Hacker News Reader

Comment by patch_cable | Hacker News Reader

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.

View on HN

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

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.

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?

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.

The point I am concerned about is that I am forced to trust a single party. AWS is not ever explicit in admitting this, at which point does it matter that your workload is on Nitro-this or attested-that? No university researcher, afaik, has physical access to audit these systems. I think the other major player(s) have a better story for this by harnessing features of certain cpu vendors.

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.

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

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.

Reply on news.ycombinator.com