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.