Cryptographic device

Abstract

A hardware security module is presented that includes a tamper detection component, a random access memory component, a non-volatile memory component, at least one processor communicatively coupled to the random access memory component, the tamper detection component, and the non-volatile memory component, and a tamper resistant device encapsulating at least the tamper detection component. Only a subset of the components of the HSM are encapsulated in the encapsulation layer. In this way, the manufacturing of the HSM is made simpler and the testing, debugging, replacement, or repair of components outside the encapsulation layer is made easier.

Description

Technical Field

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

[0002] A hardware security module (HSM) is a device that securely stores and manages cryptographic keys and executes a set of cryptographic algorithms.

[0003] HSMs can include multiple hardware components on a printed circuit board (PCB). Due to the sensitive information (e.g., cryptographic keys) stored and processed by the HSM, hardware security modules can include physical mechanisms that provide security (e.g., prevent malicious third-party tampering).

[0004] For example, tamper-proof mechanisms can be provided. An example of such mechanisms is an epoxy coating that covers all hardware components on the printed circuit board, as well as the interconnections between them, thereby preventing physical access to the components and interconnections. This coating encapsulates the individual hardware components that make up the HSM and makes it more difficult for malicious third parties to compromise the security of the Hardware Security Module (HSM). Specifically, a physical attack on a hardware component could result in damage to the component and / or tracking of the printed circuit board.

[0005] However, packaging printed circuit boards (PCBs) in this way can affect the reliability of HSMs. For example, packaging PCBs in this way makes it difficult for legitimate parties to test, debug, replace, or repair the hardware components on the PCB. Furthermore, PCB packaging makes PCB manufacturing more specialized and expensive, and makes thermal management of components more difficult. Summary of the Invention

[0006] Generally, this disclosure proposes encapsulating only a subset of the components of the HSM within an encapsulation layer. Data transfer to components outside the encapsulation layer can be performed securely, ensuring that the system's security is not compromised by attacks on components outside the encapsulation layer. This simplifies the manufacture of the HSM and facilitates the testing, debugging, replacement, or repair of components outside the encapsulation layer. Attached Figure Description

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

[0008] Figure 1A and Figure 1B A first example of an HSM is shown in schematic top view and cross-sectional view, respectively;

[0009] Figure 2A and Figure 2B A second example of an HSM is shown in schematic top view and cross-sectional view, respectively;

[0010] Figure 3A and Figure 3B A third example of an HSM is shown in schematic top view and cross-sectional view, respectively;

[0011] Figure 4 A field-programmable gate array suitable for use in a third example of an HSM is shown;

[0012] Figure 5 The structure of the processing system used in the first and second examples of HSM is schematically shown;

[0013] Figure 6 It shows Figure 5 The operation of the processing system;

[0014] Figure 7 A fourth example of an HSM is shown in a schematic top view;

[0015] Figure 8A and Figure 8B The HSM, as an embodiment of the present invention, is illustrated in schematic top and cross-sectional views, respectively. Figure 8C The boot process of the HSM performed by this embodiment is shown;

[0016] Figure 9A and Figure 9B The HSM, as a second embodiment of the present invention, is shown schematically in top view and cross-sectional view, respectively;

[0017] Figure 10A and Figure 10B The HSM, as a third embodiment of the present invention, is shown schematically in top view and cross-sectional view, respectively;

[0018] Figure 11A and Figure 11B The HSM, as a fourth embodiment of the present invention, is illustrated schematically in top view and cross-sectional view, respectively; and

[0019] Figure 12 The steps of a method for manufacturing an HSM according to any one of the first to fourth embodiments are shown.

[0020] Throughout the accompanying drawings, the same reference numerals are used to refer to the same components or functions. Features of a component described with reference to one example or embodiment should be understood to apply to all examples or embodiments including that component. Detailed Implementation

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

[0022] Figure 1A This is a schematic illustration showing a plan view of a Hardware Security Module (HSM) device according to an example. Figure 1A A 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 (as shown), although in principle different components may be on different surfaces. 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.

[0023] The Hardware Security Module (HSM) includes an Input / Output (I / O) connector 201. The I / O connector 201 is communicatively coupled to the "main" 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.

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

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

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

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

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

[0029] 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 more fully 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.

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

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

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

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

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

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

[0036] exist Figure 1A In 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.

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

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

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

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

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

[0042] Figure 1B This is a schematic illustration showing a cross-sectional view of a Hardware Security Module (HSM) according to an example. Specifically, Figure 1B It shows along Figure 1A The cross-section of line A-A' shown. From Figure 1B As can be seen, the security processor 206, processor 202, and cryptographic coprocessor 204 are located on the surface of the printed circuit board (PCB) 200. Optionally, the printed circuit board (PCB) is a multilayer printed circuit board. The printed circuit board includes components as described above. Figure 1A The connections between the various components discussed include, for example, the connection between security processor 206 and processor 202. Specifically, Figure 1BMultiple conductive connections 210 between various components of the HSM are shown, optionally as shown on the surface of the printed circuit board 200.

