Before getting into details on the security features
and architecture of Bluetooth, it’s important to revisit and discuss
some of the key characteristics of the technology and its intended user
base. Bluetooth is designed to provide cable-free operation and
interaction among a variety of devices, many of which tend to be
consumer electronic devices. Because of the variety of devices in use
and the situations for which Bluetooth is intended, no assumptions can
be made about either the Bluetooth device or the technical
sophistication of the device’s user. Bluetooth must be usable by novice
consumers and on devices with limited or no visual display or input
capabilities (headsets, keyboards, and so on). So, a key factor that
complicates Bluetooth security is that many usage scenarios involve
nontechnical users as well as devices that are incapable of the security
mechanisms a developer may wish to use.
It is important that these
issues remain at the top of mind as mobile application developers plan
the design of their applications, as well as whether and how these
applications will leverage or rely on Bluetooth security.
Pairing
Pairing,
the process whereby two Bluetooth devices establish a link and agree to
communicate, is critical to the overall security architecture of
Bluetooth and is tightly integrated with other Bluetooth security
features. During the pairing process, the communicating devices agree on
and generate keys that are used to identify and reference relationships
with other devices. In addition to being used for these identification
purposes, these keys are also used to generate additional keys used for
both device authentication and communication encryption.
Device Pairing Prior to Bluetooth v2.1 + EDR
In versions prior to
Bluetooth v2.1 + EDR (released in July 2007), pairing between devices is
accomplished through the entry of a PIN or passkey with a maximum
length of 128 bits. There are two types of such passkeys: variable
passkeys, which can be chosen at the time of pairing via some input
mechanism, and fixed passkeys, which are predetermined (Bluetooth Security,
p. 29). The type of passkey used is typically determined by a device’s
input and display capabilities (for example, a Bluetooth-enabled phone
with keyboard input and visual display may use a variable passkey,
whereas a Bluetooth-enabled mouse may use a fixed passkey because it has
neither input nor display capabilities to enter or verify a passkey).
Secure Simple Pairing with Bluetooth v2.1 + EDR
In Bluetooth v2.1 + EDR,
a new method of pairing called Secure Simple Pairing was introduced.
The older method of pairing is supported when connecting to legacy
devices, but the use of Secure Simple Pairing is mandated for
communications between Bluetooth v2.1 + EDR devices.
From
a user’s perspective, Secure Simple Pairing is meant to provide
additional flexibility and ease of use when pairing compatible devices
that have far-ranging display and input capabilities. However, from a
security perspective, Secure Simple Pairing also improves security
through the introduction of Elliptic Curve Diffie-Hellman (ECDH) for key
exchange and link key generation.
Rather than relying on
simple PIN/passkey entry and verification, Secure Simple Pairing offers
four different means for pairing compatible devices (known as
association models):
Note
For more information on Secure Simple Pairing, see the “Bluetooth Simple Pairing Whitepaper” at the Bluetooth website.
Numeric Comparison
This association model is designed for situations where both
communicating devices can display a six-digit number and have inputs
that allow the user to enter “yes” or “no.” A six-digit number from
000000 to 999999 is shown on both displays, and the user is prompted to
respond whether the numbers are the same on both devices. If “yes” is
entered on both devices, then the devices are paired successfully. Note
that a primary difference between Numeric Comparison and the PIN model
used in legacy pairing is the displayed number. In Numeric Comparison,
this value is not used as an input to further key generation, so an
attacker who can observe the displayed number cannot use it to calculate
other keys. With the legacy PIN model, the PIN entered does factor into
the generation of encryption keys, which makes PIN disclosure a real
risk to the security of the communications.
Just Works
This association model is intended for scenarios involving at least one
device without the ability to display a six-digit number or to enter
numbers. This mode uses the same key agreement protocol as Numeric
Comparison (with protections against passive eavesdropping), but the
actual method whereby the user accepts the Bluetooth connection is
determined by the product manufacturer. This association model does not
provide protection against man-in-the-middle attacks.
Out of Band
This association model is intended for scenarios involving an
out-of-band (OOB) mechanism (that is, non-Bluetooth) that is used to
both discover the Bluetooth devices and exchange information during the
pairing process. The actual OOB mechanism will vary, but a commonly
specified use case involving a Near Field Communication (NFC) OOB
mechanism is device “tapping.” This use case involves physically
touching two devices together.
Subsequent
to the devices being tapped together, the user is asked to confirm
whether the pairing request initiated by the tapping should be accepted.
To provide security for the pairing process, the OOB mechanism used
should provide privacy protections, including resistance to
man-in-the-middle attacks.
Passkey Entry
This association model is intended primarily for situations involving
one device with input capabilities but no display capabilities while the
other device has display capabilities. The device with a display
presents a six-digit number from 000000 to 999999 on the display. The
user then enters this number on the device with the input capability. If
the values match, then the devices are paired successfully.
Traditional Security Services in Bluetooth
Developers and
implementers are accustomed to having access to certain basic security
services in the technologies they employ. Such basic security services
include authentication, authorization, integrity, and confidentiality,
among others. The availability of these services, the soundness of their
implementations, and the extent to which the developer or implementer
can customize these services for their unique requirements all help
reveal the security capabilities of a given technology.
The Bluetooth specifications
include a limited set of these basic security services, and as such, the
level of security that can be implemented with native Bluetooth
features is limited. The following security services are provided by the
Bluetooth specification:
Authentication The ability to identify devices before and during connection and communication is provided by Bluetooth.
Authorization The ability to provide selected access to resources based on permissions is provided by Bluetooth.
Confidentiality The ability to protect communications during transmission over the network is provided by Bluetooth.
Noticeably absent
are integrity protections and nonrepudiation services. In addition,
native Bluetooth security services are provided at the device-to-device
level; for instance, Bluetooth’s authentication service only
authenticates a Bluetooth device. There is no provision for user-level
authentication. Of course, this does not mean that user authentication
services cannot be provided over a Bluetooth connection; instead, the
developer must implement this service by other means at a different
level in the communication stack. These limitations are important to
consider as mobile developers architect their applications and consider
which security options to employ.
Authentication
Bluetooth
authentication is the process whereby one device verifies the identity
of another device. Bluetooth authentication is a one-way process,
meaning that during any given authentication procedure, only one
device’s identity is verified. In use cases requiring mutual
authentication, this one-way process is simply repeated with the two
devices’ roles reversed.
Bluetooth authentication involves the claimant device, which is the device that will have its identify verified by the authentication process, and the verifier
device, which is the device that will verify the claimant’s identity.
To perform this verification, a traditional challenge-response mechanism
is used. The verifier sends a random number (the “challenge”) to the
claimant. Upon receipt, the claimant generates a response to this
challenge and returns the response to the verifier. This response is
generated based on a function involving the random number, the
claimant’s Bluetooth device address, and a secret key that was generated
during device pairing (see page 240 of Core Specification v2.1 + EDR on
the Bluetooth website).
The Bluetooth authentication
mechanism has a simple protection to prevent repeated attacks in a
limited timeframe. When an authentication attempt fails, the verifier
will delay its next attempt to authenticate the claimant. This delay
interval will be increased exponentially for each subsequent failed
attempt (see page 880 of Core Specification v2.1 + EDR on the Bluetooth
website).
Authorization
Authorization in Bluetooth
allows for decision making about resource access and connection
configuration (that is, authentication and encryption requirements) to
be made based on the permissions granted a given Bluetooth device or
service. Two of the primary means of implementing authorization in
Bluetooth are device trust levels and service security levels.
Device Trust Levels
Bluetooth devices can have one
of two trust levels in relation to other Bluetooth devices: trusted or
untrusted (refer to the “Wireless Security” page at the Bluetooth
website).
Trusted devices have previously been paired with the device, and will have full access to services on the Bluetooth device.
Untrusted
devices have not previously been paired with the device (or the
relationship has been otherwise removed), and will have restricted
access to services.
Service Security Levels
Bluetooth services (applications that use Bluetooth) have one of three security levels:
Service Level 1
These services require device authentication and authorization. Trusted
devices will be granted automatic access to these services. Manual
authentication and authorization will be required before untrusted
devices are granted access to these services.
Service Level 2 These services require authentication, but do not require authorization.
Service Level 3 These services have no security and are open to all devices.
Although Bluetooth’s notions
of device trust and service security levels are quite simple, the
architecture of Bluetooth does provide for the implementation of more
complex security and authorization policies.
Confidentiality
Confidentiality is
important for private communications over wireless links because the
nature of wireless networking leaves the communication between nodes
subject to eavesdropping by unauthorized parties. Confidentiality of
network communications in Bluetooth is provided through the use of
encryption, with the use of encryption being optional and determined by
the selection of one of three encryption modes during communication.
The Bluetooth
specification outlines three specific encryption modes. These modes are
intended to limit encryption key ambiguity and speed processing of
encrypted data in both point-to-point and broadcast traffic situations.
Bluetooth uses E0, a stream cipher, as the basis for the encryption processing associated with these encryption modes. The defined modes include:
Encryption Mode 1 No encryption. All traffic is unencrypted when Encryption Mode 1 is used.
Encryption Mode 2 Traffic between individual endpoints (non-broadcast) is encrypted with individual link keys. Broadcast traffic is unencrypted.
Encryption Mode 3
Both broadcast and point-to-point traffic is encrypted with the same
encryption key (the master link key). In this mode, all traffic is readable
by all nodes in the piconet (and remains encrypted to outside
observers). Note that the notion of privacy in Encryption Mode 3 is
predicated on the idea that all nodes in the piconet are trusted because
all nodes will have access to the encrypted data.
Of importance to note is that
when encryption is used in Bluetooth, not all parts of the Bluetooth
packet are encrypted. Because all members of a piconet must be able to
determine whether the packet is meant for them, the header of the
message must be unencrypted. And, a part of the packet called the access code must be available to all devices to allow the radio signal to be acquired properly (Bluetooth Security, p. 34).
Bluetooth Security Modes
The Bluetooth Generic
Access Profile details the procedures associated with the discovery of
Bluetooth devices and specifications related to device connection (Bluetooth Security,
p. 38). In addition to these discovery and connection details, the
Generic Access Profile also defines four security modes in which
connectable Bluetooth devices may operate. The use of these various
security modes controls how Bluetooth’s basic security services are
employed for any given connection:
Security Mode 1
In Security Mode 1, no security procedures are used. There is no
encryption or authentication, and devices in this mode will not use any
controls to prevent other devices from establishing connections.
Security Mode 2
In Security Mode 2, security is implemented after the Bluetooth link is
established. In this mode, security is enforced at the service level,
so it is left to the Bluetooth application or service to request
security. This flexibility allows for granular and specific security
policies to be implemented that apply security selectively based on the
services and applications requested. This, of course, also opens the
door for flaws in the implementation of these security policies that
could leave the device and data at risk.
Security Mode 3
In Security Mode 3, security is implemented when the Bluetooth link is
established. This is an “always-on” policy that provides security for
all uses and reduces the risks associated with faulty security policies
and implementations. However, this will also increase inconvenience and
decrease flexibility because devices will be unable to connect without
authentication (Bluetooth Security, p. 39).
Security Mode 4
Security Mode 4 was defined in the v2.1 + EDR specification, and it’s
required between v2.1 + EDR devices (essentially making Modes 1 through
3 legacy modes once v2.1 + EDR becomes widespread). Like Security Mode
2, security in Security Mode 4 is implemented after link setup. However,
service security requirements must be identified as one of the
following:
Authenticated link key required
Unauthenticated link key required
No security required
Security “Non-Features”
In addition to reviewing the
actual security features provided by Bluetooth, it is useful to
acknowledge and refute two characteristics of Bluetooth communications
that may be claimed as security features but do not provide any real
protection:
Frequency hopping
The frequency-hopping scheme that Bluetooth uses does not provide any
protection against eavesdropping. There is no secret used to create the
sequence of channels, and only 79 channels are used. Thus, using a
series of receivers to monitor all channels would make an offline attack
possible (Bluetooth Security, p. 31).
Device proximity
The limited range of Bluetooth radios (up to approximately 330 feet
with Class 1 radios) cannot be reliably used as a security feature. The
supposed protection provided by limited signal strength can and has been
defeated by attackers’ high gain antennas.
