5. Threats and Risks Associated with ZKS (Normative)

5.1 Purpose and Scope

This section specifies a normative threat and risk taxonomy applicable to Zero-Knowledge Sovereignty (ZKS) architectures. It defines adversarial objectives, attack surfaces, and failure modes that are relevant to determining whether a system satisfies the ZKS definition in Section 2.1 and the component constraints in Section 3.

This section is normative for the following reasons:

1. ZKS is a capability-based standard. Threat analysis in ZKS is not optional narrative; it defines the adversarial conditions under which capability claims are evaluated.
2. ZKS compliance requires resistance not only to direct compromise, but to multi-intermediary correlation and collusion (Tenet 4) and to sovereignty-specific failure modes such as revocation of decryptability (Section 2.2.6).
3. The threats enumerated herein directly determine the conformance assertions and evidence requirements specified in Sections 7 and 8 and in Appendix D.

Accordingly, an implementation that claims ZKS compliance SHALL demonstrate that the system's architecture and operational model constrain third parties such that the threats below cannot yield a sovereignty failure, as defined in this Standard.

5.2 Threat Model and Adversary Classes

5.2.1 Adversarial Objective

For the purposes of ZKS, the adversary's primary objective is to cause a sovereignty failure by achieving any of the following (given ciphertext availability):

• accessing, deriving, or intercepting the complete set of components required to decrypt user information (Section 2.2.2); or
• acquiring the technical capability to revoke decryptability for an authorized user (Section 2.2.6).

Secondary objectives include:

• forcing topological constraints that prevent user relocation of ciphertext substrates (Section 2.2.5);
• inducing decryption outside the Client Sovereignty Domain (CSD) (Section 3.2.1);
• correlating metadata to infer sensitive relationships, workflows, or content characteristics beyond minimum operational necessity (Section 3.6).

5.2.2 Adversary Classes (Non-Exhaustive)

A ZKS-compliant system SHALL be evaluated under the assumption that any of the following adversaries may exist, act concurrently, and collude:

1. Service Provider Adversary The vendor or service provider operating orchestration, support, key-related, or ancillary services. This adversary may be malicious, coerced, compromised, or negligent.

2. Intermediary Adversary Any party in the digital supply chain, including network operators, cloud infrastructure vendors, storage providers, relay services, platform vendors, and managed security services.

3. Insider Adversary Privileged insiders within a service provider, intermediary, or user organization (e.g., administrators, operators, support personnel).

4. Endpoint Compromise Adversary Adversaries capable of compromising a user device's OS, application runtime, or user-space processes.

5. Supply-Chain Adversary Adversaries capable of inserting malicious updates, compromised dependencies, or malicious firmware into the software/hardware supply chain. Mitigations include SBOM (Software Bill of Materials), reproducible builds, and binary transparency.

6. Coercion / Compulsion Adversary Adversaries able to compel a provider or intermediary to disclose or manipulate data, metadata, or operational controls through legal or extra-legal means.

ZKS does not assume benevolent providers. Compliance is determined by whether third parties lack the technical capability to produce sovereignty failures.

5.3 Threat Categories and Sovereignty Failure Modes

The threat categories below are expressed as capability paths. A ZKS-compliant architecture MUST be designed such that these paths cannot yield a sovereignty failure.

5.3.1 Sovereignty Boundary Subversion (CSD Compromise)

Threat Description.

1. Adversaries compromise one or more components within the Client Sovereignty Domain (CSD), including the cryptographic engine (TEE/HSM/soft-token), local key storage, runtime memory, or authorization logic.
2. Malicious Updates: The vendor or a compromised build pipeline introduces logic into the authorized client software that exfiltrates keys or bypasses sovereignty controls.

Relevance to ZKS.

ZKS does not claim to prevent endpoint compromise. However, ZKS imposes three critical constraints:

1. Endpoint compromise MUST NOT enable third parties outside the sovereignty boundary (CSS, OP, KCS, IRM, intermediaries) to obtain decryptability for other devices or users unless the SDO explicitly authorizes such sharing through defined governance mechanisms.
2. Endpoint compromise MUST NOT be leveraged through external services to create a persistent provider capability to revoke decryptability or derive decryptability across the user's domain.
3. Update Authority is not Absolute: A malicious update effectively constitutes a vendor-authorized compromise of the CSD. If the vendor can arbitrarily modify the CSD logic to exfiltrate keys without detection, the sovereignty boundary is illusory. Therefore, ZKS requires that the update mechanism itself be constrained by transparency or multi-party authorization.

