How to improve the security of BLE data in our specific use case

RE: How to improve the security of BLE data in our specific use case

Einar Thorsrud — Mon, 05 Oct 2020 13:04:05 GMT

I see. It should be possible for you to implement the mechanism you come up with based on the crypto libraries that are available in the SDK.

RE: How to improve the security of BLE data in our specific use case

bojan — Mon, 05 Oct 2020 12:04:04 GMT

Hello, @Einar Thorsrud

Thanks for your reply.

[quote userid="7377" url="~/f/nordic-q-a/66647/how-to-improve-the-security-of-ble-data-in-our-specific-use-case/272919#272919"]I do not follow this. Using BLE bonding with LESC gives a high degree of security, and I do not see how the links you provide argue against that. You may have other reasons for using custom security, but it is not given that doing something non-standard will give a higher degree of security.[/quote]

Even though my links are not relevant we can't afford pairing and bonding. On the pressure of a button we need to:

1) Establish a BLE connection

2) Send data packet (challenge)

3) Wait for the response

4) Disconnect

Consequently, this challenge-response mechanism with custom data encryption seems to be the way to go with.

RE: How to improve the security of BLE data in our specific use case

Einar Thorsrud — Mon, 05 Oct 2020 09:39:42 GMT

Hi Bojan,

I want to mention a few points in addition to what have allready been discussed.

[quote user="bojan"]We can not benefit from the security BLE is enabling after pairing and bonding. Moreover, that kind of security seems not to be enough nowadays (link, link).[/quote]

I do not follow this. Using BLE bonding with LESC gives a high degree of security, and I do not see how the links you provide argue against that. You may have other reasons for using custom security, but it is not given that doing something non-standard will give a higher degree of security.

[quote user=""] - What would be the ways to protect that kind of data transfer from spoofing attacks? To disable sniffing unique ID and reproducing it from the faulty device[/quote]

Using standard BLE pairing you could (and should) always required to encrypt the link when connection to device there is allready a bond with. You could probably also do something similar with a custom security scheme if you really want to do it yourself. Alternatively you could use a form of challenge-response mechanism. You would need a way to handle and distribute keys though, and that would be up to you. You could also use random resoleable addresses (based on IRK), but even though the attacker don't have the IRK it could spoof the currently used address, so it may not help much. There are probably other approaches that could be used as well.

[quote user=""] Can we benefit from them for doing data encryption/decryption? [/quote]

Yes you could do that. I suggest you refer to the nrf_crypto examples in the SDK, as well as the nrf_crypto documentation.

[quote user=""]What we would need on the phone side for the reverse operation decryption/encryption?[/quote]

You would need support for the same algorithm and the corresponding key.

Einar

RE: How to improve the security of BLE data in our specific use case

bojan — Fri, 02 Oct 2020 14:34:07 GMT

Hey, Himanshu,

Thanks for your feedback! Our data exchange process should execute in an instant (as fast as possible after the button is pressed).

We can not benefit from the security BLE is enabling after pairing and bonding. Moreover, that kind of security seems not to be enough nowadays (link, link).

It seems that we need to encrypt our data on the application level. I wonder if we can benefit from that encryption hardware built into nRF52840.

Cheers,

Bojan.

RE: How to improve the security of BLE data in our specific use case

Himanshu — Fri, 02 Oct 2020 14:27:08 GMT

I am not expert here but as far as I understand you must perform pairing/bonding between the devices. This will enable the central and peripheral devices to establish shared secret keys. With this shared secret both will be able to securely perform communications ( The shared secret keys are necessary for encryption and decryption). Without pairing a peripheral is as good as a beacon device, wherein any interceptor can read it.