Patent Publication Number: US-2022224550-A1

Title: Verification of identity using a secret key

Description:
RELATED APPLICATIONS 
     The present application is a continuation application of U.S. patent application Ser. No. 16/363,196, filed Mar. 25, 2019, the entire disclosure of which application is hereby incorporated herein by reference. 
     This application is related to U.S. Non-Provisional application Ser. No. 15/970,660, filed May 3, 2018, entitled “Key Generation and Secure Storage in a Noisy Environment,” by Pisasale et al., the entire contents of which application is incorporated by reference as if fully set forth herein. 
     This application is related to U.S. Non-Provisional application Ser. No. 15/853,498, filed Dec. 22, 2017, entitled “PHYSICAL UNCLONABLE FUNCTION USING MESSAGE AUTHENTICATION CODE,” by Mondello et al., the entire contents of which application is incorporated by reference as if fully set forth herein. 
     This application is related to U.S. Non-Provisional application Ser. No. 15/965,731, filed 27 Apr. 2018, entitled “SECURE DISTRIBUTION OF SECRET KEY USING A MONOTONIC COUNTER,” by Mondello et al., the entire contents of which application is incorporated by reference as if fully set forth herein. 
    
    
     FIELD OF THE TECHNOLOGY 
     At least some embodiments disclosed herein relate to identity verification in general and more particularly, but not limited to verification of identity using a secret key. 
     BACKGROUND 
     A physical unclonable function (PUF) provides, for example, a digital value that can serve as a unique identity for a semiconductor device, such as a microprocessor. PUFs are based, for example, on physical variations which occur naturally during semiconductor manufacturing, and which permit differentiating between otherwise identical semiconductor chips. 
     PUFs are typically used in cryptography. A PUF can be, for example, a physical entity that is embodied in a physical structure. PUFs are often implemented in integrated circuits, and are typically used in applications with high security requirements. For example, PUFs can be used as a unique and untamperable device identifier. PUFs can also be used for secure key generation, and as a source of randomness. 
     In one example related to device identification, the Microsoft® Azure® IoT platform is a set of cloud services provided by Microsoft. The Azure® IoT platform supports Device Identity Composition Engine (DICE) and many different kinds of Hardware Security Modules (HSMs). DICE is an upcoming standard at Trusted Computing Group (TCG) for device identification and attestation which enables manufacturers to use silicon gates to create device identification based in hardware. HSMs are used to secure device identities and provide advanced functionality such as hardware-based device attestation and zero touch provisioning. 
     DICE offers a scalable security framework that uses an HSM footprint to anchor trust for use in building security solutions like authentication, secure boot, and remote attestation. DICE is useful for the current environment of constraint computing that characterizes IoT devices, and provides an alternative to more traditional security framework standards like the Trusted Computing Group&#39;s (TCG) and Trusted Platform Module (TPM). The Azure® IoT platform has HSM support for DICE in HSMs from some silicon vendors. 
     In one example related to trust services, the Robust Internet-of-Things (RIoT) is an architecture for providing trust services to computing devices. The trust services include device identity, attestation, and data integrity. The RIoT architecture can be used to remotely re-establish trust in devices that have been compromised by malware. Also, RIoT services can be provided at low cost on even very small devices. 
     Improving security techniques have created a need for more frequent software updates to products in the field. However, these updates must be administered and verified without human involvement. RIoT can be used to address these technical problems. 
     RIoT provides a foundation for cryptographic operations and key management for many security scenarios. Authentication, integrity verification, and data protection require cryptographic keys to encrypt and decrypt, as well as mechanisms to hash and sign data. Most internet-connected devices also use cryptography to secure communication with other devices. 
     The cryptographic services provided by RIoT include device identity, data protection, and attestation. Regarding device identity, devices typically authenticate themselves by proving possession of a cryptographic key. If the key associated with a device is extracted and cloned, then the device can be impersonated. 
     Regarding data protection, devices typically use cryptography to encrypt and integrity protect locally stored data. If the cryptographic keys are only accessible to authorized code, then unauthorized software is not be able to decrypt or modify the data. 
     Regarding attestation, devices sometimes need to report code they are running and their security configuration. For example, attestation is used to prove that a device is running up-to-date code. 
     If keys are managed in software alone, then bugs in software components can result in key compromise. For software-only systems, the primary way to restore trust following a key compromise is to install updated software and provision new keys for the device. This is time consuming for server and mobile devices, and not possible when devices are physically inaccessible. 
     Some approaches to secure remote re-provisioning use hardware-based security. Software-level attacks can allow hackers to use hardware-protected keys but not extract them, so hardware-protected keys are a useful building block for secure reprovisioning of compromised systems. The Trusted Platform Module, or TPM, is an example of security module that provides hardware protection for keys, and also allows the device to report (attest to) the software it is running. Thus, a compromised TPMequipped device can be securely issued new keys, and can provide attestation reports. 
     TPMs are widely available on computing platforms (e.g., using SoCintegrated and processor-mode-isolated firmware TPMs). However, TPMs are often impractical. For example, a small IoT device is not be able to support a TPM without substantial increase in cost and power needs. 
     RIoT can be used to provide device security for small computing devices, but it can also be applied to any processor or computer system. If software components outside of the RIoT core are compromised, then RIoT provides for secure patching and re-provisioning. RIoT also uses a different approach to cryptographic key protection. The most-protected cryptographic keys used by the RIoT framework are only available briefly during boot. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The embodiments are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements. 
         FIG. 1  shows a host device that verifies the identity of a computing device, according to one embodiment. 
         FIG. 2  shows an example computing system having an identity component and a verification component, according to one embodiment. 
         FIG. 3  shows an example computing device of a vehicle, according to one embodiment. 
         FIG. 4  shows an example host device communicating with an example computing device of a vehicle, according to one embodiment. 
         FIG. 5A  shows an application board that generates an identifier, certificate, and key for a host device, according to one embodiment. 
         FIG. 5B  shows an example computing system booting in stages using layers, according to one embodiment. 
         FIG. 6  shows an example computing device generating an identifier, certificate, and key using asymmetric generators, according to one embodiment. Note 
         FIG. 7  shows a verification component that verifies the identity of a computing device using decryption operations, according to one embodiment. 
         FIG. 8  shows a block diagram of an example process to verify a certificate, according to one embodiment. 
         FIG. 9  shows a method to verify an identity of a computing device using an identifier, certificate, and a key, according to one embodiment. 
         FIG. 10  shows a system for generating a unique key from an output of a message authentication code (MAC) that receives an input from a physical unclonable function (PUF) device, according to one embodiment. 
         FIG. 11  shows a system for generating a unique key from an output of a MAC that receives inputs from one or more PUF devices selected by a selector module, according to one embodiment. 
         FIG. 12  shows a system for generating a unique key from an output of a MAC that receives inputs from one or more PUF devices and an input from a monotonic counter (and/or an input from another freshness mechanism like NONCE, time-stamp, etc.), according to one embodiment. 
         FIG. 13  shows a method to generate an output from a MAC that uses one or more input values provided from one or more PUFs, according to one embodiment. 
         FIG. 14  shows a system for generating a root key from an output of a MAC that receives inputs from one or more PUF devices and an input from a monotonic counter (and/or an input from another freshness mechanism like NONCE, time-stamp, etc.), and that adds an additional MAC to generate a session key, according to one embodiment. 
         FIG. 15  shows a computing device for storing an obfuscated key in nonvolatile memory, according to one embodiment. 
         FIG. 16  shows an example of an intermediate key generated during an obfuscation process, according to one embodiment. 
         FIG. 17  shows an example of another intermediate key generated during the obfuscation process of  FIG. 16 , according to one embodiment. 
         FIG. 18  shows a method for generating and storing an obfuscated key in a non-volatile memory, according to one embodiment. 
         FIG. 19  shows a computing device for generating an initial key based on key injection, obfuscating the initial key, and storing the obfuscated key in non-volatile memory, according to one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     At least some embodiments herein relate to verification of identity for one or more computing devices. In various embodiments, a host device verifies the identity of a computing device by sending a message to the computing device. The computing device uses the message to generate an identifier, a certificate, and a key, which are sent to the host device. The host device uses the generated identifier, certificate, and key to verify the identity of the computing device. 
     In some examples, the computing device can be a flash memory device. In some examples, flash memory is leveraged to add a strong level of security capability in a computing system (e.g., an application controller of an autonomous vehicle). 
     Flash memory is used in numerous computer systems. Various types of flash memory exist today, including serial NOR, parallel NOR, serial NAND, parallel NAND, e.MMC, UFS, etc. These sockets are used in most embedded systems across various industries and applications. 
     For example, serial NOR is used in a wide array of applications like medical devices, factory automation boards, automotive ECUs, smart meters, and internet gateways. Given diversity of chipset architectures (processors, controllers or SoCs), operating systems, and supply chains used across these applications, flash memory is a common denominator building block in these systems. 
     Computer system resilience today is typically characterized by the location of roots of trust integrated into devices and leveraged by the solution for the security functions they provide. For more information on roots of trust, see the definition created by the National Institute of Technology (NIST) in Special Publication 800-164. Existing industry uses varied implementations of roots of trust at the system level, using a mix of hardware and software capabilities, resulting in the technical problems of fragmentation of approaches and confusing level of security. This perplexing array of options also suffers from the key limitation of how to defend the non-volatile memory where critical code and data is stored. 
     Existing approaches rely on the processor and other secure elements like hardware security modules (HSMs) to offer critical security services to their systems. This has created a security gap at the lowest levels of boot in many systems where discrete flash memory components store system-critical code and data. The flash has become the target for many hackers to create Advanced Persistent Threats (APT&#39;s) that can mask themselves from higher levels of code and resist removal. In many of these cases, flash memory is re-imaged or rewritten with new malicious code, which undermines the integrity of that device. 
     Various embodiments of the present disclosure provide a technological solution to the above technical problems. In some embodiments, a computing device integrates hardware-based roots of trust into a flash memory device, enabling strong cryptographic identity and health management for IoT devices. By moving essential security primitives in-memory, it becomes simpler to protect the integrity of code and data housed within the memory itself. This approach can significantly enhance system level security while minimizing the complexity and cost of implementations. 
     In one embodiment, a new IoT device management capability leverages flash memory by enabling device onboarding and management by the Microsoft® Azure® IoT cloud using flash memory and associated software. In one example, the solutions provide a cryptographic identity that becomes the basis for critical device provisioning services (e.g., the Azure IoT Hub Device Provisioning Service (DPS)). In one example, this DPS along with the enabled memory can enable zero-touch provisioning of devices to the correct IoT hub as well as other services. 
     In some embodiments, to implement the above capability, the Device Identity Composition Engine (DICE) is used (DICE is an upcoming standard from the Trusted Computing Group (TCG)). In one example, the enabled memory permits only trusted hardware to gain access to the Microsoft Azure IoT cloud. In one example, the health and identity of an IoT device is verified in memory where critical code is typically stored. The unique identity of each IoT device can now offer end-to-end device integrity at a new level, starting at the boot process. This can enable additional functionality like hardware-based device attestation and provisioning as well as administrative remediation of the device if necessary. 
     In one embodiment, a method includes: receiving, by a computing device (e.g., a serial NOR flash memory device), a message from a host device (e.g., a CPU, GPU, FPGA, or an application controller of a vehicle); generating, by the computing device, an identifier (e.g., a public identifier IDL 1  public), a certificate (e.g., IDL 1  certificate), and a key (e.g., KL 1  public), wherein the identifier is associated with an identity of the computing device, and the certificate is generated using the message; and sending, by the computing device, the identifier, the certificate, and the key to the host device, wherein the host device is configured to verify the identity of the computing device using the identifier, the certificate, and the key. 
     In some embodiments, the computing device above (e.g., a flash memory device) integrates DICE-RIoT functionality, which is used to generate the identifier, certificate, and key described above and used by the host device to verify the identity of the computing device. In one example, the computing device stores a device secret that acts a primitive key on which the sequence of identification steps between layers of the DICE-RIoT protocol is based. In one example, layers L 0  and L 1  of the DICE-RIoT functionality are implemented in the computing device using hardware and/or software. In one example, layer L 0  is implemented solely in hardware. 
       FIG. 1  shows a host device  151  that verifies the identity of a computing device  141 , according to one embodiment. Host device  151  sends a message to the computing device  141 . In one embodiment, host device  151  includes a freshness mechanism (not shown) that generates a freshness for use in sending messages to the computing device  141  to avoid replay attacks. In one example, each message sent to the computing device  141  includes a freshness generated by a monotonic counter. 
     In one example, the message is an empty string, a conventional known string (e.g., alphanumeric string known to the manufacturer or operator of host device  151 ), or can be another value (e.g., an identity value assigned to the computing device). In one example, the message is a unique identity of the device (UID). 
     In response to receiving the message, computing device  141  generates an identifier, a certificate, and a key. The identifier is associated with an identity of the computing device  141 . Computing device  141  includes one or more processors  143  that control the operation of identity component  147  and/or other functions of computing device  141 . 
     The identifier, the certificate, and the key are generated by identity component  147  and are based on device secret  149 . In one example, device secret  149  is a unique device secret (UDS) stored in memory of computing device  141 . In one example, identity component  147  uses the UDS as a primitive key for implementation of the DICE-RIoT protocol. The identifier, certificate, and key are outputs from layer L 1  of the DICE-RIoT protocol (see, e.g.,  FIG. 6 ). In one embodiment, the identity of layer L 1  corresponds to the identity of computing device  141  itself, the manufacturer of computing device  141 , the manufacturer of a thing that includes computing device  141  as component, and/or an application or other software stored in memory of computing device  141 . In one example, the application identity (e.g., an ID number) is for a mobile phone, a TV, an STB, etc., for which a unique combination of characters and numbers is used to identify the thing. 
     In one example, the identity of layer L 1  is an ASCII string. For example, the identity can be a manufacturer name concatenated with a thing name (e.g., LG | TV_model_123_year_2018, etc.). In one example, the identity can be represented in hexadecimal form (e.g., 53 61 6D 73 75 6E 67 20 7C 20 54 56 5F 6D 6F 64 65 6C 5F 31 32 33 5F 79 65 61 72 5F 32 30 31 38). 
     In one embodiment, a manufacturer can use a UDS for a class or set of items that are being produced. In other embodiments, each item can have its own unique UDS. For example, the UDS for a TV can be UDS=0x12234 . . . 4444, and the UDS for a laptop can be UDS=0xaabb . . . 00322. 
     In one embodiment, the device secret  149  is a secret key stored by computing device  141  in memory  145 . Identity component  147  uses the secret key as an input to a message authentication code (MAC) to generate a derived secret. In one example, the derived secret is fused derived secret (FDS) in the DICE-RIoT protocol. 
     In one example, memory  145  includes read-only memory (ROM) that stores initial boot code for booting computing device  141 . The FDS is a key provided to the initial boot code by processor  143  during a booting operation. In one example, the ROM corresponds to layer L 0  of the DICE-RIoT protocol. 
     Host device  151  uses the identifier, certificate, and key as inputs to a verification component  153 , which verifies the identity of the computing device  141 . In one embodiment, verification component  153  performs at least one decryption operation using the identifier to provide a result. The result is compared to the key to determine whether the identity of the computer device  141  is valid. If so, host device  151  performs further communications with computing device  141  using the key received from computing device  141 . For example, once host device  151  verifies the “triple” (the identifier, certificate, and key), the key can be used to attest any other information exchanged between computing device  141  and host device  151 . 
     In one embodiment, a digital identification is assigned to numerous “things” (e.g., as per the Internet of Things). In one example, the thing is a physical object such as a vehicle or a physical item present inside the vehicle. In one example the thing is a person or animal. For example, each person or animal can be assigned a unique digital identifier. 
     In some cases, manufacturers of products desire that each product can be proved as being genuine. Presently, this problem is solved by buying things only from a trusted seller, or buying things from others with some kind of legal certificate that ensures the thing purchased is genuine. However, in the case of theft of a thing, if the thing does not have an electronic identity, it is difficult to block or localize the thing so that the thing is not used improperly. In one example, localization is based on identity when the thing tries to interact with public infrastructures. In one example, blocking is based on the inability to prove the identity of a thing that wants to use a public infrastructure. 
     In one embodiment, computing device  141  implements the DICE-RIoT protocol using identity component  147  in order to associate unique signatures to a chain of trust corresponding to computing device  141 . Computing device  141  establishes layers L 0  and L 1 . The chain of trust is continued by host device  151  which establishes layers L 2 , . . . . In one example, a unique identifier can be assigned to every object, person, and animal in any defined environment (e.g., a trust zone defined by geographic parameters). 
     In one embodiment, computing device  141  is a component in the thing that is desired to be assigned an identity. For example, the thing can be an autonomous vehicle including computing device  141 . For example, computing device  141  can be flash memory that is used by an application controller of the vehicle. 
     When the computing device  141  is manufactured, the manufacturer can inject a UDS into memory  145 . In one example, the UDS can be agreed to and shared with a customer that will perform additional manufacturing operations using computing device  141 . In another example, the UDS can be generated randomly by the original manufacturer and then communicated to the customer using a secure infrastructure (e.g., over a network such as the internet). 
     In one example, the customer can be a manufacturer of a vehicle that incorporates computing device  141 . In many cases, the vehicle manufacturer desires to change the UDS so that it is unknown to the seller of computing device  141 . In such cases, the customer can replace the UDS using an authenticated replace command that is provided by host device  151  to computing device  141 . 
     In some embodiments, the customer can inject customer immutable information into memory  145  of computing device  141 . In one example, the immutable info is used to generate a unique FDS, and is not solely used as a differentiator. The customer immutable information is used to differentiate various objects that are manufactured by the customer. For example, customer immutable information can be a combination of letters and/or numbers to define primitive information (e.g., a combination of some or all of the following information: date, time, lot position, wafer position, x, y location in a wafer, etc.). 
     For example, in many cases, the immutable information also includes data from cryptographic feature configuration performed by a user (e.g., a customer who receives a device from a manufacturer). This configuration or setting can be done only by using authenticated commands (commands that need the knowledge of a key to be executed). The user has knowledge of the key (e.g., based on being provided the key over a secure infrastructure from the manufacturer). The immutable information represents a form of cryptographic identity of a computing device, which is different from the unique ID (UID) of the device. In one example, the inclusion of the cryptographic configuration in the immutable set of information provides the user with a tool useful to self-customize the immutable information. 
     In one embodiment, computing device  141  includes a freshness mechanism that generates a freshness. The freshness can be provided with the identifier, certificate, and key when sent to host device  151 . The freshness can also be used with other communications with host device  151 . 
     In one embodiment, computing device  141  is a component on an application board. Another component (not shown) on the application board can verify the identity of computing device  141  using knowledge of device secret  149  (e.g., knowledge of an injected UDS). The component requests that computing device  141  generate an output using a message authentication code in order to prove possession of the UDS. For example, the message authentication code can be as follows: HMAC (UDS, “application board message | freshness”). 
     In another embodiment, the FDS can also be used as criteria to prove the possession of the device (e.g., the knowledge of the secret key(s)). The FDS is derived from the UDS in this way: FDS=HMAC-SHA256 [UDS, SHA256(“Identity of L 1 ”)]. So, the message authentication code can be as follows: HMAC (FDS, “application board message | freshness”). 
       FIG. 2  shows an example computing system having an identity component  107  and a verification component  109 , according to one embodiment. A host system  101  communicates over a bus  103  with a memory system  105 . A processing device  111  of memory system  105  has read/write access to memory regions  111 ,  113 , . . . ,  119  of non-volatile memory  121 . In one example, host system  101  also reads data from and writes data to volatile memory  123 . In one example, identity component  107  supports layers L 0  and L 1  of the DICE-RIoT protocol. In one example, non-volatile memory  121  stores boot code. 
     Verification component  109  is used to verify an identity of memory system  105 . Verification component  109  uses a triple including an identifier, certificate, and key generated by identity component  107  in response to receiving a host message from host system  101 , for example as described above. 
     Identity component  107  is an example of identity component  147  of  FIG. 1 . Verification component  109  is an example of verification component  153  of  FIG. 1 . 
     Memory system  105  includes key storage  157  and key generators  159 . In one example, key storage  157  can store root keys, session keys, a UDS (DICE-RIoT), and/or other keys used for cryptographic operations by memory system  105 . 
     In one example, key generators  159  generate a public key sent to host system  101  for use in verification by verification component  109 . The public key is sent as part of a triple that also includes an identifier and certificate, as described above. 
     Memory system  105  includes a freshness generator  155 . In one example, freshness generator  155  can be used for authenticated commands. In one example, multiple freshness generators  155  can be used. In one example, freshness generator  155  is available for use by host system  101 . 
     In one example, the processing device  111  and the memory regions  111 ,  113 , . . . ,  119  are on the same chip or die. In some embodiments, the memory regions store data used by the host system  101  and/or the processing device  111  during machine learning processing or other run-time data generated by software process(es) executing on host system  101  or on processing device  111 . 
     The computing system can include a write component in the memory system  105  that selects a memory region  111  (e.g., a recording segment of flash memory) for recording new data from host system  101 . The computing system  100  can further include a write component in the host system  101  that coordinates with the write component  107  in the memory system  105  to at least facilitate selection of the memory region  111 . 
     In one example, volatile memory  123  is used as system memory for a processing device (not shown) of host system  101 . In one embodiment, a process of host system  101  selects memory regions for writing data. In one example, the host system  101  can select a memory region based in part on data from sensors and/or software processes executing on an autonomous vehicle. In one example, the foregoing data is provided by the host system  101  to processing device  111 , which selects the memory region. 
     In some embodiments, host system  101  or processing device  111  includes at least a portion of the identity component  107  and/or verification component  109 . In other embodiments, or in combination, the processing device  111  and/or a processing device in the host system  101  includes at least a portion of the identity component  107  and/or verification component  109 . For example, processing device  111  and/or a processing device of the host system  101  can include logic circuitry implementing the identity component  107  and/or verification component  109 . For example, a controller or processing device (e.g., a CPU, FPGA, or GPU) of the host system  101 , can be configured to execute instructions stored in memory for performing the operations of the identity component  107  and/or verification component  109  described herein. 
     In some embodiments, the identity component  107  is implemented in an integrated circuit chip disposed in the memory system  105 . In other embodiments, the verification component  109  in the host system  101  is part of an operating system of the host system  101 , a device driver, or an application. 
     An example of memory system  105  is a memory module that is connected to a central processing unit (CPU) via a memory bus. Examples of memory modules include a dual in-line memory module (DIMM), a small outline DIMM (SO-DIMM), a nonvolatile dual in-line memory module (NVDIMM), etc. In some embodiments, the memory system can be a hybrid memory/storage system that provides both memory functions and storage functions. In general, a host system can utilize a memory system that includes one or more memory regions. The host system can provide data to be stored at the memory system and can request data to be retrieved from the memory system. In one example, a host can access various types of memory, including volatile and non-volatile memory. 
     The host system  101  can be a computing device such as a controller in a vehicle, a network server, a mobile device, a cellular telephone, an embedded system (e.g., an embedded system having a system-on-chip (SOC) and internal or external memory), or any computing device that includes a memory and a processing device. The host system  101  can include or be coupled to the memory system  105  so that the host system  101  can read data from or write data to the memory system  105 . The host system  101  can be coupled to the memory system  105  via a physical host interface. As used herein, “coupled to” generally refers to a connection between components, which can be an indirect communicative connection or direct communicative connection (e.g., without intervening components), whether wired or wireless, including connections such as electrical, optical, magnetic, etc. Examples of a physical host interface include, but are not limited to, a serial advanced technology attachment (SATA) interface, a peripheral component interconnect express (PCIe) interface, universal serial bus (USB) interface, Fibre Channel, Serial Attached SCSI (SAS), a double data rate (DDR) memory bus, etc. The physical host interface can be used to transmit data between the host system  101  and the memory system  105 . The physical host interface can provide an interface for passing control, address, data, and other signals between the memory system  105  and the host system  101 . 
       FIG. 2  illustrates a memory system  105  as an example. In general, the host system  101  can access multiple memory systems via a same communication connection, multiple separate communication connections, and/or a combination of communication connections. 
     The host system  101  can include a processing device and a controller. The processing device of the host system  101  can be, for example, a microprocessor, a central processing unit (CPU), a processing core of a processor, an execution unit, etc. In some instances, the controller of the host system can be referred to as a memory controller, a memory management unit, and/or an initiator. In one example, the controller controls the communications over bus  103  between the host system  101  and the memory system  105 . These communications include sending of a host message for verifying identity of memory system  105  as described above. 
     A controller of the host system  101  can communicate with a controller of the memory system  105  to perform operations such as reading data, writing data, or erasing data at the memory regions of non-volatile memory  121 . In some instances, the controller is integrated within the same package of the processing device  111 . In other instances, the controller is separate from the package of the processing device  111 . The controller and/or the processing device can include hardware such as one or more integrated circuits and/or discrete components, a buffer memory, a cache memory, or a combination thereof. The controller and/or the processing device can be a microcontroller, special purpose logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or another suitable processor. 
     In one embodiment, the memory regions  111 ,  113 , . . . ,  119  can include any combination of different types of non-volatile memory components. Furthermore, the memory cells of the memory regions can be grouped as memory pages or data blocks that can refer to a unit used to store data. In some embodiments, the volatile memory  123  can be, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), and synchronous dynamic random access memory (SDRAM). 
     In one embodiment, one or more controllers of the memory system  105  can communicate with the memory regions  111 ,  113 , . . . ,  119  to perform operations such as reading data, writing data, or erasing data. Each controller can include hardware such as one or more integrated circuits and/or discrete components, a buffer memory, or a combination thereof. Each controller can be a microcontroller, special purpose logic circuitry (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.), or another suitable processor. The controller(s) can include a processing device (processor) configured to execute instructions stored in local memory. In one example, local memory of the controller includes an embedded memory configured to store instructions for performing various processes, operations, logic flows, and routines that control operation of the memory system  105 , including handling communications between the memory system  105  and the host system  101 . In some embodiments, the local memory can include memory registers storing memory pointers, fetched data, etc. The local memory can also include read-only memory (ROM) for storing micro-code. 
     In general, controller(s) of memory system  105  can receive commands or operations from the host system  101  and/or processing device  111  and can convert the commands or operations into instructions or appropriate commands to achieve selection of a memory region based on data write counters for the memory regions. The controller can also be responsible for other operations such as wear-leveling, garbage collection operations, error detection and error-correcting code (ECC) operations, encryption operations, caching operations, and address translations between a logical block address and a physical block address that are associated with the memory regions. The controller can further include host interface circuitry to communicate with the host system  101  via the physical host interface. The host interface circuitry can convert the commands received from the host system into command instructions to access one or more of the memory regions as well as convert responses associated with the memory regions into information for the host system  101 . 
     The memory system  105  can also include additional circuitry or components that are not illustrated. In some embodiments, the memory system  105  can include a cache or buffer (e.g., DRAM or SRAM) and address circuitry (e.g., a row decoder and a column decoder) that can receive an address from one or more controllers and decode the address to access the memory regions. 
     In some embodiments, a controller in the host system  101  or memory system  105 , and/or the processing device  111  includes at least a portion of the identity component  107  and/or verification component  109 . For example, the controller and/or the processing device  111  can include logic circuitry implementing the identity component  107  and/or verification component  109 . For example, a processing device (processor) can be configured to execute instructions stored in memory for performing operations that provide read/write access to memory regions for the identity component  107  as described herein. In some embodiments, the verification component  109  is part of an operating system, a device driver, or an application. 
       FIG. 3  shows an example computing device of a vehicle  100 , according to one embodiment. For example, the vehicle  100  can be an autonomous vehicle, a nonautonomous vehicle, an emergency vehicle, a service vehicle, or the like. 
     The vehicle  100  includes a vehicle computing device  110 , such as an on-board computer. Vehicle computing device  110  is an example of host device  151  of  FIG. 1 . In another example vehicle computing device  110  is an example of host system  101  of  FIG. 2 , and memory  160  is an example of memory system  105 . 
     The vehicle computing device  110  includes a processor  120  coupled to a vehicular communication component  130 , such as a reader, writer, and/or other computing device capable of performing the functions described below, that is coupled to (or includes) an antenna  140 . The vehicular communication component  130  includes a processor  150  coupled to a memory  160 , such as a non-volatile flash memory, although embodiments are not so limited to such a kind of memory devices. 
     In one example, the memory  160  is adapted to store all the information related to the vehicle (e.g., driver, passengers, and carried goods) in such a way that the vehicle  100  is able to provide this information when approaching a check point by using a communication interface (for example the so-called DICE-RIoT protocol), as described below. 
     In one example, the vehicle information (such as vehicle ID/plate number) is already stored in the vehicle memory  160 , and the vehicle  100  is able to identify, for example through the communication component  130  and by using a known DICE-RIoT protocol or a similar protocol, the electronic ID of the passengers and/or the IDs of the carried luggage, goods and the like, and then to store this information in the memory  160 . In one example, electronic IDs, transported luggage and goods containers are equipped with wireless transponders, NFC, Bluetooth, RFID, touchless sensors, magnetic bars, and the like, and the communication component  130  can use readers and/or electromagnetic field to acquire the needed info from such remote sources. 
     In one example, all the passenger IDs and/or the IDs of the carried luggage, goods and the like are equipped with electronic devices capable to exchange data with a communication component. Those electronic devices may be active or passive elements in the sense that they may be active because supplied by electric power or may be activated and powered by an external electric supply source that provided the required electric supply just when the electric device is in its proximity. 
     Rental vehicles or autonomous vehicles can use readers and/or electromagnetic field to acquire information inside or in the proximity of the vehicle or, as an alternative, may receive information even from remote sources, for instance when the driver of a rental vehicle is already known to the rental system because of a previous reservation. A further check may be performed in real time when the driver arrives to pick up the vehicle. 
     Similarly, all the information about the transported luggage and goods (and also about the passengers) carried by the vehicle  100  may maintained to be always upto-date. To do so, the electronic ID of the passengers and/or the IDs of the carried luggage and goods are up-dated in real-time due to the wireless transponders associated to the luggage and good or owned by the passengers (not shown). 
     In one example, the communication between the vehicular communication component  130  and the proximity sources (e.g., the goods transponders and the like), occurs via the DICE-RIoT protocol. 
     In one example, the vehicle computing device  110  can control operational parameters of the vehicle  100 , such as steering and speed. For example, a controller (not shown) can be coupled to a steering control system  170  and a speed control system  180 . Further, the vehicle computing device  110  can be coupled to an information system  190 . Information system  190  can be configured to display a message, such as the route information or a check point security message and can display visual warnings and/or output audible warmings. The communication component  130  can receive information from additional computing devices, such as from an external computing device (not shown). 
       FIG. 4  shows an example system  390  having a host device  350  communicating with an example computing device of a vehicle  300 , according to one embodiment. The computing device includes a passive communication component  310 , such as a short-range communication device (e.g., an NFC tag). The communication component  310  can be in the vehicle  300 , which can be configured as shown in  FIG. 3  for the vehicle  100  and include the components of vehicle  100  in addition to the communication component  310 , which can be configured as the vehicular communication component  130 . The communication component  310  includes a chip  320  (e.g., implementing a CPU or application controller for vehicle  300 ) having a non-volatile storage component  330  that stores information about the vehicle  300  (such as vehicle ID, driver/passenger information, carried goods information, etc.). The communication component  310  can include an antenna  340 . 
     The host device  350  is, for example, an active communications device (e.g., that includes a power supply), which can receive information from the communication component  310  and/or transmit information thereto. In some examples, the host device  350  can include a reader (e.g., an NFC reader), such as a toll reader, or other components. The host device  350  can be an external device arranged (e.g., embedded) in proximity of a check point (e.g., at the boundary of a trust zone) or in general in proximity of limited access areas. In some embodiments, the host device  350  can also be carried by a policeman for use as a portable device. 
     The host device  350  can include a processor  360 , a memory  370 , such as a non-volatile memory, and an antenna  380 . The memory  370  can include an NFC protocol that allows the host device  350  to communicate with the communication component  310 . For example, the host device  350  and the communication component  310  can communicate using the NFC protocol, such as for example at about 13.56 mega-Hertz and according to the ISO/IEC 18000-3 international standard. Other approaches that use RFID tags can be used. 
     The host device  350  can also communicate with a server or other computing device (e.g., communicate over a wireless network with a central operation center). For example, the host device  350  can be wirelessly coupled or hardwired to the server or a communication center. In some examples, the host device  350  can communicate with the operation center via WIFI or over the Internet. The host device  350  can energize the communication component  310  when the vehicle  300  brings antenna  340  within a communication distance of antenna  380 . In some examples, the host device  350  can receive real-time information from the operation center and can transmit that information to vehicle  300 . In some embodiments, the communication component  310  can have its own battery. 
     In one embodiment, the host device  350  is adapted to read/send information from/to the vehicle  300 , which is equipped with the communication component  310  (e.g., an active device) configured to allow information exchange. 
     Referring again to  FIG. 3 , the vehicular communication component  130  of the vehicle  100  can be active internally to pick up in real-time pertinent information concerning the passengers IDs, the transported luggage and/or goods (e.g., when equipped with the corresponding wireless communication component discussed with respect to  FIG. 4  above). The vehicle&#39;s computing device may detect information in a space range of few meters (e.g., 2-3 meters), so that all data corresponding to passengers, luggage and goods may be acquired. In one example, this occurs when the vehicle approaches an external communication component (e.g., a server or other computing device acting as a host device) within a particular proximity so that communication can begin and/or become strengthened. The communication distance is for example 2-3 meters. 
     In one embodiment, the vehicular communication component  130  can encrypt data when communicating to external entities and/or with internal entities. In some cases, data concerning transported luggage, goods or even passengers may be confidential or include confidential information (e.g., the health status of a passenger or confidential documents or a dangerous material). In such a case, it is desired that the information and data stored in the memory portion associated to the vehicle computing device is kept as encrypted data. 
     In various embodiments discussed below, a method for encrypted and decrypted communication between the internal vehicle computing device and the external entity (e.g., a server acting as a host device) is discussed. In one example, this method may be applied even between the internal vehicle computing device and the electronic components associated to passengers, luggage and goods boarded on the vehicle. 
     In one example, the vehicular communication component  130  sends a vehicular public key to the external communication component (e.g., acting as a host device  151 ), and the external communication component sends an external public key to the vehicular communication component  130 . These public keys (vehicular and external) can be used to encrypt data sent to each respective communication component and verify an identity of each, and also exchange confirmations and other information. As an example, as described further below, the vehicular communication component  130  can encrypt data using the received external public key and send the encrypted data to the external communication component. Likewise, the external communication component can encrypt data using the received vehicular public key and send the encrypted data to the vehicular communication component  130 . Data sent by the vehicle  100  can include car information, passenger information, goods information, and the like. The information can optionally be sent with a digital signature to verify an identity of the vehicle  100 . Moreover, information can be provided to the vehicle  100  and displayed on a dashboard of the vehicle  100  or sent to an email of a computing device (e.g., a user device or central server that monitors vehicles) associated with the vehicle  100 . The vehicle can be recognized based on an identification of the vehicle, a VIN number, etc., along with a vehicular digital signature. 
     In one example, data exchanged between the vehicle and the external entity can have a freshness used by the other. As an example, data sent by the vehicle to the external entity to indicate the identical instructions can be altered at each of a particular time frame or for a particular amount of data being sent. This can prevent a hacker from intercepting confidential information contained in previously sent data and sending the same data again to result in the same outcome. If the data has been slightly altered, but still indicates a same instruction, the hacker might send the identical information at a later point in time, and the same instruction would not be carried out due to the recipient expecting the altered data to carry out the same instruction. 
     The data exchanged between the vehicle  100  and an external entity (e.g., a computing system or device) (not shown) can be performed using a number of encryption and/or decryption methods as described below. The securing of the data can ensure that unauthorized activity is prevented from interfering with the operation the vehicle  100  and the external entity. 
       FIG. 5A  shows an application board that generates a triple including an identifier, certificate, and key that is sent to a host device, according to one embodiment. The host device uses the triple to verify an identity of the application board. The application board is an example of computing device  141  of  FIG. 1 . The host device is an example of host device  151  of  FIG. 1 . 
     In one embodiment, the application board and the host include communication components that perform encryption and/or decryption operations for communications (e.g., on information and data) using a device identification composition engine (DICE)-robust internet of things (RIoT) protocol. In one example, the DICE-RIoT protocol is applied to communication between the vehicular communication component and an external communication component, as well as to a communication performed internally to the vehicle environment between the vehicle communication component and the various wireless electronic devices that are associated to each of the passenger IDs, the luggage, the goods and the like. 
       FIG. 5B  shows an example computing system that boots in stages using layers, according to one embodiment. The system includes an external communication component  430 ′ and a vehicular communication component  430 ″ in accordance with an embodiment of the present disclosure. As the vehicle comes near the external entity or in its proximity, the associated vehicular communication component  430 ″ of the vehicle can exchange data with the external entity as described above for example using a sensor (e.g., a radio frequency identification sensor, or RFID, or the like). 
     In other embodiments, the component  430 ′ can be an application board located in a vehicle, and the component  430 ″ can be a host device also located in the vehicle that uses the DICE-RIoT protocol to verify an identity of component  430 ′ (for example, as discussed with respect to  FIG. 1  above). 
     In one embodiment, the DICE-RIoT protocol is used by a computing device to boot in stages using layers, with each layer authenticating and loading a subsequent layer and providing increasingly sophisticated runtime services at each layer. A layer can thus be served by a prior layer and serve a subsequent layer, thereby creating an interconnected web of the layers that builds upon lower layers and serves higher order layers. Alternatively, other protocols can be used instead of the DICE-RIoT protocol. 
     In one example implementation of the communication protocol, security of the communication protocol is based on a secret value, which is a device secret (e.g., a UDS), that is set during manufacture (or also later). The device secret UDS exists within the device on which it was provisioned (e.g., stored as device secret  149  of  FIG. 1 ). 
     The device secret UDS is accessible to the first stage ROM-based boot loader at boot time. The system then provides a mechanism rendering the device secret inaccessible until the next boot cycle, and only the boot loader (e.g., the boot layer) can ever access the device secret UDS. Thus, in this approach, the boot is layered in a specific architecture that begins with the device secret UDS. 
     As is illustrated in  FIG. 5B , Layer  0 , L 0 , and Layer  1 , L 1 , are within the external communication component  430 ′. Layer  0  L 0  can provide a fuse derived secret, FDS, key to Layer  1  L 1 . The FDS key can be based on the identity of code in Layer  1  L 1  and other security relevant data. A particular protocol (such as robust internet of things (RIoT) core protocol) can use the FDS to validate code of Layer  1  L 1  that it loads. In an example, the particular protocol can include a device identification composition engine (DICE) and/or the RIoT core protocol. As an example, the FDS can include a Layer  1  L 1  firmware image itself, a manifest that cryptographically identifies authorized Layer  1  L 1  firmware, a firmware version number of signed firmware in the context of a secure boot implementation, and/or security-critical configuration settings for the device. The device secret UDS can be used to create the FDS, and is stored in the memory of the external communication component. Thus, the Layer  0  L 0  never reveals the actual device secret UDS and it provides a derived key (e.g., the FDS key) to the next layer in the boot chain. 
     The external communication component  430 ′ is adapted to transmit data, as illustrated by arrow  410 ′, to the vehicular communication component  430 ″. The transmitted data can include an external identification that is public, a certificate (e.g., an external identification certificate), and/or an external public key, as it will be illustrated in connection with  FIG. 6 . Layer  2  L 2  of the vehicular communication component  430 ″ can receive the transmitted data, execute the data in operations of the operating system, OS, for example on a first application App 1  and a second application App 2 . 
     Likewise, the vehicular communication component  430 ″ can transmit data, as illustrated by arrow  410 ″, including a vehicular identification that is public, a certificate (e.g., a vehicular identification certificate), and/or a vehicular public key. As an example, after the authentication (e.g., after verifying the certificate), the vehicular communication component  430 ″ can send a vehicle identification number, VIN, for further authentication, identification, and/or verification of the vehicle. 
     As shown in  FIG. 5B  and  FIG. 6 , in an example operation, the external communication component  430 ′ can read the device secret DS, hash an identity of Layer  1  L 1 , and perform the following calculation: 
     FDS=KDF [UDS, Hash (“immutable information”)] 
     where KDF is a cryptographic one-way key derivation function (e.g., HMACSHA256). In the above calculation, Hash can be any cryptographic primitive, such as SHA256, MD5, SHA3, etc. 
     In at least one example, the vehicle can communicate using either of an anonymous log in or an authenticated log in. The authenticated log in can allow the vehicle to obtain additional information that may not be accessible when communicating in an anonymous mode. In at least one example, the authentication can include providing the vehicular identification number VIN and/or authentication information, such as an exchange of public keys, as will be described below. In either of the anonymous and authenticated modes, the external entity (e.g., a check point police at a boundary of a trust zone) can communicate with the vehicle to provide the external public key associated with the external entity to the vehicle. 
       FIG. 6  shows an example computing device generating an identifier, certificate, and key using asymmetric generators, according to one embodiment. In one embodiment, the computing device implements a process to determine parameters (e.g., within the Layer L 1  of an external device, or Layer L 1  of an internal computing device in alternative embodiments). 
     In one embodiment, the parameters are determined including the external public identification, the external certificate, and the external public key that are then sent (as indicated by arrow  510 ′) to Layer  2  L 2  of the vehicular communication component (e.g., reference  430 ″ in  FIG. 5B ). Arrows  510 ′ and  510 ″ of  FIG. 6  correspond to arrows  410 ′ and  410 ″, respectively, of  FIG. 5B . Also, the layers in  FIG. 6  correspond to the layers of  FIG. 5B . 
     In another embodiment, a message (“Host Message”) from the host device is merged with the external public key by pattern (data) merging  531  to provide merged data for encryption. The merged data is an input to encryptor  530 . In one example, the host message is concatenated with the external public key. The generated parameters include a triple that is sent to a host device and used to verify an identity of a computing device. For example, the external public identification, the external certificate, and the external public key are used by a verification component of the host device to verify the identity. In one example, the host device is host device  151  of  FIG. 1 . 
     As shown in  FIG. 6 , the FDS from Layer  0  L 0  is sent to Layer  1  L 1  and used by an asymmetric ID generator  520  to generate a public identification, IDlkpublic, and a private identification, IDlkprivate. In the abbreviated “IDlkpublic” the “Ik” indicates a generic Layer k (in this example, Layer  1  L 1 ), and the “public” indicates that the identification is openly shared. The public identification IDlkpublic is illustrated as shared by the arrow extending to the right and outside of Layer  1  L 1  of the external communication component. The generated private identification IDlkprivate is used as a key input into an encryptor  530 . The encryptor  530  can be, for example, any processor, computing device, etc. used to encrypt data. 
     Layer  1  L 1  of the external communication component can include an asymmetric key generator  540 . In at least one example, a random number generator, RND, can optionally input a random number into the asymmetric key generator  540 . The asymmetric key generator  540  can generate a public key, KLkpublic, (referred to as an external public key) and a private key, KLkprivate, (referred to as an external private key) associated with an external communication component such as the external communication component  430 ′ in  FIG. 5B . 
     The external public key KLkpublic can be an input (as “data”) into the encryptor  530 . As mentioned above, in some embodiments, a host message previously received from the host device as part of an identity verification process is merged with KLkpublic to provide merged data as the input data to encryptor  530 . 
     The encryptor  530  can generate a result K′ using the inputs of the external private identification IDlkprivate and the external public key KLkpublic. The external private key KLkprivate and the result K′ can be input into an additional encryptor  550 , resulting in output K″. The output K″ is the external certificate, IDL 1 certificate, transmitted to the Layer  2  L 2  (or alternatively transmitted to a host device that verifies identity). The external certificate IDL 1 certificate can provide an ability to verify and/or authenticate an origin of data sent from a device. As an example, data sent from the external communication component can be associated with an identity of the external communication component by verifying the certificate, as it will be described further in association with  FIG. 7 . Further, the external public key KL 1 public key can be transmitted to Layer  2  L 2 . Therefore, the public identification IDl 1 public, the certificate IDL 1 certificate, and the external public key KL 1 public key of the external communication component can be transmitted to Layer  2  L 2  of the vehicular communication component. 
       FIG. 7  shows a verification component that verifies the identity of a computing device using decryption operations, according to one embodiment. The verification component includes decryptors  730 ,  750 . The verification component implements a process to verify a certificate in accordance with an embodiment of the present disclosure. 
     In the illustrated example of  FIG. 7 , a public key KL 1 public, a certificate IDL 1 certificate, and a public identification IDL 1 public is provided from the external communication component (e.g., from Layer  1  L 1  of the external communication component  430 ′ in  FIG. 5B ). 
     The data of the certificate IDL 1 certificate and the external public key KL 1 public can be used as inputs into decryptor  730 . The decryptor  730  can be any processor, computing device, etc. used to decrypt data. The result of the decryption of the certificate IDL 1 certificate and the external public key KL 1 public can be used as an input into decryptor  750  along with the public identification IDL 1 public, resulting in an output. The external public key KL 1 public and the output from the decryptor  750  can indicate, as illustrated at block  760 , whether the certificate is verified, resulting in a yes or no as an output. Private keys are associated with single layers and a specific certificate can only be generated by a specific layer. 
     In response to the certificate being verified (e.g., after the authentication), data received from the device being verified can be accepted, decrypted, and/or processed. In response to the certificate not being verified, data received from the device being verified can be discarded, removed, and/or ignored. In this way, unauthorized devices sending nefarious data can be detected and avoided. As an example, a hacker sending data to be processed can be identified and the hacking data not processed. 
     In an alternative embodiment, the public key KL 1 public, a certificate IDL 1 certificate, and a public identification IDL 1 public are provided from computing device  141  of  FIG. 1 , or from memory system  105  of  FIG. 2 . This triple is generated by computing device  141  in response to receiving a host message from the host device. Prior to providing IDL 1 certificate as an input to decryptor  730 , the IDL 1 certificate and a message from the host device (“host message”) are merged by pattern (data) merging  731 . In one example, the merging is a concatenation of data. The merged data is provided as the input to decryptor  730 . The verification process then proceeds otherwise as described above. 
       FIG. 8  shows a block diagram of an example process to verify a certificate, according to one embodiment. In the case where a device is sending data that may be verified in order to avoid subsequent repudiation, a signature can be generated and sent with the data. As an example, a first device may make a request of a second device and once the second device performs the request, the first device may indicate that the first device never made such a request. An anti-repudiation approach, such as using a signature, can avoid repudiation by the first device and ensure that the second device can perform the requested task without subsequent difficulty. 
     A vehicle computing device  810 ″ (e.g., vehicle computing device  110  in FIG.  3  or computing device  141  of  FIG. 1 ) can send data Dat″ to an external computing device  810 ′ (or to any other computing device in general). The vehicle computing device  810 ″ can generate a signature Sk using the vehicular private key KLkprivate. The signature Sk can be transmitted to the external computing device  810 ′. The external computing device  810 ′ can verify using data Dat′ and the public key KLkpublic previously received (e.g., the vehicular public key). In this way, signature verification operates by using a private key to encrypt the signature and a public key to decrypt the signature. In this way, a unique signature for each device can remain private to the device sending the signature while allowing the receiving device to be able to decrypt the signature for verification. This is in contrast to encryption/decryption of the data, which is encrypted by the sending device using the public key of the receiving device and decrypted by the receiving device using the private key of the receiver. In at least one example, the vehicle can verify the digital signature by using an internal cryptography process (e.g., Elliptical Curve Digital signature (ECDSA) or a similar process). 
     Due to the exchange and verification of the certificates and of the public keys, the devices are able to communicate in a secure way with each other. When a vehicle approaches an external entity (e.g., a trust zone boundary, a border security entity or, generally, an electronically-controlled host device), the respective communication devices (which have the capability shown in  FIG. 7  of verifying the respective certificate) exchange the certificates and communicate to each other. After the authentication (e.g. after receiving/verifying from the external entity the certificate and the public key), the vehicle is thus able to communicate all the needed information related thereto and stored in the memory thereof, such as plate number/ID, VIN, insurance number, driver info (e.g., IDs, eventual permission for border transition), passenger info, transported goods info and the like. Then, after checking the received info, the external entity communicates to the vehicle the result of the transition request, this info being possibly encrypted using the public key of the receiver. The exchanged messages/info can be encrypted/decrypted using the above-described DICE-RIoT protocol. In some embodiments, the so-called immutable info (such as plate number/ID, VIN, insurance number) is not encrypted, while other info is encrypted. In other words, in the exchanged message, there can be non-encrypted data as well as encrypted data: the info can thus be encrypted or not, or mixed. The correctness of the message is then ensured by using the certificate/public key to validate that the content of the message is valid. 
       FIG. 9  shows a method to verify an identity of a computing device using an identifier, certificate, and a key, according to one embodiment. For example, the method of  FIG. 9  can be implemented in the system of  FIGS. 1-7 . 
     The method of  FIG. 9  can be performed by processing logic that can include hardware (e.g., processing device, circuitry, dedicated logic, programmable logic, microcode, hardware of a device, integrated circuit, etc.), software (e.g., instructions run or executed on a processing device), or a combination thereof. In some embodiments, the method of  FIG. 9  is performed at least in part by the identity component  147  and verification component  153  of  FIG. 1 . 
     Although shown in a particular sequence or order, unless otherwise specified, the order of the processes can be modified. Thus, the illustrated embodiments should be understood only as examples, and the illustrated processes can be performed in a different order, and some processes can be performed in parallel. Additionally, one or more processes can be omitted in various embodiments. Thus, not all processes are required in every embodiment. Other process flows are possible. 
     At block  921 , a message is received from a host device. For example, computing device  141  receives a message (e.g., “host message” or “host message | freshness”) from host device  151 . 
     At block  923 , an identifier, a certificate, and a key (e.g., a public key KL 1 public) are generated. The identifier is associated with an identity of a computing device. The certificate is generated using the message (e.g., “host message”) from the host device. In one embodiment, the message is merged with the public key prior to encryption. This encryption uses private identifier IDL 1 private as a key. The private identifier IDL 1 private is associated with the public identifier IDL 1 public (e.g., an associated pair that is generated by asymmetric ID generator  520 ). 
     In one example, identity component  147  generates the identifier, certificate, and key to provide a triple. In one example, the triple is generated based on the DICERIoT protocol. In one example, the triple is generated as illustrated in  FIG. 6 . 
     In one example, using the DICE-RIoT protocol, each layer (Lk) provides to the next layers (Lk+1) a set of keys and certificates, and each certificate can be verified by the receiving layer. The fuse derived secret FDS is calculated as follows: 
     FDS=HMAC-SHA256 [UDS, SHA256(“Identity of L 1 ”)] 
     In one example, layer  1  L 1  in a DICE-RIoT architecture generates the certificate using a host message sent by the host device. Layer  1  calculates two associated key pairs as follows: 
     (IDIk public, IDIk private) and (KLk public, KLk private) 
     Layer  1  also calculates two signatures as follows: 
     K′=encrypt (IDIk private, KLk public | host message)
 
