Files
parking_solution/wiki/concepts/uhppote-vs-esp32.md
T
julian bfe64032d8 Initial scaffold: Turborepo monorepo + design wiki
Turborepo (pnpm workspaces) with all dependencies pinned to latest
mutually-compatible versions: turbo 2.9, TypeScript 6, Fastify 5,
React 19, Vite 8, better-sqlite3 12 + Drizzle ORM 0.45.

Layout:
- apps/server   Fastify backend (local JWT auth + role guard, /health)
- apps/web      React 19 + Vite 8 operator SPA
- packages/db   Drizzle schema on SQLite/WAL; append-only events + users
- packages/devices  reader/printer/relay adapter interfaces (intent-only relay)
- packages/shared   shared domain types

Architecture constraints from the design wiki are encoded in the scaffold:
append-only hash-chained + signed event log, device-agnostic adapters,
"a barrier is not a door" (relay expresses intent only), fully-local
offline-first auth.

wiki/ is an LLM-maintained Obsidian knowledge base (28 pages) ingested
from the architecture & design notes, with its own maintenance schema.

Verified: pnpm install, full turbo build (5/5), server boots and serves
/health, drizzle-kit generates the initial migration.
2026-06-14 00:34:11 +02:00

32 lines
1.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
type: concept
tags: [parking, comparison, access-control, security]
sources: [parking-system-architecture]
updated: 2026-06-14
---
# UHPPOTE vs. Custom ESP32 — Detection vs. Prevention
A head-to-head on the [[trust-boundary]] fork: the off-the-shelf [[uhppote-controller]] versus
the [[esp32-custom-controller]]. (Synthesized from [[parking-system-architecture]] §6–7.)
| | [[uhppote-controller]] | [[esp32-custom-controller]] |
| --- | --- | --- |
| **Trust boundary** | The network | The device |
| **Security posture** | Tamper-**evident** (detection) | Tamper-**proof** (prevention) |
| **Command auth** | None — [[uhppote-udp-protocol]] is open UDP | [[challenge-response-auth]] (asymmetric sigs) |
| **Key mitigation** | [[network-isolation]] (mandatory) + [[event-log-ingestion]] | [[atecc608]] holds non-extractable key; controller stores only a public key |
| **Firmware** | Manufacturer-only; not customizable | You own it (tiny + auditable) |
| **Cost / effort** | Cheap, off-the-shelf, available now | Build + firmware reliability, EMC/surge, field maintenance |
| **Replay/forgery on the wire** | Possible — contained only by isolation | Defeated by fresh per-command nonce |
| **Safety** | Barrier operator owns it ([[barrier-not-a-door]]) | Same + explicit [[fail-state-safety]] |
## Bottom line
- The UHPPOTE is the **current choice**: good enough as a detection/audit layer **when only the
host can reach it** (isolation) and every event lands in the [[append-only-event-chain]].
- The ESP32 is the **documented upgrade** when you need a control path that holds even against an
attacker on the wire. They're **mixable per lane**.
- Both still rely on host-side integrity ([[append-only-event-chain]]) and external
[[reconciliation]] as the ultimate anti-fraud control.