阅读说明：本技术 硬件安全模块 (Hardware security module ) 是由 V·克鲁梅尔 P·京特 于 2019-11-05 设计创作，主要内容包括：根据一个实施例描述了一种硬件安全模块,具有：接收器,其被设置为接收用于执行密码操作的委托,和控制装置,其被设置为基于所述硬件安全模块的委托负荷决定是否应当外包一个或多个委托,并且如果应当外包一个或多个委托,则确定用于外包所述一个或多个委托的另外的硬件安全模块,认证所述另外的硬件安全模块并请求所述另外的硬件安全模块处理所述一个或多个委托。(According to one embodiment, a hardware security module is described having: a receiver arranged to receive a delegate for performing a cryptographic operation, and control means arranged to decide whether one or more delegates should be outsourced based on a delegation load of the hardware security module, and if one or more delegates should be outsourced, to determine a further hardware security module for outsourcing the one or more delegates, authenticate the further hardware security module and request the further hardware security module to process the one or more delegates.)

1. A hardware security module having:

a receiver arranged to receive a delegate for performing a cryptographic operation, an

A control device configured to

Deciding whether one or more of the delegates received by the hardware security module should be outsourced based on the delegation load of the hardware security module, and

if one or more of the delegates received by the hardware security module should be outsourced, determining a further hardware security module for outsourcing the one or more delegates,

authenticate the additional hardware security module and request the additional hardware security module to process the one or more delegates.

2. The hardware security module of claim 1, wherein the control means is arranged to configure the further hardware security module to perform the one or more delegations.

3. A hardware security module according to claim 1 or 2, wherein the control means is arranged to clone the configuration of the hardware security module to the further hardware security module to handle the one or more delegations by the further hardware security module.

4. A hardware security module according to any of claims 1 to 3, wherein the control means is arranged to send the one or more delegations to the further hardware security module by means of a peer-to-peer communication connection.

5. A hardware security module according to any of claims 1 to 4, wherein the control means is arranged to decide that the one or more commissions should be outsourced if the commissioning load of the hardware security module is above a pre-given threshold.

6. The hardware security module of claim 5, having a delegation queue, wherein the delegation load is a fill level of the delegation queue.

7. A hardware security module according to any of claims 1 to 6, wherein the control means is arranged to allocate the further hardware security module and to release the further hardware security module again after processing the one or more delegations.

8. A hardware security module according to any of claims 1 to 7, wherein the control means is arranged to determine the number of said one or more commissions that should be outsourced based on a commissioning load of the hardware security module.

9. Hardware security module according to any of claims 1 to 8, wherein the control means is arranged to decide to outsource delegation until a delegation load of the hardware security module falls below a pre-given threshold.

10. The hardware security module of any of claims 1 to 9, having a cryptographic unit arranged to perform cryptographic operations.

11. The hardware security module of any of claims 1-10, wherein each cryptographic operation has decryption, encryption, signature, and/or verification of a signature.

12. A hardware security module according to any of claims 1 to 11, wherein the control means is arranged to authenticate the further hardware security module based on a signature generated by the further hardware security module.

13. The hardware security module of any of claims 1 to 12, wherein the hardware security module and the further hardware security module have separate hardware for performing cryptographic operations.

Technical Field

Embodiments are generally related to hardware security modules.

Background

Security-related cryptographic operations can be outsourced to this specialized, secure hardware peripheral, the so-called Hardware Security Module (HSM). Depending on the application, the HSM may perform a large number of cryptographic operations, which may result in the HSM being overloaded, the delegations received by the HSM being stored in a queue and the delegating party (e.g., computer system) correspondingly having to wait for the delegated processing. Depending on the application, this may result in undesirable delays. It is desirable to avoid such delays.

Disclosure of Invention

According to an embodiment there is provided a hardware security module having a receiver arranged to receive delegates for performing cryptographic operations, and control means arranged to decide whether one or more delegates should be outsourced based on a delegation load of the hardware security module, and if one or more delegates should be outsourced, to determine a further hardware security module for outsourcing the one or more delegates, authenticate the further hardware security module and request the further hardware security module to process the one or more delegates.

Drawings

The drawings are not intended to reproduce actual dimensional proportions, but rather should be used to illustrate the principles of various embodiments. Various embodiments are described below with reference to the following drawings.

Fig. 1 shows a data processing device with a hardware security module.

Fig. 2 shows a data processing device with a plurality of hardware security modules.

Fig. 3 shows a hardware security module in more detail, which hardware security module for example corresponds to one of the hardware security modules of fig. 2.

FIG. 4 illustrates a hardware security module that may outsource one or more delegations to another hardware security module.

Detailed Description

