Secure Guest Metadata Extension for Binding Secure Guests to HSMs

Abstract

A method for implementing three-factor authorization in a trusted computing environment is disclosed. The method includes triggering the initiation of a secure guest by transferring control over an image of the secure guest and its respective metadata to trusted firmware, where the secure guest is designed to access a hardware security module, and, upon a successful integrity check of the secure guest metadata by the trusted firmware, launching the secure guest using a hypervisor and blocking any sensitive requests from the secure guest to the hardware security module. The method further includes submitting a request to the trusted firmware having a request structure including a third authorization secret and characteristics of the requested hardware security module, and binding a respective hardware security module protection key generated in the requested hardware security module upon the request for the third authorization secret by the secure guest.

Description

[Technical Field]

[0001] The present invention relates generally to a computer-implemented security method in a trusted computing environment, and more particularly to a computer-implemented method for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest. The present invention further relates to a security system and computer program product for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest. [Background technology]

[0002] Data and communication channel security remains one of the highest priorities for corporate information technology (IT) management. This is necessitated not only by government regulations (e.g., GDPR, EU Data Protection Regulation) but also by the loss of trust among companies that cannot always reliably protect customer data and to avoid lost revenue and profits if customer data records are compromised. Data protection and providing a secure computing platform are not simply software issues; hardware modules are also involved. This may not yet be a natural environment for mass-market CPU chips used in microcontrollers, personal computers, mobile phones, or home automation devices. However, for highly trusted enterprise-class computing environments, such as those used in the financial, insurance, or government industries, it is essential to be able to demonstrate a high probability of preventing data leakage from a technical perspective. This may require some additional high-tech components and support processes. However, the associated success in terms of data security is worth the additional effort.

[0003] These ideas are also applicable to trusted computing environments in which cryptographic keys used by virtual machines (also denoted as guests) or software containers running on or within a hypervisor cannot be practically accessed by the hypervisor or associated software management and configuration programs. Nevertheless, even in such computing environments, it remains possible to compromise basic security rules, such as revealing or using private keys for secure guest images through the hypervisor. This may be possible even in environments where hardware security modules (HSMs) have been used for some time.

[0004] There are already several disclosures that apply to the context of computer-implemented methods for implementing three-factor authorization in a trusted computing environment to have control using HSM-protected keys generated by a secure guest. Document US2020 / 0076607A1 describes how secrets are securely maintained on a virtual computer system by configuring a dedicated virtual machine to manage and maintain sequents on behalf of an application. When an application requests access to a secret, the control domain, in combination with the dedicated virtual machine, verifies that the application has permission to make the request and that the application has not been compromised before making the request.

[0005] A known problem in such environments can be identified in the context of being able to perform a master key roll or local key re-encryption while software components that use the encryption key continue to run. Furthermore, the master key used to encrypt the local key may be stored in multiple redundant HSMs that are accessible by the software components. Technologies such as openCryptoki or CCA (Common Cryptographic Architecture) still cannot adequately meet this requirement.

[0006] However, none of these approaches can reliably and completely protect against unauthorized disclosure of secrets or use of secrets for erroneous and unauthorized guest images. Therefore, these open problems need to be addressed. Summary of the Invention

[0007] According to one aspect of the present invention, a computer-implemented method for implementing three-factor authorization for control using a key protected by a hardware security module and generated by a secure guest in a trusted computing environment may be provided. The method may include triggering initiation of a secure guest by a hypervisor by handing over control over the secure guest's image and respective metadata to trusted firmware, where the secure guest is designed to access the hardware security module. Upon successful integrity check of the secure guest metadata by the trusted firmware, the method may also include starting the secure guest using the hypervisor and blocking any sensitive requests from the secure guest to the hardware security module.

[0008] Further, the method may include a step of submitting, by the secure guest, a request to the trusted firmware having a request structure including a third authorization secret and characteristics of the requested hardware security module, and a step of binding, by the trusted firmware, upon the secure guest's request for the third authorization secret, each hardware security module protection key generated in the requested hardware security module.

[0009] According to another aspect of the present invention, there may be provided a security system for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest. The system may include one or more processors and memory operatively coupled to the one or more processors, where the memory stores program portions that, when executed, enable the one or more processors to trigger, by a hypervisor, the initiation of a secure guest by handing over control over an image of the secure guest and respective metadata to trusted firmware, where the secure guest is designed to access a hardware security module (HSM).

[0010] The processor may further be capable of starting the secure guest using the hypervisor and blocking any sensitive requests from the secure guest to the hardware after a successful integrity check of the secure guest metadata by the trusted firmware.

[0011] Additionally, the processor may be capable of causing the secure guest to submit a request to the trusted firmware having a request structure including a third authorization secret and characteristics of the requested hardware security module, and binding, by the trusted firmware, upon the secure guest's request for the third authorization secret, each hardware security module protection key generated in the requested hardware security module.

[0012] The proposed computer-implemented method for implementing three-factor authorization may provide multiple advantages, technical effects, contributions, and / or improvements.

[0013] The proposed concept may increase the security of confidential computing environments: in particular, the theft of access credentials of one secure guest for use by another secure guest, as well as the associated binding to a specific hardware security module, i.e., secret use for a secure image, may become impossible.

[0014] In particular, the shortcomings of conventional solutions can be overcome. Traditionally, the use of HSM-protected keys is protected by two factors: (1) access to the key object or key handle, and (2) possession of the HSM (i.e., having exclusive access to the HSM). In the case of virtual servers (aka guests) running in a virtualized environment, the second factor is weak because access to the HSM can be configured by an untrusted hypervisor administrator and therefore granted to an untrusted virtual server.

