Apparatus and method for performing cryptographic operation

Abstract

An apparatus comprising: an input; and a plurality of processing modules, the plurality of processing modules including a first processing module and a second processing module, the apparatus configured to: in response to a first command received through an input, perform a cryptographic operation corresponding to the first command on the first processing module; in response to a second command received through the input, a cryptographic operation corresponding to the second command is performed on the second processing module.

Description

Technical Field

[0001] The present invention relates to a device and a method for performing cryptographic operations. For example, the device may be a hardware security module device. Background Art

[0002] Various devices can be used to perform cryptographic operations. For example, a hardware security module (HSM) is a device configured to securely store and manage cryptographic keys and perform a set of cryptographic functions. The HSM can include both physical and non-physical properties that provide security. Non-physical security properties can include the use of encryption, i.e., including software or physical components in the device to perform encryption of stored data. Physical security properties can include, for example, a tamper switch triggered by physical access, and a tamper-proof film around the physical boundary of the device.

[0003] Various service providers aim to provide computer-implemented services to a large number of users. One example is cloud service providers (CSPs), who offer products such as "software as a service" (SaaS) or on-demand storage. Using computer-implemented services hosted by a service provider allows users to reduce the management overhead of self-hosting such services. Encryption services hosted by a service provider can use a "single-tenant" solution, where a dedicated HSM device is deployed for each user. This may lead to inefficient use of HSM resources because each user may not require all the resources provided by an entire HSM device. However, providing a multi-tenant solution, where multiple users use the same HSM device, may introduce security vulnerabilities. Brief Description of the Drawings

[0004] The device and method according to non-limiting embodiments will now be described with reference to the drawings, in which:

[0005] Figure 1 is a schematic diagram of a system including a hardware security module (HSM) according to a comparative example;

[0006] Figure 2 is Figure 1 a schematic diagram of the system in use;

[0007] Figure 3 is Figure 1 a schematic diagram of two containers running on the HSM device of ;

[0008] Figure 4 is a schematic diagram of a system including a hardware security module according to an embodiment;

[0009] Figure 5 is Figure 4 a schematic diagram of the system in use;

[0010] Figure 6 isFigure 4 Schematic diagram of two containers running on an HSM device;

[0011] Figure 7 Flowchart showing a method of communicating using a hardware security module device according to an embodiment;

[0012] Figure 8 Shows in Figure 4 Schematic diagram of two virtual machines running on an HSM device. Detailed implementation

[0013] According to a first aspect, there is provided a device comprising:

[0014] An input; and

[0015] A plurality of processing modules, the plurality of processing modules including a first processing module and a second processing module, the device being configured to:

[0016] In response to a first command received through the input, perform a cryptographic operation corresponding to the first command on the first processing module;

[0017] In response to a second command received through the input, perform a cryptographic operation corresponding to the second command on the second processing module.

[0018] In one example, the device is further configured to:

[0019] In response to a first request received through the input, run a first isolated environment on the first processing module, and in response to the first command, perform a cryptographic operation corresponding to the first command in the first isolated environment;

[0020] In response to a second request received through the input, run a second isolated environment on the second processing module, and in response to the second command, perform a cryptographic operation corresponding to the second command in the second isolated environment.

[0021] In one example, the device is further configured to: identify the first request as corresponding to a first user, and identify the second request as corresponding to a second user.

[0022] In one example, the device is further configured to:

[0023] Establish a first secure connection with the first user in the first isolated environment, and in response to receiving the first command through the first secure connection, perform an operation corresponding to the first command;

[0024] Establish a second secure connection with the second user in the second isolated environment, and in response to receiving the second command through the second secure connection, perform an operation corresponding to the second command.

[0025] In one example, the device is further configured to: receive a representation of computer program code embodying a cryptographic algorithm, and wherein the operation corresponding to the second command includes executing the program.

[0026] In one example, the first processing module is an integrated circuit and the second processing module is an integrated circuit.

[0027] In one example, the first processing module includes a microprocessor and a random access memory (RAM), and the second processing module includes a microprocessor and a random access memory (RAM).

[0028] In one example, at least one of the first processing module or the second processing module includes a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and wherein at least one cryptographic operation is implemented directly in the hardware of the ASIC or FPGA.

[0029] In one example, the device further includes a non-volatile memory component, and wherein the plurality of processing modules are configured to access the non-volatile memory component.

[0030] In one example, the device further includes a third processing module, and wherein the third processing module is configured to manage the processing modules.

[0031] In one example, the third processing module communicates bi-directionally and wired with the non-volatile memory component, and wherein the other processing modules among the plurality of processing modules access the non-volatile memory component through the third processing module.

[0032] In one example, the first processing module and the second processing module use a reduced instruction set computer (RISC) microprocessor architecture.

[0033] In one example, the first processing module and the second processing module include a system on chip.

[0034] According to another aspect, a method of performing cryptographic operations on a device is provided, the device including an input and a plurality of processing modules, the plurality of processing modules including a first processing module and a second processing module, the method including:

[0035] Performing, in response to a first command received through the input, a cryptographic operation corresponding to the first command on the first processing module;

[0036] Performing, in response to a second command received through the input, a cryptographic operation corresponding to the second command on the second processing module.

[0037] According to another aspect, a carrier medium is provided, including computer-readable code configured to cause a computer to execute the method.

[0038] Figure 1 FIG. Figure 1 is a schematic diagram of a system including a hardware security module (HSM) 1 according to a comparative example. The figure shows the hardware security module 1, which can be used to perform one or more cryptographic functions for multiple clients. Throughout the description, the term "client" is used to refer to a user of the HSM device 1. The user may also be referred to as a "tenant".

[0039] The HSM device 1 is located in the host system 9. The host system 9 can be, for example, a service provider system. The HSM 1 is communicatively coupled to a computer or server device (referred to herein as the host device 4) in the host system via a host interface 5.

[0040] A first client device 2 separated from the host system 9 is located at a remote location from the host system 9. The first client device 2 is communicatively coupled to the host device 4 in the host system 9 and is thus communicatively coupled to the HSM device 1 via the host device 4. A second client device 3 separated from both the host system 9 and the first client device 2 is also located at a remote location from the host system 9 and at a remote location from the first client device 2. The second client device 3 is communicatively coupled to the host device 4 in the host system 9 and is thus communicatively coupled to the HSM device 1 via the host device 4.

[0041] The HSM 1 includes a central processing unit (CPU) 8. The CPU 8 includes logic circuitry that responds to and processes computer program instructions in code stored in the working memory. The CPU 8 can be an NXP T1042 processor, for example, including four e550 PPC cores.

[0042] The working memory includes a RAM 7. When executed, a program is represented as a software product or process stored in the working memory. The "core program" is mentioned in the following description. The core program includes computer instructions embodying a set of one or more cryptographic functions. For example, the core program includes computer instructions embodying one or more of the following cryptographic functions: cryptographic key generation; cryptographic key derivation; encryption; decryption; and digital signature functions (such as digital signature or digital signature verification).

[0043] The HSM device 1 also includes a board support processor 10, which is configured to communicate with multiple on-board sensors and monitor the operation and security of the CPU 8 and other hardware components of the hardware security module 1.

[0044] The HSM device 1 also includes an encryption coprocessor 9. The encryption coprocessor 9 performs specific cryptographic operations in hardware. A request to perform an operation is passed from the CPU 8, and the encryption coprocessor 9 returns a response to the request to the CPU 8.

