Full text of DOI:10.1016/S1363-4127(00)03005-3

Information Security Technical Report, Vol 5, No. 3 (2000) 32-43
Bluetooth Security — An Overview
Joakim Persson and Ben Smeets, Ericsson Mobile
Communications AB, Ericsson Research
existing WLAN technologies) has created a
demand for a new cheap radio-based solution.
This is where Bluetooth enters the picture.
Background
Early during the development of the
Bluetooth specification it became clear that the
requirements imposed by modern
applications are not just restricted to having a
good radio interface design, but also to having
support for security. Before we elaborate on
security in Bluetooth, we will give a short
overview of the Bluetooth system.
Over the last five years, the market for
portable devices has more or less exploded.
Nowadays, a laptop or a notebook computer
is not only a ‘necessary’ accessory for almost
every businessperson on the move, but it is
also becoming a preferred alternative over its
stationary companion for many new
computer buyers. The classic time managers
have to a large extent been replaced by
electronic PDAs of different kinds. Moreover,
with the tremendous increase in use of cellular
phones all over the world, at least one
portable device is now present in the daily life
of most people. Up till now, all these devices
have worked virtually completely isolated
from each other. The reason is partly that
interconnecting portable devices requires
different cabling equipment; most
manufacturers have chosen proprietary
connectors to be able to promote and sell their
own products. Clearly, having to carry a lot of
different cables is not very convenient.
What is Bluetooth?
Bluetooth is a short-range radio link intended
to replace cables connecting portable and/or
fixed electronic devices. Its main features are
robustness, low complexity, low power
consumption and low cost. The Bluetooth
radio system operates in the globally available
unlicensed Industrial, Scientific and Medical
(ISM) band at 2.4 GHz and, depending on the
power class of the transceiver, provides for
radio connections with a maximal range of
between 10 and 100 meters. A Frequency Hop
Spread Spectrum (FHSS) technique with
narrowband (1 MHz) transmission is applied
to combat interference and fading. The hops
are spread over the entire available band of 79
MHz using pseudo-random sequences. All
Bluetooth units following a particular
hopping sequence are said to listen to the
same channel.
The more we use these devices, the more it
becomes clear that many useful applications
require seamless communication with clients
and/or servers running on devices physically
separated from each other. The distance might
in fact be quite small, in the region of a few
metres or less, but nevertheless, smooth
operation requires the means for
communication with remote devices. Today
there is IrDA, the infrared standard, and there
are different kinds of wireless local area
networks (WLAN). However, the drawback of
these (line of sight requirement for IrDA and
quite expensive and complex solutions for
Bluetooth uses binary GFSK modulation with
a symbol rate of 1 Msymb/s. A slotted channel
structure is applied with a nominal slot length
of 625 µs. This corresponds to 1600 hops per
second, a fairly high number compared to the
wireless LANs that exist today and operate in
the same ISM band (c.f., IEEE 802.11 that uses
50 hops per second). Time-division duplex
32
0167-4048/00/$20.00 © 2000, Elsevier Science Ltd

Bluetooth Security — An Overview
(TDD) is exploited for dividing the common
channel in a master-to-slave and a slave-to-
master direction. The Bluetooth protocol uses
a combination of circuit and packet switching,
allowing for a mixture of simultaneous
synchronous (voice) and asynchronous (data)
traffic. The data traffic can be symmetric or
asymmetric. The Bluetooth system can, for
Slave A
Slave A
Slave C
Slave A
Slave C
Master X
Slave B
(a)
Slave B
Slave B
Slave Y
(b)
(c)
example,
support
an
asymmetric
Figure 1: a) Single slave operation, b) a multi-slave
operation and c) a scatternet with inter-piconet
operation.
asynchronous connection at 723.2 kb per
second (user data rate) in one direction with
57.6 kb per second in the return direction, or a
symmetric asynchronous connection at 433.9
kb per second in both directions.
practical reasons, the number of parked slaves
will not be more than 2551. A parked slave
must be un-parked before it can be active on
the channel. This operation may require
parking of an existing active slave first since
there is only room for seven active slaves.
The Bluetooth system provides point-to-point
(connecting only two Bluetooth units) as well
as point-to-multipoint connections. In the
point-to-multipoint connection the channel is
shared among several Bluetooth units. Two or
more units sharing the same channel form a
piconet. In each piconet one Bluetooth unit is
given the special task of being the master,
whereas the other unit(s) act as slave(s). The
hopping sequence used in a piconet is
determined by the address and clock of the
master device. The underlying network
topology is a star formed with the master in
the centre. The master addresses the slaves
through a polling scheme. No slave can access
the channel unless it has been explicitly
addressed by the master. Thus, there can be no
direct data traffic flowing from one slave to
another in a piconet. When a unit becomes a
member of a piconet it is said that it
commences a session. The session terminates
when the unit disconnects from the piconet.
Finally, two or more piconets with
overlapping coverage areas form a so-called
scatternet. If desired, slaves can participate in a
time-division multiplex fashion in more than
one piconet. Figure 1 illustrates three piconet
operation scenarios; a) single slave operation,
b) a multi-slave operation and c) a scatternet
with inter-piconet operation.
Most of the built-in control intelligence needed
to set-up and administer a link resides in the
baseband Link Controller and Link Manager
(LM) of a Bluetooth unit. In principle, the
baseband can be viewed as consisting of two
separate entities: the physical layer (with RF
modulation, coding, timing etc.) and a state
machine controlling all this. Sometimes the latter
entity is referred to as the Link Controller (LC).
Link manager protocol (LMP) messages are
exchanged in a peer-to-peer fashion. These
messages are transmitted in the payload and are
filtered out and interpreted by the LM and not
propagated to higher layers.
There can be at most eight active Bluetooth
units in one piconet, including the master.
Furthermore, slaves can be locked to the
piconet in a so-called parked state. For
The physical device implementing the lower
parts of the specification is usually a module
residing in a host lacking these Bluetooth
1
In theory the maximum number of simultaneously
parked slaves in a piconet is only limited by the
Bluetooth device address space
Information Security Technical Report, Vol. 5, No. 3
33

