Alexandru Balmus

Bluetooth Low Energy SMP Pairing

Discussion created by Alexandru Balmus Employee on Oct 8, 2014
Latest reply on Aug 27, 2018 by Yanling Zhang

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]
  • 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:

  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

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

 

IO Capability

0x00

DisplayOnly

0x01

DisplayYesNo

0x02

KeyboardOnly

0x03

NoInpoutNoOutput

0x04

KeyboardDisplay

0x05-0xFF

Reserved

Bonding Flag

0x00

No Bonding

0x01

Bonding

0x10

Reserved

0x11

Reserved

 

OOB Data Flag

0x00

OOB Authentication data not present

0x01

OOB Authentication data from remote device present

0x02-0xFF

Reserved

Initiator Key Distribution Field

Responder Key Distribution Field

Subfield

EncKey

IdKey

Sign

Reserved

Bits

1

1

1

5

Bytes

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

  • No authentication

Passkey Entry

0 ... 999999 (six decimal digits)

The rest of the key is padded with zeroes.

YES

  • Authenticated
  • Interface allows displaying or entering values

Out Of Band

Usually a full 128 bit key.

YES

  • Authenticated

 

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:

  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

Outcomes