Selecting an HSM to associate with a secure guest

Abstract

A method for policy-based association of a hardware security module to a secure guest is disclosed. The method includes maintaining a binding between the secure guest and an HSM, whereby the binding allows the trusted guest to send only non-confidentiality requests to the HSM. The method further includes maintaining a pair of secrets and secret names for the secure guest, 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 guest (where the rule associates the HSM with a secret name), requesting that the secret from the pair of secrets and secret names be associated with the bound HSM, thereby triggering the trusted firmware to allow the secure guest to submit confidentiality cryptographic requests to the bound and associated HSM. (Figure 1)

Description

[Technical Field]

[0001] The present invention relates generally to a method for a policy-based secure computing environment, and more particularly to a computer-implemented method for policy-based association of hardware security modules to secure guests in a secure computing environment. The present invention further relates to an associated security system and computer program product for policy-based association of hardware security modules to secure guests in a secure computing environment. [Background technology]

[0002] The security of data and communication channels continues to be one of the highest priorities for corporate IT (information technology) management. This is necessary not only due to government regulations (e.g., GDPR, EU General Data Protection Regulation), but also due to the loss of credibility of companies that fail to consistently protect customer data in the event of compromised customer data records, and to avoid lost sales and profits. Additionally, depending on the country of data breach, fines may be required. It can be seen that data protection and providing a secure computing platform involve not only software challenges but also hardware modules. This may not yet be the natural environment for mass-market CPU chips used in microcontrollers, personal computers, mobile phones, or home automation devices. However, for highly trusted enterprise-class computing environments, such as those used in the financial, insurance, or government industries, it is essential from a technical perspective to be able to demonstrate a very high probability of preventing data breaches. This may require several additional high-tech components and support processes. However, the associated success in terms of data security is well worth the additional effort.

[0003] These concepts are also applicable to trusted and / or confidential computing environments in which cryptographic keys used by virtual machines (also denoted as guests) or software containers running on / within a hypervisor cannot be accessed by the hypervisor or associated software management and configuration programs. Nevertheless, even in such computing environments, violations of basic security rules, such as the disclosure of private keys or the use of private keys of secure guest images via the hypervisor, remain possible. This may be possible even in environments where hardware security modules (HSMs) have been used for quite some time.

[0004] There are already several disclosures that fit into the context of policy-based association of hardware security modules to secure guests in confidential computing environments. US Patent Application Publication No. 2020 / 0 076 607 A1 describes how secrets are securely maintained on a virtual computer system by configuring a specialized virtual machine to manage and maintain sequents on behalf of an application. When an application requests access to a secret, the control domain, in combination with the specialized virtual machine, verifies that the application is authorized to make the request and that the application has not been compromised prior to the request.

[0005] Additionally, US Patent Publication 2017 / 0 310 652 A1 describes a system that can transmit data to a first entity to indicate an association between the first entity and a public key, whereby the public key is to 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 transmit an indication to the second entity that the data is valid. The system can be a cryptographic service that is partially implemented by the first and second entities.

[0006] A problem in such an environment can be identified in the context of using an additional key as part of the virtual guest system's metadata under the control of the hypervisor. However, if the additional key were provided by the virtual guest system, it would be known to the virtual guest system, where it could be stolen like any other credential. Technologies such as openCryptoki or CCA (Common Cryptographic Architecture) are not yet able to meet this requirement succinctly.

[0007] Therefore, a need exists to provide a secure binding method between a virtual machine and a hardware security module so that the virtual machine does not have specific knowledge of the underlying configuration that allows such binding. Summary of the Invention

[0008] According to one aspect of the present invention, a computer-implemented method for policy-based association of a hardware security module (HSM) with a secure guest in a confidential computing environment may be provided. The method may include maintaining a binding between the secure guest and the HSM by trusted firmware, whereby the binding may enable the secure guest to send only non-confidential requests to the HSM.

[0009] The method may also include maintaining, by the trusted firmware, pairs of secrets and secret names for the secure guest, and submitting, by the secure guest, via the trusted firmware, queries to the bound HSM to obtain HSM configuration data.

[0010] Additionally, upon determining by the secure guest that the obtained HSM configuration data matches a policy rule available to the secure guest, the method may include requesting from the trusted firmware by the secure guest to associate a secret from the secret and secret name pair with the bound HSM. The policy rule may thereby associate the HSM configuration data with the secret name. As a result, the trusted firmware may allow the secure guest to submit confidential cryptographic requests to the bound and associated HSM.

[0011] According to another aspect of the present invention, a security system for policy-based association of hardware security modules to secure guests in a confidential computing environment may be provided. The system may include a processor and a memory operatively coupled to the processor, wherein the memory stores software program code that, when executed by the processor, causes the processor to maintain a binding between a secure guest and an HSM using trusted firmware, wherein the binding enables the trusted guest to send only non-confidential requests to the HSM, and enables a pair of secret and secret name to be maintained for the secure guest using trusted firmware.

[0012] The processor may also enable the secure guest, via the trusted firmware, to submit queries to the bound HSM or obtain HSM configuration data, and upon determining by the secure guest that the obtained HSM configuration data matches a policy rule available to the secure guest, the processor may enable the secure guest from the trusted firmware to request that a secret from a secret and secret name pair be associated with the bound HSM, whereby the policy rule may associate the HSM configuration data with a secret name.

[0013] As a result, the trusted firmware may allow a secure guest to submit confidential cryptographic requests to a bound and associated HSM.

[0014] The proposed computer-implemented method for policy-based association of hardware security modules to secure guests in confidential computing environments may provide multiple advantages, technical effects, contributions and / or enhancements.

[0015] The link established between a secure guest and an HSM can essentially be performed in a two-step process: (a) establishing a binding between the secure guest and the HSM, and (b) establishing an association between the same secure guest and the same HSM. The binding can thereby allow only non-confidential requests to the HSM, so that neither the request nor the response can be corrupted or accessible by untrusted components. An additional association can thereby allow confidentiality requests from the secure guest to the HSM. This can allow protecting a confidential computing environment in three ways: (i) against disclosure of secrets (e.g., security keys), (ii) against use of secrets protected by the HSM by an incorrect guest image, and (iii) against use of secrets protected by the HSM by an incorrect guest instance. In the same way, the secrets used to establish this protection can be protected against disclosure or use by an incorrect guest image or guest instance. The secrets in a secret-secret-name pair can thereby never be visible to the secure guest on the hypervisor and therefore cannot be stolen from the secure guest. Only trusted firmware has full access to this highly sensitive data.

