Bluetooth Core Specification

When multiple bit fields are contained in a single octet and represented in a drawing in this Part, the least significant (low-order) bits are shown toward the left and most significant (high-order) bits toward the right.

Multiple-octet fields are drawn with the least significant octets toward the left and the most significant octets toward the right. Multiple-octet fields shall be transmitted with the least significant octet first.

Multiple-octet values written in hexadecimal notation have the most significant octet towards the left and the least significant octet towards the right, for example if ‘12’ is the most significant octet and ‘34’ is the least significant octet it would be written as 0x1234.

In [Vol 3] Part H, the term "random number" includes pseudo-random numbers. Random number generators should conform to the requirements of [Vol 2] Part H, Section 2.

Security function e generates 128-bit encryptedData from a 128-bit key and 128-bit plaintextData using the AES-128-bit block cypher as defined in FIPS-197¹:

encryptedData = e(key, plaintextData)

The most significant octet of key corresponds to key[0], the most significant octet of plaintextData corresponds to in[0] and the most significant octet of encryptedData corresponds to out[0] using the notation specified in FIPS-197¹.

The random address hash function ah is used to generate a hash value that is used in resolvable private addresses, see [Vol 3] Part C, Section 10.8.2.

The following are inputs to the random address hash function ah:

r is concatenated with padding to generate r' which is used as the 128-bit input parameter plaintextData to security function e:

The least significant octet of r becomes the least significant octet of r’ and the most significant octet of padding becomes the most significant octet of r’.

For example, if the 24-bit value r is 0x423456 then r’ is 0x00000000000000000000000000423456.

The output of the random address function ah is:

The output of the security function e is then truncated to 24 bits by taking the least significant 24 bits of the output of e as the result of ah.

During the LE legacy pairing process confirm values are exchanged. This confirm value generation function c1 is used to generate the confirm values.

The following are inputs to the confirm value generation function c1:

iat is concatenated with 7 zero bits to create iat’ which is 8 bits in length. iat is the least significant bit of iat’.

rat is concatenated with 7 zero bits to create rat’ which is 8 bits in length. rat is the least significant bit of rat’.

pres, preq, rat’ and iat’ are concatenated to generate p1 which is XORed with r and used as 128-bit input parameter plaintextData to security function e:

The octet of iat’ becomes the least significant octet of p1 and the most significant octet of pres becomes the most significant octet of p1.

For example, if the 8-bit iat’ is 0x01, the 8-bit rat’ is 0x00, the 56-bit preq is 0x07071000000101 and the 56 bit pres is 0x05000800000302 then p1 is 0x05000800000302070710000001010001.

ra is concatenated with ia and padding to generate p2 which is XORed with the result of the security function e using p1 as the input parameter plaintextData and is then used as the 128-bit input parameter plaintextData to security function e:

The least significant octet of ra becomes the least significant octet of p2 and the most significant octet of padding becomes the most significant octet of p2.

For example, if 48-bit ia is 0xA1A2A3A4A5A6 and the 48-bit ra is 0xB1B2B3B4B5B6 then p2 is 0x00000000A1A2A3A4A5A6B1B2B3B4B5B6.

The output of the confirm value generation function c1 is:

The 128-bit output of the security function e is used as the result of confirm value generation function c1.

For example, if the 128-bit k is 0x00000000000000000000000000000000, the 128-bit value r is 0x5783D52156AD6F0E6388274EC6702EE0, the 128-bit value p1 is 0x05000800000302070710000001010001 and the 128-bit value p2 is 0x00000000A1A2A3A4A5A6B1B2B3B4B5B6 then the 128-bit output from the c1 function is 0x1E1E3FEF878988EAD2A74DC5BEF13B86.

The key generation function s1 is used to generate the STK during the LE legacy pairing process.

The following are inputs to the key generation function s1:

The most significant 64-bits of r1 are discarded to generate r1’ and the most significant 64-bits of r2 are discarded to generate r2’.

For example if the 128-bit value r1 is 0x000F0E0D0C0B0A091122334455667788 then r1’ is 0x1122334455667788. If the 128-bit value r2 is 0x010203040506070899AABBCCDDEEFF00 then r2’ is 0x99AABBCCDDEEFF00.

r1’ is concatenated with r2’ to generate r’ which is used as the 128-bit input parameter plaintextData to security function e:

The least significant octet of r2’ becomes the least significant octet of r’ and the most significant octet of r1’ becomes the most significant octet of r’.

For example, if the 64-bit value r1’ is 0x1122334455667788 and r2’ is 0x99AABBCCDDEEFF00 then r’ is 0x112233445566778899AABBCCDDEEFF00.

The output of the key generation function s1 is:

The 128-bit output of the security function e is used as the result of key generation function s1.

For example if the 128-bit value k is

and the 128-bit value r' is

then the output from the key generation function s1 is

RFC-4493² defines the Cipher-based Message Authentication Code (CMAC) that uses AES-128 as the block cipher function, also known as AES-CMAC.

The inputs to AES-CMAC are:

The 128-bit message authentication code (MAC) is generated as follows:³

A device can implement AES functions in the Host or can use the HCI_LE_Encrypt command (see [Vol 4] Part E, Section 7.8.22) in order to use the AES function in the Controller.

During the LE Secure Connections pairing process, confirm values are exchanged. These confirm values are computed using the confirm value generation function f4.

This confirm value generation function makes use of the MAC function AES-CMAC_X, with a 128-bit key X.

The inputs to function f4 are:

Z is zero (i.e. 8 bits of zeros) for Numeric Comparison and OOB protocol. In the Passkey Entry protocol, the most significant bit of Z is set equal to one and the least significant bit is made up from one bit of the passkey e.g. if the passkey bit is 1, then Z = 0x81 and if the passkey bit is 0, then Z = 0x80.

