Secure Guest Verification

Abstract

A trusted execution environment obtains an attestation request, the attestation request including at least an attestation key. One or more integrity measurements are calculated based on obtaining the attestation request, the calculation using at least the attestation key. The one or more integrity measurements are provided to an entity, and the one or more integrity measurements are used to verify that a secure guest was started using a selected secure guest image and selected secure guest metadata.

Description

Technical Field

[0001] One or more aspects generally relate to facilitating processing within a computing environment, and more particularly to improving such processing.

Background Art

[0002] A computing environment may support virtualization, in which a hypervisor or virtual machine manager of the computing environment hosts various guests such as virtual machines or virtual servers of the computing environment. A virtual machine has access rights to system resources and can execute an operating system such as a guest operating system. Various guests can be owned by various owners, and some of these guests can be secure guests.

[0003] Conventional hypervisors have complete control over hosted guests. In particular, a hypervisor even has the ability to inspect and modify the memory of a hosted guest. However, a secure guest is a guest that can be hosted by a hypervisor that cannot be fully trusted. The image of such a secure guest is protected when it is loaded, and the protection of the contents of resources (e.g., memory, CPU registers) assigned to the guest is maintained throughout the lifetime of the guest. Guest protection includes at least integrity protection (e.g., the hypervisor cannot maliciously change the state of any guest), and in addition, can include maintaining the confidentiality of the initial image, code, and data being executed in the secure guest.

[0004] The user of a secure guest may desire to obtain specific information related to the secure guest. Therefore, the processes used to obtain such information should be facilitated.

Summary of the Invention

[0005] The provision of computer program products that facilitate processing within a computing environment overcomes the shortcomings of prior art and brings additional advantages. A computer program product includes one or more computer-readable storage media and program instructions collectively stored in one or more computer-readable storage media to perform a method. This method includes obtaining a proof request from a trusted execution environment. The proof request includes at least a proof key. Based on obtaining the proof request, one or more integrity measures are calculated, this calculation using at least the proof key. One or more integrity measures are provided to an entity. One or more integrity measures are used to verify that a secure guest was started using a selected secure guest image and selected secure guest metadata. This allows the requesting entity to confirm that the secure guest is the correct secure guest, thereby bringing further security to the computing environment.

[0006] In one example, a proof request includes an integrity-protected proof request structure, where the proof key is maintained within the encrypted portion of the proof request structure. This provides protection for the proof request structure, the proof key, and the processing associated with them. This protection ensures that the proof request structure cannot be altered during transmission from the requesting entity to a trusted execution environment, and that the data within the encrypted portion of the proof request structure remains confidential during transmission.

[0007] For example, a proof request structure is exclusively interpretable by a trusted execution environment. The integrity protection of the proof request structure is verified, and based on the success of the verification of the proof request structure, the trusted execution environment obtains a proof key used to decrypt the encrypted portion of the proof request structure and compute one or more integrity measures. Security is maintained by verifying the integrity protection. If the verification fails, the processing of the proof request fails.

[0008] In one example, providing one or more integrity metrics further includes providing selected information about a trusted execution environment used to validate a secure guest. This selected information may include, for example, runtime data of the secure guest.

[0009] Furthermore, in one example, one or more integrity metrics include a computed verification code calculated based on at least the secure guest image and one or more secure guest metadata. For example, the computed verification code is further calculated based on the secure guest's runtime data. The secure guest's runtime data includes, for example, unique identification information of the running instance of the secure guest that issued the proof request. This data is also returned to the requesting entity by including data to identify the running instance of the secure guest in the returned integrity metrics. The requesting entity can then use this data to determine whether multiple (e.g., two) requests have been processed by a trusted execution environment for the same instance of the secure guest.

[0010] In one example, the calculated verification code is further calculated based on specific data of the secure guest.

[0011] In one example, a proof request is obtained from a secure guest via an uninterceptable call to a trusted execution environment. Furthermore, in another example, the proof request contains specific data from the secure guest. This specific data from the secure guest is used, along with the proof key, to compute one or more integrity measures.

[0012] Furthermore, in one example, the entity is a secure guest, and providing further includes providing runtime data of the secure guest to the secure guest. In one example, runtime data of the secure guest, one or more integrity metrics, and specific data of the secure guest are further provided to the requesting entity for use in verifying the secure guest.

[0013] For example, specific data for a secure guest includes session information for a session used by the requesting entity to connect to the secure guest and submit a proof request structure to the secure guest, which is used in the proof request.

[0014] In one example, a proof request is obtained from a secure guest via an uninterceptable call by a trusted execution environment. The uninterceptable call includes, for example, a proof request structure containing the proof key and specific data of the secure guest.

[0015] Computer implementation methods and systems related to one or more embodiments are also described and claimed herein. Furthermore, services related to one or more embodiments may also be described and claimed herein.

[0016] Further features and advantages are realized by the technologies described herein. Other embodiments and aspects are described in detail herein and are considered to be part of the claimed embodiments.

[0017] One or more embodiments are specifically pointed out and expressly claimed as examples in the claims at the end of this specification. The foregoing, as well as the purposes, features, and advantages of one or more embodiments, will become apparent from the following detailed description, made in conjunction with the accompanying drawings. [Brief explanation of the drawing]

