Capture LE Secure connection occurs bad MIC after successfully sniffering the air packets for a while

[Eric Dong]

Hi，

I tried to build a BLE sniffer environment. And it works well to capture the LE secure connection air packet after Eable Secure Connections debug mode（uses the debug keys specified in the Bluetooth Core Specification）

But I noticed MIC error reported on Wireshark after capturing the connection for a while （sometimes 3-5 minutes，sometimes half-hour）。

The sniffer fimware and profile used is nrf_sniffer_for_bluetooth_le_3.0.0_129d2b3.zip。

Wireshark version is Wireshark-win64-3.2.5.exe

The board used is nRF52840DK。

[Edvin]

Hello,

Is it possible to send the sniffer trace?

I assume you have applied some filters here, since there are quite a few packets missing (looking at the packet numbers).

I suspect that there is some packet that the sniffer is missing, that includes some connection update, which causes the encryption to go bad after this.

What devices are you sniffing? Are both master and slave nRF Devices?

BR,

Edvin

[Eric Dong]

The slave device is nRF52840DK running zephyr/samples/bluetooth/peripheral_hr/

The master device is Android Smartphone(HORNOR Play4T Pro) with nRF connect APP. (Also tried with other smartphones, issues are the same)

For company security policy, I can not upload the sniffer trace directly to Devzone. Is it OK to share the trace file with you by mail? 

[Edvin]

I can't see anything particular in the sniffer trace that you sent me. (Not the same as in the screenshot above).

In the other one, the packets are decrypted incorretly e.g. at packet 15865, but later, in packet 15868 it is decrypted correctly again.

It may be that the phone is doing something causing them to use some other key (although that doesn't seem likely, since the sniffer is able to decrypt later).

However, is there a specific reason for why you need the sniffer trace? Are you experiencing any issues while developing?

BR,

Edvin

[Eric Dong]

Hi Edvin:

About your comments below:

"It may be that the phone is doing something causing them to use some other key (although that doesn't seem likely, since the sniffer is able to decrypt later)."

I also did the same test with 2 nRF52840DK, one is slave (peripheral_hr) and on is master (central_hr). The issue still occurs, but I can see the communication betwen the 2 paired devices works well from printed log.

As you can see when the first MIC error occured, as the test running seems MIC occured more frequently. At the final, the sniffer can not capture any data  (lost sync with channel hopping?). But checking with the printed log, 2-paired devices are communicating well with each other.

I am wondering if there are some weak points in sniffer firmware or Nordic provided wireshark plugin?

The reason for using a sniffer trace, from my experience, it's quiet common and usefull when we develop some wireless product. There is no specific developing issues till now. Sniffer trace is used just for easy debugging

[Edvin]

Eric Dong said:

(lost sync with channel hopping?

 Yes. It looses the packets that contains updated channel maps, and is no longer able to follow the channel hopping.

 

Eric Dong said:

I am wondering if there are some weak points in sniffer firmware or Nordic provided wireshark plugin?

 I am not sure. I will forward that question with this description. 

 

Eric Dong said:

I also did the same test with 2 nRF52840DK, one is slave (peripheral_hr) and on is master (central_hr). The issue still occurs

 In that case we can rule out that it is because the phone does something weird.

Some background:

The nRF Sniffer was developed a while ago, while we only had the nRF5 SDK, and not yet Zephyr. 

In the earlier versions of the nRF5 SDK we included the option to use the Debug key for the LESC, but at later SDKs this was removed. I am not sure why. 

We didn't receive many complaints about this, so whether or not it has been much used I am not sure. 

But thank you either way for reporting. I will bring it on to the developers of the nRF Sniffer.

One of the main advantages of LESC is that it is un-sniffable (that is, as long as you don't use the debug key). This is because the keys are never sent over the air. If you do encounter any issues, you may try to temporary remove the LESC from the project, if you need the sniffer trace to find something.

Best regards,

Edvin