Bluetooth Security — An Overview
information regarding the Quality of Service
(QoS) expected between units. All this is the
task of the Logical Link Control and
Adaptation Protocol (L2CAP), which resides
in the host. Figure 2 shows the positioning
of these layers in the Bluetooth protocol
stack.
Bluetooth hosts
L2CAP
L2CAP
HCI driver
HCI driver
HCI
HCI
Why is security needed in Bluetooth?
HCI firmware
HCI firmware
The sheer simplicity of the Bluetooth concept
is enough to generate numerous innovative
applications of quite different kinds. The
range spans from simple point-to-point cable
replacement tasks to advanced ad-hoc
networking. An example of the former is a
wireless headset with a Bluetooth link from
the headset to the cellular phone. Moreover,
printers may be configured with Bluetooth
radios to which any Bluetooth enabled
computer can easily be connected. An
example of an ad-hoc network could be a
meeting room scenario where laptops can
share files, business cards and common
LM
LM
LC
RF
LC
RF
Physical Layer
Bluetooth modules
Figure 2: Lower part of the Bluetooth protocol stack:
the baseband (RF and LC), the LM, the HCI, and
the L2CAP.
resources such as
a
projector for
presentations. Clearly, the security needs for
these and other applications are very
different. A headset user is probably
concerned with the privacy of the voice link
and would like to be assured that only
authorized headsets are able to connect to his
particular mobile phone. In the meeting room
scenario, the file sharing should preferably be
restricted to a specific group created in an ad-
hoc manner; any non-authorized Bluetooth
device outside the room should not be able to
join this group. On the other hand, not all
applications have strict requirements on
security. For instance, a printer located in a
public library may allow access for a very
large group of people that use this facility. A
‘flight information kiosk’ at an airport may
allow unrestricted access to its services for
any Bluetooth device. In the Bluetooth
specification, hooks that make all these
scenarios possible have been included.
capabilities itself (e.g. a laptop computer).
The host interacts with the Bluetooth
module through the Host Controller
Interface (HCI). This interface constitutes a
uniform command method for accessing
Bluetooth hardware capabilities. Typically,
for commands controlling the link it will
involve the LM to exchange LMP messages
with remote Bluetooth devices. Moreover,
the host can read and write chunks of data
through this interface. The higher layer
protocol data packets need to be segmented
into (and reassembled from) the relatively
limited baseband packet sizes that are
passed to and from the LM via the HCI.
Since there is only one physical link per
module, support for multiplexing between
higher layer protocols sharing this link is
also necessary. Furthermore, some services
require the means for exchanging
34
Information Security Technical Report, Vol. 5, No. 3

