Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

0pointer.net

Post reply on HN
Print view View original

71–80 of 102 posts

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

#71

Post by cycloptic »

Enginerrrd wrote: post #24
_jal wrote: post #16

Earlier quoted context omitted.

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…

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?) An…

Journald stores a lot of metadata and it is difficult to effectively store metadata without having some kind of structured format. (And before someone says it, storing JSON on disk or trying to split the metadata across files would probably be much worse than binary logs)

I am honestly surprised we haven't seen a good GUI pop up around systemd yet that allows for simple service creation and configuration like that.

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

#72

Post by unqueued »

kdtsh wrote: post #70
kwk1 wrote: post #46

Earlier quoted context omitted.

Interesting, I've never heard of earlyssh as an option--I've used dropbear-initramfs for this in the past.

I think dropbear is what sits under earlyssh. I'll look into dropbear-initramfs, if it's easier to work with than earlyssh that is a big plus in my book. edit: early-ssh is hosted at https://github.com/gheja/early-ssh . Not to knock early-ssh by saying it's difficult to work with too - it's a great piece of software which has made my life a lot easier.

If you like early-ssh, I would like to suggest checking out better-initramfs. No dependency on systemd, easy to modify and build. I think it can do everything early-ssh can do. I use it to boot a variety of LUKS encrypted btrfs machines.

Disclosure: I'm a contributor.

https://github.com/slashbeast/better-initramfs

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

#73

Post by cycloptic »

turminal wrote: post #21
Nextgrid wrote: post #12

Earlier quoted context omitted.

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?

> 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.

>to do things that have no reason to be platform specific.

If you ever try to port systemd code to non-Linux platforms you will see that this is not true. There are lots of things in Linux that have no real analog on other platforms, and it seems strange to fault a project for taking advantage of those. (BSD is the same way when you get into that too)

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

#74

Post by cycloptic »

DyslexicAtheist wrote: post #41
Nextgrid wrote: post #12

Earlier quoted context omitted.

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?

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…

>All I have are mpd, dbus, pulseaudio, mako which I can easily run from my sway/config

The thing is, you want service management here. Sway is not a service manager and won't handle monitoring of the processes, socket activation, logging, etc.

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

#75

Post by Arnavion »

inetknght wrote: post #38
mdaniel wrote: post #37

Earlier quoted context omitted.

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

> "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 onl…

>Try finding the documentation online to write a systemd service. Google finds tons of useless results [...]

The correct page is literally the first result on ddg and google for `man systemd.service`, or even just `systemd.service`. Same for all the other `systemd.*`

This isn't even new; I've been searching `man systemd.service` and `man systemd.socket` for years to reach those same pages.

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

#76

Post by ayyy »

pengaru wrote: post #61
clipradiowallet wrote: post #15

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/ 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 in…

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.

At the risk of being offtopic, this is exactly the type of pedantry that keeps me coming back here.

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

#77

Post by gorgoiler »

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

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?

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

#78

Post by vbezhenar »

clipradiowallet wrote: post #15

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/ 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 in…

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.

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

#79

Post by Sentes »

tialaramex wrote: post #42
jdoss wrote: post #31

Earlier quoted context omitted.

I didn't know that. Thanks! I'll check it out.

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 organisat…

> There's no way to force the remote SSH client not to store that RSA private key unencrypted

But there is a way to remotely attest that the private key has been generated on device (either through TPM attestation or https://developers.yubico.com/PGP/Attestation.html ).

Not to mention that the admin could just generate private keys on the token and give employees that.

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

#80

Post by rwmj »

pengaru wrote: post #61
clipradiowallet wrote: post #15

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/ 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 in…

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.

To be even more pedantic: There's also a qemu block layer device that is compatible with LUKS and works in userspace (https://www.linux-kvm.org/images/8/8c/01x03-Daniel_Berrange-... - page 13).

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.

Post reply on HN