Arch Linux

ajstein

Member

Registered: 2013-11-03

Posts: 36

[SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

I was reading the dm-crypt page when searching about partitionless setups, but I cannot find much to tell me how stupid my idea is.

I know I can boot grub with the initramfs off of a flash drive and basically put LVM in a LUKS container.  From previous experience, but maybe out of habit before an external /boot partition, I used cfdisk and created a dummy partition (sda1) of Linux LVM type using cfdisk and did cryptsetup /dev/sda1 to build the LUKS containter.

However, on a late night I started and finished encryption of a LUKS contain and /boot on a flash, I noticed it was failing and dug deeper to discover my LUKS container is whole disk, without a partition table (sda, NOT sda1).  I have read so far, and on a cursory glance GUI disk repairs will be confused.  But on a more advanced level, I am curious: does any do it without a partition table as well?  Is it any riskier if you backup your LUKS headers?

Sorry for the silly question.  Might save me another 5-6 hours to dd the disk with urandom and start fresh.  Thanks.

Last edited by ajstein (2015-02-13 07:38:57)

teateawhy

Member

From: GER

Registered: 2012-03-05

Posts: 1,138

Website

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

It is possible to use a disk without partition table, but i would not recommend it. See this thread:
https://bbs.archlinux.org/viewtopic.php?id=193111

frostschutz

Member

Registered: 2013-11-15

Posts: 1,417

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

The risk is that you may one day partition or install a bootloader to this disk by accident and then have destroyed your LUKS header [or filesystem metadata, or whatever is at the beginning of the disk] by doing so.

Partitions declare the disk to be in use (and thanks to partition types, usually also by what). It helps avoid confusion and errors. Without partitions, various programs will think the disk unused and make it the default choice for doing something to it.

Do you already have your data on it? While it's possible to add a partition table and not have to move/reencrypt all your data, by moving the LUKS header within its offset; reformatting is simpler if it's still fresh. You don't have to redo the urandom step (no one does it in the first place really, encrypting with random key is faster) and on SSD there is TRIM anyway...

Last edited by frostschutz (2015-02-11 00:44:48)

ajstein

Member

Registered: 2013-11-03

Posts: 36

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

Ok, well that makes sense.  What both of you mentioned seems to dovetail nicely into putting the LUKS header detached from the LUKS volume itself, there by getting me about as close as possible to 2FA with LUKS as I will probably realize, and is less hacky then GPG 1.4 crypted or OpenSSL crypted decryption keys with a passphrase.

Last edited by ajstein (2015-02-13 07:42:13)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,417

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

and is less hacky then GPG 1.4 crypted or OpenSSL crypted decryption keys with a passphrase.

I have encrypted keyfiles; but the tool I use to encrypt them is not GPG or OpenSSL but LUKS itself. I find that to be simpler than having to put yet another encryption tool into the Initramfs.

With external LUKS headers you have to be careful about leaving old copies of it about... if you change your passphrase, the old passphrase would still work with a copy of the old header.

Last edited by frostschutz (2015-02-13 10:21:52)

ajstein

Member

Registered: 2013-11-03

Posts: 36

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

I have encrypted keyfiles; but the tool I use to encrypt them is not GPG or OpenSSL but LUKS itself. I find that to be simpler than having to put yet another encryption tool into the Initramfs.

Oh, I'll bite, how do you do that?  I mean you have a secondary LUKS volume with the key?  I do not want unecrypted partitions on my disk or anyone messing with anyone (I hate my theoretically evil maid as much as the next guy, no matter how theoretical).  Have you accomplished this somehow, because I am most curious!

frostschutz

Member

Registered: 2013-11-15

Posts: 1,417

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

You can encrypt keyfiles with LUKS like this: https://wiki.gentoo.org/wiki/Custom_Ini … ed_keyfile

The whole /boot as a USB key that you keep in your pocket and only get out for actually booting the thing.

Your evil maid needs to steal both your USB key and your passphrase for the LUKS-key on the USB.

To make it work with mkinitcpio you'd have to put the whole thing in a hook.

/etc/initcpio/install/lukskey

#!/bin/bash

build() {
    add_file "/root/luks.key"
    add_runscript
}

help() {
    cat <<HELPEOF
LUKS-Encrypted Key
Using /root/luks.key
HELPEOF
}

/etc/initcpio/hooks/lukskey

#!/usr/bin/ash

run_hook() {
    cryptsetup -T 5 luksOpen /root/luks.key lukskey \
    && cat /dev/mapper/lukskey > /crypto_keyfile.bin
    cryptsetup luksClose lukskey
}

/etc/mkinitcpio.conf

HOOKS="... lukskey encrypt ..."

It makes use of the fact that the encrypt hook uses /crypto_keyfile.bin by default if it exists and no other crypt key parameter was specified.

If the lukskey step fails it will still ask you for a regular passphrase.

On my server I actually use fully automatic decryption without interaction, using a "hardware fingerprint". That only protects you from someone walking along your rack and popping your hard disks out, though. While the server knows its own key, the thief won't know without access to the entire hardware.

    # Produce key without newlines.
    echo -n $(
        (
            cat /sys/class/net/*/address
            grep 'MemTotal' /proc/meminfo # warning: may be unstable - possible alternative: tail /proc/iomem
            grep -vE '(MHz|bogomips)' /proc/cpuinfo
            grep -v sr0 /proc/partitions
        ) | sha512sum
    ) > /crypto_keyfile.bin

    # Reset key. (if applicable)
    echo -n foobar | cryptsetup luksChangeKey /dev/sda3 /crypto_keyfile.bin

For the network MAC address to be available at this point you have to add your network card module to the list of modules to be loaded early in the initramfs.

Last edited by frostschutz (2015-09-28 18:51:31)

AndreasEr

Member

Registered: 2013-12-03

Posts: 17

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

You can encrypt keyfiles with LUKS like this: https://wiki.gentoo.org/wiki/Custom_Ini … ed_Keyfile

The whole /boot as a USB key that you keep in your pocket and only get out for actually booting the thing.

Your evil maid needs to steal both your USB key and your passphrase for the LUKS-key on the USB.

To make it work with mkinitcpio you'd have to put the whole thing in a hook.

/etc/initcpio/install/lukskey

#!/bin/bash

build() {
    add_file "/root/luks.key"
    add_runscript
}

help() {
    cat <<HELPEOF
LUKS-Encrypted Key
Using /root/luks.key
HELPEOF
}

/etc/initcpio/hooks/lukskey

#!/usr/bin/ash

run_hook() {
    cryptsetup -T 5 luksOpen /root/luks.key lukskey \
    && cat /dev/mapper/lukskey > /crypto.key
    cryptsetup luksClose lukskey
}

/etc/mkinitcpio.conf

HOOKS="... lukskey encrypt ..."

It makes use of the fact that the encrypt hook uses /crypto.key by default if it exists and no other crypt key parameter was specified.

If the lukskey step fails it will still ask you for a regular passphrase.

On my server I actually use fully automatic decryption without interaction, using a "hardware fingerprint". That only protects you from someone walking along your rack and popping your hard disks out, though. While the server knows its own key, the thief won't know without access to the entire hardware.

    # Produce key without newlines.
    echo -n $(
        (
            cat /sys/class/net/*/address
            grep 'MemTotal' /proc/meminfo
            grep -vE '(MHz|bogomips)' /proc/cpuinfo
            grep -v sr0 /proc/partitions
        ) | sha512sum
    ) > /crypto_keyfile.bin

    # Reset key. (if applicable)
    echo -n foobar | cryptsetup luksChangeKey /dev/sda3 /crypto_keyfile.bin

For the network MAC address to be available at this point you have to add your network card module to the list of modules to be loaded early in the initramfs.

Hi. Sorry if this is a dumb question. I've setup full disk encryption on my laptop with a remote luks header on a USB. Now i want to add an extra step to require one more USB stick with a keyfile on it. So two USB devices in total.

This is my current setup:

Disk /dev/sda: 111,8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sdb: 7,3 GiB, 7807401984 bytes, 15248832 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe5ab319b

Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1  *     2048 15248831 15246784  7,3G 83 Linux

Disk /dev/mapper/enc: 111,8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/store-root: 25 GiB, 26843545600 bytes, 52428800 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/store-swap: 5 GiB, 5368709120 bytes, 10485760 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mapper/store-home: 81,8 GiB, 87820337152 bytes, 171524096 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

How do i read that guide for my current setup as i dont have a sda1 partition?

cryptsetup luksAddKey /dev/sda1 /dev/mapper/lukskey

frostschutz

Member

Registered: 2013-11-15

Posts: 1,417

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

Umm, in this example /dev/sda1 is the LUKS encrypted device, so you use whatever device you ... oh, err, in your case, you use the LUKS header, so... /mnt/usb/luksheader or whatever you have called it.

I'm not sure what the goal here is, though... if you're already using an external LUKS header, you pretty much have what I have with an encrypted keyfile, I mean... in a manner of speaking the external header is an encrypted keyfile already, so you're simply doubling what you already have. It increases complexity, not sure for what purpose. Is it easier to keep two sticks safe instead of just one?

Last edited by frostschutz (2015-02-18 20:59:58)

AndreasEr

Member

Registered: 2013-12-03

Posts: 17

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

Umm, in this example /dev/sda1 is the LUKS encrypted device, so you use whatever device you ... oh, err, in your case, you use the LUKS header, so... /mnt/usb/luksheader or whatever you have called it.

I'm not sure what the goal here is, though... if you're already using an external LUKS header, you pretty much have what I have with an encrypted keyfile, I mean... in a manner of speaking the external header is an encrypted keyfile already, so you're simply doubling what you already have. It increases complexity, not sure for what purpose. Is it easier to keep two sticks safe instead of just one?

Haha yes i understand that the remote header is enought. But for no reason at all i want to add an extra step

/dev/sda (encrypted SSD)
/dev/sdb (USB: LUKS header)
/dev/sdc (USB: keyfile)

and then a passphrase on top of that. So kind of a "three-way" authentication.

But anyways, Would /dev/mapper/enc be my encrypted device i should use in the 'cryptsetup luksAddKey' command? My setup is pretty mush identical to the guide on the wiki.

Last edited by AndreasEr (2015-02-18 21:22:59)

jobach

Member

Registered: 2015-09-28

Posts: 5

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

You can encrypt keyfiles with LUKS like this: https://wiki.gentoo.org/wiki/Custom_Ini … ed_keyfile

The whole /boot as a USB key that you keep in your pocket and only get out for actually booting the thing.

Your evil maid needs to steal both your USB key and your passphrase for the LUKS-key on the USB.

To make it work with mkinitcpio you'd have to put the whole thing in a hook.

/etc/initcpio/install/lukskey

#!/bin/bash

build() {
    add_file "/root/luks.key"
    add_runscript
}

help() {
    cat <<HELPEOF
LUKS-Encrypted Key
Using /root/luks.key
HELPEOF
}

/etc/initcpio/hooks/lukskey

#!/usr/bin/ash

run_hook() {
    cryptsetup -T 5 luksOpen /root/luks.key lukskey \
    && cat /dev/mapper/lukskey > /crypto.key
    cryptsetup luksClose lukskey
}

/etc/mkinitcpio.conf

HOOKS="... lukskey encrypt ..."

It makes use of the fact that the encrypt hook uses /crypto.key by default if it exists and no other crypt key parameter was specified.

/crypto.key didn't work for me, instead the encrypt hook expected the keyfile to be found at /crypto_keyfile.bin, as one can also read here: https://wiki.archlinux.org/index.php/Dm … _initramfs

Since your post is 8 month old, this might be version-related (I'm using cryptsetup 1.6.7-1 and Kernel 4.1.6-1-ARCH), but I find it hard to believe that something like that gets changed by an update.

Last edited by jobach (2015-09-28 18:24:58)

frostschutz

Member

Registered: 2013-11-15

Posts: 1,417

Re: [SOLVED] Risk of Doing Full Disk dm-crypt/LUKS without partitions

Huh. crypto_keyfile.bin is correct, not sure how I got it wrong in my post. Good catch, and sorry for the inconvenience.

Definitely not update related as the other example in the same post used the correct filename.

Last edited by frostschutz (2015-09-28 18:52:29)