Out Of Band Methods

RE: Out Of Band Methods

Edvin — Mon, 01 Aug 2022 07:16:37 GMT

Hello Sreejith,

1: Looking at the rest of this discussion. How do you plan to exchange the keys? Did you consider any of the things we discussed in the my previous replies? If you plan to pre-program these 128 bit keys, you can generate the 128 bit key however you want (on a computer).

2: If you plan to create and store bonding information before programming the devices (and not to let them pair and bond over the air directly after programming), then you need to look at how the devices typically do this. As I said before, look at the ble_app_hrs and ble_app_hrs_c examples. They need to know the pre-shared LTK (128-bit key) that they will both use, and they need to know the BLE address of the other device.

BR,

Edvin

RE: Out Of Band Methods

Sreejith Sundh — Fri, 29 Jul 2022 11:20:01 GMT

Hi Edvin,

Thanks for your response, I would like to secure my app.

1. How can I create 128 bit key for my peripheral device ?

2. How a central device possible to connect with my peripheral device if central device knows this generated 128 bit key? What method or example should I follow here for the better reference?

Thanks for your valuable time and suggestion.

with Regards,

Sreejith

RE: Out Of Band Methods

Edvin — Wed, 22 Jun 2022 11:26:01 GMT

Hello Sreejith,

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

[quote user="Sreejith Sundh"]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).[/quote]

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

RE: Out Of Band Methods

Sreejith Sundh — Wed, 22 Jun 2022 07:52:55 GMT

[quote userid="26071" url="~/f/nordic-q-a/87375/out-of-band-methods/365303"]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.[/quote]

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

RE: Out Of Band Methods

Edvin — Fri, 29 Apr 2022 13:43:52 GMT

[quote user=""]I would like to secure my application using security mode 1 level 3. LE Legacy pairing with OOB key sharing[/quote]

And

[quote user="Sreejith Sundh"]SEC_PARAM_OOB set to 0 [/quote]

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.

RE: Out Of Band Methods

Sreejith Sundh — Thu, 28 Apr 2022 08:42:06 GMT

[quote userid="26071" url="~/f/nordic-q-a/87375/out-of-band-methods/365326#365326"]No, there are no samples doing this. What SDK do you plan to use? The nRF5 SDK or the nRF Connect SDK?[/quote]

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

RE: Out Of Band Methods

Edvin — Thu, 28 Apr 2022 08:17:24 GMT

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

RE: Out Of Band Methods

Sreejith Sundh — Thu, 28 Apr 2022 07:32:46 GMT

Hi Edvin,

Thanks for your response.

[quote userid="26071" url="~/f/nordic-q-a/87375/out-of-band-methods/365303#365303"]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).[/quote]

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

RE: Out Of Band Methods

Edvin — Thu, 28 Apr 2022 07:03:43 GMT

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