The relationship between zero trust and confidential computing

What is zero trust?

First of all, what actually is zero trust? I have to admit that despite having spent 15+ years in the cybersecurity, I didn’t really have a clear understanding of the term for quite a while. So let’s dig into it…

Probably the most authoritative source on the matter is NIST Special Publication 800–207 titled “Zero Trust Architecture.” According to it, zero trust is all about identity and access to resources in an enterprise network. No entity should be trusted just because it is part of a certain network or it is in a certain physical location. In essence, zero trust is about assuming breach of the enterprise network.

Correspondingly, NIST lists encryption of all network traffic and session-based access control for resources on the network among the “basic tenets” of zero trust. This is in contrast with traditional security models where everything inside the enterprise network is trusted and everything outside isn’t. In such a model, attackers get access to all resources on the enterprise network once they broke into it, i.e., they circumvented the firewall.

Half-seriously, one can possibly reduce this to: “Zero trust means treating your enterprise network as if it was a McDonald’s WiFi.”

Adding confidential computing

Now, let’s see how confidential computing fits into the picture. Abstractly, confidential computing brings two key features to the table:

• Runtime encryption and isolation for workloads
• Fine-grained remote attestation for workloads
  If you’re new to confidential computing and are unsure what the above means, check out our corresponding whitepaper for an introduction.

Runtime encryption extends zero trust to the compute infrastructure

Let’s examine runtime encryption and isolation first. It’s an orthogonal addition to the network encryption that a zero-trust architecture mandates. It lets us extend the traditional network-centric focus of zero trust to the compute infrastructure and assume widespread breach there as well. This is possible because, if implemented correctly, confidential computing can shield workloads and their data from compromised host operating systems, hypervisors, hardware components, etc. For example, if your database is correctly protected with confidential computing, say in a secure enclave, data security would remain intact even in the face of a Kernel-level or admin-level breach of the underlying operating system. Without confidential computing and with only traditional zero trust measures this clearly wouldn’t be the case.

In essence, with confidential computing-based runtime encryption and isolation, we can rewrite the metaphor from above to: “Treat your network as if it was a McDonald’s WiFi and your compute infrastructure as if it was running on unpatched Windows 98.”

This is how the AI (Midjourney) imagines enterprise IT infrastructure based on McDonald’s WiFi and unpatched Windows 98 — all good as long zero trust with confidential computing is applied throughout:

For completeness, note that runtime encryption and isolation don't work without remote attestation. Without the latter, a compromised compute infrastructure could just pretend to be "runtime encrypted" and modify workloads and access data at will. Thus, if we assume breach of the compute infrastructure and use confidential computing as a countermeasure, we always also have to verify the integrity of entities on the enterprise network based on remote attestation.

Remote attestation takes "don't trust, verify" to the next level

Ok, let's drill deeper on confidential computing-style remote attestation and what it brings to zero trust.

As outlined above, zero trust is all about the verification of identities of subjects on a network and corresponding session-based and resource-based access control. Without hardware-based remote attestation, access control can only rely on cryptographic keys held by the subjects (e.g., apps, services, or end-user devices) and unverifiable reports about patch levels etc. Once, for example, the private key of a service is breached, an attacker can perfectly impersonate that service.

With confidential computing-style remote attestation, the picture changes. It lets software prove their precise identity and integrity to a verifier for access control. More specifically, the verifier unambiguously learns the cryptographic hash of the software, the confidential-computing features it is protected with (e.g., runtime encryption), and its public key. An attacker aiming to fabricate this information would need to break the remote-attestation protocol of the employed confidential-computing technology, e.g., Intel SGX or AMD SEV. This is not impossible but far out of reach for most attackers.

Given this, it is probably fair to say that confidential computing-style remote attestation fundamentally improves the verification aspect of zero trust. With it, we can go from mostly certificate based identities (which can easily be stolen) to dynamically attested semantics-based identities and more.

Wrapping it up

The quick summary is: Zero trust and confidential computing are a great fit. Confidential computing takes zero trust to the next level in two dimensions: First, runtime encryption can extend traditional zero trust from the network to the compute infrastructure. This is a foundational improvement that, as far as I am aware, hasn't been discussed much so far. Second, remote attestation vastly extends the reliability and capabilities of access control in a network, which is at the core of zero trust.

If you're interested in seeing what confidential computing-powered zero trust looks like in practice, I recommend you check out our "confidential Kubernetes" Constellation. Constellation provides Kubernetes clusters that are shielded as a whole from the infrastructure and where each worker node is verified deeply using remote attestation.

Until next time ✌️

Author: Felix Schuster