This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • 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

Reply
  • 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

Children
Related