U, V and Z are concatenated and used as input m to the function AES-CMAC and X is used as the key k.

The inputs to f4 are different depending on different association models:

PKax denotes the x-coordinate of the public key PKa of A.

Similarly, PKbx denotes the x-coordinate of the public key PKb of B.

Nai is the nonce value of i^th round. For each round Nai value is a new 128-bit number. Similarly, rai is a one bit value of the passkey expanded to 8 bits (either 0x80 or 0x81).

Na and Nb are nonces from Devices A and B. ra and rb are random values generated by devices A and B.

The output of the confirm value generation function f4 is as follows:

The least significant octet of Z becomes the least significant octet of the AES-CMAC input message m and the most significant octet of U becomes the most significant octet of the AES-CMAC input message m.

The LE Secure Connections key generation function f5 is used to generate derived keying material in order to create the LTK and keys for the commitment function f6 during the LE Secure Connections pairing process.

The definition of this key generation function makes use of the MAC function AES-CMAC_T with a 128-bit key T.

The inputs to function f5 are:

The key (T) is computed as follows:

SALT is the 128-bit value:

Counter, keyID, N1, N2, A1, A2, and Length are concatenated and used as input m to the function AES-CMAC and T is used as the key k.

Counter is one octet. Length is two octets.

The string “btle” is mapped into a keyID using ASCII as 0x62746C65.

The output of the key generation function f5 is as follows:

The least significant octet of Length becomes the least significant octet of the AES-CMAC input message m and the most significant octet of Counter becomes the most significant octet of the AES-CMAC input message m.

The LTK and MacKey are calculated as:

DHKey is the shared secret Diffie-Hellman key generated during LE Secure Connections pairing phase 2.

Nc is whichever of N1 and N2 was generated by the Central and sent to the Peripheral; Np is the other.

BD_ADDR_C is the device address of the Central and BD_ADDR_P is the device address of the Peripheral. The device addresses are the values used during connection setup. The least significant bit in the most significant octet in both BD_ADDR_C and BD_ADDR_P is set to 1 if the address is a random address and set to 0 if the address is a public address. The 7 most significant bits of the most significant octet in both BD_ADDR_C and BD_ADDR_P are set to 0.

The LTK is the least significant 128 bits (Counter = 1) of f5. The MacKey (see Section 2.2.8) is the most significant 128 bits (Counter = 0) of f5.

A device can implement Diffie-Hellman key generation in the Host or can use the HCI_LE_Generate_DHKey command (see [Vol 4] Part E, Section 7.8.37) to generate the key in the Controller.

The LE Secure Connections check value generation function f6 is used to generate check values during authentication stage 2 of the LE Secure Connections pairing process.

The definition of the f6 function makes use of the MAC function AES-CMAC_W with a 128-bit key W.

The inputs to function f6 are:

N1, N2, R, IOcap, A1 and A2 are concatenated and used as input m to the function AES-CMAC and W is used as the key k.

The inputs to f6 are different depending on different association models:

MacKey is the 128-bit MSBs of the output of f5.

Na is the random number sent by the Central to the Peripheral and Nb is the random number sent by the Peripheral to the Central.

IOcapA is the capabilities of the Central and IOcapB is the capabilities of the Peripheral. IOcapA and IOcapB are both three octets with the most significant octet as the AuthReq parameter, the middle octet as the OOB data flag and the least significant octet as the IO capability parameter. The AuthReq, OOB data flag and IO capability parameters are present in the Pairing Request and Pairing Response SMP packets.

In Passkey Entry, ra and rb are 6-digit passkey values expressed as a 128-bit integer. For instance, if the 6-digit value of ra is 131313 then

A is the device address of the Central and B is the device address of the Peripheral. The least significant bit in the most significant octet in both A and B is set to 1 if the address is a random address and set to 0 if the address is a public address. The 7 most significant bits of the most significant octet in both A and B are set to 0.

The output of the check value generation function f6 is as follows:

The least significant octet of A2 becomes the least significant octet of the AES-CMAC input message m and the most significant octet of N1 becomes the most significant octet of the AES-CMAC input message m.

The LE Secure Connections numeric comparison value generation function g2 is used to generate the numeric comparison values during authentication stage 1 of the LE Secure Connections pairing process.

The definition of g2 makes use of the MAC function AES-CMAC_X with 128-bit key X.

The inputs to function g2 are:

U, V, and Y are concatenated and used as input m to the function AES-CMAC and X is used as the key k.

The output of the numeric comparison value generation function g2 is as follows:

The least significant octet of Y becomes the least significant octet of the AES-CMAC input message m and the most significant octet of U becomes the most significant octet of the AES-CMAC input message m.

The numeric verification value is taken as the six least significant digits of the 32-bit integer g2(PKax, PKbx, Na, Nb) where PKax denotes the x-coordinate of the public key PKa of A and PKbx denotes the x-coordinate of the public key PKb of B. Na and Nb are nonces from devices A and B. The value is then converted to decimal numeric value. The checksum used for numeric comparison is the least significant six digits.

For example, if output = 0x 01 2e b7 2a then decimal value = 19838762 and the checksum used for numeric comparison is 838762.

The function h6 is used to convert keys of a given size from one key type to another key type with equivalent strength.

The definition of the h6 function makes use of the hashing function AES-CMAC_W with 128-bit key W.

The inputs to function h6 are:

keyID is used as input m to the hashing function AES-CMAC and the most significant 128-bits of W are used as the key k (2.2.5).

The output of h6 is as follows:

The function h7 is used to convert keys of a given size from one key type to another key type with equivalent strength.

The definition of the h7 function makes use of the hashing function AES-CMAC_SALT with 128-bit key SALT.

