Selecting HSM for association to secure client

Abstract

A method for policy-based association of a hardware security module with a secure client is disclosed. The method includes maintaining a binding between the secure client and the HSM. Thereby, the binding enables the trusted client to send only non-sensitive requests to the HSM. The method further includes maintaining a pair of a secret and a secret name for the secure client, submitting a query to the bound HSM to obtain HSM configuration data, and upon determining that the obtained HSM configuration data matches a rule available to the secure client, where the rule associates the HSM to the secret name, the request associates a secret from a pair of the secret and the secret name to the bound HSM, thereby triggering the trusted firmware to allow the secure client to submit a sensitive cryptographic request to the bound and associated HSM.

Description

Background Art Technical Field

[0001] The present invention generally relates to a method for a policy-based confidential computing environment, and more particularly to a computer-implemented method for policy-based association of a hardware security module and a security client in a confidential computing environment. The present invention also relates to a related security system for policy-based association of a hardware security module and a security client in a confidential computing environment, and a computer program product.

[0002] Related Art

[0003] The security of data and communication channels continues to be one of the top priorities for managing corporate IT (Information Technology). This is necessary not only due to government regulations (such as GDPR, the EU General Data Protection Regulation), but also due to the loss of reliability of the company, which cannot reliably protect customer data at all times - and to avoid losses in sales and profits - in the event of damage to customer data records. Additionally, depending on the country where the data breach occurs, fines may need to be paid. As a result, the provision of data protection and secure computing platforms is not just a software issue; it also involves hardware modules. This may not be a natural environment for a large number of market CPU chips used in microcontrollers, personal computers, mobile phones, or home automation devices. However, for highly trusted enterprise-level computing environments, such as those used in the financial, insurance, or government industries, from a technical perspective, it is necessary to be able to demonstrate a very high probability of preventing data breaches. This may require some additional high-tech components and support processes. However, the success in data security justifies the extra effort.

[0004] These ideas can also be applied to trusted and / or confidential computing environments where keys used by virtual machines (also referred to as clients) or software containers running on / within a hypervisor cannot actually be accessed by the hypervisor or related software management and configuration programs. However, in such computing environments, it is still possible to violate basic security rules, such as by the hypervisor exposing the secret key of a security client image or using the secret key. This is also possible in an environment where a hardware security module (HSM) has been used for a considerable period of time.

[0005] There have been some disclosures suitable for the context of policy-based association of a hardware security module and a security client in a confidential computing environment. Document US2020 / 0076607A1 describes how to securely maintain secrets on a virtual computer system by configuring a dedicated virtual machine to represent an application management and maintenance sequence. When an application requests access to a secret, the control domain combines with the dedicated virtual machine to verify that the application is authorized to make the request and that the application has not been compromised prior to the request.

[0006] Additionally, the document US2017 / 0310652A1 describes that the system can send data to a first entity to indicate the association between the first entity and a public key. Thereby, the public key will be used to establish a cryptographically protected communication session between the first entity and a second entity, receive data in response to a request to verify the association, and convey an indication of data validity to the second entity. The system can be a cryptographic service partially implemented by the first and second entities.

[0007] The problem in such an environment can be identified in the context of using an additional key as part of the metadata of a virtual client system under the control of a hypervisor. However, if the additional key is provided by the virtual client system, it will be known to the virtual client system, where it may also be stolen like other credentials. Technologies such as OpenCryptoki or CCA (Common Cryptographic Architecture) do not yet well meet such requirements.

[0008] Therefore, there is a need to provide a method for secure binding between a virtual machine and a hardware security module such that the virtual machine does not have specific knowledge of the underlying configuration for implementing such binding. Summary of the Invention

[0009] According to one aspect of the present invention, there is provided a computer-implemented method for policy-based association of a hardware security module (HSM) with a secure client in a confidential computing environment. The method can include maintaining, by a trusted firmware, a binding between the secure client and the HSM. Thereby, the binding enables the secure client to be able to send only non-sensitive requests to the HSM.

[0010] The method can further include maintaining, by the trusted firmware, a pair of a secret and a secret name for the secure client, and submitting, by the secure client via the trusted firmware, a query for obtaining HSM configuration data to the bound HSM.

[0011] Furthermore, when the secure client determines that the obtained HSM configuration data matches the policy rules available to the secure client, the method can include the secure client requesting the trusted firmware to associate the secret from the pair of the secret and the secret name with the bound HSM. Thereby, the policy rules can associate the HSM configuration data with the secret name. As a result, the trusted firmware can allow the secure client to submit sensitive cryptographic requests to the bound and associated HSM.

[0012] According to another aspect of the present invention, a security system for policy-based association of a hardware security module and a secure client in a confidential computing environment can be provided. The system can include a processor and a memory operably coupled to the processor, wherein the memory stores software program code that, when executed by the processor, enables the processor to maintain a binding between the secure client and the HSM using trusted firmware, wherein the binding enables the trusted client to send only non-sensitive requests to the HSM, and to maintain a pair of a secret and a secret name for the secure client using trusted firmware.

[0013] The processor can also be enabled to submit a query to the bound HSM by the secure client via trusted firmware, or to obtain HSM configuration data. When it is determined by the secure client that the obtained HSM configuration data matches the policy rules available to the secure client, the processor can be enabled to use the secure client to request the trusted firmware to associate the key from the pair of the secret and the secret name with the bound HSM. Thus, the policy rules can associate the HSM configuration data with the secret name.

[0014] As a result, the trusted firmware can allow the secure client to submit sensitive cryptographic requests to the bound and associated HSM.

[0015] The proposed computer-implemented method for policy-based association of a hardware security module and a secure client in a confidential computing environment can provide several advantages, technical effects, contributions, and / or improvements:

[0016] The link established between the secure client and the HSM can be performed substantially in a two-step process by (a) establishing a binding between the secure client and the HSM and (b) establishing an association between the same secure client in the same HSM. Thus, the binding can only allow non-sensitive requests to be sent to the HSM, so that neither the request nor the response can be compromised or accessed by untrusted components. Thus, the additional association can allow sensitive requests from the secure client to the HSM. This can allow the confidential computing environment to be protected in three ways: (i) preventing the exposure of secrets protected by the HSM (e.g., security keys), (ii) preventing the use of secrets protected by the HSM by a wrong client image, and (iii) preventing the use of secrets protected by the HSM by a wrong client instance. In the same way, the secrets used to establish this protection can be protected from being exposed, being used by a wrong client image or client instance. Therefore, the secret of the pair of the secret and the secret name may never be visible to the secure client on the hypervisor and thus cannot be stolen from the secure client. Only the trusted firmware can have full access to these highly sensitive data.

