CN117150496A - Device identifier combining engine 3-layer architecture - Google Patents

Abstract

Implementations described herein relate to a Device Identifier Combining Engine (DICE) layer 3 architecture. In some implementations, a device may include a secure computing environment including a hardware root of trust (HRoT) dic component. The secure computing environment may include a DICE layer 0 component configured to derive a DICE identity key. The secure computing environment may include a DICE layer 1 component configured to derive a DICE alias key based on the DICE identity key. The secure computing environment may include a controller configured to receive an update to firmware of a component. The controller may be configured to update the firmware of the component based on receiving the update. The controller may be configured to update one or more keys of the component or one or more keys of one or more components above the component in a layer stack.

Description

Device identifier combining engine 3-layer architecture

RELATED APPLICATIONSCross-reference to (C)

The present patent application claims priority to U.S. provisional patent application No. 63/365,673 entitled "device identifier combination engine 3 layer architecture (DEVICE IDENTIFIER COMPOSITION ENGINE 3-LAYER ARCHITECTURE)" filed on 1, 6, 2022, which is hereby expressly incorporated by reference.

Technical Field

The present disclosure relates generally to devices having a secure computing environment, and, for example, to a Device Identifier Combination Engine (DICE) layer 3 architecture for devices having a secure computing environment.

Background

The device identifier assembly engine (DICE) is a security standard created by a Trusted Computing Group (TCG). The DICE architecture is a functional architecture for providing security in devices, such as memory devices, internet of things (IoT) devices, system-on-chip (SoC) devices, or microcontroller devices, among other examples. In the DICE architecture, DICE layer 0 may have firmware for the device and derive the key set based on the DICE hardware root of trust (HRoT) layer.

Disclosure of Invention

In one aspect, the present disclosure relates to a device comprising: a secure computing environment, comprising: a hardware root of trust (HRoT) device identifier combining engine (dic) component; a DICE tier 0 component configured to derive a DICE identity key, wherein the DICE tier 0 component is above the HRoT DICE component in the tier stack; and a DICE layer 1 component configured to derive a DICE alias key based on the DICE identity key, wherein the DICE layer 1 component is above the DICE layer 0 component in the layer stack; and a controller configured to: receiving an update to firmware of a component of a secure computing environment; updating firmware of a component of the secure computing environment based on receiving the update; and updating one or more keys of the component or one or more keys of one or more components above the component in the layer stack based on updating the firmware.

In another aspect, the present disclosure is directed to a method comprising: at a hardware root of trust (HRoT) layer of the device, receiving a command to generate a set of credentials; generating, at a device identifier combination engine (dic) layer 0 of the device, a device identifier key based on a layer 0 Composite Device Identifier (CDI), wherein the layer 0CDI is a representation of a variable code of layer 0, wherein the device identifier key is a root node of a dic derivation chain of the device; generating, at a DICE tier 1 of the device, an alias key based on the tier 1CDI, wherein the tier 1CDI is a representation of the tier 1 firmware, wherein the alias key is a leaf node of a DICE export chain of the device; at the DICE layer 1 of the device, generating a set of credentials in response to the command and based on the device identifier key and the alias key; and storing the set of credentials in a memory of the device to enable the device to provide the set of credentials as a response to another command.

In another aspect, the present disclosure is directed to a system comprising: a memory; and a controller configured to: generating a layer 0 Composite Device Identifier (CDI) of a device identifier combination engine (dic) layer 0 component using a hardware root of trust (HRoT) component; generating a DICE identity key using the DICE layer 0 component and based on the layer 0 CDI; generating an alias key using the DICE layer 1 component and based on the DICE identity key; receiving an update to firmware of the DICE layer 1 component; updating the firmware of the DICE layer 1 component but not the firmware of the DICE layer 0 component; and regenerating the alias key without regenerating the DICE identity key based on updating the firmware of the DICE layer 1 component without updating the firmware of the DICE layer 0 component.

In another aspect, the present disclosure is directed to an apparatus comprising: means for identifying an update to firmware of a 3-tier device identifier combination engine (dic e) architecture device, wherein the 3-tier dic e architecture device comprises a hardware root of trust (HRoT) tier, a dic tier 0 configured to store dic identity keys, and a dic tier 1 configured to store dic alias keys, wherein the order of tiers is a lowest tier in the 3-tier dic architecture, dic tier 0 is a lower tier in the 3-tier dic architecture, and dic tier 1 is a higher tier in the 3-tier dic architecture; and means for updating firmware of the 3-tier DICE architecture device, wherein the means for updating firmware of the 3-tier DICE architecture includes means for updating firmware of the particular tier such that one or more keys of the particular tier or a tier higher than the particular tier are updated and one or more keys of a tier lower than the particular tier are not updated.

Drawings

Fig. 1 is a diagram illustrating an example system capable of including a device having a device identifier combining engine (dic e) 3 layer architecture.

Fig. 2 is a diagram illustrating example components included in a device having a dic e 3 tier architecture.

Fig. 3 is a diagram illustrating an example of a dic architecture.

Fig. 4 is a diagram illustrating an example of components of a device having a dic e 3 tier architecture.

Fig. 5 is a flow chart of an example of providing a dic e 3 tier architecture to a device.

Fig. 6 is a flow chart of an example of updating firmware of a device having a dic e 3 tier architecture.

Detailed Description