K″=encrypt (KLk private, K′)
 
     From the above processing, layer  1  provides a triple as follows: 
     KL1={IDL 1  public, IDL 1  certificate, KL 1  public}
 
More generally, each layer provides a triple as follows:
 
KLk={set of keys and certificate} for each k=1:N
 
Using the respective triple, each layer is able to prove its identity to the next layer.
 
     In one example, layer  2  corresponds to application firmware, and subsequent layers correspond to an operating system and/or applications of the host device. 
     At block  925 , the generated identifier, certificate, and key are sent to the host device. The host device verifies the identity of the computing device using the identifier, certificate, and key. In one example, host device  151  receives the identifier, certificate, and key from computing device  141 . Host device  151  uses verification component  153  to verify the identity of the computing device. 
     In one example, verification component  153  performs decryption operations as part of the verification process. The decryption includes merging the message from the host with the certificate prior to decryption using the key received from computing device  141 . In one example, verification of the identity of the computing device is performed as illustrated in  FIG. 7 . 
     In one example, the decryption operations are performed as follows: 
     Decrypt (IDL 1 certificate) using KL 1  public to provide K′
 
Decrypt K′ using IDL 1  public to provide Result
 
The Result is compared to KL 1  public. If the Result is equal to KL 1  public, then the identity is verified. In one example, an application board identity is verified.
 
     In one embodiment, an identity of a human or animal is proven. Verification of the identity of a person is performed similarly as for verifying the identity of a computing device  141  as described above. In one example, computing device  141  is integrated into a passport for a person. A public administration department of a country that has issued the passport can use a UDS that is specific for a class of document (e.g., driver license, passport, ID card, etc.). For example, for the Italy, Sicily, Messina, Passport Office, the UDS=0x12234 . . . 4444. For the Germany, Bavaria, Munich, Passport Office, the UDS=0xaabb . . . 00322. 
     In one example regarding a passport, the identity of L 1  is an ASCII string as follows: 
     Country | Document type | etc. (e.g., “Italy, Sicily, Messina, Passport Office”) The “granularity” of the assignation can be determined by the public administration of each country. 
     Various embodiments of the method of  FIG. 9  provide various advantages. For example, a thing can be identified and certified as being produced by a specific factory without using a third party key infrastructure (e.g., PKI=public key infrastructure). Malicious or hacker man in the middle attacks are prevented due to being replay protected. The method is usable for mass production of things. 
     Further, the customer UDS is protected at a hardware level (e.g., inaccessibility of layer  0  external to the component). The UDS cannot be read by anyone, but it can be replaced (e.g., only the customer can do this by using a secure protocol). Examples of secure protocols include security protocols based on authenticated, replay protected commands and/or on secret sharing algorithms like Diffie Hellman (e.g., ECDH elliptic curves Diffie Hellman). In one example, the UDS is communicated to the customer (not the end user) by using secure infrastructure. The UDS is customizable by the customer. 
     In addition, the component recognition can work in the absence of an internet or other network connection. Also, the method can be used to readily check identity of: things, animals, and humans at a trust zone boundary (e.g., a country border, internal check point, etc.). 
     In one example, knowledge of the UDS permits the host device to securely replace the UDS. For example, replacement can be done if: the host desires to change the identity of a thing, or the host desires that the thing&#39;s identity is unknown to anyone else (including the original manufacturer). 
     In another example, a replace command is used by the host device. For example, the host device can send a replace UDS command to the computing device. The replace command includes the existing UDS and the new UDS to be attributed to the computing device. In one example, the replace command has a field including a hash value as follows: hash (existing UDS | new UDS). 
     In another example, an authenticated replay protect command is used that has a field as follows: Replace_command | freshness | signature 
     where signature=MAC [secret key, Replace_command | freshness | hash (existing UDS | new UDS)]
 