The inputs to function h7 are:

W is used as input m to the hashing function AES-CMAC and SALT is used as the key k (2.2.5).

The output of h7 is as follows:

Security Properties provided by SM are classified into the following categories:

LE Secure Connections pairing utilizes the P-256 elliptic curve (see [Vol 2] Part H, Section 7.6).

In LE legacy pairing, Authenticated man-in-the-middle (MITM) protection is obtained by using the passkey entry pairing method or may be obtained using the out of band pairing method. In LE Secure Connections pairing, Authenticated man-in-the-middle (MITM) protection is obtained by using the passkey entry pairing method or the numeric comparison method or may be obtained using the out of band pairing method. To ensure that Authenticated MITM Protection is generated, the selected Authentication Requirements option must have MITM protection specified.

Unauthenticated no MITM Protection does not have protection against MITM attacks.

For LE Legacy Pairing, none of the pairing methods provide protection against a passive eavesdropper during the pairing process as predictable or easily established values for TK are used. If the pairing information is distributed without an eavesdropper being present then all the pairing methods provide confidentiality.

An initiating device shall maintain a record of the Security Properties for the distributed keys in a security database.

A responding device may maintain a record of the distributed key sizes and Security Properties for the distributed keys in a security database. Depending upon the key generation method and negotiated key size a responding device may have to shorten the key length (see Section 2.3.4) so that the initiator and responder are using identical keys.

Security Properties of the key generated in phase 2 under which the keys are distributed shall be stored in the security database.

Input and output capabilities of a device are combined to generate its IO capabilities. The input capabilities are described in Table 2.3. The output capabilities are described in Table 2.4.

The individual input and output capabilities are mapped to a single IO capability for that device which is used in the pairing feature exchange. The mapping is described in Table 2.5.

An out of band mechanism may be used to communicate information which is used during the pairing process. The information shall be a sequence of AD structures (see [Vol 3] Part C, Section 11).

The OOB data flag shall be set if a device has the peer device's out of band authentication data. A device uses the peer device's out of band authentication data to authenticate the peer device. In LE legacy pairing, the out of band method is used if both the devices have the other device's out of band authentication data available. In LE Secure Connections pairing, the out of band method is used if at least one device has the peer device's out of band authentication data available.

Each device shall have maximum and minimum encryption key length parameters which defines the maximum and minimum size of the encryption key allowed in octets. The maximum and minimum encryption key length parameters shall be between 7 octets (56 bits) and 16 octets (128 bits), in 1 octet (8 bit) steps. This is defined by a profile or device application.

The shorter of the initiating and responding devices’ maximum encryption key length parameters shall be used as the encryption key size.

Both the initiating and responding devices shall check that the resultant encryption key size is not shorter than the minimum key size parameter for that device and if it is, the device shall send the Pairing Failed command with error code “Encryption Key Size”.

The encryption key size may be stored so it can be checked by any service that has minimum encryption key length requirements.

If a key has an encryption key size that is shorter than 16 octets (128 bits), it shall be created by masking the appropriate number of most significant octets of the generated key to provide a resulting key that has the agreed encryption key size. The key shall be masked after generation and, if required, after the key is used to derive a BR/EDR link key. The key shall be masked before the key is distributed, used for encryption, or stored.

For example, if a 128-bit encryption key is

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

The information exchanged in Phase 1 is used to select which key generation method is used in Phase 2.

When LE legacy pairing is used, the pairing is performed by each device generating a Temporary Key (TK). The method to generate TK depends upon the pairing method chosen using the algorithm described in Section 2.3.5.1. If Just Works is used then TK shall be generated as defined in Section 2.3.5.2. If Passkey Entry is used then TK shall be generated as defined in Section 2.3.5.3. If Out Of Band is used then TK shall be generated as defined in Section 2.3.5.4. The TK value shall be used in the authentication mechanism defined in Section 2.3.5.5 to generate the STK and encrypt the link.

2.3.5.6. LE Secure Connections pairing phase 2

The Long Term Key is generated in LE Secure Connections pairing phase 2.

2.3.5.6.1. Public key exchange

Initially, each device generates its own Elliptic Curve Diffie-Hellman (ECDH) public-private key pair (phase 1). The public-private key pair contains a private (secret) key, and a public key. The private keys of devices A and B are denoted as SKa and SKb respectively. The public keys of devices A and B are denoted as PKa and PKb respectively. See Section 2.3.6 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 (phase 1a). The responding device replies with its own public key (phase 1b). If the two public keys have the same X coordinate and neither is the debug key, each device shall fail the pairing process. These public keys are not regarded as secret although they may identify the devices.

Figure 2.2: Public key exchange

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

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. See [Vol 2] Part H, Section 7.6 for the values of a, b, and p.

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.

A device that detects an invalid public key from the peer at any point during the LE Secure Connections pairing process shall not use the resulting LTK, if any.

After the public keys have been exchanged, the device can then start computing the Diffie-Hellman Key.

When the Security Manager is placed in a Debug mode it shall use the following Diffie-Hellman private / public key pair:

Private key: 3f49f6d4 a3c55f38 74c9b3e3 d2103f50 4aff607b eb40b799 5899b8a6 cd3c1abd Public key (X): 20b003d2 f297be2c 5e2c83a7 e9f9a5b9 eff49111 acf4fddb cc030148 0e359de6 Public key (Y): dc809c49 652aeb6d 63329abf 5a52155c 766345c2 8fed3024 741c8ed0 1589d28b

If a device receives this debug public key and it is in a mode in which it cannot accept the debug key then it may send the Pairing Failed command with the reason set to "Invalid Parameters".

Note