Bluetooth Security — An Overview
However, for some of them (e.g. file sharing
and creating groups) it is necessary to extend
software within the particular application.
This is in accordance with the general
approach of the specification, viz., the lower
layers provide functional ‘atoms’ on which
higher layers can build more complex
protocols.
confidentiality
mechanisms,
these
authentication mechanisms are also available
in all certified Bluetooth units for immediate
use in all applications. In the next two
sections the authentication and encryption
mechanisms are explained in more detail.
The Bluetooth system uses four different types
of entities to maintain security at the link
layer; a public address that is unique for each
unit, two secret keys, and a random number
which is different for each new transaction.
The four entity types and their sizes are
summarised in Table 1.
The frequency hopping in the Bluetooth
system provides some protection against
casual interception of traffic originating from
other Bluetooth unit pairs. However, it is
obvious that this protection is not sufficient
to guarantee that the traffic of user data
between two Bluetooth units is not accessible
to a malicious eavesdropper who targets the
traffic between users. Especially in systems
that use radio transmission, eavesdroppers
have ample opportunities to make their
actions invisible to the communicating users.
Therefore, the Bluetooth system incorporates
security mechanisms that guarantee
confidentiality of user data. By doing this,
rather than leaving this problem for the users
(or the application) to solve, it is possible to
have confidentiality even in the most
minimal Bluetooth systems that one can
construct. In the Bluetooth system
confidentiality is realized through encryption
of the packets that are exchanged between
two communicating units. For reasons that
will be explained later the encryption
mechanism is linked to another security
mechanism in the Bluetooth system, namely
the authentication mechanism. Encryption by
itself is not sufficient for establishing a secure
connection between two units. In fact, maybe
more important than having the means to
keep data confidential is the need to
guarantee that when a radio connection is
established, users know only intended
devices are talking to each other. For this
reason the Bluetooth system provides
security mechanisms that perform
authentication of the users of units. Like the
Entity
Size
BD_ADDR
48 bits
128 bits
8-128 bits
Private user key, authentication
Private user key, encryption
Configurable length (byte-wise)
RAND
128 bits
Table 1: Entity types used in Bluetooth
authentication and encryption procedures.
In the specification the 48-bit IEEE (public)
address is not a secured entity. The secret keys
are derived during initialization. The
encryption keys are configurable in size for two
reasons. The first reason is the differences in
requirements imposed on the deployment and
usage of cryptographic algorithms with respect
to export regulations and official attitudes
towards privacy in general. The second reason
is to facilitate a standardized upgrade path.
Key management
Key types
The keys for the authentication and
encryption procedures have several functions
Information Security Technical Report, Vol. 5, No. 3
35

