Pairing processes

 

Silicon Labs Bluetooth stack implements Bluetooth Smart 4.2 security features as described in http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/Bluetooth-Smart-Security-4-2-features-in-BLE-SDK-V2-0-0/ta-p/179883. This involves pairing processes to set up a secure connection between two devices. There are 5 different pairing processes depending on the IO capabilities of each devices:

  • Just work [this results in an unauthenticated but encrypted connection!]
  • Numeric Comparision [authenticated]
  • Passkey Entry (Initiator displays, Responder inputs) [authenticated]
  • Passkey Entry (Responder displays, Initiator inputs) [authenticated]
  • Passkey Entry (Responder and Initiator inputs) [authenticated]

 

The process is selected based on the IO capabilities as summarized in the following table:

 

Initiator

DisplayOnly

DisplayYesNo

KeyboardOnly

NoInputNoOutput

KeyboardDisplay

Responder

DisplayOnly

Just Works

Just Works

Passkey Entry
(R displays,
 I inputs)

Just Works

Passkey Entry
(R displays,
 I inputs)

DisplayYesNo

Just Works

Numeric
Comparision

Passkey Entry
(R displays,
 I inputs)

Just Works

Numeric
Comparision

KeyboardOnly

Passkey Entry
(I displays,
 R inputs)

Passkey Entry
(I displays,
 R inputs)

Passkey Entry
(R and I inputs)

Just Works

Passkey Entry
(I displays,
 R inputs)

NoInputNoOutput

Just Works

Just Works

Just Works

Just Works

Just Works

KeyboardDisplay

Passkey Entry
(I displays,
 R inputs)

 Numeric
Comparision
 Passkey Entry
(R displays,
 I inputs)
 Just Works Numeric
Comparision 

 

In each case there is a different sequence of events and commands which has to be followed. When implementing an application, the developer has to consider all scenarios that may happen with the IO capabilities of the device. E.g. if you have a device with DisplayOnly capability (you can display the 6 digit passkey but you have not inputs such as keys or buttons) and you are supposed to be a Responder (e.g. you use a mobile application that will always initiate the bonding), then you have to implement the Just Works and the Passkey Entry (R displays, I inputs) processes in your application, as these are the possible scenarios according to the table.

The pairing process is an interactive process, since the user has to confirm the identity of the connecting devices (e.g. by typing in the passkey). This interaction is realized with events raised by the stack and with commands sent to the stack.

 

Note: You can enable automatic bonding confirmation by setting bit 3 in sm configuration flags to 0 (see gecko_cmd_sm_configure(flags,io_capabilities) ). In this case “event sm_confirm_bonding” and “call sm_bonding_confirm” steps are skipped in each processes! Do not confuse this with gecko_cmd_sm_set_bondable_mode(1) which always has to be set to 1 to enable bonding processes. To learn more about sm configuration see http://community.silabs.com/t5/Bluetooth-Wi-Fi-Knowledge-Base/Bluetooth-Smart-Security-4-2-features-in-BLE-SDK-V2-0-0/ta-p/179883

 

Just works

 

In this case there is no possibility to confirm the identity of the connecting devices, so no interaction is needed. Devices will pair with encryption but without authentication.

2017-08-25_15h05_29.png

 

Numeric Comparision

 

Both devices will display a 6-digit passkey. The user has to confirm, that the two devices display the same passkey by pressing a button. If the passkeys match, it means that there were no Man-In-The-Middle, and the devices could exchange keys securely. Note: to get the two passkeys on the two devices at the same time, disable automatic bonding confirmation (bit 3 in sm configuration flags).

2017-08-25_15h06_53.png

 

Passkey entry: responder displays, initiator inputs

 

A passkey is displayed on the responder device, which has to be typed in with the use of the numeric keyboard on the initiator device.

2017-08-25_15h08_50.png

 

Passkey entry: initiator displays, responder inputs

 

A passkey is displayed on the initiator, which has to be input on the responder device to confirm authentication.

2017-08-25_15h09_20.png

 

Passkey entry: initiator and responder inputs

 

In this scenario, both devices have to input a passkey. In contrast to other scenarios where the passkey was generated with either one of the devices, in this case the user has to find out a key, and enter the same key in both devices.

2017-08-25_15h09_52.png

 

  • Knowledge Base Articles
  • Bluetooth Low Energy
  • Bluetooth Classic