Raw AES Keyring zeros out passed in unwrappedMasterKey

[lavaleri]

Problem:

The materials manager zeros out the dataKey in the processing of creating wrapping key material during construction:

aws-encryption-sdk-javascript/modules/material-management/src/cryptographic_material.ts

Lines 823 to 838 in 6b1d1a6

	export function wrapWithKeyObjectIfSupported(
	dataKey: Uint8Array | AwsEsdkKeyObject
	): Uint8Array | AwsEsdkKeyObject {
	if (supportsKeyObject) {
	if (dataKey instanceof Uint8Array) {
	const ko = supportsKeyObject.createSecretKey(dataKey)
	/* Postcondition: Zero the secret. It is now inside the KeyObject. */
	dataKey.fill(0)
	return ko
	}
	if (dataKey instanceof supportsKeyObject.KeyObject) return dataKey
	} else if (dataKey instanceof Uint8Array) {
	return dataKey
	}
	throw new Error('Unsupported dataKey type')
	}

This is normally good practice. However in the case where the buffer has been passed in by the customer via Keyring creation, for example in the Raw AES Keyring case, this leads to surprising behavior.

The Raw AES Keyrings does not make a defensive copy of the key material before creating this material: https://github.com/aws/aws-encryption-sdk-javascript/blob/master/modules/raw-aes-keyring-node/src/raw_aes_keyring_node.ts#L63

And thus the "unwrappedMasterKey" that the customer passed in looks like it gets "consumed." This is surprising to the customer, especially since our docs have no indication of this behavior.

Solution:

The Raw AES Keyring should make a defensive copy of the "unwrappedMasterKey" in it's constructor. It is the responsibility of the customer to zero out the "unwrappedMasterKey" in their application after creation of the Keyring if it is no longer needed, in order to minimize the time the data key exists in plaintext in memory.

Out of scope:

Is there anything the solution will intentionally NOT address?