julian
c142166972
No secure element is on-site: event signing runs on the software HMAC (EVENT_SIGNING_KEY, an env var on the host disk), so the ledger is tamper-EVIDENT but forgeable by anyone who owns the host. Several pages overstated it as present-tense "ATECC608-signed / unforgeable"; correct them. - NEW concepts/hardware-signer-options.md: four options for a non-extractable signing key (USB HSM / YubiKey / reuse the TPM / plain-dongle trap) + the recommendation (TPM interim → USB-HSM target; ATECC608 stays for the embedded ESP32, wrong part for a PC host). - entities/atecc608.md: UPCOMING-not-present status banner + PC-vs-embedded. - disk-os-hardening.md: fix the live-USB row (BIOS boot-order password is load-bearing, not Secure Boot — a signed live USB runs); add a physical-tamper chain (Dell 7070 CMOS-reset → live-USB → PCR-7 same-signer unseal) + accepted risks (that unseal, unsigned-initramfs evil-maid, operator-USB read TODO). - open-questions #6 reframed; standing-decisions / overview / threat-model / index de-overstated; log query entry. Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
3.4 KiB
type, tags, sources, updated
| type | tags | sources | updated | ||||
|---|---|---|---|---|---|---|---|
| concept |
|
|
2026-06-20 |
Threat Model
The second foundational force (with offline-first). The central insight is a reframing of who the adversary is. (See parking-system-architecture §3.)
The key reframing
Early thinking focused on protecting the database at rest — SQLCipher, LUKS, BitLocker, tpm. All of that defends against an outsider who steals the machine or boots from external media.
That is the wrong primary threat. The most likely adversary is the legitimate operator at the booth. While the app runs, the database is decrypted in memory and the operator has full authorised access through the app. Encryption does nothing against the classic parking fraud: take the cash, then void/delete the entry/exit record so the books balance.
Consequences
The controls that actually address insider/operator fraud are different in kind:
- append-only-event-chain — events appended, never edited/deleted; a "void" is itself a recorded event, hash-chained, and signed. ⚠ Signing is software today (key on the host disk) → tamper-evident but forgeable by a host owner; a non-extractable hardware signer (hardware-signer-options; atecc608 upcoming) is what makes it truly unforgeable. Which is why the load-bearing insider control is reconciliation, next.
- reconciliation against an authority the operator can't alter — this is what remote sync really is: a fraud-control mechanism, not just a backup.
- disk-os-hardening still worthwhile (defeats boot-from-USB) but not the main event; with LUKS in place, SQLCipher is optional defence-in-depth.
The same reframing recurs at the device layer: the uhppote-controller's real problem is unauthenticated commands (uhppote-udp-protocol), addressed by detection (event-log-ingestion) or prevention (esp32-custom-controller).
Worked example — "store the price" ≠ "account for the sale" (found + fixed 2026-06-20). Every money-taking action must append a signed
paymentevent, or it is invisible to reconciliation. A concrete miss: selling a subscription wrote only the mutablesubscriptionsmaster row (the agreed price) and appended nothing to the ledger, so the cash the operator collected showed up in the feed/drawer/Z-report nowhere — a clean off-book channel (three real sales, 27,000 ALL, untraceable). The fix is the textbook control: append a signedpayment(subscriptionSale: true) at sale time so it folds into the shift like any taking. The lesson generalises: whenever a feature records an amount in a mutable table, ask "where is the signed event that says money changed hands?" — a price in master data is not an accountable transaction. See subscription "Collecting the fee".
Direction shift: the system is heading toward fully unmanned operation — no operator, no booth (autonomous-direction). That removes the booth-operator as the primary adversary, but swaps in unattended-machine threats (tailgating, plate spoofing, physical tampering, forced entry). The append-only signed log + reconciliation controls carry over; the emphasis moves from "catch the cashier" to "trust the automated record and detect tampering."