CYSEC has extended the capabilities of its infrastructure security solution by developing a remote attestation mechanism that you operate to increase your control on the security of your VMs while deployed in a third-party hosted private cloud. These new capabilities form the CYSEC Remote Control feature that is designed to attest the isolation of your VMs at launch time with respect to the host of the private cloud.
CYSEC provides an infrastructure security solution that protects the data of VMs in all states (at rest, in transit and in-use) for about two years. This solution relies on CYSEC’s hardened Operating System (OS) called ARCA Trusted OS. ARCA Trusted OS comes with by-default security mechanisms protecting the confidentiality of data and the integrity and authenticity of the system code. This solution provides an isolation between the VM owner data and the cloud administrators (for more details see this link)
What is the evolution of CYSEC’s VM isolation solution?
The protection of data in-use is offered by the deployment of CYSEC’s OS in so-called confidential VMs (i.e. VMs that are executed within a Confidential Computing (CC) context, e.g. AMD SEV or Intel TDX). However, the request of the activation of the CC context made by the user during the VM configuration is not suffisant in the cases where the VM owner has to consider the cloud host as untrustworthy. Indeed, in these cases the VM owner has to be able to verify that its configuration has been applied correctly by the cloud host. CC technologies offer this capability via attestation reports generated by the processing unit. CYSEC has enhanced the capabilities of its infrastructure security solution offering by developing a so-called remote attestation mechanism combined with some control capacities. This remote attestation mechanism is operated by the VM owner and allows it to verify the proper setup of the CC context and the integrity of its system during the launch of its VM. The control capacities allow the VM owner to complete the launch of the VM or to abort it depending on the verification results. This new feature of CYSEC solution gives the VM owner a better control of the security-related operations performed by the cloud host. CYSEC calls this new feature Remote Control.
What is the architecture to run the CYSEC Remote Control feature?
The remote attestation mechanism developed by CYSEC relies on a local agent in the VM and a piece of software running in the premises of the VM owner. The agent is called ARCA Verification Agent and is located in ARCA Trusted OS. The piece of software running on premise is called ARCA Verification Manager. ARCA Verification Agent has the ability to request for attestation reports to the CPU, to receive them and forward them through a secure communication channel towards ARCA Verification Manager. ARCA Verification Manager has the ability to verify attestation reports generated by the CPU, to evaluate the validity of the content of these reports based on user-defined security policies and to allow or not the completion of the VM launch. Figure 1 shows how ARCA Trusted OS, ARCA Verification Agent and ARCA Verification Manager are distributed between the cloud and on premise environments. The gray arrows illustrate the interactions between the main entities acting when Remote Control is used. As can be seen in Figure 1, in addition to CYSEC three pieces of software the CPU provider database is part of the solution. Moreover, we can see that the ARCA Verification Manager embeds a storage for encryption keys. These keys are used by a protocol designed by CYSEC and called attested launch protocol.
Figure 1: Architecture to run CYSEC Remote Control feature
What is the attested launch protocol?
As mentioned above, the main function of Remote Control is to allow the VM owner to enforce the integrity and authenticity of its OS and VM configuration at the launch of this VM. This means that when the VM owner launches its VM, it wants either to be sure of (1) the VM CC context, (2) the integrity of the OVMF, (3) the integrity of its OS and (4) the authenticity of its VM, or to abort the VM launch process before deploying any sensitive data. The goal is to obtain this assurance based on the assumption of an untrusted cloud hosting environment. Other functions allowed by the CYSEC Remote Control feature are not presented in this blog.
The principles of this protocol are illustrated in Figure 2. This protocol starts during the secure boot process of ARCA Trusted OS when the initramfs runs. Up to this step, all launched ARCA Trusted OS code pieces are in clear. The remaining partitions to launch are encrypted. The attested launch protocol is run before the decryption of these partitions.
Figure 2: Illustration of the attested launch protocol
The attested launch protocol consists of three challenge-response steps. First, the ARCA Verification Agent initiates a TLS1.3 communication channel with the ARCA Verification Manager. As the agent is not encrypted, it can not embed any secrets. Therefore, this channel is unidirectionally authenticated. The agent can authenticate the manager. The manager can just verify that the agent id exists in its database. The second step starts with the ARCA Verification Manager sending a nonce to the ARCA Verification Agent. This nonce is used by the agent to request a fresh attestation report that is forwarded to the manager. After verification and analysis of this report, the manager knows if it is communicating with a trustworthy and identified ARCA Trusted OS within a valid CC context or not. Note that the configuration of the agent is attested during this step to prevent from man-in-the-middle attacks. If all the conditions are valid, the last step consists in the distribution of the key associated with the VM id to the ARCA Verification Agent. This agent attempts to decrypt the encrypted disk with this key. If the disk decryption works, then the verifier knows that it is communicating with the authentic ARCA Trusted OS instance. Otherwise, the agent is in charge of aborting the launch process after having properly withdrawn the received key.
Where can you run the CYSEC Remote Control feature today and later?
The present development of CYSEC Remote Control feature has been performed in the context of hosted private clouds. This protocol has been demonstrated on Qemu/KVM and a patched version of Proxmox (only Qemu has been patched). The servers are based on 4th generation AMD Epyc CPUs. The ARCA Verification Manager is a software package composed of containers that are deployed on ARCA Trusted OS using Docker-compose. In this environment, CYSEC attested launch protocol relies (1) the attestation mechanism provided by the SEV-SNP feature from AMD Epyc, (2) an OVMF customized by CYSEC so that CYSEC secure boot keys are attested by the CPU and cannot be by-passed by the hypervisor, and (3) fields that are attested by the CPU and cannot be modified once the VM has been launched. This custom OVMF is needed to bootstrap ARCA Trusted OS chain of trust to the measurements attested by the CPU. The immutable and attestable fields are used for the identification of the VM and for the verification of the integrity of the agent configuration.
The future plans for private clouds are to adapt this protocol to VMware vSphere when it will be compatible with AMD SEV-SNP in 2025. Concerning the public clouds, the implementation of the protocol on Azure is in progress. The remote attestation features provided by Azure being different from the one accessible with Qemu/KVM, CYSEC chain of trust will be modified however the security claims of the protocol will still be valid.
If you are interested in knowing more about the CYSEC Remote Control feature, please contact us at sales@cysec.com.
