[patch_cable]

Excited to say I worked on this feature! (Standard disclaimer: thoughts and opinions are my own and may or may not be shared by my employer.)

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. 

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.

[jiggawatts]

Who is this for? I don’t know of any customers that are this paranoid but also trust the public cloud.

[privatelypublic]

This doesn't appear to he exclusively anti-evil maid. It takes "build an AMI that doesn't have enough userland to extract the keys" and extends it to "only approved AMI's can access the keys."

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.

[sxzygz]

On AWS, if I run my software (some VM image), what guarantee is there that you are indeed running the image I provided to you? And, if is an approved image, what guarantee is there that image being run is the one publicly disclosed?

[QuinnyPig]

At some point it does come down to "we have to trust the provider isn't outright lying to us about what they're doing."

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.

[crote]

If I understand correctly, it basically works the same as Trusted Boot on a local machine, with the host's CPU used as the root of trust. The difference is that the CPU creates multiple completely independent environments, with for example independent memory encryption keys.

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.

[everfrustrated]

It's less about being able to prove to yourself and more about being able to prove to _other_ people.