dm-crypt/ドライブの準備

Dm-crypt に戻る。

ドライブを暗号化する前に、ドライブ全体をランダムデータで上書きしてディスクを完全に消去するべきです。暗号攻撃や、望ましくないファイルリカバリがされないように、後から dm-crypt によって書き込まれたデータと判別がつかないようにするのが理想的です。もっと細かい話はディスク暗号化#ディスクの準備を見て下さい。

ハードディスクドライブの完全消去

In deciding which method to use for secure erasure of a hard disk drive, remember that this needs only to be performed once for as long as the drive is used as an encrypted drive.

警告: Make appropriate backups of valuable data prior to starting.

ヒント: The process of filling an encrypted drive can take over a day to complete on a multi-terabyte disk. In order not to leave the machine unusable during the operation, it may be worth to do it from a system already installed on another drive, rather than from the live Arch installation system.

一般的な方法

ドライブを消去して準備する詳しい手順はディスクの完全消去を見て下さい。

dm-crypt 固有の方法

The following methods are specific for dm-crypt and are mentioned complementarily, because they are very fast and can be performed after a partition setup too.

The cryptsetup FAQ mentions a very simple procedure to use an existing dm-crypt-volume to wipe all free space accessible on the underlying block device with random data by acting as a simple pseudorandom number generator. It is also claimed to protect against disclosure of usage patterns.

インストール前に dm-crypt で消去

First, create a temporary encrypted container on the partition (sdXY) or the full disk (sdX) you want to encrypt, e.g. using default parameters

# cryptsetup open --type plain /dev/sdXY container

Second, check it exists

# fdisk -l

Disk /dev/mapper/container: 1000 MB, 1000277504 bytes
...
Disk /dev/mapper/container does not contain a valid partition table

Finally, wipe it with pseudorandom (encrypted data), a use of /dev/urandom is not required as the encryption cipher is used for randomness:

# dd if=/dev/zero of=/dev/mapper/container

dd: writing to ‘/dev/mapper/container’: No space left on device

ノート:

Regularly dd is used with a block size larger than default, for example bs=4M, to gain higher throughput. Using it with dm-crypt is detrimental, because it has the same default block size of 512 bytes and the command may exit before wiping the final blocks when a larger one is used.
For daily operation the performance loss of disk I/O operations with dm-crypt is not adversely affected by this. If the filesystem performs 4K operations, dm-crypt will process eight blocks at a time. It is important though that the underlying partition is aligned to disk geometry correctly when it is created.

次はパーティショニングです。

インストール後に dm-crypt で空き領域を消去

The same effect can be achieved if a file is created on an encrypted partition that fills the free space of the partition completely after the system is installed, booted and filesystems mounted. That is because encrypted data is practically indistinguishable from random.

# dd if=/dev/zero of=/file/in/container
# rm /file/in/container

The above process has to be repeated for every partition blockdevice created.

LUKS ヘッダーを消去

The partitions formatted with dm-crypt/LUKS contain a header with the cipher and crypt-options used, which is referred to dm-mod when opening the blockdevice. After the header the actual random data partition starts. Hence, when re-installing on an already randomised drive, or de-commissioning one (e.g. sale of PC, switch of drives, etc.) it may be just enough to wipe the header of the partition, rather than overwriting the whole drive - which can be a lengthy process.

Wiping the LUKS header will delete the PBKDF2-encrypted (AES) master key, salts and so on.

ノート: It is crucial to write to the LUKS encrypted partition (/dev/sda1 in this example) and not directly to the disks device node. If you did set up encryption as a device-mapper layer on top of others, e.g. LVM on LUKS on RAID then write to RAID respectively.

A header with one single default 256 bit size keyslot is 1024KB in size. It is advised to also overwrite the first 4KB written by dm-crypt, so 1028KB have to be wiped. That is 1052672 Byte.

For zero offset use:

#head -c 1052672 /dev/zero > /dev/sda1; sync

For 512 bit key length (e.g. for aes-xts-plain with 512 bit key) the header is 2MB.

If in doubt, just be generous and overwrite the first 10MB or so.

#dd if=/dev/zero of=/dev/sda1 bs=512 count=20480

ノート: With a backup-copy of the header data can get rescued but the filesystem was likely damaged as the first encrypted sectors were overwritten. See further sections on how to make a backup of the crucial header blocks.

When wiping the header with random data everything left on the device is encrypted data. An exception to this may occur for an SSD, because of cache blocks SSDs employ. In theory it may happen that the header was cached in these some time before and that copy may consequently be still available after wiping the original header. For strong security concerns, a secure ATA erase of the SSD should be done (procedure please see the cryptsetup FAQ 5.19).

パーティショニング

このセクションはシステム全体を暗号化する場合にのみあてはまります。ドライブを完全に上書きしたら、dm-crypt の要件を満たすように、慎重にパーティションスキームを決定する必要があります。ここで決めたことが結果的にシステムの管理に影響してきます。

ここからどんな場合でも /boot のパーティションは暗号化されていない状態にしておく必要があります。ブートローダーは /boot ディレクトリにアクセスする必要があり、システムをロードするために必要な initramfs や暗号化モジュールをロードします (詳しくは mkinitcpio を参照)。これがセキュリティ上問題となる場合、dm-crypt/特記事項#暗号化されていない boot パーティションのセキュア化を見て下さい。

また、スワップ領域やサスペンドをどうするかというのも大事な点です。dm-crypt/スワップの暗号化を見て下さい。

物理パーティション

In the simplest case, the encrypted layers can be based directly on the physical partitions; see パーティショニング for the methods to create them. Just like in an unencrypted system, a root partition is sufficient, besides another for /boot as noted above. This method allows deciding which partitions to encrypt and which to leave unencrypted, and works the same regardless of the number of disks involved. It will also be possible to add or remove partitions in the future, but resizing a partition will be limited by the size of the disk that is hosting it. Finally note that separate passphrases or keys are required to open each encrypted partition, even though this can be automated during boot using the crypttab file, see Dm-crypt/システム設定#crypttab.

スタックブロックデバイス

If more flexibility is needed, though, dm-crypt can coexist with other stacked block devices like LVM and RAID. The encrypted containers can either reside below or on top of other stacked block devices:

If the LVM/RAID devices are created on top of the encrypted layer, it will be possible to add, remove and resize the file systems of the same encrypted partition liberally, and only one key or passphrase will be required for all of them. Since the encrypted layer resides on a physical partition, though, it will not be possible to exploit the ability of LVM and RAID to span multiple disks.
If the encrypted layer is created on top of LVM/RAID devices, it will still be possible to reorganize the file systems in the future, but with added complexity, since the encryption layers will have to be adjusted accordingly. Moreover, separate passphrases or keys will be required to open each encrypted device. This, however, is the only choice for systems that need encrypted file systems to span multiple disks.

Btrfs のサブボリューム

Btrfs のサブボリューム機能を dm-crypt で使うこともできます。他のファイルシステムが必要ない場合 LVM を完全に置き換えることが可能です。ただし、スワップの暗号化はできないので注意してください。今のところ btrfs はスワップファイルをサポートしていません [1]。