SoK: Cryptographic Key Recovery for Cryptoasset Custody and Financial Technologies

SoK: Cryptographic Key Recovery for Cryptoasset Custody and Financial Technologies Francisco Javier Becerra Sanchez # University of Luxembourg, Luxembourg, Luxembourg

Antonio Ken Iannillo # University of Luxembourg, Luxembourg, Luxembourg

Radu State # University of Luxembourg, Luxembourg, Luxembourg

arXiv:2608.07104v1 [cs.CR] 7 Aug 2026

Abstract Cryptoasset systems often bind cryptographic key control to financial control: losing a wallet seed, custody share, hardware device, or smart-account credential can remove spend authority, while compromised recovery can enable theft. Existing work treats recovery through separate vocabularies–key backup, secret sharing, account recovery, credential re-issuance, social recovery, and asset migration–making mechanisms and tradeoffs difficult to compare. This paper presents a Systematization of Knowledge (SoK) on cryptographic key recovery for cryptoasset custody and financial technologies. Starting from a 118-paper systematic-review discovery corpus, we derive a 77-paper synthesis corpus and code each retained system in a master matrix covering recovered objects, recovery semantics, mechanisms, enrollment and storage, authorization, trust placement, failure events, post-recovery state, validation evidence, deployment status, privacy, usability, and limitations. The matrix supports an axis-first taxonomy that separates secret-restoring, hybrid, control-restoring, forensic/extractive, and framework-oriented recovery. Our central observation is that recovery is not a single operation: systems may reconstruct an original secret, regenerate a seed, restore a share, reissue a credential, migrate signing authority, restore account control, move assets, or extract forensic artifacts. We derive a generalized construction model, check it against production-facing designs, and identify six findings: recovery semantics are heterogeneous; recovery shifts trust; liveness improvements create abuse paths; post-recovery lifecycle management is uneven; protocol evidence outpaces user evidence; and recovery metadata remains underprotected. These gaps motivate a research agenda for recovery-aware financial technologies. 2012 ACM Subject Classification Security and privacy → Key management Keywords and phrases Cryptoasset Custody, Key Recovery, Wallet Security, Smart Accounts, Threshold Cryptography, Secret Sharing, Decentralized Identity, Secure Hardware Supplementary Material Collection (Reproducibility Package): https://github.com/franciscobecerra97/ Cryptographic-Key-Recovery-for-Financial-Technologies/tree/aft-2026-artifacts Funding This research was funded in part by the Luxembourg National Research Fund (FNR), grant NCER22/IS/16570468/NCER-FT, and by FinnovationHub, funded by the Ministry of Finance of the Government of Luxembourg. Acknowledgements The authors thank colleagues and reviewers for helpful feedback.

1

Introduction

In cryptoasset systems and related financial technologies, control of a cryptographic key can become control of financial value: loss may remove access to funds or services, while compromised recovery may transfer that control to an attacker. Key recovery is therefore part of the security boundary for systems that rely on cryptographic authorization [108, 90, 8, 93]. Recovery must balance two goals that pull against each other. It should prevent legitimate users and institutions from being permanently locked out after loss, unavailability, or

2

SoK: Cryptographic Key Recovery for Financial Technologies

operational failure. At the same time, it must not create a weaker path for theft, coercion, surveillance, insider abuse, or unauthorized transfer. This tension is the core reason recovery remains difficult: the mechanisms that improve availability also introduce new actors, records, and decisions that must be secured. Existing work proposes many mechanisms, but uses incompatible vocabulary. Recovery may mean restoring cryptographic material, changing account control, moving value, reissuing identity credentials, repairing custody roles, or extracting forensic artifacts. Comparisons can therefore obscure what is actually restored and what risks remain after recovery. This paper addresses that fragmentation through a Systematization of Knowledge (SoK) focused on cryptographic key recovery for cryptoasset custody and financial technologies. We center the paper on financial control, while including adjacent identity, data-protection, governance, and secure-hardware work when it contributes a recovery pattern that can transfer to financial systems. Recovery is not one operation. A useful comparison must ask what control is restored, who authorizes it, what failure it handles, and what state remains afterward.

1.1

Contributions

This Systematization of Knowledge makes the following contributions:

Financial-technology corpus and scope. We construct a 118-paper discovery corpus on key backup, recovery, and restoration, with auditable queries, screening flow, exclusion reasons, snowballing rounds, QA threshold, and manually verified LLM-assisted screening. We then derive a 77-paper synthesis corpus scoped around financial technologies while retaining transferable recovery patterns from identity, hardware, and data-protection systems. Recovery semantics for financial control. We distinguish secret-restoring recovery from control-restoring recovery and show why this distinction matters for financial systems. This clarifies when a system restores the same secret and when it instead restores financial control through a changed control relationship. A 77-system master matrix and codebook. We code every retained system using a controlled vocabulary for financial context, recovery semantics, mechanism family, enrollment and storage, failure events, authorization, trust placement, adversary model, post-recovery state, validation evidence, deployment status, privacy, usability, postquantum relevance, and limitations. Appendix A reproduces the complete per-system matrix, while the reproducibility package provides the machine-readable matrix and its codebook. Evaluation vocabulary, taxonomy, and construction model. We organize mechanisms by whether they restore secrets, restore control, combine both, perform forensic extraction, or define requirements. We define adversary classes and recovery-specific safety, liveness, and privacy properties, then derive a seven-stage construction model. Production practice checks and research agenda. We check the taxonomy against six production or standards-facing recovery designs and tie six findings to matrix counts and examples, including sparse user-study evidence, under-specified post-recovery hygiene, metadata leakage, custody boundaries, recovery economics, inheritance, and post-quantum migration.

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

1.2

SoK Framing and Novelty

Motivation for systematization The goal is not only to summarize prior mechanisms. We define comparable recovery semantics, code every retained system into the master matrix reproduced in Appendix A, and separate secret reconstruction from restored financial control. A threshold wallet that reconstructs an old seed, a smart account that rotates ownership, and a recovery service that moves assets are all recovery systems, but they leave different post-recovery states and abuse paths.

Novelty relative to closest related work Prior work usually studies one slice of the problem: cryptocurrency protocols and DeFi, wallet protocols and attacks, threshold recovery, deterministic or hardware-wallet designs, smart-account recovery, identity recovery, or forensic extraction. This SoK contributes a cross-domain comparison centered on recovery semantics rather than mechanism names. Its novelty claims are: (i) secret-restoring and control-restoring recovery should be evaluated separately; (ii) post-recovery state is a first-class security property for financial systems; and (iii) recovery evidence must connect cryptographic mechanisms with operational controls, metadata exposure, production practice, and human behavior. Table 1 compares the closest prior-work clusters.

2

Background and Scope

This paper uses the term cryptographic key recovery broadly, but not without distinction. In the corpus, recovery may mean reconstructing an original private key, regenerating a deterministic seed, restoring a key share, reissuing a credential, transferring signing authority, recovering account control, or moving assets to a new control path. These operations differ in what they restore and in the risks they introduce. The primary scope is financial technology: systems in which cryptographic material authorizes assets, transactions, account access, custody operations, or credentials used by financial infrastructure. This includes blockchain wallets, smart-contract accounts, custody systems, decentralized applications, decentralized identity, and secure hardware when they support financial control or transferable recovery patterns. The paper also considers non-financial work when it contributes a mechanism relevant to financial systems. Examples include identity-management recovery, data-protection recovery, governance-related recovery, and hardware-enforced recovery. These systems are included because financial technologies often reuse the same primitives and operational patterns: secret sharing, threshold reconstruction, deterministic derivation, secure elements, trusted authorities, biometric or physical anchoring, and delegated recovery.

3

Review Methodology and Corpus Construction

The contribution of this paper is the systematization, not the review protocol itself. We nevertheless used a systematic literature review (SLR) workflow as an auditable discovery process and then narrowed the final synthesis around recovery in cryptoasset custody and financial technologies.

3

4

SoK: Cryptographic Key Recovery for Financial Technologies

Table 1 Closest related-work clusters and this paper’s added recovery-semantics focus. Prior work

Scope

Recovery mantics

Financialcontrol treatment Protocol and market-level financial control

Corpus or evidence

This adds

Cryptocurrency and DeFi SoKs [6, 95, 105]

Protocols, DeFi primitives, risks, and incidents

Mostly indirect: key management, incidents, rescue windows, or mitigation

SoK syntheses and incident datasets

Recovery is a feature or fallback, not the organizing axis

Wallets as transaction interfaces and attack targets

Taxonomies, SLR evidence, and incident analysis

Dynamic access structures, threshold custody, HSMs, and operations

Access update, backup restoration, share reconstruction, or signer continuity

Central: assets must stay live without weakening controls

Formal constructions, prototypes, benchmarks, and cases

Web3 account recovery [108, 17, 5, 78, 22, 12, 58]

Guardians, fallback signatures, passkeys, presigned transfers, and composition

Concrete controlrestoring mechanisms

Direct wallet and smartaccount asset control

Mechanism papers, simulations, gas costs, and composability

Identity and WebAuthn recovery [90, 91, 59, 92, 34, 60]

SSI wallets, DID backup, backup authenticators, credential reissue, and share restoration

Credential or identity-control recovery

Transferable to regulated payments and account access

Prototypes, benchmarks, and formal analyses

Usability and keymanagement studies [96, 63, 86, 88]

Human coordination, wallet mental models, memory cues, seed phrases, and factor loss

User-facing ceremonies and factor handling

Often implicit through wallet access

Three retained user-study rows plus adjacent usability evidence

Recoveryspecific matrix for wallets, custody, smart accounts, identity, and forensics Recovered objects, secret/control axis, post-recovery state, and lifecycle evidence Cross-family comparison with regulation, economics, inheritance, production cases, and users Shows how control restoration differs from secret restoration and exposes hygiene/metadata gaps Separates identity restoration from asset-control recovery and maps transfer to finance Conservative user-evidence table and agenda for stress, death, phishing, and accessibility

Wallet taxonomies and security surveys [56, 46, 45, 24]

Wallet definitions, protocols, factors, attacks, and defenses

Custody and keymanagement work [101, 93]

3.1

se-

Guiding Questions

The review was guided by four questions: RQ1: What object or control relationship is recovered? RQ2: What cryptographic primitives, system architectures, and operational

paper

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 2 Database search audit. The table separates library exports from normalized screening input so reviewers can trace the corpus before snowballing and SoK-stage filtering. Database Scopus

Exported 218

Normalized 129

462

434

1,542

1,506

2,100

2,075

IEEE Xplore ACM Digital Library ScienceDirect

Syntax and filter note TITLE-ABS-KEY logical query; Computer Science, English, article/conference filters All-metadata logical query; English conference/journal records exported in BibTeX Full-record or metadata logical query; ACM BibTeX batch exports Title/abstract/keywords logical query; ScienceDirect BibTeX batch exports

procedures enable recovery? RQ3: What safety, liveness, privacy, usability, and trust tradeoffs are reported? RQ4: What open challenges remain for wallets, smart accounts, custody systems, decentralized identity, secure hardware, and related financial infrastructure?

3.2

Discovery Corpus

We searched Scopus, IEEE Xplore, the ACM Digital Library, and ScienceDirect for peerreviewed English-language computer-science papers on cryptographic key backup, recovery, and restoration. The search was run and exported on 14 October 2025. The logical query was: (“key” OR “private key” OR “cryptographic key”) AND (“recovery” OR “backup”) AND (“public key infrastructure” OR blockchain OR cryptocurrency OR wallet OR “self-sovereign identity” OR “decentralized identity” OR “identity management” OR “digital identity”).

The same logical query was adapted only for database field syntax and export format. Table 2 reports the database-specific search surface and counts. The SLR log records 13,637 initial database-interface hits before database-side filters; the local export audit contains 4,322 BibTeX records and 4,144 normalized records. The round-0 screening log contains 4,314 records after basic filters and 4,044 after duplicate removal. The initial title-and-abstract screening used a Large Language Model through an API as a decision-support tool: gpt-5 for title/abstract screening and gpt-5-mini for basic filtering of snowballing references. Each prompt included the candidate title and abstract, inclusion and exclusion criteria, and a request for an accept/reject verdict plus justification. Outputs were recorded as status and comments fields. Both LLM-assisted inclusions and exclusions were manually verified, and accepted records were reconciled into the round-level BibTeX files before quality assessment. The model scaled screening; it did not make final inclusion decisions. Backward and forward snowballing were applied until convergence: a final iteration produced no new snowballing references and left the retained primary-study count unchanged at 312. Table 3 reports the round-level counts. Table 4 summarizes grouped exclusion reasons. Title/abstract reasons were rule-coded from the manually verified decision comments. The final SoK-stage exclusions were coded from the full-text extraction rows.

3.3

Quality Assessment and Discovery Corpus

After snowballing convergence, 312 primary studies were retained for quality assessment. Each study was scored using five criteria: evidence and validation; cryptographic foundations

5

6

SoK: Cryptographic Key Recovery for Financial Technologies

Database search: 13,637 interface hits; 4,322 exported BibTeX records

Database/basic filters and duplicate removal: 4,314 after filters; 4,044 after duplicate removal in round 0

Title/abstract screening and manual verification: 312 unique primary studies after seven snowballing iterations

Quality assessment and ten-year cutoff: 118 discovery-corpus studies

Financial-technology synthesis filtering: 77 retained systems; 41 non-core discovery studies

Figure 1 Auditable corpus-construction flow. The key transition is from broad SLR discovery to a 77-system synthesis corpus used for taxonomy, matrix counts, and findings. Table 3 Screening and snowballing counts. Round 7 provides the stopping rule. RA = research articles or candidate references; BF = after basic filters; RD = after duplicate removal; IE = cumulative retained records after inclusion/exclusion screening; BS = new backward/forward snowballing references. Round 0 1 2 3 4 5 6 7

RA 13,637 1,949 1,620 950 511 375 332 317

BF 4,314 1,147 849 594 401 331 321 314

RD 4,044 817 623 478 360 321 315 313

IE 129 230 281 303 308 311 312 312

BS 1,820 1,390 668 208 67 21 5 0

and techniques; security analysis and limitations; proposed solution or contribution; and open problems or future directions. Each criterion was scored as yes (1.0), partial (0.5), or no (0.0). Applying the QA threshold retained 194 studies with score at least 4.0. Of these, 76 were pre-2016 foundational papers and are used as background where appropriate, while 118 had score at least 4.0 and publication year at least 2016. Those 118 studies form the discovery corpus used for full-text extraction and SoK narrowing.

3.4

Financial-Technology Synthesis Corpus

The 118-paper discovery corpus was intentionally broader than the final SoK needed to be. It included direct wallet and custody papers, but also adjacent work on generic key management, authentication, identity, hardware, cloud backup, and data protection. For the final synthesis, we therefore performed a second filtering step after full-text extraction. Each extracted paper was coded for recovered object, secret/control recovery axis, mechanism family, enrollment and storage, recovery trigger, failure-event class, authorization, trust placement, adversary model, post-recovery state, financial-technology context, validation evidence, deployment status, privacy, usability, post-quantum relevance, and limitations. We retained papers that described a concrete recovery, backup, restoration, transfer, re-issuance, or extraction mechanism; were directly financial or clearly transferable to financial control; and contained enough detail to compare recovery semantics and tradeoffs. We excluded papers where recovery was peripheral, generic without a financial-technology transfer, or not comparable along the SoK dimensions.

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

7

Table 4 Grouped exclusion reasons. The table distinguishes title/abstract screening exclusions from full-text SoK-stage exclusions, showing why records left the evidence base. Title/abstract exclusion reason Cryptographic security or authentication, but no recovery Adjacent domain, but no recovery mechanism Review or non-primary literature Unrelated application or out of scope Key generation/protection, not recovery of an existing key No cryptographic private-key or ownership context Insufficient or missing abstract

Count 2,119 1,866 434 359 279

SoK-stage exclusion reason Transferable non-financial background only Financial-adjacent but not core comparable recovery Requirements or background only

Count 28 9 4

108 15

Table 5 Two-stage corpus construction. Reviewers should read the 118 papers as the discovery corpus and the 77 retained papers as the evidence base for the SoK’s comparative claims. Stage SLR discovery

Financial-technology extraction

Role in the paper Identify peer-reviewed work on cryptographic key backup, recovery, and restoration through database search, manual verification, and snowballing. Retain papers with concrete recovery semantics and direct or transferable relevance to wallets, custody, smart accounts, decentralized identity, secure hardware, or financial infrastructure.

Result 118 papers

77 papers

This filtering reduced the corpus from 118 discovery papers to 77 synthesis papers. The excluded 41 papers were not treated as irrelevant; rather, they informed boundary-setting and background but were not used as core evidence for the taxonomy, counts, and cross-cutting findings. Figure 1 summarizes the full flow, while Table 5 summarizes the final two-stage construction.

4

Corpus Overview

The 77-paper synthesis corpus is the evidence base for the taxonomy, mechanism comparison, and cross-cutting findings. It is narrower than the 118-paper discovery corpus because the goal is to systematize mechanisms that restore cryptographic or financial control, not to catalog every paper that mentions key recovery. The retained studies are concentrated in self-custody and blockchain wallet settings, with additional evidence from institutional custody, permissioned blockchains, smart-contract accounts, decentralized identity, secure hardware, and forensic recovery. Categories are non-exclusive. The venue and validation mix affects how the counts should be read. The corpus is recent-heavy: 7 of the 77 synthesis rows are from 2016–2018, while the remaining rows are from 2019 or later, with 43 conference or symposium papers, 32 journal articles, and 2 workshop or CEUR papers. This makes the evidence strongest for mechanism comparison, protocol feasibility, and engineering validation. It is weaker for deployment prevalence, recovery under stress, and operational or user outcomes, which is why we report user-study and deployment evidence separately instead of treating prototype, proof, benchmark, and deployment rows as equivalent. Table 7 reports the confidence tiers used to interpret the venue and validation mix.

8

SoK: Cryptographic Key Recovery for Financial Technologies

Table 6 Non-exclusive corpus facets. Counts can exceed 77 within a facet when a study belongs to multiple categories. Facet Financial context

Recovered object

Validation evidence

Largest extracted groups Self-custody wallets (57), payment or permissioned blockchains (14), transferable non-financial patterns (15), institutional custody (11), DeFi or smart-contract applications (10), smartcontract accounts (9), decentralized identity for finance (8), secure hardware for financial infrastructure (8). Original private keys (34), signing authority (20), account control (19), seed or root secrets (15), asset ownership or transfer paths (13), key shares (10), recovery keys (5), credentials (3), forensic artifacts (3). Prototypes (56), benchmarks (50), formal proofs (28), simulations (17), security games (11), case studies (9), gas-cost measurements (7), user studies (3), no evaluation in the extracted evidence (6), operational deployment evidence (1).

The master matrix gives each retained system one auditable row covering the comparison dimensions, evidence fields, limitations, and SoK relevance. Table 8 compresses that matrix by the paper’s primary organizing axis. The reproducibility package provides the complete machine-readable matrix, its codebook, summary tables, and audit artifacts.

5

Recovery Semantics and Evaluation Vocabulary

Recovery mechanisms in the corpus do not all recover the same thing: some reconstruct a private key or seed, some repair a threshold role, some rotate account control, and some extract artifacts after an incident. We therefore compare each design using four recoverysemantics dimensions: the recovered object, the failure event, the authorization path, and the post-recovery state. These dimensions describe what is restored, why recovery is invoked, what evidence or actors authorize it, and what control relation remains afterward. The adversary classes and recovery properties at the end of this section are supporting evaluation lenses, not additional parts of the four-part framework.

Table 7 Venue and evidence confidence tiers used to interpret corpus counts. The tiers affect confidence in claims drawn from the counts, not whether a retained row is counted in the matrix. Confidence tier Higher for protocol soundness

Rows 28

Higher for external validity

5

Medium engineering evidence

40

Lower or contextual evidence

4

Count interpretation Strongest for cryptographic claims, safety arguments, and mechanism feasibility; weaker for deployed prevalence or user behavior. Stronger support for user, forensic, or operational observations, but still narrow relative to the breadth of wallet and custody practice. Useful for comparing implemented prototypes, benchmarks, and design tradeoffs; not enough to infer production reliability. Included for requirements, boundary-setting, or conceptual relevance; used cautiously and not as strong evidence for mechanisms.

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

9

Table 8 Compressed view of the 77-system master matrix by recovery axis. Recovery axis Secretrestoring

Rows

Dominant mechanisms

38

Hybrid secret/control

16

Threshold reconstruction, password/factorprotected recovery, biometric or fuzzy regeneration, TEE/HSMassisted recovery Deterministic regeneration, threshold continuity, institutional backup, social or guardian recovery

Controlrestoring

16

Forensic/ extractive

5

Framework/ requirements

2

5.1

Smart-contract control transfer, fallback or ownership proof, passkey/backup authenticator recovery, pre-signed asset evacuation Forensic artifact recovery and cryptanalytic key extraction

Requirements analysis and composability modeling

Typical postrecovery state Same or equivalent secret available; occasional share refresh or credential reset

Secret material is restored while signing authority, custody participation, or account control may also change New owner, credential, signing path, or asset-control relation replaces the failed path

