Full Encryption Setup with /home on it's own partition

[benni]

Hey folks,
I am new to Suse, coming from the Linux Mint side and changed after my 10yrs Laptop went for a bath. When encryption came up with Snowden, my Laptop was not fit enough (and still had a HDD). Now I have the hardware, but my knowledge got old.

So here I am, asking whether you can help me fiddle a bit through this.

I want my /home on its own partition (like old times) to access it in an easy way also from other systems. I did the installation and ended up with this setup:

nvme0n1
│                                                                               
├─nvme0n1p1
│    vfat   FAT32 SYSTEM    6878-33F7                                           
├─nvme0n1p2
│                                                                               
├─nvme0n1p3
│    ntfs         Windows   B2547A96547A5D53                                    
├─nvme0n1p4
│    ntfs         WinRE_DRV 20A27A9FA27A795C                                    
├─nvme0n1p5
│ │  crypto 2               def00f07-2d43-4edb-a1e1-e2feb4bf64ee                
│ └─cr_root
│    btrfs                  ef5d2365-91d8-4add-a941-dd7fe7dbda95   24,5G    37% /var
│                                                                               /usr/local
│                                                                               /srv
│                                                                               /boot/grub2/x86_64-efi
│                                                                               /opt
│                                                                               /root
│                                                                               /boot/grub2/i386-pc
│                                                                               /.snapshots
│                                                                               /
├─nvme0n1p6
│ │  crypto 2               405c1eb6-9fa0-4877-9c3d-725c1654e980                
│ └─cr_swap
│    swap   1               8f1bfa69-4edc-4d7b-85f3-ed246d1d80f0                [SWAP]
├─nvme0n1p7
│ │  crypto 2               7551d36e-f9ee-45fd-ae09-d2c83eebe36d                
│ └─cr_home
│    xfs                    e7693fab-a2cf-441e-a6bc-83b29f34337c  245,5G     3% /home
└─nvme0n1p8
     vfat   FAT16           C905-6190                             503,2M     0% /boot/efi

First I noticed: /boot/efi seems to be quite empty! Is that correct? I guess that this is loaded by the UEFI Bios and unlocks the /LVM/LUKS2 Container, but that is just a vague guess.

Then I ended up entering two passwords. Which of course makes sense.
So I found this guide. My plan is now to adapt it the way that the encrypted /boot/grub2/x86_64-efi will unlock /home that way only one time entering keys would be sufficient. Is that the right way to do it?

Just to recall the guide: There is a key generated, which is added to the LUKS2 Container of / . Instead I would create a key which is added to the container of /home. The rest of the guide is adapted accordingly.

My next step would be to store the key in the TPM2.0 Module. What I couldn’t figure out was whether that would introduce any conflicts with my still existing Win11 installation?
Unfortunately the TPM2.0 installation section is called depreciated and links to the guide: MicroOS/FDE

I am feeling a bit unsafe here. Reading that latter guide more carefully I come to the conclusion I have done the wrong installation process and I should not use grub2?

I would love to have some hints from you.
Thanks in advance!

[arvidjaar]

@benni

Then I ended up entering two passwords. Which of course makes sense.

You do not tell for what these passwords are or at which point during boot you are prompted so there is no way to guess whether it makes sense or not. You have three encrypted devices, so you can have any number of prompts from 1 to 3 depending on your setup.

Are these LUKS containers using the same or different passphrases?

@benni

/boot/grub2/x86_64-efi will unlock /home

/boot/grub2/x86_64-efi is a directory, it cannot unlock anything.

Start with providing the missing information I mentioned.

@benni

whether that would introduce any conflicts with my still existing Win11 installation?

No.

@benni

I should not use grub2?

grub2 supports TPM2 unlock too. I do not know who and why claimed it is obsolete; last commit in fde-tools was on September 30, 2025.

It is true that grub2 unlocks root too early, when most of the context was not available and could not be verified. So, it is less secure. OTOH grub2 will discard key obtained from TPM2 when user enters menu, so it mitigates this problem (attacker cannot get access to the decrypted root content while requesting to boot something else). It will only forward the key to the booted system when doing autoboot.

[pavinjoseph]

@benni

