Secure services hosted in a virtual secure environment

Abstract

This application relates to computing systems and methods performed by computing systems. A virtual machine image provides a service identified by a role. An execution environment generates a measurement of the virtual machine image and provides it to a key service to request a role key that enables operations of the virtual machine image in the execution environment. The key service determines whether the virtual machine image is mapped to the role, and if so, returns the role key to the requesting execution environment.

Description

[0001] This application is a divisional application of the invention patent application filed on October 16, 2017, with application number 201780064096.X and invention title "Security Services Hosted in a Virtual Security Environment". Technical Field

[0002] Embodiments of this disclosure relate to the field of computers, and more specifically, to computing systems and methods for hosting security services in a virtual security environment. Background Technology

[0003] Computer systems are now widely used. Some of these computer systems are deployed in remote server environments (such as in the cloud) where they are hosted.

[0004] The hosted services can be those where security is critical. For example, some hosted services may be payment services, credit card processing services, banking services, or various other services that handle confidential information.

[0005] These types of systems have infrastructure that is typically hosted on discrete systems. For example, each service hosted may be hosted on a separate or discrete physical machine. These machines may be deployed in a physical cage environment to provide physical security. Furthermore, developers or other programmers writing code for these types of systems can often use relatively isolated networks to access secure or caged physical facilities to further enhance the security associated with the development code deployed on such services.

[0006] This can lead to many drawbacks for services, for example. Scalability can be very difficult because each service is typically deployed on a dedicated physical machine (or server) and doesn't involve virtualization. To scale such a service, additional physical machines must be added for other services or service instances. Furthermore, this can lead to rigidity, as developers or programmers need to generate code in a physically secure and tightly controlled environment, making changes very difficult.

[0007] The above discussion is provided for general background information only and is not intended to help determine the scope of the subject matter for which protection is sought. Summary of the Invention

[0008] The execution environment has deployed virtual machine images. The virtual machine images provide services identified by roles. The execution environment generates measurements of the virtual machine images and provides them to a key service to request a role key to enable operations on the virtual machine images in the execution environment. The key service determines whether the virtual machine images are mapped to roles, and if so, returns the role key to the requesting execution environment.

[0009] This "Summary" is provided to introduce some concepts in a simplified form, which will be further described in the "Detailed Description" below. This "Summary" is not intended to identify key or essential features of the claimed subject matter, nor is it intended to help determine the scope of the claimed subject matter. The claimed subject matter is not limited to the implementation of solutions to any or all the shortcomings mentioned in the background art. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating an example of a development channel used to develop services and generate virtual machine images corresponding to those services.

[0011] Figure 2 This is a block diagram of an example of a cloud cage architecture.

[0012] Figure 3 This is a flowchart illustrating an example of the operation of deploying a service.

[0013] Figure 4 This is a flowchart illustrating an example of the operation of the execution environment.

[0014] Figure 5 This is a flowchart illustrating an example of the key service operation when the requested role key is provided to the execution environment.

[0015] Figure 6 It shows that it can be shown Figure 1 A block diagram of an example computing environment used in the architecture shown. Detailed Implementation

[0016] Figure 1 This is a flowchart illustrating an example of the operation of the development channel 100. The development channel 100 illustratively includes a developer 102, a build system 104, a signing system 106, a virtual machine image generator 108, and an image measurement system 110. Figure 1 It is also shown that the development channel 100 can be coupled to the cloud architecture 122, which includes a cloud cage 123 (which itself includes trusted execution environments 124 and 126), a cloud cage deployment service 128, and a cloud cage key service 130, and the cloud architecture 122 can include other projects 129. Figure 1 It is also shown that one or more security service user systems 131 can access architecture 122 via network 132.

[0017] exist Figure 1In the example shown, developer 102 illustratively develops source code 112, which is code to be run in a hosted secure service, such as a trusted execution environment 124-126. Such a service could be a payment service, a banking service, a credit card processing service, or any of a variety of other services.

[0018] The build system 104 receives source code 112 and builds it into executable binary code (or other build code) 114. Code 114 is descriptively compiled executable code, which may include scripts and various data files. It is descriptively provided to the signing system 106. The signing system 106 descriptively signs the code 114 to generate signed executable code 116. Because the code 116 is signed, this ensures that it is not modified after the signing occurs. The signature may also indicate the identity of the code signer (or the signing system 106).

[0019] The virtual machine image generator 108 then generates a virtual machine image by combining an appropriate operating system image and signed executable code 116. The resulting virtual machine (VM) image 118 may include one or more services and a database that can be deployed to implement these services in an execution environment. In one example, the virtual machine image generator 108 may use a virtual hard disk drive format as the hard disk for the virtual machine. This allows multiple operating systems to reside on a single machine.