Artifact, credential, or key is extracted from device, backup, memory, nonce failure, or investigation evidence No single postrecovery state; evaluates recovery obligations or composed mechanisms

Studies [52, 96, 106, 53, 98, 43, 3, 47, 81, 90, 72, 89, 67, 79, 91, 35, 87, 66, 65, 104, 61, 86, 84, 80, 73, 55, 51, 102, 41, 103, 99, 48, 71, 10, 33, 9, 11, 18] [42, 69, 23, 7, 54, 68, 57, 78, 100, 59, 85, 93, 34, 77, 60, 20]

[108, 101, 107, 19, 17, 13, 8, 5, 4, 70, 21, 22, 94, 92, 88, 58]

[16, 62, 44, 49, 50]

[76, 12]

Recovered object

Recovery may reconstruct an original private key or seed, restore a share or signing role, restore account control or asset ownership, or extract forensic artifacts. Mechanisms include passwordprotected shares, threshold reconstruction, deterministic regeneration, biometric or physical regeneration, hardware-assisted retrieval, contracts, fallback keys, backup authenticators, pre-signed transactions, and ownership proofs. Table 8 lists retained studies by recovery axis, Appendix A gives the full row-level coding, and Table 9 gives representative mechanism examples.

5.2

Failure event

The corpus covers several failure modes: loss of a local key, seed, device, mnemonic, or share; unavailability of threshold participants or custody roles; loss or compromise of smart-account owners; failed identity-wallet migration or backup restoration; and post-incident forensic recovery. Table 10 summarizes how these failure modes map to adversary classes. A recurring limitation is that many designs focus on loss but give less detail for compromise, coercion, malware, or malicious recovery helpers.

10

SoK: Cryptographic Key Recovery for Financial Technologies

Recovery designs in financial technologies

Secret-restoring

Hybrid secret/control

Controlrestoring

Forensic/ extractive

Framework/ requirements

Threshold/password shares biometric or hardware same-secret recovery

Share continuity deterministic regeneration institutional backup

Smart-account transfer hot/cold control proofs pre-signed evacuation

Forensic artifacts cryptanalytic extraction

Requirements composability analysis

SoK lenses applied to every retained system Semantics object, event, authorization, state

Trust/adversary trust placement, failure classes

Properties safety, liveness, privacy

Evidence/lifecycle validation, users, hygiene

Figure 2 Roadmap of the SoK taxonomy and lenses. The top tree groups recovery designs by the promise they make; the bottom lenses are applied to every retained system in the matrix and used in the tradeoff analysis.

5.3

Authorization path

Recovery is authorized by different evidence of legitimacy. Depending on the family, authorization may require enough shares or servers, a memorized or factor-derived credential, retained root material, biometric helper data, guardian approval, contract timeouts and challenges, pre-authorized transactions, organizational procedures, hardware controls, or custody roles. The authorization basis matters because it determines who can approve recovery, who can block it, and what evidence remains after the event.

5.4

Post-recovery state

The post-recovery state is often under-specified. Some protocols return the same secret and continue with unchanged keys [52, 106]; some repair or refresh shares while preserving threshold signing authority [69, 59]; some restore access by rotating credentials or moving control to a new key [108, 22]; and some transfer assets away from a failing account [70, 58]. For financial technologies, this distinction is material: a user, exchange, or smart account that rotates ownership after recovery has a different audit and dispute problem from one that reconstructs the old private key.

5.5

Supporting adversary vocabulary

We also normalize the threat vocabulary used across papers, because terms such as “lost key,” “recovery,” and “compromise” otherwise mix different financial risks. We distinguish eight recurring classes. Loss means the legitimate party no longer has usable access to a key, seed, credential, device, share, passkey, or signer. Compromise or theft means that the material may be copied, stolen, malware-exposed, or attacker-controlled. Coercion means that a user, guardian, provider operator, or institutional signer is pressured to approve recovery or disclose recovery material. A malicious helper is a guardian, shareholder, trustee, server, or custody participant who deviates from the recovery protocol alone or in collusion. Server or provider abuse covers wallet providers, cloud backup services, identity verifiers, recovery providers, HSM operators, and infrastructure services that misuse their role or metadata. An institutional insider is an organizational actor such as an administrator,

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

treasurer, support agent, compliance role, or recovery officer who misuses delegated recovery authority. Unavailability means that a user, helper, server, blockchain, signer, network, device, or institution cannot participate when needed. A forensic adversary attempts to extract wallet artifacts, keys, backups, traces, or evidentiary control material from devices or services.

5.6

Recovery-specific properties

Finally, we evaluate each design through three recovery-specific properties. Safety means unauthorized parties cannot trigger recovery, reconstruct a secret, rotate control, evacuate assets, or exploit recovery metadata to steal financial control. Liveness means a legitimate claimant can complete recovery after loss, participant churn, device replacement, institutional outage, or disaster without relying on a single fragile actor. Privacy means the recovery process does not unnecessarily reveal helper relationships, provider choices, account linkage, recovery attempts, identity-proofing material, device replacement, or forensic traces.

6

Taxonomy of Key Recovery Mechanisms

Table 9 is axis-first: mechanism families are nested under the recovery semantics they primarily realize. This avoids grouping systems once by cryptographic primitive and again by design family. The primary recovery axis is mutually exclusive and assigned by the final recovery promise and post-recovery state recorded in Appendix A. Mechanism families remain non-exclusive because some systems combine mechanisms, such as threshold reconstruction inside a hardware wallet or backup-authenticator recovery inside a smart account. Citation columns are representative; exhaustive row-level coverage appears in Appendix A. The primary split is between secret-restoring and control-restoring recovery. Secretrestoring mechanisms preserve the old control relation by reconstructing or regenerating the same key, seed, or share. Control-restoring mechanisms intentionally create a new control relation, for example by moving an account owner, registering a backup authenticator, executing a pre-signed transaction, or proving ownership to migrate assets. Hybrid systems combine both promises, such as restoring a share while also preserving institutional signing authority or social-account control. Control-restoring designs are not weaker merely because they do not reconstruct the original secret; they make a different promise and need different post-recovery checks. Figure 2 summarizes the taxonomy spine and the lenses applied to each retained system. The taxonomy also separates cryptographic trust distribution from operational trust distribution. Threshold systems distribute cryptographic material but still need participant governance, refresh, authentication, and availability. Hardware systems reduce software exposure but concentrate trust in devices, attestation, or recovery artifacts. Social recovery and smart contracts reduce single-custodian dependence but add guardian, metadata, liveness, and irreversibility risks.

7

Mechanism-Family Tradeoff Analysis

Using the matrix in Appendix A and the axis-first taxonomy, we compare safety and liveness surfaces, post-recovery hygiene and metadata privacy, and validation evidence. Table 9 gives the axis-level mechanism comparison, Table 10 adds the adversary lens, and Table 11 summarizes the obligations that follow after recovery. The family tables are cross-cutting

11

12

SoK: Cryptographic Key Recovery for Financial Technologies

Table 9 Axis-first taxonomy and design comparison. Mechanisms that reconstruct a secret, rotate control, move assets, or extract evidence make different recovery promises. Axis

Mechanism family

What recovery restores

Secretrestoring

Threshold, passwordprotected, and factor-assisted reconstruction Memory-based, biometric, fuzzy, and hardwareassisted regeneration Share continuity, social/delegated recovery, biometric helper-key regeneration, and institutional disaster recovery Deterministic hot/cold signingauthority recovery

Same key, seed, mnemonic fragment, or share

Secretrestoring

Hybrid secret/control

Controlrestoring

Controlrestoring

Controlrestoring

Smart-contract transfer, fallback signing, passkey recovery, credential re-issuance, and ownership proof Asset evacuation and pre-authorized transfer

Same or equivalent wallet-control secret

Enrollment or storage pattern Distributed shares, password/factor material, protected server shares, backup fragments Memory artifact, helper data, biometric source, secure element, HSM, or TEE

Examples [52, 96, 106, 53, 98, 66, 55, 103, 99, 10] [81, 72, 65, 86, 51, 48, 71, 33]

Secret material plus signing role, custody role, account access, or wallet-governance authority

Committees, guardians, biometric helper keys, organizational media, custody procedures, or DID backup stores

[42, 69, 7, 78, 59, 93, 34, 77, 60]

Future signing authority after hot-key compromise, without reconstructing the compromised hot key Account owner, signer, backup credential, ownership proof, or control path

Cold-wallet seed or master state, derivation path, and synchronized wallet state

[19]

On-chain state, fallback keys, backup authenticators, challenge windows, re-issuance, or proofs

[108, 101, 17, 13, 5, 21, 22, 94, 92]

Pre-signed transactions, emergency controls, provider state, or encrypted transfer material Device access, backups, memory, nonce failures, investigation workflow, or seized evidence Requirements model, key-person analysis, or formal composition model

[70, 58]

Value or asset-control relation moved away from a failed path

Forensic/ extractive

Forensic artifact recovery and cryptanalytic extraction

Wallet artifacts, credentials, keys, or evidentiary traces

Framework/ requirements

Requirements and composability analysis

No single recovered object; compares obligations or composed mechanisms

[16, 62, 44, 49, 50]

[76, 12]

lenses rather than primary-axis reclassifications; each cited system keeps the canonical axis assigned in Appendix A. The first comparison axis is safety: who can cause unauthorized recovery? Threshold systems bound exposure by shares or servers but depend on enrollment, participant independence, and refresh; smart-account and guardian systems avoid custodial key storage but add vote-buying, social-engineering, coercion, and challenge-window risks; hardware designs isolate secrets but depend on device, attestation, backup, or HSM assumptions. The second axis is liveness: threshold, contract, biometric, memory-based, and institutional systems can

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

13

Table 10 Family-by-adversary comparison. Actors who improve liveness can also become collusion, coercion, provider, insider, or metadata surfaces. Family

Loss / unavailability

Compromise theft

/

Coercion / malicious helpers

Threshold and passwordprotected reconstruction

Lost keys, shares, or passwords when enough shares/servers remain live Device, seed, mnemonic, signer, or factor loss when source material remains available Lost owners, passkeys, or signers when guardians, fees, and windows are available

Exposed shares, weak passwords, or stale fragments can reconstruct

Collusion or coercion crossing the threshold

Restored seeds, helper keys, or cold-wallet authority may preserve attacker access unless old paths are quarantined Compromised guardians, fallback signers, modules, or passkeys can rotate control

Biometrics, memories, devices, or support flows can be coerced

Vote buying, social engineering, recoverer abuse, and guardian collusion

On-chain proposals, guardian sets, and signer rotations can reveal distress and relationships

Institutional custody and disaster recovery

Signer churn, lost institutional devices, outages, and disasters

Collusion or coercion of officers can satisfy dualcontrol policies

Forensic and extractive recovery

Inaccessible devices, backups, memory, nonce failures, or investigation evidence

Compromised operator devices, HSM credentials, backups, or policy engines can move funds The same extraction path can be abused by attackers or overbroad investigators

Administrators, recovery officers, compliance roles, logs, and drills expose insider/metadata surfaces Forensic traces are often the recovered object; chain-ofcustody and privacy risks are intrinsic

Deterministic, biometric, and hardware recovery

Social, guardian, and smartaccount transfer

Coercion may compel device access, backup disclosure, or support escalation

Provider, insider, metadata, or forensic exposure Server contact, helper membership, and recovery attempts may leak; hosted shares add provider trust Vendors, attestation, HSMs, helper data, and identity checks become trust/privacy points

all fail when helpers, fees, inputs, terminals, or policies are unavailable. The third axis is evidence: the corpus validates feasibility and performance more often than recovery under stressful, high-value conditions.

8

Generalized Construction Model

Across the taxonomy, recovery designs can be described by a common construction model. It is not a protocol template; it is a checklist of design obligations that recur across wallets, custody systems, identity wallets, and smart accounts. 1. Control material. The system identifies what is at risk: a private key, seed, key share, recovery key, credential, signing role, account owner, or asset-control relation.

Examples

[52, 96, 106, 53, 98, 61, 55, 103, 99, 59] [19, 72, 86, 48, 33, 11]

81, 65, 51, 71, 77,

[108, 101, 17, 13, 7, 5, 70, 78, 21, 22, 94, 92, 88, 12, 58] [107, 76, 100, 93, 60]

[16, 62, 44, 49, 50]

14

SoK: Cryptographic Key Recovery for Financial Technologies

Table 11 Post-recovery hygiene and metadata/privacy obligations by mechanism family. Family

Post-recovery hygiene

Threshold and passwordprotected reconstruction

Rotate/rekey if compromise is possible; revoke stale fragments; refresh shares; audit helpers/servers

Deterministic, biometric, and hardware recovery

Social, guardian, and smartaccount transfer

Institutional custody and disaster recovery

Forensic and extractive recovery

Metadata/privacy exposure Helper linkage, server contact, timing, and repeated use can reveal distress or linkage

Common gap

Examples

Old-secret reconstruction often lacks rotation, revocation, or dispute handling

Revoke backups/helper data; reset authenticators; quarantine lost devices; migrate funds or rotate control if old material may still authorize value Revoke old owners/passkeys; refresh guardians; review delays/cancellation; audit final owner state

Device replacement, helper data, vendor contact, identity checks, and account linkage expose context

Many designs lack a decision rule for continued use of restored material or retirement of old authority

[52, 96, 106, 53, 98, 61, 55, 103, 99, 59] [19, 81, 72, 65, 86, 51, 48, 71, 33, 77, 11]

Guardian relationships, proposals, signer rotations, challenge windows, and module state reveal attempts

Guardian reset, cancellation, rollback, and dispute handling are uneven

Rotate signer/API/HSM credentials and policy roles; preserve logs; quarantine affected devices Move funds or rotate keys; revoke recovered credentials; maintain chain-of-custody; quarantine devices/secrets

Approver graphs, provider contacts, audits, drills, KYC, insurance, and legal holds reveal operations Device images, backups, artifacts, clusters, investigator actions, and asset movement are metadatarich

Governance, notification, and disputedinstruction workflows are less uniform Legitimate recovery and adversarial extraction share tooling, so authority boundaries matter

[108, 101, 17, 13, 7, 5, 70, 78, 21, 22, 94, 92, 88, 12, 58] [107, 76, 100, 93, 60] [16, 62, 44, 49, 50]

2. Enrollment. The system creates recovery material before failure, such as secret shares [96, 106, 66], masked password-protected shares [52, 53, 79], deterministic seeds [19, 23, 48], biometric helper data [51, 71, 77], hardware-wrapped secrets [81, 65, 33], guardians [42, 17, 78], backup authenticators [21, 92, 11], or pre-signed transactions [70, 58]. 3. Storage and governance. Recovery material is placed with the user, helpers, servers, institutions, smart contracts, secure hardware, cloud providers, or forensic evidence stores. This step determines whether the design is non-custodial, threshold-custodial, institutionally governed, or provider-assisted. 4. Failure trigger. Recovery begins after loss, unavailability, compromise, migration, death, device replacement, identity-wallet restoration, or investigation. The trigger may be user-initiated, contract-triggered, institutional, or forensic. 5. Authorization and checks. The system verifies that the recovery claimant is legitimate. Authorization can be cryptographic, social, institutional, on-chain, biometric, hardwarebacked, or evidentiary. Strong designs separate authorization from mere possession of backup data. 6. Recovery action. The system reconstructs a secret, regenerates a derived key, repairs a

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

share, reissues a credential, rotates ownership, transfers assets, or extracts an artifact. 7. Post-recovery hygiene. The system should decide whether to rotate keys, invalidate stale shares, revoke old authenticators, refresh guardians, record an audit event, or migrate funds. Many retained studies do not fully specify this stage, which is a central gap for financial deployments. This construction model explains why apparently similar mechanisms differ in financial risk. A threshold wallet that reconstructs the old seed [106, 103, 99] exposes the recovered secret after completion. A smart-account recovery protocol that rotates ownership [108, 101, 22] avoids exposing the old key but must secure the transfer process. A pre-signed evacuation mechanism [70, 58] may preserve asset value while abandoning the old account. Appendix B walks four representative systems through all seven stages to show where their post-recovery hygiene obligations diverge. These semantics should not be evaluated under a single “key recovery” label.

9

Production Recovery Designs

The 77-paper synthesis corpus remains the peer-reviewed evidence base for this SoK. Deployed wallet and custody systems are nevertheless useful practice checks: they are not counted as corpus rows, but they show whether the taxonomy and construction model cover recovery semantics used by retail users, institutional customers, and smart-account developers. Table 12 classifies representative systems using official documentation.

Representative production recovery workflows The seven-stage model separates production systems that all call themselves “recovery.” Ledger Recover restores seed-equivalent material through device-approved fragmentation, provider-held encrypted fragments, and identity verification. Safe{RecoveryHub} stores recoverer and delay state on-chain so a recoverer can propose owner or threshold changes unless current signers cancel. MPC custody restores a share or signer path across customer devices, provider infrastructure, passphrases, and policy. Passkey smart wallets add or replace a signer, after which stale passkeys and recovery phrases remain asset-control material.

10

Cross-Cutting Findings for Financial Technologies

10.1

Finding 1: Recovery semantics are heterogeneous

Recovery may mean reconstructing a key, regenerating a seed, restoring a share, recovering a recovery key, rotating credentials, restoring account control, transferring assets, or extracting forensic artifacts. The largest recovered-object groups are original private keys (34 studies), signing authority (20), account control (19), seeds or root secrets (15), asset ownership or transfer paths (13), and key shares (10). Counts are non-exclusive, but the design implication is clear: systems that restore account control should not be evaluated as if they reconstruct the original key.

10.2

Finding 2: Non-custodial recovery still moves trust somewhere

In this corpus, recovery mechanisms reduce or redistribute trust rather than eliminating it. Password-protected systems trust server independence and rate limiting; threshold systems trust participant diversity and share availability; hardware systems trust devices, attestation,

15

16

SoK: Cryptographic Key Recovery for Financial Technologies

Table 12 Production and standards-based practice checks outside the 77-paper corpus. Design

Evidence source Vendor product docs

Recovery axis and mechanism Secret-restoring; secure-element export, encrypted fragments, HSMbacked providers

Recovery action

MPC custody

Vendor developer and help docs

Hybrid control; share signer sioning, recovery

secret/MPC backup, reprovidisaster

Fireblocks and Coinbase Prime describe share/signer recovery through provider infrastructure, devices, passphrases, and policy [40, 39, 14]

Safe {RecoveryHub} and modules

Safe documentation

Control-restoring; delayed recoverer module

A Recoverer proposes owner or threshold changes; signers can cancel during the delay [82, 83]

ERC-4337 EIP-7702

Standards and protocol docs

Control-restoring substrate; custom validation and EOA delegation

ERC-4337 supports custom account validation; EIP7702 lets EOAs delegate to code using authorization tuples [26, 25, 27]

WebAuthn/ passkeys

W3C, FIDO, and product docs

Control-restoring; backup credential or passkey signer replacement

WebAuthn exposes backup state; Coinbase Smart Wallet uses a recovery phrase to create a new signer and passkey [97, 36, 15]

Argent guardian recovery

Wallet support docs

Control-restoring; guardian social recovery with delay

Guardians approve recovery; Argent Vault recovery has majority approval and a 48hour delay [2, 1]

Ledger Recover

/

Identity checks release fragments to reconstitute seed entropy inside a Ledger secure element [64]

Main SoK implication Restores seedequivalent material; moves trust to identity proofing, firmware consent, providers, and HSMs Threshold cryptography still needs governance for passphrases, devices, signers, and disaster drills Smart-account recovery migrates control and exposes on-chain recovery metadata Account abstraction expands recovery design space; EIP7702 leaves the EOA key as a bypass risk Passkey recovery depends on credentialprovider recovery, fallback policy, and signer cleanup Social recovery improves liveness but creates guardian availability, coercion, and relationshipmetadata questions

or HSM boundaries; social recovery trusts guardians; and smart-contract recovery trusts public rules and challenge windows. In the trust and adversary fields, collusion appears in 22 rows, malicious actors in 20, server terms in 20, provider terms in 8, and insider terms in 8. These are conservative text-coded signals rather than a threat prevalence measure, but

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 10 makes the trust shift explicit. A useful recovery design should state where trust has moved.

10.3

Finding 3: Liveness improvements often create abuse paths

Adding helpers, backup authenticators, pre-signed transactions, cloud backups, or institutional procedures can prevent permanent loss while creating coercion, collusion, phishing, insider, or unilateral-transfer paths. Unavailability appears in 16 failure-event rows, while compromise or theft appears in 16 rows; the adversary text mentions collusion in 22 rows, malicious actors in 20, and coercion in 8. This tension appears across social recovery [42, 17, 78], smart-account transfer [108, 101, 5, 22], institutional custody [76, 93], and hosted or provider-assisted identity recovery [100, 92, 34]. Because coercion is rarely formalized, the observed coercion count is best read as a lower bound.

10.4

Finding 4: Post-recovery lifecycle is a common blind spot

