Chapter 19. Security in Wireless Ad Hoc Networks

19.1. Introduction

The term ad hoc networks refers to networks formed on-the-fly (ad hoc), in other words on an as-needed basis.

The term ad hoc wireless networks refers to those ad hoc networks which use a wireless medium for communication. Since a wired ad hoc network would be synonymous with a LAN, the term ad hoc networks almost always means ad hoc wireless networks and the two terms are used interchangeably throughout this text.

The term mobile ad hoc networks (MANETs) refers to ad hoc networks in which the nodes forming the ad hoc network are mobile. Most ad hoc networks allow their nodes to be mobile and are therefore MANETs.

In other words, these networks are formed on an as-needed basis and do not require the existence of any infrastructure. This property makes ad hoc wireless networks suitable for use in various scenarios like disaster recovery, enemy battlefields or in areas where user density is too sparse or too rare to justify the deployment of network infrastructure economically. Figure 19.1 shows some examples of ad hoc wireless networks.

Figure 19.1. Examples of ad hoc networks

The scenarios and examples shown in Figure 19.1 present a small subset of scenarios where ad hoc networks may be useful. An ad hoc network may operate in a standalone fashion or may be connected to a larger network like the Internet. Since ad hoc networks have such varied areas of use, it is instructive to classify them based on certain features.

First, ad hoc networks may be classified on the basis of their geographical coverage. Therefore we have ad hoc personal area networks (PANs), ad hoc local area networks (LANs) and ad hoc wide area networks (WANs).

Second, ad hoc networks may be classified based on whether or not nodes in the network are capable of acting as routers. To understand this classification, realize that the wireless networks that we have looked at till now in this book always used the fixed, static, wired infrastructure for routing. In TWNs, call routing was achieved by dedicated routing switches of the PSTN and the core GSM network (which consisted of MSCs and GMSCs). Furthermore, since both the PSTN and the core GSM network are wired networks which are static (that is, their network topology almost never changes), it is relatively easy to proactively distribute the network topology information to the routing switches. This in turn allows each routing switch to precompute and maintain routes to other switches, thus facilitating routing. Similarly, in wireless local area networks (WLANs), packet routing is achieved by using Layer 2 switches and IP routers. Again, since these routing devices are connected by a wired infrastructure and are static, it is relatively easy to proactively distribute the network topology information to the routers and switches.

Ad hoc networks have two major limitations: (a) there are no dedicated routing devices (since there is no infrastructure available) and (b) the network topology may change rapidly and unpredictably as nodes move. In the absence of any routing infrastructure, the nodes forming the ad hoc networks themselves have to act as routers. A MANET may therefore be defined as an autonomous system of mobile routers (and associated hosts) connected by wireless links—the union of which forms an arbitrary graph. Given the central importance of routing in ad hoc networks, it is not surprising that routing forms a basis for classifying ad hoc networks into two groups: single-hop ad hoc networks and multihop ad hoc networks. Single-hop ad hoc networks are ad hoc networks where nodes do not act as routers and therefore communication is possible only between nodes which are within each other’s radio frequency (RF) range. On the other hand, multihop ad hoc networks are ad hoc networks where nodes are willing to act as routers and route or forward the traffic of other nodes.

If you look at the basis for two classifications closely that—is, the geographical coverage and the routing capability of nodes—the two classifications are not completely orthogonal. Ad hoc PANs are more likely to be single hop ad hoc networks since nodes would be close enough to be within each other’s RF range. On the other hand, ad hoc LANs and ad hoc WANs are more likely to require nodes to have routing capability and therefore form multihop networks.

Multihop ad hoc networks and their security is an active area of research as of the writing of this chapter. In the next section we look at some of the emerging security concepts (and areas of active research) in multihop ad hoc networks. Single-hop ad hoc networks are now being used commercially and one of the most popular single-hop ad hoc wireless standard is Bluetooth. We look more closely at Bluetooth and how it implements security in the next section.

19.2. Bluetooth

One of the most popular ad hoc standards today is Bluetooth. Some of the salient features of Bluetooth are as follows:

