var img = document.createElement('img'); img.src = "https://analytics.zks-standard.org/matomo.php?idsite=1&rec=1&url=https://zks-standard.org" + location.pathname; img.style = "border:0"; img.alt = "tracker"; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(img,s);
Skip to main content
Version: 1.0-RC2 / RELEASE CANDIDATE

Appendix F - Security and Privacy Considerations (Informative)

This appendix consolidates the security and privacy considerations that apply to ZKS-compliant systems, including the residual risks that ZKS deliberately does not claim to eliminate. Most of this material summarizes and cross-references normative requirements and limitations stated in the body of the Standard; where a conflict exists, the body governs.

F.1 What ZKS Does and Does Not Claim​

ZKS is a claim about third-party technical incapability: no third party, and no coalition of colluding intermediaries, can access, derive, or intercept the complete set of components required to decrypt, or revoke the user's decryptability (Section 2.1). ZKS verification provides structural assurance of that property (Section 7.5.5.2). It does not guarantee:

  • absence of implementation bugs or cryptographic implementation errors;
  • resistance to all side-channel attacks;
  • absence of vulnerabilities in dependencies; or
  • protection of a compromised endpoint's local data.

Section 8.3.1 further scopes the evidentiary claim: verifying absolute impossibility is theoretically limited, so conformance evaluation demonstrates that no defined interface, workflow, or storage mechanism exposes plaintext or unwrapped keys, and that standard adversarial techniques fail. Falsifiability - the ability to disprove a sovereignty claim through defined tests - is the Standard's evidentiary contribution (Tenet 7).

F.2 Endpoint Compromise​

ZKS does not prevent compromise of user devices (Section 2.4, assumption 4). Its contribution under endpoint compromise is containment: external services must not act as amplifiers that convert a single-device compromise into domain-wide or provider-side decryptability (Section 5.3.1). Key separation modes (Section 4.10) exist specifically to reduce the value of a stolen or coerced endpoint. Users and deployers should treat endpoint hardening, OS integrity, and physical security as complementary controls outside ZKS scope.

F.3 The Update Channel and Binary Trust​

The deployed client binary is the load-bearing trust assumption of any ZKS system (Section 7.5.5.3): a malicious update is a vendor-authorized compromise of the CSD. The Standard's response is mandatory Binary Transparency for all profiles (Section 5.3.1, Assertion A13), with reproducible builds and witness cosigning as SHOULD-level reinforcement. Residual risks remain and should be disclosed: transparency enables detection of targeted updates, not prevention; on managed distribution channels (mobile app stores) platform-appropriate equivalents apply, and the store operator retains a residual substitution capability that must be disclosed (Section 5.3.1).

F.4 Metadata as Personal Data​

Even a fully compliant deployment leaves intermediaries holding operational metadata: connection events, device or item identifiers, sync timing, key-delivery events, and wrapped key material. Two considerations follow:

  1. Privacy law. Metadata about identifiable users is typically personal data under regimes such as the GDPR, and wrapped artifacts and logs are producible under legal process. Compliance statements and marketing claims should therefore say "no user content", never "no user data" (see Section 6.6 and the disclosure rules of Section 7.4.5).
  2. Sovereignty risk. Correlated metadata can become an acquisition-targeting tool. Assertion A7 and Section 3.6 impose metadata minimization and non-correlation requirements; Section 3.6.2.1 addresses ciphertext size fingerprinting, which remains a residual risk when padding is not implemented and must then be disclosed.

F.5 Out-of-Band Channel Risks​

OOB authorization channels are part of the sovereignty-critical path for key release and recovery. SMS and voice channels are vulnerable to SIM-swap and SS7-class attacks; Section 3.3.4 requires that SMS-based OOB be documented as a residual risk for ZKS-Enhanced and ZKS-Enterprise, and recommends hardware tokens or authenticator applications on independent devices for high-assurance operations. OOB channels operated by the same provider as the UKRS reduce independence and should be avoided (Section 4.10).

F.6 Extended CSD and Hardware Trust​

Where a remote TEE is used as an Extended CSD (Section 3.2.1.1), the sovereignty boundary extends onto third-party hardware: attestation verification is mandatory, trust boundaries must be documented, availability fallback is required for Assertion A4, and the TEE firmware trust assumption - firmware is controlled by the infrastructure provider - should be documented with mitigations. Local TEEs and secure elements strengthen endpoint key protection but do not change the sovereignty boundary (Section 6.5.4).

F.7 Harvest-Now-Decrypt-Later​

Long-lived ciphertext and wrapped artifacts are exposed to future cryptographic advances. The Coexistence Prohibition (Section 2.2.2) is a structural control against the worst concentration of this risk (one entity holding ciphertext plus wrapped keys); T-EXT-CAP-2 (Appendix E) provides an assessment procedure for retention and cryptographic shelf-life. The Standard is algorithm-neutral (Section 6.5.1); deployers should track post-quantum migration guidance for the primitives they select.

F.8 ZKS and Lawful Access​

ZKS constrains which party can be the effective point of legal service for decrypted content; it does not create a lawless zone:

  • The data controller remains fully capable and compellable. In enterprise and public-sector deployments the organization is the Sovereignty Domain Owner (Section 2.2.9) and retains internal access, legal hold, eDiscovery, and audit capability within its own sovereignty domain. Legal process for content is served on the accountable data controller, which can comply.
  • Infrastructure operators can produce what they hold. Providers and intermediaries remain compellable for what they actually possess - ciphertext, wrapped artifacts, and operational metadata - none of which is decryption-enabling for them.
  • The effect of ZKS is relocation, not elimination, of the point of legal service: from infrastructure operators (who are not party to the data relationship) to the data controller or the individual data subject (who are). This aligns with due-process norms that direct compulsion at the accountable party, and with EDPB Recommendations 01/2020 Use Case 1, which identifies exporter-held-keys encryption as an effective supplementary measure for cross-border transfers (Section 6.6.2).
  • What ZKS forecloses is silent, capability-based access through the infrastructure operator without the controller's or subject's involvement - including the operator's own insiders and any party that compromises the operator.

Claims in procurement or marketing material that a ZKS deployment produces "nothing" under legal process are incorrect and should not be made; the accurate statement is that the provider can produce no user content and no decryption-enabling material.

F.9 User Responsibility Transfer​

ZKS removes provider recovery as a safety net. The mandatory user disclosures of Section 7.4.5 (artifact responsibility, provider limitation, no backdoor) exist because irrecoverable data loss through lost sovereign artifacts is a real and foreseeable harm of this architecture class. Implementers should treat disclosure quality and recovery-artifact UX as safety engineering, not as documentation.