| View previous topic :: View next topic |
| Author |
Message |
pietinger
Guru
Joined: 17 Oct 2006
Posts: 520
Location: Bavaria
|
 Posted: Thu Apr 02, 2020 12:33 am Post subject: Full Disk Encryption WITHOUT Initramfs or Grub |
 |
|
How to (Secure-) Boot the kernel straight from UEFI(-bios) into a fully encrypted root-partition with plain dm-crypt encryption without using initramfs/initrd or grub. This was not possible so far. Now we have the new kernel(-module) parameter "dm-mod.create=" (dm_init).
Objective:
* Secure using the new parameter for built-in dm-crypt-functionality
* With a SSD it must not happen to save the masterkey into a file on it (even with a hd you cant really wipe a file when using a journaled filesystem). This means it is required to save the masterkey into RAM (=tmpfs) or to a stick. (I used a stick because we have to save the key in any case).
I have:
* A working Gentoo Installation on /dev/sda4 as root (containing home also) with a monolithic (signed) stub-kernel in /boot/EFI/Boot (/dev/sda2)
* An empty partition (/dev/sda5) for my new fully encrypted root partition
* An USB-Stick for the final kernel (and the masterkey if no second stick available)
You:
* MUST have openRC; (I dont know anything about systemd)
* needn't have a monolithic signed kernel; just a working kernel
Here is my course of action:
| Code: | - boot with "Gentoo minimal CD" (I used version 2020-03-15)
! be fast with input 12 for german keyboard (or you boot again :-)
# clear
# ls /sys/firmware
! check if /sys/firmware/efi exists -> yes -> ok, it was really an uefi boot
# mkdir -p /mnt/stick
- connect your properly fat32-formatted stick (if not formatted see chapter "format stick" later)
# lsblk
! check if /dev/sdb is really your stick; (probably it is /dev/sdc or /sdd if you have more than one hd or ssd; then use this instead of sdb1 in the next command)
# mount -t vfat /dev/sdb1 /mnt/stick
# mkdir /mnt/old
# parted /dev/sda p
! be sure you are using the correct root partition; (my old root-partition is sda4; again, use your old root-partition instead in next command)
# mount -o ro /dev/sda4 /mnt/old
# mkdir /mnt/cr
! "cr" means crypt-root; (its just a name; of course you can use what you want) |
Now we are ready to (a) create a random generated masterkey and setup the new root partition, (b) copy the old root partition into the new encrypted root partition, (c) compile the kernel with the new parameter in the kernel command line and (d) edit our fstab:
| Code: | ! (a)
# dd if=/dev/random of=/mnt/stick/mkey bs=1 count=64
! again, check your partitions and use yours instead of my sda5
# cryptsetup -d /mnt/stick/mkey -c aes-xts-plain64 -s 512 --allow-discards create cr /dev/sda5
! type YES in uppercase letters
# umount /mnt/stick
# mkfs.ext4 -E discard /dev/mapper/cr
# mount /dev/mapper/cr /mnt/cr
! (b)
# rsync --stats --progress --numeric-ids -axAhHSP /mnt/old/ /mnt/cr
... have a coffee
# umount /mnt/old
! (c)
# mount -t proc /proc /mnt/cr/proc
# mount --rbind /sys /mnt/cr/sys
# mount --rbind /dev /mnt/cr/dev
# cd /mnt/cr
# chroot /mnt/cr /bin/bash
# . /etc/profile
! now we are in our encrypted new root and we should give root a new password ->
# passwd
# cd /usr/src/linux
# make menuconfig
! now memorize your secret master key to be able to put it into the built-in kernel command line ...
... joke
- select "Processor type and features" and then the line under "Built-in kernel command line"
- You should be now in "Built-in kernel command string". Type in
> dm-mod.create="cr,,,
- press ALT-F2 and type the following command
# dmsetup table --concise --showkeys /dev/mapper/cr
! mark the whole line beginning with "rw,0..." (so the first marked character is r)
- press ALT-F1 - you are now back in the kernel configuration menu
- insert with your mouse the whole bunch of your marked line; See example below
- type the closing " character behind allow_discards (I mean this-> " )
- type a blank and add
> root=/dev/dm-0
- go back to x:x this is major:minor of your root partition, add 16 to minor or not; read now below !!
- dont forget the other settings for efi stub; See example below
- save and exit
# make
- take a second USB-Stick and connect it or use the first stick again
# mkdir -p /mnt/stick
# mount -t vfat /dev/sdb1 /mnt/stick
# mkdir -p /mnt/stick/EFI/BOOT
# cp arch/x86/boot/bzImage /mnt/stick/EFI/BOOT/bootx86.efi
# umount /mnt/stick
! (d)
! you should use label or UUID in your fstab (because if you boot from a stick, it become sda and your disk is now sdb)
# nano -w /etc/fstab
- change your entry for the root partition to this
> /dev/dm-0 / ext4 defaults,noatime 0 1
> PARTLABEL=swap none swap sw 0 0
# exit
# reboot
---
- press your BIOS' favorite key to get into bios boot override and select the stick for booting
.. pray |
Kernel-Config:
| Code: | Processor type and features --->
[*] EFI runtime service support
[*] EFI stub support
[*] Built-in kernel command line
(dm-mod.create="cr,,,rw,0 [size] crypt aes-xts-plain64 [your long masterkey in hex] 0 x:x 0 1 allow_discards" root=/dev/dm-0) Built-in kernel command string
Device Drivers --->
[*] Multiple devices driver support (RAID and LVM) --->
[*] Device mapper support
[*] Crypt target support
[*] DM "dm-mod.create=" parameter support
Cryptographic API --->
[*] XTS support
[*] SHA1 digest algorithm (SSSE3/AVX/AVX2/SHA-NI)
[*] SHA256 digest algorithm (SSSE3/AVX/AVX2/SHA-NI)
[*] SHA512 digest algorithm (SSSE3/AVX/AVX2)
[*] SHA224 and SHA256 digest algorithm
[*] AES cipher algorithms
[*] AES cipher algorithms (AES-NI)
[*] User-space interface for hash algorithms
[*] User-space interface for symmetric key cipher algorithms |
I dont recommend to put your kernel into the boot partition at your hd or ssd. If you loose your notebook, you maybe be safe against script kiddies. But not for an expert, examining your unencrypted kernel in this partition. Removing the key (=stick) is the most secure way to protect your data on your encrypted root partition.
At first I had a kernel panic with:
device-mapper: table: 253:0 crypt: Device lookup failed
device-mapper: ioctl: error adding target to table
The reason was simple (it took me hours) ... When booting with a stick, it become /dev/sda and my SSD became /dev/sdb. But in kernel was 8:5 (major/minor) of my SSD-partition 5, when it was sda. After booting with the stick, partition 5 of my SSD is then 8:21. So I had to go into my encrypted partition and changed (via make menuconfig) this setting in the kernel command line. So, THINK, if you want to put your new kernel into the boot partition of your ssd (I dont recommend) then you must not add 16, because there is no change of the minor nr.
Create a bootable USB Stick:
| Code: | - connect your USB stick
# lsblk
! check if /dev/sdb is really your stick; (probably it is /dev/sdc or /sdd if you have more than one hd or ssd; then use this instead of sdb1 in the next command)
# parted -a optimal /dev/sdb
> p
! if any delete with "rm X"
> mklabel gpt
> unit mib
> mkpart primary 1 128
> name 1 boot
> set 1 boot on
> q
# mkfs.fat -F 32 /dev/sdb1
! setting "boot on" is important to get the ESP flag for this partition, so UEFI can find the kernel in it
! of course you can make more partition and use them |
List of Links I used
https://www.redhat.com/archives/dm-devel/2019-February/msg00108.html
https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/dm-init.html
https://gitlab.collabora.com/koike/dm-cmdline-test/-/blob/master/dm-cmd-test.sh
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt
https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions
https://www.thenautilus.net/SW/gentoo-luks-secureboot/
http://man7.org/linux/man-pages/man8/dmsetup.8.html#CONCISE_FORMAT
https://wiki.gentoo.org/wiki/Dm-crypt_full_disk_encryption
https://wiki.gentoo.org/wiki/Dm-crypt
Last edited by pietinger on Thu May 14, 2020 9:29 pm; edited 4 times in total |
|
| Back to top |
|
 |
