11 ms·

Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on Systemd 248

148 points by uggedal 6y ago

resoluteteeth 6y ago
Does the yubikey "security key" series (the ones that only do u2f/fido2) support the necessary extension?
- shaicoleman 6y ago
  It seems like it's only available on the Yubikey 5 Series https://support.yubico.com/hc/en-us/articles/360016649319-YubiKey-5-2-3-Enhancements-to-FIDO-2-Support https://support.yubico.com/hc/en-us/articles/360016649319-Yu...
  - resoluteteeth 6y ago
    Thanks. That's too bad.
- deleted 6y ago
  [deleted]
- tialaramex 6y ago
  Edited to update: Nope :( My Security Key 2 reports lacking this extension. This is what the comment said before I updated it, in case it's important context for replies: I believe that they do implement hmac-secret yes. For what it's worth this is the same feature (for the same reason) you need to enroll FIDO authenticators to unlock a Windows system, so if you use one to do that today, it definitely ought to work with this too. I intend to spend the next few minutes playing with code to check I'm correct about this, but I might get distracted, so either there will be an edit saying I was right, saying I was wrong, or no edit because I watched Youtube.
  - resoluteteeth 6y ago
    The chart at the top of shaicoleman's link indicates that the security key series doesn't support it. I also just tested the hmac_secret.py sample from the python fido2 library and it didn't work with a yubikey security key nfc.
  - tialaramex 6y ago
    Now I feel terrible, because I think this was incorrect due to an embarrassing error and yet it has 5 upvotes which suggests several HN readers thought it was helpful :( During another activity I was talking to somebody about this test, and when I visualised it in my head I realised that even though I was talking about testing my "Security Key 2" I had actually tested a much simpler/cheaper Feitian based U2F authenticator I own because it was in my pocket and I just instinctively use the one I'm carrying for FIDO authentication. Unsurprisingly this cheaper device doesn't do hmac-secret. However I have now fetched my actual genuine Yubico Security 2 and re-tested that, and it does have hmac-secret despite Yubico's own site seeming to suggest otherwise. The chances anybody is reading this for any reason other than to point out I was wrong are small, but just in case this is found by somebody's later Google search here it is. Here's some example output from Yubico's example app (the secrets here are random and worthless) New credential created, with the HmacSecret extension. Authenticate with salt: b'21cef9e80517c7527ddaea4229ea36c675c539da7f98ecf3878dfc026caf4a6d'
madars 6y ago
I tolerate systemd as I want to use a popular distro for desktop use, but given the project's dismal security record (and attitude!) I can't trust systemd explicitly handling cryptographic secrets. No thank you; there are better options available https://wiki.archlinux.org/index.php/YubiKey#Full_disk_encryption_with_LUKS https://wiki.archlinux.org/index.php/YubiKey#Full_disk_encry...
- resoluteteeth 6y ago
  Is systemd's encryption a replacement for existing software like LUKS or just a wrapper around it?
  - AWildC182 6y ago
    By my understanding, systemd is just handling the unlocking process and merely provides LUKS with your password/token communication. LUKS is the part that actually needs to be secure beyond systemd just not emailing your password to the gubment/north korea/4chan. LUKS unlocks its key store with the info you provide it which is used to decrypt the drive.
westmeal 6y ago
Systemd is a horrific abomination at this point it just never ends...
- Nextgrid 6y ago
  The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?
  - generalizations 6y ago
    For me, the difference is simple. Systemd is great when it works. But, part of the value of the Unix philosophy is resiliency in the face of errors. When my void Linux / alpine Linux systems have internal failures, I can troubleshoot and solve them because the system is composed of minimal abstractions tied together - I can feasibly deduce the root of the problem, and fix it, even if half the OS is missing. With systemd, it's one big mess. Problems are far more opaque, and the pieces are far more interdependent: it's easier to wipe and start over, thereby treating the os as a black box, than to dig in and find the problem. I avoid systemd systems wherever I need to do anything with the os itself that isn't extremely ordinary.
    - viraptor 6y ago
      Are you sure it's not just familiarity with old tools? Systemd works pretty hard to put logs in one place (journald) - even ones from service start-ups. And any dbus interaction can be traced by listening to the system bus. Is that a mess compared to the old bunch of separate log files and errors lost if they don't activate their logging interface early enough?
      - generalizations 6y ago
        I'm not talking about reading logs. (Which, by the way, is a lot easier to do in a dead system when they're text and not binary. It's hard to mess up cat, grep, and notepad.) I'm talking about being able to rule out causes because the primary components of the system are independent of each other.
jdoss 6y ago
As someone that leaned pretty hard into using a Yubikey 5 for GPG/SSH keys over the past year, I am looking forward to giving this a try on my Fedora workstations. If you are interested in a fantastic walk through of using a Yubikey with your GPG/SSH keys check out https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide I am also really looking forward to the YubiKey Bio getting released too.
- resoluteteeth 6y ago
  If you just want ssh it's even easier to use u2f/fido now since it's built into openssh.
  - jdoss 6y ago
    I didn't know that. Thanks! I'll check it out.
    - tialaramex 6y ago
      FIDO-based SSH requires support from the server, because it's a new authentication method. So this is great in an environment where you control the servers, and some day it'll be pretty great for almost everybody, but today e.g. you can't use FIDO for GitHub. Whereas the older methods did not have this dependency. On the other hand, one really nice thing is that FIDO lets you force employees to actually use organisation mandated security if that's appropriate. There's no way to force the remote SSH client not to store that RSA private key unencrypted, for example, even if it is company policy to use a 16 character passphrase; but if you issue every employee a Yubikey (picking one famous brand) the FIDO authentication step can insist that a genuine Yubikey was used, that the Yubikey says a PIN was entered and user presence confirmed. The OpenSSH design passes the digitally signed assurance from the Yubikey to the remote server for assessment, so you can't just comment out a few lines of SSH client code to bypass it. Should you actually do that? Probably not, but it's an option you didn't have before. Certainly if your key people already swear they obey a policy requiring this there's no harm in enforcing it, is there?
clipradiowallet 6y ago
Unrelated to unlocking devices...but LUKS is a really nice piece of software for linux. You throw any block device(real or otherwise) to it, and you get a /dev/mapper/<name> volume that transparently encrypts anything written to it. Other than encrypting my local workstations, you can also use it on VMs from linode/digitalocean/aws/gcp/etc. If you store all your sensitive data beneath /home for example, you can boot the instance, use OOB console to access it, decrypt and mount /home, then SSH and it's business as usual. This gives you (some) protection against a malicious actor at your provider snooping your volumes. edit: typo
- lambda_obrien 6y ago
  You can even setup SSH to the bootloader to unlock LUKS if it reboots.
  - kdtsh 6y ago
    Yup, earlyssh - I found it a massive pain to set up, but it works.
    - kwk1 6y ago
      Interesting, I've never heard of earlyssh as an option--I've used dropbear-initramfs for this in the past.
      - jamesponddotco 6y ago
        Same here, I have been using dropbear-initramfs since forever. I am now looking into Mandos[1] though, as doing it manually with Dropbear becomes a massive pain when managing several bare-metal servers. [1] https://www.recompile.se/mandos https://www.recompile.se/mandos
        predakanga 6y ago
        Thanks for the link; I hadn't heard of Mandos. Another solution in the same space is Clevis[1]; last time I was researching this problem, I came across it via Red Hat's docs[2]. [1]: https://github.com/latchset/clevis https://github.com/latchset/clevis [2]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening https://access.redhat.com/documentation/en-us/red_hat_enterp...
turminal 6y ago
Seems like some more feature creep from systemd.
- m45t3r 6y ago
  I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald). Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). It has an init system because it needs control from early boot so it can offer a nice interface for services. Ditto for dbus, mount system, timers, logging, etc. You can use as much or as little as you want, but if you choose not too you need to invent your own way (that was what most distros used to do before systemd). Also, integration between those subsystems (say, init systemd and cron) was basically writing glue code, while in systemd world they're meant to be integrated (unit files of any type can depend of each other, so you can have a service that depends on a timer, a disk mount and a udev event, for example). So yeah, you may not like the way that systemd does things, but at least use valid arguments like the fact that things are more opaque (but this is understandable, this is an abstraction layer), or that the declarative approach of systemd makes some things harder (true enough, but you can always fallback to use scripts and you still have all the power of systemd dependency system).
  - turminal 6y ago
    > I don't really understand this feature creep argument against systemd. > Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep. > You can use as much or as little as you want, but if you choose not too you need to invent your own way Correct. The problem arises when you try using tools not provided by systemd in conjunction with systemd and systemd actively makes that hard. The accepted solution to that problem in the systemd world is to rewrite more tools the way systemd sees fit with the side effect of extinguishing every other approach and dragging linux further away from its BSD/Illumos cousins. This is again a form of feature creep. Don't get me wrong. I think the tooling available 15 years ago mostly sucked and there was definitely a need for something new. I just don't believe cleaning a mess with a giant monolith is the way to go.
