Comment by theamk | Hacker News Reader

Comment by theamk | Hacker News Reader

The document is not clear how did you achieve goal #1 ("must verifiably not be able to access or decrypt data"). There are lots of low-level details about Rust and padding attacks, but ultimately your security model is:

We keep the keys in AWS KMS and we use AWS policies settings to ensure that only executable generated by our Github Action job can access those keys.

This immediately shows how the Evervault (or a hacker impersonating Evervault employee) can access or decrypt user data:

Option 1: Go to AWS dashboard and change that KMS policy to be less restrictive. Then you can fetch the keys directly using awscli or download them from console.

Option 1a: if you are using some IaaS solution (terraform, cloudformation etc..) you can take over this, it may be easier.

Option 2: Commit a code into E3 repo that exfilatrates the keys and have that code deployed. Enclaves cannot connect to internet, so you'll have to be a bit creative -- perhaps encrypting a string "HELLO123" should produce a master key?

Option 3: If you cannot commit a code without someone noticing, go to Github settings and get all the environment/secrets from the repo. Then find an ssh key used to manage the self-hosted action runner which signs the images. Once you have those, you should be able to run the action steps locally on your repo.

Thanks for commenting! One thing worth clarifying before diving into specifics is that Evervault doesn't store user data. We do store encryption keys, but the model is that our customers store encrypted data but not keys; Evervault stores keys but not encrypted data.

The attacks you mention (correctly) base themselves on the security of the signing key used to sign the E3 binary. The security of this key is obviously extremely important, but is only one part of the attestation process. Nitro Enclaves exposes attestation documents with platform control registers (PCRs). PCR8 is a hash of the key used to sign the binary itself, but there are also 5 others which contain hashes of the specific binary that is being run as well as the in-memory state of the enclave. Combining these together, means that attestation focuses both on deployment integrity (and GitHub Actions is the weakest point here) as well as the code itself. This is why exposing the code that runs inside E3 is a major focus of ours.

Re: KMS policy integrity, having the enclave communicate with IAM with TLS certificate validation is one way of E3 proving to the end user providing keys/data that the enclave key has not been tampered with. It's a messy solution, but cryptographically robust assuming that the AWS Root CA has not been compromised.

No, only "Option 3" cares about security of the signing key.

Other options do not rely on compromising any encryption keys or production servers, they just need a developer's machine being compromised.

You are talking about PCR and hashes, and they are all good, but ultimately, it all ends up as a "Attestation" field in the request to AWS. And then it is evaluated against a policy, like that one: [0]. So what prevents someone from planting a trojan on arcurn's machine, waiting until they log into AWS console, and changing this policy to remove "Condition" block? Once this is done, anyone can fetch AWS keys and decrypt customer data.

And I don't think "TLS certificate validation" is going to help here, as it will be talking to authentic server. Nor checking of PCRs -- because this is done in that "condition" lock which is so easy to remove.

[0] https://docs.aws.amazon.com/enclaves/latest/user/kms.html

Yep, but the binary running in the enclave has access to both the attestation document (including PCRs) directly from Nitro as well as a mechanism to fetch IAM policies and verify that they are from the genuine IAM server (verify the TLS CA).

Making sure the IAM policy hasn't been tampered is just a case of adding logic to the enclave app to make sure that the IAM policy is configured correctly for that particular enclave (compare PCRs, make sure there's no wildcards, etc.)

Reply on news.ycombinator.com