Owner revocation simulation container

Abstract

A device having a processor and boot code that may create a plurality of revocation simulation containers corresponding to a plurality of owners of an electronic device over time, where respective revocation simulation containers may include asset revocation information associated with respective owners of the electronic device. The processor may program the asset revocation information of the plurality of revocation simulation containers in a one-time programmable manner. The processor may use the asset revocation information of the plurality of revocation simulation containers to determine whether to revoke use of a respective asset of a plurality of assets associated with the plurality of owners of the electronic device over time. The processor may revoke subsequent use of a respective asset 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.

Description

[0001] priority

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 423,021, filed on November 6, 2022, the contents of which are hereby incorporated in their entirety. Technical Field

[0003] The present disclosure relates to electronic devices, and more particularly to systems and methods for managing an owner revocation emulation container (REC) of keys, images, and other assets associated with an owner of an electronic device. Background Art

[0004] In computing products, an embedded controller (EC) boot code stored in a boot ROM can act as a root of trust (RoT) for secure boot applications for a specific owner of an electronic device (e.g., an original equipment manufacturer (OEM)). The OEM may store configuration options in a one-time programmable (OTP) memory during device provisioning. This may include cryptographic keys for encrypting and signing boot images. The OEM may implement EC boot images loaded and authenticated by the EC boot code stored in the boot ROM and sign these EC boot images. The EC boot code may use custom values ​​stored in the OTP memory to authenticate and decrypt the boot image. Other features supported by the EC boot code may include key revocation and image rollback protection. This may allow the owner to deactivate one or more keys in a key list stored on the electronic device, or remove a specific image revision from service, particularly by setting a bit in the OTP memory during the boot sequence. The concepts of key revocation and image rollback protection may be applicable to the first variable code (FMC) loaded and authenticated by the boot ROM. These concepts may 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 provided in OTP memory that is determined by the first owner (e.g., OEM) at manufacturing time. An image authentication key list is generated, hashed, and stored in a key hash binary large object (KHB), and the hash of the KHB is stored in OTP memory. Therefore, all owners of the device can use images signed by the OEM.

[0006] An EC with secure boot can have multiple owners during the life of the device. Each owner can configure the part to use a unique set of keys and image revisions, which are used to verify the FMC during the boot ROM authentication sequence. These keys and images can be verified using key revocation and image rollback protection information. When key revocation and image rollback protection are stored in OTP memory, all owners of the device must share the key revocation and image rollback bits. If 32 bits in OTP memory are allocated for key revocation, and the first owner of the device revokes 31 keys, the second owner of the device will only be able to support one key.

[0007] Therefore, there is a need to manage key revocation and image rollback protection information so that subsequent owners of electronic devices are not restricted by the previous owner's use of key revocation and image rollback protection features. Summary of the invention

[0008] According to one example, a device may have a boot code and a non-volatile memory. 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 code other than the boot code; create a first owner revocation simulation container for a first owner of the device, the first owner revocation simulation container including first asset revocation information; use the first unique private key to generate a first signature corresponding to the first owner revocation simulation container; store the first signature in the non-volatile memory; store the first owner revocation simulation container in the non-volatile memory; retrieve the first signature from the non-volatile memory; retrieve the first owner revocation simulation container from the non-volatile memory; simulation container; 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 first owner revocation simulation container retrieved from the non-volatile memory; after successfully verifying the first owner revocation simulation container retrieved from the non-volatile memory, using the first asset revocation information of the first owner revocation simulation container retrieved from the non-volatile memory to determine whether to revoke use of a first owner asset associated with the first owner of the device; and revoking subsequent use of the first owner asset based on determining that the first owner asset should be revoked.

[0009] Another example provides a method for an electronic device having a processor, a non-volatile memory, a boot code, and a static random access memory (SRAM) including a SRAM physically unclonable function (SRAM PUF) region. The method may include the processor generating a first unique private key based on at least one or more of the following: (i) first owner 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, the first owner revocation emulation container including first asset revocation information. The method may include the processor using the first unique private key to generate a first signature corresponding to the first owner 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 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 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 include the processor using the first unique public key and the first signature retrieved from the non-volatile memory to verify the first owner revocation simulation container retrieved from the non-volatile memory. Upon successful verification of the first owner revocation simulation container retrieved from the non-volatile memory, the method may include the processor using the first asset revocation information of the first owner revocation simulation container retrieved from the non-volatile memory to determine whether to revoke the use of the first owner asset associated with the first owner of the electronic device. The method may include the processor revoking subsequent use of the first owner asset based on determining that the first owner asset should be revoked.

[0010] Another example provides a method for an electronic device having a processor and a boot code. The method may include the processor creating a plurality of revocation simulation containers corresponding to a plurality of owners of the electronic device over time, wherein the corresponding revocation simulation containers may include asset revocation information associated with the corresponding owners of the electronic device. The method may include the processor programming the asset revocation information of the plurality of revocation simulation containers in a one-time programmable manner. The method may include the processor using the asset revocation information of the plurality of revocation simulation containers to determine whether to revoke the use of a corresponding asset among a plurality of assets associated with the plurality of owners of the electronic device over time. The method may include the processor revoking subsequent use of the corresponding asset based on determining that the corresponding asset among the plurality of assets associated with the plurality of owners of the electronic device over time should be revoked. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The figures illustrate example methods and systems for managing keys, images, and other assets associated with an owner of an electronic device.

[0012] Figure 1 A block diagram illustrating an example system for managing ownership, keys, images, and other assets associated with an owner of an electronic device.

[0013] Figure 2 A block diagram illustrating an example OTP memory for managing ownership, keys, images, and other assets associated with an owner of an electronic device.

[0014] Figure 3 A block diagram illustrating an example secure RPMC owner container for managing ownership, keys, images, and other assets associated with an owner of an electronic device.

[0015] Figure 4 A block diagram illustrating an example container header for an owner container for managing ownership of an electronic device.

[0016] Figure 5 A block diagram illustrating example container contents of an owner container for managing ownership of an electronic device.

[0017] Figure 6 A block diagram illustrating example container contents of an owner container for managing ownership of an electronic device.

[0018] Figure 7 An example command memory is illustrated.

[0019] Figure 8 A block diagram illustrating an example of managing ownership of an electronic device, including creating a first owner container by using an OEM-signed image and an OTP configuration.

[0020] Fig. 9 A block diagram illustrating an example of managing ownership of an electronic device, including creating a first owner container by using an OEM-signed image and an OTP emulation configuration.

[0021] Fig.10 A flow chart illustrating an example method for managing ownership of an electronic device, including the secure transfer of ownership of the electronic device over time.

[0022] Fig.11 and Fig.12 Block diagram illustrating two examples of using unrestricted transfer and an owner transfer authorization key (OTAK) to manage ownership of an electronic device.

[0023] Fig.13 A block diagram illustrating an example of managing ownership of an electronic device, including transferring ownership by using a container command (CCK) key of the current owner and a first changeable binary (FMB) configuration stored in an OTP memory.

[0024] Fig.14 A flow chart illustrating an example method for managing ownership of an electronic device, including the secure transfer of ownership of the electronic device over time.

[0025] Fig.15 A flow chart illustrating an example method for managing ownership of an electronic device, including the secure transfer of ownership of the electronic device over time.

[0026] Fig.16 An example volatile SRAM memory with a physically unclonable function (PUF) region that can be used for cryptographic key management is illustrated.

[0027] Fig.17 Flowchart illustrating an example method for SRAM PUF enrollment and subsequent key reconstruction.

[0028] Fig.18 An example electronic device that may respond to Security Protocol Data Model (SPDM) commands is illustrated.

[0029] Fig.19 An example electronic device with an SRAM PUF shared by multiple entities for managing device keys is illustrated.

[0030] Fig. 20 Illustrate an example boot code method for DevAK key and certificate generation.

[0031] Figure 21 to Figure 30b A flow chart illustrating an example method for managing device keys using an SRAM PUF shared by multiple entities.

[0032] Fig.31A block diagram illustrating an example OTP memory for managing keys, images, and other assets associated with an owner of an electronic device.

[0033] Fig.32 A block diagram illustrating example container contents of an owner container for managing keys, images, and other assets associated with an owner of an electronic device.

[0034] Fig.33 A block diagram illustrating an example secure revocation emulation container for managing ownership, keys, images, and other assets associated with an owner of an electronic device.

[0035] Fig.34 A block diagram illustrating an example secure revocation emulation container header for an owner container for managing ownership, keys, images, and other assets associated with an owner of an electronic device.

[0036] Fig.35 A block diagram illustrating example secure revocation emulation container contents of an owner container for managing ownership, keys, images, and other assets associated with an owner of an electronic device.

[0037] Fig.36 A flow chart illustrating an example method for undoing a simulation.

[0038] Fig.37 Block diagram illustrating various RPMC values ​​related to revocation emulation, including how a REC container may be bound to an owner container upon creation.

[0039] Fig.38 A block diagram illustrating various RPMC values ​​associated with decommissioning simulation, including how the REC RPMC value may be incremented to decommission an asset.

[0040] Figure 39 to Fig.44 A flow chart illustrating an example method for managing ownership, keys, images, and other assets associated with an owner of an electronic device.

[0041] Reference numerals for any illustrated element that appear in multiple different figures have the same meaning in the multiple figures, and reference or discussion herein to any illustrated element in the context of any particular figure also applies to every other figure (if any) in which the same illustrated element is shown. DETAILED DESCRIPTION

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

[0043] The disclosure provides systems and methods for supporting multiple owners of specific electronic equipment over time by storing the information and configuration of each owner in a storage device (for example, a serial peripheral interface (SPI) flash memory) through a signed secure replay protection monotonic counter (RPMC) owner container, including the secure transfer of ownership between different owners. In an example, the cryptographic key, secret and configuration information of the owner can be stored in a non-volatile memory (NVM) (for example, an OTP memory, SPI flash memory or an electrically erasable programmable read-only memory (EEPROM)) in a secure manner. Because security information can be stored in an erasable memory, it can be signed and verified before content is used to help security. In some examples, the system and method for storing and updating a signed secure RPMC owner container can follow the NIST 800-193 platform firmware resilience guide. As used herein, " secure RPMC owner container ", "RPMC owner container " and "owner container " refer to a signed secure RPMC owner container.

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

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

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

[0047] Security features of electronic devices can be implemented using boot code on the electronic device. In an example, the security features can be implemented using immutable boot code. The immutable boot code, which may be referred to as a hardware root of trust (RoT), may be built into the electronic device during manufacturing and may therefore be implicitly trusted because it cannot be modified.

[0048] For the purposes of this disclosure, an electronic device may include any tool or tool set that is operable to calculate, classify, process, transmit, receive, retrieve, initiate, switch, store, display, perform, detect, record, copy, dispose of or utilize any form of information, intelligence or data for commercial, scientific, control, entertainment or other purposes. For example, an electronic device may be a personal computer, a personal digital assistant (PDA), a consumer electronic device, a network storage device or any other suitable device, and may differ in size, shape, performance, function and price. An electronic device may include a memory, one or more processing resources (such as a central processing unit (CPU)) or a hardware or software control logic component. Additional components of an electronic device may include one or more storage devices, one or more communication ports for communicating with an external device, and various input and output (I / O) devices, such as a keyboard, a mouse and a video display. An electronic device may also include one or more buses that are operable to transmit communications between various hardware components.

[0049] system

[0050] Figure 1 A block diagram illustrating an example system 100 for managing ownership of an electronic device 101, including secure transfer of ownership over time through the electronic device. Figure 1 As depicted, system 100 may include electronic device 101. Components of electronic device 101 may include, but are not limited to, one or more processors 160 and a system bus 121 that communicatively couples various system components (including, for example, OTP memory 110, ROM 130, memory 170, I / O and port control device 190, and network interface 150) to processor 160. System bus 121 may be any suitable type of bus structure, such as a memory bus, a peripheral bus, or a local bus using any of a variety of bus architectures. In an example, the components of electronic device 101 may all reside on the same die. In another example, the components of electronic device 101 may include electrically coupled independent components.

[0051] Processor 160 may include any system, device, or apparatus 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 process 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.

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

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

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

[0055] The I / O and port control device 190 may include any system, device or device generally operable to receive data from / within the electronic device 101 or transmit data to / within the electronic device. The I / O and port control device 190 may include, for example, any number of communication interfaces, graphics interfaces, video interfaces, user input interfaces, or peripheral interfaces (such as, but not limited to, JTAG, I2C, UART, test access port). The I / O and port control device 190 may be communicatively coupled to external ports / pins 180-1, 180-2, ..., 180-N (and other ports / pins not depicted).

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

[0057] although Figure 1 Various components of the electronic device 101 are illustrated, but other example systems may include electronic devices with more or fewer components. In an example, without departing from the spirit and scope of these disclosed examples, the electronic device 101 according to the present disclosure may not include one or all of the components drawn in dashed lines. Additionally, the various components of the electronic device 101 may reside on the same die (e.g., the main die) or may reside on different dies. In an example, the various components may reside inside a package in a multi-chip module (MCM) or on the outside of a system board. In the same or different examples, the various components of the electronic device 101 may reside in one or more of the main dies, in an MCM, and on the outside of a system board.

[0058] OTP memory

[0059] Figure 2Block diagram illustrating an example OTP memory 110 for managing ownership of an electronic device 101, including secure transfer of ownership over time through the electronic device. Figure 2 As depicted, OTP memory 110 may include multiple areas including current RPMC value 202 , boot code generated random secret 203 , device unique random secret 204 , serial number 205 , personalization string 206 , secret device unique information 207 , and RPMC flash container state 208 .

[0060] The current RPMC value 202 can be provided by a replay protection monotone counter that increases over time. In the example shown in Table 1, the current RPMC value 202 can be a value stored in an 8-bit region in the OTP memory 110, and can correspond to nine different values ​​(0 to 8). In this example, the bit used for the current RPMC value 202 in the OTP memory 110 can be sequentially set from the lowest bit ([0]) to the highest bit ([8]), and the next RPMC value can be the next integer value after the current RPMC value 202. In the same or different examples, the value less than the current RPMC value 202 can be considered to be revoked, and the value greater than the current RPMC value 202 can be considered to be unused. In the example shown in Table 1, a value greater than 8 can not be used. In other examples in the OTP memory 110 that are assigned to the current RPMC value 202 more than eight bits, a value greater than 8 is possible. The value less than the current RPMC value 202 can be considered to be revoked, because the OTP memory 110 can not be programmed to a smaller value, because the OTP memory can only be programmed once according to definition. For example, when the current RPMC value 202 has a value of one (1), the least significant bit is programmed and cannot be unprogrammed to reset the current RPMC value 202 back to a value of zero (0).

[0061] Table 1

[0062]

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

[0064] The secret device unique 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 may be generated; (b) critical device configurations, such as image authenticity and key authenticity; (c) other cryptographic keys used by the electronic device 101; or (d) other device unique information. In some examples, the secret device unique 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 UDS and ROM seed as source data to generate the DevIK or other device unique information.

[0065] RPMC flash container state 208 can indicate whether RPMC owner feature is enabled. In an example, RPMC owner feature can be disabled by default when manufacturing, and this disabled state can be reflected in RPMC flash container state 208. Boot code 140 can program RPMC flash container state 208 to indicate that owner feature is enabled when the first owner container is created.

[0066] although Figure 2 Various regions of the OTP memory 110 are illustrated, but other example systems may include electronic devices having more or fewer regions.

[0067] RPMC Owner Container

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

[0069] - Container Signature

[0070] The container signature 312 may include a signature corresponding to the owner container 302 and may be generated by the boot code 140. In an example, the boot code 140 may use a physical unclonable function (PUF) or a deterministic random bit generator (DRBG) to generate an ECDSA signing key. The ECDSA signing key may be generated by any signature algorithm. For example, the container signature 312 may be an ECDSA-384 signature with the following properties:

[0071] Algorithm: Elliptic Curve Digital Signature Algorithm (ECDSA)

[0072] Key size: 384 bits

[0073] Curve: NIST "secp384r1" curve

[0074] Hash algorithm: SHA384

[0075] Signed message (m) = {container header 310 | container content 311}

[0076] The boot code 140 may derive an ECDSA private signing key for signing the owner container 302. In an example, the signing key may be generated based on the current owner and the unique silicon die. Thus, there may be a unique signature for each owner of each silicon die. According to an example, the boot code 140 may use the DRBG to derive the ECDSA private signing key, and may provide the following input to the DRBG:

[0077] Personalized string: It can be a known string, such as "Container*one*Key Generator".

[0078] Additional input: can be {RPMC value 431 | device serial number 435}

[0079] Entropy input: can be a device-unique random secret 204

