Bluetooth Core Specification

To perform a role switch on a connection encryption must be disabled or paused as the encryption is based off the Central's clock and Bluetooth address information. Unfortunately, if the role switch is required, and encryption is turned off, the device on the other end of the link will not be aware of the reason for disabling encryption, and can therefore take two possible actions: send clear text data, or disconnect. Neither of these possible actions is desirable. When performing a role switch on an encrypted link, the role switch shall be performed as a single operation where possible. If this is not possible because the other device does not support the encryption pause feature, then when a device wishes to have an encrypted link, and encryption is disabled, then the device should not send any user data, and should not disconnect. If both devices support the encryption pause feature, then this procedure shall be used.

It is possible to perform a change of connection link keys while a link is encrypted, but it is not possible to use the new link keys until encryption has been stopped and then restarted. As with role switches, disabling encryption and then re-enabling it again can cause user data to be sent in the clear or a disconnection to occur. The use of encryption pausing prevents this problem from occurring. On devices that do not support the encryption pause feature, when a device wishes to have an encrypted link, and encryption is disabled, then the device should not send any data, and should not disconnect. If both devices support the encryption pause feature, then this procedure shall be used.

If both devices support the encryption pause feature, then the encryption keys shall be refreshed by the Link Manager at least once every 2²⁸ ticks of the Bluetooth clock (about 23.3 hours) when E0 encryption is used and before either the PayloadCounter or dayCounter roll over (at least 2³⁸ ticks of the Bluetooth clock or at least 2.72 years) when AES-CCM encryption is used if it is not refreshed by the Host or the remote Link Manager. To refresh an encryption key, the Host may use the Change Connection Link Key procedure or request an encryption key refresh. If the encryption key has not been refreshed before going stale, a device may disconnect the link.

The link key is a 128-bit random number which is shared between two or more parties and is the base for all security transactions between these parties. The link key itself is used in the authentication routine. Moreover, the link key is used as one of the parameters when the encryption key is derived.

In the following, a session is defined as the time interval for which the device is a member of a particular piconet. Thus, the session terminates when the device disconnects from the piconet.

The link keys are either semi-permanent or temporary. A semi-permanent link key may be stored in non-volatile memory and may be used after the current session is terminated. Consequently, once a semi-permanent link key is defined, it may be used in the authentication of several subsequent connections between the devices sharing it. The designation semi-permanent is justified by the possibility of changing it. How to do this is described in Section 3.2.7.

The lifetime of a temporary link key is limited by the lifetime of the current session – it shall not be reused in a later session. Typically, in a point-to-multipoint configuration where the same information is to be distributed securely to several recipients, a common encryption key is useful. To achieve this, the temporary link key replaces the semi-permanent link keys. The details of this procedure are found in Section 3.2.6.

In the following, the current link key is the link key in use at the current moment. It can be semi-permanent or temporary. Thus, the current link key is used for all authentications and all generation of encryption keys in the on-going connection (session).

In order to accommodate different types of applications, three types of link keys have been defined:

In addition to these keys there is an encryption key, denoted K_enc. This key is derived from the current link key. Whenever encryption is activated by an LM command, the encryption key shall be changed automatically. The purpose of separating the authentication key and encryption key is to facilitate the use of a shorter encryption key without weakening the strength of the authentication procedure. There are no governmental restrictions on the strength of authentication algorithms. However, in some countries, such restrictions exist on the strength of encryption algorithms.

The combination key is derived from information in both devices A and B, and is therefore always dependent on two devices. The combination key is derived for each new combination of two devices.

The temporary link key, K_temp, shall only be used during the current session. It shall only replace the original link key temporarily. For example, this may be utilized when a Central wants to reach more than one device simultaneously using the same encryption key, see Section 3.2.6.

The initialization key, K_init, shall be used as the link key during the initialization process when no combination keys have been defined and exchanged yet or when a link key has been lost. The initialization key protects the transfer of initialization parameters. The key is derived from a random number, an L-octet PIN code, and a BD_ADDR. This key shall only be used during initialization.

The PIN may be a fixed number provided with the device (for example when there is no user interface as in a PSTN plug). Alternatively, the PIN can be selected by the user, and then entered in both devices that are to be matched. The latter procedure should be used when both devices have a user interface, for example a phone and a laptop. Entering a PIN in both devices is more secure than using a fixed PIN in one of the devices, and should be used whenever possible. Even if a fixed PIN is used, it shall be possible to change the PIN; this is in order to prevent re-initialization by users who once obtained the PIN. If no PIN is available, a default value of zero may be used. The length of this default PIN is one byte, PIN (default) = 0x00. This default PIN may be provided by the Host.

