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 third-party control. The Data Plane, Key Plane, and Control Plane must remain strictly separated.
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 claims are testable and falsifiable, based on capability and topology properties, regardless of provider intent, policy, or assertions about decryption feasibility.
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, attacker, or other coercive mechanism to produce or release the complete set of components required to decrypt the user's information?
2. The Capability Test
Can the provider, alone or through accessible pathways, access, derive, revoke, or intercept the complete set of components required to decrypt the user's information?
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 |