dm-crypt/デバイスの暗号化

Dm-crypt に戻る。

このセクションではコマンドラインから dm-crypt を利用して手動でシステムを暗号化する方法を説明しています。

準備

cryptsetup を使用する前に、dm-crypt カーネルモジュールがロードされていることを確認してください。

Cryptsetup の使用方法

Cryptsetup は暗号化デバイスを作成・管理する dm-crypt を使うためのコマンドラインツールです。後に Linux カーネルの device-mapper と cryptographic モジュールを使用する別の暗号化もサポートするように拡張されました。最も著しい拡張は Linux Unified Key Setup (LUKS) の拡張で、dm-crypt をセットアップするのに必要な情報を全てディスク自体に保存してパーティションとキーの管理を抽象化することで使いやすさを増しています。device-mapper によってアクセスされるデバイスはブロックデバイスと呼ばれます。詳しくはディスク暗号化#ブロックデバイスの暗号化を見て下さい。

ツールは以下のように使います:

# cryptsetup <OPTIONS> <action> <action-specific-options> <device> <dmname>

It has compiled-in defaults for the options and the encryption mode, which will be used if no others are specified on the command line. Have a look at

$ cryptsetup --help 

which lists options, actions and the default parameters for the encryption modes in that order. A full list of options can be found on the man page. Since different parameters are required or optional, depending on encryption mode and action, the following sections point out differences further. Blockdevice encryption is fast, but speed matters a lot too. Since changing an encryption cipher of a blockdevice after setup is difficult, it is important to check dm-crypt performance for the individual parameters in advance:

$ cryptsetup benchmark 

can give guidance on deciding for an algorithm and key-size prior to installation. If certain AES ciphers excel with a considerable higher throughput, these are probably the ones with hardware support in the CPU.

ヒント: テストしたいときは仮想マシンの仮想ハードドライブで練習すると良いでしょう。

Cryptsetup のパスフレーズとキー

暗号化されたブロックデバイスはキーによって保護されます。キーは以下のいずれかです:

• パスフレーズ、ディスク暗号化#強固なパスフレーズの選択を見て下さい。
• キーファイル、#キーファイル を見て下さい。

どちらのタイプのキーも最大サイズが決められています: パスフレーズは512文字まで、キーファイルは 8192kB までです。

LUKS の重要な特徴として、キーは LUKS によって暗号化されたデバイスのマスターキーを解除するのに使われ、root 権限で変えることができるということです。他の暗号化モードでは設定後にキーを変更することはできません。暗号化にマスターキーを使わないためです。詳しくはディスク暗号化#ブロックデバイスの暗号化を見て下さい。

dm-crypt の暗号化オプション

Cryptsetup は dm-crypt で使用できる様々な暗号化モードをサポートしています。最も一般的な (デフォルトの) モードは:

• --type LUKS

他に利用できるモードは:

• --type plain for using dm-crypt plain mode,
• --type loopaes for a loopaes legacy mode, and
• --type tcrypt for a Truecrypt compatibility mode.

The basic cryptographic options for encryption cipher and hashes available can be used for all modes and rely on the kernel cryptographic backend features. All that are loaded at runtime can be viewed with

$ less /proc/crypto 

and are available to use as options. If the list is short, execute cryptsetup benchmark which will trigger loading available modules.

The following introduces encryption options for the first two modes. Note that the tables list options used in the respective examples in this article and not all available ones.

LUKS モードの暗号化オプション

The cryptsetup action to set up a new dm-crypt device in LUKS encryption mode is luksFormat. Unlike the name implies, it does not format the device, but sets up the LUKS device header and encrypts the master-key with the desired cryptographic options.

As LUKS is the default encryption mode:

# cryptsetup -v luksFormat <device>

is all needed to perform it with default parameters (-v optional). For comparison, we can specify the default options manually too:

# cryptsetup -v --cipher aes-xts-plain64 --key-size 256 --hash sha1 --iter-time 1000 --use-urandom --verify-passphrase luksFormat <device> 

These options used are compared below in the left column, with another set in the right column:

オプション	Cryptsetup (1.6.2) のデフォルト	例	コメント
--cipher, -c	aes-xts-plain64	aes-xts-plain64	例ではデフォルトと同じ暗号を使っています: AES 暗号と XTS。
--key-size, -s	256	512	By default a 256 bit key-size is used. Note however that XTS splits the supplied key in half. So to use AES-256 instead of AES-128 you would have to set the XTS key-size to 512.
--hash, -h	sha1	sha512	Hash algorithm used for PBKDF2. Due to this processing, SHA1 is considered adequate as of January 2014.
--iter-time, -i	1000	5000	Number of milliseconds to spend with PBKDF2 passphrase processing. Using a hash stronger than sha1 results in less iterations if iter-time is not increased.
--use-random	--use-urandom	--use-random	/dev/urandom is used as randomness source for the (long-term) volume master key. Avoid generating an insecure master key if low on entropy. The last three options only affect the encryption of the master key and not the disk operations.
--verify-passphrase, -y	Yes	-	Default only for luksFormat and luksAddKey. No need to type for Arch Linux with LUKS mode at the moment.

The options used in the example column result in the following:

# cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat <device>

Please note that with release 1.6.0, the defaults have changed to an AES cipher in XTS mode. It is advised against using the previous default --cipher aes-cbc-essiv, because of its known issues and practical attacks against them.

plain モードの暗号化オプション

In dm-crypt plain mode, there is no master-key on the device, hence, there is no need to set it up. Instead the encryption options to be employed are used directly to create the mapping between an encrypted disk and a named device. The mapping can be created against a partition or a full device. In the latter case not even a partition table is needed.

To create a plain mode mapping with cryptsetup's default parameters:

# cryptsetup <options> open --type plain <device> <dmname>

Executing it will prompt for a password, which should have very high entropy. Below a comparison of default parameters with the example in Dm-crypt/Encrypting an entire system#Plain dm-crypt

Option	Cryptsetup defaults (1.6.2)	Example	Comment
--hash	ripemd160	-	The hash is used to create the key from the passphrase; it is not used on a keyfile.
--cipher	aes-cbc-essiv:sha256	twofish-xts-plain64	The cipher consists of three parts: cipher-chainmode-IV generator. Please see Disk encryption#Ciphers and modes of operation for an explanation of these settings, and the DMCrypt documentation for some of the options available.
--key-size	256bits	512	The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode requires twice the key size of cbc.
--offset	0	0	The offset from the beginning of the target disk from which to start the mapping
--key-file	default uses a passphrase	/dev/sdZ (or e.g. /boot/keyfile.enc)	The device or file to be used as a key. See #Keyfiles for further details.
--keyfile-offset	0	0	Offset from the beginning of the file where the key starts (in bytes). This option is supported from cryptsetup 1.6.7 onwards.
--keyfile-size	8192kB	- (default applies)	Limits the bytes read from the key file. This option is supported from cryptsetup 1.6.7 onwards.

Using the device /dev/sdX, the above right column example results in:

# cryptsetup --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 that the mapping has been made:

# fdisk -l

An entry should now exist for /dev/mapper/enc.

cryptsetup でデバイスを暗号化

This section shows how to employ the options for creating new encrypted blockdevices and accessing them manually.

LUKS モードでデバイスを暗号化

LUKS パーティションのフォーマット

In order to setup a partition as an encrypted LUKS partition execute:

# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>

Enter passphrase: <password>
Verify passphrase: <password>

first to setup the encrypted master-key. Checking results can be done with:

# cryptsetup luksDump /dev/<drive>

This should be repeated for all partitions to be encrypted (except for /boot). You will note that the dump not only shows the cipher header information, but also the key-slots in use for the LUKS partition.

The following example will create an encrypted root partition using the default AES cipher in XTS mode with an effective 256-bit encryption

# cryptsetup -s 512 luksFormat /dev/sdaX

LUKS を使ってキーファイルでパーティションをフォーマット

When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:

# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> /path/to/mykeyfile

This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.

See #Keyfiles for instructions on how to generate and manage keyfiles.

デバイスマッパーで LUKS パーティションのロックを解除・マップ

Once the LUKS partitions have been created it is time to unlock them.

The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/<partition name> is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/<name> so as not to overwrite the encrypted data. To guard against accidental overwriting, read about the possibilities to backup the cryptheader after finishing setup.

In order to open an encrypted LUKS partition execute:

# cryptsetup open --type luks /dev/<partition name> <device-mapper name>

Enter any LUKS passphrase: <password>
key slot 0 unlocked.
Command successful.

Usually the device mapped name is descriptive of the function of the partition that is mapped, example:

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

Once opened, the root partition device address would be /dev/mapper/root instead of the partition (e.g. /dev/sdaX).

# cryptsetup open --type luks /dev/sda3 lvmpool 

For setting up LVM ontop the encryption layer the device file for the decrypted volume group would be anything like /dev/mapper/lvmpool instead of /dev/sdaX. LVM will then give additional names to all logical volumes created, e.g. /dev/mapper/lvmpool-root and /dev/mapper/lvmpool-swap.

