SRAM Physical Unclonable Function (PUF) memory for generating keys based on device ownership

Abstract

A device having a boot code, a first variable code stored in a non-volatile memory, first owner information stored in the non-volatile memory, and an SRAM having an SRAM Physical Unclonable Function (SRAM PUF) region. The boot code can generate a first unique secret key based on both the first owner information and a portion of the SRAM PUF region, where the first unique secret key may not be directly accessible by the first variable code, generate a first unique secret key code corresponding to the first unique secret key, and provide the first unique secret key code corresponding to the first unique secret key to the first variable code. The first variable code can use the first unique secret key code to sign data with the first unique secret key and generate the first unique variable code secret key based on at least a portion of the SRAM PUF region.

Description

[Technical field]

[0001] (Priority) This application claims priority to U.S. Provisional Patent Application No. 63 / 335,442, filed April 27, 2022, the contents of which are incorporated herein in their entirety.

[0002] FIELD OF THEINVENTION The present disclosure relates to electronic devices, and more particularly to systems and methods for using a static random-access memory (SRAM) physically unclonable function (PUF) shared by multiple entities to manage device keys. [Background technology]

[0003] In computing products, an embedded controller (EC) boot code stored in a boot ROM may act as a root of trust (RoT) for a secure boot application for a particular owner (e.g., an original equipment manufacturer (OEM)) of an electronic device. The OEM may store configuration options in a one-time-programmable (OTP) memory during device provisioning. This may include cryptographic keys used to encrypt and sign the boot image. The OEM may implement and sign an EC boot image that is loaded and authenticated by the boot code stored in the boot ROM. The boot code may use custom values ​​stored in the OTP memory to authenticate and decrypt the boot image. Other features supported by the boot code may include key revocation and rollback protection. This may enable the owner to deactivate one or more of the keys stored in the electronic device's key manifest or remove a particular image revision from service by setting a bit in the OTP memory specifically during the boot sequence.

[0004] An EC with Secure Boot typically has a single configuration provisioned in the OTP memory determined at manufacturing time by the first owner (e.g., OEM). An image authentication key manifest is generated, hashed, and stored in a key hash blob (KHB), and the hash of the KHB is stored in the OTP memory. As a result, all owners of the device use OEM-signed images.

[0005] An EC with secure boot may belong to multiple owners over the life of the device, and therefore device secrets (e.g., cryptographic keys) must be managed to ensure that these secrets are maintained for each application (e.g., owner). Summary of the Invention

[0006] According to one embodiment, a system may include an electronic device. The electronic device may have a boot code, a variable code stored in a non-volatile memory, first owner information stored in the non-volatile memory, and a static random access memory (SRAM) including a SRAM physically unclonable function (SRAM PUF) area. In some embodiments, the SRAM PUF area includes a secret, unclonable silicon fingerprint unique to the electronic device. The boot code may include an immutable code stored in a read-only memory, an authenticated code stored in a non-volatile memory, an authenticated code stored in a volatile memory, or a mixture of the immutable code and the authenticated code. The boot code may be executable by a processor to generate a first unique secret key based on both the first owner information and at least a portion of the SRAM PUF area, the first unique secret key not being directly accessible by the variable code. The boot code may be executable by the processor to generate a first unique secret key code corresponding to the first unique secret key and provide the first unique secret key code to the variable code. The variable code may be executable by the processor to cause the data to be signed with the first unique private key using the first unique private key code and to generate the first unique variable code private key based on at least a portion of the SRAM PUF region.

[0007] According to the same or different embodiment, the first owner information stored in the non-volatile memory may emulate information stored in the one-time programmable memory and may be unique to the first owner of the electronic device. The boot code may be executable by the processor to transfer ownership of the electronic device to a second owner, including storing second owner information in the non-volatile memory, the second owner information may be unique to the second owner of the electronic device. The boot code may be executable by the processor to generate a second unique secret key based on both the second owner information and at least a portion of the SRAM PUF region, the second unique secret key not being directly accessible by the variable code. The boot code may be executable by the processor to generate a second unique secret key code corresponding to the second unique secret key, provide a variable code having the second unique secret key code, and prohibit access to or regeneration of the first unique secret key while the second owner has possession of the electronic device.

[0008] According to the same or different embodiment, a reset of the electronic device may cause the first unique private key to be erased. The boot code may be executable by the processor to generate, following a reset of the electronic device, a regenerated first unique private key that is equivalent to the first unique private key and is not directly accessible by the variable code. The variable code may be executable by the processor to cause data to be signed with the regenerated first unique private key using the first unique private key code.

[0009] Another embodiment provides a method for an electronic device having a processor, a non-volatile memory, and an SRAM including an SRAM PUF region, in some embodiments, the SRAM PUF region includes a secret, unclonable silicon fingerprint that is unique to the electronic device. The method may include the steps of: (1) storing first owner information and a first owner variable code in a non-volatile memory; (2) generating a first unique secret key based on both the first owner information and at least a portion of the SRAM PUF area, where the first unique secret key is not directly accessible by the first owner variable code; (3) generating a first unique secret key code corresponding to the first unique secret key; (4) providing the first unique secret key code corresponding to the first unique secret key to the first owner variable code; (5) receiving a signature request from the first owner variable code, where the signature request includes the first unique secret key code and first data; and (6) in response to the signature request from the first owner variable code, signing the first data with the first unique secret key and providing the first data signed with the first unique secret key to the first owner variable code.

[0010] In the same or a different embodiment, the method may include the steps of: a processor receiving a key generation request from a first owner variable code; and in response to the key generation request from the first owner variable code, the processor generating a first owner-specific variable code key based on at least a portion of the SRAM PUF area.

[0011] In the same or a different embodiment, the method may include a processor: (1) transferring ownership of the electronic device to a second owner including storing second owner information and a second owner variable code in a non-volatile memory, where the second owner information is unique to the second owner of the electronic device; (2) generating a second unique private key based on both the second owner information and at least a portion of the SRAM PUF area, where the second unique private key is not directly accessible by the second owner variable code; (3) generating a second unique private key code corresponding to the second unique private key; (4) providing the second owner variable code with the second unique private key code corresponding to the second unique private key; and (5) prohibiting access to or regeneration of the first unique private key while the second owner is in possession of the electronic device. In some embodiments, the method may include the steps of: receiving, by the processor, a second owner signature request from a second owner variable code, the second owner signature request including a second unique secret key code and the second data, and, in response to the second owner signature request from the second owner variable code, signing the second data with the second unique secret key and providing the second data signed with the second unique secret key to the second owner variable code. In other embodiments, the method may include the steps of: receiving, by the processor, a key generation request from the second owner variable code, and, in response to the key generation request from the second owner variable code, generating a second unique owner variable code key based on at least a portion of the SRAM PUF region.

[0012] According to the same or different embodiment, a reset of the electronic device may cause the first unique private key to be destroyed. The method may include a processor (1) generating, following a reset of the electronic device, a regenerated first unique private key that is equivalent to the first unique private key and is not directly accessible by the first owner variable code, and (2) signing a first data with the regenerated first unique private key using the first unique private key code.

[0013] According to the same or a different embodiment, the method may include receiving, by a processor, a public key request from a first owner variable code, the public key request including a first unique public key code. In response to the public key request, the method may include generating, by the processor, a first unique public key corresponding to the first unique private key, and providing the first unique public key to the first owner variable code.

[0014] According to the same or a different embodiment, the method may include the steps of: a processor generating a first unique public key corresponding to the first unique private key; generating a certificate having the first unique public key as a certifying subject; and generating a signature of the certificate using the device identity private key. According to one embodiment, the method may include the processor providing the certificate having the first unique public key as a certifying subject to a first owner variable code.

[0015] Another embodiment provides a method for an electronic device having a processor, a non-volatile memory, and an SRAM including an SRAM PUF area, the method may include storing first owner information and a first owner variable code in the non-volatile memory. The method may include the steps of a processor: (1) generating a device identification private key based on at least a portion of the SRAM PUF area; (2) generating a first unique private key based on both the first owner information and at least a portion of the SRAM PUF area, where the first unique private key is not directly accessible by the first owner variable code; (3) generating a first unique public key corresponding to the first unique private key; (4) generating a first unique private key code corresponding to the first unique private key; (5) generating a certificate having the first unique public key as an object of certification; (6) signing the certificate using the device identification private key; (7) providing the first owner variable code with the first unique private key code; and (8) providing the certificate having the first unique public key as an object of certification to the first owner variable code.

[0016] In the same or different embodiment, the method may include erasing the first unique private key during a reset of the electronic device. The method may include the processor generating a regenerated first unique private key following the reset of the electronic device, the regenerated first unique private key being equivalent to the first unique private key and not directly accessible by the first owner variable code, and receiving a signature request from the first owner variable code, the signature request including the first unique private key code and the first data. In response to receiving the signature request from the first owner variable code, the method may include the processor signing the first data with the regenerated first unique private key, and providing the first data signed with the regenerated first unique private key to the first owner variable code. [Brief description of the drawings]

[0017] The figures illustrate example methods and systems for managing ownership of electronic devices, including secure transfer of ownership of electronic devices over time. [Figure 1] 1 shows a block diagram of an example system for managing ownership of electronic devices, including through secure transfer of ownership of electronic devices over time. [Diagram 2] 1 illustrates a block diagram of an example OTP memory for managing ownership of electronic devices, including through secure transfer of ownership of electronic devices over time. [Diagram 3] 1 illustrates a block diagram of an example secure RPMC owner container for managing ownership of electronic devices, including through secure transfer of ownership of electronic devices over time. [Figure 4] 1 illustrates a block diagram of an example container header of an owner container for managing ownership of an electronic device. [Diagram 5] 1 illustrates a block diagram of example container contents of an owner container for managing ownership of electronic devices. [Figure 6] 1 illustrates a block diagram of example container contents of an owner container for managing ownership of electronic devices. [Figure 7] 1 illustrates an exemplary command memory. [Figure 8] 1 illustrates a block diagram of an embodiment of managing ownership of an electronic device, including creating a first owner container using an OEM signed image and an OTP configuration. [Figure 9] FIG. 1 illustrates a block diagram of an embodiment of managing ownership of an electronic device, including creating a first owner container using an OEM signed image and an OTP emulation configuration. [Figure 10] 1 illustrates a flowchart of an example method for managing ownership of electronic devices, including secure transfer of ownership of electronic devices over time. [Figure 11]1 shows a block diagram of two embodiments for managing ownership of electronic devices using unlimited transfer and an owner transfer authorization key (OTAK). [Figure 12] 1 shows a block diagram of two embodiments for managing ownership of electronic devices using unlimited transfer and an owner transfer authorization key (OTAK). [Figure 13] FIG. 1 illustrates a block diagram of an embodiment of managing ownership of an electronic device, including transferring ownership using a container command key (CCK) of a current owner and a first mutable binary (FMB) configuration stored in an OTP memory. [Figure 14] 1 illustrates a flowchart of an example method for managing ownership of electronic devices, including secure transfer of ownership of electronic devices over time. [Figure 15] 1 illustrates a flowchart of an example method for managing ownership of electronic devices, including secure transfer of ownership of electronic devices over time. [Figure 16] 1 illustrates an exemplary volatile SRAM memory with a physically unclonable function (PUF) region that may be used for cryptographic key management. [Figure 17] 1 shows a flowchart of an exemplary method for SRAM PUF enrollment and subsequent key reconstruction. [Figure 18] 1 illustrates an exemplary electronic device that can respond to Secure Protocol Data Model (SPDM) commands. [Figure 19] 1 illustrates an exemplary electronic device having an SRAM PUF shared by multiple entities to manage device keys. [Figure 20] 1 illustrates an exemplary boot code method for DevAK key and certificate generation. [Figure 21]1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Figure 22] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Diagram 23] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Figure 24] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Diagram 25] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Figure 26] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Figure 27] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Figure 28] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Figure 29] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Figure 30a] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys. [Figure 30b] 1 shows a flowchart of an example method for using an SRAM PUF shared by multiple entities to manage device keys.

[0018] Reference numerals for any illustrated element that appear in different figures have the same meaning throughout the figures, and any mention or discussion herein of any illustrated element in the context of any particular figure also applies to each of the other figures, if any, in which the same illustrated element is shown. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] The present disclosure provides systems and methods for managing device keys, for example, to provide device authentication (attestation) for multiple applications (e.g., multiple owners of an electronic device over time) while maintaining the secrecy of each application's (e.g., owner's) device private key. In some embodiments, the present disclosure provides systems and methods for key management where both the boot code and the first mutable code (FMC) can generate or use the same device attestation key pair. In the same or other embodiments where an electronic device may belong to multiple owners over the life of the device, the present disclosure provides systems and methods for generating device keys as a function of the current owner of the electronic device such that no two owners can have the same private key (e.g., device attestation key).

[0020] The present disclosure provides systems and methods for supporting multiple owners of a particular electronic device over time, including secure transfer of ownership between different owners, by storing each owner's information and configuration in a signed secure replay protected monotonic counter (RPMC) owner container in memory, for example, serial peripheral interface (SPI) flash memory. In one embodiment, owner cryptographic keys, secrets, and configuration information may be stored in a secure manner in non-volatile memory (NVM) (e.g., OTP memory, SPI flash memory, or electrically erasable programmable read-only memory (EEPROM)). Since the secure information may be stored in erasable memory, the contents may be signed and verified before being used to aid security. In some embodiments, the systems and methods for storing and updating signed secure RPMC owner containers may comply with the NIST 800-193 Platform Firmware Resiliency Guidelines. As used herein, "secure RPMC owner container," "RPMC owner container," and "owner container" refer to a signed secure RPMC owner container.

[0021] When an electronic device (e.g., a microcontroller) boots up (e.g., upon power-on or after a hardware or software reset), boot code may be loaded and executed by a processor of the device. The boot code may perform functions related to device startup, such as initializing hardware, which may include disabling interrupts, initializing buses, setting the processor to a particular state, and initializing memory. After performing the hardware initialization, the boot code may load a first variable code (FMC), for example, from a signed first variable binary (FMB), which may include one or more images. In one embodiment, the FMC may be application firmware, which may be signed by an OEM or other owner of the electronic device. In the same or different embodiment, the FMC may be an OEM or other proprietary application firmware, a ROM extension (ROM_EXT) or boot code extension, a Robust Internet of Things (RIoT) code, or other variable code. The functions performed by the boot code may be referred to as a boot process.

[0022] The electronic device may include security mechanisms to protect the device from malicious attacks. For example, the electronic device may prevent (1) the loading and execution of the FMC, (2) the transfer of ownership of the electronic device, or (3) crisis recovery by anyone other than the silicon owner. In one embodiment, these actions may require knowledge of a secret (e.g., a cryptographic key) known to the silicon owner. Because the silicon owner controls the secret (e.g., a cryptographic key) used for loading and execution of the FMC, the transfer of ownership, and crisis recovery, malicious attacks on the device may be reduced.

[0023] The silicon owner or electronic device owner may be an entity that provides a signed FMB that is loaded and authenticated by the boot code. The FMB may contain an FMC image that is loaded and executed by the boot code. The owner may provide a KHB that may contain hashes of each of the public keys that may be used to authenticate the FMB. For example, during manufacturing, a hash of the OEM KHB may be stored in the OTP memory, and the OEM KHB itself may be stored in non-volatile memory (e.g., SPI flash). The boot code may calculate SHA384(OEM KHB) and compare it to the hash of the OEM KHB stored in the OTP memory. If the calculated hash matches the stored hash, the boot code may trust the public key hashes stored in the OEM KHB and use them to authenticate the OEM FMB. The OEM may establish ownership during manufacturing (e.g., OEM as implied owner) or when ownership is requested by another entity. Once ownership is established, the silicon owner can use an OEM image signed by the OEM image signing key, or the owner can provide his own image signed by his own image signing key. In the latter embodiment, the owner-provided KHB hash value may be stored in the secure RPMC owner container, and the owner-provided KHB may be stored in non-volatile memory (e.g., SPI flash). The owner's image signing key can be verified by the hash stored in the owner-provided KHB. For example, the boot code can calculate SHA384(owner-provided KHB) and compare it to the stored owner-provided KHB hash value. If the calculated hash matches the stored hash, the boot code can trust the public key hash stored in the owner-provided KHB and use them to authenticate the owner-provided FMB.

[0024] Security features for an electronic device may be implemented using the boot code of the electronic device. In one embodiment, the security features may be implemented using immutable boot code. The immutable boot code, which may be referred to as a hardware root of trust (RoT), may be built into the electronic device during manufacture and therefore may be implicitly trusted because it cannot be altered.

