SRAM physically non-replicable function (PUF) memory for generating keys based on the device owner.

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 the priority of U.S. Provisional Patent Application No. 63 / 335,442, filed on April 27, 2022, the content of which is incorporated herein in its entirety.

[0002] (Field of the Invention) The present disclosure relates to an electronic device, and more particularly, to a system and method for using a static random-access memory (SRAM) physically unclonable function (PUF) shared by multiple entities to manage device keys.

Background Art

[0003] In computing products, embedded controller (EC) boot code stored in the boot ROM can function as a Root of Trust (RoT) for secure boot applications for a specific owner of the electronic device (e.g., the original equipment manufacturer, OEM). The OEM can store configuration options in one-time-programmable (OTP) memory during device provisioning. This may include cryptographic keys used to encrypt and sign the boot image. The OEM can implement and sign an EC boot image that is loaded and authenticated by the boot code stored in the boot ROM. The boot code can use custom values ​​stored in 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 allow the owner to deactivate one or more keys stored in the electronic device's key manifest, or remove certain image revisions from service, particularly by setting bits in OTP memory during the boot sequence.

[0004] An EC with Secure Boot typically has a single configuration provisioned in OTP memory determined at the time of manufacture 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 OTP memory. As a result, all owners of the device use the OEM-signed image.

[0005] An EC with Secure Boot may belong to multiple owners throughout the device's lifespan. Therefore, it is necessary to manage device secrets (e.g., encryption keys) to ensure that these secrets are maintained for each application (e.g., the owner). [Overview of the project]

[0006] According to one embodiment, the system may include an electronic device. The electronic device may have boot code, variable code stored in non-volatile memory, first owner information stored in non-volatile memory, and SRAM including a static random access memory (SRAM) physically non-copyable function (SRAM PUF) area. In some embodiments, the SRAM PUF area includes a secret, non-copyable silicon fingerprint unique to the electronic device. The boot code may include immutable code stored in read-only memory, authenticated code stored in non-volatile memory, authenticated code stored in volatile memory, or a mixture of immutable and authenticated code. The boot code may be executable by the 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 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 to provide the first unique secret key code to the variable code. The variable code may be executable by the processor to use a first unique secret key code to sign data with the first unique secret key and to generate a first unique variable code secret key based on at least a portion of the SRAM PUF area.

[0007] According to the same or different embodiments, first owner information stored in non-volatile memory may emulate information stored in one-time programmable memory and may be unique to the first owner of the electronic device. 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 non-volatile memory, and the second owner information may be unique to the second owner of the electronic device. 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 area, the second unique secret key not directly accessible by the variable code. 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 owns the electronic device.

[0008] According to the same or different embodiments, resetting an electronic device may cause the first unique secret key to be erased. Following the reset of the electronic device, boot code may be executable by the processor to generate a regenerated first unique secret key that is equivalent to the first unique secret key and is not directly accessible by variable code. Variable code may be executable by the processor to use the first unique secret key code to ensure that data is signed with the regenerated first unique secret key.

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

[0010] In the same or different embodiments, 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 different embodiments, the method may include the steps of a processor transferring ownership of an electronic device to a second owner, comprising the steps of (1) storing second owner information and a second owner variable code in non-volatile memory, wherein the second owner information is specific to the second owner of the electronic device; (2) generating a second unique secret key based on both the second owner information and at least a portion of the SRAM PUF area, wherein the second unique secret key is not directly accessible by the second owner variable code; (3) generating a second unique secret key code corresponding to the second unique secret key; (4) providing the second owner variable code with the second unique secret key; and (5) prohibiting access to or regeneration of the first unique secret key while the second owner owns the electronic device. In some embodiments, the method may include the steps of: a processor receiving a second owner signature request from a second owner variable code, the second owner signature request comprising a second unique private key code and 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 private key and providing the second data signed with the second unique private key to the second owner variable code. In other embodiments, the method may include the steps of: a processor receiving 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 area.

[0012] According to the same or different embodiments, resetting an electronic device can destroy a first unique private key. The method may include the steps of a processor (1) generating 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, following the reset of the electronic device, and (2) signing first data with the regenerated first unique private key using the first unique private key code.

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

[0014] According to the same or different embodiments, the method may include the steps of a processor generating a first unique public key corresponding to a first unique private key, generating a certificate having the first unique public key as the subject of proof, and generating a signature for the certificate using a device identification private key. According to one embodiment, the method may include the step of a processor providing a first owner variable code with a certificate having the first unique public key as the subject of proof.

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

[0016] In the same or different embodiments, the Method may include the step of erasing a first unique private key during the reset of an electronic device. The Method may include the steps of a processor generating a regenerated first unique private key that is equivalent to the first unique private key and is not directly accessible by a first owner variable code, following the reset of the electronic device, and receiving a signature request from a first owner variable code, wherein the signature request includes a first unique private key code and first data. In response to receiving a signature request from a first owner variable code, the Method may include the steps of a 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 explanation of the drawing]

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

[0018] Reference numbers for any illustrated element appearing in multiple different figures have the same meaning across the multiple figures, and any reference or discussion herein of any illustrated element in the context of any particular figure applies to any other figure where the same illustrated element is shown. [Modes for carrying out the invention]

[0019] This disclosure provides systems and methods for managing device keys to provide device authentication (certification) to multiple applications (e.g., multiple owners of an electronic device over time) while maintaining the confidentiality of each application's device secret key (e.g., owner). In some embodiments, this disclosure provides systems and methods for key management in which both boot code and first mutable code (FMC) can generate or use the same device certification key pair. In the same or other embodiments in which an electronic device may belong to multiple owners over the lifespan of the device, this disclosure provides systems and methods for generating a device key as a function of the current owner of the electronic device, such that two owners cannot have the same secret key (e.g., device certification key).

[0020] This disclosure provides a system and method for supporting multiple owners of a particular electronic device over time, including the secure transfer of ownership between different owners, by storing information and configurations for each owner in a signed secure replay-protected monotonic counter (RPMC) owner container in memory, for example, in serial peripheral interface (SPI) flash memory. In one embodiment, the owner's cryptographic key, secret, and configuration information may be securely stored 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 content may be signed and verified before being used to aid security. In some embodiments, the system and method for storing and updating the signed secure RPMC owner container 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) starts up (e.g., when powered on, or after a hardware or software reset), boot code may be loaded and executed by the device's processor. The boot code may perform hardware initialization, which may include functions related to device startup, such as disabling interrupts, initializing the bus, setting the processor to a specific state, and initializing memory. After performing hardware initialization, the boot code may load a first variable code (FMC) from a signed first variable binary (FMB), which may include, for example, one or more images. In one embodiment, the FMC may be application firmware that can be signed by the OEM or other owner of the electronic device. In the same or different embodiments, the FMC may be OEM or other owner application firmware, a ROM extension (ROM_EXT) or boot code extension, RIoT (Robust Internet of Things) code, or other variable code. The functions executed by the boot code may be called the boot process.

[0022] An electronic device may include security mechanisms to protect it from malicious attacks. For example, an 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 someone other than the silicon owner. In one embodiment, these operations may require knowledge of secrets (e.g., cryptographic keys) known to the silicon owner. Since the silicon owner controls the secrets (e.g., cryptographic keys) used for loading and execution of the FMC, transfer of ownership, and crisis recovery, malicious attacks on the device can be reduced.

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

[0024] Security features for electronic devices may be implemented using the boot code of the electronic device. In one embodiment, security features may be implemented using immutable boot code. Immutable boot code, which may be called hardware root of trust (RoT), may be incorporated into the electronic device during manufacturing and therefore can be implicitly trusted because it cannot be modified.

[0025] For the purposes of this disclosure, an electronic device may include any means or set of means capable of operating to compute, classify, process, transmit, receive, retrieve, transmit, exchange, store, display, reveal, detect, record, reproduce, 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, which may vary in size, shape, performance, functionality, and price. An electronic device may include one or more processing resources such as 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, mouse, and video display. An electronic device may also include one or more buses capable of transmitting communications between various hardware components.

[0026] system Figure 1 shows a block diagram of an exemplary system 100 for managing ownership of an electronic device 101, including the secure transfer of ownership of the electronic device over time. As shown in Figure 1, system 100 may include the 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 connects various system components to the processors 160, such as an OTP memory 110, a ROM 130, a memory 170, an I / O and port control unit 190, and a network interface 150. The system bus 121 may be any preferred type of bus structure, such as a memory bus, a peripheral bus, or a local bus using any of the various bus architectures.

[0027] The processor 160 may include, but is not limited to, any system, device, or apparatus capable of interpreting or executing program instructions or process data, including a microprocessor, microcontroller, digital signal processor (DSP), application-specific integrated circuit (ASIC), or any other digital or analog circuit for interpreting or executing program instructions or process data. In some embodiments, the processor 160 may interpret or execute program instructions, or process data stored locally (for example, in memory 170, ROM 130, OTP memory 110, or another component of electronic device 101). In the same or alternative embodiments, the 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, bits 120a and 120b of the OTP memory 110 may include conventional logic gates connected by metal wiring, the connections of which may be paired with fuses. During programming, the fuses may be blown to make these connections permanent. In this way, the OTP memory 110 may become unmodifiable once programmed. In one embodiment, unprogrammed bits (e.g., 120a, 120b) may return a value of 0 when read by the processor 160, while programmed bits may return a value of 1 when read by the processor 160. According to this embodiment, once bits 120a and 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) capable of operating to retain program instructions or data after power to the electronic device 101 is turned off. ROM 130 (e.g., boot ROM) may include boot code 140 that can be used by the processor 160 during the boot process (or startup) of the electronic device 101. In one embodiment, the boot code 140 may be immutable, i.e., incorporated into the electronic device during manufacturing, and therefore can be implicitly trusted as it cannot be altered (e.g., hardware root of trust). The boot code 140 may include, but is not limited to, code that executes functions including functions F1(145a) and F2(145b). In one embodiment, function F1 may be boot code. In the same or different embodiments, function F2 may be part of a runtime application programming interface (API), e.g., a PUF engine 1955 (Figure 19). In one embodiment, the boot code 140 may be authenticated variable code that can function as a ROM extension (e.g., an FMC that can be authenticated by other boot code stored in ROM, and the FMC may be stored in volatile memory 172 or non-volatile memory 173). In one embodiment, the boot code 140 may include both immutable code (e.g., stored in ROM 130) and authenticated variable code that can function as a ROM extension.

[0030] Memory 170 may include any system, device, or apparatus capable of operating to hold program instructions or data for a period of time. Memory 170 may include any suitable selection or array of random access memory (RAM, SRAM, DRAM), EEPROM, PCMCIA card, flash memory (e.g., SPI flash), magnetic memory, magneto-optical memory, hardware registers, or 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] The I / O and port control unit 190 may include any system, device, or apparatus that is generally capable of receiving or transmitting data to / from / within the electronic device 101. The I / O and port control unit 190 may include, for example, any number of communication interfaces, graphics interfaces, video interfaces, user input interfaces, or peripheral interfaces (e.g., but not limited to JTAG, I2C, UART, Test Access Port). The I / O and port control unit 190 may be communicatively coupled to external ports / pins 180-1, 180-2, ... 180-N (and others not shown).

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

