Hypervisor protection key

Abstract

The method, computer system, and computer program product may provide a cryptographic key object to a guest virtual server for use in cryptographic operations. The guest virtual server may register with a hypervisor. The hypervisor may generate a guest wrapping key associated with the guest certificate from the registration. The hypervisor may also generate a satellite virtual server instance. The guest virtual server and the satellite virtual server instance share a master key that is not accessible by the hypervisor or any of the guest virtual servers. The trusted hypervisor may pass a copy of the guest wrapping key to the satellite virtual server instance. A random guest key may be generated and wrapped with the guest wrapping key, thereby producing a wrapped guest key. The hypervisor may convert the wrapped guest key to become a protected key that serves as a cryptographic key object.

Description

Technical Field

[0001] The present invention generally relates to providing a cryptographic key object to a guest virtual server for use in encryption and cryptographic operations.

Background Art

[0002] The world is moving in the direction of a digital society. An increasing number of processes, products, and services are being provided in digital form. Parallel to this, privacy requirements are increasing, and companies and government organizations are striving to protect their digital assets. Cryptography is a core technology for digital privacy and is based on secret keys that must never be passed to unauthorized systems or people. In addition, the number and sophistication of cyberattacks are increasing. Thus, the need to protect confidential data is increasing significantly over time.

[0003] Assuming that there are no flaws in the cryptographic algorithm, the security of the cipher depends on keeping the key secret. The key can very often be in the memory of the user system used in the encryption function. Thus, such a key is used in the form of "clear key crypto". Access to the key enables access to the encrypted data, so exposure of the key will break the secrecy.

[0004] Therefore, there are other ways to perform encryption using keys that are not available in the memory system of the user of the relevant encryption function. For example, the user system may call into a Hardware Security Module (HSM). The user system has, in that case, a token, a wrapped key, or another way to convey to the hardware security module which key is being used. As long as no one has access rights to the hardware security module, the token or the wrapped key provides no access rights to the encrypted data, so using an HSM can provide additional security. A known drawback of such HSM solutions is that bandwidth is often limited and the latency of operations increases.

[0005] A third variation, presented as the concept of a "protected key", has been added to mainframe computers such as the IBM Z(R) system. This variation uses a wrapped key, which is formed by the wrapping key encrypting another key. The wrapping key is known by (trusted) firmware. This wrapping is initiated by a hardware security module, such as a crypto express adapter. The user system of the wrapped key may only have access rights to the wrapped key, but the CPU can perform cryptographic operations using the unwrapped key. Such an approach combines the speed of clear key cryptography with the security level of a protected key.

[0006] The protected key may be encrypted with a Virtual Server (VS) - specific Master Key (VS - MK) that is unique to the running instance of the virtual server and not accessible to the virtual server. The virtual server master key VS - MK may be hidden in the firmware.

[0007] The virtual server master key (VS-MK) is derived from the host master key (host-MK) and a virtual server specific pattern provided by the host when the virtual server is configured. Inside each virtual server, the firmware may provide an interface that converts the plaintext key to a protected key wrapped by a master key specific to the virtual server being called. Implementations of this approach currently exist on mainframe systems such as IBM Z(R).

[0008] There is a problem with this approach when the virtual server master key is specific to the running instance of the virtual server and the protected key is only valid for that specific running instance of the virtual server. There is a problem with this approach if the protected key is no longer valid when the virtual server is rebooted, interrupted to disk, and resumed or migrated to another system.

[0009] Thus, the fundamental problem with the methods and systems proposed here can be seen in a way that the key can be used as a protected key in multiple (boot) instances of the virtual server such that the virtual server does not need to store data that can be used to disclose the key in text form. This can be achieved under boundary conditions where there is no access to the host and the hosted data can be stored securely.

[0010] In this context, several documents have been published. The document, U.S. Patent Application Publication No. 2017 / 0277898 (A1), discloses a processor that employs a security module to manage authentication and encryption keys for the processor. The security module can authenticate itself to other processing systems, thereby generating a key to encrypt the address space for the software provided by the processing system that provides the software to be executed in the processor, securely import information into the processing system in the encrypted address space, and export it from the processing system.

[0011] Furthermore, document U.S. Patent No. 8,996,887 (B2) discloses a method of providing data. The method includes receiving a first request from a first virtual machine (VM) that stores data, obtaining the data and an access control list (ACL) of authorized users, obtaining a data key having a data key identifier, encrypting the data key and the ACL using a wrapping key to generate a wrapped blob, encrypting the data, storing the wrapped blob and the encrypted data, and providing the data key identifier to a user on the ACL.

[0012] However, these techniques also do not solve the above-described problems regarding the use of a protection key when a hardware security module is not available or practical. SUMMARY OF THE INVENTION

[0013] Embodiments of the present invention can include a computer-implemented method, a computer system, and a computer program product for providing a cryptographic key object to a guest virtual server for use in cryptographic operations. The guest virtual server may register with a trusted hypervisor. Registering may include using a guest credential. The trusted hypervisor may generate a guest wrapping key and associate the guest wrapping key with the guest credential. When receiving a request from the guest virtual server along with the guest credential as an argument, the trusted hypervisor may generate a satellite virtual server instance for the guest virtual server. The satellite virtual server instance may be composed of virtual server specific data from the guest virtual server. The satellite virtual server instance may share a master key with the virtual guest server. The master key is not accessible by the trusted hypervisor or the guest virtual server.

[0014] The trusted hypervisor may transfer a copy of the guest wrapping key to the satellite virtual server instance. The trusted hypervisor may generate a random guest key. The trusted hypervisor may wrap the random guest key with the guest wrapping key, thereby creating a wrapped guest key. When receiving a conversion request from the guest virtual server, a conversion of the wrapped guest key to a protected key may be performed to change the wrapped guest key. The conversion may include re-wrapping the wrapped guest key with the master key to form a protected guest key. The protected guest key serves as a cryptographic key object.

