julian
c142166972
No secure element is on-site: event signing runs on the software HMAC (EVENT_SIGNING_KEY, an env var on the host disk), so the ledger is tamper-EVIDENT but forgeable by anyone who owns the host. Several pages overstated it as present-tense "ATECC608-signed / unforgeable"; correct them. - NEW concepts/hardware-signer-options.md: four options for a non-extractable signing key (USB HSM / YubiKey / reuse the TPM / plain-dongle trap) + the recommendation (TPM interim → USB-HSM target; ATECC608 stays for the embedded ESP32, wrong part for a PC host). - entities/atecc608.md: UPCOMING-not-present status banner + PC-vs-embedded. - disk-os-hardening.md: fix the live-USB row (BIOS boot-order password is load-bearing, not Secure Boot — a signed live USB runs); add a physical-tamper chain (Dell 7070 CMOS-reset → live-USB → PCR-7 same-signer unseal) + accepted risks (that unseal, unsigned-initramfs evil-maid, operator-USB read TODO). - open-questions #6 reframed; standing-decisions / overview / threat-model / index de-overstated; log query entry. Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V
2.7 KiB
type, tags, sources, updated
| type | tags | sources | updated | |||||
|---|---|---|---|---|---|---|---|---|
| entity |
|
|
2026-07-02 |
ATECC608 (secure element)
An inexpensive secure element holding a signing key that cannot be extracted, even by someone who owns the machine. The design's intended keystone of ledger integrity. (See parking-system-architecture §3, §7.)
⚠ STATUS — UPCOMING, NOT PRESENT (2026-07-02). No ATECC608 (nor any secure element) is on the booth today. Event signing runs on the software
SoftwareSigner(HMAC-SHA256, key inEVENT_SIGNING_KEY, an env var on the host disk). Consequence: the append-only-event-chain is tamper-evident but not unforgeable by an adversary who owns the host — they can read the key and re-sign a doctored chain (disk-os-hardening physical-tamper chain). Do not describe the ledger as "hardware-signed / unforgeable" in present tense. This is the still-open open-questions.
Two distinct intended uses:
- Host-side event signing. The design has each event in the append-only-event-chain signed by a non-extractable key so the hash chain is unforgeable rather than merely self-consistent. Caveat: the ATECC608 is an external I²C part native to embedded boards, not a PC component — on the PC-based booth appliance the realistic non-extractable host signer is the tpm already on the machine, or a USB HSM (Nitrokey HSM 2 / SmartCard-HSM). See hardware-signer-options for the full menu + the TPM-interim → USB-HSM-target recommendation.
- Custom controller command authentication. On the (deferred) esp32-custom-controller, it would hold the key(s) for challenge-response-auth — generated on-chip, non-extractable, so popping the cabinet and dumping flash yields nothing usable. This use is deferred (access control is the dingtian-relay behind network-isolation).
Confirming a real secure-element signer on the host is open-questions #6. Listed (aspirationally) in the bom; treat as a future line item until procured.
Platform caveat (2026-06-21): the ATECC608 is not a PC component — it's an external I²C secure element you add/solder, native to embedded boards (the esp32-custom-controller), not to an off-the-shelf host PC. For a PC-based appliance the realistic host secure-element for the non-extractable event-signing key is the tpm the machine likely already has; reserve the ATECC608 for the embedded controller. Both give the same non-extractable property — see tpm "TPM vs. ATECC608". So use #1 (host event signing) is TPM on a PC, ATECC608 on embedded; use #2 (controller command auth) stays ATECC608.