In previous articles, 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 OOB 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. OOB is a flexible option for developers that allows you to define some of your own pairing mechanisms, so the security level depends on OOB protection capability. Now, let us have an inside look at it.
Phase 1 – pairing feature exchange
In Bluetooth® LE secure connections – numeric comparison, there is a table similar to table 1. This is a frame structure for pairing request/response. In this table, there is one field named OOB data flag, and it is one 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
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 have 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 the 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 5.0, vol3, part H, table 2.8 for the mapping detail.
- Otherwise, use just works as a pairing method.
In picture 1, the shaded parts are common with Bluetooth LE legacy pairing passkey entry, passkey entry. After this, security managers of both devices will:
- Step 0: Create random value on both sides, Mrand and Srand. After that, the OOB 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 Bluetooth LE legacy pairing passkey entry, the TK value is a 128-bit random number which is generated by a 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 to Bluetooth Core 5.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, 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.
- If the initiating device’s 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.
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 technology 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 be 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.
Interested in pairing? Read the other posts in our pairing series:
Part 1: Bluetooth® pairing feature exchange
Part 2: Bluetooth® pairing key generation methods
Part 3: Bluetooth® LE legacy pairing passkey entry
Part 4: Bluetooth® LE secure connections – numeric comparison
