Why customer-managed keys aren't zero-knowledge

The intuitive sale

The CMK pitch is intuitive: "you bring your own keys; only you can decrypt; the provider can't read your data." On the surface, this answers the sovereignty question — and for many organisations, it has been enough for procurement.

The intuition is wrong on the dimension that matters for sovereignty against legal compulsion. Let's unpack why.

Where the keys actually live

In every major hyperscaler CMK implementation, "your" keys are held in the provider's key-management service: AWS KMS, Azure Key Vault, GCP Cloud KMS. The key material does not physically sit in your data centre. It sits in the provider's HSM cluster, hosted in the provider's region of choice.

You control authorisation: only your IAM principals can request unwraps. You can rotate, schedule deletion, audit usage. You cannot — except in specialised "external key store" modes that come with severe latency and integration costs — keep the key material outside the provider's plane.

How the unwrap actually happens

When your workload requests a read of an encrypted object, the flow is roughly:

1. Workload (running on EC2/Azure VM/GCE) requests object from object storage
2. Object storage layer reads the wrapped data-encryption key
3. Object storage layer calls KMS to unwrap the DEK
4. KMS performs the unwrap inside its HSM
5. Unwrapped DEK is returned to the object storage layer
6. Object storage decrypts the object and streams plaintext to the workload

Step 5 is the problem. The unwrapped DEK exists, in memory, within the provider's environment. The plaintext exists, in memory, within the provider's environment. If a court compels the provider to log or surrender that memory state, the operation is technically reachable.

"External key stores" (AWS XKS, Azure Cloud HSM) reduce this risk by keeping the key material in customer-controlled HSMs and routing the unwrap operation through an outside cryptographic provider. But the unwrapped DEK still has to enter the provider's compute plane to perform the decryption — otherwise the workload can't read its own data. The exposure surface is narrower; it is not eliminated.

What zero-knowledge means in the SkyeConnex sense

SkyeConnex enforces a structurally different topology. The User Master Key is derived on the client device using scrypt over the user's password (or out-of-band recovery key). The UMK never reaches the SkyeConnex server in unwrapped form. The server has no API path that returns plaintext, because the server has no code that derives the key.

Practically: a court order to SkyeConnex Inc. can compel access logs, metadata, and a wrapped UMK. It cannot compel plaintext, because plaintext does not exist anywhere on SkyeConnex's infrastructure. The operation that would produce plaintext requires a secret the platform has never possessed.

This is what we mean by zero-knowledge by construction: it is not a policy commitment, it is a property of the architecture. Read the full explanation →

The compounding effect with multi-cloud RAID

Even if a quantum-level cryptographic break occurred against the UMK wrap, the file is still split across seven providers via Reed-Solomon. An attacker would need to compel five providers — in as many jurisdictions as the customer chose — to assemble enough shards to attempt decryption.

The combination of (a) zero-knowledge keys derived only on the client and (b) topological dispersion across providers and jurisdictions is what makes the SkyeConnex architecture an architectural solution rather than a contractual one.

When CMK is appropriate, and when it isn't

CMK is meaningfully better than provider-managed keys for many use cases. It gives you audit, rotation, and revocation control. For data that is sensitive but not subject to compelled-disclosure risk, CMK is usually sufficient.

For data subject to:

• Foreign legal-process exposure (CLOUD Act, IPA, NIL)
• Strict data-residency mandates with no exceptions
• Post-quantum migration requirements with non-repudiable proof
• Provincial / regional residency requirements that hyperscaler regions cannot guarantee

...CMK is not sufficient. The architecture needs to be zero-knowledge end-to-end.

What to ask vendors

• Does your server hold the unwrapped key, even briefly, in any operation?
• What is the API path that returns plaintext?
• Where is the wrap key derived, and what does derivation depend on?
• If compelled, can you produce plaintext? Under what conditions?

The honest answer from a CMK vendor is "we can produce plaintext when the workload's IAM principal authorises and our compute plane performs the unwrap." The honest answer from SkyeConnex is "we cannot — by construction."

If your data is exposed to compelled disclosure and you've been told CMK is enough, we should talk. 45 minutes, live on your configuration.

---

Published May 8, 2026 · Written by SkyeConnex Inc. · More from the SkyeConnex blog