Secure controls for export-restricted hardware components

Abstract

A device may generate at least one public key and at least one private key for authenticating execution of at least one command. A device may encrypt the at least one public key to generate a cryptographic key pair, wherein the cryptographic key pair includes the at least one private key and an encrypted version of the at least one public key. A device may provision to a root node the cryptographic key pair. A device may export, from the root node to a memory location of at least one device, the encrypted version of the at least one public key, wherein the at least one device is configured to execute the at least one command in response to receiving, from the root node, instructions comprising the at least one command fused with the at least one private key.

Description

SECURE CONTROLS FOR EXPORT-RESTRICTED HARDWARE COMPONENTSCROSS-REFERENCE TO RELATED APPLICATION

[0001] This Application claims the benefit of provisional U.S. Application No. 63 / 676,064, filed on July 26, 2024, and entitled “SECURE CONTROLS FOR EXPORT-RESTRICTED HARDWARE COMPONENTS,” which is hereby incorporated by reference in its entirety.

[0002] In cases where the present application conflicts with a document incorporated by reference, the present application controls.FIELD OF INVENTION

[0003] The present technology relates generally to technological methods of solving or alleviating supply chain and export control problems and, more specifically, to technological methods of authentication and encryption for solving or alleviating such problems.BACKGROUND OF THE INVENTION

[0004] Export controls aim to ensure safety and compliance with respect to transportation of data, hardware computing components, and the storage of data within these hardware computing components, including CPUs (Central Processing Unit), HSMs (Hardware Security Module), GPUs (Graphis Processing Unit), etc.

[0005] When the security of a device is compromised, such as when a shipment of regulated computing components is stolen, hacked, or the security of a device is compromised in some way, then it can be useful to prevent further use of the device and components. The present technology provides a technological solution, including a mechanism in which authentication and encryption are used on a regulated device to prevent operation of the device by an intruding system.SUMMARY

[0006] Technical features and security steps can be implemented into computing hardware components (i.e. circuits, packages, and other hardware computing components), using end-to- end encryption. Such encryption can keep data encrypted and safe between the originator and intended recipient, and any third-party intruder is unable to decrypt the data.

[0007] An aspect of the present technology is a system and method for securely exporting devices, addressing supply chain concerns, and issues around export controls. Another aspect ofthe present technology prevents reuse of hardware components, including but not limited to, CPUs, GPUs and HSMs, which are interdicted or stolen. Methods and systems described herein are directed to a mechanism to provision a public key schema during the manufacture of regulated devices so that commands, such as booting, can be prevented if the device is placed in a system which cannot authenticate the boot command. In accordance with another aspect of the present technology, a system (i.e. server package) and a method for generating the server package are described herein.

[0008] In some aspects, the techniques described herein relate to a method for securing export- restricted hardware components, the method including: generating at least one public key and at least one private key for authenticating execution of at least one command; encrypting the at least one public key to generate a cryptographic key pair, wherein the cryptographic key pair includes the at least one private key and an encrypted version of the at least one public key; provisioning to a root node the cryptographic key pair; exporting, from the root node to a memory location of at least one device, the encrypted version of the at least one public key; wherein the at least one device is configured to execute the at least one command in response to receiving, from the root node, instructions including the at least one command fused with the at least one private key.

[0009] In some aspects, the techniques described herein relate to a server package including: a processor; a memory; a root node; a device; wherein the memory stores instructions which, when executed by the processor, performs operations including: receiving, at the root node, a boot command signed with an owner public key, wherein the owner public key and an owner private key are generated by an owner of a platform; in response to booting the root node, transmitting by the root node a first nonce value to the device; encrypting, using a device public key, a response including a second nonce value; transmitting the encrypted response to the root node; and decrypting the response by the root node to verify the second nonce value generated with the response for booting the device.

[0010] In some aspects, the techniques described herein relate to a server package, wherein the operations further include: transmitting, by the root node to the device, a signed boot command along with a third nonce value; and receiving, from the device, instructions requesting authentication from the root node to boot the device.

