Bluetooth Security — An Overview

Information Security Technical Report, Vol 5, No. 3 (2000) 32-43

32 0167-4048/00/$20.00 © 2000, Elsevier Science Ltd

Joakim Persson and Ben Smeets, Ericsson MobileCommunications AB, Ericsson Research

Background

Over the last five years, the market forportable devices has more or less exploded.Nowadays, a laptop or a notebook computeris not only a ‘necessary’ accessory for almostevery businessperson on the move, but it isalso becoming a preferred alternative over itsstationary companion for many newcomputer buyers. The classic time managershave to a large extent been replaced byelectronic PDAs of different kinds. Moreover,with the tremendous increase in use of cellularphones all over the world, at least oneportable device is now present in the daily lifeof most people. Up till now, all these deviceshave worked virtually completely isolatedfrom each other. The reason is partly thatinterconnecting portable devices requiresdifferent cabling equipment; mostmanufacturers have chosen proprietaryconnectors to be able to promote and sell theirown products. Clearly, having to carry a lot ofdifferent cables is not very convenient.

The more we use these devices, the more itbecomes clear that many useful applicationsrequire seamless communication with clientsand/or servers running on devices physicallyseparated from each other. The distance mightin fact be quite small, in the region of a fewmetres or less, but nevertheless, smoothoperation requires the means forcommunication with remote devices. Todaythere is IrDA, the infrared standard, and thereare different kinds of wireless local areanetworks (WLAN). However, the drawback ofthese (line of sight requirement for IrDA andquite expensive and complex solutions for

existing WLAN technologies) has created ademand for a new cheap radio-based solution.This is where Bluetooth enters the picture.

Early during the development of theBluetooth specification it became clear that therequirements imposed by modernapplications are not just restricted to having agood radio interface design, but also to havingsupport for security. Before we elaborate onsecurity in Bluetooth, we will give a shortoverview of the Bluetooth system.

What is Bluetooth?

Bluetooth is a short-range radio link intendedto replace cables connecting portable and/orfixed electronic devices. Its main features arerobustness, low complexity, low powerconsumption and low cost. The Bluetoothradio system operates in the globally availableunlicensed Industrial, Scientific and Medical(ISM) band at 2.4 GHz and, depending on thepower class of the transceiver, provides forradio connections with a maximal range ofbetween 10 and 100 meters. A Frequency HopSpread Spectrum (FHSS) technique withnarrowband (1 MHz) transmission is appliedto combat interference and fading. The hopsare spread over the entire available band of 79MHz using pseudo-random sequences. AllBluetooth units following a particularhopping sequence are said to listen to thesame channel.

Bluetooth uses binary GFSK modulation witha symbol rate of 1 Msymb/s. A slotted channelstructure is applied with a nominal slot lengthof 625 µs. This corresponds to 1600 hops persecond, a fairly high number compared to thewireless LANs that exist today and operate inthe same ISM band (c.f., IEEE 802.11 that uses50 hops per second). Time-division duplex

Bluetooth Security — An Overview


Information Security Technical Report, Vol. 5, No. 3 33

(TDD) is exploited for dividing the commonchannel in a master-to-slave and a slave-to-master direction. The Bluetooth protocol usesa combination of circuit and packet switching,allowing for a mixture of simultaneoussynchronous (voice) and asynchronous (data)traffic. The data traffic can be symmetric orasymmetric. The Bluetooth system can, forexample, support an asymmetricasynchronous connection at 723.2 kb persecond (user data rate) in one direction with57.6 kb per second in the return direction, or asymmetric asynchronous connection at 433.9kb per second in both directions.

The Bluetooth system provides point-to-point(connecting only two Bluetooth units) as wellas point-to-multipoint connections. In thepoint-to-multipoint connection the channel isshared among several Bluetooth units. Two ormore units sharing the same channel form apiconet. In each piconet one Bluetooth unit isgiven the special task of being the master,whereas the other unit(s) act as slave(s). Thehopping sequence used in a piconet isdetermined by the address and clock of themaster device. The underlying networktopology is a star formed with the master inthe centre. The master addresses the slavesthrough a polling scheme. No slave can accessthe channel unless it has been explicitlyaddressed by the master. Thus, there can be nodirect data traffic flowing from one slave toanother in a piconet. When a unit becomes amember of a piconet it is said that itcommences a session. The session terminateswhen the unit disconnects from the piconet.

