[SOLVED] Headerless LUKS-root-partition

neurofnord · 2012-03-22 19:10:04

Hi,

I want to boot from USB and mount a encrypted root-partition of my harddisk.
This partition should have a detached header which is stored on the USB-device, so the root-partition looks like an empty ext4-partition.
I've read in the man-pages of cryptsetup that this is possible, but I'm not sure where I have to change the cryptsetup calls.

I would install Archlinux with a normal LUKS-root-partition and install /boot and grub to the USB-device.
Then I would move the LUKS-header of the root-partition to the USB-device.
But then I don't know where on the /boot-partition I'd have to make changes to tell the devicemapper to use the headerimage from my USB-device to de-/encrypt the root partition.

Someone has done something similar or knows how I could accomplish this?

Thanks for your time!

Last edited by neurofnord (2012-03-23 12:35:46)

neurofnord · 2012-03-22 20:02:04

After reading the Archwiki to mkinitcpio, I think I would have to specify the header-data as kernelparameters of grub's menu.lst.
This seems to be possible for legacy cryptsetup volumes which I assume is an dm-crypt partition which was created with "cryptsetup create" and has no LUKS-header.

I'll try that and post my results.

Last edited by neurofnord (2012-03-22 20:05:14)

Isola · 2012-03-22 20:20:29

This bash script will need modification:

/lib/initcpio/hooks/encrypt

It's the file taking care of encrypted roots.
Make sure you take a backup of it, because it will be overwritten when cryptsetup is upgraded/re-installed.
You'll need to know bash to do the modifications you want.

After you've modified it you need to generate your initramfs to test:

mkinitcpio -g /boot/initramfs-linux.img

The above command affects the default initramfs, leaving initramfs-fallback intact. That way you can still boot if there is an error in the modifications you made.

Overwriting files like that isn't recommended though. Instead, when you got it working, I would advice you to make a custom hook and use that in your /etc/mkinitcpio.conf

neurofnord · 2012-03-22 21:43:21

Thanks for the answer.

That's interesting.
I was looking at that file before with an archlinux install with luks-root, but there where only a few lines which where responsible for loading the encryption-modules, but none of them for devicemapping.
I'm currently on my laptop, which isn't encrypted yet, and there the hook-file is way more complex and contains calls to cryptsetup.
Same goes for the live-cd.

So the procedure then would be:
1) boot from livecd
2) update cryptsetup (only current version supports detached headers)
3) create partitions
4) create and mount root-partition with cryptsetup and --header header.img
5) install archlinux
6) create and register a new hook that mounts the encrypted partitions with the luks-header from usb
7) generate new initramfs
8) reboot

am I right?

Last edited by neurofnord (2012-03-22 22:26:02)

Isola · 2012-03-22 23:54:52

I would personally do it in a different way:
Encrypt partition, install and get everything working without --header

Then I would:

cryptsetup luksHeaderBackup /dev/your/root/disk/partition/1 --header-backup-file /root/header.img

Add the header file to the initramfs, /etc/mkinitcpio.conf

...
FILES="/root/header.img"
...

Modify or create a new encrypt hook which supports --header.
Make sure said hook present in /etc/mkinitcpio.conf HOOKS line

Generate initramfs

mkinitcpio -g /boot/initramfs-linux.img

Then boot and see if it's using the header. The header.img will be included in the initramfs, which is on the USB's boot partition.
I don't know where the file will be inside the initramfs, but that should be possible to check with:

pacman -S atool cpio
cp /boot/initramfs-linux.img /root/
cd /root
file initramfs-linux.img # To see what you compressed it with. Default is gzip
mv initramfs-linux.img{,.gz} # Add .gz to the end because I don't think gzip wants to decompress otherwise
gzip -d initramfs-linux.img.gz
atool -x initramfs-linux.img
find -name header.img

If you don't have the header.img inside the initramfs, then the filesystem where it is needs to be mounted during the initramfs process during boot, which probably makes things more complicated.

Isola · 2012-03-23 00:16:58

Looking at the script /lib/initcpio/hooks/encrypt around line 60, something like this could do it:

        for cryptopt in ${cryptoptions}; do
            case ${cryptopt} in
                allow-discards)
                    echo "Enabling TRIM/discard support."
                    cryptargs="${cryptargs} --allow-discards"
                    ;;
                # Header start
                header)
                     echo "Using custom header"
                     cryptargs="${cryptargs} --header /header.img"
                     ;;
                # Header end
                *)
                    echo "Encryption option '${cryptopt}' not known, ignoring." >&2
                    ;;
            esac
        done

It's very dirty though!

edit: Ops I forgot, you need to add "header" as an option in bootloader to make it use the header. Example:

cryptdevice=/dev/your/root/disk/partition/1:root:header

Last edited by Isola (2012-03-23 00:55:32)

neurofnord · 2012-03-23 11:04:55

