dm-crypt/ドライブの準備

提供: ArchWiki
2016年10月13日 (木) 00:11時点におけるKusakata (トーク | 投稿記録)による版 (同期)
ナビゲーションに移動 検索に移動

Dm-crypt に戻る。

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

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

ハードディスクドライブを完全に消去する方法を決める際は、暗号化ドライブとしてハードドライブを使用するかぎり消去は一度で十分だということを覚えておいてください。

警告: 消去する前に重要なデータはバックアップしてください。
ノート: 大量のデータを消去する場合、完了するまで数時間から数日かかります。
ヒント:
  • 数テラバイトのディスクだと暗号化ドライブを作成するのに1日以上かかることもあります。消去している間、マシンが使えなくなってしまうのを避けるために、Arch のライブインストールメディアではなく他のドライブにインストールされた環境から消去するのも良いでしょう。
  • SSD の場合、フラッシュメモリのキャッシュが残らないようにするため、以下の方法よりも先にメモリセルの消去を試みることを推奨します。

一般的な方法

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

dm-crypt 固有の方法

The following two methods are specific for dm-crypt and are mentioned 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. That is because encrypted data is practically indistinguishable from random.

dm-crypt で空のディスクまたはパーティションを消去

まず、暗号化するパーティション (sdXY) やディスク (sdX) に一時的に暗号化コンテナを作成してください。デフォルトの暗号化パラメータを使用して --key-file /dev/{u}random オプションでランダムなキーを使う例 (乱数生成を参照):

# cryptsetup open --type plain /dev/sdXY container --key-file /dev/random

次に、コンテナが存在することを確認:

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

コンテナをゼロで埋めます。暗号が使われるため if=/dev/urandom の使用は必須ではありません。

# dd if=/dev/zero of=/dev/mapper/container status=progress
dd: writing to ‘/dev/mapper/container’: No space left on device
ヒント:
  • Using dd with the bs= option, e.g. bs=1M, is frequently used to increase disk throughput of the operation.
  • To perform a check of the operation, zero the partition before creating the wipe container. After the wipe command blockdev --getsize64 /dev/mapper/container can be used to get the exact container size as root. Now od can be used to spotcheck whether the wipe overwrote the zeroed sectors, e.g. od -j containersize - blocksize to view the wipe completed to the end.

最後に、一時コンテナを施錠:

# cryptsetup close container

システム全体を暗号化する場合、次はパーティショニングです。パーティションを暗号化する場合は dm-crypt/root 以外のファイルシステムの暗号化#パーティションに進んでください。

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

インストールする前にハードディスクを消去するのが面倒だという場合、暗号化したシステムを起動してファイルシステムがマウントされてから同じような操作をすることもできます。ただし、ファイルシステムの領域が root ユーザー、あるいはディスククォータなどによって限定されている場合、root ユーザーで操作しても一部のブロックデバイスに書き込みが行われずに消去が中途半端になる可能性があります。

消去を実行するには、暗号化コンテナの中にファイルを書き込むことでパーティションの空き領域を一時的に無くします:

# dd if=/dev/zero of=/file/in/container status=progress
dd: writing to ‘/file/in/container’: No space left on device

キャッシュをディスクに同期させてからファイルを消去することで空き領域が戻ります:

# sync
# rm /file/in/container

作成したパーティションのブロックデバイスとファイルシステムの数だけ上記の操作を繰り返す必要があります。例えば、LVM on LUKS のセットアップであれば、全ての論理ボリュームで消去を実行する必要があります。

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 randomized 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. Setups with encryption as a device-mapper layer on top of others, e.g. LVM on LUKS on RAID should 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/urandom > /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/urandom 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/スワップの暗号化を見て下さい。

物理パーティション

物理パーティションの上に暗号化レイヤーを直接配置するのが最も単純です。パーティションを作成する方法はパーティショニングを見てください。暗号化しない場合と同じく、/boot 以外はルートパーティションだけあれば十分です。暗号化するパーティションと暗号化しないパーティションを分けることができ、ディスクの数に関係なく等しく動作します。後からパーティションを追加・削除することもできますが、パーティションのサイズの変更はディスクの容量によって制限されます。各パーティションの暗号化を解除するために別々のパスフレーズや鍵が必要になりますが、crypttab ファイルを使うことで解錠は自動化できます。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]スワップが必要な場合は暗号化したスワップパーティションを作る必要があります。dm-crypt/システム全体の暗号化#Btrfs サブボリュームとスワップも参照。