Many studies explain how to recover but not what happens next: whether to rotate keys, refresh shares, revoke helpers, clear backup authenticators, audit the event, quarantine a device, migrate funds, or handle disputes. The post-recovery-state coding is dominated by same-or-equivalent secret restoration (46 rows), followed by new control relations or credentials (17), forensic extraction (4), operational access restored or rekeyed (3), analysisonly rows (3), asset movement (2), and share or committee refresh (2). Table 11 shows that same-secret systems need rotation or migration decisions, guardian systems need owner and helper reset, institutional systems need audit and policy cleanup, and forensic systems need chain-of-custody and authority boundaries.

10.5

Finding 5: User evidence lags behind protocol evidence

Formal proofs, prototypes, and benchmarks are common, but user-study evidence is rare. The extraction records 56 prototypes, 50 benchmarks, 28 formal proofs, 17 simulations, 11 security-game analyses, 9 case studies, 7 gas-cost measurements, and 6 rows with no evaluation in the extracted evidence. Only three retained studies include user-study evidence [96, 86, 88], and one forensic tool reports operational deployment evidence [50]. Because recovery is invoked under stress, device loss, death, institutional disruption, or suspected compromise, we treat usability claims without user data as claims, not as user evidence.

10.6

Finding 6: Recovery metadata is underprotected

Several designs protect key material while saying less about metadata: which guardians exist, which servers were contacted, whether a recovery attempt occurred, which device was replaced, which account is being migrated, or which institution is under stress. Privacy or private-state terminology appears in 51 privacy-discussion rows, but 52 rows also include limited, no-formal-analysis, not-stated, or out-of-scope caveats; metadata, contact, timing, log, linkage, trace, or surveillance terms appear in 33 rows. These counts reflect conservative coding of what papers report, not proof that every omitted discussion leaks data. The issue cuts across threshold servers [52, 61, 103], guardians [42, 78], smart accounts [101, 5, 22], identity wallets [59, 92, 34], and forensic tools [44, 50].

17

18

SoK: Cryptographic Key Recovery for Financial Technologies

11

Financial, Regulatory, and Human-Factors Implications

Custody, compliance, and operational controls Recovery becomes a regulated financial-technology concern when a provider holds, administers, restores, or can influence access to crypto-assets. MiCA-style custody rules, FATF virtualasset guidance, and DORA operational-resilience obligations bring custody policy, client authentication, records, incident recovery, and provider duties into the design surface [32, 29, 37, 30]. This paper is not a legal analysis; the design point is that each mechanism should state whether recovery is self-custodial, provider-assisted, sub-custodial, institutional, or only a user-held backup. Obligations change depending on who verifies identity, sees recovery attempts, controls logs, and can block or reverse a disputed recovery [107, 76, 100, 93, 60].

Travel Rule metadata Recovery designs that transfer assets, restore hosted access, or involve a crypto-asset service provider can also trigger Travel Rule information flows. FATF treats the Travel Rule as the virtual-asset application of Recommendation 16, requiring originator and beneficiary information to accompany covered transfers, while the EU implements parallel requirements for transfers of funds and certain crypto-assets in Regulation 2023/1113 and EBA guidelines [37, 38, 31, 28]. For recovery, the design implication is that identity proofing, beneficiary changes, emergency transfers, provider logs, and self-hosted-address interactions may become compliance metadata. Systems should therefore separate recovery authorization from Travel Rule reporting, minimize unnecessary recovery metadata, and state who can disclose records during disputes or investigations.

Economics and incentives Recovery is also an incentive system. Guardians, shareholders, providers, support agents, and institutions may be unpaid, compensated, bonded, insured, or penalized; attackers can exploit those incentives through bribery, coercion, fee griefing, or collusion. Rational secret-sharing rows model some behavior [103, 99], composability work makes rational adversaries explicit [12], and pre-signed evacuation exposes fee drift and stale-UTXO issues [58]. Designs should specify who pays recovery fees, who absorbs disputed losses, and whether insurance or reimbursement changes diligence.

Inheritance and death or incapacity Death and incapacity are not ordinary key-loss events: authority may shift to an heir, executor, trustee, provider, court, or pre-authorized beneficiary. The corpus contains only a small inheritance thread–key-person loss [76], biometric/heir wallet governance [77], reregistration recovery [18], and pre-signed recovery for owner disappearance or death [58]. Estate recovery therefore needs separate treatment for enrollment while alive, beneficiary changes, disputed claims, privacy, and post-transfer auditability.

Post-quantum migration NIST finalized the first three post-quantum cryptography FIPS in 2024 and selected HQC for future standardization as a backup key-establishment algorithm in 2025 [74, 75]. Recovery material is migration-sensitive because wallet seeds, encrypted mnemonics, guardian secrets, recovery tokens, custody shares, and pre-signed emergency transactions may outlive active

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

19

signing keys. Same-secret restoration can reintroduce classical ECDSA or Schnorr keys after migration, so recovery should bind restored material to algorithm/version metadata and require re-derivation, fund migration, or key rotation when old material controls quantumvulnerable addresses. Control-restoring recovery must update every path, not only the active signer: stale EOAs, guardians, fallback keys, passkeys, authorizations, and pre-signed transactions can remain bypasses. Institutional and forensic recovery also need crypto-agile policies for shares, approvals, HSM rules, audit signatures, and evidentiary records. The corpus has early signals [13, 48, 94, 92, 11], but no complete migration playbook for deployed wallets or custody systems. Table 13 User-study evidence in the retained corpus. Existing studies test tangible shares, memory cues, and multi-factor wallet recovery, but not high-stress, adversarial, estate, or broadpopulation recovery. Study

Participants and task

Main finding

Offline secret sharing [96]

24-person form-factor survey; 18 completed field-study participants distributed five physical shares to 90 confidants and later retrieved enough shares for a 3-of-5 threshold 51 participants/510 pictures for parameters, 105-person survey, and 20 wallet-experienced users who repeated picture-location recovery after one month 27 United States participants compared custodial, conventional noncustodial, and MFKDFbased Ethereum wallet prototypes across creation, login, and recovery tasks

Physical share distribution and retrieval was practical, but recovery coordination could take days or weeks; paper versus plastic key tags did not dominate success

Reminisce [86]

Multi-factor key-derivation wallet [88]

Main limitation for recovery claims Student sample, one threshold configuration, simulated cryptographic reconstruction, and limited compliance checking

All 20 recovered successfully; 18 succeeded on the first attempt, with 1.10–8.29 minute recovery times and 2.56 minutes average

Repository security and authentication out of scope; fixed parameters; 20–40year-old experienced wallet users; photo/location privacy leakage

The MFKDF wallet reported 37% higher System Usability Scale (SUS) and 71% faster task completion than the conventional noncustodial wallet, with less seed-phrase handling

Small US-only and not gender-balanced sample; prototype fidelity limits; accessibility and marginalized populations not evaluated

Together, these studies show that tangible shares, picture-location memory, and familiar multi-factor workflows can work in controlled settings, but not how users behave under theft, grief, coercion, provider lockout, legal dispute, or market stress. Open questions include ceremony comprehension, stress errors, guardian coordination, inheritance, phishing, support escalation, accessibility, and recovery-metadata privacy.

12

Open Problems and Research Agenda

Standard recovery semantics. Wallets, custody systems, and identity wallets need explicit terminology for original-key reconstruction, seed regeneration, share repair, credential re-issuance, control transfer, and asset evacuation. Without this, designs with different promises are difficult to compare. Custody, regulation, and incentives. Recovery mechanisms should declare whether

20

SoK: Cryptographic Key Recovery for Financial Technologies

they create self-custody, provider-assisted custody, sub-custody, or institutional obligations, and should model guardian availability, provider fees, Travel Rule metadata, reimbursement, insurance, fee drift, and collusion [103, 99, 12, 58, 32, 29, 37, 31, 30]. Inheritance and estate recovery. Death and incapacity require different authorization semantics from ordinary loss, including beneficiary enrollment, revocation while alive, dispute handling, privacy, and auditability for heirs, executors, trustees, and providers [76, 77, 18, 58]. Composable recovery after loss or compromise. Smart-account recovery increasingly combines guardians, backup authenticators, fallback signatures, timeouts, ownership proofs, and pre-signed transactions [101, 13, 21, 94, 58]. Research is needed on how these paths compose, and on recovery that rotates, revokes, audits, and disputes after compromise rather than only restoring after loss [52, 71, 9]. Privacy-preserving recovery coordination. Recovery should hide helper relationships, server choices, attempts, and account linkage where possible, especially for threshold servers, guardians, identity wallets, and smart-contract metadata. Human-centered recovery under stress. Recovery ceremonies should be evaluated with users and operators under time pressure, grief, device loss, or fear of theft. Existing user evidence is useful but too sparse and controlled for the importance of the problem [96, 86, 88]. Operational threshold custody. Threshold protocols need lifecycle support for lost shares, changing personnel, institutional disaster recovery, participant churn, and auditability [69, 59, 93]. Long-lived recovery material. Wallet seeds, backup credentials, custody shares, and pre-signed recovery paths may survive for years. Post-quantum recovery is emerging [48, 92, 74], while forensic recovery raises privacy, chain-of-custody, and abuse questions [62, 44, 49, 50].

13

Ethics, Limitations, and Reproducibility

This SoK studies mechanisms that can restore or transfer financial control. The ethical risk is therefore not limited to confidentiality of keys. Recovery systems can enable theft, coercion, unauthorized transfer, insider abuse, account lockout, or exclusion from identity and financial services. For this reason, the taxonomy distinguishes what is recovered and who authorizes recovery; ambiguity in these two points can hide serious harms. The review has methodological limitations. The search considered peer-reviewed journal and conference articles written in English and classified as computer science. The final synthesis retained 77 of the 118 discovery papers after full-text extraction and financialtechnology-focused filtering. LLM assistance was used as a decision-support tool during screening, and all LLM-assisted decisions were manually verified. The resulting corpus is suitable for a focused SoK, but it does not exhaust gray literature, wallet documentation, standards drafts, or production incidents. The extraction is also limited by the evidence reported in each paper. If a study did not state a deployment, user evaluation, privacy analysis, or post-recovery rotation procedure, we classify that evidence as absent rather than infer it. This conservative choice may understate properties implemented outside the paper, but it avoids giving recovery mechanisms credit for unstated guarantees. For reproducibility, the paper reports the source databases, exact logical query, search/export date, database counts, de-duplication and screening counts, grouped exclusion reasons,

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

snowballing rounds, QA threshold, retained-study count, and extracted comparison dimensions. The reproducibility package contains search-count summaries, screening-round summaries, the LLM screening protocol and prompts, exclusion-reason summaries, QA counts, extracted rows, the matrix codebook, count audits, venue/year confidence analyses, and the machine-readable 77-system master matrix. Copyrighted PDFs, raw library exports, private credentials, repository history, and private working materials are excluded from the package. Generative-AI tools were used to support title and abstract screening and to assist with language and structural editing of the manuscript. All screening decisions and all AI-assisted manuscript content were reviewed and verified by the authors. The authors retained full responsibility for the extracted evidence, numerical counts, citations, interpretations, and final manuscript. Generative-AI tools were not treated as authoritative sources.

14

Related Work

The closest external SoKs and surveys are compared earlier in Table 1. Broad cryptocurrency and DeFi SoKs organize protocols, applications, attacks, and economic risk [6, 95, 105]. Wallet-focused surveys and SoKs organize wallet protocols, authentication factors, attack surfaces, vulnerabilities, incidents, and defenses [56, 46, 45, 24]. These works establish the broader security and financial-technology context, but they do not make recovery semantics– what object or control relation is restored, who authorizes it, and what state remains afterward–the primary unit of comparison. The retained corpus spans bodies of work that are usually discussed separately: threshold reconstruction and share repair; password-, factor-, hardware-, biometric-, and deterministicwallet recovery; social and smart-account control transfer; decentralized-identity wallet backup; institutional disaster recovery; and forensic extraction. The shared gap is not the absence of mechanisms, but the absence of a common account of what is restored, who authorizes restoration, and what state remains afterward. This paper differs from a conventional survey by using recovery semantics as the organizing viewpoint and making those semantics auditable in a system-level matrix. Rather than treating every mechanism as private-key recovery, it distinguishes secret reconstruction from account-control restoration, signing-authority migration, credential re-issuance, asset evacuation, and forensic extraction. That distinction drives the taxonomy, construction model, and agenda.

15

Conclusion

Cryptographic recovery in financial technologies is broader than private-key backup. The retained corpus shows mechanisms for reconstructing secrets, regenerating wallet seeds, repairing shares, restoring credentials, delegating recovery, rotating account ownership, evacuating assets, and extracting wallet artifacts. A wallet that reconstructs a seed, a custody protocol that repairs a signing share, a smart account that rotates ownership, and a forensic tool that extracts artifacts are not making the same promise. Recovery-aware financial systems need explicit recovery semantics before they can compare safety, liveness, privacy, usability, and trust, or remain usable after loss without creating unacceptable paths for theft, coercion, surveillance, or exclusion.

21

22

SoK: Cryptographic Key Recovery for Financial Technologies

References 1 Argent. How to add a guardian to your argent ethereum wallet, 2025. Accessed: 2026-05-26. URL: https://support.argent.xyz/hc/en-us/articles/ 360008013258-How-to-add-a-guardian-to-your-Argent-Ethereum-wallet. 2 Argent. How to recover my wallet with guardians onchain, 2025. Accessed: 2026-05-26. URL: https://support.argent.xyz/hc/en-us/articles/ 360007338877-How-to-recover-my-wallet-with-guardians-onchain-complete-guide. 3 Soumya Basu, Alin Tomescu, Ittai Abraham, Dahlia Malkhi, Michael K. Reiter, and Emin Gün Sirer. Efficient verifiable secret sharing with share recovery in bft protocols. 2019. doi: 10.1145/3319535.3354207. 4 Michele Battagliola, Alessio Galli, Riccardo Longo, and Alessio Meneghetti. A provablyunforgeable threshold schnorr signature with an offline recovery party. CEUR Workshop Proceedings, 3166:60–76, 2022. URL: https://www.scopus.com/inward/record.uri?eid= 2-s2.0-85134323353&partnerID=40&md5=66337d80bb6e1705175aa7285cda93d4. 5 Sam Blackshear, Konstantinos Chalkias, Panagiotis Chatzigiannis, Riyaz Faizullabhoy, Irakliy Khaburzaniya, Eleftherios Kokoris Kogias, Joshua Lind, David Wong, and Tim Zakian. Reactive key-loss protection in blockchains. 2021. doi:10.1007/978-3-662-63958-0_34. 6 Joseph Bonneau, Andrew Miller, Jeremy Clark, Arvind Narayanan, Joshua A. Kroll, and Edward W. Felten. SoK: Research perspectives and challenges for bitcoin and cryptocurrencies. In 2015 IEEE Symposium on Security and Privacy, pages 104–121. IEEE, 2015. URL: https://eprint.iacr.org/2015/261, doi:10.1109/SP.2015.14. 7 Micha Boro and Anna Kobusiska. Alternative authentication with smart contracts for online games. pages 415–418, 2021. doi:10.1109/LCN52139.2021.9524886. 8 Florian Breuer, Vipul Goyal, and Giulio Malavolta. Cryptocurrencies with security policies and two-factor authentication. pages 140–158, 2021. doi:10.1109/EuroSP51992.2021.00020. 9 Syeda Tayyaba Bukhari, Muhammad Umar Janjua, and Junaid Qadir. Secure storage of crypto wallet seed phrase using ecc and splitting technique. IEEE Open Journal of the Computer Society, 2024. doi:10.1109/OJCS.2024.3398794. 10 Haewon Byeon, Aadam Quraishi, Praveen Thuniki, Ismail Mohamed Keshta, Mukesh Soni, and Mohammad Shabaz. Optimized security mechanism for publicly secret key sharing over cloud using blockchain. CEUR Workshop Proceedings, 3774:137– 150, 2024. URL: https://www.scopus.com/inward/record.uri?eid=2-s2.0-85206453527& partnerID=40&md5=80d82f75bfa4de5397d86131d6d70b38. 11 Bertrand Francis Cambou and Mahafujul Alam. Challengeresponse pair mechanisms and multi-factor authentication schemes to protect private keys. Applied Sciences (Switzerland), 15, 2025. doi:10.3390/app15063089. 12 Panagiotis Chatzigiannis, Ke Coby Wang, Sunpreet Singh Arora, and Mohsen Minaei. A composability analysis framework for web3 wallet recovery mechanisms. Proceedings - IEEE Symposium on Security and Privacy, pages 1531–1546, 2025. doi:10.1109/SP61157.2025. 00158. 13 David Chaum, Mario Larangeira, Mario Yaksetig, and William Carter. W-ots+ up my sleeve! a hidden secure fallback for cryptocurrency wallets. 2021. doi:10.1007/978-3-030-78372-3_8. 14 Coinbase. How to secure your onchain wallet, 2026. Accessed: 2026-05-26. URL: https: //help.coinbase.com/en/prime/onchain-wallet/how-to-secure-your-onchain-wallet. 15 Coinbase. Recover your smart wallet, 2026. Accessed: 2026-05-26. URL: https://help. coinbase.com/en/wallet/getting-started/smart-wallet-recovery. 16 Nicolas T. Courtois and Rebekah Mercer. Stealth address and key management techniques in blockchain systems. 2017. doi:10.5220/0006270005590566. 17 Weiqi Dai, Yan Lv, Kim-Kwang Raymond Choo, Zhongze Liu, Deqing Zou, and Hai Jin. Crsa: A cryptocurrency recovery scheme based on hidden assistance relationships. IEEE Transactions on Information Forensics and Security, 16:4291–4305, 2021. doi:10.1109/TIFS.2021.3104142.

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

23

18 Weiqi Dai, Yang Zhou, Xiaohai Dai, Kim-Kwang Raymond Choo, Xia Xie, Deqing Zou, and Hai Jin. Cr-dap: A comprehensive and regulatory decentralized anonymous payment system. IEEE Transactions on Information Forensics and Security, 20:3274–3286, 2025. doi:10.1109/TIFS.2025.3550821. 19 Poulami Das, Sebastian Faust, and Julian Loss. A formal treatment of deterministic wallets. 2019. doi:10.1145/3319535.3354236. 20 Cristfol Daudn-Esmel, Jordi Castell-Roca, Alexandre Viejo, and Ignacio Miguel-Rodrguez. Multi-platform wallet for privacy protection and key recovery in decentralized applications. Blockchain: Research and Applications, 6:100243, 2025. URL: https://www.sciencedirect. com/science/article/pii/S2096720924000563, doi:10.1016/j.bcra.2024.100243. 21 Varun Deshpande, Atharva Vijay Khade, Harish J, Gandhi Kishor Addanki, and Srivatsan Deenadayalan. A passkey based recovery mechanism for blockchain hardware wallets. pages 276–281, 2024. doi:10.1109/UCC63386.2024.00046. 22 Varun M. Deshpande, J. Harish, and Atharva Vijay Khade. A practical recovery mechanism for blockchain hardware wallets. IEEE Access, 12:169928–169944, 2024. doi:10.1109/ACCESS. 2024.3497302. 23 Adriano Di Luzio, Danilo Francati, and Giuseppe Ateniese. Arcula: A secure hierarchical deterministic wallet for multi-asset blockchains. 2020. doi:10.1007/978-3-030-65411-5_16. 24 Yimika Erinle, Yathin Kethepalli, Yebo Feng, and Jiahua Xu. SoK: Design, vulnerabilities, and security measures of cryptocurrency wallets. Computer Networks, 273:111691, 2025. doi:10.1016/j.comnet.2025.111691. 25 Ethereum Improvement Proposals. EIP-7702: Set code for EOAs, 2026. Accessed: 2026-05-26. URL: https://eips.ethereum.org/EIPS/eip-7702. 26 Ethereum Improvement Proposals. ERC-4337: Account abstraction using alt mempool, 2026. Accessed: 2026-05-26. URL: https://eips.ethereum.org/EIPS/eip-4337. 27 ethereum.org. Pectra 7702 guidelines, 2026. Accessed: 2026-05-26. URL: https://ethereum. org/roadmap/pectra/7702/. 28 European Banking Authority. Guidelines on information requirements in relation to transfers of funds and certain crypto-assets transfers under regulation (EU) 2023/1113, 2024. Accessed: 2026-05-27. URL: https: //www.eba.europa.eu/activities/single-rulebook/regulatory-activities/ anti-money-laundering-and-countering-financing-terrorism/ guidelines-information-requirements-relation-transfers-funds-and-certain-crypto-assets-transfers. 29 European Banking Authority. MiCA article 75: Providing custody and administration of crypto-assets on behalf of clients, 2026. Accessed: 2026-05-26. URL: https://www.eba.europa. eu/regulation-and-policy/single-rulebook/interactive-single-rulebook/17894. 30 European Parliament and Council of the European Union. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, 2022. Accessed: 2026-05-26. URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32022R2554. 31 European Parliament and Council of the European Union. Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets, 2023. Accessed: 2026-0527. URL: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32023R1113. 32 European Parliament and Council of the European Union. Regulation (EU) 2023/1114 on markets in crypto-assets, 2023. Accessed: 2026-05-26. URL: https://eur-lex.europa.eu/ legal-content/EN/TXT/?uri=CELEX:32023R1114. 33 Sebastian Faller, Tobias Handirk, Julia Hesse, Máté Horváth, and Anja Lehmann. Passwordprotected key retrieval with(out) hsm protection. pages 2445–2459, 2024. doi:10.1145/ 3658644.3690358. 34 Mohammad Farhad, Gourab Saha, Masum Alam Nahid, Fairuz Rahaman Chowdhury, Partha Protim Paul, Mohammed Raihan Ullah, and Md Sadek Ferdous. Secure backup and recovery of ssi wallets using solid pod technology. pages 1101–1111, 2024. doi: 10.1109/COMPSAC61105.2024.00149.

