• State Verified Answer
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 88 subscribers
  • Views 3059 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

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

  • 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

    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.

  • +1 in reply to Amanda Hsieh

    Yes, agree on the part where the first encrypted packet from the master (LL_START_ENC_REQ) is not decrypted by the sniffer (yes the sniffer cannot decrypt a normal LE secure connection), however the interesting part is that the slave also fails to decrypt that packet, if this was a sniffer issue alone then the sniffer will follow the link but fail to decrypt the packet however the link abruptly stops and the slave radio just stops responding.

    The slave LL should be generating a HCI or equivalent event Connection Terminated/Dicsonnected Due to MIC Failure (0x3D). The behavior for MIC failure is that the RADIO should stop immediately as soon as MIC failure is detected, in this case it stops in the next connection event and does not respond to subsequent master TX which fits the MIC failure case.

    The master LL should get a HCI or Equivalent event Connection Terminated/Disconnection Event due to connection timeout (0x08).

    I have not seen this type of issue earlier, very atypical and rare.

    Can you post the disconnection event codes for the master and slave and that should confirm the issue.

  • 0 in reply to daviddedwin

    Indeed, on the Peripheral (slave) side, I get 0x3D Disconnect reason, and on the central (master) side, the disconnect reason is indeed 0x08.

    However, I don't want to hijack the Nordic support forum for my Dialog problem right now, even though I am not sure what am I doing wrong in my setup and how to proceed.

    Thank you Amanda and David for your time.

Reply Children
No Data
Related