Is re-pairing necessary with MITM protection? [closed]

mateusz- gravatar image

asked 2017-10-12 18:00:17 +0200

updated 2017-10-12 18:01:47 +0200

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?

edit retag flag offensive reopen delete report spam

Closed as "the question is answered, right answer was accepted" by Mateusz at 2017-10-16 15:57:05 +0200


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

Mateusz ( 2017-10-12 18:10:32 +0200 )editconvert to answer


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.

Hung Bui ( 2017-10-13 16:35:35 +0200 )editconvert to answer

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

Mateusz ( 2017-10-15 02:53:56 +0200 )editconvert to answer

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.

Hung Bui ( 2017-10-16 09:42:47 +0200 )editconvert to answer

1 answer

Sort by » oldest newest most voted
mateusz- gravatar image

answered 2017-10-16 15:56:36 +0200

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.

edit flag offensive delete publish link more

User menu

    or sign up

Question Tools


Asked: 2017-10-12 18:00:17 +0200

Seen: 34 times

Last updated: okt. 16