A backup of the metadata table holding every object's wrapped data key leaks — what does the holder actually have?

seniormust knowfreq 50%

answer

wrapped keys are ciphertext
inert without the unwrap path
becomes an access-control question
every unwrap leaves a record
one level up is the whole estate

basics

~20 s

Wrapped data keys decrypt nothing on their own. They are usable only by getting the key manager to unwrap them, so the leak turns into an access-control question: whoever the manager will still answer can read those objects, and every unwrap it performs is on the record.

solid answer

~50 s

A wrapped data key is ciphertext, and the key that opens it never left the manager, so the table by itself opens nothing. What the holder gains is a map: one entry per object, naming which key wrapped it and where its ciphertext sits. To turn an entry into plaintext they need three things together — the wrapped key, the object's ciphertext, and a caller the manager will unwrap for. The first two may be in the same backup; the third is the control that actually held. That is why the response is an authorization and monitoring exercise rather than a cryptographic one: look at which identities can call unwrap, at what rate, and what the manager recorded. The level above is the one that changes the answer entirely — if the key-encryption key material itself were taken, the same table decrypts offline, with no call and no record.

A wrapped data key is ciphertext, and the key that opens it never left the manager, so the table by itself opens nothing. What the holder gains is a **map**: one entry per object, naming which key wrapped it and where its ciphertext sits. To turn an entry into plaintext they need three things together — the wrapped key, the object's ciphertext, and a caller the manager will unwrap for. The first two may be in the same backup; the third is the control that actually held. That is why the response is an authorization and monitoring exercise rather than a cryptographic one: look at which identities can call unwrap, at what rate, and what the manager recorded. The level above is the one that changes the answer entirely — if the **key-encryption key material itself** were taken, the same table decrypts offline, with no call and no record.

code

json · 9 lines

json

{
  "objectId": "upl-7f3c91",
  "tenant": "tenant-1042",
  "ciphertextLocation": "objects/2026/09/upl-7f3c91.bin",
  "wrappedDataKey": "q8Xv...c2Fs (opaque; opens only inside the manager)",
  "wrappedBy": "document-uploads-wrapping-key",
  "wrappedAt": "2026-09-14T11:02:44Z",
  "sizeBytes": 2148311
}

go deeper

for a junior

Hold on to the basic fact: the wrapped data key stored next to an object is itself encrypted, and the key that opens it stays inside the manager. A copy of the store is not a copy of the key.

for a middle

Explain why the blob is inert and what must be assembled to use it — the wrapped key, the object's ciphertext, and a caller the manager will unwrap for. Name which of the three the leak did and did not supply.

for a senior

Run it as an incident: ask whether the ciphertext travelled in the same copy, which identities hold unwrap rights over that key, what the manager recorded, and what an abnormal unwrap rate would look like against normal read traffic.

for a principal

Decide in advance how much one stolen unwrap right should convert. Splitting wrapping keys by tenant or sensitivity, and scoping each service's unwrap right to what it serves, is the design lever that bounds this class of leak before it happens.

Three levels, three blast radii

The envelope model has levels, and the honest answer to "how bad is this" depends entirely on which level the attacker reached. The three are worth holding side by side:

what was taken	what it opens	what is still needed	leaves a record?
one plaintext data key, plus that object's ciphertext	exactly that one object	nothing further	no
every wrapped data key (the metadata table)	nothing yet	the ciphertext, plus a caller the manager will unwrap for	yes, one entry per unwrap
the key-encryption key material itself	everything ever wrapped under it	the ciphertext only	no

The middle row is the one in this scenario, and it is the one people get wrong in both directions. Treating it as catastrophic wastes an incident on re-encrypting 40 TB. Treating it as nothing ignores that the attacker now knows exactly what exists, how much of it there is, which objects belong to which tenant, and which key wrapped each one — and that they are one working credential away from using it.

Why the wrapped keys alone are inert