[0018] [Figure 1] This figure shows one example of a computing environment for using one or more embodiments of the present invention. [Figure 2] This figure shows one example of a certification inquiry according to one or more embodiments of the present invention. [Figure 3] This figure shows one example of a description relating to a proof request structure used according to one or more aspects of the present invention. [Figure 4A] This figure shows one example of processing a proof request according to one or more embodiments of the present invention. [Figure 4B] This figure shows one example of processing a proof request according to one or more embodiments of the present invention. [Figure 5] This figure shows one example of a proof process according to one or more embodiments of the present invention. [Figure 6A] This figure shows one example of facilitating processing within a computing environment according to one or more aspects of the present invention. [Figure 6B] This figure shows one example of facilitating processing within a computing environment according to one or more aspects of the present invention. [Figure 6C] This figure shows one example of facilitating processing within a computing environment according to one or more aspects of the present invention. [Figure 7A] This figure shows another example of a computing environment for using one or more embodiments of the present invention. [Figure 7B] This figure shows further details of the memory shown in Figure 7A, according to one or more embodiments of the present invention. [Figure 8]A diagram showing one embodiment of a cloud computing environment according to one or more aspects of the present invention. [Figure 9] A diagram showing one example of an abstract model layer according to one or more aspects of the present invention. **DETAILED DESCRIPTION OF THE INVENTION**

[0019] According to one or more aspects of the present invention, a capability is provided to facilitate processing within a computing environment. By way of example, this capability includes facilitating verification that a secure guest is, for example, a particular secure guest initiated using a particular secure guest image and secure guest metadata. In one example, verification regarding a session on the secure guest is provided that, for example, cannot be performed by an intermediary system. In a further aspect, this capability includes facilitating determination as to whether multiple (e.g., two) instances of a secure guest are instances of the same secure guest.

[0020] One embodiment of a computing environment incorporating and using one or more aspects of the present invention is described with reference to FIG. 1. By way of example, the computing environment is based on the z / Architecture(R) instruction set architecture provided by International Business Machines Corporation, Armonk, N.Y. One embodiment of the z / Architecture instruction set architecture is described in a publication entitled "z / Architecture Principles of Operation," IBM Publication No. SA22-7832-12, Thirteenth Edition, September 2019, which is hereby incorporated by reference in its entirety. However, the z / Architecture instruction set architecture is only one exemplary architecture, and other architectures or other types of computing environments, or both, of International Business Machines Corporation or other entity or entities may include, or use, or both, one or more aspects of the present invention. z / Architecture and IBM are trademarks or registered trademarks of International Business Machines Corporation in at least one jurisdiction.

[0021] Referring to Figure 1, in one example, the computing environment 100 includes a central processor complex (CPC) 102. The central processor complex 102 is, for example, an IBM Z(R) server (or other server or machine provided by International Business Machines Corporation or other entity) and includes several components, such as one or more processor units (also called processors) 110 and memory 104 (also called system memory, main memory, primary memory, central memory, or storage) coupled to an input / output (I / O) subsystem 111. Examples of processor units 110 include one or more general-purpose processors (also known as central processors or central processing units (CPUs)) or one or more other processors or both. IBM Z is a trademark or registered trademark of International Business Machines Corporation in at least one jurisdiction.

[0022] The I / O subsystem 111 may be part of the central processing unit complex or it may be separate from the central processing unit complex. The I / O subsystem 111 directs the flow of information between the main memory 104 and the input / output control unit 108 and input / output (I / O) devices 106 which are coupled to the central processing unit complex.

[0023] Many types of I / O devices may be used. One particular type is a data storage device 110. The data storage device 110 can store one or more programs 142, one or more computer-readable program instructions 144, or data, or a combination thereof. The computer-readable program instructions may be configured to perform functions of embodiments of the present invention.

[0024] The central processing unit complex 102 may include, or be coupled to, a removable / non-removable, volatile / non-volatile computer system storage medium, or both. For example, the central processing unit complex 102 may include, or be coupled to, a magnetic disk drive for reading and writing to a non-removable, non-volatile magnetic medium (commonly called a “hard drive”), a removable, non-volatile magnetic disk (e.g., a “floppy disk”), or an optical disk drive for reading or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM, or other optical medium, or a combination thereof, or both. It should be understood that other hardware components or software components, or both, may be used in conjunction with the central processing unit complex 102. Examples include, but are not limited to, microcode or millicode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems.

[0025] Furthermore, the central processing unit complex 102 can be operated in 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 the central processing unit complex 102 include, but are not limited to, personal computer (PC) systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, microcomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of these systems or devices.

[0026] The central processing unit complex 102 supports virtualization in one or more embodiments, and virtualization support includes, for example, memory 104, one or more virtual machines 112 (also called guests), a virtual machine manager such as a hypervisor 114 that manages the virtual machines, a trusted execution environment 115 (also called an ultravisor), and processor firmware 116. One example of a hypervisor 114 is the z / VM(R) hypervisor provided by International Business Machines Corporation (Armonk, New York). A hypervisor is sometimes referred to as a host. z / VM is a trademark or registered trademark of International Business Machines Corporation in at least one jurisdiction.

[0027] In one or more embodiments, the trusted execution environment 115 may be at least partially implemented in hardware or firmware, or both, configured to run processes such as those described herein. The trusted execution environment is trusted firmware or hardware, or both, that implements memory protection using memory protection hardware. The guest owner can securely pass information to the trusted execution environment (e.g., using IBM Secure Execution) by using a public host key embedded in a host key document. To process sensitive information, the trusted execution environment uses a matching private host key. The private host key is unique to the server (e.g., an IBM Z(R) server) and is hardware protected.

[0028] The processor firmware 116 includes, for example, the processor's microcode or millicode. The processor firmware 116 also includes, for example, hardware-level instructions or data structures, or both, used in the implementation of higher-level machine code. In one embodiment, the processor firmware 122 includes, for example, proprietary code that controls the operating system's access to the system's hardware, typically provided as microcode or millicode specific to the underlying hardware, including trusted software.

[0029] The Central Processing Unit's support for virtual machines provides the ability to operate a large number of virtual machines 112, each virtual machine 112 which can run with a different program 120 and execute a guest operating system 122 such as the Linux(R) operating system. Each virtual machine 112 can function as a separate system; that is, each virtual machine can be reset independently, execute a guest operating system, and run with a different program. An operating system or application program running within a virtual machine appears to have access to the entire system, but in reality, only a portion of it is available. While z / VM and Linux are provided as examples, other virtual machine managers and / or operating systems may be used according to one or more aspects of the present invention. The registered trademark Linux(R) is used in accordance with a sublicense from the Linux Foundation (exclusive licensee of Linus Torvalds, the worldwide trademark owner).

