Mint 17.X to 20.X (but also Ubuntu) Full Disk Encryption (directory /boot included) - Using LUKS, SecureBoot & TPM 2.0

[linux22]

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Last update: 19 December 2020


Hi folks, tutorial "Dual boot for Linux Mint 20.X Full Disk Encryption with EFI STUB loader + Windows 10" has been updated today. See details at:
https://community.linuxmint.com/tutorial/view/2191



The other tutorials listed below will be updated within the end of April 2021. Support for LUKS AutoUnlock via TPM 2.0 (Trusted Platform Module) will also be included (experimental):

1) Linux Mint with Full Disk Encryption, directory /boot included - PC UEFI & HDD GPT - Booting with EFI STUB loader ---------- Major changes
https://community.linuxmint.com/tutorial/view/2438


2) Linux Mint - How to enable UEFI Secure Boot with your own Custom keys on PC UEFI & HDD GPT --------------------------------- Minor changes
https://community.linuxmint.com/tutorial/view/2496



I think I will merge all my tutorials, concerning Linux Full Disk encryption, in one single web page. This process will take place once I will have converted all my tutorials in pdf format files.
I think I will complete this process within the end of 2021.


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Update: 20 July 2020

Hi folks, my old guide/tutorial 'Linux Mint - How to enable UEFI Secure Boot with your own Custom keys on PC with UEFI & HDD with GPT' on Linux Mint Community at: https://community.linuxmint.com/tutorial/view/2360 has been deleted because malfuncioning and not updatable anymore.

The old tutorial has been replaced by this new one: https://community.linuxmint.com/tutorial/view/2496



--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------



Hi folks, I was trying to update my guide/tutorial 'Linux Mint - How to enable UEFI Secure Boot with your own Custom keys on PC with UEFI & HDD with GPT' on Linux Mint Community at: https://community.linuxmint.com/tutorial/view/2360 but when I send the update command I get an error and the web page remain unchanged. So I will copy and paste the entire tutorial inside a new one. When ready I will put the new tutorial web page address here.

Release within the end of August 2020.


--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Hello everyone. I am working on two new solutions for Linux Mint FDE with PC UEFI & HDD GPT.

You can find these new solutions at: https://community.linuxmint.com/tutorial/view/2438

You can download the last versions as tutorials in pdf format from my cloud storage. The links are at the end of the web page.

In this new project I am abandoning the standard boot loader GRUB, replacing it with EFISTUB.

These new solutions have the following PROS and CONS:

PROS:

- VERY FAST BOOTING
- VERY FAST SHUTDOWN
- VERY SIMPLE
- SUPPORT FOR TYPE 2 LUKS PARTITIONS (LUKS2)
- FULL DISK ENCRYPTION (FDE) REQUESTING ONLY ONE PASSWORD AT BOOT-UP
- NO LUKS KEYFILES REQUIRED
- WITHOUT OR WITH LVM (FOR ENABLING HIBERNATE FUNCTION)
- NO MORE HEADACHE FOR GRUB UPDATING AND/OR UPGRADING
- WORKS (WITH MINOR CHANGES) ALSO ON LINUX 32-BIT SYSTEMS (TESTED ON VIRTUAL MACHINES ONLY)

CONS:

- POINTLESS AND/OR DANGEROUS FOR FULL DISK ENCRYPTION (FDE) SYSTEMS IF SECURE BOOT IS DISABLED
- POOR CONFIGURATION OPTIONS (COMPARED TO GRUB)
- NOT COMMON / NOT STANDARD
- NEED GREATER EFI PARTITION SIZE (MINIMUM RECOMMENDED SIZE 1GB)

Please post here your opinion about this my new idea.


Hi folks, great news. Our concerns for an easy, standard and reliable FDE solution may be over, because LMDE 3 is out and it implements an FDE solution very similar to that indicated in my last tutorial at http://community.linuxmint.com/tutorial/view/2061. This solution can be activated by installing the distro with Calamares (an indipendent installer framework, available from the menu of the distro) and selecting its build-in FDE encryption function. If the installation with Calamares will become available as standard on all versions of Linux Mint we will have an easy, standard and reliable FDE solution available without further efforts. The same FDE solution is also available on distro Manjaro and it seems that it will be available with the new releases of Debian !!! (unluckily at the moment in Debian Live Testing it does not work)