[0043] from Figure 1B As can be seen, each component and interconnection is accessible. Therefore, a malicious third party with physical access to the HSM can tamper with the components to, for example, access a user's password key. For instance, a malicious third party can measure the voltage on the traces between components to determine if data is being transmitted between them. Alternatively or additionally, a malicious third party can disconnect or mimic the function of security processor 206 to falsely indicate to processor 202 that the HSM has not been tampered with.

[0044] To mitigate such attacks, encapsulation layers can be provided to protect components and connections on printed circuit boards (PCBs) from tampering.

[0045] Figure 2A A plan view of a hardware security module (HSM) according to an example is shown, which includes an anti-tamper coating 301 as an encapsulation layer. Figure 2A Use and Figure 1A The same reference numerals are used to denote the same components.

[0046] Figure 2A The illustrated Hardware Security Module (HSM) includes a package layer 301. Package layer 301 extends over all components within the Hardware Security Module (HSM). Package layer 301 extends over the surfaces of the various hardware components on the PCB, and also over another surface (in other words, it includes two package sub-layers located on opposite main surfaces of the PCB and substantially aligned with each other). Package layer 301 forms a complete barrier around all hardware components on the PCB, making the components inaccessible without penetrating package layer 301.

[0047] Encapsulation layer 301 provides an anti-tampering device; in other words, a mechanism to prevent unauthorized physical access to components on printed circuit board 200. An attacker might attempt to gain access to components by removing parts of encapsulation layer 301 (e.g., through abrasive attacks (e.g., rubbing the surface with sandpaper) or chemical attacks). However, such an attack could damage hardware components and / or provide evidence that an attack has occurred. For example, an organization receiving an HSM could easily detect whether encapsulation layer 301 shows signs of having been drilled. As mentioned above, since encapsulation layer 301 typically extends above both main surfaces of the PCB, an attack from either side of the PCB must penetrate encapsulation layer 301.

[0048] In this way, encapsulation layer 301 defines a security boundary within which data can be stored and processed in an unencrypted manner. Within encapsulation layer 301, the component can be assumed to be physically secure. Figure 2A In the example, the security boundary extends over all components on the printed circuit board 200, leaving only external connections to the PCB 200 (such as PCIe connections) exposed.

[0049] The encapsulation layer 301 may be formed of epoxy resin. For example, epoxy resin encapsulation layers provide good resistance to chemical and abrasive attacks. Alternatively, the encapsulation layer 301 may be formed of acrylic, ceramic, or silicone resin, for example. Preferably, the encapsulation layer 301 is opaque, making the location of the encapsulated component invisible through it. A specific example of a permissible resin is PX439XS, which is available from Robnor Resins Limited in Swindon, UK. This resin is black or beige in color.

[0050] Optionally, the hardware security module (HSM) also includes a tamper detection device in the form of a wire mesh 302. The wire mesh 302 is configured to extend over all components of the HSM, such that the components are located in the area beneath the wire mesh. Optionally, the wire mesh 302 extends completely around the components of the HSM, i.e., vertically downwards to the printed circuit board 200 and horizontally across the printed circuit board 200 to form a protective cage, making it impossible to access the components of the HSM without penetrating the encapsulation layer 301 and the wire mesh 302 or the printed circuit board 200.

[0051] The wire mesh 302 forms part of a set of sensors 207 coupled to a security processor 206 and configured to detect when an attempt has been made to access the component. The security processor 206 is operable to transmit a current, typically in the nanoamp range, through the wire mesh. In one example, the wire mesh 302 includes two conductive layers, thus forming a capacitor. During an intrusion attempt, the physical arrangement of the conductive layers will be disturbed, causing a change in the capacitance of the wire mesh. The security processor 206 is configured to receive measurements indicating any change in the capacitance of the wire mesh 302. In variations, the security processor 206 may alternatively or additionally receive measurements indicating the impedance or resistance of the wire mesh, for example, to detect whether the wire mesh provides a short circuit or an open circuit. In either of these cases, if a change is detected, the security processor 206 provides an indication to the processor 202 that the security of the HSM has been compromised. Optionally, in response to this indication, the functionality of the HSM is suspended, the HSM operator is alerted, and / or sensitive information stored by the HSM is destroyed. In this way, the wire mesh 302 provides a tamper detection device.

[0052] Figure 2B It shows Figure 2AA cross-sectional view of the Hardware Security Module (HSM) shows an tamper-proof device in the form of an encapsulation layer 301 and a tamper detection device in the form of a wire mesh 302. The encapsulation layer 301 typically, but not necessarily, has a substantially uniform thickness.

[0053] Optionally, some components of the HSM are not encapsulated in the encapsulation layer 301. For example, the battery (if present) is typically not encapsulated in the encapsulation layer 301 so that it can be replaced as needed. Additionally, the IO connector 201 is not encapsulated in the encapsulation layer.