[0030] In one embodiment, one or more guests 112 are secure guests. Referring to Figure 2, the secure guest 200 is started by a hypervisor (e.g., hypervisor 114) in a manner that prevents the hypervisor from observing the state of the secure guest (e.g., memory, registers, etc.). For example, in one embodiment of confidential computing, the hypervisor can start / stop the secure guest, and the hypervisor identifies where the data used to start the secure guest is located, but cannot see inside the running secure guest. The data used to load / start the secure guest may be encrypted in a manner that prevents the hypervisor from seeing the secure guest. The owner of the secure guest image places the confidential data in the secure guest metadata and then generates the secure guest image with the secure guest metadata. After the secure guest is loaded, all information exchange with the state of the secure guest is handled by a trusted execution environment, such as a trusted execution environment 115.

[0031] In one embodiment, to start a secure guest, the hypervisor passes the secure guest image 210 and secure guest metadata 220, which the hypervisor has already loaded into memory, to a trusted execution environment 115. This metadata is integrity-protected, at least partially confidential, and interpreted only by the trusted execution environment. The trusted execution environment can then enforce the integrity of the secure guest image loaded into memory based on the information in the secure guest metadata, protect the secure guest memory containing the loaded image from becoming accessible by the hypervisor, and, if applicable, decrypt the secure guest image before starting the secure guest.

[0032] After loading or starting a secure guest, it may be desirable to verify that the secure guest is a specific secure guest started using, for example, a specific secure guest image and secure guest metadata. Therefore, according to one or more aspects of the present invention, a query is made regarding whether a secure guest is a specific secure guest (250). For example, this query is made by a requesting entity, such as the user or owner of the secure guest. To provide an answer to such a query, information is collected, and one or more metrics (e.g., hashes, message authentication codes, cryptographic signatures, etc.) are calculated and used to determine whether the secure guest is a specific secure guest (e.g., by a requesting entity outside the secure guest). In one example, a proof request structure is used to calculate one or more metrics. The proof request structure is prepared outside the secure guest, for example, by the user or owner of the secure guest.

[0033] One example of a description related to a proof request structure is illustrated with reference to Figure 3. As shown in Figure 3, in one example, a description 300 related to a proof request structure (also referred to herein as the proof request structure description 300) includes several entries 302, each entry 302 including a name 310, an abbreviation (abbreviation) 312, and a brief description (content) 314 of the entry, in addition to a protection instruction (protection) 316 indicating whether the content (e.g., content 314) is integrity protected or whether it is both integrity protected and confidential (e.g., encrypted) by a proof protection key that can only be obtained by the system under consideration. In one example, content 314 includes data / attributes of the proof structure, and the name 310, abbreviation 312, and protection instruction 316 provide information related to content 314.

[0034] For example, one entry 318 of the proof request structure contains the customer public key (provided by the requesting entity), and one or more other entries 320 contain key slots 1 to N, each containing the host key / request protection key protected by a trusted execution environment for the target host. The customer public key and key slots are used to securely transmit the request protection keys (e.g., using the Diffie-Hellman (elliptic curve) technique) for a set of possible target systems to a trusted execution environment, with each key slot specifying the address of one target system. As a further example, another entry 322 of the proof request structure description contains the proof key, abbreviated as AK (see abbreviation 312), which is, for example, a 512-bit hash-based message authentication code (HMAC) key (see content 314) and is encrypted as indicated by the protection instruction 316. An additional entry 324 of the proof request structure contains a request structure tag containing data that may be used to verify the integrity of the request structure. Additional information, less information, or other information, or a combination thereof, may be included in the Proof Request Structure Description 300. The Proof Request Structure Description 300 may contain additional entries, fewer entries, or other entries, or a combination thereof, or each entry may contain additional information, less information, or other information, or a combination thereof, or both. Furthermore, the Proof Request Structure (e.g., Content 314) may contain additional data / attributes, fewer data / attributes, or other data / attributes, or a combination thereof. Many possibilities exist.

[0035] The proof request structure is used to verify or prove that a secure guest is a specific secure guest, according to one or more aspects of the present invention. One example of this process is illustrated with reference to Figures 4A and 4B.

[0036] Referring first to Figure 4A, in one example, a proof request structure 400, prepared outside the secure guest and containing, for example, a proof key 402 (for example, containing content similar to content 314), is retrieved by the secure guest 410 (for example, sent, provided, received, retrieved, etc.). The secure guest 410 then calculates local data 412 (for example, connection information or other information or both) from, for example, the state of the secure guest. For example, the local data is specific to the secure guest and includes session information used by, for example, an entity requesting to connect to the secure guest (for example, requesting verification) when submitting a proof structure to the secure guest.

[0037] Furthermore, the secure guest 410 executes a call 414 to the trusted execution environment 420. This call includes, for example, a proof request structure and local data. The trusted execution environment receives this call with arguments containing the proof request structure (e.g., receive, provide, extract, etc.). The trusted execution environment uses a system-specific private key (also known as the host key) 424 to check the integrity of the proof request structure. For example, a request protection key is extracted from one of the key slots described herein, and that key is used to perform the request integrity check. Based on the success of the verification, the trusted execution environment continues executing the proof request, which includes first extracting the proof key 402 contained in the request structure.

[0038] The trusted execution environment determines runtime data 422 of the trusted execution environment, such as, for example, the identifier of the secure guest instance (e.g., unique identification information of the running instance of the secure guest that issued the proof request) and the firmware version. The trusted execution environment 420 further obtains one or more measurements 430 of the secure guest image 432 and secure guest metadata 434 (e.g., hash, message authentication code, cryptographic signature, etc.).