[0015] A computer-implemented method, computer system, and computer program product for providing a cryptographic key object to a guest virtual server for use in cryptographic operations can present a plurality of advantages, technical effects, contributions, or improvements, or combinations thereof.

[0016] The disclosed invention, in order to be able to avoid the overhead and / or cost, or both, required by an HSM, the option of using the concept of a protection key without the requirement for a hardware security module (HSM) is a significant advantage over existing solutions. The invention can provide security for encryption keys at the same or at least equivalent level as those solutions that require a hardware security module. The solution of the invention may be entirely software-based and may not require any additional necessary hardware. Thus, the solution of the invention can enable a lower price point for the same or equivalent level of encryption solution that has heretofore been provided only by hardware-based security module-based solutions.

[0017] One useful advantage of the present invention is that the protection key "survives longer" than an instance of a virtual system running on the hypervisor. Additionally, satellite virtual servers that may be implemented can be ignored in terms of performance degradation considering the vast number of virtual machines typically running on the hypervisor. Further, the functionality of the satellite virtual server can be limited to one or just a few functions or services. For example, the satellite virtual server can perform a single transaction, i.e., the conversion of a wrapped guest key to a protection key. The hypervisor should be a trusted hypervisor. In a typical computing environment where a protection key may be required, such as a mainframe computing environment, a series of firmware components, typically implemented in hardware, may support or be integrated with the functionality of the hypervisor, so the hypervisor can be seen as trusted-by-design.

[0018] Since no additional hardware need be installed, the invention proposed herein can be implemented even during the runtime of a mainframe computing system. Thus, the absence of operating system downtime and the reduction of production time from such downtime are further advantageous results of the proposed inventive solution.

[0019] In the following, additional embodiments of the present invention will be described.

[0020] According to one advanced embodiment of the present invention, the conversion further includes the satellite virtual server instance unwrapping a guest key wrapped with a guest wrapping key. Thus, the supply of the protection key by the satellite virtual server can occur without a hardware security module.

[0021] According to another embodiment of the present invention, the conversion request includes a guest certificate as an argument, for example, a conversion argument. Therefore, the supply of the protection key by the satellite virtual server can occur completely even without a hardware security module.

[0022] According to another embodiment of the present invention, a trustworthy hypervisor may maintain a repository of guest wrapping keys associated with data for which it is necessary to verify a guest certificate. Therefore, the guest wrapping keys of different guest virtual machines may be maintained permanently, that is, they may be spared from the shutdown of the associated guest virtual machine, and the certificates from different guest virtual servers may remain verifiable.

[0023] According to a further embodiment of the present invention, a trustworthy hypervisor may use a cryptographic one-way function for calculating data for which it is necessary to verify a guest certificate. Such a cryptographic one-way function may be a cryptographic hash function. This embodiment improves the security of the hypervisor because thereby there is no need to store the guest's certificate.

[0024] According to one advantageous embodiment of the present invention, the key repository may be protected by a passphrase. Therefore, in this embodiment, unregulated access to the key store is not permitted. The key repository can be protected against unauthorized access.

[0025] According to one enhanced embodiment of the present invention, the guest wrapping keys in the repository may be protected by a hardware security module. This embodiment may represent an advanced option for enhanced protection of guest wrapping keys when a hardware security module is available to the hypervisor but not available to all guests hosted by the hypervisor.

[0026] According to an advantageous embodiment of the present invention, the virtual server specific data may be data stored in a crypto control block (CRYCB) of a virtual machine. This data feature can be applied to both guest virtual servers and satellite virtual servers. Therefore, in this embodiment, a trustworthy hypervisor can configure two guests that share or do not share configuration data depending on security requirements. In other words, two standard guests do not share security-related data, while a guest and its satellite guest do share it.

[0027] According to another advantageous embodiment of the present invention, the satellite virtual server may have a single interface, and the single interface can be connected to a trustworthy hypervisor. Therefore, in this embodiment, other interfaces or APIs of the satellite virtual server may not be available or usable, and the satellite virtual server can be prevented from being misused in a way that undermines the security invention proposed here.

[0028] Alternatively, or in addition, according to a further embodiment of the present invention, a trustworthy hypervisor may also use services from the satellite virtual server, such as additional services, to generate a random key and wrap the random key with a guest wrapping key. Thus, in the case of this embodiment, all high-confidential core functions for the security invention proposed here can be handled between the trustworthy hypervisor and the satellite virtual server.

[0029] According to one acceptable embodiment, the present invention may also include authorizing each request after registration by a trustworthy hypervisor. Authorizing may include using an additional guest certificate provided with each request following registration. These features enable a guest to register multiple wrapping keys associated with multiple certificates such that key generation and wrapping key conversion operations can operate on multiple independent key spaces.

[0030] According to another advanced embodiment of the method, the hypervisor may authorize further requests for guest virtual server requests after registration. Authorization may additionally be based on guest-specific data. Guest-specific data for this embodiment may be, for example, boot volume data or guest owner data that may be recorded during the registration request. Thus, together with these features, the possibility of compromising the proposed security invention may be further reduced.

[0031] It should be noted that, unless otherwise notified, any combination of features belonging to the methods, systems, or computer program products described in this specification is considered to be disclosed within this document by those skilled in the art from the above description and the following description.

[0032] The aspects defined above and further aspects of the present invention are apparent from and will be elucidated with reference to the examples of embodiments described hereinafter. The present invention is not limited thereto, however.

[0033] Preferred embodiments of the present invention are described, by way of example only, with reference to the following drawings.

Brief Description of the Drawings

[0034]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

DETAILED DESCRIPTION OF THE INVENTION

[0035] In the context of this description, the following terms or expressions or both may be used.

[0036] The term "cryptographic key object" may mean a data sequence used in cryptographic operations by a guest virtual server. The guest virtual server may use the cryptographic key object as a protection key.

