Root of trust chain and updatable security for programmable logic devices, systems, and methods

Abstract

The invention relates to a root of trust chain and updatable security for programmable logic devices, systems, and methods. Various techniques are provided for providing a root chain of trust for a programmable logic device (PLD), updating a security protocol, and generating a trusted customer configuration bitstream. In one example, a method includes configuring a hardware component of a PLD with an inherently trusted default set of operations, the default set of operations being stored invariably in a non-volatile memory and including a first root of trust of the PLD. The method also includes authenticating, by a hardware component configured with a default set of operations, a customer configuration bitstream including an update set of operations. The method further includes reconfiguring the hardware component to replace the default operation set with an update operation set, where the update operation set includes a second root of trust for the PLD, if the authentication is successful. Additional devices, systems, and methods are also provided.

Description

Technical Field

[0001] The present disclosure relates generally to programmable logic devices, and more particularly to a root chain of trust and security protocols for programmable logic devices. Background Art

[0002] A programmable logic device (PLD), such as a field programmable gate array (FPGA), a complex programmable logic device (CPLD), a field programmable system on a chip (FPSC), or other type of programmable device, can be configured with various designs to implement desired functionality. The design can be converted into synthetic components that are assigned to physical hardware components of the PLD configured to implement the design. For example, a configuration bitstream can be stored in a memory and loaded (e.g., programmed) into the appropriate hardware components to configure the PLD to implement the design.

[0003] PLD customers typically invest significant resources in developing the design of the PLD. Therefore, protecting the associated configuration bitstream and protecting against subversion of the desired operation or capabilities of the PLD are important considerations for many PLD customers. Therefore, the PLD may be implemented with a security protocol to encrypt the configuration bitstream and prevent unauthorized changes.

[0004] However, in conventional PLDs, security protocols may be implemented by a microcontroller whose operation is determined by non-upgradeable read-only memory (ROM) and / or other fixed hardware. As a result, it may be difficult or impossible to upgrade the security protocols of a conventional PLD after the PLD has been provided to a customer. This is a particular concern if the previously implemented security protocols are deemed inadequate in the future, such as due to advances in quantum computing. Summary of the invention

[0005] Various techniques for providing a root of trust chain for a PLD using various configuration bitstreams are provided. For example, in an embodiment, a method includes configuring a hardware component of the PLD with an inherently trusted default operation set, the default operation set being immutably stored in a non-volatile memory and comprising a first root of trust for the PLD; authenticating, by the hardware component configured with the default operation set, a customer configuration bitstream comprising an updated operation set; and if the authentication is successful, reconfiguring the hardware component to replace the default operation set with the updated operation set, wherein the updated operation set comprises a second root of trust for the PLD.

[0006] Additional techniques for updating security protocols of a PLD are provided. For example, in an embodiment, a method includes configuring a hardware component of the PLD with an inherently trusted default operation set, the default operation set being immutably stored in a non-volatile memory and comprising a first root of trust for the PLD; further configuring the hardware component with an inherently trusted default security protocol set stored in the non-volatile memory; authenticating the updated security protocol set of the PLD by the hardware component configured with the default operation set; and replacing the default security protocol set with the updated security protocol set in the non-volatile memory if the authentication of the updated security protocol set is successful.

[0007] Further techniques for generating a trusted customer configuration bitstream for a PLD are provided. For example, in an embodiment, a method includes receiving a design of a programmable logic device (PLD); adding a trusted security block to the design; and generating a customer configuration bitstream for configuring hardware components of the PLD based on the design, wherein the customer configuration bitstream includes: an update operation set for replacing an inherently trusted default operation set that is immutably stored in a non-volatile memory and includes a first root of trust for the PLD, and a trusted security block for authenticating the customer configuration bitstream.

[0008] Additional embodiments related to PLDs, devices, systems, and other methods are also disclosed. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] Figure 1 A block diagram of a PLD, a memory, an external system, and a trusted device according to an embodiment of the present disclosure is illustrated.

[0010] Figure 2 A block diagram of a nonvolatile memory according to an embodiment of the present disclosure is illustrated.

[0011] Figure 3 A block diagram of configurable hardware components of a PLD according to an embodiment of the present disclosure is illustrated.

[0012] Figure 4 A process of populating a nonvolatile memory according to an embodiment of the present disclosure is illustrated.

[0013] Figure 5 The process of generating a customer configuration bitstream according to an embodiment of the present disclosure is illustrated.

[0014] Figure 6 A process of operating a PLD according to an embodiment of the present disclosure is illustrated.

[0015] Figure 7 A process of authenticating a customer configuration bitstream according to an embodiment of the present disclosure is illustrated.

[0016] Figure 8A process of updating a security protocol according to an embodiment of the present disclosure is illustrated.

[0017] Embodiments of the present disclosure and their advantages are best understood by referring to the following detailed description.It should be appreciated that like reference numerals are used to identify like elements illustrated in one or more of the accompanying drawings. DETAILED DESCRIPTION

[0018] Various techniques are disclosed for providing a root chain of trust, updating security protocols, and generating a trusted customer configuration (eg, implemented as a customer configuration bitstream or otherwise) for a PLD.

[0019] The PLD may communicate with non-volatile memory (e.g., on a separate die from the PLD in the same microchip, on the same die as the PLD, on a separate microchip from the PLD, and / or implemented in other ways). The non-volatile memory stores various configuration bitstreams, security protocols, metadata, data, and / or other information that the PLD may access under various circumstances.

