58	Bluetooth Security

cipher to produce 240 symbols. Altogether, KP is 132 bits in size. In Section 4.4.1 we return to the exact details.

3.7 Key databases

The Bluetooth combination key is used to protect the communication setup for one particular combination of two Bluetooth units. The key is unique for each combination of two Bluetooth units. Hence, there are as many combination keys as there are paired Bluetooth devices. Furthermore, all semipermanent keys (to which the combination key belongs) may be used for several repeated sessions between two units. Consequently, it should be possible to store semipermanent link keys in nonvolatile memory and it should be possible to retrieve the key upon request.

3.7.1Unit keys generation requirements

The unit key is a 128-bit binary value that is generated as described in Section 3.4.2. It is of utmost importance that the random value used to generate the unit key is provided with a reliable random number generator with good statistical properties (see the recommendations in [2]). Furthermore, the random value used for the key generation should be discarded immediately after it has been used for the key generation. Once created, the unit key needs to be stored in a nonvolatile memory and should not be changed (see also Section 3.7.3).

3.7.2Combination key generation requirements

The combination key, KAB, is also a 128-bit binary value that needs to be stored in a nonvolatile memory (see Section 3.7.3). It may remain constant after it has been created. However, it is good security practice to periodically change the combination key.

The procedure for changing the key is exactly the same as in the initial generation of KAB during the pairing procedure (see Section 3.4.3), where the current value of KAB replaces KINIT in the generation procedure. There is a specific HCI command that the host can use to enforce the key update: HCI Change Connection Link Key. Assume that the link manager of unit A receives a key change request through the HCI. This will cause the link manager to send an LMP comb key command to unit B. Unit B will respond with LMP comb key, and the key will be updated or it will reject the request by sending an LMP not accepted. After a successful generation of a new combination key, a mutual authentication must be performed in order to confirm that the same key has been created in both units. The host controllers of both units A

Bluetooth Pairing and Key Management	59

and B will then generate an HCI Link Key Notification event and the host controller of unit A will generate an HCI Change Connection Link Key Complete event. The HCI Link Key Notification event of unit A contains the device address of unit B (and vice versa) and the new value of the link key. The host can choose to store the new key in its own database, or it can be stored by the link controller (see Section 3.7.3 below). The

HCI Change Connection Link Key Complete event is only used to indicate whether the change of the link key succeeded or not. A message sequence example of combination key change is shown in Figure 3.7.

The combination key update policy of a unit should be part of the unit security policy. This security policy might be different for different units. If KAB is used very often, it needs to be updated regularly. Similarly, if there exists an indication that KAB has been compromised, it should of course be changed.

Host A		HC/LM-A		HC/LM-B		Host B
		Master		Slave

HCI Change

Connection

Link key

HCI Command

Status event

LMP comb key

LMP comb key

Mutual authentication

HCI Link Key Notification event

HCI Change

Connection

Link Key Complete event

HCI Link Key Notification event

Figure 3.7 Message sequence chart for a change of the combination key.

60	Bluetooth Security

3.7.3Key databases

Format and usage

To retrieve the correct link key upon request from the host or unit, the semipermanent link keys must be stored in a database. Consider one Bluetooth unit, say A. Below we discuss the database format and usage from the perspective of this unit.

The link key is identified by the device address of the other unit in the link. In this case, A needs to store as many keys as the number of performed pairings with distinguishing units. Consequently, the simplest form of database is a list of key entries where each entry only has two values, the device address, and the corresponding link key. This is shown in the database example in Table 3.3, where the device addresses and key values are written in hexadecimal notation. The device address is a 48-bit long (12 hexadecimal digits) value, while the key is 128 bits long (32 hexadecimal digits).

If A is always using a unit key, there is no need for a link key database, since the same key is used for all connections (independent of the device address of the other units). We might have a situation where the unit would like to issue unit keys for some connections while still using combination keys for other connections. However, in practice, there would in most cases then be enough storage capacity for always using a combination key and not using unit keys at all (see also the general discussion regarding unit keys in Section 7.5).

If we use the simple database format of Table 3.3, no information is given of the type of semipermanent key that is used (i.e., unit or combination key). However, a key in the table entry might be a unit key. Since a unit key is not as secure as a combination key, we might want to enforce a more restricted security policy (see Chapter 6 for more information on the usage of security policies in Bluetooth). Hence, it might be good to add one extra information field containing the key type to each entry in the table. We show this in the database example in Table 3.4. In this example, all listed keys except the last one are combination keys.

