「保存データ暗号化」の版間の差分
細 (Kusakata がページ「Disk encryption (日本語)」を「ディスク暗号化」に移動しました) |
細 |
||
| 1行目: | 1行目: | ||
| − | [[Category: |
+ | [[Category:セキュリティ]] |
| − | [[Category: |
+ | [[Category:ファイルシステム]] |
[[en:Disk encryption]] |
[[en:Disk encryption]] |
||
[[es:Disk encryption]] |
[[es:Disk encryption]] |
||
[[it:Disk Encryption]] |
[[it:Disk Encryption]] |
||
{{Related articles start (日本語)}} |
{{Related articles start (日本語)}} |
||
| − | {{ |
+ | {{Related|dm-crypt}} |
{{Related|TrueCrypt}} |
{{Related|TrueCrypt}} |
||
{{Related|eCryptfs}} |
{{Related|eCryptfs}} |
||
| − | {{ |
+ | {{Related|EncFS}} |
{{Related|Tomb}} |
{{Related|Tomb}} |
||
{{Related|tcplay}} |
{{Related|tcplay}} |
||
2015年1月5日 (月) 16:01時点における版
テンプレート:Related articles start (日本語)
この記事ではストレージディスクの論理部 (フォルダ, パーティション, ディスク全体など) を暗号化で保護するために Arch Linux で利用できる技術について扱っており、書き込まれたデータを全て自動的に暗号化して、読み込むときにオンザフライで復元することを目標とします。
これに関連して"ストレージディスク"とはコンピュータのハードドライブや、USB フラッシュドライブや DVD などの外部デバイスだけでなく、ループバックデバイスやクラウドストレージなどの (Arch Linux からブロックデバイスやファイルシステムとして参照することができる) 仮想ストレージディスクも含めます。
保護したい対象や暗号化する方法をすでに決めている場合は、右にある関連記事を直接見ることを推奨します。
なぜ暗号化を使うのか？
ディスク暗号化は確実にファイルを常に暗号化された状態でディスクに保存することができます。ファイルにアクセスできるのは、システムが動いていて信頼されたユーザーによってロックを解除された間だけで、その場合にのみオペレーティングシステムやアプリケーションは読み取れる状態でファイルにアクセスすることができるようになります。権限のないユーザーが直接ディスクの中身を見たとしても、わかるのは意味がわからないランダムなデータだけで、実際のファイルを読み取ることは不可能です。
ディスク暗号化によって、例えば、コンピュータやハードディスクが以下の状態にあるときにデータを勝手に見られることを防げます:
- あなたの離席中に、他の信頼されない人々がアクセスすることができる場所に置かれている場合。
- ノートパソコンやネットブック、または外付けのストレージデバイスなどのように紛失したり盗まれた場合。
- 修理に出している間。
- 寿命が尽きて廃棄した時。
さらに、ディスク暗号化を使うことで、オペレーティングシステムを改竄しようとする不正アクセスに対するセキュリティの強化にもなります。例えば、システムへの物理的なアクセスを手に入れた攻撃者によるキーロガーやトロイの木馬のインストールへの防衛手段になります。
ディスク暗号化によっても以下のような場合には対処できません:
- システムが動いていて、あなたがロックを解除してディスクの暗号化している部分をマウントしてしまった後に (インターネットなどを介して) 攻撃者がシステムに侵入した場合。
- コールドブートアタックに必要な手段を攻撃者が手に入れていて、(画面ロックを使っていたとしても) コンピュータが動作している、または動作していたすぐ後に攻撃者が物理的にアクセスできる場合。
- 政府機関が、上記の攻撃を簡単に行える資力を持っているだけでなく、もっとシンプルに、様々な強制執行を使って無理矢理キーやパスフレーズを明かさせることができる場合。世界中の非民主的な国々、さらにアメリカやイギリスでも、何か興味深いものをあなたが隠していると法執行機関が疑いをかけた場合、法執行機関によってロックの解除を合法的に迫られる可能性があります。
あなたがシステムを使う前にシステムに細工を施すことができるプロの攻撃者にまともに対抗するには非常に強固なディスク暗号化が必要になります (例: 平文のブートパーティションがなく真正の確認があるフルシステム暗号化)。それでもあらゆるタイプの改竄を押しとどめることができるかというと疑問です (例: ハードウェアキーロガー)。おそらくハードウェアベースの完全ディスク暗号化とトラステッドコンピューティングが最善策でしょう。
データ暗号化 vs システム暗号化
- データ暗号化
- データ暗号化は、ユーザーのデータ (
/homeディレクトリの中や、データ DVD などのリムーバルメディア) だけの暗号化と定義され、一番シンプルで込み入ったところがないディスク暗号化の利用法ですが、致命的な欠点があります。 - 最近の計算システムでは、ユーザーデータに関する情報や、またはデータそれ自体の一部を以下のようなハードドライブの暗号化されていない領域にキャッシュ・保存するバックグラウンドプロセスが多数存在します:
- さらに、データ暗号化だけではオフラインのシステムのタンパリング攻撃にたいして隙を残すことになります (例: 暗号化されたデータを解除するために使用するパスフレーズを記録するプログラムや、ロックを解除するのを待ってから密かに攻撃者がデータを回収できる場所にデータをコピー/送信するプログラムのインストール)。
- システム暗号化
- システム暗号化は、オペレーティングシステムとユーザーデータの暗号化と定義されており、データ暗号化の欠点を解決します。
- メリット:
- オペレーティングシステムのファイルに対する権限のない物理アクセス (と改竄) を防ぎます (ただし上の警告を見て下さい)
- システムによってキャッシュされる可能性のあるプライベートなデータへの権限のない物理アクセスを防ぎます
- デメリット:
- ユーザーのログイン中またはログイン後にディスクの暗号化された部分を解除することはできなくなります。起動時に行わなくてはなりません
実際には、データ暗号化とシステム暗号化はいつでも判然と区別することができるというわけではなく、様々な妥協やカスタマイズをしたセットアップというのが考えられます。
いずれにせよ、ディスク暗号化はあくまでオペレーティングシステムの既存のセキュリティ機構の添え物として考えるべきです。ネットワークセキュリティやユーザーベースのアクセス制御などを提供するシステムの他の部分を活かしながら、オフラインの物理アクセスの防御も考えて下さい。
Wikipedia:Disk encryption も参照。
利用可能な手段
あらゆるディスク暗号化の手段というのは、ディスクは暗号化されたデータを保持しながら、暗号コンテナ (つまり暗号化されたデータを保持するディスクの論理部) が"解除"されてマウントされているときにかぎり、オペレーティングシステムやアプリケーションからは通常の読み込み可能なデータとして見えるようにするという方法で働きます。
暗号化を使うには、ユーザーによって"秘密情報"が供給される必要があり (通常はキーファイルやパスフレーズの形で指定します)、それから実際の暗号化キーが生成されます (そしてセッションの間はカーネルのキーリングに保存されます)。
この種の仕組みが全くわからないという場合は、下の暗号化の仕組みセクションを読んで下さい。
利用できるディスク暗号化の方法は、稼働するレイヤーによって2つのタイプに分けることができます:
スタックファイルシステムの暗号化
スタックファイルシステムによる暗号化ソリューションは既存のファイルシステム上に積み上げられるレイヤーとして実装され、暗号化が有効になったフォルダへ書き込まれた全てのファイルを、実際のファイルシステムがディスクに書き込む前に即座に暗号化します。そしてファイルシステムがディスクからファイルを読み込んだ時は復号化を行います。この方法では、ホストファイルシステムには暗号化された形でファイルが保存されますが (ファイルの中身や、ファイル名・フォルダ名も、同じ長さのランダムなデータで置き換えられます)、それ以外のファイルはファイルシステム上に通常のファイル/シンボリックリンク/ハードリンクとして暗号化されない形で存在します。
ホストファイルシステムにある暗号化されたファイルが保存されたフォルダをロック解除するため、(特殊なスタック擬似ファイルシステムを使って) それ自体または別の場所にマウントされ、同じファイルが読み込める形で現れます。アンマウントしたり、システムの電源が落とされるまでその状態は維持されます。
スタックファイルシステム暗号化で利用できるソリューションは以下の2つです:
- eCryptfs
- eCryptfs を参照。
- EncFS
- EncFS を参照。
ブロックデバイスの暗号化
一方、ブロックデバイス暗号化はファイルシステムレイヤーの下で動作して、特定のブロックデバイス (つまり、ディスクやパーティション全体、または仮想的なループバックデバイスとして振る舞うファイル) に書き込まれる全てのデータが暗号化されます。このため、ブロックデバイスがオフラインのときは、中身が全てランダムなデータの巨大なブロブのように見え、ファイルシステムやデータに何が含まれているのか判断できなくなります。データにまたアクセスするときは、保護されたコンテナ (この場合、ブロックデバイス) を特殊な方法で任意の場所にマウントします。
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月にサポートを終了しています。
選択するレイヤーの実用性については、下の比較表を見て下さい。eCryptfs についての記事も参照。
比較表
"dm-crypt +/- LUKS" のカラムは LUKS ("+") と plain ("-") 両方の暗号化モードにおける dm-crypt の機能を示しています。特定の機能が LUKS の使用を必要とする場合、そのことは "(LUKS を使用)" で表されます。同じように "(LUKS を使用しない)" はその機能を実現するのに LUKS の使用が逆効果であり、plain モードを使うべきことを示しています。
概要 |
Loop-AES | dm-crypt +/- LUKS | Truecrypt | eCryptfs | EncFs | ||
|---|---|---|---|---|---|---|---|
|
タイプ |
ブロックデバイスの暗号化 | スタックファイルシステムの暗号化 | |||||
|
主なセールスポイント |
最古の手段であり、おそらく最速であり、レガシーなシステムでも動作します | Linux におけるブロックデバイス暗号化のデファクトスタンダードであり柔軟性があります | 携帯性が高く、洗練された、自己完結型の暗号化ソリューション | EncFS よりも若干高速で、暗号化されたファイルは個別にシステム間で移動できます | 一番使うのが簡単で、root 以外による管理をサポートしています | ||
|
Arch Linux における利用手段 |
カスタムカーネルの手動コンパイルが必須 | カーネルモジュール: デフォルトのカーネルに含まれています; ツール: device-mapper, cryptsetup [core] | truecrypt 7.1a-2 [extra] (最新バージョンには読み取り機能しかありません) | カーネルモジュール: デフォルトのカーネルに含まれています; ツール: ecryptfs-utils [community] | encfs [community] | ||
|
ライセンス |
GPL | GPL | カスタム[1] | GPL | GPL | ||
基本的な分類 |
Loop-AES | dm-crypt +/- LUKS | Truecrypt | eCryptfs | EncFs | ||
|
暗号化の対象 |
ブロックデバイス全体 | ファイル | |||||
|
暗号化されたデータのコンテナ |
|
| |||||
|
ファイルシステムとの関係 |
ファイルシステムレイヤーの下で動作し、暗号化されたブロックデバイスの中身がファイルシステム、パーティションテーブル、LVM のどれであるかには関しない | 既存のファイルシステムにレイヤーを追加して、ファイルが書き込まれたり読み込まれた時に自動的に暗号化または復号化を行う | |||||
|
暗号化の実装空間 |
カーネル空間 | ユーザー空間 (FUSE を使用) | |||||
|
暗号メタデータの保存場所 |
? | LUKS を使用: LUKS ヘッダー | (復号化された) デバイスの冒頭/最後 (フォーマット) | 暗号化されたファイルのヘッダー | EncFs コンテナのトップレベルにあるコントロールファイル | ||
|
暗号鍵の保存場所 |
? | LUKS を使用: LUKS ヘッダー | 何処にでも保存できるキーファイル | EncFs コンテナのトップレベルにあるコントロールファイル | |||
実用性 |
Loop-AES | dm-crypt +/- LUKS | Truecrypt | eCryptfs | EncFs | ||
|
ファイルのメタデータ (ファイルの数, ディレクトリ構造, ファイルサイズ, パーミッション, 更新時刻など) の暗号化 |
✔ | ✖ (ファイルやディレクトリの名前は暗号化できます) | |||||
|
(パーティションテーブルを含む) ハードドライブ全体の暗号化 |
✔ | ✖ | |||||
|
スワップ領域の暗号化 |
✔ | ✖ | |||||
|
あらかじめ特定のサイズのスペースを暗号化データコンテナに割り当てなくても使用できるか |
✖ | ✔ | |||||
|
ブロックデバイスにアクセスできない既存のファイルシステム (NFS や Samba の共有、クラウドストレージなど) の保護に使用できるか |
✖[2] | ✔ | |||||
|
暗号化されたファイルのファイルベースのオフラインバックアップ |
✖ | ✔ | |||||
ユーザビリティ |
Loop-AES | dm-crypt +/- LUKS | Truecrypt | eCryptfs | EncFs | ||
|
ログイン時の自動マウントのサポート |
? | ✔ | ? | ✔ | ✔ | ||
|
アイドル状態による自動アンマウントのサポート |
? | ? | ? | ? | ✔ | ||
|
root 以外のユーザーによる暗号化されたデータのコンテナの作成と破壊 |
✖ | ✖ | ✖ | 制限あり | ✔ | ||
|
GUI |
✖ | ✖ | ✔ | ✖ | ✔ | ||
セキュリティ |
Loop-AES | dm-crypt +/- LUKS | Truecrypt | eCryptfs | EncFs | ||
|
サポートされている暗号 |
AES | AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish, … (カーネルの Crypto API が用意している全ての暗号) | AES, Twofish, Serpent | AES, Blowfish, Twofish... | AES, Blowfish | ||
|
ソルティングのサポート |
? | ✔ (LUKS を使用) |
✔ | ✔ | ? | ||
|
複数の暗号による多段処理のサポート |
? | 複数のブロックデバイスを段階的に暗号化することは可能 | ✔ | ? | ✖ | ||
|
キースロットの拡散のサポート |
? | ✔ (LUKS を使用) |
? | ? | ? | ||
|
キースクラブに対する保護 |
✔ | ✔ (LUKS を使用しない) |
? | ? | ? | ||
|
同一の暗号化されたデータに対して複数のキー (別個に無効にできる) のサポート |
? | ✔ (LUKS を使用) |
? | ? | ✖ | ||
パフォーマンス |
Loop-AES | dm-crypt +/- LUKS | Truecrypt | eCryptfs | EncFs | ||
|
マルチスレッドのサポート |
? | ✔[8] | ✔ | ? | ? | ||
|
ハードウェア支援暗号化のサポート |
✔ | ✔ | ✔ | ✔ | ✔[13] | ||
ブロックデバイス暗号化特有の事項 |
Loop-AES | dm-crypt +/- LUKS | Truecrypt | ||||
|
所定の暗号化済みのブロックデバイスを (手動で) リサイズすることのサポート |
? | ✔ | ✖ | ||||
スタックファイルシステム暗号化特有の事項 |
eCryptfs | EncFs | |||||
|
サポートされるファイルシステム |
ext3, ext4, xfs (注意事項あり), jfs, nfs... | ? | |||||
|
ファイル名の暗号化 |
✔ | ✔ | |||||
|
ファイル名の暗号化をしない機能 |
✔ | ✔ | |||||
|
スパースファイルの最適化処理 |
✖ | ✔ | |||||
互換性と普及度 |
Loop-AES | dm-crypt +/- LUKS | Truecrypt | eCryptfs | EncFs | ||
|
サポートされる Linux カーネルバージョン |
2.0 以上 | CBC モード 2.6.4, ESSIV 2.6.10, LRW 2.6.20, XTS 2.6.24 | ? | ? | 2.4 以上 | ||
| 暗号化されたデータにアクセスできるオペレーティングシステム | Windows | ✔ (with [3]) | ✔ (with [4]) | ✔ | ? | ✔[9] | |
| Mac OS X | ? | ? | ✔ | ? | ✔[5] | ||
| FreeBSD | ? | ? | ✖ | ? | ✔[6] | ||
|
使用しているディストリビューション |
? |
|
? |
|
? | ||
準備
セットアップの選択
どのディスク暗号化をセットアップするのが適切なのかはあなたの目的 (上の #なぜ暗号化を使うのか？ を読んで下さい) とシステムパラメータによって様々です。
とりわけ、以下の質問に答える必要があるでしょう:
- あなたが身を守りたいのはどのような"攻撃者"からか？
- システムの電源がオフになっていたり盗まれたりしたときにディスクを詮索するカジュアルなコンピュータユーザー
- あなたがシステムを使用する前後に繰り返しシステムに読み書きアクセスをすることができるプロの暗号解読者
- その中間
- どの暗号化ストラテジーを使用するのか？
- データ暗号化
- システム暗号化
- その中間
- スワップや
/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 スティック上に配置
もちろん他にも様々な組み合わせが考えられます。あなたのシステムにとってどのようなセットアップが適切か注意深く計画を練って下さい。
強固なパスフレーズの選択
セキュリティ#パスワード を見て下さい。
ディスクの準備
ディスク (の一部) に暗号化をセットアップする前に、まず確実にディスクを消去するようにしてください。ディスクを消去する際にはドライブ全体またはパーティション全体をゼロバイトやランダムなバイトのストリームで上書きします。これを行う理由は以下の通り:
以前に保存されていたデータのリカバリを防ぐ
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 recovered, is to manually erase it.
For this purpose it does not matter whether zero bytes or random bytes are used (although wiping with zero bytes will be much faster).暗号化されたドライブの利用状況の発覚を防ぐ
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.
In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.
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 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.
暗号化の仕組み
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.
基本原理
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:
╔═══════╗
sector 1 ║"???.."║
╠═══════╣ ╭┈┈┈┈┈╮
sector 2 ║"???.."║ ┊ key ┊
╠═══════╣ ╰┈┈┬┈┈╯
: : │
╠═══════╣ ▼ ┣┉┉┉┉┉┉┉┫
sector n ║"???.."║━━━━━━━(decryption)━━━━━━▶┋"abc.."┋ sector n
╠═══════╣ ┣┉┉┉┉┉┉┉┫
: :
╚═══════╝
encrypted unencrypted
blockdevice or data in RAM
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.
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.
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:
キーとキーファイルとパスフレーズ
The following are examples how to store and cryptographically secure a master key with a keyfile:
stored in a plaintext keyfile
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).
stored in passphrase-protected form in a keyfile or on the disk itself
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.
randomly generated on-the-fly for each session
In some cases, e.g. when encrypting swap space or a
/tmppartition, 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.
暗号メタデータ
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):
╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮ ╭┈┈┈┈┈┈┈┈┈┈┈╮ ┊ mount passphrase ┊━━━━━⎛key derivation⎞━━━▶┊ mount key ┊ ╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,───⎝ function ⎠ ╰┈┈┈┈┈┬┈┈┈┈┈╯ ╭──────╮ ╱ │ │ salt │───────────´ │ ╰──────╯ │ ╭─────────────────────╮ ▼ ╭┈┈┈┈┈┈┈┈┈┈┈┈╮ │ encrypted master key│━━━━━━━━━━━━━━━━━━━━━━(decryption)━━━▶┊ master key ┊ ╰─────────────────────╯ ╰┈┈┈┈┈┈┈┈┈┈┈┈╯
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.
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.
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).
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.
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.
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:
╭┈┈┈┈┈┈┈┈┈┈┈┈╮
┊ master key ┊
file on disk: ╰┈┈┈┈┈┬┈┈┈┈┈┈╯
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │
╎╭───────────────────╮╎ ▼ ╭┈┈┈┈┈┈┈┈┈┈╮
╎│ encrypted file key│━━━━(decryption)━━━▶┊ file key ┊
╎╰───────────────────╯╎ ╰┈┈┈┈┬┈┈┈┈┈╯
╎┌───────────────────┐╎ ▼ ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐
╎│ encrypted file │◀━━━━━━━━━━━━━━━━━(de/encryption)━━━▶┊ readable file ┊
╎│ contents │╎ ┊ contents ┊
╎└───────────────────┘╎ └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
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.
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.
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. --keyfile-size, --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. --iter-time, --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:Key_(cryptography)
- Wikipedia:Key_management
- Wikipedia:Key_derivation_function
暗号と利用形態
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".
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:
| ブロックサイズ | キーサイズ | 注記 | ||
|---|---|---|---|---|
| AES | 128 bits | 128, 192 or 256 bits | アメリカ政府の "SECRET" または "TOP SECRET" の機密情報を保護するのに足ると NSA によって承認されています (192または256ビットのキーサイズの使用時)。 | |
| Blowfish | 64 bits | 32–448 bits | 初期のパテントフリーでセキュアな暗号の一つであり誰でも使えるため、Linux ではかなり定着しています。 | |
| Twofish | 128 bits | 128, 192 or 256 bits | Blowfish の後継として開発されましたが、それほど幅広くは利用されていません。 | |
| Serpent | 128 bits | 128, 192 or 256 bits | AES コンペティションの5つの最終候補の中で一番セキュアだと考えられています[10][11][12]。 |
Encrypting/decrypting a sector (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.
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.
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:
╭──────────────╮
│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
When decrypting, the procedure is reversed analogously.
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 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.
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:Plausible deniability を参照してください。
参照
- ^ http://www.truecrypt.org/legal/license を参照
- ^ 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
- ^ CrossCrypt - Open Source AES and TwoFish Linux compatible on the fly encryption for Windows XP and Windows 2000
- ^ (1) FreeOTFE (on sf.net) (2) FreeOTFE (archived) - supports Windows 2000 and later (for PC), and Windows Mobile 2003 and later (for PDA)
- ^ EncFs build instructions for Mac を参照
- ^ http://www.freshports.org/sysutils/fusefs-encfs/ を参照
- ^ http://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://code.google.com/p/encfs/issues/detail?id=131