Key Healing | Cyber Immunity Whitepaper

Overview

This document specifies the Key Healing protocol - a system-initiated mechanism that detects degraded share sets and restores absent ORKs' Shamir shares from encrypted mimDB backups, without reconstructing the key, without user involvement, and without any awareness of what key type is being restored.

Key Healing is triggered opportunistically during normal API processing. When an ORK receives any key-related call, it compares its local state of key's-swarm participatis (as encapsulated in the digest) against the mimDB's authoritative digest (piggybacked on the call by the Secure Web Enclave). A mismatch initiates healing - the ORK queries the mimDB for its missing SafeKeep records, decrypts them using pairwise ECDH, verifies Schnorr proofs and the Accountable Group Signature, and writes the recovered shares directly as committed state. The calling Secure Web Enclave (SWE) and user are unaware that healing occurred.

The protocol operates entirely at the Authority Layer and demonstrates pure key-type agnosticism: the same for m=1 to q loop heals CMK shares, PRISM shares, VVK shares, and CVK shares identically. No Agency Layer operation (MPC, signing, decryption) occurs. At no point does the complete key materialize.

Loading diagram...

Preconditions

Condition	Detail
SafeKeep records exist	Created during Protocol: Account Creation / KeyGen, Protocol: PRISM Password Change, or any key operation where the healing ORK was absent. Participating ORKs package the absent ORK's shares, encrypted under pairwise ECDH ( $\textsf{DH}(mSecORK_{\text{origin}}, mgORK_{\text{absent}})$ ), and write them to the mimDB during Commit.
mimDB state	Holds the authoritative key record (Participating ORKs digest $M$ , public key, swarm roster, Accountable Group Signature) and the signed SafeKeep packages for the absent ORK.
Healing ORK	Online, possesses its private key $mSecORK_i$ , but holds a stale local digest ( $CMKRecord.M \neq mDigest$ ).

Protocol Flow

Phase 0: Digest Mismatch Detection (Trigger)

Loading diagram...

The SWE passes the key's mDigest (obtained from the Home ORK's TWELVE-MAP response) alongside any normal API call. The ORK compares this against its locally stored digest to detect if its state is stale. No separate healing daemon or scheduled sync exists - detection is piggybacked on operational traffic.

Phase 1: SafeKeep Retrieval from mimDB

Loading diagram...

The mimDB's short-circuit check (M == CMKRecord.M) handles race conditions where the TWELVE-MAP digest was temporarily stale. If the ORK missed multiple operations,

B > 1

broken records are returned.

Loading diagram...

Direct-to-committed rationale: Unlike Account Creation (which uses an uncommitted → committed two-phase commit because the DKG outcome is uncertain), healing integrates data that has already passed through the full commit process on mimDB. The Accountable Group Signature and Schnorr proofs were verified by the mimDB at original-commit time and are re-verified by the healing ORK here.

PubAuth = "": The per-ORK verifier field (e.g., PRISMAuth_i for PRISM keys) is stored empty. The PRISM verifier depends on the password-PRISM product, which is only available during live authentication. It will be derived on the user's next BYOiD ceremony. This does not affect the share itself.

Multi-record iteration: If

B > 1

, the healing ORK processes records sequentially, catching up through each missed operation in order.

Phase 3: Resume Normal Operation

Once all broken records are processed, the healing ORK's local state matches the mimDB's authoritative record. The ORK resumes the API call that originally triggered the digest mismatch. The SWE and user experience only a minor one-time latency increase.

Loading diagram...

Algorithms

Algorithm 1

SafeKeep Decryption and Share Combination (per broken record)

Input:

SafeKeep

record containing

J

contributing ORKs' encrypted shares,

mSecORK_i

