CN118020071A

CN118020071A - Managing ownership of electronic devices

Info

Publication number: CN118020071A
Application number: CN202380013701.6A
Authority: CN
Inventors: E·玛兰多; R·瓦勒; A·克里希南; R·戈德伯格
Original assignee: Microchip Technology Inc
Current assignee: Microchip Technology Inc
Priority date: 2022-02-27
Filing date: 2023-02-27
Publication date: 2024-05-10

Abstract

A device having one-time programmable (OTP) memory, boot code, volatile memory, and non-volatile memory. The boot code may use information in the OTP to authenticate the code of the implicit owner of the electronic device; receiving a first create owner container request; creating a first owner container comprising a first signed data image; storing a first owner container; and authenticating a first executable code associated with the first owner using the first signed data image. The boot code may transfer ownership from the first owner to the second owner, including authenticating the signed ownership transfer command using a key stored in the first owner container, and creating a second owner container including a second signed data image associated with the second owner; storing a second owner container; revocation of the first owner container; and authenticating a second executable code associated with a second owner of the electronic device using the second signed data image.

Description

Managing ownership of electronic devices

Priority

The present application claims priority from U.S. provisional patent application No. 63/314,428, filed 2/27 at 2022, the contents of which are hereby incorporated by reference in their entirety.

Technical Field

The present disclosure relates to electronic devices, and more particularly, to systems and methods for managing ownership of electronic devices over time, including secure transfer of ownership of electronic devices.

Background

In a computing product, embedded Controller (EC) boot code stored in a boot ROM may act as a root of trust (RoT) for a secure boot application of a particular owner of an electronic device (e.g., original Equipment Manufacturer (OEM)). The OEM may store the configuration options in one-time programmable (OTP) memory during device provisioning. This may include cryptographic keys used to encrypt and sign the boot image. The OEM may implement and sign the EC boot image that is loaded and authenticated by the boot code stored in the boot ROM. The boot code may authenticate and decrypt the boot image using the custom value stored in the OTP memory. Other features supported by the boot code may include key revocation and rollback protection. This may allow an owner to deactivate one or more keys in a key list stored on the electronic device or to remove a particular mirror revision from service, particularly by setting a bit in OTP memory during a boot sequence.

An EC with secure boot typically has a single configuration provided in OTP memory that is determined by a first owner (e.g., OEM) at the time of manufacture. A mirror authentication key manifest is generated, hashed and stored in a Key Hash Blob (KHB), and a hash of KHB is stored in OTP memory. As a result, the owner of the device uses the OEM signed image.

The present disclosure provides systems and methods for supporting multiple owners of a particular electronic device for extended periods of time, including secure transfer of ownership between different owners.

Disclosure of Invention

According to one example, a system may include an electronic device. The electronic device may have one-time programmable (OTP) memory, boot code, volatile memory, and non-volatile memory. The boot code may include an immutable code stored in read-only memory, an authentication code stored in non-volatile memory, or an authentication code stored in volatile memory. The boot code is executable by the processor to authenticate code associated with an implicit owner of the electronic device using information stored in the OTP memory; receiving a first create owner container request from an authentication code associated with an implicit owner of the electronic device; in response to the first create owner container request, create a first owner container for a first owner of the electronic device, the first owner container including a first signed data image associated with the first owner of the electronic device; storing the first owner container in a non-volatile memory; a first executable code associated with a first owner of the electronic device is authenticated using a first signed data image associated with the first owner of the electronic device. The boot code is executable by the processor to perform an ownership transfer from a first owner of the electronic device to a second owner of the electronic device, which may include verifying the signed ownership transfer command using a key stored in the first owner container; in response to successful authentication of the signed ownership transfer command, creating a second owner container comprising a second signed data image associated with a second owner of the electronic device; storing the second owner container in a non-volatile memory; revocation of the first owner container; a second executable code associated with a second owner of the electronic device is authenticated using a second signed data image associated with the second owner of the electronic device.

Another example provides a method for an electronic device having a one-time programmable (OTP) memory and a non-volatile memory. The method may include authenticating a code associated with an implicit owner of the electronic device using information stored in the OTP memory. The method may include receiving a first create owner container request from an authentication code associated with an implicit owner of the electronic device, and creating 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. The method may include storing a first owner container in a non-volatile memory and authenticating a first executable code associated with a first owner of the electronic device using a first signed data image associated with the first owner of the electronic device. The method may include authenticating the signed ownership transfer command using a key stored in the first owner container, and creating a second owner container for a second owner of the electronic device in response to successful authentication of the signed ownership transfer command, the second owner container including a second signed data image associated with the second owner of the electronic device. The method may include storing a second owner container in the non-volatile memory, revoking the first owner container, and authenticating a second executable code associated with a second owner of the electronic device using a second signed data image associated with the second owner of the electronic device.

Another example provides a system that may include an electronic device. The electronic device may have a one-time programmable (OTP) memory that includes configuration information corresponding to an implicit owner of the electronic device. The electronic device may also have an immutable boot code stored in read-only memory and non-volatile memory. The immutable boot code is executable by the processor to determine whether the first owner container is present in the non-volatile memory, and in response to determining that the first owner container is not present in the non-volatile memory, prohibit loading executable code that cannot be authenticated using configuration information corresponding to an implicit owner of the electronic device. The boot code may also authenticate the first executable code associated with the implicit owner of the electronic device using configuration information corresponding to the implicit owner of the electronic device. The boot code may also load authenticated first executable code associated with an implicit owner of the electronic device. The boot code may receive a first create owner container request from authenticated executable code associated with an implicit owner of the electronic device. The boot code 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. The boot code may store the first owner container in the non-volatile memory and, in response to determining that the first owner container is present in the non-volatile memory, disable loading of executable code that cannot be authenticated using the first signed data image associated with the first owner of the electronic device. The boot code may also authenticate the first executable code associated with the first owner of the electronic device using the first signed data image associated with the first owner of the electronic device and load the authenticated first executable code associated with the first owner of the electronic device.

Drawings

The figures illustrate example methods and systems for managing ownership of an electronic device over time, including secure transfer of ownership of the electronic device.

FIG. 1 illustrates a block diagram of an example system for managing ownership of an electronic device over time, including secure transfer of ownership through the electronic device.

FIG. 2 illustrates a block diagram of an example OTP memory for managing ownership of an electronic device over time, including secure transfer of ownership over time through the electronic device.

Fig. 3 illustrates a block diagram of an exemplary secure RPMC owner container for managing ownership of an electronic device over time, including secure transfer of ownership through the electronic device.

FIG. 4 illustrates a block diagram of an example container header for an owner container for managing ownership of an electronic device.

FIG. 5 illustrates a block diagram of example container content for an owner container for managing ownership of an electronic device.

FIG. 6 illustrates a block diagram of example container content for an owner container for managing ownership of an electronic device.

FIG. 7 illustrates an example command memory.

FIG. 8 shows a block diagram of 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.

FIG. 9 illustrates a block diagram of an example of managing ownership of an electronic device including creating a first owner container by using an OEM signed mirror and OTP emulation configuration.

FIG. 10 illustrates a flow chart of an example method for managing ownership of an electronic device over time, including secure transfer of ownership of the electronic device.

Fig. 11 and 12 show block diagrams of two examples of managing ownership of an electronic device using an unrestricted transfer and an Owner Transfer Authorization Key (OTAK).

Fig. 13 shows a block diagram of an example of managing ownership of an electronic device, including transferring ownership using a Container Command (CCK) key of a current owner and a first variable binary (FMB) configuration stored in OTP memory.

FIG. 14 illustrates a flow chart of an example method for managing ownership of an electronic device over time, including secure transfer of ownership of the electronic device.

FIG. 15 illustrates a flow chart of an example method for managing ownership of an electronic device over time, including secure transfer of ownership of the electronic device.

The reference numerals for any illustrated element appearing in a plurality of different figures have the same meaning in the plurality of figures, and the references or discussion herein to any illustrated element in the context of any particular figure also apply to every other figure (if any) in which the same illustrated element is shown.

Detailed Description

