search

aws-samples / aws-nitro-enclave-blockchain-wallet

MIT No Attribution
38 stars 10 forks source link

Key security via KMS Policy change #19

Closed jeapostrophe closed 10 months ago

jeapostrophe commented 10 months ago

Hi David,

I know this is quite an old tutorial, but it is very interesting and I hope I can contact you through this method.

In part 2 of the tutorial, in the section "Configure a KMS key policy for cryptographic attestation", you create a key in KMS, and then change the KMS policy so that the enclave has access, then you claim "Now that the KMS key policy has been configured, only the enclave container running on the EC2 instance is able to run the decrypt operation using this KMS key."

I would like to check my assumptions, because based on them, this claim is not true.

First, if the user had created the key first and uploaded it to KMS, then the user would have access to the key (and thus to the wallet and all of the secret data secured by the key), but since KMS is the thing that creates the key, this is not a risk.

However, the AWS account user (especially the root user) can change the KMS policy anytime they want, so they can change the policy to e.g. "Jay AND the enclave can see the key", thus there is no guarantee that the enclave is the ONLY actor that can ever access the key.

Unless there were a way to atomically...

  1. Create the key
  2. Give the enclave access to it
  3. Only allow the enclave to change the policy for it Then there would be no hope having a key that were truly controlled only by an enclave.

(Obviously, the enclave could just create the key locally, but since they are stateless, it would have no way (on being restarted/etc) to get it again.)

My understanding is that enclaves kind of already have a key like this built-in, which is the private/public key-pair that shows up in their attestation document and that KMS with AWS Nitro integration uses to handle requests. But I don't see the APIs for using that key-pair in other contexts.

In examples like --- https://aws.amazon.com/blogs/compute/leveraging-aws-nitro-enclaves-to-perform-computation-of-multiple-sensitive-datasets/ --- the use of KMS/Nitro integration is effective for user A sharing information with user B's enclave C, but the information is still available for user A. In your example (and in blockchain examples generally), the goal is actually to ensure that user A can create an enclave D where D is the only actor with access to the key... not even A can access it but D (and future restarted instances of D) can have access it. Given that KMS policies can be changed, I don't see how A can guarantee a key is protected like this....

Can you correct me? What am I missing?

If it is better to email or talk out of Github, I can be reached at jay.mccarthy@gmail.com

Thank you!

dpdornseifer commented 10 months ago

Hi Jay, you're right about the trust assumptions. There are different ways to ensure the security of the KMS key policy. We could leverage an event based mechanism using AWS CloudTrail together with a trusted security account and having an event listener filter for policy change events and instantly trigger a remediation. Another way is to use different accounts for the KMS keys with restricted root access for example by leveraging AWS Organizations and Control Tower https://github.com/aws-samples/baseline-environment-on-aws.

Does that answer your question?

jeapostrophe commented 10 months ago

Thank you!