3. Logical Components of a ZKS Architecture (Informative with Normative Constraints)

3.1 Reference Architecture Overview

This section defines a reference architecture model for ZKS-compliant systems. The model is technology-neutral and does not prescribe a particular implementation. Instead, it provides a common vocabulary and set of component-level constraints that can be used to design, assess, and audit systems for ZKS compliance.

A ZKS architecture is characterized by the separation of responsibilities across three conceptual planes:

• a Data Plane responsible for storing and transporting ciphertext;
• a Key Plane responsible for generating, protecting, and (where applicable) releasing decryption-relevant components; and
• a Control Plane responsible for orchestration and coordination without creating decryption capability.

Additionally, a ZKS architecture may include an Out-of-Band (OOB) Plane that provides additional user authorization signals (e.g., authenticator approvals) to protect high-assurance operations.

The reference model assumes that a ZKS-compliant deployment may involve multiple third parties in the digital supply chain (e.g., storage providers, network operators, platform vendors). ZKS compliance is achieved only if no third party can access, derive, revoke or intercept the complete set of components required to decrypt the SDO's information (given ciphertext availability), and if the user retains unilateral cryptographic, operational, and topological control as defined in Section 2.

3.2 Core Logical Components

This subsection describes the core logical components found in most ZKS architectures. The component list is not exhaustive. Implementations MAY combine components, provided that the normative constraints in Sections 3.5 and 3.6 remain satisfied.

3.2.1 Client Sovereignty Domain (CSD)

The Client Sovereignty Domain (CSD) is the set of user-controlled endpoints and execution environments in which:

• user information is created, viewed, edited, and decrypted;
• cryptographic material is generated and protected; and
• authorization decisions are enforced at the point of use.

The CSD is the primary sovereignty boundary. In a ZKS architecture, the CSD is the only domain in which decryption of user information is permitted.

The CSD typically includes one or more client devices and MAY include user-controlled hardware security modules (HSMs), Trusted Execution Environments (TEEs), or secure elements. The ZKS Standard does not mandate particular hardware, but mandates that sovereignty properties be preserved irrespective of hardware selection.

3.2.1.1 Extended Client Sovereignty Domain (Remote TEE)

A Trusted Execution Environment (TEE) hosted on third-party infrastructure (e.g., AWS Nitro Enclaves, Intel SGX, AMD SEV) constitutes an "Extended CSD" with distinct trust properties from a local CSD.

Trust Model Comparison:

Property	Local CSD	Extended CSD (Remote TEE)
Execution Confidentiality	Full (physical control)	Attested (cryptographic verification)
Availability	User-controlled	Provider-controlled
Update Authority	User-controlled	Shared (firmware vs. enclave code)
Side-Channel Resistance	Physical isolation	Implementation-dependent
Attestation	Not required	REQUIRED

Extended CSD Requirements. Systems relying on Extended CSD MUST:

1. Implement Attestation Verification: A local CSD MUST verify remote attestation before trusting Extended CSD outputs. The attestation chain MUST be validated against known-good measurements.

2. Document Trust Boundaries: Compliance assessments MUST explicitly document which operations occur in Extended CSD vs. local CSD.

3. Address Availability Dependency: Extended CSD availability depends on the infrastructure provider. Systems MUST either:

   • Provide local CSD fallback for sovereignty-critical operations, OR
   • Document availability dependency as a residual risk

4. Address Firmware Trust: TEE firmware is controlled by the infrastructure provider. Systems SHOULD document the firmware trust assumption and any mitigations.

Extended CSD and Assertion A4: Assertion A4 (No Third-Party Revocation of Decryptability - Section 7.4.2) requires that service denial does not revoke decryptability. Extended CSD hosted on third-party infrastructure may not satisfy A4 without local fallback. Systems relying solely on Extended CSD for key operations MUST implement sovereign restoration (Section 4.10) that does not depend on Extended CSD availability.

3.2.2 Ciphertext Storage Substrate (CSS)