[0033] Figure 1 shows various components of the electronic device 101, but other exemplary systems may include electronic devices having more or fewer components. In one embodiment, the electronic device 101 according to this disclosure may not include one or all of the components shown in dashed lines without departing from the spirit and scope of these disclosed embodiments. In addition, the various components of the electronic device 101 may reside on the same die (e.g., primary die) or on separate dies. In one embodiment, the various components may reside inside a package within a multi-chip module (MCM) or outside a system board. In the same or different embodiments, the various components of the electronic device 101 may reside in one or more of the following locations: within the primary die, within the MCM, and outside the system board.

[0034] OTP memory Figure 2 shows a block diagram of an exemplary OTP memory 110 for managing ownership of an electronic device 101, including the secure transfer of ownership of the electronic device over time. As shown in Figure 2, the OTP memory 110 may contain multiple areas including the current RPMC value 202, a boot code generation random secret 203, a device-specific random secret 204, a serial number 205, a personalized 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 increments over time. In the embodiments shown in Table 1, the current RPMC value 202 may be a value stored in an 8-bit area in the OTP memory 110, which may correspond to nine different values ​​(0 to 8). In this embodiment, the bits in the OTP memory 110 for the current RPMC value 202 may be set sequentially 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 embodiments, values ​​smaller than the current RPMC value 202 may be considered canceled, and values ​​larger than the current RPMC value 202 may be considered unused. In the examples shown in Table 1, values ​​greater than 8 may not be used. In other embodiments where 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 smaller than the current RPMC value 202 can be considered canceled because, by definition, the OTP memory can only be programmed once, and therefore the OTP memory 110 cannot be programmed to a smaller value. For example, when the current RPMC value 202 has a value of 1, the least significant bit is programmed and cannot be unprogrammed to reset the current RPMC value 202 back to a value of 0.

[0036] Table 1 [Table 1]

[0037] The boot code generation random secret 203 can be any random information generated by the boot code 140 and accessible only to it. For example, the boot code generation random secret 203 may be a random number generated by the boot code 140 after the provisioning of the electronic device 101 is complete. The device-specific random secret 204 may be any random information specific to the electronic device 101. In one embodiment, the device-specific random secret 204 may 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 may be a random number generated by the boot code 140 after the 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 personalized string 206 may be a known string programmed into the OTP memory 110 during provisioning (e.g., by a tester). In an alternative embodiment, the personalized string 206 may be hardcoded into the boot code 140 instead of being stored in the OTP memory 110.

[0038] The secret device-specific information 207 may include (a) a device identity key ("DevIK") (e.g., the private key in a public-key-cryptographic key pair) or information that can generate a DevIK, (b) important device configurations, e.g., 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 secret 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), and the boot code 140 may use such UDS and ROM seed as source data to generate a DevIK or other device-specific information.

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

[0040] Figure 2 shows various regions of the OTP memory 110, but other exemplary systems may include electronic devices with more or fewer regions.

[0041] RPMC Owner Container Figure 3 shows a block diagram of an exemplary secure RPMC owner container 302 (owner container 302) for managing ownership of an electronic device 101, including through the 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 non-volatile memory (e.g., OTP memory 110, non-volatile memory 173) and may include configuration information of the current silicon owner and secrets that enable boot code 140 to load and execute an executable image of the owner (e.g., FMC in FMB). As shown in Figure 3, the owner container 302 may include three areas: a container header 310, container content 311, and container signature 312. In one embodiment, the owner container 302 may be a uniquely signed container of information modified, stored, and retrieved from OTP memory (e.g., OTP memory 110) or other non-volatile memory (e.g., non-volatile memory 173) by code that creates the container (e.g., boot code 140 or ROM extension (e.g., in authenticated FMC)). According to embodiments of this disclosure, the owner container 302 can 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 in Figure 7) to access or modify information within the owner container 302. In one embodiment, only immutable boot code (e.g., boot code 140) can access or modify information within 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 Signature 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 unreplicable function (PUF) or a deterministic random bit generator (DRBG) to generate the 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 having the following characteristics: • 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 can 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 for each owner per silicon die. According to one embodiment, the boot code 140 can derive an ECDSA private signing key using a DRBG and can provide the following inputs to the DRBG. • Personalized string: A known string, for example, "Container * one * It could also be called "Key Generator". Additional input: {RPMC value 431 | Device serial number 435} may also be used. • Entropy input: May be a device-specific random secret 204. • True Random Number Generator (TRNG) Input: Bootcode generation random secret 203 may also be used.

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

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

[0046] Figure 3 shows various areas of the owner container 302, but other exemplary systems may include electronic devices with more or fewer areas.

[0047] -Container headers Figure 4 shows a block diagram of an exemplary container header 310 for 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 Figure 4, the container header 310 may include areas 431-436 containing 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 protection monotonic counter that checks against the current RPMC value 202 in OTP memory 110 to determine whether this owner container is valid or revoked. In one embodiment, when the RPMC value 431 for owner container 302 is 3, the boot code 140 may determine that the owner container is valid if the current RPMC value 202 is also 3 (e.g., Figure 2). In the same or different embodiments, when the RPMC value 431 for owner container 302 is 3, the boot code 140 may determine that the owner container is revoked if the current RPMC value 202 is greater than 3 (e.g., Table 1 (Revoked RPMC Values)). In some embodiments, the RPMC value 431 may be used in checking primary and fallback containers.

[0049] The active container version 432 may represent the version number of the owner container 302. In one embodiment, the owner of the electronic device 101 may wish to update information within the owner container 302 (e.g., the area shown in Figure 6) in a way that does not require incrementing the RPMC value 431. Therefore, 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. Therefore, 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 the type associated with the owner container 302. In one embodiment, the container type 433 may have a value indicating that the container has not been initialized. In another embodiment, the container type 433 may have a value indicating that the owner container 302 has been 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, a unique serial number 205 in the OTP memory 110. The container command key hash blob 436 may contain hashes (e.g., SHA384 (Secure Hash Algorithm)) of one or more container command keys (CCKs) that may be the public keys of an encryption key pair. In the illustrated embodiment, the container command key hash blob 436 may contain hashes of the 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, the container command key hash blob436 may contain the public key instead of the hash of the public key. In this embodiment, more memory may be required.) In one embodiment, CCK0-3(437-440) may be canceled by setting the hash entries to 0. Figure 4 shows various areas of the container header 310, but other exemplary systems may include electronic devices with more or less area.

[0051] -Container Contents Owner container 302 may have different configurations depending on the configuration source, including the following: • 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] Figure 5 shows a block diagram of exemplary container content 311a of an owner container 302 for managing ownership of an electronic device 101. As shown in Figure 5, the container content 311a may be programmed in OTP memory 110 and may include several areas 501-515, including owner configuration 501, owner ID 502, owner RPMC 503, owner transfer authorization key (OTAK) 504, encrypted ECDH private key 505, ECDH public key hash 506, key hash blob (KHB) hash 507, TAGx image key revocation 508, TAGx image rollback protection 509, TAG0 base address pointer 510, TAG1 base address pointer 511, debug support 512, platform ID 513, security function 514, and PlatK hash 515. In one embodiment, some or all of the container content 311a may be programmed into OTP memory 110 during provisioning (e.g., by a tester). In the same or different embodiments, some or all of the container content 311a may be programmed into the OTP memory 110 by the boot code 140 after the 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 in Figure 7) to access or modify information within the container content 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 OTP memory (an OTP emulation configuration, which will be described more fully below).

[0054] The owner configuration 501 may include information about who can transfer ownership of the electronic device 101. In one embodiment, the current silicon owner may transfer ownership by executing an ownership transfer 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 an ownership transfer command signed by the owner's public CCK, and the new owner may transfer ownership by executing an ownership transfer 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) and may enable the new owner (or an authorized intermediate entity) to execute an ownership transfer command. The owner configuration 501 may include information indicating whether RPMC owner container crise commands are supported. In one embodiment, if crisis commands are enabled, the owner can use the I / O and port control unit 190 (e.g., I2C crisis port, UART crisis port) to insert owner container commands into command memory 171 (e.g., Figure 7). In one embodiment, owner container crisis commands may be disabled by default and may be enabled by the owner of the electronic device 101 (e.g., by programming the owner configuration 501).

[0055] The Owner ID 502 can be a value provided by the owner at the time of ownership transfer and can 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 Owner RPMC 503 may work together to indicate the unique owner of a particular electronic device 101. The Owner Transfer Authorization Key (OTAK) 504 may be a one-time ECDSA-384 public key (Elliptic Curve Digital Signature Algorithm) used to verify the ownership transfer command when, for example, the configuration information in the Owner Configuration 501 enables the new owner to execute the ownership transfer 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 can 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 can be used to derive an AES256 key encryption key (KEK) that can 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 the Diffie-Hellman key exchange protocol and used to decrypt the FMB image.

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

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

[0059] Figure 5 shows various regions of the container content 311a, but other exemplary systems may include electronic devices having more or fewer regions. In additional embodiments, specific regions of the container content 311a may include functions in addition to those described above, or some of those functions may be omitted.

[0060] Figure 6 shows a block diagram of exemplary container content 311b of an owner container 302 for managing ownership of an electronic device 101. As shown in Figure 6, the container content 311b may be programmed in non-volatile memory 173 and may include regions 501-515 that are described in relation to Figure 5 and differ in that they are stored in non-volatile memory 173 rather than in OTP memory 110. In one embodiment, an owner container 302 having container content 311b stored in non-volatile memory 173 can emulate an owner container stored in OTP memory 110 (OTP emulation) because the boot code 140 can store configuration parameters (e.g., in the container content 311b) when creating the owner container, and there are no commands for the boot code 140 (or other code) to modify those parameters. If a malicious user attempts to modify the secure RPMC owner container 302 while it is stored in non-volatile memory 173 (for example, to change one of the OTP emulate parameters), the container validation will fail. Therefore, the configuration parameters in the owner container 302 stored in non-volatile memory 173 can be considered to emulate OTP memory.

