JP7805067B2 - 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) - Google Patents

Description

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.

Cloud computing is an important aspect of enterprise infrastructure. Cloud infrastructure can be private, public, or hybrid. One of the key challenges with hybrid and public clouds is for enterprises to extend their trust boundaries to the cloud provider and its personnel. While the cloud is expanding dramatically, one of its major inhibitors is trust. In most cloud infrastructures, it is assumed from the start that the cloud provider and its staff can be trusted.

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.

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

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 attestation that the TEE satisfies, associating the attestation with a computation to be executed in the attested TEE, and generating the computation using the associated attestation.

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 performed within the authenticated TEE, and generate the computation using the associated authentication.

According to yet another embodiment of the present invention, a computer program product includes 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.

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 below and that will form the subject matter of the claims appended hereto.

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.

As such, those skilled in the art will appreciate that the conception upon 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.

Exemplary aspects of the present invention will be better understood from the following detailed description of exemplary embodiments of the invention taken in conjunction with the drawings.

FIG. 1 illustrates an example of a TEE (Trusted Execution Environment) when used in the present invention. FIG. 1 is an exemplary flow diagram of an embodiment of the present invention. FIG. 1 is an exemplary flow diagram of an embodiment of the present invention. FIG. 10 illustrates a keep your own key flow for an alternative security model of an embodiment of the present invention in a cloud infrastructure. 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. FIG. 2 illustrates a method of provisioning in an embodiment of the present invention. 1 is a layout of the ESM (enter secure mode) operand. 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. FIG. 1 illustrates verification of computation in an embodiment of the present invention. FIG. 1 illustrates an exemplary protected execution facility (PEF) according to an embodiment of the present invention. FIG. 1 illustrates an alternative security model utilizing SM for an embodiment of the present invention in a cloud infrastructure. FIG. 1 illustrates the flow of validation of a target system (i.e., a system of a protected execution facility (PEF)) for an alternative model utilizing SM of an embodiment of the present invention in a cloud infrastructure. FIG. 1 illustrates an alternative security model for an embodiment of the present invention in a cloud infrastructure that utilizes SM to provision TEEs on processors of AMD (Advanced Micro Devices). FIG. 1 illustrates a flow diagram of verification of a target system (i.e., a system with a protected execution facility (PEF)) for a TEE in a processor of an AMD (ADVANCED MICRO DEVICE) for an alternative model utilizing SM of an embodiment of the present invention in a cloud infrastructure. FIG. 1 illustrates an exemplary hardware/information handling system for incorporating an exemplary embodiment of the present invention. 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. FIG. 1 illustrates a cloud computing node according to an exemplary embodiment of the present invention. FIG. 1 illustrates a cloud computing environment in accordance with an exemplary embodiment of the present invention. FIG. 2 illustrates an abstraction model layer according to an example embodiment of the present invention.

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. The following exemplary embodiments are provided for illustrative purposes 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.

As previously mentioned, a major obstacle to cloud adoption is security. Cloud vendors have access to all information utilized 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). The present invention also supports TEEs that are part of the cloud's nodes or infrastructure but are not embedded in any particular CPU architecture.

Processor vendors provide 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 based on their "granularity" as either coarse-grained or fine-grained. A coarse-grained TEE operates at the VM (Virtual Machine) or processor level, for example, while a fine-grained TEE only protects a process or a single thread of execution. Examples of coarse-grained include IBM's Secure Service Containers, ARM's (Advanced Reduced Instruction Set Computer (RISC) Machines) TrustZone (which some may not consider a TEE), IBM's Protected Execution Facility (PEF), and AMD's Secure Encrypted Virtualization (SEV). Intel's Software Guard Extension (SGX) is a fine-grained TEE. Intel has stated its intention to provide coarse-grained support. All TEEs are trusted due to the hardware-enforced requirements placed on code running within the secure partition and the user's ability to verify that the hardware is legitimate.