The following detailed description refers to the accompanying drawings, which illustrate details and embodiments. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention. Further embodiments are also possible and these embodiments may be modified in structural, logical and electrical aspects without departing from the subject matter of the present invention. The different embodiments are not necessarily mutually exclusive, but the different embodiments can be combined with each other to create new embodiments. In the context of this specification, the terms "connected to …," "connected to," and "coupled" are used to describe both direct and indirect connections, direct or indirect connections, and direct or indirect couplings.

So-called Hardware Security Modules (HSMs) are commonly used in the following fields: in which security-related transactions take place, such as the exchange of secret data or data that does not allow counterfeiting or alteration.

Fig. 1 shows a data processing apparatus 100 with a Hardware Security Module (HSM) 101.

The hardware security module 101 is a peripheral device of a computer system 102, such as a server computer or a personal computer or a mobile data processing device, to which the hardware security module is connected via a communication connection 103. The hardware security module 101 may be located within the computer system 102 or an external device. Depending on the situation, the communication connection 103 may be, for example, a computer bus or a connection via a computer network.

The task of the HSM 101 is to perform cryptographic operations in a secure environment. The computer system 102 may send a delegate 104 for performing cryptographic operations in the form of a message to the HSM 101 via the communication connection 103, which the HSM 101 receives by means of a communication interface 105 corresponding to the communication connection 103 (i.e. which in this case operates as a receiver).

The HSM 101 processes the delegate 104. To this end, the HSM 101 has a cryptographic unit 106, which cryptographic unit 106 has data processing components such as a processor (CPU) 107 and a memory 108 and possibly other data processing components. After processing the delegate 104, the HSM 101 sends the result 108 of the processing 109 to the computer system 102 by means of its communication interface 105.

The HSM 101 may perform various cryptographic operations and implement various cryptographic algorithms therefor, e.g.

Asymmetric cryptographic methods, such as RSA (encryption or Signature), Diffie-Hellman rekeying, ECC (Elliptic Curve Cryptography), ECDSA (Elliptic Curve Digital Signature Algorithm)

Symmetric encryption and decryption: AES (Advanced Encryption Standard), DES (Data Encryption Standard), Triple-DES, IDEA (International Data Encryption Algorithm)

Cryptographic Hash functions, such as SHA-l (Secure Hash Algorithm-1 )

Generate random numbers, keys, and PINs (personal identification numbers; both physical and deterministic).

Depending on the case, the result 109 contains, for example, encrypted or decrypted data, signed data, a hash value, a cryptographic key (or key pair), a PIN, a random number, or a plurality thereof.

Security goals when using HSM 101 are typically confidentiality and authenticity of the cryptographic operations performed. These security goals are achieved through specialized hardware-based security mechanisms for the HSM 101, such as sensor and chip shielding (e.g., to prevent physical attacks on the chip from the back side of the chip). Hardware protection of other components, such as the computer system 102, may then be dispensed with. Thus, the implementation of these security objectives is typically only guaranteed by the cryptographic protocol and the mechanism by which its secure anchor is located in the cryptographic unit.

The HSM 101 may have a wide range of functionality for securely managing the HSM 101 and the data (e.g., cryptographic keys) stored thereby, among other things. Examples of this are the authentication of operators and administrators by hardware tokens (e.g. by means of chip cards or security tokens), the access protection based on the principle of multi-eye (e.g. access k from n persons is required), the encrypted backup of data (such as keys and configuration data) and the secure cloning of the HSM 101.

HSMs are typically designed as a single server with a fixed range of functions, fixed configuration, and set computing power. The change of configuration typically requires a complicated manual process to preclude manipulation of the respective device. Changes to the functional range are typically accompanied by firmware upgrades, which are also performed by manual processes. The performance of such HSMs cannot be changed throughout their lifetime, and the necessary performance increase can only be achieved by integrating other HSMs of the same type whose management and load distribution must be done through the infrastructure.

An HSM is thus provided according to various embodiments that provides the possibility to dynamically absorb overload (due to a large number of commissions or individual complex commissions) by adding other idle HSMs. After handling the overload, the additional HSM is released again.

Fig. 2 shows a data processing apparatus 200 with a plurality of Hardware Security Modules (HSMs) 201, 202, 203.

In this example, three HSMs 201, 202, 203 are provided, but only two or more HSMs may be provided.

The HSMs 201, 202, 203 are connected to each other via a communication connection 204, e.g. fully or only partially or according to a further topology such as a ring topology.

In this example, the HSMs 201, 202, 203 are connected with a plurality of computer systems 204, 205, 206, e.g., via a computer network 207. However, they may also be at least partially provided in the computer systems 204, 205, 206 and connected to each other via a communication connection between the computer systems 204, 205, 206. The communication connections between the HSMs 201, 202, 203 and each other and between the HSMs 201, 202, 203 and the computer systems 204, 205, 206 are, for example, corresponding computer buses or network connections.