[0037] The term "guest virtual server" can mean a virtual machine that emulates a complete computer system and runs within or on a hypervisor. The hypervisor can represent a layer between the physical hardware system and multiple virtual machines that can be isolated from each other. When virtual machines are isolated from each other, a fatal error within or on one of the virtual machines does not affect another one of the virtual machines.

[0038] The term "cryptographic operation" can mean the encryption or decryption of data to protect it from unauthorized access. Additionally, "cryptographic operation" can also be related to signing or verifying operations to prove the integrity of data.

[0039] The term "trusted hypervisor" can mean a hypervisor that can be built into a physical hardware system and can communicate with firmware in a way that is not exposed to risks by unauthorized persons. To achieve this security for the hypervisor, organizational provisions can be made. For example, access to a terminal for installing or managing a trusted hypervisor can be restricted. Alternatively, a software-only hypervisor can be used as a trusted hypervisor as long as organizational measurements are taken to protect the hypervisor from unauthorized access to security keys and other confidential data managed by the hypervisor.

[0040] Furthermore, a trusted hypervisor, i.e., the "hypervisor" for short, can provide hypercalls to a guest virtual server to (a) generate a random key token that is a random key wrapped by a guest wrapping key, and (b) convert the key token into a protection key. Both of these calls can take a guest secret as an argument that enables the trusted hypervisor to associate the correct satellite virtual server.

[0041] The above hypercall (a) can be executed by the hypervisor, but the guest wrapping key is exposed during its operation. The hypercall (a) may preferably be executed by the service of a satellite virtual server that can convert the guest wrapping key into a protection key when initialized with the guest wrapping key, and thus can protect the guest wrapping key while wrapping a random key using the guest wrapping key.

[0042] The hypercall (b) can be executed by the service of a satellite virtual server associated with the calling guest virtual server. The satellite virtual server may at that time use a copy of the guest wrapping key (which may be a protection key) to unwrap the key token, and may immediately convert the unwrapped key into a protection key that the satellite virtual server returns to the hypervisor.

[0043] The term "guest certificate" can mean any code - data unique to the guest virtual server. The guest certificate may be input or provided by the user, or may be stored in persistent storage accessible by the guest virtual server, for example, key storage in the form of a USB stick.

[0044] The term "satellite virtual server instance" can mean a hidden virtual machine running on a trusted hypervisor in parallel with the guest virtual machine. A 1:1 correlation may exist between the guest virtual server and the satellite virtual server. The satellite virtual server can be generated in response to a request from the guest virtual server only for the purpose of providing a protection key to the guest virtual server. The satellite virtual server may have limited functionality and may not be able to initiate requests, and thus does not have its own guest secrets. The satellite virtual server may be associated with guest secrets, for example, guest secrets from its corresponding guest virtual machine.

[0045] The term "virtual server" may be used as a synonym for the term "virtual machine" that is executed as software on a hypervisor. This term may apply to both guest virtual servers and satellite virtual servers.

[0046] The term "master key" may mean, for example, a secret code that is specific to a hardware host machine and is incorporated into the firmware of the hardware machine. Alternatively, this term may mean a virtual server master key (VS-MK), i.e., a master key associated with a specific guest virtual system. Two guest virtual systems will not have the same VS-MK unless one is a satellite virtual server of the other.

[0047] The term "random guest key" may mean a code generated by the hypervisor that is wrapped with a guest wrapping key associated with a guest certificate.

[0048] The term "guest wrapping key" may mean a key, e.g., a sequence of digital data, that is used by the hypervisor to wrap a random guest key, i.e., to protect the random guest key from unauthorized access.

[0049] The term "satellite virtual server" may mean a virtual machine that provides services to the hypervisor, for example, (a) converts a key wrapped with a guest wrapping key of an associated guest virtual server so that the key becomes a protection key for the associated guest virtual server, and optionally (b) generates a random key wrapped with a guest wrapping key of the associated guest virtual server.

[0050] The term "Cryptographic Control Block" (CRYCB) may refer to a data structure specific to a virtual machine, e.g., specific to a guest virtual server or a satellite virtual server. The CRYCB can be generated under the control of a hypervisor during the instantiation of a virtual machine on the hypervisor. In the invention proposed herein, the CRYCBs for a guest virtual server and related satellite virtual servers may be the same or may include some identical data.

[0051] The following provides a detailed description of the drawings. All indications in the drawings are schematic. First, a block diagram of an embodiment of a computer-implemented method of the invention for providing a cryptographic key object to a guest virtual server for use in cryptographic operations is provided. Thereafter, embodiments of a protection key providing system for providing a cryptographic key object to a guest virtual server for use in cryptographic operations, as well as further embodiments, are described.

[0052] FIG. 1 shows a block diagram of a preferred embodiment of a computer-implemented method 100 for providing a cryptographic key object, particularly a protection key, to a guest virtual server for use in cryptographic operations. Method 100 may include a step 102 in which a guest virtual server registers with a trustworthy hypervisor using a guest certificate. The guest certificate may be a guest virtual server-specific secret that may be input by a user, input by a file, or from another source. In another step 104, the trustworthy hypervisor generates a guest wrapping key for the registered guest virtual server. The trustworthy hypervisor may associate the guest wrapping key with the guest certificate used for the registration of the guest virtual server with the trustworthy hypervisor.

[0053] In another step 106, when the trusted hypervisor receives a request, such as an initialization request, from the guest virtual server together with a guest certificate as an argument, the trusted hypervisor generates a satellite virtual server instance for the guest virtual server. The request and the generation may be regarded as one integrated activity. The satellite virtual server is composed of virtual server specific data from the guest virtual server, particularly the same data within the CRYCB. The satellite virtual server and the guest virtual server may share a master key, for example, they may share the VS-MK. Thus, the data within the CRYCB (cryptographic control block) of the guest virtual server and the satellite virtual server is in principle the same. A further constraint is that the master key cannot be accessed by the trusted hypervisor or any guest virtual server. This protection can be achieved by hiding the master key in the firmware. As a result, the guest virtual server cannot directly access its own master key.

