Binding a security key of a secure guest to a hardware security module

Abstract

A method, computer program product, and system in which a secure interface control configures a hardware security module for exclusive use by a secure guest. A secure interface control ("SC") obtains a configuration request for configuring a hardware security module (HSM) from a given guest (via a hypervisor) of guests managed by the hypervisor. The SC determines whether the HSM has already been configured to a particular guest of one or more guests, but based on determining that the HSM is not configured to the particular guest and is a secure guest, the SC cancels the establishment of the configuration of the HSM by exclusively limiting access of the guest to the HSM to the given guest. The SC logs in the given guest to the HSM by utilizing a secret of the given guest. The SC obtains a session code from the HSM and maintains the session code.

Description

BACKGROUND

[0001] In today's computer systems and information transmission networks, cryptographic elements are important technical components. Information can be stored or transmitted in an encrypted form in order to avoid unauthorized access to the stored or transmitted information. In some cases, purely software-based techniques can be used and in other cases, hardware support and security-specific elements can be used to perform such data protection. In some cases, these specific elements are named hardware security modules (HSMs), which can be used as part of a computer or information transmission system. Such hardware security modules can include specific circuitry in order to provide functionality for data encryption and data decryption. This functionality can also include the generation and storage of encryption keys for use by a client system.

[0002] HSMs contain master keys that are not accessible to unauthorized parties. These master keys are used to encrypt (i.e., wrap) keys that are available to users of the HSM. Such keys wrapped by the HSM master keys are referred to as secure keys. HSMs are tamper-resistant and protect secrets from unauthorized access (e.g., unplanned physical insertion, physical penetration, etc.). HSMs can be assigned to various virtual resources, such as virtual machines (VMs), and in a virtual environment, the HSM can not be aware of its reassignment from one VM to another.