Each HSM 201, 202, 203 has, for example, the functions and mechanisms described above for HSM 101. In particular, each HSM 201, 202, 203 provides a secure environment for the execution of cryptographic operations. To this end, each HSM 201, 202, 203 provides hardware protection for the execution of cryptographic algorithms, e.g., using secret cryptographic keys.

According to various embodiments, each HSM 201, 202, 203 may be used by, i.e., receive and process delegates from, different (e.g., all) computer systems 204, 205, 206. For example, different computer systems 204, 205, 206 correspond to different customers and each HSM 201, 202, 203 may be used by different customers. This is also known as Multi-tenant capability (or English: Multi-Tenacy). Here, a customer (or computer system 204, 205, 206) may seize an HSM 201, 202, 203 and release it again at any time. After the release, additional customers may use the HSM.

According to one embodiment, extensibility of the HSMs 201, 202, 203 is supported. This means that each HSM 201, 202, 203 can reconfigure one or more other HSMs 201, 202, 203 at runtime and can use the current delegation to support processing, if needed. Thereby enabling automatic parallelization of complex delegation. The communication between the HSMs 201, 202, 203 may here be based on a protected peer-to-peer scheme that does not require a central server or an upper software layer. The communication is protected, for example, and the security of the encryption can likewise be extensible. The communication may additionally be divided into different, independent sessions (according to the secret sharing principle). In this case, an attacker who wants to obtain information about the communication must successfully attack each of these sessions.

Secure communications are set up between the requestor (i.e., the computer system 204, 205, 206 sending the delegate) and the HSM 201, 202, 203. Communications to and from the HSMs 202, 203 are effected, for example, via a secure communication channel. This may include user concepts, access control, and transaction authentication.

According to one embodiment, each HSM 201, 202, 203 has a secure queue for delegates of inputs. The queue is protected from possible attacks. In addition to confidentiality, the trusteeship is also guaranteed for authenticity, integrity and correct processing of the trusteeship in the correct order (e.g. corresponding to the entrusted input). Secure internal routing may also be set in the HSM.

In case of overload, each HSM 201, 202, 203 may apply load distribution to one or more further HSMs 201, 202, 203, i.e. outsource one or more delegations to one or more further HSMs 201, 202, 203. Here, the HSMs 201, 202, 203 may redirect the suspended load (e.g., a delegate in its queue) to other HSMs 201, 202, 203 that are already available and correspondingly configured. Here, the HSM ensures confidentiality, authenticity, and integrity.

As described with reference to fig. 1, each HSM 201, 202, 203 is a device that is protected from logical and physical attacks (in particular also side channel attacks) by means of hardware-based security precautions. In particular, the HSMs 201, 202, 203 may be separate devices implemented and protected by respective (separate) hardware. If the HSM 201, 202, 203 identifies an attack that violates a security precaution (e.g., by means of a corresponding sensor), such as opening the housing of the HSM 201, 202, 203 with violence, provision may be made, for example, for the HSM 201, 202, 203 to delete all security-related information, such as cryptographic keys, stored in the HSM altogether.

With regard to key management implemented by the HSMs, each HSM 201, 202, 203 may, for example, import (cryptographic) keys to be used and store them internally in a secure area. The HSM can check the authenticity and integrity of each key. The HSM may additionally store metadata for each key, e.g., specifying the cryptographic algorithm used for the key, the key usage, etc. If such metadata is present, the HSM 201, 202, 203 checks before each use of the key, in which case it checks the authorized use of the key based on the metadata.

Different cryptographic hardware may be bound in each HSM 201, 202, 203. For example, dedicated hardware and/or one or more coprocessors may be used in the cryptographic unit 106 for efficient and secure processing. The cryptographic unit 106 may be optimized for the respective cryptographic algorithm to be used and, for example, only implement the required method, i.e. forgo support for unused methods.

The HSMs 201, 202, 203 may support their status (e.g. at any time) to be checked by an external service, e.g. by one of the computer systems 201, 202, 203 (in english called remote Attestation). The check is performed in a cryptographically protected manner, for example by means of a challenge-response protocol.

The HSMs 201, 202, 203 may support Key Revocation (English: Key Revocation). For example, the HSMs 201, 202, 203 check the expiration date in the key metadata and discard the key if it has expired. This can also be done by means of signatures with a time-limited validity. The entire key complex used by the HSMs 201, 202, 203 may also be signed for a limited time. The validity of the keys of the federation then depends on the validity of the signature. For example, one or more keys must be re-signed from time to maintain a valid signature. If the validity of the signature has expired, i.e. the corresponding date has been exceeded, the HSM 201, 202, 203 denies the use of the one or more keys. Revocation can be achieved in this way, since the key can only be used within a unique HSM 201, 202, 203.

