Ragnarök: Account Disposal | Cyber Immunity Whitepaper

Overview

Every other protocol in this series maintains a single invariant: the key never materializes. Keys are born fragmented (Protocol: Account Creation / KeyGen), maintained fragmented (Protocol: Key Healing, Protocol: PRISM Password Change, Protocol: Decentralized Account Recovery), and exercised fragmented (Protocol: CMK Authentication).

Ragnarök is the deliberate, sole deviation to the 'never assemble' invariant, but not as an exception, as it operates outside the Tide paradigm.

An exit protocol is essential to the trust model. A system that can never release keys creates vendor lock-in - a different form of centralized authority over the organization's data. Ragnarök ensures the organization retains ultimate sovereignty: it can depart the Tide network and operate independently, under governance-controlled conditions with verifiable completion. This deviation strengthens the architecture. Tide's value proposition must be sustained by operational merit, not by captive custody.

Ragnarök operates on the organization's VVK (Vendor Verifiable Key) - not on individual users' CMKs. The VVK governs JWT signing, authorization, and E2EE. It is reconstructed and exported as a standard EdDSA key; Tide-based authentication is disabled; users must re-establish credentials via mass password reset. The protocol supports two disposal paths: Scenario A (Off-Boarding) releases RGK shards directly to TideCloak, and Scenario B (Backup / "Nuclear Codes") distributes the reconstruction capability across the admin quorum so that no single actor ever holds the complete RGK.

Loading diagram...

Preconditions

Condition	Detail
VVK and RGK generated	Both keys created via Nested Shamir DKG (same construction as Protocol: Account Creation / KeyGen) during vendor onboarding. Each ORK holds $VVK_i$ and $RGK_i$ shards.
Encrypted VVK shards stored	Each ORK has pre-encrypted its VVK shard under $gRGK$ : $eVVK_i = \textsf{Enc}_{gRGK}(VVK_i)$ . These are stored on TideCloak, grouped per VRK cycle. TideCloak cannot decrypt without the RGK.
Ragnarök enabled	TideCloak extension active. Email collection mandated, duplicate emails prohibited, user database scanned.
Admin quorum configured	Tide-IGA active with a governance quorum ( $t > 0$ ). Multiple administrators required for Ragnarök authorization.

Protocol Flow

Phase 0: Setup (Ragnarök Enablement)

Loading diagram...

The organization prepares for its own exit at onboarding. Each ORK generates its VVK and RGK shards via the standard Nested Shamir DKG (see Protocol: Account Creation / KeyGen for the construction), encrypts its VVK shard under

gRGK

, and deposits the ciphertext on TideCloak. The RGK is purpose-built and dormant - never used for authentication, signing, or any operational task. It exists solely to enable Ragnarök.

Ragnarök enforces email collection and uniqueness during all subsequent user signups. This forward constraint ensures every user is reachable for the post-Ragnarök mass password reset.

Phase 1: Ragnarök Initiation (Governance Gating)

Loading diagram...

An admin initiates Ragnarök on TideCloak. TideCloak verifies that Tide-IGA is active and that a governance quorum with

t > 0

is configured. It creates a formal Ragnarök Draft requiring sequential approvals from

t

distinct administrators before the initiating admin can execute the Ragnarök Commit. The specific quorum mechanisms are detailed in Article 5: Governance Without God Mode.

After commit, TideCloak submits the fully signed approval to the VVK ORK swarm. Each ORK independently validates the governance signatures. The protocol then branches into one of two disposal scenarios.

Phase 2: VVK Disposal - Two Scenarios

Scenario A: Off-Boarding (Direct)

The simpler path - used when the organization is departing Tide and the RGK can be released directly.