Note: Only one side (initiator or responder) needs to set Secure Connections debug mode in order for debug equipment to be able to determine the LTK and, therefore, be able to monitor the encrypted connection.

2.3.5.6.2. Authentication stage 1 – Just Works or Numeric Comparison

The Numeric Comparison association model will be used during pairing if the MITM bit is set to 1 in the Authentication Requirements in the Pairing Request PDU and/or Pairing Response PDU and both devices have IO capabilities set to either DisplayYesNo or KeyboardDisplay.

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

Figure 2.3: "Authentication stage 1: Just Works or Numeric Comparison, LE Secure Connections

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 shall be generated using a random number generator that meets the requirements of [Vol 2] Part H, Section 2.

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 new nonces shall be generated if the protocol is repeated.

When Just Works is used, the commitment checks (steps 7a and 7b) are not performed and the user is not shown the 6-digit values.

When Numeric Comparison is used, 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 shall 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.

2.3.5.6.3. Authentication stage 1 – Passkey Entry

The Passkey Entry protocol is used when SMP 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 2.4.

Figure 2.4: Authentication stage 1: Passkey Entry, LE Secure Connections

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.

2.3.5.6.4. Authentication stage 1 – Out of Band

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 data flag parameter included in the SMP Pairing Request and SMP Pairing Response PDU. 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 2.5.

Figure 2.5: Authentication stage 1: Out of Band, LE Secure Connections

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.

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 data flag sent in the SMP Pairing Request or SMP Pairing Response is set to “OOB Authentication data not present”, it sets its own r value to 0 (Step 5)

2.3.5.6.5. Authentication stage 2 and long term key calculation

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 2.6.

Each device computes the MacKey and the LTK using the previously exchanged values and the newly derived shared key (step 9). Each device then computes a new key confirmation value that includes the previously exchanged values and the newly derived MacKey (step 10a and 10b). The initiating device then transmits its key confirmation value, which is checked by the responding device (step 11). 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 key confirmation value, which is checked by the initiating device (step 12). A failure indicates that the responding device has not confirmed the pairing and the protocol shall abort.

Figure 2.6: Authentication stage 2 and long term key calculation

When a pairing procedure fails a waiting interval shall pass before the verifier will initiate a new Pairing Request command or Security Request command to the same claimant, or before it will respond to a Pairing Request command or Security Request command initiated by a device claiming the same identity as the failed device. For each subsequent failure, the waiting interval shall be increased exponentially. That is, after each failure, the waiting interval before a new attempt can be made, could be for example, twice as long as the waiting interval prior to the previous attempt⁴. The waiting interval should 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 pairing 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.

LE security uses the following keys and values for encryption, signing, and random addressing:

Any method of generation of keys that are being distributed that results in the keys having 128 bits of entropy can be used, as the generation method is not visible outside the Peripheral (see Appendix B). The keys shall not be generated only from information that is distributed to the Central or only from information that is visible outside of the Peripheral.

Key distribution for LE Legacy Pairing and LE Secure Connections is described in the following sections.

During the encrypted session setup the Central sends a 16-bit Encrypted Diversifier value, EDIV, and a 64-bit Random Number, Rand, distributed by the Peripheral during pairing, to the Peripheral. The Central’s Host provides the Link Layer with the Long Term Key to use when setting up the encrypted session. The Peripheral’s Host receives the EDIV and Rand values and provides a Long Term Key to the Peripheral’s Link Layer to use when setting up the encrypted link.

When both devices support LE Secure Connections, the EDIV and Rand are set to zero.

An LE device can send signed data without having to establish an encrypted session with a peer device. Data shall be signed using CSRK. A device performing signature verification must have received CSRK from the signing device. The sending device will use its CSRK to sign the transmitted data.

The following are inputs to the signing algorithm:

Signing shall be performed using the algorithm defined in the NIST Special Publication 800-38B [1] using AES-128 as the block cipher. NIST SP 800-38B defines the message authentication code (MAC) generation function:

The bit length of the MAC (Tlen) shall be 64 bits. The key used for signature generation (k) shall be set to CSRK.

The message to be signed (M) by the CMAC function is the concatenation of the variable length message to be signed (m) and 4 octet string representing the 32-bit counter value (SignCounter) least significant octet first.

For example, if data to be signed is the 7 octet sequence ‘3456789ABCDEF1’ and SignCounter is set to 67653874 (0x040850F2) then M is the octet sequence ‘3456789ABCDEF1F2500804’. Examples of CMAC generation using AES-128 as the block cipher are included in NIST Special Publication 800-38B Appendix D.

The SignCounter shall be initialized to zero when CSRK is generated and incremented for every message that is signed with a given CSRK.

The 64-bit result of the CMAC function is used as the result of the signing algorithm.

To verify a signature a device computes the MAC of a received message and SignCounter and compares it with the received MAC. If the MAC does not match then the signature verification has failed. If the MACs match then the signature verification has succeeded.

The device performing verification should store the last verified SignCounter in the security database and compare it with a received SignCounter to prevent replay attacks. If the received SignCounter is greater than the stored value then the message has not been seen by the local device before and the security database can be updated.

The Peripheral may request security by transmitting a Security Request command to the Central. When a Central receives a Security Request command it may encrypt the link, initiate the pairing procedure, or reject the request.

The Peripheral shall not send the Security Request command if the pairing procedure is in progress, or if the encryption procedure is in progress.

The Security Request command includes the required security properties. A security property of MITM protection required shall only be set if the Peripheral’s IO capabilities would allow the Passkey Entry association model to be used or out of band authentication data is available.

The Central shall ignore the Peripheral’s Security Request if the Central has sent a Pairing Request without receiving a Pairing Response from the Peripheral or if the Central has initiated encryption mode setup.

