JP2022099293A - Method, system and computer program for generating computation so as to be executed in target trusted execution environment (tee) (provisioning secure/encrypted virtual machines in cloud infrastructure) - Google Patents

Abstract

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

Description

The present invention relates to, but not limited to, secure / encrypted methods, devices, and system embodiments for secure / encrypted virtual machines in a cloud infrastructure. With respect to methods, devices, and systems for provisioning virtual machines.

Cloud computing is an important aspect of corporate infrastructure. Cloud infrastructure can be private, public, or hybrid. One of the key challenges for hybrid and public clouds is for enterprises to extend trust boundaries to cloud providers and their staff. Although the cloud is expanding dramatically, one of the major impediments is reliability. In most cloud infrastructures, cloud providers and their staff are initially assumed to be trusted.

Therefore, security is a major obstacle to cloud adoption. Therefore, there is a need to provide a more secure cloud computing platform that can be implemented efficiently and cost-effectively. Furthermore, there is a need to provide a set of protocols that can provide security in cloud computing without the need to trust cloud providers.

Considering the above and other problems, disadvantages, and drawbacks of the background techniques described above, an exemplary embodiment of the disclosed invention is for provisioning secure / encrypted virtual machines in a cloud infrastructure. Methods, devices, and systems are provided.

According to embodiments of the present invention, the selection of a targeted execution environment (TEE), the generation of a TEE-satisfied certificate, and the execution of that certificate within the authenticated TEE. A method for generating a computation to be performed within a target TEE, including associating it with a computation and generating it using its associated authentication.

According to another embodiment of the invention, a memory for storing computer instructions and the computer instructions are executed within a TEE that selects a target TEE, generates a TEE-satisfied certificate, and is authenticated. A system, including a processor, that is configured to associate with a computer and perform to generate a computer using that associated authentication.

According to yet another embodiment of the present invention, the computer-readable storage medium in which the program instruction is embodied is provided, and the program instruction selects the target TEE for the computer by the computer, and the authentication that the TEE is satisfied with. To perform a method that includes generating a computer, associating a certificate with a computer running within the TEE to be authenticated, and generating a computer with the associated certificate. A computer program product that is readable and executable.

Thus, a particular embodiment of the invention may be better understood as its detailed description herein and its contribution to the art. A fairly rough overview. Of course, there are additional embodiments of the invention described below that form the subject matter of the claims that accompany this specification.

It should be understood that the invention is not limited to the details of the structures described below or illustrated in the drawings and the arrangement of components in its use. The present invention is capable of embodiments other than those described, as well as implementation and practice in various modes. It should also be understood that the terminology and terminology used herein and in the abstract is for explanatory purposes only and should not be considered limiting.

Accordingly, one of ordinary skill in the art will appreciate that the concepts on which the present disclosure is based can be readily utilized as the basis for the design of other structures, methods, and systems for carrying out some of the objects of the invention. Will do. Therefore, it is important that the claims are considered to include such equivalent structures as long as they do not deviate from the ideas and scope of the invention.

An exemplary embodiment of the invention will be better understood from the following detailed description of the exemplary embodiments of the invention with reference to the drawings.

It is a figure which shows the example of TEE (trusted execution environment) when it is used in this invention. It is an exemplary flow diagram of an embodiment of the present invention. It is an exemplary flow diagram of an embodiment of the present invention. It is a figure which shows the flow of the keep your own key regarding the alternative security model of the embodiment of this invention in a cloud infrastructure. It is a figure which shows the flow of the verification (verifty target system) of the target system (that is, the system of the directed expression facility (PEF)) about the keep own house model of the embodiment of this invention in the cloud infrastructure. It is a figure which shows the provisioning method in embodiment of this invention. The layout of the ESM (enter secure mode) operand. It is a figure which shows the value extended to PCR6 (platform composition register 6) for the verification of the hardware configuration in embodiment of this invention. It is a figure which shows the verification of the computation in embodiment of this invention. It is a figure which shows the exemplary projected expression facility (PEF) of the Embodiment of this invention. It is a figure which shows the alternative security model utilizing SM of the Embodiment of this invention in a cloud infrastructure. It is a figure which shows the flow of the verification of the target system (that is, the system of the directed expression facility (PEF)) with respect to the alternative model utilizing SM of the embodiment of this invention in a cloud infrastructure. It is a figure which shows the alternative security model which uses SM for provisioning TEE in the processor of AMD (ADVANCED MICRO DEVICES) of embodiment of this invention in a cloud infrastructure. The flow of verification of the target system (that is, the system of directed expression facility (PEF)) about TEE in the processor of AMD (ADVANCED MICRO DEVICES) regarding the alternative model utilizing SM of the embodiment of this invention in a cloud infrastructure is shown. It is a figure. It is a figure which shows the example hardware / information handling system for incorporating the example embodiment of this invention. It is a figure which shows the signal holding storage medium for storing the machine-readable instruction of the program which carries out the method which concerns on embodiment of this invention. It is a figure which depicts the cloud computing node which concerns on embodiment of this invention. It is a figure which depicts the cloud computing environment which concerns on embodiment of this invention. It is a figure which drew the abstraction model layer which concerns on embodiment of this invention.

Here, the present invention will be described with reference to the drawings in which the same reference numbers refer to the same parts throughout. It should be emphasized that, according to common practice, the various features of the drawing are not always at the correct scale. Conversely, the dimensions of various features can be arbitrarily scaled up or down for clarity. Hereinafter, exemplary embodiments are provided for purposes of illustration, but these are not intended to limit the scope of the claims. Furthermore, it should be noted that all steps can be performed in different orders, in combination, or at the same time. In addition, any of the structures and embodiments shown can be modified or combined.

As already mentioned, security is a major obstacle to cloud adoption. Cloud vendors have access to all the information used within a running container or VM (virtual machine). To address this issue, various CPU (Central Processing Unit) vendors have modified their architecture to allow them to create and run private computations. Architectural changes generally fall into the category of Trusted Execution Environment (TEE). The invention also supports TEEs that are part of a cloud node or infrastructure but are not incorporated into any particular CPU architecture.

Processor vendors provide a means for cloud providers to address the trust gap in creating trusted execution environments (TEEs) that provide hardware support for secure execution. TEE divides a processor or process into secure and non-secure areas. TEE can be classified as either coarse-grained or fine-grained based on "grain size". A coarse-grained TEE works, for example, at the VM (virtual machine) or processor level, while a fine-grained TEE protects only a process or a single thread of execution. Examples of coarse-grained ones are IBM®'s Secure ServiceContainers, ARM® (Advanced RISC (Reduced Instruction Set Computer) Machines) and TrustZone® (which is also considered TE®). ), IBM's Protected Instruction Facility (PEF), and AMD's Secure Enhanced Virtualization (SEV). Intel® Software Guard Extension (SGX) is a fine-grained TEE. Intel has expressed its intention to provide coarse-grained support. All TEEs are trusted, because the requirements enforced by the hardware are imposed on the code running in the secure partition and the user can verify that the hardware is correct.

Most TEEs also present some form of proof. Due to the absence of proof and some other features, the existing ARM TrustZone (TM) may be excluded as a TEE. However, the ARM processor can be used with an external TPM that can provide some form of proof. There are various methods and points of proof. The proof verifies the attributes of the TEE, including which software is currently running in the TEE, the underlying firmware / software of the TEE, or both, by a remote party. It will be possible to guarantee. The proof allows TEE users to verify important characteristics about the environment in which their code or secret will be executed. The TEE is designed on the assumption that the adversary physically owns, can control, or has access to a system / device / PC that includes the processor. Its purpose is to enable confidential or secure computing in the presence of hostile access or control. The architectural changes introduced by TEE provide protection against hostile access.

