Provisioning secure / encrypted virtual machines in a cloud infrastructure

Abstract

The present disclosure relates to provisioning secure / encrypted virtual machines in a cloud infrastructure. More specifically, to a method, system and apparatus for generating a computation such that it will be executed in a target trusted execution environment (TEE), comprising: selecting the target TEE; generating an authorization to be satisfied by the TEE; associating the authorization with the computation to be executed in the authorized TEE; and generating the computation with the associated authorization.

Description

[0001] Cross Reference to Related Applications

[0002] This application is related applications U.S. Patent Application No. 17 / 130,238, IBM Docket No. P202005407US01, each of which was filed on December 22, 2020, and the entire contents of which are incorporated herein by reference. TECHNICAL FIELD

[0003] Embodiments of the present invention relate to methods, apparatuses, and systems for secure / encrypted virtual machines, and more particularly, but not by way of limitation, to methods, apparatuses, and systems for provisioning secure / encrypted virtual machines in a cloud infrastructure. BACKGROUND

[0004] Cloud computing is an important aspect of enterprise infrastructure. Cloud infrastructure can be private, public, or hybrid. One of the main challenges of hybrid and public clouds is that enterprises extend their trust boundary to the cloud provider and its personnel. Despite the rapid growth of the cloud, one of the main inhibitors is trust. Most cloud infrastructures have a built-in assumption that the cloud provider and its workforce are trustworthy.

[0005] Thus, a significant impediment to cloud adoption is security. Therefore, there is a need to provide a more secure cloud computing platform that is efficient and cost effective. Further, there is a need to provide a set of protocols that make security in cloud computing possible without having to trust the cloud provider. SUMMARY

[0006] In view of the foregoing background of the foregoing background, problems, drawbacks, and deficiencies, exemplary aspects of the disclosed invention provide a method, apparatus, and system for provisioning secure / encrypted virtual machines in a cloud infrastructure.

[0007] According to an embodiment of the present invention, a method for generating a computation such that it will be executed in a target trusted execution environment (TEE), the method comprising: selecting the target TEE; generating an authorization satisfied by a TEE; associating the authorization with the computation for execution in the authorized TEE; and generating the computation with the associated authorization.

[0008] According to another embodiment of the present invention, a system comprising: a memory storing computer instructions; and a processor configured to execute the computer instructions to: select a target TEE; generate an authorization satisfied by a TEE; associate the authorization with the computation for execution in the authorized TEE; and generate the computation with the associated authorization.

[0009] According to yet another embodiment of the present application, a computer program product comprises a computer readable storage medium having program instructions embodied therewith, the program instructions readable and executable by a computer to cause the computer to perform a method comprising: selecting a target TEE; generating an authorization satisfied by the TEE; associating the authorization with the computation performed in the authorized TEE; and generating the computation with the associated authorization.

[0010] Thus, certain embodiments of the application have been generally described as broadly as possible to encompass the inventive concepts and to provide a better understanding of the detailed description of the application and the contribution to the art. Of course, there will be additional embodiments of the application that will be described below and that will form the subject matter of the claims appended hereto.

[0011] It should be understood that the application 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 application is capable of embodiments in addition to those described and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein, as well as the abstract, are for the purpose of description and should not be regarded as limiting.

[0012] As such, those skilled in the art will appreciate that the conception, upon which this disclosure is based, can readily be utilized as a basis for the designing of other structures, methods and systems for carrying out the several purposes of the present application. It is important, therefore, that equivalent constructions be made under the spirit and scope of the application, as set forth in the claims. BRIEF DESCRIPTION OF DRAWINGS

[0013] Example aspects of the present application will be better understood in connection with the following detailed description of example embodiments of the application in reference to the following drawings.

[0014] Figure 1 An example of a TEE (Trusted Execution Environment) as utilized in the present application is shown.

[0015] Figure 2A An example flow diagram of an embodiment of the present application is shown.

[0016] Figure 2B An example flow diagram of an embodiment of the present application is shown.

[0017] Figure 3 A keep-your-own-key flow for an alternate security model for embodiments of the present application in a cloud infrastructure is shown.

[0018] Figure 4 A validate target system (i.e., a protected execution facility (PEF) system) flow for a keep-your-own-key model for embodiments of the present application in a cloud infrastructure is shown.

[0019] Figure 5 A method provided in an embodiment of the invention is shown.

[0020] Figure 6 The layout of an ESM (enter safe mode) operand is shown.

[0021] Figure 7A Values extended in an embodiment of the invention into PCR 6 (platform configuration register 6) for verification of hardware configuration are illustrated.

[0022] Figure 7B A calculation to verify an embodiment of the invention is shown.

[0023] Figure 8 An example protected execution facility (PEF) of an embodiment of the invention is shown.

[0024] Figure 9A An alternate security model using the SM of an embodiment of the invention in a cloud infrastructure is shown.

[0025] Figure 9B A verification target system (i.e., protected execution facility (PEF) system) flow for an alternate model using the SM of an embodiment of the invention in a cloud infrastructure is shown.

[0026] Figure 10A An alternate security model utilizing the SM to provide a TEE in an AMD (Advanced Micro Devices) processor of an embodiment of the invention in a cloud infrastructure is shown.

[0027] Figure 10B A verification target system (i.e., protected execution facility (PEF) system) flow for a TEE in an AMD (Advanced Micro Devices) processor for an alternate model using the SM of an embodiment of the invention in a cloud infrastructure is shown.

[0028] Figure 11 An exemplary hardware / information processing system for incorporating exemplary embodiments of the invention therein is shown.

[0029] Figure 12 A signal bearing medium for storing machine readable instructions for programs implementing methods according to exemplary embodiments of the invention is shown.

[0030] Figure 13 A cloud computing node is depicted according to an exemplary embodiment of the invention.

[0031] Figure 14 A cloud computing environment is depicted according to an exemplary embodiment of the invention.

[0032] Figure 15An abstract model layer is depicted for an example embodiment according to the present invention. DETAILED DESCRIPTION

[0033] The present invention will now be described with reference to the attached figures. Wherever possible, the same reference numbers are used in the drawings and the following description to refer to the same or similar parts. It should be noted that the drawings are in simplified form and not to precise scale. In other words, the dimensions of the various features in the figures can have been exaggerated or reduced for the sake of clarity. The exemplary embodiments are provided for illustrative purposes and are not limiting. Furthermore, it is to be understood that any feature described in relation to one embodiment can be incorporated into any other embodiment unless specifically noted. Also, it is to be understood that any step or block of the described methods can be carried out in a different order or combination, or simultaneously.

