Method, system, and computer program for generating computations to be executed in a target trusted execution environment (TEE) (Provisioning secure / encrypted virtual machines in cloud infrastructure)

Abstract

To provide provisioning of secure / encrypted virtual machines in a cloud infrastructure.SOLUTION: The invention provides a method, system and apparatus for generating a computation so as to be executed in a target trusted execution environment (TEE), including: selecting the target TEE; generating an authorization that is satisfied by a TEE; associating the authorization with the computation to be executed in the TEE that is authorized, and generating the computation with the associated authorization.SELECTED DRAWING: Figure 2A

Description

[Technical Field]

[0001] The present invention relates to embodiments of methods, apparatus, and systems for secure / encrypted virtual machines, and more particularly, but not exclusively, to methods, apparatus, and systems for provisioning secure / encrypted virtual machines in a cloud infrastructure. [Background technology]

[0002] Cloud computing is an important aspect of enterprise infrastructure. Cloud infrastructure can be either private, public, or hybrid. One of the major challenges with hybrid and public clouds is that enterprises extend their trust boundaries to the cloud provider and its personnel. While the cloud has expanded dramatically, one of its major inhibitors is trust. Most cloud infrastructures assume from the start that the cloud provider and its staff can be trusted. Summary of the Invention [Problem to be solved by the invention]

[0003] Therefore, a major obstacle to cloud adoption is security. Therefore, there is a need to provide a more secure cloud computing platform that is efficient to implement and cost-effective. Furthermore, there is a need to provide a set of protocols that can achieve security in cloud computing without the need to trust the cloud provider. [Means for solving the problem]

[0004] In view of the above and other problems, disadvantages, and shortcomings of the background art discussed above, exemplary embodiments of the disclosed invention provide methods, apparatus, and systems for provisioning secure / encrypted virtual machines in a cloud infrastructure.

[0005] According to an embodiment of the present invention, a method for generating a computation to be executed in a target trusted execution environment (TEE) includes selecting a target TEE, generating an authentication that the TEE satisfies, associating the authentication with a computation to be executed in the authenticated TEE, and generating the computation using the associated authentication.

[0006] According to another embodiment of the present invention, a system includes a memory that stores computer instructions and a processor that is configured to execute the computer instructions to select a target TEE, generate an authentication that the TEE satisfies, associate the authentication with a computation to be performed within the authenticated TEE, and generate the computation using the associated authentication.

[0007] According to yet another embodiment of the present invention, a computer program product comprises a computer-readable storage medium having program instructions embodied thereon, the program instructions being readable and executable by a computer to cause the computer to perform a method including selecting a target TEE, generating an authentication that the TEE satisfies, associating the authentication with a computation to be performed within the authenticated TEE, and generating the computation using the associated authentication.

[0008] There has thus been outlined, rather broadly, certain embodiments of the invention in order that the detailed description thereof herein may be better understood, and in order that the present contribution to the art may be better appreciated. There are, of course, additional embodiments of the invention that will be described hereinafter which will form the subject matter of the claims appended hereto.

[0009] It is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The invention is capable of embodiments other than those described and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed in the specification and abstract is for the purpose of description and should not be regarded as limiting.

[0010] As such, those skilled in the art will appreciate that the conception on which this disclosure is based may readily be utilized as a basis for the designing of other structures, methods, and systems for carrying out the several purposes of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the present invention.

[0011] Exemplary aspects of the present invention will be better understood from the following detailed description of exemplary embodiments thereof, taken in conjunction with the drawings, in which: [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 1 is a diagram illustrating an example of a TEE (Trusted Execution Environment) when used in the present invention. [Figure 2A] FIG. 1 is an exemplary flow diagram of an embodiment of the present invention. [Figure 2B] FIG. 1 is an exemplary flow diagram of an embodiment of the present invention. [Figure 3] FIG. 10 illustrates the keep your own key flow for an alternative security model of an embodiment of the present invention in a cloud infrastructure. [Figure 4] FIG. 1 illustrates a flow diagram of verifying a target system (i.e., a system of a protected execution facility (PEF)) for a keep your own key model in an embodiment of the present invention in a cloud infrastructure. [Figure 5] FIG. 2 illustrates a method of provisioning in an embodiment of the present invention. [Figure 6] This is the layout of the ESM (enter secure mode) operand. [Figure 7A] FIG. 10 is a diagram showing values ​​extended to PCR6 (Platform Configuration Register 6) for verifying the hardware configuration in an embodiment of the present invention. [Figure 7B] FIG. 1 illustrates verification of computation in an embodiment of the present invention. [Figure 8] FIG. 1 illustrates an exemplary protected execution facility (PEF) according to an embodiment of the present invention. [Figure 9A] FIG. 10 illustrates an alternative security model utilizing SM for an embodiment of the present invention in a cloud infrastructure. [Figure 9B] FIG. 10 illustrates a flow diagram of the validation of a target system (i.e., a system of a protected execution facility (PEF)) for an alternative model utilizing SM in a cloud infrastructure embodiment of the present invention. [Figure 10A] FIG. 1 illustrates an alternative security model utilizing SM to provision TEE in AMD (ADVANCED MICRO DEVICES) processors in an embodiment of the present invention in a cloud infrastructure. [Figure 10B]FIG. 10 illustrates a flow diagram for verification of a target system (i.e., a protected execution facility (PEF) system) with respect to a TEE in an AMD (ADVANCED MICRO DEVICES) processor for an alternative model utilizing SM in an embodiment of the present invention in a cloud infrastructure. [Figure 11] FIG. 1 illustrates an exemplary hardware / information handling system for incorporating an exemplary embodiment of the present invention. [Figure 12] 1 illustrates a signal-bearing storage medium for storing machine-readable instructions of a program implementing a method according to an exemplary embodiment of the present invention. [Figure 13] FIG. 1 illustrates a cloud computing node according to an exemplary embodiment of the present invention. [Figure 14] FIG. 1 illustrates a cloud computing environment in accordance with an exemplary embodiment of the present invention. [Figure 15] FIG. 2 illustrates an abstraction model layer according to an example embodiment of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0013] The present invention will now be described with reference to the drawings, in which like reference numerals refer to like parts throughout. It is emphasized that, according to common practice, the various features of the drawings are not necessarily drawn to scale. Conversely, dimensions of various features may be arbitrarily increased or decreased for clarity. Example embodiments are provided below for purposes of explanation and are not intended to limit the scope of the claims. It should further be noted that any steps may be performed in different orders, combinations, or simultaneously. Additionally, any structures and embodiments shown may be modified or combined.

[0014] As mentioned previously, a major obstacle to cloud adoption is security. Cloud vendors have access to all information used within running containers or VMs (Virtual Machines). In response to this issue, various CPU (Central Processing Unit) vendors are modifying their architectures to allow for the creation and execution of private computations. These architectural modifications generally fall under the category of Trusted Execution Environments (TEEs). This invention also supports TEEs that are part of the cloud node or infrastructure but are not embedded in any particular CPU architecture.

[0015] Processor vendors offer a means for cloud providers to address the trust gap with the creation of trusted execution environments (TEEs), which provide hardware support for secure execution. A TEE partitions a processor or process into secure and non-secure areas. TEEs can be classified as either coarse-grained or fine-grained based on their "granularity." Coarse-grained TEEs function at the VM (virtual machine) or processor level, for example, while fine-grained TEEs protect only a process or a single thread of execution. Examples of coarse-grained TEEs include IBM® Secure Service Containers, ARM® (Advanced RISC (Reduced Instruction Set Computer) Machines) TrustZone® (which some do not consider a TEE), IBM® Protected Execution Facility (PEF), and AMD® Secure Encrypted Virtualization (SEV). Intel® Software Guard Extension (SGX) is a fine-grained TEE. Intel has expressed its intention to provide coarse-grained support. The TEE is entirely trusted due to the hardware-enforced requirements it places on code running within the secure partition and the user's ability to verify that the hardware is correct.

[0016] Most TEEs also offer some form of attestation. The absence of attestation and several other characteristics may rule out the current ARM TrustZone™ as a TEE. However, ARM processors can be used with external TPMs, which can provide some form of attestation. The manner and point at which attestation occurs varies. Attestation allows a remote party to ensure that attributes of the TEE, including what software is currently running within the TEE, are verified, and / or that the TEE's underlying firmware / software is verified. Attestation allows TEE users to verify important characteristics of the environment in which their code or secrets will be executed. TEEs are designed under the assumption that an adversary has physical possession, control, or access to the system / device / PC containing the processor. Their purpose is to enable confidential or secure computation in the presence of hostile access or control. The architectural changes introduced by a TEE provide defense against hostile access.