Even with these capabilities, it remains difficult to leverage TEE to provide confidential computing, as many cloud infrastructures assume that providers can be trusted.

The invention is among other features, when enabled and utilized in a cloud infrastructure, the customer of the cloud infrastructure uses the infrastructure without sharing any of its secrets with the cloud provider. Identify the set of protocols and components that you want to be able to do. The present invention provides a set of protocols that allow users to take advantage of Protected Execution Facility or other coarse-grained TEE without having to rely on cloud providers.

The present invention is described using the Protected Execution Facility (PEF) TEE. PEF supports secure computing called secure virtual machines (SVMs). All SVMs start running as regular VMs, and in the process of their initialization, they make an ESM (Transition to Secure Mode) ULTRAVISOR call requesting a transition from a regular virtual machine to a secure virtual machine. do. The PEF requires that a properly configured platform have a TPM and be running with a secure and trusted boot enabled.

The TPM used in this embodiment represents the hardware used to hold the measured values for the proof function. The proof function may be built into the processor or implemented outside the processor architecture. Some refer to TPM PCR, which represents some reliable mechanism for recording measurements.

The present invention utilizes TPM (Trusted Platform Module) and TEE hardware deployed in a cloud infrastructure. There are two models for utilizing TEE in cloud infrastructure, BYOK (Bring Your Own Key) or KYOK (Keep Your Own Key). BYOK needs a key vault under the control of the cloud user, such as SM (Security Module) 866 in the cloud infrastructure, to avoid exposing the user's keys to the cloud provider. did. Examples of security module 866 include IBM 4769 Cryptographic Copper Secsor (TM), IBM Hyper Protect (TM), IBM Z Secure Service Controller (TM), IBM Z Secure Hardware (TM), IBM Z Security Module (TM), IBM Z Security Module (TM), IBM Z Security Module (TM) -Security module), TEE, or even TPM. Sensitive information can be stored in customer-controlled key vaults. KYOK requires the cloud to provide cloud users with more information about its infrastructure.

Cloud computing is an important aspect of corporate infrastructure. Cloud infrastructure can be either private, public, or hybrid. As already mentioned, one of the major challenges for hybrid and public clouds is for enterprises to extend their trust boundaries to cloud providers and their staff. Although the cloud is growing dramatically, reliability is one of the major impediments to it. In most cloud infrastructures, cloud providers and their staff are initially assumed to be trusted.

FIG. 1 is a diagram showing an example of TEE used in the present invention. TEE can be implemented in several ways, including as a modification of the CPU architecture, as an external component plugged into a peripheral interface, or as a completely separate processor with the appropriate interface and isolation hardware. In this embodiment the TEE is described as a single system. However, the invention also works if TEE represents a properly configured set of systems. The use of TEE refers to one or more well-configured systems. Within the software section 130 of the system 100, there is a TEE 102 that includes the hardware 120 and the software 130. A trusted application is software that runs inside TEE. The TEE API 112 is often implemented within firmware and / or hardware, with an interface to software running inside TEE and software outside TEE that may wish to be secure by running inside TEE. Provides an interface to and to. Processor B 114 in trusted hardware is a trusted part of the processor where trusted applications and TEE APIs run. This may be a completely independent processor, or it may 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 inside the TEE 102. TEE also includes a proof function 122. In a preferred embodiment, the certification function is supplied by TPM. However, any hardware used to securely store firmware and / or software measurements may provide certification.

The trusted software in the TEE may include the entire operating system separate from the untrusted OS 108 outside the TEE 102. If the TEE is of fine particle size, the OS within the TEE is often referred to as shim.

Outside the TEE, there are an operating system 108 and an application 106, as well as a memory 116 and a processing function 110. None of these components are implicitly trusted by trusted software 104. The interface between the two must be carefully implemented so as not to sacrifice reliability.

FIG. 2A shows an exemplary flow diagram for provisioning a Computation within a TEE as an embodiment of the present invention. Those skilled in the art recognize that the preparation for certification to perform a computation in TEE should be done in a trusted environment, but can be done anywhere. Provisioning of the Computation within the TEE begins with the selection of the target TEE 204. Choosing a target TEE requires choosing a system that includes the TEE capable of performing secure computations. 3, FIG. 4, FIG. 9A, FIG. 9B, FIG. 10A, and FIG. 10B show examples of how the target TEE is selected and which attributes can be verified. In a preferred embodiment, the expected attributes of TEE are expected to be known prior to selection. However, one of ordinary skill in the art recognizes that the expected attribute may be a function of the selected TEE. For example, if you are provisioning a compute that can run on multiple architectures, the required attributes will likely depend on the target architecture. Authentication 206 constrains the computation to a particular TEE or to a set of TEEs that meet certain criteria. In either case, the criteria used to validate a particular TEE and / or TEE must be known before generating a certificate. Selecting the target TEE and identifying the criteria are dealt with in step 204. Those skilled in the art will recognize that these may be two separate steps.

It is step 206 to generate the authentication. In general, authentication constrains the set of TEEs to be authenticated to perform secure computation. In a preferred embodiment, the certification is a protected symmetric seed, as shown in FIG. In a preferred embodiment, each TEE has a key pair. A preferred protection mechanism is to encrypt the seed with the public key associated with the target TEE. Only authenticated TEEs can access the private key. The private key may be locked at the TPM or at some other hardware protection mechanism. The TPM specification defines encryption using a public key as a sealing process, the result of sealing as sealed data, and decryption of sealed data using a private key as an unsealing process. ing. The authentication may include an identifier indicating which TEE the authentication is for. TEE verifies the authentication if the identifier is present.

In a preferred embodiment, the TPM is used to keep the private key secure. In a preferred embodiment, the private key is locked to the TPM and no duplication is allowed. Alternatively, the key is locked to the TPM and duplication is only allowed by password. However, those skilled in the art know that passwords must be managed very securely in order to provision multiple machines with a single secret. Those skilled in the art know that private keys can be retained in some other location protected by the hardware trust root. When using the TPM, the policy associated with the ability to access the private key and unseal the symmetric key constrains the set or configuration of the authenticated system to perform secure computation. can do. For example, in a preferred embodiment, the ability to access the public key can require the PCR to match a particular value, as illustrated in FIG. 7A. The illustrated constraints are illustrated in FIG. 7A. Those skilled in the art recognize that authentication can be arbitrarily complicated. The authentication may be embedded in the sealed data or may be separate metadata.

Associate authentication with computation 208. The steps of associating authentication with computation are illustrated in FIG.

Generate a computation with the associated authentication 210. Authentication that includes sealed data is dynamically inserted into the computation. In a preferred embodiment, the authentication is inserted into the pre-prepared computation, or the authentication is inserted during the preparation of the computation.

Finally, the computation is provisioned to the target TEE 212. An example of a computing provisioned by the present invention is a secure VM. Examples of secure VM provisioning within TEE are given in FIGS. 3 and 4, FIGS. 9A and 9B, and FIGS. 10A and 10B.

In some TEE models, the user of the TEE must explicitly verify that the TEE is valid before inserting the secret. In such a model, TEE is launched on the target system but is not decrypted until the proof is verified. After the target system becomes secure, it measures or has the state of TEE. The measurement result is sent to the user. If the user is satisfied with the measurement result, the insertion of a secret that allows TEE to decrypt the computation has been authenticated. This secret is essentially a certification. Without it, no computation would be performed within this type of TEE. This association is implied by running TEE within the target system. The generation is the user who computes the acceptable value.

