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.
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.
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.
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.
Thank you for your response. Is there any code to illustrate how to code it please ?
How to code what? Could you be a bit more specific on what you are having trouble with? What exactly do you want to implement?
A basic device and central with OOB passkey example. Document graphics are probably enough but it's difficult for me to find the corresponding handlers / functions, how to feed them. An example helps me to test and appropriate the knowledge.
Hi Fabien, I would suggest you to use our ready-made library : advertising library and device manager library.
Have you tried our SDK's examples and get familiar with how those libraries work? We have an passkey example with ble_app_gls project. You need to type a 6 digit passkey on the central to encrypt the link.
For OOB you can try the experimental_ble_app_hrs_pairing_nfc in SDK v11.
Please be aware that the nRF52 NFC module is only a tag, not a reader, so you can't do NFC reading from the nRF52. You need a peer that can do NFC reading. For example a Windows 10 PC that has NFC and BLE.
After the 2 device has been paired and bonded, the LTK (Longtermkey) is exchanged can be used for furture connection. Also the address identification of both peer also exchanged and can be used as whitelist to avoid connection from unwanted device. Please have a look at the advertising module. And have a look here.