Tamper detection systems and methods for programmable logic devices

Abstract

Systems and methods for asset tamper detection management for secure programmable logic devices (PLDs) are disclosed. An example system includes a secure PLD including a programmable logic block (PLB) disposed in a PLD structure of the secure PLD, and a configuration engine 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 detect an asset tampering attempt to a target asset of the secure PLD and lock a protectable asset associated with the detected asset tampering attempt, where the protectable asset includes the target asset of the secure PLD, configure an I / O and / or communication bus.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to and the benefit of U.S. patent application No. 18 / 584,894, filed on February 22, 2024, entitled “Tamper detection systems and methods for programmable logic devices,” the entire contents of which are incorporated herein by reference.

[0003] This application is a continuation-in-part of U.S. patent application No. 17 / 093,572, filed on November 9, 2020, entitled “KEY PROVISIONING SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0004] U.S. patent application Ser. No. 17 / 093,572 is a continuation of International Patent Application No. PCT / US2019 / 031875, filed on May 10, 2019, entitled “KEYPROVISIONING SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0005] International Patent Application No. PCT / US2019 / 031875, filed on May 10, 2019, 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 METHODS FOR PROGRAMMABLE LOGIC DEVICES,” which is hereby incorporated by reference in its entirety.

[0006] International Patent Application No. PCT / US2019 / 031875, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0007] International Patent Application No. PCT / US2019 / 031875, filed on May 10, 2019, 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 PROGRAMMABLELOGIC DEVICES,” which is hereby incorporated by reference in its entirety.

[0008] International Patent Application No. PCT / US2019 / 031875, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0009] International Patent Application No. PCT / US2019 / 031875, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0010] This application is a continuation-in-part of U.S. patent application No. 17 / 093,576, filed on November 9, 2020, entitled “ASSET MANAGEMENT SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0011] U.S. patent application No. 17 / 093,576 is a continuation-of-International patent application No. PCT / US2019 / 031883, filed on May 10, 2019, entitled “ASSETMANAGEMENT SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0012] International Patent Application No. PCT / US2019 / 031883, filed on May 10, 2019, 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 METHODS FOR PROGRAMMABLE LOGIC DEVICES,” which is hereby incorporated by reference in its entirety.

[0013] International Patent Application No. PCT / US2019 / 031883, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0014] International Patent Application No. PCT / US2019 / 031883, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0015] International Patent Application No. PCT / US2019 / 031883, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0016] International Patent Application No. PCT / US2019 / 031883, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0017] This application is a continuation-in-part of U.S. patent application No. 17 / 093,578, filed on November 9, 2020, entitled “FAILURE CHARACTERIZATION SYSTEMS AND METHODS FOR ERASING AND DEBUGGING PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0018] U.S. patent application Ser. No. 17 / 093,578 is a continuation-of-patent application of International Patent Application No. PCT / US2019 / 031881, filed on May 10, 2019, entitled “FAILURECHARACTERIZATION SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0019] International Patent Application No. PCT / US2019 / 031881, filed on May 10, 2019, 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 METHODS FOR PROGRAMMABLE LOGIC DEVICES,” which is hereby incorporated by reference in its entirety.

[0020] International Patent Application No. PCT / US2019 / 031881, filed on May 10, 2019, 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 PROGRAMMABLELOGIC DEVICES,” which is hereby incorporated by reference in its entirety.

[0021] International Patent Application No. PCT / US2019 / 031881, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0022] International Patent Application No. PCT / US2019 / 031881, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0023] International Patent Application No. PCT / US2019 / 031881, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0024] This application is a continuation-in-part of U.S. patent application No. 17 / 093,582, filed on November 9, 2020, entitled “Secure Boot System and Method for Programmable Logic Devices,” the entire contents of which are incorporated herein by reference.

[0025] U.S. patent application Ser. No. 17 / 093,582 is a continuation-of-patent application of International Patent Application No. PCT / US2019 / 031886, filed on May 10, 2019, entitled “SECURE BOOT SYSTEMS AND METHODS FOR PROGRAMMABLE LOGIC DEVICES,” the entire contents of which are incorporated herein by reference.

[0026] International Patent Application No. PCT / US2019 / 031886, filed on May 10, 2019, 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 METHODS FOR PROGRAMMABLE LOGIC DEVICES,” which is hereby incorporated by reference in its entirety.

[0027] International patent application No. PCT / US2019 / 031886, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0028] International Patent Application No. PCT / US2019 / 031886, filed on May 10, 2019, 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 PROGRAMMABLELOGIC DEVICES,” which is hereby incorporated by reference in its entirety.

[0029] International Patent Application No. PCT / US2019 / 031886, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety.

[0030] International Patent Application No. PCT / US2019 / 031886, filed on May 10, 2019, 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,” which is hereby incorporated by reference in its entirety. Technical Field

[0031] The present invention relates generally to programmable logic devices and, more particularly, to secure management of memory, communication interfaces, and / or other assets of such devices. Background Art

[0032] Programmable logic devices (PLDs) (e.g., field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), field programmable systems on chip (FPSCs), or other types of programmable devices) can be configured with various user designs to achieve desired functionality. Typically, the user design is synthesized and mapped into 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.

[0033] PLD customers often invest significant resources in developing configurations for their selected PLD types and / or capabilities, and protecting configuration data and preventing corruption of desired operations or capabilities associated with the selected PLD and / or developed configuration is crucial for many PLD customers. 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. Summary of the Invention

[0034] In one or more embodiments, a secure programmable logic device (PLD) asset tamper detection and management system is disclosed, comprising: a secure PLD, wherein the secure PLD includes a plurality of programmable logic blocks (PLBs) arranged in a PLD structure of the secure PLD; and a configuration engine 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 via configuration inputs / outputs (I / Os) of the secure PLD, wherein the secure PLD is configured to perform a computer-implemented method including: detecting an asset tamper attempt to a target asset of the secure PLD; and locking protectable assets associated with the detected asset tamper attempt, wherein the protectable assets include the target asset, the configuration I / Os, and / or a communication bus of the secure PLD.

[0035] In one or more embodiments, a method for asset tamper detection management for a secure programmable logic device (PLD) is disclosed, the method comprising: detecting an asset tamper attempt on a target asset of the secure PLD, wherein the secure PLD includes a PLD structure and a configuration engine, the configuration engine 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 via a configuration input / output (I / O) of the secure PLD; and locking protectable assets associated with the detected asset tamper attempt, wherein the protectable assets include the target asset, the configuration I / O, and / or a communication bus of the secure PLD. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0037] Figure 2 A block diagram illustrating logic blocks of a PLD according to an embodiment of the present disclosure is illustrated.

[0038] Figure 3 A design process of a PLD according to an embodiment of the present disclosure is illustrated.

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

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

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

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

[0043] Figure 7 A provisioning process for locking a secure PLD according to an embodiment of the present disclosure is illustrated.

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

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

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

[0047] Figure 10 An asset management process for a secure PLD according to an embodiment of the present disclosure is illustrated.

[0048] Figure 11 A block diagram illustrating a tamper detection strategy plan for a secure PLD according to an embodiment of the present disclosure is illustrated.

[0049] Figure 12 A tamper detection management process for a secure PLD according to an embodiment of the present disclosure is illustrated.

[0050] The embodiments of the present disclosure and their advantages can be best understood by referring to the following detailed description. It should be understood that the same reference numerals are used to identify the same elements illustrated in one or more figures, which are shown to illustrate the embodiments of the present disclosure, not to limit the embodiments of the present disclosure. DETAILED DESCRIPTION

[0051] As described herein, the present disclosure provides systems and methods for managing lockout policies regarding internal and external access to assets (e.g., buses, ports, and / or memory sectors) of a locked secure programmable logic device (PLD) for use in trusted computing applications and architectures. For example, embodiments provide systems and methods for assigning a lockout status to individual assets and / or groups of assets by setting corresponding lockout status bits stored in a secure memory of a secure PLD. The secure memory of the secure PLD itself can be locked to a customer-defined configuration and / or operating environment to help reduce or eliminate the risk of loss or extraction of customer or manufacturer data, or reprogramming of such data, without requiring protection or restriction of distribution of the locked secure PLD (e.g., a locked secure PLD could be programmed with non-customer data and potentially used to subvert various secure operations for a trusted platform, including, for example, securely configuring and / or booting such a platform / user device), as described herein.

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

[0053] Typically, a PLD (e.g., FPGA) structure includes one or more routing structures and an array of similarly arranged logic cells arranged within programmable function blocks (e.g., PFBs and / or PLBs). The purpose of the routing structure is to programmably connect the ports of the logic cells / PLBs to each other in the necessary combinations to achieve the desired functionality. A secure PLD may include various additional "hard" engines or modules configured to provide operations that can be linked to the PLD structure to provide configurable trusted computing functionality and / or a range of architectural security functions. Routing flexibility and configurable function embedding can be exploited 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, 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 the various types of components provided by the PLD and their associated signals. In embodiments that generate a netlist of the converted user design, the 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.

[0054] Referring now to the accompanying drawings, Figure 1 A block diagram of a PLD 100 according to an embodiment of the present disclosure is shown. 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 type of programmable device) typically 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 PLD 100 may be referred to as the PLD fabric.

[0055] 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 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 can be configured with less programming than logic blocks 104).

[0056] PLD 100 may also include memory blocks 106 (e.g., EEPROM blocks, block SRAM, and / or flash memory), 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 other signals). 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.

[0057] 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 employing 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 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.

[0058] 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).

[0059] 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 100) to perform their conventional functions (e.g., storing configuration data for configuring PLD 100 or providing an interconnect structure within PLD 100). It should also be understood that 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.

[0060] 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, 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.

[0061] In the illustrated embodiment, system 130 is implemented as a computer system. In this regard, system 130 includes, for example, one or more processors 132 that 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 system 130). For example, in some embodiments, 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 for programming PLD 100.

