Starlink

WHAT ARE THE SECURITY MEASURES THAT CYSEC PROVIDES TO HELP YOU LEVERAGE PUBLIC CLOUD PROVIDERS' CONFIDENTIAL VIRTUAL MACHINE OFFERINGS?

Executive summary

Based on the Confidential Computing Consortium, Confidential Computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment (TEE). One of the typical usages of confidential computing is the isolation of a virtual machine (VM) from the host OS and the hypervisor. This isolation capacity is particularly appealing in the context of public clouds where many organizations would like to migrate their sensitive data but don’t do it because of confidentiality concerns. Several public clouds launched offerings of confidential VMs, i.e. VMs running in a confidential computing context. In this blog article, we will describe what are the security mechanisms that CYSEC provides to complement confidential VMs so that your data and your workloads are isolated from cloud service provider (CSP) administrators.

Are confidential VMs sufficient to isolate your containers from any cloud administrators?

The aim of confidential VMs is to isolate a VM from its hosting environment, i.e. the host OS and the hypervisor. In a previous blog article, we explained how CYSEC can help you to migrate your sensitive data to public clouds. In this previous article, we described two important aspects that need to be considered when you try to isolate your data and workloads from any CSP admins. Firstly, CSPs provide many managed services that are extremely valuable from an operational point of view but might give access to the admins of these services to your data. This is particularly true in the context of container orchestration with Kubernetes. The admins of Kubernetes control plan have the capacity to access any containers running in the Kubernetes cluster even if the nodes are executed in confidential VMs. Secondly, confidential VMs provide protection of your data while in-use, i.e. stored in volatile memories. This protection isolates your data from host OS and hypervisor administrators when your data is stored in RAM. However it doesn’t help for the security of your data located in the image of your instances. The present article will describe the complementary security mechanisms that CYSEC provides you to address the second aspects when you want to isolate from any CSP admins.

What security measures CYSEC provides on the top of Confidential Computing to help you to isolate your containers and their data from public cloud providers? 

Confidential Computing is the protection of data in use by performing computation in a hardware-based Trusted Execution Environment (TEE). This TEE can be used to isolate certain software  packages such as a VM, a process, a container or a library. This hardware-based TEE is offered by processor providers. Each processor provider has its own technology of TEE. CYSEC presently supports the  Secure Encrypted Virtualization (SEV) feature from AMD Epyc CPUs. AMD-SEV feature generates a hardware-based TEE to isolate a VM. This feature is based on a secure co-processor (embedded in AMD CPUs) in charge of keys and encryption before storing data in the RAM. A simplified view of the isolation mechanism provided by AMD-SEV is illustrated in Figure 1. This illustration shows that the live data of a guest is encrypted before being sent to the system memory (RAM). It also shows that the data stored in the cache memory of the CPU is unencrypted for being processed. One important security aspect that is not shown in Figure 1 is that the context of each VM executed on the same CPU is isolated from each other and from the host context in the cache memory.

As shown in Figure 1, the data of the VM image is in-clear when only the SEV feature is exploited. The first additional security measure provided by ARCA Trusted OS is a by-default full disk encryption (FDE) of the VM image. Figure 2 shows a simplistic illustration of the data protections offered by ARCA Trusted OS running as guest OS of a confidential VM. The FDE mechanism provided by-default by ARCA Trusted OS encrypts the guest data before storing it in a persistent storage. The FDE key is stored in the RAM (or system memory) when the instance is under execution. From the perspective of isolation with respect to CSP admins, the FDE key is isolated from host OS and hypervisor admins thanks to AMD-SEV. If there are no services running in the confidential VM that could give access to the data or the FDE key to any CSP admins, your workloads and data in an ARCA VM are cryptographically isolated from CSP admins.  

To reach the running state shown in Figure 2, we need to make sure that the ARCA Trusted OS has not been modified to disactivate some of its security measures. To prevent modifications of ARCA Trusted OS, ARCA comes with a by-default secure boot that verifies the authenticity and integrity of ARCA Trusted OS bootloaders, kernel and file system at each boot. This secure boot is performed with CYSEC secure boot (SB) key. A successful secure boot triggers the release of the FDE key from a virtual Trusted Platform Modules (v-TPM). After this key release, the ARCA instance runs with the data protection schemes shown in Figure 2. Note that in the CYSEC threat model, we make the assumption that the UEFI/OVMF firmware and the v-TPM provided by the CSP are trusted.

How does ARCA Trusted OS create the FDE key without it being known by the CSP admins?

We described previously how ARCA Trusted OS isolates the FDE key when the ARCA instance is at rest and when the instance is under execution. It remains the critical step of creating this FDE key in a manner that is protected from the CSP admins. To do so, ARCA Trusted OS creates this FDE key during the installation process in the cloud by placing the key directly inside the TPM.

The installation of ARCA within a public cloud environment is performed with an ARCA installer and follows these steps:

  • The authenticity and integrity of the ARCA installer is verified by a secure boot sequence relying on CYSEC Secure Boot keys.
  • If the secure boot has been successful, the ARCA installer generates a FDE key.
  • One copy of this FDE key is sealed within a v-TPM with the secure boot measurement results.
  • Then, the FDE key is used by the FDE mechanism while ARCA Trusted OS is installed as guest OS in the confidential VM.

Furthermore, ARCA trusted OS  provides a mechanism of key rotation to allow the end-user to change the FDE key on demand and another one of recovery key management if necessary.

How can you use or test ARCA trusted OS in public clouds?

ARCA Trusted OS can be deployed in confidential VMs running on AMD-SEV offered by Google cloud (see Google confidential VM offering here). This is the only confidential VM offering that is supported by CYSEC currently. We are investigating the deployment of confidential VMs on similar offerings from other CSPs.

CYSEC proposes free trials of ARCA trusted OS on Google clouds. These free trials are based on NRF (None For Resale) licences. Once you have signed a license, we provide you with an ARCA Trusted OS image and all the instructions to deploy it on Google clouds. To get a request for a free trial, you just have to fill the form on this webpage.

Benefit from the ultimate secure runtime technology with ARCA Trusted OS

Contact us