FIG. 2B shows an exemplary flow diagram for provisioning a Computation within a TEE as an embodiment of the present invention. Computation preparation for TEE should be done in a trusted environment. Those skilled in the art recognize that the preparation for certification to perform a computation in TEE should be done in a trusted environment, but can be done anywhere. Provisioning starts at 230. The first step is to verify the TEE, 232. Examples of verification of the target TEE can be found in FIGS. 4, 10A, and 10B. If the TEE cannot be verified, provisioning ends at 246. Next, Computation Integrity information must be generated 234. An example of Computation Integrity Information is Integrity Information 677 in FIG. In this description, it is assumed that the TEE at which the computation is performed verifies the integrity of the computation and fails to execute if there is a problem. Alternatively, the TEE may independently calculate the integrity of the compute and return that information to the owner via some secure mechanism, if improper, the execution of the TEE will be terminated. Will be. In implementations where the owner must verify the integrity of the running TEE, it would be useful to point out that sensitive information should not be included within the TEE until it is validated. Both methods require integrity information. Next, the sealed data is generated 236. The sealed data specifies whether TEE is authenticated to perform the computation. Those skilled in the art will recognize that the sealed data is a TPM-specific term. When the data is sealed by the TPM, the sealed data is associated with a policy that must be satisfied in order to access the sealed data. Computation information, sealed data, and integrity information are sent to TEE 238. In a preferred embodiment, the policy associated with the sealed data is used to verify that the TEE is certified. This policy is carried out by TPM. TEE confirms that the TEE is authenticated to perform the computation, 240. If TEE is not authenticated, execution ends 246. Computation integrity is verified 242. This may be achieved by TEE independently computing the integrity information. It can then verify that it matches the received integrity information, or it may send the calculation results back to the initiator via some secure channel and wait for them to be confirmed. .. In either case, if the integrity of the compute is not verified, the execution ends 246. Otherwise, the computation is performed 244.

3 and 4 show a flow of an alternative form of PEF (Protected Execution Facility) in which SM (security module) 980 does not exist.

Specifically, FIG. 3 shows a flow of KYOK (Keep Your Own Key) relating to the security model of the embodiment of the present invention.

In the case of KYOK, the customer accepts the responsibility to implement the enrollment protocol. Alternatively, the enrollment protocol must be executed by someone trusted by the customer. In this model, the customer controls the value of the platform configuration register 6 (PCR6) that he trusts.

System 200 is divided into trusted infrastructure 350 (highlighted) and untrusted cloud infrastructure 361 (remaining unhighlighted structures). The trusted infrastructure 350 (highlighted) is shown as customer 302 and touring module 304.

This flow assumes that a potentially SVM VM416 (not shown) with an Image-ID image ID (identification information) is preloaded in the cloud infrastructure store. To provision a secure VM 416, the customer module (or customer network) 302 requests that the touring 304 initiate VM Image_ID 318. The touring module 304 requests secure provisioning from the cloud front end 306 320. The cloud front end 306 confirms the paid service for the touring module 304 322. The touring module 304 requests that the zone orchestrator 310 create an instance of the image-ID 324.

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 326 from the target system 312 with TPM. Those skilled in the art are known to know how existing cloud infrastructures can utilize the list of requirements and select available machines from those infrastructures. Any technique for selecting such a machine is acceptable. Those skilled in the art will recognize that the list of attributes to be selected should be augmented with the attributes associated with the target TEE. Further, those skilled in the art will recognize that Mach-Ind may be an IP address, or any other information that can be used to identify a machine within the provider's infrastructure. The target system 312 with the TPM then returns the platform certificate and storage key to the zone orchestrator 310 328. The zone orchestrator 310 requests that the client touring module 304 enroll the target machine via the machine enrolling (Mach-ind, platform certificate, storage key) 330.

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

If the target system is validated, the client touring 304 will generate sealed data 334. Although not shown, if verification 332 of the target system fails, activation will cease. The touring module 304 sends an authentication execution (Mach-ind., Sealed data) 436 to the zone orchestrator module 310.

The zone orchestrator module 310 requests the image-ID (Image identification information) 338 from the cloud object store 308. The cloud object store 308 returns the image associated with the Image-ID to the zone orchestrator module 310 again 340. The zone orchestrator 310 then inserts the sealed data into the image returned from the cloud object store 308. The zone orchestrator then passes the image with the inserted sealed data to the target system 312 with the TPM and orders the target system to perform the image 344.

FIG. 4 shows the details of the verification 332 (PEF) of the target system according to the embodiment of the present invention. The trusted infrastructure 350 is shown as a customer module (or customer network) 302 and a touring module 304. An trusted cloud infrastructure 361 is also shown.

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

FIG. 5 shows a method of provisioning a machine according to an embodiment of the present invention.

One of the embodiments of the present invention utilizes an NV (Non-Volatile) location in the TPM to hold a password. The NV location of NV_Location_X must be assigned (provisioned) with the appropriate policy before placing the machine in the infrastructure or as part of provisioning the machine into the cloud infrastructure.

System 500 generates a storage key 544 using a policy that requires the password to be used and that it matches the password in NV_Location_X. By definition, the storage key is the parent and the child of the parent key does not have to be the key. A password is required to use the storage key 544. The preferred attribute of the storage key should be fixed to the TPM, the key algorithm can be RSA2048 (Rivest-Shamir-Adleman cryptosystem with 2,048 bits), the key length is 2048, and the authentication. Is a pointer to NV_Location_X, and a platform hierarchy. Policy 544 also states that PCR 6 must be matched in order to use the storage key. A new password is assigned to ULTRAVISOR at each boot. In a preferred embodiment, the password is regenerated at each boot.

The third step 542 of provisioning is to generate a storage key using a pre-computed policy stating that the password required to utilize the storage key is in NV_Location_X. At step 544, the storage key policy requires that the password be used and that it matches the password in location NV_Location_X.

Maintaining the isolation and security of computations and related data is the sole purpose of ULTRAVISOR. System management is still the responsibility of the hypervisor. The hypervisor uses ultra-calls to continue to manage security-sensitive features. If necessary, ULTRAVISOR ensures that the action requested by the hypervisor does not affect the security of any SVM (Secure Virtual Machine) being performed.

Therefore, as mentioned, in the preferred implementation example, in addition to the other attributes, the storage key is fixed to the TPM, the key algorithm is RSA, and the key length is 2048. The ability to change passwords is tied to TPM platform authentication, which must be terminated early in the firmware boot process before any OS is loaded onto the platform. The firmware on the machine must be capable of assigning a new random password each time the machine is booted and passing that password to ULTRAVISOR or equivalent firmware.

FIG. 6 shows the layout of ESM operand 691. The ESM operand 691 can be divided into two large areas, sensitive information 685 and payload 689. Sensitive areas contain sealed data. Each sealed data allows a well-configured system to access the information in the payload area 689 of the ESM operands. The sealed data 673 provides access to machine A and the sealed data 675 provides access to machine B. The unsealed data is the seed used to generate the symmetric and HMAC keys. Everything in payload area 689 except HMAC is encrypted with a symmetric key generated from the seed. The first part of the payload area 689 is integrity information 677. This is the information required by the PEF to verify the integrity of the compute. It consists of a kernel hash, a kernel command line, initramfs (initial RAM (random access memory)), and an RTAS area. In a preferred embodiment, the integrity information 677 is encrypted as specified. In an alternative embodiment, the integrity information is not encrypted. Since the PEF validates the integrity of the computation without contacting the creator, this information is generated when a secure computation is created and placed in the ESM operand. (For technologies in which the owner / user of the Computation is contacted to verify the integrity of the Computation, the information must be calculated by TEE). The rest of the information in payload area 689 is secret 687. These are represented by CD1 to CDn, and CD represents "Customer data". The integrity of the preferred embodiment protects the VM kernel, intramfs, kernel command line, and RTAS 677. The boot disk should be encrypted. In a preferred embodiment, the first block of customer data 679 includes a passphrase that protects the root disk encrypted with the symmetric key. After the encrypted passphrase, there are zero or more blocks of customer data. Each of the secrets 687 is encrypted with a symmetric key generated from the seed.

