HK40009816B - Secure key management - Google Patents

Description

Secure key management

Background

Computers and computing systems affect nearly every aspect of modern life. Computers are commonly involved in work, leisure, medical, transportation, entertainment, home management, and the like.

Furthermore, computing system functionality may be enhanced by the ability of the computing system to interconnect to other computing systems via network connections. The network connection may include, but is not limited to, a connection via wired or wireless ethernet, a cellular connection, or even a computer-to-computer connection through serial, parallel, USB, or other connection. These connections allow the computing system to access services at other computing systems and receive application data from other computing systems quickly and efficiently.

The interconnection of computing systems helps in distributed computing systems, such as so-called "cloud" computing systems. In this description, a "cloud computing" may be a system or resource for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services, etc.), which may be provided and released with reduced management effort or service provider interaction. The cloud model may be composed of various features (e.g., on-demand self-service, wide network access, resource pools, rapid resilience, measured services, etc.), service models (e.g., software as a service ("SaaS"), platform as a service ("PaaS"), infrastructure as a service ("IaaS"), and deployment models (e.g., private cloud, community cloud, public cloud, hybrid cloud, etc.).

In cloud computing systems, there are cloud service providers and tenant (tenant) customers. While tenant customers wish to use cloud computing system resources, these customers typically do not wish for individuals at the cloud service provider (e.g., cloud service provider employees or others who may physically access the cloud service provider resources) to access the customer's data. Thus, there is a need for tenant customers to manage data in situations where a third party is not actually able to view the data.

The subject matter claimed herein is not limited to implementations that solve any disadvantages or that operate only in environments such as those described above. Rather, the present background is provided only to illustrate one exemplary technology area where some embodiments described herein may be practiced.

Disclosure of Invention

One embodiment described herein includes a machine. The machine includes a dedicated area (enclave). The private area includes a protected area of the application address space that the application is prevented from accessing for any application code that is not itself located in the private area unless keys can be provided into the private area by one or more management private areas. The machine also includes a management area coupled to the area. The management area is configured to provide keys to the area. A management private area is a protected area of the application address space that is blocked from access for any application code that is not itself located in the management private area.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Additional features and advantages will be set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the teachings herein. The features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. The features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter.

Drawings

In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments thereof which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered limiting in scope, the embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which:

FIG. 1 illustrates a machine including a management area and an area, and a certification certificate;

FIG. 2 illustrates a cloud system including a computing structure and a key structure; and

fig. 3 illustrates a method of securely managing tenants on a cloud system.

Detailed Description

The embodiments shown herein include the functionality of a hardware-based key protection system and hardware-based protection of Virtual Machines (VMs) in a cloud computing system. In particular, some modern processors include hardware instructions and architectural components that can be used to protect selected code and data from leakage or modification. The application may be partitioned into "private areas" that are enhanced by the CPU or protected execution areas that increase security. In particular, as used herein, a private area is a protected area of an application address space that is blocked from access for any software that is not itself located in the private area. This security can be maintained even on a compromise platform because the protected data and code are protected at the CPU level. That is, the CPU may prevent external software from accessing the private area. These private areas may be used to implement secure tenant data encryption key delivery and secure virtual machines for operating on tenant data. One example of such a private area and protected computation may be used for Intel SGX (Software Guard Extensions) available from Intel corporation of santa clara, california.

Fig. 1 shows a machine 100. Machine 100 is a physical hardware device configured to execute programming instructions. For example, the machine may include a Central Processing Unit (CPU). The machine includes a dedicated area 102. Private area 102 is a protected execution area that includes protected code and data. Private area 102 is protected because it has restricted (e.g., limited in CPU level) ingress and egress (ingress and egress). In particular, once the execution code and/or data is placed into the private area, it cannot be checked by any external entity. This includes both processor state and register state. Furthermore, it cannot be modified by external entities. The data may be placed into an external register 104 accessible to the code running in the private area 102, but the private area 102 will access this code when it is needed. Data cannot be forcefully provided into the private area 102, except as shown below, where the management private area 106 may provide a key (e.g., key 108) into the private area 102.

As mentioned, fig. 1 illustrates a management area 106. The management private area is similar to private area 102 in that it is a protected execution area. However, one difference is that the management area 106 has the ability to provide a key (e.g., key 108) into the area 102.

While restricted from exiting private area 102, one piece of content that private area 102 may generate and provide outside private area 102 is certificate of authenticity 110. The attestation certificate 110 may include verifiable information managed by a particular administrative specialty along with information about the specialty 102 itself for attesting that the specialty is running on a particular platform.

In particular, the attestation certificate 110 generated by the private area 102 includes a platform attestation 112. Platform attestation 112 includes verifiable evidence that private area 102 is implementing on a particular platform. This may include, for example, a particular machine 100. For example, the machine 100 may include a serial number or other characteristic or component that may be evaluated to create verifiable evidence unique to a particular machine 100. For example, a hashing algorithm may be used to create verifiable evidence using the sequence number of the processor and/or other characteristics or components of machine 100. For example, the hashing algorithm may hash (hash) the serial numbers of different components in the machine 100, a set of determined models (or other characteristics) of the components in the machine 100, or other characteristics of the machine 100.

Alternatively, this may simply be verifiable evidence that the platform to which machine 100 belongs typically has private area support. For example, verifiable evidence may assume that machine 100 includes zone support.

The attestation certificate 110 generated by the special area 102 includes a management attestation 114. The administrative proof 114 includes verifiable evidence that the private area 102 is being managed by the administrative private area 106, such as a fingerprint (fingerprint) of the private area 102. For example, code in the management specialty may be used to create verifiable evidence that the management specialty is being used for the management specialty 102. For example, a hashing algorithm may be applied to the code and/or data of the administrative district 106 to generate verifiable evidence, which may then be used in the administrative proof 114.

The certification certificate 110 generated by the private area 102 includes a private area certification 116. The private section proof 116 includes verifiable evidence of the private section. For example, the private section proof 116 may include a fingerprint of the code and/or data in the private section 106.

The attestation certificate 110 generated by the private area 102 includes an encryption function 118. The encryption function 118 may be used to encrypt data that is then placed in the registers 104. For example, encryption function 118 may be used as part of a public key exchange scheme, such as a Diffie-Hellman key exchange. In this way, data may be securely provided to the private area 102.

Using this basis, attention is directed to fig. 2, which illustrates the use of the specialized processor functions in implementing virtual machines for tenants of the cloud service. In particular, in general, customer tenants of cloud service 200 do not have a secure infrastructure, so they purchase resources from cloud service providers that can provide the secure infrastructure. In cloud service 200, cloud resources, such as computing resources (e.g., processor cycles), memory resources, and storage resources are shared among a plurality of different tenants. The physical machines in cloud service 200 host these resources and provide resources to individual tenants as needed. However, the tenant also does not need the cloud service provider to access unencrypted tenant data. Thus, particular tenants have keys 108 associated with their data that are used in a secure manner to ensure that the tenant's data 120 is not exposed to other tenants or to individuals at the cloud service 200. Because resources on different machines are shared and different machines may be used at different times for different tenants, key 108 needs to be shareable among different machines, hosted by cloud service 200, and verifiable evidence needs to assume that cloud service 200 does not know the value of key 108.

In the example shown, this may be achieved by using a key management structure 124 and a computing structure 126.

Key management structure 124 includes a plurality of machines 110-2-1 through 100-2-m selected from machines at cloud service 200 and configured to manage keys 108 for a particular tenant. In this way, keys can be stored redundantly for tenants at as much redundancy level as is needed.

Each machine in the key management structure 124 is coupled to a local storage device 122-1 through 122-m, respectively.

Fig. 2 shows a computing structure 126. The computing structure includes a plurality of machines 100-1-1 through 100-1-n selected from machines available at the cloud service 200 and configured to implement virtual machines for tenants. In particular, a tenant will require some virtual machine to run for that tenant. These virtual machines may be implemented using private areas 102-1-1 through 102-1-n. In particular, VM code may be implemented in private areas 102-1-1 through 102-1-n. The code for each zone may be provided by the cloud service provider or may be provided to the cloud service provider by the tenant to implement the zone for that tenant. In either case, the tenant may verify the VM by checking a attestation certificate generated by the private area running the VM, the attestation certificate including a private area attestation for each private area with a fingerprint of that private area.

Note that machines 100-1-1 through 100-1-n and machines 100-2-1 through 100-2-m each have a management area 106-1-1 through 106-1-n and a management area 106-2-1 through 106-2-m, respectively. In some embodiments, management monographs 106-1-1 through 106-1-n and management monographs 106-2-1 through 106-2-m all have the same executable code running in them. Thus, the expertise on these machines for the tenant, either in key structure 124 or in computing structure 126, will generate a certification certificate, such as that shown in FIG. 1, with the same administrative certificates. This allows each of the management monographs 106-1-1 through 106-1-n and 106-2-1 through 106-2-m to communicate with each other in a secure manner and reject communication with any management monographs that are not capable of generating a management proof. Using this functionality, security key creation and management may be implemented for a particular tenant.

It should be noted that although discussed in more detail below, other forms may be used to authenticate the management area. For example, in an alternative embodiment, two management areas that do not share the same fingerprint may still identify each other as trusted. The private area may implement complex and flexible policies. Thus, for example, management areas 106-1-1 through 106-1-n may be different and have different fingerprints than management areas 106-2-1 through 106-2-m, but may still be able to communicate with each other based on a trust analysis. Similarly, one or more of the management areas 106-1-1 through 106-1-n may be different from each other but still be able to communicate with each other based on the trust analysis. Similarly, one or more of the management areas 106-2-1 through 106-2-m may be different from each other but still be able to communicate with each other based on the trust analysis.

For example, in some implementations, a management specialty may be able to determine that another management specialty is running a different version of the same code. This may be accomplished, for example, by examining a private certificate (e.g., private certificate 116) of a certificate of certification (e.g., certificate of certification 110) to verify information about the code author, signing a authority, or otherwise. For example, the private certificate may include an indicator created using all three of: an indication of the signing authority, an indication of what signing authority the function of the code claims, and an indication of the version of the code claims by the signing authority. The reception management area may include a function for verifying the three indicators.

Thus, the management area may have matching functionality incorporated into the management area code. This matching function may be configured to require an exact match in the private proof or may allow for approved changes.

Consider, for example, the following scenario. In the first scenario, the management special area 106-2-1 generates the attestation certificate 110-1. The certificate of certification 110-1 includes a private certificate 116-1. The private section certificate 116-1 includes information about the management private section 106-2-1. For example, in the present case shown, management private area 106-2-1 may include functionality for computing a hash of code implementing management private area 106-2-1. In this example, the management private area needs to match the code to trust other private areas. Thus, if the administrative special area 106-1-1 receives the attestation certificate 110-1, the administrative special area 106-1-1 will only trust the administrative special area 106-2-1 if the special area attestation 116-1 can be generated by the administrative special area 106-1-1 by hashing its own administrative special area code.

In alternative embodiments, the management private area may be able to determine that other management private areas can be trusted even when those other management private areas are not running exactly the same code. For example, the management private 106-2-1 may generate the attestation certificate 110-1, wherein the attestation certificate 110-1 includes a private attestation 116-1 based on: verifiable evidence of the author of the management specialty code running in management specialty 106-2-1, verifiable evidence of the purpose of the specialty code running in management specialty 106-2-1, and verifiable evidence of the version of the management specialty code running in management specialty 106-2-1. Each of these management monographs, including management monograph 106-1-1, may include functionality for receiving attestation certificate 110-1 and verifying monograph attestation 116-1.

Various examples of how verification works are described below in some embodiments. The certificate of certification contains information that can uniquely identify the area. This includes a digital fingerprint of all code and data that is loaded into the private area when created, and may optionally also include information identifying signing by some trusted authority. In the simplest case, the verification (e.g. between two management areas) may be performed by the management areas performing the following operations:

1) Requesting other management areas to send the certification report.

