6.2.6.2.4Key Confirmation Key

The Key Confirmation Key (KCK) is a short-lived key used for message integrity during authentication. It is a 128-bit key, derived and used during authentication. It is discarded upon completion of authentication.

6.2.7 Correct key determination

Each encrypted message will have a TKID in the unencrypted header portion of the message. This TKID tells the device which key to use when decrypting the message.

6.2.8 Replay Prevention

The PTK and GTK both require a replay prevention mechanism to satisfy CCM requirements. This mechanism uses 3 components, a Secure Frame Counter (SFC), a Secure Frame Number (SFN) and a replay counter (RC). The host and Device each maintain a separate SFC for each session key they use to encrypt transmitted packets. They also maintain a separate RC for each session key they use to decrypt received packets. The counters are initialized to zero when a new key is installed. The SFN is a latched image of the SFC used to encrypt the packet. This image is included in the encrypted packet.

When a packet is encrypted for transmission, the transmitter first increments the SFC associated with the encryption key. The transmitter then copies the incremented SFC value to the SFN field of the message and encrypts the message. If retries are required, the message is re-encrypted before the retrying. Each successive retry will have a SFN value greater than the last attempt.

When a packet is received, the receiver compares packet SFN value with the value of the RC associated with the decryption key. If the SFN value is less than or equal to the value of RC, then the packet is declared to be a replay of a previous packet and is discarded. If the value of SFN is greater than the value of RC, the receiver will set RC to be equal to the SFN of the received packet. In an actual implementation, RC should only be updated after the packet has passed FCS validation and all security checks.

6.2.9 Secure Packet Reception

The processing of received secure packets is as follows:

•Validate FCS – this step is performed prior to validating security elements.

•Validate the received frame has the correct secure frame settings as per MAC Layer rules.

•Validate the MIC for the received frame.

•Check for replay attacks.

•Update RC only if the previous checks have all passed.

Received packets that fail security checks are discarded. The receiver should record the fact that an error occurred.

6.2.10 General Connection Model

The intent of the Wireless USB connection model is to mimic the wired connection model as closely as possible. Wireless devices will have to be “installed” on a computer just as wired USB devices do. This section presents an overview of the connection model without dwelling on the security-related portions of the process. For these examples, in order to provide clarity to the overall connection model, we assume that security is effectively disabled.

6.2.10.1Connection Context

In order to make secure relationships consistent across multiple connections, some amount of context must be maintained by both device and host. For the case of Wireless USB, this context consists of three pieces of

123

information, a unique host ID (CHID), a unique device ID (CDID), and a symmetric key(CK) that is shared by both parties. The symmetric key is referred to in this document as the connection key. This key is used to reestablish the connection at a later date. This key is always unique. The host never gives the same connection key to multiple devices.

Table 6-1: Elements of a Connection Context

A Connection Context (CC) must contain non-zero CHID and CDID values to be useable by the device. A host can use a CC with a value of zero in either field to revoke an existing context. When loading a context for connection purposes, if a device discovers a CC that contains CHID or CDID values of zero, it shall treat that CC as if it were entirely blank. The device shall make no use of the other fields.

Devices may find ways to add value by supporting multiple CCs. Each CC supported by the device must contain a unique CHID. In the case a device supports multiple CCs, only the CC used to connect to the host shall be made accessible to that host. If the device supports multiple CCs and establishes a first-time connection, the device shall make a blank CC accessible to the host for the purposes of allowing the host to establish an initial CC on that device.

Devices that only support a single CC shall always overwrite the current CC with a newly received CC.

Devices shall only accept CCs via secure channels. A device will only accept a CC delivered via a secure USB pipe or an out-of-band channel.

6.2.10.2Connection Lifetime

The security of any given connection is based on the temporal keys being used to secure that connection. Wireless USB temporal keys have a lifetime of 248 messages, based on the size of the replay counters. In addition, if the host loses communications with the device for TrustTimeout or more, the host must assume the device’s temporal key has been compromised. At a minimum, a 4-way handshake is required to refresh the temporal keys before the regular traffic is resumed. When a device loses communications with the host for TrustTimeout or more, it must send a reconnect device notification to inform the host that the device wishes to resume operation, re-authenticate the host, and generate new temporal keys. A device that experiences a TrustTimeout shall only accept requests to its default endpoint until trust is reestablished. During this period, the device shall NAK requests to other endpoints.

6.2.10.3New Connection

When a new connection is made, the device’s connection context is assumed to be blank. The host may already have several contexts representing other devices already installed. It will create a new context for devices being installed for a first time.

This new context may be transferred to the device in one of two ways: either through an out-of-band (OOB) channel, or via secured USB commands. Devices that receive a CC via an OOB method do not make new connections. Since they are given CCs before attempting to connect, they follow the connection logic described below in 6.2.10.4.

A device with no valid CC will have a zero CDID value. Since a CDID is required for connection, the device must manufacture a temporary CDID value to use for this first-time connection request. The CDID value is needed to allow the host to differentiate between multiple requesting devices at the same unconnected device

124

address. A device shall create this temporary CDID value from a cryptographic random number source. This requirement does not apply to devices that receive CCs via OOB methods.

Upon user initiation of a new connection, the device will seek a host advertising for new connections. When the device locates such a host, it will initiate the connection request with the host.

When the host receives the device request for a connection, it creates a new context for the device. This context consists of CHID, CDID, and CK. This context is transferred to the device using the Framework.

A device shall generate a new CDID value for every user invocation of a new connection. Once a device has created a temporary CDID, it shall retain the CDID until it receives a new CDID as part of a CC from its host or the current connection attempt fails.

