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

61–70 of 102 posts

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

#61

Post by pengaru »

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.

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

#62

Post by lambda_obrien »

kwk1 wrote: post #46
kdtsh wrote: post #39

Earlier quoted context omitted.

Yup, earlyssh - I found it a massive pain to set up, but it works.

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

Same, that's what I use, and it was super easy to do.

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

#63

Post by cromwellian »

londons_explore wrote: post #59
benlivengood wrote: post #50

Earlier quoted context omitted.

Google compute platform even offers user-provided keys at instance startup; they persist in RAM only for the lifetime of the instance and you can provide an rsa-encrypted symmetric key to GCP if you don't trust the box responsible for calling the GCP API. 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 o…

If you don't trust Google, even this doesn't help you. They run enough code in and near your VM, they could find a way to steal data out if it if they wanted. If you do trust Google, this is of no benefit. They encrypt your disk at rest anyway with their own keys if you don't provide yours. The only reason to use any of the above tech is to change the legal burden of who has to provide data if a court order is made.…

That's actually a pretty compelling use case. Instead of the US Government being able to routinely compel Apple, Google, FB, Amazon, etc to to hand over data they just say "we don't have the keys". The fact that any of these entities could find a way to get the data if they wanted (yes, even Apple, even with E2E could have an insider attack where a rogue spy employee implanted some code in the OS to intercept data)

Allowing the service providers to say "we don't have it", makes widespread government attack less scalable, because instead of focusing on one entity, suddenly they've got to chase down thousands of individuals and compel them. And the individuals usually have a lot less to lose if they don't obey than a tech company with billions on the line.

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

#64

Post by Nursie »

viraptor wrote: post #58
generalizations wrote: post #56

Earlier quoted context omitted.

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.

> is a lot easier to do in a dead system when they're text and not binary The binary format doesn't matter for browsing logs. Replace `cat /your/custom/service/file.log | grep ...` with `journalctl -u service | grep ...` (or just `-a` for everything) I'd actually argue it's easier not to mess up with journal with simple tools, because you don't have to special-case `service`, `service.1`, `service.2.gz` files.

For a dead system with it's main disk mounted on a living one, on which the service is not registered, is it that easy?

I've never tried.

I like service files, but the rest not so much.

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

#65

Post by dathinab »

mnd999 wrote: post #23

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.

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.

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

#66

Post by velosol »

znpy wrote: post #57

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.

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/ [2]: https://blog.dowhile0.org/2017/10/18/automatic-luks-volumes-... [3]: https://redhat.slides.com/pladd/securing-automated-decryptio...

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

#67

Post by Macha »

Nursie wrote: post #64
viraptor wrote: post #58

Earlier quoted context omitted.

> is a lot easier to do in a dead system when they're text and not binary The binary format doesn't matter for browsing logs. Replace `cat /your/custom/service/file.log | grep ...` with `journalctl -u service | grep ...` (or just `-a` for everything) I'd actually argue it's easier not to mess up with journal with simple tools, because you don't have to special-case `service`, `service.1`, `service.2.gz` files.

For a dead system with it's main disk mounted on a living one, on which the service is not registered, is it that easy? I've never tried. I like service files, but the rest not so much.

journalctl -D /mnt/othersystemroot/var/log/journal

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

#68

Post by predakanga »

jamesponddotco wrote: post #51
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.

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

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

[2]: https://access.redhat.com/documentation/en-us/red_hat_enterp...

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

#69

Post by benlivengood »

londons_explore wrote: post #59
benlivengood wrote: post #50

Earlier quoted context omitted.

Google compute platform even offers user-provided keys at instance startup; they persist in RAM only for the lifetime of the instance and you can provide an rsa-encrypted symmetric key to GCP if you don't trust the box responsible for calling the GCP API. 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 o…

If you don't trust Google, even this doesn't help you. They run enough code in and near your VM, they could find a way to steal data out if it if they wanted. If you do trust Google, this is of no benefit. They encrypt your disk at rest anyway with their own keys if you don't provide yours. The only reason to use any of the above tech is to change the legal burden of who has to provide data if a court order is made.…

> If you don't trust Google, even this doesn't help you. They run enough code in and near your VM, they could find a way to steal data out if it if they wanted.

Exactly, but so can Intel/AMD/Dell/HP/$HW_VENDOR. That's why we have libreboot and friends trying to disable ME and other firmware blobs.

You could airgap your hardware in a SCIF and shred it when you're done with it but as stuxnet and other attacks have shown if you want to do useful network computing you can't be totally secure.

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

#70

Post by kdtsh »

kwk1 wrote: post #46
kdtsh wrote: post #39

Earlier quoted context omitted.

Yup, earlyssh - I found it a massive pain to set up, but it works.

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.

Post reply on HN