[0003] The flexibility of VM assignment can create security problems because in highly sensitive hosted information technology (IT) environments, more stringent security protocols would support protecting trusted users who utilize clients with secure keys (wrapped by the HSM's master keys) from being used by untrusted users even if the client itself is illegally compromised or otherwise compromised and the secure keys and other data are stolen. SUMMARY

[0004] The disadvantages of the prior art are overcome and additional advantages are provided through the provision of a method for binding a security key of a secure guest to a hardware security module. The method includes, for example, configuring, by a security interface control communicatively coupled to a hypervisor and the hardware security module, the hardware security module for exclusive use by a secure guest managed by the hypervisor, the configuring including: obtaining, by the security interface control from a given guest of one or more guests managed by the hypervisor via the hypervisor, a configuration request for configuring the hardware security module; determining, by the security interface control, whether the hardware security module has been configured to a particular guest of the one or more guests, wherein the particular guest and the given guest comprise different guests of the one or more guests; based on determining that the hardware security module has not been configured to the particular guest, determining, by the security interface control, that the given guest comprises the secure guest by evaluating metadata of the given guest; based on determining that the given guest comprises the secure guest, de-establishing, by the security interface control, the configuration of the hardware security module by exclusively restricting access of the guests to the hardware security module to the given guest of the one or more guests; logging in, by the security interface control, the given guest to the hardware security module, wherein logging in to the hardware security module comprises utilizing a secret of the given guest, wherein the metadata comprises the secret; based on logging in to the hardware security module, obtaining, by the security interface control, a session code from the hardware security module; and maintaining, by the security interface control, the session code.

[0005] The disadvantages of the prior art are overcome and additional advantages are provided through the provision of a computer program product for binding a security key of a secure guest to a hardware security module. The computer program product includes a storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for performing a method. The method includes, for example, configuring, by one or more processors communicatively coupled to a hypervisor and a hardware security module, the hardware security module for exclusive use by a secure guest managed by the hypervisor, the configuring including: obtaining, by the one or more processors via the hypervisor, a configuration request for configuring the hardware security module from a given guest of one or more guests managed by the hypervisor; determining, by the one or more processors, whether the hardware security module has been configured to a particular guest of the one or more guests, wherein the particular guest and the given guest comprise different guests of the one or more guests; based on determining that the hardware security module has not been configured to the particular guest, determining, by a security interface control, that the given guest comprises the secure guest by evaluating metadata of the given guest; based on determining that the given guest comprises the secure guest, de-establishing, by the one or more processors, the configuration of the hardware security module by exclusively restricting access of the guests to the hardware security module to the given guest of the one or more guests; logging in, by the one or more processors, the given guest to the hardware security module, wherein logging in to the hardware security module includes utilizing a secret of the given guest, wherein the metadata includes the secret; based on logging in to the hardware security module, obtaining, by the one or more processors, a session code from the hardware security module; and maintaining, by the one or more processors, the session code.

[0006] The disadvantages of the prior art are overcome and additional advantages are provided through the provision of a system for binding a security key of a secure guest to a hardware security module. The system includes a memory, one or more processors in communication with the memory, and program instructions executable by the one or more processors via the memory to perform a method. The method includes, for example, configuring, by the one or more processors communicatively coupled to a hypervisor and a hardware security module, the hardware security module for exclusive use by a secure guest managed by the hypervisor, the configuring including: obtaining, by the one or more processors via the hypervisor, a configuration request from a given guest of one or more guests managed by the hypervisor for configuring the hardware security module; determining, by the one or more processors, whether the hardware security module has been configured to a particular guest of the one or more guests, wherein the particular guest and the given guest comprise different guests of the one or more guests; based on determining that the hardware security module has not been configured to the particular guest, determining, by a security interface control, that the given guest comprises the secure guest by evaluating metadata of the given guest; based on determining that the given guest comprises the secure guest, de-establishing, by the one or more processors, the configuration of the hardware security module by exclusively restricting access of the guests to the hardware security module to the given guest of the one or more guests; logging in, by the one or more processors, the given guest to the hardware security module, wherein logging in to the hardware security module includes utilizing a secret of the given guest, wherein the metadata includes the secret; based on logging in to the hardware security module, obtaining, by the one or more processors, a session code from the hardware security module; and maintaining, by the one or more processors, the session code.

[0007] Methods and systems related to one or more aspects are also described and claimed herein. Moreover, services related to one or more aspects are also described and possibly claimed herein. For example, in some embodiments of the invention, maintaining includes storing the association of the session code with the NULL session code in an association table in the security interface control.

[0008] In some embodiments of the invention, the metadata of the guest is integrity protected and the secret is encrypted using a key derived from a private key possessed by the security interface control. The private key can include a cryptographic measure of a boot image of the given guest.

[0009] In some embodiments of the invention, based on the configuration, the processor(s) and / or the security interface control provide a new session code to the given guest for use by the given guest in a request to the hardware security module.

[0010] In some embodiments of the invention, providing (by the processor(s) and / or the secure interface control) includes: the processor(s) and / or the secure interface control intercepting a hardware security module login request from a given client, where the hardware security module login request includes login data from the given client; the processor(s) and / or the secure interface control generating new login data based on a secret of the given client; the processor(s) and / or the secure interface control issuing a new hardware security module login request from the given client to the hardware security module, where the new hardware security module login request includes the new login data; the processor(s) and / or the secure interface control obtaining a session code from the hardware security module; based on obtaining the session code from the hardware security module, the processor(s) and / or the secure interface control generating a new session code; the processor(s) and / or the secure interface control storing an association between the session code from the hardware security module and the new session code in a table; and in response to the login request, the processor(s) and / or the secure interface control sending the new session code to the given client.

[0011] In some embodiments of the invention, the processor(s) and / or the secure interface control intercept a request from a given client to a hardware security module, where the request includes a new session code. The processor(s) and / or the secure interface control obtain from the table a session code from the hardware security module associated with the new session code. The processor(s) and / or the secure interface control update the request from the given client to include a new request, where the new request includes the session code from the hardware security module instead of the new session code. The processor(s) and / or the secure interface control issue the new request to the hardware security module.

[0012] In some embodiments of the invention, the processor(s) and / or the secure interface control obtain fulfillment of the request from the hardware security module. The processor(s) and / or the secure interface control issue the fulfillment of the request to the given client. In some embodiments of the invention, the request is selected from the group consisting of: a hardware security module security key generation request, and a hardware security module logout request.

[0013] In some embodiments of the invention, the processor(s) and / or the security interface control obtain an indication from the hypervisor that a given guest has stopped. The processor(s) and / or the security interface control identify, in a table, an association between a session code from the hardware security module and a new session code. Based on the table, the processor(s) and / or the security interface control generate a list of one or more sessions that utilize the session code from the hardware security module. The processor(s) and / or the security interface control log the given guest out of the one or more sessions.

[0014] In some embodiments of the invention, the processor(s) and / or the security interface control obtain an indication from the hypervisor that a given guest has stopped. The processor(s) and / or the security interface control remove the configuration.

[0015] In some embodiments of the invention, the processor(s) and / or the security interface control obtain an indication from the hypervisor that a given guest has stopped. The processor(s) and / or the security interface control identify a reference to the given guest that is maintained in the hardware security module. The processor(s) and / or the security interface control remove the reference.

[0016] In some embodiments of the invention, the security interface control is selected from the group consisting of: firmware, hardware, and software.

[0017] In some embodiments of the invention, determining that a given guest includes a secure guest by evaluating metadata of the given guest includes: the processor(s) and / or the security interface control verifying one of a presence or a type of the metadata.

[0018] In some embodiments of the invention, the processor(s) and / or the security interface control utilizing a secret of a given guest includes: the processor(s) and / or the security interface control decrypting the secret.

[0019] In some embodiments of the invention, decrypting includes: utilizing a key that is computed exclusively by the security interface control.

[0020] Additional features are realized through the techniques described herein. Other embodiments and aspects are described in detail herein and are considered a part of the claimed aspects. BRIEF DESCRIPTION OF DRAWINGS

[0021] One or more aspects are set forth in the claims at the conclusion of the specification. The foregoing and / or other aspects of the one or more aspects can be further appreciated and realized through a description of the aspects, at least one embodiment of which is presented in the following detailed description of the aspects, taken in conjunction with the accompanying drawings of which:

[0022] Figure 1 illustrates security issues encountered with current methods utilizing hardware security modules;

[0023] Figure 2 Various aspects of some embodiments of the application are illustrated;

[0024] Figure 3 is a workflow illustrating certain aspects of some embodiments of the application;

[0025] Figure 4 is a workflow illustrating certain aspects of some embodiments of the application;

[0026] Figure 5 is a workflow illustrating certain aspects of some embodiments of the application;

[0027] Figure 6 is a workflow illustrating certain aspects of some embodiments of the application;

[0028] Figure 7 is a workflow illustrating certain aspects of some embodiments of the application;

[0029] Figure 8 is a workflow illustrating certain aspects of some embodiments of the application;

[0030] Figure 9 depicts one embodiment of a computing node that can be utilized in a cloud computing environment;

[0031] Figure 10 depicts a cloud computing environment in accordance with an embodiment of the present application; and

[0032] Figure 11 depicts an abstraction model layer in accordance with an embodiment of the present application. DETAILED DESCRIPTION

[0033] The accompanying drawings further illustrate the present application and, together with the detailed description, serve to explain the principles of the present application. In the drawings, like reference characters indicate like or functionally similar elements throughout the several views, and the figures are incorporated into and form a part of the specification. The drawings provide an understanding of certain aspects of some embodiments of the present application. The present application is not limited to the embodiments described in the drawings.

[0034] As will be appreciated by those skilled in the art, program code referred to throughout this application includes both software and hardware. For example, program code in certain embodiments of the present application includes fixed function hardware, while other embodiments utilize software-based implementations of the described functionality. Certain embodiments combine both types of program code. When program / utility 40 having a set (at least one) of program modules 42 is stored in memory 28, it will be appreciated that other implementations can deploy program / utility 40 from other types of computer-readable media. For example, it can be appreciated that program / utility 40 (including program modules 42) can be downloaded over the Internet, for example, for use within other computer-based systems. Figure 9 One example of program code (also referred to as one or more programs) is depicted in FIG. 1.

[0035] The term "hardware security module" or HSM can mean a pluggable component or a separate connected component of a computer system. The HSM can perform encryption operations and decryption operations using a master key or another provided key (e.g., a client key). Encryption and / or decryption can be performed on the hardware security module in hardware and software or any combination of the two. Data can be received by the hardware security module in unencrypted fashion and can be encrypted on the HSM and vice versa.

[0036] The term "client system" can mean an operating system executing, for example, in a virtual machine VM on a hypervisor. A user can be assigned to the client system. A particular encryption key can be assigned to the client system. The mentioned hypervisor can be used to perform such assignment. The particular encryption key can be stored on the HSM.

[0037] The term "content" can mean any character-based string. The string can include readable text or any other binary data.

[0038] The term "data pattern" can essentially be another expression of content. The data pattern can mean a readable string or can include binary data. In the context of this document, no additional requirements are made to the data pattern. It can also be predefined, randomly selected, or otherwise determined.

[0039] The term "master key" can mean an encryption / decryption key stored on the HSM. In the context of this document, it can be assumed in one embodiment that the master key can never be transferred out of the hardware security module on which it is stored.

[0040] The term "client encryption unit" can mean a module adapted to perform encryption and / or decryption operations within or as part of a client system or as a service used by a client system.

[0041] The term "hardware security module encryption unit" can mean a module within the HSM adapted to encrypt any data pattern using the master key or another provided key (e.g., a guest key). Thus, a "hardware security module decryption unit" can be used to decrypt any data pattern using the master key (e.g., a guest key) or another data pattern using another provided key (e.g., a guest key).

[0042] It can be noted that the hardware security module (i.e., HSM) can be, for example, a cryptographic card. The guest system can be, for example, a virtual machine (i.e., VM) running or executing a guest operating system. Configuring the HSM can include storing the master key in a memory of the HSM.

[0043] Embodiments of the present invention include computer-implemented methods, computer program products, and computer systems that include program code that, when executed on at least one processing circuit, is effective to bind a security key of an HSM to a particular guest belonging to a particular owner, such that data protected by the HSM is only usable within a system that has access to the HSM. Specifically, as explained in greater detail below, in embodiments of the present invention, program code executing on one or more processors binds a security key of a security guest (e.g., a VM) that is configured to use an HSM to HSM session code based on a secret that is cryptographically linked to an image of the security guest. However, this secret is not part of the guest. Rather, as described herein, it is transmitted independently of the guest as part of the guest metadata (i.e., encrypted) over a secure channel (i.e., cryptographically) to a security interface control (e.g., firmware, trusted component) and cryptographically linked to the guest. The metadata is cryptographically linked to the guest (e.g., contains a signature of the guest image), and thus, metadata of one guest cannot be misused as metadata of another guest. Thus, the security interface control can verify that the guest and the metadata / secret belong to each other. In some embodiments of the present invention, the secret is linked to a boot image of the security guest that is cryptographically bound to metadata that is securely (protected by integrity and confidentiality) communicated (e.g., and independently, over a secure channel) to the trusted component. In some embodiments of the present invention, the portion of the metadata containing the secret is encrypted by a key that only the security interface control can compute.

[0044] A secure guest can also be referred to as a guest virtual machine, virtual machine, and / or virtual server. In embodiments of the present application, program code provides a secret (securely) to a secure interface control (e.g., firmware, trusted component) as part of installation metadata provided to launch an image of the secure guest. Although linked to the guest, the secret is independently transmitted to the secure interface control as part of the guest metadata and encrypted linked to the guest over a secure channel (i.e., encrypted). Thus, the secure interface control can verify that the guest and metadata / secret belong to each other. Thus, in some embodiments of the present application, the metadata of the secure guest is integrity protected and includes a secret encrypted with a key derived using a private key owned by the secure interface control (e.g., encryption measure of a boot image of a given guest). The metadata need not be accessible by the secure guest itself. As will be explained in greater detail below, in embodiments of the present application, program code of the trusted component: 1) reserves an HSM for the secure guest for the life of the guest; 2) uses the secret to open HSM sessions; 3) intercepts HSM key generation requests and reissues the request replacing the used session code with a session code received as a reply; and 4) closes all sessions opened using the secret when the secure guest is terminated.

