Authority in Action: Threshold Operations and E2EE | Cyber Immunity Whitepaper

Introduction: From Existence to Agency

Beyond generating and governing distributed keys, the architecture core function is to allow to securely exercise authority. This requires mechanisms that translate a distributed key into concrete cryptographic actions.

For that, this article answers the question:

What actions can an authority actually exercise with a key that never materializes?

The answer lies in the transition from the Authority Layer to the Agency Layer - two abstractions introduced in Article 2 whose practical significance becomes clear only now that the reader understands key lifecycle, authentication, and governance.

The Authority Layer manages key existence: generation, storage, healing, rotation, disposal. An ORK at the Authority Layer acts with pure key-type agnosticism - it stores and protects a Shamir share without knowing whether that share belongs to a user identity, a vendor signing key, or a data encryption key. This is the layer Articles 3 and 5 inhabit.

The Agency Layer manages key effect: what cryptographic operation a share participates in during a specific, bounded moment. The same ORK, holding the same share, can participate in a signing ceremony, a decryption, or a randomness generation - because the Authority Layer is oblivious to purpose. This separation is what enables key-type agnosticism: the ORK infrastructure does not need to be redesigned when a new type of cryptographic operation is introduced.

The transition from "key exists" to "key acts" requires three mechanisms: the Doken (how authority reaches the user's terminal), a Forseti Contract (combined with a vendor policy determines whether an action proceeds), and threshold MPC (how the action is computed without key reconstruction). Every authority action in the Tide architecture follows the same unified pattern:

Loading diagram...

FIGURE 12: Authority Action Flow

The key never leaves Tide Cybersecurity Fabric. The cleartext (or signature, or random value) never leaves the device. The authority is momentary - bound to the session, the device, and the moment - and dissolves when the session ends.

The Doken: Delegated Authority Token

In a standard OIDC flow, the JWT is the universal bearer of authority: the application server evaluates its claims and executes business logic. But in an architecture where the application server holds no secrets it can leak and cannot perform cryptographic operations on its own, the JWT alone is insufficient. The ORK swarm needs its own proof that the requester is authorized to demand cryptographic work.

This produces a two-token architecture:

Token	Audience	Channel	Purpose
JWT	Application / Resource Server	Server-side (standard OIDC)	API authorization, business logic
Doken	ORK Swarm (via SWE)	Client-side (SWE → ORK direct)	Cryptographic agency

The application server handles business logic using the JWT. The user's Secure Web Enclave handles cryptographic operations using the Doken. The server never touches keys or cleartext.

Loading diagram...

FIGURE 13: Delegated Authority Action Flow

The Doken is a VVK-signed token issued alongside the JWT during token exchange. It is cryptographically bound to the user's session key and device, contains the user's roles and permissions (from quorum-approved authorization proofs - Article 5), and is session-scoped and time-limited.

The issuance is seamlessly integrated into the standard OIDC authorization flow. Following BYOiD authentication, the client submits an Authorization Code to TideCloak. During token generation, TideCloak evaluates the user's authorized roles. If the user possesses permissions prefixed with _tide_ - indicating authorization for cryptographic operations - TideCloak requests a Doken signature from the VVK ORK swarm alongside the standard JWT signature. The ORKs validate that the claims conform to the user's quorum-approved authorization proofs before returning both signatures. TideCloak delivers the JWT to the client application together with the Doken. When a delegated action is required, the client application invokes the SWE and hands over the Doken for that required action. Only the SWE can trigger a Doken-initiated request to the ORKs.

When the SWE presents a Doken to the ORK swarm, each ORK independently verifies three constraints:

The Doken was signed by this vendor's VVK,
The connection is encrypted with the Doken's session key, and
The Doken contains the roles required for the requested action.

Only then does the ORK proceed to policy evaluation.

This separation is architecturally critical. The application server is relegated to a router: it handles business logic using the JWT but never touches raw keys and never observes plaintext. All cryptographic agency flows through the SWE → Doken → ORK channel, completely bypassing the server.

Forseti: The Programmable Policy Engine

Validating a Doken confirms that the requester holds an active, authorized session. But enterprise environments require granular, context-aware policy - time-of-day restrictions, geographic constraints, transaction limits, multi-party approval requirements - that goes beyond binary access checks.

In traditional IAM, policy enforcement runs at the application layer: software guards that a privileged attacker can disable, patch out, or bypass. Forseti moves policy enforcement inside the cryptographic authority itself. Each ORK independently loads and executes a deterministic C# contract before contributing its partial computation. If the contract fails, the ORK cannot produce the partial result. Because 14 of 20 ORKs must participate, the policy is enforced by the mathematics of the threshold scheme. The policy is not a gate in front of the key - it is part of the key's operation.

The Policy:1 Flow

Administrators define Forseti policies as C# contracts. The Contract ID is the SHA-512 hash of the source code - deterministic, tamper-evident, and identical across all ORKs. If a single character of the policy logic changes, the hash changes, and the ORK network will not recognize the modified contract. This ensures that every ORK in the swarm executes precisely the same logic.

When an ORK receives a Doken-authorized request, it executes a three-stage validation lifecycle:

Stage	Contract Method	What It Checks
Data	`ValidateData`	Request parameters, time windows, geographic constraints, payload integrity, transaction limits
Approvers	`ValidateApprovers`	Perform checks against the Approver Dokens that have signed this request
Executor	`ValidateExecutor`	Perform checks against the Requester's Doken for this request

Each contract runs in a sandboxed VmHost process with IL vetting (blocks forbidden namespaces like System.IO, System.Net), strict process isolation, and gas metering (bounded computational budget that terminates infinite loops or resource-exhaustion attempts). These constraints ensure that vendor-defined code cannot subvert the ORK infrastructure - the contract can inspect request data and evaluate policy, but it cannot access the filesystem, make network calls, or interfere with the ORK's cryptographic operations.

The 14-of-20 threshold provides an additional guarantee: even if a minority of ORKs are compromised and execute a modified contract that always passes, they cannot produce a valid cryptographic result alone. The policy is enforced collectively.

Forseti closes the gap between governance (Article 5 - quorum decides the rules) and execution (this article - Forseti enforces those rules at the moment of action). No one can change the rules without a quorum. No one can bypass the rules without compromising a threshold of ORKs. And even if the application server is fully compromised, the policy runs on ORKs, not on the server. For the complete contract API, IL vetting rules, and gas metering specification, see Protocol: Forseti.

The Taxonomy of Authority Actions

Every authority action follows the same pattern - Doken → Forseti → threshold MPC - but the cryptographic primitive and output differ:

Authority Action	Dispensing Mechanism	Real-World Applications
Decentralized Decryption	Just-in-Time Unlocking: ORKs compute partial decryptions via proxy re-encryption. Cleartext exists only on the user's device.	Medical records, secrets management, financial data
Threshold Signing	Consent & Approval: A valid signature emerges from partial contributions aggregated at the edge. The signing key never assembles.	Bank transfers, legal contracts, SSH auth (KeyleSSH), supply-chain signing
Blind Delegation	Oblivious Agency: Authority holder signs a capability token without observing the user's identity or the specific action.	Power of attorney, anonymous voting, corporate delegation
Verifiable Randomness	Provably Fair Entropy: Each ORK contributes randomness. The aggregate is unpredictable and verifiably unbiased.	Lotteries, random auditor selection, gaming

Decentralized Zero-Knowledge Authentication (BYOiD) and Quorum Governance are also authority actions, detailed in Articles 4 and 5 respectively. This article focuses on the four actions above, with Decentralized Decryption offering Hermetic E2EE as the flagship deep-dive.

An important architectural distinction: for signing operations (like KeyleSSH), the SWE communicates directly with the VVK ORK swarm - it presents the Doken and the payload, collects partial signatures, and assembles the result at the edge. No intermediary server needs to see the signed message. For decryption operations (Hermetic E2EE), the flow may route through the Vendor's server, which performs the Lagrange aggregation but cannot recover the cleartext due to proxy re-encryption. This distinction reflects the different trust requirements: signing produces a public artifact (anyone can verify the signature), while decryption produces a secret (only the authorized user should see the plaintext).

Case Study: KeyleSSH - Threshold Signing in Action

KeyleSSH demonstrates threshold signing with Forseti policy enforcement in a domain where key management is a persistent operational burden: SSH infrastructure. Organizations contend with key sprawl across developer laptops, orphaned credentials on decommissioned servers, and lateral movement risk when bastion hosts are compromised. The fundamental vulnerability is that SSH private keys must exist somewhere - and wherever they exist, they can be stolen.

Loading diagram...

In a KeyleSSH deployment, the target server's authorized_keys file contains the

gVVK

static public key. The corresponding private key is entirely ineffable - it exists only as fragments across the VVK ORK swarm and is never assembled. No .pem file exists on any laptop, bastion host, or application server. The public key is permanent; the private key is distributed and exercised only through threshold consensus.

When an engineer initiates an SSH connection, their web client generates a standard SSH_MSG_USERAUTH_REQUEST challenge. Instead of signing locally, the engineer's SWE submits the challenge payload with a valid Doken to the ORK swarm. Each VVK ORK runs a KeyleSSH-specific Forseti contract that performs deep packet inspection: it verifies the message type is 50 (User Auth Request), enforces the ssh-connection service, requires the ssh-ed25519 algorithm, and confirms that the SSH username requested in the payload matches the role in the engineer's Doken (e.g., the ssh:admin role for admin login).

Only after the contract passes do the VVK ORKs collaboratively produce a threshold Ed25519 signature. The SWE assembles the complete signature and the web client forwards it to the SSH server. Access is granted, and specifically to the session key used to originally authenticate that user session - without any server private key ever existing in any single location.

The entire class of SSH key vulnerability - key theft, key sprawl, orphaned keys, lateral movement via compromised bastions - is eliminated by design.

Hermetic E2EE: The Flagship Authority Action

Hermetic E2EE is the pinnacle of the authority action model. It demonstrates the complete chain: authentication → Doken issuance → policy verification → threshold decryption with proxy re-encryption → cleartext on the user's device only.

The Problem: The Server-Side Decryption Gap

Traditional encryption protects data at rest (database encryption) and in transit (TLS). But at the moment of use, the standard architecture requires the server to decrypt and transmit plaintext. Compromise the server - external breach, rogue administrator, malicious cloud provider, memory dump - and you access all data. The security model depends on trusting the server. This is antithetical to Zero Trust principles.

Hermetic E2EE eliminates this trust requirement.

The Solution: Proxy Re-Encryption

The construction is a threshold DH-ElGamal scheme with proxy re-encryption. Understanding why proxy re-encryption is necessary, not just what it does, is essential to understanding the architecture.

Encryption requires only the public key of the ineffable master key. The encrypting party generates a random key, derives a symmetric encryption key from it and the public key, encrypts the data, and stores the ciphertext alongside an ephemeral public point, access tags, and a tag signature. The access tags define which roles and permissions are required to decrypt - they become inputs to the Forseti policy evaluation during decryption. The master private key - which is fragmented across the VVK ORK swarm - is never needed for encryption. Any party with the public key can encrypt; decryption requires the live Fabric.

The intermediary problem. In a web application, the Vendor's server mediates communication between the user's SWE and the ORK swarm. If the ORKs simply computed a direct threshold decryption and returned the result through the server, the mediating server would see the decryption material and could recover the cleartext - defeating the point of E2EE. This is the gap that proxy re-encryption closes.

How proxy re-encryption works (architecturally). During BYOiD authentication, the SWE generates an ephemeral session key and embeds the corresponding public key in the Doken. When the ORK swarm processes a decryption request, each ORK blends its partial decryption with the user's session public key. The Vendor receives these blended partial results and aggregates them (Lagrange interpolation), but the aggregation is opaque - it cannot be decoded without the session private key. Only the user's SWE, which holds the session private key in browser memory, can strip the blending term and recover the symmetric decryption key. The cleartext is then decrypted locally, entirely within the SWE.

For the detailed mathematical construction (the DH-ElGamal algorithms, the exact blending operation, and the Lagrange mechanics), see Protocol: Hermetic E2EE.

The Complete Chain

The full Hermetic E2EE sequence integrates every mechanism described in this series:

User authenticates via BYOiD → receives Doken with embedded session public key (Article 4)
User requests encrypted data from the resource server
Resource server returns the encrypted record - it has no ability to decrypt
SWE sends the auth token, the ephemeral point from the ciphertext, and the tag signature to the Vendor
Vendor forwards to the ORK swarm
Each ORK validates the token, validates the tag signature, matches tags against user permissions, and runs the Forseti policy contract
Each ORK computes a blended partial decryption (data key term + session key term)
Vendor aggregates the partial results obliviously (Lagrange interpolation - cannot recover cleartext)
SWE receives the aggregate, strips the session-key term using the private session key, recovers the symmetric key, and decrypts the data locally
Session ends → session key destroyed → data inaccessible until re-authentication

Loading diagram...

FIGURE 14: End-to-End Decryption Flow

Why It Is "Hermetic"

Four guarantees enforce the hermetic seal:

The Fabric is blind. ORKs compute partial operations on algebraic curve points. They never observe the ciphertext or the resulting plaintext.
The server is blind. The Vendor aggregates blended partial results. It cannot strip the session-key term because it does not hold the session private key.
The authority is ephemeral. The entire decryption capability is bound to the session key generated during BYOiD authentication. When the session ends or the browser closes, the session key is destroyed. The data reverts to an inaccessible state until a new authentication ceremony produces a new session key.
No offline access - by design. Offline decryption would require storing a private key locally, recreating the exact vulnerability this architecture eliminates. Every decryption requires live participation of the ORK swarm, ensuring that Forseti evaluates the policy context of every access request in real time.

Comparison with Existing Models

Property	Signal-Style E2EE	Server-Side Encryption	Hermetic E2EE
Key location	User's device (stored)	Server	Nowhere (Fabric)
Key management	User must back up	Admin manages	No key to manage
Admin access	No	Yes	No
Server compromise	Safe (if device safe)	Data exposed	Safe
Enterprise policy	None	Server controls	Quorum-governed (Forseti)
Forward secrecy	Per-message ratchet	No	Per-session (ephemeral key)
Offline access	Yes (keys stored locally)	Yes	No (by design)

Hermetic E2EE delivers the data privacy of consumer messaging E2EE, combined with the policy governance required by enterprises, while eliminating the burden of key custody entirely.

The "Dumb Terminal" Architecture

Articles 3 through 6 together deliver a single architectural result: the application server has been reduced to a "dumb terminal."

The server holds no authoritative cryptographic keys - the Authority Layer dissolved them across the network (Article 3). The server cannot forge authentication tokens - BYOiD produces tokens signed by a distributed CMK ceremony no single party can replicate (Article 4). The server cannot modify authorization rules - quorum governance requires multi-admin approval sealed by the VVK swarm (Article 5). The server never sees plaintext - Hermetic E2EE ensures cleartext exists only on the user's device (this article). The server cannot bypass policy - Forseti runs on ORKs, not on the server (this article).

Each of these properties is individually achievable with existing technology. What makes the architecture novel is that they hold simultaneously - and that they hold not as operational policies that could be overridden, but as mathematical constraints that cannot be. A compromised server does not have weakened security; it has no security-relevant material to compromise.

This represents a fundamental shift from access control to authority management. Traditional security checks a badge, checks a list, opens a door. The entire model depends on the integrity of the list-keeper. Tide does not "control access" - it manages authority. Authority is not a static object stored in a vault or protected by a firewall. It is an algorithmic consensus that grants momentary agency to a verified requestor. The authority materializes only for the execution of a specific threshold operation: a decryption, a signature, a randomness generation. The instant the session concludes, the authority dissolves - the session key is destroyed, the partial computations are discarded, the Doken expires.

When authority ceases to exist as a discrete artifact, there is nothing left for an attacker to steal.

References

Hall, J. L., Hertzog, Y., et al. (2023). Manifesting Unobtainable Secrets: Threshold Elliptic Curve Key Generation using Nested Shamir Secret Sharing. arXiv:2309.00915. Presented at AustMS 2021.
Tide Developer Documentation: docs.tidecloak.com
KeyleSSH Reference Implementation: github.com/sashyo/keylessh

Introduction: From Existence to Agency

The Doken: Delegated Authority Token

Forseti: The Programmable Policy Engine

The Policy:1 Flow

The Taxonomy of Authority Actions

Case Study: KeyleSSH - Threshold Signing in Action

Hermetic E2EE: The Flagship Authority Action

The Problem: The Server-Side Decryption Gap

The Solution: Proxy Re-Encryption

The Complete Chain

Why It Is "Hermetic"

Comparison with Existing Models

The "Dumb Terminal" Architecture

Further Reading

References