FPGA and microarchitecture attacks

Abstract

A hardware security module including a field programmable gate array (FPGA) is presented. In use, the FPGA is configured to provide a soft core processor for executing program code. This enables the configuration of the soft core processor to be altered over the life cycle of the HSM based on instructions received by the FPGA. In addition, the FPGA is used such that different configurations can be provided when the HSM is used by different corresponding users (tenants). In addition, the use of the FPGA enables different instances of the HSM to have different configurations more cheaply.

Description

Technical Field

[0001] This invention relates to a cryptographic device. Background Technology

[0002] Various devices can be used to execute cryptographic algorithms. A hardware security module (HSM) is a system that securely stores and manages cryptographic keys and executes a set of cryptographic algorithms. An example hardware security module (HSM) includes a central processing unit (CPU) configured to execute computer code that implements the functions of the HSM, such as generating, storing, and managing cryptographic keys.

[0003] Commercial off-the-shelf (COTS) processors are processors that have already been designed and manufactured by third-party vendors. Using COTS processors can accelerate development and is more cost-effective compared to custom processors designed specifically for the task at hand. Example vendors of COTS processors include Intel®, AMD®, and ARM®.

[0004] Processors typically implement a microarchitecture, which includes the digital logic used to execute instructions. The microarchitecture also defines how the instructions in the processor's instruction set are implemented.

[0005] Microarchitectural attacks refer to attacks that exploit vulnerabilities in the processor's microarchitecture to compromise the security of a computing environment. Examples of microarchitectural attacks include "Meltdown" and "Spectre" attacks. In both cases, malicious actors gain access to information that would otherwise be unavailable by exploiting routines implemented by the processor (e.g., in the case of a "Spectre" attack—by exploiting speculative execution mechanisms used by modern processors to improve performance).

[0006] For Hardware Security Modules (HSMs), information that would otherwise be unavailable might be the user's cryptographic keys used to protect their information. Therefore, microarchitectural attacks can create serious vulnerabilities in the security of HSMs.

[0007] Commercial off-the-shelf (COTS) processors are typically manufactured at large scale using standard microarchitectures. Therefore, malicious third parties can identify known microarchitectural vulnerabilities in a given processor using the processor's knowledge, and attempt to exploit these vulnerabilities to obtain secret information.

[0008] Furthermore, commercial off-the-shelf (COTS) processors are typically manufactured in silicon (i.e., their design is fixed at manufacturing and cannot be changed). Therefore, if a microarchitectural attack is identified and the vulnerability cannot be patched with a software patch, the processor (and thus the security of the Hardware Security Module (HSM)) may be compromised for the remainder of the HSM's lifespan, potentially causing the HSM to cease service prematurely. Summary of the Invention

[0009] Generally, this invention proposes a hardware security module including a Field-Programmable Gate Array (FPGA). In use, the FPGA is configured to provide a control processor (e.g., a hard-core processor) and a soft-core processor for executing program code. The control processor is configured to receive a continuous sequence of program instructions that define consecutive corresponding data processing operations. The control processor implements each operation, or, if it determines that an operation is one of a set of restricted operations, sends a request to the soft-core processor to execute that restricted operation. The soft-core processor is configured based on instructions received from the FPGA. This allows the configuration of the soft-core processor to be changed based on instructions received from the FPGA throughout the lifetime of the HSM.

[0010] For example, if a vulnerability is identified in the current configuration of the FPGA, the configuration can be changed to eliminate the vulnerability. Furthermore, even if a specific vulnerability has not yet been identified, the FPGA configuration can be changed periodically to protect against vulnerabilities in the current configuration that may have been identified by malicious third parties but have not yet been noticed by the HSM owner / provider.

[0011] Furthermore, using an FPGA allows a given instance of an HSM to have different configurations for each of multiple users (tenants). That is, different tenants can be associated with different corresponding soft-core configurations, and a particular tenant uses a soft processor with the configuration associated with that tenant. The fact that the soft-core configuration changes from one user to another means that if a malicious third party discovers a vulnerability in the configuration associated with one user, that vulnerability is unlikely to exist in the soft-core configurations associated with other users.

[0012] Furthermore, using FPGAs makes it cheaper to have different configurations for different instances of an HSM. Even if the configuration of each given HSM does not change over time, the fact that it varies from one instance of an HSM to another means that if a malicious third party discovers a vulnerability in a certain configuration, that vulnerability is unlikely to exist in other instances of the HSM. Attached Figure Description

[0013] The apparatus and method according to a non-limiting embodiment will now be described with reference to the accompanying drawings, in which:

[0014] Figure 1 A hardware security module (HSM) is shown according to an example.

[0015] Figure 2 The method implemented by the Hardware Security Module (HSM) according to the example is shown;

[0016] Figure 3 The alternative hardware security module (HSM) is shown.

[0017] Figure 4 It shows according to Figure 3 Implementation of Field Programmable Gate Array (FPGA);

[0018] Figure 5A It shows according to Figure 3 A second implementation of a field-programmable gate array (FPGA);

[0019] Figure 5B It shows according to Figure 3 Functional block diagram of the functions implemented by FPGA;

[0020] Figure 6A A logic diagram of an FPGA in an HSM according to a first example embodiment is shown;

[0021] Figure 6B A method for eliminating security vulnerabilities in an HSM according to a first example embodiment is shown;

[0022] Figure 7A A logic diagram of an FPGA in an HSM according to a second example embodiment is shown;

[0023] Figure 7B The method executed by FPGA 700 in HSM according to the second example embodiment is shown;

[0024] Figure 8A A logic diagram of an FPGA in a multi-tenant HSM according to a third example embodiment is shown; and

[0025] Figure 8B The layout of components in the FPGA of a multi-tenant HSM according to the third example embodiment is illustrated schematically.

[0026] Throughout the accompanying drawings, the same reference numerals are used to refer to the same components or functions. Detailed Implementation

[0027] A hardware security module (HSM) is a device that securely stores and manages cryptographic keys and executes a set of cryptographic algorithms. Example cryptographic operations include, but are not limited to: generating cryptographic keys, securely storing cryptographic keys, and using cryptographic keys to perform functions such as encryption or digital signatures.

[0028] Figure 1 This is a schematic illustration showing a plan view of a Hardware Security Module (HSM) device according to an example. Figure 1A hardware security module (HSM) comprising multiple discrete interconnected hardware components is shown. Each component (discussed in more detail below) resides on a surface of a printed circuit board (PCB) 200. Components may all be located on the same surface of the PCB, although in principle different components may be located on different surfaces. The PCB 200 includes conductive connections 210 (also referred to as traces) for communicatively coupling the components to each other. Conductive connections 210 may be located on any one or both main surfaces of the PCB, and / or within a structure, wherein conductive connections transverse to the main surfaces of the PCB are provided by vias.

[0029] The Hardware Security Module (HSM) includes an Input / Output (I / O) connector 201. The I / O connector 201 is communicatively coupled to a processor 202 located on a PCB 200 and is configured to act as an interface for transferring data between the processor 202 and an external system. The Hardware Security Module (HSM) is configured to be communicatively coupled to a computer or server device in an external system via the I / O connector 201. For example, the Hardware Security Module (HSM) may be a PCIe Quick Card, which can be directly inserted into a computer or server device. In this case, the I / O connector may be a PCIe connector. In use, the Hardware Security Module (HSM) receives user requests through the I / O connector 201. Requests may include commands for performing specific cryptographic operations.