• Wireless ad hoc networking technology.
• Operates in the unlicensed 2.4 GHz frequency range.
• Geographical coverage limited to personal area networks (PAN).
• Point-to-point and point-to-multipoint links.
• Supports synchronous and asynchronous traffic.
• Concentrates on single-hop networks.
• Frequency hopping spread spectrum (FHSS) with Gaussian frequency shift keying (GFSK) modulation at the physical layer.
• Low power and low cost given important consideration.
• Adopted as the IEEE 802.15.1 standard for physical layer (PHY) and media access control (MAC) layers.

The Bluetooth standard limits its scope by dealing only with single-hop ad hoc networks with limited geographical coverage (PAN). In the previous sections we saw that multihop ad hoc networks present a unique set of challenges which are still an active area of research. The Bluetooth standard brings ad hoc networks to the commercial forefront by concentrating on single-hop PAN ad hoc networks. Removing the multihop feature from ad hoc networks makes things a lot simpler.

The Bluetooth Special Interest Group (SIG) was founded in 1998 with the aim of developing Bluetooth as a short-range wireless inter-connectivity standard.^[1] In other words, Bluetooth deals with ad hoc networks whose geographical coverage is limited to PAN. Typical applications of Bluetooth today include connecting a wireless headset with its cell phone, interconnecting the various components (keyboard, mouse, monitor, and so on) of a PC, and so on.

¹ The Bluetooth standard is also being accepted as the IEEE 802.15 standard.

Before we get into the details of Bluetooth and its security, it is important to emphasize that Bluetooth is by no means the only ad hoc network standard. Another popular ad hoc standard is 802.11 in its IBSS mode.

Since Bluetooth networks have been so commercially successful, we briefly look at Bluetooth security in this section.

19.2.1. Bluetooth Basics

A typical Bluetooth network, called the piconet, is shown in Figure 19.2. Each piconet has one master and can have up to seven slaves.^[2] Therefore, there can be at most eight devices in a piconet. A slave can communicate only with the master and a master can obviously communicate with any of the slaves. If two slaves wish to communicate with each other, the master should relay this traffic. In effect, therefore, we have a logical star topology in a piconet, with the master device at the center.

² To be precise, a piconet has one master and up to seven active slaves. There is no limit on the number of slaves in a piconet which are in “park” or “hold” state. This distinction is irrelevant from a security perspective however.

Figure 19.2. Bluetooth networks

Comparing the piconet to a 802.11 network, the piconet is the equivalent of a BSS (though with a much smaller geographical coverage), the master device is the equivalent of the AP (except that it is not connected to any distribution system) and the slave devices are the equivalent of the Stations (STAs).

A Bluetooth device may participate in more than one piconet simultaneously, as shown in Figure 19.3. In such a scenario, it is possible for the devices in two piconets to communicate with each other by having the common node act as the bridge and relay the inter-piconet traffic. The two piconets are now joined together and form a scatternet. Even though scatternets are theoretically possible, they are rare in commercial deployments since they pose tough practical problems like routing and timing issues. The Bluetooth standard concentrates mostly on single-hop piconets and we limit our discussion to piconet security. Scatternets (and their security) are an active area of research and involve a lot of the security issues that we discussed earlier.

Figure 19.3. Piconets and scatternets in Bluetooth

19.2.2. Security Modes

Just like IEEE 802.11 standard, the Bluetooth standard also defines Layer 1 and Layer 2 of the OSI stack to achieve communication in single-hop personal-area ad hoc networks. However, by their very nature, ad hoc networks (Bluetooth) are a much less controlled environment than WLANs (802.11). This, combined with the fact that the Bluetooth standard may be used by a wide range of applications in many different ways, makes interoperability a much bigger challenge in Bluetooth networks. To ease the problem of interoperability, the Bluetooth SIG defined application profiles. A profile defines an unambiguous description of the communication interface between two Bluetooth devices or one particular service or application.

There are basic profiles which define the fundamental procedures for Bluetooth connection and there are special profiles defined for distinct services and applications. New profiles can be built using existing profiles, thus allowing for a hierarchical profile structure as shown in Figure 19.4.

Figure 19.4. Profiles in Bluetooth

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

Before we discuss the different security modes, it is important to keep a few things in mind. First, the security mechanisms (authentication and encryption) specified by the Bluetooth standard are implemented at the link layer (Layer 2). This means that the scope of Bluetooth security is the Layer 2 level link between two nodes separated by a single hop. To be explicit, Bluetooth security does not deal with end-to-end security^[3] and does not deal with application layer security. If such security mechanisms are required, they have to be arranged for outside the scope of the Bluetooth standard.