[0054] Additionally, method 100 may include a step 108 in which the trusted hypervisor passes a copy of the guest wrapping key to the satellite server instance. This passing can be performed in any initialization step or as part of a transformation request. The guest wrapping key is the guest wrapping key associated with the request, i.e., the request for initialization or alternatively the request for wrapped key generation.

[0055] Method 100 may also include a step 110 in which the guest virtual server requests a random guest key to be wrapped by the guest wrapping key. Further, method 100 may include a step 112 in which the trusted hypervisor generates a random guest key. Method 100 may include a step 114 in which the trusted hypervisor wraps the random guest key with the guest wrapping key associated with the guest certificate.

[0056] Method 100 may also include step 116 of converting the wrapped guest key into a protection key. The conversion may occur upon receiving a conversion request from the guest virtual server, or may occur before the wrapped guest key transmitted from the hypervisor is used by the guest virtual server. This conversion or transformation may include the satellite virtual server re-wrapping the wrapped guest key with its master key that is unique to both the guest virtual server and the satellite virtual server. Thus, the wrapped guest key may be converted into a protected guest key that serves as an encryption key object.

[0057] FIG. 2 shows an exemplary flowchart 200 for generating a guest wrapping key. This may occur upon the initial load of the guest virtual server. In step 202, the guest virtual server may request from the hypervisor to generate a guest wrapping key and to associate the guest wrapping key with a guest certificate, such as a guest secret. In step 204, based on the request, the hypervisor may generate a new random key and associate the new random key with the cryptographic hash of the guest secret. Further in step 206, the hypervisor may store this association of the hash and the random key in a repository.

[0058] FIG. 3 shows a block diagram 300 of components that serve as means for generating a guest wrapping key. The hypervisor 302 may cooperate with the firmware 304 to thereby form a trusted hypervisor. In the case of a software-only hypervisor, the operating restrictions of the environment are where they protect the operation of the hypervisor, thereby constituting it as a trusted hypervisor. Incorporated in the firmware 304 is a host master key (host MK) 306. The host MK 306 may be used with a cryptographic control block (CRYCB) 308 and a guest master key pattern from the guest virtual server cryptographic control block 314 to generate a guest master key 310.

[0059] In the initialization or first use of the guest virtual server (GVS) 312, the guest virtual server 312 can access a guest certificate, which can be a guest secret 316. The guest secret 316 can be, for example, user input or from another source. The guest secret 316 can be a password or something like a password. The guest secret 316 can be transformed into a one-way form as a hash value 322. Additionally, the hypervisor 302 can generate a guest wrapping key 320. The hypervisor 302 can associate the guest wrapping key 320 with the hash value 322, as indicated by the double arrow between the hash value 322 of the guest secret 316 and the guest wrapping key 320. Both the hash value 322 of the guest secret 316 and the guest wrapping key 320 are persistently stored in the repository 318. This storage enables the guest wrapping key 320 to continue to exist even if the guest virtual server 312 is rebooted, interrupted on disk, resumed, migrated to another part of the system using another hypervisor, or a combination of these occurs.

[0060] Figure 4 shows an exemplary flowchart 400 for at least one embodiment of steps for starting a satellite virtual server. In step 402, the guest virtual server 312 sends a request to the hypervisor 302 to start or initialize the satellite virtual server and associates the satellite virtual server with the guest virtual server secret. The guest virtual server specific secret may be input by a user, input by a file, or come from another secret source. Since the guest virtual server 312 is the same as that used in the previous step, the secret is the same as the guest secret 316 used to generate the guest wrapping key 320. After this request, in step 404, the hypervisor 302 starts a satellite virtual server instance using the same wrapping key configuration used by the calling client, i.e., the same wrapping key configuration used by the guest virtual server 312. In other words, the hypervisor 302 uses the cryptographic control block CRYCB314 that has already been used to instantiate the guest virtual server 312.

[0061] In step 406, the hypervisor 302 determines the hash value 322 of the guest secret 316 and stores the guest wrapping key 320 associated with the hash value 322 in the satellite virtual server. Since the guest secret is the same, the hash determined in step 406 is the same as that used in step 200. The hash is a deterministic function. In step 408, the hypervisor 302 associates the satellite virtual server with the hash value 322.

[0062] The guest virtual server secret means referring to a specific wrapping key in a database, e.g., a repository 318. Whenever a subsequent request with the guest virtual server secret as an argument is issued to the hypervisor 302, the hypervisor 302 must remember that the newly created satellite server will be used during the lifetime of the guest (i.e., as long as the guest is running).

[0063] Since the lifetime of a running guest cannot exceed the lifetime of its host (i.e., the lifetime of the hypervisor 302), the association (e.g., the pair composed of a hash and a reference to a satellite virtual server) need not be stored in an external database, but should be stored somewhere within the memory of the hypervisor. For example, for each guest that issues an initialization request, the hypervisor 302 maintains a pair of a secret hash (used during initialization) and a reference to a satellite virtual server. For example, in LinuxKVM (Kernel-based Virtual Machine), this reference may be the process ID of the QEMU (open-source machine emulator and virtualizer) process that runs the satellite virtual server.

[0064] FIG. 5 shows a block diagram 500 of components related to the process of starting a satellite virtual server. Components already described above will not be described again, and reference numbers of previous figures for the same object are reused.

[0065] The satellite guest virtual server 502 (shown adjacent to the guest virtual server 312) is started by the hypervisor 302 using the same master key configuration or the wrapping key configuration used by the guest virtual server 312, for example, by using the cryptographic control block 314 used to instantiate the guest virtual server 312. A copy of the guest wrapping key 320 is stored in the system of the satellite guest virtual server 502 (indicated by the arrow between the two instances of 320). As a result of the process shown as a flowchart in FIG. 4, the hash value 322 of the guest secret 316 also exists in the satellite guest virtual server 502 (indicated by the arrow from the repository 318 to the satellite guest virtual server 502).