First I noticed: /boot/efi seems to be quite empty! Is that correct? I guess that this is loaded by the UEFI Bios and unlocks the /LVM/LUKS2 Container, but that is just a vague guess.

This is correct!

/bootwhich contains the initramfs is unlocked by grub. Since the initramfs is encrypted, you want to store the LUKS key files to decrypt all volumes (root, home, etc.) inside the initramfs

I have written a post about it:

How to automatically unlock LUKS encrypted root filesystem

Hello everyone, I have a fairly standard/default LUKS encrypted volume with swap and btrfs root filesystem residing in it. The subvolumes are in their standard layout too. Only change I’ve made is to add an ext4 partition to store kdump. pavin@suse-pc:~> lsblk -f /dev/nvme0n1 NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS nvme0n1 …

@benni

My next step would be to store the key in the TPM2.0 Module

I would recommend not doing this as the device would happily unlock itself if someone has physical access to it
Enter the passphrase once for grub on cold boot, but use key file unlock and kexec reboots for later.

[benni]

Hey folks,
thank you so much for your answers.

@arvidjaar

You have three encrypted devices, so you can have any number of prompts from 1 to 3 depending on your setup.

That was a very good hint. I checked and the passwords asked are at first is nvme0n1p5(no surprise ) directly after statup. Then I get into grub and than I am asked for SWAP(!). I thought my second password would be for /home but no, /homeseems to be done automatically. That of course changes my plans a bit.

Yes they are all using the same passphrases, also for swap.

@pavinjoseph

I would recommend not doing this as the device would happily unlock itself if someone has physical access to it
Enter the passphrase once for grub on cold boot, but use key file unlock and kexec reboots for later.

This is a very valid thought even though it can be countered with TPM + PIN and a very very much more difficult LUKS-Key than I am using currently. Of course you need to keep the real LUKS-Key somewhere as a backup. A PostIt at the screen is recomended for that, I have heared.

Thank you for the posts. I will read through them. From my understanding I need to add a key for Swap to the crypttab. Than I should be able to boot with one passphrase.

Thank you so much!

[arvidjaar]

@benni

/homeseems to be done automatically
…
they are all using the same passphrases

systemd caches passphrases and tries to reuse them. For root it is grub2 that prompts for passphrase, but it forwards decrypted key itself, not the passphrase, to the loaded operating system, so this passphrase is not reused.

@benni

This is a very valid thought

That is why we have login screen where users need to enter a valid password (and know the valid user name to start with). Of course, if you use automatic login then automatic LUKS unlock is not desirable, although it again depends on your threat model.

@benni

I need to add a key for Swap to the crypttab. Than I should be able to boot with one passphrase.

No. Then you will be prompted for the passphrase for cr_home.

[benni]

@arvidjaar

No. Then you will be prompted for the passphrase for cr_home

because when I add the key to crypttab than there is no more cached key to unlock, right?
But why does system not use the cached key a third time for swap?

ahh wait: because of this?:

@arvidjaar

OTOH grub2 will discard key obtained from TPM2 when user enters menu, so it mitigates this problem (attacker cannot get access to the decrypted root content while requesting to boot something else). It will only forward the key to the booted system when doing autoboot.

Putting it all together, it leads to the conclusion, that I need to set up a key and add it to crypttab for both, swap and home.

[arvidjaar]

@benni

But why does system not use the cached key a third time for swap?

You confuse key (used to en-/de-crypt data in the LUKS volume) with passphrase (used to en-/de-crypt key stored in the LUKS header).

[benni]

okay, than beeing more precise. Why does it not reuse the cached passphrase for swap? Any obvious reasons?

[arvidjaar]

@benni

Why does it not reuse the cached passphrase for swap?

I already explained it in Full Encryption Setup with /home on it's own partition - #5 by arvidjaar.

[benni]

Hey arvidjaar,
maybe it’s a language thing. I do not really understand why the cached passphrase (handed over to system) is not used for swap. But whatever it is, it’s not that important.

I followed the guide, added keys for/home and swap correspondingly, restarted the service e voila. With a new start of the system I just needed to enter one password.
Last thing to do is to add a cycle time (figured out that a long waiting time is a known issue) and then I am done.

Thanks to you two for your fast responses.
Best