CYSEC is a cybersecurity company aiming at providing solutions based on new and innovative technologies to its customers. One of these technologies is Confidential Computing that protects data in-use thanks to hardware-based TEEs. As an Operating System provider, CYSEC works on the TEE approaches that allow to protect the data in-use of a whole VM in which CYSEC Operating System, called ARCA Trusted OS, is the guest OS. Often, a VM executed in a Confidential Computing context is called a confidential VM. The main security purpose of confidential VMs is to add a cryptography-based isolation between a VM owner and all other stakeholders executing code on the same cloud infrastructure, including the Cloud Service Provider (CSP) itself.
In the case of confidential VMs, this isolation provided by the hardware (e.g. a CPU or a GPU) has to be exposed by the CSP hypervisor. If the VM owner threat model includes the CSP within the list of the threat actors, the VM owner cannot just trust that the CSP activates the TEE by default, it needs to be able to verify it. This is the reason why the processors offering Confidential Computing include the capacity to deliver attestation reports in general. When exposed by the CSP, these attestation reports can be requested by the VM itself. Furthermore, the processor manufacturer provides the capacity to verify the validity of this attestation report. By combining those two capacities, the VM owner has the ability to attest the TEE of its VM remotely. This mechanism is called a remote attestation mechanism.
CYSEC explored the attestation mechanisms offered by two different CPUs, AMD SEV-SNP and Intel TDX, early this year. Our objective is to allow the attestation from the CPU that a launched VM is executed in a Confidential Computing context and that ARCA Trusted OS is trustworthy. Finally, CYSEC defined a protocol between a VM and a verifier, relying on attestation mechanisms. This protocol, called attested VM launch protocol, has been designed with one main security objective: ensuring that an OS can boot if and only if it is trusted by a remote third party. In a nutshell, this protocol relies on the generation of encrypted VM images that can be unlocked after the verification by a third party. The encryption of the images is based on a Full Disk Encryption (FDE) mechanism managed at the OS level. The verification consists in the validation that the encrypted VM has been launched in a TEE and in checking the integrity of its OS.
The security claims of this attested VM launch protocol are the following ones:
- VM only starts if un-tampered code is running on expected CPU
- FDE keys are only sent if the VM is trusted
- FDE keys are only sent to the VM itself
- The VM may only start if authorized by the remote system
- The VM may start securely even if the host is untrustworthy
For more technical information about CYSEC attested VM launch protocol, you can find attached to this blog one chapter of an internal activity report describing the design of this protocol. Among the challenges that we identified during our investigations on this protocol, we faced the need to have a method for asserting the trustworthiness of an operating system in a VM before its complete remote start. Our solution to solve this problem is the topic of a patent application that we filed to the European Patent Office in August 2023..
CYSEC has been able to implement a first demonstration of its attested launch protocol on a preview in one Public Cloud. After this first successful feasibility demonstration, CYSEC is currently working on the industrialization of its protocol by developing a solution for private clouds based on AMD Epyc CPU. CYSEC plans to commercialize the solution in the first half of 2024. Moreover, the design of CYSEC attested launch protocol can be implemented with the Intel CPUs exposing the TDX feature as mentioned in the attached chapter. As a second development step, CYSEC will adapt its protocol implementation when this TDX feature will be available for private clouds.