Update Heads-threat-model.md

[PhilienTaylor]

Included more clear formatting of how Heads can produce a TPMTOTP or a TPMHOTP, and how the former requires users to monitor the same system time synchronicity between machines.

Hey! It's my second Pull Request for Docs! :)

Hi there, @tlaurion , your work is so priceless that no amount of money can reward you. Until then, here's my contribution to the work that you and other Heads developers & community have provided us. Thank you for everything!!

[PhilienTaylor]

I don't know how to remove 'calculate calculate' from within my pullrequest within Github. aa

[tlaurion]

Thanks for the contribution effort @PhilienTaylor !

Some raw edits (suggestions)

-### TPMTOTP and TPMHOTP

-TPMTOTP and TPMHOTP are mechanisms that bind OTP secrets to the TPM's measured boot state. TPMTOTP uses time-based OTP (TOTP) where the TPM unseals a secret and derives a code based on the current system time, requiring clock synchronization with the verifying device (e.g., your phone). TPMHOTP uses counter-based OTP (HOTP), where hardware-based OTP providers calculate the secret in the same manner as the Heads device, without requiring time synchronization.

-Hardware-based OTP providers are excluded from this time requirement as they calculate the secret in the same manner as your Heads device using bootcounts instead of time.
+### TPM-backed OTPs in Heads
+
+Heads integrates standard One-Time Password (OTP) mechanisms — **TOTP** and **HOTP** — with the TPM to detect firmware tampering and ensure measured-boot integrity.
+
+#### TPM-sealed OTP secrets
+During initial provisioning, Heads stores an OTP secret inside the TPM, sealed to specific PCR values.  
+Only when the system boots in the expected measured state can the TPM unseal this secret.  
+The TPM does **not** compute the OTP; it only protects and conditionally releases the secret.
+
+#### TOTP (Time-based OTP — RFC 6238)
+- Once unsealed, Heads computes a standard TOTP value using the system’s real-time clock.  
+- Verification is performed manually by comparing the code displayed in Heads with an authenticator app (e.g., on your phone).  
+- Because TOTP depends on time, the Heads clock must be synchronized (usually within ±30 s) with the verifier’s clock.  
+- A mismatch in RTC will cause valid firmware to appear “unverified.”  
+
+#### HOTP (Counter-based OTP — RFC 4226)
+- Heads can also compute a standard HOTP code using the same TPM-sealed secret and a **counter stored at** `/boot/hotp_counter`.  
+- After each verified boot, Heads increments this counter.  
+- Compatible hardware tokens such as Nitrokey or Librem Key use a *reverse-HOTP* protocol to automatically verify the code generated by Heads.  
+- HOTP does not depend on clock synchronization, but it **does require counter synchronization** between the platform and the hardware token.  
+- Because the counter resides on `/boot`, an attacker with write access to `/boot` could roll it back, replaying a previously valid OTP.  
+  Therefore, HOTP in Heads provides *tamper evidence*, not rollback prevention.  
+
+#### Terminology clarification
+- The term **“TPMTOTP”** refers to a *TPM-sealed secret* used to generate a standard TOTP code.  
+- There is **no such mechanism as “TPMHOTP”** — Heads simply uses the same TPM-sealed secret for HOTP computations, with the counter managed on `/boot`.  
+
+References: [RFC 6238 — TOTP](https://datatracker.ietf.org/doc/html/rfc6238), [RFC 4226 — HOTP](https://datatracker.ietf.org/doc/html/rfc4226)

• Removes the invented term TPMHOTP.

• Explains that the TPM only seals the secret, not the counter.

• Specifies the counter’s location (/boot/hotp_counter).

• Adds clock sync requirement for TOTP and counter sync requirement for HOTP.

• Notes rollback limitation of /boot.

• Adds citations to RFC 4226 and RFC 6238.