control request. The derived PTK is installed by the device and available for use immediately following the successful completion of the Handshake3 control request.

6.2.11 Key Management

This section describes the general key management philosophy of USB. In general, hosts are responsible for key management operations. Hosts track the life of session keys and are responsible for creating and distributing replacement keys, or causing replacement keys to be derived. Devices do not request new keys. If a device becomes unsynchronized with respect to the current session key, the device must send a Reconnection request.

Session keys are never transferred from device to host via the USB Framework. Distribution of a session key is a one-way function. Once in possession of a session key, the device never divulges that key.

Get Key operations are restricted to public keys. If needed, a host will ask a device to divulge its public key.

6.2.11.1PTK Management

The PTK is derived during the 4-way handshake and typically does not change during the life of the connection unless a TrustTimeout occurs on either the host or device. Under extreme circumstances, the key can be consumed if it is used to encrypt 248 packets. In this case, the host must perform an additional 4-way handshake with the device in order to derive a new PTK before the old PTK expires and the SFC associated with that key rolls over.

6.2.11.2GTK Management

The GTK is shared among all devices. Because it is shared, it must be changed whenever a device leaves the current group. Problems with detecting device departure in a wireless environment may cause hosts to choose to update GTKs at a fixed periodic interval.

Distribution of the GTK presents special problems with key synchronization between the host and the devices. The key distribution mechanism provides that the device will be ready to use the new key at the completion of the distribution request. However, the host must re-key all the devices in the current cluster. A device can take several MMC periods to respond to a key distribution, so synchronizing a GTK change among devices is an almost impossible task.

To simplify this task, USB requires that devices be capable of holding two current GTKs. Session keys have a 7-bit index value. The host will use this value to distribute GTKs in numerical order. The device provides a table capable of holding two keys. The low bit of the session key index is used as the table index. This allows Key2 to replace Key0, Key3 to replace Key1, etc.

When the initial connection is established, the host distributes key K0. When the host detects that a device has left the group, it distributes K1 to all the devices in the group. When the last device responds, the host installs and begins using the new GTK. On the next departure, the host distributes K2. Devices replace K0 with K2 as they receive it. The host continues to use K1 until K2 is installed on the last device. If another device departs before K2 can be distributed to all devices, a host should abandon distribution of K2, skip distribution of K3, and begin distributing K4.

A device should not discard an older GTK until the host begins to use the new GTK. Once the host uses the new GTK, it must not use the older GTK.

6.3Association and Authentication

When a Wireless USB connection is made, the host and device must complete association and authentication phases before the connection is considered operational. As the device progresses through the phases, additional host components are made aware of the device. Upon completion of the phases, the device is presented to host USB stack and standard USB device enumeration begins. In short, this means that device and host must fully authenticate each other before the USB stack is made aware of the device.

127

Figure 6-2: Association Phases

The Association phase of a Wireless USB connection deals with three separate problems that must be addressed in order to create a secure connection. The first problem is establishing the initial connection. In the wiredUSB world, this happens because a physical connection is made by the user. The host and device are informed of the other’s presence via circuit completion and electrical signaling. In the wireless world, we can’t use circuit completion so we must compensate by adding additional protocol messages to allow a device to request a connection with a host.

The second problem that must be addressed is that of verification of the other party. In some manner or form, each party involved in any connection must demonstrate to the other party that they have the “owner’s trust” and can therefore be connected.

The third problem is derivation of the initial PTK. Once the initial PTK has been derived and the GTK has been distributed, the device can be considered operational. It can then be presented to the main host USB Stack for the standard USB device enumeration sequence.

6.3.1 Connection and Reconnection Requests

A connection request is always initiated by a device and received by a host. The actual format of the Connection request is covered in Section 7.6.1. Of interest to security are the unique device identifier and one bit of information contained in the request. This bit is the NEW indicator. The state of these bits determines the type of connection request being made.

Table 6-2: Connection Request Types

0Connection Request – The device has previously been connected to this host. Verification will be performed with the CK.

1New Connection Request – The device has not previously been connected to this host. The host will enumerate the security capabilities of the device to determine the appropriate authentication procedure. The host will distribute a CC to the device.

Not all connection types are allowed at all times. Typically, a host will always allow reconnection requests but only conditionally allow first-time connection requests. This allows automatic recovery from host reboot, loss and recovery of channel, roaming, etc.

Some user-initiated event must be required to allow a host to accept new connections. The user is the only entity in the user-host-device relationship who knows when a new device is present in the environment. Since user validation of new devices is required anyway, involving the user at this stage serves as a pre-validation

128