2 ms·

Secure boot doesn't encrypt, secure boot only signs.

by _cenw 1y ago

lillecarl 1y ago
But it's very much a part of boot verification to unlock a TPM with your encryption keys on it.
- craftkiller 1y ago
  You're conflating secure boot with measured/verified boot.
  - lillecarl 1y ago
    They don't work in tandem? I enable secureboot with sbctl(securebootctl) and enroll keys in a TPM using the same tool as far as I can remember. Or is this just some technical detail that in practice is under the same tools and settings?
    - jeroenhd 1y ago
      By default, the secure boot status is part of the TPM registers that are used to unseal the encryption key for your drive. That's because if you disable secure boot, or reconfigure it with different keys, any bootloader could just replay measurements from a normal Linux system to the TPM and unlock your drive. If you want, you can pick a different set of registers to use. The Arch wiki has a bunch of them: https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers https://wiki.archlinux.org/title/Trusted_Platform_Module#Acc... Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same. Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.
    - craftkiller 1y ago
      In addition to the great answer by jeroenhd, you also might have encrypted your secure boot signing keys with your TPM. This has the advantage that your signing keys can't be stolen so you know that your bootloader was signed on your specific physical machine. But this is not necessary, you can just store your signing keys on your SSD or anywhere/anyway you want.

Secure boot doesn't encrypt, secure boot only signs.

by _cenw 1y ago

Secure boot doesn't encrypt, secure boot only signs.

lillecarl 1y ago

But it's very much a part of boot verification to unlock a TPM with your encryption keys on it.

craftkiller 1y ago
You're conflating secure boot with measured/verified boot.
- lillecarl 1y ago
  They don't work in tandem? I enable secureboot with sbctl(securebootctl) and enroll keys in a TPM using the same tool as far as I can remember. Or is this just some technical detail that in practice is under the same tools and settings?
  - jeroenhd 1y ago
    By default, the secure boot status is part of the TPM registers that are used to unseal the encryption key for your drive. That's because if you disable secure boot, or reconfigure it with different keys, any bootloader could just replay measurements from a normal Linux system to the TPM and unlock your drive. If you want, you can pick a different set of registers to use. The Arch wiki has a bunch of them: https://wiki.archlinux.org/title/Trusted_Platform_Module#Accessing_PCR_registers https://wiki.archlinux.org/title/Trusted_Platform_Module#Acc... Calling systemd-cryptenroll with --tpm2-pcrs would allow you to manually pick a set of options. I believe Bitlocker uses 0, 2, 7, and 11 (11 being an OS specific register rather than a spec-defined one), which is why firmware updates often make you re-enter your Bitlocker key. Some people choose to only record the secure boot state, relying on the firmware to validate its own updates and config, which means you don't need your recovery key after firmware updates as long as the secure boot state remains the same. Not taking secure boot state into account makes the entire setup rather easy to bypass, but you could do it to make your setup harder to break while still protecting against the "thief steals my SSD but not my laptop" scenario.
  - craftkiller 1y ago
    In addition to the great answer by jeroenhd, you also might have encrypted your secure boot signing keys with your TPM. This has the advantage that your signing keys can't be stolen so you know that your bootloader was signed on your specific physical machine. But this is not necessary, you can just store your signing keys on your SSD or anywhere/anyway you want.