The present disclosure provides systems and methods for supporting multiple owners of a particular electronic device over time, including secure transfer of ownership among different owners, by storing each owner's information and configuration in a signed secure Replay Protection Monotonic Counter (RPMC) owner container in memory (e.g., serial Peripheral Interface (SPI) flash memory). In one example, the owner's cryptographic key, secret, and configuration information may be stored in a secure manner in a non-volatile memory (NVM) (e.g., OTP memory, SPI flash, or Electrically Erasable Programmable Read Only Memory (EEPROM)). Because the security information may be stored in erasable memory, the content may be signed and verified before being used to aid in security. In some examples, the systems and methods for storing and updating secure RPMC owner containers may adhere to NIST 800-193 platform firmware elastic guidelines.

When an electronic device (e.g., a microcontroller) is booted (e.g., powered on or after a hardware or software reset), the boot code may be loaded and executed by a processor on the device. The boot code may perform functions related to device initiation, such as initializing hardware, which may include disabling interrupts, initializing buses, setting the processor to a particular state, and initializing memory. After performing the hardware initialization, the boot code may then load a first variable code (FMC), for example, from a signed first variable binary (FMB) that may include one or more awards. In one example, the FMC may be application firmware that may be signed by the 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 ROM extension (rom_ext) or boot code extension, RIoT code, or other variable code. The function performed by the boot code may be referred to as a boot process.

The electronic device may contain a security mechanism to prevent malicious attacks on the device. 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 one example, these operations may require knowledge of a secret (e.g., a cryptographic key) known to the silicon owner. Because the silicon owner controls secrets (e.g., cryptographic keys) for loading and execution of the FMC, transfer of ownership, and crisis recovery, malicious attacks on the device may be reduced.

The silicon owner or owner of the electronic device may be the entity that provides the signed FMB loaded and authenticated by the boot code. The FMB may contain an FMC image that is loaded and executed by the boot code. The owner may provide a KHB that may include a hash of each of the public keys that may be used to authenticate the FMB. For example, during manufacturing, a hash of the OEM KHB may be stored in OTP memory, and the OEM KHB itself may be stored in non-volatile memory (e.g., SPI flash). The boot code may calculate SHA384 (OEM KHB) and compare it to the hashes of OEM KHB stored in the OTP memory. If the calculated hash matches the stored hash, the boot code may trust public key hashes stored in the OEM KHB and use those public key hashes to authenticate the OEM FMB. The OEM may establish ownership during manufacture (e.g., the OEM acts as an implicit owner) or upon request of ownership by another entity. Once ownership is established, the silicon owner may choose to use the OEM image signed by the OEM image signing key, or the owner may provide his own image signed by his 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). The owner's mirror signing key may be verified by a hash stored in the KHB provided by the owner. 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 public key hashes stored in the owner-provided KHB and use those public key hashes to authenticate the owner-provided FMB.

The security features of the electronic device may be implemented using a boot code on the electronic device. In one example, the security feature may be implemented using immutable boot code. An immutable boot code, which may be referred to as a hardware trust root (RoT), may be built into the electronic device during manufacture and thus may be implicitly trusted because it cannot be modified.

For purposes of this disclosure, an electronic device may include any tool or set of tools operable to calculate, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, the electronic device may be a personal computer, a PDA, a consumer electronics device, a network storage device, or any other suitable device, and may vary in size, shape, performance, functionality, and price. The electronic device may include memory, one or more processing resources, such as a Central Processing Unit (CPU), or hardware or software control logic. Additional components of the electronic device may include one or more storage devices, one or more communication ports for communicating with external devices as well as various input and output (I/O) devices, such as a keyboard, a mouse, and a video display. The electronic device may also include one or more buses operable to transmit communications between the various hardware components.

System and method for controlling a system

Fig. 1 illustrates a block diagram of an example system 100 for managing ownership of an electronic device 101 over time, including secure transfer of ownership through the electronic device. As depicted in fig. 1, system 100 may include an electronic device 101. The 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 190, and network interface 150 to processor 160. The system bus 121 may be any suitable type of bus structure including a memory bus, a peripheral bus, or a local bus using any of a variety of bus architectures.

Processor 160 may include any system, device, or means operable to interpret or execute program instructions or process data, and may include, but is not limited to, microprocessors, microcontrollers, digital Signal Processors (DSPs), application Specific Integrated Circuits (ASICs), or any other digital or analog circuitry 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 remotely stored program instructions or process data.

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

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 boot-up) of electronic device 101. According to one example, the boot code 140 may be immutable, i.e., built into the electronic device during manufacture, and thus may be implicitly trusted (e.g., a hardware trust root) because it cannot be modified. Boot code 140 may include code that performs functions including, but not limited to, functions F1 (145 a) and F2 (145 b), among others. In one example, the boot code 140 may be an authenticated variable code that may act as a ROM extension (e.g., an FMC that may be authenticated by other boot codes stored in ROM, where the FMC may be stored in volatile memory 172 or nonvolatile memory 173).

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

I/O and port control apparatus 190 may comprise any system, device, or apparatus that is generally operable to receive data from/transmit data to/within electronic device 101. I/O and port control device 190 may include, for example, any number of communication interfaces, graphical interfaces, video interfaces, user input interfaces, or peripheral interfaces (e.g., without limitation, JTAG, I2C, UART, test access ports). 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).

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

Although fig. 1 illustrates various components of electronic device 101, other example systems may include electronic devices having more or fewer components. In one example, an electronic device 101 according to the present disclosure may not include one or all of the components depicted in dashed lines without departing from the spirit and scope of these disclosed examples. Additionally, the various components of the electronic device 101 may reside on the same die (e.g., a primary die) or may reside on different dies. In one 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, various components of electronic device 101 may reside in one or more of the primary dies, in the MCM, and on the outside of the system board.

OTP memory

Fig. 2 shows a block diagram of an example OTP memory 110 for managing ownership of an electronic device 101 over time, including secure transfer of ownership through the electronic device. As depicted in fig. 2, OTP memory 110 may include a plurality of regions including a current RPMC value 202, a boot code generated random secret 203, a device unique random secret 204, a serial number 205, a personalization string 206, secret device unique information 207, and an RPMC flash container state 208.

The current RPMC value 202 may be a replay protection monotonic counter that increases over time. In the example shown in Table 1, the current RPMC value 202 may be an 8-bit region in the OTP memory 110 and may correspond to nine different values (0-8). In this example, the bits in OTP memory 110 for the current RPMC value 202 may be sequentially set from the least significant bit ([ 0 ]) to the most significant bit ([ 8 ]), and the next RPMC value may be the next integer value after the current RPMC value 202. In the same or different examples, values less than the current RPMC value 202 may be considered revoked and values greater than the current RPMC value 202 may be considered unused. In the example shown in table 1, values greater than 8 may not be used. In other examples where more than 8 bits in OTP memory 110 are allocated to current RPMC value 202, values greater than 8 are possible. A value less than the current RPMC value 202 may be considered 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 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).

TABLE 1

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 140. For example, the boot code generated random secret 203 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 one 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 complete. Serial number 205 is a unique serial number assigned to electronic device 101 and programmed into OTP memory 110 during provisioning (e.g., by a tester). The personalization string 206 may be a known string that is 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 ROM 130 instead of being stored in the OTP memory 110.

The secret device unique information 207 may include: (a) A device identity key ("DevIK") (e.g., the private key of a public key cryptographic key pair) or information from which DevIK may be generated; (b) Critical device configurations, e.g., mirror 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 DevIK or other device unique information.

The RPMC flash container state 208 may indicate whether the RPMC owner feature is enabled. In one example, the RPMC owner feature may be disabled by default at manufacture time, and the disabled state may be reflected in the RPMC flash container state 208. The boot code 140 may program the RPMC mountain container state 208 to indicate that the owner feature is enabled when the first owner container is created.

Although fig. 2 shows various regions of OTP memory 110, other example systems may include electronic devices with more or fewer regions.

RPMC owner container