Verification of firmware authenticity is important to ensure that the firmware to be executed by the device during, for example, a boot sequence is valid and not subject to malicious attacks. For example, verification of firmware authenticity may be performed to ensure that firmware within the memory device is manufacturer-provided firmware, rather than firmware incorporated into the memory device by a malicious entity to enable the exporting of data stored on the memory device. To verify firmware authenticity, the device identity of the device is signed as part of a chain of trust (CoT). The CoT is a set of linked certificates associated with the firmware and other components of the device. The CoT may be linked back to a root of trust (RoT), such as a root Certificate Authority (CA). Each certificate of the CoT is signed by a predecessor certificate (e.g., parent certificate) in the CoT, linked back to the RoT (e.g., root CA). In this way, each successive component in the CoT can verify that it is valid based on the validity of the parent component in the CoT. In other words, starting from the root certificate, each leaf certificate has a chain of certificates (e.g., end certificates without sub-certificates in the chain), thereby enabling tracking the validity of the set of linked components with the leaf certificate.

In a Device Identifier Combination Engine (DICE) architecture, a DICE device identity, which may be referred to as a "device ID," is bound to a single DICE layer ("DICE layer 0"). DICE layer 0 is a mutable software layer within a secure computing environment, such as a Secure Execution Environment (SEE). The DICE architecture binds the device ID public key to the root CA using the CoT, thereby enabling verification of the validity of DICE layer 0, its device ID public key, and subsequent components in the CoT, where the certificate is hierarchically signed and linked to the device ID public key. Periodically, the firmware of DICE layer 0 may need to be updated in order to fix errors, fix security vulnerabilities, or provide different functionality than originally designed for the firmware, among other examples. When the firmware of the DICE layer 0 is updated, the device ID is changed to an unsigned device ID, which destroys the existing CoT. In other words, when the firmware is changed at DICE layer 0, both the DICE identity key and any associated DICE alias keys must be updated. Thus, the new device ID certificate is issued by the root CA to recover the CoT and enable the issuance of the new dic identity key and the new dic alias key and associated certificates. However, issuing new device ID certificates may waste resources and/or pose security issues. Furthermore, issuing new device ID certificates may increase deployment complexity of devices with a dic architecture, and may not establish a way for issuing new device ID certificates, which may lead to ad hoc issues that pose security issues.

Some implementations described herein use a DICE 3-tier architecture to enable firmware updates without requiring issuance of new device ID certificates. For example, the DICE 3 layer architecture may provide a thin DICE layer 0 with minimal firmware to enable generation of device IDs and associated DICE identity keys. Further, the new DICE layer 1 may include the remainder of the firmware of the device (e.g., DICE layer 1 may include firmware in DICE layer 2 architecture, typically in DICE layer 0). In this case, most firmware updates may occur at DICE tier 1 rather than DICE tier 0.

When a firmware update occurs at DICE layer 1, the device ID and associated DICE identity key are unchanged (because the firmware update does not include the firmware of DICE layer 0). While the DICE alias key is updated to generate a new DICE alias key based on the update to the firmware of DICE tier 1, the new DICE alias key remains linked to the device ID and associated DICE identity key. Thus, the CoT of the device remains intact, which avoids the need to issue new device ID credentials, and saves resources and other instances associated with communicating or generating new credentials. Furthermore, by reducing the need to issue new credentials, some embodiments described herein improve information security. Furthermore, the DICE layer 1 firmware may be updated with new features and/or security fixes without losing the device ID of the device that includes the DICE layer 1 firmware.

Fig. 1 is a diagram illustrating an example system 100 capable of including a device having a dic e 3 tier architecture. The system 100 may include one or more devices, apparatuses, and/or components for performing the operations described herein (e.g., for providing a secure computing environment). For example, system 100 may include a host device 110 and a memory device 120. Memory device 120 may include a controller 130 and a memory 140. The host device 110 may communicate with the memory device 120 (e.g., the controller 130 of the memory device 120) via the host interface 150. The controller 130 and the memory 140 may communicate via a memory interface 160.

The system 100 may be any electronic device configured to store data in memory. For example, the system 100 may be a computer, a mobile phone, a wired or wireless communication device, a network device, a server, a vehicle (e.g., an automobile or airplane), and/or an internet of things (IoT) device. Host device 110 may include one or more processors configured to execute instructions and store data in memory 140. For example, host device 110 may include a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), and/or another type of processing component. In some implementations, the host device 110 may be or be included in a platform that utilizes an embedded device, such as an internet of things (IoT) platform, a cloud computing platform, or a manufacturing platform, among other examples.

Memory device 120 may be any electronic device configured to store data in memory. In some implementations, the memory device 120 may be an electronic device configured to persistently store data in non-volatile memory. For example, the memory device 120 may be a hard disk drive, a Solid State Disk (SSD), a flash memory device (e.g., a NAND flash memory device or a NOR flash memory device), a Universal Serial Bus (USB) flash drive, a memory card (e.g., a Secure Digital (SD) card), a secondary storage device, a non-volatile memory high speed (NVMe) device, and/or an embedded multimedia card (eMMC) device. In this case, memory 140 may comprise a non-volatile memory configured to maintain stored data after memory device 120 is powered down. For example, memory 140 may comprise NAND memory or NOR memory. In some implementations, memory 140 may include volatile memory that requires power to maintain stored data and to lose stored data after power is turned off to memory device 120, such as one or more latches and/or Random Access Memory (RAM), such as Dynamic RAM (DRAM) and/or Static RAM (SRAM). For example, volatile memory may cache data read from or written to nonvolatile memory, and/or may cache instructions to be executed by the controller 130.

The controller 130 may be any device configured to communicate with a host device (e.g., via the host interface 150) and the memory 140 (e.g., via the memory interface 160). Additionally or alternatively, the controller 130 may be configured to control the operation of the memory device 120 and/or the memory 140. For example, the controller 130 may include a memory controller, a system controller, an ASIC, an FPGA, a processor, a microcontroller, and/or one or more processing components.

