Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase

On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski <s.adaszewski@gmail.com>
wrote:

> Dear All,
>
> Could you please guide me so that we can together integrate
> the following piece of work into the FreeBSD base system?
> Thank you for your time and consideration.
>

See below for some advice.

I have created the following bundle of work [1]. The referenced
> patch implements on top of releng/13.0, the support for TPM2
> in the EFI bootloader and in the kernel in order to allow for
> storage and retrievel of a GELI passphrase in a TPM2 module,
> secured with a PCR policy.
>
> The way the bootloader behavior is modified is the following:
>
> 1) before calling efipart_inithandles() an attempt to retrieve the
> passphrase from a TPM2 module might be performed -
> how this is achieved is described later on.
> 2) if a passphrase is indeed retrieved, then after determining
> currdev, the currdev is checked for the presence of a
> /.passphrase_marker file which must contain the same passphrase
> as retrieved from the TPM. This is supposed to ensure that we
> do not end up booting an environment not on the device we just
> unlocked with the passphrase.
> 3a) If all is go, the autoboot_delay is set to -1 in order to prevent
> any interaction and continue the boot process of the "safe" environment,
> a 'kern.geom.eli.passphrase.from_tpm2.passphrase' variable is set
> to the passphrase from TPM in order for kernel use later, as well as a
> kern.geom.eli.passphrase.from_tpm2.was_retrieved'='1' variable.
> 3b) If the passphrase marker does not match, the bootloader cleans up
> GELI keys, the TPM passphrase and kern.geom.eli.passphrase and exits.
>

I worry about information disclosure having the pass phrase available on
the running system with this setup. Can you explain why that design point
was selected? Usually there is something signed with a private key that the
public key can be used to verify instead of a direct comparison like this
to prevent disclosure of key material. I've not looked at the code yet, so
it may already do this...

The way the kernel behavior is modified is the following:
>
> 1) In init_main.c, after vfs_mountroot() a check is added
> 2a) If kern.geom.eli.passphrase.from_tpm2.was_retrieved is not
> set to 1, then we do nothing and continue the boot process
> 2b) If the was_retrieved variable is set to '1' then we check for the
> same passphrase marker as the bootloader, its content compared
> against the 'kern.geom.eli.passphrase.from_tpm2.passphrase'
> variable.
> 3a) If all is go, the passphrase variable is unset and the boot process
> continues,
> 3c) If the passphrase marker does not match, we panic.
>

I'm sure that main_init should not know about geom or geli. This is usually
done with a handler of some sort so the mountroot code can just call the
generic handler. Can your code be restructured such that this is possible?
The reason I ask is that ZFS supports encryption too and it would be nice
to use that instead of geli.

The configuration of the bootloader for this procedure looks the following:
>
> 1) We set an efivar KernGeomEliPassphraseFromTpm2NvIndex
> to contain the TPM2 NV Index we store our passphrase in, e.g. 0x1000001
> 2) We set an efivar KernGeomEfiPassphraseFromTpm2PolicyPcr
> to contain the PCR policy used to secure the passphrase, e.g.
> sha256:0,2,4,7
> 3a) If both are set, the bootloader will attempt to retrieve the passphrase
> and behave in the modified way described above
> 3b) Otherwise, it behaves as the vanilla version and will ask for GELI
> passphrases if necessary
>
> The configuration of the TPM and the passphrase marker looks the following:
>
> 1) echo -n "passphrase" >/.passphrase_marker
> 2) chmod 600 /.passphrase_marker
> 3) tpm2_createpolicy -L policy.digest --policy-pcr -l sha256:0,2,4,7
> 4) tpm2_nvdefine -Q 0x1000001 -s `wc -c /.passphrase_marker` -L
> policy.digest -A "policyread|policywrite"
> 5) tpm2_nvwrite -Q 0x1000001 -i /.passphrase_marker -P pcr:sha256:0,2,4,7
>
> [1]
> https://github.com/sadaszewski/freebsd-src/compare/releng/13.0...tpm-support-in-stand


This sounds cool. Any chance you can rebase this to the tip of the main
branch? All code goes into FreeBSD that way and 13.0 is about a year old
already.

Thanks for sharing this. Despite some reservations expressed above, I think
this has potential to be quite cool.

Warner


> Kind regards,