[0066] The single task of the satellite guest virtual server 502 can be to provide a function for converting a key wrapped by a guest wrapping key into a protection key. Therefore, any other function may not be available within the satellite guest virtual server 502, and thus, the satellite guest virtual server 502 will not be exploited for any cyberattack.

[0067] FIG. 6 shows an exemplary flowchart 600 illustrating a method for generating a random wrapped key. At step 602, the guest virtual server 312 may send a request to the hypervisor 302 and may provide a guest secret to the hypervisor 302. The request is for the hypervisor 302 to return a random key wrapped by a guest wrapping key 320 associated with the guest secret. Since the virtual guest server 312 is the same as that used in the previous steps 200 and 400, the guest secret here is the same as the previously used guest secret 316 so that the system can identify the correctly stored information in the repository 318. The guest may, for example, register two different secrets with the hypervisor 302, in which case there may be two different wrapping keys and two different satellite servers. Depending on the secret used in the request, either one of the wrapping keys and the satellite server will be used by the hypervisor 302 when fulfilling the request. Returning to step 604, the hypervisor 302 determines the hash of the guest secret and generates a random key wrapped by that guest wrapping key. Therefore, no direct communication occurs between the guest virtual server and the satellite virtual server. At step 606, the hypervisor returns the random key wrapped by the guest wrapping key to the guest virtual server.

[0068] FIG. 7 shows a block diagram 700 of components involved in the generation of a random key, as depicted by the activity flowchart of FIG. 6. FIG. 7 shows that the hypervisor 302 has generated a random key 702.

[0069] Figure 8 shows a similar block diagram 800 of the components shown in Figure 7, but shows further actions to complete the wrapped random key. Figure 8 shows that the random key 702 (Figure 7) is here wrapped using the guest wrapping key 320 from the satellite guest virtual server instance 502, thereby forming the wrapped guest key 802. The wrapped guest key 802, which is wrapped by the guest wrapping key 320, is made available to the guest virtual server (GVS) 312.

[0070] When the wrapped guest key 802 moves to or is received by the guest virtual server 312, the first version of the random key 702 (Figure 7) and the first version of the wrapped guest key 802, i.e., the wrapped guest key 802 shown on the left in Figure 8, may no longer exist and may, for example, be deleted.

[0071] Figure 9 shows an exemplary flowchart 900 for the conversion of the wrapped guest key 802 into a protection key. In step 902, the guest virtual server 312 sends a request to the hypervisor 302 to return a key wrapped by the guest virtual server master key 310 (VS-MK) starting from the wrapped guest key 802 wrapped by the guest wrapping key 320 associated with the guest secret provided in the request. In another step 904, the hypervisor 302 determines the hash value of the guest secret of this request and requests the associated satellite virtual server to convert the wrapped guest key 802, which is wrapped by the guest wrapping key 320, into the key wrapped by its guest master key 310.

[0072] In step 906, the satellite guest virtual server 502 unwraps the guest key 802 wrapped using the guest wrapping key 320. In step 908, the satellite guest virtual server 502 requests from the firmware 304 (via the hypervisor 302) to wrap the unwrapped key with its master key 310 and returns the result to the hypervisor 302. In another step 910, the hypervisor 302 returns the received key wrapped by the guest master key 310 to the guest virtual server 312. Along with this, the loop closes and the guest virtual server 312 has received the protection key, i.e., the cryptographic key object, to be used for further cryptographic functions by the guest virtual server 312 without the need to use the hardware security module.

[0073] FIG. 10 shows a block diagram 1000 of all components supporting the generation of the protection key as described in the context of the steps shown in FIG. 9. The random key 702, which becomes the guest key 802 wrapped by the guest wrapping key 320, is unwrapped in the satellite guest virtual server 502 and sent to the firmware 304 via the hypervisor 302. Here, the unwrapped guest key 1002 is wrapped with the master key 310 and returned as the protection key 1004 to the guest virtual server 312 via the hypervisor 302.

[0074] Here, a copy of the wrapped guest key 802 can be seen in the guest virtual server 312 and the satellite guest virtual server 502. However, after the wrapped guest key 802 is unwrapped into the unwrapped guest key 1002, the wrapped guest key 802 may be "forgotten", i.e., deleted in the satellite guest virtual server 502. Thus, the unwrapped guest key 1002 may exist only during the transition. Also, after the request to the firmware 304 is fulfilled, the unwrapped guest key 1002 may be deleted in the satellite guest virtual server 502. The unwrapped guest key 1002 is no longer needed. The same thing happens to the version of the protection key 1004 in the firmware after the protection key 1004 is transferred to the guest virtual server 312.

[0075] FIG. 11 shows a block diagram of an embodiment of an invention protection key providing system 1100 that provides a cryptographic key object to a guest virtual server 312 for use in cryptographic operations. The system 1100 may include a registration unit 1102 that enables the guest virtual server 312 to register with a trusted hypervisor 302 using a guest certificate. The system 1100 may also include a first generator module 1104 that enables the trusted hypervisor 302 to generate a guest wrapping key 320 and associate the guest wrapping key 320 with the guest certificate.

[0076] System 1100 may also include a second generator module 1106 that becomes active when it receives a request from guest virtual server 312 along with a guest certificate as an argument. In that case, the second generator module 1106, triggered or activated by trusted hypervisor 302, is adapted to generate, for guest virtual server 312, a satellite-guest virtual server instance 502 composed of virtual server specific data from guest virtual server 312. Guest virtual server 312 shares its master key 310 with satellite-guest virtual server instance 502. In any case, the master key 310 cannot be accessed by trusted hypervisor 302 or any guest virtual server.

