Pairing Processes#

Introduction#

Silicon Labs Bluetooth stack implements Bluetooth security features as described in Using Bluetooth Security features in Silicon Labs Bluetooth SDK

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 works [this results in an unauthenticated but encrypted connection!]

• Numeric Comparison [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:

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 has to always be set to 1 to enable bonding processes. To learn more about sm configuration see Using Bluetooth Security features in Silicon Labs Bluetooth SDK

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.

Numeric Comparison#

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).

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.

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.

Passkey entry: initiator and responder input#

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.

Example#

This guide has a related code example, Find it here: Pairing Processes Example