[0045] Figure 1 is a portion of a shared computing environment 100 that includes an HSM 110 that illustrates the problem of HSM-related key security with existing approaches that embodiments of the present invention address, thereby demonstrating how embodiments of the present invention provide much more key security in an HSM than existing approaches. As shown in Figure 1, the HSM contains a master key 120 that is not accessible to un-authorized parties. The master key 120 is used by the program code of the HSM to encrypt (i.e., wrap) keys that the program code of the HSM uses to make available to users of the HSM. Keys that are wrapped by the HSM master key 120 are referred to as secure keys. In Figure 1, a guest 150 (Guest 1) has a secure key 130 that was provided to the guest 150 by a hypervisor 140 from the HSM 110. As understood by those skilled in the art, the HSM is tamper-resistant and protects secrets from unauthorized access (e.g., unplanned physical insertion, physical penetration, etc.), however, the guest 150 does not have comparable security and thus can represent a vulnerability. In a virtual environment, because the hypervisor 140 controls the distribution of secure keys 130, the HSM 110 can not be aware of its re-distribution from one guest (i.e., VM) to another guest (i.e., VM). Thus, if a malicious user exploits a second guest 160 (Guest 2) to compromise a given guest 150 (Guest 1), and the secure key 130 assigned to the guest 150 is retained by the second guest 160, there is a security breach. Thus, the second guest 160 can steal (170) the secure key 130 of the guest 150 that was assigned by the hypervisor 140. This is particularly a problem in highly sensitive hosted IT environments where the owner of the guest that is being hosted wants to maintain more aggressive security than the administrator of the host environment. In the shared computing environment 100, various guests can be owned by different entities, and the HSM 110 can belong to only some of these entities. Thus, a guest owner, such as the owner of the guest 150 to which the secure key 130 is assigned, desires to maintain its secure key 130 that is wrapped by the master key 120 of the HSM 110. The guest owner does not want the secure key 130 to be used by a non-trusted guest owned by a different entity that exploits resources in the shared computing environment 100. In Figure 1, the guest and the second guest 160 have different owners, and the owner of the guest 150 wants to ensure that even if the guest 150 is compromised (as shown in Figure 1) and the secure key 130 and other data are stolen (170), it cannot be exploited by any owner other than the owner of the guest 150 to which the secure key 130 was originally assigned.

[0046] Embodiments of the present invention are inextricably linked to computing, at least because they are intended to solve problems that are unique to computing and provide technical approaches that are also in that field. Embodiments of the present invention bind the security keys of an HSM to a particular guest (e.g., VM) that belongs to a particular owner. The problems that aspects of some embodiments of the present invention shown in Figure 1 are intended to solve are specific to computing (i.e., an un-authorized guest gaining access to a security wrapped key of an authorized guest). Given that both the problem and the approach are specific to computing, embodiments of the present invention are inextricably linked to computing.

[0047] Embodiments of the present invention provide significant advantages over existing approaches to the key security problem shown in Figure 1, for example, some existing approaches provide support for key security by providing a context in which a guest is executed without the hypervisor being able to access the memory and / or confidentially installing the secure guest (i.e., using a public key to protect a secret within the installation data of the guest, where only trusted components (hardware (HW) and / or firmware (FW) components) have access to the private key of the guest). In some embodiments of the present invention, the secure interface control (which can also be understood as a trusted component) is hardware, firmware, or a combination thereof. This approach adds an additional layer of complexity and still does not bind the guest owner to a given security key. Other approaches create a separate session to bind a security key to a session code (which depends on the session login data), but this approach eliminates the ability to have a given key used continuously by a guest, thereby compromising the efficiency of the process involving the guest in the case of leveraging the security key. In addition, some approaches attempt to bind an HSM to an operating system (OS) image. These approaches have specific deficiencies that are not found in embodiments of the present invention: 1) the binding is broken when the boot device changes; and / or 2) the HSM adapter can only be inspected after it is plugged in.

