nRF Sniffer decryption is not working after entering passkey

[Acutetech]

I am a newbie with nRF Sniffer, which I have installed on one PCA10040 board. I am sniffing communications between a Samsung phone running nRF Connect and a second PCA10040 running the glucose sample app.

I believe I am following the instructions in the User Guide section 5.5: when the glucose app prints the 6-digit passkey I enter this into Wireshark and type enter, then I enter it into the phone. The phone and peripheral then bond and work, but Wireshark starts printing "Encrypted packet decrypted incorrectly (Bad MIC)" . When I click on Log I see this:

INFO: Setting Passkey: 691295

INFO: Sent key value to sniffer: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 140, 95]

A screenshot is here:

/resized-image/__size/640x480/__key/support-attachments/beef5d1b77644c448dabff31668f3a47-e588f28969f94ee0a39b08c9e8afde0d/Screenshot-2018_2D00_11_2D00_19-10.57.32.png

Q1: Are my results expected? What should I do differently?

Q2: Assuming I am able to get beyond this problem, is it possible to sniff subsequent connections? The Central and Peripheral will be bonded and the peripheral will not print a passkey. Can nRF Sniffer decrypt the second session based on keys it has saved?

[David Edwin]

Can you mention the wireshark version used, nRF sniffer version used and board version.

Q2: Yes, nRF Sniffer should be able to sniff the subsequent re-connections.

Q1: Seems to be as expected on actions. On the timing of actions, ensure that the wireshark has the PIN before you tap to accept on the device screen (which you seem to have done as well).

Ensure you are using the nRF Sniffer v2 Beta 3 .

I will investigate after you have posted the versions of the software and hardware as requested above.

[Acutetech]

I installed software last Friday, so should be "latest".

Wireshark says 2.6.4

I have two nRF52 boards with labels that say PCA10040 1.2.4 2018.39 (nRF sniffer) and 2018.49 (Peripheral).

nRF Sniffer was extracted from a zip file nrf_sniffer_2.0.0-beta3_12oct2018_1c2a221.zip

I confirm that I entered the passkey in Wireshark before entering it in the Central.

The peripheral, slave and central are within say 75cm of each other. AFAIK I disable BLE on other nearby devices.

I have just tried sniffing a different peripheral which uses Just Works bonding (no passkey). I continued to use nRF Connect on the Samsung phone. They bond correctly but nRF Sniffer behaves the same, with "Encrypted packet decrypted incorrectly" immediately after the LL_START_ENC_REQ packet.

[David Edwin]

If the just works crypto does not work , that could be a bug. nrf_sniffer_2.0.0-beta-3-1_08a85a0.zip

Can you try the attached zip file to see if it performs better.

[Acutetech]

I get the same results with this version (using the glucose app in one PCA10040, using a 6-digit passkey, and nRF Connect on the phone). I replaced the files in the Wireshark/extcap directory and re-programmed the PCA10040 with the new hex file. As soon as the LL_START_ENC_REQ appears all subsequent packets have "Encrypted packet decrypted incorrectly" messages.

When I look at the release notes I see "only one side (initiator or responder) needs to be set in Debug mode" - I don't understand this. I don't think that applies to me, right? Do I need to do something to place one of my devices in "debug mode"? If so - how?

I have also been struggling with a different problem relating to loss of bonding data:

https://devzone.nordicsemi.com/f/nordic-q-a/40412/android-phone-loses-bonding-information-when-trying-to-read-characteristic

From that work I have learned that either the Central or the Peripheral can start encryption. Does this matter for nRF Sniffer?

[David Edwin]

Can you verify it works for just works first ? central is the one the starts crypto and peripheral can request start, sniffer should handle both cases.

The debug keys are not for just works/passkey/oob situations so that is not relevant for you.

I saw your referred cases and would suggest you start with a working scenario for the sniffer and once you have confidence that the sniffer is working to test the scenario you are using.

[Acutetech]

Hi David

I was thinking about this: it must be straight forward for me to replicate a working system here. Can you suggest a setup that you have tested and I can set up  as closely as possible. At present I have two PCA10040 boards plugged into two USB ports of the same Windows 10 laptop, and nRF Connect running on either an Android 8 phone or a choice of Windows 7 tablets. I can't think that there is much I can vary here, other than this: can you suggest which of the sample apps from SDK15.2 I should program into the peripheral?

Regards - Charles

[David Edwin]

lets test it first with the nRF Sniffer v2 on one of the PCA10040 boards and the ble_app_uart on the other PCA10040 board. The Win 10 laptop's ble should be used to connect the ble_app_uart and sniffed.

I can replicate the above config and we can take this forward. Will this work for you ?

[Acutetech]

Hi David - I have started on the process. So far I have installed ble_app_uart on one PCA10040 and I can communicate with it using nRF Connect on an Android tablet. (I note that the documentation here: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk5.v15.0.0%2Findex.html differs from what I see: the peripheral prints "UART started." rather than "UART Start!" and characters typed are treated as ASCII rather than hex value.

However when I click "bond" on nRF Connect I get "Bonding failed" in the log. The ble_app_uart source code includes "Pairing not supported".

I have also installed the Windows version of nRF Connect and have it running using an nRF52840 dongle (cool!). (and I see this version does use hex rather than ASCII!).

Jumping ahead: I  have connected Wireshark to a second PCA10040 running the latest nRF Sniffer you sent yesterday, and used it to sniff a session between the ble_app_uart and Windows nRF Connect.

What next?