How to verify that BLE comms are encrypted using 128bit AES (Mode 1, Security Level 2)

RE: How to verify that BLE comms are encrypted using 128bit AES (Mode 1, Security Level 2)

Einar Thorsrud — Thu, 14 Jan 2021 07:41:03 GMT

Hi Karen,

Then I understand it would be a bit of hassle. I would think it should be possible to see this from Android as well, but I do not have a Android device in my home office to I have not been able to check how it looks. Alternatively, perhaps your initial idea of using a sniffer is better after all. I am not sure.

Einar

RE: How to verify that BLE comms are encrypted using 128bit AES (Mode 1, Security Level 2)

veletron — Wed, 13 Jan 2021 18:29:21 GMT

My posted log was from NRF Connect on Android.

Our device has some requirements where the app running on the central (ios/android only) has to ID its self after connection/bond. If it does not do this then it gets kicked (by the peripheral). I was hoping that the nRF Connect app on Android showed similar info to the same app on a PC, but it seems not. Getting NRF Connect on a PC to run and show the info in your log works fine, but requires the firmware on the peripheral to be modified to prevent the central getting kicked post-bond.

This obviously then leads to production firmware not being what is verified - and it also gets more complicated for the verification team.

If that's the only way of achieving this then fair enough, we will need to jump through the hoops!

Karen

RE: How to verify that BLE comms are encrypted using 128bit AES (Mode 1, Security Level 2)

Einar Thorsrud — Wed, 13 Jan 2021 18:02:35 GMT

Hi Karen,

Which nRF connect platform and version are you using here? You probably get much of the same from Android, but these status codes I assume refer to some Android API I am not familiar with.

Referring to nRF Connect from desktop, you see security level clearly stated in the short log. In this example I use a GLS example and configure nRF Connect to bond, connects and bond. Then I disconnect and reconnect. As you can see, log shows that link is secured, including security mode and level both when bonding and when securing the link after reconnecting. (I also added full log for reference - devzone.nordicsemi.com/.../6886.2021_2D00_01_2D00_13T17_5F00_53_5F00_34.999Z_2D00_log.txt, though that is probably not needed).

Einar

RE: How to verify that BLE comms are encrypted using 128bit AES (Mode 1, Security Level 2)

veletron — Wed, 13 Jan 2021 14:25:37 GMT

Hi Thanks for your response. Trying to have it bond from NRF Connect, and looking at the resulting log, can you tell me where I can find a reference as to what the numbers in the brackets mean?

D 14:10:44.584 [Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDING (11)

D 14:10:44.604 [Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)

I 14:10:45.875 Connection parameters updated (interval: 30.0ms, latency: 30, timeout: 4000ms)

I 14:10:48.165 Read Response received from 36f71401-9511-4c82-a7dd-d66d1e837a30, value: 0 bytes

D 14:10:48.228 [Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDED (12)

My main reason for asking is that I am wondering if the '12' actually means 'Mode 1, security level 2'.

Karen

RE: How to verify that BLE comms are encrypted using 128bit AES (Mode 1, Security Level 2)

Einar Thorsrud — Wed, 13 Jan 2021 13:30:54 GMT

Hi Karen,

The way this is implemented in the SoftDevice and nRF5 HW there are only two possibilities. Either the BLE packets are clear text or they are encrypted with 128 bit AES-CCM. You can use a sniffer, as you write. Or you could use a tool such as nRF Connect BLE (provided that you trust the information it gives you).

Einar