[0025] For purposes of this disclosure, an electronic device may include any means or collection of means operable to compute, classify, process, transmit, receive, search, originate, exchange, store, display, manifest, detect, record, play, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, an electronic device may be a personal computer, a Personal Digital Assistant (PDA), a home electronic device, a server, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. An electronic device may include one or more processing resources, such as a memory, a Central Processing Unit (CPU), or hardware or software control logic. Additional components of an electronic device may include one or more storage devices, one or more communication ports for communicating with external devices, and various Input and Output (I / O) devices, such as a keyboard, a mouse, and a video display. An electronic device may also include one or more buses operable to transmit communications between various hardware components.

[0026] system 1 illustrates a block diagram of an exemplary system 100 for managing ownership of an electronic device 101, including through secure transfer of ownership of the electronic device over time. As shown in FIG. 1, the system 100 may include an electronic device 101. Components of the electronic device 101 may include, but are not limited to, one or more processors 160 and a system bus 121 that communicatively couples various system components to the processor 160, including, for example, an OTP memory 110, a ROM 130, a memory 170, an I / O and port control 190, and a network interface 150. The system bus 121 may be any suitable type of bus structure, such as a memory bus, a peripheral bus, or a local bus using any of a variety of bus architectures.

[0027] Processor 160 may include any system, device, or apparatus operable to interpret or execute program instructions or process data, including, but not limited to, a microprocessor, a microcontroller, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or any other digital or analog circuitry for interpreting or executing program instructions or process data. In some embodiments, processor 160 may interpret or execute program instructions or process data stored locally (e.g., in memory 170, ROM 130, OTP memory 110, or another component of electronic device 101). In the same or alternative embodiments, processor 160 may interpret or execute program instructions or process data stored remotely.

[0028] The OTP memory 110 (one-time programmable memory) may include any system, device, or apparatus that can be programmed only once and then retain the programmed data. The OTP memory 110 may include one-time programmable bits 120a, 120b, etc. In one embodiment, the bits 120a and 120b of the OTP memory 110 may include conventional logic gates connected with metal wiring, and the connections may be paired with fuses. During programming, the fuses may be blown to make these connections permanent. In this way, the OTP memory 110, once programmed, may be unmodifiable. In one embodiment, the unprogrammed bits (e.g., 120a, 120b) may return a value of 0 when read by the processor 160, while the programmed bits may return a value of 1 when read by the processor 160. According to this embodiment, once the bits 120a, 120b are programmed with a value of 1, they cannot be reprogrammed to a value of 0.

[0029] ROM 130 may include any system, device, or apparatus (e.g., non-volatile memory) operable to retain program instructions or data after power to electronic device 101 is turned off. ROM 130 (e.g., boot ROM) may include boot code 140 that may be used by processor 160 during the boot process (or startup) of electronic device 101. According to one embodiment, boot code 140 may be immutable, i.e., built into the electronic device during manufacturing, and therefore may be implicitly trusted (e.g., hardware root of trust) because it cannot be altered. Boot code 140 may include code to perform functions, including, but not limited to, functions F1 (145a) and F2 (145b), among others. In one embodiment, function F1 may be boot code. In the same or a different embodiment, function F2 may be part of a runtime application programming interface (API), such as PUF engine 1955 (FIG. 19). In one embodiment, boot code 140 may be authenticated alterable code that may function as a ROM extension (e.g., an FMC that may be authenticated by other boot code stored in a ROM, where the FMC may be stored in volatile memory 172 or non-volatile memory 173). In one embodiment, boot code 140 may include both immutable code (e.g., stored in ROM 130) and authenticated alterable code that may function as a ROM extension.

[0030] Memory 170 may include any system, device, or apparatus operable to retain program instructions or data for a period of time. Memory 170 may include random access memory (RAM, SRAM, DRAM), EEPROM, PCMCIA cards, flash memory (e.g., SPI flash), magnetic storage devices, magneto-optical storage devices, hardware registers, or any suitable selection or array of volatile or non-volatile memory. In the illustrated embodiment, memory 170 includes, but is not limited to, command memory 171, volatile memory 172, and non-volatile memory 173.

[0031] I / O and port control 190 may include any system, device, or apparatus generally operable to receive or transmit data to / from / within electronic device 101. I / O and port control 190 may include, for example, any number of communications interfaces, graphics interfaces, video interfaces, user input interfaces, or peripheral interfaces (such as, but not limited to, JTAG, I2C, UART, Test Access Port). I / O and port control 190 may be communicatively coupled to external ports / pins 180-1, 180-2, ... 180-N (and others not shown).

[0032] Network interface 150 may be any suitable system, apparatus, or device operable to act as an interface between electronic device 101 and network 155. Network interface 150 may enable electronic device 101 to communicate over network 155 using any suitable transmission protocol or standard. Network 155 and its various components may be implemented using hardware, software, or any combination thereof.

[0033] Although FIG. 1 illustrates various components of electronic device 101, other example systems may include electronic devices having more or fewer components. In an embodiment, electronic device 101 according to the present disclosure may not include one or all of the components depicted in dashed lines without departing from the spirit and scope of these disclosed embodiments. Additionally, various components of electronic device 101 may reside on the same die (e.g., a primary die) or may reside on separate dies. In an embodiment, various components may reside within a package in a multi-chip module (MCM) or external to a system board. In the same or different embodiments, various components of electronic device 101 may reside in one or more of a primary die, an MCM, and external to a system board.

[0034] OTP Memory 2 illustrates a block diagram of an example OTP memory 110 for managing ownership of an electronic device 101, including through secure transfer of ownership of the electronic device over time. As shown in FIG. 2, the OTP memory 110 can include multiple fields including a current RPMC value 202, a boot code generated random secret 203, a device specific random secret 204, a serial number 205, a personalization string 206, secret device specific information 207, and an RPMC flash container state 208.

[0035] The current RPMC value 202 may be provided by a replay-protected monotonic counter that is incremented over time. In the embodiment shown in Table 1, the current RPMC value 202 may be a value stored in an 8-bit region in the OTP memory 110, which may correspond to nine different values ​​(0-8). In this embodiment, the bits in the OTP memory 110 for the current RPMC value 202 may be set consecutively from the least significant bit ([0]) to the most significant bit ([8]), and the next RPMC value may be the next integer value after the current RPMC value 202. In the same or different embodiment, a value less than the current RPMC value 202 may be considered to be cancelled and a value greater than the current RPMC value 202 may be considered to be unused. In the example shown in Table 1, values ​​greater than 8 may not be used. In other embodiments in which more than 8 bits in the OTP memory 110 are allocated to the current RPMC value 202, values ​​greater than 8 may be possible. A value less than the current RPMC value 202 may be considered cancelled since the OTP memory 110 may never be programmed to a lesser value since OTP memory, by definition, may only be programmed once. For example, when the current RPMC value 202 has a value of 1, the least significant bit is programmed and cannot be deprogrammed to reset the current RPMC value 202 back to a value of 0.

[0036] Table 1 [Table 1]

[0037] The boot code generated random secret 203 can be any random information generated by and accessible only to the boot code 140. For example, the boot code generated random secret 203 can be a random number generated by the boot code 140 after provisioning of the electronic device 101 is complete. The device specific random secret 204 can be any random information unique to the electronic device 101. In one embodiment, the device specific random secret 204 can be a device specific random number programmed into the OTP memory 110 during provisioning (e.g., by a tester). In another embodiment, the device specific random secret 204 can be a random number generated by the boot code 140 after provisioning of the electronic device 101 is complete. The serial number 205 is a unique serial number assigned to the electronic device 101 and programmed into the OTP memory 110 during provisioning (e.g., by a tester). The personalization string 206 can be a known string programmed into the OTP memory 110 during provisioning (e.g., by a tester). In an alternative embodiment, the personalization string 206 may be hard-coded into the boot code 140 instead of being stored in the OTP memory 110 .

[0038] The private device specific information 207 may include (a) a device identity key (“DevIK”) (e.g., the private key of a public key / cryptographic key pair) or information from which a DevIK may be generated, (b) critical device configurations, such as image authenticity and key authenticity, (c) other cryptographic keys used by the electronic device 101, or (d) other device specific information. In some embodiments, the private device specific information 207 may include (a) a unique device secret (UDS) or an encrypted UDS, or (b) a ROM seed (e.g., a random number generated by the boot code 140), which may use such UDS and ROM seed as source data to generate the DevIK or other device specific information.

[0039] RPMC flash container state 208 may indicate whether RPMC owner functionality is enabled. In one embodiment, RPMC owner functionality may be disabled by default at the time of manufacture, and this disabled state may be reflected in RPMC flash container state 208. Boot code 140 may program RPMC flash container state 208 to indicate that owner functionality is enabled when the first owner container is created.

[0040] Although FIG. 2 illustrates various regions of OTP memory 110, other example systems may include electronic devices having more or fewer regions.

[0041] RPMC Owner Container FIG. 3 illustrates a block diagram of an exemplary secure RPMC owner container 302 (owner container 302) for managing ownership of an electronic device 101, including through secure transfer of ownership of the electronic device over time. In one embodiment, the owner container 302 may be a signed data image stored in a non-volatile memory (e.g., OTP memory 110, non-volatile memory 173, among others) that may contain current silicon owner configuration information and secrets that enable the boot code 140 to load and execute an owner executable image (e.g., FMC in FMB). As shown in FIG. 3, the owner container 302 may include three areas: a container header 310, a container content 311, and a container signature 312. In one embodiment, the owner container 302 may be a unique signed container of information modified, stored, and retrieved from an OTP memory (e.g., OTP memory 110) or other non-volatile memory (e.g., non-volatile memory 173) by the code creating the container (e.g., boot code 140 or a ROM extension (e.g., in an authenticated FMC)). According to an embodiment of the present disclosure, the owner container 302 may only be signed and updated by the code that created the container. Higher level firmware (e.g., code other than the code that created the container) may require a command interface (e.g., command memory 171 of FIG. 7) to access or modify information in the owner container 302. In one embodiment, only immutable boot code (e.g., boot code 140) may access or modify information in the owner container 302. In one embodiment, the boot code that creates the owner container 302 may create two redundant copies of the owner container 302. One copy may be the primary owner container and the other copy may be the fallback owner container.

[0042] -Container signing The container signature 312 may include a signature corresponding to the owner container 302 and may be generated by the boot code 140. In one embodiment, the boot code 140 may use a physically unclonable function (PUF) or a deterministic random bit generator (DRBG) to generate an ECDSA signing key. The ECDSA signing key may be generated by any signing algorithm. For example, the container signature 312 may be an ECDSA-384 signature with the following properties: · Algorithm: Elliptic Curve Digital Signature Algorithm (ECDSA) Key size: 384 bits ·Curve: NIST “secp384r1” curve Hash algorithm: SHA384 · Signed message (m) = {container header 310 | container content 311}

[0043] The boot code 140 may derive an ECDSA private signing key used to sign the owner container 302. In one embodiment, the signing key may be generated as a function of the current owner and a unique silicon die. Thus, it may be possible to have a unique signature per owner per silicon die. According to one embodiment, the boot code 140 may derive the ECDSA private signing key using the DRBG and may provide the following inputs to the DRBG: Personalization string: A known string, e.g. "Container * one * It may also be "Key Generator". · Additional input: Can be {RPMC value 431|device serial number 435}. Entropy input: may be a device-specific random secret 204. True Random Number Generator (TRNG) Input: may be the boot code generated random secret 203.

[0044] In the above embodiment, boot code 140 may generate an ECDSA private signing key using a method from Section B.4.1 Key Pair Generation with Additional Random Bits of the FIPS 186-4 specification. private key (d) d=(c mod(n-1))+1 n = a prime number defined for the P-384 curve c = 448-bit random positive integer value

[0045] In one embodiment, boot code 140 may extract the first 448-bit positive integer value generated by the DRBG and use that value for "c" to generate an ECDSA private signing key.

[0046] Although FIG. 3 illustrates various regions of the owner container 302, other example systems may include electronic devices having more or fewer regions.

[0047] -Container header 4 illustrates a block diagram of an example container header 310 of an owner container 302 for managing ownership of an electronic device 101. In one embodiment, the container header 310 may have a common format for owner containers created for the electronic device 101. As shown in FIG. 4, the container header 310 may include fields 431-436 that include an RPMC value 431, an active container version 432, a container type 433, a secure container content length 434, a device serial number 435, and a container command key hash blob 436.

[0048] The RPMC value 431 may be provided by a replay-protected monotonic counter that may be checked against the current RPMC value 202 in the OTP memory 110 to determine if the owner container is valid or revoked. In one embodiment, when the RPMC value 431 for the owner container 302 has a value of 3, the boot code 140 may determine that the owner container is valid when the current RPMC value 202 also has a value of 3 (e.g., FIG. 2). In the same or a different embodiment, when the RPMC value 431 for the owner container 302 has a value of 3, the boot code 140 may determine that the owner container is revoked when the current RPMC value 202 has a value greater than 3 (e.g., Table 1 (Revoked RPMC Values)). In some embodiments, the RPMC value 431 may be used in checking the primary and fallback containers.

[0049] The active container version 432 may represent a version number of the owner container 302. In one embodiment, the owner of the electronic device 101 may want to update information in the owner container 302 (e.g., the areas shown in FIG. 6 ) in a manner that does not require incrementing the RPMC value 431. Thus, the boot code 140 may increment the active container version 432 when other information is updated. In another embodiment, the boot code 140 may set the active container version 432 to 0 during an operation in which the RPMC value 431 is incremented. Thus, the container with the highest RPMC value 431 and the highest active container version 432 may be the primary owner container of the electronic device 101.

[0050] The container type 433 may represent a type associated with the owner container 302. In one embodiment, the container type 433 may have a value indicating that the container is not initialized. In another embodiment, the container type 433 may have a value indicating that the owner container 302 is initialized and is a valid owner container. The secure container content length 434 may indicate the number of bytes in the owner container content 311. The device serial number 435 may correspond to the serial number of the electronic device 101, for example, the unique serial number 205 in the OTP memory 110. The container command key hash blob 436 may include a hash (e.g., SHA384 (Secure Hash Algorithm)) of one or more container command keys (CCK), which may be the public keys of a cryptographic key pair. In the illustrated embodiment, the container command key hash blob 436 may include a hash of public keys CCK0 437, CCK1 438, CCK2 439, and CCK3 440. In one embodiment, these key hashes may be used to verify commands associated with the owner container 302. (Alternatively, container command key hash blob 436 may contain the public key instead of a hash of the public key. More memory may be required in this embodiment.) In one embodiment, CCK0-3 (437-440) may be revoked by setting the hash entry to 0. Although FIG. 4 shows various fields of container header 310, other example systems may include electronic devices having more or fewer fields.

[0051] -Container Content The owner container 302 may have different configurations that may be based on configuration sources, including: FMB image configuration source = OTP memory (e.g., Figure 5) FMB image configuration source = OTP emulation in SPI flash RPMC container (e.g., Figure 6).

[0052] 5 illustrates a block diagram of exemplary container contents 311a of an owner container 302 for managing ownership of an electronic device 101. As illustrated in FIG. 5, the container contents 311a may be programmed into the OTP memory 110 and may include multiple fields 501-515, including an owner configuration 501, an owner ID 502, an owner RPMC 503, an owner transfer authorization key (OTAK) 504, an encrypted ECDH private key 505, an ECDH public key hash 506, a key hash blob (KHB) hash 507, a TAGx image key revocation 508, a TAGx image rollback protection 509, a TAG0 base address pointer 510, a TAG1 base address pointer 511, debug support 512, a platform ID 513, security features 514, and a PlatK hash 515. In one embodiment, some or all of the container contents 311a may be programmed into the OTP memory 110 during provisioning (e.g., by a tester). In the same or a different embodiment, some or all of the container contents 311a may be programmed into the OTP memory 110 by the boot code 140 after provisioning of the electronic device 101 is complete. Higher level firmware (e.g., code other than the code that created the container) may require a command interface (e.g., command memory 171 of FIG. 7) to access or modify information in the container contents 311a of the owner container 302.

[0053] The owner configuration 501 may include the location of configuration information corresponding to the FMB. For example, the configuration information may be located in OTP memory 110, non-volatile memory 173, or other memory. In one embodiment, if the configuration information is located in OTP memory 110, the container configuration may be an OTP configuration. In one embodiment, if the configuration information is located in non-volatile memory 173 (e.g., SPI flash), the container configuration may emulate an OTP memory (an OTP emulation configuration, described more fully below).

