Skip to content
Anastasis

How it works

How Anastasis works.

Start with the plain-language version. Each section below goes one level deeper, so an executive and a cryptographic engineer can read the same page and both come away with what they needed.

01

Overview

A user has something they cannot afford to lose: a wallet key, an identity credential, an encryption key. Anastasis lets them arrange, in advance, a way to get it back.

That arrangement is a recovery policy: a description of which independent providers and which authentication steps have to cooperate before the secret can be reconstructed. The secret itself is never handed to any of them.

Later, if the original copy is gone, the user proves who they are according to that policy. Enough providers release their part of the recovery material, and the secret is rebuilt on the user's device.

02

Protection process

Protection happens entirely on the user's device. The secret is encrypted locally, and the material required to reconstruct it is split so that individual pieces are not useful on their own.

Each piece is bound to an authentication challenge — the condition a provider will later require before releasing it. The user chooses the combination; the software makes the consequences of that choice explicit before it is committed.

  1. 01

    Encrypt locally

    The secret is encrypted on the device; no plaintext leaves it.

  2. 02

    Split

    Recovery material is divided so single pieces are not sufficient.

  3. 03

    Bind to challenges

    Each piece is associated with the authentication a provider will require.

03

Recovery providers

A recovery provider stores encrypted recovery material and enforces the authentication challenge attached to it. It is a deliberately unglamorous role: providers do not hold secrets, do not make policy decisions, and are not trusted individually.

Providers can be operated by different organisations — a wallet vendor, a bank, a notary, a public institution, a neutral operator in another jurisdiction. The practical strength of a deployment comes from that independence.

Providers can be added or replaced over time, and a policy can include more providers than are strictly required so that one going offline does not end recovery.

04

Recovery policies

A recovery policy states what it takes to recover: which providers, which authentication methods, and how many of them must succeed together.

Policies can express organisational reality rather than only cryptographic convenience — two officers from different business units, a customer plus their bank, a device attestation plus a postal challenge.

Several alternative policies can protect the same secret, so that losing one route does not mean losing access.

05

Recovery process

Recovery begins with the user's client discovering which policies apply. The user picks a route that is realistic for them today — the phone number they still control, the colleague who is still with the organisation.

The client then satisfies each challenge with the relevant provider. Providers release their material independently; they do not coordinate with each other.

Once enough material is collected, the secret is reconstructed locally. At no point does a provider, or the network between them, see the reconstructed secret.

06

Privacy model

The protocol is designed to minimise what a provider learns. A provider sees that some party satisfied a challenge it was configured to enforce, and releases material it cannot interpret.

What a provider should not learn: the protected secret, the contents of the wider policy, or which other providers are involved. What a provider necessarily does handle is the authentication channel it was asked to operate — an email address or a phone number, for example — and deployments should treat that as personal data.

These are design goals expressed in the protocol documentation, and they are the right things for a reviewer to test rather than take on trust.

07

Integration architecture

Anastasis is a layer, not an application. It is integrated into the product that already holds the key.

User clientholds the secretRecovery provider 1partial material onlyRecovery provider 2partial material onlyRecovery provider 3partial material onlyNO CENTRAL STORE OF THE PROTECTED SECRET
The integrating client speaks to each provider separately; providers hold only partial material.

  • Wallets

    Recovery is offered inside the wallet's own onboarding and settings flows, using the wallet's existing identity signals.

  • Fintech applications

    Recovery policies can involve the institution itself as one provider among several, without making it the custodian.

  • Identity systems

    Issuers can reuse their assurance processes as authentication steps in the recovery policy.

  • Enterprise applications

    Key recovery is mapped onto existing separation-of-duty and audit requirements.

Read the protocol documentation

Review the threat model next.

The security page sets out what the architecture is designed to withstand, and where careful deployment decisions still matter.

Security architectureTalk to us