Key management and recovery

From the white paper: section 5.2 describes a wallet restored from a recovery phrase and an encrypted backup, with no copy of the keys held by anyone at Civitas; this page explains why both parts are needed and what a second recovery route would take.

Keys are made on the device and stay there. The shipped wallet Live is non-custodial. At setup it generates a 24-word recovery phrase. The phrase derives the key that encrypts the wallet on the phone and unlocks the encrypted backup; the master secret that binds credentials to their holder and the keys behind the pairwise identifiers the wallet creates for each issuer and verifier relationship are random values kept inside that encrypted wallet. The phrase and the wallet key sit in the phone's secure storage (the iOS Keychain, or on Android a store encrypted under an Android Keystore key, hardware-backed on handsets that support it). Access is protected by a mandatory passcode, with fingerprint or face unlock as an opt-in convenience; that biometric only opens the local store on that phone and is unrelated to the biometric recovery route described below. There is no account, no email, no login password, and no server-side copy of any key. Nobody at Civitas can reset, replace or seize a holder's keys, and there is no custodian to subpoena or to breach.

The recovery unit is the phrase plus the backup, both needed. Non-custodial design cuts both ways: no one can take the keys, and no one can hand them back. The built path Live works like this. The phrase unlocks an encrypted backup held in the holder's own cloud account, and the backup restores both the keys and the credentials. In the app in service the backup is off until the holder turns it on; the decided change to offer it after the first credential and on each new one is not built yet. A holder with the phrase and no backup restores an empty wallet: the phrase alone cannot regenerate the keys, which are random, or the credentials, which are signed artifacts issued by institutions, not values that can be recomputed. This is the standard pattern for self-sovereign wallets and needs no third party, but it places the burden of safekeeping a written phrase on the holder, which is a real cost for people who may lack secure physical storage.

Why credentials survive a new phone. A credential is issued to the holder's cryptographic key, not to a handset. A restored wallet resumes its existing relationships, and the credentials it holds remain valid and can be presented again; the platform recognises the restored wallet by the same device identity, which it uses to detect cloned installations. Recovery restores access; on the rail in service it does not require re-issuance. Where the backup is missing, re-issuance by the original issuers is the fallback, which is why keeping re-issuance cheap belongs to the same problem.

A researched second route: a key derived from a biometric. For holders who cannot safely manage a written phrase, Civitas is evaluating biometric key derivation Research: no shipped code. The technique, known as fuzzy extraction, derives a key pair directly from a biometric such as a fingerprint at enrollment, then immediately discards both the biometric input and the private key. Nothing biometric is stored anywhere: no template, no central database, no honeypot. On recovery the holder presents the same biometric, the algorithm re-derives the same key, and that key unlocks the encrypted backup. The constraints that keep it out of the near-term plan:

• It changes onboarding, not only recovery: the biometric must be enrolled at wallet setup, for every user, including those who will never need it and those for whom biometric capture is itself a reason for distrust.
• Re-derivation has a non-zero false-reject rate, and the rate that matters is on low-cost handsets in field conditions, which no published study covers. A pilot has to measure it, alongside the cost of a failed recovery against simple re-issuance.
• The one mature implementation is proprietary and patented, with no public software development kit, so it could only ever ship as an optional add-on behind a vendor-neutral interface, never inside the open-source core, and it would need independent security review.
• The recovery phrase stays as the fallback, and the flow must degrade to the phrase path whenever the component or the backup is unavailable.

Other directions are being weighed against it: a passkey-based signer, recovery through a quorum of trusted contacts or institutions, and re-issuance kept cheap enough to be a genuine alternative.

Status, 2026-10-01: recovery from the 24-word phrase plus the encrypted backup runs in the shipped iOS and Android wallet, and the backup is off until the holder turns it on; no biometric recovery code exists.