noodlesUK 6y ago
Does this allow for having a fido2 pin on the yubikey and entering it at boot time?
mnd999 6y ago
This means systemd needs to live on an unencrypted volume though, right? Seems like a bit of a weakness given how much systemd can actually do. I went with LUKS1 which grub can unlock.
- Foxboron 6y ago
  What's the problem though? systemd is included in quite a few initramfs so nothing inherently has changed here.
- halz 6y ago
  Chances are theres an EFI partition thats still unencrypted, too! This is where secureboot/tboot has its chance to shine.
  - mnd999 6y ago
    Indeed. LUKS key on tpm2 with secure boot with /boot on encrypted seems anything but easy to setup. I also complicate things by making everything apart from efi on zfs.
- the8472 6y ago
  If you're concerned about an evil maid attack then you can authenticate bootloader, initramfs and kernel via secure boot.
- dathinab 6y ago
  You always need something to live outside of your main disk encryption. Now you have the choice to use grub for this or linux itself. In either case both can be modified to do arbitrary things and corrupt later stages. To prevent this you use secure boot, and if you want to do it right a custom platform key. So now you either pack the Linux kernel initramfs etc into a single blob and sign it or do something similar with grub. In both cases you should have a similar secure system. But in my experience GRUB's functionalities in this area are not very nice to use and lead to slow boot. On the other hand directly booting the signed linux blob without a bootloader is fast and smooth, but exposes what is in you initramfs, which normally doesn't matter.
