#168 use tpm on supported platforms

Otevřený
otevřeno před 1 rokem uživatelem vimuser · 2 komentářů
Leah Rowe okomentoval před 1 rokem

libreboot hasn't done anything with tpm historically, because it was unavailable on most/all of the hardware supported. for example the gm45/ich9m machines didn't have tpm because it's handled by Intel ME whose firmware is entirely removed on those platforms, at least in libreboot (and that is still true)

tpm isn't available on all platforms. i had an interesting discussion with Insurgoakatlauri on IRC (tlaurion on heads project github). I'll just paste the IRC chat:

(tpm probably not feasible on grub/seabios setups - heads uses it extensively in its linux-based payload setup)

19:24 <leah> yeah lb doesn't touch it at all
19:24 <leah> i genuinely don't know what it would be useful for, in our context
19:24 <leah> how does heads use it?
19:25 <Insurgoakatlauri> LB doesn't have any security proposition, not remote attestation, nor any of those prescriptions either
19:25 <Insurgoakatlauri> leah: you should try heads first I think.
19:25 <leah> that is currently a fact, yes
19:25 <leah> my priority has been simply to boot each machine
19:25 <leah> i'll play with heads then
19:26 <leah> (when i'm at the lab. not there right now)
19:26 <leah> i mean i know what tpm is, i've just never seen the value in it for linux/coreboot context
19:26 <Insurgoakatlauri> At least understand what are the differences here
19:26 <Insurgoakatlauri> coreboot initializes the TPM in the bootblock
19:27 <Insurgoakatlauri> uses the bootblock as root of trust if nothing "better" exists
19:27 <leah> historically, libreboot machines (pre-osboot-merge) have not had  a TPM
19:28 <Insurgoakatlauri> (this is our case, otherwise T440p can have ACM and sINIT blobs, required for TXT, to have bootblock in IBB to have hardware root of trust in CPU)
19:28 <Insurgoakatlauri> https://doc.coreboot.org/security/vboot/measured_boot.html#ibb-crtm
19:28 <leah> for example, on GM45 machines (X200, t400 etc) which were the focus, TPM is provided by ME firmware
19:28 <leah> and ME fw is removed on those
19:28 <leah> therefore the TPM was broken - and i therefore just never focused on it. though yes, i could probably do something with it on the newer machines
19:29 <leah> ok i'll add some notes in todo
19:29 <Insurgoakatlauri> bootblock then measures up the chain, each step measuring the next, producing TCPA log and extending PCR #2 with final measurement of coreboot up to payload. the "firmware"
19:29 <Insurgoakatlauri> Then Heads (payload) loads
19:29 <Insurgoakatlauri> measures what Heads uses to continue attestation measurements
19:30 <Insurgoakatlauri> each time a kernel module is loaded (insmod is script to measure modules in PCR5 then cann busybox insmod)
19:30 <Insurgoakatlauri> key material is extracted from CBFS to ramfs, measured first into PCR7
19:31 <Insurgoakatlauri> So those measurements can then be used and extended for other needs
19:31 <Insurgoakatlauri> PCR2 + PCR7 is sealed into TPM for remote attestation of firmware integrity.
19:32 <Insurgoakatlauri> Then user can set a disk encryption key, generated in ram and injected into LUKS as slot 1 (where disk recovery key is slot0)
19:32 <Insurgoakatlauri> This sealed secret, as opposed to the first, is sealed with both measurements and a passphrase.
19:32 <Insurgoakatlauri> Measurements also include LUKS header into PCR6.
19:33 <Insurgoakatlauri> So to unseal TPM disk unlock key, firmware (pcr2), runtime state (pcr5), user + user key material (pcr7) is sealed with TPM passphrase in another TPM NV region.
19:34 --> jacobk [jacobk] (Jacob K) (~quassel@64.189.201.150) has joined #libreboot
19:34 <Insurgoakatlauri> The goal of this, for security purposes, is to answer a simple need for many. How can I know that where I am asked to type my decryption passphrase is in a trustable state.
19:35 <Insurgoakatlauri> Heads was created to answer that need and improved on that idea since then
19:35 <Insurgoakatlauri> The moment that you enter into recovery shell, tPM extends PCR4
19:35 <leah> like i said, tpm has been unavailable to configure on hardware that libreboot historically focused on
19:35 <leah> it occurs to me only now, with your explanation, to finally look into it, because now lb supports hw that has it
19:35 <leah> i'll make notes of this
19:36 <leah> libreboot currently doesn't have any of this stuff
19:36 <leah> none of it is turned on
19:37 <Insurgoakatlauri> Recap:
19:37 <Insurgoakatlauri> remote attestation: seals firmware measurements (PCR2) recovery access state (pcr4), runtime known state level from tinted kernel state (pcr5) and user cbfs injected key + config overrides (pcr7)
19:37 <Insurgoakatlauri> TPM disk unlock key seals the above +  LUKS header integrity measurements (pcr7) into seperate nv space which can only unseals if measurements are valid and user passphrase is good.
19:38 <Insurgoakatlauri> No, because that requires a runtime environement which is not seabios or grub.
19:38 <Insurgoakatlauri> But those things change as well
19:38 <Insurgoakatlauri> I would suggest looking into AEM in development from QubesOS team + 3mdeb around trenchboot project
libreboot hasn't done anything with tpm historically, because it was unavailable on most/all of the hardware supported. for example the gm45/ich9m machines didn't have tpm because it's handled by Intel ME whose firmware is entirely removed on those platforms, at least in libreboot (and that is still true) tpm isn't available on all platforms. i had an interesting discussion with Insurgoakatlauri on IRC (tlaurion on heads project github). I'll just paste the IRC chat: (tpm probably not feasible on grub/seabios setups - heads uses it extensively in its linux-based payload setup) ``` 19:24 <leah> yeah lb doesn't touch it at all 19:24 <leah> i genuinely don't know what it would be useful for, in our context 19:24 <leah> how does heads use it? 19:25 <Insurgoakatlauri> LB doesn't have any security proposition, not remote attestation, nor any of those prescriptions either 19:25 <Insurgoakatlauri> leah: you should try heads first I think. 19:25 <leah> that is currently a fact, yes 19:25 <leah> my priority has been simply to boot each machine 19:25 <leah> i'll play with heads then 19:26 <leah> (when i'm at the lab. not there right now) 19:26 <leah> i mean i know what tpm is, i've just never seen the value in it for linux/coreboot context 19:26 <Insurgoakatlauri> At least understand what are the differences here 19:26 <Insurgoakatlauri> coreboot initializes the TPM in the bootblock 19:27 <Insurgoakatlauri> uses the bootblock as root of trust if nothing "better" exists 19:27 <leah> historically, libreboot machines (pre-osboot-merge) have not had a TPM 19:28 <Insurgoakatlauri> (this is our case, otherwise T440p can have ACM and sINIT blobs, required for TXT, to have bootblock in IBB to have hardware root of trust in CPU) 19:28 <Insurgoakatlauri> https://doc.coreboot.org/security/vboot/measured_boot.html#ibb-crtm 19:28 <leah> for example, on GM45 machines (X200, t400 etc) which were the focus, TPM is provided by ME firmware 19:28 <leah> and ME fw is removed on those 19:28 <leah> therefore the TPM was broken - and i therefore just never focused on it. though yes, i could probably do something with it on the newer machines 19:29 <leah> ok i'll add some notes in todo 19:29 <Insurgoakatlauri> bootblock then measures up the chain, each step measuring the next, producing TCPA log and extending PCR #2 with final measurement of coreboot up to payload. the "firmware" 19:29 <Insurgoakatlauri> Then Heads (payload) loads 19:29 <Insurgoakatlauri> measures what Heads uses to continue attestation measurements 19:30 <Insurgoakatlauri> each time a kernel module is loaded (insmod is script to measure modules in PCR5 then cann busybox insmod) 19:30 <Insurgoakatlauri> key material is extracted from CBFS to ramfs, measured first into PCR7 19:31 <Insurgoakatlauri> So those measurements can then be used and extended for other needs 19:31 <Insurgoakatlauri> PCR2 + PCR7 is sealed into TPM for remote attestation of firmware integrity. 19:32 <Insurgoakatlauri> Then user can set a disk encryption key, generated in ram and injected into LUKS as slot 1 (where disk recovery key is slot0) 19:32 <Insurgoakatlauri> This sealed secret, as opposed to the first, is sealed with both measurements and a passphrase. 19:32 <Insurgoakatlauri> Measurements also include LUKS header into PCR6. 19:33 <Insurgoakatlauri> So to unseal TPM disk unlock key, firmware (pcr2), runtime state (pcr5), user + user key material (pcr7) is sealed with TPM passphrase in another TPM NV region. 19:34 --> jacobk [jacobk] (Jacob K) (~quassel@64.189.201.150) has joined #libreboot 19:34 <Insurgoakatlauri> The goal of this, for security purposes, is to answer a simple need for many. How can I know that where I am asked to type my decryption passphrase is in a trustable state. 19:35 <Insurgoakatlauri> Heads was created to answer that need and improved on that idea since then 19:35 <Insurgoakatlauri> The moment that you enter into recovery shell, tPM extends PCR4 19:35 <leah> like i said, tpm has been unavailable to configure on hardware that libreboot historically focused on 19:35 <leah> it occurs to me only now, with your explanation, to finally look into it, because now lb supports hw that has it 19:35 <leah> i'll make notes of this 19:36 <leah> libreboot currently doesn't have any of this stuff 19:36 <leah> none of it is turned on 19:37 <Insurgoakatlauri> Recap: 19:37 <Insurgoakatlauri> remote attestation: seals firmware measurements (PCR2) recovery access state (pcr4), runtime known state level from tinted kernel state (pcr5) and user cbfs injected key + config overrides (pcr7) 19:37 <Insurgoakatlauri> TPM disk unlock key seals the above + LUKS header integrity measurements (pcr7) into seperate nv space which can only unseals if measurements are valid and user passphrase is good. 19:38 <Insurgoakatlauri> No, because that requires a runtime environement which is not seabios or grub. 19:38 <Insurgoakatlauri> But those things change as well 19:38 <Insurgoakatlauri> I would suggest looking into AEM in development from QubesOS team + 3mdeb around trenchboot project ```
Leah Rowe okomentoval před 1 rokem
Vlastník

