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

[bojan]

Hello, guys!

We are in an evaluation phase of our future product. Our plan is to use nRF52840-based module and the latest SDK 17.0.2 or FreeRTOS or Zephyr RTOS (will be decided later).

Here is a short description of the use-case:

The device containing nRF52840 SoC should act as both central and peripheral (dual role).

Peripheral role:

As a peripheral, the nRF52840 will advertise itself (its name + UUIDs of services). Central devices will be smartphones (Android/iOS).

Once a smartphone discovers nRF52840 peripheral, it should have the possibility to safely transfer some data containing its unique ID on the pressure of a Button on the phone screen. There will be no pairing and bonding between nRF52840 and smartphones. 

 - 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.

 - Is it some kind of dynamic data encryption on the application level the only thing that remains?

I am aware that nRF52840 contains Cryptocell, AES CCM,  ECB blocks.

 -  Can we benefit from them for doing data encryption/decryption?  

-  What we would need on the phone side for the reverse operation decryption/encryption?

Thanks in advance for your time and efforts!

Sincerely,

Bojan.

[Einar Thorsrud]

Hi Bojan,

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

bojan said:

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).

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.

 - 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

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.

Can we benefit from them for doing data encryption/decryption?  

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

What we would need on the phone side for the reverse operation decryption/encryption?

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

Einar

[bojan]

Hello, @Einar Thorsrud

Thanks for your reply.

Einar Thorsrud said:

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.

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.

[Einar Thorsrud]

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.