[0045] Figure 2It is a schematic diagram of a system in use. As shown in the figure, multiple containers 22 to 25 are running on the HSM device 1, and each container is associated with a different client. Specifically, the first container 22 is associated with the first client "Tenant 1". The first client "Tenant 1" uses the first client device 2. The second container 23 is associated with the second client "Tenant 2", and so on. Each container includes a group of one or more processes isolated from the rest of the system. Figure 3 A schematic diagram of two containers running on the HSM device 1 is also shown. The figure shows the operating system kernel, the container engine, and the first container 22 and the second container 23 sharing the operating system kernel running on the CPU 8. The first container 22 includes Application 1, Application 2, and the support files for these applications. The second container 23 includes Application 1, Application 2, and the support files for these applications.

[0046] When the first client wishes to use the HSM device 1, a request is sent from the first client device 2 to the host device 4. The host device 4 sends a request to the HSM device 1. The container engine running on the HSM device 1 starts the first container 22. The container engine retrieves the container image from the non-volatile memory 6 and then makes one or more API calls to the operating system kernel. The kernel implements the isolation of the first container 22 and enforces the network connection available to the first container 22. The kernel, together with the memory management unit in the CPU 8, allocates a portion of the RAM 7 to the first container 22.

[0047] Then the network address of the first container 22 is sent to the client device 2. In this way, the client device 2 can establish communication with the first container 22 through the host device 4 using the network address of the first container 22. A secure connection can be established between the client device 12 and the first container 22. The secure connection can be established by the secure connection process running in the first container 22 and the secure connection process running on the client device 2. The secure connection can be established using the SSH protocol. Via the host device 4, data is exchanged between the client device 2 and the first container 22 running in the HSM 1 using the virtual network connection between the host device 4 and the first container 22.

[0048] Once the first container 22 is running and the secure connection is established, requests are sent from the client system 2. These requests correspond to the execution of one or more cryptographic functions, such as: cryptographic key generation; cryptographic key derivation; encryption; decryption and digital signature functions (such as digital signature or digital signature verification). The HSM device 1 runs the core program process inside the client container 22, and the core program process executes the commands given to it by the client.

[0049] In some scenarios, in addition to sending requests to execute functions provided by the core program, a user can also provide code to the HSM device 1, which embodies functions not provided by the core program. Then, the HSM device 1 will execute the user code within the user container 22 or within a second container associated with the same user (optionally subject to some security checks).

[0050] The HSM device 1 uses software boundaries to separate shared hardware resources among users to mitigate the possibility that tenants who do not trust each other may attempt to obtain each other's secret information. In Figure 2 the example, containers are used to implement the software boundary. Alternative examples may use virtual machines or the like. The HSM device 1 includes a single processor 8 and uses software boundaries to separate hardware resources among users and mitigate the acquisition of each other's secret information by tenants who do not trust each other.

[0051] However, the underlying hardware resources, including the CPU 8, are shared among users. As described above, in some scenarios, a user can provide code to the HSM device 1. Since the CPU 8 is shared among users, a malicious user may attempt to provide code to obtain information from another user or prevent the correct execution of its operations using a microarchitecture attack (such as exploiting a cache timing attack).

[0052] Figure 4 is a schematic diagram of a system including a hardware security module 11 according to an embodiment. The HSM 11 can be used for the secure processing of cryptographic keys, where multiple users who do not trust each other will share the same HSM 11, in other words, a multi-tenant implementation.

[0053] The HSM device 11 is located in the host system 9, such as a service provider system. The HSM 11 is communicatively coupled to the host computing device 4, such as a general-purpose computer or server device 4 in the host system, via the host interface 17. For example, the HSM device 11 can be a PCI-express card that is directly inserted into the PCI-express card slot of the host device 4. Alternatively, the HSM device 11 can be coupled, for example, via a USB connection. The host system 9 can include a large number of HSM devices coupled to the host computing device 4. In some examples, the host device 4 can include a router or a combined router and firewall instead of a general-purpose computer or server. In some examples, the host device 4 can be an Ethernet connected to, for example, the HSM 11 instead of a PCIe connection.

[0054] In this example, a first client system 2 separated from the host system 9 is located at a remote location from the host system 9. The first client system 2 includes, for example, a general computer device or a server device. The first client system 2 is communicatively coupled to a host device 4 in the host system 9 and is thus communicatively coupled to the HSM device 11 through the host device 4. Communication between the first client system 2 and the host system 9 is carried out through a communication network. Communication between the first client system 2 and the host system 9 can be carried out through, for example, an Internet connection. A second client system 3 separated from the host system 9 is located at a remote location from the host system 9 and the first client system 2. The second client system 3 includes, for example, a general computer device or a server device. The second client system 3 is communicatively coupled to a host device 4 in the host system 9 and is thus communicatively coupled to the HSM device 11 through a computer or server device 4 in the host system 9. Communication between the second client system 3 and the host system 9 is carried out through a communication network. Communication between the second client system 3 and the host system 9 can be carried out, for example, via an Internet connection. It should be understood that one, two, or more than two clients can use the HSM device 11 simultaneously. In addition, in some alternative examples, there is no host device 4 and one or more client devices are directly connected to the HSM 11.

[0055] The HSM 11 includes a plurality of processing modules 8a to 8f. In this example, six processing modules are shown, but it should be understood that two or more processing modules are included in the HSM 11. For example, a large number of processing modules can be included, such as more than 10, more than 50, or more than 100. Each of the processing modules 8a to 8f includes a processor.

[0056] In one example, processing modules 8a to 8f are all chips or integrated circuits, including a set of electronic circuits located on a single semiconductor material. For example, the processing modules are all system-on-a-chip (SoC). For example, the HSM device can be a PCI-express card, on which multiple processor chips 8a to 8f are installed. In one example, processing modules 8a to 8f are all NXP i.MX 8M Mini SoloLite, which includes an Arm Cortex-A53 core. In some examples, the processor can include multiple processing cores. For example, processing modules 8a to 8f can all be NXP i.MX 8M Mini Quad, which is a quad-core implementation including an Arm Cortex-A53 core. The processing module can include an FPGA. For example, processing modules 8a to 8f can all be Xilinx Zynq-7000 system-on-a-chip (SoC). Different components can be used for different processing modules. For example, one or more of processing modules 8a to 8f can include a single-core processor, and one or more of the other processing modules 8a to 8f can include a multi-core processor.

[0057] One or more of processing modules 8a to 8f can be off-the-shelf processors, such as the type used for embedded devices such as mobile devices or set-top boxes. One or more of processing modules 8a to 8f can include a processor configured with a reduced instruction set computer (RISC) architecture.

[0058] Processing modules 8a to 8f all include a microprocessor. One or more of processing modules 8a to 8f can also include a graphics processor in addition to the microprocessor. One or more processing modules can also include one or more interface blocks, such as for network connection or USB connection.

[0059] One or more of the processing modules are low-power processing modules. For example, the processing module can perform less than or equal to 14,000 RSA-2k operations per second. The processing module can perform less than or equal to 10,000 RSA-2k operations per second. The processing module can perform less than or equal to 5,000 RSA-2k operations per second. The processing module can perform less than or equal to 1,000 RSA-2k operations per second.

[0060] Each processor in the processing module runs an operating system, such as the Linux operating system. The Linux operating system includes system software that manages the hardware and software resources of the HSM device 11 and acts as an intermediary between programs (applications) and the HSM hardware. It can be understood that the processor can support other operating systems.

[0061] In this example, one of the processing modules, 8d, is designated as the management processing module 8d.

[0062] The management processing module 8d communicates bidirectionally and wiredly with the host interface component 17. The management processing module 8d is configured to receive user requests through the host interface 17. The management processing module 8d accesses the interface 17. The interface 17 can be a single component or can include various components. The HSM 11 is coupled to the host device 4 through the host interface 17. The host interface 17 can include a communication port, for example, the communication port provides a PCI-e bus connection to the host device 4.

