Safety precautions needed to restrict externals from accessing BLE registers

Hi Sumit,

It sounds like what you are describing is more or less standard bluetooth encryption? If you use LE Secure Connections (LESC) with passkey that should cover all the points you have described, and you will get a securely encrypted link between the phone and the dongle. This page has a good introduction to LESC (it describes numeric comparison, but most principles are the same for passkey entry).

If this is what you are after, then there are examples using Bluetooth pairing with LESC in both the older nRF5 SDK and newer nRF Connect SDK (for the nRF Connect SDK there are no samples using passkey but adding it is straightforward, for instance as explained in this post (this demonstrates displaying the passkey on the NRF).

Einar

Dear Einar,

Thanks a lot for your informative reply. The problem with the PASSKEY is that it's static in the example code. To make it dynamic we may always need internet connection on the app side to be synced on both side. Will the LE Secure Connections work without PASSKEY or, is there any way to make the PASSKEY dynamic?

Thanks

Hi,

Ah, the post I linked to was not the best as it explained static passkey. The passkey should normally be dynamic (generate a new every pairing attempt). A static passkey gives little security as it can be brute forced very fast. You do not need internet connection to generate a passkey, but of course you would need some output capabilities the device (like a display) in order to let the user of the peer device know the passkey.

Referring to the post I linked to before, you can use it as is but do not set CONFIG_BT_FIXED_PASSKEY=y in prj.conf (as you do not want a static passkey), and also do not call bt_passkey_set(). You will get the passkey from the bluetooth stack in the passkey_display callback. Searching through the code I see there is a sample I did not know before which you can refer to: zephyr/samples/bluetooth/peripheral_esp/src/main.c. This demonstrates displaying the passkey on the device as the post I linked to before. Passkey entry on the device is similar. But of course, which option you would use depends on which I/O capabilities you have on your device.

Note that if you do not have any I/O capabilities on the nRF side, then any of the MITM protection schemes will not work (and static passkey just give the illusion of security). You could potentially use a custom MITM protection on top here, where you use LESC just work pairing, and your own scheme for MITM protection. That would involve that the devices has to be provisioned in advance though, for instance you can use a challenge-response mechanism, where each nRF device get a unique key during production and you have a form of key infrastructure that provide the corresponding public key to the phone via Internet. This is a bit complex though, and is something you would have to manage during the life time of the product. Lastly, if you don't really need that much security you could always use a static passkey in this case, but then it would be more for convenience (prevent accidentally connecting to the wrong device) and not for adding security).