[0062] 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 for PLD 100.

[0063] Figure 2 1 shows a block diagram of logic blocks 104 of PLD 100 according to an embodiment of the present disclosure. As discussed, PLD 100 includes multiple 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, which 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, mode logic circuitry 204, registers 206 (e.g., flip-flops or latches), and various programmable multiplexers (e.g., programmable multiplexers 212 and 214) for selecting desired signal paths between logic cells 200 and / or between logic cells 200. In this example, LUT 202 accepts four inputs 220A-220D, making it a four-input LUT (which may be abbreviated as "4-LUT" or "LUT4") that can be programmed by configuration data of PLD 100 to implement any appropriate logic operation with four or fewer inputs. Mode logic 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, LUTs of different sizes may be provided for different logic blocks 104 and / or different logic cells 200.

[0064] In some embodiments, output signal 222 from LUT 202 and / or mode logic 204 may pass through register 206 to provide output signal 233 of logic cell 200. In various embodiments, as shown, output signal 223 from LUT 202 and / or mode logic 204 may pass directly to output 223. Depending on the configuration of multiplexers 210-214 and / or mode logic 204, output signal 222 may be temporarily stored (e.g., latched) in latch 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 to another logic cell 200 (e.g., in another logic block or the same logic block) in a hierarchical or cascaded 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.

[0065] Mode logic circuitry 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, operating on 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 circuitry 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 can be passed directly to mode logic circuit 204 or can be passed to mode logic circuit 204 by configuring one or more programmable multiplexers, as described herein. In some embodiments, mode logic circuit 204 can be linked across multiple logic blocks 104.

[0066] Figure 2 The logic unit 200 shown in FIG is merely an example, and the logic unit 200 according to different embodiments may include different combinations and arrangements of PLD components. Figure 2 Logic block 104 is shown with eight logic cells 200, but logic block 104 according to other embodiments may include fewer logic cells 200 or more logic cells 200. Each logic cell 200 of 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 the user design.

[0067] 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, an optimization process may route various signal connections associated with the arithmetic / logic operations described herein so 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.

[0068] Figure 3 FIG. 3 shows a design process 300 for a PLD according to an embodiment of the present disclosure. For example, Figure 3The process may be performed by 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, for example, in memory 134, machine-readable media 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.

[0069] In operation 310, system 130 receives a user design that specifies the desired functionality of PLD 100. For example, a user may interact with 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). System 130 may perform one or more rule checks to confirm that the user design describes a valid configuration of PLD 100. For example, system 130 may reject invalid configurations and / or request that the user provide appropriate new design information.

[0070] In operation 320, system 130 synthesizes the design to create a netlist (e.g., a synthesized RTL description) that identifies the 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 purpose database (NGD) file in an electronic design interchange format (EDIF).

[0071] 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.

[0072] 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 interconnects 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 generate an optimized netlist).

[0073] 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, when the PLD is configured to implement the user design, would occupy multiple configurable PLD components (e.g., logic cells 200, logic blocks 104, and / or routing resources 180). 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 operating 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 propagation delays associated with the operations, and / or reprogramming corresponding LUTs and / or mode logic to account for the swapped operating modes.

[0074] In another example, the optimization process may include detecting extended logic functional operations and / or corresponding routing resources in the user design, implementing the extended logic operations as multi-mode or switchable logic cells having 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 operations and / or routing resources and / or reduce propagation delays associated with the extended logic operations, and / or programming corresponding LUTs and / or mode logic to implement the extended logic functional operations using at least the first group of logic cells and the second group of logic cells.

[0075] In another example, the optimization process may include detecting multiple modes or configurable logic cells that implement logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in a user design, swapping the operating modes of the logic cells that implement 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 operating modes and / or programming programmable registers to store or latch signals on the signal paths.

[0076] In operation 330, system 130 performs a mapping process that identifies components of PLD 100 that can be used to implement the user design. In this regard, system 130 may map the optimized netlist (e.g., stored as a result of the optimization process in operation 320) to the various types of components provided by PLD 100 (e.g., logic blocks 104, logic cells 200, embedded hardware, and / or other portions of PLD 100) and their associated signals (e.g., in a logical manner, but not yet with placement or routing specified). In some embodiments, the mapping may be performed on one or more previously stored NGD files, with the results of the mapping 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 generate a netlist that maps to the PLD components.

[0077] In operation 340, 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), thereby determining the layout of PLD 100. In some embodiments, placement may be performed on one or more previously stored NCD files, with the placement results stored as another physical design file.

[0078] In operation 350, 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.

[0079] 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 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).

[0080] 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, when the PLD is configured to implement the user design, would occupy multiple configurable PLD components (e.g., logic cells 200, logic blocks 104, and / or routing resources 180). 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 operating 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 propagation delays associated with the operations, and / or reprogramming corresponding LUTs and / or mode logic to account for the swapped operating modes.

[0081] In another example, the optimization process may include detecting extended logic functional operations and / or corresponding routing resources in the user design, implementing the extended logic operations as multi-mode or switchable logic cells having 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 operations and / or routing resources and / or reduce propagation delays associated with the extended logic operations, and / or programming corresponding LUTs and / or mode logic to implement the extended logic functional operations using at least the first group of logic cells and the second group of logic cells.

[0082] In another example, the optimization process may include detecting multiple modes or configurable logic cells that implement logic function operations, ripple arithmetic operations, extended logic function operations, and / or corresponding routing resources in a user design, swapping the operating modes of the logic cells that implement 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 operating modes and / or programming programmable registers to store or latch signals on the signal paths.

[0083] 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.

[0084] 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, 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, 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 encrypted, signed, or unprotected / unauthenticated form, and PLD 100 may be configured to treat secure configurations differently from unprotected configurations, as described herein.

[0085] Figure 4 FIG. 4 shows 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 comprised 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. Specifically, secure PLD 410 may include: PLD fabric 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 fabric 400 may be implemented with any of the various elements described with respect to PLD 100, and may be implemented using a configuration engine similar to that described with respect to PLD 100. Figure 3 The PLD structure 400 may be configured using the design process of the process 300 described above to generate and program the PLD structure 400 according to the desired configuration. More specifically, the secure PLD 410 may be configured to use a secure PLD 410 prior to programming the PLD structure 400 according to the received configuration. Figure 4 The various hard IP elements identified in the embodiment are used to receive, decrypt, authenticate and / or verify the received configuration.

[0086] Security engine 420 may be implemented as a hard IP resource configured to provide various security functions for use by PLD fabric 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 services), a public / private key pair generator (P / PKG) 430, an elliptic curve digital signature algorithm (ECDSA) authentication service 432 (e.g., ECDSA256 services), and / or other security services 434. As also shown in FIG. Figure 4 As shown, security engine 420 can be communicatively linked to PLD fabric 400 via tethered bus 406 and to configuration engine 440 via secure bus 446. Typically, tethered bus 406 can be configured to allow PLD fabric 400 to access a limited set of security functions hosted by security engine 420 and / or to access such security functions in a limited manner, such as not allowing configuration of any or all security functions hosted by security engine 420, not allowing access to device ID 422, and / or not allowing access to the private key of a public / private key pair generated by P / PKG 430. Conversely, secure bus 446 can be configured to allow configuration engine 440 to access and / or modify all security functions, data, and / or configurations of security engine 420. Typically, either or both tethered bus 406 and secure bus 446 can be configured to provide encrypted and / or otherwise secure communications between security engine 420 and other elements of secure PLD 410.

[0087] Configuration engine 440 may be implemented as a hard IP resource configured to manage configuration of and / or communication between various elements of secure PLD 410. For example, configuration engine 440 may be configured to receive an encrypted / secure configuration of PLD fabric 400 from external system 130 / machine-readable medium 136 via configuration I / O 448, authenticate and / or decrypt such configuration using security functionality 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 fabric 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.

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

[0089] NVM 450 may be implemented as a hard IP resource configured to provide secure non-volatile storage of data used to facilitate secure operation of secure PLD 410. For example, NVM 450 may include a lock policy sector 460 corresponding to a memory location in NVM 450, which indicates the 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, for example, to allow such contents to be dynamically modified by configuration engine 440 and / or PLD fabric 400 based on the settings / 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 that resource relative to PLD fabric 400, configuration I / O 448 / external access bus 443, and / or other elements of secure PLD 410.

[0090] 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 fabric 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 fabric 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 fabric 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.

[0091] like Figure 4In the illustrated embodiment, NVM 450 may include multiple, 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 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, including, for example, its own lock state. For example, first configuration image sector 452 and second configuration image sector 454 can each store a configuration of PLD structure 400 and can 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. Trim sector 456 can be used to store manufacturer trim and / or other data specific to a particular secure PLD 410, such as, for example, a modifiable customer-specific order part number and a generated customer ID number derived from device ID 422, as described herein. Device key sector 458 can be used to store encryption / decryption keys, public / private keys, and / or other security keys specific to a particular secure PLD 410. Lock policy sector 460 can be configured to store the lock status of resources of NVM 450, configuration engine 440, configuration I / O 448, and / or other components of secure PLD 410. UFM sector 462 may be used to store user data 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.

[0092] Programmable I / O 404 may be implemented at least in part as a configurable resource configured to provide or support a communication link between PLD fabric 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 fabric 400 to programmable I / O 404). In some embodiments, bus 402 and / or programmable I / O 404 may be integrated with PLD fabric 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 may be integrated with and / or within each other. Other IC modules 480 may be implemented as hard and / or configurable IP resources configured to facilitate the operation of the secure PLD 410.