Host interface 150 enables communication between host device 110 and memory device 120. Host interface 150 may include, for example, a Small Computer System Interface (SCSI), serial Attached SCSI (SAS), serial Advanced Technology Attachment (SATA), peripheral component interconnect express (PCIe), NVMe, USB, universal Flash Storage (UFS), and/or embedded multimedia card (eMMC) interface.

Memory interface 160 enables communication between memory device 120 and memory 140. The memory interface 160 may include a non-volatile memory interface (e.g., for communicating with non-volatile memory), such as a NAND interface or a NOR interface. Additionally or alternatively, the memory interface 160 may include a volatile memory interface (e.g., for communicating with volatile memory), such as a Double Data Rate (DDR) interface.

In some implementations, the memory device 120 may have a DICE 3-tier architecture. For example, the memory device 120 may be an embedded device that uses a DICE 3-tier architecture for generating an identification value derived from a Unique Device Secret (UDS). In this case, the controller 130 may execute the commands to generate a Composite Device Identifier (CDI) and/or generate a certificate or key pair associated therewith as described herein. Other types of embedded systems are contemplated that may include a DICE 3 layer architecture.

As indicated above, fig. 1 is provided as an example. Other examples may differ from the example described with respect to fig. 1.

FIG. 2 is a diagram of example components included in the memory device 120 of FIG. 1. As described above in connection with fig. 1, memory device 120 may include controller 130 and memory 140. As shown in fig. 2, memory 140 may include one or more non-volatile memory arrays 210, such as one or more NAND memory arrays and/or one or more NOR memory arrays. Additionally or alternatively, memory 140 may include one or more volatile memory arrays 220, such as one or more SRAM arrays and/or one or more DRAM arrays. The controller 130 may transmit signals to the nonvolatile memory array 210 and receive signals from the nonvolatile memory array 210 using the nonvolatile memory interface 230. The controller 130 may transmit signals to the volatile memory array 220 and receive signals from the volatile memory array 220 using the volatile memory interface 240.

The controller 130 may control the operation of the memory 140, for example, by executing one or more instructions. For example, memory device 120 may store one or more instructions as firmware in memory 140, and controller 130 may execute these one or more instructions. In some implementations, portions of firmware may be divided between different DICE layers of a DICE 3 layer architecture, as described herein. Additionally or alternatively, the controller 130 may receive one or more instructions from the host device 110 via the host interface and may execute those one or more instructions. In some implementations, a non-transitory computer-readable medium (e.g., volatile memory and/or non-volatile memory) may store a set of instructions (e.g., one or more instructions or code) for execution by the controller 130. The controller 130 may execute a set of instructions to perform one or more operations or methods described herein. In some implementations, execution of the set of instructions by the controller 130 causes the controller 130 and/or the memory device 120 to perform one or more operations or methods described herein. In some implementations, hardwired circuitry may be used in place of or in combination with one or more instructions to perform one or more operations or methods described herein. Additionally or alternatively, one or more components of the controller 130 and/or the memory device 120 may be configured to perform one or more operations or methods described herein. Instructions are sometimes referred to as "commands".

For example, the controller 130 may transmit signals to the memory 140 and/or receive signals from the memory 140 based on one or more instructions, such as transferring (e.g., writing or programming) data to the memory 140, transferring (e.g., reading) data from the memory 140, and/or erasing all or a portion of the memory 140 (e.g., one or more memory cells, pages, sub-blocks, or planes of the memory 140). Additionally or alternatively, the controller 130 may be configured to control access to the memory 140 and/or provide a translation layer between the host device 110 and the memory 140 (e.g., for mapping logical addresses to physical addresses of the memory array). In some implementations, the controller 130 can convert host interface commands (e.g., commands received from the host device 110) into memory interface commands (e.g., commands for performing operations on the memory array).

As shown in fig. 2, the controller 130 may include a memory management component 250, an error correction component 260, and/or a security component 270. In some implementations, one or more of these components are implemented as one or more instructions (e.g., firmware) executed by the controller 130. Alternatively, one or more of these components may be implemented as an application specific integrated circuit other than controller 130.

The memory management component 250 may be configured to manage the performance of the memory device 120. For example, the memory management component 250 may perform wear leveling, bad block management, block retirement, read disturb management, and/or other memory management operations. In some implementations, the memory device 120 may store (e.g., in the memory 140) one or more memory management tables. The memory management table may store information that may be used or updated by the memory management component 250, such as information regarding memory block age, memory block erase count, and/or error information associated with a memory partition (e.g., memory cells, memory rows, memory blocks, etc.).

Error correction component 260 may be configured to detect and/or correct errors associated with memory device 120. For example, error correction component 260 may be configured to detect and/or correct errors associated with writing data to or reading data from one or more memory cells of a memory array, such as Single Bit Errors (SBEs) or multi-bit errors (MBEs).

The security component 270 may be configured to perform one or more security operations for the memory device 120. For example, the security component 270 may be configured to encrypt or decrypt data, such as data read from the memory 140 and/or data to be written to the memory 140. Additionally or alternatively, the security component 270 may be configured to verify a command received from the host device 110, such as by verifying an encrypted signature of the command (e.g., using one or more encryption keys). In some implementations, the security component 270 may be part of or implement a secure execution environment and/or a secure data storage environment for generating and/or storing information associated with a chain of trust (CoT) of a dic 3 layer architecture, as described herein.

One or more devices or components shown in fig. 2 may be used to perform operations described elsewhere herein, such as one or more operations of fig. 3 and 4 and/or one or more process blocks of the methods of fig. 5 and 6. For example, the controller 130 and/or the security component 270 may perform one or more operations and/or methods for the memory device 120. Although some implementations are described herein in terms of memory device 120, other types of devices that integrate the DICE 3 layer architecture are contemplated.

