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