[0016] Additionally, the policy-based association may allow the secure guest to select a particular HSM from among multiple HSMs assigned to the secure guest to assign secrets intended to protect HSM-protected keys for a particular workload / application intended to use the particular HSM.

[0017] Additionally, policy-based association may allow a secure guest to refuse to use an HSM whose configuration is not included in the policy, thereby avoiding the risk of using an HSM belonging to an attacker.

[0018] Additionally, an optional but possible feature for unbinding and disassociating HSMs that are deallocated from a secure guest results in presenting a binding error when using a temporarily deallocated (and then reallocated) HSM, allowing the guest to be aware of the temporary reallocation and reassess the validity of the HSM to ensure that it is not replaced or reconfigured during the period it is deallocated.

[0019] In the following, additional embodiments of the inventive concepts are described that are applicable to methods and systems.

[0020] According to an advantageous embodiment, the method may also comprise the step of intercepting, by the trusted firmware, each request from the secure guest to the HSM to generate an HSM-protected key, and enforcing, by the trusted firmware, that the generated HSM-protected key be used only with the HSM associated with the secret from the secure guest. That is, it is not sufficient for an HSM to be bound to a secure guest to ensure a secure communication channel between them (or vice versa); it is additionally necessary that the association between the secure guest and the HSM be established so that the HSM-protected key can be used exclusively by the secure guest. In other words, a two-step process (first, binding, second, associating) must be performed before confidential cryptographic requests can be executed by the HSM in response to a secure guest request. In this case, the interception by the trusted firmware of each request from the secure guest to the HSM can serve to make the HSM-protected key usable by the secure guest configured with a specific (association) secret.

[0021] According to any embodiment of the method, an HSM master key verification pattern (MKVP) may represent the configuration data of the HSM. That is, all settings and configuration data and capabilities of a particular HSM may be codified, and therefore interpretable, by requesting a secure guest in a master key verification pattern. This may enable a secure guest to use the master key verification pattern for comparison against policy-based rules and select an HSM appropriate for its requirements.

[0022] According to another advantageous embodiment of the method, the secret and secret name pair may be added to metadata that the trusted firmware may maintain for the secure guest, whereby such metadata may be maintained by the trusted firmware separately for each secure guest instance.

[0023] According to a preferred embodiment, the method may also comprise requesting, by the secure guest, from the trusted firmware, a list of secret names of the pairs of secrets and secret names maintained by the trusted firmware for the secure guest, which may be implemented by a call interface or API (application programming interface) on behalf of the secure guest to the trusted firmware.

[0024] According to advanced embodiments, the method may also include, if the retrieved configuration data of an HSM does not match a policy rule, submitting, by the secure guest via the trusted firmware, a new query to another HSM to retrieve other configuration data. In this manner, the secure guest may identify an HSM in accordance with policy-based rules for selection of an HSM appropriate for the secure guest. That is, a step-and-repeat process may be established to identify an HSM that meets the requirements of the secure guest.

[0025] According to a useful and security-enhancing embodiment, the method may also comprise, upon a change in the allocation configuration of the HSM bound to a secure guest, dissolving the binding of the HSM to the secure guest and dissolving the association of the HSM with any secrets, if such an association exists. This may disable the ability to use the HSM by the secure guest; i.e., a reset of the binding and association between the secure guest and the HSM may be established. In other words, any bound HSM should become unbound when its allocation is changed; i.e., if an HSM is associated with a secret, this association must also become "unassociated." This must occur automatically and atomically, i.e., HSM to HSM and secure guest to secure guest, to comply with the regulations of confidential computing environments.

[0026] According to a further interesting embodiment of the method, the trusted firmware may reject all requests (in particular confidentiality requests) from a secure guest to an HSM that are not bound to the secure guest. Consequently, firstly, binding may need to be established before association can occur before a confidentiality request can be addressed from a secure guest to an HSM.

[0027] According to another interesting embodiment of the method, the binding between the secure guest and the HSM may be established by the trusted firmware upon a request from the secure guest to the trusted firmware to bind the HSM if the HSM is assigned to the secure guest. It may be noted that such a process may only be possible for those HSMs visible to the secure guest. This may also apply to assignment configurations.

[0028] According to an embodiment that enhances the security of the method, the plaintext value of the secret shall be inaccessible by the secure guest, i.e., the secret maintained by the trusted firmware may also not be stolen from the secure guest, since the secure guest never has access to it.

[0029] According to a further useful embodiment of the method, any request to the HSM coupled to the secure guest may only be permitted if issued by the secure guest or the trusted firmware on behalf of the secure guest. Therefore, other secure guests or any other entities may not be permitted to access the associated HSM by any sidetrack. Thus, the governing rules of confidential computing may always be applied.

[0030] According to additional embodiments of the method, any request from a secure guest to an HSM that may comprise an HSM-protected key, or whose response (particularly to a request) comprises an HSM-protected key, may be a confidentiality request. Such classification may ensure that a clear distinction between non-confidentiality requests and confidentiality requests can always be guaranteed in order to comply with confidential computing regulations.

[0031] Furthermore, embodiments may take the form of an associated computer program product accessible from a computer-usable or computer-readable medium that provides program code for use by or in connection with a computer or any instruction execution system. For purposes of this specification, a computer-usable or computer-readable medium may be any apparatus that may include means for storing, communicating, propagating, or transporting a program for use by or in connection with an instruction execution system, apparatus, or device. [Brief explanation of the drawings]

[0032] It should be noted that embodiments of the present invention are described with reference to different subject matters. In particular, some embodiments are described with reference to method-type claims, while other embodiments are described with reference to apparatus-type claims. However, a person skilled in the art will infer from the above and below description that, unless otherwise stated, any combination of features belonging to one type of subject matter, as well as any combination between features relating to different subject matters, in particular between features of method-type claims and features of apparatus-type claims, is considered to be disclosed within this specification.

