julian
4319fb86dc
- dingtian-relay: relay+input controller (4ch on hand). Inputs are decoupled from relays (configurable via input_link_relay) — solves the access-controller-button-flow blocker the UHPPOTE couldn't. Full protocol from the SDK (UDP string control :60001, `00` status parse, input_link_url push, multicast discovery). Driver + hardware test still to build. - dingtian-vs-mqtt: use direct HTTP/UDP now; MQTT skipped (broker = extra infra + failure mode + overkill at one-host/few-devices scale) but kept for later multi-lane scale. - autonomous-direction: record the roadmap to fully unmanned (no booth) and how it reshapes the threat model (operator-fraud -> unattended-machine threats), makes host-in-the-loop entry mandatory, and raises fail-state stakes. - threat-model: note the unmanned shift. index + log. gitignore the vendor SDK (dingtian/, 71MB of binaries/examples) — reference only, protocol captured in the wiki.
2.2 KiB
type, tags, sources, updated
| type | tags | sources | updated | ||||
|---|---|---|---|---|---|---|---|
| concept |
|
|
2026-06-14 |
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-sealed keys. 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 atecc608-signed (unforgeable).
- 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).
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."