[0093] Figure 5A FIGURE 5 shows 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, secure PLD provisioning system 500 includes secure PLD client 510 and secure PLD manufacturer 520 configured to communicate with each other via communication link 512 and communication network 514. Generally, communication link 512 may be implemented by one or more wired and / or wireless communication links configured to support data communication to and from communication network 514, and communication network 514 may be implemented by one or more local area networks and / or wide area networks configured to generally support data communication (e.g., an internet service provider, a cellular network, and / or the internet). Each of the remaining elements of secure PLD provisioning system 500 represents an entity in the manufacturing and delivery chain of, for example, secure PLD 410, and may generally be implemented by network communication devices, each of which is similar in scope to the secure PLD 410. Figure 1 5. The secure PLD provisioning system 500 is configured to communicate across a communication link 512 and a 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.

[0094] 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's and / or manufacturer's software and / or hardware should generally be protected or otherwise secured from unwanted access or manipulation by downstream clients 550 and / or the optional secure PLD programmer 530 and user device assembler 540. For example, in a typical 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 fabricating individual ICs and programming them with a security mechanism (e.g., locking them) to inhibit further programming with configurations not provided by the secure PLD client 510 and / or secure PLD manufacturer 520. The secure PLD customer 510 can provide the device-specific encryption configuration to the optional secure PLD programmer 530, and the secure PLD manufacturer 520 can provide locked secure PLDs 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.

[0095] 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 customer 550, all without the secure PLD programmer 530 and the downstream customer 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 customer 510 may then audit the programmed and locked secure PLD 410 in the corresponding user device at the downstream customer 550 without revealing the unencrypted contents of the device-specific cryptographic configuration or unlocking the secure PLD 410. Although 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 customer 510, secure PLD manufacturer 520, and / or downstream customer 550.

[0096] Figure 5BFIG2 shows 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 generally 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 elements of the secure PLD provisioning system 500 shown.

[0097] 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 destined for redirection to a different secure PLD client or request) from a secure PLD inventory 524 based on requests issued by a secure PLD client 510. Once locked by the secure PLD locking system 522, the locked secure PLDs can generally be programmed only with a configuration provided by the secure PLD client 510, such as by the 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 a non-secure communication link 512, and control the external system 130 via a secure communication link 527 to lock the secure PLD 410 provided via a 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 an 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 generally implemented 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, the external system 130 and the HSM 526 and / or their functionality may be integrated into a single external system 130 .

[0098] In general operation, a 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 / private key pair (e.g., generated within the secure PLD client 510, such as by its own HSM). The HSM 526 may generate a client-specific programming public / private key pair (e.g., for encrypting, decrypting, and / or authenticating the configuration for the 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 / 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 the manufacturing lot, 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.

[0099] The configuration engine 440 may then store the tracking ID in the MFG trim 456 of the NVM 450 and / or within 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 a device-unique seed may be stored in the MFG trim 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 within 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 a 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 for 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.

[0100] In some embodiments, the HSM 526 can be configured to generate a customer programming key token corresponding to a particular secure PLD customer 510 and / or a particular request for a locked secure PLD 410 received from a secure PLD customer 510. Such a customer programming key token can be used to reference (e.g., within a customer database stored in the HSM 526) all information stored about the secure PLD customer 510 and / or a request for a locked secure PLD 410 received from a secure PLD customer 510. Such stored information can 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 524 includes one or more pre-locked secure PLDs 410 for redirection (e.g., locked to a different secure PLD customer or a different secure PLD request), the HSM 526 can be configured to use the previous customer programming key token to retrieve information used to lock the locked secure PLD, provide new information to the secure PLD 410 signed using the 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), where the redirect command is executed by the PLD fabric 400 and / or the 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., device public / private key pair, programming private key, programming secret, factory public key, and / or IPI) stored in the NVM 450 with the corresponding new or updated information.

[0101] 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 can be configured to provide a secure boot mechanism for the user device 610 (e.g., a motherboard, a smartphone, and / or other user / embedded device). For example, upon powering up the user device 610, the secure PLD 410 can 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 and a controller boot loader 662 (e.g., which can 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 it from the secure PLD 410. 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 the 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.

[0102] The security PLD 410 can 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, encrypt a 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 can 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. The security PLD 410 can 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. Furthermore, the security PLD 410 and the controller 620 can be configured to register a secure communication path with each other.

[0103] In another embodiment, the security PLD 410 can be configured to use the controller 620 to verify the configuration of the PLD fabric 400 used to program the security PLD 410. For example, the security PLD 410 can 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 can 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 can 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.

[0104] 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. Upon receipt, 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 the version, release date, and / or other characteristics of the one or more configuration images stored in the NVM 450 with a database of versions, release dates, and / or other characteristics of the one or more configuration images stored in the NVM 450 residing in the user device 610 (e.g., in the NVM 630 or VM 622) and / or accessed or retrieved from the network (e.g., the communications network 514, accessed 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 .

[0105] Figure 7 FIG. 4 illustrates 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 for execution. More generally, Figure 7The operations of the process 700 may be implemented using 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 While process 700 is described with reference to systems, devices, and elements of FIG, 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 process 700, various system parameters may be populated by, for example, previous executions of processes similar to 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 operation of process 700, as described herein.

[0106] 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 customer 510. For example, such a request may be sent via communication link 512 and / or via communication network 514 and may include a customer public key of a corresponding customer public / private key pair, as well as the number of the device being requested and any specific model or other identifying information associated with the particular desired secure PLD 410.

[0107] In block 720, the logic device generates a locked PLD. For example, the secure PLD manufacturer 520 can be configured to generate a locked secure PLD 410. In some embodiments, the secure PLD manufacturer 520 can use an IC manufacturing system to manufacture the secure PLD 410, which can include, for example, programming or storing or otherwise embedding the device ID 422 in the security engine 420 and / or MFG trim 456 of the NVM 450. The secure PLD manufacturer 520 can 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 can be configured to assign a customer ID to the secure PLD customer 510 and / or the request received in block 710. This customer ID can then be combined with the device ID 422 and / or a device order part number (e.g., generated at the time of manufacturing) to provide a customer-specific order part number that can be used to reference or identify the secure PLD 410, for example, in an unencrypted database stored in the HSM 526.

[0108] The HSM 526 may also be configured to generate a customer programming key token corresponding to the customer public key in the secure PLD customer 510 and / or the request received in block 710 by generating a corresponding random and unique customer programming key token and / or customer-specific order part number and referencing all stored information associated with generating a locked secure PLD that references such 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 customer 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 customer 510, and / or the request received in block 710, which may also be stored in the HSM 526.

[0109] For example, the HSM 526 can be configured to provide the factory public key, the programming private key, and the programming secret to the external system 130 for programming / locking the secure PLD 410, and in return receive the device-specific tracking ID and the device public key. The HSM 526 can 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 can 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 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 / 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).

[0110] In another embodiment, the HSM 526 can be configured to use the customer programming key token to retrieve the programming private key, programming secret, and device public key from a securely stored database and provide them to the external system 130. The external system 130 can 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 unsecured 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 can be configured to receive a locked PLD list 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 list corresponding to the request received in block 710, sign the locked PLD list with the programming private key, and provide the signed locked PLD list to the secure PLD customer 510.

[0111] In other embodiments, it may be useful to redirect an already programmed and locked secure PLD to a different customer 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 can be used). For example, HSM 526 can be configured to use the customer 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., for execution by the secure PLD 410), where the redirect command may be executed by the PLD fabric 400 and / or the 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.

[0112] 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 customer 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.

[0113] In block 740, the logic device provides a certifiable list identifying the locked PLD. For example, the secure PLD manufacturer 520 can be configured to provide a certifiable list of locked PLDs identifying the locked secure PLD 410 generated in block 720. In one embodiment, the HSM 526 can 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 can use such information to audit the selection of deployed and / or locked secure PLDs 410.

[0114] 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 use a method similar to the reference 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 lockout policy sector 460, the UFM sector 462, and / or other defined secure storage sectors 464. Such feature bitstreams / configurations 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.

[0115] In various embodiments, the external system 130 and / or the HSM 526 of the secure PLD client 510 can 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 can 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 can 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 signature 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 customer 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.

[0116] 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.

[0117] In block 770, the logic device programs the locked PLD according to the protected configuration. For example, the external device 130 of the secure PLD programmer 530 can 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 can be configured to provide the protected configuration / packet generated in block 750 to the secure PLD 410, and the secure PLD 410 can be configured to boot according to the IPI provided to the secure PLD 410 in block 720. The secure PLD 410 can then verify the protected configuration and program elements of the secure PLD 410, including portions of the PLD structure 400 and NVM 450, via one or more buses of the secure PLD 410. More specifically, security PLD 410 may be configured to decrypt the encryption key in the program key digest using the program 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 program secret in the program key digest matches the program 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.

[0118] Once the application public key and application encryption key from the key digest are stored in NVM 450, 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 only be programmed into secure PLD 410 if the bitstream is successfully decrypted and authenticated using the application encryption key and application public key. If the application configuration is successfully authenticated, secure PLD 410 can be configured to program / store the application configuration into one of configuration image sectors 452 or 454, set the pre-authentication bit for the appropriate image, erase the IPI from PLD structure 400, and / or program PLD structure 400 according to the stored application configuration. The feature configuration can be programmed into one or more portions of NVM 450. Other security checks to be performed before programming secure PLD 410 may include verifying the locked PLD manifest, checking for a tracking ID match within the locked PLD manifest, and / or other security checks, as described herein.

[0119] 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 .

[0120] In block 790, the logic device audits the locked and programmed PLDs based on the authenticatable list. For example, the secure PLD client 510 can 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 can 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, compare the tracking ID and device public key with the tracking ID and device public key in the locked PLD list, and challenge the secure PLD 410 using the device public key, for example, 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, this audit can occur before erasing the IPI configuration in block 770. A successful audit indicates that the security PLD 410 is functionally locked.

