Dm-crypt/特記事項

Dm-crypt に戻る。

暗号化されていない boot パーティションのセキュア化

警告: systemd バージョン 230 から cryptsetup のジェネレータは crypto キーファイルの RequiresMountsFor を省きます。そのため、ファイルが含まれているファイルシステムをアンマウントすると、cryptsetup サービスも停止します。ファイルシステムと cryptokey が必要になるのは crypto コンテナを初期設定するときだけなので、この挙動は間違っています。詳しくは [1] を参照。

たとえ root を暗号化したとしても、/boot パーティションと Master Boot Record はディスクの中で暗号化されてない状態で残ります。この2つを暗号化するのは基本的に不可能です。ブートローダーと BIOS が dm-crypt コンテナの暗号化を解除してブートプロセスを続行することが出来なくなってしまいます。例外は GRUB で、LUKS で暗号化した /boot を復号する機能が存在します。GRUB を見て下さい。

警告: 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 [2].

リムーバルデバイスから起動

別のデバイスを使ってシステムを起動するのはとても簡単で、特定の攻撃に対してセキュリティを高めることができます。ルートファイルシステムを暗号化したシステムで脆弱ポイントとなりえるのは以下の2つです:

• Master Boot Record
• /boot パーティション

システムを起動するには上記をどちらも暗号化されていない状態で保存しなければなりません。改竄から保護する方法として、USB ドライブなどのリムーバルメディアに保存して、ハードディスクの代わりとしてドライブから起動することができます。ドライブを肌身離さず持ち歩いていれば、改竄を加えられる恐れがなくなり、システムを解錠する認証機構をさらにセキュアにすることができます。

既にシステム設定を終えていて専用のパーティションを /boot にマウントしていることが前提です。まだ設定していない場合、dm-crypt/システム設定#ブートローダーの手順に従ってください。リムーバルメディアはハードディスクで置き換えて下さい。

ノート: You must make sure your system supports booting from the chosen medium, be it a USB drive, an external hard drive, an SD card, or anything else.

リムーバルドライブ (/dev/sdx) を準備:

# gdisk /dev/sdx #format if necessary. Alternatively, cgdisk, fdisk, cfdisk, gparted...
# mkfs.ext2 /dev/sdx1
# mount /dev/sdx1 /mnt

既存の /boot の中身をコピー:

# cp -R -i -d /boot/* /mnt

新しいパーティションをマウントして fstab ファイルを更新:

# umount /boot
# umount /mnt
# mount /dev/sdx1 /boot
# genfstab -p -U / > /etc/fstab

その後 GRUB を更新してください。grub-mkconfig は自動的に新しいパーティションの UUID を認識するはずですが、カスタムメニューエントリは手動で更新する必要があるかもしれません。

# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install /dev/sdx #install to the removable device, not the hard disk.

再起動して新しい設定をテストしてください。忘れずに BIOS や UEFI でデバイスのブート順序を設定してください。システムが起動しない場合、ハードドライブから起動することで問題を修正することができます。

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.

インストールスクリプトが 存在します (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)。また、chkboot^AUR パッケージでインストールすることもできます。

インストールしたらサービスファイル (パッケージに含まれています) を追加して有効化してください:

[Unit]
Description=Check that boot is what we want
Requires=basic.target
After=basic.target

[Service]
Type=oneshot
ExecStart=/usr/local/bin/chkboot.sh

[Install]
WantedBy=multi-user.target

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.

/usr/local/bin/chkboot_user.sh はログイン後すぐに実行する必要があるため、自動起動するように設定してください (例: KDE の場合 -> System Settings -> Startup and Shutdown -> Autostart; GNOME 3: gnome-session-properties)。

With Arch Linux, changes to /boot are pretty frequent, for example by new kernels rolling-in. Therefore it may be helpful to use the scripts with every full system update. One way to do so:

#!/bin/bash
#
# Note: Insert your <user>  and execute it with sudo for pacman & chkboot to work automagically
#
echo "Pacman update [1] Quickcheck before updating" & 
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
/usr/local/bin/chkboot.sh
sync							# sync disks with any results 
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user> 
echo "Pacman update [2] Syncing repos for pacman" 
pacman -Syu
/usr/local/bin/chkboot.sh
sync	
sudo -u <user> /usr/local/bin/chkboot_user.sh		# insert your logged on <user>
echo "Pacman update [3] All done, let us roll on ..."