Instead of using separate hardware, the HSMs 201, 202, 203 may also be implemented in a common device. For example, one computer system implements multiple HSMs 201, 202, 203. In this case, the HSMs 201, 202, 203 may be considered as virtual HSMs 201, 202, 203 of HSM services provided by the computer system, or may also be considered as multiple HSM instances. For example, the components of the HSMs 201, 202, 203 (such as the cryptographic unit 106) are implemented by a common processor. However, the computer system has hardware protection measures, i.e. processing environments protected by hardware, to implement the HSMs 201, 202, 203, and the domains of the respective HSMs 201, 202, 203 are protected from each other just as in the case of separate hardware, e.g. such that secret data does not leave the domains of the HSMs 201, 202, 203 in clear text.

According to one embodiment, the HSMs 201, 202, 203 enable flexible manipulation from the outside. The input to the HSMs 201, 202, 203 is the delegate 104 with all parameters needed for processing (e.g. for transactions to be protected between users). The exact specifications may be selected independently of the design of the HSMs 201, 202, 203. The output 108 of the HSMs 201, 202, 203 is the result of processing the delegate and may also contain a status indicating whether the delegate was successfully processed or whether an error occurred. In one embodiment, for security reasons, the exact error details are not sent with the results 108 via the interface 105, but may be queried by a monitoring service or logging service. For security reasons, the state may be protected against unauthorized reading.

Examples of architectures of the HSMs 201, 202, 203 are described below.

Fig. 3 shows an HSM 300.

The HSM 300 has a management unit 301 that contains the control logic for the entire system, i.e. the entire HSM 300. This control logic controls, inter alia, the entire communication within the HSM 300, but also the communication with the outside world, i.e. external devices such as further HSMs 201, 202, 203 and computer systems 204, 205, 206.

To temporarily store the incoming delegates, the HSM 300 has a queue 302. Where the commitments entered after the thorough examination (e.g. for the transaction) are stored. A FIFO (first in first out) queue, a random queue, or a queue with a priority list may be used depending on the characteristics of the system.

The Session management unit (English: Session Handler) 303 of the HSM 300 opens a Session to handle the delegation. The session may provide confidential and authenticated as well as bi-directional communication, such as with another HSM. The different sessions are independent of each other so that if one session is broken, it does not affect the other sessions.

The HSM 300 also includes a memory 304 for parameters. Each HSM 201, 202, 203 has a parameter set. These parameters include:

functional parameters: the functional parameters include all parameters needed for reliable communication with the HSM. For example, the functional parameters include values such as the IP address of the HSM, a specification of the communication protocol used, and the like. These parameters are not necessarily security-related.

Parameters for management: specific functions and access to the HSM are required for management. These parameters include, for example, access data (certificates) of the HSM administrator. These parameters are security related and correspondingly protected.

Parameters for defining the interface: the HSM may be configured to provide, provide limited or no specific services at all. The configuration may be performed statically, i.e. by fixed rules and standards. However, the configuration may also be done dynamically, e.g. depending on the current session.

Keys for internal protection: for example, to authenticate against another HSM, the HSM uses secret data such as keying material and attribute certificates. These data are generated securely, entered securely into the HSM and stored securely there. Access to these data can only be made via protocols internal to the HSM. These parameters are security related and correspondingly protected.

The user key: depending on the usage scenario, the user key is used in the HSM. The confidentiality of the private key and the authenticity of all keys are ensured, depending on the particular cryptographic method used.

The HSM 300 has a cryptographic unit 305 as a core. The cryptographic unit 305 executes various cryptographic methods. To protect sensitive data, such as keys, the cryptographic unit 305 is protected by hardware-based protection measures. In addition to physical security, correct and high-performance implementation and execution of the cryptographic method is ensured. The entire contents of the cryptographic unit 305 (i.e., the data stored in the cryptographic unit 305 for processing) are security-related and protected by corresponding hardware-based protection measures.

An API (Application Programming Interface) wrapper 306 of the HSM may convert the defined user transaction into a hardware-specific command. So that different cryptographic units can be used for operation.

The HSM 300 also has a key management unit 306 that stores and manages keys to be used for specific functions, in particular the performed cryptographic methods. In addition to reliably storing keys, the key management unit supports functions such as renewing keys, e.g., periodically changing keys or revoking in response to a corresponding trigger, i.e., declaring a key invalid, and secure deletion of irretrievably deleted keys.

