To give an idea of the kinds of things you can do now:
- Keys or other secrets can only be decrypted (via KMS) by an EC2 instance if it is running an approved AMI.
- You could build a certificate authority (CA) which only issues a certificate to an instance running an approved AMI.
Lateral movement of attackers. Shadow IT. People modifying things between test and Prod.
All easy examples that don't require you to trust AWS hasn't backdoored it to still get better security.
That was a hard bridge for me to cross for a long time; I got there via sustained in-depth conversations with folks there who simply wouldn't stand for something that breathtakingly opposed to everything AWS has strived to achieve from a trust perspective, that they'd sooner tear it all down than implement such a thing.
Some folks can't get there, and that's okay; if you don't have that level of trust, perhaps the cloud is not a fit for all of your workloads.
Once you've got that, it's the usual TPM dance: each phase of the boot process verifies the next step and "ratchets" the TPM forward. The final OS uses the TPM's attestation to prove the TPM is genuine and not emulated, and the TPM's final state is used to prove it's running a genuine image booted through the proper process.
AMD had a whole bunch of SEV extensions for stuff like this. I reckon Intel isn't any different.
This is described as being related to 'NitroTPM', which is described as a 'virtual device [...] which conforms to the TPM 2.0 specification'.
Ordinarily, the way you do attestation with a TPM is to perform a TPM quote operation, which provides a TPM-signed attestation of a set of PCRs.
This is... not that. This appears (judging by looking at the source code for some of the provided tools) to be invoking an undocumented(?) vendor-specific command on the TPM device which appears related to the previous Nitro Secure Enclaves support. When AWS introduced Nitro Secure Enclaves, they came up with their own signed attestation document format rather than reusing the TPM standard, then added support for that format to KMS.
The documentation also states: "An Attestation Document is generated by the NitroTPM and it is signed by the Nitro Hypervisor."
This seems to suggest that different entities are responsible for generating AWS's Attestation Document and for signing it, which seems rather odd. What's going on here?
If AWS's claims that NitroTPM is TPM 2.0 compliant are true, it seems like there are now basically two completely different APIs for remote attestation exposed via the TPM virtual device: TPM 2.0 Quote operations and AWS Attestation Documents via an undocumented(?) vendor-specific API.
I can understand wanting to take this approach for consistency with their previous Nitro Secure Enclaves API but it's at the expense of consistency with the existing TPM 2.0 standard. Presumably if you want to use KMS with this you have to use their Attestation Document format rather than a TPM 2.0 Quote, forcing you to use a vendor specific API with it.
Just some thoughts, and this is just my quick impression. I could be mistaken. In any case, having this functionality with a viable KMS tie-in is certainly valuable, so it's nice to see in the sense that you no longer have to create a Nitro Secure Enclave to get this kind of functionality if you don't need the dual compartments separated via a vsock.