feat(KeyStore): Key Store Admin & Storage #788
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Crypto Tools would like to prepare for our next release, but it seems we have stumbled into a few Dafny bugs. The Dafny .NET compiler is struggling with the Storage changes in Additionally, the Smithy-Diff workflow has generated far too much noise. Crypto Tools use GitHub notifications to track customer cut or updated GitHub issues. Tagging a contributor for every commit pushed generates far too much noise. See #717 as evidence that '.github/workflows/block_main.yml' fails if this commit targets main.
The key store now allows for both a default DynamoDB table, or any custom storage system. The important aspect about the key store is the fact that branch keys can be versioned easily, and are cryptographically safe to use. The actual storage medium is not important. See: https://github.com/awslabs/aws-encryption-sdk-specification/blob/master/changes/2024-6-17_key-store-persistance/background.md#background
Beta build of Mutations with several substantial gaps --------- Co-authored-by: seebees <[email protected]>
Crypto Tools, at this time, intends to release Branch Key Mutations without some operations useful for recovering a dropped Mutation Token or dealing with the disagreement of a Mutation Token and a Mutation Lock. Additionally, we intend to release the Key Store Admin with only support for one Key Management Strategy. All checks are green except for Verification. Verification is failing for the Key Store Admin's Index.dfy. Verification for the Key Store Admin's Index.dfy has been failing for a long time.
…#753) This resolves feedback from both @seebees and @josecorella on Mutations branch. Verification failure is due to (just like in #751 ): 1. Key Store Admin's Index.dfy not proving Fresh, which has been a long standing issue with the Admin 2. In `AwsCryptographyKeyStore/test/Storage/TestGetItemsForInitializeMutation.dfy`, the test assumes `type` is in the Encryption Context. It is, but Structure.dfy does not prove that, so it must be proven else where. A .NET MPL job failed due to .NET 48 Sig V4 Auth bug.
* refactor(Storage): Use TransactGet instead of BatchGet for GetInitMut (#753) This resolves feedback from both @seebees and @josecorella on Mutations branch. * chore(Mutations): address #754\#discussion_r1775676091 #754 (comment) * chore(Mutations): Address feedback from #750 See #750 * chore(Mutations): address feedback on #742 See #742
The Key Store Admin client exposes administrative operations for the Branch Keys used by the AWS KMS Hierarchical Keyring. These Operations are: - Create Key - Version Key - Initialize Mutation - Apply Mutation See the Java Examples directory for the AWS Cryptographic Materials Provider for details: `AwsCryptographicMaterialProviders/runtimes/java/src/examples` Changes from rc-1.7.0 - Initialize Mutation now uses `ddb:TransactGetItems` instead of `ddb:BatchGetItems`. - To better facilitate DDB Queries, we changed the type string (sort key in key store table) of the mutation lock from `MUTATION_LOCK` to `branch:MUTATION_LOCK`. This is a breaking change that will corrupt any in-flight mutations. As Branch Key Mutations is only present in release-candidate branches, no customers are impacted by this breaking change.
If the KMS Call, for mutating the Beacon, fails, it MAY indicate the MPL Consumer does not have access to the terminal KMS Key. If the KMS call for verifying a terminal version fails, it MAY indicate the MPL Consumer does not have access to the terminal KMS Key. Also fix some Dafny tests failing verification.
Created via: git merge public_aws/main -s ort -X ours
|
@josecorella @seebees The Java Examples failure is because we removed the Strings from Opaque, See: smithy-lang/smithy-dafny#619 Thus, I am happy with that test failing. Also, I would like to get this squashed into rc-1.8.0 relatively soon, |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat: Adding a storage option to the KeyStore #594
The key store now allows for both a default DynamoDB table,
or any custom storage system.
The important aspect about the key store
is the fact that branch keys can be versioned easily,
and are cryptographically safe to use.
The actual storage medium is not important.
See: https://github.com/awslabs/aws-encryption-sdk-specification/blob/master/changes/2024-6-17_key-store-persistance/background.md#background
feat: Key Store Admin
The Key Store Admin client exposes administrative
operations for the Branch Keys used by the
AWS KMS Hierarchical Keyring.
These Operations are:
See the Java Examples directory for the
AWS Cryptographic Materials Provider for details:
AwsCryptographicMaterialProviders/runtimes/java/src/examplesfeat(KeyStore): Safely Mutating Branch Keys
TBD
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.