[0017] Even with these capabilities, leveraging TEEs to provide confidential computing remains challenging, as much cloud infrastructure assumes that the provider can be trusted.

[0018] Among other features, the present invention identifies a set of protocols and components that, when enabled and utilized in a cloud infrastructure, allow customers of the cloud infrastructure to use the infrastructure without sharing any of their secrets with the cloud provider. The present invention provides a set of protocols that allow users to leverage a Protected Execution Facility or other coarse-grained TEE without having to trust the cloud provider.

[0019] The present invention is illustrated using the Protected Execution Facility (PEF) TEE. PEF supports secure computations called Secure Virtual Machines (SVMs). All SVMs start execution as normal VMs, and during their initialization they perform an ESM (Transition to Secure Mode) ULTRAVISOR call requesting a transition from a normal virtual machine to a secure virtual machine. PEF requires a properly configured platform to have a TPM and be running with secure and trusted boot enabled.

[0020] As used herein, TPM refers to hardware used to hold measurements related to an attestation function. The attestation function may be embedded in the processor or implemented externally to the processor architecture. One refers to TPM PCRs, which represent some trusted mechanism for recording measurements.

[0021] The present invention leverages Trusted Platform Module (TPM) and TEE hardware deployed in cloud infrastructure. There are two models for leveraging TEE in cloud infrastructure: Bring Your Own Key (BYOK) and Keep Your Own Key (KYOK). BYOK requires a key vault under the control of the cloud user, such as a security module (SM) 866 in the cloud infrastructure, to avoid exposing the user's key to the cloud provider. Examples of security modules 866 include hardware security modules (HSMs) such as the IBM 4769 Cryptographic Coprocessor™, IBM Hyper Protect™, IBM Z Secure Service Container™, and IBM Z Secure Execution™, TEEs, or even TPMs. Sensitive information can be stored in the customer-controlled key vault. KYOK requires the cloud to provide detailed information about its infrastructure to the cloud user.

[0022] Cloud computing is an important aspect of enterprise infrastructure. Cloud infrastructure can be private, public, or hybrid. As mentioned earlier, one of the main challenges of hybrid and public clouds is for enterprises to extend their trust boundaries to the cloud provider and its personnel. While the cloud has grown dramatically, one of its major inhibitors is trust. In most cloud infrastructures, it is assumed from the outset that the cloud provider and its staff can be trusted.

[0023] FIG. 1 illustrates an example of a TEE utilized in the present invention. A TEE can be implemented in several ways, including as a modification of a CPU architecture, as an external component plugged into a peripheral interface, or as an entirely separate processor with appropriate interfaces and isolation hardware. In this embodiment, the TEE is described as a single system. However, the present invention also works when the TEE represents a suitably configured set of systems. The use of a TEE refers to one or more suitably configured systems. Within the software section 130 of system 100, there is a TEE 102, which includes hardware 120 and software 130. A trusted application is software that runs within the TEE. A TEE API 112, often implemented in firmware and / or hardware, provides an interface to software running within the TEE and to software outside the TEE that may wish to be secured by running within the TEE. Processor B 114 in trusted hardware is the trusted portion of the processor on which the trusted application and the TEE API execute. This may be an entirely separate processor, or it may refer to the trusted state of a single processor. The memory 116 within the TEE is trusted, and trusted software 104 resides in trusted memory 116 within the TEE 102. The TEE also includes an attestation function 122. In a preferred embodiment, the attestation function is provided by a TPM, although any hardware used to securely store measurements of firmware and / or software may provide the attestation function.

[0024] The trusted software within the TEE may include an entire operating system that is separate from the untrusted OS 108 outside the TEE 102. When the TEE is fine-grained, the OS within the TEE is often called a shim.

[0025] Outside the TEE resides the operating system 108 and applications 106, as well as memory 116 and processing functionality 110. None of these components are implicitly trusted by trusted software 104. The interface between the two must be carefully implemented so as not to sacrifice reliability.

[0026] FIG. 2A illustrates an exemplary flow diagram for provisioning a computation within a TEE according to an embodiment of the present invention. Those skilled in the art will recognize that authentication preparation for executing a computation within a TEE should occur in a trusted environment, but can occur anywhere. Provisioning a computation within a TEE begins with selecting a target TEE 204. Selecting a target TEE requires selecting a system that contains a TEE capable of executing secure computations. FIGS. 3, 4, 9A, 9B, 10A, and 10B illustrate examples of how a target TEE is selected and which attributes can be verified. In a preferred embodiment, the expected attributes of the TEE are expected to be known prior to selection. However, those skilled in the art will recognize that the expected attributes may also be functions of the selected TEE. For example, if a computation is being provisioned that can run on multiple architectures, the required attributes will likely depend on the target architecture. Authentication 206 constrains the computation to a specific TEE or to a set of TEEs that meet certain criteria. In either case, the particular TEE and / or the criteria used to verify the TEE must be known before generating a certificate. Selecting the target TEE and identifying the criteria are handled in step 204. Those skilled in the art will recognize that these may be two separate steps.

[0027] Generating a certificate is step 206. A certificate generally constrains a set of authorized TEEs to perform secure computations. In a preferred embodiment, the certificate is a protected symmetric seed, as shown in Figure 6. In a preferred embodiment, each TEE has a key pair. A preferred protection mechanism is to encrypt the seed with a public key associated with the target TEE. Only authorized TEEs have access to the private key. The private key may be locked in the TPM or some other hardware protection mechanism. The TPM specification defines encryption with the public key as the sealing process, the result of the sealing as the sealed data, and decryption of the sealed data with the private key as the unsealing process. A certificate may include an identifier indicating which TEE the certificate pertains to. If the identifier is present, the TEE validates the certificate.

[0028] In a preferred embodiment, a TPM is used to securely store the private key. In a preferred embodiment, the private key is locked to the TPM and cannot be duplicated. Alternatively, the key can be locked to the TPM and duplicated only by password. However, those skilled in the art will recognize that in order to provision multiple machines with a single secret, passwords must be managed very securely. Those skilled in the art will recognize that the private key can also be stored in some other location protected by a hardware root of trust. When a TPM is used, the policy associated with the ability to access the private key and unseal the symmetric key can constrain the set of systems or configurations of systems that are authenticated to perform secure computations. For example, in a preferred embodiment, the ability to access the public key can require that the PCRs match certain values, such as those illustrated in FIG. 7A. Example constraints are described in FIG. 7A. Those skilled in the art will recognize that authentication can be arbitrarily complex. The authentication can be embedded in the sealed data or can be separate metadata.

[0029] Associate authentication with the computation 208. The steps for associating authentication with the computation are illustrated in FIG.

[0030] The computation is generated 210 using the associated certificate. The certificate containing the sealed data is dynamically inserted into the computation. In a preferred embodiment, the certificate is inserted into a pre-prepared computation or during the preparation of the computation.

[0031] Finally, the target TEE is provisioned with a computation 212. An example of a computation provisioned by the present invention is a secure VM. Examples of provisioning a secure VM into a TEE are given in Figures 3 and 4, 9A and 9B, and 10A and 10B.

[0032] In some TEE models, the user of the TEE must explicitly verify that the TEE is valid before inserting secrets. In such models, the TEE is brought up on the target system but does not decrypt until the attestation is verified. After the target system is secured, it takes or has a measurement of the state of the TEE. It sends the measurement to the user. If the user is satisfied with the measurement, it authorizes the insertion of a secret that allows the TEE to decrypt the computation. This secret is effectively an authentication; without it, no computation would be performed within this type of TEE. This association is implicit by running the TEE within the target system. The generator is the user computing an acceptable value.