[0020] Then, the image measurement system 110 generates one or more virtual machine image measurements 120 based on the virtual machine image 118. Measurement 120 illustratively includes a recomputable strong identity representing each image 118. In one example, each measurement 120 may be a cryptographic hash value computed on the corresponding VM image 118. The VM image 118 and its corresponding measurements 120 can then be provided to a cloud environment (or cloud architecture) 122, in which the VM image 118 and its corresponding measurements 120 can be executed by virtual machines in one or more trusted execution environments 124-126.

[0021] VM image 118 and role-to-VM image mappings can be provided to Cloud Cage Deployment Service 128. Role-to-VM image mapping maps VM image 118 to a specific role corresponding to the service it will execute. VM measurement 120 and measurement-to-role mappings can be provided to Cloud Cage Key Service 130. Measurement-to-role mapping also maps specific measurements of VM image 118 to roles. Additionally, specific trusted execution environments 124-126 used to execute one of VM images 118 can send a trusted execution environment identifier to Cloud Cage Key Service 130. This trusted execution environment identifier identifies the specific trusted execution environment that will deploy the VM image 118 represented by VM image measurement 120.

[0022] In short, during operation, the Cloud Cage Deployment Service 128 can deploy a specific VM image to trusted execution environments 124-126. Environments 124-126 can then request a role key from the Cloud Cage Key Service 130. The Cloud Cage Key Service 130 identifies whether a specific VM image is suitable for a specific role and the requesting execution environment, and if so, returns an encrypted role key to the requesting execution environment so that it can operate to execute its services.

[0023] Figure 1 It is also shown that once a service (such as a payment service or other security service) is deployed to Trusted Execution Environments 124-126, the payment (or other security service) user system 131 can access the service within one of the Trusted Execution Environments via network 132 and cloud 121. As an example, if the security service is a credit card processing service, then user system 131 could be a system at a credit card company that requires credit card processing. If it is a banking service, then system 131 could be deployed at a bank. These are merely examples.

[0024] Network 132 can be any type of network, such as a wide area network (WAN), a local area network (LAN), or any other wired or wireless network or combination of networks. Some examples are listed below.

[0025] Figure 2 This is a block diagram showing a more detailed example of a cloud cage architecture 122 deployed in cloud 121. Figure 2 Some of the items shown are related to Figure 1 The items shown are similar, and their numbers are similar.

[0026] In description Figure 2 Before the overall operation of the architecture 122 shown, first provide Figure 2 A brief description of some items and their operation. In Figure 2 In the example shown, the cloud cage 123 may include one or more processors or servers 136, trusted execution environments 124-126, and may also include other items. Trusted execution environment 124 may include a hypervisor 138 and one or more virtual machines 140, as well as a decryption system 141 and a measurement system 142. It may also include other items 144. Trusted execution environment 126 may also include a hypervisor 146, or hypervisors 138 and 146 may be implemented as a single hypervisor for generating virtual machines 140-148. Execution environment 126 may also include a description system 149 and a measurement system 150, as well as various other items 152. Trusted execution environments 124-126 may be similar or different. For the purposes of this description, they will be assumed to be similar, and therefore only the operation of trusted execution environment 124 will be provided herein.

[0027] Virtual machine 140 illustratively receives and executes a virtual machine image from cloud cage deployment service 128 (described in more detail below). Measurement system 142 can measure the image deployed on virtual machine 140. Measurements can be generated by applying a cryptographic hash function to the image. For example, in the case where the image is represented by a virtual hard disk image, measurements can be generated by applying a SHA-256 hash to the image. This is just one example, and various other methods can be used to generate measurements for virtual machine images. When executing a service represented by a VM image, trusted execution environment 124 can expose an application programming interface (API) 151 that user system 131 can interact with to use the service.

[0028] To deploy a virtual machine image to a Trusted Execution Environment 124, a cloud-based deployment service 128 can be used. In one example, service 128 may include one or more processors or servers 154, a deployment engine 156, a virtual machine image repository 158, a role-to-virtual machine image mapping 160, and may include other items 162. The Trusted Execution Environment 124 descriptively provides a role (which represents the service it intends to execute) to the deployment engine 156. The deployment engine 156 then accesses the role-to-VM image mapping 160 to identify the specific VM image corresponding to that role and retrieves the image from the VM image repository 158. It then deploys the VM image on virtual machine 140 in a request to the Trusted Execution Environment 124. This will be referenced below. Figure 3 To describe in more detail.

[0029] Once the VM image is deployed on virtual machine 140, the Trusted Execution Environment 124 still illustratively requires the role keys it will use to execute the specific services (or roles) that have been deployed. That is, the deployed VM image may include code representing one or more services and databases, but it does not yet have the keys required to perform its operations. Therefore, the Trusted Execution Environment 124 generates measurements of the VM image deployed on virtual machine 140 and provides them, along with the roles (corresponding to services), to the Cloud Cage Key Service 130 to obtain the role keys it needs to operate.