[0020] The non-volatile memory may include a root of trust image (RTI) for the PLD, which is immutably stored in the non-volatile memory, such as an inherently trusted party (e.g., a manufacturer, a customer, a country, and / or other inherently trusted entity). The RTI may be an inherently trusted default configuration for a hardware component of the PLD, and thus may be used to configure the hardware component without requiring authentication prior to each use. For example, the default configuration provided by the RTI may include a plurality of default operations to be performed by the hardware component when the hardware component is configured by the default configuration in response to a cold start (e.g., a power-on reset) of the PLD and / or in response to a reconfiguration performed by an appropriate trigger.

[0021] The non-volatile memory may include a Trusted Root Image Extension (RTIE) that identifies a default security protocol used by the PLD to encrypt and / or decrypt: a customer configuration bitstream of the PLD; data stored, transmitted, and / or received by the PLD and / or the non-volatile memory; and / or other purposes, as appropriate. Similar to the RTIE, the RTIE may also be an inherently trusted default configuration for a hardware component of the PLD, and thus may be used to configure the hardware component without requiring authentication prior to each use. Notably, the RTIE in the non-volatile memory may be replaced (e.g., in the field as an upgrade) with an updated RTIE having an updated security protocol in a manner that allows the PLD to operate with an improved security protocol even after the PLD has been deployed. Thus, in the event that the original RTIE security protocol becomes obsolete, compromised, and / or less effective (e.g., due to advances in quantum computing and / or otherwise), the PLD may be readily adapted to use the improved security protocol.

[0022] The non-volatile memory may include one or more customer configuration bitstreams that may be authenticated and used to configure hardware components of the PLD in place of the RTI default configuration. For example, the customer configuration bitstream may be provided with a trusted security block that, when detected by a PLD configured with the RTI default configuration, allows the PLD to trust the customer configuration bitstream. For example, in some embodiments, the trusted security block may restrict access to the non-volatile memory by hardware components configured by the customer configuration bitstream. Thus, the customer configuration bitstream may provide a second root of trust in a chain of roots of trust, where a first root of trust is provided by the RTI default configuration.

[0023] In some embodiments, a previously authenticated customer configuration bitstream may be identified by metadata stored in non-volatile memory. Thus, if the metadata identifies that the PLD was previously authenticated, then the PLD may not need to reauthenticate the customer configuration bitstream. In some embodiments, if the RTIE security protocol has been updated, then a previously authenticated customer configuration bitstream may need to be reauthenticated prior to use (e.g., the customer configuration bitstream may not be encrypted with and / or otherwise compatible with the updated RTIE security protocol).

[0024] In addition, because the customer configuration bitstream includes a trusted security block, a PLD configured with a customer configuration bitstream can authenticate another customer configuration bitstream without relying on the RTI default configuration (e.g., when configured with the current customer configuration bitstream, the PLD does not need to be reconfigured with the RTI default settings to authenticate another customer configuration bitstream). Therefore, a root chain of trust can be provided by the RTI default configuration and extended to multiple customer configuration bitstreams.

[0025] Additionally, various customer configuration bitstreams can be used with the RTIE or updated RTIE (e.g., even after the RTI default configuration is replaced by the customer configuration bitstream). Thus, the RTI default configuration and the RTIE security protocol can be replaced independently of each other, and the customer configuration bitstream can be used with current or future security protocols.

[0026] The non-volatile memory may include various additional data and metadata, as discussed further herein.

[0027] In some embodiments, the customer configuration bitstream may be generated by an external device or system separate from the PLD and operable to add the trusted security block to the customer configuration bitstream (e.g., stored in a resulting customer configuration bitstream used to configure hardware components of the PLD, with operations implementing the customer design as well as the trusted security block). In some embodiments, the additional device or system separate from the PLD and the generating device or system may independently detect the presence of the trusted security block in the customer configuration bitstream and thereby verify that the customer configuration bitstream includes a minimum level of security (e.g., preventing a PLD hardware component configured with the customer configuration bitstream from directly accessing non-volatile memory, thereby preventing such hardware component from subverting the desired operation or capabilities of the PLD by making unauthorized changes to various information stored in the non-volatile memory).

[0028] Referring now to the accompanying drawings, Figure 1 A block diagram of PLD 100 , nonvolatile memory 103 , external system 130 , and trusted device 105 according to an embodiment of the present disclosure is illustrated.

[0029] In the illustrated embodiment, PLD 100 and nonvolatile memory 103 are implemented on separate dies provided within the same microchip 101. Other embodiments are also contemplated, such as PLD 100 and nonvolatile memory 103 being implemented together on the same die, on separate dies and separate microchips, and / or other implementations as discussed.

[0030] The PLD 100 (e.g., a field programmable gate array (FPGA), a complex programmable logic device (CPLD), a field programmable system on a chip (FPSC), or other type of programmable device) typically includes various physical hardware components (also referred to as configurable hardware components), such as input / output (I / O) blocks 102, logic blocks 104 (e.g., also referred to as programmable logic blocks (PLBs), programmable function units (PFUs), or programmable logic cells (PLCs)), and other components discussed, which can be configured according to various combinations of RTI configurations, RTIE configurations, and / or customer configuration bit streams stored in the non-volatile memory 103 and discussed further herein.