Fig. 3 illustrates a block diagram of an exemplary secure RPMC owner container 302 (owner container 302) for managing ownership of an electronic device 101 over time, including secure transfer of ownership through the electronic device. In one example, the owner container 302 may be a signed data image stored in 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 an executable image of the owner (e.g., FMC in FMB). As shown in fig. 3, the owner container 302 may include three regions: a container header 310, container content 311, and a container signature 312. In one example, the owner container 302 may be a unique signed information container modified by the code that created the container (e.g., boot code 140 or a ROM extension (e.g., in an authenticated FMC)), stored in and retrieved from OTP memory (e.g., OTP memory 110) or other non-volatile memory (e.g., non-volatile memory 173). According to examples in this 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 that creating the container) may require a command interface (e.g., command memory 171, fig. 7) to access or modify information in the owner container 302. In one example, only the immutable boot code (e.g., boot code 140) may access or modify the information in the owner container 302. In one example, the boot code that creates the owner container 302 may create two redundant copies of the owner container 302. One copy may be the primary owner container and the other copy may be the rollback owner container.

Container signature

The container signature 312 may include a signature corresponding to the owner container 302 and may be generated by the boot code 140. In one example, the boot code 140 may use a Physical Unclonable Function (PUF) or Deterministic Random Bit Generator (DRBG) to generate the ECDSA signing key. The ECDSA signing key may be generated by any signing algorithm. For example, the container signature 312 may be an ECDSA-384 signature having the following characteristics:

algorithm: elliptic Curve Digital Signature Algorithm (ECDSA)

Key size: 384 bits

Curve: NIST "secp r1" curve

Hashing algorithm: SHA384

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

The boot code 140 may derive the ECDSA private signing key for signing the owner container 302. In one example, the signing key may be generated from the current owner and the unique silicon die. Thus, there may be a unique signature for each owner of each silicon die. According to one example, the boot code 140 may use the DRBG to derive the ECDSA private signing key and may provide the following inputs to the DRBG:

Personalized string: may be a known character string, such as "content one KeyGenerator".

Additional input: may be { RPMC value 431|device sequence number 435}

Entropy input: may be a device unique random secret 204

True Random Number Generator (TRNG) input: random secret 203, which may be a boot code generation

In the above example, the boot code 140 may generate the ECDSA private signing key using a method of generating a key pair using additional random bits from b.4.1 of the FIPS186-4 specification:

Private key (d)

d＝(c mod(n-1))+1

N=prime number defined for P-384 curve

C=448-bit random positive integer value

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

Although fig. 3 illustrates various areas of the owner container 302, other example systems may include electronic devices having more or fewer areas.

-Container header

Fig. 4 shows a block diagram of an example container header 310 of an owner container 302 for managing ownership of an electronic device 101. In one example, container header 310 may have a common format of an owner container created for electronic device 101. As shown in fig. 4, container header 310 may include regions 431-436, including: RPMC value 431, active container version 432, container type 433, secure container content length 434, device serial number 435, and container command key hash blob 436.

The RPMC value 431 may be 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 one 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., table 2) when the current RPMC value 302 also has a value of three (3). In the same or a different example, 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 (e.g., table 2 (revoked RPMC value)) when the current RPMC value 202 has a value greater than three (3). In some examples, RPMC value 431 may be used to check the primary container and the fallback container.

Active container version 432 may represent a version number of owner container 302. In one example, the owner of the electronic device 101 may desire to update the information in the owner container 302 (e.g., the area shown in fig. 6) in a manner that does not require incrementing the RPMC value 431. Thus, the boot code 140 may increment the active container version 432 as other information is updated. In another example, the boot code 140 may 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 may be the primary owner container of the electronic device 101.

Container type 433 may represent a type associated with owner container 302. In one example, container type 433 may have a value indicating that the container is not initialized. In another example, container type 433 may have a value indicating that owner container 302 is initialized and 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 a serial number of the electronic device 101, e.g., the unique serial number 205 in the OTP memory 110. The container command key hash blob 436 may include a hash (e.g., SHA384 (secure hash algorithm)) of one or more Container Command Keys (CCKs), which may be public keys of a cryptographic key pair. In the illustrated example, the container command key hash blob 436 may include hashes of CCK0 437, CCK1 438, CCK2 439, and CCK3 440. In one example, these key hashes may be used to verify the commands 302 associated with the owner container. In one example, CCK0-3 (437-440) may be revoked by setting the hash entry to zero (0).

-Container content

The owner container 302 may have different configurations that may be based on configuration sources, including:

FMB mirror configuration source = OTP memory (e.g., fig. 5)

OTP emulation in FMB mirror configuration Source = SPI flash RPMC Container (e.g., FIG. 6)

Fig. 5 shows a block diagram of example container content 311a of an owner container 302 for managing ownership of an electronic device 101. As shown in fig. 5, container content 311a may be programmed in OTP memory 110 and may include regions 501-515, including: an owner configuration 501, an owner ID 502, an owner RPMC 503, an Owner Transfer Authorization Key (OTAK) 504, an encrypted ECDH private key 505, an ECDH public key hash 506, a key hash binary large object (KHB) hash 507, a TAGx mirror key revocation 508, a TAGx mirror rollback protection 509, a TAG0 base pointer 510, a TAG1 base pointer 511, a debug support 512, a platform ID 513, a security feature 514, and PlatK hashes 515. In one example, some or all of the container content 311a may be programmed into the OTP memory 110 during provisioning (e.g., by a tester). In the same or a different example, after the provisioning of the electronic device 101 is completed, some or all of the container content 311a may be programmed into the OTP memory 110 by the boot code 140. Higher level firmware (e.g., code other than that which created the container) may require a command interface (e.g., command memory 171, fig. 7) to access or modify information in container content 311a of owner container 302.

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

The owner configuration 501 may include information about who may transfer ownership of the electronic device 101. In one example, the current silicon owner may transfer ownership by executing an ownership transfer command signed by the owner's common Container Command Key (CCK). In another example, both the current silicon owner and the new owner may transfer ownership. The current silicon owners may transfer ownership by executing an ownership transfer command signed by the owners public CCK, and the new owners may transfer ownership by executing an ownership transfer command signed by an Owner Transfer Authorization Key (OTAK). The OTAK may be a public key programmed into the owner container 302 by the current owner (e.g., in the owner transfer authorization key 504) that may enable the new owner (or an approved intermediate entity) to execute the ownership transfer command. The owner configuration 501 may include information indicating whether RPMC owner container crisis commands are supported. In one example, if crisis commands are enabled, the owner may use I/O port control 190 (e.g., I2C crisis port, UART crisis port) to insert owner container commands into command memory 171 (e.g., FIG. 7). In one example, the owner container crisis command may be disabled by default and may be enabled by the owner of the electronic device 101 (e.g., by programming the owner configuration 501).

The owner ID 502 may be a value provided by the owner at the time of ownership transfer and may be used to identify the owner. The owner RPMC 503 may be a value determined by the boot code 140 at the time of ownership transfer. For example, it may be the first RPMC value assigned to the owner at the time of ownership transfer. In one example, the owner ID 502 and the owner RPMC 503 together may indicate a unique owner of a particular electronic device 101. The Owner Transfer Authorization Key (OTAK) 504 may be a one-time ECDSA-384 public key (elliptic curve digital signature algorithm) for verifying transfer of the owner command, for example, when configuration information in the owner configuration 501 enables the new owner to perform transfer of the owner command.

The encrypted ECDH private key 505 may be an encrypted ECDH (elliptic curve Diffie-Hellman) private key that is used to derive an AES256 (advanced encryption standard) mirror encryption key (IEK) that may be used to decrypt the FMB image stored in the nonvolatile memory 173. The ECDH public key hash 506 may be a SHA384 hash of the ECDH public key that may be used to derive an AES256 Key Encryption Key (KEK) that may be used to decrypt the encrypted ECDH private key 505. In one example, the encrypted ECDH private key 505 and ECDH public key hash 506 may be exchanged according to the Diffie-Hellman key exchange protocol and used to decrypt the FMB image.

