警告: Note that securing the /boot partition and MBR can mitigate numerous attacks that occur during the boot process, but systems configured this way may still be vulnerable to BIOS/UEFI/firmware tampering, hardware keyloggers, cold boot attacks, and many other threats that are beyond the scope of this article. For an overview of system-trust issues and how these relate to full-disk encryption, refer to [1].

chkboot

警告: chkboot makes a /boot partition tamper-evident, not tamper-proof. By the time the chkboot script is run, you have already typed your password into a potentially compromised boot loader, kernel, or initrd. If your system fails the chkboot integrity test, no assumptions can be made about the security of your data.

Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012, [3]) the following script checks files under /boot for changes of SHA-1 hash, inode, and occupied blocks on the hard drive. It also checks the Master Boot Record. The script cannot prevent certain type of attacks, but a lot are made harder. No configuration of the script itself is stored in unencrypted /boot. With a locked/powered-off encrypted system, this makes it harder for some attackers because it is not apparent that an automatic checksum comparison of the partition is done upon boot. However, an attacker who anticipates these precautions can manipulate the firmware to run his own code on top of your kernel and intercept file system access, e.g. to boot, and present the untampered files. Generally, no security measures below the level of the firmware are able to guarantee trust and tamper evidence.

There is a small caveat for systemd: At the time of writing, the original chkboot.sh script provided contains an empty space at the beginning of #!/bin/bash which has to be removed for the service to start successfully.

This hook requires grub release >=2.00 to function, and a dedicated, LUKS encrypted /boot partition with its own password in order to be secure.

インストール

mkinitcpio-chkcryptobootAUR をインストールして /etc/default/chkcryptoboot.conf を編集します。If you want the ability of detecting if your boot partition was bypassed, edit the CMDLINE_NAME and CMDLINE_VALUE variables, with values known only to you. You can follow the advice of using two hashes as is suggested right after the installation. Also, be sure to make the appropriate changes to the kernel command line in /etc/default/grub. Edit the HOOKS= line in /etc/mkinitcpio.conf, and insert the chkcryptoboot hook beforeencrypt. When finished, rebuild the initramfs.

技術的な概要

mkinitcpio-chkcryptobootAUR consists of an install hook and a run-time hook for mkinitcpio. The install hook runs every time the initramfs is rebuilt, and hashes the GRUB EFI stub ($esp/EFI/grub_uefi/grubx64.efi) (in the case of UEFI systems) or the first 446 bytes of the disk on which GRUB is installed (in the case of BIOS systems), and stores that hash inside the initramfs located inside the encrypted /boot partition. When the system is booted, GRUB prompts for the /boot password, then the run-time hook performs the same hashing operation and compares the resulting hashes before prompting for the root partition password. If they do not match, the hook will print an error like this:

In addition to hashing the boot loader, the hook also checks the parameters of the running kernel against those configured in /etc/default/chkcryptoboot.conf. This is checked both at run-time and after the boot process is done. This allows the hook to detect if GRUB's configuration was not bypassed at run-time and afterwards to detect if the entire /boot partition was not bypassed.

For BIOS systems the hook creates a hash of GRUB's first stage bootloader (installed to the first 446 bytes of the bootdevice) to compare at the later boot processes. The main second-stage GRUB bootloader core.img is not checked.

他の方法

While one of these methods should serve the purpose for most users, they do not address all security problems associated with the unencrypted /boot. One approach which endeavours to provide a fully authenticated boot chain was published with POTTS as an academic thesis to implement the STARK authentication framework.

The POTTS proof-of-concept uses Arch Linux as a base distribution and implements a system boot chain with

POTTS - a boot menu for a one-time authentication message prompt

TrustedGrub - a GRUB Legacy implementation which authenticates the kernel and initramfs against TPM chip registers

TRESOR - a kernel patch which implements AES but keeps the master-key not in RAM but in CPU registers during runtime.

As part of the thesis installation instructions based on Arch Linux (ISO as of 2013-01) have been published. If you want to try it, be aware these tools are not in standard repositories and the solution will be time consuming to maintain.

You can follow the above instructions with only two primary partitions, one boot partition (required because of encryption) and one primary LVM partition. Within the LVM partition you can have as many partitions as you need, but most importantly it should contain at least root, swap, and home logical volume partitions. This has the added benefit of having only one keyfile for all your partitions, and having the ability to hibernate your computer (suspend to disk) where the swap partition is encrypted. If you decide to do so your hooks in /etc/mkinitcpio.conf should look like this:

Finally, restart the remote system and try to ssh to it, explicitly stating the "root" username (even if the root account is disabled on the machine, this root user is used only in the initrd for the purpose of unlocking the remote system). If you are using the mkinitcpio-dropbearAUR package and you also have the openssh package installed, then you most probably will not get any warnings before logging in, because it convert and use the same host keys openssh uses. (Except Ed25519 keys, dropbear does not support them). In case you are using mkinitcpio-tinysshAUR, you have the option of installing tinyssh-convertAUR or tinyssh-convert-gitAUR so you can use the same keys as your openssh installation (currently only Ed25519 keys). In either case, you should have run the ssh daemon at least once, using the provided systemd units, so the keys can be generated first. After rebooting the machine, you should be prompted for the passphrase to unlock the root device. Afterwards, the system will complete its boot process and you can ssh to it as you normally would (with the remote user of your choice).