[0054] The owner configuration 501 may include information regarding who may transfer ownership of the electronic device 101. In one embodiment, the current silicon owner may transfer ownership by executing a transfer ownership command signed by the owner's public container command key (CCK). In another embodiment, both the current silicon owner and the new owner may transfer ownership. The current silicon owner may transfer ownership to the new owner by executing a transfer ownership command signed by the owner's public CCK, and the new owner may transfer ownership by executing a transfer ownership command signed by an owner transfer authorization key (OTAK). The OTAK may be a public key programmed by the current owner into the owner container 302 (e.g., owner transfer authorization key 504) to enable the new owner (or an authorized intermediate entity) to execute the owner transfer command. The owner configuration 501 may include information indicating whether the RPMC owner container crisis command is supported. In one embodiment, if crisis commands are enabled, the owner can insert owner container commands into command memory 171 (e.g., FIG. 7) using I / O and port controls 190 (e.g., I2C crisis port, UART crisis port). In one embodiment, owner container crisis commands may be disabled by default or may be enabled by the owner of electronic device 101 (e.g., by programming owner configuration 501).

[0055] The owner ID 502 may be a value provided by the owner at the time of ownership transfer and may be used to identify the owner. The owner RPMC 503 may be a value determined by the boot code 140 at the time of ownership transfer. It may be, for example, the initial RPMC value assigned to the owner at the time of ownership transfer. In one embodiment, the owner ID 502 and the owner RPMC 503 together may indicate a unique owner of a particular electronic device 101. The owner transfer authorization key (OTAK) 504 may be, for example, a one-time ECDSA-384 public key (Elliptic Curve Digital Signature Algorithm) used to verify the transfer of ownership command if the configuration information in the owner configuration 501 allows the new owner to execute the transfer of ownership command.

[0056] The encrypted ECDH private key 505 may be an encrypted ECDH (Elliptic-curve Diffie-Hellman) private key used to derive an AES256 (Advanced Encryption Standard) image encryption key (IEK) that may be used to decrypt the FMB image stored in the non-volatile memory 173. The ECDH public key hash 506 may be a SHA384 hash of the ECDH public key that may be used to derive an AES256 key encryption key (KEK) that may be used to decrypt the encrypted ECDH private key 505. In one embodiment, the encrypted ECDH private key 505 and the ECDH public key hash 506 may be exchanged according to a Diffie-Hellman key exchange protocol and used to decrypt the FMB image.

[0057] Key hash blob (KHB) hash 507 may be a SHA384 hash of the owner provided KHB (e.g., stored in non-volatile memory 173), which may include a hash of each of the public keys that may be used to authenticate other data (e.g., FMB, RPMC container commands, among others). TAGx image key revocation 508 may indicate whether a public key in the owner's KHB is available or has been revoked (not available for use). In one embodiment, KHB hash 507 may include eight public keys, and TAGx image key revocation 508 may include one bit corresponding to each public key. In this embodiment, when a bit in TAGx image key revocation 508 is programmed to a value of 1, the corresponding key may be revoked. In one embodiment, boot code 140 may not use a revoked key (e.g., before using a key, boot code 140 may verify that the corresponding bit in TAGx image key revocation 508 is not programmed to a value of 1). TAGx image rollback protection 509 may indicate whether the current image revision (e.g., FMB) is available for use or has been revoked (not available for use). In one embodiment, KHB hash 507 may allow for up to 128 image revisions, and TAGx image rollback protection 509 may include one bit corresponding to each revision. In this embodiment, if a bit in TAGx image rollback protection 509 is programmed to a value of 1, the corresponding image revision may be revoked. In one embodiment, boot code 140 may not authenticate a revoked image (e.g., before loading an image, boot code 140 may verify that the corresponding bit in TAGx image rollback protection 509 is not programmed to a value of 1).

[0058] TAG0 base address pointer 510 may be a base address for an image header of the FMB. TAG1 base address pointer 511 may be a base address for an image header of a copy of the FMB. Debug support 512 may indicate whether debugging (e.g., UART production debug) is supported. Platform ID 513 may include an owner platform identification value. Security capabilities 514 may indicate whether the current owner has enabled various security features. In one embodiment, security capabilities 514 may indicate whether an image rollback protection feature is enabled (e.g., whether an image revision can be undone using TAGx image rollback protection 509). In the same or a different embodiment, security capabilities 514 may indicate whether a key revocation feature is enabled (e.g., whether a key can be revoked using TAGx image key revocation 508). PlatK hash 515 may include a hash (e.g., SHA384) of a platform public key, which may be a key used to sign crisis commands (e.g., if owner configuration 501 indicates that RPMC owner container crisis commands are supported).

[0059] 5 illustrates various regions of the container content 311a, other example systems may include electronic devices having more or fewer regions. In additional embodiments, particular regions of the container content 311a may include functionality in addition to those described above, or may omit some of the functionality described above.

[0060] 6 illustrates a block diagram of an example container content 311b of an owner container 302 for managing ownership of an electronic device 101. As illustrated in FIG. 6, the container content 311b may be programmed into the non-volatile memory 173 and may include areas 501-515 as described with respect to FIG. 5 and differing in that it is stored in the non-volatile memory 173 rather than in the OTP memory 110. In one embodiment, the owner container 302 with the container content 311b stored in the non-volatile memory 173 may emulate an owner container stored in the OTP memory 110 (OTP emulation) because the boot code 140 may store configuration parameters (e.g., in the container content 311b) when it creates the owner container and there is no command for the boot code 140 (or other code) to modify those parameters. If a malicious user were to attempt to modify the secure RPMC owner container 302 (e.g., to change any of the OTP emulating parameters) while the secure RPMC owner container 302 is stored in the non-volatile memory 173, validation of the container would fail. Thus, the configuration parameters in the owner container 302 stored in the non-volatile memory 173 may be considered to emulate an OTP memory.

[0061] In one embodiment, the container content 311b may include a PUF boot code 621 (e.g., "PUF" refers to a physically unclonable function, described in more detail below). The boot code 140 may use the PUF boot code 621 to generate and pass a device attestation key (DevAK) to the silicon owner's firmware. In one embodiment, at the first power-on reset cycle after the owner container content 311b is created or updated, the boot code 140 may use a shared SRAM PUF to generate the PUF boot code 621 and store it within the owner container content 311b. During a subsequent boot process, if the boot code 140 loads an authentic image (e.g., FMB), the boot code 140 may use the PUF boot code 621 to generate the DevAK private and public keys. In one embodiment, boot code 140 can put the DevAK public key into an X.509 certificate and sign the certificate using the DevIK private key (e.g., private device unique information 207 of FIG. 2). In an embodiment, the signed certificate can be passed to the owner firmware (e.g., via firmware mailbox 788 of FIG. 7) along with the PUF activation code 621. The owner firmware can use the PUF activation code 621 to regenerate the DevAK private key.

[0062] Additional examples of PUF activation code 621, SRAM PUF, DevAK and DevIK keys, and device certificates are provided in Figures 16-30 and the associated discussion (below, in the "Physical Unclonable Function (PUF) SRAM" section).

[0063] In some embodiments (not shown), the boot code 140 can generate the PUF activation code 621 during manufacturing (e.g., before creating the owner container 311b). According to this embodiment, the boot code 140 can store the PUF activation code 621 in a non-volatile memory (e.g., non-volatile memory 173) at an address stored in the OTP memory 110. The boot code 140 can store a hash of the PUF activation code 621 in the OTP memory that can be used to verify the integrity of the PUF activation code 621 when the PUF activation code 621 is retrieved from the non-volatile memory 173. Thus, the boot code 140 can generate the DevAK private and public keys using the PUF activation code 621 even before creating the first owner container 311b.

[0064] 6 illustrates various regions of the container content 311b, other example systems may include electronic devices having more or fewer regions. In additional embodiments, particular regions of the container content 311b may include functionality in addition to those described above, or may omit some of the functionality described above.

[0065] Command Interface 7 illustrates an exemplary command memory 171. Command memory 171 may include rewriteable memory (e.g., registers, SRAM) and may include RPMC container commands 782, a boot code mailbox 784, and a firmware mailbox 786. According to one embodiment, boot code 140 may authenticate and optionally decrypt the FMB from non-volatile memory 173 (e.g., SPI flash) and then load the FMC into internal volatile memory 172 (e.g., SRAM) for subsequent execution by processor 160. For example, boot code may load the FMB into internal volatile memory 172 (e.g., SRAM), authenticate the FMB, and optionally decrypt the FMB, which may include one or more images including the FMC as a first image. In one embodiment, the authenticated and optionally decrypted FMB remains in volatile memory 172 (e.g., SRAM). This binary image may be referred to as the "owner" image. The boot code may then cause execution of the FMC by processor 160 (e.g., jump to the base address of the FMC). The FMC can be either a ROM extension (e.g., an authenticated ROM extension in the FMC) or an application firmware. The owner application can communicate with the boot code 140 or ROM_EXT to request a transfer of ownership or to perform some other action instead. The application can communicate this action by loading a signed command into the boot code mailbox 784, setting the associated command bit in the RPMC container commands 782, and triggering a reset (e.g., a soft reset).

[0066] In the above embodiment, RPMC container commands 782 and boot code mailbox 784 may be used to initiate RPMC container requests to be processed by boot code 140. (Firmware mailbox 786 may be used by boot code 140 (or ROM_EXT) to pass information to application firmware.) In one embodiment, command memory 171 may be user accessible so that code other than boot code 140 (e.g., FMC) may initiate requests to be processed by boot code 140. In another embodiment, command memory 171 may be accessed via external hardware (UART interface, I2C interface, among others) to, for example, perform crisis recovery (if owner configuration 501 in owner container 311a / b indicates that RPMC owner container crisis commands are supported).

[0067] In one embodiment, the RPMC container command 782 may include a bit that, when set, may indicate that an RPMC command is pending for the electronic device 101. The RPMC container command 782 may further include a command field that may indicate a particular command for the boot code 140 to process. In the same or another embodiment, the boot code mailbox 784 may be programmed with command parameters corresponding to the pending command. In one embodiment, the command parameters stored in the boot code mailbox 784 may be signed, and the boot code 140 may authenticate the pending command during the boot process before executing the command (e.g., if the parameters stored in the boot code mailbox 784 are signed, the command may be considered a signed command).

[0068] Owner Container Actions The following non-exclusive list of actions can be performed on the owner container 302: CREATE_CONTAINER_REQUEST INCREMENT_RPMC_REQUEST UPDATE_CONTAINER_REQUEST ·REPAIR_FALLBACK_CONTAINER_REQUEST CRISIS_RECOVERY_REQUEST ·ENABLE_UNRESTRICTED_TRANSFERS UPDATE_OTAK_KEY

[0069] In one embodiment, boot code 140 may authenticate a signed command received from a trusted application firmware and load it into internal volatile memory 172 (e.g., SRAM) for execution by processor 160. In another embodiment, boot code 140 may authenticate a signed command received from I / O and port control 190 (e.g., I2C, UART) as a crisis recovery command and load it into internal volatile memory 172 (e.g., SRAM) for execution by processor 160.

[0070] -CREATE_CONTAINER_REQUEST command This signed command may be called to cause the boot code 140 to create and program a first signed owner container 302 in the non-volatile memory 173 (e.g., SPI flash). The boot code 140 may ignore this command if it is called after the first signed owner container 302 has already been created. For example, after creating the first signed owner container 302, the boot code 140 may program a bit in the OTP memory 110 indicating that a container has been created (e.g., RPMC flash container status 208) and then check that OTP bit before executing a CREATE_CONTAINER_REQUEST command. If the OTP bit is programmed, the boot code 140 may ignore subsequent CREATE_CONTAINER_REQUEST commands.

[0071] In one embodiment, the CREATE_CONTAINER_REQUEST command may result in the creation of two identical signed owner containers 302 (e.g., a primary container and a fallback container). These signed containers may be stored in non-volatile memory 173 (e.g., SPI flash). In one embodiment, if boot code 140 verifies that both signed containers are successfully saved in non-volatile memory 173, it sets an OTP bit indicating that the container was created.

[0072] In one embodiment, boot code 140 can use command parameters stored in boot code mailbox 784 for the CREATE_CONTAINER_REQUEST command. The command parameters can include a command signature signed with an owner creation public key (OCKpub), an owner creation private key (OCKpriv), and other command parameters corresponding to fields 433-434 and 437-440 of FIG. 4 (container header 310) and fields 501-502 and 505-515 of FIG. 6 (container contents 311b). Before creating the signed owner container 302, boot code 140 can verify the command signature using OCKpub. In one embodiment, boot code 140 can verify the command parameter OCKpub by calculating its hash and comparing it to the OCKpub hash retrieved from the KHB stored in non-volatile memory 173. (The KHB stored in non-volatile memory 173 may be verified against the KHB hash 507 in OTP memory 110.) If either the OCKpub or command signature verification fails, boot code 140 may stop execution of the CREATE_CONTAINER_REQUEST command without creating the first owner container 302. In one embodiment, boot code 140 may store an unsuccessful command status in firmware mailbox 786.

[0073] If the verification is successful, boot code 140 can create a signed owner container 302. In one embodiment, boot code 140 can store a successful command status in firmware mailbox 786. In one embodiment, boot code 140 can save the corresponding command parameters (in boot code mailbox 784) in corresponding areas in container header 310 (areas 433-434 and 437-440 in FIG. 4) and container contents 311b (areas 501-502 and 505-515 in FIG. 5). Boot code 140 can use the following for the new signed owner container 302: RPMC Value 431 (and Owner RPMC 503): Can default to 0 (as this is the first owner container). Boot code 140 can check if any bits of the current RPMC value 202 in the OTP memory are set, and if so, set them to the first valid non-zero value. · Active container version 432: Can default to 0. · Device Serial Number 435: Can be set to the value stored in OTP Serial Number 205. Owner Transfer Authorization Key 504: Can default to 0. PUF activation code 621: may default to 0 when processing a CREATE_CONTAINER_REQUEST command. The boot code 140 may generate and store the PUF activation code 621 in the signed owner container 302 following the next power cycle.

[0074] -INCREMENT_RPMC_REQUEST Command This signed command can be called (without changing other container contents) to have the boot code 140 increment the RPMC value 431 of the primary owner container 302. If authorized, the boot code 140 can retrieve the primary owner container 302, increment the RPMC value 431, and reset the active container version 432 back to 0. The boot code 140 can erase the primary and fallback containers stored in non-volatile memory 173 and store the updated owner container 302 in their place. Once both containers are successfully updated, the boot code can increment the current RPMC value 202 in the OTP memory 110, which can cancel the previous container.

[0075] In one embodiment, boot code 140 can use command parameters stored in boot code mailbox 784 for the INCREMENT_RPMC_REQUEST command. The command parameters can include a container commands public key (CCKpub), an indication of which of CCK0-CCK3 (hashes in field 436 of current owner container header 310) CCKpub corresponds to, and a command signature signed with a container commands private key (CCKpriv). Before incrementing RPMC value 431, boot code 140 can verify the command signature using CCKpub. In one embodiment, boot code 140 can verify the command parameter CCKpub by calculating its hash and comparing it to the corresponding CCKpub hash (CCK0-CCK3) stored in current owner container header 310. (The information in the current owner container header 310 can be trusted because the owner container 302 can be verified by the boot code 140.) If either the CCKpub or command signature verification fails, the boot code 140 can stop executing the INCREMENT_RPMC_REQUEST command without incrementing the RPMC value 431. In one embodiment, the boot code 140 can store an unsuccessful command status in the firmware mailbox 786.

[0076] If the verification is successful, the boot code 140 may increment the RPMC value 431 as described above. In one embodiment, the boot code 140 may store a successful command status in the firmware mailbox 786.

[0077] -UPDATE_CONTAINER_REQUEST command This signed command may be invoked to cause the boot code 140 to update the selected container and increment the current RPMC value 202 in the OTP memory 110. In one embodiment, the particular update to be performed may be determined by sub-command parameters of the command parameters stored in the boot code mailbox 784 for the UPDATE_CONTAINER_REQUEST command. In one embodiment, the sub-commands may include: (1) "Key Revocation and Rollback Protection" and (2) "Transfer Ownership."