In addition to this basic information, it is advisable to add some redundancy to the database entries so that errors can be detected. The reasons for this

Table 3.3

An Example of a Link Key Database

Device Address	Key
10FA48C7DE52	1B4D5698AE374FDE8390912463DFE3AB
047F6BB427EA	FE729425BC9A95D39132BDE275917823
A5EE29667190	091827AD41D4E48D29CBE82615D18490
068935F6B3E2	126304467592CD71FF19B4428133AD8E

	Bluetooth Pairing and Key Management		61
		Table 3.4
	Link Key Database Example with Key Type Information
	Device Address	Key	Key Type
	10FA48C7DE52	1B4D5698AE374FDE8390912463DFE3AB	C
	047F6BB427EA	FE729425BC9A95D39132BDE275917823	C
	A5EE29667190	091827AD41D4E48D29CBE82615D18490	C
	068935F6B3E2	126304467592CD71FF19B4428133AD8E	U

U = unit key; C = combination key.

will be discussed in the next section. For instance, a simple 8-bit CRC code can be added to each row of Table 3.4.

Corrupted database

The link key database might for some reason become corrupted. The probability of having corrupted databases depends on the type of storage medium and the storage protection mechanisms. If a device address field is damaged, it might result in key lookup error. If the corrupted key entry is detected when the unit is about to send an authentication (acting as verifier), the error can be handled internally by the unit. In this case, it should be possible for the user (if desired) to demand a new pairing and derive a new link key, and the unit will initiate a new pairing by sending the LMP command LMP in rand.

If the corrupted key entry is detected after an authentication request by the other unit, the unit should return LMP not accepted after it has received the LMP au rand (see Section 3.3) with the reason “key missing,” as illustrated in Figure 3.8.

The behavior in this case is up to the unit requesting the authentication. It might demand a new pairing by sending an LMP in rand, or it might refuse the connection and detach the link. However, in order to handle corrupted databases, there should always be the possibility for the user to make a new pairing of the two devices. Hence, it must be possible for the user to find out the reason for a failed link setup.

Initiating		LMP	au	rand		Responding
		LMP	in	rand
unit		Reason		code = 0x06		unit

Figure 3.8 Authentication after key lookup failure by claimant unit. The claimant unit returns “LMP not accepted” with reason code 0× 6 (i.e., “key missing”).

62	Bluetooth Security

Storage

There are several different options for where and how to store the link key database. The Bluetooth controller might have the capability to cache a limited set of recently used link keys. However, the most common situation is that the link key database is handled by the host and that the necessary link keys are passed to the Bluetooth controller (i.e., the Bluetooth module), for example, through the defined HCI command HCI Write Stored Link Key. This command can be used to transfer one or several link keys from the host to the Bluetooth controller. The number of possible keys is determined by the link key storage capacity of the Bluetooth controller.

It is also possible that the Bluetooth controller itself completely handles the link key database. However, this is not an especially secure solution, since there is no secure HCI mechanism (involving user authentication) defined for “opening” the key database. This problem will be discussed in Section 7.4.1.

Hence, we will below assume that the key database is handled by the host. If the host handles the security database, but the keys are passed to a link key database in the controller, it is good security practice to delete the keys from the controller database after they have been used. This can be done through the HCI command HCI Delete Stored Link Key.

The Bluetooth specification does not contain any recommendations for how a host should handle the key database. Here we discuss some issues and possible solutions. In Section 7.4 we will come back to the risks that one may face if storage is not handled correctly.

There are two important security issues regarding key storage: access control and secure storage. In order to prevent a hostile user or software in control of the host to read and/or modify the link keys, the access to the keys should be restricted. Furthermore, depending on the security requirements, it should not be easy for a hostile user to physically read out the keys from the storage medium. It must still be possible for authorized users to open the database. Hence, there must be mechanisms in place for some type of user authentication. Simple forms of user authentication are PINor password-based authentication mechanisms. We discuss three different approaches to database storage that provide user authentication through a PIN or password.

A highly secure storage medium is an integrated circuit card (ICC). In order to access information on an ICC, the user is often required to enter a PIN. Hence, an ICC provides both a user authentication mechanism and secure storage. Whenever, this security level is demanded and affordable, this would be the preferred solution for storing the link key database.

If an ICC is not available, an alternative is to store the database encrypted on a general storage medium available to the host (like a hard disk or flash memory). If the database should be encrypted, there must be an encryption key available. Obviously, if this key is stored in clear text, there is no need for encrypting the