Normative Requirements (Derived).

• Systems MUST prevent external components from becoming amplifiers of endpoint compromise (e.g., provider-side key recovery that yields decryptability after a single device is compromised).

• Key separation modes (Section 4.10) MAY be used to reduce the impact of endpoint compromise, but MUST preserve ZKS invariants.

• Update Consistency and Transparency: The system MUST NOT rely solely on opaque vendor discretion for code integrity. Mechanisms MUST be employed to ensure that the vendor cannot target specific users with malicious updates without detection.

• All Profiles (ZKS-Core, ZKS-Enhanced, ZKS-Enterprise): Systems MUST implement Binary Transparency satisfying the following:

  1. Public Log: All release artifacts MUST be logged to a public, append-only transparency log before distribution.
  2. Hash Publication: Cryptographic hashes of all distributed binaries MUST be published to the log.
  3. Client Verification: Client software MUST verify its own binary hash against the transparency log, either at startup or update time.
  4. Witness Cosigning (RECOMMENDED): Transparency logs SHOULD employ independent witness cosigning to prevent log tampering.

• ZKS-Enhanced and ZKS-Enterprise (Additional): Systems SHOULD additionally implement reproducible builds enabling independent binary verification.

Rationale: Without Binary Transparency, a provider can push a targeted malicious update to a single user without detection. This grants the provider deferred decryption capability through the attack sequence:

• T0: System is compliant
• T1: Provider pushes targeted malicious update
• T2: Compromised CSD exfiltrates keys

Binary Transparency ensures any distributed binary is publicly logged, making targeted attacks detectable.

Acceptable Implementations (non-exhaustive):

Implementation	Description
Sigsum	Witness-cosigned transparency log
Custom Log + Witnesses	Append-only log with independent witness verification
Certificate Transparency Model	Adapted CT infrastructure for binaries

Non-Compliant Implementations:

• Automatic updates without public hash logging
• Updates signed only by vendor key without transparency log
• Hash publication without append-only guarantees
• "Trust us" attestations without verifiable evidence

Common Sovereignty Failures.

• Provider-hosted recovery workflows that allow reconstruction of keys after device compromise.
• Orchestration services that can push "rekey" or "device reset" operations that result in provider-influenced decryptability.
• Automatic update mechanisms that allow the vendor to target specific users with non-public, backdoored binaries (e.g., "Targeted Malice") that differ from the standard release.

5.3.2 Revocation Attacks: Decryptability vs Availability

Threat Description.

A third party attempts to deny the user access to their data or to permanently prevent decryptability, either by service action (account suspension), technical action (withholding key release), or destructive action (deleting key material).

ZKS Distinction (Normative).

• Revocation of availability is permitted as a service failure (e.g., denial of access to CSS accounts, denial of access to OP endpoints).
• Revocation of decryptability is prohibited as a sovereignty failure (Section 2.2.6), given ciphertext availability.

Edge Case Clarification: If a UKRS operator deletes wrapped key packets AND the user has lost their sovereign restoration artifact, this is an availability failure compounded by user responsibility (failure to maintain backup), not a sovereignty failure, provided the system design required and documented the sovereign restoration pathway.

Normative Requirements (Derived).

• If an optional Key Custody Service or User-Controlled Key Recovery Service is used (Sections 3.2.3 and 4.10), the system MUST provide a sovereign restoration pathway as required by INV-4.10-D, typically via a secondary user-held recovery artifact independent of the service.
• External entities MUST NOT possess kill-switch capability for decryptability.

Common Sovereignty Failures.

• Cloud-only recovery services where the vendor holds the only wrapped key packets.
• Administrative override pathways where support personnel can prevent key release permanently.
• "Account deletion" routines that delete decryption-relevant components rather than merely ciphertext replicas.

Availability vs. Sovereignty Distinction

Sovereignty (decryptability given ciphertext) is logically distinct from availability (ciphertext existence). ZKS guarantees sovereignty; it does not guarantee availability.

Property	Definition	ZKS Guarantee
Sovereignty	User can decrypt if ciphertext is available	YES
Availability	Ciphertext exists and is accessible	NO (storage-dependent)

Practical Implication: If a provider deletes ciphertext, the user loses access to their data — not because sovereignty was revoked, but because there is nothing to decrypt. This is an availability failure, not a sovereignty failure.