[0031] I / O block 102 provides I / O functionality (e.g., supports one or more I / O and / or memory interface standards) for PLD 100, while logic block 104 provides logic functionality (e.g., look-up table (LUT) logic or logic gate array-based logic) for PLD 100. Serializer / deserializer (SERDES) block 150 and physical coding sublayer (PCS) block 152 may provide additional I / O functionality. In various embodiments, I / O block 102 and SERDES block 150 may route signals to or from associated external ports (e.g., physical pins) of PLD 100. PLD 100 may also include hard intellectual property core (IP) block 160 to provide additional functionality (e.g., substantially predetermined functionality provided in hardware that may be configured with less programming than logic block 104).

[0032] PLD 100 may also include memory blocks 106 (e.g., blocks of EEPROM memory blocks, RAM (e.g., static and / or dynamic) memory blocks, and / or flash memory blocks), clock-related circuitry 108 (e.g., clock sources, PLL circuits, and / or DLL circuits), and / or various routing resources 180 (e.g., interconnects and appropriate switching logic to provide paths for routing signals throughout PLD 100, such as for clock signals, data signals, or others), as appropriate. In various embodiments, routing resources 180 may include user-configurable routing resources and hardwired signal paths. In general, the various physical hardware components of PLD 100 may be used to perform their intended functions for a desired application, as will be appreciated by those skilled in the art.

[0033] For example, I / O block 102 may be used to program PLD 100 (such as memory block 106 (e.g., including volatile configuration memory)) or to transfer information (e.g., various types of data and / or control signals) to / from PLD 100 through various external ports, as will be understood by those skilled in the art. I / O block 102 may provide a first programming port (which may represent a central processing unit (CPU) port, a peripheral data port, a serial peripheral interface (SPI), and / or a sysCONFIG programming port) and / or a second programming port, such as a Joint Test Action Group (JTAG) port (e.g., by adopting a standard such as the Institute of Electrical and Electronics Engineers (IEEE) 1149.1 or 1532 standards). For example, I / O block 102 may generally be included to receive a configuration bit stream (e.g., via connection 142) to configure PLD 100 for its intended use and to support serial or parallel device configuration and information transfer with SERDES block 150, PCS block 152, hard IP block 160, and / or logic block 104, as appropriate.

[0034] For example, in some embodiments, any of the various components discussed herein may be configured in response to PLD 100 (e.g., implemented by appropriate logic, such as one or more processors, finite state machines, and / or other hardware and / or software) passing an RTI configuration, an RTIE configuration, a customer configuration bitstream, and / or other data (e.g., any of which may be stored in non-volatile memory 103 and / or elsewhere, as appropriate) via routing resources 180. In some embodiments, the configuration and / or data may be stored locally on PLD 100 (e.g., in one or more memory blocks 106) and / or stored externally to PLD 100 (e.g., in memory 134 of external system 130) by non-volatile memory 103.

[0035] It should be understood that the number and placement of the various components are not limiting and may depend on the desired application. For example, various components may not be required for a desired application or design specification (eg, for the type of programmable device selected).

[0036] Furthermore, it should be understood that components are illustrated in block form for clarity, and that various components are generally distributed throughout PLD 100, such as in and between logic blocks 104, hard IP blocks 160, and routing resources 180 to perform their conventional functions (e.g., storing configurations for PLD 100 or providing interconnect structures 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.

[0037] Non-volatile memory 103 (e.g., flash memory and / or any other desired type of non-volatile memory) can store various RTI configurations, RTIE configurations, customer configuration bitstreams, and / or other data for reading, writing, and / or configuring hardware components of PLD 100, as discussed further herein. Non-volatile memory 103 can communicate with PLD 100 via connection 142, which can be implemented in any suitable manner. For example, in some embodiments, connection 142 can be an SPI connection (e.g., actual or emulated) that communicates with I / O block 102.

[0038] Although nonvolatile memory 103 is illustrated as communicating with PLD 100 via connection 142, other connections are contemplated. For example, in some embodiments, nonvolatile memory 103 may communicate directly with external system 130, trusted device 105, and / or other systems or devices, as appropriate.

[0039] System 130 (also referred to as an external device, for example) may be used to generate a desired customer configuration bitstream for PLD 100 based on a customer design. As discussed further herein, system 130 may add a trusted security block to the customer configuration bitstream to provide a minimum level of security for the customer configuration bitstream. This configuration may be stored in non-volatile memory 103 and / or elsewhere, as appropriate, and used by PLD 100 to configure various hardware components of PLD 100.

[0040] In the illustrated embodiment, the system 130 is implemented as a computer system. In this regard, the system 130 includes, for example, one or more processors 132 (e.g., implemented by appropriate logic as discussed with respect to the PLD 100), which may be configured to execute instructions, such as software instructions, provided in one or more memories 134 and / or stored in a non-transitory form in one or more non-transitory machine-readable media 136 (e.g., memory or other appropriate storage media internal or external to the system 130). For example, in some embodiments, the system 130 may run a PLD configuration application, such as Lattice Radiant software available from Lattice Semiconductor Corporation, to allow a user (e.g., a customer or manufacturer) to create a desired configuration and generate a corresponding configuration bitstream to program the PLD 100.

[0041] 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 device) for receiving user commands or program input to prepare a desired configuration of PLD 100. As shown, system 130 may communicate with PLD 100 via connection 140.

[0042] In some embodiments, system 130 can be a test bench operated by a predetermined inherently trusted party (e.g., a manufacturer, customer, country, and / or other trusted party) to generate and / or store RTI configurations, RTIE configurations, and / or other configurations and data in non-volatile memory 103 (e.g., during manufacture of microchip 101).

