16 ms·

Authenticated Boot and Disk Encryption on Linux

342 points by Aissen 5y ago

weinzierl 5y ago
Only had time to skim it, but even without all the details it is an excellent overview of the state of the art regarding secure boot chain. You can learn many of the points by looking into the Android boot sequence but this is a more generic and 'everything in a single place' write-up. Especially the mechanisms behind dm-verity seem to be not widely known and - in my view- underappreciated. > *This is all so desktop/laptop focused, what about servers? I know that some of the more powerful and Linux based automotive embedded systems use a similar design. While important for desktop/laptop and servers the mentioned points are crucial for systems where physical security of the hardware is limited. Oh, and BTW, if 0pointer.net i doesn't ring a bell: The author is Lennart Poettering.
- deleted 5y ago
  [deleted]
jimsi 5y ago
https://github.com/xmikos/cryptboot/blob/master/README.md https://github.com/xmikos/cryptboot/blob/master/README.md
- Foxboron 5y ago
  I don't think a 5 year old project linked without context is appropriate when talking about modern boot chain security. It doesn't even support stubs so it fails at the first threat scenario described in this post.
  - selfhoster11 5y ago
    I disagree. UEFI boot security is not that recent, and it hasn't changed so much as to render earliest approaches less secure.
    - Foxboron 5y ago
      It is less secure. The initramfs is not signed, along with the microcode.
ulzeraj 5y ago
This thing right here makes me unconfortable. I don't want Microsoft signatures or any other company for what matter to be involved in my boot process. > The UEFI firmware invokes a piece of code called "shim" (which is stored in the EFI System Partition — the "ESP" — of your system), that more or less is just a list of certificates compiled into code form. The shim is signed with the aforementioned Microsoft key, that is built into all PCs/laptops.
- amarshall 5y ago
  Almost all UEFI firmware allows replacing the default public keys with your own, and then you can sign everything yourself with private keys only you possess.
  - Foxboron 5y ago
    In theory. But part of the UEFI boot chain is Optional ROM files stored on hardware. Most commonly found on dedicated graphics cards and other hardware. All of these files need to be authenticated, and currently signed by Microsoft or the OEM vendor. A modern Lenovo Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation fails for the GFX card you are essentially "soft bricking" the device since the GFX card won't work.
    - g_p 5y ago
      An idea I just had around this, for if you run your own PK/KEK/DB chain - is it feasible to "dump" these Option ROMs? If so, you should be able to whitelist their sha256 hashes in your DB database, since the DB can contain an allow-list of hashes, as well as an allow-list of public keys. I'm not familiar with how to view relevant Option ROMs, but if you can "dump" them in the format they will be verified in, you should be able to put those into your DB database. Perhaps there could even be an open/peer-vouched crowdsourced set of such DB entries maintained for popular systems?
      - Foxboron 5y ago
        sysfs doesn't like some optionroms, so using the rom files from there wont work in some cases. Apparently they can be stored in an ACPI table.. but I haven't looked at it. Another alternative is to read the TPM2 eventlog. It should record OptionROM checksums found during boot. $ tpm2_eventlog ./t14_eventlog | grep "BOOT_SERVICES_DRIVER" | wc -l 7 This is essentially what me and Trammell Hudson has been thinking about. But I don't have any available machines to test this with, and I haven't gotten around to setting up a QEMU vm to test out this theory. https://github.com/Foxboron/sbctl/issues/85#issuecomment-886539689 https://github.com/Foxboron/sbctl/issues/85#issuecomment-886...
losingom 5y ago
>Authentication of boot loaders is done via cryptographic signatures [...] the cryptographic certificates that may be used to validate these signatures are then signed by Microsoft This is what concerns me. While Microsoft are indeed dominant, surely them signing these is a conflict of interest? Why can't there be an external body that signs these, including those for Microsoft?
- dane-pgp 5y ago
  > Why can't there be an external body that signs these Just wait a few years, and it will be the government that decides which OSes can run on your hardware. Hint: It will be OSes that only allow "approved" apps to run.
- g_p 5y ago
  The "default" boot chain is using a Microsoft CA key, but you can easily change it. In fact, the "root" for your system is the platform key, which is most probably signed by your OEM. Pragmatically speaking, I'd be more worried about my OEM's platform key being compromised when someone leaks their UEFI firmware build tree through a ransomware attack or similar. The biggest issue of the Microsoft "CA root", is that they sign everything - there was a good example [1] of them signing a Kaspersky rescue CD that could effectively break the secure boot chain. The good news is you can load your own keys into your motherboard. It's only really a solution for enterprises or tech-savvy individuals, but it at least is a viable option and helps you to "own" your own platform. [1] https://habr.com/en/post/446238/ https://habr.com/en/post/446238/
- mjg59 5y ago
  > Why can't there be an external body that signs these, including those for Microsoft? There can be, and I strongly suspect Microsoft would prefer there to be - reviewing and signing all the UEFI drivers consumes significant resources. Nobody else with sufficient resources to do this job has stepped forward.
sam_lowry_ 5y ago
After taking over the process #1, Lennart Poettering decided to go deeper and take over kernel, initrd and bootloader. I sometimes wonder whether he is on the NSA payroll. Lennart Poettering and Moxie Marlinspike are two people NSA should really strive to buy and/or intimidate.
- fmajid 5y ago
  Signal is partly funded by the US government: https://www.opentech.fund/results/supported-projects/open-whisper-systems/ https://www.opentech.fund/results/supported-projects/open-wh...
  - sam_lowry_ 5y ago
    This is all totally unsubstantiated, but... Sinal's reliance on phone numbers and their point on encrypted e2e communication facilitates meta-information gathering for the governments of the world. As for Pottering, he is an old-time RedHat employee, and RedHat is supplying virtually all governments of the world.
  - selfhoster11 5y ago
    So is Tor. Is there any other reason to suspect foul play?
- deleted 5y ago
  [deleted]
- amarshall 5y ago
  > take over kernel, initrd and bootloader Huh? There are not really any Kernel or bootloader changes proposed here, just signing them and using existing functionality within them. (Okay, I guess he proposes adjusting the Kernel to optionally have a way to authenticate parameters, but is that really “taking over”?) As for initrd, he’s just talking about adjusting the way their generated to be more static and modular to simplify signing. Yes, there’s some tooling to do this proposed as part of the systemd organizational umbrella, but systemd isn’t a monolithic thing. Regardless, and just like systemd, you don’t have to use any of this if you don’t want to.
hsbauauvhabzb 5y ago
I kinda think the claims about not encrypting /use are fairly dubious. What’s to stop an attacker replacing a lib with a signed+known vulnerable lib? As far as I know there’s no mechanism for revocation. What’s to stop this occurring to the kernel and/or boot loader? Maybe the TPM but idk
- Foxboron 5y ago
  Keeping it on a seperate blockdevice allows dm-verity to authentice the device. This value would be signed and secured, so injecting a signed+known library wouldn't work. It would refuse to mount. It should be noted that keeping it unencrypted is only for the traditional linux package manager usecase.
- amarshall 5y ago
  From the article: > The OS binary resources (i.e. /usr/) must be authenticated before being booted into. (But don't need to be encrypted, since everyone has the same anyway, there's nothing to hide here.) Authentication prevents manipulation. Encryption is not necessary to do so (encryption often also authenticates).
cesarb 5y ago
On a quick skim, I could see three issues with this proposal: 1. While each home directory is individually encrypted, since /home itself is not encrypted (unlike with current uses of full disk encryption), the user login names can be found unencrypted on the disk. 2. Since each home directory is individually encrypted, backup systems like borgbackup running as root can no longer easily backup everything. 3. As far as I could understand, this proposal does not have a mechanism to share disk space between the system and the user directories. This goes in the opposite direction of for example https://fedoraproject.org/wiki/Changes/BtrfsByDefault https://fedoraproject.org/wiki/Changes/BtrfsByDefault in Fedora 33, which allowed the whole disk to be used for files in /home, instead of always reserving IIRC 50 gigabytes exclusively for files outside /home.
- Nextgrid 5y ago
  > backup systems like borgbackup running as root can no longer easily backup everything If you’re using LUKS-encrypted volumes for home directories nothing prevents you from enrolling an extra key file entrusted to the backup program, or to the TPM (which the backup program can be allowed to access).
  - kevincox 5y ago
    But that defeats the whole point as now decrypting the system is enough to access all of the home directories. You are basically back to a FDE home partition with extra complexity.
