Secure device status apparatus and method

Abstract

The present invention relates to secure device state apparatus and methods. A semiconductor chip device is disclosed that includes device state fuses that can be used to configure various device states and corresponding security levels for the semiconductor chip as it transitions from wafer fabrication to supply. The device states and security levels prevent access and exploitation of the semiconductor chip, for example, during manufacturing testing. A secure boot process for a semiconductor chip during its lifecycle is also disclosed. The secure boot process can begin at the wafer fabrication stage and continue through the insertion of keys and firmware.

Description

[0001] Description of the case

[0002] This application is a divisional application of Chinese invention patent application No. 201710790343.6, filed on September 5, 2017. Technical Field

[0003] The subject matter described herein relates generally to the field of semiconductor chip manufacturing and includes security measures throughout the semiconductor chip lifecycle and for a secure boot process. Background Art

[0004] In semiconductor chip manufacturing, semiconductor chips may be formed together into a wafer and tested as part of the wafer. The wafer may then be sliced ​​into individual chips / devices, where the individual chips / devices are further tested before being incorporated into products and then released. In some instances, it may be useful to resupply chip devices for alternative applications during or after manufacturing.

[0005] One-time programmable non-volatile memory technology is already widely used in semiconductor chip manufacturing. Examples of this type of one-time programmable non-volatile memory technology include fuses, such as electric fuses, antifuses, or laser fuses. These fuses can be used to change the configuration and adjust the performance of semiconductor chips after they are manufactured. Fuses can also be used to store chip IDs and cryptographic keys.

[0006] E-fuse technology includes one-time programmable non-volatile memory technology, wherein the e-fuse bit(s) can only be set to 1 once, while the unprogrammed bit(s) can have a value of zero. Available e-fuse technology uses electrically programmable PMOS gate oxide antifuses, wherein read operations require only core IC power, while programming can be performed using an external power supply.

[0007] The e-fuses may be arranged as independent fuse macros, where each macro may have a certain capacity, for example, ranging from 64 bits to 1 kilobit in 64-bit increments. Summary of the Invention

[0008] In order to provide a basic understanding of some aspects of the present disclosure, this summary introduces a selection of concepts in simplified form. This summary is not an extensive overview of the present disclosure and is neither intended to identify the key or important elements of the present disclosure nor to delineate the scope of the present disclosure. This summary merely presents some of the concepts of the present disclosure as a preface to the specific embodiments provided below.

[0009] The present disclosure generally relates to semiconductor chip devices. More particularly, various aspects of the present disclosure relate to protecting a semiconductor chip device throughout its lifecycle and protecting boot flow operations.

[0010] One aspect includes a method for protecting a semiconductor chip device having multiple device state fuses, the method comprising: changing an original device bit pattern stored in the device state fuses to a test mode enable bit pattern to change the device state from the original device state to a test mode enable device state, wherein the test mode enable device state allows manufacturing tests to be performed on the semiconductor chip device; in response to the semiconductor chip device passing the manufacturing test, changing the test mode enable bit pattern to a test mode lock bit pattern to change the device state from the test mode enable device state to the test mode lock device state; and changing the security level of the semiconductor chip device based on the change in the device state.

[0011] An additional aspect relates to a method comprising: in response to changing the device state from an original device state to a test mode enabled device state, changing the original device state security level, in which the test mode and ports are not accessible from outside the chip, to a test mode enabled security level, in which manufacturing testing on the semiconductor chip device can be performed via one or more of the ports.

[0012] A further aspect includes a method comprising: in response to changing the device state from a test mode enabled device state to a test mode locked device state, changing a test mode enabled security level in which a test mode and a port are accessible from outside the chip to a test mode locked security level in which manufacturing testing on a semiconductor chip device is locked.

[0013] Still further aspects include a method comprising: in response to a semiconductor chip device failing a manufacturing test, changing a test mode enable bit pattern to a test mode disable bit pattern to change a device state from a test mode enabled device state to a test mode disabled device state; and in response to changing the device state from a test mode enabled device state to a test mode disabled device state, changing a security level from a test mode enabled security level in which test modes and ports accessible from outside the chip are to a test mode disabled security level in which manufacturing tests and ports on the semiconductor chip device are disabled.

[0014] Yet further aspects include a method comprising: in response to changing a device status fuse to a bit pattern that does not match a known bit pattern corresponding to a known pattern, modifying the bit pattern in the device status fuse to a disabled mode bit pattern, and changing the security level to a disabled security level in which all ports and memories in the semiconductor chip device are disabled.

[0015] In a still further aspect, the semiconductor chip device further includes a boot loader process, and the method further includes: in response to the boot loader process verifying that the chip device has received a correct unlock password together with the unlock request, changing the security level to unlock the chip device by allowing the value of the device status fuse to be changed to a test mode enable mode.

[0016] Additional aspects include a semiconductor chip device comprising: a device state fuse storing a bit pattern indicating a device state of the semiconductor chip device; a processor operably connected to the device state fuse; a storage device storing instructions that, when executed by the processor, cause the processor to: change an original device bit pattern stored in the device state fuse to a test mode enable bit pattern to change the device state from the original device state to a test mode enable device state, wherein the test mode enable device state allows manufacturing tests to be performed on the semiconductor chip device; in response to the semiconductor chip device passing the manufacturing test, change the test mode enable bit pattern to a test mode lock bit pattern to change the device state from the test mode enable device state to the test mode lock device state; and change the security level of the semiconductor chip device based on the change in the device state.

[0017] Other aspects include a semiconductor chip device, further comprising: one or more ports; the storage device storing further instructions, which, when executed by the processor, causes the processor to: in response to changing the device state from an original device state to a test mode enabled device state, change the original device state security level in which the test mode and port are not accessible from outside the chip to a test mode enabled security level in which manufacturing testing on the semiconductor chip device can be performed via one or more of the ports.

[0018] Another aspect includes a semiconductor chip device, further comprising: one or more ports; the storage device storing further instructions, which, when executed by the processor, causes the processor to: in response to changing the device state from a test mode enabled device state to a test mode locked device state, change the test mode enabled security level in which the test mode and port are accessible from outside the semiconductor chip device to a test mode locked security level in which manufacturing testing on the semiconductor chip device is locked.

[0019] Yet a further aspect includes a semiconductor chip device, further comprising: one or more ports; the storage device storing further instructions which, when executed by the processor, cause the processor to: in response to the semiconductor chip device failing a manufacturing test, change a test mode enable bit pattern to a test mode disable bit pattern to change the device state from a test mode enable device state to a test mode disable device state; and in response to changing the device state from a test mode enable device state to a test mode disable device state, change the security level from a test mode enable security level in which the test mode and port are accessible from outside the semiconductor chip device to a test mode disable security level in which manufacturing tests on the semiconductor chip device and the port are disabled.

[0020] Still further aspects include a semiconductor chip device, a storage device storing further instructions that, when executed by a processor, cause the processor to: in response to changing the device status fuse to a bit pattern that does not match a known bit pattern corresponding to a known pattern, modify the bit pattern in the device status fuse to a disabled mode bit pattern, and said changing the security level changes the security level to a disabled security level in which all ports and memories in the semiconductor chip device are disabled.

[0021] Still a further aspect includes a semiconductor chip device, which further includes: the storage device stores a boot loader process; the storage device stores further instructions, which, when executed by the processor, cause the processor to: in response to the boot loader process verifying that the chip device has received the correct unlock password together with the unlock request, change the security level by allowing the value of the device status fuse to be changed to a test mode disable mode to unlock the chip device.

[0022] Additional aspects include a method for provisioning a semiconductor chip device, comprising: verifying the authenticity of the boot processing code in response to a payload including the boot processing code written into the non-volatile memory of the semiconductor chip device; creating an initialization key; disabling external access to the initialization key and exporting a certificate for the initialization key, the external access being access to the memory of the semiconductor chip device via an input port; encrypting the initialization key by using a public key; exporting the encrypted initialization key; configuring the semiconductor chip device by programming the fuses of the semiconductor chip device; obtaining the provisioning key by using the initialization key; proving identity and decrypting provisioning data by using the provisioning key; and verifying that the provisioning data is valid.

[0023] In a further aspect, the non-volatile memory is flash memory.

[0024] In a still further aspect, wherein a public key used in encrypting the initialization key is maintained in the boot processing code.

[0025] In a still further aspect, the provisioning data includes application-specific flash firmware, the method further comprising the boot processing code enabling storage of the flash firmware in the flash memory.

[0026] In an even further aspect, the boot processing code is a boot loader.

