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

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:Security (日本語)]]
+[[Category:保存データ暗号化]]
+[[en:Data-at-rest encryption]]
-[[Category:File systems (日本語)]]
-[[en:Disk encryption]]
+[[es:Data-at-rest encryption]]
-[[es:Disk encryption]]
+[[pl:Data-at-rest encryption]]
+[[pt:Data-at-rest encryption]]
-[[it:Disk Encryption]]
-{{Related articles start (日本語)}}
+{{Related articles start}}
-{{Related2|dm-crypt (日本語)|dm-crypt}}
+{{Related|dm-crypt}}
 {{Related|TrueCrypt}}
 {{Related|eCryptfs}}
 {{Related|EncFS}}
+{{Related|gocryptfs}}
+{{Related|fscrypt}}
 {{Related|Tomb}}
 {{Related|tcplay}}
+{{Related|GnuPG}}
+{{Related|自己暗号化ドライブ}}
 {{Related articles end}}
-この記事ではストレージディスクの論理部 (フォルダ, パーティション, ディスク全体など) を暗号化で保護するために Arch Linux で利用できる技術について扱っており、書き込まれたデータを全て自動的に暗号化して、読み込むときにオンザフライで復元することを目標とします。
+この記事では、[[ブロックデバイス]]や[[ディスクパーティション]]、ディレクトリに書き込んだり読み込んだりするデータをその場で暗号化/復号化する、[[Wikipedia:Data at rest|保存データ]] [[Wikipedia:Disk encryption|暗号化]]ソフトウェアについて説明します。ブロックデバイスの例としては、ハードディスク、フラッシュドライブ、DVDなどがあります。
+保存データの暗号化は、あくまでもオペレーティングシステムの既存のセキュリティ機構を補助するものと考えるべきで、物理的なアクセスの保護に焦点を当て、ネットワークセキュリティやユーザーベースのアクセスコントロールなどは、システムの''他''の部分に依存することになります。
-これに関連して"ストレージディスク"とはコンピュータのハードドライブや、USB フラッシュドライブや DVD などの外部デバイスだけでなく、ループバックデバイスやクラウドストレージなどの (Arch Linux からブロックデバイスやファイルシステムとして参照することができる) ''仮想''ストレージディスクも含めます。
+フルディスク暗号化 (FDE) については、[[dm-crypt/システム全体の暗号化]]を参照してください。
-保護したい''対象''や暗号化する''方法''をすでに決めている場合は、右にある''関連''記事を直接見ることを推奨します。
-==なぜ暗号化を使うのか？==
+== なぜ暗号化を使うのか? ==
 ディスク暗号化は確実にファイルを常に暗号化された状態でディスクに保存することができます。ファイルにアクセスできるのは、システムが動いていて信頼されたユーザーによってロックを解除された間だけで、その場合にのみオペレーティングシステムやアプリケーションは読み取れる状態でファイルにアクセスすることができるようになります。権限のないユーザーが直接ディスクの中身を見たとしても、わかるのは意味がわからないランダムなデータだけで、実際のファイルを読み取ることは不可能です。
@@ 30行目: / 34行目: @@
 さらに、ディスク暗号化を使うことで、オペレーティングシステムを改竄しようとする不正アクセスに対するセキュリティの強化にもなります。例えば、システムへの物理的なアクセスを手に入れた攻撃者によるキーロガーやトロイの木馬のインストールへの防衛手段になります。
