PROVIDING SECURE / ENCRYPTED VIRTUAL MACHINES IN A CLOUD INFRASTRUCTURE

Abstract

Method for generating a computation such that it is executed in a trusted target execution environment, TEE, (100) wherein the method comprises: selecting (204) the target TEE; providing access of the target TEE to a private key; generating (206) an authorization satisfied by the target TEE, wherein the authorization includes a symmetric seed, wherein prior to generating the authorization, attributes are selected to be included in the authorization for the authorized target TEE; associating (208) the authorization with the computation executed in the authorized target TEE; generating (210) the computation with the associated authorization; wherein generating the authorization includes encrypting the symmetric seed executed in the authorized target TEE using a public key specific to the authorized target TEE;wherein the private key is required to decrypt the encrypted symmetric seed value which was encrypted with the public key, such that the authorization restricts the computation to the target TEE from a plurality of TEEs in a provider's infrastructure; and wherein a security module, SM, is used to generate the authorization, and wherein a customer securely inserts secret information into the SM, thereby preventing the provider from accessing the secret information, wherein secret information includes metadata indicating which secret information the secure computation is associated with, and wherein the SM is used as part of the infrastructure outside the plurality of TEEs;wherein the target TEE is running on a system that is validated by the SM by the SM sending a validation question and credential to a Trusted Platform Module (TPM) of the system and verifying a response to the validation question from the TPM, wherein detailed information about the cloud infrastructure or detailed information about the target TEE is disclosed only to one security module (SM), thereby not providing any details about the infrastructure to the customer.

Description

BACKGROUND

[0001] The invention relates to an embodiment of a method, a device and a system for secure / encrypted virtual machines and in particular, but not limited to, a method, a device and a system for providing secure / encrypted virtual machines in a cloud infrastructure.

[0002] Cloud computing is a crucial aspect of a company's infrastructure. Cloud infrastructures can be private, public, or hybrid. One of the biggest challenges for hybrid and public clouds is the trust boundary imposed by the company on the cloud provider and its staff. While cloud computing is growing significantly, trust remains a major obstacle. Most cloud infrastructures assume that the cloud provider and its employees are trustworthy.

[0003] A major obstacle to the adoption of cloud computing is therefore security. This necessitates the provision of 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 offer security in cloud computing without requiring trust in the cloud provider. SUMMARY

[0004] In view of the aforementioned problems as well as further problems, disadvantages and impairments of the above-mentioned prior art, an exemplary aspect of the disclosed invention provides a method, a device and a system for providing secure / encrypted virtual machines in a cloud infrastructure.

[0005] According to one embodiment of the present invention, a method for generating a computation that is executed in a targeted trusted execution environment (TEE) comprises selecting the target TEE, generating an authorization that is satisfied by a TEE, assigning the authorization to the computation that is executed in the authorized TEE, and generating the computation with the associated authorization.

[0006] According to a further embodiment of the present invention, a system comprises a memory that stores computer instructions and a processor configured to execute the computer instructions to select a target TEE, generate an authorization that is fulfilled by a TEE, assign the authorization to the computation that is performed in the authorized TEE, and generate the computation with the associated authorization.

[0007] According to a further embodiment of the present invention, a computer program product comprises a computer-readable storage medium containing program instructions, wherein the program instructions can be read and executed by a computer to cause the computer to perform a procedure that includes selecting a target TEE, generating an authorization fulfilled by a TEE, assigning the authorization to the computation performed in the authorized TEE, and generating the computation with the associated authorization.

[0008] To facilitate a better understanding of the detailed description of the invention and to allow for a more accurate appreciation of this contribution to technology, some embodiments of the invention have been outlined in broad strokes. Naturally, there are further embodiments of the invention, which are described below and are the subject of the claims included herein.

[0009] It is understood that the invention, in its application, is not limited to the details of the construction and arrangement of the components listed in the following description or illustrated in the drawings. The invention may include further embodiments in addition to those described and may be implemented in various ways. It is further understood that the language and terminology used here, as well as the summary, serve descriptive purposes and should not be considered limiting.

[0010] It is therefore obvious to those skilled in the art that the concept on which this disclosure is based can readily be used as a basis for the design of other structures, methods, and systems for carrying out the various purposes of the present invention. It is therefore important that the claims be considered in light of the fact that they encompass this equivalent structure without deviating from the idea and scope of the present invention. List of characters

[0011] The exemplary aspects of the invention are better understood by reference to the following detailed description of the exemplary embodiments of the invention with reference to the drawings. Fig. Figure 1 illustrates an example of a TEE (trusted execution environment) as used in the present invention. Fig. Figure 2A illustrates an exemplary flowchart of an embodiment of the present invention. Fig. Figure 2B illustrates an exemplary flowchart of an embodiment of the present invention. Fig. Figure 3 illustrates a flowchart for “Keep your own key” for an alternative security model of an embodiment of the present invention in a cloud infrastructure. Fig. Figure 4 illustrates a flowchart for verifying the target system (i.e., the protected execution facility (PEF) system) for the “Keep your own key” model of an embodiment of the present invention in a cloud infrastructure. Fig. Figure 5 illustrates a method for provisioning in an embodiment of the present invention. Fig. Figure 6 illustrates a layout of the ESM operand (ESM = enter secure mode). Fig. Figure 7A illustrates values ​​that are stored in the PCR 6 (platform configuration register) for validating the hardware configuration in an embodiment of the present invention. Fig. Figure 7B illustrates validating the calculation in one embodiment of the present invention. Fig. Figure 8 illustrates an example of a protected implementation device (PEF) of an embodiment of the present invention. Fig. Figure 9A illustrates an alternative security model that uses a security manager of an embodiment of the present invention in a cloud infrastructure. Fig. Figure 9B illustrates the flowchart for verifying the target system (i.e., the Protected Execution Device (PEF) system) for the alternative model that uses a SM of an embodiment of the present invention in a cloud infrastructure. Fig. Figure 10A illustrates an alternative security model that uses a SM to provide a TEE in an AMD processor (AMD = ADVANCED MICRO DEVICES) of an embodiment of the present invention in a cloud infrastructure. Fig. Figure 10B illustrates the flowchart for verifying the target system (i.e., the protected execution device (PEF) system) for a TEE in an AMD processor (AMD = ADVANCED MICO DEVICES) for the alternative model that uses an SM of an embodiment of the present invention in a cloud infrastructure. Fig. Figure 11 illustrates an exemplary hardware / information processing system for integrating the exemplary embodiment of the present invention. Fig. Figure 12 illustrates a signal-carrying storage medium for storing machine-readable instructions of a program that implements the method according to the exemplary embodiment of the present invention. Fig. Figure 13 shows a cloud computing node according to an exemplary embodiment of the present invention. Fig. Figure 14 shows a cloud computing environment according to an exemplary embodiment of the present invention. Fig. Figure 15 shows abstraction model layers according to an exemplary embodiment of the present invention. DETAILED DESCRIPTION

[0012] The invention is described below with reference to the figures shown, in which identical reference numerals consistently refer to identical parts. It should be noted that, as is common practice, the various features of the drawing are not necessarily to scale. For the sake of clarity, the dimensions of the various features may be enlarged or reduced as desired. Exemplary embodiments are provided below for illustration purposes, which do not limit the claims. Furthermore, it should be noted that the steps can be carried out in different sequences, in combination, or simultaneously. Moreover, each of the structures and embodiments shown can be modified or combined.

[0013] As previously mentioned, a major obstacle to the adoption of cloud computing is security. The cloud provider has access to all information used in a running container or VM (virtual machine). Various CPU (central processing unit) manufacturers have therefore modified their architectures to allow for the creation and execution of private computations. These architectural changes can be generally referred to as a Trusted Execution Environment (TEE). This invention also supports a TEE that is part of a cloud node or cloud infrastructure, but is not integrated into a specific CPU architecture.