[0039] Referring to Figure 4B, upon receiving a call, the trusted execution environment 420 uses the proof key 402 to determine proof data, such as a verification tag (e.g., a message authentication code tag), with respect to one or more measurement results 430, local data 412, and runtime data 422 of the trusted execution environment. This proof data, along with the runtime data 422 of the trusted execution environment, is returned to the secure guest 410. The secure guest then returns the proof data (e.g., proof data 450), the runtime data 422 of the trusted execution environment, and the local data 412 to an external requesting entity (e.g., the user or owner of the secure guest, or another entity). The proof data 450 is, for example, integrity-protected by the proof key and evaluated by, for example, an external requesting entity.

[0040] Further details of one embodiment of the verification process used to verify that a secure guest is a specific secure guest containing specific secure guest metadata are illustrated with reference to Figure 5.

[0041] In one embodiment, the requesting entity (also referred to herein as the requester), such as the owner, user, or other entity of the secure guest, has knowledge of one or more measurements of the secure guest image and secure guest metadata (e.g., hash, message authentication code, cryptographic signature, etc.) (500). The requesting entity generates, for example, a proof key and includes this proof key in a proof request structure (502). The proof request structure may be generated by the requesting entity, another entity, or an existing entity. The proof request structure includes the proof key and optionally other information as described herein. The requesting entity sends the proof request to a secure guest that has a defined relationship with the requesting entity (e.g., owned by the requesting entity) (504).

[0042] The secure guest receives a proof request, for example, which includes a proof request structure, and determines local data specific to the secure guest (506). For example, the local data includes session information for a session used by an entity that is requesting to connect to the secure guest (for example, requesting verification) when submitting a proof structure to the secure guest. Furthermore, the secure guest invokes trusted execution environment functions using the proof request structure and local data specific to the secure guest as arguments to the call (508).

[0043] A trusted execution environment receives a call containing a proof request structure and local data and checks the integrity of the proof request structure (510). For example, a trusted execution environment determines the measurement result of the proof request structure (e.g., hash, message authentication code, cryptographic signature) and compares it to the corresponding known value. If the measurement result has a predefined relationship with the known value (e.g., equal), the integrity of the proof request structure is verified. The proof request structure may contain a claim protection key (e.g., message authentication code, signature) used to protect the measurement result, which is protected by a system-specific private key (also known as a host key) available to the trusted execution environment.

[0044] Based on the successful verification of the integrity of the proof request structure, the trusted execution environment decrypts the encrypted portion of the proof request structure (e.g., using the proof protection key) and extracts the proof key from the encrypted portion. The trusted execution environment uses the proof key to compute at least one integrity measure, such as a verification tag (also called a tag, e.g., a message authentication code tag), which represents a combination of the secure guest image, one or more secure guest metadata metrics, the secure guest's local data, and the runtime data of the secure guest's trusted execution environment (512). The computation of the integrity measure may use one or more techniques that are currently known or will be developed in the future. The trusted execution environment returns the computed integrity measure (e.g., the verification tag) and the runtime data of the secure guest's trusted execution environment (e.g., unique identification information of the running instance of the secure guest that issued the proof request) to the secure guest (516).

[0045] The secure guest returns to the requesting entity the calculated integrity measurements (e.g., verification tags such as message authentication code tags), runtime data from the secure guest's trusted execution environment, and local data from the secure guest (e.g., session information) (520).

[0046] The requesting entity receives the returned data (522), which may be used to determine whether the secure guest is a specific secure guest. For example, the secure guest owner compares the retrieved verification tag (e.g., calculated in 512 and returned in 516, 520) to a known value (e.g., an existing value or a calculated value), and if those values ​​have a predefined relationship (e.g., equal), the secure guest is verified to be a specific secure guest containing specific secure guest metadata.

[0047] As described herein, for example, an attestation trusted execution environment call is provided, which can only be called from secure guests. This call takes, for example, an attestation request structure (or at least an attestation key) and selected local data (e.g., session information) as arguments and returns, for example, runtime data specific to the trusted execution environment (e.g., a unique ID of the running instance of the secure guest that issued the attestation request) and verification tags of one or more secure guest measurements (e.g., message authentication codes or other measurements), local data, and runtime data for a particular trusted execution environment calculated using an attestation key, such as a message authentication code key.

[0048] A valid secure guest invokes the function using the received certification request structure prepared by the requesting entity, and local data (e.g., data specific to the session used to receive the request, e.g., the client certificate for the SSH (Secure Shell) or TLS (Transport Layer Security) session initiated by the user). The trusted execution environment receives this invoke, determines the result (e.g., a verification tag), and returns this result to the secure guest. The secure guest passes the result of the certification function to the requesting entity, which can then verify this result as identifying both the secure guest and the session used to log in to the secure guest.

[0049] In one or more embodiments, a proof request structure is defined, which is protected, for example, by a request protection key. The request protection key is securely transmitted to a trusted execution environment using the private key (also known as the host key) of the trusted execution environment. Optionally, if a chosen technique (e.g., elliptic curve Diffie-Hellman) is used to transmit the request protection key, the request structure includes the customer's public key. Part of the request is protected (encrypted) using the request protection key, and that part includes, for example, a proof key (e.g., a message authentication code key) and an optional nonce. In one example, the request structure includes instructions on which measurements must be proven.

[0050] In a further embodiment, a certification function callable from the secure guest is added to the trusted execution environment. The certification function takes, for example, a certification request structure as an argument. Optionally, the certification function takes a second argument concerning local data specific to the secure guest. This function uses a certification key to return, for example, one or more measurements of the secure guest image, metadata of the secure guest image, any additional data defined by the request, and optionally, local data from the second argument to the function, all linked together via a message authentication code.

