Resources

"Zero-Knowledge" in ZKS refers to the condition where service providers possess zero knowledge of the cryptographic components required to decrypt user data. This is distinct from "Zero-Knowledge Proofs" (ZKPs), which are a specific cryptographic primitive.

ZKS does not mandate ZKP techniques, though compliant implementations may use them. The term emphasizes that providers must not control the components necessary for decryption - not merely that they currently lack the ability to decrypt.

Critical distinction: ZKS prohibits providers from accumulating or controlling decryption components, even if those components are individually encrypted or currently unusable. The threat model includes future cryptographic advances, legal compulsion, and long-term retention risks.

End-to-end encryption (E2EE) is necessary but not sufficient for ZKS compliance. Many E2EE systems still fail ZKS because the provider retains control over components that could enable future decryptability.

Key insight: A system with E2EE can still fail ZKS if the provider holds both ciphertext and key material (even encrypted) under their control. This coexistence creates present and future decryptability risk.

No. ZKS and Zero Trust (NIST SP 800-207) are complementary, not competing:

• Zero Trust answers: "Who can access this resource?"
• ZKS answers: "Who controls the components necessary for decryption?"

Zero Trust controls access to systems and networks. ZKS ensures that even with access, providers cannot accumulate the components necessary for decryptability. A robust security architecture should implement both.

See ZKS vs. Zero Trust Architecture for detailed analysis.

ZKS is a technical standard. It defines architectural requirements and measurable compliance criteria - not legal obligations.

However, ZKS compliance may be relevant to legal requirements:

• Data protection regulations (GDPR, etc.) may recognize ZKS as a technical measure
• Contract terms may specify ZKS compliance
• ZKS provides evidence of technical controls for legal defense

Important: ZKS compliance means the provider cannot comply with decryption demands - they lack the technical capability. This is a stronger position than "we won't comply" (policy) or "it would be difficult" (practical difficulty).

Almost never. BYOK typically fails ZKS because:

1. During use: The provider possesses the key for encryption/decryption operations - violating A2
2. At rest: The provider often stores the key (encrypted) alongside the ciphertext - violating the coexistence prohibition
3. Control: The provider has operational control over when and how keys are used

Even if the customer "owns" the key, if the provider controls it during operations, ZKS is not satisfied.

To satisfy ZKS:

• Encryption/decryption must occur only in the Client Sovereignty Domain
• The provider must not hold both ciphertext and key material under their control
• If the provider holds ciphertext, they must not hold any form of key components
• If the provider holds key components (e.g., wrapped keys for delivery), they must not hold the corresponding ciphertext

Note: A Key Custody Service (KCS) MAY hold wrapped keys for delivery purposes - this is compliant provided the same party never also holds the ciphertext those keys decrypt. The Orchestration Plane (OP) must remain 'clean' per Section 3.5.5."

Some HSM-based architectures may approach compliance if the customer-controlled HSM is truly outside provider control and the provider never accesses key material. Evaluate specific implementations against the full assertion set (A1–A12).

Yes, but only with specific architectural choices that prevent coexistence of data and key components under provider control.

Compliant cloud patterns:

• Client-side encryption before upload
• Provider stores only ciphertext (no key components whatsoever)
• Keys stored separately under user control (different provider or user devices)
• User can relocate data without provider cooperation

Non-compliant cloud patterns:

• Server-side encryption (provider holds keys)
• Provider stores ciphertext AND wrapped keys (coexistence)
• "Customer-managed keys" where provider accesses keys during use
• Key escrow or recovery keys held by provider

The ZKS Test: Does the provider hold, under their control, both data and any form of key material? If yes - regardless of encryption, wrapping, or access controls - the system is non-compliant.

All profiles ensure the core sovereignty property: no provider control over decryptability components. Higher profiles add defense-in-depth measures.

1. Perform self-assessment against ZKS-1.0 Specification
2. Document evidence per Section 7 (Compliance) requirements
3. Prepare assessment report following the structure in Section 7
4. Submit for review via GitHub Pull Request
5. Working Group review - community members review submission
6. Publication - approved assessments listed in Adopters Registry

For third-party audit options, see the Working Group page.

ZKS is algorithm-neutral. The standard specifies architectural requirements, not specific cryptographic primitives.

Implementations may use any algorithms that satisfy the security properties:

• Symmetric encryption: AES-256-GCM, ChaCha20-Poly1305, etc.
• Asymmetric encryption: RSA, ECDH, Kyber (post-quantum), etc.
• Signatures: ECDSA, Ed25519, Dilithium (post-quantum), etc.
• Key derivation: HKDF, Argon2, etc.

Important: Algorithm strength does not excuse architectural violations. Even with AES-256, if the provider holds ciphertext AND wrapped keys, the system is non-compliant. The risk is not only current cryptanalysis but future advances, implementation flaws, and coercion scenarios.

Section 5.3.2 addresses cryptographic shelf-life considerations for long-term data protection.

ZKS permits key recovery mechanisms that maintain sovereignty - meaning the provider never gains control over recovery components.

Compliant recovery patterns:

• User-controlled backup (encrypted with user password, stored by user)
• Multi-device sync (keys distributed to user's devices only)
• User-Controlled Key Recovery Service (UKRS) with sovereign restoration pathway
• Split recovery where provider holds only one share (insufficient alone)

Non-compliant recovery patterns:

• Provider-held recovery keys (provider controls recovery component)
• "Support reset" that grants provider access to keys
• Recovery that requires provider cooperation to succeed
• Escrow where provider holds complete recovery capability

The critical test: If the user loses all devices, can the provider alone restore access? If yes - non-compliant (provider controls recovery).

See Section 4.10 (Key Separation Mode) and A9 (UKRS requirements) for details.

ZKS addresses metadata in A7 (Metadata Minimization and Non-Correlation):

External components MUST adhere to metadata minimization requirements and SHALL NOT accumulate metadata sufficient to derive decryption workflows or enable decryptability by correlation.

Some operational metadata is unavoidable (e.g., storage sizes, access times). The requirement is that metadata cannot:

• Enable decryption
• Reconstruct decryption workflows
• Allow correlation attacks that assemble decryptability

Important: Metadata minimization is defense-in-depth. Even with perfect metadata minimization, coexistence of data and key components under provider control is still non-compliant.

Specific metadata constraints depend on the compliance profile. ZKS-Enhanced has stricter requirements than ZKS-Core.

ZKS applies to data sovereignty, which spans the entire data lifecycle:

• At rest: Provider must not hold both ciphertext and key components
• In transit: Transport must not grant provider control over decryption components
• During processing: If processing occurs outside CSD, it must not compromise sovereignty

The focus is on who controls the components necessary for decryption, not where data is located. Data may transit through or rest on provider infrastructure, provided the provider does not accumulate control over both data and key components.

Coexistence of ciphertext and key material under provider control is non-compliant even if keys are wrapped because:

1. Future cryptographic advances - Today's wrapping may be broken tomorrow
2. Implementation vulnerabilities - Key wrapping implementations may have flaws
3. Legal compulsion - Provider may be compelled to attempt decryption or to retain data until decryption becomes possible
4. Long-term retention - Provider accumulates risk over time; "harvest now, decrypt later"
5. Operational access - Provider staff may access wrapped keys; insider threat
6. Coercion scenarios - Provider may be pressured to cooperate with sophisticated attacks

ZKS requires topological separation - the provider must not control both components, regardless of the cryptographic protection on either. If you hold the locked box AND the locked key, you're one step closer to opening it than if you hold neither.

This is why the test is "coexistence under provider control" - not "ability to decrypt today."