[0030] The cloud-based key service 130 may include one or more processors or servers 164, a Virtual Trusted Execution Environment (VTEE) key service 166, a policy engine 168, a key-wrapping cryptographic engine 170, a VM image measurement store 172, a measurement-to-role mapping 174, a role key store / generator 176, a key wrapper key 178, and may also include various other items 180. The VTEE key service 166 provides a request (VM image measurement and corresponding role, and the identity of the requesting trusted execution environment 124) to the policy engine 168. The policy engine 168 accesses the VM image measurement 172 to verify that the requested trusted execution environment is the appropriate environment for executing the specific role represented by the VM image. The engine 168 also accesses the measurement-to-role mapping 174 to identify whether the VM image measurement provided by the trusted execution environment 124 is mapped to the role identified by the trusted execution environment 124 in its request for a key. If the policy engine 168 affirmatively evaluates, this indicates that the trusted execution environment requesting the key is the appropriate environment for executing the identified role. It also instructs that measurements of code (e.g., operating system, code, database, etc.) deployed in the VM image within the Trusted Execution Environment 124 be mapped to roles identified by the Trusted Execution Environment 124. Therefore, this indicates that the Trusted Execution Environment 124 is appropriate and that the code has not been modified and mapped to the identified roles.

[0031] In this scenario, the VTEE key service 166 requests the key-wrapping cryptographic engine to retrieve the role key for the identified role from the role key store / generator 176, and wraps or encrypts these keys with one or more key-wrapping keys 178. The wrapped keys are then provided back to the VTEE key service 166, which returns them to the requested trusted execution environment 124. There, they can be decrypted by the decryption system 141 and used to execute services (or roles) within that environment.

[0032] Figure 3 This is a flowchart illustrating an example of the operation of the Cloud Cage Deployment Service 128 in more detail. The deployment engine 156 first receives a role identifier that identifies the role to be deployed to the Trusted Execution Environment 124. This is... Figure 3 Box 190 indicates this. The role descriptively corresponds to the security service to be hosted by the trusted execution environment 124, such as a payment service, credit card service, etc. This is indicated by box 192. The role identifier can be any string 194 or other representation 196.

[0033] Then, deployment engine 156 accesses role-to-VM image mapping 160 to identify the specific VM image corresponding to the role. Access to role-to-VM image mapping is indicated by box 198, and identifying the VM image to which a role is mapped based on these mappings is indicated by box 200. In one example, the mapping is represented as shown in Equation 1 below, where “IMAGE” is represented in virtual image format and “H” is a cryptographic hash function.

[0034] Equation 1 Role mapping Signature keys can be used for role mapping The signature is signed, and deployment engine 156 can verify the signature with a public key certificate authority installed on the deployment machine (e.g., on VM 140) within the trusted execution environment 124. The role mapping signature verification is indicated by box 202. Again, the VM image can be a signed code combined with an image of the appropriate operating system, as shown in box 204. The VM image can represent one or more services and databases, as shown in box 206, and the VM image can also be identified in other ways, as shown in box 208.

[0035] Then, deployment engine 156 retrieves the identified VM image from VM image repository 158. This is indicated by box 210. It then deploys the identified VM image to cloud-based trusted execution environment 124. This is indicated by box 212.

[0036] Figure 4 This is a flowchart illustrating an example of the operations of a Trusted Execution Environment 124 when it requests role keys from a Cloud Cage Key Service 130, receives these keys, and uses them to perform its work. It is first assumed that the VM image representing the service to be executed in environment 124 has already been deployed in the Trusted Execution Environment 124 by deployment service 128. This is indicated by box 218. Then, the Trusted Execution Environment 124 determines the role keys representing the role of the service it wants to execute that require the operation to be performed. This is determined by… Figure 4 Box 220 in the flowchart indicates this.

[0037] Then, measurement system 142 generates VM image measurements of the deployed VM image deployed on virtual machine 140. This is indicated by box 222. Again, as briefly described above, VM image measurements can be obtained by applying a hash function to the VM image. This is indicated by box 224. It can also be obtained in other ways, as shown in box 226.

[0038] The Trusted Execution Environment 124 then sends the VM image measurement and the role identifier of the identified role to the Cloud Cage Key Service 130 to obtain the role key of the role, enabling the Trusted Execution Environment 124 to perform its operations. This is indicated by box 228.

[0039] Then, the Cloud Cage Key Service 130 operates to verify that the role is suitable for the Request Trusted Execution Environment and that the key is suitable for the role. If so, Service 130 returns the wrapped (or encrypted) role key to the Request Trusted Execution Environment 124 in Cloud Cage 123. See below for reference. Figure 5 A more detailed description of the operation of the Cloud Cage Key Service 130, and the acquisition of the packaged or encrypted role key at the Trusted Execution Environment 124. Figure 4 Box 230 in the flowchart indicates this.

