Secure programming of one-time-programmable (OTP) memories

Abstract

The electronic device may have a plurality of defined life cycle stages and a one-time-programmable (OTP) memory comprising a plurality of life cycle bits, a respective bit pattern of the life cycle bits corresponding to a respective one of the defined life cycle stages. The electronic device may also have boot code stored in the read-only memory and executable by the processor to receive a request to transition from a current life cycle stage to a next life cycle stage, automatically generate a bit pattern corresponding to the next life cycle stage of the plurality of defined life cycle stages in response to the received request, and program the bit pattern corresponding to the next life cycle stage of the plurality of defined life cycle stages into the OTP memory during a time when the OTP memory is not user accessible.

Description

[Technical field]

[0001] (Priority) This application claims priority to U.S. Provisional Patent Application No. 63 / 311,331, filed February 17, 2022, the contents of which are incorporated herein in their entirety.

[0002] FIELD OF THEINVENTION The present disclosure relates to provisioning of electronic devices, and more particularly, to systems and methods for managing the lifecycle of electronic devices through secure programming of the One-Time-Programmable (OTP) memory of the electronic devices. [Background technology]

[0003] Conventional techniques for OTP memory programming of information during the configuration of a device (e.g., a chip) typically provide visibility to the entire configuration memory map, but therefore leave the OTP memory open to attack, e.g., to change the device configuration. Different stages in a typical device life cycle (e.g., including manufacturing, development, and customer programming by a third party) may require access to the OTP memory. Thus, without controlled measures, all OTP areas may be accessible and vulnerable to attack. For example, the factory mode device configuration area may be modified at later stages of the device life cycle that may lock or unlock features not intended for a particular production line.

[0004] The present disclosure provides a non-reversible lifecycle system for secure one-time programming of electronic devices across multiple defined lifecycle stages, however, access to various resources of the electronic device may be constrained based on the current lifecycle stage. Summary of the Invention

[0005] According to an embodiment, the system may include an electronic device. The electronic device may be a server, a device associated with the server, or a computing platform, and the system may be a secure boot controller for the server, a device associated with the server, or a computing platform. The electronic device may have a plurality of defined life cycle stages and may include a one-time programmable (OTP) memory having a plurality of life cycle bits. A bit pattern of each of the plurality of life cycle bits may correspond to a respective life cycle stage of the plurality of defined life cycle stages. The electronic device may also have boot code stored in a read only memory (ROM). The boot code may be executable by a processor to receive a request to transition from a current life cycle stage of the plurality of defined life cycle stages to a next life cycle stage of the plurality of defined life cycle stages. The request to transition from a current life cycle stage of the plurality of defined life cycle stages to a next life cycle stage of the plurality of defined life cycle stages may be received via a physical port of the electronic device or via firmware loaded on the electronic device. According to an embodiment, the request to transition from a current life cycle stage of the plurality of defined life cycle stages to a next life cycle stage of the plurality of defined life cycle stages may be a signed command. The boot code may also be executable to automatically generate a bit pattern corresponding to a next one of the multiple defined life cycle stages in response to the received request, and to program the bit pattern corresponding to the next one of the multiple defined life cycle stages into the OTP memory during a time when the OTP memory is not user accessible.In one embodiment, the time when the OTP memory is not user accessible may be during a subsequent reset of the electronic device, which may be a device reset, reboot, or power cycle of the electronic device. According to one embodiment, boot code programming a bit pattern corresponding to a next lifecycle stage of the multiple defined lifecycle states in the OTP memory may cause a transition from a current lifecycle stage of the multiple defined lifecycle stages to a next lifecycle stage of the multiple defined lifecycle stages.

[0006] In one embodiment, the boot code may automatically generate device-specific information in response to a received request and program the device-specific information into the OTP memory during a time when the OTP memory is not user-accessible.

[0007] In one embodiment, for each lifecycle stage of the plurality of defined lifecycle stages, the boot code may make available to the user a corresponding respective set of available functions that may be executable during each lifecycle stage of the plurality of defined lifecycle stages. According to one embodiment, the respective set of available functions that may be executable during a first lifecycle stage of the plurality of defined lifecycle stages may include the first function, and the respective set of available functions that may be executable during a second lifecycle stage of the plurality of defined lifecycle stages may exclude the first function.

[0008] Another embodiment provides a system that may include an electronic device having an OTP memory, where the OTP memory may include a plurality of life cycle OTP bits. The life cycle bitmap may be associated with a plurality of defined life cycle stages of the electronic device. The life cycle bitmap may specify a plurality of life cycle OTP bit patterns, where each life cycle OTP bit pattern may correspond to a respective life cycle stage of the electronic device. The life cycle function data may specify a set of available functions for each life cycle stage. The specified set of available functions for each life cycle stage may define functions that may be executable during each life cycle stage of the electronic device. The specified set of available functions for each first life cycle stage may be different than the specified set of available functions for each second life cycle stage. An exemplary system may include boot code that may be stored in the read only memory. The boot code may be executable by the processor to manage provisioning of the electronic device through a series of life cycle stages. The boot code may be executable by the processor to selectively program the plurality of life cycle OTP bits over time to advance the electronic device through a series of life cycle stages during times when the OTP memory is not user accessible. The boot code may be executable by the processor to enable access to only a set of available functions for a respective first life cycle stage specified by the life cycle function data while the electronic device is operating in the respective first life cycle stage.

[0009] In one embodiment, the boot code may be executable by the processor to automatically generate device-specific information and program the device-specific information into the OTP memory during a time when the OTP memory is not user-accessible.

[0010] According to one embodiment, the boot code may be executable by the processor to selectively program a number of lifecycle OTP bits over time in response to signed instructions to progress the electronic device through a series of lifecycle stages.

[0011] Another embodiment provides a method for an electronic device having an OTP memory, a plurality of defined life cycles, and a plurality of defined functions. The method may include providing access to a first set of the plurality of defined functions while the electronic device is in a first life cycle stage of the plurality of defined life cycle stages. The method may include receiving a request to transition the electronic device from the first life cycle stage of the plurality of defined life cycle stages to a second life cycle stage of the plurality of defined life cycle stages. In one embodiment, the request to transition the electronic device from the first life cycle stage of the plurality of defined life cycle stages to the second life cycle stage of the plurality of defined life cycle stages may be received via a physical port of the electronic device or via firmware loaded on the electronic device. In one embodiment, the request to transition the electronic device from the first life cycle stage of the plurality of defined life cycle stages to the second life cycle stage of the plurality of defined life cycle stages may be a signed command. The method may include, in response to a received request to transition the electronic device from a first one of the plurality of defined life cycle stages to a second one of the plurality of defined life cycle stages, transitioning the electronic device to a second one of the plurality of defined life cycle stages by programming the OTP memory with information corresponding to the second one of the plurality of defined life cycle stages during a first time period during which the OTP memory is not user accessible. In one embodiment, the time period during which the OTP memory is not user accessible may be during a subsequent reset of the electronic device, which may be a device reset, reboot, or power cycle of the electronic device.The method may include providing access to a second set of the plurality of defined functions while the electronic device is in a second life cycle stage of the plurality of defined life cycle stages. In one embodiment, the first set of the plurality of defined functions may include the first function and the second set of the plurality of defined functions may exclude the first function.