[0121] Thus, by employing the systems and methods described herein, embodiments of the present disclosure enable flexible and secure key provisioning and configuration of secure PLDs across customer orders of secure PLDs. One customer's protected configuration cannot be used to program another customer'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. Customers can use key manifests to prevent device and / or application spoofing or over-engineering. In various embodiments, programming keys and manifests are managed by one or more HSMs 526 of the secure PLD manufacturer 520 and / or the secure PLD customer 510.

[0122] To help reduce or eliminate the risk of a customer 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 the risk of such data being reprogrammed, the secure PLD 410 can implement one or more lock policy management methodologies based on a lock policy scheme and / or other secure asset arrangements. For example, the lock policy scheme and / or other secure asset arrangements can be used by the PLD fabric 400, the configuration engine 440, and / or other elements of the secure PLD 410 to manage read, write, and / or erase access to assets of the secure PLD 410 and enforce a lock state. In the most general sense, the secure PLD 410 can be configured to assign lock states to various assets of the 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 lock and / or unlock operations of the secure PLD 410, as described herein. For example, access to such assets can 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 can be controlled granularly, 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 communication access) across configuration I / O 448. The lock status associated with an asset or group of assets can be implemented by a lock status bit that is configured to manage, store, or indicate read, write, and / or erase access, for example, according to a particular lock policy scheme or arrangement that can be modified to provide a particular desired granularity for secure asset management of secure PLD 410.

[0123] Figure 8A FIG. 8 is a block diagram illustrating 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 configured similarly to the one described with respect to FIG. Figure 4 4. In particular, lock policy scheme 802 may be implemented by lock policy sector 460 and corresponding shadow registers 860 of configuration engine 440 to allow elements of security PLD 410 (e.g., external system 130 on configuration I / O 448, configuration engine 440, PLD fabric 400, and / or other elements of security PLD 410) to manipulate the lock states of various elements of security PLD 410.

[0124] For example, in Figure 8AIn the illustrated embodiment, 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 840 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 841 in user data lock state group 894, and MFG trim lock state 856. Each lock state of the shadow register 860 can be assigned its own individual local (LOCAL) read, write / program and / or erase access state, and each lock state group can be assigned its own group (GROUP) read, write / program and / or erase access state, which operates to reduce access to all assets with a lock state within the group, such that a group lock state can only override a more permissive local lock state within the group. More specifically, the configuration security lock state 840 can represent the group lock state of the boot lock state group 892, and the user security lock state 841 can represent the group lock state of the user data lock state group 894.

[0125] Each lock state may be implemented by one or more registers within shadow registers 860 of configuration engine 440, e.g., these registers being configured to shadow the corresponding lock state 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 460, retrieve the various lock states from lock policy 460, and shadow the lock states within shadow registers 860 according to lock policy schedule 802, to allow the various lock states to be dynamically accessed and / or modified by configuration engine 440 and / or PLD fabric 400, depending on the settings / lock states in lock policy sector 460. Specifically, configuration I / O lock state 848 may be configured to store or represent or indicate a read and / or write access state (or multiple access states) corresponding to one or more ports of configuration I / O 448 (e.g., JTAG, SSPI, I2C, and / or other ports or protocols supported by configuration I / O 448), which may be used to lock or unlock the respective ports to receive and / or provide data across configuration I / O 448 and / or external access bus 443. Lock policy lock state 861 may be configured to store or represent or indicate a read, write, and / or erase access state corresponding to lock policy sector 460 (e.g., which may be used to lock or unlock access to all lock states stored in lock policy sector 460, such as supergroup lock states). For example, the UFM 462 may include multiple separate and / or differentiated sectors or sub-sectors, so that the UFM lock state 862 can 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 can be configured to provide a group lock state for the user data lock state group 894, as described herein.

[0126] 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 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 thereof. For example, a particular lock state may allow writing but not reading public or private keys or encryption keys, or erasing but not reading or updating configuration image sectors and / or erasing but not reading configuration image sectors to help ensure the security and integrity of customer 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.

[0127] Figure 8BFIG. 8 is a block diagram illustrating a lockout strategy plan 804 for a secure PLD according to an embodiment of the present disclosure. The lockout strategy plan 804 includes a block diagram similar to Figure 8A 802, except that the various lock states are arranged according to different boot lock state groups 896, the different boot lock state groups 896 only include the configuration image lock states 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 sector 864 are ungrouped and 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.

[0128] 9A to 9D 802. Access tables associated with corresponding lock policy plans for secure PLD 410 according to an embodiment of the present disclosure are shown. 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, Figure 9A Access table 902 shows how lock policy plan 802 provides granular management of external and internal bus access for reading, writing / programming, and erasing 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 Figure 9AIn the embodiment shown, such access also allows external access to configuration image sectors 452 and 454 (e.g., the soft-locked portion of the external bus and internal bus access are the same). In some embodiments, PLD structure 400 and / or configuration engine 440 of security PLD 410 and / or external system 130 can be configured to update configuration I / O lock state 848 (e.g., a local lock state) to lock configuration I / O 448 (e.g., prevent read and / or write access via configuration I / O 448) before adjusting the lock state bits in configuration image lock state 852 and 854 and / or configuration security lock state 840 to allow internal access (e.g., read, write / program, erase) to configuration image sectors 452 and 454 without risking interference or loss of external system 130. As can be seen in access table 902, once hard locks are enabled for configuration image lock states 852 and 854 and configuration security lock state 840, no further modification of the hard lock bits is permitted via configuration I / O 448 / external bus 443 or by PLD fabric 400 via secure bus 408.

[0129] Figure 9B The access table 904 shows how different lock policy plans / arrangements can provide differentiated granularity management of external and internal bus access 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 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, as shown, but in Figure 9B In the embodiment shown, such access applies only to external accesses to configuration image sectors 452 and 454, and PLD structure 400 has free access unless hard lockout is enabled for configuration image lock states 852 and 854 and configuration security lockout state 840, after which no further modification of the hard lock bits is permitted via configuration I / O 448 / external bus 443 or by PLD structure 400.

[0130] Figure 9CAccess table 906 shows 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 to read, write / program, and erase 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). Figure 9C As shown, this approach includes aspects of accessing both tables 902 and 904, and the fabric WB bit itself may be enabled or disabled by PLD fabric 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, this fabric WB bit may be configured to allow embodiments to prevent accidental internal modification of configuration images or other data in NVM 450.

[0131] As can be seen in access table 906, when external soft lockout is enabled (e.g., fabric WB bit is disabled), external access via configuration I / O 448 / external bus 443 can be allowed or disallowed by setting one or more group and / or local lock status bits in configuration image lock status 852 and 854 and / or configuration security lock status 840, and PLD fabric 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 via configuration I / O 448 / external bus 443, as well as internal access by PLD fabric 400, can be allowed or disallowed by setting one or more group and / or local lock status bits in configuration image lock status 852 and 854 and / or configuration security lock status 840, as shown. As with access tables 902 and 904, once hard lock is enabled for configuration image lock states 852 and 854 and configuration security lock state 840, no further modifications to the hard lock bits are permitted through configuration I / O 448 / external bus 443 or by PLD fabric 400, and the state of the fabric WB bit no longer results in a change in the lock state of configuration image sectors 452 and 454.

[0132] Figure 9D The 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 granularity management of external and internal bus access to read, write / program, and erase configuration image sectors 452 and 454 and / or other sectors in NVM 450 (e.g., device key sector 458). Figure 9D As shown, this method includes aspects of accessing tables 902, 904, and 906. For example, in Figure 9DIn the embodiment shown, Figure 8B , the corresponding lock policy plan / arrangement places the device key lock state 858 outside of the boot lock state group 892 / 896 and the user data lock state group 894. If device key changes are not expected, policy 9 can be applied to lock the device key sector 458 from any internal or external access, and such application can, for example, permanently disable external access, or permanently disable both external and internal access (e.g., by preventing internal access to the lock policy sector 460). If certain limited future device key changes are expected, policy 6 can be applied to hard lock external access to the device key sector 458, but allow the PLD fabric 400 adjustable access to the device key sector 458, as shown.

[0133] For example, in one embodiment, PLD fabric 400 can be configured to receive a new configuration image via programmable I / O 404, decrypt and / or authenticate the new configuration image using the 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 fabric 400 can 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 the new key via a secure channel (e.g., established by PLD fabric 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 fabric 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 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. This process allows embodiments to securely update keys and configuration images as part of a single or unified method.

[0134] 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 with the corresponding hard lock enabled in the configuration image lock state 852), and an updateable configuration image of the PLD structure 400 may be stored in the configuration image sector 452 (e.g., with the corresponding hard lock disabled in the configuration image lock state 854). For example, the configuration image may be updated based on the configuration image lock state 854. Figure 9DPolicy 9 in the hard lock configuration image lock state 852, and can be based on Figure 9D 4. In such an embodiment, secure PLD 410 may be configured to soft-lock configuration image locked state 854 in policy 3. In such an embodiment, secure PLD 410 may be configured to update the configuration image stored in configuration image sector 454. For example, external system 130 may be configured to provide an unlock request (e.g., identifying the configuration image stored in configuration image sector 454) to PLD fabric 400 via configuration I / O 448 and configuration engine 440, and PLD fabric 400 may be configured to receive, verify, and / or authenticate the unlock request and unlock configuration image sector 454 for programming by external system 130 and / or by PLD fabric 400 according to the updated configuration image provided by 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, verify, and / or authenticate the lock request and hard or soft lock configuration image sector 454 to prevent further external access, as described herein.

[0135] In another embodiment, both configuration image sector 452 and configuration image sector 454 can be updated with a new configuration image provided by external system 130. For example, PLD structure 400 can 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 for external access (e.g., a less recent and / or unauthenticated configuration image), or external system 130 can be configured to provide selection criteria along with an unlock request to PLD structure 400, all of which can be verified and / or authenticated by PLD structure 400 before being implemented. PLD structure 400 can then allow the determined / selected configuration sector to be updated with the updated configuration image, authenticate the updated configuration image, and / or boot the authenticated updated configuration image. PLD structure 400 can receive the lock request and, after storing and authenticating the updated configuration image, proceed to hard or soft lock the appropriate configuration image sector 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 originate externally or internally with respect to secure PLD 410 .