msst
Apprentice
Joined: 07 Jun 2011
Posts: 254
|
| Posted: Thu Apr 02, 2020 9:05 pm Post subject: |
|
|
This sounds interesting, but is there an option to get this going via a password prompt, using dm-crypt luks?
Currently I use such a setup with an initramfs. |
|
| Back to top |
|
|
pietinger
Guru
Joined: 17 Oct 2006
Posts: 520
Location: Bavaria
|
| Posted: Thu Apr 02, 2020 10:38 pm Post subject: |
|
|
| msst wrote: | | [...]via a password prompt, using dm-crypt luks? |
Oh, we are prompting for a password ... at your login. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 16506
|
| Posted: Fri Apr 03, 2020 1:35 am Post subject: |
|
|
Prompting for a login password is too late. The drive has already been unlocked, and the only thing protecting it is that the system is hopefully not compliant until a password is entered. However, I don't see anything in your instructions to prevent an attacker simply adding init=/bin/sh to the kernel's command line, and then bypassing the getty challenge entirely.
The security of this method appears to turn entirely on preventing an attacker from obtaining a copy of the kernel, since the kernel can and will boot to an unlocked state without user intervention. Systems built around requiring a user password to unlock a LUKS volume turn on the quality of the user's LUKS password. |
|
| Back to top |
|
|
msst
Apprentice
Joined: 07 Jun 2011
Posts: 254
|
| Posted: Fri Apr 03, 2020 6:13 am Post subject: |
|
|
| Quote: | | Systems built around requiring a user password to unlock a LUKS volume turn on the quality of the user's LUKS password. |
Correct. The initramfs prompts for the password and unlocks root, then later the root partition (encrypted) contains the master key to unlock a data partition without password. So the key is that the kernel has to prompt for the password for this new kernel option to be useful. |
|
| Back to top |
|
|
axl
Veteran
Joined: 11 Oct 2002
Posts: 1072
Location: Romania
|
| Posted: Fri Apr 03, 2020 7:13 am Post subject: |
|
|
| Hu wrote: | Prompting for a login password is too late. The drive has already been unlocked, and the only thing protecting it is that the system is hopefully not compliant until a password is entered. However, I don't see anything in your instructions to prevent an attacker simply adding init=/bin/sh to the kernel's command line, and then bypassing the getty challenge entirely.
The security of this method appears to turn entirely on preventing an attacker from obtaining a copy of the kernel, since the kernel can and will boot to an unlocked state without user intervention. Systems built around requiring a user password to unlock a LUKS volume turn on the quality of the user's LUKS password. |
If you take a look at the proposed solution, you will notice he is loading the kernel directly as an efi shell, therefor there is no place to add arguments to the kernel. Never the less, you are not wrong. The kernel can be disassembled and the key can be extracted from the command line. Not to mention it will show up in dmesg in hex for every user to look at it, therefor removing the need for a key.
What you have here is a useless layer of encryption which only serves to slow your system down, because it adds no extra security.
For a security lock to work, you need to put the key as far away from the lock as possible. Systems which are encrypted are not supposed to be convenient. If they have the key inside the thing that is booting, then the encryption is useless. That was the whole point to begin with. They are not supposed to start unsupervised. That is the point. Only the guy with the key can turn these on/off. If this machine works without the key... why did you need the lock in the first place? |
|
| Back to top |
|
|
alamahant
l33t
Joined: 23 Mar 2019
Posts: 668
|
| Posted: Fri Apr 03, 2020 9:15 am Post subject: |
|
|
What is the benefit in general of not using an initramfs?
Is it faster booting?
Thanks
 |