[0030] Input / output (I / O) connector 201 is communicatively coupled to processor 202 via one of conductive connections 210. Processor 202 is a central processing unit (CPU) and is configured to perform basic arithmetic, logic, control, and input / output (I / O) operations specified by instructions in computer program code. An example of processor 202 is the NXP T1042 processor. The internal structure of processor 202 is fixed, meaning that the internal circuitry of the processor used to perform various operations is fixed and cannot be changed after processor 202 is manufactured. In other words, the internal structure (i.e., hardware) of processor 202 is not configurable.

[0031] The hardware security module (HSM) also includes non-volatile memory 208 and volatile working memory, which includes random access memory (RAM) 209. Non-volatile memory 208 can include any form of non-volatile device memory. In this example, non-volatile memory 208 includes flash memory and electrically erasable read-only memory (EEROM). RAM 209 can be DDR RAM. Processor 202 communicates with both non-volatile memory 208 and RAM 209 via a wired bidirectional connection.

[0032] Computer program code is stored in non-volatile memory 208. When executed, the program is represented as a software product or process in working memory. Processor 202 includes logic circuitry that responds to and processes instructions in the program code present in working memory. The following description refers to an "application," which is program code comprising a set of computer instructions. An application includes machine code stored in non-volatile memory 208 on the HSM. Non-volatile memory 208 on the HSM also stores any components required to execute the application, including runtime system files. When executed, a copy of the application machine code is loaded into working memory. An "application process" is an instance of an application being executed, comprising the machine code in working memory. Optionally, at least a portion of non-volatile memory 208 may be provided in the form of a smart card coupled to processor 202 via a smart card reader (not shown) mounted on a PCB. In this case, non-volatile memory 208 may include a combination of a smart card reader and a smart card.

[0033] The application includes computer instructions embodying a set of one or more cryptographic algorithms. For example, the application includes computer instructions embodying one or more of the following cryptographic algorithms: cryptographic key generation; key derivation; encryption; decryption; and cryptographic digital signature algorithms (e.g., digital signatures or verification of digital signatures). The application may be embedded in the non-volatile memory 208 of the hardware security module (HSM) during manufacturing by the trusted party, or it may be provided by the trusted party, wholly or partially, after manufacturing. For example, the application may be introduced by the trusted party as a computer program product, which may be done through download. Alternatively, the trusted party may modify an existing application through updates or plugins. Execution of the application by the processor 202 results in the implementation of various functions of the hardware security module (HSM), such as generating cryptographic keys, storing cryptographic keys, or performing cryptographic operations.

[0034] The processor 202 runs a board support package. This can be a "bare metal" system, but alternatively, the processor 202 can optionally run an operating system, such as Linux. The board support package or operating system includes system software that manages the hardware and software resources of the HSM device and acts as an intermediary between applications and the HSM hardware.

[0035] One or more cryptographic application keys are associated with a client for use with cryptographic algorithms embodied in the application. The application keys can be securely stored externally to the HSM device and encrypted using a master key. The master key can also be used with processor 202, for example, stored within non-volatile memory 208 and / or a secure processor (SP) 206 (described in more detail below). For example, the application keys can be encrypted using AES (Advanced Encryption Standard) encryption with the master key. The encrypted application keys can then be sent to a separate external device for storage. When in use, the encrypted application keys can be sent to the HSM, which decrypts them using the master key and then uses the application keys to execute the cryptographic algorithm.

[0036] An example of material storage for deriving the master key will now be described between the main processor 202 and the security processor 206. In this example, the master key is derived from two keys (referred to as MK1 and MK2) using a key export function. When data decryption is required, the master key is exported from MK1 and MK2 on processor 202.

[0037] MK2 is stored in encrypted form in security processor 206 and decrypted and provided to processor 202 upon request. MK2 is stored on security processor 206 and encrypted using a key, which can be an AES 256-bit key, referred to as SP-SEK (Security Processor Stored Encryption Key). The stored encryption key SP-SEK is used by security processor 206 to protect sensitive data. Sensitive data (including MK2) is stored on security processor 206 and encrypted using SP-SEK. SP-SEK is generated from a hardware random number generation component on security processor 206. If tampering is detected at security processor 206, security processor 206 immediately performs a hardware erase of SP-SEK.

[0038] MK1 is stored in encrypted form on processor 202. Processor 202 stores a key, which can be a 256-bit AES key, referred to as MP-SEK (Master Processor Stored Encryption Key). The MP-SEK is used by processor 202 to protect sensitive data. Sensitive data (including MK1) is stored on processor 202 and encrypted using MP-SEK. MP-SEK is generated from a hardware random number generation component on processor 202. If tampering is detected at master processor 202, master processor 206 immediately performs a hardware erase of MP-SEK.

[0039] The MK1 and MK2 keys are used to derive the master key, which is used to encrypt user data, such as application keys stored elsewhere. The master key is derived using a key export function with MK1 and MK2 as input. Once the user data has been encrypted, the master key is deleted. To decrypt the user data, the master key needs to be re-derived at processor 202. This involves: security processor 206 decrypting MK2 and sending it to processor 202, which then decrypts MK1. If tampering is detected at security processor 206, the SP-SEK is erased from security processor 206 to prevent the SP-SEK key from being used. This, in turn, prevents MK2 from being decrypted, thus preventing the master key from being exported. Similarly, in response to a tampering event, the MP-SEK key is erased at processor 202 to prevent the MP-SEK from being used, and thus prevents MK1 from being decrypted, which in turn prevents the master key from being exported.

[0040] The HSM device also includes a cryptographic coprocessor 204. The cryptographic coprocessor 204 performs various cryptographic functions in hardware to accelerate cryptographic operations, such as various standard encryption and decryption algorithms and digital signature algorithms. For example, the cryptographic coprocessor 204 is configured to provide mathematical acceleration to support cryptographic operations. The cryptographic coprocessor 204 includes an application-specific integrated circuit (ASIC). The ASIC includes fixed logic circuitry configured to perform standard operations. In other words, in the cryptographic coprocessor 204, one or more operations are implemented directly in hardware (programmable logic, not software). Examples of such devices include the NXPC291 cryptographic coprocessor, the NXP C292 cryptographic coprocessor, and the MaxLinear 9240 data compression and security coprocessor. In the example, the cryptographic coprocessor 204 is implemented in a self-contained package, optionally as a flip-chip-plastic ball grid array (FC-PBGA).

[0041] The cryptographic coprocessor 204 is configured to receive requests from the CPU 202 to perform one or more operations and to return the output of the operations to the CPU 202. The CPU 202 is configured to offload various operations to the cryptographic coprocessor 204. The cryptographic coprocessor 204 is decoupled from the CPU 202 and is configured to perform certain operations in hardware, meaning that these operations can be performed more efficiently on the cryptographic coprocessor 204 than on the CPU 202. Operations can be performed concurrently on the cryptographic coprocessor 204 and on the CPU 202.

[0042] exist Figure 1In the illustrated device, CPU 202 runs an application that invokes the module "cryptographic device driver," which provides access to the kernel cryptographic driver, thereby allowing the application to utilize cryptographic coprocessor 204. Cryptographic coprocessor 204 has a fixed implementation (in other words, a hardware implementation) of one or more cryptographic operations. RAM 209 stores the working data used in these operations, including the keys.

[0043] The Hardware Security Module (HSM) also includes a power / reset component 203 configured to provide power to all active components on the printed circuit board (PCB) 200, including processor 202 and cryptographic coprocessor 204. The power / reset component 203 may, for example, be coupled to an input / output connector 201, such that power is provided to all active components on the PCB 200, including processor 202 and cryptographic coprocessor 204, via the input / output connector 201. For example, it may be connected via a PCIe (Peripheral Component Interconnect Fast) line.