[0034] As mentioned before, a significant hindrance for the adoption of the cloud is security. The cloud provider has access to all information utilized within the running containers or VMs (Virtual Machines). In response to this problem, different CPU (Central Processing Unit) vendors have modified their architecture so that private computing can be created and run. The architectural changes usually fall under the heading of Trusted Execution Environments (TEEs). The present invention also supports TEEs that are part of the cloud node or infrastructure but are not incorporated into any specific CPU architecture.

[0035] Processor vendors are providing cloud providers with means to address the trust gap with the creation of Trusted Execution Environments (TEEs) that provide hardware support for secure execution. A TEE divides a processor or process into a secure region and a non-secure region. TEEs can be classified based on "granularity" (coarse-grained or fine-grained). Coarse-grained TEEs work, for example, at the VM (Virtual Machine) or processor level, while fine-grained TEEs protect only a process or a single thread of execution. Examples of coarse-grained include IBM Secure Service Container™, ARM (Advanced RISC (Reduced Instruction Set Computer) Machines) TrustZone™ (some do not consider this a TEE), IBM TM Protected Execution Facility (PEF) and AMD™ Secure Encrypted Virtualization (SEV). Intel TM Software Guard Extensions (SGX) is an example of a fine-grained TEE. Intel has announced intentions to provide coarse-grained support. All TEEs are trusted because of the hardware-enforced requirements imposed on code running in the secure partition and the ability of the user to verify that the hardware is correct.

[0036] Most TEEs also provide some form of attestation. The lack of attestation and some other features has caused some features to be excluded from the current ARM TrustZone TMTEE. However, the arm processor can be used with an external TPM that can provide attestation in the form. The method and point of attestation differ. Attestation enables a remote party to be sure that the properties of the TEE are verified, which includes what software is currently running in the TEE and / or the firmware / software base of the TEE is verified. Attestation enables the TEE user to verify critical properties about the environment in which their code or secrets will execute. TEEs are designed assuming that an adversary can have 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 an adversary access or control. The architectural changes introduced by TEEs provide a defense against adversary access.

[0037] Even with these capabilities, it remains a challenge to leverage TEEs to provide confidential computation due to the trust in the cloud infrastructure undertaker.

[0038] Among other features, the present invention identifies a set of protocols and components that, when enabled and leveraged in a cloud infrastructure, allow a customer of the cloud infrastructure to leverage the infrastructure without sharing any of their secrets with the cloud provider. The present invention provides a set of protocols that enable a user to leverage a protected execution facility or other coarse-grained TEE without having to trust the cloud provider.

[0039] The present invention is described using a protected execution facility (PEF) TEE. PEF supports secure computation called secure virtual machines (SVMs). All SVMs start execution as normal VMs, and during their initialization process, they execute an ESM (enter secure mode) ULTRAVISOR call, which is a request to transition from a normal virtual machine to a secure virtual machine. PEF requires a correctly configured platform to have a TPM and to execute with secure and trusted boot enabled.

[0040] The TPM used in this embodiment represents the hardware used to hold the measurements of the attestation function. The attestation function can be incorporated in the processor or implemented outside the processor architecture. One involves a TPM PCR, which represents any trusted mechanism used to record measurements.

[0041] The present invention utilizes TPMs (Trusted Platform Modules) and TEE hardware deployed in the cloud infrastructure. There are two models for utilizing TEE in the cloud infrastructure, either BYOK (Bring Your Own Key) or KYOK (Keep Your Own Key). BYOK requires a secure key under the control of the cloud user, such as a SM (Secure Module) 866 in the cloud infrastructure, so that the user avoids exposing their key to the cloud provider. Examples of secure modules 866 include HSMs (Hardware Security Modules), such as IBM 4769 Cryptographic Coprocessor TM , IBM HyperProtect TM , IBM Z Secure Service Container TM , IBM Z Secure Execution TM , TEE, or even TPM. Sensitive information can be kept in key security under the control of the customer. KYOK, on the other hand, requires the cloud to provide the cloud user with detailed information about their infrastructure.

[0042] Cloud computing is an important aspect of enterprise infrastructure. Cloud infrastructure can be private, public, or hybrid. As mentioned previously, one of the major challenges of hybrid and public clouds is that enterprises extend their trust boundary to the cloud provider and its personnel. Despite the dramatic growth of the cloud, one of the major inhibitors is trust. Most cloud infrastructures have a built-in assumption that the cloud provider and its workforce are trustworthy.

[0043] Figure 1An example of a TEE utilized in the present invention is shown. The TEE can be implemented in a variety of ways, including as a modification to the CPU architecture, as an external component that plugs into a peripheral interface, or as a completely separate processor with appropriate interfaces and isolated hardware. This embodiment describes the TEE as a single system. However, the present invention also works when the TEE represents a properly configured set of systems. The use of the TEE refers to one or more properly configured systems. In the software portion 130 of the system 100, there is a TEE 102, which includes hardware 120 and software 130. The trusted applications are software that run inside the TEE. The TEE API 112, which is typically implemented in firmware and / or hardware, provides an interface to software running inside the TEE and to software outside the TEE that can want to become secure by running inside the TEE. The processor B 114 in the trusted hardware is the trusted portion of the processor on which the trusted applications and the TEE API execute. This can be a completely separate processor, or it can refer to the trusted state of a single processor. The memory 116 inside the TEE is trusted, and the trusted software 104 resides in the trusted memory 116 in the TEE 102. The TEE also includes attestation functionality 122. In the preferred embodiment, the attestation functionality is provided by a TPM. However, any hardware that is used to securely store a measurement of firmware and / or software can provide attestation functionality.

[0044] The trusted software in the TEE can include an entire operating system separate from the untrusted OS 108 outside the TEE 102. When the TEE is fine-grained, the OS in the TEE is often called an intermediary.

[0045] Outside the TEE, there are the operating system 108 and applications 106, as well as the memory 116 and processing power 110. The trusted software 104 does not implicitly trust any of these components. Both interfaces must be carefully implemented so as not to compromise the trust.

[0046] Figure 2A An example flowchart for provisioning a computation into a TEE according to an embodiment of the present invention is shown. Those skilled in the art recognize that the authorization of the computation to be run in the TEE should be done in a trusted environment, but can be done anywhere. The provisioning of a computation into a TEE begins with the selection of a target TEE, 204. The selection of a target TEE requires the selection of a system that contains a TEE capable of performing the secure computation. Figure 3 Figure 4 Figure 9A Figure 9B Figure 10A and Figure 10B ​​​​Examples of how to select a target TEE and what properties can be verified are given. In the preferred embodiment, the intended properties of the TEE are assumed to be known prior to selection. However, one skilled in the art recognizes that the intended properties can also be a function of the selected TEE. For example, if a computation is being provided that can run on multiple architectures, the required properties will likely depend on the target architecture. The authority 206 can restrict the computation to a particular TEE or a set of TEEs that meet certain criteria. In either case, the particular TEE and / or the criteria for verifying the TEE must be known prior to generating the authority. Selecting a target TEE and identifying the criteria are handled in step 204. One skilled in the art recognizes that these steps can be two separate steps.

