BLE Security

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)

o Determined by the type of pairing used see the table below

Short-Term Key (STK)

o Used to encrypt a connection when 2 devices are pairing for the first time
o STK = AES128 (TK, Srand || Mrand)
o Srand and Mrand are random numbers generated by the Master and the Slave
for every connection

Long-Term Key (LTK)

o Used to create a Session Key for each Link Layer Connection
o 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
o The salve can store it in its security database the LTK or the EDIV from which
it can be calculated

Identity Resolving Key (IRK)

o Used for generating and checking Random Resolvable Private Addresses

hash = AES128(IRK, prand), where random_address = [hash || prand

|| 0b10]

Connection Signature Resolving Key (CSRK)

o Used for sending signed data without encryption
o 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:
1. Exchange of pairing information
2. Authentication of the link
3. 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
Subfiel
d

Code

IO
OOB
Capability Data
Flag

AuthReq
Bondin
g Flags

Maximum
Initiator
Responde
Encryptio
Key
Key
MITM Reserved n Key Size Distribution Distributio

Bits

Bytes

1
1

IO Capability
0x00

DisplayOnly

0x01

DisplayYesNo

0x02

Bonding Flag
0x0
0

No
Bonding

KeyboardOnly

0x0
1

Bonding

0x03

NoInpoutNoOut
put

0x1
0

Reserved

0x04

KeyboardDispla
y

0x1
1

Reserved

0x050xFF

Reserved

Initiator Key Distribution Field

Responder Key Distribution Field
OOB Data Flag
0x00

OOB Authentication data not present

0x01

OOB Authentication data from remote device

present

0x020xFF

Reserved

Subfield

EncKey

IdKey

Sign

Bits

Bytes

The value of the IO Capability field is set up by devices according to the following table from
the BLE4.1 spec:

Rese

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 Temporary Key

Method (TK)

MITM
Protectio
n

Notes

Just
Works

0 (zero)

NO

No authentication

Passkey
Entry

0 ... 999999 (six

decimal digits)

YES

Authenticated

Interface allows
displaying or
entering values

Authenticated

The rest of the key is

padded with zeroes.

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

Generate a 128 bit random number

- Mrand

Generate a 128 bit random number

- Srand

Mconfirm = c1(k, r, pres, preq, iat,

ia, rat, ra) =

Sconfirm = c1(k, r, pres, preq, iat,

ia, rat, ra) =

Notes

The c1 function is detailed in the

BLuetooth 4.1 specification.

= c1 (TK, Mrand, Pairing req

Command, pairing Response
Command, Initiating Device
Address Type, Initiating Device
Address, Responding Device
Address Type, Responding Device
Address)

= c1 (TK, Srand, Pairing req

Command, pairing Response
Command, Initiating Device
Address Type, Initiating Device
Address, Responding Device
Address Type, Responding Device
Address)

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

The s1 function is detailed in the

BLuetooth 4.1 specification.

STK = s1(TK, Srand, Mrand)

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:
1. LTK by the slave
2. EDIV and Rand by the slave
3. IRK by the slave
4. BD ADDR by the slave
5. CSRK by the slave
6. LTK by the master
7. EDIV and Rand by the master
8. IRK by the master
9. BD_ADDR by the master
10. CSRK by the master