[0033] The above-defined aspects and further aspects of the invention will be apparent from and will be explained with reference to the example embodiments described hereinafter, to which the invention is not limited.

[0034] Preferred embodiments of the present invention will now be described, by way of example only, with reference to the following drawings:

[0035] [Figure 1] 1 shows a flowchart of an embodiment of an inventive computer-implemented method for policy-based association of hardware security modules to secure guests in a confidential computing environment.

[0036] [Figure 2]2 shows a block diagram of a basic potential embodiment 200 with multi-factor authentication.

[0037] [Figure 3] A more practical detailed embodiment 300 of the proposed method is shown, in particular a block diagram of the relevant components.

[0038] [Figure 4] 1 shows a block diagram of the first stage of associating an HSM to a secure guest.

[0039] [Figure 5] 1 shows a block diagram of the second stage of association of an HSM to a secure guest.

[0040] [Figure 6] 10 shows a block diagram of the third stage of associating an HSM to a secure guest.

[0041] [Figure 7] 1 illustrates a block diagram of an embodiment of an inventive security system for policy-based association of hardware security modules to secure guests in a confidential computing environment.

[0042] [Figure 8] 8 shows an embodiment of a computing system comprising a system according to FIG. 7. DETAILED DESCRIPTION OF THE INVENTION

[0043] In the context of this description, the following technical phrases, terms and / or expressions may be used:

[0044] The term "hardware security module" (HSM) may refer to a hardware element connected to or integrated into a computer system, such as a server system, e.g., a manufacturing server computer here. HSMs are designed to prevent tampering and protect secrets, i.e., software keys, against unauthorized access, even against unscheduled physical penetration and / or physical removal. HSMs may be closely linked to a CPU or may operate independently from the CPU. In other words, an HSM is a physical computing device that safeguards and manages one or more digital keys for strong authentication and provides cryptographic processing. These modules may traditionally come in the form of plug-in cards or external devices that can be directly attached to a computer or network server.

[0045] The term "secure guest" may refer to a virtual machine or software container with program code executable in a secure computing environment protected by a trusted execution environment, so that untrusted components of the computer system cannot observe any state (memory or registers) of the running secure guest. It may be, for example, a generic guest image, which may also be provided by a third party, such as a software house. Typical untrusted components are software hypervisors, hardware management consoles, and other guests.

[0046] The term "confidential computing environment" may refer to a computing environment in which a hypervisor or any system management software with a user interface component may not have access to any cleartext content or other state of a virtual machine.

[0047] The terms "binding" or "binding a hardware security module to a secure guest" may indicate that a link protected and controlled by trusted firmware has been established between the secure guest and the bound hardware security module. The binding may establish a secure channel between the secure guest or trusted firmware, and the HSM may ensure the integrity and confidentiality of communications between the secure guest and the bound HSM. However, the binding may only allow non-confidential, i.e., non-cryptographic, requests from the bound secure guest to the HSM. In contrast, if an additional association between the secure guest and the HSM is established, only confidential cryptographic requests from the secure guest to the HSM may be allowed and controlled by the trusted firmware.

[0048] The terms "association" or "associating a secure guest with an HSM" may indicate that a second relationship (in addition to the binding between the secure guest and the HSM) may be established between the same secure guests on the same HSM (specifically, an association between two entities). The technical basis for this may be the secret and the name of the secret, and the sequence of steps described by the method. Additionally, the association between a secure guest and the associated HSM may be "policy-based" in the sense that the secure guest may have access to a set of rules that describe (among other things) the requirements or configuration settings of the HSM that shall be associated with the secure guest.

[0049] The term "non-confidential request" may refer to a non-cryptographic request to the HSM, e.g., a request from a secure guest to the HSM via trusted firmware that only allows requests for configuration data. In contrast, the term "confidential request" or "confidential cryptographic request" may refer to a request to the HSM with an encryption or decryption command. In particular, a request to use or return a key protected by the HSM may be confidential.

[0050] The term "trusted firmware" (trusted FW or TFW) may refer to a component deeply embedded in the hardware of a computing (mainframe) system that may not be accessed by any other user-controlled software. Trusted firmware may have a predefined, highly secure application programming interface to protect the functionality of the trusted firmware (broadly defined). Trusted FW should be considered more as a deeply integrated component of the computer system instead of a service component. The communication channel to and from trusted firmware is usually cryptographically protected.

[0051] The term "metadata" may refer in its classical sense to information about data, here in particular to data required to start a virtual machine. In a confidential computing environment, such information may be used by trusted firmware to start a secure virtual machine, as well as include, for example, an integrity measure of the image of the secure guest or a key required to decrypt the image of the secure guest. These metadata may comprise, for example, the required resources, the required interfaces, the required performance, and (in some cases) which security measures are appropriate. The extension of the metadata to be used by trusted firmware (e.g., in terms of required binding information, but more specifically in terms of pairs of secrets and secret names) represents one of the cornerstones of the proposed concept.

[0052] The term "secret and secret name pair" may indicate that a secret (potentially used for association between a secure guest and an HSM) may be associated in a one-to-one manner with a secret name, e.g., an identifier of an HSM, to form the basis for an association (i.e., not a pre-established binding) between a secure guest and an HSM.

[0053] The term "HSM configuration data" may refer to a set of information that describes the capabilities and settings of an associated HSM. This may be codified in a data set denoted as a Master Key Verification Pattern (MKVP).

[0054] The term "allocated configuration" may refer to aspects of the configuration of a system component or virtual server that may define that the virtual server's components are granted visibility and possibly basic access to devices similar to HSMs. In the case of a standard guest, the allocated device may be discovered and used by the guest. In the case of a secure guest, the allocated device may be discovered by the secure guest, but it must be bound (and associated with a secret) to be used.

[0055] The term "hypervisor" may refer to a well-defined type of computer software or firmware that creates and runs virtual machines or software containers. Thus, multiple virtual machines / software containers may run in parallel without any risk of cross-referencing. The failure of a virtual machine may not cause any harm to another virtual machine. Each virtual machine may possess a defined address space.