Hello everyone, the promised new Debian method for the implementation of FDE (directory /boot included) with the standard cryptsetup package (version 1.7.3 and above) for Mint 19.X is ready (at the moment only for UEFI+GPT: ).

I have already tested this new configuration with Debian 9.3.0 and above, Ubuntu from 17.10 to 18.X, and now with Mint 19.X. It seems working smoothly.

The new configuration will not use LVM and will be working only with Debian and Debian-derived (Ubuntu, Mint, ecc.) distros equipped with cryptsetup version 1.7.3 and above.

You can read my guide/tutorial 'Linux Mint with Full Disk Encryption, directory /boot included - PC with BIOS & HDD with MBR' on Linux Community at: http://community.linuxmint.com/tutorial/view/2026

You can read my guide/tutorial 'Linux Mint with Full Disk Encryption, directory /boot included - PC with BIOS & HDD with GPT' on Linux Community at: http://community.linuxmint.com/tutorial/view/2231

You can read my guide/tutorial 'Linux Mint with Full Disk Encryption, directory /boot included - PC with UEFI & HDD with GPT' on Linux Community at: http://community.linuxmint.com/tutorial/view/2061 (This works only for Linux Mint 19 Tara and Ubuntu 17.10 and above)

You can read my guide/tutorial 'Linux Mint - How to enable UEFI Secure Boot with your own Custom keys on PC with UEFI & HDD with GPT' on Linux Mint Community at: https://community.linuxmint.com/tutorial/view/2496

You can read my guide/tutorial for 'Dual boot for Windows 10 + Linux Mint 17.X and 18 Full System Encryption (directory /boot included) - PC with UEFI & HDD with GPT' on Linux Mint Community at: http://community.linuxmint.com/tutorial/view/2191

Please feedback me if you succeed in installing and running Linux Mint using these solutions.

Thank you.

[Dupo]

Hi,

I used another method. I created the LVM on the hard disk or on the SSD, the boot partition is on an external USB key, and the decryption key is also on the same USB key for LVM. At startup, the LVM is decrypted automatically.

I will try your solution. Thanks.

[davschm]

Could anyone point me to instructions like this, but ones that leave the boot partition unencrypted?

[linux22]

Could anyone point me to instructions like this, but ones that leave the boot partition unencrypted?

Hello, if you need a Linux Mint installation with FDE and directory /boot unencrypted you can simply choose the standard Ubiquity installation with LVM and disk encryption.

But in this way your entire HDD will be overwritten. If you want to freely choose the partitions for your Linux Mint FDE installation (with directory /boot unencrypted) take a look at this link:

https://help.ubuntu.com/community/Encry ... iaUbiquity.

That was my first step for Linux Mint FDE and it is also the first item in my tutorials's useful links list.

Regards.

linux22

[Art-WooD]

Hi Linux22,

thank you a lot for your great howto on encryption. I have used it with success, but with little changes.
I have two hard disks, one SSD and one HDD. The / is on the SSD an remains unencrypted and the HDD contains /home, /var, /tmp and swap and is fully encrypted.
The only problem is now, that on boot the encrypted HDD is encrypted automatically by the keyfile.
Do you know how to change this setup in the way to enter the password instead of using the keyfile to encrypt the volume?

[linux22]

Hello, Art-WooD,

you only need to modify your /etc/crypttab file.
Set your volumes like that: sdbX_crypt UUID=xxx-yyy-zzz none luks
When you set none in the 3rd position of these lines the system will ask for the password at start-up.
Remember that you will be asked for the password of every volume listed in your crypttab file.

Regards.

linux22

[itc]

Hello linux22,

thanks for great tutorial. I will use this tutorial to encrypt my company notebook, but I would like to remove "Attempting to decrypt master key... Enter passphrase for(..)" information which appears during boot encrypted system - it will be perfect if instead of this information could be a black screen, some own information, or for example "-" character. Please, can you tell how to do this?

Best redards,
itc

EDIT:
Recently I've installed Linux MInt 17.3 using your tutorial. On my laptop (CPU Intel T7300, SSD, 4GB RAM) everything works well, maybe a little slower than without encryption. Till this moment I haven't noticed any freeze on mint logo during booting. In /boot/grub/grub.cfg I've changed locale from en_US to pl_PL, but this don't change "Attempting to decrypt master key... Enter passphrase for(..)" information - only after entering a correct password to encrypted disk, when GRUB system list are loaded, selected language appears. Still seeking how to change this.