[0040] Then, the decryption system 141 in the trusted execution environment 124 unpacks (or decrypts) the received role keys and uses them to perform work under the role (or service) it is executing. This is done by Figure 3 Boxes 232 and 234 in the flowchart indicate this. The specific tasks to be performed in a trusted execution environment will vary greatly depending on the specific service it hosts or executes. For example, role keys can be used to decrypt credit card information, as shown in box 236. They can be used to perform payment processing, as shown in box 238. They can, of course, be used in a variety of other ways, and this is indicated by box 240.

[0041] Figure 5 This is a flowchart illustrating an example of the operation of the Cloud Cage Key Service 130 in more detail. The VTEE Key Service 166 first receives a quote from the execution environment requesting the role key (such as the Trusted Execution Environment 124). This is... Figure 5 Box 250 in the flowchart indicates this. As briefly discussed above, the reference may include a role identifier 252 that identifies a specific role being executed by the requesting execution environment. It also illustratively includes VM measurements generated by that environment. This is indicated by box 254. It may include a trusted execution environment identifier 256 that identifies the specific trusted execution environment making the request. The request may also include other items 258.

[0042] The request is then provided to policy engine 168, where it is evaluated to determine whether the reference (or request) originates from an appropriate trusted execution environment and whether it has the correct operating system, code, etc., for the identified role. This is handled by... Figure 5 Box 260 in the flowchart indicates this. In one example, policy engine 168 accesses VM image measurement storage 172 to identify whether the requested trusted execution environment corresponds to a VM image measurement received in the request. For example, it can determine whether the VM image has been properly deployed in the appropriate trusted execution environment. This is indicated by box 262.

[0043] Policy engine 168 can also access the role mapping 174 to determine whether a VM image deployed on the requested trusted execution environment (and represented by the VM image measurement) is mapped to an identified role. This is indicated by box 264. Therefore, given a VM image measurement, policy engine 168 generates a set of roles by accessing the mapping 174 that maps VM images to a set of roles, as follows: in Equation 2 From Equation 2 above, it can be seen that the mapping Map the mirror image h (which is equal to H(IMAGE)(H(mirror)) shown in Equation 1 above) to a set of characters S. R The group of characters S R Through mapping And those roles mapped to VM image measurements. This group of roles consists of roles, where each role is given a mapping to an image measurement h.

[0044] If policy engine 168 determines that the requested trusted execution environment is not the appropriate environment for running the VM image identified by the VM image measurement, or if it determines that the VM image measurement is not mapped to the role of the requested trusted execution environment, then VTEE key service 166 determines that policy engine 168 has not yet affirmatively evaluated the reference. This is determined by... Figure 5 Box 270 indicates this. Therefore, the VTEE key service 166 rejects the request for the role key, as shown in box 272. It may send a notification or alarm or other message or perform other actions in response to this negative evaluation. This is indicated by box 274.

[0045] However, assuming that policy engine 168 determines that the requested trusted execution environment 124 is the appropriate environment for the execution role, and assuming that the VM image measurement provided by the requested trusted execution environment maps to the identified role, then VTEE key service 166 determines at box 270 that the policy engine evaluation is positive or favorable. In this case, VTEE key service 166 interacts with the key-wrapping cryptographic engine to obtain the role keys, so that it can provide them to the requested trusted execution environment 124.

[0046] To this end, the VTEE key service 166 provides role identifiers to the key-wrapping cryptographic engine 170. Engine 170 accesses the role key store / generator 176 to obtain or generate a role key for the identified role. This is... Figure 5 Box 276 in the flowchart indicates this. Then, engine 170 accesses key wrapper key 178 and wraps (or encrypts) the set of role keys with one or more key wrapper keys 178. This is... Figure 5Box 278 in the flowchart indicates that role keys can be packaged individually or as a group. The key wrapper key can be a public key, as shown in box 280, and packaging role keys can also be done in other ways, as indicated in box 282.

[0047] The role key can be any cryptographic key type, and the wrapper key is descriptively the public key of that specific role. When retrieving the wrapper key, Engine 170 can access the mapping between a given role and the wrapper public key Pu. r mapping As shown in Equation 3 below: Equation 3 S kr Use the public key Pu for packaging R A set of packaged role keys encrypted with role keys As shown below: Equation 4 Once the key-wrapping cryptographic engine 170 obtains the role keys and wraps them with the appropriate key-wrapper key 178, it returns the wrapped role keys to the VTEE key service 166, which then returns them to the requested trusted execution environment 124. This is achieved through... Figure 5 Box 284 in the flowchart indicates this.

[0048] Therefore, it should be understood that CloudCage treats multiple payment services as roles and maps these roles to VM images as defined above. Some examples of roles or services running in CloudCage's trusted execution environment could be virtual hardware security modules (or cryptographic services), remittance broker services, remittance broker databases, etc.