In order to write encrypted data into the partition it must be accessed through the device mapped name. The first step of access will typically be to create a filesystem

# mkfs -t ext4 /dev/mapper/root

and mount it

# mount -t ext4 /dev/mapper/root /mnt

The mounted blockdevice can then be used like any other partition. Once done, closing the device locks it again

# umount /mnt
# cryptsetup close root

plain モードでデバイスを暗号化

The creation and subsequent access of a dm-crypt plain mode encryption both require not more than using the cryptsetup open action with correct parameters. The following shows that with two examples of non-root devices, but adds a quirk by stacking both (i.e. the second is created inside the first). Obviously, stacking the encryption doubles overhead. The usecase here is simply to illustrate another example of the cipher option usage.

A first mapper is created with cryptsetup's plain-mode defaults, as described in the table's left column above

# cryptsetup --type plain -v open /dev/sdaX plain1 
Enter passphrase: 
Command successful.
# 

Now we add the second blockdevice inside it, using different encryption parameters and with an (optional) offset, create a filesystem and mount it

# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10  open /dev/mapper/plain1 plain2
Enter passphrase: 
# lsblk -p   
NAME                                                     
/dev/sda                                     
├─/dev/sdaX          
│ └─/dev/mapper/plain1     
│   └─/dev/mapper/plain2              
...
# mkfs -t ext2 /dev/mapper/plain2
# mount -t ext2 /dev/mapper/plain2 /mnt
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt

We close the stack to check access works

# cryptsetup close plain2
# cryptsetup close plain1

First, let's try to open the filesystem directly:

# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sdaX plain2
# mount -t ext2 /dev/mapper/plain2 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/mapper/plain2,
      missing codepage or helper program, or other error

Why that did not work? Because the "plain2" starting block (10) is still encrypted with the cipher from "plain1". It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For dm-crypt plain mode, the open action will not error out itself.

Trying again in correct order:

# cryptsetup close plain2    # dysfunctional mapper from previous try
# cryptsetup --type plain open /dev/sdaX plain1
Enter passphrase: 
# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2 
Enter passphrase: 
# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt
This is stacked. one passphrase per foot to shoot.
# exit

dm-crypt will handle stacked encryption with some mixed modes too. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.

Available for plain mode only is the option --shared. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a loopaes compatible cipher mode for "plain2" this time:

# cryptsetup --type plain --offset 0 --size 1000 open /dev/sdaX plain1 
Enter passphrase: 
# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sdaX plain2
Enter passphrase: 
# lsblk -p
NAME                    
dev/sdaX                    
├─/dev/sdaX               
│ ├─/dev/mapper/plain1     
│ └─/dev/mapper/plain2     
...

As the devicetree shows both reside on the same level, i.e. are not stacked and "plain2" can be opened individually.

LUKS 固有の Cryptsetup のアクション

キーの管理

It is possible to define up to 8 different keys per LUKS partition. This enables the user to create access keys for save backup storage: In a so-called key escrow, one key is used for daily usage, another kept in escrow to gain access to the partition in case the daily passphrase is forgotten or a keyfile is lost/damaged. Also a different key-slot could be used to grant access to a partition to a user by issuing a second key and later revoking it again.

Once an encrypted partition has been created, the initial keyslot 0 is created (if no other was specified manually). Additional keyslots are numbered from 1 to 7. Which keyslots are used can be seen by issuing

# cryptsetup luksDump /dev/<device> |grep BLED

Key Slot 0: ENABLED
Key Slot 1: ENABLED
Key Slot 2: ENABLED
Key Slot 3: DISABLED
Key Slot 4: DISABLED
Key Slot 5: DISABLED
Key Slot 6: DISABLED
Key Slot 7: DISABLED

Where <device> is the volume containing the LUKS header. This and all the following commands in this section work on header backup files as well.

LUKS キーの追加

Adding new keyslots is accomplished using cryptsetup with the luksAddKey action. For safety it will always, i.e. also for already unlocked devices, ask for a valid existing key ("any passphrase") before a new one may be entered:

# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>) 
Enter any passphrase:
Enter new passphrase for key slot:
Verify passphrase: 

If /path/to/<additionalkeyfile> is given, cryptsetup will add a new keyslot for <additionalkeyfile>. Otherwise a new passphrase will be prompted for twice. For using an existing keyfile to authorize the action, the --key-file or -d option followed by the "old" <keyfile> will try to unlock all available keyfile keyslots:

# cryptsetup luksAddKey /dev/<device> (/path/to/<additionalkeyfile>) -d /path/to/<keyfile>