kd913 6y ago
I am confused at which stage this is happening. Is this after the bootloader, after initramfs but now systemd-cryptsetup is loaded and unlock the first disk? AFAIK when I do my first disk unlock, at that point does systemd units get loaded including systemd-mounting. Those mounts can already already mount/unlock encrypted secondary disks, based on the keyfiles stored on the now decrypted disk. So what exactly in this case is the advantage of any of this? EDIT: Also, is there any discussions over ftpm support? Last I checked TPM2 was ok, but ftpm (which most intel/AMD now using) are a bit flaky in regards to support.
- Foxboron 6y ago
  Initramfs I believe. `systemd-cryptenrol` would probably just be a binary like any other and wrap `cryptsetup` which is on your initramfs.
  - gdamjan1 6y ago
    here's what I had to do on Arch to enable unlocking the root volume with TPM2: https://github.com/systemd/systemd/pull/17741#issuecomment-750924876 https://github.com/systemd/systemd/pull/17741#issuecomment-7... it'll need some work from the distros so the whole process is a bit more straightforward.
- dathinab 6y ago
  Quoting the man page: At early boot and when the system manager configuration reloaded, /etc/crypttab is translated systemd-cryptsetup@.service units by systemd-cryptsetup-generator(8). So this should run during mkinitcpios systemd hook, I think (i.e.during "initramfs times"). EDIT: Also as a service it can also run later one if you e.g. plug in a LUKS encrypted hard drive I think. I haven't tried it out.
- gdamjan1 6y ago
  fTPM on my Ryzen 3600 worked.