24

SoK: Cryptographic Key Recovery for Financial Technologies

35 Shahin Fatima and Shish Ahmad. Secure and effective key management using secret sharing schemes in cloud computing. International Journal of e-Collaboration, 2020. doi:10.4018/ IJeC.2020010101. 36 FIDO Alliance. Synced passkey deployment: Emerging practices for consumer use cases, 2024. Accessed: 2026-05-26. URL: https://fidoalliance.org/wp-content/uploads/ 2024/05/Synced-Passkey-Deployment_-Emerging-Practices-for-Consumer-Use-Cases_ 2024-May-31.pdf. 37 Financial Action Task Force. Updated guidance for a risk-based approach to virtual assets and virtual asset service providers, 2021. Accessed: 2026-05-26. URL: https://www.fatf-gafi. org/en/publications/Fatfrecommendations/Guidance-rba-virtual-assets-2021.html. 38 Financial Action Task Force. FATF updates standards on recommendation 16 on payment transparency, 2025. Accessed: 2026-05-27. URL: https://www.fatf-gafi.org/en/publications/ Fatfrecommendations/update-Recommendation-16-payment-transparency-june-2025. html. 39 Fireblocks. Backup and recovery, 2026. Accessed: 2026-05-26. URL: https://ncw-developers. fireblocks.com/docs/backup-recovery-1. 40 Fireblocks. Backup and recovery overview, 2026. Accessed: 2026-05-26. URL: https: //developers.fireblocks.com/docs/perform-drs-process. 41 Qianwen Gao and Yichi Tu. A blockchain wallet scheme with multi-factor authentication based on distributed system. pages 55–61, 2024. doi:10.1109/ICBCTIS64495.2024.00017. 42 Shuangyu He, Qianhong Wu, Xizhao Luo, Zhi Liang, Dawei Li, Hanwen Feng, Haibin Zheng, and Yanan Li. A social-network-based cryptocurrency wallet-management scheme. IEEE Access, 6:7654–7663, 2018. doi:10.1109/ACCESS.2018.2799385. 43 Xiaojian He, Jinfu Lin, Kangzi Li, and Ximeng Chen. A novel cryptocurrency wallet management scheme based on decentralized multi-constrained derangement. IEEE Access, 7:185250– 185263, 2019. doi:10.1109/ACCESS.2019.2961183. 44 Arran Holmes and William J. Buchanan. A framework for live host-based bitcoin wallet forensics and triage. Forensic Science International: Digital Investigation, 44, 2023. doi: 10.1016/j.fsidi.2022.301486. 45 Ivan Homoliak and Martin Perešíni. SoK: Cryptocurrency wallets: A security review and classification based on authentication factors. In 2024 IEEE International Conference on Blockchain and Cryptocurrency (ICBC), pages 1–8. IEEE, 2024. URL: https://ieeexplore. ieee.org/document/10634439, doi:10.1109/ICBC59979.2024.10634439. 46 Sabine Houy, Philipp Schmid, and Alexandre Bartel. Security aspects of cryptocurrency wallets: A systematic literature review. ACM Computing Surveys, 56(1):1–31, 2023. doi: 10.1145/3596906. 47 Felix Hrandner and Christof Rabensteiner. Horcruxes for everyone - a framework for key-loss recovery by splitting trust. pages 50–57, 2019. doi:10.1109/TrustCom/BigDataSE.2019. 00017. 48 Mingxing Hu, Zhen Liu, and Yunhong Zhou. Efficient post-quantum secure deterministic wallet scheme. Cybersecurity, 7, 2024. doi:10.1186/s42400-024-00216-w. 49 Ah hyun Park, Hyejin Ryu, Woobeen Park, and Doowon Jeong. Forensic investigation framework for cryptocurrency wallet in the end device. Computers & Security, 2023. doi: 10.1016/j.cose.2023.103392. 50 Lilita Infante, Roger A. Hallman, John Hays, Evelyn Cronnon, and Uri Stav. Recovery cat: A digital forensics tool for cryptocurrency investigations. pages 1–5, 2024. doi:10.1109/ ISDFS60797.2024.10527279. 51 Olson Italis, Samuel Pierre, and Alejandro Quintero. Privacy-preserving model for biometricbased authentication and key derivation function. Journal of Information Security and Applications, 78:103624, 2023. URL: https://www.sciencedirect.com/science/article/ pii/S2214212623002089, doi:10.1016/j.jisa.2023.103624.

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

52 Stanislaw Jarecki, Aggelos Kiayias, Hugo Krawczyk, and Jiayu Xu. Highly-efficient and composable password-protected secret sharing (or: How to protect your bitcoin wallet online). 2016. doi:10.1109/EuroSP.2016.30. 53 Stanisław Jarecki, Aggelos Kiayias, Hugo Krawczyk, and Jiayu Xu. Toppss: Costminimal password-protected secret sharing based on threshold oprf. 2017. doi:10.1007/ 978-3-319-61204-1_3. 54 Farah Maath Jasim, Ali Makki Makki Sagheer, and Abdullah Mohammed Awad. Enhancement of digital signature algorithm in bitcoin wallet. Bulletin of Electrical Engineering and Informatics, 10:449–457, 2021. doi:10.11591/eei.v10i1.2339. 55 Woochang Jeong, Haesung Park, and Chanik Park. Keyscrub: A reliable key backup and recovery method for blockchain. IEEE Access, 11:91747–91755, 2023. doi:10.1109/ACCESS. 2023.3308208. 56 Kostis Karantias. SoK: A taxonomy of cryptocurrency wallets. Cryptology ePrint Archive, Paper 2020/868, 2020. URL: https://eprint.iacr.org/2020/868. 57 Atharva Vijay Khade, Harsh Rajesh Patel, and Chirag Modi. Mnemonic phrase management and sim based two-factor authentication (2fa) for mobile wallets in blockchain. 2023. doi: 10.1109/ICBDS58040.2023.10346266. 58 Hyeonhak Kim and Sanjin Park. Cryptocurrency recovery framework using pre-signed transaction. International Journal of Information Security, 24, 2025. doi:10.1007/ s10207-025-00994-5. 59 Jihwan Kim, Pyung Kim, Younho Lee, and Daeseon Choi. Key backup and recovery for resilient did environment. Mathematics, 12, 2024. doi:10.3390/math12060830. 60 Jihwan Kim, Younho Lee, and Daeseon Choi. Key-audit chain (kac): A resilient and reliable key management framework for did-based decentralized environments. IEEE Access, 13:141871– 141885, 2025. doi:10.1109/ACCESS.2025.3597593. 61 Myungsun Kim, Sangrae Cho, Seongbong Choi, Young-Seob Cho, Soohyung Kim, and Hyung Tae Lee. A key recovery protocol for multiparty threshold ecdsa schemes. IEEE Access, 10:133206–133218, 2022. doi:10.1109/ACCESS.2022.3230683. 62 Ju-seong Ko and Jin Kwak. Private key recovery on bitcoin with duplicated signatures. KSII Transactions on Internet and Information Systems, 14:1280–1300, 2020. doi:10.3837/tiis. 2020.03.020. 63 Katharina Krombholz, Aljosha Judmayer, Matthias Gusenbauer, and Edgar Weippl. The other side of the coin: User experiences with bitcoin security and privacy. 2017. doi: 10.1007/978-3-662-54970-4_33. 64 Ledger. What is ledger recover?, 2026. Accessed: 2026-05-26. URL: https://www.ledger. com/academy/what-is-ledger-recover. 65 Niko Lehto, Kimmo Halunen, Outi-Marja Latvala, Anni Karinsalo, and Jarno Salonen. Cryptovault - a secure hardware wallet for decentralized key management. pages 1–4, 2021. doi:10.1109/COINS51742.2021.9524133. 66 Guojia Li and Lin You. A consortium blockchain wallet scheme based on dual-threshold key sharing. Symmetry, 13:1444, 2021. doi:10.3390/sym13081444. 67 Guojia Li, Lin You, Gengran Hu, and Liqin Hu. Recoverable private key scheme for consortium blockchain based on verifiable secret sharing. KSII Transactions on Internet and Information Systems, 15:2865–2878, 2021. doi:10.3837/tiis.2021.08.009. 68 Zhen Liu, Guomin Yang, Duncan S. Wong, Khoa Nguyen, Huaxiong Wang, Xiaorong Ke, and Yining Liu. Secure deterministic wallet and stealth address: Key-insulated and privacypreserving signature scheme with publicly derived public key. IEEE Transactions on Dependable and Secure Computing, 2022. doi:10.1109/TDSC.2021.3078463. 69 Sai Krishna Deepak Maram, Fan Zhang, Lun Wang, Andrew Low, Yupeng Zhang, Ari Juels, and Dawn Song. Churp: Dynamic-committee proactive secret sharing. pages 2369–2386, 2019. doi:10.1145/3319535.3363203.

25

26

SoK: Cryptographic Key Recovery for Financial Technologies

70 Natsume Matsuzaki, Masayuki Fukumitsu, and Yoshihiro Kita. Emergency button: Evacuation of crypto asset when key loss. 2023. doi:10.1109/CANDARW60564.2023.00048. 71 Ken Naganuma, Takayuki Suzuki, and Takatoshi Ohara. Leakable mnemonic phrase: A new orientation of wallets backup based on biometric-key. pages 325–328, 2024. doi:10.23919/ ISITA60732.2024.10858205. 72 Ken Naganuma, Takayuki Suzuki, Masayuki Yoshino, Kenta Takahashi, Yosuke Kaga, and Noboru Kunihiro. New secret key management technology for blockchains from biometrics fuzzy signature. 2020. doi:10.1109/asiajcis50894.2020.00020. 73 Vivek Nair and Dawn Song. Decentralizing custodial wallets with mfkdf. pages 1–9, 2023. doi:10.1109/ICBC56567.2023.10174998. 74 National Institute of Standards and Technology. Announcing approval of three federal information processing standards for post-quantum cryptography, 2024. Accessed: 2026-05-26. URL: https://csrc.nist.gov/News/2024/postquantum-cryptography-fips-approved. NIST selects HQC 75 National Institute of Standards and Technology. as fifth algorithm for post-quantum encryption, 2025. Accessed: 2026-05-27. URL: https://www.nist.gov/news-events/news/2025/03/ nist-selects-hqc-fifth-algorithm-post-quantum-encryption. 76 Chan Nam Ngo, Daniele Friolo, Fabio Massacci, Daniele Venturi, and Ettore Battaiola. Vision: What if they all die? crypto requirements for key people. pages 178–183, 2020. doi:10.1109/EuroSPW51379.2020.00032. 77 Saki Otsuki, Hiroto Tamiya, Kengo Mori, Toshiyuki Isshiki, ShinIchiro Matsuo, and Satoshi Obana. Biometrics enhances blockchain wallet governance. pages 1–9, 2025. doi:10.1109/ ICBC64466.2025.11114682. 78 Allan B. Pedin, Nazli Siasi, and Mohammad Sameni. Smart contract-based social recovery wallet management scheme for digital assets. pages 177–181, 2023. doi:10.1145/3564746. 3587016. 79 Gyeongjin Ra, Chang-hyun Roh, and Imyeong Yeoung Lee. A key recovery system based on password-protected secret sharing in a permissioned blockchain. Computers, Materials and Continua, 65:153–170, 2020. doi:10.32604/cmc.2020.011293. 80 Avishka Rathnavibhushana, Tharinda Thamaranga, Sandaru Kaveesha, and Chandana Gamage. A social wallet scheme with robust private key recovery. pages 1–6, 2023. doi:10.1109/ICIIS58898.2023.10253598. 81 Hossein Rezaeighaleh and Cliff C. Zou. New secure approach to backup cryptocurrency wallets. pages 1–6, 2019. doi:10.1109/GLOBECOM38437.2019.9014007. 82 Safe. Account recovery with safe recoveryhub, 2026. Accessed: 2026-05-26. URL: https: //help.safe.global/articles/9622260218-account-recovery-with-saferecoveryhub. 83 Safe. Safe modules, 2026. Accessed: 2026-05-26. URL: https://docs.safe.global/advanced/ smart-account-modules. 84 Asia A. Salman, Nidaa Flaih Hassan, and Raghad Abdulaali Azeez. A secure private key recovery based on dna bio-cryptography for blockchain. Iraqi Journal of Science, 64:958–972, 2023. doi:10.24996/ijs.2023.64.2.38. 85 Aaliya Sarfaraz, Ripon K. Chakrabortty, Saad Aslam, and Ahmad Sahban Rafsanjani. Optimized key recovery for blockchain wallets in sustainable supply chains. pages 343–347, 2024. doi:10.1109/IEEM62345.2024.10857165. 86 Jungwon Seo, Deokyoon Ko, Suntae Kim, Vijayan Sugumaran, and Sooyong Park. Reminisce: Blockchain private key generation and recovery using distinctive pictures-based personal memory. Mathematics, 10, 2022. doi:10.3390/math10122047. 87 Cheman Shaik. Securing cryptocurrency wallet seed phrase digitally with blind key encryption. International Journal on Cryptography and Information Security, 2020. doi:10.5121/ijcis. 2020.10401.

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

88 Tanusree Sharma, Vivek C. Nair, Henry Wang, Yang Wang, and Dawn Xiaodong Song. I can’t believe it’s not custodial! usable trustless decentralized key management. Conference on Human Factors in Computing Systems - Proceedings, 2024. doi:10.1145/3613904.3642464. 89 Har Preet Singh, Kyriakos Stefanidis, and Fabian Kirstein. A private key recovery scheme using partial knowledge. pages 1–5, 2021. doi:10.1109/NTMS49979.2021.9432642. 90 Reza Soltani, Uyen Trang Nguyen, and Aijun An. Practical key recovery model for selfsovereign identity based digital wallets. pages 320–325, 2019. doi:10.1109/DASC/PiCom/ CBDCom/CyberSciTech.2019.00066. 91 Reza Soltani, Uyen Trang Nguyen, and Aijun An. Decentralized and privacy-preserving key management model. pages 1–7, 2020. doi:10.1109/ISNCC49221.2020.9297294. 92 Douglas Stebila and Spencer Wilson. Quantum-safe account recovery for webauthn. 2024. doi:10.1145/3634737.3661138. 93 Yuto Takei and Kazuyuki Shudo. Pragmatic analysis of key management for cryptocurrency custodians. 2024. doi:10.1109/ICBC59979.2024.10634356. 94 Chen Wang, Zi Yuan Liu, and Masahiro Mambo. On the proof of ownership of digital wallets. Cryptography, 8, 2024. doi:10.3390/cryptography8040057. 95 Sam M. Werner, Daniel Perez, Lewis Gudgeon, Ariah Klages-Mundt, Dominik Harz, and William J. Knottenbelt. SoK: Decentralized finance (DeFi). In Proceedings of the 4th ACM Conference on Advances in Financial Technologies, pages 30–46. ACM, 2022. doi: 10.1145/3558535.3559780. 96 Oliver Wiese, Christoph Weinhold, Jan-Ole Malchow, and Volker Roth. I need this back, later! an exploration of practical secret sharing. pages 478–489, 2018. doi:10.1145/3274694. 3274729. 97 World Wide Web Consortium. Web authentication: An API for accessing public key credentials level 3, 2026. Accessed: 2026-05-26. URL: https://www.w3.org/TR/webauthn-3/. 98 Feng Xiong, Ruiyang Xiao, Wei Ren, Rongyue Zheng, and Jianlin Jiang. A key protection scheme based on secret sharing for blockchain-based construction supply chain system. IEEE Access, 7:126773–126786, 2019. doi:10.1109/ACCESS.2019.2937917. 99 Zhimei Yang, Changgen Peng, Chongyi Zhong, and Yangyang Long. Consortium blockchain private key protection scheme based on rational secret sharing and blockchain. Computer Networks, 242:110260, 2024. URL: https://www.sciencedirect.com/science/article/pii/ S1389128624000926, doi:10.1016/j.comnet.2024.110260. 100 Mert Yldz and erif Bahtiyar. A novel key management framework for secure and scalable decentralized identity systems. pages 1–8, 2024. doi:10.1109/SIN63213.2024.10871880. 101 Fan Zhang, Philip Daian, Iddo Bentov, Ian Miers, and Ari Juels. Paralysis proofs: Secure dynamic access structures for cryptocurrency custody and more. page 115, 2019. doi: 10.1145/3318041.3355459. 102 Yifang Zhang, Mingyue Wang, Yu Guo, and Fangda Guo. Towards dynamic and reliable private key management for hierarchical access structure in decentralized storage. pages 3371–3380, 2023. doi:10.1145/3583780.3615090. 103 Xingfan Zhao, Changgen Peng, Weijie Tan, and Kun Niu. Blockchain-based key management scheme using rational secret sharing. Computers, Materials and Continua, 79:307–328, 2024. URL: https://www.sciencedirect.com/science/article/pii/S1546221824004417, doi:10.32604/cmc.2024.047975. 104 Wenbo Zheng, Kunfeng Wang, and Feiyue Wang. Gan-based key secret-sharing scheme in blockchain. IEEE Transactions on Cybernetics, 51:393–404, 2021. doi:10.1109/TCYB.2019. 2963138. 105 Liyi Zhou, Xihan Xiong, Jens Ernstberger, Stefanos Chaliasos, Zhipeng Wang, Ye Wang, Kaihua Qin, Roger Wattenhofer, Dawn Song, and Arthur Gervais. SoK: Decentralized finance (DeFi) attacks. In 2023 IEEE Symposium on Security and Privacy, pages 2444–2461. IEEE, 2023. doi:10.1109/SP46215.2023.10179435.

27

28

SoK: Cryptographic Key Recovery for Financial Technologies

106 Xiuwen Zhou, Qianhong Wu, Bo Qin, Xinyi Huang, and Jianwei Liu. Distributed bitcoin account management. 2016. doi:10.1109/TrustCom.2016.0052. 107 Fangdong Zhu, Wen Chen, Yunpeng Wang, Ping Lin, Tao Li, Xiaochun Cao, and Long Yuan. Trust your wallet: A new online wallet architecture for bitcoin. pages 307–311, 2017. doi:10.1109/PIC.2017.8359562. 108 Yanlin Zhu, Lirong Xia, and Oshani Seneviratne. A proposal for account recovery in decentralized applications. pages 148–155, 2019. doi:10.1109/Blockchain.2019.00028.

A

Full 77-System Master Matrix

The following tables reproduce the complete master matrix used for the SoK synthesis. The matrix is split into four parts for page layout; the parts are keyed by the Study citation and kept in the same row order.

Classification and Mechanism Fields Table 14 Master matrix, part A: classification and mechanism fields.

Study [52]

Financial context self custody wallet

[96]

self custody wallet; non financial original private key secret restoring transferable pattern self custody wallet; DeFi or account control; asset control restoring smart contract application ownership or transfer signing authority; account control restoring self custody wallet; smart contract account; institutional control; asset ownership or custody; DeFi or smart contract transfer application; secure hardware for financial infrastructure institutional custody original private key secret restoring

[108] [101]

[106] [16]

Recovered object original private key

Secret/control axis secret restoring

[53]

self custody wallet; payment or adversarial key extraction forensic or adversarial permissioned blockchain extraction non financial transferable pattern seed or root secret secret restoring

[107]

self custody wallet

[42]

self custody wallet

[19]

self custody wallet; hardware wallet payment or permissioned blockchain self custody wallet

[98] [43] [69]

Mechanism family Enrollment/storage password protected secret sharing password or factor material; server held protected material threshold secret reconstruction distributed shares or committees smart contract control transfer on chain state or pre authorized transfer smart contract control transfer on chain state or pre authorized transfer

threshold secret reconstruction

distributed shares or committees requirements or vision analysis framework no single storage password protected secret sharing password or factor material; server held protected material institutional backup or disaster institutional custody media recovery and procedures social or guardian recovery guardians or delegates

signing authority; account control restoring control seed or root secret; hybrid secret and control account control restoring signing authority control restoring

deterministic seed regeneration

original private key

secret restoring

threshold secret reconstruction

original private key

secret restoring

threshold secret reconstruction

hybrid secret and control restoring

share repair or refresh

institutional custody; payment or key share; signing permissioned blockchain; DeFi or authority smart contract application

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

A.1

user retained seed or memory artifact distributed shares or committees distributed shares or committees distributed shares or committees

29

30

Study [3]

[47]

[81] [90] [72]

[89]

[17] [67] [13]

[79]

[23]

[91] [62] [35]

