The Trusted Cloud project at Microsoft Research aims to provide customers of cloud computing complete control over their data: no one should be able to access the data without the customer’s permission. Even if there are malicious employees in the cloud service provider, or hackers break into the data center, they still should not be able to get access to customer data.
Trust model: We use a non-hierarchical trust model. That is, we don’t want to trust the cloud operating system (CloudOS), middleware and other infrastructure components of the cloud, and still want to guarantee confidentiality and integrity of the user’s data and code. This implies a TCB (Trusted Computing Base) which excludes the CloudOS. Some design options are shown below:
Trusted Hardware: We wish to guard against a powerful adversary who can compromise the CloudOS, and uses all privileges of the CloudOS to compromise the integrity and confidentiality of user applications. This powerful adversary is realistic for two reasons. First, the CloudOS is likely to have vulnerabilities that hackers may exploit. Second, some individuals inside cloud data centers may be malicious and have super user privileges in the CloudOS. Secure hardware and/or small trusted hypervisors are the main weapons in our arsenal to guard against such powerful adversaries. Secure hardware (such as Intel SGX) enables user mode applications to package code and data into regions that are isolated from all other software running on the machine. Isolated regions can also be implemented with a small trusted hypervisor. However, it is an open research question as to how entire cloud services can be built using trusted hardware as a primitive, while maintaining a small TCB, providing good performance and end-to-end security guarantees. The Trusted Cloud project explores ways to answer this question.
Our world view: We imagine a world where distributed applications are built using trusted and untrusted components. Components communicate with each other using messages. Untrusted components are run on usual runtimes. Trusted components are those components that contain “secure isolated regions” (denoted by red dotted rectangles) that are run using secure hardware.
Data is always encrypted when inside untrusted components. Keys are available only inside the secure isolated regions within trusted components. One of our goals is to build various cloud services with this world view, while having acceptable performance and end-to-end security guarantees.
Layered Architecture for Trusted Components: We imagine a world where distributed applications are built using trusted and untrusted components. Untrusted components can be developed using usual hardware and software stack. Trusted components, and in particular secure isolated regions, need a separate hardware and software stack. Secure hardware such as Intel’s SGX or ARM’s TrustZone provides primitives for isolated execution. We have designed a thin abstraction layer called “Secure Hardware Abstraction Layer” (SHAL) which is a uniform API to enable applications to create and manage “Secure Isolated Regions” in a uniform manner, independent of the specific hardware platform (e.g. Intel SGX) or the specific hypervisor (eg. HyperV) that is being used to provide primitives for isolated execution.
Specific efforts: The Trusted Cloud project has several specific efforts to build specific trusted verticals (such as big-data analytics, machine learning and databases) to common infrastructure (such as key managers, hardware abstraction layers and runtimes, verification methodologies for end-to-end security).