[0043] Trusted device 105 (e.g., also referred to as a trusted system) is separate from microchip 101 and system 130 (e.g., but in some embodiments can communicate with it), and is operable to independently detect the presence of a trusted security block in a customer configuration bitstream generated by system 130, thereby verifying that the customer configuration bitstream includes the minimum level of security discussed. Trusted device 105 can be implemented with any of the various components of system 130 discussed herein to provide this feature. Trusted device 105 can communicate with system 130 (e.g., receive a customer configuration bitstream for verification) via connection 141.

[0044] Figure 2 A block diagram of non-volatile memory 103 according to an embodiment of the present disclosure is illustrated. As discussed, non-volatile memory 103 stores various information that can be used to configure PLD 100 and / or facilitate its operation according to various default configurations, customer configuration bitstreams, and security protocols. Various configurations (e.g., configuration bitstreams) stored in non-volatile memory 103 can be loaded (e.g., programmed) into configurable hardware components of PLD 100 (e.g., by configuration engine 110) to configure or reconfigure such hardware components discussed herein.

[0045] RTI 210 is an inherently trusted default configuration of the hardware components of PLD 100 that does not require authentication before each use. RTI 210 may be immutably stored in non-volatile memory 103 by a manufacturer or other inherently trusted party (e.g., the address of non-volatile memory 103 storing RTI 210 may be write-prohibited by PLD 100). RTI 210 may be a configuration bitstream that may include a plurality of default operations executed by configurable hardware components of PLD 100 in response to a power-on reset of PLD 100 (e.g., a cold boot and / or in response to a reconfiguration performed by an appropriate trigger).

[0046] RTIE 290 is an inherently trusted set of security protocols used by PLD 100 that do not require authentication prior to each use. RTIE 290 may be provided by a manufacturer or other inherently trusted party. RTIE 290 may provide security protocols for encrypting and / or decrypting: a customer configuration bitstream of the PLD; data stored, sent, and / or received by the PLD and / or nonvolatile memory; and / or other purposes, as appropriate. RTIE 290 may be replaced with an updated RTIE having an updated security protocol (e.g., in the field for upgrades) in a manner that allows PLD 100 to operate with improved security protocols even after PLD 100 is deployed to a customer.

[0047] Metadata 220 is cryptographic metadata used by RTIE 210, such as cryptographic keys used by various security protocols implemented by RTIE 290 and an identification of whether PLD 100 should be further configured with RTIE 290 during operation.

[0048] The customer configuration bitstream 240 (also referred to, for example, as customer configuration 0 or a first customer configuration bitstream) configures the hardware components of the PLD 100 in place of the RTI 210 or another customer configuration (e.g., the customer configuration bitstream 260). For example, after the RTI 210 configures the PLD 100, the customer configuration bitstream 240 may be authenticated (e.g., by the presence of a trusted security block and / or metadata 230 identifying a previous authentication, as discussed) and loaded into the PLD 100 to configure the hardware components to implement the customer design. As discussed, the customer configuration bitstream 240 may provide a second root of trust in a root of trust chain, where the RTI 210 provides a first root of trust. The metadata 230 is cryptographic metadata used by the customer configuration bitstream 240 and may identify whether the customer configuration bitstream 240 has been previously authenticated, as discussed.

[0049] The customer configuration bitstream 260 (also referred to, for example, as customer configuration 1 or a second customer configuration bitstream) configures the hardware components of the PLD 100 in place of the RTI 210 or another customer configuration (e.g., the customer configuration bitstream 240). For example, after the customer configuration bitstream 240 configures the PLD 100, the customer configuration bitstream 260 may then be authenticated (e.g., by the presence of a trusted security block and / or metadata 250 identifying a previous authentication, as discussed) and loaded into the PLD 100 to configure the hardware components to implement the customer design. As discussed, the customer configuration bitstream 260 may provide a third root of trust in a root of trust chain, where a first root of trust is provided by the RTI 210 and a second root of trust is provided by the customer configuration bitstream 240. In another embodiment, the root of trust chain may include only the RTI 210 and the customer configuration bitstream 260. The metadata 250 is cryptographic metadata used by the customer configuration bitstream 260 and may identify whether the customer configuration bitstream 260 has been previously authenticated as discussed.

[0050] Metadata 270 is additional metadata that may be populated by a customer and associated with customer configuration bitstreams 240 and / or 260. User memory 280 is encrypted memory that may be populated by a user of PLD 100 and may be used by PLD 100 during runtime and / or otherwise, as appropriate.

[0051] Figure 3 FIG. 1 is a block diagram of a configurable hardware component 300 of a PLD 100 according to an embodiment of the present disclosure. Figure 1 Similarly illustrated, PLD 100 and non-volatile memory 103 may be implemented on separate dies provided in the same microchip 101 , and may communicate via connection 142 .

[0052] Hardware component 300 may include various physical hardware components, such as I / O block 102 , logic block 104 , and others, as discussed, and may be configured according to various combinations of RTI configurations, RTIE configurations, and / or customer configurations stored in non-volatile memory 103 .

[0053] For example, a portion 302 of the hardware component 300 may be configured with a trusted security block 310 that provides various security features to facilitate interfacing of the non-volatile memory 103 with the hardware component 300, including, but not limited to, memory management, cryptographic algorithms, securely controlled flash memory access, and interface emulation (e.g., for SPI-based communications or others). Another portion 304 of the hardware component 300 may be configured with additional configurations 320 that may include various combinations of RTI 210 configurations, RTIE 290 configurations, customer configuration bitstreams 240 / 260 (e.g., for implementing customer designs), and / or other configurations stored in the non-volatile memory 103 and loaded (e.g., programmed) into the portion 302 of the hardware component 300.