If pairing or encryption mode is not supported or cannot be initiated at the time when the Peripheral’s Security Request command is received, then the Central shall respond with a Pairing Failed command with the reason set to “Pairing Not Supported.”

After receiving a Security Request, the Central shall first check whether it has the required security information to enable encryption; see Section 2.4.4.2. If this information is missing or does not meet the security properties requested by the Peripheral, then the Central shall initiate the pairing procedure. If the pairing procedure is successful, the Central’s security database is updated with the keys and security properties are distributed during the pairing procedure.

If the Central has the required security information to enable encryption and it meets the security properties request by the Peripheral, it shall perform encryption setup using LTK, see Section 2.4.4.2.

Figure 2.7 shows a summary of the actions and decisions that a Central shall take when receiving a Security Request.

The Peripheral shall check that any Pairing Request command received from the Central after sending a Security Request command contains Authentication Requirements that meet the requested security properties.

If the Peripheral requests a security property that is not Just Works and receives an encryption procedure request after sending a Security Request command then it shall check that any existing Security Information is of sufficient security properties.

Figure 2.7: Central actions after receiving Security Request command

The initiator starts the Pairing Feature Exchange by sending a Pairing Request command to the responding device. The Pairing Request command is defined in Figure 3.2.

The rules for handing a collision between a pairing procedure on the LE transport and a pairing procedure on the BR/EDR transport are defined in [Vol 3] Part C, Section 14.2.

Figure 3.2: Pairing Request packet

The following data fields are used:

Figure 3.3: Authentication requirements flags

If Secure Connections pairing has been initiated over BR/EDR, the following fields of the SM Pairing Request PDU are reserved for future use:

This command is used by the responding device to complete the Pairing Feature Exchange after it has received a Pairing Request command from the initiating device, if the responding device allows pairing. The Pairing Response command is defined in Figure 3.4.

The rules for handing a collision between a pairing procedure on the LE transport and a pairing procedure on the BR/EDR transport are defined in [Vol 3] Part C, Section 14.2.

If a Pairing Request is received over the BR/EDR transport when either cross-transport key derivation/generation is not supported or the BR/EDR transport is not encrypted using a Link Key generated using P256, a Pairing Failed shall be sent with the error code Cross-Transport Key Derivation/Generation Not Allowed (0x0E).

If a Pairing Request is received and the device is not ready to perform the pairing procedure, a Pairing Failed may be sent with the error code Busy (0x10).

Figure 3.4: Pairing Response packet

The following data fields are used:

If Secure Connections pairing has been initiated over BR/EDR, the following fields of the SM Pairing Response PDU are reserved for future use:

This is used following a successful Pairing Feature Exchange to start STK Generation for LE legacy pairing and LTK Generation for LE Secure Connections pairing. The Pairing Confirm command is defined in Figure 3.5.

This command is used by both devices to send the confirm value to the peer device, see Section 2.3.5.5 for LE legacy pairing and Section 2.3.5.6 for LE Secure Connections pairing.

The initiating device starts key generation by sending the Pairing Confirm command to the responding device. If the initiating device wants to abort pairing it can transmit a Pairing Failed command instead.

The responding device sends the Pairing Confirm command after it has received a Pairing Confirm command from the initiating device.

Figure 3.5: Pairing Confirm packet

The following data field is used:

This command is used by the initiating and responding device to send the random number used to calculate the Confirm value sent in the Pairing Confirm command. The Pairing Random command is defined in Figure 3.6.

The initiating device sends a Pairing Random command after it has received a Pairing Confirm command from the responding device.

In LE legacy pairing, the responding device shall send a Pairing Random command after it has received a Pairing Random command from the initiating device if the Confirm value calculated on the responding device matches the Confirm value received from the initiating device. If the calculated Confirm value does not match then the responding device shall respond with the Pairing Failed command.

In LE Secure Connections, the responding device shall send a Pairing Random command after it has received a Pairing Random command from the initiating device. If the calculated Confirm value does not match then the responding device shall respond with the Pairing Failed command.

The initiating device shall encrypt the link using the generated key (STK in LE legacy pairing or LTK in LE Secure Connections) if the Confirm value calculated on the initiating device matches the Confirm value received from the responding device. The successful encryption or re-encryption of the link is the signal to the responding device that key generation has completed successfully. If the calculated Confirm value does not match then the initiating device shall respond with the Pairing Failed command.

Figure 3.6: Pairing Random packet

The following are the data fields:

This is used when there has been a failure during pairing and reports that the pairing procedure has been stopped and no further communication for the current pairing procedure is to occur. The Pairing Failed command is defined in Figure 3.7.

Any subsequent pairing procedure shall restart from the Pairing Feature Exchange phase.

This command may be sent at any time during the pairing process by either device in response to a message from the remote device.

During LE Secure Connections pairing, this command shall be sent if the remote device's public key is invalid (see Section 2.3.5.6.1). The Reason field shall be set to "DHKey Check Failed".

Figure 3.7: Pairing Failed packet

The following data field is used:

The Reason field indicates why the pairing failed. The reason codes are defined in Table 3.7.

This message is used to transfer the device’s local public key (X and Y co-ordinates) to the remote device. This message is used by both the initiator and responder. This PDU is only used for Secure Connections. Its format is specified in Figure 3.8.

Figure 3.8: Pairing Public Key PDU

This message is used to transmit the 128-bit DHKey Check values (Ea and Eb) generated using f6. These are confirmation values generated using the DHKey. This message is used by both initiator and responder. This PDU is only used for LE Secure Connections. Its format is specified in Figure 3.9.

Figure 3.9: Pairing DHKey Check PDU

This message is used during the Passkey Entry protocol by a device with KeyboardOnly IO capabilities to inform the remote device when keys have been entered or erased. Its format is specified in Figure 3.10.

