「Dm-crypt/特記事項」の版間の差分
Kusakata.bot2 (トーク | 投稿記録) (Pkg/AUR テンプレートの更新) |
Kusanaginoturugi (トーク | 投稿記録) (カテゴリを修正) |
||
1行目: | 1行目: | ||
{{Lowercase title}} |
{{Lowercase title}} |
||
− | [[Category: |
+ | [[Category:ディスク暗号化]] |
− | [[Category:ファイルシステム]] |
||
[[en:Dm-crypt/Specialties]] |
[[en:Dm-crypt/Specialties]] |
||
2023年5月25日 (木) 13:39時点における版
目次
暗号化されていない boot パーティションのセキュア化
たとえ root を暗号化したとしても、/boot
パーティションと Master Boot Record は暗号化できません。この2つを暗号化するのは基本的に不可能です。ブートローダーや BIOS が dm-crypt コンテナの暗号化を解除することではできないため、ブートプロセスが続行できません。ただし GRUB には LUKS で暗号化した /boot
を復号化する機能が存在します。GRUB を見てください。
リムーバブルデバイスから起動
別のデバイスを使ってシステムを起動するのはとても簡単で、特定の攻撃に対してセキュリティを高めることができます。ルートファイルシステムを暗号化したシステムで脆弱ポイントとなりえるのは以下の2つです:
- Master Boot Record
/boot
パーティション
システムを起動するには上記をどちらも暗号化されていない状態で保存しなければなりません。改竄から保護する方法として、USB ドライブなどのリムーバブルメディアに保存して、ハードディスクの代わりとしてドライブから起動することができます。ドライブを肌身離さず持ち歩いていれば、改竄を加えられる恐れがなくなり、システムを解錠する認証機構をさらにセキュアにすることができます。
既にシステム設定を終えていて専用のパーティションを /boot
にマウントしていることが前提です。まだ設定していない場合、ハードディスクをリムーバブルメディアに置き換えて dm-crypt/システム設定#ブートローダーの手順に従ってください。
リムーバブルドライブ (/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
ct-magazine (Issue 3/12, page 146, 01.16.2012, [3]) の記事に記載されていた chkboot スクリプトは /boot
のファイルに対して SHA-1 ハッシュや inode、ハードドライブの占有ブロックが変化していないかチェックします。Master Boot Record もチェックされます。ある種の攻撃を防ぐことはできませんが、防御力を高めることができます。スクリプトの設定は暗号化されていない /boot
に保存されません。暗号化システムのロックがかかっている(休眠)状態であれば、見かけ上は起動時にパーティションの自動チェックサム比較が行われることはわからないため、攻撃するのが難しくなります。ただし、攻撃者にあらかじめ予期されていた場合、ファームウェアを操作してカーネルの上でコードを動かして、ファイルシステム (例: boot
) のアクセスを横取りされてしまう可能性はあります。一般的に、ファームウェアよりも下の階層では改竄されていないという保証は得られません。
インストールスクリプトが 存在します (作者: Juergen Schmidt, ju at heisec.de; ライセンス: GPLv2)。また、chkbootAUR パッケージでインストールすることもできます。
インストールしたらサービスファイル (パッケージに含まれています) を追加して有効化してください:
[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
systemd の場合は注意が必要です。執筆時点ではオリジナルの chkboot.sh
スクリプトには #!/bin/bash
の最初に空白が含まれておりサービスを起動するには空白を削除する必要があります。
/usr/local/bin/chkboot_user.sh
はログイン後すぐに実行する必要があるため、自動起動するように設定してください (例: KDE の場合 -> System Settings -> Startup and Shutdown -> Autostart; GNOME 3: gnome-session-properties)。
Arch Linux では新しいカーネルのアップデートなどによって /boot
に頻繁に変更が加えられます。システムアップグレードをするたびにスクリプトを使用すると良いでしょう:
#!/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
mkinitcpio-chkcryptobootAUR は初期ユーザー空間で整合性チェックを行ってシステムのセキュリティが破られている場合に 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-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 before encrypt
. 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:
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 の gnupg1AUR パッケージを使ってください。
- 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 ビルドフックが含まれており設定を楽にしてくれます。
リモートのロック解除 (フック: systemd, systemd-tool)
AUR パッケージの mkinitcpio-systemd-tool には systemd-tool という名前の systemd 中心の mkinitcpio フックが含まれており、initramfs の systemd で以下の機能を使うことができるようになります:
フックによって実現されるコア機能:
|
同梱されているサービスユニットによって実現される機能:
|
mkinitcpio-systemd-tool パッケージは systemd フックを必要とします。詳しい情報はプロジェクトの README やデフォルトの systemd サービスユニットファイル を見てください。
推奨されるフックは次の通りです: base autodetect modconf block filesystems keyboard fsck systemd systemd-tool
。
リモートのロック解除 (フック: netconf, dropbear, tinyssh, ppp)
initcpio のリモートログインを実現するパッケージの別の組み合わせとして mkinitcpio-netconf あるいは mkinitcpio-pppAUR (インターネット経由で PPP 接続を使ってリモートでロックを解除) と SSH サーバーを使用する方法があります。SSH サーバーは mkinitcpio-dropbear または mkinitcpio-tinyssh のどちらを使用するか選択できます。これらのフックはシェルをインストールしないため、mkinitcpio-utils パッケージもインストールする必要があります。以下の手順は上記のパッケージと組み合わせて使うことができます。パスが異なる場合、注意してください。
- SSH のキーペアが存在しない場合、クライアント環境でペアを生成してください (リモート環境のロックを解除するのに使用します)。mkinitcpio-tinyssh を使用する場合、Ed25519 鍵を使用することができます。
- SSH 公開鍵 (パスワードを使わなくても ssh で接続できるように使用している公開鍵、または、今さっき作成した拡張子が .pub のファイル) をリモートマシンの
/etc/dropbear/root_key
または/etc/tinyssh/root_key
ファイルにコピーしてください。 /etc/mkinitcpio.conf
の "HOOKS" 行のfilesystems
の前に<netconf and/or ppp> <dropbear or tinyssh> encryptssh
フックを追加してください (encryptssh
でencrypt
フックを置き換えます)。それから initramfs イメージを再生成してください。- ブートローダーの設定に
cryptdevice=
パラメータを設定して適切な引数を付けたip=
カーネルコマンドパラメータを追加してください。例えば、DHCP サーバーからリモート環境に固定 IP が割り当てられない場合、再起動してから SSH でアクセスするのが難しいため、以下のように使用したい IP を明示的に指定できます:ip=192.168.1.1:::::eth0:none
ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none
詳しい説明は mkinitcpio のセクションを読んでください。設定が完了したら、ブートローダーの設定を更新してください。 - 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 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, you have the option of installing tinyssh-convert 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).
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
andwpa_supplicant
binaries. - Add a hook
wifi
(or a name of your choice, this is the custom hook that will be created) before thenet
hook.MODULES="module"
BINARIES="wpa_passphrase wpa_supplicant"
HOOKS="base udev autodetect ... wifi net ... dropbear encryptssh ..."
- Create the
wifi
hook in/etc/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
} - Create the hook installation file in
/etc/initcpio/install/wifi
:build ()
{
add_runscript
}
help ()
{
cat<<HELPEOF
Enables wifi on boot, for dropbear ssh unlocking of disk.
HELPEOF
} ip=:::::wlan0:dhcp
をカーネルパラメータに追加。衝突しないようにip=:::::eth0:dhcp
は削除してください。- Optionally create an additional boot entry with kernel parameter
ip=:::::eth0:dhcp
. - initramfs イメージを再生成。
- ブートローダーの設定を更新。例えば 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 されたセクタから多くの情報が漏洩する危険があります。
以下のケースに分かれます:
- デバイスをデフォルトの 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 ヘッダーを別個に保存している場合:
- 妥当な否認権が必要な場合、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
メインの cryptdevice
設定オプションは :allow-discards
よりも先に来ます。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.
新しいドライブの追加
まず、Dm-crypt/ドライブの準備に従って新しいディスクを準備すると良いでしょう。そして LVM としてパーティショニングします (例: 全ての領域を /dev/sdY1
に割り当ててパーティションタイプを "8E00" (Linux LVM) に設定)。その後、新しいディスク・パーティションを既存の LVM ボリュームグループに追加します:
# 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
最後に、ファイルシステムのサイズを変更:
# 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-chroot
ed inside the encrypted system).
There are two options for initramfs to support a detached LUKS header.
systemd フックを使う
まず /etc/crypttab.initramfs
を作成して暗号化デバイスを追加してください。構文は 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 を再作成したら設定は完了です。
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.