Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Description of defect
BLE SecurityManager fails to restore saved security parameters from non-volatile memory after reset.
Target(s) affected by this defect ?
Testing using EP_AGORA and NRF52840_DK
Toolchain(s) (name and version) displaying this defect ?
Testing with GCC ARM
What version of Mbed-os are you using (tag or sha) ?
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
How is this defect reproduced ?
Build a BLE app that approves all pairing requests and has an on-board flash/filesystem. I have tried with both LittleFS and FATFileSystem using an internal FlashIAPBlockDevice and an external SPIF/QSPIFBlockDevice. Neither worked as expected.
I initialize the security manager with a file path to use and tell it to save security information --
I am using Nordic's nRFConnect utility to then connect to and initiate pairing with the Mbed BLE device. The pairing goes as expected.
Then I disconnect and reset the Mbed BLE device. On startup, I check the supposedly preserved bonding table:
I stepped through the initialization of the security manager at this stage (after pairing and a power cycle) and found that it is reading back an inconsistent security database version number, which causes the SecurityManager to reinitialize (delete) the security database...
I am seeing this happen at this line:
I would suggest using the BLE_SM example in mbed-os-example-ble to try to reproduce this issue, but that example is broken in other ways.
I will continue to debug what is happening. Am I missing a step?
I have confirmed that the file exists using the retargeted C file IO calls after initializing the filesystem.
When I try to read it, the size of the file is 0 and so no bytes are read back. This is after the security manager has initialized a new database, I then pair with the Mbed BLE device, disconnect, reset the chip, and step-debug the file read/write operations at filesystem initialization. The file is still size 0.
It seems the security manager or retargeted file I/O calls aren't successfully writing to disk or something.
The following test code appears to work fine:
The file persists through power cycles as expected and can be read back. Going to start looking at how BLE SM handles its file operations.
The BLE SM only appears to explicitly call
Even if the BLE SM destructor calls
Not sure if this is the cause of the problem, but the lack of an fclose may be leaving the file on the disk in a "dirty" state or the file I/O subsystem never flushes the written data to non-volatile memory.
I added a call to
I can see the MAC address of the Nordic BLE dongle I am pairing to is saved in the flash and restored on reset, however it does not retain any of the keys (all the encryption keys and security info are 0 in my debugger it seems).
Not sure where it would be best to put the call to delete the security db or just call
I am going to look into why the keys aren't being saved/reloaded properly.
Alright, so I was mistaken in that the keys were also being stored. I wasn't setting the "role reversal" hint and so only one set of long term keys (LTKs) were being exchanged.
I believe the original issue has been solved by the fix in my previous comment.
However, now I think I am encountering another bug. I have not yet enabled the use of privacy in my application (baby steps at the moment). So when I try to generate a whitelist from the bond table, the SecurityDb implementation passes over the entry for the bonded nRF Connect device due to this line of code:
I am not sure why having an Identity Resolving Key (IRK) is required to be included in the whitelist generated by the bond table. @paul-szczepanek-arm, can you clarify the intent behind this check?
Shouldn't any peer in the bond table be reported as part of the whitelist regardless of whether privacy features were used during pairing?