Techniques for managing offline identity upgrades

Methods, systems, and devices for techniques for managing offline identity upgrades are described. A memory system may receive a command to update a device identifier for a device identifier composition engine (DICE) associated with the memory system. The memory system may generate an updated device identifier, at a first software layer of a set of software layers of the DICE, based on receiving the command. The memory system may decrypt a device specific key (DSK) stored at a read-only memory device of the memory system based on the received command, and sign the updated device identifier using the DSK based on decrypting the DSK. The memory system may execute one or more operations associated with the first software layer of the set of software layers of the DICE based on the signed updated device identifier.

FIELD OF TECHNOLOGY

The following relates to one or more systems for memory, including techniques for managing offline identity upgrades.

BACKGROUND

Memory devices are widely used to store information in various electronic devices such as computers, user devices, wireless communication devices, cameras, digital displays, and the like. Information is stored by programming memory cells within a memory device to various states. For example, binary memory cells may be programmed to one of two supported states, often corresponding to a logic 1 or a logic 0. In some examples, a single memory cell may support more than two possible states, any one of which may be stored by the memory cell. To access information stored by a memory device, a component may read (e.g., sense, detect, retrieve, identify, determine, evaluate) the state of one or more memory cells within the memory device. To store information, a component may write (e.g., program, set, assign) one or more memory cells within the memory device to corresponding states.

DETAILED DESCRIPTION

A memory device may support various operations and may be operable to receive, transmit, or execute commands, data, or control information related to components of the memory device. The memory device may be configured with a device identifier composition engine (DICE) to enhance secure operations at the memory device for receiving, transmitting, or executing commands, data, or control information related to components of the memory device. For example, the memory device may use the DICE to execute a command to update a firmware associated with the memory device. In some cases, as part of the updating the firmware, the memory device may validate the firmware through a chain of trust (CoT). The CoT may establish a validation for the firmware by verifying a number of certificates (also referred to as digital certificates) associated with the firmware.

The DICE may include multiple software layers (also referred to as DICE layers), including a Layer 0 and a Layer 1. In the CoT, the DICE may be a root of trust (RoT). The RoT associated with the CoT may include a root certificate authority (CA). A root certificate associated with the root CA may be a certificate associated with the CA. The CoT may terminate with the RoT. The root certificate may be signed by the root CA. Each certificate of the number of certificates in the CoT may be signed by an entity identified by a subsequent certificate in the CoT, and each signature of each certificate of the number of certificates in the CoT may be verified up to the root certificate associated with the root CA. As such, from the root certificate, the memory device may verify that a last certificate (also referred to as leaf certificate) in the CoT is trustworthy. A leaf certificate may be an example of a certificate that does not sign other certificates in the CoT.

A device identity (ID) may be associated with the Layer 0 of the DICE. The device ID may be an asymmetric key pair that authenticates a combination of hardware and firmware as described herein. The Layer 0 may be mutable (e.g., changeable). The DICE may use the CoT to associate a device ID certificate to the root CA. The device ID certificate may be signed by a server associated with a manufacturer of the memory device. As described herein, after deployment of the memory device, the memory device may execute a command to update a firmware associated with the memory device. For example, the memory device may execute a command to update the Layer 0 associated with the DICE (e.g., to fix code bugs, or the like). During the update of the Layer 0, the Layer 0 may update (e.g., change) the device ID.

The update to the device ID by the Layer 0 may result in a disruption to the CoT. For example, when the Layer 0 is implemented with mutable code and updated, the device ID key pair may change, and a new self-signed certificate may be generated, disrupting the CoT. As a result, a new device ID certificate might be issued by the root CA to restore the CoT for the memory device. To be issued the new device ID certificate, the memory device may transmit a certificate signing request (CSR) to the server (e.g., associated with the manufacturer of the memory device). However, some original equipment manufacturers (OEMs) may not support issuing of new device IDs to memory devices that experience disrupted CoT. Therefore, it may be desirable to enhance secure operations at the memory device by restoring a CoT at the memory device.

Various aspects of the present disclosure relate to a memory device configured with a set of keys, including a device specific key (DSK) and a device specific wrap key (DSWK) to support restoring a CoT when updating a firmware associated with the memory device. The DSK may be an example of an asymmetric key pair, while the DSWK may be an example of a symmetric key. The memory device may randomly generate the DSK, for example, based on a unique device secret (UDS) associated with the memory device. The UDS may be a statistically unique, device-specific, secret value. The UDS may be generated externally and installed during manufacture or generated internally during device provisioning. The UDS may be stored in nonvolatile memory on the memory device. The DICE may restrict access to the nonvolatile memory storing the UDS, and thereby enhance the security for the CoT. The DSK may also be encrypted using the DSWK. In some examples, a server (e.g., associated with the manufacturer of the memory device) or the memory device, or both, may randomly generate the DSWK and inject it into the memory device. Additionally, the memory device may be configured with a device specific certificate (DSC) to support restoring the CoT when updating the firmware associated with the memory device. The DSC may be shared with the server or a host device, or both, as part of the CoT.

Additionally, the memory device may store the DSK in a ROM, such as a programmable fuse (e.g., an electronic fuse (eFuse) or an anti-fuse), or in a physical unclonable function (PUF) based storage. In some examples, the DSK may be revokable, for example, removed from memory (e.g., eFuse) or storing a revocation flag in a secure storage in case the key is stored in a ROM of the memory device. Additionally, the memory device may retrieve the DSWK from nonvolatile memory, such as ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), ferroelectric random-access memory (FeRAM), magnetic random-access memory (MRAM), phase-change memory (PCM), or a combination thereof. With reference to the above example relating to the update of the firmware associated with the memory device, when the update to the firmware results in an update to the device ID, the memory device may sign the updated device ID using the DSK. For example, the memory device may decrypt the DSK stored in ROM of the memory device using the DSWK, and may sign the device ID certificate using the DSK. As a result, the CoT is uninterrupted.

