「保存データ暗号化」の版間の差分

2024年6月8日 (土) 13:50時点における最新版

この記事では、ブロックデバイスやディスクパーティション、ディレクトリに書き込んだり読み込んだりするデータをその場で暗号化/復号化する、保存データ暗号化ソフトウェアについて説明します。ブロックデバイスの例としては、ハードディスク、フラッシュドライブ、DVDなどがあります。

保存データの暗号化は、あくまでもオペレーティングシステムの既存のセキュリティ機構を補助するものと考えるべきで、物理的なアクセスの保護に焦点を当て、ネットワークセキュリティやユーザーベースのアクセスコントロールなどは、システムの他の部分に依存することになります。

フルディスク暗号化 (FDE) については、dm-crypt/システム全体の暗号化を参照してください。

なぜ暗号化を使うのか?

ディスク暗号化は確実にファイルを常に暗号化された状態でディスクに保存することができます。ファイルにアクセスできるのは、システムが動いていて信頼されたユーザーによってロックを解除された間だけで、その場合にのみオペレーティングシステムやアプリケーションは読み取れる状態でファイルにアクセスすることができるようになります。権限のないユーザーが直接ディスクの中身を見たとしても、わかるのは意味がわからないランダムなデータだけで、実際のファイルを読み取ることは不可能です。

ディスク暗号化によって、例えば、コンピュータやハードディスクが以下の状態にあるときにデータを勝手に見られることを防げます:

あなたの離席中に、他の信頼されない人々がアクセスすることができる場所に置かれている場合。
ノートパソコンやネットブック、または外付けのストレージデバイスなどのように紛失したり盗まれた場合。
修理に出している間。
寿命が尽きて廃棄した時。

さらに、ディスク暗号化を使うことで、オペレーティングシステムを改竄しようとする不正アクセスに対するセキュリティの強化にもなります。例えば、システムへの物理的なアクセスを手に入れた攻撃者によるキーロガーやトロイの木馬のインストールへの防衛手段になります。

警告: ディスク暗号化はあらゆる脅威からデータを保護するわけではないので注意してください。

ディスク暗号化によっても以下のような場合には対処できません:

システムが動いていて、あなたがロックを解除してディスクの暗号化している部分をマウントしてしまった後に (インターネットなどを介して) 攻撃者がシステムに侵入した場合。
コールドブートアタックに必要な手段を攻撃者が手に入れていて、(画面ロックを使っていたとしても) コンピュータが動作している、または動作していたすぐ後に攻撃者が物理的にアクセスできる場合。
政府機関が、上記の攻撃を簡単に行える資力を持っているだけでなく、もっとシンプルに、様々な強制執行を使って無理矢理キーやパスフレーズを明かさせることができる場合。世界中の非民主的な国々、さらにアメリカやイギリスでも、何か興味深いものをあなたが隠していると法執行機関が疑いをかけた場合、法執行機関によってロックの解除を合法的に迫られる可能性があります。
締め上げ暗号分析 XKCD #538 も参照してください。

ディスク暗号化をしたとしてもディスクの消去からは保護されません。データを安全に保つため定期的なバックアップを推奨します。

あなたがシステムを使う前にシステムに細工を施すことができるプロの攻撃者にまともに対抗するには非常に強固なディスク暗号化が必要になります (例: 平文のブートパーティションがなく真正の確認があるフルシステム暗号化)。それでもあらゆるタイプの改竄を押しとどめることができるかというと疑問です (例: ハードウェアキーロガー) おそらくハードウェアベースの完全ディスク暗号化とトラステッドコンピューティングが最善策でしょう。

システムデータ暗号化

データ暗号化は、ユーザーのデータ (/home ディレクトリの中や、データ DVD などのリムーバブルメディア) だけの暗号化と定義され、一番シンプルで込み入ったところがないディスク暗号化の利用法ですが、致命的な欠点があります。

最近の計算システムでは、ユーザーデータに関する情報や、またはデータそれ自体の一部を以下のようなハードドライブの暗号化されていない領域にキャッシュ・保存するバックグラウンドプロセスが多数存在します:

スワップパーティション
- (救済策: スワップを無効にする、またはスワップも暗号化してしまう)
/tmp (ユーザーアプリケーションによって作成される一時ファイル)
- (救済策: そのようなアプリケーションを使うのをやめる、または /tmp を RAM ディスクにマウントする)
/var (ログファイルやデータベースなど。例えば mlocate は全てのファイル名のインデックスを /var/lib/mlocate/mlocate.db に保存します)

さらに、データ暗号化だけではオフラインのシステムのタンパリング攻撃にたいして隙を残すことになります (例: 暗号化されたデータを解除するために使用するパスフレーズを記録するプログラムや、ロックを解除するのを待ってから密かに攻撃者がデータを回収できる場所にデータをコピー/送信するプログラムのインストール)。

利用可能な手段

あらゆるディスク暗号化の手段というのは、ディスクは暗号化されたデータを保持しながら、暗号コンテナ (つまり暗号化されたデータを保持するディスクの論理部) が"解除"されてマウントされているときにかぎり、オペレーティングシステムやアプリケーションからは通常の読み込み可能なデータとして見えるようにするという方法で働きます。

暗号化を使うには、ユーザーによって"秘密情報"が供給される必要があり (通常はキーファイルやパスフレーズの形で指定します)、それから実際の暗号化キーが生成されます (そしてセッションの間はカーネルのキーリングに保存されます)。

この種の仕組みが全くわからないという場合は、下の暗号化の仕組みセクションを読んで下さい。

利用できるディスク暗号化の方法は、稼働するレイヤーによって2つのタイプに分けることができます:

スタックファイルシステムの暗号化