If it is intended to use multiple keys and change or revoke them, the --key-slot or -S option may be used to specify the slot:

# cryptsetup luksAddKey /dev/<device> -S 6 
Enter any passphrase: 
Enter new passphrase for key slot: 
Verify passphrase:
# cryptsetup luksDump /dev/sda8 |grep 'Slot 6'
Key Slot 6: ENABLED

To show an associated action in this example, we decide to change the key right away:

# cryptsetup luksChangeKey /dev/<device> -S 6 
Enter LUKS passphrase to be changed: 
Enter new LUKS passphrase: 

before continuing to remove it.

LUKS キーの削除

There are three different actions to remove keys from the header:

• luksRemoveKey is used to remove a key by specifying its passphrase/key-file.
• luksKillSlot may be used to remove a key from a specific key slot (using another key). Obviously, this is extremely useful if you have forgotten a passphrase, lost a key-file, or have no access to it.
• luksErase is used to quickly remove all active keys.

警告:

• All above actions can be used to irrevocably delete the last active key for an encrypted device!
• The luksErase command was added in version 1.6.4 to quickly nuke access to the device. This action will not prompt for a valid passphrase! It will not wipe the LUKS header, but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.

For above warning it is good to know the key we want to keep is valid. An easy check is to unlock the device with the -v option, which will specify which slot it occupies:

# cryptsetup -v open /dev/<device> testcrypt
Enter passphrase for /dev/<device>: 
Key slot 1 unlocked.
Command successful.

Now we can remove the key added in the previous subsection using its passphrase:

# cryptsetup luksRemoveKey /dev/<device>
Enter LUKS passphrase to be deleted: 

If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one.

Alternatively, we can specify the key slot:

# cryptsetup luksKillSlot /dev/<device> 6
Enter any remaining LUKS passphrase:

Note that in both cases, no confirmation was required.

# cryptsetup luksDump /dev/sda8 |grep 'Slot 6'
Key Slot 6: DISABLED

To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.

Backup and restore

If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much as a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. A damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table.

Therefore, having a backup of the header and storing it on another disk might be a good idea.

Attention: Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure! In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key used to encrypt all files on the partition. Of course this master key is encrypted with your passphrases or keyfiles. But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader! I.e. if someone obtains a copy of the cryptheader and one of your keys he can decrypt the master key and access all your data. Of course the same is true for all backups you create of partitions. So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not. See also the LUKS FAQ for further details on this.

cryptsetup を使ってバックアップ

Cryptsetup's luksHeaderBackup action stores a binary backup of the LUKS header and keyslot area:

# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /mnt/<backup>/<file>.img

where <device> is the partition containing the LUKS volume.

ヒント: You can also back up the plaintext header into ramfs and encrypt it in example with gpg before writing to persistent backup storage by executing the following commands.

# mkdir /root/<tmp>/
# mount ramfs /root/<tmp>/ -t ramfs
# cryptsetup luksHeaderBackup /dev/<device> --header-backup-file /root/<tmp>/<file>.img
# gpg2 --recipient <User ID> --encrypt /root/<tmp>/<file>.img 
# cp /root/<tmp>/<file>.img.gpg /mnt/<backup>/
# umount /root/<tmp>

警告: Tmpfs can swap to harddisk if low on memory so it is not recommended here.

cryptsetup を使ってリストア

警告: Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the correct one for that particular device.

In order to evade restoring a wrong header, you can ensure it does work by using it as a remote --header first:

# cryptsetup -v --header /mnt/<backup>/<file>.img open /dev/<device> test 
Key slot 0 unlocked.
Command successful.
# mount /dev/mapper/test /mnt/test && ls /mnt/test 
# umount /mnt/test 
# cryptsetup close test 

Now that the check succeeded, the restore may be performed:

# cryptsetup luksHeaderRestore /dev/<device> --header-backup-file ./mnt/<backup>/<file>.img

Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.

手動バックアップとリストア

The header always resides at the beginning of the device and a backup can be performed without access to cryptsetup as well. First you have to find out the payload offset of the crypted partition:

# cryptsetup luksDump /dev/<device> | grep "Payload offset"

 Payload offset:	4040

Second check the sector size of the drive

# fdisk -l /dev/<device> |grep "Sector size"

Sector size (logical/physical): 512 bytes / 512 bytes

Now that you know the values, you can backup the header with a simple dd command:

# dd if=/dev/<device> of=/path/to/<file>.img bs=512 count=4040

and store it safely.

A restore can then be performed using the same values as when backing up:

# dd if=./<file>.img of=/dev/<device> bs=512 count=4040

キーファイル

ノート: This section describes using a plaintext keyfile. If you want to encrypt your keyfile giving you two factor authentication see Using GPG or OpenSSL Encrypted Keyfiles for details, but please still read this section.

What is a keyfile?

A keyfile is any file in which the data contained within it is used as the passphrase to unlock an encrypted volume. Therefore if these files are lost or changed, decrypting the volume will no longer be possible.

ヒント: Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.

Why use a keyfile?

There are many kinds of keyfiles. Each type of keyfile used has benefits and disadvantages summarized below:

キーファイルのタイプ

passphrase

This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.

Example: 1234

randomtext

This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.

Example: fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-

binary

This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.

Example: images, text, video, ...

ランダムな文字列でキーファイルを作成

ファイルシステムにキーファイルを保存

キーファイルの中身とサイズは任意に決められます。

以下では dd を使って2048バイトのランダムなキーファイルを生成して、/etc/mykeyfile ファイルに保存します:

# dd bs=512 count=4 if=/dev/urandom of=/etc/mykeyfile iflag=fullblock

キーファイルを外部デバイスに保存する場合、出力先を適切なディレクトリに変更します:

# dd bs=512 count=4 if=/dev/urandom of=/media/usbstick/mykeyfile iflag=fullblock

保存されたキーファイルを完全に消去

If you stored your temporary keyfile on a physical storage device, and want to delete it, remember to not just remove the keyfile later on, but use something like

# shred --remove --zero mykeyfile

to securely overwrite it. For overaged filesystems like FAT or ext2 this will suffice while in the case of journaling filesystems, flash memory hardware and other cases it is highly recommended to wipe the entire device or at least the keyfiles partition.

tmpfs にキーファイルを保存

Alternatively, you can mount a tmpfs for storing the keyfile temporarily:

# mkdir mytmpfs
# mount tmpfs mytmpfs -t tmpfs -o size=32m
# cd mytmpfs

The advantage is that it resides in RAM and not on a physical disk, therefore it can not be recovered after unmounting the tmpfs. On the other hand this requires you to copy the keyfile to another filesystem you consider secure before unmounting.

キーファイルを使用するように LUKS を設定

Add a keyslot for the keyfile to the LUKS header:

# cryptsetup luksAddKey /dev/sda2 mykeyfile

Enter any LUKS passphrase:
key slot 0 unlocked.
Command successful.

起動時にロックを解除

If the keyfile for a secondary file system is itself stored inside an encrypted root, it is safe while the system is powered off but can be sourced to automatically unlock the mount during with boot via crypttab. Following above first example

/etc/crypttab

home    /dev/sda2     /etc/mykeyfile

is all needed for unlocking, and

/etc/fstab

/dev/mapper/home        /home   ext4        defaults        0       2

for mounting the LUKS blockdevice with the generated keyfile.

ヒント: If you prefer to use a --plain mode blockdevice, the encryption options necessary to unlock it are specified in /etc/crypttab. Take care to apply the systemd workaround mentioned in crypttab in this case.

キーファイルを使って起動時に root パーティションのロックを解除

The following method uses an USB-stick to store the keyfile and configures mkinitcpio to load the keyfile and unlock the root partition at boot.

mkinitcpio の設定

You have to add two extra modules in your /etc/mkinitcpio.conf, one for the drive's file system (vfat module in the example below) and one for the codepage (nls_cp437 module) :

MODULES="nls_cp437 vfat"

In this example it is assumed that you use a FAT formatted USB drive (vfat module). Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here. If it complains of bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need nls_iso8859-1 module for iso8859-1 codepage.

If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the keymap hook before encrypt.

Generate a new initramfs image:

# mkinitcpio -p linux

カーネルパラメータの設定

以下のオプションをカーネルパラメータに追加してください:

cryptdevice=/dev/<partition1>:root cryptkey=/dev/<partition2>:<fstype>:<path>

例:

cryptdevice=/dev/sda3:root cryptkey=/dev/sdb1:vfat:/keys/secretkey

Choosing a plain filename for your key provides a bit of 'security through obscurity'. The keyfile can not be a hidden file, that means the filename must not start with a dot, or the encrypt hook will fail to find the keyfile during the boot process.

The naming of device nodes like /dev/sdb1 is not guaranteed to stay the same across reboots. It is more reliable to access the device with udev's persistent block device naming instead. To assure that the encrypt hook finds your keyfile when reading it from an external storage device, persistent block device names must be used. See the article persistent block device naming.