Figure 3.10: Pairing Keypress Notification PDU

Notification Type can take one of the following values:

Bluetooth Low Energy devices can distribute keys from the Peripheral to the Central and from the Central to the Peripheral. When using LE legacy pairing, the following keys may be distributed from the Peripheral to the Central:

When using LE Secure Connections, the following keys may be distributed from the Peripheral to the Central:

When using LE legacy pairing, the Central may distribute to the Peripheral the following key:

When using LE Secure Connections, the Central may distribute to the Peripheral the following key:

The keys which are to be distributed in the Transport Specific Key Distribution phase are indicated in the Key Distribution field of the Pairing Request and Pairing Response commands see Section 3.5.1 and Section 3.5.2.

The format of the Initiator Key Distribution / Generation field and Responder Key Distribution / Generation field in the Pairing Request and Pairing Response commands for LE is defined in Figure 3.11.

Figure 3.11: LE Key Distribution format

The Key Distribution / Generation field has the following flags:

The Initiator Key Distribution / Generation field in the Pairing Request command is used by the Central to request which keys are distributed or generated by the initiator to the responder. The Responder Key Distribution / Generation field in the Pairing Request command is used by the Central to request which keys are distributed or generated by the responder to the initiator. The Initiator Key Distribution / Generation field in the Pairing Response command from the Peripheral defines the keys that shall be distributed or generated by the initiator to the responder. The Responder Key Distribution / Generation field in the Pairing Response command from the Peripheral defines the keys that shall be distributed or generated by the responder to the initiator. The Peripheral shall not set to one any flag in the Initiator Key Distribution / Generation or Responder Key Distribution / Generation field of the Pairing Response command that the Central has set to zero in the Initiator Key Distribution / Generation and Responder Key Distribution / Generation fields of the Pairing Request command.

When using LE legacy pairing, the keys shall be distributed in the following order:

When using LE Secure Connections, the keys shall be distributed in the following order:

If a key is not being distributed then the command to distribute that key shall not be sent.

A device may reject a distributed key by sending the Pairing Failed command with the reason set to "Key Rejected".

If EncKey, IdKey, and SignKey are set to zero in the Initiator Key Distribution / Generation and Responder Key Distribution / Generation fields, then no keys shall be distributed or generated and the link will be encrypted using the generated STK when using LE legacy pairing and LTK when using LE Secure Connections pairing.

Key distribution is complete in the device sending the final key when it receives the Baseband acknowledgment for that key and is complete in the receiving device when it receives the final key being distributed.

Encryption Information is used in the LE legacy pairing Transport Specific Key Distribution to distribute LTK that is used when encrypting future connections. The Encryption Information command is defined in Figure 3.12.

The Encryption Information command shall only be sent when the link has been encrypted or re-encrypted using the generated STK.

Figure 3.12: Encryption Information packet

The following is the data field:

Central Identification is used in the LE legacy pairing Transport Specific Key Distribution phase to distribute EDIV and Rand which are used when encrypting future connections. The Central Identification command is defined in Figure 3.13.

The Central Identification command shall only be sent when the link has been encrypted or re-encrypted using the generated STK.

Figure 3.13: Central Identification packet

The following data fields are used:

Identity Information is used in the Transport Specific Key Distribution phase to distribute the IRK. The Identity Information command is defined in Figure 3.14.

The Identity Information command shall only be sent when the link has been encrypted or re-encrypted using the generated key.

Figure 3.14: Identity Information packet

The following are the data fields:

Identity Address Information is used in the Transport Specific Key Distribution phase to distribute its public device address or static random address. The Identity Address Information command is defined in Figure 3.15.

The Identity Address Information command shall only be sent when the link has been encrypted or re-encrypted using the generated key.

Figure 3.15: Identity Address Information packet

The data fields are:

Signing Information is used in the Transport Specific Key Distribution to distribute the CSRK which a device uses to sign data. The Signing Information command is defined in Figure 3.16.

The Signing Information command shall only be sent when the link has been encrypted or re-encrypted using the generated key.

Figure 3.16: Signing Information packet

The following data field is used:

The Security Request command is used by the Peripheral to request that the Central initiates security with the requested security properties, see Section 2.4.6. The Security Request command is defined in Figure 3.17.

Figure 3.17: Security Request packet

The following data field is used:

DIV is masked before distribution and unmasked during the encryption session setup using the output of the DIV mask generation function dm.

The following are inputs to the DIV mask generation function dm:

r is concatenated with padding to generate r’ which is used as the 128-bit input parameter plaintextData to security function e:

The least significant octet of r becomes the least significant octet of r’ and the most significant octet of padding becomes the most significant octet of r’.

For example, if the 64-bit value r is 0x123456789ABCDEF0 then r’ is 0x0000000000000000123456789ABCDEF0.

The output of the DIV mask generation function dm is

The output of the security function e is then truncated to 16 bits by taking the least significant 16 bits of the output of e as the result of dm.

The responding device generates a 64-bit random value, Rand. The Rand value is used to generate 16-bit Y using the DIV mask generation function dm with the input parameter k set to DHK and the input parameter r set to Rand.

The responding device then masks the DIV value to be distributed by bitwise XORing it with Y to generate EDIV.

EDIV and Rand are distributed to an initiating device during the transport specific key distribution phase using the Central Identification command.

When the responding device receives a request to encrypt a session it calculates Y using the DIV mask generation function dm with the input parameter k set to DHK and the input parameter r set to Rand. The Y value is bitwise XORed with EDIV from the initiator to recover DIV.

The recovered DIV value can then used to recover LTK which is used to enable encryption on the link.

Diversified keys are generated with function d1. The diversifying function d1 makes use of the security function e.

