Securing wireless ad hoc networks: Part 3 - Bluetooth's security modes -

Securing wireless ad hoc networks: Part 3 – Bluetooth’s security modes


Just like IEEE 802.11 standard, the Bluetooth standard also definesLayer 1 and Layer 2 of the OSI stack to achieve communication insingle-hop personal-area ad hoc networks. However, by their verynature, ad hoc networks (Bluetooth) are a much less controlledenvironment than WLANs (802.11).

This, combined with the fact that the Bluetooth standard may be usedby a wide range of applications in many different ways, makesinteroperability a much bigger challenge in Bluetooth networks.

To ease the problem of interoperability, the Bluetooth SIG defined applicationprofiles. A profile defines an unambiguous description of thecommunication interface between two Bluetooth devices or one particularservice or application.

There are basic profiles which define the fundamental procedures forBluetooth connection and there are special profiles defined fordistinct services and applications. New profiles can be built usingexisting profiles, thus allowing for a hierarchical pro- file structureas shown in Figure 8.4, below .

Each service or application selects the appropriate profiledepending on its needs, and since each application may have differentsecurity requirements, each profile may define different securitymodes. The most fundamental profile is the Generic Access Profile (GAP)which defines the generic procedure related to the discovery of theBluetooth devices and link management aspects of connection betweenthem. The GAP defines three basic security modes of a Bluetooth device.

Figure8.4: Profiles in Bluetooth

Before we discuss the different security modes, it is important tokeep a few things in mind. First, the security mechanisms(authentication and encryption) specified by the Bluetooth standard areimplemented at the link layer (Layer 2).

This means that the scope of Bluetooth security is the Layer 2 levellink between two nodes separated by a single hop. To be explicit,Bluetooth security does not deal with end-to-end security and does notdeal with application layer security. (Thesource and destination nodes may be more than one hop away as in ascatternet .)

If such security mechanisms are required, they have to be arrangedfor outside the scope of the Bluetooth standard. Second, all Bluetoothdevices must implement an authentication procedure: that is arequirement.13 Bluetooth devices may or may not implement encryptionprocedures: that is optional.

However, just because a device implements or supports authenticationand/or encryption, does not mean that this device would use thesesecurity features in a connection. What security features are used fora Bluetooth connection depends on the security modes of the master andthe slave in the connection. (On theother hand, implementing encryption procedures is optional .)

Table 8.1, below, summarizeswhat security features are used in a Bluetooth connection depending onthe security mode of the master and the slave.


Security mode 1 is the unsecured mode in Bluetooth. A device using thismode does not demand authentication or encryption from its peer atconnection establishment.

This means that a device in security mode 1 offers its services toall devices which wish to connect to it. However, if the communicatingpeer device (say B) wishes to authenticate a node which is usingsecurity mode 1 (say A), then A must respond to the challenge that Bsends since A as a Bluetooth device must support authentication.

Similarly, if B wishes to use encryption on its link with A, then Amust turn on its encryption if it supports it. On the other end of thespectrum is security mode 3 which is the always-on security mode inBluetooth. A device which is in security mode 3 shall always initiatean authentication procedure. This means that this device will notcommunicate with a device unless it can authenticate it. The encryptionpart in security mode 3 is not as simple.

Recall that the Bluetooth standard does not require every device toimplement encryption. If a device in security mode 3 (say A) is tryingto communicate with a peer which implements encryption, then this isnot an issue since the link can be secured.

However, if A wishes to communicate with a peer which does notimplement encryption (say, B), then we have a problem. How thissituation is to be handled is left to higher layers (in other words,the security policy manager). The security manager may decide not tocommunicate with B, or it may decide to communicate with B withoutusing encryption.

Security mode 2 lies in between modes 1 and 3 and has been designedto offer applications flexibility. Whether or not authentication and/orencryption is used, is left to the decision of the security policymanager. This is achieved by relinquishing control of security use to ahigher layer security manager. In other words, security mode 2 works byusing service level-enabled security. This mode is most useful inscenarios where multiple applications (with different securityrequirements) may run on a single Bluetooth device.