mkinitcpio-chkcryptoboot

警告: このフックは GRUB のコアコード (MBR) や EFI スタブは暗号化しません。攻撃者がブートローダーの設定を変更してカーネルや initramfs を実行時に改竄できる状態からは保護されません。

mkinitcpio-chkcryptoboot^AUR は初期ユーザー空間で整合性チェックを行ってシステムのセキュリティが破られている場合に root パーティションのパスワードを入力しないようにユーザーに忠告する mkinitcpio フックです。ブートパーティションを暗号化することでセキュリティを確保し、GRUB の cryptodisk.mod モジュールでロックを解除します。root ファイルシステムのパーティションは別のパスワードを使って暗号化します。これなら、オフラインの改竄からも initramfs やカーネルを守ることができ、たとえマシンに侵入されて /boot パーティションのパスワードが入力されても root パーティションは安全です (chkcryptoboot フックが改竄を検出して、フック自体が改竄されていない場合)。

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-chkcryptoboot^AUR をインストールして /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 before encrypt. When finished, rebuild the initramfs.

技術的な概要

mkinitcpio-chkcryptoboot^AUR 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:

CHKCRYPTOBOOT ALERT!
CHANGES HAVE BEEN DETECTED IN YOUR BOOT LOADER EFISTUB!
YOU ARE STRONGLY ADVISED NOT TO ENTER YOUR ROOT CONTAINER PASSWORD!
Please type uppercase yes to continue:

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.

他の方法

上記のスクリプトの代わりに、AIDE によるハッシュチェックを設定することもできます。柔軟な設定ファイルでカスタマイズが可能です。

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.

GPG や OpenSSL で暗号化されたキーファイルを使う

The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article System Encryption using LUKS with GPG encrypted keys:

• GnuPG: Post regarding GPG encrypted keys This post has the generic instructions.
• OpenSSL: Post regarding OpenSSL encrypted keys This post only has the ssldec hooks.
• OpenSSL: Post regarding OpenSSL salted bf-cbc encrypted keys This post has the bfkf initcpio hooks, install, and encrypted keyfile generator scripts.
• LUKS: Post regarding LUKS encrypted keys with a lukskey initcpio hook.

Note that:

• 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:

  HOOKS=" ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... "

  そしてカーネルパラメータに以下を追加してください:

  resume=/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>

• If you need to temporarily store the unencrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as /dev/shm.
• GPG で暗号化されたキーファイルを使いたい場合、静的にコンパイルされた GnuPG バージョン 1.4 を使う必要があります。もしくはフックを編集して AUR の gnupg1^AUR パッケージを使ってください。
• It is possible that an update to OpenSSL could break the custom ssldec mentioned in the second forum post.

root などのパーティションのリモート解除

LUKS によって完全に暗号化されたシステムをリモートで再起動したい場合、もしくは Wake-on-LAN サービスを使ってシステムを起動したい場合、起動時にルートパーティション/ボリュームのパスフレーズを入力する手段が必要になります。ネットワークインターフェイスを設定する mkinitcpio のフックを実行することでこれを実現可能です。以下のパッケージには様々な mkinitcpio ビルドフックが含まれており設定を楽にしてくれます。

ノート:

• ネットワークインターフェイスはカーネルによるデバイス名を使用してください (例: eth0)。udev によるデバイス名 (例: enp1s0) を使用してはいけません。
• 使用しているネットワークカードのモジュールを MODULES 行に追加する必要が場合があります。

リモートのロック解除 (フック: systemd, systemd-tool)

AUR パッケージの mkinitcpio-systemd-tool^AUR には systemd-tool という名前の systemd 中心の mkinitcpio フックが含まれており、initramfs の systemd で以下の機能を使うことができるようになります:

フックによって実現されるコア機能: systemd + mkinitcpio の統合設定 バイナリと設定リソースの自動プロビジョニング オンデマンドの mkinitcpio スクリプトとインライン関数の実行

