Security

The security of VMs in the Leea Protocol relies on three core components:

1. Encrypted RAM using AMD SEV/Intel TDX

2. Remote Attestation process

3. Encrypted disk image

To explain why the Leea Protocol is fully secure, let's assume that a VM is launched on a malicious node, where all traffic is being sniffed, and every bit of RAM is continuously dumped.

Secure launch of user VM

RAM encryption

First, encrypted RAM is essential to securely launch a VM. We leverage AMD SEV and Intel TDX technologies, which operate similarly. The processor has a secure area called the Secure Processor (AMD-SP) that is inaccessible to anything but the CPU itself.

These technologies generate encryption keys, store them in the Secure Processor, and use them to encrypt the portion of RAM dedicated to the VM.

The VM is then launched with an initial RAM disk (initrd), which is intentionally unencrypted and does not contain any sensitive data. The initrd includes scripts necessary for connecting to a validator pool, which verifies VM integrity.

Even if the node is compromised, only the VM has access to its encrypted RAM, and no secrets are transmitted over the network.

Remote Attestation process

The Remote Attestation process ensures that only a specific VM running on a specific node can access the decryption keys. This process, though complex, can be explained simply:

The initrd connects to a pool of publicly available validators and randomly selects one.

The VM then collects hashes of various components, including:

• Disks

• Hardware

• Kernel and modules

• Drivers

• Configuration files

• BIOS version

• PCR banks on TPM

• Time information

• etc..

These hashes are sent to the selected validator, which has the information about the VM’s request and the node responsible for launching it. The validator compares the received hashes with its records.

If the hashes match, the Remote Attestation is successful, and the VM can proceed to obtain the disk decryption key.

For more detailed information on this process, refer to RFC 9334.

Note that no secret information is transmitted over an unsecured network. The connection between the validator and the VM is encrypted with TLS, and all transmitted information is publicly accessible.

Disk Encryption

When a user submits a VM order, the image registry prepares an encrypted disk. An encryption key is generated on the fly, split into parts using Shamir's secret sharing, and distributed across the validator pool, with each validator holding only one part.

Upon passing the Remote Attestation process, the VM is confirmed to be secure and running in a protected environment. A token is then obtained, and the VM’s script selects three validators from the pool, sending the token to retrieve parts of the decryption key.

The script then reassembles the decryption key, unlocks the encrypted disk, and the OS boots normally. Once the disk is open, it appears unencrypted within the secure VM, though it remains encrypted on the host.

While a secret is transmitted over the network, it is split into parts, encrypted with TLS, and stored only within the VM’s encrypted RAM.