[0033] FIG. 2B shows an exemplary flow diagram for provisioning a computation within a TEE according to an embodiment of the present invention. Computation preparation for a TEE should occur within a trusted environment. Those skilled in the art will recognize that while preparation of authentication for running a computation within a TEE should occur within a trusted environment, it can occur anywhere. Provisioning begins at 230. The first step is validating the TEE at 232. Examples of validating the target TEE are shown in FIGS. 4, 10A, and 10B. If the TEE cannot be validated, provisioning terminates at 246. Next, computation integrity information must be generated at 234. An example of computation integrity information is integrity information 677 in FIG. 6. This description assumes that the TEE on which the computation is executed verifies the integrity of the computation and fails execution if there is a problem. Alternatively, the TEE may independently compute the integrity of the computation and return that information to its owner via some secure mechanism; if incorrect, TEE execution will be terminated. It is useful to note that in implementations where the owner must verify the integrity of a running TEE, sensitive information should not be included in the TEE until it has been verified. Either approach requires integrity information. Next, sealed data is generated 236. The sealed data specifies whether the TEE is authorized to perform a computation. Those skilled in the art will recognize that sealed data is a term specific to the TPM. Once data is sealed by the TPM, the sealed data is associated with a policy that must be satisfied to access the sealed data. The computation information, sealed data, and integrity information are sent to the TEE 238. In a preferred embodiment, the policy associated with the sealed data is used to verify that the TEE is authorized. This policy is enforced by the TPM.The TEE verifies that it is authorized to perform the computation, 240. If the TEE is not authorized, execution terminates, 246. The integrity of the computation is verified, 242. This may be achieved by the TEE independently computing integrity information, which it can then verify matches the integrity information it received, or it may send its computation results back to the initiator over some secure channel and wait for them to be verified. In either case, if the integrity of the computation is not verified, execution terminates, 246. Otherwise, the computation is performed, 244.

[0034] 3 and 4 show the flow of an alternative form of the Protected Execution Facility (PEF) in which the Security Module (SM) 980 is not present.

[0035] Specifically, FIG. 3 illustrates a Keep Your Own Key (KYOK) flow for the security model of an embodiment of the present invention.

[0036] In the case of KYOK, the customer accepts responsibility for running the enrollment protocol, or the enrollment protocol must be run by someone trusted by the customer. In this model, the customer controls the value of Platform Configuration Register 6 (PCR6), which they trust.

[0037] System 200 is divided into trusted infrastructure 350 (highlighted) and untrusted cloud infrastructure 361 (the remaining structure not highlighted). Trusted infrastructure 350 (highlighted) is shown as customer 302 and tooling module 304.

[0038] This flow assumes that a VM 416 (not shown), which can be an SVM, with an image ID (identification) of Image-ID has been preloaded in the cloud infrastructure store. To provision a secure VM 416, the customer module (or customer network) 302 requests that the tooling 304 launch the VM Image_ID 318. The tooling module 304 requests secure provisioning 320 from the cloud front end 306. The cloud front end 306 confirms paid services 322 with the tooling module 304. The tooling module 304 requests that the zone orchestrator 310 create an instance 324 of Image-ID.

[0039] The system 200 then selects a target machine 325 as follows: The zone orchestrator 310 selects a target machine, represented by Mach-Ind, and requests a platform certificate and storage key 326 from the target system with TPM 312. Those skilled in the art will recognize that existing cloud infrastructures know how to utilize a list of requirements to select an available machine from their infrastructure. Any technique for selecting such a machine is acceptable. Those skilled in the art will recognize that the list of attributes to select should be augmented with attributes associated with the target TEE. Furthermore, those skilled in the art will recognize that Mach-Ind can be an IP address or any other information that can be used to identify a machine within the provider's infrastructure. The target system with TPM 312 then returns the platform certificate and storage key 328 to the zone orchestrator 310. The zone orchestrator 310 then requests the client tooling module 304 to enroll the target machine via enroll this machine(Mach-Ind, platform certificate, storage key) 330.

[0040] The client tooling module 304 then validates 332 the target system.

[0041] If the target system is verified, the client tooling 304 generates sealed data 334. Although not shown, if the target system verification 332 fails, activation stops. The tooling module 304 sends an authentication execution (Mach-ind., sealed data) 436 to the zone orchestrator module 310.

[0042] The zone orchestrator module 310 requests an Image-ID 338 from the cloud object store 308. The cloud object store 308 returns 340 the image associated with the Image-ID back to the zone orchestrator module 310. The zone orchestrator 310 then inserts 342 the sealed data into the image returned from the cloud object store 308. The zone orchestrator then passes the image with the inserted sealed data to the target system 312 with a TPM and instructs the target system to execute 344 the image.

[0043] 4 shows details of the target system validation (PEF) 332 of an embodiment of the present invention. The trusted infrastructure 350 is shown as a customer module (or customer network) 302 and a tooling module 304. An untrusted cloud infrastructure 361 is also shown.

[0044] The target system is validated in step 330 in response to the cloud front end 306 requesting the tooling module 304 to enroll this machine. Validating the TEE requires validating the platform certificate and verifying that the storage key characteristics are as expected. The customer tooling 304 then validates the platform certificate and checks the storage and key characteristics 460. Although not shown, if the platform certificate or storage key characteristics are not valid, the target system validation returns a failure. This failure response can cause the tooling 304 to request that the zone orchestrator provision a different target system. Continuing with FIG. 4, if the platform certificate and storage key are valid, the customer tooling 304 then generates a challenge and creates credentials 462. The challenge consists of credentials, which are a binary blob that only the TPM on the Mach-ind can open (used to obtain a challenge for the valid system). The tooling module 304 sends the challenge 464 to the cloud front end 306. The cloud front end 306 forwards the challenge 466 to the zone orchestrator 310. The zone orchestrator 310 forwards the challenge to the target system 312 with a TPM via an activate credential 468. Although not shown, the target system 312 issues an activate credential to its TPM and receives a response. The target system 312 with a TPM sends a response to the challenge 470 to the zone orchestrator 310. The zone orchestrator forwards the response to the challenge 472 to the cloud front end 306. The cloud front end 306 then forwards the response to the challenge 474 to the customer tooling module 304. The tooling module 304 then checks the challenge response and indicates success or failure 476.

[0045] FIG. 5 illustrates a method for provisioning a machine in an embodiment of the present invention.

[0046] One embodiment of the present invention utilizes a non-volatile (NV) location in the TPM to store passwords. Prior to placing a machine in the infrastructure or as part of provisioning a machine into a cloud infrastructure, an NV location of NV_Location_X must be assigned (provisioned) with the appropriate policy 540.

[0047] The system 500 generates a storage key 544 using a policy that requires the use of a password and that it matches the password in NV_Location_X. By definition, a storage key is a parent; children of a parent key are not necessarily keys. A password is required 544 to use the storage key. Preferred attributes of the storage key are that it should be locked to the TPM, the key algorithm can be RSA2048 (a Rivest-Shamir-Adleman cryptosystem with 2,048 bits), the key length is 2048, and the authentication is a pointer to NV_Location_X and the platform hierarchy. Policy 544 also states that PCR6 must match to use the storage key. A new password is assigned and provided to the ULTRAVISOR at each boot. In a preferred embodiment, the password is regenerated at each boot.

[0048] The third step of provisioning 542 is to generate a storage key using a pre-computed policy that states that the password required to use the storage key is in NV_Location_X. In step 544, the policy for the storage key requires that a password be used and that it matches the password in location NV_Location_X.

[0049] Maintaining isolation and security of computation and associated data is the sole purpose of ULTRAVISOR. System management remains the responsibility of the hypervisor. The hypervisor uses Ultra-Call to continue managing security-sensitive functions. When necessary, ULTRAVISOR ensures that actions requested by the hypervisor do not affect the security of any running SVMs (Secure Virtual Machines).

[0050] Thus, as noted, in a preferred implementation, in addition to other attributes, the storage key is fixed to the TPM, the key algorithm is RSA, and the key length is 2048. The ability to change the password is tied to TPM platform authentication, which must be completed early in the firmware boot process, before any OS is loaded onto the platform. The firmware in the machine must have the ability to assign a new random password each time the machine is booted and pass that password to ULTRAVISOR or equivalent firmware.