[0048] Figure 2Aspects of a computing environment 200 (such as a shared computing environment) in which aspects of certain embodiments of the present application are implemented are shown. Similar to Figure 1, HSM 210 includes master key 220. Also, hypervisor 240 interacts with guests (e.g., VMs) including secure guest 250, which is so understood because its security key 230 (wrapped with master key 220) is bound to HSM 210. In addition to hypervisor 240, in embodiments of the present application, a trusted component (shown as secure interface control 265 in this non-limiting example, but can also be a secure interface control in other embodiments of the present application) supports the configuration of pass-through access to HSM 210. Specifically, in some embodiments of the present application, secure interface control 265 enforces a policy that once pass-through access is configured for secure guest 250, HSM 210 cannot be (temporarily) configured to another guest or component of the system during the lifetime of that secure guest 250. In some embodiments of the present application, secure interface control 265 opens a session to HSM 210 based on a secret 225 that is part of the guest metadata that is cryptographically linked to the guest and can be included in the installation data (e.g., secure execution (SE) header) of the secure guest, and binds all security keys 230 of secure guest 250 to that secret 225. Secret 225 is cryptographically linked to the image of secure guest 250 and is securely provided to secure interface control 265 as part of the installation metadata that is provided to launch the image of secure guest 250. Secret 225 is not part of secure guest 250 and is transferred to secure interface control 265 (over a secure channel, i.e., encrypted) as part of the guest metadata and is cryptographically linked to secure guest 250. Thus, secure interface control 265 can verify that secure guest 250 and the metadata / secret 225 belong to each other. The metadata of secure guest 250 is integrity protected and includes secret 225, which is encryptable by a key derived using a private key owned by secure interface control 265 (e.g., an encryption measure of the boot image of a given guest).

[0049] Figure 3 Workflow 300 illustrating aspects of some embodiments of the present application is shown. For illustrative purposes only, reference is made to Figure 2 Computing environment 200 of Figure 1 illustrates workflow 300. Specifically, Figure 3 Workflow 300 illustrating aspects of binding secure guest 250 (a guest with at least one security key 230 that has been wrapped by HSM master key 220) to HSM 210 is shown. As described above, in a trusted component (shown as secure interface control 265 in this non-limiting example, but can also be a secure interface control in other embodiments of the present application) in which aspects of certain embodiments of the present application are implemented, the secure interface control 265 opens a session to HSM 210 based on a secret 225 that is part of the guest metadata that is cryptographically linked to the guest and can be included in the installation data (e.g., secure execution (SE) header) of the secure guest, and binds all security keys 230 of secure guest 250 to that secret 225. Secret 225 is cryptographically linked to the image of secure guest 250 and is securely provided to secure interface control 265 as part of the installation metadata that is provided to launch the image of secure guest 250. Secret 225 is not part of secure guest 250 and is transferred to secure interface control 265 (over a secure channel, i.e., encrypted) as part of the guest metadata and is cryptographically linked to secure guest 250. Thus, secure interface control 265 can verify that secure guest 250 and the metadata / secret 225 belong to each other. The metadata of secure guest 250 is integrity protected and includes secret 225, which is encryptable by a key derived using a private key owned by secure interface control 265 (e.g., an encryption measure of the boot image of a given guest). Figure 2Many of the bindings are accomplished with the help of the secure interface control 265. The program code of the secure interface control 265 in embodiments of the present invention supports the configuration of pass-through access to the HSM 210. To support this aspect, the program code executing on one or more processors configures the secure interface control 265 (i.e., the program code of the secure interface control 265) to provide certain functionality.

[0050] Figure 3 Workflow 300 illustrates the functionality provided by a configured secure interface control 265. In particular, workflow 300 illustrates certain aspects of some embodiments of the present invention in which, based on the inclusion of an HSM secret in the metadata of a secure guest, a trusted component (e.g., the secure interface control 265, the secure interface control as hardware, firmware, or a combination thereof) creates a session for the secure guest based on the HSM secret. Thus, all created (i.e., initiated via login) sessions, key generation requests, and session termination requests (i.e., initiated via logout) from the secure guest are intercepted by the secure interface control. After intercepting these requests, the program code of the secure interface control reissues the requests that originally included standard login data and session code provided by the HSM with requests that include the login data (which includes the HSM secret) and session code generated by the secure interface control. Thus, the program code replaces the standard login data in the requests with login data that includes the HSM secret, and the program code replaces the session code provided by the HSM with session code generated by the secure interface control.

[0051] Reference is made to Figure 3 For purposes of illustration, certain aspects of the workflow are presented in any order. Although described in a sequence for ease of understanding, the program code of the secure interface control opens a default session to the HSM for all aspects between the secure key (310) that has not yet been bound to any session with the HSM for a secure guest and the program code determines that the secure guest has been terminated (370) is an event loop, where the remaining aspects (the program code intercepts each HSM login session (320) of the secure guest, the program code associates the session (initiated by login) with an HSM session that utilizes login data based on the secret of the secure guest (330), the program code intercepts each HSM key generation and session logout request (340) of the secure guest, the program code replaces the session code for these actions with associated session code based on the secret of the secure guest (350), and based on determining that a given event has occurred, the program code closes all sessions based on the secret of the secure guest (360)) can occur in any order, including but not limited to the order of the workflow 300, and can also occur asynchronously at any time during the workflow 300.

[0052] ReturnFigure 3 Referring to Figure 2 In some embodiments of the application, the program code of the secure interface control 265 opens a default session to the HSM 210 for the secure key of the secure client 250 that is not yet bound to any session with the HSM 210 (310). The program code intercepts each HSM 210 login session of the secure client 250 (320). The program code associates the session (initiated by the login) with the HSM 210 session that utilizes the login data based on the secure client's secret (330). In embodiments of the application, the secret 225 is not part of the client 250, as it is transmitted separately as part of the client metadata to the secure interface control 265 (over a secure channel, i.e., encrypted), and is cryptographically linked to the client 225. Thus, the secure interface control 265 can verify that the client 250 and the metadata / secret 225 belong to each other. The program code of the HSM 265 can maintain in table 245 its association of the session code based on the secure client's secret 225 with the session code returned to the secure client 250. The HSM can provide and track in table 215 the session codes returned to the secure client 250. As shown, the program code of the secure interface control 265 also stores the HSM configuration of the secure client 250, along with storing the table associating the session code based on the secure client's secret with the session code returned to the secure client 245. Figure 2

[0053] Returning to Figure 3 The program code intercepts each HSM key generation and session logout request of the secure client 250 (340). The secure client 250 stores the secure key 230 that is wrapped by the HSM 210 with the master key 220. The program code replaces the session code for these actions with the associated session code based on the secure client's secret 225 (e.g., from table 245) (350). The program code determines that the secure client has been terminated (360). Based on determining that a given event has occurred, the program code closes all sessions based on the secure client's secret 225 (370). The given event can vary. In some embodiments of the application, the program code closes all sessions based on the secure client's secret 225 based on determining that the secure client 250 has been terminated. The program code of the HSM 210 and other elements of the system can also take additional actions to protect the security of the system when unexpected events occur. For example, in some embodiments of the application, if the HSM 210 is unplugged, the program code deletes all session state data. In some embodiments of the application, if the secure interface control 265 terminates unexpectedly, the program code executing on the processing device clears all sessions of the HSM 210.