[0014] Processor manufacturers provide cloud providers with tools to close the trust gap by creating Trusted Execution Environments (TEEs) that offer hardware support for secure execution. TEEs divide a processor or process into secure and insecure areas. A TEE can be classified by its "granularity," meaning it can be either coarse-grained or fine-grained. Coarse-grained TEEs operate, for example, at the level of a VM (virtual machine) or processor, while fine-grained TEEs protect only a process or a single execution strand. Examples of coarse-grained TEEs include IBM Secure Service Containers™, ARM (Advanced RISC (Reduced Instruction Set Computer) Machines) TrustZone™ (some do not consider this a TEE), IBM™ Protected Execution Facility (PEF), and AMD™ Secure Encrypted Virtualization (SEV).Intel™ Software Guard Extension (SGX) is an example of a fine-grained TEE. Intel has announced its intention to provide coarse-grained support. All TEEs are trustworthy because the code running in the secure partition is subject to hardware requirements, and the user has the ability to verify the correctness of the hardware.

[0015] Most TEEs also offer some form of attestation. The lack of attestation, along with certain other features, is why the currently available ARM TrustZone™ is excluded as a TEE. However, an ARM processor can be used with an external TPM, which can provide some form of attestation. The procedures and entities for providing attestation vary. Attestation allows a remotely authorized party to ensure that the attributes of the TEE are verified; this includes determining what software is currently running in the TEE and / or verifying the firmware / software foundation of the TEE. Attestation allows a TEE user to verify critical properties of the environment in which their code or confidential information is running.The development of TEEs (Technical Execution Systems) assumes that an attacker can physically possess, control, or access the system / unit / PC and its processor. The goal is to enable confidential or secure computing in the event of access or control by an attacker. The architectural changes introduced by TEEs provide protection against unauthorized access.

[0016] Since many cloud infrastructures require the provider to be trustworthy, using a TEE to provide confidential data processing still presents a challenge, even with these capabilities.

[0017] The present invention identifies, among other features, a set of protocols and components which, when activated and used in a cloud infrastructure, enable the cloud infrastructure customer to use the infrastructure without sharing their confidential information with the cloud provider. The present invention provides a set of protocols that allow the user to utilize the protected execution equipment or other coarse-grained TEEs without having to trust the cloud provider.

[0018] The present invention is described with reference to the protected execution element (PEF) of a TEE. The PEF supports secure computations, which are referred to as secure virtual machines (SVMs). All SVMs begin execution as normal VMs. During their initialization, they execute an ESM call (ESM = enter secure mode) to an ULTRAVISOR, which is a request to transition from a normal virtual machine to a secure virtual machine. The PEF requires that a properly configured platform has a TPM and is running with secure and trusted boot enabled.

[0019] The TPM used in the present embodiment is hardware used to store measurement values ​​for a verification function. The verification function can be integrated into a processor or implemented externally in the processor architecture. This is referred to as a TPM-PCR, which represents a trusted mechanism for recording measurement values.

[0020] The present invention utilizes a TPM (Trusted Platform Module) and TEE hardware implemented in a cloud infrastructure. There are two models for using a TEE in a cloud infrastructure: BYOK (Bring Your Own Key) or KYOK (Keep Your Own Key). BYOK requires a key vault controlled by a cloud user, such as an SM (Security Module) 866 within the cloud infrastructure, so that the user does not have to disclose their key to the cloud provider. Examples of Security Modules 866 include HSMs (Hardware Security Modules) such as the IBM 4769 Cryptographic Coprocessor™, IBM HyperProtect™, IBM Z Secure Service Container™, IBM Z Secure Execution™, a TEE, or even a TPM. The sensitive information can be stored in a user-controlled key vault.For KYOK, on ​​the other hand, it is necessary that the cloud provides the cloud user with detailed information about its infrastructure.

[0021] Cloud computing is a crucial aspect of a company's infrastructure. Cloud infrastructures can be private, public, or hybrid. As mentioned earlier, one of the biggest challenges for hybrid and public clouds is the company's reliance on the cloud provider and its staff. While cloud computing is growing significantly, trust remains a major obstacle. Most cloud infrastructures assume that the cloud provider and its employees are trustworthy.

[0022] Fig. Figure 1 illustrates an example of a TEE as used in the present invention. A TEE can be implemented in various ways, for example, as a modification of the CPU architecture, as an external component connected to a peripheral interface, or as a completely separate processor with appropriate interfaces and isolation hardware. In this embodiment, a TEE is described as a single system. However, this invention also works when a TEE represents a properly configured set of systems. The use of a TEE refers to one or more properly configured systems. In software area 130 of system 100 is the TEE 102, which comprises the hardware 120 and the software 130. Trusted applications are software that runs in the TEE.The APIs 112 of the TEE, which are often implemented in firmware and / or hardware, provide interfaces to the software running in the TEE, as well as interfaces to software outside the TEE that is intended to become secure by running in the TEE. The processor B 114 in the trusted hardware is the trusted part of the processor on which the trusted application and the APIs of the TEE run. This can be a completely independent processor or the trusted state of a single processor. The memory 116 in the TEE is trusted, and the trusted software 104 resides in the trusted memory 116 in the TEE 102. The TEE also includes an authentication function 122. In a preferred embodiment, the authentication function is provided by a TPM.However, any hardware used for the secure storage of firmware and / or software measurements can provide the authentication function.

[0023] The trusted software within the TEE can contain a complete operating system, separate from the untrusted operating system 108 outside of the TEE 102. If the TEE is fine-grained, the operating system within the TEE is often referred to as a shim.

[0024] Outside the TEE are an operating system 108 and applications 106, as well as a memory 116 and a processing functionality 110. The trusted software 104 does not implicitly trust any of these components. The interfaces between the two must be carefully implemented to avoid compromising trustworthiness.

[0025] Fig. Figure 2A illustrates an exemplary flowchart for deploying a computation in a TEE as an embodiment of the present invention. It is obvious to those skilled in the art that preparing authorization for a computation to be performed in a TEE should be done in a trusted environment, but can be done anywhere. Deploying a computation in a TEE begins with selecting the target TEE (204). To select a target TEE, a system must be chosen that contains a TEE capable of performing the secure computation. Fig. 3, Fig. 4, Fig. 9A, Fig. 9B, Fig. 10A and Fig. Figure 10B is an example of how a target TEE is selected and which attributes can be checked. In the preferred embodiment, it is assumed that the expected attributes of the TEE are known before selection. However, it is obvious to those skilled in the art that the expected attributes can also be a function of the selected TEE. For example, if a computation is provided that can be executed on multiple architectures, the required attribute is likely to depend on the target architecture. Authorization 206 can restrict the computation to a specific TEE or to a set of TEEs that meet certain criteria. In any case, the specific TEE and / or the criteria used to validate the TEE must be known before generating the authorization. In step 204, the target TEEs are selected and the criteria are identified. It is obvious to those skilled in the art that this can also be a two-step process.

[0026] In step 206, the authorization is generated. The authorization generally restricts the set of TEEs that are authorized to perform the safe computation. In the preferred embodiment, the authorization is, as in Fig. Figure 6 illustrates a protected symmetric seed value. In the preferred embodiment, each TEE has a key pair. The preferred protection mechanism is to encrypt the seed value with a public key belonging to the target TEE. Only an authorized TEE has access to the private key. The private key may be contained in a TPM or another hardware-protected mechanism. In the TPM specification, encryption with a public key is defined as the sealing operation, the results of the sealing as sealed data, and decryption of sealed data with a private key as an unsealing operation. The authorization may include an identifier indicating which TEE the authorization applies to. If its identifier is present, the TEE validates the authorization.

