Client Architecture and the Trust Boundary | Cyber Immunity Whitepaper

Where Trust Meets the Real World

While Tide Cybersecurity Fabric handles the core cryptographic operations, connecting users and applications to this decentralized network introduces a significant challenge at the perimiter:

How does a user, a developer, or an application reach the Fabric without centralizing trust at the edge?

The foundational principle: the Tide ORK protocol is defined at the ORK API and is not bound to any specific implementation. The ORK API specifies how to request DKG, authenticate via PRISM, submit Doken-authorized Forseti requests, and verify proofs. Any client that correctly implements the protocol can interact with the Fabric. The Secure Web Enclave (SWE) is the reference client, but not the only one - the same crypto engine is available as a backend library for microservices, CLI tools, or mobile applications.

Everything above the ORK API is a consumption layer. Each adds accessibility; none adds trust dependencies.

Loading diagram...

FIGURE 15: Client's Trust Boundaries

The Cyclical Trust Boundary

In legacy architectures, trust is a perimeter: trust the firewall, trust the server, trust the client. Breach the perimeter, access everything. In Tide, the trust boundary is a cyclical verification loop:

Loading diagram...

FIGURE 16: Client-Network Cyclical Trust Loop

The ORKs verify every request (Forseti policy, Doken signatures, temporal constraints) before computing. The client verifies every response (ZK proofs, mathematical consistency) before assembling. The SWE code is SRI-sealed and inspectable. If an ORK deviates, an honest client detects it. If a client deviates, the ORKs reject it.

The sole remaining trust assumption is the honest-minority threshold: no more than 13 of a key's 20 ORKs are colluding. With

\geq 7

honest nodes, security is preserved. With

> 6

malicious nodes, denial of service is possible (but not a breach). With

\geq 14

compromised, key compromise occurs. This is the irreducible assumption - everything else is verified.

The Secure Web Enclave

The SWE is the reference Tide client. Running in the user's browser, it coordinates all user-initiated sMPC operations: authentication, encryption, decryption, and signing. It operates as an untrusted dealer - the protocol is designed so that even a fully compromised SWE cannot breach security, only deny service. It never sees complete keys (only partial results), cannot forge proofs (lacks key material for ZK verification), and cannot impersonate users (session keys are ephemeral and local).

SRI Verification

The SWE is delivered as a signed HTML/JS bundle with a pinned SHA-256 Subresource Integrity hash. The HTML structure is minimal by design - a single <html> wrapper, an empty <body>, and a <head> containing exactly one <script> tag - which offers two complementing security guarantees:

It offers a browser-native guarantee that the code executing in the SWE is exactly the code audited by the user or a third-party auditor and eliminates the risk of supply chain attacks on the frontend.
It allows any user to independently verify the integrity of the SWE bundle, in run-time, without trusting the delivery mechanism. To our knowledge, this makes the SWE the first technology to offer a simple and immediate integritiy verification of a complex client-side application.

No injected scripts, no hidden iframes, no tracking code. If a compromised vendor, CDN, or MITM attacker alters any byte, the browser refuses to execute it. Users can independently verify the SRI hash against Tide's Integrity Checker at https://tide.org/integrity-checker or their preferred social media platform. Because the SWE also acts as a verifier of the entire Fabric's sMPC protocol, this converts "trust the vendor's technology" into "verify the vendor's system from the outside."

Rehoming

The SWE allows users, at any point in their use of it, to change the source from which it is served to a server of their choice. This allows users that still have any doubts about the integrity of the default delivery mechanism to host the SWE themselves, or to switch to a different delivery mechanism if they prefer. Because security is anchored by the SRI hash rather than the origin server, the SWE is fully portable. Organizations can serve the same bundle from their own S3 bucket, internal CDN, or on-premises server. As long as the SRI hash is the audited one, the security model holds. This eliminates frontend delivery vendor lock-in.

sMPC Orchestration and Session Management

