31cf85b707
The Librem Key is a custom device USB-based security token Nitrokey is producing for Purism and among other things it has custom firmware created for use with Heads. In particular, when a board is configured with CONFIG_LIBREMKEY, this custom firmware allows Heads to use the sealed TOTP secret to also send an HOTP authentication to the Librem Key. If the HOTP code is successful, the Librem Key will blink a green LED, if unsuccessful it will blink red, thereby informing the user that Heads has been tampered with without requiring them to use a phone to validate the TOTP secret. Heads will still use and show the TOTP secret, in case the user wants to validate both codes (in case the Librem Key was lost or is no longer trusted). It will also show the result of the HOTP verification (but not the code itself), even though the user should trust only what the Librem Key displays, so the user can confirm that both the device and Heads are in sync. If HOTP is enabled, Heads will maintain a new TPM counter separate from the Heads TPM counter that will increment each time HOTP codes are checked. This change also modifies the routines that update TOTP so that if the Librem Key executables are present it will also update HOTP codes and synchronize them with a Librem Key.
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".
Building heads
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 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 and the Chell chromebook.
** Xen and the TPM do not work in QEMU, so it is only for testing the
initrdimage. - Booting Qubes requires patching Xen's real mode startup code
see
patches/xen-4.6.3.patchand addingno-real-modeto start of the Xen command line. Booting or installing Qubes is a bit hacky and needs to be documented. - 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
Signing with GPG
gpgv is a stripped down version of GPG that can be used to verify
signatures without extraneous libraries. This works well with the
Free Software workflow that we want to use.
gpg --clearsign roothash
The roothash and roothash.sig files can be embedded into the
HDD image and then extracted at firmware boot time:
gpgv --keyring /trustedkeys.gpg roothash.sig roothash \
|| echo "FAILED"
The mount-boot script is a start at doing this automatically.
There needs to be an empty block at the end of the partition
that includes a signed script to be executed; typically it will
contain the dm-verity parameters to build the dmsetup command
line to mount /boot.
The boot script can't be stored in the boot filesystem since the dm-verity hashes that protect the filesystem would need to have their own hash pre-computed, which is not feasible with a good hashing algorithm. You could store the hashes in the ROM, but that would not allow upgrades without rewriting the ROM.
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.