Confidential Computing

Path towards the vision of Confidential Clouds

Raghu Yeluri, Sr. Principal Engineer and Lead Security Architect in the Office of the CTO/Security Architecture and Technology Group

Intel

Published in

Intel Tech

9 min readNov 14, 2022

Let me start with an assertion. In the next 7–10 years all clouds will be confidential clouds. We will stop qualifying clouds with the word confidential. All clouds, by their very nature, will be confidential clouds. There are many key requirements that must be addressed by the industry over this time frame to operationalize confidential clouds. This blog is an attempt to enumerate some of the key requirements, drive a dialog amongst my confidential computing colleagues and cloud practitioners, and educate the industry at large.

So.. what are confidential clouds? A little bit of context before we define it.

Companies are aggressively moving to ‘cloud first’ and ‘cloud only’ strategies for application deployment. Simultaneously, regulators and legislators are increasing the requirements on organizations to protect the data they manage. Companies and organizations are looking for ways to run sensitive applications (or applications that handle sensitive data) in public clouds, but are looking for stronger security, isolation, auditability. Zero Trust architectures are becoming more pervasive — not just for network access but for access and execution of data, and IP everywhere. Companies are requiring that their data is protected in all states of its modalities : at-rest, in-transit and during use; from operators of the infrastructure, from malware, from other customers running on the same infrastructures. In essence, like one CTO of a hyperscale has once said: customers are looking for a private cloud or better security in a public cloud.

With that background, let me define what confidential clouds are.

Confidential clouds provide strong, auditable isolation and security for customer workloads and data from the infrastructure, provider administrators/devOps, malware, other tenants. In short, they will keep the service provider outside the trust boundary — at-rest, in-transit and during use.

Confidential clouds employ Confidential Computing technologies to establish a more secure and cryptographic perimeter that seamlessly extends from a hardware root of trust to protect data in use, at rest, and in motion. They put the data owners in control wherever their data is stored, transmitted, or used. confidential clouds extend data encryption and resource isolation across all of the fundamental elements of IT, compute, storage, and network. Compute doesn’t mean just the CPU. Any component on a compute, storage, or network platform that either processes, manages, accesses User data and code has to be Confidential.

The confidential cloud has all the elements needed to confidentially run any workload in a trusted environment isolated from Cloud Infrastructure insiders, malicious software, or would-be attackers. This also means workloads(data and code) remain more secure even in the event a compute platform is physically and network compromised. Even an attacker with root-access to a server/compute platform would be effectively prevented from seeing data or gaining access to data and application bringing a level of security traditional micro-segmentation can’t today.

To be able to keep the service provider outside the ‘trust boundary’, but leverage the scale, services, automation and elasticity provided by the service provider, and to run your workloads, operate on data and offer services to your customers is not straightforward. A lot of things have to fall in place — technology, processes, methodologies, governance, etc. to realize the vision of confidential clouds and make it real.

Here is a list of key requirements needed to operationalize confidential clouds. I am sure there are a few others to round up the requirements, but I believe these are some of the big ones that are required.

Pervasive availability of Confidential Compute Infrastructure

The fundamental technologies and methodology that underpins the Confidential Cloud are the Confidential Compute technologies. You can refer my blog on ‘confidential computing’ for definitions and details. Confidential compute uses Trusted Execution Environments (TEEs) to provide the isolation and improve security. All CPU vendors provide TEEs, with different levels of maturity, security properties and availability.

Intel has Intel SGX and Intel TDX to address different confidential clouds usage models for application isolation and VM isolation. AMD has AMD-SEV/SNP supporting VM Isolation. The enabling of the Hypervisors, and Operating systems is also at various levels of maturity. The container runtime and Kubernetes orchestration platforms that are enabled to detect and use confidential computing technologies are beginning to be available. This is the starting point to enable confidential clouds.

To be truly Confidential compute, and achieve the vision of confidential clouds, all components on the platform that touch customer data and code, have to be confidential compute enabled as well. This would be the GPUs (in-case you are offload AI/Machine learning training and inferencing to it), FPGAs, NICs, on-die/on-board accelerators, etc. The trust model has to cover all of these. And then there is the question of performance. We will look at that in the Performance and Benchmarking section.

Enable ZTA for customers — Trust Verification service.

Confidential clouds must enable Zero-Trust architecture with compute and applications, like it is done with network access today. It means that companies/organizations will verify the trust worthiness of every aspect of the infrastructure that is hosting, operating, and managing their workloads and data. They would verify the trust worthiness of the applications/workloads running on the infrastructure before they interact with it. This leads to “don’t trust anything. Verify everything” model. This verification process must be dynamic, automated and must integrated into the operational model of the cloud.

A Trust verification service supporting remote attestation verification capabilities is required. For some customers, a trust verification service provided by the infrastructure/cloud provider may suffice and meet their security requirements. For customers in regulated industries, an independent, provider independent service would be required from stronger isolation, and to meet their audit requirements. I would imagine a class of customers — DIY kind, the ultra-paranoid kind, who would want to manage their own trust verification service within their own firewalls.

All of these are valid models; it all depends on trust model and security requirements. Interoperability of these different trust verification services is critical, which requires standardization of APIs, data formats, trust-worthiness token formats, etc. The good news is that leading companies in this space — Intel, Microsoft, Google, IBM, etc., and the confidential computing consortium (CCC) are working towards the goal of standardization of this core capability of the confidential cloud stack.

