Part E. Low Energy Link Layer Security
vAtlanta r00
This Part describes the Link Layer security for Bluetooth Low Energy.
1. Encryption and authentication overview
The Link Layer provides encryption and authentication using Counter with Cipher Block Chaining-Message Authentication Code (CCM) Mode, which shall be implemented consistent with the algorithm as defined in IETF RFC 3610 (http://www.ietf.org/rfc/rfc3610.txt) in conjunction with the AES-128 block cipher as defined in NIST Publication FIPS-197 (http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf). A description of the CCM algorithm can also be found in the NIST Special Publication 800-38C (http://csrc.nist.gov/publications/PubsSPs.html).
This specification uses the same notation and terminology as the IETF RFC except for the block cipher key K that in this specification is called the session key (see Section 2.4) and for the Message Authentication Code (MAC) that in this specification is called the Message Integrity Check (MIC) to avoid confusion with the term Media Access Controller.
CCM has two size parameters, M and L. The Link Layer defines these to be:
M = 4; indicating that the MIC (authentication field) is 4 octets
L = 2; indicating that the Length field is 2 octets
CCM requires a new session key whenever encryption is started. CCM also requires a unique nonce value for each PDU that is protected by a given session key. The CCM nonce shall be 13 octets.
An ACL connection or a BIS (if present), may be either encrypted and authenticated or unencrypted and unauthenticated. A CIS shall be encrypted and authenticated if, and only if, the associated ACL connection is.
When encryption is enabled, all Data Physical Channel and Isochronous Physical Channel PDUs with a non-zero length Payload shall be encrypted and authenticated. Authentication is performed by appending a MIC field to the Payload. The MIC shall be calculated over the PDU’s Payload and the first octet of the header with certain bits (specified in Table 2.3) masked to zero. Encryption shall be applied to the PDU’s Payload and MIC.
Each new encrypted PDU with a non-zero length Payload shall be decrypted and authenticated before being sent to the Host or processed by the Link Layer. Authentication is unrelated to the Link Layer acknowledgment scheme; authentication does not have to be performed before the packet is acknowledged by the Link Layer.
In the event of an authentication failure being detected in a Data Physical Channel PDU or CIS Data PDU, the corresponding connection shall be considered lost (see [Vol 6] Part B, Section 4.5.12). The notification to the Host shall specify the error code Connection Terminated due to MIC Failure (0x3D). The peer Link Layer will detect this loss of connection through the supervision timeout procedure.
In the event of a MIC failure being detected in a Broadcast Isochronous PDU, synchronization shall be considered lost. The Link Layer shall not receive any further packets on the BIS and the Host shall be notified of the loss of synchronization with the error code Connection Terminated due to MIC Failure (0x3D).
1.1. Cryptographic Toolbox
The following cryptographic functions are defined:
h8 is used to generate group session keys for BIGs.
The building block for the cryptographic functions h8 is the security function AES‑CMAC.
When a multi-octet integer parameter is used as input to AES-CMAC inside the h8 function, the most significant octet of the integer shall be the first octet of the stream and the least significant octet of the integer shall be the last octet of the stream.
The functions h6 and h7 used in this Part are defined in [Vol 3] Part H, Section 2.2.
1.1.1. Group Session Key Derivation Function h8
The function h8 is used to generate the Group Session Key (GSK) for encrypting or decrypting payloads of an encrypted BIS. The definition of the h8 function makes use of the AES-CMAC function. The inputs to the function h8 are:
K is 128 bits S is 128 bits keyID is 32 bits
For the first AES-CMAC function, K is used as the data m and S is used as the key. The output of the first AES-CMAC function IK (intermediate key which is 128 bits) is used as the key for the second AES-CMAC function and keyID is used as the data m:
IK = AES-CMACS(K) h8(K, S, keyID) = AES-CMACIK(keyID)
1.1.2. Derivation of Group Session Key
The Link Layer shall derive the Group Long Term Key (GLTK) and Group Session Key (GSK) as follows:
IGLTK = h7(“BIG1”, Broadcast_Code) GLTK = h6(IGLTK, “BIG2”) GSK = h8 (GLTK, GSKD, “BIG3”)
The string "BIG1" is mapped into a SALT using ASCII as 0x00000000_00000000_00000000_42494731.
The string "BIG2" is mapped into a keyID using ASCII as 0x42494732.
The string "BIG3" is mapped into a keyID using ASCII as 0x42494733.
2. CCM
This section provides the details for using the CCM algorithm. As specified, the CCM algorithm requires the payload and some additional parameters to be formatted into the CCM nonce, counter-mode blocks and encryption blocks. The CCM nonce provides uniqueness to each packet. The counter-mode blocks are used to calculate the MIC. The encryption blocks provide the keystream that is used to encrypt the payload and the MIC of the Data Physical Channel PDU, CIS Data PDU, BIS Data PDU, and BIG Control PDU.
Sample data of the blocks (see Section 2.2 and Section 2.3) can be found in [Vol 6] Part C, Section 1 and Section 1.2.
2.1. CCM nonce
The CCM nonce is constructed from a 39-bit packetCounter, 1-bit directionBit and an 8-octet IV (initialization vector). The format of the 13-octet nonce shall be as shown in Table 2.1.
Octet | Field | Size (octets) | Value | Description |
|---|---|---|---|---|
0 | Nonce0 | 1 | variable | packetCounter[7:0] |
1 | Nonce1 | 1 | variable | packetCounter[15:8] |
2 | Nonce2 | 1 | variable | packetCounter[23:16] |
3 | Nonce3 | 1 | variable | packetCounter[31:24] |
4 | Nonce4 | 1 | variable | Bit 6 – Bit 0: packetCounter[38:32] Bit 7: directionBit |
5 | Nonce5 | 1 | variable | IV[7:0] |
6 | Nonce6 | 1 | variable | IV[15:8] |
7 | Nonce7 | 1 | variable | IV[23:16] |
8 | Nonce8 | 1 | variable | IV[31:24] |
9 | Nonce9 | 1 | variable | IV[39:32] |
10 | Nonce10 | 1 | variable | IV[47:40] |
11 | Nonce11 | 1 | variable | IV[55:48] |
12 | Nonce12 | 1 | variable | IV[63:56] |
The Link Layer shall maintain one packetCounter per Role for each ACL and CIS connection and one for each BIS that the Link Layer is transmitting or is synchronized to.
For each ACL connection, the packetCounter shall be set to zero for the first encrypted Data Physical Channel PDU sent during the encryption start procedure. The packetCounter shall then be incremented by one for each new Data Physical Channel PDU that is encrypted. The packetCounter shall not be incremented for retransmissions.
For each CIS, packetCounter shall equal cisPayloadCounter defined in [Vol 6] Part B, Section 4.5.13.1.
For each BIS, packetCounter shall equal bisPayloadCounter defined in [Vol 6] Part B, Section 4.4.6.3
The value of packetCounter used for a BIG Control PDU shall be equal to the value of packetCounter used in the first subevent of the BIG event that the BIG Control PDU is part of.
The directionBit shall be set to 1 for Data Physical Channel PDUs and CIS Data PDUs sent by the Central and set to 0 for Data Physical Channel PDUs and CIS Data PDUs sent by the Peripheral. The directionBit shall be set to 1 for Broadcast Isochronous PDUs sent by the Isochronous Broadcaster.
The IV is common for both Roles of an ACL and CIS. Whenever encryption is started or restarted, a new 8-octet IV shall be used for each pair of communicating devices. The IV for an ACL is determined as specified in [Vol 6] Part B, Section 5.1.3.1. The IV for a CIS or BIS is calculated from an IVbase and the Access Address of the CIS or BIS respectively. For a CIS, the IVbase shall be set to the value of IV of the associated ACL. For a BIS, the IVbase shall be set to the value of GIV contained in the BIGInfo. IV[31:0] shall equal IVbase[31:0] XORed with the Access Address of the CIS or BIS while IV [63:32] shall equal IVbase[63:32], as shown in Figure 2.1. The IV for a BIG control logical link shall be determined in the same way as for a BIS.
Note
Note: If a CIS is terminated or considered lost and then a new CIS with the same CIS_ID is created in the same CIG, the new CIS must still have a new access address (see [Vol 6] Part B, Section 2.1.2).
2.2. Counter mode blocks
For calculating the MIC, the multiple counter mode blocks are generated according to the CCM specification. These are referred to as blocks B0 – Bn. Table 2.2 defines the format of block B0. Table 2.3 defines the format of block B1 that is devoted to the authentication of the additional authenticated data. Additional B blocks are generated as needed for authentication of the payload.
Offset (octets) | Field | Size (octets) | Value | Description |
|---|---|---|---|---|
0 | Flags | 1 | 0x49 | As per the CCM specification |
1 | Nonce | 13 | variable | The nonce as described in Table 2.1. Nonce0 shall have offset 1. Nonce12 shall have offset 13. |
14 | Length[MSO] | 1 | 0x00 | The most significant octet of the length of the payload |
15 | Length[LSO] | 1 | variable | The least significant octet of the length of the payload |
Offset | Field | Size (octets) | Value | Description |
|---|---|---|---|---|
0 | AAD_Length[MSO] | 1 | 0x00 | The most significant octet of the length of the additional authenticated data |
1 | AAD_Length[LSO] | 1 | 0x01 | The least significant octet of the length of the additional authenticated data |
2 | AAD | 1 | variable | The PDU header’s first octet with the following bits masked to 0. Data Physical channel PDU: NESN, SN, MD. Connected Isochronous PDU: NESN, SN, NPI, CIE. Broadcast Isochronous PDU: CSSN, CSTF. |
3 | Padding | 13 | 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 | These octets are only used to pad the block. They are not part of the packet and never transmitted. |
2.3. Encryption blocks
The CCM algorithm uses the Ai blocks to generate keystream that is used to encrypt the MIC and the PDU payload. Block A0 is always used to encrypt and decrypt the MIC. Block A1 is always used to encrypt and decrypt the first 16 octets of the Payload. Subsequent blocks are always used to encrypt and decrypt the rest of the Payload as needed.
Offset (octets) | Field | Size (octets) | Value | Description |
|---|---|---|---|---|
0 | Flags | 1 | 0x01 | As per the CCM specification |
1 | Nonce | 13 | variable | The nonce as described above Nonce0 shall have offset 1. Nonce12 shall have offset 13. |
14 | i[MSO] | 1 | variable | The most significant octet of the counter i |
15 | i[LSO] | 1 | variable | The least significant octet of the counter i |
2.4. Session Keys
The session key for an ACL connection shall be generated as specified in [Vol 6] Part B, Section 5.1.3.1.
The session key for a CIS shall be the same as that for the associated ACL.
The session key for a BIS shall be the Group Session Key derived in Section 1.1.2.