The numbering and arrangement of the components shown in fig. 2 is provided as an example. In practice, there may be additional components, fewer components, different components, or differently arranged components than those shown in fig. 2. Furthermore, two or more components shown in fig. 2 may be implemented within a single component, or a single component shown in fig. 2 may be implemented as multiple distributed components. Additionally or alternatively, a set of components (e.g., one or more components) shown in fig. 2 may perform one or more operations described as being performed by another set of components shown in fig. 2.

Fig. 3 is a diagram illustrating an example of a dic architecture. As shown in fig. 3, the first dic architecture 300 is a dic 2 tier architecture and the second dic architecture 300' is a dic 3 tier architecture.

As further shown in FIG. 3, the DICE architecture 300/300' includes a secure computing environment 310/310' and a Firmware Security Descriptor (FSD) component 320/320'. The FSD component 320/320 'may include open code, such as firmware or software, that is not included in the secure computing environment 310/310', and may describe security features of the DICE architecture 300/300 'that is not included in the secure computing environment 310/310'. In the first DICE architecture 300, the secure computing environment 310 includes a HRoT DICE component 312 and a DICE layer 0 component 314. In the second DICE architecture 300', the secure computing environment 310' includes a DICE layer 0 component 314 '(e.g., in a protocol stack or architecture stack) above the HRoTDICE component 312', and a DICE layer 1 component 316 '(e.g., in a protocol stack or architecture stack) above the DICE layer 1 component 314'. Although some implementations are described herein in terms of a DICE 3 layer architecture, other higher layer architectures are contemplated (e.g., where the functionality described herein in terms of DICE layer 1 is divided into multiple layers).

The HRoT dic component 312 'is a component associated with providing Unique Device Secrets (UDS) for the second dic architecture 300'. For example, the HRoT dic component may generate a Composite Device Identifier (CDI) based on the measurements of the UDS and dic layer 0 components 314 'of the HRoT dic component 312'. In some embodiments, the measurement of the DICE layer 0 component 314 'may include, for example, a hash of the code of the DICE layer 0 component 314'. For example, the HRoT dic component 312 'may hash bit representations of the code of the dic layer 0 component 314' to generate a hash value. Additionally or alternatively, CDI may be based on measurements of device configuration data. For example, the HRoT dic component 312' may hash the bit representation of the code of the dic layer 0 component 314' and the bit representation of the device configuration data associated with the dic layer 0 component 314' to generate the hash value.

The DICE layer 0 component 314 'is a component associated with storing DICE identity keys for the second DICE architecture 300'. For example, the DICE layer 0 component 314 'may inherit the layer 0 Component Device Identifier (CDI) from the HRoT DICE component 312' and may generate the DICE identity key and the layer 1CDI as described herein. The tier 1CDI may be used to generate the dic e alias keys and associated certificates to verify the authenticity of other components in the stack of the dic e 3 tier architecture 300 'above the dic tier 0 component 314'. The DICE identity key pair may be used to sign and verify an associated certificate. In some implementations, the DICE layer 0 component 314' may include variable code, but may not have all of the firmware of the DICE layer 0 component 314 (e.g., in the layer 2 DICE architecture 300). For example, the firmware of the DICE layer 0 component 314 may be divided between the DICE layer 0 component 314 'and the DICE layer 1 component 316', such that the DICE layer 0 component 314 'only includes enough firmware for, for example, generating DICE identity keys and providing layer 1CDI to the DICE layer 1 component 316'. As one example, the dic layer 0 component 314' may comprise firmware for reading the layer 0CDI from the SEE memory, calculating the measurements of the dic layer 1 component 316', deriving the device ID key pair from the layer 0CDI, and deriving the layer 1CDI of the dic layer 1 component 316'. In this example, other functions such as attestation protocol functions, updates, certificate management or tamper resistant countermeasures, and other examples are offloaded to the DICE layer 1 component 316'. For example, the DICE layer 1 component 316 'may include the remainder of the firmware for performing other functions of the secure computing environment 310/310'. Thus, the DICE layer 0 component 314' will be associated with fewer firmware updates than the DICE layer 0 component 314 (e.g., at least some firmware updates to the DICE layer 0 component 314 in the first DICE architecture 300 will be applicable to the DICE layer 1 component 316' in the second DICE architecture 300 ').

The DICE layer 1 component 316 'is a component associated with storing DICE alias keys for the second DICE architecture 300'. For example, the DICE layer 1 component 316' may generate and store DICE alias keys based on and in the CoT with the DICE identity key. The DICE alias key and associated credentials may be used to verify the authenticity of a system including the DICE 3 layer architecture 300' and its firmware. In addition, the DICE alias key can be used to verify that subsequent components in the CoT are authentic. Additionally or alternatively, the DICE layer 1 component 316' may generate a set of credentials based on the DICE identity key and/or the DICE alias key, as described herein. For example, the DICE layer 1 component 316' may include firmware configured to enable generation of device ID certificates for DICE identity keys and/or alias certificates for alias keys. The alias certificate may be a leaf certificate associated with an alias manifest signed with a device ID private key. The device ID certificate is an intermediate certificate, with the device ID public key in the device ID certificate, and the device ID itself signed using the manufacturer private key. The manufacturer-specific key may be associated with a root certificate external to memory device 120, including the manufacturer public key and signed by the manufacturer. Between the device ID certificate and the manufacturer certificate may be one or more other intermediate certificates. In some implementations, the DICE layer 1 component 316' can output one or more generated credentials to enable verification of components associated with the one or more generated credentials (e.g., the DICE layer 1 component 316' and/or the DICE layer 0 component 314 ').

As indicated above, fig. 3 is provided as an example. Other examples may differ from the example described with respect to fig. 3.

