From nobody Sat Nov 27 18:02:42 2021 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1BA4F18A90AB for ; Sat, 27 Nov 2021 18:02:24 +0000 (UTC) (envelope-from khng300@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4J1fb4041kz4S9g for ; Sat, 27 Nov 2021 18:02:24 +0000 (UTC) (envelope-from khng300@gmail.com) Received: by mail-lf1-x12d.google.com with SMTP id bu18so32733896lfb.0 for ; Sat, 27 Nov 2021 10:02:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BAPtZG0quRtHJZ9ZAWfD9Zm6o4S9wua3Jhbph50Cwk0=; b=RbRchqWXdNf7rb4dLhvChiFhK13xDk0OmdXxMDwo36F4wWZ8pSOuSKsyJn06TlrF46 y+26lCrGS0aLU9AFObimCayg9zdORguMeHOuEx+u72Uv/CJvMak67w89t11+dWtkDvPm CdYqDgN6BHMOjZ6tFRS4blG4wIbd4ilrt5Y6cgQUnMx8nkHgW7PXu6Pig98xkg8rMbLY FMPdlj+YHpqPOft/qNO+nXeFedIueMVrJmtMtu+Dsyx6rRg53e8jd5cT3bzpQ/Yu0VEK PZCXMzM4Mwmvy5Ih5j5B7hYN90s7U14mcM2mQ/8G3JFeUfNV2ECP3T0lCGVp1DR+XrW9 lBVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BAPtZG0quRtHJZ9ZAWfD9Zm6o4S9wua3Jhbph50Cwk0=; b=SwBaGBRFWDew3hefhmC13wz4nWsltS/PeCB5nl/Ja4fmzsNRKLA2Fb5wKAGri/0Ex4 NX62jy19CkVcxUu2I8a1NLvlkuhQZlrcjiriLnIUmxnE6zjMpeXkimxXdLvnKFWViG04 pWT+mnV8Ry8tEt1Ivb8+DHzrw4K0VxqgDbsFoYJApQaiFRwYFcABodv4NtQ1wSzNbxSl Smo/BBY+QUUXNSM5VRVPtmZVYDLBk6jXzXC3nJkEdizCt7xcf0h6YM7sWOU6F0JlwvMZ M/BD6EsCHElCwfuV2Fk3kkPE3P5HGqVN8PGcs2qeD70GsjItAukW6A6/+Iu0ckqnhJ5o 0uSA== X-Gm-Message-State: AOAM5329GmPRSSjN/rMl9MEWgcSfe6+E6RUhtnvVv99bcBtJJwer9pUX lgNAngZCdSMcIyMKPiwBvFnE1J+0GUQK/ftXGqg= X-Google-Smtp-Source: ABdhPJzLbSMRgoQsLn5RscWQhcIDdq/yWzyfcruVVag5xOjPbJu9qfLgVdYtWRLII4uKzfaNdCEC/53g118PBVZAeWc= X-Received: by 2002:a19:770a:: with SMTP id s10mr39073217lfc.234.1638036142653; Sat, 27 Nov 2021 10:02:22 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Ka Ho Ng Date: Sat, 27 Nov 2021 13:02:42 -0500 Message-ID: Subject: Re: TPM2 Support in bootloader / kernel in order to retrieve GELI passphrase To: Warner Losh Cc: Stanislaw Adaszewski , FreeBSD Hackers Content-Type: multipart/alternative; boundary="00000000000069870e05d1c902f7" X-Rspamd-Queue-Id: 4J1fb4041kz4S9g X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000069870e05d1c902f7 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 27, 2021, 12:00 Warner Losh wrote: > On Sat, Nov 27, 2021, 7:36 AM Stanislaw Adaszewski > > 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--