FIG. 7A shows values extended to PCR6 786 for verification of hardware configurations in embodiments of the present invention. A preferred embodiment utilizes a secure and trusted boot to ensure that the hardware and firmware configurations are valid. The values represented here are the preferred set of values. Different implementations may use different values. For those of skill in the art, PCR 6 786 is representative of the PCR used to hold the value, and whatever PCR is used, it is also to verify (Figure). I understand that it must appear within the policy of the sealed data (not shown in 7A). It is important to note that this embodiment only identifies the actions of variable and / or immutable codes required for the present invention. The variable boot loader 776 and immutable code 772 described herein are performed within a self-boot engine (SBE; self-boot engine) to perform many actions not described herein. Execution ends if secure and trusted boot is enabled each time signature validation fails. The immutable boot loader 772 is the first code to be executed when the system is powered up. The immutable boot loader 772 extends the hardware key hash 788 and the secure boot jumper 790 to the PCR6 786. The hardware key hash 788 is a hash of the cryptographic key in use to validate the signature on the cryptographic key used to validate the signature on the firmware. The secure boot jumper 790 identifies whether secure boot is enabled or disabled. Immutable code 772 loads and validates the signature of variable boot loader 776 before passing control to variable boot loader 776. If the signature is validated, the immutable code 772 extends to PCR6 786 the hash of SB validation code 774 that is part of the variable boot loader 776 that validates the signatures of other codes. It then passes control to the variable boot loader 776. The variable boot loader 767 validates the host boot loader 778. The host boot loader 778 is a host boot Init. (Initialization; initialization) 780 is verified. The host boot Init780 is a host boot Ext. (Extensions; extensions) 782 is verified. Host boot Ext. 782 extends the separator 792 to PCR6. Host boot Ext. 782 verifies OPAL784. OPAL784 extends the PEF enable bit 794 to PCR6 786. FIG. 7A illustrates how the value of PCR6 786 will be generated when properly configured hardware is booted. In a preferred embodiment, the policy associated with the sealed data requires PCR 6 to match this value. No matter what implementation requires proper validation of its configuration, other values can be extended to PCR 6 (or another PCR) if desired. The authentication policy required by the present invention is the same method (not recommended) of extending a value to a physical or virtual PCR by software using a virtual TPM, a real TPM, or reimplementing the actions performed by the TPM. Can be generated with. The policy is the hardware key hash 788, secure boot jumper 790, SB verification code 774 hash, separator used by the firmware, which is required to authenticate the TEE to perform secure computation. Specifies the state of 792 and the PEF enabled bit 794.

FIG. 7B shows, in an embodiment of the invention using PEF, 240 confirming the authentication requirements and 242 verifying the integrity of the compute information. As already mentioned, secure computing starts as a regular VM. This makes an ESM ULTRAVISOR call to transition to a secure VM running within PEF TEE, at which point verification begins, 750. In a preferred embodiment, the ESM ultra-call requires the ESM operand 691 shown in FIG. If the ESM operand is not present, the ESM Ultra-Call will fail. TEE performs a check to see if it is authenticated in order to perform a secure VM 240. If it is not authenticated, execution ends, 766. If authenticated, the TEE performs a check 754 to confirm that it is a valid TEE, which is a valid TEE that meets the sealed data policy specified by the SVM creator. In the case of PEF, this check is performed by the TPM when the ULTRAVISOR requests the TPM to extract seeds from the sealed data. If TEE does not meet these requirements, execution ends 766. Since the TEE is authenticated and meets the requirements, it has access to the HMAC key, and the symmetric seed needed to generate the symmetric key if integrity is enabled. It then generates an HMAC key, 756. It uses an HMAC key to verify that the encrypted information in the ESM operand has not been altered. 758. If the encrypted information has been modified, execution ends 766. Otherwise, a symmetric key is generated, 760. This gives the TEE access to the information required for Computation Integrity Verification 242. If the computation has been modified, execution ends, 766. Otherwise, the VM completes and executes the transition to the SVM, which successfully completes the transition 768, and the VM becomes the SVM at this point.

Provisioning FIG. 8 shows an exemplary directed expression facility (PEF) of an embodiment of the invention. The system 800 requests SVM (Secure Virtual Machine) execution (S0). Next, the orchestrator module 852 selects a target machine from T0 ... Tn864 (S1). The orchestrator module 852 asks the SM (security module) 866 to verify one of the selected target machines, T0 ... Tn, 864 (S2). In FIG. 5, the selected target is Tn, 864. SM866 requests information (platform certificate, storage key structure, HW (hardware) key hash) from the selected target system 864 (S3). SM866 must verify that they are appropriate. In order to perform verification, it must have the platform vendor's public key. Once the key is obtained, it can store the key internally to facilitate the verification process. The SM866 validates the machine using the vendor's 860 (S3a) public key and contacts the vendor if it does not already have it. The SM device 866 sends the sealed data to the orchestrator module 852 (S4). Orchestrator module 852 reads a copy of the selected SVM856 from library 858 S5. Note that in PEF, all SVMs start running as VM854. As far as library 858 is concerned, all images are VM854. For the sake of brevity of the invention, these VM854s, which can be SVMs, are labeled with SVM856 in library 858. Those of skill in the art know that library 858 can be implemented so that the difference is noticeable or invisible. The orchestrator inserts the sealed data into a copy of the SVM. Orchestrator module 852 dispatches a copy of SVM856 to target system 864 (S6). In the case of cloud infrastructure 870, the target system 864 is generally unknown at the time the SVM856 is created. Cloud providers must be able to make changes to their infrastructure (eg, perform daily maintenance, upgrades, etc.) without affecting the existing SVM856. One of the key attributes of the PEF ESM (Enter Security Module) operand, which allows easy integration into the cloud infrastructure 870, is the HMAC (Hashing for Message Authentication Code) message authentication code. Hashing for) does not cover the sealed data. This means that the sealed data does not have to be generated at the same time as the rest of the ESM operands and can be inserted into the ESM operands just before execution. In a preferred embodiment, the placeholder sealed data may be present in the ESM operand, which will be overwritten by the sealed data for the selected machine. In an alternative embodiment, the image with the sealed data may be stored in the cloud object store 308. This would be useful in alternative embodiments where TEE represents a set of systems. The cloud object store 308 may also store metadata that indicates whether the sealed information already exists. If present, the VM can be dispatched directly to the TEE (set of machines). The ESM operand is a digital blob that is placed within a reserved section of intramfs. 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 needed to validate the SVM is contained in the ESM operands.