[0015] To solve this problem, a third factor is introduced that is a secret that is stored by the trusted FW on behalf of the secure guest and used to associate all HSM-protected keys so that these keys can only be used by the secure guest for whom the trusted FW has stored that third authorization factor secret.

[0016] It should also be noted that the term authorization factor has been used here instead of the more general term "authentication factor." The relationship between authorization factors and authentication factors is as follows: in order for a subject to obtain an authorization factor to use a key object or handle, the subject must provide the associated authentication factor: i.e., provide a login certificate (factor 1) to the environment with exclusive access to the HSM (factor 2), and provide a third authorization secret to the trusted firmware controlling the environment (factor 3).

[0017] This may be handled via an extension of the metadata used for the secure guest. In particular, upon initiation of the secure guest by the hypervisor, the third authorization factor secret, particularly in encrypted form, may be loaded into trusted firmware where it is decrypted for further use with the secure guest.

[0018] In certain use cases, it may not be appropriate for the third authorization factor secret to be included in the initial metadata of the secure guest. In particular, if the secure guest image can be generic software, a user-specific secret such as the third authorization factor secret cannot be included in the initial metadata of the generic secure guest. Therefore, the third authorization factor secret must be provided to the trusted firmware (FW) in a secure manner by the running secure guest after the secure guest code has turned the generic secure guest into a guest belonging to a specific user.

[0019] This ensures security by requiring that only a trusted FW can learn the plaintext values ​​of things like third authorization factor secrets, which will only be accepted by specific secure guests.

[0020] This may make it impossible for untrusted components to intercept communication between the secure guest and the trusted firmware in order to steal access credentials as well as HSM bindings, so that the used secrets of the certificates are no longer available for the "rogue guest image."

[0021] Further embodiments of the inventive concept that are applicable to methods and systems are described below.

[0022] According to an advantageous embodiment, the method may also include unblocking sensitive requests to the requested hardware security module from a secure guest that can only operate on at least one hardware security module protection key bound to the third authorization secret. Thus, initially, the secure guest, as well as any other guest, cannot trigger any cryptographic / sensitive requests to the HSM. However, once a secure guest can initiate and request binding to a specific HSM (i.e., by extending metadata with the third factor authorization secret for the HSM), only the secure guest that initiated the binding can potentially interact with the specified HSM. Neither any other guest on the hypervisor, nor the hypervisor itself, can misuse the stolen certificate to interact with the HSM on behalf of the only authorized secure guest.

[0023] According to a preferred embodiment, the method may comprise instructing, by the trusted firmware, a hardware security module of the computing system to bind each generated key to a third authorization secret. This may form the basis for being able to accept keys bound to the third authorization secret, i.e., secure guest requests may be routed through the trusted FW to the HSM. The trusted FW may thereby intercept the relevant requests and forward them in modified form to the HSM.

[0024] According to another preferred embodiment of the method, the request structure may be integrity protected and partially encrypted, so that only trusted firmware, particularly of the target system, may be allowed to decrypt the encrypted portion of the request structure and thereafter verify the integrity of the associated request.

[0025] That is, the trusted FW and the target system may be related to each other in the sense that the target system may hold (store) a private key that helps to verify the integrity and thus allow the encrypted portion to be decrypted. As a result, the trusted FW may be able to reject requests using request structures whose integrity it cannot verify.

[0026] Furthermore, simple checksum protocols are not sufficient for integrity checking: the integrity check must be cryptographically secure, and therefore hash values, comparisons, digital signatures, or message authentication codes (MACs) are suitable means to enable integrity checking.

[0027] According to a further advantageous embodiment of the method, the encrypted portion of the request structure may comprise a third authorization secret, so that simple interception of the communication path from the secure guest to the trusted firmware may not be sufficient to compromise the system.

[0028] According to a useful embodiment of the method, the metadata of the secure guest maintained by the trusted firmware may include (a secret derived from) the extended secret, and the trusted FW will reject any request that does not include the extended secret. It should be understood that the metadata is thereby transferred to the trusted firmware during or at the start of the secure guest. The secrets and keys are encrypted outside the system and can only be decrypted using the trusted firmware. These decrypted secrets and keys may then be stored in the trusted firmware or in storage controlled exclusively by the trusted firmware for later use.

[0029] This feature may be one of the bases for the trusted firmware to reject requests using request structures that do not include the extended secret in addition to the third authorization secret in its encrypted portion, thus enforcing that only the creator of the original metadata can generate a valid request to add the third element authorization secret to the meta, unless the creator discloses the extended secret to a third party.

[0030] According to another useful embodiment of the method, a secure guest may submit a request to the trusted firmware via a direct firmware call. Such a call to the trusted firmware may ensure that any transmitted data is not intercepted and / or observed by the hypervisor or any management software. Furthermore, the trusted firmware may associate the request with a component of the system (here, a particular secure guest) that submitted the request.

[0031] Because not all requests to the hardware security module must be considered sensitive, some limited access to the hardware security module may be granted before the third authorization factor secret is associated with the hardware security module.

[0032] All cryptographic requests targeted to the hardware security module can also be submitted to trusted firmware as direct firmware calls, providing a pass-through attachment of the hardware security module to the secure guest so that the hypervisor cannot observe data exchanged between the secure guest and the hardware security module.

[0033] According to a further embodiment of the method, each request to a hardware security module having a hardware security module protection key may be classified as sensitive, and therefore the mechanisms described above for accessing specific hardware security modules may be applied during startup of the secure guest.

[0034] Because not all requests to the hardware security module should be considered sensitive, some limited access to the hardware security module may be granted before the third authorization factor secret is associated with the hardware security module.

