17

Is Bluetooth Low Energy (BLE)'s link-layer encryption secure against an attacker who eavesdrops on some random BLE connection between two devices, but has not eavesdropped on the first connection between the two devices?

Background: When the two devices are initially paired, they derive a long-term key using a key-exchange protocol. Anyone who can eavesdrop on that initial pairing can learn the long-term key, but for purposes of this question, assume the adversary didn't eavesdrop on that initial pairing (e.g., because the adversary wasn't nearby). The two devices then use this long-term key to encrypt data sent on all future connections. BLE uses AES-CCM for link-layer encryption, which should be secure if the long-term key is unpredictable.

However, at WOOT 2013, Mark Ryan published a paper speculating about a possible attack against BLE. In his attack, the attacker injects a forged LL_REJECT_IND message to one device. Apparently, this will cause the recipient to forget the current long-term key and force a new key exchange to derive a new long-term key. The attacker can eavesdrop on this new key exchange, learn the new long-term key, and decrypt all subsequent traffic. At least, that's what Ryan speculated.

Does this attack actually work? Is BLE's link-layer encryption insecure, even if the attacker didn't capture the initial pairing between the two devices?

Reference: Mike Ryan, "Bluetooth: With Low Energy comes Low Security", WOOT 2013. https://www.usenix.org/conference/woot13/workshop-program/presentation/Ryan

D.W.
  • 98,420
  • 30
  • 267
  • 572

1 Answers1

16

The attack actually works. I've been playing with the Ubertooth One that I acquired at DEF CON five years ago and have tested it against a variety of IoT devices that implement the BLE standard. Mike Ryan's paper is correct.

From the book, "Abusing the Internet of Things", the author discusses Mike Ryan's work and the implementation with the Ubertooth One.

ubertooth-btle -f -c ble.pcap

The author also discusses using the LightBlue iOS app for further troubleshooting, as it can copy Bluetooth devices and emulate them. It takes some work with BLE because it uses many channels, so turning the interfaces on and off during the network capture assessment is highly recommended.

Standard BLE encrypted data uses a key-exchange protocol by selecting an AES-based temporary key (TK). Mike Ryan released the crackle tool to brute force this key.

crackle -i ble.pcap -o decrypted-ble.pcap

This technique is not effective against OOB (128-bit optional key also defined by BLE) mode, however, as seen on the ubertooth mailing list, the development team is working to gather samples and troubleshoot the possibilities of breaking OOB mode.

A well-known blog on payment technologies and associated infrastructure has also been speculating on the demise of Bluetooth security, including some comments about breaking BLE OOB mode. 12/29/15 update: There is more discussion about BT 2.1. Also came across btproxy, which will hopefully support BTLE soon. Another tutorial I came across is entitled Sniffing and Cracking Bluetooth with the UbertoothOne.

However, (as seen in the book, "Hacking Exposed Wireless, 3rd Edition") the idea of repairing Bluetooth was first publicized in the paper “Cracking the Bluetooth PIN” by Yaniv Shaked and Avishai Wool (http://www.eng.tau.ac.il/~yash/shaked-wool-mobisys05). An adversary can use a “repairing attack” to manipulate the stored pairing status between two devices by impersonating the BD_ADDR of one of the two devices.

The tool bdaddr is the primary implementation of this technique.

gcc -obdaddr -lbluetooth bdaddr.c
hciconfig hci0
sudo bdaddr -i hci0 <new bdaddr>
(asks to reset device now)
sudo bccmd -d hci0 warmreset
(check that it changed)
hciconfig hci0
sudo hcitool cc <bdaddr of target to repair to>
sudo hcitool enc <bdaddr target again> enable

To return back to a clean slate

sudo bccmd -d hci0 coldreset
hciconfig hci0
atdre
  • 18,885
  • 6
  • 58
  • 107