[0054] As shown, direct communication between hardware component 300 and non-volatile memory 103 is limited to trusted security block 310. Additional configuration 320 cannot communicate directly with non-volatile memory 103. Instead, communication between additional configuration 320 and non-volatile memory 103 is limited (e.g., monitored, restricted, and / or otherwise managed) by trusted security block 310, which provides a minimum level of security to prevent additional configuration 320 from directly accessing non-volatile memory 103, thereby preventing additional configuration 320 from subverting the desired operation or capabilities of PLD 100 by making unauthorized changes to various information stored in non-volatile memory 103).

[0055] Figure 4 FIG. 1 illustrates a process of filling the non-volatile memory 103 according to an embodiment of the present disclosure. In some embodiments, Figure 4 The process may be performed during manufacture and / or initial deployment of PLD 100 .

[0056] In operation 410, RTI 210 is stored in non-volatile memory 103. As discussed, RTI 210 may be stored by a manufacturer or other inherently trusted party in an unchangeable manner (e.g., using a test bench and / or other methods provided by system 130) such that it cannot be erased, replaced, overwritten, and / or otherwise modified after it is stored. Thus, RTI 210 is an inherently trusted default configuration for hardware component 300 of PLD 100, as discussed.

[0057] In operation 420 , metadata 220 used by the RTI 210 is stored in non-volatile memory 103 , for example, by a manufacturer or other inherently trusted party using similar hardware as discussed with respect to operation 410 .

[0058] In operation 430, the RTIE 290 is stored in the non-volatile memory 103. In some embodiments, the original default RTIE 290 may be stored, for example, by a manufacturer or other inherently trusted party using similar hardware as discussed with respect to operation 410. In some embodiments, an updated RTIE 290 may be stored in the non-volatile memory 103 as discussed further herein.

[0059] In some embodiments, Figure 4 Operation 430 may not be performed during the initial population process of PLD 100. For example, in some cases, PLD 100 may be deployed without a security protocol (e.g., depending on customer needs), and RTIE 290 may be populated at a later time (e.g., using the security protocols described herein). Figure 8 The process of updating RTIE 290 is discussed further).

[0060] In operation 440, as described with respect to Figure 5 The process further discussed herein generates one or more of the customer configuration bitstream 240 / 260 and / or the customer metadata 230 / 250.

[0061] In operation 450, the trusted device 105 verifies (e.g., parses) the customer configuration bitstream 240 / 260 generated in operation 440 to confirm that the trusted security block 310 is included. In some embodiments, the trusted device 105 may decrypt the customer configuration bitstream 240 / 260 with a security key (e.g., a cryptographic key) to identify such confirmation. If the trusted security block 310 is included in the customer configuration bitstream 240 / 260, then Figure 4 The process continues to block 460, where the customer configuration bitstream 240 / 260 is stored in the non-volatile memory 103, and continues to operation 470, where the customer metadata 230 / 250 is stored in the non-volatile memory 103. If the trusted security block 310 is not included in the customer configuration bitstream 240 / 260, then Figure 4 The process continues to operation 480 , where no customer configuration 240 / 260 or customer metadata 230 / 250 is stored in the non-volatile memory 103 .

[0062] In some embodiments, Figure 4 The process may include additional operations to store metadata 270 and user memory 280 information, as appropriate.

[0063] It is important to understand that after completing Figure 4 After the process of RTI 210, non-volatile memory 103 will be populated with RTI 210, and may optionally be further populated with RTIE 290, customer configuration bitstream 240, metadata 230, customer configuration bitstream 260, and / or metadata 250, as discussed. Thus, non-volatile memory 103 will be ready to be deployed with PLD 100 into a desired application. In addition, one or more of RTIE 290, customer configuration bitstream 240, metadata 230, customer configuration bitstream 260, and / or metadata 250 may be updated in the field after deployment, as discussed herein.

[0064] Figure 5 1 illustrates a process for generating a customer configuration bitstream 240 / 260 for a PLD 100 according to an embodiment of the present disclosure. As discussed, Figure 5 The process can be Figure 4 is performed during operation 440. For example, Figure 5 The process may be performed by system 130 running a PLD configuration application such as the Lattice Radiant software discussed above. In some embodiments, Figure 5 The various files and information referenced in may be stored in one or more databases and / or other data structures, for example, in memory 134, machine-readable media 136, non-volatile storage 103, and / or elsewhere.

[0065] In operation 510, system 130 receives a design (e.g., a customer design) that specifies desired functionality for PLD 100. For example, a user (e.g., a customer) 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 design (e.g., operations performed by PLD 100 when configured and / or other features). In some embodiments, the 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 design describes a valid configuration for PLD 100. For example, system 130 may reject invalid configurations and / or request that the user provide new design information, as appropriate.

[0066] In operation 520, the system 130 adds the trusted security block 310 to the design to provide this feature to the end customer configuration bitstream in question.