[0044] The hardware security module (HSM) also includes a random number generator (RNG) component 205 mounted on the PCB. The hardware security module may also include a power supply (battery cell; not shown) mounted on the PCB.

[0045] As described above, the Hardware Security Module (HSM) also includes a security processor 206. The security processor 206 is configured to communicate with a plurality of onboard sensors 207. The sensors 207 are configured to monitor physical / environmental properties that can indicate an attack on the HSM. The sensors may include, but are not limited to, processor and / or board temperature sensors, or voltage and / or current sensors. The security processor 206 is configured to determine when the Hardware Security Module (HSM) has been tampered with. For example, the security processor 206 may be configured to detect a cold-start attack based on readings obtained from the temperature sensors. Furthermore, the security processor 206 may be configured to detect a fault attack based on readings from the voltage and / or current sensors. Optionally, the Hardware Security Module (HSM) is enclosed within a container with an inlet cap. In this case, the sensor 207 may include a tamper detection switch, and the security processor 206 is configured to determine when to remove the cap based on the state of the tamper detection switch. Optionally, the sensor 207 may also be used to monitor the state of the HSM, for example, to detect whether one of the components (e.g., CPU 202) is overheating.

[0046] In use, the security processor 206 is configured to communicate with the processor 202. The security processor 206 provides information indicating whether the security of the hardware security module (HSM) has been compromised.

[0047] In the example, processor 202 is configured to determine whether the security of the Hardware Security Module (HSM) has been compromised during HSM initialization. Upon receiving an indication from security processor 206 that the HSM has been compromised, processor 202 is configured to start in an error state indicating an alarm, instead of performing normal boot operations, thereby preventing the full functionality of the HSM from being implemented. Upon receiving an indication from security processor 206 that the HSM has not been compromised, processor 202 is configured to continue booting (e.g., normal boot operations), thereby making the functionality of the HSM available for use.

[0048] Figure 2 The method implemented by a hardware security module (HSM) according to an example is shown. In step 301, the HSM receives instructions to perform cryptographic operations, for example via an input / output (I / O) connector 201.

[0049] The instruction is sent to processor 202, which, in response, performs one or more cryptographic operations in step 302. The process involves multiple steps, which involve... Figure 1 Some or all of the components shown. For example, processor 202 may utilize RAM 209 (and optionally, internal RAM of processor 202, such as CPU cache) and cryptographic processor 204 to execute program instructions stored in non-volatile memory 208. This may include decrypting an encrypted cryptographic key stored in non-volatile memory 208 using one or more master keys (which may be generated by processor 202 after step 301 or stored in an HSM (e.g., security processor 206)). The cryptographic key may be associated with a user and used to execute an application stored in non-volatile memory 208. Once the cryptographic key is decrypted, processor 202 may store the cryptographic key and then use it to perform cryptographic operations. For example, cryptographic operations may be performed on data received via input / output connector 201 during step 301 or while step 302 is being executed.

[0050] Once these cryptographic operations are completed, the results of the cryptographic operations can be output from the HSM, for example, via the input / output (IO) connector 201.

[0051] Figure 2 The process may be vulnerable to microarchitectural attacks, a type of side-channel attack. Side-channel attacks exploit the idea that computations performed by a processor often leave observable side effects beyond the processor's output. For example, observable side effects such as variations in power consumption, electromagnetic noise, and acoustic noise can be used to extract secret information (e.g., encryption keys).

[0052] As discussed above, processor 202 is vulnerable to microarchitectural attacks that could allow attackers to obtain information from the Hardware Security Module (HSM) that would otherwise be unavailable. Microarchitectural attacks exploit hardware vulnerabilities in the processor to extract sensitive information. In one example, a malicious actor might exploit a vulnerability in how processor 202 executes instructions. Specifically, microarchitectural attacks could exploit vulnerabilities in cache timing, branch prediction history, and / or branch target buffers to obtain secret information.

[0053] An example of a microarchitectural attack is the "Spectre" attack. Understanding the concept of a microarchitectural attack does not require specific details of the attack itself. Therefore, only a general discussion will be provided.

[0054] Many processors use speculative execution to speed up performance when executing instructions. Essentially, speculative execution involves guessing the possible future direction of execution of a program the processor is executing and executing instructions along that path ahead of time. This can be used to accelerate program execution when the program flow depends on values ​​that are not accessible in external physical memory. Retrieving this value might take hundreds of clock cycles. Therefore, instead of idling the processor during this time, the CPU speculatively executes the predicted execution direction. If the execution direction is incorrect after retrieving the inaccessible value from memory, the CPU restores the register state to the stored checkpoint (indicating where speculative execution began in the code), resulting in no performance improvement compared to idling the processor during this period. However, if the guess is correct, the speculative execution result is committed, resulting in a significant performance gain.

[0055] During a "Spectre" attack, the processor is tricked into speculatively executing operations that would not occur during proper program execution. Spectre then exploits a vulnerability in the processor's microarchitecture where data from these operations is stored in the CPU cache (i.e., not fully erased), allowing an attacker to read the cache and gain access to sensitive information they would normally not have permission to access. In a Hardware Security Module (HSM), sensitive information could be a user's password key; therefore, this type of microarchitectural attack can introduce serious security vulnerabilities.

[0056] In the case of processor 202 being a commercial off-the-shelf (COTS) processor implemented in silicon, the processor's microarchitecture design can be fixed at manufacturing time (i.e., cannot be changed). Therefore, security vulnerabilities may exist indefinitely (i.e., throughout the entire lifespan of the Hardware Security Module (HSM) that includes processor 202). This could cause the processor and HSM to prematurely cease service, increasing power waste and cost. In the example, speculative execution could be initiated by a component in CPU 201 called the branch predictor. The branch predictor cannot be modified, therefore the associated "Spectre attack" vulnerability cannot be corrected.

[0057] Figure 3 A schematic diagram of the Hardware Security Module (HSM) is shown. As described below, as... Figure 3 The HSM shown can be operated as an embodiment of this disclosure. Figure 1 Use and Figure 1 The same reference numerals are used to denote the same components.

[0058] Figure 3 The hardware security module (HSM) includes a field-programmable gate array (FPGA) 401. This is preferably as described in the following reference. Figure 5A and Figure 5B The system-on-chip FPGA (SoC FPGA) described is possible, although it is also possible for the FPGA to be implemented as a non-SoC FPGA, as shown in the following reference. Figure 4 As described above, FPGA 401 is a single, discrete, self-contained package that implements various functions performed by processor 202 and cryptographic coprocessor 204, as per [the relevant documentation / details]. Figure 1 (Alternatively, this functionality can be provided by combining FPGA 401 with a separate non-programmable processor (not shown). FPGA 401 achieves this by interacting with non-volatile memory 208 and RAM 209. Non-volatile memory 208, RAM 209, and at least one processor are each implemented as discrete, separately packaged components.)

[0059] A System-on-a-Chip (SoC) FPGA is an integrated circuit that includes a fixed central processing unit and an array of programmable logic blocks, along with a hierarchical structure of reconfigurable interconnects that allows the blocks to be connected together to implement user-specified functions. Non-SoC FPGAs do not include a CPU. Unlike conventional central processing units, FPGAs can be configured after manufacturing. The manufacturing process defines the fixed logic present in the FPGA, including programmable logic blocks, the presence of any particular digital signal processing, or memory blocks, etc. However, the functions implemented by the FPGA are defined at a later stage when the interconnects between the various blocks are formed.