[0054] However, according to Figure 2A and Figure 2B It will be understood that while the encapsulation layer 301 and the wire mesh 302 make the HSM more secure, they can also, for example, prevent legitimate users from accessing the HSM's components for testing, debugging, repair, or replacement. In this way, the lifespan or reliability of the HSM may be compromised.

[0055] Figure 3A A schematic illustration of a plan view of a Hardware Security Module (HSM) device according to another example is shown. Figure 3A Use and Figure 2A The same reference numerals are used to denote the same components.

[0056] Figure 3A The hardware security module (HSM) includes a field-programmable gate array (FPGA) 401. This is preferably as described in the following reference. Figure 5 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 1A(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 implemented as discrete, separately packaged components. A SoC FPGA is an integrated circuit that includes a fixed central processing unit and an array of programmable logic blocks, as well as a hierarchy 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 their fabrication. The fabrication 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 functionality implemented by the FPGA is defined at a later stage when the interconnects between the various blocks are formed.

[0057] 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 3A The FPGA 401 included in the HSM may include, for example Figure 4 The FPGA shown.

[0058] Figure 4 An 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.

[0059] 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 4The 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.

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

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

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

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

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

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

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

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

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

[0069] Figure 5 A schematic illustration of a SOC field-programmable gate array (FPGA) that can be included in an HSM device, depending on the variant, is shown. For example, Figure 3A The FPGA 401 included in the HSM may include, for example Figure 5 The image shows a SoC FPGA. A 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.

[0070] Logically, the SoC FPGA is divided into the processing system 600 and the programmable logic 606.

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

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

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

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

[0075] exist Figure 3A In the HSM shown, regarding Figure 1A 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 5 The SoCFPGA is described. However, alternatively, FPGA 401 could be, for example, regarding... Figure 4 The FPGA described.

[0076] Such as about Figure 1A 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.

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

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

[0079] Figure 6 A schematic diagram of a SoC FPGA is shown, illustrating the various functions implemented within it. An FPGA is, for example, related to... Figure 5 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.

[0080] 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 702 is represented as a software product or process in the working memory of the processing system 600.

[0081] When certain cryptographic operations are to be performed, application process 702 invokes cryptographic device driver module 703. The computer program code corresponding to the cryptographic device driver module is stored in the HSM's non-volatile memory 208 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 703 implements a driver process that coordinates data transfers to and from the FPGA and provides an initialization process "Init" 705, configured to initialize other components of the HSM's hardware that are being driven by cryptographic device driver 703, such as components implemented in programmable logic.

[0082] Driver 703 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 702 invokes cryptographic device driver module 703. Driver module 703 sends a request to programmable logic 606 to perform an operation. Programmable logic 606 has hardware implementations of one or more cryptographic operations.

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

[0084] An optional IF (interface) component 706 is implemented in programmable logic. This IF component 706 is configured to access multiple acceleration cores ACC 707 and balance the load among the multiple acceleration cores ACC 707. 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.

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

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

[0087] By implementing the various functions of the cryptographic coprocessor 204 of the device in Figure 1 in an FPGA, the HSM device becomes reconfigurable. For example, the FPGA can be reconfigured to implement a more secure version of the operations implemented in hardware.

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

[0089] 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., periodically) 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. Further technical advantages can be provided by appropriately selecting the FPGA, for example, if the FPGA is implemented as a Zynq® Ultrascale+ TM The device provides the advantages described in the technical document XAPP1323.

[0090] The process of reconfiguring an FPGA to implement a more secure version of operation begins with the user generating a description of the new hardware circuitry, for example, using a Hardware Description Language (HDL). During synthesis, the high-level hardware description of the circuitry is converted into a netlist. During placement and routing, the netlist 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. The output of placement and routing is a new bitfile. The new FPGA bitfile is then loaded into the non-volatile memory 208 of the HSM, and the FPGA is configured to read the new bitfile from the non-volatile memory during power-up and implement the functionality of the new bitfile, resulting in a new configuration corresponding to the more secure version of operation.

[0091] Furthermore, by implementing the functions of the processor 202 and cryptographic coprocessor 204 of the device of FIG1 on a single chip including FPGA 401, the area to be protected by tamper-proof devices can be reduced. Figure 3BA cross-sectional view of the Hardware Security Module (HSM) is shown. The Hardware Security Module (HSM) includes a package layer 301. The package layer 301 extends over the FPGA 401 and the security processor 206, and over some or all of the other components in the Hardware Security Module (HSM), but typically does not extend over the I / O connector 201. From Figure 3A and Figure 3B It will be apparent that the tamper-proof device 302 can cover a smaller area. Optionally, the example hardware security module (HSM) includes a tamper detection device in the form of a wire mesh 302. By combining functionality into a single chip, the area vulnerable to security vulnerabilities has been reduced.

[0092] Figure 7 This is a schematic illustration of a plan view of an HSM device according to the fourth example, wherein the HSM device includes an FPGA 704. For example, the FPGA 704 may include, Figure 4 The FPGA shown is shown. Figure 7 In, with Figure 3A The same reference numerals are used to denote the same components.

