Threat Model and Security Analysis | Cyber Immunity Whitepaper

Introduction: Analyzing the Seams

Evaluating the Tide architecture requires looking beyond each protocol's security properties in isolation. This article, therefore, asks a different question:

What happens when all the protocols are assembled into a production system, and a sophisticated attacker targets the seams between them?

Individual protocol security is necessary but insufficient. Real attackers probe for gaps between layers, exploit collusion between compromised components, and weaponize assumptions that hold in theory but fail in deployment. This article examines the Tide architecture as an integrated system - analyzing it the way an attacker would: establish the attacker model, map every component to its compromise outcome, analyze multi-party collusion, and distill the architecture to its irreducible trust assumptions.

The Attacker Model: The Privileged Insider

The entire cybersecurity paradigm today, including Zero Trust architectures, ultimately fails when the attacker achieves root administrative access to core infrastructure. Security architectures assume layers of access control will hold. If the attacker breaches the final layer, the system is considered lost.

Tide abandons this dependency. The first design principle states: all controls assume the attacker is already a privileged insider. This analysis defines the adversary as:

Root access holder - total administrative control over one or more infrastructure components (server, database, network segment, codebase).
Supply chain maintainer - a rogue developer, compromised vendor, or malicious cloud provider.
Collusion-capable - can compel multiple compromised components to coordinate.
Persistent - can observe traffic, monitor memory, and execute long-term campaigns.

Every security property must hold against this attacker. If a property requires trusting a component not to be compromised, it fails the design test. The only acceptable trust foundations are the honest-minority threshold, mathematical hardness, and browser SRI enforcement.

The Threshold Foundation: The Arithmetic of Trust

Before evaluating individual components, we establish the arithmetic of the honest-minority assumption. A critical architectural distinction: every key is distributed across a different swarm. There is no mandate for any two keys to share the same 20-node topology. Compromising one swarm yields only the keys that share that exact cluster.

For any given key:

Swarm Size ( $n$ ): 20 ORK nodes.
Execution Threshold ( $t$ ): 14 ORK nodes.
Honest-Minority Requirement ( $n - t + 1$ ): ≥ 7 honest nodes.

Loading diagram...

FIGURE 19: Security Degredation and Mitigation Approaches

Malicious Nodes (same swarm)	Effect	Security Status
0-6	All operations succeed normally.	Full security, full availability.
7-13	Can deny service (refuse participation). Cannot breach confidentiality or integrity.	Security preserved. Availability degraded. Key healing (Article 3) migrates shards to restore the swarm.
14-20	Can reconstruct the key or produce unauthorized signatures.	Key compromise. Ragnarök (Article 3) enables controlled destruction.

The deliberate asymmetry: confidentiality holds if a mere 30% of nodes behave correctly. Even if 70% of the nodes are malicious, the key remains safe - only availability degrades, and availability failures are recoverable. Confidentiality failures are not.

To achieve key compromise (14+ nodes), the adversary must identify which 20 specific organizations host the target key's shards, then breach 14 of those independent organizations simultaneously. Sequential compromise is detectable; key healing migrates shards away from unresponsive nodes.

Component Compromise Analysis

For each component in the architecture: if it is completely compromised by a root-level insider, what does the attacker actually gain?

Loading diagram...

FIGURE 20: Compromise Yield Matrix

1. Compromised ORK Node(s)

ORKs are independently operated; individual compromise is a statistical certainty over time. The critical distinction: compromised nodes must be in the same swarm of a specific key to yield any progress.

Single ORK (1 of 20): Yields one mathematically opaque shard and a partial metadata view. Cannot reconstruct any key or produce valid signatures. If it returns manipulated results, the client Secure Web Enclave (SWE) detects the invalid ZK proof. Key healing cycles the node out.

Minority (up to 6 of 20, same swarm): Yields 6 shards - still below threshold. Cannot deny service (14 honest nodes remain) or force false results (SWE verifies ZK proofs). The system remains fully functional and fully secure.

DoS zone (7-13 of 20, same swarm): Can deny service by refusing participation, starving the swarm below 14 responses. Cannot reconstruct the key. The 7-day licensing grace period (Article 8) provides time for key healing to reconstitute the swarm with honest nodes.

Catastrophic (14+ of 20, same swarm): The attacker controls the threshold and can reconstruct the specific key. The impact depends on the key type:

CMK or CVK (user keys): Compromise is limited to that specific user. The attacker can forge that user's authentication or access their data vault. No other users are affected.
VVK (organizational key): The attacker can decrypt VVK-sealed data and forge governance signatures. However, the attacker cannot forge BYOiD authentication or mint user JWTs - these are bound to the user's blind signature, requiring control of the user's separate CMK swarm. The VVK alone cannot impersonate a user.

Even in the catastrophic case, the data protected by any other key remains entirely separate, independent, and untraceable. There is no skeleton key.

2. Compromised Secure Web Enclave (SWE)

The SWE executes in the browser, outside the ORK network boundary.