The Ciphertext Storage Substrate (CSS) is any storage system that may persist or replicate encrypted user information (ciphertext), including:

• local storage (filesystem, local databases);
• removable media;
• NAS substrates;
• object storage systems; or
• consumer cloud storage providers.

The CSS may be operated by the user or by third parties. ZKS compliance requires that the CSS be treated as untrusted with respect to confidentiality and decryption capability.

CSS components MAY store ciphertext and limited operational metadata, subject to the metadata minimization requirements in Section 3.6. CSS components SHALL NOT be relied upon to enforce confidentiality or access control through trust; confidentiality must be enforced cryptographically.

3.2.3 Key Custody Service (KCS)

A Key Custody Service (KCS) is any service - local or external - that participates in the storage, protection, escrow, recovery, delivery, or release of decryption-relevant components.

A KCS is OPTIONAL in ZKS architectures. When present, it MUST be designed such that it does not transfer decryption capability or key material possession to a third party in a manner that violates ZKS.

This Standard distinguishes two broad, non-exclusive KCS patterns:

1. Key Delivery Services Services that temporarily store or relay wrapped key material to support asynchronous or offline device workflows. These services MUST NOT be able to reconstruct decryptability and MUST NOT retain long-term decryption-relevant secrets. A time-to-live (TTL) of 7 days or less is RECOMMENDED for ephemeral key packets, limiting the exposure window if the key delivery service is compromised. Shorter TTLs (24–72 hours) provide stronger protection but may affect usability for devices that are offline for extended periods.

2. User-Controlled Key Recovery Services (UKRS) - Key Separation Mode Services that store encrypted or wrapped key packets under explicit user control to support threat models such as endpoint compromise. Such services MUST meet strict constraints to ensure they cannot revoke decryptability or obtain the complete decryption component set. See Section 4.10 for detailed requirements.

KCS requirements and prohibited capabilities are specified normatively in Section 3.5.

3.2.4 Authorization and Policy Plane (APP)

The Authorization and Policy Plane (APP) is the logical component responsible for determining whether a sensitive operation is permitted, including:

• authorizing a device into the user's sovereignty domain;
• releasing wrapped key material from a KCS (if present);
• approving topology changes (e.g., enabling distribution models);
• approving sovereignty-affecting actions (e.g., key deletion, key rotation, or changes to key custody topology); and
• enforcing conditions that require explicit user action or multi-factor approval.

The APP may be implemented entirely within the CSD, or may include external policy services. External APP components are heavily constrained: such services MUST NOT gain decryption capability, MUST NOT possess key material, and MUST NOT create third-party revocation of decryptability. See Section 3.5.4 for normative requirements.

3.2.5 Orchestration Plane (OP)

The Orchestration Plane (OP) coordinates system operation without possessing decryptability. Typical responsibilities include:

• device discovery and pairing coordination;
• distribution of routing information needed for secure peer connectivity;
• synchronization scheduling or conflict-avoidance orchestration;
• service coordination for optional KCS operations; and
• delivery of non-sensitive system notifications.

The OP MUST be designed so that compromise of the OP does not yield any decryption-relevant components, does not permit third-party revocation of decryptability, and does not force topological constraints that undermine user sovereignty.

The OP is a coordination component that MUST NOT store user payloads (ciphertext or key material). How asynchronous delivery is achieved is implementation-specific; the constraint is that the OP itself holds only signals and metadata.

3.2.6 Identity and Recovery Mechanisms (IRM)

The Identity and Recovery Mechanisms (IRM) provide identity assertions and recovery workflows necessary to maintain operational continuity without violating sovereignty. IRM includes mechanisms such as:

• device-based enrollment and authentication;
• recovery procedures following device loss;
• administrative separation for emergency access (when applicable);
• out-of-band authorization workflows; and
• credential rotation and revocation workflows.

IRM is frequently a source of sovereignty failure in non-compliant systems (e.g., "support reset" flows that provide the provider with decryption capability). Therefore, IRM MUST be explicitly constrained by Section 3.5.6 (Identity and Recovery Mechanisms).