[0035] The same positive behavior may be the result of another useful embodiment of the method, in which each request that returns a result containing a hardware security module protected key is sensitive.

[0036] Again, the following can be stated about this feature: since not all requests to the hardware security module should be considered sensitive, some limited access to the hardware security module may be granted before the third authorization factor secret is associated with the hardware security module.

[0037] According to a further developed embodiment of the method, the request structure may comprise measurements of the secure guest, and the trusted FW may reject the request if the measurements do not match measurements of the image of the secure guest submitting the request structure. The measurements may comprise a hash value, a digital signature, or a MAC (Message Authentication Code). This may represent an automatic blocking mechanism.

[0038] According to another advanced embodiment of the method, the request structure may include measurements of a portion of the secure guest's metadata, and the trusted firmware may reject the request if the measurements of the metadata do not match the measurements of the metadata of the secure guest submitting the request structure. The addition of measurements, for which a hash value, digital signature, or MAC may again be used, may again represent an auto-blocking mechanism.

[0039] According to an advantageous embodiment, the method may also comprise protecting the third authorization factor secret against access from any guest and hypervisor by the trusted firmware. Additionally, any other access requests from any other untrusted component of the system may be denied in the same manner. In particular, a secure guest submitting a request structure that includes the third authorization secret in an encrypted portion of the request structure should not be able to access the third authorization factor from the trusted firmware.

[0040] According to an enhanced embodiment, the method may comprise instructing, by the trusted firmware, the hardware security module to no longer accept keys bound to the third authorization secret if access to the hardware security module is provided to an untrusted component. In a sense, this can be seen as a self-locking mechanism that protects against unauthorized access for any further attempts.

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

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

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

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

[0045] [Figure 1] FIG. 1 illustrates a block diagram of one embodiment of a computer-implemented method of the present invention for implementing three-factor authorization for control in a trusted computing environment protected by a hardware security module and using keys generated by a secure guest.

[0046] [Figure 2] 1 shows a block diagram of security threats using trusted firmware and even when a hardware security module is used.

[0047] [Figure 3] 1 shows a further block diagram of how two-factor authorization operates in a trusted computing environment.

[0048] [Figure 4] 1 shows a block diagram of three-factor authorization for a trusted computing environment.

[0049] [Figure 5] 2 shows a flow chart of further and optional steps of the flow diagram according to FIG. 1;

[0050] [Figure 6] 4 shows a flowchart of the proposed security method in another aspect and in more detail.

[0051] [Figure 7] 1 illustrates components of the inventive concept in relation to one another.

[0052] [Figure 8] FIG. 1 illustrates a block diagram of one embodiment of a security system of the present invention for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest.

[0053] [Figure 9] 8 illustrates an embodiment of a computing system including a security system. DETAILED DESCRIPTION OF THE INVENTION

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

[0055] The term "three-factor authorization" may refer to a procedure under which access to computer system resources may be granted only if three conditions are met independently of one another. A well-known example is two-factor authorization for online banking, where a user enters a username and passphrase and receives a further security code via a smartphone, for example, to be entered via a browser. This concept may be enhanced by a third independent component to make access to system resources significantly more secure.

[0056] The term "key protected by a hardware security module" may indicate that encryption of the protected key may only be possible using a master key from the hardware security module, whereby access to the hardware security module may only be possible to avoid trusted firmware.

[0057] The term "secure guest" may refer to a virtual machine or software container that contains executable program code in a secure computing environment protected by a trusted execution environment such that untrusted components of the computer system cannot observe any state (memory or registers) of the running secure guest. Typical untrusted components are software hypervisors, hardware management consoles, and other guests.

[0058] The term "trusted computing environment" may refer to a computing environment in which a hypervisor on any system management software with a user interface component may access or intercept virtual machines, particularly the encryption and decryption keys used.

[0059] The term "hypervisor" may refer to a well-defined type of computer software or firmware that creates and runs virtual machines or software containers. Thus, multiple virtual machines / software containers can run in parallel without any risk of cross-referencing. An error in one virtual machine cannot cause any damage to another virtual machine. Each virtual machine may own a defined address space.

[0060] The term "secure guest image" may refer to one or more files that contain executable software components to be run as a secure guest using a hypervisor.

[0061] The term "metadata" may refer in its classical sense to information about data, and here in particular to data required to start a virtual machine. Such information may be used by the trusted firmware to start the virtual machine and may include, for example, integrity measures of the secure guest's image or keys required to decrypt the secure guest's image. These metadata may include, for example, the required resources, the required interfaces, the required performance, and possibly also which security measures are appropriate. An extension of the metadata and the proposed concept may be further private keys used by the trusted firmware and handed over, for example, by the hypervisor before the virtual machine (or software container) is started or by the secure guest during execution.

[0062] The term "trusted firmware" (trusted FW or TFW) may refer to a component that is deeply embedded in the hardware of a computing (mainframe) system and is inaccessible by any other user-controlled software. Trusted firmware may have a predefined, highly secure application programming interface to protect the functionality of the trusted firmware in a broad sense. Trusted FW should not be seen as a service component, but rather as a deeply integrated component of the computer system. The communication channel to and from trusted firmware is typically cryptographically protected.

[0063] In the context of confidential computing, trusted firmware may implement a trusted execution environment (TEE). One example of a trusted computing environment is the Ultravisor of Secure Execution for Linux feature of the IBM Z system.

[0064] The term "integrity check" may refer to ensuring that a component, particularly a request structure, can be consistent with itself. For this purpose, a hash value comparison, a digital signature, or a message authentication code (MAC) may typically be used.

[0065] The term "block any sensitive request" may refer to the refusal to forward or perform any request that requires special protection / encryption of the exchanged information.

