Files
parking_solution/wiki/entities/esp32-custom-controller.md
julian 7de5c74500 wiki: record JWT key open question; defer ESP32 controller
- open-questions #7: symmetric vs. asymmetric JWT signing key (from the
  commit security review). Prefer RS256/EdDSA so verifying hosts hold only a
  public key — mirrors the ATECC608 / challenge-response "public key only"
  property. Decide before multi-host/multi-lane deployment.
- Mark esp32-custom-controller status: deferred per decision not to build
  device-level auth now; access control stays on UHPPOTE + network isolation
  (noted in open-questions #6).
- local-jwt-auth: document hardened secret handling + 8h expiry and the
  asymmetric-key pointer.
- Update index.md and append a log.md entry.
2026-06-14 07:45:14 +02:00

2.2 KiB

type, tags, sources, updated, status
type tags sources updated status
entity
parking
hardware
access-control
upgrade-path
parking-system-architecture
2026-06-15 deferred

Custom ESP32 Controller (prevention alternative)

Status: deferred — not being implemented for now. Access control stays on the uhppote-controller behind network-isolation (tamper-evident). This page is kept as the documented upgrade path; revisit only if prevention-grade device authentication becomes a requirement. See open-questions #6.

A small custom controller for device-level authentication — a control path that holds even against an attacker on the wire. The prevention-grade upgrade from the uhppote-controller (which is only tamper-evident). It moves the trust-boundary to the device. (See parking-system-architecture §7.)

Requirement reframed

The threat is forged or replayed commands, not eavesdropping ("open lane 2" isn't secret). So the essential requirement is authenticity + freshness (anti-replay); encryption is optional defence-in-depth. This is implemented as challenge-response-auth.

Hardware

  • Olimex ESP32-POE (wired Ethernet + PoE, open-source hardware) or ESP32-S3 + W5500.
  • atecc608 secure element holding the key(s), generated on-chip, non-extractable.
  • Opto-isolated relay between GPIO and the barrier operator's dry-contact open input.
  • Enable ESP32 flash encryption + secure boot regardless.
  • Transport: Ethernet (one network paradigm on the managed switch), or RS-485 multidrop for long/noisy runs.

Safety — treat as seriously as the crypto

Governed by fail-state-safety: entry fails closed, exit fails open, a hardware manual override (key switch) that works with the ESP32 dead, a watchdog with a safe default, and the barrier operator still owns physical safety (barrier-not-a-door).

Trade-offs

You take on firmware reliability, EMC/surge protection (TVS diodes, isolation, grounding, Ethernet surge arrestor outdoors), and field maintenance. Mitigate by keeping firmware tiny and auditable: verify a signed fresh command, pulse a relay, watchdog + safe state, nothing more. All parking logic stays on the host.