From 01319faa788d6db04d98a7939b9868fd1ab3aa5a Mon Sep 17 00:00:00 2001 From: Tyler Fanelli Date: Fri, 31 May 2024 21:27:37 -0400 Subject: [PATCH] Add proposal for TEE Boot Attestation Signed-off-by: Tyler Fanelli --- 107-tee-boot-attestation.md | 509 ++++++++++++++++++++++++++++++++++++ 1 file changed, 509 insertions(+) create mode 100644 107-tee-boot-attestation.md diff --git a/107-tee-boot-attestation.md b/107-tee-boot-attestation.md new file mode 100644 index 0000000..b3c3a4e --- /dev/null +++ b/107-tee-boot-attestation.md @@ -0,0 +1,509 @@ + +# enhancement-107: TEE Boot Attestation + + + + + + +- [Release Signoff Checklist](#release-signoff-checklist) +- [Summary](#summary) +- [Motivation](#motivation) + - [Goals](#goals) + - [Non-Goals](#non-goals) +- [Proposal](#proposal) + - [User Stories (optional)](#user-stories-optional) + - [Story 1](#story-1) + - [Story 2](#story-2) + - [Notes/Constraints/Caveats (optional)](#notesconstraintscaveats-optional) + - [Risks and Mitigations](#risks-and-mitigations) +- [Design Details](#design-details) + - [Test Plan](#test-plan) + - [Upgrade / Downgrade Strategy](#upgrade--downgrade-strategy) +- [Drawbacks](#drawbacks) +- [Alternatives](#alternatives) +- [Infrastructure Needed (optional)](#infrastructure-needed-optional) + + +## Release Signoff Checklist + + + +- [ ] Enhancement issue in release milestone, which links to pull request in [keylime/enhancements] +- [ ] Core members have approved the issue with the label `implementable` +- [ ] Design details are appropriately documented +- [ ] Test plan is in place +- [ ] User-facing documentation has been created in [keylime/keylime-docs] + + + +## Summary + + + +Trusted Execution Environments (TEEs) are a confidential computing and +virtualization technology that allow for the protection/encryption of guest VM +RAM, cache memory, and CPU registers for running sensitive applications on +potentially untrusted hosts within the cloud/edge. With TEEs, data written to +RAM, caches, or registers are encrypted with keys maintained by secure +processors embedded within a CPU, thus protecting confidential VM guests from +other guests on a host, or even the host system itself. With encryption fully +managed by the hardware, only the confidential VM (CVM) itself would be able to +read/write to its own memory, protecting against buggy/malicious hosts spying +on or tampering with the CVM. + +TEEs are for protecting applications/users on untrusted platforms. In-fact, the +confidential computing threat model assumes that the host in which a CVM is +running on top of is actively attempting to tamper or spy on guest memory. With +this, users must *ensure* that a host has launched their guest with all proper +TEE protections and didn't perform any other nefarious actions to tamper with +a CVM. That is, CVMs must *attest* their boot environment and prove the +*integrity* of their workload before any sensitive operations can be performed +within a CVM. + +This enhancement will introduce the notion of workloads using TEE secure +processors as their root-of-trust, rather than vTPM devices. With this, initial +vTPM state will be derived from successful TEE attestation reports, and certain +vTPM PCRs will be extended to reflect successful TEE attestation. + +## Motivation + + + +As CVMs are deployed on untrusted systems, it is reasonable to assume that a +CVM user would also like to take advantage of system integrity monitoring +provided by Keylime *in addition to* TEE technology. That is, it is reasonable +to expect that Keylime agents will be deployed on CVMs. With that, TEE +attestation support for environments in which Keylime will already be running +for system integrity monitoring purposes will likely be desired. + +### Goals + + + * Extend Keylime Registrar to perform TEE attestation to bootstrap an agent's + initial vTPM state. + * On CVMs, extend vTPM measurements to account for TEE boot attestation within + Keylime. + * Fully support confidential computing systems' need for boot *and* runtime + attestation within Keylime. + +### Non-Goals + + + * TODO + +## Proposal + + + +### User Stories (optional) + + + +With TEE secure processors acting as the ultimate root-of-trust, much of the +registration and attestation process's behavior should be identical to that as +if vTPM devices were the root of trust. However, some registration steps will be +handled before the a Keylime agent is initialized. + +It is critical to establish trust in a CVM as early as possible. As such, +typical CVMs encrypt their root disks, and require a key stored on an +attestation server to unlock the root disk and begin running any operating +systems or applications on the CVM. To get this key from the server, a CVM would +have to fetch its TEE evidence from the secure processor and send it as input to +the server. If the server is able to validate the TEE evidence, it will then +release the key. At this point, CVMs could decrypt their root disks and begin +running their OS and applications trusting that they are in-fact running +confidentially. + +[SVSM](https://github.com/coconut-svsm/svsm) is a paravisor that is the first +thing to run in a confidential VM. It can provide trusted services to the guest +that are protected from both the host OS, and from the guest firmware & OS. +Under AMD SEV-SNP, SVSM will run at VMPL-0, while the guest firmware & OS will +run at VMPL-3. One of the services SVSM can provide is a virtual TPM (vTPM). By +performing a TEE attestation, SVSM can establish trust in the confidential +hardware environment and link the CVM attestation report to the virtual TPM +identity, enabling the guest OS to then trust the vTPM. + +A vTPM will be provided by the paravisor (SVSM) to ensure the integrity of +software running on a CVM (i.e. runtime attestation of CVMs). The intention is +to enable support for encrypted disks, whose keys are sealed using a key derived +from the vTPM. + +A vTPM may either be ephemeral in which case it is effectively re-manufactured +on every boot (fresh primary seeds & empty NVRAM), or persistent, in which case +it has state (primary seeds & NVRAM) maintained across (re)boots. + +With a stateful vTPM, the CVM paravisor initially has access to some storage +that contains the encrypted vTPM state. The keys needed to unlock this state +should only be released to the paravisor once the attestation server (keylime) +has successfully validated the CVM hardware attestation report. Once the vTPM +state is unlocked, the guest firmware can be launched, and in turn the guest OS +can launch and unseal its root disk using the vTPM. + +#### Story 1 + +The use-case of this can be broken up into two main phases, being pre-boot TEE +attestation and post-boot vTPM attestation. + +Pre-boot TEE attestation is performed from SVSM to unlock the CVM's root disk +and establish initial vTPM state for the machine. + +Post-boot vTPM registration is performed by the Keylime agent and no functional +changes are required. However, the agent enrollment policy will need to account +for TEE attestation (as will be explained). + +Pre-boot Attestation +-------------------- + +1. Pre-boot VM Provisioning + +As mentioned before, CVM root disks are encrypted, with decryption reliant upon +successful TEE attestation. In the VM provisioning phase, a user provisions an +encrypted VM image sealed with initial vTPM state, which is in-turn encrypted +with a key stored within Keylime. This step involves a new Keylime Registrar +endpoint to fetch the public components of its "TEE Attestation Key" to then +encrypt the initial vTPM state. + +- User creates an encrypted disk image instance from a plain text image + template. +- User creates initial vTPM state for the CVM. +- User seals encrypted disk image key using a key derived from the vTPM. +- User creates "vTPM State Key", encrypts vTPM state with vTPM State Key. +- User makes POST request to new Keylime Registrar endpoint to fetch TEE + Attestation Key. Keylime Registrar replies with public key. +- User encrypts initial vTPM State Key with public TEE Attestation Key. +- User stores vTPM state (encrypted with vTPM State Key) and vTPM State Key + (encrypted with TEE Attestation Key) along with encrypted root disk. + +A diagram showing the VM provisioning process: +``` + ┌────────────────┐ + │ │ + │ ┌────────────┐ │ + │ │VM rootfs │ │ + │ │Sealed w/ │ │ +┌──────┐ │ │key derived │ │ +│ VM │ ┌──────────────┐ │ │from vTPM │ │ +│ Disk ├───►│ Provisioning ├─────────►│ └────────────┘ │ +│ Image│ │ Tool │ │ │ +└──────┘ └───┬─────▲────┘ │ ┌────────────┐ │ + │ │ │ │vTPM State │ │ + GET │ │ TEE │ │encrypted │ │ + TEE │ │Attestation │ │w/ vTPM │ │ + Attestation│ │Public Key │ │State Key │ │ + Public Key │ │ │ └────────────┘ │ + ┌─▼─────┴─┐ │ │ + │ Keylime │ │ ┌────────────┐ │ + │Registrar│ │ │vTPM State │ │ + └─────────┘ │ │Key │ │ + │ │encrypted │ │ + │ │w/ TEE │ │ + │ │Attestation │ │ + │ │Key │ │ + │ └────────────┘ │ + │ Encrypted │ + │ Image │ + └────────────────┘ +``` +2. Pre-boot VM TEE Attestation + +With the image created and the CVM now running, SVSM is able to attest the CVM's +TEE evidence, unlock its initial vTPM state, and decrypt its root disk. +This step involves another new Registrar webhook to perform attestation on the +TEE evidence. + +- Since SVSM relies on the untrusted host for networking, all incoming secrets + sent upon a successful attestation must be encrypted with a key that only the + CVM controls. Therefore, SVSM generates a "CVM Integrity Key" that Keylime + must use to encrypt all secrets sent back to SVSM. +- SVSM hashes Agent UUID, CVM Integrity public key, and ID_BLOCK (or TDX/CCA/etc + equivalent) and requests an attestation report with this hash as REPORT_DATA. + This ensures freshness and integrity of attestation report. +- SVSM POSTs UUID, CVM Integrity public key, attestation report, and encrypted + vTPM State Key to the Keylime Registrar. + +A diagram of these steps: +``` + 3. Fetch + Attestation + Report ┌────────────────────────┐ + ┌────────────┤ SVSM │ + │ ├────────────────────────┤ + │ │ 1. Generate CVM │ 5. Registrar POST + │ │ Integrity Key │ ┌────────────┐ + │ │ Pair │ │ Agent │ + │ │ │ │ UUID │ +┌────▼────┐ │ 2. Hash │ ├────────────┤ +│TEE │ │ │ │ Attestation│ +│Secure │ │ Agent UUID │ │ Report │ ┌─────────┐ +│Processor│ │ + ├───►├────────────┼──►│Registrar│ +└────┬────┘ │ CVM Integrity │ │ CVM │ └─────────┘ + │ │ public Key │ │ Integrity │ + │ │ + │ │ public Key │ + │ │ CHIP_ID │ ├────────────┤ + │ │ (or TDX/CCA/etc │ │ Encrypted │ + │ │ equivalent) │ │ vTPM State │ + │ │ │ │ Key │ + │ │ Into REPORT_DATA │ └────────────┘ + │ └────────────────────────┘ + │ ▲ + └──────────────────────────┘ + 4. Attestation Report +``` + +- Registrar will attest the report (with TEE certificates) and report a + pass/fail. + +UPON SUCCESSFUL ATTESTATION +- Registrar will decrypt the vTPM State Key that was previously encrypted + with its TEE Attestation Key. +- As mentioned before, SVSM provides a CVM Integrity Key to prevent the + untrusted host from spying on decrypted secrets. The vTPM State Key is + encrypted with this key and sent back to SVSM to decrypt. + +``` + 3. Decrypt 4. Encrypt + vTPM State vTPM State Key + ┌──► Key w/ TEE ──► w/ + │ Attestation CVM Integrity + │ Key Key + ┌────┴────┐ │ + │Registrar│ │ + └─┬─────▲─┘ │ + │ │ │ +1. Attestation │ │2. Pass/Fail │ + Report │ │ │ ┌────┐ + + │ │ └───►│SVSM│ + Certificates│ │ └────┘ + │ │ + ┌──▼─────┴──┐ + │TEE │ + │Attestation│ + │Verifier │ + └───────────┘ +``` + +- As this is the "first phase" of registration, the Registrar will store the + UUID in its database: + +``` +┌─────────┐ Agent UUID ┌───────────┐ +│Registrar├────────────►│ Registrar │ +└─────────┘ │ DB │ + └───────────┘ +``` + +- SVSM will decrypt its vTPM State Key with its private CVM Integrity Key. +- SVSM will decrypt vTPM state with vTPM State Key. +- SVSM will derive key from vTPM state and use to unlock rootfs. +- SVSM will begin running OS under decrypted vTPM. + +Post-boot Attestation +--------------------- + +With the CVM's OS booted and Keylime agent started, no functional changes are +requried by the agent. The agent has a view of the vTPM and will begin the +Keylime registration/activation/enrollment/runtime attestation phases as normal. + +However, recall that upon a successful pre-boot TEE attestation, the initial +vTPM state will be extended (via a PCR) to show proof of successful pre-boot TEE +attestation. The agent enrollment policy must account for this PCR extension and +check for it during the enrollment phase to ensure that the agent's pre-boot +environment was attested. + +Agent must register with the same UUID as SVSM used in pre-boot registration. +Registrar will check to ensure that the UUID exists and that its TEE environment +has been successfully attested. + +### Notes/Constraints/Caveats (optional) + + + * TODO + +### Risks and Mitigations + + + +Keylime will store a TEE Attestation Key used to encrypt initial vTPM state for +all encrypted guests attesting with the server. If this key is leaked, all of +the images could potentially be decrypted and secrets can be leaked. + +## Design Details + + + + +### Test Plan + + + + * New tests will need to be written specifically for TEE boot attestation + extension scenarios. + +### Upgrade / Downgrade Strategy + + + +TODO + +### Dependency requirements + + +No additional dependencies should be required. + +## Drawbacks + + +No drawbacks are known of. + +## Alternatives + + + * There are other TEE attestation servers released now, such as the [trustee] + service. However, using trustee would require Keylime and trustee to work + in-tandem and communicate with each other. It would also require two separate + servers to be run for attesting one confidential VM (trustee for boot + attestation, and Keylime for runtime attestation and integrity monitoring). + Keylime already offers the sufficient runtime services needed for integrity + monitoring, so it is reasonable for it to include extensions for boot + attestation rather than require another solution to be deployed alongside it. + This would also make Keylime a one-stop solution for running sensitive CVM + workloads on the cloud or edge. + +## Infrastructure Needed (optional) + + +No infrastructure changes needed. + +[SVSM]: https://github.com/coconut-svsm/svsm/blob/main/README.md +[trustee]: https://github.com/confidential-containers/trustee/blob/main/README.md