Key Derivation & Hierarchy

This page covers the default (non-BYOK) path only: how the per-tenant encryption key used for a given operation is derived, held, and discarded.

Derivation function

On the default path, a tenant’s encryption key is not stored anywhere. It is derived on demand, at the start of a backup or restore operation, using a standard, industry-vetted key-derivation function.

The key is derived from the shared master key and the tenant’s own tenant ID, producing a 256-bit key — the size AES-256-GCM requires.

The same derivation is used consistently across BYOVault’s backup service, so a backup produced by one part of the system can always be restored by another. The derivation is validated with a shared set of test cases to guarantee that consistency.

Unique per tenant

The derivation binds the derived key to each tenant’s own identity: the same master key, combined with a different tenant ID, produces a completely different 256-bit key. No two tenants on the default path ever encrypt with the same derived key, even though every one of them ultimately traces back to the same underlying master key.

One master key behind every default-path tenant
Per-tenant derivation changes the key used for each tenant’s data — it does not change how many independent secrets exist. Every default-path tenant’s key is a deterministic function of one shared master key. Anyone who holds that master key can re-derive any default-path tenant’s key from its tenant ID alone. See The Shared Master Key for where that master key is held and what protecting it does and does not change, and Customer-Managed Keys (BYOK) for the alternative with no shared secret at all.

In-memory lifecycle

The derived key exists only in memory, and only for the duration of the operation that needs it. It is never written to disk, logged, or cached across operations.

At the start of a backup or restore operation, the key is derived once and used to encrypt or decrypt the data for that operation.

Erasure happens even on failure
The key is erased from memory as soon as the operation completes — including when the operation fails partway through.

A fresh key is derived again, from scratch, the next time an operation for that tenant runs. There is no long-lived key held in memory across operations, and no key cache to invalidate.

Where derivation does not apply

This entire derivation step is specific to the default path.

A tenant with an active customer-managed key configuration uses a genuinely random File Key generated fresh per file and wrapped by the tenant’s own KMS key — that key is never derived from the shared master key, and this derivation process is not involved at all. See Customer-Managed Keys (BYOK) for that path in full.