Out Of Band Methods

Hello,

By hardcoded data there may be at least two different meanings.

1) Either, you can hard code bonding information directly into the devices on the factory. That would mean that you have two devices talking Bluetooth LE (BLE) with each other, without ever needing to connect to anything else (e.g. if you loose one of them, you would have to buy a new pair). 

2) The other option is to "pretend" that the devices have IO capabilities, and in the case that the users usually would be asked to enter/read a 6-digit passkey, these are already stored in flash. The first time they are turned on, they will find eachother, connect using the prestored 6 digit key, and then store bonding data (meaning that after this they will no longer use the 6-digit passkey, and they will behave like in 1).

Note to 1): You wouldn't typically store the actual bonding data in the application's .hex file, but you would turn on, see that the module that handles bonding information (peer manager in the nRF5 SDK) doesn't have any bonding data stored, and then read out the address and long term keys (LTK, the key used in bonding) from somewhere in flash (NRF_UICR->CUSTOMER[] registers, perhaps), and use the peer manager API (nRF5 SDK, called something else in nRF Connect SDK) and store bonding data that way.

Both of the options are viable. I would say that the first one is more secure* but the last one is probably easier to do.

* The reason that the first one is more secure is that you are storing the bonding keys and address of the other device directly, so there is basically no way for any 3rd party device to interfere with this. If you use the 6 digit key, it is far easier to set up, but if someone was to try to bruteforce the 6-digit key when the devices turn on for the first time, there is a chance that they will be able to intersect the connection. Also, if they are actually able to crack the key, and you have no way of factory resetting the devices then it will store the wrong bonding data, and they will not be able to connect to the correct device. 

If you want to use method 1, then the device needs to know the preshared LTK, which needs to be the same on both devices. This is fine, as you can generate one key for every pair. You also need to know the BLE address of the device you want to bond to. There are two ways of achieving this. Either you can generate addresses that you use for your devices. This way you can generate the LTK and two addresses. Or you can use the preprogrammed address, but in that case, you need to read out the address from flash, and then store it on the other device. That is not difficult, but you need to consider this process for a potential production line.

Best regards,

Edvin

Hi Edvin,

Thanks for your response.

user26071 said:

Either, you can hard code bonding information directly into the devices on the factory. That would mean that you have two devices talking Bluetooth LE (BLE) with each other, without ever needing to connect to anything else (e.g. if you loose one of them, you would have to buy a new pair).

My application is a peripheral device and required to connect with only one client device. I think this can be one of the good option for me. is there any example to know further about the implementation of this method?

Where can I find some references for this method. such as implementation, theoretical knowledge....

Thanks for your time and effort.

With Regards,

Sreejith

Hello,

No, there are no samples doing this. What SDK do you plan to use? The nRF5 SDK or the nRF Connect SDK?

If you use the nRF5 SDK I would suggest that you have a look at the example pair found in:

nRF5 SDK\examples\ble_peripheral\ble_app_hrs

nRF5 SDK\examples\ble_central\ble_app_hrs_c

and monitor what they do when they connect for the first time. How they store the bonding data, and then try to intersect this and store the bonding data without connecting first.

Best regards,

Edvin

user26071 said:

No, there are no samples doing this. What SDK do you plan to use? The nRF5 SDK or the nRF Connect SDK?

I am using nRF5 SDK.

but in example ble_app_hrs (peripheral), the SEC_PARAM_OOB set to 0 (that means it is not using OOB method). I got your point to monitor the procedure. 

Please suggest me some reference documentation if you find regarding the security and implementation (Nordic family) 

Thanks and Regards,

Sreejith

I would like to secure my application using security mode 1 level 3. LE Legacy pairing with OOB key sharing

And

Sreejith Sundh said:

SEC_PARAM_OOB set to 0

That is true, but these modes and levels only apply to the procedure of generating keys and distributing them. The way that the devices generate a shared secret. If the shared secret is already pre-programmed, then this doesn't apply.