[0047] The authority is generated in step 206. Typically, the authority restricts the set of TEEs that the authority can run a secure computation. In the preferred embodiment, the authority is a protected symmetric seed, as shown in Figure 6 In the preferred embodiment, each TEE has a key pair. The preferred protection mechanism is to encrypt the seed with the public key associated with the target TEE. Only the authorized TEEs have access to the private key. The private key can be locked in a TPM or some other hardware protected mechanism. The TPM specification defines the use of public key encryption as a seal operation, the result of the seal as seal data, and the use of the private key to decrypt the seal data as an unseal operation. The authority can contain an identifier that indicates which TEE the authority is for. If there is an identifier for it, the TEE will verify the authority.

[0048] In the preferred embodiment, a TPM is used to securely hold the private key. In the preferred embodiment, the private key is locked to the TPM and not allowed to be copied. One alternative is that the key is locked to the TPM and copying is allowed only with a password. However, one skilled in the art recognizes that to provide a single secret to multiple machines, the password must be managed very securely. One skilled in the art recognizes that the private key can also be held in some other location protected by a hardware root of trust. When using a TPM, the policies associated with the ability to access the private key to unseal the symmetric key can limit the set of systems or the configuration of the system that are authorized to run the secure computation. For example, in the preferred embodiment, the ability to access the public key can require that the PCRs match certain values, such as the values shown in Figure 7A The shown restrictions are explained in Figure 7A One skilled in the art recognizes that the authority can be arbitrarily complex. The authority can be incorporated in the seal data or can be separate metadata.

[0049] The authority is associated with the computation, 208. The steps of associating the authority with the computation are explained in Figure 6

[0050] ​A computation is generated with an associated authorization, 210. The authorization containing the sealing data can be inserted into the computation dynamically. The preferred embodiment inserts the authorization into a previously prepared computation or inserts the authorization at the time of computation preparation.

[0051] Finally, the computation is provisioned 212 to the target TEE. An example of a computation provided by the present invention is a secure VM. Figure 3 and Figure 4 ; Figure 9A and Figure 9B ; and Figure 10A and Figure 10B An example of configuring a secure VM into a TEE is given in

[0052] For some TEE models, the user of the TEE must explicitly verify that the TEE is valid before inserting the secret. In this model, the TEE is launched on the target system, but cannot be decrypted until the proof of validation is verified. The target system takes a measurement of the state of the TEE after it is secure or has the state of the TEE. This measurement is sent to the user. If the user likes the measurement, it authorizes the insertion of the secret, which enables the TEE to decrypt the computation. The secret effectively is the authorization. Without it, the computation will not run in this type of TEE. By having the TEE run in the target system, the association is implicit. The generation is the user computation acceptable value.

[0053] Figure 2B An example flow chart for configuring a computation into a TEE as an embodiment of the present invention is shown. The preparation of the computation for the TEE should be done in a trusted environment. Those skilled in the art recognize that the authorization to prepare the computation to be run in the TEE should be done in a trusted environment, but can be done anywhere. The provisioning starts at 230. The first step is to verify the TEE, 232. An example of verifying the target TEE is given in Figure 4 , Figure 10A and Figure 10BThe TEE is found. If the TEE cannot be verified, provisioning terminates at 246. Next, the integrity of the computation must be generated, 234. An example of the integrity of the computation is the integrity information 677 of Figure 7. In this description, it is assumed that the TEE in which the computation is performed will verify the integrity of the computation and cannot execute if there is a problem. Alternatively, the TEE can independently compute the integrity of the computation and return that information to the owner through some secure mechanism, where if the information is incorrect, the execution of the TEE will be terminated. Notably, for implementations where the owner must verify the integrity of the TEE that is executing, no sensitive information should be included in the TEE until it is verified. For either method, the integrity information is needed. Next, sealing data is generated, 236. The sealing data specifies whether the TEE is authorized to execute the computation. Those skilled in the art recognize that sealing data is a term specific to the TPM. When data is sealed by the TPM, a policy is associated with the sealing data that must be satisfied in order to access the sealed data. The computation information, the sealing data, and the integrity information are sent to the TEE, 238. In the preferred embodiment, the policy associated with the sealing data is used to verify that the TEE is authorized. The policy is enforced by the TPM. The TEE confirms that it is authorized to execute the computation, 240. If the TEE is not authorized, the execution terminates, 246. At 242, the integrity of the computation is verified. This can be done by the TEE independently computing the integrity information. It can then verify that it matches the integrity information it received, or it can send its computation back to the initiator through some secure channel and wait for their confirmation. In either case, if the integrity of the computation is not verified, the execution terminates, 246. Otherwise, the computation is executed, 244.

[0054] Figure 3 and Figure 4 A PEF (protected execution facility) alternative flow is shown, where there is no SM (security module) 980.

[0055] In particular, Figure 3 A KYOK (keep your own keys) flow is shown for the security model of embodiments of the invention.

[0056] For KYOK, the customer accepts the responsibility of running the enrollment protocol. Alternatively, the enrollment protocol must be run by someone the customer trusts. In this model, the customer controls the value of the platform configuration register 6 (PCR 6) they trust.

[0057] The 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 the customer 302 and the tool module 304.

[0058] The flow assumes that a VM 416 (not shown) with an Image-ID's mirror ID (identity) that can be a SVM has been loaded into the cloud infrastructure storage. To provide the secure VM 416, the customer module (or customer network) 302 requests the tool 304 to launch the VM Image_ID, 318. The tool module 304 requests secure provisioning from the cloud front end 306, 320. The cloud front end 306 acknowledges paid service to the tool module 304, 322. The tool module 304 requests the zone orchestrator 310 to create an instance of Image-ID, 324.

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

[0060] The client tool module 304 then validates the target system, 332.

[0061] If the target system is validated, the client tool 304 generates the sealed data 334. Not shown is the activation of a stop if the validation of the target system 332 fails. The tool module 304 sends the authorization to execute (Mach-ind, sealed data) 436 to the zone orchestrator module 310.