Key Hash Blob (KHB) hash 507 may be an SHA384 hash of the KHB provided by the owner (e.g., stored in non-volatile memory 173), which may contain a 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 key in the owner's KHB is available or has been revoked (unavailable). In one example, the KHB may include eight (8) public keys, and the TAGx mirror key revocation 508 may include one bit for 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 one 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 or has been revoked (unavailable). In one example, KHB may allow up to 128 mirror revisions, and the TAGx mirror rollback protection 509 may include one bit for each revision. In this example, when a bit in the TAGx mirror rollback protection 509 is programmed to a value of one (1), the corresponding mirror revision may be revoked. In one 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 TAGx image rollback protection 509 is not programmed to a value of one (1)).

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 or not to support debugging (e.g., UART production debugging). Platform ID 513 may include an owner platform identification value. The security feature 514 may indicate whether the current owner has enabled various security features. In one example, the security feature 514 may indicate whether the mirror rollback protection feature is enabled (e.g., whether the mirror revision may be revoked using TAGx mirror rollback protection 509). In the same or a different example, the security feature 514 may indicate whether a key revocation feature is enabled (e.g., whether the key may be revoked using the TAGx image key revocation 508). PlatK hash 515 may include a hash of a platform public key (e.g., SHA 384), which may be a key used to sign crisis commands (e.g., if owner configuration 501 indicates support for RPMC owner container crisis commands).

Although fig. 5 shows various areas of container content 310a, other example systems may include electronic devices with more or fewer areas. In further examples, particular regions of container content 311a may include features other than, or some of, the features described above may be omitted.

Fig. 6 shows a block diagram of example container content 311b of an owner container 302 for managing ownership of the electronic device 101. As shown in fig. 6, the container content 311b may be programmed in the non-volatile memory 173 and may include regions 501-515, the regions 501-515 being described with respect to fig. 5 and differing in that they are stored in the non-volatile memory 173 instead of the OTP memory 110. In one example, the owner container 302 having container content 311b stored in non-volatile memory 173 may emulate the owner container stored in OTP memory 110 (OTP emulation) because boot code 140 may store configuration parameters (e.g., in container content 311 b) when it creates the owner container, and there is no command for boot code 140 (or other code) to modify these parameters. In the event that a malicious user may attempt to alter a signed owner container while the owner container is stored in non-volatile memory 173 (e.g., alter any OTP emulation parameters), verification of the container will fail. Accordingly, the configuration parameters stored in the owner container 302 in the non-volatile memory 173 may be considered to be an analog OTP memory.

In one example, the container content 311b may include a PUF activation code 621 (e.g., the PUF may be based on a physical unclonable function). The boot code 140 may use the PUF activation code 621 to generate and pass the device attestation key (DevAK) to the firmware of the silicon owner. In one example, the boot code 140 may use the shared PUF SRAM to generate and store the PUF activation code 621 in the owner container 311b at a first power-on reset cycle after the owner container 311b is created or updated. During a subsequent boot process, if the boot code 140 is loaded with a reliable image (e.g., FMB), the boot code 140 may use the PUF activation code 621 to generate DevAK private and public keys. In one example, the boot code 140 may place DevAK the public key in an x.509 certificate and sign the certificate (e.g., the secret device unique information 207 in fig. 2) using DevIK private key. In an example, the signed certificate along with PUF activation code 621 may be passed to the owner's firmware (e.g., via firmware mailbox 788 in fig. 7). The owner's firmware can use the PUF activation code to regenerate DevAK the private key 621.

In some examples (not shown), the boot code 140 may generate the PUF activation code 621 during manufacture (e.g., prior to creating the owner container 311 b). 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 activation code 621 when the activation code 621 is retrieved from the non-volatile memory. Thus, the boot code 140 may use the PUF activation code 621 to generate DevAK a private key and a public key, even before the first owner container 311b is created.

Although fig. 6 shows various areas of container content 310b, other example systems may include electronic devices with more or fewer areas. In further examples, particular regions of container content 311b may include features other than or some of the features described above may be omitted.

Command interface

Fig. 7 illustrates an example command memory 171. Command memory 171 may include a rewritable memory (e.g., registers, SRAM) and may contain RPMC container commands 782, boot code mailbox 784, and firmware mailbox 786. According to one example, the boot code 140 may authenticate and optionally decrypt the FMB from the non-volatile memory 173 (e.g., SPI flash) and then may load the FMC into the internal volatile memory 172 (e.g., SRAM) for subsequent execution by the processor 160. For example, the boot code may load the FMB into an internal volatile memory 172 (e.g., SRAM), authenticate the FMB, and optionally decrypt the FMB, which may include one or more images, including the FMC as the first image. In one example, the authenticated and optionally decrypted FMB is retained in a volatile memory 172 (e.g., SRAM). This 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 ownership transfer or perform some other action on behalf thereof. The application may communicate this action by loading the signed command into the boot code mailbox 784, setting the associated command bits in the RPMC container command 782, and triggering a reset (e.g., a soft reset).

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 the application firmware). In one example, the command memory 171 may be user accessible such that code other than the boot code 140 (e.g., FMC) may initiate a request to be processed by the boot code 140. In another example, command store 171 may be accessed via external hardware (UART interface, I2C interface, etc.), for example, to perform crisis restoration (if owner configuration 501 in owner container 311a/b indicates support for RPMC owner container crisis commands).

In one example, RPMC container command 782 may include a bit that, when set, may indicate that the RPMC command is pending for electronic device 101. RPMC container command 782 may additionally include a command field that may indicate a particular command to be processed by boot code 140. In the same or another example, the boot code mailbox 784 may be programmed with command parameters corresponding to pending commands. In one example, the command parameters stored in the boot code mailbox 784 may be signed, and the boot code 140 may authenticate the pending command during the boot process prior to executing the command (e.g., the command may be considered a signed command when the parameters stored in the boot code mailbox 784 are signed).

Owner container action

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

·CREATE_CONTAINER_REQUEST

·INCREMENT_RPMC_REQUEST

·UPDATE_CONTAINER_REQUEST

·REPAIR_FALLBACK_CONTAINER_REQUEST

·CRISIS_RECOVERY_REQUEST

·ENABLE_UNRESTRICTED_TRANSFERS

·UPDATE_OTAK_KEY

In one example, the boot code 140 may authenticate the 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 as a crisis recovery command from the I/O and port control 190 and load it into the internal volatile memory 172 (e.g., SRAM) for execution by the processor 160.

-CREATE CONTAINER REQUEST command

This signed command may be invoked 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 mountain village). If the command is invoked 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 (e.g., RPMC flash container state 208) indicating that the container was created, 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 the subsequent CREATE_ CONTAINER _REQUEST command.

In one example, the CREATE CONTAINER REQUEST command may result in the creation of two identical signed owner containers 302 (e.g., a master container and a rollback container). These signed containers may be stored in non-volatile memory 173 (e.g., SPI flash). In one example, if the boot code verifies that two signed containers were successfully saved in non-volatile memory 173, the boot code will set an OTP bit indicating that the container was created.

