Files

T

julian 9e442586af docs(wiki): settle on-site encrypted backup + disaster-recovery design

New concept page backup-recovery.md resolving the design half of open-question #5.
Driving scenario: a stolen/destroyed PC whose LUKS+TPM disk is unrecoverable by
design — recovery stands up a NEW PC, restores a backup, and keeps signing the
SAME chain.

Settled: admin-driven encrypted full-DB backup (SQLite online-backup/VACUUM INTO,
snapshots included) to local/USB, SMB/NFS, or SFTP targets; manual button + an
in-process daily timer; keep-last-N + dailies retention; restore is admin-only /
out-of-band (operator-adversary surface). A restored copy must still verifyChain.

Key custody (the load-bearing decision, bears on #6): three independent keys —
EVENT_SIGNING_KEY kept an extractable, escrowed software key DECOUPLED from the
TPM so the ledger survives total hardware loss (the conscious trade: a TPM-sealed
signing key would be unforgeable but permanently unverifiable after the machine
dies); a NEW dedicated park_buzi_backup_key in Komodo for backup encryption,
separate from the signing key; the LUKS/TPM disk key, appliance-only and
deliberately non-recoverable. Keys are never inside the backup they unlock.

Updated open-questions #5 (design SETTLED) + #10 note; disk-os-hardening deploy
runbook (why the signing key is not sealed + park_buzi_backup_key); index catalog
+ concept count. Design only — not yet built.

Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V

2026-06-29 11:43:23 +02:00

4.0 KiB

Raw Blame History

type, tags, sources, updated

type

Disk / OS Hardening

Worthwhile, but not the main event — it defends against the outsider-with-physical-access, not the operator (see threat-model). (See parking-system-architecture §3.)

Physical-access attacks on Windows are trivial (boot media + password-reset tools), so a dedicated Linux machine is the correct platform — not Windows or WSL. This is a standing-decisions.

LUKS full-disk encryption — defeats boot-from-USB.
GRUB password + Secure Boot — prevents boot-parameter tampering / unsigned loaders.
No desktop environment — single-purpose appliance.
Key-based SSH only.
tpm (recommended, 2026-06-21) — seals the LUKS key to the boot chain so the disk auto-unlocks only on an untampered boot, making encryption-at-rest compatible with unattended reboot (a booth must come back up after a power cut without a human typing a passphrase). Also a candidate home for the non-extractable host event-signing key. Caveats (live-root limit, bus-sniff, PCR brittleness, mandatory recovery passphrase + re-seal runbook) on tpm; implementation is open-questions #12.

With LUKS in place, SQLCipher becomes optional defence-in-depth rather than the critical layer. (The custom controller adds its own: ESP32 flash encryption + secure boot — see esp32-custom-controller.)

Step-by-step OS install + TPM-seal procedure (BIOS → encrypted install → manual PCR-7 TPM seal, with the Dell-7070-specific dbt workaround) lives in appliance-provisioning — written from the first real provisioning (2026-06-23) and verified on hardware. OS hardening on the first unit is COMPLETE: LUKS FDE + TPM auto-unlock (PCR 7, unattended) + Secure Boot (Deployed) + GRUB edit-lock (the GRUB password is the specific countermeasure to the init=/bin/bash root-shell hole that PCR-7 sealing does NOT cover). Resolves the implementation half of open-questions #12 for unit 1.

Deploy-time server configuration (runbook)

Env in apps/server/.env on the appliance (see apps/server/.env.example). The security-load-bearing ones:

JWT_SECRET — ≥32 random chars; the server refuses to boot without a strong one (no insecure default). openssl rand -hex 32. See local-jwt-auth.
EVENT_SIGNING_KEY — dedicated HMAC key for the signed ledger; ≥16 chars. Falls back to JWT_SECRET with a warning if unset — set a dedicated one before production. Deliberately kept an extractable, escrowed software key (NOT TPM-sealed) so the ledger survives total hardware loss — see backup-recovery for the custody trade vs. open-questions #6.
park_buzi_backup_key (planned) — dedicated key for encrypting backup-recovery, separate from EVENT_SIGNING_KEY (independent rotation; backups travel, the signing key shouldn't). Both escrowed offsite in fleet-deployment-komodo; recovery needs both, held out-of-band.
COOKIE_SECURE=0 — REQUIRED on the plain-HTTP LAN appliance. Auth/CSRF cookies are Secure by default (fail-safe). The appliance serves the SPA same-origin over plain http on the booth LAN, where a Secure cookie is never sent — so without this opt-out operators cannot log in. Set it deliberately. (A TLS/reverse-proxied deploy leaves it UNSET so cookies stay Secure.) This replaced the old NODE_ENV=production gate, which silently dropped Secure if the var was forgotten. See local-jwt-auth.

The plain-http booth LAN is acceptable because it's an isolated, single-purpose network (the only browser is the booth's own; access controllers sit on a separate VLAN — see network-isolation, trust-boundary). Secure-off is a network-scoped decision, not a blanket weakening; the JWT stays HttpOnly + SameSite=Strict and CSRF double-submit still applies.

4.0 KiB Raw Blame History

Disk / OS Hardening

Deploy-time server configuration (runbook)

4.0 KiB

Raw Blame History