Mitigation Guidance. Systems using External CSS SHOULD provide:

1. User-Accessible Export: Capability to export ciphertext to user-controlled storage
2. Replication Option: Capability to mirror ciphertext to secondary storage
3. Deletion Notification: Advance notice before provider-initiated deletion

Disclosure Requirement: Systems that store ciphertext solely on provider infrastructure MUST disclose that provider data deletion results in permanent data loss regardless of sovereignty status.

5.3.3 Key Custody Failure Modes and Key-Plane Attacks

Threat Description.

Adversaries target the Key Plane to obtain, reconstruct, derive, or intercept decryption-relevant components, including through:

• weak entropy generation or poor randomness;
• side-channel leakage from TEEs or soft-token implementations;
• key derivation weaknesses, including insufficient key stretching for password-derived keys;
• insecure key wrapping; or
• key distribution workflows that allow correlation or interception.

Relevance to ZKS.

ZKS is algorithm-neutral, but not quality-neutral. If cryptographic mechanisms enable third parties to derive keys or reconstruct decryptability, the system fails ZKS (Section 1.1 and Section 2.2.2).

Normative Requirements (Derived).

• A ZKS-compliant system MUST ensure that third parties cannot access, derive, or intercept the complete decryption component set through Key Plane weaknesses.
• Components outside the CSD MUST remain cryptographically blind to unwrapping capability, regardless of whether they store opaque or wrapped artifacts.

Common Sovereignty Failures.

• Provider-controlled key derivation inputs (e.g., server-supplied secrets required for key derivation).
• Re-encryption proxy models where the intermediary temporarily holds unwrapped keys or plaintext.
• Key delivery systems that retain key packets with stable correlators enabling later assembly of decryptability.

5.3.4 Orchestration Plane (OP) Collection and Key–Data Correlation

Threat Description.

An adversary uses the Orchestration Plane to correlate device identities, item identifiers, synchronization events, and delivery artifacts in order to:

• infer sensitive metadata (privacy erosion), and/or
• enable assembly of decryptability by combining correlated observations with other intermediaries (sovereignty erosion under Tenet 4).

Normative Requirements (Derived).

• Cryptographic Blindness: The OP MUST be blind with respect to the Key Plane. The OP MUST NOT store wrapped key packets or ciphertext—only opaque delivery references (pointers/notifications). Asynchronous delivery of key material MUST use components designated for that purpose (KCS), not the OP. The OP MUST NOT possess any cryptographic state (e.g., unwrapping keys or ephemeral private scalars).

• The OP MUST NOT be a collection point where ciphertext identifiers and key release artifacts can be co-located or correlated in a manner that yields decryptability.

Common Sovereignty Failures.

• OP logs containing wrapped keys and stable item identifiers.
• Telemetry pipelines exporting correlatable identifiers to third-party analytics vendors.
• Centralized orchestration combined with centralized ciphertext substrate under the same operator without appropriate minimization and separation controls.

5.3.5 Metadata Correlation and Traffic Analysis

Threat Description.

Adversaries correlate metadata across planes and intermediaries to infer:

• user relationships and social graphs;
• sensitive item semantics (e.g., document types, user activity patterns);
• key release conditions and workflows; or
• the set of devices participating in the sovereignty domain.

While this may not directly yield decryptability, it can facilitate targeted attacks that lead to sovereignty failure.

Normative Requirements (Derived).

• External components MUST adhere to Section 3.6 metadata minimization constraints.
• Systems SHOULD implement unlinkability techniques where feasible (identifier rotation, compartmentalization, minimization of stable correlators).
• Systems MUST ensure that metadata does not become a substitute for key custody, i.e., does not enable reconstruction of decryption workflows.

Common Sovereignty Failures.

• Human-readable filenames stored outside the CSD.
• Stable, content-derived identifiers used by OP and CSS.
• Centralized logging that ties key-related events to ciphertext storage paths.

5.3.6 Split Topology and Collusion Resistance

Threat Description.

Intermediaries collude (or are compelled to cooperate) such that the combination of their data yields more capability than each individually. The canonical example is correlation between:

• ciphertext traffic and storage metadata (CSS), and
• synchronization/coordination metadata (OP).

Normative Requirements (Derived).

