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.
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.
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.
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.
Wrapping text to 80 characters works but due to font size and padding
the maximum 80 character lines start to get truncated. Extending the
window to 90 characters will resolve this.
While the whiptail program wraps text appropriately based on column
size, the fbwhiptail program doesn't, leading to text that scrolls off
the window where it can no longer be read. This change wraps the longer
text output so it all fits.
Since fbwhiptail allows us to customize the background colors, we should
colorize warnings and error messages to provide a user with an
additional subtle cue that there might be a problem. I have added two
additional configuration options:
CONFIG_WARNING_BG_COLOR
CONFIG_ERROR_BG_COLOR
and in the librem13v2.config file you can see an example for how to set
them to be yellow and red gradients, respectively. I've also updated the
main two scripts that use whiptail to include those background colors.
If you decide to use regular whiptail, just don't set these config
options and it should behave as expected.
Part of the Heads workflow involves handling legitimate changes to /boot
as part of the package manager. This is a challenging workflow to handle
as package managers on many systems work in a completely unattended way
(and some even reboot first, apply updates, and then reboot again).
We need to be able to detect changes that are potentially caused by a
package manager so to do that I've set up a trigger within the OS
(currently just for Debian) that runs both before and after package
updates. It verifies the signatures in /boot and if they fail before
package updates it creates a log file in
/boot/kexec_package_trigger_pre.txt. If they fail after package updates
run /boot/kexec_package_trigger_post.txt is created. These files contain
the following fields:
CHANGED_FILES: A list of files in /boot that failed the sha256sum check
UPDATE_INITRAMFS_PACKAGE: An (optional) list of packages known to
trigger initramfs changes
Following those fields is a list of log output from the last package
manager run which contains its own formatted fields (I'm pulling from
/var/lib/dpkg/info).
When a user selects a boot option, gui-init first verifies the
checksums just to catch errors before calling kexec-select-boot. If
there are any errors it looks for these package logs and if they exist,
it displays appropriate warnings. If the files are absent it displays a
more generic warning. The user is also given an opportunity to re-sign
the /boot hashes.
The number of options we want in the menu is starting to get large
enough that it's worth slimming things down in the main menu and move
options to nested menus. Along with this nested menu change is the
option to re-sign and re-hash files in /boot directly from the menu.
One of the other core functions a user needs when bootstrapping is
taking over the TPM. I've added a new option in the menu for this and it
revealed that some of the menus needed more space so I've widened all
the menus and also made the main menu longer so the options don't
scroll.
The point of this change is to provide a failsafe (failunsafe?) mode for
less technically-savvy users who will ultimately be using Heads by
default on Librem laptops.
There are some scenarios where an end user might forget to update hashes
in /boot after an initrd change or might have some other hash mismatch.
Currently that user would then be stuck in a recovery console in Heads
not knowing what to do within that limited shell environment to fix the
situation.
This change adds a 'force' mode to kexec-select-boot that goes straight
into a boot menu and bypasses the hash checks so the user could more
easily get back into their system to attempt to repair it. It adds
appropriate warnings about why this is a risky option and moves it down
toward the bottom of the menu. The goal would be to just have this be an
emergency option our support could guide a user to if they ended up in
this situation.
In particular I added a GUI menu to instruct the user if there is no
TOTP code registered (as is the case upon first flash) and also added
better handling of the case the user selects 'default boot' when there
is no default boot set yet. Apart from that where there were text-only
menus left in gui-init I've replaced them with GUI menus.
When selecting the boot menu option (m) in the gui-init you call out to
kexec-select-boot. To better maintain the graphical menu experience,
I've added a -g option to kexec-select-boot that, when set, will use a
graphical whiptail menu for the most common menu selection modes.
This is a modified version of the generic-init script that uses whiptail
to generate a graphical menu. I changed two of the options so that the
user can refresh the menu to get an updated TOTP code if needed.