[0078] In one embodiment, the boot code 140 can use the command parameters stored in the boot code mailbox 784 for the UPDATE_CONTAINER_REQUEST command. The command parameters can include the signing public key (CCKpub or OTAKpub), an indication of whether to use OTAKpub or CCK0-CCK3 for verification (hash in field 436 of the current owner container header 310), and the command signature signed with the private key OTAKpriv or CCKpriv. Before updating the owner container 302, the boot code 140 can verify the command signature using OTAKpub or CCKpub (whichever is indicated for use). In one embodiment, the boot code 140 can verify the command parameter CCKpub by calculating its hash and comparing it to the corresponding CCKpub hash (CCK0-CCK3) stored in the current owner container header 310. (Because the owner container 302 can be verified by the boot code 140, the information in the current owner container header 310 can be trusted.) In another embodiment, the boot code 140 can verify by comparing the command parameter OTAKpub with the owner transfer authorization key 504 stored in the current owner container contents 311b. If verification of either (1) the selected OTAKpub or CCKpub key, or (2) the command signature fails, the boot code 140 can stop execution of the UPDATE_CONTAINER_REQUEST command without modifying the current owner container 302 or incrementing the current RPMC value 202 in the OTP memory 110. In one embodiment, the boot code 140 can store an unsuccessful command status in the firmware mailbox 786.

[0079] If (1) verification of both the selected OTAKpub or CCKpub key and the command signature is successful, and (2) the subcommand is "transfer ownership", then the boot code 140 may update the signed owner container 302. In one embodiment, the boot code 140 may store command parameters (e.g., in the boot code mailbox 784) corresponding to fields 433-434 and 437-440 in FIG. 4 (container header 310) and fields 501-502 and 505-515 in FIG. 6 (container contents 311b) in corresponding fields in the container header 310 and container contents 311b of the updated signed owner container 302. The boot code 140 may use the following defaults for the updated signed owner container 302: · RPMC value 431 (and owner RPMC 503): {current RPMC value 202 + 1} may be used. · Active container version 432: Can default to 0. · Device Serial Number 435: Can be set to the value stored in OTP Serial Number 205. Owner Transfer Authorization Key 504: Can default to 0. PUF activation code 621: may default to 0 when processing a CREATE_CONTAINER_REQUEST command. The boot code 140 may generate and store the PUF activation code 621 in the signed owner container 302 following the next power cycle.

[0080] If (1) verification of both the selected OTAKpub key or CCKpub key and the command signature is successful, (2) the subcommand is "transfer of ownership", and (3) both the updated primary and fallback owner containers 302 are successfully written to non-volatile memory 173, boot code 140 may increment the current RPMC value 202 in OTP memory 110. In one embodiment, boot code 140 may store the successful command status in firmware mailbox 786.

[0081] If (1) verification of both the selected OTAKpub or CCKpub key and the command signature is successful, and (2) the subcommand is "key revocation and rollback protection", then the boot code 140 can process the key revocation and rollback protection request. In one embodiment, the boot code 140 can update one or both of the TAGx image key revocation 508 and the TAGx image rollback protection 509 in the container contents 311b of the signed owner container 302. In one embodiment, the boot code 140 can store a successful command status in the firmware mailbox 786.

[0082] -REPAIR_FALLBACK_CONTAINER_REQUEST command This signed command can be called to have the boot code 140 update the fallback container to match the primary container. If the primary container is valid and the fallback container does not match the primary container, the boot code 140 can erase the fallback container and copy the primary container to the fallback container location. In one embodiment, the boot code 140 can use command parameters stored in the boot code mailbox 784 for the REPAIR_FALLBACK_CONTAINER_REQUEST command. The command parameters can include the signing public key (CCKpub or OTAKpub), an indication of whether to use OTAKpub or CCK0-CCK3 for verification (the hash in field 436 of the current owner container header 310), and a command signature signed with the private key OTAKpriv or CCKpriv. The boot code can verify the signing public key and command signature for the REPAIR_FALLBACK_CONTAINER_REQUEST command using the same mechanism disclosed for UPDATE_CONTAINER_REQUEST (above). In one embodiment, if the verification is successful and no errors are detected in updating the fallback container, a matching fallback container may be stored in non-volatile memory 173 (e.g., SPI flash), resulting in a match between the primary container and the fallback container stored in non-volatile memory 173, and boot code 140 may store a successful command status in firmware mailbox 786. If the verification is unsuccessful or an error is detected, there may be no change (e.g., the primary container is still valid in non-volatile memory 173 and the fallback container is still invalid). In this latter embodiment, boot code 140 may store an unsuccessful command status in firmware mailbox 786.

[0083] -RISK_RECOVERY_REQUEST Command This signed command can be called to recover boot code 140 from the case where the primary and fallback containers are not valid. In one embodiment, this command can be serviced when both containers are invalid. Boot code 140 can allow the owner to restore a saved copy of a working owner container using a crisis command (e.g., RESTORE_OWNER_CONTAINER) issued via I / O and port control 190 (e.g., I2C crisis port, UART crisis port).

[0084] -ENABLE_UNRESTRICTED_TRANSFERS command This signed command can be called to cause the boot code 140 to perform the following updates to the owner container 302: · Update the ownership configuration 501 (FIG. 5) so that both the current silicon owner and the new owner can transfer ownership of the electronic device 101. Provision an owner transfer authorization key 504. Increment the active container version to 432 (Figure 4). · Re-sign the owner container 302.

[0085] In one embodiment, the boot code 140 can use command parameters stored in the boot code mailbox 784 for the ENABLE_UNRESTRICTED_TRANSFERS command. The command parameters can include an OTAKpub public key (e.g., for provisioning the owner transfer authorization key 504), a signature public key (CCKpub), an indication of which of CCK0-CCK3 (hashes in field 436 of the current owner container header 310) the CCKpub corresponds to, and a command signature signed with a container command private key (CCKpriv). The boot code 140 can verify the command signature using the CCKpub before updating the owner container 302. In one embodiment, the boot code 140 can verify the command parameter CCKpub by calculating its hash and comparing it to the corresponding CCKpub hash (CCK0-CCK3) stored in the current owner container header 310. (The information in the current owner container header 310 can be trusted because the owner container 302 can be verified by the boot code 140.) If either the CCKpub or command signature verification fails, the boot code 140 can stop executing the ENABLE_UNRESTRICTED_TRANSFERS command without updating the owner container 302. In one embodiment, the boot code 140 can store the unsuccessful command status in the firmware mailbox 786.

[0086] If the verification is successful, the boot code 140 may perform the updates to the owner container 302 as described above (e.g., by updating both copies of the container in non-volatile memory (e.g., SPI flash)). In one embodiment, the boot code 140 may store a successful command status in the firmware mailbox 786.

[0087] -UPDATE_OTAK_KEY command This signed command can be called to cause the boot code 140 to perform the following updates to the owner container 302: Provision an owner transfer authorization key 504. Increment the active container version to 432 (Figure 4). · Re-sign the owner container 302.

[0088] This signed command may allow an intermediate entity with the OTAKpriv private key to trigger the update. In one embodiment, the boot code 140 may ignore this command unless the owner configuration 501 is configured to allow both the current silicon owner and the new owner to transfer ownership of the electronic device 101 (e.g., unrestricted transfers are not enabled).

[0089] In one embodiment, the boot code 140 can use the command parameters stored in the boot code mailbox 784 for the UPDATE_OTAK_KEY command. The command parameters can include the new OTAKpub_new public key (e.g., for provisioning the owner transfer authorization key 504), the signing public key (CCKpub or OTAKpub), an indication of whether to use OTAKpub or CCK0-CCK3 for verification (hash in field 436 of the current owner container header 310), and the command signature signed with the private key OTAKpriv or CCKpriv. Before updating the owner container 302, the boot code 140 can verify the command signature using OTAKpub or CCKpub (whichever is indicated for use). In one embodiment, the boot code 140 can verify the command parameter CCKpub by calculating its hash and comparing it to the corresponding CCKpub hash (CCK0-CCK3) stored in the current owner container header 310. (Because the owner container 302 can be verified by the boot code 140, the information in the current owner container header 310 can be trusted.) In another embodiment, the boot code 140 can verify by comparing the command parameter OTAKpub with the owner transfer authorization key 504 stored in the current owner container contents 311b. If verification of either (1) the selected OTAKpub key or CCKpub key, or (2) the command signature fails, the boot code 140 can stop executing the UPDATE_OTAK_KEY command without modifying the current owner container 302. In one embodiment, the boot code 140 can store an unsuccessful command status in the firmware mailbox 786.

[0090] If the verification is successful, the boot code 140 may perform the updates to the owner container 302 as described above (e.g., by updating both copies of the container in non-volatile memory (e.g., SPI flash)). In one embodiment, the boot code 140 may store a successful command status in the firmware mailbox 786.

[0091] Ownership of Electronic Devices An electronic device 101 may belong to one or more owners over its life, and each owner may customize the images that are allowed to run on the machine. In one embodiment, the OEM may be the first implicit owner ("no owner" state), and the OEM's configuration may be stored in the OTP memory 110. The OEM may enable parts to support ownership transfer by establishing a first owner container. The silicon owner may be the entity that controls the keys used for code execution, ownership transfer, and crisis recovery, for example, corresponding to the currently active (unrevoked) secure RPMC owner container (e.g., the owner container with RPMC value 431 that matches the current owner RPMC value 202 in the OTP memory 110).

[0092] Establishing Ownership During manufacturing, the OTP memory 110 may be provisioned with OEM image configuration parameters, which may include a KHB hash 507 used to authenticate an OEM image stored in the non-volatile memory 173 (e.g., SPI flash). Other parameters in the OTP memory 110 (e.g., as shown in Figures 2 and 5) may also be provisioned by the OEM during manufacturing. This configuration may be referred to as a "legacy secure boot" state. In this state, only signed OEM images (e.g., FMB) may be authenticated and executed on the electronic device 101.

[0093] The RPMC owner container 302 can be created by an OEM using the CREATE_CONTAINER_REQUEST command. The OEM can choose to use either the OTP memory configuration (e.g., FIG. 5) or the owner container configuration (OTP emulation) (e.g., FIG. 6).

[0094] The OEM owner container 302 may be created by true firmware loaded from non-volatile memory 173 (e.g., SPI flash) or may be created via code loaded into volatile memory 172 (e.g., 12C crisis port, UART crisis port) via I / O and port control 190. The firmware may store a CREATE_CONTAINER_REQUEST command in the boot code mailbox 784 (FIG. 7), set RPMC container commands 782 to indicate a pending request, and assert a reset (e.g., a soft reset).

[0095] FIG. 8 illustrates a block diagram of an embodiment of managing ownership of electronic device 101, including creating a first owner container using an OEM signed image and OTP configuration. The contents of non-volatile memory 873 (e.g., SPI flash) are shown at time t0 and include OTP TAG0 / 1 image header base address, OTP KHB (primary and fallback), and OTP TAG0 / 1 image header and image (e.g., FMB). At time t0, there may be no owner of electronic device 101, but the OEM may be the implied owner. In one embodiment, at time t1, OEM application code can write owner container 0 / 1 (primary and fallback container) base address to non-volatile memory 873. At time t2, OEM application code can store a CREATE_CONTAINER_REQUEST command in the RPMC container command area in command memory 871 and store the container parameters of the new owner (Owner A) in the boot code mailbox in command memory 871. In one embodiment, parameters corresponding to owner configuration parameters 501 may specify an OTP configuration for Owner A. At time t3, OEM application code may cause a soft system reset of electronic device 101. During the boot process, boot code 140 may notice a pending CREATE_CONTAINER_REQUEST command (e.g., in command memory 871) and process the command. At time t4, if the command is successful, boot code 140 may write Owner A container 0 / 1 (primary container and fallback container) to non-volatile memory 873. As shown, after time t4, electronic device 101 may be owned by Owner A using the OTP image. In one embodiment, following time t4, the OEM application may read command status bits from firmware mailbox 786 (FIG. 7) to verify successful completion of the command. The OEM application may optionally read Owner A container 0 / 1 from non-volatile memory 873 and verify the contents.In one embodiment, the OEM application can optionally save a copy of Owner A Container 0 / 1 as a backup.

[0096] 9 illustrates a block diagram of an embodiment of managing ownership of electronic device 101, including creating a first owner container using an OEM signed image and an OTP emulation configuration. The contents of non-volatile memory 973 (e.g., SPI flash) are shown at time t0 and include OTP TAG0 / 1 image header base address, OTP KHB (primary and fallback), and OTP TAG0 / 1 image + header (e.g., FMB). At time t0, there may be no owner of electronic device 101, but the OEM may be the implied owner. In one embodiment, at time t1, OEM application code can write (1) Owner Container 0 / 1 Base Address, (2) Owner A KHB (primary and fallback), and (3) Owner A TAG0 / 1 image + header (e.g., FMB) to non-volatile memory 973. At time t2, the OEM application code can store a CREATE_CONTAINER_REQUEST command in the RPMC container command area in command memory 971 and can store container parameters for the new owner (Owner A) in the boot code mailbox in command memory 971. In one embodiment, parameters corresponding to owner configuration parameters 501 can specify an OTP emulation configuration for Owner A. At time t3, the OEM application code can cause a soft system reset of electronic device 101. During the boot process, boot code 140 can notice the pending CREATE_CONTAINER_REQUEST command and process the command. At time t4, if the command was successful, boot code 140 can write Owner A container 0 / 1 (primary container and fallback container) to non-volatile memory 973 and begin executing the Owner A image (e.g., TAG0 image). As shown, after time t4, electronic device 101 can be owned by Owner A using Owner A's image. In one embodiment, following time t4, the Owner A application can read the command status bits from the firmware mailbox 786 (FIG. 7) to verify successful completion of the command.The Owner A application can optionally read Owner A Container 0 / 1 from non-volatile memory 973 and verify the contents. In one embodiment, the Owner A application can optionally save a copy of Owner A Container 0 / 1 as a backup.

[0097] BOOT SEQUENCE OF ELECTRONIC DEVICE HAVING RPMC OWNER CONTAINER - Patent application FIG. 10 illustrates a flow chart of an example method 1000 for managing ownership of an electronic device, including secure transfer of ownership of the electronic device over time. According to one embodiment, method 1000 may begin at block 1005. In one embodiment, method 1000 may be performed by boot code 140. In some embodiments, start block 1005 may represent a time when electronic device 101 is first powered on (POR) or a time following a reset of the electronic device (e.g., a device reset, reboot, or power cycle). Thus, method 1000 may be performed by boot code 140 at a time when OTP memory 110 is not user accessible (e.g., because user code has not yet been loaded). The teachings of the present disclosure may be implemented in various configurations of system 100. Thus, the initialization point of method 1000 and the order of steps 1005-1045 that make up method 1000 may depend on the implementation selected.

[0098] Following a POR or soft reset, the boot code may proceed to block 1010 to determine if the OTP memory is fully provisioned. If not, the boot code may proceed to block 1015 to provision the electronic device 101 with the OEM configuration and then proceed to block 1020 to reset the electronic device 101.

[0099] If the boot code determines in block 1010 that the OTP memory is fully provisioned, it may proceed to block 1025 and may determine whether the owner features are enabled in the OTP memory 110. In one embodiment, this feature may be disabled by default (i.e., at the time of manufacture). If the owner features are not enabled, the boot code may proceed to block 1040, where the boot code may load a firmware binary image using OEM information stored in the OTP memory 110. In block 1040, the OEM may be the implicit owner of the electronic device 101 because only OEM-signed firmware may be loaded and executed (which may also be referred to as “legacy secure boot”). In one embodiment, the OEM firmware may enable the owner features by issuing a CREATE_CONTAINER_REQUEST command (e.g., as shown in FIG. 8 and FIG. 9). If the boot code determines in block 1025 that the owner features are enabled in the OTP memory 110, the boot code may proceed to block 1035 and determine whether the FMB image configuration source is OTP emulation. If the FMB image configuration source is not OTP emulation, the image configuration source may be OTP memory. In this example, the boot code may proceed to block 1040 for legacy secure boot. If the boot code determines in block 1035 that the FMB configuration image source is OTP emulation, the boot code may proceed to block 1045, where the boot code may attempt to load firmware using RPMC owner container information stored in non-volatile memory 173 (e.g., SPI flash). In one example, block 1045 may represent a secure boot process using the RPMC owner container stored in non-volatile memory 173.

[0100] Although Figure 10 discloses a particular number of operations associated with method 1000, method 1000 may be performed with more or fewer operations than those shown in Figure 10. Additionally, although Figure 10 discloses a particular order of operations performed with respect to method 1000, the operations making up method 1000 may be completed in any suitable order.

[0101] Transfer of Ownership of Electronic Devices In one embodiment, the OEM may be the first silicon owner (e.g., the owner of the electronic device 101). However, the owner may change one or more times over the life of the electronic device. The owner is the entity that can determine the keys used to authenticate the FMB image. A transfer of ownership may be the act of changing the entity responsible for determining the FMB signing key.

[0102] In one embodiment, an owner may choose to use the RPMC owner container 302 with either an OTP configuration (using an OEM image) (e.g., FIG. 5) or an owner-defined configuration (using an owner image) (e.g., FIG. 6). A new owner container 302 may be created with genuine firmware loaded from non-volatile memory 173 (e.g., SPI flash) or via I / O and port control 190 (e.g., I2C crisis port, UART crisis port) by executing an UPDATE_CONTAINER_REQUEST command for ownership transfer. According to one embodiment, this command may be supported when the current owner enables unlimited transfer of ownership by executing an ENABLE_UNRESTRICTED_TRANSFERS command.

[0103] In some embodiments, there may be three types of ownership transfers: The current owner executes the transfer to the new owner. · A trusted intermediate entity performs the transfer to the new owner (unrestricted transfer). · The current owner allows the new owner to claim ownership (unrestricted transfer).

[0104] The current owner of the electronic device 101 can use the CCK key to transfer ownership to a new owner if the new owner is willing to provide that information to the current owner. In another embodiment, the current owner can use the CCK key to revert the system to an OEM / modified state. This latter type of transfer may be simplified if the OEM image and configuration information is kept in non-volatile memory 173 (e.g., SPI flash). In one embodiment, the boot code 140 may not load an OEM image unless the current owner transfers ownership to use the OEM image.

[0105] An Owner Transfer Authorization Key (OTAK) can support a one-time transfer of ownership to a new owner while avoiding providing the new owner's information to the current owner. Using an OTAK transfer (which may be referred to as an "unlimited transfer"), the new owner can upload its information and complete the ownership transfer as long as the current owner has enabled OTAK transfer. An OTAK ownership transfer can be completed when the new owner may or may not be present when the current owner relinquishes the machine.

[0106] 11 and 12 show block diagrams of two embodiments of managing ownership of electronic device 101 using unlimited transfer and OTAK. As shown in FIG. 11, a current owner (CO) may wish to transfer ownership of machine A to a new owner (NO). In one embodiment, the current owner may rely on a trusted intermediate entity (TIE) (e.g., a sales distribution channel) to assist in the transfer of ownership to the new owner. In one embodiment, the following events (1-8) may occur during the transfer: 1-CO can send the serial number of Machine A to the TIE and NO (if NO is known). The TIE and NO can use the serial number to verify that they receive the correct equipment (e.g., Machine A). 2- The TIE may send the OTAKpub1 key to the CO. The OTAKpub1 key may be the public key of a public / private key pair owned by the TIE. 3-CO can execute the ENABLE_UNRESTRICTED_TRANSFERS command and pass the OTAKpub1 key as machine A's new OTAK public key. 4-CO can send machine A to the TIE. 5- The NO may send an OTAKpub2 key to the TIE. The OTAKpub2 key may be the public key of a public / private key pair owned by the NO. 6-The TIE may execute the UPDATE_OTAK_KEY command, passing the OTAKpub2 key as the new OTAK public key for machine A. Since UPDATE_OTAK_KEY is a signed command, the TIE may sign the command with the TIE's OTAKpriv1 private key. The TIE may use the I / O and port control 190 (e.g., I2C crisis port, UART crisis port) to insert the UPDATE_OTAK_KEY command into command memory 171 (e.g., FIG. 7). 7-TIE can send machine A to NO. 8-NO can execute UPDATE_CONTAINER_REQUEST with the "Transfer Ownership" subcommand. Since UPDATE_CONTAINER_REQUEST is a signed command, NO can sign the command with NO's OTAKpriv2 private key. NO can use I / O and port control 190 (e.g., I2C crisis port, UART crisis port) to insert the UPDATE_CONTAINER_REQUEST command into command memory 171 (e.g., FIG. 7).

[0107] Although Figure 11 discloses a particular number of events associated with an unlimited ownership transfer, this type of transfer may be performed with more or less events than those shown in Figure 11. For example, the CO may not transmit the serial number to either or both the TIE and NO. Additionally, although Figure 11 discloses a particular order of events, the events may be completed in any suitable order.

[0108] As shown in Figure 12, a current owner (CO) may wish to transfer ownership of machine B to a new owner (NO). In one embodiment, the transfer may use an untrusted intermediate entity (UIE) to assist in the transfer of ownership to the new owner. In one embodiment, the following events (1-6) may occur during the transfer: 1-CO can send the serial number of Machine B to NO. NO can use the serial number to verify that it received the correct equipment (e.g., Machine B). 2- The NO can send an OTAKpub3 key to the CO. The OTAKpub3 key can be the public key of a public / private key pair owned by the NO. 3-CO can execute the ENABLE_UNRESTRICTED_TRANSFERS command and pass the OTAKpub3 key as machine B's new OTAK public key. 4-CO can send machine B to the UIE. Note that since the UIE does not have access to OTAKpriv3, the UIE may not assume ownership or execute commands on machine B. 5-UIE can transfer machine B (as is) to NO. 6-NO can execute UPDATE_CONTAINER_REQUEST with the "Transfer Ownership" subcommand. Since UPDATE_CONTAINER_REQUEST is a signed command, NO can sign the command with NO's OTAKpriv3 private key. NO can use I / O and port control 190 (e.g., I2C crisis port, UART crisis port) to insert the UPDATE_CONTAINER_REQUEST command into command memory 171 (e.g., FIG. 7).

[0109] Although Figure 12 discloses a particular number of events associated with an unlimited ownership transfer, this type of transfer may be performed with more or less events than those shown in Figure 12. For example, the CO may not send a serial number to the NO. In another embodiment, the CO may send Machine B directly to the NO without the need for an intermediary entity. Additionally, although Figure 12 discloses a particular order of events, the events may be completed in any suitable order.

[0110] As shown in Figures 11 and 12, if intermediate entities are required and the end owner is unknown, each temporary owner can have their own OTAK key. If intermediate entities are required and the end owner is known, the end owner can supply an OTAK public key that prevents intermediate entities from taking ownership or modifying the OTAK key. The current owner can retain ownership until the ownership transfer is complete. This allows the current owner to address any issues that arise during the transfer of ownership.

[0111] In one embodiment, there are six possible scenarios for transferring ownership of the electronic device 101: Direct ownership transfer using the current owner's CCK key and FMB configuration = OTP (Figure 13). Current owner's CCK key and FMB configuration = direct ownership transfer using OTP emulation. - New owner's OTAK key and FMB configuration = direct ownership transfer using OTP. · New owner's OTAK key and FMB configuration = direct ownership transfer using OTP emulation. · Intermediate entity, OTAK key, and FMB configuration = indirect ownership transfer using OTP. · Intermediate entity, OTAK key, and FMB configuration = indirect ownership transfer using OTP emulation.

[0112] In embodiments where the ownership transfer command is successful, the new owner can load and execute code via the I / O and port control 190 (e.g., a crisis port) and use this loaded code to update the SPI flash image.

[0113] Transfer procedure using CCK key FIG. 13 illustrates a block diagram of an embodiment of managing ownership of electronic device 101, including transferring ownership using the current owner's CCK key and FMB configuration=OTP. The contents of non-volatile memory 1373 (e.g., SPI flash) are shown at time t0 and include OTP TAG0 / 1 image header base address, OTP KHB (primary and fallback), OTP TAG0 / 1 image header and image (e.g., FMB), Owner Container 0 / 1 base address, and Owner A Container 0 / 1. At time t0, Owner A may be the owner of electronic device 101. The new owner may provide its owner configuration parameters to the current owner, who may sign an UPDATE_CONTAINER_REQUEST ("Ownership Transfer" subcommand) command parameters for the new owner using the current owner's CCK key (e.g., using an external hardware security module). In one embodiment, the signed parameters may then be used by either the new owner or the current owner to perform the ownership transfer. At time t1, a soft system reset of the electronic device 101 may cause the electronic device 101 to enter a crisis recovery mode. At time t2, either the new owner or the old owner may issue a signed UPDATE_CONTAINER_REQUEST command using a crisis port (e.g., I2C, UART). At time t3, if the command is successful, the boot code 140 may write Owner B containers 0 / 1 (primary and fallback containers) to non-volatile memory 1373. As shown, after time t3, the electronic device 101 may be owned by Owner B using the OEM OTP image.

[0114] FIG. 13 illustrates transferring ownership using the current owner's CCK key and FMB configuration=OTP. The process may be similar for FMB configuration=OTP emulation. For OTP emulation, after issuing the UPDATE_CONTAINER_REQUEST, the owner may use the crisis port to load the new owner's loader code image and KHB into volatile memory 172 (e.g., SRAM (FIG. 1)). If the load is successful (t3), the boot code 140 may write Owner B Container 0 / 1 (primary and fallback containers) into non-volatile memory 1373 and jump into the new owner's loader code. The new owner's loader code may then write the signed image and KHB (primary and fallback) into non-volatile memory 1373 (e.g., SPI flash).

[0115] Thus, a general procedure for ownership transfer using a CCK key may include: The new owner can provide their own owner configuration parameters to the current owner. The current owner can sign the ownership transfer command parameters for the new owner. (Optional) The current owner can enable crisis mode for restricted signing. (Optional) The current owner may delete their image and KHB (if applicable). · Electronic devices can be powered down and physically transferred to a new owner or to a trusted intermediary entity. The new owner can use the Crisis Port to issue an ownership transfer command. (For OTP emulation) The new owner can use the crisis port to load the new owner's loader code image and KHB, which writes the signed images and KHBs (primary and fallback) to non-volatile memory.

[0116] Transfer procedure using OTAK key Examples of transferring ownership using an OTAK key are discussed above with respect to Figures 11 and 12. A general procedure for transferring ownership using an OTAK key may include the following. The new owner or a trusted intermediate entity can generate a public / private ECDSA-384 key pair. The public ECDSA key can be transferred offline to its current owner via a trusted channel. The current owner can enable unlimited ownership transfers by storing this public key value in an OTAK key in the owner container and using the ENABLE_UNRESTRICTED_TRANSFERS command. (Optional) The current owner can write a new owner image and KHB to the flash. (Optional) The current owner can delete their own image and KHB. · Machines can be powered off and physically transferred to a new owner or trusted entity. · (Optional) If a trusted intermediate entity is used, execute the UPDATE_OTAK_KEY command or the UPDATE_CONTAINER_REQUEST command (with the "ownership transfer" subcommand) using the intermediate entity's OTAK key (via the security port). The new owner can then execute (via the crisis port) the UPDATE_CONTAINER_REQUEST command (with the "transfer ownership" subcommand). (For OTP emulation) The new owner can use the crisis port to load the new owner's loader code image and KHB, which writes the signed images and KHBs (primary and fallback) to non-volatile memory.

[0117] In one embodiment, if the ownership transfer command is successful, the new owner can load and execute code through the same critical port.

[0118] Locating the Owner Container In one embodiment, the boot code 140 may allocate a Boot ROM Address Pointer Table by default in the first 16 bytes in the SPI Flash memory of component 0 (e.g., the first Flash memory component accessed during the boot sequence). This 16 byte Address Pointer Table may be relocatable. The table may be used to locate the owner image and may be re-stored in the OTP memory. The location of the primary RPMC owner container base address and the fallback RPMC owner container base address may be stored in the last 8 bytes of the Address Pointer Table.

[0119] RPMC value in OTP memory and owner container In one embodiment, the current RPMC value 202 in the OTP memory 110 may match the RPMC value 431 in the container header 310 of the current owner container 302. During an update (e.g., an UPDATE_CONTAINER_COMMAND request), the RPMC value 431 in the container header 310 may be incremented by 1 to indicate that a container update is in progress. If the update is successful, the current RPMC value 202 in the OTP memory 110 may be incremented to match the RPMC value 431 in the updated container header 310.

[0120] How to transfer ownership 14 illustrates a flow chart of an example method 1400 for managing ownership of electronic devices, including secure transfer of ownership of electronic devices over time. According to one embodiment, method 1400 may begin at block 1410. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Thus, the initialization point of method 1400 and the order of steps 1410-1430 that make up method 1400 may depend on the implementation selected.

[0121] At block 1410, for an electronic device having a one-time programmable (OTP) memory and a non-volatile memory, the method 1400 can authenticate code associated with an implied owner of the electronic device using information stored in the OTP memory. At block 1415, the method 1400 can receive a first owner container creation request from an authentication code associated with the implied owner of the electronic device. At block 1420, the method 1400 can create a first owner container in response to the first owner container creation request, the first owner container including a first signed data image associated with the first owner of the electronic device. At block 1425, the method 1400 can store the first owner container in the non-volatile memory. At block 1430, the method 1400 can authenticate a first executable code associated with the first owner of the electronic device using the first signed data image associated with the first owner of the electronic device. In one embodiment, the method 1400 may authenticate a first executable code associated with a first owner of the electronic device using configuration information and secret information from a signed data image associated with the first owner of the electronic device.

[0122] Although Figure 14 discloses a particular number of operations associated with method 1400, method 1400 may be performed with more or less operations than those depicted in Figure 14. For example, method 1400 may further authenticate the first owner container creation request using a public key. In another embodiment, after block 1430, method 1400 may continue with additional operations depicted in Figure 15. Additionally, although Figure 14 discloses a particular order of operations performed with respect to method 1400, the operations comprising method 1400 may be completed in any suitable order.

[0123] 15 illustrates a flow chart of an example method 1500 for managing ownership of electronic devices, including secure transfer of ownership of electronic devices over time. According to one embodiment, method 1500 may begin at block 1510. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Thus, the initialization point of method 1500 and the order of steps 1510-1555 that make up method 1500 may depend on the implementation selected.

[0124] According to one embodiment, blocks 1510-1530 (dotted outline) may be the same as blocks 1410-1430 of FIG. 14. At block 1535, the method 1500 may authenticate the signed ownership transfer command using a key stored in the first owner container. At block 1540, the method 1500 may create a second owner container for a second owner of the electronic device in response to successful authentication of the signed ownership transfer command, the second owner container including a second signed data image associated with the second owner of the electronic device. At block 1545, the method 1500 may store the second owner container in a non-volatile memory. At block 1550, the method 1500 may revoke the first owner container. According to one embodiment, revoking the first owner container includes programming a bit in the OTP memory corresponding to the second owner container. At block 1555, the method 1500 may authenticate second executable code associated with the second owner of the electronic device using the second signed data image associated with the second owner of the electronic device.

[0125] Although Figure 15 discloses a particular number of operations associated with method 1500, method 1500 may be performed with more or fewer operations than those depicted in Figure 15. Additionally, although Figure 15 discloses a particular order of operations performed with respect to method 1500, the operations making up method 1500 may be completed in any suitable order.

[0126] Methods 1000, 1400, and 1500 may be performed using system 100 or any other system operable to perform methods 1000, 1400, and 1500. Although embodiments have been described above, other variations and embodiments may be made from this disclosure without departing from the spirit and scope of these disclosed embodiments.

[0127] Physically Unclonable Function (PUF) SRAM Some embodiments of the present disclosure may use an SRAM physically unclonable function (PUF) to generate a device attestation key (DevAK) from boot code 130 and pass it to the first variable code (FMC) without revealing the private key or the SRAM PUF keying material. Unlike devices that use an OTP memory for the DevAK key, the SRAM PUF may enable the generation of a unique device key for a specific application without revealing the private key. In embodiments, the key derived from the SRAM PUF may not be stored in the chip's non-volatile memory (e.g., OTP memory 110, non-volatile memory 173, or other non-volatile memory), and thus no key is present on the chip when the SRAM is not powered. For example, an SRAM PUF may be used to generate a device identification key (DevIK) such that the DevIK does not need to be stored in the OTP memory 110 (e.g., the DevIK may not be stored in the secret device specific information 207 (FIG. 2)). In the same or a different embodiment, the SRAM memory may be "secret" such that when the SRAM is powered, it is not directly accessible by the FMC (e.g., as a result of read / write locking, as described in the next paragraph below).

[0128] 16 illustrates an exemplary volatile memory 172, e.g., an SRAM that may include (a) a general SRAM region 1602, (b) a ROM_PUF region 1604, and (c) a shared PUF region 1606 / 1608 (SHD_PUF). The SHD_PUF region 1606 / 1608 may be shared by both the boot code 130 and application code, e.g., for cryptographic key management. The SHD_PUF region 1606 may be used as a PUF silicon fingerprint, and the SHD_PUF region 1608 may be PUF state information. In one embodiment, the SRAM 172 may be read / write lockable such that when locked, regions of the SRAM 172 may be accessed by the boot code 140 but not simultaneously by application code (e.g., controller firmware or FMC). In one embodiment, boot code 140 may have full access to ROM_PUF region 1604, but application code (e.g., controller firmware) may not have access to ROM_PUF region 1604 because it is read / write locked. In the same example or a different embodiment, boot code 140 may have full access to SHD_PUF region 1606 / 1608. Application code (e.g., controller firmware) may have limited access to SHD_PUF region 1606 / 1608. For example, application code (e.g., FMC) may have access to portion 1608 of SHD_PUF region 1606 / 1608, but may not have access to portion 1606 of SHD_PUF region 1606 / 1608 because it is read / write locked. In one embodiment, portion 1608 of SHD_PUF region 1606 / 1608 may be accessed by application code (FMC) and may contain some SRAM PUF state data (e.g., that may be used by the PUF application programming interface (API)), but may not contain information from which a device secret may be derived.In contrast, portion 1606 of SHD_PUF region 1606 / 1608 (not accessible by application code) may contain SRAM PUF keying material (e.g., a silicon fingerprint of the electronic device).