2) Verification that the certification report from the other administrative district is properly signed by the remote system to indicate that it is a trusted certification report.

3) The requesting CPU prepares a certification report for itself (trusted because it comes directly from the CPU).

4) The identity information present in the self-certification is compared with the identity information present in the remote certification. If they match, the management area has a dialogue with another copy of itself and can therefore trust it.

Alternative versions used by different versions of the management private area or between the private area and the management private area replace steps 3-4 by comparing the identity information used in the remote attestation with policy information used to determine which identities represent trusted private areas.

Key 108 may be stored redundantly in key structure 124. Key 108 may be derived from key structure 124 in a number of different ways. For example, in some implementations, the tenant may provide the key 108 to one of the management areas (e.g., management area 106-2-1). Optionally, the management area may include functionality for obtaining the key 108 from the machine. Thus, for example, management area 106-2-1 may request that the CPU at machine 100-2-1 calculate the appropriate key using the appropriate algorithm.

To redundantly store keys 108, management private 106 is able to share keys with each other, but will not share their keys with other entities (including other compromised management private), or in some embodiments other management private running the same code (or approved and verifiable versions of the code, e.g., different versions of the management private code), unless management private 106 can provide keys 108 in the associated private so that those associated private can decrypt the tenant's data. As mentioned above, the management area 106-2-1 may request that the CPU at the machine 100-2-1 calculate the appropriate key using some appropriate algorithm. The root of this derivation is the key that is later provided by the management private area to the other private areas. Thus, the management area provides the key into a location that the CPU uses to derive the key. In an alternative embodiment, the management area places the key into a special register at another machine to provide the key.

