The SMP (Security Manager Protocol) offers applications running over a Bluetooth Low Energy stack access to the following types of services:
The SMP works with 5 types of keys:
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.
The pairing procedure in Bluetooth Smart (LE) is performed in three steps:
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.
OOB Data Flag
Maximum Encryption Key Size
Initiator Key Distribution
Responder Key Distribution
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.
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.
Temporary Key (TK)
0 ... 999999 (six decimal digits)
The rest of the key is padded with zeroes.
Out Of Band
Usually a full 128 bit key.
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
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.
STK = s1(TK, Srand, Mrand)
Start Encryption In the Controller using the HCI commands
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:
I face an problem in BLE OOB with NFC
If I use the OOB-NFC to do BLE paring , In the pairing request, I see the "OOB data flag: OOB Authentication data not present". The request is sent by an android phone. What's the meaning of it ? What should I do to make the OOB data is present.
Thanks, and waiting for you response.