ヒント: If you would simply like a nice solution to mount other encrypted partitions (such as /home) remotely, you may want to look at this forum thread.

wifi でリモートのロック解除 (フック: 自分で作成)

The net hook is normally used with an ethernet connection. In case you want to setup a computer with wireless only, and unlock it via wifi, you can create a custom hook to connect to a wifi network before the net hook is run.

Below example shows a setup using a usb wifi adapter, connecting to a wifi network protected with WPA2-PSK. In case you use for example WEP or another boot loader, you might need to change some things.

Modify /etc/mkinitcpio.conf:

Add the needed kernel module for your specific wifi adatper.

Include the wpa_passphrase and wpa_supplicant binaries.

Add a hook wifi (or a name of your choice, this is the custom hook that will be created) before the net hook.

By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password. See cryptsetup FAQ, section 5.19 What about SSDs, Flash and Hybrid Drives? and Full disk encryption on an ssd.

TRIM can be left disabled if the security issues stated at the top of this section are considered a worse threat than the above bullet.

In linux 3.1 and up, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in cryptsetup version 1.4.0 and up. To add support during boot, you will need to add :allow-discards to the cryptdevice option. The TRIM option may look like this:

cryptdevice=/dev/sdaX:root:allow-discards

For the main cryptdevice configuration options before the :allow-discards see Dm-crypt/システム設定.

If you are using a systemd based initrd, you must pass:

rd.luks.options=discard

Besides the kernel option, it is also required to periodically run fstrim or mount the filesystem (e.g. /dev/mapper/root in this example) with the discard option in /etc/fstab. For details, please refer to the TRIM page.

For LUKS devices unlocked manually on the console or via /etc/crypttab either discard or allow-discards may be used.

encrypt フックと複数のディスク

The encrypt hook only allows for a singlecryptdevice= entry (FS#23182). In system setups with multiple drives this may be limiting, because dm-crypt has no feature to exceed the physical device. For example, take "LVM on LUKS": The entire LVM exists inside a LUKS mapper. This is perfectly fine for a single-drive system, since there is only one device to decrypt. But what happens when you want to increase the size of the LVM? You cannot, at least not without modifying the encrypt hook.

The following sections briefly show alternatives to overcome the limitation. The first deals with how to expand a LUKS on LVM setup to a new disk. The second with modifying the encrypt hook to unlock multiple disks in LUKS setups without LVM. The third section then again uses LVM, but modifies the encrypt hook to unlock the encrypted LVM with a remote LUKS header.

LVM を複数のディスクに拡張

The management of multiple disks is a basic LVM feature and a major reason for its partitioning flexibility. It can also be used with dm-crypt, but only if LVM is employed as the first mapper. In such a LUKS on LVM setup the encrypted devices are created inside the logical volumes (with a separate passphrase/key per volume). The following covers the steps to expand that setup to another disk.

警告: Backup! While resizing filesystems may be standard, keep in mind that operations may go wrong and the following might not apply to a particular setup. Generally, extending a filesystem to free disk space is less problematic than shrinking one. This in particular applies when stacked mappers are used, as it is the case in the following example.

新しいドライブの追加

First, it may be desired to prepare a new disk according to Dm-crypt/ドライブの準備.
Second, it is partitioned as a LVM, e.g. all space is allocated to /dev/sdY1 with partition type "8E00" (Linux LVM).
Third, the new disk/partition is attached to the existing LVM volume group, e.g.:

# pvcreate /dev/sdY1
# vgextend MyStorage /dev/sdY1

論理ボリュームの拡張

For the next step, the final allocation of the new diskspace, the logical volume to be extended has to be unmounted. It can be performed for the cryptdevice root partition, but in this case the procedure has to be performed from an Arch Install ISO.

In this example, it is assumed that the logical volume for /home (lv-name homevol) is going to be expanded with the fresh disk space:

複数の root 以外のパーティション

Maybe you have a requirement for using the encrypt hook on a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in /lib/initcpio/hooks/encrypt (the first one to your /dev/sd* partition, the second to the name you want to attribute). That should be enough.

The big advantage is you can have everything automated, while setting up /etc/crypttab with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of /etc/fstab (at least).

Of course, if the cryptsetup package gets upgraded, you will have to change this script again. Unlike /etc/crypttab, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.

If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the /dev/mdX device in /lib/initcpio/hooks/encrypt is not enough; the encrypt hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the encrypt hook is run. You can solve this by putting the RAID array in /boot/grub/menu.lst, like

kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5

If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). GRUB can handle multiple array definitions just fine:

ノート: No cryptsetup parameters need to be passed to the kernel command line, since/etc/crypttab.initramfs will be added as /etc/crypttab in the initramfs. If you wish to specify them in the kernel command line see systemd-cryptsetup-generator(8) for the supported options.

encrypt フックを修正する

This method shows how to modify the encrypt hook in order to use a remote LUKS header. Now the encrypt hook has to be modified to let cryptsetup use the separate header (FS#42851; base source and idea for these changes published on the BBS). Make a copy so it is not overwritten on a mkinitcpio update:

This is required so the LUKS header is available on boot allowing the decryption of the system, exempting us from a more complicated setup to mount another separate USB device in order to access the header. After this set up the initramfs is created.

ヒント: You will notice that since the system partition only has "random" data, it does not have a partition table and by that an UUID or a name. But you can still have a consistent mapping using the disk id under /dev/disk/by-id/