When an application requires a cryptographic operation, the SWE queries the TWELVE-MAP directory (the self-verifying, Merkle-anchored mapping of key IDs to ORK sets), distributes entropy and the Doken-authorized payload to the assigned 20 ORKs, verifies each ORK's ZK proof as results return, rejects any inconsistency, and Lagrange-interpolates

\geq 14

valid partial results into the final output.

The SWE also manages the user's ephemeral session key - generated locally during BYOiD authentication, never written to disk, never transmitted. This key is used for Hermetic E2EE proxy re-encryption (Article 6), ensuring cleartext materializes only in browser memory and is destroyed when the session ends.

For technical details on the SRI validation sequence, session key lifecycle, and sMPC orchestration logic, see Protocol: Secure Web Enclave.

TideCloak: The Optional IAM Abstraction

TideCloak is a Keycloak-based Identity, Immunity & Access Management (IIAM) server. It provides standard OIDC/OAuth 2.0 endpoints, an admin console, user federation, and client management. TideCloak is optional - a developer could interact with the Fabric directly through the SWE or Asgard without deploying it. It exists to make Tide consumption seamless for platforms that already use standard IAM patterns.

TideCloak operates as a trustless agent. It routes requests to the Fabric but holds no cryptographic authority:

Cannot sign tokens (signing authority is in the VVK, distributed across ORKs)
Cannot verify passwords (authentication runs through PRISM against CMK ORKs)
Cannot reset passwords without user participation
Cannot bypass quorum governance (Article 5)
Cannot access plaintext data (Hermetic E2EE resolves only in the SWE)
Cannot trace a user's VUID back to their CMK (VUID is derived via one-way hash)

TideCloak is the server-side embodiment of the "dumb terminal" architecture described in Article 6. Compromising it yields no keys, no hashes, no ability to forge tokens.

Aspect	Standard Keycloak	TideCloak
JWT signing key	Stored on server	Distributed across Fabric (VVK)
Password storage	Hashed in database	No hashes stored; ZK verification via Fabric
Admin password reset	Admin can reset any password	Requires user participation
Server compromise	Forged tokens, dumped hashes	No keys, no hashes, no authority

Asgard: The Backend Dealer Library

The SWE coordinates user-initiated operations from the browser. Applications that need server-initiated Fabric operations - JWT verification, backend encryption, quorum administration - use Asgard, the backend counterpart to the SWE.

Asgard is the same Dealer Library crypto engine packaged for server environments. It speaks the same sMPC protocol, verifies ZK proofs, and coordinates threshold operations. The difference is context: the SWE handles user-facing flows (login, personal data decryption); Asgard handles server-facing flows (e.g., verifyTideCloakToken() in the @tidecloak/verify Node.js package for server-side JWT verification, or backend encryption/decryption via the Fabric).

Asgard is not the Authenticator App - they are entirely separate components serving different roles.

Asgard inherits the same cyclical verification trust model as the SWE. The honest-minority assumption applies identically regardless of execution environment.

The TideCloak SDK: Developer Convenience

The TideCloak SDK wraps TideCloak + SWE integration into standard developer patterns. The Next.js SDK (@tidecloak/nextjs) is the reference implementation.

The SDK provides: <TideCloakProvider> (React context for session and token management), useTideCloak() (hook for auth state, tokens, role checks, and E2EE), <Authenticated> / <Unauthenticated> (guard components), createTideCloakMiddleware() (edge middleware for route protection), and verifyTideCloakToken() (server-side JWT verification).

A developer can scaffold a complete application in minutes:

bash

npm init @tidecloak/nextjs@latest my-app
cd my-app && npm run dev

The E2EE surface reduces all of Article 6's machinery - Doken authorization, Forseti policy evaluation, ORK-side proxy re-encryption, Lagrange interpolation - to two calls:

typescript

const encrypted = await doEncrypt([
  { data: "sensitive data", tags: ["private"] }
]);
const decrypted = await doDecrypt([
  { encrypted: ciphertext, tags: ["private"] }
]);

The SDK introduces no new trust assumptions. It is a stateless client-side wrapper - compromising it is equivalent to compromising the SWE, which is SRI-protected.