[0054] ​In embodiments of the present invention, program code executed on processing resources (including trusted components (e.g., Figure 2 The program code of the security interface control 265) is used to enable secure clients (e.g., Figure 2 The security key of the secure client 250 (e.g., Figure 2 The security key 130) is bound to the HSM (e.g., Figure 2 The HSM (210) performs at least five general functions: 1) The program code of the security interface control initially configures the relationship / connection between the HSM and the security client; 2) The program code of the security interface control intercepts requests from the security client and eventually returns a new session code to the security client; 3) The program code of the security interface control intercepts requests from the security client for a new security key generated by the HSM (wrapped in the master key); 4) The program code of the security interface control intercepts requests from the security client to log out of the session with the HSM; and 5) Based on stopping the security client, the program code of the security interface control begins and completes various cleanup activities. Figures 4-8 The workflows for these aspects are shown in 400-800.

[0055] refer to Figure 4 Workflow 400 illustrates how, in an embodiment of the invention, the program code of the security interface control initially configures the relationship / connection between the HSM and the security client. For example... Figure 2 As shown, the security interface control is communicatively coupled to the HSM and the clients managed by the hypervisor via a hypervisor. In one embodiment of the invention, the program code of the security interface control (e.g., trusted firewall, trusted component, etc.) receives a configuration request (410) from a client (e.g., a virtual machine) among one or more clients managed by the hypervisor via the hypervisor (e.g., a virtual machine manager). The program code determines whether the HSM has been configured to a given client among one or more clients (420). Based on the determination that the HSM has been configured to a given client, the program code returns an error in response to the configuration request (435). In an embodiment of the invention, the program code of the security component (e.g., secure firewall, security interface control) implements the following: for an HSM configured to a client, the hypervisor managing the client cannot intercept any requests from the secure client of the HSM.

