Chapter 7

Wireless USB Framework

This chapter describes the common attributes and operations of Wireless USB Device Management. It depends on Chapter 9, “USB Device Framework”, of the USB 2.0 Specification as the baseline, and then describes differences and extensions to the base USB Framework. The chapter starts with a description of a device state machine. This is followed by a description of extensions to standard Framework commands to support the wireless device space, then a description of the Security-specific extensions. This chapter concludes with a description of the additional Descriptors and Information Elements needed to support wireless devices.

7.1Wireless USB Device States

A device has several possible states. Some states are visible to the Wireless USB host, while others are internal to the device. This section describes the visible states.

The device states envelope the USB device states documented in the USB 2.0 specification as illustrated in Figure 7-1

Figure 7-1. Wireless USB Device State Diagram

Because a physical connection does not exist, data communication between a device and host requires that a relationship be established to serve as a logical connection. As noted in previous chapters, a host and device

137

have to make this logical connection secure before the host will use the functions advertised on the device. The model for establishing a connection and securing it is based on the device states illustrated in Figure 7-1. The sections below describe the specific device states and the general events or criteria required to occur for the device to make a state transition.

Devices don’t receive power from the host platform which means they must use power from a local source. Therefore, the device state diagram does not include the notion of a “powered” device state.

7.1.1 UnConnected

A device that does not have any established communications with a Wireless USB host is in the UnConnected state. A device defaults to this state on power up and can return to this state if:

•The device or host executes an explicit disconnect, or

•A reconnection attempt fails (i.e. host does not acknowledge the encrypted DN_Connect notification from the device), or

•The device observes a ResetDevice_IE with a matching CDID element value, or

•A 4-way handshake does not complete successfully. Failures may occur due to a variety of factors, including taking longer than TrustTimeout seconds to complete, a STALL response, etc.

While in the UnConnected state, the only data communications a device can initiate with a host over its Wireless USB Channel is a connect device notification (see DN_Connect in Section 7.6.1) . A device in the UnConnected state must have its Wireless USB channel device address set to the UnConnected_Device_Address, see Section 4.3.8.5. A device must not use secure packet encapsulation (i.e. SEC bit = 0b) when transmitting DN_Connect notifications when in the UnConnected device state. A device stays in this state until it has attempted to connect (via a connect device notification) with a specific host on its Wireless USB channel and the host has acknowledged receipt of the connect notification by sending a Connect Acknowledgement. When the host responds to a connect notification, the acknowledgement will also assign the device a device address in the Unauthenticated_Device_Address_Range, see Section 4.3.8.5

At this point the device and host have exchanged information, so the two know that data communications are possible, and the device is logically “connected” to the host’s Wireless USB channel. The device transitions to the Connected general state.

7.1.2 UnAuthenticated

The device entry sub-state within the connected device state is the UnAuthenticated device state, where data communications between the host and device are restricted to exchanging authentication messages and other related security information. This information can only be exchanged over the Default Control Pipe and because the device is unauthenticated most of the exchange must be conducted in plain text (i.e. no security encapsulation). Control requests are allowed in this state to authenticate the connection, allow the host to distribute the GTK, and to set the device to a specific USB device address in order to transition it to the Authenticated device state. The data communications that are allowed between a host and device from the UnAuthenticated state are described in Section 7.3.

When the device enters this state, it may have a device address in either the unauthenticated or USB device address range. If the host decides to completely re-enumerate the device, the following ordered set of control operations must successfully complete in order to transition the device to the Default sub-state of the Authenticated device state. Note, this is the required sequence the host must take when the device is coming from the UnConnected device state.

1.The host successfully completes the authentication process (4-way handshake). This set of control transfers establishes the PTK (used for data packet encryption).

2.The host successfully completes a SetKey(GTK) request. The host uses this request to load the current GTK onto the device so that the device can authenticate Wireless USB Channel broadcast packets (e.g.

138

MMCs). The host must encrypt the data stage of this request (using the PTK established during the 4- way handshake) in order to protect the delivery of the GTK.

3.And finally, the host completes a SetAddress(0) request. The device must authenticate the MMC which includes the new device address using the GTK.

After the 4-way handshake completes, the device and host are required to begin using the PTK to encrypt all data phase and handshake phase transaction packet transmissions. After the SetKey(GTK) is complete, the device must authenticate all MMCs before responding to requests.

The host may choose to simply re-authenticate the device and return it to its previous Authenticated device sub-state. To accomplish this the host must first re-authenticate the device (successfully complete a 4-way handshake) and optionally a SetAddress() to the device’s previously authenticated USB device address. Note the SetAddress() is only required here if the host responded to the DN_Connect with a device address in the UnAuthenticated_Device_Address_Range.

If the ordered set of control operations fails to complete within TrustTimeout seconds (start to finish), the device returns to the UnConnected device state. Note that if the 4-way handshake fails from the host’s perspective, the host will simply not continue with the authentication control requests. The host may give up retrying the SetKey() and SetAddress() requests after an implementation-specific number of tries. If the device responds to any of the control requests in this sequence with a STALL response, it will then return to the UnConnected device state.

There are no intended inter-dependencies between the different kinds of control requests that are valid in this state, besides those described above between the 4-way handshake, the SetKey(GTK) and the SetAddress(). In general a host should perform all ancillary control requests to read pertinent information from the device before beginning the ordered sequence of commands required to transition the device to the Authenticated device state.

7.1.3 Authenticated

The intent of this state is that it is the ‘normal’ operating state for functional data communications using secure packet encapsulation. If the device address on entry to this state is zero (0), then the required destination substate is the Default state. Whenever a SetAddress(0) completes, the device will transition directly to the Default device state. The side-effects of a SetAddress(0) are defined in Section 4.12. If the device address on entry to this state is not zero, the device returns to the appropriate sub-state it was in previously when it transitioned from the Authenticated to Reconnecting state.

The definition and use of the Address and Configured device sub-states are identical to those defined in the USB 2.0 specification (Chapter 9). Note that only the Default Control Pipe is available for data communications over the Wireless USB channel when the device is not in the Configured device state (see Figure 7-1). By definition, function endpoints do not exist until the device has been configured; therefore, a device must not respond to transactions addressed to non-configured endpoints.

Note that the host may initiate a 4-way handshake at any time with the device, including while it is in any substate of the Authenticated device state. The control transfers used to conduct the 4-way handshake do not use secure data encapsulation during the data and handshake phases of the control transfers. A device must continue to use its valid GTK to authenticate the MMCs transmitted by the host. This is the only exception to the rule that data communications that occur during the Authenticated device state use secure packet encapsulation.

A device will exit this state under the following:

•Explicit disconnect event. The device or host has initiated an explicit disconnect or the User of the device has initiated a New Connect operation. The device transitions to the UnConnected device state.

•Authentication Refresh Fails. In other words, a 4-way handshake fails to complete. The device transitions to the UnConnected device state.

•Trust Timeout Event. As described in Section 6.2.10.2 a device must not trust the data communications with its host whenever it loses communications for greater than a TrustTimeout. Precisely, when a device

139