[0051] Figure 6 shows the layout of an ESM operand 691. The ESM operand 691 can be divided into two large areas: sensitive information 685 and payload 689. The sensitive area contains sealed data. Each sealed data allows a properly configured system to access the information in the ESM operand's payload area 689. Sealed data 673 provides access to machine A, and sealed data 675 provides access to machine B. The unsealed data is a seed used to generate symmetric and HMAC keys. Everything in the payload area 689, except for the HMAC, is encrypted using the symmetric key generated from the seed. The first part of the payload area 689 is integrity information 677. This is information required by PEF to verify the integrity of the computation. It consists of hashes of the kernel, kernel command line, initramfs (initial RAM (random access memory)), and RTAS area. In a preferred embodiment, the integrity information 677 is encrypted as specified. In an alternative embodiment, the integrity information is not encrypted. Because the PEF verifies the integrity of a computation without contacting the creator, this information is generated when the secure computation is created and placed in an ESM operand. (For technologies that involve contacting the owner / user of the computation to verify its integrity, the information must be computed by the TEE.) The remaining information in the payload area 689 is secrets 687. These are represented as CD1 through CDn, where CD stands for "Customer data." Integrity in the preferred embodiment protects the VM's kernel, initramfs, kernel command line, and RTAS 677. The boot disk should be encrypted. In a preferred embodiment, the first block of customer data 679 contains a passphrase protecting the root disk, encrypted using a symmetric key.After the encrypted pass phrase are zero or more blocks of customer data, each of which is encrypted using a symmetric key generated from the seed.

[0052] FIG. 7A illustrates values ​​expanded into PCR6 786 for hardware configuration validation in an embodiment of the present invention. A preferred embodiment utilizes secure and trusted boot to ensure that the hardware and firmware configuration is valid. The values ​​represented here are a preferred set of values. Alternative implementations may use different values. Those skilled in the art will appreciate that PCR6 786 is representative of PCRs used to hold values, and that whatever PCR is used must also appear in the sealed data policy (not shown in FIG. 7A) for validation to occur. It is important to note that this embodiment only identifies the actions of the mutable code and / or immutable code required for the present invention. The mutable boot loader 776 and immutable code 772 described herein execute within a self-boot engine (SBE) and perform many actions not described herein. Execution terminates whenever signature verification fails and secure and trusted boot is enabled. The immutable boot loader 772 is the first code executed when the system is powered on. The immutable boot loader 772 extends a hardware key hash 788 and a secure boot jumper 790 into PCR6 786. The hardware key hash 788 is a hash of the cryptographic key being used to verify the signature on the cryptographic key used to verify the signature on the firmware. The secure boot jumper 790 identifies whether secure boot is enabled or disabled. Before passing control to the mutable boot loader 776, the immutable code 772 loads and verifies the signature of the mutable boot loader 776. If the signature is verified, the immutable code 772 extends PCR6 786 with the hash of the SB verification code 774, which is part of the mutable boot loader 776 that verifies the signatures of other code. It then passes control to the mutable boot loader 776. The mutable boot loader 776 verifies the host boot loader 778.The host boot loader 778 validates Host Boot Init. (initialization) 780. Host Boot Init 780 validates Host Boot Ext. (extensions) 782. Host Boot Ext. 782 extends Separator 792 into PCR6. Host Boot Ext. 782 validates OPAL 784. OPAL 784 extends PEF Enable bit 794 into PCR6 786. Figure 7A illustrates how the value of PCR6 786 will be generated when properly configured hardware is booted. In a preferred embodiment, the policy associated with the sealed data requires PCR6 to match this value. Other values ​​can be extended into PCR6 (or another PCR) as desired, whatever implementation requires to properly validate its configuration. The authentication policy required by this invention can be generated by software using a virtual TPM, a real TPM, extending values ​​into physical or virtual PCRs, or reimplementing the operations performed by the TPM (not recommended). The policy specifies the hardware key hash 788, secure boot jumper 790, hash of SB verification code 774, separator 792 used by firmware, and state of PEF enabled bit 794 required to authenticate the TEE to perform secure computation.

[0053] FIG. 7B illustrates checking 240 authorization requirements and verifying 242 the integrity of computation information in an embodiment of the invention using PEF. As previously described, a secure computation begins as a normal VM. It makes an ESM ULTRAVISOR call to transition to a secure VM running within the PEF TEE, at which point verification begins 750. In a preferred embodiment, the ESM ULTRAVISOR call requires the ESM operand 691 shown in FIG. 6. If the ESM operand is not present, the ESM ULTRAVISOR call fails. The TEE checks 240 to verify that it is authorized to run the secure VM. If it is not authorized, execution terminates 766. If authorized, the TEE checks 754 to verify that it is a valid TEE; a valid TEE is one that meets the sealed data policy specified by the SVM creator. In the case of PEF, this check is performed by the TPM when ULTRAVISOR requests the TPM to extract a seed from the sealed data. If the TEE does not meet these requirements, execution terminates 766. Because the TEE is authenticated and meets the requirements, it has access to the symmetric seed needed to generate the HMAC key and, if integrity is valid, the symmetric key. It then generates the HMAC key 756. It uses the HMAC key to verify that the encrypted information in the ESM operand has not been altered 758. If the encrypted information has been altered, execution terminates 766. Otherwise, a symmetric key is generated 760. This gives the TEE access to the information required to verify the integrity of the computation 242. If the computation has been altered, execution terminates 766. Otherwise, the VM completes the transition to the SVM and executes 764, thereby successfully terminating the transition 768, and the VM now becomes an SVM.

[0054] Provisioning FIG. 8 illustrates an exemplary protected execution facility (PEF) according to an embodiment of the present invention. The system 800 requests a secure virtual machine (SVM) execution (S0). The orchestrator module 852 then selects a target machine from among T0...Tn 864 (S1). The orchestrator module 852 then asks the security module (SM) 866 to verify one of the selected target machines, T0...Tn 864 (S2). In FIG. 5, the selected target is Tn 864. The SM 866 requests information (platform certificate, storage key structure, HW (hardware) key hash) from the selected target system 864 (S3). The SM 866 must verify that they are correct. To perform the verification, it must have the platform vendor's public key. Once it obtains the key, it can store it internally to facilitate the verification process. The SM 866 validates the machine using the public key of the vendor 860 (S3a) and contacts the vendor if it does not already have it. The SM device 866 sends the sealed data to the orchestrator module 852 (S4). The orchestrator module 852 retrieves a copy of the selected SVM 856 from the library 858 (S5). Note that in the PEF, all SVMs begin execution as VMs 854. As far as the library 858 is concerned, all images are VMs 854. For simplicity's sake, these VMs 854 that can become SVMs are labeled SVMs 856 in the library 858. Those skilled in the art will recognize that the library 858 can be implemented in a way that makes the difference clear or transparent. The orchestrator inserts the sealed data into the copy of the SVM. The orchestrator module 852 dispatches the copy of the SVM 856 to the target system 864 (S6). In the case of cloud infrastructure 870, the target system 864 is generally unknown at the time the SVM 856 is created.Cloud providers must be able to make changes to their infrastructure (e.g., performing routine maintenance, upgrades, etc.) without affecting existing SVMs 856. One of the key attributes of the PEF Enter Secure Module (ESM) operand that allows for easy incorporation into cloud infrastructure 870 is that the HMAC (Hashing for Message Authentication Code) does not cover the sealed data. This means that the sealed data does not need to be generated simultaneously with the rest of the ESM operand, but can be inserted into the ESM operand just before execution. In a preferred embodiment, placeholder sealed data may exist in the ESM operand, which will be overwritten by the sealed data for the selected machine. In an alternative embodiment, the image with the sealed data may be stored in the cloud object store 308. This would be useful in an alternative embodiment where the TEE represents a set of systems. The cloud object store 308 may also store metadata indicating whether sealed information already exists. If so, the VM can be dispatched directly to the TEE (set of machines). The ESM operand is a digital blob placed in a reserved section of the initramfs. It can also be placed in the ELF (executable and linkable format) section of a zImage (self-extracting compressed image) format file containing the kernel. All the information needed to verify the validity of the SVM is contained in the ESM operand.

[0055] One example deployment model involves dynamically generating sealed data using a security module (SM) 866 or equivalent functionality in the cloud provider's infrastructure. In this invention, the master secret is owned / controlled by the cloud customer, while the hardware is controlled / owned by the cloud provider. In this case, the cloud provider cannot extract information from the SM 866, and therefore, cloud customers can safely place secrets associated with their secure computations inside the SM 866. An example of an SM that can be owned by the cloud provider but controlled by the customer is the IBM 4769. The capabilities described in this invention do not currently exist in the 4769, but could be added. Because the SM 866 resides within the cloud provider's infrastructure, it is safe for the cloud provider to enable it to execute the necessary protocols to generate sealed data for the target machine. Details of the cloud infrastructure are not provided to the cloud customer. At this point, it is important to note that in PEF, all SVMs (Secure Virtual Machines) begin execution as NVMs (Normal Virtual Machines), and early in their execution they perform an ESM (Enter Secure Mode) ultra-call, which is a request to transition to an SVM. It is also important to note that from the cloud provider's perspective, the NVM image and the SVM image are the same. The cloud customer must inform the cloud provider that a particular image is intended for an SVM so that it can be handled appropriately. The deployment description assumes that the VM (Virtual Machine) image that will be transitioned to an SVM (Secure Virtual Machine) 856 has been pre-created, and that the associated symmetric seed and associated metadata are already present in SM 866. Finally, it is assumed that given the VM's identity, SM 866 will use the associated metadata to select the appropriate symmetric seed.