[0129] In some embodiments, the boot code 140 (e.g., immutable boot code or authenticated mutable boot code) may include SRAM PUF functions, for example, to support anti-aging, error correction, randomness extraction, privacy amplification, and security countermeasure techniques, among others. The SRAM PUF functions may be incorporated into the SRAM PUF API. In some embodiments, one or more of the SRAM PUF functions (e.g., error correction and privacy amplification) may be used to generate a uniform random key based on the silicon fingerprint of the SRAM PUF. In one embodiment, this process of using the SRAM PUF function to generate a uniform random key may be referred to as "registering" the SRAM PUF. In some embodiments, the SRAM PUF may be registered on the first power cycle. This may result in the generation of a PUF activation code 621 (FIG. 6), which may be stored within the container contents 311b of the owner container 302 (FIG. 3). In one embodiment, the SRAM PUF registration may be based on the current silicon owner (e.g., based on the Owner ID 502, Owner RPMC 503, or other value unique to the current owner) such that the uniform random key is unique to the current silicon owner. The SRAM PUF function may then use the PUF activation code 621 to regenerate the same random key that was generated during registration (e.g., following a second power cycle). The PUF activation code 621 need not be secret, but its integrity may be maintained (e.g., as an OTP emulated parameter, as described with respect to FIG. 6).

[0130] FIG. 17 illustrates a flow chart of an exemplary method 1700 for SRAM PUF registration and subsequent key reconstruction. According to one embodiment, the method 1700 may begin at block 1705. In one embodiment, the method 1700 may be performed by the boot code 140. For simplicity, we may use the term boot code 140 as execute a function, meaning that the boot code 140 is read by the processor 160 and understood to cause the processor 160 to execute the associated function. In some embodiments, the start block 1705 may represent the time when the electronic device 101 is first powered on (i.e., power on reset (POR)) or the time following a reset of the electronic device (e.g., a device reset, reboot, or power cycle). Thus, the method 1700 may be performed by the boot code 140 when the volatile memory 172 (e.g., the SRAM having the ROM_PUF and SHD_PUF regions) is not accessible to the FMC (e.g., because the FMC has not yet been authenticated and loaded). The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 1700 and the order of steps 1705-1745 that make up the method 1700 may depend on the implementation chosen.

[0131] Following the POR or soft reset, the boot code 140 may proceed to block 1710 where it determines whether the SRAM PUF is registered. In one embodiment, the boot code 140 may determine that the SRAM PUF is not registered based on a determination that this is the first power cycle or reset cycle after a change in ownership of the electronic device 101 (e.g., if the ownership change status bit is set, or if the PUF activation code 621 in the owner container content 311b is not set (e.g., is all zeros), or some other indication). If the SRAM PUF is not registered, the boot code may proceed to block 1715, where the boot code may determine whether this is the first power cycle after a POR (power on reset). If so, the boot code 140 may proceed to block 1720 and register the SRAM PUF. In one embodiment, the registration may include using the unique SRAM PUF silicon fingerprint to create (1) a uniform random cryptographic key, (2) a key code corresponding to the key, and (3) a PUF activation code corresponding to the current SRAM PUF cryptographic context. In one embodiment, the registration may be based on the current silicon owner (e.g., based on the Owner ID 502, Owner RPMC 503, or other value unique to the current owner) such that the uniform random key is unique to the current silicon owner. In one embodiment, the boot code 140 may perform these tasks using the SRAM PUF API (e.g., SRAM PUF functions) such that the private cryptographic key cannot be extracted by other boot code or the FMC (e.g., the private key may only be known to the SRAM PUF API).

[0132] The boot code 140 may then proceed to block 1725 and store the PUF activation code (e.g., as PUF activation code 621) in the secure RPMC owner container 302 that corresponds to the current owner of the electronic device 101. In one embodiment, block 1725 may be considered part of the registration process.

[0133] In one embodiment, the registration process may provide different owners of the electronic device 101 with respective unique PUF activation codes 621. For example, a DevAKpriv key may be generated as a function of the current owner of the electronic device 101. This may then provide different owners with unique (and random) cryptographic contexts (e.g., unique DevAK keys). In an embodiment, the unique PUF activation code 621 may be generated as a function of the current owner by the boot code at the first power cycle after a transfer of ownership of the electronic device 101. At subsequent power cycles, the stored PUF activation code 621 may be used by the SRAM PUF API functions to regenerate / recreate the previous cryptographic context (e.g., to regenerate the same DevAK key). Thus, by providing different PUF activation codes to different owners of the electronic device 101, the registration process may provide each owner with a different cryptographic context. Thus, a subsequent owner cannot devise the previous owner's cryptographic context or discover the previous owner's secrets.

[0134] After the boot code 140 stores the PUF boot code in the secure RPMC owner container at block 1725, the boot code 140 may proceed to block 1730 and store the key code generated at block 1720 in the firmware mailbox 786 (FIG. 7). The boot code 140 may then proceed to block 1740 and set the firmware mailbox 786 status. In one embodiment, this status may be information stored in the firmware mailbox 786, such as a register bit, and may indicate whether other information in the firmware mailbox 786 (e.g., DevAK key code 1922 of FIG. 19) is valid. In an embodiment following registration after POR, the boot code 140 may set a status indicating that the key code stored in block 1730 is valid. The boot code 140 may then proceed to block 1745 and the boot code may authenticate and load the FMC (e.g., firmware) into SRAM (e.g., executed by the processor 160). In one embodiment, the FMC can then execute in the cryptographic context established by the registration process and can access the key code stored in the firmware mailbox 786. An example use of the key code is described in connection with Figures 18-30 below.

[0135] If the boot code 140 determines in block 1715 that this is not the first power cycle after POR, the boot code 140 may proceed to block 1740 and may set the firmware mailbox 786 status to indicate that the key code (e.g., DevAK key code 1922 of FIG. 19) is not valid. The boot code 140 may then proceed to block 1745, where the boot code may authenticate and load (e.g., execute by the processor 160) the FMC (e.g., firmware) into SRAM.

[0136] If the boot code 140 determines in block 1710 that the SRAM PUF is registered, the boot code 140 may proceed to block 1735 and may initiate a known cryptographic context using the PUF activation code 621 and the SRAM PUF unique silicon fingerprint corresponding to the current owner of the electronic device 101 to regenerate (1) a uniform random cryptographic key and (2) a key code corresponding to the key. The boot code 140 may then proceed to block 1730 and may store the key code generated in block 1735 in the firmware mailbox 786 (FIG. 7). The boot code 140 may proceed to block 1740 and may set the firmware mailbox 786 status to indicate that the key code (e.g., DevAK key code 1922 in FIG. 19) is valid. The boot code 140 may proceed to block 1745 and may authenticate and load the FMC (e.g., firmware) into the SRAM (e.g., executed by the processor 160). The FMC can then execute in the cryptographic context established by the boot code 140 (i.e., corresponding to the PUF activation code 621 - the same cryptographic context established by the registration process for the current owner of the electronic device 101) and can access the key code stored in the firmware mailbox 786. An example use of the key code is described in connection with Figures 18-30 below.

[0137] 17 discloses a particular number of operations associated with method 1700, method 1700 may be performed with more or fewer operations than those shown in FIG. 17. For example, after block 1725, boot code 140 may sign the secure RPMC owner container, as described above in the description of container signature 312 (FIG. 3). Signing the owner container at this time may ensure that PUF startup code 621 may only be modified by boot code 140 such that its integrity may be maintained. As another example, before block 1745, boot code 140 may set a read / write lock on SRAM 172 (FIG. 16) such that application code (e.g., FMC) may have access to portion 1608 of SHD_PUF region 1606 / 1608 but may not have access to portion 1606 of SHD_PUF region 1606 / 1608. In some embodiments, the boot code 140 can set a read / write lock on the SHD_PUF region 1606 at all termination events such that no user code (e.g., the FMC) can access the secret SRAM PUF keying material. In addition, although FIG. 17 discloses a particular order of operations performed with respect to the method 1700, the operations making up the method 1700 may be completed in any suitable order.

[0138] FIG. 18 illustrates an exemplary electronic device 1801 that may respond to Secure Protocol Data Model (SPDM) GET_ATTESTATION and GET_CERTIFICATE commands. SPDM is published by the Distributed Management Task Force. Some embodiments may conform to the SPDM specification, which specifies that "Runtime authentication is a process in which an authentication initiator or requester interacts with a responder in a running system. The authentication initiator may retrieve a certificate chain from the responder and send a unique challenge to the responder. The responder signs the challenge using its private key. The authentication initiator verifies the signature by using the responder's public key and any intermediate public keys in the certificate chain by using the root certificate as a trusted anchor."

[0139] The exemplary electronic device 1801 may include boot code 1840 (e.g., immutable boot code or authenticated mutable code) and SRAM 1872. SRAM 1872 may include firmware mailbox 1886 (which may be an instance of firmware mailbox 786 (FIG. 7)) and FMC 1820 (which may function as an SPDM responder). SRAM 1872 may also include SHD_PUF area 1816 / 1818 and ROM_PUF area 1814, which may be instances of SHD_PUF area 1606 / 1608 and ROM_PUF area 1604 (FIG. 16), respectively (e.g., may be read / write lockable, such that FMC 1820 has access to SHD_PUF area 1818 but not SHD_PUF area 1816 or ROM_PUF area 1814). The initiator 1821 may be external to the electronic device 1801 and may function as an SPDM requester. In one embodiment, the initiator 1821 may communicate with the electronic device 1801 via an I2C communication interface.

[0140] In one embodiment, the boot code 1840 can register the SHD_PUF to serve as keying material for the DevAK key and can register the ROM_PUF to serve as keying material for the DevIK key. In one embodiment, the boot code can perform these tasks using the SRAM PUF API (e.g., SRAM PUF functions) such that the private encryption keys (DevAKpriv and DevIKpriv) cannot be extracted by other boot code or the FMC (e.g., the private keys can only be known to the SRAM PUF API). After registering the SHD_PUF and ROM_PUF, the boot code 1840 acting as a root of trust (RoT) can store the DevIKpub (public) key, the DevAK certificate including the DevAKpub (public) key, and the DevAK key code in the firmware mailbox 1886. The boot code 1840 can obtain the DevAKpub and DevAK keycode from the SHD_PUF (via an SRAM PUF API call) and the DevIKpub from the ROM_PUF (via an SRAM PUF API call). (More details regarding the generation of the DevAK certificate are provided in FIG. 19 and the associated description below.) In one embodiment, the FMC can access information stored in the firmware mailbox 1886, such as the DevAK keycode.

[0141] In one embodiment, the initiator 1821 can send an SPDM GET_ATTESTATION challenge to the FMC 1820 via the I2C interface. To respond, the FMC 1820 may need to return a challenge signed with the DevAKpriv key. However, the DevAKpriv key may be kept secret within the SHD_PUF and may not be directly accessible by the FMC 1820. In the illustrated example, the FMC 1820 can provide the data to be signed and the DevAK keycode to the SHD_PUF 1816 / 1818 (e.g., via an SRAM PUF API call) and receive the data signed with the DevAKpriv key in return. The SRAM PUF API can derive the DevAKpriv key using the DevAK keycode. Thus, the FMC 1820 can sign the GET_ATTESTATION challenge with the DevAKpriv key derived using the SHD_PUF 1816 / 1818 and the DevAK keycode, even though the DevAKpriv key is not exposed (or directly accessible) to the FMC 1820. The FMC 1820 can then send the signed challenge to the initiator 1821.

[0142] In another embodiment, the initiator 1821 may send an SPDM GET_CERTIFICATE request to the FMC 1820 over the I2C interface. In some embodiments, the FMC 1820 may respond by sending a device X.509 certificate, which may be a device authentication certificate (DevAKcert). In other embodiments, the FMC 1820 may respond by sending a device X.509 certificate chain, which may include a device identification certificate (DevIKcert) and a device authentication certificate (DevAKcert).

[0143] FIG. 19 illustrates an exemplary electronic device 1901 according to the present disclosure. The electronic device 1901 may include a boot code 1904, a firmware mailbox 1986, a PUF engine 1955, a ROM_PUF 1985, a SHD_PUF 1999, and an FMC 1920. The boot code 1940 may be immutable boot code stored in ROM 130 (FIG. 1) or may be authenticated mutable code stored, for example, in non-volatile memory 173 (FIG. 1). The PUF engine 1955 may include code that causes the processor to execute functions, including, but not limited to, SRAM PUF API functions. In one embodiment, the PUF engine 1955 code may be immutable code stored in ROM 130 (FIG. 1). The firmware mailbox 1986 may be an area in the command memory 171 (FIG. 7), which may be a volatile SRAM. ROM_PUF 1985 and SHD_PUF 1999 may be read / write lockable regions in non-volatile SRAM 172 (FIG. 16). FMC 1920 may be authenticated alterable code, such as firmware or application code, that can act as an SPDM responder (e.g., similar to FMC 1820 of FIG. 18).

[0144] As shown, the ROM_PUF 1985 and SHD_PUF 1999 regions are directly accessible by the PUF engine 1955 (SRAM PUF API), but may not be directly accessible by the FMC 1920. For example, the FMC 1920 may be read / write locked, so that it does not read or write to the keying material portions of the SHD_PUF 1999 region. However, the FMC 1920 may call SRAM PUF API functions of the PUF engine 1955, which may have access to the SHD_PUF secrets, for example, to sign data provided by the FMC 1920 with the DevAKpriv key. In one embodiment, the PUF engine and SRAM PUF API may be designed to not expose the SHD_PUF (or ROM_PUF) secrets to the FMC 1920, or in some embodiments, to the boot code 1940. For example, an SRAM PUF API function may not allow the FMC 1920 to read any of the secrets and may not return them to the FMC 1920 as a result of the function call.

[0145] The remote host 1933 may be external to the electronic device 1901 and may act as an SPDM requester. In one embodiment, the remote host 1901 may communicate with the electronic device 1901 via a communication interface (e.g., I2C).

[0146] The electronic device 1901 may support actions including, but not limited to, those indicated by numbered arrows 1-18.

[0147] Action 1 may represent the boot code 1940 requesting initialization of an SRAM PUF (e.g., ROM_PUF, SHD_PUF). In one embodiment, the initialization request may be a request to register the SRAM PUF following a determination that the SRAM PUF is not registered following a change of ownership (block 1710 of FIG. 17) and to initiate a new cryptographic context associated with a new owner. In another embodiment, the initialization request may be a request to initiate a known cryptographic context for a current owner of the electronic device (block 1725 of FIG. 17). For example, the known cryptographic context may be based on the current owner's PUF activation code 621 (the activation code may be passed to the PUF engine 1955 as part of a function call). In an embodiment, the initialization request may be directed to the ROM_PUF 1985. In another embodiment, the initialization request may be directed to the SHD_PUF 1999.

[0148] Action 2 may represent the boot code 1940 requesting generation (or regeneration) of a DevAKpriv key based on a current cryptographic context. As a result of the request, the PUF engine 1955 may use private key information in the SHD_PUF 1999 to create a DevAKpriv key based on a current cryptographic context (e.g., a context initiated by a previous SRAM PUF initialization request). In one embodiment, the PUF engine 1955 may return a DevAK key code corresponding to the DevAKpriv key. In another embodiment, action 2 may represent the boot code 1940 requesting generation (or regeneration) of a DevIKpriv key based on a current cryptographic context. As a result of the request, the PUF engine 1955 may use private key information in the ROM_PUF 1985 to create a DevIKpriv key based on a current cryptographic context (e.g., a context initiated by a previous SRAM PUF initialization request). In one embodiment, the PUF engine 1955 may return a DevIK key code corresponding to the DevIKpriv key.