[0066] The term "request structure" may refer to a data structure that describes details to be used as part of a request for binding between a secure guest and a particular selected hardware security module. This request structure may be integrity protected and may be partially encrypted, and the encrypted portion may also contain a third authorization secret, which is accessible only to the trusted firmware and can be decrypted using a key stored in a dedicated storage area of ​​the trusted firmware for further use.

[0067] The term "third authorization secret" may refer to the third component for a three-factor authentication protocol. In the context of this document, the first factor may be a credential (e.g., a user ID and password) for gaining access to a secure guest, and the second factor may be an access path to a particular hardware security module.

[0068] The term "integrity protected" may indicate that a data structure may have an inherent consistency structure and has not been tampered with since its creation, i.e., its integrity may be checked using, for example, a hash value, a digital signature, or a MAC.

[0069] The term "hardware security module" (HSM) may refer to a hardware element connected to or integrated into a computer system, e.g., a server system, e.g., a manufacturing server computer here. HSMs are designed to protect secrets, i.e., software keys, so that they cannot be tampered with and against unauthorized access, as well as against physical penetration and / or unscheduled physical de-plugging. HSMs may be tightly linked to a CPU or may operate independently of the CPU. In other words, an HSM is a physical computing device that protects and manages one or more digital keys for strong authentication and provides cryptographic processing. These modules may traditionally be in the form of a plug-in card or an external device that can be directly attached to a computer or network server.

[0070] The term "extended secret" may refer to a secret that, when it is part of or derived from a secret in metadata, can ensure that only the creator of the metadata can create the required structures to modify (e.g., extend) the metadata.

[0071] The term "binding a hardware security module protection key to a secret" may mean that the integrity-protected indication is part of the hardware security protection key, and as such this key may be considered valid by the hardware security module if trusted firmware, and possibly the hardware security module, has access to the secret.

[0072] A detailed description of the figures is provided below. All instructions in the figures are schematic. First, a flowchart of one embodiment of a computer-implemented method of the present invention for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest is provided. After that, further embodiments, as well as embodiments of a security system for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest, are described.

[0073] 1 shows a block diagram of a preferred embodiment of a computer-implemented method 100 for implementing three-factor authorization for control in a trusted computing environment protected by a hardware security module and using keys generated by a secure guest. The secure guest may comprise, for example, a virtual machine or software container, or simply a container, containing executable code.

[0074] The method 100 comprises a step 102 of triggering the initiation of a secure guest by the hypervisor by handing over control over the secure guest's image and respective metadata to trusted firmware, the secure guest being designed to access a hardware security module.

[0075] Method 100 also comprises, upon successful integrity check 104 of the secure guest metadata by the trusted firmware, stage 106 of starting the secure guest using the hypervisor, and stage 108 of blocking any sensitive requests from the secure guest to the hardware security module. It should also be mentioned that at a later stage in the secure guest's lifetime, blocking stage 108 may be released again once a final secure association between the secure guest and the selected hardware security module has been established.

[0076] Method 100 also comprises step 110 of submitting by the secure guest to the trusted firmware a request including a third authorization secret, i.e., a request structure including the third factor and characteristics of the requested hardware security module, and step 114 of advantageously and exclusively binding by the trusted firmware, upon request 112 by the secure guest, each hardware security module protection key generated in the requested hardware security module to the third authorization secret. After this binding 114, the virtual secure guest should now be able to submit sensitive cryptographic requests to the requested HSM, i.e., such requests are no longer blocked.

[0077] 2 shows a block diagram 200 of security threats even with the use of trusted firmware and / or security modules. All components preferably run as part of computer system 202. So closely associated with computer system 202 is trusted firmware 204, which cannot be modified by the user of the computer system and is installed and enabled during the manufacture of computer system 202.

[0078] Additionally, one or more hardware security modules HSM-1 through HSM-i 206 may be components of computer system 202, where, for example, HSM keys to be used to protect HSM-protected keys may be stored and may only be accessed using well-defined, strict access procedures.

[0079] The next layer in the stack architecture is represented by hypervisor 208, which enables running guests 210, 212, 214, e.g., virtual machines or containers containing executable code. Secure guest 210 may illustratively maintain security key 212, which may be protected by a master key managed by HSM 206. However, private key 220 may be exposed such that secure guest-2 212 may have access to it, i.e., by stealing 216 the key, and in a situation where the HSM binding to a particular HSM-1 206 has also been stolen 218 by reconfiguring HSM access from secure guest 210 to secure guest 212, private key 220 may be misused by secure guest-2 212, i.e., for an incorrect guest image.

[0080] Figure 3 shows a further block diagram 300 of how two-factor authentication works in a trusted computing environment, where the main components are the same as in Figure 2. It only shows how the first and second security elements are stolen by Secure Guest-2 212 to gain unauthorized access to HSM-1 206.

[0081] 4 shows a block diagram 400 of three-factor authentication for a trusted computing environment. The third authentication factor allows the above threat to be successfully avoided. Here, the key inside one of the secure guests 210 is now protected by another protection shield, namely, a third authorization factor 404, and as a result, secure guest-1 is protected by this third factor. To access this protection mechanism, a secret 402 is loaded into the trusted firmware 204 for secure guest-1 at the time of initialization of secure guest-1 210 as further metadata of secure guest-1 210.

[0082] Such further protection may be enabled for each secure guest (secure guest-2, ... secure guest-n), as indicated by the additional dotted line surrounding the security key of secure guest-2 214. In this way, the excessive threat 406 from the stolen key and HSM binding belonging to secure guest-1 210 by secure guest-2 214 can be stopped altogether. This theft 216 of the key representing authentication factor 1 and the theft 218 of the HSM binding representing authentication factor 2 is now no longer sufficient to illegitimately establish the binding of secure guest-2 214.

