Secure boot system and method for programmable logic devices

Abstract

Systems and methods for secure booting of a secure programmable logic device (PLD) are disclosed. An exemplary system includes a secure PLD, the secure PLD including a programmable logic block (PLB) and a configuration engine, the programmable logic block (PLB) being arranged in a PLD structure of the secure PLD, the configuration engine being configured to: program the PLD structure according to a configuration image stored in a non-volatile memory (NVM) of the secure PLD and / or coupled to the configuration engine through a configuration input / output (I / O) of the secure PLD. The secure PLD is configured to retrieve a pre-authentication state associated with the configuration image from the NVM, determine or verify that the retrieved pre-authentication state associated with the configuration image includes a valid state, and boot the PLD structure of the secure PLD using the configuration image.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This patent application claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 846,365, filed on May 10, 2019, entitled “SECURE BOOT SYSTEMS AND METHODSFOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0003] This patent application claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 756,021, filed on November 5, 2018, entitled “ASSET MANAGEMENT SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0004] This patent application claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 756,001, filed on November 5, 2018, entitled “KEY PROVISIONING SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0005] This patent application claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 756,015, filed on November 5, 2018, entitled “FAILURE CHARACTERIZATION SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0006] This patent application claims priority to and the benefit of U.S. Provisional Patent Application No. 62 / 670,487, filed on May 11, 2018, entitled “DEVICES WITH PROGRAMMABLE LOGIC AND SECURITY FEATURES AND METHODS OF USING,” the entire contents of which are incorporated herein by reference. Technical Field

[0007] The present invention relates generally to programmable logic devices and, more particularly, to secure booting of such devices. Background Art

[0008] A programmable logic device (PLD) (e.g., a field programmable gate array (FPGA), a complex programmable logic device (CPLD), a field programmable system on chip (FPSC), or other types of programmable devices) can be configured with various user designs to implement desired functions. Typically, the user design is synthesized and mapped to the configurable resources (e.g., programmable logic gates, lookup tables (LUTs), embedded hardware, or other types of resources) and interconnects available in a particular PLD. The physical layout and routing of the synthesized and mapped user design can then be determined to generate configuration data for the particular PLD.

[0009] Clients of PLDs typically devote considerable resources to developing configurations for their selected PLD types and / or capabilities, and protecting configuration data and preventing the desired operation or capabilities associated with the selected PLD and / or developed configuration from being compromised is critical to many clients of PLDs. Therefore, there is a need in the art for systems and methods for manufacturing, protecting, distributing, upgrading, and testing PLDs and PLD configurations, particularly in the context of trusted computing applications and trusted computing architectures. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 A block diagram of a programmable logic device (PLD) according to an embodiment of the present disclosure is shown.

[0011] Figure 2 A block diagram showing logic blocks of a PLD according to an embodiment of the present disclosure is shown.

[0012] Figure 3 The design process of a PLD according to an embodiment of the present disclosure is shown.

[0013] Figure 4 A block diagram of a secure PLD according to an embodiment of the present disclosure is shown.

[0014] Figure 5A A block diagram of a secure PLD provisioning system according to an embodiment of the present disclosure is shown.

[0015] Figure 5B A block diagram of a secure PLD provisioning system according to an embodiment of the present disclosure is shown.

[0016] Figure 6 A block diagram of a user device including a secure PLD according to an embodiment of the present disclosure is shown.

[0017] Figure 7 A provisioning process for a locked secure PLD according to an embodiment of the present disclosure is shown.

[0018] Fig. 8A A block diagram of a lockout strategy plan for a secure PLD according to an embodiment of the present disclosure is shown.

[0019] Figure 8B A block diagram of a lockout strategy plan for a secure PLD according to an embodiment of the present disclosure is shown.

[0020] 9A to 9D An access table associated with a corresponding lock policy plan for a secure PLD is shown according to an embodiment of the present disclosure.

[0021] Fig.10 An asset management process for a secure PLD according to an embodiment of the present disclosure is shown.

[0022] FIG. 11A to FIG. 11C A secure boot process for a secure PLD according to an embodiment of the present disclosure is shown.

[0023] FIG. 12A to FIG. 12B A secure boot process for a secure PLD according to an embodiment of the present disclosure is shown.

[0024] Fig.13 A rollback protection rule set for a secure boot process of a secure PLD according to an embodiment of the present disclosure is shown.

[0025] Fig.14 A secure boot process for a secure PLD according to an embodiment of the present disclosure is shown.

[0026] Fig.15 A secure boot process for a secure PLD according to an embodiment of the present disclosure is shown.

[0027] Embodiments of the present disclosure and their advantages may be best understood by reference to the following detailed description. It should be understood that the same reference numerals are used to identify the same elements shown in one or more of the accompanying drawings, wherein the text is for illustrating embodiments of the present disclosure rather than for limiting embodiments of the present disclosure. DETAILED DESCRIPTION

[0028] The present disclosure provides systems and methods for securely booting a locked secure programmable logic device (PLD) for use in trusted computing applications and architectures described herein. For example, embodiments provide a system and method for pre-authenticating a configuration image of a PLD structure of a secure PLD without causing the secure PLD to shut down by submitting the configuration image to an on-chip authentication engine, authenticating the configuration image, and then storing the configuration image and pre-authentication status in the secure PLD, all of which can occur when the PLD structure of the secure PLD operates according to the already booted configuration image. Once authenticated, the secure PLD can then reboot, check the pre-authentication status, and selectively program the PLD structure based on the pre-authentication status, and initialize or "wake up" the PLD structure without performing resource-intensive further authentication of the configuration image. Therefore, embodiments are able to repeatedly securely boot a secure PLD with little or no impact on the performance impact of the secure PLD and / or a trusted platform / user device incorporating the secure PLD, as described herein.

[0029] Additionally, embodiments provide a system and method for assigning a lock status to individual assets and / or groups of assets (which include stored configuration images and / or input / output buses that transmit such configuration images) by setting corresponding lock status bits stored in secure memory of a secure PLD, thereby helping to reduce or eliminate the risk of loss or extraction of client or manufacturer data, or the risk of reprogramming such data, without requiring the need to restrict or limit the distribution of locked secure PLDs (e.g., which could otherwise be programmed with non-client data and potentially used to subvert various secure operations of a trusted platform, including, for example, securely configuring and / or booting such a platform / user device), as described herein.

[0030] According to the embodiments set forth herein, a technique for safely implementing a user design in a programmable logic device (PLD) is provided. In various embodiments, a user design may be converted into a set of PLD components (e.g., configured for logic, arithmetic, or other hardware functions) and their associated interconnections available in the PLD and / or represented by a set of PLD components and their associated interconnections available in the PLD. For example, a PLD may include a plurality of programmable logic blocks (PLBs) and configurable routing resources that may be used to interconnect the PLBs and / or logic cells, each PLB including a plurality of logic cells. In some embodiments, each PLB may be implemented with between 2 and 16 or between 2 and 32 logic cells.

[0031] Typically, a PLD (e.g., FPGA) structure includes one or more routing structures and an array of similarly arranged logic cells arranged within a programmable function block (e.g., PFB and / or PLB). The purpose of the routing structure is to programmably connect the ports of the logic cells / PLBs to each other in the necessary combination to achieve the desired function. A secure PLD may include various additional "hard" engines or modules that are configured to provide operations that can be linked to the PLD structure to provide a series of security functions of a configurable trusted computing function and / or architecture. Routing flexibility and configurable function embedding can be used when synthesizing, mapping, placing and / or routing a user design into multiple PLD components. As a result of various user design optimization processes (which can result in considerable design time and cost), the user design can be implemented relatively efficiently, thereby freeing up configurable PLD components that would otherwise be occupied by additional operations and routing resources. In some embodiments, the optimized user design can be represented by a netlist that identifies various types of components provided by the PLD and their associated signals. In an embodiment that generates a netlist of the converted user design, an optimization process can be performed on such a netlist. Once optimized, such a configuration may be encrypted and signed and / or otherwise protected for distribution to secure PLDs, and such a process may include one or more key provisioning processes, as described herein.

[0032] Now referring to the accompanying drawings, Figure 1 A block diagram of a PLD 100 according to an embodiment of the present disclosure is shown. The PLD 100 (e.g., a field programmable gate array (FPGA), a complex programmable logic device (CPLD), a field programmable system on chip (FPSC), or other types of programmable devices) generally includes input / output (I / O) blocks 102 and logic blocks 104 (e.g., also referred to as programmable logic blocks (PLBs), programmable function units (PFUs), or programmable logic cells (PLCs)). More generally, the individual elements of the PLD 100 may be referred to as a PLD fabric.

[0033] I / O blocks 102 provide I / O functionality (e.g., to support one or more I / O and / or memory interface standards) for PLD 100, while programmable logic blocks 104 provide logic functionality (e.g., LUT-based logic or logic gate array-based logic) for PLD 100. Additional I / O functionality may be provided by serializer / deserializer (SERDES) blocks 150 and physical coding sublayer (PCS) blocks 152. PLD 100 may also include hard intellectual property core (IP) blocks 160 to provide additional functionality (e.g., substantially predetermined functionality provided in hardware that may be configured with less programming than logic blocks 104).

[0034] PLD 100 may also include memory blocks 106 (e.g., EEPROM blocks, block SRAM, flash memory, MRAM, and / or RRAM), clock-related circuits 108 (e.g., clock sources, PLL circuits, and / or DLL circuits), and / or various routing resources 180 (e.g., interconnects and appropriate switching logic to provide paths for routing signals throughout PLD 100, such as for clock signals, data signals, or others), as appropriate. In general, as will be appreciated by those skilled in the art, the various elements of PLD 100 may be used to perform their intended functions for a desired application.

[0035] For example, some I / O blocks 102 may be used to program memory 106 or transfer information (e.g., various types of user data and / or control signals) to / from PLD 100. Other I / O blocks 102 include a first programming port (which may represent a central processing unit (CPU) port, a peripheral data port, an SPI interface, and / or a sysCONFIG programming port) and / or a second programming port such as a Joint Test Action Group (JTAG) port (e.g., by adopting a standard such as the Institute of Electrical and Electronics Engineers (IEEE) 1149.1 or 1532 standards). In various embodiments, I / O blocks 102 may be included to receive configuration data and commands (e.g., via one or more connections 140) to configure PLD 100 for its intended use and to support serial or parallel device configuration and information transfer with SERDES block 150, PCS block 152, hard IP block 160, and / or logic block 104 as appropriate.

[0036] It should be understood that the number and location of the various elements are not limiting and may depend on the desired application. For example, various elements may not be required for the desired application or design specifications (eg, for the type of programmable device selected).