[0056] The term "policy" may refer to a description of an intended configuration, typically stored in a file. A policy may establish a correspondence between an HSM specification and a secret. The definition of that correspondence may be indirect in nature. For example, a secret may be referenced by its name, and an HSM specification may be referenced by HSM characteristics that can be queried as well as HSM configuration data, including master key verification patterns.

[0057] In the following, a detailed description of the figures is provided. All instructions in the figures are schematic. First, a block diagram of an embodiment of the inventive computer-implemented method for policy-based association of hardware security modules to secure guests in a confidential computing environment is provided. Afterwards, further embodiments, as well as embodiments of a security system for policy-based association of hardware security modules to secure guests in a confidential computing environment, are described.

[0058] FIG. 1 shows a flowchart of a preferred embodiment of a computer-implemented method 100 for policy-based association of a hardware security module to a secure guest in a confidential computing environment. The secure guest can be a virtual machine running on / in a hypervisor or a software container. The method comprises a step 102 of maintaining (by the trusted firmware) a binding between the secure guest and the HSM. Note also that there is no binding secret; in the proposed concept, there is only an association secret. Thus, the binding allows the trusted guest to send only non-confidential requests to the HSM. The binding secret can be sent by the secure guest to the trusted firmware at the secure guest's runtime (as an example) due to an extension of the secure guest's metadata in the trusted firmware. An alternative implementation comprises binding setup during the secure guest's startup. Alternative implementations are also possible. However, a strict distinction should be made between binding of a secure guest to an HSM and association of a secure guest to an HSM.

[0059] The method 100 also includes maintaining 104, by the trusted firmware, a pair of secret and secret name for the secure guest. These may originate from the secure guest's original metadata. The secret name (like the secret ID) may be an alphanumeric sequence that is never seen in plain text or otherwise invisible to the secure guest.

[0060] Additionally, method 100 includes submitting 106 a query by the secure guest, via the trusted firmware, to the bound HSM to obtain HSM configuration data. This query can be based on the binding between the secure guest and the HSM because it is a non-confidential request that does not involve, for example, keys protected by the HSM. The configuration data can be available, for example, in the form of a Master Key Verification Pattern (MKVP).

[0061] Furthermore, upon determining 108 by the secure guest that the obtained HSM configuration data matches a policy rule available to the secure guest, method 100 also comprises triggering 110 a request by the secure guest from the trusted firmware to associate the secret from the pair of secret and secret name with the bound HSM, thereby causing the trusted firmware to authorize the secure guest to submit confidential cryptographic requests to the bound and associated HSM, based on policy rules associating HSM configuration data with secret names.

[0062] 2 shows a block diagram 200 of security threats, even when using trusted firmware and / or security modules. All components preferably run as part of computer system 202. Associated very closely with computer system 202 is trusted firmware 204, which cannot be altered by the user of the computer system and which is installed and enabled during production of computer system 202.

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

[0064] The next layer in the stacked architecture is represented by hypervisor 208, which enables the execution of secure (virtual) guests 210, 214, 215, e.g., virtual machines or software containers comprising executable files of code. Secure guest 210 may illustratively maintain a secure key 212, which may be protected by a master key managed by one of HSMs 206a, 206b. However, in situations where secure key 212 may be exposed, such that secure guest-2 214 may have access to it (i.e., by stealing 216 its key), and if the HSM binding to a particular HSM-1 206a is stolen 218, private key 212 may be misused by secure guest-2 214, i.e., for the wrong guest image 214 (comparison access threat 222).