[0017] In addition, policy-based association can allow a security client to select a specific HSM among multiple HSMs assigned to the security client to allocate the secret means for protecting the HSM-protected key for a specific workload / application that is presumably using that specific HSM.

[0018] In addition, policy-based association can allow a security client to reject the use of an HSM whose configuration is not included in the policy, thus avoiding the danger of using an HSM belonging to an attacker.

[0019] Additionally, an optional but enabled feature when using a temporarily deallocated (and then reallocated) HSM, unbinding and disassociating from the HSM deallocated from the security client results in a binding error, thus allowing the client to identify the temporary reallocation and re-evaluate the validity of the HSM, ensuring that the HSM has not been swapped or reconfigured during deallocation.

[0020] Additional embodiments of the inventive concept will be described below - which are applicable to the method as well as the system.

[0021] According to an advantageous embodiment, the method may further include intercepting, by a trusted firmware, each request from a security client to an HSM for generating an HSM-protected key, and forcing, by the trusted firmware, the generated HSM-protected key to be used only with an HSM associated with a secret from the security client. That is, it is not sufficient that the HSM is bound to the security client to ensure a secure communication channel between the security client and the HSM (or vice versa), and furthermore, it is not sufficient that an association between the security client and the HSM has been established such that the HSM-protected key can be exclusively used by the security client. In other words, before the HSM executes a sensitive cryptographic request at the request of the security client, a two-step process - first binding and second association - must be performed. To this end, the interception of each request from the security client to the HSM by the trusted firmware can contribute to making the HSM-protected key available to a security client configured with a specific (association) secret.

[0022] According to a licensing embodiment of the method, an HSM Master Key Verification Mode (MKVP) can indicate the configuration data of the HSM. That is, all settings and configuration data as well as capabilities of a specific HSM can be encoded and thus interpretable by a requesting security client in the master key verification mode. Thereby, the security client can be enabled to use the master key verification mode to compare with policy-based rules to select an appropriate HSM for its needs.

[0023] According to another advantageous embodiment of the method, a pair of a secret and a secret name can be added to the metadata that the trusted firmware can maintain for a security client. Thereby, such metadata can be maintained separately by the trusted firmware for each security client instance.

[0024] According to a preferred embodiment, the method may further include the secure client requesting from the trusted firmware a list of secret names of pairs of secrets and secret names maintained by the trusted firmware for the secure client. This can be achieved through a call interface or API (Application Programming Interface) for the secure client to the trusted firmware.

[0025] According to an advanced embodiment, the method may further include the secure client submitting a new query via the trusted firmware to another HSM to obtain other configuration data in case the obtained configuration data of the HSM does not match the policy rules. In this way, the secure client can identify an HSM that complies with the policy-based rules in order to select an appropriate HSM for the secure client. That is, a step-by-step iterative process can be established to identify a suitable HSM for the requirements of the secure client.

[0026] According to a useful and security-enhanced embodiment, the method may further include - when the allocated configuration of the HSM bound to the secure client changes - unbinding the HSM from the secure client and, if such an association exists, also unassociating the HSM from any secrets. Thereby, it can be made impossible for the secure client to use the capabilities of the HSM. That is, a reset of the binding and association between the secure client and the HSM can be established. In other words, if the allocation of each bound HSM changes, it should be unbound, i.e., if the HSM is associated with a secret, that association must also be "unassociated". And this must occur automatically and atomically, i.e., the HSM is for the HSM, and the secure client is for the secure client, in order to comply with the rules of the secure computing environment.

[0027] According to another interesting embodiment of the method, the trusted firmware may reject all requests - especially sensitive requests - from the secure client to an HSM that is not bound to the secure client. Thus, first, a binding may have to be established before a sensitive request can be addressed from the secure client to the HSM and before an association can occur.

[0028] According to another interesting embodiment of the method, if an HSM is allocated to the secure client, the binding between the secure client and the HSM can be established by the trusted firmware upon a request from the secure client to the trusted firmware to bind the HSM. It can be noted that such a process may only be possible for those HSMs that are visible to the secure client. This can also be applied to the allocation configuration.

[0029] According to the security-enhanced embodiment of the method, the cleartext value of the secret will not be accessible to the secure client. That is, the secret maintained by the trusted firmware cannot be stolen from the secure client because it can never access it.

[0030] According to another useful embodiment of the method, any request to the HSM bound to the secure client is only allowed if it is issued by the secure client or the trusted firmware on behalf of the secure client. Thus, other secure clients or any other entity are not allowed to access the relevant HSM through any bypass. Therefore, the management rules of confidential computing can always be applied.

[0031] According to an additional embodiment of the method, any request from the secure client to the HSM, which may include an HSM-protected key, or whose response - especially to the request - includes an HSM-protected key, may be a sensitive request. This classification can ensure that a clear distinction between non-sensitive and sensitive requests can always be guaranteed in order to comply with the confidential computing rules.

[0032] In addition, embodiments may take the form of a relevant computer program product accessible from a computer-usable or computer-readable medium, which provides program code used by or in conjunction with a computer or any instruction execution system. For the purposes of this specification, a computer-usable or computer-readable medium can be any device that can contain, store, communicate, propagate, or transport the program for use by or in conjunction with an instruction execution system, apparatus, or device. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] It should be noted that the embodiments of the present invention are described with reference to different subjects. In particular, some embodiments are described with reference to method-type claims, while other embodiments are described with reference to apparatus-type claims. However, those skilled in the art will understand from the above and following descriptions that, unless otherwise indicated, any combination between features related to different subjects, in particular any combination between the features of method-type claims and the features of apparatus-type claims, is also considered to be disclosed within this document, in addition to any combination of features belonging to one type of subject.

[0034] The above-defined aspects and other aspects of the present invention are apparent from the examples of the embodiments described below and are explained with reference to the examples of the embodiments. The present invention is not limited to the examples of these embodiments.

[0035] The preferred embodiments of the present invention will be described only by way of example and with reference to the following drawings:

[0036] Figure 1 A flowchart showing an embodiment of a computer-implemented method of the present invention for policy-based association of a hardware security module with a secure client in a confidential computing environment.

[0037] Figure 2Block diagram of an embodiment 200 showing the potential of threads with multi-factor authentication.