[0136] In another embodiment, secure PLD 410 may be implemented according to a locking policy scheme designed to prevent in-flight attacks seeking 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 a locking policy scheme such as Figure 9D Policy 3 is shown. This policy prevents all tampering attempts on configuration image sectors 452 and 454 via configuration I / O 448. In various embodiments, PLD fabric 400 can be configured to establish a secure communication link with controller 620 (e.g., a management control of the user device) upon power-up of user device 610, and / or 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 relock configuration I / O 448 and / or configuration image sectors 452 and 454 via a lock request provided to PLD fabric 400.

[0137] Figure 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, Figure 10 The operation can be realized by Figures 1 to 9D More generally, Figure 10 The operations of the process 1000 may be implemented using 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 1000 may be different from Figure 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 9DWhile process 1000 is described with reference to systems, devices, and elements of FIG, 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, various system parameters may be populated by, for example, previous executions of processes similar to process 1000, or may be initialized to zero and / or one or more values ​​corresponding to typical, stored, and / or learned values ​​derived from past operation of process 1000, as described herein.

[0138] 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, a secure PLD customer 510 or a secure PLD manufacturer 520 coupled to the secure PLD 410 via configuration I / O 448, or issued by the PLD fabric 400 running a customer or manufacturer configuration programmed into the secure PLD 410 (e.g., using a configuration engine similar to that described with respect to FIG. 10). Figure 7 In some embodiments, the PLD architecture 400 may be configured to receive a secure PLD asset unlock request.

[0139] 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 specific secure PLD 410 characterized (e.g., extracted from a list of locked PLDs 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.

[0140] In some embodiments, the configuration engine 440 and / or the PLD fabric 400 can be configured to authenticate the secure PLD asset unlock request received in block 1010. In one embodiment, the secure PLD 410 can be configured to authenticate the secure PLD asset unlock request, signed by an application private key or other private key, using an application public key stored in NVM 450 during a lock, programming, or other provisioning step in the provisioning process, as described herein. In another embodiment, the secure PLD 410 can be configured to authenticate such a secure PLD asset unlock request by comparing a secure PLD asset unlock request tracking ID in the secure PLD asset unlock request with a tracking ID stored in the MFG trim sector 456 and / or other sectors of 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 can include decrypting the secure PLD asset unlock request using a public key stored in NVM 450, as described herein.

[0141] In various embodiments, the configuration engine 440 and / or the PLD fabric 400 may be configured to unlock the secure PLD asset corresponding to the secure PLD asset unlock request after receiving and / or authenticating the secure PLD asset unlock request. For example, the configuration engine 440 and / or the PLD fabric 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. The lock state may then be stored in the lock policy 460 of the NVM 450, depending on the contents of the corresponding lock policy lock state 861.

[0142] 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, a secure PLD customer 510 or a secure PLD manufacturer 520 coupled to the secure PLD 410 via configuration I / O 448, or issued by the PLD fabric 400 running a customer 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.

[0143] 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 status associated with a secure PLD asset (e.g., one or more ports of the configuration I / O 448 and / or a sector 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.

[0144] In various embodiments, configuration engine 440 and / or PLD fabric 400 can be configured to update one or more configuration images, such as those stored in configuration image sectors 452 and 454 and / or UFM sector 462. In one embodiment, configuration engine 440 and / or PLD fabric 400 can 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 requiring an additional authentication process) and / or boot the new configuration image.

[0145] When booting a new configuration image, PLD fabric 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 fabric 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 fabric 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 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. 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. This process allows embodiments to securely update keys and configuration images as part of a single or unified method.

[0146] In another embodiment, configuration engine 440 and / or PLD fabric 400 may be configured to receive, verify, 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 fabric 400 according to an updated configuration image provided by external system 130. Configuration engine 440 and / or PLD fabric 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 fabric 400 may be configured to receive, verify, and / or authenticate the lock request and hard or soft lock configuration image sector 454 to prevent further external access, as described herein.

[0147] In various embodiments, other secure assets of the secure PLD 410 may be securely updated using similar techniques. For example, the configuration engine 440 and / or PLD fabric 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, such as a secure PLD client 510 or secure PLD manufacturer 520 coupled to the secure PLD 410 via configuration I / O 448 or via programmable I / O 404), which may be configured to use a configuration engine similar to Figure 7The provisioning process 700 is performed 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 into service with different or updated operating data.

[0148] In optional block 1040, the logic device receives an asset lock request. For example, the configuration engine 440 of the secure PLD 410 and / or the PLD fabric 400 may be configured to receive the secure PLD asset lock request, which may be issued by, for example, a secure PLD client 510 or a secure PLD manufacturer 520 coupled to the secure PLD 410 via configuration I / O 448, or by the PLD fabric 400 running a customer 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 the secure PLD asset lock request before locking the asset according to the lock status included in the secure PLD asset lock request. For example, configuration engine 440 and / or PLD fabric 400 may be configured to lock secure PLD assets by adjusting or updating a lock state in shadow register 860 of configuration engine 440, which may then be stored in lock policy 460 of NVM 450 according to the contents of corresponding lock policy lock state 861, as described herein.

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

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

[0151] To further reduce or eliminate the risk of losing or extracting customer or manufacturer PLD fabric configurations / images, keys, and / or other secure data, or reprogramming such data from a locked or unlocked secure PLD 410, the secure PLD 410 may implement one or more tamper detection methods that utilize a lockout policy scheme and / or other secure asset arrangements, for example (e.g., used by the PLD fabric 400, configuration engine 440, security engine 420, and / or other elements of the secure PLD 410) to detect various different types of attempts to tamper with the operation of the secure PLD 410 and / or access the assets of the secure PLD 410 without proper authentication, such as by attempting brute-force dictionary and / or fuzzy / pseudo-random input type attacks on the various externally accessible ports of the secure PLD 410, including the configuration I / O 448, the programmable I / O 404, and / or other communication or configuration ports of the secure PLD 410. The secure PLD 410 can then dynamically and automatically lock the appropriate assets associated with the detected asset tampering attempt by managing and enforcing read, write, and / or erase access and lock status with respect to the assets of the secure PLD 410, as described herein at least with respect to Figures 8A-10 described.

[0152] By implementing such tamper detection management (e.g., detection and prevention), embodiments can prevent adversaries from attempting to search for or exploit weaknesses in the hardware or configuration of the secure PLD 410 and / or user devices that include one or more secure PLDs 410. For example, various elements of the secure PLD 410 may include critical information / data, such as dual-boot images, ECDSA keys, AES keys, and user data, and each asset or portion of an asset may be subject to various types of configurable protection (e.g., read, write, erase). If an attempt is made to access an asset using an illegal operation, the secure PLD 410 may flag the attempt by generating a tamper detection assertion, setting an appropriate tamper detection state, and implementing appropriate tamper prevention (e.g., by locking the asset and / or access to the asset via one or more buses or ports of the secure PLD 410).

[0153] In the most general sense, secure PLD 410 can be configured to detect asset tampering attempts, such as attempts to access a protectable asset or group of assets (e.g., ports of configuration I / O 448 and / or sectors of NVM 450) without proper authentication, lock the asset associated with the detected asset tampering attempt (e.g., the asset itself or the port used to access the asset, via a similar authentication mechanism as referenced above), and Figures 8A-10 Lockout strategy plan and / or procedures described), reporting asset tampering attempts (e.g., using a similar Figures 5A-7The communication technology described, via Figure 5A communication network 514 to report to the secure PLD customer 510, manufacturer 520, programmer 530, device assembler 540 and / or downstream customer 550), and / or unlock the locked asset once the tamper attempt is completed or otherwise thwarted.

[0154] The secure PLD 410 can be configured to manage tamper detection associated with the secure PLD 410 by assigning a tamper detection state to various assets of the secure PLD 410 (such as ports of the configuration I / O 448 and / or sectors of the NVM 450 and / or groups of such assets), and then locking and / or unlocking such assets based at least in part on the tamper detection state, as described herein. The tamper detection state can be finely controlled to indicate the type and source of tampering, such as unauthorized read, write, and / or erase access attempts associated with the NVM 450, or across the configuration I / O 448, programmable I / O 404, and / or Figure 11 The tamper detection status associated with an asset or group of assets can be implemented by a tamper detection status bit, which can be configured to manage, store, or represent the tamper detection status according to a specific tamper detection policy plan or arrangement, for example, which can be modified to provide a desired specific tamper detection management granularity for the secure PLD 410, similar to the reference Figures 8A-10 Describes the lock status.

[0155] The security PLD 410 may be configured to lock and unlock assets associated with detected asset tampering attempts by assigning lock states to various assets of the security PLD 410, as described herein with reference to Figures 8A-10 As described above. For example, access to such assets can be locked to prevent external access (e.g., via configuration I / O 448), internal access (e.g., via PLD fabric 400, configuration engine 440, and / or security engine 420), both external and internal access, and / or locked to prevent any further access regardless of the type of access. Such access can be granularly controlled, such as providing read, write, and / or erase access for each asset associated with NVM 450, or read and / or write access across configuration I / O 448 (e.g., data communication access). The lock status associated with an asset or group of assets can be implemented through a lock status bit that is configured to manage, store, or indicate read, write, and / or erase access according to a particular lock policy scheme or arrangement, for example, which can be modified to provide a particular desired granularity of secure asset management for secure PLD 410.

