tlaurion
commented
4 years ago @mikebdp2
Compared to a Linux kernel which is currently used by heads, SeaBIOS has a much smaller source code/binaries - means, a significantly smaller attack surface and less space consumed in CBFS - and yet SeaBIOS supports a TPM.
As answered in the other tickets you opened, Heads addressed threat model is to use the TPM as early as possible to establish attestable root of trust to be able to measure coreboot itself from coreboot romstage cache, where other propositions requires all the chain to be trusted to be able to take any measurements of later steps. Here, relying in seabios using TPM to measure anything would be forward measurements, while firmware itself could have been compromised already, meaning only what is going to be trusted to launch operating system can be validated forward, not validating earlier prior stages, which are considered required to an established RoT. Heads is already criticized for not using ACM/TXT in its root of trust(coreboot being measured by the CPU so the root of trust cannot be hacked), going SEABIOS would be considered a regression to the project in that sense.
Linux kernel flashed into a BIOS chip as a heads payload - is quickly outdated, so the people have to choose between constantly updating it or sacrificing some security.
Heads is used as a static root of trust in this scenario. No unnecessary modules are in the monolitic kernel and additional modules needs to be loaded prior of use, modifying the TPM measurements by calling a insmod wrapper, which extends TPM measurements to invalidate what is later used to secure the boot process. and used in TOTP/HOTP. If the PCRs do not match, TOTP/HOTP default boot won't match and fail.
Heads relies on cryptsetup, gpg2, kernel cryptomodules, lvm and kexec basically, to offer what it offers. When a user defines a boot default and decides to create a Disk Unlock Key to unlock LUKS encrypted container, the TPM measurements are used in combination with TPM measured LUKS header, sealed inside of the TPM NVRAM space, to generate a new LUKS key which is added in the LUKS header. The released key stored in password protected NVRAM space can only be released if TPM measurements are valid, LUKS header is valid and Disk Unlock Key typed to unlock NVRAM space is valid. Consequently, the default boot can only launch if the Disk Unlock Key is typed on that computer, protecting the user from video recorded LUKS passphrase being typed in public space, so that a bad actor cannot simply clone SSD in 15 minutes and decrypt content at leasure at a later time.
Also, SeaBIOS supports booting the LZMA-compressed floppy-based hobby OS like KolibriOS or FreeDOS added to CBFS, which provides some really interesting capabilities: i.e. add a KolibriOS https://kolibrios.org/ (tiny opensource OS written on ASM, with GUI and lots of apps all inside a 1.44MB) - and if it supports your Ethernet controller: you can browse the Internet with a simple web browser, or have a secure chat with your friends using a IRCC client with a custom encryption mod like http://board.kolibrios.org/viewtopic.php?t=3734 - all under a simple OS.
That may be interesting for #590
Which doesn't suffer from the vulnerabilities of a complex OS like Linux, with SystemD (https://linux.slashdot.org/story/17/07/29/1647255/systemd-named-lamest-vendor-at-pwnie-security-awards) and - even if you choose something like Void (runit) or Artix (OpenRC) to avoid a SystemD - still many other issues.
Yet again, Heads linux payload is secured by the TPM in the sense that once the user decides to drop in recovery shell to go interactive, TPM measurements are extended and TPM measurements cannot be used to launch default boot options either.
SeaBIOS source code is relatively tiny (just ~50k code lines, compared to Linux kernel's ~27.8 million or Tianocore's ~1 million) and really easy to modify, as I've proved with some custom mods like https://review.coreboot.org/c/coreboot/+/32351
@osresearch Do you think, given that SeaBIOS supports a TPM and consumes much less space in CBFS, a custom fork of SeaBIOS with some additions could become a better payload for heads?
The current avenue is to drop custom patch and rely on coreboot VBOOT+Measured boot to rely on upstream coreboot in the future. Relying on SEABIOS might be interesting if user is willing to drop librem-hotp-validation, Disk Unlock Key usage and verified boot components currently scripted inside of Heads. But the current roadmap, on my side, is a bit different: https://fosdem.org/2020/schedule/event/firmware_hodorateatria/
- This relies on Heads with an early established root of trust in romstage, not on payload.
- This relies on having the possibility of verifying the complete ROM, including its binary blobs (Gbe, ME, IFD, coreboot, user injected keys for verified boot, payload and even encrypted disk LVMs to permit factory restore)
- Rely on injected user public key to enforce verified boot on externally signed /boot digest prior to kexec boot from currently trusted linux payload. And reuse measured public keys to extend the atestation capacilities of Heads to also validate OEM disk image state (content of LVMs inside of cryptsetup-reencrypted LUKS container prior of device to be reowned by reownership)
- Push things forward and commit to it
The current trust lanscape is: We have to trust firmware (currently just CBFS BIOS region, I think we need to extend that to whole SPI unlocked region, including other blobs). Then, coreboot measures also with TPM the payload, which contains the tools requires to establish the rest of the trust (sha256sum, gpg, kexec, lvm, cryptsetup... and flashrom, altogether. Else, what is telling you that the firmware you are going to upgrade to, internally, is good (good being signed, integrity validated). Then what tells you that your flashrom, that you use to go TPM-less with Nitrokey/Librem Key, was not tampered with to verify (backup and measure with precedent tools named)? TPM-less is also a stalled project ATM.
Linux payload is minimally trusted right now. Like said previously:
- a call to recovery extends TPM and invalidates measurements..
- depending on Librem Key/ Nitrokey requires usb modules already being loaded which comes with its subset of risks
- insmod is a wrapper to busybox insmod
- The whole gui-init or generic-init is a jailed in user experience. Going "in" linux payload invalidates root of trust by calling recovery above
- Linux as a payload is trusted in the sense that it is used to support required hardware of a mainboard. For example, I will need to update the kernel to support later board versions which replaced their sdcard reader from Ricoh to Realtek, which is not provided in modules options of the actual kernel. Other then that, vulnerabilities that can be used to attack from withing the recovery shell would modify /boot content, which would be invalidated by externally signed digests verified against public key inside of CBFS measured by TPM, or attempt to gain persistence by modifying the ROM itself, which would be catched by TPM early measurements and invalidate default boot or remote attestation through TOTP/HOTP. Note that the same logic is applied when verifying bootable ISOs against detached signed ISOs for supported distributions. First firmware is remotely attested. Then when use wants to boot ISO on removable media, ISO is verified against public keys, and if verified, GRUB configuration is proposed for user to boot. Here again, Heads was criticized in the past for TOCTU, since the ISO itself is not copied in ram prior of verifying integrity prior of booting from it. Critics implied that content of sdcard could change between moment of verification and boot from it, just like what is actually enforced also in the verified boot part relying on GPG to enforce verified boot. SEABIOS would also be a regression on that point.
Thanks for challenging the situation. I think other questions will be more specific and they are more then welcome!
paulmenzel
mikebdp2
Compared to a Linux kernel which is currently used by heads, SeaBIOS has a much smaller source code/binaries - means, a significantly smaller attack surface and less space consumed in CBFS - and yet SeaBIOS supports a TPM. Linux kernel flashed into a BIOS chip as a heads payload - is quickly outdated, so the people have to choose between constantly updating it or sacrificing some security.
Also, SeaBIOS supports booting the LZMA-compressed floppy-based hobby OS like KolibriOS or FreeDOS added to CBFS, which provides some really interesting capabilities: i.e. add a KolibriOS https://kolibrios.org/ (tiny opensource OS written on ASM, with GUI and lots of apps all inside a 1.44MB) - and if it supports your Ethernet controller: you can browse the Internet with a simple web browser, or have a secure chat with your friends using a IRCC client with a custom encryption mod like http://board.kolibrios.org/viewtopic.php?t=3734 - all under a simple OS. Which doesn't suffer from the vulnerabilities of a complex OS like Linux, with SystemD (https://linux.slashdot.org/story/17/07/29/1647255/systemd-named-lamest-vendor-at-pwnie-security-awards) and - even if you choose something like Void (runit) or Artix (OpenRC) to avoid a SystemD - still many other issues.
SeaBIOS source code is relatively tiny (just ~50k code lines, compared to Linux kernel's ~27.8 million or Tianocore's ~1 million) and really easy to modify, as I've proved with some custom mods like https://review.coreboot.org/c/coreboot/+/32351
@osresearch Do you think, given that SeaBIOS supports a TPM and consumes much less space in CBFS, a custom fork of SeaBIOS with some additions could become a better payload for heads?