[0051] In a further embodiment, a service is provided to offer remote certification functionality in a valid secure guest in order to protect against man-in-the-middle systems. This service, for example, takes a request structure received within the session as an argument. This service derives connection / session-specific data and issues a request (session-specific data may be derived from the certificate of the client that initiated the connection / session, the session number, etc.). This service invokes a trusted execution environment certification call, using the request structure as one argument and the certificate as the other argument.

[0052] In one embodiment, data that may be optionally selected within the request structure to be included in the measurement results may include, for example, a public key belonging to a private key used by a trusted execution environment to unpack the secure guest metadata when starting the secure guest, a firmware release, or a secure guest ID, or a combination thereof.

[0053] A valid secure guest may use the function to receive a request structure prepared by the requesting entity or another entity, and may use data specific to the session used to receive the request (e.g., a client certificate for a user-initiated secure shell session or transport layer security session) as local data. The valid secure guest passes the result of the authentication function to the requesting entity, which can then verify this result to identify both the secure guest and the session used to log in to the secure guest.

[0054] One or more aspects of the present invention are closely related to computer technology and facilitate processing within a computer, improving its performance. Processing is facilitated by the ability to validate secure guests and provide protection to the computing environment.

[0055] Since the processing within the computing environment is related to one or more aspects of the present invention, further details of one embodiment that facilitates such processing will be described with reference to Figures 6A to 6C.

[0056] Referring to Figure 6A, in one embodiment, a trusted execution environment obtains a proof request (600). The proof request includes at least a proof key (602). Based on obtaining the proof request, one or more integrity measures are calculated, which use at least the proof key (604). One or more integrity measures are provided to an entity (606), and one or more integrity measures are used to verify that the secure guest was started using the selected secure guest image and selected secure guest metadata (608). This allows the requesting entity to verify that the secure guest is the correct secure guest, thereby bringing further security to the computing environment.

[0057] In one example, a proof request includes an integrity-protected proof request structure (610), and the proof key is maintained within an encrypted portion of the proof request structure (612). This provides protection for the proof request structure, the proof key, and any associated processing.

[0058] For example, a proof request structure is exclusively interpretable by a trusted execution environment (614). The integrity protection of the proof request structure is verified (615), and based on the success of the verification of the proof request structure, the trusted execution environment obtains a proof key used to decrypt the encrypted portion of the proof request structure and compute one or more integrity measures (616). Security is maintained by verifying the integrity protection. If the verification fails, processing of the proof request fails.

[0059] In one example, providing one or more integrity metrics further includes providing selected information about a trusted execution environment used to validate a secure guest (618). The selected information includes, for example, runtime data of the secure guest (620).

[0060] Furthermore, in one example, referring to Figure 6B, one or more integrity measures include a computed verification code calculated based on at least the secure guest image and one or more secure guest metadata (630). For example, the computed verification code is further calculated based on the secure guest runtime data (632). The secure guest runtime data includes, for example, unique identification information of the running instance of the secure guest that issued the proof request (634). By including data to identify the running instance of the secure guest in the returned integrity measure, this data is also returned to the requesting entity. The requesting entity can then use this data to determine whether multiple (e.g., two) requests have been processed by a trusted execution environment with respect to the same instance of the secure guest.

[0061] In one example, the calculated verification code is further calculated based on specific data of the secure guest (636).

[0062] In one example, a proof request is obtained from a secure guest via an uninterceptable call to a trusted execution environment (638). In another example, the proof request contains specific data from the secure guest (640). This specific data from the secure guest is used, along with a proof key, to determine one or more integrity measures (642).

[0063] Furthermore, in one example, the entity is a secure guest, and providing further includes providing the secure guest's runtime data to the secure guest (644). In one example, the secure guest's runtime data, one or more integrity metrics, and specific data of the secure guest are further provided to the requesting entity for use in verifying the secure guest (646).

[0064] As an example, referring to Figure 6C, the specific data of the secure guest includes session information of the session used by the requesting entity to connect to the secure guest and submit a proof request structure to the secure guest that is used in the proof request (650).

[0065] In one example, a proof request is obtained from a secure guest via an uninterceptable call by a trusted execution environment (652). The uninterceptable call includes, for example, a proof request structure containing a proof key and specific data of the secure guest (654).

[0066] Other variations and embodiments are possible.

[0067] Aspects of the present invention may be used in many types of computing environments. Another embodiment of a computing environment for using one or more aspects of the present invention is described with reference to Figure 7A. In this example, the computing environment 36 includes, for example, one or more native central processing units (CPUs) 37, memory 38, and one or more input / output devices or interfaces 39, coupled to each other via one or more buses 40 or other connections or both. For example, the computing environment 36 may include a PowerPC(R) processor provided by International Business Machines Corporation (Armonk, New York), an HP Superdome with an Intel(R) Itanium(R) II processor provided by Hewlett-Packard Corporation (Palo Alto, California), or other machines or combinations based on architectures provided by International Business Machines Corporation, Hewlett-Packard Corporation, Intel Corporation, Oracle Corporation, or other companies, or a combination thereof. PowerPC is a trademark or registered trademark of International Business Machines Corporation in at least one jurisdiction. Intel and Itanium are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.

[0068] The native central processing unit 37 includes one or more native registers 41, such as one or more general-purpose registers or one or more dedicated registers or both, used during processing within the environment. These registers contain information representing the state of the environment at any particular point in time.

[0069] Furthermore, the native central processing unit 37 executes instructions and code stored in memory 38. In one particular example, the central processing unit executes emulator code 42 stored in memory 38. This code allows a computing environment configured on one architecture to emulate another architecture. For example, the emulator code 42 allows machines based on architectures other than the z / Architecture instruction set architecture (such as PowerPC processors and HP Superdome servers) to emulate the z / Architecture instruction set architecture and execute software and instructions developed based on the z / Architecture instruction set architecture.