There can be at most eight active Bluetoothunits in one piconet, including the master.Furthermore, slaves can be locked to thepiconet in a so-called parked state. For

practical reasons, the number of parked slaveswill not be more than 2551. A parked slavemust be un-parked before it can be active onthe channel. This operation may requireparking of an existing active slave first sincethere is only room for seven active slaves.

Finally, two or more piconets withoverlapping coverage areas form a so-calledscatternet. If desired, slaves can participate in atime-division multiplex fashion in more thanone piconet. Figure 1 illustrates three piconetoperation scenarios; a) single slave operation,b) a multi-slave operation and c) a scatternetwith inter-piconet operation.

Most of the built-in control intelligence neededto set-up and administer a link resides in thebaseband Link Controller and Link Manager(LM) of a Bluetooth unit. In principle, thebaseband can be viewed as consisting of twoseparate entities: the physical layer (with RFmodulation, coding, timing etc.) and a statemachine controlling all this. Sometimes the latterentity is referred to as the Link Controller (LC).Link manager protocol (LMP) messages areexchanged in a peer-to-peer fashion. Thesemessages are transmitted in the payload and arefiltered out and interpreted by the LM and notpropagated to higher layers.

The physical device implementing the lowerparts of the specification is usually a moduleresiding in a host lacking these Bluetooth

1 In theory the maximum number of simultaneouslyparked slaves in a piconet is only limited by theBluetooth device address space

Slave A Slave A

Slave B Slave B

Slave C

Slave B

Slave A Slave C

Master X

Slave Y(a) (b) (c)

Figure 1: a) Single slave operation, b) a multi-slaveoperation and c) a scatternet with inter-piconetoperation.


34 Information Security Technical Report, Vol. 5, No. 3

capabilities itself (e.g. a laptop computer).The host interacts with the Bluetoothmodule through the Host ControllerInterface (HCI). This interface constitutes auniform command method for accessingBluetooth hardware capabilities. Typically,for commands controlling the link it willinvolve the LM to exchange LMP messageswith remote Bluetooth devices. Moreover,the host can read and write chunks of datathrough this interface. The higher layerprotocol data packets need to be segmentedinto (and reassembled from) the relativelylimited baseband packet sizes that arepassed to and from the LM via the HCI.Since there is only one physical link permodule, support for multiplexing betweenhigher layer protocols sharing this link isalso necessary. Furthermore, some servicesrequire the means for exchanging

information regarding the Quality of Service(QoS) expected between units. All this is thetask of the Logical Link Control andAdaptation Protocol (L2CAP), which residesin the host. Figure 2 shows the positioningof these layers in the Bluetooth protocolstack.

Why is security needed in Bluetooth?

The sheer simplicity of the Bluetooth conceptis enough to generate numerous innovativeapplications of quite different kinds. Therange spans from simple point-to-point cablereplacement tasks to advanced ad-hocnetworking. An example of the former is awireless headset with a Bluetooth link fromthe headset to the cellular phone. Moreover,printers may be configured with Bluetoothradios to which any Bluetooth enabledcomputer can easily be connected. Anexample of an ad-hoc network could be ameeting room scenario where laptops canshare files, business cards and commonresources such as a projector forpresentations. Clearly, the security needs forthese and other applications are verydifferent. A headset user is probablyconcerned with the privacy of the voice linkand would like to be assured that onlyauthorized headsets are able to connect to hisparticular mobile phone. In the meeting roomscenario, the file sharing should preferably berestricted to a specific group created in an ad-hoc manner; any non-authorized Bluetoothdevice outside the room should not be able tojoin this group. On the other hand, not allapplications have strict requirements onsecurity. For instance, a printer located in apublic library may allow access for a verylarge group of people that use this facility. A‘flight information kiosk’ at an airport mayallow unrestricted access to its services forany Bluetooth device. In the Bluetoothspecification, hooks that make all thesescenarios possible have been included.

HCI firmware

Bluetooth hosts

L2CAP

HCI driver

L2CAP

HCI driver

HCI HCI

HCI firmware

LM LM

LC LC

RFRF

Physical Layer

Bluetooth modules

Bas

eban

d

Bas

eban

d

Figure 2: Lower part of the Bluetooth protocol stack:the baseband (RF and LC), the LM, the HCI, andthe L2CAP.



However, for some of them (e.g. file sharingand creating groups) it is necessary to extendsoftware within the particular application.This is in accordance with the generalapproach of the specification, viz., the lowerlayers provide functional ‘atoms’ on whichhigher layers can build more complexprotocols.

The frequency hopping in the Bluetoothsystem provides some protection againstcasual interception of traffic originating fromother Bluetooth unit pairs. However, it isobvious that this protection is not sufficientto guarantee that the traffic of user databetween two Bluetooth units is not accessibleto a malicious eavesdropper who targets thetraffic between users. Especially in systemsthat use radio transmission, eavesdroppershave ample opportunities to make theiractions invisible to the communicating users.Therefore, the Bluetooth system incorporatessecurity mechanisms that guaranteeconfidentiality of user data. By doing this,rather than leaving this problem for the users(or the application) to solve, it is possible tohave confidentiality even in the mostminimal Bluetooth systems that one canconstruct. In the Bluetooth systemconfidentiality is realized through encryptionof the packets that are exchanged betweentwo communicating units. For reasons thatwill be explained later the encryptionmechanism is linked to another securitymechanism in the Bluetooth system, namelythe authentication mechanism. Encryption byitself is not sufficient for establishing a secureconnection between two units. In fact, maybemore important than having the means tokeep data confidential is the need toguarantee that when a radio connection isestablished, users know only intendeddevices are talking to each other. For thisreason the Bluetooth system providessecurity mechanisms that performauthentication of the users of units. Like the

confidentiality mechanisms, theseauthentication mechanisms are also availablein all certified Bluetooth units for immediateuse in all applications. In the next twosections the authentication and encryptionmechanisms are explained in more detail.

The Bluetooth system uses four different typesof entities to maintain security at the linklayer; a public address that is unique for eachunit, two secret keys, and a random numberwhich is different for each new transaction.The four entity types and their sizes aresummarised in Table 1.

Entity Size

BD_ADDR 48 bits

Private user key, authentication 128 bits

Private user key, encryption 8-128 bitsConfigurable length (byte-wise)

RAND 128 bits

Table 1: Entity types used in Bluetoothauthentication and encryption procedures.

In the specification the 48-bit IEEE (public)address is not a secured entity. The secret keysare derived during initialization. Theencryption keys are configurable in size for tworeasons. The first reason is the differences inrequirements imposed on the deployment andusage of cryptographic algorithms with respectto export regulations and official attitudestowards privacy in general. The second reasonis to facilitate a standardized upgrade path.

Key management

Key types

The keys for the authentication andencryption procedures have several functions



that support the Bluetooth system in itsvarious phases and modes of operation. Thereis a distinction between the phase where twounits want to communicate without havinghad contact before and the phase where thiscommunication takes place after the unitsalready have met before. In the former case thesecret keys have to be established for the firsttime, while in the latter case the units can usethe secret keys from the previouscommunication instance. Clearly these phasesrequire different procedures for managing thekeys. Moreover the Bluetooth master maywant to broadcast to some of its slaves insteadof communicating with each of themseparately. This also requires some special keymanagement. The Bluetooth system providesa handful of key management functions thatsupport the basic phases and modes ofoperation. For convenience, and also forunderlining the importance of theauthentication key, this key will often bereferred to as the link key.

In order to support the different phases andmodes of operation, four types of link keyshave been defined; 1) the combination keyKAB, the unit key KA, the temporary keyKmaster, and the initialization key Kinit. A linkkey can be semi-permanent, i.e. having alifetime that spans more than one session, orit can be temporary when its lifetime islimited to only one session. The link key inuse at a particular time will be referred to asthe current link key. The current link key is,l ike all other l ink keys, used forauthentication and generation of encryptionkeys. The encryption key, denoted KC, isderived from the current link key. Wheneverencryption is activated by an LM commandthe value of the encryption key will changeautomatically.

From the set of four defined link keys, the keysKAB and KA play functionally the same role.They differ only in the way they are

generated. Whereas the combination key KABis the result of a key generation processinvolving two units (A and B say), the unit keyKA is generated, and therefore dependent on, asingle unit (A say). Typically a unit key iscreated during an initialization phase and isvery rarely changed. Bluetooth units that havelittle memory may prefer the use of unit keys.Units that require more security may prefercombination keys.

The master key Kmaster is a temporary key thatwill replace the original link key temporarilywhen, for example, a master wants tocommunicate with more than one slavesimultaneously using the same encryptionkey.

Finally, the initialisation key Kinit is used as thelink key during the initialization phase whenno combination or unit keys are present. It is atemporary link key only used duringinitialization. The generation of thisinitialization key involves a PersonalIdentification Number (PIN) code. This PINcan be a number provided with the Bluetoothunit, e.g. when the unit has no Man MachineInterface (MMI) as in a PSTN plug.Alternatively, the PIN can be selectedarbitrarily by the user and entered in bothunits that want to meet. This can be donemanually using some MMI or this can be doneby the applications that are using the units.The Bluetooth specification requires that thevalue of the PIN can be changed. The length ofthe PIN can be up to 16 octets. This allows, forexample, the implementation of an automaticPIN code exchange through a Diffie-Hellmankey agreement, see [2], rather than throughmanual means.

Link key generation

It would take us too long to go through all thedifferent cases of link key generation, so in thisarticle we will exhibit only the generation of



the initialization key Kinit and generation of thecombination key KAB.

The value of Kinit is computed by the E22algorithm from the BD_ADDR of the claimantunit, a PIN code, the length of the PIN code (innumber of octets), and a random numberIN_RAND. The claimant unit is that unit thathas to prove to the other unit, referred to as theverifier, that it knows the correct PIN (lengthand value). Which unit will be the claimantand which the verifier is decided by theapplication through HCI commands.

When the PIN is shorter than 16 octets it isaugmented by padding it with the data ofBD_ADDR. Thereafter, if necessary, internallyin E22 it is cyclically expanded to 128 bits. Thusinternally in E22 we have the 128-bit IN_RANDand the (possibly augmented and expanded)128-bit PIN. The internal working of E22 besidesthis possible cyclic expansion is defined by thefunction A’r that encrypts the IN_RAND valueusing the augmented PIN as the key, see [1] forexact details. The function A’r is basically theSAFER+ encryption algorithm with amodification to prevent direct use of E22 as anencryption/decryption engine. The A’r functionwill be detailed when we describe its use in theBluetooth E1 authentication algorithm.

After generating the initialization key Kinit,the units will create a semi-permanent link

key which is either a unit key or acombination key. Suppose the units agreevia LM commands on using a combinationkey. Then the units encrypt their cyclicallyexpanded BD_ADDR values using a locallyrandomly generated value LK_RAND. Theresulting value is referred to as LK_K. Thetwo LK_RAND values are exchanged aftermasking them with the current link key, K,value. This allows both units to determinethe other’s unit LK_K value and to computethe XOR sum of both the LK_K values toobtain the final combination key KAB. For theencryption the Bluetooth E21 algorithm isused. The internal working of E21 is the sameas that of E22. We omit the details here.Figure 4 shows the process of generating thecombination key. Note that the combinationkey computed by both units is the samebecause the XOR sum (Å) commutes, i.e. KBA= LK_KBÅ LK_KA = LK_KAÅ LK_KB = KAB.After KAB has been generated a mutualauthentication is performed by first doingthe authentication procedure in onedirection and, if successful, immediatelyperforming the authentication procedure inthe opposite direction. The details of theprocedure will be the subject of the nextsection of this article. If this succeeds KABbecomes the current link key and the oldlink key K is discarded.

PaddingOf

PINWith

BD_ADDR A’ r

PIN

BD_ADDR

IN_RAND

L

PIN’

L’

E22

Exp

and

cycl

e

Kinit

Figure 3: The initialization key generation processusing the E

22algorithm.

LK_K A=E21(LK_RANDA,BD_ADDRA)

CA=LK_RANDA ⊕ K

LK_RANDB = CB ⊕ KLK_KB=E21(LK_RANDB,BD_ADDRB)

KAB = LK_KA ⊕ LK_KB

LK_KB=E21(LK_RANDB,BD_ADDRB)

CB=LK_RANDB ⊕ K

LK_RANDA = CA⊕ KLK_K A=E21(LK_RANDA,BD_ADDRA)

KBA = LK_KB⊕ LK_KA

CA

CB

Unit A Unit B

Figure 4: Generation process of a combination keyusing the E

21algorithm. The old link key K is

deleted when the exchange of the new combinationkey has been successful.



Authentication between Bluetoothunits

The authentication mechanism

