Social Recovery
Shamir social recovery
Split a backup key across trusted guardians with Shamir’s Secret Sharing, then reconstruct a quorum to recover. No servers, no network.
Last updated Jul 2026
Shared Backup · split your Master Key
Overview
A proof-of-concept Shamir Secret Sharing layer for backup and inheritance on Passport Prime. It splits a master seed into N shards with a T-of-N recovery threshold, distributes them to trusted guardians (keycard / NFC / QR), and reconstructs the seed from any quorum, with no network calls and nothing written outside the app.
It composes existing KeyOS primitives (bc-shamir, the Magic Backups shard format and restore pipeline) rather than inventing new crypto, so it integrates into KeyOS 1.3.0 with zero upstream API changes. The cryptographic core (social-recovery-core) is production-grade and covered by 11 unit tests; the Slint UI is a navigable scaffold covering every MVP flow.
What it does
- Parametric Shamir split/reconstruct over bc-shamir, the same crate KeyOS uses for Magic Backups.
- Tests cover 3-of-5 roundtrips, every threshold subset, below-threshold rejection, and cross-set contamination.
- BackupKey derivation pinned to the canonical SHA256(seed ‖ "backup_encryption") used by KeyOS backup.
- Shards reuse the existing backup-shard format (device_id, timestamp, scheme): multi-set support is free.
- Trustee flow: ingest a guardian’s shard, validate set membership, and reject Magic-Backup shards.
- No network I/O, no server calls, no persistence outside the app directory.
- Heir recovery reconstructs the seed locally and bridges into the existing Magic Backups restore.
Technical breakdown
How the proof-of-concept is built, for developers evaluating the platform.
The core crypto crate
social-recovery-core wraps bc-shamir’s split_secret/recover with validated parameters (N 2–255, T 2–N) and returns Magic-Backup-format shards. derive_backup_key() pins to SHA256(seed ‖ "backup_encryption"), bit-for-bit matching KeyOS os/backup. Its unit tests prove roundtrips, every threshold subset, below-threshold rejection, cross-set contamination detection, and key-derivation stability.
No trust in servers
The master seed is read only from device security state. Shards export to keycard / NFC / QR and are reconstructed locally; verification runs in-process without changing device state. There is no server-side set registry: each shard embeds enough metadata (device_id, timestamp) to group its set, and no network is ever touched.
KeyOS integration
Target is KeyOS 1.3.0. The core crate drops into os/gui-app-social-recovery/ (or apps/gui-app-social-recovery/ as a first-party catalog app) unchanged; the UI crate mirrors os/gui-app-launcher and swaps slint → slint-keyos-platform at integration. All required permissions (os/security, os/keycard, os/backup) already exist. Recovery is security.set_seed → backup.restore_backup, with no new KeyOS APIs.
Dig into the source
README, architecture notes, and the wire protocol live in the repo.