Features of the disclosure are initially described in the context of systems with reference toFIG.1. Features of the disclosure are described in the context of a DICE architecture, a CoT, and methods with reference toFIGS.2-6. These and other features of the disclosure are further illustrated by and described in the context of an apparatus diagram and flowchart that relate to techniques for managing offline identity upgrades with reference toFIGS.7-9.

FIG.1illustrates an example of a system100that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The system100includes a host system105coupled with a memory system110.

The memory system controller115may be configured for other operations associated with the memory devices130. For example, the memory system controller115may execute or manage operations such as wear-leveling operations, garbage collection operations, error control operations such as error-detecting operations or error-correcting operations, encryption operations, caching operations, media management operations, background refresh, health monitoring, and address translations between logical addresses (e.g., logical block addresses (LBAs)) associated with commands from the host system105and physical addresses (e.g., physical block addresses) associated with memory cells within the memory devices130, or other operations associated with the memory device130, including other memory expansion modules and future expansion modules not explicitly mentioned herein.

The memory system controller115may also include a local memory120. In some cases, the local memory120may include ROM or other memory that may store operating code (e.g., executable instructions) executable by the memory system controller115to perform functions ascribed herein to the memory system controller115. In some cases, the local memory120may additionally or alternatively include static random access memory (SRAM) or other memory that may be used by the memory system controller115for internal storage or calculations, for example, related to the functions ascribed herein to the memory system controller115. Additionally or alternatively, the local memory120may serve as a cache for the memory system controller115. For example, data may be stored in the local memory120if read from or written to a memory device130, and the data may be available within the local memory120for subsequent retrieval for or manipulation (e.g., updating) by the host system105(e.g., with reduced latency relative to a memory device130) in accordance with a cache policy.

In some cases, planes165may refer to groups of blocks170, and in some cases, concurrent operations may take place within different planes165. For example, concurrent operations may be performed on memory cells within different blocks170so long as the different blocks170are in different planes165. In some cases, an individual block170may be referred to as a physical block, and a virtual block180may refer to a group of blocks170within which concurrent operations may occur. For example, concurrent operations may be performed on blocks170-a,170-b,170-c, and170-dthat are within planes165-a,165-b,165-c, and165-d, respectively, and blocks170-a,170-b,170-c, and170-dmay be collectively referred to as a virtual block180. In some cases, a virtual block may include blocks170from different memory devices130(e.g., including blocks in one or more planes of memory device130-aand memory device130-b). In some cases, the blocks170within a virtual block may have the same block address within their respective planes165(e.g., block170-amay be “block0” of plane165-a, block170-bmay be “block0” of plane165-b, and so on). In some cases, performing concurrent operations in different planes165may be subject to one or more restrictions, such as concurrent operations being performed on memory cells within different pages175that have the same page address within their respective planes165(e.g., related to command decoding, page address decoding circuitry, or other circuitry being shared across planes165).

In some cases, to update some data within a block170while retaining other data within the block170, the memory device130may copy the data to be retained to a new block170and write the updated data to one or more remaining pages of the new block170. The memory device130(e.g., the local controller135) or the memory system controller115may mark or otherwise designate the data that remains in the old block170as invalid or obsolete and may update a logical-to-physical (L2P) mapping table to associate the logical address (e.g., LBA) for the data with the new, valid block170rather than the old, invalid block170. In some cases, such copying and remapping may be performed instead of erasing and rewriting the entire old block170due to latency or wear out considerations, for example. In some cases, one or more copies of an L2P mapping table may be stored within the memory cells of the memory device130(e.g., within one or more blocks170or planes165) for use (e.g., reference and updating) by the local controller135or memory system controller115.

In some cases, L2P mapping tables may be maintained and data may be marked as valid or invalid at the page level of granularity, and a page175may contain valid data, invalid data, or no data. Invalid data may be data that is outdated due to a more recent or updated version of the data being stored in a different page175of the memory device130. Invalid data may have been previously programmed to the invalid page175but may no longer be associated with a valid logical address, such as a logical address referenced by the host system105. Valid data may be the most recent version of such data being stored on the memory device130. A page175that includes no data may be a page175that has never been written to or that has been erased.

In some cases, a memory system controller115or a local controller135may perform operations (e.g., as part of one or more media management algorithms) for a memory device130, such as wear leveling, background refresh, garbage collection, scrub, block scans, health monitoring, or others, or any combination thereof. For example, within a memory device130, a block170may have some pages175containing valid data and some pages175containing invalid data. To avoid waiting for all of the pages175in the block170to have invalid data in order to erase and reuse the block170, an algorithm referred to as “garbage collection” may be invoked to allow the block170to be erased and released as a free block for subsequent write operations. Garbage collection may refer to a set of media management operations that include, for example, selecting a block170that contains valid and invalid data, selecting pages175in the block that contain valid data, copying the valid data from the selected pages175to new locations (e.g., free pages175in another block170), marking the data in the previously selected pages175as invalid, and erasing the selected block170. As a result, the quantity of blocks170that have been erased may be increased such that more blocks170are available to store subsequent data (e.g., data subsequently received from the host system105).

In some cases, a memory system110may utilize a memory system controller115to provide a managed memory system that may include, for example, one or more memory arrays and related circuitry combined with a local (e.g., on-die or in-package) controller (e.g., local controller135). An example of a managed memory system is a managed NAND (MNAND) system.

