Full system encryption without encrypted /boot

I noticed such feature was discussed from time to time in many other topics (especially related to super-slow decryption during boot), but couldn't find the "official" request for it.

Hence, I'd like to know if you have any plans to modify the installer to support encrypted system, but without encrypted /boot. Like this one - https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system#LVM_on_LUKS

Some will say unencrypted /boot is a security risk. But so is unencrypted bootloader (which is used now) because anyone which physical access can still replace the bootloader. However, supporting unencrypted /boot would bring at least 2 serious benefits:

  1. It would instantly solve hundreds of complains about super-slow decryption during boot. The forum is full of non-solved complains about decryption during boot taking 20-30 seconds. As some of you may already know, GRUB2 doesn't support hardware-optimized encryption/decryption, so it uses its own library. As a result, it takes 20-30 seconds to decrypt system, while having system on exactly the same machine (but with unencrypted /boot) takes exactly 1 second to decrypt everything (because it's possible to use hardware-optimized decryption then).

  2. It would bring support for LUKS2, which is already stable for years, but is not supported by GRUB2. Of course, the's not such a big benefit when compared to benefit #1 (30 times faster boot), but I'm sure many users will like it.

P.S. Please do not suggest me to use Manjaro-Architect to do this manually (unless you did it on your own and can confirm everything really works). I tried multiple times, and such setup failed every single time. I reported the issue, and other users were able to reproduce it - Multiple installation failures (UEFI, LVM on LUKS) I know it might be my own stupidity, but every time I repeated the same steps on now-defunct Antergos, it worked every single time. Hence, I strongly believe the problem was with MA.

The system is installed with Calamares installer. Issues with the Calamares installer and eventual errors or missing features it best discussed on the upstream github repo.

To my knowledge - your intention is possible using Calamares and manual partitioning - I have never needed encryption - but to make myself familiar with requirements I wrote a CLI guide.

Depending on your system and the passphrase you have chosen decrypting will always slower than unencrypted systems.

Yes, tried that. It works fine until Calamares needs to start actually installing OS into partitions that I manually created, formatted, encrypted, and "imported" into Calamares. Then after installation begins, some popup with JSON (if I remember right) errors is displayed and this is it. Tried for the 1st time more than 1 year ago, tried several times again about 3 months ago (hoping it got fixed). The same story - Calamares detects all the manual partitions, but installation doesn't finish.

I guess the only choice is to use your 100% CLI guide now, which doesn't sound very exciting. specially because I have 7 computers now that need to run Manjaro.

The main issue is not system in this situation. It's GRUB, which can't utilize instructions built into hardware to greatly speedup everything. As a result, GRUB2 decryption is 20 times slower on the same system when compared to non-GRUB2 decryption. In case you have an extra minute, I described all the tests (which I performed with multiple machines) here - Boot time optimization - LUKS encrypted install takes 47 Seconds with SSDs?

I will take a peek - of course I had to test if the Calamares encryption strategy works.

I tested using a small VM in VBox.

Manually create partitions

  • Create new GPT partitiontable
  • New 300MB /boot/efi
  • New 300MB /boot
  • New remaining / ext4 encrypt passphrase
  • Next
  • Calamares messsage - this is probably not a good idea -> Continue
  • Reboot - no issues
  • Input passphrase - login - running

But since I have no experience with encryption - I tag along - why is it a problem that decryption takes time?

After all - an encrypted system - is a security measure and some locks takes more time to open.

If you think the main issue is grub - I think you are barking up the wrong tree - why don't you talk to the grub developers?

1 Like

That might be the case. I'm using multi partitions in LUKS2 container (LVM on LUKS).

In one hand, you are 100% right, and GRUB devs should look for a solution. However, they only started supporting decryption (LUKS v1) a few years ago, and I think it will take years for them to support LUKS v2 and some more years to optimize decryption. But there's a solution - offer an option for users not to use GRUB2 decryption (leave /boot unencrypted, as suggested in Arch wiki and other security tutorials), so users can enjoy fast system without waiting years for GRUB devs to address the issue. Especially because such workaround is recommended by Arch, which Manjaro is based on.

Just a suggestion, not any kind of criticism :slight_smile:

I see - I have yet to see the useful in LVMs for personal computing - but that's probably just me :smile: :.

I easily see the usability server-side - very large server farm/hosting using virtual machines.

I think I just described such solution. I think users will accept the long decryption phase and those who will not will be smart enough to figure out how to do it otherwise.

There is no installers or operating systems which is a one-size-fits-all. Calamares and Manjaro is no exception.

But if you think Calamares should have the option - the Calamares github repo is a great place to place such feature request.

Yeah, I guess you are right - Calamares devs should probably take care of this instead of Manjaro devs. Oh well, I will try manual partitioning + Calamarers without LVM, maybe it will work for me too.

