dm-crypt/ドライブの準備

提供: ArchWiki
ナビゲーションに移動 検索に移動

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

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

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

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

一般的な方法

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

dm-crypt 固有の方法

以下の2つの方法はどちらも dm-crypt 専用の方法で、非常に高速な消去が可能でパーティションを設定した後でも実行できます。

cryptsetup FAQ には既存の dm-crypt ボリュームをシンプルな疑似乱数生成器として使って簡単にブロックデバイスの空き領域をランダムなデータで消去する方法が載っています。ランダムなデータで消去することで使用パターンが漏洩するのを防ぐことが可能です。暗号化されたデータはランダムなデータと基本的に見分けが付きません。

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
ヒント:
  • ディスクのスループットを向上させるために、dd を使うときはよく bs= オプションが使用されます。例: bs=1M
  • 操作のチェックを実行したい場合、コンテナを作成するまえにパーティションをゼロ埋めしてください。消去後、blockdev --getsize64 /dev/mapper/container を root で実行することでコンテナの正確なサイズを確認できます。消去が隅々まで行われたことを確認したい場合、od を使うことでゼロ埋めされたセクタが上書きされているか抽出検査できます。例: od -j containersize - blocksize

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

# 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 ヘッダーを消去

dm-crypt/LUKS でフォーマットしたパーティションには使用している暗号や暗号オプションが記載されたヘッダーが含まれており、ブロックデバイスを解錠するときに dm-mod から参照されます。ヘッダーの後にランダムなデータのパーティションが来ます。既にランダム化したドライブに再インストールするときやドライブを廃棄処分するときは (パソコンを売るときやディスクを交換するときなど)、わざわざディスク全体を上書きする必要はありません。パーティションのヘッダーを消去すれば十分です。

LUKS ヘッダーを消去すると PBKDF2 で暗号化された (AES) マスター鍵やソルトなども削除されます。

ノート: 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.

キースロットのサイズがデフォルトの256ビットのヘッダーなら、容量は 1024KB です。dm-crypt によって書き込まれる最初の 4KB も上書きすることが推奨されているため、合計で 1028KB だけ削除すれば良いことになります。バイトになおすと 1052672 です。

オフセットがゼロの場合、以下のコマンドでヘッダーを消去できます:

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

鍵長が512ビットの場合、ヘッダーは 2MB です (例: 512ビット鍵の aes-xts-plain)。

心配であれば、10MB ほど上書きしてしまえば安全です:

# 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.

ヘッダーをランダムデータで消去すると、後はデバイスに残っているのは暗号化されたデータだけになります。SSD の場合はキャッシュの存在があるため、完全には消去されない可能性があります。万一過去にヘッダーがキャッシュされた場合、ヘッダーを消去した後でもキャッシュからアクセスできる可能性が理論上排除できません。セキュリティを完全なものにしたい場合、SSD の Secure ATA Erase を実行すると良いでしょう (詳しくは cryptsetup の FAQ 5.19 を参照)。

パーティショニング

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

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

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

物理パーティション

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

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

もっと柔軟な構成にしたい場合、LVMRAID などのスタックブロックデバイスと dm-crypt を共存させることができます。暗号化したコンテナを他のスタックブロックデバイスの上あるいは下に配置することが可能です:

  • 暗号化レイヤーの上に LVM/RAID デバイスを作成した場合、文字通り同じ暗号化パーティションのファイルシステムを追加・削除・リサイズすることが可能になります。そしてファイルシステムに必要な鍵やパスフレーズはひとつだけで足ります。物理パーティション上に存在するのは暗号化レイヤーになるため、LVM や RAID を悪用してデータを盗み出すことは不可能です。
  • LVM/RAID デバイスの上に暗号化レイヤーを作成した場合、後でファイルシステムを再構築することができますが、暗号化レイヤーも下のデバイスにあわせて変更しなければならなくなるため、複雑性が増します。さらに、暗号化デバイスそれぞれに別々のパスフレーズや鍵が必要になります。しかしながら、複数のデバイスにまたがるように暗号化ファイルシステムを作成したい場合は唯一の選択となります。

Btrfs のサブボリューム

Btrfsサブボリューム機能を dm-crypt で使うこともできます。他のファイルシステムが必要ない場合 LVM を完全に置き換えることが可能です。今のところ btrfs はスワップファイルをサポートしていないため [1]スワップが必要な場合は暗号化したスワップパーティションを作る必要があります。dm-crypt/システム全体の暗号化#Btrfs サブボリュームとスワップも参照。