[0011] In some aspects, the techniques described herein relate to a server package, wherein the processor performs operations further including: determining by the device, a signed command from the root node, to revoke the device public key.

[0012] In some aspects, the techniques described herein relate to a server package, wherein the processor performs operations further including: generating a new device public key to be assigned to the signed command.

[0013] In some aspects, the techniques described herein relate to a server package, wherein the processor performs operations further including: in response to a boot command from the device, transmitting the signed command with the new device public key; and executing the boot command in the device, in response to authentication of the signed command with the new device public key.

[0014] All combinations of the foregoing concepts and additional concepts discussed in greater detail below (provided such concepts are not mutually inconsistent) are part of the inventive subject matter disclosed herein. In particular, all combinations of claimed subject matter appearing at the end of this disclosure are part of the inventive subject matter disclosed herein. The terminology used herein that also may appear in any disclosure incorporated by reference should be accorded a meaning most consistent with the particular concepts disclosed herein.BRIEF DESCRIPTIONS OF THE DRAWINGS

[0015] The skilled artisan will understand that the drawings primarily are for illustrative purposes and are not intended to limit the scope of the inventive subject matter described herein. The drawings are not necessarily to scale; in some instances, various aspects of the inventive subject matter disclosed herein may be shown exaggerated or enlarged in the drawings to facilitate an understanding of different features. In the drawings, like reference characters generally refer to like features (e.g., functionally similar and / or structurally similar elements).

[0016] FIG. 1 illustrates an example block diagram of a system in accordance with the present technology.

[0017] FIG. 2 illustrates an exemplary message flow and process step diagram of a handshake / replay method in accordance with the present technology.

[0018] FIG. 3 depicts a flow chart of the inventive method for generating the system of FIG. 1.DETAILED DESCRIPTION

[0019] A method of authenticating hardware devices includes providing a command signed with a corresponding private key. At least one public key, or a set of public keys paired with one private key, is generated and used for authenticating the execution of at least one command (i.e. boot command). The private key is owned and protected by the final system owner, the system including the hardware devices to be authenticated. Another aspect includes a boot enablement flow which includes a handshake / replay protection mechanism.

[0020] The present technology is directed to providing one or more solutions to address supply chain concerns and issues around exporting hardware components. A public key system provisioned during the manufacturing process for each of a number of regulated devices and used to prevent misuse or reuse of stolen hardware components (i.e. CPUs, GPUs or HSMs). The measures rely on an authentication process, including using a public key authentication mechanism, which prevents the booting of the device without the corresponding private key.

[0021] A Root-of Trust (RoT) node can be relied upon in executing commands including a secure booting process. The RoT node serves as a security component which provides a trusted source for a device or system to use to establish strong security levels. The RoT node can provide a set of trustworthy functions in a system, thereby providing the rest of the system with establishing strong levels of security. RoTs can be integrated as chips, and can be hardware, firmware or software components. RoTs play an integral role along with a Public Key Infrastructure (PKI) in ensuring security in systems and their devices.

[0022] In an embodiment, the method utilizes a RoT node with a PKI using an encryption process in which at least one public key (or a plurality of public keys) are encrypted, and paired with a private key as part of a cryptographic key pair. The RoT node is provisioned with the cryptographic key pair. The root node would then export the encrypted version of the at least one public key to a memory location of at least one device in the system. This allows the system to execute the booting process (amongst other commands) in response to receiving from the root node instructions including the at least one command signed or fused with the private key.

[0023] FIG. 1 illustrates an example of a block diagram of a system 100 to execute a method in accordance with one or more aspects of the present technology. The system 100 comprises a device 101, a PRoT 102 and a BMC 103 (baseboard management controller). The device 101 and the PRoT 102 communicate using a digital communication protocol, data communication links or communication channel through the BMC 103. For example, I2C can be used on acommunication bus to communicate with devices within a system, including sending and receiving commands and data. Device 101 may represent devices within an embedded system, which must be secured and accessed based on an authentication mechanism.

