docs(threat-model): A1 grouped TPM sealing with TEE memory encryption - #583
Merged
Conversation
The A1 bullet read "Cannot read TEE-encrypted memory (SEV-SNP, TDX) or TPM-sealed secrets", grouping two different guarantees against an adversary the same entry already grants root on the host. SEV-SNP and TDX encrypt guest memory while the VM runs, so root on the host cannot reach policy evaluation or audit construction. TPM sealing binds a secret to PCR values at unseal time: a boot-time and at-rest guarantee that says nothing about a running process. On bare-metal TPM an operator with root can read or modify the gateway's memory while it runs, including flipping a Cedar decision, and the TPM does not detect it. So the tpm tier defends against a tampered boot, not a live privileged insider, and the threat model claimed otherwise. Distinct from #453, which is the missing AK certificate chain, and from the Azure vTPM-behind-SEV-SNP case LIMITATIONS.md documents separately. Reported by @kingztech2019 in #581. Signed-off-by: Imran Siddique <imran.siddique@opaque.co>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #581, reported by @kingztech2019.
The claim that was wrong
docs/spec/threat-model.md:22, adversary A1:Two lines above, the same entry grants A1 root on the host. So this bullet is the load-bearing one: it says what root cannot reach.
It groups two different guarantees:
On bare-metal TPM, an operator with root can reach into the running gateway and flip a Cedar DENY to an ALLOW, and the TPM will not detect it, because detecting that is not what a TPM does. The threat model said otherwise.
What changed
A1's third bullet is split so each tier states its own guarantee, and the
tpmtier's boundary is explicit: it defends against a tampered boot, not against a live privileged insider.No change to the SEV-SNP or TDX position, which was accurate.
Scope
This is distinct from two things already recorded elsewhere:
LIMITATIONS.md. There the vTPM sits on top of a memory-encrypting TEE, so the SEV-SNP line applies. This change is about bare-metal TPM, and @kingztech2019 scoped it that way in the report.Why it is worth a change rather than a note
A threat model is the document a deployer reads to decide which tier they need. Someone choosing the
tpmtier because A1 "cannot read TPM-sealed secrets" would have concluded that a rogue operator cannot subvert their policy decisions, and that conclusion does not hold. Overstating a hardware guarantee in the document whose job is to bound it is the failure mode this project exists to avoid.