The system100may include any quantity of non-transitory computer readable media that support techniques for managing offline identity upgrades. For example, the host system105(e.g., a host system controller106), the memory system110(e.g., a memory system controller115), or a memory device130(e.g., a local controller135) may include or otherwise may access one or more non-transitory computer readable media storing instructions (e.g., firmware, logic, code) for performing the functions ascribed herein to the host system105, the memory system110, or a memory device130. For example, such instructions, if executed by the host system105(e.g., by a host system controller106), by the memory system110(e.g., by a memory system controller115), or by a memory device130(e.g., by a local controller135), may cause the host system105, the memory system110, or the memory device130to perform associated functions as described herein.

One or both of the host system105or the memory system110may be configured with a DICE to support secure operations at one or both of the host system105or the memory system110. For example, one or both of the host system105or the memory system110may support a DICE architecture as described with reference toFIG.2. An example of an operation at one or both of the host system105or the memory system110may include an update to firmware, software, or hardware, or any combination thereof. For example, one or both of the host system105or the memory system110may receive a command to update a device ID for a DICE associated with one or both of the host system105or the memory system110. One or both of the host system105or the memory system110may generate an updated device ID, at a first software layer (e.g., a Layer 0) of a set of software layers of the DICE.

As part of updating the firmware, one or both of the host system105or the memory system110may validate the firmware through a CoT. To support restoring the CoT when updating the firmware, one or both of the host system105or the memory system110may be configured with a set of keys, including a DSK and a DSWK. As described herein, the DSK may be encrypted using the DSWK. One or both the DSK and DSWK may be specific to one or both of the host system105or the memory system110. Additionally, one or both of the host system105or the memory system110may be configured with a DSC to support restoring the CoT when updating the firmware.

One or both of the host system105or the memory system110may decrypt the DSWK stored in a ROM (e.g., a memory die160or a silicon mask) of the memory system110. One or both of the host system105or the memory system110may then sign the updated device ID using the decrypted DSK. In some examples, one or both of the host system105or the memory system110may sign the DSC using decrypted DSK. One or both of the host system105or the memory system110may proceed to execute the first software layer (e.g., the Layer 0) of the DICE based on the signed updated device ID. By enabling one or both of the host system105or the memory system110to sign a device ID certificate using the DSK, one or both of the host system105or the memory system110may maintain or restore the CoT without requesting an OEM associated with one or both of the host system105or the memory system110to issue a device ID.

FIG.2illustrates an example of a DICE architecture200that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The DICE architecture200may implement or be implemented by aspects of the system100. For example, the DICE architecture200may be implemented by one or both of a host system105or a memory system110as described with reference toFIG.1. The DICE architecture200may include a processor205and a set of software layers, including a first software layer210(referred to as a Layer 0) and a second software layer215(referred to as a Layer 1). These components may be in electronic communication or otherwise coupled (e.g., operatively, communicatively, functionally, electronically, electrically).

The processor205may include an intelligent hardware device (e.g., a central processing unit (CPU) configured as or otherwise supporting a means for performing the functions described herein). In some examples, the processor205and a memory system (not shown) coupled with the processor205may be configured to perform one or more of the functions described herein (for example, by executing, by the processor205, instructions stored in the memory system (not shown)). The processor205may include a UDS212. The first software layer210may include one or more components including an alias key generator220, a device ID key generator225, an alias key certificate generator230, a device ID certificate generator235, and a device ID CSR generator240. In the example ofFIG.2, the first software layer210(i.e., the Layer 0) and the second software layer215(i.e., the Layer 1) may be executable code by the processor205.

The DICE architecture200may support authentication and secure communications at one or both of the host system105or the memory system110. In some examples, the DICE architecture200may support authentication and secure communications at one or both of the host system105or the memory system110using a Secure Protocol and Data Model (SPDM) session, a Transport Level Security (TLS) session, or some combination thereof, using one or more certificates. The DICE architecture200may support hardware-based cryptographic device identity, attestation, and data encryption. The DICE architecture200may support provisioning or generating an asymmetric key pair referred to as device ID keys. OEMs may enable the device ID keys to change (e.g., during remanufacture, or using other cryptographic protocols). The DICE architecture200may also support generating or provisioning other keys, such as alias keys as described herein. In contrast to the device ID credentials, which do not change, new alias keys may be generated with a higher frequency (e.g., more often), such as during an update of a firmware associated with one or both of the host system105or the memory system110.

The processor205may generate and output a compound device identity (CDI)245to the first software layer210(i.e., the Layer 0). In some examples, to generate the CDI245, the processor205may hash the UDS212with a hash of the first software layer210. The CDI245may be a secret value that may be unique to one or both of the host system105or the memory system110. The first software layer210(i.e., the Layer 0) may use the CDI245to generate one or both of private or public keys. The alias key generator220may generate an alias key pair based in part on the CDI245. In some examples, the alias key generator220may generate the alias key pair using a deterministic key generation function. The alias key pair may include an alias public key and an alias private key. The alias key generator220may output one or both of the alias public key or an alias private key to the second software layer215(i.e., the Layer 1). As such, the processor205may link the CDI245to the UDS245, and hash a first mutable code layer (e.g., one or more of the software layers).

Additionally or alternatively, the alias key generator220may generate an alias key pair based in part on a firmware security descriptor (FSD)265. The second software layer215(i.e., the Layer 1) may output the FSD265to the first software layer (i.e., the Layer 0). The FSD265may be a data structure identifying an identity associated with the second software layer215(i.e., the Layer 1). Examples of the FSD265include a firmware image of the second software layer215(i.e., the Layer 1), a firmware version associated with one or both of the first software layer210(i.e., the Layer 0) or the second software layer215(i.e., the Layer 1). In some examples, If the FSD265is invalid or missing, the alias key generator220may abort key generation.

