Date: Sat, 27 Nov 2021 13:02:42 -0500 From: Ka Ho Ng <khng300@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Stanislaw Adaszewski <s.adaszewski@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase Message-ID: <CANnchUaBspVqEzuSBr2Mxx%2BE7J-OPFqdgjkhsbbD_MGtGP-oBg@mail.gmail.com> In-Reply-To: <CANCZdfphx9ZwL4j1deR9LLMBTatqVH%2B_PtkGp8ReQtWzp6T24Q@mail.gmail.com> References: <CADxsEsRbt6xj1TOHVMMC3jhT%2BCfqZqX479JvdNyM31eAQh1%2BtA@mail.gmail.com> <CANCZdfphx9ZwL4j1deR9LLMBTatqVH%2B_PtkGp8ReQtWzp6T24Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--00000000000069870e05d1c902f7 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 27, 2021, 12:00 Warner Losh <imp@bsdimp.com> wrote: > 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 > I did not read into the code yet, but in my opinion the usual way to perform this is by utilizing TPM measurement taken place in different boot stages. Only when things matches the TPM should unseal the sealed key lying somewhere in either GELI's key slot or ZFS's corresponding part. I agree the passphrase marker looks weird in the first place as we are never supposed to present this file in file system namespace if possible. I am not even sure if such protection is really necessary in the first place. > > > [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, Ka Ho > --00000000000069870e05d1c902f7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANnchUaBspVqEzuSBr2Mxx%2BE7J-OPFqdgjkhsbbD_MGtGP-oBg>