[0049] In the architecture described above, in one example, each server hardware illustratively includes a high-guarantee cryptographic processor, a relatively small amount of key storage, key pairs, and the ability to measure binary images loaded by trusted hardware in the CloudCage deployment service 128. The high-guarantee cryptographic processor may have a public key with a verifiable certificate. It may also include proof capabilities in the hardware for keys generated by that hardware. This binds key integrity to a specific key certificate. Additionally, as mentioned above, the role-to-VM image mapping can be signed. The confidentiality of the signing key and the integrity of its public key can be verified by a separate system, or these systems can be part of the CloudCage architecture. The role key and wrapping key depend on the mapping discussed above. and Role definition code and data can be signed and verified with a certificate authority, which can be an external authority.

[0050] Therefore, it can be seen that this system can ensure security even without the physical cage security surrounding development and deployment resources. It ensures that the virtual machine image deployed in the Trusted Execution Environment (TEE) has not been altered. It also ensures that, before obtaining role keys, the virtual machine image is the appropriate virtual machine image for obtaining those keys, and the TEE is the appropriate environment for running that virtual machine image. The role key is wrapped or encrypted upon return to the TEE so that it can perform its operations.

[0051] It should be noted that the foregoing discussion has described various different systems, components, and / or logic. It should be understood that such systems, components, and / or logic may include hardware items (such as processors and associated memory, or other processing components, some of which are described below) that perform functions associated with these systems, components, and / or logic. Additionally, systems, components, and / or logic may include software loaded into memory and subsequently executed by a processor or server or other computing component, as described below. Systems, components, and / or logic may also include different combinations of hardware, software, firmware, etc., some examples of which are described below. These are merely some examples of different structures that can be used to form the systems, components, and / or logic described above. Other structures may also be used.

[0052] Processors and servers have been mentioned in this discussion. In one embodiment, processors and servers include computer processors (not shown separately) with associated memory and timing circuitry. They are functional parts of the system or device to which they belong and which activates them, and support the functionality of other components or items in these systems.

[0053] Furthermore, many user interface displays have been discussed. They can take various forms and have a wide variety of user-actuable input mechanisms. For example, user-actuable input mechanisms can be text boxes, checkboxes, icons, links, drop-down menus, search boxes, etc. They can also be actuated in various ways. For example, they can be actuated using click devices (such as trackballs or mice). They can be actuated using hardware buttons, switches, joysticks or keyboards, thumb switches or thumb pads, etc. They can also be actuated using virtual keyboards or other virtual actuators. Additionally, if the screen displaying them is a touch-sensitive screen, they can be actuated using touch gestures. Moreover, if the device displaying them has a voice recognition component, they can be actuated using voice commands.

[0054] Many data storage devices are also discussed. It should be noted that each of them can be divided into multiple data storage devices. All of these can be local to the system accessing them, all of these can be remote, or some can be local while others are remote. All of these configurations are considered in this paper.

[0055] Furthermore, the accompanying diagram illustrates multiple boxes, each with its own functionality. It should be noted that fewer boxes can be used, thus allowing functionality to be performed by fewer components. Alternatively, more boxes can be used, with functionality distributed among more components.

[0056] Architecture 122 is described herein as a cloud computing architecture. Cloud computing provides computing, software, data access, and storage services without requiring end users to know the physical location or configuration of the system providing the service. In various embodiments, cloud computing provides services over a wide area network (WAN) such as the Internet using appropriate protocols. For example, cloud computing providers offer applications over a WAN and can access them through a web browser or any other computing component. The software or components of architecture 122, along with the corresponding data, can be stored on servers at a remote location. Computing resources in a cloud computing environment can be consolidated at a remote data center location or can be distributed. Cloud computing infrastructure can provide services through a shared data center, even if they present a single point of access for the user. Therefore, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from traditional servers, or they can be installed directly or otherwise on client devices.

[0057] This description aims to encompass both public and private cloud computing. Cloud computing (both public and private) provides a large, seamless pool of resources and reduces the need for managing and configuring the underlying hardware infrastructure.

[0058] Public clouds are managed by a vendor and typically use the same infrastructure to support multiple consumers. Furthermore, unlike private clouds, public clouds do not require end-users to manage the hardware. Private clouds can be managed by the organization itself, and the infrastructure is usually not shared with other organizations. The organization still maintains the hardware to some extent, such as installation and maintenance.

[0059] Figure 6 This is an example of a computing environment where architecture 100 or a portion thereof can be deployed, for example. (See reference) Figure 6Example systems for implementing some embodiments include general-purpose computing devices in the form of a computer 810. Components of computer 810 may include, but are not limited to, a processing unit 820 (which may include a processor or server 136, 154, or 164), system memory 830, and a system bus 821 that couples various system components, including system memory, to the processing unit 820. System bus 821 may be any of several types of bus architectures, including memory buses or memory controllers using any of various bus architectures, peripheral buses, and local buses. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses (also known as mezzanine buses). Regarding... Figure 1 The described memory and program can be deployed in Figure 6 In the corresponding part.