[0083] Figure 5 shows a flowchart 500 of additional and optional steps for the flow diagram according to Figure 1. These additional activities can be performed in conjunction with or as an extension of the flowchart described in the context of Figure 1. They also do not have to be performed in the sequence shown. They can be performed before, in parallel with, or after some of the steps according to Figure 1.

[0084] These further steps comprise receiving 502 an image of the secure guest and its respective metadata by the hypervisor and trusted firmware, respectively. The trusted firmware may then trigger the initiation of the secure guest, provided that the integrity checks have been performed as described above, 504. At this early stage of the secure guest's execution, any sensitive access of the secure guest to the HSM is blocked. In a further step, the running secure guest (s-guest) receives 506 a request structure, e.g., from an operator or user of the secure guest or the respective program. The running secure guest may then submit 508 the request structure to the trusted firmware. The trusted firmware (TFW) then performs 510 an integrity check of the request, and if the check is successful, the respective HSM and secret as part of the request are associated with each other. From this point on, sensitive requests (e.g., cryptographic requests) from each secure guest to its corresponding HSM are now allowed and are no longer blocked. Thus, the protocol has been fully executed.

[0085] 6 shows a more detailed flowchart of the proposed security method under another aspect, particularly detailing the blocking and evaluation of cryptographic requests. Process 600 begins at step 602, where a secure guest submits a cryptographic request to a trusted FW. After receiving the cryptographic request, the trusted FW intercepts 604 the cryptographic request from the secure guest for a hardware security module (i.e., a target HSM). A decision 606 is then made as to whether the target HSM is bound to (or associated with) a third authorization secret. If so, i.e., "Y," then the trusted FW forwards 608 the request to the HSM and returns the result to the secure guest.

[0086] Otherwise, if 'N', ie, the target HSM is not bound (or associated) with a third authorization secret, the trusted FW evaluates 610 the type of cryptographic request.

[0087] If the type of cryptographic request is determined 612 to be sensitive, i.e., "Y," the trusted FW resends 614 the request to the HSM, optionally after possible modification based on the third authorization secret, and returns the result to the secure guest, again optionally after possible modification based on the third authorization secret. Otherwise, i.e., "N," the trusted FW rejects 616 the request and returns an error to the calling guest. Thus, if the intercepting trusted FW determines that no association exists between the requesting secure guest and the required HSM, no unauthorized secure guest can successfully perform a cryptographic request.

[0088] Figure 7 shows the components 700 of the inventive concept along with their relationship to each other. Everything takes place in the context of a computer system 702, e.g., a mainframe computing system. A hypervisor 704 enables the execution of a secure guest 706. The secure guest can be seen as a cloud computing resource for a remote user. The (remote) user can use tools in the trusted environment of the resource owner to generate a requirement structure 708.

[0089] Additionally, the computing system 702 may also include trusted firmware (FW) 712, and as part thereof, secure trusted metadata having secrets for the running secure guest 706. These metadata may be loaded during startup of the secure guest 706.

[0090] The request structure 708 is typically encrypted with the help of a public host key (not shown). The counterpart of the public host key is a private host key 714 maintained by the trusted FW. The encrypted request structure 708 includes a private key (shown as part of the request structure 708) that can be added to secure guest metadata 710. The private key, once part of the secure guest metadata (MD) 710, essentially creates a gatekeeper between the secure guest and a particular hardware security module (HSM) 716. The arrow between the private key as part of the secure guest MD 710 and the HSM 716 represents the binding 718 of the running secure guest 706 and the selected HSM 716, which can be part of one HSM among multiple HSMs.

[0091] 8 illustrates a block diagram of one embodiment of a security system 800 of the present invention for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest. The system 800 comprises one or more processors 802 and a memory 804 operatively coupled to the one or more processors 802, the memory 804 storing program portions that, when executed, enable the one or more processors to trigger the initiation of a secure guest by a hypervisor or hypervisor controller 806 by handing over control over the secure guest's image and respective metadata to trusted firmware, where the secure guest is designed to access the hardware security module.

[0092] Once the processor 802 has successfully checked the integrity of the secure guest metadata by the trusted firmware, it can then start the secure guest using the hypervisor, for example via the initiation module 808, and in particular block any sensitive requests from the secure guest to the hardware security module 812 via the block unit 810.

[0093] In addition, the processor 802 is also capable of, in particular, by a submission unit 812 that may be triggered by the secure guest, submitting a request to the trusted firmware including a request structure that includes the third authorization secret and an identifier of the requested hardware security module, and, in particular, by a binding module 814 that may be triggered by the trusted firmware, binding each hardware security module protection key generated in the requested hardware security module to the third authorization secret upon request by the secure guest.

[0094] It should also be mentioned that all functional units, modules, and functional blocks, in particular one or more processors 802, memory 804, hypervisor controller 806, initiation module 808, block unit 810, hardware security module 812, and binding module 814, may be communicatively coupled to each other for signal or message exchange in a selected one-to-one manner. Alternatively, the functional units, modules, and functional blocks may be linked to an internal bus system 816 of the system for selective signal or message exchange.

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

[0096] A computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media"), collectively contained in one or more storage devices, that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. The computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices (such as punch cards or pits / lands formed on a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through fiber optic cables, electrical signals communicated through wires, and / or other transmission media.As will be appreciated by those skilled in the art, data is typically moved at some infrequent time during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transient because the data is not transient while it is stored.