[0012] According to one embodiment, the method may include automatically generating and programming device specific information into the OTP memory during a time when the OTP memory is not user accessible in response to a received request to transition the electronic device from a first one of a plurality of defined life cycle stages to a second one of the plurality of defined life cycle stages.

[0013] In one embodiment, the method may include prohibiting transitioning the electronic device to a first one of the plurality of defined life cycle stages after transitioning the electronic device to a second one of the plurality of defined life cycle stages.

[0014] In one embodiment, the method may include receiving a request to transition the electronic device from a second one of the plurality of defined life cycle stages to a third one of the plurality of defined life cycle stages. The method may include transitioning the electronic device to the third one of the plurality of defined life cycle stages by programming the OTP memory with information corresponding to the third one of the plurality of defined life cycle stages during a second time period during which the OTP memory is not user accessible, in response to the received request to transition the electronic device from the second one of the plurality of defined life cycle stages to the third one of the plurality of defined life cycle stages. The method may include providing access to a third set of the plurality of defined functions while the electronic device is in the third one of the plurality of defined life cycle stages. In one embodiment, the method may include prohibiting transitioning the electronic device to the second one of the plurality of defined life cycle stages after transitioning the electronic device to the third one of the plurality of defined life cycle stages.

[0015] The figures illustrate exemplary methods and systems for managing the lifecycle of an electronic device through secure programming of the electronic device's one-time programmable (OTP) memory. [Brief description of the drawings]

[0016] [Figure 1] 1 illustrates a block diagram of an exemplary system for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Diagram 2] 1 illustrates an exemplary OTP memory that may be used to manage the lifecycle of an electronic device. [Diagram 3]1 illustrates an example of a valid transition from one life cycle stage to another for an electronic device. [Figure 4] 13 shows an example of a lifecycle bitmap for an exemplary set of nine lifecycle OTP bits. [Diagram 5] 1 illustrates an embodiment that uses manufacturer OTP configuration bits for sub-stages of a life cycle stage defined for an electronic device. [Figure 6] 1 illustrates an exemplary command memory. [Figure 7] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 8] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 9a] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 9b] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 9c] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 9d] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 9e] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 9f]1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 10] 13 illustrates a flowchart of additional exemplary operations for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 11] 13 illustrates a flowchart of additional exemplary operations for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 12] 13 illustrates a flowchart of additional exemplary operations for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. [Figure 13] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the OTP memory of the electronic device. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0017] Reference numerals for any illustrated element that appear in different drawings have the same meaning throughout the drawings, and any mention or discussion herein of any illustrated element in the context of any particular drawing also applies to each other drawing in which the same illustrated element appears.

[0018] When an electronic device (e.g., a microcontroller) boots up (e.g., upon power-on or after a hardware or software reset), boot code may be loaded and executed by a processor on the device. The boot code may perform functions related to device startup, such as initializing hardware, which may include disabling interrupts, initializing buses, setting the processor(s) to a particular state, and initializing memory. After performing hardware initialization, the boot code may load system software, for example from an application image. The functions performed by the boot code may be referred to as a boot process.

[0019] An electronic device may be capable of transitioning through various life cycle stages over time. Various features or functions of an electronic device may be available in some life cycle stages and unavailable in other life cycle stages. The features and functions available in a particular life cycle stage may relate to the security of the device. For example, a cryptographic key that may be used to verify code executed on an electronic device may be accessible in one or more life cycle stages but unavailable in other life cycle stages. In another embodiment, a function that may establish or allow for the establishment of secure information for an electronic device may be available in one or more life cycle stages but unavailable in other life cycle stages. In this manner, the level of security of an electronic device at a given time may correspond to the life cycle stage of the electronic device at that time.

[0020] An electronic device may include security mechanisms to protect against malicious attacks on the device, for example, the level of security of an electronic device may correspond to the life cycle stage of the electronic device and may include features to prevent an attacker from changing the life cycle stage of the electronic device.

[0021] Security features for an electronic device may be implemented using boot code on the electronic device. In one embodiment, the security features may be implemented using immutable boot code. Immutable boot code, which may be referred to as a hardware root of trust, may be built into the electronic device during manufacture and therefore may be implicitly trusted because it cannot be altered.

[0022] For purposes of this disclosure, an electronic device may include any means or collection of means operable to compute, classify, process, transmit, receive, search, originate, exchange, store, display, manifest, detect, record, play, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, an electronic device may be a personal computer, a PDA (Personal Digital Assistant), a home electronic device, a server, a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. An electronic device may include one or more processing resources, such as a memory, a Central Processing Unit (CPU), or hardware or software control logic. Additional components of an electronic device may include one or more storage devices, one or more communication ports for communicating with external devices, and various input and output (I / O) devices, such as a keyboard, a mouse, and a video display. An electronic device may also include one or more buses operable to transmit communications between various hardware components.

[0023] 1 illustrates a block diagram of an exemplary system 100 for managing the life cycle of an electronic device 101 through secure programming of the electronic device's OTP memory. As shown in FIG. 1, the system 100 may comprise an electronic device 101. Components of the electronic device 101 may include, but are not limited to, one or more processors 160 and a system bus 121 that communicatively couples various system components to the processor 160, including, for example, an OTP memory 110, a ROM 130, a memory 170, an I / O & port control 190, and a network interface 150. The system bus 121 may be any suitable type of bus structure, such as a memory bus, a peripheral bus, or a local bus using any of a variety of bus architectures.

[0024] Processor 160 may comprise any system, device, or apparatus operable to interpret or execute program instructions or process data, including, but not limited to, a microprocessor, a microcontroller, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), or any other digital or analog circuitry for interpreting or executing program instructions or process data. In some embodiments, processor 160 may interpret or execute program instructions or process data stored locally (e.g., in memory 170, ROM 130, OTP memory 110, or another component of electronic device 101). In the same or alternative embodiments, processor 160 may interpret or execute program instructions or process data stored remotely.