xaduha 6y ago
Good. No mention of contactless, but for PKCS#11 it should be automatic since it's responsibility of the reader via pcsc/ccid. Not so for FIDO2 or previous incarnations last I checked.
GekkePrutser 6y ago
Interesting, I wonder if if you can do PIV or Fido2 unlocking without systemd also?
iio7 6y ago
I see absolutely no use for this what so ever. I wish systemd would just concentrate on being an init system rather than being a Swiss army knife! GRUB and cryptsetup handles unlocking just fine!
- guenthert 6y ago
  Not sure, why you're being downvoted. Perhaps it's the tone and lack of enthusiasm for all things systemd. In the matter, I agree. I'd think unlocking of the filesystem ought to be happening in the boot-loader (either GRUB or ROM resident). Systemd will only be able to do so, if the root fs (typically holding /etc with plenty of stuff worth protecting) is unencrypted. It seems to me this feature was added to systemd just because they can.
  - nickik 6y ago
    Grub is basically a second OS. People who say 'systemd is large and should just do one thing' and then say 'this can be solved with GRUB' blow my mind.
    - guenthert 6y ago
      Sorry, didn't mean to promote grub, which sure has its own issues. If the boot-loader is meant to decrypt the root fs however, it won't be trivial and GRUB might be the best bet. At least it isn't listening on network ports ...
znpy 6y ago
I am wondering if there's a way to have some kind of unattended boot process along with an encrypted disk, as long as there's a tpm chip in the host.
- velosol 6y ago
  It is possible if a bit convoluted [1, 2]. When I looked into it last year it seemed the good guides were focused on Clevis & Tang with a separate server (i.e. your PC at home on your network would boot but if away from the Tang server the PC would fall back to password). In a quick look it seems they may simply support TPM2 now although I haven't looked into how/if this is different to the article. [1]: This is older with TPM1.2, but is the 'autoboot' similar to Windows BitLocker, https://ranzbak.nl/tpmluks/ https://ranzbak.nl/tpmluks/ [2]: https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-unlocking-using-a-tpm2-chip/ https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... [3]: https://redhat.slides.com/pladd/securing-automated-decryption/ https://redhat.slides.com/pladd/securing-automated-decryptio...
- gdamjan1 6y ago
  this is exactly the feature that's now possible with systemd too
ecesena 6y ago
> Unlocking with FIDO2 security tokens (well, at least with those which implement the hmac-secret extension, most do). i.e. your YubiKeys (series 5 and above), or Nitrokey FIDO2 and such. FYI, Nitrokey runs Solo FIDO2 implementation [1], which is also used by Signet HC and OnlyKey. So all these FIDO2 keys will work with LUKS2. And if any maker of keys is reading, please reach out if you're implementing U2F but want to upgrade to the full FIDO2, including the hmac-secret extension. [1] https://github.com/solokeys/solo https://github.com/solokeys/solo
gorgoiler 6y ago
If LUKS could store a piece of random public data in the LUKS header then LUKS keys could be derived by signing that public data. For example, ssh-agent can sign arbitrary data via its wire protocol. Lots of USB security keys expose their functionality via ssh-agent. https://tools.ietf.org/html/draft-miller-ssh-agent-04 https://tools.ietf.org/html/draft-miller-ssh-agent-04 Does LUKS / cryptsetup provide hooks for deriving a key from a blob of plaintext stored on the disk? [edit] There’s the UUID — sign it with your ssh-agent and use the hexdigest as a LUKS key. It sounds so simple it must already exist?
mo2art 6y ago
How is this superior to clevis? https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-unlocking-using-a-tpm2-chip/ https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... https://m.youtube.com/watch?v=Dk6ZuydQt9I https://m.youtube.com/watch?v=Dk6ZuydQt9I
- ae5hnw5 6y ago
  Superior might be a stretch, but it the ability to use PKCS11 and FIDO2 tokens look to be differentiating features.
- vaduz 6y ago
  It enables you to use a token that is portable and removable, which TPM2 chips are not. This has an advantage that it can be carried and secured separately, even if the device has to go into insecure storage like a hotel safe. You need to trust your FIDO2/PKCS11 device to be secure, though. Clevis, on the other hand, allows to bind the key to a specific machine, preventing the storage itself from being yanked out (where it is still possible) - and you need to trust TPM2, which many do not. It's all about trade-offs and trust.
noahbliss 6y ago
Hey all, as it was mentioned in the article, a significant remaining issue is being able to protect your initramfs and your cmdline options during boot while still keeping the convenience of auto-unlock. 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

148 points by uggedal 6y ago

resoluteteeth 6y ago

Does the yubikey "security key" series (the ones that only do u2f/fido2) support the necessary extension?

