-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include Recipient
field on KMS calls for Nitro Enclaves Attestation
#2271
Comments
@shanecurran - Thank you for your post. I am trying to understand the issue here. You are trying to call the kms Decrypt api here with the AWS KMS allows you to use attestation document values in conditions keys to grant access to specific cryptographic operations. Let me know if i misunderstood anything here. |
Thanks for the response @swetashre. In the current structure of the KMS + Nitro Enclaves flow, the KMS supports a (currently) undocumented flow whereby the resulting plaintext/random value gets RSAES_OAEP_PKCS1 encrypted using the Nitro Enclave public key from the I can't find this functionality documented anywhere in the official AWS docs, which has been a source of confusion for me as I only managed to find out the request structure by reading a third-party blog. We use the functionality in production and can confirm that it works as intended. |
Thanks for the information @shanecurran. I've contacted the KMS team to find out more. |
0550741557 |
I heard back with from a Nitro Enclaves engineer. The documentation for this feature is here, and is complete with respect to what can be done by customers with the https://docs.aws.amazon.com/enclaves/latest/user/kms.html Full description of this from the team:
If there is something missing from the documentation such that this is unclear, let us know and I will relay that to the team. |
Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one. |
I noticed this issue was closed due to inactivity, but this is still a feature that I think many users can benefit from. The definitions included in I understand if there is hesitancy to expose this feature to end users, but not exposing it forces people to reverse engineer the APIs based on the Nitro C SDK, and various blog posts like the one linked above. In addition, the documentation on Nitro is currently lacking. There is value in adding these docs just to elucidate how Nitro works internally. |
@kdaily - so are you saying that all access to the KMS API that uses attestation has to go via the C API? What if I want an implementation native to the programming language so as to avoid an FFI call to C and the complexity of deploying C libs? Wouldn't it be possible to generate the attestation (via interacting with the NSM device) and then attach that to a REST KMS API call using the Unless that's possible, then it pushes those who want native code (i.e. in their programming language) to make those KMS calls by hand - i.e. not using the @sphw gave the example of Rusoto - and there's a clear argument with that for wanting to avoid the C API. Rust is aimed at safety - unlike C. Avoiding C completely allows a security focus - critical for those wanting to use nitro enclaves., |
The repo that contains the C API documents the REST API with |
Describe the bug
AWS Nitro Enclaves includes an attestation flow which is closely linked with KMS, whereby the response of a KMS Decrypt, GenerateRandom or GenerateDataKey encrypt the response data with a public key included in the Attestation Document. The flow is described here.
Expected behavior
There is no official documentation for this particular flow and I have had to rely on unofficial sources, such as this blog post to find out what the payload structure is. No AWS SDKs currently support the additional
Recipient
parameter and I have had to resort to building my own signing scheme to call the KMS endpoints directly over HTTP.Example structure
The text was updated successfully, but these errors were encountered: