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