shaicoleman 6y ago
It seems like it's only available on the Yubikey 5 Series https://support.yubico.com/hc/en-us/articles/360016649319-YubiKey-5-2-3-Enhancements-to-FIDO-2-Support https://support.yubico.com/hc/en-us/articles/360016649319-Yu...
- resoluteteeth 6y ago
  Thanks. That's too bad.
deleted 6y ago
[deleted]
tialaramex 6y ago
Edited to update: Nope :( My Security Key 2 reports lacking this extension. This is what the comment said before I updated it, in case it's important context for replies: I believe that they do implement hmac-secret yes. For what it's worth this is the same feature (for the same reason) you need to enroll FIDO authenticators to unlock a Windows system, so if you use one to do that today, it definitely ought to work with this too. I intend to spend the next few minutes playing with code to check I'm correct about this, but I might get distracted, so either there will be an edit saying I was right, saying I was wrong, or no edit because I watched Youtube.
- resoluteteeth 6y ago
  The chart at the top of shaicoleman's link indicates that the security key series doesn't support it. I also just tested the hmac_secret.py sample from the python fido2 library and it didn't work with a yubikey security key nfc.
- tialaramex 6y ago
  Now I feel terrible, because I think this was incorrect due to an embarrassing error and yet it has 5 upvotes which suggests several HN readers thought it was helpful :( During another activity I was talking to somebody about this test, and when I visualised it in my head I realised that even though I was talking about testing my "Security Key 2" I had actually tested a much simpler/cheaper Feitian based U2F authenticator I own because it was in my pocket and I just instinctively use the one I'm carrying for FIDO authentication. Unsurprisingly this cheaper device doesn't do hmac-secret. However I have now fetched my actual genuine Yubico Security 2 and re-tested that, and it does have hmac-secret despite Yubico's own site seeming to suggest otherwise. The chances anybody is reading this for any reason other than to point out I was wrong are small, but just in case this is found by somebody's later Google search here it is. Here's some example output from Yubico's example app (the secrets here are random and worthless) New credential created, with the HmacSecret extension. Authenticate with salt: b'21cef9e80517c7527ddaea4229ea36c675c539da7f98ecf3878dfc026caf4a6d'

madars 6y ago

I tolerate systemd as I want to use a popular distro for desktop use, but given the project's dismal security record (and attitude!) I can't trust systemd explicitly handling cryptographic secrets. No thank you; there are better options available https://wiki.archlinux.org/index.php/YubiKey#Full_disk_encryption_with_LUKS https://wiki.archlinux.org/index.php/YubiKey#Full_disk_encry...

resoluteteeth 6y ago
Is systemd's encryption a replacement for existing software like LUKS or just a wrapper around it?
- AWildC182 6y ago
  By my understanding, systemd is just handling the unlocking process and merely provides LUKS with your password/token communication. LUKS is the part that actually needs to be secure beyond systemd just not emailing your password to the gubment/north korea/4chan. LUKS unlocks its key store with the info you provide it which is used to decrypt the drive.

westmeal 6y ago

Systemd is a horrific abomination at this point it just never ends...

Nextgrid 6y ago
The "horrific abomination" turned a process of trial and error and custom shell scripts full of low-level, platform-specific commands into a single, consistent interface. I don't see the downside?
- generalizations 6y ago
  For me, the difference is simple. Systemd is great when it works. But, part of the value of the Unix philosophy is resiliency in the face of errors. When my void Linux / alpine Linux systems have internal failures, I can troubleshoot and solve them because the system is composed of minimal abstractions tied together - I can feasibly deduce the root of the problem, and fix it, even if half the OS is missing. With systemd, it's one big mess. Problems are far more opaque, and the pieces are far more interdependent: it's easier to wipe and start over, thereby treating the os as a black box, than to dig in and find the problem. I avoid systemd systems wherever I need to do anything with the os itself that isn't extremely ordinary.
  - viraptor 6y ago
    Are you sure it's not just familiarity with old tools? Systemd works pretty hard to put logs in one place (journald) - even ones from service start-ups. And any dbus interaction can be traced by listening to the system bus. Is that a mess compared to the old bunch of separate log files and errors lost if they don't activate their logging interface early enough?
    - generalizations 6y ago
      I'm not talking about reading logs. (Which, by the way, is a lot easier to do in a dead system when they're text and not binary. It's hard to mess up cat, grep, and notepad.) I'm talking about being able to rule out causes because the primary components of the system are independent of each other.

jdoss 6y ago

As someone that leaned pretty hard into using a Yubikey 5 for GPG/SSH keys over the past year, I am looking forward to giving this a try on my Fedora workstations. If you are interested in a fantastic walk through of using a Yubikey with your GPG/SSH keys check out https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide I am also really looking forward to the YubiKey Bio getting released too.

resoluteteeth 6y ago
If you just want ssh it's even easier to use u2f/fido now since it's built into openssh.
- jdoss 6y ago
  I didn't know that. Thanks! I'll check it out.
  - tialaramex 6y ago
    FIDO-based SSH requires support from the server, because it's a new authentication method. So this is great in an environment where you control the servers, and some day it'll be pretty great for almost everybody, but today e.g. you can't use FIDO for GitHub. Whereas the older methods did not have this dependency. On the other hand, one really nice thing is that FIDO lets you force employees to actually use organisation mandated security if that's appropriate. There's no way to force the remote SSH client not to store that RSA private key unencrypted, for example, even if it is company policy to use a 16 character passphrase; but if you issue every employee a Yubikey (picking one famous brand) the FIDO authentication step can insist that a genuine Yubikey was used, that the Yubikey says a PIN was entered and user presence confirmed. The OpenSSH design passes the digitally signed assurance from the Yubikey to the remote server for assessment, so you can't just comment out a few lines of SSH client code to bypass it. Should you actually do that? Probably not, but it's an option you didn't have before. Certainly if your key people already swear they obey a policy requiring this there's no harm in enforcing it, is there?

clipradiowallet 6y ago

Unrelated to unlocking devices...but LUKS is a really nice piece of software for linux. You throw any block device(real or otherwise) to it, and you get a /dev/mapper/<name> volume that transparently encrypts anything written to it. Other than encrypting my local workstations, you can also use it on VMs from linode/digitalocean/aws/gcp/etc. If you store all your sensitive data beneath /home for example, you can boot the instance, use OOB console to access it, decrypt and mount /home, then SSH and it's business as usual. This gives you (some) protection against a malicious actor at your provider snooping your volumes. edit: typo

lambda_obrien 6y ago
You can even setup SSH to the bootloader to unlock LUKS if it reboots.
- kdtsh 6y ago
  Yup, earlyssh - I found it a massive pain to set up, but it works.
  - kwk1 6y ago
    Interesting, I've never heard of earlyssh as an option--I've used dropbear-initramfs for this in the past.
    - jamesponddotco 6y ago
      Same here, I have been using dropbear-initramfs since forever. I am now looking into Mandos[1] though, as doing it manually with Dropbear becomes a massive pain when managing several bare-metal servers. [1] https://www.recompile.se/mandos https://www.recompile.se/mandos
      - predakanga 6y ago
        Thanks for the link; I hadn't heard of Mandos. Another solution in the same space is Clevis[1]; last time I was researching this problem, I came across it via Red Hat's docs[2]. [1]: https://github.com/latchset/clevis https://github.com/latchset/clevis [2]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/configuring-automated-unlocking-of-encrypted-volumes-using-policy-based-decryption_security-hardening https://access.redhat.com/documentation/en-us/red_hat_enterp...

turminal 6y ago

Seems like some more feature creep from systemd.

m45t3r 6y ago
I don't really understand this feature creep argument against systemd. I mean, this is not like this is a feature included in PID1, it is a new binary so a separate feature (and I am pretty sure that you can choose to not compile it too if you don't want, like almost any other systemd feature with the exception of systemd itself and journald). Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). It has an init system because it needs control from early boot so it can offer a nice interface for services. Ditto for dbus, mount system, timers, logging, etc. You can use as much or as little as you want, but if you choose not too you need to invent your own way (that was what most distros used to do before systemd). Also, integration between those subsystems (say, init systemd and cron) was basically writing glue code, while in systemd world they're meant to be integrated (unit files of any type can depend of each other, so you can have a service that depends on a timer, a disk mount and a udev event, for example). So yeah, you may not like the way that systemd does things, but at least use valid arguments like the fact that things are more opaque (but this is understandable, this is an abstraction layer), or that the declarative approach of systemd makes some things harder (true enough, but you can always fallback to use scripts and you still have all the power of systemd dependency system).
- turminal 6y ago
  > I don't really understand this feature creep argument against systemd. > Also, the way I understand systemd nowadays is it isn't an init system, it is an API for Linux systems that abstracts low level features in kernel in a consistent way (either using unit files or systemd C interface). Starting as an init system and becoming a general API that abstracts low level kernel features seems like feature creep. > You can use as much or as little as you want, but if you choose not too you need to invent your own way Correct. The problem arises when you try using tools not provided by systemd in conjunction with systemd and systemd actively makes that hard. The accepted solution to that problem in the systemd world is to rewrite more tools the way systemd sees fit with the side effect of extinguishing every other approach and dragging linux further away from its BSD/Illumos cousins. This is again a form of feature creep. Don't get me wrong. I think the tooling available 15 years ago mostly sucked and there was definitely a need for something new. I just don't believe cleaning a mess with a giant monolith is the way to go.