The secret key is an additional key, and is the key used for authenticated commands present on the device. For example, the secret key can be a session key as described below (see, e.g.,  FIG. 12 ).
 
     In one embodiment, a method comprises: receiving, by a computing device (e.g., computing device  141 ), a message from a host device (e.g., host device  151 ); generating, by the computing device, an identifier, a certificate, and a key, wherein the identifier is associated with an identity of the computing device, and the certificate is generated using the message; and sending, by the computing device, the identifier, the certificate, and the key to the host device, wherein the host device is configured to verify the identity of the computing device using the identifier, the certificate, and the key. 
     In one embodiment, verifying the identity of the computing device comprises concatenating the message and the certificate to provide first data. 
     In one embodiment, verifying the identity of the computing device further comprises decrypting the first data using the key to provide second data. 
     In one embodiment, verifying the identity of the computing device further comprises decrypting the second data using the identifier to provide a result, and comparing the result to the key. 
     In one embodiment, the identifier is a public identifier, and the computing device stores a secret key, the method further comprising: using the secret key as an input to a message authentication code to generate a derived secret; wherein the public identifier is generated using the derived secret as an input to an asymmetric generator. 
     In one embodiment, the identifier is a first public identifier, and the computing device stores a first device secret used to generate the first public identifier, the method further comprising: receiving a replace command from the host device; in response to receiving the replace command, replacing the first device secret with a second device secret; and sending, to the host device, a second public identifier generated using the second device secret. 
     In one embodiment, the key is a public key, and generating the certificate includes concatenating the message with the public key to provide a data input for encryption. 
     In one embodiment, the identifier is a public identifier, and a first asymmetric generator generates the public identifier and a private identifier as an associated pair; the key is a public key, and a second asymmetric generator generates the public key and a private key as an associated pair; and generating the certificate comprises: concatenating the message with the public key to provide first data; encrypting the first data using the private identifier to provide second data; and encrypting the second data using the private key to provide the certificate. 
     In one embodiment, the key is a public key, the method further comprising generating a random number as an input to an asymmetric key generator, wherein the public key and an associated private key are generated using the asymmetric key generator. 
     In one embodiment, the random number is generated using a physical unclonable function (PUF). 
     In one embodiment, a system comprises: at least one processor; and memory containing instructions configured to instruct the at least one processor to: send a message to a computing device; receive, from the computing device, an identifier, a certificate, and a key, wherein the identifier is associated with an identity of the computing device, and the certificate is generated by the computing device using the message; and verify the identity of the computing device using the identifier, the certificate, and the key. 
     In one embodiment, verifying the identity of the computing device comprises: concatenating the message and the certificate to provide first data; decrypting the first data using the key to provide second data; decrypting the second data using the identifier to provide a result; and comparing the result to the key. 
     In one embodiment, the identifier is a first public identifier, the computing device stores a first device secret used to generate the first public identifier, and the instructions are further configured to instruct the at least one processor to: send a replace command to the computing device, the replace command to cause the computing device to replace the first device secret with a second device secret, and receive, from the computing device, a second public identifier generated using the second device secret. 
     In one embodiment, the computing device is configured to use the second device secret as an input to a message authentication code that provides a derived secret, and to generate the second public identifier using the derived secret. 
     In one embodiment, the replace command includes a field having a value based on the first device secret. 
     In one embodiment, the system further comprises a freshness mechanism configured to generate a freshness, wherein the message sent to the computing device includes the freshness. 
     In one embodiment, the identity of the computing device includes an alphanumeric string. 
     In one embodiment, a non-transitory computer storage medium stores instructions which, when executed on a computing device, cause the computing device to at least: receive a message from a host device; generate an identifier, a certificate, and a key, wherein the identifier corresponds to an identity of the computing device, and the certificate is generated using the message; and send the identifier, the certificate, and the key to the host device for use in verifying the identity of the computing device. 
     In one embodiment, the identifier is a public identifier associated with a private identifier, the key is a public key associated with a private key, and generating the certificate comprises: concatenating the message with the public key to provide first data; encrypting the first data using the private identifier to provide second data; and encrypting the second data using the private key to provide the certificate. 
     In one embodiment, verifying the identity of the computing device comprises performing a decryption operation using the identifier to provide a result, and comparing the result to the key. 
     Generating Values Using Physical Unclonable Function (PUF) 
     At least some embodiments disclosed below provide an improved architecture for generating values using a physical unclonable function (PUF). In some embodiments, the PUF value can itself be used as a device secret, or used to generate a device secret. In one example, the PUF value is used as a unique device secret (UDS) for use with the DICE-RIoT protocol as described above (e.g., see  FIG. 5A  and  FIG. 5B ). In one example, a value generated by a PUF is used as an input to a message authentication code (MAC). The output from the MAC is used as the UDS. 
     In some embodiments, the PUF value, or a value generated from the PUF value, can be used as a random number (e.g., a device specific random number). In one example, the random number (e.g., RND) is used as an input when generating the associated public key and private key via the asymmetric key generator described above (e.g., see  FIG. 6 ). 
     In general, the architecture below generates an output by feeding inputs provided from one or more PUFs into a message authentication code (MAC). The output from the MAC provides the improved PUF (e.g., the UDS above). 
     In general, semiconductor chip manufacturers face the problem of key injection, which is the programming of a unique secret key for each chip or die, for example, provided from a semiconductor wafer. It is desired that key injection be performed in a secure environment to avoid leaking or disclosing the secret keys injected into the chips. It is also desired to ensure that the key cannot be hacked or read back after production of the chip. In some cases, for example, key injection procedures are certified or executed by a third-party infrastructure. 
     Chip manufacturers desire to reduce the production cost of chips that include cryptographic capabilities. Chip manufacturers also desire to simplify production flows while maintaining a consistent level of security performance of the manufactured chips. However, key injection is one of the more expensive production steps. 
     Chip manufacturers also face the problem of improving the uniformity of PUFs when used as pseudo-random number generators. In some cases, this problem may include a cross-correlation between dice because of the phenomena on which a seed value provided by the PUF is based. 
     A PUF is based on unpredictable physical phenomena such as, for example, on-chip parasitic effect, on-chip path delays, etc., which are unique for each die. These phenomena are used, for example, to provide a seed value for a pseudo-random number generator. 
     Two different chips selected in the production line must have different PUF values. The PUF value generated in each chip must not change during the life of the device. If two chips have similar keys (e.g., there is a low Hamming distance between them), it may be possible to use a key of one chip to guess the key of another chip (e.g., preimage hacker attack). 
     Using the improved PUF architecture described below can provide a solution to one or more of the above problems by providing output values suitable for providing the function of a PUF on each chip or die. The improved PUF architecture below uses a PUF, which enables each chip or die to automatically generate a unique secure key at each power-up of the chip or die. The secure key does not need to be stored in a nonvolatile memory, which might be hacked or otherwise compromised. 
     The improved PUF architecture further uses a MAC to generate the improved PUF output (e.g., a unique key) for use by, for example, cryptographic functions or processes that are integrated into the semiconductor chip. The use of the MAC can, for example, increase the Hamming distance between keys generated on different chips. 
     In at least some embodiments disclosed herein, an improved PUF architecture using the output from a MAC is provided as a way to generate seed or other values. Thus, the improved PUF architecture provides, for example, a way to perform key injection that reduces cost of manufacture, and that improves reliability and/or uniformity of PUF operation on the final chip. 
     In one embodiment, a method includes: providing, by at least one PUF, at least one value; and generating, based on a MAC, a first output, wherein the MAC uses the at least one value provided by the at least one PUF as an input for generating the first output. 
     In one embodiment, a system includes: at least one PUF device; a message authentication code MAC module configured to receive a first input based on at least one value provided by the at least one PUF device; at least one processor; and memory containing instructions configured to instruct the at least one processor to generate, based on the first input, a first output from the MAC module. In various embodiments, the MAC module can be implemented using hardware and/or software. 
     In one embodiment, the system further includes a selector module that is used to select one or more of the PUF devices for use in providing values to the MAC module. For example, values provided from several PUF devices can be linked and provided as an input to the MAC module. In various embodiments, the selector module can be implemented using hardware and/or software. 
       FIG. 10  shows a system for generating a unique key  125  from an output of a message authentication code (MAC)  123  that receives an input from a physical unclonable function (PUF) device  121 , according to one embodiment. The system provides a PUF architecture  111  used to generate the unique key  125  (or other value) from an output of message authentication code (MAC) module  123 . The MAC module  123  receives an input value obtained from the physical unclonable function (PUF) device  121 . 
     The PUF device  121  in  FIG. 10  can be, for example, any one of various different, known types of PUFs. The MAC module  123  provides, for example, a oneway function such as SHA1, SHA2, MD5, CRC, TIGER, etc. 
     The architecture  111  can, for example, improve the Hamming distance of the PUF values or codes generated between chips. The MAC functions are unpredictable (e.g., input sequences with just a single bit difference provided to the MAC function provide two completely different output results). Thus, the input to MAC function cannot be recognized or determined when having only knowledge of the output. The architecture  111  also can, for example, improve the uniformity of the PUF as a pseudorandom number generator. 
     In one example, the value generated by the PUF architecture  111  (e.g., unique key  125  or another value) may be a number having N bits, where N depends on a cryptographic algorithm implemented on a chip (e.g., memory device  103  or another device) that includes the PUF architecture  111 . In one example, the chip implements a cryptographic function that uses HMAC-SHA256, in which case the output from MAC module  123  has a size N of 256 bits. The use of the output from the MAC module  123  provides a message length for the output value that is suitable for use as a key (without needing further compression or padding). 
     The PUF architecture  111  is implemented in a device such as the illustrated memory device  103 , or can be implemented in other types of computing devices such as, for example, integrated circuits implemented in a number of semiconductor chips provided by a wafer manufacturing production line. 
     In one embodiment, the MAC module  123  cooperates with and/or is integrated into or as part of cryptographic module  127 , for example which can provide cryptographic functions for memory device  103 . For example, the output of the MAC module  123  can be suitable to be used as a key due to the MAC being used by the memory device  103  for other cryptographic purposes. 
     The operation of the PUF architecture  111 , the cryptographic module  127 , and/or other functions of the memory device  103  can be controlled by a controller  107 . The controller  107  can include, for example, one or more microprocessors. 
     In  FIG. 10 , a host  101  can communicate with the memory device  103  via a communication channel. The host  101  can be a computer having one or more Central Processing Units (CPUs) to which computer peripheral devices, such as the memory device  103 , may be attached via an interconnect, such as a computer bus (e.g., Peripheral Component Interconnect (PCI), PCI eXtended (PCI-X), PCI Express (PCIe)), a communication portion, and/or a computer network. 
     In one embodiment, unique key  125  is used as a UDS to provide an identity for memory device  103 . Controller  107  implements layer  0  L 0  and layer  1  L 1  in a DICE-RIoT architecture. In response to receiving host message from host  101  via host interface  105 , cryptographic module  127  performs processing to generate a triple, as described above. Host  101  uses the triple to verify the identity of memory device  103 . Memory device  103  is an example of computing device  141 . 
     For purposes of exemplary illustration, it can be noted that there typically are two technical problems. A first problem is to prove the identity of the board to the host. The problem can be handled by the use of the public triple and asymmetric cryptography, as for example discussed above for DICE-RIoT. This approach is secure and elegant, but in some cases may be too expensive/time consuming to be used directly by a circuitry board itself. A second problem is to prove to the board the identity of the memory on the board (e.g., to avoid unauthorized memory replacement)(this is performed for example after each power-up). The second problem could be solved using the public triple and asymmetric cryptography above. However, a lighter security mechanism based simply on a MAC function is often sufficient for handling the second problem. 
     The memory device  103  can be used to store data for the host  101 , for example, in the non-volatile storage media  109 . Examples of memory devices in general include hard disk drives (HDDs), solid state drives (SSDs), flash memory, dynamic random-access memory, magnetic tapes, network attached storage device, etc. The memory device  103  has a host interface  105  that implements communications with the host  101  using the communication channel. For example, the communication channel between the host  101  and the memory device  103  is a Peripheral Component Interconnect Express (PCI Express or PCIe) bus in one embodiment; and the host  101  and the memory device  103  communicate with each other using NVMe protocol (Non-Volatile Memory Host Controller Interface Specification (NVMHCI), also known as NVM Express (NVMe)). 
     In some implementations, the communication channel between the host  101  and the memory device  103  includes a computer network, such as a local area network, a wireless local area network, a wireless personal area network, a cellular communications network, a broadband high-speed always-connected wireless communication connection (e.g., a current or future generation of mobile network link); and the host  101  and the memory device  103  can be configured to communicate with each other using data storage management and usage commands similar to those in NVMe protocol. 
     The controller  107  can run firmware  104  to perform operations responsive to the communications from the host  101 , and/or other operations. Firmware in general is a type of computer program that provides control, monitoring and data manipulation of engineered computing devices. In  FIG. 10 , the firmware  104  controls the operations of the controller  107  in operating the memory device  103 , such as the operation of the PUF architecture  111 , as further discussed below. 
     The memory device  103  has non-volatile storage media  109 , such as magnetic material coated on rigid disks, and/or memory cells in an integrated circuit. The storage media  109  is non-volatile in that no power is required to maintain the data/information stored in the non-volatile storage media  109 , which data/information can be retrieved after the non-volatile storage media  109  is powered off and then powered on again. The memory cells may be implemented using various memory/storage technologies, such as NAND gate based flash memory, phase-change memory (PCM), magnetic memory (MRAM), resistive random-access memory, and 3D XPoint, such that the storage media  109  is non-volatile and can retain data stored therein without power for days, months, and/or years. 
     The memory device  103  includes volatile Dynamic Random-Access Memory (DRAM)  106  for the storage of run-time data and instructions used by the controller  107  to improve the computation performance of the controller  107  and/or provide buffers for data transferred between the host  101  and the non-volatile storage media  109 . DRAM  106  is volatile in that it requires power to maintain the data/information stored therein, which data/information is lost immediately or rapidly when the power is interrupted. 
     Volatile DRAM  106  typically has less latency than non-volatile storage media  109 , but loses its data quickly when power is removed. Thus, it is advantageous to use the volatile DRAM  106  to temporarily store instructions and data used for the controller  107  in its current computing task to improve performance. In some instances, the volatile DRAM  106  is replaced with volatile Static Random-Access Memory (SRAM) that uses less power than DRAM in some applications. When the non-volatile storage media  109  has data access performance (e.g., in latency, read/write speed) comparable to volatile DRAM  106 , the volatile DRAM  106  can be eliminated; and the controller  107  can perform computing by operating on the non-volatile storage media  109  for instructions and data instead of operating on the volatile DRAM  106 . 
     For example, cross point storage and memory devices (e.g.,  3 D XPoint memory) have data access performance comparable to volatile DRAM  106 . A cross point memory device uses transistor-less memory elements, each of which has a memory cell and a selector that are stacked together as a column. Memory element columns are connected via two perpendicular lays of wires, where one lay is above the memory element columns and the other lay below the memory element columns. Each memory element can be individually selected at a cross point of one wire on each of the two layers. Cross point memory devices are fast and non-volatile and can be used as a unified memory pool for processing and storage. 
     In some instances, the controller  107  has in-processor cache memory with data access performance that is better than the volatile DRAM  106  and/or the nonvolatile storage media  109 . Thus, parts of instructions and data used in the current computing task are cached in the in-processor cache memory of the controller  107  during the computing operations of the controller  107 . In some instances, the controller  107  has multiple processors, each having its own in-processor cache memory. 
     Optionally, the controller  107  performs data intensive, in-memory processing using data and/or instructions organized in the memory device  103 . For example, in response to a request from the host  101 , the controller  107  performs a real-time analysis of a set of data stored in the memory device  103  and communicates a reduced data set to the host  101  as a response. For example, in some applications, the memory device  103  is connected to real-time sensors to store sensor inputs; and the processors of the controller  107  are configured to perform machine learning and/or pattern recognition based on the sensor inputs to support an artificial intelligence (AI) system that is implemented at least in part via the memory device  103  and/or the host  101 . 
     In some implementations, the processors of the controller  107  are integrated with memory (e.g.,  106  or  109 ) in computer chip fabrication to enable processing in memory and thus overcome the von Neumann bottleneck that limits computing performance as a result of a limit in throughput caused by latency in data moves between a processor and memory configured separately according to the von Neumann architecture. The integration of processing and memory increases processing speed and memory transfer rate, and decreases latency and power usage. 
     The memory device  103  can be used in various computing systems, such as a cloud computing system, an edge computing system, a fog computing system, and/or a standalone computer. In a cloud computing system, remote computer servers are connected in a network to store, manage, and process data. An edge computing system optimizes cloud computing by performing data processing at the edge of the computer network that is close to the data source and thus reduces data communications with a centralize server and/or data storage. A fog computing system uses one or more end-user devices or near-user edge devices to store data and thus reduces or eliminates the need to store the data in a centralized data warehouse. 
     At least some embodiments disclosed herein can be implemented using computer instructions executed by the controller  107 , such as the firmware  104 . In some instances, hardware circuits can be used to implement at least some of the functions of the firmware  104 . The firmware  104  can be initially stored in the nonvolatile storage media  109 , or another non-volatile device, and loaded into the volatile DRAM  106  and/or the in-processor cache memory for execution by the controller  107 . 
     For example, the firmware  104  can be configured to use the techniques discussed below in operating the PUF architecture. However, the techniques discussed below are not limited to being used in the computer system of  FIG. 10  and/or the examples discussed above. 
     In some implementations, the output of the MAC module  123  can be used to provide, for example, a root key or a seed value. In other implementations, the output can be used to generate one or more session keys. 
     In one embodiment, the output from the MAC module  123  can be transmitted to another computing device. For example, the unique key  125  can be transmitted via host interface  105  to host  101 . 
       FIG. 11  shows a system for generating unique key  125  from an output of MAC  123 , which receives inputs from one or more PUF devices selected by a selector module  204 , according to one embodiment. The system generates the unique key  125  from an output of the MAC module  123  using a PUF architecture similar to architecture  111  of  FIG. 10 , but including multiple PUF devices  202  and selector module  204 , according to one embodiment. The MAC module  123  receives inputs from one or more PUF devices  202  selected by the selector module  204 . In one example, PUF devices  202  include PUF device  121 . 
     The PUF devices  202  can be, for example, identical or different (e.g., based on different random physical phenomena). In one embodiment, selector module  204  acts as an intelligent PUF selection block or circuit to select one or more of PUF devices  202  from which to obtain values to provide as inputs to the MAC module  123 . 
     In one embodiment, the selector module  204  bases the selection of the PUF devices  202  at least in part on results from testing the PUF devices  202 . For example, the selector module  204  can test the repeatability of each PUF device  202 . If any PUF device  202  fails testing, then the selector module  204  excludes the failing device from providing an input value to the MAC module  123 . In one example, the failing device can be excluded temporarily or indefinitely. 
     In some implementations, the selector module  204  permits testing the PUF functionality of each chip during production and/or during use in the field (e.g., by checking the repeatability of the value provided by each PUF device  202 ). If two or more values provided by a given PUF device are different, then the PUF device is determined to be failing and is excluded from use as an input to the MAC module  123 . 
     In one embodiment, the selector module  204  is used to concurrently use multiple PUF devices  202  as sources for calculating an improved PUF output from the MAC module  123 . For example, the selector module  204  can link a value from a first PUF device with a value from a second PUF device to provide as an input to the MAC module  123 . In some implementations, this architecture permits obtaining a robust PUF output due to its dependence on several different physical phenomena. 
       FIG. 12  shows a system for generating a unique key from an output of a MAC that receives inputs from one or more PUF devices and an input from a monotonic counter  302  (and/or an input from another freshness mechanism like NONCE, timestamp, etc.), according to one embodiment. The system generates the unique key  125  from an output of the MAC module  123 , according to one embodiment. The PUF architecture illustrated in  FIG. 12  is similar to the PUF architecture illustrated in  FIG. 11 , except that a monotonic counter  302  is included to provide values to selector module  204 . In various embodiments, the monotonic counter  302  can be implemented using hardware and/or software. 
     The MAC module  123  receives inputs from one or more PUF devices  202  and an input from the monotonic counter  302 . In one example, values obtained from the PUF devices  202  and the monotonic counter  302  are linked and then provided as an input to the MAC module  123 . In some implementations, the monotonic counter  302  is a non-volatile counter that only increments its value when requested. In some embodiments, the monotonic counter  302  is incremented after each power-up cycle of a chip. 
     In some implementations, the PUF architecture of  FIG. 12  can be used to provide a way to securely share keys between a semiconductor chip and other components in an application, such as for example a public key mechanism. 
     In some implementations, the monotonic counter  302  is incremented before each calculation of a PUF, which ensures that the input of the MAC module  123  is different at each cycle, and thus the output (and/or pattern of output) provided is different. In some examples, this approach can be used to generate a session key, where each session key is different. 
     In some embodiments, the selector module  204  can selectively include or exclude the monotonic counter  302  (or other freshness mechanism like NONCE, timestamp) from providing a counter value as an input to the MAC module  123 . 
     In some embodiments, the monotonic counter  302  is also used by cryptographic module  127 . In some embodiments, a PUF architecture that includes the monotonic counter can be used as a session key generator to guarantee a different key at each cycle. In some implementations, the generated session key is protected in this way: Session key=MAC [one or more PUFs | MTC or other freshness]. 
     In other embodiments, a mechanism is used as follows: 
       Session key=MACkey_based[Root_Key,MTC or other freshness mechanism] 
     Where: Root_Key=an output value provided from the MAC module  123  above, or any other kind of key that is present on the chip.
         The MACkey_based function above is, for example, a MAC algorithm based on a secret key. For example, there can be two types of MAC algorithm in cryptography:   1. An algorithm based on a secret key like, for example, HMAC family (HMAC-SHA256 is key based).   2. An algorithm that is not based on a secret key, for example like SHA256 (SHA stand-alone is not key based).
 
