The present disclosure relates generally to information handling systems, and more particularly to providing for the ordering and manufacturing of information handling systems utilizing Fast IDentity Online (FIDO) Device Onboarding (FDO) protocols.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option available to users is information handling systems. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes thereby allowing users to take advantage of the value of the information. Because technology and information handling needs and requirements vary between different users or applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, airline reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
The Fast IDentity Online (FIDO) Alliance has promulgated a set of security-focused technologies and protocols (“FIDO protocols” below) intended to simplify and enhance cybersecurity. Information handling systems such as, for example, server devices and/or other computing devices known in the art, may benefit by performing authentication via the FIDO Device Onboarding (FDO) protocol, particularly when provided at the “edge” of a network (“edge computing devices”). For example a computing device manufacturer may manufacture the edge computing device using the FIDFDO Device Initialization (DI) (FDO-DI) protocol, which provides for the generation of a public/private key pair, secure storage of the private key in the edge computing device, and inclusion of the public key in a digital ownership voucher that defines an “owner” of the edge computing device, with that digital ownership voucher configured to be transferred to using public/private key signing techniques to different “owners” of the edge computing device as it moves through the supply chain (e.g., Value-Added Resellers (VARs) and/or other resellers known the art) to an end user that provides the “last owner” of the edge computing device. However, the use of such digital ownership vouchers raises some issues.
To provide a specific example of the transfer of “ownership” of an edge computing device from a computing device manufacturer to a reseller via the FDO protocol, the computing device manufacturer will use its computing device manufacturer private key to sign a combination of edge computing device information and a reseller public key to produce first signed ownership transfer data, provide that first signed ownership transfer data in the digital ownership voucher to indicate that the reseller is the “owner” of the edge computing device, and transfer the digital ownership voucher to the reseller. The reseller may then transfer “ownership” of the edge computing device to the end user by using its reseller private key to sign a combination of edge computing device information and an end user public key to produce second signed ownership transfer data, provide that second signed ownership transfer data in the digital ownership voucher along with the first signed ownership data to indicate that the end user is the “owner” of the edge computing device, and transfer the digital ownership voucher to the end user.
As such, the FDO protocol discussed above may require “owners” of the edge computing device to store digital ownership vouchers, generate and maintain respective public/private key pairs, retrieve the public key from any new owner, combine the edge computing device information and that public key and sign it with their private key to produce signed ownership transfer data, provide signed ownership transfer data in digital ownership vouchers, and/or transfer digital ownership vouchers to new owners. As such, implementation of the FDO protocol as discussed above will require digital infrastructure transformations across the supply chain, as well as the coordination, collaboration, and education of computing device manufacturers, resellers, and end users, which will operate to slow down the adoption of the FDO protocol.
Accordingly, it would be desirable to provide a FIDO Device Onboarding (FDO) protocol computing device ordering/manufacturing system that addresses the issues discussed above.
According to one embodiment, an Information Handling System (IHS) includes a processing system; and a memory system that is coupled to the processing system and that includes instructions that, when executed by the processing system, cause the processing system to provide a computing device manufacturing engine that is configured to: identify, as part of an ordering process for a computing device being ordered by a subsequent owner, rendezvous system reachability information for at least one rendezvous system; provide the rendezvous system reachability information in the computing device prior to the computing device being transferred to the subsequent owner; retrieve, from a voucher management system, a voucher management system public key; sign, using a computing device manufacturer private key, the voucher management system public key to generate first ownership transfer data; provide the first ownership transfer data in an ownership voucher in order to transfer ownership of the computing device from the computing device manufacturer system to the voucher management system; and provide the ownership voucher to the voucher management system.
For purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., personal digital assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. The information handling system may include random access memory (RAM), one or more processing resources such as a central processing unit (CPU) or hardware or software control logic, ROM, and/or other types of nonvolatile memory. Additional components of the information handling system may include one or more disk drives, one or more network ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, touchscreen and/or a video display. The information handling system may also include one or more buses operable to transmit communications between the various hardware components.
In one embodiment, IHS 100,
Referring now to
In the illustrated embodiment, the networked system 200 also includes a rendezvous system 206 that is coupled to the network 204. In an embodiment, the rendezvous system 206 may be provided by the IHS 100 discussed above with reference to
The embodiment illustrated in
In the illustrated embodiment, the networked system 200 also includes a user location 212 that includes a plurality of devices that are coupled to the network 204, and that may be any location at which an end user may receive a computing device manufactured by the computing device manufacturer system 202. In the specific example illustrated in
In the specific example illustrated in
In the embodiment illustrated in
As will be appreciated by one of skill in the art in possession of the present disclosure, for any computing device ordered by an end user from a computing device manufacturer or reseller, that end user may wish to provide for the management of that computing device within its own, closed network. For example, military and/or other governmental entities may prevent any external network connections to computing devices they utilize, and thus may require any management of those computing devices (and associated management communications) to remain within a closed network, thus requiring a rendezvous system within that closed network as well. However, many end users will allow external network connections to the computing devices they utilize, and thus a rendezvous system provided by the computing device manufacturer or reseller is an option. As will appreciated by one of skill in the art in possession of the present disclosure, the conventional FDO protocol discussed above does not consider the possibility of different rendezvous system options, while the systems and methods discussed below enable the use of different rendezvous systems via the FDO protocol, and may be configured to provide a “layered FDO rendezvous system onboarding process” that provides an option to use any of a plurality of different rendezvous system options in order to automate FDO protocol functionality in any of the different possible computing device deployment scenarios discussed above.
Referring now to
In the illustrated embodiment, the computing device manufacturer system 300 includes one or more computing device manufacture locations 302 that one of skill in the art in possession of the present disclosure will recognize may include one or more facilities utilized by a computing device manufacturer to manufacture and provide computing devices to end users and/or third parties (e.g., the resellers discussed herein). For example, the computing device manufacture location(s) 302 may include a computing device ordering subsystem 304. In an embodiment, the computing device ordering subsystem 304 may be provided by the IHS 100 discussed above with reference to
The computing device manufacture location(s) 302 may also house one or more storage systems that are coupled to the computing device ordering subsystem 304 and that provide a computing device ordering database 306 that is configured to store computing device order information associated with the ordering of any computing devices from a computing device manufacturer. The computing device manufacture location(s) 302 may also include a computing device provisioning subsystem 304 that is coupled to the computing device ordering database 306 (e.g., via a coupling to the storage system). In an embodiment, the computing device provisioning subsystem 304 may include one or more of the IHS 100 discussed above with reference to
The computing device manufacture location(s) 302 may also house a communication system 308 that is coupled to the computing device ordering subsystem 304, the computing device provisioning subsystem 308, and the computing device ordering database 306 (e.g., via a coupling between the communication system 308 and the storage subsystem) and that may be provided by Network Interface Controllers (NICs), wireless communication systems (e.g., BLUETOOTH®, Near Field Communication (NFC) components, WiFi components, cellular components etc.), and/or any other communication components that would be apparent to one of skill in the art in possession of the present disclosure will recognize as allowing the network communications to and from the computing device manufacturer system 300 described below. However, while a specific computing device manufacturer system 300 has been illustrated and described, one of skill in the art in possession of the present disclosure will recognize that computing device manufacturer systems (or other devices and/or subsystems operating according to the teachings of the present disclosure in a manner similar to that described below for the computing device manufacturer system 300) may include a variety of components and/or component configurations for providing conventional computing device manufacturer functionality, as well as the functionality discussed below, while remaining within the scope of the present disclosure as well.
Referring now to
The chassis 402 may also house a storage system (not illustrated, but which may include the storage 108 discussed above with reference to
Referring now to
The method 500 begins at block 502 where a voucher management system receives an ownership voucher from a first owner system that transfers ownership of a computing device to the voucher management system. In an embodiment, during or prior to the method 500, an “end user” at the user location 212 (also called a “last owner” below) may order a computing device from the computing device manufacturer system 202 (the “first owner system” in this example). For example, with reference to
In some of the specific examples below, the end user that ordered the computing device may be considered a “subsequent” owner of the computing device (i.e., they will own the computing device immediately subsequent to the computing device manufacturer that is the “original owner” of the computing device). However, as discussed below, the “subsequent owner” of the computing device may be provided by a third party/reseller who then later provides that computing device to the “last owner”/end user. In either situation, the computing device ordering operations 600 may include the computing device ordering subsystem 304 identifying a subsequent owner identifier for the subsequent owner that ordered the computing device from the computing device manufacturer system 202, and associating that subsequent owner identifier with the computing device ordering information for that computing device in the computing device ordering database 306.
Furthermore, in a specific example of the ordering of the computing device by the subsequent owner from the computing device manufacturer system 300, the computing device ordering operations 600 may include the subsequent owner (e.g., the end user using the management device 212b, the third party/reseller using the third party system 210, etc.) and the computing device ordering subsystem 304 communicating so that the computing device ordering subsystem 304 may identify the rendezvous system reachability information discussed above for at least one rendezvous system. For example, in the event that the subsequent owner will have the computing device manufacturer manage the computing device being ordered, the subsequent owner may specify rendezvous system reachability information for a rendezvous system managed by the computing device manufacturer (e.g., “rendezvous.dell.com” in the specific example above). Furthermore, in some examples the rendezvous system reachability information for the rendezvous system managed by the computing device manufacturer may be provided in the computing device as a default rendezvous system reachability information option, with the rendezvous system reachability information for the rendezvous system managed by the computing device manufacturer described as “global rendezvous system reachability information” in the some of examples below.
In another example, in the event that the subsequent owner is a third party/reseller that will manage the computing device being ordered, the subsequent owner may specify rendezvous system reachability information for a rendezvous system managed by the third party/reseller (e.g., “rendezvous.var.com” in the specific example above). Furthermore, in some examples the rendezvous system reachability information for the rendezvous system managed by the third party/reseller may be provided in the computing device with the default rendezvous system reachability information option discussed above, with the rendezvous system reachability information for the rendezvous system managed by the third party/reseller described as “reseller local rendezvous system reachability information” in the examples below.
In another example, in the event that the subsequent owner is an end user that will manage the computing device being ordered, the subsequent owner may specify rendezvous system reachability information for a rendezvous system managed by the end user (e.g., “rendezvous.enduser.com” in the specific example above). Furthermore, in some examples the rendezvous system reachability information for the rendezvous system managed by the end user may be provided in the computing device with the default rendezvous system reachability information option discussed above, with the rendezvous system reachability information for the rendezvous system managed by the end user described as “end user local rendezvous system reachability information” in the examples below.
As such, rendezvous system reachability information may be identified by the computing device ordering subsystem 304 during the computing device ordering operations 600 and may include global rendezvous system reachability information that is identified via the communications with the subsequent owner or in response to no rendezvous system reachability information being explicitly provided by the subsequent owner (in which case that “default”/global rendezvous system reachability information may be retrieved by the computing device ordering subsystem 304 from a database in the computing device manufacturer system 300), reseller local rendezvous system reachability information that is identified via the communications with the subsequent owner/reseller, and/or end user local rendezvous system reachability information that is identified via the communications with the subsequent owner/end user. As discussed above, the computing device ordering information storage operations 602 may include storing any of the rendezvous system reachability information identified during the computing device ordering operations 600 in the computing device ordering database 306.
In a specific example, the manufacture of the computing device ordered by the end user may include performing any of a variety of other computing device manufacturing operations that one of skill in the art in possession of the present disclosure would recognize as providing for the functionality discussed below. For example, the manufacture of the computing device ordered by the end user may include operating and utilizing information according to the FDO-DI protocol to provide a “pointer” (e.g., the rendezvous system reachability information discussed above) to the rendezvous system 206 in the computing device, generate a public/private key pair (e.g., a computing device public key and a corresponding computing device private key), and generate a hash of the computing device manufacturer public key, and storing the pointer, computing device private key, and the hash of the computing device manufacturer key in the computing device (e.g., using a Trusted Execution Environment (TEE) such as a Trusted Platform Module (TPM) in the computing device). In a specific example, the manufacture of the computing device may include providing an FDO client in the TEE in the computing device that operate to maintain device ownership credentials provided by the rendezvous system reachability information/pointer, the computing device private key, and the hash of the computing device manufacturer public key.
In a specific example of the manufacture of the computing device ordered by the end user, the computing device provisioning subsystem may retrieve the rendezvous system reachability information identified during the computing device ordering operations 600 from the computing device ordering database 306, and provide the rendezvous system reachability information in the computing device ordered by the end user. As will be appreciated by one of skill in the art in possession of the present disclosure, in some embodiments the rendezvous system reachability information provided in the computing device ordered by the end user may include a single pointer to the rendezvous system 206 (e.g., the “rendezvous.dell.com” pointer to the rendezvous system managed by the computing device manufacturer, the “rendezvous.var.com” pointer to the rendezvous system managed by the third party/reseller, or the “rendezvous.enduser.com” pointer to the rendezvous system managed by the end user, each of which is described above).
However, as also discussed above, in some embodiments, the rendezvous system reachability information provided in the computing device ordered by the end user may include multiple pointers to different rendezvous systems in order to provide the “layered FDO rendezvous system onboarding process” discussed in further detail below. Continuing with the specific example above, the rendezvous system reachability information provided in the computing device ordered by the end user may prioritize pointers to different rendezvous systems by providing the global rendezvous system reachability information (e.g., the “rendezvous.dell.com” pointer to the rendezvous system managed by the computing device manufacturer) with the highest priority, as well as providing at least one of the reseller local rendezvous system reachability information (e.g., the “rendezvous.var.com” pointer to the rendezvous system managed by the third party/reseller) with an intermediate priority, and the end user local rendezvous system reachability information (e.g., the “rendezvous.enduser.com” pointer to the rendezvous system managed by the end user) with a lowest priority. However, while a specific example of prioritized rendezvous system reachability information is provided above, one of skill in the art in possession of the present disclosure will appreciate how rendezvous system reachability information may be prioritized in the computing device for any plurality of rendezvous systems in order to configure the computing device to contact the plurality of rendezvous systems based on the priority of their rendezvous system reachability information, discussed below, while remaining within the scope of the present disclosure as well.
In an embodiment, at block 502, the computing device provisioning subsystem 308 may perform computing device ownership transfer operations that include generating an ownership voucher for the computing device ordered by the end user, and using the ownership voucher to transfer ownership of the computing device ordered by the end user to the voucher management system 208. With reference to
In a specific example, the computing device provisioning subsystem 308 may generate the CDMS-private-key-signed encoded VMS public key 704 according to the FDO protocol by retrieving a VMS public key of the voucher management system 208, and performing a hashing operation on a combination of that VMS public key, a Globally Unique IDentifier (GUID) for the computing device that was ordered by the end user, computing device information associated with the computing device that was ordered by the end user (e.g., serial number(s), Media Access Control (MAC) address(es), etc.), and/or other any other information that would be apparent to one of skill in the art in possession of the present disclosure, in order to generate an encoded VMS public key. The computing device provisioning subsystem 308 may then sign that encoded VMS public key with the CDMS private key to provide the CDMS-private-key-signed encoded VMS public key 704. However, while a specific example of the generation of the CDMS-private-key-signed encoded VMS public key 704 has been described, one of skill in the art in possession of the present disclosure will appreciate how the computing device provisioning subsystem 308 may perform other operations according to the FDO protocol in order to transfer ownership of the computing device ordered by the end user to the voucher management system 208 using the ownership voucher 700 while remaining within the scope of the present disclosure.
For example, the discussion of the signing of the VMS public key using the CDMS private key above implies that the portion of the computing device provisioning subsystem 308 that generates ownership vouchers has access to the CDMS private key. However, in some situations, the computing device provisioning subsystem 308 may separate the portion of the computing device provisioning subsystem 308 that generates ownership vouchers from the portion of the computing device provisioning subsystem 308 at which computing devices are “built” (e.g., assembled and/or otherwise manufactured), with the portion of the computing device provisioning subsystem 308 at which computing devices are built implementing security protocols in association with the CDMS private key. As such, the computing device provisioning subsystem 308 may include a private key signing module that is controlled by the portion of the computing device provisioning subsystem 308 at which computing devices are built, and an ownership voucher generation module that is separate from the private key signing module and included in the portion of the computing device provisioning subsystem 308 that generates ownership vouchers.
In such embodiments, the ownership voucher generation module in the computing device provisioning subsystem 308 may operate to retrieve the VMS public key from the voucher management system 208, and use a secure Application Programming Interface (API) to provide the VMS public key to the private key signing module with an instruction to sign that VMS public key with the CDMS private key. When the private key signing module in the computing device provisioning subsystem 308 receives the VMS public key and corresponding instruction via the secure API, it may operate to sign the VMS public key using the CDMS private key to generate the first ownership transfer data, and may use the secure API to transfer the first ownership transfer data back to the ownership voucher generation module. In response to receiving the first ownership transfer data from the private key signing module via the secure API, the ownership voucher generation module may then provide the first ownership transfer data in the ownership voucher. As such, the computing device manufacturer system 202 may implement a secure API to ensure security of the CDMS private key while separating the “building” of computing device from the ownership voucher generation for those computing devices.
With reference to
With reference to
Furthermore, the ownership voucher mapping operations 802 may also include the voucher management engine 404 in the voucher management system 208/400 mapping the ownership voucher to the subsequent owner identifier that was associated with the computing device ordering information in the computing device ordering database 306 as discussed above. As such, the ordering of the computing device may result in a subsequent owner identifier for the subsequent owner (e.g., the end user or reseller discussed above), the computing device ordering information, and the ownership voucher being mapped to each other, thus allowing the subsequent owner and computing device to subsequently access the ownership voucher as discussed in further detail below.
With reference to
The method 500 then proceeds to decision block 504 where it is determined whether an ownership transfer request has been received. In an embodiment, at decision block 504, the voucher management engine 404 in the voucher management system 208/400 may operate to monitor for any ownership transfer requests that request the transfer of ownership of the computing device 800 to a different owner. As discussed above, at block 502 the voucher management system 208 was defined as the owner of the computing device 800 using the ownership voucher 700, and thus any request received by the voucher management engine 404 to transfer ownership of the computing device 800 to a “new” owner other than the voucher management system 208 may be recognized as the ownership transfer request at decision block 504. If, at decision block 504, it is determined that an ownership transfer request has not been received, the method 500 returns to decision block 504. As such, the method 500 may loop such that the voucher management engine 404 in the voucher management system 208/400 continues to monitor for any ownership transfer requests that request the transfer of ownership of the computing device 800 to a different owner (e.g., until an ownership transfer request is received).
If, at decision block 504, it is determined that an ownership transfer request has been received, the method 500 proceeds to decision block 506 where the method proceeds depending on whether the ownership transfer is to a last owner or an intermediate owner. In the first example provided herein, a “direct” computing-device-manufacturer-to-end-user scenario is described in which ownership of the computing device is transferred directly from the voucher management system 208 to the end user that ordered the computing device 800 (a “last owner” in that example) without having any intermediate owners in between. As will be appreciated by one of skill in the art in possession of the present disclosure, such a scenario may exist when end users order their computing devices directly from the computing device manufacturer such that those computing devices are shipped from or otherwise provided by the computing device manufacturer to the end user. However, in a second example provided below, an “indirect” computing-device-manufacturer-to-end-user scenario is described in which ownership of the computing device is transferred from the voucher management system 208 to one or more third parties (“intermediate owner(s)” in that example) before being transferred to the end user that ordered the computing device 800 (a “last owner” in this example). As will be appreciated by one of skill in the art in possession of the present disclosure, such a scenario may exist when end users order their computing devices from resellers that received those computing device either from the computing device manufacturer or other resellers, with those computing devices shipped from or provided by one of the resellers to the end user.
If, at decision block 506, the ownership transfer is to a last owner, the method 500 proceeds to block 508 where the voucher management system automatically generates last owner ownership transfer data. With reference to
In an embodiment, the voucher management system access operations 1000 may include the end user using the management device 212b providing an orchestrator system (OS) public key of the orchestrator system 212a to the voucher management system 208. As discussed in further detail below, in the examples provided herein, the orchestrator system 212a provides a “last owner system” to which ownership of the computing device 800 will provided using the ownership voucher 700, and the OS public key may be provided to the voucher management system 208 in order to allow that ownership transfer to be performed.
With reference to
With reference to
As such, an embodiment of decision blocks 504 and 506 may include the end user using the management device 212b to select one or more ownership vouchers that were provided for display by the voucher management system 208 on the management device 212b in order to transmit the ownership transfer request for those ownership vouchers. Continuing with the example of the ownership voucher 700 discussed above, the end user may use the management device 212b to select the ownership voucher 700 in order to transmit the ownership transfer request that is received by the voucher management system 208 at decision block 504, and the method will then proceed to block 508 due to the end user being the “last owner” of the computing device 800.
With reference to
In a specific example, the voucher management engine 404 may generate the VMS-private-key-signed encoded OS public key 1200 according to the FDO protocol by using the OS public key of the orchestrator system 212a that was provided via the management device 212b as discussed above, and performing a hashing operation on that OS public key, a GUID for the computing device 800, computing device information associated with the computing device 800 (e.g., serial number(s), MAC address(es), etc.), and/or other any other information that would be apparent to one of skill in the art in possession of the present disclosure in order to generate an encoded OS public key. The voucher management engine 404 may then sign that encoded OS public key with the VMS private key to provide the VMS-private-key-signed encoded OS public key 1200. However, while a specific example of the generation of last owner ownership transfer data provide by the VMS-private-key-signed encoded OS public key 1200 has been described, one of skill in the art in possession of the present disclosure will appreciate how the voucher management engine 404 may perform other operations according to the FDO protocol in order to transfer ownership of the computing device 800 to the orchestrator system 212a using the ownership voucher 700 while remaining within the scope of the present disclosure.
The method 500 then proceeds to block 510 where the voucher management system provides the last owner ownership transfer data in the ownership voucher to transfer ownership of the computing device to a last owner system. With reference to
The method 500 then proceeds to block 512 where the voucher management system provides the ownership voucher to the last owner system. With reference to
With reference to
The method 500 then proceeds to block 514 where the last owner system uses the ownership voucher. With reference to
As discussed above, rendezvous system reachability information provided in the computing device 800 may provide for a “layered FDO rendezvous system onboarding process”. Continuing with the specific example above, the rendezvous system registration operations 1300 may include the orchestration system 212a accessing the rendezvous system reachability information provided in the computing device 800 to attempt to register with rendezvous systems based on prioritized pointers to different rendezvous systems provided by that rendezvous system reachability information. As such, the rendezvous system registration operations 1300 may include the orchestration system 212a first using the global rendezvous system reachability information (e.g., the “rendezvous.dell.com” pointer with the highest priority in the examples provided above) to attempt to register with the rendezvous system managed by the computing device manufacturer. In the event the orchestration system 212a is unable to register with the rendezvous system managed by the computing device manufacturer, the orchestration system 212a may then use the reseller local rendezvous system reachability information (e.g., the “rendezvous.var.com” pointer with the intermediate priority in the examples provided above, if present) to attempt to register with the rendezvous system managed by the third party/reseller. In the event the orchestration system 212a is unable to register with the rendezvous system managed by the third party/reseller, the orchestration system 212a may then use the end user local rendezvous system reachability information (e.g., the “rendezvous.enduser.com” pointer with the lowest priority in the examples provided above, if present) to attempt to register with the rendezvous system managed by the end user.
With reference to
With reference to
Similarly, the computing device 800 may sign a nonce with its computing device private key to generate a computing-device-private-key-signed nonce, transmit the computing-device-private-key-signed nonce to the orchestrator system 212a, with the orchestrator system 212a verifying the computing-device-private-key-signed nonce using the computing device public key of the computing device, which one of skill in the art in possession of the present disclosure will recognize proves that computing device 800 has control of the computing device private key. The computing device 800 may then retrieve the computing device manufacturer public key 702 from the ownership voucher 700, verify the computing device manufacturer public key 702, and then verify the CDMS-private-key-signed encoded VMS public key 704 and the VMS-private-key-signed encoded OS public key 1200 in the ownership voucher 700, which one of skill in the art in possession of the present disclosure will recognize verifies the chain of ownership secured by the private key signatures to authenticate the orchestrator system 212a as the owner of the computing device 800.
As such, one of skill in the art in possession of the present disclosure will recognize that the computing device 800 may be utilized at the user location 212 following block 514. Thus, the “direct” computing-device-manufacturer-to-end-user scenario described above allows ownership of the computing device 800 to be transferred by the computing device manufacturer system 202 to the voucher management system 208, and then directly from the voucher management system 208 to the end user that ordered the computing device 800 without having any intermediate owners in between. However, as discussed below, an “indirect” computing-device-manufacturer-to-end-user scenario may be enabled in which ownership of the computing device 800 is transferred by the computing device manufacturer system 202 to the voucher management system 208, and then from the voucher management system 208 to one or more third parties (“intermediate owner(s)” in that example) before being transferred to the end user that ordered the computing device 800.
In such an “indirect” computing-device-manufacturer-to-end-user scenario, block 502 may be modified such that, instead of the end user at the user location 212 ordering the computing device from the computing device manufacturer system 202, a third party (e.g., a reseller) may order the computing device from the computing device and system 202 in a manner similar to that described above between the end user and the computing device manufacturer system 202, with the end user at the user location 212 then ordering the computing device from the third party in a manner similar to that described above between the end user and the computing device manufacturer system 202. As such, with reference to
Similarly as discussed above, in an embodiment of decision blocks 504 and 506, the third party that received the computing device 1702 at the location associated with third party system 210 may utilize the third party system 210 to perform voucher management system access operations that include accessing the voucher management system 208 via the network 204 in a manner similar to that discussed above by the end user. In response to authenticating the third party, the voucher management engine 404 in the voucher management system 208 may retrieve any computing device ordering information about computing device(s) ordered by the third party that was authenticated, use the computing device ordering information about computing device(s) ordered by the third party that was authenticated to identify any ownership vouchers in the voucher management database 406, and provide any of the ownership vouchers identified for the third party for display on the third party system 210. As such, one of skill in the art in possession of the present disclosure will recognize that the voucher management system 208 may provide a single, centralized location/source for third party to review any ownership vouchers that define the ownership of any computing devices ordered by the third party. As will be appreciated by one of skill in the art in possession of the present disclosure, such a single, centralized location/source for ownership vouchers review may be particularly beneficial to third parties that order hundreds, and even thousands, of computing devices from the computing device manufacturer.
Similarly as described above, an embodiment of decision blocks 504 and 506 may include the third party using the third party system 210 to select one or more ownership vouchers that were provided for display by the voucher management system 208 on the third party system 210 in order to transmit the ownership transfer request for those ownership vouchers. Continuing with the example of the ownership voucher 700 discussed above, the third party may use the third-party system 210 to select the ownership voucher 700 in order to transmit the ownership transfer request that is received by the voucher management system 208 at decision block 504, and the method will then proceed to block 508 due to the third party being an “intermediate owner” of the computing device 1702.
Thus, returning to decision block 506, if the ownership transfer is to an intermediate owner, the method 500 proceeds to block 516 where the voucher management system automatically generates an intermediate owner public/private key pair. In an embodiment, at block 516, the voucher management engine 404 in the voucher management system 208/400 may generate a third-party public/private key pair (e.g., prior to the transfer of ownership of the computing device to that third party, in response a request to transfer ownership of the computing device to that third party, etc.) for any third party (an “intermediate owner” in this example) that takes possession of a computing device for eventual provisioning to an end user, and may store that third-party public/private key pair in its voucher management database 408. However, while the voucher management system 208 is described as generating the third-party public/private key pair described herein, one of skill in the art in possession of the present disclosure will appreciate how a third party may generate its own third-party public/private key pair (and provide its third-party public key to the voucher management system 208 for use as discussed below) in other embodiments while remaining within the scope of the present disclosure as well.
The method 500 then proceeds to block 518 where the voucher management system automatically generates intermediate owner ownership transfer data. With reference to
In a specific example, the voucher management engine 404 may generate the VMS-private-key-signed encoded third party public key 1800 according to the FDO protocol by using the third party public key of the third party system 210 that was generated by the voucher management system 208/400 (or received from the third party system 210) as discussed above, and performing a hashing operation on that third party public key, a GUID for the computing device 1702, computing device information associated with the computing device 1702 (e.g., serial number(s), MAC address(es), etc.), and/or other any other information that would be apparent to one of skill in the art in possession of the present disclosure in order to generate an encoded third party public key. The voucher management engine 404 may then sign that encoded third party public key with the VMS private key to provide the VMS-private-key-signed encoded third-party public key 1800. However, while a specific example of the generation of intermediate owner ownership transfer data provided by the VMS-private-key-signed encoded third party public key 1800 has been described, one of skill in the art in possession of the present disclosure will appreciate how the voucher management engine 404 may perform other operations according to the FDO protocol in order to transfer ownership of the computing device 800 to a third party system 210 using the ownership voucher 700 while remaining within the scope of the present disclosure.
The method 500 then proceeds to block 520 where the voucher management system provides the intermediate owner ownership transfer data in the ownership voucher to transfer ownership of the computing device to an intermediate owner system. With reference to
The method 500 then proceeds to decision block 522 where it is determined whether an ownership transfer request has been received. In an embodiment, at decision block 522 and following the transfer of ownership of the computing device 1702 to an intermediate owner (i.e., one of the third parties discussed above), the voucher management engine 404 in the voucher management system 208/400 may monitor for an ownership transfer request similarly as discussed above. If, at decision block 522, it is determined that an ownership transfer request has not been received, the method 500 returns to decision block 522. As such, the method 500 may loop as long as the voucher management system has not received an ownership transfer request. If, at decision block 522, it is determined that an ownership transfer request has been received, the method 500 proceeds to decision block 524 where the method 500 proceeds similarly as described above depending on whether the ownership transfer is to a last owner or an intermediate owner.
If, at decision block 524, it is determined that the ownership transfer is to an intermediate owner, the method 500 returns to block 516. As such, the method 500 may loop such that the voucher management system 208 performs blocks 516, 518, and 520 to transfer ownership of the computing device 1702 to any further third parties/intermediate owners using the ownership voucher 700 similarly as described above. For example, to transfer ownership from the “1st third party” discussed above to a “2nd third party”, the voucher management system 208 may provide a 2nd-third-party-private-key-signed encoded 1st third party public key in the ownership voucher 700 similarly as described above, with the CDMS-private-key-signed encoded VMS public key 704 providing for the transfer of the ownership of the computing device 800 from the computing device manufacturer system 202 to the voucher management system 208, and the VMS-private-key-signed encoded “1st” third party public key 1800 providing for the transfer of the ownership of the computing device 800 from the voucher management system 208 to a 1st third party system 210, allowing the 2nd-third-party-private-key-signed encoded 1st third party public key to provide for the transfer of the ownership of the computing device 800 from the 1st third party system 210 to a 2nd third party system 210. One of skill in the art in possession of the present disclosure will appreciate how this process may be repeated for any further intermediate owners prior to the last owner.
If, at decision block 524, it is determined that the ownership transfer is to a last owner, the method 500 proceeds to blocks 508, 510, 512, and 514 as discussed above. With reference to
Furthermore, with reference to
As will be appreciated by one of skill in the art in possession of the present disclosure, in some situations it may be desirable to change the ownership of the computing device 800/1702 to another orchestrator system at the user location 212 or in another user location. In such situations, the computing device 800/1702 may be reset to a factory state (e.g., using a reset command provided by the orchestrator system 212a, via the use of a reset button the computing device 800/1702, or using other reset techniques known in the art). The end user may then access the voucher management system 208 again as described with reference to
Thus, systems and methods have been described that provide an ownership voucher management system that manages ownership vouchers utilized in the FDO protocol in order to facilitate the transfer of ownership of a computing device from a first owner to a last owner, and in some cases between one or more intermediate owners between the first owner and the last owner. For example, the FDO protocol ownership voucher management system of the present disclosure may be provided in a networked system including a first owner system and a second owner system coupled to a voucher management system. The voucher management system receives, from the first owner system, an ownership voucher having first ownership transfer data including a voucher management system public key that has been signed by a first owner system private key in order to transfer ownership of a computing device from the first owner system to the voucher management system. The voucher management system determines that the ownership of the computing device should be transferred to the second owner system and, in response, automatically generates second ownership transfer data by signing a second owner system public key with a voucher management system private key, and provides the second ownership transfer data in the ownership voucher in order to transfer ownership of the computing device from the voucher management system to the second owner system.
As such, ownership voucher transfer from a computing device manufacturer to an end user is simplified without breaking the FDO protocol (via the use of FDO-TO protocols at each transfer point) and without requiring end users/last owners or third parties/intermediate owners to provide, operate, and maintain FDO protocol support systems. Thus, a cryptographically secure, “zero-touch” experience is provided for ownership voucher transfer from a computing device manufacturer to an orchestrator system, thus allowing “zero-touch” securing onboarding of computing devices to the orchestrator system. As discussed above, the systems and methods of the present disclosure enable migration of computing devices between orchestrator systems, while also enabling computing device ordering either directly from the computing device manufacturer or through resellers while still maintain secure FDO protocol ownership transfers. As will be appreciated by one of skill in the art in possession of the present disclosure, the systems and methods of the present disclosure may be combined with zero-touch automation techniques to enable relatively large-scale secure FDO protocol onboarding of hundreds (or even thousands) of computing devices simultaneously.
Although illustrative embodiments have been shown and described, a wide range of modification, change and substitution is contemplated in the foregoing disclosure and in some instances, some features of the embodiments may be employed without a corresponding use of other features. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the embodiments disclosed herein.