暗号化媒体を扱うとき、最初に分けるべき問題は「どのソフトウェアを使うか」だけではない。もちろん、 cryptsetup、 tcplay、 VeraCrypt、 TrueCrypt 本体のどれを使うかは重要である。しかし、それより前に確認すべきなのは、現在の GNU/Linux 環境、特に Debian パッケージとして導入できる自由ソフトウェアだけで、暗号化媒体に対して何ができ、何ができず、どこまでを通常運用として信頼できるのかという問題である。暗号化媒体には、単に中身を読めなくする秘匿性だけでなく、鍵管理、ヘッダー管理、既存形式との互換性、読み取り時の改ざん検証、読み書き可能な完全性保護、内部ファイルシステムの扱い、将来も開けるかという復元可能性が関係する。これらを区別しないまま「この形式は安全か」「このソフトウェアは使えるか」と考えると、自由ソフトウェアで扱える範囲を過小評価するか、逆に万能視することになる。
既稿では、暗号化ディスクを長期運用するための設計、具体的な運用手順、 LUKS 暗号化の基本、 TrueCrypt 資産の GNU/Linux 上での保全、物理媒体の復元可能性、 2.5-inch HDD で LUKS + ext4 が遅くなる理由、暗号強度が時間とともに相対化される問題を扱ってきた[1][2][3][4][5][6][7]。これらでは主に個別の運用判断や具体的な媒体管理を扱っていた。本稿では一段視点を変え、 Linux の自由ソフトウェア群そのものが、暗号化媒体、既存互換形式、読み取り専用の改ざん検証、読み書き可能な完全性保護に対して実際に提供している機能境界を整理する。つまり、本稿の主題は「LUKS の使い方」でも「TrueCrypt の是非」でもなく、 Debian パッケージだけで暗号化媒体をどこまで扱えるのかを、形式、実装、カーネル機能、運用上の限界に分けて確認することである。
結論を先に述べる。 Debian パッケージとして入手できる cryptsetup と tcplay、さらに Linux カーネルの device-mapper 系機能を組み合わせると、 LUKS、 plain dm-crypt、 loop-AES、 TrueCrypt / VeraCrypt 互換ボリューム、 BitLocker、旧 FileVault2、 dm-verity、 dm-integrity までかなり広く扱える。ただし、「扱える」とは「すべてを同じ深さで作成、変更、検証、復旧、監査できる」という意味ではない。 LUKS は作成、鍵管理、ヘッダー管理まで深く扱える。 TrueCrypt / VeraCrypt 互換ボリュームは、保守終了した TrueCrypt 本体とは分けて、媒体上の互換形式として扱える。 cryptsetup は既存ヘッダーを変更せずに保守的に開く入口になり、 tcplay は互換形式の作成や変更を補う。 BitLocker と旧 FileVault2 は条件付きで開ける場合があるが、 Windows や macOS の鍵管理機構や OS 管理体系を完全に置き換えるものではない。 dm-verity は読み取り専用の改ざん検証であり、 dm-integrity は読み書き可能な完全性保護である。この違いを分けることが、本稿全体の出発点である。
本稿では、この「扱える」という言葉を、「開ける」「作れる」「変更できる」「検証できる」「復旧できる」「継続運用できる」に分けて読む。形式を Linux で開けること、形式を完全に管理できること、暗号化によって改ざんや破損まで検出できること、速度低下の原因を暗号計算だけに帰せることは、それぞれ別の問題である。この境界を分けることで、既存暗号化媒体をどう保全し、新規媒体にどの形式を選び、自由ソフトウェアだけでどこまで信頼できる運用を作れるかを判断できる。
1. 問題は cryptsetup 単体ではなく、自由ソフトウェアでどこまで扱えるかである
暗号化媒体の話では、しばしば LUKS、 VeraCrypt、 TrueCrypt、 BitLocker、 FileVault という名前が並ぶ。しかし、これらは同じ階層の言葉ではない。 LUKS は Linux Unified Key Setup というオンディスク形式であり、 Linux で暗号化ブロックデバイスを管理する標準的な形式である。 TrueCrypt と VeraCrypt は暗号化ボリュームを作成・利用するソフトウェアであり、同時にそれぞれの互換ボリューム形式を持つ。 BitLocker と FileVault は Windows と macOS の暗号化機能であり、 OS 固有の鍵管理、起動機構、回復キー、デバイス管理と結びつく。 dm-verity と dm-integrity は暗号化そのものではなく、読み取り時の検証や読み書き可能な完全性タグを扱う device-mapper target である。この時点で、単に名称を横並びにして比較しても、正しい判断にはならない。
この違いを具体的に言えば、ソフトウェア、媒体形式、カーネル経路、ファイルシステム、信頼性は別の層である。ソフトウェアは、媒体を開いたり作成したりする実装である。媒体形式は、ディスク上に実際に記録されたヘッダー、鍵情報、暗号パラメーター、データ配置の構造である。カーネル経路は、開いた後のブロック I/O を暗号化、復号、検証する処理経路である。ファイルシステムは、復号済みブロックデバイスの中にあるファイルやディレクトリを解釈する仕組みである。信頼性は、読めること、壊れていないこと、将来も復旧できること、保守される環境で運用を続けられることを含む。これらを混同すると、たとえば「TrueCrypt 本体が古いから既存 TrueCrypt 互換媒体も即座に使えない」と誤解したり、「cryptsetup で BitLocker を開けるなら Windows の BitLocker 管理を Linux で置き換えられる」と過大評価したりする。
必要なのは、媒体上の形式、解除に必要な鍵素材、 Linux 側で使う実装、開いた後のブロック I/O 経路、内部ファイルシステム、完全性検証、復旧手順を分けることである。暗号化は中身を読めなくする秘匿性を提供するが、媒体故障、ヘッダー破損、鍵紛失、誤削除、改ざん検出、速度劣化をまとめて解決するわけではない。逆に、古い形式であっても、現役の自由ソフトウェア実装で読めるなら、ただちに捨てる必要はない。したがって、本稿では cryptsetup 単体の紹介ではなく、自由ソフトウェアと Debian パッケージだけでどの保護機能を実現でき、どこに限界があり、どの形式を新規主系として選び、どの形式を既存資産の救出・参照・段階移行に使うべきかを主題にする。
| 観点 | 見るべき対象 | 誤解しやすい点 | そこから言えること |
|---|---|---|---|
| ソフトウェア | cryptsetup、 tcplay、 VeraCrypt、 TrueCrypt 本体など、実際に媒体を開いたり作成したりする実装を指す。 | ソフトウェアが古いことと、媒体形式が直ちに無効になることは同じではない。 | 保守終了した本体を使い続けるかではなく、現役の自由ソフトウェアで同じ形式へ到達できるかを確認する必要がある。 |
| 媒体形式 | LUKS、 TrueCrypt / VeraCrypt 互換ボリューム、 BITLK、旧 FileVault2 など、ディスク上に記録された構造を指す。 | 形式を読めることと、その形式を完全に作成・変更・復旧できることは同じではない。 | LUKS のように深く管理できる形式と、外部形式として条件付きで開ける形式を分けて扱う必要がある。 |
| カーネル経路 | dm-crypt、 dm-verity、 dm-integrity、 kernel crypto API など、開いた後の実データ処理を担う層を指す。 | ユーザー空間ツールの名前だけを見ても、実際の読み書き経路は判断できない。 | cryptsetup で開いた後の実 I/O は Linux の標準経路に載るため、古い本体実装とは別に評価できる。 |
| ファイルシステム | ext4、 FAT、 exFAT、 NTFS、 HFS+、 APFS など、復号後のブロックデバイス上の構造を指す。 | 暗号化レイヤーを開けても、中のファイルシステムを安全に読み書きできるとは限らない。 | 暗号形式の対応と、ファイルとして読めるか、壊さず更新できるかは別に評価する必要がある。 |
| 信頼性 | 読めること、改ざんされていないこと、復旧できること、運用を継続できることを分けて評価する。 | 暗号化していることだけでは、長期的な信頼性は保証されない。 | 秘匿性、完全性、復元可能性、保守可能性を分け、必要なレイヤーを選ぶ必要がある。 |
2. Debian パッケージだけで実現できる範囲を先に整理する
暗号化媒体を扱うときに最初に分けるべきなのは、どのコマンドを使うかではなく、何を保護したいのかという目的である。保存内容を第三者に読まれないようにしたい場合は暗号化が必要になる。保存内容が後から書き換えられていないことを確認したい場合は完全性検証が必要になる。古い TrueCrypt 媒体や Windows の BitLocker 媒体を Linux で読みたい場合は、既存形式を Linux のブロックデバイスとして開く互換マッピングが必要になる。これらは似て見えるが、守っている対象が違う。暗号化は秘匿性を担当し、完全性検証は改ざん検出を担当し、互換マッピングは既存形式を Linux 上で扱える形に変換する入口を担当する。
ここでいうブロックデバイスとは、ディスクやパーティションのように、一定の大きさのブロック単位で読み書きされる記憶領域である。通常のファイルシステムは、このブロックデバイスの上に作られる。暗号化ブロックデバイスとは、実ディスクとファイルシステムの間に暗号化レイヤーを挟み、上位のファイルシステムからは通常のディスクのように見える一方で、下位の実ディスクには暗号化されたデータを書き込む仕組みである。 Linux では、この種の変換を device-mapper という仕組みで扱い、その中で暗号化を担当する代表的な機能が dm-crypt である。
Debian の cryptsetup-bin パッケージは、 cryptsetup、 integritysetup、 veritysetup を提供する。 cryptsetup は暗号化ブロックデバイスや既存暗号化形式のマッピングを扱う入口であり、 integritysetup は読み書き可能な完全性保護ブロックデバイスを扱い、 veritysetup は読み取り専用の検証用ブロックデバイスを扱う[8]。つまり、 Debian の通常パッケージだけで、秘匿性、読み取り専用の改ざん検証、読み書き可能な完全性保護という 3 つの入口がそろう。さらに tcplay パッケージは、 dm-crypt に基づく TrueCrypt / VeraCrypt 互換実装として提供され、 TrueCrypt / VeraCrypt 互換ボリュームの作成、開閉、 hidden volume などを扱う[9]。この時点で、 Debian パッケージだけでも、暗号化媒体の対応範囲は LUKS に閉じていない。
ただし、「扱える」という言葉は慎重に使う必要がある。ある形式を開けること、同じ形式を新規作成できること、既存ヘッダーを変更できること、鍵を追加・削除できること、改ざんを検出できること、破損時に復旧しやすいことは、すべて別の能力である。 cryptsetup は LUKS では作成、鍵管理、ヘッダーバックアップ、再暗号化まで深く扱える。一方、 TrueCrypt / VeraCrypt 互換ボリュームや BitLocker では、既存ヘッダーを解釈して Linux にマッピングすることが中心になる。 tcplay は TrueCrypt / VeraCrypt 互換ボリュームの形式管理を補うが、 LUKS 管理の主役ではない。 veritysetup は読み取り専用検証を担い、 integritysetup は読み書き可能な完全性保護を担うが、どちらも暗号化形式そのものではない。
この違いを押さえるために、まず目的ごとに Debian パッケージで実現できる範囲を整理する。表は単なるコマンド一覧ではなく、「どの目的に対して、どの自由ソフトウェアが、どの範囲まで責任を持つのか」を分けるための地図である。
| 目的 | 主な自由ソフトウェア | できること | できないこと・注意点 |
|---|---|---|---|
| Linux で新規暗号化媒体を作る | cryptsetup + LUKS2 | LUKS2 形式の暗号化媒体を作成し、鍵スロット管理、ヘッダーバックアップ、再暗号化などを一体で扱える。 | 暗号化は内容を読まれにくくする仕組みであり、鍵紛失、ヘッダー破損、媒体故障、誤削除そのものは防げない。 |
| ヘッダーなし暗号化を扱う | cryptsetup + plain dm-crypt | 媒体上に LUKS ヘッダーを持たない最小構成の暗号化ブロックデバイスを作れる。 | 暗号方式、鍵サイズ、オフセットなどの暗号パラメーターを別途正確に管理できなければ復旧困難になる。 |
| TrueCrypt / VeraCrypt 互換ボリュームを開く | cryptsetup の TCRYPT 拡張 | 既存の TrueCrypt、 tcplay、 VeraCrypt 暗号化パーティションを Linux のブロックデバイスとしてマッピングできる。 | ここでいう TCRYPT は cryptsetup の機能名であり、媒体形式を一般に説明する場合は TrueCrypt / VeraCrypt 互換形式と呼び分ける方が正確である。 cryptsetup は既存ヘッダーの作成や変更を基本的に担当しない。 |
| TrueCrypt / VeraCrypt 互換ボリュームを作成・変更する | tcplay | 通常ボリューム、 system volume、 hidden volume、パスフレーズ変更、キーファイル変更、ヘッダー復元など、 TrueCrypt / VeraCrypt 互換形式の管理を扱える。 | tcplay は TrueCrypt / VeraCrypt 互換形式を扱う自由ソフトウェア実装であるが、 VeraCrypt 本体の全機能や最新仕様を完全に代替するとは限らない。 |
| BitLocker 媒体を開く | cryptsetup の BITLK 拡張 | 回復キーやパスワードなど Linux 側に提示できる鍵素材がある場合に、既存 BitLocker / BitLocker To Go 媒体を Linux にマッピングできる。 | Windows の TPM 自動解除、 Active Directory 連携、管理ポリシーなどを Linux 側で再現するものではなく、既存媒体を条件付きで開く機能として理解する必要がある。 |
| 旧 FileVault2 媒体を開く | cryptsetup の FileVault2 対応 | 古い Core Storage + HFS+ 系 FileVault2 媒体を扱える場合がある。 | 現在の macOS で一般的な APFS FileVault を広く扱えるという意味ではなく、 FileVault2 対応は対象形式を限定して理解する必要がある。 |
| 読み取り専用の改ざん検証を行う | veritysetup + dm-verity | ハッシュツリーにより、読み取り時にブロック単位で内容が事前計算された値と一致するかを検証できる。 | dm-verity は読み取り専用の検証に向く仕組みであり、通常の読み書き更新を行うデータ領域には向かない。 |
| 読み書き可能な完全性保護を行う | integritysetup + dm-integrity | セクター単位の integrity tag により、読み書き可能なブロックデバイスに完全性保護を追加できる。 | データ本体に加えてタグも管理するため、容量、書き込み量、クラッシュ時の一貫性、性能に追加コストが発生する。 |
この表から分かるのは、 Debian パッケージだけで実現できる範囲がかなり広い一方で、各機能が同じ種類の安全性を提供しているわけではないということである。 LUKS2 は Linux で新規に暗号化媒体を作る場合の中心になる。 TrueCrypt / VeraCrypt 互換形式は、 cryptsetup で既存媒体を開き、 tcplay で形式管理を補う。 BitLocker や旧 FileVault2 は、 Linux から既存媒体へ到達するための互換入口として扱う。 dm-verity と dm-integrity は暗号化ではなく、完全性を扱う別レイヤーである。したがって、自由ソフトウェアだけで暗号化媒体をかなり扱えるという結論は正しいが、その意味は「すべての形式を同じ深さで自由に作成・変更・復旧できる」ということではない。
3. cryptsetup は暗号化媒体と互換形式を Linux の標準経路へ接続する入口である
cryptsetup は LUKS 専用の道具ではない。 cryptsetup プロジェクトは、 plain volume、 LUKS volume、 loop-AES、 TrueCrypt、 VeraCrypt extension、 BitLocker、 FileVault2 を対応形式として挙げている[10]。また、 cryptsetup の man page では、 LUKS の各種操作だけでなく、 TrueCrypt / VeraCrypt 互換、 BITLK、 FileVault2、 loop-AES などの限定対応も説明されている[11]。したがって、 cryptsetup を単に「LUKS を作るコマンド」と捉えると、 Linux が既存暗号化媒体を扱う能力を見落とす。より正確には、 cryptsetup は、暗号化媒体のヘッダーを読み、鍵を導出し、暗号方式やデータ開始位置などの情報を整理し、それを Linux カーネルの device-mapper へ渡すためのユーザー空間の入口である。
ここでいう device-mapper とは、物理ディスクやパーティションをそのまま使うのではなく、その上に変換レイヤーを作り、別のブロックデバイスとして見せる Linux カーネルの仕組みである。たとえば、暗号化デバイスでは、実ディスクには暗号化されたブロックが置かれているが、上位のファイルシステムからは復号済みの通常ディスクのように見える。 cryptsetup は、この変換レイヤーを自分だけで実装するのではなく、必要な設定を組み立てて device-mapper に登録する。つまり、 cryptsetup は暗号化データを毎回自力で読み書きするアプリケーションではなく、暗号化ブロックデバイスを Linux カーネルの標準機構として成立させるための設定者である。
この仕組みを理解すると、 cryptsetup が複数の暗号形式を扱える理由も見えやすくなる。暗号化媒体には、少なくとも 3 種類の情報がある。第一に、どの暗号方式とモードを使うかという暗号パラメーターがある。第二に、パスフレーズやキーファイルから実際の暗号鍵を得るための鍵導出情報がある。第三に、暗号化された実データが媒体上のどこから始まるかという配置情報がある。 LUKS、 TrueCrypt / VeraCrypt 互換形式、 BitLocker、 FileVault2 は、それぞれヘッダー構造や鍵管理の方法が異なるが、最終的には「どの鍵で、どの範囲を、どの暗号方式で、どのブロックデバイスとして見せるか」という問題へ落とし込まれる。 cryptsetup は、この落とし込みを形式ごとに行い、 Linux 側の標準的なブロックデバイス処理へ接続する。
| 層 | 役割 | 具体例 | 誤解しやすい点 |
|---|---|---|---|
| 媒体上の形式 | 暗号化媒体がどのようなヘッダー、鍵導出情報、暗号パラメーター、データ配置を持つかを決める。 | LUKS、 plain dm-crypt、 TrueCrypt / VeraCrypt 互換形式、 BitLocker、 FileVault2 などが該当する。 | 形式を読めることと、その形式を新規作成・変更・完全管理できることは同じではない。 |
| cryptsetup | 媒体上の形式を解釈し、鍵導出を行い、 Linux カーネルへ渡す暗号設定を組み立てる。 | LUKS では作成、開閉、鍵管理、ヘッダーバックアップ、再暗号化まで扱い、互換形式では既存ヘッダーを読んでマッピングする。 | cryptsetup 自体がすべての読み書き暗号処理をユーザー空間で実行しているわけではない。 |
| device-mapper | 実デバイスの上に変換レイヤーを作り、別のブロックデバイスとして見せる。 | 暗号化された実ディスクを、復号済みの通常ブロックデバイスのように /dev/mapper 配下へ見せる。 | device-mapper は暗号専用ではなく、暗号化、完全性、スナップショットなど複数の変換レイヤーを扱う基盤である。 |
| dm-crypt | device-mapper の crypt target として、読み書きされるブロックを透過的に暗号化・復号する。 | 上位から平文ブロックを書き込むと暗号文として実ディスクに保存し、読み出し時には暗号文を復号して上位へ返す。 | TrueCrypt / VeraCrypt 互換ボリュームを cryptsetup で開いた後も、通常の読み書きは TrueCrypt 本体ではなく dm-crypt の経路に乗る。 |
| kernel crypto API | カーネル内で利用される暗号アルゴリズムや暗号モードの実装を提供する。 | AES、 XTS、ハッシュ、暗号支援命令を利用する実装などが関係する。 | 媒体形式の互換性と暗号実装の安全性は別問題であり、 TrueCrypt 本体の暗号実装をそのまま使うという意味ではない。 |
| ファイルシステム | 復号済みブロックデバイスの上に、ファイルやディレクトリとしての構造を作る。 | ext4、 FAT、 exFAT、 NTFS、 HFS+ などが該当する。 | 暗号化媒体を開けても、内部ファイルシステムを Linux が適切に読めなければ、実際のファイル操作は制限される。 |
ただし、 cryptsetup がすべての形式を同じ深さで管理するわけではない。 LUKS では、 cryptsetup はヘッダー、鍵スロット、 KDF、再暗号化、バックアップなど、形式そのものの管理者として働く。 KDF とは key derivation function、つまりパスフレーズのような人間が入力する秘密情報から、実際に暗号処理で使う鍵を導く処理である。鍵スロットとは、同じ暗号化媒体を複数のパスフレーズや鍵素材で開けるようにするための格納領域である。 LUKS では、これらの管理情報が形式として設計されているため、 cryptsetup が作成、追加、削除、バックアップ、再暗号化まで深く扱える。
一方、 TrueCrypt / VeraCrypt 互換ボリュームや BitLocker では、 cryptsetup の役割は少し違う。これらは Linux のために cryptsetup が設計した形式ではなく、別のソフトウェアや別の OS で使われてきた既存形式である。そのため、 cryptsetup は既存ヘッダーを解釈し、必要な鍵素材と暗号パラメーターを取り出し、 Linux の device-mapper mapping として開くことを中心に担う。 cryptsetup-open の文書も、 open 操作を通じて暗号化デバイスを device-mapper mapping として開くことを説明している[12]。このため、「cryptsetup で開ける」という事実は、「cryptsetup でその形式を LUKS と同じ深さで作成・変更・管理できる」という意味ではない。
| 対象形式 | cryptsetup の役割 | 管理の深さ | 実務上の意味 |
|---|---|---|---|
| LUKS1 / LUKS2 | Linux ネイティブな暗号化コンテナとして作成、開閉、鍵管理、ヘッダーバックアップ、再暗号化を扱う。 | 深い。 | 新規に Linux で暗号化媒体を作る場合の主対象になる。 |
| plain dm-crypt | ヘッダーを持たない暗号化ブロックデバイスとして開く。 | 低レベルであり、管理情報は外部管理になる。 | 最小構成だが、暗号パラメーターを失うと復旧が難しい。 |
| loop-AES | 古い Linux 暗号化形式を互換的に扱う。 | 限定的である。 | 既存資産の参照対象であり、新規採用の中心にはならない。 |
| TrueCrypt / VeraCrypt 互換形式 | TCRYPT 拡張として既存ヘッダーを解釈し、 Linux のブロックデバイスとしてマッピングする。 | 開閉中心であり、ヘッダー作成やヘッダー変更は基本的に対象外である。 | 既存 TrueCrypt / VeraCrypt 互換媒体を、 TrueCrypt 本体ではなく Linux 標準経路で扱う入口になる。 |
| BitLocker / BitLocker To Go | BITLK 拡張として既存 BitLocker 媒体を条件付きでマッピングする。 | 限定的である。 | 回復キーやパスワードなどの鍵素材がある場合に、 Linux から既存 Windows 暗号化媒体へ到達できる可能性がある。 |
| FileVault2 | 古い Core Storage + HFS+ 系 FileVault2 を条件付きで扱う。 | 限定的である。 | 現在の APFS FileVault 全般を扱えるという意味ではなく、対象形式を限定して理解する必要がある。 |
開いた後の実データ処理では、 Linux カーネルの dm-crypt が重要になる。 dm-crypt は device-mapper の crypt target であり、ブロックデバイスに対する読み書きを透過的に暗号化・復号する。ここでの「透過的」とは、上位のファイルシステムやアプリケーションから見ると通常のブロックデバイスのように見えるが、下位ではカーネルが暗号処理を挟むという意味である[13]。たとえば、ファイルシステムがあるブロックを読み出すと、実ディスクからは暗号化されたブロックが読み込まれ、 dm-crypt がそれを復号し、上位には平文のブロックとして渡す。逆に書き込み時には、上位から渡された平文ブロックを dm-crypt が暗号化し、実ディスクには暗号文として保存する。
この構造により、 cryptsetup は単なる解除コマンドではなく、暗号化媒体を Linux の標準ブロック I/O 経路へ接続する入口になる。 TrueCrypt / VeraCrypt 互換ボリュームを例にすると、 cryptsetup は TrueCrypt 本体の古い I/O 実装を使って読み書きするわけではない。 cryptsetup が互換ヘッダーを解釈し、必要な暗号パラメーターを dm-crypt に渡した後は、通常の読み書きは Linux カーネルの dm-crypt と kernel crypto API の経路に乗る。したがって、オリジナルの TrueCrypt ソフトウェアを使うかどうかと、 TrueCrypt / VeraCrypt 互換形式の媒体を Linux で読み書きできるかどうかは、分けて考える必要がある。
この分離は、信頼性と速度の評価にも関係する。信頼性の面では、 cryptsetup で開いたデバイスは /dev/mapper 配下の通常のブロックデバイスとして扱えるため、 lsblk、 mount、 umount、 systemd、 udev など Linux の標準的な管理経路と接続しやすい。速度の面では、暗号化・復号処理が Linux カーネル側の dm-crypt と kernel crypto API に乗るため、 CPU の暗号支援やカーネルのブロック I/O 経路を利用できる。ただし、これだけで常に高速になるという意味ではない。実際の速度は、暗号方式、 CPU、 USB、 HDD や SSD の性質、ファイルシステム、小ファイル数、ランダム I/O、完全性レイヤーの有無によって決まる。
したがって、 cryptsetup の役割は 2 層に分けて理解するのが正確である。第一に、 LUKS のような Linux ネイティブ形式では、 cryptsetup は暗号化媒体の作成、鍵管理、ヘッダー管理、再暗号化まで担う管理工具である。第二に、 TrueCrypt / VeraCrypt 互換形式、 BitLocker、旧 FileVault2 のような既存形式では、 cryptsetup は既存ヘッダーを解釈し、 Linux の標準ブロックデバイス経路へ接続する互換入口である。この違いを押さえることで、 cryptsetup を過小評価せず、同時に過大評価もしない整理ができる。
4. LUKS は自由ソフトウェアだけで最も深く管理できる暗号化形式である
新規に Linux 用の暗号化媒体を作る場合、 LUKS は自由ソフトウェアだけで最も深く管理できる暗号化形式である。ここでいう「深く管理できる」とは、単に暗号化されたブロックデバイスを開けるという意味ではない。暗号化媒体を作成し、複数の解除手段を持たせ、鍵を追加・削除し、ヘッダーを退避し、必要に応じて再暗号化し、将来の復旧条件を文書化しやすいという意味である。 LUKS2 にはオンディスク形式仕様があり、 LUKS1 にも従来仕様があるため、暗号化データ領域だけでなく、復号に必要なメタデータ構造も文書化されている[14][15]。 Red Hat の文書でも、 LUKS はブロックデバイス暗号化を扱い、複数のユーザーキーでマスターキーを復号できる仕組みとして説明されている[16]。
LUKS を理解するうえで重要なのは、実際にデータを暗号化する鍵と、人間が入力するパスフレーズを分けて考えることである。人間が入力するパスフレーズは、そのままディスク全体の暗号鍵になるわけではない。 LUKS では、データ領域を暗号化する実鍵、つまりマスターキーまたはボリュームキーを別に持ち、それを複数のパスフレーズや鍵素材で保護する。鍵スロットとは、この解除手段を格納する場所である。これにより、同じ暗号化媒体を通常用パスフレーズ、非常用パスフレーズ、管理用鍵など複数の経路から開けるようにできる。これは単なる利便性ではなく、長期運用における復旧可能性を高める仕組みである。
KDF も LUKS の管理性を理解するために重要である。 KDF とは key derivation function の略で、人間が覚えられるパスフレーズから、暗号処理に使える鍵素材を導く処理である。パスフレーズは一般に機械生成された乱数鍵より弱いため、そのまま使うと総当たり攻撃に弱くなる。 KDF は計算コストやメモリコストを加え、攻撃者が大量の候補を高速に試すことを難しくする。 LUKS2 では、このような鍵導出やメタデータ管理を形式として扱えるため、単に暗号化するだけでなく、将来の運用変更にも対応しやすい。
LUKS が扱いやすい理由は、暗号方式が強いからだけではない。運用上は、パスフレーズをどう追加・削除するか、非常用の解除手段をどう残すか、 LUKS ヘッダーをどうバックアップするか、将来の再暗号化をどう行うかが重要になる。 LUKS はこれらを形式として持つため、 cryptsetup から一貫して扱える。これに対して plain dm-crypt はヘッダーを持たないため、暗号方式、鍵サイズ、 IV モード、オフセットなどのパラメーターを別途正確に保持しなければ復旧できない。 plain dm-crypt の単純さは利点だが、その単純さは管理情報を媒体上に持たないという意味でもあるため、長期保全では復旧条件を失いやすい。
この差は、「暗号化できること」と「長期にわたり復元可能な形で暗号化できること」の違いとして現れる。暗号化だけなら plain dm-crypt でも可能である。しかし、数年後に媒体を別環境へ接続し、どの暗号方式で、どの鍵長で、どのオフセットから、どの IV モードで開くべきかを再現できなければ、暗号化されたデータは実質的に失われる。 LUKS では、この種の復号に必要な条件がヘッダーに集約されるため、暗号化媒体を「現在開けるもの」ではなく「将来も開く条件を残しやすいもの」として扱える。
| 形式 | できること | できないこと・弱いこと | そこから言えること |
|---|---|---|---|
| LUKS2 | ヘッダー、鍵スロット、 KDF、トークン、メタデータ、ヘッダーバックアップ、再暗号化などを cryptsetup で一体的に管理できる。 | 媒体故障、誤削除、鍵紛失、ヘッダーバックアップ未取得、復旧手順の喪失までは防げない。 | 新規 Linux 暗号化媒体の主系として最も扱いやすいが、バックアップ、鍵管理、手順書、復旧検証と組み合わせて初めて長期運用になる。 |
| LUKS1 | 従来形式として広く使われ、鍵スロットとヘッダー管理を持ち、古い環境との互換性も比較的高い。 | LUKS2 と比べるとメタデータ拡張性や現代的な管理機能は限定される。 | 既存資産や古い環境との互換性を重視する場合には意味があるが、新規設計では LUKS2 を中心に考える方が自然である。 |
| plain dm-crypt | ヘッダーなしで最小構成の暗号化ブロックデバイスを構成でき、媒体上に LUKS ヘッダーを残さない運用もできる。 | 暗号方式、鍵サイズ、 IV モード、オフセットなどのパラメーターを失うと、正しい鍵を持っていても復旧できない可能性がある。 | 単純で柔軟だが、長期バックアップ媒体や将来復旧を重視する媒体では、管理情報を外部で厳密に保全できる場合に限って使うべきである。 |
この表から分かるのは、 LUKS2 が単に「新しい形式」だから重要なのではなく、暗号化媒体を運用対象として管理するための情報を形式の中に持てる点で重要だということである。暗号化媒体では、暗号化した瞬間だけでなく、鍵を更新する時、管理者が変わる時、別の OS や別の機材へ移す時、媒体障害から復旧する時にも、復号条件を再現できなければならない。 LUKS2 は、この再現性を cryptsetup の標準機能として扱いやすい。一方、 plain dm-crypt は構造が単純である反面、復号条件を媒体外に逃がすため、運用者側の台帳や手順書に強く依存する。
ただし、 LUKS2 を使えば何でも解決するわけではない。 LUKS ヘッダーは復号に必要な重要情報を集約するため、破損すると媒体全体を開けなくなる可能性がある。これは、管理情報を持つ形式であることの裏返しである。そのため、 LUKS ではヘッダーバックアップが重要になる。暗号化データ領域が無事でも、ヘッダーと鍵スロットが失われれば、復号に必要な道筋が失われる。つまり、 LUKS の管理性は強みであると同時に、ヘッダー保全という運用上の責任を発生させる。
| 観点 | LUKS でできること | LUKS だけではできないこと | 必要になる運用 |
|---|---|---|---|
| 秘匿性 | ブロックデバイス全体を暗号化し、媒体を取り外しても内容を直接読まれにくくできる。 | 開いた後の状態でのアクセス権限管理、マルウェア、誤操作、アプリケーション経由の漏洩までは防げない。 | マウント後の権限管理、利用者管理、不要時の close、バックアップ先の同等保護が必要になる。 |
| 鍵管理 | 複数の鍵スロットを使い、通常用、非常用、移行用など複数の解除手段を持てる。 | 弱いパスフレーズの選択、鍵の紛失、鍵の共有ミス、手順不備は自動では防げない。 | 鍵の役割分担、保管場所、更新手順、失効手順を文書化する必要がある。 |
| ヘッダー管理 | 復号に必要なメタデータをヘッダーとして管理し、ヘッダーバックアップを取得できる。 | ヘッダーバックアップを取らない運用、バックアップの所在不明、バックアップの不整合までは防げない。 | ヘッダーバックアップの取得、保管、更新タイミング、復元手順の検証が必要になる。 |
| 形式更新 | 再暗号化や鍵管理の変更により、一定範囲で将来の運用変更に対応できる。 | すべての旧環境との互換性を維持しながら無制限に更新できるわけではない。 | 更新前のバックアップ、対象環境の確認、失敗時の復旧計画が必要になる。 |
| 完全性 | LUKS は暗号化媒体として秘匿性を提供し、設定によっては dm-integrity などとの組み合わせも検討できる。 | LUKS 単体で、読み出した全データが改ざんされていないことを常に検証する仕組みになるわけではない。 | 改ざん検出を重視する場合は、 dm-verity、 dm-integrity、ハッシュ記録、バックアップ照合などを別途設計する必要がある。 |
| 復旧可能性 | ヘッダー、鍵スロット、形式情報を標準的に扱えるため、復旧条件を整理しやすい。 | 媒体故障、バックアップ不足、手順喪失、人的ミスを単独では解決できない。 | 複数媒体へのバックアップ、復旧手順書、定期的な復旧検証が必要になる。 |
ここから言えるのは、 LUKS は「暗号化の答え」ではなく、「Linux で暗号化媒体を管理可能な形にするための最も整った形式」だということである。 LUKS2 を使うことで、暗号化、鍵管理、ヘッダー管理、再暗号化の多くを自由ソフトウェアだけで扱える。しかし、暗号化媒体の長期保全では、 LUKS の外側にある問題も残る。鍵をどう保管するか、ヘッダーをどこへ退避するか、復旧手順を誰が再現できるか、媒体が壊れたときに別コピーがあるか、読み出した内容の完全性をどう確認するかは、 LUKS だけでは完結しない。
したがって、新規に Linux 用の暗号化媒体を作る場合は LUKS2 を主系に置くのが合理的である。ただし、その理由は「ほかの形式より常に暗号が強いから」ではない。 LUKS2 は、暗号化媒体を作り、鍵を管理し、ヘッダーを保全し、将来の変更に備えるための標準的な管理面を備えているからである。この点で、 LUKS2 は自由ソフトウェアだけで最も深く管理できる暗号化形式であり、 plain dm-crypt や外部互換形式とは役割が異なる。
5. TrueCrypt 本体と TrueCrypt / VeraCrypt 互換ボリューム形式は分けて考える
TrueCrypt については、最初に表現を正確にする必要がある。 TrueCrypt という古いソフトウェア本体と、媒体上に残っている TrueCrypt / VeraCrypt 互換ボリューム形式は同じではない。 cryptsetup の文脈では TCRYPT 拡張という機能名が使われ、 cryptsetup-tcryptDump の文書でも TCRYPT は TrueCrypt または VeraCrypt compatible device と説明されている[17]。したがって、本稿では、 cryptsetup の機能名を指す場合は TCRYPT 拡張、媒体上の互換形式を一般に指す場合は TrueCrypt / VeraCrypt 互換ボリューム形式、ヘッダー構造を指す場合は TCRYPT ヘッダーと呼ぶ。この呼び分けは単なる用語の整形ではない。ソフトウェア、媒体形式、互換実装、暗号処理の経路を分けなければ、移行判断を誤るからである。
TrueCrypt 本体は公式に保守が終了し、公式ページも移行を促す内容へ変わった[18]。また、 TrueCrypt License は独自ライセンスであり、 GNU のライセンス一覧でも自由ソフトウェアライセンスとしては扱われていない[19][20]。しかし、この事実から直ちに「TrueCrypt / VeraCrypt 互換ボリューム形式で暗号化された既存媒体は無効である」とは言えない。保守終了したのは TrueCrypt 本体というソフトウェアであり、媒体上の暗号化形式がその瞬間に読めなくなったわけではない。ソフトウェア本体の保守状態、ライセンス上の扱い、媒体形式の暗号学的性質、互換実装で読み書きできるかどうかは、それぞれ別の評価軸である。
この分離が重要になるのは、既存媒体の移行判断である。 TrueCrypt 本体と TrueCrypt / VeraCrypt 互換ボリューム形式を同一視すると、判断は「古い TrueCrypt を使い続けるか、それともすべてを新形式へ移すか」という二択になりやすい。しかし実際には、より細かい判断が可能である。 TrueCrypt 本体を通常運用から外しながら、既存の TrueCrypt / VeraCrypt 互換ボリューム形式を cryptsetup で読み、必要に応じて tcplay で形式管理を補うという第三の選択肢がある。この場合、古いソフトウェアを使い続けるリスクと、既存媒体を即時全面移行するコストを切り離せる。
移行判断では、「ソフトウェアが古いから形式も直ちに廃棄する」という短絡を避ける必要がある。暗号化媒体には、少なくとも 4 つの寿命がある。第一に、ソフトウェア本体の寿命がある。これは開発・保守・配布・ライセンスの問題である。第二に、媒体形式の寿命がある。これはヘッダー構造、鍵導出、暗号方式、互換実装の有無の問題である。第三に、暗号学的寿命がある。これは使われている暗号方式、鍵長、 KDF、既知の攻撃に対する耐性の問題である。第四に、運用寿命がある。これは現在の OS、パッケージ、ファイルシステム、バックアップ手順、復旧手順で扱えるかどうかの問題である。 TrueCrypt 本体の寿命が尽きていても、互換形式としての運用寿命が残っている場合はある。
| 評価軸 | 見る対象 | TrueCrypt 周辺での意味 | 移行判断への影響 |
|---|---|---|---|
| ソフトウェア寿命 | TrueCrypt 本体の保守、配布、ライセンス、現代 OS との統合状態 | TrueCrypt 本体は保守終了しており、独自ライセンスを持つ古いソフトウェアである。 | TrueCrypt 本体を通常運用の中心に置く理由は弱くなる。 |
| 形式寿命 | 媒体上のヘッダー構造、鍵導出情報、暗号パラメーター、互換実装の有無 | TrueCrypt / VeraCrypt 互換ボリューム形式は cryptsetup や tcplay で扱える範囲がある。 | 既存媒体を即時廃棄せず、互換実装で読み出し・保全・段階移行できる可能性がある。 |
| 暗号学的寿命 | 暗号方式、鍵長、 KDF、ヘッダー認証、既知の監査結果 | AES-XTS などの暗号部品だけでなく、 keyfile 処理やヘッダー構造など形式固有の論点も評価対象になる。 | 低リスクの保管媒体として残すか、重要データを LUKS2 などへ移すかをリスク別に判断する必要がある。 |
| 運用寿命 | 現在の Linux、 Debian パッケージ、 dm-crypt、ファイルシステム、復旧手順で扱えるかどうか | cryptsetup で開ける媒体は Linux の標準ブロックデバイス経路に載せられる。 | 古い TrueCrypt 本体を使わずに運用継続できるため、全面移行の緊急度を下げられる場合がある。 |
ここから言えるのは、移行判断は「古いか新しいか」ではなく、「どの層の寿命が尽きているのか」で行うべきだということである。 TrueCrypt 本体のソフトウェア寿命は尽きている。しかし、 TrueCrypt / VeraCrypt 互換ボリューム形式の形式寿命は、互換実装が存在する限り直ちには尽きない。暗号学的寿命については、利用している暗号方式、鍵導出、パスフレーズ強度、監査結果を見て判断する必要がある。運用寿命については、 cryptsetup や tcplay が Debian パッケージとして利用でき、 Linux の dm-crypt 経路で扱えるかどうかが重要になる。したがって、 TrueCrypt 本体の保守終了は重要な警告であるが、それだけで既存媒体の即時全面移行を必ず意味するわけではない。
この整理は、移行コストとリスクの比較にも影響する。もし TrueCrypt 本体でしか読めない媒体であれば、保守終了したソフトウェアへの依存が強いため、早期移行の優先度は高くなる。しかし、 cryptsetup で保守的に開け、 tcplay で必要な形式管理を補える媒体であれば、移行判断は少し変わる。重要データや頻繁に更新するデータは LUKS2 などの現行形式へ移す合理性が高い。一方、読み取り中心の互換バックアップや、更新頻度が低く、別系統のバックアップも存在する媒体であれば、即時全面移行ではなく、段階的移行や読み取り中心運用を選べる。これは古い方式を無条件に肯定する話ではなく、ソフトウェア本体のリスクと媒体形式の残存利用価値を分けて評価するという話である。
| 状況 | 判断 | 理由 | 抽象化できる原則 |
|---|---|---|---|
| TrueCrypt 本体でしか開けない | 移行優先度は高い。 | 保守終了した独自ライセンスの古いソフトウェアに運用が依存しているためである。 | 現行環境で再現できない形式は、媒体が読めるうちに移行する必要がある。 |
| cryptsetup で安定して開ける | 即時全面移行ではなく、重要度に応じた段階移行を選べる。 | TrueCrypt 本体に依存せず、 Linux 標準の dm-crypt 経路へ接続できるためである。 | 互換実装がある形式は、旧ソフトウェアから切り離して運用寿命を延ばせる。 |
| tcplay で形式管理までできる | 既存形式の維持・変更・救出の選択肢が増える。 | 作成、変更、 hidden volume、ヘッダー復元など、 cryptsetup が担わない領域を補えるためである。 | 形式管理を担う自由ソフトウェアがあれば、保守終了ソフトウェアへの依存をさらに下げられる。 |
| 重要データを長期に更新し続ける | LUKS2 など現行の管理しやすい形式へ移す合理性が高い。 | 鍵管理、ヘッダーバックアップ、再暗号化、将来の運用変更を cryptsetup で一体的に扱いやすいためである。 | 更新され続ける主系データは、互換維持より管理可能性を優先するべきである。 |
| 読み取り中心の互換バックアップ | 互換実装で読める限り、段階的に残す判断も成立する。 | 更新頻度が低く、主系ではなく、別のバックアップ系統もあるなら、即時全面移行の費用対効果が下がるためである。 | バックアップの役割が参照・保全中心なら、形式の新しさだけでなく復元可能性と移行コストを比較する必要がある。 |
ここで重要なのは、移行しないことを正当化することではない。むしろ逆である。何を理由に移行し、何を理由に残すのかを明確にするために、ソフトウェアと形式を分ける必要がある。 TrueCrypt 本体を使い続けることは、保守終了した古い実装への依存を残す。しかし、 TrueCrypt / VeraCrypt 互換ボリューム形式を cryptsetup や tcplay で扱うことは、必ずしも同じ依存ではない。前者は古いソフトウェアへの依存であり、後者は互換形式を自由ソフトウェアの実装で扱うという選択である。
この考え方は TrueCrypt に限らない。古い技術資産では、ソフトウェア本体、ファイル形式、プロトコル、媒体、実装、運用手順が一体に見えやすい。しかし、長期保全ではこれらを分解する必要がある。ソフトウェア本体が古くても、形式が文書化または解析され、自由ソフトウェアの互換実装で読めるなら、資産を救出できる可能性がある。逆に、暗号方式が現代的でも、ヘッダー情報、鍵素材、復旧手順、対応実装が失われていれば、実用上は復元不能になる。つまり、長期保全で重要なのは、特定ソフトウェアの存続ではなく、形式、実装、鍵、手順を分離し、それぞれを再現可能な状態に置くことである。
したがって、 TrueCrypt 周辺から一般化できる結論は、暗号化媒体の移行判断では「古いソフトウェアだから全部捨てる」「今も読めるから何もしない」という両極端を避けるべきだということである。ソフトウェア寿命、形式寿命、暗号学的寿命、運用寿命を分け、どの層に問題があるのかを見極める。そのうえで、主系データは現行形式へ移し、互換バックアップは読める状態を確認しながら段階的に保全し、必要なら自由ソフトウェアの互換実装で形式管理を補う。このように分解して考えることで、古い暗号化媒体を過信せず、同時に不必要な全面移行コストも避けられる。
6. TrueCrypt 本体より cryptsetup を優先する理由を分けて考える
既存の TrueCrypt / VeraCrypt 互換ボリュームを Linux で開く場合、オリジナルの TrueCrypt 本体より cryptsetup を優先する理由は、単に「新しいから」ではない。より正確には、サポート、ライセンス、実装経路、既存媒体を変更しない性質、信頼性、セキュリティ評価、運用統合、速度を分けて評価した結果、現代の Linux 運用では cryptsetup を入口にする方が合理的だということである。 TrueCrypt 本体は歴史的には元の実装であるが、保守終了した古いソフトウェアであり、独自ライセンスを持ち、現代 Linux の標準的なブロックデバイス管理に自然に統合される道具ではない。これに対して cryptsetup は、 Debian パッケージとして提供され、 Linux の device-mapper、 dm-crypt、 kernel crypto API に接続する現在の標準経路を使う。
第一の理由は、サポートの観点である。暗号化媒体は、開けた瞬間だけでなく、数年後にも同じように開けることが重要になる。そのためには、現在の OS、現在のカーネル、現在のパッケージ管理、現在のドキュメント体系の中で保守されているソフトウェアを優先するのが基本になる。 TrueCrypt 本体は公式に保守が終了し、公式ページも移行を促す内容になっている[18]。一方、 cryptsetup は Linux の暗号化ブロックデバイスを扱う現役のプロジェクトであり、 Debian パッケージとしても通常の管理対象に入る。つまり、問題が起きたときに参照すべき man page、パッケージ、カーネル機能、バグ報告先、ディストリビューション側の更新経路が残っている。この差は、長期運用では単なる好みではなく、復旧可能性そのものに関わる。
第二の理由は、ライセンスの観点である。 TrueCrypt License は独自ライセンスであり、 GNU のライセンス一覧でも自由ソフトウェアライセンスとしては扱われていない[19][20]。このため、自由ソフトウェアだけで暗号化媒体をどこまで扱えるかを整理する記事では、 TrueCrypt 本体を通常運用の前提に置くべきではない。重要なのは、 TrueCrypt 本体を使わなければ TrueCrypt / VeraCrypt 互換ボリューム形式を扱えないわけではないという点である。 cryptsetup は TrueCrypt / VeraCrypt 本体のコードを使うのではなく、互換ボリュームのヘッダーを解釈し、 Linux 側の標準機構へ接続する。したがって、ライセンス上扱いにくい古い本体と、媒体上に存在する互換ボリューム形式を切り離して運用できる。
第三の理由は、実装経路の観点である。 cryptsetup の man page は、 TrueCrypt、 tcplay、 VeraCrypt の暗号化パーティションを native Linux kernel API でマッピングでき、 TCRYPT ヘッダーのフォーマットや変更はサポートせず、オンデバイスの TCRYPT ヘッダーを変更しないと説明している[11]。これは、 TrueCrypt 本体を内部で動かしているという意味ではない。 cryptsetup は既存ヘッダーを読み、必要な鍵導出と暗号パラメーターを得て、復号済みのブロックデバイスを Linux の device-mapper mapping として提示する。実際の読み書きは、 Linux カーネルの dm-crypt と kernel crypto API の経路に乗る。つまり、古い TrueCrypt アプリケーションの I/O 経路ではなく、現在の Linux カーネルが提供するブロック I/O 経路に接続される。
第四の理由は、既存媒体を保守的に扱えることである。既存の暗号化媒体を読む場面では、まず媒体上のヘッダーやメタデータを不用意に変更しないことが重要になる。 cryptsetup の TCRYPT 拡張は、既存 TrueCrypt / VeraCrypt 互換ボリュームを開く入口であり、 TCRYPT ヘッダーの作成や変更を基本的に担当しない[11]。これは、機能不足というより、既存媒体を読み取り中心で保全する場合には利点になる。パスフレーズ変更、キーファイル変更、 hidden volume 作成、ヘッダー復元のように形式管理へ踏み込む場合は tcplay を検討する。つまり、 cryptsetup は「既存媒体をなるべく変えずに Linux へ接続する道具」、 tcplay は「TrueCrypt / VeraCrypt 互換形式そのものを管理する道具」と分担できる。
ここで不安になりやすいのは、 TrueCrypt 本体ではなく cryptsetup 経由で通常の TrueCrypt / VeraCrypt 互換ボリュームへ書き込んだ場合、保存内容が壊れたり、後から TrueCrypt 系の実装で読めない形に変わったりしないのかという点である。通常の open / read / write / close の範囲では、この不安を過大に見る必要は小さい。 cryptsetup は TCRYPT ヘッダーを読んで、パスフレーズや keyfile から必要な鍵素材を導出し、暗号方式、 IV モード、データ開始位置などを Linux の dm-crypt mapping として構成する。書き込み時には、復号済みブロックデバイス上で発生した変更が dm-crypt に渡され、同じ暗号パラメーターに従って暗号化され、既存ボリュームのデータ領域へ書き戻される。つまり、正しく open できている通常ボリュームであれば、 cryptsetup で書いたこと自体によって別形式へ変換されるわけではない。
ただし、ここでいう安全性は、同じ暗号化ボリュームを単一の経路から開くという前提に立つ。同一の TrueCrypt / VeraCrypt 互換ボリュームを、 TrueCrypt 本体と cryptsetup、または複数の cryptsetup mapping から同時に開いて書き込むべきではない。同時に複数の復号済みブロックデバイス経路を作ると、それぞれの上位ファイルシステムが自分だけが媒体を管理していると仮定して、ディレクトリ、 FAT、空き領域、更新時刻、メタデータを書き換える可能性がある。この場合に壊れる原因は、 cryptsetup の暗号処理が TrueCrypt 本体と違うからではなく、同一のデータ領域に対して複数の独立したブロックデバイスビューから書き込むことによる整合性破壊である。したがって、比較検証や移行作業を行う場合でも、片方を確実に close してからもう一方を open するという排他性が重要になる。
また、通常のデータ書き込みと、 TCRYPT ヘッダーや keyfile 構成を変更する操作は分ける必要がある。 cryptsetup の TCRYPT 対応は、通常の open 操作ではオンデバイスの TCRYPT ヘッダーを変更しない[11]。そのため、ファイルを保存しただけでヘッダーが書き換わり、パスフレーズや形式互換性が変化するという理解は適切ではない。一方、パスフレーズ変更、 keyfile 変更、ヘッダー復元、 hidden volume を含む形式管理に踏み込む場合は、データ領域ではなく形式そのものの管理になるため、 tcplay などの役割と手順を別に評価する必要がある。ここから言えるのは、 cryptsetup 経由の通常読み書きの信頼性は、 TrueCrypt 本体に忠実であることではなく、既存ヘッダーを非破壊で解釈し、単一の dm-crypt 経路として排他的に開き、形式管理操作と通常データ操作を混同しないことで担保されるということである。
| 観点 | TrueCrypt 本体を使う場合 | cryptsetup を使う場合 | そこから言えること |
|---|---|---|---|
| サポート | 保守終了した古いソフトウェアに依存する。 | 現役の Linux パッケージ、 man page、カーネル機能、ディストリビューション更新経路に乗る。 | 長期運用では、元の実装であることよりも、現在保守されている経路で扱えることを優先するべきである。 |
| ライセンス | 独自ライセンスの TrueCrypt 本体を通常運用に含めることになる。 | 自由ソフトウェア側の互換実装として TrueCrypt / VeraCrypt 互換ボリューム形式を扱える。 | ソフトウェア本体と媒体形式を分ければ、ライセンス上扱いにくい本体への依存を下げられる。 |
| 実装経路 | 古い TrueCrypt 本体の実装と統合方式に寄る。 | device-mapper、 dm-crypt、 kernel crypto API という Linux 標準経路に接続する。 | 現代 Linux では、暗号化媒体を標準ブロック I/O 経路へ載せる方が運用しやすい。 |
| 既存媒体への影響 | 形式の正統な実装ではあるが、操作内容によっては古い実装で媒体を変更することになる。 | 既存 TCRYPT ヘッダーを変更せずにマッピングする用途に向く。 | 既存媒体をまず安全に読む場合は、非破壊的に開く入口を優先するべきである。 |
| 通常読み書き | TrueCrypt 本体の経路でデータ領域を読み書きする。 | 既存ヘッダーを解釈した後、 dm-crypt mapping 経由で同じデータ領域を読み書きする。 | 正しく open できている通常ボリュームでは、 cryptsetup 経由で書いたこと自体が別形式への変換やヘッダー変更を意味するわけではない。 |
| 排他性 | cryptsetup など別実装と同時に開くと、同一データ領域へ複数経路から書き込む危険がある。 | TrueCrypt 本体など別経路と同時に開くと、上位ファイルシステムの整合性が崩れる危険がある。 | 危険なのは互換実装で書くこと自体ではなく、同一ボリュームを複数経路から同時に書くことである。 |
| 形式管理 | TrueCrypt 本体で作成・変更できるが、保守終了ソフトウェアへの依存が残る。 | cryptsetup は開閉中心であり、作成・変更は tcplay が補う。 | 開く機能と形式管理機能を分離し、必要な場面だけ tcplay を使う方が整理しやすい。 |
第五の理由は、信頼性の観点である。ここでいう信頼性とは、暗号方式が強いという意味だけではない。運用者が状態を確認できること、標準コマンドでデバイス構成を追えること、マウントとアンマウントが Linux の通常手順に乗ること、異常時に切り分けられること、復旧手順を再現できることを含む。 cryptsetup で開いたデバイスは /dev/mapper 配下のブロックデバイスとして扱えるため、 lsblk、 dmsetup、 mount、 umount、 udev、 systemd など Linux の標準的な管理経路と接続しやすい。これは、普段 LUKS を扱う運用と、 TrueCrypt / VeraCrypt 互換ボリュームを扱う運用を近づける効果を持つ。
第六の理由は、セキュリティ評価を分解しやすいことである。 TrueCrypt 本体の監査で指摘された問題は、すべてが cryptsetup に同じ形で当てはまるわけではない。たとえば、 Windows CryptoAPI への依存に関する問題は、 Linux の cryptsetup、 dm-crypt、 kernel crypto API の経路には基本的に同じ形では現れない。一方で、 TrueCrypt / VeraCrypt 互換ボリューム形式そのものに由来するヘッダー構造や keyfile 処理の性質は、互換形式を扱う限り無視できない。つまり、 TrueCrypt 本体の実装問題、互換ボリューム形式の構造問題、 Linux カーネル暗号実装の問題を分けて評価できることが重要である。 cryptsetup を使うことで、少なくとも TrueCrypt 本体の古い実装に由来する問題と、互換形式そのものに残る問題を切り離しやすくなる。
第七の理由は、監査可能性と切り分け可能性である。暗号化媒体の障害は、パスフレーズ、ヘッダー、鍵導出、暗号方式、カーネル暗号実装、ブロックデバイス、ファイルシステム、物理媒体のどこで起きているかを切り分けなければならない。 TrueCrypt 本体で閉じた運用を続けると、ソフトウェア本体、形式解釈、 I/O、マウント、ファイルシステム処理が一体に見えやすい。 cryptsetup を使うと、ヘッダー解釈と device-mapper mapping、 dm-crypt による暗号処理、ファイルシステムのマウント、物理 I/O を分けて観察しやすい。これは、信頼性だけでなく、障害時の説明可能性にも関係する。
第八の理由は、速度の観点である。速度は最後に置くべきであり、最初の理由にするべきではない。なぜなら、暗号化媒体の速度は、ソフトウェア名だけでは決まらないからである。 cryptsetup で TrueCrypt / VeraCrypt 互換ボリュームを開いた場合、暗号化・復号処理は Linux カーネル側の dm-crypt と kernel crypto API に乗るため、 CPU の暗号支援、カーネルのブロック I/O、キャッシュ、ドライバーの恩恵を受けやすい。しかし、実際の律速要因は、 USB、 HDD / SSD、ファイルシステム、小ファイル数、ランダム I/O、メタデータ更新、完全性レイヤーの有無によって変わる。したがって、「cryptsetup なら常に速い」とは言えないが、「古い TrueCrypt 本体だから安全で速い」と考える理由もない。現代 Linux の標準経路に載せたうえで、実測により判断するのが正しい。
| 理由 | 詳細 | 注意点 | 実務上の結論 |
|---|---|---|---|
| サポート | cryptsetup は現役の Linux パッケージとカーネル機能の上で使える。 | 対応形式ごとに管理できる深さは異なる。 | 通常運用では現役で保守されるソフトウェアを優先する。 |
| ライセンス | TrueCrypt 本体を使わず、自由ソフトウェア側の互換実装で媒体形式を扱える。 | 互換形式の構造的な制約まで消えるわけではない。 | 本体と形式を分け、非自由寄りの本体への依存を下げる。 |
| 非破壊性 | cryptsetup の TCRYPT 拡張は既存ヘッダーを変更せずにマッピングする用途に向く。 | 作成・変更・復旧は tcplay の領域になる。 | 既存媒体をまず読む場合は cryptsetup を優先し、形式管理が必要な場合だけ tcplay を使う。 |
| 信頼性 | /dev/mapper、 lsblk、 dmsetup、 mount、 umount、 udev、 systemd など Linux 標準運用に寄せられる。 | 媒体故障、ファイルシステム破損、パスフレーズ紛失は別問題である。 | 暗号化媒体を通常の Linux ストレージ管理体系に統合できる。 |
| セキュリティ評価 | TrueCrypt 本体の実装問題、互換形式の構造問題、 Linux カーネル暗号実装の問題を分けて評価できる。 | 互換形式に由来する制約は cryptsetup を使っても残る。 | 「TrueCrypt 監査の指摘がそのまま全部 cryptsetup に当たる」とも「全部無関係」とも言わず、層ごとに見る。 |
| 速度 | 開いた後の I/O は dm-crypt と kernel crypto API の経路に乗るため、現代 Linux の暗号処理とブロック I/O を利用できる。 | 実速度は媒体、ファイルシステム、 I/O パターン、完全性レイヤーの有無に依存する。 | 速度は実測で判断し、古い本体を使う方が安全または速いという前提を置かない。 |
ここから言えるのは、 TrueCrypt 本体より cryptsetup を優先する理由は、単一の性能差ではなく、運用全体の設計原則にあるということである。暗号化媒体は、暗号アルゴリズムだけで成立しているわけではない。サポートされるソフトウェア、自由ソフトウェアとしての扱いやすさ、標準カーネル経路、既存媒体を変更しない性質、障害時の切り分け、セキュリティ評価の分解可能性、速度の実測可能性がそろって初めて、長期運用できる媒体になる。 TrueCrypt 本体は形式の歴史的起点ではあるが、現代 Linux の通常運用では、互換形式を cryptsetup と tcplay に分けて扱う方が合理的である。
したがって、既存の TrueCrypt / VeraCrypt 互換ボリュームを Linux で扱う場合の基本方針は明確である。既存媒体を開いて内容を確認する、読み出す、通常の Linux ストレージ管理に載せる場合は cryptsetup を優先する。 TrueCrypt / VeraCrypt 互換形式の作成、パスフレーズ変更、 keyfile 変更、 hidden volume、ヘッダー復元のように形式そのものへ踏み込む場合は tcplay を検討する。 TrueCrypt 本体を使うという判断は、少なくとも通常運用の第一候補ではない。これは TrueCrypt / VeraCrypt 互換ボリューム形式を否定する話ではなく、保守終了したソフトウェア本体と、現在も自由ソフトウェアで扱える媒体形式を切り分ける話である。
7. TrueCrypt 監査の 4 件は、形式起因と実装起因に分けて読む必要がある
TrueCrypt については、セキュリティ評価も「TrueCrypt 本体」「TrueCrypt / VeraCrypt 互換ボリューム形式」「cryptsetup の TCRYPT 拡張」「tcplay」「Linux kernel crypto API」に分けて読む必要がある。 Open Crypto Audit Project の第二段階では、 TrueCrypt の暗号実装を対象にした監査が行われた[21]。その結果として、広く知られている 4 件、すなわち keyfile mixing is not cryptographically sound、 unauthenticated ciphertext in volume headers、 CryptAcquireContext may silently fail、 AES implementation susceptible to cache timing attacks が報告された[22]。 BSI による TrueCrypt 分析も、 TrueCrypt と VeraCrypt を比較するうえで、 TrueCrypt の暗号プリミティブ、実装、互換形式上の論点を整理している[23]。
ここで最初に確認すべきなのは、監査対象が何であったかである。監査で見られたのは、当時の TrueCrypt 本体が持つ暗号処理、鍵処理、ヘッダー処理、 OS 依存処理である。これは、媒体上の TrueCrypt / VeraCrypt 互換ボリューム形式そのものの性質と重なる部分もあるが、完全に同じではない。また、 cryptsetup で既存の TrueCrypt / VeraCrypt 互換ボリュームを開く場合、 TrueCrypt 本体のコードを実行するわけではない。 cryptsetup は TCRYPT 拡張として互換ヘッダーを解釈し、必要な鍵導出と暗号パラメーターを得たうえで、 Linux の device-mapper、 dm-crypt、 kernel crypto API へ接続する。したがって、 TrueCrypt 本体の監査結果を、そのまま全部 cryptsetup に当てはめることも、逆に全部無関係とみなすことも誤りである。
問題を分けるには、まず「形式起因」と「実装起因」を区別する必要がある。形式起因とは、媒体上のヘッダー構造、鍵導出の設計、 keyfile の混ぜ方、認証情報の有無など、 TrueCrypt / VeraCrypt 互換ボリューム形式として扱う限り残りやすい性質である。実装起因とは、特定のソフトウェアがどの暗号ライブラリや OS API を呼び、どの AES 実装を使い、どのエラー処理を行うかという問題である。形式起因の問題は cryptsetup で開いても残る可能性がある。一方、 TrueCrypt 本体の特定コードや Windows API に由来する問題は、 Linux の cryptsetup / dm-crypt 経路では同じ形では現れない。
| 層 | 評価対象 | TrueCrypt 監査との関係 | cryptsetup 使用時の意味 |
|---|---|---|---|
| 媒体形式 | TrueCrypt / VeraCrypt 互換ボリューム形式のヘッダー、鍵導出、 keyfile 処理、データ配置 | ヘッダー構造や keyfile 処理のように、形式の設計に近い論点はここに属する。 | cryptsetup で開いても、互換形式として扱う限り形式上の制約は残る。 |
| TrueCrypt 本体実装 | TrueCrypt 本体に含まれる暗号実装、 OS API 呼び出し、エラー処理、 I/O 経路 | Windows CryptoAPI 依存や TrueCrypt 本体内 AES 実装のような論点はここに属する。 | cryptsetup は TrueCrypt 本体のコードを使わないため、同じ実装問題がそのまま残るとは限らない。 |
| cryptsetup の TCRYPT 拡張 | TrueCrypt / VeraCrypt 互換ヘッダーの解釈、鍵導出、 device-mapper mapping の作成 | 互換形式の解釈に関わる範囲では形式起因の制約を受ける。 | 既存ヘッダーを変更せずに Linux の標準ブロックデバイス経路へ接続する入口になる。 |
| tcplay | TrueCrypt / VeraCrypt 互換ボリュームの作成、変更、 hidden volume、ヘッダー復元、 keyfile 管理 | 形式管理に踏み込むため、 keyfile やヘッダー構造に関する論点とより強く関係する。 | 形式を作成・変更する場合は、互換性のために引き受ける制約を理解して使う必要がある。 |
| Linux kernel crypto API | Linux カーネル側の暗号アルゴリズム、暗号モード、 CPU 暗号支援、 dm-crypt の実データ処理 | TrueCrypt 本体内の AES 実装とは別の評価対象である。 | cryptsetup で開いた後の暗号処理は Linux 側の実装品質、カーネル更新、 CPU 支援に依存する。 |
第一の論点は、 keyfile mixing is not cryptographically sound である。 keyfile とは、パスフレーズに加えて解除材料として使うファイルである。問題は、 TrueCrypt 系の keyfile 処理が、暗号学的に理想的な混ぜ方ではないと指摘された点にある。これは、単に TrueCrypt 本体の一部コードだけの問題ではなく、 TrueCrypt 互換の keyfile 処理を再現する場合には形式互換と関係する。したがって、 cryptsetup や tcplay で TrueCrypt / VeraCrypt 互換ボリュームを扱う場合でも、 keyfile を使う運用ではこの論点を無視しない方がよい。逆に言えば、 keyfile を使わず、十分強いパスフレーズだけで既存ボリュームを開く運用では、影響範囲はその分だけ限定される。
第二の論点は、 unauthenticated ciphertext in volume headers である。これは、ボリュームヘッダー内の暗号文が認証されていないという問題であり、形式構造に近い論点である。ここでいう認証とは、単に復号できるかどうかではなく、そのヘッダーが改ざんされていないことを暗号学的に確認できるかどうかである。 LUKS2 のような現代的な管理形式と比べると、 TrueCrypt / VeraCrypt 互換ボリューム形式では、ヘッダーの扱いに固有の制約が残る。このため、 cryptsetup で保守的に開けるからといって、既存 TrueCrypt / VeraCrypt 互換ボリュームが LUKS2 と同じメタデータ保護性を持つわけではない。
第三の論点は、 CryptAcquireContext may silently fail である。 CryptAcquireContext は Windows CryptoAPI の文脈で使われる処理であり、この指摘は TrueCrypt 本体が Windows 上で OS API に依存していた部分に関係する。 Linux の cryptsetup、 dm-crypt、 kernel crypto API で既存ボリュームを開く場合、この Windows API 依存の問題は同じ形では現れない。ここから分かるのは、 TrueCrypt 本体の監査指摘には、媒体形式そのものではなく、特定 OS 上の特定実装に由来する問題も含まれているということである。したがって、 TrueCrypt 本体を使う場合のリスクと、 cryptsetup で互換形式を開く場合のリスクは分けなければならない。
第四の論点は、 AES implementation susceptible to cache timing attacks である。これは、 TrueCrypt 本体に含まれていた AES 実装がキャッシュタイミング攻撃に対して脆弱である可能性を指摘するものである。キャッシュタイミング攻撃とは、暗号処理そのものの数学的弱点ではなく、 CPU キャッシュの使われ方や処理時間の差から秘密情報の手がかりを得ようとする実装攻撃である。 cryptsetup で TrueCrypt / VeraCrypt 互換ボリュームを開く場合、暗号化・復号の実処理は TrueCrypt 本体の AES 実装ではなく、 Linux kernel crypto API 側の実装に乗る。したがって、この指摘は cryptsetup に同じコードパスとしては適用されない。ただし、 Linux 側の暗号実装が常に無条件に安全という意味ではなく、評価対象が TrueCrypt 本体から Linux カーネル側の暗号実装へ移るという意味である。
| 監査上の論点 | 主な原因の層 | cryptsetup で同じ形で残るか | tcplay で注意すべき点 | そこから言えること |
|---|---|---|---|---|
| Keyfile mixing | TrueCrypt 系の keyfile 処理と互換形式 | keyfile 互換処理を扱う場合は、形式互換に由来する制約として残る可能性がある。 | keyfile を使った作成・変更を行う場合は、 LUKS の keyfile と同じ意味で単純に扱わない。 | 既存互換ボリュームでは keyfile 運用を慎重に扱い、新規 Linux 媒体では LUKS2 の鍵管理へ寄せる理由になる。 |
| Unauthenticated ciphertext in volume headers | TrueCrypt / VeraCrypt 互換ボリューム形式のヘッダー構造 | 既存互換形式を開く限り、 LUKS2 と同じメタデータ保護性になるわけではない。 | ヘッダー作成・復元・変更では、形式上の制約を理解したうえでバックアップと検証を行う必要がある。 | 既存媒体は保守的に扱い、新規作成・主系運用では LUKS2 のような現行形式を優先する根拠になる。 |
| CryptAcquireContext | Windows 上の TrueCrypt 本体実装と OS API 依存 | Linux の cryptsetup / dm-crypt / kernel crypto API 経路では基本的に同じ形では残らない。 | tcplay も Windows CryptoAPI に依存する TrueCrypt 本体ではないため、同じ問題としては扱わない。 | TrueCrypt 本体の実装問題と互換形式の問題は分けて評価する必要がある。 |
| AES cache timing | TrueCrypt 本体に含まれる AES 実装 | cryptsetup は Linux kernel crypto API を使うため、 TrueCrypt 本体の AES 実装と同じコードパスではない。 | tcplay でマッピング後に dm-crypt を使う場合も、実データ処理は Linux 側の暗号実装に寄る。 | オリジナル実装より Linux 標準経路を優先する理由の一つになるが、 Linux 側の暗号実装を別途信頼する必要は残る。 |
この表から分かるのは、 TrueCrypt 監査の 4 件は一枚岩ではないということである。 keyfile mixing と unauthenticated ciphertext in volume headers は、 TrueCrypt / VeraCrypt 互換ボリューム形式やその運用に近い論点であり、 cryptsetup を使っても完全には消えない。これに対して、 CryptAcquireContext と AES cache timing は、 TrueCrypt 本体の特定実装や OS 依存に近い論点であり、 cryptsetup が Linux の標準経路に接続する場合には同じ形では残らない。この違いを見ないと、「TrueCrypt は監査で問題が出たからすべて危険」とも、「cryptsetup で開けば監査指摘はすべて無関係」とも誤った結論になってしまう。
ここから導ける第一の結論は、既存 TrueCrypt / VeraCrypt 互換ボリュームを読むことと、新規にその形式で重要データを作ることは分けるべきだということである。既存媒体については、 cryptsetup でヘッダーを変更せずに読み出せるなら、保守的な参照や段階移行の選択肢がある。一方、新規に Linux 用の暗号化媒体を作るのであれば、 LUKS2 の方が鍵管理、ヘッダー管理、再暗号化、将来の保守性を一体で扱いやすい。監査結果は、既存媒体を直ちに全廃せよという単純な命令ではなく、新規主系をどこに置くべきかを判断する材料になる。
第二の結論は、 TrueCrypt 本体を使う理由はさらに弱くなるということである。 TrueCrypt 本体には、保守終了、独自ライセンス、古い実装、現代 Linux との統合不足に加えて、監査で指摘された実装起因の論点もある。 cryptsetup を使えば、少なくとも TrueCrypt 本体の Windows API 依存や本体内 AES 実装に由来する問題からは離れ、 Linux の dm-crypt と kernel crypto API の評価へ移せる。これは「cryptsetup ならすべて安全」という意味ではないが、評価対象を現役で保守される Linux 側の実装へ移せるという意味で重要である。
第三の結論は、セキュリティ評価では「どの層の問題か」を常に問うべきだということである。暗号化媒体の安全性は、暗号アルゴリズムだけで決まらない。ヘッダー形式、鍵導出、 keyfile 処理、実装、 OS API、カーネル暗号実装、物理媒体、ファイルシステム、運用手順が合成されて決まる。したがって、ある監査結果を読んだときには、その指摘が形式の問題なのか、特定実装の問題なのか、 OS 依存の問題なのか、運用の問題なのかを分解しなければならない。
この整理を移行判断へつなげると、方針は明確になる。既存の TrueCrypt / VeraCrypt 互換媒体は、 cryptsetup で読める限り、ただちに無価値になるわけではない。しかし、形式起因の制約が残る以上、新規の主系暗号化媒体として積極的に選ぶ理由は弱い。読み取り中心の互換バックアップや段階移行の対象としては扱えるが、更新され続ける重要データや長期の主系バックアップには、 LUKS2 のように現在保守され、鍵管理とメタデータ管理を一体で扱える形式を優先する方が合理的である。つまり、監査結果から言えるのは「既存媒体を即捨てる」ではなく、「既存媒体は層を分けて保守し、新規主系は現行形式へ寄せる」という判断である。
8. tcplay は TrueCrypt / VeraCrypt 互換ボリュームの形式管理を補う
tcplay が出てくる理由は、 cryptsetup だけでは TrueCrypt / VeraCrypt 互換ボリュームの管理範囲が完結しないためである。 cryptsetup の TCRYPT 拡張は、既存の TrueCrypt / VeraCrypt 互換ボリュームを Linux の device-mapper mapping として開く入口として有用である。しかし、 cryptsetup は TCRYPT ヘッダーの作成や変更を基本的に担当しない。つまり、既存媒体をなるべく変えずに開くには cryptsetup が向くが、 TrueCrypt / VeraCrypt 互換ボリュームを新規に作る、 hidden volume を作る、パスフレーズや keyfile を変更する、バックアップヘッダーから復元する、といった形式管理に踏み込む場面では別の道具が必要になる。そこで出てくる自由ソフトウェアが tcplay である。
tcplay は BSD ライセンスの自由ソフトウェアであり、 TrueCrypt / VeraCrypt 実装として、複数 keyfile、 cipher cascade などを含む実装であると説明されている[24]。 tcplay の man page も、 TrueCrypt-compatible volumes の作成と opening / mapping をサポートすると説明している[25]。 Debian の tcplay パッケージ説明でも、 dm-crypt に基づく TrueCrypt / VeraCrypt implementation とされ、 normal volume、 system volume、 hidden volume、 hidden volume 保護付き outer volume、 volume creation などの対応が説明されている[26]。このため、自由ソフトウェアだけで TrueCrypt / VeraCrypt 互換ボリュームを扱う場合、 tcplay は cryptsetup が担わない形式管理の不足部分を補う位置にある。
ここでいう形式管理とは、単に暗号化媒体を開くことではない。既存ボリュームを開くだけなら、ヘッダーを読み、パスフレーズや keyfile から鍵素材を導出し、暗号化データ領域を Linux のブロックデバイスとして見せればよい。しかし、ボリュームを作成する場合は、ヘッダーを生成し、暗号方式、鍵導出方式、データ開始位置、 hidden volume の有無、バックアップヘッダーなどを媒体上へ書き込む必要がある。パスフレーズ変更や keyfile 変更では、暗号化データ本体をすべて書き換えるのではなく、ヘッダー側の解除情報を更新することになる。ヘッダー復元では、媒体上の通常ヘッダーまたはバックアップヘッダーを使い、復号に必要な入口を回復する。このような操作は、既存媒体を開くだけの操作よりも、媒体形式そのものへ強く踏み込む。
| 操作分類 | 具体的な内容 | cryptsetup の位置づけ | tcplay の位置づけ | そこから言えること |
|---|---|---|---|---|
| 既存ボリュームを開く | 既存の TrueCrypt / VeraCrypt 互換ボリュームを Linux のブロックデバイスとしてマッピングする。 | 適する。既存ヘッダーを変更せずに開く入口として使いやすい。 | 適する。 TrueCrypt / VeraCrypt 互換実装として opening / mapping を扱える。 | 既存媒体をまず読むだけなら、通常運用では cryptsetup を優先し、必要に応じて tcplay を補助として使えばよい。 |
| 新規ボリュームを作る | TrueCrypt / VeraCrypt 互換ボリュームのヘッダー、鍵導出情報、暗号パラメーター、データ領域を構成する。 | 基本対象外である。 | 対応する。 TrueCrypt-compatible volume の creation を扱える。 | 互換形式を新規に作る必要がある場合、 cryptsetup ではなく tcplay の領域になる。 |
| hidden volume を扱う | 外側のボリュームの中に、存在を隠すことを目的とした内側のボリュームを構成または開く。 | 開くための対応範囲はあるが、形式管理の主役ではない。 | hidden volume の作成、 opening、 outer volume を hidden volume 保護付きで開く操作を扱える。 | plausible deniability を目的にした TrueCrypt 系の特殊機能を扱うなら、 tcplay の役割が大きい。 |
| system volume を扱う | OS 起動領域を含む TrueCrypt 系の暗号化ボリュームを扱う。 | 限定的なマッピング対象として理解する必要がある。 | system volume の opening / mapping を扱える。 | Linux 上で参照・救出する対象にはなり得るが、 Linux の新規運用設計では LUKS2 を主系にする方が自然である。 |
| パスフレーズや keyfile を変更する | データ本体ではなく、ヘッダー側の解除情報を更新する。 | TrueCrypt / VeraCrypt 互換ヘッダー変更は基本対象外である。 | modify 操作としてパスフレーズ、 keyfile、 PBKDF2 PRF などの変更を扱える。 | 解除条件を変更する操作は媒体形式に踏み込むため、読み取り用の cryptsetup と分けて扱うべきである。 |
| ヘッダーを復元する | バックアップヘッダーなどを使い、復号に必要なヘッダー情報を回復する。 | 主対象ではない。 | バックアップヘッダーからの復元を扱える。 | TrueCrypt / VeraCrypt 互換形式を維持するなら、 tcplay は復旧工具としても意味を持つ。 |
この表から分かるのは、 tcplay は cryptsetup の競合というより、役割が違う補完工具だということである。 cryptsetup は、既存の TrueCrypt / VeraCrypt 互換ボリュームを Linux の標準経路へ接続する入口として使いやすい。 tcplay は、互換ボリューム形式そのものを作成・変更・復旧するための工具である。したがって、両者の関係は「どちらが正しいか」ではなく、「既存媒体を開くだけなのか、形式そのものを管理するのか」という作業境界で決まる。
では、 tcplay は信頼できるのか。ここでは「信頼できる」という言葉を分解する必要がある。第一に、ライセンスと配布経路として信頼できるかという観点がある。 tcplay は BSD ライセンスの自由ソフトウェアとして説明され、 Debian パッケージとして提供されている。これは、少なくとも TrueCrypt 本体の独自ライセンスや保守終了バイナリに依存するより、自由ソフトウェアの通常の配布・更新・監査の経路に乗せやすいことを意味する。第二に、実装として信頼できるかという観点がある。 tcplay は dm-crypt に基づく TrueCrypt / VeraCrypt 実装であり、マッピング後の実データ処理は Linux の device-mapper と dm-crypt の経路に寄る。第三に、形式互換として信頼できるかという観点がある。 tcplay は TrueCrypt-compatible volume を扱うため、互換性のために TrueCrypt / VeraCrypt 互換形式の制約も引き受ける。
このため、 tcplay を「無条件に信頼してよい」と言うのは雑である。正確には、「TrueCrypt 本体に依存せず、自由ソフトウェアだけで TrueCrypt / VeraCrypt 互換ボリュームの形式管理を行うための現実的な候補」と評価するべきである。これは、 LUKS2 と同じ意味で新規主系の標準形式として推奨するという意味ではない。新規に Linux 用の暗号化媒体を作るなら、鍵管理、ヘッダーバックアップ、再暗号化、将来の保守性を cryptsetup で一体管理できる LUKS2 を主系に置く方が自然である。 tcplay の価値は、既存の TrueCrypt / VeraCrypt 互換媒体を維持・救出・段階移行する場面で大きい。
| 信頼性の観点 | 評価できる点 | 限界 | 実務上の扱い |
|---|---|---|---|
| ライセンス | BSD ライセンスの自由ソフトウェアとして扱える。 | 自由ソフトウェアであることは、暗号実装の安全性を自動的に保証するものではない。 | TrueCrypt 本体の独自ライセンスを避け、自由ソフトウェア構成に寄せるための根拠になる。 |
| 配布経路 | Debian パッケージとして利用でき、通常のパッケージ管理に載せられる。 | Debian にあることは、すべての用途で安全性が保証されたという意味ではない。 | 手元に古い TrueCrypt バイナリを置くより、再現性と管理性は高い。 |
| 実装経路 | dm-crypt に基づく実装として説明され、 Linux のブロックデバイス暗号化経路へ接続できる。 | 形式解釈、ヘッダー生成、 keyfile 処理など tcplay 自身が担う部分の評価は残る。 | 読み書きの実データ処理は Linux 標準経路に寄せつつ、形式管理部分は tcplay の責任範囲として見る。 |
| 形式互換 | TrueCrypt-compatible volumes の作成、 opening / mapping、 hidden volume などを扱える。 | 互換性を保つため、 TrueCrypt / VeraCrypt 互換形式の構造的制約を引き受ける。 | 既存互換媒体の維持や段階移行には有用だが、新規主系では LUKS2 を優先する。 |
| セキュリティ | TrueCrypt 本体を使わず、自由ソフトウェア実装で形式管理できる。 | TrueCrypt 監査で形式起因と見なすべき論点、特に keyfile やヘッダー構造に関する制約は消えない。 | tcplay を使えばすべて安全ではなく、何を作成・変更するかに応じてリスクを分けて扱う。 |
| 保守判断 | 既存 TrueCrypt / VeraCrypt 互換媒体を、保守終了した TrueCrypt 本体から切り離して扱える。 | tcplay の機能範囲が VeraCrypt 本体の全機能や最新仕様を完全に代替するとは限らない。 | 既存媒体の救出、確認、段階移行、限定的な形式管理のための工具として位置づける。 |
tcplay を使うべき場面は、既存の TrueCrypt / VeraCrypt 互換ボリュームを単に開くだけではなく、その形式に対して管理操作が必要な場合である。たとえば、既存媒体のパスフレーズを変更したい場合、 keyfile の扱いを変更したい場合、 hidden volume を扱う必要がある場合、バックアップヘッダーから復元したい場合、あるいは互換形式のボリュームを検証用に作成したい場合である。これらは cryptsetup の主対象ではないため、自由ソフトウェアだけで対応するなら tcplay が候補になる。
一方で、 tcplay を使わない方がよい場面もある。既存媒体を読み出すだけなら、ヘッダーを変更しない cryptsetup を入口にした方が保守的である。新規に Linux 用の主系暗号化媒体を作るなら、 TrueCrypt / VeraCrypt 互換形式を新たに作るより LUKS2 を選ぶ方が、鍵スロット、ヘッダーバックアップ、再暗号化、将来の管理において自然である。また、 VeraCrypt の最新機能や形式拡張を厳密に使いたい場合、 tcplay がそれを完全に代替できるとは限らないため、対応範囲を確認する必要がある。
| 状況 | 優先する道具 | 理由 | 判断の原則 |
|---|---|---|---|
| 既存互換ボリュームをまず読む | cryptsetup | 既存ヘッダーを変更せず、 Linux の標準ブロックデバイス経路へ接続しやすいためである。 | 読むだけなら、まず非破壊的な入口を優先する。 |
| 既存互換ボリュームの形式情報を変更する | tcplay | パスフレーズ変更、 keyfile 変更、 PBKDF2 PRF 変更など、形式管理を扱えるためである。 | 形式へ書き込む操作は、専用の形式管理工具で行う。 |
| hidden volume を作成・管理する | tcplay | hidden volume と hidden volume 保護付き outer volume を扱う機能があるためである。 | TrueCrypt 系の特殊機能は、互換形式を理解する工具で扱う。 |
| 新規 Linux 主系媒体を作る | cryptsetup + LUKS2 | LUKS2 は鍵管理、ヘッダー管理、再暗号化、将来の保守性を一体で扱いやすいためである。 | 新規主系は互換形式ではなく、現行の管理しやすい形式を優先する。 |
| TrueCrypt 本体を置き換えたい | cryptsetup + tcplay | 開く操作は cryptsetup、形式管理は tcplay に分担できるためである。 | 保守終了した本体ではなく、自由ソフトウェアの役割分担で置き換える。 |
ここから言えるのは、 tcplay を信頼するかどうかは、抽象的な安心感ではなく、用途ごとの責任範囲で判断すべきだということである。 tcplay は、 TrueCrypt 本体の代わりにすべてを無条件に任せる魔法の道具ではない。むしろ、 cryptsetup が意図的に担当しない TrueCrypt / VeraCrypt 互換形式の作成・変更・復旧を補う工具である。したがって、既存媒体を開くだけなら cryptsetup、形式管理が必要なら tcplay、新規 Linux 主系なら LUKS2 という分担が最も整理しやすい。
より抽象化すれば、ここでの教訓は「互換実装を使えること」と「その形式を新規標準として選ぶこと」は別である、ということである。 tcplay があることで、 TrueCrypt / VeraCrypt 互換ボリューム形式は保守終了した TrueCrypt 本体から切り離して扱える。しかし、それは新規の重要媒体を積極的に TrueCrypt / VeraCrypt 互換形式で作るべきだという意味ではない。既存資産を救出・確認・段階移行するために互換実装を使い、将来の主系は LUKS2 のような現行の管理形式へ寄せる。この二段構えが、自由ソフトウェアだけで古い暗号化媒体を扱う際の現実的な結論である。
9. VeraCrypt 本体を使う経路と Debian パッケージだけで互換形式を扱う経路は別である
ここで VeraCrypt に触れる理由は、 VeraCrypt 本体を主題にするためではない。本稿の主題は、自由ソフトウェア、あるいは Debian パッケージだけで、暗号化媒体をどこまで扱えるのかを整理することである。 VeraCrypt は TrueCrypt 7.1a を基礎にした後継的な暗号化ソフトウェアであり、 TrueCrypt で指摘された問題への修正や、セキュリティ強化を継続してきた。 VeraCrypt の release notes は、 Open Crypto Audit Project で報告された脆弱性の多くを修正したことを記載している[27]。また、 VeraCrypt 1.26 以降では TrueCrypt 形式から VeraCrypt 形式への移行について、古いバージョンを使った変換手順が案内されている[28]。さらに、 BSI の VeraCrypt 評価も、 TrueCrypt から VeraCrypt への変化、暗号プリミティブ、既知脆弱性の扱いを比較している[29]。したがって、 VeraCrypt は TrueCrypt 後の重要な実装である。しかし、それは本稿の中心を VeraCrypt 本体の導入判断に移す理由にはならない。
本稿で分けたいのは、ソフトウェア本体としての VeraCrypt と、媒体上の TrueCrypt / VeraCrypt 互換ボリューム形式である。 VeraCrypt 本体を導入する場合、評価対象は VeraCrypt プロジェクトの配布物、 GUI / CLI、対応 OS、最新形式、独自機能、アップデート方針になる。一方、 Debian パッケージだけで扱う場合、評価対象は cryptsetup、 tcplay、 dm-crypt、 device-mapper、 kernel crypto API になる。この 2 つは、どちらも TrueCrypt / VeraCrypt 系の暗号化媒体に関係するが、運用上の意味は異なる。前者は VeraCrypt エコシステムを採用する話であり、後者は Debian 標準の自由ソフトウェア経路で既存互換形式へ到達する話である。
この区別をしないと、移行判断が混乱する。たとえば、既存の TrueCrypt / VeraCrypt 互換ボリュームを Linux で読みたいだけであれば、 VeraCrypt 本体を導入しなくても、 cryptsetup でマッピングできる場合がある。パスフレーズ変更、 keyfile 変更、 hidden volume、ヘッダー復元のように形式管理へ踏み込む場合でも、 tcplay が候補になる。一方、 VeraCrypt の最新形式、最新機能、 VeraCrypt 本体が提供する UI や運用体系を使いたい場合は、 Debian パッケージだけで完結する話ではなく、 VeraCrypt 本体を別途評価する話になる。つまり、 VeraCrypt は「既存互換形式の文脈で必要になる参照対象」ではあるが、「本稿で採用すべき主役」ではない。
| 経路 | 評価対象 | できること | できないこと・注意点 | そこから言えること |
|---|---|---|---|---|
| VeraCrypt 本体を使う | VeraCrypt プロジェクトの実装、配布物、 UI、対応 OS、最新形式、リリース方針 | VeraCrypt 本体が想定する機能、最新形式、専用の操作体系を利用できる。 | 本稿の条件である Debian パッケージだけの範囲からは外れ、別途インストール、更新、信頼性評価が必要になる。 | VeraCrypt を採用するなら、それは Debian 標準経路ではなく、 VeraCrypt エコシステムを選ぶ判断として扱うべきである。 |
| cryptsetup で既存互換ボリュームを開く | cryptsetup の TCRYPT 拡張、 dm-crypt、 device-mapper、 kernel crypto API | 既存の TrueCrypt / VeraCrypt 互換ボリュームを Linux のブロックデバイスとしてマッピングできる場合がある。 | ヘッダー作成やヘッダー変更は基本的に対象外であり、 VeraCrypt 本体の全機能を代替するものではない。 | 既存媒体を保守的に読むだけなら、 VeraCrypt 本体を導入せずに Debian 標準経路で到達できる可能性がある。 |
| tcplay で互換形式を管理する | tcplay の TrueCrypt / VeraCrypt 互換実装、ヘッダー操作、 hidden volume、 keyfile 管理 | TrueCrypt / VeraCrypt 互換ボリュームの作成、開閉、 hidden volume、パスフレーズ変更、 keyfile 変更、ヘッダー復元などを扱える。 | VeraCrypt 本体の最新機能や全仕様を完全に代替するとは限らず、互換形式の制約も残る。 | 既存互換形式の保全や段階移行には有用だが、新規主系の標準形式として VeraCrypt 系を推す根拠にはならない。 |
| LUKS2 へ移行する | cryptsetup、 LUKS2、 LUKS2 オンディスク形式、 Linux の標準暗号化運用 | 鍵スロット、ヘッダー管理、ヘッダーバックアップ、再暗号化などを Linux 標準経路で一体的に扱える。 | 既存 TrueCrypt / VeraCrypt 互換ボリュームをそのまま維持する話ではなく、データ移行が必要になる。 | 新規 Linux 主系媒体や長期更新対象では、互換形式維持より LUKS2 へ寄せる判断が自然になる。 |
ここから言えるのは、 VeraCrypt を「TrueCrypt の後継だから使うべきか」という問いに本稿を引きずられない方がよいということである。 VeraCrypt は重要な後継実装であり、 TrueCrypt 本体より現代的に保守されている。しかし、本稿で確認したいのは、 Debian パッケージだけで暗号化媒体をどこまで扱えるかである。この条件では、 VeraCrypt 本体は直接の主役ではなく、既存 TrueCrypt / VeraCrypt 互換ボリューム形式を理解するための背景資料である。つまり、 VeraCrypt を評価する章ではなく、 VeraCrypt 本体を使う経路と、 Debian 標準の自由ソフトウェア経路で互換形式を扱う経路を切り分ける章として置くべきである。
移行判断への影響も明確である。既存の TrueCrypt / VeraCrypt 互換ボリュームがあり、それを Debian 上で読み出したいだけなら、まず cryptsetup で開けるかを確認するのが自然である。形式管理が必要であれば tcplay を検討する。 VeraCrypt の最新機能や専用の運用体系が必要な場合は、 VeraCrypt 本体を別経路として評価する。新規に Linux 用の主系暗号化媒体を作る場合は、 VeraCrypt 互換形式を新たに選ぶより、 LUKS2 を選ぶ方が管理性、復旧性、標準性の点で整理しやすい。したがって、 VeraCrypt について本稿から導ける結論は、「VeraCrypt があるから TrueCrypt 系はすべて VeraCrypt へ移すべきだ」ではなく、「VeraCrypt 本体、 Debian 標準経路、 LUKS2 移行を別の選択肢として評価するべきだ」ということである。
より抽象化すれば、ここでの論点は、後継ソフトウェアの存在と、互換形式の保全と、新規標準の選択は同じ判断ではないということである。ある古い形式に後継実装が存在しても、その後継実装をすべての環境へ導入する必要があるとは限らない。互換実装で読めるなら、既存資産は保全・救出・段階移行できる。一方、新規に作る主系媒体では、現在の OS に最も深く統合された形式を選ぶ方が合理的である。 VeraCrypt は TrueCrypt 後の重要な実装だが、 Debian パッケージだけでどこまで扱えるかを問う本稿では、 VeraCrypt 本体の採用可否ではなく、選択肢の境界を明確にする材料として扱うのが正しい。
10. BitLocker と旧 FileVault2 は開ける場合があるが、完全管理ではない
cryptsetup の対応範囲は、 LUKS、 plain dm-crypt、 TrueCrypt / VeraCrypt 互換ボリュームだけに閉じていない。 cryptsetup は、 BitLocker / BitLocker To Go や FileVault2 も限定的な互換対象として扱う[11]。ここで重要なのは、「対応している」という言葉の意味である。対応しているとは、 Windows や macOS の暗号化機能を Linux 上で完全に置き換えるという意味ではない。必要な鍵素材があり、 cryptsetup がヘッダーやメタデータを解釈でき、 Linux の device-mapper mapping として提示できる場合に、暗号化されたブロックデバイスへ到達できるという意味である。
BitLocker は、 Windows のデータ保護機能として、 TPM、回復キー、パスワード、組織の管理ポリシー、 Active Directory や Microsoft Entra ID との回復キー管理などと結びつく[30]。このため、 BitLocker 媒体を Linux で開けるという話は、 Windows の BitLocker 運用全体を Linux が再現するという話ではない。 Linux 側で回復キーやパスワードなどの鍵素材を提示でき、 cryptsetup が BITLK 互換形式として解釈できる場合に、暗号化されたデータ領域を復号済みブロックデバイスとして見せられるという話である。
FileVault2 も同じように、 macOS の暗号化機能全体と、 cryptsetup が互換的に扱える範囲を分けて考える必要がある。 macOS の FileVault は、デバイス管理、復旧キー、ユーザーアカウント、 Apple の管理機構と結びつく[31]。 cryptsetup が対象にする FileVault2 は、主に古い Core Storage + HFS+ 系の FileVault2 であり、近年の macOS で一般的な APFS FileVault を包括的に扱えるという意味ではない。したがって、 FileVault2 については、名称だけを見て「macOS の暗号化ディスク全般を Linux で開ける」と考えるべきではない。
この違いを理解するには、「解除」「マッピング」「ファイルシステム読み書き」「管理」の 4 段階に分けるとよい。解除とは、パスワードや回復キーなどから復号に必要な鍵素材を得ることである。マッピングとは、暗号化されたデータ領域を Linux のブロックデバイスとして見せることである。ファイルシステム読み書きとは、そのブロックデバイス上にある NTFS、 exFAT、 FAT、 HFS+ などを Linux 側のファイルシステムドライバーで扱うことである。管理とは、 TPM 自動解除、回復キー管理、組織ポリシー、ユーザー認証連携、再暗号化、形式変更など、元 OS の暗号化機能全体を運用することである。 cryptsetup が主に担うのは、このうち解除とマッピングの一部であり、元 OS の管理体系を丸ごと再現することではない。
| 段階 | 意味 | cryptsetup で扱える範囲 | 扱えない範囲 | そこから言えること |
|---|---|---|---|---|
| 解除 | 回復キー、パスワード、鍵ファイルなどから復号に必要な鍵素材を得る。 | Linux 側に提示できる鍵素材がある場合、 BitLocker や旧 FileVault2 の解除を試みられる。 | TPM や Secure Enclave など、元 OS のハードウェア連携解除をそのまま再現することは期待できない。 | Linux で開けるかどうかは、形式対応だけでなく、利用可能な鍵素材が手元にあるかで決まる。 |
| マッピング | 暗号化されたデータ領域を、 Linux のブロックデバイスとして見せる。 | 条件が合えば、 cryptsetup が device-mapper mapping を作り、復号済みブロックデバイスとして提示できる。 | すべての BitLocker 構成やすべての FileVault 構成を対象にするわけではない。 | 「開ける」とは、まずブロックデバイスへ到達できるという意味であり、元 OS の管理機能まで含まない。 |
| ファイルシステム読み書き | 復号済みブロックデバイス上のファイルシステムを Linux で扱う。 | NTFS、 exFAT、 FAT、 HFS+ など、 Linux 側に対応ドライバーがあればファイルへ到達できる場合がある。 | 暗号化を解除できても、内部ファイルシステムを Linux が安全に扱えなければ、実際のファイル操作は制限される。 | 暗号化形式の対応と、内部ファイルシステムの対応は別問題である。 |
| 管理 | TPM 自動解除、回復キー管理、組織ポリシー、ユーザー認証連携、再暗号化、形式変更を扱う。 | cryptsetup の互換対応の主目的ではない。 | Windows や macOS の暗号化管理体系を Linux 側で完全に再現するものではない。 | Linux で既存媒体を救出・参照できることと、その形式を Linux で完全管理できることは分ける必要がある。 |
BitLocker について、自由ソフトウェアでできることは、既存 BitLocker / BitLocker To Go 媒体へ条件付きで到達することである。たとえば、回復キーやパスワードなど Linux 側に提示できる鍵素材があり、 cryptsetup が BITLK 互換形式として解釈できる場合、復号済みのブロックデバイスとしてマッピングできる可能性がある。その後、内部ファイルシステムが NTFS、 exFAT、 FAT などであり、 Linux 側のドライバーで扱えるなら、ファイルを読み出せる可能性がある。ここまでが、 Debian パッケージだけで到達し得る実用上の範囲である。
一方、 BitLocker について、自由ソフトウェアだけではできないことも明確である。 Windows の TPM 自動解除をそのまま Linux で再現すること、 Windows の管理ポリシーを Linux 上で同じ意味で運用すること、組織の回復キー管理基盤を Linux 側で代替すること、 BitLocker の保護機構を Windows と同じ管理面で作成・変更・監査することは、 cryptsetup の互換対応の主目的ではない。つまり、 Linux で BitLocker 媒体を開ける場合があるという事実は、 BitLocker を Linux の通常暗号化形式として採用できるという意味ではない。
FileVault2 について、自由ソフトウェアでできることはさらに限定的である。 cryptsetup が扱う FileVault2 は、古い Core Storage + HFS+ 系を対象にした互換マッピングである。条件が合い、必要な鍵素材を提示でき、 Linux 側が HFS+ ファイルシステムを扱えるなら、既存媒体の内容へ到達できる場合がある。しかし、これは現在の macOS で一般的な APFS FileVault を Debian パッケージだけで包括的に扱えるという意味ではない。 APFS、ユーザー認証、復旧キー、 Secure Enclave などを含む現在の macOS 暗号化運用を Linux 側で再現する話ではない。
| 対象 | できること | できないこと | 注意すべき境界 | そこから言えること |
|---|---|---|---|---|
| BitLocker | 回復キーやパスワードなど必要な鍵素材があり、形式が対応範囲に入る場合、 cryptsetup で既存媒体をマッピングできる可能性がある。 | Windows の TPM 自動解除、組織ポリシー、回復キー管理、 BitLocker 管理画面、 Windows 側の保護機構を Linux で完全再現することはできない。 | 開けるかどうかは、鍵素材、媒体構成、 cryptsetup の対応状況、内部ファイルシステムに依存する。 | BitLocker 対応は救出・参照・一時的な相互運用のための入口であり、 Linux 主系暗号化形式として採用する根拠にはならない。 |
| BitLocker To Go | 外部媒体として条件が合えば、 Linux で復号済みブロックデバイスとして開ける可能性がある。 | Windows 側の自動実行、管理メタデータ、組織管理、すべてのメディア構成を同じ意味で扱うことはできない。 | 復号後の実ファイル操作は、内部ファイルシステムを Linux が安全に扱えるかに左右される。 | 外部媒体のデータ救出には有用だが、継続更新する Linux バックアップ先としては LUKS2 を優先する方が自然である。 |
| 旧 FileVault2 | 古い Core Storage + HFS+ 系 FileVault2 であれば、条件付きで cryptsetup によりマッピングできる場合がある。 | APFS FileVault、現在の macOS のユーザー認証連携、 Secure Enclave 連携、デバイス管理を Linux 側で包括的に扱うことはできない。 | FileVault2 という名称だけでは不十分であり、 Core Storage + HFS+ 系なのか APFS 系なのかを確認する必要がある。 | 旧 FileVault2 対応は過去資産への到達手段であり、現在の macOS 暗号化環境を Linux で一般管理できるという意味ではない。 |
ここから言える第一のことは、 cryptsetup の外部形式対応は、相互運用と救出のための機能として理解するべきだということである。 BitLocker や旧 FileVault2 を Linux で開ける可能性があることは、実務上は大きな意味を持つ。 Windows や古い macOS の暗号化媒体からデータを取り出す、退避する、検証する、別媒体へ移すという場面では、自由ソフトウェアだけで到達できる経路がある。しかし、その経路は元 OS の暗号化管理体系を Linux 上に移植するものではない。
第二に、暗号化形式の対応範囲とファイルシステムの対応範囲は分けて評価する必要がある。 cryptsetup が BitLocker や旧 FileVault2 を開けたとしても、その中にあるファイルシステムを Linux が安全に読み書きできるとは限らない。暗号化レイヤーを外すことは、箱の鍵を開けることに相当する。しかし、箱の中にある帳簿を読めるかどうかは、別の読み取り能力に依存する。 BitLocker なら NTFS や exFAT、 FileVault2 なら HFS+ など、暗号化解除後のファイルシステム対応を別途確認しなければならない。
第三に、 Linux で新規に使う主系暗号化媒体として、 BitLocker や FileVault2 を選ぶ理由は弱い。 BitLocker は Windows の管理体系の中で意味を持ち、 FileVault は macOS の管理体系の中で意味を持つ。 Linux で新規に暗号化媒体を作り、継続的にバックアップや保全を行うなら、 cryptsetup と LUKS2 を中心にした方が、鍵管理、ヘッダー管理、復旧手順、再暗号化、ディストリビューション更新との整合性が高い。したがって、 BitLocker と旧 FileVault2 への対応は、 Linux 主系の設計材料ではなく、他 OS 由来の既存媒体へ到達するための互換機能として位置づけるべきである。
より抽象化すれば、ここでの結論は、外部形式を開ける能力と、その形式を自分の標準形式として採用する判断は別だということである。 Debian パッケージだけで BitLocker や旧 FileVault2 に到達できる場合があることは、自由ソフトウェアの実用範囲を広げる。しかし、それは Linux の通常運用で BitLocker や FileVault2 を主系にする根拠ではない。既存媒体の救出、参照、移行には互換機能を使い、新規作成や長期更新には Linux の標準形式である LUKS2 を使う。この切り分けによって、自由ソフトウェアだけで扱える範囲を過小評価せず、同時に過大評価もしない整理ができる。
11. 開けた後に読めるかはファイルシステムと OS 構造の問題でもある
暗号化媒体を開くことと、中のファイルを正しく読むことは同じではない。 cryptsetup や tcplay が行う中心的な仕事は、暗号化されたブロックデバイスを復号可能な mapping として提示することである。これは、暗号化された箱の鍵を開ける段階に相当する。しかし、箱の中にある帳簿を読めるかどうかは別問題である。復号済みブロックデバイスの上には、 ext4、 FAT、 exFAT、 NTFS、 HFS+、 APFS などのファイルシステムが存在する。ファイルシステムとは、ブロックの並びをファイル名、ディレクトリ、権限、更新時刻、空き領域、ジャーナルなどとして解釈するための構造である。暗号化レイヤーを解除できても、このファイルシステムを Linux 側が正しく理解できなければ、最終的なファイル読み出しや安全な書き込みはできない。
この章で確認したいのは、暗号化レイヤーとファイルシステムレイヤーを分けることである。 BitLocker 媒体を cryptsetup で開けたとしても、その中身が NTFS であれば、実際の読み書きは Linux 側の NTFS ドライバーに依存する。旧 FileVault2 媒体を開けたとしても、その中身が HFS+ であれば、 HFS+ ドライバーの状態に依存する。 APFS FileVault のように、暗号化、ファイルシステム、 OS のユーザー認証、復旧キー、スナップショット、署名付きシステムボリュームが密接に結びつく場合は、暗号化レイヤーだけを見ても実用的な到達可能性は判断できない。したがって、自由ソフトウェアだけで暗号媒体を扱う範囲を評価するには、暗号化形式、ファイルシステム、 OS 固有構造、読み書き方針を分ける必要がある。
仕組みとしては、暗号化媒体の読み出しは段階的に進む。第一段階では、 cryptsetup や tcplay がヘッダーや鍵素材を解釈し、復号済みブロックデバイスを /dev/mapper 配下などに提示する。第二段階では、 Linux カーネルまたは FUSE ドライバーが、その復号済みブロックデバイス上のファイルシステムを解釈する。第三段階では、 mount によってディレクトリツリーへ接続され、通常のファイルとして読み書きできるようになる。第四段階では、権限、所有者、拡張属性、アクセス制御リスト、文字コード、ジャーナル、 dirty bit、メタデータ更新など、元 OS 固有の意味が問題になる。つまり、「開けた」は第一段階にすぎず、「壊さず読める」「安全に更新できる」「元 OS へ戻しても整合する」は別段階の能力である。
| 段階 | 担当する仕組み | できること | できないこと・注意点 | そこから言えること |
|---|---|---|---|---|
| 暗号解除 | cryptsetup、 tcplay、 dm-crypt、 device-mapper | 鍵素材が正しく、形式が対応範囲に入る場合、暗号化されたデータ領域を復号済みブロックデバイスとして提示できる。 | 内部ファイルシステムを理解するわけではなく、ファイル名、ディレクトリ、権限、ジャーナルの意味までは扱わない。 | 暗号解除は必要条件であり、ファイルアクセスの十分条件ではない。 |
| ファイルシステム解釈 | ext4、 FAT、 exFAT、 NTFS、 HFS+、 APFS などのドライバー | 復号済みブロックの並びを、ファイル、ディレクトリ、空き領域、メタデータとして解釈する。 | 対応ドライバーが未成熟、読み取り専用、非自由、未収録、または元 OS 固有機能に未対応の場合がある。 | 暗号化形式の対応範囲とファイルシステムの対応範囲は別々に確認する必要がある。 |
| マウント | Linux の mount、カーネル VFS、 FUSE | ファイルシステムを Linux のディレクトリツリーへ接続し、通常のファイル操作を可能にする。 | 読み取り専用にすべき媒体を読み書きで開くと、ジャーナル、 dirty bit、メタデータ更新により元環境との整合性を壊す可能性がある。 | 異種 OS 由来の暗号媒体では、まず読み取り専用で扱う判断が安全側になることが多い。 |
| OS 固有構造 | Windows、 macOS、 Linux の権限、拡張属性、スナップショット、復旧情報、管理メタデータ | 一部は Linux から参照できる場合がある。 | 元 OS のユーザー認証、 TPM、 Secure Enclave、 APFS スナップショット、 Windows 管理ポリシーなどは Linux 側で完全再現できるとは限らない。 | データ救出と元 OS 環境の完全な再現は別の作業である。 |
自由ソフトウェアだけで扱えるかどうかも、単純に二分できない。 ext4 は Linux の標準的な自由ソフトウェアのファイルシステムであり、 Linux 主系の暗号化媒体と最も相性がよい。 FAT と exFAT は外部媒体の相互運用で使われることが多く、現在の Linux では exFAT も通常利用の範囲に入りやすい。 NTFS は Windows 由来のファイルシステムであり、 Linux では ntfs3 などのカーネルドライバーや、従来の FUSE 系実装によって読み書きできる範囲がある。 HFS+ は古い macOS 資産への到達手段として意味があるが、現代的な主系として扱うものではない。 APFS は現在の macOS の中心的なファイルシステムだが、自由ソフトウェア側では読み取り中心の実装が多く、完全な読み書き管理を Debian パッケージだけで期待する領域ではない。
| ファイルシステム | 主な出自 | 自由ソフトウェアで扱える範囲 | 自由ではない・または弱い範囲 | 時間軸と将来性 |
|---|---|---|---|---|
| ext4 | Linux | Linux カーネルの標準的なファイルシステムとして自由ソフトウェアで深く扱える。 | Windows や macOS との標準相互運用には向かない。 | Linux 主系では将来も安定して扱える可能性が高く、 LUKS2 と組み合わせる新規暗号化媒体の自然な選択肢になる。 |
| FAT | 古い DOS / Windows 系 | Linux で広く扱え、単純な外部媒体の相互運用に向く。 | Unix 権限、シンボリックリンク、大容量ファイル、現代的なメタデータ管理には弱い。 | 互換性目的では残るが、長期の主系バックアップや権限保持には向かない。 |
| exFAT | Windows 系外部媒体 | 外部媒体の相互運用で扱いやすく、 Linux でも通常利用しやすい。 | Unix 的な権限やジャーナリングを前提にした堅牢なバックアップ用途には弱い。 | 外部媒体の交換形式としては残る可能性が高いが、 Linux 主系暗号化バックアップの内部形式としては ext4 の方が自然である。 |
| NTFS | Windows | Linux では ntfs3 などにより読み書きできる範囲があり、 BitLocker 解除後のファイル到達に意味がある。 | Windows 固有のメタデータ、更新直後の整合性、休止状態、 dirty bit、権限意味論は注意が必要である。 | Windows との相互運用需要が強いため Linux 側サポートの重要性は高いが、 Linux 主系の新規暗号化媒体として積極採用する理由は弱い。 |
| HFS+ | 古い macOS | 古い FileVault2 や過去の macOS 媒体からのデータ救出で意味を持つ場合がある。 | ジャーナリング、メタデータ、古い実装、保守状態の面で、読み書き運用には慎重さが必要である。 | 過去資産への到達手段としては残るが、将来サポートが強化される中心領域とは考えにくい。 |
| APFS | 現在の macOS | 自由ソフトウェア実装で読み取りできる場合はあるが、完全な読み書き管理を Debian パッケージだけで期待しにくい。 | スナップショット、暗号化、圧縮、 firmlink、署名付きシステムボリューム、 macOS 固有メタデータを含む完全互換は難しい。 | macOS の中心形式であるため需要はあるが、 Apple の実装と OS 統合が強く、自由ソフトウェア側で完全サポートされる可能性は短期的には高くない。 |
ここでいう自由と非自由は、少なくとも 3 つに分けて考える必要がある。第一に、実装が自由ソフトウェアとして利用できるかという意味の自由がある。 Linux カーネル内の ext4 や dm-crypt、 cryptsetup、 tcplay のように、ソースコードと配布経路が自由ソフトウェアの範囲にあるものは、この条件を満たしやすい。第二に、仕様や形式を自由に実装しやすいかという意味の自由がある。たとえ読み取りドライバーが存在しても、形式が複雑で OS 固有構造に強く依存する場合、完全互換は難しくなる。第三に、運用上自由に書き込んでよいかという意味の自由がある。読み取りはできても、書き込みによって元 OS の整合性を壊す可能性がある場合、実務上は自由に更新できるとは言えない。
| 自由の種類 | 意味 | 例 | 注意点 | 判断への影響 |
|---|---|---|---|---|
| 実装の自由 | ソースコード、ライセンス、配布経路が自由ソフトウェアとして扱える。 | cryptsetup、 tcplay、 dm-crypt、 ext4 など。 | 自由ソフトウェアであることは、すべての形式を安全に完全管理できることを自動的に意味しない。 | Debian パッケージだけで再現できる運用を作るための前提になる。 |
| 形式実装の自由 | 媒体形式を第三者が実装しやすい。 | 文書化された形式や、長年解析され実装が安定した形式。 | 形式が複雑で OS 固有機能に密接な場合、自由実装があっても部分対応にとどまりやすい。 | 将来も読めるかどうかは、形式そのものの実装しやすさに左右される。 |
| 運用上の自由 | 読み取りだけでなく、書き込み、更新、修復、再マウントを安全に行える。 | Linux 上の ext4 はこの自由度が高い。 | NTFS、 HFS+、 APFS など異種 OS 由来の形式では、読み取り可能でも安全な書き込みは別問題である。 | 救出用途なら読み取り中心、継続更新用途なら Linux ネイティブ形式を選ぶべきである。 |
時間軸を入れると、判断はさらに明確になる。過去資産へ到達するための形式と、今後の主系として使う形式は分けるべきである。 HFS+ や旧 FileVault2 は、過去の macOS 資産を読むためには意味がある。しかし、将来の Linux 主系として採用する形式ではない。 BitLocker と NTFS は、 Windows との相互運用やデータ救出では重要だが、 Linux で新規に長期バックアップ媒体を作る場合の第一候補ではない。 APFS は現在の macOS の中心形式であり、今後も macOS 側では重要であり続ける可能性が高いが、それは Linux の自由ソフトウェア環境で完全に扱える可能性が高いという意味ではない。 Apple の OS 統合、暗号化、スナップショット、署名付きシステムボリュームが強く絡むため、短期的には読み取り中心または限定対応にとどまると見る方が現実的である。
将来サポートの見込みは、需要、仕様の安定性、実装難度、ライセンス、カーネル統合の有無で決まる。 NTFS は Windows との相互運用需要が非常に大きく、 Linux 側でも read/write サポートが重要視されやすい。 exFAT も外部媒体の交換形式として需要があり、今後も扱われ続ける可能性が高い。 ext4 は Linux 自身の標準的な領域であり、将来サポートの見込みは高い。 HFS+ は過去資産として残るが、 macOS 側の主流ではなくなっており、将来強化の中心にはなりにくい。 APFS は需要は大きいが、実装難度と OS 統合が強いため、自由ソフトウェアだけで完全な読み書き管理が標準化される可能性は高いとは言いにくい。
| 対象 | 現在の役割 | 将来サポートの見込み | 理由 | 運用判断 |
|---|---|---|---|---|
| ext4 | Linux 主系ファイルシステムとして使う。 | 高い。 | Linux ネイティブであり、自由ソフトウェアの中心的な保守対象であるためである。 | LUKS2 と組み合わせる新規主系媒体では有力な選択肢になる。 |
| exFAT | 外部媒体の相互運用に使う。 | 比較的高い。 | USB メモリー、 SD カード、外部ディスクなどで相互運用需要が続くためである。 | 交換用には有用だが、権限や堅牢性が必要な主系バックアップでは慎重に扱う。 |
| NTFS | Windows 由来媒体の参照、救出、相互運用に使う。 | 中から高。 | Windows との相互運用需要が大きく、 Linux 側でも対応価値が高いためである。 | BitLocker 解除後のデータ救出には有用だが、 Linux 主系の新規媒体には ext4 を優先する。 |
| HFS+ | 古い macOS 資産への到達に使う。 | 低から中。 | macOS 側の主流が APFS へ移っており、過去資産対応の性格が強いためである。 | 読み取り中心の救出対象として扱い、継続更新先にはしない。 |
| APFS | 現在の macOS 媒体の中心形式である。 | 限定的である。 | 需要は大きいが、暗号化、スナップショット、圧縮、 macOS 固有構造が複雑で、自由ソフトウェア側の完全対応は難しいためである。 | Linux からは完全管理対象ではなく、必要なら macOS 側で読み出して中立的な形式へ移す判断が現実的である。 |
ここから言える第一のことは、暗号化媒体の可搬性は暗号化形式だけでは決まらないということである。 BitLocker を開けるか、 FileVault2 を開けるか、 TrueCrypt / VeraCrypt 互換ボリュームを開けるかという問題は重要だが、それは入口にすぎない。実際にデータを救出し、壊さずコピーし、将来も読める状態にするには、内部ファイルシステムと OS 固有構造を含めて評価する必要がある。暗号化レイヤー、ファイルシステムレイヤー、 OS 管理レイヤーを分けて確認しなければ、「開けたのに読めない」「読めたが元環境へ戻すと壊れる」「読み取りはできるが安全な更新はできない」という問題が起きる。
第二に、自由ソフトウェアだけで扱える範囲は広いが、自由ソフトウェアだけで完全に管理できる範囲は限られる。 ext4、 LUKS2、 dm-crypt のように Linux 側で設計・保守されている領域では、作成、更新、検証、復旧、将来の保守を一体で考えやすい。これに対して、 NTFS、 HFS+、 APFS のような異種 OS 由来の形式では、読み取りや一部書き込みができても、元 OS の意味論まで完全に再現できるとは限らない。したがって、自由ソフトウェアで開ける形式は救出と相互運用に使い、新規の主系媒体は Linux ネイティブな LUKS2 + ext4 へ寄せるのが合理的である。
第三に、時間軸を入れると、既存媒体と新規媒体の扱いは分かれる。既存の BitLocker、旧 FileVault2、 HFS+、 NTFS、 APFS 媒体は、必要なときに読み出し、検証し、中立的または Linux ネイティブな形式へ退避する対象である。一方、新規に作る暗号化バックアップ媒体は、将来の Linux 環境で高い確率で読める形式を選ぶべきである。将来サポートの見込みが高いのは、自由ソフトウェアとして保守され、 Linux の標準経路に統合され、仕様と実装が長期的に維持される形式である。その意味で、 Linux 主系では LUKS2 と ext4 の組み合わせが最も説明しやすく、異種 OS 由来の形式は救出・交換・参照のための互換対象として扱うのがよい。
12. veritysetup は暗号化ではなく、読み取り専用の改ざん検証を担う
暗号化と完全性は別の性質である。暗号化は、保存された内容を鍵なしでは読めない状態にするための仕組みである。一方、完全性検証は、読んだ内容が期待した内容と一致しているかを確認するための仕組みである。暗号化されていても、暗号文の一部が壊れたり、攻撃者に差し替えられたりする可能性はある。逆に、完全性検証があっても、それだけでは内容を秘匿できない。 veritysetup が扱う dm-verity は後者に属する。 Linux カーネル文書は、 dm-verity をブロックデバイスの transparent integrity checking として説明し、ハッシュツリーを使って読み取り時にブロックの整合性を検証する仕組みを示している[32]。 veritysetup の man page も、 dm-verity が読み取り専用の透過的なデータ完全性保護を提供すると説明している[33]。
dm-verity の基本構造は、データ本体とは別にハッシュツリーを持つことにある。ハッシュとは、あるデータから固定長の値を計算する処理であり、入力が少しでも変わると出力も大きく変わる性質を持つ。ハッシュツリーとは、データブロックごとのハッシュを作り、そのハッシュ群をさらにまとめてハッシュ化し、最終的に 1 つの root hash へ集約する構造である。読み取り時には、対象ブロックのハッシュを計算し、それがハッシュツリー上の期待値と一致するかを確認する。最終的な root hash が信頼できる場所に保管されていれば、読み出したブロックが作成時点の内容から変わっていないかを検証できる。
ここで重要なのは、 dm-verity の信頼の起点がデータ領域そのものではなく root hash にあるという点である。攻撃者がデータブロックだけを変更しても、読み取り時のハッシュ照合で検出される。ハッシュツリーの一部を変更しても、上位のハッシュと合わなくなる。最終的に root hash まで含めてすべてを差し替えられれば検出できないため、 root hash はカーネルコマンドライン、署名済みメタデータ、別媒体、信頼された設定管理など、改ざんされにくい経路で保持する必要がある。つまり、 dm-verity は単独で真実を保証する仕組みではなく、「信頼できる root hash に対して、読み出したブロックが一致するか」を確認する仕組みである。
| 要素 | 役割 | 具体的に起きること | 注意点 | そこから言えること |
|---|---|---|---|---|
| データブロック | 実際に読み出したい内容を保持する。 | ファイルシステムやイメージの内容がブロック単位で保存される。 | データブロックだけが正しく見えても、改ざんされていないとは限らない。 | 内容の正しさを確認するには、データ本体とは別の検証情報が必要になる。 |
| ハッシュブロック | データブロックや下位ハッシュの期待値を保持する。 | 読み取り時に計算されたハッシュと、事前に保存されたハッシュが比較される。 | ハッシュブロック自体も改ざん対象になり得るため、上位ハッシュで保護される必要がある。 | dm-verity は個別ブロックを直接信用せず、ツリー構造で検証を積み上げる。 |
| root hash | ハッシュツリー全体の信頼の起点になる。 | root hash が信頼できれば、ツリー全体を通じて読み出したブロックを検証できる。 | root hash まで攻撃者に差し替えられると、検証の前提が崩れる。 | dm-verity の設計では、 root hash をどこで信頼するかが運用上の核心になる。 |
| veritysetup | dm-verity 用のメタデータ作成、検証、 mapping 作成を扱う。 | 対象デバイスとハッシュデバイスを指定し、読み取り専用の検証付き mapping を構成する。 | 通常の読み書き更新を行うための道具ではない。 | 固定化されたデータを検証付きで読む用途に向く。 |
| dm-verity | カーネル側で読み取り時のブロック検証を行う。 | 上位から読み取り要求が来るたびに、必要なハッシュを確認してからデータを返す。 | 検証失敗時の扱いは設定や用途に依存する。 | アプリケーション側が個別に検証処理を書かなくても、ブロックデバイス層で改ざん検出できる。 |
dm-verity が向くのは、読み取り専用のシステムイメージ、配布済みイメージ、固定化されたアーカイブ、改ざんされていないことを確認したい参照用データである。たとえば、 OS イメージ、コンテナや組み込み機器の読み取り専用領域、配布後に変更されるべきではないデータセット、保存後に内容を固定したアーカイブでは、作成時点の root hash を保持しておけば、後から読み出す内容が同じかどうかを検証できる。これは、バックアップや保全の文脈では「過去に固定した内容を、現在も同じものとして読めるか」を確認する道具になる。
一方で、 dm-verity は通常の読み書き更新には向かない。ハッシュツリーは、データ内容が固定されていることを前提に作られる。データブロックを 1 つ更新すれば、そのブロックのハッシュだけでなく、上位のハッシュ、さらに root hash まで更新しなければならない。つまり、通常のファイルシステムのように日常的にファイルを追加・削除・変更する用途では、 dm-verity の前提と合わない。読み書き更新が必要な場合は、 dm-integrity、ファイル単位のハッシュ記録、バックアップ照合、アプリケーション側の署名検証など、別の設計を検討する必要がある。
| 用途 | dm-verity が向くか | 理由 | 向かない場合の代替 | そこから言えること |
|---|---|---|---|---|
| 読み取り専用 OS イメージ | 向く。 | 内容が固定されており、起動時や読み取り時に改ざんを検出する価値が高いためである。 | 更新が必要な場合は、新しいイメージを作り直して root hash を更新する。 | dm-verity は、変化しないことを前提にできる領域で強い。 |
| 配布済みデータセット | 向く。 | 配布時点の内容と読み出し時点の内容が一致するかを検証できるためである。 | ファイル単位の署名やハッシュリストと組み合わせる選択肢もある。 | データの正しさをブロック層で検証したい場合に意味がある。 |
| 固定化されたアーカイブ | 向く。 | 保存後に変更しない前提であれば、後年の読み出し時に破損や改ざんを検出できるためである。 | 通常のバックアップでは、別途ハッシュ台帳や複数コピー照合を使う方法もある。 | 読み取り専用保全では、暗号化とは別に完全性検証を設計できる。 |
| 日常的に更新するバックアップ媒体 | 向かない。 | データ更新のたびにハッシュツリーと root hash の整合性を更新する必要があり、通常の読み書き用途と相性が悪いためである。 | dm-integrity、ファイル単位のハッシュ、 rsync 後の検証、定期的な照合を検討する。 | 更新されるデータには、読み取り専用前提の dm-verity ではなく別の完全性設計が必要になる。 |
| 作業領域 | 向かない。 | ファイル作成、削除、更新が頻繁に発生し、内容固定という前提を満たさないためである。 | 通常のファイルシステム整合性、ジャーナリング、バックアップ、必要に応じた dm-integrity を使う。 | dm-verity は作業領域の堅牢化ではなく、固定内容の検証に使うべきである。 |
dm-verity と暗号化を組み合わせる場合も、役割を分けて考える必要がある。暗号化は内容を秘匿し、 dm-verity は内容の一致を検証する。したがって、機密性と完全性を両方扱いたい場合は、暗号化レイヤーと検証レイヤーの順序、 root hash の保管方法、鍵管理、読み取り専用化の範囲を設計しなければならない。単に暗号化しただけでは、読み出した内容が期待値と一致していることまでは保証されない。単に dm-verity を使っただけでは、保存内容を第三者に読まれないようにはできない。両者は代替関係ではなく、目的が異なる補完関係である。
| 性質 | 暗号化 | dm-verity | 違い | 設計上の意味 |
|---|---|---|---|---|
| 目的 | 鍵なしでは内容を読めないようにする。 | 読み出した内容が事前に固定された内容と一致するかを確認する。 | 暗号化は秘匿性、 dm-verity は完全性検証を担当する。 | 秘匿したいのか、改ざんを検出したいのか、両方必要なのかを先に分ける必要がある。 |
| 更新との相性 | 通常の読み書き媒体でも利用できる。 | 読み取り専用または固定化された内容に向く。 | dm-verity は内容が変わるたびに検証構造も変わるため、日常更新には向かない。 | 更新する主系媒体には暗号化と別の完全性設計を使い、固定アーカイブには dm-verity を検討する。 |
| 信頼の起点 | 鍵、パスフレーズ、 KDF、ヘッダー管理が重要になる。 | root hash とハッシュツリーの整合性が重要になる。 | 何を安全に保管すべきかが異なる。 | 暗号化では鍵を守り、 dm-verity では root hash を信頼できる経路で守る必要がある。 |
| 検出できる問題 | 鍵なしの読み取りを防ぐ。 | ブロックの改ざんや破損を検出できる。 | 暗号化だけでは破損や差し替えを十分に検出できない場合がある。 | 長期保全では、秘匿性と完全性を別々に設計する必要がある。 |
ここから言える第一のことは、自由ソフトウェアだけで扱える保護機能は暗号化だけではないということである。 cryptsetup と LUKS2 は秘匿性を中心に扱い、 veritysetup と dm-verity は読み取り専用データの完全性検証を扱う。これにより、 Linux では、秘密を守るための仕組みと、内容が変わっていないことを確認するための仕組みを、どちらも自由ソフトウェアで構成できる。ただし、それぞれの前提は異なるため、暗号化の代わりに dm-verity を使う、あるいは dm-verity の代わりに暗号化だけで済ませる、という整理はできない。
第二に、 dm-verity は「保管後に変わっていないこと」を扱うため、長期保全や配布物検証と相性がよい。たとえば、更新しないアーカイブ、固定化したシステムイメージ、配布後に改ざんされていないことを確認したいデータでは、 root hash を別経路で保管しておくことで、後から読み出した内容を検証できる。この性質は、通常の暗号化バックアップとは別の価値を持つ。暗号化バックアップは第三者に読まれないことを重視するが、 dm-verity は読み出した内容が保存時点と一致していることを重視する。
第三に、 dm-verity は更新されるバックアップ媒体の万能な安全装置ではない。日次バックアップや差分同期のように内容が変化する媒体では、読み取り専用のハッシュツリー検証という前提が合わない。こうした用途では、 dm-integrity、ファイル単位のハッシュ台帳、バックアップ後の照合、複数媒体間の比較、ファイルシステムの整合性検査を組み合わせる方が現実的である。つまり、 dm-verity から導ける抽象的な結論は、データ保護では「変わらないものを検証する仕組み」と「変わり続けるものを安全に更新する仕組み」を分けるべきだということである。
13. integritysetup は読み書き可能な完全性保護を作るが、コストも作る
integritysetup が扱う dm-integrity は、読み書き可能なブロックデバイスに対して、セクター単位の integrity tag を持たせる仕組みである。 Linux カーネル文書は、 dm-integrity が各セクターに追加の integrity information を保存するブロックデバイスをエミュレートすると説明している[34]。 integritysetup の man page も、 dm-integrity は dm-verity と異なり読み書き操作をサポートし、チェックサムや暗号学的ハッシュにより透過的にデータ完全性を確認できると説明している[35]。ここで重要なのは、dm-integrity が暗号化の代替ではなく、読み書き可能なデータに検証用の付加情報を持たせる別レイヤーだという点である。
dm-integrity の基本的な考え方は、データ本体だけでなく、そのデータが正しいかを確認するためのタグも一緒に管理することである。通常のブロックデバイスでは、セクターにはデータ本体だけが保存される。 dm-integrity では、各セクターまたはセクター群に対応する integrity tag を別領域に保存し、読み出し時にデータ本体とタグの整合性を確認する。タグは単純なチェックサムである場合もあり、暗号学的ハッシュや認証タグと組み合わせる場合もある。つまり、読み出したデータが偶発的に壊れていないか、または設定によっては意図的に改ざんされていないかを、ブロック層で検出するための仕組みである。
dm-verity との最大の違いは、更新できるかどうかである。 dm-verity は読み取り専用の固定データを前提にし、あらかじめ作ったハッシュツリーと root hash に対して読み出し内容を検証する。一方、 dm-integrity は読み書き可能なデバイスを前提にする。データを書き込むたびに、そのデータに対応する integrity tag も更新する。したがって、 dm-integrity は更新される領域に完全性保護を加えられるが、その代わりにタグ領域、タグ更新、クラッシュ時の整合性管理という追加コストを引き受ける。
| 要素 | 役割 | 具体的に起きること | 注意点 | そこから言えること |
|---|---|---|---|---|
| データセクター | 実際の利用データを保持する。 | ファイルシステムから見た通常の読み書きは、最終的にセクター単位の I/O として処理される。 | データ本体だけを見ても、その内容が壊れていないかは分からない。 | 読み書き可能な媒体で完全性を確認するには、データ本体とは別の検証情報が必要になる。 |
| integrity tag | データセクターに対応する検証用情報を保持する。 | 読み出し時にはデータ本体から計算した値と保存済みタグを照合し、書き込み時にはデータ本体と対応するタグを更新する。 | タグも保存領域を消費し、書き込み時にはタグ更新の I/O が増える。 | 完全性保護は、容量と書き込み負荷を増やす代わりに検出能力を得る仕組みである。 |
| journal | データ本体と integrity tag の更新順序を管理する。 | クラッシュ時にデータとタグの片方だけが更新された状態にならないように補助する。 | journal は安全性を高めるが、追加の書き込みと性能コストを発生させる。 | 読み書き可能な完全性保護では、検証情報だけでなく更新の一貫性も設計対象になる。 |
| integritysetup | dm-integrity デバイスの作成、open、format などを扱う。 | 対象ブロックデバイスに integrity メタデータを構成し、読み書き可能な検証付き mapping を作る。 | 既存データのある媒体へ不用意に適用すると、形式化やメタデータ配置によりデータを失う可能性がある。 | dm-integrity は後付けの軽いオプションではなく、媒体設計段階で考えるべきレイヤーである。 |
| dm-integrity | カーネル側で読み書き時のタグ処理と検証を行う。 | 上位からは通常のブロックデバイスのように見えるが、下位ではデータ本体とタグを対応させて処理する。 | 性能、容量、クラッシュ一貫性、下位媒体の特性に強く影響される。 | dm-integrity は保護を増やす一方で、ストレージ負荷も増やすため、用途を選ぶ。 |
dm-crypt、 dm-verity、 dm-integrity は似た位置に見えるが、守るものが違う。 dm-crypt は秘匿性を担当し、鍵なしでは内容を読めないようにする。 dm-verity は読み取り専用データの完全性検証を担当し、固定された内容が読み出し時にも同じかを確認する。 dm-integrity は読み書き可能なデータに完全性タグを持たせ、更新されるブロックデバイスでも整合性を検証できるようにする。この違いを分けないと、暗号化しているから改ざん検出もできる、または dm-verity があるから更新可能媒体も保護できる、という誤解が生じる。
| 機能 | 守るもの | 仕組み | 向く用途 | 向かない用途 |
|---|---|---|---|---|
| dm-crypt | 秘匿性を守る。 | 読み書きされるブロックを透過的に暗号化・復号する。 | 紛失や盗難に備えた暗号化媒体、 LUKS2 による Linux 主系暗号化バックアップ。 | 単独では改ざん検出、媒体故障検出、ファイル単位の整合性検証にはならない。 |
| dm-verity | 読み取り専用データの完全性を検証する。 | ハッシュツリーと root hash により、固定データの読み出し内容を検証する。 | 固定イメージ、配布イメージ、読み取り専用アーカイブ、改ざん検出が必要な参照用データ。 | 日常的に更新するバックアップ媒体、作業領域、差分同期先には向かない。 |
| dm-integrity | 読み書き可能なデータの完全性タグを扱う。 | 各セクターに対応する integrity tag を保存し、読み書き時にデータとタグを検証・更新する。 | 読み書き可能な媒体で、ブロック単位の破損検出や完全性保護を強めたい用途。 | 低速媒体、小ファイル大量同期、頻繁なランダム書き込み、容量余裕の少ない媒体には慎重な評価が必要である。 |
dm-integrity でできることは、読み書き可能なブロックデバイスに、データ本体とは別の完全性情報を持たせることである。これにより、読み出したセクターが対応するタグと一致しない場合に、破損や不整合を検出できる。これは、通常の暗号化だけでは得られない性質である。暗号化されたデータが読めることと、そのデータが保存時の期待値と一致していることは同じではない。 dm-integrity はこの差を埋めるためのレイヤーであり、暗号化と組み合わせることで、秘匿性と一定の完全性保護を同時に設計できる。
一方で、dm-integrity でできないことも明確である。第一に、dm-integrity はバックアップの代替ではない。タグ不一致を検出できても、壊れたデータを自動的に正しい内容へ戻せるわけではない。第二に、ファイル単位の意味を理解するわけではない。dm-integrity はブロック層で動くため、どのファイルが壊れたか、どのアプリケーションデータが論理的に不整合になったかまでは判断しない。第三に、すべての攻撃や障害を防ぐわけではない。鍵が漏れた場合、上位ファイルシステムが破損した場合、ユーザーが誤ってファイルを削除した場合、アプリケーションが壊れたデータを書き込んだ場合、dm-integrity だけでは解決できない。
| 観点 | dm-integrity でできること | dm-integrity ではできないこと | 必要になる補完策 | そこから言えること |
|---|---|---|---|---|
| 破損検出 | セクター単位でデータと integrity tag の不一致を検出できる。 | 不一致を検出しても、正しいデータを自動復元できるとは限らない。 | 複数バックアップ、別媒体コピー、復旧手順、ハッシュ照合が必要になる。 | 完全性検出と復旧能力は別であり、検出だけでは保全設計は完結しない。 |
| 改ざん検出 | 設定によっては、データ本体の不正な変更をタグ不一致として検出できる。 | 信頼境界の内側で正規に書き込まれた悪いデータまでは区別できない。 | アクセス制御、監査、バックアップ世代管理、アプリケーション側検証が必要になる。 | dm-integrity はブロックの整合性を扱うが、操作の正当性までは判断しない。 |
| 暗号化との併用 | dm-crypt と組み合わせることで、秘匿性と完全性保護を同時に設計できる。 | レイヤー構成、鍵管理、性能、復旧手順を誤ると複雑性が増す。 | LUKS2、 dm-integrity、ヘッダーバックアップ、実測評価を一体で設計する必要がある。 | 保護レイヤーを増やすほど、管理レイヤーも増える。 |
| ファイル単位の確認 | ブロック単位の整合性検証を提供できる。 | どのファイルが論理的に正しいか、アプリケーションデータとして整合しているかは判断しない。 | ファイル単位ハッシュ、アプリケーション検証、バックアップ検証ログが必要になる。 | ブロック層の完全性とファイル層の正しさは分けて考える必要がある。 |
| 誤操作対策 | ストレージ下位層で生じた不整合の検出には役立つ。 | ユーザーが正規に削除したファイル、上書きしたファイル、同期で消したファイルは防げない。 | スナップショット、世代バックアップ、削除保護、運用手順が必要になる。 | 完全性保護は人的ミス対策ではなく、別途世代管理が必要である。 |
ただし、読み書き可能な完全性保護は無料ではない。データ本体を書くだけでなく、それに対応するタグも一貫して書かなければならない。クラッシュ時には、データとタグの整合が崩れないようにする必要がある。このため、容量コスト、書き込みコスト、メタデータ更新、クラッシュ復旧、性能劣化が発生する。特に USB 外付け HDD、低速な 2.5-inch HDD、小ファイル大量同期、ランダム書き込みでは、暗号処理そのものよりタグ更新やファイルシステムのメタデータ更新が律速になる場合がある。
| コスト | 発生理由 | 影響しやすい場面 | 観測される症状 | 判断への影響 |
|---|---|---|---|---|
| 容量コスト | データ本体とは別に integrity tag や関連メタデータを保存するためである。 | 容量に余裕が少ない外付け HDD、世代バックアップ、長期保全媒体。 | 実データに使える容量が減る。 | 容量効率を重視する媒体では、得られる検出能力と容量損失を比較する必要がある。 |
| 書き込みコスト | データ更新に加えて、対応する integrity tag も更新するためである。 | 小ファイル大量同期、ランダム書き込み、メタデータ更新の多いバックアップ。 | 書き込み回数が増え、処理時間が延びる。 | 低速媒体では、完全性保護より実用速度を優先する判断が必要になる場合がある。 |
| クラッシュ一貫性コスト | データ本体とタグの片方だけが更新された状態を避ける必要があるためである。 | 電源断、 USB 切断、長時間バックアップ中の障害、バスパワー外付け HDD。 | ジャーナルや同期処理が増え、障害時の復旧確認が必要になる。 | 外付け媒体では電源安定性と取り外し手順がより重要になる。 |
| CPU コスト | チェックサム、ハッシュ、認証タグの計算が発生するためである。 | 低性能 CPU、暗号支援が弱い環境、同時に dm-crypt も使う構成。 | CPU 使用率が上がり、他処理と競合する可能性がある。 | 高速 SSD や高性能 CPU では目立ちにくく、低速 CPU や複合レイヤーでは無視しにくい。 |
| I/O コスト | タグ領域へのアクセスや追加メタデータ更新が発生するためである。 | HDD、特にランダムアクセスに弱い 2.5-inch HDD、 USB 接続媒体。 | シーク増加、待ち時間増加、コピーや rsync の極端な遅延が起きる場合がある。 | 媒体特性によっては、dm-integrity の採用が実用性を大きく下げる。 |
ここから言える第一のことは、dm-integrity は完全性保護を「読み書き可能な媒体」へ持ち込むための強力な仕組みだが、常に採用すべき標準設定ではないということである。読み取り専用の固定データであれば dm-verity の方が目的に合う。通常の暗号化バックアップで秘匿性を重視するなら dm-crypt / LUKS2 が中心になる。読み書き可能な媒体で、ブロック単位の破損検出や完全性保護をさらに強めたい場合に、dm-integrity を検討する。つまり、dm-integrity は暗号化媒体を単純に強化する追加オプションではなく、容量、性能、復旧手順を含めて採用可否を判断する設計要素である。
第二に、dm-integrity は特に低速外付け媒体では慎重に評価すべきである。USB 外付け HDD、2.5-inch HDD、小ファイル大量同期、ランダム書き込みが多いバックアップでは、タグ更新、ジャーナル、ファイルシステムメタデータ更新が重なり、体感上の遅さが大きくなる可能性がある。暗号化処理そのものは CPU の AES 支援で十分速くても、ストレージ側のランダム I/O が詰まれば全体は遅くなる。したがって、dm-integrity の採用判断では、理論上の安全性だけでなく、対象媒体での実測が不可欠である。
第三に、dm-integrity から得られる抽象的な結論は、保護機能を増やすほど、保護対象だけでなく運用対象も増えるということである。暗号化を加えれば鍵とヘッダーを管理する必要が生じる。完全性タグを加えればタグ領域、クラッシュ一貫性、検証失敗時の対応を管理する必要が生じる。世代バックアップを加えれば世代保持と削除ポリシーを管理する必要が生じる。したがって、長期運用では「安全そうな機能を全部足す」のではなく、何を防ぎたいのか、何を検出したいのか、どの性能低下まで許容するのか、壊れたときにどう復旧するのかを先に決める必要がある。
結論として、integritysetup と dm-integrity は、自由ソフトウェアだけで読み書き可能な完全性保護を構成できる重要な選択肢である。しかし、日常的な外付けバックアップ媒体では、LUKS2 + ext4 のような単純な構成の方が復旧性、速度、運用再現性のバランスで有利な場合も多い。dm-integrity は、完全性検出を強く求める用途、媒体性能に余裕がある用途、クラッシュ時の一貫性を含めて設計できる用途で検討するべきであり、低速な外付け HDD に機械的に重ねるべきものではない。
14. 速度は暗号計算だけでなく、ブロック I/O 全体で決まる
暗号化媒体の速度を考えるとき、「暗号が重いかどうか」だけを見ると判断を誤る。 Linux の kernel crypto API は、ユーザー空間からカーネルの暗号 API を利用する経路を提供し、 dm-crypt や関連機能はカーネル側の暗号実装とブロック I/O 経路に乗る[36]。 cryptsetup には benchmark 機能もあり、暗号アルゴリズムの処理速度を測定できる[37]。しかし、この benchmark が示すのは主に暗号変換そのものの処理能力であり、実際のバックアップ、 rsync、 cp、ファイルシステム更新、 USB 外付け HDD の待ち時間をそのまま表すものではない。暗号計算が十分速くても、媒体側のランダム I/O、ファイルシステムのメタデータ更新、 USB ブリッジ、ジャーナル、キャッシュ切れ、同期処理が詰まれば、実運用は遅くなる。
速度を見るときは、まず処理経路を分解する必要がある。アプリケーションがファイルを書き込むと、その書き込みはファイルシステムに渡される。ファイルシステムは、データ本体だけでなく、ディレクトリエントリ、 inode、空き領域管理、 journal などのメタデータを更新する。暗号化媒体であれば、その下で dm-crypt がブロックを暗号化する。さらに dm-integrity を重ねていれば integrity tag の更新も発生する。最後に、 USB ストレージ、 HDD、 SSD、フラッシュ変換層、ディスクキャッシュ、物理書き込みへ到達する。したがって、利用者が観測する速度は、暗号計算単体ではなく、上位アプリケーションから物理媒体までの全レイヤーの合成結果である。
| レイヤー | 速度に影響する要因 | 遅くなる典型例 | 切り分けで見るべき点 | そこから言えること |
|---|---|---|---|---|
| アプリケーション | cp、 rsync、 tar、バックアップスクリプトなどの処理方式が影響する。 | 小ファイルを大量に逐次コピーする、 rsync が差分判定のために多数の stat を発行する、ログ出力が多すぎる。 | 単純コピーなのか、差分同期なのか、削除反映があるのか、ファイル数が多いのかを見る。 | 同じ媒体でも、処理方式が変われば I/O パターンが変わり、速度も大きく変わる。 |
| ファイルシステム | ext4、 FAT、 exFAT、 NTFS などのメタデータ構造、 journal、権限管理、空き領域管理が影響する。 | ext4 で小ファイルを大量に作成し、 inode、 directory entry、 journal、更新時刻が頻繁に更新される。 | 大きな連続ファイル中心なのか、小ファイル大量なのか、メタデータ更新が多いのかを見る。 | 暗号化前後の速度差に見えても、実際にはファイルシステム変更による I/O 増加が支配的な場合がある。 |
| dm-crypt | 暗号方式、鍵長、 XTS、セクターサイズ、 CPU の AES-NI などの暗号支援が影響する。 | CPU が遅い、暗号支援が弱い、複数レイヤーの暗号処理が重なる。 | cryptsetup benchmark の値と、実ディスク書き込み速度のどちらが小さいかを見る。 | 暗号ベンチマークが媒体速度を大きく上回るなら、律速は暗号計算ではない可能性が高い。 |
| 完全性レイヤー | dm-integrity の integrity tag、 journal、タグ領域への追加 I/O が影響する。 | データ本体の書き込みに加えてタグ更新が発生し、ランダム I/O と書き込み回数が増える。 | dm-integrity を重ねているか、タグサイズや journal の有無、クラッシュ一貫性設定を見る。 | 完全性保護は検出能力を増やすが、低速媒体では速度低下を大きくする可能性がある。 |
| ブロック I/O | I/O スケジューラー、キュー深度、キャッシュ、同期書き込み、 flush、 discard が影響する。 | 同期書き込みや flush が頻発し、 HDD が待ち時間を吸収できない。 | iostat、iotop、dmesg、syslog、書き込み待ち、デバイスリセットの有無を見る。 | 体感速度の低下は、暗号処理ではなく I/O 待ちとして現れることが多い。 |
| 接続経路 | USB 規格、 USB-SATA ブリッジ、電源供給、ケーブル、ハブ、 UASP 対応が影響する。 | バスパワー不足、 USB ブリッジの癖、ハブ経由、ケーブル不良、デバイスの一時切断。 | 同じディスクを別ポート、別ケーブル、別筐体、別ホストで試す。 | 暗号化やファイルシステムの問題に見えても、実際には接続経路の不安定さが原因の場合がある。 |
| 物理媒体 | SSD、 3.5-inch CMR HDD、 2.5-inch HDD、 SMR、キャッシュ容量、ファームウェアが影響する。 | SMR 的な書き込み再配置、キャッシュ切れ、小ファイル大量更新、ランダム書き込みで極端に遅くなる。 | 連続書き込みは速いか、小ファイルやランダム更新で遅いか、長時間処理で速度が落ちるかを見る。 | 媒体が同じ HDD でも、容量、世代、記録方式、筐体、ブリッジにより実運用速度は大きく変わる。 |
既稿で扱ったように、 2.5-inch HDD で LUKS + ext4 が極端に遅くなる場合、暗号計算だけでは説明できないことがある[6]。たとえば、 TrueCrypt + FAT の頃には目立たなかった遅さが、 LUKS + ext4 へ移行した後に顕在化した場合、変わったものは暗号方式だけではない。 TrueCrypt 本体から dm-crypt 経路へ変わり、 FAT から ext4 へ変わり、ファイルシステムのメタデータ構造が変わり、 journal が入り、 Unix 権限や inode 管理が入り、コピー方式や同期方式も変わっている可能性がある。したがって、「LUKS が遅い」と即断するのではなく、「暗号レイヤー、ファイルシステム、媒体、 I/O パターンのどこが増えたのか」を分けて見る必要がある。
特に小ファイル大量同期では、速度低下の主因は暗号計算よりメタデータ更新になりやすい。大きな 1 個のファイルを連続書き込みする場合、処理は比較的順次 I/O に近くなり、 HDD でも一定の速度が出やすい。しかし、小さなファイルを大量に作成・更新・削除する場合、ファイル本体の書き込みよりも、ディレクトリ更新、 inode 更新、空き領域管理、 journal 更新、更新時刻の反映、 rsync の差分判定が増える。暗号化レイヤーはその下で全ブロックを処理するため、上位から細かい I/O が大量に流れてくるほど、暗号化以前にストレージ側のランダム I/O が詰まりやすくなる。
| I/O パターン | 特徴 | HDD での影響 | 暗号化媒体での見え方 | 判断 |
|---|---|---|---|---|
| 大容量連続書き込み | 大きなファイルを順に書き込む。 | シークが少なく、 HDD でも比較的速度が出やすい。 | 暗号計算と媒体の連続書き込み性能が主に見える。 | この条件で十分速いなら、暗号計算そのものは律速ではない可能性が高い。 |
| 小ファイル大量作成 | 多数の小ファイルとディレクトリを作る。 | メタデータ更新とシークが増え、 HDD では極端に遅くなりやすい。 | LUKS や ext4 が遅いように見えるが、実際には小 I/O の多発が支配的な場合がある。 | ファイル数、ディレクトリ数、 inode 更新、 journal 更新を含めて評価する。 |
| rsync 差分同期 | ファイル一覧取得、サイズ・時刻比較、必要に応じた削除や更新を行う。 | 読み取り、 stat、ディレクトリ走査、削除、書き込みが混在し、ランダム I/O が増える。 | 単純な書き込み速度より遅く見え、初回同期と差分同期で性質が変わる。 | rsync の速度を媒体の連続書き込み性能と同一視しない。 |
| 削除を伴う同期 | 宛先にだけ存在するファイルを削除しながら同期する。 | ディレクトリ更新、空き領域管理、 journal 更新が増える。 | 書き込み量が少ないのに処理時間が長いことがある。 | データ量だけでなく、変更件数と削除件数を見る必要がある。 |
| 完全性タグ付き更新 | dm-integrity などでデータとタグを同時に更新する。 | 追加 I/O と一貫性管理が増え、低速 HDD では負荷が大きい。 | 暗号化 + 完全性保護 + ファイルシステム journal が重なって遅くなる。 | 安全機能を重ねるほど I/O パターンが重くなるため、実測なしに採用しない。 |
cryptsetup で TrueCrypt / VeraCrypt 互換ボリュームを開く場合も、速度評価は単純ではない。 cryptsetup を使うと、既存ヘッダーを解釈した後の読み書きは Linux の dm-crypt と kernel crypto API に乗る。これは、保守終了した TrueCrypt 本体の古い I/O 実装から離れ、現在の Linux カーネル経路へ寄せられるという利点を持つ。しかし、それだけで必ず高速になるとは限らない。内部ファイルシステムが FAT であればメタデータ構造は単純だが、 Unix 権限やシンボリックリンクには弱い。 ext4 であれば Linux 運用には向くが、 journal やメタデータ更新が増える。 NTFS や HFS+ であれば、 Linux 側ドライバーの状態や元 OS との整合性が加わる。つまり、暗号形式を Linux 標準経路に載せても、最終速度は内部ファイルシステムと媒体に強く依存する。
媒体特性も速度評価の核心になる。 SSD はランダム I/O に強く、小ファイル大量更新やメタデータ更新を吸収しやすい。 3.5-inch CMR HDD は連続書き込みに強く、大容量バックアップでは比較的安定しやすい。 2.5-inch HDD はバスパワー、筐体、発熱、キャッシュ、記録方式、 USB ブリッジの影響を受けやすく、小ファイルやランダム更新で極端に遅くなることがある。 SMR 的な挙動をする HDD では、書き込み再配置やキャッシュ切れにより、最初は速くても長時間処理で急に遅くなる場合がある。したがって、同じ LUKS + ext4 でも、媒体が変われば評価は変わる。
| 媒体 | 得意な I/O | 苦手な I/O | LUKS + ext4 での見え方 | 運用判断 |
|---|---|---|---|---|
| SSD | ランダム I/O、小ファイル、メタデータ更新、並列 I/O に強い。 | 書き込み寿命、発熱、安価な USB SSD のキャッシュ切れには注意が必要である。 | 暗号化や ext4 journal の追加負荷が目立ちにくい。 | 更新頻度の高い暗号化バックアップや作業用暗号化領域に向く。 |
| 3.5-inch CMR HDD | 大容量の連続書き込み、定期バックアップ、据え置き運用に比較的強い。 | ランダム I/O、小ファイル大量更新、頻繁な削除には SSD より弱い。 | 大容量バックアップでは安定しやすいが、小ファイル中心では遅さが出る。 | 大容量の定期同期先として有力だが、ファイル数の多い同期では時間を見込む。 |
| 2.5-inch HDD | 可搬性、低消費電力、簡易バックアップに向く。 | ランダム I/O、長時間書き込み、キャッシュ切れ、バスパワー不安定、小ファイル大量更新に弱い。 | LUKS + ext4 のメタデータ更新や journal が重なると、極端な遅さとして表面化する場合がある。 | 媒体ごとの差が大きいため、実測で許容できるものだけを主系にし、遅すぎる媒体は互換バックアップや読み取り中心へ回す。 |
| SMR HDD | 連続的で単純な追記では容量単価の利点がある。 | ランダム更新、書き換え、長時間の混合 I/O、キャッシュ切れに弱い。 | 初期速度は出ても、途中から急激に遅くなる可能性がある。 | 差分同期や小ファイル大量更新を行う暗号化バックアップでは慎重に扱う。 |
| USB 外付け媒体 | 取り回しと交換性に優れる。 | USB ブリッジ、ケーブル、電源、 UASP、ハブ、熱による不安定性を受ける。 | 暗号やファイルシステムの問題に見えても、実際には接続経路が律速または障害要因になることがある。 | 速度だけでなく、 syslog、 dmesg、切断履歴、デバイスリセットも確認する。 |
速度の切り分けでは、まず「暗号計算が律速なのか」を確認する。 cryptsetup benchmark の AES-XTS 系の値が、対象媒体の実書き込み速度を大きく上回っているなら、暗号計算が主因である可能性は下がる。次に、大きな単一ファイルの連続書き込みと、小ファイル大量同期を分けて測る。連続書き込みが速く、小ファイル同期だけが遅いなら、ファイルシステムとメタデータ更新、ランダム I/O が疑わしい。さらに、暗号化なしの同じファイルシステム、暗号化ありの別ファイルシステム、別媒体、別 USB ポートで比較する。これにより、暗号、ファイルシステム、媒体、接続経路のどこに主因があるかを絞れる。
| 確認項目 | 見る理由 | 結果の読み方 | 次に見るもの |
|---|---|---|---|
| cryptsetup benchmark | 暗号アルゴリズム単体の処理能力を見るためである。 | 暗号速度が実媒体速度を大きく上回るなら、暗号計算は主律速ではない可能性が高い。 | 実 I/O、ファイルシステム、媒体特性を見る。 |
| 大容量単一ファイル書き込み | 連続書き込み性能を見るためである。 | ここが速く、小ファイル同期が遅いなら、ランダム I/O とメタデータ更新が疑わしい。 | 小ファイル大量同期、rsync の処理件数を見る。 |
| 小ファイル大量同期 | 実際のバックアップに近い I/O パターンを見るためである。 | 極端に遅い場合、ファイルシステム journal、inode、ディレクトリ更新、HDD のシークが影響している可能性がある。 | ファイル数、ディレクトリ数、削除件数、rsync オプションを見る。 |
| 暗号化なし ext4 との比較 | 暗号化レイヤーを外したときの差を見るためである。 | 暗号化なしでも遅いなら、ファイルシステムまたは媒体側の影響が大きい。 | 媒体交換、接続経路、ファイルシステム設定を見る。 |
| FAT / exFAT / ext4 の比較 | ファイルシステムのメタデータ構造の違いを見るためである。 | FAT 系では速く ext4 では遅い場合、Unix 権限、journal、inode、メタデータ更新の負荷が影響している可能性がある。 | その媒体を主系にするか、互換バックアップに回すかを判断する。 |
| syslog / dmesg | USB 切断、デバイスリセット、I/O error、媒体異常を確認するためである。 | device offline、reset、I/O error が出るなら、速度以前に接続または媒体の信頼性問題である。 | ケーブル、ポート、電源、筐体、媒体交換を確認する。 |
ここから言える第一のことは、速度問題を暗号方式名で説明してはいけないということである。 LUKS が遅い、 TrueCrypt が速い、 cryptsetup が速い、という言い方は粗すぎる。実際には、 LUKS + ext4 + 2.5-inch HDD + 小ファイル大量同期 + USB 接続 + journal 更新という組み合わせが遅い場合がある。一方で、同じ LUKS + ext4 でも SSD や性能のよい 5TB 2.5-inch HDD では問題が目立たない場合もある。したがって、速度評価は形式名ではなく構成全体で行う必要がある。
第二に、 TrueCrypt 本体より cryptsetup を優先する理由は、速度だけではなく、現代 Linux の標準経路へ寄せられることにある。 cryptsetup で TrueCrypt / VeraCrypt 互換ボリュームを開いた場合、読み書きは dm-crypt と kernel crypto API の経路に乗るため、古い TrueCrypt 本体の I/O 実装へ依存しない。これは信頼性、保守性、切り分け可能性の面で重要である。ただし、標準経路に載せることは、遅い媒体や悪い I/O パターンを消すことではない。標準経路に載せたうえで、どこが律速かを測れるようになることが重要である。
第三に、媒体選定は暗号化設計の一部である。暗号化形式やファイルシステムだけを正しく選んでも、対象媒体がその I/O パターンに耐えなければ運用は成立しない。更新頻度が高く、小ファイルが多く、差分同期を行い、 ext4 の権限やメタデータを保持したいなら、 SSD や性能に余裕のある媒体を選ぶべきである。大容量で更新頻度が低いなら 3.5-inch CMR HDD も候補になる。低速な 2.5-inch HDD は、主系の LUKS + ext4 更新先として無理に使うより、読み取り中心、互換バックアップ、低頻度同期など役割を限定する方が合理的である。
第四に、速度問題から導ける抽象的な結論は、保護レイヤーを増やすほど I/O の現実に近づいて評価しなければならないということである。暗号化、完全性タグ、journal、差分同期、削除反映、権限保持は、それぞれ正当な理由を持つ。しかし、それらはすべて追加の処理、追加のメタデータ、追加の I/O を発生させる。安全性と保全性を上げる設計は、媒体性能、復旧時間、運用時間、ログ量、失敗時の切り戻しと一体で評価しなければならない。つまり、暗号化媒体の速度とは、暗号アルゴリズムの速さではなく、保護設計全体が対象媒体の I/O 能力に収まっているかどうかの問題である。
15. 信頼性は秘匿性、完全性、復元可能性、保守可能性に分ける
暗号化媒体の信頼性は、一つの言葉でまとめると曖昧になる。暗号化しているから信頼できる、現役ソフトウェアだから信頼できる、自由ソフトウェアだから信頼できる、ベンチマークが速いから信頼できる、という単純な判断は成り立たない。暗号化媒体の信頼性は、少なくとも秘匿性、完全性、復元可能性、保守可能性に分けて考える必要がある。秘匿性は、第三者が媒体を入手しても中身を読めないことである。完全性は、読んだ内容が壊れていない、または改ざんされていないと確認できることである。復元可能性は、正当な利用者が将来も開けることである。保守可能性は、現在の OS、パッケージ、文書、手順、更新経路の中で、運用を継続できることである。既稿で述べた「暗号はいずれ破られるのか」という問題も、このうち暗号強度と時間の関係を扱ったものであり、暗号化媒体の信頼性全体を一度に説明するものではない[7]。
秘匿性だけを見れば、 LUKS2、 plain dm-crypt、 TrueCrypt / VeraCrypt 互換ボリューム、 BitLocker、 FileVault2 は、いずれも何らかの形で保存内容を読みにくくする仕組みである。しかし、秘匿性があることと、運用上信頼できることは同じではない。鍵を失えば正当な利用者も読めなくなる。ヘッダーを失えば、暗号方式が強くても復号できなくなる。パスフレーズが弱ければ、形式が現代的でも防御力は下がる。古いソフトウェアに依存していれば、将来の OS で開けなくなる可能性がある。つまり、秘匿性は信頼性の一部であって、信頼性そのものではない。
完全性も独立して考える必要がある。暗号化された媒体は、第三者に読まれにくい。しかし、暗号化だけで、保存内容が壊れていないことや、期待した内容と一致していることを十分に確認できるとは限らない。読み取り専用の固定データなら dm-verity によるハッシュツリー検証が使える。読み書き可能なデータなら dm-integrity による integrity tag が候補になる。ファイル単位ではハッシュ台帳、バックアップ後の照合、復元テスト、複数媒体間の比較が必要になる。ここから分かるのは、暗号化と完全性検証は競合する機能ではなく、別々のリスクを扱う補完的なレイヤーだということである。
復元可能性は、暗号化媒体で特に見落とされやすい。暗号化媒体は、攻撃者からデータを守る一方で、正当な利用者自身を締め出す構造を持つ。パスフレーズ、 keyfile、 LUKS ヘッダー、 TrueCrypt / VeraCrypt 互換ヘッダー、 BitLocker 回復キー、 FileVault 復旧キー、復旧手順、対応ソフトウェアがそろわなければ、データは存在していても実用上失われる。したがって、暗号化媒体の保全では、媒体そのものを保存するだけでは足りない。解除に必要な情報、形式を扱える実装、復元手順、検証済み環境をあわせて残す必要がある。
保守可能性は、時間軸を含む信頼性である。現在開ける媒体が、将来も同じように開けるとは限らない。保守終了した TrueCrypt 本体に依存する運用は、ソフトウェア寿命の問題を抱える。一方、 TrueCrypt / VeraCrypt 互換ボリューム形式そのものは、 cryptsetup や tcplay のような自由ソフトウェア実装で扱える範囲があるため、ソフトウェア本体の寿命と形式の寿命を分けられる。 LUKS2 は、 Linux の標準的な暗号化運用として cryptsetup から深く管理できる。 BitLocker や旧 FileVault2 は、条件付きで開ける場合があるが、 Windows や macOS の管理体系まで Linux で完全再現するものではない。つまり、保守可能性は「その形式が理論上安全か」ではなく、「現在と将来の運用環境で再現可能か」によって決まる。
| 信頼性の側面 | 意味 | 主な手段 | 限界 | そこから言えること |
|---|---|---|---|---|
| 秘匿性 | 第三者が媒体を入手しても中身を読めないようにする。 | LUKS2、 plain dm-crypt、 TrueCrypt / VeraCrypt 互換ボリューム、 BitLocker、 FileVault2 などを適切に開閉する。 | 鍵、パスフレーズ、 keyfile、ヘッダーを失えば正当な利用者も読めなくなる。 | 暗号化は必要条件であり、鍵管理とヘッダー管理を含めなければ信頼性にはならない。 |
| 完全性 | 読んだ内容が保存時点の期待値と一致するかを確認する。 | dm-verity、 dm-integrity、ハッシュ記録、リストア検証、複数媒体照合を組み合わせる。 | 暗号化だけでは十分な改ざん検出や破損検出にならない。 | 秘匿性と完全性は別の性質であり、必要に応じて別レイヤーで設計する必要がある。 |
| 復元可能性 | 正当な利用者が将来も媒体を開き、必要なデータを取り出せるようにする。 | ヘッダーバックアップ、回復キー、手順書、媒体台帳、複数環境での開封確認、定期的なリストア検証を行う。 | ソフトウェアだけでは、鍵素材の喪失、手順の喪失、媒体故障、知識継承の失敗を防げない。 | 暗号化媒体は保存するだけでは不十分であり、開ける条件を保存する必要がある。 |
| 保守可能性 | 現在の OS、パッケージ、文書、更新経路、標準コマンドの中で運用を続けられるようにする。 | Debian パッケージ、 Linux カーネル機能、文書化された形式、 cryptsetup、 tcplay、 veritysetup、 integritysetup を中心に置く。 | 外部形式は LUKS と同じ深さでは管理できず、 BitLocker や FileVault2 は元 OS の管理体系を完全には置き換えられない。 | 長期運用では、元ソフトウェアへの忠実さより、現役で保守される自由ソフトウェア経路で再現できることを優先するべきである。 |
この整理から言える第一のことは、暗号化媒体の信頼性を「安全か危険か」の二分法で判断してはいけないということである。 LUKS2 は新規 Linux 主系として深く管理しやすいが、それでもヘッダーや鍵を失えば復元できない。 TrueCrypt / VeraCrypt 互換ボリュームは、 TrueCrypt 本体が保守終了していても、 cryptsetup や tcplay で扱える範囲があるが、形式起因の制約や監査上の論点は残る。 BitLocker や旧 FileVault2 は Linux で開ける場合があるが、元 OS の管理体系を Linux に移植するものではない。 dm-verity と dm-integrity は完全性を強めるが、前提や性能コストが異なる。したがって、形式名だけで信頼性を判断するのではなく、どの側面の信頼性を必要としているのかを先に決める必要がある。
第二に、自由ソフトウェアだけで暗号化媒体を扱うことの利点は、信頼性を層ごとに分解できる点にある。 LUKS2 は新規 Linux 暗号化媒体の秘匿性と鍵管理を担う。 cryptsetup の TCRYPT 拡張は、既存 TrueCrypt / VeraCrypt 互換ボリュームを保守的に開く。 tcplay は互換形式の作成や変更を補う。 dm-verity は読み取り専用の改ざん検証を担う。 dm-integrity は読み書き可能な完全性保護を担う。つまり、単一の万能ソフトウェアを探すのではなく、リスクごとにレイヤーを配置することが重要である。
第三に、信頼性を高める設計は、常にコストも増やす。暗号化を加えれば鍵とヘッダーの管理が必要になる。完全性検証を加えればハッシュ、タグ、 root hash、検証失敗時の対応が必要になる。互換形式を残せば、対応実装と将来の読み出し確認が必要になる。外部 OS 由来の形式を扱えば、暗号化形式だけでなく内部ファイルシステムや OS 固有構造も確認しなければならない。したがって、信頼性設計とは、機能を足し続けることではなく、必要な保護と許容できる運用負荷の均衡を取ることである。
16. 結論として、自由ソフトウェアだけでかなり扱えるが、形式ごとの限界を分ける必要がある
自由ソフトウェア、あるいは Debian パッケージだけで暗号化媒体をどこまで扱えるのかという問いへの答えは、「かなり広く扱えるが、同じ深さで扱えるわけではない」である。 cryptsetup と Linux カーネルの dm-crypt により、 LUKS、 plain dm-crypt、 loop-AES、 TrueCrypt / VeraCrypt 互換ボリューム、 BitLocker、旧 FileVault2 まで到達できる。 veritysetup により、読み取り専用の改ざん検証を扱える。 integritysetup により、読み書き可能な完全性保護を扱える。 tcplay により、 TrueCrypt / VeraCrypt 互換ボリュームの作成、変更、 hidden volume、ヘッダー復元などを補える。この範囲は狭くない。少なくとも、 Linux では LUKS しか扱えない、あるいは TrueCrypt 系の媒体は古い本体がなければ扱えない、という理解は正確ではない。
しかし、これらは同じ意味で「サポートされている」わけではない。 LUKS2 は、作成、鍵スロット管理、ヘッダーバックアップ、再暗号化、将来の保守まで cryptsetup で深く扱える。 plain dm-crypt は単純だが、パラメーター管理を失うと復旧が難しい。 TrueCrypt / VeraCrypt 互換ボリュームは、 TrueCrypt 本体とは分けて、媒体形式として扱える。 cryptsetup は既存ヘッダーを変更しない保守的なマッピングに強く、 tcplay は形式管理を補う。 BitLocker と旧 FileVault2 は、必要な鍵素材と対応可能な構成があれば開ける場合があるが、 Windows や macOS の管理機構を Linux 上で完全に置き換えるわけではない。 dm-verity は読み取り専用の固定データに向き、 dm-integrity は読み書き可能な完全性保護を提供するが、容量と性能のコストを伴う。この違いを分けることが、本稿の中心的な結論である。
TrueCrypt については、特にソフトウェア本体と媒体形式を分ける必要がある。 TrueCrypt 本体は保守終了しており、独自ライセンスを持ち、現代 Linux の通常運用で第一候補にする理由は弱い。しかし、 TrueCrypt / VeraCrypt 互換ボリューム形式そのものは、 cryptsetup や tcplay によって扱える範囲がある。これは、古いソフトウェアを使い続けることとは違う。古い本体に依存せず、互換形式を自由ソフトウェアの実装で扱うという選択である。この分離により、既存媒体をただちに廃棄するのではなく、まず読める状態を確認し、必要なものを救出し、重要度や更新頻度に応じて LUKS2 へ段階移行する判断ができる。
セキュリティの観点でも、結論は単純ではない。 TrueCrypt 監査で指摘された問題は、 TrueCrypt 本体実装、 Windows API 依存、 AES 実装、 keyfile 処理、ヘッダー構造など、複数の層にまたがっている。 cryptsetup は TrueCrypt 本体のコードを実行するわけではなく、 TCRYPT 拡張として互換ヘッダーを解釈し、 Linux の dm-crypt と kernel crypto API へ接続する。そのため、 CryptAcquireContext や TrueCrypt 本体内 AES 実装のような実装起因の問題は、 cryptsetup では同じ形では現れない。一方で、 keyfile 処理やヘッダー認証のように形式起因に近い論点は、互換形式を扱う限り無視できない。ここから言えるのは、「TrueCrypt は監査で問題が出たから全部危険」でも、「cryptsetup で開けるから全部安全」でもなく、どの層の問題かを分けて判断する必要があるということである。
速度についても、結論は「cryptsetup なら速い」でも「LUKS は遅い」でもない。速度は暗号計算だけでなく、ファイルシステム、 journal、メタデータ更新、小ファイル数、 rsync の差分判定、 USB ブリッジ、 HDD / SSD、 SMR / CMR、キャッシュ、 dm-integrity のタグ更新まで含むブロック I/O 全体で決まる。 cryptsetup benchmark が十分速くても、 2.5-inch HDD、 ext4、小ファイル大量同期、 USB 接続が重なれば実運用は遅くなる。逆に、同じ LUKS + ext4 でも SSD や性能に余裕のある媒体では問題が目立たない場合がある。したがって、速度評価では形式名ではなく、構成全体と実測を見なければならない。
外部 OS 由来の暗号媒体についても、到達可能性と完全管理を分ける必要がある。 BitLocker や旧 FileVault2 は、 cryptsetup で開ける場合がある。しかし、それは Windows や macOS の暗号化管理体系を Linux が完全に再現するという意味ではない。 TPM 自動解除、 Secure Enclave、組織ポリシー、復旧キー管理、 APFS FileVault、スナップショット、 OS 固有メタデータは別問題である。さらに、暗号化レイヤーを開けても、内部ファイルシステムを Linux が安全に読み書きできるとは限らない。ここから言えるのは、外部形式対応は主に救出、参照、移行のための能力であり、新規 Linux 主系の標準形式として採用する根拠ではないということである。
| 対象 | 自由ソフトウェアでできること | できないこと・限界 | 運用上の位置づけ | 結論 |
|---|---|---|---|---|
| LUKS2 | 作成、開閉、鍵スロット管理、ヘッダーバックアップ、再暗号化などを cryptsetup で深く扱える。 | 鍵やヘッダーを失えば復元できず、媒体故障や誤削除を防ぐものではない。 | 新規 Linux 主系暗号化媒体の第一候補である。 | 自由ソフトウェアだけで最も深く管理できる暗号化形式として扱う。 |
| TrueCrypt / VeraCrypt 互換ボリューム | cryptsetup で保守的に開き、 tcplay で作成・変更・ hidden volume・ヘッダー復元などを補える。 | TrueCrypt / VeraCrypt 互換形式の制約や監査上の形式起因論点は残る。 | 既存媒体の保全、救出、段階移行の対象である。 | TrueCrypt 本体を使い続けるのではなく、互換形式として自由ソフトウェアで扱う。 |
| BitLocker | 回復キーやパスワードなど必要な鍵素材があれば、 cryptsetup で開ける場合がある。 | TPM 自動解除、 Windows 管理ポリシー、回復キー管理基盤を Linux で完全再現するものではない。 | Windows 由来媒体の救出・参照・移行用である。 | Linux 主系形式ではなく、相互運用と救出のための互換対象として扱う。 |
| 旧 FileVault2 | 古い Core Storage + HFS+ 系なら、条件付きで cryptsetup により開ける場合がある。 | APFS FileVault、 Secure Enclave、現在の macOS 管理体系を包括的に扱えるわけではない。 | 過去 macOS 資産への到達手段である。 | 現在の macOS 暗号化環境を Linux で完全管理できるとは考えない。 |
| dm-verity | 読み取り専用データの改ざんや破損をハッシュツリーで検証できる。 | 日常的に更新するバックアップ媒体や作業領域には向かない。 | 固定イメージ、配布イメージ、読み取り専用アーカイブ向けである。 | 変わらないものを検証する仕組みとして使う。 |
| dm-integrity | 読み書き可能なブロックデバイスに integrity tag を持たせられる。 | 容量、書き込み、クラッシュ一貫性、性能のコストがあり、復旧そのものを提供するわけではない。 | 完全性検出を強めたい読み書き媒体で慎重に検討する。 | 安全機能を足すほど運用コストも増えるため、媒体性能と復旧手順込みで判断する。 |
以上から、本稿の結論は 4 つに整理できる。第一に、自由ソフトウェアだけで暗号化媒体を扱える範囲は広い。 LUKS2 だけでなく、 TrueCrypt / VeraCrypt 互換ボリューム、 BitLocker、旧 FileVault2、 dm-verity、 dm-integrity まで、 Debian パッケージと Linux カーネル機能だけで到達できる領域は多い。第二に、その対応は形式ごとに深さが違う。 LUKS2 は深く管理できるが、外部形式は主に開く、参照する、救出する、段階移行するための互換対象である。第三に、 TrueCrypt 本体の保守終了は、 TrueCrypt / VeraCrypt 互換ボリューム形式の即死を意味しないが、古い本体を通常運用の中心に置く理由も弱い。第四に、新規の Linux 主系媒体は LUKS2 を中心にし、既存の互換媒体は cryptsetup と tcplay で読める状態を確認しながら、重要度に応じて段階移行するのが合理的である。
ここからさらに抽象化できることは、暗号化媒体の長期運用では「何で暗号化したか」よりも、「将来どの層まで再現できるか」が重要だということである。媒体形式、鍵素材、ヘッダー、実装、ファイルシステム、 OS 構造、完全性検証、復旧手順、速度特性を分けて確認しなければならない。古いソフトウェアを信じ続ける必要はないが、古い形式を無条件に捨てる必要もない。現役の自由ソフトウェアで開けるものは開ける状態を確認し、必要なデータを取り出し、今後更新し続ける主系は現行形式へ寄せる。この分離こそが、自由ソフトウェアだけで暗号化媒体を扱ううえで最も重要な実務判断である。
したがって、最終的な方針は明確である。新規に Linux 用の暗号化バックアップ媒体を作るなら、 LUKS2 を中心に設計する。既存の TrueCrypt / VeraCrypt 互換媒体は、 TrueCrypt 本体ではなく cryptsetup でまず保守的に開けるかを確認し、形式管理が必要な場合だけ tcplay を使う。 BitLocker や旧 FileVault2 は、救出・参照・移行のための外部形式として扱い、 Linux の主系形式にはしない。読み取り専用で固定したいデータには dm-verity を検討し、読み書き可能な完全性保護が本当に必要な場合だけ dm-integrity を検討する。速度と信頼性は実測と復元テストで確認する。これにより、自由ソフトウェアだけで扱える範囲を過小評価せず、同時に過大評価もしない、現実的な暗号化媒体運用が成立する。
参考文献
- id774, 暗号化ディスクを長期運用するための設計（2026-05-30）. https://blog.id774.net/entry/2026/05/30/4818/
- id774, 暗号化ディスク運用手順を整理する（2026-05-31）. https://blog.id774.net/entry/2026/05/31/4829/
- id774, LUKS 暗号化の手順と運用（2026-05-11）. https://blog.id774.net/entry/2026/05/11/4746/
- id774, TrueCrypt 資産を GNU/Linux で保全する（2026-05-16）. https://blog.id774.net/entry/2026/05/16/4773/
- id774, バックアップ・リカバリー戦略における物理媒体管理（2026-05-10）. https://blog.id774.net/entry/2026/05/10/4743/
- id774, 2.5-inch HDD で LUKS + ext4 が遅くなった理由（2026-05-24）. https://blog.id774.net/entry/2026/05/24/4801/
- id774, 暗号はいずれ破られる（2026-06-01）. https://blog.id774.net/entry/2026/06/01/4831/
- Debian, Details of package cryptsetup-bin in sid. https://packages.debian.org/sid/cryptsetup-bin
- Debian, Package Search Results — tcplay. https://packages.debian.org/tcplay
- Cryptsetup project, README.md. https://github.com/mbroz/cryptsetup/blob/main/README.md
- cryptsetup(8), Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup.8.html
- cryptsetup-open(8), Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup-open.8.html
- Linux Kernel Documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
- LUKS2 On-Disk Format Specification. https://gitlab.com/cryptsetup/LUKS2-docs
- LUKS1 On-Disk Format Specification. https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf
- Red Hat Documentation, LUKS を使用したブロックデバイスの暗号化. https://docs.redhat.com/ja/documentation/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening
- cryptsetup-tcryptDump(8), Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup-tcryptDump.8.html
- TrueCrypt official migration page. https://truecrypt.sourceforge.net/
- TrueCrypt License Version 3.0. https://www.truecrypt.org/docs/license
- GNU Project, Various Licenses and Comments about Them: Truecrypt license 3.0. https://www.gnu.org/licenses/license-list.html#Truecrypt-3.0
- NCC Group Cryptography Services, Truecrypt Phase Two Audit Announced. https://cryptoservices.github.io/blog/2015-02-18-truecrypt-phase-two/
- Security Affairs, TrueCrypt security audit reveals absence of backdoor. https://securityaffairs.com/35657/security/truecrypt-security-audit.html
- BSI, Security Analysis of TrueCrypt. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Truecrypt/Truecrypt.pdf?__blob=publicationFile&v=2
- tcplay project repository. https://github.com/bwalex/tc-play
- tcplay(8), Arch manual pages. https://man.archlinux.org/man/tcplay.8.en
- Debian, Details of package tcplay in sid. https://packages.debian.org/sid/tcplay
- VeraCrypt, Release Notes. https://veracrypt.io/en/Release%20Notes.html
- VeraCrypt, Conversion Guide for VeraCrypt 1.26 and Later. https://veracrypt.io/en/Conversion_Guide_VeraCrypt_1.26_and_Later.html
- BSI, Security Evaluation of VeraCrypt. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Veracrypt/Veracrypt.pdf?__blob=publicationFile&v=1
- Microsoft Learn, BitLocker overview. https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/
- Apple Platform Deployment, FileVault payload settings. https://support.apple.com/guide/deployment/filevault-payload-settings-dep32bf53500/web
- Linux Kernel Documentation, dm-verity. https://docs.kernel.org/admin-guide/device-mapper/verity.html
- veritysetup(8), Arch manual pages. https://man.archlinux.org/man/veritysetup.8.en
- Linux Kernel Documentation, dm-integrity. https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html
- integritysetup(8), Linux manual page. https://man7.org/linux/man-pages/man8/integritysetup.8.html
- Linux Kernel Documentation, Kernel Crypto API User Space Interface. https://docs.kernel.org/crypto/userspace-if.html
- cryptsetup-benchmark(8), Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup-benchmark.8.html