[0067] In operation 530, system 130 synthesizes the design to convert the design (including the customer design and trusted security block 310) into a plurality of synthesized components (e.g., logical constructs representing operations performed by the design). For example, operation 530 may include converting the design into a netlist (e.g., a synthesized RTL description) that identifies the implementation of the design as a plurality of synthesized components (e.g., also referred to as logic components or netlist components). In this regard, the synthesized components may identify logic, hardware functions, and / or other design features that may subsequently be mapped to various types of hardware components provided by PLD 100 as discussed herein in operation 540. In some embodiments, the netlist may be stored in a unified database (UDB) file in Verilog format and / or in a native general database (NGD) file in an electronic design interchange format (EDIF).

[0068] In some embodiments, operation 530 may include performing an optimization process on the design to reduce propagation delays, consumption of PLD resources and interconnects, and / or otherwise optimize the performance of PLD 100 when configured with the design. For example, an optimization process may be performed on a netlist representing a synthesized design to provide an improved netlist representing an improved synthesized design.

[0069] In operation 540 , system 130 performs a mapping process that identifies various types of hardware components of PLD 100 that may be used to implement the composite components identified in operation 530 .

[0070] In operation 550, system 130 performs a placement process to assign the types of hardware components mapped in operation 540 to actual physical hardware components 300 residing at specific physical locations of PLD 100, thereby determining the layout of PLD 100. In some embodiments, placement may be performed on one or more previously stored UDB and / or NGD files, with the placement results stored as another physical design file.

[0071] In operation 560, system 130 performs a routing process to route connections between physical hardware components 300 of PLD 100 based on the placement layout determined in operation 550 (e.g., using routing resources 180) to achieve physical interconnections between the placed components. In some embodiments, routing may be performed on one or more previously stored UDB and / or NGD files, with the routing results stored as another physical design file. Thus, after operation 560, one or more physical design files may be provided that specify the design after synthesis (e.g., conversion and optimization), mapping, placement, and routing (e.g., by combining the results of corresponding previous operations) for PLD 100.

[0072] In operation 570 , system 130 generates a customer configuration bitstream 240 / 260 for the synthesized, mapped, placed, and routed design. For example, the generated customer configuration bitstream 240 / 260 may be a configuration bitstream compatible to be stored in non-volatile memory 103 and configure hardware component 300 .

[0073] In operation 580, the system 130 generates additional information in the form of a manifest that is added to the customer configuration bitstream 240 / 260 to identify that the trusted security block 310 has been included in the customer configuration bitstream 240 / 260.

[0074] Figure 6 The process of operating PLD 100 according to an embodiment of the present disclosure is illustrated. In operation 610, PLD 100 begins operation, such as in response to a cold start (e.g., power-on reset) and / or an appropriate trigger (e.g., a signal and / or command received from an external source and / or from a previous operation of PLD 100).

[0075] In operation 615, PLD 100 reads RTI 210 from nonvolatile memory 103 and configures hardware component 300 according to the default operation of RTI 210. For example, portion 302 may be configured with trusted security block 310 included in RTI 210, and portion 304 may be configured with the rest of RTI 210.

[0076] In operation 620, PLD 100 determines whether hardware component 300 should be further configured with RTIE 290. For example, PLD 100 may determine whether RTIE 290 is present in non-volatile memory 103 and / or may read metadata 220 to make such a determination. If so, then Figure 6 The process continues to operation 625, where PLD 100 further configures portion 304 of hardware component 300 with RTIE 290 (e.g., portion 304 of hardware component 300 may be configured with both RTI 210 and RTIE 290). If not, portion 304 of hardware component 300 is still configured only with RTI 210, and Figure 6 The process continues to operation 630 .

[0077] In operation 630, PLD 100 determines whether the selected one of customer configuration bitstreams 240 / 260 should be used to replace RTI 210 to reconfigure hardware component 300. For example, PLD 100 may determine whether the selected customer configuration bitstream 240 / 260 is present in non-volatile memory 103. If so, then Figure 6 The process continues to operation 635. If not, then Figure 6 The process returns to operation 615.

[0078] In operation 635, PLD 100 reads metadata 230 / 250 to determine whether the particular one of the customer configuration bitstreams 240 / 260 selected in operation 630 has been previously authenticated, e.g., as Figure 7 The result of the previous execution of the process. If not, then Figure 6 The process continues to operation 640. If yes, then Figure 6 The process continues to operation 650 .

[0079] In operation 640, PLD 100 executes Figure 7 645, if the authentication is successful, then Figure 6 The process continues to operation 650. If the authentication is unsuccessful, then Figure 6 The process returns to operation 615.

[0080] In operation 650, PLD 100 reconfigures hardware component 300 with customer configuration bitstream 240 / 260. In this regard, portion 302 is reconfigured with trusted security block 310 included with selected customer configuration bitstream 240 / 260 (e.g., a previous trusted security block 310 provided by RTI 210 or another previously loaded configuration bitstream is replaced with trusted security block 310 included with customer configuration bitstream 240 / 260). Additionally, portion 304 is reconfigured with operation of selected customer configuration bitstream 240 / 260 (e.g., a previous configuration provided by RTI 210 or another earlier configuration bitstream is replaced in portion 304 with customer configuration bitstream 240 / 260; if previously so configured in operation 625, portion 304 will continue to include RTIE 290).

[0081] In operation 655 , PLD 100 operates hardware component 300 according to the reconfiguration of customer configuration bitstream 240 / 260 and / or the previous configuration of RTIE 290 .