スタックファイルシステムによる暗号化ソリューションは既存のファイルシステム上に積み上げられるレイヤーとして実装され、暗号化が有効になったフォルダへ書き込まれた全てのファイルを、実際のファイルシステムがディスクに書き込む前に即座に暗号化します。そしてファイルシステムがディスクからファイルを読み込んだ時は復号化を行います。この方法では、ホストファイルシステムには暗号化された形でファイルが保存されますが (ファイルの中身や、ファイル名・フォルダ名も、同じ長さのランダムなデータで置き換えられます)、それ以外のファイルはファイルシステム上に通常のファイル/シンボリックリンク/ハードリンクとして暗号化されない形で存在します。

ホストファイルシステムにある暗号化されたファイルが保存されたフォルダをロック解除するため、(特殊なスタック擬似ファイルシステムを使って) それ自体または別の場所にマウントされ、同じファイルが読み込める形で現れます。アンマウントしたり、システムの電源が落とされるまでその状態は維持されます。

スタックファイルシステム暗号化で利用できるソリューションには eCryptfs や EncFS があります。

クラウドストレージの最適化

クラウドストレージサービスなど、サードパーティが管理する場所とのゼロ知識同期を実現するためにスタックファイルシステムの暗号化を導入している場合は、eCryptfs や EncFS の代替手段を検討することをお勧めします。これらは、インターネットを介したファイルの送信用に最適化されていないためです。代わりに、この目的のために設計されたソリューションがいくつかあります。

gocryptfs
cryptomator^AUR もしくは cryptomator-bin^AUR (マルチプラットフォーム)
cryfs

一部のクラウドストレージサービスは、独自のサービスを通じてゼロ知識暗号化を直接提供していることに注意してください。クライアントアプリケーション

ブロックデバイスの暗号化

一方、ブロックデバイス暗号化はファイルシステムレイヤーの下で動作して、特定のブロックデバイス (つまり、ディスクやパーティション全体、または仮想的なループバックデバイスとして振る舞うファイル) に書き込まれる全てのデータが暗号化されます。このため、ブロックデバイスがオフラインのときは、中身が全てランダムなデータの巨大なブロブのように見え、ファイルシステムやデータに何が含まれているのか判断できなくなります。データにまたアクセスするときは、保護されたコンテナ (この場合、ブロックデバイス) を特殊な方法で任意の場所にマウントします。

Arch Linux では"ブロックデバイス暗号化"として以下の方法が利用できます:

loop-AES: loop-AES は cryptoloop の後継で、システム暗号化のためのセキュアで高速なソリューションです。ただし、標準にないカーネルのサポートが必要になるため loop-AES は他の選択肢と比べてユーザーフレンドリーとは言い難いかもしれません。

dm-crypt

dm-crypt は Linux カーネルによって提供されている標準の device-mapper 暗号化機能です。直接使うことでパーティションやキーの管理のあらゆることを完全にコントロールすることができます。dm-crypt の管理はユーザースペースユーティリティの cryptsetup を使って行います。次のタイプのブロックデバイス暗号化に使用することが可能です: LUKS (デフォルト), plain, そして機能制限がありますが loopAES と Truecrypt デバイス。

デフォルトで使用される LUKS は dm-crypt をセットアップするのに必要な情報を全てディスクに保存する便利なレイヤーで、使いやすさと暗号のセキュリティを増すためにパーティションとキー管理を抽象化します。
plain dm-crypt モードは、オリジナルのカーネルの機能であり、便利なレイヤーを使いません。レイヤーを使った時と同じ暗号強度を確保するのは難しくなります。そうしようとすると、結果的にキー (パスフレーズまたはキーファイル) が長くなってしまいます。しかしながら、下で説明しているように利点も存在します。

TrueCrypt: TrueCrypt の開発者は2014年5月にサポートを終了しています。それ以降脆弱性が修正されていないため、使用してはなりません。

VeraCrypt: TureCryptの後継です。

選択するレイヤーの実用性については、下の比較表を見て下さい。eCryptfs についての記事も参照。

ブロックデバイスとスタックファイルシステムの暗号化

特徴	デバイスの暗号化をブロックする	スタックされたファイルシステムの暗号化
暗号化	ブロック全体のデバイス	ファイル
暗号化されたデータのコンテナは次の可能性があります...	ループデバイスとしてのディスクまたはディスクパーティション/ファイル	既存のファイルシステム内のディレクトリ
ファイルシステムとの関係	ファイルシステム層の下で動作します。暗号化されたブロックデバイスの内容がファイルシステム、パーティションテーブル、LVM セットアップ、またはその他のものであるかどうかは関係ありません。	既存のファイルシステムに追加のレイヤーを追加し、ファイルの書き込み/読み取りのたびに自動的にファイルを暗号化/復号化します。
ファイルのメタデータ (ファイル数、ディレクトリ構造、ファイルサイズ、権限、mtimes など) は暗号化されます。	Yes	No (ファイル名とディレクトリ名は暗号化できます)
ハードドライブ全体 (パーティションテーブルを含む) をカスタム暗号化するために使用できます。	Yes	No
スワップスペースの暗号化に使用可能	Yes	No
暗号化されたデータコンテナ用に固定量のスペースを事前に割り当てずに使用可能	No	Yes
NFS や Samba 共有、クラウドストレージなど、デバイスアクセスをブロックせずに既存のファイルシステムを保護するために使用できます。	No	Yes
暗号化されたファイルのファイルベースのオフラインバックアップが可能	No	Yes

比較表

"dm-crypt +/- LUKS" のカラムは LUKS ("+") と plain ("-") 両方の暗号化モードにおける dm-crypt の機能を示しています。特定の機能が LUKS の使用を必要とする場合、そのことは "(LUKS を使用)" で表されます。同じように "(LUKS を使用しない)" はその機能を実現するのに LUKS の使用が逆効果であり、plain モードを使うべきことを示しています。