Most TEEs also offer some form of attestation. Due to the lack of attestation and several other characteristics, the current ARM TrustZone™ may be ruled out as a TEE. However, ARM processors can be used with external TPMs that 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 properties of the environment in which their code or secrets will be executed. TEEs are designed with 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 TEEs provide defense against hostile access.

Even with these capabilities, leveraging TEEs to provide confidential computing remains challenging, as much cloud infrastructure assumes that providers can be trusted.

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 utilize that 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.

The present invention is illustrated using the Protected Execution Facility (PEF) TEE. PEF supports secure computation using what are called Secure Virtual Machines (SVMs). All SVMs begin execution as normal VMs, and during their initialization they execute an ESM (Enter Secure Mode) ULTRAVISOR call, which requests a transition from a normal virtual machine to a secure virtual machine. PEF requires that a properly configured platform has a TPM and is running with secure and trusted boot enabled.

As used herein, TPM refers to hardware used to hold measurements related to an attestation function. The attestation function may be built into the processor or implemented external to the processor architecture. One refers to TPM PCRs as representing some trusted mechanism for recording measurements.

The present invention leverages TPM (Trusted Platform Module) and TEE hardware deployed in cloud infrastructure. There are two models for leveraging TEE in cloud infrastructure: BYOK (Bring Your Own Key) or KYOK (Keep Your Own Key). BYOK required a key vault under the control of the cloud user, such as a SM (Security Module) 866 in the cloud infrastructure, to avoid users exposing their keys 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™, IBM Z Secure Execution™, TEEs, or even TPMs. Sensitive information can be stored in customer-controlled key vaults. KYOK requires clouds to provide detailed information about their infrastructure to cloud users.

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 is growing dramatically, one of its major inhibitors is trust. In most cloud infrastructures, it is assumed from the start that the cloud provider and its staff can be trusted.

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 to 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 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 where trusted applications and the TEE API execute. This may be an entirely separate processor, or may refer to the trusted state of a single processor. The memory 116 within the TEE is trusted, and the 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; however, any hardware used to securely store measurements of firmware and/or software may provide the attestation function.

The trusted software within a 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.

External to the TEE are 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.

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 containing 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 preferred embodiments, 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 a function 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 a certificate can be generated. 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.

Step 206 generates a certificate. Generally, a certificate constrains the set of TEEs that are certified 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 the certified TEE has 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 that indicates which TEE the certificate pertains to. The TEE verifies the certificate if the identifier is present.

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 not allowed to be copied. Alternatively, the key is locked to the TPM and only copied 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 may also be kept in some other location protected by a hardware root of trust. When using a TPM, the policy associated with the ability to access the private key and unseal the symmetric key can constrain the set of systems or configuration 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 PCR match a specific value, such as that shown in Figure 7A. An example constraint is described in Figure 7A. Those skilled in the art will recognize that authentication can be arbitrarily complex. The authentication may be embedded in the sealed data or may be separate metadata.

Associate authentication with the computation 208. The steps for associating authentication with the computation are described in Figure 6.

The computation is generated using the associated certificate 210. 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.

Finally, the computation is provisioned into the target TEE 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 provided in Figures 3 and 4, 9A and 9B, and 10A and 10B.

In some TEE models, the user of the TEE must explicitly verify that the TEE is valid before inserting a secret. In such models, the TEE is launched on the target system but is not decrypted 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 has authorized 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 in this type of TEE. This association is implicit by running the TEE in the target system. The generator is the user computing an acceptable value.

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, 232. Examples of validating the target TEE are seen in FIGS. 4, 10A, and 10B. If the TEE cannot be verified, provisioning ends at 246. Next, computation integrity information must be generated, 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 the owner via some secure mechanism; if incorrect, execution of the TEE will be terminated. It is useful to note that in implementations where the owner must verify the integrity of the 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 the computation. Those skilled in the art will recognize that sealed data is a term specific to the TPM. When 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.

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

Specifically, Figure 3 shows the KYOK (Keep Your Own Key) flow for the security model of an embodiment of the present invention.