[0093] The Field Programmable Gate Array (FPGA) 704 is a single, discrete, self-contained package that implements various functions performed by the cryptographic coprocessor 204, such as... Figure 1A As stated above.

[0094] Such as about Figure 1A The application computer program code is stored in the non-volatile memory 208 of the HSM. The processor 202 is configured to execute as described above. Figure 1A The application described. The FPGA 704 is configured to perform various cryptographic functions in hardware using configurable logic, such as various standard encryption and decryption algorithms and digital signature algorithms. For example, the FPGA 704 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 the FPGA 704, one or more of these operations are implemented directly in hardware.

[0095] FPGA 704 is configured to receive requests from processor 202 to perform one or more operations and return the output of those operations to processor 202. Processor 202 is configured to offload various operations to FPGA 704. FPGA 704 is configured to perform certain operations in hardware, meaning that these operations can be performed more efficiently on FPGA 704 than on processor 602.

[0096] 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 processor 202, wherein the application is represented as a software product or process in the working memory of the HSM.

[0097] When certain cryptographic operations are to be performed, the application process invokes the cryptographic driver device module. 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 process. When executed, a copy of the program code is loaded into the working memory of the HSM, where the cryptographic device driver module is represented as a software product or process in the working memory of the HSM. The cryptographic device driver is configured to access the FPGA 704. The cryptographic device driver process sends a request to the FPGA 704 to perform an operation. The programmable logic 606 has hardware implementations of one or more cryptographic operations. The cryptographic device driver module implements a driver process that coordinates data transfers to and from the FPGA and provides an initialization process "Init" configured to initialize other components of the HSM's hardware that are being driven by the cryptographic device driver, such as components implemented in the programmable logic within the FPGA 704.

[0098] The optional IF (Interface) component 706 is implemented in the programmable logic of the FPGA 704. The IF component 706 is configured to access multiple acceleration cores (ACCs) of the FPGA 704 and to balance the load among the multiple acceleration cores (ACCs). 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.

[0099] By implementing the various functions of the cryptographic coprocessor 204 of the device in Figure 1 within the FPGA 704, the HSM device becomes reconfigurable. For example, the FPGA 704 can be reconfigured to implement a more secure version of the operations implemented in hardware.

[0100] Figure 8A A schematic illustration of a plan view of a hardware security module (HSM) device according to an embodiment is shown, wherein the HSM includes an FPGA 401. Figure 8B A schematic illustration of a cross-sectional view of a Hardware Security Module (HSM) device is shown. Figure 8A and Figure 8B In, with Figure 3A The same reference numerals are used to denote the same components. In this example, FPGA 401 includes, as shown below: Figure 5 The SoC FPGA is shown. In an alternative example, FPGA 401 is, for example, as shown below. Figure 4 The FPGA shown.

[0101] exist Figure 8A and Figure 8B In the Hardware Security Module (HSM), the security processor 206, sensor 207, random number generator (RNG) 205, and FPGA 401 are covered by a package layer 301. Although in Figure 8B In this diagram, the security processor 206, FPGA 401, and sensor 207 are shown mounted on the same main surface of PCB 200; however, in variations, any one of them may be mounted on an opposing surface of PCB 200. Electrical connections extending within the PCB may be provided as needed. Typically, all pins of all integrated circuit components are covered by package layer 301, although pins providing electrical connections to components outside the package layer (e.g., IO connector 201) may, in principle, be exposed. The HSM may also include a power source (e.g., a battery) outside the package layer 301.

[0102] The HSM's random access memory 209 is not covered by the encapsulation layer 301. Instead, sensitive data stored in the RAM 209 is encrypted. Furthermore, this sensitive data is also encrypted when transferred between the FPGA 401 and the RAM 209. One way to do this is to have the FPGA request a random number from the RNG 205. When data is to be stored in RAM 209, the FPGA 401 first modifies at least a portion of the data to be stored between it and one of the random numbers (encrypting it, e.g., by performing an XOR operation in a simple example), and writes the result to RAM 209. The random number is stored in the FPGA 401. When data is read from RAM 209, it is decrypted (e.g., again by an XOR operation in the simple case) to obtain the original data. Note that the same random number (e.g., by permutation) can be used to encrypt multiple portions of the data to be stored in RAM 401 in this way, allowing the amount of data encrypted with a given random number to be much larger than the size of the random number stored in the FPGA 401. Once all data encrypted with a given random number has been decrypted, FPGA 401 can request a new random number from RNG 205 to replace it. If FPGA 401 is powered off, the random number is lost, making it impossible to decrypt the data currently stored in RAM 401.

[0103] In variations, other generally basic encryption algorithms can be used. For example, FPGA 401 can store a second cryptographic key. The second cryptographic key can be stored in internal battery-based random access memory (BBRAM) or using an electronic fuse within FPGA 401. Sensitive data is encrypted using the second cryptographic key before it leaves FPGA 401. The second cryptographic key does not leave FPGA 401. Sensitive data is stored in encrypted form in RAM 209.