[linux22]

Hello itc, I have read your message.

I think that if you want to remove the prompt "Attempting to decrypt master key... Enter passphrase for(..)" you must modify some GRUB package files.
My advice is to leave them untouched because a little mistake can turn your system unbootable and require a new GRUB package installation.

When you encrypt your system it slow down by an amount variable from 15% to 30%. Your system will slow down especially when you make an intensive use of HDD read and write, because every write operation must be encrypted and every read operation must be decrypted, all on the fly.

I have experimented the system freeze only sometimes, specially when you install your Linux FDE aside a Windows system, or when you stress your PC with a lot of installations and un-installations (on machine devoted for development).

You must choose your correct language during the Ubiquity installation.

Regards.

linux22

[CallumCameron]

Hi,

I tried this with the Mint 18 Cinnamon beta in VirtualBox, and with a few minor tweaks it worked perfectly. Thanks!

Here's what I changed:

• If you start Ubiquity using

  Code: Select all

  sh -c 'ubiquity -b gtk_ui'

  from the terminal, rather than using the launcher on the desktop (the '-b' flag is the extra part compared to what the launcher does), it won't try to install the bootloader at all, and so won't crash. This is actually quite important, since the installer does other things after installing the bootloader, which won't get done at all if it crashes (at the very least, apt-get's sources are messed up if the installer crashes).
• The patched '00_header' file is no longer needed on Mint 18 - that bug seems to have been fixed upstream.
• Since Ubiquity isn't handling the bootloader any more, it doesn't know which packages you will need. On a UEFI system, you have to run

  Code: Select all

  sudo chroot /mnt apt-get update

  and

  Code: Select all

  sudo chroot /mnt apt-get -y install grub-efi

  before modifying /etc/default/grub. (On BIOS systems the packages Ubiquity provides are fine.)

I also wrapped all this up in a script which automates as much as possible (i.e. all the shell commands), and guides the user through all the parts that can't be automated: https://github.com/CallumCameron/mint-encrypted-install. The script handles all four versions of the tutorial, and the repo also has scripts for fixing the bootloader if you can no longer boot (i.e. the 'emergency tools' appendix). Maybe it might be useful to link to this repo from the tutorials?

I have tried the BIOS and UEFI configurations in VirtualBox alongside Windows 10, and also with multiple Linux installations inside the encrypted container - and all worked fine. Hopefully I'll be using it on my real machine soon, too, when the final version of Mint 18 comes out.

Thanks,
Callum

[linux22]

Hello CallumCameron, I have read your post and I am happy about your success installing my Linux Mint FDE solutions.

I also have tested them with Mint 18 Beta and it seems working well, but the update of my tutorials will be available
only with the release of the definitive Mint 18 edition.

Until now I have choosed to not provide a script because a little mistake during the input of the devices involved can
lead to great damages on the HDDs of real PCs.

Regards.

linux22

[linux22]

Hello CallumCameron, I have read your scripts and I think you have done a great work.

I think I will test them within the end of summer, with the release of the new Linux Mint 18.

As I said I am still hesitant in providing a script for the automation of the Linux Mint FDE solutions.

You know that a little mistake during the input of the HDDs devices can lead to great damages on real PCs.

Thank you for your work and for your advices.


Regards.

linux22

[Trapper]

I just stumbled upon your FDE (including boot) community pages this AM. I have been using FDE with unencrypted boot partition for several years now. Decided to give you tutorial a try with LM 17.2 and the MBR scenario. Following the steps given I had a successful install. Thanks very much for providing us with these nice tutorials.

[Trapper]

I need to add something here. The reason why I did my install with LM 17.2 rather than LM 18 is because of a problem I encountered while attempting to install LM 18. Actually I also encountered that problem with LM 17.2 but your routine did complete and work with LM 17.2. I am wondering if I've missed reading something somewhere. ???

While doing the ubiquity install portion of your routine I get a grub install to sda error. In LM 18 that error negates doing anything further. With LM 17.2 I can close the error message and then select to not install grub in a popup box. From there I was able to continue with your routine and when I got to to the manual grub-install part grub did install to sda in LM 17.2. I attempted this full howto several times. Each time ubiquity produced the sda grub installation error.

On the same drive I did a standard non-encrypted install of LM 18 and it installed normally and installed grub to sda. I also did a FDE install with unencrypted boot and grub installed to sda correctly.

I find nothing in ubiquity that allows me to run an install without selecting a grub installation point.

[Trapper]

I find nothing in ubiquity that allows me to run an install without selecting a grub installation point.

After doing some further research, starting ubiquity with:

Code: Select all

sh -c 'ubiquity -b gtk_ui'&

seems to have resolved this issue.

[linux22]

Hello Trapper, I come back from a long holyday and I have read your message now.

I am happy about your success installing these FDE solutions.

Please feed me back about your further activity with these FDE solutions.


Regards.

linux22

[Grabow]

Thanks a lot linux22 for the great tutorial, I used it and had no problems whatsoever. Everything runs smoothly and I hope it will for a long time.

You write that people with suggestions concerning the tutorial can reach you here. My suggestion is to include a link to this thread

In the tutorial you mention that recovery/emergency advice is especially sought by people who are "upgrading their Linux version with the latest release or they are installing software packages that modifies GRUB and its configuration files".

Now I am trying to extract the advice for me what I can do to prevent this from happening.

First I will not install newer releases. That should be easy.

Second you mention software that modifies GRUB and its configuration files. How do I identify such a software before installation? Which programs are known for causing this problem?

What about the update manager, how do I know which updates I can install from there?

Are there other limitations when using the system?

[linux22]

Hello Grabow, I am sorry for my delay answering your questions. In fact I login in this forum rarely.
I think that your idea for including this thread in my tutorials is good.

I said that a system update/ugrade can modify the GRUB configuration and lead to an unbootable system.
In the past I have experimented a few cases where that happened, expecially when I was UPGRADING the system, i.e. switching from Mint release 17 to release 18. In fact, lately, I have not had problems UPDATING my system, i.e. installing the new version packages.

There are also some software packages that modify the GRUB configuration files. About one year ago a user wrote a post to me claiming that his GRUB configuration resulted corrupted after the installation of Xen ? (I do not remember well and the post text was lost during the last year Linux Mint servers hacking).

Anyway you can recover your GRUB configuration using the specific Appendix "Emergency tools - How to reinstall GRUB after ..." of my tutorials.

Thank you for your advice.

Regards.

linux22

[gurtz]

Hi linux22,

Thanks for the fantastic tutorial! It was extremely helpful.

I have a few question:

If I enter my password incorrectly, I will immediately be taken to the "grub rescue>" prompt. Is this what I should expect (rather than another chance to enter the password correctly)? Is there any security risk with someone having access to the grub console at this point?

Also, I realized recently that I had the incorrect volume group name in /mnt/etc/default/grub. I had "sda1_crypt", but it should have been something else (since I used different naming). It seemed to work anyway. Does the volume group name used in this file make any difference? How is it used? (I'm struggling to understand what GRUB_CMDLINE_LINUX is for.)

sudo sed -i 's/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX="cryptdevice=\/dev\/sda1:sda1_crypt"/' /mnt/etc/default/grub

Thanks again!

[linux22]

Hello gurtz, I have read your post. I suppose you have installed this FDE solution on a PC with BIOS and HDD with MBR.

If I enter my password incorrectly, I will immediately be taken to the "grub rescue>" prompt. Is this what I should expect (rather than another chance to enter the password correctly)? Is there any security risk with someone having access to the grub console at this point?

Yes, if you enter the wrong password you must restart your PC. You can also enter the grub console but without the correct password you can not open the LUKS volume.

Also, I realized recently that I had the incorrect volume group name in /mnt/etc/default/grub. I had "sda1_crypt", but it should have been something else (since I used different naming). It seemed to work anyway. Does the volume group name used in this file make any difference? How is it used? (I'm struggling to understand what GRUB_CMDLINE_LINUX is for.)

No, your syntax is correct. The GRUB_CMDLINE_LINUX use its own syntax, required for GRUB (for more detail see the useful links).
For more detail concerning GRUB_CMDLINE_LINUX see https://askubuntu.com/questions/575651/ ... ux-default.

Regards.

linux22

[gurtz]

Thank you for the reply! That makes sense.