Granted the user should really be using the Librem Key/phone to check
for tampering (since an attacker could control the Heads background
color) but this provides another visual queue for the user with
the GUI menu to catch less sophisticated tampering.
Currently the Librem Key tests will time out after 40 seconds, which
adds to the boot time significantly if the user wants to boot without
inserting it. This patch changes that timeout to one second.
The HOTP counter isn't a secret but is just used to prevent replay
attacks (the time-based counter in TOTP isn't a secret either) so it
doesn't need to be protected in the TPM and storing it as a TPM
monotonic counter was causing conflicts with the Heads configuration
counter as TPM 1.2 can only increment one counter per reboot.
This change moves the HOTP counter into the file in /boot that was
previously keeping track of the TPM counter id.
TPM v1.2 has a limitation in that only a single monotonic counter can be
incremented between reboots [1]. So in the event we are using HOTP
monotonic counters, we need to reference those for the Heads rollback
counter when we update file signatures in /boot, otherwise the increment
stage at kexec-sign-config will fail since at each boot, the HOTP
monotonic counter has already been incremented.
[1] https://projects.csail.mit.edu/tc/tpmj/UsersGuide.html#inccounter
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.
The bios regions of the 12M coreboot image is 7M: 4M and 3 of the 8M split
image. The rest of the 8M image _generated_ with fake data and not usable
on real systems! It's dangerous to create them and suggest flashing them
externally.
That's exactly why the x230-flash build target is there: To
have a self-contained 4M image and enable easy unlocking of the 8M image
using the _original_ data.
the heads-wiki project is updated accordingly.
Closes#307Closes#302
Adding the VBT file makes it available through some ACPI memory area
and apparently the VBT contains the information needed by the i915 driver
in order to figure out how to control the screen's backlight.
Without the VBT, we can't control the screen backlight with Fn-F5/Fn-F6
anymore.
In addition to being able to flash a ROM from the GUI, it would also be
useful for a user to be able to add a GPG key to their keyring using the
flashing tool. This change adds the ability for a user to edit both a
ROM located on a USB key and also edit the running BIOS by using
flashrom to make a local copy of the running BIOS, edit it, then reflash
it. This also supports the upcoming delete feature in CBFS for
circumstances where keyring files already exist within CBFS.
If we want to modify a running BIOS we will need the ability to pull
down the current BIOS, modify it, and then reflash. This change adds a
read option to flash.sh and pulls down three versions of the BIOS and
only exists successfully if all three match.
To be able to boot a disk image, passed to QEMU with `-hda
/path/qemu.img`, the appropriate modules are needed. Strange, `libata`
is not enough, and the drive is only detected, when the module `ahci` is
loaded.
> ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100
Tested with QEMU emulator version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7)
with the command below,
qemu-system-x86_64 -enable-kvm -M q35 -m 1G -bios \
qemu-coreboot/coreboot.rom -serial stdio -L /dev/shm -hda \
/dev/shm/qemu-debian.img
where `qemu-debian.img` is created with grml-debootstrap.
grml-debootstrap --vmfile --vmsize 3G --target \
/dev/shm/qemu-debian.img -r sid
To keep the flash logic simpler the GUI logic has been split into a
flash-gui.sh program so flash.sh behaves closer to the original flashrom
scripts it was based from. I've also removed the previous flashrom
scripts and incorporated their options into flash.sh. Finally I set
CONFIG_BOARD via the Makefile instead of setting a duplicate option in
each board's config.
Based on the conversation for PR #406, we decided to go with a more
generic script for general-purpose flashing instead of having individual
(and therefore very similar) flash scripts for each board type. This
script currently handles flashrom on Librem and X230 board types and
introduces a new CONFIG_BOARD option that sets specific flashrom
arguments based on the board.
It also adds support to gui-init to call this flash script.
Currently the TPM counter label is hard-coded. By changing it to a
variable in this function we can reuse all of the TPM counter functions
to create other monotonic counters in the TPM (if the hardware supports
it) with custom labels.
