AWS Announces Ec2 Instance Attestation
Posted3 months agoActive3 months ago
aws.amazon.comTechstory
calmmixed
Debate
40/100
AWSEc2SecurityTpm
Key topics
AWS
Ec2
Security
Tpm
AWS announces EC2 instance attestation, a feature allowing for secure verification of EC2 instances, sparking discussion about its implementation and potential use cases.
Snapshot generated from the HN discussion
Discussion Activity
Light discussionFirst comment
50m
Peak period
3
1-2h
Avg / period
1.8
Key moments
- 01Story posted
Sep 24, 2025 at 3:05 PM EDT
3 months ago
Step 01 - 02First comment
Sep 24, 2025 at 3:55 PM EDT
50m after posting
Step 02 - 03Peak activity
3 comments in 1-2h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 24, 2025 at 8:44 PM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45364655Type: storyLast synced: 11/20/2025, 4:47:35 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
To give an idea of the kinds of things you can do now:
This is similar to the functionality that was available in Nitro Enclaves. However, enclaves came with restrictions (such as only being able to communicate through a vsock) that made them not a great fit for all use cases.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.
To every cloud/server vendor: This is a big deal. I need a system I can audit, from silicon and firmware up, but I don’t want to water it, give it sunlight, or whisper sweet nothings to it, just to rent it out as needed.
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.
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.
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.