Bluetooth Security — An Overview
that support the Bluetooth system in its
various phases and modes of operation. There
is a distinction between the phase where two
units want to communicate without having
had contact before and the phase where this
communication takes place after the units
already have met before. In the former case the
secret keys have to be established for the first
time, while in the latter case the units can use
the secret keys from the previous
communication instance. Clearly these phases
require different procedures for managing the
keys. Moreover the Bluetooth master may
want to broadcast to some of its slaves instead
of communicating with each of them
separately. This also requires some special key
management. The Bluetooth system provides
a handful of key management functions that
support the basic phases and modes of
operation. For convenience, and also for
underlining the importance of the
authentication key, this key will often be
referred to as the link key.
generated. Whereas the combination key KAB
is the result of a key generation process
involving two units (A and B say), the unit key
K is generated, and therefore dependent on, a
siAngle unit (A say). Typically a unit key is
created during an initialization phase and is
very rarely changed. Bluetooth units that have
little memory may prefer the use of unit keys.
Units that require more security may prefer
combination keys.
The master key Kmaster is a temporary key that
will replace the original link key temporarily
when, for example, a master wants to
communicate with more than one slave
simultaneously using the same encryption
key.
Finally, the initialisation key Kinit is used as the
link key during the initialization phase when
no combination or unit keys are present. It is a
temporary link key only used during
initialization. The generation of this
initialization key involves a Personal
Identification Number (PIN) code. This PIN
can be a number provided with the Bluetooth
unit, e.g. when the unit has no Man Machine
Interface (MMI) as in a PSTN plug.
Alternatively, the PIN can be selected
arbitrarily by the user and entered in both
units that want to meet. This can be done
manually using some MMI or this can be done
by the applications that are using the units.
The Bluetooth specification requires that the
value of the PIN can be changed. The length of
the PIN can be up to 16 octets. This allows, for
example, the implementation of an automatic
PIN code exchange through a Diffie-Hellman
key agreement, see [2], rather than through
manual means.
In order to support the different phases and
modes of operation, four types of link keys
have been defined; 1) the combination key
KAB, the unit key KA, the temporary key
Kmaster, and the initialization key Kinit. A link
key can be semi-permanent, i.e. having a
lifetime that spans more than one session, or
it can be temporary when its lifetime is
limited to only one session. The link key in
use at a particular time will be referred to as
the current link key. The current link key is,
like all other link keys, used for
authentication and generation of encryption
keys. The encryption key, denoted KC, is
derived from the current link key. Whenever
encryption is activated by an LM command
the value of the encryption key will change
automatically.
Link key generation
From the set of four defined link keys, the keys
KAB and KA play functionally the same role.
They differ only in the way they are
It would take us too long to go through all the
different cases of link key generation, so in this
article we will exhibit only the generation of
36
Information Security Technical Report, Vol. 5, No. 3

Bluetooth Security — An Overview
the initialization key Kinit and generation of the
combination key KAB.
Unit A
Unit B
LK_KA=E21(LK_RANDA,BD_ADDRA)
LK_KB=E21(LK_RANDB,BD_ADDRB)
The value of Kinit is computed by the E22
algorithm from the BD_ADDR of the claimant
unit, a PIN code, the length of the PIN code (in
number of octets), and a random number
IN_RAND. The claimant unit is that unit that
has to prove to the other unit, referred to as the
verifier, that it knows the correct PIN (length
and value). Which unit will be the claimant
and which the verifier is decided by the
application through HCI commands.
CA
CB
⊕
⊕
K
CA=LK_RANDA
K
CB=LK_RANDB
⊕
⊕
K
LK_RANDB = CB
K
LK_RANDA = CA
LK_KA=E21(LK_RANDA,BD_ADDRA)
LK_KB=E21(LK_RANDB,BD_ADDRB)
⊕
⊕
KBA = LK_KB LK_KA
KAB = LK_KA LK_KB
Figure 4: Generation process of a combination key
using the E algorithm. The old link key K is
deleted when21the exchange of the new combination
key has been successful.
When the PIN is shorter than 16 octets it is
augmented by padding it with the data of
BD_ADDR. Thereafter, if necessary, internally
in E22 it is cyclically expanded to 128 bits. Thus
internally in E22 we have the 128-bit IN_RAND
and the (possibly augmented and expanded)
128-bit PIN. The internal working of E22 besides
this possible cyclic expansion is defined by the
function A’r that encrypts the IN_RAND value
using the augmented PIN as the key, see [1] for
exact details. The function A’ is basically the
SAFER+ encryption algorrithm with a
modification to prevent direct use of E22 as an
encryption/decryption engine. The A’r function
will be detailed when we describe its use in the
Bluetooth E1 authentication algorithm.
key which is either a unit key or a
combination key. Suppose the units agree
via LM commands on using a combination
key. Then the units encrypt their cyclically
expanded BD_ADDR values using a locally
randomly generated value LK_RAND. The
resulting value is referred to as LK_K. The
two LK_RAND values are exchanged after
masking them with the current link key, K,
value. This allows both units to determine
the other’s unit LK_K value and to compute
the XOR sum of both the LK_K values to
obtain the final combination key K . For the
encryption the Bluetooth E21 algAoBrithm is
used. The internal working of E21 is the same
as that of E22. We omit the details here.
Figure 4 shows the process of generating the
combination key. Note that the combination
key computed by both units is the same
because the XOR sum ( ) commutes, i.e. KBA
After generating the initialization key Kinit,
the units will create a semi-permanent link
= LK_KB LK_K = LK_K
LK_KB = K .
After K has bAeen geneArated a mutuAaBl
authentiAcBation is performed by first doing
the authentication procedure in one
direction and, if successful, immediately
performing the authentication procedure in
the opposite direction. The details of the
procedure will be the subject of the next
section of this article. If this succeeds K
becomes the current link key and the olAdB
link key K is discarded.
PIN
PIN’
L’
E22
Padding
Of
PIN
With
L
BD_ADDR
BD_ADDR
Kinit
A’
r
IN_RAND
Figure 3: The initialization key generation process
using the E22 algorithm.
Information Security Technical Report, Vol. 5, No. 3
37