[0063] The management processing module 8d communicates bidirectionally and wiredly with each of the other processing modules 8a, 8b, 8c, 8e, and 8f. For clarity in the figure, only the connections between the first processing module 8a and the management processing module 8d, and between another processing module 8e and the management processing module 8d are shown. However, it can be understood that each processing module has such a connection. In one example, the interconnection between the management processing module 8d and the other processing modules is via a network interface (such as Ethernet). For example, an isolated network can be implemented behind the management processing module 8d, where the management processing module 8d relays the data packets received through the host interface 17 to the other processing modules. In an alternative example, there is no designated management processing module, and the network is connected to the host interface 17 such that the data packets are sent directly to the relevant processing modules (instead of via the management processing module).

[0064] The processing modules 8a to 8f each include a random access memory (RAM), in other words, each processing module 8a to 8f has its own RAM instance. The RAM corresponds to the working memory of the processors in the processing modules 8a to 8f. The processing modules 8a to 8f can also each include a working memory, which includes processor registers. For example, the processors in the processing modules include their own registers and processor caches. These can be designated as L1, L2, and L3 caches according to their positions within the chip. Each processor can also include logic circuitry that responds to and processes the instructions in the code stored in the working memory. When executed by one of the processors, the program is represented as a software product or process stored in the working memory. Executing various programs by one or more processors will result in the implementation of the methods described herein.