The security manager can then co-ordinate what security policy touse depending on the application which is running. In summary, whetheror not authentication and/or encryption is used in a Bluetoothcommunication link depends on a lot of factors: the security needs ofthe application, the security capabilities of the devices, the securitymode of the device and the security (access) policies. The securitymanager considers all these factors when deciding if (and at whichstage of connection establishment) the device should start using thesecurity procedures.

Key Establishment
Key establishment is probably the most complex part of Bluetoothsecurity. A large part of this complexity is in the key hierarchybecause of the large number of keys involved in the Bluetooth securityprocess. Figure 8.5 below showsa classification of most of the keys involved in the Bluetooth securityprocess.

The key hierarchy in Bluetooth varies a little bit depending onwhether we are dealing with unicast communication (between two devices)or broadcast communication. For the rest of this section we assume thatwe are dealing with unicast communication. Finally, we will point outhow broadcast communication key hierarchy is different from unicast keyhierarchy.

Figure8.5: Bluetooth Key Hierarchy

Pass Key
At the top level is the Pass-Key (PKEY). The PKEY is basically theshared secret between the two communicating devices. There are twotypes of PKEYs : variable PKEYs and fixed PKEYs .Variable PKEYs refer toPKEYs that can be chosen at the time of the “pairing” (the process by which two Bluetooth devicesestablish a shared secret that they can use for securing communication ).This is usually achieved by prompting the user to enter a PKEY duringthe pairing procedure.

Obviously, users of both devices should enter the same PKEY. On theother hand, fixed PKEYs refer to PKEYs that arepreconfigured into theBluetooth device. Again, both the communicating devices should bepreconfigured with the same PKEY. Even though variable PKEYs are moresecure (since the PKEY can be changedon a per-pairing basis ), both variable and fixed PKEYs servespecific purposes.

Consider for example, a scenario where users in a conference roomwish to form a Bluetooth network using their laptops. Such a scenariois well-suited for using variable PKEYs , since each devicehas userinteraction capabilities.

On the other hand, consider the Bluetooth network between theheadset and its cell phone. The Bluetooth headset must use a fixed PKEYsince there is no14 user interaction capability on the headset. (Or rather hardly any. ) TheBluetooth standard also allows the use of higher layerkey-establishment protocols to generate the PKEY and pass it on to theBluetooth stack.

Since the PKEY can come from one of many sources, instead ofspecifying the exact length of the PKEY, the Bluetooth standardspecifies that the PKEY can be as long as 128 bits. This allows fordevices prompting the user for a PKEY to enter a much smaller PKEY (ora PIN) thus making user interaction a little more convenient.

However, using a smaller PKEY has other drawbacks. As we will see inthe next few sections, the PKEY is the starting point for establishingthe Link Key, which in turn forms the basis of all security inBluetooth. To be precise, the PKEY is the shared secret between the twocommunicating endpoints that ensures the Link Key is known only to thecommunicating end-points.

The use of a smaller PKEY means that an attack like the dictionaryattack becomes much easier to launch. In this context, a dictionaryattack involves calculating all the link keys that can be derived fromall possible PKEYs. This list of link keys is maintained in a table andcan then be used against plaintext, ciphertext pairs to determine which link key is being used. (For example AU_RAND, SRES pairs. ) Initialization Key
The next level in the hierarchy is the Initialization Key (IK or KINIT ).The KINIT is a short-lived temporary key that is used (andexists only) during the pairing process when two Bluetooth devicesstart communicating for the first time. The KINIT is derivedusing the E22 algorithm and three inputs: PKEY, IN_RAND and LPKEY .

The PKEY is the pass-key that we just talked about and LPKEY is the length of this pass-key in bytes. Finally, the IN_RAND is a128-bit random number generated by the device. The process of derivingthe IK from these inputs is as follows:

PKEY' = PKEY + padding bits.
L PKEY ' = min(L PKEY + 6, 16).

The need for padding bits stems from the flexibility of allowing thePKEY to be as long as 128 bits but not specifying the exact length ofthe PKEY. The padding shown above is needed to ensure that PKEY isexactly 128 bits and these padding bits come from the claimant'sBD_ADDR, the 48-bit MAC address. (Bluetoothuses the terms claimant and verifier to refer to the two Bluetoothdevices which are involved in the communication. Claimant refers to thedevice which is claiming an identity and verifier refers to the devicewhich verifies this claim. )

Figure8.6: Bluetooth Authentication