Bluetooth Security — An Overview
Authentication between Bluetooth
units
system involves the BD_ADDR of the
claimant and uses the algorithm E1. An
attacker that wants to impersonate the
claimant but does not know the key may try
to come-up with a valid response value that
matches the challenge sent by the verifier.
Since the challenge is a 128-bit random value
it is impossible in practice for the real verifier
and claimant to have used this challenge
before. Thus recording valid challenge/
response pairs for later use is not a threat,
provided that the random number generator,
which creates the challenge values, is good.
The attacker might use earlier observed
challenge/response pairs to recover the link
key. Presently this would require the
breaking of the SAFER+ block cipher (a
respected cipher that has withstood existing
crypt-analytic techniques). So the attacker’s
decision about his response value is no better
than guessing, and, hence, the attacker will
succeed with probability 2-32. This is too low
to be of any practical use to the attacker.
The authentication mechanism
As mentioned earlier, during the
authentication process the LM designates one
unit as the verifier and the other unit as the
claimant that has to prove to the verifier that
it knows the same secret, the current link key
that the verifier has. The mechanism used in
Bluetooth is a so-called challenge response
scheme where the claimant is sent a random
value that the claimant has to process
together with the secret link key to obtain a
response value. The claimant sends this
response value back to the verifier who
compares the received value against the
expected value the verifier has computed
him/herself. If the two values agree the
authentication is claimed to be successful. If
the values differ the authentication fails. A
certain waiting interval must pass before a
new authentication attempt can be made. For
each authentication failure with the same
Bluetooth address involved, the waiting
interval will be increased exponentially until
a given limit is reached. For making the
system less vulnerable to denial-of-service
attacks it is recommended that Bluetooth
units should keep a list of individual waiting
intervals for each unit it has established
contact with. As Figure 5 illustrates the
authentication process in the Bluetooth
Mutual authentication is achieved by
performing the scheme of Figure 5 in both
directions, i.e. in the second authentication the
roles of claimant and verifier are reversed.
As a side-effect of a successful auth-
entication procedure an auxiliary parameter,
the Authenticated Ciphering Offset (ACO),
will be computed. The ACO is used for
ciphering key generation. Note that when
performing mutual authentication some
coordination has to take place as to which
ACO needs to be retained for ciphering key
generation. We refer to [1, Section 14.2.2.2]
for more details.
Verifier
(user A)
Claimant
(user B)
RAND
SRES =E1(K,BD_ADDRB,RAND)
SRES’ =E1(K,BD_ADDRB,RAND)
Check: SRES=’ SRES
SRES
The Algorithm E1
At the heart of the authentication mechanisms
we have the Bluetooth authentication function
E1. E1 uses the encryption function SAFER+ in
the 128-bit key mode. Like in the Bluetooth
Figure 5: Bluetooth Challenge-response
authentication scheme.
38
Information Security Technical Report, Vol. 5, No. 3

