Starting Encryption

To start encryption, the link must be unencrypted. To encrypt the link, both the nonce and a session key (SK) need to be created. The nonce requires 4 octets of information to be

contributed by each device, and the session key requires 8 octets of information to be

contributed by each device. An additional key is also required, called the long-term key (LTK). This is the shared secret that is established during pairing (for more information, go to Chapter 11, Security, Section 11.2).

To start encryption, as illustrated in Figure 7–26, the master first transmits an encryption request message (LL_ENC_REQ) to the slave. The slave then responds with an encryption response message (LL_ENC_RSP). The encryption request packet from the master includes its 4-byte contribution to the initialization vector, 8 bytes of session key diversifier, and some additional information that the slave transmitted to it when they initially paired. This

additional information is static for a given master, and the slave can use this information to determine with which master it is communicating and possibly derive the LTK for the master from this information. By doing this, the slave might not need to store any information about bonded devices. The encryption response packet from the slave includes its 4-byte

contribution to the initialization vector and its contribution to the session key diversifier.

Figure 7–26. Starting the encryption procedure

If the LTK is not available on the slave side, the slave will then immediately send a reject indication to the master along with the reason it rejected the encryption. If the LTK is

available, the slave will start a three-way handshake to begin encryption. The three-way handshake is required because the slave, for example, must be able to transmit an

unencrypted packet to the master, but it must be able to receive an encrypted packet back.

Thus, this handshake procedure moves the two devices in lockstep into a fully encrypted link.

When encryption is started, a session key is used to encrypt the link. The session key is calculated from the LTK and the session key diversifier contributed to by both devices.

The session key diversifier enables an LTK to be used multiple times. This is done by ensuring that each time a connection is encrypted a different encryption key is derived from the session key. The master and slave contribute half of this diversifier to ensure that even if one device is an attacker, the other device can force a different diversifier and therefore a different encryption key. The primary reason all this is done is to protect against the single weakness in AES: A key cannot be used more than once, ever. Therefore, even though we have a shared secret, LTK, we cannot use this to encrypt the application data. Instead, we must diversify this LTK into a session key, SK.

The two session key diversifiers (SKD), SKD_master contributed by the master, and

SKD_slave contributed by the slave, are concatenated together and used as the plaintext input into the AES encryption engine (refer to Equation 7-4). The LT K is used as the key input into the AES encryption engine. The output of the AES encryption engine is the session key that is used as the key to encrypt the link.

SK = E_LTK (SKD_master || SKD_slave)

The initialization vector (IV) is also calculated from the two values contributed by both devices IV_master contributed by the master and IV_slave contributed by the slave by

concatenating them together.

IV = IV_master || IV_slave

All data transfers are paused while encryption is starting. This is done on the master before it sends its encryption request packet; on the slave, it’s done before it sends its encryption response packet. This ensures that no data can be sent unencrypted while the encryption is starting up; it also helps the three-way handshake to perform correctly.

Once the SK and IV have been calculated by the slave, the slave sends the start encryption request packet (LL_START_ENC_REQ) unencrypted, but the slave sets to receive an encrypted packet by using the SK and IV values just calculated. If the master doesn’t receive the slave’s packet, the master will respond by requesting the same packet again, using an empty packet because all other data packets have been paused. Because empty packets can never be encrypted (there is no payload to encrypt), the slave can receive either this packet or the master’s next encrypted packet.

The master responds to the slave’s packet by sending an encrypted packet

(LL_START_RSP) that uses the same SK and IV values it has just calculated and setting up to receive an encrypted packet in response. The slave can receive this encrypted packet

because it was configured to receive encrypted packets. The slave will now turn on encrypted packet transmission.

Upon receipt of this master’s encrypted packet, the slave will respond with an encrypted

packet (LL_START_RSP). The master can receive this encrypted packet because it has already turned on the reception of encrypted packets.

Once the master has received this final packet, it can turn on the flow of application data, all of which will be encrypted. Once the slave has received the Link Layer

acknowledgement of this final packet, it can turn on the flow of application data, all of which will be encrypted.

On Bluetooth classic, authentication must be performed before encryption can be started.

This costs both in terms of time and additional messages that need to be transmitted. In Bluetooth low energy, this process is not necessary because each packet that is transmitted includes authentication. Therefore, the authentication of the link is done on each and every packet, not just once at the start of the encryption process.