[0060] Computer 810 typically includes a variety of computer-readable media. Computer-readable media can be any available medium accessible to computer 810, and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, computer-readable media can include computer storage media and communication media. Computer storage media are distinct from and do not include modulated data signals or carrier waves. It includes hardware storage media, which includes volatile and non-volatile removable and non-removable media implemented using any method or technology for storing information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, Digital Universal Disc (DVD) or other optical disc storage devices, magnetic tape cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to computer 810. Communication media typically contain computer-readable instructions, data structures, program modules, or other data in a transmission mechanism and include any information transmission medium. The term "modulated data signal" refers to a signal whose one or more characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0061] System memory 830 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 831 and random access memory (RAM) 832. A basic input / output system 833 (BIOS) containing basic routines that facilitate the transfer of information between components within computer 810 (e.g., during startup) is typically stored in ROM 831. RAM 832 typically contains data and / or program modules that are immediately accessible and / or currently being operated by processing unit 820. This is by way of example and not limitation. Figure 6 The operating system 834, application program 835, other program modules 836, and program data 837 are shown.

[0062] Computer 810 may also include other removable / non-removable volatile / non-volatile computer storage media. This is just one example. Figure 6 A hard disk drive 841 is shown that reads from or writes to a non-removable, non-volatile magnetic medium, and an optical disk drive 855 that reads from or writes to a removable, non-volatile optical disk 856, such as a CD-ROM or other optical media. Other removable / non-removable volatile / non-volatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, magnetic tape cartridges, flash memory cards, digital universal disks, digital videotapes, solid-state RAM, solid-state ROM, etc. The hard disk drive 841 is typically connected to the system bus 821 via a non-removable memory interface such as interface 840, and the optical disk drive 855 is typically connected to the system bus 821 via a removable memory interface such as interface 850.

[0063] Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. For example, and not limitingly, illustrative types of hardware logic components that may be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc.

[0064] The above discussion and Figure 6 The drive and its associated computer storage medium shown provide storage for computer-readable instructions, data structures, program modules, and other data for computer 810. For example, in Figure 6 In this diagram, hard disk drive 841 is shown storing operating system 844, application programs 845, other program modules 846, and program data 847. Note that these components may be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to indicate that they are at least different copies.

[0065] Users can input commands and information into computer 810 through input devices such as keyboard 862, microphone 863, and pointing devices 861 such as mouse, trackball, or touchpad. Other input devices (not shown) may include joysticks, game controllers, satellite dish antennas, scanners, etc. These and other input devices are typically connected to processing unit 820 via user input interface 860 coupled to the system bus, but may be connected via other interfaces and bus structures such as parallel ports, game ports, or Universal Serial Bus (USB). Visual display 891 or other types of display devices are also connected to system bus 821 via interfaces such as video interface 890. In addition to the display, the computer may also include other peripheral output devices, such as speakers 897 and printers 896, which can be connected via output peripheral interface 895.

[0066] Computer 810 operates in a network environment using logical connections to one or more remote computers, such as remote computer 880. Remote computer 880 can be a personal computer, handheld device, server, router, network PC, peer-to-peer device, or other public network node, and typically includes many or all of the elements described above with respect to computer 810. Figure 6 The logical connections described include Local Area Networks (LANs) 871 and Wide Area Networks (WANs) 873, but may also include other networks. This network environment is common in offices, enterprise-wide computer networks, intranets, and the Internet.

[0067] When used in a LAN network environment, computer 810 connects to LAN 871 via a network interface or adapter 870. When used in a WAN network environment, computer 810 typically includes a modem 872 or other means for establishing communication over a WAN 873, such as the Internet. The modem 872, which may be internal or external, can be connected to system bus 821 via user input interface 860 or other suitable mechanism. In a network environment, program modules described with respect to computer 810 or parts thereof may be stored in a remote memory storage device. This is by way of example and not limitation. Figure 6 The remote application 885 is shown residing on the remote computer 880. It is understood that the network connection shown is exemplary, and other means of establishing a communication link between computers can be used.

[0068] It should also be noted that the different embodiments described herein can be combined in different ways. That is, portions of one or more embodiments can be combined with portions of one or more other embodiments. All of these are considered herein.

[0069] Example 1 is a computing system that includes: The policy engine receives role and virtual machine (VM) image measurements, role identification service, VM image measurements indicating virtual machine images deployed in the execution environment, and the policy engine determines whether VM image measurements are mapped to roles and generates an evaluation signal indicating the determination. A key-wrapping cryptographic engine, based on an evaluation signal indicating that a VM image measurement is mapped to a role, acquires and wraps a set of role keys, each corresponding to a role and enabling the execution environment to perform services; and Key service provides a set of wrapped role keys for the execution environment.

