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-RC1 / CANDIDATE STANDARD

Appendix B - Formal Terminology and Semantics (Normative)

This appendix defines the normative semantics for key terms used in the ZKS Standard. Where these definitions differ from general industry usage, the definitions in this appendix SHALL take precedence for the purpose of evaluating ZKS compliance.

Access​

In the context of ZKS, Access refers specifically to the technical capability to obtain plaintext user information or to derive the cryptographic keys necessary to produce plaintext. It is distinct from "Storage Access" (the ability to retrieve ciphertext blobs) or "Metadata Access" (the ability to view routing headers). (See also: Section 2.2.3)

Availability Failure​

A condition where a service provider or intermediary ceases to provide access to ciphertext, orchestration signals, or key custody interfaces (e.g., due to outage, blocking, or account suspension). An Availability Failure does not constitute a Sovereignty Failure unless it results in the permanent revocation of decryptability for locally held or independently recovered ciphertext. (See also: Section 5.3.2)

Ciphertext Storage Substrate (CSS)​

Any system, service, or medium used to store encrypted user information (ciphertext). In ZKS, a CSS is treated as untrusted and lies outside the Sovereignty Boundary. (See also: Section 3.2.2)

Client Sovereignty Domain (CSD)​

The logical and physical boundary encompassing the user-controlled computing environment(s) where decryptability is permitted to exist. The CSD includes user devices, local memory, and user-controlled cryptographic modules (TEEs/HSMs). It excludes all vendor-controlled cloud services and intermediaries. (See also: Section 3.2.1)

Complete Set of Components Required to Decrypt​

The specific combination of cryptographic artifacts (e.g., wrapped keys, unwrap keys, derivation secrets, nonces) and authorization tokens required to transform ciphertext into plaintext. ZKS compliance requires that no third party can ever possess or reconstruct this set. (See also: Section 2.2.2)

Cryptographic Blindness​

A property of a system component wherein the component processes or stores cryptographic artifacts (such as wrapped keys or ciphertext) without possessing the private key material, secrets, or entropy required to unwrap, decrypt, or inspect the content of those artifacts. Cryptographic blindness is not defeated by the ability to delete or corrupt artifacts; it refers specifically to the inability to read or derive plaintext content or keys. (See also: Section 2.2.7, Section 5.3.4)

Decryptability​

The effective capability to produce plaintext from ciphertext. In ZKS, "maintaining decryptability" refers to the user's ability to decrypt their data, while "preventing third-party decryptability" refers to the assurance that no other party can do so.

Digital supply chain​

The set of all third-party services, infrastructure providers, and intermediaries whose technical position in the system architecture could potentially enable access to, or accumulation of, decryption-relevant components. This includes but is not limited to: cloud storage providers, key management services, content delivery networks, orchestration platforms, and software update distribution channels.

Intercept​

The capability to capture decryption-relevant components in transit or during processing such that the interceptor gains decryptability. ZKS requires that the Control Plane and Key Plane be designed such that interception of traffic by intermediaries does not yield the Complete Set of Components Required to Decrypt. For the purposes of this Standard, the storage or retention by a third party of both ciphertext and wrapped decryption keys-regardless of cryptographic protection-constitutes interception of the complete decryption component set unless such storage occurs entirely within the Client Sovereignty Domain. (See also: Section 2.2.4)

Key Material Possession​

The state of holding cryptographic keys in plaintext form or in a form that can be unwrapped by the holder (e.g., holding a key wrapped by a KEK that the holder also possesses). ZKS prohibits third-party possession of key material. Holding a user-encrypted key blob without the unwrapping key does not constitute Key Material Possession. Conversely, holding a wrapped key AND the unwrapping key (or the ability to obtain it) DOES constitute possession. (See also: Section 1.4; Section 6.5.2)

Non-Sovereignty-Impacting Change​

A software or configuration update that does not modify the Sovereignty Boundary, the Key Plane, or the Cryptographic Engine, and therefore may inherit prior compliance evidence without requiring fresh evaluation. Major updates to cryptographic cores do not qualify. (See also: Section 7.5.4)

Relocation (Topological Sovereignty)​

The user's capability to move the Ciphertext Storage Substrate (CSS) to a different provider or location without losing decryptability and without requiring cryptographic transformation (re-encryption) by the original provider. (See also: Section 2.2.5)

Revocation of Decryptability​

A specific failure mode where a third party (e.g., service provider) exercises a technical capability to permanently prevent an authorized user from decrypting their data, even when the user retains the ciphertext. ZKS strictly prohibits third-party revocation of decryptability. (See also: Section 2.2.6)

Sovereign Restoration Pathway​

A user-controlled mechanism (e.g., BIP-39 mnemonic, local file backup, hardware token) that enables the user to restore decryptability independently of any provider-operated service. A sovereign restoration pathway is REQUIRED when a UKRS or external key custody service is used, to ensure that provider denial of service cannot constitute revocation of decryptability. (See also: Section 3.5.3, Section 4.10)

Sovereignty Boundary​

The cryptographic and logical perimeter separating the Client Sovereignty Domain (CSD) from all other parties. Decryption keys in plaintext form and unwrapping capabilities MUST NOT cross this boundary. (See also: Section 3.4.2)

Sovereignty Domain Owner (SDO)​

The entity with ultimate authority over decryption capability within a sovereignty domain.

Sovereignty Failure​

Any condition in which a third party obtains the technical capability to decrypt user information or to revoke the user's ability to decrypt their own information (given ciphertext availability). Sovereignty failures are prohibited under ZKS.

Unilateral Control​

The ability of the user to exercise cryptographic and operational authority (e.g., authorizing a device, recovering keys, deleting data) without requiring the discretionary permission, cooperation, or cryptographic participation of a third party, except where the user has explicitly delegated such participation in a manner that remains reversible. (See also: Section 2.2.8)

Unwrap​

The cryptographic operation of decrypting a wrapped (encrypted) key to produce a usable plaintext key. ZKS requires that Unwrapping Capability be restricted to the CSD or a user-controlled secure hardware element, and never granted to a cloud provider.