[0104] exist Figure 8A In this embodiment, the tamper-proof device 301 does not cover the RAM 209, non-volatile memory 208, input / output 201, or power socket 203 (or power source (battery), not shown). Therefore, these components (e.g., RAM memory 209) can be easily repaired or replaced, thereby improving the reliability of the HSM device. In this embodiment, the HSM device includes the aforementioned tamper detection device 302 in the form of a wire mesh. The tamper detection device 302 does not cover various components, specifically the RAM 209 of the HSM device.

[0105] The HSM stores the master key at least partially in the security processor 206 and / or at least partially in the FPGA 401, i.e., covered by the package 301 and the tamper detection device 302. For example, it may be stored in a portion of the FPGA 401 that is battery-powered and loses the master key if power is lost.

[0106] The non-volatile memory 208 is also not covered by the package layer 301. The non-volatile memory 208 stores the application code to be implemented by the FPGA 401, as well as a bit file containing information identifying the configuration of programmable logic resources within the FPGA 401 (as stated above, unless otherwise specified, the term FPGA is used herein to include both FPGA and SoC FPGA). The application code and bit file are stored in the non-volatile memory 208 in an authenticated form (but not encrypted), while the key (e.g., a cryptographic key) may be stored in the non-volatile memory in an encrypted form (e.g., encrypted using a master key). When the non-volatile memory 208 is installed, the FPGA 401 can perform an authentication process on the non-volatile memory 208 based on the data stored therein. Additionally, the FPGA 401 reads and decrypts the key.

[0107] FPGA 401 uses a "safe boot" procedure during startup. Figure 8C An example method for initializing an HSM device is shown. This method can be performed when the HSM is powered on (e.g., in response to receiving a "Power On" or "Reset" signal at the "Power / Reset" component).

[0108] In S801, the boot code stored in FPGA ROM 604 is executed.

[0109] In S802, software from HSM non-volatile memory 208 is retrieved, verified, and loaded into processing system 600. This step may include several stages, wherein boot code first retrieves and executes first software from non-volatile memory 208, then retrieves and executes second software from non-volatile memory 208, and so on. S802 includes booting the software onto processing system 600.

[0110] As part of this process, the certified application code is retrieved from non-volatile memory 208. FPGA 401 stores a first cryptographic key (e.g., a master key) used to recover and verify the key. Optionally, the first key is stored in internal battery-based random access memory (BBRAM) or stored using an electronic fuse (eFuse).

[0111] In S803, the software running on the processing system 600 then configures the programmable logic 606. During HSM initialization, the software running on the processing system 600 retrieves and authenticates a bit file from the HSM's non-volatile memory 208, the bit file containing information identifying the configuration of the programmable logic. The software running on the processing system 600 then configures the programmable logic 606.

[0112] The sensitive data stored in non-volatile memory 208 is not "public." That is, the sensitive data is stored in encrypted form in non-volatile memory 208. Even if a malicious actor reads information from non-volatile memory 208 by physically accessing the HSM device, they still cannot obtain the sensitive data without accessing the first cryptographic key. The first cryptographic key is stored within FPGA 401 (which is inside the security boundary formed by encapsulation layer 301) and therefore cannot be physically accessed by a malicious actor. The authenticated and encrypted key is now retrieved from non-volatile memory 208.

[0113] The tamper-proof device 301 does not cover the non-volatile memory 208. Therefore, the non-volatile memory 208 can be easily repaired or replaced, thereby improving the reliability of the HSM device.

[0114] In this example, the HSM device includes a tamper detection device 302. The tamper detection device 302 does not cover the non-volatile memory 208 of the HSM device.

[0115] By initializing FPGA 401 using a secure boot process and encrypting the data in RAM 209, the security boundary formed by encapsulation layer 301 can be reduced, so that encapsulation layer 301 only covers security processor 206, sensor 207, RNG 205, and FPGA 401. These components are only those containing sensitive data in unencrypted form or data used to determine the security of hardware security modules.

[0116] By reducing the number of components covered by the encapsulation layer, the PCB 200 is made easier to debug, test, and maintain.

[0117] Note that different areas within the FPGA 401 can be configured to process information with different security levels. For example, there can be a "decision" section and an "execution" section. The "decision" section is the main logic of the FPGA 401, but it never processes unencrypted keys, while the "execution" section processes unencrypted keys and checks the actions of the main logic. This reduces the required security level for the decision section to some extent.

[0118] Figure 9A A schematic diagram of a hardware security module (HSM) according to another embodiment is shown. Figure 9B A cross-sectional view of the Hardware Security Module (HSM) is shown. Figure 9A and Figure 9B In, with Figure 3A The same reference numerals are used to denote the same components.

[0119] Figure 9A The hardware security module (HSM) is shown, in which the security processor 206, sensor 207, non-volatile memory 208, RNG 205 and FPGA 401 are covered by the encapsulation layer 301.