Because the temporary CDID is a random number, there is a very small chance that two devices will attempt to make a new connection to the same host using the same CDID. This also means that there is a very small chance that the host will connect to the wrong device. The protocols used for establishing connections between host and device contain protections against this and will fail to connect. This error-checking combined with the requirement that a device create a new temporary CDID after a failure provides the means for recovering from this error.

6.2.10.4Connection

A device may make a connection with any host that it has a connection context for. To make a connection, the device first has to locate the host advertisement for the known host. This is done by locating a host broadcasting a CHID that matches a Connection Context CHID known by the device. Once located, the device makes a connection request, supplying the corresponding Connection Context CDID.

The host, upon receiving the connection request uses CDID to locate the corresponding context for the device. If a context is found, the host completes the connection by issuing a Connect Acknowledge to the device. As part of the Connect Acknowledge, the host will also move the device to a unique un-authenticated device address.

At this point, both host and device perform mutual authentication and key derivation using a 4-way handshake and the CK. Upon successful completion of the 4-way handshake, the host will enable the device for operation.

6.2.10.5Reconnection

When a device loses communications with the host for a period of time greater than TrustTimeout, it must inform the host that it no longer trusts the security of the connection. It does this by sending a connect request to the host, specifying its CDID and its previous device address. This request informs the host that the device wishes to re-authenticate the connection without losing its current device state and configuration. The host may choose to either allow the device to reconnect while retaining device state or it may process the request as a connect request, instructing the device to reset any remembered state.

6.2.10.6Revocation

When we make provisions for creating secure relationships, we must also make provisions for deleting them. Revocation of a connection by either party can be accomplished by deleting the unique host ID from the device or by deleting the unique device ID from the host. The host can delete the context via framework commands. How the device deletes a context without host intervention is outside the scope of this document, however, the device should provide the user with an ability to return to “factory default settings”. This action should delete any contexts currently held by the device.

6.2.10.7One-time Connections

In some use cases, hosts will not wish to establish permanent connections. Some use cases will want to establish a one-time connection where a CC is delivered to the device to allow a connection to occur, but the CC is not retained for future connections. The host can accomplish this by delivering a CC to the device, then revoking the CC immediately after the 4-way handshake is completed.

125

6.2.10.8Diagnostic Support

Support for diagnostic equipment is important for the success of a new technology. Wireless USB recognizes this need and accommodates it by leaving the common trigger elements in clear-text in transmitted messages. These components are still authenticated by the integrity value. Only the data payload portion of Wireless USB transactions will be encrypted. Device Notifications are authenticated only and contain no encrypted data.

Specific security-defeat mechanisms will not be added to provide diagnostic access to encrypted payloads. . These types of mechanism tend to be more useful to the attacker than the developer. What is really required is a way to provide the diagnostic tool with the keys used by the host and device. This will typically be done on a channel other than Wireless USB, so this specification will not define the mechanism to be used. Instead, this chapter offers three suggestions of dealing with encryption when using diagnostic tools.

•Test in unauthenticated mode. This mode supports a limited subset of framework requests and test modes that can be used to test basic operation

•Make the “Connection Key” available to the diagnostic software. If a 4-way handshake sequence is captured, then the diagnostic tool has all the material needed to perform the same key derivation logic as the host and device did. To aid in this, this specification defines the CK value of 0 to be the Wireless USB Diagnostic Connection Key.

•Provide a means of moving the current temporal keys from the host to the diagnostic device.

6.2.10.9Mutual Authentication

As noted in the introduction, authentication must be symmetrical between the host and device. USB Security accomplishes this by using a 4-way handshake that allows the host and device to prove to each other they hold matching CKs. The 4-way handshake also allows both parties to derive initial session keys from the CK without directly using the CK to encrypt transmitted messages.

6.2.10.9.14-Way Handshake

The 4-way handshake combines mutual authentication and temporal key distribution into a single 4-message protocol. Temporal keys are derived in a manner that does not expose the CK, thereby eliminating the need for a unique nonce for every use of the CK.

The host initiates the 4-way handshake by sending a TKID and a 128 random nonce HNonce to the device. The device also creates a random nonce DNonce. The device then provides it’s DevAddr, the host’s DevAddr, and the two nonces to a key generation function. This key generation function derives an initial session data key. The key generation function also derives the Key Confirmation Key (KCK), which is used during authentication and then discarded.

The host initiates Phase 2 of the 4-way handshake by asking the device for DNonce. The device returns the TKID and DNonce. It also adds a third item to the returned data. It uses KCK to compute a message integrity code (MIC) over the TKID and DNonce.

When the host receives the DNonce message, it can also derive the initial session data key. After deriving the key, it validates the MIC received from the device by performing the same MIC computation with KCK. If the MICs do not match, the host halts further processing and silently disconnects the device.

At the end of Phase 2, the host and device have both derived initial session keys and the host has proof that the device holds the correct CK. Phase 3 is used to provide proof to the device that the host also holds the correct CK and to instruct the device to install the derived key. The host initiates Phase 3 by installing the derived session key and constructing a message containing the TKID, HNonce, and a MIC computed over the previous fields with KCK. It sends this message to the device. The device validates the received MIC by also performing the MIC computation. If the MICs do not match, the device silently disconnects. If the MICs match, the device installs the derived session key.

Phase 4 of the 4-way handshake is used to tell the host that the device has successfully installed the session keys. Wireless USB devices perform phase 4 by successfully completing the status phase of the Handshake3

126