[0062] The zone orchestrator module 310 requests the Image-ID (mirror identity) from the cloud object store 308, 338. The cloud object store 308 returns the mirror associated with Image-ID to the zone orchestrator module 310, 340. The zone orchestrator 310 then inserts the sealed data into the mirror returned from the cloud object store 308, 342. The zone orchestrator then passes the mirror with the inserted sealed data to the target system with TPM 312, instructing the target system to execute the mirror, 344.

[0063] Figure 4Details of the validation target system (PEF) 332 of an embodiment of the present invention are shown. The trusted infrastructure 350 is shown as the customer module (or customer network) 302 and the tooling module 304. Also indicated is the untrusted cloud infrastructure 361.

[0064] At step 330, the validation target system is validated in response to the cloud front end 306 requesting that the tool module 304 register the machine. The validation TEE needs to validate the platform certificate and verify that the properties of the storage key are as expected. Then, the customer tool 304 performs the validation of the platform certificate and checks the storage and key properties, 460. Not shown is that if the platform certificate or storage key properties are incorrect, the validation target system returns a failure. This failure return can cause the tool 304 to request the regional orchestrator to provision a different target system. Continuing to refer to Figure 4 If the platform certificate and storage key are valid, the customer tool 304 generates a challenge and makes a credential, 462. The challenge consists of a credential that is a binary large object (blob) that can only be opened on the Mach-ind by the TPM (it is used to bring the challenge to the right system). The tool module 304 sends the challenge to the cloud front end 306, 464. The cloud front end 306 forwards the challenge 466 to the regional orchestrator 310. The regional orchestrator 310 forwards the challenge to the target system 312 with the TPM via the activation credential, 468. Not shown is that the target system 312 issues the activation credential to its TPM and receives a response. The target system 312 with the TPM sends the response to the challenge to the regional orchestrator 310, 470. The regional orchestrator forwards the response to the challenge to the cloud front end 306, 472. The cloud front end 306 then forwards the response to the challenge to the customer tool module 304, 474. Then, the tool module 304 checks the challenge response 476 and indicates success or failure.

[0065] Figure 5 A method of provisioning a machine in an embodiment of the present invention is shown.

[0066] One of the embodiments of the present invention utilizes the NV (non-volatile) location in the TPM to hold the password. The NV location of the NV_Location_X must be allocated (provisioned) with the proper policy before the machine is put into the infrastructure or as part of provisioning the machine into the cloud infrastructure, 540.

[0067] System 500 generates a storage key with a policy that requires a password and matches it with the password in NV_Location_X, 544. By definition, a storage key is a parent key, and a child key of the parent key is not necessarily a key. To use the storage key, a password is required, 544. The preferred attributes of the storage key should be fixed to the TPM, the key algorithm can be RSA 2048 (Rivest-Shamir-Adleman cryptosystem with 2048 bits), the key length 2048, the authorization is a pointer to NV_Location_X, and the platform hierarchy. The policy 544 also states that to use the storage key, PCR 6 must match. At each boot, a new password is assigned and given to ULTRAVISOR. In the preferred embodiment, the password is regenerated at each boot.

[0068] The third step 542 supplies is to generate a storage key with a previously calculated policy that indicates that a password is required to utilize the storage key in NV_Location_X. In step 544, the policy on the storage key requires a password to utilize and match it with the password in location NV_Location_X.

[0069] Maintaining the isolation and security of the computations and related data is the sole objective of ULTRAVISOR. System management continues to be the responsibility of the hypervisor. The hypervisor uses hypercalls to continue to manage the security sensitive facilities. When needed, ULTRAVISOR confirms that the actions requested by the hypervisor will not affect the security of any running SVMs (secure virtual machines).

[0070] Thus, as described above, in the example preferred implementation, the storage key is fixed to the TPM, the key algorithm is RSA, the key length is 2048, and other attributes. The ability to change the password is tied to the TPM platform authorization, which must be early terminated in the firmware boot process before any OS is loaded into the platform. The firmware in the machine must have the ability to assign a new random password each time the machine boots and pass that password to ULTRAVISOR or equivalent firmware.

[0071] Figure 6The layout of the ESM operand 691 is shown. The ESM operand 691 can be divided into two large areas, sensitive information 685 and payload 689. The sensitive area contains sealing data. Each sealing data enables an appropriately configured system to access information in the payload area 689 of the ESM operand. Sealing data 673 provides access to machine A, and sealing data 675 provides access to machine B. The unsealed data is a seed used to generate symmetric keys and HMAC keys. Everything in the payload area 689 except the HMAC is encrypted with symmetric keys generated from the seed. The first portion of the payload area 689 is integrity information 677. This is the information required for the PEF to verify the integrity of the computation. It consists of the hash of the kernel, the kernel command line, the initramf, and the RTAS area. In the preferred embodiment, the integrity information 677 is encrypted as specified. In alternate embodiments, the integrity information is not encrypted. Since the PEF verifies the integrity of the computation without contacting the creator, this information is generated when the secure computation is created and placed in the ESM operand. (For techniques where the owner / user of the computation is contacted to verify the integrity of the computation, the information must be computed by the TEE.) The remaining information in the payload area 689 is secrets 687. These are the customer data CD1 through CDn. Each of these is encrypted with a symmetric key generated from the seed. n where CD stands for "customer data". The preferred embodiment integrity protects 677 the kernel, the initramfs, the kernel command line, and the VM's RTAS. The boot disk should be encrypted. In the preferred embodiment, the first customer data block 679 contains the password to protect the root disk encrypted with a symmetric key. There can be zero or more customer data blocks after the encrypted passphrase. Each of the secrets 687 is encrypted with a symmetric key generated from the seed.

