54 |
Bluetooth Security |
Table 3.1
An Example of Two UTF-8 Encoded Pass-Keys
User-Entered Pass-Key
String (Hexadecimal)
‘0123’ 0x30313233
’Ärlig’ 0xC384726C67
the French AZERTY keyboards). The keyboard itself usually lacks knowledge of what is printed on the key tops. Normally, a scan code is sent to the host, which interprets this code differently depending on the language setting. However, before the keyboard and the computer have been paired, the keyboard must do the interpretation by itself and it has to make some assumptions about the language in order to generate the correct PKEY. Then the best option for the computer is to only use numerical values in its random pass-key string, as the numerical keys tend to have the same scan codes for every language. The computer displays the chosen pass-key string on screen, and then the user enters this number on the keyboard in order to complete the pairing.
3.6 Cipher key generation
When encryption is desired, a ciphering key must be computed. In Bluetooth, the link key is not directly used as the key for the encryption mechanisms. Instead, the ciphering key is determined in several additional steps from the link key and is logically linked to the last authentication that has occurred between two devices through the ACO. In addition, the ciphering key is refreshed for each package that is transmitted. Since we want to explain the ciphering process in its entirety, we will in this section go stepwise through each detail of the ciphering key generation until the final key is fed into the E0 stream cipher.
3.6.1Encryption key KC
Before encryption can commence, the encryption key must be computed. The encryption key KC can be seen as a high-level encryption key from which the other ciphering keys are derived. The value of KC is computed by using the algorithm E3 from the current link key K, a 96-bit ciphering offset (COF), and a 128-bit random number EN_RAND. The value of COF equals the value of the authentication ciphering offset ACO, except when the current link key is a master key. In the latter case, COF is derived from the BD_ADDR of the master as
Bluetooth Pairing and Key Management |
55 |
|
|
|
|
BD _ ADDR ||BD _ ADDR , |
when link is master key |
(3.15) |
COF = |
|
|
ACO |
otherwise |
|
Now KC is given by |
|
|
K C = E 3 (K , EN _ RAND, COF) |
(3.16) |
|
The ciphering activation always starts with a new computation of KC and is a result of an explicit LM command. As a result, the encryption key is changed every time the encryption is activated. The algorithm E3 is described in more detail in Section 4.2.4.
3.6.2Constraint key K C′
Bluetooth has a key strength constraining mechanism that reduces the 128-bit KC to a 128-bit key whose effective key length may be less than 128 bits. Here, effective key length refers to the number of unknown (bit) combinations in the key. The constraining mechanism was introduced in Bluetooth as a result of export restrictions on encryption hardware. The resulting key is here called the constraint key and is denoted by K C′ . K C′ is determined for a given L by the computation
|
|
|
|
C |
|
|
2 |
|
|
{ |
C |
(x ) |
[ |
|
1 |
]} |
|
||
|
|
|
|
K ′ |
(x) = g L (x ) |
K |
|
mod g L (x ) |
(3.17) |
||||||||||
where K |
C |
= (K |
C, 0 |
, …, |
K |
C, 127 |
), K |
C,i |
|
{0,1} and K ′ |
= (K ′ |
,K, K ′ |
) and K ′ |
||||||
{0,1}, |
|
|
|
|
|
|
|
|
|
|
|
C |
C , 0 |
C ,127 |
C ,i |
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
K C (x ) = ∑127 |
K C ,i x i |
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
i = 0 |
|
|
|
|
|
|
|
|
|
|
|
|
|
K |
|
′ (x ) |
= |
127 |
K |
′ |
x i |
|
|
|
||
|
|
|
|
|
|
|
|
C |
|
|
|
∑ |
|
C ,i |
|
|
|
|
|
i = 0
and (g 1L (x), g 2L (x)) is a pair of polynomials over GF(2), that is, polynomials with coefficients that are elements of the finite field (Galois field) with 2 elements. Since the polynomials KC(x) and K C′ (x) can also be viewed as polynomials over GF(2), the computation in (3.17) is performed using the arithmetic of polynomials over GF(2)2. The modulo computation by g1(x) reduces KC(x) to a polynomial h(x) of a degree less than the degree of g1(x). Thus the effective
2.Mathematicians would say that arithmetic is carried out in GF(2)[x] the ring of polynomials over GF(2).
56 |
Bluetooth Security |
|
|
|
number of unknown keys is reduced to at most 2 |
degree[ g 1 |
( x )] |
. The multiplication |
|
|
|
|||
of h(x) by g2(x) results in a polynomial of a degree less than 128. Yet only 2 degree[ g 1 ( x )] products can occur. Thus, depending on the degree of g1(x), this might be considerably less than 2128, the number of all possible polynomials of degree less than 128. The polynomials g2(x) are chosen with an additional property that guarantees that if two different values of KC result in two different K C′ (x), the number of coefficients in which they differ is at least some given value. The latter value is denoted by Dmin. There are 16 pairs of polynomials
[g 1L (x), g 2L (x)]. Table 3.2 lists the pairs and the DLmin of the resulting constrained key. The effective key length is ≤ 8L.
Although the computations in (3.17) seem to be complicated, they are in fact very easily realized in a hardware circuit using a linear feedback/feedforward shift register with controllable taps. This fact, combined with the slight advantage of the guaranteed differences in the distinct K C′ s, motivated the use of this way of constraining the encryption key.
The effective key length L (number of octets) is established via the encryption key size negotiation. As of Bluetooth version 1.2, there are two supported
|
|
|
Table 3.2 |
|
|
|||
Table of Pairs of Key Constraining Polynomials and D L |
|
Values (Or Upper Limits When Marked with an *) |
||||||
|
|
|
|
min |
|
|
|
|
L |
Deg |
gL |
|
Deg |
gL |
DL |
||
|
|
1 |
|
|
|
|
2 |
min |
1 |
8 |
00000000 00000000 00000000 |
0000011d |
119 |
|
00e275a0 abd218d4 cf928b9b bf6cb08f |
63 |
|
2 |
16 |
00000000 00000000 00000000 |
0001003f |
112 |
|
0001e3f6 3d7659b3 7f18c258 cff6efef |
48 |
|
3 |
24 |
00000000 00000000 00000000 |
010100db |
104 |
|
000001be f66c6c3a b1030a5a 1919808b |
44 |
|
4 |
32 |
00000000 00000000 00000001 |
000000af |
|
96 |
00000001 6ab89969 de17467f d3736ad9 |
32 |
|
5 |
40 |
00000000 00000000 00000100 |
00000039 |
|
88 |
00000000 01630632 91da50ec 55715247 |
32* |
|
6 |
48 |
00000000 00000000 00010000 |
00000291 |
|
77 |
00000000 00002c93 52aa6cc0 54468311 |
27* |
|
7 |
56 |
00000000 00000000 01000000 |
00000095 |
|
71 |
00000000 000000b3 f7fffce2 79f3a073 |
24* |
|
8 |
64 |
00000000 00000001 00000000 |
0000001b |
|
63 |
00000000 00000000 a1ab815b c7ec8025 |
21* |
|
9 |
72 |
00000000 00000100 00000000 |
00000609 |
|
49 |
00000000 00000000 0002c980 11d8b04d |
15* |
|
10 |
80 |
00000000 00010000 00000000 |
00000215 |
|
42 |
|
00000000 00000000 0000058e 24f9a4bb |
14* |
11 |
88 |
00000000 01000000 00000000 |
0000013b |
|
35 |
|
00000000 00000000 0000000c a76024d7 |
11* |
12 |
96 |
00000001 00000000 00000000 |
000000dd |
|
28 |
|
00000000 00000000 00000000 1c9c26d9 |
9* |
13 |
104 |
00000100 00000000 00000000 |
0000049d |
|
21 |
00000000 00000000 00000000 0026d9e3 |
7* |
|
14 |
112 |
00010000 00000000 00000000 |
0000014f |
|
14 |
00000000 00000000 00000000 00004377 |
5* |
|
15 |
120 |
01000000 00000000 00000000 |
000000e7 |
|
7 |
00000000 00000000 00000000 00000089 |
3 |
|
16 |
128 |
1 00000000 00000000 00000000 00000000 |
|
0 |
00000000 00000000 00000000 00000001 |
1 |
||
|
|
|
|
|
|
|
|
|
Note: Polynomials are given via their hexadecimal representation.
Bluetooth Pairing and Key Management |
57 |
|
|
ways of doing this. The new and simple way is for the master to ask the slave what key lengths are supported using a bit vector (see Section 5.2). This is particularly useful in the case of broadcast encryption key negotiation. Alternatively, the master can proceed according to the procedure outlined below.
Each approved Bluetooth device must implement a maximal key size value Lmax, 1 ≤ Lmax ≤ 16. In addition, each Bluetooth application should specify a lower value of L denoted as Lmin. The effective key size L that the two devices A and B will use is determined through a negotiation that tries to find the largest key size that satisfies all the constraints on L between the master and slave devices. The negotiation starts with the master suggesting a length Lsug to a slave that equals the highest possible value for the master. If the constraints at the slave allow this suggested value of L, the suggested value is accepted as the value to be used. If the slave is not allowed to use the suggested value of L, the slave will send its Lmax back to the master. Again, if the master allows this key length it will be used; otherwise, the master proposes the closest acceptable length that is smaller than this. The procedure is repeated with the master and slave alternating proposing the largest remaining key length. This hopefully leads finally to a key length that both master and slave can accept. However, it could be that the constraints are such that no key length exists that meets the size requirements of the slave and the master.
3.6.3Payload key KP
The payload key is the actual key that is used to (de)cipher the (incoming) outgoing packages. The value of KP is computed per packet using the constraint key K C′ , and by a short run for E0 loaded with K C′ , 26 bits of the current clock value, BD_ADDR, and a 128-bit random EN_RAND, Figure 3.6 shows that KP is computed by the algorithm E0 (see Section 4.4). In fact, KP is formed by the state of the 4-bit register in the feedback path of E0 and the last 128 bits of the key stream generated by E0 when initialized with its input data and clocking the
K’C
Clock
E0 |
|
KP |
|
BD_ADDR
EN_RAND
Figure 3.6 Process of generating the payload key KP using the stream cipher algorithm E0.