[0056] With further reference to FIG. 8 , the overall process for executing SVM 856 is shown. A cloud user requests that a running instance of a pre-created SVM 856 be created. Cloud infrastructure 870 selects a target machine 864 and extracts a platform certificate and storage key from the target. The infrastructure forwards the target machine 864, platform certificate, and storage key to an SM 866 under the customer's control and requests enrollment of the target machine 864 with the SVM. In an alternative embodiment, the cloud infrastructure forwards only the target machine and requests an SM to enroll the target machine. The SM extracts the platform certificate and storage key from the target machine itself and then proceeds with the enrollment process. If enrollment is successful, SM 866 will return sealed data about the target machine 866 to cloud infrastructure 870. The infrastructure retrieves the image copy 856 from the library 858, uses tooling to insert the sealed data into the ESM operand of the SVM 856, and provisions the image copy 856 containing the inserted sealed data to the target machine 864. Because the newly inserted sealed data pertains to the target machine 864, barring other issues, the VM will be successfully migrated to the SVM 856. This model assumes that the customer will have one seed per SVM 856 and that this seed will be valid for all target systems 866. Other models are possible, and in particular, this embodiment is written as if the selected target 864 is a single machine. However, one skilled in the art will recognize that the target may be either a single machine 864 or a set of machines 868, depending on how the infrastructure is provisioned. Sealed data can be inserted dynamically into a computation.

[0057] The enrollment protocol includes the following: The SM 866, or an equivalent function, must execute the enrollment protocol. The enrollment protocol requires the cloud infrastructure 870 to pass the SM 866 the target machine's machine indicator (Internet Protocol (IP) address), platform certificate, SVM indicator, and storage key. In an alternative embodiment, the cloud provider passes only the machine indicator to the SM, and the SM extracts the platform certificate and storage key itself. In either embodiment, the SM 866 will validate the platform certificate and check that the storage key characteristics are correct. If the platform certificate and storage key pass the checks, the SM 866 will generate a random challenge and create a credential. It will then send the activation credential to the target machine 864 to be executed on its TPM 862. The target machine 864 will return a challenge response. If the challenge response is valid, the SM 866 generates sealed data about the target machine 864 and returns it to the cloud infrastructure 870 of the system 800.

[0058] The enrollment protocol only needs to be run once per target. Therefore, if SM866 maintains a database of enrolled machines, it can check to see if the current target machine is enrolled. If it is already enrolled, it can skip enrollment and generate the sealed data directly. Also, each hardware key hash only needs to be verified once. SM866 can maintain a database of verified hardware key hashes. Before system 800 runs the protocol against vendor 860 to verify the hardware key hash, system 800 can check to see if the hash from target machine 864 has already been verified. This is not a significant optimization for PEF because the hardware key hash is verified when the SVM is created, not once per run. When a key hash becomes invalid, it must be purged from SM866. When a machine is deprovisioned from the cloud infrastructure 870 of the present system 800, the SM 866 must be notified that the machine is no longer a valid target so that the SM 866 can empty its internal database. Finally, to ensure that the deprovisioned machine cannot be used to extract secrets from an already authenticated SVM 866, the primary seed in the TPM 862 must also be emptied when the machine is deprovisioned.

[0059] 9 and 10 show a Protected Execution Facility (PEF) that utilizes a SM to verify a target system.

[0060] The first technique, shown in Figures 3 and 4, requires the infrastructure provider to reveal details such as the server's Internet Protocol (IP) address to the user in order for the user to verify that the intended target machine is acceptable and to configure the computation to run on the intended target. The required APIs reduce the transparency of the cloud provider's infrastructure to the cloud user.

[0061] Some cloud providers may not want to expose details of their infrastructure because it would make transparently managing their infrastructure significantly more complex. The present invention achieves the same goal of provisioning secure computation to a TEE without exposing infrastructure details to cloud customers by including a properly configured SM. The SM must be under the control of the customer utilizing the TEE. The SM must be configured to execute a pre-written validation flow, such as those shown in Figures 9 and 10. The customer must securely insert their secret into the SM.

[0062] 9A, 9B, 10A, and 10B illustrate how the present invention works within a PEF TEE. PEF and similar TEEs are designed so that the TEE attests to the integrity of a computation without requiring separate verification from the user / owner of the TEE. 10A and 10B illustrate how the present invention works with a TEE, such as AMD's SEV, that requires the owner / user to explicitly authenticate a secure computation after it has been loaded into a valid TEE. In either case, both the TEE and the computation are attested / verified. 9A, 9B, 10A, and 10B do not assume that the customer has pre-loaded a VM image. A customer could pre-load a VM image, My-Image482, which would imply that the customer has prior knowledge of Image-ID483.

[0063] 9A illustrates an alternative implementation of a Protected Execution Facility (PEF) utilizing a security module (SM) in accordance with an embodiment of the present invention. This flow does not assume that a potential secure VM with an image identity of Image-ID has been pre-loaded into the cloud object store 308. The trusted infrastructure 350 is the customer module 302, the tooling module 304, and the security module (SM) 980. In this alternative embodiment, the SM 980 is trusted despite being part of the untrusted cloud infrastructure 361.

[0064] To provision a secure VM, the customer module 302 requests that its trusted tooling 304 start the SVM My-Image 318. The tooling module 304 requests 320 secure provisioning from the cloud front end 306. The cloud front end 306 confirms 322 paid services with the tooling module 304.

[0065] Next, the tooling module 304 uploads 982 the VM My-Image to the cloud object store 308, which can then migrate it to an SVM. The cloud object store 308 then sends the Image-ID 983 back to the tooling module 304. The tooling module 304 sends a command to the SM 980 for secure insertion 984 of the seed metadata into the SM, which will be indexed by the Image-ID. Those skilled in the art will recognize that the image could have been pre-loaded, in which case the Image-ID would have been known. The tooling module 304 requests 324 that the zone orchestrator 310 create an instance 324 of the Image-ID.

[0066] The system 300 then selects a target machine 325 as follows: The zone orchestrator 310 selects 326 the target machine requests a platform certificate and storage key from the selected target system with a TPM 312. The target system with a TPM 312 then returns 328 the platform certificate and storage key to the zone orchestrator 310.

[0067] The zone orchestrator 310 then requests that the SM 980 enroll 330 this machine (Machine-indic, platform certificate, and storage key). The SM 980 is a trusted infrastructure 350 by the customer module 302.

[0068] The SM then performs a verification 933 of the target system's Mach-ind against the target system 312 with the TPM. If the verification fails, the activation terminates. If the verification is successful, the SM 980 returns (Machine-ind., sealed data) 336 to the zone orchestrator 310 authorizing the execution.

[0069] The zone orchestrator module 310 then requests the Image-ID 338 from the cloud object store 308. The cloud object store 308 returns the image 340 associated with the Image-ID to the zone orchestrator 310. The zone orchestrator 310 then inserts sealed data 342 into the image returned by the cloud object store 308. The zone orchestrator 310 then sends the image with the inserted sensitive data, along with instructions to execute 344 the image, to the target system 312 with the selected machine's TPM.

[0070] 9B illustrates the required flow between target system 312 with a TPM and SM 980 to complete target system Mach-Ind verification 933 in an embodiment of the present invention. As highlighted, trusted infrastructure 350 includes SM 980. Within untrusted cloud infrastructure 361, zone orchestrator 310 and target system 312 with a TPM are external to trusted infrastructure 350.

[0071] The zone orchestrator 310 sends a request to the SM 980 to enroll this machine (Machine-indic, platform certificate, and storage key) 330.

[0072] The SM 980 validates the platform certificate and checks the storage key characteristics 460. The SM Hyper Protect 980 generates a challenge and creates authentication information 462, which creates a binary blob called a Credential that can only be from the TPM validated in 460. The SM 980 sends an Activate Credential 468 to the target system with a TPM 312. The target system with a TPM 312 then returns a challenge response 470 to the SM 980. The SM 980 checks the challenge response 476. If the challenge response is incorrect, the activation terminates and the process returns a failure indication. If the challenge response is correct, the SM 980 generates sealed data 334 using the policy passed as metadata along with the seed. The SM 980 returns an Authorize Execution (machine-in, sealed data) 336 to the zone orchestrator 310.

