Thierry Laurion
bd0f786c4d
The NK3 uses 'Secrets app' terminology and has 8 PIN retry attempts (vs 3 for older devices), but the codebase had inconsistent UX messaging that referred to 'GPG Admin PIN', 'USB security dongle', 'TOKEN', etc. instead of the actual brand and PIN type. Fix 1: PIN label - $prompt_message is used in all user-facing strings (status, prompts, error messages, reminder note) with correct value: 'Secrets app' for NK3, 'GPG Admin' for older devices. Fix 2: Dynamic attempt counting - after the default PIN trial consumes an attempt, re-read the counter and limit user attempts to min(retries-1, 3). If the counter read is unreliable (0 or 1), fall back to 3 attempts so the user is never blocked from sealing. Documented with example outcomes for NK3 (8 retries) and pre-NK3 (3 retries). Fix 3: NK3-specific error message now references 'Secrets app PIN' instead of 'GPG Admin PIN' in the PIN reset instructions. Fix 4: Use $DONGLE_BRAND consistently in all USB security dongle messaging (STATUS, prompts, dialog titles, guidance strings, integrity report, DEBUG logs, error messages, NOTES) instead of hardcoded 'USB security dongle', 'OpenPGP signing card', 'GPG security dongle', 'dongle', 'signing card', 'Dongle key'. Also replaces 'TOKEN' in hotp_state/hotp_display with $DONGLE_BRAND so integrity report shows actual brand (e.g. 'Nitrokey 3 PRESENT' instead of 'TOKEN PRESENT'). Fix 5: Centralize branding detection in standalone script entry points: - gui-init.sh: already detects at boot flow entry (line ~965) - oem-factory-reset.sh: added detection at script start (was missing) - confirm_gpg_card: detects for gpg-gui.sh and kexec-sign-config.sh - report_integrity_measurements: detects for hotp/gpg flow - seal-hotpkey.sh: has its own detection at script start Fix 6: detect_usb_security_dongle_branding now guards against redundant re-detection while preserving USB init safety: it skips USB re-init and lsusb re-scan only when a specific DONGLE_BRAND is already set and _USB_ENABLED=y in the current process. In child scripts that inherit DONGLE_BRAND but reset _USB_ENABLED, it still runs enable_usb, then returns without re-scan if branding is already specific. Fix 7: Comment casing fix in oem-factory-reset.sh (Secrets App -> Secrets app) to match user-facing strings and hotp_verification output. Fix 8: Remove duplicate show_pin_retries call before PIN entry loop in seal-hotpkey.sh. The function was being called twice before the first prompt (once before the loop, once at loop start), showing 'Nitrokey 3 Secrets app PIN retries remaining: 8' twice. Fix 9: Clarify and enforce fast-path behavior for detect_usb_security_dongle_branding in mixed parent/child script contexts: avoid redundant module loads and scans in the same process, but do not skip USB initialization when only branding is inherited. Fix 10: detect_usb_security_dongle_branding now reuses wait_for_usb_devices after enable_usb only when USB was not already initialized in the current process. This avoids early lsusb enumeration races without regressing the no-redundant-load/no-re-scan fast path. Signed-off-by: Thierry Laurion <insurgo@riseup.net>
Heads: the other side of TAILS
Heads is a configuration for laptops and servers that tries to bring more security to commodity hardware. Among its goals are:
- Use free software on the boot path
- Move the root of trust into hardware (or at least the ROM bootblock)
- Measure and attest to the state of the firmware
- Measure and verify all filesystems
NOTE: It is a work in progress and not yet ready for non-technical users. If you're interested in contributing, please get in touch. Installation requires disassembly of your laptop or server, external SPI flash programmers, possible risk of destruction and significant frustration.
More information is available in the 33C3 presentation of building "Slightly more secure systems".
Documentation
The doc/ directory contains technical reference documentation for the
Heads codebase. Start here:
| Document | What it covers |
|---|---|
| doc/architecture.md | Component overview: coreboot, Linux payload, initrd, build system, configuration layers |
| doc/security-model.md | Trust hierarchy, measured boot, TOTP/HOTP attestation, GPG boot signing, LUKS DUK, fail-closed design |
| doc/boot-process.md | Step-by-step boot flow: /init → gui-init → kexec-select-boot → OS handoff |
| doc/tpm.md | PCR assignments, sealing policies, SRTM chain, board-specific TPM variations, developer config reference |
| doc/ux-patterns.md | GUI/UX conventions: whiptail wrappers, integrity report, error flows |
| doc/config.md | Board and user configuration system |
| doc/docker.md | Reproducible build workflow using Docker |
| doc/qemu.md | QEMU board targets for development and testing |
| doc/wp-notes.md | Flash write-protection status per board |
| doc/BOARDS_AND_TESTERS.md | Supported boards and their maintainers/testers |
For user-facing documentation and guides, see Heads-wiki.
Contributing
We welcome contributions to the Heads project! Before contributing, please read our Contributing Guidelines for information on how to get started, submit issues, and propose changes.
Building Heads
Heads builds inside a versioned Docker image. The supported and tested workflow uses the provided Docker wrappers — no host-side QEMU or swtpm installation is needed.
Quick start (requires Docker CE):
./docker_repro.sh make BOARD=x230-hotp-maximized
./docker_repro.sh make BOARD=qemu-coreboot-fbwhiptail-tpm2 run
For full details — wrapper scripts, Nix local dev, reproducibility verification, and maintainer workflow — see doc/docker.md.
For QEMU board testing see doc/qemu.md.
General notes on reproducible builds
In order to build reproducible firmware images, Heads builds a specific
version of gcc and uses it to compile the Linux kernel and various tools
that go into the initrd. Unfortunately this means the first step is a
little slow since it will clone the musl-cross-make tree and build gcc...
Once that is done, the top level Makefile will handle most of the
remaining details -- it downloads the various packages, verifies the
hashes, applies Heads specific patches, configures and builds them
with the cross compiler, and then copies the necessary parts into
the initrd directory.
There are still dependencies on the build system's coreutils in
/bin and /usr/bin/, but any problems should be detectable if you
end up with a different hash than the official builds.
The various components that are downloaded are in the ./modules
directory and include:
We also recommend installing Qubes OS,
although there Heads can kexec into any Linux or
multiboot
kernel.
Notes
- Building coreboot's cross compilers can take a while. Luckily this is only done once.
- Builds are finally reproducible! The reproduciblebuilds tag tracks any regressions.
- Currently only tested in QEMU, the Thinkpad x230, Librem series and the Chell Chromebook. ** Xen does not work in QEMU. Signing, HOTP, and TOTP do work; see below.
- Building for the Lenovo X220 requires binary blobs to be placed in the blobs/x220/ folder. See the readme.md file in that folder
- Building for the Librem 13 v2/v3 or Librem 15 v3/v4 requires binary blobs to be placed in the blobs/librem_skl folder. See the readme.md file in that folder
QEMU
OS booting can be tested in QEMU using a software TPM. HOTP can be tested by forwarding a USB token from the host to the guest.
For more information and setup instructions, refer to the qemu documentation.
coreboot console messages
The coreboot console messages are stored in the CBMEM region
and can be read by the Linux payload with the cbmem --console | less
command. There is lots of interesting data about the state of the
system.