[0025] OTP memory 110 (one-time programmable memory) may comprise any system, device, or apparatus that may be programmed only once and then retain the programmed data. OTP memory 110 may comprise one-time programmable bits 120a, 120b, etc. In one embodiment, bits 120a and 120b of OTP memory 110 may comprise conventional logic gates connected with metal wiring, and the connections may be paired with fuses. During programming, the fuses may be blown to make these connections permanent. In this manner, OTP memory 110, once programmed, may be unmodifiable. In one embodiment, unprogrammed bits (e.g., 120a, 120b) may return a value of 0 when read by processor 160, while programmed bits may return a value of 1 when read by processor 160. According to this embodiment, once bits 120a, 120b are programmed with a value of 1, they cannot be reprogrammed to a value of 0.

[0026] ROM 130 may comprise any system, device, or apparatus (e.g., non-volatile memory) operable to retain program instructions or data after power to electronic device 101 is turned off. ROM 130 (e.g., boot ROM) may comprise boot code 140 that may be used by processor 160 during the boot process (or start-up) of electronic device 101. According to one embodiment, boot code 140 may be immutable, i.e., built into the electronic device during manufacture, and therefore may be implicitly trusted (e.g., hardware root of trust) because it cannot be altered. Boot code 140 code may include code that performs functions, including, but not limited to, functions F1 (145a) and F2 (145b).