[0097] FIG. 9 illustrates a computing environment 900 that includes an example of an environment for the execution of at least some of the computer code involved in implementing the methods of the present invention, such as a computer-implemented method 100, 950 for implementing three-factor authorization for control using keys protected by a hardware security module and generated by a secure guest in a trusted computing environment.

[0098] In addition to block 950, computing environment 900 includes, for example, a computer 901, a wide area network (WAN) 902, an end user device (EUD) 903, a remote server 904, a public cloud 905, and a private cloud 906. In this embodiment, computer 901 includes a set of processors 910 (including processing circuitry 920 and cache 921), a communications fabric 911, volatile memory 912, persistent storage 913 (including an operating system 922 and the above-identified block 950), a set of peripheral devices 914 (including a user interface (UI), a set of devices 923, storage 924, and a set of Internet of Things (IoT) sensors 925), and a network module 915. Remote server 904 includes a remote database 930. Public cloud 905 includes a gateway 940, a cloud orchestration module 941, a set of host physical machines 942, a set of virtual machines 943, and a set of containers 944.

[0099] Computer 901 may take the form of a desktop computer, a laptop computer, a tablet computer, a smartphone, a smartwatch or other wearable computer, a mainframe computer, a quantum computer, or any other form of computer or mobile device now known or later developed that is capable of running programs, accessing a network, or querying a database, such as remote database 930. As is well understood in the art of computer technology, and depending on the technology, execution of a computer-implemented method may be distributed among multiple computers and / or among multiple locations. While in this presentation of computing environment 900, to keep the presentation as concise as possible, the detailed discussion focuses on a single computer, specifically computer 901. Although computer 901 is not depicted in the cloud of FIG. 9, it may be located in the cloud. However, computer 901 is not required to reside within a cloud except to any extent that may be expressly indicated.

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

[0101] Computer-readable program instructions are typically loaded onto the computer 901 to cause a series of operational steps to be performed by the processor set 910 of the computer 901, thereby realizing a computer-implemented method, whereby the instructions so executed instantiate the method specified in the flowcharts and / or descriptions of the computer-implemented method (collectively referred to as the "methods of the present invention") contained herein. These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 921 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 910 to control and direct the execution of the methods of the present invention. In the computing environment 900, at least some of the instructions for implementing the methods of the present invention may be stored in block 950 in persistent storage 913.

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

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

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

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

[0106] The network module 915 is a collection of computer software, hardware, and firmware that enables the computer 901 to communicate with other computers over the WAN 902. The network module 915 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for communicating data over the Internet. In some embodiments, the network control and network forwarding functions of the network module 915 are implemented on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control and forwarding functions of the network module 915 are implemented on physically separate devices, such that the control function manages several different network hardware devices. Computer-readable program instructions for implementing the methods of the present invention can be downloaded to the computer 901 from an external computer or external storage device, typically through a network adapter card or network interface included in the network module 915.

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

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

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

[0110] A public cloud 905 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer functionality, particularly data storage (cloud storage) and computing power, without direct, active management by users. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct, active management of the public cloud's 905 computing resources is performed by computer hardware and / or software in a cloud orchestration module 941. The computing resources provided by the public cloud 905 are typically implemented by virtual computing environments running on various computers that comprise a host physical machine set 942, which is the universe of physical computers in and / or available to the public cloud 905. A virtual computing environment (VCE) typically takes the form of a virtual machine from a virtual machine set 943 and / or a container from a container set 944. It is understood that these VCEs may be stored as images and may be transferred among and between various physical machine hosts either as images or after instantiation of the VCE. Cloud orchestration module 941 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 940 is a collection of computer software, hardware, and firmware that enables public cloud 905 to communicate over WAN 902.

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

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

[0113] It should also be mentioned that the security system 800 for implementing three-factor authorization for control in a trusted computing environment, protected by a hardware security module and using keys generated by a secure guest, may be an operational subsystem of the computer 801 and may be attached to a bus system within the computer.

[0114] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It can be further understood that the terms "comprises" and / or "comprising," as used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, components of elements, and / or groups thereof.

[0115] In the following claims, the corresponding structure, material, acts, and equivalents of all means-plus-function or step-plus-function elements are intended to include any structure, material, or acts for performing the function in combination with the elements of other claims as specifically claimed. The description of the present invention has been presented for purposes of illustration and description, but is not intended to be exhaustive or to limit the invention to the form disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the invention. The embodiments have been chosen and described to best explain the principles and practical application of the invention and to enable others skilled in the art to understand the invention in various embodiments with various modifications as suitable for the particular uses contemplated.