Bluetooth Security — An Overview
specification this block cipher is here denoted
as the function A which maps the 128-bit
input x under ther128-bit key k to a 128-bit
output t;
RAND BD_ADDR L=6
K
Ar
128
48
8
t = Ar(k,x).
offset
+
16
The function E1 is constructed using Ar and
performs the operation:
128
+
16
E
E1: (K,RAND,BD_ADDR) (SRES, ACO)
A’ r
where SRES is a 32-bit response value and
ACO is a 96-bit authenticated ciphering offset
value computed respectively as:
+
16
16 8 bit xor additions
+
16
16 8 bit additions mod 256
32
96
SRES
ACO
SRES
=
octets
0
through
3
of
Hash(K,RAND,BD_ADDR,6)
Figure 6: E1 construction using the SAFER+ block
cipher Ar.
and:
SAFER+ round is added to the input of the
third round. This is done to make the modified
version non-invertible and it prevents the
immediate use of A’r (especially in E and E )
as an encryption/decryption means.21Figure226
shows the overall construction of E1.
ACO
=
octets
4
through 15 of
Hash(K,RAND,BD_ADDR,6).
The function Hash( , , , ) is a keyed hash
function defined as2 :
Hash(K,I1,I2,L) = A’r( offset(K), [ E(I2,L) +16
(Ar(K,I1) 16 I1)] )
There were several reasons for choosing
SAFER+. Firstly it is a modern block cipher that
operates directly on 128-bit data blocks and has
an 128-bit key. SAFER+ was one of the
and where the cyclic expansion function E is
defined by:
3
candidates for the new AES block cipher
standard but was surpassed in speed by some
other candidates. Since the application in
Bluetooth does not concern bulk encryption the
fact that SAFER+ is based on a proven design
and that a very in-depth strength analysis is
available outweighed by far the speed aspects.
E(x[0,...,L-1], L) (x[ i mod L]; i=0,...,15).
The value offset(K) is an additive offset from K
using a mix of mod 256 and XOR additions.
We refer to the Bluetooth specification for the
details [1, Section 14.5.1]. The hash functions
use both Ar and a modified version of it; A’r.
The function A’ is SAFER+ with the
modification thart the input of the first
Encryption
The encryption provided in the Bluetooth
system can protect the packet payload. The
2The operator +16 denotes the bytewise addition mod
256 of the 16 octets, and the operator 16 denotes the
bytewise XOR-ring of the 16 octets.
3Submitted by Cylink Corp, Sunnyvale, USA and
designed by J.L. Massey and G. Khachatrian.
Information Security Technical Report, Vol. 5, No. 3
39

