Broadcast Encryption

address is all zeros, the message is a broadcast; otherwise it is destined to an individual device. Since the LT _ADDR is received rather close to the payload, there is very little time for the decryption machinery to get properly initialized before the deciphering starts. To avoid the uncertainty of which key to use, only one key can be valid at a time. As a consequence of this, there are three supported modes for traffic in Bluetooth:

1.No encryption—all traffic is in plain text.

2.Encryption on point-to-point links based on semipermanent link key1 —broadcast traffic is still unencrypted.

3.Encryption on point-to-point and point-to-multipoint links—indi- vidual traffic and broadcast traffic are encrypted using the same encryption key.

The last case above implies that the link privacy is effectively removed with respect to all units sharing Kmaster but kept with respect to the rest of the world.

5.2 Preparing for broadcast encryption

In a broadcast scenario, since all slaves use the same encryption key, they must all support the encryption key length that the master chooses. Some countries have put export restrictions on hardware equipped with encryption circuitry. For this reason, the effective key length of the encryption key can be restricted to something less than 128 bits using the procedure described in Section 3.6.2. The maximum length supported is determined by the manufacturer and cannot be changed afterwards. In practice, this is accomplished by only implementing a subset of the key constraining polynomials defined in Table 3.2.

In order to select the key length, the master must know what lengths are supported for all individual members of the piconet. For devices compliant with version 1.1, there is no standardized way of obtaining this information, and the only available method is the key negotiation procedure that we described in Section 3.6.2. The complexity of gathering individual capabilities and negotiating the key size is one of the reasons broadcast encryption capability is a feature not always implemented in 1.1-compliant devices. Among the 1.1-compliant units that have this feature, practical tests have shown that interoperability between different manufacturers is not particularly good.

1.The 1.2 specification indicates that if a master key has been distributed, individual traffic can be encrypted based on that temporary key in this mode. As broadcast messages are unencrypted, the device is not forced to use Kmaster and the individual semipermanent keys give higher security.

The interoperability has been considerably improved in the 1.2 version of the specification [2] with the two new LMP commands:

•LMP encryption key size mask req

•LMP encryption key size mask res

The first command can be used by the master to request a bit mask that describes the supported key length (in bytes) by the slave. The slave uses the second command to return the supported key length (for the details; see Section 5.3). Furthermore, the LMP features mask, exchanged at link setup, defines what features are available in a device. From version 1.2, the number of possible features that can be defined have been increased significantly by the means of extended features masks. This is just a new LM PDU for which the bit positions in the payload refer to the extended features. Generally, for each optional LMP feature, the features mask indicates whether it is supported or not. As broadcast encryption is now defined to be an optional feature, it is supported only if the corresponding bit in the extended features mask is set. Legacy devices do not have the extended features mask, but it is possible for a new device to determine this from the LMP version number.

5.3 Switching to broadcast encryption

Before encrypted broadcast is possible, the master must change the current link key. To switch from the semipermanent to the temporary key, a few steps must

be carried out. First, the master generates the temporary link key, Kmaster. Obviously, this key cannot be sent in plaintext. One option would be to distribute it

over encrypted links. However, this imposes an unnecessary restriction, as it mandates an initial switch to encrypted master-slave traffic, even in cases where the application requesting broadcast traffic does not need it. Instead, the key is sent XORed with an overlay that is a function of the current link key and a public random number. The details of this scheme can be found in Section 3.4.5.

Whether or not broadcast encryption is supported can be determined via the LMP features mask. Furthermore, as we discussed previously, one can request the supported key lengths using the LMP encryption key size mask req. In this PDU, there are 16 bits whose positions correspond to the same length in bytes of the encryption key. For each supported length, the corresponding bit is set, and for each unsupported length, the bit is not set. Thus, the least significant bit corresponds to an 8-bit key, while the most significant bit corresponds to a 128-bit key. After acquiring this information from all slaves,

Subscenario 1.1: No common key size for slaves and not forced

HCI master link key complete

(status, conHandle, key flag)

Subscenario 1.2: Common key size available or forced

Subscenario 2: Switch from Master Link Key to Semipermanent Link Key

Figure 5.1 Message sequence chart for setting up broadcast encryption and for returning to individual link encryption.