In 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.

System 200 is divided into a trusted infrastructure 350 (highlighted) and an untrusted cloud infrastructure 361 (the remaining structure not highlighted). The trusted infrastructure 350 (highlighted) is shown as customer 302 and tooling module 304.

This flow assumes that a VM 416 (not shown), which may be an SVM, with an image ID (identification information) of Image-ID has been pre-loaded 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 of Image-ID 324.

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 a 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 a TPM 312 then returns the platform certificate and storage key 328 to the zone orchestrator 310. The zone orchestrator 310 requests that the client tooling module 304 enroll the target machine via Enroll This Machine (Mach-ind, Platform Certificate, Storage Key) 330.

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

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.

The zone orchestrator module 310 requests an Image-ID (Image identification information) 338 from the cloud object store 308. The cloud object store 308 returns the image associated with the Image-ID 340 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 the image 344.

Figure 4 shows details of target system validation 332 (PEF) in 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.

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 correct, 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 authentication information 462. The challenge consists of authentication information, which is a binary blob that only the TPM on the Mach-inst can open (used to obtain a challenge for the correct system). The tooling module 304 sends a 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.

Figure 5 shows a method for provisioning a machine in an embodiment of the present invention.

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

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 in order to use the storage key. A new password is assigned and provided to the ULTRAVISOR with each boot. In a preferred embodiment, the password is regenerated with each boot.

The third step of provisioning 542 is to generate a storage key using a pre-computed policy that states that the password required to access 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.

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

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.

Figure 6 shows the layout of the 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 payload area 689 of the ESM operand. Sealed data 673 provides access to machine A, and sealed data 675 provides access to machine B. The unsealed data is the seed used to generate the symmetric key and HMAC key. Everything in the payload area 689 except 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 the information required by PEF to verify the integrity of the computation. It consists of a hash of the kernel, the kernel command line, initramfs (initial RAM (random access memory)), and the 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 the ESM operand. (For techniques that involve contacting the owner/user of the computation to verify the integrity of the computation, the information must be calculated by the TEE.) The remaining information in the payload area 689 is the secret 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 that protects the root disk, encrypted with a symmetric key. Following the encrypted passphrase are zero or more blocks of customer data. Each secret 687 is encrypted using a symmetric key generated from the seed.

Figure 7A shows 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 understand 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 Figure 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 if secure and trusted boot is enabled whenever signature verification fails. When the system is powered on, the immutable boot loader 772 is the first code executed. 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 encryption key being used to verify the signature on the encryption 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. Variable boot loader 776 validates host boot loader 778. 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 the state of the PEF enabled bit 794 required to authenticate the TEE to perform secure computation.

Figure 7B illustrates checking authentication requirements 240 and verifying the integrity of computation information 242 in an embodiment of the invention using PEF. As previously described, a secure computation begins as a normal VM. It executes an ESM ULTRAVISOR call to transition to a secure VM running within a PEF TEE, at which point verification begins 750. In a preferred embodiment, the ESM ultra-call requires the ESM operand 691 shown in Figure 6. If the ESM operand is not present, the ESM ultra-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 the PEF, this check is performed by the TPM when the 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, the symmetric key is generated 760. This gives the TEE access to the information required for verifying 242 the integrity of the computation. If the computation has been altered, execution terminates 766. Otherwise, the VM completes the migration to the SVM and is executed 764, thereby completing the migration successfully 768 and the VM now becoming an SVM.