Bluetooth Security — An Overview
L
=
effective key size
(in octets)
k
EN_RAND
ACO
KC
Sizelimiter and
reformatting of
KC
E
3
Plain text/Cipher text
bits
Link key
K’ C
Z
BD_ADDR master
clockmaster
E0
E0
Cipher text/Plain text
bits
Ciphering payload key
computation
Payload
Ciphering/deciphering
Ciphering key
computation
Figure 7. Overall process for ciphering and deciphering of the payload.
packet header and other control information
are never encrypted. The encryption of the
payload is performed with a stream cipher E
that is re-synchronized for every payload0.
Whether encryption is activated or not, is
decided by the LM. The overall principle of
the encryption process is shown in Figure 7.
The process consists of three stages. Firstly, the
ciphering key KC is computed from the
EN_RAND, ACO4, and the current link key.
The computation is performed by the
Bluetooth E3 algorithm. Secondly, the
ciphering payload key is computed from the
ciphering key, the master’s BD_ADDR and
clock values. This computation is done by E0
with the addition that prior to its computation
the ciphering key is possibly limited in size
and reformatted to get an effective key size of
Lk octets. Thirdly, in the final stage, the
payload is actually encrypted by the bitstream
generated by E0. Deciphering is performed in
the same manner.
The E3 algorithm computes KC as:
KC = Hash(K,EN_RAND,ACO,12)
where Hash( , , , ) is the hash function
mentioned earlier and where K is the current
link key.
When the effective key size is 16 octets KC is
passed unaltered as K’C to the second phase. If
the effective key size is less than 16 octets the
KC is modified by computing K’C as:
L
L
K’C(x) = g2 (x) ( K (x) mod g (x))
k
k
(computations in GF2[x])C
1
where K’C(x) and KC(x) are the corresponding
representations as polynomials over the finite
L
field GF2, and the polynomials g1 (x) and
k
g2L (x) are fixed polynomials as specified in
k
the
Bluetooth
specifications.
The
L
computation mod g1 (x) reduces the
k
effective length of KC to L octets and the
subsequent product by g2 k(x) expands the
Lk
4 In the Bluetooth specification one finds here the COF
parameter COF. In our limited condensed description
COF = ACO.
obtained reduced key to 128 bits (or near to
it) with the property that it contains only 8Lk
40
Information Security Technical Report, Vol. 5, No. 3

Bluetooth Security — An Overview
effective bits. The effective key size Lk can be
1 through 16 octets. Each Bluetooth unit has
been assigned a maximal value of Lk referred
to as L . This maximal value of Lk can be
hardwimreaxd in the unit. Each application can
define a minimal value Lmin for Lk. Which
effective key length is used depends on a
protocol between the master and the slave
that negotiates the final value on the basis of
required minimal and maximal values of the
units involved. It could happen that the
negotiation fails because, e.g. a slave has a
too small value of Lmax. In such negotiation
failures Bluetooth link encryption cannot be
applied.
The stream cipher algorithm E itself uses four
linear feedback shiftregisters 0(LFSRs) whose
output is combined by a finite state machine
(called the summation combiner) with 16
states. The construction is highly tuned for
low-power hardware implementation. Based
on analysis of Meier and Staffelbach [3] of a
similar construction, the Bluetooth summation
combiner uses a simple mechanism to lower
the correlation between the produced
keystream sequence and the internal state of
the LFSRs. Figure 8 shows the concept of the
encryption engine. For details on the exact
way to initialize the LFSRs, how the output
bits Xit (i=1,2,3,4) are formed, and how the
mappings T1 and T2 are specified we refer to
the Bluetooth specification, [1, Section 14.3.4].
The feedback polynomials of each of the
LFSRs are given in Figure 8 and are so-called
primitive polynomials.
After having computed the K’C, the payload
ciphering key has to be derived. The payload
ciphering key is created by loading E0 with the
K’C value, and the master’s BD_ADDR and
clock values. After having ran E for a given
number of clock cycles the last 1208 output bits
are retained and fed back into E0 as the payload
key. This task is always performed prior to
transmitting or receiving a new packet.
Before we conclude this section with a brief
review of the strength of E it is important to
point out that encrypting t0he link traffic also
guarantees that the link is protected against
X1
t
LFSR1
X2
t
LFSR2
X3
t
Encryption keystream Zt
LFSR3
XOR
X4
t
2
2
LFSR4
T2
T1
2
Z-1
Z-1
Feedback polynomials
LFSR1:f(t)=t25+t20+t12+t8+1
LFSR2:f(t)=t31+t24+t16+t12+1
LFSR3:f(t)=t33+t28+t14+t4+1
LFSR4:f(t)=t39+t36+t28+t4+1
XOR
c
t
1
2
2
3
3
2
+
+
/2
yt
Figure 8. Concept of the E0 stream cipher engine and the four feedback polynomials.
Information Security Technical Report, Vol. 5, No. 3
41