概要			Loop-AES	dm-crypt +/- LUKS	TrueCrypt	VeraCrypt	eCryptfs	EncFs
	タイプ		ブロックデバイスの暗号化				スタックファイルシステムの暗号化
	主なセールスポイント		最古の手段であり、おそらく最速であり、レガシーなシステムでも動作します	Linux におけるブロックデバイス暗号化のデファクトスタンダードであり柔軟性があります	携帯性が高く、洗練された、自己完結型の暗号化ソリューション	活発に開発されている TrueCrypt のフォークで、デファクトスタンダードの代替	EncFS よりも若干高速で、暗号化されたファイルは個別にシステム間で移動できます	一番使うのが簡単で、root 以外による管理をサポートしています
	Arch Linux における利用手段		カスタムカーネルの手動コンパイルが必須	カーネルモジュール: デフォルトのカーネルに含まれています; ツール: device-mapper, cryptsetup [core]	truecrypt [extra] (開発終了) または後方互換のある veracrypt [community]	veracrypt [community]	カーネルモジュール: デフォルトのカーネルに含まれています; ツール: ecryptfs-utils [community]	encfs [community]
	ライセンス		GPL	GPL	TrueCrypt License 3.1^[1]	Apache License 2.0, 一部はTrueCrypt License v3.0^[1]	GPL	GPL

基本的な分類			Loop-AES	dm-crypt +/- LUKS	TrueCrypt	VeraCrypt	eCryptfs	EncFs
	暗号化の対象		ブロックデバイス全体				ファイル
	暗号化されたデータのコンテナ		ディスクまたはディスクパーティション仮想パーティションとして作用するファイル				既存のファイルシステムのディレクトリ
	ファイルシステムとの関係		ファイルシステムレイヤーの下で動作し、暗号化されたブロックデバイスの中身がファイルシステム、パーティションテーブル、LVM のどれであるかには関しない				既存のファイルシステムにレイヤーを追加して、ファイルが書き込まれたり読み込まれた時に自動的に暗号化または復号化を行う
	暗号化の実装空間		カーネル空間					ユーザー空間 (FUSE を使用)
	暗号メタデータの保存場所		?	LUKS を使用: LUKS ヘッダー	(復号化された) デバイスの冒頭/最後 (フォーマット)		暗号化されたファイルのヘッダー	EncFs コンテナのトップレベルにあるコントロールファイル
	暗号鍵の保存場所		?	LUKS を使用: LUKS ヘッダー	(復号化された) デバイスの冒頭/最後 (フォーマット)		何処にでも保存できるキーファイル

実用性			Loop-AES	dm-crypt +/- LUKS	TrueCrypt	VeraCrypt	eCryptfs	EncFs
	ファイルのメタデータ (ファイルの数, ディレクトリ構造, ファイルサイズ, パーミッション, 更新時刻など) の暗号化		✔				✖ (ファイルやディレクトリの名前は暗号化できます)
	(パーティションテーブルを含む) ハードドライブ全体の暗号化		✔				✖
	スワップ領域の暗号化		✔				✖
	あらかじめ特定のサイズのスペースを暗号化データコンテナに割り当てなくても使用できるか		✖				✔
	ブロックデバイスにアクセスできない既存のファイルシステム (NFS や Samba の共有、クラウドストレージなど) の保護に使用できるか		✖^[2]				✔
	暗号化されたファイルのファイルベースのオフラインバックアップ		✖				✔

ユーザビリティ			Loop-AES	dm-crypt +/- LUKS	TrueCrypt	VeraCrypt	eCryptfs	EncFs
	ログイン時の自動マウントのサポート		?	✔	✔	✔	✔	✔
	アイドル状態による自動アンマウントのサポート		?	?	?	?	?	✔
	root 以外のユーザーによる暗号化されたデータのコンテナの作成と破壊		✖	✖	✖	✖	制限あり	✔
	GUI		✖	✖	✔	✔	✖	✔

セキュリティ			Loop-AES	dm-crypt +/- LUKS	TrueCrypt	VeraCrypt	eCryptfs	EncFs
	サポートされている暗号		AES	AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish, ... (カーネルの Crypto API が用意している全ての暗号)	AES, Twofish, Serpent	AES, Twofish, Serpernt, Camellia, Kuznyechik	AES, Blowfish, Twofish...	AES, Blowfish, Twofish, その他システムで使える暗号
	ソルティングのサポート		?	✔ (LUKS を使用)	✔	✔	✔	?
	複数の暗号による多段処理のサポート		?	複数のブロックデバイスを段階的に暗号化することは可能	✔	✔	?	✖
	キースロットの拡散のサポート		?	✔ (LUKS を使用)	?	?	?	?
	キースクラブに対する保護		✔	✔ (LUKS を使用しない)	?	?	?	?
	同一の暗号化されたデータに対して複数のキー (別個に無効にできる) のサポート		?	✔ (LUKS を使用)	?	?	?	✖

パフォーマンス			Loop-AES	dm-crypt +/- LUKS	TrueCrypt	VeraCrypt	eCryptfs	EncFs
	マルチスレッドのサポート		?	✔^[8]	✔	✔	?	?
	ハードウェア支援暗号化のサポート		✔	✔	✔	✔	✔	✔^[13]

ブロックデバイス暗号化特有の事項			Loop-AES	dm-crypt +/- LUKS	TrueCrypt	VeraCrypt
	所定の暗号化済みのブロックデバイスを (手動で) リサイズすることのサポート		?	✔	✖	✖

スタックファイルシステム暗号化特有の事項							eCryptfs	EncFs
	サポートされるファイルシステム						ext3, ext4, xfs (注意事項あり), jfs, nfs...	ext3, ext4, xfs (with caveats), jfs, nfs, cifs...[1]
	ファイル名の暗号化						✔	✔
	ファイル名の暗号化をしない機能						✔	✔
	スパースファイルの最適化処理						✖	✔