Link Key
The next level in the key hierarchy is the Link Key (LK). The link keyis the shared secret established between the two Bluetooth devices whenthe pairing sequence ends.

There are two types of link keys specified by the Bluetoothstandard: the unit key and the combination key. The use of unit key hasnow been deprecated because of the security loopholes that result fromits use. We therefore concentrate only on the combination link keyshere. The terms link key and combination key from now on are usedinterchangeably throughout the text to refer to the same key.

The combination/ link key is derived either from the existing linkkey (if such a key exists ) orthe initialization key, KINIT (if no link key exists between the twodevices ). We will see how the combination link key is generatedbut note that we talk about generating a link key from the existinglink key! What does this mean?

Consider two devices which establish a combination/link key andcommunicate securely for a while. When the communication is terminated,what should the two devices do with the link key which they used forthis session?

One approach is to discard these keys. This approach requires thatevery time these two devices want to establish a Bluetooth session,they must generate the link key from scratch.

Even though cryptographically this is a more pure approach, in theinterest of efficiency Bluetooth allows devices to store the link keysthat they generate in nonvolatile memory and reuse this link key forfuture communications with the same device. In other words, unlike theinitialization key, the link key is a semi-permanent key.

Therefore, each device may maintain a database of remote_device_address,link_key pairs for the link keys it wishes to reuse. (The decision whether or not to store aparticular link key in the database may be left to the user. )

Such an approach is specially suited to devices which repeatedlyconnect to a small fixed set of devices for example the Bluetoothheadset which usually connects to its cell phone. Note that justbecause devices can reuse link keys does not mean that they shouldnever change the link key.

Periodically changing the link key is a recommended practice since,as we know by now, the more a key is used or exposed, the more it isvulnerable to compromise. It is in these scenarios that a link key isused to generate another link key.

In other scenarios where two devices do not already have a link keyshared between them, the KINIT is used to generate the linkkey. In summary, the end of the pairing process in Bluetooth shouldlead to the establishment of a link key which the two devices can usefor securing their communication. This link key (combination key) cancome from three sources:

1. Use anexisting link key that the two devices had established previously.

2. Use anexisting link key to generate a fresh link key.

3. Use theinitialization key, KINIT to generate a link key.

The process of generating the link key is as follows. We start witheither the existing link key or the KINIT depending on thecontext. Let us call this starting key KSTART . (Therefore, K Start = LK or K INIT )

The most important property to remember about KSTART isthat it is shared secretly between the two communicating devices; thatis, it is known only to the two communicating devices.

Now, each of the communicating devices (say A and B) generate aprivate key using the E21 algorithm, their BD_ADDR and aself-generated random number (LK_RAND). Therefore,

K A = E 21 (LK_RAND A ,BD_ADDR A )
K B = E 21 (LK_RAND B ,BD_ADDR B )

The combination Link Key is simply the XOR of KA and KB .However, the process of establishing the Link Key is not yet completesince KA is available only at A and KB isavailable only at B. What is needed is a way for B to be able togenerate KA and for A to be able to generate KB .

Figure8.7: Bluetooth Key Establishment

To be able to generate KB , A needs to know LK_RANDB and BD_ADDRB . Arguably, A already knows BD_ADDRB since it is going to communicate with it. So, what is needed is asecure way to get LK_ADDRB from B to A. Here is where KSTART comes in. B XORs LK_ADDRB with KSTART and sendsit to A. Since KSTART is a shared secret known only to A andB, we are assured that this transmission of LK_ADDRB issecure.

Once A gets to know LK_ADDRB , A can generate KB too. Following the exact same procedure, B can generate KA too. At this point both A and B have calculated KA and KB and can therefore easily calculate the combination link key as KA XORKB .

Note from Figure 8.7 above that after the establishment of the new combination link key, KSTART is deleted by both endpoints since the new combination link key shouldbe used from now on.Encryption Key
The combination link key is used in the authentication process. Thelink key is also used for generating the ciphering key (CK or KC )which is the next key in the key hierarchy. The KC isderived from the link key using the E3 algorithm as follows:


The link key is denoted by K. EN_RAND refers to a 128-bit randomnumber and COF refers to a 96-bit Ciphering Offset. The value of COF isequal to the value of the Authentication Ciphering Offset (ACO), whichis derived from the authentication process.