noodlesUK 6y ago

Does this allow for having a fido2 pin on the yubikey and entering it at boot time?

mnd999 6y ago

This means systemd needs to live on an unencrypted volume though, right? Seems like a bit of a weakness given how much systemd can actually do. I went with LUKS1 which grub can unlock.

Foxboron 6y ago
What's the problem though? systemd is included in quite a few initramfs so nothing inherently has changed here.
halz 6y ago
Chances are theres an EFI partition thats still unencrypted, too! This is where secureboot/tboot has its chance to shine.
- mnd999 6y ago
  Indeed. LUKS key on tpm2 with secure boot with /boot on encrypted seems anything but easy to setup. I also complicate things by making everything apart from efi on zfs.
the8472 6y ago
If you're concerned about an evil maid attack then you can authenticate bootloader, initramfs and kernel via secure boot.
dathinab 6y ago
You always need something to live outside of your main disk encryption. Now you have the choice to use grub for this or linux itself. In either case both can be modified to do arbitrary things and corrupt later stages. To prevent this you use secure boot, and if you want to do it right a custom platform key. So now you either pack the Linux kernel initramfs etc into a single blob and sign it or do something similar with grub. In both cases you should have a similar secure system. But in my experience GRUB's functionalities in this area are not very nice to use and lead to slow boot. On the other hand directly booting the signed linux blob without a bootloader is fast and smooth, but exposes what is in you initramfs, which normally doesn't matter.