[0056] return Figure 4Based on determining that the HSM is not configured to the given client, the program code determines whether the client is a secure client (e.g., based on authentication including various aspects of the client's metadata) (440). In embodiments of the application, the presence or type of the client's metadata determines whether the client is secure. The metadata is cryptographically linked to the client (e.g., contains the signature of the client image), and thus, the metadata of one client cannot be misused as the metadata of another client. If the client is not secure, the process terminates (435). Based on determining that the client is a secure client, the program code prevents the HSM from being accessed by other clients (450). In some embodiments of the application, if a secure client is launched but has not been terminated, no HSM configured for the secure client (in particular, no HSM on which a session is created using the HSM secrets of the secure client) can be configured to another client (or component running in the system).

[0057] Referring to Figure 4 , the program code logs in (e.g., accesses) the HSM using the secrets of the secure client (460). Prior to the HSM being accessed by the secure client for the first time, the program code of the secure interface control uses the HSM secrets from the metadata of the secure client to log into the HSM. In response to logging into the HSM, the program code receives a session code from the HSM (470). The program code stores the association of the session code with a NULL session code in an association table in the secure component (480). Thus, the secure interface control stores the association of the NULL session code with the session code returned by the HSM in the table. In some embodiments of the application, the table associates the session code based on the secrets of the secure client with the session code returned by the HSM to the secure client.

[0058] Referring to Figure 5 , the workflow 500 illustrates that the program code of the secure interface control intercepts requests from the secure client in embodiments of the application. As shown in Figure 5 , the program code of the secure component (e.g., secure FW) intercepts each session login request from the secure client and reissues the login request with the login data of the secure client replaced with a combination of the login data and the HSM secrets (e.g., by performing a bitwise XOR of the two pieces of data). Thus, instead of returning the session code returned by the HSM, the program code of the secure interface control generates a new session code consistent with the specifications of the login request (e.g., from the login data of the secure client) and stores the association of the generated session code with the session code returned by the HSM in a table (e.g., table 265 of Figure 2 ).

[0059] Returning to Figure 5In some embodiments of the application, the program code of the secure interface control (e.g., trusted FW, trusted component) intercepts a HSM login request from the secure guest, where the HSM login request utilizes login data from the secure guest (510). The program code generates new login data based on a secret of the secure guest, where the secret of the secure guest is cryptographically linked to the image of the secure guest (520). The program code issues a HSM login request (having intercepted the original request) with the new login data (i.e., data based on the secret of the secure guest) (530). The program code receives a session code from the HSM (540). Based on receiving the session code from the HSM, the program code generates a new session code (the session code changes based on the login data) (550). The program code associates the session code from the HSM with the new session code and stores the association in an association table (560). The program code returns the new session code to the secure guest (570).

[0060] In addition to intercepting HSM login requests from the secure guest as shown in Figure 5 , in embodiments of the application, the program code of the trusted component (e.g., secure interface control 265 of Figure 2 ) also intercepts requests from the secure guest to the HSM, including but not limited to key generation requests and session logout requests. Figures 6-7 Aspects of the secure component handling key generation and logout requests are shown separately. As shown in Figures 6-7 , the program code of the secure component intercepts and reissues these requests, where the session code provided by the secure guest is replaced with the session code provided by the HSM (as stored in the association table).

[0061] Figure 6 Workflow 600 is shown illustrating the workings of the program code of the secure interface control handling a HSM key generation request utilizing a new session code (e.g., 560 of Figure 5 . In some embodiments of the application, the program code of the secure interface control (e.g., trusted FW, trusted component) intercepts a HSM key generation request from the secure guest utilizing a new session code (610). The program code looks up the new session code in the association table and locates the associated session code (the session code from the HSM, e.g., 540 of Figure 5 ). Based on locating the session code, the program code issues a HSM key generation request to the HSM utilizing the session code (630). In response to the request, the program code obtains the requested key and returns the key to the secure guest (640). Thus, the program code returns the results of the HSM request to the secure guest.

[0062] Similar to workflow 600 of Figure 6 ,Figure 7 Workflow 700 is depicted, which illustrates program code of a secure interface control handling a HSM logout request with a new session code (e.g., 560) of the secure client. In some embodiments of the application, program code of a secure interface control (e.g., trusted FW, trusted component) intercepts a HSM logout request with a new session code from a secure client (710). The program code looks up the new session code in an association table and locates the associated session code (session code from HSM, e.g., 540) (720). Based on locating the session code, the program code issues a HSM logout request to the HSM with the session code (730). The program code removes the association from the association table (the association of the new session code with the session code) (735). In response to the request, the logout of the secure client from the HSM is completed (740). Figure 5 Figure 5

[0063] Figure 8 Workflow 800 is depicted, which illustrates program code of a secure interface control terminating a secure client in some embodiments of the application. Generally, in embodiments of the application, if a secure client terminates, the secure interface control terminates all sessions that it created (using HSM secrets of the secure client). In some embodiments of the application, program code of a secure interface control obtains information via a hypervisor indicating that a secure client has been stopped (810). Based on determining that the secure client has been stopped, program code of the secure component identifies all sessions of the secure client with a HSM based on an association table (820). In some embodiments of the application, the program code can generate a list of all sessions associated with a session code. Based on identifying the sessions via the session code, the program code logs out the secure client from all identified sessions (830). The program code removes HSM configuration of the secure client (840). The program code cleans up remaining resources of the secure client (850).

[0064] Embodiments of the application include various security measures to protect the integrity of the HSM and secure client. For example, in some embodiments of the application, if a secure interface control crashes, all sessions in the HSM are terminated. Additionally, if a HSM is removed from a server, all sessions in the HSM are terminated.

[0065] ​​Embodiments of the invention include computer-implemented methods, computer program products, and systems for binding a security key of a secure guest to a hardware security module. Various aspects of these embodiments are performed by a security interface control, which can include software, hardware, and / or firmware. Software aspects are executed by one or more processors. Thus, for ease of understanding, aspects of various embodiments of the invention are described as being performed broadly by program code, which can include the security interface control, regardless of the composition of the aspect. Thus, in some embodiments of the invention, program code configures a hardware security module for exclusive use by a secure guest managed by a hypervisor. This configuration includes: program code obtaining, via the hypervisor, a configuration request from a given guest of one or more guests managed by the hypervisor for configuring the hardware security module; program code determining whether the hardware security module has already been configured to a particular guest of the one or more guests, where the particular guest and the given guest comprise different guests of the one or more guests; based on the program code determining that the hardware security module has not been configured to the particular guest, the program code determining that the given guest comprises the secure guest by evaluating metadata of the given guest; based on determining that the given guest comprises the secure guest, the program code undoing the configuration of the hardware security module by exclusively restricting access of the guests to the hardware security module to the given guest of the one or more guests. The program code logs in the given guest to the hardware security module, where logging in to the hardware security module includes utilizing a secret of the given guest, where the metadata includes the secret. Based on the program code logging in to the hardware security module, the program code obtains a session code from the hardware security module; and the one or more processors maintain the session code.

[0066] In some embodiments of the invention, maintaining includes: program code storing an association of the session code with a NULL session code in an association table in the security interface control.

[0067] In some embodiments of the invention, the metadata of the guest is integrity protected and the secret is encrypted by a key derived using a private key owned by the security interface control. The private key can include an encryption measure of a boot image of the given guest.

[0068] In some embodiments of the invention, based on the configuration, the program code provides a new session code to the given guest for use by the given guest in a request to the hardware security module.

[0069] In some embodiments of the invention, the program code providing comprises: the program code intercepting a hardware security module login request from a given guest, wherein the hardware security module login request includes login data from the given guest; the program code generating new login data based on a secret of the given guest; the program code issuing a new hardware security module login request from the given guest to the hardware security module, wherein the new hardware security module login request includes the new login data; the program code obtaining a session code from the hardware security module; the program code generating a new session code based on obtaining the session code from the hardware security module; the program code storing in a table an association between the session code from the hardware security module and the new session code; and the program code sending the new session code to the given guest in response to the login request.

[0070] In some embodiments of the invention, the program code intercepting a request from a given guest to a hardware security module, wherein the request includes a new session code. The program code obtaining from a table a session code from the hardware security module associated with the new session code. The program code updating the request from the given guest to include a new request, wherein the new request includes the session code from the hardware security module instead of the new session code. The program code issuing the new request to the hardware security module.

[0071] In some embodiments of the invention, the program code obtaining fulfillment of the request from the hardware security module. The program code issuing the fulfillment of the request to the given guest. In some embodiments of the invention, the request is selected from the group consisting of: a hardware security module security key generation request, and a hardware security module logout request.

[0072] In some embodiments of the invention, the program code obtaining from the hypervisor an indication that the given guest has stopped. The program code identifying in a table an association between a session code from the hardware security module and a new session code. The program code generating, based on the table, a list of one or more sessions that utilize the session code from the hardware security module. The program code logging out the given guest from the one or more sessions.

[0073] In some embodiments of the invention, the program code obtaining from the hypervisor an indication that the given guest has stopped. The program code removing the configuration.

[0074] In some embodiments of the invention, the program code obtaining from the hypervisor an indication that the given guest has stopped. The program code identifying references to the given guest that are maintained in the hardware security module. The program code removing the references.

[0075] In some embodiments of the invention, the secure interface control is selected from the group consisting of: firmware, hardware, and software.

[0076] In some embodiments of the application, determining that a given client includes a secure client by evaluating metadata of the given client includes one of: presence or type of program code verification metadata.

[0077] In some embodiments of the application, the program code utilizes a secret of the given client includes the program code decrypting the secret.

[0078] In some embodiments of the application, decrypting includes utilizing a key computed exclusively by the secure interface control.

[0079] Additional features are realized through the techniques described herein. Other embodiments and aspects are described in detail herein, and are considered a part of the claimed aspects.

[0080] Reference is now made to the following drawings, in which Figure 9 a schematic diagram of an example of a computing node, which can be a cloud computing node 10. Cloud computing node 10 is only one example of a suitable cloud computing node and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the application described herein. Regardless, cloud computing node 10 is capable of being implemented and / or performing any of the functionality set forth hereinabove in connection with the above described embodiments of the application. In embodiments of the application, a secure client 250( Figure 2 ), a secure interface control 265 (e.g., secure interface control) Figure 2 ), and / or a hypervisor 240( Figure 2 ) can each be understood to be executing on cloud computing node 10( Figure 9 ) and, if not cloud computing node 10, one or more general purpose computing nodes that include aspects of cloud computing node 10.

[0081] Within cloud computing node 10 there is a computer system / server 12, which is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well- known computing systems, environments, and / or configurations that can be suitable for use with computer system / server 12 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices, and the like.

[0082] The computer system / server 12 can be described in the general context of computer system-executable instructions, such as program modules, being executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, and so on that perform particular tasks or implement particular abstract data types. Computer system / server 12 can be practiced in distributed cloud computing environments with remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules can be located in both local and remote computer system storage media including memory storage devices.

[0083] As shown in Figure 9 FIG. 1, computer system / server 12 is shown in the form of a general-purpose computing device. The components of computer system / server 12 can include, but are not limited to, one or more processors or processing units 16, a system memory 28, and a bus 18 that couples various system components including system memory 28 to processor 16.

[0084] Bus 18 represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limiting, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus.

[0085] Computer system / server 12 typically includes a variety of computer system readable media. Such media can be any available media that is accessible by computer system / server 12, and it includes both volatile and non-volatile media, removable and non-removable media.

[0086] The system memory 28 can include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Computer system / server 12 can further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 can be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown and typically called a "hard drive"). Although not specifically shown, a magnetic disk drive can also be used for reading from and writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive can be used for reading from or writing to a removable, non-volatile optical disk (such as a CD-ROM, DVD-ROM or other optical media). In this regard, the storage media, of which the storage system 34 can include in the illustrated example, can be connected to the system bus 18 by one or more data media interfaces. As will be further depicted and described below, the memory 28 can include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the application.