- michaelt 5y ago
  Also, once you've got per-user encryption on ~/.ssh/authorized_keys you'll need some other mechanism for users to log in. And don't think of having the users do their own backups - locking users' home directories mean they won't be able to run their own cron jobs.
  - predakanga 5y ago
    > Also, once you've got per-user encryption on ~/.ssh/authorized_keys you'll need some other mechanism for users to log in. OpenSSH supports this through the AuthorizedKeysFile directive - it'd be quite simple for the homedir mounting tool to sync that file from the user's authorized_keys file on unmount. You could also use SSH certificates, but that requires a CA - not ideal for the home user.
BiteCode_dev 5y ago
Are other people experiencing too many corruption problems on encrypted disks? I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc. Also, it's slow. I put my firefox conf folder in it, but it slows the browser down. Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.
- withinboredom 5y ago
  You probably have some fun disk caching turned on in the OS or your disk has a built in cache that it’s not properly flushing. I’ve seen this before with cheap SSDs.
  - BiteCode_dev 5y ago
    Maybe, I don't know enough about this, but I've been using this veracrypt disk on 6 machines, now, and I have the problem with each of them. Also, I don't have any problem with non encrypted data.
    - blablablub 5y ago
      Looks like a veracrypt problem then.
    - orthecreedence 5y ago
      Maybe a dumb question, but are you on windows? Check that Defender isn't scanning every single time data is written to your veracrypt drive. When I was on windows, the most painful slowdowns were almost invariably caused by Windows Defender.
- snassar 5y ago
  The better solution to these kind of problems is having a backup concept with an implementation and regular testing of backups. The encryption exposed a problem with your disks or system in general. Depending on what the problem was, the problem is still there but you are not seeing it. Now you have a possible problem and unencrypted files.
bloopernova 5y ago
Is it possible to set up an encrypted+authenticated boot that relies on a hardware token being present? In other words, only boot this OS if the Yubikey is inserted?
- kevincox 5y ago
  It definitely is. The easiest way is to set up the token in challenge-response mode (supported by yubikey). The disk has a key which is sent to the token and the response is used to decrypt the disk.
  - sam_lowry_ 5y ago
    Does not LUKS already work with Yubikeys [1]? [1] https://github.com/cornelinux/yubikey-luks https://github.com/cornelinux/yubikey-luks
    - kevincox 5y ago
      Based on the description of that repo it does exactly what I suggested you can do.
- maverwa 5y ago
  According to the docs ([0], [1]) systemd-cryptenroll and crypttab support FIDO2 and PKCS#11, both should be supported by the yubikey as well. So without having tested it: I think yes, it should generally be possible, at least for encryption. [0]: https://www.freedesktop.org/software/systemd/man/crypttab.html https://www.freedesktop.org/software/systemd/man/crypttab.ht... [1]: https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html# https://www.freedesktop.org/software/systemd/man/systemd-cry...
- nsajko 5y ago
  See my top-level comment. Just put the initrd and secret on the external device.
  - egberts1 5y ago
mschuster91 5y ago
> Some corners of the community tried (unfortunately successfully to some degree) to paint TPMs/Trusted Computing/SecureBoot as generally evil technologies that stop us from using our systems the way we want. That idea is rubbish though, I think. It's not as rubbish as the author wants to think. Just look at the current state of Android SafetyNet attestation - a myriad of apps refuse to run entirely (banking apps, games) or with reduced quality (Netflix) on unlocked bootloader / rooted systems. There are workarounds but these are a) a constant cat-and-mouse game and b) the only known workaround against online SafetyNet attestation (pretending that the device does not have a TrustZone element, forcing SafetyNet to Basic attestation) is bound to fail as soon as Google is reasonably certain that there is no hardware floating around that has the latest Android but no TrustZone element. Additionally, look at what happened to Microsoft's ARM adventures. Locked down to the point of being utterly useless, on top of MS not providing a Rosetta equivalent. The problem is that here the interests of hackers (who either want as-open-as-reasonably-possible devices or, like the author, as-secure-as-possible devices) and big corporate interests (who want to keep license holders happy like Netflix, want a way to reduce successful "my device got pwned, someone stole my money, refund me!!!" claims like banks or fight against cheaters) collide in a position that's hard to make something decent out of.
- aseipp 5y ago
  The modern Windows ARM laptops all(?) use standard x86 Secure Boot/UEFI rules, as far as I know. You can install Linux on them pretty easily; I know at least Fedora/Anaconda supports ARM64 pretty well. The bigger problems come after that but are more of the same stuff, i.e. lack of drivers for peripherals, you're dealing with Qualcomm, etc.
- no_time 5y ago
  I would LOVE tpms and every other hardware security feature if the had an user override that allows me (and only me) to control what the device does. Basically the opposite of the current and forseeable landscape.
nsajko 5y ago
An option that wasn't at all considered in the article is to have the initrd and (optionally) the secret key used for decrypting the disk on a separate device (or devices), for example on an 1 GB USB drive. This way the big disk can have full, real FDE (not LUKS). To an attacker not in possesion of the USB drive the big disk just looks like random data. And the USB drive can be kept on one's own person and easily destroyed if necessary. The main part is having the initrd on an external, small, device. The secret can be either a regular passphrase, or stored somewhere on the small device. Works fine on my Archlinux. I mount the initrd file system to /boot when I need to update it.
- selfhoster11 5y ago
  Now we are back to boot floppies of yore. Oh how the wheel of IT turns.
- SkyMarshal 5y ago
  > This way the big disk can have full, real FDE (not LUKS). I thought LUKS was the only way to do FDE in Linux. What other options for FDE are there? But yes, putting /boot on an external USB drive is the only way I know of get FDE on your hard drives. Possible with UEFI, not BIOS/MBR.
  - nsajko 5y ago
    LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-does-luks-header-contain https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.
    - lugged 5y ago
      Does this matter? I once went through the waste of time of getting /boot encrypted. Would rather avoid needless pain.
sharmin123 5y ago
The Best And Easiest Ways To Protect Yourself From Hackers: https://www.hackerslist.co/the-best-and-easiest-ways-to-protect-yourself-from-hackers/ https://www.hackerslist.co/the-best-and-easiest-ways-to-prot...
maverwa 5y ago
Running the FDE (or partial encryption) of the TPM would include the risk that a hardware defect on the mainboard would render the disks unreadable, right? Since it would be quite hard to get that key out of it. Guess thats what recovery keys are for...
egberts1 5y ago
I only wish that package maintainers (outside of OS distro) installed directly directly into /usr/local/bin but instead they wanted “in” on the /usr/bin placement. So, We lost there as this would have facilitated secondary signing of non-OS packages by OS distro. Doesn’t help when Fedora started muddling (merging) /bin and /usr/bin. So, secondary signing for non-OS vendors just went out the window. https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i... Even systemd is just now complaining about that during boot up (if the /usr partition somehow got invalidated during bootup). This multi-tiered */bin is that hallmark of Unix (and continuously the (Linux Filesystem Standard https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf ). — Althou, systemd designer seems to disagree with this LFS approach. (IMHO, he needs to look deeper into the overall aspects of package signing architecture by OS-distros, and not just for Fedora) https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... Now if Debian would just arrest the slide into a singular binary directory, all would be good. Linux Distros are about to be ignoring this future need of multi-island/multi-signing of encryption/immutability. No embedded Linux distro should want to be Windowized, much less the desktop Linux, unless they too seek this single island approach for immutably-verified/encrypted binaries of OS, vendors, and customers.
- wereHamster 5y ago
  Yeah, let's move to the complete opposite side: one /bin for each package. You can have that today, in NixOS.
  - egberts1 5y ago
    We know that package containerization (a la Apple, or NixOS) didn’t expand well either for the vendors/maintainers who want to include their products into multiples of OS distros. And currently this probably would be very difficult to implement a signed-immutable binaries with regard to multi-OS distros vs multi-vendors. So, the nice sweet convergence is probably hovering around hardware/OS/vendor grouping somewhere.
- 5y ago
MayeulC 5y ago
I haven't read the whole essay (stopped at "In detail"). So far, I agree with most of what Lennart said, it matches my analysis, except perhaps this: > 3. The OS configuration and state (i.e. /etc/ and /var/) must be encrypted, and authenticated before they are used. The encryption key should be bound to the TPM device; i.e system data should be locked to a security concept belonging to the system, not the user. Not sure you actually need a TPM for this, there are a few alternatives: - Use a generic system configuration until you get to the user prompt. This doesn't require encrypting the partition, only authenticating it. - After user authentication, either unlock the shared /etc configuration from a password stored in the encrypted user partition (could be protected by the TPM to avoid users leaking it). - Or, the better (IMO) option is to get rid of that "shared" /etc, and allow each user to have a unique, system-wide set of parameters (with a "safe mode" in case they need to recover). Not allowing users to install arbitrary software while there are tools like overlayfs is a bit backwards IMO, unless there's a company policy, but in that case capabilities can be dropped before, or the user can be limited on a case-by-case basis.
phh 5y ago
Every time I read stuff about secure boot, "evil maid" attack scenarios come up. And every time, they fail to mention the easiest one. The attack described here involves dismantling the victim's hard drive. I have an attack that isn't defeated by secure boot, and doesn't even require dismantling anything. Steal the original laptop. Take another physically identical unit. Replace it. Copy the login screen of original laptop on a brand new laptop, and have it log the password when the victim types it to you over wifi. There. I stole your data. Without any security flaw. In the exact same threat model described.
- nsajko 5y ago
  Replicating the chassis (including the scratches, etc.) and other laptop parts is the hardest part of your attack. I assume you don't know about the nail-polish with glitter based protection? Even "copying the login screen" is not necessarily easy.
  - phh 5y ago
    You know the scratches on the chassis of your laptop? I definitely don't. If someone replaces my laptop with a brand new one, I'll notice something is off, but I wouldn't be surprised I'd notice /after/ typing my password. If rather than brand new, it's replaced another laptop with approximately same age/usage, I would most definitely not notice. > I assume you don't know about the nail-polish with glitter based protection? Nope, can you explain? But okay, you may extend my attack by saying that you exchange the motherboard between the victim and the attacker laptop, so that you don't need to replicate the chassis. > Even "copying the login screen" is not necessarily easy. Personally my login screen is ubuntu's default FDE screen untouched, so there is literally no work involved to attack me there. I have absolutely no idea how to customize FDE screen. But even if I did, I'd expect that it would be pretty easy to plug in an HDMI capture to have a close-enough duplicate of the screen.
    - Foxboron 5y ago
      >But okay, you may extend my attack by saying that you exchange the motherboard between the victim and the attacker laptop, so that you don't need to replicate the chassis. Modern computers has tamper detection and if you open them you'll need to type the BIOS password. However, replacing the motherboard is going to replace the TPM. This is easily detectable with something like tpm2_totp in the bootchain. https://github.com/tpm2-software/tpm2-totp https://github.com/tpm2-software/tpm2-totp
supperburg 5y ago
“With LUKS, the encryption is as good as your password is strong.” Well that was anticlimactic. I thought my entire setup would have to be overhauled.
- amarshall 5y ago
  Did you read the whole thing? LUKS (or FDE in general) is not enough for the attacks presented. Partly because FDE is rarely ever the “full” disk.
  - supperburg 5y ago
    I did read it. The “attacks presented” are of concern to basically nobody.
amarshall 5y ago
I’m pleasantly surprised to realize this is from Poettering, as it gives me hope that it may actually find its way to being adopted. What he says is right: Linux is way behind others (except maybe the BSDs) in authenticated boot.
vbezhenar 5y ago
So basically an issue is that initramfs is not validated. Is it even possible to resolve that issue? If new grub version adds forced initramfs validation when run under secure boot mode, attacker can just install old grub which is still signed, but allows for unsigned initramfs. Of course everything but /boot must just be encrypted, there's no reason not to.
- zokier 5y ago
  You don't need separate initramfs file these days, you can bake it into the kernel executable which you can then sign
  - cmurf 5y ago
    True but this is complicated for users to do themselves.. And also complicated for distributions to create, sign, and distribute a "universal" or no-host-only initramfs that will boot any supported configuration. Plus that universal initramfs is quite a lot larger than the more compact host-only initramfs. It should be possible to automate writing out a new fs-verity "boot" directory containing the locally-signed files we care about, and having the signing regime enforced by a distro signed bootloader. Like dm-verity Android images, the Merkel tree is signed by asymmetric key pair, with the private key tossed immediately after successfully creating and signing the tree, with the public key being exposed wherever convenient.
- vbernat 5y ago
  When upgrading, you have to remove old PCR states, so rolling back to an older version is detected.
codedokode 5y ago
Sadly, the described scheme doesn't protect from hardware backdoors. Let's say someone confiscates your laptop, installs a backdoor that sends all keypresses using GSM, and returns it to you. Now the attacker has all your passwords.
nebulous1 5y ago
There's definitely something to be said about assumptions here. I knew all/most of the mentioned high level details regarding SecureBoot and the TPM. However, I would have assumed that a TPM-enabled linux distro would have authenticated everything up to the FDE password prompt at a minimum as not doing so would seem to completely defy the point! Turns out this assumption is wrong.
nimbius 5y ago
"The shim is signed with the aforementioned Microsoft key, that is built into all PCs/laptops." this is a non-starter for me. the sheer number of microsoft products and programs dedicated to or endorsing a backdoor for third parties makes it untenable for any security purpose.
- selfhoster11 5y ago
  Strip the signature and sign with your own key? It's possible as a part of the Secure Boot model.
  - stragies 5y ago
    That ^^ feels like an important part of the HowTo. Is there one, that includes this step already?
    - selfhoster11 5y ago
      I imagine that this is a documented generic process that works for all UEFI boot binaries. I can't point to any specific guide because I don't use UEFI in Secure Boot mode.
yyyk 5y ago
This is a thoughtful post, yet it is useful to think again about the threat scenarios. Poettering mentions three: The obvious 'basic' one, and two advanced scenarios focused on a thief stealing the computer and then returning it. I recall exactly one case close to the these latter two scenarios: When Mossad stole a Syrian laptop allegedly containing nuclear weapon program information and returned it[0]. However, I do not think Poettering's proposal is going to even annoy Mossad-level operations. The same people who can steal your harddrive and put it back in without notice, can for example replace your mouse with a BadUSB device and get all the info that way. Once they got hardware access, and were able to return it without the owner noticing, they have multiple ways of getting what they want. On Linux we can't be assured of controlling the hardware Apple-style. So this is a proposal which probably doesn't stop the advanced and rare scenarios it thinks it stops. In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). IMHO, the cost-benefit ratio for splitting the system isn't good enough. We should try a simpler solution with the main purpose of stopping the basic scenario. Maybe dm-crypt everything, despite the minor speed loss? Or use fs-level authentication/encryption a-la fscrypt? Either solution still allows people who want to split the system to do so. [0] https://www.theregister.com/2009/11/06/mossad_syria_trojan_hack/ https://www.theregister.com/2009/11/06/mossad_syria_trojan_h... * The authenticated base system, the encrypted base system, and at least one encrypted home directory. In most system there will also be an encrypted swap partition.
- JonathonW 5y ago
  > In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). Is there anything akin to APFS containers [1] in the Linux space? APFS's ability to share space between multiple filesystems is, among other features, how Apple is able to get away with splitting the filesystem up similarly to Poettering's proposal. (They don't go quite as far; they have a signed, sealed system volume plus a single user volume rather than Poettering's multiple user volumes, but the split is still there and therefore runs into the same issue of space allocation.) [1] https://en.wikipedia.org/wiki/Apple_File_System#Partition_scheme https://en.wikipedia.org/wiki/Apple_File_System#Partition_sc...
noahbliss 5y ago
A significant issue is being able to protect your initramfs and your cmdline options during boot while still keeping the convenience of auto-unlock. By using the TPM to handle validation, you also cut yourself out of the mix by not knowing the password. Of course this comes with the risk of hardware attacks, but there is always a risk. Current distribution implementations DO NOT, EVEN WITH SECUREBOOT ON, verify the integrity of the initramfs, which can be repacked to include malicious code that will execute during boot, potentially intercepting your LUKS key. There have been a number of attempts to solve this problem, but the most complete appear to be Mortar (a project I head) and safeboot.dev I highly recommend taking a look at either of these projects if you want be able to improve both your convenience through auto unlocking, and security through broadened scope of audit. https://github.com/noahbliss/mortar https://github.com/noahbliss/mortar https://safeboot.dev https://safeboot.dev
teddyh 5y ago
If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote. Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either live with typing in a password at every boot, or get a USB key of some kind. For servers with FDE you might want to use something to enable remote and unattended reboots, like (shameless plug) Mandos¹. 1. https://www.recompile.se/mandos https://www.recompile.se/mandos
- jonathanstrange 5y ago
  Well, you can probably annoy at least some attackers by using tamper-proof seals on your PC case and act accordingly if they are broken, because that would likely prevent them from conducting the first physical attack. But that won't help in the long run. Outstanding locks on a reinforced door and a combination of visible and hidden cameras in the hallway are probably more effective.
  - panarky 5y ago
    All tamper-evident devices can be defeated by a sophisticated attacker with physical access. https://www.slideshare.net/MichaudEric/how-to-steal-a-nuclear-warhead-without-voiding-your-xbox-warranty https://www.slideshare.net/MichaudEric/how-to-steal-a-nuclea...
    - imwillofficial 5y ago
      This is incorrect
      - panarky 5y ago
        Perhaps you'd like to cite a source.
- gear54rus 5y ago
royragsdale 5y ago
Two projects that are interesting and relevant work to address portions of this space are safeboot (https://safeboot.dev/ https://safeboot.dev/) and heads (https://osresearch.net/ https://osresearch.net/).
cmurf 5y ago
A keylogger in the initramfs seems like a pretty obvious weakness to try and exploit. From there the attacker eventually gets the password manager master password, as well as any disk encryption passwords. We could soon get to signed grub being able to read and authenticate from as fs-verity /boot on which initrd resides. Ext4 and recently btrfs support fs-verity and its more flexible than dm-verity.
richardfey 5y ago
I would have preferred that the post started with the scenarios against one wants to fortify/harden, rather than an "everything on Linux sucks" one. Everything sucks depending from the perspective, Windows, Mac or Android are not perfect either.
colek42 5y ago
The Linux kernel's Integrity Measurement Architecture can be used with the TPM to establish trust of the filesystem. ref: https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture https://www.redhat.com/en/blog/how-use-linux-kernels-integri...
clipradiowallet 5y ago
In other news, operational security is just as important as technological security measures. This means not leaving your device unattended, and if you do, implementing tamper detection of some variety. This can be as simple as a battery operated motion activated video recorder hidden and aimed at your equipment. You can pick one up for $25 on amazon.
thayne 5y ago
On most linux distros the initrd is dynamically generated, and depends on the specific hardware. So it isn't possible for the initrd to be signed by the vendor. Is it possible for the TPM to verify such a dynamically created file during boot? Also, requiring a TPM for decrypting the hard drive has a security/usability tradeof. If the TPM dies, or possibly other components of the computer (like the motherboard), then you lose the ability to access the data on the drive altogether. While if it isn't you can still recover the data from the drive.
- psanford 5y ago
  The TPM 2.0 spec has the ability to duplicate keys from one TPM to another for this type of use case. It of course requires the key policy to allow for duplication, so you have to plan ahead of time, but it is possible.
- tkfu 5y ago
  The article already mentions both of those challenges, and outlines practical solutions/mitigations to both--can you be more specific about what you didn't like?
  - thayne 5y ago
    To be honest I hadn't read the whole article when I posted that, I'd only made it about halfway through. Now having read the whole thing, regarding a failing TPM, having a recovery key seems like a fine solution, I just didn't know if that was possible. Regarding initrd, the idea of a base image plus extension images might work. Although I still have questions. Are these extension image signed by the vendor or the host? If the former, how do DKMS modules work? That isn't an edge case, the nvidia propriatary drivers, some wireless drivers, virtualbox, and sysdig for example all rely on DKMS (at least on ubuntu). And how does that system handle competing drivers? Should the base initrd use the nouveau drivers or the proprietary nvidia drivers, or does the user need to load an extension image to choose? And for that matter the base initrd you want for a server will probably be pretty different from what you want for a laptop.
cmurf 5y ago
Can a TPM be shared by two operating systems? As in, dual boot configurations? Is any sort of deconfliction required and does the relevant spec account for this?
- mjg59 5y ago
  > Can a TPM be shared by two operating systems? Yes. > Is any sort of deconfliction required No.
gautamcgoel 5y ago
Does FreeBSD do a better job addressing the issues he raises?
- vermaden 5y ago
  I did not read the article but the FreeBSD bsdinstall(8) installer gives you the option to use the GELI full disk encryption with ZFS on top of it. Its kinda similar to LUKS on Linux and will ask you for password in the bootloader. Here are the details: https://docs.freebsd.org/en/books/handbook/disks/#disks-encrypting https://docs.freebsd.org/en/books/handbook/disks/#disks-encr... Regards.
simias 5y ago
>Unfortunately not at all. Because distributions set up disk encryption the way they do, and only bind it to a user password, an attacker can easily duplicate the disk, and then attempt to brute force your password. I think this "not at all" is a bit strong. With a good enough passphrase and a slow key derivation algorithm bruteforcing the key should be impossible in practice. The key derivation takes about 2s for my root partition for instance, fast enough that it really doesn't make a difference for a legitimate user but slow enough to be hugely impractical to bruteforce, especially given that I use a long, random passphrase. On the other hand the author is entirely right that this setup is rather simple to backdoor for a sophisticated attacker, but it does a good job of protecting the data at rest.
contingencies 5y ago
Set up a new laptop for Ubuntu recently and opted for ZFS encryption, impressed it was now a mainstream install option. Sadly amused after setup that it suspends indefinitely without requiring the passphrase, ie. keeps unlocked volumes in memory. This makes the encryption basically pointless. (NB. This category of issue was highlighted in the recent interview by the resurfaced Alpha Bay operator, specifically after his former associate Cazes was bagged in Bangkok after an international police sting allegedly created a server issue explicitly to require him to log in to the so they could access his credentials unencrypted. The resurfaced operator's reported solution was apparently to always power down, even on a bathroom break.)
- privacyxpert 5y ago
  Just a heads up, you should be aware that ZFS encryption leaks considerably more metadata than full LUKS block encryption.
pabs3 5y ago
I wonder if there is a way to solve TPM sniffing attacks: https://pulsesecurity.co.nz/articles/TPM-sniffing https://pulsesecurity.co.nz/articles/TPM-sniffing https://news.ycombinator.com/item?id=19379092 https://news.ycombinator.com/item?id=19379092
UltraViolence 5y ago
I keep wondering: why do we really need authenticated boot? If you encrypt the entire disk, including the boot partition, there's no way for an adversary to make any changes anyway.
qqii 5y ago
If I've understood this right, the biggest problems are outlined in the section titled "TPM PCR Brittleness". I'm not convinced that any three of the proposed solutions are good.

342 points by Aissen 5y ago

Only had time to skim it, but even without all the details it is an excellent overview of the state of the art regarding secure boot chain. You can learn many of the points by looking into the Android boot sequence but this is a more generic and 'everything in a single place' write-up. Especially the mechanisms behind dm-verity seem to be not widely known and - in my view- underappreciated. > *This is all so desktop/laptop focused, what about servers? I know that some of the more powerful and Linux based automotive embedded systems use a similar design. While important for desktop/laptop and servers the mentioned points are crucial for systems where physical security of the hardware is limited. Oh, and BTW, if 0pointer.net i doesn't ring a bell: The author is Lennart Poettering.

deleted 5y ago
[deleted]

jimsi 5y ago

https://github.com/xmikos/cryptboot/blob/master/README.md https://github.com/xmikos/cryptboot/blob/master/README.md

Foxboron 5y ago
I don't think a 5 year old project linked without context is appropriate when talking about modern boot chain security. It doesn't even support stubs so it fails at the first threat scenario described in this post.
- selfhoster11 5y ago
  I disagree. UEFI boot security is not that recent, and it hasn't changed so much as to render earliest approaches less secure.
  - Foxboron 5y ago
    It is less secure. The initramfs is not signed, along with the microcode.

ulzeraj 5y ago

This thing right here makes me unconfortable. I don't want Microsoft signatures or any other company for what matter to be involved in my boot process. > The UEFI firmware invokes a piece of code called "shim" (which is stored in the EFI System Partition — the "ESP" — of your system), that more or less is just a list of certificates compiled into code form. The shim is signed with the aforementioned Microsoft key, that is built into all PCs/laptops.

amarshall 5y ago
Almost all UEFI firmware allows replacing the default public keys with your own, and then you can sign everything yourself with private keys only you possess.
- Foxboron 5y ago
  In theory. But part of the UEFI boot chain is Optional ROM files stored on hardware. Most commonly found on dedicated graphics cards and other hardware. All of these files need to be authenticated, and currently signed by Microsoft or the OEM vendor. A modern Lenovo Thinkpad T14 Gen 2 laptop has 7 OpROM files. If validation fails for the GFX card you are essentially "soft bricking" the device since the GFX card won't work.
  - g_p 5y ago
    An idea I just had around this, for if you run your own PK/KEK/DB chain - is it feasible to "dump" these Option ROMs? If so, you should be able to whitelist their sha256 hashes in your DB database, since the DB can contain an allow-list of hashes, as well as an allow-list of public keys. I'm not familiar with how to view relevant Option ROMs, but if you can "dump" them in the format they will be verified in, you should be able to put those into your DB database. Perhaps there could even be an open/peer-vouched crowdsourced set of such DB entries maintained for popular systems?
    - Foxboron 5y ago
      sysfs doesn't like some optionroms, so using the rom files from there wont work in some cases. Apparently they can be stored in an ACPI table.. but I haven't looked at it. Another alternative is to read the TPM2 eventlog. It should record OptionROM checksums found during boot. $ tpm2_eventlog ./t14_eventlog | grep "BOOT_SERVICES_DRIVER" | wc -l 7 This is essentially what me and Trammell Hudson has been thinking about. But I don't have any available machines to test this with, and I haven't gotten around to setting up a QEMU vm to test out this theory. https://github.com/Foxboron/sbctl/issues/85#issuecomment-886539689 https://github.com/Foxboron/sbctl/issues/85#issuecomment-886...

losingom 5y ago

>Authentication of boot loaders is done via cryptographic signatures [...] the cryptographic certificates that may be used to validate these signatures are then signed by Microsoft This is what concerns me. While Microsoft are indeed dominant, surely them signing these is a conflict of interest? Why can't there be an external body that signs these, including those for Microsoft?

dane-pgp 5y ago
> Why can't there be an external body that signs these Just wait a few years, and it will be the government that decides which OSes can run on your hardware. Hint: It will be OSes that only allow "approved" apps to run.
g_p 5y ago
The "default" boot chain is using a Microsoft CA key, but you can easily change it. In fact, the "root" for your system is the platform key, which is most probably signed by your OEM. Pragmatically speaking, I'd be more worried about my OEM's platform key being compromised when someone leaks their UEFI firmware build tree through a ransomware attack or similar. The biggest issue of the Microsoft "CA root", is that they sign everything - there was a good example [1] of them signing a Kaspersky rescue CD that could effectively break the secure boot chain. The good news is you can load your own keys into your motherboard. It's only really a solution for enterprises or tech-savvy individuals, but it at least is a viable option and helps you to "own" your own platform. [1] https://habr.com/en/post/446238/ https://habr.com/en/post/446238/
mjg59 5y ago
> Why can't there be an external body that signs these, including those for Microsoft? There can be, and I strongly suspect Microsoft would prefer there to be - reviewing and signing all the UEFI drivers consumes significant resources. Nobody else with sufficient resources to do this job has stepped forward.

sam_lowry_ 5y ago

After taking over the process #1, Lennart Poettering decided to go deeper and take over kernel, initrd and bootloader. I sometimes wonder whether he is on the NSA payroll. Lennart Poettering and Moxie Marlinspike are two people NSA should really strive to buy and/or intimidate.

fmajid 5y ago
Signal is partly funded by the US government: https://www.opentech.fund/results/supported-projects/open-whisper-systems/ https://www.opentech.fund/results/supported-projects/open-wh...
- sam_lowry_ 5y ago
  This is all totally unsubstantiated, but... Sinal's reliance on phone numbers and their point on encrypted e2e communication facilitates meta-information gathering for the governments of the world. As for Pottering, he is an old-time RedHat employee, and RedHat is supplying virtually all governments of the world.
- selfhoster11 5y ago
  So is Tor. Is there any other reason to suspect foul play?
deleted 5y ago
[deleted]
amarshall 5y ago
> take over kernel, initrd and bootloader Huh? There are not really any Kernel or bootloader changes proposed here, just signing them and using existing functionality within them. (Okay, I guess he proposes adjusting the Kernel to optionally have a way to authenticate parameters, but is that really “taking over”?) As for initrd, he’s just talking about adjusting the way their generated to be more static and modular to simplify signing. Yes, there’s some tooling to do this proposed as part of the systemd organizational umbrella, but systemd isn’t a monolithic thing. Regardless, and just like systemd, you don’t have to use any of this if you don’t want to.

hsbauauvhabzb 5y ago

I kinda think the claims about not encrypting /use are fairly dubious. What’s to stop an attacker replacing a lib with a signed+known vulnerable lib? As far as I know there’s no mechanism for revocation. What’s to stop this occurring to the kernel and/or boot loader? Maybe the TPM but idk

Foxboron 5y ago
Keeping it on a seperate blockdevice allows dm-verity to authentice the device. This value would be signed and secured, so injecting a signed+known library wouldn't work. It would refuse to mount. It should be noted that keeping it unencrypted is only for the traditional linux package manager usecase.
amarshall 5y ago
From the article: > The OS binary resources (i.e. /usr/) must be authenticated before being booted into. (But don't need to be encrypted, since everyone has the same anyway, there's nothing to hide here.) Authentication prevents manipulation. Encryption is not necessary to do so (encryption often also authenticates).

cesarb 5y ago

On a quick skim, I could see three issues with this proposal: 1. While each home directory is individually encrypted, since /home itself is not encrypted (unlike with current uses of full disk encryption), the user login names can be found unencrypted on the disk. 2. Since each home directory is individually encrypted, backup systems like borgbackup running as root can no longer easily backup everything. 3. As far as I could understand, this proposal does not have a mechanism to share disk space between the system and the user directories. This goes in the opposite direction of for example https://fedoraproject.org/wiki/Changes/BtrfsByDefault https://fedoraproject.org/wiki/Changes/BtrfsByDefault in Fedora 33, which allowed the whole disk to be used for files in /home, instead of always reserving IIRC 50 gigabytes exclusively for files outside /home.

Nextgrid 5y ago
> backup systems like borgbackup running as root can no longer easily backup everything If you’re using LUKS-encrypted volumes for home directories nothing prevents you from enrolling an extra key file entrusted to the backup program, or to the TPM (which the backup program can be allowed to access).
- kevincox 5y ago
  But that defeats the whole point as now decrypting the system is enough to access all of the home directories. You are basically back to a FDE home partition with extra complexity.
michaelt 5y ago
Also, once you've got per-user encryption on ~/.ssh/authorized_keys you'll need some other mechanism for users to log in. And don't think of having the users do their own backups - locking users' home directories mean they won't be able to run their own cron jobs.
- predakanga 5y ago
  > Also, once you've got per-user encryption on ~/.ssh/authorized_keys you'll need some other mechanism for users to log in. OpenSSH supports this through the AuthorizedKeysFile directive - it'd be quite simple for the homedir mounting tool to sync that file from the user's authorized_keys file on unmount. You could also use SSH certificates, but that requires a CA - not ideal for the home user.

BiteCode_dev 5y ago

Are other people experiencing too many corruption problems on encrypted disks? I have a veracrypt drive, and I regularly have to run a scan and fix on it because it's very sensitive to power cut, brutal restart, etc. Also, it's slow. I put my firefox conf folder in it, but it slows the browser down. Once I went full encrypted disk, but one day corruption happened, and it stopped booting. So I went back.

withinboredom 5y ago
You probably have some fun disk caching turned on in the OS or your disk has a built in cache that it’s not properly flushing. I’ve seen this before with cheap SSDs.
- BiteCode_dev 5y ago
  Maybe, I don't know enough about this, but I've been using this veracrypt disk on 6 machines, now, and I have the problem with each of them. Also, I don't have any problem with non encrypted data.
  - blablablub 5y ago
    Looks like a veracrypt problem then.
  - orthecreedence 5y ago
    Maybe a dumb question, but are you on windows? Check that Defender isn't scanning every single time data is written to your veracrypt drive. When I was on windows, the most painful slowdowns were almost invariably caused by Windows Defender.
snassar 5y ago
The better solution to these kind of problems is having a backup concept with an implementation and regular testing of backups. The encryption exposed a problem with your disks or system in general. Depending on what the problem was, the problem is still there but you are not seeing it. Now you have a possible problem and unencrypted files.

bloopernova 5y ago

Is it possible to set up an encrypted+authenticated boot that relies on a hardware token being present? In other words, only boot this OS if the Yubikey is inserted?

kevincox 5y ago
It definitely is. The easiest way is to set up the token in challenge-response mode (supported by yubikey). The disk has a key which is sent to the token and the response is used to decrypt the disk.
- sam_lowry_ 5y ago
  Does not LUKS already work with Yubikeys [1]? [1] https://github.com/cornelinux/yubikey-luks https://github.com/cornelinux/yubikey-luks
  - kevincox 5y ago
    Based on the description of that repo it does exactly what I suggested you can do.
maverwa 5y ago
According to the docs ([0], [1]) systemd-cryptenroll and crypttab support FIDO2 and PKCS#11, both should be supported by the yubikey as well. So without having tested it: I think yes, it should generally be possible, at least for encryption. [0]: https://www.freedesktop.org/software/systemd/man/crypttab.html https://www.freedesktop.org/software/systemd/man/crypttab.ht... [1]: https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html# https://www.freedesktop.org/software/systemd/man/systemd-cry...
nsajko 5y ago
See my top-level comment. Just put the initrd and secret on the external device.
- egberts1 5y ago

mschuster91 5y ago

> Some corners of the community tried (unfortunately successfully to some degree) to paint TPMs/Trusted Computing/SecureBoot as generally evil technologies that stop us from using our systems the way we want. That idea is rubbish though, I think. It's not as rubbish as the author wants to think. Just look at the current state of Android SafetyNet attestation - a myriad of apps refuse to run entirely (banking apps, games) or with reduced quality (Netflix) on unlocked bootloader / rooted systems. There are workarounds but these are a) a constant cat-and-mouse game and b) the only known workaround against online SafetyNet attestation (pretending that the device does not have a TrustZone element, forcing SafetyNet to Basic attestation) is bound to fail as soon as Google is reasonably certain that there is no hardware floating around that has the latest Android but no TrustZone element. Additionally, look at what happened to Microsoft's ARM adventures. Locked down to the point of being utterly useless, on top of MS not providing a Rosetta equivalent. The problem is that here the interests of hackers (who either want as-open-as-reasonably-possible devices or, like the author, as-secure-as-possible devices) and big corporate interests (who want to keep license holders happy like Netflix, want a way to reduce successful "my device got pwned, someone stole my money, refund me!!!" claims like banks or fight against cheaters) collide in a position that's hard to make something decent out of.

aseipp 5y ago
The modern Windows ARM laptops all(?) use standard x86 Secure Boot/UEFI rules, as far as I know. You can install Linux on them pretty easily; I know at least Fedora/Anaconda supports ARM64 pretty well. The bigger problems come after that but are more of the same stuff, i.e. lack of drivers for peripherals, you're dealing with Qualcomm, etc.
no_time 5y ago
I would LOVE tpms and every other hardware security feature if the had an user override that allows me (and only me) to control what the device does. Basically the opposite of the current and forseeable landscape.

nsajko 5y ago

An option that wasn't at all considered in the article is to have the initrd and (optionally) the secret key used for decrypting the disk on a separate device (or devices), for example on an 1 GB USB drive. This way the big disk can have full, real FDE (not LUKS). To an attacker not in possesion of the USB drive the big disk just looks like random data. And the USB drive can be kept on one's own person and easily destroyed if necessary. The main part is having the initrd on an external, small, device. The secret can be either a regular passphrase, or stored somewhere on the small device. Works fine on my Archlinux. I mount the initrd file system to /boot when I need to update it.

selfhoster11 5y ago
Now we are back to boot floppies of yore. Oh how the wheel of IT turns.
SkyMarshal 5y ago
> This way the big disk can have full, real FDE (not LUKS). I thought LUKS was the only way to do FDE in Linux. What other options for FDE are there? But yes, putting /boot on an external USB drive is the only way I know of get FDE on your hard drives. Possible with UEFI, not BIOS/MBR.
- nsajko 5y ago
  LUKS leaves encryption metadata unencrypted. For real FDE, use "plain dm-crypt" with cryptsetup: https://security.stackexchange.com/questions/109223/what-does-luks-header-contain https://security.stackexchange.com/questions/109223/what-doe... > Possible with UEFI, not BIOS/MBR. Why do you think that? I have this setup on a modern (UEFI) computer, but I use the old BIOS/MBR interface.
  - lugged 5y ago
    Does this matter? I once went through the waste of time of getting /boot encrypted. Would rather avoid needless pain.

sharmin123 5y ago

The Best And Easiest Ways To Protect Yourself From Hackers: https://www.hackerslist.co/the-best-and-easiest-ways-to-protect-yourself-from-hackers/ https://www.hackerslist.co/the-best-and-easiest-ways-to-prot...

maverwa 5y ago

Running the FDE (or partial encryption) of the TPM would include the risk that a hardware defect on the mainboard would render the disks unreadable, right? Since it would be quite hard to get that key out of it. Guess thats what recovery keys are for...

egberts1 5y ago

I only wish that package maintainers (outside of OS distro) installed directly directly into /usr/local/bin but instead they wanted “in” on the /usr/bin placement. So, We lost there as this would have facilitated secondary signing of non-OS packages by OS distro. Doesn’t help when Fedora started muddling (merging) /bin and /usr/bin. So, secondary signing for non-OS vendors just went out the window. https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/ https://freedesktop.org/wiki/Software/systemd/separate-usr-i... Even systemd is just now complaining about that during boot up (if the /usr partition somehow got invalidated during bootup). This multi-tiered */bin is that hallmark of Unix (and continuously the (Linux Filesystem Standard https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.pdf ). — Althou, systemd designer seems to disagree with this LFS approach. (IMHO, he needs to look deeper into the overall aspects of package signing architecture by OS-distros, and not just for Fedora) https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor... Now if Debian would just arrest the slide into a singular binary directory, all would be good. Linux Distros are about to be ignoring this future need of multi-island/multi-signing of encryption/immutability. No embedded Linux distro should want to be Windowized, much less the desktop Linux, unless they too seek this single island approach for immutably-verified/encrypted binaries of OS, vendors, and customers.

wereHamster 5y ago
Yeah, let's move to the complete opposite side: one /bin for each package. You can have that today, in NixOS.
- egberts1 5y ago
  We know that package containerization (a la Apple, or NixOS) didn’t expand well either for the vendors/maintainers who want to include their products into multiples of OS distros. And currently this probably would be very difficult to implement a signed-immutable binaries with regard to multi-OS distros vs multi-vendors. So, the nice sweet convergence is probably hovering around hardware/OS/vendor grouping somewhere.
5y ago

MayeulC 5y ago

I haven't read the whole essay (stopped at "In detail"). So far, I agree with most of what Lennart said, it matches my analysis, except perhaps this: > 3. The OS configuration and state (i.e. /etc/ and /var/) must be encrypted, and authenticated before they are used. The encryption key should be bound to the TPM device; i.e system data should be locked to a security concept belonging to the system, not the user. Not sure you actually need a TPM for this, there are a few alternatives: - Use a generic system configuration until you get to the user prompt. This doesn't require encrypting the partition, only authenticating it. - After user authentication, either unlock the shared /etc configuration from a password stored in the encrypted user partition (could be protected by the TPM to avoid users leaking it). - Or, the better (IMO) option is to get rid of that "shared" /etc, and allow each user to have a unique, system-wide set of parameters (with a "safe mode" in case they need to recover). Not allowing users to install arbitrary software while there are tools like overlayfs is a bit backwards IMO, unless there's a company policy, but in that case capabilities can be dropped before, or the user can be limited on a case-by-case basis.

phh 5y ago

Every time I read stuff about secure boot, "evil maid" attack scenarios come up. And every time, they fail to mention the easiest one. The attack described here involves dismantling the victim's hard drive. I have an attack that isn't defeated by secure boot, and doesn't even require dismantling anything. Steal the original laptop. Take another physically identical unit. Replace it. Copy the login screen of original laptop on a brand new laptop, and have it log the password when the victim types it to you over wifi. There. I stole your data. Without any security flaw. In the exact same threat model described.

nsajko 5y ago
Replicating the chassis (including the scratches, etc.) and other laptop parts is the hardest part of your attack. I assume you don't know about the nail-polish with glitter based protection? Even "copying the login screen" is not necessarily easy.
- phh 5y ago
  You know the scratches on the chassis of your laptop? I definitely don't. If someone replaces my laptop with a brand new one, I'll notice something is off, but I wouldn't be surprised I'd notice /after/ typing my password. If rather than brand new, it's replaced another laptop with approximately same age/usage, I would most definitely not notice. > I assume you don't know about the nail-polish with glitter based protection? Nope, can you explain? But okay, you may extend my attack by saying that you exchange the motherboard between the victim and the attacker laptop, so that you don't need to replicate the chassis. > Even "copying the login screen" is not necessarily easy. Personally my login screen is ubuntu's default FDE screen untouched, so there is literally no work involved to attack me there. I have absolutely no idea how to customize FDE screen. But even if I did, I'd expect that it would be pretty easy to plug in an HDMI capture to have a close-enough duplicate of the screen.
  - Foxboron 5y ago
    >But okay, you may extend my attack by saying that you exchange the motherboard between the victim and the attacker laptop, so that you don't need to replicate the chassis. Modern computers has tamper detection and if you open them you'll need to type the BIOS password. However, replacing the motherboard is going to replace the TPM. This is easily detectable with something like tpm2_totp in the bootchain. https://github.com/tpm2-software/tpm2-totp https://github.com/tpm2-software/tpm2-totp

supperburg 5y ago

“With LUKS, the encryption is as good as your password is strong.” Well that was anticlimactic. I thought my entire setup would have to be overhauled.

amarshall 5y ago
Did you read the whole thing? LUKS (or FDE in general) is not enough for the attacks presented. Partly because FDE is rarely ever the “full” disk.
- supperburg 5y ago
  I did read it. The “attacks presented” are of concern to basically nobody.

amarshall 5y ago

I’m pleasantly surprised to realize this is from Poettering, as it gives me hope that it may actually find its way to being adopted. What he says is right: Linux is way behind others (except maybe the BSDs) in authenticated boot.

vbezhenar 5y ago

So basically an issue is that initramfs is not validated. Is it even possible to resolve that issue? If new grub version adds forced initramfs validation when run under secure boot mode, attacker can just install old grub which is still signed, but allows for unsigned initramfs. Of course everything but /boot must just be encrypted, there's no reason not to.

zokier 5y ago
You don't need separate initramfs file these days, you can bake it into the kernel executable which you can then sign
- cmurf 5y ago
  True but this is complicated for users to do themselves.. And also complicated for distributions to create, sign, and distribute a "universal" or no-host-only initramfs that will boot any supported configuration. Plus that universal initramfs is quite a lot larger than the more compact host-only initramfs. It should be possible to automate writing out a new fs-verity "boot" directory containing the locally-signed files we care about, and having the signing regime enforced by a distro signed bootloader. Like dm-verity Android images, the Merkel tree is signed by asymmetric key pair, with the private key tossed immediately after successfully creating and signing the tree, with the public key being exposed wherever convenient.
vbernat 5y ago
When upgrading, you have to remove old PCR states, so rolling back to an older version is detected.

codedokode 5y ago

Sadly, the described scheme doesn't protect from hardware backdoors. Let's say someone confiscates your laptop, installs a backdoor that sends all keypresses using GSM, and returns it to you. Now the attacker has all your passwords.

nebulous1 5y ago

There's definitely something to be said about assumptions here. I knew all/most of the mentioned high level details regarding SecureBoot and the TPM. However, I would have assumed that a TPM-enabled linux distro would have authenticated everything up to the FDE password prompt at a minimum as not doing so would seem to completely defy the point! Turns out this assumption is wrong.

nimbius 5y ago

"The shim is signed with the aforementioned Microsoft key, that is built into all PCs/laptops." this is a non-starter for me. the sheer number of microsoft products and programs dedicated to or endorsing a backdoor for third parties makes it untenable for any security purpose.

selfhoster11 5y ago
Strip the signature and sign with your own key? It's possible as a part of the Secure Boot model.
- stragies 5y ago
  That ^^ feels like an important part of the HowTo. Is there one, that includes this step already?
  - selfhoster11 5y ago
    I imagine that this is a documented generic process that works for all UEFI boot binaries. I can't point to any specific guide because I don't use UEFI in Secure Boot mode.

yyyk 5y ago

This is a thoughtful post, yet it is useful to think again about the threat scenarios. Poettering mentions three: The obvious 'basic' one, and two advanced scenarios focused on a thief stealing the computer and then returning it. I recall exactly one case close to the these latter two scenarios: When Mossad stole a Syrian laptop allegedly containing nuclear weapon program information and returned it[0]. However, I do not think Poettering's proposal is going to even annoy Mossad-level operations. The same people who can steal your harddrive and put it back in without notice, can for example replace your mouse with a BadUSB device and get all the info that way. Once they got hardware access, and were able to return it without the owner noticing, they have multiple ways of getting what they want. On Linux we can't be assured of controlling the hardware Apple-style. So this is a proposal which probably doesn't stop the advanced and rare scenarios it thinks it stops. In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). IMHO, the cost-benefit ratio for splitting the system isn't good enough. We should try a simpler solution with the main purpose of stopping the basic scenario. Maybe dm-crypt everything, despite the minor speed loss? Or use fs-level authentication/encryption a-la fscrypt? Either solution still allows people who want to split the system to do so. [0] https://www.theregister.com/2009/11/06/mossad_syria_trojan_hack/ https://www.theregister.com/2009/11/06/mossad_syria_trojan_h... * The authenticated base system, the encrypted base system, and at least one encrypted home directory. In most system there will also be an encrypted swap partition.

JonathonW 5y ago
> In return, we get more complexity by splitting the system into at least three components*, and going back into the partitioning mess ("You only gave 300GB to /home, in order to download the ISO you want you need to repartition the system"). Is there anything akin to APFS containers [1] in the Linux space? APFS's ability to share space between multiple filesystems is, among other features, how Apple is able to get away with splitting the filesystem up similarly to Poettering's proposal. (They don't go quite as far; they have a signed, sealed system volume plus a single user volume rather than Poettering's multiple user volumes, but the split is still there and therefore runs into the same issue of space allocation.) [1] https://en.wikipedia.org/wiki/Apple_File_System#Partition_scheme https://en.wikipedia.org/wiki/Apple_File_System#Partition_sc...

noahbliss 5y ago

A significant issue is being able to protect your initramfs and your cmdline options during boot while still keeping the convenience of auto-unlock. By using the TPM to handle validation, you also cut yourself out of the mix by not knowing the password. Of course this comes with the risk of hardware attacks, but there is always a risk. Current distribution implementations DO NOT, EVEN WITH SECUREBOOT ON, verify the integrity of the initramfs, which can be repacked to include malicious code that will execute during boot, potentially intercepting your LUKS key. There have been a number of attempts to solve this problem, but the most complete appear to be Mortar (a project I head) and safeboot.dev I highly recommend taking a look at either of these projects if you want be able to improve both your convenience through auto unlocking, and security through broadened scope of audit. https://github.com/noahbliss/mortar https://github.com/noahbliss/mortar https://safeboot.dev https://safeboot.dev

teddyh 5y ago

If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this. What we can do is address the scenarios in which an attacker is either unsophisticated or remote. Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either live with typing in a password at every boot, or get a USB key of some kind. For servers with FDE you might want to use something to enable remote and unattended reboots, like (shameless plug) Mandos¹. 1. https://www.recompile.se/mandos https://www.recompile.se/mandos

jonathanstrange 5y ago
Well, you can probably annoy at least some attackers by using tamper-proof seals on your PC case and act accordingly if they are broken, because that would likely prevent them from conducting the first physical attack. But that won't help in the long run. Outstanding locks on a reinforced door and a combination of visible and hidden cameras in the hallway are probably more effective.
- panarky 5y ago
  All tamper-evident devices can be defeated by a sophisticated attacker with physical access. https://www.slideshare.net/MichaudEric/how-to-steal-a-nuclear-warhead-without-voiding-your-xbox-warranty https://www.slideshare.net/MichaudEric/how-to-steal-a-nuclea...
  - imwillofficial 5y ago
    This is incorrect
    - panarky 5y ago
      Perhaps you'd like to cite a source.
gear54rus 5y ago

royragsdale 5y ago

Two projects that are interesting and relevant work to address portions of this space are safeboot (https://safeboot.dev/ https://safeboot.dev/) and heads (https://osresearch.net/ https://osresearch.net/).

cmurf 5y ago

A keylogger in the initramfs seems like a pretty obvious weakness to try and exploit. From there the attacker eventually gets the password manager master password, as well as any disk encryption passwords. We could soon get to signed grub being able to read and authenticate from as fs-verity /boot on which initrd resides. Ext4 and recently btrfs support fs-verity and its more flexible than dm-verity.

richardfey 5y ago

I would have preferred that the post started with the scenarios against one wants to fortify/harden, rather than an "everything on Linux sucks" one. Everything sucks depending from the perspective, Windows, Mac or Android are not perfect either.

colek42 5y ago

The Linux kernel's Integrity Measurement Architecture can be used with the TPM to establish trust of the filesystem. ref: https://www.redhat.com/en/blog/how-use-linux-kernels-integrity-measurement-architecture https://www.redhat.com/en/blog/how-use-linux-kernels-integri...

clipradiowallet 5y ago

In other news, operational security is just as important as technological security measures. This means not leaving your device unattended, and if you do, implementing tamper detection of some variety. This can be as simple as a battery operated motion activated video recorder hidden and aimed at your equipment. You can pick one up for $25 on amazon.

thayne 5y ago

On most linux distros the initrd is dynamically generated, and depends on the specific hardware. So it isn't possible for the initrd to be signed by the vendor. Is it possible for the TPM to verify such a dynamically created file during boot? Also, requiring a TPM for decrypting the hard drive has a security/usability tradeof. If the TPM dies, or possibly other components of the computer (like the motherboard), then you lose the ability to access the data on the drive altogether. While if it isn't you can still recover the data from the drive.

psanford 5y ago
The TPM 2.0 spec has the ability to duplicate keys from one TPM to another for this type of use case. It of course requires the key policy to allow for duplication, so you have to plan ahead of time, but it is possible.
tkfu 5y ago
The article already mentions both of those challenges, and outlines practical solutions/mitigations to both--can you be more specific about what you didn't like?
- thayne 5y ago
  To be honest I hadn't read the whole article when I posted that, I'd only made it about halfway through. Now having read the whole thing, regarding a failing TPM, having a recovery key seems like a fine solution, I just didn't know if that was possible. Regarding initrd, the idea of a base image plus extension images might work. Although I still have questions. Are these extension image signed by the vendor or the host? If the former, how do DKMS modules work? That isn't an edge case, the nvidia propriatary drivers, some wireless drivers, virtualbox, and sysdig for example all rely on DKMS (at least on ubuntu). And how does that system handle competing drivers? Should the base initrd use the nouveau drivers or the proprietary nvidia drivers, or does the user need to load an extension image to choose? And for that matter the base initrd you want for a server will probably be pretty different from what you want for a laptop.

cmurf 5y ago

Can a TPM be shared by two operating systems? As in, dual boot configurations? Is any sort of deconfliction required and does the relevant spec account for this?

mjg59 5y ago
> Can a TPM be shared by two operating systems? Yes. > Is any sort of deconfliction required No.

gautamcgoel 5y ago

Does FreeBSD do a better job addressing the issues he raises?

vermaden 5y ago
I did not read the article but the FreeBSD bsdinstall(8) installer gives you the option to use the GELI full disk encryption with ZFS on top of it. Its kinda similar to LUKS on Linux and will ask you for password in the bootloader. Here are the details: https://docs.freebsd.org/en/books/handbook/disks/#disks-encrypting https://docs.freebsd.org/en/books/handbook/disks/#disks-encr... Regards.

simias 5y ago

>Unfortunately not at all. Because distributions set up disk encryption the way they do, and only bind it to a user password, an attacker can easily duplicate the disk, and then attempt to brute force your password. I think this "not at all" is a bit strong. With a good enough passphrase and a slow key derivation algorithm bruteforcing the key should be impossible in practice. The key derivation takes about 2s for my root partition for instance, fast enough that it really doesn't make a difference for a legitimate user but slow enough to be hugely impractical to bruteforce, especially given that I use a long, random passphrase. On the other hand the author is entirely right that this setup is rather simple to backdoor for a sophisticated attacker, but it does a good job of protecting the data at rest.

contingencies 5y ago

Set up a new laptop for Ubuntu recently and opted for ZFS encryption, impressed it was now a mainstream install option. Sadly amused after setup that it suspends indefinitely without requiring the passphrase, ie. keeps unlocked volumes in memory. This makes the encryption basically pointless. (NB. This category of issue was highlighted in the recent interview by the resurfaced Alpha Bay operator, specifically after his former associate Cazes was bagged in Bangkok after an international police sting allegedly created a server issue explicitly to require him to log in to the so they could access his credentials unencrypted. The resurfaced operator's reported solution was apparently to always power down, even on a bathroom break.)

privacyxpert 5y ago
Just a heads up, you should be aware that ZFS encryption leaks considerably more metadata than full LUKS block encryption.

pabs3 5y ago

I wonder if there is a way to solve TPM sniffing attacks: https://pulsesecurity.co.nz/articles/TPM-sniffing https://pulsesecurity.co.nz/articles/TPM-sniffing https://news.ycombinator.com/item?id=19379092 https://news.ycombinator.com/item?id=19379092

UltraViolence 5y ago

I keep wondering: why do we really need authenticated boot? If you encrypt the entire disk, including the boot partition, there's no way for an adversary to make any changes anyway.

qqii 5y ago

If I've understood this right, the biggest problems are outlined in the section titled "TPM PCR Brittleness". I'm not convinced that any three of the proposed solutions are good.