Threat Model

Threat Model

This page explains what risks Ethernity is designed to handle, and what you still need to handle with good operational practice.

It is written for both users and maintainers.

One-Minute Summary

• Ethernity is strong at detecting corruption and mixed backup inputs.
• It helps with offline recovery and optional quorum-based custody.
• It cannot protect you from every risk (for example, a fully compromised endpoint).
• You still need drills, separation of storage, and release verification discipline.

If you are a regular user, read this page once and then follow Security and Trust Model for daily practice.

Security Goals

Main goals:

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

Additional goals:

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

Assets to Protect

• Backup payload plaintext.
• Passphrase material.
• 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.

Each boundary can fail in different ways, so controls should be layered.

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 your custody policy.
• Hardware/firmware implant-level attacks.

In short: some risks can only be managed by endpoint hardening and operational policy.

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	What can happen	Built-in controls	What you still need to do
Corrupted QR/fallback data	Restore fails or output is wrong	strict parsing, hash checks, conflict checks	collect clean inputs again
Mixed files from different backups	Rebuild fails	doc-id/hash consistency checks	keep one backup set per recovery run
Missing artifacts	Recovery may be impossible	fallback mode + optional sharding	keep custody and retention policy tight
Full-set substitution	You may trust the wrong set	internal checks still run	use external trust anchors in high-assurance workflows
Release artifact tampering	Running malicious binary	Sigstore-based verification guidance	always verify before execution
Using kit while online	extra exposure risk	online warning in kit	prefer offline and controlled environments

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 quick 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 happens:

• 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