³ The source and destination nodes may be more than one hop away as in a scatternet.

Second, all Bluetooth devices must implement an authentication procedure: that is a requirement.^[4] Bluetooth devices may or may not implement encryption procedures: that is optional. However, just because a device implements or supports authentication and/or encryption, does not mean that this device would use these security features in a connection. What security features are used for a Bluetooth connection depends on the security modes of the master and the slave in the connection. Table 19.1 summarizes what security features are used in a Bluetooth connection depending on the security mode of the master and the slave.

⁴ On the other hand, implementing encryption procedures is optional.

Table 19.1. Security features of Bluetooth connection

Security Master Slave	1	2	3
1	Authentication=No;	Authentication=if the master app. demands it;	Authentication=Yes;
	Encryption=No;	Encryption=if the master app. demands it;	Encryption=if the master policy demands it.
2	Authentication=if the slave app. demands it.	Authentication=if the master or the slave app. demands it;	Authentication=Yes;
	Encryption=if the slave app. demands it.	Encryption=if the master or the slave app. demands it;	Encryption=if the master policy or if the slave app. demands it.
3	Authentication=Yes.	Authentication=Yes.	Authentication=Yes.
	Encryption=if the slave policy demands it;	Encryption=if the slave policy or if the master app. demands it.	Encryption=if the master or the slave policy demands it;

Security mode 1 is the unsecured mode in Bluetooth. A device using this mode does not demand authentication or encryption from its peer at connection establishment. This means that a device in security mode 1 offers its services to all devices which wish to connect to it. However, if the communicating peer device (say B) wishes to authenticate a node which is using security mode 1 (say A), then A must respond to the challenge that B sends since A as a Bluetooth device must support authentication. Similarly, if B wishes to use encryption on its link with A, then A must turn on its encryption if it supports it.

On the other end of the spectrum is security mode 3 which is the always-on security mode in Bluetooth. A device which is in security mode 3 shall always initiate an authentication procedure. This means that this device will not communicate with a device unless it can authenticate it. The encryption part in security mode 3 is not as simple. Recall that the Bluetooth standard does not require every device to implement encryption. If a device in security mode 3 (say A) is trying to communicate with a peer which implements encryption, then this is not an issue since the link can be secured. However, if A wishes to communicate with a peer which does not implement encryption (say, B), then we have a problem. How this situation is to be handled is left to higher layers (in other words, the security policy manager). The security manager may decide not to communicate with B, or it may decide to communicate with B without using encryption.

Security mode 2 lies in between modes 1 and 3 and has been designed to offer applications flexibility. Whether or not authentication and/or encryption is used, is left to the decision of the security policy manager. This is achieved by relinquishing control of security use to a higher layer security manager. In other words, security mode 2 works by using service level-enabled security. This mode is most useful in scenarios where multiple applications (with different security requirements) may run on a single Bluetooth device. The security manager can then co-ordinate what security policy to use depending on the application which is running.

In summary, whether or not authentication and/or encryption is used in a Bluetooth communication link depends on a lot of factors: the security needs of the application, the security capabilities of the devices, the security mode of the device and the security (access) policies. The security manager considers all these factors when deciding if (and at which stage of connection establishment) the device should start using the security procedures.

19.2.3. Key Establishment

Key establishment is probably the most complex part of Bluetooth security. A large part of this complexity is in the key hierarchy because of the large number of keys involved in the Bluetooth security process. Figure 19.5 shows a classification of most of the keys involved in the Bluetooth security process. The key hierarchy in Bluetooth varies a little bit depending on whether we are dealing with unicast communication (between two devices) or broadcast communication. For the rest of this section we assume that we are dealing with unicast communication. Finally, in Section 19.2.3.7 we will point out how broadcast communication key hierarchy is different from unicast key hierarchy.

Figure 19.5. Bluetooth key hierarchy

19.2.3.1. Pass Key

