Forgot your password?
typodupeerror
Input Devices Security Wireless Networking

Sniffing and Decoding NRF24L01+ and Bluetooth LE Packets For Under $30 46

Posted by timothy
from the on-the-cheap dept.
An anonymous reader writes "I was able to decode NRF24L01+ and Bluetooth Low Energy protocols using RTL-SDR. As far as I can see, this is the first time NRF24L01+ is being decoded, especially considering the low entry price for the hardware. Given the extreme popularity of this transceiver, we are likely to see a wave of hackers attacking the security of many wireless gadgets, and they are likely to succeed as security is usually the last priority for hardware designers of such cheap gadgets. A lot of work has been done to decode bluetooth using dedicated hardware, and I am sure this software can be adapted to output the right format as input to existing Bluetooth decoders such as Wireshark."
This discussion has been archived. No new comments can be posted.

Sniffing and Decoding NRF24L01+ and Bluetooth LE Packets For Under $30

Comments Filter:
  • RTFA, everyone... (Score:5, Informative)

    by Shoten (260439) on Tuesday January 21, 2014 @02:19PM (#46027527)

    He isn't decrypting the traffic; he's just able to pull the raw packets from the air and express then, still encrypted, as data. And for BTLE, he isn't even able to do that, as he can't manage the frequency agility. So he isn't even seeing the encrypted data, just the BT advertisements...which you can already do with a variety of tools (bluetoothscan, bluelog, etc.) and a cheap BT dongle with greater range than the setup he has put together.

    It's a clever kluge for capturing and reading 2.4 GHz traffic with a sub-2.2 GHz device on the cheap but it's not really meaningful from a security perspective.

  • by mpeg4codec (581587) * on Tuesday January 21, 2014 @03:22PM (#46028289) Homepage

    Hi, I'm a Bluetooth Security researcher [lacklustre.net]. My primary focus is on BLE for which I built a highly robust sniffer on the Ubertooth platform [sourceforge.net]. I have experience in other aspects of Bluetooth.

    TL;DR: Classic Bluetooth is very secure, BLE is secure under some circumstances. Even if you leave your Bluetooth on in discoverable mode, there isn't much an attacker can do to harm you barring bugs in your Bluetooth stack.

    Bluetooth is a well-designed protocol stack that takes security seriously in its design. Implementation quality (and bugs therein) varies from stack to stack. It's always a good idea to disable Bluetooth if you aren't using it, as is the case with any other remotely accessible feature.

    Classic Bluetooth has used Secure Simple Pairing (SSP) since 2.1 in 2007. This pairing mechanism is based on ECDH to provide perfect forward secrecy and is highly secure. There was one weakness discovered in the numeric entry pin mode [blackhat.com] in 2008 by Andrew Lindell. This mode is not commonly used in older devices and more recent devices do not implement it. It's effectively impossible for an attacker to sniff any data sent over Bluetooth with SSP.

    BLE has major weaknesses in its pairing protocol that I spoke about at BlackHat USA 2013 [blackhat.com] and other venues. For the most recent video see my presentation at USENIX WOOT 13 [usenix.org].

    In BLE, a passive eavesdropper who is present during pairing can recover the secret key used to encrypt all communications. This effectively makes the security worthless. However, if the attacker is not present during pairing then the encryption is very effective. It uses AES-CCM and doesn't have any major flaws in the design. AES-CCM is used in WPA2-AES; it's well-established and has no major shortcomings.

    Finally, some Bluetooth stack implementations have bugs. I've found remote bugs in one major vendor's stack.

HELP!!!! I'm being held prisoner in /usr/games/lib!

Working...