[0070] Example 2 is a computing system according to any or all of the previous examples, wherein the policy engine is configured to receive a receiving role, receive VM image measurements, and receive an execution environment identifier from the requesting execution environment, the execution environment identifier identifying the requesting execution environment.

[0071] Example 3 is a computing system based on any or all of the previous examples, wherein the policy engine is configured to determine whether the requesting execution environment is mapped to a VM image measurement based on the execution environment identifier, and to generate an evaluation signal based on the determination.

[0072] Example 4 is a computing system based on any or all of the previous examples, and also includes: A set of measurement-to-role mappings maps each role in multiple different groups of roles to a different VM image measurement. The policy engine determines whether a VM image measurement is mapped to a role by accessing the measurement-to-role mappings.

[0073] Example 5 is a computing system based on any or all of the previous examples, and also includes: A role key store / generator is configured to provide a set of role keys to the key wrapper cryptographic engine; and a set of key wrapper keys, each key wrapper key being mapped to a given role. The key wrapper cryptographic engine identifies one or more key wrapper keys mapped to a role and encrypts the role keys with the identified one or more key wrapper keys.

[0074] Example 6 is a computing system based on any or all of the previous examples, and also includes: The deployment engine is configured to receive roles, retrieve VM images based on those roles, and deploy the VM images to the execution environment.

[0075] Example 7 is a computing system based on any or all of the previous examples, and also includes: A set of role-to-image mappings maps roles to VM images. The deployment engine accesses a set of role-to-image mappings to identify VM images.

[0076] Example 8 is a computing system based on any or all of the previous examples, and also includes: The VM image repository stores VM images, and the deployment engine retrieves VM images from the VM image repository for deployment.

[0077] Example 9 is a computing system according to any or all of the previous examples, wherein the execution environment includes: The measurement system is configured to generate VM image measurements and provide the VM image measurements to the key service.

[0078] Example 10 is a computing system according to any or all of the previous examples, wherein the measurement system performs a hash function on a VM image to obtain a hash value that includes the VM image measurement.

[0079] Example 11 is a computer-implemented method that includes: The key service identifies the execution environment service and indicates the virtual machine (VM) image measurement of the virtual machine image deployed in the execution environment; Determine whether VM image measurements are mapped to the execution environment service; Generate evaluation signals that indicate the determination of the criteria; In response to an evaluation signal indicating that a VM image measurement is mapped to an execution environment service, a set of role keys is obtained, which correspond to the execution environment service and enable the execution environment to execute the execution environment service. Encrypting a set of role keys for a single role key; and Provides a set of encrypted role keys for the execution environment.

[0080] Example 12 is a computer-implemented method according to any or all of the preceding examples, further comprising: The role of receiving and executing environment services; Receive VM image measurements; and Receive an execution environment identifier from the requesting execution environment, the execution environment identifier identifying the requesting execution environment, and wherein determining whether a VM image measurement is mapped to an execution environment service includes determining whether the requesting execution environment is mapped to a VM image measurement based on the execution environment identifier, and generating an evaluation signal includes generating an evaluation signal based on the determination.

[0081] Example 13 is a computer-implemented method according to any or all of the previous examples, wherein determining whether a VM image measurement is mapped to an execution environment service includes: It is determined whether a VM image measurement is mapped to a role by accessing a set of assets that map each role in multiple different groups of roles to a different VM image measurement.

[0082] Example 14 is a computer-implemented method according to any or all of the previous examples, wherein the encrypted role key includes: The identifier is mapped to one or more key wrapper keys of the role; and Encrypt the role key using one or more identified key wrapper keys.

[0083] Example 15 is a computer-implemented method according to any or all of the preceding examples, further comprising: Receive the role at the deployment system; VM images are obtained at the deployment system based on roles by accessing a set of role-to-image mappings that map roles to VM images; and Deploy the VM image to the execution environment.

[0084] Example 16 is a computer-implemented method according to any or all of the preceding examples, further comprising: Measurements are generated using a measurement system within the execution environment to create VM image samples; and Provide VM image measurements to the key service.

[0085] Example 17 is a computer implementation method according to any or all of the previous examples, wherein generating a VM image measurement includes: The measurement system is used to perform a hash function on the VM image to obtain a hash value that includes the VM image measurement.

[0086] Example 18 is a computing system that includes: The execution environment executes services represented by deployed virtual machine (VM) images and identified by roles; The measurement system is configured to apply a hash function to a VM image to generate VM image measurements and provide these measurements to a key service. The execution environment provides roles and VM image measurements to the key service to request a set of role keys. The decryption system receives a set of packaged role keys from the key service and decrypts the packaged role keys to obtain the requested set of role keys. The execution environment uses the requested role keys to perform services.