[0060] Figure 4 A schematic illustration of an example non-SoC field-programmable gate array (FPGA) is shown, which may be included in one of the examples above or in an HSM device according to one of the embodiments described below. For example, Figure 3 The FPGA 401 included in A's HSM may include, for example: Figure 4 The FPGA shown.

[0061] Figure 4An FPGA 500 is shown, which includes multiple input / output (I / O) interfaces 501 and multiple functional blocks 502, 503, and 504. In this example, these can be implemented as configurable logic blocks (CLBs) 502, multiple memory blocks 503, and multiple digital signal processing (DSP) blocks 504 connected via a wiring network 505. The wiring network 505 includes multiple vertical and horizontal channels communicatively coupled to the input / output (I / O) interfaces 501, configurable logic blocks (CLBs) 502, memory blocks 503, and digital signal processing (DSP) blocks 504, thereby forming a communication bus. Each of these blocks is connected to and can communicate through this communication bus.

[0062] The wiring network 505 also includes multiple switch blocks located at the intersections of vertical and horizontal channels. The switch blocks can be programmably routed to form connections from source to destination (e.g., one-to-one connections) or from source to multiple destinations (one-to-many connections) to form connections between different blocks of the FPGA 500. Figure 4 The FPGA architecture shown is referred to as an island architecture because it comprises a two-dimensional block array containing configurable logic blocks, memory blocks, and DSP blocks (i.e., islands) within a large number of routed interconnects. Alternatively, other FPGA architectures can be used.

[0063] The Configurable Logic Block (CLB) 502 includes a programmable lookup table (LUT) and registers. The lookup table (LUT) includes an array of data that maps input values ​​to output values.

[0064] Memory block 503 includes random access memory (RAM) used by the configurable logic of the FPGA.

[0065] The digital signal processing (DSP) block 504 includes dedicated logic circuitry (i.e., fixed circuitry) for performing digital signal processing operations.

[0066] Input / output (I / O) interface 501 includes an interface through which information can be received into FPGA 500 and sent out of FPGA 500. Optionally, each I / O interface 501 is associated with a pin of the FPGA package (i.e., a metal connection to which wiring or traces on PCB 200 (e.g., conductive connection 210) can be connected). Optionally, I / O interface 501 supports various signaling technologies, including but not limited to Low Voltage CMOS Signaling (LVCMOS), Low Voltage Differential Signaling (LVDS), and / or Short Cut Wire Serial Termination Logic (SSTL).

[0067] The process of configuring an FPGA to implement desired logic functions is called the FPGA design flow. The first step in the FPGA design flow is the design input. In this step, the user generates a description of the hardware circuitry to be implemented by the FPGA. This description can be in the form of a schematic diagram. Alternatively, and more likely for complex designs, a hardware description language (HDL) such as VHDL (Very High Speed ​​Integrated Circuit Hardware Description Language) can be used to describe the hardware circuitry.

[0068] The second step in the FPGA design flow is synthesis. During synthesis, the high-level hardware description of the circuit (which may take the form of a hardware description language) is translated into a hardware architecture (i.e., gate-level circuitry) using FPGA-specific primitives (i.e., the smallest atomic logic elements of the FPGA, such as flip-flops, multiplexers, block RAM, etc.). The output of synthesis is a netlist (also known as an unrouted netlist or a post-synthesized netlist), which includes indications of the FPGA elements used to implement the hardware circuitry and indications of the interconnections between these elements.

[0069] The third step in the FPGA design flow is placement and routing. During placement and routing, the netlist (generated in step 2) is analyzed and mapped to specific physical hardware resources in the FPGA (placement), and then the components are interconnected (routing) to form the functionality of the hardware circuitry (specified in step 1). The placement and routing steps can be subject to several constraints. For example, users can specify timing constraints to ensure that logic elements will meet timing requirements, such as synchronous circuitry being able to process data accurately at a specified clock rate. Alternatively or additionally, the location of design elements can be constrained to specific areas of the FPGA die, known as location constraints.

[0070] The output of the layout and routing is an FPGA bitstream, also known as a bit file. The FPGA bitstream includes programming information that the FPGA uses to implement hardware circuitry, that is, to implement the functions specified in step 1 using physical FPGA resources according to user constraints regarding timing / location, etc., in step 3.

[0071] FPGAs use bit files to configure all necessary areas of the FPGA to achieve the designed functionality. This includes, but is not limited to, routing between each configurable logic block, configuration of each logic block, memory contents, I / O connections, and pin configuration.

[0072] Figure 5A It shows that, depending on the variant, it can be included. Figure 3 A schematic illustration of a SoC (Field-Programmable Gate Array) in an HSM device. That is, Figure 3 The FPGA 401 included in the HSM may include, for example Figure 5AThe diagram shows a System-on-a-Chip (SoC) FPGA. An SoC FPGA integrates a processor and an FPGA architecture. An SoC FPGA is a device that includes a system-on-a-chip and programmable logic on the same device, thus combining the advanced management functions of a processor and the data processing capabilities of configurable logic into a single device.

[0073] The SOC FPGA is logically divided into the processing system 600 and the programmable logic 606.

[0074] The processing system 600 forms a system-on-a-chip (SoC) and includes an input / output (I / O) interface 601, a processor 602 (e.g., a single (e.g., quad-core) processor), on-chip read-only memory (ROM) 604, on-chip random access memory (RAM) 603, and an external memory controller 605. Additional capabilities may also be provided. The input / output (I / O) interface 601 is communicatively coupled to the processor 602. In one example, the processor 602 may be an ARM® Cortex-A53. The processor 602 is coupled to the on-chip read-only memory (ROM) 604 and the on-chip random access memory (RAM) 603. The processor 602 is also coupled to the external memory controller 605, which is configured to communicate with off-chip memory via the input / output (I / O) interface 601, including HSM non-volatile memory 208 and RAM 209.

[0075] The processing system 600 is configured to execute program instructions retrieved from memory, such as boot instructions retrieved from on-chip ROM 604 and application instructions retrieved from non-volatile memory (e.g., flash memory).

[0076] Processor 602 is configured to communicate with programmable logic 606 via an interconnect (e.g., a bus). In one example, the interconnect is an ARM AMBA® AXI-based interface. In this way, software being executed by processor 602 can interact with programmable logic 606, for example, to obtain values ​​calculated by programmable logic 606, initiate hardware operations, etc.

[0077] Programmable logic 606 includes, for example, the following: Figure 4 The configurable logic blocks (CLBs), digital signal processing (DSP) blocks, and memory blocks are described. The FPGA also includes an input / output (I / O) interface 501, which is similar to the one described above. Figure 4 This describes the I / O interface that is communicatively coupled to programmable logic 606. The bit file for programmable logic 606 (including instructions on how to configure the programmable logic to perform the desired function) can be configured in terms of... Figure 4 The method discussed is generated in the same way and stored in the non-volatile memory 208 of the HSM.

[0078] exist Figure 3 In the HSM shown, regarding Figure 1 The various functions of the described processor 202 and cryptographic coprocessor 204 are implemented by FPGA 401 in the following manner. In the example described below, FPGA 401 is, for example, about Figure 5A The SOCFPGA is described. However, alternatively, FPGA 401 may be, for example, related to... Figure 4 The FPGA described.