Provisioning. Figure 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 asks a security module (SM) 866 to verify one of the selected target machines, T0...Tn, 864 (S2). In Figure 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 do this, it must have the platform vendor's public key. Once it has the key, it can store it internally to expedite the verification process. The SM 866 uses the vendor's (S3a) public key to verify the machine, or 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 PEF, all SVMs begin execution as VMs 854. As far as the library 858 is concerned, all images are VMs 854. To simplify the description of the present invention, these VMs 854 that can become SVMs are labeled as 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 distinction clear or transparent. The orchestrator inserts the sealed data into a copy of the SVM. The orchestrator module 852 dispatches (S6) a copy of the SVM 856 to the target system 864. In the case of a 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 daily maintenance, upgrades, etc.) without affecting the existing SVM 856. One of the key attributes of the PEF Enter Secure Module (ESM) operand that allows for easy integration into the cloud infrastructure 870 is that HMAC (Hashing for Message Authentication Code) does not cover the sealed data. This means that the sealed data does not need to be generated at the same time as 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 saved to the cloud object store 308. This would be useful in alternative embodiments where a TEE represents a set of systems. The cloud object store 308 may also save metadata indicating whether sealed information already exists. If so, a VM can be dispatched directly to the TEE (set of machines). The ESM operand is a digital blob that resides in a reserved section of the initramfs. It may also reside in the ELF (executable and linkable format) section of a zImage (self-extracting compressed image) format file that contains the kernel. All the information needed to verify the validity of the SVM is contained in the ESM operand.

An example deployment model involves dynamically generating sealed data using a security module (SM) 866 or equivalent functionality in the cloud provider's infrastructure. In the present 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 are safe to 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 is 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 identity of the VM, SM 866 will use the associated metadata to select the appropriate symmetric seed.

Continuing with 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 transfers the target machine 864, the platform certificate, and the storage key to SM 866 under the customer's control and requests enrollment of the target machine 864 for the SVM. In an alternative embodiment, the cloud infrastructure transfers only the target machine and requests the 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, those 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.

The enrollment protocol includes the following: SM866, or an equivalent function, must execute the enrollment protocol. The enrollment protocol requires the cloud infrastructure 870 to pass the SM866 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 SM866 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 SM866 will generate a random challenge and create credentials. It will then send the activation credentials to the target machine 864 to be executed on its TPM862. 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.

The enrollment protocol only needs to be run once per target. Thus, 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.

Figures 9 and 10 show a Protected Execution Facility (PEF) that uses SM to verify a target system.

The first approach, shown in Figures 3 and 4, requires the infrastructure provider to expose details such as the server's IP (Internet Protocol) 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.

Some cloud providers may not want to expose details of their infrastructure because doing so 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 that shown in Figures 9 and 10. The customer must securely insert their secret into the SM.

Figures 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. Figures 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. Figures 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-Image 482, which would imply that the customer has prior knowledge of Image-ID 483.

Figure 9A illustrates an alternative form of a Protected Execution Facility (PEF) utilizing a Security Module (SM) in 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.

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

The tooling module 304 then uploads 982 the VM My-Image to the cloud object store 308, where it can be migrated 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 of the Image-ID.

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.

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

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

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 the image 344, to the target system 312 with the selected machine's TPM.

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

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

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

Figure 10A shows an alternative security model for an embodiment of the present invention in a cloud infrastructure, utilizing an SM to provision TEEs on AMD processors. In Figure 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 from the cloud front end 306 320. The cloud front end 306 confirms the paid service 322. The customer's tooling uploads its image, My-Image, to the cloud object store 982. The cloud object store 308 returns 383 the image identifier, Image-ID, of the stored image to the customer tooling 304. The customer tooling 304 securely inserts 984 the 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 the 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.

