Software dongle for USB type-c certification

Abstract

A dongle includes an upstream-facing Universal Serial Bus (USB) Type-C port and a downstream-facing USB Type-C port. The dongle also includes a secure processor communicatively coupled between the upstream-facing USB Type-C port and the downstream-facing USB Type-C port. The secure processor authenticates the dongle in response to an authentication initiation request from a host in a case where the upstream-facing USB Type-C port is connected to the host and the downstream-facing USB Type-C port is connected to a device.

Description

BACKGROUND

[0001] Universal Serial Bus (USB) Type-C authentication specification can be used to restrict the types of devices that can be connected to a host system through a USB Type-C port of the host system. The basic premise of this specification is that a device sends verifiable information about itself in the form of a chain of security certificates. 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 a host system is referred to as an authentication policy. BRIEF DESCRIPTION OF DRAWINGS

[0002] Figures 1A-1C is a block diagram illustrating various examples of dongles.

[0003] Figure 2 is a block diagram illustrating one example of a system.

[0004] Figures 3A-3D is a flowchart illustrating one example of a method of authenticating a Universal Serial Bus (USB) Type-C device to a USB Type-C authentication-enabled host. DETAILED DESCRIPTION

[0005] In the following detailed description, reference is made to the accompanying drawings, which form a part hereof, and in which are shown by way of illustration specific examples in which the disclosure can be practiced. It is to be understood that other examples can be utilized and structural or logical changes can 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 should be understood that features of the various examples described herein can be combined, in part or whole, with each other, unless specifically noted otherwise.

[0006] An information technology (IT) department of an organization (or other entity) can set a Universal Serial Bus (USB) authentication policy that commands that a USB device be signed before it is allowed to connect to a host system within the organization. By signing a device, a high level of security and control of USB devices that connect to a host system is ensured. Any USB device that is not signed by the IT department will not be able to exchange information with a host system within the organization.

[0007] However, implementing a USB authentication policy can have some limitations. There can be a limited number of USB devices on the market that support the authentication specification, and the IT department can not be able to find a USB device for certain tasks. The IT department can have difficulty signing multiple types of USB devices to support different tasks. Time sensitive USB device tasks can arise that do not allow the IT department time to sign the USB device. In some cases, it can be desirable to connect legacy USB devices that do not support authentication to the organization’s host systems. Additionally, instead of limiting the USB devices that can be used, different intentions for the security of the organization can limit the people that have access to use the USB ports of the host systems within the organization.

[0008] Accordingly, disclosed herein is a dongle that includes an upstream facing USB Type-C port (e.g., male port), a downstream facing USB Type-C port (e.g., female port), and a secure processor between the upstream facing USB Type-C port and the downstream facing USB Type-C port. The dongle can be used between a USB Type-C authentication enabled host and a USB Type-C device that does not support authentication. The secure processor responds to an authentication initiation request from the host to authenticate the dongle so that the USB Type-C device can communicate with and share data with the host. In this way, USB Type-C devices that do not support authentication can be used with USB Type-C authentication enabled hosts.

[0009] By using the dongle disclosed herein, devices do not need to support the authentication protocol because the authentication responsibility is performed by the secure processor in the dongle. This enables any USB Type-C device to be used with the dongle. Once the dongle is connected to a port of an authentication host, the device is no longer constrained. An organization can implement tiers of USB access levels through the dongle implementation. A first group of dongles can be distributed to a small group of individuals that have credentials that allow them access to a group of highly secure host systems. A larger second group of dongles with different credentials can be distributed to a larger group of individuals to access a group of less secure host systems.

[0010] The IT department can sign the dongles and distribute them to selected employees (e.g., to employees authorized and trusted to use the organization's host system's USB ports). The IT department can set authentication policies for authorized dongles allowed to connect to the host ports. Using this architecture, an individual uses a signed dongle plugged into a USB Type-C port of a host system to connect a USB Type-C device to the host system's USB Type-C port. An individual without a signed dongle cannot use the authentication-enabled USB Type-C port. Thus, instead of restricting USB use to a particular device (as the USB Type-C authentication specification intends), the dongles and methods disclosed herein restrict USB use to a particular user in possession of a signed dongle. Since the signed dongle does not rely on a USB device to respond to authentication requests, non-authentication and non-signed USB devices can 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 the type of "master key" that the user possesses to use the authenticated USB Type-C ports of the host system.