[0061] In one embodiment, the container content 311b may contain PUF boot code 621 (for example, “PUF” refers to a physically non-replicable function, which is described in more detail below). The boot code 140 can use the PUF boot code 621 to generate a device attestation key (DevAK) and pass it to the silicon owner's firmware. In one embodiment, during the first power-on reset cycle after the owner container content 311b is created or updated, the boot code 140 can generate the PUF boot code 621 using a shared SRAM PUF and store it in the owner container content 311b. During the subsequent boot process, if the boot code 140 loads an authentic image (e.g., FMB), the boot code 140 can use the PUF boot code 621 to generate the DevAK private and public keys. In one embodiment, boot code 140 can place the DevAK public key within an X.509 certificate and sign the certificate using the DevIK private key (e.g., the secret device-specific information 207 in Figure 2). In this embodiment, the signed certificate can be passed to the owner's firmware (e.g., via the firmware mailbox 788 in Figure 7) along with the PUF boot code 621. The owner's firmware can then use the PUF boot code 621 to regenerate the DevAK private key.

[0062] Examples of adding PUF activation code 621, SRAM PUF, DevAK key and DevIK key, and device certificate are provided in Figures 16 to 30 and related descriptions (in the section "Physically Unreplicable Function (PUF) SRAM" below).

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

[0064] Figure 6 shows various regions of the container content 311b, but other exemplary systems may include electronic devices having more or fewer regions. In additional embodiments, specific regions of the container content 311b may include functions in addition to those described above, or may omit some of those functions.

[0065] Command Interface Figure 7 shows an exemplary command memory 171. The command memory 171 may include rewritable 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, the boot code 140 can authenticate the FMB from non-volatile memory 173 (e.g., SPI flash), optionally decrypt it, and then load the FMC into internal volatile memory 172 (e.g., SRAM) for subsequent execution by the processor 160. For example, the boot code can 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 containing 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 is sometimes referred to as the “owner” image. The boot code can then trigger execution of the FMC by the processor 160 (e.g., by jumping to the base address of the FMC). The FMC can be either a ROM extension (e.g., an authenticated ROM extension within the FMC) or application firmware. The owner application can communicate with boot code 140 or ROM_EXT to request a transfer of ownership or, instead, perform some other action. The application can communicate this action by loading a signed command into boot code mailbox 784, setting the relevant command bits within RPMC container command 782, and triggering a reset (e.g., a soft reset).

