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

提供: ArchWiki
ナビゲーションに移動 検索に移動
100行目: 100行目:
   
 
;dm-crypt: [[dm-crypt (日本語)|dm-crypt]] は Linux カーネルによって提供されている標準の device-mapper 暗号化機能です。直接使うことでパーティションやキーの管理のあらゆることを完全にコントロールすることができます。dm-crypt の管理はユーザースペースユーティリティの {{Pkg|cryptsetup}} を使って行います。次のタイプのブロックデバイス暗号化に使用することが可能です: ''LUKS'' (デフォルト), ''plain'', そして機能制限がありますが ''loopAES'' と ''Truecrypt'' デバイス。
 
;dm-crypt: [[dm-crypt (日本語)|dm-crypt]] は Linux カーネルによって提供されている標準の device-mapper 暗号化機能です。直接使うことでパーティションやキーの管理のあらゆることを完全にコントロールすることができます。dm-crypt の管理はユーザースペースユーティリティの {{Pkg|cryptsetup}} を使って行います。次のタイプのブロックデバイス暗号化に使用することが可能です: ''LUKS'' (デフォルト), ''plain'', そして機能制限がありますが ''loopAES'' と ''Truecrypt'' デバイス。
  +
:* デフォルトで使用される LUKS は dm-crypt をセットアップするのに必要な情報を全てディスクに保存する便利なレイヤーで、使いやすさと暗号のセキュリティを増すためにパーティションとキー管理を抽象化します。
:* 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 モードは、オリジナルのカーネルの機能であり、便利なレイヤーを使いません。レイヤーを使った時と同じ暗号強度を確保するのは難しくなります。そうしようとすると、結果的にキー (パスフレーズまたはキーファイル) が長くなってしまいます。しかしながら、下で説明しているように利点も存在します。
:* 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月にサポートを終了しています。
 
;TrueCrypt: [[TrueCrypt]] の開発者は2014年5月にサポートを終了しています。
195行目: 195行目:
 
暗号メタデータの保存場所
 
暗号メタデータの保存場所
 
| ?
 
| ?
| LUKS を使用: LUKS Header
+
| LUKS を使用: LUKS ヘッダー
| rowspan="2" | begin/end of (decrypted) device ([http://www.truecrypt.org/docs/volume-format-specification format])
+
| 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"
 
|- valign="top"
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
204行目: 204行目:
 
暗号鍵の保存場所
 
暗号鍵の保存場所
 
| ?
 
| ?
| LUKS を使用: LUKS header
+
| LUKS を使用: LUKS ヘッダー
  +
| 何処にでも保存できるキーファイル
| key file that can be stored anywhere
 
  +
| EncFs コンテナのトップレベルにあるコントロールファイル
| control file at the top level of each EncFs container
 
 
|-
 
|-
 
| colspan="3" style="height:20px; border-color:transparent" |
 
| colspan="3" style="height:20px; border-color:transparent" |
224行目: 224行目:
 
ファイルのメタデータ (ファイルの数, ディレクトリ構造, ファイルサイズ, パーミッション, 更新時刻など) の暗号化
 
ファイルのメタデータ (ファイルの数, ディレクトリ構造, ファイルサイズ, パーミッション, 更新時刻など) の暗号化
 
| colspan="3" | <span style="font-size:210%; color:#5F9E23;">✔</span>
 
| colspan="3" | <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"
 
|- valign="top"
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
240行目: 240行目:
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
| 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" |
 
! 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="3" | <span style="font-size:160%; color:#CF2525;">✖</span>
 
| colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
 
| colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
246行目: 246行目:
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
| 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" |
 
! 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>[[#参照|[2]]]</sup>
 
| colspan="3" | &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>
 
| colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
252行目: 252行目:
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
| 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" |
 
! 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="3" | <span style="font-size:160%; color:#CF2525;">✖</span>
 
| colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
 
| colspan="2" | <span style="font-size:210%; color:#5F9E23;">✔</span>
291行目: 291行目:
 
| <span style="font-size:160%; color:#CF2525;">✖</span>
 
| <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>
 
| <span style="font-size:210%; color:#5F9E23;">✔</span>
 
|- valign="top"
 
|- valign="top"
337行目: 337行目:
 
複数の暗号による多段処理のサポート
 
複数の暗号による多段処理のサポート
 
| ?
 
| ?
  +
| 複数のブロックデバイスを段階的に暗号化することは可能
| 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>
 
| ?
 
| ?
362行目: 362行目:
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
| 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" |
 
! 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>(LUKS を使用)
413行目: 413行目:
 
| style="border-left-color:transparent; border-bottom-color:transparent" |
 
| 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" |
 
! 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:210%; color:#5F9E23;">✔</span>
430行目: 430行目:
 
! scope="row" colspan="5" style="text-align:left; font-weight:normal; color:#393939; background:#E2E2E2; padding:0 6px" |
 
! scope="row" colspan="5" 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...
 
| ?
 
| ?
 
|- valign="top"
 
|- valign="top"
565行目: 565行目:
 
<li>複数のユーザーに便宜をはかるにはどうすればいいか?
 
<li>複数のユーザーに便宜をはかるにはどうすればいいか?
 
<ul style="list-style-type:circle;color:#777;font-size:90%;line-height:1em;margin-top:0">
 
<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></li>
 
</ul>
 
</ul>
580行目: 580行目:
 
* "下位ディレクトリ"の場所 (スタックファイルシステムの暗号化を使う場合)
 
* "下位ディレクトリ"の場所 (スタックファイルシステムの暗号化を使う場合)
   
  +
実際にやってみると、以下のような取り合わせが考えられると思われます:
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/Encrypting an entire system#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.
 
   
 
===強固なパスフレーズの選択===
 
===強固なパスフレーズの選択===
600行目: 600行目:
 
===ディスクの準備===
 
===ディスクの準備===
   
  +
ディスク (の一部) に暗号化をセットアップする前に、まず確実にディスクを消去するようにしてください。ディスクを消去する際にはドライブ全体またはパーティション全体をゼロバイトやランダムなバイトのストリームで上書きします。これを行う理由は以下の通り:
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>
 
<ul>
<li><p>'''prevent recovery of previously stored data'''</p>
+
<li><p>'''以前に保存されていたデータのリカバリを防ぐ'''</p>
 
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>
 
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).
 
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>
   
<li><p>'''prevent disclosure of usage patterns on the encrypted drive'''</p>
+
<li><p>'''暗号化されたドライブの利用状況の発覚を防ぐ'''</p>
 
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>
 
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.
 
In order to satisfy this goal, wiping the disk using high-quality random bytes is crucial.

2014年12月29日 (月) 04:17時点における版

テンプレート:Related articles start (日本語)

  • dm-crypt
  • TrueCrypt
  • eCryptfs
  • EncFS
  • Tomb
  • tcplay
  • この記事ではストレージディスクの論理部 (フォルダ, パーティション, ディスク全体など) を暗号化で保護するために 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 (with [3]) (with [4]) ?     [9]
    Mac OS X ? ? ?     [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 スティック上に配置

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

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

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

    ディスクの準備

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

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

      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.

    ヒント: 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.

    基本原理

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

    暗号メタデータ

    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:

    暗号と利用形態

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

    参照

    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 - Open Source AES and TwoFish Linux compatible on the fly encryption for Windows XP and Windows 2000
    4. ^ (1) FreeOTFE (on sf.net) (2) FreeOTFE (archived) - supports Windows 2000 and later (for PC), and Windows Mobile 2003 and later (for 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://code.google.com/p/encfs/issues/detail?id=131