Introduction
The SMP (Security Manager Protocol) offers applications running over a Bluetooth Low Energy stack access to the following types of services:
- Device Authentication
- Device Authorization
- Data Integrity
- Data Confidentiality
- Data privacy
The SMP works with 5 types of keys:
- Temporary Key (TK)
- Determined by the type of pairing used – see the table below
- Short-Term Key (STK)
- Used to encrypt a connection when 2 devices are pairing for the first time
- STK = AES128 (TK, Srand || Mrand)
- Srand and Mrand are random numbers generated by the Master and the Slave for every connection
- Long-Term Key (LTK)
- Used to create a Session Key for each Link Layer Connection
- Can be deduced by the Slave using and EDIV (unique to each master) and a Rand value sent from the Slave to the Master when the devices are bonding
- The salve can store it in its security database the LTK or the EDIV from which it can be calculated
- Identity Resolving Key (IRK)
- Used for generating and checking Random Resolvable Private Addresses
- hash = AES128(IRK, prand), where random_address = [hash || prand || 0b10]
- Used for generating and checking Random Resolvable Private Addresses
- Connection Signature Resolving Key (CSRK)
- Used for sending signed data without encryption
- Authenticates a message
What services and keys are used for the communication between two devices are established during the SMP Pairing procedure which is performed by the SMP and set up by the Application according to its needs.
Pairing Procedure in BLE
The pairing procedure in Bluetooth Smart (LE) is performed in three steps:
- Exchange of pairing information
- Authentication of the link
- Distribution of the keys
Exchange of pairing information
The exchange of pairing information between two devices is done through the Pairing Request and Pairing Response SMP messages. The contents of these two messages is shown below and is set up by the application according to device capabilities and/or its needs.
0x01 | Pairing Request | ||||||||
0x02 | Pairing Response | ||||||||
Field | Code | IO Capability | OOB Data Flag | AuthReq | Maximum Encryption Key Size | Initiator Key Distribution | Responder Key Distribution | ||
Subfield | Bonding Flags | MITM | Reserved | ||||||
Bits | 8 | 8 | 8 | 2 | 1 | 5 | 8 | 8 | 8 |
Bytes | 1 | 1 | 1 | 1 | 1 | 1 | 1 | ||
|
| |||||||||||||||||||||||||||||||||
|
| |||||||||||||||||||||||||||||||||
The value of the IO Capability field is set up by devices according to the following table from the BLE4.1 spec:
The OOB Data Flag is set to 1 if the application/device requires and supports exchanging data through an Out-of-band method.
The MITM flag is set in the AuthReq field if the Application requires Man-in-the-middle protection.
The Bonding Flags in the AuthReq field are set if the application requires bonding.
The minimum Encryption Key Size is set up by the application with a value between 7 Bytes (56 bits) and 16 Bytes (128 bits) in steps of 1 byte. Keys which are less than 128 bits are padded with zeroes starting with the lowest address: 128 bit key - 0x123456789ABCDEF0123456789ABCDEF0, 56 bit key - 0x0000000000000000003456789ABCDEF0.
The Initiator and Responder key distribution fields are set depending on what keys must be exchanged between two devices in phase 3 of the pairing process.
The Initiator is always the Link Layer Master (GAP Central) and the Responder is always the Link Layer Slave (GAP Peripheral) in a connection.
Authentication
The second step of the pairing procedure is the Authentication step which is performed based on the information exchanged in the previous step in the Pairing Request and Pairing Response messages.
In this step the Temporary Key is generated. There are 3 ways of generating the TK in BLE (described below): Just Works, OOB, and Passkey Entry. The priority of these methods is the following: if both devices have set the OOB flag than the OOB method is used regardless of the other flags in the Pairing Request and Response. If the OOB flag is not set on at least one of the devices then the MITM flag is checked. If both devices have not set the MITM flag then the just works method is chosen (IO capabilities are ignored), else the pairing algorithm is chosen based on the IO Capabilities.
The following table describes the relation between the TK and the pairing methods.
Pairing Method | Temporary Key (TK) | MITM Protection | Notes |
Just Works | 0 (zero) | NO |
|
Passkey Entry | 0 ... 999999 (six decimal digits) The rest of the key is padded with zeroes. | YES |
|
Out Of Band | Usually a full 128 bit key. | YES |
|
The enabling of MITM protection during pairing is considered as “Authenticated Pairing”
Based on the contents of the Pairing Request and Pairing Response SMP messages the pairing method is chosen as described in the following tables from the BLE 4.1 specification.
After the TK is obtained the devices generate the STK. The STK generation procedure is detailed in the following table for the Initiator and the Responder
Intiator | Responder | Notes |
Generate a 128 bit random number - Mrand | Generate a 128 bit random number - Srand | |
Mconfirm = c1(k, r, pres, preq, iat, ia, rat, ra) = = c1 (TK, Mrand, Pairing req Command, pairing Response Command, Initiating Device Address Type, Initiating Device Address, Responding Device Address Type, Responding Device Address) | Sconfirm = c1(k, r, pres, preq, iat, ia, rat, ra) = = c1 (TK, Srand, Pairing req Command, pairing Response Command, Initiating Device Address Type, Initiating Device Address, Responding Device Address Type, Responding Device Address) | The c1 function is detailed in the BLuetooth 4.1 specification. |
Transmit Mconfirm to the responding device. | ||
Transmit Sconfirm to the intiating device. | ||
Transmit Mrand to the responding device | ||
Verify Mconfirm using the c1 function | ||
If Mconfirm verifies transmit Srand to the initiating device | ||
Verify Sconfirm using the c1 function | ||
If Sconfirm verifies generate STK STK = s1(TK, Srand, Mrand) | The s1 function is detailed in the BLuetooth 4.1 specification. | |
Generate STK STK = s1(TK, Srand, Mrand) | ||
Start Encryption In the Controller using the HCI commands |
Distribution of keys
The third phase of the pairing procedure is the distribution of the keys. The keys are distributed using specific SMP packets. The keys are encrypted with the STK and once stored in a security database must have the same properties (authentication, MITM protection) as the STK. The keys which can be distributed are: (LTK, EDIV and Rand), IRK, CSRK.
The distributed EDIV and Rand values are transmitted in clear text by the master device to the slave device during encrypted session setup.
The BD_ADDR of devices is also distributed in this phase.
Only the security information specified in the Pairing Request and response is distributed. The distribution is done in the following order specified by the standard:
- LTK by the slave
- EDIV and Rand by the slave
- IRK by the slave
- BD ADDR by the slave
- CSRK by the slave
- LTK by the master
- EDIV and Rand by the master
- IRK by the master
- BD_ADDR by the master
- CSRK by the master
