fix: Raw AES keyring handling of MasterKey

There are two sublte things going on here.

First, in the case of a mixed backend,
the non-zero backend should be the native implementation.
I assert that it should be slightly harder to exfiltrate
from the native implementation than a JS implementation.

Second, if I force the import of the master key into only half of the mixed backend,
then `getSubtleFunction` will complain about a mismatch.
Because the crypto key and the backend are not both mixed.

To resolve this the backend for the raw AES master key is issolated here.

Author: seebees

modules/raw-aes-keyring-browser/src/raw_aes_keyring_browser.ts

@@ -46,7 +46,7 @@ import {
 } from '@aws-crypto/raw-keyring'
 import { fromUtf8, toUtf8 } from '@aws-sdk/util-utf8-browser'
 import { randomValuesOnly } from '@aws-crypto/random-source-browser'
-import { getWebCryptoBackend, getZeroByteSubtle } from '@aws-crypto/web-crypto-backend'
+import { getWebCryptoBackend, getNonZeroByteBackend } from '@aws-crypto/web-crypto-backend'
 const { serializeEncryptionContext } = serializeFactory(fromUtf8)
 const { rawAesEncryptedDataKey } = rawAesEncryptedDataKeyFactory(toUtf8, fromUtf8)
 const { rawAesEncryptedParts } = rawAesEncryptedPartsFactory(fromUtf8)
@@ -134,9 +134,8 @@ export class RawAesKeyringWebCrypto extends KeyringWebCrypto {
       * See: raw_aes_material.ts in @aws-crypto/raw-keyring for details
       */
       .setUnencryptedDataKey(masterKey, { keyNamespace: 'importOnly', keyName: 'importOnly', flags: KeyringTraceFlag.WRAPPING_KEY_GENERATED_DATA_KEY })
-    return getWebCryptoBackend()
-      .then(getZeroByteSubtle)
-      .then(backend => _importCryptoKey(backend, material, ['encrypt', 'decrypt']))
+    return backendForRawAesMasterKey()
+      .then(backend => _importCryptoKey(backend.subtle, material, ['encrypt', 'decrypt']))
   }
 }
 immutableClass(RawAesKeyringWebCrypto)
@@ -158,7 +157,7 @@ async function aesGcmWrapKey (
   aad: Uint8Array,
   wrappingMaterial: WebCryptoRawAesMaterial
 ): Promise<WebCryptoEncryptionMaterial> {
-  const backend = await getWebCryptoBackend()
+  const backend = await backendForRawAesMasterKey()
   const iv = await backend.randomValues(material.suite.ivLength)
 
   const kdfGetSubtleEncrypt = getSubtleFunction(wrappingMaterial, backend, 'encrypt')
@@ -194,7 +193,7 @@ async function aesGcmUnwrapKey (
   const { suite } = material
   const { iv, ciphertext, authTag } = rawAesEncryptedParts(suite, keyName, edk)
 
-  const backend = await getWebCryptoBackend()
+  const backend = await backendForRawAesMasterKey()
 
   const KdfGetSubtleDecrypt = getSubtleFunction(wrappingMaterial, backend, 'decrypt')
   const info = new Uint8Array()
@@ -203,3 +202,20 @@ async function aesGcmUnwrapKey (
   material.setUnencryptedDataKey(new Uint8Array(buffer), trace)
   return importForWebCryptoDecryptionMaterial(material)
 }
+
+/**
+ * The master key can not be zero length.
+ * If the back end is mixed,
+ * to support both zero and non-zero byte AES-GCM operations,
+ * then the `NonZeroByteBackend` should be the native implementation.
+ * I assert that it should be slightly harder to exfiltrate
+ * from the native implementation than a JS implementation.
+ * So I *force* the master key to be stored in the native implementation **only**.
+ */
+async function backendForRawAesMasterKey () {
+  const backend = await getWebCryptoBackend()
+  const { randomValues } = backend
+  const subtle = getNonZeroByteBackend(backend)
+
+  return { randomValues, subtle }
+}