[0070] Further details relating to the emulator code 42 are described with reference to Figure 7B. The guest instructions 43 stored in memory 38 include software instructions developed to run on architectures other than the native CPU 37 architecture (e.g., those that interact with machine instructions). For example, the guest instructions 43 may be designed to run on a processor based on the z / Architecture instruction set architecture, but instead are emulated on the native CPU 37, which may be, for example, an Intel Itanium II processor. In one example, the emulator code 42 includes an instruction fetch routine 44 for retrieving one or more guest instructions 43 from memory 38 and for optionally providing local buffering of the retrieved instructions. The emulator code 42 also includes an instruction translation routine 45 for determining the type of guest instruction retrieved and for translating the guest instruction into one or more corresponding native instructions 46. This translation includes, for example, identifying the function performed by the guest instruction and selecting a native instruction to perform that function.

[0071] Furthermore, the emulator code 42 includes an emulation control routine 47 for triggering the execution of a native instruction. The emulation control routine 47 may cause the native CPU 37 to execute a native instruction routine that emulates one or more already obtained guest instructions, and upon completion of such execution, return control to the instruction fetch routine to emulate the acquisition of the next guest instruction or group of guest instructions. The execution of the native instruction 46 may include reading data from memory 38 into a register, storing data back into memory from the register, or performing some kind of arithmetic or logical operation as determined by the translation routine.

[0072] For example, each routine is implemented in software stored in memory and executed by the native central processing unit 37. In other examples, one or more routines or operations are implemented in firmware, hardware, software, or any combination thereof. Registers of the emulated processor may be emulated by using the registers 41 of the native CPU or by using locations in memory 38. In embodiments, the guest instruction 43, the native instruction 46, and the emulator code 42 may reside in the same memory or be distributed across different memory devices.

[0073] Instructions, commands, or calls that can be emulated include calls to trusted execution environments described herein, in accordance with one or more aspects of the present invention. Furthermore, other instructions, commands, functions, operations, calls, or one or more aspects of the present invention, or combinations thereof, may be emulated in accordance with one or more aspects of the present invention.

[0074] The computing environments described herein are merely examples of available computing environments. Other environments may be used, including, but not limited to, undivided environments, divided environments, cloud environments, or emulated environments, or combinations thereof, and embodiments are not limited to any one of these environments. Various examples of computing environments are described herein, but one or more embodiments of the present invention may be used with many types of environments. The computing environments provided herein are merely examples.

[0075] Each computing environment can be configured to include one or more embodiments of the present invention.

[0076] One or more embodiments may relate to cloud computing.

[0077] While this disclosure includes a detailed description of cloud computing, it should be understood that implementations of the contents enumerated herein are not limited to cloud computing environments. Embodiments of the present invention may be implemented in combination with any other type of computing environment that is currently known or may be developed in the future.

[0078] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services), allowing these resources to be provisioned and released quickly with minimal administrative effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0079] The features are as follows:

[0080] On-demand self-service: Cloud users can unilaterally and automatically provision computing power, such as server time and network storage, as needed, without requiring human interaction with service providers.

[0081] Broad network access: The capability is available over the network and accessible through standard mechanisms, facilitating use by heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0082] Resource Pooling: A provider's computing resources are pooled and delivered to multiple users using a multi-tenant model, with various physical and virtual resources dynamically allocated and reallocated as needed. There is a sense of location independence, and users typically have neither control nor know the exact location of the resources provided, although at a higher level of abstraction, they may be able to specify a location (e.g., country, state, or data center).

[0083] Rapid Adaptability: Capabilities can be provisioned quickly and flexibly, sometimes automatically, scale out rapidly, and be released quickly to scale in rapidly. The capacity available for provisioning often appears to the user as if they can purchase any amount at any time without limit.

[0084] Measured Services: Cloud systems leverage metering capabilities to automatically control and optimize resource usage at an appropriate level of abstraction for each type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and users.

[0085] The service model is as follows:

[0086] Software as a Service (SaaS): The ability provided to the user is the use of a provider's applications running on a cloud infrastructure. These applications can be accessed from various client devices via thin-client interfaces such as web browsers (e.g., web-based email). Users do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or individual application functions, except for the possibility of making limited user-specific application configuration settings.

[0087] Platform as a Service (PaaS): The ability provided to the user is to deploy applications created or acquired by the user, written using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage, but can control the configuration of the deployed application and, in some cases, the application hosting environment.

[0088] Infrastructure as a Service (IaaS): The capability provided to users is the provisioning of processing, storage, networking, and other basic computing resources, allowing users to deploy and run any software, including operating systems and applications. Users do not manage or control the underlying cloud infrastructure, but they can control the operating system, storage, and deployed applications, and in some cases, have limited control over selected network components (e.g., host firewalls).

[0089] The deployment model is as follows:

[0090] Private Cloud: This cloud infrastructure is operated solely for the organization. It can be managed by this organization or a third party and can reside on-premises or off-premises.

[0091] Community Cloud: This cloud infrastructure is shared by multiple organizations and supports specific communities that share common interests (e.g., missions, security requirements, policies, and compliance considerations). It can be managed by these organizations or third parties and can reside on-premises or off-premises.

[0092] Public Cloud: This cloud infrastructure is available for use by general users or large industry groups and is owned by the organization that sells the cloud service.

[0093] Hybrid Cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that are joined together while retaining their own distinct entities, through standardized or proprietary technologies that enable the portability of data and applications (e.g., cloud bursting to adjust load balancing between clouds).

[0094] Cloud computing environments are service-oriented environments that emphasize statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure, which includes a network of interconnected nodes.