An example deployment model involves dynamically generating sealed data using Security Module (SM) 866 or equivalent functionality in a cloud provider's infrastructure. In the present invention, the master secret is owned / controlled by the cloud customer, while the hardware is controlled / owned by the cloud provider. In this case, the cloud provider cannot extract the information from the SM866, so it is safe for cloud customers to put the secret associated with their secure computation inside the SM866. An example of an SM that can be owned by a cloud provider but controlled by a customer is IBM 4769. The capabilities described in the present invention do not currently exist in 4769, but can be added. Since the SM866 is within the cloud provider's infrastructure, it is safe for the cloud provider to be able to run the protocols it needs to generate sealed data for the target machine. No cloud infrastructure details are provided to cloud customers. At this point, in PEF, all SVMs (Secure Virtual Machines) start running as NVMs (Normal Virtual Machines), and in the early stages of their execution, they are ESMs (Secure Modes) that are requests for migration to SVMs. (Transition to) It is important to keep in mind to perform ultra-calls. It is also important to note that from the cloud provider's point of view, the NVM image and the SVM image are the same. Cloud customers need to inform cloud providers that a particular image is for an SVM so that it can be processed properly. In the deployment description, the VM (Virtual Machine) image that will be migrated to SVM (Secure Virtual Machine) 856 is pre-created, and the associated symmetric seed and associated metadata are pre-SM866. It is supposed to be inside. Finally, given the identity of the VM, it is hypothesized that SM866 will use the associated metadata to select the correct symmetric seed.

Further referencing FIG. 8 shows the overall process for performing SVM856. The cloud user requests that a pre-created execution instance of SVM856 be created. The cloud infrastructure 870 selects the target machine 864 and extracts the platform certificate and storage key from this target. The infrastructure transfers the target machine, 864, platform certificate, and storage key to SM866 under customer control and requests enrollment of the target machine 864 for the SVM. In an alternative embodiment, the cloud infrastructure transfers only the target machine and requests SM to enroll the target machine. The SM extracts the platform certificate and storage key from the target machine itself and then proceeds with the enrollment process. If the enrollment is successful, SM866 will return sealed data about the target machine 866 to the cloud infrastructure 870. The infrastructure reads a copy of the image, 856 from library 858, uses touring to insert the sealed data into the ESM operand of the SVM856, and a copy of the image containing the inserted sealed data, targeting the machine 856. Provision to 864. The newly inserted and sealed data is for the target machine 864, so if there are no other issues, the VM will successfully migrate to the SVM856. This model assumes that the customer will have one seed per SVM856, and that this seed will be valid for all target systems 866. Other models are possible, and in particular this embodiment is written as if the selected target, 864, is a single machine. However, one of ordinary skill in the art recognizes that the target may be a single machine, 864, or a set of machines, 868, depending on how the infrastructure is provisioned. .. Sealed data can be dynamically inserted into the computation.

Enrollment protocols include: The SM866, or equivalent, must implement the enrollment protocol. The enrollment protocol requires the cloud infrastructure 870 to pass the SM866 a machine indicator (IP (Internet Protocol) address), platform certificate, SVM indicator, and storage key for the target machine. In an alternative embodiment, the cloud provider passes only the machine indicator to the SM, which itself extracts the platform certificate and storage key. In either embodiment, the SM866 will validate the platform certificate and check that the storage key characteristics are correct. If the platform certificate and storage key pass the check, SM866 will generate a random challenge and create credentials. It will then send activation credentials to the target machine 864 to be run on that TPM862. The target machine 864 will return a challenge response. If the challenge response is valid, SM866 will generate sealed data about the target machine 864 and return it to the cloud infrastructure 870 of the System 800.

The enrollment protocol only needs to be run once per target. Therefore, if SM866 maintains a database of enrolled machines, it can perform a check to see if the current target machine is enrolled. If it is already enrolled, it can skip enrollment and generate sealed data directly. Also, each hardware key hash only needs to be verified once. The SM866 can maintain a database of verified hardware key hashes. Before System 800 executes the protocol against Vendor 860 to verify the hardware key hash, System 800 may perform a check to see if the hash from the target machine 864 has already been verified. can. This is not a major optimization for the PEF, because the hardware key hash is validated when the SVM is created, rather than once per run. If the key hash becomes invalid, it must be purged from SM866. When a machine is deprovisioned from the Cloud Infrastructure 870 of the System 800, it must notify SM866 that the machine is no longer a valid target so that SM866 can empty its internal database. Finally, the primary seed in TPM862 must also be emptied when the machine is deprovisioned to ensure that the secret cannot be extracted from the already authenticated SVM866 using the deprovisioned machine.

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

The first technique shown in FIGS. 3 and 4 is for the user to ensure that the intended target machine is acceptable and to configure the computation to run on the intended target. Require the infrastructure provider to expose details such as the server's IP (Internet Protocol) address to its users. The requested API reduces the transparency of the cloud provider's infrastructure to cloud users.

Some cloud providers do not want to expose the details of their infrastructure because it makes managing their infrastructure significantly more complex. By including a well-configured SM, the present invention can achieve the same objective of provisioning secure computations in TEE without exposing infrastructure details to cloud customers. SM must be under the control of the customer who utilizes TEE. The SM shall be configured to perform a pre-described validation flow as shown in FIGS. 9 and 10. Customers must securely insert their secrets into the SM.

9A, 9B, 10A, and 10B illustrate how the invention works within PEF TEE. PEFs and similar TEEs are designed for TEEs to prove the integrity of Computation without requiring separate verification from the TEE's users / owners. In FIGS. 10A and 10B, the present invention requires the owner / user to explicitly authenticate the computation after the secure computation has been loaded into a valid TEE, eg AMD SEV. Explains how it works. In either case, both TEE and Computation are certified / verified. 9A, 9B, 10A, and 10B do not assume that the customer has preloaded the VM image. The customer can preload the VM image, My-Image482, which may suggest that the customer knows the Image-ID483 in advance.

FIG. 9A shows an alternative form of PEF (Protected Execution Facility) utilizing SM (security module) in the embodiment of the present invention. This flow does not assume that a potentially secure VM with an Image-ID image identity is preloaded in the cloud object store 308. The trusted infrastructure 350 is a customer module 302, a touring module 304, and a security module (SM) 980. In this alternative embodiment, the SM980 is trusted despite being part of the Antrusted Cloud Infrastructure 361.

To provision a secure VM, customer module 302 requests that the trusted touring 304 start the SVM My-Image 318. The touring module 304 requests secure provisioning from the cloud front end 306 320. The cloud front end 306 confirms the paid service for the touring module 304 322.

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

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

The zone orchestrator 310 then requests the SM980 to enroll this machine (Machine-ind, platform certification, and storage key) 330. SM980 is a trusted infrastructure 350 with customer module 302.

The SM then performs verification 933 of the target system Mach-ind against the target system 312 having a TPM. If the verification fails, the activation will end. If the verification is successful, the SM980 returns a certifying execution (Machine-ind., Sealed data) 336 to the zone orchestrator 310.

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

FIG. 9B shows the flow required between the target system 312 with a TPM and the SM980 to complete the verification 933 of the target system Mach-Ind in embodiments of the present invention. As highlighted, the trusted infrastructure 350 includes the SM980. Within the untrusted cloud infrastructure 361, the target system 312 with the zone orchestrator 310 and the TPM is outside the trusted infrastructure 350.

The zone orchestra 310 sends the SM980 a request for this machine (Machine-ind, platform certification, and storage key) 330 and enrolls it.

The SM980 validates the platform certificate and checks the storage key characteristics 460. SM HyperProtect980 creates a challenge and creates a binary blob called Credential that can only be due to the TPM validated at 460, creating credentials 462. The SM980 sends an activation of credentials to the target system 312 with a TPM 468. The target system 312 with TPM then returns the challenge response 470 to SM980 again. SM980 checks the challenge response 476. If the challenge response is incorrect, activation will be terminated and this process will return a failure indication. If the challenge response is correct, the SM980 utilizes the policy passed as metadata with the seed to generate sealed data 334. The SM980 returns to the zone orchestrator 310 a machine-in (sealed data) 336 that authenticates execution.