It should be noted that a MAC that is key-based can be transformed in a MAC that is not key-based by setting the key to a known value (e.g. 0x000 . . . 0xFFFF etc . . . ).
       

       FIG. 13  shows a method to generate an output from a MAC that uses one or more input values provided from one or more PUFs, according to one embodiment. For example, the method of  FIG. 13  can be implemented in the memory device  103  of  FIG. 10 . 
     The method of  FIG. 13  includes, at block  411 , providing one or more values by at least one PUF (e.g., providing values from one or more of PUF devices  202 ). 
     At block  413 , repeatability of one or more of the PUFs can be tested, for example as was described above. This testing is optional. 
     At block  415 , if testing has been performed at block  413 , and it has been determined that a PUF device fails the testing, then the failing PUF device is excluded from providing an input to the MAC. This excluding may be performed, for example, by selector module  204 , as was discussed above. 
     At block  417 , a value is provided from a monotonic counter (e.g., monotonic counter  302 ). The use of the monotonic counter in the PUF architecture is optional. 
     At block  419 , an output is generated from the MAC, which uses one or more values provided by the PUFs (and optionally at least one value from the monotonic counter) as inputs to the MAC. 
     Various other embodiments are now described below for a method implemented in a computing device that includes: providing, by at least one physical unclonable function (PUF), at least one value; and generating, based on a message authentication code (MAC), a first output, wherein the MAC uses the at least one value provided by the at least one PUF as an input for generating the first output. 
     In one embodiment, the computing device is a first computing device, and the method further comprises transmitting the first output to a second computing device, wherein the first output is a unique identifier of the first computing device. 
     In one embodiment, providing the at least one value comprises selecting a first value from a first PUF and selecting a second value from a second PUF. 
     In one embodiment, the method further comprises: providing a value from a monotonic counter; wherein generating the first output further comprises using the value from the monotonic counter as an additional input to the MAC for generating the first output. 
     In one embodiment, the method further comprises: generating a plurality of session keys based on respective outputs provided by the MAC, wherein the monotonic counter provides values used as inputs to the MAC; and incrementing the monotonic counter after generating each of the session keys. 
     In one embodiment, the method further comprises: testing repeatability of a first PUF of the at least one PUF; and based on determining that the first PUF fails the testing, excluding the first PUF from providing any input to the MAC when generating the first output. 
     In one embodiment, the testing comprises comparing two or more values provided by the first PUF. 
     In one embodiment, the computing device is a memory device, and the memory device comprises a non-volatile storage media configured to store an output value generated using the MAC. 
     In one embodiment, the method further comprises performing, by at least one processor, at least one cryptographic function, wherein performing the at least one cryptographic function comprises using an output value generated using the MAC. 
     In one embodiment, a non-transitory computer storage medium stores instructions which, when executed on a memory device (e.g., the memory device  103 ), cause the memory device to perform a method, the method comprising: providing, by at least one physical unclonable function (PUF), at least one value; and generating, based on a message authentication code (MAC), a first output, wherein the MAC uses the at least one value provided by the at least one PUF as an input for generating the first output. 
     In various other embodiments described below, the method of  FIG. 4  can be performed on a system that includes: at least one physical unclonable function (PUF) device; a message authentication code (MAC) module configured to receive a first input based on at least one value provided by the at least one PUF device; at least one processor; and memory containing instructions configured to instruct the at least one processor to generate, based on the first input, a first output from the MAC module. 
     In one embodiment, the MAC module includes a circuit. In one embodiment, the first output from the MAC module is a key that identifies a die. In one embodiment, the first output from the MAC module is a root key, and the instructions are further configured to instruct the at least one processor to generate a session key using an output from the MAC module. 
     In one embodiment, the system is part of a semiconductor chip (e.g., one chip of several chips obtained from a semiconductor wafer), the first output from the MAC module is a unique value that identifies the chip, and the instructions are further configured to instruct the at least one processor to transmit the unique value to a computing device. 
     In one embodiment, the at least one PUF device comprises a plurality of PUF devices (e.g., PUF devices  202 ), and the system further comprises a selector module configured to select the at least one PUF device that provides the at least one value. 
     In one embodiment, the selector module is further configured to generate the first input for the MAC module by linking a first value from a first PUF device and a second value from a second PUF device. 
     In one embodiment, the system further comprises a monotonic counter configured to provide a counter value, and the instructions are further configured to instruct the at least one processor to generate the first input by linking the counter value with the at least one value provided by the at least one PUF device. 
     In one embodiment, the system further comprises a selector module configured to select the at least one PUF device that provides the at least one value, wherein linking the counter value with the at least one value provided by the at least one PUF device is performed by the selector module. 
     In one embodiment, the monotonic counter is further configured to increment, after generating the first input, the counter value to provide an incremented value; and the instructions are further configured to instruct the at least one processor to generate, based on the incremented value and at least one new value provided by the at least one PUF device, a second output from the MAC module. 
       FIG. 14  shows a system for generating a root key from an output of a MAC that receives inputs from one or more PUF devices and an input from a monotonic counter (and/or an input from another freshness mechanism like NONCE, time-stamp, etc.), and that adds an additional MAC to generate a session key, according to one embodiment. 
     In one embodiment, the system generates the root key from an output of a MAC that receives inputs from one or more PUF devices  202  and an input from a monotonic counter  302  (and/or an input from another freshness mechanism like NONCE, time-stamp, etc.), and that adds an additional MAC module  504  to generate a session key using a root key input, according to one embodiment. In this embodiment, MAC module  123  provides root key  502  as the output from MAC module  123 . Root key  502  is an input to the MAC module  504 , which can use a MAC function such as Session key=MACkey_based [Root_Key, MTC or other freshness mechanism], which was described above. The root key input in this key-based function can be root key  502 , as illustrated. 
     Additionally, in one embodiment, monotonic counter  302  can provide an input to the MAC module  504 . In other embodiments, a different monotonic counter or other value from the chip can be provided as an input to MAC module  504  instead of using monotonic counter  302 . In some cases, the monotonic counter  302  provides a counter value to MAC module  504 , but not to selector module  204 . In other cases, the counter value can be provided to both MAC modules, or excluded from both modules. 
     Key Generation and Secure Storage 
     As mentioned above, PUFs can be used for secure key generation. Various embodiments discussed below relate to generating an initial key using at least one PUF, applying processing to increase obfuscation of the initial key, and storing the final obfuscated key in a non-volatile memory. The final obfuscated key and/or an intermediate key used to generate the final obfuscated key can be shared with another computing device and used for secure communication with the other computing device (e.g., messaging using symmetric cryptography based on a shared key). In some embodiments, the secure key generation is done for computing devices to be used in automotive applications (e.g., a controller in an autonomous vehicle). 
     In alternative embodiments, the initial key is generated in other ways that do not require using the at least one PUF above. In one embodiment, the initial key can be generated by using an injected key. For example, the initial key is present in a chip due to being injected in a factory or other secure environment. In this case, the applying processing to increase obfuscation of the initial key is performed by applying obfuscation processing to the injected key. 
     The automotive environment presents the technical problem of introducing “noise” during the key generation phase. Various embodiments below provide a technological solution to this problem by using a methodology to diminish or avoid key variation due to this induced noise by storing an obfuscated key inside a non-volatile memory area. 
     The automotive environment can affect key generation in various ways. For example, engine power-on can cause a drop in application power to a computing device resulting in a key being generated in the wrong manner. Temperature extremes can also affect the circuit that generates the key. Other sources such as magnetic fields from power lines can cause inter-symbol interference or crosstalk, making a host not recognize the device. 
     In contrast, if the key is generated in a safe environment and is stored in memory, it will be immune from noise. A safe environment can be, for example, directly mounted in a car, in a test environment, or in a factory (e.g., that manufactures the computing device generating the key) depending on the strategy used to propagate the key between end users/customers of the computing device product. 
     In one example, ADAS or other computing systems as used in vehicles are subject to power supply variations. This can occur, for example, during turning on the vehicle, braking, powering the engine, etc. 
     Various embodiments to generate and store a key as discussed below provide the advantages of being substantially independent from external factors (e.g., power supply variations, temperature and other external sources of noise). Another advantage in some embodiments is that for every cycle, for example, the generation of the key vector is the same. 
     When storing the key, another advantage provided in some embodiments is that the key is substantially immune against hardware attack (e.g., that hackers might put in place). For example, one such attack is monitoring of the power-on current of a device so as to associate current variation to bits associated with the key. Other attacks can use, for example, voltage measurements (e.g., a Vdd supply voltage). Some attacks can use, for example, temperature variations to interfere with operation of a device. 
     In some embodiments, the initial key can be generated using the approaches and/or architectures as described above for  FIGS. 10-14 . For example, a PUF is used to generate the key for every power-on cycle of the computing device that is storing the key. In alternative embodiments, other approaches can be used to generate the initial key. 
     In one exemplary approach, as discussed earlier above, key injection uses at least one PUF and a MAC algorithm (e.g., SHA256) to generate a key for a device that is significantly different from other devices (e.g., from adjacent die located on a wafer). The MAC cryptography algorithm provides the benefit of increasing the entropy of the bits generated by the PUF. 
     In one embodiment, the generated key (e.g., the initial key as provided from a PUF and then a MAC algorithm) is stored in a non-volatile area of the device after preprocessing is performed on the key in order to diminish or avoid hacker attacks, and also to improve reliability of the stored key. In one embodiment, after the key is stored, the circuit generating the key can be disabled. The pre-processing is generally referred to herein as obfuscation processing. In one example, circuitry and/or other logic is used to implement the obfuscation processing on the device. In one example, the stored key can be read by the device because the key is independent from the external source of noise. An internal mechanism is used to read any data of the device. 
     In various embodiments, storing the key as described herein increases the margin against noise. Also, this makes it difficult for a hacker to read the stored key, for example, using a power monitoring or other hacking method. 
     At least some embodiments herein use a PUF and an encryption algorithm (e.g., HMAC-SHA256) to make the key generation independent from external factors such as temperature or voltage that may otherwise cause the key to be different from one power-on of the device to the next power-on. If this occurs, it can be a problem for a host to be able to exchange messages with the device. Various embodiments make the key generation more robust by placing the stored key in memory such that it is not impacted by external factors. 
     In one embodiment, the key is generated once on a device and stored in nonvolatile memory of the device. In one example, the key can be generated using the content of an SRAM before a reset is applied to the SRAM. The key, which is a function of the PUF, is generated using the pseudo random value output from the PUF. The content of the SRAM is read before a reset of the appliance or other device. The key can also be re-generated at other times through a command sequence, as may be desired. In one example, the generated key is used as a UDS in the DICE-RIoT protocol, as described above. In one example, the command sequence uses a replace command to replace a previously-generated UDS with a new UDS, as described above. 
     In one embodiment, the key generation is independent of the cryptography implemented by the device. The generated key is shared with a host. This embodiment stores the key and/or reads the key in the device in a way that avoids an attacker guessing the key and using it internally, such as for example by analyzing the shape of the current that the device absorbs during key usage. 
     In addition, for example, in asymmetric cryptography the generated key becomes the variable password that is the secret key of the system. The key is not shared with others. For public key cryptography, the key is used to generate a corresponding public key. 
     In various embodiments, an initial key is generated using an injected key or using one or more PUFs (e.g., to provide a initial key PUF 0 ). The initial key is then subjected to one or more steps of obfuscation processing to provide intermediate keys (e.g., PUF 1 , PUF 2 , PUF 5 ) such as described below. The output (e.g., PUF 5 ) from this processing is an obfuscated key that is stored in non-volatile memory of the device. When using an injected key, obfuscation processing is applied to the injected key similarly as described below for the non-limiting example of PUF 0 . 
     In one embodiment, as mentioned above, a mechanism is used as follows for the case of an initial injected key: 
       Session key=MACkey_based[Root_Key,MTC or other freshness mechanism] 
     Where: Root_Key=any other kind of key that is present on the chip (e.g., the key can be an initial key injected in the chip in a factory or other secure environment) 
     In one embodiment, on first power-up of a device, a special sequence wakes up at least one circuit (e.g., a read circuit) of the device and verifies that the circuit(s) is executing properly. The device then generates an initial key PUF 0 , as mentioned above. This key can be stored or further processed to make it more robust for secure storage, as described below. 
     An intermediate key, PUF 1 , is generated by concatenating PUF 0  with a predetermined bit sequence (e.g., a sequence known by others) to generate PUF 1 . In one embodiment, PUF 1  is used to verify the ability of the device to correctly read the key and to ensure that noise, such as fluctuations in the power supply, are not affecting the generated key. 
     A next intermediate key, PUF 2 , is generated. PUF 1  is interleaved with an inverted bit pattern (e.g., formed by inverting the bits of PUF 1 , and sometimes referred to herein as PUF 1  bar) to generate PUF 2 . 
     In one embodiment, PUF 2  has the same bit number of 0 s and 1 s. This makes the shape of the device current substantially the same for any key (e.g., any key stored on the device). This reduces the possibility of an attacker guessing the key value by looking at the shape of the device current when the key is being read by the device. 
     A next intermediate key, PUF 3 , is generated. The bits of PUF 2  are interleaved with pseudo-random bits to form PUF 3 . This further helps to obfuscate the key. In one embodiment, the pseudo-random bits are derived from PUF 1  or PUF 2  by using a hash function. For example, these derived bits are added to PUF 2  to form PUF 3 . 
     A next intermediate key, PUF 4 , is generated. Error Correction Codes (ECCs) are generated by the internal circuitry of the device (e.g., during programming). The bits of the ECC are added to PUF 3  to generate PUF 4 . In one embodiment, the ECC bits help guard against the effects of non-volatile memory (e.g., NVRAM) aging that can be caused by, for example, device endurance limits, X-rays and particles. Non-volatile memory aging can also be caused, for example, by an increase in the number of electrons in the NV cell which can cause bits to flip. 
     A next intermediate key, PUF 5 , is generated. PUF 5  is a concatenation of several copies of PUF 4 . Having the redundancy of multiple PUF 4  copies present in PUF 5  further increases robustness by increasing the likelihood of being able to correctly read the key at a later time. In one embodiment, several copies of PUF 5  are stored in various regions of non-volatile memory storage to further increase robustness. For example, even if PUF 5  is corrupted in one of the regions, PUF 5  can be read from other of the regions, and thus the correct key can be extracted. 
     In one embodiment, PUF 1  or PUF 3  is the key that is shared with a host for symmetric cryptography, or used to generate a public key for asymmetric cryptography. In one embodiment, PUF 4  and PUF 5  are not shared with end users or a host. 
     The above approach is modular in that PUF 2 , PUF 3 , PUF 4  and/or PUF 5  are not required for generating an obfuscated key. Instead, in various embodiments, one or more of the foregoing obfuscation steps can be applied to the initial key, and further the ordering can be varied. For example, the number obfuscation steps can be decreased for a system that is known not to have Vdd voltage supply drops. 
     In one embodiment, when storing the obfuscated key, the bit patterns will be physically spread around the non-volatile storage media (e.g., in different rows and words). For example, the device is able to read the bits at the same time and protect against multi-bit errors. 
       FIG. 15  shows a computing device  603  for storing an obfuscated key  635  in non-volatile memory (e.g., non-volatile storage media  109 ), according to one embodiment. Computing device  603  is an example of computing device  141  of  FIG. 1 . In one example, the obfuscated key is used as a UDS. (Note) For example, the obfuscation adds entropy to the bits of the key to avoid a possible attempt by a hacker to understand the value of the key. The device is always able to extract the key by removing the added bits used as obfuscation. In one example, a common hacker attack consists of guessing the secret key generated/elaborated inside the device by processing, with statistical tools, the current profile absorbed by the device in some particular timeframe. The obfuscation mitigates this problem in a considerable way. 
     An initial key  625  is generated based on a value provided by at least one physical unclonable function device  121 . The obfuscated key  635  is generated based on initial key  625 . After being generated, the obfuscated key  635  is stored in nonvolatile storage media  109 . 
     In one embodiment, a message authentication code (MAC)  123  uses the value from PUF device  121  as an input and provides the initial key  625  as an output. In one embodiment, obfuscation processing module  630  is used to perform processing on initial key  625  in order to provide obfuscated key  635  (e.g., PUF 5 ), for example as was discussed above. 
     In one embodiment, the obfuscated key  635  is securely distributed to another computing device as described in related U.S. Non-Provisional application Ser. No. 15/965,731, filed 27 Apr. 2018, entitled “SECURE DISTRIBUTION OF SECRET KEY USING A MONOTONIC COUNTER,” by Mondello et al., the entire contents of which application is incorporated by reference as if fully set forth herein. In other embodiments, initial key  625  and/or any one or more of the intermediate keys from the obfuscation processing described herein can be securely distributed in the same or a similar manner. Optionally, an end user/customer uses the foregoing approach to read the value of an initial key (e.g., PUF 0 ), an intermediate key, and/or a final obfuscated key (e.g., PUF 5 ). For example, the end user can verify the proper execution of the internal generation of the key by the device, and/or monitor the statistical quality of the key generation. 
       FIG. 16  shows an example of an intermediate key (PUF 2 ) generated during an obfuscation process by obfuscation processing module  630 , according to one embodiment. As mentioned above, the bits of PUF 1  are inverted to provide inverted bits  702 . Bits  702  are interleaved with the bits of PUF 1  as illustrated. For example, every second bit in the illustrated key is an interleaved inverted bit  702 . 
       FIG. 17  shows an example of another intermediate key (PUF 3 ) generated during the obfuscation process of  FIG. 16  (PUF 3  is based on PUF 2  in this example), according to one embodiment. As mentioned above, the bits of PUF 2  are further interleaved with pseudo-random bits  802 . As illustrated, bits  802  are interleaved with PUF 2 . For example, every third bit in the illustrated key is an interleaved pseudorandom bit  802 . 
       FIG. 18  shows a method for generating and storing an obfuscated key (e.g., obfuscated key  635 ) in a non-volatile memory (e.g., non-volatile storage media  109 ), according to one embodiment. In one example, memory system  105  of  FIG. 2  stores the obfuscated key in non-volatile memory  121 . 
     In block  911 , an initial key is generated based on a value provided by at least one physical unclonable function (PUF). 
     In other embodiments, in block  911 , the initial key is generated by key injection. For example, the initial key can simply be a value injected into a chip during manufacture. 
     In block  913 , an obfuscated key is generated based on the initial key. For example, the generated obfuscated key is PUF 3  or PUF 5 . 
     In block  915 , the obfuscated key is stored in a non-volatile memory of a computing device. For example, the obfuscated key is stored in NAND flash memory or an EEPROM. 
     In one embodiment, a method includes: generating an initial key using key injection; generating an obfuscated key based on the initial key; and storing the obfuscated key in non-volatile memory. For example, the initial key can be the key injected during a key injection process at the time of manufacture. 
     In one embodiment, a method comprises: generating an initial key provided by key injection or based on a value provided by at least one physical unclonable function (PUF); generating an obfuscated key based on the initial key; and storing the obfuscated key in a non-volatile memory of the computing device. 
     In one embodiment, generating the initial key comprises using the value from the PUF (or, for example, another value on the chip) as an input to a message authentication code (MAC) to generate the initial key. 
     In one embodiment, the obfuscated key is stored in the non-volatile memory outside of user-addressable memory space. 
     In one embodiment, generating the obfuscated key comprises concatenating the initial key with a predetermined pattern of bits. 
     In one embodiment, concatenating the initial key with the predetermined pattern of bits provides a first key (e.g., PUF 1 ); and generating the obfuscated key further comprises interleaving the first key with an inverted bit pattern, wherein the inverted bit pattern is provided by inverting bits of the first key. 
     In one embodiment, interleaving the first key with the inverted bit pattern provides a second key (e.g., PUF 2 ); and generating the obfuscated key further comprises interleaving the second key with pseudo-random bits. 
     In one embodiment, the method further comprises deriving the pseudorandom bits from the first key or the second key using a hash function. 
     In one embodiment, interleaving the second key with pseudo-random bits provides a third key (e.g., PUF 3 ); and generating the obfuscated key further comprises concatenating the third key with error correction code bits. 
     In one embodiment, the computing device is a first computing device, the method further comprising sharing at least one of the initial key, the first key, or the third key with a second computing device, and receiving messages from the second computing device encrypted using the shared at least one of the initial key, the first key, or the third key. 
     In one embodiment, concatenating the third key with error correction code bits provides a fourth key (e.g., PUF 4 ); and generating the obfuscated key further comprises concatenating the fourth key with one or more copies of the fourth key. 
     In one embodiment, concatenating the fourth key with one or more copies of the fourth key provides a fifth key (e.g., PUF 5 ); and storing the obfuscated key comprises storing a first copy of the fifth key on at least one of a different row or block of the non-volatile memory than a row or block on which a second copy of the fifth key is stored. 
     In one embodiment, a system comprises: at least one physical unclonable function (PUF) device (e.g., PUF device  121 ) configured to provide a first value; a nonvolatile memory (e.g., non-volatile storage media  109 ) configured to store an obfuscated key (e.g., key  635 ); at least one processor; and memory containing instructions configured to instruct the at least one processor to: generate an initial key based on the first value provided by the at least one PUF device; generate the obfuscated key based on the initial key; and store the obfuscated key in the non-volatile memory. 
     In one embodiment, the system further comprises a message authentication code (MAC) module (e.g., MAC  123 ) configured to receive values provided by the at least one PUF device, wherein generating the initial key comprises using the first value as an input to the MAC module to generate the initial key. 
     In one embodiment, generating the obfuscated key comprises at least one of: concatenating a key with a predetermined pattern of bits; interleaving a first key with an inverted bit pattern of the first key; interleaving a key with pseudo-random bits; concatenating a key with error correction code bits; or concatenating a second key with one or more copies of the second key. 
     In one embodiment, the stored obfuscated key has an equal number of zero bits and one bits. 
     In one embodiment, generating the obfuscated key comprises concatenating the initial key with a first pattern of bits. 
     In one embodiment, concatenating the initial key with the first pattern of bits provides a first key; and generating the obfuscated key further comprises interleaving the first key with a second pattern of bits. 
     In one embodiment, generating the obfuscated key further comprises interleaving a key with pseudo-random bits. 
     In one embodiment, generating the obfuscated key further comprises concatenating a key with error correction code bits. 
     In one embodiment, a non-transitory computer storage medium stores instructions which, when executed on a computing device, cause the computing device to perform a method, the method comprising: generating an initial key using at least one physical unclonable function (PUF); generating an obfuscated key based on the initial key; and storing the obfuscated key in non-volatile memory. 
       FIG. 19  shows computing device  1003  used for generating initial key  625  based on key injection  1010 , obfuscating the initial key, and storing the obfuscated key in non-volatile memory, according to one embodiment. 
     In one embodiment, the initial key  625  is generated by using the injected key  1010 . For example, initial key  625  is present in a chip by being injected in a factory or other secure environment during manufacture, or other assembly or testing. In one example, the initial key  625  is used as an initial UDS for computing device  1003 . The obfuscation can also be applied to the UDS. The UDS is the secret that the DICE-RIoT starts to use to generate the secure generation of keys and certificates. The applying processing to increase obfuscation of the initial key is performed by applying obfuscation processing (via module  630 ) to the injected key (e.g., the value from key injection  1010 ). In other embodiments, obfuscation processing can be applied to any other value that may be stored or otherwise present on a chip or die. 
     Variations of Key Generation and Secure Storage 
     Various additional non-limiting embodiments are now described below. In one embodiment, after (or during) first power up of a system board, a special sequence is activated to turn on the device containing a cryptographic engine (e.g., cryptographic module  127 ). The sequence further wakes-up the internal PUF and verifies its functionality, then the PUF generates an initial value PUF 0 , for instance as described above. The PUF 0  value is processed by an on-chip algorithm (e.g., by obfuscation processing module  630 ) and written in a special region of a non-volatile array (out of the user addressable space). In alternative embodiments, instead of the PUF 0  value, an injected key is processed by the on-chip algorithm similarly as described below to provide an obfuscated key for storage. 
     In one embodiment, obfuscation processing is performed to prevent Vdd (voltage) and/or temperature fault hacker attacks. This processing includes concatenating PUF 0  with a well-known pattern (e.g., which contains a fixed amount of 0/1 bits). These bits permit, during the life of the device (e.g., chip) when the PUF value is internally read, determining if the read circuitry is able to properly discriminate 0/1 bits. For example, PUF 1 =PUF 0  ∥ 010101 . . . 01. 
     Next, the result of the above processing (e.g., PUF 1 ) is further embodied with dummy bits (e.g., to avoid Icc hacker analysis). Specifically, for example, the bits of PUF 1  are interleaved with an inverted version of PUF 1  (i.e., PUF 1  bar, which is formed by inverting each bit of PUF 1 ). For example, PUF 2 =PUF 1  interleaved PUF 1  bar. 
     In one embodiment, the rule of interleaving depends on the kind of column decoder (e.g., of a NV non-volatile array) that is present on the chip/device. The device ensures that at each read of the PUF value (from the non-volatile array), the read circuitry processes (in a single shot) the same number of bits from PUF 1  and PUF 1  bar. This ensures reading the same number of bits at values of 0 and 1, which provides a regular shape in the supply current (Idd). 
     Next, the bits of PUF 2  are further interleaved with pseudo-random bits. In one example, the interleaving depends on the non-volatile array column decoder structure. In one embodiment, the output has the same number of PUF 2  bits stuffed with a certain number of pseudo-random bits (e.g., in order to obfuscate an eventual residual correlation that may be present in the PUF 2  pattern). 
     In one embodiment, the pseudo-random bits can be derived from PUF 1  or PUF 2  by using a hash function. Other alternative approaches can also be used. 
     In one embodiment, optionally, to reduce or prevent bit loss due to nonvolatile aging, the bits of PUF 3  are concatenated with error correction code (ECC) bits. In one embodiment, the bits of PUF 4  are optionally replicated one or more times (which also extends ECC capabilities). For example, the foregoing may be implemented on a NAND memory. In one example, PUF 5 =PUF 4  ∥ PUF 4  ∥ . . . ∥ PUF 4 . 
     In one embodiment, the value of PUF 5  can be written two or more times on different rows and or blocks of a non-volatile memory array. 
     As a result of the above obfuscation processing, for example, once the final PUF value is written into a non-volatile array block, the value can be used with diminished or no concern about key reliability (e.g., due to noise, or charge loss), or any attempt to infer its value by Idd analysis or forcing its value by Vdd fault attack. 
     In one embodiment, once obfuscation processing is completed, the PUF circuitry can be disabled. In one embodiment, after disablement, the PUF device can provide values used internally on a device for other purposes (e.g., using a standard read operation inside the non-volatile array). 
     In one embodiment, key bits are differentiated from random bits when extracting a key from PUF 3 . For example, internal logic of a device storing a key is aware of the position and method required to return from PUF  5  to a prior or original PUF (e.g., PUF 3 ). 
     In one embodiment, the bit positions of key bits are known by the device extracting the key. For example, the internal logic of the device can receive one of the intermediate PUF or the final key PUF 5 , depending on design choice. Then, applying the operation(s) in the reverse order will obtain the original PUF. For example, the processing steps from PUF 1  to PUF 5  are executed to store the obfuscated PUF in a manner that a hacker would have to both: read the content (e.g., key bits), and also know the operation(s) that were applied in order to get back to and determine the original key. 
     Closing 
     A non-transitory computer storage medium can be used to store instructions of the firmware  104 , or to store instructions for processor  143  or processing device  111 . When the instructions are executed by, for example, the controller  107  of the memory device  103  or computing device  603 , the instructions cause the controller  107  to perform any of the methods discussed above. 
     In this description, various functions and operations may be described as being performed by or caused by computer instructions to simplify description. However, those skilled in the art will recognize what is meant by such expressions is that the functions result from execution of the computer instructions by one or more controllers or processors, such as a microprocessor. Alternatively, or in combination, the functions and operations can be implemented using special purpose circuitry, with or without software instructions, such as using Application-Specific Integrated Circuit (ASIC) or Field-Programmable Gate Array (FPGA). Embodiments can be implemented using hardwired circuitry without software instructions, or in combination with software instructions. Thus, the techniques are limited neither to any specific combination of hardware circuitry and software, nor to any particular source for the instructions executed by the data processing system. 
     While some embodiments can be implemented in fully-functioning computers and computer systems, various embodiments are capable of being distributed as a computing product in a variety of forms and are capable of being applied regardless of the particular type of machine or computer-readable media used to actually effect the distribution. 
     At least some aspects disclosed can be embodied, at least in part, in software. That is, the techniques may be carried out in a computer system or other data processing system in response to its processor, such as a microprocessor or microcontroller, executing sequences of instructions contained in a memory, such as ROM, volatile RAM, non-volatile memory, cache or a remote storage device. 
     Routines executed to implement the embodiments may be implemented as part of an operating system or a specific application, component, program, object, module or sequence of instructions referred to as “computer programs.” The computer programs typically comprise one or more instructions set at various times in various memory and storage devices in a computer, and that, when read and executed by one or more processors in a computer, cause the computer to perform operations necessary to execute elements involving the various aspects. 
     A tangible, non-transitory computer storage medium can be used to store software and data which, when executed by a data processing system, causes the system to perform various methods. The executable software and data may be stored in various places including for example ROM, volatile RAM, non-volatile memory and/or cache. Portions of this software and/or data may be stored in any one of these storage devices. Further, the data and instructions can be obtained from centralized servers or peer-to-peer networks. Different portions of the data and instructions can be obtained from different centralized servers and/or peer-to-peer networks at different times and in different communication sessions or in a same communication session. The data and instructions can be obtained in their entirety prior to the execution of the applications. Alternatively, portions of the data and instructions can be obtained dynamically, just in time, when needed for execution. Thus, it is not required that the data and instructions be on a machine-readable medium in their entirety at a particular instance of time. 
     Examples of computer-readable storage media include, but are not limited to, recordable and non-recordable type media such as volatile and non-volatile memory devices, read only memory (ROM), random access memory (RAM), flash memory devices, floppy and other removable disks, magnetic disk storage media, and optical storage media (e.g., Compact Disk Read-Only Memory (CD ROM), Digital Versatile Disks (DVDs), etc.), among others. The instructions may be embodied in a transitory medium, such as electrical, optical, acoustical or other forms of propagated signals, such as carrier waves, infrared signals, digital signals, etc. A transitory medium is typically used to transmit instructions, but not viewed as capable of storing the instructions. 
     In various embodiments, hardwired circuitry may be used in combination with software instructions to implement the techniques. Thus, the techniques are neither limited to any specific combination of hardware circuitry and software, nor to any particular source for the instructions executed by the data processing system. 
     Although some of the drawings illustrate a number of operations in a particular order, operations that are not order dependent may be reordered and other operations may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be apparent to those of ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof. 
     The above description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding. However, in certain instances, well known or conventional details are not described in order to avoid obscuring the description. References to one or an embodiment in the present disclosure are not necessarily references to the same embodiment; and, such references mean at least one. 
     In the foregoing specification, the disclosure has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.