Figure 10B illustrates the flow of target system validation (PEF) for a TEE in an AMD processor for an alternative model utilizing an SM for an embodiment of the present invention in a cloud infrastructure. Figure 10B provides details of the target machine validation 1025 request of Figure 10A. The request to validate 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 a TEE, Figure 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 sub-component of the AMD processor that is expanded in Figure 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 an overview of the process. Further details are provided in AMD white papers and technical documentation available to anyone 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 1027 the certificate from the response and requests validation 1094 from the AMD certificate authority 1054. The AMD certificate authority 1054 returns a validation response 1096. If the certificate does not validate, the activation (the request to run a secure VM within the TEE) is terminated. If the certificate is validated, the SM 980 requests 1029 the zone orchestrator 310 to load the VM image onto the target system. The zone orchestrator 310 sends the VM image associated with the Image-ID to the target system along with a load image request 1051. The target system 312 loads the VM image into a TEE (not shown). The SM 980 issues an attestation request for the VM image Image-ID to the target system 312 1057. The target system 312 issues an attestation request to the trusted PSP 1003. The PSP 1003 generates an attestation response and returns it to the system 312 1059. The target system returns the attestation response to the SM 980 1099. The SM verifies the attestation response against the hash of the VM 1055. If the verification fails, the activation is terminated. If the verification is successful, the SM 980 obtains the certificate (also called a decryption key) and issues an insert certificate to the target system 312 1091. The target system passes the Insert Authentication command to the PSP 1003 (1097). The PSP 1003 inserts the authentication into the TEE. The SM 980 issues a Boot System command to the target system 312 (1093), which is successful because secure computation has been authenticated (the decryption key has been successfully inserted).

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.

Figure 11 shows another hardware configuration of a system in which an information handling/computer system 1100 according to the present invention resides, 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.

As already mentioned, the trusted execution environment 102 can be implemented in a local infrastructure such as that shown in FIG. 11.

The CPU 1110 is interconnected via the system bus 1112 to random access memory (RAM) 1114, 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, and/or other user interface devices 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.).

In addition to the hardware/software environments described above, another aspect of the present invention includes a computer-implemented method for performing the above-described method. By way of example, this method may be implemented in the specific environment discussed above.

Such methods may be implemented, for example, by operating a computer, such as one embodied in a digital data processing device, to execute a sequence of machine-readable instructions. These instructions may reside in various types of signal-bearing media.

As such, this aspect of the present 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 CPU 1110 and the hardware described above to perform the method of the present invention.

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

Alternatively, the instructions may be contained on another signal-bearing storage medium 1200 accessible directly or indirectly by the CPU 1110, such as flash memory 1210 or optical storage diskette 1220 (Figure 12).

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.

Accordingly, 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.

A computer-readable storage medium may be a tangible device capable of holding 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 (DVDs), 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 waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted over wires.

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.

The 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, 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 circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute computer-readable program instructions to personalize the electronic circuit by utilizing state information in the computer-readable program instructions to perform aspects of the present invention.

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.

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 implementing the functions/acts specified in one or more blocks of the flowcharts and/or block diagrams.

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.

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.

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 the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur in an order different from that 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.

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 be implemented and/or capable of performing any of the functionality described herein above. As previously mentioned, trusted execution environment 102 may be implemented in a cloud infrastructure such as that of 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.

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. 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.

As shown in FIG. 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, system memory 1428, and a bus 1418 that couples various system components, including system memory 1428 to processor 1416.

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. By way of example, and without limitation, such architectures include 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.

Computer system/server 1412 typically includes a variety of computer system-readable media. Such media may be any available media accessible by computer system/server 1412, including both volatile and nonvolatile media, removable and non-removable media.

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. Computer system/server 1412 may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, 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, magnetic disk drives may be provided for reading from and writing to removable, non-volatile magnetic disks (e.g., "floppy disks"), and optical disk drives 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 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.

Programs/utilities 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 the 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 implementation of a networking environment. Program modules 1442 generally perform the functions or methodologies, or combinations thereof, of embodiments of the present invention as described herein.

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.

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 cell phone 1554A, a desktop computer 1554B, a laptop computer 1554C, or an automobile 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 illustrative 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).

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

The hardware and software layer 1600 includes hardware and software components. Examples of hardware components include mainframes, such as IBM zSeries systems, RISC (Reduced Instruction Set Computer) architecture-based servers, such as IBM pSeries systems, IBM xSeries systems, and IBM BladeCenter systems, storage devices, 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.)

The virtualization layer 1620 provides an abstraction layer that can 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.

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 users and tasks, and protection of data and other resources. A user portal provides users 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 anticipated future cloud computing resource needs per SLAs.

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.

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 entireties.