同梱されているサービスユニットによって実現される機能: initrd のデバッグ 初期ユーザー空間でのネットワークの設定 インタラクティブなユーザーシェル initrd におけるリモート ssh アクセス cryptsetup + カスタムパスワードエージェント

mkinitcpio-systemd-tool^AUR パッケージは systemd フックを必要とします。詳しい情報はプロジェクトの README やデフォルトの systemd サービスユニットファイル を見てください。

推奨されるフックは次の通りです: base autodetect modconf block filesystems keyboard fsck systemd systemd-tool。

リモートのロック解除 (フック: netconf, dropbear, tinyssh, ppp)

initcpio のリモートログインを実現するパッケージの別の組み合わせとして mkinitcpio-netconf^AUR あるいは mkinitcpio-ppp^AUR (インターネット経由で PPP 接続を使ってリモートでロックを解除) と SSH サーバーを使用する方法があります。SSH サーバーは mkinitcpio-dropbear^AUR または mkinitcpio-tinyssh^AUR のどちらを使用するか選択できます。これらのフックはシェルをインストールしないため、mkinitcpio-utils^AUR パッケージもインストールする必要があります。以下の手順は上記のパッケージと組み合わせて使うことができます。パスが異なる場合、注意してください。

1. SSH のキーペアが存在しない場合、クライアント環境でペアを生成してください (リモート環境のロックを解除するのに使用します)。mkinitcpio-tinyssh^AUR を使用する場合、Ed25519 鍵を使用することができます。
2. SSH 公開鍵 (パスワードを使わなくても ssh で接続できるように使用している公開鍵、または、今さっき作成した拡張子が .pub のファイル) をリモートマシンの /etc/dropbear/root_key または /etc/tinyssh/root_key ファイルにコピーしてください。
   ヒント: 必要であれば他の SSH 公開鍵を後で追加することもできます。リモートの ~/.ssh/authorized_keys の中身をコピーする場合、リモートマシンのロックを解除するのに使用する鍵だけが含まれていることを確認してください。鍵を追加したら、mkinitcpio で initrd も再生成する必要があります。Secure Shell#SSH の保護も参照してください。
3. /etc/mkinitcpio.conf の "HOOKS" 行の filesystems の前に <netconf and/or ppp> <dropbear or tinyssh> encryptssh フックを追加してください (encryptssh で encrypt フックを置き換えます)。それから initramfs イメージを再生成してください。
   ノート: mkinitcpio-nfs-utils に含まれている net フックは必要ありません。
4. ブートローダーの設定に cryptdevice= パラメータを設定して適切な引数を付けた ip= カーネルコマンドパラメータを追加してください。例えば、DHCP サーバーからリモート環境に固定 IP が割り当てられない場合、再起動してから SSH でアクセスするのが難しいため、以下のように使用したい IP を明示的に指定できます:

   ip=192.168.1.1:::::eth0:none

   ノート: mkinitcpio-netconf^AUR のバージョン 0.0.4 現在、複数の ip= パラメータをネストすることで複数のインターフェイスを設定できます。ip=dhcp (ip=:::::eth0:dhcp) と混ぜることはできません。インターフェイスを指定する必要があります。

   ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none

   詳しい説明は mkinitcpio のセクションを読んでください。設定が完了したら、ブートローダーの設定を更新してください。
5. 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-dropbear^AUR 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-tinyssh^AUR, you have the option of installing tinyssh-convert^AUR or tinyssh-convert-git^AUR 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.

1. 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.

     MODULES="module"
     BINARIES="wpa_passphrase wpa_supplicant"
     HOOKS="base udev autodetect ... wifi net ... dropbear encryptssh ..."