[0149] Action 3 may represent boot code 1940 requesting a DevAKpub key or a DevIKpub key. Because the public key of the key pair is not secret, PUF engine 1955 may expose the public key to boot code 1940 (e.g., return the public key to boot code 1940 so that boot code 1940 can use the key). In one embodiment, boot code 1940 provides PUF engine 1955 with a key code (e.g., a DevAK key code or a DevIK key code) that corresponds to the public key it is requesting.

[0150] Action 4 may represent the boot code 1940 requesting a DevAKpriv or DevIKpriv keycode, which may be used in a subsequent signing request to the PUF engine 1955 (e.g., the FMC requesting signing of an SPDM attestation challenge with DevAKpriv, as described with respect to FIG. 18).

[0151] Action 5 may represent the boot code 1940 requesting that the data be signed with either the DevIKpriv key or the DevAKpriv key. In one embodiment, the boot code may send the data to be signed and the corresponding key code to the PUF engine 1955. The PUF engine 1955 may return the data signed with the appropriate key.

[0152] Action 6 may represent boot code 1940 generating certificate DevAK cert 1976. In an embodiment, DevAK cert 1976 may include the DevAKpub key (e.g., obtained from PUF engine 1955 in action 3) as its subject. DevAK cert 1976 may be signed with DevIKpriv (e.g., boot code 1940 may send unsigned certificate data along with the DevIK key code to PUF engine 1955 for signing in action 5).

[0153] Action 7 may represent the boot code 1940 storing the signed DevAK cert 1976 in the firmware mailbox 1986, thereby providing the signed DevAK cert 1976 to the FMC 1920.

[0154] Action 8 may represent the boot code 1940 storing the DevAK key code 1922 in the firmware mailbox 1986, thereby providing the DevAK key code 1922 to the FMC 1920. (The boot code may obtain the DevAK key code 1922 from the PUF engine 1955 in action 4.)

[0155] Action 9 may represent the boot code 1940 storing the signed DevIKpub 1924 in the firmware mailbox 1986, thereby providing the signed DevIKpub 1924 to the FMC 1920. (The boot code 1940 may obtain the DevIKpub key from the PUF engine 1955 in action 3.)

[0156] Action 10 may represent the FMC 1920 reading the signed DevAK cert 1976 from the firmware mailbox 1986.

[0157] Action 11 may represent the FMC 1920 reading the DevAK key code 1922 from the firmware mailbox 1986.

[0158] Action 12 may represent the FMC 1920 reading the DevIKpub 1924 from the firmware mailbox 1986.

[0159] Action 13 may represent the FMC 1920 requesting the DevAKpub key from the PUF engine 1955. In one embodiment, the FMC 1920 may send the DevAK key code 1922 to the PUF engine 1955 (e.g., after retrieving it from the firmware mailbox 1986). The PUF engine 1955 may return the DevAKpub key.

[0160] Action 14 may represent the FMC 1920 requesting that data be signed with the DevAKpriv key. In one embodiment, the FMC 1920 may send the data to be signed along with the DevAK keycode 1922 (e.g., after retrieving it from the firmware mailbox 1986) to the PUF engine 1955. The PUF engine 1955 may return the data signed with the DevAKpriv key.

[0161] Action 15 may represent the remote host 1933 issuing an SPDM request (e.g., GET_ATTESTATION, GET_CERTIFICATE) to the FMC 1920 (shown / described in FIG. 18).

[0162] Action 16 may represent the FMC 1920 returning a signed SPDM challenge to the remote host 1933, for example, in response to a GET_ATTESTATION request (shown / described in FIG. 18).

[0163] Action 17 may represent the FMC 1920 returning a certificate to the remote host 1933, for example in response to a GET_CERTIFICATE request.

[0164] Although FIG. 19 discloses a particular number of actions (1-17) associated with electronic device 1901, electronic device 1901 may be executed with more or fewer actions than those shown in FIG. 19. For example, boot code 1940 or FMC 1920 may request PUF engine 1955 to stop the current cryptographic context (e.g., a stop() request), which may result in the SRAM PUF secret being destroyed or erased and the SRAM PUF being returned to its uninitialized state. As another example, boot code 1940 may request to set a read / write lock on the SRAM PUF region, which may result in no user code (e.g., FMC 1920) having access to the secret SRAM PUF keying material. As yet another example, FMC 1920 may request the generation of other keys (e.g., not DevAK or DevIK) using the SHD_PUF. In an embodiment, the PUF engine 1955 can return a key code for the newly generated key, and the FMC 1920 can use the key code to request the PUF engine 1955 to sign data with the newly generated key, generate and transmit a public key corresponding to the newly generated key, etc. Thus, the private key may not be revealed to the FMC 1920, but the private key can still be used to sign data. Additionally, although FIG. 19 discloses actions 1-17, these actions may be completed in any suitable order.

[0165] FIG. 20 illustrates an exemplary boot code method 2000 for DevAK key and certificate generation. According to one embodiment, method 2000 may begin at block 2002. In one embodiment, method 2000 may be performed by boot code 140, 1840, or 1940. In some embodiments, start block 2002 may represent the time when electronic device 101 is first powered on (POR) or the time following a reset of the electronic device (e.g., a device reset, reboot, or power cycle). Thus, method 2000 may be performed by boot code 140 when volatile memory 172 (e.g., SRAM having ROM_PUF and SHD_PUF regions) cannot be accessed by the FMC (e.g., because the FMC has not yet been authenticated and loaded). The teachings of the present disclosure may be performed in various configurations of system 100. Thus, the initialization point of method 2000 and the order of 2002-2032 that make up method 2000 may depend on the implementation selected.

[0166] In one embodiment, the method 2000 may begin by generating a DevAK key. Starting at block 2002, the boot code 140 may initialize the SHD_PUF (e.g., 1606 / 1608 of FIG. 16). In one embodiment, this may include the boot code 140 registering the SHD_PUF for the first time after a transfer of ownership of the electronic device. In another embodiment, this may include providing the current owner's PUF activation code to the PUF engine to re-establish a previous cryptographic context for the current owner. The method may then proceed to block 2004, where the boot code 140 may request generation of a DevAKpriv key and obtain a DevAK keycode (e.g., action 2 of FIG. 19). The method may then proceed to block 2006, where the boot code 140 may request generation of a DevAKpub key using the DevAK keycode (e.g., action 3 of FIG. 19). The method may then proceed to block 2008, where the boot code 140 may store the DevAK keycode in the firmware mailbox 1986 (e.g., action 8 of FIG. 19 ). The method may then proceed to block 2010, where the boot code 140 may request to stop the current SHD_PUF cryptographic context (e.g., a stop() request), which may result in the SHD_PUF secret being destroyed or erased and returning the SHD_PUF to its uninitialized state.

[0167] In one embodiment, the method 2000 may proceed by generating a DevIK key. Starting at block 2012, the boot code 140 may initialize the ROM_PUF (e.g., 1604 of FIG. 16). In one embodiment, this may include the boot code 140 registering the ROM_PUF for the first time, or in another embodiment, re-establishing a previous cryptographic context. In one embodiment, the ROM_PUF cryptographic context may be the same for different owners of the electronic device. In another embodiment, the ROM_PUF cryptographic context (like the SHD_PUF cryptographic context) may be unique per owner of the electronic device. Thus, initializing the ROM_PUF at block 2012 may or may not include providing the current owner's PUF activation code to the PUF engine to re-establish a previous cryptographic context for the current owner. The method may then proceed to block 2014, where the boot code 140 may request generation of a DevIKpriv key and obtain a DevIK key code (e.g., action 2 of FIG. 19).

[0168] In one embodiment, the method 2000 may proceed by generating a DevAK certificate. Beginning at block 2016, the boot code 140 may obtain a DevAK certificate template, which may be stored in the OTP memory 110, the non-volatile memory 173, the boot ROM 130, or any other suitable location. (The boot code 140 may authenticate the DevAK certificate template prior to use (not shown).) In one embodiment, the DevAK certificate may be an X.509 CA or END certificate in ANSI.1 DER format. In other examples, the DevAK certificate may be generated in other certificate formats. The method may then proceed to block 2018, where the boot code 140 may generate a DevAK unsigned certificate, for example, by storing the DevAKpub key (e.g., generated at block 2006) as the certification subject. The method may then proceed to block 2020, where the boot code 140 may request to sign the DevAK certificate with the DevIKpriv key. In one embodiment, the boot code 140 sends a request to the PUF engine to sign the DevAK certificate with the DevIKpriv key by providing the DevAK unsigned proof data (e.g., generated in block 2014) and the DevIK key code to the PUF engine (e.g., action 5 of FIG. 19 ). The method may then proceed to block 2022, where the boot code 140 may store the DevAK certificate in the firmware mailbox 1986 (e.g., action 7 of FIG. 19 ). The method may then proceed to block 2024, where the boot code 140 may request to stop the current ROM_PUF cryptographic context (e.g., a stop() request), which may result in the ROM_PUF secret being destroyed or erased and the ROM_PUF returning to its uninitialized state.

[0169] In one embodiment, the method 2000 may proceed by initializing the SHD_PUF for use by the FMC. Beginning at block 2026, the boot code 140 may initialize the SHD_PUF as described for block 2002. The method may then proceed to block 2028, where the boot code 140 may request generation of a DevAKpriv key and obtain a DevAK keycode (e.g., action 2 of FIG. 19). The method may then proceed to block 2030, where the boot code 140 may verify that the generated DevAK keycode matches the DevAK keycode 1922 previously stored in the firmware mailbox 1986 (e.g., at block 2008). In this example, the verification at block 2030 may confirm that the FMC and boot code 140 are using the same cryptographic context and therefore the same DevAK keypair. The method may then proceed to block 2032, where the boot code 140 may request setting a read / write lock for the ROM_PUF and the SHD_PUF. In one embodiment, the read / write lock may be set on the ROM_PUF such that the FMC has no access. In the same example or a different example, the read / write lock may be set on the SHD_PUF such that the FMC does not have access to the SHD_PUF keying material area (e.g., 1606 in FIG. 16 ) but has access to the SHD_PUF state area (e.g., 1608 in FIG. 16 ) that may enable the FMC to use the DevAK key code and PUF API to sign SPDM challenges and access other authorized PUF functions (e.g., use the DevAK key code to obtain the DevAKpub key and create other cryptographic key pairs, among other things).

[0170] Although FIG. 20 discloses a particular number of operations associated with method 2000, method 2000 may be performed with more or fewer operations than those shown in FIG. 20. For example, after block 2008, the boot code may not require stopping the SHD_PUF. Similarly, after block 2022, the boot code may not require stopping the ROM_PUF. In these embodiments, stopping the SRAM PUF at a boot code exit event may be a good practice to avoid FMC access to device secrets. However, stopping the SRAM PUF may be avoided if, for example, the boot code executes blocks 2002-2032 of method 2000 without exiting the FMC or before loading the FMC. In one embodiment, if block 2010 is omitted, block 2026 (initializing the SHD_PUF) may also be omitted since the SHD_PUF was not stopped. 20 discloses a particular order of operations performed with respect to method 2000, the operations making up method 2000 may be completed in any suitable order. For example, the boot code may generate a DevIK key (blocks 2012-2014) before generating a DevAK key (blocks 2002-2010).

[0171] 21 illustrates a flow chart of an example method 2100 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2100 may begin at block 2110. The teachings of the present disclosure may be performed in a variety of configurations of system 100. Thus, the initialization point of method 2100 and the order of steps 2110-2135 that make up method 2100 may depend on the implementation selected.

[0172] In block 2110, for an electronic device having a processor, a non-volatile memory, and an SRAM including an SRAM Physical Unclonable Function (SRAM PUF) area, the processor may store the first owner information and the first owner variable code in the non-volatile memory. In one embodiment, the SRAM PUF area may include a secret, unclonable silicon fingerprint that is unique to the electronic device. In the same or different embodiment, the first owner information may be stored in the non-volatile memory such that it may emulate a one-time programmable memory (e.g., as an OTP emulated parameter, as described with respect to FIG. 6) and may be unique to the first owner of the electronic device. At block 2115, the processor may generate a first unique private key based on both the first owner information and at least a portion of the SRAM PUF region, where the first unique private key may not be directly accessible by the first owner variable code (e.g., the PUF engine 1955 may not reveal the first unique private key to the first owner variable code while still allowing the first owner variable code to sign data with the first unique private key). At block 2120, the processor may generate a first unique private key code corresponding to the first unique private key. At block 2125, the processor may provide the first unique private key code to the first owner variable code. (The key code may serve as a reference or handle to the corresponding key, such that when the key code is passed to the PUF engine 1955, the PUF engine 1955 can use the key code to determine the corresponding key. In this way, the key may not be exposed outside of the PUF engine 1955 and its confidentiality may be maintained.) At block 2130, the processor may receive a signature request from the first owner variable code, the signature request including the first unique secret key code and the first data. In one embodiment, the first data may include a device attestation challenge.At block 2130, in response to a signature request from the first owner variable code, the processor may sign the first data with the first unique private key and provide the first data signed with the first unique private key to the first owner variable code.

[0173] Although Figure 21 discloses a particular number of operations associated with method 2100, method 2100 may be performed with more or fewer operations than those depicted in Figure 21. For example, after block 2135, method 2100 may continue with additional operations depicted in Figures 22-29. Additionally, although Figure 21 discloses a particular order of operations performed with respect to method 2100, the operations comprising method 2100 may be completed in any suitable order.

[0174] 22 illustrates a flow chart of an example method 2200 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2200 may begin at block 2210. The teachings of the present disclosure may be performed in various configurations of system 100. Thus, the initialization point of method 2200 and the order of steps 2210-2220 that make up method 2200 may depend on the implementation selected.

[0175] According to one embodiment, block 2210 may be the same as blocks 2110-2135 of FIG. 21. In block 2215, the processor may receive a key generation request from the first owner variable code. In block 2220, in response to the key generation request from the first owner variable code, the processor may generate a first owner-specific variable code key based on at least a portion of the SRAM PUF area. In one embodiment, the generated first owner-specific variable code key may be based on keying material in the SHD_PUF area 1606 (FIG. 16) and may be different from the DevAK key (e.g., for use other than responding to device attestation challenges).

[0176] Although Figure 22 discloses a particular number of operations associated with method 2200, method 2200 may be performed with more or fewer operations than those depicted in Figure 22. Additionally, although Figure 22 discloses a particular order of operations performed with respect to method 2200, the operations making up method 2200 may be completed in any suitable order.

[0177] 23 illustrates a flow chart of an example method 2300 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2300 may begin at block 2310. The teachings of the present disclosure may be performed in a variety of configurations of system 100. Thus, the initialization point of method 2300 and the order of steps 2310-2335 that make up method 2300 may depend on the implementation selected.

[0178] According to one embodiment, block 2310 may be the same as blocks 2110-2135 of FIG. 21. In block 2315, the processor may transfer ownership of the electronic device to the second owner, including storing in the non-volatile memory the second owner information and the second owner variable code, where the second owner information may be unique to the second owner of the electronic device. In one embodiment, the ownership transfer may proceed as shown and described in any of FIGs. 8-15. In block 2320, the processor may generate a second unique private key based on both the second owner information and at least a portion of the SRAM PUF area, where the second unique private key may not be directly accessible by the second owner variable code (e.g., the PUF engine 1955 may not reveal the key to the second owner variable code while still allowing the second owner variable code to sign data with the key). In block 2325, the processor may generate a second unique private key code corresponding to the second unique private key. In block 2330, the processor may provide the second owner variable code with the second unique secret key code. In block 2335, the processor may prohibit access to or regeneration of the first unique secret key while the second owner has possession of the electronic device. In one embodiment, access may be prohibited because (1) the first unique secret key has been erased or destroyed (e.g., by a stop() request or by resetting the electronic device 101) and the boot code 140 may limit the cryptographic context to the current user's cryptographic context, for example, by using the current owner's PUF activation code, which may be authenticated prior to use. Thus, the system may not allow use of the previous owner's PUF activation code, and therefore prohibit access to or regeneration of the first unique secret key.

[0179] Although Figure 23 discloses a particular number of operations associated with method 2300, method 2300 may be performed with more or fewer operations than those depicted in Figure 23. For example, after block 2335, method 2300 may continue with additional operations depicted in Figures 24-25. Additionally, although Figure 23 discloses a particular order of operations performed with respect to method 2300, the operations comprising method 2300 may be completed in any suitable order.

[0180] 24 illustrates a flow chart of an example method 2400 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2400 may begin at block 2410. The teachings of the present disclosure may be performed in various configurations of system 100. Thus, the initialization point of method 2400 and the order of steps 2410-2420 that make up method 2400 may depend on the implementation selected.