The device ID key generator225may generate an asymmetric device ID key pair based in part on the CDI245. In some examples, the device ID key generator225may generate an asymmetric device ID key pair using a deterministic key generation function. The asymmetric device ID key pair may include a device ID private key and a device ID public key. The device ID key generator225may output the device ID public key to the second software layer215(i.e., the Layer 1). The alias key certificate generator230may generate and output an alias certificate250to the second software layer215(i.e., the Layer 1). In some examples, the alias key certificate generator230may generate the alias certificate250based in part on the alias public key and sign the alias certificate250using the device ID private key. The device ID certificate generator235may generate and output a device ID certificate255to the second software layer215(i.e., the Layer 1). In some examples, the device ID certificate generator235may generate the device ID certificate255based in part on the device ID public key and sign the device ID certificate255using the device ID private key. The device ID CSR generator240may generate the device ID CSR260based in part on the device ID public key and sign the device ID CSR260using the device ID private key.

Accordingly, the DICE architecture200may support secure operations at one or both of the host system105or the memory system110. For example, one or more components of the DICE architecture200may receive a command to update a device ID associated with one or both of the host system105or the memory system110. One or more components of the DICE architecture200may generate an updated device ID, at the first software layer210(e.g., the Layer 0) of the DICE architecture200. As part of updating the firmware, one or more components of the DICE architecture200may validate the firmware through a CoT. To support restoring the CoT when updating the firmware, one or more components of the DICE architecture200may be configured with a set of keys, including a DSK and a DSWK. As described herein, the DSK may be encrypted using the DSWK. One or both the DSK and DSWK may be specific to one or both of the host system105or the memory system110. Additionally, one or more components of the DICE architecture200may be configured with a DSC to support restoring the CoT when updating the firmware.

One or more components of the DICE architecture200may decrypt the DSK of the memory system110. One or more components of the DICE architecture200may then sign the updated device ID using the decrypted DSK. In some examples, one or more components of the DICE architecture200may sign the DSC using decrypted DSK. One or more components of the DICE architecture200may proceed to execute the first software layer210(e.g., the Layer 0) of the DICE architecture200based on the signed updated device ID. By enabling one or more components of the DICE architecture200to sign a device ID certificate using the DSK, the DICE architecture200may maintain or restore the CoT without requesting an OEM associated with one or both of the host system105or the memory system110to issue a device ID.

FIG.3illustrates an example of a CoT method300that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The CoT method300may implement or be implemented by aspects of the system100. For example, the CoT method300may be implemented by one or both of a host system105or a memory system110as described with reference toFIG.1. In some examples, the CoT method300may be implemented by a server305. The server305may be associated with a manufacturer of one or both of the host system105or the memory system110. In some examples, some operations may be omitted from the CoT method300, and other operations may be added to the CoT method300.

The server305may provision a set of devices, including the host system105with a CoT including a sequence of certificates, which embed one or more public keys used to validate them together with a public key of the root CA that acts as an anchor for the CoT. The server305may provision a set of devices, including one or both of the host system105or the memory system110with a root key pair315. Additionally, the server305may provision a set of devices, including one or both of the host system105or the memory system110with a certificate320and a key pair325. In the example ofFIG.3, one or more of the server root CA310, the root key pair315, the certificate320, or the key pair325may be common to the set of devices, including one or both of the host system105or the memory system110.

In the CoT method300, each device of the set of devices may be associated with a respective DSC335and a DSK pair340. For example, a first device may be associated with a first DSC335-aand a first DSK pair340-a, a second device may be associated with a second DSC335-band a second DSK pair340-b, and a third device may be associated with a third DSC335-cand a third DSK pair340-c. Additionally, in the CoT method300, each device of the set of devices may be associated with a respective device ID certificate345and a device ID key pair350. For example, the first device may be associated with a first device ID certificate345-aand a first device ID key pair350-a, a second device may be associated with a second device ID certificate345-band a second device ID key pair350-b, and a third device may be associated with a third device ID certificate345-cand a third device ID key pair350-c. Additionally, in the CoT method300, each device of the set of devices may be associated with a respective alias certificate355and an alias key pair360. For example, the first device may be associated with a first alias certificate355-aand a first alias key pair360-a, a second device may be associated with a second alias certificate355-band a second alias key pair360-b, and a third device may be associated with a third alias certificate355-cand a third alias key pair360-c.

One or more of the respective DSC335, the respective DSK pair340, the respective device ID certificate345, the respective device ID key pair350, the respective alias certificate355, or the alias key pair360may device-specific and downloadable by each device via a SPDM. In the example ofFIG.3, a respective DSC may be stored at each device of the set of devices. Additionally, a respective DSK associated with each device of the set of devices may be stored and encrypted in a secure environment, such as a programmable fuse (e.g., eFuse). The key pair325may be kept within the server boundary of the server305. By enabling one or more operations of the CoT method300to sign a device ID certificate using the DSK, the CoT method300may maintain or restore the CoT without requesting an OEM associated with one or both of the host system105or the memory system110to issue a device ID.

FIG.4illustrates an example of a signing method400that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The signing method400may implement or be implemented by aspects of the system100. For example, the signing method400may be implemented by a memory system110as described with reference toFIG.1. In some examples, the signing method400may be implemented by a server405. The server405may be associated with a manufacturer of the memory system110. In some examples, some operations may be omitted from the signing method400, and other operations may be added to the signing method400. As part of deployment of the memory system110, the server405may sign a device ID certificate associated with the memory system110. In some cases, after deployment of the memory system110, the server405may be unable to sign (or re-sign) the device ID certificate associated with the memory system110.