A wrapped data key is the data key encrypted under a key that the manager generates internally and never emits. There is no operation the holder of the blob can perform on it offline that yields the data key; the only door is asking the manager to unwrap, and the manager decides whether to answer. This is the property the whole model is bought for: the store can be replicated, backed up, shipped to a second site and handed to an operations team, and none of those copies is a copy of the key.

It also means the security of the table reduces to two other systems entirely:

who the manager will unwrap for — which identities hold that right, over which keys, and whether that right is scoped to the service or effectively estate-wide;
what the manager records — an unwrap call per object is a loud, countable signal, and a run against the whole table is twenty million of them.

What the holder gains that is not plaintext

Underrating the leak usually comes from thinking only about decryption. The metadata record is itself disclosure:

an inventory — how many objects exist, per tenant, with what creation times;
a targeting list — if objects are named or labelled, the interesting ones are picked before any unwrap is attempted, so the attacker's call volume can be small enough to sit under a threshold;
a structure map — which key wrapped which set of objects, which tells them what a single successful unwrap right would reach.

What actually changes the verdict

Two follow-on facts flip this from a contained event to a serious one, and both are worth asking for immediately:

Did the same copy carry the object ciphertext? A backup holding both is one working credential from being plaintext. A backup holding only the metadata table is two steps away.
Did anything in the same breach reach a caller the manager honours? A service identity with unwrap rights over the whole key is the difference between the middle row of that table and the bottom one in practice, even though the key material itself never moved.

The unwrap right is also where a design choice shows up sharply. If every object's data key is wrapped under one key-encryption key and every read path holds the right to unwrap under it, then a single stolen caller identity is equivalent to the whole table. Splitting the wrapping keys — per tenant, per region, per sensitivity class — does not make the leak of wrapped blobs any worse or better, but it does change how much one stolen unwrap right converts.

Rotating the wrapping key is not the fix here

This is the standard wrong reflex. Rotating and rewrapping gives every record a new wrapped blob, but the leaked blobs were wrapped under the previous key, and that key still exists until it is destroyed — so the leaked copy remains unwrappable-by-the-manager exactly as before, no better and no worse. The controls that matter are the ones on the unwrap path: which identities may call it, whether their rights can be narrowed to the objects they serve, what rate is normal, and whether anyone is watching the count. Destroying the old wrapping key does neutralise the leaked blobs permanently, but it also permanently destroys every object still wrapped under it, so it is only available once every live record has moved.

The summary a candidate should be able to give in one breath: wrapped keys are ciphertext, the leak is an access-control and monitoring problem rather than a cryptographic one, and the answer changes completely one level up.