Financial context Recovered object payment or permissioned key share blockchain; institutional custody; non financial transferable pattern self custody wallet, non financial recovery key transferable pattern

Secret/control axis secret restoring

Mechanism family share repair or refresh

secret restoring

password protected secret sharing password or factor material; server held protected material secure hardware or wrapped TEE or HSM assisted recovery secret threshold secret reconstruction distributed shares or committees biometric or fuzzy regeneration biometric source and helper data

self custody wallet; hardware seed or root secret secret restoring wallet self custody wallet; decentralized original private key secret restoring identity for finance self custody wallet; exchange or original private key secret restoring hosted wallet; payment or permissioned blockchain decentralized identity for finance; original private key secret restoring self custody wallet; non financial transferable pattern asset ownership or transfer control restoring self custody wallet payment or permissioned original private key secret restoring blockchain self custody wallet signing authority; account control restoring control; asset ownership or transfer payment or permissioned original private key secret restoring blockchain; self custody wallet self custody wallet; institutional seed or root secret; signing hybrid secret and control custody; DeFi or smart contract authority restoring application; payment or permissioned blockchain self custody wallet; decentralized original private key secret restoring identity for finance self custody wallet; forensics or original private key; forensic or adversarial asset investigation adversarial key extraction extraction non financial transferable pattern original private key secret restoring

threshold secret reconstruction

Enrollment/storage distributed shares or committees

distributed shares or committees

social or guardian recovery threshold secret reconstruction

guardians or delegates distributed shares or committees ownership proof or fallback signing on chain state or pre authorized transfer

password protected secret sharing password or factor material; server held protected material deterministic seed regeneration user retained seed or memory artifact

threshold secret reconstruction cryptanalytic key extraction threshold secret reconstruction

distributed shares or committees device backup or forensic evidence distributed shares or committees

SoK: Cryptographic Key Recovery for Financial Technologies

Table 14 Master matrix, part A: classification and mechanism fields. (continued)

Study [87]

Financial context self custody wallet

Recovered object seed or root secret

Secret/control axis secret restoring

[76]

institutional custody; secure hardware for financial infrastructure self custody wallet; payment or permissioned blockchain smart contract account; non financial transferable pattern

original private key; plaintext or application data original private key

framework or requirements requirements or vision

[66] [7]

[8]

[54]

smart contract account; self custody wallet; DeFi or smart contract application self custody wallet; hardware wallet; secure hardware for financial infrastructure self custody wallet

[104]

self custody wallet

[5]

self custody wallet; smart contract account; institutional custody; payment or permissioned blockchain institutional custody

[65]

[61] [4]

secret restoring

recovery key; account hybrid secret and control control; asset ownership or restoring transfer account control; asset control restoring ownership or transfer original private key

secret restoring

seed or root secret; signing hybrid secret and control authority restoring original private key secret restoring

Mechanism family threshold secret reconstruction

threshold secret reconstruction smart contract control transfer

distributed shares or committees on chain state or pre authorized transfer

smart contract control transfer

on chain state or pre authorized transfer

threshold secret reconstruction; TEE or HSM assisted recovery

distributed shares or committees; secure hardware or wrapped secret user retained seed or memory artifact distributed shares or committees on chain state or pre authorized transfer

deterministic seed regeneration threshold secret reconstruction

asset ownership or transfer; account control; signing authority

control restoring

smart contract control transfer

key share

secret restoring

threshold secret reconstruction

distributed shares or committees ownership proof or fallback signing on chain state or pre authorized transfer

[86]

self custody wallet; institutional signing authority; account control restoring custody; payment or control permissioned blockchain self custody wallet original private key secret restoring

memory based regeneration

[68]

self custody wallet

deterministic seed regeneration

seed or root secret; signing hybrid secret and control authority; account control restoring

Enrollment/storage distributed shares or committees analysis framework no single storage

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 14 Master matrix, part A: classification and mechanism fields. (continued)

user retained seed or memory artifact user retained seed or memory artifact

31

32

Study [44]

Financial context self custody wallet; hardware wallet; forensics or asset investigation

[84]

self custody wallet

[80]

self custody wallet

[73]

self custody wallet

[70] [49]

self custody wallet; smart contract account forensics or asset investigation

[55]

self custody wallet

[57]

self custody wallet

[51]

self custody wallet; secure hardware for financial infrastructure; non financial transferable pattern recovery key; account self custody wallet; smart hybrid secret and control contract account; DeFi or smart control; asset ownership or restoring contract application transfer non financial transferable pattern original private key; key secret restoring share self custody wallet original private key secret restoring

[78]

[102] [41] [100]

Recovered object original private key; seed or root secret; credential; forensic artifact; adversarial key extraction original private key

Secret/control axis forensic or adversarial extraction

Mechanism family forensic artifact recovery

Enrollment/storage device backup or forensic evidence

secret restoring

biometric or fuzzy regeneration

original private key; seed or root secret original private key

secret restoring

social or guardian recovery

biometric source and helper data guardians or delegates

secret restoring

password protected secret sharing password or factor material; server held protected material pre signed asset evacuation on chain state or pre authorized transfer forensic artifact recovery device backup or forensic evidence threshold secret reconstruction distributed shares or committees threshold secret reconstruction distributed shares or committees biometric or fuzzy regeneration biometric source and helper data

asset ownership or transfer control restoring forensic artifact original private key; key share key share; seed or root secret; account control recovery key

forensic or adversarial extraction secret restoring hybrid secret and control restoring secret restoring

decentralized identity for finance; seed or root secret; signing hybrid secret and control institutional custody; non authority restoring financial transferable pattern

social or guardian recovery

guardians or delegates

threshold secret reconstruction

distributed shares or committees distributed shares or committees secure hardware or wrapped secret

threshold secret reconstruction TEE or HSM assisted recovery

SoK: Cryptographic Key Recovery for Financial Technologies

Table 14 Master matrix, part A: classification and mechanism fields. (continued)

Study [21]

Financial context self custody wallet; hardware wallet; smart contract account

Recovered object account control

Secret/control axis control restoring

Mechanism family passkey or backup authenticator recovery; smart contract control transfer

[22]

hardware wallet; self custody wallet; smart contract account; secure hardware for financial infrastructure self custody wallet; DeFi or smart contract application payment or permissioned blockchain self custody wallet

account control; asset ownership or transfer; signing authority

control restoring

smart contract control transfer

original private key

secret restoring

threshold secret reconstruction

original private key

secret restoring

threshold secret reconstruction

seed or root secret

secret restoring

deterministic seed regeneration

hybrid secret and control restoring

threshold secret reconstruction

secret restoring

biometric or fuzzy regeneration

[103] [99] [48] [59]

[71]

decentralized identity for finance; key share; signing self custody wallet; non financial authority transferable pattern self custody wallet seed or root secret

[94]

self custody wallet

[85] [10] [33]

[93]

signing authority; account control restoring control; asset ownership or transfer self custody wallet; payment or seed or root secret; hybrid secret and control permissioned blockchain account control restoring self custody wallet; non financial original private key secret restoring transferable pattern secure hardware for financial original private key secret restoring infrastructure; non financial transferable pattern institutional custody; exchange original private key; key hybrid secret and control or hosted wallet; secure hardware share; signing authority; restoring for financial infrastructure asset ownership or transfer

Enrollment/storage on chain state or pre authorized transfer; backup authenticator or reissued credential on chain state or pre authorized transfer

distributed shares or committees distributed shares or committees user retained seed or memory artifact distributed shares or committees

biometric source and helper data ownership proof or fallback signing on chain state or pre authorized transfer deterministic seed regeneration threshold secret reconstruction TEE or HSM assisted recovery

institutional backup or disaster recovery

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 14 Master matrix, part A: classification and mechanism fields. (continued)

user retained seed or memory artifact distributed shares or committees secure hardware or wrapped secret institutional custody media and procedures

33

34

Study [92]

[50] [34] [9] [88]

[12]

[77] [11]

[18] [58] [60] [20]

A.2

Financial context non financial transferable pattern; decentralized identity for finance forensics or asset investigation

Recovered object Secret/control axis credential; account control control restoring

forensic or adversarial extraction hybrid secret and control restoring secret restoring

Enrollment/storage backup authenticator or reissued credential

device backup or forensic evidence decentralized identity for finance; credential; plaintext or institutional backup or disaster institutional custody media non financial transferable pattern application data recovery and procedures self custody wallet seed or root secret threshold secret reconstruction distributed shares or committees self custody wallet; DeFi or signing authority; account control restoring password protected secret sharing password or factor material; smart contract application control server held protected material self custody wallet; smart original private key; key framework or requirements recovery analysis framework analysis framework no single contract account; DeFi or smart share; account control; storage contract application signing authority self custody wallet recovery key; signing hybrid secret and control biometric or fuzzy regeneration biometric source and helper authority restoring data self custody wallet; hardware original private key secret restoring passkey or backup authenticator backup authenticator or wallet; secure hardware for recovery reissued credential financial infrastructure payment or permissioned original private key secret restoring credential reissuance or rotation backup authenticator or blockchain; self custody wallet reissued credential asset ownership or transfer control restoring pre signed asset evacuation on chain state or pre self custody wallet authorized transfer decentralized identity for finance signing authority; key hybrid secret and control threshold secret reconstruction distributed shares or share restoring committees self custody wallet; DeFi or original private key; hybrid secret and control deterministic seed regeneration user retained seed or smart contract application signing authority restoring memory artifact

Recovery Semantics

forensic artifact

Mechanism family passkey or backup authenticator recovery; credential reissuance or rotation forensic artifact recovery

SoK: Cryptographic Key Recovery for Financial Technologies

Table 14 Master matrix, part A: classification and mechanism fields. (continued)

Study [52]

[96]

[108]

[101]

[106]

[16]

[53]

[107] [42]

[19]

[98]

Recovery trigger Failure event class loss of local secret availability with key material or device loss password retained; user initiates reconstruction by contacting t+1 servers lost device or lost private key / later need device or credential loss to retrieve encrypted backup migration; key material or device loss lost device or lost private key/account device or credential loss credentials migration; key material or device loss unavailable signer, custodian participant or service refusal/unavailability, or smart-contract unavailability; institutional paralysis proven by timeout or failed test disaster or governance change enterprise joint authorization need for not stated or general loss transaction signing under distributed control key leakage, exposed derived key plus not stated or general loss higher-level public key, or repeated randomness in stealth-address transactions need to retrieve previously shared secret; key material or device loss succeeds only with correct password and at least t+1 honest servers one or both service units fail; disaster institutional disaster or destroys provider-side data governance change lost device or device replacement/update device or credential loss of the management device migration; key material or device loss hot-wallet compromise and later need for cold wallet to derive per-transaction signing key from on-chain ID lost device or terminal damage causing loss of private key

compromise or theft; key material or device loss device or credential loss migration; key material or device loss

Authorization method credential

Post-recovery state same or equivalent secret available

any k confidants return valid shares

same or equivalent secret available

prior transaction partners vote with three-fifths supermajority; original owner can veto migration rule satisfied by on-chain challenge-response, Merkle proof of failed test, or TEE-signed transition per-sub-account CP-ABE access tree plus global t-of-n threshold

new control relation or credential

recipient spend secret authorizes normal spending; no separate authorized recovery workflow stated password only

analysis only no single post state

new control relation or credential same or equivalent secret available

same or equivalent secret available

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 15 Master matrix, part B: recovery semantics.

Bitcoin 3-of-5 multisignature; user provides operational access restored or more keys in degraded modes rekeyed user personal information plus new control relation or signature-based server authentication, with credential biometric authentication between user and management device cryptographic authorization by deriving sk same or equivalent secret ID on the cold wallet and producing a valid available signature same or equivalent secret zero-knowledge-proof-style password knowledge proof plus threshold share return available

35

36

Study [43]

[69]

[3]

[47] [81]

[90]

[72] [89]

[17]

[67]

[13] [79]

Recovery trigger local key data missing on reconnect; storage-node offline or node destruction affecting availability unavailable signer

Failure event class participant or service unavailability

Authorization method Post-recovery state biometric-derived identity material plus same or equivalent secret routing ID, authentication info, and available nonce-based challenge-response participant or service threshold verification and interpolation with share or committee refreshed unavailability; key material or committee participation and on-chain device loss commitment checks threshold recovery contributions from f+1 share or committee refreshed unavailable or missing replica share during participant or service PBFT execution, view change, or state unavailability; key material or replicas with verification transfer device loss device loss, failure, or theft compromise or theft; key password for remote PPSS plus out-of-band same or equivalent secret material or device loss authentication for local/social shares available lost device or broken wallet motivates device or credential loss user visual verification of vcode on trusted same or equivalent secret proactive backup creation migration; key material or wallet screens plus physical-button available device loss confirmation lost key or need to restore wallet secret key device or credential loss wallet authenticates user; threshold share same or equivalent secret migration; key material or release from at least t providers available device loss every signing event; motivated by lost or key material or device loss biometric sample sufficiently close to same or equivalent secret leaked stored keys enrollment available lost device or key access, forgotten device or credential loss possession of secured private key sK plus same or equivalent secret passphrase, hardware corruption, migration; key material or threshold subset of correct answers to available long-term loss of access device loss personal security questions lost device or lost private key / device or credential loss threshold assistants + zero-knowledge user new control relation or inaccessible original wallet key migration; key material or proof + off-chain identity confirmation credential device loss lost device or lost private key due to crash, device or credential loss CA re-authentication plus identity same or equivalent secret data damage, or force majeure migration; key material or confirmation by committer peers and user available device loss biometric key compromised key compromise or theft challenge-response proof using hidden new control relation or backup key credential lost device or lost private key is implied; participant or service password-based authorization using p or p’ same or equivalent secret exact trigger conditions beyond key unavailability; device or with threshold server responses available unavailability are not stated credential loss migration; key material or device loss

SoK: Cryptographic Key Recovery for Financial Technologies

Table 15 Master matrix, part B: recovery semantics. (continued)

Study [23]

[91]

[62] [35]

[87]

[76]

[66]

[7]

[8]

[65]

Recovery trigger lost device or wallet, hardware failure, natural disaster, catastrophic loss; also hierarchy change or key replacement for rekeying lost device or key unavailability not formally specified; recovery begins when local secret is unavailable nonce reuse or complementary nonce causing duplicated r Not stated; reconstruction is described when access to the encrypted key-protected data is needed, but no explicit loss, compromise, or disaster trigger is defined. device loss, theft, corruption, or destruction

Failure event class Authorization method device or credential loss possession of initial seed and master secret migration; key material or rooted certificate authority device loss; institutional disaster or governance change participant or service biometric identity verification via unavailability; device or reconstructed IBV and CBV comparison, credential loss migration; key then threshold provider response material or device loss forensic or adversarial recovery; None; any observer with public blockchain key material or device loss data can perform extraction compromise or theft; key threshold possession of shares material or device loss; institutional disaster or governance change

Post-recovery state same or equivalent secret available

same or equivalent secret available

artifact or key extracted for investigation same or equivalent secret available

same or equivalent secret user supplies both ciphertexts and available corresponding decryption components, or access to two configured endpoints/accounts missing periodic heart-beat after timeout death or incapacity; participant Not stated consistently; examples mention analysis only no single post due to sysadmin unavailability or service unavailability any other supplier actor, CEO, regulator, or state judge-assisted process; this matters because unclear authorization prevents comparison of abuse resistance and liveness lost wallet private key; insufficient participant or service CA certificate plus biometric key SK same or equivalent secret primary-threshold peer responses due to unavailability; key material or available failure or malicious behavior device loss lost device or lost main blockchain private device or credential loss knowledge of answers to security questions new control relation or key for the original account; only migration; key material or plus signature under reconstructed proof key credential contract-deposited assets are recoverable device loss key loss, key theft, or policy-flagged compromise or theft; key digital signature plus DZT security-question new control relation or exceptional transaction material or device loss authentication or U2F token; optionally credential 2FA-only in liberal mode lost/broken/stolen device; lost access to compromise or theft; key possession of threshold number of shares same or equivalent secret key; lost password material or device loss available compromise or theft; key material or device loss

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 15 Master matrix, part B: recovery semantics. (continued)

37

38

Study [54]

[104]

[5]

[61]

[4]

[86]

[68]

[44]

[84] [80]

[73]

Recovery trigger lost device; forgotten password or mnemonic

Failure event class Authorization method Post-recovery state device or credential loss possession of stego image plus synchronized same or equivalent secret migration; key material or address book and user re-entry/reselection available device loss of recovery parameters lost device or lost key not stated precisely; forensic or adversarial recovery; qualified participant subset under general same or equivalent secret evidence supports lost key device or credential loss access structure / threshold available migration; key material or device loss accidental key loss or transfer to key material or device loss claimant initiates commit-reveal-claim; new control relation or mistyped/unknown address current owner vetoes by proof of possession credential within challenge window lost device or lost share; paper states loss device or credential loss threshold participation by t helper parties same or equivalent secret of a secret share, including simple loss or migration; key material or available extortion-triggered loss of availability device loss lost key, unreachable signer, or signer remaining online signer engages offline new control relation or participant or service unavailability unavailability; key material or recovery party using pre-distributed credential device loss encrypted recovery material lost device or lost private key / inability to device or credential loss user recalls picture locations and repository same or equivalent secret use mnemonic backup; exact trigger is loss migration; key material or returns stored pictures/public key based on available of private key device loss user’s basic information; repository authentication not stated hardware breakdown or wallet participant or service possession of master secret key (a,b) by the same or equivalent secret unavailability requiring reconstruction unavailability; key material or wallet owner available from backed-up master secret device loss law-enforcement search and urgent seizure forensic or adversarial recovery legal search/seizure authority under artifact or key extracted for need; live host access before volatile POCA/PACE, not user authorization investigation artefacts disappear lost private key or need wallet access to key material or device loss biometric measurement of the user; exact same or equivalent secret initiate transaction verification process not stated available lost device secret in the form of lost device or credential loss threshold shareholder approval plus email new control relation or private key or mnemonic phrase migration; key material or OTP plus fingerprint-based fuzzy vault credential device loss decoding lost or forgotten authentication factor key material or device loss threshold t-of-n authentication factors via same or equivalent secret threshold MFKDF available

SoK: Cryptographic Key Recovery for Financial Technologies

Table 15 Master matrix, part B: recovery semantics. (continued)

Study [70]

[49]

[55]

[57]

[51]

[78]

[102] [41]

[100]

[21]

[22]

Recovery trigger Failure event class Authorization method Post-recovery state lost device or inaccessible original private device or credential loss pre-authorization via transaction signed assets moved to recovery path key; example includes forgotten password migration; key material or with original key at setup; no strong for hot wallet access device loss authentication at activation in base design confiscated device investigation where forensic or adversarial recovery; legal warrant and, in some cases, exchange artifact or key extracted for investigators lack wallet address/private key material or device loss or token-issuer cooperation investigation key user requests key restoration; periodic key material or device loss server-to-server proof-based validation for same or equivalent secret scrubbing detects failed or invalid server share checking; user recovery request available share authentication Not stated lost device share due to storage loss/app device or credential loss user password plus SIM-held data plus same or equivalent secret uninstall/device change; password change; migration; key material or server-held encrypted share for lost-share available SIM loss discussed operationally device loss recovery lost device-stored key or lost device or credential loss fresh biometric capture plus helper data same or equivalent secret cryptographic key migration; key material or Q/CP and external salt or identifier available device loss lost device or lost private key; compromise or theft; device or threshold guardian assistance plus biometric new control relation or credential compromised key credential loss migration; key verification plus smart-contract check of registered recovery key material or device loss epoch transition under node churn and compromise or theft; key hierarchical threshold access structure K same or equivalent secret compromise accumulation material or device loss available user needs to use private key; motivated key material or device loss WebAuthn/FIDO2 hardware-token same or equivalent secret by loss/non-storage of local wallet secret authentication plus threshold server available verification Not stated; only general MFA, separation of same or equivalent secret key loss / system failure key material or device loss duties, and four-eyes controls are mentioned, available which matters because recovery authorization is central to abuse resistance lost device; stolen device; malfunction; compromise or theft; device or pre-signed ARC by current owner plus new control relation or compromise of hardware wallet credential loss migration; key TK/passkey signature over new owner credential material or device loss address hardware wallet loss, theft, or malfunction compromise or theft; key KRC signature verification plus new control relation or without backup material or device loss secret-and-commitment consistency checks credential enforced by registry smart contract

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 15 Master matrix, part B: recovery semantics. (continued)

39

40

Study [103]

[99]

Recovery trigger Failure event class lost device, data damage, or hacking device or credential loss causing loss/leakage of wallet data; user migration; key material or initiates recovery rounds device loss lost or unavailable private key; participant or service reconstruction also threatened by silent or unavailability; key material or colluding share-holding nodes device loss

[48]

lost device or device crash of wallet host

[59]

lost device or lost/damaged user secret share in DID wallet

[71]

[94]

[85]

[10]

[33]

[93]

device or credential loss migration; key material or device loss device or credential loss migration; key material or device loss key material or device loss

Authorization method threshold participant submissions plus smart-contract verification and user-side checking user reconstruction request in a CA-authenticated consortium blockchain setting; exact recovery authorization procedure not stated possession of seed or master secret; no separate recovery authorization stated

