「Dm-crypt/システム全体の暗号化」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
(未訳部分の翻訳)
54行目: 54行目:
 
* LUKS ヘッダに損害が発生した場合の耐障害性があります
 
* LUKS ヘッダに損害が発生した場合の耐障害性があります
 
* [[Wikipedia:Deniable encryption|否認可能暗号]]が使える
 
* [[Wikipedia:Deniable encryption|否認可能暗号]]が使える
  +
* SSD の[[Dm-crypt/特記事項#ソリッドステートドライブ (SSD) の Discard/TRIM のサポート|問題]]を解決できます
 
|
 
|
 
* 全ての暗号化パラメータに注意する必要があります
 
* 全ての暗号化パラメータに注意する必要があります
  +
* 暗号鍵はひとつだけで変更する方法はありません
* Single encryption key and no option to change it
 
 
|----------------------------------------------------------
 
|----------------------------------------------------------
 
| [[#boot パーティションの暗号化 (GRUB)]]
 
| [[#boot パーティションの暗号化 (GRUB)]]
 
GRUB ブートローダーを使って boot パーティションを暗号化する方法を説明します。<br>このシナリオでは ESP パーティションを使いますが、他のシナリオでも ESP を使うことができます。
 
GRUB ブートローダーを使って boot パーティションを暗号化する方法を説明します。<br>このシナリオでは ESP パーティションを使いますが、他のシナリオでも ESP を使うことができます。
 
|
 
|
  +
* ベースにするシナリオと同じメリット (このページの例では LVM on LUKS)
* Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)
 
  +
* ブートローダーや ESP パーティションまで暗号化されます
* Less data is left unencrypted, i.e. the boot loader and the ESP partition, if present
 
 
|
 
|
  +
* ベースにするシナリオと同じデメリット (このページの例では LVM on LUKS)
* Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)
 
 
* 設定が複雑です
 
* 設定が複雑です
 
* 他のブートローダーのサポートがありません
 
* 他のブートローダーのサポートがありません
  +
|----------------------------------------------------------
  +
| [[#Btrfs サブボリュームとスワップ]]
  +
UEFI 環境で [[Btrfs]] のシステムパーティションと {{ic|/boot}} ディレクトリを暗号化して、スワップパーティションを追加する方法。
  +
|
  +
* [[#boot パーティションの暗号化 (GRUB)]] と同じメリット
  +
* Btrfs の機能を活用できます
  +
|
  +
* [[#boot パーティションの暗号化 (GRUB)]] と同じデメリット
 
|}
 
|}
   
144行目: 153行目:
 
+-----------------------------------------------------------------------+ +----------------+
 
+-----------------------------------------------------------------------+ +----------------+
 
| Logical volume1 | Logical volume2 | Logical volume3 | | |
 
| Logical volume1 | Logical volume2 | Logical volume3 | | |
|/dev/MyStorage/swapvol |/dev/MyStorage/rootvol |/dev/MyStorage/homevol | | Boot partition |
+
|/dev/mapper/MyVol-swap |/dev/mapper/MyVol-root |/dev/mapper/MyVol-home | | Boot partition |
 
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on |
 
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on |
 
| | | other device) |
 
| | | other device) |
155行目: 164行目:
 
{{Tip|Two variants of this setup:
 
{{Tip|Two variants of this setup:
 
* [[Dm-crypt/特記事項#リモート LUKS ヘッダーを使ってシステムを暗号化]]ではこのセットアップと USB デバイスのリモート LUKS ヘッダーを使って二段階認証を実現します。
 
* [[Dm-crypt/特記事項#リモート LUKS ヘッダーを使ってシステムを暗号化]]ではこのセットアップと USB デバイスのリモート LUKS ヘッダーを使って二段階認証を実現します。
* Instructions at [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ Pavel Kogan's blog] show how to encrypt the {{ic|/boot}} partition while keeping it on the main LUKS partition when using GRUB, but be aware of {{Bug|43663}}.}}
+
* Instructions at [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/ Pavel Kogan's blog] show how to encrypt the {{ic|/boot}} partition while keeping it on the main LUKS partition when using GRUB.}}
   
 
=== ディスクの準備 ===
 
=== ディスクの準備 ===
184行目: 193行目:
 
# pvcreate /dev/mapper/lvm
 
# pvcreate /dev/mapper/lvm
   
{{ic|MyStorage}} という名前のボリュームグループを作成して、先に作成した物理ボリュームを追加:
+
{{ic|MyVol}} という名前のボリュームグループを作成して、先に作成した物理ボリュームを追加:
   
# vgcreate MyStorage /dev/mapper/lvm
+
# vgcreate MyVol /dev/mapper/lvm
   
 
ボリュームグループに論理ボリュームを作成:
 
ボリュームグループに論理ボリュームを作成:
   
# lvcreate -L 8G MyStorage -n swapvol
+
# lvcreate -L 8G MyVol -n swap
# lvcreate -L 15G MyStorage -n rootvol
+
# lvcreate -L 15G MyVol -n root
# lvcreate -l +100%FREE MyStorage -n homevol
+
# lvcreate -l 100%FREE MyVol -n home
   
 
論理ボリュームのファイルシステムをフォーマット:
 
論理ボリュームのファイルシステムをフォーマット:
   
# mkfs.ext4 /dev/mapper/MyStorage-rootvol
+
# mkfs.ext4 /dev/mapper/MyVol-root
# mkfs.ext4 /dev/mapper/MyStorage-homevol
+
# mkfs.ext4 /dev/mapper/MyVol-home
# mkswap /dev/mapper/MyStorage-swapvol
+
# mkswap /dev/mapper/MyVol-swap
   
 
ファイルシステムをマウント:
 
ファイルシステムをマウント:
   
# mount /dev/MyStorage/rootvol /mnt
+
# mount /dev/mapper/MyVol-root /mnt
 
# mkdir /mnt/home
 
# mkdir /mnt/home
# mount /dev/MyStorage/homevol /mnt/home
+
# mount /dev/mapper/MyVol-home /mnt/home
# swapon /dev/MyStorage/swapvol
+
# swapon /dev/mapper/MyVol-swap
   
 
=== boot パーティションの準備 ===
 
=== boot パーティションの準備 ===
239行目: 248行目:
 
起動時に暗号化された root パーティションの暗号化が解除されるように、以下のカーネルパラメータをブートローダーで設定します ({{ic|''<device-UUID>''}} は {{ic|/dev/sdaX}} の UUID に置き換えてください。詳しくは[[永続的なブロックデバイスの命名]]を参照):
 
起動時に暗号化された root パーティションの暗号化が解除されるように、以下のカーネルパラメータをブートローダーで設定します ({{ic|''<device-UUID>''}} は {{ic|/dev/sdaX}} の UUID に置き換えてください。詳しくは[[永続的なブロックデバイスの命名]]を参照):
   
cryptdevice=UUID=''<device-UUID>'':MyStorage root=/dev/mapper/MyStorage-rootvol
+
cryptdevice=UUID=''device-UUID'':lvm
   
 
詳しくは [[Dm-crypt/システム設定#ブートローダー]] を見て下さい。
 
詳しくは [[Dm-crypt/システム設定#ブートローダー]] を見て下さい。
332行目: 341行目:
 
== Plain dm-crypt ==
 
== Plain dm-crypt ==
   
  +
Contrary to LUKS, dm-crypt ''plain'' mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow [[Wikipedia:Deniable encryption|deniable encryption]]. See also [[wikipedia:Disk encryption#Full disk encryption]].
This scenario sets up a system on a dm-crypt a full disk with ''plain'' mode encryption. Note that for most use cases, the methods using LUKS described above are the better options for both system encryption and encrypted partitions. LUKS features like key management with multiple pass-phrases/key-files are unavailable with ''plain'' mode.
 
   
  +
Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with ''plain'' mode.
dm-crypt ''plain'' mode does not require a header on the encrypted disk: this means that an unpartitioned, encrypted disk will be indistinguishable from a disk filled with random data, which is the desired attribute for this scenario, see also [[Wikipedia:Deniable encryption]].
 
   
''Plain'' dm-crypt encrypted disks can be more resilient to damage than LUKS encrypted disks, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using ''plain'' mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also [[ディスク暗号化#暗号メタデータ]].
+
''Plain'' dm-crypt encryption can be more resilient to damage than LUKS encrypted disks, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using ''plain'' mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also [[ディスク暗号化#暗号メタデータ]]. Using ''plain'' mode could also be considered if concerned with the problems explained in [[Dm-crypt/特記事項#ソリッドステートドライブ (SSD) の Discard/TRIM のサポート]].
   
 
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are:
 
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are:
342行目: 351行目:
 
* dm-crypt LUKS mode by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook [[Dm-crypt/特記事項#リモート LUKS ヘッダーを使ってシステムを暗号化|may be modified]].}}
 
* dm-crypt LUKS mode by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook [[Dm-crypt/特記事項#リモート LUKS ヘッダーを使ってシステムを暗号化|may be modified]].}}
   
The scenario uses a USB stick for the boot device and another one to store the encryption key. The disk layout is:
+
The scenario uses two USB sticks:
  +
* one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;
  +
* another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[Dm-crypt/Device encryption#Keyfiles]] to prepare the keyfile.
   
 
|--------------------+------------------+--------------------+ +---------------+ +---------------+
 
|--------------------+------------------+--------------------+ +---------------+ +---------------+
353行目: 364行目:
 
|disk drive /dev/sdaX encrypted using plain mode and LVM | |USB stick 1 | |USB stick 2 |
 
|disk drive /dev/sdaX encrypted using plain mode and LVM | |USB stick 1 | |USB stick 2 |
 
+------------------------------------------------------------+ +---------------+ +---------------+
 
+------------------------------------------------------------+ +---------------+ +---------------+
 
{{ic|/boot}} and the boot loader cannot be kept on the encrypted drive, or it will defeat the purpose of using ''plain'' mode for deniable encryption. This also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone.
 
 
This scenario also uses a key file, assuming it stored as raw bits on a second USB stick, so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[Dm-crypt/デバイスの暗号化#キーファイル]] to prepare the keyfile.
 
   
 
{{Tip|
 
{{Tip|
419行目: 426行目:
   
 
cryptdevice=/dev/sd''X'':enc cryptkey=/dev/sd''Z'':0:512 crypto=sha512:twofish-xts-plain64:512:0:
 
cryptdevice=/dev/sd''X'':enc cryptkey=/dev/sd''Z'':0:512 crypto=sha512:twofish-xts-plain64:512:0:
  +
  +
{{Note|encrypt の代わりに sd-encrypt を使用する場合、cryptdevice の代わりに {{ic|''luks.uuid''}} を使ってください。詳しくは ''systemd-cryptsetup-generator(8)'' を参照。}}
   
 
他に必要なパラメータについては [[Dm-crypt/システム設定#ブートローダー]] を見て下さい。
 
他に必要なパラメータについては [[Dm-crypt/システム設定#ブートローダー]] を見て下さい。
457行目: 466行目:
 
+---------------+----------------+--------------------------------------------------+
 
+---------------+----------------+--------------------------------------------------+
   
{{Tip|All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].}}
+
{{Tip|All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].}}
  +
{{Note|{{AUR|cryptboot}} パッケージの {{ic|cryptboot}} スクリプトを使うことで暗号化された boot の管理 (マウント・アンマウント・パッケージのアップグレード) を簡単にできます。また、[[セキュアブート#自分で署名した鍵を使う|UEFI Secure Boot]] を使用して [https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html 悪意あるメイド] 攻撃から身を守ることができます。詳しくは [https://github.com/xmikos/cryptboot cryptboot のプロジェクトページ] を参照。}}
   
 
=== ディスクの準備 ===
 
=== ディスクの準備 ===
553行目: 563行目:
 
=== ブートローダーの設定 ===
 
=== ブートローダーの設定 ===
   
起動時に暗号化された root パーティションの暗号化が解除されるように、以下のカーネルパラメータブートローダーで設定します ({{ic|''<device-UUID>''}} は {{ic|/dev/sdaX}} の UUID に置き換えてください。詳しくは[[永続的なブロックデバイスの命名]]を参照):
+
起動時に LUKS で暗号化された {{ic|/boot}} パーティションを認識して暗号化された root パーティションの暗号化が解除されるように GRUB を設定:
   
  +
{{hc|/etc/default/grub|2=
cryptdevice=UUID=''<device-UUID>'':MyStorage root=/dev/mapper/MyStorage-rootvol
 
  +
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=''<device-UUID>'':lvm ..."
  +
GRUB_ENABLE_CRYPTODISK=y
  +
}}
   
詳しくは [[Dm-crypt/システム設定#ブートローダー]] を参照。
+
詳しくは [[Dm-crypt/システム設定#ブートローダー]] [[GRUB#Boot パーティション]]を参照。{{ic|''<device-UUID>''}} は {{ic|/dev/sdaZ}} (ルートファイルシステムが存在する LVM が含まれているパーティション) の UUID に置き換えてください。詳しくは[[永続的なブロックデバイスの命名]]を参照。
   
  +
GRUB の[[GRUB#メイン設定ファイルの生成|設定ファイル]]を作成して、マウントされている ESP に [[GRUB#インストール|GRUB をインストール]]:
それから GRUB ブートローダーをインストールして LUKS で暗号化された {{ic|/boot}} パーティションを認識させます。[[GRUB#Boot パーティション]]を参照。
 
 
{{ic|/etc/default/grub}} を開いてパラメーターを末端に追加:
 
 
{{ic|1=GRUB_ENABLE_CRYPTODISK=y}}
 
 
GRUB メニュー設定ファイルを作成:
 
   
 
# grub-mkconfig -o /boot/grub/grub.cfg
 
# grub-mkconfig -o /boot/grub/grub.cfg
 
マウントされている ESP に [[GRUB#インストール|GRUB をインストール]]:
 
 
 
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck
 
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck
   
597行目: 601行目:
 
* It may be worth considering to add the GRUB bootloader to the ignore list of {{ic|/etc/pacman.conf}} in order to take particular control of when the bootloader (which includes its own encryption modules) is updated.
 
* It may be worth considering to add the GRUB bootloader to the ignore list of {{ic|/etc/pacman.conf}} in order to take particular control of when the bootloader (which includes its own encryption modules) is updated.
 
* If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[Dm-crypt/特記事項#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}
 
* If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[Dm-crypt/特記事項#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}
  +
  +
== Btrfs サブボリュームとスワップ ==
  +
  +
The following example creates a full system encryption with LUKS using [[Btrfs]] subvolumes to [[Btrfs#Mounting_subvolumes|simulate partitions]].
  +
  +
If using UEFI, an [[EFI System Partition]] (ESP) is required. {{ic|/boot}} itself may reside on {{ic|/}} and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is {{ic|/dev/sda''Y''}} and is mounted at {{ic|/boot/efi}}. {{ic|/boot}} itself is located on the system partition, {{ic|/dev/sda''X''}}.
  +
  +
Since {{ic|/boot}} resides on the encrypted {{ic|/}}, [[GRUB]] must be used as the bootloader because only GRUB can load modules necessary to decrypt {{ic|/boot}} (e.g., crypto.mod, cryptodisk.mod and luks.mod) [http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/].
  +
  +
Additionally an optional plain-encrypted [[swap]] partition is shown.
  +
  +
{{Warning|Do not use a [[swap file]] instead of a separate partition, because this may result in data loss. See [[Btrfs#Swap file]].}}
  +
  +
+--------------------------+--------------------------+--------------------------+
  +
|ESP |System partition |Swap partition |
  +
|'''un'''encrypted |LUKS-encrypted |plain-encrypted |
  +
| | | |
  +
|/boot/efi |/ | |
  +
|/dev/sda''Y'' |/dev/sda''X'' |/dev/sda''Z'' |
  +
|--------------------------+--------------------------+--------------------------+
  +
  +
=== ディスクの準備 ===
  +
  +
{{Note|It is not possible to use btrfs partitioning as described in [[Btrfs#Partitionless Btrfs disk]] when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.}}
  +
  +
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[Dm-crypt/Drive preparation]]. If you are using [[UEFI]] create an [[EFI System Partition]] with an appropriate size. It will later be mounted at {{ic|/boot/efi}}. If you are going to create an encrypted swap partition, create the partition for it, but do '''not''' mark it as swap, since plain ''dm-crypt'' will be used with the partition.
  +
  +
Create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda''X''}}). See the [[Partitioning]] article.
  +
  +
=== システムパーティションの準備 ===
  +
  +
==== LUKS コンテナの作成 ====
  +
  +
Follow [[dm-crypt/Device encryption#Encrypting devices with LUKS mode]] to setup {{ic|/dev/sda''X''}} for LUKS. See the [[Dm-crypt/Device encryption#Encryption options for LUKS mode]] before doing so for a list of encryption options.
  +
  +
==== LUKS コンテナの解錠 ====
  +
  +
Now follow [[Dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper]] to unlock the LUKS container and map it.
  +
  +
==== マッピングされたデバイスのフォーマット ====
  +
  +
Proceed to format the mapped device as described in [[Btrfs#File system on a single device]], where {{ic|''/dev/partition''}} is the name of the mapped device (i.e., {{ic|cryptroot}}) and '''not''' {{ic|/dev/sda''X''}}.
  +
  +
==== マッピングされたデバイスのマウント ====
  +
  +
Finally, [[mount]] the now-formatted mapped device (i.e., {{ic|/dev/mapper/cryptroot}}) to {{ic|/mnt}}.
  +
  +
{{Tip|You may want to use the {{ic|1=compress=lzo}} mount option. See [[Btrfs#Compression]] for more information.}}
  +
  +
=== btrfs サブボリュームの作成 ===
  +
  +
==== レイアウト ====
  +
  +
[[Btrfs#Subvolumes|Subvolumes]] will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:
  +
  +
subvolid=5 (/dev/sda''X'')
  +
|
  +
├── @ (mounted as /)
  +
| |
  +
| ├── /bin (directory)
  +
| |
  +
| ├── /home (mounted @home subvolume)
  +
| |
  +
| ├── /usr (directory)
  +
| |
  +
| ├── /.snapshots (mounted @snapshots subvolume)
  +
| |
  +
| ├── /var/cache/pacman/pkg (nested subvolume)
  +
| |
  +
| ├── ... (other directories and nested subvolumes)
  +
|
  +
├── @snapshots (mounted as /.snapshots)
  +
|
  +
├── @home (mounted as /home)
  +
|
  +
└── @... (additional subvolumes you wish to use as mount points)
  +
  +
This section follows the [[Snapper#Suggested filesystem layout]], which is most useful when used with [[Snapper]]. You should also consult [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs Wiki SysadminGuide#Layout].
  +
  +
==== トップレベルサブボリュームの作成 ====
  +
  +
Here we are using the convention of prefixing {{ic|@}} to subvolume names that will be used as mount points, and {{ic|@}} will be the subvolume that is mounted as {{ic|/}}.
  +
  +
Following the [[Btrfs#Creating a subvolume]] article, create subvolumes at {{ic|/mnt/@}}, {{ic|/mnt/@snapshots}}, and {{ic|/mnt/@home}}.
  +
  +
Create any additional subvolumes you wish to use as mount points now.
  +
  +
==== トップレベルサブボリュームのマウント ====
  +
  +
Unmount the system partition at {{ic|/mnt}}.
  +
  +
Now mount the newly created {{ic|@}} subvolume which will serve as {{ic|/}} to {{ic|/mnt}} using the {{ic|1=subvol=}} mount option. Assuming the mapped device is named {{ic|cryptroot}}, the command would look like:
  +
  +
# mount -o compress=lzo,subvol=@ /dev/mapper/cryptroot /mnt
  +
  +
See [[Btrfs#Mounting subvolumes]] for more details.
  +
  +
Also mount the other subvolumes to their respective mount points: {{ic|@home}} to {{ic|/mnt/home}} and {{ic|@snapshots}} to {{ic|/mnt/.snapshots}}.
  +
  +
==== ネストされたサブボリュームの作成 ====
  +
  +
Create any subvolumes you do '''not''' want to have snapshots of when taking a snapshot of {{ic|/}}. For example, you probably do not want to take snapshots of {{ic|/var/cache/pacman/pkg}}. These subvolumes will be nested under the {{ic|@}} subvolume, but just as easily could have been created earlier at the same level as {{ic|@}} according to your preference.
  +
  +
Since the {{ic|@}} subvolume is mounted at {{ic|/mnt}} you will need to [[create a subvolume]] at {{ic|/mnt/var/cache/pacman/pkg}} for this example. You may have to create any parent directories first.
  +
  +
Other directories you may wish to do this with are {{ic|/var/abs}}, {{ic|/var/tmp}}, and {{ic|/srv}}.
  +
  +
==== ESP のマウント ====
  +
  +
If you prepared an EFI system partition earlier, create its mount point and mount it now.
  +
  +
{{Note|Btrfs snapshots will exclude {{ic|/boot/efi}}, since it is not a btrfs file system.}}
  +
  +
At the [[Installation guide#Install the base packages|pacstrap]] installation step, the {{Pkg|btrfs-progs}} must be installed in addition to the base group.
  +
  +
=== mkinitcpio の設定 ===
  +
  +
==== キーファイルの作成 ====
  +
  +
In order for GRUB to open the LUKS partition without having the user enter his passphrase twice, we will use a keyfile embedded in the initramfs. Follow [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] making sure to add the key to {{ic|/dev/sda''X''}} at the ''luksAddKey'' step.
  +
  +
==== mkinitcpio.conf の編集 ====
  +
  +
After creating, adding, and embedding the key as described above, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]] as well as any other hooks you require. See [[Dm-crypt/System configuration#mkinitcpio]] for detailed information. Be sure to regenerate the initial ramdisk when finished.
  +
  +
{{Tip|You may want to add {{ic|1=BINARIES="/usr/bin/btrfs"}} to your {{ic|mkinitcpio.conf}}. See the [[Btrfs#Corruption recovery]] article.}}
  +
  +
=== ブートローダーの設定 ===
  +
  +
Install [[GRUB]] to {{ic|/dev/sda}}. Then, edit {{ic|/etc/default/grub}} as instructed in the [[GRUB#Encryption]] article, following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file.
  +
  +
=== スワップの設定 ===
  +
  +
If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at [[Dm-crypt/Swap encryption]].
  +
  +
After completing this step, continue configuring your system as normal according to the [[Installation_guide#Reboot|installation guide]].

2016年9月22日 (木) 21:38時点における版

dm-crypt に戻る。

以下は dm-crypt を使って完全なシステム暗号化を行う一般的なシナリオの例です。通常のインストール手順に加える必要がある変更を全て説明しています。必要なツールは全て インストールイメージ に入っています。

目次

概要

root ファイルシステムの暗号化については機能やパフォーマンスの点で dm-crypt が優れています。システムの root ファイルシステムが dm-crypt デバイス上にあれば、システム上のほとんど全てのファイルが暗号化されます。root 以外のファイルシステムを選択的に暗号化するのと異なり、root ファイルシステムの暗号化は様々な情報を隠匿できます。インストールされているプログラム、ユーザーアカウントのユーザー名、mlocate/var/log/ など媒介してデータ漏洩の恐れがあるファイルなど。さらに、root ファイルシステムを暗号化することでシステムの改竄が非常に難しくなります。ブートローダーやカーネルを除く全てが暗号化されるためです。

以上の利点をのぞく、それぞれのシナリオのメリットやデメリットなどの違いをまとめて、全てのシナリオを以下の表で説明します:

シナリオ メリット デメリット
#LUKS を使用するシンプルなパーティションレイアウト

LUKS で root を完全に暗号化するベーシックなセットアップ

  • パーティショニングと設定がシンプル
  • 柔軟性がない、暗号化するディスク領域をあらかじめ指定する必要がある
#LVM on LUKS

LUKS 暗号化パーティションの中で LVM を使うことでパーティショニングの柔軟性を確保

  • LVM を使ったことがあるのであれば簡単にパーティショニングできます
  • 一つのキーで全てのボリュームのロックを解除できます (ディスクからの復帰を設定するのが簡単)
  • ロックされていればボリュームのレイアウトが外から分かりません
  • ハイバネートを利用したいときの一番簡単な方法
  • LVM によってマッピングレイヤーとフックが追加されます
  • ボリュームごとに別のキーを設定する場合は不便です
#LUKS on LVM

LVM をセットアップした後に dm-crypt を使用

  • LVM を使うことで複数のディスクにまたがる暗号化ボリュームを作成できます
  • 非暗号化・暗号化ボリュームグループを簡単に混ぜられます
  • 複雑です。ボリュームを変更するときは暗号化マッパーも変更する必要があります
  • ボリュームごとに個別のキーが必要になります
  • ロックされていても LVM レイアウトは外から分かってしまいます
#Plain dm-crypt

dm-crypt の plain モードを使用、LUKS ヘッダーや LUKS の複数のキーのオプションは使わない
このシナリオでは /boot とキーストレージに USB デバイスを使いますが、これは他のデバイスでも利用可能です

  • LUKS ヘッダに損害が発生した場合の耐障害性があります
  • 否認可能暗号が使える
  • SSD の問題を解決できます
  • 全ての暗号化パラメータに注意する必要があります
  • 暗号鍵はひとつだけで変更する方法はありません
#boot パーティションの暗号化 (GRUB)

GRUB ブートローダーを使って boot パーティションを暗号化する方法を説明します。
このシナリオでは ESP パーティションを使いますが、他のシナリオでも ESP を使うことができます。

  • ベースにするシナリオと同じメリット (このページの例では LVM on LUKS)
  • ブートローダーや ESP パーティションまで暗号化されます
  • ベースにするシナリオと同じデメリット (このページの例では LVM on LUKS)
  • 設定が複雑です
  • 他のブートローダーのサポートがありません
#Btrfs サブボリュームとスワップ

UEFI 環境で Btrfs のシステムパーティションと /boot ディレクトリを暗号化して、スワップパーティションを追加する方法。

上記全てのシナリオが外部からの脅威に対して十分な保護を約束しますが、共通の欠点も存在します。暗号化キーを持っているユーザーなら誰でもデバイスの全てを復号化して、他のユーザーのデータにもアクセスすることが可能という点です。これが問題だという場合は、ブロックデバイスの暗号化とスタックファイルシステムの暗号化と組み合わせて使用することで、両者の利点を取り入れることができます。ディスク暗号化を見て下さい。

他にも、スワップパーティションの暗号化を設定するべきかどうか考慮する必要があります。Dm-crypt/スワップの暗号化を見て下さい。

シナリオで使用されているパーティショニングの外観について Dm-crypt/ドライブの準備#パーティショニング も参照してください。

LUKS を使用するシンプルなパーティションレイアウト

この例ではシンプルなパーティションレイアウトによる 'dmcrypt+ LUKS のフルシステム暗号化を説明します:

+--------------------+--------------------------+--------------------------+
|Boot partition      |LUKS encrypted system     |Optional free space       |
|                    |partition                 |for additional partitions |
|/dev/sdaY           |/dev/sdaX                 |or swap to be setup later |
+--------------------+--------------------------+--------------------------+

最初のステップは Arch Linux のインストールイメージを起動した後すぐに実行します。

ディスクの準備

パーティションを作成する前に、Dm-crypt/ドライブの準備 で説明されているように、ディスクを完全に消去する必要性・方法を学んでください。

それから必要なパーティションを作成します。最低でも / が必要です (例: /dev/sdaX) と /boot (/dev/sdaY)。パーティショニングを参照。

boot 以外のパーティションの準備

以下のコマンドは暗号化された root パーティションを作成・マウントします。Dm-crypt/root 以外のファイルシステムの暗号化#パーティション に詳しく説明されている手順に該当します (ページタイトルと相違して、mkinitcpioブートローダーが正しく設定されていれば、root パーティションにも適用できます)。デフォルトになってない特定の暗号化オプションを使いたいときは (例: 暗号アルゴリズムや鍵長など)、最初のコマンドを実行する前に暗号化オプションを読んでください:

# cryptsetup -y -v luksFormat /dev/sdaX
# cryptsetup open /dev/sdaX cryptroot
# mkfs -t ext4 /dev/mapper/cryptroot
# mount -t ext4 /dev/mapper/cryptroot /mnt

マッピングが問題ないかチェック:

# umount /mnt
# cryptsetup close cryptroot
# cryptsetup open /dev/sdaX cryptroot
# mount -t ext4 /dev/mapper/cryptroot /mnt

パーティションを分割した場合 (例: /home)、以上のコマンドを全てのパーティションに繰り返し実行してください。ただし /boot は別です。起動時に追加のパーティションを扱う方法は Dm-crypt/root 以外のファイルシステムの暗号化#ロック解除とマウントの自動化 を見て下さい。

それぞれのブロックデバイスには個々のパスフレーズが必要になります。起動時に、別々のパスフレーズを入力しないといけないので、不便とも言えます。crypttab を使うことでシステムパーティションにキーファイルを保存して使用することで別のパーティションを解錠することができます。方法は Dm-crypt/デバイスの暗号化#LUKS を使ってキーファイルでパーティションをフォーマット を見て下さい。

boot パーティションの準備

セットアップする必要があるのは暗号化されない /boot パーティションで、暗号化する root に必要となります。例えば、標準的な MBR/BIOS/boot パーティションの場合、以下を実行します:

# mkfs -t ext4 /dev/sdaY
# mkdir /mnt/boot
# mount -t ext4 /dev/sdaY /mnt/boot

デバイスのマウント

インストールガイド#パーティションのマウントでは実際のパーティションではなく、マップされたデバイスをマウントしてください。もちろん、/boot は暗号化されていないので、直接マウントします。

mkinitcpio の設定

encrypt フックを mkinitcpio.conf 内の filesystems の前に追加します:

etc/mkinitcpio.conf
HOOKS="... encrypt ... filesystems ..."

他に必要なフックについては dm-crypt/システム設定#mkinitcpio を見て下さい。

設定後はイメージを再生成してください:

# mkinitcpio -p linux

ブートローダーの設定

暗号化された root パーティションを起動するには、ブートローダーに以下のカーネルパラメータを設定する必要があります (<device-UUID>/dev/sdaX の UUID に置き換えてください。詳しくは永続的なブロックデバイスの命名を参照):

cryptdevice=UUID=<device-UUID>:cryptroot root=/dev/mapper/cryptroot

他に必要なパラメータについては Dm-crypt/システム設定#ブートローダー を見て下さい。

LVM on LUKS

The straight-forward method is to set up LVM on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted blockdevice. Hence, the LVM is not transparent until the blockdevice is unlocked and the underlying volume structure is scanned and mounted during boot.

The disk layout in this example is:

+-----------------------------------------------------------------------+ +----------------+
| Logical volume1       | Logical volume2       | Logical volume3       | |                |
|/dev/mapper/MyVol-swap |/dev/mapper/MyVol-root |/dev/mapper/MyVol-home | | Boot partition |
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on     |
|                                                                       | | other device)  |
|                        LUKS encrypted partition                       | |                |
|                          /dev/sdaX                                    | | /dev/sdbY      |
+-----------------------------------------------------------------------+ +----------------+

この方法では論理ボリュームを複数のディスクに跨がらせることはできません。後で変更することも不可能です。#LUKS on LVM の方法ではそのような制限はありません。

ヒント: Two variants of this setup:

ディスクの準備

パーティションを作成する前に、Dm-crypt/ドライブの準備 で説明されているように、ディスクを完全に消去する必要性・方法を学んでください。

GPTGRUB ブートローダーを使う時は、GRUB#BIOS システム で説明されているように BIOS Boot Partition を作成してください。

/boot にマウントするパーティションをタイプ 8300 で容量 100 MB 以上にして作成します。

タイプ 8E00 のパーティションを作成してください。後で暗号化コンテナを入れます。

"system" パーティションに LUKS 暗号化コンテナを作成してください。選んだパスワードを二回入力します。

# cryptsetup luksFormat /dev/sdaX

cryptsetup のオプションについては LUKS 暗号化のオプションを見て下さい。

コンテナを開いてください:

# cryptsetup open --type luks /dev/sdaX lvm

The decrypted container is now available at /dev/mapper/lvm.

論理ボリュームの準備

開いた LUKS コンテナの上に物理ボリュームを作成:

# pvcreate /dev/mapper/lvm

MyVol という名前のボリュームグループを作成して、先に作成した物理ボリュームを追加:

# vgcreate MyVol /dev/mapper/lvm

ボリュームグループに論理ボリュームを作成:

# lvcreate -L 8G MyVol -n swap
# lvcreate -L 15G MyVol -n root
# lvcreate -l 100%FREE MyVol -n home

論理ボリュームのファイルシステムをフォーマット:

# mkfs.ext4 /dev/mapper/MyVol-root
# mkfs.ext4 /dev/mapper/MyVol-home
# mkswap /dev/mapper/MyVol-swap

ファイルシステムをマウント:

# mount /dev/mapper/MyVol-root /mnt
# mkdir /mnt/home
# mount /dev/mapper/MyVol-home /mnt/home
# swapon /dev/mapper/MyVol-swap

boot パーティションの準備

ブートローダーは /boot ディレクトリから、カーネルや initramfs、あるいはブートローダーの設定ファイルをロードします。このディレクトリは暗号化されていない別のファイルシステム上に配置する必要があります。

/boot にするパーティションに Ext2 ファイルシステムを作成します。ブートローダーが読み込めるファイルシステムなら何でもかまいません。

# mkfs.ext2 /dev/sdbY

/mnt/boot ディレクトリを作成:

# mkdir /mnt/boot

パーティションを /mnt/boot にマウント:

# mount /dev/sdbY /mnt/boot

Aftwards continue with the installation procedure up to the mkinitcpio step.

mkinitcpio の設定

encryptlvm2 フックを mkinitcpio.conf 内の filesystems の前に追加します:

/etc/mkinitcpio.conf
HOOKS="... encrypt lvm2 ... filesystems ..."
ノート: The order of both hooks no longer matters with the current implementation of lvm2.

他に必要なフックについては dm-crypt/システム設定#mkinitcpio を見て下さい。

設定後はイメージを再生成してください:

# mkinitcpio -p linux

ブートローダーの設定

起動時に暗号化された root パーティションの暗号化が解除されるように、以下のカーネルパラメータをブートローダーで設定します (<device-UUID>/dev/sdaX の UUID に置き換えてください。詳しくは永続的なブロックデバイスの命名を参照):

cryptdevice=UUID=device-UUID:lvm

詳しくは Dm-crypt/システム設定#ブートローダー を見て下さい。

LUKS on LVM

LVM 上で暗号化を利用するには、まず LVM ボリュームをセットアップして、それから暗号化パーティションのベースとして使うことになります。この方法では、暗号化パーティションと非暗号化パーティションのミックスが可能です。#LVM on LUKS とは違って、複数のディスクにまたがる論理ボリュームを通常通り使うことができます。

The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for /tmp and /swap. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan. If you want to span a logical volume over multiple disks during setup already, a procedure to do so is described in Dm-crypt/特記事項#LVM を複数のディスクに拡張.

ディスクの準備

パーティションスキーム:

  • /dev/sda1 -> /boot
  • /dev/sda2 -> LVM

Dm-crypt/ドライブの準備#インストール前に dm-crypt で消去を見て /dev/sda2 をランダム化してください。

論理ボリュームの準備

# lvm pvcreate /dev/sda2
# lvm vgcreate lvm /dev/sda2
# lvm lvcreate -L 10G -n lvroot lvm
# lvm lvcreate -L 500M -n swap lvm
# lvm lvcreate -L 500M -n tmp lvm
# lvm lvcreate -l 100%FREE -n home lvm
# cryptsetup luksFormat -c aes-xts-plain64 -s 512 /dev/lvm/lvroot
# cryptsetup open --type luks /dev/lvm/lvroot root
# mkfs -t ext4 /dev/mapper/root
# mount /dev/mapper/root /mnt

Note that /home will be encrypted later in this example. Further, note that if you ever have to access the encrypted root from the Arch-ISO, the above open action will allow you to after the LVM shows up.

boot パーティションの準備

# dd if=/dev/zero of=/dev/sda1 bs=1M
# mkfs -t ext4 /dev/sda1
# mkdir /mnt/boot
# mount /dev/sda1 /mnt/boot

Now after setup of the encrypted LVM partitioning, it would be time to install: Arch Install Scripts.

mkinitcpio の設定

encryptlvm2 フックを mkinitcpio.conf 内の filesystems の前に追加します:

etc/mkinitcpio.conf
HOOKS="... block ''encrypt lvm2 ... filesystems ..."

他に必要なフックについては dm-crypt/システム設定#mkinitcpio を見て下さい。

設定ファイルを変更した後は次のコマンドを root 権限で実行してください:

# mkinitcpio -p linux

ブートローダーの設定

上の例の場合、ブートローダーの設定で root デバイスのカーネルオプションを以下のように変更します:

cryptdevice=/dev/lvm/lvroot:cryptoroot root=/dev/mapper/cryptoroot

詳しくは Dm-crypt/システム設定#ブートローダー を見て下さい。

fstab と crypttab の設定

/etc/fstab
 /dev/mapper/root        /       ext4            defaults        0       1
 /dev/sda1               /boot   ext4            defaults        0       2
 /dev/mapper/tmp         /tmp    tmpfs           defaults        0       0
 /dev/mapper/swap        none    swap            sw              0       0

以下の crypttab オプションは再起動するたびに一時ファイルシステムを暗号化します:

/etc/crypttab
 swap	/dev/lvm/swap	/dev/urandom	swap,cipher=aes-xts-plain64,size=256
 tmp	/dev/lvm/tmp	/dev/urandom	tmp,cipher=aes-xts-plain64,size=256

論理ボリューム /home の暗号化

Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for /home should be persistent, of course. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths. To safe on entering a second passphrase at boot for it, a keyfile is created:

mkdir -m 700 /etc/luks-keys
dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256

論理ボリュームは以下のように暗号化します:

cryptsetup luksFormat -v -s 512 /dev/lvm/home /etc/luks-keys/home
cryptsetup -d /etc/luks-keys/home open --type luks /dev/lvm/home home
mkfs -t ext4 /dev/mapper/home
mount /dev/mapper/home /home

暗号化されたマウントは crypttab で設定します:

/etc/crypttab
home	/dev/lvm/home   /etc/luks-keys/home
/etc/fstab
/dev/mapper/home        /home   ext4        defaults        0       2

これでセットアップは完了です。 and setup is done.

If you want to expand the logical volume for /home (or any other volume) at a later point, it is important to note that the LUKS encrypted part has to be resized as well. For a procedure see Dm-crypt/特記事項#LVM を複数のディスクに拡張.

Plain dm-crypt

Contrary to LUKS, dm-crypt plain mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow deniable encryption. See also wikipedia:Disk encryption#Full disk encryption.

Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with plain mode.

Plain dm-crypt encryption can be more resilient to damage than LUKS encrypted disks, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using plain mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also ディスク暗号化#暗号メタデータ. Using plain mode could also be considered if concerned with the problems explained in Dm-crypt/特記事項#ソリッドステートドライブ (SSD) の Discard/TRIM のサポート.

ヒント: If headerless encryption is your goal but you are unsure about the lack of key-derivation with plain mode, then two alternatives are:
  • tcplay which offers headerless encryption but with the PBKDF2 function, or
  • dm-crypt LUKS mode by using the cryptsetup --header option. It cannot be used with the standard encrypt hook, but the hook may be modified.

The scenario uses two USB sticks:

  • one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;
  • another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also Wikipedia:Security through obscurity, follow Dm-crypt/Device encryption#Keyfiles to prepare the keyfile.
|--------------------+------------------+--------------------+ +---------------+ +---------------+
|Volume 1:           |Volume 2:         |Volume 3:           | |Boot device    | |Encryption key |
|                    |                  |                    | |               | |file storage   |
|root                |swap              |home                | |/boot          | |(unpartitioned |
|                    |                  |                    | |               | |in example)    |
|/dev/store/root     |/dev/store/swap   |/dev/store/home     | |/dev/sdY1      | |/dev/sdZ       |
|--------------------+------------------+--------------------| |---------------| |---------------|
|disk drive /dev/sdaX encrypted using plain mode and LVM     | |USB stick 1    | |USB stick 2    |
+------------------------------------------------------------+ +---------------+ +---------------+
ヒント:
  • It is also possible to use a single usb key by copying the keyfile to the initram directly. An example keyfile /etc/keyfile gets copied to the initram image by setting FILES="/etc/keyfile" in /etc/mkinitcpio.conf. The way to instruct the encrypt hook to read the keyfile in the initram image is using rootfs: prefix before the filename, e.g. cryptkey=rootfs:/etc/keyfile.
  • Another option is using a passphrase with good entropy.

ディスクの準備

It is vital that the mapped device is filled with data. In particular this applies to the scenario usecase we apply here.

Dm-crypt/ドライブの準備Dm-crypt/ドライブの準備#dm-crypt 固有の方法 を見て下さい。

boot 以外のパーティションの準備

詳しくは Dm-crypt/デバイスの暗号化#plain モードの暗号化オプション を参照。

Using the device /dev/sdX, with the twofish-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:

# cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=/dev/sdZ --key-size=512 open --type=plain /dev/sdX enc

Unlike encrypting with LUKS, the above command must be executed in full whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details.

We can now check a mapping entry has been made for /dev/mapper/enc:

# fdisk -l

Next, we setup LVM logical volumes on the mapped device, see LVM#Arch Linux を LVM にインストールする for further details:

# pvcreate /dev/mapper/enc
# vgcreate store /dev/mapper/enc
# lvcreate -L 20G store -n root
# lvcreate -L 10G store -n swap
# lvcreate -l +100%FREE store -n home

論理ボリュームをフォーマットしてマウントします。詳しくはファイルシステム#デバイスのフォーマットを見て下さい

# mkfs.ext4 /dev/store/root
# mkfs.ext4 /dev/store/home
# mount /dev/store/root /mnt
# mkdir /mnt/home
# mount /dev/store/home /mnt/home
# mkswap /dev/store/swap
# swapon /dev/store/swap

boot パーティションの準備

The /boot partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200MB partition is all that is required. Create the partition using a partitioning tool of your choice.

We choose a non-journalling file system to preserve the flash memory of the /boot partition, if not already formatted as vfat:

# mkfs.ext2 /dev/sdY1
# mkdir /mnt/boot
# mount /dev/sdY1 /mnt/boot

mkinitcpio の設定

encryptlvm2 フックを mkinitcpio.conf 内の filesystems の前に追加します:

etc/mkinitcpio.conf
HOOKS="... encrypt lvm2 ... filesystems ..."

他に必要なフックについては dm-crypt/システム設定#mkinitcpio を見て下さい。

設定後はイメージを再生成してください:

# mkinitcpio -p linux

ブートローダーの設定

暗号化した root パーティションを起動するには、以下のカーネルパラメータをブートローダーで設定する必要があります:

cryptdevice=/dev/sdX:enc cryptkey=/dev/sdZ:0:512 crypto=sha512:twofish-xts-plain64:512:0:
ノート: encrypt の代わりに sd-encrypt を使用する場合、cryptdevice の代わりに luks.uuid を使ってください。詳しくは systemd-cryptsetup-generator(8) を参照。

他に必要なパラメータについては Dm-crypt/システム設定#ブートローダー を見て下さい。

ヒント: GRUB を使用する場合、次のコマンドを使うことで /boot パーティションと同じ USB にインストールすることができます:
# grub-install --recheck /dev/sdY

インストール後

You may wish to remove the USB sticks after booting. Since the /boot partition is not usually needed, the noauto option can be added to the relevant line in /etc/fstab:

/etc/fstab
# /dev/sdYn
/dev/sdYn /boot ext2 noauto,rw,noatime 0 2

However, when an update to the kernel or bootloader is required, the /boot partition must be present and mounted. As the entry in fstab already exists, it can be mounted simply with:

# mount /boot

boot パーティションの暗号化 (GRUB)

This setup utilizes the same partition layout and configuration for the system's root partition as the previous #LVM on LUKS section, with two distinct differences:

  1. The setup is performed for an UEFI system and
  2. A special feature of the GRUB bootloader is used to additionally encrypt the boot partition /boot. See also GRUB#Boot partition.

The disk layout in this example is:

+---------------+----------------+----------------+----------------+----------------+
|ESP partition: |Boot partition: |Volume 1:       |Volume 2:       |Volume 3:       |
|               |                |                |                |                |
|/boot/efi      |/boot           |root            |swap            |home            |
|               |                |                |                |                |
|               |                |/dev/store/root |/dev/store/swap |/dev/store/home |
|/dev/sdaX      |/dev/sdaY       +----------------+----------------+----------------+
|unencrypted    |LUKS encrypted  |/dev/sdaZ encrypted using LVM on LUKS             |
+---------------+----------------+--------------------------------------------------+
ヒント: All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in #LVM on LUKS.
ノート: cryptbootAUR パッケージの cryptboot スクリプトを使うことで暗号化された boot の管理 (マウント・アンマウント・パッケージのアップグレード) を簡単にできます。また、UEFI Secure Boot を使用して 悪意あるメイド 攻撃から身を守ることができます。詳しくは cryptboot のプロジェクトページ を参照。

ディスクの準備

パーティションを作成する前に、Dm-crypt/ドライブの準備に書かれているように、ディスクを完全に消去するようにしてください。

EFI System Partition (ESP) を適当な容量で作成してください。後で /boot/efi にマウントします。

/boot にマウントするパーティションをタイプ 8300 の容量 100 MB 以上で作成します。

ヒント: BIOS/GPTGRUB ブートローダーを使用する場合は、GRUB#BIOS システムに書かれているように ESP の代わりに BIOS Boot Partition を作成してください。

タイプ 8E00 のパーティションを作成してください。後で暗号化コンテナを入れます。

"system" パーティションに LUKS 暗号化コンテナを作成してください。

# cryptsetup luksFormat /dev/sdaZ

上記のコマンドの cryptsetup で使えるオプションについては LUKS 暗号化オプションを参照してください。

パーティションレイアウトは以下のようになります:

 gdisk /dev/sda 
Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         1050623   512.0 MiB   EF00  EFI System
   2         1050624         1460223   200.0 MiB   8300  Linux filesystem
   3         1460224        41943006   19.3 GiB    8E00  Linux LVM

コンテナを開く:

# cryptsetup open --type luks /dev/sdaZ lvm

The decrypted container is now available at /dev/mapper/lvm.

論理ボリュームの準備

The LVM logical volumes of this example follow the exact layout as the previous scenario. Therefore, please follow Preparing the logical volumes above or adjust as required.

boot パーティションの準備

ブートローダーは /boot ディレクトリからカーネルや initramfs、あるいはブートローダーの設定ファイルをロードします。

First, create the LUKS container where the files will be located and installed into:

# cryptsetup luksFormat /dev/sdaY 

Next, open it:

# cryptsetup open /dev/sdaY cryptboot 

/boot にするパーティションにファイルシステムを作成。ブートローダーから読み込めるならどんなファイルシステムでもかまいません:

# mkfs.ext2 /dev/mapper/cryptboot

/mnt/boot ディレクトリを作成:

# mkdir /mnt/boot

パーティションを /mnt/boot にマウント:

# mount /dev/mapper/cryptboot /mnt/boot

grub-install から利用できるように ESP のマウントポイントを /boot/efi に作成してマウント:

# mkdir /mnt/boot/efi
# mount /dev/sdaX /mnt/boot/efi

この時点で、/mnt の中に以下のパーティションと論理ボリュームが作成されているはずです:

lsblk
NAME              	  MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                       8:0      0   200G  0 disk  
├─sda1                    8:1      0   512M  0 part  /boot/efi
├─sda2                    8:2      0   200M  0 part  
│ └─boot		  254:0    0   198M  0 crypt /boot
└─sda3                    8:3      0   100G  0 part  
  └─lvm                   254:1    0   100G  0 crypt 
    ├─MyStorage-swapvol   254:2    0     8G  0 lvm   [SWAP]
    ├─MyStorage-rootvol   254:3    0    15G  0 lvm   /
    └─MyStorage-homevol   254:4    0    77G  0 lvm   /home

Afterwards continue with the installation procedure up to the mkinitcpio step.

mkinitcpio の設定

mkinitcpio.confencryptlvm2 フックを追加:

/etc/mkinitcpio.conf
HOOKS="... encrypt lvm2 ... filesystems ..."

詳細や必要な他のフックについては dm-crypt/システム設定#mkinitcpio を参照。


設定後はイメージを再生成してください:

# mkinitcpio -p linux

ブートローダーの設定

起動時に LUKS で暗号化された /boot パーティションを認識して暗号化された root パーティションの暗号化が解除されるように GRUB を設定:

/etc/default/grub
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=<device-UUID>:lvm ..."
GRUB_ENABLE_CRYPTODISK=y

詳しくは Dm-crypt/システム設定#ブートローダーGRUB#Boot パーティションを参照。<device-UUID>/dev/sdaZ (ルートファイルシステムが存在する LVM が含まれているパーティション) の UUID に置き換えてください。詳しくは永続的なブロックデバイスの命名を参照。

GRUB の設定ファイルを作成して、マウントされている ESP に GRUB をインストール:

# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck

設定に問題がなければ、次の起動時に GRUB は /boot パーティションのロックを解除するためのパスフレーズを要求するはずです。

fstab と crypttab の設定

This section deals with extra configuration to let the system mount the encrypted /boot.

While GRUB asks for a passphrase to unlock the encrypted /boot after above instructions, the partition unlock is not passed on to the initramfs. Hence, /boot will not be available after the system has re-/booted, because the encrypt hook only unlocks the system's root.

インストール時に genfstab スクリプトを使用した場合、/boot/boot/efi マウントポイントのエントリが含まれた /etc/fstab が作成されています。しかしながらシステムはブートパーティションに生成されたデバイスマッパーを見つけることができません。デバイスマッパーを使えるようにするために、以下を crypttab に追加してください。例:

/etc/crypttab
cryptboot  /dev/sdaY      none        luks

上記を設定するとパスフレーズが二回要求されるようになります (GRUB と systemd ユニットでそれぞれ一回ずつ入力しなくてはなりません)。/boot のロックを解除するエントリを重複させたくない場合、Dm-crypt/デバイスの暗号化#キーファイルの指示に従ってください:

  1. ランダムなテキストのキーファイルを作成
  2. キーファイルを (/dev/sdaY) ブートパーティションの LUKS ヘッダに追加
  3. /etc/fstab のエントリを確認して起動時に自動的にロックが解除されるように /etc/crypttab 行を追加

何らかの理由でキーファイルを使って boot パーティションのロックを解除できなかった場合、systemd はフォールバックして解除するためのパスフレーズを要求します。パスフレーズが正しければ、起動に進みます。

ヒント: Optional post-installation steps:
  • It may be worth considering to add the GRUB bootloader to the ignore list of /etc/pacman.conf in order to take particular control of when the bootloader (which includes its own encryption modules) is updated.
  • If you want to encrypt the /boot partition to protect against offline tampering threats, the mkinitcpio-chkcryptoboot hook has been contributed to help.

Btrfs サブボリュームとスワップ

The following example creates a full system encryption with LUKS using Btrfs subvolumes to simulate partitions.

If using UEFI, an EFI System Partition (ESP) is required. /boot itself may reside on / and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is /dev/sdaY and is mounted at /boot/efi. /boot itself is located on the system partition, /dev/sdaX.

Since /boot resides on the encrypted /, GRUB must be used as the bootloader because only GRUB can load modules necessary to decrypt /boot (e.g., crypto.mod, cryptodisk.mod and luks.mod) [1].

Additionally an optional plain-encrypted swap partition is shown.

警告: Do not use a swap file instead of a separate partition, because this may result in data loss. See Btrfs#Swap file.
+--------------------------+--------------------------+--------------------------+
|ESP                       |System partition          |Swap partition            |
|unencrypted               |LUKS-encrypted            |plain-encrypted           |
|                          |                          |                          |
|/boot/efi                 |/                         |                          |
|/dev/sdaY                 |/dev/sdaX                 |/dev/sdaZ                 |
|--------------------------+--------------------------+--------------------------+

ディスクの準備

ノート: It is not possible to use btrfs partitioning as described in Btrfs#Partitionless Btrfs disk when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.

Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in Dm-crypt/Drive preparation. If you are using UEFI create an EFI System Partition with an appropriate size. It will later be mounted at /boot/efi. If you are going to create an encrypted swap partition, create the partition for it, but do not mark it as swap, since plain dm-crypt will be used with the partition.

Create the needed partitions, at least one for / (e.g. /dev/sdaX). See the Partitioning article.

システムパーティションの準備

LUKS コンテナの作成

Follow dm-crypt/Device encryption#Encrypting devices with LUKS mode to setup /dev/sdaX for LUKS. See the Dm-crypt/Device encryption#Encryption options for LUKS mode before doing so for a list of encryption options.

LUKS コンテナの解錠

Now follow Dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper to unlock the LUKS container and map it.

マッピングされたデバイスのフォーマット

Proceed to format the mapped device as described in Btrfs#File system on a single device, where /dev/partition is the name of the mapped device (i.e., cryptroot) and not /dev/sdaX.

マッピングされたデバイスのマウント

Finally, mount the now-formatted mapped device (i.e., /dev/mapper/cryptroot) to /mnt.

ヒント: You may want to use the compress=lzo mount option. See Btrfs#Compression for more information.

btrfs サブボリュームの作成

レイアウト

Subvolumes will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:

subvolid=5 (/dev/sdaX)
   |
   ├── @ (mounted as /)
   |       |
   |       ├── /bin (directory)
   |       |
   |       ├── /home (mounted @home subvolume)
   |       |
   |       ├── /usr (directory)
   |       |
   |       ├── /.snapshots (mounted @snapshots subvolume)
   |       |
   |       ├── /var/cache/pacman/pkg (nested subvolume)
   |       |
   |       ├── ... (other directories and nested subvolumes)
   |
   ├── @snapshots (mounted as /.snapshots)
   |
   ├── @home (mounted as /home)
   |
   └── @... (additional subvolumes you wish to use as mount points)

This section follows the Snapper#Suggested filesystem layout, which is most useful when used with Snapper. You should also consult Btrfs Wiki SysadminGuide#Layout.

トップレベルサブボリュームの作成

Here we are using the convention of prefixing @ to subvolume names that will be used as mount points, and @ will be the subvolume that is mounted as /.

Following the Btrfs#Creating a subvolume article, create subvolumes at /mnt/@, /mnt/@snapshots, and /mnt/@home.

Create any additional subvolumes you wish to use as mount points now.

トップレベルサブボリュームのマウント

Unmount the system partition at /mnt.

Now mount the newly created @ subvolume which will serve as / to /mnt using the subvol= mount option. Assuming the mapped device is named cryptroot, the command would look like:

# mount -o compress=lzo,subvol=@ /dev/mapper/cryptroot /mnt

See Btrfs#Mounting subvolumes for more details.

Also mount the other subvolumes to their respective mount points: @home to /mnt/home and @snapshots to /mnt/.snapshots.

ネストされたサブボリュームの作成

Create any subvolumes you do not want to have snapshots of when taking a snapshot of /. For example, you probably do not want to take snapshots of /var/cache/pacman/pkg. These subvolumes will be nested under the @ subvolume, but just as easily could have been created earlier at the same level as @ according to your preference.

Since the @ subvolume is mounted at /mnt you will need to create a subvolume at /mnt/var/cache/pacman/pkg for this example. You may have to create any parent directories first.

Other directories you may wish to do this with are /var/abs, /var/tmp, and /srv.

ESP のマウント

If you prepared an EFI system partition earlier, create its mount point and mount it now.

ノート: Btrfs snapshots will exclude /boot/efi, since it is not a btrfs file system.

At the pacstrap installation step, the btrfs-progs must be installed in addition to the base group.

mkinitcpio の設定

キーファイルの作成

In order for GRUB to open the LUKS partition without having the user enter his passphrase twice, we will use a keyfile embedded in the initramfs. Follow Dm-crypt/Device encryption#With a keyfile embedded in the initramfs making sure to add the key to /dev/sdaX at the luksAddKey step.

mkinitcpio.conf の編集

After creating, adding, and embedding the key as described above, add the encrypt hook to mkinitcpio.conf as well as any other hooks you require. See Dm-crypt/System configuration#mkinitcpio for detailed information. Be sure to regenerate the initial ramdisk when finished.

ヒント: You may want to add BINARIES="/usr/bin/btrfs" to your mkinitcpio.conf. See the Btrfs#Corruption recovery article.

ブートローダーの設定

Install GRUB to /dev/sda. Then, edit /etc/default/grub as instructed in the GRUB#Encryption article, following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file.

スワップの設定

If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at Dm-crypt/Swap encryption.

After completing this step, continue configuring your system as normal according to the installation guide.