Providing Anonymity	131

8.4.3General connectable mode

When a Bluetooth device is in general connectable mode, it makes page scans on both the Bluetooth active device address, BD_ADDR, and the fixed device address, BD_ADDR-fixed. This makes it possible for a device to accept Bluetooth connections from both trusted known devices and unknown devices (through the inquiry procedure). A device in general connectable mode makes two consecutive page scans at each scanning occasion. Only the scanning modes R1 or R2 can be used in general connectable mode and not R0. The first scan is based on the page hopping sequence derived from the BD_ADDR and the second scan is based on the page hopping sequence derived from the BD_ADDRfixed. Since R0 is not supported, fast connection setup cannot be achieved by using continuous scanning. When very fast connection setups are required, it is possible to use two consecutive R1 page scans with interlaced scan and very short page scan interval. The paging attack (see Section 7.6.2) applies also to the general connectable mode. To reduce the risk for this attack, a device shall always expect an alias authentication request (see Section 8.5) from the master after making a response to a paging on the fixed address. If no alias is received or the setup fails before the connection state has been reached, a connection failure counter can be incremented (see Section 8.4.2).

8.5 Alias authentication

As we have discussed, anonymous devices regularly update the active device address. Hence, the active address cannot be used to identify devices. This is not strange, since the whole idea with the anonymity mode is that it should not be possible to identify devices. However, this causes problems when trusted devices would like to authenticate each other and set up secure connections without repeated pairing. We introduce alias authentication to solve this problem. Alias authentication is a method to disconnect the link key dependency on the (physical) device address and an alias address is used as a link key identifier. To be more precise, alias authentication allows authentication based on an alias address instead of the active or fixed device address. By exchanging alias addresses after a link is established but before authentication takes place, the involved devices are able to find the link key associated with the established link. This possibility is useful not only for anonymous devices but for other purposes as well. One example is when a device attaches to a network access point and the device wishes to authenticate to the network rather than the access point (see Section 10.2).

Alias addresses are used to identify a security association between a pair of devices (or a network and a device). Denote two devices in a pair by A and B. In

132	Bluetooth Security

the symmetric case, two alias addresses are used. One address, BD_ADDR_ aliasA, is used by device B to identify device A, and the other address, BD_ADDR_aliasB, is used by device A to identify device B. Alias authentication can also be used in an asymmetric fashion. In that case, only one of the devices in the pair uses an alias address to authenticate the other device. The other device in the pair is identified (for mutual authentication) using the fixed address. If both devices are operating in anonymous mode, symmetric alias authentication will apply and the devices exchange two alias addresses, one for each device.

For the anonymity mode, we propose a special pairing procedure. During this pairing procedure, the devices exchange alias and fixed addresses (see Section 8.6). A device supporting alias authentication needs to maintain an alias database (part of the key and device database). The alias database maps alias addresses to link keys. Device A stores BD_ADDR_aliasA together with the link key, the alias address used to identify device B (BD_ADDR_aliasB), and the fixed address of device B (BD_ADDR-fixedB) in its database. (The fixed address is sent to the device over an encrypted link at the pairing occasion. See Section 8.6.) Similarly, device B stores BD_ADDR_aliasB together with the link key, the alias address used to identify device A (BD_ADDR_aliasA), and the fixed address of device A (BD_ADDR-fixedA) in its database.

We propose to use the same format as the BD_ADDR for the alias addresses. The 48 bits shall be chosen uniformly at random by devices A and B (see also Section 8.2.3). The alias addresses should be updated at each new connection between A and B. If this is not the case, there is a risk that the device is instead tracked based on the alias address. It is most convenient if the new alias is generated by the “owner” of the alias address; that is, device A updates

BD_ADDR_aliasA and device B updates BD_ADDR_aliasB. The updated address is only allowed to be sent over an encrypted channel.

In the case of an application that uses the same alias for several different devices (e.g., see Section 10.2), the updated address might be the same as the previous. However, this principle shall only be used when alias addresses are not used for anonymity purposes.

At the next connection setup, the BD_ADDR_aliasA and BD_ADDR_ aliasB need to be sent before authentication (but after a check that the corresponding device supports alias authentication) is performed. If this is not done, it is impossible for the devices to identify the right link key to use. Device A should send its BD_ADDR_aliasA and device B should respond with BD_ADDR_aliasB (see also the example in Section 8.8). The alias addresses are then used by the devices to find the correct link key. The link key is then used to perform mutual authentication and calculate the encryption key that is needed for the connection to be encrypted.