step. This requirement also serves to prevent hosts from interfering with each other’s ability to connect to a device.

A reconnection request is always initiated by a device and received by a host. The reconnection request allows a device to request that it be allowed to resume operation at its previous USB device address, in its previous device state. This allows the “trust” surrounding a connection to be regenerated without having to fully reset and re-enumerate the device.

6.3.2 Authentication

The purpose of the Authentication phase is to allow the device and host to prove to each other that they have the owner’s trust. There are several means of doing this, but the essence of most of the methods is that both parties prove to each other that they know a common secret without revealing the actual secret.

New connections require some form of user-interaction as one of the parties to be connected will not yet have a Connection key. This means that Owner trust has not yet been conveyed to that entity. Just how the user is involved depends on the capabilities of the device. The different types of interactions are covered in detail in the sections below.

6.3.2.1Authentication Related Device Capabilities

USB Security provides multiple means of authentication, based on the capabilities of a device. The host enumerates these capabilities from the device. It then uses the returned capabilities to determine which type of Authentication process to use. Different types are provided to allow the best method to be selected for a specific device type. Different methods make different requirements on devices, so one method may be easily accomplished on one existing device architecture, while adding significant cost/complexity to another. For instance, a printer may already contain a CPU sufficient for PK methods, whereas a specific ASIC state machine would require much additional complexity.

6.3.2.1.1Device has Out-Of-Band Channel for Key Distribution

Devices can provide an out-of-band channel for distribution of a Connection key. Examples of such out-of- band channels might be wired USB connection, memory card, user-interface, etc. Devices that support this mode of key distribution never have to establish new connections. A connection context is transferred to the device via the OOB channel before the first wireless connection is ever made. Since the device was pre-loaded with a connection context, it can use connection requests to establish connections with the host.

6.3.2.1.2Device has Symmetrical Association Key

Devices can have a fixed symmetrical association key. This is typically a hardwired key, set during manufacturing. This key must be unique to the device. The user is required to transfer this key from the device to the host in order to establish a new connection. This may be transferred by data entry or by OOB channel means.

6.3.2.1.3Device has PK Association Keys

If devices wish, they can support Public Key encryption. In this case, the device must contain a unique key-pair. In this case, the user will not be required to transfer a key, but they will be required to participate in validating that host and device have received the correct public key from each other. This insures that the correct devices have been connected.

6.3.2.2Ceremonies

A ‘Ceremony’ refers to the interactions between the entities involved in a secure relationship, specifically the interactions involved in establishing the relationship. Ceremony diagrams are very similar to network protocol diagrams. However, instead of requiring that protocol participants are network nodes, they encompass the user and possibly the environment. The following sections present the Association ceremonies for association

129

methods listed. Note that many equivalent ceremonies can be constructed by simple reordering of ceremony steps. Actual implementations of the ceremonies presented here may use equivalent ceremonies if sufficient benefit exists for reordering.

6.3.2.2.1Association Ceremony for Out of Band Channel Key Distribution

This ceremony is used with devices that have some means other than Wireless USB for receiving a connection context. Regardless of how this OOB channel is implemented, some type of user action will be required to either initiate or complete distribution of the connection context to the device. The user may either directly enter the context information or physically shuttle a context container. Either way, the user’s involvement is required. To be useful for transferring secrets, the user must be able to control access to the OOB channel. This means that the OOB channel used is not susceptible to the same attacks as WUSB.

The Ceremony diagram shows that the ceremony first starts with a CC distribution between the user and the host. Presumably, a distribution from user to host only happens once, when the host is first initialized. If the CC is to be distributed electronically, the user will accept an electronic copy of the CC from the host (on appropriate media).

The next step is the user distribution of the CC to the device. The user transfers the CC to the device via the OOB channel. If the OOB channel is a wire or cable, then the user will not physically transfer the CC. The user will however, be required to instruct the host to distribute the CC to the device.

Once the device has received a valid CC, it uses connect protocol to connect to the host. This protocol is a 4- way handshake sequence using the CK. Successful completion results in the derivation of the PTK, distribution of the GTK, and the announcement of device arrival to the USB sub-system.

Figure 6-3 Ceremony for Out of Band Channel Context Distribution

6.3.2.2.2Ceremony for Association using a Fixed Symmetric Key

This ceremony is used for devices that contain a “static” symmetric key for association purposes. This key must uniquely represent the device. This key can be created during manufacturing or in some cases, be created by the device when first powered up. The key must exist when the device attempts to associate.

The ceremony begins with the device distributing the key to the user. This distribution may be electronic or printed. It could be embedded in installation software or it could be printed on the bottom of the device. Regardless of how the distribution is done, the user is involved in transferring the key from the device to the host. This allows the host to demonstrate Owner Trust by its knowledge of the device key. The device likewise demonstrates Owner Trust by its knowledge of the key. It is important to note that we can treat this key as if it were the owner key because the owner/user was involved in transferring the key. By transferring the key, the owner has effectively approved use of the key as a temporary owner key. While transferring the key to the host, the owner should also instruct the host to advertise via its MMCs that new connections are allowed.

130

Note that in real implementations, the user may not transfer the key to the host until after the device has made its connect request. This allows the host to postpone seeing the key until it knows what the key purpose is.

The device will see the host allowing new connections and make a connect request with the NEW attribute set. The host completes the request and notifies the SME that a new device needs to be processed. The SME enumerates the device and discovers that a fixed symmetric key is required. It gets this key from user, either now or earlier, and enables encryption.

The host and device next perform a 4-way handshake that allows host and device to both prove to each other that they know the fixed key and to derive a PTK to protect the CC.

After successful completion of the 4-way handshake, the host distributes a CC to the device. It then announces the device to the USB sub-system.

Figure 6-4 Ceremony for Fixed Symmetric Key Association

6.3.2.2.3Ceremony for Association using Public Key Cryptography

This ceremony is used for devices that contain a PK encryption key-pair for association purposes. This key-pair must uniquely represent the device. They can be created during manufacturing or in some cases, be created by the device when first powered up. They must exist when the device attempts to associate.

The ceremony begins with the user instructing the host to advertise for and accept new connections. The device will see the host allowing new connections and make a connect request with the NEW attribute set. The host completes the request and notifies the Security Entity that a new device needs to be processed. The SME enumerates the device and discovers that PK encryption is required so it provides the device with the host public key and requests the device public key from the device.

At this point, the owner becomes involved. The owner must validate that both device and host have received the correct public IDs. This validation step is necessary to verify that the host and device are connected to each other and not to malicious agents. This step is also necessary because the user validation of the received keys serves as the transfer of Owner Trust from the owner to the device and host. The owner is instructing the host and device to trust the owners of the received keys.

After successful validation of the device public key, the host uses the device public key to protect and distribute a CC to the device. After distributing the CC, the host performs a 4-way handshake using the newly distributed CC. This allows the host and device to derive a PTK and begin secure operation.

131

Figure 6-5 Ceremony Public Key Association

6.4Interfacing to AES-128 CCM

This section provides the details for interfacing with AES-128 CCM. As specified, this protocol requires the message and some additional keying material be formatted into the CCM nonce, Counter-mode blocks, and encryption blocks. The CCM nonce provides uniqueness to each message. The Counter-mode blocks are used to calculate the MIC. The encryption blocks provide the keystream that it used to encrypt the message and the MIC.

6.4.1 CCM nonce Construction

The CCM nonce is constructed from the following MAC-Layer header components: SrcAddr, DestAddr, TKID, and SFN. The format of the nonce is given in Table 6-3. All values are stored in little-endian byte order.

Table 6-3: CCM nonce format

132