[0011] The USB Type-C authentication specification defines a mechanism for USB Type-C devices to include a chain of certificates to securely identify themselves to a USB Type-C host. In one example, authentication uses a chain of X.509 certificates encoded in ANS.1 format. The certificates are asymmetrically encrypted with an elliptic curve mechanism (e.g., ECC-ECDSA) to protect the delivery of the certificate chain through a public / private key exchange with the host. In the specified mechanism, the USB Type-C authentication "master key" dongle will keep the private key and pass the public key (e.g., ECDSA key) to the host. For a USB Type-C device that supports authentication, there is a set of information about the device that can be transmitted to a 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 can include the values for version, XID, and security description.

[0012] According to the USB Type-C authentication specification, a host system cannot have two connected devices that use the same private key. If an organization wants to connect multiple dongles to the system at the same time, each dongle should include a different private key. Each dongle can be configured by the IT department (or other entity) with the required information and / or private key(s). This enables the IT department to verify that the dongle belongs to their organization.

[0013] Figure 1Ais a block diagram illustrating one example of a dongle 100a. The dongle 100a includes an upstream-facing USB Type-C port 102, a downstream-facing USB Type-C port 104, and a secure processor 106. The secure processor 106 is communicatively coupled between the upstream-facing USB Type-C port 102 and the downstream-facing USB Type-C port 104. The secure processor 106 is communicatively coupled to the upstream-facing USB Type-C port 102 by a communication link 108 and to the downstream-facing USB Type-C port 104 by a communication link 110.

[0014] As specified by the USB Type-C standard, the upstream-facing USB Type-C port 102 and the downstream-facing USB Type-C port 104 can include pins for USB 2.0 differential pairs (i.e., D+ and D-), power and ground pins (i.e., VBUS and GND), pins for transmitting and receiving differential pairs (i.e., TX1+, TX1-, RX1+, RX1-, TX2+, TX2-, RX2+, RX2-), channel configuration pins (i.e., CC1 and CC2), power supply pins (i.e., VCONN), and alternate mode pins (i.e., SBU1 and SBU2).

[0015] The secure processor 106 can include a microcontroller unit (MCU), a programmable system on a chip (PSOC), a central processing unit (CPU), an embedded controller, or other suitable processor. The secure processor 106 can be based on an ARM Cortex CyptoIsland or TrustZone architecture or another suitable security architecture. The secure processor will authenticate the dongle 100a in response to an authentication initiation request from a host in a case where the upstream-facing USB Type-C port 102 is connected to the host and the downstream-facing USB Type-C port 104 is connected to a device. The authentication can be implemented based on the USB Type-C authentication specification.

[0016] Figure 1B is a block diagram illustrating another example of a dongle 100b. The dongle 100b includes an upstream-facing USB Type-C port 102, a downstream-facing USB Type-C port 104, and a secure processor 106 as previously referenced with respect to the dongle 100a. The dongle 100b also includes a secure memory 112 and a secure storage 114. The secure memory 112 and the secure storage 114 are communicatively coupled to the secure processor 106. Figure 1AAn upstream-facing USB Type-C port 102, a downstream-facing USB Type-C port 104, and a secure processor 106 are described and shown. In this example, the secure processor 106 includes a memory 120. The secure processor 106 is communicatively coupled to the upstream-facing USB Type-C port 102 by an upstream-facing CC line 122 and to the downstream-facing USB Type-C port 104 by a downstream-facing CC line 124. A VCONN input of the secure processor 106 is electrically coupled to the upstream-facing USB Type-C port 102 by a VCONN line 126. The upstream-facing USB Type-C port 102 is directly electrically coupled to the downstream-facing USB Type-C port 104 by VBUS, TX / RX, USB2, and SBU lines 128. Thus, the lines 128 bypass the secure processor 106.

[0017] 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. The memory 120 stores machine-readable instructions executable by the secure processor 106, private key(s), and security certificate(s) for authenticating the dongle 100b. The memory 120 can be integrated into the secure processor 106 as shown in Figure 1B or coupled communicatively to the secure processor 106 as will be described below with reference to Figure 1C The memory 120 can be a read-only memory (ROM), such as a serial peripheral interface (SPI) ROM, an electrically erasable programmable read-only memory (EEPROM), a flash memory, or other suitable ROM.