互換性と普及度			Loop-AES	dm-crypt +/- LUKS	TrueCrypt	VeraCrypt	eCryptfs	EncFs
	サポートされる Linux カーネルバージョン		2.0 以上	CBC モード 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24	?	?	?	2.4 以上
	暗号化されたデータにアクセスできるオペレーティングシステム	Windows	✔^[3]	?^[4]	✔	✔	?	✔^[9]
		macOS	?	?	✔	✔	?	✔^[5]
		FreeBSD	?	?	✔ (VeraCrypt を使用)	✔	?	✔^[6]
	使用しているディストリビューション		?	Debian/Ubuntu インストーラ (システム暗号化) Fedora インストーラ	?	?	Ubuntu インストーラ (ホームディレクトリの暗号化) Chromium OS (キャッシュされたユーザーデータの暗号化^[7])	?

準備

セットアップの選択

どのディスク暗号化をセットアップするのが適切なのかはあなたの目的 (上の #なぜ暗号化を使うのか? を読んで下さい) とシステムパラメータによって様々です。
とりわけ、以下の質問に答える必要があるでしょう:

あなたが身を守りたいのはどのような"攻撃者"からか?
- システムの電源がオフになっていたり盗まれたりしたときにディスクを詮索するカジュアルなコンピュータユーザー
- あなたがシステムを使用する前後に繰り返しシステムに読み書きアクセスをすることができるプロの暗号解読者
- その中間

どの暗号化ストラテジーを使用するのか?
- データ暗号化
- システム暗号化
- その中間

スワップや /tmp などはどうすればいいか?
- 無視する、データが流出しないことを祈る
- 無効化する、または ramdisk としてマウント
- 暗号化する (完全なディスク暗号化の一部として、または別個に暗号化)

どうやってディスクの暗号化された部分を解除するか?
- パスフレーズ (ログインパスワードと同じパスワード、または別個のパスワード)
- キーファイル (例: 安全な場所に置いたり常に持ち歩いている USB スティックに保存)
- 両方

ディスクの暗号化された部分を解除するのはいつか?
- 起動する前
- 起動中
- ログイン時
- (ログイン後に) 必要に応じて手動で

複数のユーザーに便宜をはかるにはどうすればいいか?
- 気にしない
- パスフレーズ/キーを共有する
- ディスクの同一の暗号化部分に対して別個に発行・無効化できるパスフレーズ/キーを使う
- ユーザーごとにディスクの暗号化部分を分ける

さらに技術的な選択をする必要があります (上の #利用可能な手段や、下の #暗号化の仕組みを参照):

スタックファイルシステムの暗号化 vs. ブロックデバイスの暗号化
キーの管理
暗号と利用モード
メタデータの保管
"下位ディレクトリ"の場所 (スタックファイルシステムの暗号化を使う場合)

実際にやってみると、以下のような取り合わせが考えられると思われます:

例 1: EncFS を使ってユーザーのホームディレクトリに "~/Private" という仮想フォルダを作って暗号化する、シンプルなデータ暗号化 (内蔵ハードドライブ)
└──> ~/.Private のファイルは暗号化されてディスク上に保存されます
└──> 必要に応じて専用のパスフレーズでロックを解除します

例 2: TrueCrypt で暗号化した USB ドライブによる、シンプルなデータ暗号化 (リムーバブルメディア)
└──> コンピュータに接続したときにロックを解除します (専用のパスフレーズと、キーファイルを変換した ~/photos/2006-09-04a.jpg を使用)

例 3: ECryptfs でそれぞれのユーザーのホームディレクトリを暗号化する、部分的なシステム暗号化
└──> 各々のユーザーのログイン時に、ログインパスフレーズを使ってロックを解除します
└──> スワップと /tmp パーティションは Dm-crypt と LUKS で暗号化して、セッションごとに自動生成される使い捨てのキーを使用
└──> slocate (やその他のアプリ) による /home の中身のインデックス作成/キャッシュは無効にする

例 4: システム暗号化 - /boot パーティションを除いてハードドライブ全体を Dm-crypt と LUKS で暗号化
└──> 起動中に、パスフレーズまたはキーファイルが保存された USB スティックを使ってロックを解除します
└──> ユーザーごとに別々のパスフレーズ/キーを使用 - 別個に無効化可能
└──> LUKS を LVM 上に配置して複数のドライブを跨ったりするパーティションレイアウトにおける暗号化の柔軟性を確保

例 5: 徹底して隠されたシステム暗号化 - plain dm-crypt によるハードドライブ全体の暗号化
└──> 専用のパスフレーズとキーファイルが入った USB スティックを使用して USB ブート
└──> マウントする前にデータの状態をチェックします
└──> /boot パーティションは先の USB スティック上に配置

もちろん他にも様々な組み合わせが考えられます。あなたのシステムにとってどのようなセットアップが適切か注意深く計画を練って下さい。

強固なパスフレーズの選択

セキュリティ#パスワードを見てください。

ディスクの準備

ディスク (の一部) に暗号化をセットアップする前に、まず確実にディスクを消去するようにしてください。ディスクを消去する際にはドライブ全体またはパーティション全体をゼロバイトやランダムなバイトのストリームで上書きします。これを行う理由は以下の通り:

以前に保存されていたデータのリカバリを防ぐ

たとえディスクを暗号化したとしても、実際のセクタは必要に応じて、ファイルシステムが特定のセクタにデータを作成したり修正したときにしか上書きされることはありません (下の #暗号化の仕組みを参照)。ファイルシステムから"使用されていない"セクタは弄られることがないため、前に使っていたファイルシステムのデータが残ってしまっている可能性があります。先にドライブに保存していたデータを完全にリカバリ不可能にするには、手動でデータを消去するしか道はないでしょう。
データを完全に消去するということについては、ゼロバイトを使用するかランダムバイトを使用するかの違いはありません (ゼロバイトで消去するほうが高速です)。
暗号化されたドライブの利用状況の発覚を防ぐ

理想を言えば、ディスクの暗号化部分はランダムなデータと区別を付かないようにするほうが望ましいでしょう。暗号化データを含んでいるセクタの数を知ることができなくなるということ自体が (完全な機密性を確保する上で) 好ましいですし、暗号化を解除しようと試みる攻撃者に対してセキュリティを増すことにもつながります。
利用状況の発覚を防ぐということに関しては、高品質なランダムバイトを使用してディスクを消去するのが重要です。

二番目の理由はブロックデバイスの暗号化をしている場合にのみ意味をなします。スタックファイルシステムの暗号化では簡単に暗号化データを突き止められてしまいます (ホストファイルシステムに暗号化されたファイルがあることは隠しようがありません)。また、たとえ特定のフォルダだけを暗号化したいという場合でも、暗号化されてない状態でフォルダに保存されていたファイルを削除するためには (断片化している可能性があるため) パーティション全体を消去する必要があります。同一パーティションに別のフォルダが存在する場合、一度バックアップして、削除してから元のパーティションに戻すようにします。

ディスク消去することを決めたら、ディスクの完全消去の記事を参照してください。

ヒント: ハードディスクドライブを完全に消去する方法を決めるときは、暗号化ドライブとして使用する以上、消去をするのは一回だけで十分だということを覚えておいてください。

暗号化の仕組み

このセクションは、一般的なディスク暗号化の心臓部である仕組みと方法についての高レベルなイントロダクションです。

技術的数学的な詳細にまで立ち入ることはありませんが (適当な技術書を読んで下さい)、システム管理者が理解しておくべき、暗号化セットアップの選択がユーザビリティやセキュリティにどう影響をあたえるのかという基礎知識を提供します。

基本原理

ディスクを暗号化するとき、各ブロックデバイス (スタックファイルシステムの暗号化の場合、個々のファイル) は等長のセクタに分割されます。例えば512バイト (4096ビット) など。暗号化・復号化はセクタ単位で行われるので、ディスク上のブロックデバイスやファイルの n 番目のセクタには、元のデータの n 番目のセクタを暗号化したものが保存されます。

オペレーティングシステムやアプリケーションがブロックデバイス・ファイルから特定のデータを要求した場合、そのデータが含まれているセクタ全体がディスクから読み込まれて、即座に復号化され、一時的にメモリに保存されます:

          ╔═══════╗
 sector 1 ║"???.."║
          ╠═══════╣         ╭┈┈┈┈┈╮
 sector 2 ║"???.."║         ┊ key ┊
          ╠═══════╣         ╰┈┈┬┈┈╯
          :       :            │
          ╠═══════╣            ▼             ┣┉┉┉┉┉┉┉┫
 sector n ║"???.."║━━━━━━━(decryption)━━━━━━▶┋"abc.."┋ sector n
          ╠═══════╣                          ┣┉┉┉┉┉┉┉┫
          :       :
          ╚═══════╝
 
          encrypted                          unencrypted
     blockdevice or                          data in RAM
       file on disk

同じように、書き込み操作のときは、該当箇所のセクタが全て再暗号化されます (他のセクタに変更が加えられることはありません)。

データを暗号化・復号化するために、ディスク暗号化システムはディスクに関連付けられたユニークな秘密鍵を知る必要があります。暗号化されたブロックデバイスやフォルダをマウントするには、適切な鍵が必要です (以後「マスター鍵」と呼びます)。

暗号化のセキュリティでは鍵のエントロピーが一番重要です。ランダムに生成された一定の長さ (例えば32バイト=256ビット) のバイト文字列が望ましいですが、覚えづらい上にマウント時に手動で入力するのは苦痛です。

そこで2つの方法があります。1番目の方法はマスター鍵のエントロピーを増大させる暗号化アプリケーションです。通常は人間が扱える程度のパスフレーズが用いられます。様々なタイプの暗号化方法があり比較表ではそれぞれの特徴を列記しています。そして、2番目の方法は高エントロピーのキーファイルを作成して暗号化するデータドライブとは別のメディアに保存する方式です。

参照:

Wikipedia:ja:認証付き暗号

鍵とキーファイルとパスフレーズ

以下はキーファイルでマスター鍵を安全に保存する方法の例です:

プレーンテキストのキーファイルに保存

マスター鍵をファイルに保存するのは最も単純な方法です。ファイル (キーファイル) は USB メモリなどに保存して、安全な場所に保管しておき、ディスク上の暗号データをマウントしたいときだけコンピュータに接続します (例: 起動時やログイン時)。
パスフレーズで保護したキーファイルあるいはディスクに保存

マスター鍵 (と暗号データ) は秘密のパスフレーズで保護することができます。暗号化したブロックデバイスやフォルダをマウントするたびに思い出して入力する必要があります。詳しくは下の#暗号メタデータを見てください。
セッションごとにランダムに生成

スワップ領域や /tmp パーティションを暗号化する場合など、ときとしてマスター鍵を必ずしも保存しなくてよい場合があります。セッション毎に使い捨てのキーをランダムに生成するのであれば、ユーザーが何かする必要はありません。その場合、パーティションをアンマウントするとパーティションに書き込まれたデータを誰も復号化できなくなります。暗号化するのが一時ファイルなどの場合はそれで特に問題ありません。

暗号メタデータ

暗号技術ではマスター鍵のセキュリティを守るために暗号化関数がよく使われます。暗号化されたデバイスがマウントされたとき、パスフレーズやキーファイルを暗号化関数に入れて、出てきた計算結果を使ってマスター鍵を解錠してデータを復号化します。

一般的なのはパスフレーズのいわゆる「キーストレッチング」です (「鍵導出関数」が使用されます)。パスフレーズはマウントキーとして使用し、実際のマスター鍵を復号化するのに使われます (マスター鍵は暗号化された状態で保存されます):

 ╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮                         ╭┈┈┈┈┈┈┈┈┈┈┈╮
 ┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key ┊
 ╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,───⎝   function   ⎠    ╰┈┈┈┈┈┬┈┈┈┈┈╯
 ╭──────╮            ╱                              │
 │ salt │───────────´                               │
 ╰──────╯                                           │
 ╭─────────────────────╮                            ▼         ╭┈┈┈┈┈┈┈┈┈┈┈┈╮
 │ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊
 ╰─────────────────────╯                                      ╰┈┈┈┈┈┈┈┈┈┈┈┈╯

鍵導出関数 (例: PBKDF2 や scrypt) は意図的に低速にしか動作しないようになっており (ハッシュ関数を何度も繰り返し使用します、例えば HMAC-SHA-512 を1000回実行)、総当り攻撃によってパスフレーズを見つけ出すことが事実上不可能です。正しいパスワードを持っているユーザーの場合、計算する必要があるのは一度だけなので、多少遅くても問題になりません。

また、ディスク暗号化をセットアップするときにランダムに生成される "salt" を追加引数として使います。salt は暗号メタデータに含まれ暗号化されていない状態で保存されます。セットアップのたびに異なる値となるため、あらかじめ計算済みのテーブルを使って鍵導出関数に対して総当り攻撃をすることが不可能になります。

暗号化されたマスター鍵は暗号化されたデータと一緒にディスク上に保存するため、暗号化データの機密性は完全に秘密のパスフレーズに依存します。

USB スティックなどのキーファイルに暗号化したマスター鍵を保存することでセキュリティをさらに向上させることも可能です。いわゆる二段階認証です: 暗号化されたデータにアクセスするにはあなただけが知っているもの (パスフレーズ) に加えて、あなただけが持っているもの (キーファイル) も必要となります。

二段階認証を実現する他の方法として、上記の鍵導出を強化してパスフレーズと (USB スティックなどに保存した) 外部のファイルに含まれるバイトデータを数学的に「ミックス」してから鍵導出関数に渡すという手段もあります。使用するファイルは何でもかまいません。通常の JPEG 画像などであれば#もっともらしい否認にも有効でしょう。画像ではありますが、ここでは同じ「キーファイル」となります。

導出したマスター鍵は暗号化ブロックデバイスやフォルダがマウントされている間だけ、メモリ上に安全に保管されます (カーネルのキーリングなど)。

通常はディスクデータを暗号化・復号化するのにマスター鍵が直接使われることはありません。例えば、スタックファイルシステム暗号化の場合、ファイルにはそれぞれ別々の暗号鍵が自動的に割り当てられます。ファイルを読み書きしたくなったら、最初にメイン鍵を使ってファイルの鍵を復号化してから、ファイルの中身が復号化・暗号化できるようになります:

                          ╭┈┈┈┈┈┈┈┈┈┈┈┈╮
                          ┊ master key ┊
  file on disk:           ╰┈┈┈┈┈┬┈┈┈┈┈┈╯
 ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐        │
 ╎╭───────────────────╮╎        ▼          ╭┈┈┈┈┈┈┈┈┈┈╮
 ╎│ encrypted file key│━━━━(decryption)━━━▶┊ file key ┊
 ╎╰───────────────────╯╎                   ╰┈┈┈┈┬┈┈┈┈┈╯
 ╎┌───────────────────┐╎                        ▼           ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐
 ╎│ encrypted file    │◀━━━━━━━━━━━━━━━━━(de/encryption)━━━▶┊ readable file ┊
 ╎│ contents          │╎                                    ┊ contents      ┊
 ╎└───────────────────┘╎                                    └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
 └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘

同じように、スタックファイルシステム暗号化の場合、ファイル名を暗号化するときは別の鍵 (例: フォルダごとに割り振られた鍵) が使われます。

ブロックデバイス暗号化の場合、デバイスごと、つまり全てのデータで使われるのはひとつのマスター鍵です。一部のブロックデバイス暗号化では同一デバイスに複数のパスフレーズやキーファイルを割り当てることができますが、できないものもあります。上記の関数を使ってマスター鍵を保全する場合もあればキーのセキュリティを完全にユーザーに委ねる場合もあります。例として dm-crypt の plain モードと LUKS モードで使用される暗号パラメータで説明しましょう。

両方のモードで使用するパラメータを比較すると、dm-crypt の plain モードではキーファイルの場所に関するパラメータがあることに気づくでしょう (例: --keyfile-size, --keyfile-offset)。dm-crypt の LUKS モードではキーファイルの場所を指定する必要はありません。各ブロックデバイスのヘッダーに暗号のメタデータが含まれるためです。ヘッダーには使用する暗号、暗号化されたマスター鍵、そして鍵導出に必要なパラメータが存在します。最後のパラメータは最初にマスター鍵を暗号化したときに使用したオプションから生成されます (例: --iter-time, --use-random)。

暗号化手段のメリット・デメリットについては#比較表やそれぞれのページを参照してください。

参照:

暗号と利用モード

与えられた暗号鍵を使って実際に暗号化データと非暗号化データ (つまり"平文"と"暗号文") を変換するのに使われるアルゴリズムは "cipher" と呼ばれます。

ディスク暗号化では等長なブロックのデータを処理する"ブロック暗号" (block cipher) が用いられます。ブロック長は16バイト (128ビット) などになります。執筆時点で、主に使われている暗号は以下のとおり:

	ブロックサイズ	キーサイズ	注記
AES	128 ビット	128, 192, 256 ビット	アメリカ政府の "SECRET" または "TOP SECRET" の機密情報を保護するのに足ると NSA によって承認されています (192または256ビットのキーサイズの使用時)。
Blowfish	64 ビット	32–448 ビット	初期のパテントフリーでセキュアな暗号の一つであり誰でも使えるため、Linux ではかなり定着しています。
Twofish	128 ビット	128, 192, 256 ビット	Blowfish の後継として開発されましたが、それほど幅広くは利用されていません。
Serpent	128 ビット	128, 192, 256 ビット	AES コンペティションの5つの最終候補の中で一番セキュアだと考えられています^[10][11][12]。

セクタの暗号化・復号化 (上を参照) を行うときはセクタを暗号のブロックサイズにあわせて小さなブロックに分割します。個々のブロックに暗号をどのように適用していくかは特定のルールセット (いわゆる"暗号利用モード") に従います。

特に手を加えずにそれぞれのブロックを独立して暗号化するのはセキュアではありません ("電子符号表 (electronic codebook, ECB)" モードと呼ばれます)。平文で同じ16バイトのテキストがあれば、暗号文も常に同じになるため、ディスクに保存されている暗号文から簡単にパターンを見つけ出すことができてしまいます。

実際に広く使われている利用モードは "暗号ブロック連鎖 (cipher-block chaining, CBC)" です。CBC モードでセクタを暗号化した場合、平文データの各ブロックは前のブロックの暗号文と数学的に混ぜ合わされてから暗号化されます。最初のブロックは前の暗号文がないため、"初期化ベクトル (IV)" と呼ばれる暗号メタデータに保存されている特殊な事前生成済みのデータブロックが使われます:

                                  ╭──────────────╮
                                  │initialization│
                                  │vector        │
                                  ╰────────┬─────╯
          ╭  ╠══════════╣        ╭─key     │      ┣┉┉┉┉┉┉┉┉┉┉┫        
          │  ║          ║        ▼         ▼      ┋          ┋         . START
          ┴  ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"Hello, W"┋ block  ╱╰────┐
    sector n ║          ║                         ┋          ┋ 1      ╲╭────┘
  of file or ║          ║──────────────────╮      ┋          ┋         ' 
 blockdevice ╟──────────╢        ╭─key     │      ┠┈┈┈┈┈┈┈┈┈┈┨
          ┬  ║          ║        ▼         ▼      ┋          ┋
          │  ║"????????"║◀━━━━(cipher)━━━━(+)━━━━━┋"orld !!!"┋ block
          │  ║          ║                         ┋          ┋ 2
          │  ║          ║──────────────────╮      ┋          ┋
          │  ╟──────────╢                  │      ┠┈┈┈┈┈┈┈┈┈┈┨
          │  ║          ║                  ▼      ┋          ┋
          :  :   ...    :        ...      ...     :   ...    : ...
 
               ciphertext                         plaintext
                  on disk                         in RAM

復号化するときは、手順が逆になります。

注目に値することの1つは、セクターごとに一意の初期化ベクトルを生成することです。最も簡単な選択は、セクター番号などのすぐに利用できる値から予測可能な方法で計算することです。ただし、これにより、システムに繰り返しアクセスする攻撃者が、いわゆる watermarkingattack を実行できる可能性があります。これを防ぐために、 暗号化されたソルトセクター初期化ベクトル ( ESSIV) と呼ばれる方法を使用して、潜在的な攻撃者に完全にランダムに見えるように初期化ベクトルを生成できます。

ディスク暗号化に利用できる他のより複雑な操作モードもいくつかあります。これらは、そのような攻撃に対する組み込みのセキュリティをすでに提供しています(したがって、 ESSIV を必要としません)。暗号化されたデータの信頼性をさらに保証できるものもあります(つまり、キーにアクセスできない人によってデータが変更/破損されていないことを確認します)。

参照:

もっともらしい否認

Wikipedia:Plausible deniability を参照してください。

ディスク暗号化シナリオのバックアップ

データ損失から保護するために、ユーザーデータのバックアップを作成します。一般に、暗号化されたデータのバックアップも暗号化する必要があります。

ブロックデバイスの暗号化

複数のオプションがあり、暗号化コンテナが存在するディスクブロックデバイスをイメージとしてバックアップできます。 /dev/sdx または暗号化されたコンテナ内のファイルシステムをバックアップできます。 /dev/mapper/dm_name またはファイルをバックアップできます。例: rsync で。次のセクションでは、各オプションの長所と短所を示します。

ディスクブロックデバイスのバックアップ

ディスクブロックデバイスのバックアップは次のとおりです。

作業コピーと同じレベルのセキュリティでそのまま暗号化
LUKS ヘッダーが含まれています
常にディスクブロックデバイスと同じ大きさ
増分バックアップ、圧縮、重複排除などの高度なバックアップ戦略を簡単に許可することはできません
暗号化コンテナも復元されるため、新しいディスクに簡単に復元できます

ファイルシステムまたはファイルのバックアップ

1つまたは複数のファイルのバックアップは次のとおりです。

そのまま 暗号化されていない
ネットワーク経由で転送する前、またはディスクに保存するときに暗号化する必要があり、追加の作業が必要です
必ずしも作業コピーと同じレベルのセキュリティで暗号化されているとは限りません
LUKS ヘッダーは含まれていません
ファイルシステムの使用済みスペースと同じ大きさのみ。たとえば、Partclone
増分バックアップ、圧縮、重複排除などの高度なバックアップ戦略を可能にします
LUKS ヘッダーのバックアップを復元するなどして、暗号化コンテナを新しいディスクに手動で復元する必要があります

LUKS ヘッダーバックアップ

LUKS を使用している場合、dm-crypt/デバイスの暗号化#バックアップとリストアを作成できます。特にパスフレーズが取り消されている場合は、これらのバックアップを定期的にチェックして同期するのが理にかなっています。

ただし、データのバックアップがあり、それを復元する場合は、cryptsetupを使用してLUKS暗号化パーティションを最初から再作成してからデータを復元できます。したがって、LUKSヘッダーのバックアップはデータのバックアップよりも重要ではありません。

参照

^ http://www.truecrypt.org/legal/license を参照
^ ファイルシステムのひとつのファイルをコンテナとして使うことはできますが(仮想ループバックデバイス)、ファイルシステム(の機能)を使うことはできなくなります。
^ CrossCrypt - Windows XP や Windows 2000 と互換性のあるオープンソースの AES と TwoFish による Linux の暗号化
^ (1) FreeOTFE (on sf.net) (2) FreeOTFE (archived) - Windows 2000 以上 (PC) や Windows Mobile 2003 以上 (PDA) をサポート
^ EncFs build instructions for Mac を参照
^ http://www.freshports.org/sysutils/fusefs-encfs/ を参照
^ https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data を参照
^ http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
^ http://members.ferrara.linux.it/freddy77/encfs.html
^ http://csrc.nist.gov/archive/aes/round2/r2report.pdf
^ https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf
^ https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf
^ https://github.com/vgough/encfs/issues/118
^ LibreCrypt (旧名 DOXBOX) - 新しいバージョンの Windows におけるオープンな dm-crypt / LUKS のサポート (OTFE のフォークを含む)

@@ 1行目: / 1行目: @@
-[[Category:ディスク暗号化]]
+[[Category:保存データ暗号化]]
 [[en:Data-at-rest encryption]]
 [[es:Data-at-rest encryption]]
@@ 48行目: / 48行目: @@
 === システムデータ暗号化 ===
-; データ暗号化
 : データ暗号化は、ユーザーのデータ ({{ic|/home}} ディレクトリの中や、データ DVD などのリムーバブルメディア) だけの暗号化と定義され、一番シンプルで込み入ったところがないディスク暗号化の利用法ですが、致命的な欠点があります。
 : 最近の計算システムでは、ユーザーデータに関する情報や、またはデータそれ自体の一部を以下のようなハードドライブの暗号化されていない領域にキャッシュ・保存するバックグラウンドプロセスが多数存在します:
@@ 106行目: / 105行目: @@
 選択するレイヤーの実用性については、下の[[#実用性|比較表]]を見て下さい。[http://ksouedu.com/doc/ecryptfs-utils/ecryptfs-faq.html#compare eCryptfs] についての記事も参照。
+=== ブロックデバイスとスタックファイルシステムの暗号化 ===
-=== Block device vs stacked filesystem encryption ===
 {| class="wikitable left-align-row-headers" style="text-align:center;"
-! Aspect
+! 特徴
+! {{B|デバイスの暗号化をブロックする}}
-! {{B|Block device encryption}}
+! {{V|スタックされたファイルシステムの暗号化}}
-! {{V|Stacked filesystem encryption}}
 |-
+! 暗号化
-! Encrypts
+| ブロック全体のデバイス
-| whole block devices
+| ファイル
-| files
 |-
+! 暗号化されたデータのコンテナは次の可能性があります...
-! Container for encrypted data may be...
+| ループデバイスとしてのディスクまたはディスクパーティション/ファイル
-| a disk or disk partition / a file as loop device
+| 既存のファイル システム内のディレクトリ
-| a directory in an existing file system
 |-
+! ファイルシステムとの関係
-! Relation to filesystem
+| ファイルシステム層の下で動作します。暗号化されたブロックデバイスの内容がファイルシステム、パーティションテーブル、LVM セットアップ、またはその他のものであるかどうかは関係ありません。
-| operates below filesystem layer: does not care whether the content of the encrypted block device is a filesystem, a partition table, a LVM setup, or anything else
+| 既存のファイルシステムに追加のレイヤーを追加し、ファイルの書き込み/読み取りのたびに自動的にファイルを暗号化/復号化します。
-| adds an additional layer to an existing filesystem, to automatically encrypt/decrypt files whenever they are written/read
 |-
+! ファイルのメタデータ (ファイル数、ディレクトリ構造、ファイル サイズ、権限、mtimes など) は暗号化されます。
-! File metadata (number of files, dir structure, file sizes, permissions, mtimes, etc.) is encrypted
 | {{Yes}}
+| {{No}}<br>(ファイル名とディレクトリ名は暗号化できます)
-| {{No}}<br>(file and dir names can be encrypted though)
 |-
+! ハードドライブ全体 (パーティションテーブルを含む) をカスタム暗号化するために使用できます。
-! Can be used to custom-encrypt whole hard drives (including partition tables)
 | {{Yes}}
 | {{No}}
 |-
+! スワップスペースの暗号化に使用可能
-! Can be used to encrypt swap space
 | {{Yes}}
 | {{No}}
 |-
+! 暗号化されたデータコンテナ用に固定量のスペースを事前に割り当てずに使用可能
-! Can be used without pre-allocating a fixed amount of space for the encrypted data container
 | {{No}}
 | {{Yes}}
 |-
+! NFS や Samba 共有、クラウドストレージなど、デバイスアクセスをブロックせずに既存のファイルシステムを保護するために使用できます。
-! Can be used to protect existing filesystems without block device access, e.g. NFS or Samba shares, cloud storage, etc.
 | {{No}}
 | {{Yes}}
 |-
+! 暗号化されたファイルのファイルベースのオフラインバックアップが可能
-! Allows offline file-based backups of encrypted files
 | {{No}}
 | {{Yes}}

「保存データ暗号化」の版間の差分

2024年6月8日 (土) 13:50時点における最新版

目次

なぜ暗号化を使うのか?

システムデータ暗号化

利用可能な手段

スタックファイルシステムの暗号化

クラウドストレージの最適化

ブロックデバイスの暗号化

ブロックデバイスとスタックファイルシステムの暗号化

比較表

概要

基本的な分類

実用性

ユーザビリティ

セキュリティ

パフォーマンス

ブロックデバイス暗号化特有の事項

スタックファイルシステム暗号化特有の事項

互換性と普及度

準備

セットアップの選択

強固なパスフレーズの選択

ディスクの準備

暗号化の仕組み

基本原理

鍵とキーファイルとパスフレーズ

暗号メタデータ

暗号と利用モード

もっともらしい否認

ディスク暗号化シナリオのバックアップ

ブロックデバイスの暗号化

ディスクブロックデバイスのバックアップ

ファイルシステムまたはファイルのバックアップ

LUKS ヘッダーバックアップ

参照

案内メニュー

検索