Repository navigation
Raw AES Keyring zeros out passed in unwrappedMasterKey #970
Description
Problem:
The materials manager zeros out the dataKey in the processing of creating wrapping key material during construction:
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?
Activity
musatoktas commentedon Oct 14, 2026
I would like to take this. I can reproduce it on current
master(0ceb1f9):RawAesKeyringNodepasses the caller'sunencryptedMasterKeystraight tosetUnencryptedDataKey, andwrapWithKeyObjectIfSupportedzeros it after moving it into aKeyObject. The caller's buffer is wiped, and a second keyring cannot be built from the same key.I would implement what the issue description suggests: the keyring takes a copy of the key (keeping the isolated buffer precondition on the caller's buffer), and the caller stays responsible for zeroing its own copy. It is the same approach as #1699 for the hierarchical keyring.
One behaviour change to be aware of: code that relied on the keyring zeroing the buffer would now keep a live copy until it zeroes it itself. Is this approach fine for the team, or would you prefer a different one?