As mentioned earlier, during theauthentication process the LM designates oneunit as the verifier and the other unit as theclaimant that has to prove to the verifier thatit knows the same secret, the current link keythat the verifier has. The mechanism used inBluetooth is a so-called challenge responsescheme where the claimant is sent a randomvalue that the claimant has to processtogether with the secret link key to obtain aresponse value. The claimant sends thisresponse value back to the verifier whocompares the received value against theexpected value the verifier has computedhim/herself. If the two values agree theauthentication is claimed to be successful. Ifthe values differ the authentication fails. Acertain waiting interval must pass before anew authentication attempt can be made. Foreach authentication failure with the sameBluetooth address involved, the waitinginterval will be increased exponentially untila given limit is reached. For making thesystem less vulnerable to denial-of-serviceattacks it is recommended that Bluetoothunits should keep a list of individual waitingintervals for each unit it has establishedcontact with. As Figure 5 illustrates theauthentication process in the Bluetooth

system involves the BD_ADDR of theclaimant and uses the algorithm E1. Anattacker that wants to impersonate theclaimant but does not know the key may tryto come-up with a valid response value thatmatches the challenge sent by the verifier.Since the challenge is a 128-bit random valueit is impossible in practice for the real verifierand claimant to have used this challengebefore. 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 observedchallenge/response pairs to recover the linkkey. Presently this would require thebreaking of the SAFER+ block cipher (arespected cipher that has withstood existingcrypt-analytic techniques). So the attacker’sdecision about his response value is no betterthan guessing, and, hence, the attacker willsucceed with probability 2-32. This is too lowto be of any practical use to the attacker.

Mutual authentication is achieved byperforming the scheme of Figure 5 in bothdirections, i.e. in the second authentication theroles 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 forciphering key generation. Note that whenperforming mutual authentication somecoordination has to take place as to whichACO needs to be retained for ciphering keygeneration. We refer to [1, Section 14.2.2.2]for more details.

The Algorithm E1

At the heart of the authentication mechanismswe have the Bluetooth authentication functionE1. E1 uses the encryption function SAFER+ inthe 128-bit key mode. Like in the Bluetooth

Verifier(user A)

Claimant(user B)

RAND

SRESSRES = E1(K,BD_ADDRB,RAND)SRES’ = E1(K,BD_ADDRB,RAND)

Check: SRES’ = SRES

Figure 5: Bluetooth Challenge-responseauthentication scheme.



specification this block cipher is here denotedas the function Ar which maps the 128-bitinput x under the 128-bit key k to a 128-bitoutput t;

t = Ar(k,x).

The function E1 is constructed using Ar andperforms the operation:

E1: (K,RAND,BD_ADDR) ® (SRES, ACO)

where SRES is a 32-bit response value andACO is a 96-bit authenticated ciphering offsetvalue computed respectively as:

SRES = octets 0 through 3 ofHash(K,RAND,BD_ADDR,6)

and:

ACO = octets 4 through 15 ofHash(K,RAND,BD_ADDR,6).

The function Hash( , , , ) is a keyed hashfunction defined as2 :

Hash(K,I1,I2,L) = A’r( offset(K), [ E(I2,L) +16(Ar(K,I1) Å16 I1)] )

and where the cyclic expansion function E isdefined by:

E(x[0,...,L-1], L) ® (x[ i mod L]; i=0,...,15).

The value offset(K) is an additive offset from Kusing a mix of mod 256 and XOR additions.We refer to the Bluetooth specification for thedetails [1, Section 14.5.1]. The hash functionsuse both Ar and a modified version of it; A’r.The function A’r is SAFER+ with themodification that the input of the first

SAFER+ round is added to the input of thethird round. This is done to make the modifiedversion non-invertible and it prevents theimmediate use of A’r (especially in E21 and E22)as an encryption/decryption means. Figure 6shows the overall construction of E1.

There were several reasons for choosingSAFER+. Firstly it is a modern block cipher thatoperates directly on 128-bit data blocks and hasan 128-bit key. SAFER+ was one of thecandidates3 for the new AES block cipherstandard but was surpassed in speed by someother candidates. Since the application inBluetooth does not concern bulk encryption thefact that SAFER+ is based on a proven designand that a very in-depth strength analysis isavailable outweighed by far the speed aspects.

Encryption

The encryption provided in the Bluetoothsystem can protect the packet payload. The

Ar

E

A’ r

offset

SRES ACO

RAND BD_ADDR L=6

K

128 48 8

128

9632

+16

+16

+16

+16

16 8 bit xor additions

16 8 bit additions mod 256