(healing ORK's private key)
Output:

\{Y[m]\}_{m=1}^{q}

(combined shards per key type),

\{gK[m][z], gR[m][z], S[m][z]\}

(Schnorr proofs)

ECDH derivation: $ECDH_{ij} \leftarrow \textsf{DH}(mSecORK_i,\ SafeKeep.OriginGORK_j) \quad \forall j \in [1..J]$
Decrypt share ciphertexts: $(keyID_j, \tau_j, \{Y[m]_j\}_{m=1}^{q}, \{gK[m]_j\}, \{gR[m]_j\}, \{S[m]_j\}, activeOrigin_j) \leftarrow \textsf{AES\_DEC}_{ECDH_{ij}}(SafeKeep.YijCipher_j) \quad \forall j$
Combine shares per key type: $Y[m] \leftarrow \sum_{j=1}^{J} Y[m]_j \quad \forall m \in [1..q]$

The loop over

q

key types is key-type agnostic - the algorithm applies identical arithmetic to CMK shares (

m=1

), PRISM shares (

m=2

), and any additional key types without distinguishing them.

Algorithm 2

Schnorr Verification and Record Adoption (per broken record)

Input: Decrypted contributions

\{gK[m][z], gR[m][z], S[m][z], \tau_z\}

, mimDB record

(gR, S, M, ORKsBitwise)

Output: Verified aggregated public keys

\{gK[m]\}

, or abort

Per-contribution Schnorr verification: $\textsf{For } m = 1 \text{ to } q, \text{ for } z = 1 \text{ to } J:$ $\quad \textsf{assert}\bigl(\mathcal{G} \cdot S[m][z] \stackrel{?}{=} gR[m][z] + H(gR[m][z],\ gK[m][z],\ \tau_z) \cdot gK[m][z]\bigr)$ $\quad \textsf{If pass: } gK[m] \leftarrow gK[m] + gK[m][z]$ $\quad \textsf{If fail: dLog entry, SLA report, abort}$
Accountable Group Signature verification: $\textsf{assert}\bigl(AccountableKey.\textsf{verifySig}(gR, S, M)\bigr)$ $\textsf{If fail: abort}$
Write directly as committed: $\textsf{AddLocalEntry.User}(keyID, gK[1], gR, \text{"RECOVER"}, ORKsBitwise, \textbf{committed})$ $\textsf{For } z = 1 \text{ to } n: \textsf{FindOrAddLocalEntry.ORKS}(mIdORK_z, mgORK_z, \textbf{committed})$ $\textsf{For } z = 1 \text{ to } n: \textsf{AddLocalEntry.Assoc}(keyID, ORKidx_z, \textbf{committed})$ $\textsf{For } m = 1 \text{ to } q: \textsf{AddLocalEntry.Keys}(keyID, Type\!=\!m, Y[m], PubAuth\!=\!"", \textbf{committed})$

Healing vs. Recovery: Architectural Distinction

Key Healing (this protocol) and Account Recovery (Protocol: Decentralized Account Recovery) both restore share state, but serve different actors through fundamentally different mechanisms:

Key Healing is system-initiated. It occurs when infrastructure (an ORK) identifies it lost its state due to outage. The ORK detects the drift via digest mismatch (where digest encapulates the exact state of the participating ORKs) and repairs its own share from encrypted backups awaiting at other ORKs. No user active involvement. The original swarm and threshold remain intact. Shares are the same ones pre-computed during the original ceremony.

Account Recovery is user-initiated. It occurs when a user loses their password or device. The user proves identity via secondary factors (e.g., cryptographic email loop). The protocol generates entirely new key shares and a new PRISM state - potentially assigning the user to a new ORK swarm - without assembling the key.

Healing repairs the network's operational state. Recovery reclaims the user's authoritative access.

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$
$keyID$	Key identifier (e.g., $H(\text{username})$ for a CMK)
$mSecORK_i$	Healing ORK's long-term private key
$mgORK_i$	Healing ORK's long-term public key: $\mathcal{G} \cdot mSecORK_i$
$mIdORK_i$	Healing ORK's public identifier
$OriginGORK_j$	Public key of contributing ORK $j$ that created the SafeKeep record
$ECDH_{ij}$	Pairwise ECDH shared secret: $\textsf{DH}(mSecORK_i, OriginGORK_j)$
$mDigest$	Current key's Accountable Group Signature digest of participating ORKS, as taken from the Home ORK's TWELVE-MAP response
$CMKRecord.M$	The healing ORK's locally stored digest
$YijCipher$	Encrypted share ciphertext in a SafeKeep record
$Y[m]$	Healing ORK's combined shard for key type $m$
$gK[m]$	Aggregated public key for key type $m$
$gK[m][z]$ , $gR[m][z]$ , $S[m][z]$	Contributing ORK $z$ 's public key, Schnorr nonce, and Schnorr signature for key type $m$
$gR$ , $S$	Aggregate nonce and signature from the original Accountable Group Signature
$q$	Number of key types being healed (e.g., $q=2$ for CMK + PRISM)
$B$	Number of broken records (missed key operations)
$J$	Number of contributing ORKs in a SafeKeep record
$n$ , $t$	Swarm size (20), threshold (14)
$ORKsBitwise$	Bitwise array of ORKs that participated in the original ceremony
$\textsf{AES\_DEC}_{a}(B)$	AES256 decryption of message $B$ with key $a$

Actors and Trust Assumptions

Actor	Description	Trust Assumption
SWE	Client-side agent. Passes `mDigest` to ORKs during normal API calls. Not involved in healing orchestration - unaware healing is occurring.	Minimal role. Cannot influence the healing outcome.
Home ORK	Serves swarm roster and current key's digest via the TWELVE-MAP.	No elevated trust. A compromised Home ORK could provide a stale digest (delaying healing), but cannot compromise key material.
Healing ORK	The primary actor. Detects mismatch, queries mimDB, decrypts SafeKeep records, verifies integrity, writes committed state.	Must possess $mSecORK_i$ to decrypt SafeKeep records. Standard ORK trust.
Other ORKs	Stores key SafeKeep packages. Returns records to the healing ORK. Already verified Accountable Group Signatures and SafeKeep proofs at original-commit time.	Stores healing ORKs shards in unaccessible encrypted form. Standard ORK trust.
mimDB	Mimir Database - The Fabric's synced authoritative registry. Stores key records.	Append-only registry integrity.
TWELVE-MAP	Tide Wide Enumerated Ledger of Verifiable Entries - Mapping Authoritative Pointers is the self-verifying directory service on mimDB mapping key identifiers to ORK swarms.	Each entry includes a ZK proof attesting to its authenticity against the master registry.
Contributing ORKs (implicit)	Created SafeKeep records during the original ceremony. Not contacted during healing.	Integrity verified at original commit (mimDB signature check) and re-verified during healing (Schnorr proofs).

Layer Traversal

Layer	How Healing Engages It
Legitimacy	The triggering API call and TWELVE-MAP key lookup use standard Tide legitimacy mechanisms (ECDH session, Doken).
Authority	Primary layer. Healing restores Shamir shares - the Authority Layer's core responsibility. The $\text{for } m = 1 \text{ to } q$ loop processes all key types uniformly, maintaining key-type agnosticism.
Agency	Not engaged. Healing restores key existence, not key purpose. No MPC, signing, or decryption occurs. Agency operations resume after healing completes.
Settlement	Minimally engaged. No new vouchers required. The original ceremony was funded by the vendor; SafeKeep records exist because that ceremony was properly settled.

Security Properties

Property	Mechanism	Assumption
No key reconstruction	The ORK computes its own Shamir share ( $Y[m] = \sum Y[m]_j$ ). The complete key is never assembled.	Threshold ( $< 14$ compromised)
Encryption at rest (SafeKeep)	Records encrypted via pairwise ECDH ( $\textsf{DH}(mSecORK_{\text{origin}}, mgORK_{\text{absent}})$ ). Only the intended ORK can decrypt. ORK's database stores ciphertext only.	ECDH + AES security
Fraud detection	Schnorr proof verification on each contributing ORK's public key contribution. Failure → dLog + SLA report + abort.	DLP hardness
Accountable Group Signature verification	Composite key record verified against the mimDB's endorsed Accountable Group Signature before adoption.	Registry integrity
Key-type agnosticism	The $\text{for } m = 1 \text{ to } q$ loop processes all key types uniformly. No metadata about key purpose is exposed.	Architectural design
Opportunistic, zero user latency	Triggered during normal API calls via piggybacked digest comparison. No separate daemon, scheduled task, or user action.	-
Multi-operation catch-up	$B > 1$ broken records processed sequentially in a single healing pass.	-
Direct committed state	Data already validated via two-phase commit at original ceremony time. No uncommitted phase needed.	mimDB transaction finality
Audit trail	`ChangePurpose = "RECOVER"` distinguishes healed records from live-ceremony records.	Local DB integrity
Replay resistance	Digest comparison ( $CMKRecord.M \neq mDigest$ ) ensures healing only when needed. Short-circuit check resolves race conditions.	Hash collision resistance
Transport-independent security	SafeKeep encryption uses ECDH, not TLS.	-
PRISM verifier gap	`PubAuth = ""` for healed keys. PRISM verifiers are password-dependent and regenerated on next authentication - shares themselves are intact.	-

Call Summary

Call	Direction	Purpose
`keyLookup`	SWE → Home ORK	Retrieve swarm roster and current mimDB digest (`mDigest`).
`SomeAPICall`	SWE → Healing ORK	Any normal API call, carrying `mDigest`. Triggers digest comparison.
`HealKey`	Healing ORK → mimDB	Submit stale digest. Request missing SafeKeep records and the TWELVE-MAP state.
`BrokenRecords` / `YouAlreadyHaveLatest`	mimDB → Healing ORK	Return encrypted SafeKeep records ( $B \geq 1$ ), or confirm ORK is current.

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: Digest Mismatch Detection (Trigger)

Phase 1: SafeKeep Retrieval from mimDB

Phase 2: SafeKeep Decryption and Share Integration

Phase 3: Resume Normal Operation

Algorithms

Algorithm 1

Algorithm 2

Healing vs. Recovery: Architectural Distinction

Notation Reference

Actors and Trust Assumptions

Layer Traversal

Security Properties

Call Summary

References