[0038] Figure 3 Block diagram of an embodiment 300 showing more practical details of the proposed method, especially the components involved.

[0039] Figure 4 Block diagram showing the first step of the association between the HSM and the secure client.

[0040] Figure 5 Block diagram showing the second step of the association between the HSM and the secure client.

[0041] Figure 6 Block diagram showing the third step of the association between the HSM and the secure client.

[0042] Figure 7 Block diagram of an embodiment of the secure system of the present invention for policy-based association between a hardware security module and a secure client in a confidential computing environment.

[0043] Figure 8 Shows an embodiment of a computing system including a system according to Figure 7 of. Detailed Description

[0044] In the context of this specification, the following technical conventions, terms, and / or expressions may be used:

[0045] The term "hardware security module" (HSM) may represent a hardware element connected to or integrated into a computer system (such as a server system, here for example a manufacturing-end server computer). The HSM is designed to be tamper-proof and protect secrets, i.e., software keys, from unauthorized access, even against physical penetration and / or unscheduled physical unlocking. The HSM may be closely connected to the CPU or may operate independently of the CPU. In other words, the HSM is a physical computing device that protects and manages one or more digital keys for strong authentication and provides cryptographic processing. These modules may traditionally appear in the form of an insertion card or an external device, which can be directly attached to a computer or a network server.

[0046] The term "secure client" may represent a virtual machine or a software container including executable program code in a secure computing environment protected by a trusted execution environment such that untrusted components of the computer system cannot observe any state (memory or registers) of the running secure client. It may be, for example, a general client image that can also be provided by a third party (such as a software company). Typical untrusted components are hypervisors, hardware management consoles, and other clients.

[0047] The term "secure computing environment" may refer to a hypervisor or any system management software with a user interface component that cannot access any plaintext content or other state of a virtual machine.

[0048] The term "binding" or "binding a hardware security module to a secure client" may mean that a link protected and controlled by trusted firmware has been established between the secure client and the bound hardware security module. This binding can establish a secure channel between the secure client or trusted firmware and the HSM, which can ensure the integrity and confidentiality of the communication between the secure client and the bound HSM. However, the binding may only allow non-sensitive, i.e., non-encrypted, requests from the bound secure client to the HSM. In contrast, if an additional association has been established between the secure client and the HSM, sensitive cryptographic requests from the secure client to the HSM can only be allowed and controlled by the trusted firmware.

[0049] The term "association" or "associating a secure client to an HSM" may mean that - in addition to the binding between the secure client and the HSM - a second relationship between the same secure clients within the same HSM - in particular, an association between two components - may have been established. The technical basis for this may be secrets and secret names and the sequence of steps described by the method. - Additionally, the association between the secure client and the associated HSM can be "policy-based" in the sense that the secure client can access a set of rules that describe the requirements or configuration settings, etc., of the HSM to be associated with the secure client.

[0050] The term "non-sensitive request" may refer to a request from a secure client to an HSM via trusted firmware that only allows non-encrypted requests to the HSM, e.g., requests for configuration data. In contrast, the term "sensitive request" or "sensitive cryptographic request" may refer to a request to the HSM that includes encryption or decryption commands. In particular, requests to use or return keys protected by the HSM may be sensitive.

[0051] The term "trusted firmware" (trusted FW or TFW) may refer to a component deeply embedded in the hardware of a computing (host) system that cannot be accessed by software controlled by any other user. The trusted firmware may have a predefined and highly secure application programming interface to protect - in a broad sense - the operation of the trusted firmware. The trusted FW should be regarded more as a deeply integrated component of the computer system rather than a service component. The communication channels to / from the trusted firmware are typically cryptographically protected.

[0052] The term "metadata" can denote – in the classical sense, here information about data – in this article, in particular the data required to start a virtual machine. In a confidential computing environment, such information can be used by trusted firmware to start a secure virtual machine, for example, it can include the integrity measurement of the image of the secure guest or the key required to decrypt the image of the secure guest. Such metadata can include, for example, the required resources, the required interfaces, the required performance, and – in some cases – also which security measures are appropriate. The extension of the metadata – for example, in terms of the required binding information – but more specifically in terms of the pair of secret and secret name – is one of the bases for the proposed concept to be used by trusted firmware.

[0053] The term "pair of secret and secret name" can denote a secret – potentially used for the association between a secure guest and an HSM – that can be related to a secret name (e.g., the identifier of the HSM) in a one-to-one manner to establish the basis for the association between the secure guest and the HSM (i.e., not a pre-established binding).

[0054] The term "HSM configuration data" can denote a set of information that describes the capabilities and settings of the relevant HSM. This can be encoded in a dataset represented as the master key verification mode (MKVP).

[0055] The term "allocation configuration" can denote an aspect of the configuration of a system component or a virtual server that can define the visibility of the components of the virtual server to devices such as an HSM and may be granted basic access to that device. For a standard guest, the specified device can be detected and used by the guest. For a secure guest, the allocated device can be detected by the secure guest, but it must be bound (and associated with a secret) to be used.

[0056] The term "hypervisor" can denote a well-defined type of computer software or firmware that creates and runs virtual machines or software containers. Thus, multiple virtual machines / software containers can be executed in parallel without any risk of cross-reference. An error in a virtual machine may not cause any damage to another virtual machine. Each virtual machine can have a defined address space.

[0057] The term "policy" can denote a description of the expected configuration that is usually stored in a file. The policy can establish a correspondence between the HSM specification and the secret. The definition of this correspondence can be indirect in nature. For example, the secret can be referred to by a secret name, while the HSM specification can be referred to by HSM attributes, and the HSM attributes can be queried like the HSM configuration data including the master key verification mode.

[0058] Next, a detailed description of the accompanying drawings will be given. All descriptions in the figures are illustrative. First, a block diagram of an embodiment of a computer-implemented method for policy-based association of a hardware security module and a secure client in a confidential computing environment is given. Then, further embodiments and embodiments of a security system for policy-based association of a hardware security module and a secure client in a confidential computing environment will be described.

[0059] Figure 1 A flowchart of a preferred embodiment of a computer-implemented method 100 for policy-based association of a hardware security module and a secure client in a confidential computing environment is shown. The secure client can be a virtual machine running on / within a hypervisor or a software container. The method includes - maintaining 102 by a trusted firmware - a binding between the secure client and the HSM. It should also be noted that there is no binding secret; there is only an association secret in the proposed concept. Thus, the binding enables the trusted client to send only non-sensitive requests to the HSM. The binding secret can - as an example - be sent by the secure client to the trusted firmware at runtime of the secure client for extension of the metadata of the secure client in the trusted firmware. Alternative implementations include binding settings during the startup of the secure client. Alternative implementations are also possible. However, a strict distinction should be made between the binding of the secure client to the HSM and the association of the secure client to the HSM.