The management area will not provide the key 108 to another management area unless the management area can determine that the other management area is trusted, for example, by determining that the management area is running the same management area code or other approved code, such as the code described above, in some embodiments. This may be accomplished by examining the certification certificates of the management area to determine management certification matches. Thus, in this example, the management specialty may determine that another management specialty has the same fingerprint or an approved fingerprint, and thus it may be safe to communicate with the other management specialty.

Each of the management areas 106-2-1 through 106-2-m encrypts the management key using a machine key unique to the particular machine on which the management area is running to create encryption keys 108-1 through 108-m and store the encryption keys 108-1 through 108-m in storage devices 122-1 through 122-m associated with their respective machines, respectively. Each of the management monographs 106-2-1 through 106-2-m is configured to store the encrypted tenant key locally and exclusively on its respective machine in a storage device. That is, the management areas running in the key management structure have the ability to store client keys in encrypted form on their local storage devices and only on their local storage devices.

To accelerate the virtual machine (spin up), machines in the computing structure 126 will accelerate the management specialty 106 and specialty 102. For example, in the example shown in FIG. 2, machine 100-1-1 accelerates management of private area 106-1-1 and private area 102-1-1. The management special area 106-1-1 runs the same code as the management special areas 106-2-1 through 106-2-m in the key structure 124. Thus, the management special area 106-1-1 may securely communicate with the management special areas 106-2-1 through 106-2-m using the attestation certificate. This allows the management private area in the key structure 124 to obtain the encrypted tenant key from the storage device, decrypt the encrypted key, and provide the key 108 to the management private area in the computing structure. For example, management area 106-2-1 may obtain encrypted key 108-1 from storage device 122-1. The management area 106-2-1 may decrypt the encrypted key 108-1 using the machine key of the machine 100-2-1 to obtain the key 108. The key 108 may then be provided to the management area 106-1-1.