For many applications the PIN code will be a relatively short string of numbers. Typically, it may consist of only four decimal digits. Even though this gives sufficient security in many cases, there exist countless other, more sensitive, situations where this is not reliable enough. Therefore, the PIN code may be chosen to be any length from 1 to 16 octets. For the longer lengths, the devices exchanging PIN codes may use software at the application layer rather than mechanical (i.e. human) interaction. For example, this can be a Diffie-Hellman key agreement, where the exchanged key is passed on to the $K_{init}$ generation process in both devices, just as in the case of a shorter PIN code.

The link keys must be generated and distributed among the devices in order to be used in the authentication procedure. Since the link keys shall be secret, they shall not be obtainable through an inquiry routine in the same way as the Bluetooth Device Addresses. The exchange of the keys takes place during an initialization phase which shall be carried out separately for each two devices that are using authentication and encryption. The initialization procedures consist of the following five parts:

After the initialization procedure, the devices can proceed to communicate, or the link can be disconnected. If encryption is implemented, the $E_0$ algorithm shall be used with the proper encryption key derived from the current link key. For any new connection established between devices A and B, they should use the common link key for authentication, instead of once more deriving $K_{init}$ from the PIN. A new encryption key derived from that particular link key shall be created next time encryption is activated.

If no link key is available, the LM shall automatically start an initialization procedure.

3.2.4. Generation of a combination key

To use a combination key, it is first generated during the initialization procedure. The combination key is the combination of two numbers generated in device A and B, respectively. First, each device shall generate a random number, LK_RAND_A and LK_RAND_B. Then, utilizing $E_{21}$ with the random number and their own BD_ADDRs, the two random numbers

Equation 1. 

$LK\_K_A=E_{\mathit{21}}\left(LK\_RAN{D}_A\text{, }BD\_ADDR\_A\right),$

and

Equation 2. 

$LK\_K_B=E_{\mathit{21}}\left(LK\_RAN{D}_B\text{, }BD\_ADDR\_B\right),$

shall be created in device A and device B, respectively. These numbers constitute the devices’ contribution to the combination key that is to be created. Then, the two random numbers LK_RAND_A and LK_RAND_B shall be exchanged securely by XORing with the current link key, $K$. Thus, device A shall send $CA=K\oplus LK\_RAN{D}_A$ to device B, while device B shall send $CB=K\oplus LK\_RAN{D}_B$ to device A. If this is done during the initialization phase the link key $K=K_{init}$. If CA is identical to CB, then the devices should terminate the process of generating the combination key.

When the random numbers $LK\_RAN{D}_A$ and $LK\_RAN{D}_B$ have been mutually exchanged, each device shall recalculate the other device’s contribution to the combination key. This is possible since each device knows the Bluetooth Device Address of the other device. Thus, device A shall calculate (EQ 2) and device B shall calculate (EQ 1). After this, both devices shall XOR the two numbers to generate the 128-bit link key. The result shall be stored in device A as the link key $K_{AB}$ and in device B as the link key $K_{BA}$. If the resulting link key consists of all zeroes, then the devices should discard the link key and terminate the process of generating the combination key. When both devices have derived the new combination key, a mutual authentication procedure shall be initiated to confirm the success of the transaction. The old link key shall be discarded after a successful exchange of a new combination key. The message flow between Central and Peripheral and the principle for creating the combination key is depicted in Figure 3.1.

Figure 3.1: Generating a combination key. The old link key (K) is discarded after the exchange of a new combination key has succeeded.

3.2.8. Generating a temporary link key

The key-change routines described so far are semi-permanent. To create the temporary link key, which can replace the current link key during a session (see Section 3.2.6), other means are needed. First, the Central shall create a new link key from two 128-bit random numbers, RAND1 and RAND2. This shall be done by

Equation 4. 

$\mathrm{K\_temp}=E_{22}(\text{RAND1, RAND2, 16).}$

This key is a 128-bit random number. The reason for using the output of $E_{22}$ and not directly choosing a random number as the key, is to avoid possible problems with degraded randomness due to a poor implementation of the random number generator within the device.

Then, a third random number, RAND, shall be transmitted to the Peripheral. Using $E_{22}$ with the current link key and RAND as inputs, both the Central and the Peripheral shall compute a 128-bit overlay. The Central shall send the bitwise XOR of the overlay and the new link key to the Peripheral. The Peripheral, who knows the overlay, shall recalculate K_temp. To confirm the success of this transaction, the devices shall perform a mutual authentication procedure using the new link key. This procedure shall then be repeated for each Peripheral that receives the new link key. The ACO values from the authentications shall not replace the current ACO, as this ACO is needed to (re)compute a ciphering key when the Central falls back to the previous (semi-permanent) link key.

The Central activates encryption by an LM command. Before activating encryption, the Central shall ensure that all Peripherals receive the same random number, EN_RAND, since the encryption key is derived through the means of $E_3$ individually in all participating devices. Each Peripheral shall compute a new encryption key as follows:

Equation 5. 

$\mathrm{K\_enc}=E_3\left(\text{K\_temp, EN\_RAND, COF}\right)$