[0066] In the above embodiment, the RPMC container command 782 and the boot code mailbox 784 may be used to initiate RPMC container requests to be processed by the boot code 140. (The firmware mailbox 786 may be used by the boot code 140 (or ROM_EXT) to pass information to the application firmware.) In one embodiment, the command memory 171 may be user-accessible so that code other than the boot code 140 (e.g., FMC) can initiate requests to be processed by the boot code 140. In another embodiment, the command memory 171 may be accessed via external hardware (among other things, a UART interface, an I2C interface) to perform crisis recovery, for example (if the owner configuration 501 in the 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, indicates 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 specific 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 (for example, 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 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, the 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 the processor 160. In another embodiment, the boot code 140 may authenticate a signed command received as a crisis recovery command from an I / O and port control unit 190 (e.g., I2C, UART) and load it into internal volatile memory 172 (e.g., SRAM) for execution by the processor 160.

[0070] -CREATE_CONTAINER_REQUEST command This signed command may be called to cause boot code 140 to create and program a first signed owner container 302 in non-volatile memory 173 (e.g., SPI flash). 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, boot code 140 may program a bit in OTP memory 110 (e.g., RPMC flash container state 208) indicating that the container has been created, and then check that OTP bit before executing the CREATE_CONTAINER_REQUEST command. If the OTP bit is programmed, boot code 140 may ignore the subsequent CREATE_CONTAINER_REQUEST command.

[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 the boot code 140 verifies that both signed containers have been successfully stored in non-volatile memory 173, it sets an OTP bit to indicate that the containers have been 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 may include an owner creation public key (OCKpub), a command signature signed with an owner creation private key (OCKpriv), and other command parameters corresponding to areas 433-434 and 437-440 in Figure 4 (container header 310) and areas 501-502 and 505-515 in Figure 6 (container content 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 with the OCKpub hash retrieved from the KHB stored in non-volatile memory 173. (The KHB stored in the non-volatile memory 173 may be verified against the KHB hash 507 in the OTP memory 110.) If verification of either OCKpub or command signature fails, the boot code 140 may stop executing the CREATE_CONTAINER_REQUEST command without creating the first owner container 302. In one embodiment, the boot code 140 may store the unsuccessful command status in the firmware mailbox 786.

[0073] If verification is successful, boot code 140 can create a signed owner container 302. In one embodiment, boot code 140 can store the successful command status in firmware mailbox 786. In one embodiment, boot code 140 can store the corresponding command parameters (in boot code mailbox 784) in the corresponding areas within container header 310 (areas 433-434 and 437-440 in Figure 4) and container content 311b (areas 501-502 and 505-515 in Figure 5). Boot code 140 can use the following for the new signed owner container 302: • RPMC value 431 (and owner RPMC 503): Can be 0 by default (as this is the first owner container). Boot code 140 checks if any of the bits of the current RPMC value 202 in OTP memory are set, and if so, can set them to the first valid non-zero value. • Active container version 432: This can be 0 by default. Device serial number 435: Can be set to the value stored in OTP serial number 205. • Ownership transfer permission key 504: Can be 0 by default. • PUF boot code 621: When processing the CREATE_CONTAINER_REQUEST command, it can default to 0. Boot code 140 can generate PUF boot code 621 following the next power cycle and store it in the signed owner container 302.

[0074] -INCREMENT_RPMC_REQUEST command This signed command may be invoked by boot code 140 to increment the RPMC value 431 of the primary owner container 302 (without changing the contents of other containers). If permitted, boot code 140 may retrieve the primary owner container 302, increment the RPMC value 431, and reset the active container version 432 back to 0. Boot code 140 may 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 have been successfully updated, boot code may increment the current RPMC value 202 in OTP memory 110, which can undo 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 may include a container commands public key (CCKpub), an indication of which of CCK0 to CCK3 (hashes in area 436 of the current owner container header 310) CCKpub corresponds to, and a command signature signed with a container commands private key (CCKpriv). Before incrementing the RPMC value 431, boot code 140 may 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 to CCK3) stored in the current owner container header 310. (Since the owner container 302 can be verified by boot code 140, the information in the current owner container header 310 can be trusted.) If verification of either CCKpub or command signature fails, boot code 140 can stop executing the INCREMENT_RPMC_REQUEST command without incrementing the RPMC value 431. In one embodiment, boot code 140 can store the unsuccessful command status in the firmware mailbox 786.

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

[0077] -UPDATE_CONTAINER_REQUEST command This signed command may be invoked to cause boot code 140 to update the selected container and increment the current RPMC value 202 in OTP memory 110. In one embodiment, the specific update to be performed may be determined by subcommand parameters of the command parameters stored in boot code mailbox 784 for the UPDATE_CONTAINER_REQUEST command. In one embodiment, the subcommand may include (1) "key revocation and rollback protection" and (2) "transfer of ownership".

[0078] In one embodiment, boot code 140 can use command parameters stored in boot code mailbox 784 for the UPDATE_CONTAINER_REQUEST command. The command parameters may include a signing public key (CCKpub or OTAKpub), an instruction to use either OTAKpub or CCK0-CCK3 for verification (a hash in area 436 of the current owner container header 310), and a command signature signed with the private key OTAKpriv or CCKpriv. Before updating the owner container 302, boot code 140 can verify the command signature using OTAKpub or CCKpub (whichever is indicated for use). In one embodiment, boot code 140 can verify the command parameter CCKpub by calculating its hash and comparing it to the corresponding CCKpub hashes (CCK0-CCK3) stored in the current owner container header 310. (Since 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 the command parameter OTAKpub by comparing it with the owner transfer permission key 504 stored in the current owner container content 311b. If verification of (1) the selected OTAKpub key or CCKpub key, or (2) the command signature fails, the boot code 140 can stop the 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 the unsuccessful command status in the firmware mailbox 786.

[0079] (1) If both the selected OTAKpub or CCKpub key and the command signature are verified successfully, and (2) the subcommand is "Transfer Ownership", the boot code 140 can update the signed owner container 302. In one embodiment, the boot code 140 can store the command parameters (for example, in the boot code mailbox 784) corresponding to areas 433-434 and 437-440 in Figure 4 (container header 310) and areas 501-502 and 505-515 in Figure 6 (container content 311b) in the corresponding areas in the container header 310 and container content 311b of the updated signed owner container 302. The boot code 140 can use the following defaults for the updated signed owner container 302. • RPMC value 431 (and owner RPMC 503): Can use {current RPMC value 202 + 1} • Active container version 432: This can be 0 by default. Device serial number 435: Can be set to the value stored in OTP serial number 205. • Ownership transfer permission key 504: Can be 0 by default. • PUF boot code 621: When processing the CREATE_CONTAINER_REQUEST command, it can default to 0. Boot code 140 can generate PUF boot code 621 following the next power cycle and store it in the signed owner container 302.

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

[0081] (1) If both the selected OTAKpub key or CCKpub key and the command signature are verified successfully, and (2) the subcommand is "Key revocation and rollback protection", 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 TAGx image rollback protection 509 in the container content 311b of the signed owner container 302. In one embodiment, the boot code 140 can store the successful command status in the firmware mailbox 786.

[0082] -REPAIR_FALLBACK_CONTAINER_REQUEST command This signed command may be invoked to cause boot code 140 to 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, boot code 140 may erase the fallback container and copy the primary container to the fallback container location. In one embodiment, boot code 140 may use command parameters stored in the boot code mailbox 784 for the REPAIR_FALLBACK_CONTAINER_REQUEST command. The command parameters may include a signing public key (CCKpub or OTAKpub), an instruction to use either OTAKpub or CCK0-CCK3 for verification (a hash in area 436 of the current owner container header 310), and a command signature signed with the private key OTAKpriv or CCKpriv. The boot code may use the same mechanism disclosed with respect to UPDATE_CONTAINER_REQUEST (above) to verify the signing public key and command signature for the REPAIR_FALLBACK_CONTAINER_REQUEST command. In one embodiment, if verification is successful and no errors are detected when updating the fallback container, the 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 the boot code 140 may store the successful command status in the firmware mailbox 786. If verification fails or an error is detected, there may be no change (e.g., the primary container remains valid in non-volatile memory 173 and the fallback container remains invalid). In this latter embodiment, the boot code 140 may store the unsuccessful command status in the firmware mailbox 786.

[0083] -RISK_RECOVERY_REQUEST command This signed command may be invoked to recover boot code 140 from the point when the primary and fallback containers are disabled. In one embodiment, this command may be served when both containers are disabled. Boot code 140 may allow the owner to restore a saved copy of the working owner container using a crisis command (e.g., RESTORE_OWNER_CONTAINER) issued via the I / O and port control unit 190 (e.g., I2C crisis port, UART crisis port).

[0084] -ENABLE_UNRESTRICTED_TRANSFERS command This signed command may be invoked to cause boot code 140 to perform the following update on owner container 302. The owner configuration 501 (Figure 5) is updated so that both the current silicon owner and the new owner can transfer ownership of the electronic device 101. Provision the ownership transfer permission key 504. • Increment the active container version to 432 (Figure 4). • Re-sign the owner of container 302.

[0085] In one embodiment, boot code 140 can use command parameters stored in boot code mailbox 784 for the ENABLE_UNRESTRICTED_TRANSFERS command. The command parameters may include an OTAKpub public key (for example, to provision the owner transfer permission key 504), a signing public key (CCKpub), an instruction indicating which of CCK0~CCK3 (hashes in area 436 of the current owner container header 310) the CCKpub corresponds to, and a command signature signed using a container command private key (CCKpriv). Boot code 140 can verify the command signature using the CCKpub before updating the owner container 302. In one embodiment, boot code 140 can verify the command parameter CCKpub by calculating its hash and comparing it to the corresponding CCKpub hashes (CCK0~CCK3) stored in the current owner container header 310. (Since the owner container 302 can be verified by the boot code 140, the information in the current owner container header 310 can be trusted.) If verification of either the CCKpub or the command signature fails, the boot code 140 can stop the execution of 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 an update to the owner container 302 as described above (for example, by updating both copies of the container in non-volatile memory (e.g., SPI flash)). In one embodiment, the boot code 140 may store the successful command status in the firmware mailbox 786.

[0087] -UPDATE_OTAK_KEY command This signed command may be invoked to cause boot code 140 to perform the following update on owner container 302. Provision the ownership transfer permission key 504. • Increment the active container version to 432 (Figure 4). • Re-sign the owner of container 302.

[0088] This signed command may allow an intermediate entity possessing the OTAKpriv private key to trigger the above 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 transfer is not enabled).

[0089] In one embodiment, boot code 140 can use command parameters stored in boot code mailbox 784 for the UPDATE_OTAK_KEY command. The command parameters may include a new OTAKpub_new public key (e.g., for provisioning the owner transfer permission key 504), a signing public key (CCKpub or OTAKpub), an instruction to use either OTAKpub or CCK0-CCK3 for verification (a hash in area 436 of the current owner container header 310), and a command signature signed with the private key OTAKpriv or CCKpriv. Before updating the owner container 302, boot code 140 can verify the command signature using OTAKpub or CCKpub (whichever is indicated for use). In one embodiment, boot code 140 can verify the command parameter CCKpub by calculating its hash and comparing it to the corresponding CCKpub hashes (CCK0-CCK3) stored in the current owner container header 310. (Since 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 the command parameter OTAKpub by comparing it with the owner transfer permission key 504 stored in the current owner container content 311b. If verification of (1) the selected OTAKpub key or CCKpub key, or (2) the command signature fails, the boot code 140 can stop the execution of the UPDATE_OTAK_KEY command without modifying the current owner container 302. In one embodiment, the boot code 140 can store the unsuccessful command status in the firmware mailbox 786.

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

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

[0092] Establishment of ownership During manufacturing, the OTP memory 110 may be provisioned with OEM image configuration parameters that may include a KHB hash 507 used to authenticate the OEM image stored in the non-volatile memory 173 (e.g., SPI flash). Other parameters in the OTP memory 110 (e.g., shown in Figures 2 and 5) may also be provisioned by the OEM during manufacturing. This configuration is sometimes referred to as the “Legacy Secure Boot” state. In this state, only signed OEM images (e.g., FMB) can be authenticated and executed on the electronic device 101.

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

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

[0095] Figure 8 shows a block diagram of one embodiment of ownership management for electronic device 101, which includes 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 the OTP TAG0 / 1 image header base address, OTP KHB (primary and fallback), and the OTP TAG0 / 1 image header and image (e.g., FMB). At time t0, there may be no owner for electronic device 101, but the OEM may be the implicit owner. In one embodiment, at time t1, the OEM application code can write the owner container 0 / 1 (primary container and fallback container) base address to non-volatile memory 873. At time t2, the OEM application code can store the CREATE_CONTAINER_REQUEST command in the RPMC container command area in command memory 871 and the container parameters for the new owner (owner A) in the boot code mailbox in command memory 871. In one embodiment, the parameter corresponding to the owner configuration parameter 501 can specify the OTP configuration for owner A. At time t3, the OEM application code may cause a soft system reset of the electronic device 101. During the boot process, the 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, the boot code 140 may write owner A containers 0 / 1 (primary container and fallback container) to non-volatile memory 873. As shown in the figure, after time t4, the electronic device 101 may be owned by owner A using the OTP image. In one embodiment, following time t4, the OEM application may read the command status bits from the firmware mailbox 786 (Figure 7) to verify the successful completion of the command. The OEM application may optionally read owner A containers 0 / 1 from non-volatile memory 873 and verify their contents.In one embodiment, the OEM application may optionally save a copy of owner A container 0 / 1 as a backup.

[0096] Figure 9 shows a block diagram of one embodiment of ownership management for electronic device 101, which includes 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 the 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 implicit owner. In one embodiment, at time t1, the OEM application code may write (1) the owner container 0 / 1 base address, (2) the owner A KHB (primary and fallback), and (3) the owner A TAG0 / 1 image+ header (e.g., FMB) to non-volatile memory 973. At time t2, the OEM application code can store the CREATE_CONTAINER_REQUEST command in the RPMC container command area in command memory 971 and store the container parameters for the new owner (owner A) in the boot code mailbox in command memory 971. In one embodiment, the parameter corresponding to owner configuration parameter 501 can specify the OTP emulation configuration for owner A. At time t3, the OEM application code can trigger a soft system reset of the electronic device 101. During the boot process, the boot code 140 can notice the pending CREATE_CONTAINER_REQUEST command and process it. At time t4, if the command is successful, the boot code 140 can write owner A containers 0 / 1 (primary container and fallback container) to non-volatile memory 973 and begin execution of the owner A image (e.g., TAG0 image). As shown in the figure, after time t4, the electronic device 101 may 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 (Figure 7) to verify the successful completion of the command.Owner A application can optionally read Owner A container 0 / 1 from non-volatile memory 973 and verify its contents. In one embodiment, Owner A application can optionally save a copy of Owner A container 0 / 1 as a backup.

[0097] Boot sequence of an electronic device with an RPMC owner container Figure 10 shows a flowchart of an exemplary method 1000 for managing ownership of an electronic device, including the secure transfer of ownership of the electronic device over time. According to one embodiment, method 1000 may begin from block 1005. In one embodiment, method 1000 may be executed by boot code 140. In some embodiments, the starting block 1005 may represent the time when the 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 1000 may be executed by boot code 140 at a time when the OTP memory 110 is not accessible to the user (e.g., because user code has not yet been loaded). The teachings of this disclosure can be executed in various configurations of system 100. Therefore, the initialization point of method 1000 and the order of blocks 1005-1045 that constitute method 1000 may depend on the chosen execution.

[0098] Following a POR or soft reset, the boot code may proceed to block 1010 to determine whether the OTP memory has been fully provisioned. If not, the boot code may proceed to block 1015 to provision the OEM configuration to the electronic device 101, 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 to determine whether the owner function is enabled in the OTP memory 110. In one embodiment, this function may be disabled by default (i.e., at manufacturing). If the owner function is not enabled, the boot code may proceed to block 1040, where it can load the firmware binary image using the OEM information stored in the OTP memory 110. In block 1040, only OEM-signed firmware can be loaded and executed (which may also be called "legacy secure boot"), so the OEM may be the implicit owner of the electronic device 101. In one embodiment, the OEM firmware can enable the owner function by issuing a CREATE_CONTAINER_REQUEST command (for example, as shown in Figures 8 and 9). If the boot code determines in block 1025 that the owner function is enabled in the OTP memory 110, it may proceed to block 1035 to determine whether the FMB image configuration source is an OTP emulation. If the FMB image configuration source is not OTP emulation, the image configuration source may be OTP memory. In this embodiment, 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 the firmware using RPMC owner container information stored in non-volatile memory 173 (e.g., SPI flash). In one embodiment, block 1045 may represent a secure boot process using the RPMC owner container stored in non-volatile memory 173.

[0100] Figure 10 discloses a specific number of operations related to Method 1000, but Method 1000 may be performed with more or fewer operations than those shown in Figure 10. In addition, Figure 10 discloses a specific order of operations performed with respect to Method 1000, but the operations constituting Method 1000 may be completed in any preferred order.

[0101] Transfer of ownership of electronic devices In one embodiment, the OEM may be the first silicon owner (e.g., the owner of electronic device 101). However, the owner may change more than once throughout the lifespan of the electronic device. The owner is the entity that can determine the key used to authenticate the FMB image. A transfer of ownership may be an act that changes the entity responsible for determining the FMB signing key.

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

[0103] In some cases, the following three types of ownership transfers may exist: The current owner performs the transfer to the new owner. • A trusted intermediate entity performs the transfer to the new owner (unrestricted transfer). • Allows the current owner to allow the new owner to claim ownership (unrestricted transfer).

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

[0105] An Ownership Transfer Authorization Key (OTAK) can support a one-time transfer of ownership to a new owner while avoiding providing the current owner with the new owner's information. Using OTAK transfer (which may be referred to as “unrestricted transfer”), as long as the current owner has enabled OTAK transfer, the new owner can upload their information and complete the ownership transfer. OTAK ownership transfer can be completed whether or not a new owner exists when the current owner relinquishes the machine.

[0106] Figures 11 and 12 show block diagrams of two embodiments for managing ownership of electronic device 101 using unrestricted transfer and OTAK. As shown in Figure 11, the 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 and 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 TIE and NO (if NO is known). TIE and NO can use the serial number to verify that they receive the correct equipment (e.g., machine A). 2-TIE can send the OTAKpub1 key to 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 the new OTAK public key for machine A. 4-CO can send machine A to TIE. 5-NO can send the OTAKpub2 key to TIE. The OTAKpub2 key can be the public key of a public / private key pair owned by NO. 6-TIE may execute the UPDATE_OTAK_KEY command and pass the OTAKpub2 key as the new OTAK public key for machine A. Since UPDATE_OTAK_KEY is a signed command, TIE can sign the command with TIE's OTAKpriv1 private key. TIE can use the I / O and port control unit 190 (e.g., I2C port, UART port) to insert the UPDATE_OTAK_KEY command into command memory 171 (e.g., Figure 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 the I / O and port control unit 190 (e.g., I2C port, UART port) to insert the UPDATE_CONTAINER_REQUEST command into command memory 171 (e.g., Figure 7).

[0107] Figure 11 discloses a specific number of events related to an unlimited transfer of ownership, but this type of transfer may be performed with more or fewer events than those shown in Figure 11. For example, the CO does not have to send the serial number to either or both of the TIE and NO. In addition, Figure 11 discloses a specific order of events, but the events may be completed in any suitable order.

[0108] As shown in Figure 12, the 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 facilitate 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 confirm that they have received the correct equipment (e.g., machine B). 2-NO can send the OTAKpub3 key to CO. The OTAKpub3 key can be the public key of a public / private key pair owned by NO. 3-CO can execute the ENABLE_UNRESTRICTED_TRANSFERS command and pass the OTAKpub3 key as the new OTAK public key for machine B. 4-CO can send machine B to UIE. Note that since UIE does not have access to OTAKpriv3, UIE may not assume ownership or may not execute commands on machine B. 5-UIE can transfer machine B to NO (in its original state). 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 the I / O and port control unit 190 (e.g., I2C port, UART port) to insert the UPDATE_CONTAINER_REQUEST command into command memory 171 (e.g., Figure 7).

[0109] Figure 12 discloses a specific number of events related to an unlimited transfer of ownership, but this type of transfer may be performed with more or fewer events than those shown in Figure 12. For example, the CO does not have to send the serial number to the NO. In another embodiment, the CO can send machine B directly to the NO without requiring an intermediate entity. In addition, Figure 12 discloses a specific order of events, but the events may be completed in any suitable order.

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

[0111] In one embodiment, there are six possible scenarios for transferring ownership of the electronic device 101. • Direct transfer of ownership using the current owner's CCK key and FMB configuration = OTP (Figure 13). • Direct ownership transfer using the current owner's CCK key and FMB configuration = OTP emulation. • Direct ownership transfer using the new owner's OTAK key and FMB configuration=OTP. Direct ownership transfer using the new owner's OTAK key and FMB configuration = OTP emulation. • Indirect ownership transfer using an intermediate entity, OTAK key, and FMB configuration = OTP. • Indirect ownership transfer using an intermediate entity, OTAK key, and FMB configuration = OTP emulation.

[0112] In an embodiment where the ownership transfer command is successful, the new owner can load and execute code via the I / O and port control unit 190 (e.g., critical port). This loaded code can then be used to update the SPI flash image.

[0113] Transfer procedure using CCK key Figure 13 shows a block diagram of one 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 the 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 can provide its owner configuration parameters to the current owner, who can then use the current owner's CCK key (e.g., using an external hardware security module) to sign the UPDATE_CONTAINER_REQUEST ("Transfer Ownership" subcommand) command parameters for the new owner. In one embodiment, the signed parameters can then be used by either the new owner or the current owner to perform the transfer of ownership. At time t1, a soft system reset of electronic device 101 may cause electronic device 101 to enter crisis recovery mode. At time t2, either the new or 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, boot code 140 may write owner B containers 0 / 1 (primary container and fallback container) to non-volatile memory 1373. As shown in the figure, after time t3, electronic device 101 may be owned by owner B using the OEM OTP image.

[0114] Figure 13 illustrates the transfer of ownership using the current owner's CCK key and FMB configuration=OTP. This process may be similar in the case of FMB configuration=OTP emulation. In the case of OTP emulation, after issuing UPDATE_CONTAINER_REQUEST, the owner can use the critical port to load the new owner's loader code image and KHB into volatile memory 172 (e.g., SRAM (Figure 1)). If the load is successful (t3), the boot code 140 may write owner B container 0 / 1 (primary container and fallback container) to non-volatile memory 1373 and jump into the new owner's loader code. The new owner's loader code can then write the signed image and KHB (primary and fallback) to non-volatile memory 1373 (e.g., SPI flash).

[0115] Therefore, a general procedure for transferring ownership using a CCK key may include the following: • The new owner can provide the current owner with their own owner configuration parameters. • 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 own image and KHB (if applicable). • Electronic devices may be powered off and physically transferred to a new owner or 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 critical port to load the new owner's loader code image and KHB, and the loader code image and KHB write the signed image and KHB (primary and fallback) to non-volatile memory.

[0116] Transfer procedure using OTAK key An example of transferring ownership using an OTAK key was discussed above with reference to Figures 11 and 12. A general procedure for transferring ownership using an OTAK key may include the following: • A new owner or trusted intermediate entity can generate a public / private ECDSA-384 key pair. • Public ECDSA keys can be transferred offline to the current owner via a trusted channel. The current owner can store this public key value in the OTAK key within the owner container and enable unrestricted ownership transfer using the ENABLE_UNRESTRICTED_TRANSFERS command. • (Optional) The current owner can write the new owner image and KHB to the flash memory. • (Optional) The current owner can delete their own image and KHB. The machine can be powered off and physically transferred to a new owner or trusted entity. • (Optional) If using a trusted intermediate entity, execute the UPDATE_OTAK_KEY command or the UPDATE_CONTAINER_REQUEST command (with the "Transfer Ownership" subcommand) using the intermediate entity's OTAK key (via the crisis port). The new owner can execute the UPDATE_CONTAINER_REQUEST command (which has the "Transfer Ownership" subcommand) (via the crisis port). • (For OTP emulation) The new owner can use the critical port to load the new owner's loader code image and KHB, and the loader code image and KHB write the signed image and KHB (primary and fallback) to non-volatile memory.

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

[0118] Identifying the location of the owner's container In one embodiment, boot code 140 may, by default, be allocated to the first 16 bytes in the SPI Flash memory of component 0 (e.g., the first flash memory component accessed during the boot sequence) in the boot ROM address pointer table. This 16-byte address pointer table may be relocatable. The table may be used to locate the owner image and may be restorable in OTP memory. The locations 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 values ​​in OTP memory and owner container In one embodiment, the current RPMC value 202 in 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 OTP memory 110 may be incremented to match the updated RPMC value 431 in the container header 310.

[0120] Method of transferring ownership Figure 14 shows a flowchart of an exemplary method 1400 for managing ownership of electronic devices, including the secure transfer of ownership of electronic devices over time. According to one embodiment, method 1400 may begin from block 1410. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 1400 and the order of blocks 1410-1430 that constitute method 1400 may depend on the chosen execution.

[0121] In block 1410, for an electronic device having one-time programmable (OTP) memory and non-volatile memory, method 1400 can authenticate a code associated with the implicit owner of the electronic device using information stored in the OTP memory. In block 1415, method 1400 can receive a request to create a first owner container from the authentication code associated with the implicit owner of the electronic device. In block 1420, method 1400 can create a first owner container in response to the request to create a first owner container, the first owner container containing a first signed data image associated with the first owner of the electronic device. In block 1425, method 1400 can store the first owner container in non-volatile memory. In block 1430, 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, method 1400 can authenticate a first executable code associated with a first owner of an electronic device using configuration information and secret information from a signed data image associated with the first owner of the electronic device.

[0122] Figure 14 discloses a specific number of operations related to Method 1400, but Method 1400 may be performed with more or fewer operations than those shown 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 shown in Figure 15. In addition, Figure 14 discloses a specific order of operations performed with respect to Method 1400, but the operations constituting Method 1400 may be completed in any preferred order.

[0123] Figure 15 shows a flowchart of an exemplary method 1500 for managing ownership of electronic devices, including the secure transfer of ownership of electronic devices over time. According to one embodiment, method 1500 may begin from block 1510. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 1500 and the order of blocks 1510-1555 that constitute method 1500 may depend on the chosen execution.

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

[0125] Figure 15 discloses a specific number of operations related to Method 1500, but Method 1500 may be performed with more or fewer operations than those shown in Figure 15. In addition, Figure 15 discloses a specific order of operations performed with respect to Method 1500, but the operations constituting Method 1500 may be completed in any preferred order.

[0126] Methods 1000, 1400, and 1500 may be performed using System 100, or any other system capable of performing Methods 1000, 1400, and 1500. While embodiments have been described above, other variations and embodiments may be derived from this disclosure without departing from the spirit and scope of these disclosed embodiments.

[0127] Physically Unreplicable Function (PUF) SRAM Some embodiments of this disclosure may use a SRAM physically non-replicable function (PUF) to generate a device proof key (DevAK) from boot code 130 and pass it to a first variable code (FMC) without exposing a secret key or SRAM PUF keying material. Unlike devices that use OTP memory for DevAK keys, SRAM PUFs may enable the generation of unique device keys for specific applications without exposing a secret key. In embodiments, keys derived from SRAM PUFs 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 therefore, when the SRAM is not powered, the key does not exist on the chip. For example, a SRAM PUF may be used to generate a device identification key (DevIK) so that it does not need to be stored in OTP memory 110 (e.g., the DevIK may not be stored in secret device-specific information 207 (Figure 2)). In the same or different embodiments, when the SRAM is powered, the SRAM memory may be “secret” so that it is not directly accessible by the FMC (for example, as a result of read / write locking, as described in the following paragraph).

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

[0129] In some embodiments, the boot code 140 (e.g., immutable boot code or authenticated variable boot code) may include SRAM PUF functions to support, for example, anti-aging, error correction, randomness extraction, privacy amplification, and security countermeasures techniques. The SRAM PUF functions may be incorporated into the SRAM PUF API. In some embodiments, one or more 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 SRAM PUF functions to generate a uniform random key may be referred to as "registering" the SRAM PUF. In some embodiments, the SRAM PUF may be registered in a first power cycle. This may result in the generation of a PUF activation code 621 (Figure 6) which can be stored in the container content 311b of the owner container 302 (Figure 3). In one embodiment, SRAM PUF registration may be based on the current silicon owner (e.g., owner ID 502, owner RPMC 503, or other value unique to the current silicon owner) such that the uniform random key is unique to the current silicon owner. The SRAM PUF function can then use the PUF activation code 621 to regenerate the same random key generated during registration (e.g., following a second power cycle). The PUF activation code 621 does not have to be secret, but its integrity may be maintained (e.g., as an OTP emulated parameter, as described with respect to Figure 6).

[0130] Figure 17 shows a flowchart of an exemplary method 1700 for SRAM PUF registration and subsequent key reconstruction. According to one embodiment, method 1700 may begin from block 1705. In one embodiment, method 1700 may be executed by boot code 140. For simplicity, the inventors may use the term boot code 140 as to execute a function, meaning that boot code 140 is read by processor 160 and causes processor 160 to execute an associated function. In some embodiments, the starting 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., device reset, reboot, or power cycle). Thus, method 1700 may be executed by boot code 140 when the FMC cannot access the volatile memory 172 (e.g., SRAM having ROM_PUF and SHD_PUF areas) (e.g., because the FMC has not yet been authenticated and loaded). The teachings of this disclosure can be performed in various configurations of System 100. Therefore, the initialization point of Method 1700 and the order of Steps 1705-1745 that constitute Method 1700 may depend on the selected execution.

[0131] Following a POR (Power On Reset) or soft reset, the boot code 140 may proceed to block 1710, which 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 the determination that this is the first power cycle or reset cycle after a change of 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., 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 can 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, where the SRAM PUF is registered. In one embodiment, registration may include creating (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, using a unique SRAM PUF silicon fingerprint. In one embodiment, registration may be based on the current silicon owner such that the uniform random key is unique to the current silicon owner (e.g., based on owner ID 502, owner RPMC 503, or other value unique to the current owner). In one embodiment, boot code 140 may perform these tasks using the SRAM PUF API (e.g., SRAM PUF functions) such that the secret cryptographic key cannot be extracted by other boot code or FMC (e.g., the secret key can only be known to the SRAM PUF API).

[0132] The boot code 140 may then proceed to block 1725, where the PUF boot code (for example, as PUF boot code 621) may be stored in the secure RPMC owner container 302 corresponding 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 each different owner of the electronic device 101 with a unique PUF activation code 621. For example, the DevAKpriv key may be generated as a function of the current owner of the electronic device 101. This can then provide each different owner with a unique (and random) cryptographic context (e.g., a unique DevAK key). In the embodiment, the unique PUF activation code 621 may be generated as a function of the current owner by the boot code in the first power cycle after the transfer of ownership of the electronic device 101. In subsequent power cycles, the stored PUF activation code 621 may be used by the SRAM PUF API function 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. Therefore, a subsequent owner cannot devise the previous owner's cryptographic context or discover the previous owner's secrets.

[0134] After boot code 140 stores the PUF boot code in the secure RPMC owner container in block 1725, boot code 140 can proceed to block 1730, where it can store the key code generated in block 1720 in the firmware mailbox 786 (Figure 7). Next, boot code 140 can proceed to block 1740, where it can set the firmware mailbox 786 status. In one embodiment, this status may be information stored in the firmware mailbox 786, such as register bits, or it may indicate whether other information in the firmware mailbox 786 (e.g., DevAK key code 1922 in Figure 19) is valid. In an embodiment following registration after POR, boot code 140 can set the status to indicate that the key code stored in block 1730 is valid. Next, boot code 140 may proceed to block 1745, where boot code may authenticate the FMC (e.g., firmware) and load it into SRAM (e.g., this may be done by processor 160). In one embodiment, the FMC can then be executed within the cryptographic context established by the registration process and can access the key code stored in the firmware mailbox 786. Exemplary use of the key code is described in relation to Figures 18 to 30 below.

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

[0136] If boot code 140 determines in block 1710 that the SRAM PUF is registered, boot code 140 may proceed to block 1735, where it can initiate a known cryptographic context using the PUF activation code 621 and the SRAM PUF-specific 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. Next, boot code 140 may proceed to block 1730, where it may store the key code generated in block 1735 in the firmware mailbox 786 (Figure 7). Boot code 140 may proceed to block 1740, where it may set the firmware mailbox 786 status to indicate that the key code (e.g., DevAK key code 1922 in Figure 19) is valid. Boot code 140 may proceed to block 1745, where the boot code may authenticate the FMC (e.g., firmware) and load it into SRAM (e.g., this may be done by processor 160). The FMC can then be executed in the cryptographic context established by boot code 140 (i.e., corresponding to PUF activation code 621 - the same cryptographic context established by the registration process for the current owner of electronic device 101) and can access the key code stored in the firmware mailbox 786. Exemplary use of the key code is described below in relation to Figures 18 to 30.

[0137] Figure 17 discloses a certain number of operations related to method 1700, but method 1700 may be performed with more or fewer operations than those shown in Figure 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 (Figure 3). Signing the owner container at this time ensures that the PUF boot code 621 can only be modified by boot code 140 so that its integrity can be maintained. In another embodiment, before block 1745, boot code 140 may set a read / write lock on SRAM 172 (Figure 16) so that application code (e.g., FMC) may have access to portion 1608 of the SHD_PUF area 1606 / 1608, but may not have access to portion 1606 of the SHD_PUF area 1606 / 1608. In some embodiments, boot code 140 may set a read / write lock on the SHD_PUF area 1606 at every exit event so that no user code (e.g., FMC) can access the secret SRAM PUF keying material. In addition, Figure 17 discloses a specific sequence of operations performed with respect to method 1700, although the operations constituting method 1700 may be completed in any preferred order.

[0138] Figure 18 shows an exemplary electronic device 1801 capable of responding to the Secure Protocol Data Model (SPDM) GET_ATTESTATION and GET_CERTIFICATE commands. SPDM is published by the Distributed Management Task Force. Several embodiments may conform to the SPDM specification, which states that "runtime authentication is the process by which an authentication initiator or requester interacts with a responder in a running system. The authentication initiator may retrieve the 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, using the root certificate as a trusted anchor."

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

[0140] In one embodiment, boot code 1840 can register SHD_PUF to function as keying material for DevAK keys and ROM_PUF to function as keying material for DevIK keys. In one embodiment, boot code may perform these tasks using the SRAM PUF API (e.g., SRAM PUF functions) so that the private cryptographic 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 SHD_PUF and ROM_PUF, boot code 1840, acting as the Base of Trust (RoT), can store the DevIKpub (public) key, the DevAK certificate containing the DevAKpub (public) key, and the DevAK keycode in the firmware mailbox 1886. Boot code 1840 can obtain the DevAKpub and DevAK keycode from SHD_PUF (via SRAM PUF API calls) and the DevIKpub from ROM_PUF (via SRAM PUF API calls). (Further details regarding the generation of DevAK certificates are provided in Figure 19 and the relevant descriptions below). In one embodiment, the FMC can access information stored in the firmware mailbox 1886, such as the DevAK keycode.

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

[0142] In another embodiment, initiator 1821 may send an SPDM GET_CERTIFICATE request to FMC1820 via the I2C interface. In some embodiments, FMC1820 may respond by sending a device X.509 certificate, which may be a device authentication certificate (DevAKcert). In other embodiments, FMC1820 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] Figure 19 shows an exemplary electronic device 1901 according to the present disclosure. The electronic device 1901 may include boot code 1904, firmware mailbox 1986, PUF engine 1955, ROM_PUF1985, SHD_PUF1999, and FMC1920. Boot code 1940 may be immutable boot code stored in ROM 130 (Figure 1), or it may be authenticated variable code stored in, for example, non-volatile memory 173 (Figure 1). 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 (Figure 1). Firmware mailbox 1986 may be an area in command memory 171 (Figure 7), which may be volatile SRAM. ROM_PUF1985 and SHD_PUF1999 may be read / write lockable areas within the non-volatile SRAM 172 (Figure 16). FMC1920 may be certified variable code, such as firmware or application code, that can function as an SPDM responder (for example, similar to FMC1820 in Figure 18).

[0144] As shown in the diagram, the ROM_PUF1985 and SHD_PUF1999 areas may be directly accessible by the PUF engine 1955 (SRAM PUF API), but not directly accessible by the FMC 1920. For example, the FMC 1920 may not read or write to the keying material portion of the SHD_PUF1999 area because it may be locked for read / write access. However, the FMC 1920 can call the SRAM PUF API functions of the PUF engine 1955, and these functions can access the SHD_PUF secret, for example, to sign the data provided by the FMC 1920 with a DevAKpriv key. In one embodiment, the PUF engine and SRAM PUF API may be designed not to expose the SHD_PUF (or ROM_PUF) secret to the FMC 1920, or in some embodiments to the boot code 1940. For example, SRAM PUF API functions may not allow the FMC1920 to read any of the secrets, and may not return them to the FMC1920 as a result of the function call.

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

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

[0147] Action 1 may represent boot code 1940 requesting the initialization of an SRAM PUF (e.g., ROM_PUF, SHD_PUF). In one embodiment, the initialization request may be a request to register an SRAM PUF following a determination that the SRAM PUF is not registered following a change of ownership (block 1710 in Figure 17) and to start a new cryptographic context associated with the new owner. In another embodiment, the initialization request may be a request to start a known cryptographic context for the current owner of the electronic device (block 1725 in Figure 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 one embodiment, the initialization request may be directed to ROM_PUF1985. In another embodiment, the initialization request may be directed to SHD_PUF1999.

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

[0149] Action 3 may represent that boot code 1940 requests a DevAKpub key or a DevIKpub key. Since the public key of the key pair is not secret, the PUF engine 1955 can expose the public key to boot code 1940 (for example, by returning the public key to boot code 1940 so that boot code 1940 can use the key). In one embodiment, boot code 1940 provides the PUF engine 1955 with a key code (for example, a DevAK key code or a DevIK key code) corresponding to the public key it is requesting.

[0150] Action 4 may indicate that boot code 1940 requests a DevAKpriv key code or a DevIKpriv key code. This key code may be used in a subsequent signing request to the PUF engine 1955 (for example, as described with respect to Figure 18, when the FMC requests a signing of the SPDM certification challenge by DevAKpriv).

[0151] Action 5 may indicate that boot code 1940 requests data to be signed with either a DevIKpriv key or a 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 cert1976. In an embodiment, DevAK cert1976 may include a DevAKpub key (e.g., obtained from PUF engine 1955 in Action 3) as its subject. DevAK cert1976 may be signed using 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 boot code 1940 storing the signed DevAK cert1976 in firmware mailbox 1986, thereby providing the signed DevAK cert1976 to FMC1920.

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

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

[0156] Action 10 may represent FMC1920 reading the signed DevAK cert1976 from firmware mailbox 1986.

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

[0158] Action 12 may represent FMC1920 reading DevIKpub1924 from 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 (for example, after obtaining it from the firmware mailbox 1986). The PUF engine 1955 may return the DevAKpub key.

[0160] Action 14 may represent the FMC1920 requesting the data to be signed with the DevAKpriv key. In one embodiment, the FMC1920 may send the data to be signed, along with the DevAK key code 1922 (for example, after obtaining 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 SPDM requests (e.g., GET_ATTESTATION, GET_CERTIFICATE) to the FMC 1920 (as illustrated / explained in Figure 18).

[0162] Action 16 could represent FMC1920 returning a signed SPDM challenge to remote host 1933 in response to a GET_ATTESTATION request, for example (as illustrated / explained in Figure 18).

[0163] Action 17 could represent FMC1920 returning a certificate to remote host 1933 in response to a GET_CERTIFICATE request, for example.

[0164] Figure 19 discloses a specific number of actions (1-17) associated with the electronic device 1901, but the electronic device 1901 may perform more or fewer actions than those shown in Figure 19. For example, boot code 1940 or FMC 1920 may request the PUF engine 1955 to stop the current cryptographic context (e.g., stop stop pointAs a result, the SRAM PUF secret may be destroyed or erased, and the SRAM PUF may be returned to its uninitialized state. In another embodiment, boot code 1940 may request that a read / write lock be set on the SRAM PUF area, so that no user code (e.g., FMC1920) can access the secret SRAM PUF keying material. In yet another embodiment, FMC1920 may request the generation of another key (e.g., not DevAK or DevIK) using SHD_PUF. In an embodiment, the PUF engine 1955 may return a key code for the newly generated key, and FMC1920 may use the key code to request the PUF engine 1955 to sign the data with the newly generated key, generate and send a public key corresponding to the newly generated key, and so on. Thus, the secret key does not have to be exposed to FMC1920, but it can still be used to sign the data. In addition, Figure 19 discloses actions 1 to 17, but these actions can be completed in any appropriate order.

[0165] Figure 20 shows an exemplary boot code method 2000 for DevAK key and certificate generation. According to one embodiment, method 2000 may begin from block 2002. In one embodiment, method 2000 may be executed by boot code 140, 1840, or 1940. In some embodiments, the starting block 2002 may represent the time when the electronic device 101 is first powered on (POR), or the time following a reset of the electronic device (e.g., device reset, reboot, or power cycle). Thus, method 2000 may be executed by boot code 140 when the volatile memory 172 (e.g., SRAM with ROM_PUF and SHD_PUF areas) cannot be accessed by the FMC (e.g., because the FMC has not yet been authenticated and loaded). The teachings of this disclosure can be executed in various configurations of system 100. Therefore, the initialization point of method 2000 and the order of blocks 2002-2032 that constitute method 2000 may depend on the chosen execution.

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

[0167] In one embodiment, method 2000 can proceed by generating a DevIK key. Starting from block 2012, boot code 140 can initialize ROM_PUF (e.g., 1604 in Figure 16). In one embodiment, this may involve boot code 140 registering 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 may be unique for each owner of the electronic device (like the SHD_PUF cryptographic context). Thus, initializing ROM_PUF in block 2012 may or may not include providing the PUF activation code for the current owner to the PUF engine in order to re-establish a previous cryptographic context for the current owner. The method can then proceed to block 2014, where boot code 140 can request the generation of a DevIKpriv key and obtain a DevIK key code (e.g., action 2 in Figure 19).

[0168] In one embodiment, Method 2000 can proceed by generating a DevAK certificate. Starting from block 2016, boot code 140 can obtain a DevAK certificate template which can be stored in OTP memory 110, non-volatile memory 173, boot ROM 130, or any other preferred location. (Boot code 140 can authenticate the DevAK certificate template before 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 can then proceed to block 2018, where boot code 140 can generate an unsigned DevAK certificate by, for example, storing a DevAKpub key (e.g., generated in block 2006) as the certificate subject. The Method can then proceed to block 2020, where boot code 140 can request that the DevAK certificate be signed using the DevIKpriv key. In one embodiment, boot code 140 sends a request to the PUF engine to sign the DevAK certificate using the DevIKpriv key by providing the PUF engine with the DevAK unsigned certification data and the DevIK key code (e.g., generated in block 2014) (e.g., action 5 in Figure 19). The method can then proceed to block 2022, where boot code 140 can store the DevAK certificate in firmware mailbox 1986 (e.g., action 7 in Figure 19). The method can then proceed to block 2024, where boot code 140 can request to stop the current ROM_PUF cryptographic context (e.g., stop stop point (Request) As a result, the ROM_PUF secret can be destroyed or erased, and the ROM_PUF can be returned to its uninitialized state.

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

[0170] Figure 20 discloses a certain number of operations related to Method 2000, but Method 2000 may be performed with more or fewer operations than those shown in Figure 20. For example, after block 2008, the boot code does not have to request that SHD_PUF be stopped. Similarly, after block 2022, the boot code does not have to request that ROM_PUF be stopped. In these embodiments, stopping the SRAM PUF at the boot code termination event may be good practice to avoid FMC access to device secrets. However, stopping the SRAM PUF may be avoided, for example, if the boot code executes blocks 2002-2032 of Method 2000 without terminating the FMC or before loading the FMC. In one embodiment, if block 2010 is omitted, SHD_PUF was not stopped, so block 2026 (initializing SHD_PUF) may also be omitted. In addition, Figure 20 discloses a specific sequence of operations performed with respect to Method 2000, but the operations constituting Method 2000 may be completed in any preferred order. For example, the boot code may generate the DevIK key (blocks 2012-2014) before generating the DevAK key (blocks 2002-2010).

[0171] Figure 21 shows a flowchart of an exemplary method 2100 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2100 may begin from block 2110. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2100 and the order of blocks 2110-2135 that constitute method 2100 may depend on the chosen execution.

[0172] In block 2110, for an electronic device having a processor, non-volatile memory, and SRAM including an SRAM physically non-copyable function (SRAM PUF) area, the processor can store first owner information and first owner variable code in the non-volatile memory. In one embodiment, the SRAM PUF area may include a secret, non-copyable silicon fingerprint unique to the electronic device. In the same or different embodiments, the first owner information can emulate one-time programmable memory (for example, as OTP emulate parameters as described with respect to Figure 6) and may be stored in the non-volatile memory so as to be unique to the first owner of the electronic device. In block 2115, the processor can 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 may not be directly accessible by the first owner variable code (for example, the PUF engine 1955 may not expose the first unique secret key to the first owner variable code, while still allowing the first owner variable code to sign data with the first unique secret key). In block 2120, the processor can generate a first unique secret key code corresponding to the first unique secret key. In block 2125, the processor can provide the first unique secret key code to the first owner variable code. (The key code may function as a reference or handle to a corresponding key so 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 the PUF engine 1955 and its secrecy may be maintained.) In block 2130, the processor may receive a signature request from a first owner variable code, the signature request comprising a first unique secret key code and first data. In one embodiment, the first data may include a device proof challenge. Block 213 5In this case, in response to a signature request from the first owner variable code, the processor can 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] Figure 21 discloses a specific number of operations related to Method 2100, but Method 2100 may be performed with more or fewer operations than those shown in Figure 21. For example, after block 2135, Method 2100 may continue with additional operations shown in Figures 22 to 29. In addition, Figure 21 discloses a specific order of operations performed with respect to Method 2100, but the operations constituting Method 2100 may be completed in any preferred order.

[0174] Figure 22 shows a flowchart of an exemplary method 2200 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2200 may begin from block 2210. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2200 and the order of blocks 2210-2220 that constitute method 2200 may depend on the chosen execution.

[0175] In one embodiment, block 2210 may be the same as blocks 2110-2135 in Figure 21. In block 2215, the processor can receive a key generation request from a first owner variable code. In block 2220, in response to the key generation request from the first owner variable code, the processor can 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 (Figure 16) and may be different from the DevAK key (for use other than, for example, responding to a device proof challenge).

[0176] Figure 22 discloses a specific number of operations related to Method 2200, but Method 2200 may be performed with more or fewer operations than those shown in Figure 22. In addition, Figure 22 discloses a specific order of operations performed with respect to Method 2200, but the operations constituting Method 2200 may be completed in any preferred order.

[0177] Figure 23 shows a flowchart of an exemplary method 2300 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2300 may begin from block 2310. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2300 and the order of blocks 2310-2335 that constitute method 2300 may depend on the chosen execution.

[0178] In one embodiment, block 2310 may be the same as blocks 2110-2135 in Figure 21. In block 2315, the processor can transfer ownership of an electronic device to a second owner, including storing second owner information and a second owner variable code in non-volatile memory, the second owner information may be unique to the second owner of the electronic device. In one embodiment, the ownership transfer may proceed as illustrated and described in any of Figures 8-15. In block 2320, the processor can generate a second unique secret key based on both the second owner information and at least a portion of the SRAM PUF area, the second unique secret key may not be directly accessible by the second owner variable code (for example, the PUF engine 1955 may not expose 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 can generate a second unique secret key code corresponding to the second unique secret key. In block 2330, the processor may provide a second unique secret key code to a second owner variable code. In block 2335, the processor may prohibit access to or regeneration of the first unique secret key while the second owner possesses the electronic device. In one embodiment, access is prohibited if (1) the first unique secret key is (e.g., suspended stop point It has been erased or destroyed (by request, or by resetting the electronic device 101), (2) Boot code 140 may be prohibited because it could restrict the cryptographic context to the current user's cryptographic context by, for example, using the current owner's PUF startup code, which can be authenticated before use. Therefore, the system may not permit the use of a previous owner's PUF startup code and thus prohibit access to or regeneration of the first unique private key.

[0179] Figure 23 discloses a specific number of operations related to Method 2300, but Method 2300 may be performed with more or fewer operations than those shown in Figure 23. For example, after block 2335, Method 2300 may continue with additional operations shown in Figures 24 and 25. In addition, Figure 23 discloses a specific order of operations performed with respect to Method 2300, but the operations constituting Method 2300 may be completed in any preferred order.

[0180] Figure 24 shows a flowchart of an exemplary method 2400 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2400 may begin from block 2410. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2400 and the order of blocks 2410-2420 that constitute method 2400 may depend on the chosen execution.

[0181] In one embodiment, block 2410 may be the same as blocks 2310 to 2335 in Figure 23. In block 2415, the processor can receive a second owner signature request from the second owner variable code, the second owner signature request including a 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 can 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] Figure 24 discloses a specific number of operations related to method 2400, but method 2400 may be performed with more or fewer operations than those shown in Figure 24. For example, after block 2420, method 2400 may continue with additional operations shown in Figure 25. In addition, Figure 24 discloses a specific order of operations performed with respect to method 2400, but the operations constituting method 2400 may be completed in any preferred order.

[0183] Figure 25 shows a flowchart of an exemplary method 2500 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2500 may begin from block 2510. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2500 and the order of blocks 2510-2520 that constitute method 2500 may depend on the chosen execution.

[0184] In one embodiment, block 2510 may be the same as blocks 2410-2420 in Figure 24. In block 2515, the processor can 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 can 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 (Figure 16) and may be different from a DevAK key (for use other than, for example, responding to a device proof challenge).

[0185] Figure 25 discloses a specific number of operations related to Method 2500, but Method 2500 may be performed with more or fewer operations than those shown in Figure 25. In addition, Figure 25 discloses a specific order of operations performed with respect to Method 2500, but the operations constituting Method 2500 may be completed in any preferred order.

[0186] Figure 26 shows a flowchart of an exemplary method 2600 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2600 may begin from block 2610. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2600 and the order of blocks 2610-2625 that constitute method 2600 may depend on the selected execution.

[0187] In one embodiment, block 2610 may be the same as blocks 2110-2135 in Figure 21. In block 2615, the method may include destroying a first unique secret key during the reset of the electronic device. In one embodiment, the first unique secret key is stored in volatile memory and may be destroyed or erased during the reset, and its contents may not be maintained during the reset event. In an alternative embodiment, the processor, in response to instructions in the boot code, stops the PUF engine 1955. stop point By making a request, the first unique private key may be destroyed or erased. In response to this request, the PUF engine 1955 may destroy or erase the first unique private key, which may be a variable code stored in 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 (for example, the PUF engine 1955 may not expose 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 signature request from the first owner variable code, the processor may use the first unique private key code to sign the first data with the regenerated first unique private key. In one embodiment, the PUF engine 1955 can use a first unique secret key code as a reference or handle to determine the corresponding key that will ultimately be used to sign the data.

[0188] Figure 26 discloses a specific number of operations related to Method 2600, but Method 2600 may be performed with more or fewer operations than those shown in Figure 26. In addition, Figure 26 discloses a specific order of operations performed with respect to Method 2600, but the operations constituting Method 2600 may be completed in any preferred order.

[0189] Figure 27 shows a flowchart of an exemplary method 2700 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2700 may begin from block 2710. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2700 and the order of blocks 2710-2720 that constitute method 2700 may depend on the chosen execution.

[0190] In one embodiment, block 2710 may be the same as blocks 2110 to 2135 in Figure 21. In block 2715, the processor can receive a public key request from a first owner variable code, the public key request may include a first unique private key code. In block 2720, in response to the public key request, the processor can 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] Figure 27 discloses a specific number of operations related to Method 2700, but Method 2700 may be performed with more or fewer operations than those shown in Figure 27. In addition, Figure 27 discloses a specific order of operations performed with respect to Method 2700, but the operations constituting Method 2700 may be completed in any preferred order.

[0192] Figure 28 shows a flowchart of an exemplary method 2800 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2800 may begin from block 2810. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2800 and the order of blocks 2810-2825 that constitute method 2800 may depend on the selected execution.

[0193] In one embodiment, block 2810 may be the same as blocks 2110 to 2135 in Figure 21. In block 2815, the processor may generate a first unique public key corresponding to a first unique private key. In block 2820, the processor may generate a certificate having the first unique public key as the object to be proven. In block 2825, the processor may generate a signature for the certificate using the device identification private key.

[0194] Figure 28 discloses a specific number of operations related to Method 2800, but Method 2800 may be performed with more or fewer operations than those shown in Figure 28. For example, after block 2825, Method 2800 may continue with additional operations shown in Figure 29. In addition, Figure 28 discloses a specific order of operations performed with respect to Method 2800, but the operations constituting Method 2800 may be completed in any preferred order.

[0195] Figure 29 shows a flowchart of an exemplary method 2900 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 2900 may begin from block 2910. The teachings of this disclosure can be performed in various configurations of system 100. Therefore, the initialization point of method 2900 and the order of blocks 2910-2915 that constitute method 2900 may depend on the chosen execution.

[0196] In one embodiment, block 2910 may be the same as blocks 2810 to 2825 in Figure 28. In block 2915, the processor can provide the first owner variable code with a certificate which may have a first unique public key as the object of proof.

[0197] Figure 29 discloses a specific number of operations related to Method 2900, but Method 2900 may be performed with more or fewer operations than those shown in Figure 29. In addition, Figure 29 discloses a specific order of operations performed with respect to Method 2900, but the operations constituting Method 2900 may be completed in any preferred order.

[0198] Figures 30a and 30b show flowcharts of an exemplary method 3000 for using an SRAM PUF shared by multiple entities to manage device keys. According to one embodiment, method 3000 may begin from block 3010. The teachings of this disclosure can be performed in various configurations of system 100. Thus, the initialization point of method 3000 and the order of blocks 3010 to 3070 that constitute method 3000 may depend on the chosen execution.

[0199] In block 3010, for an electronic device having a processor, non-volatile memory, and SRAM including an SRAM physically non-copyable function (SRAM PUF) area, the processor can store first owner information and a first owner variable code in the non-volatile memory. In one embodiment, the SRAM PUF area may include a secret, non-copyable silicon fingerprint unique to the electronic device. In the same or different embodiments, the first owner information can emulate one-time programmable memory (for example, as OTP emulate parameters as described with respect to Figure 6) and may be stored in the non-volatile memory so as to be unique to the first owner of the electronic device. In block 3015, the processor can generate a device identification secret key based on at least a portion of the SRAM PUF area. In block 3020, the processor can generate a first unique private key which may be obtained based on both first owner information and at least a portion of the SRAM PUF area, and which may not be directly accessible by the first owner variable code (for example, the PUF engine 1955 may not expose the first unique private key to the first owner variable code, while still allowing the first owner variable code to sign data using the key). In block 3025, the processor can generate a first unique public key corresponding to the first unique private key. In block 3030, the processor can generate a first unique private key code corresponding to the first unique private key. In block 3035, the processor can generate a certificate which may have the first unique public key as the object of proof. In block 3040, the processor can sign the certificate using the device identification private key. In block 3045, the processor may provide the first owner variable code with a first unique private key code (for example, by storing it in the firmware mailbox). In block 3050, the processor may provide the first owner variable code with a certificate (for example, by storing it in the firmware mailbox).In block 3055, the method may include erasing a first unique secret key during the reset of the electronic device. In one embodiment, the first unique secret key is stored in volatile memory and may be destroyed or erased during the reset, and its contents may not be maintained during the reset event. In an alternative embodiment, the boot code stops. stop point By issuing a request to the PUF engine 1955, the processor can be caused to destroy or erase the first unique private key. In block 3060, following a reset of the electronic device, the processor can 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 (for example, the PUF engine 1955 may not expose 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 3065, the processor can receive a signature request from the first owner variable code, the signature request comprising the first unique private key code and first data. In one embodiment, the first data may include a device proof challenge. In block 3070, in response to receiving a signature request from the first owner variable code, the processor may sign the first data with a 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] Figures 30a to 30b disclose a specific number of operations related to Method 3000, but Method 3000 may be performed with more or fewer operations than those shown in Figures 30a to 30b. In addition, Figures 30a to 30b disclose a specific order of operations performed with respect to Method 3000, but the operations constituting Method 3000 may be completed in any preferred order.

[0201] Methods 1700 and 2000-3000 may be performed using System 100 or any other system capable of performing Methods 1700 and 2000-3000. Although embodiments have been described above, other variations and embodiments can be derived from this disclosure without departing from the spirit and scope of these disclosed embodiments.

Claims

1. It is a device, It is an electronic device, Boot code and, A first variable code stored in non-volatile memory, The first owner information stored in the non-volatile memory, An electronic device comprising a static random access memory (SRAM) including an SRAM physical non-copyable function (SRAM PUF) area, The aforementioned boot code is: A first unique secret key is generated based on both the first owner information and at least a portion of the SRAM PUF area, and the first unique secret key is not directly accessible by the first variable code. A first unique secret key code corresponding to the first unique secret key is generated, The processor can perform the following actions to provide the first variable code with the first unique secret key code corresponding to the first unique secret key: The first variable code is, Using the first unique secret key code, the data is signed 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 portion of the SRAM PUF area.

2. The device according to claim 1, wherein the SRAM PUF region 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 aforementioned boot code is: Transferring ownership of the electronic device to a second owner, including storing second owner information in the non-volatile memory, wherein the second owner information is unique to the second owner of the electronic device. A second unique secret key is generated based on both the second owner information and at least a portion of the SRAM PUF area, and the second unique secret key is not directly accessible by the first variable code. A second unique secret key code corresponding to the second unique secret key is generated, The first variable code is provided with the second unique secret key code, The device according to claim 3, wherein the processor is executable to prohibit the second owner from accessing or regenerating the first unique secret key while the second owner possesses the electronic device.

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

6. The reset of the electronic device erases the first unique secret key. 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 is 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 is executable by the processor to cause data to be signed with the first unique secret key using the first unique secret key code, the first variable code is executable by the processor to cause data to be signed 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 certification challenge from a remote host and, in response to the device certification challenge, send a signed device certification response to the remote host. The device according to claim 1, wherein the first variable code is executable by the processor to cause the first unique secret key code to sign data with the first unique secret key, which includes the first variable code being executable by the processor to cause the first unique secret key code to sign the device certificate response with the first unique secret key.

8. An electronic device having a processor, non-volatile memory, and static random-access memory (SRAM) including an SRAM physically non-copyable function (SRAM PUF) area, wherein the processor stores first owner information and a 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 area, wherein the first unique secret key is not directly accessible by the first owner variable code. The processor generates a first unique secret key code corresponding to the first unique secret key, The processor provides the first unique secret key code to the first owner variable code, The processor receives a signature request from the first owner variable code, the signature request comprising the first unique private key code and first data, In response to the signature request from the first owner variable code, The processor signs the first data with the first unique secret key, A method comprising the step of the processor providing the first data signed with the first unique secret key to the first owner variable code.

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

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. A step of transferring ownership of an electronic device to a second owner, comprising the processor storing second owner information and a second owner variable code in the non-volatile memory, wherein the second owner information is unique to the second owner of the electronic device; The step of the processor generating a second unique secret key based on both the second owner information and at least a portion of the SRAM PUF area, wherein the second unique secret key is not directly accessible by the second owner variable code. The processor generates a second unique secret key code corresponding to the second unique secret key, The processor provides the second unique secret key code to the second owner variable code, The method according to claim 8, further comprising the step of the processor prohibiting access to or regeneration of the first unique secret key while the second owner possesses the electronic device.

13. 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 the second data. In response to the second owner signature request from the second owner variable code, The processor signs the second data with the second unique secret key, The method according to claim 12, comprising the step of providing the second data signed with the second unique secret key to the second owner variable code.

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

15. The steps include destroying the first unique secret key during the reset of the electronic device, The processor includes the step of generating a regenerated first unique secret key, which 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. The method according to claim 8, wherein the step of the processor signing the first data with the first unique private key in response to the signing request from the first owner variable code includes the step of the processor signing the first data with the regenerated first unique private key using the first unique private key code.

16. The method according to claim 8, wherein the first data includes a device certification 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 private key code. In response to the aforementioned public key request, The processor generates a first unique public key corresponding to the first unique private key, The method according to claim 8, comprising the step of the processor providing the first unique public key to the first owner variable code.

18. The processor generates a first unique public key corresponding to the first unique private key, The processor generates a certificate having the first unique public key as the object of proof, The method according to claim 8, further comprising the step of the processor generating a signature for the certificate using a device identification secret key.

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

20. An electronic device having a processor, non-volatile memory, and static random-access memory (SRAM) including an SRAM physically non-copyable function (SRAM PUF) area, comprising the steps of storing first owner information and first owner variable code in the non-volatile memory, The processor generates a device identification secret key based on at least a portion of the SRAM PUF area, 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 area, wherein the first unique secret key is not directly accessible by the first owner variable code. The processor generates a first unique public key corresponding to the first unique private key, The processor generates a first unique secret key code corresponding to the first unique secret key, The processor generates a certificate having the first unique public key as the object of proof, The processor signs the certificate using the device identification secret key, The processor provides the first unique secret key code to the first owner variable code, The processor provides the certificate to the first owner variable code, The steps include erasing the first unique secret key during the reset of the electronic device, The processor, following the reset of the electronic device, generates a regenerated first unique secret key which is equivalent to the first unique secret key and is not directly accessible by the first owner variable code. The processor receives a signature request from the first owner variable code, the signature request comprising the first unique private key code and first data, In response to receiving the signature request from the first owner variable code, The processor signs the first data with the regenerated first unique secret key, A method comprising the step of the processor providing the first owner variable code with the first data signed with the regenerated first unique private key.

Images