3

Bluetooth Pairing and Key Management

In this chapter we will have a closer look at pairing and key management in the Bluetooth system. Key management involves the generation, distribution, storage, and handling of the cryptographic keys. We recall from Table 2.1 that the main key types in Bluetooth are the link and encryption keys. Of these, the link key is the most important, since it is the basis for all future identifications between the units, and it is also used in the creation of an encryption key for each session requiring privacy. The link key is created during the pairing operation.

In the following sections we discuss pairing and Bluetooth key generation, storage, and updating of the link and encryption keys in more detail. We first give an overview of the pairing process as performed by Bluetooth 1.2 devices. We will show the involved steps and mechanisms in each of the Bluetooth stack layers.

3.1 Pairing in Bluetooth

The Bluetooth pairing operation is crucial in the process of establishing a secure connection (link) between two Bluetooth devices. To set up a Bluetooth connection, the involved procedure starts with establishing an ACL connection. When this task is completed, the Bluetooth devices can exchange messages on the radio channel. Before any user data can be exchanged, the devices can (optionally) require verification of their respective identities. In order to make use of the authentication and encryption mechanisms that provide protection against misuse and or wiretapping, the involved Bluetooth devices must establish some shared secret. It is during the pairing that this is accomplished.

43

44	Bluetooth Security

The pairing procedure results in a bonding of two Bluetooth devices in the sense that after the pairing the devices share information that only the paired devices know. At this stage of connection setup, some user interaction is usually required in the form of entering a pass-key (compare Figure 2.1).

For convenience, Bluetooth devices must have the ability to store a number of (link key, device address) pairs in a database for later reference. Preferably, this information is stored in nonvolatile memory. Then when the Bluetooth devices meet again, they already have a link key and can skip the steps related to pairing. The exact number of such pairs is, of course, dependent on what type of application(s) the Bluetooth-enabled device runs. For PCs, the available memory resources should be more than enough to accommodate many hundreds of such pairs, while a phone headset with a very specific usage area need only save a few.

Even if pairing normally is only carried out for first-time connections, the pairing process is also automatically invoked if authentication is requested when one device for some reason (e.g., power failure or corruption of the link key database) has lost the link key for the connection.

The pairing procedure consists of the following steps:

•Generating an initialization key;

•Generating a link key;

•Link key exchange;

•Authentication.

How the pairing process is realized is explained in the following subsections for the HCI protocol, the LMP, and the baseband level, respectively.

3.2 HCI protocol

Using the host controller and baseband commands, it is possible to set the policy for authentication through the Authentication Enable command parameter. When this parameter is enabled, the local device will always authenticate the remote device at connection setup. Only if both units have this parameter disabled no authentication will take place. The setting of the parameter in the device depends on the current security mode. See Section 2.5.1.

Assuming the authentication is enabled in a device, the host controller (HC) will ask the host for a link key to use for the BD_ADDR of the remote device in the authentication protocol that is to be executed. This is, of course, unless the HC already has access to this key by itself (e.g., from caching or direct key storage access). If no such key can be found on the host, a negative response

Bluetooth Pairing and Key Management	45

is sent back (HCI Link Key Request Negative Reply) over the HCI to the host controller. This “failure” event will initiate the pairing procedure.

The first thing needed in the pairing is a pass-key. The HC generates an HCI PIN Code Request event. The reply either consists of a pass-key (plus some additional information) or a negative response indicating that the host for some reason cannot specify a pass-key to use for the connection. The latter will ultimately cause the pairing request with the remote device to fail. When things work as intended, the HC at the initiating side can send the pass-key to the baseband for further processing. Next the LM will send a 128-bit random number (IN_RAND) to the remote device, which will trigger an HCI PIN Code Request event there as well.

From now on it is the LM that runs the pairing. The LMP ensures that a shared secret, the link key, is generated at both the local and remote devices. Depending on the device configuration, the link key can be a unit key or a combination key. The former is completely determined by one of the devices and the latter is constructed using contributions from both devices. Once the LMs have finished negotiating the link key, both hosts will be notified through the HCI Link Key Notification event.

3.3 LM protocol

The LM assists in the pairing procedure by communicating parameters and results between the local and remote devices. The calculations are done in the baseband. On the link manager level, the pairing procedure starts with the transmission of the PDU LMP in rand (containing the 128-bit random number IN_RAND) from one of the units to the other. This PDU will trigger the generation of the initialization key for use in the protocol for creating the actual link key.

If a unit key is to be used, the LMP unit key command is sent in one direction only, with the secret unit key XORed with the initialization key as its parameter. The receiver can easily calculate the key from this. See Section 3.4.2. If a combination key is to be created, two contributions (one from each side) are needed. This is accomplished through the LMP comb key PDU. The argument of this PDU is also a random number, but generating this and deriving the link key from it is slightly more complicated. For details, see Section 3.4.3.

After these PDUs have been exchanged, both ends are able to compute the link key. As a final check of success of this procedure and the established link key, a mutual authentication event is performed. A 128-bit challenge is sent through the LMP au rand, and the 32-bit response uses the LMP sres PDU. If neither of these authentications fails, both the local and the remote HCs notify their respective hosts.