[0024] In some aspects, a controller (i.e. BMC 103) will send the signed boot commands as part of an initial out of band component enumeration. This allows for the controller (BMC 103) to provide a secure dedicated alternate access method for authenticating and booting the device 101 (for example, a server device). The BMC 103 is able to authenticate, boot and manage powered devices in the system through an alternate point of access (i.e. BMC).

[0025] For example, during manufacture, the PRoT 102 gets provisioned with a cryptographic key pair, in some cases, with the public key referred to as the Boot PuK and the private key referred to as Boot Prk.

[0026] The term platform in this description refers to a server or a system. In some aspects, the platform can be a set of integrated elements in a chassis, including but not limited to a motherboard, PCI devices, hard drives, CPUs, GPUs, accelerators, management engines (BMC), dedicated processers (TPM, PRoT), memory, etc. Additionally, the platform can be implemented as a server platform, drones, satellites, or any other kind of computing devices.

[0027] In some aspects, the PRoT also supports manual programming of the private key(s) that will be used to sign the boot commands. In some aspects, more than one public key is provisioned in a given device, allowing for device X to be able to boot in different platforms, for example, Platform A, B, or C. A device may rely on available key slots to implement access to multiple devices. Additionally, the generation, storage, transportation and custody of such keys (public or private keys) may be in accordance with a different protocol or mechanism.

[0028] In some aspects, once the PRoT and devices have been provisioned with the keys, the PRoT is finally programmed with a public key that is owned by the final customer of the platform. This owner public key is generated by the owner of the platform, as a pair, the pair including a private key as well. For example, the referenced private key and public key could be referred to as OwnerPub and OwnerPriv, respectively. The provisioning of the owner keys are carried out generally towards the end of the manufacturing processing, including but not limited to after, the quality assurance steps and manufacture validation is completed and the devices are ready to be shipped.

[0029] In further steps of the method, the platform is powered with a DC power connect, with the PRoT booting when the command signed with the corresponding key is provided. For example, the owner public key is provisioned to the PRoT during manufacture or nearing the end of manufacture, where the PRoT is programmed with this owner public key that is owned by the final customer of the platform. This provisioning allows for the PRoT to be authenticated and booted when a command signed with the corresponding owner private key is provided.

[0030] The authentication of the PRoT boot prevents additional abuse, where for example, instead of just cannibalizing the platform, an intruder may attempt to steal the whole system and attempts to boot the system as a whole. In such cases, the PRoT is able to authenticate scenarios, in which upon rack placement, all the servers can be securely booted by designated staff and hand carry a device capable of sending the signed boot command. Additionally, the generation, storage, transportation and custody of such keys (public or private keys) and the device may be in accordance with various different protocols or mechanism.

[0031] In some aspects, the PRoT is able to access the network, and once powered up is able to listen for the signed boot command from the owner’s device (i.e. Owner’s Control Plane).

[0032] Upon authentication, the final owner is considered to be operating in a trusted environment. Additional aspects include a handshake / replay protected flow which can be implemented to authenticate a device and / or the PRoT.

[0033] In the next steps of the method, the PRoT and device boot handshake is described. The PRoT is unlocked during the PRoT boot process, and once booted, a nonce value (K) is transmitted to the device. The device uses its public key (device public key) to encrypt a response which contains a K+l nonce value. Next, the PRoT is able to decrypt the response from the device and confirm the K+l nonce value. After the confirmation of the K+l nonce value, the PRoT is now able to send a signed boot command together with a K+2 nonce value to the device. The device responds with an acknowledge signal (ACK) and a nonce value (K+3), allowing the PRoT to authenticate and complete the boot process for the device. The noncebased mechanism provides additional protection against replay attacks.

[0034] Additional aspects include a method for transferring device ownership. The user accessing the device further comprises a method for supporting transfer of ownership. A flow process describes the PRoT device recognizing a signed command from the PRoT to revoke the current private key and bum or assign a new private key in an available slot. Upon a subsequent request of the boot command, the device can boot after receiving a boot command signed withthe new private key. This allows options for reconfiguring the private key for authentication after manufacture, for situations, such as, as using a device to boot on a different platform.