[0018] In this example, the secure processor 106 receives authentication commands and non-authentication commands (from a host) over the upstream-facing CC line 122. The secure processor 106 responds to authentication commands over the upstream-facing CC line 122 and passes non-authentication commands to the downstream-facing CC line 124 (to a USB device). The secure processor 106 communicates responses to non-authentication commands (from a USB device) over the downstream-facing CC line 124 to the upstream-facing CC line 122 (to the host). The VCONN line 126 can be used to power the secure processor 106 with the upstream-facing USB Type-C port 102 connected to the host (via the host). The VBUS, TX / RX, USB2, and SBU signals are passed directly between the upstream-facing USB Type-C port 102 and the downstream-facing USB Type-C port 104 by the VBUS, TX / RX, USB2, and SBU lines 128.

[0019] More specifically, in one example, authentication of the dongle 100b can be performed as follows: The dongle 100b is attached to a USB device via a downstream-facing USB Type-C port 104 and to a host via an upstream-facing USB Type-C port 102. The host acts as the authentication initiator and sends a query via CC line 122 to obtain a chain of public keys and X.509 certificates from the security processor 106. The security processor 106 receives the authentication initiation request and provides a certificate including values ​​for version, XID, and security description. Furthermore, the security processor 106 can provide custom information injected by the IT department (or other entity) to allow it to verify itself as the master key that should be allowed access to the host. The security processor 106 performs the tasks of an "authentication responder" as defined in the USB Type-C authentication specification. Once authentication is complete and the security processor 106 has provided a valid certificate to the host, the USB device is allowed to connect to the host for information sharing.

[0020] After authentication, the host can execute standard power delivery (PD) commands to collect information and configure the USB device. When the dongle 100b receives a PD request that is not an authentication packet via CC line 122, the security processor 106 forwards the PD request to the USB device via CC line 124. The USB device then responds to the command via CC line 124. In this case, the security processor 106 forwards the response back to the host via CC line 122. That is, if the authentication request comes from the host via CC line 122, the security processor 106 responds to the request directly. If the standard PD command comes from the host via CC line 122, the security processor 106 forwards the command to the USB device attached to the dongle 100b via CC line 124 and forwards the response from the USB device back to the host.

[0021] Once the security processor 106 has responded to the authentication command from the host and the USB device has responded to the standard PD command from the host (forwarded via the dongle), the USB device attached to the dongle is allowed to have a USB connection to the host. The USB signal carrying the information passes directly through the dongle 100b, bypassing the security processor 106. If the longest allowed cable is used with the dongle 100b, the dongle can achieve the following (see reference below). Figure 1C The aforementioned signal conditioner compensates for any signal degradation caused by the dongle.

[0022] Figure 1C This is a block diagram illustrating another example of the software dongle 100c. The software dongle 100c includes, as previously referenced... Figure 1BThe description and illustration include an upstream-facing male USB Type-C port 102, a downstream-facing female USB Type-C port 104, and a security processor 106. In this example, the dongle 100c includes a memory 120 communicatively coupled to the security processor 106 via a communication link 142. The dongle 100c also includes a power supply 134 and a signal conditioner 132.

[0023] Power supply 134 can be used to power security processor 106, memory 120, and signal conditioner 132. Power supply 134 may include AC or DC inputs to receive input power and / or (one or more) batteries to provide input power. Power supply 134 includes circuitry adapted 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 can be used instead of the VCONN input.

[0024] Security processor 106 is communicatively coupled to upstream USB Type-C port 102 via upstream CC line 122 and to downstream USB Type-C port 104 via downstream CC line 124. Signal conditioner 132 is electrically coupled to upstream USB Type-C port 102 via upstream TX / RX, USB2, and SBU lines 136 and to downstream USB Type-C port 104 via downstream TX / RX, USB2, and SBU lines 138. Signal conditioner 132 regulates (e.g., retiming, amplifying, filtering noise, etc.) the TX / RX, USB2, and SBU signals transmitted between upstream USB Type-C port 102 and downstream USB Type-C port 104. Upstream USB Type-C port 102 is directly electrically coupled to downstream USB Type-C port 104 via VBUS line 140. Therefore, VBUS line 140 bypasses both security processor 106 and signal conditioner 132.

