y'know i'm convinced the microsoft surface's red "secure boot off" banner is just there to annoy people using operating systems other than windows. by the time you see the banner it's already too late to turn the computer off before it starts executing the 👻 non microsoft-signed code!!! oooo! 👻 (unless your battery is so degraded or just gone making unplugging it shut down)
@thememesniper i think its there the same reason bootloader unlock screens are there: to warn you that Things Might Not Be Right in the case of an evil maid attack
(also several linux distros are allowed secure boot so any conspiracy about "just to annoy non-windows users" is out the window)
@chfour@ipg i'm not really familiar with how the TPM interlocks with windows bitlocker yet, does your user account password also unlock the bitlocker partition?
@thememesniper@ipg afaik bitlocker gets unlocked by a key in the tpm and the tpm will only "unseal" the key after the checksums of everything (even stuff like hardware configuration) match the checksums inside the tpm. the key is also sent in plaintext to the cpu but thats another thing
in this case bitlocker would just fail to unlock bc the tpm would refuse to hand the key over. i kinda meant a scenario in which you're not relying on the tpm, in that case theoretically someone could replace the initramfs (or even the kernel) and make it do malicious stuff after disks have been unlocked manually
so a TPM unseal requires the used TPM state (the PCRs used to seal the key) to be exactly the same as when the key was sealed. if it's not then the TPM will just return error.
when secure boot is disabled, bitlocker on the OS device uses PCRs 0,2,4,11, that's the UEFI firmware itself; option ROMs; the loaded bootloader; and a PCR that gets a cap event extended when bootmgr hands off to the next stage so only bootmgr can unseal the VMK from the TPM
when secure boot is enabled, it uses PCRs 7, 11. PCR 7 is the state of secure boot, the data measured to it includes whether secure boot is enabled at all; if any hardware debuggers were enabled (some systems forgot to do this); the content of dbx (the denylist of certs and hashes); and the values from db (the allowlist of certs and hashes) that were used to allow the binaries that have executed. and PCR 11 is the same as before.
additionally, when secure boot is disabled, the bitlocker metadata on disk contains hashes of allowed second stage bootloaders, and the known boot manager configuration, so if any of that gets changed, the key gets unsealed initially but then wiped from memory by bootmgr later when those hashes are checked. (none of this is done when secure boot is enabled! and there are known bugs in older bootloaders that can be used to dump bitlocker keys!)
...so really if you're using TPM-only bitlocker, you have to do some manual registry configuration to get it to always use the more secure "legacy" integrity validation, alongside setting it to use a combination of both sets of PCRs: 0, 2, 4, 7, 11. alongside making sure your system is updated.
and even then you're still vulnerable to hardware attacks (sniffing the LPC bus, glitching AMD PSP for the non-pluton fTPM implementation, just enabling the hardware debugger on some systems because they forgot to measure an event to the TPM when that's enabled)
there's a reason MS specifically says "use TPM+PIN at least", not that it helps anyone using home edition where TPM-only and recovery key are the only allowed key protectors.
also, automatic bitlocker is a thing, which has caused actual data loss on dbx updates in the past. i've been told they've actually fixed that issue since.
also, about secure boot: excuse me while i laugh hard at the state of the windows bootloader
Add comment