Out Of Band Methods

[Sreejith Sundh]

Hi,

I would like to secure my application using security mode 1 level 3. LE Legacy pairing with OOB key sharing. (both master and slave device does not have I/O Capabilities). what are the possible OOB methods which I can follow here? Is only NFC can use here? what are the OOB methods other than NFC? I have heard about hardcoded data, what is mean by hardcoded data from factory? is there any example or reference to learn more about this?

I am really looking forward for your recommandation what I can follow here to secure my application.

Thanks and Regards,

Sreejith

[Edvin]

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

[Sreejith Sundh]

Edvin said:

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.

Hi Edvin,

Do you know any of atricle or any vlogs related to BLE security in detail and how can they implemented especially Nordic? Because I could not understand the concept of security in BLE, also it makes confusing some parameters such as Link Key, 128 bit Secret code etc...

It would be great if you share any useful sources to learn more about BLE security and their code implementation (would be plus if it is from Nordic).

Thanks and Regards,

Sreejith

[Edvin]

Hello Sreejith, 

Just be aware that this pre-bonding during production falls a bit outside the typical guides and theories.

Sreejith Sundh said:

It would be great if you share any useful sources to learn more about BLE security and their code implementation (would be plus if it is from Nordic).

From the top of my head, I can't think of anything in particular, but you can check out this "Bluetooth LE Security Study guide" from Bluetooth.com.

What I meant to point out is that once two devices are bonded, it doesn't really matter how they were bonded. The result of a bonding information is to exchange a common key between two devices. Whether this key is sent over the air (BLE), sent over the air via a temporary encrypted link using either a 6 digit passkey or using LESC (Diffie Hellman), doesn't matter. The end result is always that the two devices will have a LTK (Long Term Key) and an LTK if any of the devices uses address resolution (not relevant in your case, I think). 

Best regards,

Edvin