[0087] By way of example, and not limitation, as embodied in the embodiments of the present application, the programs / utility 40, having a set (at least one) of program modules 42, can be stored in memory 28 by way of example, and not limitation, as embodied in the embodiments of the present application, the programs / utility 40, having a set (at least one) of program modules 42, can be stored in memory 28

[0088] Computer system / server 12 can also communicate with one or more external devices 14 such as a keyboard, a pointing device, a display 24; one or more devices that enable a user to interact with computer system / server 12; and / or any devices (e.g., network card, modem, etc.) that enable computer system / server 12 to communicate with one or more other computing devices. Such communication can occur via Input / Output (I / O) interfaces 22. Still yet, computer system / server 12 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via network adapter 20. As depicted, network adapter 20 communicates with the other components of computer system / server 12 via bus 18. It will be appreciated that other hardware and / or software components could be used in conjunction with computer system / server 12. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0089] It should be appreciated that while the present disclosure includes a detailed description on cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment. Rather, embodiments of the present application are capable of being implemented in conjunction with any other type of computing environment now known or later developed.

[0090] Cloud computing is a model of service delivery for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g. networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model can be composed of at least five characteristics, at least three service models, and at least four deployment models.

[0091] Features are as follows:

[0092] On-demand self-service: cloud consumers can unilaterally provision computing capabilities (e.g., server time and network storage), automatically and without human interaction with the service's provider.

[0093] Broad network access: capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0094] Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is no requirement that the same physical and virtual resources be allocated to each consumer, but rather, consumers typically have no control or knowledge of the exact location of the provided resources but rather are able to specify location at a higher level of abstraction (e.g., country, state, or datacenter), and there is a location independence.

[0095] Rapid elasticity: capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out and rapidly released to quickly scale in. To the consumer, the provider's ability to provision capabilities on-demand and in near real-time, allows for only a minimum amount of lead time between the request for the provisioning of the capabilities and the provision of the capabilities.

[0096] Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.

[0097] Service models are as follows:

[0098] Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based e-mail). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0099] Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

[0100] Infrastructure as a Service (IaaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

[0101] Deployment models are as follows:

[0102] Private cloud: the cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0103] Community cloud: the cloud infrastructure is shared by several organizations and supports mission-oriented business

[0104] Public cloud: the cloud infrastructure is made available to general public or a large industry group and is owned by an organization selling cloud services.

[0105] Hybrid cloud: the cloud infrastructure is a composition of two or more types of cloud (private, community, or public) that remain unique entities but are bound together by standardized technologies that enable data and application portability.

[0106] Cloud computing environments are service-oriented, with characteristics centered on statelessness, loose coupling, modularity, and semantic interoperability. At the core of the computing is an infrastructure that includes a network of interconnected nodes.

[0107] Referring now to the drawingsFigure 10 The diagram illustrates an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 to which local computing devices used by cloud consumers can communicate. These local computing devices are, for example, personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks (such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above). This allows the cloud computing environment 50 to provide Infrastructure as a Service, Platform as a Service, and / or Software as a Service, without requiring cloud consumers to maintain resources on their local computing devices. It should be understood that... Figure 10 The various computing devices 54A-N shown are merely illustrative. The computing node 10 and the cloud computing environment 50 can communicate with any type of computing device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0108] Now for reference Figure 11 This demonstrates a cloud computing environment of 50 ( Figure 10 This provides a set of functional abstraction layers. First, it should be understood that... Figure 11 The components, layers, and functions shown are merely illustrative, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0109] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a mainframe 61; a RISC (Reduced Instruction Set Computer) based server 62; a server 63; a blade server 64; a storage device 65; and a network and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0110] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0111] In one example, management layer 80 can provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing 82 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 85 provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.

[0112] Workloads layer 90 provides examples of functionality for which the cloud computing environment can be utilized. Examples of workloads and functions which can be provided include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and binding of security keys to secure clients 96. It is understood that these are simply example workloads, and that the layers can include different services in other embodiments.

[0113] The present application can be a system, a method, and / or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0114] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

[0115] Computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer readable program instructions from the network and forwards the computer readable program instructions to storage media within the respective computing / processing device for execution by a processor.

[0116] Computer readable program instructions for carrying out operations of the present application can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and a procedural programming language such as the "C" programming language or similar programming languages. The computer readable program instructions can be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or connected to an external computer (e.g., using the Internet through an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry in order to perform aspects of the present application.

[0117] Aspects of the present application are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems) and computer program products according to embodiments of the application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0118] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored

[0119] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0120] The flow diagrams and block diagrams in the drawings are illustrative of possible architectures, functions, and operations for systems, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical functions (‘instructions’). In some alternative implementations, the functions noted in the blocks can occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently or the blocks can sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and / or flow diagrams, and combinations thereof, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

[0121] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. 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 be further understood that the terms "comprises" and / or "comprising," when used in this specification, specify the presence of 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.

[0122] The description of various embodiments has been presented for purposes of illustration but is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method comprising: configuring, by a security interface control communicatively coupled to a hypervisor and a hardware security module, the hardware security module for exclusive use by a secure guest managed by the hypervisor, the configuring comprising: obtaining, by the security interface control from a given guest of one or more guests managed by the hypervisor via the hypervisor, a configuration request for configuring the hardware security module; determining, by the security interface control, whether the hardware security module has been configured to a particular guest of the one or more guests, wherein the particular guest and the given guest comprise different guests of the one or more guests; based on determining that the hardware security module has not been configured to the particular guest, determining, by the security interface control, that the given guest comprises the secure guest by evaluating metadata of the given guest; based on determining that the given guest comprises a secure guest, revoking, by the security interface control, establishment of the configuration of the hardware security module by exclusively restricting access to the hardware security module to the given guest of the one or more guests; logging in, by the security interface control, the given guest to the hardware security module, wherein the logging in to the hardware security module comprises utilizing a secret of the given guest, wherein the metadata comprises the secret; based on the logging in to the hardware security module, obtaining, by the security interface control, a session code from the hardware security module; and maintaining, by the security interface control, the session code.

2. The computer-implemented method of claim 1, wherein, the maintaining comprises storing an association of the session code with a NULL session code in an association table in the security interface control.

3. The computer-implemented method of claim 1, wherein, the metadata of the guest is integrity protected and the secret is encrypted using a key derived from a private key owned by the security interface control.

