In the Bluetooth® Core Specification, there are three major architectural layers: controller, host, and application. In the host layer, there is a module called security manager (SM) which defines the methods and protocols for pairing and key distribution, the corresponding security toolbox, and the security manager protocol (SMP) which defines the pairing command frame format, frame structure, and timeout restriction. The security manager (SM) uses a key distribution approach to perform identity and encryption functionalities in radio communication.
Pairing is performed to establish keys which can then be used to encrypt a link. A transport specific key distribution is then performed to share the keys. The keys can be used to encrypt a link in future reconnections, verify signed data, or perform random address resolution. In general, there are three phases for paring.
- Phase 1: pairing feature exchange
- Phase 2 (Bluetooth LE legacy pairing): short-term key (STK) generation
- Phase 2 (Bluetooth LE secure connections): long-term key (LTK) generation
- Phase 3: transport-specific key distribution
Bluetooth LE legacy pairing and Bluetooth LE secure connections may be new terms to most. Bluetooth LE is in the Bluetooth® Core Specification as a main feature of Bluetooth® Core 4.0 and above. In Bluetooth® Core 4.2, the secure connections feature to the LE physical transport was added, which upgraded pairing to utilize FIPS-approved algorithms (AES-CMAC and P-256 elliptic curve) on the Bluetooth LE physical transport. In order to distinguish secure connections from LE pairing as defined in Bluetooth® Core 4.0 and Bluetooth® Core 4.1, it is referred to as LE legacy pairing. Figure 1 is a pairing flowchart which applies to both legacy pairing and secure connections.
Today, we will look at phase 1: pairing feature exchange. Pairing is the exchange of security features that include things like input/output (IO) capabilities, requirements for man-in-the-middle protection, etc. The exchange of pairing information between two devices is done through the pairing request and pairing response packet. The contents of these two messages are shown below in the table below: Table 1 Pairing Request/Response.
Code IO cap, IO capabilities
Since IO refers to input/output, the IO capabilities are combined to generate the value for this field. For input capabilities, it could be no input, yes/no, or keyboard, as detailed below.
For output capabilities, it could be no output or numeric output, as detailed below.
After combining those capabilities of input and output, here is a matrix defining what IO capabilities the Bluetooth device should have.
None of the pairing algorithms can use yes/no input and no output, therefore, NoInputNoOutput is used as the resulting IO capability.
From the above matrix, you map the corresponding IO capabilities and select below enum to place into pairing request/response packet.
OOB DF, OOB data flag
OOB, or out-of-band, uses an external means of communication to exchange some information used in the pairing process. The OOB media could be any other wireless communication standard which can carry the corresponding information for pairing, like NFC or QRCode.
BF, bonding_flags
Bonding is the exchange of long-term keys after pairing occurs, and storing those keys for later use — it is the creation of permanent security between devices. Pairing is the mechanism that allows bonding to occur.
Man in the middle (MITM)
This field is a 1-bit flag that is set to one if the device is requesting MITM protection. This article focuses on the procedure for the pairing feature exchange — if you are interested in MITM, please refer to the Bluetooth Core 4.2, Vol1, Part A, 5.2.3.
Secure connection (SC)
The SC field is a 1-bit flag that is set to one to request Bluetooth LE secure connection pairing. If both devices support Bluetooth LE secure connections, use Bluetooth LE secure connections. Otherwise, use Bluetooth LE legacy pairing. So this flag is an indicator to determine phase 2 pairing method.
Keypress (KC)
The keypress field is a 1-bit flag that is used only in the passkey entry protocol and is ignored in other protocols. passkey entry protocol is a typical pairing method of legacy pairing and secure connection. We will go into this in a future article.
Maximum encryption key size
The maximum key size shall be in the range 7 to 16 octets.
Initiator key distribution & responder key distribution
These two fields have the same definition as below.
When the exchange of pairing feature starts, the initiator and responder will exchange their pairing feature information with each other through pairing request and response. With the information, the initiator and responder can determine the I/O capabilities with each other, which pairing mechanism — legacy pairing or secure connection — should be used, and select the pairing method — just work, passkey entry, numeric comparison, or out of band — to use in phase 2. We will explore the details in Bluetooth pairing key generation methods.