[0027] In the preferred embodiment, a TPM is used to securely store the private key. In this embodiment, the private key is contained within the TPM, and duplication is not permitted. An alternative is that the key is contained within the TPM, and duplication is only possible with a password. However, it is obvious to those skilled in the art that the password must be managed very securely when a single piece of secret information is made available to multiple machines. It is also obvious to those skilled in the art that the private key could be stored elsewhere, protected by a hardware trust base. If a TPM is used, the policy governing the ability to access the private key to unlock the symmetric key can restrict the set of systems or the configuration of systems authorized to perform the secure computation.In the preferred embodiment, access to the public key may, for example, require a PCR with a specific value as in . Fig. 7A corresponds to the restriction shown. Fig. Section 7A explains. It is obvious to experts that permissions can be designed to be arbitrarily complex. The permission can be integrated into the sealed data or exist as separate metadata.

[0028] The authorization is assigned to a calculation (208). The step of assigning the authorization to the calculation is described in Fig. 6 explained.

[0029] The calculation is generated with the associated authorization (210). The authorization with the sealed data can be dynamically inserted into the calculation. The preferred embodiment inserts the authorization into a previously prepared calculation or inserts the authorization while the calculation is being prepared.

[0030] Finally, the calculation of the target TEE is provided (212). An example of a calculation provided by this invention is a safe VM. Examples of providing a safe VM in a TEE are given in the Fig. 3 and Fig. 4; Fig. 9A and Fig. 9B; as well as 10A and 10B are shown.

[0031] In some TEE models, the user must explicitly verify the TEE's validity before inserting secret information. In such a model, the TEE is initiated in the target system but cannot be decrypted until authentication has been verified. The target system determines a measurement value or knows the TEE's state after it has been secured. This measurement value is sent to the user. If the user accepts the measurement value, they authorize the insertion of the secret information, allowing the TEE to decrypt the calculation. The secret information constitutes the actual authorization. Without it, the calculation will not be performed in this type of TEE. The mapping is implicit when the TEE is executed in the target system. The generation process consists of the user calculating the acceptable values.

[0032] Fig. Figure 2B illustrates an exemplary workflow for deploying a computation to a TEE as an embodiment of the present invention. A computation for a TEE should be prepared in a trusted environment. It is obvious to those skilled in the art that preparing authorization for a computation to be executed in a TEE should be done in a trusted environment, but it can be done anywhere. Deployment begins at 230. The first step is to verify the TEE (232). Examples of verifying a target TEE are given in the Fig. 4, Fig. 10A and Fig. 10B is shown. If the TEE cannot be verified, the provisioning ends (246). Next, the integrity information for the computation must be generated (234). An example of integrity information for the computation is the integrity information 677 from Fig. 7. This description assumes that the TEE in which the computation is performed verifies the integrity of the computation and does not execute it if a problem is detected. Alternatively, the TEE can independently calculate the integrity of the computation and return this information to the owner via a secure mechanism, terminating the TEE's execution if the result is incorrect. It should be noted that in implementations where the owner must verify the integrity of the executing TEE, no sensitive information should be included in the TEE until this verification has been completed. Integrity information is required for both approaches. Next, the sealed data (236) is generated. The sealed data indicates whether the TEE is authorized to perform the computation.It is obvious to experts that sealed data is a specific term in the context of the TPM. When data is sealed by a TPM, a policy is assigned to the sealed data, which must be met to access it. The computation information, the sealed data, and the integrity information are sent to the TEE (238). In the preferred embodiment, the policy associated with the sealed data is used to validate that the TEE is authorized. This policy is executed by the TPM. The TEE confirms that it is authorized to perform the computation (240). If the TEE is not authorized, the execution terminates (246). The integrity of the computation is verified (242). This can be done by the TEE independently computing the integrity information.It can then check whether there is a match with the received integrity information, or it can send its calculations back to the initiator via a secure channel and wait for confirmation. In both cases, execution terminates if the integrity of the calculation is not verified (246). Otherwise, the calculation is performed (244).

[0033] The Fig. 3 and Fig. Figure 4 illustrates alternative operations of a PEF (protected execution device) where no SM (safety module) 980 is present.

[0034] In particular Fig. Figure 3 illustrates a KYOK (Keep Your Own Key) process for the security model of an embodiment of the present invention.

[0035] For KYOK, the customer assumes responsibility for executing the registration protocol. Alternatively, the registration protocol must be executed by someone the customer deems trustworthy. In this model, the customer controls the value of Platform Configuration Register 6 (PCR6), which they consider trustworthy.

[0036] System 200 is divided into a trusted infrastructure 350 (highlighted) and an untrusted cloud infrastructure 361 (other structures not highlighted). The trusted infrastructure 350 (highlighted) consists of the customer 302 and the tool module 304.

[0037] This process assumes that a VM 416 (not shown) with an ID (identifier) ​​of an image that can become an SVM has already been loaded into the cloud infrastructure's storage. To provision a secure VM 416, the customer module (or customer network) 302 requests that tool 304 start the VM with image ID 318. Tool module 304 requests a secure provision 320 from the cloud's front end 306. The cloud's front end 306 confirms the paid service 322 to tool module 304. Tool module 304 then requests that the scope orchestrator 310 create an instance with image ID 324.

[0038] System 200 then selects a target machine 325 as follows. The domain orchestrator 310 selects a target machine, represented by Mach-Ind, and requests the platform certification and storage key 326 from the target system using the TPM 312. It is obvious to experts that existing cloud infrastructures are capable of selecting an available machine from their infrastructure from a list of requirements. Any technique for selecting such a machine is permissible. It is obvious to experts that the list of attributes for selection must be supplemented with the attributes belonging to the target TEE. It is further obvious to experts that Mach-Ind can be an IP address or other information that can be used to identify a machine in a provider's infrastructure.The target system with TPM 312 then sends the platform certificate and control key 328 back to the area orchestrator 310. The area orchestrator 310 requests that the customer's tool module 304 register the target machine with "Register this machine" (machine index, platform certificate, memory key) 330.

[0039] The customer's tool module 304 checks the target system 332.

[0040] When the target system is checked, the customer tool 304 generates the sealed data 334. Not shown is that activation ends if the check of the target system 332 fails. The tool module 304 sends an authorization execution (Mach-Ind, sealed data) 436 to the area orchestrator module 310.

[0041] The area orchestrator module 310 requests the image ID (image identifier) ​​338 from the cloud object store 308. The cloud object store 308 sends the image 340 corresponding to the image ID back to the area orchestrator module 310. The area orchestrator 310 then inserts the sealed data 342 into the image returned by the cloud object store 308. The area orchestrator then forwards the image with the inserted sealed data to the target system with the TPM 312 and instructs the target system to execute the image 344.

[0042] Fig. Figure 4 illustrates the details of verifying the target system 332 (PEF) of an embodiment of the present invention. The trusted infrastructure 350 consists of the customer module (or customer network) 302 and the tool module 304. The untrusted cloud infrastructure 361 is also shown.

[0043] The target system is verified when the cloud's front end (306) requests that the tool module (304) register this machine at step 330. To verify the TEE, the platform certificate must be checked, and the storage key properties must be verified as expected. The customer tool then performs a 304 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, an error will be returned during the target system verification process. This error message can prompt the tool (304) to request that the scope orchestrator provision a different target system. Continue with Fig. 4: If the platform certificate and storage key are valid, the customer tool 304 generates a verification question and creates the credentials 462. The verification question contains the credential, which is a binary blob that can only be opened by the TPM in Mach-Ind (which is used to deliver the verification question to the correct system). The tool module 304 sends the verification question 464 to the cloud front end 306. The cloud front end 306 forwards the verification question 466 to the scope orchestrator 310. The scope orchestrator 310 forwards the verification question to the target system 312 via "Enable Credential" 468 to the target system with the TPM 312. Not shown is that the target system 312 sends "Enable Credential" to its TPM and receives a response. The target system with the TPM 312 sends the answer to test question 470 to the area orchestrator 310.The area orchestrator forwards the answer to check question 472 to the cloud's front end 306. The cloud's front end 306 then forwards the answer to check question 474 to the customer tool module 304. Tool module 304 then checks the answer to check question 476 and indicates success or failure.