The memory system110may include immutable ROM410, which may store executable code including one or more keys (e.g., DSK, DWSK, or the like). The memory system110may include a memory. The memory may be a nonvolatile memory, for example, ROM, EPROM, EEPROM, FeRAM, MRAM, PCM, or a combination thereof. Additionally, or alternatively, the memory may be a volatile memory device, for example, a DRAM or a SRAM. The memory system110may be configured with a DICE, including a DICE layer 0415and a DICE layer 1420. The server405may generate a set of certificates including a certificate430, which may be signed by one or more previous certificates including a root certificate associated with a root CA425. The memory system110may be associated with a DSC435, which may sign a device ID certificate440. The device ID certificate440may sign an alias certificate445.

Updating a device ID may disrupt the CoT. For example, the device ID for the DICE system is bound to DICE Layer 0. The DICE system may use the CoT to bind the device ID with the root CA. In such examples, if the device ID is changed, it may break the CoT because the device ID certificate associated with the new device ID may be invalid. For instance, the device ID certificate may be associated with the old device ID and not the new device ID. In many systems, the device ID certificate can be issued by a remote server during a manufacturing process. To ensure secure transmission the device ID certificate may typically be communicated using a direct connection during a manufacturing process. In many instances such a connection is not possible after the product has been deployed. Thus, other solutions for update the CoT for a new device ID in a DICE system may be useful.

In the example ofFIG.4, the memory system110may support maintaining or restoring a CoT by executing one or more operations associated with a certificate chain450. For example, the memory system110may support maintaining or restoring a CoT by signing the device ID certificate440using a DSK as described herein. The memory system110may retrieve the DSK from the memory, which may be a programmable fuse (e.g., eFuse). Additionally, or alternatively, the memory system110may retrieve a DSWK from the memory, which may be a nonvolatile memory, such as a ROM. The memory system110may decrypt the DSK (e.g., a private DSK of the memory system110) using the DSWK. Subsequently, the memory system110may sign the device ID certificate440using the DSK based on decrypting the DSK. By signing the device ID certificate440using the DSK (e.g., a private DSK of the memory system110), the CoT may be conserved.

FIG.5illustrates an example of a method500that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The operations of method500may be implemented by a host system105or a memory system110or components thereof as described herein. For example, the operations of method500may be performed by the host system105or the memory system110as described with reference toFIGS.1-4. In some examples, a host system105or a memory system110may execute a set of instructions to control the functional elements of the host system105or the memory system110to perform the described operations. In some examples, some operations may be performed in a different order than the example order shown, or some operations may be performed in different orders or at different times. In some other examples, some operations may be omitted from the method500, and other operations may be added to the method500.

At505, the host system105or the memory system110may enter a production mode. The production mode may include one or more of manufacturing (e.g., installing, configuration, reconfiguring, uninstalling, and the like of software, firmware, and/or hardware) components associated with the host system105or the memory system110. At510, the host system105or the memory system110may generate a UDS. At515, the host system105or the memory system110may derive a DSK based on the UDS. At520, the host system105or the memory system110may encrypt the DSK using a DSWK. In some examples, the host system105or the memory system110may encrypt the DSK using the DSWK and in accordance with an encryption function. At525, the host system105or the memory system110may store the encrypted DSK in a programmable fuse (e.g., eFuse) of the host system105or the memory system110. At530, the host system105or the memory system110may sign a DSC CSR. At535, the host system105or the memory system110may store the signed DSC. At540, the host system105or the memory system110may be deployed.

FIG.6illustrates an example of a method600that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The operations of method600may be implemented by a host system105or a memory system110or components thereof as described herein. For example, the operations of method600may be performed by the host system105or the memory system110as described with reference toFIGS.1-4. In some examples, a host system105or a memory system110may execute a set of instructions to control the functional elements of the host system105or the memory system110to perform the described operations. In some examples, some operations may be performed in a different order than the example order shown, or some operations may be performed in different orders or at different times. In some other examples, some operations may be omitted from the method500, and other operations may be added to the method600.

At605, the host system105or the memory system110may update a device ID. For example, the host system105or the memory system110may receive a command to update a device identifier for a DICE associated with a memory system. At610, the host system105or the memory system110may reset the host system105or the memory system110. At615, the host system105or the memory system110may execute a ROM code. At620, the host system105or the memory system110may load and validate a DICE Layer 0. At625, the host system105or the memory system110may execute the DICE Layer 0. At630, the host system105or the memory system110may generate a new device ID and store in a nonvolatile memory, for example, ROM, among other examples. At635, the host system105or the memory system110may rest the host system105or the memory system110. At640, the host system105or the memory system110may execute a ROM code. At645, the host system105or the memory system110may load and validate a DICE Layer 0.

At650, the host system105or the memory system110may decrypt a DSK. The DSK may be an asymmetric key. An asymmetric cryptographic process may use a pair of keys (e.g., a public key and a private key) to encrypt and decrypt information and protect the information for unauthorized access or use. For example, a first key may be used to encrypt the information and a second key may be used to decrypt the information. The DSK may be an example of one of the keys of a pair of keys in an asymmetric cryptographic process. In some examples, the DSK may be encrypted using a DSWK as described herein. The DSWK may be a symmetric key used to encrypt and decrypt the DSK as described herein. A symmetric cryptographic process may use a single key to encrypt and decrypt information. At655, the host system105or the memory system110may sign the new device ID. For example, the host system105or the memory system110may sign the new device ID based on the decrypted DSK. At660, the host system105or the memory system110may evict the DSK from volatile memory before additional operations are performed. Ensuring that the DSK is evicted from volatile memory may help protect the DSK from being accessed by unauthorized users. For example, the host system105or the memory system110may evict the DSK from an SRAM associated with the host system105or the memory system110. At665, the host system105or the memory system110may execute the DICE Layer 0. At670, the host system105or the memory system110may continue normal operations.

