Hacker News Reader

Comment by clipradiowallet | Hacker News Reader

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

View on HN

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.

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.

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.

> VPS hoster

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

It is encrypted remotely using LUKS, but I have to enter password manually when machine is booting (via web VNC). Of course I understand that determined attacker from hoster side could sniff that password, but, as I said, that's more about preventing automatic scripts to mount my disks rather than trying to hide something.

You can even setup SSH to the bootloader to unlock LUKS if it reboots.

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

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

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

Nice! Starred, will definitely keep that in mind, thanks a lot.

Also you can auto-decrypt LUKS when your main machine is booted https://blog.haschek.at/2020/the-encrypted-homelab.html

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

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

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 provide the keys then the court has to come to you to provide data on demand.

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.

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

Reply on news.ycombinator.com