julian
8a8e74561d
Pivot from the hardware/integrity layer to the parking operation. All wiki-only; no code yet. Core principle throughout: business entities are projections over the signed append-only event log, never mutable tables. New concepts: parking-session, tariff (composable/versioned, FX-ready), shift (manned-only Z-report), capacity-occupancy, validation-discounts, reporting-analytics, clock-integrity, ticket-encoding, anti-passback. New entities: permit, opencv-anpr-service, blocklist. Decisions: session-model, vision-service (host-side ANPR + vehicle verification; scoped AGPL exception for the isolated service). Updates: append-only-event-chain (new event types + vision witness), local-jwt-auth (drop 8h expiry -> until logout; code change pending), lpr-camera (host-side recognition supersedes edge-AI), standing-decisions (AGPL exception), open-questions (+FX, +pay-station money corners, backup). Deferred + flagged: intercom/help-call, receipts/refunds/change, FX engine, lane topology (#1).
2.3 KiB
2.3 KiB
type, tags, sources, updated, status
| type | tags | sources | updated | status | |||||
|---|---|---|---|---|---|---|---|---|---|
| concept |
|
2026-06-15 | open |
Clock Integrity
Fees are a function of time (tariff: fee = f(enteredAt, asOf)), and the event chain is
ordered/timestamped. So the host clock is part of the trust model — and on an offline appliance
(offline-first, no NTP guarantee) it's a real attack surface, fitting the
threat-model frame:
- Backdating to cut a fee — wind the clock back so a long stay computes as short, or so an exit timestamps before its entry.
- Forward/backward jumps that corrupt durations, the rolling-24h cap, or shift boundaries (shift).
- An operator with host access changing the system time deliberately.
What protects it
- Monotonic chain order is independent of wall-clock. The append-only-event-chain
indexis strictly increasing regardless of timestamps, so reordering is caught even if timestamps are forged. But the durations used for pricing still rely on the wall clock — so: - Detect clock anomalies and record them as events. A timestamp that goes backwards between
consecutive chain events, or jumps implausibly, is an
anomaly(the type already exists) — signed and surfaced to reconciliation, not silently accepted. - Hardware-backed time where possible. A battery-backed RTC on the appliance; the atecc608/secure element and disk-os-hardening reduce casual tampering. An operator changing time should require privilege the booth login doesn't have.
- Opportunistic trusted sync when a reconciliation channel is briefly online (the same USB/hotspot path) — set/check the clock against an external authority, log any correction as an event.
Stance
Like the rest of the system: prevention (hardened host, privileged-only time change) first, detection (anomaly on clock regression, reconciliation) as the backstop. The clock can't be made unforgeable on an offline box, but a forged clock can be made visible.
Open
- RTC / time source on the chosen appliance (bom).
- Tolerance thresholds for "implausible" jumps before flagging.
- Whether to hard-refuse an event on a backwards clock vs. record-and-flag (record-and-flag matches the append-only ethos — never drop).