-{{Warning|ディスク暗号化はあらゆる脅威からデータを保護するわけではないので注意してください。}}
+{{Warning|ディスク暗号化はあらゆる脅威からデータを保護するわけではないので注意してください。
 ディスク暗号化によっても以下のような場合には対処できません:
 * システムが動いていて、あなたがロックを解除してディスクの暗号化している部分をマウントしてしまった後に (インターネットなどを介して) 攻撃者がシステムに侵入した場合。
 * [[Wikipedia:Cold boot attack|コールドブートアタック]]に必要な手段を攻撃者が手に入れていて、(画面ロックを使っていたとしても) コンピュータが動作している、または動作していたすぐ後に攻撃者が物理的にアクセスできる場合。
 * 政府機関が、上記の攻撃を簡単に行える資力を持っているだけでなく、もっとシンプルに、様々な[[Wikipedia:ja:強制|強制執行]]を使って無理矢理キーやパスフレーズを明かさせることができる場合。世界中の非民主的な国々、さらにアメリカやイギリスでも、何か興味深いものをあなたが隠していると法執行機関が疑いをかけた場合、法執行機関によってロックの解除を合法的に迫られる可能性があります。
+* [[Wikipedia:Rubber-hose_cryptanalysis|締め上げ暗号分析]] [https://xkcd.com/538/ XKCD #538] も参照してください。
+ディスク暗号化をしたとしても[[ディスクの完全消去|ディスクの消去]]からは保護されません。データを安全に保つため[[バックアッププログラム|定期的なバックアップ]]を推奨します。
-あなたがシステムを使う前にシステムに細工を施すことができるプロの攻撃者にまともに対抗するには非常に強固なディスク暗号化が必要になります (例: 平文のブートパーティションがなく真正の確認があるフルシステム暗号化)。それでもあらゆるタイプの改竄を押しとどめることができるかというと疑問です (例: ハードウェアキーロガー)。おそらく[[Wikipedia:Hardware-based full disk encryption|ハードウェアベースの完全ディスク暗号化]]と[[Wikipedia:Trusted_Computing|トラステッドコンピューティング]]が最善策でしょう。
+}}
+あなたがシステムを使う前にシステムに細工を施すことができるプロの攻撃者にまともに対抗するには非常に強固なディスク暗号化が必要になります (例: 平文のブートパーティションがなく真正の確認があるフルシステム暗号化)。それでもあらゆるタイプの改竄を押しとどめることができるかというと疑問です (例: ハードウェアキーロガー) おそらく[[Wikipedia:Hardware-based full disk encryption|ハードウェアベースの完全ディスク暗号化]]と[[Wikipedia:Trusted_Computing|トラステッドコンピューティング]]が最善策でしょう。
-{{Warning|ディスク暗号化をしたとしても[[Securely wipe disk|ディスクの消去]]からは保護されません。データを安全に保つため[[Backup programs (日本語)|定期的なバックアップ]]を推奨します。}}
-=== データ暗号化 vs システム暗号化 ===
+=== システムデータ暗号化 ===
+: データ暗号化は、ユーザーのデータ ({{ic|/home}} ディレクトリの中や、データ DVD などのリムーバブルメディア) だけの暗号化と定義され、一番シンプルで込み入ったところがないディスク暗号化の利用法ですが、致命的な欠点があります。
-; データ暗号化
-: データ暗号化は、ユーザーのデータ ({{ic|/home}} ディレクトリの中や、データ DVD などのリムーバルメディア) だけの暗号化と定義され、一番シンプルで込み入ったところがないディスク暗号化の利用法ですが、致命的な欠点があります。
 : 最近の計算システムでは、ユーザーデータに関する情報や、またはデータそれ自体の一部を以下のようなハードドライブの暗号化されていない領域にキャッシュ・保存するバックグラウンドプロセスが多数存在します:
 :* スワップパーティション
-:** <span style="color:#555">''(救済策: スワップを無効にする、または[[Dm-crypt/Swap encryption|スワップも暗号化]]してしまう)''</span>
+:** <span style="color:#555">''(救済策: スワップを無効にする、または[[Dm-crypt/スワップの暗号化|スワップも暗号化]]してしまう)''</span>
 :* {{ic|/tmp}} (ユーザーアプリケーションによって作成される一時ファイル)
-:** <span style="color:#555">''(救済策: そのようなアプリケーションを使うのをやめる、または {{ic|/tmp}} を [[ramdisk (日本語)|RAM ディスク]]にマウントする)''</span>
+:** <span style="color:#555">''(救済策: そのようなアプリケーションを使うのをやめる、または {{ic|/tmp}} を [[RAM ディスク]]にマウントする)''</span>
 :* {{ic|/var}} (ログファイルやデータベースなど。例えば mlocate は全てのファイル名のインデックスを {{ic|/var/lib/mlocate/mlocate.db}} に保存します)
 :さらに、データ暗号化だけではオフラインのシステムのタンパリング攻撃にたいして隙を残すことになります (例: 暗号化されたデータを解除するために使用するパスフレーズを[[Wikipedia:ja:キーロガー|記録]]するプログラムや、ロックを解除するのを待ってから密かに攻撃者がデータを回収できる場所にデータをコピー/送信するプログラムのインストール)。
+== 利用可能な手段 ==
-; システム暗号化
-: システム暗号化は、オペレーティングシステム''と''ユーザーデータの暗号化と定義されており、データ暗号化の欠点を解決します。
+あらゆるディスク暗号化の手段というのは、ディスクは暗号化されたデータを保持しながら、暗号コンテナ (つまり暗号化されたデータを保持するディスクの論理部) が"解除"されてマウントされているときにかぎり、オペレーティングシステムやアプリケーションからは通常の読み込み可能なデータとして見えるようにするという方法で働きます。
-: メリット:
-:* オペレーティングシステムのファイルに対する権限のない物理アクセス (と改竄) を防ぎます ''(ただし上の警告を見て下さい)''
-:* システムによってキャッシュされる可能性のあるプライベートなデータへの権限のない物理アクセスを防ぎます
-: デメリット:
-:* ユーザーのログイン中またはログイン後にディスクの暗号化された部分を解除することはできなくなります。起動時に行わなくてはなりません
+暗号化を使うには、ユーザーによって"秘密情報"が供給される必要があり (通常はキーファイルやパスフレーズの形で指定します)、それから実際の暗号化キーが生成されます (そしてセッションの間はカーネルのキーリングに保存されます)。
-実際には、データ暗号化とシステム暗号化はいつでも判然と区別することができるというわけではなく、様々な妥協やカスタマイズをしたセットアップというのが考えられます。
+この種の仕組みが全くわからないという場合は、下の[[#暗号化の仕組み|暗号化の仕組み]]セクションを読んで下さい。
-いずれにせよ、ディスク暗号化はあくまでオペレーティングシステムの既存のセキュリティ機構の添え物として考えるべきです。ネットワークセキュリティやユーザーベースのアクセス制御などを提供するシステムの''他の''部分を活かしながら、オフラインの物理アクセスの防御も考えて下さい。
+利用できるディスク暗号化の方法は、稼働するレイヤーによって2つのタイプに分けることができます:
-[[Wikipedia:Disk encryption]] も参照。
+===スタックファイルシステムの暗号化===
-==利用可能な手段==
+スタックファイルシステムによる暗号化ソリューションは既存のファイルシステム上に積み上げられるレイヤーとして実装され、暗号化が有効になったフォルダへ書き込まれた全てのファイルを、実際のファイルシステムがディスクに書き込む前に即座に暗号化します。そしてファイルシステムがディスクからファイルを読み込んだ時は復号化を行います。この方法では、ホストファイルシステムには暗号化された形でファイルが保存されますが (ファイルの中身や、ファイル名・フォルダ名も、同じ長さのランダムなデータで置き換えられます)、それ以外のファイルはファイルシステム上に通常のファイル/シンボリックリンク/ハードリンクとして暗号化されない形で存在します。
-All disk encryption methods operate in such a way that even though the disk actually holds encrypted data, the operating system and applications "see" it as the corresponding normal readable data as long as the cryptographic container (i.e. the logical part of the disk that holds the encrypted data) has been "unlocked" and mounted.
+ホストファイルシステムにある暗号化されたファイルが保存されたフォルダをロック解除するため、(特殊なスタック擬似ファイルシステムを使って) それ自体または別の場所にマウントされ、同じファイルが読み込める形で現れます。アンマウントしたり、システムの電源が落とされるまでその状態は維持されます。
-For this to happen, some "secret information" (usually in the form of a keyfile and/or passphrase) needs to be supplied by the user, from which the actual encryption key can be derived (and stored in the kernel keyring for the duration of the session).
+スタックファイルシステム暗号化で利用できるソリューションには [[eCryptfs]] や [[EncFS]] があります。
-If you are completely unfamiliar with this sort of operation, please also read the [[#How the encryption works]] section below.
+==== クラウドストレージの最適化 ====
-利用できるディスク暗号化の方法は、稼働するレイヤーによって2つのタイプに分けることができます:
+クラウドストレージサービスなど、サードパーティが管理する場所とのゼロ知識同期を実現するためにスタックファイルシステムの暗号化を導入している場合は、eCryptfs や EncFS の代替手段を検討することをお勧めします。これらは、インターネットを介したファイルの送信用に最適化されていないためです。代わりに、この目的のために設計されたソリューションがいくつかあります。
-===スタックファイルシステムの暗号化===
+* [[gocryptfs]]
-Stacked filesystem encryption solutions are implemented as a layer that stacks on top of an existing filesystem, causing all files written to an encryption-enabled folder to be encrypted on-the-fly before the underlying filesystem writes them to disk, and decrypted whenever the filesystem reads them from disk. This way, the files are stored in the host filesystem in encrypted form (meaning that their contents, and usually also their file/folder names, are replaced by random-looking data of roughly the same length), but other than that they still exist in that filesystem as they would without encryption, as normal files / symlinks / hardlinks / etc.
+* {{AUR|cryptomator}} もしくは {{AUR|cryptomator-bin}} (マルチプラットフォーム)
+* {{Pkg|cryfs}}
+一部のクラウドストレージサービスは、独自のサービスを通じてゼロ知識暗号化を直接提供していることに注意してください。[[アプリケーション一覧/インターネット#クラウド同期クライアント|クライアントアプリケーション]]
-The way it is implemented, is that to unlock the folder storing the raw encrypted files in the host filesystem ("lower directory"), it is mounted (using a special stacked pseudo-filesystem) onto itself or optionally a different location ("upper directory"), where the same files then appear in readable form - until it is unmounted again, or the system is turned off.
+===ブロックデバイスの暗号化===
-Available solutions in this category are:
+一方、ブロックデバイス暗号化はファイルシステムレイヤーの''下''で動作して、特定のブロックデバイス (つまり、ディスクやパーティション全体、または仮想的なループバックデバイスとして振る舞うファイル) に書き込まれる全てのデータが暗号化されます。このため、ブロックデバイスがオフラインのときは、中身が全てランダムなデータの巨大なブロブのように見え、ファイルシステムやデータに何が含まれているのか判断できなくなります。データにまたアクセスするときは、保護されたコンテナ (この場合、ブロックデバイス) を特殊な方法で任意の場所にマウントします。
-;eCryptfs: [[eCryptfs]] を参照。
+Arch Linux では"ブロックデバイス暗号化"として以下の方法が利用できます:
-;EncFS: [[EncFS]] を参照。
+;loop-AES: loop-AES は cryptoloop の後継で、システム暗号化のためのセキュアで高速なソリューションです。ただし、標準にないカーネルのサポートが必要になるため loop-AES は他の選択肢と比べてユーザーフレンドリーとは言い難いかもしれません。
-===ブロックデバイスの暗号化===
+;dm-crypt: [[dm-crypt]] は Linux カーネルによって提供されている標準の device-mapper 暗号化機能です。直接使うことでパーティションやキーの管理のあらゆることを完全にコントロールすることができます。dm-crypt の管理はユーザースペースユーティリティの {{Pkg|cryptsetup}} を使って行います。次のタイプのブロックデバイス暗号化に使用することが可能です: ''LUKS'' (デフォルト), ''plain'', そして機能制限がありますが ''loopAES'' と ''Truecrypt'' デバイス。
-Block device encryption methods, on the other hand, operate ''below'' the filesystem layer and make sure that everything written to a certain block device (i.e. a whole disk, or a partition, or a file acting as a virtual loop-back device) is encrypted. This means that while the block device is offline, its whole content looks like a large blob of random data, with no way of determining what kind of filesystem and data it contains. Accessing the data happens, again, by mounting the protected container (in this case the block device) to an arbitrary location in a special way.
+:* デフォルトで使用される LUKS は dm-crypt をセットアップするのに必要な情報を全てディスクに保存する便利なレイヤーで、使いやすさと暗号のセキュリティを増すためにパーティションとキー管理を抽象化します。
+:* plain dm-crypt モードは、オリジナルのカーネルの機能であり、便利なレイヤーを使いません。レイヤーを使った時と同じ暗号強度を確保するのは難しくなります。そうしようとすると、結果的にキー (パスフレーズまたはキーファイル) が長くなってしまいます。しかしながら、下で説明しているように利点も存在します。
+;TrueCrypt: [[TrueCrypt]] の開発者は2014年5月にサポートを終了しています。それ以降脆弱性が修正されていないため、使用してはなりません。
-Arch Linux では"ブロックデバイス暗号化"として以下の方法が利用できます:
+;VeraCrypt: TureCryptの後継です。
-;loop-AES: loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption. However, loop-AES is considered less user-friendly than other options as it requires non-standard kernel support.
+選択するレイヤーの実用性については、下の[[#実用性|比較表]]を見て下さい。[http://ksouedu.com/doc/ecryptfs-utils/ecryptfs-faq.html#compare eCryptfs] についての記事も参照。
-;dm-crypt: [[dm-crypt]] is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management. The management of dm-crypt is done with the {{Pkg|cryptsetup}} userspace utility. It can be used for the following types of block-device encryption: ''LUKS'' (default), ''plain'', and has limited features for ''loopAES'' and ''Truecrypt'' devices.
-:* LUKS, used by default, is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use and cryptographic security.
-:* plain dm-crypt mode, being the original kernel functionality, does not employ the convenience layer. It is more difficult to apply the same cryptographic strength with it. When doing so, longer keys (passphrases or keyfiles) are the result. It has, however, other advantages, described in the following.
+=== ブロックデバイスとスタックファイルシステムの暗号化 ===
-;TrueCrypt: [[TrueCrypt]] の開発者は2014年5月にサポートを終了しています。
+{| class="wikitable left-align-row-headers" style="text-align:center;"
-For practical implications of the chosen layer of operation, see the [[#practical_implications|comparison table]] below, as well as the general write up for [http://ksouedu.com/doc/ecryptfs-utils/ecryptfs-faq.html#compare eCryptfs].
+! 特徴
+! {{B|デバイスの暗号化をブロックする}}
+! {{V|スタックされたファイルシステムの暗号化}}
+|-
+! 暗号化
+| ブロック全体のデバイス
+| ファイル
+|-
+! 暗号化されたデータのコンテナは次の可能性があります...
+| ループデバイスとしてのディスクまたはディスクパーティション/ファイル
+| 既存のファイル システム内のディレクトリ
+|-
+! ファイルシステムとの関係
+| ファイルシステム層の下で動作します。暗号化されたブロックデバイスの内容がファイルシステム、パーティションテーブル、LVM セットアップ、またはその他のものであるかどうかは関係ありません。
+| 既存のファイルシステムに追加のレイヤーを追加し、ファイルの書き込み/読み取りのたびに自動的にファイルを暗号化/復号化します。
+|-
+! ファイルのメタデータ (ファイル数、ディレクトリ構造、ファイル サイズ、権限、mtimes など) は暗号化されます。
+| {{Yes}}
+| {{No}}<br>(ファイル名とディレクトリ名は暗号化できます)
+|-
+! ハードドライブ全体 (パーティションテーブルを含む) をカスタム暗号化するために使用できます。
+| {{Yes}}
+| {{No}}
+|-
+! スワップスペースの暗号化に使用可能
+| {{Yes}}
+| {{No}}
+|-
+! 暗号化されたデータコンテナ用に固定量のスペースを事前に割り当てずに使用可能
+| {{No}}
+| {{Yes}}
+|-
+! NFS や Samba 共有、クラウドストレージなど、デバイスアクセスをブロックせずに既存のファイルシステムを保護するために使用できます。
+| {{No}}
+| {{Yes}}
+|-
+! 暗号化されたファイルのファイルベースのオフラインバックアップが可能
+| {{No}}
+| {{Yes}}
+|}
 ===比較表===
+"dm-crypt +/- LUKS" のカラムは LUKS ("+") と plain ("-") 両方の暗号化モードにおける dm-crypt の機能を示しています。特定の機能が LUKS の使用を必要とする場合、そのことは "(LUKS を使用)" で表されます。同じように "(LUKS を使用しない)" はその機能を実現するのに LUKS の使用が逆効果であり、plain モードを使うべきことを示しています。
-The column "dm-crypt +/- LUKS" denotes features of dm-crypt for both LUKS ("+") and plain ("-") encryption modes. If a specific feature requires using LUKS, this is indicated by "(with LUKS)". Likewise "(without LUKS)" indicates usage of LUKS is counter-productive to achieve the feature and plain mode should be used.
 {| class="wikitable" style="text-align:center; cell-padding:100px; "
@@ 116行目: / 159行目: @@
 ! scope="col" style="background:#E2E2E2" | Loop-AES
 ! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
-! scope="col" style="background:#E2E2E2" | Truecrypt
+! scope="col" style="background:#E2E2E2" | TrueCrypt
+! scope="col" style="background:#E2E2E2" | VeraCrypt
 ! scope="col" style="background:#E2E2E2" | eCryptfs
 ! scope="col" style="background:#E2E2E2" | EncFs
@@ 123行目: / 167行目: @@
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 タイプ
-| colspan="3" | ブロックデバイスの暗号化
+| colspan="4" | ブロックデバイスの暗号化
 | colspan="2" | スタックファイルシステムの暗号化
 |- valign="top"
@@ 132行目: / 176行目: @@
 | Linux におけるブロックデバイス暗号化のデファクトスタンダードであり柔軟性があります
 | 携帯性が高く、洗練された、自己完結型の暗号化ソリューション
+| 活発に開発されている TrueCrypt のフォークで、デファクトスタンダードの代替
 | EncFS よりも若干高速で、暗号化されたファイルは個別にシステム間で移動できます
 | 一番使うのが簡単で、root 以外による管理をサポートしています
@@ 140行目: / 185行目: @@
 | カスタムカーネルの手動コンパイルが必須
 | ''カーネルモジュール:'' デフォルトのカーネルに含まれています; ''ツール:'' {{Pkg|device-mapper}}, {{Pkg|cryptsetup}} [core]
+| {{pkg|truecrypt}} [extra] (開発終了) または後方互換のある {{pkg|veracrypt}} [community]
-| [https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/truecrypt&id=efe03070990f9e3554508bd982b1bd5a654aa095 truecrypt 7.1a-2] [extra] (最新バージョンには読み取り機能しかありません)
+| {{pkg|veracrypt}} [community]
 | ''カーネルモジュール:'' デフォルトのカーネルに含まれています; ''ツール:'' {{Pkg|ecryptfs-utils}} [community]
 | {{Pkg|encfs}} [community]
@@ 149行目: / 195行目: @@
 | GPL
 | GPL
-| カスタム<sup>[[#Notes_.26_References|[1]]]</sup>
+| TrueCrypt License 3.1<sup>[[#参照|[1]]]</sup>
+| Apache License 2.0, 一部はTrueCrypt License v3.0<sup>[[#参照|[1]]]</sup>
 | GPL
 | GPL
@@ 160行目: / 207行目: @@
 ! scope="col" style="background:#E2E2E2" | Loop-AES
 ! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
-! scope="col" style="background:#E2E2E2" | Truecrypt
+! scope="col" style="background:#E2E2E2" | TrueCrypt
+! scope="col" style="background:#E2E2E2" | VeraCrypt
 ! scope="col" style="background:#E2E2E2" | eCryptfs
 ! scope="col" style="background:#E2E2E2" | EncFs
@@ 167行目: / 215行目: @@
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 暗号化の対象
-| colspan="3" | ブロックデバイス全体
+| colspan="4" | ブロックデバイス全体
 | colspan="2" | ファイル
 |- valign="top"
@@ 173行目: / 221行目: @@
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 暗号化されたデータのコンテナ
-| colspan="3" |
+| colspan="4" |
 * ディスクまたはディスクパーティション
 * 仮想パーティションとして作用するファイル
@@ 182行目: / 230行目: @@
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 ファイルシステムとの関係
-| colspan="3" | ファイルシステムレイヤーの下で動作し、暗号化されたブロックデバイスの中身がファイルシステム、パーティションテーブル、LVM のどれであるかには関しない
+| colspan="4" | ファイルシステムレイヤーの下で動作し、暗号化されたブロックデバイスの中身がファイルシステム、パーティションテーブル、LVM のどれであるかには関しない
 | colspan="2" | 既存のファイルシステムにレイヤーを追加して、ファイルが書き込まれたり読み込まれた時に自動的に暗号化または復号化を行う
 |- valign="top"
@@ 188行目: / 236行目: @@
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 暗号化の実装空間
-| colspan="4" | カーネル空間
+| colspan="5" | カーネル空間
 | ユーザー空間<br>''(FUSE を使用)''
 |- valign="top"
@@ 195行目: / 243行目: @@
 暗号メタデータの保存場所
 | ?
-| with LUKS: LUKS Header
+| LUKS を使用: LUKS ヘッダー
-| rowspan="2" | begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format])
+| colspan="2" rowspan="2" | (復号化された) デバイスの冒頭/最後 ([http://www.truecrypt.org/docs/volume-format-specification フォーマット])
+| 暗号化されたファイルのヘッダー
-| header  of  each encrypted file
+| EncFs コンテナのトップレベルにあるコントロールファイル
-| control file at the top level of each EncFs container
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
@@ 204行目: / 252行目: @@
 暗号鍵の保存場所
 | ?
-| with LUKS: LUKS header
+| LUKS を使用: LUKS ヘッダー
+| colspan="2" rowspan="1" | 何処にでも保存できるキーファイル
-| key file that can be stored anywhere
-| control file at the top level of each EncFs container
 |-
 | colspan="3" style="height:20px; border-color:transparent" |
@@ 216行目: / 263行目: @@
 ! scope="col" style="background:#E2E2E2" | Loop-AES
 ! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
-! scope="col" style="background:#E2E2E2" | Truecrypt
+! scope="col" style="background:#E2E2E2" | TrueCrypt
+! scope="col" style="background:#E2E2E2" | VeraCrypt
 ! scope="col" style="background:#E2E2E2" | eCryptfs
 ! scope="col" style="background:#E2E2E2" | EncFs
@@ 223行目: / 271行目: @@
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 ファイルのメタデータ (ファイルの数, ディレクトリ構造, ファイルサイズ, パーミッション, 更新時刻など) の暗号化
-| colspan="3" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+| colspan="4" | <span style="font-size:210%; color:#5F9E23;">✔</span>
-| colspan="2" | <span style="font-size:160%; color:#CF2525;">✖</span><br>''(file and dir names can be encrypted though)''
+| colspan="2" | <span style="font-size:160%; color:#CF2525;">✖</span><br>''(ファイルやディレクトリの名前は暗号化できます)''
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 (パーティションテーブルを含む) ハードドライブ全体の暗号化
-| colspan="3" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+| colspan="4" | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | colspan="2" | <span style="font-size:160%; color:#CF2525;">✖</span>
 |- valign="top"
@@ 235行目: / 283行目: @@
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 スワップ領域の暗号化
-| colspan="3" | <span style="font-size:210%; color:#5F9E23;">✔</span>
+| colspan="4" | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | colspan="2" | <span style="font-size:160%; color:#CF2525;">✖</span>
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+あらかじめ特定のサイズのスペースを暗号化データコンテナに割り当てなくても使用できるか
-can be used without pre-allocating a fixed amount of space for the encrypted data container
-| colspan="3" | <span style="font-size:160%; color:#CF2525;">✖</span>
+| colspan="4" | <span style="font-size:160%; color:#CF2525;">✖</span>
 | colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+ブロックデバイスにアクセスできない既存のファイルシステム (NFS や Samba の共有、クラウドストレージなど) の保護に使用できるか
-can be used to protect existing filesystems without block device access, e.g. NFS or Samba shares, cloud storage, etc.
-| colspan="3" | &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:160%; color:#CF2525;">✖</span><sup>[[#Notes_.26_References|[2]]]</sup>
+| colspan="4" | &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:160%; color:#CF2525;">✖</span><sup>[[#参照|[2]]]</sup>
 | colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+暗号化されたファイルのファイルベースのオフラインバックアップ
-allows offline file-based backups of encrypted files
-| colspan="3" | <span style="font-size:160%; color:#CF2525;">✖</span>
+| colspan="4" | <span style="font-size:160%; color:#CF2525;">✖</span>
 | colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
 |-
@@ 263行目: / 311行目: @@
 ! scope="col" style="background:#E2E2E2" | Loop-AES
 ! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
-! scope="col" style="background:#E2E2E2" | Truecrypt
+! scope="col" style="background:#E2E2E2" | TrueCrypt
+! scope="col" style="background:#E2E2E2" | VeraCrypt
 ! scope="col" style="background:#E2E2E2" | eCryptfs
 ! scope="col" style="background:#E2E2E2" | EncFs
@@ 272行目: / 321行目: @@
 | ?
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
-| ?
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
@@ 279行目: / 329行目: @@
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 アイドル状態による自動アンマウントのサポート
+| ?
 | ?
 | ?
@@ 291行目: / 342行目: @@
 | <span style="font-size:160%; color:#CF2525;">✖</span>
 | <span style="font-size:160%; color:#CF2525;">✖</span>
+| <span style="font-size:160%; color:#CF2525;">✖</span>
-| limited
+| 制限あり
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 |- valign="top"
@@ 299行目: / 351行目: @@
 | <span style="font-size:160%; color:#CF2525;">✖</span>
 | <span style="font-size:160%; color:#CF2525;">✖</span>
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:160%; color:#CF2525;">✖</span>
@@ 311行目: / 364行目: @@
 ! scope="col" style="background:#E2E2E2" | Loop-AES
 ! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
-! scope="col" style="background:#E2E2E2" | Truecrypt
+! scope="col" style="background:#E2E2E2" | TrueCrypt
+! scope="col" style="background:#E2E2E2" | VeraCrypt
 ! scope="col" style="background:#E2E2E2" | eCryptfs
 ! scope="col" style="background:#E2E2E2" | EncFs
@@ 319行目: / 373行目: @@
 サポートされている暗号
 | AES
-| AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish, … (カーネルの Crypto API が用意している全ての暗号)
+| AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish, ... (カーネルの Crypto API が用意している全ての暗号)
 | AES, Twofish, Serpent
+| AES, Twofish, Serpernt, Camellia, Kuznyechik
 | AES, Blowfish, Twofish...
-| AES, Blowfish
+| AES, Blowfish, Twofish, その他システムで使える暗号
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
@@ 328行目: / 383行目: @@
 ソルティングのサポート
 | ?
-| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(with LUKS)
+| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(LUKS を使用)
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
@@ 337行目: / 393行目: @@
 複数の暗号による多段処理のサポート
 | ?
+| 複数のブロックデバイスを段階的に暗号化することは可能
-| Not in one device, but blockdevices can be cascaded
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | ?
@@ 346行目: / 403行目: @@
 キースロットの拡散のサポート
 | ?
-| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(with LUKS)
+| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(LUKS を使用)
+| ?
 | ?
 | ?
@@ 355行目: / 413行目: @@
 キースクラブに対する保護
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
-| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(without LUKS)
+| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(LUKS を使用しない)
+| ?
 | ?
 | ?
@@ 362行目: / 421行目: @@
 | style="border-left-color:transparent; border-bottom-color:transparent" |
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+同一の暗号化されたデータに対して複数のキー (別個に無効にできる) のサポート
-support for multiple (independently revokable) keys for the same encrypted data
+| ?
+| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(LUKS を使用)
 | ?
-| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(with LUKS)
 | ?
 | ?
@@ 377行目: / 437行目: @@
 ! scope="col" style="background:#E2E2E2" | Loop-AES
 ! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
-! scope="col" style="background:#E2E2E2" | Truecrypt
+! scope="col" style="background:#E2E2E2" | TrueCrypt
+! scope="col" style="background:#E2E2E2" | VeraCrypt
 ! scope="col" style="background:#E2E2E2" | eCryptfs
 ! scope="col" style="background:#E2E2E2" | EncFs
@@ 385行目: / 446行目: @@
 マルチスレッドのサポート
 | ?
-| <span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[8]]]</sup>
+| <span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#参照|[8]]]</sup>
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | ?
@@ 397行目: / 459行目: @@
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
-| <span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[13]]]</sup>
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
+| <span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#参照|[13]]]</sup>
 |-
 | colspan="3" style="height:20px; border-color:transparent" |
-| colspan="3" style="border-right-color:transparent" |
+| colspan="4" style="border-right-color:transparent" |
 | colspan="2" style="border-color:transparent" |
 |-
@@ 408行目: / 471行目: @@
 ! scope="col" style="background:#E2E2E2" | Loop-AES
 ! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
-! scope="col" style="background:#E2E2E2" | Truecrypt
+! scope="col" style="background:#E2E2E2" | TrueCrypt
+! scope="col" style="background:#E2E2E2" | VeraCrypt
 | colspan="2" rowspan="2" style="border-color:transparent" |
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
 ! scope="row" colspan="2" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+所定の暗号化済みのブロックデバイスを (手動で) リサイズすることのサポート
-support for (manually) resizing the encrypted block device in-place
 | ?
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
+| <span style="font-size:160%; color:#CF2525;">✖</span>
 | <span style="font-size:160%; color:#CF2525;">✖</span>
 |-
 | colspan="3" style="height:20px; border-color:transparent" |
-| colspan="3" style="border-color:transparent" |
+| colspan="4" style="border-color:transparent" |
 | colspan="2" style="border-right-color:transparent" |
 |-
-| colspan="6" style="border-left-color:transparent; text-align:left;" |
+| colspan="7" style="border-left-color:transparent; text-align:left;" |
 =====''スタックファイルシステム暗号化特有の事項''=====
 ! scope="col" style="background:#E2E2E2" | eCryptfs
@@ 428行目: / 493行目: @@
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
-! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+! scope="row" colspan="6" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 サポートされるファイルシステム
-| ext3, ext4, xfs (with caveats), jfs, nfs...
+| ext3, ext4, xfs (注意事項あり), jfs, nfs...
+| ext3, ext4, xfs (with caveats), jfs, nfs, cifs...[https://github.com/vgough/encfs]
-| ?
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
-! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+! scope="row" colspan="6" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 ファイル名の暗号化
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
@@ 440行目: / 505行目: @@
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
-! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+! scope="row" colspan="6" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 ファイル名の暗号化を''しない''機能
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
@@ 446行目: / 511行目: @@
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
-! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
+! scope="row" colspan="6" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 スパースファイルの最適化処理
 | <span style="font-size:160%; color:#CF2525;">✖</span>
@@ 459行目: / 524行目: @@
 ! scope="col" style="background:#E2E2E2" | Loop-AES
 ! scope="col" style="background:#E2E2E2" | dm-crypt +/- LUKS
-! scope="col" style="background:#E2E2E2" | Truecrypt
+! scope="col" style="background:#E2E2E2" | TrueCrypt
+! scope="col" style="background:#E2E2E2" | VeraCrypt
 ! scope="col" style="background:#E2E2E2" | eCryptfs
 ! scope="col" style="background:#E2E2E2" | EncFs
@@ 468行目: / 534行目: @@
 | 2.0 以上
 | CBC モード 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24
+| ?
 | ?
 | ?
@@ 475行目: / 542行目: @@
 ! scope="row" rowspan="3" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" | 暗号化されたデータにアクセスできるオペレーティングシステム
 ! scope="row" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" | Windows
-| <span style="font-size:210%; color:#5F9E23;">✔</span> (with <sup>[[#Notes_.26_References|[3]]]</sup>)
+| <span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#参照|[3]]]</sup>
-| <span style="font-size:210%; color:#5F9E23;">✔</span> (with <sup>[[#Notes_.26_References|[4]]]</sup>)
+| ?<sup>[[#参照|[4]]]</sup>
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | ?
-| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[9]]]</sup>
+| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#参照|[9]]]</sup>
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
-! scope="row" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" | Mac OS X
+! scope="row" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" | macOS
 | ?
 | ?
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
 | <span style="font-size:210%; color:#5F9E23;">✔</span>
 | ?
-| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[5]]]</sup>
+| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#参照|[5]]]</sup>
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
@@ 493行目: / 562行目: @@
 | ?
 | ?
-| <span style="font-size:160%; color:#CF2525;">✖</span>
+| <span style="font-size:210%; color:#5F9E23;">✔</span><br>(VeraCrypt を使用)
+| <span style="font-size:210%; color:#5F9E23;">✔</span>
 | ?
-| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#Notes_.26_References|[6]]]</sup>
+| &nbsp;&nbsp;&nbsp;&nbsp;<span style="font-size:210%; color:#5F9E23;">✔</span><sup>[[#参照|[6]]]</sup>
 |- valign="top"
 | style="border-left-color:transparent; border-bottom-color:transparent" |
@@ 504行目: / 574行目: @@
 * Debian/Ubuntu インストーラ (システム暗号化)
 * Fedora インストーラ
+| ?
 | ?
 |
 * Ubuntu インストーラ (ホームディレクトリの暗号化)
-* Chromium OS (キャッシュされたユーザーデータの暗号化<sup>[[#Notes_.26_References|[7]]]</sup>)
+* Chromium OS (キャッシュされたユーザーデータの暗号化<sup>[[#参照|[7]]]</sup>)
 | ?
 |}
@@ 515行目: / 586行目: @@
 ===セットアップの選択===
-どのディスク暗号化をセットアップするのが適切なのかはあなたの目的 (上の [[#なぜ暗号化を使うのか？]] を読んで下さい) とシステムパラメータによって様々です。<br>
+どのディスク暗号化をセットアップするのが適切なのかはあなたの目的 (上の [[#なぜ暗号化を使うのか?]] を読んで下さい) とシステムパラメータによって様々です。<br>
 とりわけ、以下の質問に答える必要があるでしょう:
 <ul>
-<li>あなたが見を守りたいのはどのような"攻撃者"からか？
+<li>あなたが身を守りたいのはどのような"攻撃者"からか?
 <ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+<li>システムの電源がオフになっていたり盗まれたりしたときにディスクを詮索するカジュアルなコンピュータユーザー</li>
-<li>Casual computer user snooping around your disk when your system is turned off / stolen / etc.</li>
+<li>あなたがシステムを使用する前後に繰り返しシステムに読み書きアクセスをすることができるプロの暗号解読者</li>
-<li>Professional cryptanalyst who can get repeated read/write access to your system before and after you use it</li>
-<li>anything in between</li>
+<li>その中間</li>
 </ul></li>
 </ul>
 <ul>
-<li>どの暗号化ストラテジーを使用するのか？
+<li>どの暗号化ストラテジーを使用するのか?
 <ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
-<li>data encryption</li>
+<li>データ暗号化</li>
-<li>system encryption</li>
+<li>システム暗号化</li>
-<li>something in between</li>
+<li>その中間</li>
 </ul></li></ul>
 <ul>
-<li>スワップや {{ic|/tmp}} などはどうすればいいか？
+<li>スワップや {{ic|/tmp}} などはどうすればいいか?
 <ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+<li>無視する、データが流出しないことを祈る</li>
-<li>ignore, and hope no data is leaked</li>
+<li>無効化する、または ramdisk としてマウント</li>
-<li>disable or mount as ramdisk</li>
+<li>暗号化する ''(完全なディスク暗号化の一部として、または別個に暗号化)''</li>
-<li>encrypt ''(as part of full disk encryption, or separately)''</li>
 </ul></li></ul>
 <ul>
-<li>どうやってディスクの暗号化された部分を解除するか？
+<li>どうやってディスクの暗号化された部分を解除するか?
 <ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
+<li>パスフレーズ ''(ログインパスワードと同じパスワード、または別個のパスワード)''</li>
-<li>passphrase ''(same as login password, or separate)''</li>
+<li>キーファイル ''(例: 安全な場所に置いたり常に持ち歩いている USB スティックに保存)''</li>
-<li>keyfile ''(e.g. on a USB stick, that you keep in a safe place or carry around with yourself)''</li>
-<li>both</li>
+<li>両方</li>
 </ul></li>
 </ul>
 <ul>
-<li>ディスクの暗号化された部分を解除するのは''いつ''か？
+<li>ディスクの暗号化された部分を解除するのは''いつ''か?
 <ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
-<li>before boot</li>
+<li>起動する前</li>
-<li>during boot</li>
+<li>起動中</li>
-<li>at login</li>
+<li>ログイン時</li>
+<li>''(ログイン後に)'' 必要に応じて手動で</li>
-<li>manually on demand ''(after login)''</li>
 </ul></li>
 </ul>
 <ul>
-<li>複数のユーザーに便宜をはかるにはどうすればいいか？
+<li>複数のユーザーに便宜をはかるにはどうすればいいか?
 <ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
-<li>not at all</li>
+<li>気にしない</li>
+<li>パスフレーズ/キーを共有する</li>
-<li>using a shared passphrase/key</li>
+<li>ディスクの同一の暗号化部分に対して別個に発行・無効化できるパスフレーズ/キーを使う</li>
-<li>idependently issued and revocable passphrases/keys for the same encrypted part of the disk</li>
+<li>ユーザーごとにディスクの暗号化部分を分ける</li>
-<li>separate encrypted parts of the disk for different users</li>
 </ul></li>
 </ul>
@@ 576行目: / 647行目: @@
 * スタックファイルシステムの暗号化 vs. ブロックデバイスの暗号化
 * キーの管理
-* 暗号と利用形態
+* 暗号と利用モード
 * メタデータの保管
 * "下位ディレクトリ"の場所 (スタックファイルシステムの暗号化を使う場合)
+実際にやってみると、以下のような取り合わせが考えられると思われます:
-In practice, it could turn out something like:
+;例 1: [[EncFS]] を使ってユーザーのホームディレクトリに "~/Private" という仮想フォルダを作って暗号化する、シンプルなデータ暗号化 (内蔵ハードドライブ)<span style="color:#777"><br>└──> ~/.Private のファイルは暗号化されてディスク上に保存されます<br>└──> 必要に応じて専用のパスフレーズでロックを解除します</span><br>
-;Example 1: simple data encryption (internal hard drive) using a virtual folder called "~/Private" in the user's home dir encrypted with [[EncFS]]<span style="color:#777"><br>└──> encrypted versions of the files stored on-disk in ~/.Private<br>└──> unlocked on demand with dedicated passphrase</span><br>
-;Example 2: simple data encryption (removable media), an USB drive encrypted with [[TrueCrypt]]<span style="color:#777"><br>└──> unlocked when attached to the computer (using dedicated passphrase + using ~/photos/2006-09-04a.jpg as covert keyfile)</span>
+;例 2: [[TrueCrypt]] で暗号化した USB ドライブによる、シンプルなデータ暗号化 (リムーバブルメディア)<span style="color:#777"><br>└──> コンピュータに接続したときにロックを解除します (専用のパスフレーズと、キーファイルを変換した ~/photos/2006-09-04a.jpg を使用)</span>
-;Example 3: partial system encryption with each user's '''home directory''' encrypted with [[ECryptfs]]<span style="color:#777"><br>└──> unlocked on respective user login, using login passphrase<br>└──> '''swap''' and '''/tmp''' partitions encrypted with [[dm-crypt|Dm-crypt with LUKS]], using an automatically generated per-session throwaway key<span style="color:#777"><br>└──> indexing/caching of contents of /home by slocate (and similar apps) disabled.
+;例 3: [[ECryptfs]] でそれぞれのユーザーの''ホームディレクトリ''を暗号化する、部分的なシステム暗号化<span style="color:#777"><br>└──> 各々のユーザーのログイン時に、ログインパスフレーズを使ってロックを解除します<br>└──> ''スワップ''と ''/tmp'' パーティションは [[dm-crypt|Dm-crypt と LUKS]] で暗号化して、セッションごとに自動生成される使い捨てのキーを使用<span style="color:#777"><br>└──> slocate (やその他のアプリ) による /home の中身のインデックス作成/キャッシュは無効にする
-;Example 4: system encryption - whole hard drive except /boot partition encrypted with [[dm-crypt|Dm-crypt with LUKS]] <span style="color:#777"><br>└──> unlocked during boot, using passphrases or USB stick with keyfiles<br>└──> Maybe different passphrases/keys per user - independently revocable<br>└──> Maybe encryption spanning multiple drives or partition layout flexibility with [[Dm-crypt/Encrypting an entire system#LUKS on LVM|LUKS on LVM]]</span>
+;例 4: システム暗号化 - /boot パーティションを除いてハードドライブ全体を [[dm-crypt|Dm-crypt と LUKS]] で暗号化 <span style="color:#777"><br>└──> 起動中に、パスフレーズまたはキーファイルが保存された USB スティックを使ってロックを解除します<br>└──> ユーザーごとに別々のパスフレーズ/キーを使用 - 別個に無効化可能<br>└──> [[Dm-crypt/システム全体の暗号化#LUKS on LVM|LUKS を LVM 上に配置]]して複数のドライブを跨ったりするパーティションレイアウトにおける暗号化の柔軟性を確保</span>
-;Example 5: hidden/plain system encryption - whole hard drive encrypted with [[dm-crypt|plain dm-crypt]] <span style="color:#777"><br>└──> USB-boot, using dedicated passphrase + USB stick with keyfile<br>└──> data integrity checked before mounting<br>└──> /boot partition located on aforementioned USB stick</span>
+;例 5: 徹底して隠されたシステム暗号化 - [[dm-crypt|plain dm-crypt]] によるハードドライブ全体の暗号化 <span style="color:#777"><br>└──> 専用のパスフレーズとキーファイルが入った USB スティックを使用して USB ブート<br>└──> マウントする前にデータの状態をチェックします<br>└──> /boot パーティションは先の USB スティック上に配置</span>
+もちろん他にも様々な組み合わせが考えられます。あなたのシステムにとってどのようなセットアップが適切か注意深く計画を練って下さい。
-Many other combinations are of course possible. You should carefully plan what kind of setup will be appropriate for your system.
 ===強固なパスフレーズの選択===
-[[Security (日本語)#パスワード|セキュリティ#パスワード]] を見て下さい。
+[[セキュリティ#パスワード]]を見てください。
 ===ディスクの準備===
+ディスク (の一部) に暗号化をセットアップする前に、まず確実にディスクを消去するようにしてください。ディスクを消去する際にはドライブ全体またはパーティション全体をゼロバイトやランダムなバイトのストリームで上書きします。これを行う理由は以下の通り:
-Before setting up disk encryption on a (part of a) disk, consider securely wiping it first. This consists of overwriting the entire drive or partition with a stream of zero bytes or random bytes, and is done for one or both of the following reasons:
 <ul>
-<li><p>'''prevent recovery of previously stored data'''</p>
+<li><p>'''以前に保存されていたデータのリカバリを防ぐ'''</p>
+たとえディスクを暗号化したとしても、実際のセクタは必要に応じて、ファイルシステムが特定のセクタにデータを作成したり修正したときにしか上書きされることはありません (下の [[#暗号化の仕組み]] を参照)。ファイルシステムから"使用されていない"セクタは弄られることがないため、前に使っていたファイルシステムのデータが残ってしまっている可能性があります。先にドライブに保存していたデータを完全に[[Wikipedia:Data_recovery|リカバリ]]不可能にするには、手動でデータを消去するしか道はないでしょう。<br>データを完全に消去するということについては、ゼロバイトを使用するかランダムバイトを使用するかの違いはありません (ゼロバイトで消去するほうが高速です)。
-Disk encryption doesn't change the fact that individual sectors are only overwritten on demand, when the file system creates or modifies the data those particular sectors hold (see [[#How_the_encryption_works]] below). Sectors which the filesystem considers "not currently used" are not touched, and may still contain remnants of data from previous filesystems. The only way to make sure that all data which you previously stored on the drive can not be [[Wikipedia:Data_recovery|recovered]], is to manually erase it.<br>
-For this purpose it does not matter whether zero bytes or random bytes are used (although wiping with zero bytes will be much faster).
 </li>
-<li><p>'''prevent disclosure of usage patterns on the encrypted drive'''</p>
+<li><p>'''暗号化されたドライブの利用状況の発覚を防ぐ'''</p>
+理想を言えば、ディスクの暗号化部分はランダムなデータと区別を付かないようにするほうが望ましいでしょう。暗号化データを含んでいるセクタの数を知ることができなくなるということ自体が (完全な機密性を確保する上で) 好ましいですし、暗号化を解除しようと試みる攻撃者に対してセキュリティを増すことにもつながります。<br>利用状況の発覚を防ぐということに関しては、高品質なランダムバイトを使用してディスクを消去するのが重要です。
-Ideally, the whole encrypted part of the disk should be indistinguishable from uniformly random data. This way, no unauthorized person can know which and how many sectors actually contain encrypted data - which may be a desirable goal in itself (as part of true confidentiality), and also serves as an additional barrier against attackers trying to break the encryption.<br>
-In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.
 </li>
 </ul>
+二番目の理由はブロックデバイスの暗号化をしている場合にのみ意味をなします。スタックファイルシステムの暗号化では簡単に暗号化データを突き止められてしまいます (ホストファイルシステムに暗号化されたファイルがあることは隠しようがありません)。また、たとえ特定のフォルダだけを暗号化したいという場合でも、暗号化されてない状態でフォルダに保存されていたファイルを削除するためには ([[Wikipedia:ja:フラグメンテーション|断片化]]している可能性があるため) パーティション全体を消去する必要があります。同一パーティションに別のフォルダが存在する場合、一度バックアップして、削除してから元のパーティションに戻すようにします。
-The second goal only makes sense in combination with block device encryption, because in the case of stacked filesystem encryption the encrypted data can easily be located anyways (in the form of distinct encrypted files in the host filesystem). Also note that even if you only intend to encrypt a particular folder, you will have to erase the whole partition if you want to get rid of files that were previously stored in that folder in unencrypted form (due to [[Wikipedia::File_system_fragmentation|disk fragmentation]]). If there are other folders on the same partition, you will have to back them up and move them back afterwards.
+ディスク消去することを決めたら、[[ディスクの完全消去]]の記事を参照してください。
-Once you have decided which kind of disk erasure you want to perform, refer to the [[Securely_wipe_disk]] article for technical instructions.
+{{Tip|ハードディスクドライブを完全に消去する方法を決めるときは、暗号化ドライブとして使用する以上、消去をするのは一回だけで十分だということを覚えておいてください。}}
-{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}
 ==暗号化の仕組み==
+このセクションは、一般的なディスク暗号化の心臓部である仕組みと方法についての高レベルなイントロダクションです。
-This section is intended as a high-level introduction to the concepts and processes which are at the heart of usual disk encryption setups.
+技術的数学的な詳細にまで立ち入ることはありませんが (適当な技術書を読んで下さい)、システム管理者が理解しておくべき、暗号化セットアップの選択がユーザビリティやセキュリティにどう影響をあたえるのかという基礎知識を提供します。
-It does not go into technical or mathematical details (consult the appropriate literature for that), but should provide a system administrator with a rough understanding of how different setup choices (especially regarding key management) can affect usability and security.
 ===基本原理===
+ディスクを暗号化するとき、各ブロックデバイス (スタックファイルシステムの暗号化の場合、個々のファイル) は等長の'''セクタ'''に分割されます。例えば512バイト (4096ビット) など。暗号化・復号化はセクタ単位で行われるので、ディスク上のブロックデバイスやファイルの n 番目のセクタには、元のデータの n 番目のセクタを暗号化したものが保存されます。
-For the purposes of disk encryption, each blockdevice (or individual file in the case of stacked filesystem encryption) is divided into '''sectors''' of equal length, for example 512 bytes (4,096 bits). The encryption/decryption then happens on a per-sector basis, so the n'th sector of the blockdevice/file on disk will store the encrypted version of the n'th sector of the original data.
+オペレーティングシステムやアプリケーションがブロックデバイス・ファイルから特定のデータを要求した場合、そのデータが含まれているセクタ全体がディスクから読み込まれて、即座に復号化され、一時的にメモリに保存されます:
-Whenever the operating system or an application requests a certain fragment of data from the blockdevice/file, the whole sector (or sectors) that contains the data will be read from disk, decrypted on-the-fly, and temporarily stored in memory:
            ╔═══════╗
@@ 648行目: / 717行目: @@
         file on disk
+同じように、書き込み操作のときは、該当箇所のセクタが全て再暗号化されます (他のセクタに変更が加えられることはありません)。
-Similarly, on each write operation, all sectors that are affected must be re-encrypted complelety (while the rest of the sectors remain untouched).
+データを暗号化・復号化するために、ディスク暗号化システムはディスクに関連付けられたユニークな秘密鍵を知る必要があります。暗号化されたブロックデバイスやフォルダをマウントするには、適切な鍵が必要です (以後「マスター鍵」と呼びます)。
-In order to be able to de/encrypt data, the disk encryption system needs to know the unique secret "key" associated with it. Whenever the encrypted block device or folder in question is to be mounted, its corresponding key (called henceforth its "master key") must be supplied.
+暗号化のセキュリティでは鍵のエントロピーが一番重要です。ランダムに生成された一定の長さ (例えば32バイト=256ビット) のバイト文字列が望ましいですが、覚えづらい上にマウント時に手動で入力するのは苦痛です。
-The entropy of the key is of utmost importance for the security of the encryption. A randomly generated byte string of a certain length, for example 32 bytes (256 bits), has desired properties but is not feasible to remember and apply manually during the mount.
+そこで2つの方法があります。1番目の方法はマスター鍵のエントロピーを増大させる暗号化アプリケーションです。通常は人間が扱える程度のパスフレーズが用いられます。様々なタイプの暗号化方法があり[[#比較表|比較表]]ではそれぞれの特徴を列記しています。そして、2番目の方法は高エントロピーのキーファイルを作成して暗号化するデータドライブとは別のメディアに保存する方式です。
-For that reason two techniques are used as aides. The first is the application of cryptography to increase the entropic property of the master key, usually involving a separate human-friendly passphrase. For the different types of encryption the [[#Comparison_table]] lists respective features. The second method is to create a keyfile with high entropy and store it on a medium separate from the data drive to be encrypted.
-''Further reading:''
+''参照:''
-* [[Wikipedia:Authenticated_encryption]]
+* [[Wikipedia:ja:認証付き暗号]]
-===キーとキーファイルとパスフレーズ===
+===鍵とキーファイルとパスフレーズ===
+以下はキーファイルでマスター鍵を安全に保存する方法の例です:
-The following are examples how to store and cryptographically secure a master key with a keyfile:
 <ul>
-<li><p>'''''stored in a plaintext keyfile'''''</p>
+<li><p>'''''プレーンテキストのキーファイルに保存'''''</p>
+マスター鍵をファイルに保存するのは最も単純な方法です。ファイル (キーファイル) は USB メモリなどに保存して、安全な場所に保管しておき、ディスク上の暗号データをマウントしたいときだけコンピュータに接続します (例: 起動時やログイン時)。
-Simply storing the master key in a file (in readable form) is the simplest option. The file - called a "keyfile" - can be placed on a USB stick that you keep in a secure location and only connect to the computer when you want to mount the encrypted parts of the disk (e.g. during boot or login).
 </li>
+<li><p>'''''パスフレーズで保護したキーファイルあるいはディスクに保存'''''</p>
-<li><p>'''''stored in passphrase-protected form in a keyfile or on the disk itself'''''</p>
+マスター鍵 (と暗号データ) は秘密のパスフレーズで保護することができます。暗号化したブロックデバイスやフォルダをマウントするたびに思い出して入力する必要があります。詳しくは下の[[#暗号メタデータ]]を見てください。
-The master key (and thus the encrypted data) can be protected with a secret passphrase, which you will have to remember and enter each time you want to mount the encrypted block device or folder. See [[#Cryptographic metadata]] below for details.
-<li><p>'''''randomly generated on-the-fly for each session'''''</p>
+<li><p>'''''セッションごとにランダムに生成'''''</p>
+スワップ領域や {{ic|/tmp}} パーティションを暗号化する場合など、ときとしてマスター鍵を必ずしも保存しなくてよい場合があります。セッション毎に使い捨てのキーをランダムに生成するのであれば、ユーザーが何かする必要はありません。その場合、パーティションをアンマウントするとパーティションに書き込まれたデータを誰も復号化できなくなります。暗号化するのが一時ファイルなどの場合はそれで特に問題ありません。
-In some cases, e.g. when encrypting swap space or a {{ic|/tmp}} partition, it is not necessary to keep a persistent master key at all. A new throwaway key can be randomly generated for each session, without requiring any user interaction. This means that once unmounted, all files written to the partition in question can never be decrypted again by ''anyone'' - which in those particular use-cases is perfectly fine.
 </li>
 </ul>
@@ 681行目: / 750行目: @@
 ===暗号メタデータ===
+暗号技術ではマスター鍵のセキュリティを守るために暗号化関数がよく使われます。暗号化されたデバイスがマウントされたとき、パスフレーズやキーファイルを暗号化関数に入れて、出てきた計算結果を使ってマスター鍵を解錠してデータを復号化します。
-Frequently the encryption techniques use cryptographic functions to enhance the security of the master key itself. On mount of the encrypted device the passphrase or keyfile is passed through these and only the result can unlock the master key to decrypt the data.
+一般的なのはパスフレーズのいわゆる「キーストレッチング」です (「鍵導出関数」が使用されます)。パスフレーズはマウントキーとして使用し、実際のマスター鍵を復号化するのに使われます (マスター鍵は暗号化された状態で保存されます):
-A common setup is to apply so-called "key stretching" to the passphrase (via a "key derivation function"), and use the resulting enhanced passphrase as the mount key for decrypting the actual master key (which has been previously stored in encrypted form):
 <pre>
@@ 697行目: / 766行目: @@
 </pre>
+'''鍵導出関数''' (例: PBKDF2 や scrypt) は意図的に低速にしか動作しないようになっており (ハッシュ関数を何度も繰り返し使用します、例えば HMAC-SHA-512 を1000回実行)、総当り攻撃によってパスフレーズを見つけ出すことが事実上不可能です。正しいパスワードを持っているユーザーの場合、計算する必要があるのは一度だけなので、多少遅くても問題になりません。
-The '''key derivation function''' (e.g. PBKDF2 or scrypt) is deliberately slow (it applies many iterations of a hash function, e.g. 1000 iterations of HMAC-SHA-512), so that brute-force attacks to find the passphrase are rendered infeasible. For the normal use-case of an authorized user, it will only need to be calculated once per session, so the small slowdown is not a problem.
-<br>It also takes an additional blob of data, the so-called "'''salt'''", as an argument - this is randomly generated once during set-up of the disk encryption and stored unprotected as part of the cryptographic metadata. Because it will be a different value for each setup, this makes it infeasible for attackers to speed up brute-force attacks using precomputed tables for the key derivation function.
+また、ディスク暗号化をセットアップするときにランダムに生成される "'''salt'''" を追加引数として使います。salt は暗号メタデータに含まれ暗号化されていない状態で保存されます。セットアップのたびに異なる値となるため、あらかじめ計算済みのテーブルを使って鍵導出関数に対して総当り攻撃をすることが不可能になります。
-The '''encrypted master key''' can be stored on disk together with the encrypted data. This way, the confidentiality of the encrypted data depends completely on the secret passphrase.
+'''暗号化されたマスター鍵'''は暗号化されたデータと一緒にディスク上に保存するため、暗号化データの機密性は完全に秘密のパスフレーズに依存します。
-Additional security can be attained by instead storing the encrypted master key in a keyfile on e.g. a USB stick. This provides '''two-factor authentication''': Accessing the encrypted data now requires something only you ''know'' (the passphrase), and additionally something only you ''have'' (the keyfile).
+USB スティックなどのキーファイルに暗号化したマスター鍵を保存することでセキュリティをさらに向上させることも可能です。いわゆる'''二段階認証'''です: 暗号化されたデータにアクセスするにはあなただけが知っているもの (パスフレーズ) に加えて、あなただけが持っているもの (キーファイル) も必要となります。
-Another way of achieving two-factor authentication is to augment the above key retrieval scheme to mathematically "combine" the passphrase with byte data read from one or more external files (located on a USB stick or similar), before passing it to the key derivation function.<br>The files in question can be anything, e.g. normal JPEG images, which can be beneficial for [[#Plausible deniability]]. They are still called "keyfiles" in this context, though.
+二段階認証を実現する他の方法として、上記の鍵導出を強化してパスフレーズと (USB スティックなどに保存した) 外部のファイルに含まれるバイトデータを数学的に「ミックス」してから鍵導出関数に渡すという手段もあります。使用するファイルは何でもかまいません。通常の JPEG 画像などであれば[[#もっともらしい否認]]にも有効でしょう。画像ではありますが、ここでは同じ「キーファイル」となります。
-After it has been derived, the master key is securely stored in memory (e.g. in a kernel keyring), for as long as the encrypted block device or folder is mounted.
+導出したマスター鍵は暗号化ブロックデバイスやフォルダがマウントされている間だけ、メモリ上に安全に保管されます (カーネルのキーリングなど)。
-It is usually not used for de/encrypting the disk data directly, though.
-For example, in the case of stacked filesystem encryption, each file can be automatically assigned its own encryption key. Whenever the file is to be read/modified, this file key first needs to be decrypted using the main key, before it can itself be used to de/encrypt the file contents:
+通常はディスクデータを暗号化・復号化するのにマスター鍵が直接使われることはありません。例えば、スタックファイルシステム暗号化の場合、ファイルにはそれぞれ別々の暗号鍵が自動的に割り当てられます。ファイルを読み書きしたくなったら、最初にメイン鍵を使ってファイルの鍵を復号化してから、ファイルの中身が復号化・暗号化できるようになります:
                            ╭┈┈┈┈┈┈┈┈┈┈┈┈╮
@@ 724行目: / 793行目: @@
   └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
+同じように、スタックファイルシステム暗号化の場合、ファイル名を暗号化するときは別の鍵 (例: フォルダごとに割り振られた鍵) が使われます。
-In a similar manner, a separate key (e.g. one per folder) may be used for the encryption of file names in the case of stacked filesystem encryption.
+ブロックデバイス暗号化の場合、デバイスごと、つまり全てのデータで使われるのはひとつのマスター鍵です。一部のブロックデバイス暗号化では同一デバイスに複数のパスフレーズやキーファイルを割り当てることができますが、できないものもあります。上記の関数を使ってマスター鍵を保全する場合もあればキーのセキュリティを完全にユーザーに委ねる場合もあります。例として [[dm-crypt]] の plain モードと LUKS モードで使用される暗号パラメータで説明しましょう。
-In the case of block device encryption one master key is used per device and, hence, all data. Some methods offer features to assign multiple passphrases/keyfiles for the same device and others not. Some use above mentioned functions to secure the master key and others give the control over the key security fully to the user. Two examples are explained by the cryptographic parameters used by [[dm-crypt]] in plain or LUKS modes.
+両方のモードで使用するパラメータを比較すると、dm-crypt の plain モードではキーファイルの場所に関するパラメータがあることに気づくでしょう (例: {{ic|--keyfile-size}}, {{ic|--keyfile-offset}})。dm-crypt の LUKS モードではキーファイルの場所を指定する必要はありません。各ブロックデバイスのヘッダーに暗号のメタデータが含まれるためです。ヘッダーには使用する暗号、暗号化されたマスター鍵、そして鍵導出に必要なパラメータが存在します。最後のパラメータは最初にマスター鍵を暗号化したときに使用したオプションから生成されます (例: {{ic|--iter-time}}, {{ic|--use-random}})。
-When comparing the parameters used by both modes one notes that dm-crypt plain mode has parameters relating to how to locate the keyfile (e.g. {{ic|--keyfile-size}}, {{ic|--keyfile-offset}}). The dm-crypt LUKS mode does not need these, because each blockdevice contains a header with the cryptographic metadata at the beginning. The header includes the used cipher, the encrypted master-key itself and parameters required for its derivation for decryption. The latter parameters in turn result from options used during initial encryption of the master-key [e.g. {{ic|--iter-time}}, {{ic|--use-random}}).
+暗号化手段のメリット・デメリットについては[[#比較表]]やそれぞれのページを参照してください。
-For the dis-/advantages of the different techniques, please refer back to [[#Comparison_table]] or browse the specific pages.
-''Further reading:''
+''参照:''
-* [[Wikipedia:Passphrase]]
+* [[Wikipedia:ja:パスワード]]
-* [[Wikipedia:Key_(cryptography)]]
+* [[Wikipedia:ja:鍵 (暗号)]]
 * [[Wikipedia:Key_management]]
-* [[Wikipedia:Key_derivation_function]]
+* [[Wikipedia:ja:鍵導出関数]]
-===暗号と利用形態===
+===暗号と利用モード===
+与えられた暗号鍵を使って実際に暗号化データと非暗号化データ (つまり"平文"と"暗号文") を変換するのに使われるアルゴリズムは "'''cipher'''" と呼ばれます。
-The actual algorithm used for translating between pieces of unencrypted and encrypted data (so-called "plaintext" and "ciphertext") which correspond to each other with respect to a given encryption key, is called a "'''cipher'''".
+ディスク暗号化では等長なブロックのデータを処理する"ブロック暗号" (block cipher) が用いられます。ブロック長は16バイト (128ビット) などになります。執筆時点で、主に使われている暗号は以下のとおり:
-Disk encryption employs "block ciphers", which operate on fixed-length blocks of data, e.g. 16 bytes (128 bits). At the time of this writing, the predominantly used ones are:
 {| class="wikitable" style="margin:0 5em 1.5em 5em;"
 ! scope="col" style="text-align:left" |
-! scope="col" style="text-align:left" | block&nbsp;size
+! scope="col" style="text-align:left" | ブロックサイズ
-! scope="col" style="text-align:left" | key&nbsp;size
+! scope="col" style="text-align:left" | キーサイズ
-! scope="col" style="text-align:left" | comment
+! scope="col" style="text-align:left" | 注記
 |-
-! scope="row" style="text-align:right" | [[Wikipedia:Advanced_Encryption_Standard|AES]]
+! scope="row" style="text-align:right" | [[Wikipedia:ja:Advanced_Encryption_Standard|AES]]
-| 128 bits
+| 128 ビット
-| 128, 192 or 256 bits
+| 128, 192, 256 ビット
+| ''アメリカ政府の "SECRET" または "TOP SECRET" の機密情報を保護するのに足ると NSA によって承認されています (192または256ビットのキーサイズの使用時)。''
-| ''approved by the NSA for protecting "SECRET" and "TOP SECRET" classified US-government information (when used with a key size of 192 or 256 bits)''
 |-
-! scope="row" style="text-align:right" | [[Wikipedia:Blowfish_%28cipher%29|Blowfish]]
+! scope="row" style="text-align:right" | [[Wikipedia:ja:Blowfish|Blowfish]]
-| 64 bits
+| 64 ビット
-| 32–448 bits
+| 32–448 ビット
+| ''初期のパテントフリーでセキュアな暗号の一つであり誰でも使えるため、Linux ではかなり定着しています。''
-| ''one of the first patent-free secure ciphers that became publicly available, hence very well established on Linux''
 |-
-! scope="row" style="text-align:right" | [[Wikipedia:Twofish|Twofish]]
+! scope="row" style="text-align:right" | [[Wikipedia:ja:Twofish|Twofish]]
-| 128 bits
+| 128 ビット
-| 128, 192 or 256 bits
+| 128, 192, 256 ビット
+| ''Blowfish の後継として開発されましたが、それほど幅広くは利用されていません。''
-| ''developed as successor of Blowfish, but has not attained as much widespread usage''
-|
 |-
-! scope="row" style="text-align:right" | [[Wikipedia:Serpent_%28cipher%29|Serpent]]
+! scope="row" style="text-align:right" | [[Wikipedia:ja:Serpent (暗号)|Serpent]]
-| 128 bits
+| 128 ビット
-| 128, 192 or 256 bits
+| 128, 192, 256 ビット
+| AES コンペティションの5つの最終候補の中で一番セキュアだと考えられています<sup>[[#参照|[10]]][[#参照|[11]]][[#参照|[12]]]</sup>。
-| Considered the most secure of the five AES-competition finalists<sup>[[#Notes_.26_References|[10]]][[#Notes_.26_References|[11]]][[#Notes_.26_References|[12]]]</sup>.
 |}
+セクタの暗号化・復号化 ([[#基本原理|上を参照]]) を行うときはセクタを暗号のブロックサイズにあわせて小さなブロックに分割します。個々のブロックに暗号をどのように適用していくかは特定のルールセット (いわゆる"'''暗号利用モード'''") に従います。
-Encrypting/decrypting a sector ([[#Basic principle|see above]]) is achieved by dividing it into small blocks matching the cipher's block-size, and following a certain rule-set (a so-called "'''mode of operation'''") for how to consecutively apply the cipher to the individual blocks.
+特に手を加えずにそれぞれのブロックを独立して暗号化するのはセキュアではありません ("''電子符号表 (electronic codebook, ECB)''" モードと呼ばれます)。平文で同じ16バイトのテキストがあれば、暗号文も常に同じになるため、ディスクに保存されている暗号文から簡単にパターンを見つけ出すことができてしまいます。
-Simply applying it to each block separately without modification (dubbed the "''electronic codebook (ECB)''" mode) would not be secure, because if the same 16 bytes of plaintext always produce the same 16 bytes of ciphertext, an attacker could easily recognize patterns in the ciphertext that is stored on disk.
+実際に広く使われている利用モードは "''暗号ブロック連鎖 (cipher-block chaining, CBC)''" です。CBC モードでセクタを暗号化した場合、平文データの各ブロックは前のブロックの暗号文と数学的に混ぜ合わされてから暗号化されます。最初のブロックは前の暗号文がないため、"'''初期化ベクトル (IV)'''" と呼ばれる暗号メタデータに保存されている特殊な事前生成済みのデータブロックが使われます:
-The most basic (and common) mode of operation used in practice is "''cipher-block chaining (CBC)''". When encrypting a sector with this mode, each block of plaintext data is combined in a mathematical way with the ciphertext of the previous block, before encrypting it using the cipher. For the first block, since it has no previous ciphertext to use, a special pre-generated data block stored with the sector's cryptographic metadata and called an "'''initialization vector (IV)'''" is used:
                                    ╭──────────────╮
@@ 798行目: / 866行目: @@
                    on disk                         in RAM
+復号化するときは、手順が逆になります。
-When decrypting, the procedure is reversed analogously.
+注目に値することの1つは、セクターごとに一意の初期化ベクトルを生成することです。 最も簡単な選択は、セクター番号などのすぐに利用できる値から予測可能な方法で計算することです。 ただし、これにより、システムに繰り返しアクセスする攻撃者が、いわゆる [[wikipedia:Watermarking_attack|watermarkingattack]] を実行できる可能性があります。 これを防ぐために、'' 暗号化されたソルトセクター初期化ベクトル ( '''ESSIV''')'' と呼ばれる方法を使用して、潜在的な攻撃者に完全にランダムに見えるように初期化ベクトルを生成できます。
-One thing worth noting is the generation of the unique initialization vector for each sector. The simplest choice is to calculate it in a predictable fashion from a readily available value such as the sector number. However, this might allow an attacker with repeated access to the system to perform a so-called [http://en.wikipedia.org/wiki/Watermarking_attack watermarking attack]. To prevent that, a method called "Encrypted salt-sector initialization vector ('''ESSIV''')" can be used to generate the initialization vectors in a way that makes them look completely random to a potential attacker.
+ディスク暗号化に利用できる他のより複雑な操作モードもいくつかあります。これらは、そのような攻撃に対する組み込みのセキュリティをすでに提供しています(したがって、 ESSIV を必要としません)。
-There are also a number of other, more complicated modes of operation available for disk encryption, which already provide built-in security against such attacks (and hence don't require ESSIV).
+暗号化されたデータの信頼性をさらに保証できるものもあります(つまり、キーにアクセスできない人によってデータが変更/破損されていないことを確認します)。
-Some can also additionally guarantee authenticity of the encrypted data (i.e. confirm that it has not been modified/corrupted by someone who does not have access to the key).
-''Further reading:''
+''参照:''
 * [[Wikipedia:Disk_encryption_theory]]
-* [[Wikipedia:Block_cipher]]
+* [[Wikipedia:ja:ブロック暗号]]
-* [[Wikipedia:Block_cipher_modes_of_operation]]
+* [[Wikipedia:ja:暗号利用モード]]
 ===もっともらしい否認===
 [[Wikipedia:Plausible deniability]] を参照してください。
+== ディスク暗号化シナリオのバックアップ ==
+データ損失から保護するために、ユーザーデータの [[バックアップ]] を作成します。一般に、暗号化されたデータのバックアップも暗号化する必要があります。
+=== ブロックデバイスの暗号化 ===
+複数のオプションがあり、暗号化コンテナが存在するディスクブロックデバイスをイメージとしてバックアップできます。 {{ic|/dev/sd''x''}} または暗号化されたコンテナ内のファイルシステムをバックアップできます。 {{ic|/dev/mapper/''dm_name''}} またはファイルをバックアップできます。例: [[rsync]] で。次のセクションでは、各オプションの長所と短所を示します。
+==== ディスクブロックデバイスのバックアップ ====
+ディスクブロックデバイスのバックアップは次のとおりです。
+* 作業コピーと同じレベルのセキュリティでそのまま暗号化
+* LUKS ヘッダーが含まれています
+* 常にディスクブロックデバイスと同じ大きさ
+* 増分バックアップ、圧縮、重複排除などの高度なバックアップ戦略を簡単に許可することはできません
+* 暗号化コンテナも復元されるため、新しいディスクに簡単に復元できます
+==== ファイルシステムまたはファイルのバックアップ ====
+つまたは複数のファイルのバックアップは次のとおりです。
+* ''そのまま'' 暗号化されていない
+* ネットワーク経由で転送する前、またはディスクに保存するときに暗号化する必要があり、追加の作業が必要です
+* 必ずしも作業コピーと同じレベルのセキュリティで暗号化されているとは限りません
+* LUKS ヘッダーは含まれていません
+* ファイルシステムの使用済みスペースと同じ大きさのみ。たとえば、[[Partclone]]
+* 増分バックアップ、圧縮、重複排除などの高度なバックアップ戦略を可能にします
+* LUKS ヘッダーのバックアップを復元するなどして、暗号化コンテナを新しいディスクに手動で復元する必要があります
+==== LUKS ヘッダーバックアップ ====
+LUKS を使用している場合、[https://wiki.archlinux.jp/index.php/Dm-crypt/%E3%83%87%E3%83%90%E3%82%A4%E3%82%B9%E3%81%AE%E6%9A%97%E5%8F%B7%E5%8C%96#.E3.83.90.E3.83.83.E3.82.AF.E3.82.A2.E3.83.83.E3.83.97.E3.81.A8.E3.83.AA.E3.82.B9.E3.83.88.E3.82.A2 dm-crypt/デバイスの暗号化#バックアップとリストア]を作成できます。特にパスフレーズが取り消されている場合は、これらのバックアップを定期的にチェックして同期するのが理にかなっています。
+ただし、データのバックアップがあり、それを復元する場合は、cryptsetupを使用してLUKS暗号化パーティションを最初から再作成してからデータを復元できます。したがって、LUKSヘッダーのバックアップはデータのバックアップよりも重要ではありません。
 ==参照==
-<small>
-# [[#summary|^]] see http://www.truecrypt.org/legal/license
+# [[#概要|^]] http://www.truecrypt.org/legal/license を参照
+# [[#実用性|^]] ファイルシステムのひとつのファイルをコンテナとして使うことはできますが(仮想ループバックデバイス)、ファイルシステム(の機能)を使うことはできなくなります。
-# [[#practical_implications|^]] well, a single file in those filesystems could be used as a container (virtual loop-back device!) but then one wouldn't actually be using the filesystem (and the features it provides) anymore
-# [[#compatibility_.26_prevalence|^]] [http://www.scherrer.cc/crypt CrossCrypt] - Open Source AES and TwoFish Linux compatible on the fly encryption for Windows XP and Windows 2000
+# [[#互換性と普及度|^]] [http://www.scherrer.cc/crypt CrossCrypt] - Windows XP や Windows 2000 と互換性のあるオープンソースの AES と TwoFish による Linux の暗号化
-# [[#compatibility_.26_prevalence|^]] (1) [http://sourceforge.net/projects/freeotfe.mirror/ FreeOTFE (on sf.net)]  (2) [http://web.archive.org/web/20130531062457/http://freeotfe.org/ FreeOTFE (archived)] - supports Windows 2000 and later (for PC), and Windows Mobile 2003 and later (for PDA)
+# [[#互換性と普及度|^]] (1) [https://sourceforge.net/projects/freeotfe.mirror/ FreeOTFE (on sf.net)]  (2) [https://web.archive.org/web/20130531062457/http://freeotfe.org/ FreeOTFE (archived)] - Windows 2000 以上 (PC) や Windows Mobile 2003 以上 (PDA) をサポート
-# [[#compatibility_.26_prevalence|^]] see [http://www.arg0.net/encfs-mac-build EncFs build instructions for Mac]
+# [[#互換性と普及度|^]] [http://www.arg0.net/encfs-mac-build EncFs build instructions for Mac] を参照
-# [[#compatibility_.26_prevalence|^]] see http://www.freshports.org/sysutils/fusefs-encfs/
+# [[#互換性と普及度|^]] http://www.freshports.org/sysutils/fusefs-encfs/ を参照
-# [[#compatibility_.26_prevalence|^]] see http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data
+# [[#互換性と普及度|^]] https://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data を参照
-# [[#compatibility_.26_prevalence|^]] http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
+# [[#互換性と普及度|^]] http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
-# [[#compatibility_.26_prevalence|^]] http://members.ferrara.linux.it/freddy77/encfs.html
+# [[#互換性と普及度|^]] http://members.ferrara.linux.it/freddy77/encfs.html
-# [[#compatibility_.26_prevalence|^]] http://csrc.nist.gov/archive/aes/round2/r2report.pdf
+# [[#互換性と普及度|^]] http://csrc.nist.gov/archive/aes/round2/r2report.pdf
-# [[#compatibility_.26_prevalence|^]] https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf
+# [[#互換性と普及度|^]] https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf
-# [[#compatibility_.26_prevalence|^]] https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf
+# [[#互換性と普及度|^]] https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf
-# [[#encfs_acceleration|^]] https://code.google.com/p/encfs/issues/detail?id=131
+# [[#パフォーマンス|^]] https://github.com/vgough/encfs/issues/118
+# [[#互換性と普及度|^]] [https://github.com/t-d-k/LibreCrypt LibreCrypt] (旧名 [https://github.com/t-d-k/doxbox DOXBOX]) - 新しいバージョンの Windows におけるオープンな dm-crypt / LUKS のサポート (OTFE のフォークを含む)
-</small>

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

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

目次

なぜ暗号化を使うのか?

システムデータ暗号化

利用可能な手段

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

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

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

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

比較表

概要

基本的な分類

実用性

ユーザビリティ

セキュリティ

パフォーマンス

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

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

互換性と普及度

準備

セットアップの選択

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

ディスクの準備

暗号化の仕組み

基本原理

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

暗号メタデータ

暗号と利用モード

もっともらしい否認

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

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

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

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

LUKS ヘッダーバックアップ

参照

案内メニュー

検索