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>
オプションや暗号化モードにはデフォルト値が存在し、コマンドラインで何も指定しなかった場合はデフォルト値が使われます。オプションや暗号化モードのデフォルトパラメータを確認するには以下のコマンドを実行:
$ cryptsetup --help
オプションの完全なリストは man ページで確認できます。暗号化モードやアクションによって必要なパラメータは変わるため、以下のセクションでは違いについて説明しています。ブロックデバイス暗号化は高速ですが、速度は非常に重要な問題です。ブロックデバイスの暗号を設定後に変更することは難しいため、それぞれのパラメータについて dm-crypt のパフォーマンスをチェックすると良いでしょう:
$ cryptsetup benchmark
上記のコマンドはインストールするときにアルゴリズムや鍵長を決める手がかりになります。特定の AES 暗号が非常に高速に処理される場合、おそらくその暗号は CPU によるハードウェア支援の恩恵に与かっています。
Cryptsetup のパスフレーズとキー
暗号化されたブロックデバイスはキーによって保護されます。キーは以下のいずれかです:
- パスフレーズ、ディスク暗号化#強固なパスフレーズの選択を見て下さい。
- キーファイル、#キーファイル を見て下さい。
どちらのタイプのキーも最大サイズが決められています: パスフレーズは512文字まで、キーファイルは 8192kB までです。
LUKS の重要な特徴として、キーは LUKS によって暗号化されたデバイスのマスターキーを解除するのに使われ、root 権限で変えることができるということです。他の暗号化モードでは設定後にキーを変更することはできません。暗号化にマスターキーを使わないためです。詳しくはディスク暗号化#ブロックデバイスの暗号化を見て下さい。
dm-crypt の暗号化オプション
Cryptsetup は dm-crypt で使用できる様々な暗号化モードをサポートしています。最も一般的な (デフォルトの) モードは:
--type LUKS
他に利用できるモードは:
--type plain- dm-crypt plain モードを使用。--type loopaes- loopaes legacy モードを使用。--type tcrypt- Truecrypt 互換モードを使用。
暗号やハッシュの基本的な暗号化オプションは全てのモードで使うことができ、カーネルの暗号化バックエンド機能を利用します。使用できるオプションは以下のコマンドで確認できます:
$ less /proc/crypto
リストが短い場合、cryptsetup benchmark を実行すればモジュールのロードが行われます。
以下では最初の2つのモードの暗号化オプションを紹介します。記事の中で例として使っているオプションを並べていますが、利用できるオプションの全てではないので注意してください。
LUKS モードの暗号化オプション
LUKS 暗号化モードで新しい dm-crypt デバイスをセットアップする cryptsetup のアクションは luksFormat です。名前にはフォーマットとありますが、実際にはデバイスをフォーマットするのではなく、LUKS デバイスヘッダーを設定して指定された暗号オプションを使ってマスター鍵を暗号化します。
LUKS はデフォルトの暗号化モードなので、デフォルトパラメータで新しい LUKS デバイスを作成する場合、以下のコマンドだけで作成できます (-v は任意です):
# cryptsetup -v luksFormat device
手動でデフォルトのオプションを全て指定すると以下のようになります:
# cryptsetup -v --cipher aes-xts-plain64 --key-size 256 --hash sha256 --iter-time 2000 --use-urandom --verify-passphrase luksFormat device
以下の表ではデフォルト値とサンプルにコメントを付けて説明しています:
| オプション | Cryptsetup (1.7.0) のデフォルト | 例 | コメント |
|---|---|---|---|
| --cipher, -c | aes-xts-plain64
|
aes-xts-plain64
|
例ではデフォルトと同じ暗号を使っています: AES 暗号と XTS。 |
| --key-size, -s | 256
|
512
|
デフォルトでは256ビットが使われます。ただし XTS はキーを半分に割るので、AES-128 ではなく AES-256 を使うには XTS のキーサイズを 512 に設定する必要があります。
|
| --hash, -h | sha256
|
sha512
|
PBKDF2 で使用されるハッシュアルゴリズム。リリース 1.7.0 でデフォルト設定が sha1 から sha256 に変更されました。セキュリティ上の理由ではなく SHA1 が使用できないシステムでも動作するようにするためです [1]。sha1 でも十分セキュアであるため古いバージョンの cryptsetup と互換性を維持する目的で使用できます [2]。
|
| --iter-time, -i | 2000
|
5000
|
Number of milliseconds to spend with PBKDF2 passphrase processing. Release 1.7.0 changed defaults from 1000 to 2000 to "try to keep PBKDF2 iteration count still high enough and also still acceptable for users."[3]. This option is only relevant for LUKS operations that set or change passphrases, such as luksFormat or luksAddKey. Specifying 0 as parameter selects the compiled-in default.
|
| --use-{u,}random | --use-urandom
|
--use-random
|
乱数生成器の選択。cryptsetup のマニュアルページより: "In a low-entropy situation (e.g. in an embedded system), both selections are problematic. Using /dev/urandom can lead to weak keys. Using /dev/random can block a long time, potentially forever, if not enough entropy can be harvested by the kernel." |
| --verify-passphrase, -y | Yes | - | Default only for luksFormat and luksAddKey. No need to type for Arch Linux with LUKS mode at the moment. |
LUKS の暗号機能について詳しく知りたい場合は LUKS specification (例: 付記) を読むと良いでしょう。
plain モードの暗号化オプション
dm-crypt の plain モードでは、デバイスのマスター鍵が存在せず、セットアップも必要ありません。代わりに、直接暗号化オプションを使用して暗号ディスクと名前付きデバイスのマッピングを作成します。パーティションやデバイス全体に対してマッピングを作成できます。後者の場合、パーティションテーブルも不要です。
cryptsetup のデフォルトパラメータを使って plain のマッピングを作成するには:
# cryptsetup <options> open --type plain <device> <dmname>
実行するとパスワードを求められます。以下は Dm-crypt/システム全体の暗号化#Plain dm-crypt の例とデフォルトパラメータの比較表です。
| オプション | Cryptsetup (1.7.0) のデフォルト | 例 | コメント | |
|---|---|---|---|---|
| --hash | ripemd160 |
- | パスフレーズからキーを作成するのに使用するハッシュ。キーファイルでは使われない。 | |
| --cipher | aes-cbc-essiv:sha256 |
twofish-xts-plain64 |
暗号は3つの文字列からなります: cipher-chainmode-IV generator。ディスク暗号化#暗号と利用形態や DMCrypt のドキュメント を見てください。 | |
| --key-size | 256 |
512 |
キーサイズ (ビット数)。サイズは使用する暗号や使用するチェインモードによって変わります。Xts モードは cbc モードの2倍のキーサイズを必要とします。 | |
| --offset | 0 |
0 |
マッピングを開始するディスクの先頭からのオフセット。 | |
| --key-file | デフォルトではパスフレーズを使用 | /dev/sdZ (もしくは /boot/keyfile.enc) |
キーとして使用するデバイスまたはファイル。詳しくは #キーファイル を参照。 | |
| --keyfile-offset | 0 |
0 |
キーファイルの先頭からのオフセット (バイト数)。cryptsetup 1.6.7 以上でサポートされているオプション。 | |
| --keyfile-size | 8192kB |
- (デフォルト) | キーファイルから読み込まれるバイト数を制限。cryptsetup 1.6.7 以上でサポートされているオプション。 |
/dev/sdX デバイスで、上記の例を使用する場合:
# cryptsetup --cipher=twofish-xts-plain64 --offset=0 --key-file=/dev/sdZ --key-size=512 open --type=plain /dev/sdX enc
LUKS による暗号化と違って、上記のコマンドはマッピングを再現するために毎回全て指定する必要があります。暗号やハッシュ、キーファイルについて覚えておく必要があります。マッピングが作成されたことは以下のコマンドで確認できます:
# fdisk -l
/dev/mapper/enc のエントリが存在しているはずです。
cryptsetup でデバイスを暗号化
以下のセクションでは新しい暗号化ブロックデバイスを作成するオプションと手動のアクセス方法を説明します。
LUKS モードでデバイスを暗号化
LUKS パーティションのフォーマット
暗号化 LUKS パーティションとして設定するには次を実行:
# cryptsetup luksFormat device
上記のコマンドを実行するとパスワードの入力が要求されます。
コマンドラインオプションは #LUKS モードの暗号化オプションを参照。
結果は次のコマンドで確認できます:
# cryptsetup luksDump device
ダンプでは暗号のヘッダー情報だけでなく、LUKS パーティションで使われるキースロットもわかります。
以下の例はデフォルトの AES 暗号を使って256ビットの XTS モードで /dev/sda1 に暗号化したルートパーティションを作成します:
# cryptsetup -s 512 luksFormat /dev/sda1
LUKS を使ってキーファイルでパーティションをフォーマット
LUKS による暗号化パーティションを新しく作成する場合、以下のように作成するときにパーティションにキーファイルを関連付けることができます:
# cryptsetup luksFormat device /path/to/mykeyfile
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.
キーファイルを作成・管理する方法は #キーファイル を見て下さい。
デバイスマッパーで LUKS パーティションのロックを解除・マップ
LUKS パーティションを作成したら、解錠することができます。
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that device is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/dm_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.
暗号化された LUKS パーティションを開くには次のコマンドを実行:
# cryptsetup open --type luks device dm_name
You will then be prompted for the password to unlock the partition. Usually the device mapped name is descriptive of the function of the partition that is mapped. For example the following unlocks a luks partition /dev/sda1 and maps it to device mapper named cryptroot:
# cryptsetup open --type luks /dev/sda1 cryptroot
Once opened, the root partition device address would be /dev/mapper/cryptroot instead of the partition (e.g. /dev/sda1).
For setting up LVM ontop the encryption layer the device file for the decrypted volume group would be anything like /dev/mapper/cryptroot instead of /dev/sda1. 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. For example:
# mkfs -t ext4 /dev/mapper/cryptroot
/dev/mapper/cryptroot デバイスは他のパーティションと同じようにマウントできます。
To close the luks container, unmount the partition and do:
# cryptsetup close cryptroot
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:
luksRemoveKeyis used to remove a key by specifying its passphrase/key-file.luksKillSlotmay 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.luksEraseis used to quickly remove all active keys.
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.
バックアップとリストア
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. 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.
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.
# 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>
cryptsetup を使ってリストア
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
デバイスの再暗号化
The cryptsetup package features the cryptsetup-reencrypt tool. It can be used to convert an existing unencrypted filesystem to a LUKS encrypted one (option --new) and permanently remove LUKS encryption (--decrypt) from a device. As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the #LUKS モードの暗号化オプション. cryptsetup-reencrypt actions can be performed to unmounted devices only. See cryptsetup-reencrypt(8) for more information.
One application of re-encryption may be to secure the data again after a passphrase or keyfile has been compromised and one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only (#Key management).
The following shows an example to encrypt an unencrypted filesystem partition and a re-encryption of an existing LUKS device.
暗号化されていないファイルシステムの暗号化
A LUKS encryption header is always stored at the beginning of the device. Since an existing filesystem will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.
The default LUKS header encryption cipher requires 4096 512-byte sectors. We already checked space and keep it simple by shrinking the existing ext4 filesystem on /dev/sdaX to its current possible minimum:
# umount /mnt
# e2fsck -f /dev/sdaX
e2fsck 1.43-WIP (18-May-2015) Pass 1: Checking inodes, blocks, and sizes ... /dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks
# resize2fs -M /dev/sdaX
resize2fs 1.43-WIP (18-May-2015) Resizing the filesystem on /dev/sdaX to 26347 (4k) blocks. The filesystem on /dev/sdaX is now 26347 (4k) blocks long.
Now we encrypt it, using the default cipher we do not have to specify it explicitly. Note there is no option (yet) to double-check the passphrase before encryption starts, be careful not to mistype:
# cryptsetup-reencrypt /dev/sdaX --new --reduce-device-size 4096S
WARNING: this is experimental code, it can completely break your data. Enter new passphrase: Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 37,6 MiB/s
After it finished, the encryption was performed to the full partition, i.e. not only the space the filesystem was shrunk to (sdaX has 2.6GiB and the CPU used in the example has no hardware AES instructions). As a final step we extend the filesystem of the now encrypted device again to occupy available space:
# cryptsetup open /dev/sdaX recrypt
Enter passphrase for /dev/sdaX: ...
# resize2fs /dev/mapper/recrypt
resize2fs 1.43-WIP (18-May-2015) Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks. The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.
# mount /dev/mapper/recrypt /mnt
and are done.
既存の LUKS パーティションの再暗号化
以下の例では既存の LUKS デバイスを最暗号化しています。
In order to re-encrypt a device with its existing encryption options, they do not need to be specified. A simple:
# cryptsetup-reencrypt /dev/sdaX
WARNING: this is experimental code, it can completely break your data. Enter passphrase for key slot 0: Progress: 100,0%, ETA 00:00, 2596 MiB written, speed 36,5 MiB/s
performs it.
A possible usecase is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned 4096 sectors:
# cryptsetup luksDump /dev/sdaX |grep -e "mode" -e "Payload" -e "MK bits"
Cipher mode: cbc-essiv:sha256 Payload offset: 2048 MK bits: 128
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the --reduce-device-size option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.
暗号化デバイスのリサイズ
If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space.
The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:
# cryptsetup luksOpen /dev/sdX2 sdX2 # cryptsetup resize sdX2
Then the underlying filesystem must be resized.
ループバックファイルシステム
暗号化したループバックデバイスを /mnt/secret にマウントしている場合、例えば Dm-crypt/root 以外のファイルシステムの暗号化#Loop デバイス に従っている場合、最初に暗号化コンテナをアンマウント:
# umount /mnt/secret # cryptsetup close secret # losetup -d /dev/loop0
次に、追加したいデータ容量を決めてコンテナファイルを拡張します:
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret
ループデバイスにコンテナをマップ:
# losetup /dev/loop0 /bigsecret # cryptsetup --type luks open /dev/loop0 secret
その後、コンテナの暗号化された部分をコンテナファイルの最大サイズまでリサイズ:
# cryptsetup resize secret
最後に、ファイルシステムのチェックを実行して、問題なければ、リサイズを行います (例: ext2/3/4):
# e2fsck -f /dev/mapper/secret # resize2fs /dev/mapper/secret
またコンテナをマウントすることができます:
# mount /dev/mapper/secret /mnt/secret
キーファイル
キーファイルとは？
キーファイルは暗号化されたボリュームを解錠するパスフレーズとして使用するデータを含んだファイルです。ファイルを喪失した場合、ボリュームの復号化は出来なくなります。
なぜキーファイルを使うのか？
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.
例: 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.
例: 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.
例: 画像, テキスト, 動画。
ランダムな文字列でキーファイルを作成
ファイルシステムにキーファイルを保存
キーファイルの中身とサイズは任意に決められます。
以下では dd を使って2048バイトのランダムなキーファイルを生成して、/etc/mykeyfile ファイルに保存します:
# dd bs=512 count=4 if=/dev/urandom of=/etc/mykeyfile
キーファイルを外部デバイスに保存する場合、出力先を適切なディレクトリに変更します:
# dd bs=512 count=4 if=/dev/urandom of=/media/usbstick/mykeyfile
保存されたキーファイルを完全に消去
物理的なストレージデバイスに一時的なキーファイルを保存する場合、削除するときは、以下のように完全に削除してください:
# shred --remove --zero mykeyfile
FAT や ext2 であれば上記で十分ですが、ジャーナリングファイルシステムやフラッシュメモリハードウェアの場合、ディスクの完全消去あるいはキーファイルのあるパーティションを削除することを強く推奨します。
tmpfs にキーファイルを保存
もしくは、tmpfs をマウントしてキーファイルを一時的に保存:
# 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 を設定
キーファイルのキースロットを LUKS ヘッダに追加:
# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile
Enter any LUKS passphrase: key slot 0 unlocked. Command successful.
キーファイルを使ってパーティションを手動でアンロック
LUKS デバイスをオープンするときに --key-file オプションを使ってください:
# cryptsetup open /dev/sda2 dm_name --key-file /etc/mykeyfile
起動時にロックを解除
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.
キーファイルを使って起動時に root パーティションのロックを解除
mkinitcpio を設定して必要なモジュールやファイルを記述して cryptkey カーネルパラメータを設定してキーファイルの場所を指定します。
2つの方法が存在します:
- 外部メディア (USB スティック) にキーファイルを保存
- initramfs にキーファイルを埋め込む
キーファイルを外部メディアに保存
mkinitcpio の設定
ドライブのファイルシステムを使うために /etc/mkinitcpio.conf にモジュールを追加してください (以下の例では vfat モジュール):
MODULES=(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. 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
カーネルパラメータの設定
以下のオプションをカーネルパラメータに追加してください (encrypt フックではなく sd-encrypt フックを使用する場合は Dm-crypt/システム設定#sd-encrypt フックを使うを参照):
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.
/dev/sdb1 のようなデバイスノードの名前は再起動しても同じであるとは保証されていません。udev による永続的なブロックデバイスの命名を使ったほうが確実にデバイスにアクセスできます。外部ストレージデバイスからキーファイルを読み取るときに encrypt フックが確実にキーファイルを見つけられるように、永続的なブロックデバイスの名前を絶対に使うべきです。永続的なブロックデバイスの命名を見て下さい。
キーファイルを initramfs に埋め込む
This method allows to use a specially named keyfile that will be embedded in the initramfs and picked up by the encrypt hook to unlock the root filesystem (cryptdevice) automatically. It may be useful to apply when using the GRUB early cryptodisk feature, in order to avoid entering two passphrases during boot.
The encrypt hook lets the user specify a keyfile with the cryptkey kernel parameter: in the case of initramfs, the syntax is rootfs:path, see Dm-crypt/システム設定#cryptkey. Besides, this kernel parameter defaults to use /crypto_keyfile.bin, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the cryptkey parameter.
encrypt の代わりに sd-encrypt を使用する場合、luks.key カーネルパラメータでキーファイルの場所を指定してください。Dm-crypt/システム設定#luks.key を参照。
キーファイルを生成して適切な権限を与えて LUKS キーとして追加:
# dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin # chmod 000 /crypto_keyfile.bin # chmod 600 /boot/initramfs-linux* # cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin
mkinitcpio の FILES にキーを記述:
/etc/mkinitcpio.conf
FILES=(/crypto_keyfile.bin)
最後に initramfs を再生成してください。
次の起動時からコンテナを復号化するパスフレーズを入力するのは一度だけですむようになります。
詳しくは こちら を参照。