[0156] Figure 11 A block diagram of a tamper detection strategy plan 1102 for a secure PLD 410 according to an embodiment of the present disclosure is shown. In various embodiments, the tamper detection strategy plan 1102 may be implemented by Figure 4 Safety PLD 410 and / or Figure 8A-8B 4. Tamper detection policy plan 1102 may be implemented by elements similar to those described in lock policy plan 802 and 804 in FIG. In particular, tamper detection policy plan 1102 may be implemented by tamper detection policy sector 1160 and / or corresponding tamper detection state register 1164 implemented by or within configuration engine 440 and / or shadow register 860 of configuration engine 440 to allow elements of secure PLD 410 (e.g., via external system 130 of configuration I / O 448, configuration engine 440, PLD fabric 400, security engine 420, and / or other elements of secure PLD 410) to manipulate the tamper detection state of various elements of secure PLD 410.

[0157] exist Figure 11 In the embodiment shown in FIG, the tamper detection strategy plan 1102 includes Figure 8A-8B The locking strategy plans 802 and 804 are similar to the elements shown in the elements (e.g., according to Figure 8A-8B 896, optionally grouping / ungrouping the configuration security lock state 840, the lock policy lock state 861, the device key lock state 858, the other protectable storage lock sectors 864, and the tamper detection status register 1164), where the tamper detection status register 1164 can be grouped within the boot lock state group 892 and subject to the boot group lock state, can be ungrouped and therefore subject to its local lock state rather than the boot or user data group lock state, or can be implemented as a multi-bit non-volatile register within the configuration engine 440 (e.g., in some embodiments, it can operate without a corresponding tamper detection policy 1160). It should be understood that similar techniques can be used to implement other tamper detection policy schemes with other groupings and / or non-groupings to, for example, simplify tamper detection policy operation or provide different levels of tamper detection policy granularity.

[0158] like Figure 11As shown in FIG, configuration engine 440 can be linked to PLD fabric 400 via a tamper detection interrupt bus 1108, which can be configured to provide tamper detection interrupt assertions generated by configuration engine 440 to PLD fabric 400 (e.g., upon detecting an asset tamper attempt, such as an illegal or reserved or otherwise incorrect command provided to configuration I / O 448 and / or other elements of secure PLD 410, or an attempt to access a locked asset (such as a configuration asset or bus or port)). In various embodiments, tamper detection interrupt bus 1108 can be implemented as a separate bus from secure bus 408, such as through one or more common interface blocks associated with the PLC of PLD fabric 400, so as to provide a relatively high priority (e.g., a fast response) bus for tamper detection interrupt assertions. Tamper detection interrupt bus 1108 can alternatively be implemented as part of secure bus 408. In some embodiments, tamper detection interrupt bus 1108 can be implemented as a bidirectional bus or one or more unidirectional buses.

[0159] In some embodiments, for example, tamper detection status register 1164 may be implemented within shadow register 860 of configuration engine 440, which is configured to shadow corresponding tamper detection status stored within tamper detection policy sector 1160 of NVM 450. Upon powering up secure PLD 410, configuration engine 440 may be configured to access tamper detection policy sector 1160, retrieve various tamper detection statuses from tamper detection policy sector 1160, and shadow the tamper detection status within tamper detection status register 1164 of shadow register 860 according to tamper detection policy plan 1102, thereby allowing configuration engine 440 and / or PLD fabric 400 to dynamically access and / or modify various tamper detection statuses. In other embodiments, tamper detection status register 1164 may be implemented within configuration engine 440 (eg, via non-volatile registers of configuration engine 440 ), and secure PLD 410 may omit separate, shadowed tamper detection policy sector 1160 .

[0160] In various embodiments, tamper detection status register 1164 may be configured to store or represent or indicate unauthorized read, write, and / or erase access attempts to specific assets of security PLD 410 (e.g., both the asset and the type of access that constitutes a detected tamper attempt) such as one or more ports of configuration I / O 448 (e.g., JTAG, SSPI, I2C, and / or other ports or protocols supported by configuration I / O 448), one or more ports of programmable I / O 404, one or more sectors of NVM 450, one or more lock states of shadow registers 860, one or more secure buses of security PLD 410, and / or one or more security functions and / or other elements of security engine 420.

[0161] For example, in some embodiments, configuration engine 440 can be configured to detect a specific asset tamper attempt on an asset of secure PLD 410, generate a tamper detection interrupt assertion (e.g., an incorrect configuration command assertion) and provide it to PLD fabric 400 via tamper detection interrupt bus 1108, and / or set tamper detection status register 1164 to indicate the type of asset tamper attempt detected and the corresponding target asset. In other embodiments, PLD fabric 400 can be configured to detect a specific asset tamper attempt on an asset of secure PLD 410, generate a tamper detection interrupt assertion (e.g., a configuration port lock assertion) and provide it to configuration engine 440 via tamper detection interrupt bus 1108, and / or set tamper detection status register 1164 to indicate the type of asset tamper attempt detected and the corresponding target asset. The PLD structure 400 and / or the configuration engine 440 may be configured to read the tamper detection status register 1164 (e.g., which may clear the tamper detection interrupt assertion on the tamper detection interrupt bus 1108) and lock an asset of the secure PLD 410 associated with the detected asset tamper attempt, such as the asset itself or a communication bus or port used to access the asset.

[0162] When an asset is locked, read, write, and / or erase access and / or other lock states can be configured to provide interrelated access to sectors of NVM 450 to help provide secure access to such assets without risking data leakage within such assets. For example, the lock state bits can allow sectors of NVM 450 to (1) be erased but not read or written, (2) be written or erased but not read, (3) be read but not written or erased, or (4) be neither read, written, nor erased, or various combinations thereof. For example, a particular lock state can 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 erased but not read, to help ensure the security and integrity of customer and / or manufacturer data. As described herein, each of these types of access can also be set and / or controlled differently with respect to or for external or internal access.

[0163] Figure 12 FIGURE 12 illustrates a tamper detection management process 1200 for a secure PLD 410 according to an embodiment of the present disclosure. In some embodiments, Figure 12 The operation can be realized by Figures 1-11 More generally, software instructions executed by one or more logic devices associated with the corresponding electronic devices, modules and / or structures depicted in FIG. Figure 12 The operations of the process 1200 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 1200 may be implemented in accordance with the same Figure 12 1200. For example, in other embodiments, one or more blocks may be omitted from process 1200, 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 1200. Although process 1200 is a reference to Figures 1-11 Although the process 1200 is described with reference to systems, devices, and components of the present invention, the process 1200 may be performed by other systems, devices, and components and include different selections of electronic systems, devices, components, assemblies, and / or arrangements. When the process 1200 is initiated, for example, various system parameters may be populated by previously executing a process similar to the process 1200, or may be initialized to zero and / or one or more values ​​corresponding to typical, stored, and / or learned values ​​derived from past operation of the process 1200, as described herein.

[0164] In block 1210, the logic device detects an asset tampering attempt. For example, the configuration engine 440 and / or the PLD structure 400 (e.g., the PLD structure of the locked and / or programmed secure PLD 410) can be configured to detect an asset tampering attempt on a target asset of the secure PLD 410. In some embodiments, the configuration engine 440 can be configured to detect an asset tampering attempt including an incorrect command provided to the configuration engine 440 (e.g., the target asset) via the configuration I / O 448 and / or other buses of the secure PLD 410. For example, such incorrect commands may include illegal or reserved configuration commands, such as unauthenticated commands (e.g., including SRAM readback) that attempt to access locked assets (e.g., via a security permission violation, including a password authentication or permission failure), unauthenticated commands such as unauthenticated asset access requests, attempts to enter manufacturer mode or load the configuration of secure PLD 410, unauthenticated commands that attempt to assert one or more manufacturer commands, unauthenticated commands that attempt to access illegal memory addresses (e.g., via read, write, or erase commands to locked sectors and / or to out-of-range memory addresses), any undefined commands (e.g., from a command decoder implemented by configuration engine 440), and / or other incorrect commands (e.g., which may be listed or otherwise defined within tamper detection policy sector 1160). In particular, such illegal or reserved configuration commands may also include various JTAG-related commands and protocols, including attempting to provide programming instructions when JTAG boundary scan (BSCAN) is enabled but programming (via a JTAG bus or port) is blocked, or attempting to provide programming instructions when programming is enabled but JTAG BSCAN is blocked. In other embodiments, PLD architecture 400 may be configured to detect any such incorrect commands relayed by configuration engine 440 and / or detected as being provided to programmable I / O 404 and / or other buses of safety PLD 410. More generally, any element of safety PLD 410 may be configured to detect such incorrect commands provided to any other element of safety PLD 410.

[0165] In various embodiments, upon detecting any type of asset tampering attempt against any asset of secure PLD 410, configuration engine 440 and / or PLD fabric 400 may be configured to generate a tamper detection interrupt assertion associated with the asset tampering attempt, provide the tamper detection interrupt assertion to other components of secure PLD 410, and / or set tamper detection status register 1164 to indicate the target asset and the type of asset tampering (e.g., read, write, erase) corresponding to the detected asset tampering attempt. For example, if configuration engine 440 detects an asset tampering attempt, configuration engine 440 may be configured to generate a tamper detection interrupt assertion including an incorrect configuration command assertion and provide it to PLD fabric 400 via tamper detection interrupt bus 1108 and / or secure bus 408. Configuration engine 440 may then set tamper detection status register 1164 accordingly. In the event that the PLD fabric 400 detects an asset tampering attempt, the PLD fabric 400 may be configured to generate a tamper detection interrupt assertion, including a configuration port lock assertion, and provide it to the configuration engine 440 via the tamper detection interrupt bus 1108 and / or the secure bus 408. The PLD fabric 400 may then set the tamper detection status register 1164 accordingly via a tamper detection status set command provided to the configuration engine 440 via the secure bus 408.

