---
type: concept
tags: [parking, security, platform, hardware]
sources: []
updated: 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|outsider-with-the-box]]) 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|signed 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|signed 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|ESP32]]** 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).