[0065] If the secure guest 210 knows the binding secret 218 (as may have been provided to the trusted firmware during the startup of the secure guest 210), then even the association secret 222 together with the third factor 220 may not ultimately stop such a thread. However, the solution to this potential security threat is never to reveal the association secret to the secure guest, but instead to allow the secure guest to refer to the secret by its name (i.e., the HSM's identifier), as explained in the context of FIG.

[0066] Figure 3 shows a block diagram of an embodiment 300 of the proposed method in more practical details. Here, a computer system 302 comprises trusted firmware 306 including secure guest metadata 312. In the computer system 302, a hypervisor 304 is operable to host one or more secure guests 308. Furthermore, an HSM 316 is available to and / or part of the computer system 302, comprising a master key 318 and configuration data 320, e.g., in the form of a master key verification pattern. The secure guest metadata 312 is linked to the secure guest 308, which shall use the HSM 316; both relationships are indicated by the associated arrows. Of note are also a pair 314 of secrets and associated secret names as part of the secure guest metadata 312, as well as a policy 310 accessible by the secure guest 308.

[0067] 4 shows a block diagram 400 of the first stage in the association of an HSM 316 with a secure guest 308. Reference numbers already used in FIG. 3 have the same nominal value. In this first stage, the secure guest (indicated by two arrows 404) sends a request 402 to the trusted firmware 306 to establish a binding 406 between the secure guest 308 and the HSM 316. This binding allows only non-confidential requests from the secure guest 308 to the HSM 316.

[0068] 5 shows a block diagram 500 of the second stage in the association of an HSM 316 with a secure guest 308. One of the permitted non-confidential requests from the secure guest 308 to the HSM 316 is a request 502 for the HSM's 316 configuration data 320. This is returned to the secure guest 308 in the form of a master key verification pattern 504. A comparison of the received master key verification pattern 504 with a set of rules (i.e., policies 310) may indicate that the rules have been satisfied for a particular HSM 316, thereby satisfying the relationship between the master key verification pattern 504 and the secret name (here, "abc") representing the HSM 316. The trusted firmware 306 helps establish this relationship because all requests to the HSM 316 are routed through the trusted firmware 306 and intercepted to determine whether a confidential or non-confidential request is being submitted.

[0069] 6 shows a block diagram 600 of the third (and final) stage of associating the HSM 316 with the secure guest 308. Based on the received master key verification pattern 504 in the previous stage and a request to or via the trusted firmware 306 to associate the HSM 316 with the secure guest 308, the association 604 is finally achieved based on the secret of the secret-secret name pair 314. As a result, the HSM 316 is (i) bound to and (ii) associated with the secure guest 308, thereby now allowing confidentiality requests (i.e., cryptographic requests) to be sent to the HSM 316. Note also that the complete secret-secret name pair 314 is not visible to the secure guest 308 at any point in this process. Thus, all conditions for secure computing are met.

[0070] The process steps described as a sequence in Figures 4 to 6 can be summarized as follows: First, the secure guest requests from the trusted firmware to bind an HSM to the secure guest. The trusted firmware then allows the secure guest to submit requests to the HSM without a key protected by the HSM. Second, the secure guest submits a query to the HSM to obtain HSM configuration data, i.e., a master key verification pattern. Optionally, the secure guest may request from the firmware to return the name of the secret in the secure guest metadata.

[0071] The secure guest then searches the policy for the secret name returned by the previous request, thereby allowing a master key verification pattern to be associated with the secret name and policy. For a secret name associated with a master key verification pattern in the policy, the secure guest requests from the trusted firmware to associate the secret associated with the secret name and metadata with the HSM from which the configuration data was obtained. Based on this, the trusted firmware performs the association request. Finally, the trusted firmware intercepts any requests to generate an HSM-protected key and enforces that the HSM-protected key can only be processed by the HSM associated with the secret.

[0072] 7 shows a block diagram of an embodiment of a security system 700 for policy-based association of hardware security modules to secure guests in a confidential computing environment. The system comprises a processor 702 and a memory 704 operatively coupled to the processor 702, the memory 704 storing software program code that, when executed by the processor 702, enables the processor 702 to maintain a binding between the secure guest and the HSM using trusted firmware 706, where the binding enables the trusted guest to send only non-confidential requests of the HSM 316 (compare previous figure).

[0073] The processor also uses trusted firmware 306 (compare previous figure) as a maintenance unit to maintain pairs of secrets and secret names for secure guests, and enables secure guests to submit queries to the associated HSM 316 or obtain configuration data for the HSM 708 via trusted firmware 306 as a submission unit.

[0074] Furthermore, upon determining by the secure guest that the obtained HSM 316 configuration data matches policy rules available to the secure guest, where the policy rules associate the HSM 316 configuration data with a secret name, the processor can cause the secure guest to request from the trusted firmware 306 that the secret from the secret and secret name pair be associated with the bound HSM 316. The trusted firmware can then allow the secure guest to submit confidential cryptographic requests to the bound and associated HSM 316.

[0075] It should also be mentioned that all functional units, modules and functional blocks (particularly the processor 702, memory 704, trusted firmware 306 and HSM 316) may be communicatively coupled to each other for the exchange of signals or messages in a selected 1:1 manner. Alternatively, the functional units, modules and functional blocks may be linked to the system internal bus system 706 for the exchange of selective signals or messages.

[0076] Various aspects of the present disclosure are described through text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). For any flowchart, depending on the technology involved, operations may be performed in an order different from that shown in a given flowchart. For example, again depending on the technology involved, two operations shown in successive flowchart blocks may be performed in the reverse order, as a single integrated step, simultaneously, or in an at least partially overlapping manner.

[0077] A computer program product embodiment (CPP embodiment or CPP) is a term used in this disclosure to describe any set of one or more storage media (also called mediums) collectively contained in one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A storage device is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, 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 diskettes, 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 disk (DVD), memory stick, floppy disk, mechanically encoded device (such as punch cards or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing. A computer-readable storage medium, as the term is used in this disclosure, is not to be construed as storage in the form of a transitory signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fiber optic cable, electrical signals communicated through wires, and / or other transmission media.As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transient, as data is not transient while it is stored.

[0078] FIG. 8 illustrates a computing environment 800 comprising an example environment 850 for execution of at least some of the computer code involved in performing an inventive method, such as a computer-implemented method for policy-based association of a hardware security module to a secure guest in a confidential computing environment.

[0079] In addition to block 850, 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, computer 801 includes a set of processors 810 (including processing circuitry 820 and cache 821), a communications fabric 811, volatile memory 812, persistent storage 813 (including an operating system 822 and block 850, as identified above), a set of peripheral devices 814 (including a user interface (UI), a set of devices 823, storage 824, and a set of Internet of Things (IoT) sensors 825), and a network module 815. Remote server 804 includes a remote database 830. The public cloud 805 includes a gateway 840, a cloud orchestration module 841, a set of host physical machines 842, a set of virtual machines 843, and a set of containers 844.

[0080] Computer 801 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch 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 executing programs, accessing a network, or querying a database, such as remote database 830. As is well understood in the art of computer technology, depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or among multiple locations. While in this presentation of computing environment 800, to keep the presentation as simple as possible, the detailed discussion focuses on a single computer, specifically computer 801. Computer 801 may be located within a cloud, even though it is not depicted in the cloud of FIG. 8 . However, computer 801 is not required to be in a cloud except to any extent that may be expressly indicated.

[0081] Processor set 810 includes one or more computer processors of any type now known or later developed. Processing circuitry 820 may be distributed across multiple packages, e.g., multiple tailored integrated circuit chips. Processing circuitry 820 may implement multiple processor threads and / or multiple processor cores. Cache 821 is memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 810. Cache memory is typically organized into multiple levels depending on relative proximity to the processing circuitry. Alternatively, some or all of the cache for a processor set may be located “off-chip.” In some computing environments, processor set 810 may be designed to operate with qubits to perform quantum computing.

[0082] Computer-readable program instructions are typically loaded into computer 801 to cause a series of operational steps to be performed by processor set 810 of computer 801, thereby affecting a computer-implemented methodology, such that the instructions thus executed instantiate the methods specified in the computer-implemented method flowcharts and / or descriptions contained herein (collectively referred to as the "methods 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 described below. The program instructions and associated data are accessed by processor set 810 to control and direct the execution of the methods of the present invention. In computing environment 800, at least a portion of the instructions for performing the methods of the present invention may be stored in block 850 in persistent storage 813.

[0083] Communications fabric 811 is the signal-conducting pathway that allows the various components of computer 801 to communicate with one another. Typically, this fabric is made up of switches and conductive pathways, such as those that make up buses, bridges, physical input / output ports, and the like. Other types of signal communication pathways, such as fiber optic and / or wireless communication pathways, may be used.

[0084] Volatile memory 812 may be any type of volatile memory now known or later developed. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory is characterized by random access, although this is not required unless expressly indicated. In computer 801, volatile memory 812 is located in a single package and is internal to computer 801, although alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 801.

[0085] Persistent storage 813 is any form of non-volatile computer storage, now known or later developed. The non-volatility of this storage means that stored data remains regardless of whether power is supplied to computer 801 and / or to persistent storage 813 directly. Persistent storage 813 may be read-only memory (ROM), but typically at least a portion of persistent storage allows data to be written, data to be deleted, and data to be rewritten. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 822 can take several forms, such as various known proprietary operating systems employing a kernel or open-source Portable Operating System Interface-style operating systems. The code contained in block 850 typically includes at least some of the computer code involved in performing the methods of the present invention.

[0086] Peripheral device set 814 includes a set of peripheral devices of computer 801. Data communication connections between peripheral devices and other components of computer 801 may be implemented in various manners, such as Bluetooth connections, near field communication (NFC) connections, connections made by cable (such as a universal serial bus (USB)-type cable), insertable connections (e.g., Secure Digital (SD) cards), connections made by local area communication networks, and even connections made by wide area networks such as the Internet. In various embodiments, UI device set 823 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers, and haptic devices. Storage 824 may be external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 824 may be persistent and / or volatile. In some embodiments, storage 824 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 801 is required to have a large amount of storage (e.g., computer 801 stores and manages a large database locally), this storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. IoT sensor set 825 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.

[0087] Network module 815 is a collection of computer software, hardware, and firmware that allows computer 801 to communicate with other computers over WAN 802. Network module 815 may include hardware such as a modem or Wi-Fi® signal transceiver, software for packetizing and / or de-packetizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of network module 815 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing Software-Defined Networking (SDN)), the control and forwarding functions of network module 815 are performed on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention may be downloaded to computer 501, typically from an external computer or external storage device, through a network adapter card or network interface included in network module 515.

[0088] WAN 802 is any wide area network (e.g., the Internet) capable of communicating computer data over non-local distances by any technology for communicating computer data now known or later developed. In some embodiments, a WAN may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in a local area, such as a Wi-Fi network. WANs and / or LANs typically include copper transmission cables, optical fiber transmissions, wireless transmissions, and computer hardware such as routers, firewalls, switches, gateway computers, and edge servers.

[0089] End-user device (EUD) 803 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating computer 801) and may take any of the forms described above with respect to computer 801. EUD 803 typically receives useful and useful data from the operation of computer 801. For example, in a hypothetical case where computer 801 is designed to provide recommendations to the end user, the recommendations would typically be communicated from computer 801's network module 815 over WAN 802 to EUD 803. In this manner, EUD 803 can display or otherwise present the recommendations to the end user. In some embodiments, EUD 803 may be a client device such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

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

