Secure Web Enclave: Verifiable Client-Side Coordination | Cyber Immunity Whitepaper

Overview

This document specifies the delivery, initialization, and execution lifecycle of the Secure Web Enclave (SWE) - a browser-delivered HTML/JS module that serves as the user-facing dealer for all secure Multi-Party Computation (sMPC) operations against the Tide Cybersecurity Fabric.

The SWE replaces blind trust in vendor-served JavaScript with two properties. First, code integrity: the bundle is delivered with a pinned SHA-256 SRI hash that the browser enforces natively - any modification blocks execution. Second, the SWE operates as an untrusted dealer: the protocol is designed so that even a compromised SWE cannot extract keys (it receives only partial results), forge Zero-Knowledgeproofs (it lacks key material), or impersonate users (session keys are ephemeral). An honest SWE additionally verifies ZK proofs on every ORK response, closing the cyclical verification loop: ORKs verify the SWE's requests, the SWE verifies the ORKs' responses.

For architectural context, see the parent Article 7. For the PRISM authentication ceremony the SWE coordinates, see Protocol: CMK Authentication. For the Hermetic E2EE decryption flow, see Protocol: Hermetic E2EE.

Loading diagram...

Preconditions

SWE Bundle

Artifact	Description
HTML wrapper	Single `<html>`, single empty `<body>`, single `<head>` with one `<script>` tag
Script attributes	`defer`, `src` (bundle URL), `integrity` (SHA-256 SRI hash), `crossorigin="anonymous"`
Bundle content	JavaScript/WASM implementing the Tide Dealer Library: PRISM, DKG, threshold signing/decryption, Forseti request construction
SRI hash	SHA-256 hash pinned at delivery time. Any modification → browser blocks execution

User Credentials

Artifact	Description
Username	User-provided identifier
Password / 2FA	User-provided secret. Blinded by SWE via PRISM before any network transmission

TWELVE-MAP Entry

Tide Wide Enumerated Ledger of Verifiable Entries - Mapping Authoritative Pointers (TWELVE-MAP) is the self-verifying directory service mapping key identifiers to ORK swarms. Each entry includes a ZK proof attesting to its authenticity against the master registry. The SWE queries TWELVE-MAP on the Home-ORK (or any ORK) for the target key's ORK roster and verifies the proof before proceeding with sMPC orchestration.

Artifact	Description
Key ID	Identifier for the target key (CMK, VVK, or CVK)
Node set	`[node₁ ... node₂₀]` - the 20 ORKs holding shards of this key
ZK proof	Proof that the mapping is authentic against the master registry

Phase 1: Code Delivery and Integrity Verification

Loading diagram...

The SWE bundle is served to the browser from the vendor's preferred Home-ORK, but can be served from any origin - Tide CDN, the vendor's own S3/on-premises infrastructure, or any custom domain. The security model is hash-based, not origin-based: rehoming the SWE does not change the security posture.

The browser processes the <script> tag and executes Algorithm 1. If the SHA-256 hash of the fetched content does not match the pinned integrity attribute, the browser blocks execution. This is a browser-native guarantee independent of Tide or the vendor.

The HTML structure is minimal by design:

html

<html>
  <head>
    <script defer src="..." integrity="sha256-..." crossorigin="anonymous"></script>
  </head>
  <body></body>
</html>

A single <html> wrapper, a single empty <body>, and a single <head> with exactly one <script> tag (no additional scripts, stylesheets, meta tags, inline handlers). This eliminates the DOM-based attack surface: no injected elements exist to exfiltrate data. A user or automated auditor can view the page source and confirm no unexpected elements are present.

Users may optionally extract the integrity value and verify it against Tide's Integrity Checker or any independent auditor.

Phases 2-3: Session Initialization and sMPC Orchestration

Loading diagram...

Session initialization

The SWE is the only component that touches raw user credentials. Upon entry, the SWE blinds the password into a PRISM challenge c (see Protocol: CMK Authentication for the blinding construction). The raw credential is discarded after blinding.

The SWE generates three ephemeral key pairs (Algorithm 3):

NetworkSessionKey - The primary SWE session key that is used against all Tide related interactions (authentication, authorization, authority actions, etc.). Generated as a non-extractable key, never transmitted. Used in Hermetic E2EE proxy re-encryption (Article 6) - each ORK adds $B \cdot a_i$ where $B = \mathcal{G} \cdot \text{b}$ . Establishes pairwise ECDH-encrypted channels with each ORK, bypassing reliance on TLS. Destroyed on session end.
VendorSessionKey - The vendor's client app key to be used post-authentication. This key is generated and operated by and on the vendor client application and is used throughout the user session in the vendor app. Signs Browser Key (BRK) public as sessKeyProof (proving the BRK is bound to this session) and is included in the appReq payload for Authenticator App cross-verification (Protocol: Authenticator App).

sMPC orchestration

