AwsKmsCryptographicMaterialsProvider Design/Behavior Improvements

[lavaleri]

Problem:

The correct behavior of the DirectKMSMaterialProvider is to use the configured CMK on encrypt, and to let KMS determine the correct CMK to use on Decrypt (this is a common KMS pattern, as KMS ciphertext stores the CMK used as metadata).

However, this behavior for DirectKMSMaterialProvider is potentially confusing, as customers may expect that the CMK configured on the CMP is also "used" to decrypt, and may be surprised if decryption succeeds even though the configured CMK was not the CMK used to encrypt the data.

Solution:

Since the original DirectKMSMaterialProvider was designed, KMS has introduced a keyId param on Decrypt that ensures the call fails if a different key was used to encrypt the ciphertext.

We should consider either updating or replacing the DirectKMSMaterialProvider to allow enforcing a particular key on decrypt, similar to the Strict vs. Discovery modes expressed by the AWS Encryption SDK's Keyrings and Master Key Providers.

Our new design should:

• maintain API parity between the DDBEC for Python and Java.
• be as simple as possible to reason about.
• minimize possible "modes" for behavior, and ensure that any "mode" needs to be explicitly chosen by customers on config.
• ensure that any default configuration/behavior chooses the safest/most conservative option for customers.

[lavaleri]

Related Java Issue: aws/aws-dynamodb-encryption-java#151

[nappelson]

Thanks @lavaleri - do you have any suggestions for us while using the library in its current state to enforce the key_id? Is there some further validation we could do?

[lavaleri]

Hi @nappelson,

Unfortunately there isn't a workaround to enforce the use of a key_id in the current release. While we do have plans to provide a CryptographicMaterialsProvider that performs the behavior you want, we do not have a timeline we can share for its release.

CryptographicMaterialsProviders were designed as a point of custom configuration to suite customer's key management needs. If it is necessary for you to have this behavior now, you may implement your own CryptographicMaterialsProvider which does the same thing as your changes in #171, and use that in your application. However, if you go this route you will not pick up any future improvements we make to AwsKmsCryptographicMaterialsProvider, and we cannot guarantee a smooth migration to new or upgraded CryptographicMaterialsProviders we may provide in the future.