The many features and advantages of the present invention are apparent from the detailed description, and thus, it is intended by 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 shown and described; therefore, all suitable modifications and equivalents may be utilized that are within the scope of the invention.

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.

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 satisfies the TEE;
Associating the authentication with the computation performed 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 certificate utilizes a security module (SM).
[Item 4]
4. The method of claim 1, 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 of the SM;
Item 5. The method according to item 5.
[Item 7]
The SM inserts the authentication into the target TEE.
The method according to item 3.
[Item 8]
8. The method of any one of claims 1 to 7, wherein the TEE is in the cloud or in a local infrastructure.
[Item 9]
9. The method of claim 8, wherein SM is used as part of the cloud or local infrastructure.
[Item 10]
10. The method of any one of claims 1 to 9, wherein detailed information about the cloud infrastructure or detailed information about the TEE is disclosed only to a 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 regenerated.
[Item 12]
12. The method of claim 1, wherein at least a portion of the computation is encrypted, and wherein encrypting the 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 a plurality of 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
Selecting a target Trusted Execution Environment (TEE),
Generate a certificate that satisfies the TEE;
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;
said generating said certificate utilizing 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 of the SM;
the security module inserts the certificate into the target TEE;
Item 16. The system according to item 15.
[Item 17]
the TEE is in the cloud or in a local infrastructure;
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,
selecting a target trusted execution environment (TEE);
a procedure for generating a certificate that satisfies the TEE;
associating the authentication with a computation executed within the TEE that is authenticated;
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;
said generating said certificate utilizing 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 of the SM;
20. The computer program product of claim 18, wherein the SM inserts the authentication into the target TEE.
[Item 20]
the TEE is in the cloud or in a local infrastructure;
SM is used as part of the cloud or local infrastructure;
detailed information about the selected TEE is disclosed only to a 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 according to claim 18, further comprising the step of provisioning the generated computation.

100 System 102 TEE, Trusted Execution Environment 104 Trusted Software 106 Application 108 Operating System 110 Processing Function 112 TEE API
114 Processor B
116 Memory, Trusted Memory 120 Hardware 122 Attestation Function 130 Software Section, Software 200 System 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 Target System 318 VM Image_ID, SVM My-Image
325 Target machine 326 Storage key 338 Image-ID
340 Image associated with Image-ID 342 Sealed data 344 Image 350 Trusted Infrastructure 361 Untrusted Cloud Infrastructure, Cloud Provider 380 Security Module 416 VM
464 Challenge 466 Challenge 470 Response to challenge, challenge response 472 Challenge 474 Response to challenge 476 Challenge response 482 My-Image
483 Image-ID
500 System 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 Operand 772 Immutable Code 774 SB Verification Code 776 Variable Boot Loader 778 Host Boot Loader 780 Host Boot Init.
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 Machine, Target System 866 SM, Security Module 868 Set of Machines 870 Cloud Infrastructure 980 SM, Security Module, SM Hyper Protect
983 Image-ID
1003 PSP
1054 AMD Certification Authority 1100 Information Handling/Computer System 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 device 1139 printer 1140 tape drive 1200 signal-bearing storage medium 1210 flash memory 1220 optical storage diskette 1400 cloud computing node 1412 computer system/server 1414 external device 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 System 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 Layer 1620 Virtualization Layer 1630 Management Layer 1640 Workload Layer

Claims (13)

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: The method of claim 1 , wherein the certificate is generated by the SM if the SM verifies the target TEE based on information of the target TEE and the verification is successful. 3. The method of 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. 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 with the TPM. 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 . The method of claim 1 , wherein associating the authentication with the computation comprises dynamically inserting information into the computation. The method of claim 1 , wherein 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 method of claim 7 . The SM inserts the authentication into the target TEE.
9. The method according to any one of claims 1 to 8 . 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 a processor configured to perform the provisioning of the generated computation . 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 . 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 . 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.