Each ORK unlicenses the VRK (marking it invalid for future operations) and revokes it (destroying the distributed key's operational validity), then encrypts its dormant RGK shard under the vendor's ephemeral public key:

\textsf{ENC}_{gVRK}(RGK_i)

. These ciphertexts are returned to TideCloak, which decrypts them using

VRK

and interpolates the RGK shards to reconstruct the complete RGK. Revocation occurs before release - there is no window of dual validity.

The more secure path - distributes the reconstruction capability across the admin quorum so that no single actor (including TideCloak) holds the complete RGK until all parties converge.

Loading diagram...

After ORK-swarm approval, TideCloak creates a secondary Ragnarök init draft. Each admin independently requests their "Nuclear Codes" through the Secure Web Enclave (SWE). Each ORK verifies the approval, generates a deterministic admin-specific sub-share of its RGK shard (Algorithm 1), unlicenses and revokes the VVK, and returns the sub-share. The SWE interpolates the 20 sub-shares into a single consolidated

\text{admin\_share}

- this admin's fragment of the global RGK.

After an off-boarding period,

t

administrators contribute their shares to TideCloak, which interpolates them to reconstruct the complete RGK. The nested threshold ensures that reconstruction requires both an ORK quorum (inner, during share distribution) and an admin quorum (outer, during contribution).

Phase 3: VVK Recovery and System Transition

With the RGK reconstructed (from either scenario), TideCloak decrypts the pre-stored

eVVK

shards and assembles the complete VVK private key. The system then executes a clean transition: the reconstructed VVK is installed as a standard EdDSA signing key in TideCloak, the Tide-IdP is disabled, the VVK license cancellation is verified against the ORK network, authentication flows are replaced with standard (non-Tide) modules, IdP-less IGA is toggled on, and all user accounts are placed on mandatory password reset. TideCloak generates new

\text{SignedSettings}

designating itself as the Home ORK, permanently redirecting client software away from the decentralized network.

TideCloak prompts the admin to authorize a mass email dispatching password-reset links to all users - the operational reason Ragnarök mandated email collection and uniqueness from Phase 0.

Phase 4: Post-Ragnarök Operation

Loading diagram...

The system operates as a standard Keycloak deployment. Users authenticate via email-and-password credentials, receiving Dokens that embed TideCloak's URL as the Home ORK. Heimdall then continues to processes decryption and signing requests from the client using the recovered VVK as a conventional EdDSA key, with no ORK involvement.

Loading diagram...

Algorithms

Algorithm 1:

Deterministic Admin Share Generation (per ORK , Scenario B)

Input:

RGK_i

(this ORK's RGK shard),

Doken

(validated session token),

ORKkey_i

(this ORK's long-term key),

t_{\text{admin}}

(admin quorum threshold), admin index

a

Output:

\text{admin\_share}_i

(admin

a

's sub-share of

RGK_i

)

Derive deterministic Shamir coefficients: $c_0 \leftarrow \textsf{HMAC}(H(Doken),\ ORKkey_i)$ $\textsf{For } k = 1 \textsf{ to } t_{\text{admin}} - 1: \quad c_k \leftarrow H(c_{k-1})$
Shamir-split the RGK shard: $\textsf{SSS}(RGK_i,\ [c_0, c_1, \ldots, c_{t_{\text{admin}}-1}]) \rightarrow \{\text{share}_a\}_{a=1}^{|\text{admins}|}$
Extract the requesting admin's sub-share: $\text{admin\_share}_i \leftarrow \text{share}_a$

Deterministic consistency: The coefficients are derived from the

Doken

(shared across the ceremony) and the

ORKkey_i

(ORK-specific), via an HMAC-then-hash chain. Every ORK that holds the same

Doken

produces a polynomial whose evaluation points are compatible - admin

a

's sub-shares from all 20 ORKs can be Lagrange-interpolated by the SWE into a single

\text{admin\_share}

without any inter-ORK coordination.

Nested threshold: The complete RGK requires

t_{\text{admin}}

consolidated admin shares, each of which required interpolation across 20 ORK sub-shares. No single admin, no single ORK, and no single system component holds the complete RGK at any point.

Notation Reference

Symbol	Description
$VVK$ , $VVK_i$	Vendor Verifiable Key / ORK $i$ 's shard
$gVVK$	VVK public key
$RGK$ , $RGK_i$	Ragnarök Key (dormant, purpose-built) / ORK $i$ 's shard
$gRGK$	RGK public key
$eVVK_i$	Encrypted VVK shard: $\textsf{Enc}_{gRGK}(VVK_i)$ - stored on TideCloak
$gVRK$ , $VRK$	Vendor's ephemeral public / private key (Scenario A encryption)
$Doken$	Voucher-derived token; input to deterministic coefficient chain
$ORKkey_i$	ORK $i$ 's long-term key; paired with Doken in HMAC
$c_0, c_k$	Deterministic Shamir coefficients: $c_0 = \textsf{HMAC}(H(Doken), ORKkey_i)$ , $c_k = H(c_{k-1})$
$\textsf{SSS}(s, \mathbf{c})$	Shamir Secret Sharing with deterministic coefficients $\mathbf{c}$
$\text{admin\_share}_i$	Admin $a$ 's sub-share from ORK $i$
$\text{admin\_share}$	Admin $a$ 's consolidated RGK share (interpolated from 20 sub-shares)
$t$	Admin governance quorum threshold
$n$	ORKs in VVK swarm (20)
$\textsf{Enc}_K(M)$	Encryption of $M$ under key $K$

Actors and Trust Assumptions

Actor	Description	Trust Assumption
Admin (Quorum)	Authorize Ragnarök via multi-admin draft/approval/commit. In Scenario B, each admin receives and later contributes an RGK share.	Quorum assumption: no single admin can trigger Ragnarök. $t$ must act independently.
User	Not involved in the Ragnarök decision. Affected post-disposal: must re-establish credentials via email-based password reset.	-
SWE	Browser agent. In Scenario B: sends approved Ragnarök to ORKs, collects admin-specific sub-shares, interpolates into consolidated admin share.	Standard SWE trust. Handles one admin's sub-shares, never the complete RGK.
TideCloak	Vendor's IAM server with Ragnarök extension. Stores $eVVK$ . Orchestrates governance. Scenario A: receives RGK shards. Scenario B: collects admin shares. Post-Ragnarök: holds complete VVK as standard EdDSA key.	Under organization's control. Cannot decrypt $eVVK$ without RGK.
Ragnarök	TideCloak extension (plugin + DLL). Stores encrypted VVK shards, orchestrates Ragnarök workflows, hosts post-Ragnarök SWE replacement.	Within TideCloak's trust boundary.
Heimdall	Post-Ragnarök auth handler. Replaces ORK-based authentication; processes requests using recovered VVK as conventional EdDSA key.	Standard IAM trust.
ORK Swarm (VVK)	20 nodes holding VVK and RGK shards. Validate governance approval. Revoke VVK. Release RGK material (directly or as admin sub-shares).	Standard threshold assumption. Each ORK independently validates governance before releasing material.

Layer Traversal

Layer	How Ragnarök Engages It
Legitimacy	Multi-admin governance approval and ORK-swarm ratification qualify the Ragnarök request. In Scenario B, the Doken provides entropy for deterministic coefficient generation.
Authority	Primary layer. Ragnarök is the terminal Authority Layer operation - the disposal of key shares. Encrypted VVK shards are decrypted, RGK shards are released, the distributed VVK is permanently revoked. The key transitions from "fragmented across the Fabric" to "conventional key held by the organization."
Agency	Transitional. The VVK's purpose (JWT signing, authorization, E2EE) transitions from threshold MPC operations to standard single-key operations. Post-Ragnarök, Heimdall exercises the VVK as a conventional EdDSA key.
Settlement	The Doken participates in deterministic coefficient generation (Scenario B). Accountability is provided by governance audit trail and ORK dLog entries during revocation.

Security Properties

Property	Mechanism	Assumption
Governance-gated disposal	Multi-admin draft + sequential quorum approvals + commit + ORK-swarm ratification. No single actor can trigger Ragnarök.	Tide-IGA quorum integrity
Revocation before release	Each ORK unlicenses and revokes VVK before releasing RGK material. No window of dual validity.	-
Pre-encryption independence	$eVVK$ shards encrypted and deposited at setup. Ragnarök does not require all ORKs online at disposal time.	Encryption scheme security
RGK isolation	The Ragnarök Key is dormant from creation. Never used for authentication, signing, or any operational task. Zero operational attack surface.	-
Deterministic admin shares (Scenario B)	HMAC-chain-derived Shamir coefficients from $Doken + ORKkey$ . Consistent polynomials across ORKs without coordination.	SHA-256 collision resistance
Nested threshold (Scenario B)	Reconstruction requires admin quorum (outer) contributing shares, each interpolated from ORK sub-shares (inner). No single admin, ORK, or system holds complete RGK.	Shamir reconstruction hardness
Complete system transition	Tide-IdP disabled, standard EdDSA replaces threshold, email login enforced, all accounts require password reset. No hybrid state or residual Tide dependencies.	-
Email mandate as forward constraint	Ragnarök enforces email collection and uniqueness from signup. Ensures all users reachable for post-Ragnarök password reset.	-
Audit trail	Governance approvals, ORK ratification, VVK revocation all produce verifiable records (governance logs, dLog).	-
Irreversibility	After Ragnarök, the distributed VVK no longer exists. Returning to Tide requires new VVK generation.	-

Call Summary

Phase / Call	Direction	Purpose
Enable Backup	Admin → TideCloak	Activate Ragnarök. Trigger VVK+RGK generation.
Generate VVK + RGK	TideCloak → ORK Swarm	Nested Shamir DKG for both keys.
$eVVK$ storage	ORK Swarm → TideCloak	Pre-encrypted VVK shards deposited for future recovery.
Ragnarök draft/approval/commit	Admin Quorum ↔ TideCloak	Multi-admin governance ceremony.
Sign Ragnarök approval	TideCloak → ORK Swarm	ORKs validate governance signatures.
$\textsf{ENC}_{gVRK}(RGK_i)$	ORK Swarm → TideCloak	Scenario A: Direct RGK shard release (after VVK revocation).
Request Nuclear Codes	SWE → ORK Swarm	Scenario B: Admin requests deterministic sub-share.
$\text{admin\_share}_i$	ORK Swarm → SWE	Scenario B: Per-ORK sub-share (after VVK revocation).
$\text{admin\_share}$	SWE → Admin	Scenario B: Consolidated share after interpolation.
Admin share contribution	Admin Quorum → TideCloak	Scenario B: $t$ admins deposit shares for RGK reconstruction.
VVK decryption + transition	TideCloak (internal)	Decrypt $eVVK$ , install EdDSA key, disable Tide-IdP, enforce email login.
Mass password reset	TideCloak → All users	Email-based credential re-establishment.

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

Overview

Preconditions

Protocol Flow

Phase 0: Setup (Ragnarök Enablement)

Phase 1: Ragnarök Initiation (Governance Gating)

Phase 2: VVK Disposal - Two Scenarios

Scenario A: Off-Boarding (Direct)

Scenario B: Backup (Admin Share Distribution - "Nuclear Codes")

Phase 3: VVK Recovery and System Transition

Phase 4: Post-Ragnarök Operation

Algorithms

Algorithm 1:

Notation Reference

Actors and Trust Assumptions

Layer Traversal

Security Properties

Call Summary

References