Bluetooth Pairing Part 5:
Legacy Pairing – Out of Band

In previous blogs, we touched on topics such as Passkey Entry and Numeric Comparison which are two types of pairing methods. Today, I will introduce another one, out of band.

The out of band (OOB) association model is designed for scenarios where an out of band mechanism is used to both discover the devices as well as to exchange or transfer cryptographic information which would be used in the pairing process. Out of band is a flexible option for developers that allows you to define some of your own pairing mechanisms, so the security level depends on out of band protection capability. Now, let’s have an inside look at it.

1. Phase 1 – Pairing Feature Exchange

In my blog Bluetooth Pairing Part 4, there is a table similar to table 1. This is frame structure for pairing request/response. In this table, there is one field named “OOB Data Flag”, and it’s 1 byte in length.

For the definition of “OOB Data Flag”, please refer to Table 2. 

The OOB data flag defines the values which are used when indicating whether OOB authentication data is available

2. Bluetooth LE Legacy Pairing

When both Bluetooth^® devices use LE legacy pairing, the process is easy to understand. For details about legacy pairing method selection mapping, please refer to Table 3. I’ve already highlighted OOB selection in this table, and you can see that:

• Both devices MUST set their OOB data flag if they want to use OOB for pairing;
• If one of device sets OOB data flag, but the other does not, both devices will check MITM flag which is in“AutheReq” field, Table 1, marked in green. If any device sets its MITM flag, the pairing method will be selected by the mapping of IO Capabilities to pairing method. Please refer to Bluetooth Core Specification v5.0, Vol3, Part H, Table 2.8 for the mapping detail.
• Otherwise, use “Just Works” as pairing method.

• Step 0. Create random value on both sides, Mrand and Srand. After that, the out of band mechanism may be used to exchange information to help with device discovery, such as device address and the 128-bit Temporary Key (TK) value. As I explained before in Part 3, Legacy Pairing – Passkey Entry, TK value is a 128-bit random number which is generated by pseudo-random number engine, and the engine should comply with the requirements of the Bluetooth Core Specification.
• Step 1. Compute Mconfirm and Sconfirm by function c1, please refer Bluetooth Core Specification v5.0, Vol 3, Part H, Section 2.2 for any cryptographic toolbox.
• Step 2. Exchange Mconfirm, Sconfirm and Mrand.
• Step 3. The responding device verifies the Mconfirm value by repeating the calculation the initiating device performed using the Mrand value received.
  • If the responding device’s calculated Mconfirm value does not match the received Mconfirm value from the initiating device then the pairing process will be aborted and the responding device will send the Pairing Failed command with reason code “Confirm Value Failed.”
  • If the responding device’s calculated Mconfirm value matches the received Mconfirm value from the initiating device, the responding device transmits Srand to the initiating device.

  The initiating device verifies the received Sconfirm value by repeating the calculation the responding device performed using the Srand value received.

  • If the initiating devices calculated Sconfirm value does not match the received Sconfirm value from the responding device then the pairing process will be aborted and the initiating device will send the Pairing Failed command with the reason code “Confirm Value Failed.”
  • If the initiating device’s calculated Sconfirm value matches the received Sconfirm value from the responding device the initiating device then calculates Short Term Key (STK) and tells the Controller to enable encryption.

3. Simplicity from OOB

Currently, smartphones and tablets have Bluetooth^® low energy capabilities as a standard, and as we have seen there are many ways to use Bluetooth to connect devices together. Another popular way to pair Bluetooth devices together is to use NFC to ‘tap to pair’ devices. Because of NFC’s super low range, some developers use the close NFC proximity between devices as an assurance that the two devices are indeed meant to be paired together. So, NFC can a good communications interface for OOB pairing. The user’s experience differs a bit when they use OOB for pairing. As an example, the user has one smartphone and one wristband, both devices have Bluetooth low energy and NFC interface. The user will initially touch the two devices together, and is given the option to pair. If “YES” is selected, the pairing is successful. This is a single touch experience where the exchanged information is used in both devices…it’s cool.

Interested in pairing? Read the other posts in our pairing series:

Part 1: Pairing Feature Exchange
Part 2: Key Generation Methods
Part 3: Low Energy Legacy Pairing Passkey Entry
Part 4: LE Secure Connections – Numeric Comparison