[0077] Guest virtual server 312 may share master key 310 without having access rights to the master key. The encryption request is sent to the system along with a protection key (a key wrapped by the master key). The system knows from which virtual server the encryption request is coming and uses the master key for that virtual server to unwrap the protection key. Then, the encryption operation is performed based on the plaintext key within the CPU. Thus, the encryption operation can be performed without the virtual server ever knowing the actual encryption key.

[0078] Furthermore, system 1100 may include a delivery module 1108 that enables trusted hypervisor 302 to deliver a copy of guest wrapping key 320 associated with the requested guest certificate to satellite-guest virtual server instance 502. System 1100 may also include a third generator module 1110 that enables trusted hypervisor 302 to generate a random key 702.

[0079] Additionally, system 1100 may include a wrapping module 1112 that enables trusted hypervisor 302 to wrap random key 702 with guest wrapping key 320 associated with the guest certificate, thereby creating a wrapped guest key 802.

[0080] Also, the system 1100 may include a request unit 1114 that requests conversion of the wrapped guest key 802 to a protection key before using the wrapped guest key 802. The conversion may include the satellite guest virtual server instance 502 re-wrapping the wrapped guest key 802 with the master key 310. The master key 310 may be unique to both the guest virtual server 312 and the satellite guest virtual server 502, or may be shared by the guest virtual server 312 and the satellite guest virtual server 502. In the re-wrapping, the wrapped guest key 802 may be converted to a protected guest key 1004 and function as a cryptographic key object.

[0081] Note that the units and modules mentioned can be interconnected directly or indirectly for the exchange of information and / or signals or both. Alternatively, the registration unit 1102, the first generator module 1104, the second generator module 1106, the handover module 1108, the third generator module 1110, the wrapping module 1112, and the request unit 1114 can be interconnected via the internal bus system 1116 of the protection key providing system 1100. These units and modules can be formed via software.

[0082] Embodiments of the present invention can be implemented with virtually any type of computer, regardless of the platform suitable for storing or executing or both the program code. FIG. 12 shows, as an example, a computer system 1200 suitable for executing program code related to the proposed method.

[0083] Whether the computer system 1200 is implemented, or any of the functionality described above is performed, or both, the computer system 1200 is merely an example of a suitable computer system and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the invention described herein. The computing system 1200 includes components that are operable with a number of other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, or configurations, or combinations thereof, that may be suitable for use with the computer system / server 1200 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 including any of the above systems or devices. The computer system / server 1200 may be described in the general context of computer system executable instructions, such as program modules, being executed by the computer system 1200. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system / server 1200 may be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

[0084] As shown in the figure, computer system / server 1200 is shown in the form of a general-purpose computing device. The components of computer system / server 1200 may include, but are not limited to, one or more processors or processing units 1202, system memory 1204, and a bus 1206 that couples various system components including system memory 1204 to processor 1202. Bus 1206 represents any one or more of a plurality of types of bus structures including a memory bus or memory controller, a peripheral bus, a high-speed graphics port, and a processor or local bus that uses any of a variety of bus architectures. By way of example and not limitation, such architectures may 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 Interconnects (PCI) bus. Computer system / server 1200 typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system / server 1200, and it includes both volatile and nonvolatile media, removable and non-removable media.

[0085] System memory 1204 may include a computer system readable medium in the form of volatile memory such as, for example, random access memory (RAM) 1208 or cache memory 1210 or both. The computer system / server 1200 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 1212 may be provided for reading from and writing to a non-removable non-volatile magnetic medium (not shown and typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk, such as, for example, a “floppy (R) disk,” and an optical disk drive for reading from or writing to a removable non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media may be provided. In such instances, each may be connected to bus 1206 by one or more data media interfaces. Further shown and described hereinafter, memory 1204 may include at least one program product having a set (at least one) of program modules configured to carry out the functions of embodiments of the present invention.

[0086] A program / utility having a set (at least one) of program modules 1216 may, for example, be stored in memory 1204. An operating system, one or more application programs, other program modules, and program data may also be stored in memory 1204. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Program modules 1216 generally carry out the functions or methodologies of embodiments of the invention, as described herein.

[0087] The computer system / server 1200 can also communicate with one or more external devices 1218 such as a keyboard, a pointing device, a display 1220, one or more devices that enable a user to interact with the computer system / server 1200, or any device that enables the computer system / server 1200 to communicate with one or more other computing devices (e.g., a network card, a modem, etc.), or a combination thereof. Such communication can occur via the input / output (I / O) interface 1214. Further, the computer system / server 1200 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), or a public network (e.g., the Internet), or a combination thereof, via the network adapter 1222. As shown, the network adapter 1222 can communicate with other components of the computer system / server 1200 via the bus 1206. Although not shown, it should be understood that other hardware components or software components, or both, can be used in conjunction with the computer system / server 1200. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0088] Additionally, the protection key providing system 1100 for providing a cryptographic key object to a guest virtual server for use in cryptographic operations can be attached to the bus system 1206.

[0089] The descriptions of various embodiments of the present invention are presented for illustrative purposes and are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected in order to best explain the principles of the embodiments, the practical application, or the technical improvement found in the marketplace, or to enable other skilled artisans to understand the embodiments disclosed herein.

[0090] The present invention may be embodied as a system, method, or computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium (or media) having thereon computer-readable program instructions for causing a processor to execute aspects of the present invention.

[0091] The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system for a propagation medium. Examples of computer-readable media may include semiconductor or solid-state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read-only memory (ROM), hard magnetic disks, and optical disks. Current examples of optical disks may include compact disk read-only memory (CD-ROM), compact disk read / write (CD-R / W), DVD, and Blu-Ray disks.

[0092] A computer-readable storage medium can be a tangible device that holds and stores instructions for use by an instruction execution device. The computer-readable storage medium can be, for example, 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, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy (R) disk, punch card, or mechanically encoded devices such as raised structures in grooves in which instructions are recorded thereon, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through an electrical wire.