more log

19:39 <Insurgoakatlauri> but yet again, if you do not implement those things inside of linux/bsd kernel+ initramfs, you would rely on modified grub + systemd
19:39 <Insurgoakatlauri> I highly doubt you would agree with those
19:39 <Insurgoakatlauri> This is why I invest time into heads so much.
19:39 <leah> yeah
19:39 <Insurgoakatlauri> different states of trust depending on personal beliefs and hardware enablement
19:39 <leah> i'm not eager to mess with this in grub/seabios
19:40 <leah> so it would be more practical to explore this in a linux payload
19:40 <Insurgoakatlauri> gm45: firmware RoT based on personally paid work to have flashrom enable WP properly, so that bootblock can be set to RO and have coreboot enable security through cpu measurements without TPM and sBOM
19:41 <Insurgoakatlauri> xx20/xx30: RoT in bootblock with io386 + auth.
19:42 <Insurgoakatlauri> t440p and other Haswell: add ACM + sINIT blobs for TXT RoT. As xx20/xx30, but with bootblock measured by CPU into PCR0 (only the blob can do that). This enables DRTM, and Trenchboot, to offer really good security premises that cannot be obtained on older hardware unfortunately
19:43 <Insurgoakatlauri> Where I would highly suggest you to do PoC for LB to embed xen in firmware to support BSD boot.
more log ``` 19:39 <Insurgoakatlauri> but yet again, if you do not implement those things inside of linux/bsd kernel+ initramfs, you would rely on modified grub + systemd 19:39 <Insurgoakatlauri> I highly doubt you would agree with those 19:39 <Insurgoakatlauri> This is why I invest time into heads so much. 19:39 <leah> yeah 19:39 <Insurgoakatlauri> different states of trust depending on personal beliefs and hardware enablement 19:39 <leah> i'm not eager to mess with this in grub/seabios 19:40 <leah> so it would be more practical to explore this in a linux payload 19:40 <Insurgoakatlauri> gm45: firmware RoT based on personally paid work to have flashrom enable WP properly, so that bootblock can be set to RO and have coreboot enable security through cpu measurements without TPM and sBOM 19:41 <Insurgoakatlauri> xx20/xx30: RoT in bootblock with io386 + auth. 19:42 <Insurgoakatlauri> t440p and other Haswell: add ACM + sINIT blobs for TXT RoT. As xx20/xx30, but with bootblock measured by CPU into PCR0 (only the blob can do that). This enables DRTM, and Trenchboot, to offer really good security premises that cannot be obtained on older hardware unfortunately 19:43 <Insurgoakatlauri> Where I would highly suggest you to do PoC for LB to embed xen in firmware to support BSD boot. ```
Leah Rowe okomentoval před 1 rokem
Vlastník

note: io386 and other things mentioned on discussion on 30 March 2023. i've yet to paste those logs, will paste them here when i get round to it, it's relevant to this

note: io386 and other things mentioned on discussion on 30 March 2023. i've yet to paste those logs, will paste them here when i get round to it, it's relevant to this
Přihlaste se pro zapojení do konverzace.
Bez štítku
Bez milníku
Bez zpracovatele
1 účastníků
Načítání...
Zrušit
Uložit
Není zde žádný obsah.