FIG. 10A shows an alternative security model of an embodiment of the invention in a cloud infrastructure that utilizes SM to provision TEE on AMD processors. In FIG. 9B, customer module 302 has its own trusted infrastructure 350 and uses cloud provider 361. Within the cloud provider, the customer is using the Security Module (SM) 980, which he has control over, and is trusted 350. The rest of the infrastructure of cloud provider 361 is untrusted. Customer module 302 sends a request to those trusted touring 304s to start SVM My-Image. The touring 304 requests secure provisioning from the cloud front end 306 320. Cloud front end 306 confirms paid service 322. Customer touring uploads his image, My-Image, to the cloud object store 982. The cloud object store 308 returns the image identifier, Image-ID of the stored image to the customer touring 304 383. Customer Touring 304 securely inserts a seed, also referred to as detailed or sensitive information, indexed by Image-ID into Security Module (SM) 980. This insertion may contain additional metadata to be associated with the Image-ID. Customer Touring 304 then requests that Zone Orchestrator 310 create an instance of Image-ID 324. The zone orchestrator 310 selects the target machine 312Mach-Ind 1065. The zone orchestrator 310 then requests that the security module 380 verify the target machine 312Mach-Ind 1063. The security module verifies the target machine 1025.

FIG. 10B shows a flow of target system validation (PEF) for TEE in an AMD processor for an alternative model utilizing SM of the embodiment of the invention in cloud infrastructure. FIG. 10B is given the details of the request for verification 1025 of the target machine of FIG. 10A. The 1063 request to validate the Mach-Ind is received from the Zone Orchestrator 310 by the Security Module (SM) 980. Since the target system 312 includes AMD's process for TEE, FIG. 10B is extended to include PSP1003 within the target system, which can be trusted 350 if certified. It is important to note that the PSP is a subordinate component of AMD's processor, extended in FIG. 10B to clarify the flow. Another important point is that the communication between SM and PSP is secure and cannot be forged in either direction. This description is an overview of the process. Details can be found in AMD's white papers and technical documentation available to anyone skilled in the art. The SM issues a request for verification request 1056 to the target system 312, where the request is passed to PSP1003 1058. In response to this request, PSP1003 generates signed data and returns it to processor 312 1092, which processor 312 returns it to SM980 1011. The SM980 extracts the certificate from the response and requests 1027, the AMD Certificate Authority 1054 for verification 1094. AMD Certificate Authority 1054 returns a verification response 1096. If the certificate is not validated, the activation (request to perform a secure VM within the TEE) ends. If the certificate is validated, SM980 requests the Zone Orchestrator 310 to load the VM image into the target system 1029. The zone orchestrator 310 sends the VM image associated with the Image-ID to the target system along with the load image request 1051. The target system 312 loads the VM image into the TEE (not shown). The SM980 issues a VM image Image-ID certification request to the target system 312 in 1057. Target system 312 issues a certification request to trusted PSP1003. PSP1003 generates a proof response and returns it to system 312 1059. The target system returns a proof response to SM980 in 1099. SM verifies the proof response to the hash of the VM 1055. If the verification fails, the activation will end. If the verification is successful, SM980 obtains the certificate (also known as the decryption key) and issues 1091 to insert the certificate into the target system 312. Target system passes 1097 to insert authentication into PSP1003. PSP1003 inserts authentication into TEE. This is successful because the SM980 has issued a system boot to the target system 312, 1093, and the secure computation has been authenticated (the decryption key has been successfully inserted).

11 to 15 show alternative configurations of systems 100, 200, 300, 301, 500, and 800 that can be implemented. The different features shown in the different figures of FIGS. 1 to 15 can be combined, modified or exchanged between different examples.

FIG. 11 preferably comprises at least one processor or central processing unit (CPU) 1110 capable of implementing the techniques of the invention in the form of a software program for software intelligence as a service, information handling according to the invention. Shown is another hardware configuration of the system in which the computer system 1100 resides.

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

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

In addition to the hardware / software environment described above, different aspects of the invention include computer implementation methods for performing the methods described above. As an example, this method can be performed in the particular environment discussed above.

Such a method may be carried out, for example, by operating a computer, such as that embodied by a digital data processing device, to perform a sequence of machine-readable instructions. These instructions may reside within various types of signal holding media.

Thus, this aspect of the invention is a signal that tangibly embodies a program of machine-readable instructions that can be executed by a digital data processor incorporating the CPU 1110 and the hardware described above to implement the method of the invention. It is aimed at programmed products, including retention storage media.

The signal holding storage medium may include RAM housed in the CPU 1110, for example, as represented by high speed access storage.

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

Instructions can be stored on various machine-readable data storage media, whether included in flash memory 1210, optical disc 1220, computer / CPU 1110, or otherwise.

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

The computer-readable storage medium can be a tangible device that can hold and store the instructions used by the instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. .. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erase. Possible Programmable Read-Only Memory (EPROM or Flash Memory), Static Random Access Memory (SRAM), Portable Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD), Memory Stick, Includes mechanically encoded devices such as floppy disks, punch cards on which instructions are recorded or raised structures in grooves, and any suitable combination of the above. Computer-readable storage media as used herein are radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (eg, optical pulses through fiber optic cables), or wiring. It should not be construed as a transient signal itself, such as an electrical signal transmitted via.

The computer-readable program instructions described herein are from computer-readable storage media to their respective computing / processing devices or networks such as the Internet, local area networks, wide area networks, or wireless networks. , Or a combination thereof, may be downloaded to an external computer or external storage device. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives computer-readable program instructions from the network and sends those computer-readable program instructions to the computer-readable storage medium within each computing / processing device. Transfer to be remembered in.

The computer-readable program instructions for performing the operations of the present invention are assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcodes, firmware instructions, state setting data, or Smalltalk (registration). Sources written in any combination of programming languages, including object-oriented programming languages such as C ++, and traditional procedural programming languages such as the "C" programming language or similar programming languages. It can be either code or object code. Computer-readable program instructions are exclusively 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 exclusively. It can be run on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or externally. You may make a connection to your computer (eg, over 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) are computer readable to perform aspects of the invention. By using the state information of a program instruction, a computer-readable program instruction can be executed to personalize an electronic circuit.

Aspects of the invention are described herein with reference to the flow charts and / or block diagrams of the methods, devices (systems), and computer program products according to embodiments of the invention. It will be appreciated that each block of the flow chart and / or block diagram, and the combination of blocks in the flow chart and / or block diagram, can be performed by computer-readable program instructions.

These computer-readable program instructions are functions / operations in which an instruction executed through the processor of a computer or other programmable data processing device is specified in one or more blocks of a flowchart, a block diagram, or both. It may be provided to a general purpose computer, a dedicated computer, or the processor of another programmable data processing device to create a machine so as to create a means of implementation.

These computer-readable program instructions also include instructions in which the computer-readable storage medium in which the instructions are stored performs the mode of function / operation specified in one or more blocks of the flowchart and / or block diagram. It may be stored on a computer-readable storage medium to include the product and can instruct a computer, programmable data processing device, or other device, or a combination thereof, to function in a particular manner. obtain.

Computer-readable program instructions also perform a function / operation in which an instruction executed on a computer, other programmable device, or other device is specified in one or more blocks of a flowchart, a block diagram, or both. As such, it is loaded onto a computer, other programmable data processing device, or other device to create a process performed by the computer, and a series of operating steps on the computer, other programmable device, or other device. It may be something to be executed.