|
| Back to top |
|
|
tbart
Apprentice
Joined: 31 Oct 2004
Posts: 150
|
| Posted: Fri Apr 03, 2020 10:38 am Post subject: |
|
|
Well, i mostly do the same (no grub, booting from EFI directly) but with an initramfs.
But this initramfs is included in the kernel, so I don't need any unencrypted partition (except the EFI one which you need anyway) on my disk.
The whole disk is LUKS encrypted using a password, no key or plaintext password for data partitions needed. If you like, use a USB stick. Or whatever scheme LUKS supports.
The build process is streamlined using a little script that does all that's necessary (building kernel, initramfs, including it into the kernel, copying it to the efi partition, updating boot entries)
Regarding speed:
Is 12s (excluding password input) to graphical login fast enough (this is a notebook, not a high end workstation/server)?
I like the flexibility of having an initramfs to e.g. include an SSH server or other stuff, should I ever need it, and frankly, a mere 20M kernel size is OK for me! Mounting a LUKS volume in another PC or recovery environment also seems easier to me... |
|
| Back to top |
|
|
axl
Veteran
Joined: 11 Oct 2002
Posts: 1072
Location: Romania
|
| Posted: Fri Apr 03, 2020 10:47 am Post subject: |
|
|
USB stick is a good solution. As long as you don't leave it hanging around to be stolen.
pxe (tftp/dhcp) boot also works ok. I prefer this solution. The tftp server which has/holds the kernels/initramfs files/key files is a small raspberry pi I keep secured and offline and under locking key. I only connect it to the switch when I need to reboot something or update a kernel. Connect it, update, boot, disconnect.
EDIT: the reason I had to resort to this solution is because some of my systems are headless. None the less, even so, the key is not always bundled on the tftp server. I use that design for 1 of the servers, but not the others. I have to manually ssh (within the initramfs) to unlock the disk manually with password and then let the boot continue. I feel the last of the solutions is most secure, but kinda inconvenient. Not sure how I will move forward with these, but never the less I feel pxe booting allows for some flexibility. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 16506
|
| Posted: Sat Apr 04, 2020 12:54 am Post subject: |
|
|
| axl wrote: | | If you take a look at the proposed solution, you will notice he is loading the kernel directly as an efi shell, therefor there is no place to add arguments to the kernel. |
Some EFI implementations allow the operator to drop into an interactive EFI shell, and from there to execute EFI programs (including Linux kernels) with user-chosen arguments appended. If the firmware is not locked, the operator could also try to create a new boot entry that always passes init=/bin/sh, avoiding the need to use the full EFI shell. |
|
| Back to top |
|
|
axl
Veteran
Joined: 11 Oct 2002
Posts: 1072
Location: Romania
|
| Posted: Sat Apr 04, 2020 7:42 am Post subject: |
|
|
Even if firmware is locked, you could still move the drive to a system where the firmware is not locked. Or you could reset the firmware. Remove the battery. Remove the drive.
I think, most types of bios/firmware, even if locked with password, even if boot options have been limited (i.e. only boot from this disk), will try to boot other medium regardless. NOT ALL, but some. I tried. Set up boot... only boot this thing, remove that thing, and add another thing. Bios says... ohhh that thing is gone, maybe I'll try this other thing. And this is why I don't like USB devices.
What I learned in the past few years is that you can't trust manufacturers to do a proper firmware. On the other hand, if things were done properly, I would have been locked out of my systems several times over the last decade. 
Anyway, thanks for that clarification. Now I'm curious how many of my systems actually implemented a full efi shell. Thanks for giving me something to do |
|
| Back to top |
|
|
pietinger
Guru
Joined: 17 Oct 2006
Posts: 520
Location: Bavaria
|
| Posted: Sat Apr 04, 2020 10:19 am Post subject: |
|
|
| Hu wrote: | | The security of this method appears to turn entirely on preventing an attacker from obtaining a copy of the kernel,[...] |
| axl wrote: | | For a security lock to work, you need to put the key as far away from the lock as possible. |
Yes, hence I said the kernel must reside on a stick ... and only I am in the posession of it. When only I have the stick, the attacker would be myself. (and of course I use secureboot also)
However I would like to have a secure system beeing able to boot from disk (without tons of layers) instead of a stick. The minimum I need would be at first SecureBoot (I already have; I wrote a small guide in german: https://forums.gentoo.org/viewtopic-t-1109672.html). But the second thing I need I am still working/searching on:
At runtime I can create a mapping with dmsetup using a key in the kernel keyring (e.g.: "dmsetup create cr --table "0 $(blockdev --getsz /dev/sda5) crypt aes-xts-plain64 :64:user:mkey 0 /dev/sda5 0" which I can create before with: "dd if=/dev/random bs=1 count=64 status=none | keyctl padd user mkey @s"). But I need a key at boottime from EFI (or TPM). Until now I only managed to get my own (db-)certificate in the keyring ".platform". At the moment I check if there are options with IMA or/and EVM. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Documentation, Tips & Tricks
