ZKS Comprehensive Test Catalog
Reference Workbook for ZKS-1.0 Compliance
Version: 1.1
Status: Comprehensive Guide (Extends ZKS-1.0 Appendix D)
Standard: ZKS-1.0
Overview
This workbook defines the comprehensive conformance tests for verifying ZKS compliance. It includes:
- Normative Tests - The tests defined in ZKS-1.0 Appendix D (mandatory reference)
- Extended Tests - Additional tests recommended for thorough compliance verification
Test Categories
| Category | Code | Description |
|---|---|---|
| Structural | T-STR | Architecture and component mapping |
| Observable Behavior | T-OBS | Runtime behavior verification |
| Capability Analysis | T-CAP | Provider capability constraints |
| Revocation Boundary | T-REV | Decryptability preservation |
| Extended | T-EXT | Additional recommended tests |
Compliance Levels
| Level | Description |
|---|---|
| MUST | Required for any ZKS compliance claim |
| SHOULD | Required for ZKS-Enhanced and above |
| MAY | Recommended for ZKS-Enterprise |
Part I: Normative Tests (ZKS-1.0 Appendix D)
The following tests are defined in the normative reference table of ZKS-1.0 Appendix D. All implementations claiming ZKS compliance MUST address these tests.
Normative Reference Table
| Test ID | Test Name | Assertion/Invariant | Section Reference |
|---|---|---|---|
| T-STR-1 | Component Mapping | All | 3.2–3.4, Appendix C |
| T-STR-2 | Plane Alignment | A5, INV-3 | 3.3, 4, Appendix C |
| T-OBS-1 | Ciphertext-Only Data Plane | A1, A2 | 3.5.2, 3.6, 7.5.2 E1 |
| T-OBS-2 | OP Key-Plane Blindness | A5 | 3.5.5, 4.5, 5.3.4 |
| T-OBS-3 | KCS/UKRS Blindness | A9 | 3.5.3, 4.10, 7.4.3 |
| T-CAP-1 | Provider Infrastructure Access | A2, A3 | 7.5.2 E2, 5.3.3 |
| T-CAP-2 | Collusion Test | A3, Tenet 4 | 5.3.6, 7.5.2 E4 |
| T-CAP-3 | Opaque Enforcement Point | A12 | 6.2.4, 7.4.3 |
| T-CAP-4 | Binary Transparency Verification | A2, A3 | 5.3.1, 7.4.4, 7.5.2 |
| T-REV-1 | Availability vs Decryptability | A4, INV-4 | 2.2.6, 4.6, 5.3.2, 7.5.2 E3 |
| T-REV-2 | UKRS Denial Test | A4, A9 | 4.10, 7.4.3, 7.5.2 E3 |
Structural Tests (T-STR)
T-STR-1: Component Mapping
Requirement: The implementation MUST document all system components and their relationship to the Client Sovereignty Domain (CSD).
| Aspect | Verification |
|---|---|
| Procedure | 1. Document all system components. 2. Classify each as "Inside CSD" or "Outside CSD". 3. Map components to the reference architecture (Appendix C). 4. Verify all decryption-capable components are inside CSD. |
| Evidence | Architecture diagram with explicit boundary annotation; component inventory. |
| Pass Criteria | All components mapped; all decryption keys and engines reside exclusively within the CSD. |
| Maps To | Sections 3.2–3.4, Appendix C, All Assertions |
T-STR-2: Plane Alignment
Requirement: The implementation MUST demonstrate correct alignment of components to Data Plane, Key Plane, and Control Plane.
| Aspect | Verification |
|---|---|
| Procedure | 1. Map each component to its plane(s). 2. Identify any component spanning multiple planes. 3. Verify no external component spans both Data Plane and Key Plane. 4. Verify Orchestration Plane (OP) alignment per Section 3.5.5. |
| Evidence | Plane separation diagram; component-to-plane mapping table. |
| Pass Criteria | All components correctly aligned; no single external component spans Data Plane and Key Plane. |
| Maps To | Section 3.3, Section 4, A5, INV-3, Appendix C |
Observable Behavior Tests (T-OBS)
T-OBS-1: Ciphertext-Only Data Plane
Requirement: Transfers to the Ciphertext Storage Substrate (CSS) MUST NOT include plaintext or unwrapped keys.
| Aspect | Verification |
|---|---|
| Procedure | 1. Capture network traffic to/from CSS. 2. Audit storage logs. 3. Verify payloads are high-entropy (encrypted). 4. Confirm no plaintext or key material in Data Plane traffic. |
| Evidence | Network capture (PCAP) or storage inspection report; entropy analysis. |
| Pass Criteria | No plaintext or key material detected in Data Plane traffic. |
| Maps To | Section 3.5.2, Section 3.6, 7.5.2 E1, A1, A2 |
T-OBS-2: OP Key-Plane Blindness
Requirement: The Orchestration Plane (OP) MUST NOT observe, log, or retain key material.
| Aspect | Verification |
|---|---|
| Procedure | 1. Trigger synchronization/device-pairing events. 2. Inspect OP logs and traffic. 3. Verify OP handles only opaque references, not key content. 4. Confirm OP possesses zero cryptographic state. |
| Evidence | OP log sample; API specification; traffic analysis. |
| Pass Criteria | OP possesses zero cryptographic state; no key material in OP logs or traffic. |
| Maps To | Section 3.5.5, Section 4.5, Section 5.3.4, A5 |
T-OBS-3: KCS/UKRS Blindness
Requirement: External Key Custody Services (KCS) and User-Controlled Key Recovery Services (UKRS) MUST be cryptographically blind.
| Aspect | Verification |
|---|---|
| Procedure | 1. Audit KCS/UKRS storage format. 2. Verify keys are wrapped by KEK held only in CSD. 3. Verify KCS/UKRS has no access to unwrapping keys. 4. Confirm service cannot decrypt stored key material. |
| Evidence | Cryptographic protocol review; KCS/UKRS database schema; key wrapping analysis. |
| Pass Criteria | Service handles only wrapped/encrypted key packets; cannot unwrap. |
| Maps To | Section 3.5.3, Section 4.10, Section 7.4.3, A9 |
Capability Analysis Tests (T-CAP)
T-CAP-1: Provider Infrastructure Access
Requirement: The provider MUST NOT possess the technical capability to decrypt user data, even with full administrative access to provider infrastructure.
| Aspect | Verification |
|---|---|
| Procedure | 1. Assume root/admin access to all provider databases and servers. 2. Attempt to decrypt a specific user record. 3. Attempt to unwrap user keys using only provider-held assets. 4. Document why decryption is technically impossible. |
| Evidence | Threat model "Red Team" analysis; cryptographic proof of impossibility. |
| Pass Criteria | Provider cannot produce plaintext from held assets under any circumstance. |
| Maps To | Section 5.3.3, 7.5.2 E2, A2, A3 |
T-CAP-2: Collusion Test
Requirement: No colluding set of external parties MUST be able to derive decryptability.
| Aspect | Verification |
|---|---|
| Procedure | 1. Identify all external components (OP, CSS, KCS, etc.). 2. Combine all data accessible to external parties. 3. Analyze if the combination yields the "Complete Set of Components" for decryption. 4. Document why collusion is insufficient. |
| Evidence | Collusion analysis document; component data inventory. |
| Pass Criteria | Sum of all external knowledge < Decryptability; collusion cannot succeed. |
| Maps To | Section 5.3.6, 7.5.2 E4, A3, Tenet 4 |
T-CAP-3: Opaque Enforcement Point
Requirement: Where Policy Enforcement Points (PEPs) exist, they MUST operate on opaque (encrypted) data without access to plaintext or decryption capability.
| Aspect | Verification |
|---|---|
| Procedure | 1. Identify all Policy Enforcement Points in the architecture. 2. Verify PEPs operate only on encrypted data or metadata. 3. Confirm PEPs have no access to decryption keys. 4. Verify policy decisions do not require plaintext inspection. |
| Evidence | PEP architecture documentation; data flow analysis showing opacity. |
| Pass Criteria | All PEPs operate without plaintext access; enforcement based on metadata or encrypted attributes only. |
| Maps To | Section 6.2.4, Section 7.4.3, A12 |
T-CAP-4: Binary Transparency Verification
Requirement: The system MUST ensure that all distributed client binaries are recorded in a public, append-only transparency log, and the client software MUST verify its own inclusion in this log to prevent targeted, unlogged malicious updates.
| Aspect | Verification |
|---|---|
| Procedure | 1. Log Inspection: Access the declared public transparency log and verify it is accessible and structurally sound (append-only). 2. Inclusion Check: Hash the currently deployed client binary. Query the log to verify that this specific hash is present. 3. Client Verification Logic Test: In a test environment, deploy a modified or "dummy" update binary that is not submitted to the log. Attempt to force the client to update to or run this binary. 4. Targeted Attack Simulation: Block the client's access to the log server (or return a fake response) and verify: - The client refuses to install or update to any new binary - The client MAY continue operating with its current verified binary - The client SHOULD alert the user to the verification failure. |
| Evidence | URL of the public log; Cryptographic inclusion proofs for current releases; Network captures showing the client performing the verification lookup; Client logs showing rejection of unverified binaries. |
| Pass Criteria | 1. The specific binary hash is found in the public log. 2. The client refuses to install or execute any binary that lacks a valid inclusion proof. 3. The log infrastructure is append-only with cryptographic integrity guarantees. Witness cosigning is RECOMMENDED for enhanced tamper resistance. |
| Note | For multi-platform deployments, all platform-specific binaries (Windows, macOS, Linux, mobile) MUST be independently logged and verified. |
| Maps To | Section 5.3.1, 7.5.2 (E1/E4) |
Revocation Boundary Tests (T-REV)
T-REV-1: Availability vs Decryptability
Requirement: Service denial (Availability Failure) MUST NOT revoke decryptability for data already held by the user.
| Aspect | Verification |
|---|---|
| Procedure | 1. Ensure user has local copies of ciphertext and keys. 2. Disconnect CSD from internet (simulate total provider outage). 3. Attempt to decrypt locally cached ciphertext. 4. Verify decryption succeeds without any provider contact. |
| Evidence | "Unplugged" test video or log; offline decryption demonstration. |
| Pass Criteria | Decryption succeeds without calling home; availability ≠ decryptability. |
| Maps To | Section 2.2.6, Section 4.6, Section 5.3.2, 7.5.2 E3, A4, INV-4 |
T-REV-2: UKRS Denial Test
Requirement: Denial of UKRS service MUST NOT permanently revoke decryptability if the user possesses sovereign restoration artifacts.
| Aspect | Verification |
|---|---|
| Procedure | 1. Ensure user has sovereign restoration artifacts (backup, mnemonic, recovery key). 2. Delete local keys from all devices. 3. Simulate UKRS denial ("Account Suspended" or service unavailable). 4. Execute Sovereign Restoration using only user-held artifacts. 5. Verify full functionality restored with zero provider cooperation. |
| Evidence | Independent restoration test results; step-by-step documentation. |
| Pass Criteria | User can restore full decryptability solely from user-held artifacts. |
| Maps To | Section 4.10, Section 7.4.3, 7.5.2 E3, A4, A9, Appendix B |
Part II: Extended Tests (Recommended)
The following tests extend the normative catalog with additional verification procedures. These tests are RECOMMENDED for comprehensive compliance assessment but are not part of the normative Appendix D.
Extended tests use the prefix T-EXT followed by the category code.
Extended Structural Tests (T-EXT-STR)
T-EXT-STR-1: Sovereignty Boundary Identification
Requirement: The implementation SHOULD explicitly document the sovereignty boundary with formal definition.
| Aspect | Verification |
|---|---|
| Procedure | 1. Define the precise sovereignty boundary. 2. Document trust assumptions at the boundary. 3. Identify all crossing points (data flows across boundary). |
| Evidence | Sovereignty boundary specification document. |
| Pass Criteria | Boundary clearly defined; all crossings documented and justified. |
| Extends | T-STR-1 (Component Mapping) |
T-EXT-STR-2: Component Classification & Exposure
Requirement: All external components SHOULD have explicit data exposure classifications.
| Aspect | Verification |
|---|---|
| Procedure | For each external component, document exactly what data types (ciphertext, metadata, wrapped keys) it handles and under what conditions. |
| Evidence | Component exposure matrix. |
| Pass Criteria | All exposures documented; no unexpected data handling. |
| Extends | T-STR-1, T-STR-2 |
T-EXT-STR-3: Coexistence Analysis
Requirement: The implementation SHOULD demonstrate that no provider-controlled infrastructure holds both ciphertext and key material.
| Aspect | Verification |
|---|---|
| Procedure | 1. For each storage location, document what is stored. 2. Identify any coexistence of data types. 3. Verify separation is maintained across all provider components. |
| Evidence | Storage inventory with data classification; coexistence analysis. |
| Pass Criteria | No provider storage contains both ciphertext AND any form of key material. |
| Extends | T-CAP-1, Tenet 3 |
Extended Observable Behavior Tests (T-EXT-OBS)
T-EXT-OBS-1: Metadata Exposure Audit
Requirement: External components SHOULD NOT accumulate metadata enabling derivation of decryptability.
| Aspect | Verification |
|---|---|
| Procedure | 1. Document all metadata visible to each external component. 2. Analyze correlation potential across components. 3. Verify metadata minimization controls. |
| Evidence | Metadata inventory; logging configuration audit. |
| Pass Criteria | No component accumulates sufficient metadata to derive decryption capability. |
| Extends | A7, INV-6 |
T-EXT-OBS-2: Decryption Location Verification
Requirement: All decryption operations SHOULD be verified to occur exclusively within the CSD.
| Aspect | Verification |
|---|---|
| Procedure | 1. Trace all decryption code paths. 2. Verify execution location for each path. 3. Confirm no decryption occurs on provider infrastructure. |
| Evidence | Code audit; execution trace analysis. |
| Pass Criteria | All decryption code paths execute within CSD. |
| Extends | T-OBS-1, A1 |
Extended Capability Analysis Tests (T-EXT-CAP)
T-EXT-CAP-1: Coercion Resistance Assessment
Requirement: The implementation SHOULD document provider capability under legal compulsion scenarios.
| Aspect | Verification |
|---|---|
| Procedure | 1. Analyze provider capability under subpoena/court order. 2. Document what provider can and cannot produce. 3. Verify technical impossibility of compliance with decryption demands. |
| Evidence | Coercion analysis document; legal-technical review. |
| Pass Criteria | Provider cannot produce plaintext even if legally compelled. |
| Extends | T-CAP-1, Section 5.2.3, Tenet 2 |
T-EXT-CAP-2: Future Decryptability Analysis
Requirement: The implementation SHOULD assess "Harvest Now, Decrypt Later" risk.
| Aspect | Verification |
|---|---|
| Procedure | 1. Analyze what provider retains over time. 2. Assess risk if current cryptography is broken in future. 3. Document retention policies and cryptographic shelf-life. |
| Evidence | Retention analysis; cryptographic shelf-life assessment. |
| Pass Criteria | Provider retention policies minimize long-term accumulation risk. |
| Extends | T-CAP-1, Section 5.3.2, Tenet 3 |
T-EXT-CAP-3: Component Control Analysis
Requirement: The implementation SHOULD document control relationships for all components handling sensitive data.
| Aspect | Verification |
|---|---|
| Procedure | 1. For each component, determine who controls it. 2. Document what each controlled component holds. 3. Verify no single controller has both ciphertext and key material. |
| Evidence | Control matrix. |
| Pass Criteria | No single party controls components containing both ciphertext AND key material. |
| Extends | T-CAP-2, Tenet 3, A2, A3 |
Extended Revocation Boundary Tests (T-EXT-REV)
T-EXT-REV-1: Provider Termination Resilience
Requirement: The implementation SHOULD remain functional if the provider ceases operations.
| Aspect | Verification |
|---|---|
| Procedure | 1. Analyze user capability if provider terminates business. 2. Document dependencies on provider services. 3. Verify user retains all keys and data access. |
| Evidence | Continuity/Exit Plan analysis. |
| Pass Criteria | User retains full decryptability after provider termination. |
| Extends | T-REV-1, T-REV-2, A4 |
T-EXT-REV-2: Topology Independence
Requirement: Users SHOULD be able to relocate data without provider permission.
| Aspect | Verification |
|---|---|
| Procedure | 1. Export ciphertext from current storage. 2. Migrate to alternative storage (different provider or local). 3. Verify decryption still works without re-encryption. |
| Evidence | Migration test results. |
| Pass Criteria | User can relocate all data without provider cooperation or re-encryption. |
| Extends | A6, INV-5 |
Part III: Profile-Specific Tests
ZKS-Enhanced Requirements
| Test ID | Requirement | Procedure & Verification |
|---|---|---|
| T-ENH-1 | Update Transparency | Procedure: Verify that client software updates are logged in a public transparency log or use multi-party signing. Pass Criteria: Malicious updates cannot be targeted at specific users without detection. |
| T-ENH-2 | Metadata Minimization | Procedure: Audit all external logs. Pass Criteria: Logs contain NO semantic identifiers (e.g., filenames, contact names) even in encrypted form if correlation is possible. |
| T-ENH-3 | Binary Integrity | Procedure: Verify that the client binary is reproducible or cryptographically verifiable against the public manifest. Pass Criteria: User can independently verify the running code matches the published source/release. |
ZKS-Enterprise Requirements
| Test ID | Requirement | Procedure & Verification |
|---|---|---|
| T-ENT-1 | Split Topology | Procedure: Verify that CSS (Storage) and OP (Signal) are operated by distinct legal/technical entities. Pass Criteria: No single provider sees both traffic streams. |
| T-ENT-2 | Enterprise Delegation | Procedure: Test admin workflows. Pass Criteria: Enterprise admins can manage access policies but CANNOT decrypt user data or impersonate users to obtain keys. |
| T-ENT-3 | On-Premise Option | Procedure: Verify availability of self-hosted Key/Control plane components. Pass Criteria: Organization can host critical sovereignty components internally. |
| T-ENT-4 | Independent Auth | Procedure: Verify that Key Recovery requires authentication independent of the primary IdP (e.g., separate OOB token). Pass Criteria: Compromise of primary corporate IdP does not yield decryptability. |
Part IV: Test Evidence Requirements
Documentation Requirements
| Evidence Type | Description | Required For |
|---|---|---|
| Architecture Diagram | Sovereignty boundary and component mapping | All (T-STR-1) |
| Plane Separation Diagram | Data/Key/Control plane mapping | All (T-STR-2) |
| Threat Analysis | Provider capability and collusion analysis | All (T-CAP-1, T-CAP-2) |
| Protocol Specification | Key management and encryption protocols | All |
| API Documentation | External service interfaces | All |
| Test Results | Execution of T-REV tests | All (T-REV-1, T-REV-2) |
Attestation Requirements
| Attestation | Description | Required For |
|---|---|---|
| Self-Assessment | Vendor attestation of compliance | ZKS-Core |
| Peer Review | Working Group member review | ZKS-Enhanced |
| Third-Party Audit | Independent security assessment | ZKS-Enterprise |
Part V: Test Result Classification
Pass/Fail Criteria
| Result | Meaning |
|---|---|
| PASS | Requirement fully satisfied. |
| CONDITIONAL | Satisfied with documented constraints (must be disclosed). |
| FAIL | Requirement not satisfied (non-compliant). |
| N/A | Requirement not applicable (e.g., no KCS/UKRS used). |
Conditional Pass Requirements
A CONDITIONAL pass requires:
- Clear documentation of the constraint
- Explanation of why full compliance is not achieved
- Assessment that the constraint does not undermine sovereignty
- User disclosure of the limitation
Part VI: Compliance Determination
Minimum Requirements
| Profile | Pass Requirements |
|---|---|
| ZKS-Core | All normative tests (T-STR, T-OBS, T-CAP, T-REV) pass; no FAIL on any assertion |
| ZKS-Enhanced | ZKS-Core + all T-ENH tests pass |
| ZKS-Enterprise | ZKS-Enhanced + all T-ENT tests pass |
Non-Compliance Indicators
Any of the following results in immediate non-compliance:
| Indicator | Test Reference |
|---|---|
| Provider can decrypt user data | T-CAP-1 FAIL |
| Collusion enables decryptability | T-CAP-2 FAIL |
| PEPs have plaintext access | T-CAP-3 FAIL |
| Unlogged binaries accepted by client | T-CAP-4 FAIL |
| Service denial revokes decryptability | T-REV-1 FAIL |
| No sovereign restoration pathway | T-REV-2 FAIL |
| Components not properly mapped | T-STR-1 FAIL |
| Plane separation violated | T-STR-2 FAIL |
Appendix: Test ID Quick Reference
Normative Tests (ZKS-1.0 Appendix D)
| Test ID | Test Name | Category |
|---|---|---|
| T-STR-1 | Component Mapping | Structural |
| T-STR-2 | Plane Alignment | Structural |
| T-OBS-1 | Ciphertext-Only Data Plane | Observable Behavior |
| T-OBS-2 | OP Key-Plane Blindness | Observable Behavior |
| T-OBS-3 | KCS/UKRS Blindness | Observable Behavior |
| T-CAP-1 | Provider Infrastructure Access | Capability Analysis |
| T-CAP-2 | Collusion Test | Capability Analysis |
| T-CAP-3 | Opaque Enforcement Point | Capability Analysis |
| T-CAP-4 | Binary Transparency Verification | Capability Analysis |
| T-REV-1 | Availability vs Decryptability | Revocation Boundary |
| T-REV-2 | UKRS Denial Test | Revocation Boundary |
Extended Tests (Recommended)
| Test ID | Test Name | Extends |
|---|---|---|
| T-EXT-STR-1 | Sovereignty Boundary Identification | T-STR-1 |
| T-EXT-STR-2 | Component Classification & Exposure | T-STR-1, T-STR-2 |
| T-EXT-STR-3 | Coexistence Analysis | T-CAP-1 |
| T-EXT-OBS-1 | Metadata Exposure Audit | A7 |
| T-EXT-OBS-2 | Decryption Location Verification | T-OBS-1 |
| T-EXT-CAP-1 | Coercion Resistance Assessment | T-CAP-1 |
| T-EXT-CAP-2 | Future Decryptability Analysis | T-CAP-1 |
| T-EXT-CAP-3 | Component Control Analysis | T-CAP-2 |
| T-EXT-REV-1 | Provider Termination Resilience | T-REV-1, T-REV-2 |
| T-EXT-REV-2 | Topology Independence | A6 |
Profile-Specific Tests
| Test ID | Test Name | Profile |
|---|---|---|
| T-ENH-1 | Update Transparency | ZKS-Enhanced |
| T-ENH-2 | Metadata Minimization | ZKS-Enhanced |
| T-ENH-3 | Binary Integrity | ZKS-Enhanced |
| T-ENT-1 | Split Topology | ZKS-Enterprise |
| T-ENT-2 | Enterprise Delegation | ZKS-Enterprise |
| T-ENT-3 | On-Premise Option | ZKS-Enterprise |
| T-ENT-4 | Independent Auth | ZKS-Enterprise |
This catalog is a comprehensive guide supporting the normative ZKS-1.0 Standard. Part I reproduces the normative test table from Appendix D for convenience. Parts II–VI provide extended guidance for thorough compliance assessment.