Bluetooth Pairing and Key Management In this chapter we will have a closer look at pairing and key management in the
3.4 Baseband events
3.4.3 Combination key generation
The combination key is a link key that two pairing devices AandB generate together. Like the unit key, the combination key is generated when the two devices possess no common link key. The combination key is computed by combining their respective secret keys,KAandKB. The two keys are generated
from locally generated (secret) 128-bit random values (LK_RANDA and
LK_RANDB, respectively) and the units’ BD_ADDR, using the algorithm E21.
To be more precise,
(
)
KA =E21 LK RAND_ A,BD ADDR_ A (3.6)
(
)
KB =E21 LK RAND_ B,BD ADDR_ B (3.7)
The combination keyKABis then calculated as
KAB =KA ⊕KB (3.8)
The latter calculation is only possible to perform if the units know the secret key of the other unit. This is realized by sending the secret random values
LK_RANDAandLK_RANDB to each other, protected by the current link keyK.
The current link key might be a KINIT or an existing combination key for the
link. Thus, toward the final computation ofKABthe units send
CA =LK RAND_ A ⊕K, sent byAtoB (3.9)
CB =LK RAND_ B ⊕K, sent byBtoA (3.10) Now, say unitAreceivesCBand computes
(
)
CB ⊕ =K LK RAND_ B ⊕K ⊕ =K LK RAND_ B
where the latter follows again from the properties of the ⊕(XOR) operation. Hence, unit A now knows LK_RANDB, and since it knows B s BD_ADDR′
value, it can computeKBusing (3.6). UnitBdetermines the combination key in
a similar fashion from the received valueCA. Figure 3.3 illustrates the establish-
ment of the combination key.
When two devices have exchanged a link key, the pairing is finalized with a (peer) authentication in which the devices prove to each other that they possess the correct link key. If the authentication fails, the pairing is not successful and a new pairing must be initiated.
3.4.4 Authentication
In the authentication process, a device will take either the role of claimant or verifier. In case of a mutual authentication, the roles will be interchanged in the process. Prior to the authentication, the host or user determines which device is the claimant and which device is the verifier. Which role to take depends on the security policy and security mode for each device. A more thorough discussion on security policies and security modes can be found in Section 2.5 and in Chapter 6.
Suppose deviceAis the verifier and deviceBis the claimant. ThenAchal- lenges device Bby sending the random 128-bit value AU_RANDand expects fromBthe response
(
)
SRES =E1 K AU RAND BD ADDR, _ , _ B (3.11)
whereKis the exchanged link key andE1is the Bluetooth authentication func-
tion. E1 is described in Section 4.2.1. The claimant B receives the challenge
AU_RANDand sendsAthe responseSRES=E1(K,AU_RAND,BD_ADDRB).
The verifierAreceives SRES’and compares its value with that of the expected
SRES. If the values are equal, Adeclares that it has successfully authenticated deviceB. If the values differ, the authentication has failed. WhenAhas success- fully authenticatedB, the LM may want to conduct a mutual authentication, in
Device A Device B
EraseK EraseK KAB=KA⊕KB
KB=E21(LK_RAND BD_ADDRB, B) KA=E21(LK_RAND BD_ADDRA, A)
KAB=KB⊕KA CB⊕ =K LK_RANDB CA=LK_RANDA⊕K KA=E21(LK_RAND BD_ADDRA, A) LK_RANDA BD_ADDRA BD_ADDRB LK_RANDB KB=E21(LK_RAND BD_ADDRB, B) CA⊕ =K LK_RANDA CB=LK_RANDB⊕K CB CA
Figure 3.3 Process of generating the combination keyKABbetween unitsA and B using the
current link keyK. The current link key K is erased after the successful establish- ment ofKAB.
which case the above procedure is repeated with the roles of A and B inter- changed. The random value used in the challenge of deviceAthis time is a com- pletely new random value.
It is important to note that it is not necessarily the master that starts as verifier. It is the application via the LM that determines the order in which authentication is performed and if one-way or mutual authentication is required. Figure 3.4 shows a mutual authentication.
Besides the peer authentication, the Bluetooth authentication procedure also results in the creation of theauthenticated ciphering offset(ACO). The ACO is used when computing the ciphering key. In the case of mutual authentication, the ACO of the last authentication is retained. The ACO is produced by the mechanismE1at the same timeSRESis computed. For details on the computa-
tion ofSRESand ACO, see Section 4.2.1.
Finally, the Bluetooth authentication uses a simple method to reduce the impact of repeated erroneous authentications. This could, for example, be a component in adenial-of-service (DoS) attack. If authentication fails, a certain amount of time must elapse before the verifier will initiate a new attempt to the same claimant and before the claimant sends a response to an authentication attempt by a unit using the same identity as the unit that notified an authentica- tion failure. For each additional authentication failure, the waiting interval should be exponentially increased until a certain maximum value is obtained. The Bluetooth specification speaks about a doubling of the waiting interval time. When no authentications take place, the waiting interval is exponentially reduced until a certain lowest value is reached. Moreover, if a successful authen- tication event takes place, the waiting interval may immediately be reset to the minimum value, To obtain some protection against a DoS attack, a Bluetooth
Link keyK ACO ACO Device A Device B as claimant: as claimant as verifier as verifier: Challenge A Challenge B Response A Response B Link keyK
Figure 3.4 The mutual authentication process between devicesA and B and the generation of the ACO.
device should keep a list containing, for each unit it has connected with, the cor- responding waiting interval.