6.2Overview

6.2.1 Base of Trust

Any security architecture must begin with a base of trust. A “secure relationship” implies that A) there is a reason for the group to exist, i.e. some common goal, and B) there is some requirement that is used to restrict membership to the group. The members of the group “trust” each other because of ‘B’ in order to accomplish ‘A’. An architecture that stops short of defining ‘A’ or ‘B’ is not useful because it only assumes an already functioning relationship. It does not address how the relationship is created in the first place. In common computing jargon, A and B are needed to ‘bootstrap’ the relationship.

If we examine the function of the USB cable in regards of its ability to establish secure relationships between host and device, we find that A) the purpose of the relationship is to transfer data, and B) membership to the group is restricted to only the nodes that the owner/user has chosen by connecting via the wire. If Wireless USB is a wire-replacement, then clearly Wireless USB Security must provide the same function. Therefore, USB Security defines “Ownership” as the base of trust for USB security. Trust always begins with the user/owner and is propagated to the devices by the owner/user. The USB Security architecture is designed to propagate trust from the user to the user’s equipment. The individual nodes can then demonstrate this trust to each other in order to establish the relationships the owner wants.

Different security architectures have different bases of trust that may or may not be applicable to USB. Items that are specifically not applicable are:

•Device/Host characteristics such as manufacturer, model number, firmware revisions.

•External third parties such a Certificate Authorities or Clearinghouses

•Class/Type of device

If a client application requires any of these items for establishing trust, that application can define an application-specific security, implemented on top of the core USB stack.

6.2.2 Preserve the Nature of the USB Device Model

USB Security cannot be allowed to affect the fundamental nature of the USB device model. Implementation must not add significant cost or complexity to a device. It must provide a path for device implementation solely in hardware as USB does not currently require a device to have a processor. If cost or complexity must be introduced, they should be confined to the host.

USB Security must preserve the basic asymmetric communications model of USB. Communications are always, with the exception of signal-replacement messages (connect, disconnect, etc) initiated by the host. This holds true for the security architecture as well. Security operations are always initiated and driven by the host.

The connection policies of USB Security must provide for symmetric authentication between host and device. That is, the device must be given the opportunity to validate the host as the host is given to validate the device. It is just as important to insure that the owner’s device connect to the right host as it is to insure that the owner’s host connect to the right device. This is especially important as some usage models may have two owners involved, the owner of the host and a separate owner of the device.

6.2.3 Implementation of Security Extensions

USB already provides a “device control plane” via the USB framework. This framework was created for performing enumeration and control operations and as such is the ideal method of implementing security operations. Descriptors, Features, and Requests are all used to create the USB Security Framework.

USB Security requests always target the device as the request recipient. USB Security is device-wide and does not make a distinction between endpoints, just as the cable does not.

USB Descriptors are used to enumerate the security capabilities of a device to a host. The device always describes its capabilities to the host. The host then chooses the device capabilities to use. This simplifies device construction and is in keeping with the USB device model.

120