[0060] Method 100 also includes maintaining 104 by the trusted firmware - for the secure client - pairs of secrets and secret names. These can be derived from the original metadata of the secure client. The secret name can be an alphanumeric sequence - such as a secret ID - and will never be visible to the secure client in plain text or otherwise.

[0061] In addition, method 100 includes - by the secure client via the trusted firmware - submitting 106 a query to the bound HSM for obtaining HSM configuration data. Based on the binding between the secure client and the HSM, this query is possible because it is a non-sensitive request, e.g., does not involve keys protected by the HSM. The configuration data can be available in the form of, for example, a master key verification mode (MKVP).

[0062] Furthermore, once it is determined 108 - by the secure client - that the obtained HSM configuration data matches the policy rules available at the secure client side, method 100 also includes - by the secure client requesting 110 from the trusted firmware - to associate the secret from the pair of secret and secret name to the bound HSM, thereby triggering the trusted firmware to allow the secure client side to submit sensitive cryptographic requests to the bound and associated HSM. As a basis, the policy rules associate the HSM configuration data with the secret name.

[0063] Figure 2Block diagram 200 shows security threats even when using trusted firmware and / or security modules. All components preferably execute as part of a computer system 202. Closely related to the computer system 202 is the trusted firmware 204, which cannot be changed by the user of the computer system and is installed and enabled during the production of the computer system 202.

[0064] Additionally, one or more hardware security modules HSM-1 206a, HSM-i 206b can be components of the computer system 202. Here, for example, an HSM master key (shown as a black horizontal key) can be stored to protect HSM-protected keys, and the HSM master key can only be accessed using well-defined and strict access procedures.

[0065] The next layer in the stack architecture is represented by the hypervisor 208, which enables the execution of secure (virtual) clients 210, 214, 215, such as virtual machines or software containers for executable code including code. The secure client 210 can exemplarily maintain a secure key 212 protected by a master key managed by one of the HSMs 206a, 206b. However, in the case where the secure key 212 might be exposed such that the secure guest 2 214 can have access to the key, i.e., by stealing 216 the key, and in the case where the HSM bound to the specific HSM-1 206a is also stolen 218, the secure key 212 might be misused by the secure guest 2 214, i.e., for the wrong guest image 214 (compare access threat 222).

[0066] If the secure client 210 knows the binding secret 218 (since such a secret might have been provided to the trusted firmware during the startup of the secure client 210), then even with the third factor 220 together with the associated secret 222 might not ultimately stop such a thread. However, a solution to this potential security threat is to never disclose the associated secret to the secure client, but rather, have the secure client reference the secret by the secret name (i.e., the identifier of the HSM), as Figure 3 discussed in the context of

[0067] Figure 3Block diagram of embodiment 300 showing more practical details of the proposed method. Here, computer system 302 includes a trusted firmware 306 which includes secure client metadata 312. On computer system 302, a hypervisor 304 is operable to host one or more secure clients 308. Additionally, an HSM 316 may be used by and / or as part of computer system 302, which includes a master key 318 and configuration data 320 in the form of, for example, a master key verification mode. Secure client metadata 312 is linked to secure client 308, and the secure client will use HSM 316; both relationships are indicated by the relevant arrows. Also notable are the pairs 314 of secrets and associated secret names as part of secure client metadata 312, and the policy 310 accessible by secure client 308.

[0068] Figure 4 Block diagram 400 showing the first step in the association of HSM 316 with secure client 308. Figure 3 Reference numerals already used have the same nominal value. In this first step, the secure client (indicated by two arrows 404) sends a request 402 to the trusted firmware 306 to establish a binding 406 between secure client 308 and HSM 316. This binding only allows non-sensitive requests from secure client 308 to HSM 316.

[0069] Figure 5 Block diagram 500 showing the second step in the association of HSM 316 with secure client 308. One of the allowed non-sensitive requests from secure client 308 to HSM 316 is a request 502 for the configuration data 320 of HSM 316. This is returned to secure client 308 in the form of a master key verification mode 504. The comparison of the received master key verification mode 504 with a set of rules – namely policy 310 – may indicate that the rules are satisfied for a particular HSM 316, thus indicating that the relationship between the master key verification mode 504 of HSM 316 and the secret name – here “abc” – is satisfied. The trusted firmware 306 is helpful in establishing this relationship as all requests to HSM 316 are routed via the trusted firmware 306 and intercepted to determine whether a sensitive or non-sensitive request is present.

[0070] Figure 6Block diagram 600 shows the third (and final) step of associating HSM 316 with secure client 308. Based on the master key verification mode 504 received in the previous step, and based on this, HSM 316 is associated with secure client 308 by requesting or via trusted firmware 306, and finally the association 604 is achieved based on the secret of the pair 314 of the secret and the secret name. As a result, HSM 316 (i) is bound to secure client 308 and (ii) associated therewith, such that now sensitive requests - i.e., encryption requests - are allowed to be sent to HSM 316. It should also be noted that the complete pair 314 of the secret and the secret name is not visible to secure client 308 at any time during this process. Thus, all conditions for secure computing are met.

[0071] Summarizing the processing steps described in the order as Figures 4 to 6 It can be illustrated that, first, the secure client requests the trusted firmware to bind the HSM to the secure client. Thereby, the trusted firmware allows the secure client to submit requests for keys without HSM protection to the HSM. Second, the secure client submits a query to the HSM to obtain HSM configuration data, i.e., the master key verification mode. Optionally, the secure client can request from the firmware to return the secret name in the secure client metadata.

[0072] Next, the secure client searches for a policy for the secret name returned by the previous request. Thereby, the master key verification mode can be associated with the secret name and the policy. For the secret name associated with the master key verification mode of the policy, the secure client requests the trusted firmware to associate the secret associated with the secret name and the metadata with the HSM from which the configuration data was retrieved. Based on this, the trusted firmware executes the association request. Finally, the trusted firmware intercepts any requests for generating HSM-protected keys and enforces that HSM-protected keys can only be processed by the HSM associated with the secret.

