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 THE INVENTION 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 their One-Time-Programmable (OTP) memory. [Background technology]

[0003] Conventional techniques for programming OTP memory with information during the configuration of a device (e.g., a chip) typically provide visibility into the entire configuration memory map, thus leaving the OTP memory open to attack, e.g., to change the device configuration. Different stages in a typical device lifecycle (e.g., including manufacturing, development, and customer programming by a third party) may require access to the OTP memory. Thus, without controlled means, all OTP areas may be accessible and vulnerable to attack. For example, the factory-mode device configuration area may be modified at later stages in the device lifecycle, which can 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, where access to various resources of the electronic device may be restricted based on the current lifecycle stage. Summary of the Invention

[0005] According to one embodiment, a 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 lifecycle stages and may include a one-time programmable (OTP) memory having a plurality of lifecycle bits. A bit pattern of each of the plurality of lifecycle bits may correspond to a respective lifecycle stage of the plurality of defined lifecycle 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 lifecycle stage of the plurality of defined lifecycle stages to a next lifecycle stage of the plurality of defined lifecycle stages. The request to transition from a current lifecycle stage of the plurality of defined lifecycle stages to a next lifecycle stage of the plurality of defined lifecycle stages may be received via a physical port of the electronic device or via firmware loaded on the electronic device. According to one embodiment, the request to transition from a current lifecycle stage of the plurality of defined lifecycle stages to a next lifecycle stage of the plurality of defined lifecycle stages may be a signed command. The boot code may also be executable to automatically generate a bit pattern corresponding to a next life cycle stage of the plurality of defined life cycle stages in response to a received request, and to 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.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 plurality of defined lifecycle states in the OTP memory may cause a transition from a current lifecycle stage of the plurality of defined lifecycle stages to a next lifecycle stage of the plurality of 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 multiple lifecycle OTP bits. The lifecycle bitmap may be associated with multiple defined lifecycle stages of the electronic device. The lifecycle bitmap may specify multiple lifecycle OTP bit patterns, each corresponding to a respective lifecycle stage of the electronic device. The lifecycle function data may specify a set of available functions for each lifecycle stage. The specified set of available functions for each lifecycle stage may define functions that may be executable during each lifecycle stage of the electronic device. The specified set of available functions for each first lifecycle stage may be different from the specified set of available functions for each second lifecycle stage. An exemplary system may include boot code that may be stored in read-only memory. The boot code may be executable by the processor to manage provisioning of the electronic device through a series of lifecycle stages. The boot code may be executable by the processor to selectively program the multiple lifecycle OTP bits over time to advance the electronic device through a series of lifecycle 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 the respective first lifecycle stage specified by the lifecycle function data while the electronic device is operating in the respective first lifecycle 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 times when the OTP memory is not user-accessible.

[0010] According to one embodiment, the boot code may be executable by a processor to selectively program a plurality of lifecycle OTP bits over time in response to signed commands 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 lifecycle stages, 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 lifecycle stage of the plurality of defined lifecycle stages. The method may include receiving a request to transition the electronic device from the first lifecycle stage of the plurality of defined lifecycle stages to a second lifecycle stage of the plurality of defined lifecycle stages. In one embodiment, 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 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 lifecycle stage of the plurality of defined lifecycle stages to the second lifecycle stage of the plurality of defined lifecycle 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 lifecycle stages to a second one of the plurality of defined lifecycle stages, transitioning the electronic device to a second one of the plurality of defined lifecycle stages by programming the OTP memory with information corresponding to the second one of the plurality of defined lifecycle stages during a first time period when the OTP memory is not user-accessible. In one embodiment, the time period 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.The method may include providing access to a second set of the plurality of defined functions while the electronic device is in a second lifecycle stage of the plurality of defined lifecycle 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 lifecycle stage of a plurality of defined lifecycle stages to a second lifecycle stage of the plurality of defined lifecycle stages.

