Currently Heads relies on a hard-coded config value to determine which
USB disk to mount. This can be problematic when trying to distribute a
pre-built version of Heads that can work on multiple disk
configurations. I've modified the USB mounting script so that it
attempts to detect all USB boot disks present on the system, pick sane
defaults, and prompt the user when there are multiple choices.
I've also removed the USB configuration option from config-gui.sh as
this config option is no longer used.
It makes more logical sense for GPG functions to be split out into their
own menu instead of being part of the "Flash" menu. This creates a
gpg-gui.sh script and moves GPG options there while adding a few
additional features (like listing keys and initial smartcard key
generation support).
key-init makes sure trustdb is updated at run time and user and distro keys are ultimately trusted. Each time a file is signed, the related public key is showed without error on it's trustability.
flash-gui deals with gpg1 to gpg2 migration. If pubring.kbx is found, pubring.gpg is deleted from running rom dump.
.ash_history: add examples to generate keys and otrust in rom
flash-gui: export otrust and import it in rom
key-init: import otrust.txt if present to supress warning about user public key being untrusted
We need to handle the case where the specific config file doesn't exist,
or else grep fails, so we touch the file ahead of time. Mounting the usb
storage caused problems when you re-enter the menu a second time, so we
will just load the storage module.
As part of the config gui we want to be able to have the system define
new config options without them being lost if the user makes their own
changes in CBFS. To allow that this change creates a function initiated
in init that combines all /etc/config* files into /tmp/config. All
existing scripts have been changed to source /tmp/config instead of
/etc/config. The config-gui.sh script now uses /etc/config.user to hold
user configuration options but the combine_configs function will allow
that to expand as others want to split configuration out further.
As it stands here are the current config files:
/etc/config -- Compiled-in configuration options
/etc/config.user -- User preferences that override /etc/config
/tmp/config -- Running config referenced by the BIOS, combination
of existing configs
This change will add a new GUI script that will allow users to change
their running configuration (currently just /boot and USB boot options)
and optionally persist that modified configuration with reflashing the
BIOS with a modified cbfs.
The Librem coreboot is labeled with the current version and is visible
from dmidecode and is supposed to reflect the current version of
coreboot, however it was out of date and reflected 4.7 when Heads has
moved on to 4.8.1.
I've also added a simple change to further simplify onboarding by
warning users who have Librem Key configured when they boot without it
being inserted.
We want to catch the missing GPG keyring error regardless of TPM failure
or even in the case of a system without a TPM at all so we need to move
that section up above the TPM check.
To help with onboarding new users to Heads, this change will detect when
Heads does not have any keys in its keyring and will guide the user
through adding a key to the running BIOS. It's important that this
happen *before* guiding them through setting up an initial TOTP/HOTP
secret because adding a GPG key changes the BIOS, so the user would have
to generate TOTP/HOTP secrets 2x unless we handle the keyring case
first.
In addition to this change I've simplified the main menu so that the
majority of the options appear under an 'advanced' menu.
When the Librem Key is enabled, the kernel loads USB modules at boot,
this causes PCR5 to change and breaks unsealing the LUKS key (if set).
This change retains the protection of the PCR5 check unless Librem Key
is enabled.
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.
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 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.