[0079] Such as about Figure 1 The application computer program code is stored in the non-volatile memory 208 of the HSM. The processing system 600 of the FPGA 401 is configured to execute the application, which can be loaded directly and / or via RAM 209 into the SoC RAM 603. The non-volatile memory 208 on the HSM also stores any components required for application execution, including runtime system files. When executed, a copy of the application machine code is loaded into the processing system 600. Execution of the application by the processing system 600 results in the implementation of various functions of the Hardware Security Module (HSM), such as generating cryptographic keys, storing cryptographic keys, or performing cryptographic operations.

[0080] Additionally, FPGA 401 is configured to perform various cryptographic functions in hardware using configurable logic 606, such as various standard encryption and decryption algorithms and digital signature algorithms. For example, FPGA 401 is configured to provide at least one of the following: a public-key hardware accelerator (PKSA), a random number generator, an advanced cryptographic standard accelerator (AESA), and a message digest hardware accelerator (MDHA). In FPGA 401, one or more of these operations are implemented directly in hardware.

[0081] Programmable logic 606 is configured to receive requests from processing system 600 to perform one or more of these operations, and to return the output of the operations to processing system 600. Processing system 600 is configured to offload various operations to programmable logic 606. Programmable logic 606 is configured to perform certain operations in hardware, meaning that these operations can be performed more efficiently on programmable logic 606 than on processing system 600.

[0082] Figure 5B A schematic diagram of a SOC FPGA is shown, illustrating the various functions implemented within it. An FPGA is, for example, related to... Figure 5A The SOC FPGA is described. The dashed lines indicate the logical division between the functions performed by the processing system 600 and the programmable logic 606.

[0083] As previously described, the application computer program code is stored in the non-volatile memory 208 of the HSM. When executed, a copy of the application machine code is loaded into the processing system 600, wherein the application 612 is represented as a software product or process in the working memory of the processing system 600.

[0084] When certain cryptographic operations are to be performed, application process 612 invokes cryptographic device driver module 613. The computer program code corresponding to the cryptographic device driver module is stored in the non-volatile memory 208 of the HSM and retrieved by the application. When executed, a copy of the program code is loaded into processing system 600 as a software product or process in the working memory of processing system 600. Cryptographic device driver module 613 implements a driver process that coordinates data transfers to and from the FPGA and provides an initialization process "Init" 615, which is configured to initialize other components of the HSM hardware being driven by cryptographic device driver 613, such as components implemented in programmable logic.

[0085] Driver 613 is configured to access the interface between processor 602 and programmable logic 606. Processor 602 is configured to offload various operations to programmable logic 606. Programmable logic 606 is configured to perform certain operations in hardware, meaning these operations can be performed more efficiently than on processor 602. Application process 612 invokes cryptographic device driver module 613. Driver module 613 sends a request to programmable logic 606 to perform an operation. Programmable logic 606 has hardware implementations of one or more cryptographic operations.

[0086] Board support package (BSP) process 611 (e.g., Linux BSP) also runs on processing system 600.

[0087] An optional IF (interface) component 616 is implemented in programmable logic. This IF component 616 is configured to access multiple acceleration cores ACC 617 and balance the load among the multiple acceleration cores ACC 617. Each ACC corresponds to a portion of the FPGA hardware configured to implement one or more cryptographic functions. Each core is typically identical. It can correspond to a cryptographic function implemented in hardware, such as a symmetric security algorithm.

[0088] In this example, the FPGA is as follows: Figure 5A The SOC FPGA shown. As described above, by Figure 1 The various functions performed by the processor 202 in the device are executed by the processor 602 of the SOC FPGA. Figure 1 The various functions performed by the cryptographic coprocessor in the device are executed by the programmable logic 606 of the SOC FPGA.

[0089] In use such Figure 4 In the case of implementing an FPGA as shown, by Figure 1 The functions performed by the processor 202 in the device are implemented by a soft processor (also known as a soft-core processor), which is a processor implemented using the programmable logic resources of an FPGA.

[0090] Implemented in FPGA Figure 1 The various functions of the device's cryptographic coprocessor 204 enable the HSM device to be reconfigured. For example, the FPGA can be reconfigured to implement a more secure version of the operations implemented in hardware.

[0091] The FPGA can also be configured to store the HSM's ID and output it when appropriate, which can be used for interaction between the HSM's manufacturer and owner (e.g., for troubleshooting or operational warranty purposes). Furthermore, functions performed by the FPGA can be made device-specific, for example, by arranging it as ID-dependent and / or physically non-clonable functions (“PUFs”). Tampering with the HSM will alter the output content because this cannot be inferred from the manufactured SP and FPGA.

[0092] In another option, the FPGA can be configured to provide a security monitoring block that monitors changes to logic block 502 and provides security options (e.g., generating warnings or restricting operations performed by the HSM) upon observing such changes, thereby protecting the HSM from reconfiguration. Furthermore, the FPGA can be configured to (e.g., intermittently) read the state of each logic block 502 and verify that the state matches expectations. This makes it more difficult for an intruder to maliciously switch logic blocks. Additionally, the FPGA can provide, for example, short-term RAM functionality supported by the HSM's battery. By appropriately selecting the FPGA, further technical advantages can be provided; for example, if the FPGA is implemented as a Zynq® Ultrascale+™ device, it provides the advantages described in the technical document XAPP1323.

[0093] As will become apparent from the examples provided below, implementation using an FPGA (including configurable logic) Figure 1 The processor 202 provides functionality with Figure 1 Compared to hardware security modules (HSMs) that are more robust to microarchitectural attacks (making HSMs more secure overall), HSMs also provide the ability to restore a high level of security to the system in response to the identification of microarchitectural attack vulnerabilities, thus allowing HSMs to be used for a longer period of time at a high level of security (i.e., not easily susceptible to identified microarchitectural attacks).

