Has Bluetooth Become Secure?

Bluetooth has a bad reputation when it comes to security. Many vulnerabilities have been found over the years in the technology, and many successful attacks have been demonstrated against it. But the Bluetooth specification has also changed much over the years, and each revision of the specification has made substantial changes to the Bluetooth security protocols. Whether the latest protocols are secure is a question open to debate. This question is especially important when Bluetooth is used in emerging medical and Internet-of-Things applications where security flaws have safety implications. But it has also come up recently in the context of the Derived Credentials being standardized by NIST for authentication of Federal employees who use mobile devices.

(This is a continuation of the last two posts, which reported on the recent NIST Workshop on PIV-Related Special Publications. It is also the last of a seven-part series of posts discussing the public comments on Draft SP 800-157: Guidelines for Derived Personal Identity Verification (PIV) Credentials, and the final version of the publication. Links to all the posts in the series can be found here.)

Before tackling the question of whether Bluetooth is secure today, let me explain how it came up in the context of PIV Derived Credentials. SP 800-157 permits the storage of derived credentials in embedded hardware or software tokens, or in removable tokens. Removable tokens include USB tokens, microSD cards, and UICC cards. The companion document Draft NISTIR 7981 mentions the possibility of accessing a PIV card from a mobile device using a card reader that communicates with the device via Bluetooth, and both NISTIR 7981 and SP 800-157 allow a mobile device to access a contactless PIV card via NFC. But neither NISTIR 7981 nor SP 800-157 considered the option of storing derived credentials in hardware tokens accessed from a mobile device via Bluetooth. Many comments asked for such an option, and some comments asserted that, although Bluetooth may have been insecure in the past, Bluetooth LE provides high security today.

In response to all the comments that referred to Bluetooth, NIST asked William Burr, a retired NIST employee who now has his own consultancy, to make a presentation at the workshop on Future Tokens for Derived PIV Credentials (Future Revision of SP 800-157), where he discussed among other things the security of Bluetooth. (The video of his talk can be found at the end of the Day-2-Part-3 portion of the webcast.)

Early history of Bluetooth security

Like many other secure channel protocols, Bluetooth includes (in first approximation) an initial phase (known as pairing in Bluetooth) where two devices establish shared keys, followed by a traffic protection phase where data is encrypted and authenticated with those shared keys.

Before version 2.1, the pairing phase was utterly insecure. A passive eavesdropper was able to obtain enough information to test guesses of a pairing PIN offline, which made it trivial to crack the PIN and then use the cracked PIN to compute the traffic protection keys.

In version 2.1, Bluetooth introduced Secure Simple Pairing, which comes in four flavors known as “Just Works“, “Numeric Comparison“, “Passkey Entry” and “Out-Of-Band“. Secure simple pairing uses Elliptic Curve Diffie-Hellman (ECDH) for establishment of the session protection keys. This prevents a passive eavesdropper from obtaining the traffic protection keys. Furthermore, the Numeric Comparison flavor was proved by Lindell to be secure against an active adversary.

However, version 2.1 kept the same traffic encryption algorithm used in previous versions, known as E0, which was shown by Lu, Meier and Vaudenay to be insecure. Dr. Burr referred to this in his talk, noting that E0 is not a NIST-approved algorithm and is not likely to be approved in the future.

Version 4.0 introduced Bluetooth LE (Bluetooth Low Energy, now marketed as Bluetooth Smart), with completely different security protocols. Traffic encryption used AES-CCM, but pairing reverted to not using ECDH, making the PIN as well as the traffic encryption keys again vulnerable to a passive eavesdropper. Dr. Burr noted this, then considered the option of performing the pairing in a secure location to protect the keys. But he pointed out that an attack described by Ryan (see Section 6.1 of Ryan’s WOOT’13 paper) allows an adversary to force a re-pairing when the devices are outside the secure location.

Current state of Bluetooth security

But Dr. Burr did not discuss the latest Bluetooth specifications, which again have made substantial changes to the Bluetooth security protocols. Version 4.1, released in December 2013, added a “Secure Connections” feature to classical (non-LE) Bluetooth, and version 4.2, released in December 2014, added the same Secure Connections feature to Bluetooth LE.

Secure Connections feature AES-CCM for traffic encryption, which was included in LE but not in classical Bluetooth as of version 4.0. And they use Secure Simple Pairing, which was included in classical Bluetooth but not in LE as of version 4.0. So it would seem that, with secure connections in both classical Bluetooth and Bluetooth LE, Bluetooth should finally be secure. Unfortunately, that is not the case.

The lack of security is related to the four flavors of Secure Simple Pairing. We saw above that Numeric Comparison has been proved secure; but it can only be used for pairing two devices that can both display 6-digit numbers; the user checks the numbers and allows the pairing if they are the same. Many Bluetooth devices do not have a display and cannot use Numeric Comparison. Just Works is not secure against active attack. Out-Of-Band, as it name indicates, requires an out-of-band channel such as an NFC connection for protection against man-in-the-middle attacks. It is not widely implemented, and attacks against it have been reported.

That leaves Passkey Entry, where access to one of the devices is protected with a 6-digit PIN (the passkey) while the other device has a keyboard or keypad where the user can enter the passkey.

The passkey-protected device may generate a fresh random passkey before each pairing and display it to the user, in which case Passkey Entry is secure. But if the passkey-protected device does not have a display, as is often the case, the passkey has to be built into the device by the manufacturer and communicated to the user, e.g. in the device documentation. In that case, even if each device has a different random passkey, Passkey Entry is not secure. Lindell, the same researcher who proved Numeric Comparison secure, found two very easy attacks against the protocol. In one of them, the attacker learns the passkey in less than a second by eavesdropping on a pairing session, without even having to mount a brute-force guessing attack against the passkey. In the other, the attacker learns the passkey after making about ten pairing attempts against the passkey-protected device. In both attacks, once the attacker has learned the passkey, he or she can pair at will with the protected device. The attacks are described in an easy-to-read 2008 Blackhat paper

Lindell recommended making Passkey Entry secure by using the password-authenticated key exchange method of Katz, Ostrovsky and Yung instead of the flawed ad-hoc method of Bluetooth version 2.1. Unfortunately, the Passkey Entry protocol found in version 4.2 (see Section H.7.2.3, page 1346) is still the same flawed one.

So the answer to the question in the title of this post is: No, Bluetooth is still not secure.

See also:

• Part 1: NIST Fails to Address Concerns on Derived Credentials
• Part 2: NIST Omits Encryption Requirement for Derived Credentials
• Part 3: Biometrics in PIV Cards
• Part 4: Biometrics and Derived Credentials
• Part 5: Highlights of the NIST Worshop on PIV-Related Special Publications
• Part 6: NIST Looks at EMV to Speed up Physical Access with PIV Contactless Cards
• Pomcor’s Derived Credentials page