At machine 100-1-1, management area 106-1-1 may provide key 108 into area 102-1-1. Private area 102-1-1 may then be used to obtain tenant's data from storage device 120 and decrypt the data using key 108. In one embodiment, the private area architecture defined by the CPU may provide privileged instructions that are only available to the management private area, allowing it to transfer keys directly into the address space of the private area. In another embodiment, the management private area and private area may establish a secure connection using mutual authentication (via attestation), and the management private area may communicate keys over the secure connection.

Any tenant in their private area that needs key portability must trust the cloud service 200 to manage keys on their behalf or must provide their own key management system. Any model can be implemented without requiring the client to trust the cloud service to keep the keys secret, as the hardware will do that for them. Thus, in summary, the design may be as follows:

the design includes a key management structure that includes a set of servers hosting a per-customer key management private area (which may be written by a cloud provider or may be customer-provided). Each server is able to run a (non-migratable) management area per client that stores the master key for that client.

2. When a new client master key is needed, the key management structure starts an instance of the client's management area on each key management server. One instance generates a new random key and then distributes it to all other instances (using the private certificate to verify that each endpoint is the correct management private for that client). The client's master key is now fully replicated.

3. Each management area obtains a CPU-derived encryption key for sealing the master key. This sealing key is generated by the private area architecture and includes a machine-specific secret and a cryptographic hash of the management private area. Each master key now resides on each key management server using a hardware protected key.

