parking_solution/wiki/concepts/tpm.md

type, tags, sources, updated

type	tags	sources	updated
concept	parking security platform hardware		2026-06-21

TPM 2.0 (Trusted Platform Module)

A small crypto chip on the host that provides two host-hardening primitives. Useful defence-in- depth for the appliance, but — like all secure elements — it defends the secondary (threat-model) threat, never the operator-at-the-booth, and is not a substitute for the system's real anti-fraud control (reconciliation over the append-only-event-chain). (Analysis recorded 2026-06-21; implementation pending — see open-questions #12.)

⚠ Naming: it's TPM (Trusted Platform Module), often miswritten "TMP".

How it works — two primitives

1. Non-extractable keys. A key generated inside the TPM never leaves it. No command at any privilege level reads out the private key; you can only ask the TPM to use it (sign/decrypt). So the key isn't a file an attacker can copy — the same property the atecc608 gives, but with hardware most PCs already have.
2. Boot measurement + sealing (PCRs). Each boot stage hashes the next (firmware → bootloader → kernel) into tamper-evident registers (PCRs). A secret can be sealed so the TPM only releases/uses it when the PCRs match a known-good boot state — tamper the boot chain → PCRs change → the TPM refuses.

What it buys this appliance

• Sealed-LUKS auto-unlock for unattended reboot. The headline win. LUKS (disk-os-hardening) normally needs a human to type a passphrase at boot; a parking booth must reboot itself after a power cut. systemd-cryptenroll --tpm2-device seals the LUKS key to the TPM + boot-chain PCRs, so the disk auto-unlocks only on an untampered boot. This is what makes "encrypted disk" and "unattended appliance" compatible.
• Defeats the offline disk-tamper / re-sign attack. If the host event-signing key lives in the TPM (non-extractable), then pulling the SSD yields the data but not the signing key — so an attacker cannot edit a row and re-sign the chain. verifyChain() then catches every edit. (With a software signer the key sits in .env on the disk, so disk theft = key theft = forgeable; see append-only-event-chain "Signer abstraction".) Sealed-LUKS goes further: the disk won't even mount off-host, blocking the read step entirely.
• Boot tamper-evidence complementing the already-decided Secure Boot + GRUB password (disk-os-hardening).

What it does NOT protect against (be honest about the limits)

• A rooted running host. The TPM stops key theft, not key use. An attacker with admin/root on the live appliance can still ask the TPM to sign — the chip signs for whoever the running OS authorizes. So a TPM does not make a compromised host trustworthy. (A per-op TPM auth PIN/policy raises this bar but a determined root can often capture it.) This is exactly why the load-bearing control stays reconciliation against an external authority that assumes the box may lie.
• Determined physical + BIOS access with tools. Documented attacks exist:
  • Bus sniffing — a discrete TPM talks to the CPU over an external LPC/SPI bus; researchers have physically tapped it and captured secrets as they're released (e.g. the LUKS/BitLocker key in transit) on PCR-only-sealed systems. A firmware TPM (fTPM) inside the CPU has no external bus to sniff (but has had its own firmware bugs).
  • TPM 1.2 is broken (SHA-1) — require 2.0 only.
  • Vendor-specific firmware/reset/replay vulns have surfaced over the years.
• The operator (primary threat). While the app runs, the DB is decrypted in memory and the operator acts through the authenticated app — encryption/sealing is irrelevant to "take the cash, void the record" (threat-model).
• Windows caveat. On Windows the TPM serves BitLocker/Hello, not our Linux app; a Windows-admin attacker inherits Windows' long history of BitLocker-TPM bypasses. Another reason the Windows + WSL fallback (desktop-shell-tauri) is the weak deployment.

Verdict & guidance

• Recommended (not required) on the Ubuntu 26.04 LTS appliance ([[desktop-shell-tauri|best case]]): use it for sealed-LUKS auto-unlock + a non-extractable host event-signing key. It is a cost-raiser and theft-defeater, not an absolute vault.
• Prefer a firmware TPM (fTPM) (Intel PTT / AMD fTPM — no external bus to sniff) and add a PIN/auth policy, rather than PCR-only sealing.
• Operational hazard: sealing to boot-chain PCRs means a legitimate kernel / GRUB / BIOS update also changes the PCRs and locks you out until re-sealed. Keep a LUKS recovery passphrase and a re-seal-on-update runbook — mandatory, and a reason this stays "enhancement," not "baseline".
• It complements, never replaces, the append-only-event-chain + reconciliation.

TPM vs. ATECC608 — which secure element for the signing key

Both can hold the non-extractable host event-signing key. Pick by platform:

	TPM 2.0	atecc608
In a typical PC?	Often yes (discrete or fTPM)	No — an external I²C part you add/solder
Standard / integration	TCG standard, OS-integrated	Microchip part, app-integrated over I²C
Best fit here	PC-based host appliance (use what's there)	**Embedded / [[esp32-custom-controller
Tangled with the whole OS attack surface?	Yes (general-purpose)	Less so (single-purpose chip)

Implication (refines the prior framing): the wiki/bom treated the ATECC608 as the host signing root, but for the Ubuntu-PC appliance the TPM is the realistic host secure-element (no extra part to source), with the ATECC608 reserved for the embedded controller where there's no TPM. Either delivers the tamper-proof property; see open-questions #6 (host secure-element by platform) and #12 (TPM hardening implementation).