FIG.7shows a block diagram700of a memory system720that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The memory system720may be an example of aspects of a memory system as described with reference toFIGS.1-6. The memory system720, or various components thereof, may be an example of means for performing various aspects of techniques for managing offline identity upgrades as described herein. For example, the memory system720may include a command component725, a unique secret component730, a secure key storage component735, a signing component740, an operation component745, a certificate component750, a processor component755(e.g., a cryptographic processor component), a memory component760(e.g., a public non-volatile storage component), or any combination thereof. Each of these components may communicate, directly or indirectly, with one another (e.g., via one or more buses).

The command component725(e.g., an I/O controller) may manage input and output signals for the memory system720. In some cases, the command component725may utilize an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS/2®, UNIX®, LINUX®, or another known operating system. In some cases, the command component725may be implemented as part of a processor, such as the processor component755. In some cases, a user may interact with the memory system720via the command component725or via hardware components controlled by the command component725. The command component725may be configured as or otherwise support a means for receiving a command to update a device identifier for a DICE associated with the memory system720. The unique secret component730may be configured as or otherwise support a means for generating an updated device identifier, at a first software layer of a set of software layers of the DICE, based at least in part on receiving the command. The secure key storage component735may be configured as or otherwise support a means for decrypting a DSK stored at a ROM device of the memory system720based at least in part on the received command. The signing component740may be configured as or otherwise support a means for signing the updated device identifier using the DSK based at least in part on decrypting the DSK. The operation component745may be configured as or otherwise support a means for executing one or more operations associated with the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier.

In some examples, the secure key storage component735may be configured as or otherwise support a means for generating the DSK based at least in part on a UDS associated with the memory system720. In some examples, the secure key storage component735may be configured as or otherwise support a means for encrypting the DSK using a DSWK associated with the memory system720. In some examples, the key component735may be configured as or otherwise support a means for decrypting the DSK based at least in part on the DSWK. In some examples, the secure key storage component735may be configured as or otherwise support a means for storing the encrypted DSK in the ROM device of the memory system720, where the ROM device includes a programmable fuse.

In some examples, the DSWK includes a symmetric key used to encrypt and decrypt information. In some examples, the DSWK may be derived based on a UDS. In some examples, the secure key storage component735may be configured as or otherwise support a means for retrieving the DSWK from a nonvolatile memory associated with the memory system720. In some examples, the nonvolatile memory includes ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), ferroelectric random-access memory (FeRAM), magnetic random-access memory (MRAM), phase-change memory (PCM), or a combination thereof.

In some examples, the certificate component750may be configured as or otherwise support a means for receiving a CSR signed by a server associated with the memory system720. In some examples, the signing component740may be configured as or otherwise support a means for signing a DSC based at least in part on the received CSR. In some examples, the signing component740may be configured as or otherwise support a means for signing the updated device identifier using the DSK based at least in part on signing the DSC. In some examples, to support signing the DSC, the signing component740may be configured as or otherwise support a means for signing the DSC using the decrypted DSK. In some examples, the certificate component750may be configured as or otherwise support a means for storing the signed DSC in a nonvolatile memory associated with the memory system720. In some examples, the nonvolatile memory includes ROM, EPROM, EEPROM, FeRAM, MRAM, PCM, or a combination thereof.

In some examples, the DSK includes an asymmetric key pair. In some examples, the secure key storage component735may be configured as or otherwise support a means for removing the DSK from a volatile memory device of the memory system720based at least in part on signing the updated device identifier using the decrypted DSK. In some examples, the operation component745may be configured as or otherwise support a means for executing the one or more operations associated with the first software layer of the DICE in response to removing the DSK from the volatile memory device. In some examples, the volatile memory device includes dynamic random-access memory (DRAM) or static random access memory (SRAM), or both.

In some examples, the unique secret component730may be configured as or otherwise support a means for generating an updated device identifier at a first software layer of a set of software layers of a DICE associated with the memory system720. In some examples, the signing component740may be configured as or otherwise support a means for signing the updated device identifier using a DSK stored at a ROM device of the memory system720. In some examples, the operation component745may be configured as or otherwise support a means for executing the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier.

In some examples, the secure key storage component735may be configured as or otherwise support a means for generating the DSK based at least in part on a UDS associated with the memory system720. In some examples, the secure key storage component735may be configured as or otherwise support a means for encrypting the DSK using a DSWK associated with the memory system720. In some examples, the secure key storage component735may be configured as or otherwise support a means for decrypting the DSK based at least in part on the DSWK. In some examples, the DSWK includes a symmetric key used to encrypt and decrypt information, and the DSWK may be derived based on a UDS. In some examples, the secure key storage component735may be configured as or otherwise support a means for retrieving the DSWK from a nonvolatile memory associated with the memory system720. In some examples, the nonvolatile memory includes ROM, EPROM, EEPROM, FeRAM, MRAM, PCM, or a combination thereof.

The processor component755may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a CPU, a microcontroller, an ASIC, an FPGA, a programmable logic device, a discrete gate or transistor logic component, a discrete hardware component, or any combination thereof). In some cases, the processor component755may be configured to operate a memory array using a memory controller. In some other cases, a memory controller may be integrated into the processor component755. The processor component755may be configured to execute computer-readable instructions stored in a memory (e.g., the memory component760) to cause the memory system720to perform various functions (e.g., functions or tasks supporting managing offline identity upgrades).

The memory component760may include RAM and ROM. The memory component760may store computer-readable, computer-executable code including instructions that, when executed by the processor component755, cause the memory system720to perform various functions described herein. The code may be stored in a non-transitory computer-readable medium such as system memory or another type of memory. In some cases, the code may not be directly executable by the processor component755but may cause a computer (e.g., when compiled and executed) to perform functions described herein. In some cases, the memory component760may contain, among other things, a basic I/O system (BIOS) which may control basic hardware or software operation such as the interaction with peripheral components or devices.