[0072] Figure 7A The value extended into PCR 6 786 is shown, which is used to verify the hardware configuration in embodiments of the invention. The preferred embodiment relies on secure and trusted boot to be able to confirm that the hardware and firmware configuration is valid. The value shown here is a set of preferred values. Alternate implementations can use different values. Any person of ordinary skill in the art understands that PCR 6786 represents the PCR used to hold this value, and no matter what PCR is used, it must also appear in the policy of the sealing data Figure 7AThe important thing to note is that this embodiment only identifies the actions of the changeable and / or unchangeable code necessary for the invention. The changeable bootloader 776 and changeable code 772 described herein are executed in a self-booting engine (SBE) and perform many actions not described herein. If security and trusted boot is enabled whenever signature verification fails, execution terminates. When the system is powered on, the unchangeable bootloader 772 is the first code to run. The unchangeable bootloader 772 extends the hardware key hash 788 and the secure boot jumper 790 into PCR 6 786. The hardware key hash 788 is a hash of the cryptographic key that is used to verify the signature on the cryptographic key that is used to verify the signature on the firmware. The secure boot jumper 790 identifies whether secure boot is enabled or disabled. The unchangeable code 772 loads and verifies the features of the changeable bootloader 776 before passing control to the changeable bootloader 776. If the signature is verified, the changeable code 772 extends the hash of the SB verification code 774, which is part of the changeable bootloader 776 that verifies the signature of other code, into PCR 6 786. It then passes control to the changeable bootloader 776. The changeable bootloader 776 verifies the host bootloader 778. The host bootloader 778 verifies the host boot initialization (init) 780. The host boot initialization 780 verifies the host boot extension (ext) 782. The host boot extension 782 extends the isolator 792 into PCR 6. The host boot extension 782 verifies the OPAL 784. The OPAL 784 extends the PEF enable bit 794 into PCR 6 786. Figure 7A It is described how the value of PCR 6 786 will be generated when the appropriately configured hardware is booted. In the preferred embodiment, the policy associated with the sealing data requires that PCr 6 match this value. Other values can be extended into PCR 6 (or another PCR) as needed, as the implementation requires to properly verify its configuration. The authorization policy required by the invention can be generated in the same way by software using a virtual TPM, an actual TPM, or reimplementing the operations performed by the TPM (not recommended) to extend values into physical or virtual PCRs. The policy specifies the state of the hardware key hash 788, the secure boot jumper 790, the hash of the SB verification code 774, the isolator 792 used by the firmware, and the PEF enable bit 794 required by the TEE to be authorized to run secure computations.

[0073] Figure 7BThis illustrates an embodiment of the invention using PEF, demonstrating the verification of authorization requirements 240 and the validation of the integrity of computation information 242. As previously described, secure computation begins as a normal VM. It executes an ESM ULTRAVISOR call to transition to the secure VM running in the PEF TEE, at which point validation begins, 750. In a preferred embodiment, the ESM Ultra call requires ESM operand 691, as... Figure 6 As shown. If the ESM operand does not exist, the ESM Ultra call fails. The TEE checks to see if it is authorized to execute the secure VM, 240. If not authorized, execution terminates, 766. If authorized, it checks to see if it is a valid TEE, 754. A valid TEE satisfies the sealing data policy specified by the SVM creator. For PEF, this check is performed by the TPM when the ULTRAVISOR requests the TPM to extract the seed from the sealed data. If the TEE does not meet these requirements, execution terminates, 766. Since the TEE is authorized and meets the requirements, it is able to access the symmetric seed required to generate the HMAC key, and if integrity is valid, it accesses 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 modified, 758. If the encrypted information has been modified, then execution terminates, 766. Otherwise, the symmetric key is generated, 760. This gives the TEE access to the information needed to verify the integrity of the computation, 242. If the computation has been modified, execution terminates, 766. Otherwise, the VM completes the conversion to SVM and executes, 764, which successfully ends the conversion, 768, the VM is now an SVM.

[0074] supply

[0075] Figure 8 An example Protected Execution Facility (PEF) of an embodiment of the present invention is illustrated. System 800 requests SVM (Secure Virtual Machine) execution (S0). Then, orchestrator module 852 selects a target machine from T0…Tn 864 (S1). Orchestrator module 852 requests SM (Security Module) 866 to verify the selected target machine, one of T0…Tn, 864 (S2). Figure 5In the middle, the selected target is Tn, 864. SM 866 requests information (platform certificate, storage key structure, HW (hardware) key hash) from the selected target system 864 (S3). SM 866 must verify that these are correct. To do the verification, it must have the public key of the platform's vendor. Once it acquires the key, it can store the key internally to speed up the verification process. SM 866 uses the public key of the vendor 860 to verify the machine (S3a), if it does not already have it, it will contact the vendor. SM device 866 sends the sealing data to the orchestrator module 852 (S4). The orchestrator module 852 retrieves a copy of the selected SVM 856 from the library 858, S5. Note that in the PEF, all SVMs start execution as VMs 854. In terms of the library 858, all the images are VMs 854. To simplify the description of the invention, those VMs 854 that can become SVMs have been marked as SVMs 856 in the library 858. As any person skilled in the art knows, the library 858 can be implemented to know the differences or not. The orchestrator inserts the sealing data into the copy of the SVM. The orchestrator module 852 deploys the copy of the SVM 856 onto the target system 864 (S6). For the cloud infrastructure 870, the target system 864 will typically not be known at the time of creation of the SVM 856. The cloud provider must be able to make changes to its infrastructure (e.g., to perform routine maintenance, upgrades, etc.) without affecting existing SVMs 856. One of the key properties of the PEF ESM (entry secure module) operand that enables easy integration into the cloud infrastructure 870 is that the HMAC (hash message authentication code) does not cover the sealing data. This means that the sealing data does not have to be generated at the same time as the rest of the ESM operand, allowing it to be inserted into the ESM operand just prior to execution. In the preferred embodiment, there can be placeholder sealing data in the ESM operand that will be overwritten by the sealing data of the selected machine. In an alternate embodiment, the image with the sealing data can be stored in the cloud object store 308. This would be useful in alternate embodiments where the TEE represents a set of systems. The cloud object store 408 can also store metadata indicating whether the sealing information already exists. When it does, the VM can be directly deployed to the TEE (set of machines). The ESM operand is a digital blob that is placed in a reserved section of the initramfs. It can also be placed in the ELF (executable and linkable format) section of the zImage (self-extracting compressed image) format file that contains the kernel. All the information necessary to verify the validity of the SVM is included in the ESM operand.

[0076] One example deployment model includes using a secure module (SM) 866 or equivalent function in the cloud provider's infrastructure to dynamically generate sealed data. In the present invention, the master secret can be owned / controlled by the cloud customer while the hardware is controlled / owned by the cloud provider. In this way, the cloud provider cannot extract information from the SM 866; thus, the cloud customer is safe in placing the secrets associated with its secure computation within 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 the present invention do not currently exist in the 4769, but can be added. Because the SM 866 is in the cloud provider's infrastructure, the cloud provider is safe in allowing it to run the necessary protocols to generate the sealed data for the target machine. The details of the cloud infrastructure will not be provided to the cloud customer. In this regard, it is important to note that in the PEF, all SVMs (secure virtual machines) start as NVMs (normal virtual machines) and early in their execution, they execute an ESM (enter secure mode) hypercall, which is a request to transition to a SVM. It is also important to note that from the cloud provider's perspective, NVM images and SVM images are identical. The cloud customer needs to inform the cloud provider that a particular image is for a SVM so that it will be handled correctly. In the description of the deployment, it is assumed that a VM (virtual machine) image has been created that will be converted to a SVM (secure virtual machine) 856 and the associated symmetric seed and associated metadata are already in the SM 866. Finally, given the identity of a given VM, the SM 866 will use the associated metadata to select the correct symmetric seed.

