The node's disk design splits the machine in two: an unencrypted 30GiB OS root and a LUKS2 data partition holding everything sensitive (wallets, identities, secrets, app volumes). The data volume auto-unlocks at boot via a keyfile that sits in plaintext on that unencrypted root (/etc/crypttab -> /root/.luks-archipelago.key), because the product must boot headless and unattended — no keyboard exists to answer a passphrase prompt, and a kiosk must come back by itself after a power cut.
Consequence (recorded in docs/1.8.0-RELEASE-HARDENING-PLAN.md §F): whole-box theft while powered off gets no protection — the key rides with the machine. Today the encryption protects the data disk (RMA, resale, disposal, drive-only theft, mounting the partition without the OS), not the machine.
Proposed Solution
Bind the LUKS key to a second factor per the hardening plan:
TPM2 sealing (preferred on hardware that has it — the x250 fleet does): key sealed to the motherboard; unlock requires the machine, not a typed secret; still headless/unattended.
Operator passphrase as the fallback / opt-in tier for hardware without TPM2 or for users who want power-off protection against even whole-box theft.
Likely a tiered or install-time choice given fleet heterogeneity (kiosk boxes, RPi images).
Known dependencies
The kdump design (docs/kdump-rasdaemon-design.md) deliberately dumps to the unencrypted root because the crash kernel must never handle key material — if root ever becomes encrypted, the dump target needs redesign (network dump or dedicated plain rescue area).
Must not break unattended reboot-survive (the lifecycle gate's cold-boot requirement).
Acceptance
Design doc: unlock strategy per hardware tier, recovery path (broken TPM / forgotten passphrase), migration for existing nodes
Implementation in installer + bootstrap backfill path
Lifecycle gate: cold boot still unattended on representative hardware
### Problem
The node's disk design splits the machine in two: an unencrypted 30GiB OS root and a LUKS2 data partition holding everything sensitive (wallets, identities, secrets, app volumes). The data volume auto-unlocks at boot via a keyfile that sits in plaintext on that unencrypted root (`/etc/crypttab` -> `/root/.luks-archipelago.key`), because the product must boot headless and unattended — no keyboard exists to answer a passphrase prompt, and a kiosk must come back by itself after a power cut.
Consequence (recorded in docs/1.8.0-RELEASE-HARDENING-PLAN.md §F): **whole-box theft while powered off gets no protection** — the key rides with the machine. Today the encryption protects the *data disk* (RMA, resale, disposal, drive-only theft, mounting the partition without the OS), not the *machine*.
### Proposed Solution
Bind the LUKS key to a second factor per the hardening plan:
- **TPM2 sealing** (preferred on hardware that has it — the x250 fleet does): key sealed to the motherboard; unlock requires the machine, not a typed secret; still headless/unattended.
- **Operator passphrase** as the fallback / opt-in tier for hardware without TPM2 or for users who want power-off protection against even whole-box theft.
- Likely a tiered or install-time choice given fleet heterogeneity (kiosk boxes, RPi images).
### Known dependencies
- The kdump design (docs/kdump-rasdaemon-design.md) deliberately dumps to the unencrypted root because the crash kernel must never handle key material — if root ever becomes encrypted, the dump target needs redesign (network dump or dedicated plain rescue area).
- Must not break unattended reboot-survive (the lifecycle gate's cold-boot requirement).
### Acceptance
- [ ] Design doc: unlock strategy per hardware tier, recovery path (broken TPM / forgotten passphrase), migration for existing nodes
- [ ] Implementation in installer + bootstrap backfill path
- [ ] Lifecycle gate: cold boot still unattended on representative hardware
chaum
added the roadmap label 2026-08-31 11:29:25 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
The node's disk design splits the machine in two: an unencrypted 30GiB OS root and a LUKS2 data partition holding everything sensitive (wallets, identities, secrets, app volumes). The data volume auto-unlocks at boot via a keyfile that sits in plaintext on that unencrypted root (
/etc/crypttab->/root/.luks-archipelago.key), because the product must boot headless and unattended — no keyboard exists to answer a passphrase prompt, and a kiosk must come back by itself after a power cut.Consequence (recorded in docs/1.8.0-RELEASE-HARDENING-PLAN.md §F): whole-box theft while powered off gets no protection — the key rides with the machine. Today the encryption protects the data disk (RMA, resale, disposal, drive-only theft, mounting the partition without the OS), not the machine.
Proposed Solution
Bind the LUKS key to a second factor per the hardening plan:
Known dependencies
Acceptance