Patent Application
20200329040
Embodiments relate to authenticating devices remotely.
Universal Serial Bus (USB) has evolved from being an interface to connect low power peripherals into a more sophisticated system that adds capabilities of up to 100 Watts in power delivery and super speed data transfer up to 40 gigabits per second (Gbps). The USB Implementers Forum (USB-IF) maintains specifications for cables, connectors, protocols, communication and power delivery (PD).
The USB4 specification version 1.0 (published Aug. 29, 2019) implements a converged input/output protocol over a USB Type-C port providing multiple functionalities like USB, DisplayPort and Peripheral Component Interconnect (PCI), thus enabling newer devices connected through USB ports in future compute ecosystems. This includes devices for use in a corporate environment that implement secure access or access with policy enforcement.
The USB Type-C (USB-C) Authentication Specification revision 1.0 (published Jan. 7, 2019) extends the functionality of USB-C systems to authenticate devices over a USB-C port. However, such authentication is limited to peer-to-peer use cases, where a USB device is physically coupled to an authenticating system.
In various embodiments, an authentication protocol is provided to enable cloud-based authentication of peripheral devices coupled to remote client systems. While many different architectures are possible, embodiments may be applicable to cloud-based environments in which a cloud server acts as an authentication initiator when a peripheral device is connected into a given client system, e.g., via a USB/USB-C connection.
Many different types of client systems may implement embodiments, including cloud-managed workplace devices such as a cloud-managed Chromebook™ arrangement. Other embodiments may be used in connection with a cloud point-of-sale system. Of course embodiments are not limited to these examples and apply equally to many different types of client systems that may be present in a given enterprise or other secure environment.
With embodiments, many different types of peripheral and other devices that can dynamically connect into a system, such as so-called converged IO peripheral devices, when connected into a local computing system undergo an authentication procedure. When the local computing system itself is implemented within a cloud environment in which some enterprise or other IT management of the local computing system resides in the cloud, a cloud computing device such as a cloud server may act as an authentication initiator for the authentication of the peripheral device.
As such, in arrangements herein, the device may receive a request for authentication from the locally coupled system, based on an authentication initiation by a cloud-based server. In turn, rather than implementing a peer-to-peer authentication between a client computing device and the peripheral device, embodiments provide techniques and mechanisms to enable/extend a cloud-based authentication of local peripheral devices.
In one embodiment, an authentication sequence defined by a USB-C authentication protocol can be used to authenticate, e.g., USB PD products originating from different vendors. In this way, since USB is an open standard, embodiment may help protect a host platform from security vulnerabilities. Understand of course embodiments are not limited in this regard, and authentication communications between peer-connected devices may occur in accordance with other authentication protocols or a custom-defined authentication protocol.
Embodiments thus obtain authentication information from the peripheral device by way of peer-to-peer communication between the local client computing device and the peripheral device. Understand that such operation proceeds in response to receipt of an authentication request from the cloud-based server. In turn, once the client computing device successfully obtains the authentication information, it may communicate it to the cloud-based server, e.g., with some of its own authentication information. In one embodiment, the client computing device may append at least a portion of the device authentication information to at least some of its authentication information. In turn, this consolidated authentication information may be sent to the cloud-based server. In particular embodiment, this information may be encapsulated within one or more protocol packets and then sent to the cloud-based server.
Referring now to
As illustrated, method 100 begins by enrolling the client system (block 110). More specifically, this client system, which may be an enterprise device, e.g., located at a given workplace, business or so forth and that may be IT managed remotely via the cloud, may be enrolled as a trusted third party. To this end, this enrollment process may be implemented using a protocol to establish the client system as a trusted third party, to enable authentications to proceed as described herein for peripheral devices that may become locally connected to it.
Note that the enrollment process may occur when the client system is configured into an enterprise and may be part of an authentication of that device in the cloud environment. And understand that different types of operations to perform enrollment may occur, e.g., based on a type of operating system (OS) that is used. In some cases, an OS-based technique may be used to enroll the client system as trusted third party. In other cases, a hypervisor or a virtual machine that executes under the hypervisor may perform the enrollment. Understand that the term “trusted third party” as used herein is not to mean that the client system is a certificate authority or other third party entity capable of providing keys or other cryptographic material or trust assertions, but instead is an authorized enrollee to obtain authentication information from peripheral devices for shipping to the cloud-based server.
Still with reference to
Next at block 130, the cloud server issues an authentication request to the client system. This request may be in the form of a GET_DIGESTS request according to a USB Type-C authentication protocol (e.g., according to the USB-C Authentication Specification, revision 1.0, or any other version, modification or variation thereof), in an embodiment. Of course other authentication requests are possible.
Next it is determined at diamond 140 whether a response has been received before a timeout period occurs. If not, control passes back to block 130 where the authentication request again may be issued. Note that in some cases, this determination as to whether a response has been received is based on whether a response to the authentication request is received, or alternately whether a busy message has been received from the client system, to indicate that it is currently in the process of performing authentication protocol operations with the peripheral device.
Control next passes to block 150 where an authentication protocol may be performed with the client system to obtain authentication information of the peripheral device. In an embodiment, this information may be appended to or otherwise included with authentication information of the client system itself. In an embodiment, this authentication information may include digest information, certificate information and challenge response information. Of course additional or different information may be received in other embodiments.
Based at least in part on this information, the cloud server may determine at diamond 160 whether the peripheral device is authenticated. For example, if all of the digests, certificate and challenge response information indicate that the device is what it says is, e.g., by way of computed results matching expected results, the peripheral device may be authenticated. If so, control passes to block 180 where the cloud server may send an authorization success message to the client system. In response to this authorization success message, the client system may enable connection with the peripheral device, and can begin communicating with the peripheral device. Otherwise, the peripheral device is not authenticated, and control passes to block 170 where the cloud server may send an authorization failure message to the client system. In response to this authorization failure message, the client system may disconnect from the peripheral device. Understand while shown at this high level in the embodiment of
Referring now to
As illustrated, method 200 begins by receiving an authentication request in the client system from a cloud server (block 210). This authentication request may be a request to authenticate a peripheral device recently coupled to the client system that implements. In response to this authentication request which, in one embodiment may be in the form of a GET_DIGESTS request, the client system performs an authentication protocol with the peripheral device to obtain authentication information of the peripheral device (block 215). This authentication protocol may be a peer-to-peer authentication protocol.
Next at diamond 220 it may be determined whether the authentication protocol has completed successfully before a timeout period. In some embodiments, this timeout period may be set according to the protocol. If the authentication protocol is not completed in this time, control passes to diamond 225 to determine whether there was a failure. If so, at block 230 an error report is sent to the cloud server. If no failure occurs, the client may send a busy response to the cloud server at block 235, which may trigger the sending and receiving of another authentication request. Note that this busy signal sending may be optional in certain cases.
Still with reference to
Note that in different embodiments, different manners of parsing and providing authentication information of both the peripheral device and the client system may occur. For example, the client system may only provide a portion of the received device authentication information to the cloud server. Similarly, only a portion of the available authentication information of the client system may be sent to the cloud server. And understand that whatever the amount, different manners of packaging the information for communication to the cloud server may occur. While an encapsulation technique may be used in one embodiment, other manners of packing the information may occur in other embodiments.
Still with reference to
Other authentication results may include determining, as a result of the authentication, whether a connected device is appropriate per a policy. For example, a vendor, concerned about product damage resulting from substandard charging devices, can set a policy requiring that only certified PD products be used for charging. As another example, a user, concerned about charging his phone at a public terminal, can set a policy requiring that the phone only charge from certified PD products. As a still further example, an organization, concerned about unidentifiable storage devices gaining access to corporate PC assets, can set a policy requiring that only USB storage devices that have been verified and signed by corporate IT are used. Of course other use cases for authentications as described herein may occur such as USB-C/USB4 docks that extend the ports of the client device.
As described above, embodiments may be used in many different types of enterprise systems. Referring now to
In PoS system 300, these connected peripherals (e.g., converged IO devices) may be used for high secure transactions and thus appropriate authentication is proper. As described herein cloud server 310 may act as the authentication initiator, although it resides in the cloud, to authenticate these non-peer devices.
As shown in
As shown in
As shown in
Alternately, another ecosystem that is evolving is “Grab and Go with Chrome Enterprise,” a self-service shared Chromebook™ program. As one example in an enterprise system a shelf stacked with Chromebooks™ can be used by employees to pick up a device and get to work in minutes. When the user is done, the device is put back for the next user, no reconfiguration necessary. Embodiments may be used to connect and authenticate peripherals in such an environment.
Referring now to
As further shown in
With embodiments, all of these peripheral devices may be authenticated in environment 400. More particularly, cloud server 410 may be an initiator of such authentications via communication of authentication requests to client system 420 that in turn may perform a peer-to-peer authentication protocol to obtain authentication information of the peripheral device. In turn, client system 420 may include at least some of this information and at least some of its own authentication information and communicate it, e.g., via protocol packets to cloud server 410 to enable cloud server 410 to determine whether a given peripheral device is authenticated to thus enable normal operation. While shown at this high level in the embodiment of
Referring now to
As shown in
As further shown in
Still with reference to
While client device 520 receives the above-described authentication information from leaf device 530, it does not verify the contents itself. Instead, as further shown in
Thus after obtaining all the authentication information from leaf device 530, it is sent to cloud server 510. More specifically, client device 520 has the required certificate chain from leaf device 530. Thus in response to GET_DIGESTS request 550, it sends a DIGESTS_response 552 with digests from leaf device 530 appended to its digests. Similarly, in response to GET_CERTIFICATES request 554, it appends the certificate chain of leaf device 530 to its leaf certificate, related ACD object and TLVs applicable to leaf device 530. Client system 520 may append the leaf device's certificate encoded in X509v3 ASN.1 format to its leaf certificate and ACD object. The ACD object may contain a VENDOR_EXTENSION TLV to denote that the authentication response contains appended information of the leaf device, followed by TLVs applicable for the leaf device.
In an embodiment, the certificates may be encapsulated in protocol packets in x509v3 ASN.1 format and sent via the cloud server APIs defined by a cloud service provider. As further shown in
Cloud server 510 may use the appended certificate information to send ‘CHALLENGE’ request 558, and validate ‘CHALLENGE_AUTH’ response 560 of leaf device 530 as sent through client device 520.
Cloud server 510, in an embodiment, may implement a USB PD authentication protocol state machine and libraries for computation of secure information. Once the application/daemon running on cloud server 510 receives notification of connection of leaf device 530, it starts the state machine. Handshake between cloud server 510 and client device 520 may be based on a pre-defined format. In this way, cloud server 510 extracts the appended information of leaf device 530 to validate/authenticate it. While not shown in
Note that if leaf device 530 is a USB PD capable product, it can use USB PD messages to send the authentication protocol sequence. In this case, authentication request messages are sent as security_request USB PD messages and authentication response messages are send as security_response USB PD messages. In other cases, leaf device 530 may send authentication messages through USB control transfer messages for non-USB PD capable device to use the same authentication methodology.
With respect to the above discussion, a certificate is a digital form of identification that provides information about an entity and certifies ownership of a particular public key. Note that a certificate chain is a series of two or more certificates where each certificate is signed by the preceding certificate in the chain. In turn, a certificate chain topology may include a root certificate that is self signed and USB-IF issued and acts as a first certificate in a chain. In turn, an intermediary certificate may be root signed and USB-IF issued. In turn, a leaf certificate may be issued by a product owner and may include allowed extensions.
In an embodiment, certificates may use the X509v3 ASN.1 structure. Certificates may use binary DER encoding for ASN.1. Certificates may use the cryptographic methods and the certificate format assumes that the reader is familiar with X509v3 certificate terminology. In some cases, leaf certificates are not allowed to exceed a MaxLeafCertSize in length. Intermediate Certificates similarly may not be allowed to exceed a MaxlntermediateCertSize in length.
In embodiments, the certificates are provided various Attributes and Extensions with object identifiers (OID) wherever applicable. The certificate also may contain a custom certificate extension, namely USB-IF additional certificate data (ACD) (OID 2.23.145.1.2)”. The USB-IF ACD is a custom certificate extension for use with compliant products. Note that leaf certificates may contain this extension and non-leaf certificates may use this extension. The ACD formatting may include a sequence of zero or more Type, Length, Value (TLV) fields that start at the first byte of a binary object. Table 1 below depicts the various types of TLV objects available in the leaf certificate as part of extension.
With the arrangement above in
While
With embodiments, a secure session for a high compute system occurs to authenticate non-peer devices. Thus with embodiments, non-peer devices may be authenticated by using an intermediary device as a trusted third party.
Turning next to
Interconnect 612 provides communication channels to the other components, such as a Subscriber Identity Module (SIM) 630 to interface with a SIM card, a boot ROM 635 to hold boot code for execution by cores 606 and 607 to initialize and boot SoC 605, a SDRAM controller 640 to interface with external memory (e.g., DRAM 660), a flash controller 645 to interface with non-volatile memory (e.g., flash 665), a peripheral controller 650 (e.g., an eSPI interface) to interface with peripherals, video codec 620 and video interface 625 to display and receive input (e.g., touch enabled input), GPU 615 to perform graphics related computations, etc. In addition, the system illustrates peripherals for communication, such as a Bluetooth module 670, 3G modem 675, GPS 680, and WiFi 685. Further illustrated in
As further shown, SoC 605 may include a USB interface circuit 632, which may be configured to perform USB authentication protocols with connected USB devices (such as USB device 655) in response to an authentication request received from a cloud-based server, as described herein. To this end, USB interface circuit 632 may include hardware, software and/or firmware to perform a peer-to-peer authentication process to obtain authentication information from USB device 655 and send at least portions of it to the cloud-based server to enable remote authentication.
Referring now to
Still referring to
Furthermore, chipset 790 includes an interface 792 to couple chipset 790 with a high performance graphics engine 738, by a P-P interconnect 739. As shown in
The following examples pertain to further embodiments.
In one example, a method comprises: receiving, in a client system, an authentication request from a cloud server remotely coupled to the client system, the authentication request for authentication of a device coupled to the client system; in response to the authentication request, performing an authentication protocol with the device via the client system, including obtaining device authentication information of the device; placing at least a portion of the device authentication information and authentication information of the client system in a protocol packet, and sending the protocol packet to the cloud server; and in response to a challenge request from the cloud server, sending to the cloud server a challenge response signed with a first certificate of the client system and a second certificate of the device, to cause the cloud server to authenticate the device.
In an example, the method further comprises establishing a secure session between the client system and the device in response to the authentication of the device by the cloud server.
In an example, the method further comprises placing the authentication information and the at least portion of the device authentication information in the protocol packet according to an application programming interface defined by the cloud server.
In an example, obtaining the device authentication information of the device comprises obtaining at least one digest and a certificate chain, the certificate chain comprising additional certificate data.
In an example, the method further comprises obtaining the at least one digest and the certificate chain from the device using Universal Serial Bus power delivery security messages.
In an example, the method further comprises receiving the authentication request in response to coupling the device to the client system via a Universal Serial Bus connector.
In an example, the method further comprises performing the authentication protocol according to a Universal Serial Bus-Type C peer-to-peer authentication protocol, in response to the authentication request from the cloud server.
In an example, the method further comprises communicating with the cloud server to enroll the client system as a trusted third-party, to enable the client system to perform the authentication protocol with the device.
In an example, the method further comprises appending the at least portion of the device authentication information to the authentication information and encapsulating the appended portion of the device authentication information and the authentication information in the protocol packet.
In another example, a computer readable medium including instructions is to perform the method of any of the above examples.
In a further example, a computer readable medium including data is to be used by at least one machine to fabricate at least one integrated circuit to perform the method of any one of the above examples.
In a still further example, an apparatus comprises means for performing the method of any one of the above examples.
In another example, a system includes a cloud server. The cloud server may include: at least one processor to execute instructions; and a non-transitory storage medium coupled to the at least one processor comprising instructions that when executed cause the at least one processor to: determine that a device has been connected to a system remotely coupled to the cloud server; in response to the determination of device connection, send, as authentication initiator, an authentication request to the client system to obtain device authentication of the device; in response to the authentication request, receive via the system one or more protocol packets comprising the device authentication information; and remotely authenticate the device in the cloud server using the device authentication information.
In an example, the non-transitory storage medium further comprises instructions that cause the at least one processor to: receive digest information of the device appended to digest information of the system; and thereafter request certificate information from the system.
In an example, the non-transitory storage medium further comprises instructions that cause the at least one processor to: in response to the request for the certificate information, receive the certificate information comprising device certificate information of the device and system certificate information of the system; and thereafter issue a challenge request to the system.
In an example, the non-transitory storage medium further comprises instructions that cause the at least one processor to in response to the challenge request, receive a challenge response from the system, the challenge response signed using the device certificate information and the system certificate information.
In an example, the non-transitory storage medium further comprises instructions that cause the at least one processor to further send application programming information to the system to enable the system to format the one or more protocol packets comprising the device authentication information.
In an example, the non-transitory storage medium further comprises instructions that cause the at least one processor to enroll the system as a trusted third party to enable the system to perform a Universal Serial Bus authentication protocol to obtain the device authentication information of the device.
In yet another example, an apparatus includes: at least one processor; and a USB interface coupled to the at least one processor to connect the apparatus to one or more USB devices. In response to connection of a first USB device to the apparatus, the apparatus is to inform a cloud server of the connection, the cloud server remote from the apparatus, where in response to an authentication request from the cloud server, the apparatus is to obtain device authentication information from the first USB device via a USB peer-to-peer authentication protocol and send at least a portion of the device authentication information to the cloud server, to enable the cloud server to remotely authenticate the first USB device.
In an example, the apparatus is to generate a protocol packet comprising the at least portion of the device authentication information and authentication information of the apparatus and send the protocol packet to the cloud server.
In an example, the apparatus, in response to a challenge request from the cloud server, is to send to the cloud server a challenge response signed with a first certificate of the apparatus and a second certificate of the first USB device, to enable the cloud server to authenticate the first USB device.
In an example, the apparatus comprises a battery, where in response to the authentication of the first USB device, the apparatus is to enable the first USB device to charge the battery, the first USB comprising a USB power delivery device.
In an example, the apparatus is to obtain the at least one digest and the certificate chain from the first USB device using USB power delivery security messages.
Understand that various combinations of the above examples are possible.
Note that the terms “circuit” and “circuitry” are used interchangeably herein. As used herein, these terms and the term “logic” are used to refer to alone or in any combination, analog circuitry, digital circuitry, hard wired circuitry, programmable circuitry, processor circuitry, microcontroller circuitry, hardware logic circuitry, state machine circuitry and/or any other type of physical hardware component. Embodiments may be used in many different types of systems. For example, in one embodiment a communication device can be arranged to perform the various methods and techniques described herein. Of course, the scope of the present invention is not limited to a communication device, and instead other embodiments can be directed to other types of apparatus for processing instructions, or one or more machine readable media including instructions that in response to being executed on a computing device, cause the device to carry out one or more of the methods and techniques described herein.
Embodiments may be implemented in code and may be stored on a non-transitory storage medium having stored thereon instructions which can be used to program a system to perform the instructions. Embodiments also may be implemented in data and may be stored on a non-transitory storage medium, which if used by at least one machine, causes the at least one machine to fabricate at least one integrated circuit to perform one or more operations. Still further embodiments may be implemented in a computer readable storage medium including information that, when manufactured into a SoC or other processor, is to configure the SoC or other processor to perform one or more operations. The storage medium may include, but is not limited to, any type of disk including floppy disks, optical disks, solid state drives (SSDs), compact disk read-only memories (CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any other type of media suitable for storing electronic instructions.
While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.
