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 (physi- cal) 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 byAandB. In

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 deviceAto identify deviceB. 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. DeviceAstoresBD_ADDR_aliasAtogether with the link

key, the alias address used to identify deviceB(BD_ADDR_aliasB), and the fixed

address of deviceB(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, deviceBstoresBD_ADDR_aliasBtogether with the link key, the alias

address used to identify deviceA(BD_ADDR_aliasA), and the fixed address of

deviceA(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 devicesAandB

(see also Section 8.2.3). The alias addresses should be updated at each new con- nection betweenAandB. 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 corre-

sponding 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.

8.6 Pairing

For anonymous devices, we would like the user to decide (at the pairing) whether to disclose the fixed hardware address or not. Higher location privacy is achieved if the fixed address is only disclosed to trusted devices. By this we mean devices that can be trusted for a long time. This is not true for all pairings, as trust relations might as well be quite temporary. Thus, at the pairing, anony- mous devices need to distinguish between devices to which the fixed address should be given and other devices. This is done by setting the device topairable

orprivate pairablemode. In the first pairing mode, the fixed address is not dis- closed, while it is in the second. This is different from standard Bluetooth units that only support two pairing modes:nonpairableandpairable.

When a device supporting the anonymity mode is in pairable mode, it accepts a request for pairing through the LMP commandLMP in randfrom a remote device. It also issues this command if authentication is requested and no link key for the corresponding device is known. The device does not exchange alias addresses or private addresses with the remote device. The device shall reject all fixed address exchange requests, since it will not give out its own fixed address.

When a device is in private pairable mode, it also accepts requests for pair- ing and initiates a pairing if authentication is requested and the link key is miss- ing. The device uses the new LMP commands (see Section 8.7) to exchange alias and private addresses.

The behavior of a device supporting the new private pairing modes needs to be carefully specified in order to provide good interoperability. We do not give any details here, but in the next section we list a set of LMP commands that can be used by the devices to exchange private addresses and alias addresses and in Section 8.8 we give a private pairing example.