where the value of COF shall be derived from the Central’s BD_ADDR as specified by equation (EQ 3). The details of the encryption key generating function are described in Section 6.4. The message flow between the Central and the Peripheral when generating the temporary link key is depicted in Figure 3.2.

Note

Note: In this case the ACO produced during the authentication is not used when computing the ciphering key.

Figure 3.2: Temporary link key distribution and computation of the corresponding encryption key

Each device implementing the Baseband specification shall have a parameter defining the maximal allowed key length, L_max, 1 ≤ L_max ≤ 16 (number of octets in the key). For each application using encryption, a number L_min shall be defined indicating the shortest acceptable key size for that particular application. Before generating the encryption key, the devices involved shall negotiate to decide the key size to use.

The Central shall send a suggested value, L_sug_c, to the Peripheral. Initially, the suggested value shall be set to L_max_c. If L_min_p ≤ L_sug_c, and, the Peripheral supports the suggested length, the Peripheral shall acknowledge and this value shall be the length of the encryption key for this link. However, if both conditions are not fulfilled, the Peripheral shall send a new proposal, L_sug_p < L_sug_c, to the Central. This value shall be the largest among all supported lengths less than the previous Central suggestion. Then, the Central shall perform the corresponding test on the Peripheral suggestion. This procedure shall be repeated until a key length agreement is reached, or, one device aborts the negotiation. An abort may be caused by lack of support for L_sug and all smaller key lengths, or if L_sug < L_min in one of the devices. In case of an abort link encryption cannot be employed.

The possibility of a failure in setting up a secure link is an unavoidable consequence of letting the application decide whether to accept or reject a suggested key size. However, this is a necessary precaution. Otherwise a fraudulent device could enforce a weak protection on a link by claiming a short maximum key size.

There may be three settings for the Baseband regarding encryption:

For the encryption routine, a stream cipher algorithm is used in which ciphering bits are XORed with the data stream to be sent over the air interface. The payload is ciphered after the CRC bits are appended, but, prior to the FEC encoding.

Each packet payload shall be ciphered separately. The cipher algorithm $E_0$ uses the Central’s Bluetooth Device Address (BD_ADDR_C), 26 bits of the Central real-time clock (CLK_26-1) and the encryption key K_enc as input, see Figure 4.2.

The encryption key K_enc is derived from the current link key, COF, and a random number, EN_RAND_C (see Section 6.4). The random number shall be issued by the Central before entering encryption mode.

Within the $E_0$ algorithm, the encryption key K_enc is modified into another key denoted K_session. The maximum effective size of this key shall be factory preset and may be set to any multiple of eight between one and sixteen (i.e. 8 to 128 bits). The procedure for deriving the key is described in Section 4.5.

The real-time clock is incremented for each slot. The $E_0$ algorithm shall be re-initialized at the start of each new packet (i.e. for Central-to-Peripheral as well as for Peripheral-to-Central transmission). By using CLK_26-1 at least one bit is changed between two transmissions. Thus, a new keystream is generated after each re-initialization. For packets covering more than a single slot, the Bluetooth clock as found in the first slot shall be used for the entire packet.

The encryption algorithm $E_0$ generates a binary keystream, $K_{cipher}$, which shall be XORed with the data to be encrypted. The cipher is symmetric; decryption shall be performed in exactly the same way using the same key as used for encryption.

Figure 4.2: Functional description of the encryption procedure

The system uses linear feedback shift registers (LFSRs) whose output is combined by a simple finite state machine (called the summation combiner) with 16 states. The output of this state machine is the key stream sequence, or, during initialization phase, the randomized initial start value. The algorithm uses an encryption key K_enc, a 48-bit Bluetooth address, the Central's clock bits CLK_26-1, and a 128-bit RAND value. Figure 4.3 shows the setup.

There are four LFSRs (LFSR₁ ,...,LFSR₄ ) of lengths $L_1=25$, $L_2=31$, $L_3=33$, and, $L_4=39$, with feedback polynomials as specified in Table 4.2. The total length of the registers is 128. These polynomials are all primitive. The Hamming weight of all the feedback polynomials is five.

Figure 4.3: Concept of the encryption engine

Let $x_t^i$ denote the $t^{th}$ symbol of LFSR_i. The value $y_t$ is derived from the four-tuple $x_t^1,...,x_t^4$ using the following equation:

where the sum is over the integers. Thus $y_t$ can take the values 0,1,2,3, or 4. The output of the summation generator is obtained by the following equations:

where $T_1\left[.\right]$ and $T_2\left[.\right]$ are two different linear bijections over GF(4). Suppose GF(4) is generated by the irreducible polynomial $x^2+x+1$, and let $\mathrm{\alpha }$ be a zero of this polynomial in GF(4). The mappings $T_1$ and $T_2$ are now defined as:

The elements of GF(4) can be written as binary vectors. This is summarized in Table 4.3.