[0035] Additionally, the systems and methods described herein pertains to varying situations, including but not limited to, a single device booting on a single platform, a single device booting in more than one platform with corresponding PuKs which are programmed, a set of devices booting on a single platform, and a set of devices with a set of PuKs, programmed to boot on a given set of platforms.

[0036] During manufacture, the PRoT 102 is provisioned with a cryptographic key pair, a public key 105 (i.e. Boot PuK), and a private key 106 (Boot PrK). The public key is exported and burnt or programmed in the memory 104 of PRoT 102 for booting across the set of devices that will be locked to a platform. Memory 104 can include RAM, registers, One-Time-Programmable Memory (OTP) and / or Programmable Read Only Memory (PROM). The platform may include a set of devices allowed to boot only if the PRoT sends a boot command signed with the corresponding private key. The device 101 includes at least one slot 107 for storing the at least public key. In some embodiments, the device is provisioned with additional key slots.Additionally, the generation, storage, transportation and custody of such keys (public or private keys) may be in accordance with a different protocol or mechanism.

[0037] In some aspects, the public key is exported and burnt or programmed in memory (memory 104) across the set of devices that are locked down to the platform, i.e. the set of devices allowed to boot when the PRoT sends a boot command signed with the corresponding private key. The key generation can be carried out automatically by the PRoT or an external device can be used to generate through, for example, a Key Derivation Unit, using a nonce mechanism, IV values etc..

[0038] In some embodiments, more than one public key is provisioned to a given device. This allows for a device to be able to boot in different platforms, including for example, any one of platform A, B or C. In such cases, the device 101 would need additional key slots.

[0039] Generating the key(s) can be done automatically by the PRoT 102 or an external input can be used, including but not limited to, a Key Derivation Function based on a nonce mechanism, IV values etc. PRoT 102 may also support manual programming of the private key(s) that will be used to sign the boot commands.

[0040] The BMC 103 can be implemented in a variety of ways including as a Field Programmable Gate Array (‘FPGA’), a Programmable Logic Chip (PLC), an Application Specific Integrated Circuit (ASIC), System-on-Chip (SOC) or any computing devices that includes discrete components such as a processing device, central processing unit, computer memory or various adapters.

[0041] The data communication links described herein are collectively illustrated by data communication links and may be implemented through a PCIe interface.

[0042] Data communications links may be PCIe interfaces or may be based on other communication standards.

[0043] BMC 103 may be configured to manage, control the operation of, and monitor components of system 100 and may function as the central management agent for a server or computing system. BMC 103 may be responsible for and configured to manage debugging, fault handling, firmware updating for components, thermal and power management, telemetry, and other suitable functions. BMC 103 may include at least one processor and at least one non- transitory computer-readable medium, the medium containing instructions configuring the processor to perform one or more functions outlined herein. The BMC 103 may transmit the signed boot commands as part of an initial out-of-band component enumeration.

[0044] In some embodiments, once the PRoT 102 and the device 101 are provisioned with the keys, the PRoT 102 is programmed with a public key that is owned by the final customer of the platform. As such, a public owner key and a private owner key are associated with the PRoT 102 for authenticating and booting the PRoT. This step is carried out generally after a quality assurance process and manufacture validation is completed, when the servers are ready to be shipped to the final owner.

[0045] Once the platform has been connected to a power, for example, by installing a power supply such as a DC power supply or an AC power supply, the PRoT 102 can be booted when a command signed with the corresponding key is provided. In this case, the public owner key and the private owner key pair are used for the booting of the PRoT 102. This further protects the system as a whole, and prevents additional abuse. Instead of stealing the platform, the attacker steals the whole system and boots it as a whole. For example, upon rack placement, all the devices (i.e. servers) can be securely booted by designated users, and a device capable of sending the signed boot command can be transported throughout a data center.

[0046] In some embodiments, the PRoT 102 has direct network access and after receiving power listens for the signed boot command from a set of devices in the owner’s system (i.e. owner’s control plane). The control plane, for example, is a component that runs controller processes and is part of a system.

