StreamCipher header metadata is not authenticated in encrypted backups

[Montana]

Hello,

Observed Issue: Unauthenticated Encryption Metadata

While reviewing the encrypted backup flow in apple/foundationdb, we noticed that the encryption header and metadata associated with StreamCipher are not covered by any authentication mechanism.

Concretely, the current design appears to:

• Encrypt the backup payload using AES-GCM (or an AES-GCM-like construction).

• Store metadata such as:

  • key_id / key_version
  • nonce / iv
  • additional backup-related fields
    adjacent to the ciphertext, but

• This does not bind this metadata into the AEAD as Additional Authenticated Data (AAD).

Therefore, an attacker with write access to the encrypted backup object could, in principle, tamper with metadata (e.g., the key ID or other flags) without invalidating the authentication tag, since this header is not authenticated as part of the AEAD.

In other words, even if the ciphertext itself is encrypted using a correct AEAD scheme, the metadata that the system depends on to decrypt and interpret the data is not integrity-protected.

---

Why This Matters

If header fields (e.g., key_id, encryption mode, version flags) are not covered by authentication, several classes of semantic tampering become possible:

Key-ID Swapping

An attacker could modify the key_id in the header so the decryptor selects a different (but valid) key. Depending on implementation details, this might:

• produce deterministic but incorrect plaintext that does not look corrupted, or
• cause the decryptor to silently fall back to a legacy behavior.

Mode / Version Downgrade

If the header encodes an encryption version or mode flag, an attacker could potentially force decryption into a weaker or legacy code path by editing that field.

Misleading Metadata

Even if the ciphertext fails to decrypt, the system may still log or display unauthenticated metadata (e.g., “encrypted with key version 5”), allowing forged or misleading information to be surfaced.

Modern AES-GCM guidance recommends that all non-secret metadata that affects ciphertext interpretation (e.g., key_id, algorithm version, flags) be included as AAD. This is called out explicitly in multiple AEAD usage guidelines and security best-practice documents.

---

Suggested Remediation

Bind the encryption metadata (including key_id, nonce, encryption mode, version, and any backup-specific flags) into the AEAD invocation as AAD, such as:

EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), nullptr, nullptr, nullptr);

EVP_EncryptUpdate(ctx, nullptr, &len, header_bytes, header_len);

EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len);

This ensures any tampering with header fields invalidates the authentication tag.

---

References

• https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption
• https://andrea.corbellini.name/2023/03/09/authenticated-encryption/

Michael