[0025] Figure 2 This is a block diagram illustrating an example of system 200. System 200 includes, as previously referenced... Figure 1A The software dongle 100a, the USB Type-C authentication enabled host 202, and the USB Type-C device 208 without authentication support are described and illustrated. In other examples, the previously referenced documents may also be used. Figure 1B and 1CThe software dongle 100b or 100c described and shown replaces the software dongle 100a. The USB Type-C authentication enabled host 202 includes a USB Type-C port 204. The USB Type-C device 208 includes a USB Type-C port 210. The upstream-facing USB Type-C port 102 of the software dongle 100a is communicatively coupled to the USB Type-C port 204 of the USB Type-C authentication enabled host 202 via a communication link 206 (e.g., a USB Type-C cable). The downstream-facing USB Type-C port 104 of the software dongle 100a is communicatively coupled to the USB Type-C port 210 of the USB Type-C device 208 via a communication link 212 (e.g., a USB Type-C cable).

[0026] Security processor 106 authenticates dongle 100a to enable USB communication between host 202 and device 208 when the upstream-facing USB Type-C port 102 is connected to a USB Type-C authentication-enabled host 202 and the downstream-facing USB Type-C port 104 is connected to a USB Type-C device 208 that does not support authentication. In one example, security processor 106 authenticates the user before authenticating dongle 100a. For example, security processor 106 may request password input or biometric verification from the user before authenticating dongle 100a. This user authentication ensures that dongle 100a is authenticated by a specific user before use. By requiring the user to enter a password or biometric verification before using the dongle, the dongle cannot be used by another individual if it is lost or falls into the wrong hands. Security processor 106 can process user authentication data and determine whether the dongle should be allowed to perform the USB Type-C authentication process.