[0047] The environment in which the PRoT is authenticated and booted can be trusted and under the full and final control of the owner and / or at the least, accessible to designated users. An additional replay protected flow can also be implemented for further authentication.

[0048] Fig. 2 shows an exemplary message flow and process step diagram of a handshake / replay method in accordance with the present technology, between a device 101, and a PRoT 102. The handshake / replay method relies on a nonce mechanism to authenticate the communications between the device 101 and the PRoT 102. The nonce value is used to protect the communication between the PRoT 102 and the device 101. The nonce value prevents replay attacks and are represented as random or pseudo-random numbers that authentication protocols attach to communications. As such, the nonce value provides additional confirmation and prevents replay attacks that rely on impersonating prior communications in order to gain access. As such, the nonce mechanism provides additional confirmation of the authenticity of a message. Attaching a nonce value to a communication adds another verification step for the communication between the device 101 and the PRoT 102.

[0049] The pictured handshake replay method is between the device 101 and PRoT 102 but a BMC 103 may also serve to facilitate the communication between the device 101 and PRoT 102. Step 200 begins when, for example, a server package has arrived to the final owner. At the onset of the device handshake process, the PRoT 102 has been unlocked and booted based on a cryptographic authentication.

[0050] At step 201, PRoT 102 sends a nonce (K) to the device 101. The device 101 uses its public key to encrypt a response and sends a second nonce value (K+l) in step 202. The PRoT 102 decrypts this response from the device 101 and confirms that the second nonce value was sent. At step 203, the PRoT 102 then sends a signed boot command along with a third nonce value (K+2) to the device 101. At step 204, the device 101 responds with an acknowledge (ACK) command and a fourth nonce value (K+3). The PRoT 102 then authenticates and completes the boot process for device 101. At step 205, device 101 has been authenticated and booted by PRoT 102. This nonce-based approach protects against replay attacks. Each devicecan receive a different nonce as they have different SMBus addresses in a communication channel (i.e. MoBo I2C Topology).

[0051] FIG. 3 shows an exemplary flow chart 300 of the inventive method executed during manufacturing of the device 101. Step 310 depicts generating at least one public key and at least one private key for authenticating execution of at least one command. Step 320 discloses encrypting the at least one public key to generate a cryptographic key pair, wherein the cryptographic key pair comprises the at least one private key and an encrypted version of the at least one public key. Step 330 discloses provisioning to a root node the cryptographic key pair. Step 340 discloses exporting, from the root node to a memory location of at least one device, the encrypted version of the at least one public key, wherein the at least one device is configured to execute the at least one command in response to receiving, from the root node, instructions comprising the at least one command fused with the at least one private key.

[0052] In another embodiment, a transfer of ownership of the device 101 may be implemented. Transferring device ownership includes the device 101 recognizing a signed command from the PRoT 102, to revoke the current key and burn or program new key in an available slot. When the next boot request is initiated, the device will boot in response to receiving a boot command signed with the new private key. This can be useful for booting device 101 across multiple and different platforms.

[0053] The implementation set forth above can include scenarios in which a single device is allowed to boot on a platform (1:1); a single device can boot on a plurality of platforms with corresponding public keys which are programmed (l:Many); a set of devices are locked down to a platform (N: 1); a set of devices can have a set of public keys programmed to boot on a given set of platforms (N:Many).CONCLUSION

[0054] While various inventive embodiments have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and / or structures for performing the function and / or obtaining the results and / or one or more of the advantages described herein, and each of such variations and / or modifications is deemed to be within the scope of the inventive embodiments described herein. More generally, those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary and that the actual parameters, dimensions, materials, and / or configurations will depend upon the specific application or applications for which the inventiveteachings is / are used. Those skilled in the art will recognize or be able to ascertain using no more than routine experimentation, many equivalents to the specific inventive embodiments described herein. It is, therefore, to be understood that the foregoing embodiments are presented by way of example only and that, within the scope of the appended claims and equivalents thereto, inventive embodiments may be practiced otherwise than as specifically described and claimed. Inventive embodiments of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods, if such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent, is included within the inventive scope of the present disclosure.