Bluetooth Security — An Overview
known
keystream
material.
Some
(a)
improvements to this type of attack bring this
down to O(261) operations and O(250) known
key stream material [5]. Hence E0 has
sufficient safety margin against the currently
best known attacks.
A simple use case
Bluetooth technology can be applied to build a
wireless headset accessory for a mobile phone.
The physical size of a radio unit is indeed
small as Figure 9 demonstrates. Clearly, in this
application the headset has no MMI. Therefore
the headset can be programmed during
manufacture with a random PIN code value
that the user receives together with the
handset. During the initialization phase the
mobile phone user selects a menu on the
phone to initialize the headset. The headset
will automatically discover that it is not
already paired with this unit as soon as a
connection attempt is performed. Both units
enter the pairing mode during which the user
is prompted to enter the headset’s PIN code
value. When this has been done the built-in
key management functions generate an
initialization key which is used to exchange
the semi-permanent combination key. After
the generation of KAB, a mutual authentication
is performed. All these steps are performed
without any user or application intervention.
Should the authentication attempt fail, the
user will be asked once more to enter a PIN.
Once the mutual authentication has
succeeded, the units are paired which means
that no user interaction at all will be necessary
on the next occasion the headset and mobile
phone set up a connection.
(b)
Figure 9: a) The Bluetooth module is a realization of
the radio part in a MCM module and designed for
communication distances up to 10 metres. b) The
Ericsson wireless headset..
hijacking attempts by a malicious user. The
use of ACO in the derivation of K always
links the encryption process to Cthe last
authentication.
Finally some words about the strength of E0.
First we note that the longest payload that will
be encrypted/decrypted contains 2712 bits.
This is much too short to make it feasible to
perform any cryptanalysis on the basis of a so-
called correlation attack which is among the
strongest attacks presently known on this type
of stream cipher. In [4] a method is described
that breaks the cipher using a known-
plaintext/ciphertext attack that requires O(264)
operations and O(264) consecutive bits of
Due to the fact that the owner of the mobile
phone probably does not want everybody to
be able to connect a wireless headset to
his/her phone, the software running on the
phone would issue an authentication request
to the connecting headset each time a
42
Information Security Technical Report, Vol. 5, No. 3

Bluetooth Security — An Overview
connection is set up between them (regardless
of which unit actually initiates this
connection). For this example it is also likely
that the voice link will be encrypted. The
mobile phone (or the headset) can issue a
request for authentication as well as for
switching the encryption on through specific
HCI commands.
combine it with the built-in security
mechanisms for obtaining short-term link
protection.
References
[1] Bluetooth Baseband Specification V1.0B,
obtainable via www.bluetooth.com.
[2] A.J. Menezes, P.C. van Oorschot and S.A.
Vanstone, 1997. Handbook on Applied
Cryptology, CRC Press, New York, 1997.
Conclusions
The Bluetooth system provides several built-
in security mechanisms that allow developers
to secure a wide range of applications. This
strengthens the benefits of Bluetooth
technology both for the solution developers
and for the end-users. In more complex usage
scenarios the existing security mechanisms
need extending into an overall security
architecture. As a starting point the reader
may want to read the Bluetooth Whitepaper
on the Security Architecture. This is the first
guideline for application developers on
Bluetooth security that the Bluetooth Special
Interest Group (SIG) has released. When
applications need a very high degree of
security it is advisable to provide this security
at the application level (or just below it) and
[3] W. Meier and O. Staffelbach, 1992.
“Correlation properties of combiners with
memory in stream ciphers”, Journal of
Cryptology, Vol. 51(1), 1992, pp. 67-86.
[4] M. Hermelin and K. Nyberg, 1999.
“Correlation Properties of the Bluetooth
Combiner Generator”, Proceedings ICISC’99,
1999 International Conference on Information
Security and Cryptology, 9-10 December 1999,
Seoul, S. Korea, LNCS 1787, Springer Verlag
1999.
[5] S. Fluher, input to discussion group
sci.crypt.reseach, 2000-02-25.
Information Security Technical Report, Vol. 5, No. 3
43