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.
At risk of being pedantic, technically it's device-mapper/dm-crypt that's doing the heavy lifting here... but I guess LUKS has become the popular name for the whole pile due to its visibility.
I’ve found out that my VPS hoster mounts disk of my VM when I power it off and writes some config changes (which broke network because their scripts were buggy). That creeped me out, so I decided to encrypt my disks. So encryption is useful even for better stability in uncontrolled environments.
> 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.
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
I am also really looking forward to the YubiKey Bio getting released too.
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.
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.
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.
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.
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.
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_encry...
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.
systemd-boot measures the bootloader, initramfs, kernel and kernel-params state into the PCR registers of your TPM. SecureBoot state is also measured.
You can configure through systemd-enroll to configure the TPM to only unlock the cryptokey if those measurements are consistent.
If somebody changes your systemd binary in the initramfs; this causes the TPM PCR register to change; and will cause the system to not be able to decrypt the stage-2 rootfs
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 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.
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).
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?
Systemd is here to stay at this point. It's not ideal(I much preferred sysV, and then preferred upstart...and so on), but it's what we have. It's also improved greatly from the initial state we received it in.
What specifically irks you about it? When I'm honest with myself, I realize my biggest objection to systemd was "change". I was comfortable with something, it changed, and I resisted it. Once debian finally gave out and switched to systemd, I saw the writing on the wall and drank the kool-aid. I haven't had any regrets.
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!
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.
clipradiowallet|5 years ago
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
pengaru|5 years ago
vbezhenar|5 years ago
lambda_obrien|5 years ago
dharmab|5 years ago
ecesena|5 years ago
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
jdoss|5 years ago
I am also really looking forward to the YubiKey Bio getting released too.
resoluteteeth|5 years ago
noahbliss|5 years ago
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://safeboot.dev
resoluteteeth|5 years ago
tialaramex|5 years ago
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.
shaicoleman|5 years ago
https://support.yubico.com/hc/en-us/articles/360016649319-Yu...
unknown|5 years ago
[deleted]
gorgoiler|5 years ago
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
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?
kd913|5 years ago
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.
dathinab|5 years ago
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.
Foxboron|5 years ago
gdamjan1|5 years ago
xaduha|5 years ago
madars|5 years ago
resoluteteeth|5 years ago
mnd999|5 years ago
I went with LUKS1 which grub can unlock.
dathinab|5 years ago
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.
the8472|5 years ago
arianvanp|5 years ago
You can configure through systemd-enroll to configure the TPM to only unlock the cryptokey if those measurements are consistent.
If somebody changes your systemd binary in the initramfs; this causes the TPM PCR register to change; and will cause the system to not be able to decrypt the stage-2 rootfs
halz|5 years ago
Foxboron|5 years ago
mo2art|5 years ago
vaduz|5 years ago
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.
ae5hnw5|5 years ago
noodlesUK|5 years ago
znpy|5 years ago
velosol|5 years ago
[1]: This is older with TPM1.2, but is the 'autoboot' similar to Windows BitLocker, https://ranzbak.nl/tpmluks/ [2]: https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... [3]: https://redhat.slides.com/pladd/securing-automated-decryptio...
gdamjan1|5 years ago
GekkePrutser|5 years ago
turminal|5 years ago
m45t3r|5 years ago
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).
westmeal|5 years ago
Nextgrid|5 years ago
clipradiowallet|5 years ago
What specifically irks you about it? When I'm honest with myself, I realize my biggest objection to systemd was "change". I was comfortable with something, it changed, and I resisted it. Once debian finally gave out and switched to systemd, I saw the writing on the wall and drank the kool-aid. I haven't had any regrets.
inetknght|5 years ago
https://systemd.software/index.html
iio7|5 years ago
guenthert|5 years ago
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.