kd913 6y ago

I am confused at which stage this is happening. Is this after the bootloader, after initramfs but now systemd-cryptsetup is loaded and unlock the first disk? AFAIK when I do my first disk unlock, at that point does systemd units get loaded including systemd-mounting. Those mounts can already already mount/unlock encrypted secondary disks, based on the keyfiles stored on the now decrypted disk. So what exactly in this case is the advantage of any of this? EDIT: Also, is there any discussions over ftpm support? Last I checked TPM2 was ok, but ftpm (which most intel/AMD now using) are a bit flaky in regards to support.

Foxboron 6y ago
Initramfs I believe. `systemd-cryptenrol` would probably just be a binary like any other and wrap `cryptsetup` which is on your initramfs.
- gdamjan1 6y ago
  here's what I had to do on Arch to enable unlocking the root volume with TPM2: https://github.com/systemd/systemd/pull/17741#issuecomment-750924876 https://github.com/systemd/systemd/pull/17741#issuecomment-7... it'll need some work from the distros so the whole process is a bit more straightforward.
dathinab 6y ago
Quoting the man page: At early boot and when the system manager configuration reloaded, /etc/crypttab is translated systemd-cryptsetup@.service units by systemd-cryptsetup-generator(8). So this should run during mkinitcpios systemd hook, I think (i.e.during "initramfs times"). EDIT: Also as a service it can also run later one if you e.g. plug in a LUKS encrypted hard drive I think. I haven't tried it out.
gdamjan1 6y ago
fTPM on my Ryzen 3600 worked.

xaduha 6y ago

Good. No mention of contactless, but for PKCS#11 it should be automatic since it's responsibility of the reader via pcsc/ccid. Not so for FIDO2 or previous incarnations last I checked.

GekkePrutser 6y ago

Interesting, I wonder if if you can do PIV or Fido2 unlocking without systemd also?