A Logging unit 307 (Logging unit) logs an operation performed in the HSM 300. Here, the log does not contain confidential data such as a key. The integrity and authenticity of the log entries is protected. The export of this log can be set up for external analysis and storage, for example by access by means of a log service.

The monitoring unit 308 monitors the status of the remaining components of the HSM 300. So that the monitoring unit checks, for example, the authenticity and integrity of the log of the logging unit 307, the state of the cryptographic unit 305 and the state of the queue 302. In case of a critical condition, such as leakage of the cryptographic unit 305, the monitoring unit sends a message to a configurable receiver (e.g. over a network, a radio network, a telephone network or a satellite) for external monitoring 309. The device for external monitoring 309 may also query information about the state of the HSM 300 from outside by means of said monitoring unit.

To communicate with additional devices (e.g., additional HSMs 201, 202, 203 and computer systems 204, 205), HSM 300 has a communication interface 310. The communication interface 310 is provided with a firewall that regulates communication of the HSM 300 with additional devices. So that, for example, network-based attacks such as DoS (Denial of Service) attacks can be defended.

The various functional units of the HSM 300, such as the management unit 301, the session management unit 303, the API wrapper 306, the key management unit 306, the logging unit 307, the monitoring unit 308 and the communication interface 310 may be implemented by one or more programmed processors and, if necessary, corresponding memories (and correspondingly components regarded as logical components) or may also be implemented by hardwired circuitry.

For example, the management unit 301 decides to outsource the delegation to another HSM. For this purpose, the management unit checks, for example, the status of the queue and decides that the delegation should be outsourced if the fill level of the queue is above a predefined threshold. The management unit 301 may find out which further HSMs are present and how they can be reached, e.g. by accessing the memory 304. For example, corresponding information (for example, an IP address or a TCP address of the further HSM) is stored in the memory 304 for this purpose.

The HSM 300 uses various objects, such as one or more of the following

The session object: a session object is created for each session and contains the following data

o session ID: a unique identifier of the session. However, uniqueness is not a security feature.

o session key: a unique secret key for the session. From which keys, for example, working keys for various protection targets can be derived.

Certificates, such as ROOT certificates HSM-AUTH-ROOT-ZERT, are used to check chains of authenticity certificates, e.g. in order to mutually authenticate HSMs.

Cryptographic KEYs, such as the secret KEY HSM-AUTH-KEY used to prove the authenticity of the HSM 300.

DH (Diffie-Hellmann) parameters, e.g.

An O DH generator: generator of DH group

O DH group parameters: parameters of the DH set (e.g., module, EC (elliptic curve),).

The following describes the procedures and protocols for the components of the HSM 300. This includes, in addition to the required functionality, specific measures for achieving protection goals such as confidentiality, integrity, authenticity, availability and liability/non-repudiation.

The user sends a delegate 104 to the HSM 300 by way of the computer system 102 for processing. The delegate contains all necessary parameters and data in addition to the description of the command.

Queue 302 is responsible for managing the delegation of inputs. According to one embodiment, a first-in-first-out scheme is implemented. Alternatively, an optimization strategy based on independent delegation may also be implemented. According to one embodiment, the queues are not stored and processed in the secure hardware area of the HSM 300. Instead, the above protection objective is ensured by appropriate cryptographic measures.

The operation used to join a delegate to queue 302 (enqueue operation) enqueues the new delegate to queue 302. For safety reasons, the above-mentioned safety goals are pursued by, for example, the following corresponding measures:

confidentiality, i.e. not allowing to determine information about delegated content by analyzing the activated queue. To this end, each delegate is stored in the queue encrypted, and each response (e.g., result 109) is transmitted to the sender encrypted.

Authenticity, i.e. only allowed to accept delegates from authenticated sources. For this reason, only authenticated delegation is accepted. Further, an authenticated (i.e., signed) confirmation of acceptance of the delegate 104 is sent to the delegate source (computer system 102) and the response 109 is authenticated with respect to the delegate source.

Availability, i.e., the queue 302 is not allowed to jeopardize the availability of the services provided by the HSM 300 as a "single point of failure," e.g., due to a failure or overload. To this end, the queues may be stored redundantly (e.g., by means of replication through multiple peers such as multiple HSMs).

Responsibility/non-repudiation. To this end, an authenticated (signed) confirmation of acceptance of the delegation is sent to the delegation source. Further, the log recording unit 307 sets an authenticated entry in the delegation log.

