skip to content

Your archive is encrypted under a provider-held key - what does moving it to a key you control and can revoke actually buy you?

level: middleimportance: should knowfreq 54%

answer

  1. control changes one specific thing
  2. same construction, different governance
  3. unwrap is the choke point
  4. revocation plus a key-use record
  5. authorized reads still return plaintext

basics

~20 s

Chiefly one capability and one signal: a revocation switch that renders ciphertext needing that key unopenable, and a record of key use under your own policy. It does not stop an authorized caller reading now.

solid answer

~40 s

Both postures encrypt the same way - a per-object data key, wrapped under a longer-lived key - so the bytes are no better protected. What changes is who controls the `unwrap` call. With a key you control you can withdraw it, and every read that needs it stops; you get a key-use record and a key policy separate from the store's; and you can scope keys to match an obligation, such as one per customer. What you do not get is protection against an authorized caller, because the service still decrypts to serve a permitted read while the key is available. And you take on a real cost: the key service is now on the read path, so a mistaken disable or an unreachable key store means an unreadable archive.

code

pseudocode · 12 lines
pseudocode
# writing an object
dataKey    = randomSymmetricKey()
ciphertext = encrypt(objectBytes, dataKey)
wrappedKey = keyService.wrap(dataKey, keyId = archiveKeyId)
store.put(objectId, ciphertext, metadata = { wrappedKey, keyId: archiveKeyId })

# reading it back
record  = store.get(objectId)
dataKey = keyService.unwrap(record.metadata.wrappedKey, record.metadata.keyId)
if dataKey is refused:          # key disabled, destroyed, or use not permitted
    return error("object unreadable")
return decrypt(record.ciphertext, dataKey)

go deeper

for a junior

Remember that the difference is about who holds and governs the key, not about how strong the encryption is. A key you hold can be taken away; a key the provider holds cannot be taken away by you.

for a middle

Explain envelope encryption precisely, then name what custody adds - revocation, a key-use record, separate policy and chosen scope - and what it leaves untouched, which is any caller the store already permits.

for a senior

Show the operational side: the key service on the read path, the cache window that delays a revocation, the mistaken disable that presents as an outage, and the rewrite needed to move existing objects under a new key.

for a principal

Decide when custody is warranted at all. Tie the choice to a stated obligation, set the key scope that obligation implies, and price the on-call and recovery burden the organisation is accepting for every store that adopts it.

## Both postures use the same construction Start by killing the idea that a controlled key encrypts the data differently. In both cases the service uses **envelope encryption**: a per-object or per-volume **data key** encrypts the bytes, and a longer-lived **wrapping key** encrypts the data key. The wrapped data key is stored alongside the ciphertext. The only thing that changes between the two postures is **which wrapping key is used and who governs it**. So the honest framing is not *stronger encryption*. It is: who owns the `unwrap` call, and can they refuse it? ## What control actually buys - **Revocation.** Disable or destroy the key and every remaining piece of ciphertext that needs it becomes unopenable, including copies you cannot enumerate. This is the one capability a provider-held default cannot give you, and it is the reason custody exists. - **A key-use record.** Key operations are recorded under your key policy, giving a signal distinct from the store's own access records. A read that never appears as an unwrap is a read that did not happen, which is useful during an investigation. - **Policy separation.** Permission to call the store and permission to use the key are two grants on two objects. A caller who has one and not the other gets ciphertext or an error, not data. - **Scoping.** You choose the granularity - one key per store, per environment, or per customer. That scope is what a later revocation will act on, so it is worth deciding deliberately rather than inheriting. ## What it does not buy | Claim | True? | Why | |---|---|---| | An authorized caller no longer reads plaintext | No | While the key is available the service unwraps and decrypts as before | | The service never holds plaintext | No | It must, in order to serve the read | | The data is encrypted more strongly | No | Identical construction; only the wrapping key's governance changed | | You can withdraw readability on demand | Yes | This is the capability custody adds | | Key use becomes visible to you | Yes | Under your key policy, separate from data access records | The first row is where candidates lose the question. Custody is a **withdrawal** control and an **evidence** control, not a confidentiality control against callers who are already permitted. Who may call the store is a separate mechanism. ## The cost you take on Control puts the key service on the path of every read, and often every write. Three consequences follow, and a strong answer names them without being prompted: 1. **Availability.** An unreachable key service, a mistakenly disabled key, or a policy change that removes the service's permission to use the key all present as an unreadable archive. A confidentiality control has become an availability dependency. 2. **Recoverability.** You can now lose the key, and losing it is indistinguishable from destroying the data. This is why key services offer a pending-deletion window that is still reversible - and why that window is also a hole in any destruction claim. 3. **Latency and caching.** Services cache unwrapped data keys for a bounded interval to avoid an unwrap per request. That interval is the lag between revoking a key and reads actually failing, so a revocation is never instantaneous. ## Where the key material can live There is a further step beyond controlling a key inside the platform's key service: holding key material in a store you operate outside the provider and making it available to the platform. That buys custody that survives the provider relationship and makes the residency of key material a fact you control - at the price of running, monitoring and being paged for the system on which every read now depends. It is a defensible posture for a specific obligation and an expensive one taken on reflex. ## How to answer it Say the construction is the same, name the three things custody adds - revocation, a key-use record, policy and scope of your own - and then name what it does not add, which is any defence against a caller already permitted to read. Close with the cost: the key is now on the read path, and your team owns whatever happens to it. An answer that claims custody keeps the provider out of the plaintext is the common failure, because the service must decrypt in order to serve the request.

  • If a caller may read the store but may not use the key, what does it get?
    An error, or ciphertext it cannot open, depending on where the service checks. The two grants are independent, which is the practical value of policy separation: the store permission alone is no longer sufficient to obtain plaintext, and the failed unwrap appears in the key-use record as a signal.
  • Why is a revocation not instantaneous even when the key is yours?
    Services cache unwrapped data keys for a bounded interval so that every request does not cost an unwrap call. Until those cached keys expire, reads continue to succeed. The cache window is therefore the real answer to how quickly a revocation takes effect, and it is worth knowing before you promise one.
  • Does moving to a controlled key re-encrypt data that already exists?
    Usually not. Many services apply a changed key only to new writes, so existing objects stay wrapped under the old key until they are rewritten - often by copying them in place. Some designs re-wrap in the background instead. Either way, check before assuming the whole archive has moved.

saying these in an interview costs you the question

  • Says a customer-controlled key stops an authorized caller reading the data.
  • Claims controlling the key means the service never handles plaintext.
  • Assumes the whole object is encrypted directly under the controlled key.
  • Ignores that the key service now sits on the path of every read.
  • Treats key control as a pure upgrade with no operational cost.