search

canonical / tdx

Intel confidential computing - TDX
Other
55 stars 20 forks source link

Disk encryption #52

Closed CasellaJr closed 21 hours ago

CasellaJr commented 2 months ago

Hi everyone. Have someone experimented with disk encryption in a TDX guest? I have found this guide on the Intel TDX tools repository: disk encryption guide, but the repository is archived. Are there specific resources for doing disk encryption?

matti commented 2 months ago

is it possible to have guest disk encrypted and keep the host completely unaware of the key? no?

CasellaJr commented 2 months ago

I do not know. I have found on the Intel TDX tools github a reference to this repo: https://github.com/cc-api/full-disk-encryption But it contains the same info contained in the original repo of tdx-tools, which is no longer under activate management. I hope they will update that one.

hector-cao commented 1 month ago

@matti Hello, one of the architecture to protect the disk encryption key is to store it in the relying party and the key will be released through remote attestation, but that is just an idea, we do not plan yet to work on that, our priority is to release TDX for Ubuntu 24.04

matti commented 1 month ago

@hector-cao can you expand that a bit more? what does "store it in the relaying party" mean?

ruomengh commented 1 month ago

I do not know. I have found on the Intel TDX tools github a reference to this repo: https://github.com/cc-api/full-disk-encryption But it contains the same info contained in the original repo of tdx-tools, which is no longer under activate management. I hope they will update that one.

It's a reference of TDX full disk encryption with remote attestation. The secret will be retrieved by KBS if remote attestation is successful. The reference skips the KBS part so that users can implement it with their own KBS, e.g. https://github.com/intel/trustauthority-kbs. See more details in https://github.com/cc-api/full-disk-encryption/blob/3c4325c7a6b4d2fe76aa0b873920bf981c46db41/src/key_broker.rs#L20

hector-cao commented 1 month ago

@matti The key that will be used to decrypt the disk can be stored in a remote entity, one of the scenario is to have this key stored in the third/relaying party. Do you see what is the role of the relaying party in the attestation big picture ?

matti commented 3 weeks ago

@hector-cao no I don't. the disk needs to be decrypted for the VM to be able to boot?

Or, are we talking about having the boot disk unencrypted, then doing something inside of the VM and decrypting an additional disk (not the boot disk)

syncronize-issues-to-jira[bot] commented 3 weeks ago

Thank you for reporting us your feedback!

The internal ticket has been created: https://warthogs.atlassian.net/browse/PEK-659.

This message was autogenerated

hector-cao commented 1 week ago

@matti Basically we will have the rootfs encrypted and the initrd will contain the necessary bits to do attestation and retrieve the key from the KBS (Key Broker Service) for the rootfs decryption