2. Create the wifi hook in /lib/initcpio/hooks/wifi:

   run_hook ()
   {
   	# sleep a couple of seconds so wlan0 is setup by kernel
   	sleep 5
   
   	# set wlan0 to up
   	ip link set wlan0 up
   
   	# assocciate with wifi network
   	# 1. save temp config file
   	wpa_passphrase "network ESSID" "pass phrase" > /tmp/wifi
   
   	# 2. assocciate
   	wpa_supplicant -B -D nl80211,wext -i wlan0 -c /tmp/wifi
   
   	# sleep a couple of seconds so that wpa_supplicant finishes connecting
   	sleep 5
   
   	# wlan0 should now be connected and ready to be assigned an ip by the net hook
   }
   
   run_cleanuphook ()
   {
   	# kill wpa_supplicant running in the background
   	killall wpa_supplicant
   
   	# set wlan0 link down
   	ip link set wlan0 down
   
   	# wlan0 should now be fully disconnected from the wifi network
   }

3. Create the hook installation file in /lib/initcpio/install/wifi:

   build ()
   {
   	add_runscript
   }
   help ()
   {
   cat<<HELPEOF
   	Enables wifi on boot, for dropbear ssh unlocking of disk.
   HELPEOF
   }

4. ip=:::::wlan0:dhcp をカーネルパラメータに追加。衝突しないように ip=:::::eth0:dhcp は削除してください。
5. Optionally create an additional boot entry with kernel parameter ip=:::::eth0:dhcp.
6. initramfs イメージを再生成。
7. ブートローダーの設定を更新。例えば GRUB の場合:

   # grub-mkconfig -o /boot/grub/grub.cfg

Remember to setup wifi, so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.

ソリッドステートドライブ (SSD) の Discard/TRIM のサポート

ソリッドステートドライブを使用している場合、device-mapper はデフォルトでは TRIM コマンドを有効にしないので注意してください。デフォルト設定を上書きしないかぎりブロックデバイスは discard オプションが無効な状態でマウントされます。

セキュリティ上の問題があるため dm-crypt デバイスで TRIM のサポートがデフォルトで有効になることは永遠にないと device-mapper のメンテナは説明しています [4][5]。TRIM を有効にすると開放されたブロック情報という形でデータが漏洩する可能性が僅かにあり、そこから使用しているファイルシステムが判別される恐れがあります。TRIM を有効にすることによる問題の議論と説明は cryptsetup の開発者による ブログ記事 で読むことができます。デバイスが昔 (cryptsetup <1.6.0) のデフォルト暗号である --cipher aes-cbc-essiv で暗号化されている場合、最新のデフォルト設定を使用している場合よりも TRIM されたセクタから多くの情報が漏洩する危険があります。

The following cases can be distinguished:

• デバイスをデフォルトの dm-crypt LUKS モードで暗号化している場合:
  • 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.

ディスクの完全消去#フラッシュメモリも参照してください。

• デバイスを dm-crypt の plain モードで暗号化している、または LUKS ヘッダーを別個に保存している場合:
  • If plausible deniability is required, TRIM should never be used because of the considerations at the top of this section, or the use of encryption will be given away.
  • If plausible deniability is not required, TRIM can be used for its performance gains, provided that the security dangers described at the top of this section are not of concern.

警告: ドライブの TRIM を有効にする前に、デバイスが TRIM コマンドを完全にサポートしていることを確認してください。TRIM がサポートされていない場合、データが消失する危険があります。ソリッドステートドライブ#TRIM を見てください。

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 single cryptdevice= 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:

# umount /home
# fsck /dev/mapper/home
# cryptsetup luksClose /dev/mapper/home
# lvextend -l +100%FREE MyStorage/homevol

Now the logical volume is extended and the LUKS container comes next:

# cryptsetup open --type luks /dev/mapper/MyStorage-homevol home
# umount /home      # as a safety, in case it was automatically remounted
# cryptsetup --verbose resize home

Finally, the filesystem itself is resized:

# e2fsck -f /dev/mapper/home
# resize2fs /dev/mapper/home

Done! If it went to plan, /home can be remounted

# mount /dev/mapper/home /home

and now includes the span to the new disk. Note that the cryptsetup resize action does not affect encryption keys, they have not changed.

複数のパーティションの encrypt フックを修正

複数のパーティションにまたがる root ファイルシステム

起動時に複数のハードドライブからルートファイルシステム (/) を復号化するように encrypt フックを修正することが可能です:

# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2
# cp /usr/lib/initcpio/hooks/encrypt  /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptdevice/cryptdevice2/" /etc/initcpio/hooks/encrypt2
# sed -i "s/cryptkey/cryptkey2/" /etc/initcpio/hooks/encrypt2

ブートオプションに cryptdevice2= を (必要であれば cryptkey2= も) 追加して、mkinitcpio.conf に encrypt2 フックを追加してからリビルドしてください。Dm-crypt/システム設定も参照。

複数の 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:

kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5

リモート LUKS ヘッダーを使ってシステムを暗号化

以下の例では Dm-crypt/システム全体の暗号化#Plain dm-crypt と同じセットアップを使います。先に進む前に読んでおいてください。

リモートのヘッダーを使うことにより、暗号化されたブロックデバイスには暗号化データだけが保持され、攻撃者にヘッダーの存在が露見しないかぎり否認可能性を得ることができます。plain dm-crypt を使用する場合と似ていますが、LUKS の利点としてマスター鍵と鍵導出関数によって複数のパスフレーズが使えるなどのメリットがあります。さらに、リモートヘッダーは GPG や OpenSSL で暗号化したキーファイルを使う方法よりも簡単に二要素認証を実現できます。内蔵のパスワードプロンプトで複数回の入力が可能です。詳しくはディスク暗号化#暗号メタデータを見てください。

dm-crypt/デバイスの暗号化#LUKS モードの暗号化オプションを見て暗号化オプションを確認してから、暗号化したシステムパーティションを設定し cryptsetup で使用するヘッダーファイルを作成してください:

# truncate -s 2M header.img
# cryptsetup luksFormat /dev/sdX --header header.img

コンテナを開くには:

# cryptsetup open --header header.img --type luks /dev/sdX enc

後は LVM on LUKS セットアップに従ってください。同じようにリムーバルデバイスに boot パーティションを準備します (同じでなければ、暗号化ディスクを解錠するためのヘッダーファイルを別にする意味がありません)。そして header.img を移動します:

# mv header.img /mnt/boot

Follow the installation procedure up to the mkinitcpio step (you should now be arch-chrooted inside the encrypted system).

There are two options for initramfs to support a detached LUKS header.

systemd フックを使う

First create /etc/crypttab.initramfs and add the encrypted device to it. The syntax is defined in crypttab(5):

/etc/crypttab.initramfs

MyStorage    PARTUUID=00000000-0000-0000-0000-000000000000    none    header=/boot/header.img

systemd を使用するように /etc/mkinitcpio.conf を編集して FILES にヘッダーを追加してください:

/etc/mkinitcpio.conf

FILES="/boot/header.img"

HOOKS="... systemd ... block sd-encrypt sd-lvm2 filesystems ..."

initramfs を再作成したら設定は完了です。

ノート: 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:

# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2

/etc/initcpio/hooks/encrypt2 (around line 52)

warn_deprecated() {
    echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"
    echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."
}

local headerFlag=false
for cryptopt in ${cryptoptions//,/ }; do
    case ${cryptopt} in
        allow-discards)
            cryptargs="${cryptargs} --allow-discards"
            ;;  
        header)
            cryptargs="${cryptargs} --header /boot/header.img"
            headerFlag=true
            ;;
        *)  
            echo "Encryption option '${cryptopt}' not known, ignoring." >&2 
            ;;  
    esac
done

if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then
    if $headerFlag || cryptsetup isLuks ${resolved} >/dev/null 2>&1; then
        [ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated
        dopassphrase=1

Now edit the mkinitcpio.conf to add the encrypt2 and lvm2 hooks, the header.img to FILES and the loop to MODULES, apart from other configuration the system requires:

/etc/mkinitcpio.conf

MODULES="loop"

FILES="/boot/header.img"

HOOKS="... encrypt2 lvm2 ... filesystems ..."

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.

次にブートローダーを設定して cryptdevice= で新しい header オプションも設定します:

cryptdevice=/dev/sdX:enc:header

To finish, following Dm-crypt/システム全体の暗号化#インストール後 is particularly useful with a /boot partition on an USB storage medium.

ヒント: 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/