Example code for generateDataKey

Hi, I’ve been using the SDK and I can encrypt and decrypt in javascript but now I’d like to generateDataKey(s) for each of my departments - there doesn’t seem to be an example and following the same style doesn’t seem to work. I’ve tried following some of the code I found in one of the Mocha tests but it appears to use a helper? Any chance of adding an example or extending the current encrypt-browser example?

The code below is an example of what I think should work but throws “generateDataKey is not a function”.

       const { encrypt, generateDataKey } = buildClient(
            CommitmentPolicy.REQUIRE_ENCRYPT_REQUIRE_DECRYPT
        );
        let clientProvider = getClient(KMS, { credentials: this.creds });

        let params = {
            "KeyId": this.generatorKeyId,
            "EncryptionContext": {"department": "test"},
            "NumberOfBytes": 256,
            "KeySpec": AES_256,
            "Client": clientProvider
        }

        let dek = await generateDataKey(params);

[seebees]

Ah, I think I see. The short answer is: You don’t add DEKs/KEKs to the current AWS KMS keyring. To accomplish something like this you could use the RAW AES keyrings and implement a key hierarchy. This is probably more complicated than than you need, but you are the best judge of your requirements 😃 I do not suggest going down this road.

This is because you are securing this separation of access through policy. You only let each department have access to the specific top level key stored in DDB through some kind of policy control on the CMK.

Instead I would suggest that you use policy conditions in AWS KMS https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms

For your use case I think you could use encryption context https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-encryption-context and then define policies for "kms:EncryptionContext:department": "Finance" vs "kms:EncryptionContext:department": "HR".

This pushes the policy control down to the item level. This gets you out of having to manage the keys in DDB. It also lets you more easily change your access, and you can apply even or granular controls than by department…

[seebees]

I hope it does.

Key hierarchies are complicated because they touch on key distribution, cryptographic limits, and key rotation. If you must, you can use AWS KMS to help. GenerateDataKeyPairWithoutPlaintext can help you generate the department keys that you are proposing storing in DDB (I think). Also remember that anyone who can decrypt this key will have access to everything encrypted under the department.

Last plug for the AWS KMS policy solution: Audit. This gives you the ability to see who and when each element of you encrypted data is being touched. It is an oft overlooked element of rolling your own key hierarchy.