• 0 Posts
  • 49 Comments
Joined 3 years ago
cake
Cake day: June 15th, 2023

help-circle

  • given that Secure Boot prevents any modification of your computer’s boot chain

    Secure Boot does no such thing. All it does it require that everything in the boot chain is signed by a trusted cert.

    Binding TPM PCR7 to FDE (or more brittle options like 0+2+4) is really what protects against boot chain modifications but that’s another topic.

    Disabling SB to install the distro, then re-enabling it once installed with either maintainer-signed shim or self-signed UKI/bootloader is perfectly fine.


  • You need both FDE and Secure Boot, ideally with FDE using a TPM with PIN and PCR 7+15=0. FDE without SB can be trivially boot-kitted and obviously SB without FDE is mostly pointless. Maybe for a server/desktop behind locked doors you don’t worry as much, but for a laptop you absolutely should. Also it’s really easy in Arch to resign the UKI with sbctl via a pacman hook whenever the kernel is updated so there’s no good reason not to use it.

    If you’re relying on a LUKS password only, it can be brute-forced. To protect against that you need a decently long password which is annoying to type every boot. A short TPM PIN sealed by SB protecting LUKS is both more convent and more secure.

    Finally, if an attacker or malware gets root, FDE isn’t protecting you either.


  • Yeah this is an issue but not a big one. Most distro’s installation media don’t use shim so you have to disable SB during install anyway.

    And installing the 2023 KEK and db certs can be done via firmware without much trouble or you can use sbctl in setup mode which I believe has both the 2011 and 2023 keys.

    If you dual boot Windows you’ll want to update it to the new bootmgr signed with the 2023 keys and add the 2011 certs to dbx to protect against BlackLotus or let Windows do it via patches+regfixes.

    Also know that any changes to PK, KEK, dB, or dbx will change the PCR 7 measurement so handle that accordingly if you use TPM unlock for FDE.







  • Microsoft uses TPM PCRs 7+11 for BitLocker which is more secure than the Linux implementations mentioned in the article.

    PCR 7 is the Secure Boot measurement which means it can’t be unlocked unless every signed boot component has not been tampered with up to the point of unlock by the EFI bootloader. PCR 11 is simply flipped from a 0 to a 1 by the bootloader to protect the keys from being extracted in user land from an already booted system.

    The article is correct that most Linux implementations blindly following these kinds of “guides” are not secure. Without additional PCRs, specifically 8 and 9 measuring the grub commands (no single-user bypass) and initrd (which is usually on an unencrypted partition), it is trivial to bypass. But the downside of using these additional PCRs is that you need to manually unlock with a LUKS2 password and reseal the keys in TPM whenever the kernel and or initrd updates.

    Of course to be really secure, you want to require a PIN in addition to TPM to unlock the disk under any OS. But Microsoft’s TPM-only implementation is fairly secure with only a few advanced vulnerabilities such as LogoFAIL and cold boot attacks.






  • An SSO-like payment system with tracking and revocation is a great idea and would be amazing for us consumers. I’m just not holding my breath waiting for the corpos to implement it.

    While nowhere near perfect (far from it, really), as long as the sites you are shopping on are PCI-compliant (most should be), you don’t have to worry too much about a compromised site leaking your payment details for use elsewhere.

    Basically just use a password manager and don’t worry about saving credit card (NOT debit card) details in the site as long as they aren’t extra-sketchy.