Fig. 4 is a diagram illustrating an example of components of a device 400 having a dic e 3 tier architecture. Fig. 5 is an example method 500 associated with providing a dic e 3 layer architecture (e.g., a dic e 3 layer architecture 300') to a device 400 (e.g., which may correspond to a memory 140, a controller 130, a memory device 120, or a security component 270, among other examples).

As shown in fig. 4, the device 400 may include: SEE ROM HRoT 402, which may correspond to HRoT DICE component 312'; a DICE layer 0 component 404, which may correspond to the DICE layer 0 component 314'; a DICE layer 1 component 406, which may correspond to DICE layer 1 component 316'; and FSD 408, which may correspond to FSD component 320'.

As shown in fig. 4 and 5, and with reference numeral 550, the device 400 can read the UDS from a protected location within the SEE ROM. The UDS may be a statistically unique device-specific secret value specific to the hardware of the device 400. In some implementations, the UDS may be generated externally and installed with the device 400 during manufacture. Additionally or alternatively, the UDS may be generated internally during provisioning of the device, for example by using a Physical Unclonable Function (PUF). For example, the device 400 may obtain the UDS from a secure element of a memory structure associated with the SEE ROM HRoT 402. In some implementations, the device 400 may receive a command to generate a set of credentials at the SEE ROM HRoT 402. For example, device 400 may receive a command to generate a set of credentials in conjunction with a boot program or an authentication program, as well as other examples (e.g., memory device 120 may receive a command from host device 110). In this case, the device 400 (e.g., using the SEE ROM HRoT 402) may obtain the UDS to enable generation of the set of credentials. In some implementations, the device 400 may receive a command to generate a credential. In some implementations, the commands may include or be associated with a set of subcommands (e.g., a first command for the SEE ROM HRoT 402, a second command for the dic layer 0 component, or a third command for the dic layer 1 component, among other examples). In this case, the device 400 may receive multiple commands or may autonomously decompose a single command into multiple command sets for multiple components of the device 400.

As shown by reference numeral 552, the apparatus 400 may calculate a measurement of the dic layer 0 component 404. For example, the device 400 may use the hash function H (L0) to compute a hash of the code of the dic layer 0 component 404 (e.g., firmware stored in or associated with the dic layer 0 component 404 or a portion of the firmware). As shown by reference numeral 554, the apparatus 400 may derive a layer 0 (L0) CDI based on the measurements of the UDS and dic layer 0 components 404. For example, the device 400 may implement an encryption algorithm, such as secure hash algorithm 2 (SHA 2), to process UDS and H (L0) to generate values of L0 CDI (e.g., the device 400 may apply SHA2 or another hash algorithm to measurements of the UDS and dic layer 0 components 404 to generate L0 CDI). In some implementations, the device 400 may generate an L0 CDI at the dic layer 0 component 404. In some implementations, the L0 CDI may be a representation of variable code of the dic layer 0 component 404. For example, an L0 CDI is generated based on the code of the DICE layer 0 component 404. Thus, different code of the DICE layer 0 component 404 may result in different L0 CDI generation. In some embodiments, CDI may represent an invariable code measurement of a variable code. As described above, the measurements are combined with the device-specific UDS to form CDI. Thus, the CDI is unique to the device 400, the encrypted identity of the variable code of the device 400 (e.g., the variable code of the dic layer 0 component 404), and/or the configuration data of the device 400.

As shown by reference numeral 560, the device 400 may derive an asymmetric key pair based on the L0 CDI. For example, device 400 may use an asymmetric key generation function to generate a device identity key, such as a device ID of device 400, based on the L0 CDI. In some implementations, the device identity key can be the root node of a DICE derived chain (e.g., coT). In this way, the device ID is linked to the UDS in a secure manner (e.g., via hashing the UDS and measurements) in conjunction with the CoT. As shown by reference numeral 562, the apparatus 400 may calculate the measurements of the dic layer 1 components 406. For example, the device 400 may use the hash function H (L1) to calculate a hash of code of the dic layer 1 component 406 (e.g., firmware stored in or associated with the dic layer 1 component 406 or a portion of the firmware). As shown by reference numeral 564, the apparatus 400 may derive a layer 1 (L1) CDI based on the L0 CDI and the measurements of the dic layer 0 component 404. For example, the device 400 may implement an encryption algorithm, such as SHA2, to process L0 CDI and H (L1) to generate a value of L1 CDI (e.g., the device 400 may apply SHA2 or another hashing algorithm to the measurements of the L0 CDI and dic layer 1 components 406 to generate L1 CDI). In some implementations, the device 400 may derive the L1 CDI at the dic layer 1 component 406. In some implementations, the L1 CDI may be a representation of firmware of the dic layer 1 component 406. For example, the L1 CDI is generated based on firmware of the DICE layer 1 component 406. Thus, different firmware of the DICE layer 1 component 406 may result in different L0 CDI generation.

As shown by reference numeral 570, the device 400 may calculate a measurement of the FSD 408, which FSD 408 may be an open firmware component as described above in connection with fig. 3. For example, the device 400 may hash an open image set of the FSD 408 (e.g., code, data, or configuration information stored in the FSD 408 or associated with the FSD 408, or a portion of the code, data, or configuration information) to determine the measurements of the FSD 408. In some implementations, the device 400 may implement a hash function H (FSD) to process the FSD 408 (e.g., to hash an open code or firmware of the FSD 408). As shown by reference numeral 572, the apparatus 400 may derive key material based on the measurements of the L1 CDI and FSD 408. For example, the device 400 may implement a one-way function, such as SHA2, to process L1 CDI and H (FSD) (e.g., the device 400 may apply SHA2 or another hashing algorithm to the measurements of L1 CDI and FSD 408 to generate the keying material). The key material may be used to generate an alias key, as described below. In some implementations, the device 400 may derive the key material at the dic layer 1 component 406. In some implementations, the key material can be a representation of the code of the FSD 408. The keying material may be based on the FSD 408 and the layer 1CDI. The FSD 408 input may bind the open image measurement to the keying material. Thus, if FSD 408 changes the keying material, then the associated asymmetric key pair as described herein is changed. Layer 1CDI binds keying material indirectly to UDS and layer 0CDI such that if UDS or layer 0CDI changes, then the keying material changes and the associated asymmetric key pair changes. Thus, the host device 110 may authenticate the memory device 120 by receiving credentials signed with a different key and detecting whether the device code has changed (e.g., based on whether the different key has changed).

As shown in fig. 4 and 5, and with reference numeral 574, the device 400 may derive an asymmetric key pair based on the key material. For example, the device 400 may use an asymmetric key generation function to generate the alias key based on the key material. In this way, the alias key is linked to the UDS in conjunction with the CoT (e.g., via L1 CDI and L0 CDI). As shown by reference numeral 576, the apparatus 400 may generate a set of dic credentials. For example, the device 400 may use a device ID key pair to generate a device ID certificate (e.g., a device identifier certificate). Additionally or alternatively, the device 400 may use the device ID key pair and the alias key pair to generate a signed alias certificate. In some implementations, the device ID certificate can be a signed device identity of the device ID key pair. In this way, the device 400 may generate a set of credentials as a response to a command to generate the set of credentials.

In some implementations, the device 400 can receive another command to provide at least one of the set of credentials (e.g., the device ID credential and/or the alias credential), and can provide at least one of the set of credentials based on receiving the command, enabling verification of a component associated with the at least one credential. For example, when a system including device 400 is to authenticate device 400 to boot firmware provided by the manufacturer of device 400, device 400 may receive a command to provide a credential. In this case, the device 400 may use the device ID certificate and/or the alias certificate to provide credentials to the system. In some implementations, the device 400 may provide the alias certificate to the system to authenticate the device 400, and may use the device ID certificate to authenticate the alias certificate. In some implementations, the device 400 may use the alias key to determine a Message Authentication Code (MAC) as a response to the challenge (e.g., for verification or attestation).

In some implementations, the device 400 may receive an update to the code of the device 400, e.g., an update to the software of the device 400 or the firmware of the device 400. For example, the device 400 may receive updates to code of the FSD 408, the DICE layer 1 component 406, or the DICE layer 0 component 404. When the device 400 receives an update to the code of the DICE layer 0 component 404, the device 400 generates a new L0 CDI (which is based on a hash of the code of the DICE layer 0 component 404) and a new device ID (which is based on the L0 CDI). In this case, the alias key and the corresponding certificate are regenerated. In contrast, when modifying the code of the DICE layer 1 component 406, the L1 CDI is modified (which is based on the L0 CDI and a hash of the code of the DICE layer 1 component 406). Thus, when modifying the L1 CDI, the alias key (which is based on the hash of the open images of the L1 CDI and FSD 408) is modified. However, the device ID key based on the L0 CDI remains static during the update of the code of the dic layer 1 component 406. Similarly, an update to the code of FSD 408 results in an update to the alias key instead of the device ID key. Thus, by separating the firmware of the DICE layer into a DICE layer 0 component 404 with the device ID key and a DICE layer 1 component with the alias key, the device 400 is less likely to need to update the device ID key, which saves resources and achieves a higher level of security as described above. In this way, the memory device 120 may be updated with new features or security fixes at the DICE tier 1 without changing the device ID.

As indicated above, fig. 4 and 5 are provided as examples. Other examples may differ from the examples described with respect to fig. 4 and 5.

Fig. 6 is a flow diagram of an example method 600 associated with updating firmware of a device having a dic e 3 tier architecture. In some implementations, a device (e.g., device 400) may be executable or configurable for performing one or more of the process blocks of fig. 6. In some implementations, one or more components of the device (e.g., the controller 130, the HRoT dic component 312', the dic layer 0 component 314', the dic layer 1 component 316', the FSD component 320', the SEE ROM HRoT 402, the dic layer 0 component 404, the dic layer 1 component 406, or the FSD 408, among other examples) may be executed or configurable to perform one or more process blocks of fig. 6.

As shown in fig. 6, method 600 may include receiving an update to firmware of a component of a secure computing environment (block 610). For example, the device may receive updates to the DICE layer 0 component or the DICE layer 1 component. As further shown in fig. 6, method 600 may include updating firmware of components of the secure computing environment based on receiving the update (block 620). As further shown in fig. 6, method 600 may include updating one or more keys of a component or one or more keys of one or more components above the component in a layer stack based on updating firmware (block 630). For example, when updating for a DICE layer 0 component, the device may update one or more keys of the DICE layer 0 component and one or more keys of the DICE layer 1 component. For example, the device may generate an updated DICE device ID key and an updated DICE alias key. In contrast, when updating the key for the DICE layer 1 component, the device may update one or more keys of the DICE layer 1 component, but the device may refrain from updating one or more keys of the DICE layer 0 component. For example, the device may generate an updated DICE alias key, and may not need to generate an updated DICE device ID key.

While fig. 6 shows example blocks of the method 600, in some implementations, the method 600 may include additional blocks, fewer blocks, different blocks, or blocks arranged in a different manner than the blocks depicted in fig. 6. Additionally or alternatively, two or more of the blocks of method 600 may be performed in parallel. Method 600 is an example of one method that may be performed by one or more devices described herein. One or more devices may perform or be configured to perform one or more other methods based on operations described herein, such as operations described in connection with fig. 3-5.

In some embodiments, the apparatus comprises: a secure computing environment, comprising: a hardware root of trust (HRoT) device identifier combining engine (dic) component; a DICE tier 0 component configured to derive a DICE identity key, wherein the DICE tier 0 component is above the HRoT DICE component in the tier stack; and a DICE layer 1 component configured to derive a DICE alias key based on the DICE identity key, wherein the DICE layer 1 component is above the DICE layer 0 component in the layer stack; and a controller configured to: receiving an update to firmware of a component of a secure computing environment; updating firmware of a component of the secure computing environment based on receiving the update; and updating one or more keys of the component or one or more keys of one or more components above the component in the layer stack based on updating the firmware.

In some embodiments, the method comprises: at an HRoT layer of a device, receiving a command to generate a set of credentials; generating, at a dic layer 0 of the device, a device identifier key based on the layer 0CDI, wherein the layer 0CDI is a representation of a variable code of layer 0, wherein the device identifier key is a root node of a dic export chain of the device; generating, at a DICE tier 1 of the device, an alias key based on the tier 1CDI, wherein the tier 1CDI is a representation of the tier 1 firmware, wherein the alias key is a leaf node of a DICE export chain of the device; at the DICE layer 1 of the device, generating a set of credentials in response to the command and based on the device identifier key and the alias key; and storing the set of credentials in a memory of the device to enable the device to provide the set of credentials as a response to another command.

In some embodiments, the system comprises: a memory; and a controller configured to: generating a layer 0CDI of the dic layer 0 component using the HRoT component; generating a DICE identity key using the DICE layer 0 component and based on the layer 0CDI; generating an alias key using the DICE layer 1 component and based on the DICE identity key; receiving an update to firmware of the DICE layer 1 component; updating the firmware of the DICE layer 1 component but not the firmware of the DICE layer 0 component; and regenerating the alias key without regenerating the DICE identity key based on updating the firmware of the DICE layer 1 component without updating the firmware of the DICE layer 0 component.

In some embodiments, an apparatus comprises: means for identifying an update to firmware of a 3-tier dic architecture apparatus, wherein the 3-tier dic architecture apparatus comprises a HRoT tier, a dic tier 0 configured to store dic identity keys, and a dic tier 1 configured to store dic alias keys, wherein the order of tiers is the lowest tier in the 3-tier dic architecture, dic tier 0 is the lower tier in the 3-tier dic architecture, and dic tier 1 is the higher tier in the 3-tier dic architecture; and means for updating firmware of the 3-tier DICE architecture device, wherein the means for updating firmware of the 3-tier DICE architecture includes means for updating firmware of the particular tier such that one or more keys of the particular tier or a tier higher than the particular tier are updated and one or more keys of a tier lower than the particular tier are not updated.

The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of the embodiments described herein.

Although specific combinations of features are recited in the claims and/or disclosed in this specification, these combinations are not intended to limit the disclosure of the embodiments described herein. Many of these features may be combined in ways not specifically set forth in the claims and/or disclosed in the present specification. For example, the disclosure includes each dependent claim of the claim set in combination with each other individual claim of the claim set and each combination of multiple claims of the claim set. As used herein, a phrase referring to "at least one of" a list of items refers to any combination of those items, including a single member. As an example, "at least one of: a. b or c "is intended to encompass a, b, c, a +b, a+c, b+c, and a+b+c, as well as any combination with a plurality of the same elements (e.g., a+a, a+a+b, a+a+c, a+b+b, a+c, b+b, b+b+c, c+c, and c+c, or any other order of a, b, and c).

No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Furthermore, as used herein, the articles "a" and "an" are intended to include and be used interchangeably with "one or more" items. Furthermore, as used herein, the article "the" is intended to include, and be used interchangeably with, one or more of the items referred to in connection with the article "the". Where only one item is intended, the phrase "only one", "single" or similar language is used. Further, as used herein, the terms "having", and the like are intended to be open-ended terms that do not limit the elements they modify (e.g., "elements having" a may also have B). Moreover, unless explicitly stated otherwise, the phrase "based on" is intended to mean "based, at least in part, on". As used herein, the term "multiple" may be replaced with "multiple (a pluralityof)" and vice versa. Furthermore, as used herein, unless explicitly stated otherwise, the term "or" is intended to be inclusive when used in series and is used interchangeably with "and/or" if used in conjunction with "either" or "only one of".

Claims (25)

1. A device, comprising:

a secure computing environment, comprising:

a hardware root of trust (HRoT) device identifier combining engine (dic) component;

a DICE tier 0 component configured to derive a DICE identity key, wherein the DICE tier 0 component is above the HRoT DICE component in a tier stack; a kind of electronic device with high-pressure air-conditioning system

A DICE layer 1 component configured to derive a DICE alias key based on the DICE identity key, wherein the DICE layer 1 component is above the DICE layer 0 component in the layer stack; a kind of electronic device with high-pressure air-conditioning system

A controller configured to:

receiving an update to firmware of a component of the secure computing environment;

updating the firmware of the component of the secure computing environment based on receiving the update; a kind of electronic device with high-pressure air-conditioning system

One or more keys of the component or one or more keys of one or more components above the component in the layer stack are updated based on updating the firmware.

2. The device of claim 1, wherein the controller is further configured to refrain from updating any keys of one or more components below the component in the layer stack based on updating the firmware.

3. The device of claim 1, wherein the component is the dic layer 0 component; and is also provided with

Wherein the controller is configured to:

the DICE identity key and the DICE alias key are updated based on updating the firmware.

4. The device of claim 1, wherein the component is the dic layer 1 component; and is also provided with

Wherein the controller is configured to:

the DICE alias key is updated based on updating the firmware instead of the DICE identity key.

5. The device of claim 1, wherein the controller is configured to update the dic alias key based on the update to the firmware to generate an updated dic alias key, and

wherein the updated DICE alias key is linked to a signed device identity associated with the DICE identity key.

6. The device of claim 1, wherein the dic alias key is linked to the dic identity key, the dic identity key being linked to a root certificate authority of the HRoT dic component.

7. The apparatus of claim 1, wherein the dic identity key and the dic alias key form at least part of a chain of trust of a set of components of the apparatus.

8. The device of claim 1, wherein the dic layer 1 component is configured to store a device identifier certificate and an alias certificate.

9. The device of claim 8, wherein the device identifier credential is based on the dic identity key.

10. The apparatus of claim 8, wherein the alias certificate is based on the dic identity key and the dic alias key.

11. The device of claim 1, further comprising:

an open firmware component associated with a firmware security descriptor that generates a signed alias certificate based on the firmware security descriptor.

12. A method, comprising:

at a hardware root of trust (HRoT) layer of the device, receiving a command to generate a set of credentials;

generating, at a device identifier combination engine (dic) layer 0 of the device, a device identifier key based on a layer 0 Composite Device Identifier (CDI), wherein the layer 0CDI is a representation of a variable code of layer 0, wherein the device identifier key is a root node of a dic derived chain of the device;

generating, at a DICE tier 1 of the device, an alias key based on a tier 1CDI, wherein the tier 1CDI is a representation of firmware of tier 1, wherein the alias key is a leaf node of the DICE export chain of the device;

generating, at the DICE 1 layer of the device, the set of credentials in response to the command and based on the device identifier key and the alias key; a kind of electronic device with high-pressure air-conditioning system

The set of credentials is stored in a memory of the device to enable the device to provide the set of credentials as a response to another command.

13. The method as in claim 12, further comprising:

determining, at the HRoT layer of the device, the layer 0CDI based on measurements of the dic layer 0 of the device; a kind of electronic device with high-pressure air-conditioning system

At the DICE layer 0 of the device, the device identifier key is generated based on determining the layer 0CDI.

14. The method as in claim 13, further comprising:

reading, at the HRoT layer of the device, a unique device secret from a secure element of a secure computing environment of the device, wherein the secure computing environment includes at least the HRoT layer; a kind of electronic device with high-pressure air-conditioning system

At the HRoT layer of the device, the layer 0CDI is determined based on the unique device secret.

15. The method of claim 12, wherein the device identifier key is part of an asymmetric key pair.

16. The method as in claim 12, further comprising:

determining, at the dic layer 0 of the apparatus, the layer 1CDI based on measurements of the dic layer 1 and the layer 0CDI of the apparatus; a kind of electronic device with high-pressure air-conditioning system

At the DICE layer 1 of the device, the alias key is generated based on determining the layer 1 CDI.

17. The method as in claim 12, further comprising:

at the DICE layer 1 of the device, measuring a firmware security descriptor using a hash function; a kind of electronic device with high-pressure air-conditioning system

At the DICE layer 1 of the device, the alias key is generated based on measuring the firmware security descriptor.

18. The method of claim 12, wherein the alias key is part of an asymmetric key pair.

19. The method as in claim 12, further comprising:

receiving another command to provide at least one of the set of credentials; a kind of electronic device with high-pressure air-conditioning system

At least one of the set of credentials is provided from the memory as a response to another command.

20. A system, comprising:

a memory; a kind of electronic device with high-pressure air-conditioning system

A controller configured to:

generating a layer 0 Composite Device Identifier (CDI) of a device identifier combination engine (dic) layer 0 component using a hardware root of trust (HRoT) component;

generating a DICE identity key using the DICE layer 0 component and based on the layer 0 CDI;

generating an alias key using a DICE layer 1 component and based on the DICE identity key;

Receiving an update to firmware of the DICE layer 1 component;

updating the firmware of the DICE layer 1 component but not updating the firmware of the DICE layer 0 component; a kind of electronic device with high-pressure air-conditioning system

The alias key is regenerated without regenerating the DICE identity key based on updating the firmware of the DICE layer 1 component without updating the firmware of the DICE layer 0 component.

21. The system of claim 20, wherein the controller is configured to generate the alias key based on a layer 1CDI.

22. The system of claim 21, wherein the controller is configured to generate the tier 1CDI based on export of the firmware of the tier 0CDI and the dic tier 1 components.

23. An apparatus, comprising:

means for identifying an update to firmware of a layer 3 device identifier combination engine (dic) architecture device,

wherein the 3-tier DICE architecture means comprises a hardware root of trust (HRoT) tier, a DICE tier 0 configured to store DICE identity keys, and a DICE tier 1 configured to store DICE alias keys,

wherein the order of layers is that the HRoT layer is the lowest layer in the 3-layer dic architecture, the dic layer 0 is the lower layer in the 3-layer dic architecture, and the dic layer 1 is the higher layer in the 3-layer dic architecture; a kind of electronic device with high-pressure air-conditioning system

Means for updating the firmware of the 3-tier dic architecture means, wherein the means for updating the firmware of the 3-tier dic architecture comprises means for updating the firmware of a particular tier such that one or more keys of the particular tier or a tier higher than the particular tier are updated and one or more keys of a tier lower than the particular tier are not updated.

24. The apparatus of claim 23, further comprising:

means for updating the firmware of the DICE tier 1, wherein the update to the firmware of the DICE tier 1 triggers an update to the DICE alias key instead of the DICE identity key.

25. The apparatus of claim 23, further comprising:

means for updating the firmware of the DICE tier 0, wherein the update to the firmware of the DICE tier 0 triggers an update to the DICE identity key but not to the DICE alias key.