iio7 6y ago

I see absolutely no use for this what so ever. I wish systemd would just concentrate on being an init system rather than being a Swiss army knife! GRUB and cryptsetup handles unlocking just fine!

guenthert 6y ago
Not sure, why you're being downvoted. Perhaps it's the tone and lack of enthusiasm for all things systemd. In the matter, I agree. I'd think unlocking of the filesystem ought to be happening in the boot-loader (either GRUB or ROM resident). Systemd will only be able to do so, if the root fs (typically holding /etc with plenty of stuff worth protecting) is unencrypted. It seems to me this feature was added to systemd just because they can.
- nickik 6y ago
  Grub is basically a second OS. People who say 'systemd is large and should just do one thing' and then say 'this can be solved with GRUB' blow my mind.
  - guenthert 6y ago
    Sorry, didn't mean to promote grub, which sure has its own issues. If the boot-loader is meant to decrypt the root fs however, it won't be trivial and GRUB might be the best bet. At least it isn't listening on network ports ...

znpy 6y ago

I am wondering if there's a way to have some kind of unattended boot process along with an encrypted disk, as long as there's a tpm chip in the host.

velosol 6y ago
It is possible if a bit convoluted [1, 2]. When I looked into it last year it seemed the good guides were focused on Clevis & Tang with a separate server (i.e. your PC at home on your network would boot but if away from the Tang server the PC would fall back to password). In a quick look it seems they may simply support TPM2 now although I haven't looked into how/if this is different to the article. [1]: This is older with TPM1.2, but is the 'autoboot' similar to Windows BitLocker, https://ranzbak.nl/tpmluks/ https://ranzbak.nl/tpmluks/ [2]: https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-unlocking-using-a-tpm2-chip/ https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... [3]: https://redhat.slides.com/pladd/securing-automated-decryption/ https://redhat.slides.com/pladd/securing-automated-decryptio...
gdamjan1 6y ago
this is exactly the feature that's now possible with systemd too

ecesena 6y ago

> Unlocking with FIDO2 security tokens (well, at least with those which implement the hmac-secret extension, most do). i.e. your YubiKeys (series 5 and above), or Nitrokey FIDO2 and such. FYI, Nitrokey runs Solo FIDO2 implementation [1], which is also used by Signet HC and OnlyKey. So all these FIDO2 keys will work with LUKS2. And if any maker of keys is reading, please reach out if you're implementing U2F but want to upgrade to the full FIDO2, including the hmac-secret extension. [1] https://github.com/solokeys/solo https://github.com/solokeys/solo

gorgoiler 6y ago

If LUKS could store a piece of random public data in the LUKS header then LUKS keys could be derived by signing that public data. For example, ssh-agent can sign arbitrary data via its wire protocol. Lots of USB security keys expose their functionality via ssh-agent. https://tools.ietf.org/html/draft-miller-ssh-agent-04 https://tools.ietf.org/html/draft-miller-ssh-agent-04 Does LUKS / cryptsetup provide hooks for deriving a key from a blob of plaintext stored on the disk? [edit] There’s the UUID — sign it with your ssh-agent and use the hexdigest as a LUKS key. It sounds so simple it must already exist?

mo2art 6y ago

How is this superior to clevis? https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-unlocking-using-a-tpm2-chip/ https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... https://m.youtube.com/watch?v=Dk6ZuydQt9I https://m.youtube.com/watch?v=Dk6ZuydQt9I

ae5hnw5 6y ago
Superior might be a stretch, but it the ability to use PKCS11 and FIDO2 tokens look to be differentiating features.
vaduz 6y ago
It enables you to use a token that is portable and removable, which TPM2 chips are not. This has an advantage that it can be carried and secured separately, even if the device has to go into insecure storage like a hotel safe. You need to trust your FIDO2/PKCS11 device to be secure, though. Clevis, on the other hand, allows to bind the key to a specific machine, preventing the storage itself from being yanked out (where it is still possible) - and you need to trust TPM2, which many do not. It's all about trade-offs and trust.

noahbliss 6y ago

Hey all, as it was mentioned in the article, a significant remaining issue is being able to protect your initramfs and your cmdline options during boot while still keeping the convenience of auto-unlock. 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