[0087] Example 19 is a computing system according to any or all of the previous examples, wherein the key service includes: The policy engine receives roles, identifying services, and VM image measurements indicating virtual machine images deployed in the execution environment from the execution environment. It then determines whether VM image measurements are mapped to roles and generates an evaluation signal indicating the determination. The key-wrapping cryptographic engine obtains and wraps a set of role keys based on the evaluation signal indicating that the VM image measurement is mapped to a role. The key service provides the execution environment with a set of wrapped role keys.

[0088] Example 20 is a computing system according to any or all of the previous examples, and also includes: The deployment system includes a set of role-to-image mappings that map roles to VM images and a VM image repository that stores VM images. The deployment engine is configured to retrieve VM images from the VM image repository for deployment by accessing the role-to-image mappings based on roles, and is configured to deploy VM images to the execution environment.

[0089] Although the subject matter has been described using language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

Claims

1. A method performed by a computing system, the method comprising: Receive a request to deploy computing services in the execution environment of the computing system; Before executing at least a portion of the computing services in the execution environment, In the execution environment, a measurement function is applied to a virtual machine (VM) image, which defines the computing service deployed in the execution environment. The computing system generates VM image measurements based on the application of the measurement function; The computing system sends a key request to the key service, the key request including instructions from the computing service and the VM image measurement, and In response to the key request, a key indicating that the VM image measurement is mapped to the compute service is obtained from the key service, wherein the key enables the execution environment to execute the portion of the compute service; as well as The key is used to execute the portion of the computing service in the execution environment.

2. The method according to claim 1, wherein the measurement function comprises a hash function.

3. The method of claim 1, wherein the computing service is identified by a role, and the method further includes sending an indication of the role to the key service.

4. The method of claim 3, wherein obtaining the key includes receiving a role key associated with the role from the key service.

5. The method of claim 1, wherein the execution environment includes a trusted execution environment.

6. The method of claim 4, wherein the role key includes an encrypted role key.

7. The method of claim 6 further includes decrypting the encrypted role key to obtain the key.

8. The method according to claim 3, further comprising: The computing service is deployed to the execution environment using a VM image.

9. The method according to claim 8, further comprising: Obtain the VM image from the deployment system.

10. The method of claim 9, wherein the deployment system accesses the role-to-image mapping that maps the role to the VM image.

11. A computing system, comprising: At least one processor; as well as A memory storing instructions executable by the at least one processor, wherein the instructions, when executed, cause the computing system to: Receive a request to deploy computing services in the execution environment of the computing system; Before executing at least a portion of the computing services in the execution environment. In the execution environment, a measurement function is applied to a virtual machine (VM) image, which defines the computing service deployed in the execution environment. The computing system generates VM image measurements based on the application of the measurement function; The computing system sends a key request to the key service, the key request including instructions from the computing service and the VM image measurement, and In response to the key request, a key indicating that the VM image measurement is mapped to the compute service is obtained from the key service, wherein the key enables the execution environment to execute the portion of the compute service; as well as The key is used to execute the portion of the computing service in the execution environment.

12. The computing system of claim 11, wherein the measurement function comprises a hash function.

13. The computing system of claim 11, wherein the computing service is identified by a role, and wherein the instruction, when executed, causes the computing system to send the role's instruction to the key service.

14. The computing system of claim 13, wherein the instructions cause the computing system to receive a role key associated with the role from the key service.

15. The computing system of claim 14, wherein the role key is received from the key service based on determining that the VM image measurement is mapped to the role.

16. The computing system of claim 14, wherein the role key includes an encrypted role key, and the instruction causes the computing system to: The encrypted role key is decrypted to obtain the key.

17. The computing system of claim 14, wherein the instructions, when executed, cause the computing system to: Obtain the VM image from the deployment system; and The computing service is deployed to the execution environment using a VM image.

18. The computing system of claim 17, wherein the deployment system accesses a set of role-to-image mappings that map the role to the VM image, and receives the role key from the key service based on determining that the VM image is mapped to the role.

19. A computing system, comprising: At least one processor; as well as A memory storing instructions executable by the at least one processor, wherein the instructions are provided when executed: Measurement system, the measurement system being configured as follows: Before executing at least a portion of the computing services in the execution environment. In the execution environment, a measurement function is applied to a virtual machine (VM) image, which defines the computing service deployed in the execution environment. VM image measurements are obtained by applying the measurement function to the VM image. Send a key request to the key service, the key request including an indication of the computing service and the VM image measurement; as well as Execution environment, wherein the execution environment is configured as follows: Based on determining that the VM image measurement is mapped to a role corresponding to the compute service, a role key is received from the key service, wherein the role key enables the execution environment to execute at least a portion of the compute services of the compute service, and The key is used to execute the portion of the computing service in the execution environment.

20. The computing system of claim 19, wherein The measurement function includes a hash function, and The instructions are provided when executed: A decryption system receives an encrypted role key associated with the role from the key service and decrypts the encrypted role key to obtain the key.

Images