[0093] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or to an external computer or external storage device via a network, such as, for example, the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network can include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium within each respective computing / processing device.

[0094] The computer-readable program instructions for carrying out the operations of the present invention may be source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or object-oriented programming languages such as Smalltalk(R), C++, and conventional procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may 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 the connection may be made to an external computer (e.g., through the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by individuating the electronic circuit using the state information of the computer-readable program instructions to carry out aspects of the present invention.

[0095] Aspects of the invention 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 invention. It should 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.

[0096] Instructions executed by a processor of a computer or other programmable data processing apparatus may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus for manufacturing a machine, so as to generate means for implementing the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both. These computer-readable program instructions may also be stored in a computer-readable storage medium that includes a product containing instructions for implementing the mode of the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both, so as to instruct a computer, a programmable data processing apparatus, or other device, or a combination thereof, to function in a specific manner.

[0097] Instructions executed on a computer, other programmable apparatus, or another device may also be loaded onto a computer, other programmable data processing apparatus, or another device for executing a series of operation steps on the computer, other programmable apparatus, or another device to create a computer-implemented process, so as to implement the functions / operations specified in one or more blocks of a flowchart, a block diagram, or both.

[0098] The flowcharts, block diagrams, or both in the drawings illustrate the architecture, functionality, and operation of possible embodiments of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of a module that includes one or more executable instructions for performing the specified logical function. In some alternative embodiments, the functions described within the blocks may occur out of the order described in the drawings. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagram or flowchart or both, and combinations of blocks in the block diagram or flowchart or both, can be implemented by a dedicated hardware-based system that performs the specified function or operation, or a combination of dedicated hardware and computer instructions.

[0099] In the case of embodiments that take the form of a related computer program product, the program code may be accessible from a computer-usable medium or a computer-readable medium, and may be suitable for use by, or in connection with, a computer or any instruction execution system. For the purposes of this description, a computer-usable medium or a computer-readable medium may be any device that can store, communicate, propagate, or transport a program for use by, or in connection with, an instruction execution system, apparatus, or device.

[0100] This disclosure includes a detailed description of cloud computing, but it should be understood that the embodiments of the teachings recited herein are not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0101] Cloud computing is a service delivery model 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 service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0102] The characteristics are as follows. On-demand self-service: A cloud consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed, automatically, without the need for human interaction with the service provider. Broad network access: The 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). Resource pooling: Provider 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 demand. There is a sense of location independence in that consumers generally have no control or knowledge of the exact location of the provided resources, but may be able to specify location at a higher level of abstraction (e.g., country, state, or data center). Speedy scalability: Capabilities can be supplied speedily and elastically to scale out immediately, and in some cases automatically, and released speedily to scale in immediately. To consumers, the capabilities available for supply often appear to be unlimited and can be purchased in any quantity at any time. Measurability of services: The cloud system automatically controls and optimizes resource usage by leveraging measurement capabilities at an appropriate abstract level suitable for the type of service (e.g., storage, processing, bandwidth, active user accounts). The amount of resource usage can be monitored, controlled, and reported, providing transparency to both the provider and the consumer of the services used.

[0103] The service model is as follows. Software as a Service (SaaS): The capabilities provided to consumers are to use the provider's applications running on the cloud infrastructure. The applications are accessible from various client devices through a thin-client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, although there may be exceptions for limited user-specific application configurations. Platform as a Service (PaaS): The capabilities provided to consumers are to deploy consumer-created or consumer-acquired applications created using programming languages and tools supported by the provider onto the cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but do control the deployed applications and, to the extent possible, the application hosting environment configuration. Infrastructure as a Service (IaaS): The capabilities provided to the consumer are to supply other basic computing resources that enable the consumer to deploy and run processing, storage, networks, and any software that the consumer may 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 limited control over select networking components (e.g., host firewalls) as much as possible.

[0104] The deployment models are as follows. Private cloud: The cloud infrastructure is operated solely for an organization. The cloud infrastructure may be managed by the organization or a third party and may exist on - premise or off - premise. Community cloud: The cloud infrastructure is shared by multiple organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by an organization or a third party and may exist on - premise or off - premise. Public cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services. Hybrid cloud: The cloud infrastructure remains a unique entity but is a composition of two or more clouds (private, community, or public) joined by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0105] A cloud computing environment is service-oriented, centered around statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0106] Referring now to FIG. 13, an exemplary cloud computing environment 1300 is shown. As illustrated, cloud computing environment 1300 includes one or more cloud computing nodes 1200 that may communicate with local computing devices used by cloud consumers such as, for example, a personal digital assistant (PDA) or cellular telephone 1300A, a desktop computer 1300B, a laptop computer 1300C, or an automotive computer system 1300N, or combinations thereof. Nodes 1200 may communicate with each other. They may be physically or virtually grouped within one or more networks (not shown) such as a private cloud, community cloud, public cloud, or hybrid cloud as described above, or combinations thereof. This allows cloud computing environment 1300 to offer infrastructure, platform, software, or combinations thereof, as services such that cloud consumers need not maintain resources on local computing devices. The types of computing devices 1300A - N shown in FIG. 13 are intended to be exemplary only, and it is to be understood that cloud computing nodes 1200 and cloud computing environment 1300 may communicate with any type of computerized device via any type of network or network addressable connection or both (e.g., using a web browser).

[0107] Referring now to FIG. 14, a set of functional abstraction layers 1400 provided by a cloud computing environment 1300 is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 14 are intended to be merely exemplary, and embodiments of the invention are not limited thereto. As shown, the following layers and corresponding functions are provided.

[0108] The hardware and software layer 1402 includes hardware and software components. Examples of hardware components include mainframe 1404, RISC (Reduced Instruction Set Computer) architecture-based server 1406, server 1408, blade server 1410, storage device 1412, and network and networking components 1414. In some embodiments, the software components include network application server software 1416 and database software 1418.

