• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 62 subscribers
  • Views 2554 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 125892
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Is re-pairing necessary with MITM protection?

Mateusz

I am working on a peripheral. This peripheral is IO display only. On the other side, the central is keyboard + display. I have a single, custom service with a single characteristic. Said characteristic is readable and writable and requires both encryption and authentication. Pairing seems to work - I can read and write to it successfully.

However, with bonding enabled, once I re-connect and try to read or write to that characteristic, I get an "Insufficient Authentication (Error Code 0x05)" error.

Is this expected? When using MITM protection, does a central always need to re-pair?

  • 0

    According to a book "Getting Started With Bluetooth Energy" by Kevin Townsend & others, "Insufficient Authentication (...) denotes (...) that the link is encrypted, but the LTK used to perform the encryption procedure is not authenticated (generated with man-in-the-middle protection (...)) while the permissions required authenticated encryption".

  • 0

    Hi,

    Could you provide a sniffer trace ?

    Have you make sure when you re-establish the connection, the LTK is used and the connection is encrypted using the LTK.

    My suspicion is that the LTK was not stored properly (or not exchanged at all if it was only pairing not bonding, initially). So when re-establishing connection, the link is not encrypted , causing Insufficient Authentication.

    You can check in the code if BLE_GAP_EVT_CONN_SEC_UPDATE is triggered or not when the connection is established. But it's the best to have the sniffer trace.

  • 0

    Here's a log - see link below. It was captured on MacOS with Xcode's PacketLogger, but it's viewable with WireShark. The flow is (more or less) - connect to the device, pair and bond, read and write the characteristic value (successfully), then disconnect. Then, connect again and attempt to read the characteristic value (fails). MacOS then begins to re-pair. In the PacketLogger, I see that the LTK is distributed properly - it's used on next connection for encryption. https://goo.gl/BYKNeS

  • 0

    The log didn't show how the initial bonding is performed. I would suggest you to get hold of a nRF51 DK (or nRF52 DK ) and capture a sniffer trace.

  • 0

    Looks like the issue was with non-volatile memory. Security properties were not being saved properly. Why or how - I'm not sure yet, but that's a different issue.

    So if a device is paired and bonded with MITM protection, authenticated reads or writes should succeed on the initial and following connections.

    Thanks Hung Bui for your help. I deleted my previous "answer" as I was misunderstanding the book quote.

Related