[0077] Further Figure 8The cloud user requests to create a running instance of the previously created SVM 856. The cloud infrastructure 870 selects a target machine 864 and extracts the platform certificate and storage key from the target. The infrastructure forwards the target machine 864 platform certificate and storage key to the SM 866 under the control of the customer and requests that the target machine 864 be registered with the SVM. In an alternative embodiment, the cloud infrastructure forwards only the target machine and requests that the SM register the target machine. The SM extracts the platform certificate and storage key from the target machine itself and then proceeds with the registration process. If the registration is successful, the SM 866 returns the sealing data for the target machine 866 to the cloud infrastructure 870. The infrastructure retrieves a copy of the image 856 from its library 858, uses the tools to insert the sealing data into the ESM operand of the SVM 856, and provides the copy of the image 856 containing the inserted sealing data to the target machine 864. Since the newly inserted sealing data is for the target machine 864, the VM will successfully convert into the SVM 856 if there are no other issues. This model assumes that the customer will have one seed per SVM 856 and that this seed will be valid on all target systems 866. Other models are possible, specifically, this embodiment is written as if the selected target 864 is a single machine. However, one of skill in the art recognizes that the target can be a single machine 864 or a group of machines 868 depending on how the infrastructure is provisioned. The sealing data can be inserted into the computation dynamically.

[0078] The registration protocol includes the following. The SM 866 or equivalent functionality must run the registration protocol. The registration protocol requires that the cloud infrastructure 870 pass the machine indicator (such as the IP (Internet Protocol) address) of the target machine, the platform certificate, the SVM indicator, and the storage key to the SM 866. In an alternative embodiment, the cloud provider passes only the machine indicator to the SM and the SM extracts the platform certificate and storage key itself. In either embodiment, the SM 866 will verify the platform certificate and check that the storage key attributes are correct. If the platform certificate and storage key pass the checks, the SM 866 will generate a random challenge and make a credential. It will then send the activation credential to the target machine 864, 862, which will execute on its TPM. The target machine 864 will return the challenge response. If the challenge response is valid, the SM 866 will generate the sealing data for the target machine 864 and return it to the cloud infrastructure 870 of the system 800.

[0079] For each target, the registration protocol must be run only once. Therefore, if the SM 866 maintains a database of registered machines, it can check to see if the current target machine is registered. If it is already registered, registration can be skipped and sealed data generated directly. Furthermore, each hardware key hash must be verified only once. The SM 866 can maintain a database of verified hardware key hashes. Before the system 800 runs the protocol to vendor 860 to verify the hardware key hash, the system 800 can check to see if the hash from the target machine 864 has already been verified. This is not as optimized for PEF because the hardware key hash is verified when the SVM is created, and not once for each execution. If the key hash becomes invalid, it must be cleared from the SM 866. When a machine is unprovided from the cloud infrastructure 870 of this system 800, the SM 866 must be notified that the machine is no longer a valid target, so it can clear its internal database. Finally, when the machine is deprovisioned, the primary seed in the TPM 862 must also be cleared to ensure that the deprovisioned machine cannot be used to extract secrets from a previously authorized SVM866.

[0080] Figures 9 and 10 illustrate the use of SM to verify the PEF (Protected Execution Facility) of a target system.

[0081] Figure 3 and 4 The initial approach illustrated requires infrastructure providers to expose details such as server IP (Internet Protocol) addresses to their users so that users can confirm the intended target machine is acceptable and configure computation to run on the intended target. The required API reduces the transparency of cloud provider infrastructure to cloud users.

[0082] Some cloud providers do not want to expose details of their infrastructure because it makes transparently managing their infrastructure significantly more complex. This invention achieves the same purpose, providing secure computing to a TEE without exposing infrastructure details to cloud customers through a properly configured SM. The SM must be under the control of the customer utilizing the TEE. The SM must be configured to run the previously described authentication process as shown in Figures 9 and 10. The customer must securely insert its secrets into the SM.

[0083] Figure 9A , Figure 9B , Figure 10A and Figure 10B This describes how the invention works in a PEF TEE. PEF and similar TEEs are designed to allow the TEE to prove the integrity of the computation without requiring separate verification with the TEE's user / owner. Figure 10A and Figure 10BHow the invention works with a TEE (such as AMD SEV) is described, which requires the owner / user of the secure computation to explicitly authorize the computation after it has been loaded into an active TEE. In both cases, the TEE and the computation are verified / validate. Figure 9A , Figure 9B , Figure 10A and Figure 10B It is not assumed that the customer has pre-loaded the VM image. The customer can pre-load the VM image, My-Image 482, which would imply that they already know the Image-ID 483.

[0084] Figure 9A A PEF (protected execution facility) alternative utilizing an SM (security module) in an embodiment of the invention is shown. This flow does not assume that the VM that can become an image-identified with an Image-ID has been loaded into the cloud object store 308. The trusted infrastructure 350 is the customer module 302, the tool module 304, and the security module (SM) 980. In this alternate embodiment, the SM 980 is trusted even though it is part of the untrusted cloud infrastructure 361.

[0085] To provide a secure VM, the customer module 302 requests that its trusted tool 304 launch the SVM My-Image, 318. The tool module 304 requests secure provisioning from the cloud front end 306, 320. The cloud front end 306 confirms that the paid service has been paid for to the tool module 304, 322.

[0086] Next, the tool module 304 uploads the VM My-Image that can be converted to a SVM to the cloud object store 308, 982. The cloud object store 308 then sends the Image-ID back to the tool module 304, 983. The tool module 304 sends a command to the SM 980 to securely insert the seed, metadata (which will be indexed by the Image-ID) into the SM, 984. Those skilled in the art recognize that the image can be pre-loaded, in which case the Image-ID is known. The tool module 304 requests that the regional orchestrator 310 create an instance of the Image-ID, 324.

[0087] The system 300 then selects a target machine as follows, 325. The regional orchestrator 310 selects a target machine request platform certificate and storage key from the selected target system 312 with a TPM, 326. The target system 312 with a TPM then returns the platform certificate and storage key to the regional orchestrator 310, 328.

[0088] The region orchestrator 310 then requests the SM 980 to register the machine (Machine-ind, platform certificate, and storage key), 330. The SM 980 is the trusted infrastructure 350 of the customer module 302.