In one example, the boot code 140 may use command parameters for the CREATE CONTAINER REQUEST command stored in the boot code mailbox 784. The command parameters may include an owner created public key (OCKpub), a command signature signed with an owner created private key (OCKpriv), and other command parameters corresponding to regions 433-434 and 437-440 (container header 310) in FIG. 4 and 501-502 and 505-515 (container content 311 b) in FIG. 6. The boot code 140 may use OCKpub to verify the command signature before creating the signed owner container 302. In one example, the boot code 140 may verify the command parameters OCKpub by calculating OCKpub a hash and comparing the hash to OCKpub hashes retrieved from the KHB stored in the non-volatile memory 173. (KHB stored in non-volatile memory 173 may be verified against KHB hash 507 in OTP memory 110. If OCKpub or verification of the command signature fails, boot code 140 may stop execution of the CREATE_ CONTAINER _REQUEST command without creating first owner container 302. In one example, boot code 140 may store the unsuccessful command state in firmware mailbox 786.

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

RPMC value 431 (and owner RPMC 503): may default to zero (as this is the first owner container). The boot code 140 may check whether any bits of the current RPMC value 202 in the OTP memory are set and if so, set these to the first valid non-zero value.

Active container version 432: may default to zero.

Device serial number 435: may be set to a value stored in OTP sequence number 205.

Owner transfer authorization key 504: may default to zero.

PUF activation code 621: the CREATE CONTAINER REQUEST command may default to zero when processed. The boot code 140 may generate a PUF activation code 621 and store the PUF activation code 621 in the signed owner container 302 after the next power cycle.

-INCREMENT_RPMC_REQUEST command

The signed command may be invoked to cause the boot code 140 to increment the RPMC value 431 of the primary owner container 302 (without changing the other container contents). If so, the boot code 140 may retrieve the master owner container 302, increment the RPMC value 431, and reset the active container version 432 back to zero. The boot code 140 may erase the primary container and the rollback container stored in the non-volatile memory 173 and store the updated owner container 302 in their locations. Once both containers are successfully updated, the boot code may increment the current RPMC value 202 in OTP memory 110, which may undo the previous container.

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

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

-Update_ CONTAINER _request command

This signed command may be invoked to cause the boot code 140 to update the selected container and increment the current RPMC value 202 in the OTP memory 110. In one example, the particular UPDATE performed may be determined by a subcommand parameter of the command parameter stored in the boot code mailbox 784 for the UPDATE_ CONTAINER _REQUEST command. In one example, the subcommand may include: (1) "Key revocation and rollback protection" and (2) "transfer ownership.

In one 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 an indication of which of the public signature keys (CCKpub or OTAKpub), OTAKpub, or CCK0-CCK3 (the hash in the current owner container header 310 field 436) was used for verification, and the command signature signed with the private key OTAKpriv or CCKpriv. The boot code 140 may use OTAKpub or CCKpub (whichever is indicated for use) to verify the command signature before updating the owner container 302. In one example, the boot code 140 may verify the command parameters CCKpub by calculating a hash of the command parameters CCKpub and comparing it to the corresponding CCKpub hashes (CCK 0-CCK 3) stored in the current owner container header 310. (the information in the current owner container header 310 may be trusted because the owner container 302 may be verified by the boot code 140. In another example, the boot code 140 may verify the command parameter OTAKpub by comparing the command parameter OTAKpub with the owner transfer authorization key 504 stored in the current owner container content 311 b. If verification of (1) the selected OTAKpub or CCKpub key or (2) the command signature fails, the boot code 140 may stop execution of the UPDATE_ CONTAINER _REQUEST command without modifying the current owner container 302 or incrementing the current RPMC value 202 in the OTP memory 110. In one example, the boot code 140 may store an unsuccessful command state in the firmware mailbox 786.

If (1) verification of both the selected OTAKpub or CCKpub key and the command signature is successful and (2) the subcommand is "transfer ownership," the boot code 104 may update the signed owner container 302. In one example, the boot code 140 may save command parameters (e.g., 784 in the boot code mailbox) corresponding to the regions 433-434 and 437-440 (container header 310) in FIG. 4 and 501-502 and 505-515 (container content 311 b) in FIG. 6 into the corresponding region in the container header 310 and the updated container content 311b of the signed owner container 302. The boot code 140 may use the following default values for the updated signed owner container 302:

RPMC value 431 (owner RPMC 503): { current RPMC value 202+1}, may be used.

Active container version 432: may default to zero.

Owner transfer authorization key 504: may default to zero.

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 master and rollback owner containers 302 are successfully written to the non-volatile memory 173, the boot code 104 may increment the current RPMC value 202 in the OTP memory 110. In one example, boot code 140 may store the successful command status in firmware mailbox 786.

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

-REPAIR_ FALLBACK _ CONTAINER _REQUEST command

The signature command may be invoked to cause the boot code 140 to update the rollback container to match the master container. If the master container is valid and the fallback container does not match the master container, the boot code 140 may erase the fallback container and copy the master container to the fallback container location. In one 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 public signature keys (CCKpub or OTAKpub), OTAKpub, or CCK0-CCK3 (the hash in the current owner container header 310 field 436) was used for verification, and the command signature signed with the private key OTAKpriv or CCKpriv. The boot code may use the same mechanism disclosed for update_ CONTAINER _request (above) to verify the signature public key and command signature for the REPAIR_ FALLBACK _ CONTAINER _request command. In one example, if verification is successful and no error is detected when updating the rollback container, the matching master container and rollback container may be stored in non-volatile memory 173 (e.g., SPI flash), and boot code 140 may store the successful command status in firmware mailbox 786. If the verification fails or an error is detected, there may be no change (e.g., the master container remains valid in the non-volatile memory 173 and the rollback container remains invalid). In the latter example, boot code 140 may store the unsuccessful command state in firmware mailbox 786.

-CRISIS _RECTORY_REQUEST command

The signed command may be invoked to cause the boot code 140 to recover from the primary container and the rollback container being invalidated. In one example, the command may be serviced when both containers are invalid. Boot code 140 may allow an OWNER to recover a saved copy of the work OWNER container using crisis commands (e.g., restore_owner_ CONTAINER) issued via I/O port control 190 (e.g., I2C crisis port, UART crisis port).

-Enable_ UNRESTRICTED _ TRANSFERS command

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

Update owner configuration 501 (fig. 5) so that both the current silicon owner and the new owner can transfer ownership of electronic device 101.

Provide owner transfer authorization key 504.

Increment active container version 432 (fig. 4).

Re-sign the owner container 302.

In one 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 OTAKpub public key (e.g., for the vendor transfer authorization key 504), signature public key (CCKpub), an indication of which of CCK0-CCK3 corresponds to (hashes in the current vendor container header 310 field 436), and a command signature signed with the container command private key (CCKpriv). The boot code 140 may use CCKpub to verify the command signature before updating the owner container 302. In one example, the boot code 140 may verify the command parameters CCKpub by calculating a hash of the command parameters CCKpub and comparing it to the corresponding CCKpub hashes (CCK 0-CCK 3) stored in the current owner container header 310. (the information in the current owner container header 310 may be trusted because the owner container 302 may be verified by the boot code 140. If CCKpub or verification of the command signature fails, the boot code 140 may stop execution of the ENABLE UNRESTRICTED TRANSFERS command without updating the owner container 302. In one example, the boot code 140 may store the unsuccessful command status in the firmware mailbox 786.

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

-Update_otak_key command

Provide owner transfer authorization key 504.

Increment active container version 432 (fig. 4).

Re-sign the owner container 302.

The signed command may allow an intermediate entity with OTAKpriv private keys to cause the update. In one 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 (e.g., unrestricted transfer has been enabled).

In one example, the boot code 140 may store 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 the provisioning owner transfer authorization key 504), a signature public key (CCKpub or OTAKpub), an indication of which of OTAKpub or CCK0-CCK3 (hashes in the current owner container header 310 area 436) to use for verification, and a command signature signed with private key OTAKpriv or CCKpriv. The boot code 140 may use OTAKpub or CCKpub (whichever is indicated for use) to verify the command signature before updating the owner container 302. In one example, the boot code 140 may verify the command parameters CCKpub by calculating a hash of the command parameters CCKpub and comparing it to the corresponding CCKpub hashes (CCK 0-CCK 3) stored in the current owner container header 310. (the information in the current owner container header 310 may be trusted because the owner container 302 may be verified by the boot code 140. In another example, the boot code 140 may verify the command parameter OTAKpub by comparing the command parameter OTAKpub with the owner transfer authorization KEY 504 stored in the current owner container content 311 b. If verification of (1) the selected OTAKpub or CCKpub KEY or (2) the command signature fails, the boot code 140 may stop execution of the UPDATE_OTAK_KEY command without modifying the current owner container 302. In one example, the boot code 140 may store an unsuccessful command state in the firmware mailbox 786.

Ownership of electronic devices

The electronic device 101 may have one or more owners during its lifetime and each owner may customize the images that are allowed to run on the machine. In one example, the OEM may be a first implicit owner ("no owner" state) and the OEM's configuration may be stored in OTP memory 110. The OEM may enable the portion to support ownership transfer by establishing a first owner container.

Establishing ownership

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

The RPMC owner container 302 may be created by the OEM using the CREATE_ CONTAINER _REQUEST command. The OEM may choose to use an OTP memory configuration (e.g., fig. 5) or an owner container configuration (OTP emulation) (e.g., fig. 6).

OEM owner container 302 may be created from reliable firmware loaded from non-volatile memory 173 (e.g., SPI flash) or via code loaded into volatile memory 172 (e.g., SRAM) via I/O port control 190 (e.g., 12C crisis port, UART crisis port). Firmware may store the CREATE CONTAINER REQUEST command into the boot code mailbox 784 (fig. 7), set the RPMC container command 782 to indicate a pending REQUEST, and assert a reset (e.g., a soft reset).

Fig. 8 shows a block diagram that includes an example of managing ownership of the electronic device 101 by creating a first owner container using OEM signature mirroring and OTP configuration. The contents of the non-volatile memory 873 (e.g., SPI flash) are shown at time t0 and include: OTP TAG0/1 mirror header base address, OTP KHB (Primary and Back off), OTP TAG0/1 mirror header and mirror (e.g., FMB). At time t0, there may be no owner of the electronic device 101, although the OEM may be an implicit owner. In one example, at time t1, the OEM application code may write 873 the owner container 0/1 base address into non-volatile memory. At time t2, the OEM application code may store the CREATE_ CONTAINER _REQUEST command to the RPMC container command area in command memory 871, and may store the container parameters of the new owner (owner A) in the boot code mailbox in command memory 871. In one example, parameters corresponding to the owner configuration parameters 501 may specify an 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 notify the pending CREATE CONTAINER REQUEST command (e.g., in the command memory 871) and process the command. At time t4, if the command is successful, the boot code 140 may write the owner A container 0/1 (the master container and the rollback container) to the nonvolatile memory 873. As shown, after time t4, electronic device 101 may be owned by owner a using OTP mirroring. In one example, after time t4, the OEM application may read a command status bit (fig. 7) from firmware mailbox 786 to verify 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 content. In one example, the OEM application may optionally save a copy of the owner A container 0/1 as a backup.

Fig. 9 shows a block diagram that includes an example of managing ownership of the electronic device 101 by creating a first owner container using OEM signature mirroring and OTP emulation configuration. The contents of non-volatile memory 973 (e.g., SPI flash) are shown at time t0 and include: OTP TAG0/1 mirror header base address, OTP KHB (Primary and Back off), OTP TAG0/1 mirror+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 one example, at time t1, the OEM application code may write (1) the owner container 0/1 base address, (2) the owner A KHB (primary and fallback), and (3) the owner ATAG0/1 mirror + header (e.g., FMB) into the non-volatile memory 973. At time t2, the OEM application code may store the CREATE_ CONTAINER _REQUEST command to the RPMC container command area in command memory 971, and may store the container parameters of the new owner (owner A) in the boot code mailbox in command memory 971. In one example, parameters corresponding to the 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 notify of the 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 (the master container and the rollback container) to the nonvolatile memory 973 and begin executing the owner A image (e.g., TAG0 image). As shown, after time t4, electronic device 101 may be owned by owner a using the owner a image. In one example, after time t4, the owner A application may read a command status bit (FIG. 7) from the firmware mailbox 786 to verify successful completion of the command. The owner A application may optionally read owner A container 0/1 from non-volatile memory 973 and verify the content. In one example, the owner A application may optionally save a copy of owner A container 0/1 as a backup.

Boot sequence for an electronic device with an RPMC owner container

Fig. 10 illustrates a flow chart of an example method 1000 for managing ownership of an electronic device over time, including secure transfer of ownership of the electronic device. According to one example, the method 1000 may begin at block 1005. In particular, method 1000 may be performed by boot code 140. In some examples, start block 1005 may represent a time at which electronic device 101 is first Powered On (POR) or a time after an electronic device reset (e.g., device reset, reboot, or power cycle). Thus, method 1000 may be performed by boot code 140 at a time when OTP memory 110 is not accessible to the user (e.g., because the user code has not yet been loaded). The teachings of the present disclosure may be implemented in a variety of configurations of system 100. Thus, the initialization point of the method 1000 and the order of 1005-1045 constituting the method 1000 may depend on the particular implementation chosen.

After a 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, supply the OEM configuration to the electronic device 101, and then proceed to block 1020 and reset the electronic device 101.

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 the owner feature is enabled in the OTP memory 110. In one example, this feature may be disabled by default (i.e., at the time of manufacture). If the owner feature is not enabled, the boot code may proceed to block 1040 where it may load the firmware binary image using the OEM information stored in OTP memory 110. At block 1040, the OEM may be an implicit owner of the electronic device 101, as only the OEM signed firmware may be loaded and executed (also referred to as "legacy secure booting"). In one example, the OEM may enable the owner feature by issuing a CREATE_ CONTAINER _REQUEST command (e.g., shown in FIGS. 8 and 9). If the boot code determines at block 1025 that the owner feature is enabled in the OTP memory 110, the boot code may proceed to block 1035 where it may determine whether the FMB image configuration source is OTP emulation. If the FMB image configuration source is not OTP emulation, the image configuration source may be OTP memory. In this example, the boot code may proceed to block 1040 for conventional secure booting. If the boot code determines at block 1035 that the FMB configuration image source is an OTP emulation, the boot code may proceed to block 1045 where it may attempt to load the firmware using RPMC owner container information stored in non-volatile memory 173 (e.g., SPI flash). In one example, block 1045 may represent a secure boot process using an RPMC owner container stored in non-volatile memory 173.

Although fig. 10 discloses a particular number of operations related to method 1000, method 1000 may be performed with more or fewer operations than those depicted in fig. 10. Further, although FIG. 10 discloses a certain order of operations to be performed with respect to method 1000, operations comprising method 1000 may be performed in any suitable order.

Transferring ownership of an electronic device

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

In one example, the owner may choose to use an RPMC owner container 302 with an OTP configuration (using OEM mirroring) (e.g., fig. 5) or an owner-defined configuration (using owner mirroring) (e.g., fig. 6). The new owner container 302 may be created by reliable firmware loaded from non-volatile memory 173 (e.g., SPI flash) or by executing update_ CONTAINER _request commands via I/O port control 190 (e.g., I2C crisis port, UART crisis port). According to one example, the enable_ UNRESTRICTED _ TRANSFERS command may be supported when the current owner ENABLEs unrestricted transfer of ownership by executing the command.

In some examples, there may be three types of ownership transfers:

The current owner performs the transfer to the new owner.

The trusted intermediary performs a transfer to the new owner (unrestricted transfer).

The current owner enables the new owner to claim ownership (unrestricted transfer).

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

An Owner Transfer Authorization Key (OTAK) may support one-time ownership transfer to a new owner while avoiding providing the current owner with information of the new owner. With an OTAK transfer (which may be referred to as an "unlimited transfer"), a new owner can upload his information and complete ownership transfer whenever the current owner enables the OTAK transfer. The OTAK ownership transfer may be accomplished in the event that the new owner may or may not exist when the current owner surrendered the machine.

Fig. 11 and 12 show block diagrams of two examples of managing ownership of the electronic device 101 using unlimited transfer and OTAK. As shown in fig. 11, the Current Owner (CO) may want to transfer ownership of machine a to the New Owner (NO). In one 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 one example, the following events (1-8) may occur during a transfer.

The 1-CO may send the machine A sequence number (if NO is known) to the TIE and NO. TIE and NO may use the sequence number to confirm that they received the correct device (e.g.,

Machine a).

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

The 3-CO may run the ENABLE UNRESTRICTED TRANSFERS command to pass the OTAKpub1 key as the new OTAK public key for machine a.

The 4-CO may send machine A to the TIE.

The 5-NO may send OTAKpub a2 keys to the TIE. OTAKpub2 the key may be the public key of a public/private key pair owned by the NO.

The 6-TIE may run an update_otak_key command, passing OTAKpub the 2 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 its OTAKpriv private KEY. The TIE may use the I/O port control 190 (e.g., I2C crisis port, UART crisis port) to insert the update_otak_key command into the command memory 171 (e.g., fig. 7).

The 7-TIE may send machine A to NO.

8-NO can run UPDATE_ CONTAINER _REQUEST using the "transfer ownership" subcommand. Because update_ CONTAINER _request is a signed command, NO can sign the command with the NO's OTAKpriv private key. NO may use the I/O port control 190 (e.g., I2C crisis port, UART crisis port) to insert the update_ CONTAINER _request command into the command memory 171 (e.g., fig. 7).

Although fig. 11 discloses a particular number of events associated with unlimited ownership transfer, this type of transfer may be performed with more or fewer events than depicted in fig. 11. For example, the CO may not send a sequence number to either or both of the TIE and NO. Additionally, although FIG. 11 discloses a particular sequence of events, the events may be completed in any suitable order.

As shown in fig. 12, the Current Owner (CO) may want to transfer ownership of machine B to the New Owner (NO). In one example, the transfer may use an Untrusted Intermediate Entity (UIE) to assist in transferring ownership to the new owner. In one example, the following events (1-6) may occur during a transfer.

The 1-CO may send the machine B sequence number to the NO. NO may use the serial number to confirm that it received the correct device (e.g., machine B).

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

The 3-CO may run the ENABLE UNRESTRICTED TRANSFERS command to pass OTAKpub the key as the new OTAK public key for machine B.

The 4-CO may send machine B to UIE. Note that because UIE cannot access OTAKpriv, UIE may not assume ownership or run commands on machine B.

The 5-UIE may forward machine B to NO (as is).

The 6-NO may run the UPDATE_ CONTAINER _REQUEST using the "transfer ownership" subcommand. Because update_ CONTAINER _request is a signed command, NO can sign the command with NO's OTAKpriv private key. NO may use the I/O port control 190 (e.g., I2C crisis port, UART crisis port) to insert the update_ CONTAINER _request command into the command memory 171 (e.g., fig. 7).

Although fig. 12 discloses a particular number of events associated with unlimited ownership transfer, this type of transfer may be performed with more or fewer events than depicted in fig. 12. For example, the CO may not send a sequence number to the NO. In another example, the CO may send machine B directly to the NO without the need for an intermediate entity. Additionally, although FIG. 12 discloses a particular sequence of events, the events may be completed in any suitable order.

As shown in fig. 11 and 12, if an intermediate entity is required and the end-owners are unknown, each temporary owner may have their own OTAK keys. If an intermediate entity is required and the terminal owner is known, the terminal owner may provide their OTAK public key to prevent the intermediate entity from owning or changing the OTAK key. The current owner may retain ownership until the owner transfer is complete. This allows the current owner to deal with any problems that occur during ownership transfer.

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

direct ownership transfer using the current owner's CCK key and FMB configuration=otp (fig. 13).

Direct ownership transfer emulation using the current owner's CCK key and FMB configuration = OTP.

Direct ownership transfer using the new owner's OTAK key and FMB configuration = OTP.

Direct ownership transfer using the new owner's OTAK key and FMB configuration = OTP emulation.

Indirect ownership transfer using intermediate entity, OTAK key and FMB configuration = OTP.

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

In examples where the ownership transfer command is successful, the new owner may load and execute the code via the I/O port control 190 (e.g., crisis port). The loaded code may be used to update the SPI flash image.

Transfer procedure using CCK key

Fig. 13 shows a block diagram including an example of managing ownership 101 of an electronic device by transferring ownership using a CCK key of a current owner and FMB configuration=otp. The contents of the non-volatile memory 1373 (e.g., SPI flash) are shown at time t0 and include: OTP TAG0/1 mirror header base address, OTP KHB (master and fallback), OTP TAG0/1 mirror header and mirror (e.g., FMB), owner container 0/1 base address, and owner A container 0/1. At time t0, owner A may be the owner of electronic device 101. The new owner may provide its owner configuration parameters to the current owner and the current owner may sign the 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 one example, the signed parameter may then be used by the new owner or the current owner to perform ownership transfer. At time t1, a soft system reset of electronic device 101 may cause it to enter a crisis recovery mode. At time t2, the new owner or the old owner may issue a signed UPDATE_ CONTAINER _REQUEST command using a crisis port (e.g., I2C, UART). At time t3, if the command is successful, boot code 140 may write owner B container 0/1 (primary container and rollback container) to non-volatile memory 1373. As shown, after time t3, electronic device 101 may be owned by owner B using the OEM OTP image.

Fig. 13 shows transfer of ownership using the CCK key of the current owner and FMB configuration = OTP. The process may be similar when FMB configuration = OTP emulation. For OTP emulation, after issuing 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 (fig. 1)). Upon successful loading (t 3), boot code 140 may write owner B container 0/1 (primary container and rollback container) to nonvolatile memory 1373 and jump into the new owner's loader code. The new owner's loader code may then write the signed image and KHB (primary and rollback) to non-volatile memory 1373 (e.g., SPI flash).

Thus, a general procedure for ownership transfer using a CCK key may include:

the new owner may provide its owner configuration parameters to the current owner.

The current owner can transfer ownership command parameters for the new owner signature.

The (optional) current owner may enable crisis mode for restricted signatures.

The (optional) current owner can erase their mirror and KHB (if applicable).

The electronic device may be powered down and physically transferred to a new owner or trusted intermediate entity.

The new owner may issue a transfer ownership command using the crisis port.

New owners can use crisis ports to load new owners' loader code images and KHB (for OTP emulation), which will sign images and KHB (Primary and Back-off)

Written to a non-volatile memory.

Transfer procedure using OTAK keys

Examples of transfer of ownership using an OTAK key are discussed above with respect to fig. 11 and 12. The general procedure of ownership transfer using an OTAK key may include:

The new owner or trusted intermediary may generate a public/private ECDSA-384 key pair.

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

The current owner may store this public key value to the OTAK key in the owner container and use the ENABLE UNRESTRICTED TRANSFERS command to ENABLE unrestricted ownership transfer.

The current owner (optional) can write the new owner image and KHB to flash.

The (optional) current owner may erase their mirror and KHB.

The machine may be powered and physically transferred to the new owner or trusted entity.

If a trusted intermediate entity is used, then the intermediate entity's OTAK KEY is used to execute (via crisis port) the UPDATE_OTAK_KEY command or UPDATE_ CONTAINER _REQUEST command (using the "transfer ownership" subcommand).

New owners may execute (via crisis ports)

The UPDATE _ CONTAINER _ REQUEST command has (transfer ownership is used) "

Subcommand).

Written to a non-volatile memory.

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

Positioning owner container

In one example, boot code 140 may be assigned by default to the first 16 bytes in the SPI flash of component 0 for booting the ROM address pointer table. The 16-byte address pointer table may be repositionable. The table may be used to locate the owner image and may be remapped in the OTP memory. The locations of the primary RPMC owner container base address and the rollback RPMC owner container base address are stored in the last 8 bytes of the address pointer table.

RPMC values in OTP memory and owner container

In one example, the current RPMC value 202 in OTP memory 110 may match the RPMC value 431 in the container header 310 of the current owner container 302. During an UPDATE (e.g., update_ CONTAINER COMMAND request), the RPMC value 431 in the container header 310 may increment by 1, 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.

Ownership transfer method

Fig. 14 illustrates a flow chart of an example method 1400 for managing ownership of an electronic device over time, including secure transfer of ownership of the electronic device. 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 system 100. Thus, the point of initialization of method 1400 and the order of 1410-1430 constituting method 1400 may depend on the particular implementation chosen.

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

Although fig. 14 discloses a particular number of operations related to method 1400, method 1400 may be performed with more or less operations than those depicted in fig. 14. For example, the method 1400 may also use the public key to authenticate the first create owner container request. In another example, after block 1430, the method 1400 may continue with additional operations illustrated in fig. 15. Further, although FIG. 14 discloses a certain order of operations to be performed with respect to method 1400, operations comprising method 1400 may be performed in any suitable order.

Fig. 15 illustrates a flow chart of an example method 1500 for managing ownership of an electronic device over time, including secure transfer of ownership of the electronic device. 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 system 100. Thus, the initialization point of the method 1500 and the order of 1510-1555 constituting the method 1500 may depend on the particular implementation selected.

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

Although fig. 15 discloses a particular number of operations related to method 1500, method 1500 may be performed with more or fewer operations than those depicted in fig. 15. Further, although FIG. 15 discloses a certain order of operations to be performed with respect to method 1500, operations comprising method 1500 may be performed in any suitable order.

Methods 1000, 1400, and 1500 may be implemented using system 100 or any other system operable to try out methods 1000, 1400, and 1500. Although examples have been described above, other modifications and examples can be made in accordance with this disclosure without departing from the spirit and scope of these disclosed examples.

Claims

1. A system, the system comprising:

An electronic device, the electronic device having:

One Time Programmable (OTP) memory;

A boot code;

A volatile memory; and

Nonvolatile memory

The boot code is executable by the processor to:

authenticating a code associated with an implicit owner of the electronic device using information stored in OTP memory;

receiving a first create owner container request from an authenticated code associated with an implicit owner of the electronic device;

creating a first owner container for a first owner of the electronic device in response to the first create owner container request, the first owner container including a first signed data image associated with the first owner of the electronic device;

Storing the first owner container in the non-volatile memory; and

Authenticating a first executable code associated with a first owner of the electronic device using the first signed data image associated with the first owner of the electronic device.

2. The system of claim 1, wherein the boot code comprises an immutable code stored in read-only memory.

3. The system of claim 1, wherein the boot code comprises an authentication code stored in the non-volatile memory or an authentication code stored in the volatile memory.

4. A system according to any one of claims 1-3, wherein:

The first signed data image associated with the first owner of the electronic device includes configuration information and secret information; and

Boot code executable by the processor to authenticate the first executable code associated with the first owner of the electronic device using the first signed data image associated with the first owner of the electronic device includes the boot code executable by the processor to authenticate the first executable code associated with the first owner of the electronic device using the configuration information and secret information.

5. The system of any one of claims 1-4, wherein:

the first create owner container request comprises a signed request; and

The boot code is executable by the processor to authenticate the first create owner container request using a public key.

6. The system of any of claims 1-5, wherein the first owner container comprises:

A container header;

container content including owner configuration information associated with the first owner of the electronic device and an owner transfer authorization key; and

Container signature.

7. The system of claim 6, wherein the container header comprises a Replay Protection Monotonic Counter (RPMC).

8. The system of any of claims 1-7, wherein the boot code executable by the processor to store the first owner container in the non-volatile memory comprises the boot code executable by the processor to store two copies of the first owner container in the non-volatile memory.

9. The system of claim 8, wherein the boot code is executable by the processor to provide an indication that ownership is established in response to an acknowledgement that the two copies of the first owner container were successfully stored in the non-volatile memory.

10. The system of any of claims 1-9, wherein the non-volatile memory comprises a Serial Peripheral Interface (SPI) flash memory or an electrically erasable programmable read-only memory (EEPROM).

11. The system according to any one of claims 1-10, the system comprising:

the boot code is executable by the processor to perform ownership transfer from the first owner of the electronic device to a second owner of the electronic device, the boot code comprising boot code executable by the processor to:

Authenticating the signed ownership transfer command using the key stored in the first owner container;

Responsive to successful authentication of the signed ownership transfer command, creating a second owner container comprising a second signed data image associated with a second owner of the electronic device;

Storing the second owner container in the non-volatile memory;

Revocation of the first owner container; and

Authenticating a second executable code associated with a second owner of the electronic device using the second signed data image associated with the second owner of the electronic device.

12. The system of claim 11, wherein revoking the first owner container comprises programming bits in the OTP memory corresponding to the second owner container.

13. A method, the method comprising:

For an electronic device having a one-time programmable (OTP) memory and a non-volatile memory, using information stored in the OTP memory to authenticate code associated with an implicit owner of the electronic device;

in response to the first create owner container request, create a first owner container comprising a first signed data image associated with a first owner of the electronic device;

Storing the first owner container in the non-volatile memory; and

Authenticating a first executable code associated with the first owner of the electronic device using the first signed data image associated with the first owner of the electronic device.

14. The method according to claim 13, the method comprising:

Authenticating the signed ownership transfer command using a key stored in said first owner container;

In response to successful authentication of the signed ownership transfer command, creating a second owner container for a second owner of the electronic device, the second owner container comprising a second signed data image associated with the second owner of the electronic device;

Storing the second owner container in the non-volatile memory;

Revocation of the first owner container; and

Authenticating a second executable code associated with the second owner of the electronic device using the second signed data image associated with the second owner of the electronic device.

15. The method of claim 14, wherein revoking the first owner container comprises programming bits in the OTP memory corresponding to the second owner container.

16. The method according to any one of claims 13-15, the method comprising:

the first create owner container request is authenticated using a public key.

17. The method of any of claims 13-16, wherein authenticating the first executable code associated with the first owner of the electronic device using the first signed data image associated with the first owner of the electronic device includes authenticating the first executable code associated with the first owner of the electronic device using configuration information and secret information from signed data images associated with the first owner of the electronic device.

18. A system, the system comprising:

An electronic device, the electronic device having:

a one-time programmable (OTP) memory including configuration information corresponding to an implicit owner of the electronic device;

An immutable boot code stored in the read-only memory; and

Nonvolatile memory

The immutable boot code is executable by the processor to:

determining whether a first owner container exists in the non-volatile memory;

in response to determining that the first owner container is not present in the non-volatile memory:

disabling loading of executable code that cannot be authenticated using configuration information corresponding to the implicit owner of the electronic device;

Authenticating a first executable code associated with the implicit owner of the electronic device using configuration information corresponding to the implicit owner of the electronic device;

loading authenticated first executable code associated with the implicit owner of the electronic device;

Receiving a first create owner container request from authenticated executable code associated with the implicit owner of the electronic device;

creating the 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; and

Storing the first owner container in the non-volatile memory; and

In response to determining that the first owner container exists in the non-volatile memory:

Disabling loading of executable code that cannot be authenticated using the first signed data image associated with the first owner of the electronic device;

authenticating a first executable code associated with the first owner of the electronic device using the first signed data image associated with the first owner of the electronic device; and

The authenticated first executable code associated with the first owner of the electronic device is loaded.

19. The system of claim 18, wherein:

the first signed data image associated with a first owner of the electronic device includes configuration information and secret information; and

The immutable boot code executable by the processor to authenticate the first executable code associated with the first owner of the electronic device includes the immutable boot code executable by the processor to authenticate the first executable code associated with the first owner of the electronic device using the configuration information and secret information.

20. The system of any of claims 18-19, wherein, in response to determining that the first owner container is present in the non-volatile memory, the immutable boot code is executable by the processor to perform an ownership transfer process from the first owner of the electronic device to a second owner of the electronic device, comprising the immutable boot code executable by the processor to:

In response to successful authentication of the signed ownership transfer command, creating a second owner container for the second owner of the electronic device, the second owner container comprising a second signed data image associated with the second owner of the electronic device;

Storing the second owner container in the non-volatile memory; and

The first owner container is revoked.

21. The system of claim 20, wherein the immutable boot code is executable by the processor to determine whether the second owner container is present in the non-volatile memory, and in response to determining that the second owner container is present in the non-volatile memory:

Disabling loading of executable code that cannot be authenticated using the second signed data image associated with the second owner of the electronic device;

Authenticating a second executable code associated with a second owner of the electronic device using the second signed data image associated with the second owner of the electronic device; and

Loading authenticated second executable code associated with the second owner of the electronic device.

22. The system of any of claims 18-21, wherein:

The OTP memory includes a current container Replay Protection Monotonic Counter (RPMC) field;

The first signed data image associated with a first owner of the electronic device includes a container header RPMC field; and

The immutable boot code executable by the processor to authenticate the first executable code associated with the first owner of the electronic device includes the immutable boot code executable by the processor to authenticate the first executable code associated with the first owner of the electronic device by ensuring that the current container RPMC field and the container header RPMC field both have the same value.