[0116] In summary, the concept of the present invention can be summarized by the following items. 1. 1. A computer-implemented method for implementing three-factor authorization for control in a trusted computing environment protected by a hardware security module and using keys generated by a secure guest, the method comprising: - triggering the initiation of a secure guest by the hypervisor by handing over control and respective metadata about the image of said secure guest to a trusted firmware, said secure guest being designed to access a hardware security module; If the integrity check of the secure guest metadata by the trusted firmware is successful, - starting the secure guest using the hypervisor; and - blocking any sensitive requests from the secure guest to the hardware security module; - submitting, by the secure guest, a request to the trusted firmware, the request structure including a third authorization secret and a required characteristic of a hardware security module; binding, by the trusted firmware, upon a request by the secure guest for the third authorization secret, each hardware security module protection key generated in the requested hardware security module. A method comprising: 2. unblocking sensitive requests from the secure guest to the requested hardware security module operating only on at least one hardware security module protection key bound to the third authorization secret. The method of item 1 further comprises: 3. instructing the hardware security module by the trusted firmware to bind each key generated to the third authorization secret. The method according to item 1 or 2, further comprising: 4. 10. The method of claim 9, wherein the request structure is integrity protected and partially encrypted, such that only the trusted firmware can decrypt the encrypted portion of the request structure and thereafter verify the integrity of the associated request. 5. Item 5. The method of item 4, wherein the encrypted portion of the request structure includes the third authorization secret. 6. The metadata of the secure guest maintained by the trusted firmware includes an extended secret, and the trusted firmware rejects all requests that do not include the extended secret. A method according to any of the preceding items. 7. The secure guest sends the request submitting the request structure and all sensitive cryptographic requests to the trusted firmware via a direct firmware call, where the request structure and all sensitive cryptographic requests are targeted to a hardware security module; A method according to any of the preceding items. 8. The method of any of the preceding items, wherein each request to the hardware security module that includes a hardware security module protection key is sensitive. 9. The method of any of the preceding items, wherein each request that returns a result that includes a hardware security module protection key is sensitive. 10. The method of any of the preceding items, wherein the request structure includes measurements of a secure guest, and the trusted firmware rejects the request if the measurements do not match the measurements of the image of the secure guest submitting the request structure. 11. The method of any of the preceding items, wherein the request structure includes measurements of a portion of the metadata of the secure guest, and the trusted firmware rejects the request if the measurements of the metadata do not match the measurements of the metadata of the secure guest submitting the request structure. 12. protecting, by the trusted firmware, the third authorization secret against access from any guest and the hypervisor. The method of any of the preceding items, further comprising: 13. Providing access to the hardware security module to an untrusted component instructing, by the trusted firmware, the hardware security module to no longer accept keys bound to the third authorization secret. The method according to any of the preceding items also comprises: 14. 1. A security system for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest, the system comprising: one or more processors; and memory operatively coupled to the one or more processors, wherein the memory, when executed, causes the one or more processors to - triggering the initiation of a secure guest by a hypervisor by handing over control and respective metadata about an image of said secure guest to a trusted firmware, said secure guest being designed to access a hardware security module; If the integrity check of the secure guest metadata by the trusted firmware is successful, - starting the secure guest using the hypervisor; and - blocking any sensitive requests from the secure guest to the hardware security module; submitting, by the secure guest, a request to the trusted firmware, the request structure including a third authorization secret and a desired characteristic of the hardware security module; binding, by the trusted firmware, upon a request by the secure guest for the third authorization secret, each hardware security module protection key generated in the requested hardware security module. Store the program part that allows you to A system comprising: 15. the one or more processors: unblocking sensitive requests from the secure guest to the requested hardware security module operating only on at least one hardware security module-protected key bound to the third authorization secret. Item 15. The system according to item 14, wherein the 16. the one or more processors: instructing the hardware security module by the trusted firmware to bind each key generated to the third authorization secret. The system according to item 14 or 15, further comprising: 17. 17. The system of any of items 14 to 16, wherein the request structure is integrity protected and partially encrypted, such that only the trusted firmware is able to decrypt the encrypted portion of the request structure and thereafter verify the integrity of the associated request. 18. Item 18. The system of item 17, wherein the encrypted portion of the request structure includes the third authorization secret. 19. 19. The system of any of claims 14 to 18, wherein the metadata of the secure guest maintained by the trusted firmware comprises an extended secret. 20. 20. The system of any of items 14 to 19, wherein the secure guest submits the request to the trusted firmware via a direct firmware call, and the request structure and all sensitive cryptographic requests target a hardware security module. twenty one. 21. The system of any of items 14 to 20, wherein each request to the hardware security module that includes the hardware security module protection key is sensitive. twenty two. 22. The system of any of items 14 to 21, wherein each request that returns a result including a hardware security system protection key is sensitive. twenty three. - the request structure includes measurements of a secure guest, and the trusted firmware rejects the request if the measurements do not match the measurements of the image of the secure guest submitting the request structure; or The request structure includes measurements of the metadata of the secure guest, and the trusted firmware rejects the request if the measurements of the metadata do not match the measurements of the metadata of the secure guest submitting the request structure. 23. The system according to any of items 14 to 22. twenty four. 24. The system of any of items 14 to 23, wherein the security also enables trusted firmware to protect the third authorization secret against access from any guest and the hypervisor. twenty five. 1. A computer program product for implementing three-factor authorization for control in a trusted computing environment protected by a hardware security module and using keys generated by a secure guest, the computer program product comprising: a computer-readable storage medium having program instructions embodied therein, the program instructions being transmitted by one or more computing systems or controllers to the one or more computing systems; - triggering the initiation of a secure guest by a hypervisor by handing over control and respective metadata about an image of said secure guest to a trusted firmware, said secure guest being designed to access a hardware security module; If the integrity check of the secure guest metadata by the trusted firmware is successful, - starting the secure guest using the hypervisor; and - blocking any sensitive requests from the secure guest to the hardware security module; submitting, by the secure guest, a request to the trusted firmware, the request structure including a third authorization secret and an identifier of a requested hardware security module; binding, by the trusted firmware, upon a request by the secure guest for the third authorization secret, each hardware security module protection key generated in the requested hardware security module. A computer program product executable to cause a

Claims

1. 1. A computer-implemented method for implementing three-factor authorization for control in a trusted computing environment protected by a hardware security module and using keys generated by a secure guest, the method comprising: - triggering the initiation of a secure guest by the hypervisor by handing over control and respective metadata about the image of said secure guest to a trusted firmware, said secure guest being designed to access a hardware security module; - if the integrity check of the secure guest metadata by the trusted firmware is successful, - starting the secure guest using the hypervisor; and - blocking any sensitive requests from the secure guest to the hardware security module; - submitting, by the secure guest, to the trusted firmware a request having a request structure including a third authorization secret and a required hardware security module characteristic; - binding, by the trusted firmware upon a request by the secure guest for the third authorization secret, each hardware security module protection key generated in the requested hardware security module. A method comprising:

2. - unblocking sensitive requests from the secure guest to the requested hardware security module operating only on at least one hardware security module protection key bound to the third authorization secret; The method of claim 1 , further comprising:

3. - instructing the hardware security module by the trusted firmware to bind each key generated to the third authorization secret; The method of claim 1 or 2, further comprising:

4. 4. The method of claim 1, wherein the request structure is integrity protected and partially encrypted, so that only the trusted firmware is able to decrypt the encrypted portion of the request structure and thereafter verify the integrity of the associated request.

5. The method of claim 4 , wherein the encrypted portion of the request structure comprises the third authorization secret.

6. The metadata of the secure guest maintained by the trusted firmware contains an extended secret, and the trusted firmware rejects all requests that do not contain the extended secret.

6. The method according to claim 1.

7. The secure guest sends the request submitting the request structure and all sensitive cryptographic requests to the trusted firmware via a direct firmware call, where the request structure and all sensitive cryptographic requests are targeted to a hardware security module; The method according to one of claims 1 to 6.

8. The method of claim 1 , wherein each request to the hardware security module that includes the hardware security module protection key is sensitive.

9. The method of claim 1 , wherein each request that returns a result that includes a hardware security module protection key is sensitive.

10. 10. The method of claim 1, wherein the request structure includes measurements of a secure guest, and the trusted firmware rejects the request if the measurements do not match the measurements of the image of the secure guest submitting the request structure.

11. 11. The method of claim 1, wherein the request structure includes measurements of a portion of the metadata of the secure guest, and the trusted firmware rejects the request if the measurements of the metadata do not match the measurements of the metadata of the secure guest submitting the request structure.

12. protecting, by the trusted firmware, the third authorization secret against access from any guest and from the hypervisor; The method according to claim 1 , further comprising:

13. Providing access to the hardware security module to an untrusted component - instructing, by the trusted firmware, the hardware security module to no longer accept keys bound to the third authorization secret; The method according to claim 1 , further comprising:

14. 1. A security system for implementing three-factor authorization for control in a trusted computing environment using keys protected by a hardware security module and generated by a secure guest, the system comprising: one or more processors and a memory operatively coupled to said one or more processors, said memory, when executed, causing said one or more processors to - triggering the initiation of a secure guest by a hypervisor by handing over control and respective metadata about the image of said secure guest to a trusted firmware, said secure guest being designed to access a hardware security module; - if the integrity check of the secure guest metadata by the trusted firmware is successful, - starting the secure guest using the hypervisor; and - blocking any sensitive requests from the secure guest to the hardware security module; - submitting, by said secure guest, to said trusted firmware a request having a request structure including a third authorization secret and a required hardware security module characteristic; binding, by the trusted firmware upon a request by the secure guest for the third authorization secret, each hardware security module protection key generated in the requested hardware security module; Store the program part that allows you to A system comprising:

15. the one or more processors unblocking sensitive requests to the requested hardware security module from the secure guest operating only on at least one hardware security module protection key bound to the third authorization secret; The system of claim 14, further comprising:

16. the one or more processors instructing the hardware security module to bind each key generated by the trusted firmware to the third authorization secret; The system according to claim 14 or 15, further comprising:

17. 17. The system of claim 14, wherein the request structure is integrity protected and partially encrypted, such that only the trusted firmware is able to decrypt the encrypted portion of the request structure and thereafter verify the integrity of the associated request.

18. 20. The system of claim 17, wherein the encrypted portion of the request structure comprises the third authorization secret.

19. 19. The system of claim 14, wherein the metadata of the secure guest maintained by the trusted firmware comprises an extended secret.

20. 20. The system of claim 14, wherein the secure guest submits the request to the trusted firmware via a direct firmware call, and the request structure and all sensitive cryptographic requests are targeted to a hardware security module.

21. 21. The system of claim 14, wherein each request to the hardware security module that includes the hardware security module protection key is sensitive.

22. 22. The system of claim 14, wherein each request that returns a result that includes a hardware security system protection key is sensitive.

23. - the request structure includes measurements of a secure guest, and the trusted firmware rejects the request if the measurements do not match the measurements of the image of the secure guest submitting the request structure, or the request structure includes measurements of the metadata of the secure guest, and the trusted firmware rejects the request if the measurements of the metadata do not match the measurements of the metadata of the secure guest submitting the request structure.

23. A system according to one of claims 14 to 22.

24. 24. The system of claim 14, wherein the security also enables the trusted firmware to protect the third authorization secret against access from any guest and the hypervisor.

25. 1. A computer program product for implementing three-factor authorization for control in a trusted computing environment protected by a hardware security module and using keys generated by a secure guest, the computer program product comprising: a computer-readable storage medium having program instructions embodied therein, the program instructions being transmitted by one or more computing systems or controllers to the one or more computing systems; - triggering the initiation of a secure guest by a hypervisor by handing over control and respective metadata about the image of said secure guest to a trusted firmware, said secure guest being designed to access a hardware security module; - if the integrity check of the secure guest metadata by the trusted firmware is successful, - starting the secure guest using the hypervisor; and - blocking any sensitive requests from the secure guest to the hardware security module; - submitting, by the secure guest, to the trusted firmware a request having a request structure including a third authorization secret and an identifier of a requested hardware security module; binding, by the trusted firmware upon a request by the secure guest for the third authorization secret, each hardware security module protection key generated in the requested hardware security module; A computer program product executable to cause a

Images