The following are inputs to diversifying function d1:

d is concatenated with r and padding to generate d’, which is used as the 128-bit input parameter plaintextData to security function e:

The least significant octet of d becomes the least significant octet of d’ and the most significant octet of padding becomes the most significant octet of d’.

For example, if the 16-bit value d is 0x1234 and the 16-bit value r is 0xABCD, then d’ is 0x000000000000000000000000ABCD1234.

The output diversifying function d1 is:

The 128-bit output of the security function e is used as the result of diversifying function d1.

ER is used to generate LTK and CSRK. ER can be assigned, randomly generated by the device during manufacturing or some other method could be used, that results in ER having 128 bits of entropy. If ER is randomly generated then the requirements for random generation defined in [Vol 2] Part H, Section 2 shall be used.

The EDIV and Rand generation method described in Appendix A shall be used. LTK is the result of the diversifying function d1 with the ER as the input parameter k, the DIV as the input parameter d, and the value 0 as the input parameter r; see Section B.2.1.

LTK can be recovered from ER and DIV by repeating the calculation when LTK is required.

CSRK is the result of the diversifying function d1 with the ER as the input parameter k, the DIV as the input parameter d, and the value 1 as the input parameter r; see Section B.2.1.

CSRK can be recovered from ER and DIV by repeating the calculation when CSRK is required.

This method provides an LTK and CSRK with limited amount of entropy because LTK and CSRK are directly related to EDIV and may be less secure than other generation methods.

To reduce the probability of the same LTK or CSRK value being generated, the DIV values must be unique for each CSRK, LTK, EDIV, and Rand set that is distributed.

A method for preventing a malicious device from repeatedly pairing and collecting CSRK, LTK and DIV information, which could be used in a known plain text attack in ER, should be implemented.

IR can be used to generate IRK and other required keys. IR can be assigned, randomly generated by the device during manufacturing or some other method could be used, that results in IR having 128 bits of entropy. If IR is randomly generated then the requirements for random generation defined in Section A.1 shall be used.

IRK is the result of the diversifying function d1 with IR as the input parameter k and the value 1 as the input parameter d and the value 0 as the input parameter r; see Section B.2.1.

If the example EDIV and Rand generation method described in EDIV and Rand Generation, Section A.1 is used then DHK can be the result of diversifying function d1 with IR as the input parameter k and the value 3 as the input parameter d and the value 0 as the input parameter r.EDIV and Rand Generation

Other keys can be generated by using different values for k as the input to the diversifying function d1. If the value of k is reused for a given IR then the resulting key will be the same.

The Peripheral may request the Central initiates security procedures. Figure C.3 shows an example where the Peripheral requests security and the Central initiates pairing in response.

Figure C.3: Peripheral security request, Central initiated pairing

The following subsections include message sequence charts for LE legacy pairing.

C.2.1.1. Legacy Phase 2: Short Term Key generation – Just Works

After Pairing Feature Exchange has completed a pairing method is selected. Figure C.4 shows the Just Works pairing method.

Figure C.4: Legacy Just Works pairing method

C.2.1.2. Legacy Phase 2: Short Term Key generation – Passkey Entry

After Pairing Feature Exchange has completed, a pairing method is selected. Figure C.5 shows the Passkey Entry pairing method.

Figure C.5: Legacy Passkey Entry pairing method

C.2.1.3. Legacy Phase 2: Short Term Key generation – Out of Band

After Pairing Feature Exchange has completed, a pairing method is selected. Figure C.6 shows the Out of Band pairing method.

Figure C.6: Legacy OOB pairing method

The following subsections include message sequence charts for LE Secure Connections.

C.2.2.1. Public key exchange

In Step 1a and 1b, the two devices exchange public keys. The Central sends its public key to the Peripheral followed by Peripheral sending its public key to the Central.

Figure C.7: Pairing Phase 2 – Public Key Exchange

C.2.2.2. Authentication stage 1

The following subsections include message sequence charts for the success and failure cases in each association model.

C.2.2.2.1. Successful Numeric Comparison (or Just Works)

The numeric comparison step will be done when both devices have output capabilities, or if one of the devices has no input or output capabilities. If both devices have output capabilities, this step requires the displaying of a user confirmation value. This value should be displayed until the end of step 2. If one or both devices do not have output capabilities, the same protocol is used but the Hosts will skip the step asking for the user confirmation.

Note

Note: The sequence for Just Works is identical to that of Numeric Comparison with the exception that the Host will not show the numbers to the user.

Figure C.8: Pairing Phase 2, authentication stage 1, successful Numeric Comparison

C.2.2.2.2. Numeric Comparison – Confirm Check failure on the Initiator side

If the Confirm value calculated by the Initiator is not equal to the Commitment value received from the Responder, the Initiator will abort Pairing process by sending Pairing Failed with reason “Confirm Value Failed”.

Figure C.9: Pairing Phase 2, authentication stage 1, Numeric Comparison – Confirm Check failure on Initiator side

C.2.2.2.3. Numeric Comparison failure on the Initiator side

If the numeric comparison fails on the initiating side due to the user indicating that the confirmation values do not match, Pairing is terminated.

Figure C.10: Pairing Phase 2, authentication stage 1, Numeric Comparison failure on Initiator side

C.2.2.2.4. Numeric Comparison failure on the Responding side

If the numeric comparison fails on the responding side due to the user indicating that the confirmation values do not match, Pairing is terminated.

Figure C.11: Pairing Phase 2, authentication stage 1, Numeric Comparison failure on Responding side

C.2.2.2.5. Successful Passkey Entry

The Passkey Entry step is used in two cases: when one device has numeric input only and the other device has either a display or numeric input capability. In this step, one device display a number to be entered by the other device or the user enters a number on both devices. Key press notification messages are shown during the user input phase.