[0027] Additional aspects include a semiconductor chip device comprising: a fuse; a non-volatile memory; an input port; a processor; a storage device storing instructions that, when executed by the processor, cause the processor to: verify the authenticity of the boot processing code in response to a payload including boot processing code being written to the non-volatile memory; create an initialization key; disable external access to the initialization key and export a certificate for the initialization key, wherein external access is access to the non-volatile memory of the semiconductor chip device via the input port; encrypt the initialization key by using a public key; export the encrypted initialization key; configure the semiconductor chip device by programming the fuse; obtain a supply key by using the initialization key; prove identity and decrypt supply data by using the supply key; and verify that the supply data is valid.

[0028] Further aspects include a semiconductor chip device wherein the nonvolatile memory is flash memory.

[0029] Still further aspects include a semiconductor chip device in which a public key used in encrypting an initialization key is retained in a boot processing code.

[0030] Yet further aspects include a semiconductor chip device wherein the provisioning data includes application specific flash firmware, the method further comprising the boot processing code enabling the flash firmware to be stored in the flash memory.

[0031] Even further aspects include a semiconductor chip device wherein the boot processing code is a boot loader.

[0032] It should be noted that some or all of the embodiments of the processor and storage system disclosed herein may also be configured to perform some or all of the method embodiments disclosed above. In addition, some or all of the embodiments of the method disclosed above may also be expressed as instructions embodied on a non-transitory processor-readable storage medium such as an optical or magnetic memory.

[0033] Further scope of applicability of the methods and systems of the present disclosure will become apparent from the detailed description given below. However, it should be understood that the detailed description and specific examples, while indicating embodiments of the methods and systems, are given by way of example only, as various changes and modifications within the spirit and scope of the concepts disclosed herein will become apparent to those skilled in the art from this detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] These and other objects, features and characteristics of the present disclosure will become apparent to those skilled in the art through a study of the following detailed description taken in conjunction with the appended claims and drawings.

[0035] Figure 1 is a block diagram of an example chip according to various aspects of the present invention;

[0036] Figure 2 is a block diagram of an example device status decoder according to various aspects of the present invention;

[0037] Figure 3 is a schematic diagram of a wafer test layer system according to various aspects of the present invention;

[0038] Figure 4 is a flow chart of a chip life cycle according to various aspects of the present invention;

[0039] Figure 5 is a flow chart of chip device status management according to various aspects of the present invention;

[0040] Figure 6A and Figure 6B is a flow chart of a chip life cycle of a wafer according to various aspects of the present invention;

[0041] Figure 7 is a schematic diagram of a package test layer system according to various aspects of the present invention;

[0042] Figure 8A 、 Figure 8B and Figure 8C is a flow chart of a chip life cycle for personalization and provisioning according to various aspects of the present invention;

[0043] Figure 9 is a block diagram of an example one-time programmable memory controller according to various aspects of the present invention; and

[0044] Figure 10 is a block diagram illustrating an example computing device implementing various aspects in accordance with one or more embodiments described herein.

[0045] The accompanying drawings depict embodiments of the disclosed invention for purposes of illustration only. One skilled in the art will recognize from the following discussion that alternative embodiments of the structures and methods described herein may be employed without departing from the principles of the invention described herein. DETAILED DESCRIPTION

[0046] The following description refers to the accompanying drawings. The same reference numerals may identify the same or similar elements in different drawings. The following description is not intended to limit the scope. Instead, the scope is defined by the appended claims.

[0047] Semiconductor chip devices—also referred to herein as chips—are susceptible to various forms of attack, both as part of a final product and during the manufacturing of the chip devices themselves. Attacks can be conducted on chip devices within a product to determine the chip device's internal configuration and functionality. One-time programmable memory technologies, such as fuses, are susceptible to attacks that include physical tampering, such as physically cutting a wire indicating a '0', causing it to become an open '1', or rewiring the fuse by depositing metal to convert an open '1' to a '0'.

[0048] Fuse sensing requires an electrical query of the fuse state. This type of fuse sensing can only be performed a certain number of times and has a lifecycle sensing limit defined by the manufacture of the electric fuse. In order to avoid too much fuse sensing, a "shadow copy" of the fuse can be created. Just after a reset, the fuse controller can sense the fuse value and write the result to a register that becomes a "shadow copy." Future queries of the state can only read the value of the shadow register instead of electrically sensing the fuse. If an attacker wants to modify the fuse value, the attacker can attack the physical electric fuse itself or the shadow register. However, if the fuse attack occurs after reset sensing, by confirming that the fuse and the shadow copy are the same value, the attacker needs to attack both the fuse and the shadow copy.

[0049] During manufacturing testing, security-sensitive test modes of chip devices can be accessed and exploited, allowing secret information to be extracted. Attacks can be carried out during chip manufacturing to change the configuration or operation of chip devices to achieve unintended uses. Chip devices that fail manufacturing testing may be discarded even if they are partially operational, thereby making the discarded devices vulnerable to attacks and exploitation. In the case of secure chip devices, such attacks can enable the extraction of secret information. Similarly, testing processes performed during manufacturing may leak information, such as information about internal operations, and such leaked information may compromise the configuration and provisioning processes. The provisioning payload provided during the provisioning process may be at risk of being altered. Likewise, information that may be leaked during the device provisioning process may include the process of creating device unique identifiers and secrets.

[0050] Aspects of the present invention provide solutions to these and other problems.

[0051] The life cycle of a chip device may include manufacturing testing of the chip devices included in a physical semiconductor wafer, dicing the wafer into individual chip devices, testing the sliced ​​chip devices, supplying, and re-supplying.

[0052] Various aspects of the present invention include security measures for physical semiconductor wafers and individual chip devices during the device lifecycle or portions of the device lifecycle. Various aspects of the present invention include a secure boot process performed during at least a portion of the device lifecycle. The secure boot process may include control by boot firmware in conjunction with certain testing and provisioning operations.

[0053] One aspect of the present invention is intrusion detection of each security chip due to tampering during its life cycle as each security chip moves from a blank, untested and untrusted portion on a wafer through the testing phase, slicing into individual chips, further testing, mass production, supply and re-supply life cycle phases.

[0054] One aspect of the present invention is a secure chip device in which intrusions attributed to tampering with a one-time programmable memory are detected during the lifecycle of the chip device. In response to detecting such tampering, the chip device can be caused to permanently disable access to and execution of internal functions of the chip device. The general term "fuse" may be used interchangeably with one-time programmable memory technology.

[0055] exist Figure 1 An example semiconductor chip device 100 is shown in FIG. The semiconductor chip device or chip device 100 includes multiple access ports. The access ports may include a debug port 101, one of which may be a serial wire debug (SWD) port that provides a path to a fuse 123. Other ports may also be included to provide access for testing, such as a flash test port 145 and a scan test port 147. The flash test port 145 has an associated flash test control 141. The scan test port 147 has an associated TAP / scan control 143.

[0056] The chip device 100 may be an SPI slave device, wherein commands and data may be transferred using an SPI personal identification code, SPI IN 149 and SPI OUT 151 with corresponding SPI slave control 135 and SPI master control 137 .

[0057] In an example embodiment, there may be a fuse 123 that acts as a bit storage device. As a non-limiting example, the fuse 123 may be a 27-bit storage device, but it is understood that the number of bits may vary depending on the application.

[0058] In an example embodiment, fuse 123 may be implemented as a set of redundant fuse shadow registers and fuse macros (see Figure 9 , which will be described later). Furthermore, the fuses may be implemented as a set of fuse macros.

[0059] In example embodiments, the fuses 123 may include a key fuse 125 , a device status fuse 127 , and a device ID fuse 129 .

[0060] The key fuse 125 can be used to store keys and other secrets. For example, the key fuse 125 can store secret data that serves as a key or is used to obtain a key. A specific example is the device initialization key (DIK), which can serve as a root shared secret between the device 100 and the key management server 307.

[0061] Device state fuses 127 store and define the device state. More specifically, device state fuses 127 may include a group or stack of fuses, wherein each group / stack of fuses defines an incremental state during manufacturing testing of the device.

[0062] The device ID fuse 129 stores a unique device ID of the semiconductor device 100 .

