• State Verified Answer
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 88 subscribers
  • Views 3047 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 263263
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Encrypted packet decrypted incorrectly (bad MIC)

vctrvlad

Helo, I am developing a BLE product, and @ encryption stage, I get thie message on the topic.

I attach my log for further information.

The log entry that gives the message in the topic is: 

2629 23.809161 Master_0x23c8cccf LE 1M LE LL 1 399691 21 Encrypted packet decrypted incorrectly (bad MIC)

Any help on how to sort this out would be appreciated.

Thank you, decrypted incorrectly.pcapng

Victor

  • 0

    Hi Victor, 

    Encrypted packet decrypted incorrectly (bad MIC)

    It is most commonly caused by the sniffer not having the private keys for the connection, so it can not decrypt the packages it intercepts.

    You can refer to this Sniffing a connection between paired devices documentation to sniff a connection between devices that are already paired.

    -Amanda H. 

  • +1

    I have not seen a MIC failure code that is actually a MIC failure and not a sniffer artifact for quite a while, however I also notice that both the devices (master and slave) are both from Dialog semiconductor.

    That stated is definitely a real MIC failure as the slave stops as soon as it realized that a MIC failure has occurred. Only one slave packet is transmitted but that is expected as it would take some time to stop the RADIO. 

    We can do a set of simple experiments to nail the issue but it feels a bit awkward to deal with the dialog parts here.

    Remove the secure connections (use any of the other pairing methods maybe legacy JUSTWORKS) and then check if things work.
    If they work then we need to dig a little into the setup of the secure connections.
    Stop the master from transmitting the first packet after encryption and let the slave transmit the packet and see if the MIC failure occurs on the slave transmit as well.

  • 0 in reply to Amanda Hsieh

    I think if the sniffer did not get the keys, the link will continue to be sniffed until the link parameters change. If the first packet from the master after encryption is a channel map update or a conn params update, its possible that the sniffer cannot see the packets (it cannot decrypt it anyway), however in this case it continues to see the master packets at the 200ms interval so my hypothesis is that this is actually a real MIC failure in the wild.
    What are your thoughts ?

  • 0 in reply to daviddedwin

    I took a quick look at the setup of the encrypted link and I think that the first master packet that was sent as an encrypted packet resulted in the Slave radio stopping in the next connection interval. This clearly points at a setup problem for the encryption, verify them carefully on your Central and Peripheral but as these are Dialog APIs, it will be a bit difficult to support them more in this forum.

    Please accept and upvote the answer if this has been helpful to you.

  • 0 in reply to daviddedwin

    Hi David, 

    From the log, it starts to get bad MIC after the link is encrypted (LL_START_ENC_REQ). If it is using LE secure connection (Diffie-Hellman) then it is not possible to decrypt the link. Need to refer to the part of  For connections that use LE Secure Connections to sniff. Also, see this similar case. 

    -Amanda H.

Related