[0073] Figure 7 Block diagram shows an embodiment of a security system 700 for policy-based association of a hardware security module and a secure client in a secure computing environment. The system includes a processor 702 and a memory 704 operatively coupled to the processor 702, where the memory 704 stores software program code that, when executed by the processor 702, enables the processor 702 to maintain a binding between the secure client and the HSM using trusted firmware 706, where the binding enables the trusted client to send only non-sensitive requests to HSM 316 (compare the previous figures).

[0074] The processor can also use the trusted firmware 306 (compare the previous figures) as a maintenance unit to maintain pairs of secrets and secret names for secure clients, and submit queries or obtain configuration data of the HSM 708 to the bound HSM 316 by the secure clients via the trusted firmware 306 as a submission unit.

[0075] In addition, when the secure client determines that the obtained configuration data of the HSM 316 matches the policy rules available to the secure client, where the policy rules associate the configuration data of the HSM 316 with secret names, the processor is enabled for the secure client to request the trusted firmware 306 to associate the secret from the pair of secret and secret name with the bound HSM 316. Thereby, the trusted firmware is enabled to allow the secure client to submit sensitive cryptographic requests to the bound and associated HSM 316.

[0076] It should also be mentioned that all functional units, modules, and functional blocks - in particular the processor 702, the memory 704, the trusted firmware 306, and the HSM 316 - can be communicatively coupled to each other in a selected 1:1 manner for signal or message exchange. Alternatively, the functional units, modules, and functional blocks can be linked to the internal bus system 706 of the system for selective signal or message exchange.

[0077] Aspects of the present disclosure are described by narrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. Regarding any flowchart, depending on the technology involved, the operations can be performed in an order different from the order shown in a given flowchart. For example, again depending on the technology involved, two operations shown in consecutive flowchart blocks can be performed in the reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0078] A computer program product embodiment (CPP embodiment or CPP) is a term used in this disclosure to describe any group of one or more storage media (also referred to as media) collectively included in one or more groups of storage devices, the one or more groups of storage devices collectively including machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A storage device is any tangible device that can retain and store instructions used by a computer processor. By way of non-limitation, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded devices such as punched cards or pits / lands formed in the main surface of a disc, or any suitable combination of the foregoing. A computer-readable storage medium, as the term is used in this disclosure, should not be construed to store in the form of a transitory signal per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, optical pulses passing through an optical fiber cable, electrical signals transmitted through a wire and / or other transmission media. As will be understood by those skilled in the art, data is typically moved at certain incidental points in time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not render the storage device transitory because the data is not transitory when it is stored.

[0079] Figure 8 FIG. 800 shows a computing environment that includes an example of an environment for executing at least some of the computer code involved in performing the method of the present invention, the method of the present invention being, for example, a computer-implemented method for policy associating a hardware security module with a secure client in a confidential computing environment 850.

[0080] In addition to the block 850, the computing environment 800 includes, for example, a computer 801, a wide area network (WAN) 802, an end-user device (EUD) 803, a remote server 804, a public cloud 805, and a private cloud 806. In this embodiment, the computer 801 includes a processor group 810 (including processing circuitry 820 and a cache 821), a communication fabric 811, volatile memory 812, a permanent storage device 813 (including the operating system 822 and the block 850 as described above), a peripheral group 814 (including a user interface (UI), a device group 823, a storage device 824, and an Internet of Things (IoT) sensor group 825), and a network module 815. The remote server 804 includes a remote database 830. The public cloud 805 includes a gateway 840, a cloud coordination module 841, a host physical machine group 842, a virtual machine group 843, and a container group 844.

[0081] The computer 801 can take the form of a desktop computer, a laptop computer, a tablet computer, a smart phone, a smart watch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of running programs, accessing a network, or querying a database such as the remote database 830. As is well known in the computer art and depending on the technology, the performance of computer-implemented methods can be distributed among multiple computers and / or among multiple locations. On the other hand, in this presentation of the computing environment 800, the discussion focuses on a single computer, specifically the computer 801, to keep the presentation as simple as possible. The computer 801 can be located in the cloud, even if it is not shown in the cloud in Figure 8 the figure. On the other hand, the computer 801 does not need to be in the cloud unless it is definitely indicated to any extent.

[0082] The processor group 810 includes one or more computer processors of any type now known or later developed. The processing circuitry 820 can be distributed across multiple packages, such as multiple cooperating integrated circuit chips. The processing circuitry 820 can implement multiple processor threads and / or multiple processor cores. The cache 821 is memory located within the processor chip package and is generally used for data or code that should be made available for rapid access by the threads or cores running on the processor group 810. Cache memory is typically organized into multiple levels based on its relative proximity to the processing circuitry. Alternatively, some or all of the cache in the processor group can be located "off-chip". In some computing environments, the processor group 810 can be designed to work with qubits and perform quantum computing.