[0073] FIG. 10A illustrates an alternative security model for an embodiment of the present invention in a cloud infrastructure, utilizing an SM to provision a TEE on an AMD processor. In FIG. 9B, a customer module 302 has its own trusted infrastructure 350 and uses a cloud provider 361. Within the cloud provider, the customer uses a security module (SM) 980 over which it has control and is trusted 350. The rest of the cloud provider's 361 infrastructure is untrusted. The customer module 302 sends a request to their trusted tooling 304 to start the SVM My-Image. The tooling 304 requests secure provisioning 320 from the cloud front end 306. The cloud front end 306 confirms the paid service 322. The customer's tooling uploads 982 its image, My-Image, to the cloud object store. The cloud object store 308 returns 383 an image identifier, Image-ID, for the stored image to the customer tooling 304. The customer tooling 304 securely inserts 984 a seed, also referred to as detailed information or sensitive information, indexed by the Image-ID into the security module (SM) 980. This insertion may include additional metadata to be associated with the Image-ID. The customer tooling 304 then requests 324 that the zone orchestrator 310 create an instance of the Image-ID. The zone orchestrator 310 selects 1065 a target machine 312, Mach-Ind. The zone orchestrator 310 then requests 1063 that the security module 380 validate the target machine 312, Mach-Ind. The security module validates 1025 the target machine.

[0074] FIG. 10B illustrates the flow of target system verification (PEF) for the TEE in an AMD processor for an alternative model using an SM for an embodiment of the present invention in a cloud infrastructure. FIG. 10B provides details of the target machine verification 1025 request from FIG. 10A. The request to verify Mach-Ind 1063 is received by the security module (SM) 980 from the zone orchestrator 310. Because the target system 312 encompasses AMD processes for the TEE, FIG. 10B is expanded to include the PSP 1003 within the target system, which, if certified, can be trusted 350. It is important to note that the PSP is a subcomponent of the AMD processor, expanded in FIG. 10B for clarity of the flow. Another important point is that communication between the SM and PSP is secure and cannot be forged in either direction. This description is a general overview of the process. Further details are provided in AMD white papers and technical documentation available to those skilled in the art. The SM issues a validation request 1056 to the target system 312, which passes the request 1058 to the PSP 1003. In response to this request, the PSP 1003 generates signed data and returns it 1092 to the processor 312, which returns it 1011 to the SM 980. The SM 980 extracts the certificate from the response 1027 and requests validation 1094 from the AMD Certificate Authority 1054. The AMD Certificate Authority 1054 returns a validation response 1096. If the certificate is not validated, the activation (the request to run a secure VM within the TEE) is terminated. If the certificate is validated, the SM 980 requests the zone orchestrator 310 to load the VM image onto the target system 1029. The zone orchestrator 310 sends the VM image associated with the Imag-ID along with a load image request 1051 to the target system. The target system 312 loads the VM image into the TEE (not shown). The SM 980 issues a certification request 1057 to the target system 312 for the VM image Image-ID.The target system 312 issues an attestation request to the trusted PSP 1003. The PSP 1003 generates an attestation response and returns it 1059 to the system 312. The target system returns the attestation response 1099 to the SM 980. The SM verifies the attestation response against the hash of the VM 1055. If the verification fails, the activation ends. If the verification is successful, the SM 980 obtains the certificate (also called the decryption key) and issues an Insert Certificate 1091 to the target system 312. The target system passes the Insert Certificate 1097 to the PSP 1003. The PSP 1003 inserts the certificate into the TEE. The SM 980 issues a Boot System 1093 to the target system 312, which is successful because the secure computation is authenticated (the decryption key was successfully inserted).

[0075] Figures 11 through 15 illustrate alternative configurations of systems 100, 200, 300, 301, 500, and 800 that may be implemented. Different features shown in different figures of Figures 1 through 15 may be combined, modified, or interchanged between different examples.

[0076] FIG. 11 shows another hardware configuration of a system in which there is an information handling / computer system 1100 according to the present invention, preferably having at least one processor or central processing unit (CPU) 1110 capable of implementing the techniques of the present invention in the form of a software program for software intelligence as a service.

[0077] As already mentioned, the trusted execution environment 102 may be implemented in a local infrastructure such as that shown in FIG.

[0078] The CPU 1110 is interconnected via a system bus 1112 to a random access memory (RAM) 1114, a read-only memory (ROM) 1116, an input / output (I / O) adapter 1118 (for connecting peripheral devices such as a disk unit 1121 and a tape drive 1140 to the bus 1112), a user interface adapter 1122 (for connecting a keyboard 1124, a mouse 1126, speakers 1128, a microphone 1132, or other user interface devices, or a combination thereof, to the bus 1112), a communications adapter 1134 for connecting the information handling system to a data processing network, the Internet, an intranet, a personal area network (PAN), etc., and a display adapter 1136 for connecting the bus 1112 to a display device 1138 and / or a printer 1139 (e.g., a digital printer, etc.).

[0079] In addition to the hardware / software environments described above, different aspects of the present invention include computer-implemented methods for performing the above-described methods. By way of example, the methods may be implemented in the specific environments discussed above.

[0080] Such methods may be implemented, for example, by operating a computer, such as embodied by a digital data processing apparatus, to execute sequences of machine-readable instructions, which may reside in various types of signal-bearing media.

[0081] Thus, this aspect of the invention is directed to a programmed product including a signal-bearing storage medium tangibly embodying a program of machine-readable instructions executable by a digital data processor incorporating a CPU 1110 and the above-described hardware to perform the methods of the invention.

[0082] This signal-bearing storage medium may include, for example, RAM housed within CPU 1110, such as represented by fast-access storage.

[0083] Alternatively, the instructions may be contained in another signal-bearing storage medium 1200 that is directly or indirectly accessible by the CPU 1110, such as flash memory 1210 or optical storage diskette 1220 (FIG. 12).

[0084] The instructions may be stored on a variety of machine-readable data storage media, whether contained in flash memory 1210, optical disk 1220, computer / CPU 1110, or otherwise.

[0085] Thus, the present invention may be a system, a method, or a computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0086] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer 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), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures on which instructions are recorded, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as ephemeral signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted over wires.

[0087] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored on a computer-readable storage medium within the respective computing / processing device.

[0088] Computer-readable program instructions for carrying out the operations of the present invention may be either 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 code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk®, C++, and traditional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute 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 a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), can execute computer readable program instructions to personalize the electronic circuitry by utilizing state information of the computer readable program instructions to perform aspects of the present invention.

[0089] Aspects of the present 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 will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0090] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0091] These computer-readable program instructions may also be stored on a computer-readable storage medium such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture including instructions that implement aspects of the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams, and may be capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner.

[0092] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to create a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0093] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur in a different order than noted in the figures. For example, two blocks shown in succession may in fact be executed substantially in parallel, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It will also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.

[0094] Referring now to FIG. 13, a schematic diagram 1400 of an example cloud computing node is shown. Cloud computing node 1400 is merely one example of a suitable cloud computing node and is not intended to suggest any limitation as to the scope of use or functionality of the inventive embodiments described herein. In any event, cloud computing node 1400 may implement and / or perform any of the functionality described herein above. As previously mentioned, trusted execution environment 102 may be implemented in a cloud infrastructure such as FIG. 13 (and also FIGS. 14 and 15). Cloud computing node 1400 includes computer system / server 1412, which is capable of operating with numerous 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 computer system / server 1412 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the above systems or devices.

[0095] The computer system / server 1412 may be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. 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 1412 may also be practiced in a distributed cloud computing environment where tasks are performed by remote processing devices that are 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.

[0096] 13, computer system / server 1412 in cloud computing node 1400 is shown in the form of a general-purpose computing device. Components of computer system / server 1412 may include, but are not limited to, one or more processors or processing units 1416, a system memory 1428, and a bus 1418 that couples various system components, including the system memory 1428 to the processor 1416.

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

[0098] Computer system / server 1412 typically includes a variety of computer system-readable media, which can be any available media that can be accessed by computer system / server 1412 and includes both volatile and nonvolatile media, removable and non-removable media.