Post-recovery state same or equivalent secret available same or equivalent secret available

same or equivalent secret available

user initiates by sending new identifier to same or equivalent secret TTP; secure authenticated channels available assumed lost mnemonic phrase biometric reproduction via fuzzy extractor; same or equivalent secret optional additional 2FA for helper-data available download is suggested compromised or exposed classical wallet compromise or theft; key user proves knowledge of backup key linked new control relation or credential private key; anticipated quantum break of material or device loss to wallet key via non-interactive zero-knowledge proof, using backup key and classical signatures stored x same or equivalent secret lost credentials, forgotten password, compromise or theft; device or Not stated; paper only says authorized hardware failure, failed authentication, credential loss migration; key Global Ledger users can access the Recovery available Ledger corrupted or compromised wallet material or device loss lost device or lost private key; unavailable participant or service threshold number of verified participating same or equivalent secret signer or offline fragment holder unavailability; device or nodes available credential loss migration; key material or device loss lost device or device switching; later need device or credential loss password-based authentication, with same or equivalent secret to retrieve stored key with password migration; key material or HSM-backed checks and in OPRF-PPKR available device loss recovered signing key proof media failure, KMF disaster, media compromise or theft; key M-of-N treasurer approval, with all N operational access restored or loss/theft, personnel change, threshold material or device loss; required for initial KeyGen rekeyed change, suspected compromise institutional disaster or governance change

SoK: Cryptographic Key Recovery for Financial Technologies

Table 15 Master matrix, part B: recovery semantics. (continued)

Study [92]

[50]

[34]

[9]

[88]

[12]

[77]

[11]

[18]

[58]

Recovery trigger lost device or lost primary authenticator

Failure event class device or credential loss migration; key material or device loss

Authorization method Post-recovery state backup authenticator proves possession of new control relation or backup key by producing a recovery credential response/signature over a server challenge tied to a stored recovery credential discovery or suspicion of forensic or adversarial recovery procedural controls including user validation artifact or key extracted for cryptocurrency-related artifacts in seized for private key material, witness investigation evidence requirement, and supervisor notifications lost device and restore onto a new phone device or credential loss Pod server username plus hashed password, operational access restored or from prior encrypted backup migration; key material or plus separate backup password for local rekeyed device loss; institutional decryption disaster or governance change lost, stolen, damaged, or destroyed device compromise or theft; key Not stated clearly; appears to rely on same or equivalent secret or hardware wallet; private key loss or material or device loss possession of decryption keys, encrypted available hardware failure parts, and correct ordering information forgotten password; lost TOTP device; device or credential loss email OTP/OOBA plus TOTP and same or equivalent secret lost key file; portability need from another migration; key material or password reset workflow available device device loss key loss; user unavailability/non-response; participant or service threshold shares/components for key analysis only no single post agent corruption/collusion affecting unavailability; key material or reconstruction; guardian approval plus state composed recovery paths device loss challenge window for key rotation; KELP commit-reveal-claim-challenge with collateral and delays biometric unavailability; loss or user death death or incapacity; participant user biometric participation plus same or equivalent secret or service unavailability; key wallet-provider helper-key activation; available material or device loss inheritance also uses heir biometric and shared temporal key loss/failure of one MFA factor, especially key material or device loss remaining MFA factors plus stored values, new control relation or token; loss of terminal device with keystore-assisted release of CT-T and credential suggested out-of-band code lost private key; inheritance is motivated death or incapacity; device or identity verification by TA plus committee new control relation or but workflow details are not stated credential loss migration; key enrollment approval credential material or device loss private key loss; owner death or incapacity; key identity verification by trusted recovery assets moved to recovery path disappearance/death material or device loss service provider

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 15 Master matrix, part B: recovery semantics. (continued)

41

42

Study [60]

Recovery trigger lost or compromised wallet key share; participant unavailability; key revocation lifecycle events

[20]

lost device; smartphone loss, damage, or change; IPFS unavailability

A.3

Trust, Threats, and Evidence

Failure event class compromise or theft; participant or service unavailability; key material or device loss participant or service unavailability; device or credential loss migration; key material or device loss

Authorization method 2-of-3 threshold signing plus registered device checks and TTP key-status verification

Post-recovery state same or equivalent secret available

24-word mnemonic plus password; smart-contract device authorization; prototype also uses QR scans

same or equivalent secret available

Table 16 Master matrix, part C: trust, threats, and evidence. Study [52]

Trust model threshold trust in servers; up to t compromised servers reveal nothing, trusted/authenticated initialization required

[96]

distributed social trust; secure if fewer than k confidants collude; recovery tolerates up to n-k unavailable helpers

[108]

Adversary model Security properties unauthorized recovery via online password safety, liveness, privacy, guessing, compromise of up to t servers, non custodiality, and man-in-the-middle control of robustness communication channels

unauthorized recovery via colluding confidants, physical theft, social engineering, and remote compromise avoided by offline storage; formal model not stated decentralized social verification by prior fraudulent recovery requester, social transaction partners plus correct engineering, vote buying, smart-contract enforcement; no custodian Sybil/duplicate-account voter manipulation, 51% attack

Validation type formal proof, security game

safety; availability; non prototype; user custodiality; limited study; survey or accountability; usability interview tradeoff safety; privacy; liveness; prototype; simulation availability; non custodiality; accountability; revocability; usability

Deployment status conceptual design with formal analysis; no prototype or operational deployment stated prototype study workflow, not operational deployment prototype implementation on Hyperledger Composer; no operational deployment stated

SoK: Cryptographic Key Recovery for Financial Technologies

Table 15 Master matrix, part B: recovery semantics. (continued)

Study [101]

Trust model Adversary model Security properties blockchain as censorship-resistant stateful Byzantine corrupted parties, strong safety; liveness; channel plus smart contract or SGX trust network adversary, malicious host/OS availability; robustness; anchor against TEE, stale-proof and accountability; false-accusation attempts; formal proof for revocability; partial non static adversaries custodiality

[106]

trusted owner/master-account for setup and final reconstruction; authorized departmental users for share decryption; standard trust in Bitcoin miners for transaction validation recipient protects spend key(s); sender uses fresh randomness; auditor/read-only wallet can monitor but not spend

[16]

[53]

[107]

unauthorized managers, colluding safety, robustness, participants, eavesdroppers, transaction privacy, availability tamperers, and possible trading-platform theft as informally discussed attacker recovers master private key from safety; privacy; derived key plus higher-level public key, or availability; robustness; spend key from audit material plus non custodiality repeated randomness

threshold trust in n servers with at most t up to t corrupted servers, online corrupt; secure/authenticated channels password-guessing interactions, and and correct setup assumed network/man-in-the-middle adversary; static corruption in shown theorem user retains 3 keys; two provider service theft or cracking of provider-stored keys; units each store one encrypted key; broader adversary model not stated disaster recovery center restores provider-side state

Validation type Deployment status formal proof; prototype with prototype; Bitcoin testnet benchmark; gas deployment cost measurement; evidence; no case study operational production deployment stated prototype, prototype only benchmark

formal proof; security game

safety, liveness, privacy, availability, non custodiality

formal proof, security game

safety; availability; robustness

simulation

analysis of deployed systems and variants; no prototype or operational deployment by authors stated no evaluation

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

conceptual design with analytical and simulated evaluation; operational deployment not stated

43

44

Study [42]

[19]

[98]

Trust model Adversary model Security properties Validation type honest-but-curious central server plus safety; privacy; formal proof; server database reader, attacker with semi-trusted social-network helpers; secure access to management device storage, availability; liveness; non prototype; runtime assumed malware/physical theft discussed custodiality; usability benchmark informally; collusion and coercion not fully stated self-custodial hot/cold split; hot wallet hot-wallet compromise, observation of safety; privacy; non formal proof; may be compromised; cold wallet must blockchain keys/signatures, state exposure, custodiality security game; remain secret and synchronized; miners related-key attacks benchmark only verify signatures

user must keep password secret; enough collusion and malicious share holders, share-holder nodes must be available and network attackers, eavesdropping, replay, not all malicious DDoS, Sybil; password compromise handling not clearly modeled decentralized storage and neighbor nodes malware theft motivation, fake attacks, with threshold availability; no central replay attacks, source-address inference, custodian; exact collusion assumptions not and partial node destruction; broader stated collusion model not stated

safety, liveness, availability, robustness, limited privacy

[69]

threshold-honest committee under active PPT adversary bounds, synchronous blockchain/network assumptions, and KZG setup trust or at-least-one-honest setup assumption

safety; liveness; availability; robustness; accountability; non custodiality

[3]

BFT threshold trust with n=3f+1, at most Byzantine dealer/client and up to f f Byzantine replicas, authenticated Byzantine replicas; secrecy against fewer channels, PKI, eventual synchrony than threshold shares

[43]

active adversary corrupting up to threshold-bounded committee members, plus possible KZG setup/assumption failure

simulation, prototype, benchmark

safety, liveness, simulation, availability, robustness, benchmark privacy, non custodiality

formal proof; prototype; benchmark; case study

safety; liveness; privacy; formal proof; availability; robustness; prototype; accountability benchmark

Deployment status prototype only

conceptual design with formal analysis and Bitcoin transaction cost discussion; no operational deployment stated prototype only

prototype deployment not stated; operational deployment not stated; evaluated by experiments and simulations only prototype deployment and lab/mainnet experiments only; no operational deployment stated prototype only

SoK: Cryptographic Key Recovery for Financial Technologies

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

Study [47]

[81]

[90]

[72]

[89]

[17]

Trust model split trust across local holders, social helpers, remote organizations, cloud storage availability, and recommender honesty trusted wallet screens/buttons and hardware storage; untrusted smartphone relay; user-in-the-loop verification

Adversary model Security properties Validation type unauthorized recovery via collusion and safety, availability, prototype, password guessing; denial of recovery via liveness, privacy, non benchmark cloud withholding/deletion or request-limit custodiality, revocability, exhaustion usability compromised terminal, safety; non custodiality; prototype; eavesdropping/sniffing, MITM public-key availability; usability benchmark substitution, wallet theft; compromised wallet internals not stated trusted wallet endpoint; semi-trustworthy collusion of fewer than t escrow providers safety; availability; prototype; no escrow providers; trusted DLT lookup and is resisted; broader unauthorized recovery liveness; limited non evaluation secure channels; fewer than t providers and endpoint compromise model not custodiality; claimed cannot reconstruct stated privacy

trust biometric sensor/authentication malware stealing stored keys; server safety; non custodiality; prototype; device for correct regeneration; do not hacking; malicious administrator; privacy claimed for benchmark trust server admin with secret-key custody credential leakage in hosted wallet model; template leakage; template leakage discussed informally usability and automation tradeoff self-service local recovery with no external qualitative discussion of key theft, insecure safety; liveness; prototype recovery server; trust in user retention of cloud storage, guessable or publicly availability; non sK and secrecy/memorability of answers inferable answers; no formal adversary custodiality; usability model stated non-custodial assistants and modified unauthorized recovery by colluding safety, privacy, non formal proof, blockchain nodes are trusted for correct assistants, malicious custodiality, availability, security game, participation; at least one CRS setup users/nodes/assistants, ledger observers, accountability prototype, participant must destroy randomness; and verification-bypass attackers; endpoint benchmark, off-chain channels are trusted for user compromise and network/consensus simulation authentication attacks excluded

Deployment status prototype only

prototype only

conceptual design with high-level proof-of-concept implementation claim, no operational deployment shown prototype on Hyperledger Fabric; no operational deployment stated

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

prototype integration demo in Ethereum-based SSI application prototype on modified Ethereum EVM/geth, not operational deployment

45

46

Study [67]

[13]

[79]

[23]

[91]

[62]

[35]

Trust model hybrid cryptographic and institutional trust in threshold peers, CA authentication, and user-held biometric key user-held backup key with verifier acceptance; blockchain/protocol support needed for full on-chain fallback

Adversary model man-in-the-middle attacker, colluding or bribed committer peers, malicious peers returning altered shares

Security properties Validation type safety, robustness, formal proof availability, non custodiality, revocability

leaked ECDSA secret key attacker; safety; non custodiality; hot-wallet compromise; quantum/ECDLP revocability; break; forgery attempts against eW-OTS+ accountability; limited liveness honest-but-curious recovery servers with honest-but-curious insiders, external safety; privacy; Dolev-Yao attackers, spoofing, availability; robustness tolerance for some malicious or faulty nodes in a threshold setting eavesdropping, and collusion attempts centralized trust in cold storage holder of formal corruption of arbitrary users with safety; availability; descendant compromise, signing oracle seed and msk; hierarchical trust where robustness; ancestors can derive descendant keys; access, and prevention of upward privilege accountability; limited blockchain scripting environment must escalation; cold storage compromise is revocability; usability verify certificates catastrophic trusted wallet plus semi-trustworthy key provider compromise and sub-threshold safety; privacy; escrow providers and blockchain-based collusion explicitly discussed; broader availability; non provider registry wallet, biometric, coercion, and DoS custodiality; limited threats not stated robustness; limited revocability no trusted third party; safety depends on public-data attacker exploiting duplicated safety failure; limited signatures to compute Bitcoin private keys privacy discussion; non correct ECDSA nonce generation, and attacker needs only public blockchain custodiality context access

formal proof; security game; prototype; benchmark no evaluation

threshold secret-sharing assumption with external and internal attackers stealing or safety, availability, distributed cloud resource providers; fewer hacking keys; brute-force attack discussed; liveness, robustness than threshold shares cannot reconstruct, collusion and malicious providers not but provider collusion and malicious explicitly modeled behavior are not explicitly modeled

simulation, benchmark

formal proof; prototype; benchmark

prototype; no evaluation

prototype; case study

Deployment status conceptual design only; no prototype or operational deployment stated prototype only

conceptual design with analytical comparison only prototype on Bitcoin Cash test blockchain; no operational deployment stated prototype only

prototype analysis on historical Bitcoin blockchain data; no deployed recovery or mitigation system stated prototype-like Matlab simulation only; no operational deployment stated

SoK: Cryptographic Key Recovery for Financial Technologies

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

Study [87]

[76]

[66]

[7]

[8]

[65]

Trust model Adversary model Security properties Validation type at least one of two physically separated unauthorized recovery by attacker safety, availability, formal proof storage locations remains uncompromised compromising one storage location; robustness, non and available; user trusts wallet software factoring and brute-force on random value custodiality, usability and storage/account access paths discussed; compromise of both locations not stated trusted sysadmin; semi-honest bank and semi-honest insiders and external safety; liveness; no evaluation non-sysadmin supplier actors; additional adversaries; escrow collusion, stale-puzzle availability; limited recovery actors not formalized recovery, blockchain fork interference, accountability discussion; malicious sysadmin noted but not solved unclonability desired for heart-beat puzzle user trusted; consortium peers store malicious peers sending wrong shares; safety; liveness; formal proof shadow shares and must meet threshold bribed peers; man-in-the-middle availability; robustness; availability; CA trusted for registration interception; external key theft attempts; limited non custodiality; and identity confirmation collusion claimed resisted partial revocability; claimed privacy prototype; safety, liveness, non no trusted third party; trust in Ethereum public blockchain observer can read simulation; custodiality, limited smart contract execution, client-side questions and encrypted shares and benchmark; gas privacy, limited cryptographic processing, and secrecy of perform unlimited offline guessing; cost measurement user-chosen answers attacker may initiate malicious recovery if accountability, partial revocability answers are cracked smart-contract-enforced policy with stolen key/credentials, corruption of up to safety; liveness; privacy; formal proof; threshold committee or hardware token; t-1 committee parties, offline guessing of availability; robustness; security game; no central trusted authority stated low-entropy answers, replay, malformed accountability; usability prototype; responses, denial of service benchmark; gas cost measurement trust in Intel SGX enclave and device/software compromise, keylogging, safety; availability; prototype implementations; remote server stores side-channel attacks, memory exposure of liveness; non custodiality; encrypted share; malicious parties fewer printable share, MITM on server qualitative privacy than threshold communication, SGX attacks

Deployment status conceptual design only

conceptual design / vision only

no evaluation

prototype evaluation only; no operational deployment stated

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

prototype deployment on Ethereum only; no operational deployment stated prototype implementation only

47

48

Study [54]

[104]

[5]

[61]

[4]

[86]

Trust model Adversary model Security properties Validation type user-retained recovery artifacts and local dictionary attacker; blockchain linkability safety; privacy; prototype; recomputation; no trusted third party for observer; physical theft/observation and availability; liveness; non benchmark; signing authority; cloud storage malware mentioned informally; cloud custodiality; usability simulation availability/integrity assumptions are compromise and metadata tampering not informal fully modeled distributed participants must retain and unauthorized recovery by forbidden safety, liveness, non formal proof, provide shares; forbidden subsets learn subsets modeled; broader collusion, custodiality simulation, nothing; setup/model trust not fully stated coercion, malware, and stolen-share benchmark threats not stated relies on on-chain enforcement plus unauthorized claimers, front-running, safety; liveness; prototype; case synchrony and no prolonged censorship random testing, heuristic targeting, availability; non study custodiality; during t2; no secret escrow helper deanonymization, short-range and long-range censorship, key destruction accountability; limited attack privacy; some revocability in key-rotation settings cryptographic trust in Shamir sharing, malicious static PPT adversary corrupting safety, privacy, formal proof, commitments, secure channels, and at up to t-1 parties in a partially synchronous availability, non security game, most t-1 static malicious corruptions; network custodiality prototype, active availability of t helpers required benchmark trustless setup with non-collusion adaptive malicious adversary corrupting at safety; liveness; formal proof; assumption; secure if sub-threshold parties most t-1 players; forgery resistance under availability; non security game; collude and one helping party remains Schnorr, non-malleable commitment, custodiality; robustness simulation honest; recovery depends on offline party DDH, and IND-CPA assumptions cooperation user memory plus repository and map unauthorized recovery via repository safety, usability, limited prototype; user application availability/integrity; attack, brute-force GPS guessing, and non custodiality, liveness study; benchmark repository security/authentication not inference of locations from picture content; stated many practical threats not stated

Deployment status prototype evaluation only

conceptual design with lab evaluation; no operational deployment stated prototype-level Diem implementation noted; no operational deployment stated prototype only; no operational deployment stated conceptual design with formal analysis only

prototype deployment in a mobile wallet application; operational deployment not stated

SoK: Cryptographic Key Recovery for Financial Technologies

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

Study [68]

[44]

[84]

Trust model non-custodial single-owner trust; security relies on secrecy of master spend component and secure backup of master secret

Adversary model Security properties Validation type chosen-message adversary with corruption safety; privacy; non formal proof; of arbitrary derived signing keys and custodiality; limited security game; master secret view key; privacy adversary usability prototype; attempts linkage of derived benchmark keys/signatures institutional trust in investigators and offline dictionary attacker using seized availability; prototype; evidence handling; operational trust in host artefacts; target wallet owner may accountability; limited benchmark; case forensic tools, cloud GPUs, and blockchain resist through encryption, hardware-wallet safety via forensic study APIs separation, or app termination integrity measures; weak privacy self-service recovery relying on user unauthorized key guessing and general safety, liveness, non prototype, biometric data and trusted local software; unauthorized access mentioned; formal custodiality; privacy and benchmark no guardians or custodians stated adversary model not stated robustness claimed informally but not formalized

[80]

threshold social helpers plus smart unauthorized recovery with fewer than safety; privacy; prototype; contracts, with residual wallet admin trust threshold shares is addressed; broader availability; robustness; benchmark for Public contract deployment and OTP collusion, coercion, email compromise, and non custodiality; signing recovery-endpoint compromise are not accountability; usability stated

[73]

no trusted third party or committee; untrusted public storage for public parameters; security depends on possession of threshold factors

unauthorized recovery via compromised factors, brute-force attacks, storage-layer DoS, temporary eclipse attack, factor compromise such as SIM swapping

safety, liveness, availability, non custodiality, usability

prototype

Deployment status prototype only

prototype and lab evaluation only

conceptual design with lab-style experimental evaluation; no operational deployment stated prototype on Ganache local Ethereum test network, not operational deployment prototype Ethereum web wallet validated on testnet and mainnet, not stated as operational deployment

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

49

50

Study [70]

[49]

[55]

[57]

[51]

[78]

Trust model user trusts cold storage of backup key, smart contract correctness, and availability/correctness of Chainlink, external adapter, and IPFS

Adversary model Security properties Validation type unauthorized activation, backup-key theft, liveness; non custodiality; prototype; destination rewriting, forged emergency accountability; partial benchmark; gas contract, privacy leakage from exposed privacy, with weakened cost measurement recovery data safety due to unauthenticated activation investigators need lawful device access and criminal wallet users and liveness, availability, case study accurate forensic analysis; some cases encrypted/hidden wallet artifacts; false accountability require exchange or issuer cooperation positives in artifact search; broader misuse threats not stated

distributed backup servers plus system manager and recruitable replacement server; threshold availability required