[0089] The SM then runs the verification target system Mach-ind 933 with the target system 312 with TPM. If the verification fails, then termination is activated. If the verification succeeds, the SM 980 returns the authorization to execute (Machine-ind, sealed data) to the region orchestrator 310, 336.

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

[0091] Figure 9B The flow required to complete the verification target system Mach-ind 933 between the target system 312 with TPM and the SM 980 in embodiments of the present application is shown. As highlighted, the trusted infrastructure 350 includes the SM 980. The region orchestrator 310 and the target system 312 with TPM are external to the trusted infrastructure 350 in the untrusted cloud infrastructure 361.

[0092] The region orchestrator 310 sends and registers the machine (Machine-ind, platform certificate, and storage key) request to the SM 980, 330.

[0093] The SM 980 validates the platform certificate and performs a check on the storage key attributes, 460. The SM HyperProtect 980 generates a challenge and makes a credential, 462, which creates a binary large object (blob) called a credential that can only be invoked by the TPM verified in 460. The SM 980 sends the activation credential (Credential) to the target system with TPM 312, 468. The target system with TPM 312 then returns the challenge response to the SM 980, 470. The SM 980 checks the challenge response, 476. If the challenge response is incorrect, the activation terminates and a failure indication is returned from the process. If the challenge response is correct, the SM 980 generates the sealed data with the policy passed as metadata along with the seed, 334. The SM 980 returns the authorized execution (machine-in, sealed data) to the region orchestrator 310, 336.

[0094] Figure 10A An alternative security model for the TEE in an AMD processor with the SM provisioning embodiments of the present invention in a cloud infrastructure is shown. In Figure 9B In this case, the customer module 302 has their trusted infrastructure 350 and are using a cloud provider 361. Within the cloud provider, the customer is using a secure module (SM) 980, they have control of the secure module and are trusted 350. The rest of the cloud provider 361 infrastructure is untrusted. The customer module 302 sends a request to their trusted tool 304 to start the S VM My-Image. The tool 304 requests secure provisioning from the cloud front end 306, 320. The cloud front end 306 confirms that the service has been paid for, 322. The customer tool uploads their image, My-Image, to the cloud object store 982. The cloud object store 308 returns the image identifier of the stored image, Image-ID, to the customer tool 304, 383. The customer tool 304 securely inserts the seed (also called details or sensitive information) indexed by the Image-ID into the secure module (SM) 380, 384. This insertion can include additional metadata to be associated with the Image-ID. The customer tool 304 then requests that the region orchestrator 310 create an instance of the Image-ID, 324. The region orchestrator 310 selects a target machine 312 Mach-ind, 1065. Next, the region orchestrator 310 requests that the secure module 380 validate the target machine 312 Mach-ind, 1063. The secure module validates the target machine, 1025.

[0095] Figure 10B A verification target system (PEF) flow for the TEE in an AMD processor with the alternative model for the SM using embodiments of the present invention in a cloud infrastructure is shown. Figure 10BDetails of the request 1025 from the verification target machine are given. Figure 10A The verification Mach-Ind request is received by the security module (SM) 980 from the region orchestrator 310, 1063. Because the target system 312 contains an AMD process with a TEE, the Figure 10B The PSP 1003 has been extended to include in the target system, if it is authenticated, it can be trusted 350. It is important to note that the PSP is a subcomponent of the AMD processor, which is extended in Figure 10B to clarify the flow. Another important point is that the communication between the SM and the PSP is secure and cannot be forged in either direction. This description is an overview of the process. See the AMD white paper and technical literature available to those skilled in the art for details. The SM issues a request verification request to the target system 312, 1056, which passes the request to the PSP 1003, 1058. In response to the request, the PSP 1003 generates signature data and returns it to the processor 312, 1092, which returns it to the SM 980, 1011. The SM 980 extracts the certificate from the response, 1027, and requests verification from the AMD certificate authority 1054, 1094. The AMD certificate authority 1054 returns a verification response, 1096. If the certificate does not verify, the activation (request to run the secure VM in the TEE) terminates. If the certificate verifies, the SM 980 requests the region orchestrator 310 to load the VM image into the target system, 1029. The region orchestrator 310 sends the VM image associated with the Image-ID to the target system with a load image request, 1051. The target system 312 loads the VM image into the TEE (not shown). The SM 980 issues a request attestation of the VM image Image-ID to the target system 312, 1057. The target system 312 issues a request attestation 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 terminates. If the verification succeeds, the SM 980 gets the authorization (also known as the decryption key) and issues an insert authorization to the target system 312, 1091. The target system passes the insert authorization to the PSP 1003, 1097. The PSP 1003 inserts the authorization into the TEE. The SM 980 issues a boot system to the target system 312, 1093, which succeeds because the secure computation is authorized (the decryption key was successfully inserted).

[0096] Figures 11 to 15 Alternative configurations of the systems 100, 200, 300, 301, 500, and 800 that can be implemented are shown. In Figures 1 to 15The different features illustrated in the different drawings can be combined with each other in different examples.

[0097] Figure 11 Another hardware configuration of a system is shown in which there is an information processing / computer system 1100 according to the present application and which preferably has at least one processor or central processing unit (CPU) 1110 capable of implementing the techniques of the present application in the form of software programs for software intelligence as a service.

[0098] As previously mentioned, the trusted execution environment 102 can be implemented in a local infrastructure (e.g., a data center) such as Figure 11

[0099] The CPU 1110 is interconnected via a system bus 1112 to a random access memory (RAM) 1114, a read only memory (ROM) 1116, an input / output (I / O) adapter 1118 for connecting peripheral devices such as disk units 1121 and tape drives 1140 to the bus 1112, a user interface adapter 1122 for connecting a keyboard 1124, a mouse 1126, a speaker 1128, a microphone 1132, and / or other user interface devices to the bus 1112, a communication adapter 1134 for connecting the information processing 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.).

[0100] In addition to the above-described hardware / software environments, different aspects of the present application include computer-implemented methods for performing the above-described methods. As an example, such a method can be implemented in the specific environments discussed above.

[0101] Such a method can be implemented, for example, by operating a computer embodied by a digital data processing device to execute a sequence of machine-readable instructions. These instructions can reside in different types of signal-bearing media.

[0102] Thus, this aspect of the present application is directed to a program product comprising a signal-bearing storage medium tangibly embodying a program of machine-readable instructions executable by a digital data processor, such as the CPU 1110, and the hardware described above, to perform the methods of the present application.

[0103] This signal-bearing storage medium can include, for example, RAM contained within the CPU 1110, as represented by the fast-access storage device, for example.

