OWNER REVOCATION SIMULATION CONTAINER

Abstract

A device comprising a processor and boot code, wherein the processor is operable to generate a plurality of revocation emulation containers associated with a plurality of owners of the electronic device over time, the respective revocation emulation containers comprising revocation information of assets associated with the respective owners of the electronic device. The processor is operable to program the asset revocation information of the plurality of revocation emulation containers in a one-time programmable manner. The processor is operable to use the asset revocation information of the plurality of revocation emulation containers to determine whether to revoke use of the respective assets of a plurality of assets associated with the plurality of owners of the electronic device over time.The processor may revoke subsequent use of assets of the plurality of assets associated with the plurality of owners of the electronic device over time if it determines that the respective asset should be revoked.

Description

PRIORITY

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 423,021, filed November 6, 2022, the contents of which are hereby incorporated in their entirety. FIELD OF THE INVENTION

[0002] This disclosure relates to electronic devices, and more particularly to systems and methods for an Owner Revocation Emulation Container (REC) for managing keys, images, and other assets related to an owner of an electronic device. BACKGROUND

[0003] In computer products, the embedded controller (EC) boot code stored in the boot ROM can act as the root of trust (ROT) for secure boot applications for a specific owner (e.g., the original equipment manufacturer (OEM)) of an electronic device. The OEM can store configuration options in one-time programmable (OTP) memory during device deployment. This can include cryptographic keys used to encrypt and sign the boot images. The OEM can implement and sign the EC boot images, which are loaded and authenticated by the EC boot code stored in the boot ROM. The EC boot code can use custom values ​​stored in the OTP memory to authenticate and decrypt the boot images. Other features supported by the EC boot code can include key revocation and image rollback protection.This may allow the owner to deactivate one or more of the keys stored in a key manifest on the electronic device or to remove certain image revisions from circulation, in particular by setting bits in the OTP memory during the boot sequence.

[0004] The concepts of key revocation and image rollback protection can be applied to the first mutable code (FMC) loaded and authenticated by the boot ROM. These concepts can also be applied to images authenticated by the FMC to extend the chain of trust.

[0005] ECs with Secure Boot typically have a single configuration in the OTP memory, determined at the time of manufacture by the first owner (e.g., OEM). A key manifest for image authentication is generated, hashed, and stored in a Key Hash Blob (KHB), and the KHB hash is stored in the OTP memory. Therefore, all owners of the device can use OEM-signed images.

[0006] An EC with Secure Boot can have multiple owners over the device's lifetime. Each owner can train the device to use a unique set of keys and image revisions, which are used to validate the FMC during the boot ROM authentication sequence. These keys and images can be validated using the key revocation and image rollback protection information. If key revocation and image rollback protection are stored in the OTP memory, all device owners must share the key revocation and image rollback bits. If 32 bits in the OTP memory are dedicated to key revocation and the first device owner has revoked 31 keys, the second device owner can only support one key.

[0007] There is therefore a need to manage information about key revocation and image rollback protection in such a way that subsequent owners of the electronic device are not restricted by the use of key revocation and image rollback protection features by a previous owner. SUMMARY

[0008] According to one example, a device may include boot code and non-volatile memory. The boot code may be executed by a processor to generate a first unique private key, wherein the first unique private key may not be directly accessible by code other than the boot code; generating a first owner revocation emulation container for a first owner of the device, wherein the first owner revocation emulation container includes first asset revocation information; using the first unique private key to generate a first signature,which corresponds to the revocation emulation container of the first owner; storing the first signature in the non-volatile memory; storing the revocation emulation container of the first owner in the non-volatile memory; retrieving the first signature from the non-volatile memory; retrieving the revocation emulation container of the first owner from the non-volatile memory; deriving a first unique public key from the first unique private key; using the first unique public key and the first signature retrieved from the non-volatile memory,to verify the revocation emulation container of the first owner retrieved from the non-volatile memory; after successfully verifying the revocation emulation container of the first owner retrieved from the non-volatile memory, use the first asset revocation information of the revocation emulation container of the first owner retrieved from the non-volatile memory to determine whether the use of a first asset associated with the first owner of the device should be revoked; and revoke subsequent use of the owner's first asset based on the determination that the owner's first asset should be revoked. Another example provides a method for an electronic device comprising a processor, a non-volatile memory,a boot code and a static random access memory (SRAM) including a region of physically non-clonable functionality (SRAM PUF). The method may include the processor generating a first unique private key based on at least one or more of the following information: (i) first ownership information associated with a first owner of the electronic device, and (ii) at least a portion of the SRAM PUF region, wherein the first unique private key is not directly accessible by code other than the boot code. The method may include the processor creating a first owner revocation emulation container for the first owner of the electronic device, wherein the first owner revocation emulation container includes first asset revocation information. The method may includethat the processor uses the first unique private key to generate a first signature corresponding to the first owner's revocation emulation container. The method may include the processor storing the first signature in the non-volatile memory. The method may include the processor storing the first owner's revocation emulation container in the non-volatile memory. The method may include the processor retrieving the first signature from the non-volatile memory. The method may include the processor retrieving the first owner's revocation emulation container from the non-volatile memory. The method may include the processor deriving a first unique public key from the first unique private key. The method may includethe processor uses the first unique public key and the first signature retrieved from the non-volatile memory to verify the first owner's revocation emulation container retrieved from the non-volatile memory. After successfully verifying the first owner's revocation emulation container retrieved from the non-volatile memory, the method may include the processor using the first asset revocation information of the first owner's revocation emulation container retrieved from the non-volatile memory to determine whether use of a first asset associated with the first owner of the electronic device should be revoked. The method may include the processor revoking subsequent use of the owner's first asset if it determines that the owner's first asset should be revoked.

[0009] Another example provides a method for an electronic device having a processor and boot code. The method may include the processor generating a plurality of revocation emulation containers associated with a plurality of owners of the electronic device over time, wherein the respective revocation emulation containers may include asset revocation information associated with the respective owners of the electronic device. The method may include the processor programming the asset revocation information of the plurality of revocation emulation containers in a one-time programmable manner.The method may include the processor using the asset revocation information of the plurality of revocation emulation containers to determine whether the use of the respective assets of a plurality of assets associated with the plurality of owners of the electronic device should be revoked over time. The method may include the processor revoking subsequent use of assets from the plurality of assets associated with the plurality of owners of the electronic device over time if the processor determines that the respective asset should be revoked. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The figures illustrate example methods and systems for managing keys, images, and other assets associated with an owner of an electronic device. Fig. 1 illustrates a block diagram of an example system for managing ownership, keys, images, and other assets related to an owner of an electronic device. Fig. Figure 2 illustrates a block diagram of an example OTP store for managing ownership, keys, images, and other assets related to the owner of an electronic device. Fig. Figure 3 illustrates a block diagram of an example secure RPMC Owner Container for managing ownership, keys, images, and other assets related to an owner of an electronic device. Fig. 4 illustrates a block diagram of an example container header of an owner container for managing ownership of an electronic device. Fig. Figure 5 illustrates a block diagram of an example of the contents of a container for managing ownership of an electronic device. Fig. 6 illustrates a block diagram of an example of the contents of an owner container of an electronic device for managing ownership. Fig. Figure 7 illustrates an example instruction memory. Fig. Figure 8 illustrates a block diagram of an example of managing ownership of an electronic device, including the creation of an initial owner container using OEM-signed images and OTP configuration. Fig. 9 illustrates a block diagram of an example of managing ownership of an electronic device, including the creation of an initial owner container using OEM-signed images and an OTP emulation configuration. Fig. 10 illustrates a flowchart of an example method for managing ownership of an electronic device, including securely transferring ownership of the electronic device over time. Fig. 11 and Fig. 12 illustrate block diagrams of two examples of managing ownership of an electronic device using unrestricted transfer and an owner transfer authorization key (OTAK). Fig. 13 illustrates a block diagram of an example of managing ownership of an electronic device, including transferring ownership using a current owner container command (CCK) key and a first mutable binary (FMB) configuration stored in OTP memory. Fig. 14 illustrates a flowchart of an example method for managing ownership of an electronic device, including securely transferring ownership of the electronic device over time. Fig. 15 illustrates a flow diagram of an example method for managing ownership of an electronic device, including securely transferring ownership of the electronic device over time. Fig. Figure 16 illustrates an example of a volatile SRAM memory with physically non-clonable functional (PUF) areas that can be used for cryptographic key management. Fig. Figure 17 illustrates a flowchart of an exemplary method for SRAM PUF registration and subsequent key reconstruction. Fig. Figure 18 illustrates an exemplary electronic device that can respond to Secure Protocol Data Model (SPDM) commands. Fig. 19 illustrates an example electronic device having an SRAM PUF shared by multiple entities for managing device keys. Fig. Figure 20 illustrates an example boot code procedure for generating DevAK keys and certificates. Fig. 21-30b illustrate flowcharts of example methods for using a shared SRAM PUF to manage device keys. Fig. 31 illustrates a block diagram of an example OTP store for managing keys, images, and other assets related to an owner of an electronic device. Fig. Figure 32 illustrates a block diagram of the contents of an owner container for managing keys, images, and other assets for the owner of an electronic device. Fig. 33 illustrates a block diagram of an example secure revocation emulation container for managing ownership, keys, images, and other assets associated with an owner of an electronic device. Fig. 34 illustrates a block diagram of an example secure revocation emulation container header of an owner container for managing ownership, keys, images, and other assets related to an owner of an electronic device. Fig. 35 illustrates a block diagram of an example of the contents of a secure revocation emulation container of an owner container for managing ownership, keys, images, and other assets related to an owner of an electronic device. Fig. 36 illustrates a flowchart of an exemplary method for deprivation emulation. Fig. Figure 37 illustrates a block diagram of various RPMC values ​​related to withdrawal emulation, including how the REC container can be bound to the owner container at creation time. Fig. Figure 38 illustrates a block diagram of various RPMC values ​​related to withdrawal emulation, including an illustration of how the REC RPMC value can be increased to withdraw an asset. Fig. 39-44 illustrate flowcharts of example methods for managing ownership, keys, images, and other assets related to an owner of an electronic device. The reference numerals for each illustrated element that appears in several different figures have the same meaning in all figures, and mention or discussion of an illustrated element in connection with a particular figure also applies to any other figure in which the same illustrated element is shown, if any. DETAILED DESCRIPTION

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

[0012] The present disclosure provides systems and methods for supporting multiple owners of a given electronic device over time, including securely transferring ownership between the different owners by storing each owner's information and configuration in a signed, secure, replay-protected monotonic counter (RPMC) in memory, e.g., serial peripheral interface (SPI) flash memory. In one example, the owner's cryptographic keys, secrets, 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)).Because secure information can be stored in erasable storage, the contents can be signed and verified before being used to increment security. In some examples, the system and methods for storing and updating the signed secure RPMC owner container can comply with the NIST 800-193 Platform Firmware Resiliency Guidelines. As used herein, "secure RPMC owner container," "RPMC owner container," and "owner container" include a signed secure RPMC owner container.

[0013] When an electronic device (e.g., a microcontroller) boots up (e.g., at power-up or after a hardware or software reset), boot code may be loaded and executed by a processor on the device. The boot code may perform functions related to starting the device, such as initializing the hardware, which may include disabling interrupts, initializing buses, putting the processor(s) into a particular state, and initializing memory. After performing hardware initialization, the boot code may then load a first mutable code (FMC), for example, from a signed first mutable binary code (FMB), which may comprise one or more images. In one example, the FMC may be application firmware, which may be signed by an OEM or other owner of the electronic device.In the same or other examples, the FMC may be the OEM's or another owner's application firmware, a ROM extension (ROM_EXT) or boot code extension, RIOT (Robust Internet of Things) code, or other modifiable code. The functions performed by the boot code may be referred to as the boot process.

[0014] The electronic device may include security mechanisms that protect against malicious attacks on the device. For example, an electronic device may prevent (1) loading and executing the FMC, (2) transferring ownership of the electronic device, or (3) recovering from crisis events by persons other than the silicon owner. In one example, these operations may require knowledge of secrets (e.g., cryptographic keys) known to the silicon owner. Because the silicon owner controls the secrets (e.g., cryptographic keys) used for loading and executing the FMC, transferring ownership, and crisis recovery, malicious attacks on the device may be reduced.

[0015] The silicon owner or the electronic device owner can be the entity that provides the signed FMB, which is loaded and authenticated by the boot code. The FMB can contain the FMC image, which is loaded and executed by the boot code. The owner can provide a KHB containing hashes of the individual public keys that can be used to authenticate the FMB. During manufacturing, for example, a hash of the OEM KHB can be stored in the OTP memory and the OEM KHB itself can be stored in non-volatile memory (e.g., SPI Flash). The boot code can calculate the SHA384 (OEM KHB) and compare it to the hash of the OEM KHB stored in the OTP memory. If the calculated hash matches the stored hash, the boot code can trust the public key hashes stored in the OEM KHB and use them to authenticate the OEM FMB.

[0016] The OEM can establish ownership during manufacturing (e.g., the OEM as the implicit owner) or when ownership is requested by another entity. Once ownership is established, the silicon owner can use the OEM images signed with the OEM image signing keys, or the owner can provide their own images signed with their image signing keys. In the latter case, an owner-provided KHB hash value can be stored in a secure RPMC Owner Container, and an owner-provided KHB can be stored in non-volatile storage (e.g., SPI Flash). The owner's image signing keys can be validated by the hash values ​​stored in the owner-provided KHB.For example, the boot code can calculate the SHA384 (owner-provided KHB) and compare it with the stored hash value of the KHB provided by the owner. If the calculated hash value matches the stored hash value, the boot code can trust the hashes of the public key stored in the owner-provided KHB and use them to authenticate the owner-provided FMB.

[0017] Security features for an electronic device can be implemented using boot code on the electronic device. In one example, the security features can be implemented using immutable boot code. Immutable boot code, also known as Hardware Root of Trust (ROT), can be built into the electronic device during manufacturing and is therefore implicitly trusted because it cannot be modified.

[0018] For the purposes of this disclosure, an electronic device may include any instrument or collection of instrumentation operable to calculate, classify, process, transmit, receive, retrieve, generate, switch, store, display, recognize, record, reproduce, process, or use any form of information, intelligence, or data for business, scientific, control, entertainment, or any other purpose. An electronic device may be, for example, a personal computer, a personal digital assistant (PDA), a consumer electronic device, a server, a network storage device, or any other suitable device, and may vary in size, shape, performance, functionality, and price.The electronic device may include memory, one or more processing resources such as a central processing unit (CPU), or hardware or software control logic.

[0019] Other components of the electronic device may include one or more memory devices, one or more communication ports for communicating with external devices, and various input and output (I / O) devices such as a keyboard, a mouse, and a video monitor. The electronic device may also include one or more buses operable to transmit communication between the various hardware components. system

[0020] Fig. 1 illustrates a block diagram of an example 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 Fig. 1, the system 100 may include an electronic device 101. The components of the electronic device 101 may include, among other things, one or more processors 160 and a system bus 121 that couples various components of the system to the processors 160, such as the OTP memory 110, the ROM 130, the storage 170, the I / O & port control 190, and a network interface 150. The system bus 121 may be any suitable type of bus structure, such as a memory bus, a peripheral bus, or a local bus, using a variety of bus architectures. In one example, the components of the electronic device 101 may all be located on the same chip. In another example, the components of the electronic device 101 may include individual components that are electrically coupled.

[0021] Processor 160 may comprise any system, apparatus, or device operable to interpret or execute program instructions or process data, and may include, but is not limited to, a microprocessor, a microcontroller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), or any other digital or analog circuit for interpreting or executing program instructions or processing data. In some examples, processor 160 may interpret or execute program instructions or process data stored locally (e.g., in memory 170, ROM 130, OTP memory 110, or another component of electronic device 101). In the same or alternative examples, processor 160 may interpret or execute program instructions or process data stored remotely.

[0022] The OTP memory 110 (one-time programmable memory) may include any system, device, or apparatus that can be programmed only once and thereafter retains the programmed data. The OTP memory 110 may include one-time programmable bits 120a, 120b, and others. In one example, bits 120a and 120b of the OTP memory 110 may comprise conventional logic gates connected with metal wires, and the connections may be paired with fuses. During programming, the fuses may be blown to make these connections permanent. In this way, the OTP memory 110 cannot be changed after programming. In one example, an unprogrammed bit (e.g., 120a, 120b) may return a value of 0 when read by the processor 160, while a programmed bit returns a value of 1 when read by the processor 160.According to this example, once bit 120a, 120b has a value of 1, it can no longer be reprogrammed to a value of 0.

[0023] ROM 130 may include any system, apparatus, or device operable to retain program instructions or data after the electronic device 101 is turned off (e.g., non-volatile memory). ROM 130 (e.g., boot ROM) may include boot code 140, which may be used by processor 160 during the boot process (or power-up) of the electronic device 101. According to one example, boot code 140 may be immutable, i.e., built into the electronic device during manufacturing and therefore implicitly trusted (e.g., a hardware root of trust) because it is not modifiable. Boot code 140 may include code that performs functions, including, but not limited to, functions F1 (145a) and F2 (145b). In one example, function F1 may be the boot code.In the same or another example, function F2 may be part of a runtime application programming interface (API), e.g., PUF Engine 1955 (FIGURE 19). In one example, boot code 140 may be authenticated mutable code that can act as a ROM extension (e.g., an FMC that can be authenticated by other boot code stored in ROM, where the FMC can be stored in volatile memory 172 or non-volatile memory 173). In one example, boot code 140 may include both immutable code (e.g., stored in ROM 130) and authenticated mutable code that can act as a ROM extension.

[0024] Memory 170 may comprise any system, apparatus, or device operable to retain program instructions or data for a period of time. Memory 170 may comprise random access memory (RAM, SRAM, DRAM), EEPROM, a PCMCIA card, flash memory (e.g., SPI flash), magnetic memory, opto-magnetic memory, hardware registers, or any selection or arrangement of volatile or non-volatile memories. In the illustrated example, memory 170 includes, among others, command memory 171, volatile memory 172, and non-volatile memory 173.

[0025] The I / O & Port Control 190 may include any system, device, or facility generally operable to receive or transmit data to / from / within the electronic device 101. For example, the I / O & Port Control 190 may include any number of communication interfaces, graphics interfaces, video interfaces, user input interfaces, or peripheral interfaces (e.g., without limitation, JTAG, I2C, UART, test access port). The I / O & Port Control 190 may be communicatively coupled to external ports / pins 180-1, 180-2, 180-N (and others not shown).

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

[0027] Although Fig. 1 illustrates various components of electronic device 101, other example systems may include electronic devices with more or fewer components. In one example, an electronic device 101 according to this disclosure may not include one or all of the dashed components without departing from the spirit and scope of these disclosed examples. Additionally, the various components of electronic device 101 may be packaged on the same die (e.g., a primary die) or on separate dies. In one example, various components may be packaged within the assembly in a multi-chip module (MCM) or externally on a system board. In the same or other examples, various components of electronic device 101 may be packaged in one or more of the primary dies, in an MCM, and externally on a system board. OTP storage

[0028] Fig. Figure 2 illustrates a block diagram of an exemplary OTP store 110 for managing ownership of an electronic device 101, including the secure transfer of ownership of the electronic device over time. As shown in Fig. 2, the OTP memory 110 may contain areas including the current RPMC value 202, the random secret 203 generated to generate the boot code, the device unique random secret 204, the serial number 205, the personalization string 206, the device-specific secret information 207, and the RPMC flash container status 208.

[0029] The current RPMC Value 202 may be provided by a repetition-protected monotonic counter that is incremented over time. In the example shown in TABLE 1, the current RPMC Value 202 may be a value stored in an 8-bit range in the OTP Memory 110 and may correspond to nine different values ​​(0-8). In this example, the bits in the OTP Memory 110 for the current RPMC Value 202 may be set sequentially from the lowest bit ([0]) to the highest bit ([8]), and the next RPMC Value may be the next integer value after the current RPMC Value 202. In the same or other examples, values ​​less than the current RPMC Value 202 may be considered revoked and values ​​greater than the current RPMC Value 202 may be considered unused. In the example shown in TABLE 1, values ​​greater than 8 may not be used.In other examples, where more than eight bits are assigned to the current RPMC Value 202 in the OTP Memory 110, values ​​greater than 8 may also be possible. A value less than the current RPMC Value 202 may be considered revoked, as the OTP Memory 110 cannot be programmed to a lower value, as the OTP Memory, by definition, can only be programmed once. For example, if the current RPMC Value 202 has a value of one (1), the least significant bit is programmed and cannot be reset to reset the current RPMC Value 202 to a value of zero (0). TABLE 1 OTP [7:0](binäresFormat) AktuellerRPMC Wert(Hex Format) NächsterRPMC Wert(Hex Format) WiderrufeneRPMC Werte(Hex Format) Nicht verwendeteRPMC Werte (HexFormat) 0000_0000 0 1 Keine 1-8 0000_0001 1 2 0 2-8 0000_001x 2 3 0-1 3-8 0000_01xx 3 4 0-2 4-8 ... ... ... ... ... 01xx xxxx 7 8 0-6 8 1xxx_xxxx 8 n / a 0-7 Keine