[0082] In operation 660, if a trigger event (e.g., a signal, a command, and / or other trigger) is received to reconfigure the hardware component 300 (e.g., to reconfigure the hardware component 300 with the customer configuration bitstream 240 / 260) by loading or replacing the current configuration bitstream with a new customer configuration bitstream, then Figure 6The process returns to operation 630 and operations 630 to 655 are repeated for the new or replacement customer configuration bitstream (e.g., if hardware component 300 was previously configured with customer configuration bitstream 240, it may be reconfigured with customer configuration bitstream 260, or vice versa). If no such triggering event is received, then Figure 6 The process continues to operation 665.

[0083] In operation 665, if a triggering event (e.g., a signal, command, and / or other trigger) is received to update the RTIE 290, then Figure 6 The process continues to operation 670. If no such triggering event is received, then Figure 6 The process returns to operation 655.

[0084] In operation 670, PLD 100 executes Figure 8 The process for updating RTIE 290 is discussed further herein.

[0085] In operation 675, if the update of RTIE 290 is successful, then Figure 6 The process continues to operation 680. If the update of RTIE 290 is unsuccessful, then Figure 6 The process returns to operation 655.

[0086] In operation 680, PLD 100 updates metadata 230 / 250 to identify that customer configuration bitstream 240 / 260 is not authenticated. In this regard, although one or both of customer configuration bitstreams 240 / 260 may have been previously authenticated during a previous iteration of operation 640, operation 680 ensures that they will be re-authenticated prior to use after RTIE 290 is successfully updated. In this regard, if the security protocol provided by RTIE 290 has been updated, then any previously authenticated customer configuration bitstream 240 / 260 may not be encrypted with and / or otherwise compatible with the updated security protocol provided by RTIE 290. Updating metadata 230 / 250 in this manner ensures that re-authentication is performed prior to PLD 100 being reconfigured with customer configuration bitstream 240 / 260.

[0087] Figure 7 6 illustrates a process for authenticating one of the customer configuration bitstreams 240 / 260 selected in operation 630 (e.g., any one of the possible reconfigurations currently being considered for hardware component 300), in accordance with an embodiment of the present disclosure. As discussed, Figure 7 The process can be Figure 6 is performed during operation 640 .

[0088] In operation 710 , PLD 100 reads customer configuration bitstream 240 / 260 from nonvolatile memory 103 .

[0089] In operation 720, PLD 100 determines Figure 7 Whether the authentication process has been canceled (e.g., in response to a signal, command, and / or other trigger). If so, then Figure 7 The process continues to operation 780, where the client configuration bitstream 240 / 260 is not authenticated and the associated metadata 230 / 250 remains unchanged. Figure 7 The process continues to operation 730 .

[0090] In operation 730, PLD 100 determines whether customer configuration bitstream 240 / 260 includes trusted security block 310. For example, in some embodiments, PLD 100 may parse configuration bitstream 240 / 260 to determine whether it includes a manifest previously added by system 130 in previous operation 580. In some embodiments, PLD 100 may parse configuration bitstream 240 / 260 to detect the presence of trusted security block 310 in the bitstream itself. If trusted security block 310 is detected, then Figure 7 The process continues to operation 740. Otherwise, Figure 7 The process continues to operation 780.

[0091] In operation 740, PLD 100 determines whether the detected trusted security block 310 includes minimum security features. For example, in some embodiments, this may include restricting portion 304 of hardware component 300 from directly accessing non-volatile memory 103, as previously discussed and Figure 3 In other embodiments, the entire trusted security block 310 may be checked to determine if all expected features of the trusted security block 310 are present. If operation 740 is satisfied, then Figure 7 The process continues to operation 750. If not, then Figure 7 The process continues to operation 780.

[0092] In operation 750, PLD 100 determines whether customer configuration bitstream 240 / 260 is signed by a security key (e.g., provided by trusted device 105 in operation 450). If so, then Figure 7 The process continues to operation 760. If not, then Figure 7 The process continues to operation 780.

[0093] In operation 760, due to the successful completion of operations 730, 740 and 750, it is confirmed that the customer configuration bit stream 240 / 260 has been authenticated. In some embodiments, this confirmation may be in the form of a Figure 7More or fewer authentication operations identified in are conditions.

[0094] In operation 770, PLD 100 updates metadata 230 / 250 to identify that the selected customer configuration bitstream 240 / 260 has been authenticated.

[0095] Figure 8 FIG. 1 illustrates a process for updating the security protocol of PLD 100 according to an embodiment of the present disclosure. As discussed, Figure 8 The process can be Figure 6 is performed during operation 670 .

[0096] In operation 810, PLD 100 receives an updated RTIE 290. For example, updated RTIE 290 may be provided by a manufacturer, a customer, and / or other trusted through system 130 via connection 140, any of the various I / O blocks 102 of PLD 100, and / or other appropriate techniques. As discussed, updated RTIE 290 may include updated security protocols to replace default security protocols included in the current RTIE 290 stored in non-volatile memory.

[0097] In operation 820, PLD 100 authenticates the updated RTIE 290. For example, in some embodiments, PLD 100 may Figure 7 The process is applied to the updated RTIE 290 to detect the presence of the trusted security block 310, the presence of minimum security features, the signing of security keys, and / or any other desired authentication techniques.

[0098] In operation 830, if the authentication is successful, then Figure 8 The process continues to operation 840, where PLD 100 stores the updated RTIE 290 in non-volatile memory 103 to replace the current RTIE 290. If the authentication is unsuccessful, then Figure 8 The process continues to operation 860, where the current RTIE 290 is not updated (e.g., not replaced by the updated RTIE 290 in non-volatile memory 103). Therefore, it is understood that PLD 100 can subsequently be reconfigured with the updated RTIE 290 without requiring further authentication upon such reconfiguration.

[0099] Where applicable, the various embodiments provided by the present disclosure may be implemented using hardware, software, or a combination of hardware and software. Moreover, 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, and / or both, without departing from the spirit of the present disclosure. In addition, where applicable, it is envisioned that software components may be implemented as hardware components, and vice versa.

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

[0101] 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 method comprising: configuring hardware components of a programmable logic device (PLD) with an inherently trusted set of default operations, the default set of operations being immutably stored in a non-volatile memory and comprising a first root of trust for the PLD; authenticating, by said hardware component configured with said default set of operations, a customer configuration bitstream including an updated set of operations; as well as If the authentication is successful, the hardware component is reconfigured to replace the default set of operations with the updated set of operations, wherein the updated set of operations includes a second root of trust for the PLD.

2. The method according to claim 1, wherein the authentication comprises: Verifying that the customer configuration bitstream includes a trusted security block.

3. The method according to claim 2, wherein: The verifying includes determining that the customer configuration bitstream restricts access to the non-volatile memory by the hardware component.

4. The method of claim 1, wherein the authentication comprises: reading metadata associated with the client configuration bitstream; as well as Confirming that the metadata identifies that the client configuration bitstream has been previously authenticated.

5. The method according to claim 1, wherein: The customer configuration bitstream is a first customer configuration bitstream and the set of update operations is a first set of update operations; and The method further comprises: authenticating, by the hardware component configured with the first set of update operations, a second customer configuration bitstream comprising a second set of update operations; and The hardware component is reconfigured with the second set of update operations to replace the first set of update operations in the hardware component, wherein the second set of update operations includes a third root of trust for the PLD.

6. The method according to claim 1, further comprising: further configuring the hardware component with an inherently trusted set of default security protocols stored in the non-volatile memory; authenticating, by the hardware component configured with the default set of operations, an updated set of security protocols for the PLD; as well as If the authentication of the updated security protocol set is successful: replacing the default security protocol set with the updated security protocol set in the non-volatile memory, and The client configuration bitstream is identified as unauthenticated.

7. The method according to claim 6, further comprising: reconfiguring the hardware component using the default set of operations; further configuring the hardware component with the updated security protocol set; as well as The customer configuration bitstream is re-authenticated by the hardware component reconfigured with the default set of operations.

8. The method according to claim 6, wherein: The default operation set and the default security protocol set are provided by a predetermined inherently trusted party; and The default security protocol set and the updated security protocol set include an encryption process.

9. A PLD comprising a field programmable gate array (FPGA) operable to perform the method of claim 1.

10. A method comprising: configuring hardware components of a programmable logic device (PLD) with an inherently trusted set of default operations, the default set of operations being immutably stored in a non-volatile memory and comprising a first root of trust for the PLD; further configuring the hardware component with an inherently trusted set of default security protocols stored in the non-volatile memory; authenticating, by the hardware component configured with the default set of operations, an updated set of security protocols for the PLD; as well as If the authentication of the updated security protocol set is successful, the default security protocol set is replaced with the updated security protocol set in the non-volatile memory.

11. The method according to claim 10, further comprising: If the authentication of the update security protocol set is successful, the customer configuration bitstream including the update operation set is identified as unauthenticated.

12. The method according to claim 10, further comprising: authenticating, by said hardware component configured with said default set of operations, a customer configuration bitstream including an updated set of operations; as well as If the authentication of the customer configuration bitstream is successful, then reconfiguring the hardware component to replace the default set of operations with the updated set of operations, wherein the updated set of operations includes a second root of trust for the PLD.

13. The method of claim 12, wherein said authenticating said customer configuration bitstream comprises: Verifying that the customer configuration bitstream includes a trusted security block.

14. The method according to claim 13, wherein: The verifying includes determining that the customer configuration bitstream restricts access to the non-volatile memory by the hardware component.

15. The method of claim 12, wherein said authenticating said customer configuration bitstream comprises: reading metadata associated with the client configuration bitstream; as well as Confirming that the metadata identifies that the client configuration bitstream has been previously authenticated.

16. The method of claim 12, wherein: The customer configuration bitstream is a first customer configuration bitstream and the set of update operations is a first set of update operations; and The method further comprises: authenticating, by the hardware component configured with the first set of update operations, a second customer configuration bitstream comprising a second set of update operations; and The hardware component is reconfigured with the second set of update operations to replace the first set of update operations in the hardware component, wherein the second set of update operations includes a third root of trust for the PLD.

17. The method of claim 10, wherein: The default operation set and the default security protocol set are provided by a predetermined inherently trusted party; and The default security protocol set and the updated security protocol set include an encryption process.

18. A PLD comprising a field programmable gate array (FPGA) operable to perform the method of claim 10.

19. A method comprising: Receive designs of programmable logic devices (PLDs); adding a trusted security block to the design; as well as Generate a customer configuration bitstream according to the design, the customer configuration bitstream is used to configure the hardware components of the PLD, wherein the customer configuration bitstream includes: updating an operation set for replacing an inherently trusted default operation set, the default operation set being immutably stored in non-volatile memory and comprising a first root of trust for the PLD, and The trusted security block is used to authenticate the customer configuration bit stream.

20. The method of claim 19, wherein: The receiving, the adding, and the generating are performed by a first device different from the PLD; and The method also includes verifying, by a second device different from the first device and the PLD, that the customer configuration bitstream includes the trusted security block.

Images