ディスク暗号化

提供: ArchWiki
2017年7月21日 (金) 20:58時点におけるToMeWelcome (トーク | 投稿記録)による版
(差分) ← 古い版 | 最新版 (差分) | 新しい版 → (差分)
移動先: 案内検索

この記事ではストレージディスクの論理部 (フォルダ, パーティション, ディスク全体など) を暗号化で保護するために Arch Linux で利用できる技術について扱っており、書き込まれたデータを全て自動的に暗号化して、読み込むときにオンザフライで復元することを目標とします。

これに関連して"ストレージディスク"とはコンピュータのハードドライブや、USB フラッシュドライブや DVD などの外部デバイスだけでなく、ループバックデバイスやクラウドストレージなどの (Arch Linux からブロックデバイスやファイルシステムとして参照することができる) 仮想ストレージディスクも含めます。

保護したい対象や暗号化する方法をすでに決めている場合は、右にある関連記事を直接見ることを推奨します。

なぜ暗号化を使うのか?

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

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

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

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

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

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

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

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

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

データ暗号化 vs システム暗号化

データ暗号化
データ暗号化は、ユーザーのデータ (/home ディレクトリの中や、データ DVD などのリムーバルメディア) だけの暗号化と定義され、一番シンプルで込み入ったところがないディスク暗号化の利用法ですが、致命的な欠点があります。
最近の計算システムでは、ユーザーデータに関する情報や、またはデータそれ自体の一部を以下のようなハードドライブの暗号化されていない領域にキャッシュ・保存するバックグラウンドプロセスが多数存在します:
  • スワップパーティション
  • /tmp (ユーザーアプリケーションによって作成される一時ファイル)
    • (救済策: そのようなアプリケーションを使うのをやめる、または /tmpRAM ディスクにマウントする)
  • /var (ログファイルやデータベースなど。例えば mlocate は全てのファイル名のインデックスを /var/lib/mlocate/mlocate.db に保存します)
さらに、データ暗号化だけではオフラインのシステムのタンパリング攻撃にたいして隙を残すことになります (例: 暗号化されたデータを解除するために使用するパスフレーズを記録するプログラムや、ロックを解除するのを待ってから密かに攻撃者がデータを回収できる場所にデータをコピー/送信するプログラムのインストール)。
システム暗号化
システム暗号化は、オペレーティングシステムユーザーデータの暗号化と定義されており、データ暗号化の欠点を解決します。
メリット:
  • オペレーティングシステムのファイルに対する権限のない物理アクセス (と改竄) を防ぎます (ただし上の警告を見て下さい)
  • システムによってキャッシュされる可能性のあるプライベートなデータへの権限のない物理アクセスを防ぎます
デメリット:
  • ユーザーのログイン中またはログイン後にディスクの暗号化された部分を解除することはできなくなります。起動時に行わなくてはなりません

実際には、データ暗号化とシステム暗号化はいつでも判然と区別することができるというわけではなく、様々な妥協やカスタマイズをしたセットアップというのが考えられます。

いずれにせよ、ディスク暗号化はあくまでオペレーティングシステムの既存のセキュリティ機構の添え物として考えるべきです。ネットワークセキュリティやユーザーベースのアクセス制御などを提供するシステムの他の部分を活かしながら、オフラインの物理アクセスの防御も考えて下さい。

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, そして機能制限がありますが loopAESTruecrypt デバイス。
  • デフォルトで使用される 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 [3] [4]  ?     [9]
macOS  ?  ?  ?     [5]
FreeBSD  ?  ?  ?     [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番目の方法は高エントロピーのキーファイルを作成して暗号化するデータドライブとは別のメディアに保存する方式です。

参照:

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

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

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

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

  • パスフレーズで保護したキーファイルあるいはディスクに保存

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

  • セッションごとにランダムに生成

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

暗号メタデータ

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

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

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

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

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.

参照:

暗号と利用形態

与えられた暗号鍵を使って実際に暗号化データと非暗号化データ (つまり"平文"と"暗号文") を変換するのに使われるアルゴリズムは "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]

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 を参照してください。

参照

  1. ^ http://www.truecrypt.org/legal/license を参照
  2. ^ 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
  3. ^ CrossCrypt - Windows XP や Windows 2000 と互換性のあるオープンソースの AES と TwoFish による Linux の暗号化
  4. ^ (1) FreeOTFE (on sf.net) (2) FreeOTFE (archived) - Windows 2000 以上 (PC) や Windows Mobile 2003 以上 (PDA) をサポート
  5. ^ EncFs build instructions for Mac を参照
  6. ^ http://www.freshports.org/sysutils/fusefs-encfs/ を参照
  7. ^ http://www.chromium.org/chromium-os/chromiumos-design-docs/protecting-cached-user-data を参照
  8. ^ http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
  9. ^ http://members.ferrara.linux.it/freddy77/encfs.html
  10. ^ http://csrc.nist.gov/archive/aes/round2/r2report.pdf
  11. ^ https://www.cl.cam.ac.uk/~rja14/Papers/serpentcase.pdf
  12. ^ https://www.cl.cam.ac.uk/~rja14/Papers/serpent.pdf
  13. ^ https://github.com/vgough/encfs/issues/118
  14. ^ DOXBOX - 新しいバージョンの Windows におけるオープンな dm-crypt / LUKS のサポート (OTFE のフォークを含む)