Figure 6: E1

construction using the SAFER+ blockcipher A

r.

2The operator +16 denotes the bytewise addition mod256 of the 16 octets, and the operator Å16 denotes thebytewise XOR-ring of the 16 octets.

3Submitted by Cylink Corp, Sunnyvale, USA anddesigned by J.L. Massey and G. Khachatrian.



packet header and other control informationare never encrypted. The encryption of thepayload is performed with a stream cipher E0that is re-synchronized for every payload.Whether encryption is activated or not, isdecided by the LM. The overall principle ofthe encryption process is shown in Figure 7.The process consists of three stages. Firstly, theciphering key KC is computed from theEN_RAND, ACO4, and the current link key.The computation is performed by theBluetooth E3 algorithm. Secondly, theciphering payload key is computed from theciphering key, the master’s BD_ADDR andclock values. This computation is done by E0with the addition that prior to its computationthe ciphering key is possibly limited in sizeand reformatted to get an effective key size ofLk octets. Thirdly, in the final stage, thepayload is actually encrypted by the bitstreamgenerated by E0. Deciphering is performed inthe same manner.

The E3 algorithm computes KC as:

KC = Hash(K,EN_RAND,ACO,12)

where Hash( , , , ) is the hash functionmentioned earlier and where K is the currentlink key.

When the effective key size is 16 octets KC ispassed unaltered as K’C to the second phase. Ifthe effective key size is less than 16 octets theKC is modified by computing K’C as:

K’C(x) = g2Lk(x) ( KC(x) mod g1

Lk(x))(computations in GF2[x])

where K’C(x) and KC(x) are the correspondingrepresentations as polynomials over the finitefield GF2, and the polynomials g1

Lk(x) andg2

Lk(x) are fixed polynomials as specified inthe Bluetooth specifications. Thecomputation mod g1

Lk(x) reduces theeffective length of KC to Lk octets and thesubsequent product by g2

Lk(x) expands theobtained reduced key to 128 bits (or near toit) with the property that it contains only 8Lk

E3

EN_RAND

E0

ACO

Link key

E0

BD_ADDR master

clockmaster

Size limiter andreformatting of

KC

L k = effective key size(in octets)

KC

Plain text/Cipher textbits

Cipher text/Plain textbits

Z

Ciphering keycomputation

Ciphering payload keycomputation

PayloadCiphering/deciphering

K’ C

Figure 7. Overall process for ciphering and deciphering of the payload.

4 In the Bluetooth specification one finds here the COFparameter COF. In our limited condensed descriptionCOF = ACO.



effective bits. The effective key size Lk can be1 through 16 octets. Each Bluetooth unit hasbeen assigned a maximal value of Lk referredto as Lmax. This maximal value of Lk can behardwired in the unit. Each application candefine a minimal value Lmin for Lk. Whicheffective key length is used depends on aprotocol between the master and the slavethat negotiates the final value on the basis ofrequired minimal and maximal values of theunits involved. It could happen that thenegotiation fails because, e.g. a slave has atoo small value of Lmax. In such negotiationfailures Bluetooth link encryption cannot beapplied.

After having computed the K’C, the payloadciphering key has to be derived. The payloadciphering key is created by loading E0 with theK’C value, and the master’s BD_ADDR andclock values. After having ran E0 for a givennumber of clock cycles the last 128 output bitsare retained and fed back into E0 as the payloadkey. This task is always performed prior totransmitting or receiving a new packet.

The stream cipher algorithm E0 itself uses fourlinear feedback shiftregisters (LFSRs) whoseoutput is combined by a finite state machine(called the summation combiner) with 16states. The construction is highly tuned forlow-power hardware implementation. Basedon analysis of Meier and Staffelbach [3] of asimilar construction, the Bluetooth summationcombiner uses a simple mechanism to lowerthe correlation between the producedkeystream sequence and the internal state ofthe LFSRs. Figure 8 shows the concept of theencryption engine. For details on the exactway to initialize the LFSRs, how the outputbits Xi

t (i=1,2,3,4) are formed, and how themappings T1 and T2 are specified we refer tothe Bluetooth specification, [1, Section 14.3.4].The feedback polynomials of each of theLFSRs are given in Figure 8 and are so-calledprimitive polynomials.

Before we conclude this section with a briefreview of the strength of E0 it is important topoint out that encrypting the link traffic alsoguarantees that the link is protected against

1

3 2