Constraint Key
The next step in the key hierarchy is the constraint key (KC '),a.k.a. the constraint encryption key. The reason for the existence ofthis key is export restrictions. Many countries impose restrictions onthe export of encryption hardware.

Specifically, hardware which is capable of encrypting above certainkey strengths is not exportable. For this purpose, Bluetooth put in akey strength constraining mechanism that reduces the 128-bit KC to a 128-bit KC ' whose effective key length (key strength)can be any value less than 128 bits.

The derivation of KC ' from KC is achieved inhardware using linear feedback and feed forward registers and can begiven as:

K C'(x)= g 2 L (x){KC [mod g1 L (x)]}

Where L is the desired effective length and g1 and g2 are two polynomials specified by the Bluetooth standard.

Payload Key
Finally, the Payload Key (PK ) is the actual key that is usedto encrypt (decrypt) Bluetooth packets. Therefore, PK isderived from the Constraint Key KC ' using the E0 algorithm as follows:


Where BD_ADDR is the 48-bit Bluetooth (read MAC) address of thedevice, EN_RAND is a 128-bit random number and CK_VAL is the 26 bits ofthe current clock value (bits 1″26 of the master's native clock).

Broadcast Key Hierarchy
All our discussion regarding Bluetooth key hierarchy has assumed thatthe Bluetooth communication is between two devices (a master and aslave). However, the Bluetooth standard also supports broadcastcommunication where a master may broadcast data to all its slaves.

Realize that a broadcast transmission is different from multipleunicast transmissions. In a broadcast transmission, the master sendsout a message to a special broadcast address and all slaves in thepiconet accept this message. In the latter case, a master sends outmultiple copies of a message to each slave individually. Here we willtalk about broadcast in the former sense.

Recall that the (combination) link key in unicast communication in apiconet was generated using the addresses and random numbers from bothendpoints involved in the communication. In broadcast communication,this becomes a dilemma since communication is not between twoendpoints. Therefore, the link key is replaced by the use of a MasterKey (Kmaster).

The master key is derived independently by the master withoutinvolving any of the slaves. This is done using the E22 algorithmas follows:

K master= E 22 (LK_RAND1, LK_RAND2, 16)

Since the master key is derived only at the master, we need a way tocommunicate the Kmaster to all the slaves in the piconet securely. Thisis done using the Overlay Key, Kovl. The overlay key is derived fromthe current link key as follows:

K overlay = E22 (K, RAND3, 16)

Since the master and each of the slaves in a Bluetooth piconet sharea link key, the overlay key can be securely established between themaster and each of the slaves. This overlay key can then be used forconveying the master key to each of the slaves. Finally, the master keyis used for securing broadcast communication in a piconet.

Note that unlike the link key which is a semi-permanent key (stored in nonvolatile memory for future use),the master key is a temporary key which is never stored in nonvolatilememory (and never re-used ).The Algorithms
The key hierarchy that we have discussed uses five algorithms: E0 ,E1 , E3 , E21 and E22 . Ofthese five algorithms, four (E1 , E3 , E21 and E22 ) are based on a blockcipher and one on a stream cipher (E0 ). The discussion of E0 as astream cipher is postponed until later where we see how Bluetoothpackets are encrypted.

To understand the use of the block cipher for four of thesealgorithms, recall that all keys in Bluetooth have a length of 128bits. Using a 128-bit block cipher in key derivation means that we canfeed one key directly as input into the block cipher to generate thekey of the next level in the hierarchy. All these four algorithms usethe same underlying block cipher: SAFER+.

At the time the Bluetooth standard was being ratified, the NationalInstitute of Standards and Technology (NIST) was considering contendersfor the Advanced Encryption Standard (AES). SAFER+ was one of thestrong contenders for AES which had been very thoroughly cryptanalyzed.

Bluetooth therefore chose SAFER+ as the block cipher to be used forthe implementation of E1 , E3 , E21 and E22 .The details of thisalgorithm are not discussed here for reasons of brevity and theinterested reader is referred to the Bluetooth standards.

The authentication process always involves two endpoints: the claimant(which claims a certain identity) and the verifier (which wishes toverify that the claimant is actually the identity it is claming to be).In the Bluetooth piconet context, the roles of claimant and verifierare orthogonal to the rule of the master and the slave. In other words,either the master or the slave can act as the verifier.

Who is the verifier depends on higher layers. The application or theuser who wishes to ensure the identity of the remote end (and whotherefore starts the authentication process) takes on the role of theverifier. For mutual authentication, both end-points take on the roleof the verifier one at a time. Figure8.8 below shows a mutual authenticationprocess in Bluetooth.

Figure8.8: Bluetooth Mutual Authentication

The authentication process in Bluetooth is basically achallenge-response protocol which is carried out using the existinglink key. Consider a device (claimant) which initiates communicationwith A claiming to be B. A wishes to verify that the claimant is infact B.

To verify this A sends the claimant a random number, AU_RAND. Onreceiving this, the claimant is expected to send back a signed responseSRES calculated using the E1 algorithm as follows:


<>Since the AU_RAND and BD_ADDRB may easily be knownpublicly, thesecurity lies in K, the link key. The underlying assumption of theBluetooth authentication process is that the link key is known only tothe two endpoints which established it. Since only B knows the correctK which it establishedwith A, only B would be able to generate the correct SRES. So, all Aneeds to verify the identity of the claimant is to ensurethat the response sent back by the claimant is equal to SRES.

As Figure 8.8 above shows,mutual authentication can also be carriedout in Bluetooth with B now taking on the role of a verifier. B sendsout a challenge to A and carries on the authentication process toverify the identity of A.

The E1 algorithm used for generating the SRES in theauthenticationprocess also produces a 96-bit Authentication Ciphering Offset (ACO) asan output. As we saw in Section, this ACO is used forgenerating the ciphering key, KC .

It is this ACO which “links” the authentication process to the restof the session. In other words, the ACO serves to link the securitycontext established by the authentication process to the rest of thesession. Note that if mutual authentication is desired, first A acts asthe verifier and B as the claimant.

Next, the roles are swapped with B acting as the verifier and A asthe claimant. Therefore, in mutual authentication, there would be twoACOs that would be produced: one from each authentication process. Insuch a scenario, the standard specifies that the ACO from the latterauthentication process be used for generating the encryption key.Therefore, the security context is linked to the last authenticationprocess that is carried out.Confidentiality
As we discussed earlier, the payload key PK , which is usedforencrypting outgoing messages is derived using the E0 algorithm. The E0 algorithm is basically a stream cipher which generates a key stream.

Figure8.9: Bluetooth Encryption

This key stream is then XORed with the plaintext of the messages tocreate the ciphertext. The design of the E0 stream cipher is not basedon any existing stream cipher but is a proprietary algorithm specifiedby the Bluetooth standard.

Figure 8.9 above shows theencryption process in Bluetooth networks.From earlier we know that PK is derived from the Constraint Key KC'using the E0 algorithm as follows:


Where BD_ADDR is the 48-bit Bluetooth address of the device, EN_RANDis a 128-bit random number and CK_VAL is the 26 bits of the currentclock value (bits 1″26 of the master's native clock). Next, this PK isfed into the key stream generator. This key stream generator thenproduces a key stream which is XORed with the plaintext to produce theciphertext. There are a few important things to note about theencryption process in Bluetooth:

Figure8.10: Bluetooth Packet Format

First, not all bits of the Bluetooth packet are encrypted. Figure8.10 above shows the format of a Bluetooth packet. It consistsof an accesscode followed by a header and finally the payload. The access code isderived from the BD_ADDR of the master of the piconet and since everypiconet has a unique master, the access code uniquely identifies apiconet. The access code is therefore used by the devices in a piconetto determine if a packet is for another piconet, in which case thepacket is discarded.

The access code also defines where a slot boundary lies and istherefore also used by the slaves in a piconet to synchronize theirclocks to the master's clock. It is therefore not a surprise that theaccess code in Bluetooth packets is not encrypted. Next, the header inthe Bluetooth packet is also not encrypted.

The reason for this is also pretty obvious when you consider thatthe header contains the address of the destination device. Thisinformation is obviously needed by all devices in the piconet todetermine whether or not a particular packet is intended for it or not.Therefore, the bottom line is that only the payload in the Bluetoothpacket is encrypted.

Second, as shown in Figure 8.9 ,the CRC is appended to the packetbefore it is encrypted. In other words, the CRC along with the payloadis also encrypted. Third, realize that using a stream cipher in awireless medium is a security loophole.

Just like WEP tries to overcome the drawbacks of using a streamcipher by changing the key for each packet, Bluetooth uses the sameapproach: the PK is derived for each Bluetooth packet. (Multislotpackets do not require a change of the payload key when passing a slotboundary within a packet. )

However, unlike WEP where the per-packet key is calculated simplyby prepending the IV with the master key, the derivation of theper-packet key in Bluetooth is much more cryptographically involved,thus making Bluetooth encryption more secure than WEP. Let us take acloser look at Figure 8.9 .

As Figure 8.9 shows, theencryption process in Bluetooth can beseparated into three distinct blocks. The first block consists ofderiving the payload key, PK . We saw at the beginning ofthis sectionhow this is achieved. This PK feeds into the second blockand acts asthe initialization seed to a key stream generator. In other words, PK is used to initialize the key stream generator.

The key stream generated from the second block feeds into the thirdblock which is nothing but a simple XOR operation between this keystream and the payload of the Bluetooth packet. (Along with the CRC. )

Finally, realize that to change the PK on a per-packetbasis, weneed a variable which changes on a per-packet basis. One of the inputsrequired for generating the payload key, PK is CK_VAL, thelower 26bits of the master clock.

Since the lowest bit of the master clock (and hence the CK_VAL)changes every 625 microseconds, this means the value of the PK can bederived afresh every 625 microseconds. However initializing the keystream generator with PK takes some time. This is whereguard spacecomes in.

Figure8.11: Bluetooth Stream Cipher Periodicity

The Bluetooth standard specifies a guard space between the end ofthe payload in one packet and the start of the next packet. This guardspace must be at least 259 microseconds, which is enough time for thekey stream generator to be initialized. The overall timing sequence isas shown in Figure 8.11 above where”running the stream cipher” and”initializing key stream generator” slots alternate.

Integrity Protection
The Bluetooth standard relies on a cyclic redundancy check (CRC) toprovide message integrity. WEP also uses CRC for providing messageintegrity. Considering the loopholes of this approach, usng a linearnoncryptographic integrity check mechanism like CRC leaves a lot to bedesired as far as integrity protection is concerned. Just encryptiondoes not automatically provide integrity.

In other words, just because a message is encrypted does not meanthat it can't be modified in-transit without the receiver's knowledge.The bottom line is that by choosing CRC, Bluetooth fails to provide anyreal integrity protection. (That is,any strong enough .)

As we said at the beginning of series, ad hoc networking technologyis still in its nascent stage. There are many issues to be resolved andsecurity is such an issue. The Bluetooth standard is also expected toevolve as ad hoc networking technology evolves.

(Editor's note: For more onembedded security, check out the cover story in the Octoberissue of Embedded Systems Design Magazine: Embedded systems security has moved to theforefront,” as well as “ Employ a secure flavorof Linux.”

To read Part 1, go to “Routing inmultihop ad hoc networks.”
To read Part 2, go to “Keyestablishment and authentication.”

Thisarticle is excerpted from “Bulletproofwireless security,” by Praphul Chandra, with permission fromElsevier/Newnes which hold the copyright. It is a part of thepublisher's Communications Engineering Series and can be purchased online.

Praphul Chandra currently works asa senior research scientist at HPLabs, India, which focuses on “technological innovation foremerging countries.”

Recent articles on security
Securingwireless MCUs is changing embedded systems design
Stateof security technology: embedded to enterprise
Securiingmobile and embedded devices: encryptioon is not security
Guidelinesfor designing secure PCI PED EFT terminals
Overcomingsecurity issues in embedded systems
Buildingmiddleware for security and safety-critical applications
Securityconsiderations for embedded operating systems
Diversityprotects embedded systems
Aproactive strategy for eliminating embedded software vulnerabilities
Understandingelliptic curve cryptography
Securingad hoc embedded wireless networks with public key cryptography

Aframework for considering security in embedded systems
Calculatingthe exploitability of your embedded software
Badassumptions lead to bad security

Securingembedded systems for networks
Implementingsolid security on a Bluetooth product
Smartsecurity improves battery life
Howto establish mobile security
Ensuringstrong security for mobile transactions
Securingan 802.11 network

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.