[0091] A public cloud 805 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, particularly data storage (cloud storage) and computing power, without direct, active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct, active management of the computing resources of the public cloud 805 is performed by computer hardware and / or software in a cloud orchestration module 841. The computing resources provided by the public cloud 805 are typically implemented by virtual computing environments running on various computers comprising a host physical machine set 842, which is the universe of physical computers within and / or available in the public cloud 805. A virtual computing environment (VCE) typically takes the form of a virtual machine from a virtual machine set 843 and / or a container from a container set 844. It is understood that these VCEs can be stored as images and can be transferred among and between various physical machine hosts either 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 active instantiations of VCE deployments. The gateway 840 is a collection of computer software, hardware, and firmware that allows the public cloud 805 to communicate over the WAN 802.

[0092] Some further description of virtualized computing environments (VCEs) is provided here. A VCE can be stored as an "image." A new, active instance of a VCE can be instantiated from the image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of an operating system in which the kernel allows the existence of multiple isolated user space instances, called containers. These isolated user space instances typically behave as real computers from the perspective of programs running within them. A computer program running on a typical operating system can utilize all of the computer's resources, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0093] Private cloud 806 is similar to public cloud 805, except that the computing resources are available only for use by a single enterprise. While private cloud 806 is shown in communication with WAN 802, in other embodiments, the private cloud may be entirely disconnected from the Internet and accessible only through a local / private network. A hybrid cloud is a composite of multiple clouds of different types (e.g., private, community, or public cloud types), often each implemented by a different vendor. While each of the multiple clouds remains a separate, discrete entity, the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this embodiment, public cloud 805 and private cloud 806 are both part of a larger hybrid cloud.

[0094] It should also be mentioned that the security system 700 for policy-based association of hardware security modules to secure guests in a confidential computing environment may be an operational subsystem of the computer 801 and may be attached to the computer's internal bus system.