4. When a client workload specific area requires a master key, it contacts the key management structure to obtain a connection with an instance of the client specific management specific area. It establishes a secure connection to that private area, uses the proof to verify that it is obtaining the key from the correct management private area, and then obtains the key.

Such a system may have one or more of the following characteristics:

A. the cloud data center cannot be forced to reveal any master keys because each master key is sealed with an encryption key specific to the exact key management code (protected by the CPU's private key). Any attempt to modify the management area to allow leakage will result in a change to the sealing key, thus preventing the master key from being successfully decrypted. In addition, any attempt to persuade the anti-compromised version of the management private area to compromise the master key to a compromised version of that private area will prove prohibitive (since each management private area only compromised the master key to a version of the management private area that it knows is anti-compromised).

B. Each client workload may verify that the management area does not allow leakage of the master key because it may prove that its key is being provided by a particular anti-leakage version of the management area. Suspicious customers may obtain the guarantees by themselves providing management areas.

C. The master key is protected from disasters because the key management structure provides sufficient replication to ensure key availability.

The following discussion now refers to various methods and method acts that may be performed. Although method acts may be discussed in a certain order or illustrated in a flowchart as occurring in a particular order, no particular ordering is required unless specifically specified or required because the act depends on another act being completed before the act is performed.

Referring now to FIG. 3, a method 300 is shown. Method 300 includes an act of securely managing tenants on a cloud system. The method includes obtaining a tenant key (act 302). For example, for purposes of method 300, a tenant key may be obtained from a tenant of a cloud service. Alternatively or in addition, tenant keys may be generated at the cloud service and obtained by the management private area. Alternatively or additionally, a particular management private area may obtain a tenant key from another management private area. As will be discussed in more detail below, this may be implemented by a management area running the same application code. Note that the same application code may include different versions of the same application code. That is, one management private area may run one version of the application code, while a different management private area runs a different version of the same application code. Nevertheless, the management private area may still be able to pass tenant keys to each other by verifying the application code (whether the same version or a different version).

The method 300 also includes providing the tenant key into a private area on the machine at a management private area on the machine in a computing structure in the cloud service (act 302). For a given private area, for any application code that is not itself located in the given private area, the management private area and private area are protected areas of the application address space that are blocked from access unless the management private area can provide keys to the tenant private area. In some implementations, the management area may be limited to being able to only provide tenant keys into areas running on the same machine as the management area. Thus, for example, the management area 106-1-1 can provide the key 108 into the area 102-1-1 because they are all running on the same machine 100-1-1. However, managing the private area 106-1-1 is not able to provide the keys 108 into the private area 102-1-1 because they are on different machines.

The private area is configured to perform a function for the cloud service tenant. Note that the application code may be in a different instance of the special area, but as long as it is the same application code, it can access the special area. For example, the management special area 106-2-1 may be able to provide the key 108 to the management special area 106-1-1 if both management special areas run the same application code. As mentioned, this may be confirmed using a certification certificate (e.g., certification certificate 110-1 shown in fig. 2).

It is further noted that as used herein, the same "application code" may include different versions of the same code. However, the application code in the management area may be configured to allow communication with different versions of the same application code. For example, the management special area 106-2-1 may be able to provide the key 108 to the management special area 106-1-1 if both management special areas run different versions of the same code. As mentioned, this may be confirmed using a certification certificate (e.g., certification certificate 110-1 shown in fig. 2). For example, some embodiments may verify a certification certificate that includes a private certification of the management private area. The private section proof includes verifiable evidence of the signing authority, verifiable evidence of the signing authority regarding what function the application code has, and verifiable evidence of the version of the signing authority of the application code.

Thus, method 300 may be practiced wherein obtaining the tenant key comprises: obtaining a tenant key from another management specialty running a version of the same application code by verifying that the other management specialty is running mutually-approvable and authenticatable management specialty codes, such that the tenant key may be transferred between management specialty in a trusted manner by approval and authentication of the management specialty codes by the management specialty.

In some such embodiments, verifying that another administrative district is running mutually-approvable and authenticatable application code includes: and verifying that another management area is running the same application code.

Alternatively or additionally, in some such embodiments, verifying that another administrative district is running mutually-approvable and authenticatable administrative district codes includes: verify that another administrative district is running a different version of the application code, which may be verified as a different version of the application code.

In some such embodiments, verifying that another management specialty is running a different version of the management specialty code comprises: the certification certificate including the private area certification of the management private area is verified. The private section proof includes verifiable evidence of the signing authority, verifiable evidence of the signing authority regarding what function the application code has, and verifiable evidence of the version of the signing authority of the application code.

In some embodiments, the management private area and private area are peers (peers) that use mutual authentication and attestation to verify that the key issuer management private area is a trusted issuer, and the recipient private area is a trusted recipient of the key. This may be performed, for example, by using a certification certificate as described above. In particular, the administrative district and district may verify that the other party is using mutually approved and verifiable codes, respectively. This may be done by the administrative district and district running the same code as defined above or by some other district mutually agreeing to the code.

The embodiments shown herein may be practiced by a computer system comprising one or more processors and a computer-readable medium, such as a computer memory. In particular, the computer memory may store computer-executable instructions that, when executed by one or more processors, cause various functions, such as the acts recited in the embodiments, to be performed.

Embodiments of the invention may include or utilize a special purpose or general-purpose computer including computer hardware, as discussed in greater detail below. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. The computer-readable medium carrying computer-executable instructions is a transmission medium. Thus by way of example, and not limitation, embodiments of the invention may include at least two distinct types of computer-readable media: physical computer readable storage media and transmission computer readable media.

Physical computer-readable storage media include RAM, ROM, EEPROM, CD-ROM or other optical disk storage (e.g., CD, DVD, etc.), magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code modules in the form of computer-executable instructions or data structures and that can be accessed by a general purpose or special purpose computer.

A "network" is defined as one or more data links that enable transmission between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmission media can include networks and/or data links which can be used to carry desired program code modules in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.

Furthermore, when reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be automatically transferred from a transmission computer-readable medium to a physical computer-readable storage medium (or vice versa). For example, computer-executable instructions or data structures received over a network or data link may be cached in RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to computer system RAM and/or a less volatile computer-readable physical storage medium at a computer system. Thus, a computer readable physical storage medium may be included in a computer system component that also (or even primarily) utilizes transmission media.

Computer-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. The computer-executable instructions may be, for example, binary, intermediate format instructions such as assembly language or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts described above. Rather, the features and acts are disclosed as example forms of implementing the claims.

Those skilled in the art will appreciate that the invention may be practiced with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, switches, and the like, in a network computing environment. The invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (e.g., by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

Alternatively or in addition, the functions described herein may be performed, at least in part, by one or more hardware logic components. For example and without limitation, illustrative types of hardware logic layouts that may be used include Field Programmable Gate Arrays (FPGAs), program specific integrated circuits (ASICs), program specific standard products (ASSPs), system-on-a-chip (SOCs), complex Programmable Logic Devices (CPLDs), and the like.

The present invention may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

Claims (15)

1. A system, comprising:

a computing structure comprising a first plurality of machines, each machine of the first plurality of machines running a first management private area and a tenant private area, wherein for each machine of the first plurality of machines, the first management private area is configured to provide one or more tenant keys into the tenant private area; the tenant private area corresponds to a protected area of application address space that is blocked from access for any application code that is not located in the tenant private area; and the first management private area corresponds to a protected area of application address space that is blocked from access for any application code that is not located in the first management private area unless the first management private area is permitted to provide the one or more tenant keys to the tenant private area; and

a key structure comprising a second plurality of machines, each of the second plurality of machines running a second management private area, wherein for each of the second plurality of machines, the second management private area is configured to have one or more encrypted tenant keys stored locally and exclusively on the second machine, and wherein each of the first management private area and the second management private area run mutually-approvable and authenticatable management private area application codes, allowing approval and authentication of management private area application codes by management private areas of different machines to transfer the tenant keys between the management private areas in a trusted manner.

2. The system of claim 1, wherein each of the first and second management monographs runs mutually-approvable and authenticatable management monograph application code by running the same application code.

3. The system of claim 1, wherein each of the first and second management monographs runs mutually-approvable and authenticatable management-monograph application code by running different versions of the same application code that can be verified as different versions of the same application code.

4. A system as claimed in claim 3, wherein the first and second management monographs are configured to verify different versions of the same application code by verifying a certification certificate comprising a monograph certificate of the management monograph, wherein the monograph certificate comprises verifiable evidence of a signing authority, verifiable evidence of a signing authority regarding what function the application code has, and verifiable evidence of a version of the application code declared by a signing authority.

5. The system of claim 1, wherein each of the second management areas is configured to encrypt and decrypt tenant keys using a machine key of a machine on which each second management area is running.

6. The system of claim 1, wherein the system is configured to generate a tenant key.

7. The system of claim 1, wherein the system is configured to receive a tenant key from a tenant.

8. A machine, comprising:

a tenant private area corresponding to a protected area of application address space that is blocked from access for any application code that is not itself located in the tenant private area unless keys can be provided to the tenant private area by one or more management private areas; and

a management private area coupled to the tenant private area, wherein the management private area is configured to provide keys to the tenant private area, and wherein the management private area corresponds to a protected area of application address space that is blocked from access for any application code that is not itself located in the management private area.

9. The machine of claim 8, wherein the management monograph is configured to communicate with other management monographs running mutually-approvable and authenticatable application code such that tenant keys can be communicated between the management monographs in a trusted manner by approval and authentication of management monograph application code by the management monographs.

10. The machine of claim 9, wherein the management area is configured to communicate with other management areas running the same application code.

11. The machine of claim 9, wherein the management specialty is configured to communicate with other management specialty that run different versions of the same application code that can be verified as different versions of the same application code.

12. The machine of claim 11, wherein the administrative specialty is configured to verify different versions of the same application code by verifying a certification certificate that includes a specialty certificate of the administrative specialty, wherein the specialty certificate includes verifiable evidence of a signing authority, verifiable evidence of a signing authority regarding what function the application code has, and verifiable evidence of a version of the application code declared by the signing authority.

13. The machine of claim 8, wherein the management area is configured to encrypt and decrypt tenant keys using machine keys of the machine.

14. The machine of claim 8, wherein the tenant private area is configured to perform functions for a cloud service tenant, and wherein the management private area is configured to provide tenant keys into the tenant private area.

15. A method of securely managing tenants on a cloud system, the method comprising:

obtaining a tenant key; and

providing the tenant key into a tenant private area on a machine in a computing structure in a cloud service at a management private area on the machine, wherein the management private area corresponds to a protected area of application address space that is blocked from access for any application code that is not itself located in the management private area, and the tenant private area corresponds to a protected area of application address space that is blocked from access for any application code that is not itself located in the tenant private area, unless the management private area is capable of providing keys to the tenant private area, and wherein the tenant private area is configured to perform functions for a cloud service tenant.