[0065] In this example, the processing modules 8a through 8f each further include a non-volatile storage device. The non-volatile storage device in each of the processing modules 8a through 8f includes one or more of the following: an HSM device 11 and / or a unique identifier of the processing module; program code (such as a bootloader, an operating system, and / or an HSM core program); and secret information for each processing module. In one example, one or more public keys (such as a manufacturer's public key or the public key of some other trusted party) are directly stored in the non-volatile storage device in each of the processing modules 8a through 8f. Then, this key is used to verify whether the code has been signed by a trusted party before it is executed on the processor. In this example, each of the processing modules 8a through 8f includes information that uniquely identifies the processing module, and information that attests to the source of the information that identifies the processing module as a trusted party - for example, this can include a digital signature generated using the manufacturer's private key or the private key of some other trusted party. The information that uniquely identifies the processing module and the information that attests to the source are collectively referred to as authorization.

[0066] The processing module non-volatile memory can include any form of non-volatile memory (such as flash memory). The non-volatile memory can be physically secure and resistant to tampering by a third party, for example, by including physical security (such as a film covering the entire device) that cannot be removed without destroying the underlying physical hardware, rendering it unusable. Additional security measures can be applied to the non-volatile memory, such as encrypting at least some of the data stored in the non-volatile memory. In this example, most of the data stored in the non-volatile memory of the processing module is either saved in a signed form to guarantee integrity (for example, this includes information such as an operating system), or saved in an encrypted form to guarantee confidentiality (this includes information such as authorization). Only any unique secret information used to sign or encrypt the data is further protected. Such protective measures can at least partially rely on information stored elsewhere within the HSM 11 (such as in a fuse or a secure area on the silicon wafer on which the processing modules 8a through 8f are mounted). In one example, a unique secret information is stored in the HSM 11, which can be a key, a part of a key, or can be combined with other secret information (for example, it can be located elsewhere in the HSM or on a separate device) to derive a key through a key derivation function (KDF). Then, this key is also able to unlock other encrypted data stored in the non-volatile storage device, or for example, able to sign data.

[0067] In this example, the HSM 11 also includes a shared non-volatile storage device 6. The management processing module 8d communicates with the shared non-volatile storage device 6 in a wired two-way manner. In some examples, other processing modules may also communicate with the shared non-volatile storage device 6 in a wired two-way manner, or they may access the shared non-volatile storage device 6 through the management processing module 8d.

[0068] The shared non-volatile memory 6 may include any form of non-volatile device memory (such as flash memory, optical discs, or magnetic hard disks). The shared non-volatile memory 6 may also be physically secure and resistant to tampering by third parties, for example, by including physical security measures (such as a film covering the entire device). Additional security measures may be applied to the shared non-volatile memory 6 again, such as encrypting at least some of the data stored in the shared non-volatile memory 6. In this example, most of the data stored in the shared non-volatile memory 6 is saved in a signed form again to ensure integrity (for example, this includes information such as the operating system), or in an encrypted form to ensure confidentiality (this includes information such as system keys). Only the unique secret information used to sign or encrypt this data is further protected. Such protection measures also rely at least in part on information stored elsewhere within the HSM 11 (such as in fuses or secure areas on the silicon wafer where the processing modules 8a to 8f are installed). In one example, a unique secret information is stored in the HSM 11 (the secret information may be a key, a part of a key, or data that can be combined with other secret information (for example, it may be located elsewhere in the HSM or on a separate device) to derive a key through a key derivation function (KDF). Then, this key can unlock other encrypted data or signed data stored in the shared non-volatile storage device 6.

[0069] In this example, the shared non-volatile storage device 6 stores system data and data for each container.

[0070] The data for each container includes information associated with the container. This is packaged into a single file, also known as a container image. Various known formats of the files in the container image can be used, such as the Docker V2 image manifest. One or more files corresponding to the container are stored in the shared non-volatile memory 6 of the HSM device 11. In other words, the data for each container corresponds to one or more container images. At runtime, the container image becomes a container.

[0071] A container is an example of an isolated environment. A container isolates one or more running processes from the rest of the system. A container image includes program code corresponding to the program to be run in the container (or a reference allowing retrieval of the relevant program code). In this example, this includes the core program (or a reference to the core program) and an SSH server. The container image also includes all libraries, support files and programs, and any language interpreters required to run these programs. This means that when the container runs, the program can run without accessing files outside the container.

[0072] As described above, the data for each container includes the core program, or information identifying the core program used by the container.

[0073] The core program includes computer instructions embodying a set of one or more cryptographic functions. For example, the core program includes computer program instructions embodying one or more of the following cryptographic functions: cryptographic key generation; cryptographic key derivation; encryption; decryption; and digital signature functions (such as digital signature or digital signature verification). These programs are referred to as "core programs", but typically these programs include a set of computer instructions stored in non-volatile memory on the HSM device 11 and embodying the functions described herein with respect to "core programs". The computer instructions or core program can be written in any of a variety of programming languages and can be stored on the HSM device 11 as compiled code. A "core program process" refers to the program in execution, in other words, it is a running instance of the core program. The core program can be embedded in the hardware security module 11 at the time of manufacture, or can be provided as a whole or in part after manufacture. For example, the core program can be introduced as a computer program product, which can be in the form of a download. Alternatively, an existing core program can be modified by an update or a plug-in. To enhance security, only software from trusted parties is accepted. This can be enforced using a digital signature process, and the software can be provided in a command by the host system device 4.

[0074] As described above, in some examples, the data for each container includes information for identifying the core program used by the container. This information can identify the version of the core program that the container is to use from among multiple versions of the core program on the HSM device 11 in the system data stored on the shared non-volatile memory 6. For example, the system data on the shared non-volatile storage device 6 can store a set of core program images, such as to provide different functions or software versions. The data for each container can include a reference to the core program image that the container is to use. At runtime, the identified core program image is then loaded into the container. Alternatively, the information can include attributes of the core program, such as "latest version" - in which case, when the container is run, the latest version that matches the attribute is retrieved. Thus, the HSM 11 can have a "core program version library" in the system data on the shared non-volatile memory 6, which contains a copy of each supported core program version. Then, the data for each container on the shared non-volatile memory 6 indicates which version it is using, and based on the indication, that version is retrieved and loaded into the container at runtime. The host system administrator can access the core program version library and can add and / or remove core program versions from the library, thereby managing the core program versions available to the clients and controlling the versions available to the clients.

[0075] The data for each container on the shared non-volatile memory 6 can also include information for establishing a secure connection. For example, the data for each container can include a private key from a public-private key pair - which is hereinafter referred to as the second private key. The data for each container can also include a program for establishing a secure connection. For example, the Secure Shell (SSH) protocol can be used to provide a secure connection. The data for each container includes an SSH server as well as an SSH key pair, for example, the SSH key pair can be specific to the container. The SSH server is a program that uses the Secure Shell protocol to accept connections, which will be described in more detail below.

[0076] In this example, the container image does not include user secret information, such as user keys. The container image can run for any user. In other words, one or more general-purpose container images that can be used by any user are stored in the shared non-volatile storage device 6. When a client request is received, a container is started on the processing module using the general-purpose container image. Once running, as a separate step, the container is provided with client-specific information, such as one or more master keys associated with the client.

[0077] However, in other examples, the container image is associated with a specific client. When a client request is received, the container corresponding to the client is identified and launched on the processing module. In this case, the container image can also store one or more master keys associated with the client. The data of each container can also include information for establishing a secure connection with the specific client in this example - for example, the public key from the client's public-private key pair, where the private key can only be accessed by the corresponding client. The public key can be used to authenticate the client. The master key can include a symmetric key that serves as the root of the "application" key, as will be described in more detail below.

[0078] Each container can also use its own cryptographic key (referred to herein as the container key) to encrypt the information stored in the container. The container key can encrypt the entire container file, or it can encrypt certain data in the container file. For example, when the container is specific to a particular client, the container key can encrypt one or more user master keys. The container key is stored in the hardware security module 11. For example, the container key can be stored in the system data in the shared non-volatile memory 6. In one example, the container key is split into multiple separate parts, and the separate parts of the container key are stored in different components of the hardware security module 11. For example, the container key is split into three parts, and each part of the container key is stored in one of the system data in the non-volatile storage areas of the shared non-volatile storage device 6, the board support processor 10, and the processing modules 8a to 8f. When access to the container data is required, the separate parts are combined in the working memory of the processing module to form the final container key. Splitting the container key into different parts makes it more difficult to extract the complete key by physically disassembling the HSM device 11.

[0079] The system data stored in the shared non-volatile storage device 6 can include, for example, the serial number of the hardware security module, the manufacturer's certificate, and any keys associated with the manufacturer's security key. The system data also includes the boot loader and the operating system image, such as binary executable files. In this example, the boot loader and the operating system image are stored on the shared non-volatile memory 6 and are network-booted onto each processing module, and the management processing module 8d acts as a boot service, for example, using the Preboot Execution Environment (PXE) process. In other examples, the boot loader and the operating system image can be additionally or alternatively stored on, for example, the non-volatile storage device on each processing module.

[0080] In this example, one or more of processing modules 8a through 8f further include a security engine. For example, when the processing module is a chip, the processing module may include a security engine within the chip. For example, when the processing module is an NXP i.MX 8M, the processing module may include a security engine implemented on an application specific integrated circuit (ASIC). When the processing module is a Xilinx Zynq-7000 system-on-chip (SoC), the processing module may include a security engine implemented on a field programmable gate array (FPGA). The Xilinx Zynq-7000 system-on-chip (SoC) combines the SoC and the FPGA into one device. The security engine may be an encryption coprocessor. In some examples, management processing module 8d does not include an encryption coprocessor, while the other processing modules include an encryption coprocessor.

[0081] The encryption coprocessor directly implements specific cryptographic operations in hardware. The encryption coprocessor is configured to receive requests from the processor to perform one or more operations and return the output of the operations to the processor. The processor is configured to offload various operations to the encryption coprocessor. The encryption coprocessor is separate from the processor but is included in the processing module together with the processor, such as both being mounted on the same chip. The encryption coprocessor is configured to perform certain operations in hardware, which means that these operations can be performed more efficiently on the encryption coprocessor than on the processor. The operations can be performed on the encryption coprocessor simultaneously with the operations performed on the processor. The encryption coprocessor may include an application specific integrated circuit (ASIC) or an FPGA that has specific operations efficiently implemented directly in hardware. Specifically, the ASIC may include fixed logic circuitry configured to perform the operations such that the operations are directly implemented in hardware. The FPGA may include programmable logic circuitry configured to perform the operations such that the operations are directly implemented in hardware. In this example, except for the management processing module, processing modules 8a through 8f each include its own encryption coprocessor. Processing modules 8a through 8f do not share an encryption processor.

[0082] The HSM device 11 further includes a shared board support processor 10. The board support processor 10 communicates bi-directionally by wire with each of the processing modules 8a through 8f. Although only the connection with the management processor 8d is shown in the figure for clarity, it can be understood that each of the processing modules 8a through 8f may have such a connection. The board support processor 313 is configured to communicate with a plurality of on-board sensors and monitor the operations of the processing modules 8a through 8f and other hardware components of the hardware security module 11. The sensors may include, but are not limited to, CPU and / or on-board temperature sensors, voltage and / or current sensors. Optionally, a second board support processor may be included in the host device 4.

[0083] Figure 5It is a schematic diagram of a system in use. As shown in the figure, multiple containers are running on the HSM device 11, where each container is associated with a different client, and each container runs on a different processing module. Specifically, the first container 52 is associated with the first client "Tenant 1" and runs on the first processing module 8a. The first client "Tenant 1" uses the first client device 2. The second container 53 is associated with the second client "Tenant 2" and runs on the second processing module 8b. Each container includes a set of one or more processes isolated from the rest of the system. Each container runs on a separate processing module.

[0084] When the first client wishes to use the HSM device 1, a request is sent from the first client device 2 to the host device 4. The host device 4 sends a request to the HSM device 1 to run a container on the first processing module 8a. The container engine process running on the first processing module 8a in the HSM device 11 starts the first container 52. In this example, the management processing module 8d retrieves the container image from the shared non-volatile storage device 6 and provides it to the container engine running on the first processing module 8a. Then, the container engine makes one or more API calls to the operating system kernel running on the first processing module 8a. The kernel enforces the network connections available to the first container 52. Then, the network address of the first container 52 is sent to the client device 2. In this way, the client device 2 can use the network address of the first container 52 to establish communication with the first container 52 through the host device 4 and the management processing module 8d. A secure connection can be established between the client device 12 and the first container 52.

[0085] Once the first container 52 is running and a secure connection is established, requests are sent from the client system 2. These requests correspond to performing one or more cryptographic functions, such as: cryptographic key generation; cryptographic key derivation; encryption; decryption, and digital signature functions (e.g., digital signature or digital signature verification). The requests are generated using a communication protocol. The HSM device 11 runs a core program process inside the client container 52 on the first processing module 8a, and this core program process executes the commands given to it by the client.

[0086] In some scenarios, in addition to sending requests to perform functions provided by the core program, the user is also able to provide the HSM device 1 with code that embodies functions not provided by the core program. Then, the HSM device 11 will execute the user code (optionally subject to some security checks) inside the user container 52 on the first processing module 8a. Alternatively, a separate container can be run on a different processing module to run the user code in order to provide hardware separation between the core program and the user code.

[0087] The HSM device 11 uses separate hardware components for different users to mitigate the possibility that tenants who do not trust each other may attempt to obtain each other's secret information. In Figure 5 the example, each user corresponds to a different processing module with a different processor. Each of the first processing module 8a and the second processing module 8b runs a separate container. In this example, only a single container runs on each processing module at a time. Each processing module has only one tenant. When a request is received from a client, a container can be run as needed.

[0088] Figure 7 A flowchart of a method of communicating using a hardware security module device according to an embodiment is shown. The method can be performed using a hardware security module device, such as the device shown above Figure 4 and Figure 5 .

[0089] In step 501, the device 4 in the host system 9 receives an initial request from the first client system 2. The initial request includes information identifying the client 1. The host system device 4 stores a lookup table such that the processing module in the HSM device 11 corresponding to a specific client can be identified. For example, the host system device 4 stores a lookup table in which the information identifying each registered client is associated with the information identifying the corresponding processing module. The host system device 4 sends a request to the HSM device 11 to run a container on the processing module identified as corresponding to the client - in this case, the first processing module 8a. The request includes the information identifying the processing module corresponding to the client. The HSM 11 receives the request through the host interface 17 and directs it to the management processing module 8d. The client can specify a particular container (e.g., a particular version corresponding to a core program), in which case this is also specified in the request.

[0090] In step 502, a container is started on the identified processing module 8a in the HSM device 11. When the HSM device 11 receives a command to start a container on the identified processing module, the startup program running on the management processing module 8d receives the request and starts the container on the identified processing module. This involves providing a command to start the corresponding container to the container engine executing on the processing module. Various known container engines can be used. Examples of container engines include Docker, Linux LXC, and Linux LXD. The management processing module 8d assigns a container image to the identified processing module. In this example, the container image is assigned to the first processing module 8a. The startup program running on the management processing module 8d retrieves the container image from the shared non - volatile storage device 6 and provides it to the first processing module 8a.

[0091] The container engine running on the first processing module 8a receives a container image and makes one or more API calls to the operating system kernel running on the first processing module 8a. The kernel implements container isolation and enforces the network connections available to the container. The kernel, together with the memory management unit within the first processing module 8a, also allocates a portion of the RAM within the first processing module 8a to the container. The RAM is allocated to each container based on the resources required by the container in order to correctly execute the corresponding core program process and other processes.

[0092] The files in the container image are loaded into the allocated portion of the RAM. When the core program is identified by a reference stored in the container image (rather than being part of the container image), the core program identified by the corresponding container image stored in the shared non-volatile memory 6 is loaded into the container. The indication of the core program version stored in the container image is used to obtain the core program version from the core program version library that is part of the system data, and the container engine loads the selected core program version into the container space in the RAM of the first processing module 8a. When the indication of the core program version includes one or more attributes rather than a reference to a specific version, the program running on the HSM device 11 and provided by a trusted party will check the one or more attributes and select the core program version stored in the system data that most closely matches the specified attributes. For example, the client 1 can request that its container run "the latest version supporting V2 Security Worlds" or "the latest FIPS-approved version". Then a container corresponding to this request is selected in response to the client request. When the host system administrator adds a new version of the core program to the core program version library, if the container matches the attributes, the container will automatically include the core program process corresponding to the latest version of the core program.

[0093] The SSH server and the information for establishing a secure connection stored in the container image are loaded into the container from the container image. In this example, the information for establishing a secure connection with the client is subsequently loaded into the container in a separate step. For example, the shared non-volatile storage device 6 can include a public key corresponding to each client, which is retrieved using the information identifying the client in the initial request. Alternatively, the initial request can include the client public key.

[0094] As described above, in step 502, the startup program running on the management processing module 8d of the HSM device 11 receives the request and starts the container. This involves providing the container engine on the first processing module 8a with a command to start the container and the container file. Then, the container engine makes one or more API calls to the operating system kernel. The container file is loaded into a portion of the first processing module RAM corresponding to the container. This includes the secure connection process for establishing a secure connection and communicating over the secure connection.

[0095] Once the container is started, the launcher is configured to send information about the container to the client (via the host system device 4) to allow the client to connect to it, such as the network address of the container. This then allows a secure connection to be established with the container using the SSH protocol in step 503.

[0096] In this example, the HSM device 11 appears to the host system device 4 as if it were connected via a local area network. When the container is started, the network address of the container is sent to the client device. In this way, the client device can establish communication with the container using the network address of the container via the host system device 4 and the management processing module 8d. The communication from the client device is sent to the host system device together with the network address of the container. The host system then routes the communication to the container using this network address via the management processing module 8d.

[0097] In step 503, a secure connection is established between the client system and the container running on the first processing module 8a. The secure connection is established by a secure connection process running in the container on the first processing module 8a and a secure connection process running on the client system. The secure connection is established directly to the container running on the first processing module 8a within the HSM device 11. This means that the host system device 4 or the management processing module 8d does not have to separate the tunnel traffic and ensure that client commands are executed using the correct keys. An example process for establishing the secure connection will now be described. In this example, the SSH protocol is used to establish the secure connection.

[0098] The first SSH key pair includes a first private key at the client system and a first public key loaded into the container at the HSM 11. The SSH key pair includes a first private key and a first public key. The client device stores the first private key, while the first public key is loaded into the container. The first SSH key pair allows the container to verify that the connection is terminated by the correct client. The first public key can be provided in the initial request in step 501, in which case a registration process is performed. Alternatively, the first public key can be retrieved from the shared non-volatile storage of the HSM using the information identifying the client provided in the initial request in step 501.

[0099] Similarly, the second SSH key pair includes a second private key stored together with the container data. The second SSH key pair is also shared between the container and the client device. The second private key is stored with the container, and the second public key is registered with the client device. The public part of the second SSH key pair can be verified using the identity key of the hardware security module device, which is unique to the hardware security module. For example, the second public key is first sent to the client device together with a certificate signed by the identity key. The certificate can specify further information, such as the firmware version.

[0100] For example, the system data stored in the shared non-volatile storage device 6 includes the manufacturer's asymmetric key. The manufacturer can be a trusted party that manufactures the hardware security module. The system data in the shared non-volatile storage device 6 also stores a unique asymmetric identity key. This key is generated in the factory, for example, when manufacturing the HSM, and can be used to prove the origin and authenticity of the data. A key generation certificate for the identity key can also be stored, and this key generation certificate is signed using the manufacturer's private key. The key generation certificate can describe the public parameters of the key. For example, the key generation certificate can include information related to the key type and its length. The key generation certificate includes information for verifying that the identity key is generated in the HSM device. For example, the key generation certificate can include the hash value of the public part of the identity key and is signed by the private part of the manufacturer's key. The signature key generation certificate generated during manufacturing can be used to verifiably identify the HSM. It can securely store its identity so that it cannot be imitated.

[0101] The client system can use the public part of the manufacturer's key as the trust root to verify whether the hardware security module is a genuine device. In addition, the parameters and status of the hardware security module can be verified in a non-repudiable manner by exchanging certificates signed by the identity private key or the manufacturing private key. For example, the key generation certificate can be used to perform the initial step of verifying at the client that the identity key is generated in the processing module of the HSM device. As described above, the public part of the second SSH key pair can be verified by the identity key of the hardware security module device, which is unique to the hardware security module. For example, the second public key is first sent to the client device together with the certificate signed by the identity key.

[0102] The client device uses the Secure Shell (SSH) protocol to convey commands to the container running on the first processing module 8a in the hardware security module 11. Each client device includes an SSH process, also known as an SSH client. This process is a running instance of a program that uses the Secure Shell protocol to connect to a remote device, which in this case is the container running on the first processing module 8a in the HSM device 11. The private key part of the first SSH key pair is loaded into the memory space of the SSH process at the client device. The public key part of the second SSH key pair is also loaded into the memory space of the SSH process at the client device.

[0103] The container running on the first processing module 8a also includes an SSH process, also known as an SSH server. This process is a running instance of a program that uses the Secure Shell protocol to accept connections from the client system. The private key part of the second SSH key pair is loaded into the memory space of the SSH process running on the first processing module 8a. The public key part of the first SSH key pair is also loaded into the memory space of the SSH process.

[0104] In 503, using the network address of the container provided in 502, a request to establish a secure connection is sent from the client device to the container running on the first processing module 8a in the hardware security module 11. The request includes connection information. The connection information may include the client network address. It may also include information about the client identity, such as a username. The SSH client on the client device and the SSH server in the container running on the first processing module 8a both have corresponding network addresses. The host system, the operating system of the management processing module 8d, and the operating system of the first processing module 8a (on which the container runs) use these network addresses to ensure that SSH protocol messages are delivered to the intended processes. At least a part of the connection information sent from the client to the container is signed using the first private key. For example, in the SSH protocol, the client network address is not signed using the first private key, while the message content is signed using the first private key. The connection information may also include the identification of the port number of the hardware security module 11, which is used to indicate the type of service of the hardware security module requested by the client device. For example, the type of service of the hardware security module may be "management" or "primary". The "primary" service refers to the cryptographic functions performed by the hardware security module.

[0105] The connection information includes information for identifying the container targeted by the request, i.e., the network address of the container provided in 502. The operating system running on the management processing module 8d, the operating system running on the first processing module 8a, and the operating system running on the host system use this information to route connection messages between the client device and the corresponding SSH processes in the container running on the first processing module 8a.

[0106] The connection information is loaded into the memory space of the specified container running on the first processing module 8a. Specifically, the connection information is loaded into the working memory on the first processing module, in the memory space of the SSH process in the specified container. The SSH process running in the container on the first processing module 8a verifies the signature using the first public key. If the verification is successful, the container confirms that the connection between the client device and the corresponding container is verified. In other words, the container authenticates the client. If the signature is not verified, the connection is rejected and an error message is sent to the client system.

[0107] If the container acknowledges the connection, i.e., the client is authenticated, the container generates a response. The response includes the client network address so that it can be correctly routed. At least a portion of the response is signed using a second private key. For example, in the SSH protocol, the client network address is not signed using the second private key, while the content of the response is signed using the second private key. The response is sent from the HSM device 11 to the designated client system. The SSH process running in the client system verifies the signature using the second public key. If the verification is successful, the client system acknowledges that the connection between the client device and the corresponding container is verified. If the signature is not verified, the connection is rejected and an error message is sent to the container.

[0108] If both the container and the client system have verified the connection, a communication cipher key is generated in step 504 and exchanged between the container running on the first processing module 8a and the client system. For example, the client system can generate a symmetric key, encrypt the symmetric key using the second public key, and send the encrypted symmetric key to the container running on the first processing module 8a. The encrypted symmetric key is then loaded into the working memory of the first processing module 8a, in the memory space of the SSH process running in the container, and decrypted using the second private key. The decrypted symmetric key is then stored in the container data on the first processing module 8a. Encrypting communication using a symmetric key is more efficient than using an asymmetric key pair. The communication between the client system and the container is then encrypted using the symmetric key.

[0109] Client secret information (including one or more application keys) is stored encrypted outside the HSM. Once a secure connection is established, the client registers the container into the secure world. This includes loading one or more client master keys into the container. To load the master keys, the client may need to present various smart cards storing the master keys and may optionally enter a password to authenticate the use of the smart cards. The master keys associated with the client can be divided among two or more smart cards, and in order to register the associated container into the secure world, multiple of the two or more client smart cards need to be presented to the container. The master keys are combined with the authorization stored on the first processing module 8a. The encrypted client secret information (one or more application keys) is then retrieved from a remote location. The client secret information (one or more application keys) is then decrypted using the information generated by the combination of the client master key and the first processing module authorization and stored in the working memory of the first processing module for use. In other words, once the application keys are loaded into the container, the container is ready for use by the client.

[0110] In each secure world, the management card and the operator card work properly. For example, when the processing module 8a is first registered to the secure world, the management card can be presented to the hardware security module, and the operator card can be associated with a specific application key. The container may need to present the operator card in order to use the associated application key to authenticate certain operations.

[0111] In other examples specific to the client for the container image, one or more master keys are loaded from the container image.

[0112] The master key or keys define a "secure world" associated with the client. The term "secure world" refers to one or more security facilities (such as an HSM) or parts of a security facility (such as a container or a processing module) that share at least one private key and are configured to protect cryptographic keys and perform a set of cryptographic functions. Once running, each container can belong to a different secure world. Each processing module belongs to a different secure world. Thus, a deployment with many secure worlds can run with fewer HSMs because several secure worlds can be compressed onto one HSM. When requested by different clients, the secure worlds can run at different times.

[0113] In this example, the master key associated with the client is loaded into the container and used to retrieve the client application key. There are multiple cryptographic application keys associated with the client and used for the cryptographic functions embodied in the core program process. In this example, the application keys are securely stored outside the HSM device 11. In this example, the application keys associated with the client and used for the core program cryptographic functions are encrypted using information generated by the combination of authorization and the master key and stored outside the HSM device 11. In this example, the user password application keys are stored in binary format outside the HSM device 11. For example, the application keys can be encrypted using the Advanced Encryption Standard (AES). Alternatively, triple DES encryption can be used. Each application key can be associated with an access control list, which is also encrypted. The application key and the ACL are encrypted together, and the result is signed using the client master key. This forms a "key block". The encrypted and protected key block can be stored outside the HSM device 11, for example, on a smart card or a server storage device (such as a hard disk within the host system). When a client request is received, the application key is retrieved using the client master key and authorization and loaded into the RAM space of the core program process on the processing module corresponding to the authorization. The application key associated with the client device is used to perform one or more cryptographic functions embodied in the core program process.

[0114] When application keys are loaded into a container on a processing module, these keys are stored in the operating memory space of the core program process on the processing module. The application keys can be used to perform one or more functions, including performing various encryption and decryption operations and performing digital signature operations. The client master key and authorization are used to retrieve the application keys and load them into the container.

[0115] In 505, a command is sent from the client system to the hardware security module 11. In this example, the command corresponds to a cryptographic function embodied in the core program. The command is encrypted using a symmetric communication key. The message also includes information specifying the container that the command is directed to, i.e., the network address. The encrypted command is loaded into the memory space of the specified container, which in this case is the working memory of the first processing module 8a. Specifically, the encrypted command is loaded into the memory space of the SSH process in the specified container. The command is decrypted using the symmetric key. Then the decrypted command is loaded into the memory space of the core program process in the container, where the memory space is located in the working memory of the first processing module 8a. The core program process executes the command in 506 on the first processing module 8a. If the command fails to decrypt successfully, it is not passed to the core program process. In this step, the program instructions in the core program correspond to one or more of the following: cryptographic key generation; cryptographic key derivation; encryption; decryption; or performing a digital signature function (such as digital signature or digital signature verification) on the first processing module 8a. The program instructions can be executed using the application keys loaded into the memory space of the core program process on the first processing module 8a.

[0116] The HSM device 11 runs the core program process inside the container on the first processing module 8a, and the core program process executes the commands given to it by the client. For example, the host system receives a request from the client system via a secure connection in 505. The request corresponds to performing one or more cryptographic functions, such as: cryptographic key generation; cryptographic key derivation; encryption; decryption; and digital signature functions (such as digital signature or digital signature verification). The request is generated using a communication protocol. The request is routed to the container using the connection information.

[0117] In some cases, the core program process may require an additional level of authentication before it executes a command. For example, the core program process may require the client to present a smart card to the container and enter a password.

[0118] Then, the output of the core program process is passed to the SSH process. The output is encrypted using a symmetric key and sent to the client system. For example, if the client requests the generation of a new password key, the response will include the identifier of the new password key. If the client requests the decryption of text information using the password key, the response will include the decrypted text information. The client can also send a status check request, and the response will confirm whether the command has been successfully executed.

[0119] Once running, a container is a group of one or more processes isolated from the rest of the system. The container engine includes a set of program instructions that retrieve the container image in response to a command to start the container and start and run the container (the running process) by making one or more API calls to the operating system kernel. The HSM device 11 runs the "core program process" inside the container. Once running, each container includes a core program process associated with each client. The container provides multiple copies of the support files and libraries required to run the core program process, thus providing good isolation. In addition, the containers run on different processing modules, which means that the core program processes associated with each client run on separate processors and are therefore isolated in hardware. Each processing module runs its own copy of the core program process and runs in the memory space of each processing module. If a core program vulnerability results in the leakage of critical data (e.g., by leaking uninitialized memory content), only the critical data visible to a specific instance of that core program process may be compromised. Each container is isolated from other containers and has limited and well-defined dependencies on anything outside the container. In addition, one or more containers corresponding to a first client are isolated in hardware from one or more containers corresponding to a second client. Separate hardware components run the core program process for different users, where each user corresponds to a different processing module, which has a different processor and separate working memory.

[0120] Different versions of the core program can be used by different containers on different processing modules because each container includes the relevant support files and libraries required to run the processes needed for that container. Some clients can run an older version of the core program process, while other clients can run the latest version. The "core program" process running in each container does not need to be the same version of the code.

[0121] Figure 6Schematic diagram of two containers running on the HSM device 11. The figure shows a first operating system kernel 331 running on a first processing module 8a. A first container engine 330 runs on the first operating system kernel 331 and runs a first container 339. A second operating system kernel 334 runs on a second processing module 8b. A second container engine 333 runs on the second operating system kernel 334 and runs a second container 349. The first container 339 includes Application 1, Application 2, and the support files for these applications. The second container 349 includes Application 1, Application 2, and the support files for these applications. In addition, containers 339 and 349 run on different processing modules and thus use different operating system kernels, as Figure 6 shown. Since the first container 339 and the second container 349 run on independent processing modules with independent working memories, there is hardware isolation in the memory spaces in which the containers 339 and 349 run. Containers can be used with various operating systems, but they are compatible with the underlying operating system.

[0122] A secure connection between the container and the client system means that the host system administrator cannot read or modify the command traffic between each client and the hardware security module. In addition, even in the case of a network configuration error, a client cannot read or modify the command traffic of another client. The secure connection enables the client device to communicate with the hardware security module and vice versa without relying on the correct direct traffic between them for security. For example, if the HSM device 11 erroneously sends data associated with Client 1 to Client 2, Client 2 will not be able to access the data because Client 2 does not have the necessary information to decrypt the data. If the management processing module 8d in the HSM device 11 erroneously sends a command from Client 1 to the Client 2 container, the Client 2 container will not be able to access the command because the Client 2 container does not have the necessary information to decrypt the command. Therefore, the command will not be executed.

[0123] The secure channel allows for separation between the communication channels of different clients and restricts the host system administrator's access to the data being communicated between the client device and the hardware security module 21. For example, the first container running on the first processing module 8a shares a communication key with the client device 1, while the second container running on the second processing module 8b shares a communication key with the client 2. The communication key allows the HSM container to verify whether a command sent to the first container was indeed sent by Client 1. It is impossible for Client 2 to send a command to exploit a vulnerability in the core program running in the first container because Client 2 and the first container do not share a communication key. In addition, it is impossible for Client 2 to simply send a command that normally uses the key loaded in the first container because Client 2 and the first container do not share a communication key.

[0124] Role separation is provided between the host system roles (including network and hardware management) and the security management role, as each client retains control of the keys and cards. Smart cards can be used to transfer security world keys, such as to a new HSM device joining the security world, to a new processing module joining the security world, or to a new container joining the security world. The key data is split across a number of smart cards and loaded from the smart cards into the HSM, processing module, and / or container. When a new container joins the security world, the security world is associated with that container rather than with the entire HSM. A secure tunnel is used to load the keys from the smart card into the container. Additionally, since the network traffic uses a secure tunnel, the host system cannot access the commands and data.

[0125] When a new client wishes to register a hardware security module, a registration process is executed. To ensure that the initial system setup is secure and that a man-in-the-middle attack cannot be established by the system administrator, the registration process is protected by a "certificate" signed with the unique identity key of the module manufacturer. Using the manufacturer key to verify the registration ensures that the initial system setup is secure.

[0126] The client generates a first SSH key pair, which includes a first public key and a first private key. The first SSH key pair is associated with the client and identifies the client. The first public key is provided to the hardware security module 11. As previously mentioned, the first public key can be provided as part of the initial request related to step 501 above, in which case the following registration process is executed as part of the method related to Figure 5 the relevant method. Alternatively, it can be provided in a separate registration process and stored in the shared non-volatile memory of the HSM 6 for later use.

[0127] Information identifying the processing module in the HSM 11 as a trusted device is sent to the client.

[0128] For example, the processing module in the hardware security module 11 stores the manufacturer's asymmetric key. The manufacturer can be a trusted party that manufactures the hardware security module. The processing module also stores a unique asymmetric identity key. This key is generated, for example, at the factory when the HSM is manufactured and can be used to prove the origin and authenticity of data.

[0129] A key generation certificate for the identity key can also be stored, which is signed using the manufacturer's private key. The key generation certificate can describe the public parameters of the key. For example, the key generation certificate can include information related to the key type and its length. The key generation certificate includes information authenticating that the identity key was generated in the processing module in the HSM device. For example, the key generation certificate can include the hash value of the public part of the identity key and is signed with the private part of the manufacturer key. The identity key and the key generation certificate can form the processing module authorization.

[0130] A signature key generated during manufacturing can be used to generate a certificate, enabling the processing module to be verifiably identified as a trusted device. It can securely store its identity, making it impossible to be imitated. The client system can use the public key part of the manufacturer key as the trust root to verify whether the processing module in the hardware security module is a genuine facility. Additionally, by exchanging certificates signed by the identity private key or the manufacturer private key, the parameters and status of the processing module in the hardware security module can be verified in a non-repudiable manner.

[0131] For example, a certificate can be generated using a key. The initial step of authenticating the identity key at the client is generated in the processing module of the HSM device. Then, by using a combination of the authorization and the client master key, access to the client application key can be obtained.

[0132] In the above description, the isolated environment is a container. However, the isolated environment can also be a virtual machine. Figure 8 A schematic diagram showing two virtual machines running on the HSM device 11 is presented. The virtual machines include a set of one or more processes isolated from the rest of the system. In this case, a separate kernel runs in each virtual machine. The first virtual machine 1201 includes Application 1, Application 2, the support files for these applications, and the kernel. The second virtual machine 1202 includes Application 1, Application 2, the support files for these applications, and the kernel. The hypervisor includes software for creating and running virtual machines and acts as an intermediary between the virtual machines and the HSM hardware. The first hypervisor 1204 runs on the first processing module 8a. The first virtual machine 1202 runs on the first hypervisor 1204. The second hypervisor 1205 runs on the second processing module 8b. The second virtual machine 1202 runs on the second hypervisor 1205. The memory space in which the virtual machines run is isolated. Additionally, the virtual machines run on different processing modules and thus use different hypervisors, as shown in Figure 9.

[0133] In the above description, an isolated environment that can be run for any user is provided. In other words, a general container that can be used by any user is provided. When the host system device 4 receives a client request, the general container is launched on the processing module. Once running, the container is provided with client-specific information, such as the client password key or other information, as a separate step. However, in other examples, the container image is associated with a specific client. When a client request is received at the host system device 4, the container corresponding to the client is identified and launched on one of the processing modules.

[0134] In the above description, an isolated environment runs on each processing module. However, in other examples, the isolated environment is not used. For example, the core program can be stored in the non-volatile memory of each processing module. Then, in response to a client request, the core program is executed on the processing module.

[0135] In the above HSM device 11, instead of sharing the resources of one or more processors or cores, a separate processor is assigned to each user. Since a separate processing module is assigned to each user, microarchitecture attacks on shared hardware components within the processor are mitigated. Each tenant uses a smaller processor and can have exclusive use of that processor when running in the corresponding isolated environment. Since each tenant has a separate processor when running in the isolated environment, the security vulnerability of software errors leaking secret information between two tenants in the system can be mitigated. The system provides a degree of hardware separation and software separation, thus providing a higher level of security. This allows for the implementation of a multi-tenant system with a higher security level.

[0136] The HSM device 11 uses hardware separation, which includes separate processing modules where software controls the separation.

[0137] Multiple processing units can also provide a cost-effective alternative to using a single large processor. Since the system uses lower-cost and smaller processing modules, it can be scaled up, which means that many instances can be connected together to provide the same performance as a single, more expensive processor. Using lower-cost and smaller processing modules can be scaled up to high transaction volumes.

[0138] In the above with Figure 7In related examples, a user sends a command over a secure connection to a container running on the HSM device 11 to execute a function provided by a core program. The core program process runs inside a container on the HSM device 21 and executes a function corresponding to the received command. However, in some examples, the user is able to provide code to the HSM device 1 that embodies functions not provided by the core program. The HSM device 1 then executes the user code within the user container (optionally subject to some security checks). Such a system allows the user to execute custom code within the HSM device 11. As described above, since each user is assigned a separate processing module, microarchitectural attacks on shared hardware components within the processor can be mitigated. As described above, the system provides a degree of hardware separation, not just software separation, thus providing a higher level of security, especially when tenants are allowed to execute their own code on the HSM, such as within a secure execution environment. An example method of a user providing code to be executed on an HSM device is described in EP3952202 - An apparatus and method for performing cryptographic algorithms, the entire content of which is incorporated herein by reference. Specifically, in step 505 of the above example, a command is sent from the client system to the hardware security module 11, where the command corresponds to an encryption function embodied in the core program. In other examples, in step 505, first data including a representation of computer program code embodying a cryptographic algorithm is sent from the client system to the container. This can be sent as part of the command or separately. The program is then executed within the container.

[0139] Since each user is assigned a separate processing module, this allows for the secure implementation of a secure execution environment (SEE) similar to a software "sandbox" in a multi-tenant system. For example, an existing client can generate a new virtual machine to develop or test new program code in the HSM 1. For example, an existing client can set up a new virtual machine to act as a secure execution environment (SEE). This runs on a processing module not used by any other tenant. Thus, a SEE can be securely implemented in a multi-tenant system. Since they have their own hardware, there will be no software bugs that leak secrets between two tenants in the system, so it provides both hardware separation and software separation, providing a higher level of security, especially when tenants are allowed to execute their own code on the HSM within a secure execution environment.

[0140] In the above example, the HSM device 11 is located in the host system 9. In some examples, the host system 9 is a service provider system, where multiple client devices are connected to the service provider system via a communication network (e.g., the Internet). The HSM 11 service is provided by the service provider as a service, e.g., as Software as a Service to the clients. However, in an alternative system, the HSM is hosted in the client system, where multiple different client devices are connected to the HSM via the devices in the client system. In this case, the client system can be regarded as the host system. In such an example, the client controls the HSM.

[0141] In some examples, a single client can run multiple containers, each located on a different processing module, where the containers act as secure execution environments to execute client code. For example, the client can instruct the HSM to run a first container to execute a core program. Then, the HSM starts the first container on the first processing module and executes the core program within the first container. The client can request to run its own code in a container different from the first container. Then, the HSM starts the second container on the second processing module and executes the client code in the second container. In this way, the client code is isolated from the core program. For example, the above example relates to a multi-tenant scenario. However, in some alternative examples, the HSM is used by a single client, where different processing modules are used to execute different programs. Thus, hardware isolation between the programs is provided.

[0142] Although some embodiments have been described, these embodiments are presented by way of example only and are not intended to limit the scope of the invention. Indeed, the novel methods and devices described herein can be embodied in various other forms; furthermore, various omissions, substitutions, and changes can be made to the forms of the methods and devices described herein.

Claims

1. An apparatus, comprising: an input; and a plurality of processing modules, the plurality of processing modules including a first processing module and a second processing module, the apparatus being configured to: in response to a first command received via the input, perform a cryptographic operation corresponding to the first command on the first processing module; in response to a second command received via the input, perform a cryptographic operation corresponding to the second command on the second processing module.

2. The apparatus according to claim 1, the apparatus further being configured to: in response to a first request received via the input, run a first isolated environment on the first processing module, and in response to the first command, perform a cryptographic operation corresponding to the first command in the first isolated environment; in response to a second request received via the input, run a second isolated environment on the second processing module, and in response to the second command, perform a cryptographic operation corresponding to the second command in the second isolated environment.

3. The apparatus according to claim 2, wherein the apparatus is further configured to: identify the first request as corresponding to a first user, and identify the second request as corresponding to a second user.

4. The apparatus according to claim 3, wherein the apparatus is further configured to: establish a first secure connection with the first user in the first isolated environment, and in response to receiving the first command via the first secure connection, perform an operation corresponding to the first command; establish a second secure connection with the second user in the second isolated environment, and in response to receiving the second command via the second secure connection, perform an operation corresponding to the second command.

5. The apparatus according to any one of the preceding claims, wherein the apparatus is further configured to: receive a representation of computer program code embodying a cryptographic algorithm, and wherein the operation corresponding to the second command includes executing the program.

6. The apparatus according to any one of the preceding claims, wherein the first processing module is an integrated circuit, and the second processing module is an integrated circuit.

7. The apparatus according to claim 6, wherein the first processing module includes a microprocessor and a random access memory (RAM), and the second processing module includes a microprocessor and a random access memory (RAM).

8. The apparatus according to claim 7, wherein at least one of the first processing module or the second processing module includes a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC), and wherein at least one cryptographic operation is implemented directly in hardware in the ASIC or the FPGA.

9. The apparatus according to any one of the preceding claims, further comprising a non - volatile memory component, wherein the plurality of processing modules are configured to access the non - volatile memory component.

10. The apparatus according to claim 9, further comprising a third processing module, wherein the third processing module is configured to manage the processing modules.

11. The apparatus according to claim 10, wherein The third processing module communicates bi-directionally and wiredly with the non-volatile memory component, and wherein other processing modules among the plurality of processing modules access the non-volatile memory component through the third processing module.

12. The device according to any one of the preceding claims, wherein, the first processing module and the second processing module use a reduced instruction set computer (RISC) microprocessor architecture.

13. The device according to any one of the preceding claims, wherein, the first processing module and the second processing module comprise a system on chip.

14. A method for performing cryptographic operations on a device, the device comprising an input and a plurality of processing modules, the plurality of processing modules comprising a first processing module and a second processing module, the method comprises: performing a cryptographic operation corresponding to the first command on the first processing module in response to a first command received through the input; performing a cryptographic operation corresponding to the second command on the second processing module in response to a second command received through the input.

15. A carrier medium comprising computer-readable code configured to cause a computer to perform the method according to claim 14.

Images