[0037] Furthermore, it should be understood that the elements are shown in block form for clarity and that the various elements are typically distributed throughout PLD 100, such as in logic blocks 104, hard IP blocks 160, and routing resources (e.g., Figure 2 The various embodiments disclosed herein are not limited to programmable logic devices such as PLD 100, and may be applied to various other types of programmable devices, as will be appreciated by those skilled in the art.

[0038] External system 130 may be used to create a desired user configuration or design for PLD 100 and generate corresponding configuration data to program (e.g., configure) PLD 100. For example, external system 130 may provide such configuration data to one or more I / O blocks 102, SERDES block 150, and / or other portions of PLD 100. Thus, programmable logic blocks 104, various routing resources, and any other appropriate components of PLD 100 may be configured to operate according to a user-specified application.

[0039] In the illustrated embodiment, the external system 130 is implemented as a computer system. In this regard, the external system 130 includes, for example, one or more processors 132, which may be configured to execute instructions, such as software instructions, provided in one or more memories 134 and / or stored in a non-transitory form in one or more non-transitory machine-readable media 136 (e.g., which may be internal or external to the external system 130). For example, in some embodiments, the external system 130 may run PLD configuration software, such as Lattice Diamond System Planner software available from Lattice Semiconductor Corporation, to allow a user to create a desired configuration and generate corresponding configuration data to program the PLD 100.

[0040] External system 130 also includes, for example, a user interface 135 (e.g., a screen or display) for displaying information to a user, and one or more user input devices 137 (e.g., a keyboard, mouse, trackball, touch screen, and / or other devices) for receiving user commands or design entries to prepare a desired configuration of PLD 100.

[0041] Figure 2 1 shows a block diagram of a logic block 104 of a PLD 100 according to an embodiment of the present disclosure. As discussed, the PLD 100 includes a plurality of logic blocks 104 that include various components to provide logic and arithmetic functions. Figure 2In the exemplary embodiment shown, logic block 104 includes a plurality of logic cells 200 that may be interconnected internally within logic block 104 and / or externally using routing resources 180. For example, each logic cell 200 may include various components such as a lookup table (LUT) 202, a mode logic circuit 204, a register 206 (e.g., a flip-flop or latch), and various programmable multiplexers (e.g., programmable multiplexers 212 and 214) for selecting desired signal paths between logic cells 200 and / or logic cells 200. In this example, LUT 202 accepts four inputs 220A-220D, which makes it a four-input LUT (which may be abbreviated as "4-LUT" or "LUT4") that may be programmed by configuration data of PLD 100 to implement any appropriate logic operation with four or fewer inputs. Mode logic circuit 204 may include various logic elements and / or additional inputs, such as input 220E, to support the functionality of various modes, as described herein. In other examples, LUT 202 may have any other suitable size, with any other suitable number of inputs for a particular implementation of a PLD. In some embodiments, different sized LUTs may be provided for different logic blocks 104 and / or different logic cells 200 .

[0042] In some embodiments, output signal 222 from LUT 202 and / or mode logic circuit 204 may pass through register 206 to provide output signal 233 of logic cell 200. In various embodiments, as shown, output signal from LUT 202 and / or mode logic circuit 204 may pass directly to output 223. Depending on the configuration of multiplexers 210-214 and / or mode logic circuit 204, output signal 222 may be temporarily stored (e.g., latched) in register 206 according to control signal 230. In some embodiments, configuration data for PLD 100 may configure outputs 223 and / or 233 of logic cell 200 to be provided as one or more inputs of another logic cell 200 (e.g., in another logic block or the same logic block) in a hierarchical or cascade arrangement (e.g., including multiple levels) to configure a logic operation that cannot be implemented in a single logic cell 200 (e.g., a logic operation that has too many inputs to be implemented by a single LUT 202). Furthermore, logic unit 200 may be implemented with multiple outputs and / or interconnects to facilitate selectable modes of operation, as described herein.

[0043] Mode logic circuits 204 may be used in some configurations of PLD 100 to efficiently implement arithmetic operations, such as adders, subtractors, comparators, counters, or other operations, to efficiently form some extended logic operations (e.g., higher order LUTs, working with multi-bit data), to efficiently implement relatively small RAMs, and / or to allow selection between logic, arithmetic, extended logic, and / or other selectable operating modes. In this regard, mode logic circuits 204 across multiple logic cells 202 may be chained together to pass carry signals 205 and carry out signals 207, and / or other signals (e.g., output signals 222) between adjacent logic cells 202, as described herein. Figure 2 In the example of , carry signal 205 may be passed directly to mode logic circuit 204 , or may be passed to mode logic circuit 204 by configuring one or more programmable multiplexers, as described herein. In some embodiments, mode logic circuit 204 may be linked across multiple logic blocks 104 .

[0044] Figure 2 The logic unit 200 shown in FIG. 1 is merely an example, and the logic unit 200 according to different embodiments may include different combinations and arrangements of PLD components. Figure 2 A logic block 104 is shown having eight logic cells 200, but logic blocks 104 according to other embodiments may include fewer logic cells 200 or more logic cells 200. Each logic cell 200 of a logic block 104 may be used to implement a portion of a user design implemented by PLD 100. In this regard, PLD 100 may include many logic blocks 104, each of which may include logic cells 200 and / or other components that collectively implement a user design.

[0045] As further described herein, when PLD 100 is configured to implement a user design, portions of the user design may be adjusted to occupy fewer logic cells 200, fewer logic blocks 104, and / or place less of a burden on routing resources 180. Such adjustments according to various embodiments may identify certain logic, arithmetic, and / or extended logic operations to be implemented in arrangements that occupy multiple embodiments of logic cells 200 and / or logic blocks 104. As further described herein, the optimization process may route various signal connections associated with the arithmetic / logic operations described herein such that the logic, ripple arithmetic, or extended logic operations may be implemented into one or more logic cells 200 and / or logic blocks 104 to be associated with the previous arithmetic / logic operations.

[0046] Figure 3 FIG. 3 shows a design process 300 of a PLD according to an embodiment of the present disclosure. For example, Figure 3The process may be performed by external system 130 running Lattice Diamond software to configure PLD 100. In some embodiments, Figure 3 The various files and information referenced in the description may be stored in one or more databases and / or other data structures, such as in memory 134, machine-readable medium 136, and / or other data structures. In various embodiments, such files and / or information may be encrypted or otherwise protected when stored and / or transmitted to PLD 100 and / or other devices or systems.

[0047] In operation 310, external system 130 receives a user design that specifies desired functionality for PLD 100. For example, a user may interact with external system 130 (e.g., via user input device 137 and hardware description language (HDL) code representing the design) to identify various features of the user design (e.g., high-level logic operations, hardware configuration, and / or other features). In some embodiments, the user design may be provided in a register transfer level (RTL) description (e.g., a gate-level description). External system 130 may perform one or more rule checks to confirm that the user design describes a valid configuration for PLD 100. For example, external system 130 may reject invalid configurations and / or request that the user provide appropriate new design information.

[0048] In operation 320, external system 130 synthesizes the design to create a netlist (e.g., a synthesized RTL description) that identifies an abstract logical implementation of the user design as a plurality of logic components (e.g., also referred to as netlist components), which may include both programmable components and hard IP components of PLD 100. In some embodiments, the netlist may be stored in a local general database (NGD) file in an electronic design interchange format (EDIF).

[0049] In some embodiments, synthesizing the design into a netlist in operation 320 may involve converting (e.g., translating) a high-level description of logic operations, hardware configurations, and / or other features in the user design into a collection of PLD components (e.g., logic blocks 104, logic cells 200, and other components of PLD 100 configured to implement the logic, arithmetic, or other hardware functions of the user design) and their associated interconnections or signals. Depending on the embodiment, the converted user design may be represented as a netlist.

[0050] In some embodiments, synthesizing the design into a netlist in operation 320 may further involve performing an optimization process on the user design (e.g., the user design converted / translated into a set of PLD components and their associated interconnections or signals) to reduce propagation delays, consumption of PLD resources and routing resources, and / or optimize the performance of the PLD when configured to implement the user design. Depending on the embodiment, the optimization process may be performed on a netlist representing the converted / translated user design. Depending on the embodiment, the optimization process may represent the optimized user design in a netlist (e.g., to produce an optimized netlist).

[0051] In some embodiments, the optimization process may include optimizing certain instances of logic function operations, ripple arithmetic operations, and / or extended logic function operations that would occupy multiple configurable PLD components (e.g., logic cells 200, logic blocks 104, and / or routing resources 180) when the PLD is configured to implement the user design. For example, the optimization process may include detecting multiple modes or configurable logic cells that implement the logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in the user design, swapping the operation modes of the logic cells that implement the various operations to reduce the number of PLD components and / or routing resources used to implement the operations and / or reduce the propagation delay associated with the operations, and / or reprogramming the corresponding LUTs and / or mode logic to account for the swapped operation modes.

[0052] In another example, the optimization process may include detecting an extended logic function operation and / or corresponding routing resources in a user design, implementing the extended logic operation as a multi-mode or switchable logic cell with a single physical logic cell output, routing or coupling logic cell outputs of a first group of logic cells to inputs of a second group of logic cells to reduce the number of PLD components used to implement the extended logic operation and / or routing resources and / or reduce propagation delays associated with the extended logic operation, and / or programming corresponding LUTs and / or mode logic to implement the extended logic function operation using at least the first group of logic cells and the second group of logic cells.

[0053] In another example, the optimization process may include detecting multiple modes or configurable logic cells implementing logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in a user design, swapping operation modes of the logic cells implementing the various operations to provide programmable registers along signal paths within the PLD to reduce propagation delays associated with the signal paths, and reprogramming corresponding LUTs, mode logic, and / or other logic cell control bits / registers to account for the swapped operation modes and / or programming programmable registers to store or latch signals on the signal paths.

[0054] In operation 330, external system 130 performs a mapping process that identifies components of PLD 100 that may be used to implement the user design. In this regard, external system 130 may map the optimized netlist (e.g., stored in operation 320 as a result of the optimization process) to various types of components (e.g., logic blocks 104, logic cells 200, embedded hardware, and / or other portions of PLD 100) provided by PLD 100 and their associated signals (e.g., in a logical manner, but without having yet to specify placement or routing). In some embodiments, the mapping may be performed on one or more previously stored NGD files, with the mapping results stored as physical design files (e.g., also referred to as NCD files). In some embodiments, the mapping process may be performed as part of a synthesis process in operation 320 to produce a netlist that is mapped to PLD components.

[0055] In operation 340, external system 130 performs a placement process to assign the mapped netlist components to specific physical components residing at specific physical locations of PLD 100 (e.g., to specific logic cells 200, logic blocks 104, routing resources 180, and / or other physical components of PLD 100), and thereby determine the layout of PLD 100. In some embodiments, placement may be performed on one or more previously stored NCD files, with the placement results being stored as another physical design file.

[0056] In operation 350, external system 130 performs a routing process to route connections between components of PLD 100 (e.g., using routing resources 180) based on the placement layout determined in operation 340 to implement physical interconnections between the placed components. In some embodiments, routing may be performed on one or more previously stored NCD files, with the routing results stored as another physical design file.

[0057] In various embodiments, routing the connections in operation 350 may further involve performing an optimization process on the user design to reduce propagation delays, consumption of PLD resources and / or routing resources, and / or to optimize performance of the PLD when configured to implement the user design. In some embodiments, the optimization process may be performed on a physical design file representing the converted / translated user design, and the optimization process may represent the optimized user design in the physical design file (e.g., to generate an optimized physical design file).

[0058] In some embodiments, the optimization process may include optimizing certain instances of logic function operations, ripple arithmetic operations, and / or extended logic function operations that would occupy multiple configurable PLD components (e.g., logic cells 200, logic blocks 104, and / or routing resources 180) when the PLD is configured to implement the user design. For example, the optimization process may include detecting multiple modes or configurable logic cells that implement the logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in the user design, swapping the operation modes of the logic cells that implement the various operations to reduce the number of PLD components and / or routing resources used to implement the operations and / or reduce the propagation delay associated with the operations, and / or reprogramming the corresponding LUTs and / or mode logic to account for the swapped operation modes.

[0059] In another example, the optimization process may include detecting an extended logic function operation and / or corresponding routing resources in a user design, implementing the extended logic operation as a multi-mode or switchable logic cell with a single physical logic cell output, routing or coupling logic cell outputs of a first group of logic cells to inputs of a second group of logic cells to reduce the number of PLD components used to implement the extended logic operation and / or routing resources and / or reduce propagation delays associated with the extended logic operation, and / or programming corresponding LUTs and / or mode logic to implement the extended logic function operation using at least the first group of logic cells and the second group of logic cells.

[0060] In another example, the optimization process may include detecting multiple modes or configurable logic cells implementing logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in a user design, swapping operation modes of the logic cells implementing the various operations to provide programmable registers along signal paths within the PLD to reduce propagation delays associated with the signal paths, and reprogramming corresponding LUTs, mode logic, and / or other logic cell control bits / registers to account for the swapped operation modes and / or programming programmable registers to store or latch signals on the signal paths.

[0061] Changes in routing can be propagated back to previous operations, such as synthesis, mapping, and / or placement, to further optimize various aspects of the user's design.

[0062] Thus, after operation 350, one or more physical design files may be provided that specify the user design after it has been synthesized (e.g., converted and optimized), mapped, placed, and routed (e.g., further optimized) for PLD 100 (e.g., by combining the results of the corresponding previous operations). In operation 360, external system 130 generates configuration data for the synthesized, mapped, placed, and routed user design. In various embodiments, such configuration data may be encrypted and / or otherwise protected as part of such generation process, as described more fully herein. In operation 370, external system 130 configures PLD 100 with the configuration data by, for example, loading a configuration data bitstream (e.g., a "configuration") into PLD 100 via connection 140. For example, such a configuration may be provided in an encrypted, signed, or unprotected / unauthenticated form, and PLD 100 may be configured to treat secure configurations and unprotected configurations differently, as described herein.

[0063] Figure 4 FIG. 4 is a block diagram of a secure PLD 410 according to an embodiment of the present disclosure. In various embodiments, the secure PLD 410 may be composed of a Figure 1 100, but with additional configurable and / or hard IP elements configured to facilitate operation of secure PLD 410 in trusted computing applications and / or architectures, as described herein. In particular, secure PLD 410 may include: PLD structure 400, linked to security engine 420 via various buses; configuration engine 440; non-volatile memory (NVM) 450; programmable I / O 404 and / or other integrated circuit (IC) modules 480, all of which are implemented on a single IC, as shown. In general, PLD structure 400 may be implemented with any of the various elements described with respect to PLD 100, and may be implemented using methods similar to those described with respect to PLD 100. Figure 3 The PLD structure 400 may be configured to generate and program the PLD structure 400 according to the desired configuration using the design process of the process 300 described above. More specifically, the secure PLD 400 may be configured to use a PLD structure 400 prior to programming the PLD structure 400 according to the received configuration. Figure 4 The various hard IP elements identified in the example may be used to receive, decrypt, authenticate and / or verify the received configuration.

[0064] Security engine 420 may be implemented as a hard IP resource that is configured to provide various security functions for use by PLD structure 400 and / or configuration engine 440. Figure 4In the illustrated embodiment, the security engine 420 includes a device ID 422 (e.g., a 64-bit unique and device-specific ID), a true random number generator 424, a secure hash algorithm (SHA) service 426 (e.g., SHA256, SHA-2, and / or SHA-3 services), an advanced encryption standard (AES) service 428 (e.g., AES128 / 256 encryption / decryption service), a public key / private key pair generator (P / PKG) 430, an elliptic curve digital signature algorithm (ECDSA) authentication service 432 (e.g., ECDSA256 service), and / or other security services 434. Also as shown in FIG. Figure 4 As shown, the security engine 420 may be communicatively linked to the PLD fabric 400 via the tethered bus 406 and to the configuration engine 440 via the secure bus 446. In general, the tethered bus 406 may be configured to allow the PLD fabric 400 to access a limited set of security functions hosted by the security engine 420 and / or to access such security functions in a limited manner, such as not allowing configuration of any one or all of the security functions hosted by the security engine 420, not allowing access to the device ID 422, and / or not allowing access to the private key of the public key / private key pair generated by the P / PKG 430. In contrast, the secure bus 446 may be configured to allow the configuration engine 440 to access and / or modify all security functions, data, and / or configurations of the security engine 420. In general, either or both of the tethered bus 406 and the secure bus 446 may be configured to provide encrypted and / or otherwise secure communications between the security engine 420 and other elements of the secure PLD 410.

[0065] Configuration engine 440 may be implemented as a hard IP resource configured to manage configuration of and / or communications between various elements of secure PLD 410. For example, configuration engine 440 may be configured to receive an encrypted / secure configuration of PLD structure 400 from external system 130 / machine-readable medium 136 via configuration I / O 448, authenticate and / or decrypt such configuration using security functions of security engine 420, store the authenticated and / or decrypted configuration in NVM 450, soft or hard lock a portion of NVM 450 corresponding to the stored configuration, mark the stored configuration as authenticated and / or verified bootable, and / or program PLD structure 400 according to the authenticated, decrypted, verified, and / or locked configuration, as described herein. In further embodiments, configuration engine 440 may be configured to configure at least a portion of programmable I / O 404 (eg, enable and / or disable at least a portion of programmable I / O 404) via configuration port 444, as shown.

[0066] More generally, configuration engine 440 may be configured to manage or control configuration of elements of secure PLD 410, lock states of elements of secure PLD 410, booting of PLD structure 400, and flow control of the entire secure PLD 410. For example, configuration engine 440 may be configured to, for example, soft lock or unlock or hard lock any one or portion of buses 408, 442, 443, 446, and / or soft lock or unlock or hard lock any portion or sector of NVM 450. In a default unlock configuration, buses 408, 442, and 446 may be implemented as a secure bus that is functionally similar to secure bus 446. External access bus 443 of configuration I / O 448 may be implemented according to one or more of JTAG, I2C, SPI, and / or other external access buses or protocols, for example, configured to provide lockable / unlockable access to and / or from external system 130 / machine-readable medium 136. In certain embodiments, the security bus 408 may be implemented according to a wishbone bus / interface.

[0067] NVM 450 may be implemented as a hard IP resource configured to provide secure non-volatile storage of data for facilitating secure operation of secure PLD 410. For example, NVM 450 may include a lock policy sector 460 corresponding to a memory location in the NVM that indicates a lock status of data stored in NVM 450. The contents of lock policy sector 460 may be transferred to a shadow register within configuration engine 440 upon power-up of secure PLD 410, e.g., to allow such contents to be dynamically modified by configuration engine 440 and / or PLD structure 400 based on a set / lock status in lock policy sector 460. In general, the lock status of a particular resource indicates read, write / program, and / or erase access to the resource relative to PLD structure 400, configuration I / O 448 / external access bus 443, and / or other elements of secure PLD 410.

[0068] As described herein, a "soft" lockout refers to a read, write, and / or erase access state of a bus / port or memory location in NVM 450 that can be programmatically enabled or disabled by PLD structure 400 and / or across external access bus 443 to granularly allow or disallow read, write, and / or erase access to the corresponding resource. A "hard" lockout refers to a read, write, and / or erase access state of a bus / port or memory location in NVM 450 that can be programmatically enabled via external access bus 443, but cannot be enabled or disabled by PLD structure 400 and cannot be disabled via external access bus 443. In various embodiments, assertion of a hard lockout is generally unidirectional and eliminates the ability of PLD structure 400 and / or external access bus 443 to further modify the lockout state of all secure resources within secure PLD 410. In some embodiments, such a locking scheme may be implemented with four bits for each resource (eg, a bus port or a memory sector within NVM 450), one bit each for hard lock enable, read lock enable, write lock enable, and erase lock enable.

[0069] like Figure 4As shown in the illustrated embodiment, NVM 450 may include a plurality of differentiated lockable sectors, each of which may have its own lock state. Such lockable sectors may include, for example, a first configuration image sector 452, a second configuration image sector 454, a manufacturer-specified MFG trim sector 456, a device key sector 458 (e.g., an AES key sector and a separate public key / key pair sector), a lock policy sector 460, a user flash memory (UFM) sector 462, and / or other defined secure storage sectors 464, as shown. In some embodiments, UFM sector 462 may be further differentiated into sub-sectors, each of which may have its own lock state. Lock policy sector 460 may store the lock state of each sector of NVM 450, for example, including its own lock state. For example, the first configuration image sector 452 and the second configuration image sector 454 may each store a configuration of the PLD structure 400, and may further be tagged with a version and / or date and pre-authenticated, for example, to allow them to be selected (e.g., based on the version or date) and used to program the PLD structure without performing an authentication process. The MFG trim sector 456 may be used to store manufacturer trim and / or other data specific to a particular secure PLD 410, such as a modifiable client-specific order part number and a generated client ID number derived from the device ID 422 as described herein. The device key sector 458 may be used to store encryption / decryption keys, public / private keys, and / or other security keys specific to a particular secure PLD 410. The lock policy sector 460 may be configured to store the lock status of resources of the NVM 450, the configuration engine 440, the configuration I / O 448, and / or other elements of the secure PLD 410. UFM sector 462 may be used to store user data that is generally accessible by PLD structure 400, such as configuration or application-specific security keys, certificates, and / or other secure user data. Other secure storage sectors 464 may be used to store other device-specific secure data. Any one or more individual elements, portions, or sectors of NVM 450 may be implemented, for example, as configurable memory or one-time programmable (OTP) memory, as described herein.

[0070] Programmable I / O 404 may be implemented as at least partially configurable resources configured to provide or support a communication link between PLD structure 400 and an external controller, memory, and / or other device, such as across bus 402 (e.g., a bus configured to link portions of PLD structure 400 to programmable I / O 404). In some embodiments, bus 402 and / or programmable I / O 404 may be integrated with PLD structure 400. Configuration I / O 448 may be implemented as a hard IP resource configured to support one or more external bus interfaces and / or protocols 449 to support communications with external systems 130 / machine-readable media 136, as described herein. In some embodiments, configuration I / O 448 and / or bus 443 may be integrated with configuration engine 440. More generally, in Figure 4 One or more elements of the secure PLD 410 shown as separate in FIG. 4 may be integrated with and / or within each other. Other IC modules 480 may be implemented as hard and / or configurable IP resources that are configured to facilitate the operation of the secure PLD 410.

[0071] Figure 5A FIG. 5 is a block diagram of a secure PLD provisioning system 500 according to an embodiment of the present disclosure. For example, one or more elements of the provisioning system 500 may be configured to perform operations related to Figure 7 Describe at least part of the provisioning process. Figure 5A In the illustrated embodiment, the secure PLD provisioning system 500 includes a secure PLD client 510 and a secure PLD manufacturer 520 configured to communicate with each other via a communication link 512 and a communication network 514. In general, the communication link 512 may be implemented by one or more wired and / or wireless communication links configured to support data communications to and from the communication network 514, and the communication network 514 may be implemented by one or more local area networks and / or wide area networks configured to generally support data communications (e.g., an Internet service provider, a cellular network, and / or the Internet). Each of the remaining elements of the secure PLD provisioning system 500 represents an entity in the manufacturing and delivery chain of, for example, the secure PLD 410, and may be generally implemented by a network communication device, each of which is similar in scope to the secure PLD 410. Figure 1 The secure PLD provisioning system 500 is configured to communicate across the communication link 512 and the communication network 514. In various embodiments, the secure PLD provisioning system 500 may be configured to provision keys and / or other secure communication elements and / or mechanisms for secure PLDs similar to the secure PLD 410.

[0072] like Figure 5A As shown, the secure PLD client 510 and the secure PLD manufacturer 520 can be considered trusted entities within the provisioning system 500, while all other elements of the provisioning system 500 can be considered untrusted entities, such that the client and / or manufacturer's software and / or hardware should generally be protected or otherwise secured from unwanted access or manipulation by the downstream client 550 and / or the optional secure PLD programmer 530 and user device assembler 540. For example, in a general operation, the secure PLD client 510 requests one or more secure PLDs 410 from the secure PLD manufacturer 520 and generates a proprietary configuration to be programmed into the PLD structure 400 of the secure PLD 410. The secure PLD manufacturer 520 prepares the requested one or more secure PLDs 410 by manufacturing individual ICs and programming them with a security mechanism (e.g., locking them) to inhibit further programming by configurations not provided by the secure PLD client 510 and / or the secure PLD manufacturer 520. The secure PLD client 510 may provide the device-specific encryption configuration to an optional secure PLD programmer 530, and the secure PLD manufacturer 520 may provide the locked secure PLD 410 to the secure PLD programmer 530, such that the secure PLD programmer 530 can only program each locked secure PLD 410 with its device-specific encryption configuration, and such that the secure PLD programmer 530 cannot easily determine the unencrypted contents of the device-specific encryption configuration.

[0073] The secure PLD programmer 530 may deliver the programmed and locked secure PLD 410 to an optional user device assembler 540 (e.g., a motherboard assembler, a smartphone assembler, and / or other user device / embedded device assembler / manufacturer), which integrates the programmed and locked secure PLD 410 with the user device and provides the integrated user device to a downstream client 550, all without the secure PLD programmer 530 and the downstream client 550 being able to determine the unencrypted contents of the device-specific cryptographic configuration or reprogram the locked secure PLD with an alternate configuration. The secure PLD client 510 may then audit the programmed and locked secure PLD 410 in the corresponding user device at the downstream client 550 without revealing the unencrypted contents of the device-specific cryptographic configuration or unlocking the secure PLD 410. Although in Figure 5A 5. Although shown as separate entities in FIG. 5, secure PLD programmer 530 and user device assembler 530 may be combined together and / or separately integrated with secure PLD client 510, secure PLD manufacturer 520, and / or downstream client 550.

[0074] Figure 5BFIG. 5 is a block diagram of a secure PLD provisioning system 502 according to an embodiment of the present disclosure. For example, one or more elements of the provisioning system 502 may be configured to perform operations related to Figure 7 In one embodiment, the secure PLD provisioning system 502 may correspond substantially to Figure 5A More generally, a system similar to or including elements of the secure PLD provisioning system 502 may be used to implement a secure PLD manufacturer 520. Figure 5A Any one or more of the elements of secure PLD provisioning system 500 as shown.

[0075] exist Figure 5B In the illustrated embodiment, the secure PLD provisioning system 502 includes a secure PLD locking system 522 configured to lock and / or redirect a plurality of secure PLDs 410 (e.g., unlocked / blank secure PLDs 410 and / or previously locked secure PLDs 410 intended for redirection to a different secure PLD client or request) from a secure PLD inventory / storage area 524 based on requests issued by secure PLD clients 510. Once locked by the secure PLD locking system 522, the locked secure PLDs can generally only be programmed with a configuration provided by a secure PLD client 510, such as by the secure PLD locking system 522 or more generally by a secure PLD programmer 530, as described herein. In various embodiments, the secure PLD locking system 522 may include a hardened security module (HSM) 526 configured to receive a client public key from the secure PLD client 510, for example, via the non-secure communication link 512, and control the external system 130 via the secure communication link 527 to lock the secure PLD 410 provided via the device delivery link 525 (e.g., a mechanical and / or electronic delivery link configured to retrieve the secure PLD 420 from the PLD inventory / storage area 524 and interface the configuration I / O 448 of the secure PLD 410 with the external system 130 via the external bus interface 449). The locked secure PLD 410 may then be physically delivered to the secure PLD programmer 530 via a similar device delivery link 528. For example, the HSM 526 may be implemented generally similarly to the external system 130, but placed in a secure factory location with monitored and limited physical access to eliminate the risk of external manipulation and / or monitoring of the HSM 526. In some embodiments, external system 130 and HSM 526 and / or their functionality may be integrated into a single external system 130 .

[0076] In general operation, the secure PLD client 510 may provide a request for a plurality of locked secure PLDs 410 to the HSM 526, the request including a client public key of a client public key / private key pair (e.g., generated within the secure PLD client 510, such as generated by its own HSM). The HSM 526 may generate a client-specific programming public key / private key pair (e.g., for encrypting, decrypting, and / or authenticating a configuration for a locked secure PLD 410, such as locking the secure PLD 410 and unlocking the secure PLD 410 for programming) and a programming secret (e.g., a 256-bit random number to further authenticate the provided configuration), and provide the programming private key, programming secret, and factory public key to the external system 130 for loading into a blank or unlocked secure PLD 410 and locking the blank or unlocked secure PLD 410. For example, the HSM 526 may be configured to locally generate a factory public key / private key pair and / or retrieve such a factory key from the memory 134, and such a factory key may be factory-specific and / or client-specific. Configuration engine 440 may receive a device-specific tracking ID (e.g., which may identify a manufacturing batch, wafer, and wafer location corresponding to the manufacturing process of secure PLD 410), a programming private key, a programming secret, a factory public key, and an initial programming image (IPI) configuration of PLD structure 400, which may all be stored in one or more sectors of NVM 450 to lock secure PLD 410.

[0077] The configuration engine 440 may then store the tracking ID in the MFG trim sector 456 of the NVM 450 and / or in the device ID 422 of the security engine 420, and generate a device unique seed by appending a random number (e.g., generated by the TRNG 424) to the end of the tracking ID, and such device unique seed may be stored in the MFG trim sector 456 and / or used for seed generation of a device public / private key pair (e.g., generated by the P / PKG 430 of the security engine 420), which may be stored in the device key sector 458 of the NVM 450. The configuration engine 440 may then provide the resulting device public key and tracking ID to the external system 130, which may relay the device public key and tracking ID to the HSM 526 to be added to the locked PLD inventory, which includes a line item for each locked secure PLD 410 requested by the secure PLD client 510, wherein each line item includes a device-specific tracking ID and a device public key. The HSM 526 may then encrypt and sign the programming secret using the client public key and the programming private key, and may provide the resulting encrypted programming packet to the secure PLD client 510 along with the programming public key (e.g., to help generate an encrypted and signed configuration of the PLD structure 400 of the secure PLD 410). Once all locked secure PLD 410 entries requested by the secure PLD client 510 are complete, the HSM 526 may sign the locked PLD manifest using the programming private key and provide the signed locked PLD manifest to the secure PLD client 510, which may then use the locked PLD manifest, the programming secret, and the programming public key to manage programming of the locked secure PLD 410 by the secure PLD programmer 530, as described herein.

[0078] In some embodiments, the HSM 526 may be configured to generate a client programming key token corresponding to a particular secure PLD client 510 and / or a particular request for a locked secure PLD 410 received from a secure PLD client 510. Such a client programming key token may be used to reference (e.g., within a client database stored in the HSM 526) all information stored about the secure PLD client 510 and / or a request for a locked secure PLD 410 received from a secure PLD client 510. Such stored information may include a programming public / private key pair, a programming secret, a factory public / private key pair, a locked PLD inventory, and / or other information or subsets of information associated with the operation of the secure PLD provisioning system 502 and / or 500. In embodiments where the PLD inventory / storage area 524 includes one or more pre-locked secure PLDs 410 for redirection (e.g., locked to a different secure PLD client or a different secure PLD request), the HSM 526 may be configured to use a previous client programming key token to retrieve information used to lock the locked secure PLD, provide new information to the secure PLD 410 signed using a previous factory private key (e.g., via the external system 130), and provide a redirect command to the secure PLD 410 (e.g., to be executed by the secure PLD 410), wherein the redirect command is executed by the PLD fabric 400 and / or configuration engine 440 to authenticate the new information with a previous factory public key stored in the NVM 450 and replace the previous information (e.g., device public / private key pair, programming private key, programming secret, factory public key, and / or IPI) stored in the NVM 450 with corresponding new or updated information.

[0079] Figure 6A block diagram of a user device 610 including a secure PLD 410 according to an embodiment of the present disclosure is shown. In one embodiment, the secure PLD 410 may be configured to provide a secure boot mechanism for the user device 610 (e.g., a motherboard, a smart phone, and / or other user / embedded device). For example, when the user device 610 is powered on, the secure PLD 410 may be configured to use the P / PKG 430 of the security engine 420 to generate a temporary public key / private key pair and provide the temporary public key and a controller boot loader 662 (e.g., which may be pre-authenticated and / or stored in the UFM 462 of the NVM 450) to the controller 620 via a bus 604 (e.g., a bus supported by the programmable I / O 404). The execution engine 624 of the controller 620 may be configured to execute the controller boot loader 662 upon receiving the controller boot loader 662 from the secure PLD 410, and the secure PLD 410 may configure the execution engine 624 to generate a temporary session key (e.g., using a power-on RAM value derived from a power-on state of the volatile memory (VM) 612), to encrypt the temporary session key using a temporary public key and a cryptographic salt provided by the secure PLD 410, and to provide the resulting first encrypted packet to the secure PLD 410 via the bus 604.

[0080] The security PLD 410 may be configured to extract a temporary session key (e.g., using a temporary private key) from a first encrypted packet provided by the controller 620 to encrypt the controller application image decryptor 663 using the session key, and provide the resulting second encrypted packet to the controller 620 via the bus 604. The execution engine 624 of the controller 620 may be configured to extract the controller application image decryptor 663 from the second encrypted packet upon receiving the second encrypted packet from the security PLD 410, and the security PLD 410 may configure the execution engine 624 to retrieve, authenticate, and decrypt the controller application image 632 stored in the NVM 630 (e.g., via the buses 602 and 604), store the authenticated and decrypted controller application image 632 in the VM 622, and execute the authenticated and decrypted controller application image 632. In addition, the security PLD 410 and the controller 620 may be configured to register a secure communication path with each other.

[0081] In another embodiment, the security PLD 410 may be configured to use the controller 620 to verify the configuration of the PLD structure 400 used to program the security PLD 410. For example, the security PLD 410 may be configured to use the P / PKG 430 of the security engine 420 to generate a temporary public / private key pair and provide the temporary public key to the controller 620. The execution engine 624 of the controller 620 may be configured to generate a temporary session key, encrypt the temporary session key using the temporary public key and a cryptographic salt provided by the security PLD 410, and provide the resulting third encrypted packet to the security PLD 410 via the bus 604. The controller 620 may also be configured to use the session key to encrypt a request to extract identification data from one or more configuration images stored, for example, in the NVM 450 of the security PLD 410, and send the resulting fourth encrypted packet to the security PLD 410 via the bus 604.

[0082] The secure PLD 410 may be configured to extract the temporary session key from the third encrypted packet provided by the controller 620, extract a request from the fourth encrypted packet using the temporary session key to extract the requested identification data from one or more configuration images stored in the NVM 450 of the secure PLD 410, encrypt the requested identification data using the temporary session key, and provide the resulting fifth encrypted packet to the controller 620 via the bus 604. Once received, the controller 620 may be configured to verify the version, release date, and / or other characteristics of the one or more configuration images stored in the NVM 450 by comparing with a database of versions, release dates, and / or other characteristics of the one or more configuration images stored in the NVM 450 that resides in the user device 610 (e.g., in the NVM 630 or VM 622) and / or that is accessible or retrieved from a network (e.g., the communications network 514, via other user device modules 680, which may include a network interface device). In further alternative embodiments, secure PLD 410 may replace controller 620 and be used to control the operation of user device 600 .

[0083] Figure 7 FIG. 2 shows a provisioning process for a locked secure PLD according to an embodiment of the present disclosure. In some embodiments, Figure 7 The operations may be implemented as software instructions by Figures 1 to 6 The corresponding electronic devices, modules and / or structures shown are associated with one or more logic devices. More generally, Figure 7The operations of the process 700 may be implemented with any combination of software instructions and / or electronic hardware (e.g., inductors, capacitors, amplifiers, actuators, or other analog and / or digital components). It should be understood that any step, sub-step, sub-process, or block of the process 700 may be different from Figure 7 For example, in other embodiments, one or more blocks may be omitted from process 700, and other blocks may be included. In addition, block inputs, block outputs, various sensor signals, sensor information, calibration parameters, and / or other operating parameters may be stored in one or more memories before moving to subsequent portions of process 700. Although reference is made to Figures 1 to 7 The process 700 is described with reference to systems, devices, and elements of the present invention, but the process 700 may be performed by other systems, devices, and elements, and include different selections of electronic systems, devices, elements, components, and / or arrangements. At the start of the process 700, for example, various system parameters may be populated by previous executions of processes similar to the process 700, or may be initialized to zero and / or one or more values ​​corresponding to typical, stored, and / or learned values ​​derived from past operations of the process 700, as described herein.

[0084] In block 710, the logic device receives a request for a locked PLD. For example, a network communication device (e.g., external system 130, HSM 526) of a secure PLD manufacturer 520 may be configured to receive a request for a locked secure PLD 410 from a network communication device (e.g., external system 130, HSM 526) of a secure PLD client 510. For example, such a request may be sent over a communication link 512 and / or over a communication network 514, and may include a client public key of a corresponding client public key / private key pair, as well as the number of the device being requested and any specific model or other identification information associated with the particular desired secure PLD 410.

[0085] In block 720, the logic device generates a locked PLD. For example, the secure PLD manufacturer 520 may be configured to generate a locked secure PLD 410. In some embodiments, the secure PLD manufacturer 520 may use an IC manufacturing system to manufacture the secure PLD 410, which may include, for example, programming or storing or otherwise embedding the device ID 422 in the security engine 420 and / or MFG trim sectors 456 of the NVM 450. The secure PLD manufacturer 520 may also use an external system 130 to lock the secure PLD 410, as described herein. In one embodiment, the secure PLD locking system 522 of the secure PLD manufacturer 520 may be configured to assign a client ID to the secure PLD client 510 and / or the request received in block 710, which may then be combined with the device ID 422 and / or a device order part number (e.g., generated at manufacturing time) to provide a client-specific order part number that may be used to reference or identify the secure PLD 410, for example, in an unencrypted database stored in the HSM 526.

[0086] The HSM 526 may also be configured to generate a client programming key token corresponding to the client public key in the secure PLD client 510 and / or the request received in block 710 by generating a corresponding random and unique client programming key token and / or client-specific order part number and referencing all stored information associated with generating a locked secure PLD referencing such a token or number. The HSM 526 may also be configured to generate a programming public / private key pair and a programming secret, all of which may be specific to the secure PLD client 510 and / or the request received in block 710, all of which may be stored in the HSM 526. The HSM 526 may also be configured to generate a factory public / private key pair, which may be specific to the secure PLD manufacturer 520, the secure PLD client 510, and / or the request received in block 710, which may also be stored in the HSM 526.

[0087] For example, the HSM 526 may be configured to provide the factory public key, programming private key, and programming secret to the external system 130 for programming / locking the secure PLD 410, and receive the device-specific tracking ID and the device public key in response. The HSM 526 may also be configured to encrypt and sign the programming secret using the client public key and the programming private key, and the resulting encrypted programming packet may be provided to the secure PLD client 510 along with the programming public key (e.g., to help the secure PLD client 510 generate an encrypted and signed configuration of the PLD structure 400 for the secure PLD 410). The secure PLD 410 may be configured to use the TRNG 424 of the security engine 420 to generate a device unique seed based on the tracking ID stored in the MFG trim sector 456 and / or the device ID 422, and to use the device unique seed of the security engine 420 and / or the P / PKG 430 to generate a device public key / private key pair, all of which are specific to the secure PLD 410, and all of which may be stored in the NVM 450 (e.g., along with a programming private key, programming secret, factory public key, and / or IPI configuration provided by the external system 130 and / or the HSM 526).

[0088] In another embodiment, the HSM 526 may be configured to retrieve the programming private key, programming secret, and device public key from a securely stored database using the client programming key token and provide them to the external system 130. The external system 130 may then be configured to use the programming private key, programming secret, and / or device public key to provide an IPI configuration to the secure PLD 410 and program the PLD structure 400 using the IPI. This programming may constitute an unsecure write operation and therefore may require a secure environment (e.g., occurring entirely within the secure PLD manufacturer 520). In a further embodiment, the HSM 526 may be configured to receive a locked PLD manifest entry including a tracking ID corresponding to the secure PLD 410 and a corresponding device public key from the external system 130, generate a complete locked PLD manifest corresponding to the request received in block 710, sign the locked PLD manifest with the programming private key, and provide the signed locked PLD manifest to the secure PLD client 510.

[0089] In other embodiments, it may be useful to redirect an already programmed and locked secure PLD to a different client or application (e.g., using a different programming key pair, programming secret, and public device key). Typically, there is no need to reprogram an already programmed IPI (e.g., the same IPI configuration of PLD structure 400 may be used). For example, HSM 526 may be configured to use a client programming key token and / or tracking ID to retrieve the previous information used to lock secure PLD 410 (e.g., the original programming private key, programming secret, and device public key stored in HSM 526). The HSM 526 may then be configured to use the external system 130 to provide the new information to the secure PLD 410 signed using the previous factory private key, and to provide a redirect command to the secure PLD 410 (e.g., to be executed by the secure PLD 410), where the redirect command may be executed by the PLD fabric 400 and / or configuration engine 440 to authenticate the new information with the previous factory public key stored in the NVM 450, and replace the previous information (e.g., a device public / private key pair, a programming private key, a programming secret, a factory public key, and / or an IPI) stored in the NVM 450 with the corresponding new or updated or redirected information, as described herein.

[0090] In block 730, the logic device provides a secure unlock package for the locked PLD. For example, the HSM 526 of the secure PLD manufacturer 520 may be configured to provide a secure unlock package for the locked secure PLD 410 generated in block 720 to the secure PLD client 510. In one embodiment, the HSM 526 may be configured to provide the encrypted programming packet, programming public key, and / or client programming key token generated in block 720 to the secure PLD client 510. The secure PLD client 510 may use such information to generate a protected configuration of the secure PLD 410, as locked in block 720.

[0091] In block 740, the logic device provides a certifiable list identifying the locked PLD. For example, the secure PLD manufacturer 520 may be configured to provide a certifiable list of locked PLDs identifying the locked secure PLDs 410 generated in block 720. In one embodiment, the HSM 526 may be configured to generate a list of tracking IDs and device public keys (e.g., a list of device public keys referenced by the tracking IDs), sign the locked PLD list using the programming private key generated in block 720, and provide the signed locked PLD list to the secure PLD client 510. The secure PLD client 510 may use such information to audit the selection of deployed and / or locked secure PLDs 410.

[0092] In block 750, the logic device generates a protected configuration for the locked PLD. For example, the external system 130 of the secure PLD client 510 may be configured to generate a protected configuration for the locked secure PLD 410 generated in block 720. In one embodiment, the external system 130 may be configured to generate a protected configuration for the locked secure PLD 410 using a method similar to that described in reference to FIG. Figure 3 The process 300 discussed above is used to generate an unprotected configuration of the PLD structure 400 of the secure PLD 410. Such a configuration may include, for example, an application bitstream / configuration to be primarily loaded into and configure the PLD structure 400, and a feature bitstream / configuration to be primarily loaded into and configure the lock policy sector 460, the UFM sector 462, and / or other defined secure storage sectors 464. Such a feature bitstream / configuration may include security keys, functions, and / or other features that may be executed and / or otherwise used by the configuration engine 440 to implement any of the processes described herein.

[0093] In various embodiments, the HSM 526 of the external system 130 and / or the secure PLD client 510 may be configured to generate an application public / private key pair, an application encryption key (e.g., an AES encryption key), and a programming group public / private key pair. The external system 130 may be configured to sign the application and feature configuration using the application private key, and to encrypt the signed application and feature configuration using the application encryption key. The external system 130 may also be configured to generate a programming key digest by signing a combination / list of the application public key, the application encryption key, and the programming secret (e.g., extracted from the encrypted programming group of the secure unlock package provided in block 730) and the application private key, deriving an encryption key based on the programming public key and the programming group private key (e.g., using an elliptic curve Diffie-Hellman key derivation function), encrypting the signed combination of the keys using the derived encryption key, and combining the encrypted and signed key combination with the programming group public key (e.g., appending the programming group public key to the encrypted and signed key combination) to create the programming key digest. External system 130 may also be configured to sign the locked PLD manifest (e.g., received in block 740) with the group private key for authenticated delivery to downstream secure PLD programmer 530, user device assembler 540, and / or downstream client 550. External system 130 may be configured to generate a protected configuration for secure PLD 410 by combining the encrypted application and feature configurations with the programming key digest to create a single protected information packet.

[0094] In block 760, the logic device provides the locked PLD to the configuration programmer. For example, secure PLD manufacturer 520 may be configured to provide the locked secure PLD 410 generated in block 720 to secure PLD programmer 530, as described herein.

[0095] In block 770, the logic device programs the locked PLD according to the protected configuration. For example, the external system 130 of the secure PLD programmer 530 may be configured to program the locked secure PLD 410 generated in block 720 according to the protected configuration generated in block 750 and provided by the secure PLD client 510. In one embodiment, the external system 130 of the secure PLD programmer 530 may be configured to provide the protected configuration / packet generated in block 750 to the secure PLD 410, and the secure PLD 410 may be configured to boot according to the IPI provided to the secure PLD 410 in block 720. The secure PLD 410 may then validate the protected configuration and program elements of the secure PLD 410, including portions of the PLD structure 400 and the NVM 450, through one or more buses of the secure PLD 410. More specifically, security PLD 410 may be configured to decrypt the encryption key in the programming key digest using the programming private key stored in NVM 450 in block 720 and the group public key generated in block 750. In block 720, security PLD 410 may also be configured to authenticate the decrypted key digest with the application public key and verify that the programming secret in the programming key digest matches the programming secret stored in NVM 450. If both checks pass, security PLD 410 may store the application public key and the application encryption key from the key digest in NVM 450.

[0096] Once the application public key and the application encryption key from the key digest are stored in NVM 450, the secure PLD 410 can then decrypt the application and feature configuration and authenticate the decrypted application and feature configuration. For example, the application and feature configuration can be programmed into the secure PLD 410 only if the bitstream is successfully decrypted and authenticated using the application encryption key and the application public key. In the event that the application configuration is successfully authenticated, the secure PLD 410 can be configured to program / store the application configuration into one of the configuration image sectors 452 or 454, set the pre-authentication bit for the appropriate image, erase the IPI from the PLD structure 400, and / or program the PLD structure 400 according to the stored application configuration. The feature configuration can be programmed into one or more portions of the NVM 450. Other security checks to be performed before programming the secure PLD 410 can include validating a locked PLD manifest, checking for a tracking ID match within the locked PLD manifest, and / or other security checks, as described herein.

[0097] In block 780 , the logic device assembles the user device including the locked and programmed PLD. For example, the pick and place system of the user device assembler 540 may be configured to assemble the user device 610 including the locked secure PLD 410 generated in block 720 and programmed in block 770 .

[0098] In block 790, the logic device audits the locked and programmed PLDs based on the authenticatable list. For example, the secure PLD client 510 may be configured to audit the locked secure PLD generated in block 720 and programmed in block 770 based on the authenticatable locked PLD list provided in block 740. In one embodiment, the secure PLD client 510 or the external system 130 of the downstream client 550 may be configured to authenticate the locked PLD list provided by the secure PLD manufacturer 520 or the secure PLD client 510 in block 740, query the secure PLD 410 for its tracking ID and / or device public key and compare with the tracking ID and device public key in the locked PLD list, and challenge the secure PLD 410 using the device public key, such as by encrypting a random number using the device public key, providing the resulting encrypted packet to the secure PLD 410 in a device key challenge, and comparing the returned result with the original random number (e.g., a matching result indicates a successful audit of the operational secure PLD 410). In some embodiments, such an audit may occur before erasing the IPI configuration in block 770. A successful audit indicates that the security PLD 410 is functionally locked.

[0099] Thus, by employing the systems and methods described herein, embodiments of the present disclosure are able to provide flexible and secure key provisioning and configuration of secure PLDs across client orders of secure PLDs. A protected configuration of one client cannot be used to program another client's personalized secure PLD or a blank secure PLD. The protected configuration can be programmed within the system or using an external device. Application keys can only be decrypted within the secure PLD. Clients can use key manifests to prevent device and / or application spoofing or overbuilding. In various embodiments, programming keys and manifests are managed by one or more HSMs 526 of the secure PLD manufacturer 520 and / or secure PLD client 510.

[0100] To help reduce or eliminate the risk of a client or manufacturer's PLD fabric configuration / image, keys, and / or other secure data being lost or extracted from a locked or unlocked secure PLD 410, or to help reduce or eliminate the risk of such data being reprogrammed, secure PLD 410 may implement one or more lock policy management rules in accordance with a lock policy scheme and / or other secure asset arrangements, for example, which may be used by PLD fabric 400, configuration engine 440, and / or other elements of secure PLD 410 to manage read, write, and / or erase access to assets of secure PLD 410 and enforce lock states. In the most general sense, secure PLD 410 may be configured to assign lock states to various assets of secure PLD 410, such as ports of configuration I / O 448 and / or sectors of NVM 450, and / or to groups of such assets, to protect locked and / or unlocked operations of secure PLD 410, as described herein. For example, access to such assets may be locked to prevent external access (e.g., via configuration I / O 448), internal access (e.g., via PLD fabric 400), both external and internal access, and / or locked to prevent any further access regardless of the type of access. Such access may be finely controlled, such as providing read, write, and / or erase access to each asset associated with NVM 450, or read and / or write access (e.g., data communications access) across configuration I / O 448. The lock status associated with an asset or group of assets may be implemented by a lock status bit that is configured to manage, store, or represent read, write, and / or erase access, such as in accordance with a particular lock policy scheme or arrangement that may be modified to provide a particular desired granularity of secure asset management for secure PLD 410.

[0101] Fig. 8A FIG. 8 is a block diagram of a lockout strategy plan 802 for a secure PLD 410 according to an embodiment of the present disclosure. In various embodiments, the lockout strategy plan 802 may be similar to that described with respect to FIG. Figure 4 In particular, the lock policy scheme 802 may be implemented by the lock policy sector 460 and the corresponding shadow register 860 of the configuration engine 440 to allow elements of the secure PLD 410 (e.g., the external system 130 on the configuration I / O 448, the configuration engine 440, the PLD structure 400, and / or other elements of the secure PLD 410) to manipulate the lock states of various elements of the secure PLD 410.

[0102] For example, in Fig. 8AIn the illustrated embodiment, the shadow registers 860 include: configuration image lock states 852 and 854, configuration I / O lock state 848, lock policy lock state 861, device key lock state 858 and other secure storage lock sectors 864 (e.g., associated with corresponding sectors in NVM 450, configuration I / O 448 and / or external access bus 443), as well as configuration security lock state 841 in boot lock state group 892, UFM lock state 862 (e.g., associated with corresponding UFM sector 462 in NVM 450), and user security lock state 840 in user data lock state group 894, and MFG trim lock state 856. Each lock state of shadow register 860 can be assigned its own individual local read, write / program and / or erase access state, and each lock state group can be assigned its own group read, write / program and / or erase access state, which operates to reduce access to all assets with lock states within the group, so that the group lock state can only override the more permissive local lock states within the group. More specifically, configuration security lock state 840 can represent a group lock state for boot lock state group 892, and user security lock state 841 can represent a group lock state for user data lock state group 894.

[0103] Each lock state may be implemented by one or more registers within shadow registers 860 of configuration engine 440, which are configured, for example, to shadow corresponding lock states stored within lock policy sector 460 of NVM 450. In various embodiments, upon power-up of secure PLD 410, configuration engine 440 may be configured to: access lock policy sector 460, retrieve various lock states from lock policy sector 460, and shadow the lock states within shadow registers 860, and allow the various lock states to be dynamically accessed and / or modified by configuration engine 440 and / or PLD structure 400 depending on the settings / lock states in lock policy sector 460 in accordance with lock policy schedule 802. Specifically, the configuration I / O lock state 848 can be configured to store or represent or indicate a read and / or write access state corresponding to one or more ports of the configuration I / O 448 (e.g., JTAG, SSPI, I2C and / or other ports or protocols supported by the configuration I / O 448), which can be used to lock or unlock the respective ports to receive and / or provide data across the configuration I / O 448 and / or the external access bus 443. The lock policy lock state 861 may be configured to store, or represent, or indicate a read, write, and / or erase access state corresponding to the lock policy sector 460 (e.g., which may be used to lock or unlock access to all lock states (such as a super group lock state) stored in the lock policy sector 460. For example, the UFM 462 may include multiple separate and / or differentiated sectors or sub-sectors, so the UFM lock state 862 may be configured to provide a granular local lock state for each sector or sub-sector of the UFM 462, and the user security lock state 841 may be configured to provide a group lock state for the user data lock state group 894, as described herein.

[0104] Read, write and / or erase access and / or other lock states can be configured to provide relevant access to sectors of NVM 450 to help provide secure access to such assets without the risk of data leakage within such assets. For example, the lock state bits may allow sectors of NVM 450 to be, for example, (1) erased but not read or written, (2) written or erased but not read, (3) read but not written or erased, or (4) neither read, written or erased, or various combinations of these. For example, a particular lock state may allow public or private keys or encryption keys to be written but not read, or allow configuration image sectors to be erased but not read or updated, and / or allow configuration image sectors to be erased but not read, to help ensure the security and integrity of client and / or manufacturer data. Each of these types of access can be set and / or controlled differently with respect to or for external or internal access, as described herein.

[0105] Figure 8BFIG. 8 is a block diagram of a lockout strategy plan 804 for a secure PLD according to an embodiment of the present disclosure. The lockout strategy plan 804 includes a lockout strategy plan similar to Fig. 8A The elements shown in the lock policy plan 802 of the embodiment of the present invention are as follows, except that the various lock states are arranged according to different boot lock state groups 896: the different boot lock state group 896 only includes the configuration image lock state 852 and 854 and the configuration I / O lock state 848 and the configuration security lock state 840 in the boot lock state group 896, and the lock policy lock state 861, the device key lock state 858 and the other secure storage lock sectors 864 are ungrouped and are therefore subject to their local lock states and not to the boot or user data group lock states, as shown. It should be understood that similar techniques can be used to implement other lock policy plans with other groupings and / or non-groupings to simplify, for example, lock policy operations, or to provide different levels of lock policy granularity.

[0106] 9A to 9D 802 shows an access table associated with a corresponding lock policy plan for secure PLD 410 according to an embodiment of the present disclosure. In particular, access table 902 shows external bus and internal bus accessibilities associated with various lock states arranged according to lock policy plan 802. For example, Fig. 9A Access table 902 of FIG. 8 illustrates how lock policy plan 802 provides granular management of external and internal bus access for read, write / program, and erase of configuration image sectors 452 and 454 in NVM 450 by grouping configuration I / O lock state 848 and configuration image lock state 852 and 854. In this approach, as shown, internal access to PLD structure 400 may be allowed or disallowed by setting one or more group and / or local lock state bits in configuration image lock state 852 and 854 and / or configuration security lock state 840, but in Fig. 9AIn the illustrated embodiment, such access also allows external access to configuration image sectors 452 and 454 (e.g., the soft lockout portion of external bus and internal bus access is the same). In some embodiments, secure PLD 410 and / or PLD structure 400 and / or configuration engine 440 of external system 130 may be configured to update configuration I / O lock state 848 (e.g., local lock state) to lock configuration I / O 448 (e.g., prevent read and / or write access through configuration I / O 448) before adjusting the lockout state bits in configuration image lockout states 852 and 854 and / or configuration security lockout state 840 to allow internal access (e.g., read, write / program, erase) to configuration image sectors 452 and 454 without risk of intervention or loss of external system 130. As can be seen in access table 902, once the hard locks for configuration image lock states 852 and 854 and configuration security lock state 840 are enabled, no further modification of the hard lock bits is allowed either through configuration I / O 448 / external bus 443 or by PLD structure 400 through secure bus 408.

[0107] Fig. 9B The access table 904 of FIG. 1 illustrates how different lock policy plans / arrangements can provide differentiated granularity management of external and internal bus accesses to read, write / program, and erase configuration image sectors 452 and 454 in NVM 450 (e.g., by not grouping configuration I / O lock state 848 and configuration image lock state 852 and 854). In this approach, external access by external system 130 via configuration I / O 448 / external bus 443 can be allowed or not allowed by setting one or more group and / or local lock state bits in configuration image lock state 852 and 854 and / or configuration security lock state 840, as shown, but in Fig. 9B In the embodiment shown, such access applies only to external access to configuration image sectors 452 and 454, and PLD structure 400 has free access unless hard locks for configuration image lock states 852 and 854 and configuration security lock state 840 are enabled, after which no further modification of the hard lock bits is allowed either through configuration I / O 448 / external bus 443 or through PLD structure 400.

[0108] Fig. 9CAccess table 906 of FIG. 906 illustrates how a lock policy plan / arrangement including multiple types of soft locks (e.g., additional granularity with respect to external or internal or total soft locks) can provide differentiated granularity management of external and internal bus accesses for reading, writing / programming, and erasing configuration image sectors 452 and 454 in NVM 450 (e.g., by adding additional lock status bits or fabric write block (WB) bits to enable or disable access specifically by PLD fabric 400). Fig. 9C As shown, this approach includes aspects of accessing both tables 902 and 904, and the structure WB bit itself may be enabled or disabled by PLD structure 400 and / or by configuring I / O 448 / external bus 443, depending on the corresponding lock state in lock policy lock state 861. For example, such a structure WB bit may be configured to allow an embodiment to prevent accidental internal modification of configuration images or other data in NVM 450.

[0109] As can be seen in access table 906, when external soft lockout is enabled (e.g., fabric WB bit is disabled), external access through configuration I / O 448 / external bus 443 may be allowed or disallowed by setting one or more group and / or local lock status bits in configuration image lockout status 852 and 854 and / or configuration security lockout status 840, and PLD structure 400 has free and open access to configuration image sectors 452 and 454. When general soft lockout is enabled (e.g., fabric WB bit is enabled), external access through configuration I / O 448 / external bus 443 and internal access by PLD structure 400 may be allowed or disallowed by setting one or more group and / or local lock status bits in configuration image lockout status 852 and 854 and / or configuration security lockout status 840, as shown. As with access tables 902 and 904, once hard locks are enabled for configuration image lock states 852 and 854 and configuration security lock state 840, no further modifications to the hard lock bits are allowed through configuration I / O 448 / external bus 443 or through PLD structure 400, and the state of the structure WB bit no longer results in a change in the lock state of configuration image sectors 452 and 454.

[0110] Fig.9D Access table 908 shows how a lock policy plan / arrangement including multiple types of hard locks (e.g., additional granularity regarding external or internal or total hard locks) can provide differentiated granular management of external and internal bus accesses to read, write / program and erase configuration image sectors 452 and 454 and / or other sectors in NVM 450, such as device key sector 458. Fig.9D As shown, this method includes multiple aspects of accessing tables 902, 904, and 906. For example, in Fig.9D In the embodiment shown, Figure 8B 804 in , the corresponding lock policy plan / arrangement places the device key lock state 858 outside the boot lock state group 892 / 896 and the user data lock state group 894. If device key changes are not expected, policy 9 may be applied to lock the device key sector 458 from any internal or external access, and such application may, for example, permanently disable external access, or permanently disable external and internal access (e.g., by blocking internal access to the lock policy sector 460). If certain limited future device key changes are expected, policy 6 may be applied to hard lock external access to the device key sector 458, but allow the PLD structure 400 to adjustably access the device key sector 458, as shown.

[0111] For example, in one embodiment, PLD structure 400 may be configured to receive a new configuration image via programmable I / O 404, decrypt and / or authenticate the new configuration image using a device key stored in device key sector 458, and store the new configuration image in one of configuration image sectors 452 or 454 (and set the authentication bit to indicate that the stored new configuration image is bootable without requiring another authentication process) and / or boot the new configuration image. When booting a new configuration image, PLD structure 400 may be configured to set device key lock state 858 to allow write and / or erase access to device key sector 458 and / or UFM sector 462, download new keys via a secure channel (e.g., established by PLD structure 400 via programmable I / O 404), write the new keys to UFM sector 462, erase device key sector 458, copy the new keys from UFM sector 462 to device key sector 458, download an additional configuration image for PLD structure 400, decrypt and / or authenticate the additional new configuration image using the new keys, and store the additional new configuration image in one of configuration image sectors 452 and 454 (and include setting the authentication bit to indicate that the stored additional new configuration image is bootable without requiring another authentication process) and / or boot the new configuration image. Such a process allows embodiments to securely update keys and configuration images as part of a single or unified method.

[0112] In another embodiment, a “golden” configuration image of the PLD structure 400 may be permanently stored in the configuration image sector 452 (e.g., as a known good backup configuration of the PLD structure 400, in the configuration image lock state 852, with the corresponding hard lock enabled), and an updateable configuration image of the PLD structure 400 may be stored in the configuration image sector 452 (e.g., in the configuration image lock state 854, with the corresponding hard lock disabled). For example, the configuration image may be updated according to the configuration image sector 452. Fig.9D In policy 9, hard lock configuration image lock state 852, and can be based on Fig.9D 4. In such an embodiment, the secure PLD 410 may be configured to update the configuration image stored in the configuration image sector 454. For example, the external system 130 may be configured to provide an unlock request (e.g., identifying the configuration image stored in the configuration image sector 454) to the PLD structure 400 through the configuration I / O 448 and through the configuration engine 440, and the PLD structure 400 may be configured to receive, validate and / or authenticate the unlock request, and unlock the configuration image sector 454 for programming by the external system 130 and / or by the PLD structure 400 according to the updated configuration image provided by the external system 130. PLD structure 400 may also be configured to receive a lock request (e.g., identifying an updated configuration image stored in configuration image sector 454) from external system 130 via configuration I / O 448 and via configuration engine 440, and PLD structure 400 may be configured to receive, validate and / or authenticate the lock request and hard lock configuration image sector 454 or soft lock configuration image sector 454 against further external access, as described herein.

[0113] In another embodiment, both configuration image sector 452 and configuration image sector 454 may be updated with a new configuration image provided by external system 130. For example, PLD structure 400 may be configured to determine one configuration image sector to lock against external access (e.g., the most recently authenticated configuration image) and one configuration image sector to unlock against external access (e.g., a less recent and / or unauthenticated configuration image), or external system 130 may be configured to provide selection criteria to PLD structure 400 along with an unlock request, all of which may be validated and / or authenticated by PLD structure 400 before being acted upon. PLD structure 400 may then allow the determined / selected configuration sectors to be updated with an updated configuration image, authenticate the updated configuration image, and / or boot the authenticated updated configuration image. PLD structure 400 may receive the lock request and, after storing and authenticating the updated configuration image, proceed to hard lock or soft lock the appropriate configuration image sectors to prevent further external and / or internal read, write, and / or erase access. In various embodiments, other lock states may be requested and / or selected for either of configuration image sectors 452 and 454 , for example, and such selection may come from external or internal to secure PLD 410 .

[0114] In another embodiment, secure PLD 410 may be implemented according to a locking policy scheme designed to prevent in-flight attacks that attempt to extract or manipulate data stored in NVM 450. For example, configuration image sectors 452 and 454 may both be locked against all external access but configured to allow internal access, typically according to the following example. Fig.9D Strategy 3 is shown. This strategy prevents all attempts to tamper with configuration image sectors 452 and 454 through configuration I / O 448. In various embodiments, PLD structure 400 can be configured to establish a secure communication link with controller 620 (e.g., a management control of the user device) when, for example, user device 610 is powered on, and / or otherwise authenticate controller 620, to receive an unlock request from controller 620 to unlock one or more ports of configuration I / O 448 and / or configuration image sectors 452 and 454, and accordingly unlock such identified ports of configuration I / O 448 and / or configuration image. Once powered on, controller 620 can be configured to provide an updated configuration image to configuration image sectors 452 and 454, and then re-lock configuration I / O 448 and / or configuration image sectors 452 and 454 via a lock request provided to PLD structure 400.

[0115] Fig.10 FIG. 1 shows an asset management process 1000 for a secure PLD 410 according to an embodiment of the present disclosure. In some embodiments, Fig.10 The operation can be implemented as Figures 1 to 6 More generally, Fig.10 The operations of process 1000 may be implemented with any combination of software instructions and / or electronic hardware (e.g., inductors, capacitors, amplifiers, actuators, or other analog and / or digital components). It should be understood that any step, sub-step, sub-process, or block of process 1000 may be implemented in different Fig.10 For example, in other embodiments, one or more blocks may be omitted from process 1000, and other blocks may be included. In addition, block inputs, block outputs, various sensor signals, sensor information, calibration parameters, and / or other operating parameters may be stored in one or more memories before moving to subsequent portions of process 1000. Although reference is made to Figures 1 to 6Process 1000 is described with reference to systems, devices, and elements of FIG. 1 , but process 1000 may be performed by other systems, devices, and elements and include different selections of electronic systems, devices, elements, components, and / or arrangements. At the start of process 1000, for example, various system parameters may be populated by previous executions of processes similar to process 1000, or may be initialized to zero and / or to one or more values ​​that correspond to typical, stored, and / or learned values ​​derived from past operations of process 1000, as described herein.

[0116] In optional block 1010, the logic device receives an asset unlock request. For example, the configuration engine 440 of the locked and / or programmed secure PLD 410 may be configured to receive a secure PLD asset unlock request issued by, for example, an external system 130 coupled to the secure PLD 410 via the configuration I / O 448, or issued by the PLD structure 400 running a client configuration or manufacturer configuration programmed into the secure PLD 410 (e.g., using a configuration engine similar to that described with respect to FIG. 1 ). Figure 7 In some embodiments, the PLD structure 400 may be configured to receive a secure PLD asset unlock request.

[0117] In various embodiments, such a secure PLD asset unlock request may be signed, encrypted, and / or include additional information to enable the secure PLD 410 to authenticate the secure PLD asset unlock request. In a particular embodiment, such a secure PLD asset unlock request may include a tracking ID of a particular secure PLD 410 characterized (e.g., extracted from a locked PLD inventory provided by the secure PLD manufacturer 520), and the external system 130 and / or HSM 526 of the secure PLD client 510 may be configured to sign such a secure PLD asset unlock request using its application private key or a different private key, as described herein.

[0118] In some embodiments, the configuration engine 440 and / or the PLD structure 400 may be configured to authenticate the secure PLD asset unlock request received in block 1010. In one embodiment, the secure PLD 410 may be configured to authenticate the secure PLD asset unlock request signed by the application private key or other private key using the application or other public key stored in the NVM 450 during the locking, programming or other provisioning step in the provisioning process, as described herein. In another embodiment, the secure PLD 410 may be configured to authenticate such a secure PLD asset unlock request by comparing the secure PLD asset unlock request tracking ID in the secure PLD asset unlock request with the tracking ID stored in the MFG trim sector 456 and / or other sectors of the NVM 450, or with the device ID 422 of the security engine 420, such that a matching tracking ID in the secure PLD asset unlock request indicates an authenticated secure PLD asset unlock request. In further embodiments, such an authentication process may include decrypting the secure PLD asset unlock request using the public key stored in the NVM 450, as described herein.

[0119] In various embodiments, the configuration engine 440 and / or the PLD structure 400 may be configured to, after receiving and / or authenticating the secure PLD asset unlock request, unlock the secure PLD asset corresponding to the secure PLD asset unlock request. For example, the configuration engine 440 and / or the PLD structure 400 may be configured to unlock the secure PLD asset by adjusting or updating the lock state in the shadow register 860 of the configuration engine 440, which may then be stored in the lock policy sector 460 of the NVM 450, depending on the content of the corresponding lock policy lock state 861.

[0120] In block 1020, the logic device receives an asset access request. For example, the configuration engine 440 and / or the PLD fabric 400 of the locked and / or programmed secure PLD 410 may be configured to receive the secure PLD asset access request issued by, for example, an external system 130 such as a secure PLD client 510 or a secure PLD manufacturer 520 coupled to the secure PLD 410 via the configuration I / O 448, or issued by the PLD fabric 400 running a client or manufacturer configuration programmed into the secure PLD 410. In various embodiments, the configuration engine 440 and / or the PLD fabric 400 may be configured to authenticate such a secure PLD asset access request before proceeding to block 1030.

[0121] In block 1030, the logic device performs an asset update process. For example, the configuration engine 440 and / or the PLD structure 400 of the locked and / or programmed secure PLD 410 may be configured to perform a secure PLD asset update process corresponding to the secure PLD asset access request received in block 1020 and / or the secure PLD asset unlock request received in block 1010. In various embodiments, performing the secure PLD asset update process may be based at least in part on a lock state associated with a secure PLD asset (e.g., one or more ports of the configuration I / O 448 and / or sectors of the NVM 450) corresponding to the secure PLD asset access request received in block 1020 and / or the secure PLD asset unlock request received in block 1010.

[0122] In various embodiments, configuration engine 440 and / or PLD structure 400 may be configured to update one or more configuration images stored, for example, in configuration image sectors 452 and 454 and / or UFM sector 462. In one embodiment, configuration engine 440 and / or PLD structure 400 may be configured to receive a new configuration image via configuration I / O 448 (e.g., via configuration engine 440) and / or programmable I / O 404, decrypt and / or authenticate the new configuration image using a device key stored in device key sector 458, determine that a lock state associated with one of configuration image sectors 452 and 454 includes a write enable and / or erase enable lock state, and store the new configuration image in one of configuration image sectors 452 or 454 (e.g., while setting an authentication bit to indicate that the stored new configuration image is bootable without an additional authentication process), and / or boot the new configuration image.

[0123] When booting a new configuration image, PLD structure 400 may be configured to set or update device key lock state 858 to allow write and / or erase access to device key sector 458 and / or UFM sector 462, download / receive a new key over a secure channel (e.g., established by PLD structure 400 via programmable I / O 404), write the new key to UFM sector 462, erase device key sector 458, copy the new key from UFM sector 462 to device key sector 458, download an additional configuration image for PLD structure 400, decrypt and / or authenticate the additional new configuration image using the new key, and store the additional new configuration image in one of configuration image sectors 452 and 454 (and including setting an authentication bit to indicate that the stored additional new configuration image is bootable without requiring another authentication process) and / or boot the new configuration image. In various embodiments, device key lock state 858 may be updated to include a write disable and / or erase disable lock state with respect to configuration I / O 448 and / or PLD structure 400. Such a process allows embodiments to securely update keys and configuration images as part of a single or unified method.

[0124] In another embodiment, configuration engine 440 and / or PLD structure 400 may be configured to receive, validate and / or authenticate an unlock request for a particular configuration image sector and unlock the particular configuration image sector for programming by external system 130 and / or by PLD structure 400 according to an updated configuration image provided by external system 130. Configuration engine 440 and / or PLD structure 400 may also be configured to receive a lock request (e.g., identifying an updated configuration image stored in configuration image sector 454) from external system 130 via configuration I / O 448 and via configuration engine 440, and configuration engine 440 and / or PLD structure 400 may be configured to receive, validate and / or authenticate the lock request and hard lock configuration image sector 454 or soft lock configuration image sector 454 against further external access as described herein.

[0125] In various embodiments, other securable assets of the secure PLD 410 may be securely updated using similar techniques. For example, the configuration engine 440 and / or PLD structure 400 of the secure PLD 410 may be configured to receive updated MFG trim, tracking ID, device key, IPI, and / or other data (e.g., issued / generated by an external system 130 and / or HSM 526 coupled to the secure PLD 410 or secure PLD manufacturer 520, via configuration I / O 448, or, for example, via programmable I / O 404), which is configured to use similar techniques to Figure 7The process of the provisioning process 700 is used to re-provision the security PLD 410 and / or place the security PLD 410 in a state to be re-provisioned, thereby allowing the security PLD 410 to be placed in service with different or updated operating data.

[0126] In optional block 1040, the logic device receives an asset lock request. For example, the configuration engine 440 and / or the PLD structure 400 of the secure PLD 410 may be configured to receive the secure PLD asset lock request issued by, for example, an external system 130 such as a secure PLD client 510 or a secure PLD manufacturer 520 coupled to the secure PLD 410 via a configuration I / O 448, or issued by the PLD structure 400 running a client configuration programmed into the secure PLD 410. In various embodiments, the configuration engine 440 and / or the PLD structure 400 may be configured to authenticate such a secure PLD asset lock request before locking the asset according to a lock status included in the secure PLD asset lock request. For example, the configuration engine 440 and / or the PLD structure 400 may be configured to lock a secure PLD asset by adjusting or updating a lock state in a shadow register 860 of the configuration engine 440, which may then be stored in a lock policy sector 460 of the NVM 450 based on the contents of a corresponding lock policy lock state 861, as described herein.

[0127] In general, the various blocks of process 1000 may be performed entirely by or within secure PLD client 510, secure PLD manufacturer 520, and / or other elements of secure PLD provisioning system 500 and / or 502. In a particular embodiment, block 1030 may be performed by downstream client 550 to update various elements of NVM 450 in-situ, such as while integrated with user device 610. More generally, block 1030 may be performed by secure PLD client 510, secure PLD manufacturer 520, secure PLD programmer 530, user device assembler 540, and / or downstream client 550 at any time during the operational life of secure PLD 410 and / or user device 610.

[0128] Thus, by employing the systems and methods described herein, embodiments of the present disclosure can provide flexible and secure asset management for secure PLDs. Client-locked and / or otherwise provisioned secure PLDs can be securely erased and / or updated without risk of exposing client data. Furthermore, secure PLDs can be securely re-provisioned, for example, based on updated client data or based on new client applications, without the need to orphan or otherwise destroy the secure PLD.

[0129] Authentication of configuration images (referred to herein for simplicity as "authentication") using an asymmetric key encryption / authentication scheme such as RSA or ECDSA is one way to increase device security, including enabling validated and secure device booting. Secure device booting is an important element in providing a complete stack of security capabilities from a hardware root of trust to secure application layer security. For example, authentication of the configuration image helps ensure that the configuration image has not been modified in transit. Some devices have relatively small firmware images, while others have much larger and more complex images. For example, the PLD structure of secure PLD 410 may have a very large configuration image.

[0130] For many PLDs, authentication can be computationally intensive and result in a large delay in boot time. For example, a 30K FPGA has approximately 6 million configuration bits, and typically (assuming a 150MHz clock) requires approximately 10ms to write the configuration image into the PLD structure without any authentication. In some embodiments, the PLD may not have onboard non-volatile memory, or may be configured to read the configuration image from an external non-volatile memory. It may be relatively easy to corrupt such an external non-volatile memory with an unauthorized configuration bitstream, because authenticating the configuration bitstream may be an important feature for systems where security is an important attribute. However, authentication using ECDSA may add approximately 7 million computation cycles, which would require an additional 50ms to complete in the same situation. Therefore, in such a scenario, providing authentication for such a PLD may increase the boot time by approximately 5 times, which may result in a significant performance loss. Even when the PLD includes onboard non-volatile memory for the configuration image, it should not be assumed to be valid simply because the configuration image is stored on the chip.

[0131] In various embodiments, the secure PLD 410 may include sufficient on-board non-volatile storage (e.g., NVM 450) for multiple on-chip configuration images. In some usage models of this capability, it may be desirable to boot from the last known good image until an updated image has been validated, or to attempt to boot from the latest image but use the older image as a safety backup in the event that the latest image fails to boot. Such functionality allows for seamless in-field system upgrades with much less likelihood of a device being "bricked" by a remote update in the field. The client / user / administrator also needs a reliable method to obtain authentication information regarding which configuration image the secure PLD 410 is using and the security status of the secure PLD 410 and / or the configuration image.

[0132] In some embodiments, secure PLD 410 may be configured to perform a dry run on the received configuration data or image, the dry run including performing a check on at least the integrity of the configuration data (e.g., that the configuration image is complete and has not been inadvertently truncated or corrupted during transmission). The dry run may also include authenticating the source of the configuration data using various techniques described herein, including the provisioning and asset management techniques described herein. The dry run may also include performing other validity checks on the configuration data related to architectural details or other requirements imposed by secure PLD 410 itself. The configuration data may be obtained from an external port, which may receive the configuration data from a flash memory, or, for example, from a network interface. In some implementations, the configuration data may be stored before the dry run occurs, but a flag or state may be set to allow or prevent the configuration data from being used to actually configure the PLD (e.g., PLD structure 400). Depending on the method used for the integrity check, the integrity check may be performed while the data is being received or after the entire image is received. In some embodiments, any one or a combination of protocols described herein may be used to verify both authentication and integrity. The configuration data may be encrypted or decrypted in transit and / or when stored. If encrypted, an integrity check may be performed on the encrypted data.In various embodiments, the security PLD 410 includes a security engine 420 that may be configured to implement cryptographic primitives and may also be capable of generating asymmetric key pairs and / or random numbers for various encryption / authentication and / or communication schemes.

[0133] For example, the secure PLD 410 may be configured to provide a public key generated by it to a source of configuration data (e.g., secure PLD client 510), and the source of configuration data may use the public key to encrypt configuration data and other data to be returned to the secure PLD 410, such as an HMAC of the configuration data. The HMAC may be signed by the source's private key, and the source's public key may also be provided to the secure PLD 410, which may use the public key in authenticating the source of the configuration data packet. In some implementations, it may be necessary to authenticate the source of the configuration data prior to the integrity check. Some implementations require that the authentication and integrity check be performed atomically - meaning that the portion of the secure PLD 410 that participates in the authentication and integrity check does not process any other intervening tasks, such as participating in I / O, in the context of the secure PLD 410. The secure PLD 410 may also employ obfuscation countermeasures against side channel attacks. Other methods of configuration data integrity, source authentication, and privacy of configuration data may be implemented.

[0134] Once the relevant authentication, integrity and / or validity checks have been passed, the secure PLD 410 may set a flag or state that allows the configuration data stored in the secure PLD 410 itself to be used thereafter to configure or program the PLD structure 400. The area or sector within the NVM 450 where the configuration data is stored may be set to not allow write operations. Some implementations may allow reading of the configuration data, while some implementations may not allow all access (e.g., except for the configuration engine 440). If the permissions are set to again allow writing to any memory location storing previously verified configuration data, the pre-authentication flag or state may be cleared, meaning that the configuration data is no longer considered pre-authenticated or available for programming the PLD structure 400. The clearing of the flag may occur atomically with the change of permissions to the memory location. If there is a command or other condition indicating the use of such configuration data, authentication and integrity checks must be performed again. The configuration data / image may be stored encrypted or unencrypted. The secure engine 420 may decrypt the configuration data as it is read from the NVM 450 in order to configure portions of the PLD.

[0135] While some implementations may provide one or more complete images of configuration data, thereby configuring the secure PLD 410 from one image, other implementations may allow for partial configuration or reconfiguration of the secure PLD 410. In this case, the secure PLD 410 may further implement an authorization framework, where specific portions of the configuration data may be authorized to configure specific portions of the secure PLD 410. While some implementations may provide a programmable logic structure configured by the configuration data, the elements and actions disclosed herein may also be applied to firmware or software provided to a secure PLD that includes a processor (e.g., other IC modules 480) that can execute instructions, such as a RISC core. This approach may also be applied to setup data that may be provided as a hard functional block for use in the secure PLD. Therefore, it should be understood that the secure PLD is not simply or solely the programmable logic portion of a device or system, as some implementations may provide for the integration of other functional elements to which these authentication, integrity and / or authorization checks are performed.

[0136] Some implementations may further provide the ability to have multiple different boot images, and in them, if a dry run fails, another image that has been validated may be selected for use. In the case where there are two images, the boot or initialization process may include determining which images are marked as validated, and then determining which of the marked images is the most recent. The series or recent information may be provided by the configuration data source, or may be generated by the secure PLD 410, or both. For example, the source may maintain a monotonically increasing counter that identifies each image version. In many cases, there will be only one configuration data source for the secure PLD 410, and therefore maintaining such information will be straightforward. In various embodiments, a "dry run" or pre-authentication process may be performed on the received bitstream, and the dry run may include verifying the source of the bitstream (e.g., through a certificate or private key mechanism), as well as performing integrity checks on the bitstream (e.g., whether it has been modified - such modification may occur intentionally or accidentally - such as by attempts to compromise the bitstream or through transmission errors). These features may be accomplished by different implementation combinations. For example, in one embodiment, the security PLD 410 may be configured to generate a public key / private key pair, and thus may provide a public key to a source of a bitstream, and the source may use the public key to encrypt data to be sent back to the security PLD 410. Such public keys may be exchanged using a key exchange algorithm, or may be extracted from the security PLD 410 during initial configuration. Such public key / private key pairs may be updated or renewed in a deployed device. Such data may include a keyed Hash Message Authentication Code (HMAC). While an unkeyed hash may provide a sign of the integrity of the bitstream, a keyed HMAC (e.g., keying the hash with the source's private key) provides authentication if the security PLD 410 can authenticate using the source's public key. The hash may also be keyed using a shared key.

[0137] In some implementations, the bitstream may be encrypted, and if so, the HMAC may be over the unencrypted or encrypted bitstream, although it may be preferred that the HMAC be over the encrypted bitstream. The bitstream may be encrypted with a symmetric key that is a shared secret between the source of the bitstream and the secure PLD 410. The symmetric key may be provided to the secure PLD 410 encrypted using a public key provided by the secure PLD 410. In other implementations, the shared secret key may be provided to the secure PLD 410 via a secure communication channel and / or in a secure facility. In this case, the shared secret key may be used for hashing of the encrypted bitstream for decryption and comparison in the secure PLD 410. The bitstream itself may or may not be encrypted. Other implementations may use an encryption method with an integrated authentication mechanism. Depending on the choice of encryption and authentication method, an initialization vector or random number may also be required to initialize or salt the HMAC.

[0138] In one example, a method for securely loading configuration data in a programmable logic device provides for a configuration source to encrypt the configuration data using a symmetric key (bulk encryption). A message authentication protocol (e.g., hashing) is then performed on the encrypted configuration source to generate a plaintext signature. The plaintext signature is encrypted with the public key of the programmable logic device. The symmetric key may be included in the encrypted package. The secure PLD 410 receives the bulk encrypted configuration data and the encrypted package. It decrypts the encrypted package using its private key corresponding to the public key to obtain the plaintext signature and the optional symmetric key. The secure PLD 410 hashes the received bulk encrypted configuration data to generate a second hash and compares it to the plaintext signature. If there is a match, the secure PLD 410 can trust the authenticity of the configuration data and can store it in encrypted form together with the symmetric key, or can decrypt and store the configuration data. At this point, the secure PLD 410 performs other pre-use checks on the configuration data, but does not actually use the configuration data to configure the secure PLD 410. After passing the pre-use check and determining that the generated and received hashes match, the secure PLD 410 sets a state or flag indicating that the configuration data / image has been pre-authenticated. Thus, when the configuration data is used to configure the secure PLD 410, it can be loaded without regenerating the hash and performing a comparison.

[0139] In another example, a digest or hash of the configuration data may be signed by a private key of the source of the configuration data. The configuration data itself may be encrypted or unencrypted (and the digest may be over the encrypted or plaintext data, although preferably taken from the encrypted data). If encrypted, the encryption may be bulk encryption using a symmetric key that is shared with the security PLD 410, which is encrypted using a public key that corresponds to a private key held by the security PLD 410. The private key may be unique to the security PLD 410, or may be shared among multiple security PLDs.

[0140] A method for securely loading configuration data in a secure PLD 410 may include: hashing the configuration data using a hash function (e.g., SHA256) to generate a first digest; encrypting the first digest using a private key corresponding to a first public key / private key pair (e.g., using an elliptic curve algorithm) to generate a signature of the configuration data; encrypting the configuration data, the signature, and a public key corresponding to the first public key / private key pair into an encrypted payload using a symmetric key and a symmetric key encryption algorithm (e.g., AES); transmitting the symmetric key to the secure PLD via a secure channel or at a secure location; 410, the symmetric key is stored in the programmable logic device; the encrypted payload is transmitted to the programmable logic device; in the programmable logic device, the encrypted payload is decrypted using the symmetric key and a symmetric key decryption algorithm corresponding to the symmetric key encryption algorithm to obtain a public key, a signature, and configuration data; using the public key, the signature is decrypted to obtain a first digest; using the same hash function, the configuration data is hashed to generate a second digest; the first digest and the second digest are compared to determine whether the configuration data is valid; and in response to determining that the configuration data is valid, the configuration data is allowed to be used to configure the programmable logic in the secure PLD 410.

[0141] A method for securely loading configuration data in secure PLD 410 may include: in secure PLD 410, receiving configuration data and signature data; hashing the configuration data using a hash function (e.g., SHA256) to generate a first digest; decrypting the signature data using a private key stored in the PLD to obtain candidate digest data; comparing the candidate digest data with the first digest; in response to the candidate digest data matching the first digest, determining that the received configuration data is valid; in response to determining that the received configuration data is valid, setting a flag in a secure location of the PLD, the flag indicating that the received configuration data is valid.

[0142] An article of manufacture (e.g., secure PLD 410) comprising PLD structure 400; NVM 450 of sufficient size to store at least two configuration images for PLD structure 400; and a security engine 420 capable of generating a hash of a configuration image as the configuration image is streamed to an input port, and any one or more of: capable of storing an encrypted configuration image and dynamically decrypting the configuration image as the configuration image is used to configure a programmable logic structure; comparing the generated hash of the received configuration image with a signature of the configuration image, the signature provided via an authenticated communication mechanism; maintaining a current configuration of the programmable logic structure, verifying the hash of the received image by comparing with the signature, and applying the received configuration to the programmable logic structure if the comparison validates the configuration image. Secure PLD 410 may also be configured to revert to a last known good configuration image if a newly applied configuration image fails to operate or fails to operate according to a command from an external authenticated source; including an internal bus to control access to NVM 450. In some embodiments, in the event that two or more images have been validated, a portion of the current configuration determines which configuration image is used. In some lock modes, the PLD structure 400 responds to properly authenticated external lock and unlock requests in one or more lock modes, and can be configured to not respond to any external unlock requests. The non-volatile key memory (e.g., the memory storing the private key used to authenticate chip communications) can be locked independently of the configuration image. For example, a new configuration can be downloaded and validated with the old key; to update the key, the device's new private key is authenticated by the master private key and encrypted by the existing public key of the security PLD 410. It can then be decrypted by the private key of the security PLD 410 and authenticated by the public key of the source.

[0143] A method for securely loading configuration data in a programmable logic device may include: hashing the configuration data using a hash function (e.g., SHA256) to generate a first digest; encrypting the first digest using a private key corresponding to a first public key / private key pair (e.g., using an elliptic curve algorithm) to generate a signature of the configuration data; encrypting the configuration data, the signature, and the public key corresponding to the first public key / private key pair into an encrypted payload using a symmetric key and a symmetric key encryption algorithm (e.g., AES); transmitting the symmetric key to a secure PLD via a secure channel or at a secure location; 410, the symmetric key is stored in the programmable logic device; the encrypted payload is transmitted to the programmable logic device; in the programmable logic device, the encrypted payload is decrypted using the symmetric key and a symmetric key decryption algorithm corresponding to the symmetric key encryption algorithm to obtain a public key, a signature, and configuration data; using the public key, the signature is decrypted to obtain a first digest; using the same hash function, the configuration data is hashed to generate a second digest; the first digest and the second digest are compared to determine whether the configuration data is valid; and in response to determining that the configuration data is valid, the configuration data is allowed to be used to configure the programmable logic in the secure PLD 410.

[0144] A symmetric key may be provided to protect the PLD 410 in a secure environment and stored in a one-time programmable memory in the programmable logic device. The secure PLD 410 may be associated with a second public key / private key pair, and a private key for the second public key / private key pair may be securely provided in the programmable logic device, and the public key for the second public key / private key pair may be used to encrypt a symmetric key to provide to the programmable logic device, and the secure PLD 410 may: use the private key for the second public key / private key pair to decrypt the symmetric key and store the private key in the programmable logic device. The secure PLD 410 may include a module for generating a public key / private key pair, generating a second public key / private key pair, and providing the public key from the secure PLD 410 for encrypting the symmetric key. A programmable logic device may include a memory capable of storing a first complete configuration image and a second complete configuration image for fully programming a programmable structure of the programmable logic device, wherein a portion of the memory is also capable of storing user data, which is also readable by the programmable structure. Secure PLD 410 may be configured to boot from the first configuration image as the active boot image while updating the second configuration image and performing an integrity check on the second configuration image, and secure PLD 410 may be configured to switch the active boot image to the second configuration image in response to the second configuration image being valid.

[0145] The secure boot system may include a generator or source of a bitstream for configuring the PLD structure 400 and the secure PLD 410, wherein the generator or source includes a private key for a first public key / private key pair, and the secure PLD 410 stores the public key for the first public key / private key pair, the generator is operable to generate a hash of the bitstream and encrypt the hash of the bitstream with the private key, wherein the secure PLD 410 is operable to decrypt the hash and generate the hash using the same hashing algorithm as the generator, and compare the decrypted hash with the generated hash before using the received bitstream to configure the secure PLD 410 to validate the bitstream received by the secure PLD 410. The generator and the secure PLD 410 may both store a symmetric key, and before generating the hash, the generator uses the symmetric key to encrypt the bitstream and the secure PLD 410 uses the symmetric key to decrypt the bitstream.

[0146] FIG. 11A to FIG. 11C 1 shows a secure boot process 1100, 1102, and 1104 for secure PLD 410 according to an embodiment of the present disclosure. In particular, Fig.11A The secure boot process 1100 of FIG. 1 shows a relatively slow secure boot process, which includes sending a “wake-up” signal to the PLD structure 400 before initializing the PLD structure 400 (e.g., before entering normal operation in the user phase), the configuration engine 440 of the secure PLD 410 authenticates the configuration image for each boot of the PLD structure 400 (e.g., Figure 4 Configuration image 0 in sector 452 of NVM 450 in . Fig. 11B The secure boot process 1102 of FIG. 1 illustrates a relatively efficient and fast secure boot process in which the configuration engine 440 of the secure PLD 410 performs a pre-authentication process 1120 once to determine a pre-authentication state and / or sets the state to a valid state, and then performs a relatively fast secure boot process 1122 to boot the PLD structure 400 relatively quickly and without performing a full and resource-intensive authentication of the configuration image. Fig. 11C The secure boot process 1104 shows a relatively quick subsequent secure boot process 1132, in which the configuration engine 440 of the secure PLD 410 simply boots the PLD architecture 400 and enters normal operation without performing a full authentication of the configuration image.

[0147] In various embodiments, pre-authentication process 1120 may be a secure process initiated using a single command provided to or generated by configuration engine 440, which may include reading a configuration image (e.g., from NVM 450 and / or through configuration I / O 448 or programmable I / O 404), and providing the configuration image to an authentication engine (e.g., implemented in configuration engine 440, security engine 420, or a combination of these and / or other IC modules 480), which is configured to determine a pre-authentication status associated with the received configuration image (e.g., configuration image 0 of sector 452). Such a status may be implemented at least in part as a flag or status bit (e.g., associated with sector 452, similar to the various techniques described herein for asset management) that is configured to protect the configuration image from being erased, overwritten, and / or unauthorized access. If such a flag or status bit is set (e.g., the status includes a "valid" state), configuration engine 440 may be configured to perform fast secure boot process 1122 and / or fast subsequent secure boot process 1132. If such a flag or status bit is not set (e.g., the status includes an "invalid" state), configuration engine 440 may be configured to stop booting of a configuration image or boot PLD structure 400 according to a different, valid configuration image (e.g., configuration image 1 of sector 454). Pre-authentication process 1120 may be performed on a configuration image that is stored in NVM 450, stored on machine-readable medium 136 and accessed through configuration I / O 448 and / or programmable I / O 404, or streamed through various I / O buses including configuration I / O 448 and / or programmable I / O 404.

[0148] In related embodiments, pre-authentication process 1120 may include determining a design version corresponding to a configuration image, and / or determining a pre-authentication digest or hash of the configuration image (e.g., for relatively quick comparison prior to booting), and in addition, providing the configuration image to an authentication engine and / or storing associated authentication engine results as described herein. In alternative embodiments, an authentication engine implemented by configuration engine 440 and / or security engine 420 may be configured to authenticate the configuration image (e.g., using various encryption / signature schemes), determine the version of the configuration image, generate a digest or hash of the configuration image (e.g., for relatively quick comparison prior to booting), determine that the configuration image includes a complete configuration image for secure PLD 410, and / or validate the configuration image relative to secure PLD 410 (e.g., verify that the configuration refers to a specific selection of components implemented and / or integrated by secure PLD 410). In various embodiments, in order for the pre-authentication status to be a valid state, the authentication engine result must be a passing result (e.g., must pass all checks).

[0149] FIG. 12A to FIG. 12B The secure boot process 1200, 1202 for the secure PLD 410 according to an embodiment of the present disclosure is shown. In particular, the secure boot process 1200 shows a golden image secure boot process (e.g., a secure PLD 410 configured according to a "golden boot mode"), and the secure boot process 1202 shows a ping pong image secure boot process (e.g., a secure PLD 410 configured according to a "ping pong boot mode").

[0150] exist Fig. 12A In the illustrated embodiment, the golden image secure boot process 1200 includes a configuration image update process that shows both an update failure process 1210 and an update success process 1212. In the golden image secure boot process 1200, configuration image B is booted because its pre-authentication status is valid and because it is not a golden configuration image (e.g., typically configuration image B is later in date or includes additional functionality relative to the golden configuration image). In the update failure process 1210, configuration image C is received and written to NVM 450 (e.g., by configuration image B), but the pre-authentication process 1120 fails, and thus configuration engine 440 retrieves the golden configuration image and boots PLD structure 400 accordingly. Subsequently, configuration image D is written over the invalid configuration image C, and the pre-authentication process 1120 succeeds (e.g., it is determined that configuration image D has a valid pre-authentication status). Configuration engine 440 then boots PLD structure 400 according to the valid configuration image D.

[0151] exist Fig. 12BIn the illustrated embodiment, a ping pong image secure boot process 1202 includes a configuration image update process that shows both an update failure process 1220 and an update success process 1222. In the ping pong image secure boot process 1202, configuration image B is booted because its pre-authentication status is valid and because its design version is later than configuration image A. In the update failure process 1220, configuration image C is received and written to NVM 450 (e.g., over configuration image B) and a default design version number is assumed (e.g., to indicate that it is not pre-authenticated and to ensure that it continues to pass pre-authentication), but the pre-authentication process 1120 fails, and therefore configuration engine 440 retrieves valid configuration image A and boots PLD structure 400 accordingly. Subsequently, configuration image D is written over invalid configuration image C (and again given a default design version number), pre-authentication process 1120 succeeds (e.g., configuration image D is determined to have a valid pre-authentication status), and configuration image D is given a non-default design version number (e.g., which is equal to or later than the design version number of configuration image B). Configuration engine 440 then boots PLD structure 400 according to the valid and most recently updated configuration image D.

[0152] Typically, the golden configuration image is used as an inviolable backup of the PLD architecture 400, and updated configuration images can only be stored in other areas of the NVM 450. Either configuration image in the ping-pong boot mode can be updated based on the last boot image, the most recent date, and / or according to various rules depending on the client's expectations or needs. In some embodiments, the secure PLD 410 may initially be in the ping-pong boot mode, and the configuration engine 440 may be configured to select one of the configuration images stored in the NVM 450 and / or received through the configuration I / O 448 and / or the programmable I / O 404 as the golden configuration image and place the secure PLD 410 in the golden boot mode. Similarly, the configuration engine 440 may be configured to change the state of the golden configuration image in the NVM 440 to an updateable configuration image and place the secure PLD 410 in the ping-pong boot mode. In further embodiments, the NVM 450 may be configured to have sufficient capacity to implement a golden boot and / or ping-pong boot mode with more than two configuration images.

[0153] In various embodiments, the design version number of the configuration image may be configured simply to distinguish one configuration image from another (e.g., A vs. B), which may require only 1 or 2 bits of information. In other embodiments, the design version number may be configured to identify, for example, a version date, a serial number, and / or other configuration image identification information, and may be implemented with 3 or more bits as desired. Such a design version may be used in combination with one or more rollback protection rulesets, such as during pre-authentication process 1120, to help protect secure PLD 410 from known vulnerable configuration images, as described herein.

[0154] For example, Fig.13 A rollback protection rule set 1300 for a secure boot process of a secure PLD 410 according to an embodiment of the present disclosure is shown. In various embodiments, the configuration engine 440 may be configured to compare a design version corresponding to a non-pre-certified configuration image with a design version corresponding to a pre-certified valid configuration image stored in NVM 450, or with a set of blacklisted design versions, according to a rollback protection rule set stored in NVM 450 and / or integrated with a pre-certified valid configuration image stored in NVM 450.

[0155] exist Fig.13 , a rollback protection rule set 1300 indicates how various configuration images are validated and invalidated during an attempted update as part of the pre-authentication process 1120 based on their individual design versions, the design version of the configuration image stored in NVM 450, the specific boot mode used for the secure PLD 440, and the various rules shown in the rollback protection rule set 1300. For example, in an embodiment where the secure PLD 440 is in the golden boot mode (e.g., top row), a rollback rule set that only requires the design version of the updated configuration image B to be greater than or equal to the design version of the golden configuration image A (e.g., second column) results in the indicated validated update (e.g., a configuration image with design version 16 or 11). The rule-based rule set may include a user-defined minimum design version (e.g., third column). The middle row shows an example rollback rule set for a secure PLD 440 in a ping-pong boot mode (e.g., with an internal configuration image stored in NVM 450), and the bottom row shows an example rollback rule set for a secure PLD 440 that is configured to boot away from an internal or external configuration image.

[0156] In addition to the Boolean operations identified in the rollback protection rule set 1300, such a rollback protection rule set may include a blacklisted design version (e.g., design version != blacklisted design version 1, or version 1-5, etc.). The configuration engine 440 may be configured to set the pre-certification state to a valid state only if the tested configuration image is validated based on its design version and such a rollback protection rule set. In some embodiments, the design version may be, for example, a monotonically increasing unsigned integer selected by the secure PLD client 510 or the secure PLD manufacturer 520 and / or a date code integrated with the configuration image. The rollback protection rule set may also be integrated with the configuration image to update the applicable rollback protection rule set. For external configuration image updates, the configuration engine 440 may be configured to process the internal configuration image as a golden image and use the rollback protection rule set to update one or more external configuration images, or if no internal configuration image exists, simply use the rollback protection rule set to update one or more external configuration images.

[0157] Fig.14 FIG. 14 shows a secure boot process 1400 for secure PLD 410 according to an embodiment of the present disclosure. In some embodiments, Fig.14 The operation can be implemented as Figures 1 to 13 More generally, software instructions executed by one or more logic devices associated with the corresponding electronic devices, modules, processes and / or structures described in the Fig.14 The operations of the process 1400 may be implemented with any combination of software instructions and / or electronic hardware (e.g., inductors, capacitors, amplifiers, actuators, or other analog and / or digital components). It should be understood that any step, sub-step, sub-process, or block of the process 1400 may be different from Fig.14 For example, in other embodiments, one or more blocks may be omitted from process 1400, and other blocks may be included. In addition, block inputs, block outputs, various sensor signals, sensor information, calibration parameters, and / or other operating parameters may be stored in one or more memories before moving to subsequent portions of process 1400. Although reference is made to Figures 1 to 13 Process 1400 is described with reference to systems, devices, processes, and elements of the present invention, but process 1400 may be performed by other systems, devices, and elements and include different selections of electronic systems, devices, elements, components, and / or arrangements. At the start of process 1400, for example, various system parameters may be populated by previous executions of processes similar to process 1400, or may be initialized to zero and / or to one or more values ​​that correspond to typical, stored, and / or learned values ​​derived from past operations of process 1400, as described herein.

[0158] In block 1410, the logic device retrieves a pre-authentication state associated with a configuration image for the secure PLD. For example, configuration engine 440 of secure PLD 410 may be configured to retrieve a pre-authentication state associated with configuration image 0 in sector 452 or configuration image 1 in sector 454 of NVM 450 (e.g., stored in other securely storable sectors 464 of NVM 450), either of which may be used to program PLD structure 400 of secure PLD 410. In other embodiments, configuration engine 440 may be configured to retrieve a pre-authentication state associated with a configuration image stored on machine-readable medium 136 and provided through configuration I / O 448 and / or programmable I / O 404.

[0159] Prior to such retrieval, configuration engine 440 may be configured to: perform a pre-authentication process 1120 associated with the configuration image for secure PLD 410 to determine a pre-authentication state associated with the configuration image retrieved in block 1410. In various embodiments, such a pre-authentication process may include: determining an authentication engine result based at least in part on the configuration image; determining a design version corresponding to the configuration image and / or a pre-authentication digest or hash signature associated with the configuration image; and storing the authentication engine result, the design version corresponding to the configuration image, and / or the pre-authentication digest or hash signature in NVM 450 as a pre-authentication state. In some embodiments, such a pre-authentication process may include: determining an authentication engine result based at least in part on the configuration image; and selectively storing the authentication engine result as a pre-authentication state in NVM based at least in part on the authentication engine result.

[0160] In various embodiments, the authentication engine may be implemented by, within, and / or include other IC modules 480, configuration engine 440, security engine 420, and / or a combination thereof. The authentication engine may be configured to authenticate the configuration image, e.g., where the configuration image is signed using a private key associated with secure PLD client 510 of secure PLD 410 or secure PLD manufacturer 520 of secure PLD 410, a corresponding public key is stored in NVM 450, and the authentication includes using the public key to verify that the configuration image is signed using a private key associated with secure PLD client 510 or secure PLD manufacturer 520. The authentication engine may be configured to determine that the configuration image includes a complete configuration image for secure PLD 410, e.g., by comparing the size of the configuration image to a corresponding expected size or checksum. The authentication engine can be configured to validate the configuration image for the secure PLD 410, which can include, for example, design version comparisons with rollback protection rule sets and / or other configuration images, functional comparisons, serial number, device ID, and / or other comparisons. In such an embodiment, the authentication engine can be configured to provide a pass result, for example, when all such checks pass, and a fail result when any such check fails. In general, such design version comparisons and / or validations can be performed by the authentication engine, or can be performed as part of the pre-authentication process 1120.

[0161] In one embodiment, secure PLD 410 may be configured to authenticate a configuration image signed by an application private key or other private key using an application or other public key stored in NVM 450 during a lock, program, or other provisioning step in the provisioning process, as described herein. In another embodiment, secure PLD 410 may be configured to authenticate such a configuration image by comparing a secure PLD tracking ID in the configuration image with a tracking ID stored in MFG trim sector 456 and / or other sectors of NVM 450, or with device ID 422 of security engine 420, such that a matching tracking ID in the configuration image indicates an authenticated configuration image. In a further embodiment, such an authentication process may include decrypting the configuration image using a public key stored in NVM 450, as described herein.

[0162] In block 1420, the logic device determines that the pre-authentication state includes a valid state. For example, configuration engine 440 of secure PLD 410 may be configured to: determine an authentication engine result associated with the configuration image including a pass result and / or determine or calculate a pre-boot digest or hash signature associated with the configuration image, and verify that the calculated pre-boot hash signature matches a pre-authentication digest or hash signature (e.g., generated by pre-authentication process 1120) before booting PLD structure 400 using the configuration image, wherein the pre-authentication state includes the pre-authentication hash signature associated with the configuration image.

[0163] In block 1430, the logic device boots the PLD structure of the secure PLD using the configuration image. For example, the configuration engine 440 of the secure PLD 410 may be configured to: retrieve configuration image 0 from the NVM 450; program the PLD structure 400 according to configuration image 0; and initialize or wake up the PLD structure 400 of the secure PLD 410. When booting configuration image 0, PLD structure 400 may be configured to: set or update device key lock state 858 to allow write and / or erase access to device key sector 458 and / or UFM sector 462, download / receive new keys over a secure channel (e.g., established by PLD structure 400 via programmable I / O 404), write new keys to UFM sector 462, erase device key sector 458, copy new keys from UFM sector 462 to device key sector 458, download an updated configuration image for PLD structure 400, decrypt and / or authenticate the updated configuration image using the new keys, and store the updated configuration image in one of configuration image sectors 452 and 454 (and including setting the authentication bit to indicate that the stored updated configuration image is bootable without requiring another authentication process) and / or boot the updated configuration image. In various embodiments, device key lock state 858 may be updated to include a write disable lock state and / or an erase disable lock state with respect to configuration I / O 448 and / or PLD structure 400. Such a process allows embodiments to securely update keys and configuration images as part of a single or unified method.

[0164] In another embodiment, configuration engine 440 and / or PLD structure 400 may be configured to receive, validate and / or authenticate an unlock request for a particular configuration image sector and unlock the particular configuration image sector for programming by external system 130 and / or by PLD structure 400 according to an updated configuration image provided by external system 130. Configuration engine 440 and / or PLD structure 400 may also be configured to receive a lock request (e.g., identifying an updated configuration image stored in configuration image sector 454) from external system 130 and by configuration engine 440 via configuration I / O 448, and configuration engine 440 and / or PLD structure 400 may be configured to receive, validate and / or authenticate the lock request and hard lock or soft lock configuration image sector 454 against further external access as described herein.

[0165] Fig.15 FIG. 1 shows a secure boot process 1500 for secure PLD 410 according to an embodiment of the present disclosure. In some embodiments, Fig.15 The operation can be implemented as Figures 1 to 14 More generally, software instructions executed by one or more logic devices associated with the corresponding electronic devices, modules, processes and / or structures described in the Fig.15 The operations of the process 1500 may be implemented with any combination of software instructions and / or electronic hardware (e.g., inductors, capacitors, amplifiers, actuators, or other analog and / or digital components). It should be understood that any step, sub-step, sub-process, or block of the process 1500 may be different from Fig.15 1500. For example, in other embodiments, one or more blocks may be omitted from process 1500, and other blocks may be included. In addition, block inputs, block outputs, various sensor signals, sensor information, calibration parameters, and / or other operating parameters may be stored in one or more memories before moving to subsequent portions of process 1500. Although reference is made to Figures 1 to 14 Process 1500 is described with reference to systems, devices, processes, and elements of the present invention, but process 1500 may be performed by other systems, devices, and elements and include different selections of electronic systems, devices, elements, components, and / or arrangements. At the start of process 1500, for example, various system parameters may be populated by previous executions of processes similar to process 1500, or may be initialized to zero and / or to one or more values ​​that correspond to typical, stored, and / or learned values ​​derived from past operations of process 1500, as described herein.

[0166] In block 1510, the logic device receives an updated configuration image for the secure PLD. For example, the configuration engine 440 of the secure PLD 410 may be configured to receive the updated configuration image through the configuration I / O 448 or the programmable I / O 404 of the secure PLD 410 to attempt to update the configuration image 0 or 1 in the NVM 450. In some embodiments, the configuration engine 440 may be configured to receive the updated configuration image issued by an external system 130, such as a secure PLD client 510 or a secure PLD manufacturer 520 coupled to the secure PLD 410 through the configuration I / O 448, or issued by the PLD fabric 400 running a client or manufacturer configuration programmed into the secure PLD 410.

[0167] In block 1520, the logic device performs a pre-authentication process associated with the updated configuration image. For example, the configuration engine 440 of the secure PLD 410 may be configured to perform the pre-authentication process 1120 associated with the updated configuration image to determine a pre-authentication state associated with the updated configuration image. In some embodiments, performing the pre-authentication process 1120 may include determining an authentication engine result based at least in part on the updated configuration image, and selectively storing the authentication engine result in the NVM 450 as a pre-authentication state based at least in part on the authentication engine result. For example, if the authentication engine result includes a pass result, the configuration engine 440 may be configured to store the pass result as a valid state associated with the pre-authentication process 1120 and / or the received updated configuration image. If the authentication engine result includes a fail result, the configuration engine 440 may be configured to omit the pre-authentication state or store the fail result as an invalid state associated with the pre-authentication process 1120 and / or the received updated configuration image.

[0168] In further embodiments, performing pre-authentication process 1120 may include determining a design version corresponding to the received updated configuration image based at least in part on rollback protection rule set 1300 stored in NVM 450, a secure boot mode associated with secure PLD 410, and / or a first design version and / or a second design version corresponding to a respective first configuration image and / or second configuration image (e.g., configuration images 0 and 1) stored in NVM 450, and selectively validating the design version corresponding to the updated configuration image.

[0169] In block 1530, the logic device selectively stores the updated configuration image in the secure PLD. For example, the configuration engine 440 of the secure PLD 410 may be configured to selectively store the updated configuration image in the NVM 450 in place of the first configuration image or the second configuration image (e.g., configuration image 0 or 1) based at least in part on the pre-authentication state determined in block 1520 and the secure boot mode associated with the secure PLD 410. For example, if the pre-authentication state associated with the updated configuration image includes a valid state, the configuration engine 440 may be configured to store the updated configuration image in the NVM 450 (e.g., on configuration 0 or 1) based at least in part on the design version identified in the pre-authentication state and the golden boot mode or the ping-pong boot mode associated with the secure PLD 410. In embodiments where the secure boot mode associated with secure PLD 410 includes a golden boot mode, storing the updated configuration image in NVM 450 may include identifying the first configuration image (e.g., configuration 0) as a golden configuration image, and storing the updated configuration image in NVM 450 in place of the second configuration image (e.g., in place of configuration 1). In embodiments where the secure boot mode associated with secure PLD 410 includes a ping-pong boot mode, storing the updated configuration image in NVM 450 may include identifying the second configuration image (e.g., configuration 1) as an updateable configuration image, and storing the updated configuration image in NVM 450 in place of the second configuration image (e.g., in place of configuration 1).

[0170] If the pre-authentication state associated with the updated configuration image includes an invalid state, configuration engine 440 may be configured to: erase the updated configuration image or set the relevant sectors in NVM 450 to enable writing and / or erasure. In various embodiments, once configuration engine 440 overwrites configuration 0 or 1 with the updated configuration image received in block 1510, configuration engine 440 may proceed similar to Fig.14 The fast secure boot process of process 1400 includes: retrieving a pre-authentication state associated with an updated configuration image from NVM 450, verifying that the retrieved pre-authentication state associated with the configuration image includes a valid state, and booting the PLD structure 400 of the secure PLD 410 using the updated configuration image. Such booting of the PLD structure 400 may include retrieving the updated configuration image from NVM 450, programming the PLD structure 400 according to the updated configuration image, and initializing the PLD structure 400 of the secure PLD 410.

[0171] By employing the systems and methods disclosed herein, embodiments of the present disclosure can provide flexible and secure booting for secure PLDs. Client-locked and / or otherwise provisioned secure PLDs can be securely booted and / or updated without risking exposure of client data and without incurring substantial downtime or repeated degraded performance associated with repeated authentication of the same configuration image at boot time.

[0172] Where applicable, hardware, software, or a combination of hardware and software may be used to implement the various embodiments provided by the present disclosure. In addition, where applicable, the various hardware components and / or software components set forth herein may be combined into composite components comprising software, hardware, and / or both, without departing from the spirit of the present disclosure. Where applicable, the various hardware components and / or software components set forth herein may be separated into subcomponents comprising software, hardware, or both, without departing from the spirit of the present disclosure. In addition, where applicable, it is conceivable that software components may be implemented as hardware components, and vice versa.

[0173] Software according to the present disclosure, such as non-transitory instructions, program code and / or data, can be stored on one or more non-transitory machine-readable media. It is also contemplated that the software identified herein can be implemented using one or more general-purpose or special-purpose computers and / or computer systems, which are networked and / or otherwise. Where applicable, the order of the various steps described herein can be changed, combined into composite steps, and / or separated into sub-steps to provide the features described herein.

[0174] The above embodiments illustrate but do not limit the present invention. It should also be understood that many modifications and variations are possible based on the principles of the present invention. Therefore, the scope of the present invention is limited only by the following claims.

Claims

1. A secure boot system for a secure programmable logic device (PLD), comprising: A security PLD, wherein the security PLD comprises: a plurality of programmable logic blocks (PLBs) arranged in a PLD structure of the security PLD; and a configuration engine configured to program the PLD structure according to a first configuration image or a second configuration image stored in a non-volatile memory (NVM) of the security PLD and / or coupled to the configuration engine through a configuration input / output (I / O) of the security PLD, wherein the security PLD is configured to perform a computer-implemented method, the computer-implemented method comprising: retrieving from the NVM a first pre-authentication state associated with the first configuration image or the second configuration image; determining that the retrieved first pre-authentication state associated with the first configuration image or the second configuration image is valid; and booting the PLD structure of the secure PLD using the first configuration image or the second configuration image; receiving an update configuration image via the configuration I / O or programmable I / O of the secure PLD; performing an update pre-authentication process associated with the update configuration image to determine an update pre-authentication status associated with the update configuration image; storing the updated configuration image in the NVM in place of the first configuration image or the second configuration image based at least in part on a secure boot mode associated with the secure PLD if the updated pre-authentication state associated with the updated configuration image is valid; and booting the PLD structure of the secure PLD using the stored updated configuration image without performing an additional authentication process for the stored updated configuration image, wherein the secure boot mode associated with the secure PLD comprises a golden boot mode, and wherein storing the updated configuration image in the NVM comprises: identifying the first configuration image as a golden configuration image; and storing the updated configuration image in the NVM to replace the second configuration image; or wherein the secure boot mode associated with the secure PLD comprises a ping-pong boot mode, and wherein storing the updated configuration image in the NVM comprises: identifying the second configuration image as an updateable configuration image; and The updated configuration image is stored in the NVM in place of the second configuration image.

2. The secure PLD secure boot system of claim 1 , wherein the computer-implemented method further comprises: Before retrieving the first pre-authentication state associated with the first configuration image or the second configuration image, performing a first pre-authentication process associated with the first configuration image or the second configuration image, the pre-authentication process comprising: determining, based at least in part on the first configuration image or the second configuration image, that an authentication engine result comprises a passing result; determining a design version corresponding to the first configuration image or the second configuration image and / or a pre-authenticated hash signature associated with the first configuration image or the second configuration image; and The authentication engine result, the design version corresponding to the first configuration image or the second configuration image, and / or the pre-authentication hash signature are stored in the NVM as the first pre-authentication state.

3. The secure PLD secure boot system of claim 2, wherein determining that the authentication engine result includes a pass result comprises: authenticating the first configuration image or the second configuration image, wherein the first configuration image or the second configuration image is signed using a private key associated with a secure PLD client for the secure PLD, or a secure PLD manufacturer for the secure PLD, a corresponding public key is stored in the NVM, and the authenticating includes using the public key to verify that: the first configuration image or the second configuration image is signed using the private key associated with the secure PLD client, or the secure PLD manufacturer; determining that the first configuration image or the second configuration image comprises a complete configuration image for the secure PLD; and / or The first configuration image or the second configuration image is validated with respect to the secure PLD.

4. The secure PLD secure boot system of claim 1 , wherein determining that the retrieved first pre-authentication state associated with the first configuration image or the second configuration image is valid comprises: determining that an authentication engine result associated with the first configuration image or the second configuration image includes a passing result; and / or determining a pre-boot hash signature associated with the first configuration image or the second configuration image and, prior to booting the PLD structure using the first configuration image or the second configuration image, verifying that the pre-boot hash signature matches a pre-authentication hash signature, wherein the first pre-authentication state includes the pre-authentication hash signature associated with the first configuration image or the second configuration image.

5. The secure PLD secure boot system of claim 1 , wherein performing the update pre-authentication process associated with the update configuration image comprises: determining a design version corresponding to the updated configuration image; as well as The design version corresponding to the updated configuration image is validated based at least in part on a rollback protection rule set stored in the NVM, the secure boot mode associated with the secure PLD, and / or a first design version and / or a second design version corresponding to the respective first configuration image and / or the second configuration image.

6. A secure programmable logic device (PLD) secure boot system, comprising: A security PLD, wherein the security PLD comprises: a plurality of programmable logic blocks (PLBs) arranged in a PLD structure of the security PLD; and a configuration engine configured to program the PLD structure according to a first configuration image and / or a second configuration image stored in a non-volatile memory (NVM) of the security PLD and / or coupled to the configuration engine through a configuration input / output (I / O) of the security PLD, wherein the security PLD is configured to perform a computer-implemented method, the computer-implemented method comprising: receiving an update configuration image via the configuration I / O or programmable I / O of the secure PLD; performing an update pre-authentication process associated with the update configuration image to determine an update pre-authentication status associated with the update configuration image; and selectively storing the updated configuration image in the NVM in place of the first configuration image or the second configuration image based at least in part on a secure boot mode associated with the secure PLD if the updated pre-authentication state associated with the updated configuration image is valid; and booting the PLD structure of the secure PLD using the stored updated configuration image without performing an additional authentication process for the stored updated configuration image, wherein the secure boot mode associated with the secure PLD comprises a golden boot mode, and wherein storing the updated configuration image in the NVM comprises: identifying the first configuration image as a golden configuration image; and storing the updated configuration image in the NVM to replace the second configuration image; or wherein the secure boot mode associated with the secure PLD comprises a ping-pong boot mode, and wherein storing the updated configuration image in the NVM comprises: identifying the second configuration image as an updateable configuration image; and The updated configuration image is stored in the NVM in place of the second configuration image.

7. The secure PLD secure boot system of claim 6, wherein performing the update pre-authentication process associated with the update configuration image comprises: determining an authentication engine result based at least in part on the updated configuration image; as well as Based at least in part on the authentication engine result, selectively storing the authentication engine result in the NVM as the updated pre-authentication state.

8. The secure PLD secure boot system of claim 6, wherein performing the update pre-authentication process associated with the update configuration image comprises: determining a design version corresponding to the updated configuration image; as well as The design version corresponding to the updated configuration image is selectively validated based at least in part on a rollback protection rule set stored in the NVM, a secure boot mode associated with the secure PLD, and / or a first design version and / or a second design version corresponding to the respective first configuration image and / or the second configuration image.

9. The secure PLD secure boot system of claim 6, wherein the computer-implemented method further comprises: retrieving from the NVM the update pre-authentication state associated with the update configuration image; as well as Verifying that the retrieved update pre-authentication status associated with the update configuration image includes a valid status.

10. The secure PLD secure boot system of claim 9, wherein the PLD structure for booting the secure PLD comprises: retrieving the stored updated configuration image from the NVM; programming the PLD structure according to the stored updated configuration image; as well as The PLD structure of the secure PLD is initialized.

11. A method for secure booting of a secure programmable logic device (PLD), the method comprising: retrieving a first pre-authentication state associated with a first configuration image or a second configuration image of a PLD structure of the security PLD from a non-volatile memory (NVM) of the security PLD, wherein the first configuration image or the second configuration image is stored in the NVM and / or coupled to the security PLD via a configuration input / output (I / O) of the security PLD; determining that the retrieved first pre-authentication state associated with the first configuration image or the second configuration image is valid; booting the PLD structure of the secure PLD using the first configuration image or the second configuration image; receiving an update configuration image via the configuration I / O or programmable I / O of the secure PLD; performing an update pre-authentication process associated with the update configuration image to determine an update pre-authentication status associated with the update configuration image; storing the updated configuration image in the NVM in place of the first configuration image or the second configuration image based at least in part on a secure boot mode associated with the secure PLD if the updated pre-authentication state associated with the updated configuration image is valid; as well as booting the PLD structure of the secure PLD using the stored updated configuration image without performing an additional authentication process for the stored updated configuration image, wherein the secure boot mode associated with the secure PLD comprises a golden boot mode, and wherein storing the updated configuration image in the NVM comprises: identifying the first configuration image as a golden configuration image; and storing the updated configuration image in the NVM to replace the second configuration image; or wherein the secure boot mode associated with the secure PLD comprises a ping-pong boot mode, and wherein storing the updated configuration image in the NVM comprises: identifying the second configuration image as an updateable configuration image; and The updated configuration image is stored in the NVM in place of the second configuration image.

12. The method according to claim 11, further comprising: Before retrieving the first pre-authentication state associated with the first configuration image or the second configuration image, performing a first pre-authentication process associated with the first configuration image or the second configuration image, the first pre-authentication process comprising: determining, based at least in part on the first configuration image or the second configuration image, that an authentication engine result comprises a passing result; determining a design version corresponding to the first configuration image or the second configuration image and / or a pre-authenticated hash signature associated with the first configuration image or the second configuration image; and The authentication engine result, the design version corresponding to the first configuration image or the second configuration image, and / or the pre-authentication hash signature are stored in the NVM as the first pre-authentication state.

13. The method of claim 12, wherein determining that the authentication engine result comprises a passing result comprises: authenticating the first configuration image or the second configuration image, wherein the first configuration image or the second configuration image is signed using a private key associated with a secure PLD client of the secure PLD or a secure PLD manufacturer of the secure PLD, a corresponding public key is stored in the NVM, and the authenticating includes using the public key to verify that: the first configuration image or the second configuration image is signed using the private key associated with the secure PLD client or the secure PLD manufacturer; determining that the first configuration image or the second configuration image comprises a complete configuration image for the secure PLD; and / or The first configuration image or the second configuration image is validated with respect to the secure PLD.

14. The method of claim 11, wherein determining that the retrieved first pre-authentication state associated with the first configuration image or the second configuration image is valid comprises: determining that an authentication engine result associated with the first configuration image or the second configuration image includes a passing result; and / or determining a pre-boot hash signature associated with the first configuration image or the second configuration image and, prior to booting the PLD structure using the first configuration image or the second configuration image, verifying that the pre-boot hash signature matches a pre-authentication hash signature, wherein the first pre-authentication state includes the pre-authentication hash signature associated with the first configuration image or the second configuration image.

15. The method of claim 11, wherein performing the update pre-authentication process associated with the update configuration image comprises: determining a design version corresponding to the updated configuration image; as well as The design version corresponding to the updated configuration image is validated based at least in part on a rollback protection rule set stored in the NVM, the secure boot mode associated with the secure PLD, and / or a first design version and / or a second design version corresponding to the respective first configuration image and / or the second configuration image.

Images