Changing default key to App generated key during connection via BLE in nRF52840

[Mathangopal]

Hi. I am currently using an nRF52840 DK board and SDK 17.0.2.

My team is implementing a default key for the first connection to device.

During the connection, we plan to generate a private and public key in the APP side and pass the public key to the device.

Through this, we are trying to achieve encrypted messaging.

Is this implementation possible in the bootloader?

Thank you and appreciate the help. 

[Einar Thorsrud]

Hi,

Everything you describe should be possible, also in the bootloader. I lack a bit of context in order to suggest anything specific, though. I assume you intend to use some custom/application specific security mechanism here? If so, why do you not use standard BLE pairing/bonding and encryption instead? Is there any reason for using a custom approach?

[Mathangopal]

HI. Thanks for the reply.

The reason is when the device is connected for the first time to our custom APP, we want it to be available to all users of the app. 

After which the device should be able to be connected to only one user of the app to prevent tempering of information received and sent from other users in the same app.

Therefore, I require a custom approach.

I want this implementation to be in the bootloader side cos I feel that whatever messages sent and received during the application level should be encrypted.

I am not sure how to implement this in the bootloader side. Do you have any idea?

[Einar Thorsrud]

Hi,

I am still not clear about the use case so I will make a suggestions, which may not be what you are looking fore. But it is often a good idea to use standard approaches if possible, instead of making your own, where it is easier to miss a corner case. Please let me know if any is appropriate or not, an if not perhaps explain a bit more. So for now I will ignore that you want this to happen in the bootloader, as I do not see the rational for it(?) and doing it in the application makes it closer to how this is handled in the SDK (example bootloader does not support pairing or bonding out of the box as we have never seen a use case for it).

If you allow anyone to do the first connection, then I suggest simply using normal connectable advertising in the application. When the first device connects you can perform pairing/bonding using LESC to have a authenticated secure connection. If you use LESC, the key is generated using Diffie–Hellman key exchange so the key remains secret. Any communication after this point will be encrypted. After a disconnect the device can advertise using a whitelist from this point so that no new device will be allowed to connect (and if an attacker spoofs the address, it will not be able to secure the link, and the link should be dropped).

Does the above approach fit your requirement? If it does, that would be good as it would use only standard Bluetooth concepts that are very well though out and tested and will give you very good security.

As you mention your custom app I wonder if it is so that you want to ensure that only users of your custom app should be allowed to communicate or use the device? If that is the case, then you could add an additional layer of security so that after securing the link using normal LESC pairing, then you exchange a key or do a challenge-response or similar so that the nRF would know that the APP is valid and other way around. If that fails, you could disconnect. I do not immediately know if or why you would want to do this, and I would not recommend it unless there is a good reason for it, but it is certainly possible.

Lastly you can implement all this in the bootloader, but that would increase the size and complexity of the bootloader significantly and we have no example code for it. So you should not do that unless you have a good reason for it, and I am not sure if that is the case?

[Mathangopal]

Hi. Thanks for the reply. If the standard approach is on the application layer then I will ignore the bootloader implementation. If I use LESC, I will generate a key and exchange the key during the first connection to the app. Then, I will use whitelist to prevent other users from connecting. Finally, the app will send another key to the device to ensure that it is the valid user from the app. Am I correct?

[Einar Thorsrud]

Hi,

I am a bit unsure about the key management you describe here. Is there a reason you should care about keys at all? Why not let the BLE stack of the phone and nRF5 SDK implementation handle this for you using normal LESC procedure only? That way you get the key exchange and encryption all out of the box in a secure and tested manner.

To ask in a different way: Do you need any additional security compared to what you get from normal BLE pairing/bonding using LESC? If so, can you describe in a high level manner what you need additionally, as it is not clear to me which part of you rrequierment is not covered by the standard approach?