Threat Model

Threat Model

This page documents the practical threat model for Ethernity stable v1, including assumptions, attack surfaces, controls, and residual risks.

It is written for both operators and maintainers.

Security Goals

Primary goals:

• Preserve confidentiality of backed-up payloads.
• Detect corruption and cross-set mixing during recovery.
• Preserve operational recoverability from printed and offline artifacts.

Secondary goals:

• Provide cryptographic provenance checks for release artifacts.
• Support high-assurance workflows through external trust policy.

Assets to Protect

• Backup payload plaintext.
• Passphrase material (including generated mnemonic passphrases).
• Shard documents (passphrase shards and signing-key shards).
• Recovery artifacts (qr_document.pdf, recovery_document.pdf, optional shard PDFs).
• Signing public key trust expectations in high-assurance workflows.

Trust Boundaries

1. Producer boundary: machine generating backups.
2. Artifact custody boundary: storage/transport of printed and digital artifacts.
3. Recovery boundary: machine/browser used for reconstruction/decryption.
4. Release boundary: downloaded binaries and provenance verification.

Crossing any boundary changes attacker opportunities.

Assumptions

• Cryptographic primitives and dependencies behave as expected.
• Operators can maintain at least one independent backup path.
• Recovery drills are periodically executed.
• In high-assurance contexts, trust anchors are managed out-of-band.

Out of Scope

• Compromised endpoint with full runtime control at backup/recovery time.
• Coercion/insider threats beyond documented custody controls.
• Hardware/firmware implant-level attacks.

Adversary Profiles

• Accidental operator error: wrong files, mixed documents, partial scans.
• Opportunistic tampering: modifies or replaces subset of artifacts.
• Full-set substitution attacker: replaces entire artifact set with coherent forged set.
• Supply-chain attacker: attempts to deliver modified release artifacts.

Attack Surface Overview

• CLI inputs (scan dirs, payload files, fallback text, shard/auth files).
• Browser recovery kit parsing and state handling.
• Artifact custody and transport channels.
• Release download and update channels.

Threats and Controls

Threat	Typical impact	Built-in controls	Residual risk
Corrupted QR/fallback data	Recovery failure or wrong output	strict framing/decoder validation, hash checks, dedupe/conflict checks	operator must re-collect clean inputs
Mixed artifacts from different backups	invalid reconstruction	doc id/hash consistency checks, parser bounds, shard consistency checks	operator workflow mistakes still possible
Partial artifact loss	inability to recover	fallback path + optional threshold sharding	if below threshold, recovery unavailable
Full artifact-set substitution	false confidence in foreign set	internal consistency/signature checks	requires external trust anchor for strong identity assurance
Release artifact tampering	malicious binary execution	Sigstore bundle verification, release runbook checks	skipped verification by operator
Online browser environment during kit usage	telemetry/exfiltration exposure	offline warnings and operator guidance	warning is advisory; network state is not a hard guarantee

Trust Modes for Recovery

Self-contained trust

• Verification is rooted in the artifact set itself.
• Strong for integrity/consistency.
• Weaker for identity when artifact provenance is untrusted.

Externally anchored trust

• Verification is additionally tied to an out-of-band trust anchor (policy-managed signer identity).
• Stronger against full-set substitution.
• Higher operational burden.

See Security and Trust Model for concise operator guidance.

Operational Controls (Recommended)

• Keep primary, fallback, and shard artifacts in separate custody paths.
• Run scheduled recovery drills (for example quarterly).
• Treat rescue/bypass controls as incident-only procedures.
• Verify release artifacts before execution.
• For high-assurance operations, document and enforce external trust-anchor policy.

Residual Risks You Must Accept or Mitigate Externally

• Endpoint compromise at time of backup/recovery.
• Full artifact-set substitution without independent trust anchor.
• Human process errors in custody/rotation if runbooks are not followed.

Incident Response Triggers

Escalate and pause normal operations if any of the following occurs:

• unexpected signature/key mismatch in a high-assurance workflow
• repeated parser/conflict failures with previously known-good artifacts
• provenance verification failures for release binaries
• unexplained divergence between recovered output and trusted reference

Validation Checklist

• Recovery drill completed for each workflow type used in production.
• Artifact custody map documented.
• Release verification procedure documented and practiced.
• Trust mode policy documented (self-contained vs externally anchored).

Related

• Security and Trust Model
• Recovery Workflow
• Troubleshooting
• Maintainer Release Runbook
• Release Artifacts