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

[veletron]

Hi

My device is a medical device, we are now beginning verification. One of the items on the spec requires verification that 128bit AES is used during post-bond comms with the device. The device uses 'Just Works' legacy pairing, Mode 1, with Security level 2. I am aware that this is using 128Bit AES-CMAC, but am wishing to know if, from the outside anyone has an idea how this could be verified?

My only thought is doing this via the Nordic Sniffer app with wireshark, but this is pretty long winded!  

Karen

[Einar Thorsrud]

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

[veletron]

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

[Einar Thorsrud]

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 - 6886.2021-01-13T17_53_34.999Z-log.txt, though that is probably not needed).

Einar

[veletron]

Hi

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

[Einar Thorsrud]

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