[0083] Computer-readable program instructions are typically loaded onto a computer 801 so that a series of operation steps are performed by a processor group 810 of the computer 801, thereby implementing a computer-implemented method such that the instructions so executed will instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method included in this document (collectively referred to as "the method of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 821 and other storage media discussed below. The program instructions and associated data are accessed by the processor group 810 to control and direct the execution of the method of the present invention. In the computing environment 800, in block 850, at least some of the instructions for performing the method of the present invention may be stored in the permanent storage device 813.

[0084] The communication structure 811 is a signal conduction path that allows the various components of the computer 801 to communicate with each other. Generally, this structure is composed of switches and conductive paths, such as switches and conductive paths that constitute a bus, a bridge, a physical input / output port, etc. Other types of signal communication paths can be used, such as fiber optic communication paths and / or wireless communication paths.

[0085] The volatile memory 812 is any type of volatile memory known now or developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Generally, volatile memory is characterized by random access, but this is not required unless specifically stated. In the computer 801, the volatile memory 812 is located in a single package and inside the computer 801. However, as an alternative or supplement, the volatile memory can be distributed across multiple packages and / or located externally with respect to the computer 801.

[0086] The permanent storage device 813 is any form of non-volatile storage for a computer known now or developed in the future. The non-volatility of this memory means that the stored data is retained regardless of whether power is supplied to the computer 801 and / or directly to the permanent memory 813. The permanent storage device 813 can be a read-only memory (ROM), but generally at least a portion of the permanent storage device allows writing of data, deletion of data, and re-writing of data. Some common forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 822 can take several forms, such as various known proprietary operating systems employing a kernel or an operating system of the open-source portable operating system interface type. The code included in block 850 generally includes at least some of the computer code involved in performing the method of the present invention.

[0087] The peripheral device group 814 includes the peripheral device group of the computer 801. The data communication connection between the peripheral devices and other components of the computer 801 can be implemented in various ways, such as a Bluetooth connection, a near-field communication (NFC) connection, a connection formed by a cable (such as a universal serial bus (USB) type cable), a plug-in connection (for example, a secure digital (SD) card), a connection formed through a local communication network, and even a connection formed through a wide area network such as the Internet. In various embodiments, the UI device group 823 may include components such as a display screen, a speaker, a microphone, wearable devices (such as goggles and smart watches), a keyboard, a mouse, a printer, a touchpad, a game controller, and a haptic device. The storage device 824 is an external memory, such as an external hard disk drive, or a pluggable memory, such as an SD card. The storage device 824 can be persistent and / or volatile. In some embodiments, the storage 824 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where the computer 801 needs to have a large amount of storage (for example, in the case where the computer 801 locally stores and manages a large database), the storage may be provided by a peripheral storage device designed to store a very large amount of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor group 825 consists of sensors that can be used in Internet of Things applications. For example, one sensor can be a thermometer, and another sensor can be a motion detector.

[0088] The network module 815 is a collection of computer software, hardware, and firmware that allows the computer 801 to communicate with other computers through the WAN 802. The network module 815 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packetizing and / or depacketizing data transmitted over the communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 815 are executed on the same physical hardware device. In other embodiments (for example, embodiments using software-defined networking (SDN)), the control function and the forwarding function of the network module 815 are executed on physically separate devices, such that the control function manages several different network hardware devices. The computer-readable program instructions for performing the methods of the present invention can generally be downloaded to the computer 501 from an external computer or an external storage device through the network adapter or network interface included in the network module 515.

[0089] The WAN 802 is any wide area network (e.g., the Internet) that is capable of transmitting computer data over non-local distances via any technology, now known or hereafter developed, for transmitting computer data. In some embodiments, the WAN may be replaced and / or supplemented by a local area network (LAN), which is designed to transmit data between devices located in a local area, such as a Wi-Fi network. The WAN and / or LAN typically includes computer hardware, such as copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0090] The end user device (EUD) 803 is any computer system used and controlled by an end user (e.g., a customer of an enterprise operating the computer 801), and may take any form discussed above in connection with the computer 801. The EUD 803 typically receives useful and beneficial data from the operation of the computer 801. For example, in the hypothetical case where the computer 801 is designed to provide recommendations to an end user, the recommendation will typically be transmitted from the network module 815 of the computer 801 to the EUD 803 via the WAN 802. In this way, the EUD 803 can display or otherwise present the recommendation to the end user. In some embodiments, the EUD 803 may be a client device, such as a thin client, thick client, mainframe, desktop computer, etc.

[0091] The remote server 804 is any computer system that provides at least some data and / or functionality to the computer 801. The remote server 804 may be controlled and used by the same entity operating the computer 801. The remote server 804 represents a machine that collects and stores useful and beneficial data used by other computers, such as the computer 801. For example, in the hypothetical case where the computer 801 is designed and programmed to provide recommendations based on historical data, the historical data may be provided to the computer 801 from the remote database 830 of the remote server 804.

[0092] A public cloud 805 is any computer system that can be used by multiple entities, which provides on-demand availability of computer system resources and / or other computing capabilities (notably data storage (cloud storage) and computing power), without direct active management by the user. Cloud computing typically exploits the sharing of resources to achieve economies of scale and consistency. The direct and active management of the computing resources of the public cloud 805 is performed by the computer hardware and / or software of the cloud orchestration module 841. The computing resources provided by the public cloud 805 are typically implemented by a virtual computing environment that runs on various computers that make up a host physical machine group 842, which is the universe of physical computers in and / or available to the public cloud 805. The virtual computing environment (VCE) typically takes the form of virtual machines from a virtual machine group 843 and / or containers from a container group 844. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after instantiation of the VCE. The cloud orchestration module 841 manages the transfer and storage of images, deploys new instantiations of the VCE, and manages the active instantiations of the VCE deployment. The gateway 840 is a collection of computer software, hardware, and firmware that allows the public cloud 805 to communicate via the WAN 802.

[0093] Some further explanations of the virtualized computing environment (VCE) will now be provided. The VCE can be stored as an "image". New active instances of the VCE can be instantiated from this image. Two common types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows for the existence of multiple isolated user space instances, called containers. From the perspective of the programs running within them, these isolated user space instances typically appear as actual computers. A computer program running on a normal operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU capabilities, and quantifiable hardware capabilities. However, a program running within a container can only use the contents of the container and the devices allocated to the container, which is a feature known as containerization.

[0094] A private cloud 806 is similar to a public cloud 805, except that the computing resources are only available to a single enterprise. Although the private cloud 806 is depicted as communicating with the WAN 802, in other embodiments, the private cloud can be completely disconnected from the Internet and only accessible through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types) that are typically implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable coordination, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, the public cloud 805 and the private cloud 806 are both part of the larger hybrid cloud.

[0095] It should also be noted that the security system 700 for policy-based association of a hardware security module and a secure client in a confidential computing environment can be an operating subsystem of the computer 801 and can be attached to the computer's internal bus system.

[0096] The terms used herein are for the purpose of describing particular embodiments only and are not intended to limit the invention. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the terms "comprises" and / or "comprising", when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0097] All apparatus or steps in the following claims, plus the corresponding structures, materials, acts, and equivalents of the functional elements, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of the invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the invention to the disclosed form. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the invention. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, and to enable others of ordinary skill in the art to understand the invention in various embodiments with various modifications as are suited to the particular use contemplated.

[0098] In summary, the concepts of the present invention can be summarized by the following clauses:

[0099] 1. A computer-implemented method for policy-based association of a hardware security module HSM and a secure client in a confidential computing environment, the method comprising:

[0100] - The trusted firmware maintains the binding between the secure client and the HSM, where the binding enables the trusted client to send only non-sensitive requests to the HSM.

[0101] - The trusted firmware maintains pairs of secrets and secret names for the secure client.

[0102] - The secure client submits a query for obtaining HSM configuration data to the bound HSM via the trusted firmware.

[0103] - When the secure client determines that the obtained HSM configuration data matches the policy rules available to the secure client, where the policy rules associate the HSM configuration data with secret names.

[0104] - The secure client requests the trusted firmware to associate the secret from the pair of secret and secret name with the bound HSM, thereby triggering the trusted firmware to allow the secure client to submit sensitive encryption requests to the bound and associated HSM.