4. The computer-implemented method of claim 3, wherein, the private key comprises an encryption measure of a boot image of the given guest.

5. The computer-implemented method of claim 2, further comprising: based on the configuring, providing, by the security interface control, a new session code to the given guest for use by the given guest in a request to the hardware security module.

6. The computer-implemented method of claim 5, wherein, the providing comprises: intercepting, by the security interface control, a hardware security module login request from the given guest, wherein the hardware security module login request comprises login data from the given guest; generating, by the security interface control, new login data based on the secret of the given guest; issuing, by the security interface control, a new hardware security module login request from the given guest to the hardware security module, wherein the new hardware security module login request comprises the new login data; obtaining, by the security interface control, a session code from the hardware security module; based on obtaining the session code from the hardware security module, generating, by the security interface control, the new session code; storing, by the secure interface control, an association between the session code from the hardware security module and the new session code in the table; and sending, by the secure interface control, the new session code to the given guest in response to the login request.

7. The computer-implemented method of claim 5, further comprising: intercepting, by the secure interface control, a request from the given guest to the hardware security module, wherein the request includes the new session code; obtaining, by the secure interface control, the session code from the hardware security module associated with the new session code from the table; updating, by the secure interface control, the request from the given guest to include a new request, wherein the new request includes the session code from the hardware security module instead of the new session code; and issuing, by the secure interface control, the new request to the hardware security module.

8. The computer-implemented method of claim 7, further comprising: obtaining, by the secure interface control, a fulfillment of the request from the hardware security module; and issuing, by the secure interface control, the fulfillment of the request to the given guest. the request is selected from a group consisting of: a hardware security module secure key generation request, and a hardware security module logout request.

9. The computer-implemented method of claim 8, wherein, 10. The computer-implemented method of claim 6, further comprising: obtaining, by the secure interface control, an indication from the hypervisor that the given guest has stopped; identifying, by the secure interface control, an association between the session code from the hardware security module and the new session code in the table; generating, by the secure interface control, a list of one or more sessions that utilize the session code from the hardware security module based on the table; and logging out, by the secure interface control, the given guest from the one or more sessions.

11. The computer-implemented method of claim 1, further comprising: obtaining, by the secure interface control, an indication from the hypervisor that the given guest has stopped; removing, by the secure interface control, the configuration.

12. The computer-implemented method of claim 6, further comprising: obtaining, by the secure interface control, an indication from the hypervisor that the given guest has stopped; identifying, by the secure interface control, a reference to the given guest maintained in the hardware security module; and removing, by the secure interface control, the reference. the secure interface control is selected from a group consisting of: firmware, hardware, and software. determining that the given guest includes the secure guest by evaluating metadata of the given guest includes one of: verifying a presence or a type of the metadata. utilizing the secret of the given guest includes: decrypting, by the secure interface control, the secret.

13. The computer-implemented method of any one of claims 1 to 12, wherein, the decrypting includes: utilizing a key computed exclusively by the secure interface control.

14. The computer-implemented method of any one of claims 1 to 12, wherein, 17. A computer program product, comprising:

15. The computer-implemented method of any one of claims 1 to 12, wherein, ​ 16. The computer-implemented method of claim 15, wherein, ​ ​ A computer-readable storage medium that is readable by one or more processors and stores instructions for execution by the one or more processors to perform a method comprising: configuring, by the one or more processors that are communicatively coupled to a hypervisor and a hardware security module, the hardware security module for exclusive use by a secure guest managed by the hypervisor, the configuring comprising: obtaining, by the one or more processors via the hypervisor, a configuration request for configuring the hardware security module from a given guest of one or more guests managed by the hypervisor; determining, by the one or more processors, whether the hardware security module has already been configured to a particular guest of the one or more guests, wherein the particular guest and the given guest comprise different guests of the one or more guests; based on determining that the hardware security module has not been configured to the particular guest, determining, by the one or more processors, that the given guest comprises the secure guest by evaluating metadata of the given guest; based on determining that the given guest comprises a secure guest, de-establishing, by the one or more processors, configuration of the hardware security module by exclusively restricting access to the hardware security module to the given guest of the one or more guests; logging, by the one or more processors, the given guest into the hardware security module, wherein the logging into the hardware security module comprises utilizing a secret of the given guest, wherein the metadata comprises the secret; based on logging into the hardware security module, obtaining, by the one or more processors, a session code from the hardware security module; and maintaining, by the one or more processors, the session code.

18. The computer program product of claim 17, wherein, The maintaining comprises storing an association of the session code with a NULL session code in a table accessible to the one or more processors.

19. The computer program product of claim 17 or 18, wherein, The metadata of the guest is integrity protected and the secret is encrypted using a key derived from a private key possessed by the one or more processors.

20. A computer system comprising: a memory; one or more processors in communication with the memory; program instructions executable by the one or more processors via the memory to perform a method comprising: configuring, by the one or more processors that are communicatively coupled to a hypervisor and a hardware security module, the hardware security module for exclusive use by a secure guest managed by the hypervisor, the configuring comprising: obtaining, by the one or more processors via the hypervisor, a configuration request for configuring the hardware security module from a given guest of one or more guests managed by the hypervisor; determining, by the one or more processors, whether the hardware security module has already been configured to a particular guest of the one or more guests, wherein the particular guest and the given guest comprise different guests of the one or more guests; based on determining that the hardware security module has not been configured to the particular guest, determining, by the one or more processors, that the given guest comprises the secure guest by evaluating metadata of the given guest; based on determining that the given guest comprises a secure guest, de-establishing, by the one or more processors, configuration of the hardware security module by exclusively restricting access to the hardware security module to the given guest of the one or more guests; logging, by the one or more processors, the given guest into the hardware security module, wherein the logging into the hardware security module comprises utilizing a secret of the given guest, wherein the metadata comprises the secret; based on logging into the hardware security module, obtaining, by the one or more processors, a session code from the hardware security module; and maintaining, by the one or more processors, the session code. The maintaining comprises storing an association of the session code with a NULL session code in a table accessible to the one or more processors. The metadata of the guest is integrity protected and the secret is encrypted using a key derived from a private key possessed by the one or more processors. based on determining that the hardware security module is not configured to the particular guest, determining, by the one or more processors, that the given guest comprises the secure guest by evaluating metadata of the given guest; based on determining that the given guest comprises a secure guest, cancelling, by the one or more processors, establishing a configuration of the hardware security module by exclusively restricting access of guests to the hardware security module to the given guest of the one or more guests; logging in, by the one or more processors, the given guest to the hardware security module, wherein the logging in to the hardware security module comprises utilizing a secret of the given guest, wherein the metadata comprises the secret; based on logging in to the hardware security module, obtaining, by the one or more processors, a session code from the hardware security module; and maintaining, by the one or more processors, the session code.

Images