The flowcharts and block diagrams in the figure describe the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products according to various embodiments of the invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or part of an instruction that contains one or more executable instructions for performing a specified logical function. In some alternative implementations, the functions described within the block may be performed in a different order than that shown in the figure. For example, two blocks shown in succession can actually be executed substantially in parallel, or these blocks can sometimes be executed in reverse order, depending on the function involved. Also, each block of the block diagram and / or flow chart, and the combination of blocks in the block diagram and / or flow chart, performs the specified function or operation, or performs a combination of dedicated hardware and computer instructions. It will also be noted that it can be implemented by a dedicated hardware-based system.

Here, with reference to FIG. 13, schematic diagram 1400 of an example of a cloud computing node is shown. The cloud computing node 1400 is merely an example of a suitable cloud computing node and is intended to suggest any limitation with respect to the use or scope of functionality of the embodiments of the invention described herein. Not done. In any case, the cloud computing node 1400 can be implemented, can perform either of the above-mentioned functionality herein, or both. As already mentioned, the trusted execution environment 102 can be implemented in a cloud infrastructure such as FIG. 13 (and also FIGS. 14 and 15). At the cloud computing node 1400, there is a computer system / server 1412 that can operate with a number of other general purpose or dedicated computing system environments or configurations. Examples of well-known computing systems, environments, or configurations or combinations thereof that may be suitable for use with computer systems / servers 1412 include personal computer systems, server computer systems, thin clients, and the like. Thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computers A system and a distributed cloud computing environment including, but not limited to, any of the above systems or devices.

The computer system / server 1412 can be described in the general context of computer system executable instructions executed by the computer system, such as program modules. In general, a program module can include routines, programs, objects, components, logic, data structures, etc. that perform a particular task or implement a particular abstract data type. The computer system / server 1412 may be performed in a distributed cloud computing environment in which tasks are performed by remote processing devices linked over a communication network. In a distributed cloud computing environment, program modules can be located within both local and remote computer system storage media, including memory storage devices.

As shown in FIG. 13, the computer system / server 1412 in the cloud computing node 1400 is shown in the form of a general purpose computing device. A component of a computer system / server 1412 may include one or more processors or processing units 1416, a system memory 1428, and a bus 1418 connecting various system components including system memory 1428 to processor 1416. However, it is not limited to these.

Bus 1418 is of several types, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus that uses one of a variety of bus architectures. Represents one or more of the bus structures of. By way of example, but not limited to, 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.

The computer system / server 1412 typically includes various computer system readable media. Such media may be any available medium accessible to the computer system / server 1412, including both volatile and non-volatile media, removable and non-removable media. included.

The system memory 1428 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1430 and / or cache memory 1432. The computer system / server 1412 may further include other removable / non-removable volatile / non-volatile computer system storage media. As a mere example, a storage system 1434 may be provided for reading and writing to a non-removable non-volatile magnetic medium (typically referred to as a "hard drive" (not shown)). Although not shown, magnetic disk drives for reading and writing to removable non-volatile magnetic disks (eg, "floppy disks"), as well as CD-ROMs, DVD-ROMs, or other optical media. It is possible to provide an optical disk drive for reading and writing to a removable non-volatile optical disk such as. In such an example, each may be connected to bus 1418 by one or more data medium interfaces. As further described and described below, the memory 1428 has at least one program product comprising a set of (eg, at least one) program modules configured to perform the functions of the embodiments of the present invention. May include.

A program / utility 1440 with a set (at least one) program module 1442 may be stored in memory 1428 as an example, but not limited to, an operating system, one or more application programs, and other programs. It can also be stored in modules and program data. The operating system, one or more application programs, other program modules, and each of the program data, or any combination thereof, may include an implementation of a networking environment. The program module 1442 generally implements the functions or methodologies or combinations thereof of embodiments of the invention as described herein.

The computer system / server 1412 may also be one or more external devices 1414 such as keyboards, pointing devices, displays 1424, etc., one or more devices that allow interaction between the user and the computer system / server 1412. Alternatively, it may communicate with any device (eg, network card, modem, etc.) that allows communication between the computer system / server 1412 and one or more other computing devices, or a combination thereof. Such communication can be performed via the input / output (I / O) interface 1422. Furthermore, the computer system / server 1412 may be a local area network (LAN), a general wide area network (WAN), or a public network (eg, the Internet), or a public network thereof (eg, the Internet), via a network adapter 1420. It may communicate with one or more networks, such as a combination. As depicted, the network adapter 1420 communicates with other components of the computer system / server 1412 via bus 1418. Although not shown, it should be understood that other hardware and / or software components may be used in combination with the computer system / server 1412. Examples include, but are not limited to, microcodes, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems, etc. ..

Here, with reference to FIG. 14, an exemplary cloud computing environment 1550 is depicted. As shown, the cloud computing environment 1550 includes one or more cloud computing nodes 1400, which can be used by local computing devices used by cloud users, such as, for example. A mobile information terminal (PDA) or a mobile phone 1554A, a desktop computer 1554B, a laptop computer 1554C, or an automobile computer system 1554N, or a combination thereof, can perform communication. Nodes 1400 may communicate with each other. These may be physically or virtually grouped in one or more networks, such as a private, community, public, or hybrid cloud, or a combination thereof, as described herein above. (Not shown). This allows the cloud computing environment 1550 to provide infrastructure, platforms, software, or a combination thereof, as a service that allows cloud users to maintain resources on their local computing devices. Will be possible. The computing device types 1554A-1554N shown in FIG. 14 are intended to be merely exemplary, and the computing node 1400 and cloud computing environment 1550 are any type of network or ( It is understood that it is possible to communicate with any type of computerized device via a network addressable connection (eg using a web browser) or both.

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

The hardware and software layer 1600 includes hardware and software components. Examples of hardware components are mainframes, for example IBM zSeries systems, RISC (Reduced Instruction Set Computer) architecture-based servers, for example IBM pSeries systems, IBM xSeries® systems, etc. Included are IBM Hardware Center® systems, storage devices, network and networking components. Examples of software components include network application server software, IBM WebSphere® application server software and database software, and IBM DB2 database software, for example. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation, registered in many jurisdictions around the world).

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

In one example, management layer 1630 may provide the functions described below. Resource provisioning provides dynamic procurement of computing resources and other resources used to perform tasks within a cloud computing environment. Metering and pricing track the cost of resources being used in a cloud computing environment and bill or invoice for the consumption of these resources. In one example, these resources may include application software licenses. Security provides the verification of identity information about cloud users and tasks, as well as the protection of data and other resources. The user portal provides users and system administrators with access to the cloud computing environment. Service level management provides the allocation and management of cloud computing resources to meet the required service level. Service level agreement (SLA) planning and implementation provides pre-adjustment and procurement of cloud computing resources that are expected to be needed by SLA in the future.

The workload layer 1640 provides an example of functionality in which a cloud computing environment can be utilized. Examples of workloads and features that can be provided from this layer are mapping and navigation, software development and lifecycle management, virtual classroom education delivery, data analysis processing, transaction processing, and more specifically APIs for the present invention. And features such as a run-time system component that generates search autocomplete candidates based on contextual input.

Cross-reference to related applications This application is a related application of US Patent Application Nos. 17 / 130,238, IBM Reference No. P202005407US01, each of which was filed on December 22, 2020, and is in its entirety. Is incorporated herein by reference.

Many features and advantages of the invention are evident from the detailed description, and therefore, within the scope of the appended claims, all such features and advantages of the invention within the true ideas and scope of the invention. Intended to be included. Moreover, it is not desired to limit the invention to the exact structures and operations illustrated and described, as many modifications and variations are readily conceivable to those of skill in the art, and therefore the invention. Any suitable modifications and equivalents within the scope of can be utilized.