[0099] The system memory 1428 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 1430 and / or cache memory 1432. The computer system / server 1412 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, a storage system 1434 may be provided for reading from and writing to non-removable, non-volatile magnetic media (not shown, but typically referred to as a "hard drive"). Although not shown, a magnetic disk drive may be provided for reading from and writing to removable, non-volatile magnetic disks (e.g., "floppy disks"), and an optical disk drive may be provided for reading from and writing to removable, non-volatile optical disks, such as CD-ROMs, DVD-ROMs, or other optical media. In such an example, each may be connected to the bus 1418 by one or more data media interfaces. As further depicted and described below, memory 1428 may include at least one program product having a set (e.g., at least one) program module configured to perform the functions of embodiments of the present invention.

[0100] A program / utility 1440 having a set (at least one) program module 1442 may be stored in memory 1428, by way of example and not limitation, but also in an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may include an implementation of a networking environment. The program modules 1442 generally perform the functions or methodologies, or combinations thereof, of embodiments of the present invention as described herein.

[0101] The computer system / server 1412 may also communicate with one or more external devices 1414, such as a keyboard, pointing device, display 1424, etc., one or more devices that enable a user to interact with the computer system / server 1412, or any device (e.g., a network card, modem, etc.) that enables the computer system / server 1412 to communicate with one or more other computing devices, or a combination thereof. Such communication may occur via an input / output (I / O) interface 1422. Furthermore, the computer system / server 1412 may 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 a network adapter 1420. As depicted, the network adapter 1420 communicates with the other components of the computer system / server 1412 via a bus 1418. Although not shown, it should be understood that other hardware and / or software components may be used in combination with computer system / server 1412. 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, etc.

[0102] Referring now to FIG. 14 , an exemplary cloud computing environment 1550 is depicted. As shown, the cloud computing environment 1550 includes one or more cloud computing nodes 1400 with which local computing devices used by cloud users, such as a personal digital assistant (PDA) or mobile phone 1554A, a desktop computer 1554B, a laptop computer 1554C, or an automotive computer system 1554N, or combinations thereof, can communicate. The nodes 1400 may communicate with each other. They may be physically or virtually grouped in one or more networks (not shown), such as a private, community, public, or hybrid cloud, or combinations thereof, as described herein above. This enables the cloud computing environment 1550 to provide infrastructure, platform, and / or software as a service without requiring cloud users to maintain resources on their local computing devices. It is understood that the types of computing devices 1554A-1554N shown in FIG. 14 are intended to be exemplary only, and that the computing node 1400 and cloud computing environment 1550 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0103] Referring now to Figure 15, a set of functional abstraction layers provided by cloud computing environment 1550 (Figure 14) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 15 are intended to be merely exemplary, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0104] The hardware and software layer 1600 includes hardware and software components. Examples of hardware components include mainframes, such as IBM zSeries systems; servers based on RISC (Reduced Instruction Set Computer) architecture, such as IBM pSeries systems, IBM xSeries systems, and IBM BladeCenter systems; storage devices; and networks and networking components. Examples of software components include network application server software, such as IBM WebSphere application server software, and database software, such as IBM DB2 database software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.)

[0105] The virtualization layer 1620 provides an abstraction layer that may provide examples of the following virtual entities: virtual servers, virtual storage, virtual networks including virtual private networks, virtual applications and operating systems, and virtual clients.

[0106] In one example, the management layer 1630 may provide the following functions: Resource provisioning provides dynamic procurement of computing resources and other resources utilized to perform tasks within the cloud computing environment. Metering and pricing provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud subscribers and tasks, and protection of data and other resources. A user portal provides subscribers and system administrators with access to the cloud computing environment. Service level management provides allocation and management of cloud computing resources so that required service levels are met. Service level agreement (SLA) planning and fulfillment provides proactive coordination and procurement of cloud computing resources anticipated to be needed in the future by SLAs.

[0107] The workload layer 1640 provides examples of functionality for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this layer include mapping and navigation, software development and lifecycle management, virtual classroom instruction delivery, data analytics processing, transaction processing, and, more specifically with respect to the present invention, runtime system components that generate search autocomplete suggestions based on API and contextual input.

[0108] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a related application to co-pending U.S. patent application Ser. No. 17 / 130,238, IBM Docket No. P202005407US01, each filed Dec. 22, 2020, the contents of which are incorporated herein by reference in their entirety.

[0109] The many features and advantages of the present invention are apparent from the detailed description, and thus, it is intended in the appended claims to cover all such features and advantages of the present invention that fall within the true spirit and scope of the invention. Further, because numerous modifications and variations will readily occur to those skilled in the art, it is not desired to limit the invention to the exact construction and operation as illustrated and described, and therefore, all suitable modifications and equivalents may be utilized that are within the scope of the invention.

[0110] It is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The invention is capable of embodiments other than those described and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed in the specification and abstract is for the purpose of description and should not be regarded as limiting.

[0111] As such, those skilled in the art will appreciate that the conception on which this disclosure is based may readily be utilized as a basis for the designing of other structures, methods, and systems for carrying out the several purposes of the present invention. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the present invention. [Item 1] 1. A method for generating a computation to be executed in a target trusted execution environment (TEE), comprising: selecting the target TEE; generating a certificate that is satisfactory to the TEE; and Associating the authentication with the computation executed within the TEE that is authenticated; and generating the computation using the associated authentication. [Item 2] selecting attributes to be incorporated into the certificate for the TEE that are valid. The method according to item 1. [Item 3] 3. The method of claim 1 or 2, wherein the generating the authentication utilizes a security module (SM). [Item 4] 4. The method of any one of items 1 to 3, wherein associating the authentication with the computation includes dynamically inserting information into the computation. [Item 5] Item 4. The method of item 3, wherein a customer securely inserts a secret into the SM, the secret including metadata indicating which secure computation the secret is associated with. [Item 6] The customer has control over the SM; The method according to item 5. [Item 7] The SM inserts the certificate into the target TEE. The method according to item 3. [Item 8] 8. The method of any one of items 1 to 7, wherein the TEE is in the cloud or in a local infrastructure. [Item 9] 9. The method of claim 8, wherein the SM is used as part of the cloud or local infrastructure. [Item 10] 10. The method according to any one of items 1 to 9, wherein the detailed information about the cloud infrastructure or the detailed information about the TEE is disclosed only to the security module. [Item 11] 11. The method of any one of items 1 to 10, wherein the SM stores a list of pre-generated authentications if authentications have been pre-generated for the selected target TEE, and the SM is not re-generated. [Item 12] 12. The method of any one of items 1 to 11, wherein at least a portion of the computation is encrypted, and wherein encrypting a portion of the computation comprises encrypting information necessary to check the integrity of the computation. [Item 13] 13. The method of any one of items 1 to 12, wherein the authentication constrains the computation to a particular TEE among multiple TEEs. [Item 14] Provisioning the generated computation. 14. The method of any one of items 1 to 13, further comprising: [Item 15] 1. A system comprising: a memory for storing computer instructions; The computer instructions Select the target Trusted Execution Environment (TEE), Generate a certificate that the TEE is satisfied with, Associating the authentication with a computation executed within the TEE that is authenticated; a processor configured to execute the associated authentication to generate a computation; A system comprising: [Item 16] selecting attributes to be incorporated into the certificate for the TEE that are valid; generating the authentication utilizes a security module (SM); associating the authentication with the computation includes dynamically inserting information into the computation; a customer securely inserts a secret into the SM, the secret including metadata indicating which secure computation the secret is associated with; The customer has control over the SM; the security module inserts the authentication into the target TEE; Item 16. The system according to item 15. [Item 17] The TEE is located in the cloud or in local infrastructure; The SM is used as part of the cloud or local infrastructure; detailed information about the selected TEE is disclosed only to the SM; The SM stores a list of pre-generated certificates if certificates have been pre-generated for the selected target TEE, and the SM is not regenerated; at least a portion of the computation is encrypted, and encrypting the portion of the computation includes encrypting information necessary to check the integrity of the computation; the authentication constrains the computation to a particular TEE among a plurality of TEEs; The system further comprises: 17. The system of claim 15 or 16, further comprising provisioning the generated computation. [Item 18] On the computer, A procedure for selecting a target Trusted Execution Environment (TEE); a procedure for generating a certificate that is satisfactory to the TEE; associating the authentication with a computation executed within the TEE that is authenticated; and a computer program for causing the computer to perform the steps of generating a computation using the associated authentication. [Item 19] The computer, selecting attributes to be incorporated into the certificate for the TEE that are valid; the generating step utilizes a security module (SM); associating the authentication with the computation includes dynamically inserting information into the computation; a customer securely inserts a secret into the SM, the secret including metadata indicating which secure computation the secret is associated with; The customer has control over the SM; Item 19. The computer program of item 18, wherein the SM inserts the authentication into the target TEE. [Item 20] The TEE is located in the cloud or in local infrastructure; The SM is used as part of the cloud or local infrastructure; detailed information about the selected TEE is disclosed only to the security module; The SM stores a list of pre-generated certificates if certificates have been pre-generated for the selected TEE, and the SM is not regenerated; at least a portion of the computation is encrypted, and encrypting the portion of the computation includes encrypting information necessary to check the integrity of the computation; the authentication constrains the computation to a particular TEE among a plurality of TEEs; The computer, 20. The computer program of claim 18 or 19, further comprising the step of provisioning the generated computation. [Explanation of symbols]