[0095] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of 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 dictates otherwise. It will be further understood that the terms "comprises" and / or "comprising," when used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0096] In addition to the functional elements in the following claims, the corresponding structure, material, acts, and equivalents of all means or steps are intended to include any structure, material, or acts for performing a function in combination with other claimed elements as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the invention to the form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been chosen and described to best explain the principles of the invention and its practical application and to enable others skilled in the art to understand the invention in terms of various embodiments with various modifications as suited to the particular uses contemplated. In short, the concept of the invention can be summarized by the following items: (Item 1) 1. A computer-implemented method for policy-based association of a Hardware Security Module (HSM) with a secure guest in a confidential computing environment, the method comprising: maintaining, by trusted firmware, a binding between a secure guest and an HSM, wherein the binding enables the trusted guest to send only non-confidential requests to the HSM; maintaining a pair of secrets and secret names for the secure guests by the trusted firmware; submitting a query to the coupled HSM via the trusted firmware by the secure guest to obtain HSM configuration data. upon determining, by the secure guest, that the obtained HSM configuration data matches a policy rule available to the secure guest, wherein the policy rule associates the HSM configuration data with a secret name; requesting, by the secure guest, from 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 authorize the secure guest to submit confidentiality cryptographic requests to the bound and associated HSM. A method comprising: (Item 2) intercepting, by the trusted firmware, each request from the secure guest to the HSM to generate an HSM-protected key; and enforcing, by the trusted firmware, that the generated HSM-protected key be used only with the HSM associated with the secret from the secure guest. Item 1. The method according to item 1, further comprising: (Item 3) 3. The method according to claim 1, wherein an HSM master key verification pattern indicates the configuration data of the HSM. (Item 4) 10. The method of any of the preceding items, wherein the pair of the secret and the name of the secret is added to the metadata that the trusted firmware maintains for the secure guest. (Item 5) The method of any of the preceding items, further comprising a step of requesting, by the secure guest, from the trusted firmware, a list of secret names of the pairs of secrets and secret names maintained by the trusted firmware for the secure guest. (Item 6) the retrieved configuration data for the HSM does not match the policy rules; submitting, by the secure guest via the trusted firmware, a new query to another HSM to obtain other configuration data; 10. The method of any of the preceding items, further comprising: (Item 7) Upon changing the allocation configuration of said HSM bound to a secure guest, dissolving the binding of the HSM to the secure guest; and dissolving said association with any secrets in said HSM if such association exists. 10. The method of any of the preceding items, further comprising: (Item 8) 10. The method of any of the preceding items, wherein the trusted firmware rejects all requests from a secure guest to an HSM that are not bound to the secure guest. (Item 9) 10. The method of claim 9, wherein the binding between the secure guest and the HSM is established by the trusted firmware upon a request from the secure guest to the trusted firmware to bind the HSM when the HSM is assigned to the secure guest. (Item 10) 10. The method of any of the preceding items, wherein the secret plaintext value is inaccessible by the secure guest. (Item 11) 10. The method of claim 1, wherein any request to the HSM coupled to the secure guest is only allowed if issued by the secure guest or the trusted firmware on behalf of the secure guest. (Item 12) 10. The method of any of the preceding items, wherein any request from a secure guest to the HSM with a key protected by the HSM is a confidentiality request or the response thereof comprises a key protected by the HSM. (Item 13) 1. A security system for policy-based association of an HSM with a secure guest in a confidential computing environment, the security system comprising: a processor and a memory operatively coupled to the processor; wherein the memory, when executed by the processor, causes the processor to: maintaining a binding between a secure guest and an HSM using trusted firmware, wherein the binding allows the trusted guest to send only non-confidential requests to the HSM; a procedure for maintaining pairs of secrets and secret names for secure guests using trusted firmware; submitting a query to the coupled HSM or obtaining HSM configuration data by the secure guest via the trusted firmware; upon determining, by the secure guest, that the obtained HSM configuration data matches a policy rule available to the secure guest, wherein the policy rule associates the HSM configuration data with a secret name. requesting, by the secure guest, from 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 authorize the secure guest to submit confidentiality cryptographic requests to the bound and associated HSM. A security system storing software program code that enables the execution of (Item 14) The processor: using the trusted firmware to intercept each request to the HSM to generate a key protected by the HSM; and enforcing, by the trusted firmware, that the generated HSM-protected key be used only with the HSM associated with the secret from the secure guest. Item 14. The security system according to item 13, which is also capable of executing the following. (Item 15) 15. The security system of claim 13, wherein an HSM master key verification pattern indicates the configuration data of the HSM. (Item 16) 16. The security system of any of items 13 to 15, wherein the pair of the secret and the name of the secret is added to the metadata that the trusted firmware maintains for the secure guest. (Item 17) The processor: using the secure guest to request from the trusted firmware a list of secret names of the pairs of secrets and secret names maintained by the trusted firmware for the secure guest. 17. The security system according to any one of items 13 to 16, wherein the security system is also capable of executing the following. (Item 18) The processor: the retrieved configuration data for the HSM does not match the policy rules; submitting, by the secure guest via the trusted firmware, a new query to another HSM to obtain other configuration data; 18. The security system according to any one of items 13 to 17, wherein the security system is also capable of executing the following. (Item 19) The processor: Upon changing the allocation configuration of said HSM bound to a secure guest, dissolving the binding of the HSM to the secure guest; and dissolving said association with any secrets in said HSM, if such association exists. 19. The security system according to any one of items 13 to 18, wherein the security system is also capable of executing the following. (Item 20) The processor: and using the trusted firmware to reject all requests from a secure guest to an HSM that are not bound to the secure guest. 20. The security system according to any one of items 13 to 19, wherein the security system is also capable of executing the above. (Item 21) 21. The security system of claim 13, wherein the binding between the secure guest and the HSM is established by the trusted firmware upon a request from the secure guest to the trusted firmware to bind the HSM when the HSM is assigned to the secure guest. (Item 22) 22. The security system of any of items 13 to 21, wherein the secret plaintext value is inaccessible by the secure guest. (Item 23) 23. The security system of any of items 13 to 22, wherein any request to the HSM coupled to the secure guest is only allowed if issued by the secure guest or the trusted firmware on behalf of the secure guest. (Item 24) 24. The security system of any of items 13 to 23, wherein any request from a secure guest to the HSM with a key protected by the HSM is a confidentiality request or the response thereof includes a key protected by the HSM. (Item 25) 1. A computer program product for policy-based association of an HSM with a secure guest in a confidential computing environment, the computer program product comprising: a computer-readable storage medium having program instructions embodied thereon, the program instructions including: maintaining a binding between a secure guest and an HSM using trusted firmware, wherein the binding allows the trusted guest to send only non-confidential requests to the HSM; a procedure for maintaining pairs of secrets and secret names for secure guests using trusted firmware; submitting a query to the coupled HSM or obtaining HSM configuration data by the secure guest via the trusted firmware; upon determining, by the secure guest, that the obtained HSM configuration data matches a policy rule available to the secure guest, wherein the policy rule associates the HSM configuration data with a secret name. requesting, by the secure guest, from 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 authorize the secure guest to submit confidentiality cryptographic requests to the bound and associated HSM. a computer program product executable by the one or more computing systems or controllers to cause the one or more computing systems or controllers to execute

Claims