[0166] In additional embodiments, configuration engine 440 and / or PLD fabric 400 may be configured to detect asset tampering attempts, including physical anomalies, such as abnormal voltage offsets, fluctuations, or patterns of fluctuations detected on one or more communication buses of secure PLD 410 during operation of secure PLD 410 (e.g., associated with bus probing or other physical intrusion), or temperature offsets, fluctuations, or patterns of fluctuations detected within secure PLD 410 and / or one of its components during operation of secure PLD 410 (e.g., associated with attempted disassembly or other physical intrusion), which may be detected by corresponding physical anomaly sensors (e.g., voltage and / or temperature sensors implemented by other IC modules 480).

[0167] In block 1220, the logic device locks the asset associated with the asset tamper attempt. For example, configuration engine 440 and / or PLD structure 400 (e.g., configuration engine 440 and / or PLD structure 400 of locked and / or programmed secure PLD 410) can be configured to lock the secure PLD asset associated with the asset tamper attempt detected in block 1210. In various embodiments, configuration engine 440 and / or PLD structure 400 can be configured to lock the secure PLD asset by adjusting or updating a lock state in shadow register 860 of configuration engine 440, which can then be stored in lock policy 460 of NVM 450 depending on the contents of the corresponding lock policy lock state 861.

[0168] In some embodiments, configuration engine 440 may be configured to receive tamper detection interrupt assertions (including configuration port lock assertions generated by PLD structure 400 in block 1210), read tamper detection status register 1164, and / or use the same as reference Figures 8A-10 A similar process is described to lock access to all external configuration ports (e.g., JTAG, I2C, SPI, MSPI) connected to configuration engine 440 (e.g., locking configuration I / O 448 and / or bus 443, or other buses of secure PLD 410), such as setting the appropriate lock state of shadow register 860. In this case, all JTAG, BSCAN, programming, read ID, and / or other similar functionality of configuration engine 440 and / or secure PLD 410 will be completely blocked. In embodiments where the detected asset tampering attempt is associated with secure bus 408, PLD fabric 400 and / or configuration engine 440 can be configured to implement a secondary traffic gating protocol to lock secure bus 408 but allow communication between PLD fabric 400 and configuration engine 440 (e.g., a secondary secure communication protocol supported by the locked secure bus 408, such as a secondary encrypted communication tunnel between PLD fabric 400 and configuration engine 440). In a related or alternative embodiment, configuration engine 440 may be configured to lock one or more individual secure PLD assets (eg, including individual configuration port access) based on the asset and / or tamper type identified within tamper detection status register 1164 .

[0169] In other embodiments, the PLD fabric 400 can be configured to receive a tamper detection interrupt assertion (including an incorrect configuration command assertion generated by the configuration engine 440 in block 1210), read the tamper detection status register 1164, and / or lock one or more individual secure PLD assets (e.g., including individual configuration port access) based on the asset and / or tamper type identified in the tamper detection status register 1164 via a control command provided to the configuration engine 440. In yet another embodiment, the PLD fabric 400 can be configured to receive a first tamper detection interrupt assertion (including an incorrect configuration command assertion generated by the configuration engine 440 in block 1210), generate a second tamper detection interrupt assertion including a configuration port lock assertion, and then provide it back to the configuration engine 440. In various embodiments, the configuration engine 440 and / or the PLD fabric 400 can be configured to stop asserting the tamper detection interrupt after reading the tamper detection status register 1164.

[0170] In optional block 1230, the logic device reports the asset tamper attempt. For example, the configuration engine 440 and / or the PLD structure 400 (e.g., the locked and / or programmed secure PLD 410) may be configured to use a reference Figures 5A-7 The communication technology described is similar to the communication technology via Figure 5AThe communication network 514 of the secure PLD 510 provides an asset tamper attempt report of the asset tamper attempt detected in block 1210 to any of the secure PLD client 510, secure PLD manufacturer 520, secure PLD programmer 530, user device assembler 540, and / or downstream customer 550. In various embodiments, the configuration engine 440 and / or PLD structure 400 can be configured to encrypt and / or sign the asset tamper attempt report before providing such an asset tamper attempt report, as described herein. Each such report can include a copy of the tamper detection status register 1164, a time associated with the asset tamper attempt, a device key, a trace ID, and / or other information that can be used to identify the secure PLD and / or the user device including the secure PLD. In a related embodiment, any of the secure PLD client 510, secure PLD manufacturer 520, secure PLD programmer 530, user device assembler 540, and / or downstream client 550 can be triggered to intervene in an asset tamper attempt through such a report, thereby preventing a denial of service (DOS) attack on the operation of the secure PLD 410 and / or the user device including the secure PLD 410. For example, any such entity can analyze a received asset tamper attempt report, generate a new configuration image for the PLD fabric 400 that is designed to mitigate or prevent the detected asset tamper attempt without halting the operation of the secure PLD 410 and / or the user device including the secure PLD 410, and securely provide the new configuration image to the secure PLD 410 for secure booting of the PLD 410, as described herein.

[0171] In block 1240, the logic device unlocks the asset associated with the asset tamper attempt. For example, the configuration engine 440 and / or the PLD structure 400 (e.g., the configuration engine 440 and / or the PLD structure 400 of the locked and / or programmed secure PLD 410) can be configured to unlock the secure PLD asset associated with the asset tamper attempt detected in block 1210 and locked in block 1220. In various embodiments, the configuration engine 440 and / or the PLD structure 400 can 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 can then be stored in the lock policy 460 of the NVM 450 depending on the contents of the corresponding lock policy lock state 861.

[0172] In some embodiments, the configuration engine 440 and / or the PLD fabric 400 may be configured to detect that the asset tamper attempt detected in block 1210 has ceased before restoring the operational state of the secure PLD 410 at block 1210 (e.g., before detecting the asset tamper attempt). For example, the configuration engine 440 and / or the PLD fabric 400 may be configured to unlock the asset locked in block 1220 (e.g., in the case of a locked communication port, the secure PLD 410 typically must unlock the communication port before tamper activity on the communication port can be detected), monitor the secure PLD 410 for an updated asset tamper attempt status (e.g., the same or different asset tamper attempt type for the same asset or a different asset), and selectively restore the previous operational state of the secure PLD 410 based on the updated asset tamper attempt status. Configuration engine 440 and / or PLD structure 400 can be configured to wait a preselected tamper delay period (e.g., stored within tamper detection policy sector 1160) after locking an asset (as in block 1220), and to repeatedly wait for this preselected tamper delay period before attempting to detect that the asset tamper attempt has ceased in block 1210, or as the asset tamper attempt detected in block 1210 continues and / or a different asset tamper attempt is detected in block 1240.

[0173] In other embodiments, the configuration engine 440 and / or the PLD fabric 400 may be configured to, after first detecting authenticated access to an asset of the secure PLD 410, unlock the secure PLD asset associated with the asset tamper attempt detected in block 1210 and lock the asset in block 1220. For example, the configuration engine 440 and / or the PLD fabric 400 may be configured to detect asset tamper recovery commands provided to the configuration engine 440 via the configuration I / O 448 and / or other bus of the secure PLD 410. For example, such asset tamper recovery commands may include various legitimate configuration commands, such as commands attempting to access locked assets through authentication (e.g., through authenticated security permissions, including successful password authentication or permissions), such as authenticated asset access requests, authenticated commands attempting to enter manufacturer mode or configuration of the secure PLD 410, authenticated commands attempting to assert one or more manufacturer commands, and / or other authorized commands (e.g., which may be listed or otherwise defined within the tamper detection policy sector 1160).

[0174] In another embodiment, the use and reference Figures 5A-7 Similar to the communication techniques described above, in response to reporting an asset tamper attempt in optional block 1230 and / or prior to unlocking an asset associated with the asset tamper attempt detected in block 1210 and locked in block 1220, the configuration engine 440 and / or PLD structure 400 can be configured to communicate via Figure 5A The communication network 514 receives an asset unlock request and / or a new configuration / boot image (e.g., designed to mitigate detected asset tampering attempts) from any of the secure PLD client 510, the secure PLD manufacturer 520, the secure PLD programmer 530, the user device assembler 540, and / or the downstream client 550. In various embodiments, such a secure PLD asset unlock request and / or new configuration image can be signed, encrypted, and / or include additional information to enable the secure PLD 410 to authenticate the secure PLD asset unlock request and / or new configuration image, as described herein. In a particular embodiment, such a secure PLD asset unlock request and / or new configuration image can include a trace ID of the specific secure PLD 410 being unlocked (e.g., extracted from a list of locked PLDs provided by the secure PLD manufacturer 520), and the external system 130 and / or HSM 526 of the secure PLD client 510 can be configured to sign such a secure PLD asset unlock request and / or new configuration image using its application private key or a different private key, as described herein.

[0175] In some embodiments, the configuration engine 440 and / or the PLD architecture 400 can be configured to authenticate a secure PLD asset unlock request and / or a new configuration image. In one embodiment, the secure PLD 410 can be configured to authenticate a secure PLD asset unlock request signed by an application or other private key using an application or other public key stored in the NVM 450 during a lock, programming, or other configuration step in the provisioning process, as described herein. In another embodiment, the secure PLD 410 can be configured to authenticate such secure PLD asset unlock request and / or a new configuration image by comparing a trace ID in the secure PLD asset unlock request and / or the new configuration image with a trace 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 trace ID in the secure PLD asset unlock request and / or the new configuration image indicates an authenticated secure PLD asset unlock request and / or the new configuration image. In further embodiments, such an authenticated process may include decrypting the secure PLD asset unlock request and / or the new configuration image using a public key stored in NVM 450, as described herein.