[0055] Also, various inventive concepts may be embodied as one or more methods, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.

[0056] All definitions, as defined and used herein, should be understood to control over dictionary definitions, definitions in documents incorporated by reference, and / or ordinary meanings of the defined terms.

[0057] The indefinite articles “a” and “an,” as used herein in the specification and in the claims, unless clearly indicated to the contrary, should be understood to mean “at least one.”

[0058] The phrase “and / or,” as used herein in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and / or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and / or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and / or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements); etc.

[0059] As used herein in the specification and in the claims, “or” should be understood to have the same meaning as “and / or” as defined above. For example, when separating items in a list, “or” or “and / or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of’ or “exactly one of,” or, when used in the claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used herein shall only be interpreted as indicating exclusive alternatives (i.e. “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.” “Consisting essentially of,” when used in the claims, shall have its ordinary meaning as used in the field of patent law.

[0060] As used herein in the specification and in the claims, the phrase “at least one,” in reference to a list of one or more elements, should be understood to mean at least one element selected from any one or more of the elements in the list of elements, but not necessarily including at least one of each and every element specifically listed within the list of elements and not excluding any combinations of elements in the list of elements. This definition also allows that elements may optionally be present other than the elements specifically identified within the list of elements to which the phrase “at least one” refers, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, “at least one of A and B” (or, equivalently, “at least one of A or B,” or, equivalently “at least one of A and / or B”) can refer, in one embodiment, to at least one, optionally including more than one, A, with no B present (and optionally including elements other than B); in another embodiment, to at least one, optionally including more than one, B, with no A present (and optionally including elements other than A); in yet another embodiment, to at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

[0061] In the claims, as well as in the specification above, all transitional phrases such as “comprising,” “including,” “carrying,” “having,” “containing,” “involving,” “holding,” “composed of,” and the like are to be understood to be open-ended, i.e., to mean including but not limited to. Only the transitional phrases “consisting of’ and “consisting essentially of’ shall be closed or semi-closed transitional phrases, respectively, as set forth in the United States Patent Office Manual of Patent Examining Procedures, Section 2111.03.

Claims

CLAIMS1. A method for securing export-restricted hardware components, the method comprising: generating at least one public key and at least one private key for authenticating execution of at least one command; encrypting the at least one public key to generate a cryptographic key pair, wherein the cryptographic key pair comprises the at least one private key and an encrypted version of the at least one public key; provisioning to a root node the cryptographic key pair; and exporting, from the root node to a memory location of at least one device, the encrypted version of the at least one public key; wherein the at least one device is configured to execute the at least one command in response to receiving, from the root node, instructions comprising the at least one command fused with the at least one private key.

2. A server package comprising: a processor; a memory; a root node; and a device; wherein the memory stores instructions which, when executed by the processor, performs operations comprising: receiving, at the root node, a boot command signed with an owner public key, wherein the owner public key and an owner private key are generated by an owner of a platform; in response to booting the root node, transmitting by the root node a first nonce value to the device; encrypting, using a device public key, a response comprising a second nonce value; transmitting the encrypted response to the root node; and decrypting the response by the root node to verify the second nonce value generated with the response for booting the device.

3. The server package of claim 2, wherein the operations further comprise: transmitting, by the root node to the device, a signed boot command along with a third nonce value; andreceiving, from the device, instructions requesting authentication from the root node to boot the device.

4. The server package of claim 3, wherein the processor performs operations further comprising: determining by the device, a signed command from the root node, to revoke the device public key.

5. The server package of claim 4, wherein the processor performs operations further comprising: generating a new device public key to be assigned to the signed command.

6. The server package of claim 5, wherein the processor performs operations further comprising: in response to a boot command from the device, transmitting the signed command with the new device public key; and executing the boot command in the device, in response to authentication of the signed command with the new device public key.

Images