Patent Application
20230315832
The Universal Serial Bus (USB) Type-C Authentication Specification may be used to restrict the types of devices that may connect to a host system through a USB Type-C port of the host system. The basic principle of the specification is that a device sends verifiable information about itself in the form of a secure certificate chain. The host system then uses this information to determine whether the host system should allow the device to connect and share information with the host system. The criteria used to determine whether a device should be allowed to connect to the host system is called an authentication policy.
In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific examples in which the disclosure may be practiced. It is to be understood that other examples may be utilized and structural or logical changes may be made without departing from the scope of the present disclosure. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims. It is to be understood that features of the various examples described herein may be combined, in part or whole, with each other, unless specifically noted otherwise.
An organization's Information Technology (IT) department (or other entity) may set a Universal Serial Bus (USB) authentication policy that mandates that USB devices be signed prior to allowing the USB devices to connect to host systems within the organization. By signing devices, a high level of security and control is ensured for USB devices that are connected to the host systems. Any USB device not signed by the IT department would not be able to exchange information with host systems within the organization.
Implementing a USB authentication policy, however, may have some limitations. USB devices on the market supporting the authentication specification might be limited, and the IT department might not be able to find USB devices for certain tasks. It might be difficult for the IT department to sign multiple types of USB devices to support different tasks. Time sensitive USB device tasks might arise that do not allow time for the IT department to sign the USB device. In some cases, it may be desirable to connect legacy USB devices that do not support authentication to the organization's host systems. Further, instead of limiting the USB devices that may be used, a different intent for the organization's security might be to limit the people who have authority to use the USB ports of the host systems within the organization.
Accordingly, disclosed herein are dongles including an upstream facing USB Type-C port (e.g., male port), a downstream facing USB Type-C port (e.g., female port), and a security processor between the upstream facing USB Type-C port and the downstream facing USB Type-C port. The dongle may be used between a USB Type-C authentication-enabled host and a USB Type-C device that does not support authentication. The security processor responds to authentication initiation requests from the host to authenticate the dongle, such that the USB Type-C device may communicate and share data with the host. In this way, USB Type-C devices that do not support authentication may be used with USB Type-C authentication-enabled hosts.
By using the dongles disclosed herein, devices do not need to support the authentication protocol since the authentication responsibilities are performed by the security processor in the dongle. This enables any USB Type-C device to be used with the dongle. The devices are not constrained once the dongle is connected to the authentication host's port. An organization could implement tiers of USB access levels through dongle implementation. A first group of dongles could be distributed to a small group of individuals that have certificates that allow them to access a group of highly secure host systems. A larger second group of dongles with different certificates could be distributed to a larger group of individuals to access a group of less-secure host systems.
An IT department may sign the dongles and distribute them to select employees (e.g., to employees who are authorized and trusted to use the USB ports of the organization's host systems). The IT department may set an authentication policy for authorized dongles that are allowed to connect to a host port. Using this architecture, an individual uses a signed dongle plugged into the host system's USB Type-C port to connect a USB Type-C device to the host system's USB Type-C port. Individuals without a signed dongle cannot use the authentication-enabled USB Type-C ports. Therefore, instead of restricting USB usage to particular devices (as the USB Type-C Authentication Specification was intended to do), the dongles and methods disclosed herein restrict USB usage to particular users in possession of a signed dongle. Since the signed dongles do not rely on the USB devices to respond to authentication requests, non-authenticated and non-signed USB devices may be used in the system as long as the user of these devices has a signed dongle between the host and the device. This signed dongle is a type of “master key” that a user possesses to use a host system's authenticated USB Type-C ports.
The USB Type-C Authentication Specification defines a mechanism for a USB Type-C device to contain a chain of certificates to securely identify itself to a USB Type-C host. In one example, the authentication uses a chain of X.509 certificates encoded in ANS.1 format. The certificates are asymmetrically encrypted with elliptic curve mechanisms (e.g., ECC-ECDSA) to secure the delivery of the certificate chain through public/private key exchange with the host. In the mechanism specified, the USB Type-C authentication “master key” dongle will keep the private key and will transfer a public key (e.g., ECDSA key) to the host. For USB Type-C devices that support authentication, there is a set of information about the device that can be transmitted to the USB Type-C host through the X.509 certificate chain. This information is listed in table A-25 of the USB Type-C Authentication Specification. As such, the dongles disclosed herein may contain values for Version, XID, and Security Description.
Per the USB Type-C Authentication Specification, a host system cannot have two connected devices using the same private key. If an organization wishes to connect multiple dongles to a system simultaneously, each dongle should include a different private key. Each dongle may be configured by an IT department (or other entity) with desired information and/or private key(s). This enables the IT department to verify that the dongle belongs to their organization.
The upstream facing USB Type-C port 102 and the downstream facing USB Type-C port 104 may include pins for USB 2.0 differential pairs (i.e., D+ and D−), power and ground pins (i.e., VBUS and GND), pins for transmit and receive differential pairs (i.e., TX1+, TX1−, RX1+, RX1−, TX2+, TX2−, RX2+, RX2−), channel configuration pins (i.e., CC1 and CC2), power supply pin (i.e., VCONN), and alternate mode pins (i.e., SBU1 and SBU2), as specified by the USB Type-C standard.
Security processor 106 may include a MicroController Unit (MCU), a Programmable System On a Chip (PSOC), a Central Processing Unit (CPU), an embedded controller, or another suitable processor. Security processor 106 may be based on the ARM Cortex Cyptolsland or TrustZone architectures or another suitable security architecture. The security processor is to, with the upstream facing USB Type-C port 102 connected to a host and the downstream facing USB Type-C port 104 connected to a device, authenticate the dongle 100a in response to an authentication initiation request from the host. The authentication may be implemented based on the USB Type-C Authentication Specification.
In this example, the upstream facing USB Type-C port 102 includes an upstream facing male USB Type-C port and the downstream facing USB Type-C port 104 includes a downstream facing female USB Type-C port. Memory 120 stores machine readable instructions executable by the security processor 106, a private key(s), and a secure certificate(s) used to authenticate dongle 100b. Memory 120 may be integral to security processor 106 as illustrated in
In this example, the security processor 106 is to receive authentication commands and non-authentication commands (from a host) through the upstream facing CC lines 122. The security processor 106 responds to the authentication commands through the upstream facing CC lines 122 and passes the non-authentication commands to the downstream facing CC lines 124 (to a USB device). The security processor 106 passes responses to the non-authentication commands (from the USB device) on the downstream facing CC lines 124 to the upstream facing CC lines 122 (to the host). The VCONN line 126 may be used to power (via the host) the security processor 106 with the upstream facing USB Type-C port 102 connected to the host. VBUS, TX/RX, USB2, and SBU signals pass directly between the upstream facing USB Type-C port 102 and the downstream facing USB Type-C port 104 through VBUS, TX/RX, USB2, and SBU lines 128.
In more detail, in one example, the authentication of dongle 100b may proceed as follows. The dongle 100b is attached to a USB device through the downstream facing USB Type-C port 104 and to a host through the upstream facing USB Type-C port 102. The host acts as an authentication initiator and sends a query over the CC lines 122 to acquire a public key and a chain of X.509 certificates from the security processor 106. The security processor 106 receives the authentication initiation requests and provides the certificates including values for Version, XID, and Security Description. In addition, the security processor 106 may provide custom information injected by an IT department (or other entity) to allow the security processor 106 to validate itself as a master key that should be allowed to access the host. The security processor 106 performs the tasks of an “authentication responder” as defined in the USB Type-C Authentication Specification. Once the authentication is complete and valid certificates have been provided to the host by the security processor 106, the USB device is allowed to connect to the host for information sharing.
After authentication, the host may perform standard power delivery (PD) commands to gather information and configure the USB device. When the dongle 100b receives a PD request through CC lines 122 that is not an authentication packet, the security processor 106 forwards that PD request to the USB device through CC lines 124. The USB device then responds to the command through the CC lines 124. In this case, the security processor 106 forwards the response back to the host through the CC lines 122. That is, if an authentication request comes from the host through the CC lines 122, the security processor 106 responds directly to that request. If a standard PD command comes from the host through the CC lines 122, the security processor 106 forwards that command to the USB device attached to the dongle 100b through CC lines 124 and forwards the response from the USB device back to the host.
Once the security processor 106 has responded to the authentication commands from the host and the USB device has responded to the standard PD commands from the host (forwarded through the dongle), the USB device attached to the dongle is allowed to have a USB connection to the host. USB signals carrying information pass directly through the dongle 100b bypassing security processor 106. If the longest-allowed cables are to be used with the dongle 100b, the dongle may implement a signal conditioner as described below with reference to
Power supply 134 may be used to power the security processor 106, memory 120, and signal conditioner 132. Power supply 134 may include an AC or DC input to receive input power and/or a battery(s) to provide input power. Power supply 134 includes circuitry suitable to provide a regulated supply voltage (e.g., Vdd) to power security processor 106, memory 120, and signal conditioner 132. In this example, power supply 134 may be used in place of the VCONN input.
Security processor 106 is communicatively coupled to the upstream facing USB Type-C port 102 through upstream facing CC lines 122 and communicatively coupled to the downstream facing USB Type-C port 104 through downstream facing CC lines 124. Signal conditioner 132 is electrically coupled to the upstream facing USB Type-C port 102 through upstream facing TX/RX, USB2, and SBU lines 136 and electrically coupled to the downstream facing USB Type-C port 104 through downstream facing TX/RX, USB2, and SBU lines 138. Signal conditioner 132 conditions (e.g., retimes, amplifies, filters noise, etc.) TX/RX, USB2, and SBU signals passing between the upstream facing USB Type-C port 102 and the downstream facing USB Type-C port 104. The upstream facing USB Type-C port 102 is electrically coupled to the downstream facing USB Type-C port 104 directly through VBUS lines 140. Thus, the VBUS lines 140 bypass both the security processor 106 and the signal conditioner 132.
Security processor 106 is to, with the upstream facing USB Type-C port 102 connected to the USB Type-C authentication-enabled host 202 and the downstream facing USB Type-C port 104 connected to the USB Type-C device 208 that does not support authentication, authenticate the dongle 100a to enable USB communications between the host 202 and the device 208. In one example, the security processor 106 is to authenticate a user prior to authenticating the dongle 100a. For example, the security processor 106 may request a password entry or biometric verification from a user prior to authenticating the dongle 100a. This user authentication would ensure that the dongle 100a is authenticated by a specific user before use. By having a user input a password or biometric prior to using the dongle, if the dongle is lost or falls into the wrong hands, the dongle cannot be used by another individual. The security processor 106 may process the user authentication data and determine whether the dongle should be allowed to perform the USB Type-C authentication process.
As illustrated in
As illustrated in
Although specific examples have been illustrated and described herein, a variety of alternate and/or equivalent implementations may be substituted for the specific examples shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the specific examples discussed herein. Therefore, it is intended that this disclosure be limited only by the claims and the equivalents thereof.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2020/043268 | 7/23/2020 | WO |