[0181] According to one embodiment, block 2410 may be the same as blocks 2310-2335 of Figure 23. In block 2415, the processor may receive a second owner signature request from the second owner variable code, the second owner signature request including the second unique private key code and second data (e.g., a proof challenge). In block 2420, in response to the second owner signature request from the second owner variable code, the processor may sign the second data with the second unique private key and provide the second data signed with the second unique private key to the second owner variable code.

[0182] Although Figure 24 discloses a particular number of operations associated with method 2400, method 2400 may be performed with more or fewer operations than those depicted in Figure 24. For example, after block 2420, method 2400 may continue with additional operations depicted in Figure 25. Additionally, although Figure 24 discloses a particular order of operations performed with respect to method 2400, the operations comprising method 2400 may be completed in any suitable order.

[0183] 25 illustrates a flow chart of an example method 2500 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2500 may begin at block 2510. The teachings of the present disclosure may be performed in a variety of configurations of system 100. Thus, the initialization point of method 2500 and the order of steps 2510-2520 that make up method 2500 may depend on the implementation selected.

[0184] According to one embodiment, block 2510 may be the same as blocks 2410-2420 of FIG. 24. In block 2515, the processor may receive a key generation request from the second owner variable code. In block 2520, in response to the key generation request from the second owner variable code, the processor may generate a second owner-specific variable code key based on at least a portion of the SRAM PUF area. In one embodiment, the generated second owner-specific variable code key may be based on keying material in the SHD_PUF area 1606 (FIG. 16) and may be different from the DevAK key (e.g., for use other than responding to device attestation challenges).

[0185] Although Figure 25 discloses a particular number of operations associated with method 2500, method 2500 may be performed with more or fewer operations than those shown in Figure 25. Additionally, although Figure 25 discloses a particular order of operations performed with respect to method 2500, the operations making up method 2500 may be completed in any suitable order.

[0186] 26 illustrates a flow chart of an example method 2600 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2600 may begin at block 2610. The teachings of the present disclosure may be performed in a variety of configurations of system 100. Thus, the initialization point of method 2600 and the order of steps 2610-2625 that make up method 2600 may depend on the implementation selected.

[0187] According to one embodiment, block 2610 may be the same as blocks 2110-2135 of FIG. 21. In block 2615, the method may include destroying the first unique private key during a reset of the electronic device. In one embodiment, the first unique private key may be destroyed or erased during a reset because it is stored in a volatile memory and its contents may not be maintained during the reset event. In an alternative embodiment, the processor may destroy or erase the first unique private key by making a stop() request to the PUF engine 1955 in response to an instruction in the boot code. In response to the request, the PUF engine 1955 may destroy or erase the first unique private key, which may be a variable code stored in a ROM (e.g., ROM 130). In block 2620, following a reset of the electronic device, the processor may generate a regenerated first unique private key that is equivalent to the first unique private key and is not directly accessible by the first owner variable code (e.g., the PUF engine 1955 may not reveal the regenerated key to the first owner variable code while still allowing the first owner variable code to sign data with the regenerated key). In block 2625, in response to a signing request from the first owner variable code, the processor may sign the first data with the regenerated first unique private key using the first unique private key code. In one embodiment, the PUF engine 1955 may use the first unique private key code as a reference or handle to determine the corresponding key that will ultimately be used to sign the data.

[0188] Although Figure 26 discloses a particular number of operations associated with method 2600, method 2600 may be performed with more or fewer operations than those depicted in Figure 26. Additionally, although Figure 26 discloses a particular order of operations performed with respect to method 2600, the operations making up method 2600 may be completed in any suitable order.

[0189] 27 illustrates a flow chart of an example method 2700 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2700 may begin at block 2710. The teachings of the present disclosure may be performed in various configurations of system 100. Thus, the initialization point of method 2700 and the order of steps 2710-2720 that make up method 2700 may depend on the implementation selected.

[0190] According to one embodiment, block 2710 may be the same as blocks 2110-2135 of Figure 21. At block 2715, the processor may receive a public key request from a first owner variable code, where the public key request may include a first unique private key code. At block 2720, in response to the public key request, the processor may generate a first unique public key corresponding to the first unique private key and provide the first unique public key to the first owner variable code.

[0191] Although Figure 27 discloses a particular number of operations associated with method 2700, method 2700 may be performed with more or fewer operations than those depicted in Figure 27. Additionally, although Figure 27 discloses a particular order of operations performed with respect to method 2700, the operations making up method 2700 may be completed in any suitable order.

[0192] 28 illustrates a flow chart of an example method 2800 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2800 may begin at block 2810. The teachings of the present disclosure may be performed in a variety of configurations of system 100. Thus, the initialization point of method 2800 and the order of steps 2810-2825 that make up method 2800 may depend on the implementation selected.

[0193] According to one embodiment, block 2810 may be the same as blocks 2110-2135 of FIG. 21. In block 2815, the processor may generate a first unique public key corresponding to the first unique private key. In block 2820, the processor may generate a certificate having the first unique public key as a certification subject. In block 2825, the processor may generate a signature for the certificate using the device identity private key.

[0194] Although Figure 28 discloses a particular number of operations associated with method 2800, method 2800 may be performed with more or fewer operations than those depicted in Figure 28. For example, after block 2825, method 2800 may continue with additional operations depicted in Figure 29. Additionally, although Figure 28 discloses a particular order of operations performed with respect to method 2800, the operations comprising method 2800 may be completed in any suitable order.

[0195] 29 illustrates a flow chart of an example method 2900 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2900 may begin at block 2910. The teachings of the present disclosure may be performed in a variety of configurations of system 100. Thus, the initialization point of method 2900 and the order of steps 2910-2915 that make up method 2900 may depend on the implementation selected.

[0196] According to one embodiment, block 2910 may be the same as blocks 2810-2825 of Figure 28. In block 2915, the processor may provide a certificate to the first owner variable code, the certificate may have a first unique public key as a subject of certification.

[0197] Although Figure 29 discloses a particular number of operations associated with method 2900, method 2900 may be performed with more or fewer operations than those depicted in Figure 29. Additionally, although Figure 29 discloses a particular order of operations performed with respect to method 2900, the operations making up method 2900 may be completed in any suitable order.

[0198] 30a-b show a flow chart of an example method 3000 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 3000 may begin at block 3010. The teachings of the present disclosure may be performed in various configurations of system 100. Thus, the initialization point of method 3000 and the order of steps 3010-3070 that make up method 3000 may depend on the implementation selected.

[0199] In block 3010, for an electronic device having a processor, a non-volatile memory, and an SRAM including an SRAM Physical Unclonable Function (SRAM PUF) region, the processor may store first owner information and a first owner variable code in the non-volatile memory. In one embodiment, the SRAM PUF region may include a secret, unclonable silicon fingerprint unique to the electronic device. In the same or different embodiment, the first owner information may be stored in the non-volatile memory such that it may emulate a one-time programmable memory (e.g., as an OTP emulated parameter, as described with respect to FIG. 6) and may be unique to a first owner of the electronic device. In block 3015, the processor may generate a device identification private key based on at least a portion of the SRAM PUF region. In block 3020, the processor may generate a first unique private key that may be based on both the first owner information and at least a portion of the SRAM PUF region, and the first unique private key may not be directly accessible by the first owner variable code (e.g., the PUF engine 1955 may not reveal the first unique private key to the first owner variable code while still allowing the first owner variable code to sign data with the key). In block 3025, the processor may generate a first unique public key corresponding to the first unique private key. In block 3030, the processor may generate a first unique private key code corresponding to the first unique private key. In block 3035, the processor may generate a certificate that may have the first unique public key as a certification subject. In block 3040, the processor may sign the certificate using the device identification private key. At block 3045, the processor may provide the first unique secret key code to the first owner variable code (e.g., by storing it in a firmware mailbox). At block 3050, the processor may provide the first owner variable code with a certificate (e.g., by storing it in a firmware mailbox).At block 3055, the method may include erasing the first unique private key during a reset of the electronic device. In one embodiment, the first unique private key may be destroyed or erased during a reset since it is stored in a volatile memory, and its contents may not be maintained during the reset event. In an alternative embodiment, the boot code may cause the processor to destroy or erase the first unique private key by issuing a stop() request to the PUF engine 1955. At block 3060, following a reset of the electronic device, the processor may generate a regenerated first unique private key that is equivalent to the first unique private key and is not directly accessible by the first owner variable code (e.g., the PUF engine 1955 may not reveal the regenerated key to the first owner variable code while still allowing the first owner variable code to sign data with the regenerated key). At block 3065, the processor may receive a signature request from the first owner variable code, the signature request including the first unique private key code and the first data. In one embodiment, the first data may include a device attestation challenge. At block 3070, in response to receiving the signing request from the first owner variable code, the processor may sign the first data with the regenerated first unique private key and provide the first data signed with the regenerated first unique private key to the first owner variable code.

[0200] 30a-b disclose a particular number of operations associated with method 3000, but method 3000 may be performed with more or fewer operations than those depicted in FIGURES 30a-b. Additionally, although FIGURES 30a-b disclose a particular order of operations performed with respect to method 3000, the operations making up method 3000 may be completed in any suitable order.

[0201] Methods 1700 and 2000-3000 may be performed using system 100 or any other system operable to perform methods 1700 and 2000-3000. Although embodiments have been described above, other variations and embodiments may be made from this disclosure without departing from the spirit and scope of these disclosed embodiments.

Claims

1. A device, An electronic device, Boot code, A first variable code stored in a non - volatile memory, First owner information stored in the non - volatile memory, A static random access memory (SRAM) including a SRAM physically non - replicable function (SRAM PUF) area, comprising an electronic device, The boot code, Generates a first unique secret key based on both the first owner information and at least a part of the SRAM PUF area, and the first unique secret key is not directly accessible by the first variable code, Generates a first unique secret key code corresponding to the first unique secret key, Is executable by a processor to provide the first unique secret key code corresponding to the first unique secret key to the first variable code, The first variable code, Uses the first unique secret key code to sign data with the first unique secret key, A device executable by the processor to generate a first unique variable code secret key based on at least a part of the SRAM PUF area.

2. The device according to claim 1, wherein the SRAM PUF area includes a secret non - replicable silicon fingerprint unique to the electronic device.

3. The device according to claim 1 or 2, wherein the first owner information stored in the non - volatile memory emulates a one - time programmable memory and is unique to the first owner of the electronic device.

4. The boot code, Transfers the ownership of the electronic device to a second owner, including storing second owner information in the non - volatile memory, and the second owner information is unique to the second owner of the electronic device, Generates a second unique secret key based on both the second owner information and at least a part of the SRAM PUF area, and the second unique secret key is not directly accessible by the first variable code, Generates a second unique secret key code corresponding to the second unique secret key, Provides the second unique secret key code to the first variable code, The device according to claim 3, which is executable by the processor to prohibit access to the first unique secret key or regeneration of the first unique secret key while the second owner owns the electronic device.

5. The device according to claim 4, wherein the first variable code is executable by the processor to sign data with the second unique secret key using the second unique secret key code.

6. Upon reset of the electronic device, the first unique secret key is erased, the boot code is executable by the processor to generate a regenerated first unique secret key that is equivalent to the first unique secret key and not directly accessible by the first variable code following the reset of the electronic device, The device according to claim 1, wherein the first variable code being executable by the processor to sign data with the first unique secret key using the first unique secret key code includes that the first variable code is executable by the processor to sign the data with the regenerated first unique secret key using the first unique secret key code.

7. The first variable code is executable by the processor to receive a device authentication challenge from a remote host and transmit a signed device authentication response to the remote host in response to the device authentication challenge, The device according to claim 1, wherein the first variable code being executable by the processor to sign data with the first unique secret key using the first unique secret key code includes that the first variable code is executable by the processor to sign the device authentication response with the first unique secret key using the first unique secret key code.

8. For an electronic device having a processor, a non-volatile memory, and a static random access memory (SRAM) including an SRAM physically unclonable function (SRAM PUF) region, the step of the processor storing first owner information and first owner variable code in the non-volatile memory, The step of the processor generating a first unique secret key based on both the first owner information and at least a portion of the SRAM PUF region, wherein the first unique secret key is not directly accessible by the first owner variable code; generating. The step of the processor generating a first unique secret key code corresponding to the first unique secret key. The step of the processor providing the first unique secret key code to the first owner variable code. The step of the processor receiving a signature request from the first owner variable code, the signature request including the first unique secret key code and first data; receiving. In response to the signature request from the first owner variable code. The step of the processor signing the first data with the first unique secret key. The step of the processor providing the first data signed with the first unique secret key to the first owner variable code. A method including.

9. The step of the processor receiving a key generation request from the first owner variable code. In response to the key generation request from the first owner variable code, the step of the processor generating a first owner-specific variable code key based on at least a portion of the SRAM PUF region. The method according to claim 8.

10. The method according to claim 8 or 9, wherein the SRAM PUF region includes a secret non-replicable silicon fingerprint unique to the electronic device.

11. The method according to claim 8, wherein the first owner information stored in the non-volatile memory emulates a one-time programmable memory and is unique to the first owner of the electronic device.

12. The step of transferring ownership of the electronic device to a second owner, including the processor storing second owner information and second owner variable code in the non-volatile memory, wherein the second owner information is unique to the second owner of the electronic device; transferring. The step in which the processor generates a second unique secret key based on both the second owner information and at least a part of the SRAM PUF area, wherein the second unique secret key is not directly accessible by the second owner variable code; generating step The step in which the processor generates a second unique secret key code corresponding to the second unique secret key; The step in which the processor provides the second unique secret key code to the second owner variable code; The method according to claim 8, comprising: the step in which the processor prohibits access to the first unique secret key or regeneration of the first unique secret key while the second owner owns the electronic device.

13. The step in which the processor receives a second owner signature request from the second owner variable code, wherein the second owner signature request includes the second unique secret key code and second data; receiving step In response to the second owner signature request from the second owner variable code The step in which the processor signs the second data with the second unique secret key; The method according to claim 12, comprising: the step in which the processor provides the second data signed with the second unique secret key to the second owner variable code.

14. The step in which the processor receives a key generation request from the second owner variable code; In response to the key generation request from the second owner variable code, the step in which the processor generates a second owner-specific variable code key based on at least a part of the SRAM PUF area; the method according to claim 13.

15. The step of destroying the first unique secret key during reset of the electronic device; The step in which the processor generates a regenerated first unique secret key that is equivalent to the first unique secret key and is not directly accessible by the first owner variable code following the reset of the electronic device; including The method according to claim 8, wherein the step of the processor signing the first data with the first unique secret key in response to the signature request from the first owner variable code includes the processor signing the first data with the regenerated first unique secret key using the first unique secret key code.

16. The method according to claim 8, wherein the first data includes a device authentication challenge.

17. The step of the processor receiving a public key request from the first owner variable code, wherein the public key request includes the first unique secret key code, and in response to the public key request, the step of the processor generating a first unique public key corresponding to the first unique secret key, and the step of the processor providing the first unique public key to the first owner variable code, which are included in the method according to claim 8.

18. The step of the processor generating a first unique public key corresponding to the first unique secret key, and the step of the processor generating a certificate having the first unique public key as the object to be certified, and the step of the processor generating a signature for the certificate using the device identification secret key, which are included in the method according to claim 8.

19. The method according to claim 18, including the step of the processor providing the certificate having the first unique public key as the object to be certified to the first owner variable code.

20. For an electronic device having a processor, a non-volatile memory, and a static random access memory (SRAM) including a SRAM physically unclonable function (SRAM PUF) region, the step of storing first owner information and first owner variable code in the non-volatile memory, and the step of the processor generating a device identification secret key based on at least a part of the SRAM PUF region, and the step of the processor generating a first unique secret key based on both the first owner information and at least a part of the SRAM PUF region, wherein the first unique secret key is not directly accessible by the first owner variable code, and the step of the processor generating a first unique public key corresponding to the first unique secret key, The step of the processor generating a first unique secret key code corresponding to the first unique secret key; The step of the processor generating a certificate having the first unique public key as the object to be proved; The step of the processor signing the certificate using the device identification secret key; The step of the processor providing the first unique secret key code to the first owner variable code; The step of the processor providing the certificate to the first owner variable code; The step of erasing the first unique secret key during reset of the electronic device; The step of the processor generating a regenerated first unique secret key that is equivalent to the first unique secret key and not directly accessible by the first owner variable code following the reset of the electronic device; The step of the processor receiving a signature request from the first owner variable code, the signature request including the first unique secret key code and first data; In response to receiving the signature request from the first owner variable code, The step of the processor signing the first data with the regenerated first unique secret key; The step of the processor providing the first data signed with the regenerated first unique secret key to the first owner variable code, a method comprising.

Images