3.3 Planes and Channels

ZKS architectures SHALL separate concerns across planes and, where applicable, across channels, to ensure that no intermediary can access, derive, revoke, or intercept the complete set of components required to decrypt the SDO's information.

3.3.1 Data Plane

The Data Plane carries and stores ciphertext and only the metadata required to enable storage and transport. The Data Plane includes:

• ciphertext replication and synchronization;
• ciphertext persistence in the CSS; and
• ciphertext transfer between CSD instances.

ZKS requires that the Data Plane be sufficient to recover encrypted data across user-chosen topologies without granting decryptability to third parties.

3.3.1.1 Transport Layer Clarification

ZKS requirements apply to application-layer data protection, not transport-layer encryption.

Permitted Transport Operations:

• TLS termination at load balancers is permitted
• TLS termination at OP infrastructure is permitted
• Transport-layer inspection of ciphertext metadata is permitted

Requirement: The application-layer payload revealed after TLS termination MUST be ciphertext (encrypted user data), not plaintext. This is satisfied when encryption occurs in the CSD before data enters the transport layer.

Transport Flow:

1. Within the CSD: Plaintext is encrypted at the application layer, producing ciphertext
2. In transit: Ciphertext is wrapped in TLS for transport security
3. At provider infrastructure: TLS is terminated, revealing application-layer ciphertext (not plaintext)
4. Provider processing: The provider handles ciphertext only; decryption never occurs outside the CSD

This satisfies ZKS because the provider sees only ciphertext after TLS termination.

3.3.2 Key Plane

The Key Plane governs the creation, protection, distribution, and release of decryption-relevant components, including:

• generation of content keys and wrapping keys;
• storage of key material within the CSD;
• creation of wrapped key packets for distribution to authorized devices; and
• optional KCS interactions for delivery or recovery purposes.

The Key Plane MUST be designed such that no third party can access, derive, revoke, or intercept the complete set of components required to decrypt the SDO's information (given ciphertext availability).

3.3.3 Control Plane

The Control Plane governs orchestration and coordination signals that enable system functionality without exposing decryptability. It includes:

• device roster and routing coordination;
• synchronization initiation and state coordination;
• policy evaluation requests (where applicable); and
• telemetry and audit signaling, subject to Section 3.6.

The Control Plane is permitted to carry operational metadata necessary for orchestration, but MUST NOT carry decryption-relevant components in a form that enables reconstruction of decryptability by any third party.

3.3.4 Out-of-Band (OOB) Plane

The Out-of-Band (OOB) Plane carries independent authorization signals used to harden high-risk operations such as:

• releasing locked or escrowed wrapped keys;
• authorizing new devices;
• restoring sovereignty after suspected compromise; or
• approving destructive operations affecting decryptability.

The OOB Plane MAY be implemented using authenticator applications, hardware tokens, secondary devices, or other independent channels. The OOB Plane MUST be logically independent from the Data Plane and MUST NOT be co-located with ciphertext storage in a way that enables third parties to reconstruct decryptability.

The OOB Plane SHOULD be resistant to SIM-swap, SS7, and similar attacks when SMS or voice channels are used. For ZKS-Enhanced and ZKS-Enterprise compliance profiles, SMS-based OOB channels MUST be documented as a residual risk in compliance assessments. Hardware tokens or authenticator applications on independent devices are RECOMMENDED for high-assurance operations.

3.4 Trust Boundaries vs. Sovereignty Boundaries

ZKS compliance requires explicit treatment of sovereignty boundaries as distinct from general security trust boundaries.

3.4.1 Trust Boundary

A trust boundary is a boundary across which the system assumes different security properties (e.g., internal network vs. external network, privileged service vs. unprivileged service).

Trust boundaries are common in traditional architectures and often rely on administrative controls, infrastructure security, or organizational processes.

3.4.2 Sovereignty Boundary

A sovereignty boundary is a boundary across which decryptability MUST NOT be transferable. Specifically:

Inside the sovereignty boundary: The SDO and SDO-controlled components (the CSD) possess and exercise decryption capability.

Outside the sovereignty boundary: All third parties, including service providers, infrastructure operators, and intermediaries. These parties:

• MUST NOT be able to access, derive, revoke, or intercept the complete set of components required to decrypt the SDO's information (given ciphertext availability); and
• MUST NOT be able to revoke decryptability for the authorized SDO through unilateral control of key custody or release.

In a ZKS architecture, the CSD defines the primary sovereignty boundary. The CSS, OP, and any third-party KCS MUST be treated as outside the sovereignty boundary and MUST be constrained accordingly.

Sovereignty boundaries SHALL be evaluated under adversarial assumptions, including insider threat, compromise, coercion, legal compulsion, and multi-party collusion.

3.5 Required Properties per Component (Normative)

This subsection specifies minimum properties and prohibited capabilities for ZKS compliance. The requirements in this subsection are normative.

3.5.1 Client Sovereignty Domain (CSD)

A ZKS-compliant system MUST ensure that:

1. Decryption occurs only within the CSD. Third parties MUST NOT be able to cause decryption outside the CSD.
2. Decryption-relevant components are generated within the CSD or within user-controlled cryptographic modules (including TEEs) whose outputs are bound to the CSD.
3. Key material possession remains under user control. Third parties MUST NOT possess plaintext keys, master secrets, or equivalent decryption-enabling material.
4. Device authorization is sovereign. Only the user (directly or through user-defined governance mechanisms) SHALL have authority to authorize or revoke devices in the CSD. No third party SHALL possess this capability.

A ZKS-compliant system MUST NOT rely on provider-controlled secrets to maintain decryptability.

3.5.2 Ciphertext Storage Substrate (CSS)

A ZKS-compliant system MUST ensure that:

1. Ciphertext stored in the CSS is not decryptable by the CSS operator.
2. Ciphertext storage location is user-governed. The user MUST be able to relocate ciphertext substrates without provider permission that would constrain sovereignty.
3. Loss of CSS availability does not imply revocation of decryptability. A CSS operator MAY deny access (availability failure), but SHALL NOT possess the capability to revoke decryptability as defined in Section 2.2.6.

A ZKS-compliant system MUST NOT depend on any CSS operator for possession of key material or decryption-enabling secrets.

3.5.3 Key Custody Service (KCS)

If a Key Custody Service is present, a ZKS-compliant system MUST ensure that:

1. The KCS does not possess the complete set of decryption components. A KCS MUST NOT be able to access or derive the complete set of components required to decrypt, whether alone or in conjunction with the OP or CSS.

2. KCS storage is limited to wrapped or encrypted key packets such that the KCS operator cannot unwrap or derive plaintext key material.

3. KCS does not create third-party revocation of decryptability. A KCS MAY fail or deny service (availability failure). However, the system MUST be designed such that the KCS operator cannot permanently prevent an authorized user from recovering decryptability by unilateral decision. This requirement is satisfied if, and only if, the user retains a sovereign restoration pathway to restore decryptability without provider discretionary approval (e.g., local key custody, user-controlled backups, recovery seed phrase, hardware security token, or other SDO-governed recovery mechanism). See Section 4.10 for detailed requirements.

4. Release operations are user-authorized. Where a KCS participates in key release, release MUST require explicit user authorization under the APP and, where indicated by the threat model, via an independent OOB signal.

5. Provider support workflows MUST NOT introduce decryptability. Customer support, administrative override, or "recovery" workflows MUST NOT enable the provider to obtain or reconstruct decryption components.

6. KCS audit logging MUST NOT contain key material or unwrapping-sufficient metadata.

A ZKS-compliant system with a KCS MUST NOT claim compliance if the KCS operator can, as a matter of technical capability, unilaterally deny decryptability (not merely service availability) to an authorized user.

3.5.4 Authorization and Policy Plane (APP)

A ZKS-compliant system MUST ensure that:

1. Authorization decisions cannot be bypassed by third parties to obtain decryption components.
2. Policy enforcement cannot be overridden by provider administrators in a way that yields decryptability or revokes decryptability for authorized users.
3. APP compromise does not yield decryptability. If an APP component exists outside the CSD, it MUST be designed such that compromise does not provide decryption components.

3.5.5 Orchestration Plane (OP)

A ZKS-compliant system MUST ensure that:

1. The OP cannot access decryptability. Orchestration data MUST NOT include decryption components or authorization artifacts that enable reconstruction of decryptability.
2. OP compromise does not yield decryption capability and does not permit third-party revocation of decryptability.
3. OP cannot force topology. The OP MUST NOT impose a storage location, synchronization topology, or key placement model that prevents user-governed relocation and sovereign control.
4. OP cannot co-locate key and ciphertext planes. OP design MUST prevent the OP from acting as a collection point where both ciphertext and unwrapping capability can be assembled.
5. OP holds no decryption-relevant payloads. The OP MUST NOT store or forward ciphertext, wrapped keys, or any decryption-relevant artifacts. This prohibition applies regardless of whether such artifacts are encrypted, wrapped, or otherwise opaque to the OP.

Rationale: This is a topological constraint (what the OP holds), not a capability constraint (what the OP can read). Even encrypted payloads create harvest-now-decrypt-later risk if stored at the OP. The OP is limited to signaling, coordination, and metadata necessary for system operation (e.g., notifications, pointers, routing information, presence indicators).

The OP is limited to signaling, coordination, and metadata necessary for system operation (e.g., notifications, pointers, routing information, presence indicators).

Rationale: This constraint ensures the OP cannot become a collection point for decryptability components and eliminates harvest-now-decrypt-later risk from OP compromise.

3.5.6 Identity and Recovery Mechanisms (IRM)

A ZKS-compliant system MUST ensure that:

1. Identity recovery does not enable provider decryptability. Recovery workflows MUST NOT create a path for the provider to access or derive decryption components.
2. Recovery mechanisms do not transfer key material possession to third parties under the guise of supportability.
3. Delegated administration does not break sovereignty. In organizational deployments, administrators MAY manage membership, devices, and policies within the organization's sovereignty domain. However, administrators:

• MUST NOT be granted technical capability to obtain the complete set of components required to decrypt and transfer that capability to the service provider; and
• MUST NOT enable the service provider to obtain decryption capability through administrative actions.

Enterprise administrators act as agents of the organizational SDO, not as agents of the service provider. Any arrangement that grants the provider decryption capability through administrative delegation MUST be explicitly declared as outside ZKS compliance.

3.5.7 Administrative Action Integrity (AAI)

Administrative actions that affect decryptability (device authorization, recovery approval, key rotation, access delegation) represent sovereignty-sensitive operations. If performed through vendor-controlled interfaces, the vendor may capture or manipulate authorization signals.

Integrity Requirements. Administrative actions affecting decryptability MUST satisfy one of the following:

Option A: CSD-Signed Actions The action is cryptographically signed within a local CSD application (desktop or mobile) before transmission to provider infrastructure. The provider receives only the signed authorization; the signing operation occurs entirely within the CSD.

Option B: Verified Client-Side Web Application The action is performed in a web application satisfying:

• JavaScript served with Subresource Integrity (SRI) hashes
• SRI hashes published in a transparency log or verifiable manifest
• Critical cryptographic operations (signing, key derivation) occur client-side
• No sensitive material transmitted to server before client-side cryptographic protection

Option C: Out-of-Band Confirmation The action requires out-of-band confirmation via a separate CSD. For example:

• Web console initiates action
• Mobile app (separate CSD) receives confirmation request
• User approves in mobile app, which signs the authorization
• Signed authorization transmitted to complete the action

Non-Compliant Implementations:

• Web console where vendor-served JavaScript handles sensitive credentials without SRI verification
• Administrative APIs accepting unsigned authorization tokens
• "Approve" buttons in vendor-controlled interfaces without CSD signing or verified client-side execution