At the top level is the Pass Key (PKEY). The PKEY is basically the shared secret between the two communicating devices. There are two types of PKEYs: variable PKEYs and fixed PKEYs. Variable PKEYs refer to PKEYs that can be chosen at the time of the “pairing” (the process by which two Bluetooth devices establish a shared secret that they can use for securing communication). This is usually achieved by prompting the user to enter a PKEY during the pairing procedure. Obviously, users of both devices should enter the same PKEY. On the other hand, fixed PKEYs refer to PKEYs that are preconfigured into the Bluetooth device. Again, both the communicating devices should be preconfigured with the same PKEY. Even though variable PKEYs are more secure (since the PKEY can be changed on a per-pairing basis), both variable and fixed PKEYs serve specific purposes. Consider for example, a scenario where users in a conference room wish to form a Bluetooth network using their laptops. Such a scenario is well-suited for using variable PKEYs, since each device has user interaction capabilities. On the other hand, consider the Bluetooth network between the headset and its cell phone. The Bluetooth headset must use a fixed PKEY since there is no^[5] user interaction capability on the headset. The Bluetooth standard also allows the use of higher layer key-establishment protocols to generate the PKEY and pass it on to the Bluetooth stack.

⁵ Or rather hardly any.

Since the PKEY can come from one of many sources, instead of specifying the exact length of the PKEY, the Bluetooth standard specifies that the PKEY can be as long as 128 bits. This allows for devices prompting the user for a PKEY to enter a much smaller PKEY (or a PIN) thus making user interaction a little more convenient. However, using a smaller PKEY has other drawbacks. As we will see in the next few sections, the PKEY is the starting point for establishing the Link Key, which in turn forms the basis of all security in Bluetooth. To be precise, the PKEY is the shared secret between the two communicating endpoints that ensures the Link Key is known only to the communicating end-points. The use of a smaller PKEY means that an attack like the dictionary attack becomes much easier to launch. In this context, a dictionary attack involves calculating all the link keys that can be derived from all possible PKEYs. This list of link keys is maintained in a table and can then be used against <plaintext, ciphertext pairs>^[6] to determine which link key is being used.

⁶ For example AU_RAND, SRES pairs.

19.2.3.2. Initialization Key

The next level in the hierarchy is the Initialization Key (IK or K^INIT). The K^INIT is a short-lived temporary key that is used (and exists only) during the pairing process when two Bluetooth devices start communicating for the first time. The K^INIT is derived using the E²² algorithm and three inputs: PKEY, IN_RAND and L^PKEY. The PKEY is the pass-key that we just talked about and L^PKEY is the length of this pass-key in bytes. Finally, the IN_RAND is a 128-bit random number generated by the device. The process of deriving the IK from these inputs is as follows:

Figure 19.6. Bluetooth authentication

The need for padding bits stems from the flexibility of allowing the PKEY to be as long as 128 bits but not specifying the exact length of the PKEY. The padding shown above is needed to ensure that PKEY is exactly 128 bits and these padding bits come from the claimant’s^[7] BD_ADDR (the 48-bit MAC address).

⁷ Bluetooth uses the terms claimant and verifier to refer to the two Bluetooth devices which are involved in the communication. Claimant refers to the device which is claiming an identity and verifier refers to the device which verifies this claim.

19.2.3.3. Link Key

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

There are two types of link keys specified by the Bluetooth standard: the unit key and the combination key. The use of unit key has now been deprecated because of the security loopholes that result from its use. We therefore concentrate only on the combination link keys here. The terms link key and combination key from now on are used interchangeably throughout the text to refer to the same key. The combination/link key is derived either from the existing link key (if such a key exists) or the initialization key, K^INIT (if no link key exists between the two devices). We will see how the combination link key is generated but note that we talk about generating a link key from the existing link key! What does this mean?

Consider two devices which establish a combination/link key and communicate securely for a while. When the communication is terminated, what should the two devices do with the link key which they used for this session? One approach is to discard these keys. This approach requires that every 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 the interest of efficiency Bluetooth allows devices to store the link keys that they generate in nonvolatile memory and reuse this link key for future communications with the same device. In other words, unlike the initialization key, the link key is a semi-permanent key. Therefore, each device may^[8] maintain a database of <remote_device_address, link_key> pairs for the link keys it wishes to reuse. Such an approach is specially suited to devices which repeatedly connect to a small fixed set of devices for example the Bluetooth headset which usually connects to its cell phone.

⁸ The decision whether or not to store a particular link key in the database may be left to the user.

Note that just because devices can reuse link keys does not mean that they should never 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 is vulnerable to compromise. It is in these scenarios that a link key is used to generate another link key. In other scenarios where two devices do not already have a link key shared between them, the K^INIT is used to generate the link key. In summary, the end of the pairing process in Bluetooth should lead to the establishment of a link key which the two devices can use for securing their communication. This link key (combination key) can come from three sources:

1. Use an existing link key that the two devices had established previously.
2. Use an existing link key to generate a fresh link key.
3. Use the initialization key, K^INIT, to generate a link key.

The process of generating the link key is as follows. We start with either the existing link key or the K^INIT depending on the context. Let us call this starting key K^START.^[9] The most important property to remember about K^START is that it is shared secretly between the two communicating devices; that is, it is known only to the two communicating devices. Now, each of the communicating devices (say A and B) generate a private key using the E²¹ algorithm, their BD_ADDR and a self-generated random number (LK_RAND). Therefore,

⁹ Therefore K^START = LK or K^INIT.

The combination link key is simply the XOR of K^A and K^B. However, the process of establishing the link key is not yet complete since K^A is available only at A and K^B is available only at B. What is needed is a way for B to be able to generate K^A and for A to be able to generate K^B.

To be able to generate KB, A needs to know LK_RAND^B and BD_ADDR^B. Arguably, A already knows BD_ADDR^B since it is going to communicate with it. So, what is needed is a secure way to get LK_ADDR^B from B to A. Here is where K^START comes in. B XORs LK_ADDR^B with K^START and sends it to A. Since K^START is a shared secret known only to A and B, we are assured that this transmission of LK_ADDR^B is secure. Once A gets to know LK_ADDR^B, A can generate K^B too. Following the exact same procedure, B can generate K^A too. At this point both A and B have calculated K^A and K^B and can therefore easily calculate the combination link key as K^A XOR K^B.

Note from Figure 19.7 that after the establishment of the new combination link key K^START is deleted by both endpoints since the new combination link key should be used from now on.

Figure 19.7. Bluetooth key establishment

19.2.3.4. Encryption Key

The combination link key is used in the authentication process (see Section 19.2.4) as we will see in the next section. The link key is also used for generating the ciphering key (CK or K^C) which is the next key in the key hierarchy. The K^C is derived from the link key using the E3 algorithm as follows:-

The link key is denoted by K. EN_RAND refers to a 128-bit random number and COF refers to a 96-bit Ciphering Offset. The value of COF is equal to the value of the Authentication Ciphering Offset (ACO), which is derived from the authentication process. (See Section 19.2.4 for details on this.)

19.2.3.5. Constraint Key

The next step in the key hierarchy is the constraint key (K^C’), a.k.a. the constraint encryption key. The reason for the existence of this key is export restrictions. Many countries impose restrictions on the export of encryption hardware. Specifically, hardware which is capable of encrypting above certain key strengths is not exportable. For this purpose, Bluetooth put in a key strength constraining mechanism that reduces the 128-bit K^C to a 128-bit K^C’ whose effective key length (key strength) can be any value less than 128 bits. The derivation of K^C’ from K^C is achieved in hardware using linear feedback and feed forward registers and can be given as:

where L is the desired effective length and g¹ and g² are two polynomials specified by the Bluetooth standard.

19.2.3.6. Payload Key

Finally, the payload key (P^K) is the actual key that is used to encrypt (decrypt) Bluetooth packets. Therefore, P^K is derived from the Constraint Key K^C’ using the E⁰ algorithm as follows:

where BD_ADDR is the 48-bit Bluetooth (read MAC) address of the device, EN_RAND is a 128-bit random number and CK_VAL is the 26 bits of the current clock value (bits 1–26 of the master’s native clock).

19.2.3.7. Broadcast Key Hierarchy

All our discussion regarding Bluetooth key hierarchy has assumed that the Bluetooth communication is between two devices (a master and a slave). However, the Bluetooth standard also supports broadcast communication where a master may broadcast data to all its slaves. Realize that a broadcast transmission is different from multiple unicast transmissions. In a broadcast transmission, the master sends out a message to a special broadcast address and all slaves in the piconet accept this message. In the latter case, a master sends out multiple copies of a message to each slave individually. In this section, we talk about broadcast in the former sense.

Recall from Section 19.2.3.3 that the (combination) link key in unicast communication in a piconet was generated using the addresses and random numbers from both endpoints involved in the communication. In broadcast communication, this becomes a dilemma since communication is not between two endpoints. Therefore, the link key is replaced by the use of a master key (K^master). The master key is derived independently by the master without involving any of the slaves. This is done using the E²² algorithm as follows:

Since the master key is derived only at the master, we need a way to communicate the K^master to all the slaves in the piconet securely. This is done using the overlay key, K^ovl. The overlay key is derived from the current link key as follows:

Since the master and each of the slaves in a Bluetooth piconet share a link key, the overlay key can be securely established between the master and each of the slaves. This overlay key can then be used for conveying the master key to each of the slaves. Finally, the master key is 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 nonvolatile memory (and never re-used).

19.2.3.8. The Algorithms

The key hierarchy that we have discussed in the previous sections uses five algorithms: E⁰, E¹, E³, E²¹ and E²². Of these five algorithms, four (E¹, E³, E²¹ and E²²) are based on a block cipher and one on a stream cipher (E⁰). The discussion of E⁰ as a stream cipher is postponed to Section 19.2.5 where we see how Bluetooth packets are encrypted. To understand the use of the block cipher for four of these algorithms, recall that all keys in Bluetooth have a length of 128 bits. Using a 128-bit block cipher in key derivation means that we can feed one key directly as input into the block cipher to generate the key of the next level in the hierarchy. All these four algorithms use the same underlying block cipher: SAFER+.

At the time the Bluetooth standard was being ratified, the National Institute of Standards and Technology (NIST) was considering contenders for the Advanced Encryption Standard (AES). SAFER+ was one of the strong contenders for AES which had been very thoroughly cryptanalyzed. Bluetooth therefore chose SAFER+ as the block cipher to be used for the implementation of E¹, E³, E²¹ and E²². The details of this algorithm are not discussed here for reasons of brevity and the interested reader is referred to the Bluetooth standards.

19.2.4. Authentication

The authentication process always involves two endpoints: the claimant (which claims a certain identity) and the verifier (which wishes to verify that the claimant is actually the identity it is claming to be). In the Bluetooth piconet context, the roles of claimant and verifier are 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 the user who wishes to ensure the identity of the remote end (and who therefore starts the authentication process) takes on the role of the verifier. For mutual authentication, both end-points take on the role of the verifier one at a time. Figure 19.8 shows a mutual authentication process in Bluetooth.

Figure 19.8. Bluetooth mutual authentication

The authentication process in Bluetooth is basically a challenge-response protocol which is carried out using the existing link key. Consider a device (claimant) which initiates communication with A claiming to be B. A wishes to verify that the claimant is in fact B. To verify this A sends the claimant a random number, AU_RAND. On receiving this, the claimant is expected to send back a signed response SRES calculated using the E¹ algorithm as follows:

Since the AU_RAND and BD_ADDR^B may easily be known publicly, the security lies in K, the link key. The underlying assumption of the Bluetooth authentication process is that the link key is known only to the two endpoints which established it (see Section 19.2.3.3 on how this is achieved). Since only B knows the correct K which it established with A, only B would be able to generate the correct SRES. So, all A needs to verify the identity of the claimant is to ensure that the response sent back by the claimant is equal to SRES.

As Figure 19.8 shows, mutual authentication can also be carried out in Bluetooth with B now taking on the role of a verifier. B sends out a challenge to A and carries on the authentication process to verify the identity of A. The E¹ algorithm used for generating the SRES in the authentication process also produces a 96-bit Authentication Ciphering Offset (ACO) as an output. As we saw in Section 19.2.3.4, this ACO is used for generating the ciphering key, K^C. It is this ACO which “links” the authentication process to the rest of the session. In other words, the ACO serves to link the security context established by the authentication process to the rest of the session.

Note that if mutual authentication is desired, first A acts as the verifier and B as the claimant. Next, the roles are swapped with B acting as the verifier and A as the claimant. Therefore, in mutual authentication, there would be two ACOs that would be produced: one from each authentication process. In such a scenario, the standard specifies that the ACO from the latter authentication process be used for generating the encryption key. Therefore, the security context is linked to the last authentication process that is carried out.

19.2.5. Confidentiality

As we discussed in Section 19.2.3.6, the payload key P^K, which is used for encrypting outgoing messages is derived using the E⁰ algorithm. The E⁰ algorithm is basically a stream cipher which generates a key stream. This key stream is then XORed with the plaintext of the messages to create the ciphertext. The design of the E⁰ stream cipher is not based on any existing stream cipher but is a proprietary algorithm specified by the Bluetooth standard.