What the attacker gains: Can refuse to complete operations (DoS). If the SWE code is replaced, the attacker could capture raw credentials before PRISM blinding. A malicious SWE could also generate an extractable session key (rather than a non-extractable WebCrypto key), enabling session hijack.

What the attacker cannot do: See complete keys (only partial results from ORKs), forge ORK ZK proofs (mathematically bound to ORK computation), or modify ORK responses undetected (proof verification fails).

Mitigation: SRI prevents code replacement - the browser refuses to execute a modified bundle. Replacing the SWE requires simultaneously compromising the CDN and the SRI hash in the vendor's signed HTML. Independent hash verification is available via Tide's Integrity Checker. The SWE can be rehomed to the vendor's own infrastructure. The Authenticator App (Article 7) provides a credential-free authentication path - no password enters the browser, nullifying both keystroke capture and session key extraction threats.

Net assessment: Degrades to DoS. Credential and session risks are mitigated by SRI, rehoming, and the Authenticator App.

3. Compromised TideCloak (Application Server)

TideCloak is open-source, self-deployable IAM built on Keycloak. It is served on-premises or as a hosted service controlled by the organization - not a SaaS operated by Tide. Tide personnel have no access to an organization's TideCloak deployment, just as Red Hat cannot access a customer's Keycloak instance.

What the attacker gains: Control over web routing. Access to the VRK (ephemeral payment key). Ability to disrupt UX (phishing redirects). Ability to drain the monthly voucher facility by allocating rogue vouchers.

What the attacker cannot do: Change role definitions, realm settings, or authorization policies (all require cryptographic quorum governance - Article 5). Sign JWTs or verify passwords (no VVK or CMK material). Access VVK ORK APIs for modification (all changes mandate quorum signatures; VRK authentication alone is insufficient).

Net assessment: Yields financial disruption (one drained monthly credit facility) and service interruption. Zero cryptographic authority. The attacker inherits an empty shell.

4. Compromised Payer ORK

What the attacker gains: Visibility into gVRK values, obfuscated VVK values (Y''), and operational cadences. Ability to inflict one month of financial damage - approving unfunded operations (defrauding ORK operators) or rejecting valid vouchers (causing DoS).

What the attacker cannot do: Learn actual Vendor identities (VVK obfuscated by slip-knot). Map users to vendors. Access user data, keys, or credentials. No direct security threat arises from a compromised Payer node.

Net assessment: The maximum damage, even if Tide itself turns malicious as Payer operator, is bounded to the active billing cycle. Because the operational model and specifications are open, ORK operators detecting fraud or DoS will route to an alternative, honest Payer cluster.

5. Compromised User Device

What the attacker gains: Raw password (via keylogger before PRISM blinding). Ephemeral session key during a live session (via memory dump). DVK from the Authenticator App (protected by secure element and biometrics).

What the attacker cannot do: Access other users' data. Persist beyond the current session. Recover the master CMK (sharded across ORKs).

Net assessment: Blast radius is one user, one session. Compare: a compromised admin device in traditional IAM can affect all users.

6. Network Attack (MiTM)

What the attacker gains: Encrypted traffic patterns.

What the attacker cannot do: Read PRISM-blinded credentials (zero-knowledge). Modify SWE code (SRI). Impersonate ORKs (ZK proof verification fails). Replay authentication or vouchers (ephemeral keys, timestamps, Payer digest uniqueness).

Net assessment: Active MiTM is neutralized. The attacker is reduced to passive traffic analysis.

Multi-Party Collusion Scenarios

Settlement Layer Collusion

The triple-blinded voucher system (Article 8) resists deep collusion. From the MATH-AnonVouchers analysis:

Colluding Parties	What They Gain	Impact	Mitigation
Vendor + SWE	Map that vendor's user CMK IDs to VUIDs	Low	SWE SRI / rehoming
Vendor + SWE	Map that vendor's users to CMK ORK nodes	Low	SWE SRI verification
ORK + Payer	Map user-vendor-ORK-Payer routing	Low	Payer nodes scrutinized
ORK + Payer	Unobfuscate a Vendor master VVK	Low	Payer nodes scrutinized
Malicious Payer alone	Accrue up to one month of debt	High	Open Payer model; ORKs migrate
Malicious Payer alone	Map obfuscated ORK IPs to Vendors	Medium	Payer nodes scrutinized
Vendor + User + ORK + Payer	Inflate billing to defraud honest ORK	Very High	Cryptographic logging + dispute resolution
Vendor + Payer	Map vendor traffic to ORK nodes	Low	Payer nodes scrutinized

Cross-Layer Collusion

Colluding Parties	What They Gain	What They Still Cannot Do
TideCloak + SWE	Full control over user-facing path and server routing.	Cannot sign JWTs (VVK distributed), recover CMK (sharded), or forge ORK ZK proofs.
TideCloak + 13 ORKs	Server + maximum-before-breach ORKs.	Cannot reconstruct keys (threshold is 14). TideCloak adds zero shards.
SWE + 13 ORKs	Client + maximum-before-breach ORKs.	Same: SWE is not an ORK, holds no shards. Threshold unbroken.
TideCloak + Payer	Server + economic clearinghouse.	Can cause economic disruption and DoS. Cannot breach cryptographic security.