wow, thanks a lot for the effort
I'll try it and post my results...

neurofnord · 2012-03-23 12:30:01

Yay, works like a charm :3

I had to do two things on top:
1) adding the loop-module to mkinitcpio.conf (seems to be required for the header-image)
2) changing /lib/initcpio/hooks/encrypt a bit more. Before the part which calls cryptsetup to mount is an if-statement which checks if the partition has a luks header. because i want my partition to look like an ext4 I had to change that if statement to "partition has luksheader" or "kernel was called with ...:header".

Thanks again for the great help

Last edited by neurofnord (2012-03-23 12:31:43)

bluephoenix47 · 2012-04-01 04:04:18

So I've been trying to do just this, and while this thread helped a lot, but I seem to have problems trying to boot from the header file. I get the following error:

"Requested offset is beyond real size of device"

It boots fine when I boot normally, i.e. without the header file. But, when I specify --header /tmp/header.img in my encrypt hook, I get the above error. I've ensured /tmp/header.img exists in my initramfs, and I've verified the header via cryptsetup isLuks. I didn't add any other options to the encrypt hook beyond --header, so I'm really confused about what's going on.

Let me know if either of you have thoughts.

Last edited by bluephoenix47 (2012-04-01 04:05:29)

hgabreu · 2014-07-15 00:57:47

Hate to necro-bump, but I think this is important.

This thread helped me a lot setting up an entire system encryption with separate header allowing two factor authentication and deniable encryption, but I had to do a lot of searching and trial-and-error to get it working that a wrote a section on ArchWiki. So, for future readers, here's it:
Dm-crypt/Device encryption#Encrypt entire system using a seperate Luks header

KairiTech · 2014-07-30 22:06:48

I followed your instructions but all I ever get is a repeated prompt for the root partition passphrase with no errors no matter what I enter. Just the passphrase prompt every time I hit the [Enter] key.

What might I be missing?

Looks like the link in your post is incorrect. Should be?

https://wiki.archlinux.org/index.php/Dm-crypt/Specialties#Encrypted_system_using_a_remote_LUKS_header

Those were the instructions I followed.

Last edited by KairiTech (2014-08-02 16:20:43)

KairiTech · 2014-08-02 16:20:58

I've noticed something interesting. I can manually open the root device using the header file on the USB ESP or on any other type of physical media but not if I extract it from the initramfs into RAM. The passphrase prompt appears as expected but nothing happens and there is no error messages displayed when the console prompt returns.

hgabreu · 2014-08-03 20:13:35

Yes, I got that behavior too since the last update (~7 days ago). I just reverted it and haven't looked at it yet. I'll try to get it working today and will post back here.

About the article: yeah, it got moved. That's the correct link now.

KairiTech · 2014-08-05 16:32:28

Additionally, a key file on the USB works fine if I do not modify the encrypt hook but with the modifications is reported as either invalid (when located on the USB) or cannot be opened (when located in the initramfs).

faultylee · 2014-08-07 08:59:31

KairiTech wrote:

I've noticed something interesting. I can manually open the root device using the header file on the USB ESP or on any other type of physical media but not if I extract it from the initramfs into RAM. The passphrase prompt appears as expected but nothing happens and there is no error messages displayed when the console prompt returns.

I'm getting the same problem as well since I updated yesterday. Downgrading cryptsetup from 1.6.5.2 to 1.6.5.1 resolve the issue.

hgabreu · 2014-08-07 12:39:46

In my case I had to downgrade to 1.6.4, 1.6.5-1 didn't worked. Which is weird, because the issue appeared when I upgraded 1.6.5-1 to 1.6.5-2.
I already sent a message to the cryptsetup list, I'll post back here when there's any update/solution and will update the ArchWiki entry accordingly.

faultylee · 2014-08-08 10:47:23

hgabreu wrote:

In my case I had to downgrade to 1.6.4, 1.6.5-1 didn't worked. Which is weird, because the issue appeared when I upgraded 1.6.5-1 to 1.6.5-2.
I already sent a message to the cryptsetup list, I'll post back here when there's any update/solution and will update the ArchWiki entry accordingly.

Sorry, you're right, I actually downgraded to 1.6.4 out of panic, and then upgraded to 1.6.5-1.

hgabreu · 2014-08-12 13:09:30

One of the maintainers of cryptsetup confirmed the problem and says it's already fixed in git and will be fixed on version 1.6.6 which, he says, will be released in a few days. Check his answer here:
http://article.gmane.org/gmane.linux.ke … crypt/7579

KairiTech wrote:

Additionally, a key file on the USB works fine if I do not modify the encrypt hook but with the modifications is reported as either invalid (when located on the USB) or cannot be opened (when located in the initramfs).