[0095] Referring now to Figure 8, an exemplary cloud computing environment 50 is shown. As illustrated, the cloud computing environment 50 includes one or more cloud computing nodes 52 on which local computing devices used by cloud users (e.g., a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automotive computer system 54N, or a combination thereof) can communicate. The nodes 52 may communicate with each other. The nodes 52 may be physically or virtually grouped within one or more networks into a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described herein (not illustrated). This allows the cloud computing environment 50 to provide infrastructure, platforms, or software, or a combination thereof, as a service, without requiring cloud users to maintain resources on their local computing devices. The types of computing devices 54A-N shown in Figure 8 are intended for illustrative purposes only, and it is understood that the computing node 52 and the cloud computing environment 50 can communicate with any type of computer-controlled device via any type of network or network-addressable connection (e.g., a connection using a web browser) or both.

[0096] Referring now to Figure 9, a set of functional abstraction layers provided by the cloud computing environment 50 (Figure 8) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 9 are intended for illustrative purposes only, and embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided:

[0097] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include a mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based servers 62, 63, blade servers 64, storage devices 65, and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0098] The virtualization layer 70 includes an abstraction layer that can provide virtual entities such as virtual servers 71, virtual storage 72, virtual networks 73 including virtual private networks, virtual applications and operating systems 74, and virtual clients 75.

[0099] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 dynamically procures computing and other resources used to perform tasks within the cloud computing environment. Measurement and pricing 82 tracks the costs of using resources within the cloud computing environment and sends invoices or bills for the use of those resources. In one example, those resources may include application software licenses. Security verifies the identities of cloud users and tasks and protects data and other resources. The user portal 83 provides users and system administrators with access to the cloud computing environment. Service level management 84 allocates and manages cloud computing resources to meet required service levels. Service Level Agreement (SLA) planning and execution 85 prepares and procures cloud computing resources in advance of anticipated future demands in accordance with the SLA.

[0100] Workload Layer 90 provides examples of capabilities available in a cloud computing environment. Examples of workloads and capabilities that may be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom education delivery 93, data analysis processing 94, transaction processing 95, and secure guest authentication processing 96.

[0101] Aspects of the present invention may be systems, methods, or computer program products, or combinations thereof, at any possible level of technical detail of integration. A computer program product may include one or more computer-readable storage media containing computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0102] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exclusive list of further specific examples of computer-readable storage media includes portable floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) or flash memory, static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooved structures on which instructions are recorded, and any appropriate combination thereof. When used herein, computer-readable storage media should not be interpreted as transient signals in themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmitting media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0103] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing device / processing device, or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). This network may include copper transmission cables, optical transmission fibers, wireless transmitters, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing device / processing device receives computer-readable program instructions from the network and transfers those computer-readable program instructions for storage on a computer-readable storage medium within each computing device / processing device.

[0104] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk(R) and C++, and procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be executed as a whole on the user's computer, partially as a standalone software package on the user's computer, partially on the user's computer and a remote computer, respectively, or as a whole on a remote computer or a server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, to carry out aspects of the present invention, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may be customized by executing computer-readable program instructions using state information of computer-readable program instructions.

[0105] Aspects of the present invention will be described herein by reference to flowcharts or block diagrams, or both, of methods, apparatuses (systems), and computer program products, according to embodiments of the present invention. It will be understood that each block in a flowchart or block diagram, or both, and any combination of blocks contained in a flowchart or block diagram, or both, can be implemented by computer-readable program instructions.

[0106] These computer-readable program instructions may be provided to a computer or other programmable data processing device processor to create a machine, so that instructions executed via the processor of the computer or other programmable data processing device may create means to perform functions / operations specified in one or more blocks of a flowchart or block diagram or both. These computer-readable program instructions may be stored on a computer-readable storage medium containing instructions that include a product containing instructions to perform modes of functions / operations specified in one or more blocks of a flowchart or block diagram or both, and may be used to instruct a computer, a programmable data processing device, or other device, or a combination thereof, to function in a particular manner.

[0107] Computer-readable program instructions may be read into a computer, another programmable data processing device, or other device so that instructions executed on a computer, another programmable device, or other device perform functions / operations specified in one or more blocks of a flowchart or block diagram, or both, thereby causing a series of operable steps to be executed on a computer, another programmable device, or other device that generates a computer implementation process.

[0108] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a defined logical function. In some alternative implementations, the functions shown in the blocks may occur in an order different from the order shown in the figures. For example, two consecutively shown blocks may actually be implemented as a single step, executed simultaneously, executed substantially simultaneously in a way that partially or completely overlaps in time, or possibly executed in reverse order, depending on the functions they contain. Note also that each block in the block diagram or flowchart diagram, or both, and any combination of blocks contained in the block diagram or flowchart diagram, or both, may be implemented by a dedicated hardware-based system that performs a defined function or operation, or a combination of dedicated hardware and computer instructions.

[0109] In addition to the above, one or more aspects may be provided, presented, deployed, managed, or serviced by a service provider that provides management of the customer's environment. For example, a service provider may create, maintain, and support computer code or computer infrastructure, or both, that runs one or more aspects for one or more customers. In return, the service provider may receive payment from the customer, for example, in accordance with a subscription or fee agreement, or both. As an additional or alternative, the service provider may receive payment from the sale of advertising content to one or more third parties.

[0110] In one aspect, an application may be deployed to perform one or more embodiments. As one example, the deployment of an application may include providing a computer infrastructure that functions to perform one or more embodiments.

[0111] In a further embodiment, a computing infrastructure may be deployed that includes integrating computer-readable code into a computing system, such that the code combined with the computing system can execute one or more embodiments.

[0112] In a further embodiment, a process for integrating a computing infrastructure may be provided, which includes integrating computer-readable code into a computer system. The computer system comprises a computer-readable medium, the computer medium including one or more embodiments. The code combined with the computer system can perform one or more embodiments.