[0013] In one embodiment, the method may include prohibiting transitioning the electronic device to a first lifecycle stage of the plurality of defined lifecycle stages after transitioning the electronic device to a second lifecycle stage of the plurality of defined lifecycle 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 lifecycle stages to a third one of the plurality of defined lifecycle stages. In response to the received request to transition the electronic device from the second one of the plurality of defined lifecycle stages to the third one of the plurality of defined lifecycle stages, the method may include transitioning the electronic device to the third one of the plurality of defined lifecycle stages by programming the OTP memory with information corresponding to the third one of the plurality of defined lifecycle stages during a second time period when the OTP memory is not user-accessible. 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 lifecycle stages. In one embodiment, the method may include prohibiting transitioning the electronic device to the second one of the plurality of defined lifecycle stages after transitioning the electronic device to the third one of the plurality of defined lifecycle 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 explanation 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 device's OTP memory. [Figure 2] 1 illustrates an exemplary OTP memory that can be used to manage the lifecycle of an electronic device. [Figure 3]1 illustrates an example of a valid transition from one life cycle stage to another in an electronic device. [Figure 4] 10 shows an example of a lifecycle bitmap for an exemplary set of nine lifecycle OTP bits. [Figure 5] 10 illustrates one embodiment of using manufacturer OTP configuration bits for sub-stages of life cycle stages 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 electronic device's OTP memory. [Figure 8] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 9a] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 9b] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 9c] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 9d] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 9e] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 9f]1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 10] 10 illustrates a flowchart of additional exemplary operations for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 11] 10 illustrates a flowchart of additional exemplary operations for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 12] 10 illustrates a flowchart of additional exemplary operations for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. [Figure 13] 1 illustrates a flowchart of an exemplary method for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. DETAILED DESCRIPTION OF THE INVENTION

