1
Bluetooth security
As Bluetooth is a wireless technology, data is transmitted over air and as such easily to be
intercepted. The Bluetooth specification therefore gives the architecture of a build-in
security to discourage eavesdropping and attempts to falsify the data, which is the so
called spoofing.
The link level security enforces authentication and encryption to prevent unwanted
devices to access the network and to protect privacy. Additionally, the frequency hopping
and the limited range of the most used Bluetooth devices makes eavesdropping more
difficult.
Each Bluetooth device has an individual Bluetooth address. Furthermore, to ensure
security feature in link level, there are two secret keys and a random number for each
device, while the random number is different for new connections.
Entities and size:

Bluetooth address – BT_ADDR
48 bits

Private user key, authentication
128 bits

Private user key, encryption
8 – 128 bits

Random Number – RAND
128 bits
The three basic security services defined by the Bluetooth specification are:

Authentication

Confidentiality Preventing private information from passive attacks
Identifying the communicating devices
2
Makes sure only authorized devices are allowed to
view data

Authorization Resource control, only authorized devices can use Services
The Frequency Hopping
With the frequency hopping the Bluetooth technology itself contains a - albeit insufficient
– security feature. Designed to avoid interferences with other devices likewise using the
free ISM band, frequency hopping makes it more difficult to listen to a Bluetooth
connection.
There are two variations of this technology, the older random frequency hopping and –
implemented in version 1.2 of the Bluetooth specification – the adaptive frequency
hopping.
How frequency hopping works
The first generation of Bluetooth devices, using the random frequency hopping, switch
continuously between 79 of the disposal channels. Whenever another wireless device
enters the environment, this technology will cause occasional interferences. Figure 5
illustrates the problem between a Bluetooth device and a Wireless LAN:
3
GHz
2,180
2,402
Time
= Bluetooth
= WLAN
Figure 4:
Collisions resulting from random frequency hopping
In the pictured case, the Bluetooth advice is not able to avoid these collisions.
In contrast to this, the adapted frequency hopping is able to accommodate to its
environment by detecting fixed sources of interference and drop them from the list of free
channels. This of course narrows the number of available channels for the Bluetooth
device itself. The Bluetooth specification requires at least a set of 20 channels.
Figure 2 shows the same environment as Figure 1, but now the device uses adaptive
frequency hopping:
4
GHz
2,180
2,402
Time
= Bluetooth
= WLAN
Figure 5:
Collisions avoided using adaptive frequency hopping
The hop channel selection function is a mapping algorithm following different sequences
depending on the link control state. The particular phase is chosen depending on parts of
the Bluetooth address and the Bluetooth clock. The stream of the generated channel
numbers is given to the RF subsystem and finally programmed to the channel synthesizer.
Security Modes
The Bluetooth specification describes three different modes of security. Each device
operates in only one of these modes at a time. The security modes are:
Security mode 1:
No security mode
5
Security mode 2:
Service level enforced security mode
Security mode 3:
Link level enforced security mode
During an Initialization process, when Bluetooth devices try to connect with each other,
one of these modes is selected.
Random number generator
Each Bluetooth device has a random number generator, used for many purposes within
security sector. The ideal generator would use random physical processes, such as
thermal noise generated by semiconductors.
Practically, software solutions are used for random number generating.
The process shall secure that it is highly improbable that the same number is generated
twice during the lifetime. Also, the generated number shall of course not be predictable.
Secret Keys and PINS:
If the encryption security feature is requested, the communicating master and slave
device must share a secret key. This key is not transmitted on air, so no other device can
intercept this key. This secret key can be built in three different ways:

As a fixed key build by the manufacturer, for example for a headset
device.

A variable key derived from the Personal Identification Number PIN, for
example used in hotels with frequent changing users and a new PIN for
each new user.
6

A link key made by the pairing process.
For the key generating and also from procedures that require authentication, the Personal
Identification Number PIN is used. There are two different types of PIN numbers, the
fixed PIN which is given by the producer to devices without any interface for users, such
as headsets for example. Using other devices like a mobile phone, a PDA or a Laptop, the
user is able to select a PIN. This is of course more secure than the fixed numbers, the
selected PIN can be changed and vary in length. The length of a PIN is another detail that
has influence on security. A short PIN, typically four decimal digits as people are used to
have for many other concerns, is not as secure as a PIN that uses the appropriated 16
octets.
The Encryption
Bluetooth devices are able to send and receive encrypted data to protect it from unmeant
third parties. Before encrypted data can be exchanged, the devices have to perform some
more steps. These steps can be processed after the units have undergone the
authentication procedure and agreed on a common link key.
Now the devices have to execute the following:

Key size negotiation

Encryption mode negotiation

Starting encryption
The payload of the data packages is encrypted by the cipher stream E0, which is resynchronized for every payload. The header of the data packages is not encrypted.
E0 consists mainly of three parts; one performing the initialization which includes the
generation of the encryption key, the second is responsible for the generation of the
key stream bits and the last for encryption and decryption itself.
7
The second part is the most important one, as it is also used for the initialization process.
Key stream bits are derived from a summation stream cipher generator attributable to
Massey and Rueppel. The process is strong compared to other known methods.
The first part consists of combining the input bits in an advisable order and then shifts
them into four Linear Feedback Shift Registers, which are used in the key stream
generator.
Ciphering key
BT_ADDR
BT_CLK
Random number
Payload key generator
Key stream generator
Plain text
Cipher text
+
Cipher text
Figure 6:
Plain text
General encryption process
Encryption modes:
The encryption mode generally depends on the link key used by the slave. If the slave is
using a semi-permanent link key like a combination or a unit key, it is possible to encrypt
point to point data but not broadcast data. Figure 4 shows the possible encryption modes
for slaves using a semi-permanent key.
8
Otherwise, if the slave has received a master key, all the units in the piconet which are
involved in the particular connection use this master key. So, it is possible to encrypt
broadcast traffic and individual traffic as well, Figure 5.
Mode 1
Mode 2
Broadcast
Individual
Traffic
Traffic
No
No
Encryption
Encryption
No
Encryption
Encryption
Figure 4:
Mode 1
Mode 2
Modes using a semi-permanent link key
Broadcast
Individual
Traffic
Traffic
No
No
Encryption
Encryption
No
Encryption
Encryption
Mode 3
Encryption
Encryption
Figure 7: Modes using a master key
Encryption key size:
9
Bluetooth devices do not necessarily use a full 128 bit encryption key. Because of that, it
is important that the corresponding master and slave devices agree to a key size they use
for encryption. For that, the master device sends a key size request to the slave. If the
slave can handle this size, it sends a key size accept to the master. Otherwise, the slave
sends a message telling the master device that the key size is too large. This process is
repeated until an appropriate key size is found.
Furthermore, the key size can be dedicated by the application the devices run. If the slave
is not able to handle the key size given by the application, encryption is not possible and
the master device aborts the negotiation.
Starting encryption:
Once the encryption mode and key length is found, encryption can be switched on or off.
Starting and ending encryption is a three step process. During this process, higher layer
data traffic is stopped to prevent reception of corrupt data.
The three steps of starting the encryption are the following:

The master device is configured to transmit unencrypted data and to
receive encrypted data packages.

The slave device is configured to receive and transmit encrypted data.

The master device is configured to receive and transmit encrypted data.
Stopping the encryption is similar.
If the mode or key or random number of encryption is changed, it is necessary to stop
encryption, configure the new parameters and start encryption again.
10
Encryption concept:
For the encryption routine, the cipher algorithm E0 is used with the data bits before they
are send over air. Each data packages are ciphered separately. E0 uses the Master
Bluetooth address, 26 bits of the master clock and the encryption key KC as inputs. The
E0 algorithm computes the encryption key into another key denoted K’C, which size is a
factory preset between 8 and 128 bits.
The master clock is the only input that changes during the process; it is incremented for
each new slot. As the E0 algorithm is started for each new packet, there is a new cipher
stream computed in every turn. An exceptional case is a multi slot package, these are enor decrypted with the same cipher key.
The result of the E0 algorithm is the cipher key Kcipher, and the data stream bits are added
using an XOR operation with this cipher key in both directions, also for encryption as
well as decryption. Figure 6 shows the process.
Master Device
BT_ADDR
BT_CLK
Slave Device
Kc
Eo algorithm
Eo algorithm
Kcipher
Kcipher
Ciphertext
Packet in
Packet out
XOR
XOR
XOR
Packet out
XOR
Packet in
11
Figure 8: Encryption concept
Pairing and Bonding:
One of the procedures involved in starting up a connection between Bluetooth devices
base on a common link key is called bonding. Two devices sharing a link key are called
bonded. Bonding includes creating a link specifically for purpose of creating and
exchanging a common link key. For Bonding, the Link Manager verifies that units share
a secret key with the so called Authentication procedure. After that, the Link Manager
creates and exchanges a link key.
The link level process of the link key generating and the authentication procedure is
called Pairing.
Link keys can also be created by higher layer exchange methods, and import them to the
Bluetooth device.
Authentication:
The Authentication procedure is used to make sure the devices use the same secret key.
This can take place at any time of a communication; it depends on the used application.
For example, if a device starts an application that requires authentication, the
authentication procedure is started at this time even if a connection is established.
If an Authentication is failed, this can have different reasons:

The connection does not exist

The Authentication failed
12

One of the Bluetooth devices does not support Authentication

The device does not have a key to authenticate with

The command is not allowed
The steps of an authentication procedure are the following:

An 48-bit address (BT_ADDR) is transmitted from the claimant to the
verifier

The verifier transmits a 128-bit random number to the claimant
(AU_RAND)

The verifier and the claimant create a 32-bit authentication response with
the inputs Bluetooth address, the link key and the random number using
the E1 algorithm.

The created response, SRES, is transmitted from the claimant to the
verifier.

Now the verifier compares the SRES with the response the verifier
computed itself

If the values are equal, the authentication is completed and the verifier will
continue connection establishment.
As a side product, a successful authentication procedure also computes an Authenticated
Ciphering Offset (ACO) which can be used to generate the encryption key.
13
Device 1
Device 2
Verifier
Claimant
Random Number
Generator
BT_ADDR
AU_RAND
Link
key
Link
key
E1 algorithm
SRES
E1 algorithm
SRES
ACO
ACO
=?
Figure 8: Authentication procedure sequence
Trusted and untrusted devices
A so called trusted device has a permanent relationship to the service offering device
(paired devices) and enjoys unrestricted access to all offered services.
As an opposite to this, untrusted devices do not have a fixed relationship to the offering
device and as a result of that they have no access to the services.
The three levels of trust can be described like follows:

Unknown device: No security information is stored about this device, so this
device is untrusted and service access may be restricted
14

Known untrusted device: The device is known by a pairing or bonding
procedure, but is marked as untrusted in the database and therewith service
access may be restricted.

Trusted devices: These devices are known by pairing or bonding and marked
as trusted in the database and can be given unrestricted access to services.
Devices may have access to specific services, and are restricted by others. These different
levels of trust can be implemented by the service and are also stored in the database. For
example, some users may be able to look at a calendar but on the other hand only the
devices of the owner are able to change the information given there.
Note that a Bluetooth security does not set users to trusted or untrusted state, but only
devices. As the PIN number is only needed once at the beginning of two devices
communicating (if they want to share a secret key), it is possible to use a different PIN
next time. The security architecture of course allows applications to implement their own
security features.
Authentication, authorisation and encryption features are set independent, and as a result
of this there are three security levels of services:

Open service: all devices have full access to this service without any
security requirements

Service
requires
authentication:
Devices
that
go
through
the
authentication procedure (i.e. share a secret key with the service providing
device) have access to the services

Service requires authentication and authorization: Trusted devices may
have automatic access; others have to go through authorization manually.
15
Security Manager:
The security manager is the instance that handles the database containing the knowledge
about trusted or untrusted devices as well as the security level of services. Different
protocols may interact with the security manager to query information from the database.
The L2CAP for example enforces security for cordless telephony and the RFCOMM
enforces security for dial-up networking. The security manager handles the transactions
between different layers, all exchanged data goes through the manager.
Security policies are enforced by exchanging these queries with the manager:

Applications want information about the access of devices to the services

HCI needs information whether authentication and/or encryption should be
involved

The user interface is queried by the security manager to get the PIN and
also to authorize new devices

The protocol layers query the security manager with access requests
Applications which are unable to call the security manager on their own use an “adapter”
application that connects with the security manager. If no information is found in the
database, the default settings (according to the white paper) should be:

Incoming connections: require authentication and authorization

Outgoing connections: require authentication
The Bluetooth security does not replace the existing network security features. The
Bluetooth security architecture is an open configuration that allows applications to set
their own security features additionally. Extremely sensitive requirements such as ecommerce use additional application level security.
16
User Interface
Application Application Application
L2CAP
Host Controller Interface
Link Manager / Link Controller
= Registration
= Query
Figure 10: Security architecture
Security Manager
RFCOMM
General
Management
Entity
Service
Database
Device
Database