[0109] The virtualization layer 1420 provides an abstraction layer that can provide the following examples of virtual entities: virtual server 1422, virtual storage 1424, virtual network 1426 including a virtual private network, virtual applications and operating systems 1428, and virtual client 1430.

[0110] In one example, the management layer 1432 may provide the functions described below. Resource provisioning 1434 provides for the dynamic procurement of computing resources and other resources that are utilized to execute tasks within a cloud computing environment. Measurement and pricing 1436 provides cost tracking when resources are utilized within the cloud computing environment and are billed or charged for the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. The user portal 1438 provides access to the cloud computing environment for consumers and system administrators. Service level management 1440 provides cloud computing resource allocation and management such that the required service levels are met. Service level agreement (SLA) planning and enforcement 1442 provides for the pre - placement and procurement of cloud computing resources where future requirements are anticipated according to the SLA.

[0111] The workload layer 1444 provides examples of functionality that the cloud computing environment may utilize. Examples of workloads and functions that may be provided from this layer include mapping and navigation 1446, software development and lifecycle management 1448, virtual classroom education delivery 1450, data analysis processing 1452, transaction processing 1454, as well as cryptographic key object processing and protection key provisioning processing 1456. The functions of cryptographic key object processing and protection key provisioning processing were described in the foregoing embodiments of the present invention.

[0112] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. The terms "comprises", "comprising", "includes", "including", "has", "have", "having", "with", and the like, when used herein, specify the presence of the stated feature, integer, step, operation, element, or component, or combinations thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

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

Claims

Claim 1 A computer-implemented method for providing a cryptographic key object to a guest virtual server for use in cryptographic operations, comprising: registering, by the guest virtual server, with a trusted hypervisor, the registering including using a guest certificate; generating, by the trusted hypervisor, a guest wrapping key and associating the guest wrapping key with the guest certificate; when receiving, from the guest virtual server, a request along with the guest certificate as an argument, generating, by the trusted hypervisor, a satellite virtual server instance composed of virtual server-specific data from the guest virtual server for the guest virtual server, the satellite virtual server instance sharing a master key with the guest virtual server, the master key being inaccessible by the trusted hypervisor or any guest virtual server; transferring, by the trusted hypervisor, a copy of the guest wrapping key to the satellite virtual server instance; generating, by the trusted hypervisor, a random guest key; wrapping, by the trusted hypervisor, the random guest key with the guest wrapping key to create a wrapped guest key; when receiving a transformation request from the guest virtual server, performing a transformation of the wrapped guest key to change the wrapped guest key into a protection key, the transformation including re-wrapping the wrapped guest key with the master key to form a protected guest key, the protected guest key serving as the cryptographic key object; A computer-implemented method comprising the above steps. Claim 2 The method according to claim 1, wherein the transformation further includes the satellite virtual server instance unwrapping the wrapped guest key using the guest wrapping key. Claim 3 The method according to claim 1 or 2, wherein the transformation request includes the guest certificate as a transformation argument. Claim 4 The method according to any one of claims 1 to 3, wherein the trusted hypervisor maintains a key repository associated with data necessary for verifying the guest certificate.

5. The method according to claim 4, wherein the trusted hypervisor uses an encrypted one-way function to calculate the data necessary for verifying the guest certificate.

6. The method according to claim 4, wherein the key repository is protected by a passphrase.

7. The method according to any one of claims 1 to 6, wherein the guest wrapping key is protected by a hardware security module.

8. The method according to any one of claims 1 to 7, wherein the virtual server specific data is data stored in an encrypted control block of a virtual machine.

9. The satellite virtual server instance has a single interface, The method according to any one of claims 1 to 8, wherein the single interface connects to the trusted hypervisor.

10. The method according to any one of claims 1 to 9, wherein the trusted hypervisor uses services from the satellite virtual server instance to generate a random key and wrap the random key with the guest wrapping key.

11. Further comprising authorizing each request by the trusted hypervisor subsequent to the registering, The method according to any one of claims 1 to 10, wherein the authorizing includes using an additional guest certificate provided with each request subsequent to the registering.

12. Further comprising authorizing further requests for guest virtual server requests by the trusted hypervisor subsequent to the registering, The method according to any one of claims 1 to 11, wherein the authorizing the guest virtual server requests includes using guest specific data.

13. A computer system for providing an encryption key object to a guest virtual server for use in encryption operations, the computer system comprising: a processor, a computer-readable tangible storage medium, and program instructions stored on the computer-readable tangible storage medium for execution by the processor, the computer system comprising: Registration with a trusted hypervisor by the guest virtual server, the registration including using a guest certificate, the registration, and Generating a guest wrapping key by the trusted hypervisor and associating the guest wrapping key with the guest certificate, and When receiving a request together with the guest certificate as an argument from the guest virtual server, generating, by the trusted hypervisor, a satellite virtual server instance composed of virtual server specific data from the guest virtual server for the guest virtual server, the satellite virtual server instance sharing a master key with the guest virtual server, the master key being inaccessible by the trusted hypervisor or any guest virtual server, the generating, and Transferring a copy of the guest wrapping key to the satellite virtual server instance by the trusted hypervisor, and Generating a random guest key by the trusted hypervisor, and Creating a wrapped guest key by wrapping the random guest key with the guest wrapping key by the trusted hypervisor, and When receiving a conversion request from the guest virtual server, performing a conversion of the wrapped guest key to change the wrapped guest key to a protection key, the conversion including re-wrapping the wrapped guest key with the master key to form a protected guest key, the protected guest key serving as the cryptographic key object, the changing, and A computer system capable of executing a method including.

14. A program for causing each step of the method according to any one of Claims 1 to 12 to be executed.

15. A computer-readable tangible storage medium storing the program according to Claim 14.

Images