share tampering, unavailability, and safety; liveness; privacy; plaintext leakage during repair explicitly availability; partial non considered; colluding servers and custodiality goal unauthorized requester model Not stated trusted central server, trusted SIM storage, informal discussion of brute force, MITM, safety; availability; trusted device/Android KeyStore, dictionary attack, keylogger, and DoS; liveness; robustness; assumption that at least 2 of 3 entities are collusion and insider compromise not partial non custodiality; available stated usability

prototype; benchmark; simulation

user biometrics must remain reproducible; malware, brute force, ciphertext-only, and safety; privacy; helper data storage on known-text attacks considered; robustness; revocability; device/server/TTP/HSM must remain communication attacks excluded; usability available; secure communication channel spoofing/coercion/helper-data tampering assumed not fully modeled user-selected guardians with k-of-n unauthorized recovery via guardian safety; liveness; threshold; trusted smart-contract collusion or eavesdropping is mentioned availability; privacy; enforcement; secure communication informally; no formal adversary model robustness; non channels; biometric mechanism stated custodiality assumptions

prototype; benchmark

no evaluation

Deployment status prototype on Goerli testnet, not stated as operational deployment

lab-style case studies on Windows 10 wallets; operational deployment not stated prototype only

conceptual design only; no prototype or deployment stated in supplied evidence prototype and lab evaluation; blockchain use case conceptual only

prototype; prototype only benchmark; gas cost measurement

SoK: Cryptographic Key Recovery for Financial Technologies

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

Study [102]

[41]

[100]

[21]

[22]

[103]

Trust model Adversary model Security properties Validation type no TTP; threshold trust in hierarchical active computationally bounded adversary safety, liveness, formal proof, committee, trusted user setup server, with threshold-bounded node corruption availability, robustness, prototype, blockchain commitment availability, and arbitrary deviation by corrupted privacy, partial non benchmark reliable channels nodes custodiality threshold trust in distributed key custody unauthorized recovery requires safety, liveness, prototype, servers plus trusted hardware compromise of authentication factors and availability, usability benchmark, authenticator; client compromise enough servers; replay addressed; broader simulation assumptions not stated endpoint/coercion model not stated HSM-rooted institutional trust; external physical and side-channel attacks on HSM, safety; liveness; no evaluation cryptanalytic attacks on wrapped seeds, availability; privacy; storage must preserve wrapped-seed availability/integrity; privileged operators network attacks, insider abuse, DoS, social accountability; constrained by organizational controls engineering, storage attacks, quantum revocability; usability threat trusted hardware wallet secure unauthorized recovery via ARC plus TK safety; liveness; prototype; environment; trusted smart account and compromise; DoS via stolen ARC availability; non benchmark registry logic; secure ARC storage; secure registration; replay; brute force; MEV; custodiality; revocability; and reliable passkey provider; secure GUI; intercepted on-chain data considered usability blockchain execution user must securely store KRC and secret; MEV/fronthardware wallet secure element and RNG running/reordering/censorship adversary; DoS via leaked KRC or random entries; trusted; registry and smart account contracts trusted for correct enforcement; brute force against 256-bit secret; replay after reveal; theft of one or both recovery blockchain may be adversarial but artifacts eventually processes transactions mixed cryptographic and incentive-based rational or malicious participants, false threshold model; no trusted nodes claimed uploads, withholding, and collusion; for escrow/recovery, but setup uses endpoint compromise and smart-contract administrator and multi-server generation bugs not explicitly modeled

safety; liveness; privacy; prototype; availability; non benchmark custodiality; accountability; robustness safety; liveness; availability; robustness; non custodiality; accountability

formal proof; simulation; benchmark; gas cost measurement

Deployment status prototype only

prototype only

conceptual design only; prototype and performance testing are future work prototype deployment on Ethereum Sepolia testnet, not stated as operational deployment prototype on Ethereum Sepolia testnet, not operational deployment

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

prototype-style smart-contract simulation only; no operational deployment stated

51

52

Study [99]

Trust model Adversary model threshold trust in subsecret-holding nodes silent, selfish, colluding, or plus smart-contract incentive enforcement false-share-providing nodes; broader and consortium-chain institutional trust unauthorized recovery model not stated

Security properties safety, liveness, availability, robustness, accountability, partial non custodiality

Validation type simulation, prototype, benchmark

[48]

user and cold wallet must protect root quantum adversary with ledger secret; hot wallet may be compromised; observation and hot-wallet compromise; cryptographic trust in lattice assumptions seed-compromise model not stated and QROM

safety, privacy

formal proof, prototype, benchmark

[59]

TTP and backup device are trusted to be theft of up to t-1 threshold secrets safety; liveness; prototype; available and provide correct recovery discussed; unauthorized recovery, helper availability; robustness; benchmark contributions; secure channels assumed collusion, and helper compromise not privacy explicitly modeled user plus external storage availability; attacker obtains stored backup artifact safety, availability, non prototype, and attempts unauthorized recovery by confidentiality relies on fuzzy extractor custodiality, usability benchmark assumptions and biometric device/sample guessing or spoofing biometrics; broader integrity compromise model not stated non-custodial user-held backup key; trust attacker steals classical secret key, forges safety; non custodiality; formal proof; in cryptographic assumptions and verifier signatures, may be quantum-capable, and privacy; limited usability; prototype; acceptance; no guardians or custodians may replay or clone non-interactive proofs post-quantum-oriented benchmark soundness claims trust in wallet software, Recovery Ledger unauthorized access and brute-force safety; availability; prototype; access control, and PoA ledger/validator guessing discussed; broader compromise usability simulation; infrastructure and insider model not stated benchmark elected controller node plus threshold of malicious controller, malicious safety; availability; prototype; participating nodes; blockchain publication participating nodes, collusion, liveness; robustness; benchmark; for verification; no fully specified impersonation, offline nodes accountability; limited simulation user-authentication step privacy claim

[71]

[94]

[85]

[10]

Deployment status conceptual design with simulation and prototype-like implementation clues; no operational deployment stated prototype-style implementation and lab benchmarking; no operational deployment stated prototype only

prototype only

prototype only

prototype-level lab evaluation only prototype only

SoK: Cryptographic Key Recovery for Financial Technologies

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

Study [33]

Trust model Adversary model single server with internal HSM; Lev-1 malicious server, file leakage, full server corruption, Lev-2 file leakage with server/HSM corruption, online guessing, trusted HSM core, Lev-3 full server/HSM offline guessing after leakage, corruption replay/rerouting/key-planting attacks

[93]

trusted operating terminal integrity, insider collusion, media theft/swapping, safety; liveness; prototype; case trusted physical KMF controls, threshold malware, side channels, transaction availability; study trust in treasurers, organizational tampering, MITM during KMF accountability; usability procedures duplication, malicious software exfiltration user-held primary and backup active network/protocol adversary and safety via recovery formal proof; authenticators plus server-stored recovery malicious server considered; quantum authentication; privacy security game; adversary motivates pq design; replay and via unlinkability; limited benchmark credential; authenticated registration unlinkability attacks modeled availability due to single channel and secure CTAP client-token backup token communication assumed assumption; partial non custodiality institutional and cloud-service trust; internal bad actors and operational misuse accountability, usability, prototype; case cloud-based SaaS in investigators, witnesses, supervisors, and explicitly mentioned; broader cloud and some operational study; operational use by at least one SaaS environment must be trusted key-misuse adversaries not stated availability; no formal deployment U.S. safety or privacy proof law-enforcement stated team; on-prem containerized version planned user-managed credentials plus trusted Pod spoofing, tampering, repudiation, safety, privacy, formal proof; prototype only server/Pod provider availability and access information disclosure, denial of service, availability, prototype control; no threshold or guardian model and elevation of privilege under STRIDE; accountability, usability, endpoint compromise and stolen-password non custodiality scenarios not stated self-managed user trust model with attacker targets online wallets or storage, safety, availability, non prototype, prototype only distributed storage locations; no guardians may compromise one server, guess split custodiality; limited benchmark or custodian count, storage locations, ordering, or usability discussion brute-force seed phrase

[92]

[50]

[34]

[9]

Security properties safety; privacy; availability; liveness; robustness; usability

Validation type formal proof; benchmark

Deployment status conceptual design with formal analysis and efficiency comparison; no operational deployment stated prototype mockup on Bitcoin Testnet; no operational deployment stated conceptual design with formal analysis; no full prototype deployment

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

53

54

Study [88]

[12]

[77]

[11]

[18]

Trust model Adversary model Security properties Validation type non-custodial client-side key derivation informal threats include credential stuffing, non custodiality; prototype; user with dependence on user devices, email offline brute force, custodial compromise, usability; liveness; study channel, TOTP app, and public parameter malware/browser compromise, seed phrase availability; partial safety storage; exact collusion threshold not exposure, and multi-device compromise; claims stated no formal adversary model rational profit-motivated adversary; some colluding compromised agents seeking safety; liveness; simulation; case non-collusion and distinct-provider profitable unauthorized recovery, draining, availability; robustness; study assumptions; smart-contract enforcement; blackmail/refusal, DoS, and front-running non custodiality; user responsiveness matters accountability; usability

user plus wallet provider and backup data one corrupted signing party in security safety; non custodiality; manager availability; provider stores experiments; wallet provider and backup privacy; availability; revocability; usability helper key but should not recover signing data manager alone or colluding should key unilaterally not recover or sign without user involvement user retains private key secrecy; keystore device compromise, keystore/HSM insider safety; non custodiality; assists recovery by storing/releasing factor attack, interception of recovery material, privacy; availability; table; trust in token, biometric liveness, biometric spoofing, side-channel leakage, robustness; usability and backup device availability physical coercion

formal proof; prototype; benchmark

fully trusted TA plus semi-honest external adversary may corrupt a small safety; privacy; committee with limited malicious members number of users or committee members to accountability; detectable obtain identity/private key, evade tracing, availability; liveness; or forge/impersonate robustness; reduced escrow style non custodiality claim; usability

formal proof; prototype; benchmark

prototype; benchmark

Deployment status prototype deployment in user study; no operational deployment stated conceptual analysis framework with PRISM model checking; no operational deployment evidenced prototype only

prototype-like lab evaluation only; operational deployment not stated prototype only, with future real-world validation stated

SoK: Cryptographic Key Recovery for Financial Technologies

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

Study [58]

Trust model Adversary model Security properties trusted third-party RSP with unauthorized recovery and transaction safety, liveness, bank/government-grade institutional trust; hijacking mentioned informally; malicious availability, non RSP availability required RSP, insider abuse, and impersonation not custodiality, usability stated

[60]

wallet owner, TTP share holder/auditor, and backup node must satisfy threshold assumptions; collusion assumptions not clearly stated

replay/reuse, tampering, revoked-key use, safety; availability; unauthorized device participation, robustness; phishing/wallet compromise; helper accountability; collusion not clearly modeled revocability; limited privacy

[20]

non-custodial user-controlled recovery anchored in smartphone app, mnemonic/password, smart contract, blockchain, and IPFS; strong OS security assumption

computationally bounded attacker; theft safety; privacy; availability; non of smartphone or mnemonic, custodiality; limited interception/tampering attempts, and key-linkage attacks are discussed; endpoint revocability; integrity compromise and coercion are largely absent

A.4

Privacy, Usability, and Limitations

Validation type prototype, benchmark

Deployment status prototype deployment on Bitcoin Testnet, not operational deployment prototype; prototype benchmark implementation and lab-style experiments; no operational deployment stated prototype; prototype deployed benchmark; gas on Sepolia with cost measurement IPFS test setup; no operational deployment stated

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 16 Master matrix, part C: trust, threats, and evidence. (continued)

Table 17 Master matrix, part D: privacy, usability, and limitations. Study

Privacy discussion

Usability evidence

[52]

OPRF hides password input, no evaluation but broader recovery-metadata privacy is not stated

[96]

limited; protects key confidentiality but no formal analysis of helper identity or recovery-attempt leakage

user study; survey or interview

Post-quantum relevance Not stated

Not stated

Main limitation

SoK relevance

reduced default verifiability weakens proof-backed server-assisted wallet robustness and server fault secret recovery using password identification; no empirical usability plus threshold servers or deployment evidence empirical evidence for offline social slow recovery with weak external validity and no revocation or formal secret-sharing recovery of private abuse model keys relevant to self-custody backup

55

56

Study [108]

[101]

[106]

[16]

[53]

Privacy discussion

Usability evidence

Post-quantum Main limitation SoK relevance relevance per-voter encrypted proofs, but no user study; claimed no Not stated vulnerable to social engineering, direct example of non-custodial public sos and unenforceable pre-loss setup, but user vote buying, and transaction-partner account recovery via asset transfer encryption create leakage risk must recall transaction manipulation, with no formal to a new account rather than details and recruit at security proof or user validation private-key reconstruction least five prior partners recovery improves but does not strong example of recovering limited; public on-chain no user study; only Not stated; this control by dynamic authorization challenge-response and possible performance, fee, gas, matters because the eliminate safety/availability on-chain encrypted and testnet paper’s security tradeoffs, and practical Bitcoin migration rather than authentication material, no demonstrations recovery is largely dependent on reconstructing lost keys assumptions are formal privacy treatment stated classical and the SoK TEE assistance while on-chain smart-contract proofs are costly tracks whether recovery paths depend on non-post-quantum signatures or hardware assumptions. informal attribute-based no user study Not stated reconstructs the full original private enterprise Bitcoin threshold key identity privacy only key at the owner and does not reconstruction with address loss, compromise recovery, attribute-gated share access; rotation, or revocation relevant as a governance-oriented recovery pattern rather than user loss recovery supporting wallet key-management no evaluation Not stated mostly analyzes attacker key yes; focuses on receiver unlinkability/anonymity, but recovery and wallet design tradeoffs paper for privacy, delegated notes later output merging can rather than legitimate user recovery monitoring, and compromise-resilient custody break privacy or post-compromise restoration design password and secret hidden no deployment or usability evidence, threshold password-only secret no evaluation Not stated and security relies on ROM plus recovery primitive transferable to from up to t corrupt servers; OMDH/T-OMDH assumptions wallet and key-backup recovery metadata leakage during recovery not stated

SoK: Cryptographic Key Recovery for Financial Technologies

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

Study

Privacy discussion

Usability evidence

[107]

Not stated

Not stated

[42]

claims blind wallet recovery so no user study; only server and helpers do not learn claimed usability plus master password or exact performance shares, but metadata leakage is measurements and not formally stated framework comparison forward unlinkability for no evaluation pre-breach keys; privacy can fail if chaincode or poorly chosen IDs reveal linkage

[19]

[98]

limited; focuses on not revealing password during recovery, broader metadata privacy not stated

[43]

limited; anonymous no user study communication hides backup source address, but broader recovery metadata leakage is not stated informal discussion of no user study anonymity leakage from direct off-chain communication; no formal privacy model stated

[69]

no user study

Post-quantum relevance Not stated

Main limitation

SoK relevance

Not stated

infrastructure-level share continuity dynamic committee-based recovery rather than explicit end-user of threshold key control for recovery, with blockchain custody under churn trusted-setup-dependent main path and weaker fallback threshold

no user-side key-loss recovery and provider-side wallet disaster no formalized backup integrity or recovery restoring multisig service adversary model in supplied state and practical signing evidence capability Not stated recovery depends on a central server direct cryptocurrency wallet and enough social helpers, under recovery via server-assisted social strong secure-environment threshold reconstruction of a assumptions and limited master key collusion/coercion analysis Not stated not a user-facing recovery protocol formal wallet-security framework and requires strong for compromise-resilient deterministic hot/cold wallets, synchronization/secure-erasure assumptions for forward useful as recovery-adjacent unlinkability custody analysis rather than direct recovery mentions quantum security and successful recovery direct blockchain private-key computing as a threat, depend heavily on memorized recovery for token accounts using but no post-quantum password secrecy, with no revocation password-protected threshold recovery design is or compromise-rotation workflow secret sharing provided Not stated no formal security model/proof, decentralized non-custodial wallet unclear collusion assumptions, and key recovery via threshold shares no discussion of biometric failure or and network-based path/share post-recovery rotation retrieval

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

57

58

Study

Privacy discussion

[3]

threshold hiding against up to f no evaluation Byzantine servers, but dealer secret may be exposed if dealer is proven dishonest

[47]

password hidden from servers; cloud data alone insufficient; broader privacy formalization not stated seed confidentiality in transit discussed; broader recovery privacy not stated

no user study

[90]

partial, not formalized

no user study

[72]

public template claimed hard benchmark only; to invert, but no formal privacy biometric required for evidence stated every signature; automatic transactions unsupported

[81]

Usability evidence

Post-quantum Main limitation SoK relevance relevance Not stated; the notes recovery is system-internal replica strong example of threshold share identify KZG and share repair, not end-user account or recovery for BFT financial Pedersen style wallet recovery, and no revocation infrastructure, but indirect for components but do or compromise-remediation consumer custody recovery not discuss workflow is stated post-quantum implications, which matters for long-term financial infrastructure planning. Not stated cryptographic robustness omitted, split-trust recovery-key with reliance on user reporting and reconstruction for self-custody recommender flagging wallet access recovery

no user study; only Not stated implementation flow and convenience claims Not stated

Not stated

no revocation or direct hardware-wallet seed compromise-response workflow after backup and recovery mechanism duplicating the same master seed for self-custody onto two wallets no substantive security or usability concrete wallet secret-key recovery evaluation and strong trust in the design using threshold escrow, transferable to financial wallet wallet endpoint recovery no support for automatic recovery-adjacent custody design transactions or smart contracts that regenerates signing keys from because biometric input is always biometrics instead of storing them required

SoK: Cryptographic Key Recovery for Financial Technologies

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

Study

Privacy discussion

[89]

no user study qualitative only; answers not stored or transferred in SSI workflow, but question-answer data may be guessable from public information hides assistant identities and no user study threshold via zk proofs, but metadata inference may require fake assistants/addresses

[17]

Usability evidence

[67]

anonymity claimed but not no user study formally defined; biometric privacy implications not stated

[13]

proof-of-ownership is not zero-knowledge; broader privacy leakage not stated

[79]

limited to confidentiality of no user study secret shares and password-protected values; no formal privacy definition public derivation leaks key no user study relationships and prevents unlinkability in that mode; alternative unlinkability mode discussed informally

[23]

no user study

Post-quantum relevance Not stated

Not stated; this matters because the scheme relies on conventional zk and elliptic-curve components whose long-term recovery security may change under quantum threats. Not stated

yes, uses hash-based fallback to address possible quantum break of ECDLP Not stated

Not stated

Main limitation

SoK relevance

security-usability tradeoff relies on low-entropy security-question answers and lacks formal security and usability validation

explicit reconstruction of the same blockchain private key via self-service partial-knowledge recovery

requires protocol/EVM privacy-preserving wallet recovery modifications and trusted off-chain by asset transfer rather than key assistant authentication, with weak reconstruction evidence on real-world usability

no empirical validation and direct private-key recovery incomplete treatment of biometric, mechanism for permissioned availability, and post-recovery financial blockchain accounts using operational issues verifiable threshold shares does not directly restore stolen wallet recovery by ownership proof funds and full fallback requires and fallback signing after key blockchain/protocol changes; base leakage rather than secret proof is one-time reconstruction no prototype or formal proof, and direct example of original no revocation or private-key reconstruction via compromise-recovery path is stated password protected secret sharing in blockchain recovery recovery depends on preserved seed direct example of deterministic or msk, and compromise of cold wallet key regeneration and storage is catastrophic with no organizational rekeying tradeoffs stated fallback for seed loss in financial wallets

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

59

60

Study

Privacy discussion

[91]

no evaluation local biometric verification shares only comparison result; encrypted bundles and threshold sharing reduce single-custodian exposure public blockchain transparency Not stated; paper is not Not stated enables extraction analysis; no a legitimate user formal privacy treatment recovery design

[62]

Usability evidence

Post-quantum relevance Not stated

[35]

Not stated beyond high-level no evaluation privacy/security motivation; no privacy formalization

Not stated

[87]

limited; confidentiality of seed no evaluation phrase discussed, broader metadata privacy not stated

Not stated

[76]

limited to keeping key hidden no direct usability during normal operation; evidence recovery privacy not formalized

Not stated; this matters because puzzle hardness assumptions and long-term recovery security may change under quantum-capable adversaries

Main limitation

SoK relevance

no formal security proof and incomplete treatment of cheating, biometric threats, auditability, and wallet-compromise assumptions

concrete wallet key recovery design reconstructing the original secret via threshold escrow with privacy-preserving authorization

not a legitimate recovery protocol attacker-centric evidence that and no mitigation or public signature artifacts can post-compromise recovery design is reveal wallet private keys under evaluated nonce misuse no formal security proof or explicit transferable threshold key malicious-provider/collusion model, reconstruction pattern for custody and no finance-specific recovery and backup, but only supporting scenario evidence rather than direct fintech evidence no formal security model or direct self-custody seed recovery empirical evaluation, and no mechanism that reconstructs the handling of both-location original wallet seed phrase from compromise or one-location two separated digital stores unavailability no concrete heart-beat puzzle institutional financial continuity construction, proof, or and outsourced operational key implementation; authorization and recovery requirements malicious-sysadmin handling remain unresolved

SoK: Cryptographic Key Recovery for Financial Technologies

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