Operations that remove the delegate from the queue 302 (dequeue operations) send the delegate to the secure hardware of the HSM 300 for processing and remove the entry from the queue 302. No other mechanisms for confidentiality, integrity and authenticity are required here. The queue 302 may be stored redundantly for availability (e.g., by replication through multiple peers such as HSMs). Dequeue operations are replicated by redundant instances. For the sake of liability/non-repudiation, the log recording unit 307 registers the execution of the delegation in a log (e.g., a log file). The log contains, for example, the principal, the time of incorporation into the queue, the time of removal from the queue, and information about the process link, for example, information about the association with another operation being performed (e.g., cross-referencing).

To distribute the load onto the further HSMs 201, 202, 203, the HSM 300 searches for the further HSMs 201, 202, 203 and first verifies that the further HSMs 201, 202, 203 are valid HSMs. To this end, the HSM (hereinafter referred to as verified HSM) and the further HSM (hereinafter referred to as target HSM) use HSM verification operations (e.g., referred to as "verify SFC-HSM"). This operation verifies that the target HSM is a valid HSM. Here, no information is disclosed about who currently "owns" the target HSM (ownership), i.e. which client or which computer system 204, 205, 206 is currently occupying the target HSM.

It is assumed that the target HSM is provided with the (secret) KEY HSM-AUTH-KEY as described above. The target HSM also has a corresponding certificate HSM-AUTH-ZERT that certifies the authenticity of the KEY HSM-AUTH-KEY. The proof is part of a certificate chain that ends in the global HSM-AUTH-ROOT-ZERT. The verified HSM has a certificate HSM-AUTH-ROOT-ZERT.

If the HSM verification operation fails, the verified HSM is not sure (i.e., unsuccessfully verified) that the target HSM is a valid HSM. If the HSM authentication operation is successful and the session object is generated as a result, the authenticated HSM is confident (i.e., successfully authenticated) that the target HSM is a valid HSM. The session object enables a secure communication session to be established between the verified HSM and the target HSM.

The input to the HSM validation operation is the address of the target HSM (e.g., TCP address). If the verification fails, the output of the HSM verify operation is "error". If the verification is successful, the session object is returned.

For safety reasons, the above-mentioned safety goals are pursued, for example, by the following countermeasures:

confidentiality: it is specified that no outside person can see information about the secret keying material, the settings of the HSM or about who owns the HSM (ownership). This is achieved, for example, by the following measures:

the synchronization protocol used for authentication between the authenticated HSM and the target HSM uses appropriate encryption measures.

The key used for this purpose is based on a pre-personalized key set.

The o-sync protocol is direction specific and session based and has a forward secret nature.

Authenticity: the authenticity of the data of all messages exchanged between the verified HSM and the target HSM for verification is ensured by a signature (or alternatively by a MAC (Message Authentication Codes)). The authenticity is checked for each message directly after acquisition. If the check fails, the HSM validation operation (with error message) is aborted.

Availability: not applicable. Availability of delegates for input may be achieved by redundantly storing the queue 302.

Responsibility/non-repudiation. To this end, an authenticated (signed) confirmation of acceptance of the delegation is sent to the delegation source. Further, the log recording unit 307 sets an authenticated (signed) entry in the delegation log.

Table 1 shows an example of the flow of an HSM verify operation in pseudo code. Here, V denotes a verified HSM, and P (representing a verifier) denotes a target HSM. If only the source is illustrated and the target is not, then the operation is performed in the source, otherwise the message is transmitted in the direction illustrated by the arrow "→". Arrow "←" indicates a message forming the left side of the arrow with the content to the right of the arrow.

Table 1

In (2), HSM-AUTH-ZERT represents HSM-AUTH-ZERT and all other certificates in the certificate chain. If the authentication from (4) to (6) is successful, then (7) to (9) are performed for DH key exchange.

According to one embodiment, for load distribution, operations are also provided by which a verified HSM verifies that the target HSM is a valid HSM and that the target HSM is owned (in ownership), i.e. currently occupied by a particular client or computer system, 204, 205, 206. For example, this operation is referred to as "authenticating the client HSM".

Additionally, an operation called "isFree" operation may be provided by which the HSM may determine whether the target HSM is idle (i.e., not currently in use).

For the "authenticate client HSM" operation, it is assumed that the target HSM is provided with the (secret) KEY HSM-AUTH-KEY. The target HSM also has a corresponding certificate HSM-AUTH-ZERT that certifies the authenticity of the KEY HSM-AUTH-KEY. The proof is part of a certificate chain that ends in the global HSM-AUTH-ROOT-ZERT. The verified HSM has a certificate HSM-AUTH-ROOT-ZERT.

The ownership checked by the verified HSM is, for example, whether the target HSM is owned by the same customer as the verified HSM itself.

If the target HSM is already owned by a specific customer, the target HSM has a configuration data set that includes all personal settings and keys (for the customer). Each HSM implements an algorithm that creates a cryptographic checksum on the configuration set. The checksum is explicit, collision-resistant, and does not allow for the contents of the configuration to be inferred.