KairiTech, indeed, this setup was not intended to use with a key file, although I can't see why it wouldn't work. But maybe more important, if you're using a keyfile, you have the same type of authentication factor as using a separete header, therefore only one factor. Using a separate header is just for deniable encryption in this case.

If you get it to work though, please update the wiki entry to add this option.

KairiTech · 2014-08-23 14:02:01

cryptsetup 1.6.6-1 works perfectly with the header in the initrams and the keyfile on the USB. I use a key file so that I don't have to manually enter a passphrase during boot.

The cryptkey entry in the kernel command line takes the form shown below for the keyfile and is documented here :

cryptkey=UUID=XXXX-XXXX:vfat:/path/to/keyfile

I should add that I'm still waiting for systemd-cryptsetup@.service to start supporting detached headers. Until then I have a script for that.

Last edited by KairiTech (2014-09-03 13:03:30)

gavinhungry · 2014-11-14 05:33:00

Hope I didn't reinvent a wheel here.

I wanted to keep the header out of the initramfs, because I want to use the same USB flash drive to boot multiple machines (seperate GRUB entries), then keep the header(s) either on the /boot filesystem, or some entirely different flash drive.

I added a "cryptheader" option that is akin to the "cryptkey" option (although without the raw read support, just pick a file on a device).

cryptheader=UUID=XXXX-XXXX:vfat:/path/to/header

Hook patch here: https://github.com/gavinhungry/patches/ … ader.patch

Last edited by gavinhungry (2016-10-12 12:17:28)

starfry · 2014-11-28 16:45:50

Wow, that's just what I've been looking for Gavin. It looks like your end goal is the same as mine - to have a key that you need to use to boot, and one that will work on multiple systems.

I am working on patching the Grub crypto stuff so that you can use a detached header and I have got it working. I needed to do the initrd side of it but you've saved me from having to do that.

Do you plan to try and get this enhancement into the mainline?

I'm working on the Grub side of it, I have a little tidying up to do but it shouldn't be long. Right now, I can boot a system with an encrypted headerless root, with the boot loader and header being stored on a USB stick so that, without the key, there'd no chance of booting my machines.

update anyone wishing for extended crypto capabilities in Grub, including plain mode, detached luks headers and key files, is welcome to try my patches .

Last edited by starfry (2015-02-12 09:55:26)

starfry · 2014-12-09 13:19:27

FYI feature request 42851 has been raised for this patch.

I also raised a feature request 43054 to support key file offsets in a similar fashion to cryptsetup (--keyfile-offset and --keyfile-size).

These two together allow boot parameters like these:

cryptheader=<dev>:<fstype>:<header> 
cryptkey=<dev>:<fstype>:<keyfile>:<offset>:<size>

Arch Linux

#1 2012-03-22 19:10:04

[SOLVED] Headerless LUKS-root-partition

#2 2012-03-22 20:02:04

Re: [SOLVED] Headerless LUKS-root-partition

#3 2012-03-22 20:20:29

Re: [SOLVED] Headerless LUKS-root-partition

#4 2012-03-22 21:43:21

Re: [SOLVED] Headerless LUKS-root-partition

#5 2012-03-22 23:54:52

Re: [SOLVED] Headerless LUKS-root-partition

#6 2012-03-23 00:16:58

Re: [SOLVED] Headerless LUKS-root-partition

#7 2012-03-23 11:04:55

Re: [SOLVED] Headerless LUKS-root-partition

#8 2012-03-23 12:30:01

Re: [SOLVED] Headerless LUKS-root-partition

#9 2012-04-01 04:04:18

Re: [SOLVED] Headerless LUKS-root-partition

#10 2014-07-15 00:57:47

Re: [SOLVED] Headerless LUKS-root-partition

#11 2014-07-30 22:06:48

Re: [SOLVED] Headerless LUKS-root-partition

#12 2014-08-02 16:20:58

Re: [SOLVED] Headerless LUKS-root-partition

#13 2014-08-03 20:13:35

Re: [SOLVED] Headerless LUKS-root-partition

#14 2014-08-05 16:32:28

Re: [SOLVED] Headerless LUKS-root-partition

#15 2014-08-07 08:59:31

Re: [SOLVED] Headerless LUKS-root-partition

#16 2014-08-07 12:39:46

Re: [SOLVED] Headerless LUKS-root-partition

#17 2014-08-08 10:47:23

Re: [SOLVED] Headerless LUKS-root-partition

#18 2014-08-12 13:09:30

Re: [SOLVED] Headerless LUKS-root-partition

#19 2014-08-23 14:02:01

Re: [SOLVED] Headerless LUKS-root-partition

#20 2014-11-14 05:33:00

Re: [SOLVED] Headerless LUKS-root-partition

#21 2014-11-28 16:45:50

Re: [SOLVED] Headerless LUKS-root-partition

#22 2014-12-09 13:19:27

Re: [SOLVED] Headerless LUKS-root-partition

Board footer