• ZKS compliance MUST hold under plausible collusion assumptions (Tenet 4).
• Split Topology, where CSS and OP operators are distinct entities, strengthens compliance and reduces correlated observability, but is not mandatory for ZKS-Core. If CSS and OP are operated by the same entity, the system MUST demonstrate alternative controls sufficient to prevent assembly of decryptability and to minimize correlation.
• ZKS-Enterprise: Systems SHOULD implement split topology OR document compensating controls with equivalent assurance.

Common Sovereignty Failures.

• Single provider operating OP, CSS, and KCS, yielding de facto centralization.
• Provider-operated KCS combined with OP correlation enabling targeted suppression of key release (revocation of decryptability).

5.3.7 Device Loss, Theft, Coercion, and Local Extraction

Threat Description.

Adversaries obtain physical access to devices or coerce users to unlock devices, aiming to extract keys or decrypt data.

Relevance to ZKS.

These threats primarily affect endpoint security and user safety. ZKS constrains third-party capability but does not eliminate the risk of local extraction. Key separation modes (Section 4.10) exist specifically to mitigate local extraction and ring-0 compromise scenarios by separating key custody from endpoints.

Normative Requirements (Derived).

• If a system claims support for key separation, it MUST implement User-Controlled Key Recovery Services in a manner that preserves sovereign restoration and does not introduce provider revocation of decryptability.
• OOB approvals SHOULD be used for key release when the threat model includes coercion or device theft.

Common Sovereignty Failures.

• Recovery mechanisms that allow a provider to bypass user authorization after device theft.
• Device enrollment procedures that allow silent reauthorization by a vendor.

5.3.8 Insider Threat and Administrative Abuse

Threat Description.

Privileged administrators - within the vendor, intermediaries, or within an organization - attempt to obtain decryptability or to revoke decryptability.

ZKS Governance Position (Normative).

• Internal enterprise delegation is permitted within the user's sovereignty domain (Section 3.5.6 and Section 4.7).
• Delegation to the vendor or external intermediaries in a manner that grants decryptability is prohibited.

Normative Requirements (Derived).

• Enterprise governance systems MUST preserve the sovereignty boundary: administrators may manage devices and policies but MUST NOT grant decryptability to third parties.
• Provider support and administrative workflows MUST NOT create bypass paths to key release or key derivation.

Common Sovereignty Failures.

• Vendor-admin "break glass" access that can decrypt or release keys.
• Helpdesk reset flows that regenerate keys or rewrap keys under provider influence.

5.3.9 Vendor Lock-In, Portability, and Format Dependency

Threat Description.

Vendor-controlled formats, opaque schemas, and proprietary key-wrapping schemes can create practical relocation constraints, undermining topological sovereignty (Section 2.2.5) even if ciphertext is nominally user-controlled.

Normative Requirements (Derived).

• ZKS-compliant systems MUST permit ciphertext substrate relocation without requiring proprietary provider permission or tooling that effectively prevents migration.
• Systems SHOULD support export and portability mechanisms sufficient to avoid de facto custody by lock-in.
• Export mechanisms SHOULD produce outputs in documented, non-proprietary formats to ensure long-term accessibility.

Common Sovereignty Failures.

• Encryption formats tied to provider-controlled identifiers.
• Key recovery artifacts stored only in provider-managed services.
• Export mechanisms that require provider-side transformation.

5.4 Summary of Sovereignty Failure Conditions

The following are non-exhaustive but SHALL be treated as prima facie indicators of non-compliance:

1. Any third party can decrypt user data or can induce decryption outside the CSD.
2. Any third party possesses or can access, derive, or intercept the complete set of components required to decrypt user information (given ciphertext availability).
3. Any third party can revoke decryptability for an authorized user, including through withholding the only key recovery artifact or through provider-controlled key release mechanisms.
4. Any architecture uses unblinded server-side re-encryption proxies or key wrapping workflows where an intermediary temporarily holds plaintext or unwrapped keys during the cryptographic operation. Zero-Knowledge Proxy Re-Encryption schemes that demonstrably preserve cryptographic blindness are permitted.
5. Any orchestration or logging system creates a collection point where ciphertext identity and key-related artifacts can be correlated sufficiently to assemble decryptability.
6. Any recovery workflow provides provider support personnel with a bypass capability to key release or key reconstruction.
7. Any architecture imposes vendor-controlled topology constraints that prevent SDO relocation of ciphertext substrates.

These conditions are used to derive the conformance criteria in Sections 7 and 8 and the conformance tests in Appendix D.