If the verified HSM calls the corresponding checksum to the target HSM to verify whether the target HSM is occupied by a specific client, for example, random numbers are set for both sides: on the part of the verified HSM, for preventing replay attacks, and on the part of the target HSM, for ensuring confidentiality. A comparison of the outputs of different algorithms should not allow to deduce e.g. the same or different.

If the client HSM validation operation fails, the validated HSM is not sure that the target HSM is a valid HSM owned accordingly. If the HSM validation operation is successful and the session object is generated as a result, the validated HSM is assured that the target HSM is a valid HSM that is correspondingly owned. The session object enables a secure communication session to be established between the verified HSM and the target HSM.

The input to the client HSM authentication operation is the address (e.g., IP address) of the target HSM. If the verification fails, the output of the guest HSM verification operation is "error". If the verification is successful, the session object is returned.

For safety reasons, the above-mentioned safety goals are pursued, for example, by the following countermeasures:

confidentiality: it is specified that no outside person can see information about the secret keying material, the settings of the HSM or about who owns the HSM (ownership). This is achieved, for example, by the following measures:

the synchronization protocol used for authentication between the authenticated HSM and the target HSM uses appropriate encryption measures.

The key used for this purpose is based on a pre-personalized key set.

The synchronization protocol is direction-specific and session-based and has a forward secret nature.

The o checksum is random so that no configuration change can be inferred based on the log record. This means that both parties (verified HSM and target HSM) introduce random values in the log flow, which prevents deriving information about the internal state of the target HSM based on the log record.

Authenticity: the authenticity of the data of all messages exchanged between the verified HSM and the target HSM for verification is ensured by a signature (or alternatively by a MAC (Message Authentication Codes)). The authenticity is checked for each message directly after acquisition. If the check fails, the HSM validation operation (with error message) is aborted.

Availability: not applicable. The availability of incoming delegates may be achieved by redundantly storing the queue 302 (e.g., by replication through multiple peers, i.e., HSMs).

Responsibility/non-repudiation. To this end, an authenticated (signed) confirmation of acceptance of the delegation is sent to the delegation source. Further, the log recording unit 307 sets an authenticated (signed) entry in the delegation log.

Table 2 shows an example of the flow of a guest HSM authentication operation in pseudo code. As in table 1, V denotes a verified HSM and P denotes a target HSM. If only the source is illustrated and the target is not, then the operation is performed in the source, otherwise the message is transmitted in the direction illustrated by the arrow "→". Arrow "←" indicates a message forming the left side of the arrow with the content to the right of the arrow.

Table 2

In (2), HSM-AUTH-ZERT stands for HSM-AUTH-ZERT and all other certificates of the certificate chain. If the authentication from (4) to (6) is successful, then (7) to (9) are performed for DH key exchange.

In order to distribute a delegation from one HSM (hereinafter source HSM) to another HSM (hereinafter target HSM), the source HSM (specific hardware) may be cloned onto the target HSM, for example for performance reasons, which may be personalized correspondingly for handling delegations for a specific customer (or computer system 204, 205, 206). Here, all client specific data, settings and keys are sent from the secure area of the source HSM to the secure area of the target HSM. It should be noted here that sensitive keying material must be derived from the hardware (which may be relevant for authentication). After successfully performing this operation, the target HSM is equivalent to the source HSM.

The cloning operation initiates a cloning process, which includes, for example, the following actions:

1. finding potential target HSM

2. Synchronizing settings with a key

3. The synchronization is verified.

For safety reasons, the above-mentioned safety goals are pursued, for example, by the following countermeasures:

confidentiality: it is specified that no outside person can see information about the secret keying material, the settings of the HSM or about who owns the HSM (ownership). This is achieved, for example, by the following measures:

o the synchronization protocol used between the source HSM and the target HSM uses appropriate encryption measures.

The key used for this purpose is based on a pre-personalized key set.

The synchronization protocol is direction-specific and session-based and has a forward secret nature.

Authenticity:

the o-target HSM accepts configuration only from the authenticated source HSM.

The o-target HSM sends an authenticated (i.e., signed) confirmation.

The o-source HSM authenticates (i.e., verifies) each response from the target HSM.

If a user or computer system 204, 205, 206 sends a commit (e.g., for a transaction) to the HSM 300, the HSM 300 distributes the load as necessary on one or more additional HSMs, depending on the load or complexity of the commit. To this end, the HSM 300 may verify the further HSMs (i.e. check their authenticity) by means of the above-described verification operation and transfer its configuration to the further HSM by means of the above-described cloning operation.