[0105] 2. The method according to clause 1, further comprising:

[0106] - The trusted firmware intercepts each request from the secure client to the HSM for generating an HSM-protected key, and

[0107] - The trusted firmware enforces that the generated HSM-protected key is used only with the HSM associated with the secret from the secure client.

[0108] 3. The method according to clause 1 or 2, where the HSM master key verification mode indicates the configuration data of the HSM.

[0109] 4. The method according to any one of clauses 1 to 3, where the pair of secret and secret name is added to the metadata maintained by the trusted firmware for the secure client.

[0110] 5. The method according to any one of clauses 1 to 4, further comprising:

[0111] - The secure client requests the trusted firmware for a list of secret names of the pair of secret and secret name maintained by the trusted firmware for the secure client.

[0112] 6. The method according to any one of clauses 1 to 5, further comprising:

[0113] - If the obtained configuration data of the HSM does not match the policy rules,

[0114] -The security client submits a new query for obtaining other configuration data to another HSM via the trusted firmware.

[0115] 7. The method according to any one of clauses 1 to 6, further comprising:

[0116] -When the allocated configuration of the HSM bound to the security client changes,

[0117] -Release the binding between the HSM and the security object, and

[0118] -If there is an association between the HSM and any secret, release the association.

[0119] 8. The method according to any one of clauses 1 to 7, wherein the trusted firmware rejects all requests from the security client to an HSM not bound to the security client.

[0120] 9. The method according to any one of clauses 1 to 8, wherein when the HSM is allocated to the security client, the trusted firmware establishes the binding between the security client and the HSM according to the request of the security client to bind the HSM to the trusted firmware.

[0121] 10. The method according to any one of clauses 1 to 9, wherein the cleartext value of the secret is not accessible to the security client.

[0122] 11. The method according to any one of clauses 1 to 10, wherein any request to the HSM bound to the security client is allowed only when issued by the security client or the trusted firmware on behalf of the security client.

[0123] 12. The method according to any one of clauses 1 to 11, wherein any request from the security client to the HSM that includes an HSM-protected key is a sensitive request, or its response includes an HSM-protected key.

[0124] 13. A security system for policy-based association between an HSM and a security client in a confidential computing environment, the security system comprising

[0125] A processor and a memory operatively coupled to the processor, wherein the memory stores software program code that, when executed by the processor, enables the processor to:

[0126] -Maintain a binding between a security client and an HSM using trusted firmware, wherein the binding enables the trusted client to send only non-sensitive requests to the HSM,

[0127] - Maintain a pair of a secret and a secret name for a secure client using trusted firmware,

[0128] - Submit a query or obtain HSM configuration data from the bound HSM by the secure client via the trusted firmware,

[0129] - When the obtained HSM configuration data determined by the secure client matches the policy rules available to the secure client, wherein the policy rules associate the HSM configuration data with a secret name,

[0130] - Request by the secure client to the trusted firmware to associate the secret from the pair of the secret and the secret name with the bound HSM, thereby triggering the trusted firmware to allow the secure client to submit sensitive cryptographic requests to the bound and associated HSM.

[0131] 14. The security system according to clause 13, wherein the processor is further capable of:

[0132] - Use the trusted firmware to intercept each request to the HSM for generating an HSM-protected key, and

[0133] - Force the trusted firmware to use the generated HSM-protected key only with the HSM associated with the secret from the secure client.

[0134] 15. The security system according to clause 13 or 14, wherein the HSM master key verification mode indicates the configuration data of the HSM.

[0135] 16. The security system according to any one of clauses 13 to 15, wherein the pair of the secret and the secret name is added to the metadata maintained by the trusted firmware for the secure client.

[0136] 17. The security system according to any one of clauses 13 to 16, wherein the processor is further capable of:

[0137] - Use the secure client to request from the trusted firmware a list of the secret names of the pair of the secret and the secret name maintained by the trusted firmware for the secure client.

[0138] 18. The security system according to any one of clauses 13 to 17, wherein the processor is further capable of:

[0139] - If the obtained configuration data of the HSM does not match the policy rules,

[0140] - Submit a new query for obtaining other configuration data to another HSM by the secure client via the trusted firmware.

[0141] 19. A security system according to any of clauses 13 to 18, wherein the processor is further capable of:

[0142] - when the allocation configuration of said HSM bound to a secure client changes,

[0143] - unbinding the HSM from the secure client, and

[0144] - If there is an association of the HSM with any secret, then the association is disassociated.

[0145] 20. A security system according to any of clauses 13 to 19, wherein the processor is further capable of:

[0146] All requests from a secure client to an HSM not bound to the secure client are denied using the trusted firmware.

[0147] 21. A security system according to any one of clauses 13 to 20, wherein, when the HSM is assigned to the security client, the binding between the security client and the HSM is established by the trusted firmware based on a request from the security client to bind the HSM.

[0148] 22. A security system according to any of clauses 13 to 21, wherein the plaintext value of the secret is not accessible to the secure client.

[0149] 23. A security system according to any of clauses 13 to 22, wherein any request to the HSM bound to the secure client is allowed only if issued by the secure client or by the trusted firmware on behalf of the secure client.

[0150] 24. A security system according to any of clauses 13 to 23, wherein any request from a secure client to the HSM that includes an HSM-protected key is a sensitive request, or a response thereof includes an HSM-protected key.

[0151] 25. A computer program product for policy-based association of an HSM with a secure client in a confidential computing environment, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by one or more computing systems or controllers to cause the one or more computing systems to:

[0152] - maintaining a binding between a secure client and an HSM using trusted firmware, wherein the binding enables the trusted client to send only non-sensitive requests to the HSM,

[0153] - Maintain a pair of a secret and a secret name for a secure client using trusted firmware,

[0154] - Submit a query or obtain HSM configuration data from the bound HSM by the secure client via the trusted firmware,

[0155] - When the secure client determines that the obtained HSM configuration data matches a policy rule available to the secure client, where the policy rule associates the HSM configuration data with a secret name,

[0156] - Request by the secure client to the trusted firmware to associate the secret from the pair of the secret and the secret name with the bound HSM, thereby triggering the trusted firmware to allow the secure client to submit sensitive cryptographic requests to the bound and associated HSM.

Claims