[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 of the other drawings in which the same illustrated element appears.

[0018] When an electronic device (e.g., a microcontroller) starts 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 the boot process.

[0019] An electronic device may be capable of transitioning through various lifecycle stages over time. Various features or functions of the electronic device may be available in some lifecycle stages and unavailable in other lifecycle stages. The features and functions available in a particular lifecycle stage may relate to the security of the device. For example, a cryptographic key that may be used to verify code executing on the electronic device may be accessible in one or more lifecycle stages but may be inaccessible in other lifecycle stages. In another example, a function that may establish or enable the establishment of secure information for the electronic device may be available in one or more lifecycle stages but may be unavailable in other lifecycle stages. In this manner, the level of security of an electronic device at a given time may correspond to the lifecycle 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, a level of security for an electronic device may correspond to a lifecycle stage of the electronic device, and may include features to prevent an attacker from changing the lifecycle 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 manufacturing 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, reproduce, manipulate, 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 personal digital assistant (PDA), 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 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, mouse, and 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 lifecycle of an electronic device 101 through secure programming of the electronic device's OTP memory. As shown in FIG. 1, system 100 may comprise an electronic device 101. Components of electronic device 101 may include, but are not limited to, one or more processors 160 and a system bus 121 that communicatively couples various system components to processor 160, including, for example, OTP memory 110, ROM 130, memory 170, I / O & port control 190, and network interface 150. 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 can 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 by 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 may be unmodifiable once programmed. 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 startup) of electronic device 101. According to one embodiment, boot code 140 may be immutable, i.e., built into the electronic device during manufacturing, and therefore may be implicitly trusted (e.g., a 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, SRAM (Static Random Access Memory), DRAM (Dynamic Random Access Memory)), 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] I / O and port control 190 may include any system, device, or apparatus generally operable to receive or transmit data to / from / within electronic device 101. 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 (e.g., without limitation, JTAG, I2C, UART, Test Access Port). 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 with 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 lifecycle of an electronic device. As shown in FIG. 2, the OTP memory 110 may include various defined regions, including lifecycle bits 203, manufacturer configuration information 213, customer information 223, and private device-specific information 233. In one embodiment, the lifecycle bits 203 may be programmed (currently broken) by the boot code 140 and may trigger transitions between different lifecycle stages in a defined series of lifecycle stages for the electronic device 101. In the same or another embodiment, the manufacturer configuration information 213 may be programmed (currently broken) 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. Manufacturer configuration information 213 may include bits that enable, disable, or configure features on electronic device 101 (e.g., GPIO pin (General Purpose Input / Output pin) availability, clock rate, and security feature availability), public keys of public key / crypto key pairs, and device identification information. In one embodiment, customer information 223 may include bits that are programmed (currently blown off) by the customer of electronic device 101.

[0032] In one embodiment, secret device specific information 233 may include (a) a device identification key (“DevIK”) (e.g., the private key of a public key / cryptographic key pair) or information from which a DevIK can 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 different lifecycle stages, as disclosed in Tables 2-7. Exemplary methods for making functions available are shown in FIG. 13 and related 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 lifecycle stages and simultaneously linear transitions. In one embodiment, the manufacturer of electronic device 101 may define the allowable transitions. Boot code 140 may enforce the manufacturer-defined allowable transitions by managing the transition of electronic device 101 through the series of lifecycle stages. FIG. 3 shows an example of valid transitions (e.g., manufacturer-defined allowable transitions) from one lifecycle stage to another with arrows between different lifecycle stages in series of lifecycle stages 308. For example, from the RAW stage, a 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, transitions from one lifecycle stage to another are phased and require a reset of electronic device 101 (e.g., a device reset, reboot, or power cycle) 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, e.g., 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] FIG. 4 illustrates an example of a lifecycle bitmap for an exemplary set of nine lifecycle bits (bit 0-bit 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 corresponding to a defined lifecycle stage in a series of lifecycle stages 408. As shown in this example, lifecycle OTP bit pattern 404a in lifecycle bitmap 203a may correspond to lifecycle stage RAW shown immediately below lifecycle bitmap 203a. Similarly, lifecycle OTP bit pattern 404b in lifecycle bitmap 203b may correspond to lifecycle stage MFG shown immediately below lifecycle bitmap 203b. Other illustrated lifecycle OTP bit patterns (eg, 404c-404f in lifecycle bitmaps 203c-203f) may correspond to the lifecycle stages illustrated immediately below them.

[0042] As shown in FIG. 4, lifecycle bitmap 203a may correspond to lifecycle OTP bit pattern 404a for the RAW lifecycle stage (i.e., bits 0 through 8 are not programmed). Lifecycle bitmap 203b may correspond to lifecycle OTP bit pattern 404b for the MFG lifecycle stage (i.e., bits 0 and 2 are programmed, and bits 1 and 3 through 8 are not programmed). Lifecycle bitmap 203c may correspond to lifecycle OTP bit pattern 404c for the DEV lifecycle stage (i.e., bits 0 and 2 through 4 are programmed, and bits 1 and 5 through 8 are not programmed). Lifecycle bitmap 203d may correspond to lifecycle OTP bit pattern 404d for the PROD lifecycle stage (i.e., bits 0, 2, and 4 through 5 are programmed, and bits 1, 3, and 6 through 8 are not programmed). Lifecycle bitmap 203e may correspond to lifecycle OTP bit pattern 404e for the FA lifecycle stage (i.e., bits 0, 2 through 6, and 8 are programmed, and bits 1 and 7 are not programmed). Lifecycle bitmap 203f may correspond to lifecycle OTP bit pattern 404f for the EOL lifecycle 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 unidirectionally through a series of lifecycle stages. For example, transition 410 from the MFG lifecycle stage back to the RAW lifecycle stage after boot code 140 programs lifecycle bits 203 with lifecycle OTP bit pattern 404b corresponding to the MFG lifecycle stage may be prohibited because it is not possible to "deprogram" lifecycle bits 0 and 2 (the OTP memory may be permanently programmed). Thus, as shown by exemplary lifecycle OTP bit patterns 404a-404f in lifecycle bitmaps 203c-203f, electronic device 101 may be restricted to progressing through lifecycle stages in one direction, i.e., from left to right in FIG. 4 .

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

[0045] While Figure 5 illustrates an example of defining substages for the MFG lifecycle stage, a similar approach may be used to define substages for other lifecycle stages of an electronic device. For example, a customer may desire a development substage (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 customer information 223 of OTP memory 110 to define the substage (e.g., similar to substage 515). The customer configuration bits may be used by 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 lifecycle request bits 682, command area 684, and command parameter area 686. In one embodiment, lifecycle 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 so that code other than boot code 140 (e.g., manufacturer code, customer code) can 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, lifecycle request bit 682, when set, may correspond to a request to transition electronic device 101 from a current lifecycle stage to a next lifecycle stage. In the same or another embodiment, command field 684 may be programmed with commands corresponding to functions that boot code 140 may perform (e.g., functions F1, F2 shown as 145a and 145b in FIG. 1). Command parameter field 686 may be programmed with parameters corresponding to the commands programmed in field 684.

[0048] FIG. 7 illustrates a flowchart of an example method 700 for managing the lifecycle 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. Accordingly, the initialization point of method 700 and the order of steps 710-760 that comprise method 700 may depend on the selected implementation.

[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 in 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 fewer operations than those shown in FIG. 7. For example, prior to block 750, the boot code may determine the next lifecycle stage, for example, based on the OTP configuration bits. Also, prior to block 750, the boot code may generate a lifecycle bit pattern corresponding to the next lifecycle stage. In another embodiment, in block 760, the boot code may cause the transition to the next lifecycle stage by forcing a reset of electronic device 101. Note 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 flowchart of an example method 800 for managing the lifecycle 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 comprise method 800 may depend on the selected implementation.

[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 it determines whether a secure lifecycle request is required. In some embodiments, a manufacturer may desire secure programming of the OTP lifecycle bit 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 a public key pair. The boot code may access the other half of the key pair to verify the signed command. If the boot code determines in block 830 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 the boot code determines in block 830 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 field 684 from command memory 171 shown in FIG. 6. The command may include parameters from command parameter field 686. As described with respect to FIG. 6, the user may write the secure lifecycle request command to command memory 171 via firmware (e.g., customer code) or via a physical interface (e.g., a JTAG debug interface, a UART interface, an 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 fewer 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 also be performed in method 800. Note that while 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 illustrate a flowchart of an example method 900 for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. According to one embodiment, method 900 may begin at block 902 of FIG. 9a. In one embodiment, method 900 may be performed by boot code 140. In some embodiments, start block 902 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 900 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 900 and the order of steps 902-984 comprising method 900 may depend on the selected implementation.

[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 the RAW life cycle stage. If so, the boot code may proceed to block 908 and stop executing code. For example, by stopping code execution, the boot code may not load a code image so that no features or capabilities are enabled on the electronic device. This functionality can prevent silicon theft while the silicon is being transported 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 the RAW life cycle stage, the boot code may proceed to block 910 (continued in FIG. 9b). In this example, 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 lifecycle bits 203 in OTP memory 110. In other embodiments, boot code 104 may program a lifecycle OTP bit pattern (e.g., 404b) corresponding to the MFG LCS into lifecycle bits 203, 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 the boot code determines in block 914 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 disabled, the boot code may proceed to block 920. In block 920, the boot code may generate a PROD lifecycle OTP bit pattern (e.g., 404d in FIG. 4). The boot code may then proceed to block 922 and program the OTP lifecycle bits 203 in the OTP memory 110 with the PROD lifecycle 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 lifecycle 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 lifecycle stage (e.g., as shown in FIG. 12).

[0059] If, in block 918, it is determined that JTAG is not disabled, the boot code may proceed to block 926. In 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, in block 930, the boot code may cause the transition to the DEV lifecycle stage by forcing a reset of the electronic device 101. In 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 FIGS. 7 and 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 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 a DEV LCS to either an 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 for block 845 of FIG. 8. In other embodiments, verification of the received request / command may proceed as shown in Figures 10 and 11. If verification 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 the verification (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 an 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 device configuration information area 213 or customer information area 223) may indicate which transition is desired.

[0063] If the boot code determines to transition to the FA LCS in block 944, 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 in block 944, the boot code may proceed to block 946. In 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, in block 950, the boot code may cause the transition to the EOL lifecycle stage by forcing a reset of the electronic device 101. In 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 may erase all memory, effectively erasing all secrets stored in the OTP memory (e.g., by programming all bits in the OTP memory), thus protecting manufacturer and customer secrets and eliminating the need to physically destroy the part.

[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 in 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 verification fails in block 968, the boot code may proceed to block 964. Blocks 944, 946, 948, 950, 952, 954, and 956 of Figure 9d are described by the like numbered blocks in Figure 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 the boot code determines in block 974 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 845, 942, and 968 (in FIGS. 8, 9c, and 9d, respectively), except that if verification fails in block 980, the boot code may proceed to block 976. Blocks 946, 948, and 950 in 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 in the EOL lifecycle stage. If so, the boot code may proceed to block 982 and stop executing the code. For example, by stopping code execution, 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 result for a part that has reached end-of-life (EOL). If the boot code determines in block 980 that the LCS is not in the 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, for example, any of the six defined lifecycle stages of the electronic device 101. Alternatively, because no error condition is expected, the boot code may return from block 984 to block 902 of FIG. 9a and re-execute method 900.

[0071] 9a-9f disclose a particular number of operations associated with method 900, method 900 may be performed with more or fewer operations than those shown in Figures 9a-9f, including the operations described above and other operations. Figures 10-12 provide additional examples of method 900 having more operations than those shown in Figures 9a-9f. Note 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 flowchart of additional exemplary operations of a method 900 for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. FIG. 10 illustrates an example of additional operations that boot code 140 may perform when receiving and verifying a signed lifecycle FA / EOL command, as described with respect to blocks 940, 966, 978, and 942, 968, and 980 of FIGS. 9c, 9d, and 9e. In this example, a manufacturer may enhance security associated with transitioning to the FA or EOL lifecycle stage. Accordingly, blocks 940, 966, 978, and 942, 968, and 980 of FIGS. 9c, 9d, and 9e may be replaced with blocks 986-994 and 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-specific information 233, which 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 shown in Figure 10 (e.g., as shown in Figure 11). Note 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 shows a flowchart of additional example operations of method 900 for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. FIG. 11 shows 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 that period has elapsed. The timeout period may begin executing after the boot code sends the DUD in block 990. If the timeout period elapses before the boot code receives a signed lifecycle 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 trigger a transition to either the FA or EOL lifecycle stage may be required to start the process again, including requesting the DUD in block 986.

[0076] FIG. 12 shows a flowchart of additional example 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. 12 illustrates an example of additional operations that 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 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. While 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 shows a flowchart of an example method 1300 for managing the lifecycle of an electronic device through secure programming of the electronic device's OTP memory. In one embodiment, electronic device 101 may include lifecycle function data that specifies a set of available functions for each lifecycle stage. The specified set of available functions for each lifecycle stage defines the functions that may be executed during each lifecycle stage of the electronic device. In FIG. 13, 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 lifecycle FA / EOL command. If so, the boot code may proceed to block 1306, where the boot code determines whether the current lifecycle stage is either a DEV LCS or a PROD LCS. If so, the boot code may proceed to block 1310 and process the received command. If the current lifecycle stage is neither DEV nor 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 directive is 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 limit the functions available to that respective lifecycle stage as defined by the lifecycle function data.

[0078] Methods 700-1300 may be implemented using system 100 or any other system operable to implement methods 700-1300. Although examples are 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 life cycle stage of the plurality of defined life cycle stages; boot code stored in a read-only memory, receiving a request to transition from a current lifecycle stage of the plurality of defined lifecycle stages to a next lifecycle stage of the plurality of defined lifecycle stages; and boot code executable by a processor to: in response to the received request, automatically generate a bit pattern corresponding to the next life cycle stage of the plurality of defined life cycle stages; 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.

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 lifecycle stages into the OTP memory during a time when the OTP memory is not user-accessible comprises boot code executable by the processor to automatically generate and program the bit pattern corresponding to the next one of the plurality of defined lifecycle stages into the OTP memory during a reset of the electronic device.

3. The system of claim 2 , wherein the 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 lifecycle stage of the plurality of defined lifecycle stages in the OTP memory causes a transition from the current lifecycle stage of the plurality of defined lifecycle stages to the next lifecycle stage of the plurality of defined lifecycle stages.

5. 2. 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. 2. The system of claim 1, wherein for each lifecycle stage of the plurality of defined lifecycle stages, the boot code makes available to the user a corresponding respective set of available functions executable during the respective lifecycle stage of the plurality of defined lifecycle stages.

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 lifecycle stages excludes the first function.

8. 10. The system of claim 1, wherein the request to transition from a current lifecycle stage of the plurality of defined lifecycle stages to a next 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.

9. 10. The system of claim 1, wherein the request to transition from a current lifecycle stage of the plurality of defined lifecycle stages to a next lifecycle stage of the plurality of defined lifecycle stages comprises a signed command.

10. 10. The system of claim 1, 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 lifecycle OTP bit pattern corresponding to a respective lifecycle stage of the electronic device; lifecycle function data specifying a set of available functions for each lifecycle stage; 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 lifecycle stage is different from the designated set of available functions for each second lifecycle stage; boot code stored in read-only memory and executable by a processor to manage the provisioning of the electronic device through a series of lifecycle stages; selectively programming the plurality of lifecycle OTP bits over time to progress the electronic device through the series of lifecycle stages during times when the OTP memory is not user accessible; and while the electronic device is operating in the respective first lifecycle stage, allowing access to only the set of available functions for the respective first lifecycle stage as specified by the lifecycle 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, wherein the boot code executable by the processor to selectively program the plurality of lifecycle OTP bits over time to advance the electronic device through the series of lifecycle stages comprises boot code executable by the processor to selectively program the plurality of lifecycle OTP bits over time to advance the electronic device through the series of lifecycle stages in response to signed instructions.

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

16. The method of claim 14 , wherein resetting the electronic device comprises a device reset, a reboot, or a power cycle of the electronic device.

17. The method of claim 15 , wherein the reset of the electronic device comprises a device reset, a reboot, or a power cycle of the electronic device.

18. 15. The method of claim 14, comprising: in response to the received request to transition the electronic device from the first one of the plurality of defined lifecycle stages to the second one of the plurality of defined lifecycle 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.

19. the first set of the plurality of defined functions includes a first function; The method of claim 14 , wherein the second set of the plurality of defined functions excludes the first function.

20. 15. The method of claim 14, comprising prohibiting transitioning the electronic device to the first lifecycle stage of the plurality of defined lifecycle stages after transitioning the electronic device to the second lifecycle stage of the plurality of defined lifecycle stages.

21. 15. The method of claim 14, 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.

22. 15. The method of claim 14, wherein the request to transition the electronic device from the first of the plurality of defined lifecycle stages to the second of the plurality of defined lifecycle stages comprises a signed command.

23. receiving a request to transition the electronic device from the second one of the plurality of defined lifecycle stages to a third one of the plurality of defined lifecycle stages; in response to the received request to transition the electronic device from the second one of the plurality of defined lifecycle stages to the third one of the plurality of defined lifecycle stages, transitioning the electronic device to the third one of the plurality of defined lifecycle stages by programming the OTP memory with information corresponding to the third one of the plurality of defined lifecycle 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.

24. 24. The method of claim 23, comprising prohibiting the electronic device from transitioning to the second lifecycle stage of the plurality of defined lifecycle stages after transitioning the electronic device to the third lifecycle stage of the plurality of defined lifecycle stages.

Images