Policy-based Key/Secret delivery and distribution

Applications need secrets, user-credentials, keys as they handle PII, sensitive data, sensitive IP (like training or inferencing models) etc. The data and IP are delivered in encrypted form (at-rest and in-transit protection) with the keys controlled by the customer.

Typically, keys are provided directly to the application during launch/pre-launch of the application to decrypt and execute. With confidential compute and the Zero-Trust model, the Key management systems have to verify that the applications are indeed running in TEEs, they are the right TEEs, and the application code inside the TEEs is the expected one. This verification comes from a Trust verification service mentioned above. Application owners and Data owners would need the ability to define policies declaratively and specify key release policies at runtime.

Key/secret management systems (KeyVaults, KMS… etc.) must be enhanced to integrate this step into the delivery flow. The keys must also be delivered via a secure channel directly in the TEEs. This policy-based key delivery and distribution is a key requirement towards operationalizing confidential clouds.

Confidential Cloud Governance

This is a very complex and not well understood requirement, given that the technologies and the paradigm is relatively new. How do the current cloud governance models change with the advent of confidential clouds? Currently, regulations and compliance requirements are well understood and there is a good governance framework to monitor, triage and remediate cloud operations, security and performance. What changes are required to support data-in-use protections with confidential clouds? Many open questions exist in this space, for example:

How do you articulate what is desired state of the system? How do you detect a breach?
What are the contractual obligations to meet regulations? Will they change from the standard cloud obligations?
Are there changes in the shared responsibility model of security between Provider and the Customer/organization?
What should the hardware vendors provide as telemetry to aid/facilitate in evaluation of controls?
What is the guidance for auditors/assessors, who evaluate compliance of confidential clouds for the organization data and applications?

It is great to see the CCC addressing this all-important space via the CCC governance WG. I expect there would be actionable guidance for hardware TEE vendors, ISV, OSV and the cloud service providers to provide the plumbing and the automation to provide necessary evidence for regulators to evaluate. I can even see additions to security controls and regulatory requirements like NIST 800–53, PCI-DSS, etc., in support of confidential clouds.

Benchmarking

Confidential Clouds are new. The confidential cloud stack is going to have some new components and new capabilities, compared to the traditional cloud stack. The benefits that confidential computing technologies provide via strong isolation and enhanced security to customer data and workloads, are not for free. There would be small performance hit to provide these capabilities. How do you characterize these? What are the overheads of confidential clouds? Are the overheads with performance or latency or both? How different is the runtime resource consumption with confidential clouds, compared to traditional?

This brings us to the question of benchmarks. Will the current cloud benchmarks apply? Will the current metrics suffice? What modifications are needed for the current cloud benchmarks — SpecCloud, PerfBenchmarker, etc. How portable will these benchmarks be given that confidential computing technologies from hardware vendors are very different in their operational aspects? No clear answers here.

Getting the right set of benchmarks to consistently classify performance, latency and scale is a very critical requirement for operationalization of confidential clouds. These benchmarks help determine capacity management, SLAs, QOS and determine OpEx requirements for organizations.

Certification & Standardization

The success of Confidential clouds depends not only on the core confidential computing technologies — which are of course the precursor for these clouds to exist, but a vibrant eco-system of ISVs across the spectrum. For this, there have been certain core set of standards, so whether the confidential cloud if from CSP1, or from CSP2 or on-prem, the capabilities and functions that the ISVs provide would work.

Standards have to exist across the stack –the way confidential computing technologies interact with applications, containers, VMs, etc., attestation data formats, APIs for trust verification services, trust verification report formats, key exchange and distribution protocols, telemetry for evaluating security controls, etc. Typically, standards lag behind some of the early implementors and visionaries, and confidential cloud standards are following the same path. I would imagine new security controls with NIS800–53, updates to PCI-DSS, updates to CIS guidelines, and updates to the NIST 800–161 etc.

Disaster recovery and business continuity

There are well defined workflows and models implemented for traditional clouds for DR and BC. It is unclear how much these models and workflows would change with Confidential Clouds. I haven’t dug enough into these to make any definitive statements about the type of changes required to have a reliable DR/BC strategy for confidential clouds. More on this in the future blogs.

Summary

Let me reiterate the assertion that I started this blog with. In 7 -10 years, all clouds will be confidential clouds — built on confidential computing paradigm and technologies. The shared responsibility model that is there today will be modified extensively. End customers and organizations will have complete control and security of their data and IP from the service/infrastructure provider. This blogs highlights some of the key requirements needed to operationalize confidential clouds. Hardware, software, ISVs and consortiums like CCC are working feverishly to make the vision of confidential clouds happen. Future blogs will delve in to details and progress towards each of these requirements.

Notices and Disclaimers:

Intel technologies may require enabled hardware, software or service activation.

No product or component can be absolutely secure.

Statements in this document that refer to future plans or expectations are forward-looking statements. These statements are based on current expectations and involve many risks and uncertainties that could cause actual results to differ materially from those expressed or implied in such statements. For more information on the factors that could cause actual results to differ materially, see our most recent earnings release and SEC filings at www.intc.com.