Since the mappings are linear, they can be implemented using XOR gates; i.e.

4.4.1. The operation of the cipher

Figure 4.4 gives an overview of the operation in time. The encryption algorithm shall run through the initialization phase before the start of transmission or reception of a new packet. Thus, for multislot packets the cipher is initialized using the clock value of the first slot in the multislot sequence.

Figure 4.4: Overview of the operation of the encryption engine. Between each start of a packet (TX or RX), the LFSRs are re-initialized.

The key stream generator is loaded with an initial value for the four LFSRs (in total 128 bits) and the 4 bits that specify the values of c₀ and c_–1. The 132 bit initial value is derived from four inputs by using the key stream generator. The input parameters are the key K_enc, a 128-bit random number RAND, a 48-bit Bluetooth Device Address, and the 26 Central's clock bits CLK_26-1.

The effective length of the encryption key may vary between 8 and 128 bits. The actual key length as obtained from E₃ is 128 bits. Then, within E₀, the key length may be reduced by a mod operation between K_enc and a polynomial of desired degree. After reduction, the result is encoded with a block code in order to distribute the starting states more uniformly. The operation shall be as defined in (EQ 10).

When the encryption key has been created the LFSRs are loaded with their initial values. Then, 200 stream cipher bits are created by operating the generator. Of these bits, the last 128 are fed back into the key stream generator as an initial value of the four LFSRs. The values of c_t and c_t–1 are kept. From this point on, when clocked the generator produces the encryption (decryption) sequence which is bitwise XORed to the transmitted (received) payload data.

In the following, octet i of a binary sequence X is X[i]. Bit 0 of X is the LSB. Then, the LSB of X[i] corresponds to bit 8i of the sequence X, the MSB of X[i] is bit 8i + 7 of X. For instance, bit 24 of the Bluetooth Device Address is the LSB of BD_ADDR[3].

The details of the initialization shall be as follows:

After the parallel load in item 4, the blend register contents shall be updated for each subsequent clock.

In Figure 4.5, all bits are shifted into the LFSRs, starting with the least significant bit (LSB). For instance, from the third octet of the address, BD_ADDR[2], first BD_ADDR₁₆ is entered, followed by BD_ADDR₁₇, etc. Furthermore, CL₀ corresponds to CLK₁,..., CL₂₅ corresponds to CLK₂₆.

Figure 4.5: Arranging the input to the LFSRs

In Figure 4.6, the 128 binary output symbols Z₀,..., Z₁₂₇ are arranged in octets denoted Z[0],..., Z[15]. The LSB of Z[0] corresponds to the first of these symbols, the MSB of Z[15] is the last output from the generator. These bits shall be loaded into the LFSRs according to the figure. It is a parallel load and no update of the blend registers is done. The first output symbol is generated at the same time. The octets shall be written into the registers with the LSB in the leftmost position (i.e. the opposite of before). For example, Z₂₄ is loaded into position 1 of LFSR₄.

Figure 4.6: Distribution of the 128 last generated output symbols within the LFSRs.

When the initialization is finished, the output from the summation combiner is used for encryption/decryption. The first bit to use shall be the one produced at the parallel load, i.e. at $t=240$. The circuit shall be run for the entire length of the current payload. Then, before the reverse direction is started, the entire initialization process shall be repeated with updated values on the input parameters.

Sample data of the encryption output sequence can be found in [Vol 2] Part G, Section 1.1. A necessary, but not sufficient, condition for all Bluetooth compliant implementations of encryption is to produce these encryption streams for identical initialization values.

When the authentication attempt fails, a waiting interval shall pass before the verifier will initiate a new authentication attempt to the same claimant, or before it will respond to an authentication attempt initiated by a device claiming the same identity as the failed device. For each subsequent authentication failure, the waiting interval shall be increased exponentially. For example, after each failure, the waiting interval before a new attempt can be made could be twice as long as the waiting interval prior to the previous attempt^[2]. The waiting interval shall be limited to a maximum.

The maximum waiting interval depends on the implementation. The waiting time shall exponentially decrease to a minimum when no new failed attempts are made during a certain time period. This procedure restricts the rate at which an intruder can repeat the authentication procedure with different keys.

To protect a device's private key, a device should implement a method to prevent an attacker from retrieving useful information about the device's private key. For this purpose, a device should change its private key after every pairing (successful or failed). Otherwise, it should change its private key whenever S + 3F > 8, where S is the number of successful pairings and F the number of failed attempts since the key was last changed.

The authentication function $E_1$ is a computationally secure authentication code. $E_1$ uses the encryption function SAFER+. The algorithm is an enhanced version of an existing 64-bit block cipher SAFER-SK128, and it is freely available. In the following discussion, the block cipher will be denoted as the function $A_r$ which maps using a 128-bit key, a 128-bit input to a 128-bit output, i.e.

The details of $A_r$ are given in the next section. The function $E_1$ is constructed using $A_r$ as follows

