No encrypted storage for the TDX guest

[ameba23]

The memory used by a TDX enclave is encrypted using key derived from a hardware key which is inaccessible to the host. I had hoped / expected that the storage volume used by the enclave would also be encrypted in a similar way.

When setting up a TDX guest using qemu as described in the ubuntu tdx tutorial, i can see that the storage volume file (with .qcow2 extension) is not encrypted.

i know what with SGX there is a feature called 'sealing' which allows you to encrypt / decrypt values using the hardware key in order to have them persist outside of the enclave. But i can't find anything about whether this feature is available for tdx.

qemu-img does have a built in encryption feature, but there is a note in the man page saying The use of encryption in qcow and qcow2 images is considered to be flawed by modern cryptography standards and suggesting alternatives such as the Linux dm-crypt / LUKS system.

Regardless of which software we use, there is a chicken and egg problem with where to store the encryption keys as they cannot be stored on the host.

We need disk encryption for 2 reasons:

1. entropy-tss stores keyshares as well as secret keys used for authenticaion on disk, and these need to be inaccessible to the host operator. A workaround would be that we just don't store keyshares or secret keys on disk (and make sure to not use swapfiles). There is a proposal for that here. But this would mean that this secret data would not survive a server reset and would mean we need some quite big changes to our overall design to accommodate that.
2. Using authenticated encryption would give integrity protection meaning the host cannot modify the binaries or other files from the guest image. Without this, it is possible that the host stops the VM from running, modifies the code, then restarts it. Since an attestation has already been made, and we have no way of knowing that this has happened, we will continue to assume this node is trustworthy until the next attestation check is made. Our current design of the attestation feature assumes that we do not continuously need to do attestation checks.

Some related links to projects:

• https://github.com/cc-api/full-disk-encryption - it is specifically for TDX but looks like it relies on some external key broker service.
• Intel's 'confidential computing zoo' has some scripts / tutorials which might be helpful with getting storage encryption. Eg: Attested Boot with encrypted Intel TDVM OS Image. The stuff showing how to setup LUKS encrpytion with a .qcow2 image is useful. But it looks to me like this is still geared towards retrieving the encryption key from a centralized service, rather than using the hardware key.

[ameba23]

It appears the only way to have access to the hardware key for encryption is through the SGX sealing API. Since we cannot run binaries compiled for the SGX target on a TDX VM, we need to use gramine (or something similar).

Heres what dstack uses:

https://github.com/kvinwang/gramine-sealing-key-provider

and here is the PR which incorporates it:

Dstack-TEE/dstack#81

[ameba23]

I am having difficultly using the gramine-sealing-key-provider because of an error relating the the DCAP setup, but i am able to retrieve sealing keys using gramine by starting with their rust example template and reading the key from gramine's filesystem interface in the same way the sealing provider does:
https://github.com/MoeMahhouk/gramine-sealing-key-provider/blob/254900e3be65d4aff83e0d68abbf0a6deb54da74/src/gramine/interface.rs#L7

Some things to bear in mind:

• This key is unique to the enclave - we can only retrieve it again from this enclave (but it will persist if the enclave is restarted).
• Since this service needs to run on the host, it wont be possible if we use a cloud provider for TDX VMs. gramine-sealing-key-provider requires that the sgx enclave and TDX VM giving the quote are on the same machine. But maybe we could do something similar which allows for remote key providing (even though the whole reason we are doing this is to avoid a centralized key provider).