SECURITY MANAGER (SM)

KeyWord :
STK , LTK ,IRK and EDIV

function :

• generate and exchange security keys
• to trust the identity of the remote device
• to hide the public Bluetooth Address if required to avoid malicious peers tracking

Security Procedures:

1. Pairing

• which a temporarycommon security encryption key is generated
  to be able to switch to a secure, encrypted link.

     2.Bonding

• A sequence of pairing followed by the generation and exchange of permanent se‐
  curity keys,

    3.Encryption Re-establishment

•   If encryption keys have been stored(bonding), this procedure defines how
  to use those keys in subsequent connections to re-establish a secure, encrypted
  connection without having to go through the pairing (or bonding) procedure again.

phase 1/2 is for Pair procedure and the phase 3 for bonding.

Pairing Algorithms

an exchange of Security Manager Protocol (SMP) packets
to generate a temporary encryption key called Short Term Key (STK) on both sides.
(*the exchange SMP Packet is on L2CAP 0x06)
follow the STK generator method , it can have three type

• Just Works : The STK is generated on both sides, based on the packets exchanged in plain text.

• Passkey Display : One of the peers displays a randomly generated, six-digit passkey and the other side

  is asked to enter it

• Out Of Band (OOB) : When using this method, additional data is transferred by means other than the

  BLE radio(NFC)

security mechanisms that can be used to enforce various levels of security

• Encryption : This mechanism consists of the full encryption of all packets transmitted over an
  established connection.
  
• Privacy :

The privacy feature allows an advertiser to hide its public Bluetooth address by
using temporary, randomly generated addresses that can be recognized by a scanner
that is bonded with the advertising device.

• Signing : With this mechanism, a device can send an unencrypted packet over an established
  connection that is digitally signed

Security Keys :

when bond Procedures , it reference “security mechanisms” to generator keys and identification.

• Encryption, Long Term Key(LTK) and Master Identification(EDIV, Rand)

This is a 128-bit encryption key shared by both sides (LTK) along with two values
(EDIV, Rand) acting as its identifier, since a device may be bonded with multiple
other peers.

• Privacy,Identity Information (Identity Resolving Key or IRK) and Identity Address Information
  (Address Type and Bluetooth Device Address)

it can generate and resolve resolvable addresses . The actual public or static random address of the
device distributing it is included along with the IRK.

• Signing, Signing Information (Connection Signature Resolving Key or CSRK)

A key used to digitally sign unencrypted data

Since each key is asymmetrical (and therefore the process of key distribution is sym‐
metrical) and thus each bond information stored between two devices can contain up
to two instances of each key (each peer having distributed its own), it’s important to
note how keys distributed by each device are used in subsequent connections.

 Implementation:follow data is come from nordic nRF51 document. we see how to implementation the that.
we can see the security key and the Message Sequence Charts(MSC) above information.

Security Procedures , Security Keys and Random Address .
Message Sequence Charts(MSC) above information.

A. Just Work (pair and bonding)

B. GAP Bonding: Passkey Entry, Peripheral displays

 

C. Encryption Re-establishment

if Connected to a previously bonded master ,we need GAP Peripheral Initiated Security Establishment first.

D. GAP Security Establishment using stored keys

A/B  section is for the bonding , the last statement we can get the KEY(m_auth_status)

/** @brief Security levels supported.

 *  @note See Bluetooth Specification Version 4.0 Volume 3, Chapter 10.

*/

typedef struct

{

  uint8_t lv1 : 1;                              /**< If 1: Level 1 is supported. */

  uint8_t lv2 : 1;                              /**< If 1: Level 2 is supported. */

  uint8_t lv3 : 1;                              /**< If 1: Level 3 is supported. */

} ble_gap_sec_levels_t;

/** @brief Keys that have been exchanged. */

typedef struct

{

  uint8_t ltk       : 1;                        /**< Long Term Key. */

  uint8_t ediv_rand : 1;                        /**< Encrypted Diversifier and Random value. */

  uint8_t irk       : 1;                        /**< Identity Resolving Key. */

  uint8_t address   : 1;                        /**< Public or static random address. */

  uint8_t csrk      : 1;                        /**< Connection Signature Resolving Key. */

} ble_gap_sec_keys_t;

/** @brief Event data for authentication status event. */

typedef struct

{

  uint8_t               auth_status;            /**< Authentication status, see @ref BLE_GAP_SEC_STATUS. */

  uint8_t               error_src;              /**< On error, source that caused the failure, see @ref BLE_GAP_SEC_STATUS_SOURCES. */

  ble_gap_sec_levels_t  sm1_levels;             /**< Levels supported in Security Mode 1. */

  ble_gap_sec_levels_t  sm2_levels;             /**< Levels supported in Security Mode 2. */

  ble_gap_sec_keys_t    periph_kex;             /**< Bitmap stating which keys were exchanged (distributed) by the peripheral. */

  ble_gap_sec_keys_t    central_kex;            /**< Bitmap stating which keys were exchanged (distributed) by the central. */

  struct periph_keys_t

  {

    ble_gap_enc_info_t    enc_info;             /**< Peripheral's Encryption information. */

  } periph_keys;                                /**< Actual keys distributed from the Peripheral to the Central. */ 

  struct central_keys_t

  {

    ble_gap_irk_t         irk;                  /**< Central's IRK. */

    ble_gap_addr_t        id_info;              /**< Central's Identity Info. */

  } central_keys;                               /**< Actual keys distributed from the Central to the Peripheral. */

} ble_gap_evt_auth_status_t;

and other data structure about he auth information

/**@brief GAP Encryption Information. */

typedef struct

{

  uint16_t  div;                        /**< Encryption Diversifier. */

  uint8_t   ltk[BLE_GAP_SEC_KEY_LEN];   /**< Long Term Key. */

  uint8_t   auth : 1;                   /**< Authenticated Key. */

  uint8_t   ltk_len : 7;                /**< LTK length in octets. */

} ble_gap_enc_info_t;

/**@brief GAP Master Identification. */

typedef struct

{

  uint16_t  ediv;                       /**< Encrypted Diversifier. */

  uint8_t   rand[8];                    /**< Random Number. */

} ble_gap_master_id_t;

/**@brief GAP Identity Information. */

typedef struct

{

  ble_gap_addr_t  addr;                       /**< Bluetooth address to which this key applies. */

  uint8_t         irk[BLE_GAP_SEC_KEY_LEN];   /**< Identity Resolution Key. */

} ble_gap_id_info_t;

/**@brief GAP Signing Information. */

typedef struct

{

  uint8_t   csrk[BLE_GAP_SEC_KEY_LEN]; /* Connection Signature Resolving Key. */

} ble_gap_sign_info_t;

You should care the Peripheral to Central key(ltk) and Central to Peripheral key(irk and irk and identifty infor),espeical the Central to Peripheral is for the Address Type.

Connected to a previously bonded master the follow is :

1.C. Encryption Re-establishment to send the “call sd_ble_gap_authenticate function”send the MIMT IO Capation

2.A. Just Work (pair and bonding) , you should be no bonding state and get the “m_auth_status”

3.D. GAP Security Establishment using stored keys , use the auth_state(LTK) to reply

 

reference :
Getting Started with Bluetooth Low Energy
by Kevin Townsend, Carles Cufí, Akiba, and Robert Davidson
BLUETOOTHLOW ENERGY
TECHNOLOGY TRAINING
by
All Hands Meeting 19-22 April 2010
Bluetooth SIG Proprietary and Confidentia