It should be understood that the invention is not limited to the details of the structures described in the following description or illustrated in the drawings and the arrangement of components in its application. The present invention is capable of embodiments other than those described, as well as implementation and practice in various modes. It should also be understood that the terminology and terminology used herein and in the abstract is for explanatory purposes only and should not be considered limiting.

Accordingly, one of ordinary skill in the art will appreciate that the concepts on which the present disclosure is based can be readily utilized as the basis for the design of other structures, methods, and systems for carrying out some of the objects of the invention. Will do. Therefore, it is important that the claims are considered to include such equivalent structures as long as they do not deviate from the ideas and scope of the invention.

100 System 102 TEE, Trusted Execution Environment 104 Trusted Software 106 Application 108 Operating System 110 Processing Function 112 TEE API
114 Processor B
116 Memory, Trusted Memory 120 Hardware 122 Certification Function 130 Software Section, Software 200 System 300 System 301 System, Trusted Hardware 302 Customer, Customer Module 304 Touring Module, Tooling 306 Cloud Front End 308 Cloud Cloud Object Store 310 Zone Orchestrator, Zone Orchestrator Module 312 Target System 318 VM Image_ID, SVM My-Image
325 Target Machine 326 Storage Key 338 Image-ID
340 Image associated with Image-ID 342 Sealed data 344 Image 350 Trusted Infrastructure 361 Untrusted Cloud Infrastructure, Cloud Provider 380 Security Module 416 VM
464 Challenge 466 Challenge 470 Response to Challenge, Challenge Response 472 Challenge 474 Response to Challenge 476 Challenge Response 482 My-Image
483 Image-ID
500 System 540 Policy 544 Policy 673 Sealed data 675 Sealed data 677 Integrity information 679 Customer data 685 Sensitive information 678 Secret 689 Payload, payload area 691 ESM operand 772 Immutable code 774 SB validation code 777 Variable boot loader Boot loader 780 Host boot Init.
782 Host Boot Ext.
784 OPAL
786 PCR6
788 Hardware Key Hash 790 Secure Boot Jumper 792 Separator 794 PEF Enable Bit 800 System 852 Orchestrator Module 854 VM
856 SVM, image copy 858 Library 860 Vendor 862 TPM
864 Target Machine, Target System 866 SM, Security Module 868 Machine Set 870 Cloud Infrastructure 980 SM, Security Module, SM Hyper Protect
983 Image-ID
1003 PSP
1054 AMD Certificate Authority 1100 Information Handling / Computer System 1110 Central Processing Unit, CPU
1112 Bus 1114 Random Access Memory 1116 Read-Only Memory 1118 Input / Output (I / O) Adapter 1121 Disk Unit 1122 User Interface Adapter 1124 Keyboard 1126 Mouse 1128 Speaker 1132 Microphone 1134 Communication Adapter 1136 Display Adapter 1138 Display Device 1139 Printer 1140 Tape Drive 1200 Signal Retention Storage Medium 1210 Flash Memory 1220 Optical Storage Discet 1400 Cloud Computing Node 1412 Computer System / Server 1414 External Device 1416 Processor or Processing Unit 1418 Bus 1420 Network Adapter 1422 Input / Output (I / O) Interface 1424 Display 1428 System Memory 1430 Random Access Memory 1432 Cache Memory 1434 Storage System 1440 Program / Utility 1442 Program Module 1550 Cloud Computing Environment 1554A Mobile Information Terminal (PDA) or Mobile Phone 1554B Desktop Computer 1554C Laptop Computer 1554N Automotive Computer System 1600 Hardware and Software Layer 1620 Virtualization Layer 1630 Management Layer 1640 Workload Layer

Claims (20)

A method for generating a computation to run in a targeted trusted execution environment (TEE).
Selecting the target TEE and
To generate a certificate that TEE is happy with,
To associate the certification with the computation running within the TEE to be authenticated.
A method comprising generating the computation with the associated authentication. Further comprising selecting an attribute to be incorporated into the certification for the TEE that is valid.
The method according to claim 1. The method of claim 1 or 2, wherein the generation of the certification utilizes a security module (SM). The method of any one of claims 1 to 3, wherein associating the authentication with the computation comprises dynamically inserting information into the computation. The method of claim 3, wherein the customer securely inserts the secret into the SM, the secret comprising metadata indicating which secure computation the secret is associated with. The customer has the control capability of the SM.
The method according to claim 5. The SM inserts the authentication into the target TEE,
The method according to claim 3. The method of any one of claims 1-7, wherein the TEE is in the cloud or local infrastructure. The method of claim 8, wherein the SM is used as part of the cloud or local infrastructure. The method according to any one of claims 1 to 9, wherein the detailed information about the cloud infrastructure or the detailed information about the TEE is disclosed only to the security module. 13. the method of. At least a portion of the computation is encrypted, and encrypting a portion of the computation comprises encrypting the information necessary to check the integrity of the computation. Item 10. The method according to any one of Items 1 to 11. The method of any one of claims 1-12, wherein the authentication constrains the computation to a particular TEE among a plurality of TEEs. The method of any one of claims 1-13, further comprising provisioning the generated computation. It ’s a system,
Memory for storing computer instructions and
The computer instruction,
Select the Target Trusted Execution Environment (TEE) and select
Generates a certificate that TEE is happy with,
Associating the certification with the computation running within the TEE being authenticated,
A system comprising a processor that is configured to perform to generate a computation using the associated authentication. It further comprises selecting the attributes to be incorporated into the certification for the TEE that are valid.
The generation of the certification utilizes a security module (SM) and
Associating the authentication with the Computation involves dynamically inserting information into the Computation.
The customer securely inserts the secret into the SM, which contains metadata indicating which secure computation the secret is associated with.
The customer has the control capability of the SM and
The security module inserts the authentication into the target TEE.
The system according to claim 15. The TEE is in the cloud or local infrastructure and
SM is used as part of the cloud or local infrastructure,
Detailed information about the selected TEE is disclosed only to the SM.
The SM stores a list of pre-generated authentications if the authentication was pre-generated for the selected target TEE, and the SM is not regenerated.
At least part of the computation is encrypted, and encrypting part of the computation involves encrypting the information needed to check the integrity of the computation.
The authentication constrains the computation to a particular TEE among a plurality of TEEs.
The system further
15. The system of claim 15 or 16, comprising provisioning said computing to be generated. On the computer
Procedures for selecting the Target Trusted Execution Environment (TEE),
The procedure for generating a certificate that TEE is satisfied with, and
The procedure for associating the certification with the computation running within the TEE to be authenticated.
A computer program for performing a procedure for generating a computation using the associated authentication. To the computer
Further performing the procedure of selecting the attribute to be incorporated in the authentication for the TEE that is valid is performed.
The procedure for generating the certification utilizes a security module (SM).
The procedure for associating the authentication with the computation comprises dynamically inserting information into the computation.
The customer securely inserts the secret into the SM, which contains metadata indicating which secure computation the secret is associated with.
The customer has the control capability of the SM and
The computer program of claim 18, wherein the SM inserts the authentication into the target TEE. The TEE is in the cloud or local infrastructure and
SM is used as part of the cloud or local infrastructure,
Detailed information about the selected TEE is disclosed only to the security module.
The SM stores a list of pre-generated authentications if the authentication was pre-generated for the selected TEE, and the SM is not regenerated.
At least part of the computation is encrypted, and encrypting part of the computation involves encrypting the information needed to check the integrity of the computation.
The authentication constrains the computation to a particular TEE among a plurality of TEEs.
To the computer
The computer program of claim 18 or 19, further performing a procedure for provisioning the generated computation.

Images