1. A computer-implemented method for policy-based association of a Hardware Security Module (HSM) and a secure client in a confidential computing environment, the method comprising: - Maintaining, by a trusted firmware, a binding between the secure client and the HSM, wherein the binding enables the trusted client to send only non-sensitive requests to the HSM, - Maintaining, by the trusted firmware, a pair of a secret and a secret name for the secure client, - Submitting, by the secure client via the trusted firmware, a query to the bound HSM for obtaining HSM configuration data, - When the obtained HSM configuration data is determined by the secure client to match policy rules available to the secure client, wherein the policy rules associate the HSM configuration data with a secret name, - Requesting, by the secure client from the trusted firmware, to associate the secret from the pair of the secret and the secret name with the bound HSM, thereby triggering the trusted firmware to allow the secure client to submit sensitive cryptographic requests to the bound and associated HSM.

2. The method according to claim 1, further comprising: - Intercepting, by the trusted firmware, each request from the secure client to the HSM for generating an HSM-protected key, and - Enforcing, by the trusted firmware, that the generated HSM-protected key is used only with the HSM associated with the secret from the secure client.

3. The method according to claim 1 or 2, wherein The HSM master key verification mode indicates the configuration data of the HSM.

4. The method according to any one of claims 1 to 3, wherein The pair of the secret and the secret name is added to the metadata maintained by the trusted firmware for the secure client.

5. The method according to any one of claims 1 to 4, further comprising: - Requesting, by the secure client from the trusted firmware, a list of secret names of the pair of the secret and the secret name maintained by the trusted firmware for the secure client.

6. The method according to any one of claims 1 to 5, further comprising: - If the obtained configuration data of the HSM does not match the policy rules, - Submitting, by the secure client via the trusted firmware, a new query to another HSM for obtaining other configuration data.

7. The method according to any one of claims 1 to 6, further comprising: - When the assigned configuration of the HSM bound to the secure client changes, - Removing the binding of the HSM to the secure object, and - If there is an association between the HSM and any secret, removing the association.

8. The method according to any one of claims 1 to 7, wherein The trusted firmware rejects all requests from the secure client to an HSM not bound to the secure client.

9. The method according to any one of claims 1 to 8, wherein, When the HSM is assigned to the secure client, the trusted firmware establishes the binding between the secure client and the HSM according to the request of the secure client to the trusted firmware for binding the HSM.

10. The method according to any one of claims 1 to 9, wherein, The plaintext value of the secret is not accessible to the secure client.

11. The method according to any one of claims 1 to 10, wherein, Any request to the HSM bound to the secure client is allowed only when issued by the secure client or the trusted firmware on behalf of the secure client.

12. The method according to any one of claims 1 to 11, wherein, Any request from the secure client to the HSM that includes an HSM-protected key is a sensitive request, or its response includes an HSM-protected key.

13. A security system for policy-based association of an HSM with a secure client in a confidential computing environment, the security system comprising A processor and a memory operably coupled to the processor, wherein, The memory stores software program code that, when executed by the processor, enables the processor to: - Use trusted firmware to maintain a binding between the secure client and the HSM, wherein the binding enables the trusted client to send only non-sensitive requests to the HSM, - Use trusted firmware to maintain a pair of a secret and a secret name for the secure client, - Submit a query or obtain HSM configuration data from the secure client to the bound HSM via the trusted firmware, - When the secure client determines that the obtained HSM configuration data matches the policy rules available to the secure client, wherein the policy rules associate the HSM configuration data with a secret name, - Request by the secure client to the trusted firmware to associate the secret from the pair of the secret and the secret name with the bound HSM, thereby triggering the trusted firmware to allow the secure client to submit sensitive cryptographic requests to the bound and associated HSM.

14. The security system according to claim 13, wherein, The processor is also able to: - Use the trusted firmware to intercept each request to the HSM for generating an HSM-protected key, and - Force the trusted firmware to use the generated HSM-protected key only with the HSM associated with the secret from the secure client.

15. The security system according to claim 13 or 14, wherein, The HSM master key verification mode indicates the configuration data of the HSM.

16. The security system according to any one of claims 13 to 15, wherein, The pair of the secret and the secret name is added to the metadata maintained by the trusted firmware for the secure client.

17. The security system according to any one of claims 13 to 16, wherein, The processor is also able to: - Use the secure client to request from the trusted firmware a list of the secret names of the pair of the secret and the secret name maintained by the trusted firmware for the secure client.

18. The security system according to any one of claims 13 to 17, wherein, The processor is also able to: - If the obtained configuration data of the HSM does not match the policy rules, - Submit a new query for obtaining other configuration data from the secure client to another HSM via the trusted firmware.

19. The security system according to any one of claims 13 to 18, wherein, The processor is also able to: - When the allocated configuration of the HSM bound to the secure client changes, - Release the binding between the HSM and the secure client, and - If there is an association between the HSM and any secret, release the association.

20. The security system according to any one of claims 13 to 19, wherein The processor is also able to: Use the trusted firmware to reject all requests from the secure client to an HSM not bound to the secure client.

21. The security system according to any one of claims 13 to 20, wherein, When the HSM is allocated to the secure client, the trusted firmware establishes the binding between the secure client and the HSM according to the request from the secure client to the trusted firmware for binding the HSM.

22. The security system according to any one of claims 13 to 21, wherein, The plaintext value of the secret is not accessible to the secure client.

23. The security system according to any one of claims 13 to 22, wherein, Any request to the HSM bound to the secure client is allowed only if issued by the secure client or the trusted firmware on behalf of the secure client.

24. The security system according to any one of claims 13 to 23, wherein, Any request from the secure client to the HSM that includes an HSM-protected key is a sensitive request, or its response includes an HSM-protected key.

25. A computer program product for policy-based association of an HSM with a secure client in a confidential computing environment, the computer program product comprising a computer-readable storage medium having program instructions embodied therewith, the program instructions executable by one or more computing systems or controllers to cause the one or more computing systems to: - Use trusted firmware to maintain the binding between the secure client and the HSM, where The binding enables the trusted client to send only non-sensitive requests to the HSM. - Maintain pairs of secrets and secret names for the secure client using trusted firmware. - Submit queries or obtain HSM configuration data from the secure client to the bound HSM via the trusted firmware. - When the obtained HSM configuration data is determined by the secure client to match the policy rules available to the secure client, wherein the policy rules associate the HSM configuration data with a secret name. - Request by the secure client to the trusted firmware to associate the secret from the pair of secrets and secret names with the bound HSM, thereby triggering the trusted firmware to allow the secure client to submit sensitive cryptographic requests to the bound and associated HSM.

Images