[0030] The random secret 203 generated by the boot code can be any random information generated by and accessible only to the boot code 140. For example, the random secret 203 generated by the boot code can be a random number generated by the boot code 140 after setup of the electronic device 101 is complete. The device-specific random secret 204 can be any random information unique to the electronic device 101. In one example, the device-specific random secret 204 can be a device-specific random number programmed into the OTP memory 110 during provisioning (e.g., by the tester). In another example, the device-specific random secret 204 can be a random number generated by the boot code 140 after setup 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 deployment (e.g., by the tester). The personalization string 206 may be a known character string programmed into the OTP memory 110 during deployment (e.g., by the tester). In alternative examples, the personalization string 206 may be hard-coded into the boot code 140 instead of being stored in the OTP memory 110.

[0031] Secret device-specific information 207 may include (a) a device identity key ("DevIK") (e.g., a private key of a public-key cryptographic key pair) or information from which a DevIK can be generated, (b) critical 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 examples, 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), where the boot code 140 may use such a UDS and a ROM seed as source data to generate a DevIK or other device-specific information.

[0032] The RPMC Flash Container Status 208 includes an indication of whether the RPMC Ownership feature is enabled. In one example, the RPMC Ownership feature may be disabled by default during manufacturing, and this disabled state may be reflected in the RPMC Flash Container Status 208. Boot Code 140 may program the RPMC Flash Container Status 208 to include an indication of the Ownership feature's activation when an initial Ownership container is created.

[0033] Although Fig. 2 illustrates different areas of the OTP memory 110, other example systems may include electronic devices with more or fewer areas. RPMC Owner Container

[0034] Fig. 3 illustrates a block diagram of an exemplary secure RPMC Owner Container 302 (Owner Container 302) for managing the ownership of an electronic device 101, including the secure transfer of ownership of the electronic device over time. In one example, an Owner Container 302 may be a signed data image stored in non-volatile memory (e.g., OTP Memory 110, Non-Volatile Memory 173, among others) and containing the configuration information and secrets of the current silicon owner so that the Boot Code 140 can load and execute the owner's executable images (e.g., FMC in FMB). As shown in Fig. 3, owner container 302 may include three areas: container header 310, container content 311, and container signature 312. In one example, owner container 302 may be a uniquely signed container with information modifiable by the code that creates the container (e.g., boot code 140 or a ROM extension (e.g., in an authenticated FMC)), stored in and retrieved from OTP memory (e.g., OTP memory 110) or other non-volatile memory (e.g., non-volatile memory 173). According to the examples in this disclosure, owner container 302 may only be signed and updated by the code that created the container. Higher-level firmware (e.g., code other than the code that created the container) may include a command interface (e.g., command memory 171, Fig. 7) to access or modify information in the owner container 302. In one example, only immutable boot code (e.g., boot code 140) can access or modify information in the owner container 302. In one example, the boot code that creates the owner container 302 can create two redundant copies of the owner container 302. One copy can be the primary owner container, and the other copy can be the fallback container for the owner. Container Signature

[0035] 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 example, the boot code 140 may use a physically non-clonable function (PUF) or a deterministic random bit generator (DRBG) to generate ECDSA-signing keys.

[0036] ECDSA signing keys can be generated using any signing algorithm. For example, the Container Signature 312 can be an ECDSA-384 signature, which has the following characteristics: • Algorithm: Elliptic Curve Digital Signature Algorithm (ECDSA) • Key size: 384 bits • Curve: NIST “secp384r1” curve • Hashing algorithm: SHA384 • Signed message (m) = {Container Header 310 | Container Content 311}

[0037] Boot code 140 may derive the private ECDSA signing key used to sign owner container 302. In one example, the signing key may be generated as a function of the current owner and the unique silicon chip. Thus, it may be possible to have a unique signature per owner per chip. According to one example, boot code 140 may use a DRBG to derive the private ECDSA signing key and provide the DRBG with the following inputs: • Personalization String: can be a known string, e.g. “Container *one* Key Generator” • Additional input: can be {RPMC Value 431 | Device Serial Number 435} • Entropy Input: can be Device Unique Random Secret 204 • True Random Number Generator (TRNG) Input: can be a Random Secret 203 generated by the boot code

[0038] In the example above, Boot Code 140 can generate the ECDSA private key for signing using a method from Section B.4.1 Key Pair Generation Using Extra Random Bits of the FIPS 186-4 specification (although other specifications can also be used): Private key (d) d = (c mod (n -1)) + 1 n = for the P-384 curve defined prime number c = 448-bit positive integer random value

[0039] In one example, Boot Code 140 can extract the first 448-bit positive integer value generated by the DRBG and use that value for "c" to generate the ECDSA private signing key.

[0040] Fig. While Figure 3 illustrates various regions of the owner container 302, other example systems may include electronic devices with more or fewer regions. Container header

[0041] Fig. 4 illustrates a block diagram of an exemplary container header 310 of an owner container 302 for managing the ownership of an electronic device 101. In one example, the container header 310 may have a common format for the owner containers created for the electronic device 101. As shown in Fig. 4, the container header 310 may include the ranges 431-436, including: RPMC Value 431, Active Container Version 432, Container Type 433, Secure Container Content Length 434, Device Serial Number 435, and Container Command Key Hash Blob 436.

[0042] The RPMC Value 431 may be provided by a repeatable monotonic counter, which may be compared with the current RPMC Value 202 in the OTP Memory 110 to determine whether that Owner Container is valid or has been revoked. For example, if the RPMC Value 431 for an Owner Container 302 has a value of three (3), the Boot Code 140 may determine that the Owner Container is valid if the current RPMC Value 202 also has a value of three (3) (e.g., Fig. 2). In the same or other examples, if the RPMC Value 431 for an Owner Container 302 has a value of three (3), Boot Code 140 may determine that the Owner Container is revoked if the current RPMC Value 202 has a value greater than three (3) (e.g., TABLE 1 (Revoked RPMC Values)). In some examples, the RPMC Value 431 may include a check for primary and fallback containers.

[0043] The Active Container Version 432 may include a version number for the Owner Container 302. In one example, the owner of the electronic device 101 may wish to update information in the Owner Container 302 (e.g., the Fig. 6) in a manner that does not require incrementing the RPMC Value 431. Accordingly, the Boot Code 140 may increment the Active Container Version 432 when the other information is updated. In another example, the Boot Code 140 may set the Active Container Version 432 to zero (0) when the RPMC Value 431 is incremented. Thus, the container with the highest RPMC Value 431 and the highest Active Container Version 432 may be the primary owner container for the electronic device 101.

[0044] The Container Type 433 may represent a type associated with the Owner Container 302. In one example, the Container Type 433 may have a value indicating that the container is not initialized. In another example, the Container Type 433 may have a value indicating that the Owner Container 302 is initialized and is a valid owner container. The Secure Container Content Length 434 may include 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, e.g., the Unique Serial Number 205 in the OTP Memory 110. The Container Command Key Hash Blob 436 may include a hash (e.g., SHA384 (Secure Hash Algorithm)) of one or more Container Command Keys (CCKs), which may be public keys of a cryptographic key pair.In the illustrated example, the container command key hash blob 436 may include hashes of the public keys CCK0 437, CCK1 438, CCK2 439, and CCK3 440. In one example, these key hashes may be used to verify commands related to the owner container 302. (Alternatively, the container command key hash blob 436 may include the public keys instead of hashes of the public keys. More storage space may be required in this example.) In one example, CCK0-3 (437-440) may be revoked by setting the hash entry to zero (0). Although . Fig. 4 illustrates different regions of the container header 310, other example systems may include electronic devices with more or fewer regions. Container Contents

[0045] The Owner Container 302 can have various configurations that may depend on the configuration source, including: • FMB Image Configuration Source = OTP Memory (e.g Fig. 5) • FMB Image Configuration Source = OTP emulation in the SPI flash RPMC container (e.g Fig. 6)

[0046] Fig. 5 illustrates a block diagram of the exemplary container content 311a of an owner container 302 for managing the ownership of an electronic device 101. As in Fig. 5, the container content 311a may be programmed into the OTP memory 110 and may include regions 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 Features 514, and PlatK hash 515. In one example, some or all of the contents of the container 311a may be programmed into the OTP memory 110 during deployment (e.g., by the tester). In the same or another example, part 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 completed. A higher-level firmware (e.g.,other code than the code that created the container) may use a command interface (e.g. Command Memory 171, . Fig. 7) to access or modify information in the Container Content 311a of the Owner Container 302.

[0047] The owner configuration 501 may include the location of the configuration information corresponding to the FMB. The configuration information may be located, for example, in the OTP memory 110, the non-volatile memory 173, or another memory. For example, if the configuration information is located in the OTP memory 110, the container configuration may be an OTP configuration. If the configuration information is located, for example, in the non-volatile memory 173 (e.g., SPI flash), the container configuration may emulate an OTP memory (OTP emulation configuration, which is described in more detail below).

[0048] The owner configuration 501 may include information about who can transfer ownership of the electronic device 101. In one example, the current owner of the silicon may transfer ownership by executing a transfer ownership command signed with the owner's public container command key (CCK). In another example, both the current owner of the silicon and the new owner may transfer ownership.The current silicon owner may transfer ownership to a new owner by executing an ownership transfer command signed with the owner's public CCK, and the new owner may transfer ownership by executing an ownership transfer command signed with an ownership transfer authorization key (OTAK). The OTAK may be a public key programmed into the Owner Container 302 by the current owner (e.g., in the Owner Transfer Authorization Key 504) that allows the new owner (or an approved intermediary entity) to execute an ownership transfer command. The Owner Configuration 501 may include information indicating whether RPMC Owner Container crisis commands are supported.When crisis commands are enabled, an owner can, for example, use the I / O & Port Control 190 (e.g., I2C Crisis Port, UART Crisis Port) to insert owner container commands into the Command Memory 171 (e.g., . Fig. 7). In one example, the crisis commands for the owner container may be disabled by default and enabled by an owner of the electronic device 101 (e.g., by programming the Owner Configuration 501).

[0049] The Owner ID 502 may be a value provided by the owner upon transfer of ownership and used to identify the owner. The Owner RPMC 503 may be a value determined by the Boot Code 140 at the time of the transfer of ownership. For example, it may be the first RPMC value assigned to the owner at the time of the transfer of ownership. In one example, the Owner ID 502 and the Owner RPMC 503 together may indicate a unique owner for a particular electronic device 101. The Owner Transfer Authorization Key (OTAK) 504 may be a one-time programmable ECDSA-384 (Elliptic Curve Digital Signature Algorithm) public key used to verify a transfer of the Ownership Command, e.g., when the configuration information in the Owner Configuration 501 allows a new owner to perform a transfer of the Ownership Command.

[0050] 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), which can be used to decrypt an FMB image stored in the non-volatile memory 173. The hash value 506 of the ECDH public key may be a SHA384 hash value of an ECDH public key, which can be used to derive an AES256 key (KEK), which can be used to decrypt the encrypted private ECDH key 505. In one example, the encrypted private ECDH key 505 and the hash value of the ECDH public key hash 506 can be exchanged according to a Diffie-Hellman key exchange protocol and used to decrypt an FMB image.

[0051] The Key Hash Blob (KHB) hash 507 may be a SHA384 hash of an owner-provided KHB (e.g., stored in Non-Volatile Memory 173), which may include hashes of the individual public keys that may be used to authenticate other data (e.g., the FMB, the RPMC container commands, and others). TAGx Image Key Revocation 508 may indicate whether the public keys in the owner's KHB are available or have been revoked (not available for use). In one example, the KHB hash 507 may include eight (8) public keys, and the TAGx Image Key Revocation 508 may have a bit corresponding to each public key. In this example, if a bit in the TAGx Image Key Revocation 508 is programmed to the value one (1), the corresponding key may be revoked. In one example, the Boot Code 140 may not use a revoked key (e.g.,Boot Code 140 may check whether a corresponding bit in TAGx Image Key Revocation 508 is programmed to the value one (1) before using a key. TAGx Image Rollback Protection 509 may indicate whether a current image revision (e.g., FMB) is available for use or has been revoked (not available for use). In one example, KHB Hash 507 may allow up to 128 image revisions, and TAGx Image Rollback Protection 509 may have a bit corresponding to each revision. In this example, if a bit in TAGx Image Rollback Protection 509 is programmed to the value one (1), the corresponding image revision may be revoked. In one example, Boot Code 140 may not authenticate a revoked image (e.g., before loading an image, Boot Code 140 may check whether a corresponding bit in TAGx Image Rollback Protection 509 is programmed to the value one (1)).

[0052] TAG0 Base Address Pointer 510 can be the base address for the FMB's image header. TAG1 Base Address Pointer 511 can be the base address for the image header of the FMB copy. Debug Support 512 can indicate whether debug (e.g., UART production debug) is supported. Platform ID 513 can contain an identification value for the owner's platform. Security Features 514 can indicate whether the current owner has various security features. In one example, Security Features 514 can indicate whether an image rollback protection feature is enabled (e.g., whether an image revision can be revoked using TAGx Image Rollback Protection 509). In the same or other examples, Security Features 514 can indicate whether a key revocation feature is enabled (e.g., whether a key can be revoked using TAGx Image Key Revocation 508). PlatK Hash 515 can contain a hash (e.g.,SHA384) of a public platform key that can be used to sign crisis commands (e.g., if the Owner Configuration 501 indicates that RPMC Owner Container crisis commands are supported).

[0053] Although Fig. While Figure 5 illustrates various regions of the container content 311a, other example systems may include electronic devices with more or fewer regions. In further examples, certain regions of the container content 311a may include additional functionality to that described above or omit some of the functionality described above.

[0054] Fig. 6 illustrates a block diagram of the exemplary container content 311b of an owner container 302 for managing the ownership of an electronic device 101. As in Fig. 6, the container content 311b can be programmed in the non-volatile memory 173 and can include the regions 501-515 which are Fig. 5 and differ in that they are stored in the non-volatile memory 173 and not in the OTP memory 110. In one example, an owner container 302 whose container content 311b is stored in the non-volatile memory 173 can emulate an owner container stored in the OTP memory 110 (OTP emulation) because the boot code 140 can store configuration parameters (e.g., in the container content 311b) when the owner container is created, and no commands exist for the boot code 140 (or any other code) to modify these parameters. Should a malicious user attempt to modify the secure RPMC owner container 302 while it is stored in the non-volatile memory 173 (e.g., to modify one of the OTP-emulated parameters), the verification of the container will fail.Therefore, the configuration parameters stored in the non-volatile memory 173 in the owner container 302 can be considered as an emulation of the OTP memory.

[0055] In one example, the Container Content 311b may include the PUF Activation Code 621 (e.g., "PUF" refers to physically unclonable functions, which are described in more detail below). The Boot Code 140 may use the PUF Activation Code 621 to generate and propagate the Device Attestation Key(s) (DevAK) to the silicon owner's firmware. In one example, on the first power-on reset cycle after the Owner Container Content 311b is created or updated, the Boot Code 140 may use a shared SRAM PUF to generate the PUF Activation Code 621 and store it in the Owner Container Content 311b. When the Boot Code 140 loads an authentic image (e.g., FMB) during a subsequent boot, the Boot Code 140 may use the PUF Activation Code 621 to generate the DevAK private and public keys. In one example, boot code 140 can convert the DevAK public key to an X.509 certificate and sign the certificate with the private DevIK key (e.g. with the Secret Device Unique Information 207 in . Fig. 2). In examples, the signed certificate can be forwarded to the owner’s firmware along with the PUF Activation Code 621 (e.g. via the firmware mailbox 788 in Fig. 7). The owner's firmware can regenerate the DevAK private key using the PUF Activation Code 621.

[0056] Further examples of the PUF Activation Code 621, the SRAM PUF, the DevAK and DevIK keys and the device certificates are in the Fig. 16-30 and the associated descriptions (section Physically Unclonable Function (PUF) SRAM, below).

[0057] In some examples (not illustrated), the boot code 140 may generate the PUF activation code 621 during manufacturing (e.g., before the owner container 311b is created). According to this example, the boot code 140 may store the PUF activation code 621 in non-volatile memory (e.g., in the non-volatile memory 173) at an address stored in the OTP memory 110. The boot code 140 may store a hash of the PUF activation code 621 in the OTP memory, which can be used to verify the integrity of the PUF activation code 621 when retrieved from the non-volatile memory 173. Accordingly, the boot code 140 may use the PUF activation code 621 to generate the private and public DevAK keys even before the first owner container 311b is created.

[0058] Although Fig. 6 illustrates various regions of the container content 311b, other example systems may include electronic devices with more or fewer regions. In further examples, certain regions of the container content 311b may include additional functionality to that described above or omit some of the functionality described above. Command Interface