[0104] ​Alternatively, the instructions can be embodied in another signal-bearing storage medium 1200, which is directly or indirectly accessible by the CPU 1110, such as a flash memory 1210 or an optical storage disk 1220 Figure 12

[0105] Regardless of the inclusion in the flash memory 1210, the optical disk 1220, the computer / CPU 1110, or elsewhere, the instructions can be stored on a variety of machine-readable data storage media.

[0106] Accordingly, the present application can be a system, a method, and / or a computer program product. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0107] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch cards or raised structures in

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

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

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

[0111] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0112] These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including

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

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

[0115] Referring now to the Figure 13 , a schematic diagram 1400 of an example of a cloud computing node is shown. Cloud computing node 1400 is only one example of a suitable cloud computing node and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the application described herein. Regardless, cloud computing node 1400 is capable of being implemented and / or performing any of the functionality set forth hereinabove. As previously described, trusted execution environment 102 can be implemented in a cloud infrastructure such as Figure 13 (And also Figure 14 and 15 ). In cloud computing node 1400, there are typically many

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

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

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

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

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

[0121] The program / utility 1440, having a set (at least one) of program modules 1442, can be stored in memory 1428 by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, can include an implementation of the embodiments of the application as embodied within an object code or an executable. Program modules 1442 generally carry out the functions and / or methodologies of embodiments of the application as described herein.

[0122] The computer system / server 1412 can also communicate with one or more external devices 1414 such as a keyboard, a pointing device, a display 1424, etc.; one or more devices that enable a user to interact with computer system / server 1412; and / or one or more devices that enable computer system / server 1412 to communicate with one or more other computing devices. Such communication can occur via Input / Output (I / O) interfaces 1422. Still yet, computer system / server 1412 can communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet) via network adapter 1420. As depicted, network adapter 1420 communicates with the other components of computer system / server 1412 via bus 1418. It should be understood that although not specifically shown, other hardware and / or software components could be used in conjunction 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 archival storage systems, etc.

[0123] Referring now to FIG. 15, Figure 14 depicts an illustrative cloud computing environment 1550. As shown, cloud computing environment 1550 includes one or more cloud computing nodes 1400 with which a cloud consumer can engage with to access cloud computing resources. Nodes 1400 can communicate with one another. They can be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment 1550 to offer infrastructure, platforms and / or software as services with Figure 14 the types of computing devices 1554A-N shown in FIG. 15 are intended to be illustrative only and that cloud computing nodes 1400 and cloud computing environment 1550 can communicate with any type of computerized device over any type of network and / or network addressable connection (e.g., using a web browser).

[0124] Referring now to FIG. 16, Figure 15 a set of functional abstraction layers provided by cloud computing environment 1550 Figure 14 is shown. It should be understood that the components, layers, and functions shown in FIG. 16 are intended to be illustrative only and that embodiments of the application are not limited thereto. As depicted, the following layers and respective functions are provided: Figure 15

[0125] Hardware and software layer 1660 includes hardware and software components. Examples of hardware components include mainframes, in one example IBM® zSeries® computers; RISC (Reduced Instruction Set Computer) architecture based servers, in one example IBM® pSeries® computers; IBM® xSeries® computers; IBM® BladeCenter® servers; Storage devices; Networks and networking components. Examples of software components include network application server software, in one example IBM® WebSphere® application server software; and database software, in one example IBM® DB2® database software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation registered in many jurisdictions worldwide). IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation registered in many jurisdictions worldwide).

[0126] ​​​​​​Virtualization layer 1662 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers; virtual storage; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients.

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

[0128] Workloads layer 1666 provides examples of functionality for which the cloud computing environment can be utilized. Examples of workloads and functions which can be provided from this layer include: mapping and navigation; software development and lifecycle management; virtual classroom education delivery; data analysis processing; transaction processing; and, more specifically to the present invention, API and runtime system components for generating search autocomplete suggestions based on contextual input.

[0129] Many of the attendant features and advantages of this application will be appreciated from the following detailed description in connection with the attached drawings, and it will be understood that various modifications can be made without departing from the spirit and scope of the application. Accordingly, the application is not limited to the precise details of construction and operation as set forth herein, as such modifications are intended to be included within the scope of the present application.

[0130] It should be understood that the application 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 application is capable of other embodiments and of being practiced or being carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0131] As such, those skilled in the art will appreciate that the conception, upon which this disclosure is based, can readily be utilized as a basis for the designing of other structures, methods and systems for carrying out the several purposes of the present application. It is important, therefore, that equivalent constructions that do not depart from the spirit and scope of the present application are intended to be encompassed within the scope of the claims appended hereto. Accordingly, while the application is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and will be described below in detail. It should be understood, however, that there are many variations and modifications of the application and that the application can be practiced otherwise than is specifically described.

Claims

1. A method for generating computations such that they will be executed in a target Trusted Execution Environment (TEE), comprising: Select the target TEE, wherein the target TEE is in a cloud or on-premises infrastructure; The security module SM generates an authorization satisfied by the target TEE, wherein the SM stores a list of previously generated authorizations, wherein the SM is used as part of the cloud or on-premises infrastructure, wherein detailed information about the target TEE is only revealed to the SM, and wherein the SM does not regenerate authorizations if authorizations have already been generated for the target TEE. The authorization is associated with the computation performed in the authorized target TEE, wherein at least a portion of the computation is encrypted, and encrypting a portion of the computation includes encrypting information required to check the integrity of the computation, wherein the authorization restricts the computation to a specific TEE among a plurality of TEEs; Generate the computation with associated authorization that can be executed in the target TEE; and The calculations generated by the supply.

2. The method according to claim 1, further comprising: Select the valid attributes to be incorporated into the authorization of the target TEE.

3. The method according to claim 1, wherein, Associating the authorization with the computation includes dynamically inserting information into the computation.

4. The method according to claim 1, wherein, The client securely inserts a secret into the SM, wherein the secret includes metadata indicating which secure computation the secret is associated with.

5. The method according to claim 4, The customer has control over the SM.

6. The method according to claim 1, in, The SM inserts the authorization into the target TEE.

7. A system for generating computations such that they will be executed in a target Trusted Execution Environment (TEE), comprising: Memory that stores computer instructions; as well as A processor configured to execute the computer instructions to perform the operation of the method according to any one of claims 1 to 6.

8. A computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being readable and executable by a computer to cause the computer to perform operations according to any one of claims 1 to 6.

9. A system for generating computations such that they will be executed in a target trusted execution environment (TEE), comprising means for performing operations of the method according to any one of claims 1 to 6.

Images