Add support for two-factor HW passkey (FIDO2)

README.md

@@ -27,6 +27,8 @@ Or, if you are in a hurry, kill all processes with open files inside your tomb a
 ```
  $ tomb slam
 ```
+
+Tomb also supports two-factor unlocking with a FIDO2 passkey; see `doc/FIDO2.md` for setup details.
 ## 📖 [Get started on dyne.org/tomb](https://dyne.org/tomb)
 
 <a href="https://dyne.org/tomb"><img src="https://files.dyne.org/software_by_dyne.png" width="30%"></a>

doc/FIDO2.md

@@ -0,0 +1,52 @@
+# FIDO2 / Passkey Support in Tomb
+
+Tomb can protect a tomb key with a FIDO2/WebAuthn passkey instead of a traditional passphrase. The secret material that unlocks the key is derived from the authenticator, so opening the tomb requires:
+
+- Physical presence on the passkey (touch/UV).
+- The authenticator PIN (if configured).
+
+This effectively replaces the passphrase with two‑factor authentication: you need both the hardware token and its PIN.
+
+## How it works
+
+- Tomb registers a discoverable credential on your authenticator using the `hmac-secret` extension.
+- During forge (`tomb forge --fido2 -k …`) Tomb asks the device for an HMAC secret derived from:
+  - a random challenge,
+  - the relying party (`tomb.dyne.org` by default),
+  - the credential id, and
+  - a random salt Tomb stores in the key header.
+- The returned 32‑byte secret (plus optional extra material) is used as the passphrase to encrypt the tomb key. Tomb embeds the FIDO2 metadata (`rp`, `cred`, `salt`, optional `device`) in the key header.
+
+When opening/locking with `--fido2`, Tomb:
+
+1) Reads the `_FIDO2 …` header from the key file.  
+2) Requests a new `hmac-secret` from the authenticator with the stored RP, credential id, and salt.  
+3) Uses that secret to decrypt the key and unlock the tomb.
+
+## Usage
+
+- Forge a FIDO2 key:
+  ```
+  tomb forge --fido2 -k secrets.tomb.key
+  ```
+- Lock/open with the passkey:
+  ```
+  tomb lock  --fido2 -k secrets.tomb.key secrets.tomb
+  tomb open  --fido2 -k secrets.tomb.key secrets.tomb
+  ```
+- If you have multiple authenticators, point to one explicitly: `--fido2-device /dev/hidrawX`.
+
+## Hardware requirements
+
+- The authenticator must advertise the `hmac-secret` extension (`fido2-token -I` should list `extension strings: hmac-secret`).
+- A PIN/UV-capable device is required; Tomb requests user verification.
+
+### DIY option: Fidelio on Raspberry Pi Pico
+
+If you need a compliant token and want to build it yourself, you can flash the open-source [Fidelio](https://github.com/danielinux/fidelio) firmware on a Raspberry Pi Pico to create a FIDO2 authenticator with `hmac-secret` support.
+
+## Security notes
+
+- The passphrase is never stored; the authenticator derives it on demand.
+- Losing the registered passkey means losing access to the tomb unless you keep another copy of the key protected differently.
+- The FIDO2 metadata in the key header is not secret; protect the key file itself as usual.

doc/tomb.1

@@ -280,6 +280,24 @@ Tell tomb to use an asymmetric GnuPG key encryption instead of a
 symmetric passphrase to protect a tomb key. This option can be
 followed by \fI-r\fR when the command needs to specify recipient(s).
 .B
+.IP "--fido2"
+Use a FIDO2/WebAuthn passkey (hmac-secret) instead of a passphrase to protect
+the tomb key. Requires an authenticator that advertises the hmac-secret
+extension; during forge/open/lock Tomb will prompt for PIN/UV and device
+presence. For details see doc/FIDO2.md.
+.B
+.IP "--fido2-device \fI<path>\fR"
+Select a specific FIDO2 authenticator (e.g. /dev/hidrawX). If omitted Tomb
+auto-detects.
+.B
+.IP "--fido2-rp \fI<rp_id>\fR"
+Override the relying party id used when registering the passkey (default:
+tomb.dyne.org).
+.B
+.IP "--fido2-user \fI<name>\fR"
+Override the username stored in the authenticator when registering the passkey
+(default: the current user).
+.B
 .IP "-r \fI<gpg_id>[,<gpg_id2>]\fR"
 Provide a new set of recipient(s) to encrypt a tomb key. \fIgpg_ids\fR
 can be one or more GPG key ID, comma separated. All GPG keys must be