[0120] Specifically, in Figure 9A In this process, a security boundary is added to cover the non-volatile memory 208. Therefore, sensitive data can be stored in the non-volatile memory 208 in plaintext (i.e., without encryption).

[0121] Such as about Figure 8AThe data stored in the random access memory (RAM) 209, as well as the data transferred between the FPGA 401 and the RAM 209 during use, is encrypted. Therefore, in this case, there is no vulnerable data stored in the RAM 209 (i.e., data that could be intercepted and lead to security vulnerabilities). Instead, the RAM 209 stores data in encrypted form, which can only be decrypted by breaching the security boundary of the FPGA 401. Therefore, when data is stored in RAM, it is not "publicly available" in a form easily understood by a malicious third party.

[0122] Therefore, there is no need for anti-tampering devices and tamper detection devices to cover RAM 209, as this is no longer a vulnerable part of the HSM. Anti-tampering device 301 does not cover RAM 209. Therefore, RAM 209 can be easily repaired or replaced, thereby improving the reliability of the HSM device.

[0123] Figure 10A A schematic diagram of a hardware security module (HSM) according to another embodiment is shown. Figure 10B A cross-sectional view of the Hardware Security Module (HSM) is shown. Figure 10A and Figure 10B In, with Figure 3A The same reference numerals are used to denote the same components. In this embodiment, only the security processor 206, sensor 207, RNG 205, RAM 209, and FPGA 401 are covered by the encapsulation layer 301. The non-volatile memory 208 is not covered by the encapsulation layer 301.

[0124] RAM 209 is covered by encapsulation layer 301, so data can be stored and transmitted to RAM 209 in plaintext (in other words, without encryption).

[0125] As described with respect to Figure 8, the non-volatile memory 208 is not covered by the encapsulation layer 301. Application code and bit files are stored in the non-volatile memory 208 in an authenticated form, and the key stored in the non-volatile memory 208 is encrypted. The FPGA 401 uses a "secure boot" process during startup.

[0126] Similarly, sensitive data stored in non-volatile memory 208 is in encrypted form. Even if a malicious actor reads information from non-volatile memory 208 by physically accessing the HSM device, they still cannot obtain the sensitive data without accessing the first cryptographic key. The first cryptographic key is stored within FPGA 401 (which is inside the security boundary formed by encapsulation layer 301) and therefore cannot be physically accessed by a malicious actor.

[0127] The tamper-proof device 301 does not cover the non-volatile memory 208. Therefore, the non-volatile memory 208 can be easily repaired or replaced, thereby improving the reliability of the HSM device.

[0128] In this example, the HSM device includes a tamper detection device 302. The tamper detection device 302 does not cover the non-volatile memory 208 of the HSM device.

