[HN Gopher] Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Se...
___________________________________________________________________
Unlocking LUKS2 Volumes with TPM2, FIDO2, PKCS#11 Security HW on
Systemd 248
Author : uggedal
Score : 93 points
Date : 2021-01-21 18:24 UTC (4 hours ago)
(HTM) web link (0pointer.net)
(TXT) w3m dump (0pointer.net)
| clipradiowallet wrote:
| 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
| dharmab wrote:
| Note that this trashes your disk I/O performance; AWS offers
| Customer Managed Keys as an alternative where you use their
| platform's encryption but with your own keys:
| https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncry...
| lambda_obrien wrote:
| You can even setup SSH to the bootloader to unlock LUKS if it
| reboots.
| geek_at wrote:
| Also you can auto-decrypt LUKS when your main machine is
| booted https://blog.haschek.at/2020/the-encrypted-
| homelab.html
| kdtsh wrote:
| Yup, earlyssh - I found it a massive pain to set up, but it
| works.
| kwk1 wrote:
| Interesting, I've never heard of earlyssh as an option--
| I've used dropbear-initramfs for this in the past.
| westmeal wrote:
| Systemd is a horrific abomination at this point it just never
| ends...
| Nextgrid wrote:
| 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?
| [deleted]
| generalizations wrote:
| 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.
| zests wrote:
| I tinker on my gentoo box and OpenRC is more than capable of
| everything it needs to do. I don't understand why people's
| linux fill up with "trial and error custom shell scripts".
|
| Can someone explain why non-systemd systems are claimed to be
| full of broken shell scripts? I've yet to experience that.
| tgbugs wrote:
| It is a straw man that people use to try to try to make
| systemd seem like a solution, the only issue is that the
| problem never actually existed, just like people who try to
| argue that "x is dying or not attracting enough new users"
| in order to try to present a change they want to make as
| some how "solving" the problem of users leaving (e.g. "we
| should switch development to github"). When you look at the
| numbers and look at the existing systems, the stories are a
| complete fabrication to try to prop up a fallacious
| argument or process, tool, or project that is usually worse
| than what is really out there, not what its proponents
| claim is out there.
| DyslexicAtheist wrote:
| for me the downside is mostly when I am forced as user to
| everything the 'systemd --user' way. All I have are mpd,
| dbus, pulseaudio, mako which I can easily run from my
| sway/config (the script that starts sway or xinitrc whatever)
| and I do not need systemd and journalctl and all the tooling
| that I'm then also buying into. This is IMO an annoyance
| where I think systemd is creeping in too much.
|
| 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
|
| As an elitist user, sure firejail is great - but I would not
| install firejail on my 72 yro aunt Debian laptop (because
| many reasons :))
| turminal wrote:
| > platform-specific commands into a single, consistent
| interface
|
| 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.
| inetknght wrote:
| I concur. Here, read my take on systemd:
|
| https://systemd.software/index.html
| mdaniel wrote:
| Whew, thank goodness for "View > Page Style > No Page Style"
| as that is some geocities-esque CSS on that page
|
| 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
| inetknght wrote:
| > _" View > Page Style > No Page Style"_
|
| Just turn on reader-mode in your browser. Or prefix the url
| with `about:reader?url=`.
|
| > _that shortly thereafter redirects to the freedesktop.org
| site_
|
| Specifically, it redirects to the systemd documentation
| part of the freedesktop.org site. There's also a bunch of
| other documentation redirects for the stuff I use. That's
| what index.html describes.
|
| Try finding the documentation online to write a systemd
| service. Google finds tons of useless results and good luck
| remembering the freedesktop.org URL for systemd
| documentation (or even knowing that it's the
| _freedesktop.org_ link that is authoritive), or try
| navigating their landing page. It's a f#$%ing nightmare!
|
| Just go here instead. https://systemd.software/service.
| Super short and easier to remember and easier to discover
| than `man service` oh wait I mean `man systemd` wait no I
| actually mean `man systemd.service` because `man
| systemctl`. Wait where do I even put the .service file???
| clipradiowallet wrote:
| 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.
| _jal wrote:
| Not to derail, but I've mostly gotten to just living with it.
|
| 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.
| Enginerrrd wrote:
| Yeah this is my exact sentiment. It took a lot easy things
| and made them require more boilerplate overhead. I'm sure
| its great for some use cases, but I've never encountered
| them. I actually like the idea of having a more consistent
| way to administrate the system, and for some thing systemd
| does great. But it also involved a lot of real head-
| scratcher decisions. (What problem was binary log files
| trying to solve?)
|
| And screw unit files. Is there a helper utility to write
| and place the unit files for me? That would make me
| actually shutup about systemd.
| mnd999 wrote:
| 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 wrote:
| What's the problem though? systemd is included in quite a few
| initramfs so nothing inherently has changed here.
| the8472 wrote:
| If you're concerned about an evil maid attack then you can
| authenticate bootloader, initramfs and kernel via secure boot.
| halz wrote:
| Chances are theres an EFI partition thats still unencrypted,
| too! This is where secureboot/tboot has its chance to shine.
| mnd999 wrote:
| 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.
| jdoss wrote:
| 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.
| resoluteteeth wrote:
| If you just want ssh it's even easier to use u2f/fido now since
| it's built into openssh.
| jdoss wrote:
| I didn't know that. Thanks! I'll check it out.
| tialaramex wrote:
| 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?
| kd913 wrote:
| 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 wrote:
| Initramfs I believe. `systemd-cryptenrol` would probably just
| be a binary like any other and wrap `cryptsetup` which is on
| your initramfs.
| dathinab wrote:
| 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.
| iio7 wrote:
| 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!
| turminal wrote:
| Seems like some more feature creep from systemd.
| m45t3r wrote:
| 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).
| resoluteteeth wrote:
| Does the yubikey "security key" series (the ones that only do
| u2f/fido2) support the necessary extension?
| [deleted]
| tialaramex wrote:
| 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 wrote:
| 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.
| shaicoleman wrote:
| It seems like it's only available on the Yubikey 5 Series
|
| https://support.yubico.com/hc/en-us/articles/360016649319-Yu...
| resoluteteeth wrote:
| Thanks. That's too bad.
| noodlesUK wrote:
| Does this allow for having a fido2 pin on the yubikey and
| entering it at boot time?
| xaduha wrote:
| 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.
| madars wrote:
| 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...
| resoluteteeth wrote:
| Is systemd's encryption a replacement for existing software
| like LUKS or just a wrapper around it?
| AWildC182 wrote:
| 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.
| GekkePrutser wrote:
| Interesting, I wonder if if you can do PIV or Fido2 unlocking
| without systemd also?
___________________________________________________________________
(page generated 2021-01-21 23:00 UTC)