The SWE queries TWELVE-MAP for the target key's ORK roster and verifies the directory entry's ZK proof. If the proof fails, the SWE rejects the mapping (protection against directory poisoning).

The SWE constructs the operation-specific request, establishes ECDH-encrypted channels via NetworkSessionKey with each ORK, and dispatches to all 20 nodes simultaneously.

Timing model (from LLD): The SWE waits 1 second for all

n = 20

responses (optimistic), then up to 5 seconds total for at least

t = 14

(threshold). If fewer than 14 arrive, the operation fails.

Each ORK response contains a partial result

Z_i

and a ZK proof

\pi_i

. The SWE independently verifies each

\pi_i

against public parameters. Invalid proofs → that ORK's response is discarded. If fewer than 14 verified responses remain, the operation aborts.

The SWE Lagrange-interpolates the valid partials (Algorithm 2, Step 6). For decryption, it additionally subtracts

A \cdot b

(where

b

is NetworkSessionKey) to recover cleartext in browser memory. For signing, it aggregates partial signatures. The final result exists only in browser memory.

Phase 4: Result Delivery

The SWE presents the assembled result to the calling application:

Authentication: Redirects to TideCloak with VendorEncryptedData - the blind signature, VUID, and auth token encrypted under gVRK (the vendor's ephemeral public key, signed by gVVK).
Decryption: Returns plaintext to the application's JavaScript context. Cleartext exists only in browser memory.
Signing: Returns the threshold signature.

Local storage (conditional)

For "remember me" flows, the SWE stores limited session metadata in browser localStorage: username, ORK routing addresses, session expiry. The Browser Key (BRK) is stored in localStorage only if the Authenticator App was used to log in - this is a precondition for the Protocol: Authenticator App cross-verification flow. No credential material is stored.

Session termination

On logout or expiry: ephemeral session keys (NetworkSessionKey, VendorSessionKey) are garbage collected from JavaScript memory. Stored authentication tokens expire. Because NetworkSessionKey is the hermetic seal for E2EE, data encrypted to this session becomes permanently unrecoverable.

Algorithms

Algorithm 2: sMPC Orchestration and Assembly

Input:

\text{key\_id}

, operation payload

P

\text{NetworkSessionKey}

Output: Assembled cryptographic result

R

\bot

(failure)

$([\text{node}_1 \ldots \text{node}_n],\; \pi_{\text{map}}) \leftarrow \textsf{TWELVE-MAP.Lookup}(\text{key\_id})$
if $\textsf{VerifyProof}(\pi_{\text{map}}) = \text{false}$ : return $\bot$
for each $j \in [1..n]$ : send $\textsf{AES\_ENC}_{\textsf{DH}(\text{NetworkSessionKey},\; \text{mgORK}_j)}(P)$ to $\text{node}_j$
Collect responses $(Z_i, \pi_i)$ within timing window: 1s optimistic (all $n$ ), 5s threshold ( $\geq t$ )
for each $(Z_i, \pi_i)$ : if $\textsf{VerifyZKProof}(\pi_i) = \text{false}$ : discard $Z_i$
Let $\mathcal{V} = \{i : \pi_i \text{ valid}\}$ . if $|\mathcal{V}| < t$ : return $\bot$
$R \leftarrow \sum_{i \in \mathcal{V}} Z_i \cdot L_i$ where $L_i$ are Lagrange coefficients from $\{id_i : i \in \mathcal{V}\}$
return $R$

Note: For decryption, a final step subtracts

A \cdot b

(where

b

= NetworkSessionKey) from

R

to recover plaintext. See Protocol: Hermetic E2EE.

Algorithm 3: Session Key Lifecycle

Input: Browser WebCrypto context
Output: Three ephemeral key pairs

$(\text{NetworkSessionKey},\; \text{gNetPub}) \leftarrow \textsf{WebCrypto.generateKey}(\text{ECDH},\; \text{extractable: false})$
$(\text{VendorSessionKey},\; \text{gVendPub}) \leftarrow \textsf{WebCrypto.generateKey}(\text{ECDH},\; \text{extractable: false})$

Invariants:

Private keys never written to localStorage, IndexedDB, or any persistent store
Private keys never transmitted over any network interface
NetworkSessionKey serves as the hermetic seal for E2EE proxy re-encryption ( $B = \mathcal{G} \cdot \text{NetworkSessionKey}$ )
All keys destroyed (garbage collected) on logout, tab close, or session expiry
After destruction, data encrypted to NetworkSessionKey is permanently unrecoverable

Note: extractable: false per WebCrypto API prevents key export via JavaScript. This provides software-level non-extractability; hardware-level guarantees are not claimed. See Protocol: CMK Authentication for session binding details.

Notation Reference

Symbol	Description
SWE	Secure Web Enclave: the verifiable HTML/JS/WASM bundle executing in the browser
SRI	Subresource Integrity: browser security feature using cryptographic hashes to verify resource integrity
TWELVE-MAP	Self-verifying, Merkle-anchored directory mapping key IDs to ORK swarms
NetworkSessionKey	Ephemeral session private key used for all Tide-related operations
$\text{gNetPub}$	Session public key derived from `NetworkSessionKey`
VendorSessionKey	Ephemeral key for the vendor client app. Used for BRK proof signing and App cross-verification
VRK / gVRK	Vendor Random private/public Key - vendor's ephemeral key for encrypting VendorEncryptedData
BRK	Browser Key: persistent key stored in localStorage (only after App authentication) for device continuity
$n$	Total ORKs in a swarm (20)
$t$	Threshold for successful MPC outcome (14)
$Z_i$	ORK $i$ 's partial computational result
$L_i$	Lagrange coefficient for ORK $i$
$\pi_i$	ZK proof from ORK $i$ attesting correct computation
$\textsf{AES\_ENC}_{a}(B)$	AES256 encryption of message $B$ with key $a$
$\textsf{DH}(a, b)$	Diffie-Hellman shared secret derived from private key $a$ and public key $b$

Actors

Actor	Description	Trust Assumption
User	End user interacting via browser. Enters credentials into the SWE.	Potentially adversarial. The SWE protects credentials from all other parties.
Secure Web Enclave	Browser-delivered JS/WASM bundle. Dealer for all user-initiated sMPC sessions.	Operates as untrusted. Coordinates but cannot cheat. SRI ensures code integrity. ZK proofs ensure sMPC integrity. An honest SWE also verifies ORK outputs.
Vendor / TideCloak	Serves the SWE bundle (or delegates to Tide CDN). Routes OIDC flows.	Does not need to be trusted for code integrity (SRI) or cryptographic operations (ORKs verify independently).
ORK Swarm	20 nodes holding key shards. Compute partial results and produce ZK proofs.	Standard threshold trust ( $\leq 13$ may collude). Each ORK validates independently.
TWELVE-MAP	Distributed directory mapping keys to ORK swarms.	Entries verified by ZK proofs. Directory poisoning fails without forging proofs.

Layer Traversal

Layer	How the SWE Engages It
Legitimacy	SRI verification establishes code integrity. Session key generation establishes session identity. TWELVE-MAP proof verification establishes node authenticity.
Authority	The SWE requests key operations from ORKs. It never holds or reconstructs keys.
Agency	Primary layer. The SWE is the dealer for all Agency Layer operations: authentication, decryption, signing, delegation. It constructs requests, distributes them, and assembles results.
Settlement	The SWE submits cryptographic vouchers required by ORKs to process operations. Voucher validation is part of ORK request processing. See Article 8: The Settlement Layer.

Security Properties

Property	Mechanism	Assumption
Code integrity (SRI)	Browser-native SHA-256 verification. Tampered bundle → blocked execution.	Browser SRI implementation integrity
Minimal HTML structure	Single html/head/body/script - no injected scripts, iframes, or handlers. Verifiable by source inspection.	-
Untrusted dealer	SWE coordinates but cannot extract keys (receives only partial $Z_i$ ), forge proofs (lacks key material), or modify responses (proof verification detects tampering). A compromised SWE can only deny service.	DLP hardness
Credential capture mitigation	SRI prevents code replacement. Authenticator App (Protocol: Authenticator App) bypasses browser credential entry entirely.	SRI integrity; App availability for high-security deployments
Cyclical verification	SWE verifies ORK outputs ( $\pi_i$ ). ORKs verify SWE requests (Forseti, Doken). Protocol is open and SWE code is SRI-sealed. Neither trusts the other.	-
Session key isolation	Ephemeral, in-memory only (`extractable: false` via WebCrypto), never transmitted. Destroyed on session end.	Browser sandbox isolation; WebCrypto API integrity
Credential blinding	Raw credentials blinded via PRISM before any network transmission. ORKs process authentication without seeing the password.	OPRF security
ZK proof verification	Every ORK response independently verified. Invalid proofs → response rejected.	ZK parameter integrity
Origin-independent security	Trust anchor is the SRI hash, not the serving origin. Rehoming does not weaken security.	-
Threshold resilience	$\geq 14$ of 20 valid responses required. Fewer → operation fails safely.	$\leq 13$ compromised nodes
BRK conditional storage	BRK stored in localStorage only after Authenticator App authentication. Not stored for password-only flows.	-

Call Summary

Call	Direction	Purpose
Bundle delivery	Origin → Browser	Fetch HTML/JS/WASM bundle for browser-native SRI verification
TWELVE-MAP lookup	SWE → Directory	Resolve ORK roster for target key; verify mapping ZK proof
sMPC request	SWE → all $n$ ORKs	Distribute ECDH-encrypted operation payload (PRISM challenge, decryption request, or signing request)
Partial response	$I$ ORKs → SWE	Return partial results $Z_i$ and ZK proofs $\pi_i$
Result presentation	SWE → Client App / TideCloak	Deliver assembled result: redirect with VendorEncryptedData (auth), plaintext (decrypt), or signature (sign)

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