[arcurn]

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.

[theamk]

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

[arcurn]

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.)