[0044] Fig. Figure 5 illustrates a method for providing a machine in an embodiment of the present invention.

[0045] In one embodiment of the present invention, an NV storage location (NV = non-volatile) in the TPM is used to store a password. Before the machine is integrated into an infrastructure or as part of a deployment of a machine in the cloud infrastructure, a suitable policy must be assigned (provisioned) to the NV storage location of NV_LOCATION_X (540).

[0046] System 500 generates a memory key with a policy that requires a password matching the password of NV_LOCATION_X 544. By definition, a memory key is a parent key; a child key of a parent key need not be a key. A password (544) is required to use the memory key. The preferred attributes of the memory key should be defined in the TPM. The key algorithm can be RSA 2048 (Rivest-Shamir-Adleman 2048-bit cryptosystem), the key length is 2048 bits, the authorization is a pointer to NV_LOCATION_X, and the platform hierarchy is also specified. Policy 544 further specifies that PCR 6 must match to use the memory key. A new password is assigned and passed to the ULTRAVISOR at each boot. In a preferred embodiment, the password is regenerated at every boot.

[0047] The third step (542) of the deployment process involves generating the storage key using the previously calculated policy, which specifies that a password is required to use the storage key for NV_LOCATION_X. The storage key policy specifies that a password must be used and that it must match the password in NV_LOCATION_X from step 544.

[0048] The sole purpose of ULTRAVISOR is to ensure the isolation and security of the computation and its associated data. System administration remains with the hypervisor. The hypervisor uses ultra-calls to continue managing security-related facilities. If necessary, ULTRAVISOR verifies that the action requested by the hypervisor will not compromise the security of a running SVM (secure virtual machine).

[0049] As mentioned previously, in a preferred example implementation, the storage key is set in the TPM. The key algorithm is RSA, the key length is 2048, and other attributes are also included. The ability to change the password is tied to the TPM platform's authorization, which must be completed early in the firmware's boot process, before an operating system is loaded onto the platform. The firmware in the machine must be able to assign a new random password at each boot and forward this password to the ULTRAVISOR or equivalent firmware.