All activities are logged by the logging unit 307. The HSM may check the authenticity and integrity of the log (e.g., periodically). In addition, the HSM may perform (e.g., periodically) status checks of the management unit 301 and the queue 302.

In summary, a hardware security module is provided according to various embodiments, as shown in fig. 4.

Fig. 4 shows a hardware security module 400.

The hardware security module 400 has a receiver 401 arranged to receive a delegate to perform a cryptographic operation.

The hardware security module 400 further has control means 402 arranged to decide whether one or more commissions should be outsourced based on the commissioning load of the hardware security module 400.

The control means 402 are further arranged to determine a further hardware security module 403 for outsourcing one or more delegations if the one or more delegations should be outsourced, authenticate the further hardware security module 403 and request the further hardware security module 402 to handle the one or more delegations.

According to various embodiments, load distribution is performed among multiple Hardware Security Modules (HSMs) to avoid delays in handling delegation for cryptographic operations by the HSMs. To this end, the source HSM that has received the delegation selects the target HSM, authenticates it and requests that the delegation be processed by the target HSM. With the authentication, the source HSM ensures that the target HSM is a real HSM, e.g., a corresponding protected device, rather than just masquerading as a device that is an attacker of the HSM.

By distributing the load among a plurality of HSMs, it is clear to provide the HSM service to the user instead of providing the respective HSMs, or in other words, to realize a cloud composed of the respective cloud-enabled HSMs.

The hardware security module 400 and the further hardware security module 402 have, for example, a communication interface by means of which they perform the authentication and by means of which the hardware security module 400 requests the further hardware security module 402 to perform one or more delegations. To request a delegation, the hardware security module 400 sends, for example, a specification of the delegation and data (e.g., encrypted text and keys) needed to perform the delegation to the further hardware security module 402. The hardware security module 400 may copy its configuration (i.e., configuration data) onto another hardware security module 402 (clearly cloned itself). The configuration data may contain data (e.g. a key) needed to perform the delegation.

Various embodiments are described in detail below.

Embodiment 1 is a hardware security module as shown in fig. 4.

Embodiment 2 is the hardware security module of embodiment 1, wherein the control means is arranged to configure the further hardware security module to perform the one or more delegations.

Embodiment 3 is the hardware security module of embodiment 1 or of embodiment 2, wherein the control means is arranged to clone the configuration of the hardware security module to the further hardware security module for handling the one or more delegations by the further hardware security module.

Embodiment 4 is the hardware security module of one of embodiments 1 to 3, wherein the control means is arranged to send the one or more delegates to the further hardware security module by means of a peer-to-peer communication connection.

Embodiment 5 is the hardware security module of one of embodiments 1 to 4, wherein the control means is arranged to decide that the one or more delegations should be outsourced if a delegation load of the hardware security module is above a pre-given threshold.

Embodiment 6 is a hardware security module according to embodiment 5, having a delegation queue, wherein the delegation load is a fill level of the delegation queue.

Embodiment 7 is the hardware security module of one of embodiments 1 to 6, wherein the control device is configured to assign the further hardware security module and to release the further hardware security module again after processing the one or more delegations.

Embodiment 8 is the hardware security module of one of embodiments 1 to 7, wherein the control device is configured to determine the number of the one or more commissions that should be outsourced based on a commissioning load of the hardware security module.

Embodiment 9 is the hardware security module of one of embodiments 1 to 8, wherein the control means is arranged to decide to outsource the delegation until a delegation load of the hardware security module falls below a predefined threshold.

Embodiment 10 is a hardware security module according to one of embodiments 1 to 9, having a cryptographic unit arranged to perform cryptographic operations.

Embodiment 11 is the hardware security module of one of embodiments 1 to 10, wherein each cryptographic operation has decryption, encryption, signature and/or verification of a signature.

Embodiment 12 is the hardware security module of one of embodiments 1 to 11, wherein the control means is arranged to authenticate the further hardware security module based on a signature generated by the further hardware security module.

Embodiment 13 is the hardware security module of one of embodiments 1 to 12, wherein the hardware security module and the additional hardware security module have separate hardware for performing cryptographic operations.

According to another embodiment, a hardware security module is provided having a receiver arranged to receive a delegate for performing a cryptographic operation, a detection device arranged to detect an overload, and an outsourcing device arranged to outsource one or more delegates to a further hardware security module in case of an overload.

While the invention has been particularly shown and described with reference to a particular embodiment, it will be understood by those skilled in the art that many changes in design and details may be made therein without departing from the spirit and scope of the invention as defined by the following claims. The scope of the invention is, therefore, indicated by the appended claims, and all changes that come within the meaning and range of equivalency of the claims are intended to be embraced therein.