Operative Definition
"In a ZKS architecture, no third party - including the service provider - possesses the technical capability to access, derive, revoke, or intercept the complete set of components required to decrypt the user's information."
ZKS-1.0-RC1 Section 2.1|Invariant: Kp ⊂ D
1. Topological Independence
Data and key material must never coexist under provider control in a manner that enables present or future reconstruction of decryptability. ZKS mandates strict plane separation between the Data Plane, Key Plane, and Control Plane.
2. Unilateral Control
Users must be able to relocate data and key materials, and revoke access unilaterally - without provider permission or cooperation. Any provider capability to revoke user decryptability is a sovereignty failure.
3. Falsifiable Security
Compliance is capability-based, not intent-based. If a provider possesses the technical capability to decrypt user data - or can be compelled to do so - they are not ZKS compliant, regardless of provider policy or their claim to impracticality.
The ZKS Compliance "Litmus Test"
A system is Non-Compliant if either of the following conditions is met:
1. The Subpoena Test
Can the provider be compelled by a court or attacker to produce the complete set of components required to obtain the plaintext?
2. The Capability Test
Can the provider reconstruct decryptability by combining what they hold or can access?
How ZKS Relates to Other Standards
| Framework | Primary Concern | Relationship to ZKS |
|---|---|---|
| Zero Trust (NIST 800-207) | Access Control | Complementary - ZT controls who accesses; ZKS controls who can decrypt |
| BYOK / HYOK / DKE | Key Management | Often insufficient - key possession ≠ decryptability control |
| E2E Encryption | Content Confidentiality | Necessary but not sufficient - ZKS adds topology, revocation, metadata |
| Confidential Computing | Processing Security | Defense in depth - CC protects compute; ZKS protects storage and control |