BLE minimal modifications to use pre shared key auth and encryption

[Fabien Comte]

Hello,

I have a nRF52 to nRF52 connection. I want to secure it (auth and if possible encryption) with a pre shared key. What are the points that I have to modify please ?

Thank you.

[Petter Myhre]

It is difficult to completely remove the possibility of getting connected to malicious devices, but there are things you could do. This is because in BLE you usually don't set a security requirement on the connection, you set it on characteristic values, CCCDs and so on. So a device can connect, but the security level of the connection must be high enough to access the characteristic values. You could of course implement a general security requirement of the connection in the application, for example by using a timer a disconnect if the required security level is not reached in a certain amount of time.

To achieve a higher level of privacy you can use the resolvable private device address type. This means that friendly (bonded) devices can identify the device, while unfriendly (unbonded) devices cannot. The actual device address changes periodically, typically every 15 minutes, but it can be resolved by using an Identify Resolving Key (IRK). If a device uses this address type it can distribute the IRK when it bonds with other devices. Then the device will generete its device address using the shared IRK, and the other device can resolve the device address to identify the trusted device.

If you don't want malicious devices to connect you should use a whitelist. A whitelist on the peripheral will ignore connection requests from centrals that are not in the list. Put the IRK of your trusted device into this whitelist. To become a trusted device you need to bond.

The first time you connect you should authenticate the other device, and you can do this by using your pre-shared key when you bond. You can bond by using Passkey Entry or OOB. The key used with Passkey Entry is short, so I would recommend using a 128-bit key with OOB, this is much more secure.

With OOB the 128-bit key is normally transferred by some other means, for example by using Near-Field Communcation, but you can also have this static in our SoftDevices. The OOB key is intended to be random, so setting it statically is less secure.

Please see this and this MSCs for how to do bonding with OOB.

On subsequent connections you can encrypt the link with the keys shared during bonding. See this and this MSCs.

[Fabien Comte]

Thank you for your response. Is there any code to illustrate how to code it please ?