Skip to content

Roadmap

v0.3.0 closes Phase 9 ("hardening"). Phase 10 follows FOSSCOMM 2026 and has no dates yet. Smaller items live in the backlog.

Phase 10 — physical hardening

The goal is that a stolen dongle can no longer sign without the PIN.

PIN-bound signing

In the documented signing API the chip checks which pairing key opened the session, not a PIN. So signing becomes PIN-bound indirectly:

  1. A new pairing key pair: its public key goes into slot SH1, which gets the signing rights; SH0, whose private key is public, loses them. Writing a pairing slot is one-way and the access-policy change follows the official configuration procedure, so this gets its own reviewed design first.
  2. SH1’s private key is stored sealed under the PW1-derived key, like the decryption key today. The goal: without the PIN, no session with signing rights can be opened — provided no other pairing slot keeps signing rights and no unsealed key or open session survives.
  3. Open design questions: while a signature runs, the unsealed SH1 key is in STM32 RAM and needs read-out protection (RDP / TrustZone); and a PIN reset must not use up the pairing slots: SH0 is occupied, and each of the three initially blank slots can be written only once.

Protecting secrets on the STM32

Read-out protection level, TrustZone, or keeping long-term secrets in or sealed by TROPIC01. Closing DFU would need a signed update path.

Decryption key that survives a PIN reset

Once the pairing key is private, the decryption key can be sealed with a chip-held secret (keeping the PIN check in front), so an Admin-PIN reset keeps it, as on a YubiKey. The chip can restrict data-slot reads to chosen pairing slots, but per group of 128 slots, so this needs its own storage region.

OpenPGP key import (keytocard)

Import of signing and authentication keys into chip slots (the chip reports whether a key was generated or imported), and of the decryption key into the sealed record. This gives an off-card backup of the decryption key; the trade-off is that an imported key was not generated by the chip.

Device identity

Verify the chip's certificate chain against Tropic Square's root, and check the chip firmware version at runtime against the supported range.

libtropic 4 and newer chip firmware

  • Move the firmware from libtropic 3.2.1 to 4.2.0 (renamed APIs, a digest-based ECDSA call, reworked firmware-update API, CRC retry handling that must be audited around destructive commands).
  • Update the chip to the newest public application firmware (2.2.0 at the time of writing) only with the controlled procedure from Tropic Square's advisory: both banks, version checks before and after, maintenance mode disabled. Check the RNGTEST_DIS erratum's applicability first.
  • Write down which chip firmware versions nixtropic supports.

Other

  • Per-device pairing keys.
  • Non-resident (wrapped) FIDO credentials, so the 29 slots stop limiting the number of sites.
  • A registered USB VID:PID and upstream libccid support, which removes the libccid patch.
  • Packaging in nixpkgs.