FIG.8shows a flowchart illustrating a method800that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The operations of method800may be implemented by a memory system or its components as described herein. For example, the operations of method800may be performed by a memory system as described with reference toFIGS.1-7. In some examples, a memory system may execute a set of instructions to control the functional elements of the device to perform the described functions. Additionally, or alternatively, the memory system may perform aspects of the described functions using special-purpose hardware.

At805, the method may include receiving a command to update a device identifier for a DICE associated with a memory system. The operations of805may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of805may be performed by a command component725as described with reference toFIG.7.

At810, the method may include generating an updated device identifier, at a first software layer of a set of software layers of the DICE, based at least in part on receiving the command. The operations of810may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of810may be performed by a unique secret component730as described with reference toFIG.7.

At815, the method may include decrypting a DSK stored at a ROM device of the memory system based at least in part on the received command. The operations of815may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of815may be performed by a secure key storage component735as described with reference toFIG.7.

At820, the method may include signing the updated device identifier using the DSK based at least in part on decrypting the DSK. The operations of820may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of820may be performed by a signing component740as described with reference toFIG.7.

At825, the method may include executing one or more operations associated with the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier. The operations of825may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of825may be performed by an operation component745as described with reference toFIG.7.

In some examples, an apparatus as described herein may perform a method or methods, such as the method800. The apparatus may include features, circuitry, logic, means, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor), or any combination thereof for performing the following aspects of the present disclosure:Aspect 1: A method, apparatus, or non-transitory computer-readable medium including operations, features, circuitry, logic, means, or instructions, or any combination thereof for receiving a command to update a device identifier for a DICE associated with a memory system; generating an updated device identifier, at a first software layer of a set of software layers of the DICE, based at least in part on receiving the command; decrypting a DSK stored at a ROM device of the memory system based at least in part on the received command; signing the updated device identifier using the DSK based at least in part on decrypting the DSK; and executing one or more operations associated with the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier.Aspect 2: The method, apparatus, or non-transitory computer-readable medium of aspect 1, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for generating the DSK based at least in part on a UDS associated with the memory system.Aspect 3: The method, apparatus, or non-transitory computer-readable medium of any of aspects 1 through 2, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for encrypting the DSK using a DSWK associated with the memory system and where decrypting the DSK is based at least in part on the DSWK.Aspect 4: The method, apparatus, or non-transitory computer-readable medium of aspect 3, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for storing the encrypted DSK in the ROM device of the memory system, where the ROM device includes a programmable fuse.Aspect 5: The method, apparatus, or non-transitory computer-readable medium of any of aspects 3 through 4 where the DSWK includes a symmetric key used to encrypt and decrypt information, and the DSWK is derived based at least in part on a UDS.Aspect 6: The method, apparatus, or non-transitory computer-readable medium of any of aspects 3 through 5, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for retrieving the DSWK from a nonvolatile memory associated with the memory system and where the nonvolatile memory includes ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), ferroelectric random-access memory (FeRAM), magnetic random-access memory (MRAM), phase-change memory (PCM), or a combination thereofAspect 7: The method, apparatus, or non-transitory computer-readable medium of any of aspects 3 through 6, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for receiving a CSR; signing a DSC based at least in part on the received CSR signed by a server associated with the memory system; and where signing the updated device identifier using the DSK is further based at least in part on signing the DSC.Aspect 8: The method, apparatus, or non-transitory computer-readable medium of aspect 7 where signing the DSC includes operations, features, circuitry, logic, means, or instructions, or any combination thereof for signing the DSC using the decrypted DSK.Aspect 9: The method, apparatus, or non-transitory computer-readable medium of any of aspects 7 through 8, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for storing the signed DSC in a nonvolatile memory associated with the memory system and where the nonvolatile memory includes ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), ferroelectric random-access memory (FeRAM), magnetic random-access memory (MRAM), phase-change memory (PCM), or a combination thereofAspect 10: The method, apparatus, or non-transitory computer-readable medium of any of aspects 1 through 9 where the DSK includes an asymmetric key.Aspect 11: The method, apparatus, or non-transitory computer-readable medium of any of aspects 1 through 10, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for removing the DSK from a volatile memory device of the memory system based at least in part on signing the updated device identifier using the decrypted DSK and where executing the one or more operations associated with the first software layer of the DICE occurs in response to removing the DSK from the volatile memory device.Aspect 12: The method, apparatus, or non-transitory computer-readable medium of aspect 11 where the volatile memory device includes DRAM or SRAM, or both.

FIG.9shows a flowchart illustrating a method900that supports techniques for managing offline identity upgrades in accordance with examples as disclosed herein. The operations of method900may be implemented by a memory system or its components as described herein. For example, the operations of method900may be performed by a memory system as described with reference toFIGS.1-7. In some examples, a memory system may execute a set of instructions to control the functional elements of the device to perform the described functions. Additionally, or alternatively, the memory system may perform aspects of the described functions using special-purpose hardware.

At905, the method may include generating an updated device identifier at a first software layer of a set of software layers of a DICE associated with a memory system. The operations of905may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of905may be performed by a unique secret component730as described with reference toFIG.7.

At910, the method may include signing the updated device identifier using a DSK stored at a ROM device of the memory system. The operations of910may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of910may be performed by a signing component740as described with reference toFIG.7.

At915, the method may include executing the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier. The operations of915may be performed in accordance with examples as disclosed herein. In some examples, aspects of the operations of915may be performed by an operation component745as described with reference toFIG.7.