Figure C.12: Pairing Phase 2, authentication stage 1, Successful Passkey Entry

Note

Note: Passkey Entry may prolong pairing experience because of the time required to execute 20 repetitions over SMP.

C.2.2.2.6. Passkey Entry – Confirm Check failure on the Responder side

If during one of the 20 repetitions, the Confirm calculated by the Responder is not equal to the one received from the Initiator, the Responder will abort the Pairing process by sending Pairing Failed with reason “Confirm Value Failed.”

Figure C.13: Pairing Phase 2, authentication stage 1, Passkey Entry – Confirm Check failure on Responder side

C.2.2.2.7. Passkey Entry – Confirm Check failure on the Initiator side

If during one of the 20 repetitions, the Confirm calculated by the Initiator is not equal to the one received from the Responder, the Initiator will abort the Pairing process by sending Pairing Failed with reason “Confirm Value Failed”.

Figure C.14: Pairing Phase 2, authentication stage 1, Passkey Entry – Confirm Check failure on Initiator side

C.2.2.2.8. Passkey Entry failure on the Responding side

If the passkey entry fails on the responding side, Pairing is terminated.

Figure C.15: Pairing Phase 2, authentication stage 1, Passkey Entry failure on Responding side

C.2.2.2.9. Passkey Entry Failure on the Initiator Side

If the passkey entry fails on the initiating side, Pairing is terminated.

Figure C.16: Pairing Phase 2, authentication stage 1, Passkey Entry failure on Initiator side

C.2.2.2.10. Successful Out of Band

The OOB authentication will only be done when at least one device has some OOB information to use. This step requires no user interaction.

Figure C.17: Pairing Phase 2, authentication stage 1, successful Out of Band

C.2.2.2.11. Out of Band – Confirm Check failure on the Responder side

If the Confirm value received from OOB is not equal to the calculated Confirm value, the Responder will abort the Pairing process by sending Pairing Failed with reason “Confirm Value Failed”.

Figure C.18: Pairing Phase 2, authentication stage 1, Out of Band – Confirm Check failure on Responder side

C.2.2.2.12. Out of Band - Confirm Check failure on the Initiating side

If the Confirm value received from OOB is not equal to the calculated Confirm value, the Initiator will abort the Pairing process by sending Pairing Failed with reason "Confirm Value Failed".

Figure C.19: Pairing Phase 2: authentication stage 1, Out of Band – Confirm Check failure on Initiator side

C.2.2.2.13. Out of Band Failure on the Initiator side (OOB information not available)

If the initiating side does not have the responder's OOB information, Pairing is terminated.

Figure C.20: Pairing Phase 2, authentication stage 1, Out of Band failure on Initiator side

C.2.2.2.14. Out of Band Failure on the Responding side (OOB information not available)

If the responding side does not have the initiator's OOB information, Pairing is terminated.

Figure C.21: Pairing Phase 2, authentication stage 1, Out of Band failure on Responding side

C.2.2.3. Long Term Key calculation

Once the DHKey generation is complete, the Long Term Key (LTK) is calculated from the DHKey.

Figure C.22: Long Term Key calculation

C.2.2.4. Authentication stage 2 (DHKey checks)

Once the LTK calculation and authentication stage 1 have completed, the DHKey value generated is checked by exchanging DHKey Check values generated using the DHKey. If this succeeds, then both devices would have finished displaying information to the user about the process, and therefore the Host can stop displaying this information.

Figure C.23: Pairing Phase 2, authentication stage 2, DHKey checks

The Central initiates encryption procedures. There is no SM signaling to enable this; the Central initiates Link Layer encryption only. See [Vol 6] Part D, Section 6.6.

The Peripheral may request the Central initiates security procedures. Figure C.25 shows an example where the Peripheral requests security and the Central initiates Link Layer encryption.

Figure C.25: Peripheral security request, Central initiates Link Layer encryption

If the Peripheral does not support pairing or pairing cannot be performed the Peripheral can reject the request from the Central. Figure C.26 shows the Peripheral rejecting a Pairing Request command from the Central.

Figure C.26: Peripheral rejects pairing attempt

During Pairing Feature Exchange the size of the Encryption Key is negotiated. Figure C.27 shows an example where the Central terminates the pairing procedure because the resulting key size is not acceptable.

Figure C.27: Central rejects pairing because of key size

During Pairing Feature Exchange the size of the Encryption Key is negotiated. Figure C.28 shows an example where the Peripheral terminates the pairing procedure because the resulting key size is not acceptable.

Figure C.28: Peripheral rejects pairing because of key size

During Passkey Entry pairing the user enters a passkey on both devices. Figure C.29 shows an example where the passkey entry fails on the Central.

Figure C.29: Passkey Entry failure on Central

During Passkey Entry pairing the user enters a passkey on both devices. Figure C.30 shows an example where the passkey entry fails on the Peripheral.

Figure C.30: Passkey Entry failure on Peripheral

During Passkey Entry pairing the user enters a passkey on both devices. Figure C.31 shows an example where a different passkey is entered on both devices. This sequence could also occur if any of the inputs to c1 (Passkey, LP_RAND_I, LP_RAND_R, Pairing Request command, Pairing Response command, address types or addresses) are incorrect or altered.

Figure C.31: Different passkeys entered

During all the pairing methods the Central and Peripheral send random numbers and confirm values. Figure C.32 shows an example where the Central rejects pairing because it cannot verify the confirm value from the Peripheral because any of the inputs to c1 (Passkey, LP_RAND_I, LP_RAND_R, Pairing Request command, Pairing Response command, address types or addresses) are incorrect or altered.

Figure C.32: Central rejects LP_CONFIRM_R value from Peripheral