[0176] Thus, by employing the systems and methods described herein, embodiments of the present disclosure can provide flexible and secure asset tamper detection management for secure PLDs. Customer-locked and / or otherwise provisioned secure PLDs can be monitored for external tamper attempts and securely locked, erased, and / or updated without risking exposure to customer data. Furthermore, secure PLDs can be securely unlocked, re-provisioned, and / or otherwise put back into operation based on updated customer data or new customer applications after asset tamper attempts have ceased, without the need to isolate or otherwise destroy the secure PLDs.

[0177] Where applicable, the various embodiments provided by the present disclosure may be implemented using hardware, software, or a combination of hardware and software. Likewise, 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. Furthermore, where applicable, it is envisioned that software components may be implemented as hardware components, and vice versa.

[0178] 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, 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.

[0179] 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 programmable logic device (PLD) asset tampering detection and management 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 configuration image stored in a non-volatile memory (NVM) of the security PLD and / or coupled to the configuration engine via a configuration input / output (I / O) of the security PLD, wherein the security PLD is configured to perform a computer-implemented method comprising: detecting an asset tampering attempt on a target asset of the secure PLD; and A protectable asset associated with the detected asset tampering attempt is locked, wherein the protectable asset includes a target asset, configuration I / O, and / or communication bus of the secure PLD.

2. The secure PLD asset tampering detection and management system of claim 1 , wherein detecting the asset tampering attempt comprises: Incorrect commands provided to the configuration engine via the configuration I / O and / or other bus of the security PLD are detected by the configuration engine, wherein the incorrect commands include illegal or reserved configuration commands.

3. The secure PLD asset tampering detection and management system according to claim 1, wherein the illegal or reserved configuration commands include: Unauthenticated commands that attempt to access locked assets without authentication, attempt to enter manufacturer mode or load a configuration for the secure PLD, attempt to assert one or more manufacturer commands, or attempt to access an illegal memory address or any undefined command.

4. The secure PLD asset tampering detection and management system of claim 1 , wherein detecting the asset tampering attempt comprises: Incorrect commands provided to a programmable I / O of the security PLD are detected by the PLD fabric, the incorrect commands being coupled to the PLD fabric and / or relayed via other buses of the configuration engine and / or the security PLD.

5. The secure PLD asset tamper detection and management system of claim 1 , wherein the asset tamper attempt comprises a physical anomaly comprising an abnormal voltage bias, fluctuation, or fluctuation pattern detected on one or more communication buses during operation of the secure PLD and / or a temperature excursion, fluctuation, or fluctuation pattern detected within the secure PLD during operation of the secure PLD.

6. The secure PLD asset tampering detection and management system according to claim 1, wherein: The tamper detection interrupt assertion includes an incorrect configuration command assertion and / or a configuration port lock assertion; as well as Detecting asset tampering attempts includes: generating a tamper detection interrupt assertion associated with the detected attempt to tamper with the asset, setting a tamper detection status register of the configuration engine to indicate the target asset and an asset tamper attempt type corresponding to the detected asset tamper attempt, wherein the asset tamper attempt type includes an attempted read, write, and / or erase access to the target asset, and Do the following: The configuration engine provides the tamper detection interrupt assertion to the PLD structure, and / or The tamper detection interrupt assertion is provided by the PLD fabric to the configuration engine, wherein locking the protectable asset includes locking the configurable I / O, programmable I / O, and / or other buses of the secure PLD.

7. The secure PLD asset tamper detection and management system of claim 1 , wherein the computer-implemented method further comprises: Providing an asset tamper attempt report of the detected asset tamper report to one or more of a secure PLD customer, a secure PLD manufacturer, a secure PLD programmer, a user equipment assembler, and / or a downstream customer via a communication network coupled to the secure PLD via the configuration I / O or programmable I / O of the secure PLD, wherein the asset tamper attempt report includes a copy of a tamper detection status register of the configuration engine, a time associated with the detected asset tamper attempt, a device key associated with the secure PLD, and / or a trace ID associated with the secure PLD.

8. The secure PLD asset tamper detection and management system of claim 1 , wherein the computer-implemented method further comprises unlocking the protectable asset associated with the detected asset tamper attempt, wherein unlocking the protectable asset comprises: waiting a preselected tamper delay period after locking the securable asset; updating a lock status associated with the protectable asset to unlock the protectable asset; monitoring the secure PLD for an updated asset tamper attempt status; as well as An operational state for the secure PLD is selectively restored based on the updated asset tamper attempt status.

9. The secure PLD asset tamper detection and management system of claim 1 , wherein the computer-implemented method further comprises unlocking the protectable asset associated with the detected asset tamper attempt, wherein unlocking the protectable asset comprises: detecting authenticated access to any asset of the secure PLD, wherein the authenticated access comprises an asset tamper recovery command provided to the configuration engine via the configuration I / O and / or other bus of the secure PLD; as well as A lock status associated with the protectable asset is updated to unlock the protectable asset.

10. The secure PLD asset tamper detection and management system of claim 1 , wherein the computer-implemented method further comprises unlocking the protectable asset associated with the detected asset tamper attempt, wherein unlocking the protectable asset comprises: receiving, over a communication network coupled to the secure PLD via the configuration I / O or programmable I / O of the secure PLD, an asset unlock request corresponding to a locked protectable asset and / or a new configuration image for the secure PLD from one or more of a secure PLD customer, a secure PLD manufacturer, a secure PLD programmer, a user device assembler, and / or a downstream customer; authenticating the asset unlock request and / or the new configuration image; as well as A lock status associated with the protectable asset is updated to unlock the protectable asset and / or the new configuration image is stored in a configuration image sector of the NVM with an authentication bit set to indicate that the configuration is authenticated and bootable.

11. A method for asset tamper detection management for a secure programmable logic device (PLD), the method comprising: detecting an asset tampering attempt on a target asset of the secure PLD, wherein the secure PLD includes a PLD structure and a configuration engine 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 via a configuration input / output (I / O) of the secure PLD; as well as A protectable asset associated with the detected asset tampering attempt is locked, wherein the protectable asset includes a target asset, configuration I / O, and / or communication bus of the secure PLD.

12. The method of claim 11 , wherein detecting the asset tampering attempt comprises: Incorrect commands provided to the configuration engine via the configuration I / O and / or other bus of the security PLD are detected by the configuration engine, wherein the incorrect commands include illegal or reserved configuration commands.

13. The method according to claim 11, wherein the illegal or reserved configuration command comprises: Unauthenticated commands that attempt to access locked assets without authentication, attempt to enter manufacturer mode or load a configuration for the secure PLD, attempt to assert one or more manufacturer commands, or attempt to access an illegal memory address or any undefined command.

14. The method of claim 11 , wherein detecting the asset tampering attempt comprises: Incorrect commands provided to a programmable I / O of the security PLD are detected by the PLD fabric, the incorrect commands being coupled to the PLD fabric and / or relayed via other buses of the configuration engine and / or the security PLD.

15. The method of claim 11, wherein the asset tampering attempt comprises a physical anomaly comprising an abnormal voltage bias, fluctuation, or pattern of fluctuation detected on one or more communication buses during operation of the secure PLD and / or a temperature excursion, fluctuation, or pattern of fluctuation detected within the secure PLD during operation of the secure PLD.

16. The method of claim 11, wherein: The tamper detection interrupt assertion includes an incorrect configuration command assertion and / or a configuration port lock assertion; as well as Detecting asset tampering attempts includes: Generates tamper detection interrupt assertions associated with detected asset tampering attempts, setting a tamper detection status register of the configuration engine to indicate the target asset and an asset tamper attempt type corresponding to the detected asset tamper attempt, wherein the asset tamper attempt type includes an attempted read, write, and / or erase access to the target asset, and Do the following: The configuration engine provides the tamper detection interrupt assertion to the PLD structure, and / or The tamper detection interrupt assertion is provided by the PLD fabric to the configuration engine, wherein locking the protectable asset includes locking the configurable I / O, programmable I / O, and / or other buses of the secure PLD.

17. The method according to claim 11, further comprising: Providing an asset tamper attempt report of the detected asset tamper report to one or more of a secure PLD customer, a secure PLD manufacturer, a secure PLD programmer, a user equipment assembler, and / or a downstream customer via a communication network coupled to the secure PLD via the configuration I / O or programmable I / O of the secure PLD, wherein the asset tamper attempt report includes a copy of a tamper detection status register of the configuration engine, a time associated with the detected asset tamper attempt, a device key associated with the secure PLD, and / or a trace ID associated with the secure PLD.

18. The method of claim 11 , further comprising unlocking the protectable asset associated with the detected asset tampering attempt, wherein unlocking the protectable asset comprises: waiting a preselected tamper delay period after locking the securable asset; updating a lock status associated with the protectable asset to unlock the protectable asset; monitoring the secure PLD for an updated asset tamper attempt status; as well as An operational state for the secure PLD is selectively restored based on the updated asset tamper attempt status.

19. The method of claim 11 , further comprising unlocking the protectable asset associated with the detected asset tampering attempt, wherein unlocking the protectable asset comprises: detecting authenticated access to any asset of the secure PLD, wherein the authenticated access comprises an asset tamper recovery command provided to the configuration engine via the configuration I / O and / or other bus of the secure PLD; as well as A lock status associated with the protectable asset is updated to unlock the protectable asset.

20. The method of claim 11, further comprising unlocking the protectable asset associated with the detected asset tampering attempt, wherein unlocking the protectable asset comprises: receiving, over a communication network coupled to the secure PLD via the configuration I / O or programmable I / O of the secure PLD, an asset unlock request corresponding to a locked protectable asset and / or a new configuration image for the secure PLD from one or more of a secure PLD customer, a secure PLD manufacturer, a secure PLD programmer, a user device assembler, and / or a downstream customer; authenticating the asset unlock request and / or the new configuration image; as well as A lock status associated with the protectable asset is updated to unlock the protectable asset and / or the new configuration image is stored in a configuration image sector of the NVM with an authentication bit set to indicate that the configuration is authenticated and bootable.

Images