[0027] Figures 3A-3D This shows a host that enables USB Type-C authentication (e.g., Figure 2 202) certified USB Type-C devices (e.g., Figure 2 A flowchart of an example of method 300 (208). Figure 3AAs shown at 302, method 300 includes connecting an upstream-facing USB Type-C port (e.g., 102) of a dongle (e.g., 100a, 100b, or 100c) to a host. At 304, method 300 includes connecting a downstream-facing USB Type-C port (e.g., 104) of the dongle to a USB Type-C device. At 306, method 300 includes receiving an authentication initiation request from the host via a security processor (e.g., 106) of the dongle communicatively coupled between the upstream-facing and downstream-facing USB Type-C ports. At 308, method 300 includes authenticating the dongle via the security processor to enable USB communication between the host and the USB Type-C device. In one example, authenticating the dongle includes transmitting a chain of public keys and certificates to the host via the security processor in response to the authentication initiation request.

[0028] like Figure 3B As shown at 310, method 300 may further include transmitting USB and SBU signals between the host and the USB Type-C device when the dongle is authenticated. Figure 3C As shown at 312 in the diagram, method 300 may further include a signal conditioner via a dongle (e.g., Figure 1C (132) is used to regulate the USB signals transmitted between the host and the USB Type-C device.

[0029] like Figure 3D As shown at 314, method 300 may further include receiving a power delivery (PD) command from the host via a secure processor (e.g., via CC line 122). At 316, method 300 may further include transmitting the PD command from the host to the USB Type-C device via a secure processor (e.g., via CC line 124). At 318, method 300 includes transmitting a response to the PD command from the USB Type-C device to the host via a secure processor.

[0030] Although specific examples have been illustrated and described herein, various alternatives and / or equivalent implementations may be made in place of the specific examples shown and described without departing from the scope of this disclosure. This application is intended to cover any modifications or variations of the specific examples discussed herein. Therefore, this disclosure is intended to be limited only by the claims and their equivalents.

Claims

1. A software dongle, comprising: Upstream-facing Universal Serial Bus (USB) Type-C port; Downstream-facing USB Type-C port; as well as A security processor communicatively coupled between an upstream-facing USB Type-C port and a downstream-facing USB Type-C port, the security processor authenticating the dongle in response to an authentication initiation request from the host when the upstream-facing USB Type-C port is connected to the host and the downstream-facing USB Type-C port is connected to the device, enabling the device to communicate with the host and share data via a dongle signed by an entity that sets authentication policies for the authorized dongle, wherein the device does not support authentication and is not signed by said entity.

2. The software dongle according to claim 1, wherein, The security processor is communicatively coupled to the upstream-facing USB Type-C port via the upstream-facing CC line and also communicatively coupled to the downstream-facing USB Type-C port via the downstream-facing CC line.

3. The software dongle according to claim 2, wherein, The security processor receives authentication commands and non-authentication commands through the upstream-facing CC line, responds to authentication commands through the upstream-facing CC line, passes non-authentication commands to the downstream-facing CC line, and passes responses to non-authentication commands on the downstream-facing CC line to the upstream-facing CC line.

4. The software dongle according to claim 1, further comprising: The VBUS cable connects directly between the upstream-facing USB Type-C port and the downstream-facing USB Type-C port. The transmit (TX) and receive (RX) lines are directly connected between the upstream-facing USB Type-C port and the downstream-facing USB Type-C port; The USB2 cable connects directly between the upstream-facing USB Type-C port and the downstream-facing USB Type-C port; and The SBU cable connects directly between the upstream-facing USB Type-C port and the downstream-facing USB Type-C port.

5. The software dongle according to claim 1, wherein, Upstream-facing USB Type-C ports include upstream-facing male USB Type-C ports, and downstream-facing USB Type-C ports include downstream-facing female USB Type-C ports.

6. A software dongle, comprising: Upstream-facing Universal Serial Bus (USB) Type-C port; Downstream-facing USB Type-C port; as well as A security processor is communicatively coupled between an upstream-facing USB Type-C port and a downstream-facing USB Type-C port. When the upstream-facing USB Type-C port is connected to a USB Type-C authentication-enabled host and the downstream-facing USB Type-C port is connected to a USB Type-C device that does not support authentication and is not signed by an entity that has set an authentication policy for the authorized dongle, the security processor enables USB communication between the host and the device, allowing the USB Type-C device to communicate with and share data with the USB Type-C authentication-enabled host via the dongle signed by the entity.

7. The software dongle according to claim 6, wherein, The security processor authenticates the user before authenticating the dongle.

8. The software dongle according to claim 6, wherein, The security processor includes a VCONN input electrically coupled to an upstream-facing USB Type-C port to supply power to the security processor when the upstream-facing USB Type-C port is connected to a host.

9. The software dongle according to claim 6, further comprising: Power supply, providing power to the security processor.

10. The software dongle according to claim 6, further comprising: The memory is communicatively coupled to the security processor to store private keys, certificates, and machine-readable instructions for authenticating the dongle.

11. A method for authenticating a USB Type-C device to a Universal Serial Bus (USB) Type-C authentication enabled host, the method comprising: Connect the upstream-facing USB Type-C port of the dongle to the host; Connect the downstream-facing USB Type-C port of the dongle to a USB Type-C device; The security processor of the dongle, communicatively coupled between the upstream-facing USB Type-C port and the downstream-facing USB Type-C port, receives authentication initiation requests from the host. as well as The security processor authenticates the dongle to enable USB communication between the host and the USB Type-C device, so that the USB Type-C device communicates and shares data with the USB Type-C authentication enable host via the dongle signed by an entity that sets the authentication policy for the authorized dongle, wherein the USB Type-C device does not support authentication and is not signed by the entity.

12. The method of claim 11, further comprising: When the dongle is certified, it transmits USB and SBU signals between the host and the USB Type-C device.

13. The method of claim 12, further comprising: The signal conditioner of the dongle regulates the USB signal transmitted between the host and the USB Type-C device.

14. The method according to claim 11, wherein, An authentication dongle includes a chain that transmits a public key and a certificate to the host via a security processor in response to an authentication initiation request.

15. The method of claim 11, further comprising: Receive power delivery (PD) commands from the host via a secure processor; The PD command is transmitted from the host to the USB Type-C device via a security processor; as well as The response to PD commands is transmitted from the USB Type-C device to the host via the security processor.

Images