In some examples, an apparatus as described herein may perform a method or methods, such as the method900. The apparatus may include features, circuitry, logic, means, or instructions (e.g., a non-transitory computer-readable medium storing instructions executable by a processor), or any combination thereof for performing the following aspects of the present disclosure:Aspect 13: A method, apparatus, or non-transitory computer-readable medium including operations, features, circuitry, logic, means, or instructions, or any combination thereof for generating an updated device identifier at a first software layer of a set of software layers of a DICE associated with a memory system; signing the updated device identifier using a DSK stored at a ROM device of the memory system; and executing the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier.Aspect 14: The method, apparatus, or non-transitory computer-readable medium of aspect 13, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for generating the DSK based at least in part on a UDS associated with the memory system.Aspect 15: The method, apparatus, or non-transitory computer-readable medium of any of aspects 13 through 14, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for encrypting the DSK using a DSWK associated with the memory system and decrypting the DSK is based at least in part on the DSWK.Aspect 16: The method, apparatus, or non-transitory computer-readable medium of aspect 15 where the DSWK includes a symmetric key used to encrypt and decrypt information, and the DSWK is derived based at least in part on a UDS.Aspect 17: The method, apparatus, or non-transitory computer-readable medium of any of aspects 15 through 16, further including operations, features, circuitry, logic, means, or instructions, or any combination thereof for retrieving the DSWK from a nonvolatile memory associated with the memory system and where the nonvolatile memory includes ROM, EPROM, EEPROM, FeRAM, MRAM, PCM, or a combination thereof.

An apparatus is described. The following provides an overview of aspects of the apparatus as described herein:Aspect 18: An apparatus, including: a memory system; and a controller coupled with the memory system and configured to: receive a command to update a device identifier for a DICE associated with the memory system; generate an updated device identifier, at a first software layer of a set of software layers of the DICE, based at least in part on receiving the command; decrypt a DSK stored at a ROM device of the memory system based at least in part on the received command; sign the updated device identifier using the DSK based at least in part on decrypting the DSK; and execute one or more operations associated with the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier.Aspect 19: The apparatus of aspect 18, where the controller is further configured to: generate the DSK based at least in part on a UDS associated with the memory system.Aspect 20: The apparatus of any of aspects 18 through 19, where the controller is further configured to: encrypt the DSK using a DSWK associated with the memory system, where to decrypt the DSK is further based at least in part on the DSWK.Aspect 21: The apparatus of aspect 20, where the controller is further configured to: store the encrypted DSK in the ROM device of the memory system, where the ROM device includes a programmable fuse.Aspect 22: The apparatus of any of aspects 20 through 21, where the DSWK includes a symmetric key used to encrypt and decrypt information, and the DSWK is derived based at least in part on a UDS.Aspect 23: The apparatus of any of aspects 20 through 22, where the controller is further configured to: retrieve the DSWK from a nonvolatile memory associated with the memory system, where the nonvolatile memory includes ROM, EPROM, EEPROM, FeRAM, MRAM, PCM, or a combination thereofAspect 24: The apparatus of any of aspects 20 through 23, where the controller is further configured to: receive a CSR signed by a server associated with the memory system; and sign a DSC based at least in part on the received CSR, where to sign the updated device identifier using the DSK is further based at least in part on signing the DSC.Aspect 25: The apparatus of aspect 24, where, to sign the DSC, the controller is configured to: sign the DSC using the decrypted DSK.Aspect 26: The apparatus of any of aspects 24 through 25, where the controller is further configured to: store the signed DSC in a nonvolatile memory associated with the memory system, where the nonvolatile memory includes ROM, EPROM, EEPROM, FeRAM, MRAM, PCM, or a combination thereofAspect 27: The apparatus of any of aspects 18 through 26, where the DSK includes an asymmetric key.Aspect 28: The apparatus of any of aspects 18 through 27, where the controller is further configured to: remove the DSK from a volatile memory device of the memory system based at least in part on signing the updated device identifier using the decrypted DSK, where to execute the one or more operations associated with the first software layer of the set of software layers of the DICE occurs in response to removing the DSK from the volatile memory device.Aspect 29: The apparatus of aspect 28, where the volatile memory device includes DRAM or SRAM, or both.

An apparatus is described. The following provides an overview of aspects of the apparatus as described herein:Aspect 30: An apparatus, including: a memory system; and a controller coupled with the memory system and configured to: generate an updated device identifier, at a first software layer of a set of software layers of a DICE associated with the memory system; sign the updated device identifier using a DSK stored at a ROM device of the memory system; and execute one or more operations associated with the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier.Aspect 31: The apparatus of aspect 30, where the controller is further configured to: generate the DSK based at least in part on a UDS associated with the memory system.Aspect 32: The apparatus of any of aspects 30 through 31, where the controller is further configured to: encrypt the DSK using a DSWK associated with the memory system; and decrypt the DSK based at least in part on the DSWK.Aspect 33: The apparatus of aspect 32, where the DSWK includes a symmetric key used to encrypt and decrypt information, and the DSWK is derived based at least in part on a UDS.Aspect 34: The apparatus of any of aspects 32 through 33, where the controller is further configured to: retrieve the DSWK from a nonvolatile memory associated with the memory system, where the nonvolatile memory includes ROM, EPROM, EEPROM, FeRAM, MRAM, PCM, or a combination thereof.

An apparatus is described. The following provides an overview of aspects of the apparatus as described herein:Aspect 35: An apparatus, including: a memory system; a DICE coupled with the memory system, the DICE including a set of software layers; and a controller coupled with the DICE, the controller configured to: receive a command to update a device identifier for a DICE associated with the memory system; generate an updated device identifier, at a first software layer of the set of software layers of the DICE, based at least in part on receiving the command; decrypt a DSK stored at a ROM device of the memory system based at least in part on the received command; sign the updated device identifier using the DSK based at least in part on decrypting the DSK; and execute one or more operations associated with the first software layer of the set of software layers of the DICE based at least in part on the signed updated device identifier.