• State Suggested Answer
  • +1 person also asked this people also asked this
  • Replies 20 replies
  • Answers 1 answer
  • Subscribers 68 subscribers
  • Views 8159 views
  • Users 0 members are here
Attachments (6) Download All
Nordic Case Info
  • Case ID: 218140
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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?

Parents
  • 0

    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.

  • 0 in reply to David Edwin

    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.

  • 0 in reply to Acutetech

    Erase and Reflash the board running the peripheral to delete the bond and try again. 

    For nRF connect , click on the adapter wheel, then click "delete bond information".

    I can see that the encrypted packets are being decrypted as "Encryption Information" and "Master Identification" are all encrypted packets.

    In the Nordic_CLI device, click on the UART over BLE and then click UART TX. Click on the arrow so that the Nordic CLI will send periodic notifications.

    It is possible some packets are not decrypted correctly if they are received incorrectly on the sniffer, but that will not impact the entire connection.

    Read the user guide to setup the wireshark profile for the sniffer. (section 2.3.2 and section 2.3.3)

  • 0 in reply to David Edwin

    I have tried this cycle several times and almost always the decryption fails. I am about to give up with a "broken for me" conclusion. I did get one session in which I successfully bonded and then nRF Sniffer/Wireshark could decrypt each of the (encrypted) notifications from the peripheral, but almost always I get the "packet decrypted incorrectly" messages.

    Interestingly, my most recent session (attached) shows bonding at around packet 4401, and some packets correctly decrypted until packet 4444, then failed packets with a few correctly decrypted packets interspersed (e.g. 5540, 5672, 5686). From 4444, the only successfully decrypted packets are sent by the slave - I don't know whether this is significant. Could there be some timing issue? e.g. packets come too fast to be processed?

    Probably an unrelated bug/feature: whenever I ask nRF Connect to reconnect to the bonded peripheral I get a "failed to authenticate" dialog, even though the nRF Connect behaviour shows that it has connected correctly. 

    ble_app_cli_2.pcapng

  • 0 in reply to Acutetech

    If you want to re-connect to bonded peripheral, then the "perform bonding" check box must be ticked when in the pairing screen.

    Keep the boards close by for the test, maybe a few centimeters apart, with the sniffer in the center.

  • 0 in reply to David Edwin

    No better. The boards are almost touching. Most (but not all) packets give "packet decrypted incorrectly" messages. There is no sign of packets being lost or corrupted prior to encryption being enabled.

    Have you actually tried the identical setup yourself?

  • 0 in reply to Acutetech

    sniffer_pca10040_mic_recover_v2_18Dec2018.hex

    This seems to perform better for MIC failure. can you test this and let me know.

    Edit: Updated hex fix

Reply Children
No Data
Related