The critical insight: Collusion that does not include ≥14 ORKs for a specific key cannot breach cryptographic security. Even when ≥14 specific ORKs are compromised, the data protected by that key is breached - but every other key's data remains separate, independent, and untraceable.

Cross-Layer Defense Reinforcement

The architecture's resilience emerges from how layers mutually reinforce each other.

Cyclical verification (Article 7): ORKs verify SWE requests via Forseti and Doken. SWE verifies ORK responses via ZK proofs. If either party is compromised, the honest party detects the anomaly. No single compromise breaks the chain.

Voucher-gated operations (Article 8): Every ORK operation requires a valid voucher. A compromised ORK without a funded voucher cannot execute. Fraudulent vouchers are caught at monthly redemption. The economic layer reinforces the cryptographic layer.

Distributed signing (Article 5): TideCloak (identity) and VVK swarm (authority) have independent compromise surfaces. Compromising the identity provider yields no ability to forge tokens.

Hermetic E2EE (Article 6): Even if TideCloak and the SWE are both compromised, encrypted data remains safe. The session key for decryption is ephemeral, existing only in browser memory during live sessions.

PRISM zero-knowledge (Article 4): Database compromise yields no password hashes. Credentials are verified dynamically across the Tide Cybersecurity Fabric without persistent storage.

Authenticator App (Article 7): If the browser is compromised at the OS level, the Authenticator App provides an independent, credential-free path. It cross-verifies the session via BRK recognition and TLD matching, bypassing the compromised browser entirely.

The Irreducible Trust Assumptions

After all verification, zero-knowledge, and threshold cryptography, five assumptions remain:

Honest-minority threshold (≤13 of 20 per key). If 14 nodes in the same swarm collude, that key is compromised. This is the single irreducible cryptographic assumption. Mitigation: swarm heterogeneity, independent operators, geographic distribution.
Mathematical hardness. ECDLP, SHA-256 preimage resistance, EdDSA signature security. If these primitives fall (e.g., cryptographically relevant quantum computing), the foundations fail. Note: this applies to all modern cryptographic systems, not just Tide.
Browser SRI enforcement. SWE integrity relies on the browser correctly refusing tampered scripts. Mitigation: independent hash verification, Authenticator App as out-of-band path.
Node independence. The honest-minority assumption holds only if ORK nodes are genuinely independent. A single operator secretly controlling 14 nodes renders the threshold meaningless. Mitigation: operator vetting, geographic diversity, TWELVE-MAP verifiability.
Payer node integrity (economic only). The Payer must honestly manage economic clearing. Mitigation: damage bounded to one billing cycle. Open model - ORK operators can establish alternative Payers. No cryptographic security depends on the Payer.

What is NOT on this List

To deploy TideCloak, an organization does not need to trust:

Tide (the company): TideCloak is self-deployed. Tide operates no centralized SaaS holding customer keys or data.
The vendor / application server: Compromise yields no cryptographic authority or plaintext data.
The SWE code: SRI-verifiable. Operates as an untrusted dealer.
Any single ORK operator: The architecture assumes individual nodes will be compromised.
The Payer for security: Only for economics, and bounded to one month.
The network transport: Zero-knowledge proofs and end-to-end encryption assume a hostile network.

Conclusion: TideCloak vs. Traditional IAM

Tide is a decentralized manager of Authority - a novel concept that defies direct comparison with any single product category. The most meaningful comparison evaluates an organization using TideCloak against one using a traditional IAM.

Attack Scenario	Traditional IAM (Okta, Standard Keycloak)	TideCloak
Server compromise	JWT signing key stolen - forge any token. Password hashes dumped - offline cracking. Full admin control.	No signing key (VVK distributed). No hashes (PRISM). No admin escalation (quorum governance).
Database breach	All user records, hashed passwords, session data exposed.	No complete keys exist. No hashes stored. Session keys ephemeral.
Admin gone rogue	Single admin can reset any password, elevate privileges, access all data.	Quorum required. Single admin has no unilateral power.
Supply chain injection	Injected code runs with full trust in the browser.	SRI prevents execution of modified code. Independent hash verification. Rehoming.
Insider threat (vendor employee)	Access to production = access to keys, hashes, data.	Tide employees cannot access customer TideCloak deployments. ORKs independently operated. No single exfiltration point.
Full infrastructure compromise	Complete data breach - all users, all passwords, all data.	Requires ≥14 specific ORKs per key, simultaneously. Server compromise yields nothing.

The composite picture: TideCloak does not build higher walls around the same vulnerable artifacts. It removes the artifacts themselves. The keys that attackers would target do not exist in any single place to steal. The credentials that would be cracked are never stored. The admin powers that would be abused require cryptographic consensus. The residual risk surface is not merely smaller - it is structurally different.