where $\text{SRES}=Hash\left(K,\text{RAND, address, 6}\right)\left[0,...,3\right]$, where $Hash$ is a keyed hash function defined as^[3],

and where

is an expansion of the $L$ octet word $X$ into a 128-bit word. The function $A_r$ is evaluated twice for each evaluation of $E_1$. The key $\tilde{K}$ for the second use of $A_r$ (actually $A{\text{'}}_r$) is offset from $K$ as follows^[4]

A data flowchart of the computation of $E_1$ is shown in Figure 6.1. $E_1$ is also used to deliver the parameter ACO (Authenticated Ciphering Offset) that is used in the generation of the ciphering key by $E_3$, see equations (EQ 3) and (EQ 23). The value of ACO is formed by octets 4 to 15 of the output of the hash function defined in (EQ 13):

Figure 6.1: Flow of data for the computation of E₁

The function $A_r$ is identical to SAFER+. It consists of a set of 8 layers, (each layer is called a round) and a parallel mechanism for generating the sub keys $K_p\left[j\right],p=1,2,\dots ,17$, which are the round keys to be used in each round. The function will produce a 128-bit result from a 128-bit random input string and a 128-bit key. Besides the function $A_r$, a slightly modified version referred to as $A{\text{'}}_r$ is used in which the input of round 1 is added to the input of round 3. This is done to make the modified version non-invertible and prevents the use of $A{\text{'}}_r$ (especially in $E_{2x}$) as an encryption function. See Figure 6.2 for details.

6.2.2. The substitution boxes “e” and “l”

In Figure 6.2 two boxes are shown, marked “e” and “l”. These boxes implement the same substitutions as are used in SAFER+; i.e. they implement

Equation 0. 

$\begin{array}{ccl}\mathit{\text{e, l}}& :& \left\{0,...,255\right\}\to \left\{0,...,255\right\},\\ e& :& i\mapsto \left({45}^i\mathit{\text{ mod }}257\right)\mathit{\text{ mod }}256,\\ l& :& i\mapsto j\text{ s.t. }i=e\left(j\right).\end{array}$

Their role, as in the SAFER+ algorithm, is to introduce non-linearity.

Figure 6.2: One round in A_r and A’_r

In Section 6.2, the permutation boxes show how input byte indices are mapped onto output byte indices. Thus, position 8 is mapped on position 0 (leftmost), position 11 is mapped on position 1, etc.

6.2.3. Key scheduling

In each round, 2 batches of 16 octet-wide keys are needed. These round keys are derived as specified by the key scheduling in SAFER+. Figure 6.3 gives an overview of how the round keys K_p[j] are determined. The bias vectors B₂, B₃, ..., B₁₇ shall be computed according to following equation:

Equation 17. 

$B_p\left[i\right]=\left(\left({45}^{\left({45}^{17p+i+1}\mathit{\text{mod }}257\right)}\mathit{\text{mod }}\text{257}\right)\mathit{\text{ mod }}\text{256}\right),\text{for }i=0,...,15.$

Figure 6.3: Key scheduling in A_r

The key used for authentication shall be derived through the procedure that is shown in Figure 6.4. The figure shows two modes of operation for the algorithm. In the first mode, $E_{21}$ produces a 128-bit link key, $K$, using a 128-bit RAND value and a 48-bit address. This mode shall be utilized when creating combination keys. In the second mode, $E_{22}$ produces a 128-bit link key, $K$, using a 128-bit RAND value and an $L$ octet user PIN. The second mode shall be used to create the initialization key, and also when a temporary link key is to be generated.

When the initialization key is generated, the PIN is augmented with the BD_ADDR, see Section 3.2.1 for which address to use. The augmentation shall always start with the least significant octet of the address immediately following the most significant octet of the PIN. Since the maximum length of the PIN used in the algorithm cannot exceed 16 octets, it is possible that not all octets of BD_ADDR will be used.

This key generating algorithm again exploits the cryptographic function $E_2$. for mode 1 (denoted $E_{21}$) is computed according to following equations:

where (for mode 1)

Let $L$ be the number of octets in the user PIN. The augmenting is defined by

where L' = min { 16, L+6 }.

Then, in mode 2, E₂ (denoted E₂₂) is

where

Figure 6.4: Key generating algorithm E₂ and its two modes. Mode 1 is used for combination keys, while mode 2 is used for K_init and K_temp

The ciphering key K_enc used by $E_0$ shall be generated by $E_3$. The function $E_3$ is constructed using A'_r as follows

where Hash is the hash function as defined by (EQ 13). The key length produced is 128 bits. However, before use within $E_0$, the encryption key K_enc is shortened to the correct encryption key length, as described in Section 4.5. A block scheme of $E_3$ is depicted in Figure 6.5.

The value of COF is determined as specified by equation (EQ 3).

Figure 6.5: Generation of the encryption key

Initially, each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-private key pair (step 1). See Section 5.1 for recommendations on how frequently this key pair should be changed.

Pairing is initiated by the initiating device sending its public key to the receiving device (step 1a). The responding device replies with its own public key (step 1b). If the two public keys have the same X coordinate and neither is the debug key (see [Vol 4] Part E, Section 7.6.4), each device should fail the pairing process. These public keys are not regarded as secret although they may identify the devices.

When both devices’ Controllers and Hosts support Secure Connections, the P-256 elliptic curve is used. When at least one device’s Controller or Host doesn’t support Secure Connections, the P-192 elliptic curve is used.

Figure 7.2: Public key exchange details

A device shall validate that any public key received from any BD_ADDR is on the correct curve (P-192 or P-256) - see Section 7.6.

Authentication stage 1 has three different protocols: Numeric Comparison, Out-of-Band, and Passkey Entry. The Just Works association model shares the Numeric Comparison protocol and does not have a separate protocol.

The protocol is chosen based on the IO capabilities of the two devices.

Figure 7.3: Authentication stage 1 (high level)

The three protocols are described in the following sections.

7.2.1. Authentication stage 1: Numeric Comparison protocol

The Numeric Comparison protocol provides limited protection against active "man-in-the-middle" (MITM) attacks as an active man-in-the-middle will succeed with a probability of 0.000001 on each iteration of the protocol. Provided that there is no MITM at the time the pairing is performed, the shared Link Key that is generated is computationally secure from even a passive eavesdropper that may have been present during the pairing.

The sequence diagram of Authentication stage 1 for the Numeric Comparison protocol from the cryptographic point of view is shown in Figure 7.4.

Figure 7.4: Authentication stage 1: Numeric Comparison protocol details

After the public keys have been exchanged, each device selects a random 128-bit nonce (step 2). This value is used to mitigate replay attacks and shall be freshly generated with each instantiation of the pairing protocol. This value should be generated directly from a physical source of randomness or with a good pseudo-random generator seeded with a random value from a physical source.

Following this the responding device then computes a commitment to the two public keys that have been exchanged and its own nonce value (step 3c). This commitment is computed as a one-way function of these values and is transmitted to the initiating device (step 4). The commitment prevents an attacker from changing these values at a later time.

The initiating and responding devices then exchange their respective nonce values (steps 5 and 6) and the initiating device confirms the commitment (step 6a). A failure at this point indicates the presence of an attacker or other transmission error and causes the protocol to abort. The protocol may be repeated with or without the generation of new public-private key pairs, but, as stated above, new nonces must be generated if the protocol is repeated.

Assuming that the commitment check succeeds, the two devices each compute 6-digit confirmation values that are displayed to the user on their respective devices (steps 7a, 7b, and 8). The user is expected to check that these 6-digit values match and to confirm if there is a match. If there is no match, the protocol aborts and, as before, new nonces must be generated if the protocol is to be repeated.

An active MITM must inject its own key material into this process to have any effect other than denial-of-service. A simple MITM attack will result in the two 6-digit display values being different with probability 0.999999. A more sophisticated attack may attempt to engineer the display values to match, but this is thwarted by the commitment sequence. If the attacker first exchanges nonces with the responding device, it must commit to the nonce that it will use with the initiating device before it sees the nonce from the initiating device. If the attacker first exchanges nonces with the initiating device, it must send a nonce to the responding device before seeing the nonce from the responding device. In each case, the attacker must commit to at least the second of its nonces before knowing the second nonce from the legitimate devices. It therefore cannot choose its own nonces in such a way as to cause the display values to match.

7.2.2. Authentication stage 1: Out of Band protocol

The Out-of-Band protocol is used when authentication information has been received by at least one of the devices and indicated in the OOB Authentication Data Present parameter in the LMP IO capability exchange sequence. The mode in which the discovery of the peer device is first done in-band and then followed by the transmission of authentication parameters through OOB interface is not supported. The sequence diagram for Authentication stage 1 for Out of Band from the cryptographic point of view is shown in Figure 7.5.

Figure 7.5: Authentication stage 1: Out of Band details

Principle of operation: If both devices can transmit and/or receive data over an out-of-band channel, then mutual authentication will be based on the commitments of the public keys (Ca and Cb) exchanged OOB in Authentication stage 1. If OOB communication is possible only in one direction, then authentication of the device receiving the OOB communication will be based on that device knowing a random number r sent via OOB. In this case, r must be secret: r can be created afresh every time, or access to the device sending r must be restricted. If r is not sent by a device, it is assumed to be 0 by the device receiving the OOB information in step 4a or 4b.

Roles of A and B: The OOB Authentication stage 1 protocol is symmetric with respect to the roles of A and B. It does not require that device A always will initiate pairing and it automatically resolves asymmetry in the OOB communication, e.g. in the case when one of the devices has an NFC tag and can only transmit OOB.

Order of steps: The public key exchange must happen before the verification step 5. In the diagram the in-band public key exchange between the devices (step 1) is done before the OOB communication (step 4). But when the pairing is initiated by an OOB interface, public key exchange will happen after the OOB communication (step 1 will be between steps 4 and 5).

Values of ra and rb: Since the direction of the peer's OOB interface cannot be verified before the OOB communication takes place, a device should always generate and if possible transmit through its OOB interface a random number r to the peer. Each device applies the following rules locally to set the values of its own r and the value of the peer's r:

1. Initially, r of the device is set to a random number and r of the peer is set to 0 (step 2).

2. If a device has received OOB, it sets the peer's r value to what was sent by the peer (Step 5).

3. If the remote device's OOB Authentication Data parameter sent in the LMP IO capabilities exchange sequence is set to No OOB Data Received, it sets its own r value to 0 (Step 5)

These rules ensure that when entering Authentication stage 2, both A and B have the same values for ra and rb if OOB communication took place.

7.2.3. Authentication stage 1: Passkey Entry protocol

The Passkey Entry protocol is used when LMP IO capability exchange sequence indicates that Passkey Entry shall be used.

The sequence diagram for Authentication stage 1 for Passkey Entry from the cryptographic point of view is shown in Figure 7.6.

Figure 7.6: Authentication stage 1: Passkey Entry details

The user inputs an identical Passkey into both devices. Alternately, the Passkey may be generated and displayed on one device, and the user then inputs it into the other (step 2). This short shared key will be the basis of the mutual authentication of the devices. The Passkey should be generated randomly during each pairing procedure and not be reused from a previous procedure. Static Passkeys should not be used since they can compromise the security of the link.

Steps 3 to 8 are repeated 20 times since a 6-digit Passkey is 20 bits (999999=0xF423F). If the device allows a shorter passkey to be entered, it shall be prefixed with zeros (e.g. “1234” is equivalent to “001234”).

In Steps 3 to 8, each side commits to each bit of the Passkey, using a long nonce (128 bits), and sending the hash of the nonce, the bit of the Passkey, and both public keys to the other party. The parties then take turns revealing their commitments until the entire Passkey has been mutually disclosed. The first party to reveal a commitment for a given bit of the Passkey effectively reveals that bit of the Passkey in the process, but the other party then has to reveal the corresponding commitment to show the same bit value for that bit of the Passkey, or else the first party will then abort the protocol, after which no more bits of the Passkey are revealed.

This "gradual disclosure" prevents leakage of more than 1 bit of un-guessed Passkey information in the case of a MITM attack. A MITM attacker with only partial knowledge of the Passkey will only receive one incorrectly-guessed bit of the Passkey before the protocol fails. Hence, a MITM attacker who engages first one side, then the other will only gain an advantage of at most two bits over a simple brute-force guesser, making the probability of success 0.000004 instead of 0.000001.

The long nonce is included in the commitment hash to make it difficult to brute-force even after the protocol has failed. The public Diffie-Hellman values are included to tie the Passkey protocol to the original ECDH key exchange, to prevent a MITM from substituting the attacker's public key on both sides of the ECDH exchange in standard MITM fashion.

At the end of this stage, Na is set to Na20 and Nb is set to Nb20 for use in Authentication stage 2.

The second stage of authentication then confirms that both devices have successfully completed the exchange. This stage is identical in all three protocols and is shown in Figure 7.7.

Each device computes a new confirmation value that includes the previously exchanged values and the newly derived shared key (step 9). The initiating device then transmits its confirmation value which is checked by the responding device (step 10). If this check fails, it indicates that the initiating device has not confirmed the pairing, and the protocol shall be aborted. The responding device then transmits its confirmation value which is checked by the initiating device (step 11). A failure indicates that the responding device has not confirmed the pairing and the protocol should abort.

Figure 7.7: Authentication stage 2

Once both sides have confirmed the pairing, a link key is computed from the derived shared key and the publicly exchanged data (step 12). The nonces ensure the freshness of the key even if long-term ECDH values are used by both sides. This link key is used to maintain the pairing.

When computing the link key both parties shall input the parameters in the same order (shown in Figure 7.8) to ensure that both devices compute the same key: Nc is whichever of Na and Nb was generated by the Central and Np is the other, while BD_ADDR_C and BD_ADDR_P are the addresses of the Central and Peripheral respectively.

Figure 7.8: Link key calculation

The final phase in Secure Simple Pairing consists of authentication and generation of the encryption key. This is the same as the final steps in legacy pairing.

Secure Simple Pairing supports two elliptic curves: P-192 and P-256.

Secure Simple Pairing uses the FIPS P-192 and P-256 curves defined in FIPS 186-4^[5]. Elliptic curves are specified by p, a, b and are of the form:

In NIST P-192 and P-256, a is -3 and the following parameters are given:

The function P192 is defined as follows. Given an integer u, 0 < u < r, and a point V on the curve E, the value P192(u,V) is computed as the x-coordinate of the u^th multiple uV of the point V.

The private keys shall be between 1 and r/2, where r is the order of the Abelian group on the elliptic curve (i.e., between 1 and 2¹⁹²/2).

The function P256 is defined as follows. Given an integer u, 0 < u < r, and a point V on the curve E, the value P256(u, V) is computed as the x-coordinate of the u^th multiple uV of the point V.

The private keys shall be between 1 and r/2, where r is the order of the Abelian group on the elliptic curve (i.e., between 1 and 2²⁵⁶/2).

A valid public key Q = (X_Q, Y_Q) is one where X_Q and Y_Q are both in the range 0 to p - 1 and satisfy the equation (Y_Q)² = (X_Q)³ + aX_Q + b (mod p) in the relevant curve's finite field.

A device can validate a public key by directly checking the curve equation, by implementing elliptic curve point addition and doubling using formulas that are valid only on the correct curve, or by other means.

In addition to computing the Elliptic Curve Diffie Hellman key, the Numeric Comparison, Out-of-Band and Passkey Entry protocols require four cryptographic functions. These functions are known as f1, g, f2 and f3.

The basic building block for these functions is based on SHA-256, specified in [FIPS PUB 180-4] (http://dx.doi.org/10.6028/NIST.FIPS.180-4).

Inside the f1, g, f2, and f3 cryptographic functions, when a multi-octet integer input parameter is used as input to the SHA-256 and HMAC-SHA-256 functions, the most significant octet of the integer parameter shall be the first octet of the stream and the least significant octet of the integer parameter shall be the last octet of the stream. The output of the f1, g, f2, and f3 cryptographic functions is a multi-octet integer where the first octet out of SHA-256 and HMAC-SHA-256 shall be the MSB and the last octet shall be the LSB of that parameter.

All of the parameters in the nonce are unique per logical transport. The nonce will be 13 octets and will have two formats. The first format is called the payload counter format and is used for ACL packets on the primary LT_ADDR. The second format is called the clock format and is used for eSCO packets.

The reason for two formats has to do with two factors: potential security attacks and synchronization. Since ACL packets on the primary LT_ADDR carry protocol, they are susceptible to attacks that eSCO packets (only data) are not.

The descriptions of the two nonce formats are provided in Table 9.1.

In the payload counter format, the PayloadCounter starts at zero for the first encrypted packet in each direction after encryption is started or resumed and increments every time an encrypted payload including zero-length payloads is accepted by the remote device.

Bit 4 of Octet 4 shall be set to 1 for a zero length ACL-U continuation packet (see [Vol 2] Part B, Section 7.6.2.2), otherwise it shall be set to 0.

In the clock format, the Central's clock (CLK) used for the nonce shall be the value in the first slot of the packet. After a new ACL connection has been established or a role switch has been successfully performed and when eSCO is successfully established for the first time then the dayCounter value shall be initialized to:

After the dayCounter has been initialized, it shall increment every time the Central's clock (CLK) rolls over to 0x0000000 (approximately every 23.3 hours).

The IV is an 8 octet field. For encryption start, all octets of the IV are from the ACO output of the last execution of h5 prior to the start of encryption. Multiple device authentications may occur prior to starting encryption but only the ACO of the last device authentication is used. After an encryption resume, all 8 octets of the IV are from the EN_RAND sent by the device initiating the encryption pause (see [Vol 2] Part C, Section 4.2.5.5). An encryption pause and resume will be required prior to the PayloadCounter or dayCounter rolling over in order to keep the nonce fresh for an encryption key.

For calculating the MIC, the payload is broken into two or more counter mode blocks. The CCM specification refers to these blocks as blocks B₀ – B_n. B₀ applies to the nonce, B₁ applies to the associated data {that is packet header and payload header} and additional B blocks are generated as needed for authentication of the payload body.

The CCM algorithm uses the A_i blocks to generate a keystream that is used to encrypt the MIC and payload body. Block A₀ is always used to encrypt and decrypt the MIC, when present. Block A₁ is always used to encrypt and decrypt the first 16 octets of the payload body. Subsequent blocks are always used to encrypt and decrypt the rest of the payload body as needed.

When the devices have negotiated a key size shorter than the maximum length, the key will be shortened by replacing the appropriate number of least significant octets of the key with 0x00.

For example, if a 128-bit encryption key is

and it is reduced to 7 octets (56 bits), then the resulting key is

Anytime the MIC check fails and the CRC passes on a given packet, it is considered an authentication failure. No more than three authentication failures shall be permitted during the lifetime of an encryption key with a given IV. The third authentication failure shall initiate an encryption key refresh (see [Vol 2] Part C, Section 4.2.5.8). If a fourth authentication failure occurs prior to the encryption key refresh procedure completing, the link shall be disconnected with reason code Connection Rejected Due to Security Reasons (0x0E).