[0050] Fig. Figure 6 illustrates a layout of an ESM operand 691. The ESM operand 691 can be divided into two main areas: the sensitive information 685 and the payload 689. The sensitive area contains sealed data. The sealed data allows a properly configured system to access information in the payload area 689 of the ESM operand. The sealed data 673 allows access to machine A, and the sealed data 675 allows access to machine B. The unsealed data consists of the seed value, which is used to generate a symmetric key and an HMAC key. All data in the payload area 689, except for the HMAC, is encrypted with the symmetric key generated from the seed value. The first part of the payload area 689 consists of the integrity information 677. This information is required by the PEF to verify the integrity of the computation.They consist of hash values ​​of the kernel, the kernel command line, initramfs (first 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 validates the integrity of the computation without contacting the creator, this information is generated when the secure computation is created and stored in the ESM operand. (In technologies where the owner / user of the computation is contacted to verify the computation's integrity, the information must be computed by the TEE.) The remaining information in payload area 689 is the secret information 687. This is stored under CD1 to CD2. nrepresented, where CD stands for "customer data". In the preferred embodiment, the integrity protects the kernel, initramfs, kernel command line, and RTAS of the VM (677). The boot disk should be encrypted. In the preferred embodiment, the first block of customer data 679 contains the key phrase that protects the root directory disk, which is encrypted with the symmetric key. There can be zero or more blocks of customer data after the encrypted key phrase. All secret information 687 is encrypted with the symmetric key generated from the seed value.

[0051] Fig. Figure 7A illustrates values ​​stored in the PCR 6786 for validating the hardware configuration in one embodiment of the present invention. The preferred embodiment relies on secure and trusted booting to confirm that the hardware and firmware configurations are valid. The values ​​presented here are a preferred set of values. Other values ​​may be used in a different implementation. It is obvious to those skilled in the art that the PCR 6786 is a PCR used to store the value, and that any PCR used also complies with the policy of sealed data (not in Fig. (as shown in Figure 7A) must appear in order for the verification to be performed. It is important to note that in this embodiment, only actions of modifiable and / or non-modifiable code required for the invention are identified. The modifiable boot loader 776 and the non-modifiable code 772 described herein are executed in the Self-Boot Engine (SBE) and perform numerous actions not described here. If secure and trusted booting is enabled, execution terminates as soon as a signature verification fails. When the system is powered on, the modifiable boot loader 772 is executed as the first code. The modifiable boot loader 772 stores the hash value of the hardware key 788 and the secure boot bridge 790 in PCR 6 786.The hash value of hardware key 788 is a hash value of the cryptographic keys used to verify the signatures in the cryptographic keys used to verify the signature in the firmware. The secure boot bridge 790 determines whether secure booting is enabled or disabled. Before control is passed to the modifiable boot loader 776, the immutable code 772 loads and verifies the signature of the modifiable boot loader 776. If the signature is verified, the immutable code 772 stores a hash value of the SB verification code 774 in PCR 6 786, where the SB verification code is part of the modifiable boot loader 776 that verifies the signature of other code. It then passes control to the modifiable boot loader 776. The modifiable boot loader 776 checks the host boot loader 778.Hostboot loader 778 checks hostboot initialization 780. Hostboot initialization checks hostboot extensions 782. Hostboot extension 782 places a separator 792 in PCR 6. Hostboot extension 782 checks OPAL 784. OPAL 784 places the PEF activation bit 794 in PCR 6 786. Fig. Figure 7A illustrates how the value of PCR 6 786 is generated when properly configured hardware is powered on. In the preferred embodiment, the policy associated with the sealed data requires that PCR 6 match this value. Other values ​​can be stored in PCR 6 (or another PCR) as desired, depending on what an implementation needs to properly verify its configuration. The authorization policy required in this invention can be created in the same way by storing values ​​in a physical or virtual PCR using software that utilizes a virtual TPM or an actual TPM, or by reimplementing (not recommended) the operations performed by a TPM.The policy specifies the status of the hash value of the hardware key 799, the secure boot bridge 790, the hash value of the SB verification code 774, the separator 792 used by the firmware, and the PEF activation bit 794, which are required for the TEE to be authorized to perform the secure computation.

[0052] Fig. Figure 7B illustrates confirming the authorization requirements 240 and verifying the integrity of the computation information 242 in an embodiment of the present invention that uses a PEF. As mentioned previously, the secure computation begins as a normal VM. An ESM call of the ULTRAVISOR is then executed to transition to a secure VM running in the PEF of the TEE. At this point, the validation (750) begins. In the preferred embodiment, the ESM-Ultra call requires, as shown in Fig. Figure 6 shows an ESM operand 691. If the ESM operand is not present, the ESM Ultra call fails. The TEE checks if it is authorized to execute the secure VM (240). If it is not authorized, execution terminates (766). If it is authorized, it checks if it is a valid TEE (754). A valid TEE meets the sealed data policy set by the SVM creator. For the PEF, this check is performed by the TPM when the ULTRAVISOR requests that the TPM 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 has access to the symmetric seed, which is needed to generate an HMAC key and—if the integrity is valid—a symmetric key. Next, the HMAC key is generated (756).The HMAC key is used to validate that the encrypted information in the ESM operand has not been modified (758). If the encrypted information has been modified, 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 transition to an SVM and performs an execution (764), thus successfully completing the transition (768); the VM is now an SVM. PROVIDE

[0053] Fig. Figure 8 illustrates an example of a protected execution device (PEF) of an embodiment of the present invention. The system 800 requests the execution of a safe virtual machine (SVM) (S0). Subsequently, the orchestrator module 852 selects a target machine from T0...Tn 864 (S1). The orchestrator module 852 requests the safety module (SM) 866 to validate the selected target machine, i.e., a machine selected from T0...Tn 864 (S2). Fig. S3 is the selected target Tn 864. The SM 866 requests information (platform certification, storage key structure, hash value of the hardware key) from the selected target system 864 (S3). The SM 866 must validate that this information is correct. To validate, it needs the platform provider's public key. Once it has the key, it can store it internally to speed up the validation process. The SM 866 validates a machine using the provider 860's public key (S3a); if it doesn't already have the key, it contacts the provider. The SM unit 866 sends sealed data to the orchestrator module 852 (S4). The orchestrator module 852 retrieves a copy of the selected SVM 856 from library 858 (S5). Note that all SVMs in the PEF begin execution as a VM 854. Regarding library 858, all images are VMs 854.To simplify the description of the invention, the VMs 854 that can become SVMs are labelled as SVMs 856 in library 858. It is obvious to those skilled in the art that library 858 can be implemented to recognize the difference. The orchestrator inserts the sealed data into the copy of the SVM. The orchestrator module 852 allocates the copy of SVM 856 to the target system 864 (S6). In cloud infrastructures 870, the target system 864 is generally unknown at the time SVM 856 is created. Cloud providers must be able to make changes to their infrastructure (e.g., daily maintenance, updates, etc.) without affecting the existing SVMs 856. One of the most important features of the PEF's ESM operand (ESM = Enter Secure Module), which enables easy integration into a cloud infrastructure 870, is that the HMAC (Hashing for Message Authentication Code) does not cover the sealed data.This means that the sealed data does not need to be created at the same time as the rest of the ESM operand, allowing it to be inserted into the ESM operand immediately before execution. In a preferred embodiment, the ESM operand can contain sealed placeholder data that is overwritten by the sealed data for the selected machine. In an alternative embodiment, the image containing the sealed data can be stored in cloud object storage 308. This would be useful in alternative embodiments where the TEE represents a set of systems. Cloud object storage 408 can also contain metadata indicating whether the sealed information already exists. If so, the VM can be directly allocated to the TEE (set of machines). The ESM operand is a digital blob stored in a reserved area of ​​initramfs.It can also be placed in an ELF section (ELF = executable and linkable format) of the zlmage format file (zlmage = self-extracting compressed image), which contains the kernel. All information required to verify the validity of the SVM is contained in the ESM operand.

[0054] An example of an implementation model involves using a Security Module (SM) 866 or an equivalent function in a cloud provider's infrastructure to dynamically generate sealed data. In the present invention, the secret master information can be owned or controlled by the cloud customer, while the hardware is owned or controlled by the cloud provider. In this way, the cloud provider cannot extract information from the SM 866; consequently, it is secure for the cloud customer to store secret information pertaining to its secure computations in the SM 866. An example of an SM that can be owned by a cloud provider but controlled by a customer is the IBM 4769. The functions described in this invention are not currently present in the 4769 but can be added.Because the SM 866 resides within the cloud provider's infrastructure, it is secure for the cloud provider to allow the SM to execute the necessary protocols to generate the sealed data for the target machine. No details about the cloud infrastructure are provided to the cloud customer. It is important to note that all SVMs (secure virtual machines) in the PEF initially run as NVMs (normal virtual machines). At the start of their execution, they make an ESM Ultra call (ESM = enter secure mode), which is a request to transition to an SVM. Furthermore, it is important to note that an NVM image and an SVM image are identical from the cloud provider's perspective. The cloud customer must inform the cloud provider that a particular image is intended for an SVM in order for it to be processed correctly.The implementation description assumes that the image of the VM (virtual machine) transitioning into an SVM (secure virtual machine) 856 has already been created and that the corresponding symmetric seed and metadata are already present in SM 866. Finally, it is assumed that, given the VM's identity, SM 866 selects the correct symmetric seed using the associated metadata.

[0055] With renewed reference to Fig. Figure 8 describes the general process for running an SVM 856. The cloud user requests that an execution instance of a previously created SVM 856 be created. The cloud infrastructure 879 selects a target machine 864 and extracts the platform certificate and storage key from the target machine. The infrastructure forwards the target machine 864, the platform certificate, and the storage key to the customer-controlled SM 866 and requests that the target machine 864 be registered for the SVM. In an alternative embodiment, the cloud infrastructure only forwards the target machine and requests the SM to 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 sends sealed data for the target machine 866 back to the cloud infrastructure 870.The infrastructure retrieves a copy of image 856 from its library 858, inserts the sealed data into the ESM operands in SVM 856 using the tool, and provides the copy of image 856 with the inserted sealed data to the target machine 864. Since the newly inserted sealed data is intended for target machine 864, the VM successfully transitions into SVM 856, provided there are no other issues. This model assumes that the customer has a seed value for each SVM 856 and that this seed value is valid on all target systems 866. Other models are possible, with this embodiment in particular being designed as if a selected target machine 864 were a single machine. However, it is obvious to those skilled in the art that a target machine can be either a single machine 864 or a set of machines 868, depending on how the infrastructure is deployed.The sealed data can be dynamically inserted into the calculation.

[0056] The registration protocol includes the following. The SM 866, or an equivalent function, must execute the registration protocol. For the registration protocol to work, the Cloud Infrastructure 870 must forward the machine indicator (e.g., the IP address (IP = Internet Protocol)), the platform certificate, the SVM indicator, and the storage key of the target machine to the SM 866. In an alternative embodiment, the cloud provider forwards only the machine indicator to the SM, and the SM extracts the platform certificate and storage key itself. In both embodiments, the SM 866 validates the platform certificate and verifies that the properties of the storage key are correct. If the result of the verification of the platform certificate and storage key is positive, the SM 866 generates a random check question and issues a credential.It sends "Activate authentication" to the target machine 864, which is to be executed on its TPM 862. The target machine 864 sends back the response to the verification question. If the response to the verification question is valid, the SM 866 generates sealed data for the target machine 864 and sends it back to the cloud infrastructure 870 of the present system 800.

[0057] The registration protocol only needs to be executed once for each target machine. If the SM 866 maintains a database of the registered machine, it can check whether the current target machine is registered. If it is already registered, it can skip the registration and generate the sealed data directly. Furthermore, each hardware key hash value only needs to be verified once. The SM 866 can maintain a database of validated hardware key hash values. Before the System 800 executes the protocol for the provider 860 to verify the hardware key hash value, the System 800 can check whether the target machine 864's hash value has already been validated. This isn't a significant optimization for the PEF, as hardware key hash values ​​are validated when the SVM is created, not even on every execution. If a key hash value becomes invalid, it must be deleted from the SM 866.When a machine is removed from the cloud infrastructure 870 of the present system 800, the SM 866 must be informed that the machine is no longer a valid target machine so that it can clean up its internal databases. Finally, the primary startup value in the TPM 862 must also be deleted when the machine is removed to ensure that the removed machine cannot be used to extract secret information from the previously authorized SVMs 866.

[0058] The Fig. 9 and Fig. Figure 10 illustrates a PEF (protected execution device) that uses an SM to verify the target system.

[0059] The one in the Fig. 3 and Fig. The original approach described in point 4 requires the infrastructure provider to disclose details such as the IP address (IP = Internet Protocol) of the servers to its users so they can confirm that the intended target machine is acceptable and configure the computation to run on the intended target machine. The required API makes the cloud provider's infrastructure less transparent to cloud users.

[0060] Some cloud providers are reluctant to disclose details of their infrastructure, as this significantly hinders transparent infrastructure management. The present invention achieves the same goal—providing secure computation to a TEE without disclosing infrastructure details to the cloud customer—by incorporating a suitably configured SM. The SM must be controllable by the customer using the TEEs. The SM must be configured to perform the verification processes described above, as outlined in the [reference to relevant documentation]. Fig. 9 and Fig. The process is carried out as shown in section 10. The customer must securely insert their confidential information into the SM.

[0061] The Fig. 9A, Fig. 9B, Fig. 10A and Fig. Figure 10B describes how the present invention functions in a PEF of a TEE. The PEF and similar TEEs are designed such that the TEE authenticates the integrity of the calculation without requiring separate verification with the user / owner of the TEE. Fig. 10A and Fig. Figure 10B describes how the present invention works with a TEE, e.g., an AMD-SEV, where the owner / user of the secure computation must explicitly authorize the computation after it has been loaded into a valid TEE. In both cases, both the TEE and the computation are authenticated / verified. Fig. 9A, Fig. 9B, Fig. 10A and Fig. 10B does not assume that the customer has previously loaded a VM image. Customers can preload a VM image, My-Image 482, which requires that they already know image ID 483.

[0062] Fig. Figure 9A illustrates the PEF alternative (PEF = Protected Execution Device) in which a security module (SM) is used in an embodiment of the present invention. In this process, it is not assumed that a VM, which can become a VM with an image identity of the image ID, has already been loaded into the cloud object store 308. The trusted infrastructure 350 consists of the customer module 302, the tool module 304, and the security module (SM) 980. In this alternative embodiment, the SM 980 is trusted even though it is part of the untrusted cloud infrastructure 361.

[0063] To deploy a secure VM, the customer module 302 requests that the trusted tool 304 start a My-Image 318 of the SVM. The tool module 304 requests a secure deployment 320 from the cloud front end 306. The cloud front end 306 confirms the paid service 322 to the tool module 304.

[0064] Next, tool module 304 uploads a My-Image 982 of the VM, which can transition to an SVM, to cloud object store 308. Cloud object store 308 then sends the image ID 983 back to tool module 304. Tool module 304 sends a command to SM 980 to securely insert the seed value and metadata indexed by the image ID into SM 984. It is obvious to experts that the image could have been loaded earlier; in that case, the image ID would have been known. Tool module 304 requests that scope orchestrator 310 create an instance of image ID 324.

[0065] The system 300 then selects a target machine 325 as follows. The area orchestrator 310 selects a target machine and requests the platform certificate and the memory key 326 from the selected target system with the TPM 312. The target system with the TPM 312 then sends the platform certificate and the memory key 328 back to the area orchestrator 310.

[0066] The area orchestrator 310 then requests that the SM 980 register this machine (Mach index, platform certification, and memory key) 330. The SM 980 is the trusted infrastructure 350 for the customer module 302.

[0067] The SM then performs a check of the target system from Mach-Ind 933 on the target system with TPM 312. If the check result is negative, the activation ends. If the check result is positive, the SM sends 980 "Approve Execution" (Mach-Ind, Sealed Data) 366 back to the area orchestrator 310.

[0068] The area orchestrator module 310 requests image ID 338 from the cloud object store 308. The cloud object store 308 sends the image 340 corresponding to the image ID back to the area orchestrator 310. The area orchestrator 310 then inserts the sealed data 342 into the image returned by the cloud object store 308. Afterward, the area orchestrator 310 sends the image with the inserted sensitive data to the selected target system with the TPM 312, along with a command to execute image 344.

[0069] Fig. Figure 9B shows the processes required between the target system with the TPM 312 and the SM 980 to complete verification of the target system of Mach-Ind 933 in one embodiment of the present invention. As highlighted, the trusted infrastructure 350 includes the SM 980. The area orchestrator 310 and the target system with the TPM 312 are located outside the trusted infrastructure 350 in the untrusted cloud infrastructure 361.

[0070] The area orchestrator 310 sends requests to register this machine (machine index, platform certification and memory key) 330 to the SM 980.

[0071] The SM 980 validates the platform certificate and performs a check of the storage key properties (460). The SM Hyperprotect 980 generates a verification question and creates the credential 462, which produces a binary blob labeled Credential that can only be for the TPM validated at 460. The SM 980 sends "Activate Credential" (Credential) 468 to the target system with the TPM 312. The target system with the TPM 312 then sends the response 470 to the verification question back to the SM 980. The SM 980 checks the response 476 to the verification question. If the response to the verification question is incorrect, the activation process terminates and an error message is returned. If the response to the verification question is correct, the SM 980 generates sealed data 334 using the policy that was forwarded as metadata along with the seed value.The SM 980 sends "Approve Execution" (Machine-Ind, Sealed Data) 336 to the Area Orchestrator 310.

[0072] Fig. Figure 10A illustrates an alternative security model that uses a security manager to deploy a TEE in an AMD processor of an embodiment of the present invention in a cloud infrastructure. Fig. In 9B, the customer module 302 has a trusted infrastructure 350 and uses a cloud provider 361. The customer uses a security module (SM) 980 with the cloud provider, which they control and which is trusted 350. The rest of the cloud provider's infrastructure 361 is not trusted. The customer module 302 sends a request to the trusted tool 304 to start My-Image of the SVM. The tool module 304 requests secure deployment (320) from the cloud's front end 306. The cloud's front end 306 confirms the paid service (322). The customer tool uploads the image My-Image to the cloud object store (982). The cloud object store 308 sends the image identifier, image ID, of the stored image back to the customer tool 304 (383). The customer tool 304 inserts the seed value 384, also known as detailed or sensitive information and indexed by the image ID, into the security module (SM) (380).Furthermore, additional metadata associated with the image ID can be inserted. The customer tool 304 then requests that the scope orchestrator 310 create an instance of an image ID (324). The scope orchestrator 310 selects (1065) a target machine 312 Mach-Ind. Next, the scope orchestrator 310 requests that the safety module 380 check the target machine 312 Mach-Ind (1063). The safety module checks the target machine (1025).

[0073] Fig. Figure 10B illustrates the process for verifying the target system (PEF) for a TEE in an AMD processor for the alternative model that uses an SM of an embodiment of the present invention in a cloud infrastructure. Fig. 10B shows the details of the requirement to check the target machine (1025) of Fig. 10A. The Mach-Ind check request (1063) is received by the area orchestrator 310 through the safety module (SM) 980. Since the target system 312 contains an AMD process with the TEE, Fig. 10B extended to include the PSP 1003 in the target system, which can be trusted (350) if it is certified. It is important to note that the PSP is a sub-component of the AMD processor, which is in Fig. Figure 10B is extended to clarify the processes. Another important point is that the data transmission between the SM and the PSP is secure and cannot be forged in either direction. This description provides an overview of the process. The details can be found in the AMD White Papers and technical documentation, which are available to any professional. The SM issues a verification request (1056) to the target system 312, which forwards the request (1058) to the PSP 1003. In response to the request, the PSP 1003 generates signed data and sends it back to the processor 312 (1092), which in turn sends it back 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 sends back the verification response (1096).If the certificate is not verified, activation (request to run the secure VM in the TEE) terminates. If the certificate is verified, SM 980 requests that scope orchestrator 310 load the VM image into the target system. Scope orchestrator 310 sends the VM image associated with the image ID to the target system with a request to load the image (1051). Target system 312 loads the VM image into the TEE (not shown). SM 980 issues a request to authenticate the image ID of the VM image to target system 312 (1057). Target system 312 issues a request to authenticate the VM image ID to the trusted PSP 1003. PSP 1003 generates the authentication response and sends it back to system 312 (1059). The target system sends the authentication response back to SM 980 (1099). The SM verifies the authentication response using the hash value of the VM (1055).If the verification result is negative, activation ends. If the verification result is positive, the SM 980 receives the authorization (also known as the decryption key) and issues "Insert authorization" to target system 312 (1091). The target system forwards "Insert authorization" to the PSP 1003 (1097). The PSP 1003 inserts the authorization into the TEE. The SM 980 issues "Boot system" to target system 312 (1093), which is successful because secure computation is authorized (the decryption key has been successfully inserted).

[0074] The Fig. 11 to Fig. Figure 15 shows alternative configurations of systems 100, 200, 300, 301, 500, and 800 that can be implemented. Various features, represented in different figures of the Fig. 1 to Fig. The 15 examples shown can be combined, modified, or exchanged between the different examples.

[0075] Fig. Figure 11 illustrates another hardware configuration of the system in which there is an information processing / computer system 1100 according to the present invention, which has at least one processor or central processing unit (CPU) 1110 that can implement the techniques of the invention in the form of a software intelligence as a service program.

[0076] As mentioned previously, the trusted execution environment 102 can be used in a local infrastructure such as in Fig. 11 are shown and implemented.

[0077] The CPUs 1110 are connected via a system bus 1112 to a random access memory (RAM) 1114, a read-only memory (ROM) 1116, an input / output adapter (I / O adapter) 1118 (for connecting peripherals 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 another user interface unit to the bus 1112), a data transmission adapter 1134 for connecting an 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 unit 1138 and / or a printer. 1139 (e.g., a digital printer or similar).

[0078] In addition to the hardware / software environment described above, another aspect of the invention comprises a computer-implemented method for carrying out the above method. This method can, for example, be implemented in the special environment described above.

[0079] Such a method can be implemented, for example, by operating a computer, as in a digital data processing device, to execute a sequence of machine-readable instructions. These instructions can be contained in various types of signal-carrying media.

[0080] This aspect of the present invention thus relates to a programmed product, including signal-carrying storage media, which physically execute a program of machine-readable instructions that can be executed by a digital processor comprising the aforementioned CPU 1110 and the hardware to carry out the method of the invention.

[0081] These signal-carrying storage media can, for example, contain RAM, which is included in the CPU 1110, as represented by the fast access memory.

[0082] Alternatively, the instructions can be stored in other signal-carrying storage media 1200 such as a flash memory 1210 or an optical storage disk 1220 ( Fig. 12) contained therein, which the CPU 1110 can access directly or indirectly.

[0083] Regardless of whether the instructions are contained in flash memory 120, optical disk 1220, computer / CPU 1110 or elsewhere, the instructions can be stored in a variety of machine-readable data storage media.

[0084] The present invention may therefore be a system, a method, and / or a computer program product. The computer program product may comprise a computer-readable storage medium (or media) on which computer-readable program instructions are stored to induce a processor to execute aspects of the present invention.

[0085] A computer-readable storage medium can be a physical unit capable of retaining and storing instructions for use by a unit to execute instructions. For example, a computer-readable storage medium can be an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof, without limitation. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, random-access memory (RAM), read-only memory (ROM), and erasable programmable read-only memory (EPROM).Flash memory), static random-access memory (SRAM), portable compact storage disk-read-only memory (CD-ROM), DVD (digital versatile disc), USB flash drive, floppy disk, a mechanically coded unit such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium shall not, in its use herein, be understood as volatile signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses traveling through an optical fiber), or electrical signals transmitted by a wire.

[0086] The computer-readable program instructions described here can be downloaded from a computer-readable storage medium to individual data processing units (DPUs) or, via a network such as the internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or storage device. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each DPU receives computer-readable program instructions from the network and forwards them for storage on a computer-readable storage medium within the respective DPU.

[0087] Computer-readable program instructions for executing work steps of the present invention may be assembly instructions, ISA (Instruction Set Architecture) 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 object-oriented programming languages ​​such as Smalltalk, C++, etc., as well as conventional procedural programming languages ​​such as the programming language "C" or similar programming languages.The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer can 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 the connection can be made to an external computer (for example, 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 by using state information from the computer-readable program instructions to personalize the electronic circuits to implement aspects of the present invention.

[0088] Aspects of the present invention are described here with reference to flowcharts and / or block diagrams or diagrams of methods, devices (systems), and computer program products according to embodiments of the invention. It is pointed out that each block of the flowcharts and / or block diagrams or diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams or diagrams, can be executed by means of computer-readable program instructions.

[0089] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a specialized computer, or another programmable data processing device to create a machine such that the instructions executed by the processor of the computer or other programmable data processing device generate a means of implementing the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.

[0090] These computer-readable program instructions may also be stored on a computer-readable storage medium capable of controlling a computer, programmable data processing device, and / or other units to function in a particular manner, such that the computer-readable storage medium on which instructions are stored comprises a manufacturing article, including instructions that implement aspects of the function / step specified in the block(s) of the flowchart and / or block diagrams or charts.

[0091] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other unit to cause the execution of a series of process steps on the computer or other programmable device or other unit in order to generate a process executed on a computer, such that the instructions executed on the computer, other programmable device, or other unit implement the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.

[0092] The flowcharts and block diagrams or charts 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 context, each block in the flowcharts or block diagrams or charts can represent a module, segment, or part of instructions comprising one or more executable instructions for performing the specific logical function(s). In some alternative embodiments, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown consecutively may in reality be executed essentially simultaneously, or the blocks may sometimes be executed in reverse order depending on the corresponding functionality.It should also be noted that each block of the block diagrams or charts and / or flowcharts, as well as combinations of blocks in the block diagrams or charts and / or flowcharts, can be implemented by special hardware-based systems that perform the specified functions or steps, or execute combinations of special hardware and computer instructions.

[0093] With reference to now Fig. Figure 13 shows a schematic representation 1400 of an example of a cloud computing node. The cloud computing node 1400 is only an example of a suitable cloud computing node and is not intended to suggest any limitation of the scope of use or functionality of embodiments of the invention described herein. Notwithstanding this, the cloud computing node 1400 can be implemented and / or perform any of the functionalities described above. As already mentioned, the trusted execution environment 102 can be located in a local infrastructure such as in Fig. 13 (and also in the Fig. 14 and Fig. 15) are implemented as shown. Cloud computing node 1400 contains a computer system / server 1412 that is compatible with numerous other general-purpose or specialized data processing system environments or configurations. Examples of known data processing systems, environments, and / or configurations that may be suitable for use with computer system / server 1412 include, but are not limited to, personal computer systems, server computer systems, lightweight clients, high-performance clients, handheld or laptop units, multiprocessor systems, microprocessor-based systems, peripheral devices, programmable consumer electronics, network PCs, minicomputer systems, mainframe systems, and distributed cloud computing environments containing any of the above systems or units, and the like.

[0094] The computer system / server 1412 can be described in the general context of instructions executable by a computer system, such as program modules that are executed by a computer system. In general, program modules can contain routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement certain abstract data types. The computer system / server 1412 can be used in distributed cloud computing environments, where tasks are performed by remotely located processing units connected via a data transmission network. In a distributed cloud computing environment, program modules can reside on both local and remotely located computer system storage media, including memory units.

[0095] As in Fig. Figure 13 shows that the computer system / server 1412 in the cloud computing node 1400 is represented as a universal data processing unit. The components of the computer system / server 1412 can be—but are not limited to—one or more processors or processing units 1416, a system memory 1428, and a bus 1418 that connects various system components, including the system memory 1428, to the processor 1416.

[0096] Bus 1418 represents one or more of any several types of bus structures, including a memory bus or memory control unit, a peripheral bus, an AGP (Accelerated Graphics Port) interface, and a processor or local bus that utilizes any one of a variety of bus architectures. For 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 Interconnects (PCI) bus.

[0097] The computer system / server 1412 typically includes a variety of computer-readable media. These media can be any available media that the computer system / server 1412 can access, including volatile and non-volatile media, and removable and non-removable media.

[0098] The system memory 1428 can contain computer system-readable media in the form of volatile memory, e.g., random access memory (RAM) 1430 and / or cache 1432. The computer system / server 1412 can also contain other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 1434 can be provided to read and write a non-removable, non-volatile magnetic medium (not shown and commonly referred to as a "hard disk"). Although not shown, a magnetic disk drive can be provided for reading and writing a removable, non-volatile magnetic disk (e.g., a "floppy disk"), and an optical disk drive can be provided for reading or writing a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM, and other optical media.In such cases, each can be connected to bus 1418 via one or more data media interfaces. As further shown and described below, memory 1428 can contain at least one program product with one (e.g., at least one) set of program modules configured to perform the functions of the embodiments of the invention.

[0099] The program / utility 1440, comprising (at least) one set of program modules 1442, can, for example, and without limitation, be stored in memory 1428, as can an operating system, one or more application programs, further program modules, and program data. The operating system, one or more application programs, further program modules, and program data, or a combination thereof, can each include an implementation of a network environment. The program modules 1442 generally perform the functions and / or methodologies of embodiments of the invention described herein.

[0100] The computer system / server 1412 can also exchange data with one or more external units 1414, e.g., a keyboard, a pointing device, a display 1424, etc.; as well as with one or more units that enable a user to interact with the computer system / server 1412; and / or any units (e.g., network card, modem, etc.) that enable the computer system / server 1412 to exchange data with one or more data processing units. Such data transmission can take place via the input / output interfaces (I / O interfaces) 1422. Furthermore, the computer system / server 1412 can exchange data with one or more networks, e.g., a local area network (LAN), a wide area network (WAN), and / or a public network (e.g., the Internet), via the network adapter 1420.As shown, the network adapter 1420 exchanges data with the other components of the computer system / server 1412 via bus 1418. It is understood that other hardware and / or software components may be used in conjunction with the computer system / server 1412, even if not shown. Examples include, but are not limited to: microcode, unit drivers, redundant processing units, external hard disk drive arrays, RAID systems, tape drives, and storage systems for data archiving, etc.

[0101] With reference to now Fig. Figure 14 illustrates a cloud computing environment 1550. As shown, the cloud computing environment 1550 contains one or more cloud computing nodes 1400, with which local data processing units used by cloud users, such as the personal digital assistant (PDA) or mobile phone 1554A, the desktop computer 1554B, the laptop computer 2054C, and / or the automotive computer system 1554N, can exchange data. The nodes 1400 can exchange data with each other. They can be physically or virtually arranged in groups (not shown) in one or more networks, such as private, shared, public, or hybrid clouds as described above, or in a combination thereof. This enables the cloud computing environment 1550 to offer infrastructure, platforms, and / or software as services, for which a cloud user does not need to maintain resources on a local data processing unit.It goes without saying that the in . Fig. The 16 types of data processing units shown, 1554A to N, are intended to be illustrative only, and the data processing nodes 1400 and the cloud computing environment 1550 can exchange data with any type of computer-based unit over any type of network and / or network-addressable connection (e.g., via a web browser).

[0102] With reference to now Fig. 15 shows a set of functional abstraction layers that are used by the cloud computing environment 1550 ( Fig. 14) will be provided. It is understood in advance that the in Fig. The components, layers, and functions shown in Figure 15 are for illustrative purposes only, and embodiments of the invention are not limited to them. As shown, the following layers and corresponding functions are provided:

[0103] Layer 1660 contains hardware and software components. Examples of hardware components include mainframe computers, such as IBM. ® zSeries ® -systems; servers based on the RISC (Reduced Instruction Set Computer) architecture, for example the IBM pSeries ® -systems; IBM xSeries ® -systems; IBM BladeCenter ® Systems; storage units; networks; and network components. Examples of software components include network application server software, such as 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).

[0104] The 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.

[0105] In one example, the management layer 1664 can provide the following functionalities. Resource provisioning enables the dynamic provisioning of compute resources and other resources used to perform tasks in the cloud computing environment. Metering and pricing provide cost tracking (when resources are used in the cloud computing environment) and billing for the use of these resources. In one example, these resources might include licenses for application software. The security function provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal provides access to the cloud computing environment for users and system administrators.Service level management (SLA) provides the allocation and management of cloud computing resources to ensure the required service level is met. Planning and fulfilling the SLA involves the advance allocation and provisioning of cloud computing resources, the future demand for which is predicted based on the SLA.

[0106] Workload layer 1666 provides examples of functionalities for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: mapping and navigation; software development and lifecycle management; delivery of education from the virtual classroom; data analytics processing; transaction processing; and, in particular with respect to the present invention, APIs and runtime system components for generating suggestions for autocomplete searches based on contextual input.

[0107] The numerous features and advantages of the invention become apparent from the detailed description; therefore, the appended claims are intended to cover all these features and advantages of the invention that correspond to the actual concept and scope of application of the invention. Since numerous modifications and variations are obvious to those skilled in the art, the invention is not intended to be limited to the exact structure and function as shown and described, and accordingly, recourse may be made to all suitable modifications and equivalents that fall within the scope of application of the invention.

[0108] It is understood that the invention, in its application, is not limited to the details of the construction and arrangement of the components listed in the following description or illustrated in the drawings. The invention may include further embodiments in addition to those described and may be implemented in various ways. It is further understood that the language and terminology used here, as well as the summary, serve descriptive purposes and should not be considered limiting.

[0109] It is therefore obvious to those skilled in the art that the concept on which this disclosure is based can readily be used as a basis for the design of other structures, methods, and systems for carrying out the various purposes of the present invention. It is therefore important that the claims be considered in light of the fact that they encompass this equivalent structure without deviating from the idea and scope of the present invention.

Claims

[1] A method for generating a computation such that it is executed in a trusted target execution environment (TEE), wherein the method comprises: Selecting the target TEE; Generating an authorization that is fulfilled by a TEE; Assigning the authorization to the calculation that is performed in the authorized TEE; and Generating the calculation with the associated authorization. [2] The method of claim 1, further comprising: Selecting attributes to be included in the authorization for the valid TEE. [3] Method according to claim 1, wherein a security module (SM) is used to generate the authorization. [4] Method according to claim 1, wherein assigning the authorization to the calculation includes dynamically inserting information into the authorization. [5] Method according to claim 3, wherein a customer securely inserts secret information into the SM, wherein secret information includes metadata indicating which secret information the secure computation is associated with. [6] Method according to claim 5, wherein the customer has control via the SM. [7] Method according to claim 3, wherein the SM inserts the authorization into the target TEE. [8] Method according to claim 1, wherein the TEE is located in a cloud infrastructure or local infrastructure. [9] Method according to claim 1, wherein a SM is used as part of the cloud infrastructure or local infrastructure. [10] Method according to claim 1, wherein detailed information about the cloud infrastructure or detailed information about the TEE is disclosed only to the security module. [11] Method according to claim 1, wherein the SM stores a list of previously generated authorizations; if an authorization for the selected target TEE has previously been generated, the SM does not perform a re-generation. [12] Method according to claim 1, wherein at least part of the calculation is encrypted, and encrypting part of the calculation comprises encrypting the information required to check the integrity of the calculation. [13] Method according to claim 1, wherein the authorization limits the calculation to a specific TEE from a plurality of TEEs. [14] The method of claim 1, further comprising: Providing the generated calculation. [15] System that features: a memory that stores computer instructions; and a processor configured to execute computer instructions to: to select a trusted destination execution environment (TEE); to generate an authorization that is fulfilled by a TEE; to assign the authorization to the calculation that is performed in the authorized TEE; and to generate the calculation with the associated authorization. [16] Computer program product comprising a computer-readable storage medium containing program instructions, wherein the program instructions are readable and executable by a computer to cause the computer to perform a procedure comprising: Selecting a trusted destination execution environment (TEE); Generating an authorization that is fulfilled by a TEE; Assigning the authorization to the calculation that is performed in the authorized TEE; and Generating the calculation with the associated authorization.

Images