While the SWE handles credential-based authentication via PRISM, the Authenticator App extends the trust model to physical device possession. It is a mobile application (distinct from Asgard) for passwordless login where the user never enters a password into the browser.

The user's identity is bound to a Device Key (DVK) - a private key stored in the mobile device's secure element, protected by biometrics or PIN. Each ORK stores a per-ORK verification value derived from the DVK, enabling independent verification of device possession without any ORK knowing the DVK itself.

The QR-Mediated Flow

Enclave setup: The SWE generates ephemeral session keys and a persistent Browser Key (BRK), then opens a channel through a Home ORK and renders a QR code.
App cross-verification: The user scans the QR code. The App verifies the request was signed by the BRK, that the BRK is linked to the session key, and that the Return URL TLD matches expectations (phishing detection).
Device memory: The App maintains an encrypted list of known BRKs, stored at rest using DVK asymmetric encryption. An unfamiliar BRK triggers a warning - "Unfamiliar device! Verify the TLD." - creating device recognition without centralized device registration. If an attacker extracts app storage without the DVK, they cannot read the list of known browser keys.
Biometric authentication: The user authenticates via biometrics/PIN, unlocking the DVK.
Threshold authentication: The App communicates directly with CMK ORKs, proves device key possession, and produces a blind signature. ORK responses use layered encryption ensuring neither the Home ORK relay nor the browser can read internal state.
Completion: The App encrypts the blind signature under the SWE's session key and returns it through the Home ORK channel. The SWE decrypts and proceeds with VVK authorization (JWT signing, Doken issuance).

Every participant verifies the others. The App does not trust the browser - it verifies the TLD and BRK signatures. The ORKs do not trust the App - they require proof of the DVK.

For the cryptographic construction of the 2FA protocol, see Protocol: Authenticator App.

Three Authentication Paths

The six-step flow above describes the returning user path (DVK exists, BRK recognized). The App handles three distinct paths after QR scan or deep link:

Returning user (DVK exists, BRK known). The App proceeds directly to threshold authentication. No confirmation screen, no warnings. This is the common case for daily use.

Known device, new browser (DVK exists, BRK unknown). The App displays a confirmation screen with the vendor's TLD and an "Unfamiliar device" warning. The user verifies the domain and confirms. The App adds the new BRK to its encrypted known-BRK list and proceeds to authentication.

New device (no DVK). The App presents a setup wizard. For new Tide users, the App creates the DVK, stores it in the device's secure element, and registers a new account with the CMK ORK swarm (no password is ever created). For existing Tide users migrating from password-based authentication, the App requires one final password entry to prove identity, creates and stores the DVK, and pairs the device with the existing CMK via the ORK swarm. After pairing, the password authentication path is disabled. The migration is one-directional: once device-bound authentication is active, the user authenticates exclusively via DVK and biometrics.

The Trust Gradient

Layer	Trust Model	Verification	Compromise Yields
Tide ORK API	Honest minority ( $\geq 7$ of 20 honest)	Cyclical: ORKs verify requests; clients verify ZK proofs; protocol is open	$\leq 13$ compromised: secure. $> 6$ malicious: DoS possible. $\geq 14$ : key compromise.
Secure Web Enclave	Untrusted dealer	SRI hash (browser-native), ZK proof verification	Can only deny service. Cannot forge, impersonate, or exfiltrate.
Asgard (Backend Library)	Untrusted dealer	Same cyclical verification, server context	Same as SWE - same protocol, same guarantees.
TideCloak	Trustless agent	VVK-signed JWTs, no stored keys, cannot trace VUID→CMK	No keys, no hashes, no authority.
TideCloak SDK	Convenience wrapper	Inherits SWE + TideCloak posture	Same as SWE.
Authenticator App	Device-bound possession	DVK + biometrics, BRK cross-verification, encrypted BRK list, layered encryption	Lost device: auth fails (biometrics protect DVK). Stolen app data: no key material (BRK list encrypted with DVK).

No single component is "the" trust boundary. The trust model is a web of mutual verification anchored in mathematics, with one irreducible assumption: that the decentralized infrastructure remains predominantly honest.