1. 1. A computer-implemented method for policy-based association of a Hardware Security Module (HSM) with a secure guest in a confidential computing environment, the method comprising: maintaining, by trusted firmware, a binding between a secure guest and an HSM, wherein the binding enables the trusted guest to send only non-confidential requests to the HSM. maintaining a pair of secrets and secret names for the secure guests by the trusted firmware; submitting a query by the secure guest via the trusted firmware to the coupled HSM to obtain HSM configuration data; upon determining, by the secure guest, that the obtained HSM configuration data matches a policy rule available to the secure guest, wherein the policy rule associates the HSM configuration data with a secret name; requesting, by the secure guest, from 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 authorize the secure guest to submit confidential cryptographic requests to the bound and associated HSM. A method comprising:

2. intercepting, by the trusted firmware, each request from the secure guest to the HSM to generate a key protected by the HSM; and enforcing, by the trusted firmware, that the generated HSM protection key be used only with the HSM associated with the secret from the secure guest. The method of claim 1 , further comprising:

3. The method of claim 1 or 2, wherein an HSM master key verification pattern is indicative of the configuration data of the HSM.

4. The method of claim 1 , wherein the pair of the secret and the name of the secret is added to the metadata that the trusted firmware maintains for the secure guest.

5. 5. The method of claim 1, further comprising requesting, by the secure guest, from the trusted firmware, a list of secret names of the pairs of secrets and secret names maintained by the trusted firmware for the secure guest.

6. If the retrieved configuration data of the HSM does not match the policy rules, submitting a new query by the secure guest via the trusted firmware to another HSM to obtain other configuration data; The method according to claim 1 , further comprising:

7. Upon a change in the allocation configuration of the HSM coupled to a secure guest, dissolving the binding of the HSM to the secure guest; and dissolving said association with any secrets of said HSM if such association exists. The method according to claim 1 , further comprising:

8. The method of claim 1 , wherein the trusted firmware rejects all requests from a secure guest to an HSM that are not bound to the secure guest.

9. 9. The method of claim 1, wherein the binding between the secure guest and the HSM is established by the trusted firmware upon a request from the secure guest to the trusted firmware to bind the HSM when the HSM is assigned to the secure guest.

10. The method of claim 1 , wherein the secret plaintext value is inaccessible by the secure guest.

11. 11. The method of claim 1, wherein any request to the HSM coupled to the secure guest is only allowed if issued by the secure guest or the trusted firmware on behalf of the secure guest.

12. 12. The method of claim 1, wherein any request from a secure guest to the HSM that comprises a key protected by the HSM is a confidentiality request or the response comprises a key protected by the HSM.

13. 1. A security system for policy-based association of an HSM with a secure guest in a confidential computing environment, the security system comprising: a processor and a memory operatively coupled to the processor; wherein the memory, when executed by the processor, causes the processor to: maintaining a binding between a secure guest and an HSM using trusted firmware, wherein the binding allows the trusted guest to send only non-confidential requests to the HSM; a procedure for maintaining pairs of secrets and secret names for secure guests using trusted firmware; submitting a query to the coupled HSM or obtaining HSM configuration data by the secure guest via the trusted firmware; upon determining, by the secure guest, that the obtained HSM configuration data matches a policy rule available to the secure guest, wherein the policy rule associates the HSM configuration data with a secret name. requesting, by the secure guest, from 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 authorize the secure guest to submit confidential cryptographic requests to the bound and associated HSM. A security system storing software program code that enables the execution of

14. The processor: using the trusted firmware to intercept each request to the HSM to generate a key protected by the HSM; and and enforcing, by the trusted firmware, that the generated HSM protection key be used only with the HSM associated with the secret from the secure guest.

14. The security system of claim 13, further comprising:

15. 15. The security system of claim 13 or 14, wherein an HSM master key verification pattern is indicative of the configuration data of the HSM.

16. 16. The security system of claim 13, wherein the pair of the secret and the name of the secret is added to the metadata that the trusted firmware maintains for the secure guest.

17. The processor: using the secure guest to request from the trusted firmware a list of secret names of the pairs of secrets and secret names maintained by the trusted firmware for the secure guest.

17. A security system according to claim 13, wherein the system is also capable of carrying out the following:

18. The processor: If the retrieved configuration data of the HSM does not match the policy rules, submitting a new query to another HSM by the secure guest via the trusted firmware to obtain other configuration data; 18. A security system according to claim 13, wherein the security system is also capable of carrying out the following:

19. The processor: Upon a change in the allocation configuration of the HSM coupled to a secure guest, dissolving the binding of the HSM to the secure guest; and dissolving said association with any secrets of said HSM if such association exists.

19. A security system according to any one of claims 13 to 18, which is also capable of carrying out the following:

20. The processor: and using the trusted firmware to reject all requests from a secure guest to an HSM that are not bound to the secure guest.

20. A security system according to claim 13, wherein the system is also capable of:

21. 21. The security system of claim 13, wherein the binding between the secure guest and the HSM is established by the trusted firmware upon a request from the secure guest to the trusted firmware to bind the HSM when the HSM is assigned to the secure guest.

22. 22. The security system of claim 13, wherein the secret plaintext value is inaccessible by the secure guest.

23. 23. The security system of claim 13, wherein any request to the HSM coupled to the secure guest is only allowed if issued by the secure guest or the trusted firmware on behalf of the secure guest.

24. 24. The security system of claim 13, wherein any request from a secure guest to the HSM that includes a key protected by the HSM is a confidentiality request or the response includes a key protected by the HSM.

25. 1. A computer program product for policy-based association of an HSM with a secure guest in a secure computing environment, the computer program product comprising: a computer-readable storage medium having program instructions embodied thereon, the program instructions including: maintaining a binding between a secure guest and an HSM using trusted firmware, wherein the binding allows the trusted guest to send only non-confidential requests to the HSM; a procedure for maintaining pairs of secrets and secret names for secure guests using trusted firmware; submitting a query to the coupled HSM or obtaining HSM configuration data by the secure guest via the trusted firmware; upon determining, by the secure guest, that the obtained HSM configuration data matches a policy rule available to the secure guest, wherein the policy rule associates the HSM configuration data with a secret name. requesting, by the secure guest, from 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 authorize the secure guest to submit confidential cryptographic requests to the bound and associated HSM. a computer program product executable by the one or more computing systems or controllers to cause the one or more computing systems or controllers to perform

Images