Is it not possible in Calmares? Just use its Manual Installation option. See the User Guide page 93.
image
This will only create a LUKS encrypted partition, not LVM. But your use case was an old computer IIRC and LVM will only add additional overhead.
In manual installation you can then create a partition to be mounted on /boot and select not to encrypt it.

At the moment, I have some very old systems, some new systems (with hardware released less than 2 years ago), and some systems with very latest hardware (just a few months old). Anyways, I will try with Calamares again when I have some free time. In the past, I couldn't complete installations with manual encryption o UEFI machines.

A different approach would be to install with encrypted LVM (is it possible?), and mount the ESP on /boot.

And no crypto_keyfile.bin and so on in initramfs, of course. Also leaving /boot unencrypted means anyone with direct access can compromise unsigned files like kernel or initrd and you won't even notice that right away.

You are right - there is downsides to everything. There will always be compromises - the only system I can think of - A reasonably secure operating system - is Qubes OS.

If you were a human rights activist or in the cross-hairs of three letter or more agencies I think Qubes not Manjaro is the right choice.

Yes, I'm perfectly aware of this. However, please correct me if I'm wrong, but having boot encrypted doesn't protect from this type of attacks much because anyone with direct access can compromise bootloader (which is NOT encrypted even if /boot is encrypted). For this reason, while I prefer encrypted system, having 20-30 times faster boot (when compared to encrypted /boot) is a major advantage for me. Or do I miss something here?

1 Like

No, you are correct. I have just added some reasonable bits to make the whole picture complete.
But there is another aspect: the entire purpose of full disk encryption is to make data inaccessible and resistant to be tampered with. And as we can see, it is impossible to reach that with encryption alone. So what's the point then?
The only immediate available solution would be a combination of disk encryption with TPM and/or Secure Boot keys signed kernel and initramfs, e.g. sbupdate, luks-tpm or manual setting up.

For me, the biggest point is that data is still secure. While anyone with direct access and good skills can still replace bootloader and/or /boot stuff, doing so won't magically decrypt LUKS-protected data. In other words, such a person will still have a very tough time decrypting LUKS data, and I'm sure he will fail in 99% of cases (unless this person is from some government agency, but Internet is still full of stories how agencies were not able to decrypt data in some cases even having direct access).

That is to say, we all know that no perfect doorlock exists - all can be unlocked by a highly-skilled professional, it's just matter of time. Despite this, I'm sure 100% of community members still lock their doors :slight_smile:

1 Like

But he doesn't have to. Simply adding malicious keylogger to initramfs will do the thing... It's not that difficult imho. I'm not an expert on this so I may be mistaken though.

1 Like

That makes sense, didn't think about it. In other hand, such scenario is probably very rare because your system must contain extremely valuable information if someone is willing to secretly place a keylogger (which probably means secretly breaking into house/office, doing the job, and then ensuring that owner doesn't suspect a thing) before trying to actually access your data. But your point is good, and I'm sure some users will have to think about it.

It's good to point out that even full disk encryption isn't going to be a 100% secure, nothing is in my opinion.
But just because one can't get 100% security this should not mean we settle on 0%, we shouldn't lose sight on why we are encrypting and what we want to prevent.

I encrypt all my drives (except bootloader) because I hold other peoples personal data (sports club members, customer data).
If I lose my laptop or someone breaks into my house and grabs my machine I am highly confident that that individual is not going to get access to my data. Finding someone with the skill (Linux + Keylogger) to break into my system doesn't make economical sense for someone who's just after my hardware.
But if the data was plain open they might check it out and see if they can make an additional € with selling my data or blackmailing.
On the other hand, if I was to store the Coca Cola formula I would surely apply additional measures (USB tokens, etc.)

2 Likes

But if you rule out a local attacker, because the door is locked, then why any disk encryption at all??

My prefered solution would be a bootloader on an external device. Then you can encrypt the whole disk, not leave an ESP partition on it which can't be encrypted.

For the same reason you lock the door at home. Because even some pro thief can unlock door in seconds/minutes, having door locked will cause problems for amateurs and will fully protect against persons who go from house to house at night and hope to find unlocked door, so they can get quick and easy profit. Having door locked (even if lock is simple) will prevent them from breaking in.

For very high level of security - absolutely. But not for every day tasks because extra gains in security wouldn't be worth extra pain in the a** in my opinion. For example, I have multiple laptops in my office (and these are used by college girls mainly), so using external device for boot would cause lots of problems. But simply having disk encrypted (even if /boot is not encrypted at all) will probably protect data in 100% of cases (like someone gets into office and steals laptop, etc.).

I say 100% because my business is not interesting for government agencies and/or super-professional hackers (at least I hope so), so even "weak" protection will do the job perfectly.

Forum kindly sponsored by