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
And the cryptsetup tools / kernel has recently added support for Windows Bitlocker encryption as an alternative to LUKS, obviously only really appropriate if you deal with Windows images or need interop with Windows.
> so I decided to encrypt my disks
Where is the data encrypted? Local or remote? If its done remotely, whoever owns the hardware and has root on the host OS has your private key. Even with rented servers, where you are root, the KVM is king.
Combined with AMD-based (SEV) confidential computing and shielded vm you can get close to what on-premises hardware offers.
Nothing can truly replace hardware you own (except maybe fast fully homomorphic encryption eventually) but if you can trust the firmware that Intel/AMD, HP, Dell, or Supermicro ships in a box then the cloud is 99% as good at this point.
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.
I am also really looking forward to the YubiKey Bio getting released too.
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.
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.
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'
https://support.yubico.com/hc/en-us/articles/360016649319-Yu...
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?
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.
it'll need some work from the distros so the whole process is a bit more straightforward.
I went with LUKS1 which grub can unlock.
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.
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
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.
[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...
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).
> 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.
AFAIK systemd and the different components has so many internal dependencies on each other than not much works if you try to pull things apart. You can remove systemd completely, yes, but try to only have systemd as an init system and nothing works!
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.
Can someone explain why non-systemd systems are claimed to be full of broken shell scripts? I've yet to experience that.
From a developer pov I'm optimistic. systemd seems to be positioning itself as a isolation technology. It gives me a simple and effective way to ship security controls that the user themselves would not be able to do with this granularity (well normally) and it's part of the package / installer (e.g. by default hardened because why bother the user?). And the process for me as dev is really simple too (see below).
It gives me additional options rather than just hope everyone will use firejail and apparmor (even on a debian sid apparmor userspace is too permissive or not properly maintained - firejail is better but rare).
some simple things that can be dumped into a systemd.service file (source https://www.redhat.com/sysadmin/mastering-systemd) to ensure hardening isolation/hardening is always shipped with the package.
RestrictNamespaces=true
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6 AF_NETLINK
ProtectClock=true
NoNewPrivileges=true
DevicePolicy=closed
PrivateTmp=true
ProtectControlGroups=true
ProtectHome=true
ProtectKernelLogs=true
ProtectKernelModules=true
ProtectSystem=strict
RestrictSUIDSGID=true
SystemCallArchitectures=native
SystemCallFilter=sendmsg recvfrom sendto getpid prctl brk socket read stat openat rt_sigaction fstat bind close connect getsockname setpriority capset getpriority lseek mmap mprotect munmap access execve getuid capget arch_prctl gettid
RestrictRealtime=true
LockPersonality=true
MemoryDenyWriteExecute=true
Consistent interface that only works on one platform and uses all the platform specific commands imaginable to do things that have no reason to be platform specific. And it doesn't even play well with other parts of that same platform.
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 feel like it was mostly a missed opportunity to do things better; the declarative unit stuff is both over and underspecified, and for anything nontrivial, I always end up with sidecar scripts, anyway, which makes the whole thing just a game of useless boilerplate.
And then it started attempting to assimilate other daemons...
Like I said, it is what it is. But what it is is a barely competent make-work replacement for something that wasn't the worst problem in early-startup, anyway.
If others were similarly curious, the "/index.html" isn't pedantry, just navigating to "/" is a separate welcome page that shortly thereafter redirects to the freedesktop.org site
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.