[0112] 100 systems 102 TEE, Trusted Execution Environment 104 Trusted Software 106 Applications 108 Operating System 110 Processing Functions 112 TEE API 114 Processor B 116 Memory, Trusted Memory 120 Hardware 122 Proof Function 130 Software Section, Software 200 systems 300 System 301 System, Trusted Hardware 302 Customer, Customer Module 304 Tooling Module, Tooling 306 Cloud Front End 308 Cloud Object Store 310 Zone Orchestrator, Zone Orchestrator Module 312 Targeting System 318 VM Image_ID, SVM My-Image 325 Target Machine 326 Storage Key 338 Image-ID 340 Image-ID and associated image 342 Sealed Data 344 Images 350 Trusted Infrastructure 361 Untrusted Cloud Infrastructure, Cloud Providers 380 Security Module 416 VM 464 Challenge 466 Challenge 470 Response to Challenge, Challenge Response 472 Challenge 474 Challenge Response 476 Challenge Response 482 My-Image 483 Image-ID 500 Systems 540 Policy 544 Policy 673 Sealed Data 675 Sealed Data 677 Integrity Information 679 Customer Data 685 Sensitive Information 687 Secret 689 Payload, Payload Area 691 ESM Operands 772 Immutable Code 774 SB verification code 776 Variable Boot Loader 778 Host Boot Loader 780 HostBootInit. 782 Host Boot Ext. 784 OPAL 786 PCR6 788 Hardware Key Hash 790 Secure Boot Jumper 792 Separator 794 PEF Enable Bit 800 System 852 Orchestrator Module 854 VM 856 SVM, Image Copy 858 Library 860 vendor 862 TPM 864 Target Machines, Target Systems 866 SM, Security Module 868 Machine Set 870 Cloud Infrastructure 980 SM, Security Module, SM Hyper Protect 983 Image-ID 1003 PSP 1054 AMD Certification Authority 1100 Information Handling / Computer Systems 1110 Central Processing Unit, CPU 1112 Bus 1114 Random Access Memory 1116 Read-Only Memory 1118 Input / Output (I / O) Adapter 1121 Disk Unit 1122 User Interface Adapter 1124 keyboard 1126 Mouse 1128 Speaker 1132 Microphone 1134 Communication Adapter 1136 Display Adapter 1138 Display Devices 1139 Printer 1140 Tape Drive 1200 Signal retention storage medium 1210 Flash Memory 1220 Optical Storage Diskette 1400 cloud computing nodes 1412 Computer Systems / Servers 1414 External Devices 1416 processor or processing unit 1418 Bus 1420 Network Adapter 1422 Input / Output (I / O) Interface 1424 display 1428 System Memory 1430 Random Access Memory 1432 Cache Memory 1434 Storage Systems 1440 Programs / Utilities 1442 program modules 1550 Cloud Computing Environment 1554A Personal Digital Assistant (PDA) or Cell Phone 1554B Desktop Computer 1554C Laptop Computer 1554N Automotive Computer System 1600 Hardware and Software Layers 1620 Virtualization Layer 1630 Management layer 1640 workload tier

Claims

1. 1. A method performed by a system for generating a computation to be executed in a target trusted execution environment (TEE), comprising: selecting the target TEE in a cloud or local infrastructure; utilizing a Security Module (SM) to generate a certificate indicating that the target TEE meets certain criteria for performing the computation, the SM storing a list of already generated certificates, the SM being used as part of the cloud or local infrastructure, the SM being a trusted infrastructure by customer modules, detailed information about the target TEE being disclosed only to the SM, and the SM not regenerating a certificate for the target TEE if one has already been generated; associating the authentication with the computation to be performed in the target TEE to be authenticated, wherein at least a portion of the computation is encrypted, and wherein encrypting the portion of the computation includes encrypting information necessary to check the integrity of the computation, and wherein the authentication constrains the computation to a particular TEE among a plurality of TEEs; generating the computation executable in the target TEE using the associated authentication; provisioning the computation to be generated; A method comprising:

2. The method described in claim 1, wherein the authentication is generated by the SM when the SM verifies the target TEE based on information of the target TEE and the verification is successful.

3. The method described in claim 2, wherein the information of the target TEE includes an IP address of the target TEE, a platform certificate of the target TEE, and a storage key of the target TEE.

4. The target TEE comprises a Trusted Platform Module (TPM); The method of claim 2 or 3, wherein the verification is performed by checking a challenge response by the target TEE to information sent to the target TEE having the TPM.

5. selecting attributes to be incorporated into the certificate for the target TEE that are valid.

5. The method according to any one of claims 1 to 4.

6. The method of claim 1 , wherein associating the authentication with the computation comprises dynamically inserting information into the computation.

7. A method described in any one of claims 1 to 6, wherein the SM has a secret securely inserted by a customer, the secret including metadata indicating which secure computation the secret is associated with.

8. The SM is under the control of the customer. The method of claim 7.

9. The SM inserts the authentication into the target TEE.

9. The method according to any one of claims 1 to 8.

10. 1. A system comprising: a memory for storing computer instructions; The computer instructions Selecting a target Trusted Execution Environment (TEE) in a cloud or local infrastructure; Utilizing a Security Module (SM) to generate a certificate indicating that the target TEE meets certain criteria for performing a computation, the SM storing a list of already generated certificates, the SM being used as part of the cloud or local infrastructure, the SM being a trusted infrastructure by customer modules, detailed information about the target TEE being disclosed only to the SM, and the SM not regenerating a certificate for the target TEE if one has already been generated; associating the authentication with the computation to be performed in the target TEE to be authenticated, wherein at least a portion of the computation is encrypted, and wherein encrypting the portion of the computation includes encrypting information necessary to check the integrity of the computation, and wherein the authentication constrains the computation to a particular TEE among a plurality of TEEs; generating the computation executable in the target TEE using the associated authentication; and provisioning the generated computation. A system comprising:

11. selecting attributes to be incorporated into the certificate for the target TEE that are valid; associating the authentication with the computation includes dynamically inserting information into the computation; the SM has a secret securely inserted by a customer, the secret including metadata indicating which secure computation the secret is associated with; The SM is under the control of the customer; The SM inserts the authentication into the target TEE. The system of claim 10.

12. On the computer, selecting a target Trusted Execution Environment (TEE) in a cloud or local infrastructure; utilizing a security module (SM) to generate a certificate indicating that the target TEE meets certain criteria for performing a computation, the SM storing a list of already generated certificates, the SM being used as part of the cloud or local infrastructure, the SM being a trusted infrastructure by customer modules, detailed information about the target TEE being disclosed only to the SM, and the SM not regenerating a certificate for the target TEE if one has already been generated; associating the authentication with the computation to be performed in the target TEE to be authenticated, wherein at least a portion of the computation is encrypted, and wherein encrypting the portion of the computation includes encrypting information necessary to check the integrity of the computation, and wherein the authentication constrains the computation to a particular TEE among a plurality of TEEs; generating the computation executable on the target TEE using the associated authentication; and a computer program for causing the computer to execute a procedure for provisioning the generated computation.

13. The computer, selecting attributes to be incorporated into the certificate for the target TEE that are valid; associating the authentication with the computation includes dynamically inserting information into the computation; the SM has a secret securely inserted by a customer, the secret including metadata indicating which secure computation the secret is associated with; The SM is under the control of the customer; The computer program product of claim 12 , wherein the SM inserts the authentication into the target TEE.

Images