Decentralized Account Recovery | Cyber Immunity Whitepaper

Overview

This document specifies the Decentralized Account Recovery ceremony - the protocol by which a user reclaims authority over their digital identity after losing access to their password or device. Recovery is user-initiated: the user provides their username, the ORK swarm independently dispatches recovery emails, and the user clicks a threshold (

t = 14

) of links to authorize the generation of a new PRISM secret.

Architecturally, this protocol is a different authorization front-end to the same PRISM DKG back-end used in Protocol: PRISM Password Change. The email challenge (Phases 1-4) replaces the ConvertPass PRISM preamble. Once

t

authorization tokens are collected, the DKG ceremony (Phases 5-8) is identical. Only the PRISM secret changes. The CMK, gCMK, VUID, gCMKAuth, and swarm membership are untouched.

The key cryptographic distinction from PRISM Password Change: recovery selfRequest tokens use two-layer encryption (AES_ORK → relay channel key), omitting the PRISMAuth layer that proves password knowledge. The email challenge replaces the password proof.

Loading diagram...

Preconditions

Condition	Detail
User	Knows their username. Has access to email inbox(es) registered during Protocol: Account Creation / KeyGen. Does not possess the current password.
Recovery emails established	During Account Creation, the SWE randomly assigned 1-20 user-provided email addresses across the 20 ORKs (one per ORK, with possible overlap). Each ORK stores its (single) assigned address as `CMKEmailAddress`. The SWE destroyed the mapping.
ORK swarm	Each ORK holds a committed record: `CMK_i` (unchanged), `gCMK` (unchanged), `PRISM_i` (to be replaced), `PRISMAuth_i` (to be replaced), `CMKEmailAddress`.

Protocol Flow

Phases 1-3: Recovery Authorization (Unique to This Protocol)

Loading diagram...

The relay pattern: The Home ORK establishes a relay channel (ChannelID, 1-hour TTL). When the user clicks an email link, the resulting HTTP request hits the Home ORK, which extracts the encrypted token and holds it. The SWE long-polls the Home ORK for updates, collecting tokens as they arrive. The SWE never exposes a direct public endpoint. The Home ORK provides deduplication (rejecting repeated mIdORK_i) and progress feedback ("N more links to go!").

Two-layer vs. three-layer encryption: In PRISM Password Change, selfRequest tokens are triple-encrypted (AES_ORK → ECDH → PRISMAuth), with the PRISMAuth layer proving password knowledge. In recovery, the PRISMAuth layer is absent because the password is lost. The email challenge - requiring

t

independent link clicks - replaces the password proof as the authorization gate.

Independent ORK dispatch: Each ORK independently retrieves its single stored CMKEmailAddress, constructs a recovery email with its own encrypted token, and sends it. No ORK knows which addresses other ORKs hold, whether the user will succeed, or which other emails were sent. The threshold requirement (14 of 20) ensures no partial compromise of email accounts suffices.

Phase 4: New Password Entry

Once

t

tokens are collected, the SWE prompts the user for a new password and blinds it:

gBlurNewPass = \textsf{H2P}(newPassword) \cdot r

where

H2P

is a deterministic string-to-curve mapping and

r

is a random blinding scalar. This blinded password point is used in the subsequent DKG ceremony to derive the new PRISM secret, without ever exposing the password or the PRISM secret in plaintext.

Loading diagram...

Phases 5-8: PRISM DKG (Shared with PRISM Password Change)

From this point, the protocol is identical to Protocol: PRISM Password Change, Phases 2-5.

Loading diagram...

Recovery-specific differences from PRISM Password Change:

UpdateShard goes to all

n

ORKs, not just the

I

that provided email tokens. ORKs without valid tokens set activeORK = false - they contribute PRISM shares (maintaining threshold health) but produce S_i = null (no partial group signature). The activeORK flag is determined by whether the user clicked that ORK's email link, rather than by ConvertPass participation.