Disclosure Requirement: Administrative interfaces that do not satisfy these requirements MUST be documented as a potential sovereignty transfer point in compliance assessments.

3.6 Metadata Minimization Requirements (Normative)

ZKS compliance depends not only on ciphertext/key separation but also on limiting metadata that could enable third parties to infer sensitive relationships, reconstruct key release conditions, or indirectly rebuild decryptability.

A ZKS-compliant system MUST minimize and constrain metadata across all non-CSD components (CSS, OP, KCS, and intermediaries). The following requirements are normative.

3.6.1 Prohibited Metadata Capabilities

A ZKS-compliant system MUST ensure that third parties cannot, through metadata collection:

1. Derive decryptability such that the complete set of components required to decrypt becomes obtainable through correlation.

Clarification: "Reconstruction of decryption workflows" refers to the cryptographic process of combining key material and ciphertext to produce plaintext. A component that can reconstruct the decryption workflow possesses or can derive the Complete Set of Components Required to Decrypt.

This is distinct from traffic analysis, which may reveal behavioral patterns (who accessed what, when) without enabling decryption. Traffic analysis concerns are addressed in Section 3.6.1 point 4 and A7 (Metadata Minimization and Non-Correlation - Section 7.4.2).

Concern	Requirement	Section
Cryptographic workflow reconstruction	Prohibited	3.6.1 point 1
Traffic analysis / access patterns	Minimization required	3.6.1 point 4, 7.4.2 - A7

2. Infer plaintext content beyond what is unavoidable for system operation.
3. Create a de facto topology lock-in by binding ciphertext identity or structure to provider-controlled identifiers that cannot be migrated.
4. Identify which specific items a user is accessing based on key-release patterns, where such identification would enable targeted attacks.

3.6.2 Permitted Operational Metadata (Minimum Necessary)

A ZKS-compliant system MAY process the following metadata outside the CSD only to the extent strictly necessary for operation:

• opaque item identifiers (non-semantic, non-content-derived);
• ciphertext blob identifiers and sizes (as required for transport);
• routing and connectivity information required for peer establishment;
• coarse-grained state indicators (e.g., "available," "pending," "delivered") that do not disclose content or semantic relationships.

All such metadata SHOULD be:

• minimized in cardinality and retention time,
• protected in transit,
• resistant to correlation (e.g., through rotation, compartmentalization, or unlinkability techniques where feasible).

3.6.2.1 Size-Based Fingerprinting Mitigation

Ciphertext blob sizes may enable content fingerprinting through correlation with known document sizes or content types.

Recommendation: Systems SHOULD implement padding to mitigate size-based fingerprinting:

Strategy	Description	Overhead
Fixed Block Padding	Pad to fixed block sizes (e.g., 4KB, 64KB)	Low-Medium
Randomized Padding	Add random padding within a range	Medium
Content-Type Profiles	Apply padding profiles based on content type	Variable
Exponential Padding (PADMÉ)	Pad to power-of-two boundaries	Low

Disclosure Requirement: Systems that do not implement padding MUST document size correlation as a residual metadata risk in compliance assessments.

3.6.3 Logging and Audit Evidence Constraints

ZKS-compliant systems often require audit evidence for verification (see Sections 7 and 8). However, audit logging MUST NOT become a metadata side-channel that undermines sovereignty.

Therefore:

1. Logs outside the CSD MUST NOT contain decryptability-enabling material, including wrapped keys where unwrapping capability might be inferable.
2. Logs MUST NOT contain semantic identifiers such as filenames, folder names, human-readable labels, contact names, or structured content descriptors unless encrypted end-to-end and only readable within the CSD.
3. Retention policies MUST be explicit and SHOULD default to minimal retention outside the CSD.

3.6.4 Third-Party Intermediaries

Where traffic traverses third-party intermediaries (e.g., network providers, relays), ZKS compliance requires that:

• metadata exposure be minimized consistent with system function; and
• no intermediary be able to accumulate sufficient metadata to derive the complete set of components required to decrypt user information.