## Three levels, three blast radii The envelope model has levels, and the honest answer to "how bad is this" depends entirely on which level the attacker reached. The three are worth holding side by side: | what was taken | what it opens | what is still needed | leaves a record? | |---|---|---|---| | one plaintext **data key**, plus that object's ciphertext | exactly that one object | nothing further | no | | every **wrapped data key** (the metadata table) | nothing yet | the ciphertext, plus a caller the manager will unwrap for | yes, one entry per unwrap | | the **key-encryption key material** itself | everything ever wrapped under it | the ciphertext only | no | The middle row is the one in this scenario, and it is the one people get wrong in both directions. Treating it as catastrophic wastes an incident on re-encrypting 40 TB. Treating it as nothing ignores that the attacker now knows exactly what exists, how much of it there is, which objects belong to which tenant, and which key wrapped each one — and that they are one working credential away from using it. ## Why the wrapped keys alone are inert A wrapped data key is the data key encrypted under a key that the manager generates internally and never emits. There is no operation the holder of the blob can perform on it offline that yields the data key; the only door is asking the manager to unwrap, and the manager decides whether to answer. This is the property the whole model is bought for: the store can be replicated, backed up, shipped to a second site and handed to an operations team, and none of those copies is a copy of the key. It also means the security of the table reduces to two other systems entirely: - **who the manager will unwrap for** — which identities hold that right, over which keys, and whether that right is scoped to the service or effectively estate-wide; - **what the manager records** — an unwrap call per object is a loud, countable signal, and a run against the whole table is twenty million of them. ## What the holder gains that is not plaintext Underrating the leak usually comes from thinking only about decryption. The metadata record is itself disclosure: - **an inventory** — how many objects exist, per tenant, with what creation times; - **a targeting list** — if objects are named or labelled, the interesting ones are picked before any unwrap is attempted, so the attacker's call volume can be small enough to sit under a threshold; - **a structure map** — which key wrapped which set of objects, which tells them what a single successful unwrap right would reach. ## What actually changes the verdict Two follow-on facts flip this from a contained event to a serious one, and both are worth asking for immediately: 1. **Did the same copy carry the object ciphertext?** A backup holding both is one working credential from being plaintext. A backup holding only the metadata table is two steps away. 2. **Did anything in the same breach reach a caller the manager honours?** A service identity with unwrap rights over the whole key is the difference between the middle row of that table and the bottom one in practice, even though the key material itself never moved. The unwrap right is also where a design choice shows up sharply. If every object's data key is wrapped under one key-encryption key and every read path holds the right to unwrap under it, then a single stolen caller identity is equivalent to the whole table. Splitting the wrapping keys — per tenant, per region, per sensitivity class — does not make the leak of wrapped blobs any worse or better, but it does change how much one stolen unwrap right converts. ## Rotating the wrapping key is not the fix here This is the standard wrong reflex. Rotating and rewrapping gives every record a new wrapped blob, but the leaked blobs were wrapped under the previous key, and that key still exists until it is destroyed — so the leaked copy remains unwrappable-by-the-manager exactly as before, no better and no worse. The controls that matter are the ones on the unwrap path: which identities may call it, whether their rights can be narrowed to the objects they serve, what rate is normal, and whether anyone is watching the count. Destroying the old wrapping key does neutralise the leaked blobs permanently, but it also permanently destroys every object still wrapped under it, so it is only available once every live record has moved. The summary a candidate should be able to give in one breath: wrapped keys are ciphertext, the leak is an access-control and monitoring problem rather than a cryptographic one, and the answer changes completely one level up.

The same breach also took the object ciphertext. Does that change your assessment?
Yes, from two steps to one. With both halves in hand, the only remaining control is the manager's willingness to unwrap, so the question becomes whether any credential the attacker holds carries that right. It also means the exposure is permanent for any object whose data key is later obtained by any route, because the ciphertext no longer has to be re-stolen.
Would rotating the key-encryption key contain this leak?
No. The leaked blobs are wrapped under the previous key, which still exists after a rotation, so they remain exactly as usable as before. Only destroying that previous key neutralises them, and that is possible only once every live record has been rewrapped — otherwise it destroys real data along with the attacker's copy.
What signal would show someone working through the leaked table?
Unwrap volume, not failures. A stolen caller identity succeeds, so failure alerting sees nothing; what stands out is a sustained unwrap rate against one wrapping key, from one identity, far above its normal read pattern, or unwraps for objects that identity has never served before.

saying these in an interview costs you the question

Says wrapped data keys can leak freely because they can never be used
Believes the wrapped keys decrypt the objects once you hold them
Assumes unwrapping the entire table would go unnoticed by the manager
Claims rotating the wrapping key makes the leaked wrapped blobs useless
Treats losing key-encryption key material as the same order of problem as losing one data key
Expects failed-authentication alerts to catch an attacker using a valid unwrap right

A backup of the metadata table holding every object's wrapped data key leaks — what does the holder actually have?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Three levels, three blast radii

Why the wrapped keys alone are inert

What the holder gains that is not plaintext

What actually changes the verdict

Rotating the wrapping key is not the fix here

▾common follow-ups3 questions

▾red flags6 flags

Three levels, three blast radii

Why the wrapped keys alone are inert

What the holder gains that is not plaintext

What actually changes the verdict

Rotating the wrapping key is not the fix here

answer

go deeper