[0094] In the examples below, references will be made to "hard core" processors and "soft core" processors. A "soft core" processor (also known as a soft processor) is, for example, a processor that can be reconfigured based on received reconfiguration instructions. A "soft core" process is implemented in the programmable logic resources available in the FPGA (i.e., using the FPGA's configurable logic blocks (CLBs), block RAM, and digital signal processing (DSP) components).

[0095] In contrast, a "hard-core" processor (also known as a hard processor) is a processor implemented in silicon (or other semiconductors), such that the logical operations performed by the processor's logic blocks are determined by the processor's manufacturing process (i.e., the processor's components, such as control units, arithmetic units, and memory units, are implemented in a fixed manner). Therefore, the implementation of a "hard core" is fixed after manufacturing and is not reconfigurable like a "soft-core" processor.

[0096] Figure 6A A logic diagram of the FPGA in the HSM according to the first example embodiment is shown. Specifically, Figure 6A A field-programmable gate array (FPGA) 630 including a soft-core processor 631 is shown. Optionally, the FPGA 630 also includes at least one hardware-implemented cryptographic function 632, which is communicatively coupled to the soft-core processor 631. Figure 6A In the example, FPGA 630 could be about Figure 4 The FPGA discussed, or about Figure 5A The FPGAs discussed include System-on-Chip (SoC) and programmable logic.

[0097] The soft-core processor 631 is implemented in the programmable logic of the FPGA 600 and is configured to execute program code to perform actions related to... Figure 1 The hardware security module (HSM) described has the following functions (e.g., generating cryptographic keys, storing cryptographic keys, performing cryptographic operations, etc.). Although not shown, it will be understood that the soft-core processor is communicatively coupled to the input / output modules of the FPGA to communicate with external processes, components, or users.

[0098] The hardware-implemented cryptographic function 632 includes cryptographic functions implemented by executing functions through configurable logic specifically configured on the FPGA. In the example, the cryptographic operations include at least one of the following: a public-key hardware accelerator (PKSA), a random number generator, an Advanced Cryptographic Standard accelerator (AESA), and a message digest hardware accelerator (MDHA). Implementing at least one cryptographic function in hardware (i.e., using the configurable logic resources of the FPGA) accelerates the function by leveraging the ability to perform operations in parallel using logic resources.

[0099] exist Figure 6AIn the example, the processor used to execute the program code for the HSM is a "soft-core" processor (i.e., implemented in the configurable logic of the FPGA). Therefore, if it is determined that the version of the processor being used in the FPGA 630 is vulnerable to microarchitectural attacks, a new version of the processor core (which does not contain the vulnerability) is developed, and the FPGA is subsequently reconfigured to use the new version of the processor that does not contain the security vulnerability.

[0100] Therefore, the security of the Hardware Security Module (HSM) and the information it uses (e.g., cryptographic keys) is maintained, and the lifespan of the HSM is extended because the HSM no longer becomes obsolete due to identified security vulnerabilities.

[0101] Figure 6B A method for eliminating a security vulnerability in a Hardware Security Module (HSM) is illustrated according to an example. In step 651, information indicating a security vulnerability exists in the processor used in the HSM is obtained. Optionally, the security vulnerability is due to the existence of a newly disclosed microarchitectural attack. In the example, the information obtained in step 651 is obtained from the manufacturer of the soft-core processor.

[0102] In step 652, an updated soft-core processor is obtained. In one example, the updated soft-core processor is obtained by modifying the processor's hardware description, which eliminates the vulnerabilities identified in step 651. In another example, the updated soft-core processor is obtained by receiving a gate-level netlist (i.e., a list of logic gates and associated interconnections that constitute the circuit) from a third party (optionally from the same third party that designed the soft-core processor), wherein the gate-level netlist is generated by synthesizing the updated processor's hardware description.

[0103] In the example, if the current "soft core processor" implements a branch predictor, a vulnerability to Spectre attacks can be identified due to the branch predictor. For example, this vulnerability could arise from allowing unencrypted keys to be used in the authentication process (e.g., requiring the HSM user to provide a secure smart card to the HSM's smart card reader). Figure 3(Not shown in the image) After the application is generated following the process of reading the identifier to authenticate it, the branch predictor can speculatively perform the process of decrypting one or more cryptographic keys and storing them in a cache memory, such as that of an FPGA 630, before the authentication process is successfully completed. If authentication fails, the decrypted keys can remain in the cache memory, and a malicious third party may be able to extract them or cause the HSM to use them, thus creating a vulnerability. In this case, an updated soft-core processor can omit the branch predictor, thereby eliminating the Spectre attack vulnerability. Alternatively, for example, if the presence of the branch predictor is particularly valuable during the normal operation of the HSM, the branch predictor can be modified in some way to eliminate the vulnerability, for example by reconfiguring the branch predictor to perform a cache wipe at a specific time (e.g., when a certain wipe criterion is met, such as authentication failure, or failure to complete successfully at least within a certain time threshold after the generation of the unencrypted key), to remove sensitive data from the cache.

[0104] In step 653, FPGA 630 is reconfigured to use the updated soft-core processor. In one example, reconfiguring FPGA 630 to use the updated soft-core processor includes generating a bitfile that includes the updated soft-core processor by completing the FPGA design flow discussed above (i.e., through synthesis, placement, and routing, etc.), wherein the hardware description includes the updated soft-core processor and a hardware-implemented cryptographic function 632 (if present).

[0105] The updated bit file is then uploaded to FPGA 630, either using the JTAG programming interface or by uploading the updated bit file to memory and restarting FPGA 630 (i.e., powering on and off FPGA 630). During this process, FPGA 630 reads the contents of memory to identify the bit file used to configure the configurable logic. The process of reconfiguring FPGA 630 by resetting and uploading the complete updated bit file is called static reconfiguration. For example, the reconfigured bit file can be loaded onto non-volatile memory 208 via input / output (I / O) connector 201, or by replacing non-volatile memory 208 with a replacement non-volatile memory 208 storing the reconfigured bit file. FPGA 630 can load the reconfigured bit file from non-volatile memory 208 during a restart.

[0106] In another example, the FPGA 630 is dynamically reconfigured (referred to as dynamic reconfiguration or partial reconfiguration). Generally speaking, dynamic reconfiguration refers to the ability to modify blocks of programmable logic by loading a portion of the bit file into the FPGA, while the remaining logic (i.e., the unchanged static logic) continues to operate without interruption, thereby avoiding the need to restart the FPGA 630.

[0107] In short, dynamic reconfiguration technology involves specifying a reconfigurable portion of FPGA 630 and constructing a partial bit file for the portion of FPGA 630 to be reconfigured. In the example, a soft-core processor 631 is designed to occupy a reconfigurable region, and reconfiguring FPGA 630 includes: generating a partial bit file for the reconfigurable region based on the updated soft-core processor generated in step 652, sending the partial bit file to FPGA 630, and causing FPGA 300 to reconfigure the specified portion according to the partial bit file, thereby implementing an updated version of the soft-core processor (i.e., without security vulnerabilities) without disabling the hardware security module. In the example, the static portion of the FPGA 630 design includes a hardware-implemented cryptographic function 632.

[0108] As discussed above, by using FPGAs to implement soft-core processors, hardware security modules (HSMs) are more resilient to microarchitectural attacks because once an attack is identified, the soft-core processor can be easily updated through "patching." Furthermore, these vulnerabilities can be patched during the deployment of the hardware security module (HSM), thus extending the HSM's lifespan.

[0109] Figure 7A A logic diagram of the FPGA in the HSM according to the second example embodiment is shown. Figure 7A In, with Figure 6A The same reference numerals are used to denote the same components. Figure 7A A field-programmable gate array (FPGA) 700 is shown, which includes a control processor 701 (which may be a hard-core processor as shown) and a soft-core processor 631. Optionally, the hard-core processor 701 is a commercial off-the-shelf (COTS) processor, such as an application processor unit based on an ARM® Cortex-A53 (or -A9). Optionally, the FPGA 700 also includes at least one hardware-implemented cryptographic function 632 communicatively coupled to the soft-core processor 631. Note that in some embodiments, the control processor 701 may alternatively be a soft-core CPU instead of a hard-core processor, although this is generally not deducible.

[0110] exist Figure 7A In the example, FPGA 700 could be about Figure 5AThe SoC FPGA discussed includes both System-on-Chip (SoC) and programmable logic. Therefore, in Figure 7A In the diagram, the dashed line indicates the (logical) partition between the "fixed" circuitry of the System-on-Chip (SoC) and the programmable logic of the FPGA (which can be configured according to a user-generated bit file).

[0111] exist Figure 7A In the example, FPGA 700 includes a hard-core processor 701 (i.e., a processor implemented in silicon, wherein the processor's components (e.g., control unit, arithmetic unit, and memory unit) are implemented in a fixed manner; for example, the hard-core processor may be derived from... Figure 5A The processor 602 is implemented. The hard-core processor 701 is configured to execute the implementation regarding... Figure 1 The program code for at least a portion of the Hardware Security Module (HSM) functionality discussed.

[0112] Although the hard-core processor 701 is not reconfigurable, it does offer some advantages. For example, a hard-core processor can have a faster processing speed (i.e., clock rate) because it is specifically designed for high-speed operation. Furthermore, the hard-core processor 701 can support a larger instruction set and / or more advanced features (e.g., the use of cache) than a soft-core processor.

[0113] exist Figure 7A In the example, the processing of the HSM function is divided between the hard-core processor 701 and the soft-core processor 631. Specifically, security-critical operations (i.e., operations that retrieve, use, or generate cryptographic keys) are performed by the soft-core processor 631, while other operations (i.e., non-security-critical operations) are performed by the hard-core processor 701.

[0114] In this scenario, the security vulnerability in the hard-core processor 701 has a limited impact on the security of the Hardware Security Module (HSM) because all processing of security-critical data is performed by the soft-core processor 631, as per [the relevant regulations / information]. Figure 6A and Figure 6B The security vulnerability discussed could be patched by updating the soft-core processor 631. However, processing speed could be improved by using the hard-core processor 701 to perform other (non-security-critical) operations.

[0115] In response to the identification of a security vulnerability in the soft-core processor 631, the soft-core processor 631 was updated (to eliminate the security vulnerability), and the FPGA 600 was reconfigured to use as described above. Figure 6B The described updated version. Therefore, continuing the example explained above, if the security vulnerability is due to the branch predictor, which is part of the current soft-core processor 631, then the FPGA 700 can receive instructions (e.g., via the above regarding...) Figure 6AThe discussed method is to reconfigure the soft-core processor 631 to make it an updated soft-core processor that omits the branch processor or modifies the branch processor's operations in the updated soft-core processor, for example, performing a cache erase if the erase criterion is met.

[0116] Figure 7B A method executed by an FPGA 700 in an HSM according to a second example embodiment is illustrated. The method begins at step 751, where the hard core processor 701 obtains the next data processing operation from the program code. This operation can be a set of multiple instructions. For example, it can be a cryptographic operation.

[0117] In step 752, the hard processor 701 determines whether the next operation belongs to the first group of restricted operations. Specifically, the hard processor 701 determines whether the next operation is a cryptographic operation (i.e., an operation / function of retrieving, using, or generating a cryptographic key).

[0118] If the next operation is one of the restricted operations in that group, the method proceeds to step 753. In step 753, the hard-core processor 701 sends a request to the soft-core processor 631 to execute the operation (belonging to the first group of restricted operations). Subsequently, the soft-core processor 631 receives the request.

[0119] In step 754, the soft-core processor 631 executes the operation received in the request. The method then proceeds to step 755.

[0120] In step 755, the soft-core processor 631 sends an indication to the hard-core processor 701 that the operation requested in step 753 has been executed. In response to receiving this indication, the hard-core processor 701 proceeds to step 751, whereby the hard-core processor 701 obtains the next operation.

[0121] Returning to step 752, if it is determined in step 752 that the next operation is unrelated to operations belonging to the first group of restricted operations, the method proceeds to step 756. In step 756, the hard processor 701 executes the operation. The method then proceeds to step 751, where the hard processor 701 obtains the next operation.

[0122] In the example, the request sent to the soft-core processor 631 in step 753 includes data to be encrypted. The soft-core processor 631 retrieves the cryptographic key and encrypts the data in step 754, and then sends the encrypted data in an instruction sent in step 755.

[0123] Advantageously, Figure 7AThe architecture shown uses a hard-core processor 701 to perform unrestricted operations (thus increasing processing speed) and a soft-core processor 631 to perform restricted operations. Therefore, if a security vulnerability exists in the hard-core processor 701 and cannot be patched, this will not compromise the security of the Hardware Security Module (HSM), as operations related to the cryptographic keys are performed by the soft-core processor 631. Furthermore, in the event of a security vulnerability in the soft-core processor 631, the soft-core processor 631 can be updated (to eliminate the vulnerability), and the FPGA can be reconfigured to implement the updated soft-core processor 631. This maintains a high level of security and extends the lifespan of the HSM.

[0124] In principle, vulnerabilities could be discovered by malicious third parties without the HSM provider's knowledge. Therefore, the HSM provider could periodically update the soft-core processor to a new version (e.g., a heavily redesigned version), rendering any information that a malicious third party might have obtained regarding previous versions of the soft-core processor (e.g., related to vulnerabilities in previous versions of the soft-core processor) obsolete.

[0125] The Hardware Security Module (HSM) discussed above can be used by multiple different users. This is called multitenancy, where each tenant is a user of the Hardware Security Module (HSM). An example use case for multitenant systems is deploying the Hardware Security Module (HSM) in a cloud deployment, where end users or consumers can access the HSM's functionality as needed.

[0126] From a security perspective, multitenancy can present a challenge. For example, when using a single processor, a Hardware Security Module (HSM) might use the same processor to process sensitive data (e.g., password keys) from multiple different users. Therefore, the potential for security vulnerabilities increases because multiple users (who do not agree to share their sensitive information) are using a shared set of resources. Thus, a legitimate (but malicious) user of the HSM could execute program code to exploit vulnerabilities in the processor (e.g., microarchitectural attacks), allowing the user to access the sensitive information (e.g., password keys) of another user / tenant on the HSM.

[0127] If the soft-core CPU is limited to trusted software, multi-tenancy separation requirements can be met, for example, by using a single soft-core processor. However, other use cases have different requirements. For example, Figure 8A A logic diagram of an FPGA in a multi-tenant HSM according to a third example embodiment is shown. Figure 8A In, with Figure 7A The same reference numerals are used to denote the same components. Specifically, Figure 8AAn FPGA 800 is shown, which includes a control processor 701 (ideally, but not necessarily, a hard-core processor as shown), a soft-core processor 631 (associated with a first tenant), a second soft-core processor 802 (associated with a second tenant), and a third soft-core processor 804 (associated with a third tenant). Each of the soft-core processors 631, 802, and 804 is implemented in the programmable logic of the FPGA and communicatively coupled to the hard-core processor 701.

[0128] Optionally, a soft-core processor 701 (associated with the first tenant) is communicatively coupled to a hardware-implemented cryptographic function 632, a second soft-core processor 802 (associated with the second tenant) is communicatively coupled to a second hardware-implemented cryptographic function 803, and a third soft-core processor 804 (associated with the third tenant) is communicatively coupled to a third hardware-implemented cryptographic function 805. Each of the first, second, and third hardware-implemented cryptographic functions is implemented in the programmable logic of the FPGA 800.

[0129] In the example below, three tenants are discussed. However, to avoid any doubt, it should be emphasized that the technique described below can be extended to any number of tenants, more than one.

[0130] In a first example embodiment, the hard-core processor 701 is configured to execute program code associated with each tenant. For example, the hard-core processor 701 is configured to execute a first thread (defined by a first program associated with the first tenant), a second thread (defined by a second program associated with the second tenant), and a third thread (defined by a third program associated with the third tenant). Here, a thread (also referred to as a CPU thread) is a series of programming instructions that define a series of operations (where each operation may correspond to a corresponding sequence of multiple instructions among these instructions). Thus, the first thread is associated with the first tenant, the second thread with the second tenant, and the third thread with the third tenant. Therefore, the soft-core processor 632 is used (only) to execute operations associated with the first tenant; the second soft-core processor 802 is used (only) to execute operations associated with the second tenant; and the third soft-core processor 804 is used (only) to execute operations associated with the second tenant.

[0131] In the first example, the hard-core processor 701 was configured to execute per thread. Figure 7BThe method involves the hard core processor 701 retrieving the next operation and determining whether it is an operation within a set of restricted operations. If it is determined that the next operation (of the first thread) is indeed related to a restricted operation, a request is sent to the soft core processor 631 to execute the operation discussed above. In this example, the soft core processors implemented in the FPGA configurable logic are uniquely associated with tenants (i.e., each tenant has a single, unique soft core processor for executing operations that are restricted operations).

[0132] When the hard-core processor 701 is a single-core processor, while the FPGA 700 is executing the second thread, the first thread will be paused, and the second thread (associated with the second tenant) will be executed by the processor 701. The processor 701 executes... Figure 7B However, in this case, if it is determined that the next operation of the second thread is an operation in the group of restricted operations, the hard core processor sends a request to the second soft core processor 802 to execute the restricted operation, since it is the only second soft core processor 802 associated with the second tenant.

[0133] When the hard-core processor executes the third thread (associated with the third tenant), a similar approach is taken. In this case, operations from that group of restricted operations are sent to the third soft-core processor 804, as it is the only third soft-core processor 804 associated with the third tenant.

[0134] In another example, the hard-core processor 701 is a multi-core processor, where each tenant is associated with a different core, and operations unrelated to the restricted operation from different threads can be performed simultaneously on the corresponding core. For one of the threads, when the next operation of the corresponding core (associated with the corresponding tenant) is a restricted operation, that core sends a request to the soft-core processor uniquely associated with the same tenant to execute the restricted operation.

[0135] By implementing a Hardware Security Module (HSM) using an FPGA 800 with configurable logic, a soft-core processor can be implemented for each tenant. Therefore, restricted operations associated with each tenant's data are executed independently, reducing the risk that a tenant of the HSM could gain unauthorized access to secret information (e.g., cryptographic keys) associated with another tenant in a multi-tenant system. Figure 8A The implementation shown provides a more secure multi-tenant hardware security module (HSM).

[0136] In the example discussed above, the hard processor 701 is configured to perform non-restricted operations per tenant.

[0137] In another example, the hard core processor 701 is configured to send all operations performed for that tenant to the soft core processor associated with that tenant (i.e., regardless of whether they are related to restricted operations), thereby further improving isolation between tenants.

[0138] Figure 8B The layout of components in the FPGA of a multi-tenant HSM according to the third example embodiment is illustrated schematically. Figure 8B An FPGA 850 is shown, which includes a hard core processor 701, a first portion 851 of configurable logic associated with a first tenant, a second portion 852 of configurable logic associated with a second tenant, and a third portion 853 of configurable logic associated with a third tenant. The first, second, and third portions of the configurable logic are distinct and may not overlap, and may optionally be spaced apart from each other.

[0139] The first portion 851 of the configurable logic associated with the first tenant includes programmable logic (e.g., configurable logic block, digital signal processing block, block RAM) required to implement the soft-core processor 601, as well as hardware-implemented cryptographic functions 602 (if present).

[0140] Similarly, the second portion 852 of the configurable logic associated with the second tenant includes programmable logic (e.g., configurable logic blocks, digital signal processing blocks, block RAM) required to implement the second soft-core processor 802, as well as cryptographic functions 803 (if present) implemented in second hardware. Similarly, the third portion 853 of the configurable logic associated with the third tenant includes programmable logic (e.g., configurable logic blocks, digital signal processing blocks, block RAM) required to implement the third soft-core processor 804, as well as cryptographic functions 805 (if present) implemented in third hardware.

[0141] As discussed above, regarding Figure 4 During the FPGA design flow, when generating bit files (which include information indicating the configuration of programmable logic that implements the function of a specified circuit), constraints on the placement of synthesized logic within the FPGA can be specified (i.e., which parts of the configurable logic are selected to implement the first soft core, the second soft core, and the third soft core).

[0142] In the example, following the FPGA design flow discussed above, the locations of the first, second, and third parts of the configurable logic are constrained to specific regions of the FPGA die by using constraint files and generating bit files, where placement and routing are based on constraint files.

[0143] Specifically, in one example, the design can specify that the first, second, and third portions of the configurable logic should be placed as far apart as possible (within the FPGA resources) (e.g., diagonally across the FPGA die) or placed in locations that maximize the distance between the portions of the configurable logic (throughout the implementation). This reduces the risk that the security of one soft core is compromised if the security of another soft core is compromised, resulting in a more secure implementation of the multi-tenant hardware security module (HSM).

[0144] It should be understood that the present invention is not limited to the embodiments described above, and various modifications and improvements can be made without departing from the concept described herein. Unless mutually exclusive, any feature may be used alone or in combination with any other feature, and this disclosure extends to and includes all combinations and sub-combinations of one or more features described herein.

Claims

1. A hardware security module including a Field Programmable Gate Array (FPGA), the hardware security module comprising: A soft-core processor is used to execute program code implemented in a part of programmable logic; as well as A control processor is communicatively coupled to the soft-core processor; wherein the control processor is configured to: Obtain program operations; Determine whether the program operation is in the first group of restricted operations; and In response to determining that the program operation is in the first set of restricted operations, a request to execute the program operation is sent to the soft-core processor.

2. The hardware security module according to claim 1, wherein, The FPGA includes a system-on-a-chip, wherein the system-on-a-chip includes the control processor.

3. The hardware security module according to claim 1 or 2, wherein, The soft-core processor is also configured to: Receive a request to execute the program operation; Execute the program operation; and Send a response, including information associated with the program operation, to the control processor.

4. The hardware security module according to any one of claims 1 to 3, wherein: The hardware security module is a multi-tenant hardware security module used by the first tenant and the second tenant. In use, the FPGA is also configured to provide a second soft-core processor for executing program code; and wherein: The control processor is also configured to: Obtain a first operation from a first program associated with the first tenant, and in response to determining that the first operation is an operation in the first set of restricted operations, send a request to the soft-core processor to execute the first operation; and A second operation is obtained from a second program associated with the second tenant, and in response to determining that the second operation is an operation in the first set of restricted operations, a request to execute the second operation is sent to the second soft core processor; Therefore, the soft-core processor is used to perform operations associated with the first tenant, and the second soft-core processor is used to perform operations associated with the second tenant.

5. The hardware security module according to claim 4, wherein, The FPGA is also configured to: The soft-core processor is implemented through a first portion of the programmable logic of the FPGA; and The second soft-core processor is implemented through a second part of the programmable logic of the FPGA; The first and second parts of the programmable logic of the FPGA are different.

6. The hardware security module according to any one of the preceding claims, wherein, The FPGA is also configured to provide: The hardware-implemented cryptographic function is communicatively coupled to the soft-core processor.

7. A method for updating a hardware security module according to any one of the preceding claims, the method comprising: Obtain indications that the soft-core processor includes security vulnerabilities; Generate an updated version of the soft-core processor; as well as The FPGA is reconfigured to use an updated version of the soft-core processor.

8. The method according to claim 7, wherein: Generating an updated version of the soft-core processor includes: generating a bit file, the bit file including information for configuring the programmable logic in the FPGA, and wherein: Reconfiguring the FPGA includes loading the bit file into the FPGA.

9. The method according to claim 7, wherein: Generating an updated version of the soft-core processor includes: generating a partial bit file for configuring the portion of the configurable logic in the FPGA associated with implementing the soft-core processor, wherein: Reconfiguring the FPGA includes reconfiguring the portion of the configurable logic associated with the soft-core processor based on the partial bit file.

10. The method according to any one of the preceding claims, wherein, The control processor is implemented as a hard-core processor.

Images