[0063] Fuse 123 may have an associated fuse controller and device state decoder 121. In an example embodiment, the device state may be retrieved using the device state decoder 121 based on a bit pattern stored in the device state fuse 127. Reading the device state fuse 127 may be accomplished directly or via a fuse shadow register (e.g., Figure 9 In addition, a comparison operation can also be performed between the device status fuse 127 value and the shadow fuse register value to ensure that the fuse 127 and / or register has not been attacked or tampered with. This comparison operation can also be performed when reading the key fuse 125 and / or the device ID fuse 129.

[0064] Figure 2is a block diagram of device state decoder 121. Device state decoder 121 may include logic function circuitry 203 that maps a bit pattern from device state fuse 127 as input to one of a plurality of device states as output based on an arbitrary function. In an example embodiment, device state decoder 121 may include logic function circuitry that maps a 27-bit pattern from a bit storage device as input 201 to one of five device states as output 205. In an example embodiment, the fifth state may be a disabled state 207 that is achieved due to a failure to achieve any of the other four states.

[0065] In an example embodiment, each of the five device state decoder output ports 205 can be redundantly encoded as 3 bits. In this example embodiment, the 27 raw device fuse bits are processed by the device state decoder 121, and the result is used to set the device state to one of the three physical states before being passed to the system. There may be a hardware decoder that reads the 27 bits and sends a signal (wire) to anyone who needs the value of the device state. The current state can be transmitted by simple signal transmission of the shared result.

[0066] Chip device 100 may include an embedded processor 103 and a memory 105 component including non-volatile memory such as ROM 107 and flash memory 111, and a small on-chip RAM such as SRAM 109. During the life cycle of chip device 100, a payload including a boot ROM 161 may be written to ROM 107, and a boot loader 163 may be written to flash memory 111.

[0067] Chip device 100 may include security processing functionality. A security coprocessor 131 may be used to process security algorithms, such as a secure hash algorithm. Example secure hash algorithms include the SHA family of algorithms. Similarly, a random number generator, such as a random number generator (TRNG) 133, may be included to provide random values.

[0068] After wafer production, the chip devices on the wafer are tested and can be personalized. As will be discussed later, the personalization process includes inserting the device unique ID and key into the device ID fuse 129 and the key fuse 125.

[0069] Figure 3 The diagram shows an example test layer system for a wafer. The tester 303 has a function of testing each chip device 100 ( Figure 1 ) and can provide the power and commands required to perform the test. Figure 3 (Not shown, but assuming that wafer 301 will include multiple chip devices 100), a key management server (KMS 307) can send and receive data to and from chip devices 100 on wafer 301 through a hardware security module (HSM 305) on the manufacturing floor (located between tester 303 and the Internet connection). HSM 305 may not be directly used as the basis for maintaining the confidentiality of the device-unique key. Instead, HSM 305 can be used to buffer payloads to handle temporary connectivity issues with KMS 307, and to monitor and collect statistics about operations performed during the personalization process.

[0070] Mechanisms for controlling chip devices can be used to supplement testing and personalization to address the potential for various attacks during the device's lifecycle. One aspect of the present invention includes a chip device lifecycle that can be broken down into multiple phases, each of which can have multiple states. In one embodiment, the product lifecycle can be broken down into various phases and multiple states. Depending on whether the manufactured chip device is part of a wafer or in the form of a separate package, the phases can include a wafer phase and a package phase.

[0071] Figure 4

[0014] Figure 1 is a high-level diagram illustrating example states of a chip's lifecycle. The mechanism for transitioning between these states will be described later. Figure 4 The states are shown in sequential order. However, the selection of states for entering the wafer stage and the packaging stage may be changed.

[0072] Figure 4 1. An example of a state is shown, which may include: an original device state 401, a test mode enabled device state 403, a test mode locked device state 405, a test mode disabled device state 407, a personalized device state 409, a configured device state 411, and a provisioned device state 413. As will be discussed in more detail later, the first three states may be hard physical states of the device and may be defined by fuses. In an example embodiment, the physical state of the device may be defined based on fuse values ​​stored in the device state register 127. As will be further explained below, there are (multiple) security levels associated with the device state, including: an original device state security level, a test mode enabled device state security level, a test mode locked device state security level, a test mode disabled device state security level, a personalized device state security level, a configured device state security level, and a provisioned device state security level. As will be further explained below, a change in device state may trigger a change in security level.

[0073] Chip devices can have various degrees of lock / security. "Lock" or "security level" can refer to the actions taken to affect chip access. For example, a chip device is considered locked when all access ports are disabled. In some embodiments, memory can also be disabled. A chip device is considered primarily locked when minimal access is allowed to achieve a path to the next state. Other degrees of locked chip devices can include: restricting access to ports to a greater degree than the original device 401 state.

[0074] In the initial state, the original device 401 state, each chip 100 has an original device security level, which essentially locks the chip so that the debug port 101, the scan test port 147, and the flash test port 145 are inaccessible from outside the chip 100. To implement the original device security level, port blocking can be achieved by inhibiting the data path between the outside world and the internal logic of the chip 100.

[0075] First, the original device 401 state can be merged into the next state, such as the test mode enable device 403 state, to start the manufacturing test process. In an exemplary embodiment, the original device 401 state can be a state in which all device state fuses 127 are in their unprogrammed default state (original device bit pattern), such as, for example, all are set to zero. It is believed that the chip is fused to the next state by blowing, setting or changing a specific fuse in the device state fuse 127. In the case of a one-time programmable memory, blowing a fuse can take the form of programming the fuse to the second fuse state, such as changing the fuse state from 0 to 1 in an example in which all fuses are 0. In an exemplary embodiment, the chip device (original device state security level) in the original device 401 is mainly locked, so that a command can be sent through the serial line debug port 101. The command can make the test mode enable bit pattern be written into the fuse to increment to the test mode enable device 403 state.

[0076] In response to the change in device state, the security level is correspondingly changed from the original device state security level to the test mode enabled security level. In the test mode enabled security level, all ports (debug port 101, flash test port 145, and scan test port 147) are open. When device state decoder 121 determines that the device state is in the test mode enabled device state, port opening can be achieved by enabling the port's data path.

[0077] In the test mode enabled device 403 state, the device unique identifier can be incorporated into the device ID fuse 129, manufacturing tests can be run, and failed devices can be marked for destruction. Failed devices can be marked for destruction by physical marking etching or by other physical means.

[0078] When the manufacturing test process is successfully completed, device 100 transitions from the test mode enabled device 403 state to the test mode locked device 405 state (successful password entry) or the test mode disabled device 407 state (unsuccessful password entry).

[0079] A password may be required to transition from the Test Mode Locked Device 405 state to the Test Mode Enabled Device state. This is a temporary change, and an on-chip reset will return the chip to its default value. A chip cannot transition from the Test Mode Disabled state to the Test Mode Enabled Device state. A chip can only be personalized once. If a password is used to return to the temporary Test Mode Enabled state, the chip is still considered personalized.

[0080] State transitions and security level settings are controlled by firmware 104 running on chip 100 and can be combined with Figure 4 、 Figure 5 、 Figure 6A and Figure 6B The secure boot process is controlled by firmware 104 running on chip 100 and can be combined with Figure 8A 、 Figure 8B and Figure 8C The firmware can be Figure 1 A portion of the embedded processor 104 is shown. Figure 10 Further details of the hardware implementation are provided which will be further explained below.

[0081] The transition to the personalized device state 409 protects the chip device 100 to ensure that private data cannot be accessed through the disabled ports (debug port 101, flash test port 145, and scan test port 147) when the personalized device is in state 409, which is similar to the security measures taken when in the test mode locked 405 or test mode disabled 407 device states.

[0082] The personalized device state 409 may be based on creating a secret device initialization key (DIK), exporting the DIK to a key management server (KMS), and storing the DIK in on-chip non-volatile memory, such as key fuses 125. In this manner, the state is characterized by the DIK assets within the device 100. The apparatus 100 may be re-personalized, i.e., the device 100 may be transitioned to the personalized device state 409 a number of times equal to the number of physical DIKs within the device (e.g., this number may be set to 3 + the test DIK).

[0083] As with other state transitions, the firmware 104 running on the processor 103 controls the transition from the personalized device state 409 to the configured device state 411. The firmware 104 also programs the values ​​in the flash memory 111 and fuses 123, 125, 127 to personalize the device 100. Once such values ​​are programmed by the firmware 104, the device 100 is considered configured (configured device state 411).

[0084] The fifth state - the configured device 411 state is the state where the device already has any application or product specific fuses, which are blown if necessary to achieve configuration of the application or product.

[0085] The sixth state, Provisioned Device 413, is a virtual state and is defined by the firmware 104, keys, and certificates stored in the device's on-chip flash memory. In this way, the device can be re-provisioned at any time by erasing the firmware and restarting the provisioning process. The processes associated with incrementing the personalized device state 409 and the provisioned device state 413 will be discussed later with respect to the accompanying figures.

[0086] <Physical Device Status Security>

[0087] One aspect of the present invention is to control fuses as chip devices increment between physical device security states. One aspect of the present invention is to enhance fuse security. Throughout the life cycle of a chip device, an attacker may attempt to restore a fuse or blow a fuse. One aspect of the present invention is that each chip device may include a separate stack of fuses (e.g., stack 0 or device state fuse 127) for managing device state and a device ID fuse 129 for storing device ID. In an example embodiment, there may be 27 bits in the fuse that encode the state of the device, but it is to be understood that the number of bits mentioned herein may vary depending on the application. In addition to these bits, stack 0 may also include a 3-bit lock and a 24-bit checksum.

[0088] like Figure 2As shown in the example device state decoder of , the 27 device state bits 201 can be divided into three 9-bit groups (Group 0, Group 1, Group 2), and each group can be further decomposed into three 3-bit subgroups. The 3-bit subgroups can be spread out into the physical fuse macros that contain the fuses of the device. In this way, if an attack is attempted on a group of critical security fuses, the attack may also interfere with some of the 27 device state fuses. One aspect of the present invention is that the device state can only be moved forward by incrementing to the next state, such as Figure 4 As shown, in which all 3-bit subgroups in the next 9-bit group have been programmed to create a 9-bit pattern.

[0089] Likewise, during the life cycle of a chip device, an attacker may attempt a fuse sensing attack. A fuse sensing attack is an attack on the sensing / reading of fuse values ​​and can be performed by forcing the fuse shadow register 915 ( Figure 9 ) occurs when the fuse data is incorrectly latched and remains all 0s. As discussed above, there are two types of attacks on fuses. The fuse can be attacked by: (a) physically cutting the wire indicating a '0', causing it to become an open '1'; or (b) rebuilding the fuse by depositing metal to convert the open '1' to a '0'. Alternatively or in addition, the fuse shadow register 915 associated with the fuse can be attacked.

[0090] To protect against fuse sensing attacks in any state during manufacturing test, the chip device can default back to the original locked state. In an example embodiment, if a fuse sensing attack is successful after the chip has been fused into one of the device states, the fuse shadow register 915 will contain zeros instead of fuse data (or store a bit pattern that does not match the value stored in the device state fuse 127). In this case, comparing the value stored in the fuse shadow register 915 with the device state fuse 127 can trigger a process that forces the chip device into the default original device 401 state. One aspect of the present invention can be that, in the event of a fuse sensing attack, the state of the fuses in the chip device is forced into the default original device 401 state, which is primarily a locked state.

[0091] Figure 5 is a flow chart illustrating changing between physical device states based on fuse states during the device lifecycle. Figure 5 The functions outlined in may be handled by, for example, the security co-processor 131 ( Figure 1 ) or executed by the embedded processor 103.

[0092] In S501( Figure 5 ), original device 401( Figure 4) state is related to the state of the chip device after the wafer is first manufactured. In this state, all device state fuses 127 ( Figure 1 ) are in a default state, such as zero. In the original device 401 state, the chip device is almost locked, wherein only the path from the debug port 101 (eg, serial wire debug (SWD) port) to the fuse controller 121 may be available.

[0093] In S503( Figure 5 ), after the chip device 100 ( Figure 1 ) After power is applied, a command may be sent to the fuse control and device state decoder 121 that causes the fuse control and device state decoder 121 to write the correct pattern that "increments" the device state to a test mode enabled device 403 ( Figure 4 )state.

[0094] Once in test mode enable device 403 ( Figure 4 ) state, the test mode port and the test mode feature become enabled. In an example embodiment, the enabling of the test mode port may include access to a complete debug port 101 ( Figure 1 )path.

[0095] Other ports that may be enabled include the Flash Test Controller port 145 ( Figure 1 ) and scan test port 147. With the three test mode ports enabled, in S505 ( Figure 5 ), perform manufacturing tests on chip devices. This manufacturing test may include any tests performed during the manufacture and initial distribution of the device, including, for example, running a set of hardware built-in self-tests (HW BIST) known in the art.

[0096] In an example embodiment, the device 403 is enabled in test mode ( Figure 4 ) state, the fuse shadow register 915 ( Figure 9 ) is rewritable, and various debugging features (such as sending clock signals to ports) can also be enabled. This makes the chip device more flexible for various tests and software development.

[0097] Once the manufacturing test has been completed and the chip device has passed all test modes ("Yes" in S507), in S511 ( Figure 5 ), blow the appropriate device status fuse 127 ( Figure 1 In one embodiment, the Group 1 device state fuses 127 are written with the correct pattern to "increment" the device state to the test mode locked device 405 ( Figure 4) state. Alternatively, when the chip device fails the test ("No" in S507), for example, due to a manufacturing defect, the group 1 and group 2 fuses can be programmed to a mode that skips the test mode lock device 405 state and directly jumps to the test mode disable device 407 state in S509. Alternatively, S509 can program the fuses to an invalid state, placing the device in a disabled device state.

[0098] One aspect of the present invention is that the test mode disable device 407 ( Figure 4 ) state is a functional state and can be used as the final state of the device. In this state, it can be permanently disabled (for example, by in firmware 104 ( Figure 1 ) does not provide any supported way to switch out of test mode (disable device 407 state) test mode ports and features. Once permanently disabled, a part can be locked and cannot be restored to a functional state. No access is allowed for debugging or mainline functions.

[0099] Test mode locking device 405 ( Figure 4 ) state is also a functional state and can be used as the final state of the device if the product's safety standards allow. In this state, the test mode ports and features can be unlocked by, for example, a password. This password can be derived from the device's unique Device Initialization Key (DIK) and may be from the TRNG 133 ( Figure 1 ) (for example, if one-time password mode is enabled using a fuse).

[0100] In S513( Figure 5 ), in a known state mode and device state fuse 127 ( Figure 1 ) to check whether the device state fuse 127 decodes to the previous state - the original device 401 ( Figure 4 ) state, test mode enabled device 403 state, test mode locked device 405 state, and test mode disabled device 407 state. When device status fuse 127 is not fully decoded into one of the above four states (S513, No), at S515, the device is disabled (fuse 127 is not updated). In an exemplary embodiment, at S515, the chip device is completely locked and disabled (permanently "blocked").

[0101] In an exemplary embodiment, by using the fuse control and device status decoder 121 ( Figure 1 ) to execute S513( Figure 5 ) and S515. The fuse control and device status decoder 121 sets the fuse shadow register 915 ( Figure 9) is decoded into, for example, a 3-bit pattern representing a state identifier. The fuse control and device state decoder 121 may be unable to decode the large bit pattern into one of the predefined states ("No" in S513), possibly due to a fuse sensing attack. In this case, the large bit pattern is deemed incorrect, which causes the device state fuse 127 to be programmed to a default decoding state, such as a disabled device state, at S515. The disabled device state is similar to the original device 401 state in that both states force the chip device into an almost locked state. The disabled device state is different from the original device state in that, in the disabled device state, the debug port (e.g., SWD) path may also be disabled. Therefore, the disabled device state is completely locked and disabled.

[0102] When the device status fuse 127 ( Figure 1 ) is decoded into one of the previous states (S513, yes), in S517 ( Figure 5 ), S519 and S521, if the fuse bit indicates that the device is currently in the test mode lock device 405 state, an unlock request including a password has been received ("Yes" in S517) and the password has been verified ("Yes" in S521), the chip device can be forced to enter the test mode enable device 403 ( Figure 4 ) status (S503).

[0103] In S519( Figure 5 ), the chip device can perform a verification operation to verify the unlock password. In an example embodiment, the device 405 ( Figure 4 ) state to the test mode enabled device 403 state can be controlled by the second stage software (e.g., a boot loader). The first and second stage software is, for example, software boot code, which is in the boot loader 163 ( Figure 1 ), the software boot code can be executed outside of the flash memory.

[0104] In this case, the third stage software that wishes to unlock the device to allow test mode must unlock via the verified signature header. In the example embodiment, the boot loader ( Figure 1 ) performs verification of the validity of the third stage image. Once the boot loader 163 verifies the image, the boot loader can accept the request and unlock the device to allow test mode. Unlocking the device for test mode may include allowing access to additional areas of memory in the chip device. This mechanism allows the boot loader 163 to maintain the confidentiality of the unlock process while allowing a clear interface for external unlock requests. Once the device is unlocked into test mode, the chip device will have a test mode enable device 403 ( Figure 4) state and its test capabilities and behaviors.

[0105] If the unlock password is verified to be correct (Yes, S521), then S503 ( Figure 5 ) to put the device into execution test mode, enabling device 403 ( Figure 4 )state.

[0106] In an exemplary embodiment, if the device status fuse 127 ( Figure 1 ) is written as a mode in which the device state decoder 121 does not decode into a known state, the chip device can be transferred to the original device 401 ( Figure 4 ) state of the system.

[0107] <Secure Boot Process>

[0108] In situations such as Figure 4 The chip device can be powered on and booted in various physical or logical states as shown, and while in use in the field. One aspect of the present invention is a secure boot process used by the chip device throughout its life cycle. The secure boot process begins at the wafer manufacturing stage, continues through the insertion of keys and firmware, and the blowing of fuses, and can include the field firmware update process.

[0109] Figure 6A 、 Figure 6B is a flow chart of an example embodiment of a wafer stage related to a secure boot process. As will be discussed later, Figure 8A 、 Figure 8B 、 Figure 8C is a flowchart of an example of the packaging phase.

[0110] As mentioned above, after wafer production, the chip device is in the default original device 401 ( Figure 4 ) state, in which the test mode is not accessible from the outside. The inaccessible test mode includes using the flash test port 145 ( Figure 1 ), TAP control scan test port 147, debug port 101, and any test features that may leak information (such as TRNG 133 data readout) and would compromise the device personalization process (creating the device unique identifier and secrets shared with the key management server). At S601 ( FIG. 6 ), to begin the security-sensitive manufacturing test process, chip devices (not shown) on a wafer are powered on (e.g., so that many chip devices on a wafer can be tested in parallel).

[0111] Because the chip device is initially in the original device state, after the chip device is initially powered on, in S603 ( FIG. 6 ), a group of device state fuses 127 ( Figure 1 ) to increment the device state to test mode enable device 403 ( Figure 4In an example embodiment, if the fuse mode does not correspond to a known state (such as test mode enabled device 403), the chip device will increment back to the default original device 401 state. This operation ensures that if the fuse sensing process is tampered with (which may cause the device state fuses 127 to remain at all 0s, or alternatively, to switch to all 1s), the chip device cannot be turned back on to any security-sensitive test mode.

[0112] To blow these original device state fuses while in this initial locked state ( Figure 1 ), a dedicated debug port 101 (e.g., SWD) to the fuse control and device status decoder 121 remains open. Through this path, the device status fuse 127 can be accessed. As mentioned earlier, the device status fuse 127 can be a set of fuse bits. In an exemplary embodiment, the device status fuse is 27 bits that are programmed to enable the device to function in the extraction mode.

[0113] After test mode has been enabled (ie, the device is incremented to test mode enabled 403 ( Figure 4 ) state), in S605 ( Figure 6A ), a set of manufacturing yield tests can be run.

[0114] In an exemplary embodiment, to begin manufacturing yield testing, first, a flash memory yield test can be run to screen out any flash memory defects. Second, a logic BIST can be run to obtain substantial coverage over the logic, particularly over the logic included in the personalization process. Third, a scan pattern can be run to cover any gaps in the personalization logic coverage, so that the scan pattern can be locked out and does not need to be run again (to prevent compromising the safety of the personalization process). Fourth, a memory BIST (on-chip SRAM and ROM) can be run to verify that the memory is functional. Fifth, a set of TRNG tests can be run to gain confidence in the safety-critical circuitry, so that any data read test patterns can be locked out. At the conclusion of this testing, any failed devices can be flagged for destruction ("No" in S607, S609).

[0115] After running these manufacturing yield tests, the chip device passes the manufacturing test ("Yes" in S607), and in S611 ( Figure 6A ), you can use debug port 101 ( Figure 1 ) interface to blow another set of device state fuses 127 to lock these test modes; the device can be advanced to the test mode lockout 405 state. The lockout mechanism can be unlocked by writing the correct password into a register exposed via a direct path from the debug port 101 interface. However, the expected password does not exist at this time, so the device will reject all passwords.

[0116] In an example embodiment, before or after running the manufacturing test, the debug port 101 ( Figure 1 ) interface encodes a device unique identifier (Device ID or Dev ID) such as a 64-bit identifier into the Device ID fuse 129. For example, the Device ID may be stored in 64 fuses and represented by 64 fuse shadow registers 915 ( Figure 9 ) Mask the device ID. 64 fuses are provided by way of example, and the exact number of fuses is not important. (Once the key is created and stored on the key management server 307 ( Figure 3 )The device ID can be used as an index to the device and its key.

[0117] One aspect of the present invention includes a security sensitive test mode that is locked to prevent any snooping into the device personalization process. Again, the test mode is intended to be unlocked only in the event of a field rework, rather than for performing additional testing of each device (all additional yield testing can be performed with other test features, or by rerunning the built-in self-test (BIST)). In addition to the test mode, external interfaces with DMA (Direct Memory Access) capabilities on the internal system bus may also pose a threat to the personalization process. In an example embodiment, these capabilities cannot be enabled by default, and the bus security mechanism will also default to a "secure state" (secure means that by default all DMA-like capabilities will not have access rights within the device, but will first require the security coprocessor 131 ( Figure 1 )

[0118] At this point, the chip device has been substantially tested and is now ready for the personalization process (which involves creating the wafer 301 ( Figure 3 ) between the chip device on the 300 and the key management server (KMS 307)). In order to protect the secret, the test mode can be locked 405 ( Figure 4 ) state or the test mode disabled 407 state. To start the personalization process, the chip devices on the wafer can be powered on again, a set of hardware (HW) BISTs can be run (i.e., testing many chip devices on the wafer in parallel), and the embedded processor 103 on each chip device can be rebooted from the boot ROM 161 ( Figure 1 ).

[0119] Specifically, the process starts at S613 ( Figure 6A), in which the chip device is powered on and a set of HW BIST tests are run. In an exemplary embodiment, three hardware units including a finite state machine (FSM) can participate in the test. These hardware units are design for testability (DFT) or flash memory test 141 ( Figure 1 ), fuse controller & device status decoder 121, and TRNG 133, wherein the synchronization of events can be controlled by the power management unit (PMU) FSM that releases the reset. Flash test 141 runs logic BIST and memory BIST, fuse control and device status decoder 121 runs a set of integrity tests, and TRNG 133 runs its BIST. If all of these tests are successful ("yes" in S615), then in S619, the reset of the embedded processor 103 is released so that it can be booted from ROM. If the test fails ("no" in S615), the BIST has failed and the processor will not be booted (S617). If the BIST fails, the component can enter a locked (unusable) state. You can try resetting, but there may be an expectation that a failed BIST indicates that the BIST will fail again, and therefore the component is useless.

[0120] Likewise, at S619 ( FIG. 6 ), the embedded processor 103 ( Figure 1 ) can boot from boot ROM 161. For security reasons, in an exemplary embodiment, the instruction bus is gated by default reading data from any other memory (e.g., flash memory 111 or SRAM 109). ROM 107 may contain an RSA public key, the main purpose of which is to authenticate the stage 1 boot loader in on-chip flash memory 111. At S619, the stage 1 boot loader will not be present in ROM 107.

[0121] Before the ROM code checks the Stage 1 bootloader, at S621 ( FIG. 6 ), the ROM code reads the status of the auto-erase PIN. The PIN can be communicated off-chip, as it may be an external chip PIN. If the auto-erase PIN indicates that the flash memory needs to be erased, then at S623, the flash memory is erased until the erase is verified to be complete.

[0122] In S625( Figure 6B ), the ROM code can check for a stage 1 flash boot loader. At this point, the boot loader does not exist in the flash memory 111 ( Figure 1) (S625, No: Not Present), therefore, at S643, the processing loop continues until a flash firmware payload containing a boot loader is delivered via, for example, SPIIN 149. Once the firmware payload is received ("Yes" at S645), at S647, the payload is written to the flash memory 111. In addition to the boot loader, the payload may also include other firmware for personalization. In an exemplary embodiment, the payload includes a personalization-specific code and an RSA public key used to encrypt the DIK for export to the key management server (KMS 307).

[0123] Once the ROM 107 is stored in the flash memory 111 ( Figure 1 ), in S627( Figure 6B ), ROM 107 performs a hash function on the personalized dedicated code and performs an RSA verification operation to verify the boot loader using the public key embedded in the firmware. At S629, it is determined whether the verification of the personalized dedicated code is passed.

[0124] In an example embodiment, the ROM code may not use branches when executing the decision to verify whether it has passed. Instead, it uses the expected hash digest portion of the RSA signature to perform an XOR operation on the calculated SHA-256 digest (the value generated is a 384-byte constant, where, if the verification is passed, the top is blank and the bottom is 256 bits of zero). Then, for example, the 384-byte constant is hashed using SHA-256 to produce a smaller value. The 256-bit result is then written to a register connected to a 256-bit hardware comparator. If all bits match the expected 256-bit constant (which is embedded in the gate of the hardware comparator), the comparator will then only allow the flash memory to be unlocked for execution.

[0125] If the verification of the personalized firmware fails ("No" in S629), then in S631 the device must be rebooted to try again.

[0126] If the verification passes ("Yes" in S629), the ROM code first writes, for example, a 256-bit SHA-256 digest into the RWR hidden key ladder (HKey) register which is writable only by the ROM 107.

[0127] In an exemplary embodiment, if the verification passes ("YES" in S629), then in S633, ROM 107 unlocks flash memory 111 and SRAM 109 for additional flash code execution, performs instruction fetch and starts running the stage 1 boot loader (personalized firmware).

[0128] In S635( Figure 6B), executing the personalized firmware may include creating random secret data that is used to derive, for example, two 256-bit device-unique secrets. One secret may be a device initialization key (DIK), which may serve as a root shared secret between the device 301 and the key management server (KMS 307). The other secret may serve as an asymmetric private key (HPriv) from which the personalized firmware may generate a corresponding asymmetric public key (HPub) that will also be sent to the KMS 307. In an example embodiment, these secret values ​​may be generated from a pair of global secret constants (HWC and RBC) and a pair of device-unique secrets (e.g., each 256 bits in size). The device's on-chip TRNG 133 ( Figure 1 ) can be used as a source for creating device-unique secrets (OBS, FBS, and RSR). The OTP-based secret (OBS) component of the DIK can be burned into key fuses 125. The flash-based secret (FBS) component of the DIK can be written to flash memory 111. In an example embodiment, the RSR component can serve as an initial random seed for later "stirring" or "mixing" with a runtime-generated random number. This "stirring" or "mixing" can be a standard cryptographic use of random entropy.

[0129] Once the device unique secret is stored in the non-volatile memory (NVM) - flash memory 111 ( Figure 1 ) or fuse 125, the firmware can instruct the security coprocessor 131 (e.g., SHA engine) to obtain DIK, HPriv, and another key called HI PHIK (used as the HMAC key to derive the encrypted DIK). All of these SHA-based acquisitions can be limited by specific hardware operation certificates and use an internal secret register file called a hidden key ladder, which is used to store root secrets and intermediate values. The SHA hardware can interact directly with the HKey ladder via a dedicated bus. This initial generation of the DIK is visible to the embedded processor 103, so the processor can store the DIK in memory. The generation of HPub from HPriv can be completed by the firmware. At this point, the firmware has collected the DIK & HPub, and the XI PHIK is available via the SHAHMAC certificate, which can automatically load the XI PHIK from the key ladder.

[0130] In S637( Figure 6B ), using the saved DIK, the personalized firmware can burn the fuse to permanently disable the HKey certificate used to create the DIK into the firmware readable register (FRR). From this point on, the DIK has no effect on the embedded processor 103 ( Figure 1) is no longer visible to the user and is stored in non-volatile memory (NVM) such as flash memory 111 (still resident in registers). The DIK may be subjected to a series of SHA HKey operations to create a firmware version-bound root key.

[0131] In S639( Figure 6B ), the personalized firmware can encrypt the DIK, HPub and device ID and export them to the key management server (KMS 307( Figure 3 In an example embodiment, the personalized firmware can RSA encrypt the data bundle using the personalized public key obtained from the flash boot loader. Once the data bundle is encrypted, it can create a MAC of the data using SHA-256 HMAC, where the HKey certificate uses the XI PHIK as the key. The MAC and encrypted DIK / DevID can then be exported from 135 to the KMS 307 via SPI.

[0132] In S641( Figure 6B ), using the DIK stored locally in NVM and also in the key management server 307, the chip device has a unique shared secret indexed by the DevID on the KMS 307 side. At this point, the status of the device is personalized device 409 ( Figure 4 )state.

[0133] Between personalizing the active chip device on the wafer and provisioning the device in packaged form, the key management server 307 can prepare a separate provisioning payload for each chip device. The key management server (KMS 307) contains a list of all personalized chip devices indexed by DevID, along with their individual device initialization keys (DIKs). The KMS 307 also has a copy of the personalized firmware residing in the flash memory of each device as a stage 1 boot loader. Using the personalized firmware and the DIK, the KMS 307 can retrieve a key (which may be called the FW DIK) that is specific to the device and bound to the firmware image. Using this key, the KMS 307 can pre-encrypt the provisioning payload (endorsement base seed (EPS), X.509 certificate, and functional firmware) or at least pre-encrypt the EPS using the unique FW DIK for each device. This means that the separate provisioning payload can be pre-calculated when the wafer arrives at the packaging location.

[0134] Figure 7 An example test layer system is shown for the packaging phase, in which the packaged device is provisioned. To provision the packaged device 701, the key management server (KMS 307) can send data to and receive data from the packaged device 701 through the hardware security module 305 and the tester 303.

[0135] Figure 8A 、 Figure 8B 、 Figure 8C It is a diagram that can be obtained by, for example Figure 7 The flowchart of the packaging stage of the wafer test layer system implementation is shown. Figure 4 The status and Figure 1 The process is described using a semiconductor chip device.

[0136] During the packaging phase, the wafer arrives containing the individual devices 409 ( Figure 4 ) state (some yields are marked to allow destruction due to manufacturing test failures). In this arrival position, the wafer can be sliced ​​and the devices assembled into their packages (packaged device 701 ( Figure 7 )). Once packaged, in S801( Figure 8A ), powering up the individual packaged devices 701 to begin the remainder of the manufacturing yield testing. At S803, the remainder of the manufacturing testing can be run to characterize and determine the suitability of each device. This remaining testing is longer-lasting and more thorough than the testing performed at the wafer stage. Manufacturing testing performed at this stage may include flash integrity testing, logic BIST, and some analog qualification testing. In an exemplary embodiment, these tests do not enable the extraction of secret information installed during the device personalization sequence, which was previously performed at the wafer stage. For example, scan testing is run at the wafer stage prior to personalization.

[0137] At S805, a decision is made as to whether the packaged device 701 passes the remaining manufacturing tests. In an exemplary embodiment, at S807, any device that does not meet the required minimum standards ("No" in S805) is considered a failed device and can be destroyed (e.g., to prevent surreptitious reverse engineering).

[0138] For functional packaged devices that do pass the remaining manufacturing tests ("yes" in S805), the additional remaining fuse 123 may be blown in S809 ( Figure 1 At this point, each chip device has been incremented to the configuration device state 411.

[0139] After all devices have been fuse configured, all devices can be rebooted to perform the provisioning process. Figure 7 ), the key management server (KMS 307) is connected to the hardware security module (HSM 305 ( Figure 3)) sends data to and receives data from the packaging device 701. As with provisioning, the confidentiality of the provisioning secrets cannot be directly relied upon by the HSM 305. Rather, the HSM 305 can be used to buffer payloads, to handle temporary connectivity issues with the KMS 307, and to monitor and collect statistics about operations performed during the personalization process.

[0140] In an example embodiment, the packaged chip device may be provisioned with valid certificates and market-specific functional firmware. While the personalized firmware consists of a Phase 1 firmware module, the functional firmware may be broken down into multiple modules. To get these certificates and functional firmware into the device, at S811, the packaged chip may be rebooted in a manner similar to the personalization process. The packaged chip device is powered on and a set of BIST tests may be run. Three hardware units comprising a finite state machine (FSM) may participate in these tests (DFT 141( Figure 1 ), fuse controller 121, TRNG 133), and the synchronization of these events can be controlled by the PMU FSM that releases the reset. The DFT unit 141 can run the logic BIST and memory BIST, the fuse controller 121 can run a set of integrity tests, and the TRNG 133 can run its BIST. If all of these tests are successful (S813( Figure 8A ), then at S817, the reset of the embedded processor 103 may be released (so that the boot process is performed by the boot ROM 161). Otherwise ("No" in S813), at least one test has failed at S815.

[0141] In an exemplary embodiment, for security reasons, at this time, by reading the data from any other memory (ie, flash memory 111 ( Figure 1 ) or SRAM 109) to enable the instruction bus. ROM 107 may contain an RSA public key whose primary purpose is to authenticate the stage 1 boot loader in flash memory 111. In this case, the stage 1 boot loader is the personalized firmware. However, before checking the stage 1 loader, the ROM code can check whether a flash auto-erase is being requested by checking the value of the personal identification code.

[0142] Specifically, before the ROM code check stage 1 flash boot loader, at S819 ( Figure 8A ), the ROM code can read the status of automatically erasing the personal identification code. If this status is set ("Yes" in S819), then in S821, the ROM firmware can erase the entire flash memory.

[0143] At this point, at S823, the ROM code can check for a stage 1 flash boot loader. At this point, the boot loader is present as the personalized firmware. However, if the stage 1 boot loader is not present ("No" at S823), the processing loop loops through S847, S849, and S851 until the firmware payload is received and written to the flash memory (compare to S643, S645, and S647 in FIG6).

[0144] In S825( Figure 8A ), the stage 1 boot loader is verified. To verify the stage 1 flash boot loader, the ROM firmware can generate a hash table of the code using a hash function and perform an RSA verification operation using the public key embedded in the firmware. At step S827, it is determined whether the boot loader passes the verification process.

[0145] In an exemplary embodiment, for determining whether the boot loader verification is passed (S827( Figure 8B )), the ROM code may not use branches. Instead, it performs an XOR operation on the calculated SHA-256 digest with the expected hash digest portion of the RSA signature ("yes" in S827; the resulting value is a 384-byte constant, where, if verification passes, the top is blank and the bottom is 256 bits of zeros). The 384-byte constant is then hashed to produce a smaller value, for example, using SHA-256. The 256-bit result is then written to a register connected to a 256-bit hardware comparator. The comparator will only allow unlocking of the flash memory 111 if all bits match the expected 256-bit constant (which is embedded in the gate of the hardware comparator). Figure 1 ) in an additional area for execution (S831).

[0146] If the verification of the personalized firmware fails ("No" in S827), then at S829 the device must be rebooted to try again, or another signed boot loader must be reloaded using the auto-erase feature.

[0147] In another example embodiment, if the bootloader can be authenticated ("Yes" in S827), the ROM code can first write, for example, a 256-bit SHA-256 digest to a RWR hidden key ladder (HKey) register (not specifically shown), which is writable only by the ROM, and lock it. This register is not readable by any agent except the dedicated SHA HKey certificate handler. Because the original DIK creation certificate has been revoked via the fuse at this point, the bootloader firmware can be forced to include its firmware hash table when obtaining its device initialization key (called FW DIK).

[0148] Next, in S831( Figure 8B ), ROM firmware can unlock flash memory 111 ( Figure 1 ) and SRAM 109 for instruction fetching and starts running the stage 1 boot loader (personalized firmware).

[0149] Because the device has been personalized, the personalization firmware can now check whether the chip is provisioned at S833. The personalization firmware checks whether the chip is provisioned by looking for a certificate. However, at this point, the certificate may not exist and the chip device will be considered not provisioned ("No" in S833).

[0150] Because the device has not been provisioned yet, at S835 a loop process is performed to wait for a payload to be provisioned via, for example, the SPI slave control 135 .

[0151] Once the firmware detects the start of the provisioning process via the SPI slave control 135 (S837( Figure 8C ), at S839, the firmware can begin to obtain its provisioning key. In the example embodiment, the security coprocessor 131 ( Figure 1 ) (e.g., a SHA-256 control processor) performs a specific RW DIK creation operation (for which the security coprocessor 131 has a hardware embedded certificate) using a hidden key ladder (HKey). The embedded processor 103 then uses the security coprocessor 131, such as a SHA-256 control processor, and the HKey to retrieve a set of three provisioning keys (one provisioning key for remote authentication of the device, one provisioning key for encrypting the provisioning payload, and one provisioning key for authentication and integrity on the provisioning payload). All of these keys can be rooted in a firmware-bound version of the DIK (referred to as FW DIK), which can be retrieved by the security coprocessor 131 (SHA-256 control processor) by creating a hash table {HWC, RBC, OBS, FBS, RWR} and writing the resulting digest into ISR0. ISR0 can then be used to retrieve the three provisioning keys.

[0152] In S841( Figure 8C ), Key Management Server (KMS 307( Figure 3)) can read the DevID from the device and issue a challenge that forces the device to prove its identity. The response may involve operating on the challenge random number with the "Am I the Device" authentication key, which is derived from the DIK version bound to the flash firmware. This ensures that the device has the correct DIK and the correct version of the personalized firmware (when the ROM mixes its own hash table into the KDF 307). In an example embodiment, the provisioning payload may contain the following items, where (at least) the EPS is encrypted:

[0153] Endorsement base seed (EPS)

[0154] A signed X.509 certificate with the RSA subject's public key.

[0155] Signed X.509 certificate with the ECC subject's public key.

[0156] Market specific feature hash firmware.

[0157] In S841( Figure 8C ), which can decrypt parts of the supply payload.

[0158] In an example embodiment, the payload may contain a market-specific hashed firmware, a device-unique endorsement base seed (EPS), and two signed X.509 certificates (one containing the RSA subject public key and one containing the ECC subject public key). These subject public keys are the public half of an endorsement key pair (EK), which can be verified by the device using its own EK certificate (i.e., the X.509 certificate just received).

[0159] In S843( Figure 8C ), the device can perform this verification by using the EPS and a set of parameters to obtain an EK pair, and can then compare the resulting EK.Pub with the EK.Pub contained in the EK certificate. Once this verification process has been completed, at S845, it can be determined whether the provisioning payload is valid. If it is determined that the provisioning payload is valid ("Yes" in S845), the device is considered to have been provisioned, and its status becomes Provisioning Device 413 ( Figure 4 At this time, at S859, the chip device is supplied and the chip device can continue to function boot.

[0160] One aspect of the present invention includes that the process of decrypting and verifying the provisioning payload (both the entire signature payload verification and the EK verification; S841, S843, S845) can be completed immediately or at some other time (or more trusted location). The order can depend on the order in the personalization firmware.

[0161] Likewise, each time the device boots up, in an example embodiment, it must repeat this verification process. Thus, the state of the device may initially be that the device 411 ( Figure 4 ) state, and then, only after verifying the two EK key pairs (RSA and ECC) with its two certificates, changes to the Provisioning Device 413 state. Subsequently, this final device state transition can be a soft device state transition and, like the previous state changes, may not depend on fuses.

[0162] In the event that device provisioning fails, at S859 , a secure method may be used to communicate a problem with booting, a message such as a boot loader verification failure, or a provisioning verification failure.

[0163] If necessary, chip device 100 can be re-provisioned at any time. This may be necessary due to a firmware vulnerability, or simply because a device originally intended for one market needs to be provisioned for another market. The re-provisioning process can be started in the same way as a normal boot, with one minor difference: the device already contains functional firmware, EPS, and two valid certificates. To this end, the method used to trigger the re-provisioning can be to erase all or some of the flash firmware and data.

[0164] The erasure of flash memory data can be triggered by reading the value of a specific personal identification code or by communicating with the firmware of the device through any one of the interfaces of the device. The purpose of the personal identification code is to force the erasure of the entire flash memory, not including personalized data, but including the boot loader (if the device contains valid signature firmware, but cannot start the re-supply process, then this method may be the only method). In an exemplary embodiment, if the boot loader is erased, the device must first receive a new boot loader by a method similar to that used during device personalization (for example, by receiving the flash firmware payload using an SPI slave interface). Once the boot loader is in place (or if it is not erased), the process can be carried out similarly to the original supply process. First, the key management server (KMS 307) makes the device prove that it is a valid device by reading the device identifier and then issuing a challenge that will prove whether the device identifier contains the correct FW HIK.

[0165] If you replace the boot loader 163 with a new boot loader ( Figure 1 ), the FW HIK derivation key used in the challenge may also change (e.g., because it includes a hash table of the boot loader firmware). Assuming the device passes the challenge, it can then wait for a new flash supply payload via the SPI slave interface (not shown). Through this interface, the chip device 100 receives data from the KMS 307 ( Figure 3) and a new signature payload encrypted with a key similar to the key used in the HIK challenge. At this point, the chip device 100 can verify the supply (by the same method as above), change to the supply device 413 state, and continue functional booting.

[0166] <Fuse Controller>

[0167] Figure 9 is a block diagram of an example embodiment of a fuse control and device state decoder 121 that handles programming of a group of associated fuse macros 900, including OPT (one-time programmable) macros 901a-d. In an example embodiment, fuse shadow registers 915 can redundantly store the bit values ​​of the fuse macros 900. The redundant storage of fuse bits can be set in a manner that provides an additional layer of protection for controlling any test mode or security-sensitive feature. The redundant storage of the bit values ​​of the fuse macros can also include mechanisms for protecting shadow operations from attacks. For example, an attack on the fuse macro latch operation can be detected because the attack can cause all fuse shadow registers 915 to become zero macros even when the fuse macros 900 themselves are not zero.

[0168] In the example fuse controller 121, fuse bits can be programmed via a fuse shadow register 915, where the actual fuse macro is blown internally by the fuse controller. Functions associated with programming the actual fuse 900 and reading the fuse value can be handled by an internal controller 910. Similarly, the fuse controller 121 can include a finite state machine 905 for handling the programming of a specific fuse macro 900. Programming of the fuse macro 900 can be achieved based on commands transmitted to a device state unlock circuit 913 via a serial wire debug port (SWDP) 931. The device state unlock circuit 913 increments the device state stored in the fuse macro to the next device state. A mechanism for setting the device state to a default can be provided by a default parameter save circuit 917 and a logic gate 919, which controls access to the fuse via an interface 935. The processor bus 933 provides a path to read and program the fuse value stored in the fuse shadow register 915.

[0169] Figure 1 、 Figure 2 and Figure 9 Exemplary implementation details of the semiconductor chip device 100 are provided. Figure 10 is a high-level block diagram of an exemplary apparatus (1000) that may include a semiconductor chip device 100, or may be used to implement various components of the semiconductor chip device 100, including one or more of an embedded processor 103, firmware 104, a security coprocessor 131, and an internal controller 910.

[0170] According to at least one embodiment, the digital component / computing device (1000) can be configured to perform various functions to support secure device state and boot flow. As described above, state transitions are controlled by firmware 104 running on chip 100 and can be combined with Figure 4 、 Figure 5 、 Figure 6A and Figure 6B The secure boot flow is controlled by firmware 104 running on chip 100 and can be combined with Figure 8A 、 Figure 8B and Figure 8C The firmware can be Figure 1 A portion of the embedded processor 104 is shown. Figure 10 Further details of the hardware implementation are provided which will be further explained below.

[0171] In a very basic configuration (1001), a computing device (1000) typically includes one or more processors (1010) and a system memory (1020). A memory bus (1030) may be used to communicate between the processors (1010) and the system memory (1020).

[0172] Depending on the desired configuration, the processor (1010) can be of any type, including but not limited to a system on a chip (SoC), a microprocessor (μP), a microcontroller (μC), a digital signal processor (DSP), or any combination thereof. The processor (1010) can include one or more levels of cache, such as a level 1 cache (1011) and a level 2 cache (1012), a processor core (1013), and registers (1014). The processor core (1013) can include an arithmetic logic unit (ALU), a floating point unit (FPU), a digital signal processing core (DSP core), or a combination thereof. A memory controller (1015) can also be used with the processor (1010), or in some embodiments, the memory controller (1015) can be an internal part of the processor (1010).

[0173] Depending on the desired configuration, the system memory (1020) can be of any type, including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or a combination thereof. The system memory (1020) typically includes an operating system (1021), one or more applications (1022), and program data (1024). The application(s) (1022) may include software implementations of the various components of the ROM 107 for supporting the enhanced random number generator according to one or more embodiments described herein. The program data (1024) may include stored instructions that, when executed by one or more processing devices, implement the method(s) for performing the various functions of the ROM 107 described in detail above. In some embodiments, the application(s) (1022) may be configured to run on the operating system (1021) along with the program data (1024).

[0174] The computing device (1000) may have additional features or functionality, and additional interfaces to facilitate communications between the basic configuration (1001) and any desired devices and interfaces.

[0175] The system memory (1020) is an example of computer storage media. Such computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing device 1000. Any such computer storage media may be part of the device (1000).

[0176] The computing device (1000) can be implemented as part of a small portable (or mobile) electronic device, such as a cellular phone, a smartphone, a personal digital assistant (PDA), a personal media player device, a tablet computer (tablet), a wireless web viewing device, a personal head-mounted device, a dedicated device, or a hybrid device that includes any of the above functions. The computing device (1000) can also be implemented as a personal computer, including both laptop computer configurations and non-laptop computer configurations.

[0177] The foregoing detailed description has described various embodiments of devices and / or processes through the use of block diagrams, flow charts, and / or examples. Because such block diagrams, flow charts, and / or examples contain one or more functions and / or operations, those skilled in the art will understand that each function and / or operation within such block diagrams, flow charts, or examples can be implemented individually and / or collectively by a wide range of hardware, software, firmware, or nearly any combination thereof.

[0178] According to at least one embodiment, portions of the subject matter described herein may be implemented via one or more ASICs (Application Specific Integrated Circuits), Field Programmable Gate Arrays (FPGAs), Digital Signal Processors (DSPs), or other integrated formats. However, those skilled in the art will recognize that some aspects of the embodiments disclosed herein may be equivalently implemented, in whole or in part, in an integrated circuit, as one or more computer programs running on one or more computers, as one or more programs running on one or more processors, as firmware, or as nearly any combination thereof, and that designing circuitry and / or writing code for software and / or firmware will be well within the skill of those skilled in the art in light of the present disclosure.

[0179] In addition, those skilled in the art will appreciate that the mechanisms of the subject matter disclosed herein can be distributed as various forms of program products, and that the illustrative embodiments of the subject matter described herein are used regardless of the particular type of non-transitory computer-readable medium. Examples of non-transitory computer-readable media include, but are not limited to, recordable media such as flash drives, hard drives, compact discs (CDs), digital video disks, digital tapes, and computer memories.

[0180] For any plural and / or singular terms used herein, those skilled in the art may convert from the plural to the singular and / or from the singular to the plural as appropriate to the context and / or application. For clarity, various singular / plural permutations may be explicitly stated.

[0181] Thus, specific embodiments of the present subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. Additionally, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing may be beneficial.

[0182] The systems and methods discussed herein do not require the collection or use of user personal information. Where certain embodiments may collect or use personal information about a user (e.g., user data, information about the user's social network, the user's location and time, the user's biometric information, the user's activities, and demographic information), the user may be provided with a means to control whether to collect personal information, whether to store personal information, whether to use personal information, and how to collect, store, and use information about the user. That is, the systems and methods discussed herein collect, store, and / or use user personal information, particularly when receiving explicit authorization from the relevant user to do so. In addition, before storing or using specific data, the specific data may be processed in one or more ways so that personal identification information may be removed. As an example, the user's identity may be processed so that personal identification information cannot be determined. As another example, the user's geographic location may be generalized to a larger area so that the user's specific location cannot be determined.

[0183] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are illustrative and not restrictive, with the true scope and spirit being indicated by the following claims.

Claims

1. A method for supplying a semiconductor chip device, the method comprising: determining that the semiconductor chip device is ready to be provisioned based on a bit pattern stored in a device fuse within the semiconductor chip device; Writing the boot processing code into the non-volatile memory of the semiconductor chip device; Verifying the authenticity of the boot processing code; Use the certificate to create a device initialization key that is used to generate multiple provisioning keys; disabling the certificate used to create the device initialization key used to generate the provisioning key by blowing a device fuse associated with the certificate, wherein blowing the device fuse associated with the certificate prevents an embedded processor of the semiconductor chip device or an external device from accessing the certificate or recreating the device initialization key; exporting the device initialization key to a key management server; obtaining the provisioning key by using the device initialization key and the boot processing code; proving identity to the key management server by providing a device ID and one of the provisioning keys; decrypting the provisioning data using another one of the provisioning keys; as well as Verify that the provisioning data is valid.

2. The method according to claim 1, wherein The non-volatile memory is a flash memory.

3. The method according to claim 1, wherein The device initialization key is stored in firmware readable registers.

4. The method according to claim 1, wherein The provisioning data includes application-specific flash firmware; and The method further includes enabling, by the boot processing code, storage of the application-specific flash firmware in the non-volatile memory.

5. The method according to claim 1, wherein The certificate is contained within the boot processing code.

6. The method according to claim 1, further comprising: In response to determining that the bit pattern corresponds to an unknown pattern, the semiconductor chip device is locked such that ports and memory of the semiconductor chip device are permanently disabled.

7. The method according to claim 1, wherein The boot processing code and the provisioning data are received via a serial peripheral interface.

8. The method according to claim 1, wherein One of the provisioning keys is a device authentication key.

9. The method according to claim 8, wherein The identity is proven by providing the device ID and the device authentication key to the key management server and receiving an acknowledgement from the key management server.

10. The method according to claim 1, wherein The device ID is stored in the device fuse.

11. The method according to claim 1, wherein The provisioning key is obtained through the security co-processor.

12. A semiconductor chip device comprising: fuse; Non-volatile memory; processor; a storage device storing instructions that, when executed by the processor, cause the semiconductor chip device to: determining that the semiconductor chip device is ready to be provisioned based on a bit pattern stored in a device fuse; Writing the boot processing code into the non-volatile memory; Verifying the authenticity of the boot processing code; Use the certificate to create a device initialization key that is used to generate multiple provisioning keys; disabling the certificate used to create the device initialization key used to generate the provisioning key by blowing a device fuse associated with the certificate, the blowing of the device fuse associated with the certificate preventing the processor or an external device from accessing the certificate or recreating the device initialization key; exporting the device initialization key to a key management server; obtaining the provisioning key by using the device initialization key and the boot processing code; proving identity to the key management server by providing a device ID and one of the provisioning keys; decrypting the provisioning data using another one of the provisioning keys; as well as Verify that the provisioning data is valid.

13. The semiconductor chip device according to claim 12, wherein: The non-volatile memory is a flash memory.

14. The semiconductor chip device according to claim 12, wherein: The device ID is maintained in the device fuse.

15. The semiconductor chip device according to claim 12, wherein: The provisioning data includes application-specific flash firmware, wherein the boot processing code enables storage of the application-specific flash firmware in the non-volatile memory.

16. The semiconductor chip device according to claim 12, wherein: The boot processing code is a boot loader.

17. The semiconductor chip device according to claim 12, wherein: The identity is proven by providing the device ID and device authentication key to the key management server and receiving confirmation from the key management server.

18. The semiconductor chip device according to claim 12, wherein: The processor is further configured to, in response to detecting the unknown pattern of the device fuse, lock the semiconductor chip device so that ports and memory of the semiconductor chip device are inaccessible.

19. The semiconductor chip device according to claim 12, wherein: The bit pattern is dispersed in fuse macros of the semiconductor chip device. 20 . The semiconductor chip device according to claim 12 , further comprising a security co-processor, wherein the provisioning key is obtained by the security co-processor.

Images