-coreboot support of TPM v2.0 (shared config for TPM2 support across all 4 previous variations)
-swtpm set to be launched under TPM v2.0 mode under board config
-Documentation file under each board.md softlinks to qemu-coreboot-fbwhiptail-tpm1.md (which has been generalized)
This is skeleton for TPM v2 integration under Heads
-------------
WiP
TODO:
- libcurl cannot be built as a tpm2-tools dependency as of now not sure why. curl currently needs to be added in board config to be built
- Note: tpm-reset (master and here) needs some review, no handle of no tpm use case. Caller is responsible to not call it otherwise does nothing
- init tries to bind fd and fails currently
- Note: Check if whiptail is different of fbwhiptail in clearing screen. As of now every clear seems to be removed, still whiptail clears previous console output
- When no OS' /boot can be mounted, do not try to TPM reset (will fail)
- seal-hotpkey is not working properly
- setting disk unlock key asks for TPM ownership passphrase (sealing in NV requires ownership, but text is misleading user as if reowning TPM)
- We should cache input, feed tpm behind the scene and wipe passphrase and state clearly that this is TPM disk unlock kye passphrase.
- primary key from TPM2 is invalid most of the time from kexec-select-boot and verifying global hashes but is setuped correctly at disk unlock key setup
- would be nice to take advantage of bash function tracing to understand where we are for debugging purposes, code takes ash in consideration only
- tpmr says it implements nv calls but actually doesn't. Removing those falsely wrapped functions would help.
- Implementing them would be better
- REVIEW TODOS IN CODE
- READD CIRCLECI CONFIG
Current state:
- TPM unseal works without disk unlock key and generates TOTP properly (was missing die condition at unseal to not produce always good TOTP even if invalid)
- TPM disk encryption key fails. Hypothesis is that sealing with USB drivers loaded and measures in inconsistent with sealed with/without.
- TPM disk unsealing happens without USB modules being loaded in non-HOTP setup. This fails.
- Current tests are with fbwhiptail (no clear called so having traces on command line of what happens)
- Testing with HOTP implementation for sealing/unsealing since that forces USB module loads on each boot to remove this from failing possibilities
- Add TRACE function tracing output under etc/functions, depending on CONFIG_ENABLE_FUNCTION_TRACING_OUTPUT enabled in board configs
- Replace current DEBUG to TRACE calls in code, reserving DEBUG calls for more verbose debugging later on (output of variables etc)
- add 'export CONFIG_ENABLE_FUNCTION_TRACING_OUTPUT=y' in qemu-coreboot(fb)whiptail-tpm1(-hotp) boards to see it in action
If /boot isn't mounted, we can't read the HOTP counter, so no
point in reading from the TPM. This speeds up getting to the
main menu in the case of an inaccessible or non-existant /boot.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
If /boot isn't mounted, we can't read the HOTP secret, so no
point in reading from the TPM. This speeds up getting to the
main menu in the case of an inaccessible or non-existant /boot,
and maintains the warning condition from not being able to
validate the HOTP.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
Because of the way unseal-hotp is called from gui-init,
dropping to a recovery shell when failing to mount /boot
causes it to hang, leaving the user stranded until they
kill it with CTRL+C. Instead, simply return and continue
to the main GUI menu where the user can address the problem.
Rename the function to clarify difference from other versions
of mount_boot() which do drop to the recovery shell.
Signed-off-by: Matt DeVillier <matt.devillier@puri.sm>
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.
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.