Figure 19.9 shows the encryption process in Bluetooth networks. From Section 19.2.3.6, we know that P^K is derived from the constraint key K^C’ using the E⁰ algorithm as follows:

Figure 19.9. Bluetooth encryption

where BD_ADDR is the 48-bit Bluetooth address of the device, EN_RAND is a 128-bit random number and CK_VAL is the 26 bits of the current clock value (bits 1–26 of the master’s native clock). Next, this P^K is fed into the key stream generator. This key stream generator then produces a key stream which is XORed with the plaintext to produce the ciphertext. There are a few important things to note about the encryption process in Bluetooth.

First, not all bits of the Bluetooth packet are encrypted. Figure 19.10 shows the format of a Bluetooth packet. It consists of an access code followed by a header and finally the payload. The access code is derived from the BD_ADDR of the master of the piconet and since every piconet has a unique master, the access code uniquely identifies a piconet. The access code is therefore used by the devices in a piconet to determine if a packet is for another piconet, in which case the packet is discarded.

Figure 19.10. Bluetooth packet format

The access code also defines where a slot boundary lies and is therefore also used by the slaves in a piconet to synchronize their clocks to the master’s clock. It is therefore not a surprise that the access code in Bluetooth packets is not encrypted. Next, the header in the Bluetooth packet is also not encrypted. The reason for this is also pretty obvious when you consider that the header contains the address of the destination device. This information is obviously needed by all devices in the piconet to determine whether or not a particular packet is intended for it or not. Therefore, the bottom line is that only the payload in the Bluetooth packet is encrypted.

Second, as shown in Figure 19.9, the CRC is appended to the packet before it is encrypted. In other words, the CRC along with the payload is also encrypted.

Third, realize that using a stream cipher in a wireless medium is a security loophole as discussed in Section 18.5.1 (What’s Wrong with WEP?). Just like WEP tries to overcome the drawbacks of using a stream cipher by changing the key for each packet, Bluetooth uses the same approach: the P^K is derived for each Bluetooth packet.^[10] However, unlike WEP where the per-packet key is calculated simply by prepending the IV with the master key, the derivation of the per-packet key in Bluetooth is much more cryptographically involved, thus making Bluetooth encryption more secure than WEP. Let us take a closer look at Figure 19.9.

¹⁰ Multislot packets do not require a change of the payload key when passing a slot boundary within a packet.

As Figure 19.9 shows, the encryption process in Bluetooth can be separated into three distinct blocks. The first block consists of deriving the payload key, P^K. We saw at the beginning of this section how this is achieved. This P^K feeds into the second block and acts as the initialization seed to a key stream generator. In other words, P^K is used to initialize the key stream generator. The key stream generated from the second block feeds into the third block which is nothing but a simple XOR operation between this key stream and the payload^[11] of the Bluetooth packet.

¹¹ Along with the CRC.

Finally, realize that to change the P^K on a per-packet basis, we need a variable which changes on a per-packet basis. One of the inputs required for generating the payload key, P^K is CK_VAL, the lower 26 bits 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 P^K can be derived afresh every 625 microseconds. However initializing the key stream generator with P^K takes some time. This is where guard space comes in. The Bluetooth standard specifies a guard space between the end of the payload in one packet and the start of the next packet. This guard space must be at least 259 microseconds, which is enough time for the key stream generator to be initialized. The overall timing sequence is as shown in Figure 19.11 where “running the stream cipher” and “initializing key stream generator” slots alternate.

Figure 19.11. Bluetooth stream cipher periodicity

19.2.6. Integrity Protection

The Bluetooth standard relies on a cyclic redundancy check (CRC) to provide message integrity. Recall from Section 18.6 that WEP also used CRC for providing message integrity. We discussed the loopholes of this approach in Section 18.7 and concluded that using a linear noncryptographic integrity check mechanism like CRC leaves a lot to be desired as far as integrity protection is concerned. We also saw that just encryption does not automatically provide integrity. In other words, just because a message is encrypted does not mean that it can’t be modified in-transit without the receiver’s knowledge. The bottom line is that by choosing CRC, Bluetooth fails to provide any real^[12] integrity protection.

¹² That is, any strong enough.

19.2.7. Enhancements

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