[0080] True Random Number Generator (TRNG) input: can be a random secret generated by the boot code 203

[0081] In the above example, boot code 140 may generate an ECDSA private signing key using the method for generating a key pair using additional random bits from B.4.1 of the FIPS 186-4 specification (although other specifications may also be used):

[0082] Private key(d)

[0083] d=(c mod(n-1)) + 1

[0084] n = a prime number defined for the P-384 curve

[0085] c = 448-bit random positive integer value

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

[0087] although Figure 3 Various regions of the owner container 302 are illustrated, but other example systems may include electronic devices having more or fewer regions.

[0088] - Container Header

[0089] Figure 4A block diagram illustrating an example container header 310 of an owner container 302 for managing ownership of an electronic device 101. In an example, the container header 310 may have a common format for owner containers created for the electronic device 101. Figure 4 As shown, the container header 310 may include areas 431 to 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 binary large object (blob) 436.

[0090] The RPMC value 431 may be provided by a replay protection monotonic counter that may be checked against the current RPMC value 202 in the OTP memory 110 to determine whether the owner container is valid or has been revoked. In an example, when the RPMC value 431 of the owner container 202 has a value of three (3), the boot code 140 may determine that the owner container is valid (e.g., Figure 2 In the same or different examples, when the RPMC value 431 of the owner container 302 has a value of three (3), the boot code 140 may determine that the owner container is revoked when 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 be used to check the primary container and the fallback container.

[0091] The active container version 432 may represent a version number of the owner container 302. In an example, the owner of the electronic device 101 may desire to update the information in the owner container 302 in a manner that does not require incrementing the RPMC value 431 (e.g., Figure 6 ). Thus, when other information is updated, the boot code 140 can increment the active container version 432. In another example, the boot code 140 can set the active container version 432 to zero (0) during the operation of incrementing the RPMC value 431. Thus, the container with the highest RPMC value 431 and the highest active container version 432 can be the primary owner container of the electronic device 101.

[0092] The container type 433 may represent a type associated with the owner container 302. In an 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 indicate the number of bytes in the owner container content 311. The device serial number 435 may correspond to the serial number of the electronic device 101, for example, the unique serial number 205 in the OTP memory 110. The container command key hash blob 436 may contain 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 example shown, the container command key hash blob 436 may include hashes of public keys CCK0 437, CCK1 438, CCK2 439, and CCK3 440. In an example, these key hashes may be used to verify commands 302 associated with the owner container. (Alternatively, container command key hash blob 436 may contain the public key instead of the hash of the public key. In this example, more memory may be required.) In the example, CCK0-3 (437 to 440) may be revoked by setting the hash entry to zero (0). Although Figure 4 Various regions of the container header 310 are illustrated, but other example systems may include electronic devices having more or fewer regions.

[0093] - Container content

[0094] The owner container 302 may have different configurations based on the configuration source, including:

[0095] FMB image configuration source = OTP memory (e.g. Figure 5 )

[0096] FMB image configuration source = OTP emulation in SPI flash RPMC container (e.g. Figure 6 )

[0097] Figure 5 A block diagram illustrating example container content 311a of an owner container 302 for managing ownership of an electronic device 101. Figure 5As shown, container content 311a can be programmed in OTP memory 110 and can include areas 501 to 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 binary large object (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 an example, some or all of container content 311a can be programmed into OTP memory 110 during provisioning (e.g., by a tester). In the same or different examples, after provisioning of electronic device 101 is completed, some or all of container content 311a can be programmed into OTP memory 110 by boot code 140. Higher-level firmware (e.g., code other than the code that creates the container) may require a command interface (e.g., command memory 171, Figure 7 ) to access or modify the information in the container content 311a of the owner container 302.

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

[0099] The owner configuration 501 may include information about who can transfer ownership of the electronic device 101. In an example, the current silicon owner can transfer ownership by executing an ownership transfer command signed by the owner's public container command key (CCK). In another example, both the current silicon owner and the new owner can transfer ownership. The current silicon owner can transfer ownership to the new owner by executing an ownership transfer command signed by the owner's public CCK, and the new owner can transfer ownership by executing an ownership transfer command signed by an owner transfer authorization key (OTAK). The OTAK can be a public key (e.g., in the owner transfer authorization key 504) programmed into the owner container 302 by the current owner, which can enable the new owner (or an approved intermediate entity) to execute the ownership transfer command. The owner configuration 501 may include information indicating whether the RPMC owner container crisis command is supported. In an example, if the crisis command is enabled, the owner can use the I / O port control device 190 (e.g., I2C crisis port, UART crisis port) to insert the owner container command into the command memory 171 (e.g., Figure 7 ). In an example, the owner container crisis command may be disabled by default and may be enabled by the owner of the electronic device 101 (eg, by programming the owner configuration 501).

[0100] Owner ID 502 can be a value provided by the owner when ownership is transferred, and can be used to identify the owner. Owner RPMC 503 can be a value determined by boot code 140 when ownership is transferred. For example, it can be the first RPMC value assigned to the owner when ownership is transferred. In an example, owner ID 502 and owner RPMC 503 can indicate the only owner of a specific electronic device 101 together. Owner transfer authorization key (OTAK) 504 can be a one-time ECDSA-384 public key (elliptic curve digital signature algorithm) for verifying the transfer of ownership commands, for example, when the configuration information in the owner configuration 501 enables the new owner to execute the transfer of owner commands.

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

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

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

[0104] although Figure 5 Various regions of container content 311a are illustrated, but other example systems may include electronic devices with more or fewer regions. In additional examples, specific regions of container content 311a may include features in addition to those described above, or some of the features described above may be omitted.

[0105] Figure 6 A block diagram illustrating example container content 311b of an owner container 302 for managing ownership of an electronic device 101. Figure 6 As shown, container content 311b may be programmed in non-volatile memory 173 and may include regions 501 to 515, which are related to Figure 5 Described and difference is that they are stored in the non-volatile memory 173 instead of the OTP memory 110. In the example, the owner container 302 with the container content 311b stored in the non-volatile memory 173 can simulate the owner container (OTP simulation) stored in the OTP memory 110, because the boot code 140 can store configuration parameters (for example, in the container content 311b) when it creates the owner container, and there is no command for boot code 140 (or other code) to modify these parameters. In the case where a malicious user may try to change the secure RPMC owner container 302 while the secure RPMC owner container is stored in the non-volatile memory 173 (for example, to change any parameters through OTP simulation), the verification of this container will fail. Therefore, the configuration parameters stored in the owner container 302 in the non-volatile memory 173 can be regarded as simulating the OTP memory.

[0106] In an example, the container content 311b may include a PUF activation code 621 (e.g., “PUF” refers to Physically Unclonable Function, described in more detail below). The boot code 140 may use the PUF activation code 621 to generate a device attestation key (DevAK) and pass it to the silicon owner's firmware. In an example, at the first power-on reset cycle after the owner container content 311b is created or updated, the boot code 140 may use the shared SRAM PUF to generate the PUF activation code 621 and store it in the owner container content 311b. During a subsequent boot process, if the boot code 140 loads a trusted image (e.g., FMB), the boot code 140 may use the PUF activation code 621 to generate a DevAK private key and public key. In an example, the boot code 140 may place the DevAK public key in an X.509 certificate and sign the certificate using the DevIK private key (e.g., Figure 2 In an example, the signed certificate along with the PUF activation code 621 may be delivered to the owner's firmware (e.g., via Figure 7 The owner's firmware can use the PUF activation code 621 to regenerate the DevAK private key.

[0107] Additional examples of PUF activation code 621, SRAM PUF, DevAK and DevIK keys, and device certificates are provided in Figure 16 to Figure 3 0 and the associated description (Physically Unclonable Function (PUF) SRAM section below).

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

[0109] although Figure 6Various regions of container content 311b are illustrated, but other example systems may include electronic devices with more or fewer regions. In additional examples, specific regions of container content 311b may include features in addition to those described above, or some of the features described above may be omitted.

[0110] Command interface

[0111] Figure 7 An example command memory 171 is illustrated. The command memory 171 may include a rewritable memory (e.g., registers, SRAM) and may contain an RPMC container command 782, a boot code mailbox 784, and a firmware mailbox 786. According to an example, the boot code 140 may authenticate and optionally decrypt an FMB from a non-volatile memory 173 (e.g., SPI flash memory), and then may load the FMC into an internal volatile memory 172 (e.g., SRAM) for subsequent execution by the processor 160. For example, the boot code may load an FMB into an internal volatile memory 172 (e.g., SRAM), authenticate the FMB, and optionally decrypt the FMB, which may include one or more images, including an FMC as a first image. In an example, the authenticated and optionally decrypted FMB is retained in the volatile memory 172 (e.g., SRAM). The binary image may be referred to as an "owner" image. The boot code may then cause the processor 160 to execute the FMC (e.g., jump to the base address of the FMC). The FMC may be a ROM extension (e.g., an authenticated ROM extension in the FMC) or application firmware. The owner application may communicate with the boot code 140 or ROM_EXT to request a transfer of ownership or to perform some other action on its behalf. The application may communicate the action by loading a signed command into the boot code mailbox 784, setting the associated command bit in the RPMC container command 782, and triggering a reset (e.g., a soft reset).

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

[0113] In an example, RPMC container commands 782 may include positions that may indicate that RPMC commands are pending for electronic device 101 when being set. RPMC container commands 782 may additionally include command fields that may indicate the specific commands that boot code 140 will handle. In identical or another example, boot code mailbox 784 may be programmed with command parameters corresponding to pending commands. In an example, the command parameters that may be stored in the boot code mailbox 784 may be signed, and boot code 140 may authenticate pending commands during the boot process (for example, when the parameters that may be stored in the boot code mailbox 784 are signed, this command may be considered to be a signed command) before executing the command.

[0114] Owner container actions

[0115] The following non-exclusive list of operations may be performed on the owner container 302:

[0116] CREATE_CONTAINER_REQUEST

[0117] INCREMENT_RPMC_REQUEST

[0118] UPDATE_CONTAINER_REQUEST

[0119] ·REPAIR_FALLBACK_CONTAINER_REQUEST

[0120] CRISIS_RECOVERY_REQUEST

[0121] ·ENABLE_UNRESTRICTED_TRANSFERS

[0122] UPDATE_OTAK_KEY

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

[0124] - CREATE_CONTAINER_REQUEST life make

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

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

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

[0128] If the verification is successful, the boot code 140 may create a signed owner container 302. In an example, the boot code 140 may store the successful command status in the firmware mailbox 786. In an example, the boot code 140 may save the corresponding command parameters (in the boot code mailbox 784) to the corresponding area in the container header 310 ( Figure 4 433 to 434 and 437 to 440 in the container content 311b) and the corresponding area in the container content 311b ( Figure 5 501 to 502 and 505 to 515 in ). The boot code 140 may use the following for the new signed owner container 302:

[0129] RPMC Value 431 (and Owner RPMC 503): May default to zero (since this is the first owner container). Boot code 140 may check if any bits of the current RPMC value 202 in OTP memory are set, and if so, set these to the first valid non-zero value.

[0130] Activity container version 432: may default to zero.

[0131] Device Serial Number 435: can be set to the value stored in OTP Serial Number 205.

[0132] • Owner transfer authorization key 504: may default to zero.

[0133] PUF Activation Code 621: May default to zero when processing a CREATE_CONTAINER_REQUEST command. The boot code 140 may generate the PUF Activation Code 621 and store it in the signed owner container 302 after the next power cycle.

[0134] - INCREMENT_RPMC_REQUEST Command

[0135] This signed command can be called to make the boot code 140 increment the RPMC value 431 of the main owner container 302 (without changing the contents of other containers). If allowed, the boot code 140 can retrieve the main owner container 302, increment the RPMC value 431, and reset the active container version 432 back to zero. The boot code 140 can erase the main container and the fallback container stored in the non-volatile memory 173, and store the updated owner container 302 in their position. Once the two containers are successfully updated, the boot code can increment the current RPMC value 202 in the OTP memory 110, which can revoke the previous container.

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

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

[0138] - UPDATE_CONTAINER_REQUEST Command

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

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

[0141] If (1) verification of both the selected OTAKpub or CCKpub key and the command signature succeeds and (2) the subcommand is "transfer ownership", boot code 140 may update signed owner container 302. In an example, boot code 140 may transfer the corresponding Figure 4 Regions 433 to 434 and 437 to 440 (container header 310) and Figure 6 The command parameters 501 to 502 and 505 to 515 (container content 311b) in the boot code mailbox 784 are saved to the corresponding areas in the container header 310 and the container content 311b of the updated signed owner container 302. The boot code 140 may use the following default values ​​for the updated signed owner container 302:

[0142] ●RPMC value 431 (and owner RPMC503): {current RPMC value 202+1} can be used.

[0143] ●Activity container version 432: may default to zero.

[0144] ●Device serial number 435: can be set to the value stored in OTP serial number 205.

[0145] = Owner Transfer Authorization Key 504: May default to zero.

[0146] PUF Activation Code 621: May default to zero when processing the CREATE_CONTAINER_REQUEST command. The boot code 140 may generate the PUF Activation Code 621 and store it in the signed owner container 302 after the next power cycle.

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

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

[0149] - REPAIR_FALLBACK_CONTAINER_REQUEST command

[0150] This signature command may be called to cause the 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, the boot code 140 may erase the fallback container and copy the primary container to the fallback container location. In an example, the boot code 140 may use command parameters for the REPAIR_FALLBACK_CONTAINER_REQUEST command stored in the boot code mailbox 784. The command parameters may include an indication of which of the signature public keys (CCKpub or OTAKpub, OTAKpub or CCK0-CCK3 (a hash in the current owner container header 310 area 436) is used for verification and a command signature signed with the private key OTAKpriv or CCKpriv. The boot code may verify the signature public key and command signature for the REPAIR_FALLBACK_CONTAINER_REQUEST command using the same mechanism disclosed for UPDATE_CONTAINER_REQUEST (above). In the example, In the example, if the verification is successful and no error is detected when updating the fallback container, the matching fallback container may be stored in the non-volatile memory 173 (e.g., SPI flash memory), resulting in the matching main container and fallback container being stored in the non-volatile memory 173, and the boot code 140 may store the successful command status in the firmware mailbox 786. If the verification fails or an error is detected, there may be no change (e.g., the main container is still valid in the non-volatile memory 173, and the fallback container is still invalid). In the latter example, the boot code 140 may store the unsuccessful command status in the firmware mailbox 786.

[0151] - CRISIS_RECOVERY_REQUEST Command

[0152] This signature command may be called to cause the boot code 140 to recover from a situation where the primary container and the fallback container are invalid. In an example, this command may be serviced when both containers are invalid. The boot code 140 may allow the owner to restore the saved copy of the working owner container using a crisis command (e.g., RESTORE_OWNER_CONTAINER) issued via the I / O port control device 190 (e.g., I2C crisis port, UART crisis port).

[0153] - ENABLE_UNRESTRICTED_TRANSFERS command

[0154] This signed command may be invoked to cause the boot code 140 to perform the following owner container 302 updates:

[0155] ● Update Owner Configuration 501 ( Figure 5 ) so that both the current silicon owner and the new owner can transfer ownership of the electronic device 101.

[0156] ●Provide Owner Transfer Authorization Key 504.

[0157] ●Increment activity container version 432 ( Figure 4 ).

[0158] ●Re-sign the owner container 302.

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

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

[0161] - UPDATE_OTAK_KEY Command

[0162] This signed command may be invoked to cause the boot code 140 to perform the following owner container 302 updates:

[0163] • Provide owner transfer authorization key 504.

[0164] ·Increment activity container version 432 ( Figure 4 ).

[0165] • Re-sign the owner container 302.

[0166] This signed command may allow an intermediate entity with the OTAKpriv private key to cause the above-mentioned update. In an example, the boot code 140 may ignore the command unless the owner configuration 501 is configured to allow both the current silicon owner and the new owner to transfer ownership of the electronic device 101 (eg, unrestricted transfer is enabled).

[0167] In an example, the boot code 140 may store the command parameters for the UPDATE_OTAK_KEY command in the boot code OTAK 784. The command parameters may include a new OTAKpub_new public key (e.g., for provisioning the owner transfer authorization key 504), a signature public key (CCKpub or OTAKpub), an indication of which of OTAKpub or CCK0-CCK3 to use for verification (the hash in the current owner container header 310 area 436), and a command signature signed with the private key OTAKpriv or CCKpriv. Before updating the owner container 302, the boot code 140 may use OTAKpub or CCKpub (whichever is indicated to be used) to verify the command signature. In an example, the boot code 140 may verify the command parameter CCKpub by calculating a hash of the command parameter CCKpub and comparing it to the corresponding CCKpub hash (CCK0-CCK3) stored in the current owner container header 310. (The information in the current owner container header 310 can be authentic because the owner container 302 can be verified by the boot code 140. In another example, the boot code 140 can verify the command parameter OTAKpub by comparing the command parameter OTAKpub to the owner transfer authorization key 504 stored in the current owner container content 311b. If the verification of (1) the selected OTAKpub or CCKpub key or (2) the command signature fails, the boot code 140 can stop the execution of the UPDATE_OTAK_KEY command without modifying the current owner container 302. In an example, the boot code 140 can store the unsuccessful command status in the firmware mailbox 786.

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

[0169] Ownership of electronic devices

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

[0171] Establishing Ownership

[0172] During manufacturing, the OTP memory 110 may be provisioned with OEM image configuration parameters, which may include a KHB hash 507 for authenticating the OEM image stored in the non-volatile memory 173 (e.g., SPI flash memory). Other parameters in the OTP memory 110 (e.g., Figure 2 and Figure 5 ) can also be supplied by the OEM during manufacturing. Such a configuration can be referred to as a "legacy secure boot" state. In this state, only a signed OEM image (e.g., FMB) can be authenticated and executed on the electronic device 101.

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

[0174] The OEM owner container 302 may be created by trusted firmware loaded from non-volatile memory 173 (e.g., SPI flash) or via code loaded into volatile memory 172 (e.g., SRAM) through I / O and port control device 190 (e.g., I2C port, UART port). The firmware may store a CREATE_CONTAINER_REQUEST command into boot code mailbox 784 ( Figure 7 ), sets the RPMC container command 782 to indicate a pending request, and asserts a reset (e.g., a soft reset).

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

[0176] Fig. 9The illustration includes a block diagram of an example of managing ownership of an electronic device 101 by creating a first owner container using an OEM-signed image and an OTP emulation configuration. The contents of a non-volatile memory 973 (e.g., SPI flash memory) are shown at time t0 and include: OTP TAG0 / 1 image header base address, OTP KHB (primary and fallback), and OTP TAG0 / 1 image + header (e.g., FMB). At time t0, there may be no owner of the electronic device 101, although the OEM may be an implicit owner. In the example, at time t1, the OEM application code may write (1) owner container 0 / 1 base address, (2) owner A KHB (primary and fallback), and (3) owner A TAG0 / 1 image + header (e.g., FMB) to the non-volatile memory 973. At time t2, the OEM application code may store a CREATE_CONTAINER_REQUEST command to the RPMC container command area in the command memory 971, and may store the container parameters of the new owner (owner A) in the boot code mailbox in the command memory 971. In an example, parameters corresponding to owner configuration parameters 501 may specify an OTP emulation configuration for owner A. At time t3, the OEM application code may cause a soft system reset of the electronic device 101. During the boot process, the boot code 140 may be notified of a pending CREATE_CONTAINER_REQUEST command and process the command. At time t4, if the command is successful, the boot code 140 may write the owner A container 0 / 1 (primary container and fallback container) to the non-volatile memory 973 and begin executing the owner A image (e.g., TAG0 image). As shown, after time t4, the electronic device 101 may be owned by owner A using the owner A image. In an example, after time t4, the owner A application may read the command status bits ( Figure 7 ) to verify the successful completion of the command. The owner A application may optionally read the owner A container 0 / 1 from the non-volatile memory 973 and verify the contents. In an example, the owner A application may optionally save a copy of the owner A container 0 / 1 as a backup.

[0177] Boot sequence for electronic devices with RPMC owner container

[0178] Fig.10A flow chart illustrating an example method 1000 for managing ownership of an electronic device, including secure transfer of ownership of the electronic device over time. According to one example, the method 1000 may start at block 1005. In an example, the method 1000 may be performed by the boot code 140. In some examples, the start block 1005 may represent the time when the electronic device 101 is first powered on (POR) or the time after the electronic device is reset (e.g., device reset, reboot, or power cycle). Therefore, the method 1000 may be performed 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 been loaded). The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Therefore, the initialization point of the method 1000 and the order of 1005 to 1045 that constitute the method 1000 may depend on the specific implementation selected.

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

[0180] If the boot code determines in block 1010 that the OTP memory is fully provisioned, it may proceed to block 1025 where it may determine whether to enable owner features in the OTP memory 110. In an example, this feature may be disabled by default (i.e., at the time of manufacture). If the owner feature is not enabled, the boot code may proceed to block 1040 where it may load a 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 firmware signed by the OEM may be loaded and executed (also referred to as a "legacy secure boot"). In an example, the OEM may enable the owner feature by issuing a CREATE_CONTAINER_REQUEST command (e.g., Figure 8 and Fig. 91025 places) to enable the owner feature. If the boot code determines that the owner feature is enabled in the OTP memory 110 at frame 1025, the boot code can proceed to frame 1035, wherein it can determine whether the FMB mirror configuration source is OTP emulation. If the FMB mirror configuration source is not OTP emulation, the mirror configuration source can be OTP memory. In this example, the boot code can proceed to frame 1040 for traditional secure booting. If the boot code determines that the FMB configuration mirror source is OTP emulation at frame 1035 places, the boot code can proceed to frame 1045, wherein it can attempt to load firmware using the RPMC owner container information stored in the non-volatile memory 173 (e.g., SPI flash memory). In an example, frame 1045 can represent a secure boot process using the RPMC owner container stored in the non-volatile memory 173.

[0181] although Fig.10 A specific number of operations are disclosed in connection with method 1000, but method 1000 may utilize more Fig.10 More or fewer operations may be performed than those depicted. In addition, although Fig.10 A certain order for operations to be taken with respect to method 1000 is disclosed, but the operations making up method 1000 may be performed in any suitable order.

[0182] Transferring ownership of electronic devices

[0183] In an example, the OEM may be the first silicon owner (e.g., the owner of the electronic device 101). However, the owner may change one or more times during the life of the electronic device. The owner is the entity that can determine the key used to authenticate the FMB image. The transfer of ownership may be the act of changing the entity responsible for determining the FMB signing key.

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

[0185] In some examples, there can be three types of ownership transfers:

[0186] The current owner performs the transfer to the new owner.

[0187] A trusted intermediary entity performs the transfer to the new owner (unrestricted transfer).

[0188] • The current owner enables the new owner to claim ownership (unrestricted transfer).

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

[0190] An Owner Transfer Authorization Key (OTAK) can support a one-time transfer of ownership to a new owner while avoiding providing the new owner's information to the current owner. Using OTAK transfer (which may be referred to as "unrestricted transfer"), as long as the current owner enables OTAK transfer, the new owner can upload their information and complete the ownership transfer. OTAK ownership transfer can be completed in situations where the new owner may or may not be present when the current owner hands over the machine.

[0191] Fig.11 and Fig.12 Block diagram illustrating two examples of using unrestricted transfer and OTAK to manage ownership of electronic device 101. Fig.11 As shown, the current owner (CO) may want to transfer ownership of machine A to a new owner (NO). In the example, the current owner may rely on a trusted intermediate entity (TIE) (e.g., a sales distribution channel) to help transfer ownership to the new owner. In the example, the following events (1 to 8) may occur during the transfer.

[0192] 1-CO can send Machine A serial number to TIE and NO (if NO is known).

[0193] TIEs and NOs can use the serial number to confirm that they received the correct device (e.g.

[0194] Machine A).

[0195] 2- TIE may send the OTAKpub1 key to the CO. The OTAKpub1 key may be the public key of a public / private key pair owned by TIE.

[0196] 3-CO can run the ENABLE_UNRESTRICTED_TRANSFERS command, passing the OTAKpub1 key as the new OTAK public key for Machine A.

[0197] The 4-CO can send Machine A to the TIE.

[0198] 5-NO may send the OTAKpub2 key to TIE. The OTAKpub2 key may be the public key of a public / private key pair owned by NO.

[0199] 6- The TIE may run the UPDATE_OTAK_KEY command, passing the OTAKpub2 key as the new OTAK public key for Machine A. Because UPDATE_OTAK_KEY is a signed command, the TIE may sign the command with the TIE's OTAKpriv1 private key. The TIE may use the I / O port control device 190 (e.g., I2C port, UART port) to insert the UPDATE_OTAK_KEY command into the command memory 171 (e.g., Figure 7 ).

[0200] 7-TIE can send machine A to NO.

[0201] 8-NO You can run UPDATE_CONTAINER_ with the "transfer ownership" subcommand

[0202] Because UPDATE_CONTAINER_REQUEST is a signed command, NO may sign the command with NO's OTAKpriv2 private key.

[0203] NO may use the I / O port control device 190 (eg, I2C port, UART port) to insert the UPDATE_CONTAINER_REQUEST command into the command memory 171 (eg, Figure 7 ).

[0204] although Fig.11 A specific number of events related to unrestricted ownership transfers are disclosed, but this type of transfer can be Fig.11 More or fewer of the events depicted may be performed. For example, the CO may not send a sequence number to either or both of the TIE and NO. In addition, although Fig.11 A specific order of events is disclosed, but events can be completed in any suitable order.

[0205] like Fig.12As shown, the current owner (CO) may want to transfer ownership of machine B to a new owner (NO). In the example, the transfer may use an untrusted intermediate entity (UIE) to facilitate the transfer of ownership to the new owner. In the example, the following events (1 to 6) may occur during the transfer.

[0206] 1-CO may send the Machine B serial number to NO. NO may use the serial number to confirm that it received the correct device (eg, Machine B).

[0207] 2- NO may send the OTAKpub3 key to the CO. The OTAKpub3 key may be the public key of a public key / private key pair owned by the NO.

[0208] 3-CO can run the ENABLE_UNRESTRICTED_TRANSFERS command, passing the OTAKpub3 key as the new OTAK public key for Machine B.

[0209] 4-CO can send machine B to UIE. Note that because UIE does not have access to OTAKpriv3, UIE may not assume ownership or run commands on machine B.

[0210] 5-UIE can forward machine B to NO (as is).

[0211] 6-NO may run the UPDATE_CONTAINER_REQUEST using the "Transfer Ownership" subcommand. Because the UPDATE_CONTAINER_REQUEST is a signed command, NO may sign the command using NO's OTAKpriv3 private key. NO may use the I / O port control device 190 (e.g., I2C crisis port, UART crisis port) to insert the UPDATE_CONTAINER_REQUEST command into the command memory 171 (e.g., Figure 7 ).

[0212] although Fig.12 A specific number of events related to unrestricted ownership transfers are disclosed, but this type of transfer can be Fig.12 More or fewer of the events depicted may be performed. For example, CO may not send the serial number to NO. In another example, CO may send machine B directly to NO without the need for an intermediary entity. In addition, although Fig.12 A specific order of events is disclosed, but events can be completed in any suitable order.

[0213] like Fig.11 and Fig.12As shown, if an intermediary entity is required and the terminal owner is unknown, each temporary owner can have their own OTAK key. If an intermediary entity is required and the terminal owner is known, the terminal owner can provide their OTAK public key to prevent the intermediary entity from taking ownership of the OTAK key or changing the OTAK key. The current owner can retain ownership until the owner transfer is complete. This allows the current owner to handle any problems that arise during the ownership transfer.

[0214] In the example, there may be six scenarios for transferring ownership of the electronic device 101:

[0215] Direct ownership transfer of OTP using current owner’s CCK key and FMB configuration Fig.13 ).

[0216] • Direct ownership transfer simulation using the current owner's CCK key and FMB configuration = OTP.

[0217] • Direct ownership transfer using new owner's OTAK key and FMB configuration = OTP.

[0218] • Direct ownership transfer using new owner's OTAK key and FMB configuration = OTP emulation.

[0219] • Indirect ownership transfer using an intermediate entity, OTAK key and FMB configuration = OTP.

[0220] Indirect ownership transfer using an intermediate entity, OTAK key and FMB configuration = OTP emulation.

[0221] In the example where the ownership transfer command is successful, the new owner can load and execute code via the I / O port controller 190 (eg, crisis port). The loaded code can be used to update the SPI flash image.

[0222] Transfer process using CCK key

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

[0224] Fig.13 The example uses the current owner's CCK key and FMB configuration = OTP to transfer ownership. When FMB configuration = OTP emulation, the process can be similar. For OTP emulation, after issuing an UPDATE_CONTAINER_REQUEST, the owner can use the crisis port to load the new owner's loader code image and KHB into volatile memory 172 (e.g., SRAM ( Figure 1 )). Upon successful loading (t3), the boot code 140 may write the owner B container 0 / 1 (primary and fallback containers) to the non-volatile memory 1373 and jump to the loader code of the new owner. Subsequently, the loader code of the new owner may write the signed image and KHB (primary and fallback) to the non-volatile memory 1373 (e.g., SPI flash).

[0225] Therefore, the general process of ownership transfer using CCK keys can include:

[0226] The new owner can provide its owner configuration parameters to the current owner.

[0227] The current owner can sign the transfer ownership command parameters for the new owner.

[0228] (Optional) The current owner can enable crisis mode for restricted signing.

[0229] (Optional) The current owner can wipe their image and KHB (if applicable).

[0230] • Electronic devices can be powered off and physically transferred to a new owner or trusted intermediary entity.

[0231] The new owner can use the crisis port to issue a transfer of ownership order.

[0232] (For OTP emulation) The new owner can use the crisis port to load the new owner's loader code image and KHB, which will convert the signed images and KHB (main and fallback)

[0233] Write to non-volatile memory.

[0234] Transfer process using OTAK key

[0235] The above targets Fig.11 and Fig.12 An example of transferring ownership using an OTAK key is discussed. The general process of transferring ownership using an OTAK key may include:

[0236] The new owner or a trusted intermediate entity can generate a public / private ECDSA-384 key pair.

[0237] The public ECDSA key can be transferred to the current owner offline via a trusted channel.

[0238] The current owner can store this public key value to the OTAK key in the owner container and use the ENABLE_UNRESTRICTED_TRANSFERS command to enable unrestricted ownership transfers.

[0239] (Optional) The current owner can write the new owner image and KHB for flashing.

[0240] (Optional) The current owner can wipe their image and KHB.

[0241] • The machine can be powered off and physically transferred to a new owner or trusted entity.

[0242] (Optional) If a trusted intermediary entity is used, execute (via the crisis port) an UPDATE_OTAK_KEY command or an UPDATE_CONTAINER_REQUEST command (using the "Transfer Ownership" subcommand) using the intermediary entity's OTAK key.

[0243] New owner can execute (via crisis port)

[0244] UPDATE_CONTAINER_REQUEST command (with "transfer ownership" subcommand).

[0245] (For OTP emulation) The new owner can use the crisis port to load the new owner's loader code image and KHB, which will convert the signed images and KHB (main and fallback)

[0246] Write to non-volatile memory.

[0247] In an example, if the transfer ownership command is successfully executed, the new owner may load and execute code via the same crisis port.

[0248] Locating the owner container

[0249] In an example, the boot code 140 may be assigned by default to the first 16 bytes in the SPI flash memory of component 0 (e.g., the first flash memory component accessed during the boot sequence) for the boot ROM address pointer table. The 16-byte address pointer table may be relocatable. The table may be used to locate the owner image and may be remapped in the OTP memory. The location of the primary RPMC owner container base address and the fallback RPMC owner container base address may be stored in the last 8 bytes of the address pointer table.

[0250] RPMC value in OTP storage and owner container

[0251] In an 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 an update (e.g., an 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.

[0252] Ownership transfer method

[0253] Fig.14Flowchart illustrating an example method 1400 for managing ownership of an electronic device, including secure transfer of ownership of an electronic device over time. According to one example, the method 1400 may begin at block 1410. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 1400 and the order of 1410 to 1430 constituting the method 1400 may depend on the specific implementation selected.

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

[0255] although Fig.14 A specific number of operations associated with method 1400 are disclosed, but method 1400 may utilize more Fig.14 The operations depicted may be performed with more or fewer operations. For example, method 1400 may additionally use a public key to authenticate the first create owner container request. In another example, after block 1430, method 1400 may continue Fig.15 In addition, although Fig.14 A certain order of operations to be taken with respect to method 1400 is disclosed, but the operations making up method 1400 may be performed in any suitable order.

[0256] Fig.15 Flowchart illustrating an example method 1500 for managing ownership of an electronic device, including secure transfer of ownership of an electronic device over time. According to one example, the method 1500 may begin at block 1510. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 1500 and the order of 1510 to 1555 constituting the method 1500 may depend on the specific implementation selected.

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

[0258] although Fig.15 A specific number of operations are disclosed in connection with method 1500, but method 1500 may utilize more Fig.15 More or fewer operations may be performed than those depicted. In addition, although Fig.15 A certain order for operations to be taken with respect to method 1500 is disclosed, but the operations making up method 1500 may be performed in any suitable order.

[0259] Methods 1000, 1400, and 1500 may be implemented using system 100 or any other system operable to implement methods 1000, 1400, and 1500. Although examples have been described above, other variations and examples may be made in accordance with the present disclosure without departing from the spirit and scope of these disclosed examples.

[0260] Physically Unclonable Function (PUF) SRAM

[0261] Some examples of the present disclosure may use an SRAM Physical Unclonable Function (PUF) to generate a device attestation key (DevAK) and pass it from the boot code 130 to the first variable code (FMC) without exposing the private key or the SRAM PUF key material. Unlike devices that use OTP memory for DevAK keys, SRAM PUF may allow unique device keys to be generated for specific applications without exposing the private key. In an example, the key derived from the SRAM PUF may not be stored in a non-volatile memory on the chip (e.g., OTP memory 110, non-volatile memory 173, or other non-volatile memory) so that the key does not exist on the chip when the SRAM is not powered. For example, the SRAM PUF can be used to generate a device identity key (DevIK) so that there is no need to store the DevIK key in the OTP memory 110 (e.g., the DevIK may not be stored in the secret device unique information 207 ( Figure 2 In the same or different example, the SRAM memory can be "secret" when the SRAM is powered, such that it is not directly accessible by the FMC (e.g., as a result of read-write locking, as described in the next paragraph below).

[0262] Fig.16An example volatile memory 172 is shown, such as an SRAM that may include (a) a general SRAM region 1602, (b) a ROM_PUF region 1604, and (c) a shared PUF region 1606 / 1608 (SHD_PUF). The SHD_PUF region 1606 / 1608 may be shared by both the boot code 130 and the application code, for example, for cryptographic key management. The SHD_PUF region 1606 may be used as a PUF silicon fingerprint, and the SHD_PUF region 1608 may be PUF state information. In an example, the SRAM 172 may be read-write locked, such that when locked, a region of the SRAM 172 may be accessible to the boot code 140 and at the same time may not be accessible to the application code (e.g., controller firmware or FMC). In an example, the boot code 140 may fully access the ROM_PUF region 1604, while the application code (e.g., controller firmware) may not access the ROM_PUF region 1604 because the region is read-write locked. In the same or different examples, boot code 140 may fully access SHD_PUF area 1606 / 1608. Application code (e.g., controller firmware) may have limited access to SHD_PUF area 1606 / 1608. For example, application code (e.g., FMC) may access portion 1608 of SHD_PUF area 1606 / 1608, but may not access portion 1606 of SHD_PUF area 1606 / 1608 because the portion is read-write locked. In an example, portion 1608 of SHD_PUF area 1606 / 1608 is accessible by application code (FMC) and may include some SRAM PUF state data (e.g., which may be used by a PUF application programming interface (API)), but does not include information from which device secrets may be derived. Conversely, portion 1606 of SHD_PUF area 1606 / 1608 (not accessible by application code) may include SRAM PUF key material (e.g., a silicon fingerprint of an electronic device).

[0263] In some examples, the boot code 140 (e.g., immutable boot code or authenticated mutable boot code) may include SRAM PUF functionality to support, for example, anti-aging, error correction, randomness extraction, privacy amplification, and security countermeasure techniques. The SRAM PUF functionality may be built into the SRAM PUF API. In some examples, one or more of the SRAM PUF functionality (e.g., error correction and privacy amplification) may be used to generate a uniform random key based on a silicon fingerprint of the SRAM PUF. In an example, this process of using the SRAM PUF functionality to generate a uniform random key may be referred to as "enrolling" the SRAM PUF. In some examples, the SRAM PUF may be enrolled at the first power cycle. This may result in the generation of a uniform random key that may be stored in the owner container 302 ( Figure 3) in the container content 311b ( Figure 6 ). In an example, the SRAM PUF registration may be based on the current silicon owner (e.g., based on the owner ID 502, the owner RPMC 503, or other value unique to the current owner) such that the uniform random key is unique to the current silicon owner. The SRAM PUF function may then use the PUF activation code 621 to regenerate the same random key generated during registration (e.g., after a second power cycle). While the PUF activation code 621 may not be secret, its integrity may be maintained (e.g., as a parameter emulated by the OTP, such as for Figure 6 described).

[0264] Fig.17 Flowchart illustrating an example method 1700 for SRAM PUF enrollment and subsequent key reconstruction. According to one example, the method 1700 may start at block 1705. In an example, the method 1700 may be executed by the boot code 140. For simplicity, we may use the term boot code 140 as an execution function, which means that the boot code 140 is understood to be read by the processor 160 and causes the processor 160 to perform the relevant function. In some examples, the start block 1705 may represent the time when the electronic device 101 is first powered on (i.e., power-on reset (POR)) or the time after a reset of the electronic device (e.g., device reset, reboot, or power cycle). Therefore, the method 1700 may be executed by the boot code 140 at a time when the volatile memory 172 (e.g., SRAM with ROM_PUF and SHD_PUF areas) is not accessible to the FMC (e.g., because the FMC has not yet been authenticated and loaded). The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of method 1700 and the order of steps 1705 to 1745 that constitute method 1700 may depend on the specific implementation chosen.

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

[0266] The boot code 140 may then proceed to block 1725 and may store the PUF activation code in the secure RPMC owner container 302 (eg, as PUF activation code 621) corresponding to the current owner of the electronic device 101. In an example, block 1725 may be considered part of a registration process.

[0267] In an example, the registration process may provide different owners of the electronic device 101 with corresponding unique PUF activation codes 621. For example, a DevAKpriv key may be generated based on the current owner of the electronic device 101. This in turn may provide different owners with unique (and random) cryptographic contexts (e.g., unique DevAK keys). In an example, the unique PUF activation code 621 may be generated based on the current owner via a boot code at the first power cycle after the ownership transfer of the electronic device 101. In subsequent power cycles, the stored PUF activation code 621 may be used by the SRAM PUF API function to regenerate / recreate the previous cryptographic context (e.g., regenerate the same DevAK key). Therefore, by providing different PUF activation codes for different owners of the electronic device 101, the registration process may provide each owner with a different cryptographic context. Therefore, subsequent owners may not figure out the cryptographic context of the previous owner or discover the secrets of the previous owner.

[0268] After boot code 140 stores the PUF activation code in the secure RPMC owner container in block 1725, boot code 140 may then proceed to block 1730 where it may store the key code generated in block 1720 in firmware mailbox 786 ( Figure 7 ). The boot code 140 may then proceed to block 1740 where it may set the firmware mailbox 786 state. In an example, this state may be information stored in the firmware mailbox 786, such as a register bit, and may indicate other information in the firmware mailbox 786 (e.g., Fig.19 1922) is valid. In the example after registration after POR, the boot code 140 may set a state indicating that the key code stored in block 1730 is valid. The boot code 140 may then proceed to block 1745 where it may authenticate the FMC (e.g., firmware) and load it into SRAM (e.g., where it may be executed by the processor 160). In the example, the FMC may thereafter execute in the cryptographic context established by the registration process and may access the key code stored in the firmware mailbox 786. Figure 18 to Figure 3 0 describes example uses of the key codes in detail.

[0269] If the boot code 140 determines at block 1715 that this is not the first power cycle after a POR, the boot code 140 may proceed to block 1740 where it may set the firmware mailbox 786 state to indicate a key code (e.g., Fig.19The DevAK key code 1922 in is not valid. The boot code 140 may then proceed to block 1745 where it may authenticate the FMC (eg, firmware) and load it into SRAM (eg, where it may be executed by the processor 160).

[0270] 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 initiate a known cryptographic context by using the PUF activation code 621 corresponding to the current owner of the electronic device 101 and the SRAM PUF unique silicon fingerprint to regenerate (1) a uniform random cryptographic key and (2) a key code corresponding to the key. The boot code 140 may then proceed to block 1730 where it may store the key code generated in block 1735 in the firmware mailbox 786 ( Figure 7 ). The boot code 140 may proceed to block 1740 where it may set the firmware mailbox 786 state to indicate a key code (e.g., Fig.19 The DevAK key code 1922 in the boot code 140 may proceed to block 1745, where it may authenticate the FMC (e.g., 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., corresponding 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. Figure 18 to Figure 3 0 describes example uses of the key codes in detail.

[0271] although Fig.17 A specific number of operations associated with method 1700 are disclosed, but method 1700 may utilize more Fig.17 For example, after block 1725, boot code 140 may sign the secure RPMC owner container, as described above in signing container 312 ( Figure 3 ). Signing the owner container at this time can ensure that the PUF activation code 621 can be changed only by the boot code 140 so that its integrity can be maintained. As another example, before block 1745, the boot code 140 can set a read-write lock on the SRAM 172 ( Fig.16), so that application code (e.g., FMC) can access portion 1608 of SHD_PUF area 1606 / 1608, but cannot access portion 1606 of SHD_PUF area 1606 / 1608. In some examples, boot code 140 can set a read-write lock on SHD_PUF area 1606 at all exit events so that no user code (e.g., FMC) can access the secret SRAM PUF key material. In addition, although Fig.17 A certain order for operations to be taken with respect to method 1700 is disclosed, but the operations making up method 1700 may be performed in any suitable order.

[0272] Fig.18 An example electronic device 1801 that can respond to the Security Protocol Data Model (SPDM) GET_ATTESTATION and GET_CERTIFICATE commands is shown. SPDM is published by the Distributed Management Task Force. Some examples can follow the SPDM specification, which states that "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 a certificate chain from the responder and send a unique challenge to the responder. The responder signs the challenge using a private key. The authentication initiator verifies the signature using the responder's public key and verifies any intermediate public keys within the certificate chain by using the root certificate as a trusted anchor.

[0273] The example electronic device 1801 may include boot code 1840 (eg, immutable boot code or authenticated mutable code) and SRAM 1872. The SRAM 1872 may include a firmware mailbox 1886 (which may be firmware mailbox 786 ( Figure 7 ) and FMC 1820 (which may act as an SPDM responder). SRAM 1872 may also include SHD_PUF area 1816 / 1818 and ROM_PUF area 1814, which may be SHD_PUF area 1606 / 1608 and ROM_PUF area 1604 ( Fig.16 ) (e.g., it may be read-write locked, and the FMC 1820 may access the SHD_PUF area 1818, but not the SHD_PUF area 1816 or the ROM_PUF area 1814). The initiator 1821 may be located outside the electronic device 1801 and may act as a SPDM requestor. In an example, the initiator 1821 may communicate with the electronic device 1801 via an I2C communication interface.

[0274] In an example, the boot code 1840 may register the SHD_PUF for use as key material for the DevAK key, and may register the ROM_PUF for use as key material for the DevIK key. In an example, the boot code may use the SRAM PUF API (e.g., SRAM PUF functions) to perform these tasks so that the private cryptographic keys (DevAKpriv and DevIKpriv) may not be extracted by other boot code or the FMC (e.g., the private keys may be known only to the SRAM PUF API). After registering the SHD_PUF and ROM_PUF, the boot code 1840, acting as the root of trust (RoT), may store the DevIKpub (public) key, the DevAK certificate containing the DevAKpub (public) key, and the DevAK key code in the firmware mailbox 1886. The boot code 1840 may obtain the DevAKpub and DevAK key code from the SHD_PUF (via an SRAM PUF API call) and obtain the DevIKpub from the ROM_PUF (via an SRAM PUF API call). (In Fig.19 Further details regarding the generation of the DevAK certificate are provided in the associated description below.) In an example, the FMC may access information stored in the firmware mailbox 1886, such as the DevAK key code.

[0275] In an example, the initiator 1821 may send a SPDM GET_ATTESTATION challenge to the FMC 1820 via the I2C interface. In response, the FMC 1820 may need to return a challenge signed with the DevAKpriv key. However, the DevAKpriv key may be kept as a secret in the SHD_PUF and may not be directly accessible by the FMC 1820. In the example shown, the FMC 1820 may provide the data to be signed and the DevAK key code to the SHD_PUF 1816 / 1818 (e.g., via an SRAM PUF API call), and in response, receive data signed with the DevAKpriv key. The SRAM PUF API may use the DevAK key code to derive the DevAKpriv key. Therefore, the FMC 1820 may use the DevAKpriv key derived by the SHD_PUF 1816 / 1818 and the DevAK key code to sign the GET_ATTESTATION challenge, even though the DevAKpriv key is not exposed to (or directly accessible to) the FMC 1820. The FMC 1820 may then send the signed challenge to the initiator 1821.

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

[0277] Fig.19 An example electronic device 1901 according to the present disclosure is shown. The electronic device 1901 may include a boot code 1904, a firmware mailbox 1986, a PUF engine 1955, a ROM_PUF 1985, a SHD_PUF 1999, and a FMC 1920. The boot code 1940 may be stored in the ROM 130 ( Figure 1 ) or, for example, stored in nonvolatile memory 173 ( Figure 1 ) in the authenticated variable code in ROM 130 ( ). PUF engine 1955 may include code that causes the processor to perform functions including, but not limited to, SRAM PUF API functions. In an example, the PUF engine 1955 code may be stored in ROM 130 ( Figure 1 ) in immutable code. The firmware mailbox 1986 may be the command memory 171 ( Figure 7 ) in the area, the command memory may be a volatile SRAM. ROM_PUF 1985 and SHD_PUF 1999 may be a read-write lock area ( Fig.16 ). FMC 1920 may be authenticated mutable code, such as firmware or application code that may act as an SPDM responder (e.g., similar to Fig.18 (FMC 1820 in ).

[0278] As depicted, the ROM_PUF 1985 and SHD_PUF 1999 regions are directly accessible by the PUF engine 1955 (SRAM PUF API), but not by the FMC 1920. For example, the FMC 1920 may not read or write to the key material portion of the SHD_PUF 1999 region because that portion may be read-write locked. However, the FMC 1920 may call the SRAM PUF API functions of the PUF engine 1955, and these functions may access the SHD_PUF secrets, for example, to sign data provided by the FMC 1920 with the DevAKpriv key. In an example, the PUF engine and SRAM PUF API may be designed not to expose the SHD_PUF (or ROM_PUF) secrets to the FMC 1920, or in some examples to the boot code 1940. For example, the SRAM PUF API function may not allow the FMC 1920 to read any secrets and may not return them to the FMC 1920.

[0279] The remote host 1933 may be located outside the electronic device 1901 and may act as a SPDM requester. In an example, the remote host 1901 may communicate with the electronic device 1901 via a communication interface (eg, I2C).

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

[0281] Action 1 may represent boot code 1940 requesting initialization of an SRAM PUF (e.g., ROM_PUF, SHD_PUF). In an example, the initialization request may be to register the SRAM PUF (e.g., ROM_PUF, SHD_PUF) after determining that the SRAM PUF is not registered after the ownership change. Fig.17 In another example, the initialization request may be to initiate a known password context ( Fig.17 1725 in block 1726). For example, the known cryptographic context may be based on the current owner's PUF activation code 621 (which may be passed to the PUF engine 1955 as part of the function call). In an example, the initialization request may be directed to ROM_PUF 1985. In other examples, the initialization request may be directed to SHD_PUF 1999.

[0282] Action 2 may represent that the boot code 1940 requests to generate (or regenerate) the DevAKpriv key based on the current cryptographic context. The request may cause the PUF engine 1955 to use the secret key information in the SHD_PUF 1999 to create the DevAKpriv key based on the current cryptographic context (e.g., the context initiated by the previous SRAM PUF initialization request). In an example, the PUF engine 1955 may return a DevAK key code corresponding to the DevAKpriv key. In another example, action 2 may represent that the boot code 1940 requests to generate (or regenerate) the DevIKpriv key based on the current cryptographic context. The request may cause the PUF engine 1955 to use the secret key information in the ROM_PUF 1985 to create the DevIKpriv key based on the current cryptographic context (e.g., the context initiated by the previous SRAM PUF initialization request). In an example, the PUF engine 1955 may return a DevIK key code corresponding to the DevIKpriv key.

[0283] Action 3 may represent the boot code 1940 requesting the DevAKpub key or the DevIKpub key. Since the public key of the key pair is not secret, the PUF engine 1955 may expose the public key to the boot code 1940 (e.g., return the public key to the boot code 1940 so that the boot code 1940 can use the key). In an example, the boot code 1940 provides the PUF engine 1955 with a key code corresponding to the public key that the boot code is requesting (e.g., a DevAK key code or a DevIK key code).

[0284] Action 4 may represent the boot code 1940 requesting the DevAKpriv key code or the DevIKpriv key code. This key code may be used for subsequent signature requests to the PUF engine 1955 (e.g., such as for Fig.18 As described, the FMC requests that the SPDM certification challenge be signed with DevAKpriv).

[0285] Action 5 may represent a request by the boot code 1940 to sign the data with the DevIKpriv key or the DevAKpriv key. In an example, the boot code may send the data to be signed and the corresponding key code to the PUF engine 1955. The PUF engine 1955 may return the data signed with the appropriate key.

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

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

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

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

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

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

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

[0293] Action 13 may represent the FMC 1920 requesting the DevAKpub key from the PUF engine 1955. In an example, the FMC 1920 may send the DevAK key code 1922 (eg, after obtaining the key code from the firmware mailbox 1986) to the PUF engine 1955. The PUF engine 1955 may return the DevAKpub key.

[0294] Action 14 may represent that the FMC 1920 requests that the data be signed with the DevAKpriv key. In an example, the FMC 1920 may send the data to be signed together with the DevAK key code 1922 (e.g., after obtaining the key code from the firmware mailbox 1986) to the PUF engine 1955. The PUF engine 1955 may return the data signed with the DevAKpriv key.

[0295] Action 15 may represent that the remote host 1933 issues a SPDM request (e.g., GET_ATTESTATION, GET_CERTIFICATE) to the FMC 1920 (e.g., Fig.18 shown / described).

[0296] Action 16 may represent the FMC 1920 returning a signed SPDM challenge (eg, Fig.18 shown / described).

[0297] Action 17 may represent the FMC 1920 returning a certificate to the remote host 1933, such as in response to a GET_CERTIFICATE request.

[0298] although Fig.19 A specific number of actions (1 to 17) are disclosed in relation to electronic device 1901, but electronic device 1901 may be capable of performing more than Fig.19 More or fewer actions than those depicted. For example, the boot code 1940 or FMC 1920 may request that the PUF engine 1955 stop the current cryptographic context (e.g., a stop() request), which may cause the SRAM PUF secret to be destroyed or erased and return the SRAM PUF to its uninitialized state. As another example, the boot code 1940 may request that a read-write lock on the SRAM PUF region be set so that no user code (e.g., FMC 1920) can access the secret SRAM PUF key material. As another example, the FMC 1920 may request that other keys (e.g., not DevAK or DevIK) be generated using SHD_PUF. In an example, the PUF engine 1955 may return a key code for the newly generated key, and the FMC 1920 may use the key code 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. Therefore, the private key may not be exposed to the FMC 1920, but it may still use the private key to sign data. Fig.19 Actions 1 to 17 are disclosed, but these actions may be completed in any suitable order.

[0299] Fig. 20An example boot code method 2000 for DevAK key and certificate generation is shown. According to one example, method 2000 may start at block 2002. In an example, method 2000 may be performed by boot code 140, 1840, or 1940. In some examples, starting block 2002 may represent the time when electronic device 101 is first powered on (POR) or after the electronic device is reset (e.g., device reset, reboot, or power cycle). Therefore, method 2000 may be performed by boot code 140 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. Therefore, the initialization point of method 2000 and the order of 2002 to 2032 that constitute method 2000 may depend on the specific implementation selected.

[0300] In an example, method 2000 may begin by generating a DevAK key. Starting at block 2002, boot code 140 may initialize SHD_PUF (e.g., Fig.16 1606 / 1608 in ). In an example, this may include boot code 140 registering the SHD_PUF for the first time after transferring ownership of the electronic device. In another example, this may include providing the PUF engine with the current owner's PUF activation code to reestablish a previous cryptographic context for the current owner. The method may then proceed to block 2004, where boot code 140 may request to generate a DevAKpriv key and obtain a DevAK key code (e.g., Fig.19 The method may then proceed to block 2006 where the boot code 140 may request the use of the DevAK key code to generate a DevAKpub key (e.g., Fig.19 The method may then proceed to block 2008 where the boot code 140 may store the DevAK key code in the firmware mailbox 1986 (e.g., Fig.19 8 in ). The method may then proceed to block 2010 where the boot code 140 may request to stop the current SHD_PUF cryptographic context (eg, a stop() request), which may cause the SHD_PUF secret to be destroyed or erased and return the SHD_PUF to its uninitialized state.

[0301] In an example, the method 2000 may proceed by generating a DevIK key. Starting at block 2012, the boot code 140 may initialize ROM_PUF (e.g., Fig.161604 in block 2012). In an example, this may include the boot code 140 registering the ROM_PUF for the first time, or in another example, reestablishing a previous cryptographic context. In an 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 (like the SHD_PUF cryptographic context) may be unique for each owner of the electronic device. Thus, initializing the ROM_PUF in block 2012 may or may not include providing the PUF engine with the current owner's PUF activation code to reestablish a previous cryptographic context for the current owner. The method may then proceed to block 2014, where the boot code 140 may request generation of a DevIKpriv key and obtain a DevIK key code (e.g., Fig.19 Action 2).

[0302] In an example, the method 2000 may be performed by generating a DevAK certificate. Starting at block 2016, the boot code 140 may obtain a DevAK certificate template, which may be stored in the OTP memory 110, the non-volatile memory 173, the boot ROM 130, or any other suitable location. (The boot code 140 may authenticate the DevAK certificate template before using it (not illustrated).) In an example, the DevAK certificate may be an X.509CA or END certificate in ANSI.1DER format. In other examples, the DevAK certificate may be generated in other certificate formats. The method may then proceed to block 2018, where the boot code 140 may generate a DevAK unsigned certificate, for example, by storing the DevAKpub key (e.g., generated in block 2006) as a certificate object. The method may then proceed to block 2020, where the boot code 140 may request that the DevAK certificate be signed with the DevIKpriv key. In an example, the boot code 140 sends a request to the PUF engine to sign the DevAK certificate with the DevIKpriv key (e.g., Fig.19 Action 5): Provide the PUF engine with DevAK unsigned certificate data and DevIK key code (e.g., generated in block 2014). The method may then proceed to block 2022, where the boot code 140 may store the DevAK certificate in the firmware mailbox 1986 (e.g., Fig.19 7 in ). The method may then proceed to block 2024 where the boot code 140 may request to stop the current ROM_PUF cryptographic context (eg, a stop() request), which may cause the ROM_PUF secret to be destroyed or erased and return the ROM_PUF to its uninitialized state.

[0303] In an example, the method 2000 may proceed by initializing the SHD_PUF for use by the FMC. Beginning at block 2026, the boot code 140 may initialize the SHD_PUF as described for block 2002. The method may then proceed to block 2028, where the boot code 140 may request the generation of a DevAKpriv key and obtain a DevAK key code (e.g., Fig.19 2 in action 2). The method may then proceed to box 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 box 2008). In an example, the verification at box 2030 may confirm that the FMC and the boot code 140 are using the same cryptographic context and therefore the same DevAK key pair. The method may then proceed to box 2032, where the boot code 140 may request that a read / write lock be set for the ROM_PUF and SHD_PUF. In an example, a read / write lock may be set on the ROM_PUF so that the FMC cannot access it. In the same or different examples, a read / write lock may be set on the SHD_PUF so that the FMC cannot access the SHD_PUF key material area (e.g., Fig.16 1606 in ), but the SHD_PUF status area can be accessed (e.g., Fig.16 1608 in ), which allows the FMC to use the DevAK key code and PUF API to sign the SPDM challenge and access other allowed PUF functions (e.g., use the DevAK key code to obtain the DevAKpub key, create and other cryptographic key pairs, etc.).

[0304] although Fig. 20 A specific number of operations associated with method 2000 are disclosed, but method 2000 may utilize more Fig. 20 The boot code may perform more or less operations than those depicted. For example, after block 2008, the boot code may not request to stop SHD_PUF. Similarly, after block 2022, the boot code may not request to stop ROM_PUF. In these examples, stopping SRAM PUF upon a boot code exit event may be good practice to avoid the FMC from accessing device secrets. However, if, for example, the boot code executes blocks 2002 to 2032 of method 2000 without exiting or before loading the FMC, stopping SRAM PUF may be avoided. In the example, if block 2010 is omitted, block 2026 (initializing SHD_PUF) may also be omitted because SHD_PUF is not stopped. In addition, although Fig. 20A certain order of operations to be taken with respect to method 2000 is disclosed, but the operations making up method 2000 may be completed in any suitable order. For example, the boot code may generate a DevIK key (blocks 2012 to 2014) before generating a DevAK key (blocks 2002 to 2010).

[0305] Fig.21 Flowchart illustrating an example method 2100 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2100 may begin at block 2110. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2100 and the order of 2110 to 2135 constituting the method 2100 may depend on the specific implementation selected.

[0306] At block 2110, for an electronic device having a processor, a nonvolatile memory, and an SRAM including a SRAM physically unclonable function (SRAM PUF) region, the processor may store first owner information and a first owner variable code in the nonvolatile memory. In an example, the SRAM PUF region may include a secret unclonable silicon fingerprint unique to the electronic device. In the same or different examples, the first owner information may be stored in the nonvolatile memory so that it may be emulated to a one-time programmable memory (e.g., as a parameter emulated by an OTP, such as for a Figure 6The processor may generate a first unique private key based on the first owner information and at least a portion of the SRAM PUF area, wherein the first unique private key is not directly accessible by the first owner variable code (e.g., the PUF engine 1955 may not expose the first unique private key to the first owner variable code while still allowing the first owner variable code to sign data with the first unique private key). At box 2120, the processor may generate a first unique private key code corresponding to the first unique private key. At box 2125, the processor may provide the first unique private key code to the first owner variable code. (The key code may serve as a reference or handle to the corresponding key, so that when the key code is passed to the PUF engine 1955, the PUF engine 1955 may use the key code to determine the corresponding key. In this way, the key may not be exposed to the outside of the PUF engine 1955 and its confidentiality may be maintained. At box 2130, the processor may receive a signature request from the first owner variable code, the signature request including the first unique private key code and the first data. In an example, the first data may include a device certification challenge. At box 2130, in response to the signature request from the first owner variable code, the processor may sign the first data with the first unique private key and provide the first owner variable code with the first data signed with the first unique private key.

[0307] although Fig.21 A specific number of operations associated with method 2100 are disclosed, but method 2100 may utilize more Fig.21 The operations depicted may be performed with more or fewer operations. For example, after block 2135, method 2100 may continue Figure 22 to Figure 29 In addition, although Fig.21 A certain order of operations to be taken with respect to method 2100 is disclosed, but the operations constituting method 2100 may be performed in any suitable order.

[0308] Fig. 22 Flowchart illustrating an example method 2200 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2200 may begin at block 2210. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2200 and the order of 2210 to 2220 constituting the method 2200 may depend on the specific implementation selected.

[0309] According to an example, block 2210 may be associated with Fig.21At block 2215, the processor may receive a key generation request from the first owner variable code. At block 2220, in response to the key generation request from the first owner variable code, the processor may generate a first owner unique variable code key based on at least a portion of the SRAM PUF area. In an example, the generated first owner unique variable code key may be based on the SHD_PUF area 1606 ( Fig.16 ) and may be different from the DevAK key (e.g., suitable for purposes other than responding to device attestation challenges).

[0310] although Fig. 22 A specific number of operations associated with method 2200 are disclosed, but method 2200 may utilize more Fig. 22 More or fewer operations may be performed than those depicted. In addition, although Fig. 22 A certain order of operations to be taken with respect to method 2200 is disclosed, but the operations constituting method 2200 may be performed in any suitable order.

[0311] Fig.23 Flowchart illustrating an example method 2300 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2300 may begin at block 2310. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2300 and the order of 2310 to 2335 constituting the method 2300 may depend on the specific implementation selected.

[0312] According to an example, block 2310 may be associated with 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 owner variable code in a non-volatile memory, wherein the second owner information may be unique to the second owner of the electronic device. In an example, the ownership transfer may be as follows: Figures 8 to 15At box 2320, the processor may generate a second unique private key based on the second owner information and at least a portion of the SRAM PUF area, wherein the second unique private key is not directly accessible by the second owner variable code (e.g., the PUF engine 1955 may not expose the key to the second owner variable code while still allowing the second owner variable code to sign data with the key). At box 2325, the processor may generate a second unique private key code corresponding to the second unique private key. At box 2330, the processor may provide the second unique private key code to the second owner variable code. At box 2335, the processor may prohibit access to the first unique private key or regeneration of the first unique private key while the second owner owns the electronic device. In an example, access may be prohibited due to (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, for example, limit the cryptographic context to the cryptographic context of the current user by using the PUF activation code of the current owner, which may be authenticated before use. Therefore, the system may not allow the use of the previous owner's PUF activation code, thereby prohibiting the first unique private key or the regeneration of the first unique private key.

[0313] although Fig.23 A specific number of operations associated with method 2300 are disclosed, but method 2300 may utilize more Fig.23 The operations depicted may be performed with more or fewer operations. For example, after block 2335, method 2300 may continue Figure 24 to Figure 25 In addition, although Fig.23 A certain order of operations to be taken with respect to method 2300 is disclosed, but the operations constituting method 2300 may be performed in any suitable order.

[0314] Fig.24 Flowchart illustrating an example method 2400 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2400 may begin at block 2410. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2400 and the order of 2410 to 2420 constituting the method 2400 may depend on the specific implementation selected.

[0315] According to an example, block 2410 may be associated with Fig.23The processor may receive a second owner signature request from the second owner variable code at block 2415, the second owner signature request including the second unique private key code and second data (e.g., a certification challenge). At block 2420, in response to the second owner signature request from the second owner variable code, the processor may sign the second data with the second unique private key and provide the second owner variable code with the second data signed with the second unique private key.

[0316] although Fig.24 A specific number of operations associated with method 2400 are disclosed, but method 2400 may utilize more Fig.24 The operations depicted may be performed with more or fewer operations. For example, after block 2420, method 2400 may continue Fig.25 In addition, although Fig.24 A certain order of operations to be taken with respect to method 2400 is disclosed, but the operations constituting method 2400 may be performed in any suitable order.

[0317] Fig.25 Flowchart illustrating an example method 2500 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2500 may begin at block 2510. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2500 and the order of 2510 to 2520 constituting the method 2500 may depend on the specific implementation selected.

[0318] According to an example, block 2510 may be associated with Fig.24 At block 2515, the processor may receive a key generation request from the second owner variable code. At block 2520, in response to the key generation request from the second owner variable code, the processor may generate a second owner unique variable code key based on at least a portion of the SRAM PUF area. In an example, the generated second owner unique variable code key may be based on the SHD_PUF area 1606 ( Fig.16 ) and may be different from the DevAK key (e.g., suitable for purposes other than responding to device attestation challenges).

[0319] although Fig.25 A specific number of operations associated with method 2500 are disclosed, but method 2500 may utilize more Fig.25 More or fewer operations may be performed than those depicted. In addition, although Fig.25A certain order of operations to be taken with respect to method 2500 is disclosed, but the operations constituting method 2500 may be performed in any suitable order.

[0320] Fig.26 Flowchart illustrating an example method 2600 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2600 may begin at block 2610. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2600 and the order of 2610 to 2625 constituting the method 2600 may depend on the specific implementation selected.

[0321] According to an example, block 2610 may be associated with Fig.21 . At box 2615, the method may include destroying the first unique private key during a reset of the electronic device. In an example, the first unique private key may be destroyed or erased during a reset because the first unique private key is stored in a volatile memory whose contents may not be maintained during a reset event. In an alternative example, in response to an instruction in the boot code, the processor may destroy or erase the first unique private key by making a stop() request to the PUF engine 1955. In response to this request, the PUF engine 1955 may destroy or erase the first unique private key, which may be a variable code stored in a ROM (e.g., ROM 130). At box 2620, after a reset of the electronic device, the processor may generate a regenerated first unique private key that is equivalent to the first unique private key and cannot be directly accessed by the first owner variable code (e.g., the PUF engine 1955 may not expose the regenerated key to the first owner variable code, while still allowing the first owner variable code to sign data using the regenerated key). At block 2625, in response to the signature request from the first owner variable code, the processor may use the first unique private key code to sign the first data with the regenerated first unique private key. In an example, the PUF engine 1955 may use the first unique private key code as a reference or handle to determine the corresponding key that is ultimately used to sign the data.

[0322] although Fig.26 A specific number of operations associated with method 2600 are disclosed, but method 2600 may utilize more Fig.26 More or fewer operations may be performed than those depicted. In addition, although Fig.26 A certain order of operations to be taken with respect to method 2600 is disclosed, but the operations constituting method 2600 may be performed in any suitable order.

[0323] Fig. 27Flowchart illustrating an example method 2700 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2700 may begin at block 2710. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2700 and the order of 2710 to 2720 constituting the method 2700 may depend on the specific implementation selected.

[0324] According to an example, block 2710 may be associated with Fig.21 The processor may receive a public key request from the first owner variable code at block 2715, which may include the first unique private key code. At block 2720, in response to the public key request, the processor may generate a first unique public key corresponding to the first unique private key and provide the first unique public key to the first owner variable code.

[0325] although Fig. 27 A specific number of operations associated with method 2700 are disclosed, but method 2700 may utilize Fig. 27 More or fewer operations may be performed than those depicted. In addition, although Fig. 27 A certain order of operations to be taken with respect to method 2700 is disclosed, but the operations constituting method 2700 may be performed in any suitable order.

[0326] Fig.28 Flowchart illustrating an example method 2800 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2800 may begin at block 2810. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2800 and the order of 2810 to 2825 constituting the method 2800 may depend on the specific implementation selected.

[0327] According to an example, block 2810 may be associated with Fig.21 The processor may generate a first unique public key corresponding to the first unique private key. At block 2815, the processor may generate a certificate having the first unique public key as a certificate object. At block 2825, the processor may generate a signature for the certificate using the device identity private key.

[0328] although Fig.28 A specific number of operations associated with method 2800 are disclosed, but method 2800 may utilize more Fig.28 The operations depicted may be performed with more or fewer operations. For example, after block 2825, method 2800 may continue Fig.29In addition, although Fig.28 A certain order of operations to be taken with respect to method 2800 is disclosed, but the operations constituting method 2800 may be performed in any suitable order.

[0329] Fig.29 Flowchart illustrating an example method 2900 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 2900 may begin at block 2910. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 2900 and the order of 2910 to 2915 constituting the method 2900 may depend on the specific implementation selected.

[0330] According to an example, block 2910 may be associated with Fig.28 At block 2915, the processor may provide a certificate for the first owner variable code that may have the first unique public key as a certificate object.

[0331] although Fig.29 A specific number of operations associated with method 2900 are disclosed, but method 2900 may utilize Fig.29 More or fewer operations may be performed than those depicted. In addition, although Fig.29 A certain order of operations to be taken with respect to method 2900 is disclosed, but the operations constituting method 2900 may be performed in any suitable order.

[0332] Figure 30a to Figure 30b Flowchart illustrating an example method 3000 for managing device keys using an SRAM PUF shared by multiple entities. According to one example, the method 3000 may begin at block 3010. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 3000 and the order of 3010 to 3070 constituting the method 3000 may depend on the specific implementation selected.

[0333] At block 3010, for an electronic device having a processor, a nonvolatile memory, and an SRAM including a SRAM physically unclonable function (SRAM PUF) region, the processor may store first owner information and a first owner variable code in the nonvolatile memory. In an example, the SRAM PUF region may include a secret unclonable silicon fingerprint unique to the electronic device. In the same or different examples, the first owner information may be stored in the nonvolatile memory so that it may be emulated to a one-time programmable memory (e.g., as a parameter emulated by an OTP, such as for a Figure 6) and may be unique to a first owner of the electronic device. At box 3015, the processor may generate a device identity private key based on at least a portion of the SRAM PUF area. At box 3020, the processor may generate a first unique private key, which may be based on both the first owner information and at least a portion of the SRAM PUF area, wherein the first unique private key is not directly accessible by the first owner variable code (e.g., the PUF engine 1955 may not expose the first unique private key to the first owner variable code while still allowing the first owner variable code to sign data with the key). At box 3025, the processor may generate a first unique public key corresponding to the first unique private key. At box 3030, the processor may generate a first unique private key code corresponding to the first unique private key. At box 3035, the processor may generate a certificate that may have the first unique public key as a certificate object. At box 3040, the processor may sign the certificate using the device identity private key. At box 3045, the processor may provide the first unique private key code to the first owner variable code (e.g., by storing it in a firmware mailbox). At box 3050, the processor may provide the certificate to the first owner variable code (e.g., by storing it in a firmware mailbox). At box 3055, the method may include erasing the first unique private key during a reset of the electronic device. In an example, the first unique private key may be destroyed or erased during a reset because the first unique private key is stored in a volatile memory whose contents may not be retained during a reset event. 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 box 3060, after a reset of the electronic device, the processor may generate a regenerated first unique private key that is equivalent to the first unique private key and cannot be directly accessed by the first owner variable code (e.g., the PUF engine 1955 may not expose the regenerated key to the first owner variable code while still allowing the first owner variable code to sign data with the regenerated key). At block 3065, the processor may receive a signature request from the first owner variable code, the signature request including the first unique private key code and the first data. In an example, the first data may include a device certification challenge. At block 3070, in response to receiving the signature request from the first owner variable code, the processor may sign the first data with the regenerated first unique private key and provide the first owner variable code with the first data signed with the regenerated first unique private key.

[0334] although Figure 30a to Figure 30bA specific number of operations are disclosed in connection with method 3000, but method 3000 may be performed using more or fewer operations than those depicted in Figure 30. Furthermore, although Figure 30 discloses a certain order of operations to be taken with respect to method 3000, the operations making up method 3000 may be performed in any suitable order.

[0335] Security Owner Revocation Emulation Container (REC)

[0336] As in the various examples above (e.g., Figure 5 ), the concepts of image key revocation and image rollback protection may be applied to the first mutable code (FMC) that may be loaded and authenticated by the boot code 140. The same concepts may also be applied to images authenticated by the FMC to extend the chain of trust (e.g., application firmware). In the case of introducing device ownership, each owner may configure the electronic device 101 to use a unique set of keys and image revisions for authenticating the FMC during the authentication sequence of the boot code. These keys and images may be authenticated using the TAGx image key revocation 508 and TAGx image rollback protection 509 information stored in the secure RPMC owner container 302. A secure owner revocation emulation container (REC) may extend these concepts.

[0337] In the example, the new REC (e.g. Fig.33 ) may be generated and stored in non-volatile memory 173 after the transfer of ownership. A new REC may contain revocation or rollback protection information associated with an asset of the current owner of the electronic device 101. In an example, the revocation and rollback protection information may correspond to an asset, such as a key (a separate key or a key hash binary large object), a hash table, or a mirror. In the same or different examples, the revocation and rollback protection information may correspond to an asset such as static configuration data or accumulated data (revocation information, logs, states, etc.). In an example, the revocation and rollback protection information may only be programmed, thereby emulating the OTP function, and is not deprogrammed until the transfer of ownership occurs. In this way, each owner of the electronic device 101 can utilize the same number of assets as other owners (e.g., corresponding to the number of revocation and / or rollback protection bits provided in the REC). In the absence of a REC, all owners can share the asset revocation and rollback protection information stored in the OTP memory 110, and thus the number of assets that the current owner can revoke can be reduced by the number of assets revoked by the previous owner.

[0338] Fig.31 A block diagram illustrating an example OTP memory for managing keys, images, and other assets associated with an owner of an electronic device, including through the use of a secure owner REC. In the example, Fig.31The information shown in the OTP memory 110 may be Figure 2 The information shown is supplemental. Revoke Emulation Feature Enable 3102 may indicate whether the electronic device 101 supports a secure revocation emulation feature. In an example, if the value of Revoke Emulation Feature Enable 3102 indicates that the feature is enabled, each owner of the electronic device 101 may be provided with their own set of emulation OTP (EOTP) asset revocation bits, which may be stored in the non-volatile memory 173 (e.g., in the secure REC ( Figure 33 to Figure 35 )). In the example where the asset revocation bit is used for key and image assets, the feature can allow each owner of the electronic device 101 to start at image revision 0 and key 0. In an alternative example where the value of the revocation emulation feature enable 3102 indicates that the feature is not enabled, the asset revocation bit can be stored in the OTP memory 110. In this alternative example, the asset revocation bit can be shared among all owners of the electronic device 101, and the new owner may not use an asset (e.g., a key or image revision) revoked by the previous owner.

[0339] The revocation emulation container (REC) current RPMC value 3104 may be provided by a replay protection monotonic counter that increments over time. In an example, the REC current RPMC value 3104 may be incremented when the ownership of the electronic device 101 changes. Fig.31 In the example shown, REC current RPMC value 3104 may be a value stored in OTP memory 110. In this example, the bits in OTP memory 110 for REC current RPMC value 3104 may be sequentially set from the lowest bit to the highest bit, and the next REC current RPMC value may be the next integer value after REC current RPMC value 3104. In the same or different examples, values ​​less than REC current RPMC value 3104 may be considered to be revoked, and values ​​greater than REC current RPMC value 3104 may be considered to be unused (e.g., much like Figure 2 202 in the REC current RPMC value 3104). A value less than the REC current RPMC value 3104 may be considered to be revoked because the OTP memory 110 may not be programmed to a smaller value because the OTP memory may be programmed only once by definition. For example, when the REC current RPMC value 3104 has a value of one (1), the least significant bit is programmed and cannot be deprogrammed to reset the REC current RPMC value 3104 back to a value of zero (0).

[0340] Regions 3108 to 3112 may serve as revocation emulation data for various assets associated with the current owner of the electronic device 101. In the example shown, the assets may include hash tables, keys, and images corresponding to regions 3108 to 3112, respectively. In the example, the owner may provide eight (8) public keys that may be used to authenticate other data. Application public key revocation 3110 may include a bit corresponding to each public key. In this example, when the bit in application public key revocation 3110 is programmed to a value of one (1), the corresponding key may be revoked. In the example, the boot code 140 may not use the revoked key (e.g., before using the key, the boot code 140 may check to ensure that the corresponding bit in application public key revocation 3110 is not programmed to a value of one (1)). Similarly, hash table rollback protection 3108 and image rollback protection 3112 may indicate whether the current hash table or image revision (e.g., FMB) is available for use or has been revoked (not available for use). In an example, the electronic device 101 may allow up to 128 hash table revisions and 128 image revisions, and the hash table rollback protection 3108 and the image rollback protection 3112 may each include a bit corresponding to each revision. In this example, when a bit in the hash table rollback protection 3108 is programmed to a value of one (1), the corresponding hash table revision may be revoked. In an example, the boot code 140 may not use the revoked hash table (e.g., before using the hash table, the boot code 140 may check to ensure that the corresponding bit in the hash table rollback protection 3108 is not programmed to a value of one (1)). In the same or different examples, when a bit in the image rollback protection 3112 is programmed to a value of one (1), the corresponding image revision may be revoked. In an example, the boot code 140 may not authenticate the revoked image (e.g., before loading the image, the boot code 140 may check to ensure that the corresponding bit in the image rollback protection 3112 is not programmed to a value of one (1)).

[0341] Regions 3114-3115 may serve as revocation mask data for various assets associated with the current owner of electronic device 101. Hashtable authentication key mask 3114 may serve as a permission mask for hashtable revocation. Mirror authentication key mask 3115 may serve as a permission mask for mirror revocation.

[0342] although Fig.31 Various regions of the OTP memory 310 are illustrated, but other example systems may include electronic devices having more or fewer regions.

[0343] Revocation emulation container (REC) base address 3106 may be a base address where a default revocation emulation container is stored in non-volatile memory 173. In an example where revocation emulation feature enable 3102 indicates that electronic device 101 supports a secure revocation emulation feature, boot code may access the default revocation emulation container in non-volatile memory 173 using REC base address 3106.

[0344] Fig.32 A block diagram illustrating example container contents of an owner container for managing keys, images, and other assets associated with an owner of an electronic device, including through the use of a secure owner REC. Fig.32 As shown, container content 311b may be programmed into non-volatile memory 173 and may include regions 501 to 515 (with respect to Figure 5 described) and 621 (about Figure 6 3201)). The container content 311b may also include areas 3214 to 3216 corresponding to secure RECs. The owner REC RPMC 3214 may be equal to the offset (e.g., index) of the most significant bit (MSB) programmed in the REC current RPMC value 3104. In an example, the boot code 140 may determine whether the REC is valid by comparing the owner REC RPMC 3214 with the REC current RPMC value 3104 (stored in the OTP memory 110). The hash table authentication key mask 3215 may include information for generating hash table permission bits. The mirror authentication key mask 3216 may include information for generating mirror table permission bits.

[0345] although Fig.32 Various regions of container content 311b are illustrated, but other example systems may include electronic devices having more or fewer regions.

[0346] Fig.33 A block diagram illustrating an example secure revocation emulation container (REC) 3302 for managing ownership, keys, images, and other assets associated with an owner of an electronic device 101. In an example, the REC 3302 may be a signed data image stored in a non-volatile memory (e.g., OTP memory 110, non-volatile memory 173, etc.), which may contain configuration information and revocation information of the current silicon owner to enable the boot code 140 to revoke various assets (e.g., keys, hash tables, images, etc.). Fig.33As shown, the owner container 3302 may include three areas: a REC header 3310, REC content 3311, and a REC signature 3312. In an example, REC 3302 may be a unique signed information container that is modified by the code that created the container (e.g., boot code 140 or ROM extension (e.g., in an authenticated FMC)), stored in a non-volatile memory (e.g., non-volatile memory 173), and retrieved therefrom. According to examples in the present disclosure, REC 3302 may be signed and updated only by the code that created the container. Higher-level firmware (e.g., code other than the code that created the container) may require a command interface (e.g., command memory 171, Figure 7 ) to access or modify information in REC 3302. In an 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 ROM extension (e.g., certified FMC)) can access or modify information in REC 3302. In an example, the boot code that creates REC 3302 can create two redundant copies of REC 3302. One copy can be a primary REC and the other copy can be a fallback REC.

[0347] although Fig.33 Various regions of REC 3302 are illustrated, but other example systems may include electronic devices having more or fewer regions.

[0348] - REC Signature

[0349] REC signature 3312 may include a signature corresponding to REC 3302 and may be generated by boot code 140 or a ROM extension (e.g., an authenticated FMC). In an example, boot code 140 may use a physical unclonable function (PUF) to generate a non-deterministic ECDSA signature. For example, REC signature 3312 may be an ECDSA-384 signature with the following properties:

[0350] ●Algorithm: Elliptic Curve Digital Signature Algorithm (ECDSA)

[0351] Key size: 384 bits

[0352] ●Curve: NIST "secp384r1" curve

[0353] Hash algorithm: SHA384

[0354] ●Signed message (m) = {REC header 3310 | REC content 3311}

[0355] The boot code 140 may derive an ECDSA private signature key for signing the REC 3302. In an example, the boot code 140 may register / start the SRAM PUF (e.g., Fig.16 Once the ECDSA private signing key is exported, the boot code 140 can sign the REC3302.

[0356] - REC Header

[0357] Fig.34 A block diagram illustrating an example REC header 3310 for managing the revocation emulation container 3302 of ownership, keys, images, and other assets associated with the owner of the electronic device 101. In an example, the REC header 3310 may have a common format for RECs created for the electronic device 101. Fig.34 As shown, the REC header 3310 may include areas 3431 to 3436, including: REC RPMC value 3431, container type 3433, secure container content length 3434, device serial number 3435 and container command key hash binary large object 3436.

[0358] The REC RPMC value 3431 may be provided by a replay protection monotonic counter that may be checked against the REC current RPMC value 3104 in the OTP memory 110 to determine whether the REC container is valid or has been revoked. In one example, when the REC RPMC value 3431 of REC 3302 has a value of three (3), the boot code 140 may determine that REC 3302 is valid when the revocation emulation container (REC) current RPMC value 3104 also has a value of three (3). In the same or different examples, when the REC RPMC value 3431 of REC 3302 has a value of three (3), the boot code 140 may determine that REC 3302 is revoked when the revocation emulation container (REC) current RPMC value 3104 has a value greater than three (3). In some examples, the REC RPMC value 3431 may be used to check the primary REC container and the fallback REC container.

[0359] Container type 3433 may represent a type associated with REC 3302. In an example, container type 3433 may have a value indicating that the container is not initialized. In another example, container type 3433 may have a value indicating that REC 3302 is initialized and is a valid REC. Secure container content length 3434 may indicate the number of bytes in REC content 3311. Device serial number 3435 may correspond to the serial number of electronic device 101, for example, unique serial number 205 in OTP memory 110. Container command key hash blob 3436 may contain a hash of one or more container command keys (CCK) (e.g., SHA384 (Secure Hash Algorithm)), which may be a public key of a cryptographic key pair. In the example shown, container command key hash blob 3436 may include hashes of public keys CCK0 3437, CCK1 3438, CCK2 3439, and CCK33440. In an example, these key hashes may be used to verify commands associated with REC 3302. (Alternatively, container command key hash blob 3436 may contain the public key instead of a hash of the public key. In this example, more memory may be required.) In an example, CCK0-3 (3437 to 3440) may be revoked by setting the hash entry to zero (0). Although Fig.34 Various regions of the REC header 3310 are illustrated, but other example systems may include electronic devices having more or fewer regions.

[0360] - REC Content

[0361] Fig.35 A block diagram illustrating example REC content 3311 of REC 3302 for managing ownership, keys, images, and other assets associated with an owner of an electronic device 101. Fig.35 As shown, REC content 3311 may include areas 3501 to 3507, which include: 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 REC content version to support updates to the REC format. Owner ID 3502 may be a value provided by the owner when ownership is transferred, may be the same as the owner ID 501 value stored in the current owner's secure RPMC owner container, and may be used to verify that the REC belongs to the current owner.

[0362] Regions 3503 to 3505 may serve as revocation emulation data for various assets associated with the current owner of the electronic device 101. In the example shown, the assets may include hash tables, keys, and images corresponding to regions 3503 to 3505, respectively. In the example, the owner may provide eight (8) public keys that may be used to authenticate other data. Application public key revocation 3504 may include a bit corresponding to each public key. In this example, when the bit in application public key revocation 3504 is programmed to a value of one (1), the corresponding key may be revoked. In the example, the boot code 140 may not use the revoked key (e.g., before using the key, the boot code 140 may check to ensure that the corresponding bit in application public key revocation 3504 is not programmed to a value of one (1)). Similarly, hash table rollback protection 3503 and image rollback protection 3505 may indicate whether the current hash table or image revision (e.g., FMB) is available for use or has been revoked (not available for use). In an example, the electronic device 101 may allow up to 128 hash table revisions and 128 image revisions, and the hash table rollback protection 3503 and the image rollback protection 3505 may respectively include a bit corresponding to each revision. In this example, when the bit in the hash table rollback protection 3503 is programmed to a value of one (1), the corresponding hash table revision may be revoked. In an example, the boot code 140 may not use the revoked hash table (e.g., before using the hash table, the boot code 140 may check to ensure that the corresponding bit in the hash table rollback protection 3503 is not programmed to a value of one (1)). In the same or different examples, when the bit in the image rollback protection 3505 is programmed to a value of one (1), the corresponding image revision may be revoked. In an example, the boot code 140 may not authenticate the revoked image (e.g., before loading the image, the boot code 140 may check to ensure that the corresponding bit in the image rollback protection 3505 is not programmed to a value of one (1)).

[0363] The revocation emulation in the areas 3503 to 3505 may be emulated OTP (EOTP) information stored in the non-volatile memory 173. In an example, this feature may allow each owner of the electronic device 101 to start at hash table revision 0, image revision 0, and key 0 (e.g., when the REC 3302 is first created, each area 3503 to 3505 may be initialized to zero (0)). In an example, the areas 3503 to 3505 may be stored in the non-volatile memory 173 and may emulate data stored in the OTP memory 110 (OTP emulation) because the trusted boot code 140 (e.g., the immutable boot code or the authenticated ROM extension in the FMC) may only program these areas, and may not provide commands for the boot code 140 (or other code) to deprogram these areas. In the event that a malicious user may attempt to change the REC 3302 while the secure REC is stored in the non-volatile memory 173 (e.g., to change any EOTP area), the verification of the REC will fail. For example, verification uses REC signature 3312 which is also stored in non-volatile memory 173. Because REC signature 3312 is based on SRAM PUF (e.g., Fig.16 The SRAM_PUF area 1606 / 1608 in the non-volatile memory 173 is generated from a private key, and only the boot code 140 can directly access the SRAM_PUF, so a malicious user cannot spoof the REC signature 3312. Therefore, the revocation emulation data in areas 3503 to 3505 in the REC 3302 stored in the non-volatile memory 173 can be considered to be an emulated OTP memory.

[0364] Regions 3506-3507 may serve as revocation mask data for various assets associated with the current owner of the electronic device 101. Hashtable authentication key mask 3506 may serve as a permission mask for hashtable revocation. Mirror authentication key mask 3507 may serve as a permission mask for mirror revocation.

[0365] although Fig.35 Various regions of REC content 3311 are illustrated, but other example systems may include electronic devices with more or fewer regions.

[0366] - Undo Simulation Container Method

[0367] Fig.36A flowchart illustrating an example method for revoking emulation. According to one example, method 3600 may begin at box 3605. In the example, method 3600 may be executed by boot code 140. For simplicity, we may use the term boot code 140 as an execution function, which means that boot code 140 is understood to be read by processor 160 and causes processor 160 to perform related functions. In some examples, starting box 3605 may represent the time when electronic device 101 is first powered on (i.e., power-on reset (POR)) or the time after the electronic device is reset (e.g., device reset, reboot, or power cycle). In the same or different examples, starting box 3605 may represent a time after which boot code 140 has determined that: (1) the owner feature of electronic device 101 is enabled (e.g., based on an enable bit in OTP memory 110 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 state 208 stored in OTP memory 110 ( Figure 2 )). In these examples, method 1700 may be executed by boot code 140 at a time when volatile memory 172 (e.g., SRAM with ROM_PUF and SHD_PUF areas) is not accessible to the FMC (e.g., because the FMC has not yet been authenticated and loaded). The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Thus, the initialization point of method 3600 and the order of 3605 to 3650 that make up method 1700 may depend on the specific implementation selected.

[0368] After a POR or soft reset, the boot code 140 may proceed to block 3610 where it may determine whether the deactivate emulation feature is enabled. In an example, the boot code 140 may make this determination based on the value of deactivate emulation feature enable 3102 in the OTP memory 110 ( Fig.31 ). If the revocation emulation feature is not enabled, the boot code 140 may proceed to block 3613 where it may retrieve asset revocation information from the OTP memory 110. In an 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 may share the asset revocation and rollback protection information stored in the OTP memory 110, and thus the number of assets (e.g., keys, images) that the current owner may revoke may be reduced by the number of assets revoked by the previous owner.

[0369] If at block 3610, boot code 140 determines that the de-emulation feature is enabled, boot code 140 may proceed to block 3616 where the boot code may determine whether it can find a valid REC. In an example, a valid REC (e.g., REC 3302) is considered found when (1) REC signature 3312 is valid, (2) REC RPMC value 3431 is valid, and (3) other integrity checks pass. In the same or different examples, boot code 140 may determine that REC signature 3312 is valid by taking the following steps:

[0370] 1. Verify the availability of SRAM PUF (e.g., PUF activation code 621 ( Figure 6 ) exists in the secure RPMC owner container of the current owner). In an example, a non-zero PUF activation code 621 may indicate the presence of the PUF activation code 621 and the availability of the SRAM PUF.

[0371] 2. Generate an ECDSA-384 private key for signing REC 3302. In an example, the boot code 140 may use the PUF engine 1955 (and the SRAM PUF API functions) ( Fig.19 ) to generate a private key. The PUF engine 1955 can return a key code for the newly generated key.

[0372] 3. Generate an ECDSA-384 public key from the private key. In an example, the boot code 140 can use the key code obtained in step #2 to request the PUF engine 1955 to generate the corresponding public key (e.g., Fig.19 Action 14).

[0373] 4. Use the derived public key to verify REC 3302. In an example, the boot code 140 may request the PUF engine 1955 to verify REC 3302 using the public key obtained in step #3 and the REC 3302 header, content, and signature (which may be stored in volatile memory (e.g., SRAM)).

[0374] In the same or different examples, boot code 140 can determine that REC RPMC value 3431 is valid by comparing it with REC current RPMC value 3104 in OTP memory 110. In an example, when the value of RECRPMC value 3431 is equal to the index of the least significant bit set to zero in the revocation emulation container (REC) current RPMC value 3104, the REC RPMC value can be valid. In the same or different examples, boot code 140 may perform any of the following integrity checks: (a) correct container version (e.g., version 3501 matches expected value); (b) correct container type 3433 (e.g., REC); (c) correct container content length 3434 (e.g., 0x11c); (d) device serial number 3435 in REC 3302 matches serial number 205 value in OTP memory 110; (e) CCK key hash blob 3436 in REC 3302 matches value programmed in secure RPMC owner container of current owner (e.g., Figure 4 436 in REC); (f) Owner ID 3502 in REC is equal to the owner ID in the secure RPMC owner container of the current owner (e.g., Figure 5 or (g) revoke the mask data (e.g., 3506 / 3507) to match the value stored in the secure RPMC owner container of the current owner (e.g., Fig.32 3215 / 3216 in the table above).

[0375] If at block 3616 the boot code 140 determines that it has found a valid REC, the boot code 140 may proceed to block 3619 where the boot code uses the verified REC from the non-volatile memory 173 in subsequent steps. If at block 3616 the boot code 140 determines that it has not found a valid REC, the boot code 140 may proceed to block 3622 where the boot code determines whether a new REC can be generated. In an example, (1) if no asset (e.g., key, image revision, hash table, etc.) has been revoked by the current owner, and (2) the current owner's secure RPMC owner container has a valid PUF activation code 621 ( Figure 6 ), the boot code 140 can determine that a new REC can be generated. Fig.38 An example of determining whether the current owner has not revoked the asset is illustrated. In the same or different examples, a non-zero PUF activation code 621 can indicate a valid PUF activation code 621 .

[0376] If at block 3622, boot code 140 determines that a new REC can be generated, boot code 140 can proceed to block 3625 where it can create a new REC. In an example, boot code 140 will create a new REC when a new owner of electronic device 101 is established (e.g., when deactivate emulation feature enable 3102 indicates that the feature is enabled).

[0377] Fig.37 The example is related to undoing simulation and more specifically to creating a new REC ( Fig.36 ) block diagram of various RPMC values ​​associated with the REC container, including how a REC container can be bound to an owner container when created. In the example, the REC current RPMC value [319:0] 3704 in the OTP memory 110 can be 320 bits wide, thereby allowing 320 different secure revocation emulation containers in the electronic device 101. (REC current RPMC value [319:0] 3704 is Fig.31 3702 and REC RPMC value 3731 are examples of REC 3302 and REC RPMC value 3431.) In the example, when a new owner of the electronic device 101 is established, a new REC 3702 may be created (e.g., Fig.36 When creating a new REC 3702, the boot code 140 may set the values ​​of both the owner REC RPMC 3714 and the REC RPMC value 3731 to "Offset (N+1)", which may be the index of the least significant bit set to zero in REC Current RPMC Value [319:0] 3704 (as shown in block 3760).

[0378] Fig.38 A block diagram illustrating various RPMC values ​​associated with revocation simulation and more specifically with updating RPMC values ​​when revoking an asset (e.g., a key, image, hash table), including how the REC RPMC value may be incremented to revoke an asset. In the example, the RPMC value from Fig.37RPMC value can exist in electronic device 101 after ownership change.When asset is revoked, boot code 140 can increment REC RPMC value 3831 (for example, increment to N+2), and can set the least significant bit of zero (for example, N+1) in REC current RPMC value [319:0] 3804 to one, as shown in frame 3860.In the same example, boot code 140 can not change owner REC RPMC 3814 (its value can still be N+1).Therefore, once asset is revoked, owner REC RPMC 3814 (for example, N+1) just may be less than the offset (for example, index) of the least significant bit equal to zero in REC current RPMC value [319:0] 3804 in OTP memory 110.In the example, boot code 140 can use these values ​​at frame 3622 place to determine whether new REC can be generated. If the owner REC RPMC 3814 is equal to the offset of the least significant bit equal to zero in the REC current RPMC value [319:0] 3804, the boot code 140 can determine that the current owner has not revoked the asset (e.g., key, image, hash table), and therefore a new REC can be generated. If not, the boot code 140 may not create a new REC because the current owner may have revoked one or more assets.

[0379] According to the example, when ownership is transferred, both owner REC RPMC 3814 and REC RPMC value 3831 can be initialized to value eight (1000b). This initialization can occur when bits 0 to 7 of REC current RPMC value [319:0] 3804 are set to one (1). In this example, N=7 and (N+1)=8. When the asset is revoked, the boot code 140 can increment RECRPMC value 3831 to value nine (1001b) (e.g., increment to N+2), and the least significant bit (e.g., bit 8 (i.e., N+1)) set to zero in REC current RPMC value [319:0] 3804 can be set to one. In this example, the boot code 140 may determine that it may not create a new REC because the owner REC RPMC 3814, which holds its initialized value of eight, is less than (and not equal to) the offset of the least significant bit equal to zero in the REC current RPMC value [319:0] 3804, which is now bit nine (N+2) because bit eight is set to one.

[0380] Return to Fig.36If the boot code 140 determines that a new REC cannot be generated at block 3622, the boot code 140 may proceed to block 3649, indicating a recoverable fatal error. In an example, at block 3649, the boot code 140 may cause the electronic device 101 to enter a crisis recovery mode so that the current owner can use a crisis port (e.g., I2C, UART) for recovery by transferring ownership of the electronic device 101.

[0381] The boot code may proceed from any of blocks 3613, 3619, and 3625 to block 3628, where the boot code may use the asset revocation information when authenticating the asset. In the example where the boot code reaches block 3628 from block 3613, the boot code may use the asset revocation information retrieved from the OTP memory when authenticating the asset (block 3616). In the example where the boot code reaches block 3628 from block 3619, the boot code may use the asset revocation information retrieved from the verified REC when authenticating the asset (block 3619). In the example where the boot code reaches block 3628 from block 3625, the boot code may use the asset revocation information retrieved from the newly created REC when authenticating the asset (block 3625).

[0382] After box 3628, the boot code 140 can proceed to box 3631, where the boot code can determine whether it can find a valid image. In an example, an image that the boot code 140 authenticates and has not been revoked can be a valid image. In an example where the revocation emulation feature enable 3102 is enabled, the boot code 140 can 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 the image. This can allow the boot code 140 to use the authenticated revocation emulation data (e.g., Fig.35 3503 to 3505 in ). In an example, the boot code 140 may check whether the key used to sign the image has been revoked and whether the image itself has been permanently removed from service (i.e., rollback protection). The boot code 140 may use the revocation and rollback protection information in the same manner during authentication, regardless of whether the source of the revocation and rollback protection information (i.e., revocation emulation data) is the OTP memory 110 or the REC 3302.

[0383] If the boot code 140 determines that it has found a valid image at box 3631, the boot code 140 can proceed to box 3634, where it can determine whether to revoke the asset. In an example, the boot code 140 can use the revocation information obtained from the current owner of the electronic device 101 to determine whether to revoke the asset. For example, the revocation information can be provided via the revocation information stored in the verification image stored in the non-volatile memory. Because the current owner's secret (e.g., private key) can be used to verify the image, the current owner can maintain control of the revocation of assets such as images, hash tables, and keys. In an example, the boot code 140 can load and verify the image, and then check the revocation information within the image to determine whether any of the assets (e.g., keys, images, hash tables) of the current silicon owner have been revoked. In an example, the revocation information within the verified image can include a single permission bit corresponding to each available asset, and if the corresponding permission bit is set within the verified image, the boot code 140 can determine that the asset should be revoked.

[0384] If at block 3634, the boot code 140 determines that there are assets to be revoked, the boot code 140 may proceed to block 3637 where it may update the revocation data. In an example, if the revocation emulation feature is not enabled (e.g., the revocation emulation feature enable 3102 is not set), the boot code 140 may update the revocation data in the OTP memory 110 (e.g., the corresponding bits in the programming areas 3108 to 3112 ( Fig.31 )). In an example, if the de-emulation feature is enabled (e.g., de-emulation feature enable 3102 is set), the boot code 140 may update the corresponding EOTP bits (e.g., de-emulation information 3503 to 3505) in the 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 memory) 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 to Fig.36 . The method may be more secure than operating on a copy of the REC in non-volatile memory 173 that may be accessed by a malicious user. ) In the example where the revoke emulation feature enable 3102 is enabled, the boot code 140 may re-sign the REC 3302 in the volatile memory 172 (e.g., as described for REC signature 3312).

[0385] After updating the revocation data in block 3637, the boot code may proceed to block 3640 where it may update the REC 3302 in the non-volatile memory 173. In the example where the revocation emulation feature enable 3102 is not enabled, the boot code 140 may proceed from block 3640 to end block 3650 without updating the REC 3302 because there may be no REC 3302 in the non-volatile memory 173 in this case. In the example where the revocation emulation feature enable 3102 is enabled, the boot code 140 may take the following actions to update the REC 3302 in the non-volatile memory 173:

[0386] 1. Update the fallback REC in the nonvolatile memory 173. In an example, the boot code 140 may do this by erasing the fallback REC, writing an updated fallback REC to the same location, reading the updated fallback REC from the nonvolatile memory 173, and verifying that the updated fallback REC read from the nonvolatile memory 173 is valid.

[0387] 2. Increment the current RPMC value 3104 of the Revocation Emulation Container (REC) in the OTP memory 110.

[0388] 3. Update the master REC in the nonvolatile memory 173. In an example, the boot code 140 may do this by erasing the master REC, writing the updated master REC to the same location, reading the updated master REC from the nonvolatile memory 173, and verifying that the updated master REC read from the nonvolatile memory 173 is valid.

[0389] After block 3640, the boot code 140 may proceed to end block 3650. If the boot code 140 determines at block 3634 that there are no assets to be revoked, the boot code 140 may proceed to end block 3650. In an example, the boot code 140 may perform operations to exit the boot sequence in block 3650, thereby allowing the electronic device 101 to continue normal operation.

[0390] although Fig.36 A specific number of operations associated with method 3600 are disclosed, but method 3600 may utilize more Fig.36 The boot code 140 may perform more or less of the operations depicted. For example, if the boot code 140 determines at block 3634 that there are no assets to be revoked, the boot code 140 may proceed to check whether the fallback REC needs to be repaired, and if so, repair the fallback REC by replacing the fallback REC with a copy of the valid primary REC. As another example, if a new REC cannot be generated (block 3622) or a valid image is not found (block 3631), the boot code 140 may proceed to a recoverable fatal error block. In addition, although Fig.36A certain order of operations to be taken with respect to method 3600 is disclosed, but the operations constituting method 3600 may be performed in any suitable order.

[0391] Figure 39a to Figure 39b Flowchart illustrating an example method 3900 for managing ownership, keys, images, and other assets associated with an owner of an electronic device. According to one example, the method 3900 may begin at block 3910. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 3900 and the order of 3910 to 3960 that make up the method 3900 may depend on the specific implementation selected.

[0392] At box 3910, for an electronic device having a processor, a non-volatile memory, a boot code, and a static random access memory (SRAM) including a SRAM physically unclonable function (SRAM PUF) region, the processor may generate a first unique private key based on at least one or more of: (i) first owner 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 box 3915, the processor may create a first owner revocation simulation container for the first owner of the electronic device, wherein the first owner revocation simulation container may include first asset revocation information. At box 3920, the processor may use the first unique private key to generate a first signature corresponding to the first owner revocation simulation container.

[0393] At box 3925, the processor may store the first signature in non-volatile memory. At box 3930, the processor may store the first owner revocation simulation container in non-volatile memory. At box 3935, the processor may retrieve the first signature from the non-volatile memory. At box 3940, the processor may retrieve the first owner revocation simulation container from the non-volatile memory. At box 3945, the processor may derive the first unique public key from the first unique private key. At box 3950, the processor may verify the first owner revocation simulation container retrieved from the non-volatile memory using the first unique public key and the first signature retrieved from the non-volatile memory.

[0394] Upon successful verification of the first owner revocation simulation container retrieved from the non-volatile memory, at box 3955, the processor may use the first asset revocation information of the first owner revocation simulation container retrieved from the non-volatile memory to determine whether to revoke the use of the first owner asset associated with the first owner of the electronic device. In one example, the first owner 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 box 3960, the processor may revoke subsequent use of the first owner asset based on determining that the first owner asset should be revoked. In an example, the processor may determine that the first owner asset should be revoked by determining that the first asset revocation information of the first owner revocation simulation container has been programmed once.

[0395] although Figure 39a to Figure 39b A specific number of operations associated with method 3900 are disclosed, but method 3900 may be used in a manner similar to Figure 39a to Figure 39b For example, after block 3960, method 3900 may continue Figure 40 to Figure 42 Additional operations are shown. Furthermore, although FIG. 39 discloses a certain order for operations to be performed with respect to method 3900, the operations that make up method 3900 may be performed in any suitable order.

[0396] Fig.40 Flowchart illustrating an example method 4000 for managing ownership, keys, images, and other assets associated with an owner of an electronic device. According to one example, the method 4000 may begin at block 4010. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 4000 and the order of 4010 to 4015 constituting the method 4000 may depend on the specific implementation selected.

[0397] According to an example, block 4010 may be associated with Figure 39a to Figure 39b The blocks 3910 to 3960 in FIG. 4015 are the same. At block 4015, the processor may program the first asset revocation information of the first owner revoking the emulation container in a one-time programmable manner. In an example, the processor may execute a trusted boot code 140 (e.g., an immutable boot code or an authenticated ROM extension in the FMC) that may program the first asset revocation information of the first owner revoking the emulation container, and may not provide a command in the boot code 140 (or other code) to deprogram the information.

[0398] although Fig.40 A specific number of operations are disclosed in connection with method 4000, but method 4000 may utilize more Fig.40More or fewer operations may be performed than those depicted. In addition, although Fig.40 A certain order of operations to be taken with respect to method 4000 is disclosed, but the operations constituting method 4000 may be performed in any suitable order.

[0399] Fig.41 Flowchart illustrating an example method 4100 for managing ownership, keys, images, and other assets associated with an owner of an electronic device. According to one example, the method 4100 may begin at block 4110. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 4100 and the order of 4110 to 4125 that make up the method 4100 may depend on the specific implementation selected.

[0400] According to an example, block 4110 may be associated with Figure 39a to Figure 39b The processor may create a second owner revocation emulation container for the second owner of the device, and 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 the use of the second owner asset associated with the second owner of the device. At block 4125, the processor may revoke subsequent use of the second owner asset based on determining that the second owner asset should be revoked.

[0401] although Fig.41 A specific number of operations associated with method 4100 are disclosed, but method 4100 may utilize Fig.41 The operations depicted may be performed with more or fewer operations. For example, after block 4125, method 4100 may continue Fig.42 In addition, although Fig.41 A certain order of operations to be taken with respect to method 4100 is disclosed, but the operations constituting method 4100 may be performed in any suitable order.

[0402] Fig.42 Flowchart illustrating an example method 4200 for managing ownership, keys, images, and other assets associated with an owner of an electronic device. According to one example, the method 4200 may begin at block 4210. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 4200 and the order of 4210 to 4250 that make up the method 4200 may depend on the specific implementation selected.

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

[0404] although Fig.42 A specific number of operations associated with method 4200 are disclosed, but method 4200 may utilize Fig.42 More or fewer operations may be performed than those depicted. In addition, although Fig.42 A certain order of operations to be taken with respect to method 4200 is disclosed, but the operations constituting method 4200 may be performed in any suitable order.

[0405] Fig.43 Flowchart illustrating an example method 4300 for managing ownership, keys, images, and other assets associated with an owner of an electronic device. According to one example, the method 4300 may begin at block 4310. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 4300 and the order of 4310 to 4325 that make up the method 4300 may depend on the specific implementation selected.

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

[0407] although Fig.43 A specific number of operations associated with method 4300 are disclosed, but method 4300 may utilize Fig.43 The operations depicted may be performed with more or fewer operations. For example, after block 4325, method 4300 may continue Fig.44 In addition, although Fig.43 A certain order of operations to be taken with respect to method 4300 is disclosed, but the operations constituting method 4300 may be performed in any suitable order.

[0408] Fig.44 Flowchart illustrating an example method 4400 for managing ownership, keys, images, and other assets associated with an owner of an electronic device. According to one example, the method 4400 may begin at block 4410. The teachings of the present disclosure may be implemented in a variety of configurations of the system 100. Thus, the initialization point of the method 4400 and the order of 4410 to 4420 constituting the method 4400 may depend on the specific implementation selected.

[0409] According to an example, block 4410 may be associated with Fig.4343. The processor may generate a plurality of unique private keys, the respective unique private keys corresponding to respective 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 an example, the processor may generate respective unique private keys of the plurality of unique private keys based at least on one or more of the following: (i) owner information associated with respective owners of the electronic device over time; and (ii) at least a portion of a static random access memory (SRAM) physical unclonable function (SRAM PUF) region of the electronic device. At box 4420, the processor may use respective unique private keys of the plurality of unique private keys to sign and verify respective revocation emulation containers of the plurality of revocation emulation containers corresponding to respective owners of the electronic device over time.

[0410] although Fig.44 A specific number of operations associated with method 4400 are disclosed, but method 4400 may utilize Fig.44 More or fewer operations may be performed than those depicted. In addition, although Fig.44 A certain order of operations to be taken with respect to method 4400 is disclosed, but the operations constituting method 4400 may be performed in any suitable order.

[0411] Methods 1700, 2000 to 3000, 3600, and 3900 to 4400 may be implemented using system 100 or any other system operable to implement methods 1700, 2000 to 3000, 3600, and 3900 to 4400. Although examples have been described above, other variations and examples may be made in accordance with the present disclosure without departing from the spirit and scope of these disclosed examples.

Claims

1. A device, comprising: Boot code; Non-volatile memory; The boot code is executable by the processor to: generating a first unique private key, wherein the first unique private key is not directly accessible by code other than the boot code; Creating a first owner revocation simulation container for a first owner of the device, wherein the first owner revocation simulation container includes first asset revocation information; generating, using the first unique private key, a first signature corresponding to the first owner revocation emulation container; storing the first signature in the non-volatile memory; storing the first owner revocation emulation container in the non-volatile memory; retrieving the first signature from the non-volatile memory; retrieving the first owner revocation emulation container from the non-volatile memory; deriving a first unique public key from said first unique private key; verifying the first owner revocation emulation container retrieved from the non-volatile memory using the first unique public key and the first signature retrieved from the non-volatile memory; after successfully verifying the first owner revocation emulation container retrieved from the non-volatile memory, determining whether to revoke use of a first owner asset associated with the first owner of the device using the first asset revocation information of the first owner revocation emulation container retrieved from the non-volatile memory; and Subsequent use of the first owner asset is revoked based on a determination that the first owner asset should be revoked. 2 . The apparatus of claim 1 , wherein the boot code comprises an immutable boot code stored in a read-only memory.

3. The device according to any one of claims 1 to 2, comprising: A static random access memory (SRAM), wherein the static random access memory (SRAM) includes a SRAM physically unclonable function (SRAM PUF) region; Wherein the boot code executable by the processor to generate a first unique private key includes the boot code executable by the processor to generate the first unique private key based on 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 area.

4. The apparatus of any one of claims 1 to 3, wherein the boot code is executable by the processor to: The first asset revocation information of the first owner revoking the emulation container is programmed in a one-time programmable manner.

5. The device of claim 4, wherein programming the first asset revocation information of the first owner revoking the emulation container in a one-time programmable manner comprises: After the first asset revocation information of the first owner-revoked emulation container has been programmed by the boot code, there is no boot code for modifying the first asset revocation information of the first owner-revoked emulation container.

6. A device according to any one of claims 4 to 5, wherein the boot code is executable by the processor to revoke the subsequent use of the first owner's asset based on determining that the first owner's asset should be revoked, including determining that the first owner has revoked the first asset revocation information of the simulation container that has been programmed once.

7. A device according to any one of claims 1 to 6, wherein the first owner asset associated with the first owner of the device includes 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. The apparatus of any one of claims 1 to 7, wherein the boot code is executable by the processor to: creating a second owner revocation simulation container for a second owner of the device, wherein the second owner revocation simulation container includes second asset revocation information; using the second asset revocation information of the second owner revoking the emulation container to determine whether to revoke use of a second owner asset associated with the second owner of the device; and The subsequent use of the second owner asset is revoked based on a determination that the second owner asset should be revoked.

9. The device according to claim 8, comprising: A static random access memory (SRAM), wherein the static random access memory (SRAM) includes a SRAM physically unclonable function (SRAM PUF) region; Wherein the boot code is executable by the processor to: generating a second unique private key based on at least one or more of: (i) second owner information associated with the second owner of the device; and (ii) at least a portion of the SRAM PUF area, wherein the second unique private key is not directly accessible by code other than the boot code; generating, using the second unique private key, a second signature corresponding to the second owner revocation emulation container; storing the second signature in the non-volatile memory; storing the second owner revocation emulation container in the non-volatile memory; retrieving the second signature from the non-volatile memory; retrieving the second owner revocation emulation container from the non-volatile memory; deriving a second unique public key from the second unique private key; The second owner revocation emulation container retrieved from the non-volatile memory is verified using the second unique public key and the second signature retrieved from the non-volatile memory.

10. A method comprising: For an electronic device having a processor, a non-volatile memory, a boot code, and a static random access memory (SRAM) including a SRAM physically unclonable function (SRAM PUF) region, the processor generates a first unique private key based on at least one or more of: (i) first owner 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 creates a first owner revocation simulation container for the first owner of the electronic device, the first owner revocation simulation container including first asset revocation information; the processor generating, using the first unique private key, a first signature corresponding to the first owner revocation emulation container; The processor stores the first signature in the non-volatile memory; The processor stores the first owner revocation emulation container in the non-volatile memory; the processor retrieving the first signature from the non-volatile memory; the processor retrieving the first owner revocation emulation container from the non-volatile memory; the processor deriving a first unique public key from the first unique private key; the processor verifying the first owner revocation emulation container retrieved from the non-volatile memory using the first unique public key and the first signature retrieved from the non-volatile memory; upon successful verification of the first owner revocation emulation container retrieved from the non-volatile memory, the processor using the first asset revocation information of the first owner revocation emulation container retrieved from the non-volatile memory to determine whether to revoke use of a first owner asset associated with the first owner of the electronic device; as well as The processor revokes the subsequent use of the first owner asset based on determining that the first owner asset should be revoked.

11. The method according to claim 10, comprising: The processor programs the first asset revocation information of the first owner revoking the emulation container in a one-time programmable manner.

12. The method of claim 11, wherein the processor revoking the subsequent use of the first owner asset based on determining that the first owner asset should be revoked comprises determining that the first asset revocation information of the first owner revoking emulation container has been one-time programmed.

13. A method according to any one of claims 10 to 11, wherein the first owner asset associated with the first owner of the electronic device includes 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.

14. The 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 including second asset revocation information; The processor determines whether to revoke use of a second owner asset associated with the second owner of the device using the second asset revocation information of the second owner revoking the emulation container; as well as The processor revokes the subsequent use of the second owner asset based on determining that the second owner asset should be revoked.

15. The method according to claim 14, comprising: The processor generates a second unique private key based on at least one or more of: (i) second owner information associated with the second owner of the device; and (ii) at least a portion of the SRAM PUF area, wherein the second unique private key is not directly accessible by code other than the boot code; the processor generating, using the second unique private key, a second signature corresponding to the second owner revocation emulation container; The processor stores the second signature in the non-volatile memory; The processor stores the second owner revocation emulation container in the non-volatile memory; the processor retrieving the second signature from the non-volatile memory; the processor retrieving the second owner revocation emulation container from the non-volatile memory; the processor deriving a second unique public key from the second unique private key; The processor verifies the second owner revocation emulation container retrieved from the non-volatile memory using the second unique public key and the second signature retrieved from the non-volatile memory.

16. A method comprising: For an electronic device having a processor and boot code, the processor creates a plurality of revocation emulation containers corresponding to a plurality of owners of the electronic device over time, wherein respective revocation emulation containers include asset revocation information associated with respective owners of the electronic device; The processor programs the asset revocation information of the plurality of revocation simulation containers in a one-time programmable manner; the processor using the asset revocation information of the plurality of revocation emulation containers to determine whether to revoke use of a corresponding asset from a plurality of assets associated with the plurality of owners of the electronic device over time; as well as The processor revokes the subsequent use of the respective asset based on determining that the respective asset of the plurality of assets associated with the plurality of owners of the electronic device over time should be revoked.

17. The method according to claim 16, comprising: the processor generating a plurality of unique private keys, respective unique private keys corresponding to respective ones of the plurality of owners of the electronic device over time, wherein the plurality of unique private keys are not directly accessible by code other than the boot code; as well as The processor signs and verifies a corresponding one of the plurality of revocation emulation containers corresponding to a corresponding one of the plurality of owners of the electronic device over time using a corresponding one of the plurality of unique private keys.

18. A method according to claim 17, wherein the processor generates multiple unique private keys, including generating corresponding unique private keys among the multiple unique private keys based on at least one or more of the following: (i) owner information associated with corresponding owners among the multiple owners of the electronic device; and (ii) at least a portion of a static random access memory (SRAM) physically unclonable function (SRAM PUF) area of ​​the electronic device.

19. A method according to any one of claims 16 to 18, wherein the processor revokes the subsequent use of the corresponding asset based on determining that the corresponding asset in the multiple assets should be revoked, including determining that the corresponding asset revocation information of the corresponding revocation simulation container in the multiple revocation simulation containers has been programmed once.

20. A method according to any one of claims 16 to 19, wherein a corresponding asset among the multiple assets associated with the multiple owners of the electronic device over time includes one of the following: a cryptographic key associated with a corresponding owner among the multiple owners, an executable image associated with a corresponding owner among the multiple owners; and a hash table associated with a corresponding owner among the multiple owners.

Images