Study

Privacy discussion

[66]

claims anonymous recovery no user study behavior, but no formal privacy definition or proof in evidence notes

[7]

yes; public on-chain questions, no user study; paper Not stated; this encrypted shares, and balances informally argues matters because the paper does not create linkage and targeting security questions are risks easier to remember than discuss whether its passwords cryptographic components remain suitable under post-quantum assumptions DZT aims to reveal only no user study Not stated success/failure, but broader on-chain metadata privacy is not stated

[8]

[65]

[54]

Usability evidence

no user study qualitative only; encrypted remote storage claimed private, but plaintext paper share and plaintext address storage create exposure per-transaction fresh keys no user study; only reduce linkability, but indirect evidence from cloud-stored stego image and framework comparison address book may leak and metadata; no formal privacy password/randomness analysis tests

Post-quantum relevance Not stated

Not stated

Not stated

Main limitation

SoK relevance

no prototype or empirical usability/deployment evidence; secure transmission and overhead left unresolved

Direct wallet private-key recovery mechanism for consortium blockchain using dual-threshold secret sharing with biometric-protected shares transferable smart-contract asset recovery depends on weak user-chosen security questions and recovery pattern that restores public on-chain data enables contract-level control without unlimited offline guessing; recovery recovering the original private key only covers contract-held assets

recovery restores fund control by policy-based smart-contract transfer to a fresh address rather recovery via control transfer after than reconstructing the original key, key loss, with concrete threshold and the unsigned recovery tradeoff and hardware-2FA variants is not deeply analyzed strong SGX trust assumptions plus direct wallet private-key recovery possible MITM and plaintext share mechanism for self-custody using exposure, with no formal evaluation TEE plus secret sharing shown recovery depends on stego image plus synchronized address-book state and lacks formal analysis of cloud compromise, tampering, and revocation

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

Bitcoin self-custody recovery design that reconstructs root secret and derived keys without daily backups

61

62

Study

Privacy discussion

Usability evidence

[104]

limited to secrecy against forbidden subsets; broader metadata/privacy not stated

no user study

[5]

yes, but informal and limited; no user study; claimed reveal and side channels can simplicity from no prior expose target and claimer links backup, but monitoring and long delays are required protects helper shares and no evaluation global secret during recovery, but broader metadata privacy is not stated

[61]

no empirical usability evidence

Post-quantum relevance Not stated

Not stated

Not stated; this matters because the protocol relies on discrete-log-based elliptic-curve assumptions Not stated

[4]

standard-signature indistinguishability stated; no formal privacy model for recovery metadata

[86]

yes; pictures may reveal private user study information and locations, and landmarks/faces may aid inference

Not stated

[68]

formal unlinkability of derived no user study verification keys and signatures; auditor with view key can see wallet activity but cannot spend

Not stated

Main limitation

SoK relevance

no realistic wallet integration or full direct private-key recovery adversary/lifecycle model, and exact mechanism for blockchain, but key recovery from noisy image mostly a transferable reconstruction is unclear secret-sharing construction rather than a deployed financial recovery system safety depends on timely owner reactive non-custodial recovery by challenge and strong anti-censorship delayed on-chain control transfer assumptions; no recovery for rather than secret reconstruction compromise cases no robustness or fairness, static-only direct threshold-share recovery for corruption model, and no revocation blockchain key management or rekeying after recovery

recovery can be blocked by malicious or DoS-targeted offline recovery party; no empirical deployment evidence

clear recovery-by-fallback-signing pattern for crypto-asset custody that restores signing capability rather than the original private key repository security/authentication is direct example of wallet original out of scope despite being central, private key recovery via and picture-based recovery leaks memory-based regeneration rather privacy and depends on than social, biometric, or autobiographical secrecy threshold methods recovery is only backup-based wallet supporting mechanism for reconstruction, with no social self-custody wallet recovery via recovery, threshold recovery, or root-secret reconstruction post-compromise combined with key-insulated rotation/revocation workflow compromise containment

SoK: Cryptographic Key Recovery for Financial Technologies

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

Study [44]

[84]

[80]

Privacy discussion

Usability evidence

Post-quantum relevance broad host-data extraction no validated user study; Not stated acknowledged, but no formal only aspirational claim of privacy model or minimization 2-hour triage by analysis relatively unskilled technician DNA biometric dependence is no user study; authors Not stated central, but storage, leakage, note biometric error rate and revocation of biometric may hinder practical use data are not stated

fingerprint template not stored no user study directly; encoded fingerprint with chaff points is encrypted, but broader metadata leakage is not stated yes; public identifiers, wallet no user study linkage, and login metadata may leak despite early privacy claims

Not stated

[70]

encrypted transaction storage no user study; only reduces account exposure, but prototype timing and on-chain activation can cost measurements deanonymize owner

Not stated

[49]

endpoint artifacts can reveal seed phrases, passwords, addresses, backups, and user activity

[73]

no evaluation

Not stated

Not stated

Main limitation

SoK relevance

recovery success is highly forensic seizure and adversarial state-dependent and often requires wallet-secret extraction evidence, live artefacts plus weak passwords; not end-user account recovery Ledger seed not recovered from examined host artefacts biometric error rate and direct private-key recovery underspecified practical deployment proposal for blockchain wallets, and authorization details useful as a biometric-assisted self-custody recovery pattern with major threat-model and validation gaps recovery depends on email access, hybrid wallet recovery combining fingerprint availability, and social helpers, biometrics, and threshold shareholder cooperation, smart-contract coordination for with no stated post-recovery self-custody key reconstruction revocation or compromise handling security and privacy depend heavily direct non-custodial wallet on underlying factors and recovery by re-deriving the same public-metadata handling, with no private key from threshold full usability or formal security multi-factor inputs evaluation activation authentication is weak direct example of self-custody and recovery depends on external recovery by asset migration rather services plus user retention of than key reconstruction backup key and emergency contract address relies on endpoint leakage and forensic recovery of wallet artifacts limited wallet classes; no formal enabling investigator access or security/privacy model seizure, not user-facing recovery

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

63

64

Study

Privacy discussion

Usability evidence

[55]

protects partial data from plaintext disclosure during validation and rebuilding; metadata privacy Not stated Not stated; no explicit privacy analysis of server metadata, recovery events, or wallet linkage

no end-user study; user must choose thresholds t and u

[57]

[51]

[78]

[102]

[41]

no evaluation

Post-quantum relevance Not stated

Not stated

Main limitation

SoK relevance

user recovery authorization and collusion threat model are underspecified in the supplied evidence strong trust/availability assumptions and lack of formal or empirical validation

direct wallet private-key recovery with proactive share repair and reliability analysis

Not stated narrow threat model and vague helper data should not reveal smartphone authentication around financial deployment assumptions, original biometric vector; 400 ms; biometrics especially around helper-data helper-data-only code integrity, spoofing/coercion, and generation probability reported positioned as easier than compromise recovery below 2^-300 and 2^-246 on PIN/token methods; no tested datasets user study claims encrypted no user study biometric encryption no formal threat model or proof, communication and is described as and guardian unlinkability between user and post-quantum in identity-proof/biometric security guardians, but no formal passing, but no details are underspecified privacy analysis stated broader post-quantum recovery analysis is stated commitment hiding claimed; no user study Not stated not a direct end-user financial broader metadata privacy not recovery workflow and relies on stated strong setup and coordination assumptions limited; NIZK used but no one hardware-token Not stated no explicit treatment of explicit privacy formalization operation claimed; hardware-token loss, client benchmark latency compromise, or post-recovery reported; no user study revocation/rotation

mobile wallet recovery architecture that reconstructs lost mnemonic shares using Shamir sharing, SIM-based 2FA, and server-assisted backup direct example of biometric key regeneration for blockchain key-loss recovery without third-party custody

clear example of smart-contract-assisted social recovery that restores asset control by reconstructing a separate recovery key rather than the original wallet key transferable dynamic committee and proactive refresh pattern for private-key recoverability direct wallet private-key recovery via threshold server-held shares after MFA

SoK: Cryptographic Key Recovery for Financial Technologies

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

Study [100]

[21]

[22]

[103]

[99]

Privacy discussion

Usability evidence

Post-quantum Main limitation SoK relevance relevance purpose-specific and no user study; usability future work mentions recovery authorization and transferable HSM-assisted pseudonymous keys reduce is asserted via single exploring root-of-trust disaster recovery are deterministic root-secret recovery linkability, but recovery-process master-seed backup post-quantum underspecified, and there is no pattern for managed identity and privacy is not formalized cryptographic direct validation financial key infrastructures algorithms claims no secret information no user study; usability Not stated security depends on ARC storage clear example of account-control revealed to contract, but no argued from passkey and passkey/TK security; if ARC recovery for hardware-wallet users formal privacy model familiarity and two-step and TK are both compromised after without seed reconstruction, using registration, attacker can transfer passkey authorization and recovery flow ownership smart-contract owner transfer recovers account ownership rather clear example of non-backup heuristic only; hash obfuscation no user study; usability Not stated and address rotation aim to claims only than the original seed/private key, hardware-wallet recovery via reduce linkage, but no formal and relies on strong user on-chain ownership transfer rather artifact-storage and than secret reconstruction privacy analysis stated timing-management assumptions without formal security or usability validation Not stated; no formal privacy no evaluation Not stated mixed and partly vague trust direct wallet private-key escrow analysis of participant or assumptions plus no explicit privacy and recovery mechanism for public recovery metadata leakage or compromise model blockchains with threshold reconstruction and incentive design Not stated; no explicit privacy no evaluation Not stated no explicit privacy or compromise direct example of model for share metadata or model and no post-recovery key consortium-chain wallet original recovery visibility rotation or re-sharing procedure private key recovery via threshold stated secret reconstruction with incentive-based liveness support

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

65

66

Study [48]

[59]

[71]

[94]

[85]

Privacy discussion

Usability evidence

Post-quantum relevance formal unlinkability of session no user study yes; lattice-based public keys; randomized basis construction with hides information about QROM proofs original secret basis targeting post-quantum wallet security limited for recovery workflow; no user study not post-quantum broader SSI privacy claims plus secure; authors note masking to hide helper shares future from user lattice/quantum direction helper data claimed public no user study; prototype Not stated under fuzzy extractor reports about 200 ms assumptions; biometric encryption/decryption information is the main secret; and successful recovery formal privacy analysis not after 6 months stated zero-knowledge for backup key, simplified single backup explicit; proof and but no formal privacy key for multiple wallets fallback-signing treatment of published x,y or is argued, but no user direction target replay/linkability study post-quantum ownership continuity, but fallback QROM proof is missing limited informal discussion benchmark only; no user Not stated only; no formal privacy analysis study of ledger-stored seed phrases

Main limitation

SoK relevance

larger signature and transaction size seed-based wallet key restoration due to trapdoor quality degradation in a post-quantum hot/cold from lattice basis delegation self-custody design, but not a full compromise-remediation or social recovery system strong helper trust and availability assumptions with no explicit collusion or unauthorized-recovery analysis

concrete DID wallet share-recovery protocol that restores threshold signing participation without changing public key

informal security analysis with no stated revocation or compromise-recovery path for biometric leakage

direct wallet mnemonic backup and recovery mechanism using biometric-derived decryption of externally stored backup artifacts

not true key recovery; unresolved clone attack; incomplete practical revocation and fallback-signature proof

recovery-adjacent mechanism for restoring wallet ownership and migration after key compromise

vague authorization and incomplete concrete wallet recovery design threat/privacy analysis for storing restoring seed-based wallet access, seed phrases in a Recovery Ledger but with limited validation and underspecified trust assumptions

SoK: Cryptographic Key Recovery for Financial Technologies

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

Study

Privacy discussion

[10]

no evaluation identity IDs and blockchain-published verification may expose participant and recovery metadata; privacy not formally analyzed prevents password-equality no user study testing across honest users; no full privacy formalization stated in evidence

[33]

[93]

[92]

[50]

[34]

Usability evidence

Post-quantum relevance Not stated

Main limitation

SoK relevance

no formal security proof and no clear recovery authorization or compromise-handling model

direct private-key recovery mechanism transferable to blockchain wallet recovery, but not tied to a concrete financial deployment

efficient quantum-safe strongest security depends on transferable password-based key OPRF remains open advanced OPRF-based design and recovery pattern for hardware-backed wallet or custody strong HSM/attestation assumptions; simpler variants fail recovery architectures under full HSM compromise qualitative only; CCTV, prototype timing only; Not stated strong trusted-terminal assumption institutional custody recovery case study showing backup, threshold memo/tag tracking, and KeyGen time-consuming and mostly qualitative security physical observation can leak and Sign initially over 1 validation reconstruction, disaster recovery, and rekeying tradeoffs sensitive information hour then about 30 minutes clear example of recovering yes, central focus on no user study yes, proposes pqCBR no full implementation or user account access by unlinkability and server-side using Kyber-based evaluation, single-backup-token account-linkage risks components and model, and no explicit post-recovery backup-authenticator-based post-quantum revocation/audit workflow in the credential rotation rather than key-blinding evidence reconstructing the original lost signatures secret sensitive key material handling prototype UI and Not stated no formal threat/privacy model and forensic recovery of wallet artifacts acknowledged, but no formal workflow plus limited validation beyond narrow and selective asset recovery from privacy model for cloud time-saving case studies; case studies; cloud deployment may seized evidence, not end-user processing or seized data no user study be unacceptable for some agencies wallet recovery exposure encrypted backup and Solid no user study Not stated single point of failure at the Pod backup-based restoration of SSI access control are discussed, server and explicit failure to provide wallet contents and related keys restore during DoS after device loss; useful but privacy is not formally transferable pattern but not direct defined beyond secrecy/access cryptoasset custody recovery restriction

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

67

68

Study

Privacy discussion

[9]

limited; no formal analysis of no user study; only storage metadata, locations, or operational burden ordering leakage discussed and runtime benchmarks reported

[88]

limited; no formal privacy analysis stated

[12]

privacy largely out of scope; no no user study; usability privacy formalization evidenced discussed analytically through complexity, parameter choice, and response burden helper key should not reveal no user study signing key or biometric information, but broader metadata leakage is not stated

[77]

Usability evidence

user study

Post-quantum relevance Not stated

Not stated

Not stated

Not stated

[11]

template-less biometric claims, benchmark timings and but recovery-metadata and FRR/FAR experiments; helper-exposure privacy are not no user study fully stated

uses CRYSTALS Dilithium / ML-DSA44 in implementation context

[18]

conditional anonymity with TA no user study; only Not stated traceability; committee does design claims about not learn real identity at join identity-based addressing time; flow-analysis and and re-registration network-layer privacy are out of recovery scope

Main limitation user must store decryption keys for all parts; initial seed generation/download remains vulnerable

SoK relevance

concrete self-custody seed backup and reconstruction mechanism, but with underspecified authorization and limited security/usability evaluation strong usability evidence but direct wallet recovery mechanism incomplete formal security, privacy, showing factor-based restoration of and post-recovery lifecycle wallet access without custodial key specification storage rational-adversary and strong for analyzing composition static-parameter model with no of wallet recovery paths and real-world attack-data or distinguishing secret deployment validation reconstruction from account-control recovery security theorem is limited to wallet recovery restores signing single-key registration, while authority via helper-key backup/inheritance create multiple regeneration rather than related helper keys original-key reconstruction, with important provider-trust and biometric tradeoffs recovery depends on keystore release concrete same-key wallet recovery of factor material and uses an mechanism after factor loss, with acknowledged weak XOR keystore-assisted MFA composition with no formal proof in reconstruction rather than supplied evidence provider custody or account transfer strong trust in TA and incomplete regulated payment-system treatment of real-world privacy, private-key recovery via compromise abuse, and deployment identity-based reissuance, combining recovery with anonymity and traceability

SoK: Cryptographic Key Recovery for Financial Technologies

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

Study

Privacy discussion

[58]

identity-linked registration required; no formal privacy analysis metadata-only audit claimed, no user study; only but TTP still learns hashes, automation claims and timestamps, RP identifiers, and latency benchmarks device cluster IDs

[60]

[20]

Usability evidence

Post-quantum relevance benchmark only; no user Not stated study

yes; focuses on unlinkability via prototype UI and fresh hardened per-dApp keys, runtime benchmarks but no formal privacy proof only; no user study and limited metadata-leakage discussion

Not stated

Not stated

Main limitation

SoK relevance

reliance on trusted third-party RSP core example of asset recovery by and incomplete handling of stale pre-signed transfer rather than key UTXOs/fee drift reconstruction recovery semantics and collusion transferable threshold recovery assumptions are unclear; evidence and audit pattern for DID-linked shows threshold signing continuity financial access, but not an more clearly than full secret explicit asset-custody paper restoration recovery still depends on retained concrete non-custodial wallet mnemonic plus password and strong recovery design combining endpoint-security assumptions; no deterministic root regeneration, clear compromise-recovery or encrypted decentralized backup, post-recovery revocation model and smart-contract-mediated device management

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 17 Master matrix, part D: privacy, usability, and limitations. (continued)

69

70

SoK: Cryptographic Key Recovery for Financial Technologies

B

Seven-Stage Recovery Walkthroughs

Table 18 applies the construction model from Section 8 to four representative retained systems. The examples were selected to cover the main recovery promises requested by the model: threshold secret reconstruction, smart-account or access-structure control transfer, biometric/seed restoration, and institutional custody recovery. The comparison shows that the same seven stages produce different post-recovery obligations depending on whether the design restores the old secret, migrates control, regenerates seed material, or restores operational custody.

System and axis 1. Control material Original wallet PPSS wallet private key or backup [52]; secret-restoring wallet-control secret threshold recovery

2. Enrollment

3. Storage and 4. Failure trigger 5. Authorization 6. Recovery governance and checks action The user protects Server-held Local secret The claimant proves The same the secret with protected material availability is lost password knowledge wallet secret is passwordplus user password; while the user to enough servers reconstructed protected secret security assumes still remembers through the recovery for continued sharing across bounded server the password protocol use recovery servers compromise and authenticated setup

Governance is Signing Parties define A signer, authority, recovery or encoded in custodian, or account control, migration rules contracts, proofs, access-structure or asset-control before paralysis, participants, and participant sometimes trusted becomes relation under including challengeexecution; public unavailable or a dynamic access structure response, state can expose refuses service failed-test, or recovery activity TEE-assisted paths Wallet The user enrolls Recovery depends The mnemonic Leakable mnemonic phrase mnemonic or on biometric biometricphrase is lost [71]; seed-equivalent derived helper recapture, helper biometric/seed backup artifact data and stores data, external secret restoration encrypted backup availability, mnemonic and any optional recovery material second-factor gate Paralysis proofs [101]; control-restoring access-structure transfer

7. Post-recovery hygiene gap If loss might also imply compromise, the paper leaves rotation, fund migration, stale server records, and recovery-attempt metadata handling mostly outside the core protocol A migration rule is Control moves The new signer set, satisfied by timeout, to a new access dispute window, failed-test evidence, structure rather failed participant Merkle proof, than status, audit trail, on-chain challenge, reconstructing and old recovery path or TEE-signed the failed need cleanup; the old transition party’s key secret may remain lost or compromised

A fresh biometric sample reproduces the decryption material through a fuzzy-extractorstyle process; optional 2FA may gate helper-data download

F. J. Becerra Sanchez, A. K. Iannillo, and R. State

Table 18 Representative systems walked through the seven-stage construction model.

The mnemonic Restoring the same or seed leaves open seed-equivalent whether to rotate material funds, replace helper becomes data, revoke leaked available again biometric-derived material, or recover after biometric compromise

71

72

System and axis 1. Control material Custodian key Private keys, management [93]; key shares, institutional signing hybrid recovery authority, and asset-transfer capability in a custody operation

2. Enrollment

3. Storage and 4. Failure trigger 5. Authorization governance and checks Custodians Governance sits in Media failure, M-of-N treasurer create threshold institutional policy, key-management- approval and shares, backup trusted terminals, facility disaster, operational media, M-of-N approval, personnel change, procedures physical controls, threshold change, authorize procedures, treasurer roles, backup media, media loss or reconstruction, and logs, and theft, or rekeying, or signer disaster-recovery operational suspected restoration processes separation of compromise duties

6. Recovery 7. Post-recovery action hygiene gap The hygiene burden is Operational operational: rotate access is restored, shares keys or shares after suspected are reconstructed compromise, update or refreshed, personnel and thresholds, preserve and custody control may be audit evidence, and review rekeyed trusted-terminal and insider assumptions

SoK: Cryptographic Key Recovery for Financial Technologies

Table 18 Representative systems walked through the seven-stage construction model. (continued)

Related documents

• CBOR Object Signing and Encryption (COSE): Hash Algorithms#502494
• The Cryptogram: A Novel#44198
• Short Signatures from the Weil Pairing#6648
• ECMA-410 — NFC-SEC-03: NFC-SEC entity authentication and key agreement using asymmetric cryptography (June 2017)#600220
• Implementasi Algoritma Kriptografi Hybrid AES dan RSA dalam Rancang Bangun Aplikasi Bank Sampah Pancadaya Berbasis Web untuk Keamanan Data Transaksi Nasabah#1067025