[0129] like Figure 10B As shown, the electrical connection between FPGA 401 and security processor 206 is provided as electrical connection 1001. Electrical connection 1001 has a "U-shaped" configuration, which includes a plane located within PCB 200 and parallel to the main surface of the PCB (i.e., as shown). Figure 10B A horizontally extending conductive elongated portion 1002 is shown. It also includes conductive portions 1003 and 1004 (vias) at both ends of portion 1002, which extend substantially laterally to the main surface of PCB 200 and provide electrical connections from portion 1002 to security processor 206 and FPGA 401, respectively. The portions 1003 and 1004 of the electrical connections 1001 are spaced apart from the periphery of security processor 206 and FPGA 401 on the surface of PCB 200 (in... Figure 10B Electrical contact is made with FPGA 401 and security processor 206 at the corresponding location (shown in the horizontal direction). In other words, the location is on the "lower" surface (the surface of security processor 206 and FPGA 401 located on PCB 200) of security processor 206 and FPGA 401, spaced apart from the edges of these surfaces. Therefore, Figure 10B An example of the conductive connection described above is shown, extending within a PCB, wherein the conductive connection transverse to the main surface of the PCB is provided by vias. One or more conductive connections of this type may be provided in any embodiment. Figure 10B As shown, they can connect two components within the encapsulation layer 301. Additionally, as... Figure 10B As shown, they can be connected to components at appropriate locations spaced apart from the periphery of components on the PCB.

[0130] Figure 11A A schematic diagram of a hardware security module (HSM) according to another embodiment is shown. Figure 11B A cross-sectional view of the Hardware Security Module (HSM) is shown. Figure 11A and Figure 11B In this document, the same reference numerals as those in the foregoing examples and embodiments are used to denote the same components, and all have the functions described above.

[0131] Figure 11AA hardware security module (HSM) is shown, in which only the security processor 206, RNG 205, and sensor 207 are covered by the encapsulation layer 301. In this HSM, RNG 205 is connected to the security processor 206, not the FPGA 401. Note that, as in other embodiments, RNG 205 is within the encapsulation layer 301, and the communication path for RNG 205 to send random numbers to other components is also the same.

[0132] The device actually includes two areas with primary tamper protection. The first of these two areas is applied when the FPGA 401 (preferably a SoC FPGA) is powered on. For example, when the FPGA 401 is one of the specific choices mentioned above (e.g., Zynq® Ultrascale+...). TM In the case of an MPSoC, tamper protection is provided by the secure operation of the FPGA 401 itself. That is, the FPGA 401 is configured to be sensitive to attacks while powered on. Once an attack is detected, the FPGA enters an alarm state, in which it can erase all sensitive data stored in the FPGA 401 (e.g., random numbers used to encrypt data stored in RAM 209 and any unencrypted keys). Specifically, all internal FPGA memory can be erased and all FPGA processors can be reset. Additionally, when the FPGA 401 is powered off, all sensitive data stored in the FPGA 401 is lost, so no security risk arises even though the primary tamper protection area is no longer effective. In both the alarm state and power-off conditions, it is preferable not to erase the ID stored within the FPGA. In, for example, the configuration shown in Figure 10, this facilitates the return of the HSM to the manufacturer and, for example, the reset of the HSM for reuse after repair of damage caused by an intruder.

[0133] The second area of ​​primary tamper protection is defined by the tamper protection provided by the encapsulation layer 301 and the security processor 206 through interaction with the sensor 207 and the wire mesh 302. This tamper protection remains effective while sensitive materials are stored in this second area. It is independent of a power source outside the encapsulation layer 301; instead, the security processor 206 may include an internal power source (not shown), or may provide a power source separate from the security processor 206, encapsulated within the encapsulation layer 301. If the power source outside the encapsulation layer 301 fails (e.g., using an internal power source or a power source encapsulated within the encapsulation layer), the sensitive materials are removed. The security processor 206 is designed to be highly energy efficient. If the security processor 206 detects an attack, or if the power source within its encapsulation layer 201 fails to provide power above a threshold, the security processor 206 enters an alarm state, in which any sensitive materials within it are erased.

[0134] Furthermore, either FPGA 401 and / or security processor 206 can be configured to: send an alarm signal to the other of FPGA 401 and security processor 406 when entering an alarm state; and upon receiving the alarm signal, the other of FPGA 401 and security processor 406 can automatically enter an alarm state and thus perform the aforementioned actions.

[0135] FPGA 401 and security processor 206 can be configured such that neither is "cryptographically complete" on its own; in other words, information from both is required to perform certain security operations. One way to achieve this is to split one or more keys used by FPGA 401 into two "key parts," one stored on FPGA 401 and the other on security processor 206. Neither key part is sufficient to perform a successful cryptographic operation. If FPGA 401 needs to perform an operation (cryptographic algorithm) using a key that has been split into key parts, it requests the key part of that key stored in security processor 206. After receiving the key part from security processor 206, it uses the complete key to perform the security operation and then erases the key part received from security processor.

[0136] The key portion stored in each of FPGA 401 and security processor 206 may belong to sensitive data that is erased when FPGA 401 or security processor 206 enters an alarm state, respectively.

[0137] Alternatively or additionally, FPGA 401 and security processor 206 may have different "shared secrets," i.e., data required as part of a handshake operation between FPGA 401 and security processor 206, and security processor 206 may delete portions of this information when it enters an alarm state (e.g., power failure). The handshake operation may be performed as a challenge / response operation, for example, at intervals. For instance, FPGA 401 may be configured to observe that: after FPGA 401 sends a challenge message to security processor 206, security processor 206 signals that it is in an alarm state, and / or security processor fails to provide a proper response, or the time spent responding to the challenge message exceeds a threshold.

[0138] Because FPGA 401 erases all sensitive information when it is powered off, it does not need to be covered by the package layer 301 and / or the wire mesh 302. Therefore, FPGA 401 can be easily repaired or replaced, thereby improving the reliability of the HSM device.

[0139] Furthermore, since the non-volatile memory 208 is not covered by the encapsulation layer 301 and / or the metal mesh 302, the non-volatile memory 208 can be easily repaired or replaced, thereby improving the reliability of the HSM device.

[0140] Such as about Figure 8A The data stored in the random access memory (RAM) 209, and the data transferred between the FPGA 401 and the RAM 209 during use, are encrypted, for example, using a temporary key. Therefore, in this case, there is no vulnerable data stored on the RAM 209 (i.e., data that could be intercepted and lead to security vulnerabilities). Instead, the RAM 209 stores data in encrypted form, which can only be decrypted by breaching the security boundary where the FPGA 401 is located. Therefore, when data is stored in RAM, it is not "exposed" in a form easily understood by a malicious third party. Therefore, there is no need for an encapsulation layer 301 and / or a wire mesh 302 to cover the RAM 209. Therefore, the RAM 209 can be easily repaired or replaced, thereby improving the reliability of the HSM device.

[0141] Despite Figure 11A In this diagram, the wire mesh 302 is shown entirely within the encapsulation layer 301, but alternatively, it may extend beyond the encapsulation layer 301, for example, covering any or all components of the HSM shown in FIG. 2. In this case, the wire mesh 302 may be provided as a woven mesh made of epoxy resin. Figure 12 A method for manufacturing an HSM device is illustrated. This method can be used to manufacture, for example... Figure 7 The device shown in Figure 8, Figure 9, or Figure 10 or Figure 11.

[0142] In step S1001, hardware components are mounted onto the PCB. In this step, non-volatile memory components, RAM, sensors, security processors, FPGAs, RNGs, input / output connectors, and power / reset components are mounted onto the PCB.

[0143] In S1002, an encapsulation layer is provided. In this step, epoxy resin (e.g., the specific epoxy resin discussed earlier) is applied over all components to be covered by the encapsulation layer. For example, epoxy resin is applied over FPGAs, security processors, and sensors. The epoxy resin is then cured in situ.

[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. Specifically, references above... Figures 1A to 7The various features of the components described in the examples apply to the same components used in the embodiments of Figures 8 through 11. For example, Figures 5 to 6 The FPGA configuration described herein can be used in the embodiments of Figures 8 through 11. In another example, the FPGA 401 in the embodiments of Figures 8 through 11 can be replaced with a fixed processor, as referenced above. Figures 1A to 2B As stated above.

Claims

1. A hardware security module device, comprising: Tamper detection components; Random access memory components; Non-volatile memory components; At least one processor is communicatively coupled to the random access memory component, the tamper detection component, and the non-volatile memory component; as well as The tamper-proof device at least encapsulates the tamper detection component, wherein at least one of the random access memory component and the non-volatile memory component is external to the tamper-proof device.

2. The device according to claim 1, wherein, The random access memory is external to the tamper-proof device and is configured to store data in encrypted form. When in use, the at least one processor is configured to: encrypt the data, send the encrypted data to be stored in the random access memory, and recover the data retrieved from the random access memory.

3. The device according to claim 1 or claim 2, wherein, The at least one processor is configured to: detect a physical attack on the at least one processor, and enter an alarm state when the attack is detected, wherein in the alarm state, the at least one processor erases the data stored in the at least one processor.

4. The device according to any one of the preceding claims, wherein, The tamper detection component includes a security processor encapsulated in the anti-tamper device and coupled to the at least one processor. The tamper detection component and the security processor are configured to cooperate to perform cryptographic algorithms on the data. The tamper detection component is also configured to determine whether at least one alarm criterion is met, and to enter an alarm state when the at least one alarm criterion is met.

5. The device according to claim 4, wherein, When the security processor enters the alarm state, the security processor is configured to erase the data stored within the security processor.

6. The device according to claim 4 or 5, which is dependent on claim 3, wherein, When the security processor enters the alarm state, the security processor is configured to send a message to the at least one processor to cause the at least one processor to enter the alarm state.

7. The device according to any one of claims 4 to 6, wherein, The tamper detection component further includes at least one sensor communicatively coupled to the security processor, wherein the security processor is configured to: identify, based on readings from the sensor, that the security of the device has been compromised, and enter the alarm state upon such identification.

8. The device according to any one of claims 4 to 7, wherein, The at least one sensor includes a metal mesh embedded in the tamper-proof device, and the security processor is configured to: recognize that the security of the device has been compromised in response to detecting a change in the electrical properties of the metal mesh, and enter the alarm state upon recognition.

9. The device according to any one of the preceding claims, wherein, The at least one processor includes a field-programmable gate array (FPGA) component.

10. The device according to claim 9, wherein, The non-volatile memory component stores program files and bit files, and wherein, when in use, the FPGA is configured as follows: Load the program file and the bit file from the non-volatile memory component; Configure a portion of the programmable logic in the FPGA according to the bit file; and The program file is executed using the configuration section of programmable logic.

11. The device according to claim 10, wherein, The bit file includes information for implementing cryptographic functions in the programmable logic portion of the FPGA.

12. The device according to claim 10 or claim 11, wherein, The non-volatile memory is configured to store encryption keys, and wherein, in use, the FPGA is further configured to: load the encryption keys from the non-volatile memory, recover the one or more keys using a first cryptographic key, and execute the program file using the recovered key.

13. The device according to any one of the preceding claims, wherein, In use, the at least one processor and the tamper detection component are configured to store different corresponding subsets of the security keys, and the at least one processor is configured to: when the security keys are to be used to perform a cryptographic operation, obtain a subset of the security keys stored by the tamper detection component from the tamper detection component, and use the security keys to perform the cryptographic operation.

14. The device according to any one of the preceding claims, wherein, The tamper-proof device includes an encapsulation layer, such as an encapsulation layer provided as an epoxy layer.

15. The device according to any one of the preceding claims, wherein: The anti-tampering device encapsulates at least a portion of the at least one processor, the tampering detection component, and one or more connections between the at least one processor and the tampering detection component; At least a portion of the at least one processor is external to the anti-tampering device, and the anti-tampering device encapsulates the tampering detection component; The device also includes a random number generator component, which may optionally be encapsulated by the tamper-proof device; and / or The random access memory, the non-volatile memory, and the at least one processor are each implemented as discrete, separately packaged components.

Images