• State Not Answered
  • Replies 5 replies
  • Subscribers 74 subscribers
  • Views 1213 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 296319
Options

Beginner's help with Wireshark and nRF52840-Dongle programmed as a sniffer

arnoldw

I have a finished product (a very simple wireless remote control with a button) based on two nRF52832 chips and I need to determine whether the communication between the two is encrypted or not. So I would like to see the raw packets (or at least their data payload, if Bluetooth packets contains such) going through the air. I have bought an nRF52840-Dongle and programmed it to become a sniffer and I have installed Wireshark and the required Nordic Semiconductor plugin. Everything seems to work well and I see A LOT of packets when I start sniffing in Wireshark. I have no Bluetooth knowledge and I'm not quite sure how I should configure Wireshark (or do I need to do some configuration using the Python files in nrf_sniffer_for_bluetooth_le_4.1.0.zip?) to only see the "regular" packet between my nRF52832 chips that are sent when I press the button on the remote. When I put the devices into bonding mode, then I'm able to see occasional packets from/to my my devices (and hence I can determine the 6-byte addresses of them), but as soon bonding is finished I no longer see any packets from/to the devices in Wireshark (but the packets are successfully received, I've confirmed this). Can someone please help me, how do I see the raw "regular" packets that are sent when I press the button on the remote and how should I set up the filters properly to not be swamped with data in Wireshark?

Parents
  • 0

    Hello,

    It seems like you have come a long way, then.

    Just in case you didn't know: Pairing is the same as encrypting a Bluetooth Low Energy (BLE) connection, while bonding is the same as storing these encryption keys for later connections. 

    Are you using the nRF5 SDK or the nRF Connect for Desktop SDK? If you are not sure, can you please show me the snippet where you initiate the encryption, and I will probably be able to tell. Or you can upload the main.c file. 

    So when two devices are not paired or bonded, the nRF Sniffer for BLE is capable of keeping track with the connection, and show you all the packets. Once the link is actually encrypted the sniffer will no longer be able to see the packets ***. Since it is not able to pick up the packets, it will also loose track of the channel hopping seqence that the devices are using (it will keep up for a while, but once it changes, which it does regularly, it will loose track). Once it doesn't know the channel hopping sequence anymore, because this is also encrypted, the sniffer doesn't know what channel the next packet will occur on, and hence it will no longer be able to follow the encrypted traffic. From time to time you will probably see a packet or two, because they happen to bump into the channel that the sniffer is currently on.

    *** I said that it will no longer be able to see the packets once the connection is encrypted. That is partially true. It depends on what encryption method you use. There are several ways to negotiate the keys that they will use for encryption. Starting from "Just works". In this case the keys are sent over the air, and the sniffer can pick up the encryption keys, and use it to decrypt the link and follow the channel hopping sequence. 

    If you use some sort of out of band (MITM protection), the sniffer will not be able to pick up the keys. But if you use a six digit passkey (temporary key used to transfer the full key), it is an option to add this into the sniffer as well (there is a OOB key field near the top of wireshark when sniffing). Then the sniffer can use this key to decrypt the link. 

    Then there is something called LESC (Low Energy Secure Connection), which is a Diffie Hellman encryption. The keys are never sent over the air, but they agree upon it in other wayts (search for it on youtube for explanation). In this case it is not possible for the sniffer to decrypt the link. 

    So to summarize: If the sniffer is not able to pick up the encryption key in some way, then you can't see the raw packets, because the sniffer can't keep up with the channel hopping sequence (they use a new channel every connection interval). If you decrypt the link you will only see the decrypted packages, but there is probably some sort of flag in the sniffer saying whether it is encrypted or not. 

    There are events in your application telling you when the link is encrypted. If you can't tell from the log, let me know what SDK version you are using, and I can dig it up. 

    Hopefully this cleared up a few things. Please let me know if anything is still unclear. 

    Best regards,

    Edvin

Reply
  • 0

    Hello,

    It seems like you have come a long way, then.

    Just in case you didn't know: Pairing is the same as encrypting a Bluetooth Low Energy (BLE) connection, while bonding is the same as storing these encryption keys for later connections. 

    Are you using the nRF5 SDK or the nRF Connect for Desktop SDK? If you are not sure, can you please show me the snippet where you initiate the encryption, and I will probably be able to tell. Or you can upload the main.c file. 

    So when two devices are not paired or bonded, the nRF Sniffer for BLE is capable of keeping track with the connection, and show you all the packets. Once the link is actually encrypted the sniffer will no longer be able to see the packets ***. Since it is not able to pick up the packets, it will also loose track of the channel hopping seqence that the devices are using (it will keep up for a while, but once it changes, which it does regularly, it will loose track). Once it doesn't know the channel hopping sequence anymore, because this is also encrypted, the sniffer doesn't know what channel the next packet will occur on, and hence it will no longer be able to follow the encrypted traffic. From time to time you will probably see a packet or two, because they happen to bump into the channel that the sniffer is currently on.

    *** I said that it will no longer be able to see the packets once the connection is encrypted. That is partially true. It depends on what encryption method you use. There are several ways to negotiate the keys that they will use for encryption. Starting from "Just works". In this case the keys are sent over the air, and the sniffer can pick up the encryption keys, and use it to decrypt the link and follow the channel hopping sequence. 

    If you use some sort of out of band (MITM protection), the sniffer will not be able to pick up the keys. But if you use a six digit passkey (temporary key used to transfer the full key), it is an option to add this into the sniffer as well (there is a OOB key field near the top of wireshark when sniffing). Then the sniffer can use this key to decrypt the link. 

    Then there is something called LESC (Low Energy Secure Connection), which is a Diffie Hellman encryption. The keys are never sent over the air, but they agree upon it in other wayts (search for it on youtube for explanation). In this case it is not possible for the sniffer to decrypt the link. 

    So to summarize: If the sniffer is not able to pick up the encryption key in some way, then you can't see the raw packets, because the sniffer can't keep up with the channel hopping sequence (they use a new channel every connection interval). If you decrypt the link you will only see the decrypted packages, but there is probably some sort of flag in the sniffer saying whether it is encrypted or not. 

    There are events in your application telling you when the link is encrypted. If you can't tell from the log, let me know what SDK version you are using, and I can dig it up. 

    Hopefully this cleared up a few things. Please let me know if anything is still unclear. 

    Best regards,

    Edvin

Children
No Data
Related
Terms of service