Encrypted packet decrypted incorrectly (bad MIC)

Question

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

daviddedwin · Accepted Answer

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.

daviddedwin · Answer

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. 
 vctrvlad Can you post the disconnection event codes for the master and slave and that should confirm the issue.

vctrvlad · Answer

Hello, it really seems to be a MIC failure, the returned disconnection reason in the Peripheral application is CO_ERROR_TERMINATED_MIC_FAILURE 0x3D. 
 
 Thank you for the help. The only reason I raised this questioin was to make sure is not a sniffer limitation, and it does not seem to be the case. 
 
 Thank you for the allocated time. 
 Regards, 
 Victor

Encrypted packet decrypted incorrectly (bad MIC)

Top Replies