• State Not Answered
  • Replies 3 replies
  • Subscribers 25 subscribers
  • Views 189 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288811
Options

Safety precautions needed to restrict externals from accessing BLE registers

user111085

Dear Concern,

We are using NRF USB dongle in of our products. We are developing our android app in house. We want to add some security layer in the communication between app and dongle as such externals will not be able to communication with dongle without authorization. 

We were thinking to use the following two methods to implement the security in the BLE communication layer.

a) Encrypt BLE message using public/private key (Data communication)

Only the messages will be encrypted(i.e AES256).

b) PIN code verification when establishing BLE connection (pairing)

There will be PASSKEY verification on connection.

Do you think both type of securities are needed to restrict other to sniff data or control the dongle over BLE.

And kindly let me know if nordic has already any example which addressed both kind of security.

Thanks in Advance,

Sumit

Parents
  • 0

    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

Reply
  • 0

    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

Children
  • 0 in reply to user7377

    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

  • 0 in reply to user111085

    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).

Related
Terms of service