[0059] Fig. 7 illustrates an example of a command memory 171. The command memory 171 may comprise rewritable memory (e.g., registers, SRAM) and may include the RPMC container command 782, the boot code mailbox 784, and the firmware mailbox 786. According to one example, the boot code 140 may authenticate and optionally decrypt the FMB from the non-volatile memory 173 (e.g., SPI flash) and then load the FMB into the internal volatile memory 172 (e.g., SRAM) for subsequent execution by the processor 160. For example, the boot code may load the FMB into the internal volatile memory 172 (e.g., SRAM), authenticate the FMB, and optionally decrypt the FMB, which may include one or more images, including the FMC as the first image. In one example, the authenticated and optionally decrypted FMB remains in volatile memory 172 (e.g., SRAM). This binary image can be referred to as the "owner" image.The boot code can then cause the FMC to be executed by processor 160 (e.g., by jumping to the FMC's base address). The FMC can be either a ROM extension (e.g., an authenticated ROM extension in the FMC) or application firmware. An owner's application can communicate with Boot Code 140 or ROM_EXT to request a transfer of ownership or perform another action on its behalf. The application can communicate this action by loading a signed command into Boot Code Mailbox 784, setting the associated command bits in RPMC Container Command 782, and initiating a reset (e.g., a soft reset).

[0060] In the above example, the RPMC Container Command 782 and the Boot Code Mailbox 784 can be used to initiate requests to the RPMC container to be processed by the Boot Code 140. (The Firmware Mailbox 786 can be used by the Boot Code 140 (or ROM EXT) to pass information to the application firmware.) In one example, the Command Memory 171 can be user-accessible, so that code other than the Boot Code 140 (e.g., FMC) can initiate requests for processing by the Boot Code 140. In another example, the Command Memory 171 can be accessed via external hardware (UART interface, I2C interface, etc.), for example, to perform crisis recovery (if the Owner Configuration 501 in the Owner Container 311a / b indicates that RPMC Owner Container crisis commands are supported).

[0061] In one example, 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 additionally include a command field that contains an indication of a particular command that the Boot Code 140 should process. In the same or another example, the Boot Code Mailbox 784 may be programmed with command parameters corresponding to a pending command. In one example, the command parameters stored in the Boot Code Mailbox 784 may be signed, and the Boot Code 140 may authenticate a pending command during the boot process (e.g., a command may be considered a signed command if the parameters stored in the Boot Code Mailbox 784 are signed) before the command is executed. Owner Container Actions

[0062] The following non-exhaustive list of operations 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

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

[0064] This signed command can be called to cause Boot Code 140 to create and program the first signed Owner Container 302 in Non-Volatile Memory 173 (e.g., SPI Flash). Boot Code 140 can 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 can program a bit in OTP Memory 110 (e.g., in RPMC Flash Container Status 208) indicating that a container has been created and then check this OTP bit before executing the CREATE CONTAINER REQUEST command. If the OTP bit is programmed, Boot Code 140 can ignore subsequent CREATE_CONTAINER_REQUEST commands.

[0065] In one example, the CREATE CONTAINER REQUEST command can result in the creation of two identical signed owner containers 302 (e.g., a primary container and a fallback container). These signed containers can be stored in non-volatile memory 173 (e.g., SPI flash).

[0066] In one example, Boot Code 140 sets the OTP bit, indicating that a container has been created, when it verifies that both signed containers have been successfully stored in Non-Volatile Memory 173.

[0067] In one example, boot code 140 may use the command parameters stored in boot code mailbox 784 for the CREATE_CONTAINER_REQUEST command. The command parameters may include a public key for creation of the owner (OCKpub), a command signature signed with the owner's private key for creation of the container (OCKpriv), and other command parameters corresponding to ranges 433-434 and 437-440 in Fig. 4 (Container Header 310) and 501-502 and 505-5 in Fig. 6 (Container Content 311b). Before creating the signed Owner Container 302, Boot Code 140 may verify the command signature with OCKpub. In one example, Boot Code 140 may verify the OCKpub command parameter by calculating its hash and comparing it to the OCKpub hash retrieved from the KHB stored in Non-Volatile Memory 173. (The KHB stored in Non-Volatile Memory 173 may be compared with the KHB hash 507 in OTP Memory 110.) If the verification of OCKpub or the command signature fails, Boot Code 140 may abort execution of the CREATE_CONTAINER_REQUEST command without creating the first Owner Container 302. In one example, Boot Code 140 may save the status of the failed command in Firmware Mailbox 786.

[0068] If the verification was successful, the boot code 140 can create the signed owner container 302. In one example, the boot code 140 can store a successful command status in the firmware mailbox 786. In one example, the boot code 140 can store corresponding command parameters (in the boot code mailbox 784) in the corresponding areas of the container header 310 (areas 433-434 and 437-440 in Fig. 4) and the container content 311b (regions 501-502 and 505-515 in Fig. 5) Save. Boot code 140 can contain the following for the new signed owner container 302: • RPMC Value 431 (and Owner RPMC 503): can be set to zero by default (since this is the first owner container). Boot Code 140 checks whether any bits of the current RPMC Value 202 are set in the OTP memory and, if so, sets them to the first valid non-zero value. • Active Container Version 432: can be set to zero. • Device Serial Number 435: can be set to the value stored in the OTP Serial Number 205. • Owner Transfer Authorization Key 504: can be set to zero by default. • PUF Activation Code 621: Can be set to zero when processing the CREATE CONTAINER REQUEST command. Boot Code 140 can contain PUF Activation Code 621 to create and store in the signed Owner Container 302 after the next power cycle. INCREMENT RPMC REQUEST Command

[0069] This signed command can be called to cause Boot Code 140 to increment the RPMC Value 431 of the primary Owner Container 302 (without changing other container contents). If permitted, Boot Code 140 can retrieve the primary Owner Container 302, increment the RPMC Value 431, and reset the Active Container Version 432 to zero. Boot Code 140 can delete 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, the Boot Code can increment the current RPMC Value 202 in OTP Memory 110, which can revoke the previous containers.

[0070] In one example, boot code 140 may use the command parameters stored in boot code mailbox 784 for the INCREMENT_RPMC_REQUEST command. The command parameters may include a container command public key (CCKpub), an indication of which of the CCK0-CCK3 hashes in Current Owner Container Header 310 region 436 the CCKpub corresponds to, and a command signature signed with the container command private key (CCKpriv). Before incrementing RPMC Value 431, boot code 140 may verify the command signature against CCKpub. In one example, boot code 140 may verify the CCKpub command parameter by calculating its hash and comparing it to the corresponding CCKpub hash (CCK0-CCK3) stored in Current Owner Container Header 310. (The information in Current Owner Container Header 310 can be trusted because Owner Container 302 can be verified by Boot Code 140).If the CCKpub or command signature verification fails, Boot Code 140 can abort the execution of the INCREMENT_RPMC_REQUEST command without incrementing the RPMC value 431. In one example, Boot Code 140 can save the status of the failed command in firmware mailbox 786.

[0071] If the verification is successful, Boot Code 140 can increment the RPMC value 431 as described above. In one example, Boot Code 140 can successfully save a command status to firmware mailbox 786. UPDATE_CONTAINER_ REQUEST Command

[0072] This signed command can 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 example, the specific update performed can be determined by a subcommand parameter of the command parameters stored in Boot Code Mailbox 784 for the UPDATE_CONTAINER_REQUEST command. In one example, the subcommands can include: (1) "Key Revocation and Rollback Protection" and (2) "Transfer Ownership."

[0073] In one example, boot code 140 may use the command parameters stored in boot code mailbox 784 for the UPDATE_CONTAINER_REQUEST command. The command parameters may include a public key signature (CCKpub or OTAKpub), an indication of which of the hashes OTAKpub or CCK0-CCK3 (hashes in region 436 of the Current Owner Container header 310) should be used for verification, and a command signature signed with the private key OTAKpriv or CCKpriv. Before updating the Owner Container 302, boot code 140 may verify the command signature with OTAKpub or CCKpub (whichever is specified for use). In one example, boot code 140 may check the CCKpub command parameter by calculating its hash and comparing it with the corresponding CCKpub hash (CCK0-CCK3) stored in the Current Owner Container header 310.(The information in Current Owner Container Header 310 may be trusted because Owner Container 302 may be verified by Boot Code 140.) In another example, Boot Code 140 may verify the OTAKpub command parameter by comparing it to the Owner Transfer Authorization Key 504 contained in the contents of Current Owner Container Content 311b. If verification of either (1) the selected OTAKpub or CCKpub key or (2) the command signature fails, Boot Code 140 may abort execution of the UPDATE_CONTAINER REQUEST command without modifying Current Owner Container 302 or incrementing the current RPMC Value 202 in OTP Memory 110. In one example, Boot Code 140 may save the status of an unsuccessful command in Firmware Mailbox 786.

[0074] If (1) the verification of both the selected OTAKpub or CCKpub key and the command signature is successful and (2) the subcommand is “Transfer Ownership”, Boot Code 140 can update the signed Owner Container 302. In one example, Boot Code 140 can transfer command parameters (e.g., in Boot Code Mailbox 784) that cover regions 433-434 and 437-440 in Fig. 4 (Container Header 310) and 501-502 and 505-515 in Fig. 6 (Container Content 311b) in the corresponding areas of the Container Header 310 and the Container Content 311b of the updated signed Owner Container 302. The Boot Code 140 can use the following specifications 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: may contain the default value zero. • Device Serial Number 435: can be set to the value stored in the OTP Serial Number 205. • Owner Transfer Authorization Key 504: can be set to zero. • PUF Activation Code 621: Can be set to zero by default when processing the CREATE CONTAINER REQUEST command. Boot Code 140 can include PUF Activation Code 621 to create and store in the signed Owner Container 302 after the next power-on.

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

[0076] If (1) the verification of both the selected OTAKpub or CCKpub key and the command signature is successful, and (2) the subcommand is "Key Revocation and Rollback Protection," Boot Code 140 may process the key revocation and rollback protection request. In one example, Boot Code 140 may update the TAGx Image Key Revocation 508 and / or the TAGx Image Rollback Protection 509 in Container Content 311b of the signed Owner Container 302. In one example, Boot Code 140 may save a command successful status to Firmware Mailbox 786. REPAIR_FALLBACK_CONTAINER _REQUEST Command

[0077] This signed command can be called 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 can delete the fallback container and copy the primary container to the fallback container's location. In one example, Boot Code 140 can include the command parameters for the REPAIR FALLBACK CONTAINER REQUEST command stored in Boot Code Mailbox 784. The command parameters can include a signature of the public key (CCKpub or OTAKpub), an indication of which of the hashes OTAKpub or CCK0-CCK3 (hashes in the Current Owner Container Header 310 Region 436) should be used for verification, and a command signature signed with the private key OTAKpriv or CCKpriv.The boot code can verify the public key signature and the command signature for the REPAIR FALLBACK_CONTAINER REQUEST command using the same mechanisms disclosed for the UPDATE_CONTAINER_REQUEST command (above). If the verification is successful and no errors are detected updating the fallback container, a suitable fallback container can be stored in non-volatile memory 173 (e.g., SPI flash), resulting in a suitable primary and fallback container being stored in non-volatile memory 173, and the boot code 140 can store a successful command status in firmware mailbox 786. If the verification fails or an error is detected, nothing can change (e.g., the primary container in non-volatile memory 173 is still valid and the fallback container is still invalid). In this last example, Boot Code 140 can save the status of a failed command in Firmware Mailbox 786. CRISIS_RECOVERY_REQUEST Command

[0078] This signed command can be called to cause Boot Code 140 to recover from the primary and fallback containers being invalid. This command can be executed, for example, if both containers are invalid. Boot Code 140 can allow the owner to restore a saved copy of a functioning owner container by issuing a crisis command (e.g., RESTORE_OWNER_CONTAINER) via I / O & Port Control 190 (e.g., I2C crisis port, UART crisis port). ENABLE_UNRESTRICTED_TRANSFERS Command

[0079] This signed command can be called to cause boot code 140 to perform the following updates to owner container 302: • Update of Owner Configuration 501 ( Fig. 5) so that both the current silicon owner and a new owner can transfer ownership of the electronic device 101. • Providing the Owner Transfer Authorization Key 504. • Active Container Version 432 ( Fig. 4) increment. • Re-sign Owner Container 302.

[0080] In one example, boot code 140 may use command parameters stored in boot code mailbox 784 for the ENABLE_UNRESTRICTED_TRANSFERS command. The command parameters may include a public key OTAKpub (e.g., for providing the Owner Transfer Authorization Key 504), a public key for signature (CCKpub), an indication of which of CCK0-CCK3 (hashes in region 436 of the Current Owner Container header 310) the CCKpub corresponds to, and a command signature signed with the container command's private key (CCKpriv). Before updating Owner Container 302, boot code 140 may verify the command signature against CCKpub. In one example, boot code 140 may verify the CCKpub command parameter by calculating its hash and comparing it to the corresponding CCKpub hash (CCK0-CCK3) stored in the Current Owner Container header 310.(The information in Current Owner Container Header 310 can be trusted because Owner Container 302 can be verified by Boot Code 140.) If the CCKpub or command signature verification fails, Boot Code 140 can abort execution of the ENABLE_UNRESTRICTED_TRANSFERS command without updating Owner Container 302. In one example, Boot Code 140 can save the status of the failed command in Firmware Mailbox 786.

[0081] If the verification is successful, Boot Code 140 can update Owner Container 302 as described above (e.g., by updating both copies of the container in non-volatile memory (e.g., SPI Flash). In one example, Boot Code 140 can save a successful command status in Firmware Mailbox 786. UPDATE OTAK KEY Command

[0082] This signed command can be called to cause boot code 140 to perform the following updates to owner container 302: • Providing the Owner Transfer Authorization Key 504. • Incrementing the Active Container version 432 ( Fig. 4). • Re-sign Owner Container 302.

[0083] This signed command may allow an intermediary entity having the private key OTAKpriv to effect the above-mentioned updates. In one example, the boot code 140 may ignore this command unless the owner configuration 501 is configured to allow both the current silicon owner and a new owner to transfer ownership of the electronic device 101 (e.g., if unrestricted transfers are enabled).

[0084] In one example, boot code 140 may use the command parameters stored in boot code mailbox 784 for the UPDATE_OTAK_KEY command. The command parameters may include a new public key OTAKpub_new (e.g., for providing the Owner Transfer Authorization Key 504), a public key for signature (CCKpub or OTAKpub), an indication of which of the keys OTAKpub or CCK0-CCK3 (hashes in region 436 of the Current Owner Container header 310) should be used for verification, and a command signature signed with the private key OTAKpriv or CCKpriv. Before updating the Owner Container 302, boot code 140 may verify the command signature with OTAKpub or CCKpub (depending on which is specified for use).In one example, boot code 140 may verify the CCKpub command parameter by calculating its hash and comparing it to the corresponding CCKpub hash (CCK0-CCK3) stored in the current owner container header 310. (The information in the current owner container header 310 may be trusted because the owner container 302 may be verified by boot code 140.) In another example, boot code 140 may verify the OTAKpub command parameter by comparing it to the owner transfer authorization key 504 contained in the contents of the current owner container 311b. If the verification of either (1) the selected OTAKpub or CCKpub key or (2) the command signature fails, boot code 140 may stop execution of the UPDATE_OTAK_KEY command without modifying the current owner container 302. In one example, boot code 140 can save the status of the failed command in firmware mailbox 786.

[0085] If the verification is successful, Boot Code 140 can perform updates to Owner Container 302 as described above (e.g., by updating both copies of the container in non-volatile memory (e.g., SPI Flash)). In one example, Boot Code 140 can save a successful command status to Firmware Mailbox 786. Ownership of the electronic device

[0086] The electronic device 101 may have one or more owners during its lifetime, and each owner can individually customize the images allowed to run on the device. In one example, the OEM may be the first implicit owner (a "no owner" state), and the OEM's configuration may be stored in the OTP memory 110. The OEM may enable the part to support transfer of ownership by setting up the first owner container. The silicon owner may be the entity that controls the keys for code execution, transfer of ownership, and crisis recovery, e.g., corresponding to the currently active (unrevoked) secure RPMC owner container (e.g., the owner container with an RPMC value of 431 corresponding to the current owner RPMC value of 202 in the OTP memory 110). Setting up ownership

[0087] During manufacturing, OTP Memory 110 can be provided with configuration parameters for OEM images, which may include a KHB Hash 507 used to authenticate the OEM images stored in Non-Volatile Memory 173 (e.g., SPI Flash). Other parameters in OTP Memory 110 (e.g., illustrated in Fig. 2 and Fig. 5) can also be provided by the OEM during manufacturing. This state can be referred to as "Legacy Secure Boot." In this state, only the signed OEM images (e.g., FMB) can be authenticated and executed on the electronic device 101.

[0088] The RPMC Owner Container 302 can be created by the OEM using the CREATE_CONTAINER_REQUEST command. The OEM can either use the OTP storage configuration (e.g. Fig. 5) or an owner container configuration (OTP emulation) (e.g. Fig. 6) use.

[0089] The OEM-Owner Container 302 can be created by authentic firmware loaded from the Non-Volatile Memory 173 (e.g., SPI Flash) or by code loaded into the Volatile Memory 172 (e.g., SRAM) via the I / O & Port Control 190 (e.g., I2C Crisis Port, UART Crisis Port). The firmware can use the CREATE_CONTAINER_REQUEST command in the Boot Code Mailbox 784 ( Fig. 7) save, set the RPMC Container Command 782 to indicate a pending request, and perform a reset (e.g. soft reset).

[0090] Fig. 8 illustrates a block diagram of an example of managing ownership of an electronic device 101, including the creation of an initial owner container using OEM-signed images and OTP configuration. The contents of the non-volatile memory 873 (e.g., SPI flash) are shown at time t0 and include: OTP TAG0 / 1 image header base addresses, OTP KHB (primary and fallback), and OTP TAG0 / 1 image headers and images (e.g., FMB). At time t0, there may be no owner of the electronic device 101, although the OEM may be an implicit owner. In one example, at time t1, the OEM application code may write the base addresses of the owner container 0 / 1 (primary and fallback containers) to the non-volatile memory 873.At time t2, the OEM application code stores the CREATE_CONTAINER_REQUEST command in the RPMC Container Command Region in Command Memory 871 and stores the container parameters of the new owner (Owner A) in the Boot Code Mailbox in Command Memory 871. In one example, the parameter corresponding to Owner Configuration Parameter 501 may specify an OTP configuration for Owner A. At time t3, the OEM application code may cause a soft reset of the electronic device 101. During the boot process, Boot Code 140 may notice a pending CREATE_CONTAINER_REQUEST command (e.g., in Command Memory 871) and process this command. At time t4, if the command is successful, Boot Code 140 may write Owner A Container 0 / 1 (primary and fallback containers) to Non-Volatile Memory 873.As illustrated, after time t4, the electronic device 101 may be transferred to Owner A using OTP images. In one example, after time t4, the OEM application may read the status bits of the command from the firmware mailbox 786 (. Fig. 7) to verify the successful completion of the command. The OEM application can optionally read Owner A's containers 0 / 1 from the non-volatile memory 873 and verify the contents. In one example, the OEM application can optionally save a copy of Owner A's container 0 / 1 as a backup.

[0091] Fig. 9 illustrates a block diagram of an example of managing ownership of an electronic device 101, including the creation of a first owner container using OEM-signed images and an OTP emulation configuration. The contents of the non-volatile memory 973 (e.g., SPI flash) are shown at time t0 and include: OTP TAG0 / 1 image header base addresses, OTP KHB (primary and fallback), and OTP TAG0 / 1 images + headers (e.g., FMB). At time t0, there may be no owner of the electronic device 101, although the OEM may be an implicit owner. In one example, at time t1, the OEM application code may write (1) Owner Container 0 / 1 base addresses, (2) Owner A KHB (primary and fallback), and (3) Owner A TAG0 / 1 images + headers (e.g., FMB) to the non-volatile memory 973.At time t2, the OEM application code may store the CREATE_CONTAINER_REQUEST command in the RPMC Container Command Region 971 and place the container parameters of the new owner (Owner A) in the Boot Code Mailbox in Command Memory 971. In one example, the parameter corresponding to Owner Configuration Parameter 501 may specify an OTP emulation configuration for Owner A. At time t3, the OEM application code may cause a soft reset of the electronic device 101. During the boot process, Boot Code 140 may detect a pending CREATE_CONTAINER_REQUEST command and process the command. At time t4, if the command is successful, Boot Code 140 may write Owner A Containers 0 / 1 (primary and fallback containers) to Non-Volatile Memory 973 and begin executing the Owner A image (e.g., TAG0 image).As illustrated, after time t4, the electronic device 101 may become the property of Owner A using Owner A images. In one example, after time t4, the Owner A application may read the status bits of the command from the firmware mailbox 786 (. Fig. 7) to verify the successful completion of the command. Owner A's application can optionally read Owner A's containers 0 / 1 from non-volatile memory 973 and verify the contents. In one example, Owner A's application can optionally save a copy of Owner A's container 0 / 1 as a backup. Boot sequence for electronic device containing RPMC owner container

[0092] Fig. 10 illustrates a flowchart of an example method 1000 for managing ownership of an electronic device, including securely transferring ownership of the electronic device over time. According to one example, the method 1000 may begin at block 1005. In one example, the method 1000 may be executed by the boot code 140. In some examples, the starting block 1005 may represent a time when the electronic device 101 is first powered on (POR) or a time after a reset of the electronic device (e.g., a device reset, reboot, or power failure). Thus, the method 1000 may be executed by the boot code 140 at a time when the OTP memory 110 is not accessible to the user (e.g., because the user code has not yet been loaded).The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Thus, the initialization point for method 1000 and the order of steps 1005-1045 comprising method 1000 may depend on the chosen implementation.

[0093] After a POR or soft reset, the boot code may proceed to block 1010, where it determines whether the OTP memory has been fully deployed. If not, the boot code may proceed to block 1015, configure the electronic device 101 with the OEM configuration, and then proceed to block 1020 and reset the electronic device 101.

[0094] If the boot code determines in block 1010 that the OTP memory is fully configured, it may determine in block 1025 whether the ownership feature is enabled in the OTP memory 110. In one example, this feature may be disabled by default (i.e., at the time of manufacture). If the ownership feature is not enabled, the boot code may proceed to block 1040, where it may load the firmware binary image using the OEM information stored in the OTP memory 110. At block 1040, the OEM may be the implicit owner of the electronic device 101 because only OEM-signed firmware may be loaded and executed (may also be referred to as "Legacy Secure Boot"). In one example, the OEM firmware may enable the ownership feature by issuing the CREATE CONTAINER REQUEST command (e.g., illustrated in Fig. 8 and Fig. 9). If the boot code determines at block 1025 that the owner function is enabled in the OTP memory 110, the boot code may proceed to block 1035, where it determines whether the configuration source for the FMB image is the OTP emulation. If the FMB image configuration source is not the OTP emulation, the image configuration source may be the OTP memory. In this example, the boot code may proceed to block 1040 for Legacy Secure Boot. If the boot code determines in block 1035 that the source for the FNM configuration image is the OTP emulation, the boot code may proceed to block 104, where it may attempt to load the firmware using the RPMC owner container information stored in the non-volatile memory 173 (e.g., SPI flash). In one example, block 1045 may represent a secure boot process that includes RPMC owner containers stored in non-volatile memory 173.

[0095] Although Fig. 10 discloses a certain number of operations in connection with the method 1000, the method 1000 may be implemented with more or fewer operations than those described in Fig. 10 shown. Even if Fig. 10 has a particular order of operations with respect to the method 1000, the operations comprising the method 1000 may be performed in any suitable order. Transfer of ownership of an electronic device

[0096] In one example, an OEM may be the initial owner of the silicon (e.g., the owner of electronic device 101). However, the owner may change one or more times over the device's lifetime. The owner is the entity that establishes the keys used to authenticate the FMB images. The transfer of ownership may involve changing the entity responsible for establishing the FMB signing keys.

[0097] In one example, an owner may choose to deploy RPMC Owner Container 302 either with the OTP configuration (using OEM images) (e.g. Fig. 5) or an owner-defined configuration (using Owner Images) (e.g. Fig. 6). New Owner Containers 302 can be created using authentic firmware loaded from the Non-Volatile Memory 173 (e.g., SPI Flash) or via the I / O & Port Control 190 (e.g., I2C Crisis Port, UART Crisis Port) by executing the UPDATE_CONTAINER_REQUEST command to transfer ownership. According to one example, this command can be supported if the current owner allows unrestricted ownership transfers by executing the ENABLE_UNRESTRICTED_TRANSFERS command.

[0098] In some examples, there may be three types of transfers of ownership: • The current owner carries out the transfer to the new owner. • A trusted intermediary entity performs the transfer to the new owner (unrestricted transfers). • The current owner allows the new owner to claim ownership (unrestricted transfers).

[0099] Using their CCK keys, the current owner of the electronic device 101 can transfer ownership to a new owner if the new owner is willing to provide their information to the current owner. In another example, the current owner can use their CCK keys to restore the system to the OEM / refurbished state. This latter type of transfer can be simplified if the OEM images and configuration information are retained in non-volatile memory 173 (e.g., SPI flash). In one example, the boot code 140 can load the OEM images only if the current owner transfers ownership to use the OEM images.

[0100] The Owner Transfer Authorization Key (OTAK) can support a one-time transfer of ownership to a new owner without providing the new owner's information to the current owner. With OTAK transfer (also known as "unrestricted transfer"), the new owner can upload their data and complete the ownership transfer as long as the current owner has enabled OTAK transfer. The OTAK ownership transfer can be completed whether or not the new owner is present at the time the current owner hands over the device.

[0101] Fig. 11 and Fig. 12 illustrate block diagrams of two examples of managing the ownership of an electronic device 101 using unrestricted transfer and OTAK. As in Fig. As illustrated in Figure 11, the current owner (CO) wishes to transfer ownership of Machine A to a new owner (NO). In one example, the current owner may rely on a trusted intermediary entity (TIE) (e.g., a distribution channel) to assist in transferring ownership to the new owner. During the transfer, for example, the following events (1-8) may occur. 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 confirm that they received the correct device (e.g., Machine A). 2-TIE can send the OTAKpubl key to CO. The OTAKpubl key can be a public key of a public-private key pair owned by TIE. 3-CO can execute the ENABLE_UNRESTRICTED_TRANSFERS command, passing OTAKpubl key as the new OTAK public key for machine A. 4-CO can send machine A to TIE. 5 - NO can send OTAKpub2 keys to TIE. The OTAKpub2 key can be one of a public-private key pair owned by NO. 6 - TIE can execute the UPDATE OTAK_KEY command, passing the key OTAKpub2 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 private key OTAKpriv1. TIE can use the I / O & Port Control 190 (e.g., I2C Crisis Port, UART Crisis Port) to insert the UPDATE_OTAK_KEY command into the Command Memory 171 (e.g., Fig. 7). 7 -TIE can send machine A to NO. 8 - NO can execute UPDATE_CONTAINER_REQUEST with the "Transfer Ownership" subcommand. Since UPDATE_CONTAINER_REQUEST is a signed command, NO can sign the command with NO's private key OTAKpriv2. NO can use the I / O & Port Control 190 (e.g., I2C Crisis Port, UART Crisis Port) to insert the UPDATE_CONTAINER_REQUEST command into the Command Memory 171 (e.g., Fig. 7).

[0102] Although in Fig. 11 a certain number of events is shown in connection with an unrestricted transfer of ownership, this type of transfer can be carried out with more or fewer events than in Fig. 11. For example, CO cannot send the serial number to either TIE or NO. Even if Fig. 11 shows a specific sequence of events, the events can be executed in any order.

[0103] As in Fig. As illustrated in Figure 12, the current owner (CO) may want to transfer ownership of Machine B to a new owner (NO). In one example, the transfer may occur via an untrusted intermediate entity (UIE), which assists in transferring ownership to the new owner. In one example, 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 it has received the correct device (e.g., Machine B). 2 - NO can send the OTAKpub3 key to CO. The OTAKpub3 key can be a public key of a public-private key pair owned by NO. 3-CO can execute the ENABLE_UNRESTRICTED_TRANSFERS command, passing OTAKpub3 key as the new OTAK public key for machine B. 4 - CO can send machine B to UIE. Note that UIE is not allowed to take ownership or execute commands on machine B because UIE does not have access to OTAKpriv3. 5 - UIE may forward machine B to NO (as is). 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 its OTAKpriv3 private key. NO can use the I / O & Port Control 190 (e.g., I2C Crisis Port, UART Crisis Port) to insert the UPDATE CONTAINER REQUEST command into the Command Memory 171 (e.g., Fig. 7).

[0104] Although in Fig. 12 a certain number of events is shown in connection with an unrestricted transfer of ownership, this type of transfer can be carried out with more or fewer events than in Fig. 12. For example, CO cannot send the serial number to NO. In another example, CO can send machine B directly to NO without the need for an intermediary entity. Even if in Fig. 12 a specific sequence of events is shown, the events can be executed in any order.

[0105] As in Fig. 11 and Fig. As illustrated in Figure 12, if an intermediary entity is required and the owner of the end device is unknown, each temporary owner can have their own OTAK key. If an intermediary entity is required and the final owner is known, the final owner can provide their public OTAK key to prevent the intermediary entities from taking ownership or altering the OTAK key. The current owner can retain ownership until the ownership transfer is complete. This allows the current owner to resolve any issues that arise during the ownership transfer.

[0106] In one example, there are six scenarios for transferring ownership of the electronic device 101: Direct transfer of ownership using the current owner's CCK key and the FMB configuration = OTP ( Fig. 13). Direct transfer of ownership using the current owner's CCK key and FMB configuration = OTP emulation. Direct transfer of ownership using the new owner's OTAK key and FMB configuration = OTP. Direct transfer of ownership using the new owner's OTAK key and FMB configuration = OTP emulation. Indirect transfer of ownership using an intermediary entity, an OTAK key and an FMB configuration = OTP. Indirect transfer of ownership using an intermediary entity, OTAK keys and FMB configuration = OTP emulation.

[0107] In an example where the ownership transfer was successful, the new owner can load and execute code via I / O & Port Control 190 (e.g., a Crisis port). This loaded code can be used to update the SPI flash images. Transmission with CCK keys

[0108] Fig. 13 illustrates a block diagram of an example of managing ownership of an electronic device 101, including transferring ownership using the current owner's CCK key and the FMB configuration = OTP. The contents of the non-volatile memory 1373 (e.g., SPI flash) are shown at time t0 and include: OTP TAG0 / 1 image header base addresses, OTP KHB (primary and fallback), OTP TAG0 / 1 image headers and images (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 the electronic device 101. The new owner may provide its configuration parameters to the current owner, and the current owner may sign the parameters of the UPDATE_CONTAINER_REQUEST command (“Transfer Ownership” subcommand) for the new owner with the current owner's CCK key (e.g., with an external hardware security module).In one example, 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 the electronic device 101 can cause it to enter crisis recovery mode. At time t2, either the new owner or the old owner can use the crisis port (e.g., I2C, UART) to send the signed UPDATE_CONTAINER_REQUEST command. At time t3, if the command is successful, the boot code 140 can write the Owner B containers 0 / 1 (primary and fallback containers) to non-volatile memory 1373. As illustrated, after time t3, the electronic device 101 can be owned by Owner B using OEM OTP images.

[0109] Fig. Figure 13 illustrates the transfer of ownership using the current owner's CCK key and the FMB configuration = OTP. The process can be similar when FMB configuration = OTP emulation. With OTP emulation, after issuing the UPDATE_CONTAINER_REQUEST, the owner can use the Crisis port to copy the loader code image and the KHB of the new owner into the volatile memory 172 (e.g., SRAM ( Fig. 1)). If the load is successful (t3), Boot Code 140 can write Containers 0 / 1 (Primary and Fallback Containers) of Owner B to Non-Volatile Memory 1373 and jump to the new owner's loader code. The new owner's loader code can then write signed images and KHB (Primary and Fallback) to Non-Volatile Memory 1373 (e.g., SPI Flash).

[0110] The general procedure for transferring ownership using CCK keys may include: • The new owner can provide its owner configuration parameters to the current owner. • The current owner can sign the parameters for transferring ownership for the new owner. • (optional) The current owner can enable crisis mode for restricted signing. • (optional) The current owner can delete his images and KHB (if applicable). • The electronic device can be switched off and physically transferred to the new owner or trusted intermediary entity. • The new owner can issue the transfer of ownership command via the Crisis Port. • (for OTP emulation) The new owner can use the Crisis port to load the new owner's code image and KHB, which then writes signed images and KHB (primary and fallback) to non-volatile memory. Procedure for transmission with OTAK keys

[0111] Examples of transferring ownership using the OTAK key are shown above in Fig. 11 and Fig. 12. The general procedure for transferring ownership using OTAK keys may include the following: • The new owner or trusted intermediary entity can generate a public / private ECDSA-384 key pair. • The ECDSA public key 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 in the owner container and enable unrestricted transfer of ownership using the ENABLE_UNRESTRICTED_TRANSFERS command. • (optional) The current owner can write new owner images and KHB to the flash. • (optional) The current owner can delete his images and KHB. • The machine can be turned off and physically transferred to the new owner or trusted entity. • (optional) if a trusted intermediary entity is used, execute (via the Crisis port) the UPDATE_OTAK_KEY or UPDATE_CONTAINER_REQUEST command (with the Transfer Ownership subcommand) using the OTAK key of the intermediary entity. • The new owner can execute (via the Crisis port) the UPDATE_CONTAINER_REQUEST command (with the "Transfer Ownership" subcommand). • (for OTP emulation) The new owner can use the Crisis port to load the new owner's loader code image and KHB, which will write signed images and KHB (primary and fallback) to non-volatile memory.

[0112] If the transfer ownership command is successful, the new owner can load and execute the code through the same Crisis port. Locating owner containers

[0113] In one example, Boot Code 140 can be assigned, by default, the first 16 bytes in the SPI flash memory of component 0 (e.g., the first flash memory component accessed during the boot sequence) for the boot ROM's address pointer table. This 16-byte address pointer table is potentially relocatable. The table can be used to locate owner images and can be reordered in OTP memory. The location of the primary RPMC owner container base address and the fallback RPMC owner container base address can be located in the last 8 bytes of the address pointer table. RPMC value in OTP storage and owner containers

[0114] In one example, the current RPMC value 202 in the OTP memory 110 may match the RPMC value 431 in the container header 310 of the current owner container 302. During updates (e.g., during the UPDATE_CONTAINER_COMMAND request), the RPMC value 431 in the container header 310 may be incremented by one, indicating that a container update is in progress. If the update is successful, the current RPMC value 202 in the OTP memory 110 may be incremented to match the RPMC value 431 in the updated container header 310. Procedure for transferring ownership

[0115] Fig. 14 illustrates a flowchart of an exemplary method 1400 for managing ownership of an electronic device, including securely transferring ownership of the electronic device over time. According to one example, method 1400 may begin at block 1410. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 1400 and the order of blocks 1410-1430 comprising method 1400 may depend on the chosen implementation.

[0116] At block 1410, for an electronic device having one-time programmable (OTP) memory and non-volatile memory, the method 1400 may use the information stored in the OTP memory to authenticate code associated with an implicit owner of the electronic device. At block 1415, the method 1400 may receive a first request to create an owner container from the authenticated code associated with the implicit owner of the electronic device. At block 1420, in response to the first request to create an owner container, the method 1400 may create a first owner container, wherein the first owner container includes a first signed data image associated with the first owner of the electronic device.At block 1425, the method 1400 may store the first owner container in non-volatile memory. At block 1430, the method 1400 may use the first signed data image associated with the first owner of the electronic device to authenticate the first executable code associated with the first owner of the electronic device. In one example, the method 1400 may use configuration information and secret information from the signed data image associated with the first owner of the electronic device to authenticate the first executable code associated with the first owner of the electronic device.

[0117] Although Fig. 14 discloses a certain number of operations with respect to the method 1400, the method 1400 may be implemented with more or fewer operations than in Fig. 14. For example, the method 1400 may additionally authenticate the request of the first owner of the container with a public key. In another example, the method 1400 may be executed after block 1430 with additional Fig. 15 illustrated operations. Even if Fig. 14 shows a particular order of operations with respect to method 1400, the operations comprising method 1400 may be performed in any suitable order.

[0118] Fig. 15 illustrates a flowchart of an exemplary method 1500 for managing ownership of an electronic device, including securely transferring ownership of the electronic device over time. According to one example, method 1500 may begin at block 1510. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 1500 and the order of blocks 1510-1550 comprising method 1500 may depend on the chosen implementation.

[0119] According to one example, blocks 1510-1530 (dashed outlines) may be the same as blocks 1410-1430 in Fig. 14. At block 1535, the method 1500 may authenticate a signed transmission of the ownership command using a key stored in the first owner container. At block 1540, in response to successfully authenticating the signed transmission of the ownership command, the method 1500 may create a second owner container for a second owner of the electronic device, the second owner container including a second signed data image associated with the second owner of the electronic device. At block 1545, the method 1500 may store the second owner container in the non-volatile memory. At block 1550, the method 1500 may revoke the first owner container. According to one example, revoking the first owner container includes programming a bit in the OTP memory that includes the second owner container.At block 1555, the method 1500 may use the second signed data image associated with the second owner of the electronic device to authenticate the second executable code associated with the second owner of the electronic device.

[0120] Although Fig. 15 discloses a certain number of operations in connection with the method 1500, the method 1500 may be implemented with more or fewer operations than in Fig. 15. Even if Fig. 15 has a particular order of operations with respect to method 1500, the operations of method 1500 may be performed in any suitable order.

[0121] Methods 1000, 1400, and 1500 may be performed with system 100 or another system operable to perform methods 1000, 1400, and 1500. Although the examples have been described above, other variations and examples may be derived from this disclosure without departing from the spirit and scope of these disclosed examples. Physically Unclonable Function (PUF) SRAM

[0122] In some examples of the present disclosure, the SRAM Physical Unclonable Function (PUF) may be used to generate and propagate a device attestation key (DevAK) from the boot code 130 to the first mutable code (FMC) without exposing the private key or the SRAM PUF key material. Unlike a device that uses an OTP memory for DevAK keys, the SRAM PUF may enable the generation of unique device keys for a specific application without exposing the private key. In examples, the keys derived from the SRAM PUF may not be stored in the chip's non-volatile memory (e.g., OTP memory 110, non-volatile memory 173, or other non-volatile memory), so that when the SRAM is powered off, no keys are present on the chip.For example, the SRAM PUF can be used to generate a device identity key (DevIK), so that the DevIK key does not need to be stored in the OTP Memory 110 (e.g., DevIK cannot be stored in the Secret Device Unique Information 207 (. Fig. 2). In the same or another example, the SRAM memory may be "secret" when powered, so that FMC cannot access it directly (e.g., the result of a read-write lock, as described in the next paragraph).

[0123] Fig. 16 shows an example of a volatile memory 172, e.g., an SRAM, which may include (a) general SRAM regions 1602, (b) ROM_PUF region 1604, and (c) shared PUF region 1606 / 1608 (SHD_PUF). SHD_PUF region 1606 / 1608 may be shared by both boot code 140 and application code, e.g., for cryptographic key management. SHD_PUF region 1606 may be used as a PUF silicon fingerprint, and SHD_PUF region 1608 may be PUF state information. In one example, SRAM 172 may be read and write locked, such that, in the locked state, areas of SRAM 172 are accessible by boot code 140 while simultaneously being inaccessible by application code (e.g., controller firmware or FMC). In one example, boot code 140 may have full access to ROM_PUF region 1604, while application code (e.g.The application code (e.g., the controller firmware) does not have access to ROM_PUF region 1604 because this area is read-only. In the same or other examples, Boot Code 140 may have full access to SHD_PUF region 1606 / 1608. Application code (e.g., the controller firmware) may have limited access to SHD_PUF region 1606 / 1608. For example, application code (e.g., FMC) may have access to region 1608 of SHD_PUF region 1606 / 1608, but not to region 1606 of SHD_PUF region 1606 / 1608 because this area is read-only. In one example, region 1608 of the SHD_PUF region 1606 / 1608 may be addressed by the application code (FMC) and may contain some SRAM PUF state data (e.g., which may be used by the PUF Application Programming Interface (API)), but no information from which the device secrets can be derived.In contrast, region 1606 of the SHD_PUF region 1606 / 1608 (which is not accessible to application code) may contain SRAM PUF key material (e.g., the silicon fingerprint of the electronic device).

[0124] In some examples, the boot code 140 (e.g., immutable boot code or authenticated mutable boot code) may include SRAM PUF functions to support, for example, anti-aging, error correction, random extraction, privacy amplification, and security countermeasure techniques. The SRAM PUF functions may be integrated into the SRAM PUF API. In some examples, one or more of the SRAM PUF functions (e.g., error correction and privacy amplification) may be used to generate a uniformly random key based on the silicon fingerprint of the SRAM PUF. In one example, this process of using the SRAM PUF functions to generate a uniform random key may be referred to as "enrolling" the SRAM PUF. In some examples, the SRAM PUF may be enrolled in a first power cycle. This may result in the generation of the PUF Activation Code 621 ( Fig. 6) which is stored in the Container Content 311b of the Owner Container 302 ( Fig. 3). In one example, the SRAM PUF enrollment may be based on the current owner of the silicon (e.g., on the Owner ID 502, the Owner RPMC 503, or another value unique to the current owner), so that the uniformly random key is unique to the current owner of the silicon. The SRAM PUF functions may then use the PUF Activation Code 621 to regenerate the same random key generated during enrollment (e.g., after a second power cycle). While the PUF Activation Code 621 is not secret, its integrity may be maintained (e.g., as an emulated OTP parameter, as in Fig. 6).

[0125] Fig. 17 illustrates a flowchart of an example method 1700 for SRAM PUF registration and subsequent key reconstruction. According to one example, the method 1700 may begin at block 1705. In one example, the method 1700 may be executed by boot code 140. For simplicity, we use the term boot code 140 as execution of functions, which is to be understood as the boot code 140 being read by the processor 160 and causing the processor 160 to execute the corresponding functions. In some examples, the starting block 1705 may represent a time when the electronic device 101 is first turned on (i.e., power-on reset (POR)) or a time after a reset of the electronic device (e.g., a device reset, a reboot, or a power cycle). Thus, the method 1700 may be performed by boot code 140 at a time when volatile memory 172 (e.g.,SRAM with ROM_PUF and SHD_PUF regions) may not have access by the FMC (e.g., because the FMC has not yet been authenticated and loaded). The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 1700 and the order of steps 1705-1745 comprising method 1700 may depend on the chosen implementation.

[0126] After a POR or soft reset, boot code 140 may proceed to block 1710, where it determines whether the SRAM PUF has been enrolled. In one example, boot code 140 may determine that the SRAM PUF has not been enrolled if it determines that this is the first power cycle or reset cycle after a change of ownership of electronic device 101 (e.g., an ownership change status bit may be set, or the PUF Activation Code 621 in Owner Container Content 311b is not set (e.g., all zeros), or some other indication). If the SRAM PUF has not been enrolled, boot code 140 may proceed to block 1715, where it may determine whether this is the first power cycle after a POR (Power On Reset). If so, boot code 140 may proceed to block 1720 and enroll the SRAM PUF.In one example, enrollment may include using the SRAM PUF's unique silicon fingerprint to create (1) a uniformly random cryptographic key, (2) a KeyCode corresponding to the key, and (3) a PUF activation code corresponding to the SRAM PUF's current cryptographic context. In one example, enrollment may be based on the current owner of the silicon (e.g., the Owner ID 502, the Owner RPMC 503, or another value unique to the current owner) such that the uniformly random key is unique to the current owner of the silicon. In one example, boot code 140 may perform these tasks using the SRAM PUF API (e.g., SRAM PUF functions) such that the private cryptographic key cannot be extracted by other boot codes or the FMC (e.g., the private key may only be known to the SRAM PUF API).

[0127] Boot code 140 may then proceed to block 1725 and store the PUF activation code in the secure RPMC Owner Container 302 containing the current owner of the electronic device 101 (e.g., as PUF Activation Code 621). In one example, block 1725 may be considered part of the enrollment process.

[0128] In one example, the enrollment process may provide a unique PUF Activation Code 621 to different owners of the electronic device 101. For example, the DevAKpriv key may be generated depending on the current owner of the electronic device 101. This, in turn, may provide a unique (and random) cryptographic context (e.g., a unique DevAK key) to different owners. In examples, the unique PUF Activation Code 621 may be generated as a function of the current owner by the boot code on the first power cycle after a 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 functions to regenerate / recreate the previous cryptographic context (e.g., to regenerate the same DevAK key).By providing different PUF activation codes to different owners of the electronic device 101, the enrollment process can provide each owner with different cryptographic contexts. This prevents a subsequent owner from discovering the previous owner's cryptographic context or the previous owner's secrets.

[0129] After Boot Code 140 has stored the PUF activation code in the secure RPMC owner container in block 1725, Boot Code 140 can proceed to block 1730, where it stores the KeyCode generated in block 1720 in firmware mailbox 786 ( Fig. 7). The boot code 140 may then proceed to block 1740, where it may set the status of the firmware mailbox 786. In one example, this status may be information stored in the firmware mailbox 786, such as register bits, and it may indicate whether other information is stored in the firmware mailbox 786 (e.g., the DevAK KeyCode 1922 in Fig. 19) are valid. In one example following enrollment after a POR, boot code 140 may set the status indicating that the key code stored in block 1730 is valid. Boot code 140 may then proceed to block 1745, where it may authenticate the FMC (e.g., the firmware) and load it into SRAM (e.g., where it may be executed by processor 160). In one example, the FMC may thereafter execute in the cryptographic context created by the enrollment process and access the key code stored in firmware mailbox 786. Examples of using the key code are described in connection with the Fig. 18-30 described below.

[0130] If Boot Code 140 determines at block 1715 that this is not the first power cycle after a POR, Boot Code 140 may proceed to block 1740, where it may set the status of Firmware Mailbox 786 to indicate that the KeyCode (e.g., the DevAK KeyCode 1922 in Fig. 19) is not valid. Boot code 140 can then proceed to block 1745, where it can authenticate the FMC (e.g., the firmware) and load it into SRAM (e.g., where it can be executed by processor 160).

[0131] If the boot code 140 determines at block 1710 that the SRAM PUF has been enrolled, the boot code 140 may proceed to block 1735, where it may start a known cryptographic context by using the PUF Activation Code 621 corresponding to the current owner of the electronic device 101 and the unique silicon fingerprint of the SRAM PUF to regenerate (1) the uniformly random cryptographic key and (2) the KeyCode corresponding to the key. The boot code 140 may then proceed to block 1730, where it stores the KeyCode generated in block 1735 in the firmware mailbox 786 ( Fig. 7). Boot Code 140 can proceed to block 1740, where it can set the status of firmware mailbox 786 to indicate that the KeyCode (e.g., DevAK KeyCode 1922 in Fig. 19) is valid. The boot code 140 may proceed to block 1745, where it may authenticate the FMC (e.g., the firmware) and load it into SRAM (e.g., where it may be executed by the processor 160). The FMC may then execute in the cryptographic context established by the boot code 140 (i.e., it corresponds to the PUF Activation Code 621—the same cryptographic context established by the enrollment process for the current owner of the electronic device 101) and may access the key code stored in the firmware mailbox 786. Examples of using the key code will be described in connection with the Fig. 18-30 described below.

[0132] Although Fig. 17 discloses a certain number of operations with respect to the method 1700, the method 1700 may be implemented with more or fewer operations than in Fig. 17. For example, boot code 140 after block 1725 may sign the secure RPMC owner container as described above in the description of container signature 312 ( Fig. 3). Signing the owner's container at this time can ensure that the PUF Activation Code 621 can only be modified by Boot Code 140, thus preserving its integrity. As another example, Boot Code 140 can lock the read / write lock on SRAM 172 ( Fig. 16) so that application code (e.g., FMC) can have access to region 1608 of the SHD_PUF region 1606 / 1608, but cannot have access to region 1606 of the SHD_PUF region 1606 / 1608. In some examples, Boot Code 140 can set the read / write lock for SHD_PUF region 1606 on all exit events, so that no user code (e.g., FMC) can access the secret SRAM PUF key material. Although Fig. 17 discloses a particular order of operations with respect to method 1700, the operations comprising method 1700 may be performed in any suitable order.

[0133] Fig. Figure 18 shows an example electronic device 1801 that can respond to the GET_ATTESTATION and GET_CERTIFICATE commands of the Secure Protocol Data Model (SPDM). SPDM is published by the Distributed Management Task Force. Some examples conform to the SPDM specification, which provides the following: "Runtime authentication is the process by which an authentication initiator or requestor interacts with a responder in a running system. The authentication initiator can retrieve the responder's certificate chains and send a unique challenge to the responder. The responder uses the private key to sign the challenge. The authentication initiator verifies the signature with the responder's public key and any intermediate public keys within the certificate chain, using the root certificate as a trusted anchor."

[0134] The electronic device 1801 may, for example, include the boot code 1840 (e.g., immutable boot code or authenticated modifiable code) and SRAM 1872. SRAM 1872 may include firmware mailbox 1886 (may include an instance of firmware mailbox 786 ( Fig. 7) and FMC 1820 (which can act as an SPDM responder). The SRAM 1872 can also include SHD_PUF region 1816 / 1818 and ROM_PUF region 1814, which are instances of SHD_PUF region 1606 / 1608 and ROM_PUF region 1604 ( Fig. 16) (e.g., it may be lockable for reading and writing, and FMC 1820 may have access to SHD_PUF region 1818, but not to SHD_PUF region 1816 or ROM_PUF region 1814). Initiator 1821 may be external to electronic device 1801 and act as an SPDM requestor. In one example, initiator 1821 may communicate with electronic device 1801 via an I2C communication interface.

[0135] In one example, boot code 1840 can enroll the SHD_PUF as key material for the DevAK key and the ROM_PUF as key material for the DevIK key. In one example, the boot code can 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 key can only be known to the SRAM PUF API). After enrolling SHD_PUF and ROM_PUF, boot code 1840, acting as the Root 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 KeyCodes from SHD_PUF (via SRAM PUF API call(s)) and DevIKpub from ROM_PUF (via SRAM PUF API call(s)).(Further details on generating the DevAK certificate can be found in . Fig. 19 and the associated description provided below.) In one example, FMC can access the information stored in the firmware mailbox 1886, e.g., the DevAK KeyCode.

[0136] In one example, the initiator 1821 can send an SPDM GET_ATTESTATION request to the FMC 1820 over the I2C interface. To respond, the FMC 1820 may need to return the request signed with the DevAKpriv key. However, the DevAKpriv key can be kept secret in the SHD_PUF and is not directly accessible to the FMC 1820. In the illustrated example, the FMC 1820 can provide the data to be signed and the DevAK key code to the SHD_PUF 1816 / 1818 (e.g., via SRAM PUF API calls) and receive the data signed with the DevAKpriv key in return. The SRAM PUF API can use the DevAK key code to derive the DevAKpriv key. This allows FMC 1820 to sign the GET_ATTESTATION challenge with the DevAKpriv key derived using SHD_PUF 1816 / 1818 and the DevAK KeyCode, even if the DevAKpriv key is not visible (or directly accessible) to FMC 1820. FMC 1820 can then send the signed challenge to Initiator 1821.

[0137] In another example, initiator 1821 may send an SPDM GET_CERTIFICATE request to FMC 1820 over the I2C interface. In some examples, FMC 1820 may respond by transmitting an X.509 certificate of the device, which may be the device attestation certificate (DevAKcert). In other examples, FMC 1820 may respond by sending an X.509 certificate chain, which may include the device identity certificate (DevIKcert) and the device attestation certificate (DevAKcert).

[0138] Fig. 19 shows an example of an electronic device 1901 according to the present disclosure. The electronic device 1901 may include boot code 1904, firmware mailbox 1986, PUF engine 1955, ROM_PUF 1985, SHD_PUF 1999, and FMC 1920. The boot code 1940 may be an immutable boot code stored in the ROM 130 ( Fig. 1) or an authenticated changeable code stored, for example, in the Non-Volatile Memory 173 ( Fig. 1). The PUF engine 1955 may include code that causes a processor to perform functions, including, but not limited to, the SRAM PUF API functions. In one example, the PUF engine 1955 code may be immutable code stored in the ROM 125 ( Fig. 1). The firmware mailbox 1986 can be an area in the Command Memory 171 ( Fig. 7), which may be volatile SRAM. ROM PUF 1985 and SHD_PUF 1999 may be read- and write-lockable regions in non-volatile SRAM 172 ( Fig. 16). FMC 1920 can be authenticated modifiable code, such as firmware or application code, which can act as an SPDM responder (e.g. similar to FMC 1820 in Fig. 18).

[0139] As illustrated, the ROM_PUF 1985 and SHD_PUF 1999 regions may be directly accessible by the PUF Engine 1955 (SRAM PUF APIs), but not directly by the FMC 1920. For example, the FMC 1920 cannot read or write to the SHD_PUF Region 1999 portion of the key material because this region may be read-write locked. However, the FMC 1920 can call SRAM PUF API functions of the PUF Engine 1955, and these functions can access the SHD_PUF secrets, e.g., to sign data provided by the FMC 1920 with the DevAKpriv key. In one example, the PUF Engine and the SRAM PUF API may be designed so that the SHD_PUF (or ROM_PUF) secrets are not passed to the FMC 1920 or, in some examples, to the Boot Code 1940. For example, the SRAM PUF API functions cannot allow the FMC 1920 to read the secrets, and they cannot return them as a result of function calls to the FMC 1920.

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

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

[0142] Action 1 may represent boot code 1940, which requests the initialization of the SRAM PUF (e.g., ROM PUF, SHD_PUF). In one example, the initialization request may be a request to enroll the SRAM PUF after detecting that the SRAM PUF has not been enrolled following a change of ownership (block 1710 in Fig. 17) and start the new cryptographic context associated with the new owner. In another example, the initialization request may be a request to start a known cryptographic context for the current owner of the electronic device (block 1725 in Fig. 17). The known cryptographic context can be based, for example, on the current owner's PUF Activation Code 621 (the activation code can be passed as part of the function call to the PUF Engine 1955). In some examples, the initialization request can be directed to ROM_PUF 1985. In other examples, the initialization request can be directed to SHD_PUF 1999.

[0143] Action 2 may represent Boot Code 1940, which requests the generation (or regeneration) of the DevAKpriv key based on the current cryptographic context. The request may cause the PUF Engine 1955 to use the secret key information in SHD_PUF 1999 to generate the DevAKpriv key based on the current cryptographic context (e.g., a context started by a previous SRAM PUF initialization request). In one example, the PUF Engine 1955 may return a DevAK KeyCode corresponding to the DevAKpriv key. In another example, Action 2 may represent Boot Code 1940, which requests the generation (or regeneration) of the DevAKpriv key based on the current cryptographic context.The request may cause the PUF Engine 1955 to use the secret key information in ROM_PUF 1985 to generate the DevIKpriv key based on the current cryptographic context (e.g., a context initiated by a previous SRAM PUF initialization request). In one example, the PUF Engine 1955 may return a DevIK KeyCode corresponding to the DevIKpriv key.

[0144] Action 3 can represent that Boot Code 1940 requests the DevAKpub Key or the DevIKpub Key. Since the public key of the key pair is not secret, PUF Engine 195 can disclose the public key to Boot Code 1940 (e.g., return the public key to Boot Code 1940 so that Boot Code 1940 can use the key). In one example, Boot Code 1940 provides PUF Engine 195 with the KeyCode corresponding to the requested public key (e.g., DevAK KeyCode or DevIK KeyCode).

[0145] Action 4 can represent that the Boot Code 1940 requests the DevAKpriv KeyCode or the DevIKpriv KeyCode. This KeyCode can be used in subsequent signing requests to the PUF Engine 1955 (e.g., FMC requesting the signing of an SPDM attestation request with DevAKpriv, as in Fig. 18).

[0146] Action 5 can represent the boot code 1940, which requests the signing of data with either the DevIKpriv key or the DevAKpriv key. In one example, the boot code can send the data to be signed and the corresponding key code to the PUF engine 1955. The PUF engine 1955 can return the data signed with the corresponding key.

[0147] Action 6 can represent Boot Code 1940, which generates the certificate DevAK Cert 1976. In examples, DevAK Cert 1976 can contain the DevAKpub Key as an object (e.g., obtained from PUF Engine 1955 in Action 3). DevAK Cert 1976 can be signed with DevIKpriv (e.g., Boot Code 1940 can send unsigned certificate data along with the DevIK KeyCode to PUF Engine 195 for signing in Action 5).

[0148] Action 7 can represent that the boot code 1940 stores the signed DevAK Cert 1976 in the firmware mailbox 1986 and thus makes it available to the FMC 1920.

[0149] Action 8 can represent the boot code 1940 storing the DevAK key code 1922 in the firmware mailbox 1986, thus making it available to the FMC 1920. (The boot code can obtain the DevAK key code 1922 from the PUF engine 1955 in action 4.)

[0150] Action 9 can represent that Boot Code 1940 stores the signed DevIKpub 1924 in Firmware Mailbox 1986 and thus makes it available to FMC 1920. (Boot Code 1940 can obtain the DevIKpub key from PUF Engine 1955 in Action 3.)

[0151] Action 10 can represent that FMC 1920 reads the signed DevAK Cert 1976 from the firmware mailbox 1986.

[0152] Action 11 can represent that FMC 1920 reads the DevAK KeyCode 1922 from the firmware mailbox 1986.

[0153] Action 12 can represent that FMC 1920 reads the DevIKpub 1924 from the firmware mailbox 1986.

[0154] Action 13 can represent FMC 1920 requesting the DevAKpub Key from PUF Engine 1955. In one example, FMC 1920 can send the DevAK KeyCode 1922 (e.g., after receiving it from Firmware Mailbox 1986) to PUF Engine 1955. PUF Engine 1955 can return the DevAKpub Key.

[0155] Action 14 can represent FMC 1920 requesting the signing of data with the DevAKpriv key. In one example, FMC 1920 can send the data to be signed along with the DevAK KeyCode 1922 (e.g., after receiving it from Firmware Mailbox 1986) to PUF Engine 1955. PUF Engine 1955 can return the data signed with the DevAKpriv key.

[0156] Action 15 can represent that the remote host 1933 makes an SPDM request (e.g. GET_ATTESTATION, GET_CERTIFICATE) to FMC 1920 (as in Fig. 18 illustrated / described).

[0157] Action 16 can represent that FMC 1920 returns a signed SPDM request to the remote host 1933, e.g. in response to a GET_ATTESTATION request (as in Fig. 18 illustrated / described).

[0158] Action 17 can represent that FMC 1920 returns a certificate to the remote host 1933, e.g. in response to a GET_CERTIFICATE request.

[0159] Although Fig. 19 discloses a certain number of actions (1-17) with respect to the electronic device 1901, the electronic device 1901 may be capable of more or fewer actions than those in Fig. 19. For example, Boot Code 1940 or FMC 1920 may request PUF Engine 1955 to terminate the current cryptographic context (e.g., a stop() request), which may result in the SRAM PUF secrets being destroyed or erased and the SRAM PUF returning to its uninitialized state. Another example: Boot Code 1940 may request to set the read / write lock for SRAM PUF areas so that no user code (e.g., FMC 1920) can access the secret SRAM PUF key material. Another example: FMC 1920 may request the generation of other keys (e.g., not DevAK or DevIK) using the SHD_PUF.In examples, the PUF Engine 1955 can return a KeyCode for the newly generated key, and the FMC 1920 can use the KeyCode to request the PUF Engine 1955 to sign data with the newly generated key, generate and send a public key corresponding to the newly generated key, and so on. Accordingly, the private key may not be passed to the FMC 1920, but it can still use the private key to sign data. Even if . Fig. 19 actions 1-17 are shown, these actions can be performed in any order.

[0160] Fig. 20 shows an example boot code method 2000 for generating DevAK keys and certificates. According to one example, method 2000 may begin with block 2002. In one example, method 2000 may be executed from boot code 140, 1840, or 1940. In some examples, starting block 2002 may represent a time when electronic device 101 is first powered on (POR) or a time after a reset of the electronic device (e.g., a device reset, a reboot, or a power failure).

[0161] Thus, method 2000 of boot code 140 may be performed at a time when volatile memory 172 (e.g., SRAM with ROM_PUF and SHD_PUF areas) is not accessible by the FMC (e.g., because the FMC has not yet been authenticated and loaded). The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Thus, the initialization point for method 2000 and the order of 2002-2032 comprising method 2000 may depend on the chosen implementation.

[0162] In one example, the method 2000 may begin by generating the DevAK keys. At block 2002, the boot code 140 may initialize the SHD_PUF (e.g., 1606 / 1608 in Fig. 16). In one example, this may include the boot code 140 enrolling the SHD_PUF for the first time after a transfer of ownership of the electronic device. In another example, this may include providing the current owner's PUF activation code to the PUF engine to restore a previous cryptographic context for the current owner. The method may then proceed to block 2004, where the boot code 140 requests the generation of the DevAKpriv key and obtains the DevAK KeyCode (e.g., action 2 in Fig. 19). The method may then proceed to block 2006, where the boot code 140 may request the generation of the DevAKpub key using the DevAK KeyCode (e.g., action 3 in Fig. 19). The procedure can then proceed to block 2008, where the boot code 140 can store the DevAK KeyCode in the firmware mailbox 1986 (e.g., action 8 in Fig. 19). The method may then proceed to block 2010, where boot code 140 may request stopping the current SHD_PUF cryptographic context (e.g., a stop() request), which may result in the SHD_PUF secrets being destroyed or deleted and the SHD_PUF returning to its uninitialized state.

[0163] In one example, the method 2000 may continue with generating the DevIK keys. At block 2012, the boot code 140 begins with the initialization of the ROM_PUF (e.g., 1604 in Fig. 16). In one example, this may include the boot code 140 enrolling the ROM_PUF for the first time or, in another example, restoring a previous cryptographic context. In one example, the ROM_PUF cryptographic context may be the same for different owners of the electronic device. In another example, the ROM_PUF cryptographic context (such as the SHD_PUF cryptographic context) may be unique for each owner of the electronic device. Therefore, the initialization of the ROM_PUF in block 2012 may or may not include the current owner's PUF activation code to provide the PUF engine with a previous cryptographic context for the current owner. The method may then proceed to block 2014, where the boot code 140 requests the generation of the DevIKpriv key and obtains the DevIK KeyCode (e.g., action 2 in Fig. 19).

[0164] In one example, method 2000 may proceed with generating a DevAK certificate. At block 2016, boot code 140 may retrieve a DevAK certificate template, which may be stored in OTP memory 110, non-volatile memory 173, boot ROM 130, or another suitable location. (Boot code 140 may authenticate the DevAK certificate template before using it (not illustrated).) In one example, the DevAK certificate may be an X.509 CA or END certificate in ANSI.1 DER format. In other examples, the DevAK certificate may be generated in other certificate formats. The method may then proceed to block 2018, where boot code 140 may generate an unsigned DevAK certificate, e.g., by storing the DevAKpub key (e.g., generated in block 2006) as a certificate subject. The process can then proceed to block 2020, where boot code 140 can request the signing of the DevAK certificate with the DevIKpriv key.In one example, boot code 140 sends the request to sign the DevAK certificate with the DevIKpriv key to the PUF engine (e.g., action 5 in . Fig. 19) by providing the unsigned DevAK certificate data and the DevIK key code (e.g., generated in block 2014) to the PUF engine. The procedure can then proceed to block 2022, where the boot code 140 can store the DevAK certificate in the firmware mailbox 1986 (e.g., action 7 in Fig. 19). The method may then proceed to block 2024, where boot code 140 may request stopping the current ROM_PUF cryptographic context (e.g., a stop() request), which may result in the ROM_PUF secrets being destroyed or deleted and the ROM_PUF returning to its uninitialized state.

[0165] In one example, method 2000 may proceed with initializing the SHD_PUF for use by the FMC. At block 2026, boot code 140 may initialize the SHD_PUF as described for block 2002. The method may then proceed to block 2028, where boot code 140 requests the generation of the DevAKpriv key and obtains the DevAK KeyCode (e.g., action 2 in Fig. 19). The method may then proceed to block 2030, where the boot code 140 may verify that the generated DevAK key code matches the DevAK key code 1922 previously stored in the firmware mailbox 1986 (e.g., at block 2008). In this example, the check in block 2030 may confirm that the FMC and the boot code 140 are using the same cryptographic context and, thus, the same DevAK key pair. The method may then proceed to block 2032, where the boot code 140 may request the setting of the read / write lock for ROM_PUF and SHD_PUF. In one example, the read / write lock may be set on ROM_PUF, so that the FMC has no access. In the same or another example, the read / write lock can be set on SHD_PUF so that the FMC cannot access the area of ​​the SHD_PUF key material (e.g. 1606 in Fig. 16) but has access to the SHD_PUF status range (e.g., 1608 in Fig. 16), which may allow the FMC to use the DevAK KeyCode and PUF APIs to sign SPDM challenges and access other permitted PUF functions (e.g., use the DevAK KeyCode to obtain the DevAKpub Key, create other cryptographic key pairs, etc.).

[0166] Although Fig. 20 discloses a certain number of operations with respect to the method 2000, the method 2000 may be implemented with more or fewer operations than in Fig. 20. For example, the boot code may no longer request stopping the SHD_PUF after block 2008. Likewise, the boot code may no longer request stopping the ROM_PUF after block 2022. In these examples, stopping the SRAM PUFs on a boot code exit event may be good practice to prevent the FMC from accessing the device's secrets. However, stopping the SRAM PUFs can be avoided if the boot code, for example, executes blocks 2002-2032 of method 2000 without exiting or before loading the FMC. In one example, if block 2010 is omitted, block 2026 (initialization of the SHD_PUF) can also be omitted because the SHD_PUF has not been stopped. Although Fig. 20 has a particular order of operations with respect to method 2000, the operations comprising method 2000 may be performed in any suitable order. For example, the boot code may generate the DevIK keys (blocks 2012-2014) before generating the DevAK keys (blocks 2002-2010).

[0167] Fig. Figure 21 illustrates a flowchart of an example method 2100 for using an SRAM PUF shared by multiple entities to manage device keys. According to one example, method 2100 may begin at block 2110. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2100 and the order of blocks 2110-2135 comprising method 2100 may depend on the chosen implementation.

[0168] At block 2110, for an electronic device including a processor, non-volatile memory, and SRAM with a physically unclonable function (SRAM PUF) area, the processor may store first owner information and first modifiable owner code in the non-volatile memory. In one example, the SRAM PUF area may include a secret, unclonable silicon fingerprint unique to the electronic device. In the same or another example, the first owner information may be stored in the non-volatile memory so that it may emulate a one-time programmable memory (e.g., as an OTP-emulated parameter, as in Fig. 6) and is unique to a first owner of the electronic device. At block 2115, the processor may generate a first unique private key based on both the first owner information and at least a portion of the SRAM PUF area, wherein the first unique private key is not directly accessible to the first owner's mutable code (e.g., the PUF engine 1955 may not disclose the first unique private key to the first owner's mutable code while still allowing the first owner's mutable code to sign data with the first unique private key). At block 2120, the processor may generate a first unique private key code corresponding to the first unique private key. At block 2125, the processor may provide the first unique private key code to the first owner's mutable code.(The KeyCode may serve as a reference or handle to the corresponding key, so that when the KeyCode is passed to the PUF Engine 1955, the PUF Engine 1955 may use the KeyCode to determine the corresponding key. In this way, the key cannot be disclosed outside of the PUF Engine 1955 and its confidentiality can be maintained.) At block 2130, the processor may receive a signing request from the first owner's mutable code, where the signing request includes the first unique private KeyCode and first data. In one example, the first data may include a request to attest the device.At block 2130, in response to the signing request of the first owner's mutable code, the processor may sign the first data with the first unique private key and provide the first data signed with the first unique private key to the first owner's mutable code.

[0169] Although Fig. 21 discloses a certain number of operations with respect to the method 2100, the method 2100 may be implemented with more or fewer operations than in Fig. 21. For example, the method 2100 may be executed after block 2135 with additional Fig. 22-29. Moreover, the operations comprised by method 2100 may be performed in any order, even if Fig. 21 a specific sequence of operations is specified with respect to the method 2100.

[0170] Fig. Figure 22 illustrates a flowchart of an example method 2200 for using an SRAM PUF shared by multiple entities to manage device keys. According to one example, method 2200 may begin at block 2210. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2200 and the order of blocks 2210-2220 comprising method 2200 may depend on the chosen implementation.

[0171] According to one example, block 2210 may be the same as blocks 2110-2135 in Fig. 21. At block 2215, the processor may receive a request to generate a key from the first owner's mutable code. At block 2220, in response to the request to generate a key from the first owner's mutable code, the processor may generate a unique first owner's mutable code key based on at least a portion of the SRAM PUF region. In one example, the generated unique first owner's mutable code key may be based on the key material in SHD_PUF region 1606 ( Fig. 16) and are different from the DevAK key (e.g., for purposes other than answering challenges to attest the device).

[0172] Although Fig. 22 has a certain number of operations with respect to the method 2200, the method 2200 may be implemented with more or fewer operations than in Fig. 22. Although Fig. 22 has a particular order of operations with respect to method 2200, the operations comprising method 2200 may be performed in any suitable order.

[0173] Fig. 23 illustrates a flowchart of an example method 2300 for using a shared SRAM PUF to manage device keys. According to one example, method 2300 may begin at block 2310. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2300 and the order of blocks 2310-2335 comprising method 2300 may depend on the chosen implementation.

[0174] According to one example, block 2310 may be the same as blocks 2110-2135 in Fig. 21. At block 2315, the processor may transfer ownership of the electronic device to a second owner, including storing second owner information and a second alterable code in the non-volatile memory, wherein the second owner information may be unique to the second owner of the electronic device. In one example, the transfer of ownership may be as described in any of the Fig. 8-15. At block 2320, the processor may generate a second unique private key based on both the second owner information and at least a portion of the SRAM PUF region, where the second unique private key may not be directly accessible to the mutable code of the second owner (e.g., the PUF engine 1955 may not disclose the key to the mutable code of the second owner while still allowing the mutable code of the second owner to sign data with the key). At block 2325, the processor may generate a second unique private key code corresponding to the second unique private key. At block 2330, the processor may provide the second unique private key code to the mutable code of the second owner.At block 2335, the processor may prohibit access to or regeneration of the first unique private key as long as the second owner possesses the electronic device. In one example, access may be prohibited because (1) the first unique private key has been erased or destroyed (e.g., by a stop() request or by a reset of the electronic device 101), and the boot code 140 may restrict the cryptographic context to that of the current user, e.g., by using the current owner's PUF activation code, which may be authenticated prior to use. Accordingly, the system may disallow the use of a previous owner's PUF activation code, thus prohibiting access to or regeneration of the first unique private key.

[0175] Although Fig. 23 discloses a certain number of operations in connection with the method 2300, the method 2300 may be implemented with more or fewer operations than those described in Fig. 23. For example, the method 2300 may be executed after block 2335 with additional Fig. 24-25. Furthermore, the operations comprised by method 2300 may be performed in any order, even if Fig. 23 a specific sequence of operations relating to method 2300 is specified.

[0176] Fig. 24 illustrates a flowchart of an example method 2400 for using an SRAM PUF shared by multiple entities to manage device keys. According to one example, method 2400 may begin at block 2410. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2400 and the order of blocks 2410-2420 comprising method 2400 may depend on the chosen implementation.

[0177] According to one example, block 2410 may be the same as blocks 2310-2335 in Fig. 23. At block 2415, the processor may receive a second owner signing request from the second owner's mutable code, the second owner signing request including the second unique private key code and second data (e.g., an attestation request). At block 2420, in response to the second owner's request to sign by the second owner's mutable code, the processor may sign the second data with the second unique private key and provide the second data signed with the second unique private key to the second owner's mutable code.

[0178] Although Fig. 24 discloses a certain number of operations in connection with the method 2400, the method 2400 may be implemented with more or fewer operations than those described in Fig. 24. For example, the method 2400 may be executed after block 2420 with additional Fig. 25. Furthermore, the operations comprised by method 2400 may be performed in any order, even if Fig. 24 a specific sequence of operations is specified with respect to the method 2400.

[0179] Fig. 25 illustrates a flowchart of an example method 2500 for using a shared SRAM PUF to manage device keys. According to one example, method 2500 may begin at block 2510. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2500 and the order of blocks 2510-2520 comprising method 2500 may depend on the chosen implementation.

[0180] According to one example, block 2510 may be the same as blocks 2410-2420 in Fig. 24. At block 2515, the processor may receive a request to generate a key from the second owner's mutable code. At block 2520, in response to the request to generate a key from the second owner's mutable code, the processor may generate a unique second owner's mutable code key based on at least a portion of the SRAM PUF region. In one example, the generated second owner's unique mutable code key may be based on the key material in the SHD_PUF region 1606 ( Fig. 16) and are different from the DevAK key (e.g., for purposes other than answering challenges to attest the device).

[0181] Although Fig. 25 discloses a certain number of operations with respect to the method 2500, the method 2500 may be implemented with more or fewer operations than in Fig. 25. Although Fig. 25 has a particular order of operations with respect to method 2500, the operations of method 2500 may be performed in any suitable order.

[0182] Fig. 26 illustrates a flowchart of an example method 2600 for using a shared SRAM PUF to manage device keys. According to one example, method 2600 may begin at block 2610. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2600 and the order of blocks 2610-2625 comprising method 2600 may depend on the chosen implementation.

[0183] According to one example, block 2610 may be combined with blocks 2110-2135 in Fig. 21. At block 2615, the method may include destroying the first unique private key during a reset of the electronic device. In one example, the first unique private key may be destroyed or erased during a reset because it is stored in volatile memory whose contents are not persisted during the reset event. In an alternative example, in response to instructions in the boot code, the processor may destroy or erase the first unique private key by issuing a stop() request to the PUF engine 1955. In response to this request, the PUF engine 1955, which may be mutable code stored in ROM (e.g., ROM 130), may destroy or erase the first unique private key.At block 2620, after resetting the electronic device, the processor may generate a regenerated first unique private key corresponding to the first unique private key that is not directly accessible by the first owner's mutable code (e.g., the PUF engine 1955 may not make the regenerated key accessible to the first owner's mutable code while still allowing the first owner's mutable code to sign data with the regenerated key). At block 2625, in response to a signing request from the first owner's mutable 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 example, the PUF Engine 1955 may use the first unique private KeyCode as a reference or handle to determine the corresponding key that is ultimately used to sign the data.

[0184] Although Fig. 26 discloses a certain number of operations with respect to the method 2600, the method 2600 may be implemented with more or fewer operations than in Fig. 26. Even if Fig. 26 has a particular order of operations with respect to method 2600, the operations comprising method 2600 may be performed in any suitable order.

[0185] Fig. 27 illustrates a flowchart of an example method 2700 for using a shared SRAM PUF for managing device keys. According to one example, method 2700 may begin at block 2710. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2700 and the order of blocks 2710-2720 comprising method 2700 may depend on the chosen implementation.

[0186] According to one example, block 2710 may be the same as blocks 2110-2135 in Fig. 21. At block 2715, the processor may receive a public key request from the first owner's mutable code, where the public key request may include the first unique private key. At block 2720, in response to the public key request, the processor may generate a first unique public key corresponding to the first unique private key and provide the first unique public key to the first owner's mutable code.

[0187] Although Fig. 27 discloses a certain number of operations with respect to the method 2700, the method 2700 may be implemented with more or fewer operations than those described in Fig. 27. Although Fig. 27 has a particular order of operations with respect to method 2700, the operations comprising method 2700 may be performed in any suitable order.

[0188] Fig. 28 illustrates a flowchart of an example method 2800 for using an SRAM PUF shared by multiple entities to manage device keys. According to one example, method 2800 may begin at block 2810. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2800 and the order of blocks 2810-2825 comprising method 2800 may depend on the chosen implementation.

[0189] According to one example, block 2810 may be the same as blocks 2110-2135 in Fig. 21. At block 2815, the processor may generate a first unique public key corresponding to the first unique private key. At block 2820, the processor may generate a certificate having the first unique public key as a certificate subject. At block 2825, the processor may generate a signature for the certificate using a private key of the device.

[0190] Although Fig. 28 discloses a certain number of operations with respect to the method 2800, the method 2800 may be implemented with more or fewer operations than those described in Fig. 28. For example, the method 2800 may be executed after block 2825 with additional Fig. 29. Furthermore, the operations comprising method 2800 may be performed in any order, even if Fig. 28 a specific sequence of operations is specified with respect to the method 2800.

[0191] Fig. 29 illustrates a flowchart of an example method 2900 for using a shared SRAM PUF for managing device keys. According to one example, method 2900 may begin at block 2910. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 2900 and the order of blocks 2910-2915 comprising method 2900 may depend on the chosen implementation.

[0192] According to one example, block 2910 may be the same as blocks 2810-2825 in Fig. 28. At block 2915, the processor may provide the first owner with mutable code with the certificate, which may include the first unique public key as a certificate subject.

[0193] Although Fig. 29 discloses a certain number of operations with respect to the method 2900, the method 2900 may be implemented with more or fewer operations than those described in Fig. 29. Although Fig. 29 has a particular order of operations with respect to method 2900, the operations comprising method 2900 may be performed in any suitable order.

[0194] The Fig. 30a-30b illustrate a flowchart of an example method 3000 for using a shared SRAM PUF for managing device keys. According to one example, method 3000 may begin at block 3010. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 3000 and the order of blocks 3010-3070 comprising method 3000 may depend on the chosen implementation.

[0195] At block 3010, for an electronic device including a processor, non-volatile memory, and SRAM with a physically unclonable function (SRAM PUF) area, the processor may store first owner information and first modifiable owner code in the non-volatile memory. In one example, the SRAM PUF area may include a secret, unclonable silicon fingerprint unique to the electronic device. In the same or another example, the first owner information may be stored in the non-volatile memory so that it may emulate a one-time programmable memory (e.g., as an OTP-emulated parameter, as in Fig. 6) and is unique to a first owner of the electronic device. At block 3015, the processor may generate a private key for the device based on at least a portion of the SRAM PUF region. At block 3020, the processor may generate a first unique private key that may be based on both the first owner information and at least a portion of the SRAM PUF region, where the first unique private key is not directly accessible to the first owner's mutable code (e.g., the PUF engine 1955 may not make the first unique private key accessible to the first owner's mutable code while still allowing the first owner's mutable code to sign data with the key). At block 3025, the processor may generate a first unique public key corresponding to the first unique private key.At block 3030, the processor may generate a first unique private key code corresponding to the first unique private key. At block 3035, the processor may generate a certificate that may include the first unique public key as a certificate subject. At block 3040, the processor may sign the certificate with the device's private key. At block 3045, the processor may provide the first unique private key code to the first owner (e.g., by storing it in a firmware mailbox). At block 3050, the processor may provide the certificate to the first owner's mutable key (e.g., by storing it in a firmware mailbox). At block 3055, the method may include deleting the first unique private key during a reset of the electronic device.In one example, the first unique private key may be destroyed or erased during the reset because it is stored in volatile memory, the contents of which may not be preserved during the reset. In an alternative example, the boot code may cause the processor to destroy or erase the first unique private key by issuing a stop() request to the PUF Engine 1955. At block 3060, after resetting the electronic device, the processor may generate a regenerated first unique private key that corresponds to the first unique private key and that is not directly accessible by the first owner's mutable code (e.g.,the PUF engine 1955 may not disclose the regenerated key to the first owner's mutable code while still allowing the first owner's mutable code to sign data with the regenerated key). At block 3065, the processor may receive a signing request from the first owner's mutable code, the signing request including the first unique private key code and first data. In one example, the first data may comprise a request to attest the device. At block 3070, in response to receiving the signing request from the first owner's mutable code, the processor may sign the first data with the regenerated first unique private key and provide the first owner's mutable code with the first data signed with the regenerated first unique private key.

[0196] Although the Fig. 30a-30b disclose a certain number of operations in connection with the method 3000, the method 3000 may be implemented with more or fewer operations than in Fig. 30 shown. Even if Fig. 30 has a particular order of operations with respect to method 3000, the operations comprising method 3000 may be performed in any suitable order. Secure Owner Revocation Emulation Container (REC)

[0197] The concepts of image key revocation and image rollback protection as described in various examples above (e.g. Fig. 5) can be applied to the first mutable code (FMC), which can be loaded and authenticated by the boot code 140. The same concepts can also be applied to images that the FMC authenticates to extend the chain of trust (e.g., application firmware). With the introduction of device ownership, each owner can train the electronic device 101 to use a unique set of keys and image revisions that are used to validate the FMC during the boot code authentication sequence. These keys and images can be validated using the TAGx Image Key Revocation 508 and TAGx Image Rollback Protection 509 information stored in the secure RPMC Owner Container 302. The secure Owner Revocation Emulation (REC) container can extend these concepts.

[0198] In one example, after a transfer of ownership, a new REC (e.g. Fig. 33) and stored in non-volatile memory 173. The new REC may include revocation or rollback protection information for assets associated with the current owner of electronic device 101. In one example, the revocation and rollback protection information may correspond to assets such as keys (individual keys or key hash blobs), hash tables, or images. In the same or other examples, the revocation and rollback protection information may correspond to assets such as static configuration data or accumulated data (revocation information, logs, status, etc.). In one example, the revocation and rollback protection may be programmed only to emulate OTP functionality and deprogrammed only upon a transfer of ownership.In this way, each owner of the electronic device 101 can use the same number of assets as other owners (e.g., corresponding to the number of bits provided in the REC for revocation and / or rollback protection). Without the REC, all owners share the asset revocation information and rollback protection stored in the OTP memory 110, so the number of assets a current owner can revoke is reduced by the number of assets revoked by a previous owner.

[0199] Fig. Figure 31 illustrates a block diagram of an exemplary OTP memory for managing keys, images, and other assets related to an owner of an electronic device, including the use of a secure owner REC. In one example, the information stored in the OTP memory 110 of Fig. 31 illustrated information on the Fig. 2. Revocation Emulation Feature Enable 3102 may indicate whether the electronic device 101 supports secure revocation emulation. If the value of Revocation Emulation Feature Enable 3102 indicates that the feature is enabled, for example, each owner of the electronic device 101 may be provided with a separate set of bits for revoking assets with emulated OTP (EOTP) stored in the non-volatile memory 173 (e.g., in a secure REC ( Fig. 33-35)). In an example where the asset revocation bits apply to keys and image assets, this feature may allow each owner of the electronic device 101 to start with image version 0 and key 0. In an alternative example, where the value of Revocation Emulation Feature Enable 3102 indicates that the feature is not enabled, the asset revocation bits may be stored in the OTP Memory 110. In this alternative example, the asset revocation bits may be shared by all owners of the electronic device 101, and a new owner cannot use assets (e.g., keys or image revisions) that were revoked by a previous owner.

[0200] The current RPMC Value 3104 of the revocation emulation container (REC) may be provided by a repetition-protected monotonic counter that is incremented over time. In one example, the current REC RPMC Value 3104 may be incremented upon a change of ownership of the electronic device 101. In the Fig. 31, the current REC RPMC Value 3104 may be a value stored in the OTP Memory 110. In this example, the bits in the OTP Memory 110 for the current REC RPMC Value 3104 may be set sequentially from the lowest bit to the highest bit, and the next current REC RPMC Value may be the next integer value after the current REC RPMC Value 3104. In the same or other examples, values ​​less than the current REC RPMC Value 3104 may be considered revoked and values ​​greater than the current REC RPMC Value 3104 may be considered unused (e.g., similar to the current RPMC Value 202 in Fig. 2). A value less than the current REC RPMC Value 3104 can be considered revoked, as the OTP Memory 110 cannot be programmed to a lower value, as the OTP memory, by definition, can only be programmed once. For example, if the current RPMC Value 3104 has a value of one (1), the least significant bit is programmed and cannot be reset to restore the current RPMC Value 3104 to a value of zero (0).

[0201] Regions 3108-3112 may serve as revocation emulation data for various assets associated with the current owner of electronic device 101. In the illustrated example, the assets may include hash tables, keys, and images, each corresponding to regions 3108-3112. In one example, an owner may provide eight (8) public keys that can be used to authenticate other data. Application Public Key Revocation 3110 may have a bit corresponding to each public key. In this example, if a bit in Application Public Key Revocation 3110 is programmed to the value one (1), the corresponding key may be revoked. In one example, Boot Code 140 may not use a revoked key (e.g.,Boot Code 140 may check before using a key whether a corresponding bit in Application Public Key Revocation 3110 is programmed to the value one (1). Similarly, Hash Table Rollback Protection 3108 and Image Rollback Protection 3112 may indicate whether a current hash table or image revision (e.g., FMB) is available for use or has been revoked (not available for use). In one example, electronic device 101 may allow up to 128 hash table revisions and 128 image revisions, and Hash Table Rollback Protection 3108 and Image Rollback Protection 3112 may each have a bit corresponding to each revision. In this example, if a bit in Hash Table Rollback Protection 3108 is programmed to a value of one (1), the corresponding hash table revision may be revoked. In one example, Boot Code 140 may not use a revoked hash table (e.g.,Boot Code 140 may check, before using a hash table, whether a corresponding bit in Hash Table Rollback Protection 3108 is not programmed to the value one (1). In the same or other examples, the corresponding image revision may be revoked if a bit in Image Rollback Protection 3112 is programmed to the value one (1). In one example, Boot Code 140 may not authenticate a revoked image (e.g., before loading an image, Boot Code 140 may check whether a corresponding bit in Image Rollback Protection 3112 is not programmed to the value one (1)).

[0202] Regions 3114-3115 can serve as masking data for revoking various assets associated with the current owner of electronic device 101. Hash Table Authentication Key Mask 3114 can serve as an authorization mask for revoking the hash table. Image Authentication Key Mask 3115 can serve as an authorization mask for revoking images.

[0203] Although Fig. 31 illustrates different areas of the OTP memory 310, other example systems may include electronic devices with more or fewer areas.

[0204] The Revocation Emulation Container (REC) Base Address 3106 may be the base address where the default revocation emulation container is stored in the non-volatile memory 173. In an example where the Revocation Emulation Feature Enable 3102 indicates that the electronic device 101 supports the secure revocation emulation feature, the boot code may access the default revocation emulation container in the non-volatile memory 173 via the REC Base Address 3106.

[0205] Fig. Figure 32 illustrates a block diagram of the contents of an owner container for managing keys, images, and other assets related to an owner of an electronic device, including through the use of a secure owner REC. As shown in Fig. 32, the container content 311b can be programmed in the non-volatile memory 173 and the regions 501-515 (described in Fig. 5) and 621 (described in Fig. 6) (all previously described regions in dashed box 3201). Container Content 311b may further include regions 3214-3216, which include a secure REC. Owner REC RPMC 3214 may correspond to the offset (e.g., the index) of the most significant bit (MSB) programmed into current REC RPMC Value 3104. In one example, Boot Code 140 may determine if a REC is valid by comparing Owner REC RPMC 3214 to current REC RPMC Value 3104 (stored in OTP Memory 110). Hash Table Authentication Key Mask 3215 may include information for generating authorization bits for the hash table. Image Authentication Key Mask 3216 for image authentication may include information for generating authorization bits for the image table.

[0206] Although Fig. While 32 different regions of the container content 311b are illustrated, other example systems may include electronic devices with more or fewer regions.

[0207] Fig. 33 illustrates a block diagram of an exemplary Secure Revocation Emulation Container (REC) 3302 for managing ownership, keys, images, and other assets related to an owner of the electronic device 101. In one example, the REC 3302 may be a signed data image stored in non-volatile memory (e.g., OTP Memory 110, Non-Volatile Memory 173, among others) and includes the configuration and revocation of the current silicon owner to allow the Boot Code 140 to revoke various assets (e.g., keys, hash tables, and images, among others). As in Fig. 33, the owner container 3302 may include three regions: REC header 3310, REC content 3311, and REC signature 3312. In one example, REC 3302 may be a unique, signed container with information modifiable by the code that created the container (e.g., boot code 140 or a ROM extension (e.g., an authenticated FMC)), stored and retrieved in non-volatile memory (e.g., non-volatile memory 173). According to the examples in this disclosure, the REC 3302 may only be signed and updated by the code that created the container. Higher-level firmware (e.g., code other than the code that created the container) may include a command interface (e.g., command memory 171, Fig. 7) to access or modify information in REC 3302. In one example, only immutable boot code (e.g., Boot Code 140) can access or modify information in REC 3302. In another example, boot code (whether immutable boot code or a ROM extension (e.g., an authenticated FMC)) can access or modify information in REC 3302. In one example, the boot code that creates REC 3302 can create two redundant copies of REC 3302. One copy can be the primary REC, and the other copy can be the fallback REC.

[0208] Although Fig. 33 different regions of the REC 3302 are illustrated, other example systems may include electronic devices with more or fewer regions. REC signature

[0209] REC Signature 3312 may include a signature corresponding to REC 3302 and generated by Boot Code 140 or a ROM extension (e.g., an authenticated FMC). In one example, Boot Code 140 may use a physically unclonable function (PUF) to generate a non-deterministic ECDSA signature. For example, REC Signature 3312 may be an ECDSA-384 signature that has the following characteristics: • Algorithm: Elliptic Curve Digital Signature Algorithm (ECDSA) • Key size: 384 bits • Curve: NIST “secp384r1” curve • Hashing algorithm: SHA384 • Signed Message (m) = {REC Header 3310 | REC Content 3311}

[0210] Boot Code 140 can derive the private ECDSA key used to sign the REC 3302. In one example, Boot Code 140 can derive the SRAM PUF (e.g., SHD_PUF region 1606 / 1608 in Fig. 16) Enroll / start before deriving the private ECDSA signing key. Once the private ECDSA signing key has been generated, Boot Code 140 can sign REC 3302. REC header

[0211] Fig. 34 illustrates a block diagram of an exemplary REC header 3310 of the revocation emulation container 3302 for managing ownership, keys, images, and other assets related to an owner of the electronic device 101. In one example, the REC header 3310 may have a common format for the RECs created for the electronic device 101. As shown in Fig. 34, the REC header 33 may include regions 3431-3436, including: REC RPMC Value 3431, Container Type 3433, Secure Content Container Length 3434, Device Serial Number 3435, and Container Command Key Hash Blob 3436.

[0212] The REC RPMC Value 3431 may be provided by a repeatable monotonic counter that can be compared with the current REC RPMC Value 3104 in the OTP Memory 110 to determine whether this REC container is valid or revoked. For example, if the REC RPMC Value 3431 for REC 3302 has a value of three (3), Boot Code 140 can determine that REC 3302 is valid if the current RPMC Value 3104 of the revocation emulation container (REC) also has a value of three (3). In the same or other examples, if REC RPMC Value 3431 for REC 3302 has a value of three (3), Boot Code 140 may determine that REC 3302 is revoked if the current RPMC Value 3104 of the revocation emulation container (REC) has a value greater than three (3). In some examples, REC RPMC Value 3431 may include a check for primary and fallback REC containers.

[0213] The Container Type 3433 may represent a type associated with the REC 3302. In one example, the Container Type 3433 may have a value indicating that the container is not initialized. In another example, the Container Type 3433 may have a value indicating that the REC 3302 is initialized and is a valid REC. Secure Content Container Length 3434 may include the number of bytes in the REC Content 3311. The Device Serial Number 3435 may correspond to the serial number of the electronic device 101, e.g., the unique Serial Number 205 in the OTP Memory 110. The Container Command Key Hash Blob 3436 may include a hash (e.g., SHA384 (Secure Hash Algorithm)) of one or more Container Command Keys (CCKs), which may be public keys of a cryptographic key pair.In the illustrated example, the container Command Key Hash Blob 3436 may include hashes of the public keys CCK0 3437, CCK1 3438, CCK2 3439, and CCK3 3440. In one example, these key hashes may be used to verify commands related to REC 3302. (Alternatively, the container Command Key Hash Blob 3436 may include the public keys instead of hashes of the public keys. More storage space may be required in this example.) In one example, CCK0-3 (3437-3440) may be revoked by setting the hash entry to zero (0). Although . Fig. While 34 different regions of the REC header 3310 are illustrated, other example systems may include electronic devices with more or fewer regions. REC Content

[0214] Fig. 35 illustrates a block diagram of an exemplary REC Content 3311 of REC 3302 for managing ownership, keys, images, and other assets related to an owner of an electronic device 101. As in Fig. As shown in Figure 35, the REC content 3311 may include regions 3501-3507, including: version 3501, owner ID 3502, hash table rollback protection 3503, application public key revocation 3504, image rollback protection 3505, hash table authentication key mask 3506, and image authentication key mask 3507. Version 3501 may indicate the version of the REC content to support updates to the REC format. The owner ID 3502 may be a value provided by the owner at the time of transfer of ownership, may be the same value as the owner ID 501 stored in the current owner's secure RPMC owner container, and may be used to verify that this REC belongs to the current owner.

[0215] Regions 3503-3505 may serve as revocation emulation data for various assets associated with the current owner of electronic device 101. In the illustrated example, the assets may include hash tables, keys, and images, each corresponding to regions 3503-3505. In one example, an owner may provide eight (8) public keys that can be used to authenticate other data. Application Public Key Revocation 3504 may have a bit corresponding to each public key. In this example, if a bit in Application Public Key Revocation 3504 is programmed to a value of one (1), the corresponding key may be revoked. In one example, Boot Code 140 may not use a revoked key (e.g.,Before using a key, Boot Code 140 may check whether a corresponding bit in Application Public Key Revocation 3504 is programmed to the value one (1). Similarly, Hash Table Rollback Protection 3503 and Image Rollback Protection 3505 may indicate whether a current hash table or image revision (e.g., FMB) is available for use or has been revoked (not available for use). In one example, Electronic Device 101 may allow up to 128 hash table revisions and 128 image revisions, and Hash Table Rollback Protection 3503 and Image Rollback Protection 3505 may each have a bit corresponding to each revision. In this example, if a bit in Hash Table Rollback Protection 3503 is programmed to a value of one (1), the corresponding hash table revision may be revoked. In one example, Boot Code 140 may not use a revoked hash table (e.g.,Boot Code 140 may check, before using a hash table, whether a corresponding bit in Hash Table Rollback Protection 3503 is not programmed to the value one (1). In the same or other examples, the corresponding image revision may be revoked if a bit in Image Rollback Protection 3505 is programmed to the value one (1). In one example, Boot Code 140 may not authenticate a revoked image (e.g., before loading an image, Boot Code 140 may check whether a corresponding bit in Image Rollback Protection 3505 is not programmed to the value one (1)).

[0216] The revocation emulation data in regions 3503-3505 may be emulated OTP (EOTP) information stored in non-volatile memory 173. In one example, this function may allow each owner of electronic device 101 to start with hash table revision 0, image revision 0, and key 0 (e.g., each region 3503-3505 may be initialized to zero (0) upon initial creation of REC 3302). In one example, regions 3503-3505 may be stored in non-volatile memory 173 and emulate data stored in OTP memory 110 (OTP emulation) because a trusted boot code 140 (e.g., an immutable boot code or an authenticated ROM extension in the FMC) can only program these regions and no commands are provided for boot code 140 (or any other code) to deprogram these regions.Should a malicious user attempt to modify the REC 3302 while it is stored in the non-volatile memory 173 (e.g., to modify one of the EOTP regions), the verification of the REC will fail. Verification uses, for example, the REC Signature 3312, which is also stored in the non-volatile memory 173. Since the REC Signature 3312 is generated from a private key based on the SRAM PUF (e.g., SHD_PUF region 1606 / 1608 in . Fig. 16), and only the boot code 140 can directly access the SRAM_PUF, it is not possible for the malicious user to forge the REC signature 3312. Therefore, deprivation emulation data in regions 3503-3505 in the REC 3302, which are stored in the non-volatile memory 173, can be considered as an emulation of the OTP memory.

[0217] Regions 3506-3507 may serve as revocation masking data for various assets associated with the current owner of electronic device 101.

[0218] Hash Table Authentication Key Mask 3506 can serve as an authorization mask for revoking the hash table. Image Authentication Key Mask 3507 can serve as an authorization mask for revoking images.

[0219] Although Fig. While 35 different regions of REC content 3311 are illustrated, other example systems may include electronic devices with more or fewer regions. Withdrawal emulation container procedure

[0220] Fig. 36 illustrates a flowchart of an example method for revocation emulation. According to one example, method 3600 may begin at block 3605. In one example, method 3600 may be executed by boot code 140. For simplicity, we use the term boot code 140 as executing functions, which is understood to mean that boot code 140 is read by processor 160 and causes processor 160 to perform the appropriate functions. In some examples, starting block 3605 may represent a time when electronic device 101 is first powered on (i.e., power-on reset (POR)) or a time after a reset of the electronic device (e.g., a device reset, reboot, or power failure).In the same or another example, starting block 3605 may represent a point in time after boot code 140 has determined that (1) the ownership feature of electronic device 101 is enabled (e.g., based on an enable bit in OTP memory 110 that was set during device provisioning) and (2) the device has a current owner (e.g., based on the state of a bit in RPMC flash container status 208 stored in OTP memory 110). Fig. 2)). In these examples, method 1700 may be performed by boot code 140 at a time when volatile memory 172 (e.g., SRAM with ROM_PUF and SHD_PUF regions) is not accessible by the FMC (e.g., because the FMC has not yet been authenticated and loaded). The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Thus, the initialization point for method 3600 and the order of steps 3605-3650 comprising method 1700 may depend on the chosen implementation.

[0221] Following a POR or soft reset, Boot Code 140 may proceed to block 3610, where it may determine whether the revocation emulation feature is enabled. In one example, Boot Code 140 may make this determination based on the value of Revocation Emulation Feature Enable 3102 in OTP Memory 110 ( Fig. 31). If the asset revocation emulation function is not enabled, the boot code 140 may proceed to block 3613, where it retrieves the asset revocation information from the OTP memory 110. In one example, the boot code 140 may retrieve asset revocation such as Hash Table Rollback Protection 3108, Application Public Key Revocation 3110, or Image Rollback Protection 3112 ( Fig. 31). In this example, all owners can share the asset revocation and rollback protection information stored in the OTP Memory 110, so that the number of assets (e.g., keys, images) that a current owner can revoke is reduced by the number of assets that a previous owner revoked.

[0222] At block 3610, boot code 140 determines that the revocation emulation feature is enabled and proceeds to block 3616, where it determines whether it can find a valid REC. In one example, a valid REC (e.g., REC 3302) is considered found if (1) the REC Signature 3312 is valid, (2) the REC RPMC Value 3431 is valid, and (3) other integrity checks are successful. In the same or another example, boot code 140 may determine the validity of the REC Signature 3312 by performing the following steps: 1. Check the availability of the SRAM PUF (e.g. the PUF Activation Code is 621 ( Fig. 6) contained in the current owner's secure RPMC owner container. In one example, a non-zero PUF Activation Code 621 may indicate the presence of PUF Activation Code 621 and the availability of the SRAM PUF. 2. Generate a private ECDSA-384 key to sign REC 3302. In one example, Boot Code 140 can use the PUF Engine 1955 (and the SRAM PUF API functions) ( Fig. 19) to generate a private key. PUF Engine 1955 can return a key code for the newly generated key. 3. Generate an ECDSA-384 public key from the private key. In one example, the Boot Code 140 can use the KeyCode obtained in step 2 to request the PUF Engine 1955 to generate the corresponding public key (e.g., action 14 in Fig. 19). 4. Verify the REC 3302 with the derived public key. In one example, the boot code 140 may use the public key obtained in step 3 and the header, contents, and signature of the REC 3302 (which may be stored in volatile memory, e.g., SRAM) to request the PUF engine 1955 to verify the REC 3302.

[0223] In the same or another example, Boot Code 140 may determine that REC RPMC Value 3431 is valid by comparing it to the current REC RPMC Value 3104 in OTP Memory 110. In one example, REC RPMC Value 3431 may be valid if its value is equal to the index of the least significant bit set to zero in the current RPMC Value 3104 of the revocation emulation container (REC). In the same or another example, Boot Code 140 may perform one of the following integrity checks: (a) correct container version (e.g., version 3501 corresponds to an expected value); (b) correct Container Type 3433 (e.g., REC); (c) correct Container Content Length 3434 (e.g., Ox11c); (d) Device Serial Number 3435 in REC 3302 matches the value of Serial Number 205 in OTP Memory 110; (e) CCK Key Hash Blob 3436 in REC 3302 matches values ​​(e.g., 436 in Fig. 4) programmed in the secure RPMC owner container of the current owner; (f) the Owner ID 3502 in the REC matches the Owner ID (e.g. 502 in Fig. 5) in the current owner's secure RPMC owner container; or (g) the revocation masking data (e.g., 3506 / 3507) matches values ​​stored in the current owner's secure RPMC owner container (e.g., 3215 / 3216 in Fig. 32).

[0224] If Boot Code 140 determines at block 3616 that it has found a valid REC, Boot Code 140 may proceed to block 3619, where it uses the verified REC from Non-Volatile Memory 173 in subsequent steps. If Boot Code 140 determines in block 3616 that it has not found a valid REC, Boot Code 140 may proceed to block 3622, where it determines whether a new REC can be generated. In one example, Boot Code 140 may determine that a new REC can be generated if (1) no assets (e.g., keys, image revisions, hash tables, etc.) have been revoked by the current owner and (2) the current owner's secure RPMC Owner Container has a valid PUF Activation Code 621 ( Fig. 6). Fig. Figure 38 illustrates an example of determining whether the current owner has withdrawn assets. In the same or a different example, a non-zero PUF Activation Code 621 may indicate a valid PUF Activation Code 621.

[0225] If boot code 140 determines at block 3622 that a new REC can be created, boot code 140 may proceed to block 3625, where it may create a new REC. In one example, boot code 140 creates a new REC when a new owner of electronic device 101 is determined (e.g., when the revocation release 3102 indicates that the feature is enabled).

[0226] Fig. Figure 37 illustrates a block diagram of various RPMC values ​​related to withdrawal emulation and, in particular, to the creation of a new REC at block 3625 ( Fig. 36), including how the REC container can be bound to the owner container at creation time. In one example, the Current REC RPMC Value [319:0] 3704 in the OTP Memory 110 can be 320 bits wide, allowing for 320 different secure revocation emulation containers in the electronic device 101. (The Current REC RPMC Value [319:0] 3704 is an example of an implementation of the Current REC RPMC Value 3104 in Fig. 31). The Secure RPMC Owner Container 3711 may contain the Owner REC RPMC 3714. (Secure RPMC Owner Container 3711 and Owner REC RPMC 3714 are examples of an implementation of Secure RPMC Owner Container 302 and Owner REC RPMC 3214, respectively.) The Revocation Emulation Container 3702 may contain the REC RPMC Value 3731. (Revocation Emulation Container 3702 and REC RPMC Value 3731 are examples of REC 3302 and REC RPMC Value 3431.) For example, if a new owner of the electronic device 101 is determined, a new REC 3702 may be created (e.g., block 3625 in Fig. 36). When creating the new REC 3702, Boot Code 140 may set the value of both the Owner REC RPMC 3714 and the REC RPMC Value 3731 to "Offset (N+1)", which may be the index of at least the least significant bit in the current REC RPMC Value [319:0] 3704, which is set to zero (as illustrated in block 3760).

[0227] Fig. Figure 38 illustrates a block diagram of various RPMC values ​​in the context of demonstrating revocation and, in particular, the updating of RPMC values ​​at the time of revocation of an asset (e.g., key, image, hash value), including the incrementation of the REC RPMC value to revoke an asset. In one example, the RPMC values ​​may be Fig. 37 may be present in the electronic device 101 after a change of ownership. When an asset is revoked, the boot code 140 may increment the REC RPMC Value 3831 (e.g., to N+2) and set the at least least significant bit in the current REC RPMC Value [319:0] 3804, which is set to zero (e.g., N+1), to one, as illustrated in block 3860. In the same example, the boot code 140 may not change the owner REC RPMC 3814 (its value may still be N+1). Consequently, after an asset is revoked, the owner REC RPMC 3814 (e.g., N+1) may have less than the offset (e.g., the index) of the least significant bit equal to zero in the REC Current RPMC Value [319:0] 3804 in the OTP Memory 110. At block 3622, Boot Code 140 can use these values ​​to determine whether a new REC is available to be created.If the owner's RPMC 3814 is equal to the offset of the least significant bit in the current RPMC value [319:0] 3804, Boot Code 140 can determine that no assets (e.g., keys, images, hashes) have been revoked by the current owner and can therefore generate a new REC. If this is not the case, Boot Code 140 cannot create a new REC because it is possible that the current owner has revoked one or more assets.

[0228] According to one example, the Owner REC RPMC 3814 and the REC RPMC Value 3831 may both be initialized to a value of eight (1000b) upon transfer of ownership. This initialization may occur when bits 0-7 of REC Current RPMC Value [319:0] 3804 are set to one (1). In this example, N=7 and (N+1)=8. When an asset is revoked, Boot Code 140 may increment the REC RPMC Value 3831 to a value of nine (1001b) (e.g., to N+2) and set the least significant bit in the Current REC RPMC Value [319:0] 3804 that is set to zero (e.g., bit 8 (i.e., N+1)) to one.In this example, Boot Code 140 may determine that it cannot create a new REC because the owner REC RPMC 3814, which retains its initialization value of eight, is less than (and not equal to) the offset of the least significant bit equal to zero in REC Current RPMC Value [319:0] 3804, which is now bit nine (N+2) because bit eight has been set to one.

[0229] Back to Fig. 36: If Boot Code 140 determines at block 3622 that a new REC cannot be generated, Boot Code 140 may proceed to block 3649 and indicate a recoverable fatal error. For example, at block 3649, Boot Code 140 may cause Electronic Device 101 to enter Crisis Recovery Mode so that the current owner can use the crisis port (e.g., I2C, UART) to restore the transfer of ownership of Electronic Device 101.

[0230] The boot code may proceed from blocks 3613, 3619, and 3625 to block 3628, where it may use asset revocation information when authenticating assets. In an example where the boot code proceeds from block 3613 to block 3628, the boot code may use asset revocation information retrieved from the OTP store (block 3616) when authenticating assets. In an example where the boot code proceeds from block 3619 to block 3628, the boot code may use asset revocation information from the verified REC (block 3619) when authenticating assets. In an example where the boot code moves from block 3625 to block 3628, the boot code may use the asset revocation information retrieved from the newly created REC (block 3625) when authenticating assets.

[0231] After block 3628, boot code 140 may proceed to block 3631, where it determines if it can find a valid image. In one example, an image that boot code 140 authenticates and that has not been revoked may be a valid image. In an example where revocation emulation feature 3102 is enabled, boot code 140 may copy the current owner's REC from non-volatile memory 173 to volatile memory 172 (e.g., SRAM) and authenticate the REC (in volatile memory 172) before attempting to authenticate an image. This allows boot code 140 to find authenticated revocation emulation data (e.g., items 3503-3505 in Fig. 35) when determining whether it can find a valid image in block 3631. In one example, boot code 140 may check whether the key used to sign an image has been revoked and whether the image itself has been permanently removed from circulation (i.e., rollback protection). Boot code 140 may use the revocation and rollback protection information in the same way during authentication, regardless of whether the source of the revocation and rollback protection information (i.e., the revocation emulation data) is the OTP memory 110 or the REC 3302.

[0232] If, at block 3631, boot code 140 determines that it has found a valid image, it may proceed to block 3634, where it may determine whether to revoke assets. In one example, boot code 140 may determine whether to revoke assets based on revocation information received from the current owner of electronic device 101. The revocation information may be provided, for example, via revocation information stored in a verified image in non-volatile memory. Because the image can be verified using the current owner's secrets (e.g., private keys), the current owner retains control over asset revocation information, such as images, hash tables, keys, and others. In one example, boot code 140 may load and verify an image and then retrieve the asset revocation information (e.g.,Keys, images, hash tables) of the current owner of the silicon. In one example, the revocation information in a verified image may include a single permission bit corresponding to each available asset, and Boot Code 140 may determine that an asset should be revoked if the corresponding permission bit is set in the verified image.

[0233] If Boot Code 140 determines at block 3634 that assets are to be revoked, Boot Code 140 may proceed to block 3637, where it updates the revocation. For example, if the revocation emulation feature is not enabled (e.g., if Revocation Emulation Feature Enable 3102 is not set), Boot Code 140 may update the revocation data in OTP Memory 110 (e.g., by programming the appropriate bits in regions 3108-3112 ( Fig. 31)). For example, if the revocation emulation feature is enabled (e.g., if the Revocation Emulation Feature Enable 3102 is enabled), the boot code 140 may update the corresponding EOTP bits (e.g., the revocation emulation data 3503-3505) in a copy of REC 3302 stored in the volatile memory 172 (e.g., SRAM). (In one example, the boot code 140 may copy the REC 3302 from the non-volatile memory 173 (e.g., SPI flash) to the volatile memory 172 (e.g., SRAM) before verifying the REC signature 3312 in block 3616. The boot code may then use the copy of the REC 3302 in the volatile memory 172 for the remaining blocks in Fig. 36. This approach may be more secure than using the copy of the REC in the non-volatile memory 173, which can be accessed by a malicious user. In the example where the Revocation Emulation Feature Enable 3102 is enabled, the boot code 140 can re-sign the REC 3302 in the volatile memory 172 (e.g., as described for the REC Signature 3312).

[0234] After updating the revocation data in block 3637, the boot code may proceed to block 3640, where it updates the REC 3302 in the non-volatile memory 173. In an example where the Revocation Emulation Feature Enable 3102 is not enabled, the boot code 140 may continue from block 3640 to the END block 3650 without updating the REC 3302, since in this case, no REC 3302 may be present in the non-volatile memory 173. In an example where the Revocation Emulation Feature Enable 3102 is enabled, the boot code 140 may perform the following actions to update the REC 3302 in the non-volatile memory 173: 1. Update the fallback REC in the non-volatile memory 173. In one example, the boot code 140 can do this by deleting the fallback REC, writing the updated fallback REC to the same location, reading the updated fallback REC from the non-volatile memory 173, and checking whether the updated fallback REC read from the non-volatile memory 173 is valid. 2. Increment the current revocation emulation container (REC) RPMC value 3104 in OTP memory 110. 3. Update the primary REC in the non-volatile memory 173. In one example, the boot code 140 may do this by deleting the primary REC, writing the updated primary REC to the same location, reading the updated primary REC from the non-volatile memory 173, and checking whether the updated primary REC read from the non-volatile memory 173 is valid.

[0235] Following block 3640, boot code 140 may proceed to END block 3650. If boot code 140 determines in block 3634 that there are no assets that need to be revoked, boot code 140 may proceed to END block 3650. In one example, boot code 140 may perform operations to terminate the boot sequence in block 3650 so that electronic device 101 may proceed with normal operation.

[0236] Although Fig. 36 discloses a certain number of operations in connection with the method 3600, the method 3600 may be implemented with more or fewer operations than in Fig. 36. For example, if Boot Code 140 determines in block 3634 that there are no assets that need to be revoked, Boot Code 140 may check whether the fallback REC needs to be repaired and, if so, repair it by replacing it with a copy of the valid primary REC. Another example: If a new REC cannot be created (block 3622) or no valid images are found (block 3631), Boot Code 140 may transition to a recoverable fatal error block. Even if Fig. 36 discloses a particular order of operations with respect to method 3600, the operations comprising method 3600 may be performed in any suitable order.

[0237] Fig. 39a-b illustrate a flowchart of an exemplary method 3900 for managing ownership, keys, images, and other assets related to an owner of an electronic device. According to one example, method 3900 may begin at block 3910. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 3900 and the order of blocks 3910-3960 comprising method 3900 may depend on the chosen implementation.

[0238] At block 3910, for an electronic device having a processor, non-volatile memory, boot code, and static random access memory (SRAM) including an SRAM region with physically unclonable functionality (SRAM PUF), the processor may generate a first unique private key based on at least one or more of the following information: (i) first ownership information associated with a first owner of the electronic device, and (ii) at least a portion of the SRAM PUF region, wherein the first unique private key may not be directly accessible by code other than the boot code. At block 3915, the processor may create a first owner revocation emulation container for the first owner of the electronic device, wherein the first owner revocation emulation container may include first asset revocation information.At block 3920, the processor may use the first unique private key to generate a first signature for creating the first owner's revocation emulation container.

[0239] At block 3925, the processor may store the first signature in non-volatile memory. At block 3930, the processor may store the first owner's revocation emulation container in non-volatile memory. At block 3935, the processor may retrieve the first signature from non-volatile memory. At block 3940, the processor may retrieve the first owner's revocation emulation container from non-volatile memory. At block 3945, the processor may derive a first unique public key from the first unique private key. At block 3950, the processor may use the first unique public key and the first signature retrieved from non-volatile memory to verify the first owner's revocation emulation container retrieved from non-volatile memory.

[0240] Upon successful verification of the first owner's revocation emulation container retrieved from non-volatile memory, at block 3955, the processor may use the first asset revocation information of the first owner's revocation emulation container retrieved from non-volatile memory to determine whether to revoke use of a first asset associated with the first owner of the electronic device. In one example, the first asset associated with the first owner of the electronic device may be one of the following: a cryptographic key associated with the first owner, an executable image associated with the first owner, and a hash table associated with the first owner. At block 3960, the processor may revoke further use of the first owner's asset if it determines that the first owner's asset should be revoked.In one example, the processor may determine that the revocation of assets of the first owner is to be revoked by determining that the asset revocation information of the revocation emulation container of the first owner was programmed once.

[0241] Although the Fig. 39a-b disclose a certain number of operations in connection with the method 3900, the method 3900 may be implemented with more or fewer operations than those described in the Fig. 39a-b. For example, the method 3900 may be executed after block 3960 with additional Fig. 40-42. Moreover, the operations comprised by method 3900 may be performed in any order, even if Fig. 39 discloses a particular order of operations relating to method 3900.

[0242] Fig. 40 illustrates a flowchart of an example method 4000 for managing ownership, keys, images, and other assets related to an owner of an electronic device. According to one example, method 4000 may begin at block 4010. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 4000 and the order of blocks 4010-4015 comprising method 4000 may depend on the chosen implementation.

[0243] According to one example, block 4010 may be the same as blocks 3910-3960 in the Fig. 39a-b. At block 4015, the processor may program the first asset revocation information of the first owner's revocation emulation container once. In one example, the processor may execute trusted boot code 140 (e.g., immutable boot code or an authenticated ROM extension in the FMC) that programs the first asset revocation information of the first owner's revocation emulation container, and no instructions may be provided in boot code 140 (or other code) to deprogram this information.

[0244] Although Fig. 40 discloses a certain number of operations with respect to the method 4000, the method 4000 may be implemented with more or fewer operations than in Fig. 40. Even if Fig. 40 has a particular order of operations with respect to method 4000, the operations comprising method 4000 may be performed in any suitable order.

[0245] Fig. 41 illustrates a flowchart of an example method 4100 for managing ownership, keys, images, and other assets related to an owner of an electronic device. According to one example, method 4100 may begin at block 4110. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 4100 and the order of blocks 4110-4125 comprising method 4100 may depend on the chosen implementation.

[0246] According to one example, block 4110 may be the same as blocks 3910-3960 in the Fig. 39a-b. At block 4115, the processor may create a second owner revocation emulation container for a second owner of the device, wherein the second owner revocation emulation container may include second asset revocation information. At block 4120, the processor may use the second asset revocation information of the second owner revocation emulation container to determine whether to revoke use of a second asset associated with the second owner of the device. At block 4125, the processor may revoke further use of the owner's second asset if it determines that the owner's second asset should be revoked.

[0247] Although Fig. 41 discloses a certain number of operations in connection with the method 4100, the method 4100 may be implemented with more or fewer operations than those described in Fig. 41. For example, the method 4100 may be executed after block 4125 with additional Fig. 42. Furthermore, the operations comprising method 4100 may be performed in any order, even if Fig. 41 a specific sequence of operations is specified with respect to the method 4100.

[0248] Fig. 42 illustrates a flowchart of an example method 4200 for managing ownership, keys, images, and other assets related to an owner of an electronic device. According to one example, method 4200 may begin at block 4210. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 4200 and the order of blocks 4210-4250 comprising method 4200 may depend on the chosen implementation.

[0249] According to one example, block 4210 may be the same as blocks 4110-4125 in Fig. 41. At block 4215, the processor may generate a second unique private key based on at least one or more of the following information: (i) second owner information associated with the second owner of the device, and (ii) at least a portion of the SRAM PUF region, wherein the second unique private key may not be directly accessible by code other than the boot code. At block 4220, the processor may use the second unique private key to generate a second signature corresponding to the second owner's revocation emulation container. At block 4225, the processor may store the second signature in non-volatile memory. At block 4230, the processor may store the second owner's revocation emulation container in non-volatile memory. At block 4235, the processor may retrieve the second signature from the non-volatile memory.At block 4240, the processor may retrieve the second owner's revocation emulation container from the non-volatile memory. At block 4245, the processor may derive a second unique public key from the second unique private key. At block 4250, the processor may use the second unique public key and the second signature retrieved from the non-volatile memory to verify the second owner's revocation emulation container retrieved from the non-volatile memory.

[0250] Although Fig. 42 discloses a certain number of operations with respect to the method 4200, the method 4200 may be implemented with more or fewer operations than in Fig. 42. Although Fig. 42 has a particular order of operations with respect to method 4200, the operations comprising method 4200 may be performed in any suitable order.

[0251] Fig. 43 illustrates a flowchart of an example method 4300 for managing ownership, keys, images, and other assets related to an owner of an electronic device. According to one example, method 4300 may begin at block 4310. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. The initialization point for method 4300 and the order of blocks 4310-4325 comprising method 4300 may therefore depend on the chosen implementation.

[0252] At block 4310, for an electronic device having a processor and boot code, the processor may create a plurality of revocation emulation containers associated over time with a plurality of owners of the electronic device, wherein the respective revocation emulation containers may include revocation information of assets associated with the respective owners of the electronic device. At block 4315, the processor may program the asset revocation information of the plurality of revocation emulation containers in a one-time programmable manner. At block 4320, the processor may use the asset revocation information of the plurality of revocation emulation containers to determine whether to revoke the use of the respective assets of a plurality of assets associated with the plurality of owners of the electronic device over time.In one example, the respective assets of the plurality of assets associated with the plurality of owners of the electronic device may include one of the following: a cryptographic key associated with the respective owners of the plurality of owners, an executable image associated with the respective owners of the plurality of owners, and a hash table associated with the respective owners of the plurality of owners. At block 4325, the processor may revoke subsequent use of the respective assets of the plurality of assets associated with the plurality of owners of the electronic device over time based on the determination that the respective asset should be revoked.In one example, the processor may determine that the respective asset should be revoked by determining that the respective asset revocation information was programmed once in the respective revocation emulation container of the plurality of revocation emulation containers.

[0253] Although Fig. 43 discloses a certain number of operations with respect to the method 4300, the method 4300 may be implemented with more or fewer operations than those described in Fig. 43. For example, the method 4300 may be executed after block 4325 with additional Fig. 44 illustrated operations will continue. Although Fig. 43 has a particular order of operations with respect to method 4300, the operations comprising method 4300 may be performed in any suitable order.

[0254] Fig. 44 illustrates a flowchart of an example method 4400 for managing ownership, keys, images, and other assets related to an owner of an electronic device. According to one example, method 4400 may begin at block 4410. The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Therefore, the initialization point for method 4400 and the order of blocks 4410-4420 comprising method 4400 may depend on the chosen implementation.

[0255] According to one example, block 4410 may be the same as blocks 4310-4325 in Fig. 43. At block 4415, the processor may generate a plurality of unique private keys, wherein the respective unique private keys correspond to the respective owners of the plurality of owners of the electronic device over time, wherein the plurality of unique private keys may not be directly accessible by code other than the boot code. In one example, the processor may generate the respective unique private keys of the plurality of unique private keys based on at least one or more of the following: (i) owner information associated with the respective owners of the plurality of owners of the electronic device, and (ii) at least a portion of a region of the static random access memory (SRAM) with physically non-clonable functionality (SRAM PUF) of the electronic device.At block 4420, the processor may use the respective unique private keys of the plurality of unique private keys to sign and verify the respective revocation emulation containers of the plurality of revocation emulation containers corresponding to the respective owners of the plurality of owners of the electronic device over time.

[0256] Although Fig. 44 discloses a certain number of operations with respect to the method 4400, the method 4400 may be implemented with more or fewer operations than in Fig. 44. Even if Fig. 44 has a particular order of operations with respect to method 4400, the operations comprising method 4400 may be performed in any suitable order.

[0257] Methods 1700, 2000-3000, 3600, and 3900-4400 may be implemented with system 100 or another system operable to implement methods 1700, 2000-3000, 3600, and 3900-4400. Although the examples above comprise a description, other variations and examples may be derived from this disclosure without departing from the spirit and scope of these disclosed examples. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US 63 / 423,021

[0001] Cited non-patent literature

[0000] PUF Engine 1955 (FIGURE 19

[0023]

Claims

[1] Device comprising: a boot code; a non-volatile memory; where the boot code is executable by a processor to: generate a first unique private key, wherein the first unique private key is not directly accessible by any code other than the boot code; create a first owner revocation emulation container for a first owner of the device, the first owner revocation emulation container comprising first asset revocation information; use the first unique private key to generate a first signature corresponding to the revocation emulation container of the first owner; to store the first signature in non-volatile memory; store the first owner's revocation emulation container in non-volatile memory; retrieve the first signature from non-volatile memory; retrieve the first owner's revocation emulation container from non-volatile memory; derive a first unique public key from the first unique private key; use the first unique public key and the first signature retrieved from the non-volatile memory to verify the first owner's revocation emulation container retrieved from the non-volatile memory; after successful verification of the revocation emulation container of the first owner retrieved from the non-volatile memory, use the first asset revocation information of the revocation emulation container of the first owner retrieved from the non-volatile memory to determine whether the use of a first asset associated with the first owner of the device should be revoked; and to withdraw the subsequent use of the owner's first asset based on the determination that the owner's first asset should be withdrawn. [2] The apparatus of claim 1, wherein the boot code comprises an immutable boot code stored in a read-only memory. [3] Device according to one of claims 1 to 2, comprising: a static random access memory (SRAM) containing a region of physically non-clonable functionality (SRAM PUF); wherein the processor-executable boot code for generating a first unique private key comprises at least one or more of the following: (i) first owner information associated with the first owner of the device, and (ii) at least a portion of the SRAM PUF region. [4] Apparatus according to any one of claims 1 to 3, wherein the boot code is executable by the processor to: to program the first asset revocation information of the first owner's revocation emulation container in a one-time programmable manner. [5] The apparatus of claim 4, wherein programming the first asset revocation information of the first owner's revocation emulation container in a one-time programmable manner comprises no boot code being present to modify the first asset revocation information of the first owner's revocation emulation container after it has been programmed by the boot code. [6] The apparatus of any one of claims 4 to 5, wherein the boot code executable by the processor to revoke subsequent use of the first owner's asset based on a determination that the first owner's asset should be revoked comprises determining the first asset revocation information of the first owner's revocation emulation container that was programmed once. [7] The device of any one of claims 1 to 6, wherein the first asset associated with the first owner of the device comprises one of the following: a cryptographic key associated with the first owner, an executable image associated with the first owner, and a hash table associated with the first owner. [8] Apparatus according to any one of claims 1 to 7, wherein the boot code is executable by the processor to: create a second owner revocation emulation container for a second owner of the device, the second owner revocation emulation container comprising second asset revocation information; use the second asset revocation information of the second owner's revocation emulation container to determine whether to revoke the use of a second asset associated with the second owner of the device; and to withdraw the subsequent use of the owner's second asset based on a determination that the second asset should be withdrawn. [9] Device according to claim 8, comprising: a static random access memory (SRAM) containing a region of physically non-clonable functionality (SRAM PUF); where the boot code is executable by the processor to: generate a second unique private key based on at least one or more of the following information: (i) second owner information associated with the second owner of the device, and (ii) at least a portion of the SRAM PUF region, wherein the second unique private key is not directly accessible by code other than the boot code; use the second unique private key to generate a second signature corresponding to the revocation emulation container of the second owner; to store the second signature in non-volatile memory; to store the second owner's revocation emulation container in non-volatile memory; retrieve the second signature from non-volatile memory; retrieve the second owner's revocation emulation container from non-volatile memory; derive a second unique public key from the second unique private key; use the second unique public key and the second signature retrieved from the non-volatile memory to verify the revocation emulation container of the second owner retrieved from the non-volatile memory. [10] Method comprising: for an electronic device having a processor, non-volatile memory, boot code, and static random access memory (SRAM) including an SRAM region with physically non-clonable functionality (SRAM PUF), the processor generates a first unique private key based on at least one or more of (i) first ownership information associated with a first owner of the electronic device and (ii) at least a portion of the SRAM PUF region, wherein the first unique private key is not directly accessible by code other than the boot code; the processor generates a first owner revocation emulation container for the first owner of the electronic device, the first owner revocation emulation container comprising first asset revocation information; the processor uses the first unique private key to generate a first signature corresponding to the revocation emulation container of the first owner; the processor stores the first signature in the non-volatile memory; the processor stores the first owner's revocation emulation container in the non-volatile memory; the processor retrieves the first signature from non-volatile memory; the processor retrieves the first owner's revocation emulation container from non-volatile memory; the processor derives a first unique public key from the first unique private key; the processor uses the first unique public key and the first signature retrieved from the non-volatile memory to verify the first owner's revocation emulation container retrieved from the non-volatile memory; upon successful verification of the revocation emulation container of the first owner retrieved from the non-volatile memory, the processor uses the first asset revocation information of the revocation emulation container of the first owner retrieved from the non-volatile memory to determine whether the use of a first asset associated with the first owner of the electronic device should be revoked; and the processor withdraws subsequent use of the owner's first asset based on a determination that the owner's first asset should be withdrawn. [11] A method according to claim 10, comprising: the processor programs the first asset revocation information of the first owner's revocation emulation container in a programmable manner. [12] The method of claim 11, wherein the processor revoking subsequent use of the first owner's asset based on a determination that the first owner's asset should be revoked comprises the first asset revocation information of the first owner's revocation emulation container being programmed once. [13] The method of any one of claims 10 to 11, wherein the first asset associated with the first owner of the electronic device comprises one of the following elements: a cryptographic key associated with the first owner, an executable image associated with the first owner, and a hash table associated with the first owner. [14] A method according to any one of claims 10 to 13, comprising: the processor creates a second owner revocation emulation container for a second owner of the device, the second owner revocation emulation container comprising second asset revocation information; the processor uses the second asset revocation information of the second owner's revocation emulation container to determine whether to revoke the use of a second asset associated with the second owner of the device; and the processor revokes subsequent use of the owner's second asset based on a determination that the owner's second asset should be revoked. [15] A method according to claim 14, comprising: the processor generates a second unique private key based on at least one or more of the following information: (i) second owner information associated with the second owner of the device, and (ii) at least a portion of the SRAM PUF region, wherein the second unique private key is not directly accessible by code other than the boot code; the processor uses the second unique private key to generate a second signature corresponding to the revocation emulation container of the second owner; the processor stores the second signature in the non-volatile memory; the processor stores the revocation emulation container of the second owner in the non-volatile memory; the processor retrieves the second signature from non-volatile memory; the processor retrieves the second owner's revocation emulation container from non-volatile memory; the processor derives a second unique public key from the second unique private key; the processor uses the second unique public key and the second signature retrieved from the non-volatile memory to verify the second owner's revocation emulation container retrieved from the non-volatile memory. [16] Method comprising: for an electronic device having a processor and boot code, the processor generates a plurality of revocation emulation containers associated with a plurality of owners of the electronic device over time, the respective revocation emulation containers comprising asset revocation information associated with the respective owners of the electronic device; the processor programs the asset revocation information of the plurality of revocation emulation containers in a one-time programmable manner, wherein the processor uses the asset revocation information of the plurality of revocation emulation containers to determine whether to revoke the use of respective assets of a plurality of assets associated with the plurality of owners of the electronic device over time; and the processor revokes subsequent use of respective assets of the plurality of assets associated with the plurality of owners of the electronic device over time based on a determination that the respective asset should be revoked. [17] A method according to claim 16, comprising: the processor generates a plurality of unique private keys, wherein the respective unique private keys correspond to the respective owners of the plurality of owners of the electronic device over time, wherein the plurality of unique private keys are not directly accessible by any code other than the boot code; and the processor uses the respective unique private keys of the plurality of unique private keys to sign and verify the respective revocation emulation containers of the plurality of revocation emulation containers corresponding to the respective owners of the plurality of owners of the electronic device over time. [18] The method of claim 17, wherein the processor generating a plurality of unique private keys comprises generating respective unique private keys from the plurality of unique private keys based on at least one or more of: (i) owner information associated with respective owners of the plurality of owners of the electronic device, and (ii) at least a portion of a region of a static random access memory (SRAM) with physically non-clonable functionality (SRAM PUF) of the electronic device. [19] The method of any one of claims 16 to 18, wherein the processor revoking subsequent use of respective assets of the plurality of assets based on a determination that the respective asset should be revoked comprises determining respective asset revocation information of the respective revocation emulation container of the plurality of revocation emulation containers that was programmed once. [20] The method of any one of claims 16 to 19, wherein the respective assets of the plurality of assets associated with the plurality of owners of the electronic device comprise, over time, one of the following features: a cryptographic key associated with the respective owners of the plurality of owners, an executable image associated with the respective owners of the plurality of owners, and a hash table associated with the respective owners of the plurality of owners.

Images