[0113] Although various embodiments have been described above, these are merely examples. For example, computing environments of other architectures may be used to incorporate one or more embodiments, to use one or more embodiments, or both. Furthermore, various instructions, commands, functions, calls, or actions, or combinations thereof, may be used. Furthermore, various types of structures may be used. Many variations are possible.

[0114] Various embodiments are described herein. Furthermore, many modifications are possible without departing from the spirit of the embodiments of the present invention. It should be noted that each embodiment or feature and its variations described herein can be combined with any other embodiment or feature, in particular, as long as they do not contradict each other.

[0115] Furthermore, other types of computing environments can benefit and be used. For example, a data processing system could be used that includes at least two processors, directly or indirectly coupled to memory elements via a system bus, suitable for storing, executing, or both program code. These memory elements include, for example, local memory used during the actual execution of program code, bulk storage, and cache memory for temporarily storing at least some program code to reduce the number of times the code must be retrieved from bulk storage during execution.

[0116] Input / output devices or I / O devices (including, but not limited to, keyboards, displays, pointing devices, DASDs, tapes, CDs, DVDs, thumb drives, and other storage media) may be coupled to the system directly or through an intermediary I / O controller. Network adapters may be coupled to the system, enabling data processing systems to be coupled to other data processing systems or remote printers or storage devices through an intermediary private or public network. Modems, cable modems, and Ethernet(R) cards are just a few of the types of network adapters that can be used.

[0117] The terms used herein are intended solely to describe specific embodiments and are not intended to be limiting. Where used herein, the singular forms “a,” “an,” and “the” are intended to include the plural form unless otherwise explicitly indicated in the context. It will be further understood that the terms “equipped with” or “possessing” or both, as used herein, indicate the presence of a described function, integer, step, operation, element, or component, or a combination thereof, but do not exclude the presence or addition of one or more other functions, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0118] All means or steps and functional elements within the following claims, along with their corresponding structures, materials, actions, and equivalents, are intended to include, if any, any structures, materials, or actions for performing a function in combination with other claimed elements, when specifically claimed. Descriptions of one or more embodiments are presented for illustrative and explanatory purposes, but are not intended to be exhaustive and are not limited to the disclosed forms. Many modifications and variations will be apparent to those skilled in the art. Embodiments have been selected and described to best illustrate various aspects and practical applications, and to enable others skilled in the art to understand the diverse embodiments with various modifications suitable for a particular intended use.

Claims

1. A computer program for facilitating processing within a computing environment, wherein the processor Obtaining a proof request by a trusted execution environment, wherein the proof request includes at least a proof key, Based on obtaining the aforementioned proof request, the calculation of one or more integrity measurement results, using at least the proof key, A computer program for performing a method including providing one or more integrity measurement results to an entity, the one or more integrity measurement results being used to verify that a secure guest was started using a selected secure guest image and selected secure guest metadata.

2. The computer program according to claim 1, wherein the proof request includes an integrity-protected proof request structure, and the proof key is maintained within an encrypted portion of the proof request structure.

3. The proof request structure is exclusively interpretable by the trusted execution environment, and the method is To verify the integrity protection of the aforementioned proof request structure, The computer program according to claim 2, further comprising, by the trusted execution environment, decrypting the encrypted portion of the proof request structure and obtaining the proof key used in calculating one or more integrity measurement results, based on the success of the verification of the integrity protection of the proof request structure.

4. The computer program according to claim 1, wherein providing one or more integrity measurement results further includes providing selected information of the trusted execution environment used to verify the secure guest, the selected information including runtime data of the secure guest.

5. The computer program according to claim 1, wherein the one or more integrity measurement results include a calculated verification code calculated based on at least the image of the secure guest and one or more secure guest metadata.

6. The computer program according to claim 5, wherein the calculated verification code is further calculated based on the runtime data of the secure guest.

7. The computer program according to claim 6, wherein the runtime data of the secure guest includes unique identification information of the running instance of the secure guest that issued the proof request.

8. The computer program according to claim 6, wherein the calculated verification code is further calculated based on specific data of the secure guest.

9. The computer program according to claim 1, wherein the proof request is obtained from the secure guest via an uninterceptable call to the trusted execution environment, the proof request further comprises specific data of the secure guest, the specific data of the secure guest is used together with the proof key to compute the one or more integrity measurement results, the entity is the secure guest, and the provision further comprises providing the secure guest's runtime data, the secure guest's runtime data, the one or more integrity measurement results, and the specific data of the secure guest are further provided to the requesting entity for use in verifying the secure guest.

10. The computer program according to claim 9, wherein the specific data of the secure guest includes session information of a session used by the requesting entity to connect to the secure guest and submit to the secure guest a proof request structure used in the proof request.

11. The computer program according to claim 1, wherein the proof request is obtained by the trusted execution environment from the secure guest via an uninterceptable call, and the uninterceptable call includes a proof request structure containing the proof key and specific data of the secure guest.

12. A computer system for facilitating processing within a computing environment, wherein the computer system is Memory and The computer system is configured to perform the method, comprising at least one processor that communicates with the memory, and the method is Obtaining a proof request by a trusted execution environment, wherein the proof request includes at least a proof key, Based on obtaining the aforementioned proof request, the calculation of one or more integrity measurement results, using at least the proof key, A computer system comprising providing one or more integrity measurement results to an entity, the one or more integrity measurement results being used to verify that a secure guest was started using a selected secure guest image and selected secure guest metadata.

13. A computer implementation method for facilitating processing within a computing environment, wherein the computer implementation method is Obtaining a proof request by a trusted execution environment, wherein the proof request includes at least a proof key, Based on obtaining the aforementioned proof request, the calculation of one or more integrity measurement results, using at least the proof key, A computer implementation method comprising providing one or more integrity measurement results to an entity, wherein the one or more integrity measurement results are used to verify that a secure guest was started using a selected secure guest image and selected secure guest metadata.

Images