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

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
  • "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."
    I'm not allowed to send the full main.c file, but I think this is the part where encryption is initiated:

    // Security parameters to be used for all security procedures.
    sec_param.bond = 1;
    sec_param.mitm = 0;
    sec_param.lesc = 0;
    sec_param.keypress = 0;
    sec_param.io_caps = BLE_GAP_IO_CAPS_NONE;
    sec_param.oob = 0;
    sec_param.min_key_size = 7;
    sec_param.max_key_size = 16;
    sec_param.kdist_own.enc = 1;
    sec_param.kdist_own.id = 1;
    sec_param.kdist_peer.enc = 1;
    sec_param.kdist_peer.id = 1;
    err_code = pm_sec_params_set(&sec_param);

    It seems to me that these are the most lenient options possible so the sniffer should have no problems figuring out how to decrypt the packets. So it appears that my bonding (pairing?) is very insecure, but afterwards the packets (the ones that are sent when I press the button on the remote) are properly encrypted (with 128-bit AES-CCM, if I understand my google searches correctly)? So as long as the user performs the bonding (pairing?) in a secure area, my product should be considered a secure product?

    "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."
    As soon as I type in any other channel than 37,38, or 39 the textbox in Wireshark for "Adv Hop" turns red, as to indicate an invalid value. Hence, I'm not able to change channels at all. So I never see any packets at all from my remote after the bonding (pairing?) stage.

Reply
  • "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."
    I'm not allowed to send the full main.c file, but I think this is the part where encryption is initiated:

    // Security parameters to be used for all security procedures.
    sec_param.bond = 1;
    sec_param.mitm = 0;
    sec_param.lesc = 0;
    sec_param.keypress = 0;
    sec_param.io_caps = BLE_GAP_IO_CAPS_NONE;
    sec_param.oob = 0;
    sec_param.min_key_size = 7;
    sec_param.max_key_size = 16;
    sec_param.kdist_own.enc = 1;
    sec_param.kdist_own.id = 1;
    sec_param.kdist_peer.enc = 1;
    sec_param.kdist_peer.id = 1;
    err_code = pm_sec_params_set(&sec_param);

    It seems to me that these are the most lenient options possible so the sniffer should have no problems figuring out how to decrypt the packets. So it appears that my bonding (pairing?) is very insecure, but afterwards the packets (the ones that are sent when I press the button on the remote) are properly encrypted (with 128-bit AES-CCM, if I understand my google searches correctly)? So as long as the user performs the bonding (pairing?) in a secure area, my product should be considered a secure product?

    "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."
    As soon as I type in any other channel than 37,38, or 39 the textbox in Wireshark for "Adv Hop" turns red, as to indicate an invalid value. Hence, I'm not able to change channels at all. So I never see any packets at all from my remote after the bonding (pairing?) stage.

Children
  • Ok. So you are using the nRF5 SDK, then I also see that you are using bonding, but not mitm.

    arnoldw said:

    So as long as the user performs the bonding (pairing?) in a secure area, my product should be considered a secure product?

    That is correct. The mitm and oob and all that is only used for the pairing process. When the devices are bonded, it doesn't matter how they originally exchanged those keys, as they will have the same level of encryption in the end. So if the encryption is "Just Works", meaning the keys will be sent over the air, but noone was around to pick up the keys, then the connection is just as secure as if you had used all the high end encryption methods. 

    arnoldw said:
    So I never see any packets at all from my remote after the bonding (pairing?) stage

    That is probably correct. I havent tested in a while, but I imagine that the sniffer will give up after a while, and go back to sniffing on the advertising channels. 

Related