Confidential Computing with SCONE

Confidential computing focuses on the protection of applications. We require that confidential computing protects an application's

• confidentiality, i.e., no other entity, like a root user, can read the data, the code, or the secrets of the application in memory, on disk or on the network,
• integrity, i.e., no other entity, like the hypervisor, can modify the data, or at least any modifications are detected in the memory, on disk or the network, and
• consistency, i.e., the application reads always the value that was written last - both in memory as well as on disk and the network.

Modern cloud-native applications consist of multiple services that communicate via the network with each other and with external clients. These services are deployed with the help of containers. In this section, we focus on confidential, cloud-native applications.

Hardware Support

Currently, there are two classes of hardware support for confidential computing available. The current mechanisms can be classified as follows:

• one can encrypt the VM (Virtual Machine) in which the application is executing, and
• one can encrypt each individual service inside of an enclave - with the help of SCONE.

One has to be careful regarding the security guarantees because the use of encrypted VMs does not necessarily mean that a root user of the host does not have access to the VM. In current AMD CPUs without Secure Nested Pages (SNP), the hypervisor could break the confidentiality and integrity of an application. In our discussion, we assume that we already are able to use SNPs.

Note that the consistency of memory pages is not protected by AMD CPUs, i.e., one could replace a memory page with an older version: this would be properly encrypted but would break the consistency. In Intel SGX enclaves, it is guaranteed that an application always reads the most recent data that was written.

Encrypted VMs

When running cloud-native applications, multiple stakeholders are involved. This includes:

• a host admin that maintains the host OS (operating system)
• a Kubernetes admin that maintains Kubernetes, say, we have a managed Kubernetes service, and
• a container/service admin that takes care of the services and the containers.

In the context of cloud-native applications, an encrypted VM would be used to represent a Kubernetes node. The trusted computing base would not only include the application but we would also need to trust:

• the operating system and the OS admin,
• Kubernetes and the Kubernetes admin,
• the container/service admin.

One could try to execute each container in a separate encrypted VM. This would reduce the size of the trusted computing base (TCB) since the Kubernetes admin could - if one does this correctly - be not part of the trusted computing base anymore. Still, the container/service admin, the operating system in the VM and its OS admin would still be part of the TCB.

Enclaves

Enclaves permit to reduce the size of the trusted computing base to the application itself: we can remove all admins and all code outside of the application from the trusted computing base. Note that SCONE will help to protect the files of an application and also the network if needed, i.e., a service admin will only see encrypted files and will not know any application secrets.

Isolation and Cooperation

The advantage of enclaves together with SCONE is that one can protect services from each other. A service has only access to its own enclave and to its files but not to the data/files of other enclaves.

Using encrypted VMs, one would need to run each service in a separate VM with its own operating system - which increases the TCB as we explained above. This also increases the resource usage since each container would come with its own operating system.

With the help of SCONE, services of an application can cooperate and implicitly attest each other via TLS: a service can only establish a TLS connection with another service of the application if that service executes inside of an enclave, its code was not modified and the filesystem is in the correct state.

Simplicity

One of the arguments for using encrypted VMs (instead of enclaves) is that it simplifies the protection of existing applications. In reality, this is of course not that simple since one

• has to encrypt files of the VM,
• one has to ensure that the VM learns the filesystem encryption key but only if neither the operating system nor the application was not modified and it is executed in an encrypted VM,
• one has to ensure that the service in the different VMs do attest each other, and
• one has to provision secrets etc

With the help of SCONE, one can transform an existing container image into a confidential container image in a single step (see sconify images). SCONE provides a policy language that permits to define how to provision secrets and how to attest applications, i.e., address all these issues using a simple, Yaml-based policy language.

We argue that the use of enclaves is with the help of SCONE not only more secure than encrypted VMs but also more convenient since the transformation is automated and the policy support allows both cooperation between services as well as isolation without the need to change the services.