LFSR1

XOR

LFSR2

LFSR3

LFSR4

+ + /2

Z-1 Z-1 XOR

T1T2

X2t

X1t

X3t

X4t

ct

Encryption keystream Zt

2

2

2

2

Initi

al v

alue

s

yt

LFSR1: f(t)=t25+t20+t12+t8+1

LFSR2: f(t)=t31+t24+t16+t12+1

LFSR4: f(t)=t39+t36+t28+t4+1

LFSR3: f(t)=t33+t28+t14+t4+1

Feedback polynomials

2

3

Figure 8. Concept of the E0

stream cipher engine and the four feedback polynomials.



hijacking attempts by a malicious user. Theuse of ACO in the derivation of KC alwayslinks the encryption process to the lastauthentication.

Finally some words about the strength of E0.First we note that the longest payload that willbe encrypted/decrypted contains 2712 bits.This is much too short to make it feasible toperform any cryptanalysis on the basis of a so-called correlation attack which is among thestrongest attacks presently known on this typeof stream cipher. In [4] a method is describedthat breaks the cipher using a known-plaintext/ciphertext attack that requires O(264)operations and O(264) consecutive bits of

known keystream material. Someimprovements to this type of attack bring thisdown to O(261) operations and O(250) knownkey stream material [5]. Hence E0 hassufficient safety margin against the currentlybest known attacks.

A simple use case

Bluetooth technology can be applied to build awireless headset accessory for a mobile phone.The physical size of a radio unit is indeedsmall as Figure 9 demonstrates. Clearly, in thisapplication the headset has no MMI. Thereforethe headset can be programmed duringmanufacture with a random PIN code valuethat the user receives together with thehandset. During the initialization phase themobile phone user selects a menu on thephone to initialize the headset. The headsetwill automatically discover that it is notalready paired with this unit as soon as aconnection attempt is performed. Both unitsenter the pairing mode during which the useris prompted to enter the headset’s PIN codevalue. When this has been done the built-inkey management functions generate aninitialization key which is used to exchangethe semi-permanent combination key. Afterthe generation of KAB, a mutual authenticationis performed. All these steps are performedwithout any user or application intervention.Should the authentication attempt fail, theuser will be asked once more to enter a PIN.Once the mutual authentication hassucceeded, the units are paired which meansthat no user interaction at all will be necessaryon the next occasion the headset and mobilephone set up a connection.

Due to the fact that the owner of the mobilephone probably does not want everybody tobe able to connect a wireless headset tohis/her phone, the software running on thephone would issue an authentication requestto the connecting headset each time a

Figure 9: a) The Bluetooth module is a realization ofthe radio part in a MCM module and designed forcommunication distances up to 10 metres. b) TheEricsson wireless headset..

(a)

(b)



connection is set up between them (regardlessof which unit actually initiates thisconnection). For this example it is also likelythat the voice link will be encrypted. Themobile phone (or the headset) can issue arequest for authentication as well as forswitching the encryption on through specificHCI commands.

Conclusions

The Bluetooth system provides several built-in security mechanisms that allow developersto secure a wide range of applications. Thisstrengthens the benefits of Bluetoothtechnology both for the solution developersand for the end-users. In more complex usagescenarios the existing security mechanismsneed extending into an overall securityarchitecture. As a starting point the readermay want to read the Bluetooth Whitepaperon the Security Architecture. This is the firstguideline for application developers onBluetooth security that the Bluetooth SpecialInterest Group (SIG) has released. Whenapplications need a very high degree ofsecurity it is advisable to provide this securityat the application level (or just below it) and

combine it with the built-in securitymechanisms for obtaining short-term linkprotection.

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 AppliedCryptology, CRC Press, New York, 1997.

[3] W. Meier and O. Staffelbach, 1992.“Correlation properties of combiners withmemory in stream ciphers”, Journal ofCryptology, Vol. 51(1), 1992, pp. 67-86.

[4] M. Hermelin and K. Nyberg, 1999.“Correlation Properties of the BluetoothCombiner Generator”, Proceedings ICISC’99,1999 International Conference on InformationSecurity and Cryptology, 9-10 December 1999,Seoul, S. Korea, LNCS 1787, Springer Verlag1999.

[5] S. Fluher, input to discussion groupsci.crypt.reseach, 2000-02-25.

Bluetooth Security — An Overview

Documents

Transcript of Bluetooth Security — An Overview