[0027] Memory 170 may comprise any system, device, or apparatus operable to retain program instructions or data for a period of time. Memory 170 may include random access memory (RAM, Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM)), Electrically Erasable Programmable Read-Only Memory (EEPROM), PCMCIA card (Personal Computer Memory Card International Association's Card), flash memory, magnetic storage device, magneto-optical storage device, hardware registers, or any suitable selection or array of volatile or non-volatile memory. In the illustrated embodiment, memory 170 includes, but is not limited to, instruction memory 171, flash memory 172, and SRAM 173.

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

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

[0030] 1 illustrates various components of electronic device 101, other example systems may include electronic devices having more or fewer components. In one embodiment, electronic device 101 according to the present disclosure may not include one or all of the components depicted in dashed lines without departing from the spirit and scope of these disclosed embodiments.

[0031] FIG. 2 illustrates an exemplary OTP memory 110 that may be used to manage the life cycle of an electronic device. As shown in FIG. 2, the OTP memory 110 may include various defined regions including life cycle bits 203, manufacturer configuration information 213, customer information 223, and private device specific information 233. In one embodiment, the life cycle bits 203 may be programmed (current interrupted) by the boot code 140 and may cause transitions between different life cycle stages in a defined series of life cycle stages of the electronic device 101. In the same or another embodiment, the manufacturer configuration information 213 may be programmed (current interrupted) by a test machine or other device used by the manufacturer to program the OTP memory 110, for example, during provisioning of the electronic device 101. The manufacturer configuration information 213 may include bits that enable, disable, or configure features on the electronic device 101 (e.g., GPIO pin availability, clock rate, and availability of security features), public keys of public key / crypto key pairs, and device identification information. In one embodiment, the customer information 223 may include bits that are programmed (currently blown off) by the customer of the electronic device 101.

[0032] In one embodiment, secret device specific information 233 may include (a) a device identification key (“DevIK”) (e.g., a private key of a public key / cryptographic key pair) or information from which a DevIK may be generated, (b) critical device configurations, such as image authenticity and key authenticity, (c) other cryptographic keys used by electronic device 101, or (d) other device specific information. In some embodiments, secret device specific information 233 may include (a) a unique device secret (UDS) or an encrypted UDS, or (b) a ROM seed (e.g., a random number generated by boot code 140), which may use such UDS and ROM seed as source data to generate a DevIK or other device specific information.

[0033] <Life cycle stages of electronic devices 101> Electronic device 101 may be capable of transitioning through various life cycle stages over time. In one embodiment, the life cycle stages may be defined by the manufacturer of electronic device 101 and may include, but are not limited to, the life cycle stages shown in Table 1. Table 1 [Table 1]

[0034] In one embodiment, the six lifecycle stages may have the characteristics listed in Tables 2-7. Different functions, features, and operations may be available at the different lifecycle stages, as disclosed in Tables 2-7. An exemplary method for making the functions available is shown in FIG. 13 and associated documents. Table 2 [Table 2]

[0035] Table 3

Table 3

[0036] Table 4

Table 4

[0037] Table 5

Table 5

[0038] Table 6

Table 6

[0039] Table 7

Table 7

[0040] Transitions between lifecycle stages may be linear (e.g., from stage 1 to stage 6), may jump lifecycle stages, or may be a combination of jumping one or more lifecycle stages and simultaneously linear transitions. In one embodiment, the manufacturer of the electronic device 101 may define the allowable transitions. The boot code 140 may enforce the manufacturer-defined allowable transitions by managing the transition of the electronic device 101 through the series of lifecycle stages. FIG. 3 illustrates an example of valid transitions (e.g., manufacturer-defined allowable transitions) from one lifecycle stage to another lifecycle stage with arrows between different lifecycle stages in the series of lifecycle stages 308. For example, from the RAW stage, the device may be limited to transitioning to the MFG stage. From the MFG stage, the device may transition to the DEV stage or may transition to the PROD stage. In some embodiments, the transition from one lifecycle stage to another lifecycle stage is phased and requires a reset (e.g., a device reset, reboot, or power cycle) of the electronic device 101 to effect the transition to the new lifecycle stage. According to one embodiment, the RAW lifecycle stage may correspond to the time the silicon is in transit from the foundry where it was manufactured to the manufacturer (Original Equipment Manufacturer (OEM)). The MFG lifecycle stage may correspond to when the silicon is owned by the manufacturer, for example, during manufacturer provisioning of the device. The remaining lifecycle stages (DEV, PROD, FA, EOL) may correspond to the time the silicon is owned by the customer.

[0041] 4 illustrates an example of a lifecycle bitmap for an example set of nine lifecycle bits (bits 0-8), where, for example, each lifecycle bitmap 203a-203f may correspond to a lifecycle bit 203 in OTP memory 110 of FIG. 2. Lifecycle bitmaps 203a-203f may specify six lifecycle OTP bit patterns (404a-404f) for the nine lifecycle bits, each OTP bit pattern corresponding to a respective defined lifecycle stage in a set of lifecycle stages 408. As shown in this example, lifecycle OTP bit pattern 404a in lifecycle bitmap 203a may correspond to a lifecycle stage RAW shown immediately below lifecycle bitmap 203a. Similarly, lifecycle OTP bit pattern 404b in lifecycle bitmap 203b may correspond to a lifecycle stage MFG shown immediately below lifecycle bitmap 203b. The other illustrated life cycle OTP bit patterns (eg, 404c-404f in life cycle bitmaps 203c-203f) may correspond to the life cycle stages illustrated immediately below them.

[0042] As shown in FIG. 4, life cycle bitmap 203a may correspond to life cycle OTP bit pattern 404a for the RAW life cycle stage (i.e., bits 0 through 8 are not programmed). life cycle bitmap 203b may correspond to life cycle OTP bit pattern 404b for the MFG life cycle stage (i.e., bits 0 and 2 are programmed and bits 1 and 3 through 8 are not programmed). life cycle bitmap 203c may correspond to life cycle OTP bit pattern 404c for the DEV life cycle stage (i.e., bits 0 and 2 through 4 are programmed and bits 1 and 5 through 8 are not programmed). life cycle bitmap 203d may correspond to life cycle OTP bit pattern 404d for the PROD life cycle stage (i.e., bits 0, 2, and 4 through 5 are programmed and bits 1, 3, and 6 through 8 are not programmed). The life cycle bitmap 203e may correspond to the life cycle OTP bit pattern 404e for the FA life cycle stage (i.e., bits 0, 2 through 6, and 8 are programmed, and bits 1 and 7 are not programmed). The life cycle bitmap 203f may correspond to the life cycle OTP bit pattern 404f for the EOL life cycle stage (i.e., bits 0 through 8 are programmed).

[0043] In one embodiment, electronic device 101 may be designed such that boot code 140 may have exclusive write access to lifecycle bits 203. In this manner, boot code 140 may selectively program the lifecycle bits over time, e.g., in response to commands, to advance the electronic device in one direction through a series of lifecycle stages. For example, a transition 410 from the MFG lifecycle stage back to the RAW lifecycle stage after boot code 140 has programmed lifecycle bits 203 with lifecycle OTP bit pattern 404b corresponding to the MFG lifecycle stage may be prohibited because it is not possible to "unprogram" lifecycle bits 0 and 2 (OTP memory may be permanently programmed). Thus, as illustrated by the exemplary lifecycle OTP bit patterns 404a-404f in lifecycle bitmap 203c-203f, electronic device 101 may be restricted to progressing through the lifecycle stages in one direction, i.e., from left to right in FIG. 4.

[0044] FIG. 5 illustrates an example embodiment using manufacturer OTP configuration bits for sub-stages of a lifecycle stage defined for electronic device 101. For example, a manufacturer may wish to provision an electronic device in stages to restrict access to certain features or functions of the electronic device during provisioning. In the illustrated example, the manufacturer may define sub-stages 515 (MFG0, MFG1, and MFG3) that may each correspond to a unique state of manufacturer OTP configuration bits in 513a-513c. In this example, lifecycle OTP bit patterns 404a-404f in lifecycle bitmaps 203a-203f may correspond to those shown in FIG. 4. Similarly, the defined lifecycle stages in the set of lifecycle stages 508 may correspond to the defined lifecycle stages in 408, except that sub-stage 515 corresponds to the MFG stage in 408. Thus, while the electronic device is in the MFG life cycle stage (life cycle OTP bit pattern 404b, life cycle bitmap 203b), sub-stage 515 may be defined by programming the manufacturer OTP configuration bits stored in the manufacturer configuration information 213 of the OTP memory 110 (FIG. 2). In one embodiment, the electronic device 101 may be designed such that the boot code 140 may have exclusive write access to the manufacturer OTP configuration bits in the manufacturer configuration information 213. In another embodiment, the electronic device 101 may be designed such that other code (manufacturer code) may have write access to the manufacturer OTP configuration bits in the manufacturer configuration information 213. In yet another embodiment, the manufacturer may program the manufacturer OTP configuration bits in the manufacturer configuration information 213 via external hardware (e.g., a JTAG debug interface). As shown, sub-stage 515 may be limited to proceeding in one direction since it is not possible to "unprogram" the manufacturer OTP configuration bits (OTP memory may be permanently programmed).

[0045] While FIG. 5 illustrates an example of defining sub-stages for the MFG lifecycle stage, a similar approach may be used to define sub-stages for other lifecycle stages of an electronic device. For example, a customer may want a development sub-stage (DEV lifecycle stage) to restrict access to certain features or functions of the electronic device. To accomplish this, the customer may define customer configuration bits in the customer information 223 of the OTP memory 110 to define the sub-stage (e.g., similar to sub-stage 515). The customer configuration bits may be used by the customer code to restrict access to certain features or functions of the electronic device.

[0046] 6 illustrates an exemplary command memory 171. Command memory 171 may comprise rewritable memory (e.g., registers) and may include life cycle request bits 682, command area 684, and command parameter area 686. In one embodiment, life cycle request bits 682, command area 684, and command parameter area 686 may be used (individually or in any combination) to initiate requests to be processed by boot code 140. In one embodiment, command memory 171 may be user accessible such that code other than boot code 140 (e.g., manufacturer code, customer code) may initiate requests to be processed by boot code 140. In another embodiment, command memory 171 may be accessed via external hardware (e.g., a JTAG debug interface, a UART interface, an I2C interface).

[0047] In one embodiment, the lifecycle request bit 682, when set, may correspond to a request to transition the electronic device 101 from a current lifecycle stage to the next lifecycle stage. In the same or another embodiment, the command field 684 may be programmed with commands corresponding to functions that the boot code 140 may perform (e.g., functions F1, F2 shown as 145a and 145b in FIG. 1). The command parameter field 686 may be programmed with parameters corresponding to the commands programmed in field 684.

[0048] FIG. 7 illustrates a flow chart of an example method 700 for managing the life cycle of an electronic device through secure programming of the electronic device's OTP memory. According to one embodiment, method 700 may begin at block 710. In one embodiment, method 700 may be performed by boot code 140. In some embodiments, start block 710 may represent the time when electronic device 101 is first powered on or the time following a reset of the electronic device (e.g., a device reset, reboot, or power cycle). Thus, method 700 may be performed by boot code 140 when OTP memory 110 is not user accessible (e.g., because user code has not yet been loaded). The teachings of the present disclosure may be performed in various configurations of system 100. Thus, the initialization point of method 700 and the order of steps 710-760 that make up method 700 may depend on the implementation selected.

[0049] At block 720, the boot code may determine the current life cycle stage (LCS) of the electronic device 101 by reading the life cycle bit 203 from the OTP memory 110. At block 730, the boot code may determine whether there is a pending life cycle request, for example, by checking whether the life cycle request bit 682 in the command memory 171 is set. If there is no pending life cycle request, the boot code may proceed to block 740 and perform an operation appropriate for the current life cycle stage. If at block 730, the boot code determines that a life cycle request is pending, the boot code may proceed to block 750. At block 750, the boot code may program the life cycle bit 203 with a life cycle OTP bit pattern (e.g., 404a-404f of FIG. 4) corresponding to the next life cycle stage. Following programming, the boot code may proceed to block 760 and transition to the next life cycle stage.

[0050] Although FIG. 7 discloses a particular number of operations associated with method 700, method 700 may be performed with more or less operations than those depicted in FIG. 7. For example, prior to block 750, the boot code may determine the next life cycle stage, for example, based on the OTP configuration bits. Also, prior to block 750, the boot code may generate a life cycle bit pattern that corresponds to the next life cycle stage. In another embodiment, at block 760, the boot code may cause a transition to the next life cycle stage by forcing a reset of electronic device 101. It is noted that although FIG. 7 discloses a particular order of operations performed with respect to method 700, the operations comprising method 700 may be completed in any suitable order.

[0051] FIG. 8 illustrates a flow chart of an example method 800 for managing the life cycle of an electronic device through secure programming of the electronic device's OTP memory. According to one embodiment, method 800 may begin at block 810. In one embodiment, method 800 may be performed by boot code 140. In some embodiments, start block 810 may represent the time when electronic device 101 is first powered on or the time following a reset of the electronic device (e.g., a device reset, reboot, or power cycle). Thus, method 800 may be performed by boot code 140 when OTP memory 110 is not user-accessible (e.g., because user code has not yet been loaded). The teachings of the present disclosure may be performed in various configurations of system 100. Thus, the initialization point of method 800 and the order of steps 810-850 that make up method 800 may depend on the implementation selected.

[0052] In method 800, blocks 810, 815, and 820 may correspond to blocks 710, 720, and 730, respectively, except that if the boot code determines in block 820 that there is a pending lifecycle request, it may proceed to block 830, where the boot code determines whether a secure lifecycle request is required. In some embodiments, the manufacturer may desire secure programming of the OTP lifecycle bits 203 so that a malicious user cannot trigger an irreversible lifecycle transition. According to these embodiments, the boot code may request the user to provide a signed lifecycle request command, which may be signed with a cryptographic key of the public key pair. The boot code may access the other half of the key pair to verify the signed command. If in block 830, the boot code determines that a secure lifecycle request is not required, it may proceed to blocks 835 and 850, which may correspond to blocks 750 and 760, respectively, of method 700.

[0053] If in block 830 the boot code determines that a secure lifecycle request is required, the boot code may proceed to block 840 and receive a signed lifecycle request from the user. The command may be received from command area 684 from command memory 171 shown in FIG. 6. The command may include parameters from command parameter area 686. As described with respect to FIG. 6, the user may write a secure lifecycle request command to command memory 171 via firmware (e.g., customer code) or via a physical interface (e.g., JTAG debug interface, UART interface, I2C interface). After receiving the signed lifecycle request in block 840, the boot code may proceed to block 845. In block 845, the boot code may verify the signed lifecycle request, for example, by using a private encryption key that is the second half of the key pair that the user used to sign the request. If the boot code verifies the request, it may proceed to block 835 (and then 850), as described above. If the signed lifecycle request fails verification, the boot code may proceed to block 825, where the current lifecycle stage resumes without transitioning to the next lifecycle stage.

[0054] Although FIG. 8 discloses a particular number of operations associated with method 800, method 800 may be performed with more or less operations than those shown in FIG. 8. For example, if the signed lifecycle request fails verification at block 845, the boot code may return to block 840, thereby allowing the user to make a second attempt at requesting a signed lifecycle request command. In another embodiment, the boot code may allow a limited number of attempts (e.g., for a predetermined amount of time) before locking the command memory. In some embodiments, additional operations described with respect to method 700 may be performed in method 800 as well. It is noted that although FIG. 8 discloses a particular order of operations performed with respect to method 800, the operations comprising method 800 may be completed in any suitable order.

[0055] 9a-9f show a flow chart of an example method 900 for managing the life cycle of an electronic device through secure programming of the electronic device's OTP memory. According to one embodiment, the method 900 may begin at block 902 of FIG. 9a. In one embodiment, the method 900 may be executed by the boot code 140. In some embodiments, the start block 902 may represent the time when the electronic device 101 is first powered on or the time following a reset of the electronic device (e.g., a device reset, reboot, or power cycle). Thus, the method 900 may be executed by the boot code 140 when the OTP memory 110 is not user-accessible (e.g., because user code has not yet been loaded). The teachings of the present disclosure may be implemented in various configurations of the system 100. Thus, the initialization point of the method 900 and the order of steps 902-984 that make up the method 900 may depend on the implementation selected.

[0056] In block 904, the boot code may determine the current life cycle stage (LCS) of the electronic device 101. In block 906, the boot code may determine whether the LCS is a RAW life cycle stage. If so, the boot code may proceed to block 908 and stop executing the code. For example, by stopping execution of the code, the boot code may not load a code image such that no features or capabilities are enabled on the electronic device. This functionality may prevent theft of silicon while it is being shipped from the foundry to the manufacturer (e.g., the RAW life cycle stage of FIG. 3). If the boot code determines in block 906 that the current LCS is not a RAW life cycle stage, the boot code may proceed to block 910 (continued in FIG. 9b). In this embodiment, the boot code may not be able to cause a transition from the RAW LCS to the MFG LCS. A manufacturer may use an external tester to cause a transition from the RAW LCS to the MFG LCS and program a lifecycle OTP bit pattern (e.g., 404b in FIG. 4) corresponding to the MFG LCS into the lifecycle bits 203 in the OTP memory 110. In other embodiments, the boot code 104 may program a lifecycle OTP bit pattern (e.g., 404b) corresponding to the MFG LCS into the lifecycle bits 203 in the OTP memory 110, for example, in response to determining that one or more external pins (e.g., 180-1, 180-2, ... 180-N in FIG. 1) are in a predetermined state.

[0057] FIG. 9b begins at block 910 and may proceed to block 912. In block 912, the boot code may determine whether the LCS is in the MFG lifecycle stage. If so, the boot code may proceed to block 914, where it may determine whether there is a pending lifecycle request (e.g., as described with respect to FIGS. 7 and 8). If there is no pending lifecycle request, the boot code may proceed to block 916, where the current MFG lifecycle stage resumes without transitioning to another lifecycle stage. If in block 914, the boot code determines that there is a pending lifecycle request, the boot code may proceed to block 918. In block 918, the boot code may determine whether the JTAG functionality of the electronic device 101 is disabled. In one embodiment, the boot code may make this determination by reading configuration information from the manufacturer's configuration information area 213 of the OTP memory 110. In this embodiment, the manufacturer may determine that a transition from the MFG LCS to the PROD LCS is permissible if JTAG is disabled. Therefore, the boot code may enforce this restriction at block 918.

[0058] If it is determined that JTAG is invalid, the boot code may proceed to block 920. In block 920, the boot code may generate a PROD life cycle OTP bit pattern (e.g., 404d in FIG. 4). The boot code may then proceed to block 922 and program the OTP life cycle bits 203 in the OTP memory 110 with the PROD life cycle OTP bit pattern (e.g., 404d). The boot code may then proceed to block 924 and transition to the PROD LCS. In one embodiment, in block 924, the boot code may cause the transition to the PROD life cycle stage by forcing a reset of the electronic device 101. In block 924, the boot code may perform other operations corresponding to the transition to the PROD life cycle stage (e.g., as shown in FIG. 12).

[0059] If, at block 918, it is determined that JTAG has not been disabled, the boot code may proceed to block 926. At block 926, the boot code may generate a DEV lifecycle OTP bit pattern (e.g., 404c in FIG. 4). The boot code may then proceed to block 928 and program the OTP lifecycle bits 203 in the OTP memory 110 with the DEV lifecycle OTP bit pattern (e.g., 404c). The boot code may then proceed to block 930 and transition to the DEV LCS. In one embodiment, at block 930, the boot code may cause the transition to the DEV lifecycle stage by forcing a reset of the electronic device 101. At block 930, the boot code may perform other operations corresponding to the transition to the DEV lifecycle stage.

[0060] If, in block 912, the boot code determines that the LCS is not in the MFG lifecycle stage, the boot code may proceed to block 932 (continued in FIG. 9c).

[0061] FIG. 9c begins at block 932 and may proceed to block 934. In block 934, the boot code may determine whether the LCS is in the DEV lifecycle stage. If so, the boot code may proceed to block 936, where it may determine whether there is a pending lifecycle request (e.g., as described with respect to FIG. 7 and FIG. 8). If there is no pending lifecycle request, the boot code may proceed to block 938, where the current DEV lifecycle stage resumes without transitioning to another lifecycle stage. If, in block 936, the boot code determines that there is a pending lifecycle request, the boot code may proceed to block 940. Blocks 940 and 942 may operate similarly to blocks 840 and 845 of FIG. 8. In this embodiment, transitioning from the DEV LCS to either the FA or EOL LCS may require a secure lifecycle request, which may be a signed lifecycle FA / EOL command. In one embodiment, validation of the received request / command may proceed as described with respect to block 845 of FIG. 8. In other embodiments, validation of the received request / command may proceed as shown in Figures 10 and 11. If validation of the received request / command (at block 942) fails, the boot code may proceed to block 938. In other embodiments (not shown), the boot code may proceed to block 940 to receive additional signed lifecycle FA / EOL command attempts.

[0062] If validation (at block 942) of the received request / command is successful, the boot code may proceed to block 944. In block 944, the boot code may determine whether the signed lifecycle FA / EOL command indicated a transition to a FA LCS or EOL. For example, the signed lifecycle FA / EOL command may originate from command memory 171 and may include command parameters 686 that may indicate which transition is desired. In other embodiments, configuration information in OTP memory 110 (e.g., in manufacturer configuration information area 213 or customer information area 223) may indicate which transition is desired.

[0063] If the boot code determines in block 944 to transition to the FA LCS, the boot code may proceed to block 952. In block 952, the boot code may generate an FA lifecycle OTP bit pattern (e.g., 404e in FIG. 4). The boot code may then proceed to block 954 and program the OTP lifecycle bits 203 in the OTP memory 110 with the FA lifecycle OTP bit pattern (e.g., 404e). The boot code may then proceed to block 956 and transition to the FA LCS. In one embodiment, in block 956, the boot code may cause the transition to the FA lifecycle stage by forcing a reset of the electronic device 101. In block 956, the boot code may perform other operations (not shown) corresponding to the transition to the FA lifecycle stage. In one embodiment, the boot code may effectively erase all secrets stored in the OTP memory (e.g., by programming all bits in the OTP memory) and erase all memory. In this example, the customer may be returning parts to the manufacturer for failure analysis and does not want the manufacturer to have access to the customer's secrets.

[0064] If the boot code determines to transition to the EOL LCS at block 944, the boot code may proceed to block 946. At block 946, the boot code may generate an EOL lifecycle OTP bit pattern (e.g., 404f in FIG. 4). The boot code may then proceed to block 948 and program the OTP lifecycle bits 203 in the OTP memory 110 with the EOL lifecycle OTP bit pattern (e.g., 404f). The boot code may then proceed to block 950 and transition to the EOL LCS. In one embodiment, at block 950, the boot code may cause the transition to the EOL lifecycle stage by forcing a reset of the electronic device 101. At block 950, the boot code may perform other operations (not shown) corresponding to the transition to the EOL lifecycle stage. In one embodiment, the boot code effectively erases all secrets stored in the OTP memory (e.g., by programming all bits in the OTP memory), and may erase all memory such that the part does not need to be physically destroyed to protect manufacturer and customer secrets.

[0065] If, in block 934, the boot code determines that the LCS is not in the DEV lifecycle stage, the boot code may proceed to block 958 (continued in FIG. 9d).

[0066] FIG. 9d begins at block 958 and may proceed to block 960. In block 960, the boot code may determine whether the LCS is in the PROD lifecycle stage. If so, the boot code may proceed to block 962, where it may determine whether there is a pending lifecycle request (e.g., as described with respect to FIGS. 7 and 8). If there is no pending lifecycle request, the boot code may proceed to block 964, where the current PROD lifecycle stage resumes without transitioning to another lifecycle stage. If the boot code determines at block 962 that there is a pending lifecycle request, the boot code may proceed to block 966. Blocks 966 and 968 may operate similarly to blocks 840, 940, and 845, 942 (in FIGS. 8 and 9c, respectively), except that if the verification fails at block 968, the boot code may proceed to block 964. Blocks 944, 946, 948, 950, 952, 954, and 956 of FIG. 9d are described in the same numbered blocks of FIG. 9c.

[0067] If, in block 960, the boot code determines that the LCS is not in the PROD lifecycle stage, the boot code may proceed to block 970 (continued in FIG. 9e).

[0068] FIG. 9e begins at block 970 and may proceed to block 972. In block 972, the boot code may determine whether the LCS is in the FA lifecycle stage. If so, the boot code may proceed to block 974, where it may determine whether there is a pending lifecycle request (e.g., as described with respect to FIGS. 7 and 8). If there is no pending lifecycle request, the boot code may proceed to block 976, where the current FA lifecycle stage resumes without transitioning to another lifecycle stage. If in block 974 the boot code determines that there is a pending lifecycle request, the boot code may proceed to block 978. Blocks 978 and 980 may operate similarly to blocks 840, 940, 966, and blocks 845, 942, 968 (in FIGS. 8, 9c, and 9d, respectively), except that if the verification fails in block 980, the boot code may proceed to block 976. Blocks 946, 948, and 950 of FIG. 9e are described with the same numbered blocks in FIG. 9c.

[0069] If, in block 972, the boot code determines that the LCS is not in the FA lifecycle stage, the boot code may proceed to block 978 (continued in FIG. 9f).

[0070] FIG. 9f may begin at block 978 and proceed to block 980. In block 980, the boot code may determine whether the LCS is an EOL lifecycle stage. If so, the boot code may proceed to block 982 and stop executing the code. For example, by stopping execution of the code, the boot code may not load a code image so that no features or capabilities are enabled on the electronic device. This may be a desired outcome for parts that have reached end of life (EOL). If in block 980 the boot code determines that the LCS is not an EOL lifecycle stage, the boot code may proceed to block 984. As shown, block 984 may be an LCS error condition because the LCS does not match any of the six defined lifecycle stages of the electronic device 101, for example. Alternatively, because an error condition is not expected, the boot code may return from block 984 to block 902 of FIG. 9a and re-execute method 900.

[0071] Although Figures 9a-9f disclose a particular number of operations associated with method 900, method 900 may be performed with more or fewer operations than those depicted in Figures 9a-9f, such as those described above and other operations. Figures 10-12 provide additional examples of method 900 having more operations than those depicted in Figures 9a-9f. It is noted that although Figures 9a-9f disclose a particular order of operations performed with respect to method 900, the operations comprising method 900 may be completed in any suitable order.

[0072] FIG. 10 illustrates a flow chart of additional exemplary operations of a method 900 for managing the life cycle of an electronic device through secure programming of the OTP memory of the electronic device. FIG. 10 illustrates an example of additional operations that the boot code 140 may perform when receiving and verifying a signed life cycle FA / EOL command as described with respect to blocks 940, 966, 978, and 942, 968, and 980 of FIG. 9c, 9d, and 9e. In this example, the manufacturer may enhance security associated with the transition to the FA or EOL life cycle stage. Thus, blocks 940, 966, 978, and 942, 968, and 980 of FIG. 9c, 9d, and 9e may be replaced with blocks 986-994 and blocks 942, 968, and 980 of FIG. 10.

[0073] At block 986, the boot code may receive a request for Device Unique Data (DUD). At block 988, the boot code may obtain or generate the requested DUD. In one embodiment, the DUD may include a random number. In another embodiment, the DUD may include a serial number or other secret device unique information 233 that may be stored in the OTP memory 110 (see FIG. 2). At block 990, the boot code may transmit the DUD to the user, for example, via a physical interface (e.g., a JTAG debug interface, a UART interface, an I2C interface). At block 992, the boot code may receive a signed lifecycle FA / EOL command that includes the DUD previously transmitted at block 990. At block 994, the boot code may verify the signed lifecycle FA / EOL command that includes the DUD. In one embodiment, a lifecycle FA / EOL command that does not include a DUD may fail verification, thus enhancing the security of the electronic device.

[0074] Although Figure 10 discloses a particular number of operations associated with method 900, method 900 may be performed with more or fewer operations than those depicted in Figure 10 (e.g., as shown in Figure 11). It is noted that although Figure 10 discloses a particular order of operations performed with respect to method 900, the operations comprising method 900 may be completed in any suitable order.

[0075] FIG. 11 illustrates a flowchart of additional exemplary operations of a method 900 for managing the life cycle of an electronic device through secure programming of the electronic device's OTP memory. FIG. 11 illustrates the same operations as FIG. 10 with the addition of block 996. In block 996, the boot code may implement a timeout period and determine whether the period has elapsed. The timeout period may begin to execute after the boot code sends a DUD in block 990. If the timeout period elapses before the boot code receives a signed life cycle FA / EOL command that includes a DUD (block 992), the boot code may proceed as if the signed command failed verification. Thus, a user wishing to cause a transition to either the FA or EOL life cycle stage may be required to start the process again, including requesting a DUD in block 986.

[0076] FIG. 12 illustrates a flow chart of additional exemplary operations of a method 900 for managing the life cycle of an electronic device through secure programming of the OTP memory of the electronic device. FIG. 12 illustrates an example of additional operations that the boot code 140 may perform between blocks 922 and 924 of FIG. 9b. In this example, the boot code may proceed from block 922 to block 923. In block 923, the boot code may generate device specific information. In block 925, the boot code may program the OTP memory 110 with the device specific information generated in block 923. In one example, the device specific information may be a public encryption key, a ROM seed, or other device specific information. Although shown operating between blocks 922 and 924, in one example, blocks 923 and 925 may operate between blocks 928 and 930 (FIG. 9b).

[0077] FIG. 13 illustrates a flow chart of an example method 1300 for managing the life cycle of an electronic device through secure programming of the OTP memory of the electronic device. In one embodiment, the electronic device 101 may include life cycle function data that specifies a set of available functions for each life cycle stage. The specified set of available functions for each life cycle stage defines the functions that may be executed during each life cycle stage of the electronic device. In FIG. 13, the boot code may receive a command at block 1302. In one embodiment, the command may be received from command memory 171 (e.g., FIG. 6). In block 1304, the boot code may determine whether the received command is a signed life cycle FA / EOL command. If so, the boot code may proceed to block 1306, where the boot code determines whether the current life cycle stage is either DEV LCS or PROD LCS. If so, the boot code may proceed to block 1310 and process the received command. If the current life cycle stage is not DEV or PROD, the boot code may proceed to block 1308 and ignore the received command. In this manner, the boot code may specify a set of functions available for each lifecycle stage. In this embodiment, the signed lifecycle FA / EOL directives are not available in the RAW, MFG, FA, or EOL lifecycle stages. Thus, while the electronic device is operating in each lifecycle stage, the boot code may restrict the functions available to that respective lifecycle stage as defined by the lifecycle function data.

[0078] Methods 700-1300 may be performed using system 100 or any other system operable to perform methods 700-1300. Although examples have been described above, other variations and embodiments may be made from this disclosure without departing from the spirit and scope of these disclosed embodiments.

Claims

1. 1. A system comprising: an electronic device having a plurality of defined life cycle stages, the electronic device including a One-Time-Programmable (OTP) memory having a plurality of life cycle bits, a bit pattern of each of the plurality of life cycle bits corresponding to a respective one of the plurality of defined life cycle stages; a boot code stored in a read only memory, receiving a request to transition from a current life cycle stage of the plurality of defined life cycle stages to a next life cycle stage of the plurality of defined life cycle stages; and boot code executable by a processor to: in response to the received request, automatically generate a bit pattern corresponding to the next one of the plurality of defined life cycle stages; and program the bit pattern corresponding to the next one of the plurality of defined life cycle stages into the OTP memory during a time when the OTP memory is not user accessible.

2. 2. The system of claim 1, wherein the boot code executable by the processor to automatically generate and program the bit pattern corresponding to the next one of the plurality of defined life cycle stages in the OTP memory during a time when the OTP memory is not user accessible includes boot code executable by the processor to automatically generate and program the bit pattern corresponding to the next one of the plurality of defined life cycle stages in the OTP memory during a subsequent reset of the electronic device.

3. The system of claim 2 , wherein the subsequent reset of the electronic device comprises a device reset, a reboot, or a power cycle of the electronic device.

4. 4. The system of claim 1, wherein the boot code programming the bit pattern corresponding to the next life cycle stage of the plurality of defined life cycle stages in the OTP memory causes a transition from the current life cycle stage of the plurality of defined life cycle stages to the next life cycle stage of the plurality of defined life cycle stages.

5. 5. The system of claim 1, wherein the boot code is executable by the processor to automatically generate device specific information in response to the received request, and to program the device specific information into the OTP memory during the time when the OTP memory is not user accessible.

6. 6. The system of claim 1, wherein for each life cycle stage of the plurality of defined life cycle stages, a corresponding respective set of available functions executable during the respective life cycle stage of the plurality of defined life cycle stages is made available to the user by the boot code.

7. the respective set of available functions executable during a first lifecycle stage of the plurality of defined lifecycle stages includes a first function; The system of claim 6 , wherein the respective set of available functions executable during a second of the plurality of defined life cycle stages excludes the first function.

8. 8. The system of claim 1, wherein the request to transition from a current one of the plurality of defined lifecycle stages to a next one of the plurality of defined lifecycle stages is received via a physical port of the electronic device or via firmware loaded on the electronic device.

9. 9. The system of claim 1, wherein the request to transition from a current one of the plurality of defined life cycle stages to a next one of the plurality of defined life cycle stages includes a signed command.

10. The system of any one of claims 1 to 9, wherein the electronic device comprises a server, a device associated with a server, or a computing platform, and the system comprises a secure boot controller for the server, a device associated with the server, or a computing platform.

11. 1. A system comprising: an electronic device having a one-time programmable (OTP) memory, the OTP memory including a plurality of lifecycle OTP bits; a lifecycle bitmap associated with a plurality of defined lifecycle stages of the electronic device, the lifecycle bitmap specifying a plurality of lifecycle OTP bit patterns, each corresponding to a respective lifecycle stage of the electronic device; life cycle function data specifying, for each life cycle stage, a set of available functions; the specified set of available functions for each lifecycle stage defines functions executable during the respective lifecycle stage of the electronic device; the designated set of available functions for each first life cycle stage is different from the designated set of available functions for each second life cycle stage; boot code stored in a read only memory and executable by a processor to manage the provisioning of the electronic device through a series of life cycle stages; selectively programming the plurality of life cycle OTP bits over time to progress the electronic device through the sequence of life cycle stages during times when the OTP memory is not user accessible; and while the electronic device is operating in the respective first life cycle stage, enabling access to only the set of available functions for the respective first life cycle stage as specified by the life cycle function data.

12. 12. The system of claim 11, further comprising: the boot code executable by the processor to automatically generate device specific information and program the device specific information into the OTP memory during a time when the OTP memory is not user accessible.

13. 13. The system of claim 11, further comprising: a boot code executable by the processor to selectively program the plurality of life cycle OTP bits over time to advance the electronic device through the series of life cycle stages, the boot code executable by the processor to selectively program the plurality of life cycle OTP bits over time to advance the electronic device through the series of life cycle stages in response to a signed command.

14. 1. A method comprising: For an electronic device having a one-time programmable (OTP) memory, a plurality of defined life cycle stages, and a plurality of defined functions, providing access to a first set of the plurality of defined functions while the electronic device is in a first life cycle stage of the plurality of defined life cycle stages; receiving a request to transition the electronic device from the first one of the plurality of defined life cycle stages to a second one of the plurality of defined life cycle stages; in response to the received request to transition the electronic device from the first one of the plurality of defined life cycle stages to the second one of the plurality of defined life cycle stages, transitioning the electronic device to the second one of the plurality of defined life cycle stages by programming the OTP memory with information corresponding to the second one of the plurality of defined life cycle stages during a first time when the OTP memory is not user accessible; and providing access to a second set of the plurality of defined functions while the electronic device is in the second one of the plurality of defined life cycle stages.

15. 15. The method of claim 14, wherein programming the OTP memory during the first time when the OTP memory is not user-accessible comprises programming the OTP memory during a subsequent reset of the electronic device.

16. The method of any one of claims 14 to 15, wherein the subsequent reset of the electronic device comprises a device reset, a reboot, or a power cycle of the electronic device.

17. 17. The method of claim 14, further comprising: in response to the received request to transition the electronic device from the first one of the plurality of defined life cycle stages to the second one of the plurality of defined life cycle stages, automatically generating device specific information during the time when the OTP memory is not user accessible, and programming the same into the OTP memory.

18. the first set of the plurality of defined functions includes a first function; The method of any one of claims 14 to 17, wherein the second set of the plurality of defined functions excludes the first function.

19. 19. The method of claim 14, further comprising the step of prohibiting transition of the electronic device to the first of the plurality of defined life cycle stages after transitioning the electronic device to the second of the plurality of defined life cycle stages.

20. 20. The method of any one of claims 14 to 19, wherein the request to transition the electronic device from the first lifecycle stage of the plurality of defined lifecycle stages to the second lifecycle stage of the plurality of defined lifecycle stages is received via a physical port of the electronic device or via firmware loaded on the electronic device.

21. 21. The method of claim 14, wherein the request to transition the electronic device from the first one of the plurality of defined life cycle stages to the second one of the plurality of defined life cycle stages comprises a signed command.

22. receiving a request to transition the electronic device from the second one of the plurality of defined life cycle stages to a third one of the plurality of defined life cycle stages; in response to the received request to transition the electronic device from the second one of the plurality of defined life cycle stages to the third one of the plurality of defined life cycle stages, transitioning the electronic device to the third one of the plurality of defined life cycle stages by programming the OTP memory with information corresponding to the third one of the plurality of defined life cycle stages during a second time when the OTP memory is not user accessible; and providing access to a third set of the plurality of defined functions while the electronic device is in the third lifecycle stage of the plurality of defined lifecycle stages.

23. 23. The method of claim 22, comprising prohibiting the electronic device from transitioning to the second one of the plurality of defined life cycle stages after transitioning the electronic device to the third one of the plurality of defined life cycle stages.

Images