Purpose codes: The local RecoveryRequest uses Purpose = "RECOVER" (ORK-level authorization token). The mimDB (Mimir Database - The Fabric's synced repository) PermissionMessage uses Purpose = "RESET" (same as Password Change). From the DKG and mimDB perspective, PRISM regeneration is identical regardless of the authorization front-end.

For the full specification of UpdateShard, SetPRISM, Test, and Commit internals - Schnorr verification, Accountable Group Signature construction, uncommitted/committed state management, SafeKeep packaging, mimDB write - see Protocol: PRISM Password Change, Phases 2-5.

Algorithms

Algorithm 1

Recovery Email Construction and Token Dispatch (per ORK )

Input:

\text{uid}

gSessKeyPub

HomeORKURL

ChannelID

CMKEmailAddress_i

aesKey_i

Output: Email dispatched,

\text{dLog}

entry recorded

$\textsf{Retrieve } CMKRecord(\text{uid}) \rightarrow CMKEmailAddress_i$
$RecoveryRequest \leftarrow (\text{uid},\ \text{"RECOVER"},\ gSessKeyPub,\ \textsf{now}() + 3600)$
$selfRequest_i \leftarrow \textsf{AES\_ENC}_{aesKey_i}(RecoveryRequest)$ - inner: self-sealed
$encRequest_i \leftarrow \textsf{Enc}_{gSessKeyPub}(selfRequest_i)$ - outer: session-bound
$link \leftarrow \textsf{BuildLink}(HomeORKURL,\ \text{"Assemble"},\ ChannelID,\ mIdORK_i,\ encRequest_i,\ \text{uid})$
$subject \leftarrow \text{"Tide account recovery - shard \#"} \| \textsf{Last6Chars}(H(ChannelID \oplus mIdORK_i))$
$\textsf{sendMail}(CMKEmailAddress_i,\ subject,\ link,\ \text{recovery template})$
$\textsf{dLog}(RecoveryRequested)$

Two-layer encryption (vs. three-layer in Password Change): Password Change wraps

selfRequest

in AES_ORK → ECDH → PRISMAuth (password proof). Recovery wraps

selfRequest

in AES_ORK → relay channel key (no password layer - email replaces password).

Algorithm 2

Email Token Collection (SWE, via Home ORK long-polling)

Input: Polling responses containing

(encRequest_i, mIdORK_i)

pairs from Home ORK
Output:

\{selfRequest_i\}_{i=1}^{I}

where

I \geq t

, or abort on timeout

$\textsf{For each polled } (encRequest_i, mIdORK_i) \textsf{ from Home ORK:}$
$\qquad \textsf{assert } mIdORK_i \in \text{swarm roster}$
$\qquad selfRequest_i \leftarrow \textsf{Dec}_{SessKey}(encRequest_i)$
$\qquad ORKsBitwise \leftarrow ORKsBitwise\ |\ \textsf{bit}(mIdORK_i)$
$\qquad I \leftarrow \textsf{popcount}(ORKsBitwise)$
$\qquad \textsf{DisplayProgress}(I, t)$
$\textsf{If } I \geq t: \textbf{ return } \{selfRequest_i\}$
$\textsf{If } \textsf{elapsed} > 3600\text{s}: \textbf{ abort}$ - relay channel expired

Home ORK collection logic (concurrent): For each email link click: parse

\rightarrow

store token

\rightarrow

deduplicate by

mIdORK_i

\rightarrow

display progress to user ("N more links to go!"). SWE long-polls to collect accumulated tokens. Terminate relay channel when clicks

\geq t

or timeout.

Recovery vs. Password Change vs. Healing: Architectural Distinctions

Property	Account Recovery	PRISM Password Change	Key Healing
Trigger	User lost access	User wants new password	ORK detects stale digest
Initiated by	User	User	System (automatic)
Old password required?	No	Yes	N/A
Authorization mechanism	Distributed email challenge ( $t$ link clicks) + CMK group signature	Old-password PRISM + CMK group signature	Pre-authorized SafeKeep records
`selfRequest` encryption	2 layers (AES_ORK → relay channel key)	3 layers (AES_ORK → ECDH → PRISMAuth)	N/A
Authorization window	1 hour	~30 seconds	N/A
What changes	PRISM secret, PRISM verifiers	PRISM secret, PRISM verifiers	Individual ORK's local share state
What doesn't change	CMK, gCMK, VUID, gCMKAuth, swarm	CMK, gCMK, VUID, gCMKAuth, swarm	CMK, gCMK, VUID, gCMKAuth, swarm
mimDB Purpose	"RECOVER"	"RESET"	N/A
User awareness	Explicit	Explicit	Transparent

Notation Reference

Symbol	Description
$\mathcal{G}$	Generator point on Curve25519
$A \cdot b$	Scalar-point multiplication
$H(\cdot)$	SHA-256 unless stated otherwise
$\textsf{DH}(a, B)$	Diffie-Hellman: $B \cdot a$
$\textsf{H2P}(\cdot)$	Hash-to-point (Elligator 2 on Curve25519)
$\text{uid}$	User identifier: $\text{uid} \leftarrow H(\text{username})$
$\text{gNewPass}$ , $\text{gBlurNewPass}$	New password-derived / blinded curve points
$r$	Blinding scalar for new password
$PRISM'_i$	ORK $i$ 's new random PRISM sub-secret
$PRISMY_i$	ORK $i$ 's combined new PRISM shard
$newPRISMAuth_i$	ORK $i$ 's new PRISM verifier: $\textsf{DH}(mSecORK_i, gNewPRISMAuth)$
$gNewPRISMAuth$	New PRISM auth base point: $\mathcal{G} \cdot H(\text{gNewPass} \cdot s')$
$CMK_i$ , $gCMK$	ORK $i$ 's CMK shard / user's CMK public key (unchanged)
$mSecORK_i$ , $mgORK_i$	ORK $i$ 's long-term private / public key
$aesKey_i$	ORK $i$ 's symmetric key
$mIdORK_i$	ORK $i$ 's public identifier
$ECDH_{ij}$	Pairwise shared secret between ORKs $i$ and $j$
$SessKey$ , $gSessKeyPub$ ( $U$ )	SWE's session private / public key
$\textsf{AES\_ENC}_{a}(B)$	AES256 encryption of message $B$ with key $a$
$\textsf{AES\_DEC}_{a}(B)$	AES256 decryption of message $B$ with key $a$
$\textsf{ENC}_{A}(B)$	X25519-based El-Gamal encryption of message $B$ with public key $A$
$\textsf{DEC}_{a}(B)$	X25519-based El-Gamal decryption of message $B$ with private key $a$
$ChannelID$	Recovery relay channel identifier on the Home ORK (1hr TTL)
$RecoveryRequest$	Auth structure: $(\text{uid}, \text{"RECOVER"}, gSessKeyPub, \text{expiry})$
$selfRequest_i$	Per-ORK authorization token (double-encrypted)
$encRequest_i$	session-key-encrypted $selfRequest_i$ (carried in email link)
$activeORK$	Boolean: was this ORK's email link clicked and token validated?
$CMKEmailAddress_i$	ORK $i$ 's stored recovery email (from Account Creation)
$n$ , $t$ , $I$	Swarm size (20), threshold (14), tokens collected
$S$ , $S_i$	Aggregate / partial Accountable Group Signature
$gR$ , $gR_i$	Aggregate / partial signature nonce
$mDigest$	Digest: Current key's Accountable Group Signature digest of participating ORKS: $H(ORKsBitwise\ \\|\ PermissionMessage)$
$ORKsBitwise$	Bitwise array of participating ORKs

Actors and Trust Assumptions

Actor	Description	Trust Assumption
User	Has lost access. Provides username, clicks email links, enters new password. Does not possess current password.	-
Vendor Site	Triggers SWE rendering. Not otherwise involved.	Standard web trust.
Secure Web Enclave	Browser agent. Orchestrates email challenge, collects tokens via long-polling, executes PRISM DKG, test sign-in, Commit.	Potentially adversarial. Cannot bypass threshold - needs $t$ valid tokens.
Home ORK	Entry point. Provides roster, establishes recovery relay channel, collects link clicks, deduplicates, enforces 1hr timeout.	No elevated trust. Cannot forge tokens or route clicks to wrong SWE (session-bound).
CMK ORKs ( $n = 20$ )	Each independently dispatches recovery email, validates tokens, generates PRISM shares, signs state transition.	Up to 13 may collude. Zero ORK-to-ORK communication during email dispatch.
User Email	Delivers recovery emails to user.	Adversary has no access to threshold number of user's email accounts. Each Email system reliable but not confidential. Compromised email sees links but cannot forge/decrypt selfRequests (AES_ORK sealed).
mimDB	Stores updated key record in Fabric's repository.	Append-only integrity.

Layer Traversal

Layer	How Recovery Engages It
Legitimacy	ECDH session establishment. Long-polling relay collects email link clicks. Voucher validation for DKG operations.
Authority	Primary layer for Phases 5-8. PRISM shares generated, distributed, combined, stored via Nested Shamir DKG. Old PRISM replaced atomically at commit. CMK untouched.
Agency	Not engaged during email authorization (Phases 1-4). No MPC operation. Engaged during test sign-in (Phase 7): blind signature verifies new PRISM.
Settlement	Vouchers govern and fund email recovery, DKG and Commit operations.

Security Properties

Property	Mechanism	Assumption
Threshold email authorization	Recovery requires $t = 14$ independent selfRequest tokens. Attacker needs access to email accounts linked to $\geq 14$ distinct ORKs.	Threshold assumption
No password exposure (new)	New password blinded as $\text{gBlurNewPass}$ . No ORK sees raw password point. Old password never used or transmitted.	Blinding scalar randomness
CMK preservation	CMK, gCMK, VUID, gCMKAuth, swarm membership unchanged. Only PRISM and verifiers replaced.	-
CMK-based authorization	Group signature uses $keyAuth = gCMK$ and $CMK_i$ shards. Email proves identity; CMK proves swarm authorization.	DLP hardness
No key reconstruction	DKG generates new PRISM shares. Complete PRISM and complete CMK never materialize.	-
Independent ORK email dispatch	Each ORK independently constructs and sends its email. No coordinator, no central mail gateway.	SMTP availability
Encrypted authorization tokens	selfRequests double-encrypted (AES_ORK → relay channel key). Email provider can inspect link URL but cannot forge or decrypt payload.	AES security
Relay isolation	SWE not directly exposed. Home ORK terminates link callbacks and holds tokens for long-polling collection.	-
1-hour temporal bound	RecoveryRequest expiry and relay channel timeout = 3600s. Limits attack window for compromised inboxes.	Accurate ORK clocking
Audit trail	`dLog(RecoveryRequested)` at each ORK. Distributed tamper-evident record of recovery attempts.	dLog integrity
Active/passive ORK separation	Only ORKs whose email links were clicked produce partial group signatures. Passive ORKs contribute PRISM shares but not authorization.	-
Two-phase commit	Uncommitted state until test sign-in succeeds. Old password remains valid until explicit commit.	-
SafeKeep for absent ORKs	Missing ORKs' new PRISM shares packaged as SafeKeep records, healable via Protocol: Key Healing.	ECDH + AES security
Transport-independent security	All token encryption via ECDH/AES, not TLS. Security independent of email or transport confidentiality.	-

Call Summary

Call	Direction	Purpose
`GetKeyORKs`	SWE → Home ORK	Retrieve swarm roster. Establish recovery relay channel ( $ChannelID$ , 1hr TTL).
`RequestRecovery`	SWE → all $n$ ORKs	Each ORK builds double-encrypted selfRequest, dispatches recovery email, logs `dLog`.
Email link relay	Home ORK → SWE (via long-polling)	Per click: parse, deduplicate, hold for SWE poll. Return $(encRequest_i, mIdORK_i)$ when polled.
`UpdateShard`	SWE → all $n$ ORKs	PRISM DKG round 1. `numKeys=1`, `null` swarm, `gBlurNewPass`, `selfRequest_i` as auth.
`SetPRISM`	SWE → $I$ ORKs	PRISM DKG round 2. Share distribution, Schnorr proofs, group signature, uncommitted state.
`SignIn`	SWE → $I$ ORKs	Test authentication with new password against uncommitted state.
`Commit`	SWE → $I$ ORKs	Verify aggregate signature, transition to committed, mimDB write, archive.

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