TrueCrypt 資産を GNU/Linux で保全する

TrueCrypt は、かつて暗号化ファイルコンテナーや暗号化デバイスを扱うための実用的な選択肢だった。通常ファイルの中に暗号化された仮想ディスクを作り、パスフレーズを入力してマウントすれば、内部を通常のドライブのように扱えた。外付け HDD、USB メモリー、パーティションを丸ごと暗号化する用途にも使われた。そのため、現在でも、過去に作成された TrueCrypt 7.1a のファイルコンテナーや、TrueCrypt で丸ごと暗号化されたデバイスが、既存の暗号データ資産として残っている場合がある。

しかし、現在 TrueCrypt について考えるとき、論点は新規採用ではない。新規に暗号化領域を作るなら、GNU/Linux では LUKS、cryptsetup、dm-crypt を使うのが自然であり、その運用はすでに別稿で整理した[1]。TrueCrypt はすでに保守停止済みであり、現在の主系暗号化基盤として選ぶべきものではない。一方で、この事実は、過去に作成した TrueCrypt 資産を直ちに捨てるべきだという意味でもない。データ量、媒体の所在、バックアップ構造、履歴的価値、鍵管理、移行作業の手間によって、現実には長期間保持せざるを得ない場合がある。

この問題の本質は、暗号手法の好き嫌いではなく、復元可能性の設計である。バックアップは単にデータを別媒体に置くことではなく、必要な時点で必要なデータを復元できるように、媒体、鍵、手順、検証履歴を組み合わせて管理することである[2]。暗号化されたデータ資産では、この条件がさらに厳しくなる。物理媒体が残っていても、パスフレーズ、鍵ファイル、読み出し手順、対応ツール、対象デバイスの識別情報が失われれば、データ本体は存在していても復元できない。暗号が破られていなくても、正当な利用者が読めなくなれば、保全には失敗している。

とくに古い暗号化媒体では、物理媒体の劣化、デバイス名の変化、読み出し環境の消滅、鍵ファイルの紛失、手順の忘却がすべて復元失敗の原因になる[3]。TrueCrypt 資産でも同じである。問題は、TrueCrypt の暗号が今すぐ破られるかどうかだけではない。むしろ、現在の GNU/Linux 環境で読み出せるか、どのコマンドで開けるか、鍵ファイルを使っているか、どの媒体が原本か、読み出した後にどのように LUKS 側へ移すかを確認し、記録することが重要になる。

保存とは、単にデータ本体を残すことではなく、未来の時点で必要な主体が必要な情報を理解可能な形で取り出せるようにすることである。この観点は、以前「未来の自分に意味を残す」という形で整理した[4]。暗号化されたデータ資産では、この問題が特に明確になる。暗号化ファイルや暗号化デバイスが残っていても、鍵、ヘッダー、対応ソフトウェア、復元環境、手順が失われれば、暗号が破られていなくても正当な利用者が読めなくなる。したがって、本稿は「TrueCrypt を使い続ける方法」ではなく、「TrueCrypt で作られた既存資産を未来に復元できる状態で保全するための運用設計」として読むべきである。

本稿では、TrueCrypt 7.1a の通常ファイルコンテナーと、TrueCrypt で丸ごと暗号化されたデータ用デバイスを主対象にする。GNU/Linux 上で cryptsetup の TCRYPT 拡張を使い、TrueCrypt 本体や古い VeraCrypt に依存せずに読み出せるかを確認する。そのうえで、読み取り専用確認、書き込み可能に扱う場合の注意点、鍵ファイル、隠しボリューム、バックアップヘッダー、tcryptDump、LUKS への移行、長期保全の台帳化まで整理する。目的は、TrueCrypt を再評価して推奨することではなく、既存の暗号データ資産を失わないための現実的な出口を作ることである。

1. TrueCrypt は新規利用ではなく既存資産の保全問題である

TrueCrypt を現在扱うには、まず歴史的背景を整理する必要がある。TrueCrypt は、かつて Windows、macOS、Linux をまたいで使えるクロスプラットフォームなオンザフライ暗号化ソフトとして広く使われた。通常ファイルの中に暗号化された仮想ディスクを作るファイルコンテナー、外付け HDD や USB メモリーやパーティションを丸ごと暗号化する非システムボリューム、Windows のシステム暗号化、隠しボリュームなどを扱えたため、個人利用から業務上の持ち出しデータ保護まで、かなり広い用途で実用的な選択肢になっていた。当時の利用者にとっては、暗号化されたコンテナーを作り、パスフレーズを入力してマウントすれば、内部を通常のドライブのように扱える点が分かりやすかった。

しかし、TrueCrypt は通常のソフトウェアとは異なる不確実性を抱えていた。開発者は匿名であり、ライセンスは GPL、BSD、Apache License のような標準的な自由ソフトウェアライセンスではなく、開発体制や責任主体も外部から見えにくかった。それでも、暗号化ソフトとして実際に使われ、ソースコードも公開され、実用上の信頼を集めていたため、多くの暗号化データ資産が TrueCrypt 形式で作られた。この時点で重要なのは、TrueCrypt が単なるソフトウェアではなく、過去に作成された暗号化ファイル、外付け媒体、バックアップ、アーカイブの形式として残ったことである。

転機になったのは、2014 年の突然の開発終了である。TrueCrypt の公式サイトは、TrueCrypt の使用は安全でない可能性があり、開発は終了したという趣旨の警告を掲げた。後に TrueCrypt 7.2 が公開されたが、それは従来どおり暗号化機能を発展させる通常リリースではなく、既存利用者に移行を促す特殊な位置づけだった。そのため、実質的な最終完全版としては TrueCrypt 7.1a が扱われることが多い。この出来事によって、TrueCrypt は「これから選ぶ暗号化ソフト」ではなく、「すでに作成されてしまった暗号資産をどう読むか」という問題へ変わった。

ここで判断を誤りやすいのは、TrueCrypt の終了をそのまま暗号破綻と同一視することである。開発終了、匿名開発者、独自ライセンス、公式サイトの警告、保守主体の不在は重大な問題である。しかし、それらは直ちに、過去に作成されたすべての TrueCrypt ボリュームが第三者に読まれることを意味しない。暗号資産の評価では、暗号アルゴリズム、鍵導出、実装、ヘッダー形式、パスフレーズ強度、鍵ファイル、媒体状態、読み出し環境、保守体制を分けて考える必要がある。TrueCrypt の問題は、単に「暗号が弱い」という話ではなく、保守停止済み形式を将来も復元可能な状態で維持できるかという問題である。

現在の GNU/Linux を前提にすれば、新規の暗号化領域には LUKS を使うのが自然である。LUKS は cryptsetup と dm-crypt を通じて Linux の標準的なブロックデバイス暗号化として扱え、ディストリビューションのパッケージ、man page、initramfs、復旧手順、運用ノウハウの蓄積がある。したがって、「これから何を使うべきか」という問いに対しては、TrueCrypt ではなく LUKS が基本になる。この点は迷う必要がない。

一方で、この結論は、既存の TrueCrypt 資産を直ちに破棄すべきだという意味ではない。既存資産には、すでに暗号化済みのファイルコンテナー、外付け HDD や USB メモリーの丸ごと暗号化、古いバックアップ、履歴的なアーカイブ、当時の作業環境に紐づくデータが含まれる。これらは、全量をすぐ LUKS へ移せるとは限らない。容量が大きい場合、媒体が複数ある場合、作成時のファイルシステムが古い場合、保管場所が分散している場合、鍵ファイルの有無を確認する必要がある場合、移行作業そのものがリスクになる場合もある。

したがって、TrueCrypt を現在扱うとき、最初に切り分けるべきなのは「これから使う暗号化方式」と「すでに存在する暗号データ資産」である。これから作るなら LUKS を使う。すでに TrueCrypt 形式で存在する資産については、恐怖で消すのでも、安心して使い続けるのでもなく、読み出し可能性を確認し、記録し、必要なデータを段階的に移行する対象として扱う。この区別を置かないと、TrueCrypt の議論は、過去資産の救済なのか、現在の暗号化方式選定なのかが混ざってしまう。

本稿の対象は、TrueCrypt を今後も使い続ける方法ではない。対象は、TrueCrypt 7.1a 以前で作成された普通のファイルコンテナーと、外付け HDD、USB メモリー、パーティションなどを丸ごと暗号化した既存データ資産である。特に GNU/Linux 上で、TrueCrypt 本体や古い VeraCrypt に依存せず、cryptsetup の TCRYPT 対応を使って読み出せるかを確認し、読めたデータを LUKS 側へ移す実務を中心に扱う。Windows システム暗号化、隠しボリューム、バックアップヘッダー、生のボリュームキー抽出などは必要に応じて触れるが、主線は既存データを失わずに保全することである。

この問題は、最終的には暗号の強さだけでは決まらない。十分に強いパスフレーズで守られている既存資産では、総当たり攻撃よりも、媒体劣化、鍵ファイル紛失、読み出し手順の喪失、ツール互換性の変化、デバイス指定ミス、移行漏れのほうが先に問題化しやすい。したがって、TrueCrypt 資産の扱いは、次の 3 段階に分けるべきである。第一に、現在の GNU/Linux で読み出せるか確認する。第二に、読めた資産について、ハッシュ値、鍵ファイル、パスフレーズ管理方針、コマンド、cryptsetup のバージョン、検証日を作業記録として残す。第三に、重要なデータから LUKS 側へ段階的に移し、TrueCrypt 側は読み取り専用アーカイブとして凍結する。この順序を取れば、移行困難な状況でも、読み出し不能になるリスクを下げられる。

2. TrueCrypt 7.1a とは何だったのか

TrueCrypt は、暗号化された領域を通常のストレージ領域のように扱うためのオンザフライ暗号化ソフトである。オンザフライ暗号化とは、利用者がファイルを開いたり保存したりするたびに、暗号化と復号を手作業で行う方式ではなく、マウントされた暗号化領域に対する読み書きの途中で、ソフトウェアが自動的に復号と再暗号化を行う方式である。利用者から見ると、暗号化されたファイルやデバイスをマウントすると、内部のファイルシステムが通常のドライブやディレクトリのように見える。しかし実際には、ディスク上に保存されているデータは暗号文のままであり、読み出し時に復号され、書き込み時に再び暗号化される。このため、TrueCrypt は「暗号化ファイルを作るツール」というより、「暗号化された仮想ブロックデバイスを作り、その上に通常のファイルシステムを載せるツール」と理解したほうが正確である。

TrueCrypt が扱えた対象は複数あった。代表的なのは、通常ファイルの内部に暗号化領域を作るファイルコンテナー、既存のパーティションや外付けディスク全体を暗号化領域として使う非システムデバイス暗号化、Windows の起動領域を含めて暗号化するシステム暗号化、外側ボリュームの未使用領域に別の暗号ボリュームを配置する隠しボリュームである。ファイルコンテナーは、ファイルシステム上では 1 個の大きな通常ファイルに見える。しかしマウント後には、そのファイルの内部が仮想ブロックデバイスとして扱われ、その上に FAT、NTFS、ext 系などのファイルシステムを置ける。デバイス丸ごと暗号化では、ファイルではなくパーティションや外付けディスクそのものが暗号化ボリュームになり、マウント後に復号済みのブロックデバイスとして扱われる。

この構造は、現在の GNU/Linux における LUKS とも共通する部分がある。どちらも、暗号化されたストレージ領域を復号済みのブロックデバイスとして見せ、その上に通常のファイルシステムを載せる。しかし、TrueCrypt と LUKS は同じものではない。LUKS は Linux の dm-crypt と組み合わされ、ディストリビューション標準の暗号化基盤として保守されている。一方、TrueCrypt は独自形式のヘッダー、独自のボリューム形式、独自の運用モデルを持つクロスプラットフォームな暗号化ソフトとして普及した。したがって、既存の TrueCrypt 資産を GNU/Linux で扱う場合も、それを LUKS と同じ形式として扱うのではなく、TCRYPT 形式のレガシー暗号ボリュームとして読み出す必要がある。

TrueCrypt 7.1a は、実質的に最後の完全版として扱われることが多い。後に TrueCrypt 7.2 が公開されたが、これは暗号化機能を継続するための通常リリースではなく、既存データの復号や他方式への移行を促す特殊な位置づけだった。つまり、TrueCrypt 7.2 は「TrueCrypt の正常な後継版」ではなく、プロジェクト終了時の移行用リリースとして理解するべきである。そのため、既存資産の保全を考える場合、実務上の対象は基本的に TrueCrypt 7.1a 以前で作成されたボリュームになる。

本稿で対象にするのは、普通の TrueCrypt 7.1a ファイルコンテナーと、外付け HDD、USB メモリー、パーティションなどを丸ごと暗号化した非システムデバイスである。これらは GNU/Linux 上で cryptsetup の TCRYPT 対応を使って読み出せる可能性がある。一方、Windows のシステム暗号化は、起動前認証、ブートローダー、Windows 固有のディスク構成が関係するため、単なるデータボリュームの保全とは分けて考える必要がある。また、隠しボリュームは cryptsetup で扱える場合があるが、外側ボリュームへの書き込みによって内部の隠し領域を破壊する可能性があるため、通常ボリュームと同じ感覚で扱うべきではない。

したがって、本稿では TrueCrypt の全機能を網羅的に再利用することを目的にしない。目的は、過去に作成された TrueCrypt 7.1a 資産を失わないために、GNU/Linux 上で安全に読み出し確認を行い、必要なデータを LUKS など現在保守されている暗号化基盤へ移せる状態を作ることである。TrueCrypt はすでに新規利用の対象ではなく、保全すべき既存資産の形式である。この前提を置くことで、暗号強度、監査結果、ライセンス、VeraCrypt 互換性、cryptsetup 手順の意味が整理しやすくなる。

3. TrueCrypt が問題化した理由

TrueCrypt が問題化した理由は、単純に暗号が弱かったからではない。むしろ、問題の中心は、暗号ソフトを信頼するために必要な条件が、TrueCrypt では複数の層で不安定だったことにある。暗号化ソフトの信頼性は、暗号アルゴリズムの強度だけで決まらない。どのような開発者が、どのような設計思想で、どのようなソースコードを公開し、どのようなビルド手順で、どのようなバイナリを配布し、脆弱性が見つかったときに誰が修正し、利用者がどの経路から安全な更新を受け取れるのかという、技術と制度と運用の全体で成立する。TrueCrypt の問題は、この全体構造が十分に透明でなかったにもかかわらず、実用上は広く信頼されていた点にあった。

TrueCrypt は、長い間、個人や組織が機密データを守るための有力な選択肢として使われていた。ファイルコンテナー、外付けディスク、非システムパーティション、Windows のシステム暗号化、隠しボリュームなどを扱え、Windows、macOS、Linux をまたいで利用できたためである。特に、暗号化されたファイルを通常のドライブのようにマウントできる使い勝手は、多くの利用者にとって実用的だった。しかし、この実用性の背後には、匿名開発者、独自ライセンス、再現性の弱いビルド手順、限定的な開発透明性、公式配布物への強い依存という課題が残っていた。利用者は、暗号の数学的強度だけでなく、配布された実行ファイルが本当に公開ソースから作られたものなのか、更新が信頼できるのか、保守が継続されるのかという問題も抱えていた。

この不安が決定的に表面化したのが 2014 年の突然の開発終了である。TrueCrypt の公式サイトは、TrueCrypt の使用は安全でない可能性があり、開発は終了したという趣旨の警告を掲げ、利用者に他の暗号化手段への移行を促した。この告知は、通常のソフトウェア終了告知とは性質が異なっていた。どの脆弱性が理由なのか、どの範囲が危険なのか、既存ボリュームが直ちに危険なのか、単に保守を終了するという意味なのかが明確に説明されなかったためである。その結果、利用者の側には「TrueCrypt で作成済みの暗号化データは安全なのか」「すぐ移行しなければならないのか」「公式サイト自体が改ざんされたのではないか」「外部圧力があったのではないか」という複数の疑念が残った。

ここで重要なのは、突然の終了が、そのまま暗号破綻を意味するわけではないことである。暗号ソフトの安全性は、少なくとも、暗号アルゴリズム、暗号利用モード、鍵導出関数、乱数生成、ヘッダー形式、実装品質、ビルド手順、署名と配布経路、保守体制、利用者の運用手順に分解して評価しなければならない。TrueCrypt の開発終了によって失われたのは、主に保守体制、将来の修正可能性、正統な配布経路、公式の説明責任である。一方で、過去に作成されたボリュームの暗号方式や鍵導出が、その瞬間に自動的に無効になったわけではない。この区別をしないと、「TrueCrypt は安全ではないからすべて捨てるべきだ」という過剰反応と、「監査で致命的問題が見つからなかったから使い続けてよい」という過小評価の両方に陥る。

TrueCrypt の本質的な課題は、暗号の数学的強度と、ソフトウェア供給網としての信頼性が分離していたことである。AES、Serpent、Twofish のような暗号アルゴリズム自体が十分に強くても、その実装が正しいとは限らない。実装が正しくても、乱数生成や鍵導出が適切でなければ弱くなる。ソースコードが公開されていても、配布されるバイナリがそのソースから再現可能に作られていなければ、利用者は実際に何を実行しているのか確認しにくい。さらに、脆弱性が見つかったときに修正されなければ、時間の経過とともに安全余裕は削られる。TrueCrypt は、このような暗号ソフト特有の信頼連鎖を、十分に制度化しないまま広く使われていた。

匿名開発者であったことも、単に「怪しい」という感情的な問題ではない。匿名性そのものは、必ずしもソフトウェアの品質を否定しない。匿名の開発、仮名の開発、組織に属さない開発でも、優れたソフトウェアは存在する。しかし、暗号ソフトの場合、匿名性は責任主体、継続保守、脆弱性対応、法的・制度的圧力への耐性、終了時の説明責任に影響する。開発者の身元が不明であれば、開発終了の理由、配布物の真正性、署名鍵の管理、後継プロジェクトの正統性を外部から検証しにくい。TrueCrypt の終了が大きな混乱を生んだのは、まさにこの責任主体の不透明さが、暗号化済みデータという高価値資産の運用と結びついていたためである。

独自ライセンスの問題も、暗号強度そのものとは別の層にある。TrueCrypt のライセンスは、一般的な自由ソフトウェアライセンスとして扱いやすいものではなく、主要な GNU/Linux ディストリビューションが標準パッケージとして長期的に取り込み、監査し、修正し、再配布するには扱いづらい性質を持っていた。これは、既存ボリュームの暗号が直ちに破られるという問題ではない。しかし、暗号化ソフトを長期運用する場合、配布と保守の制度的な安定性は重要である。LUKS と cryptsetup が GNU/Linux の標準的な暗号化基盤として扱われるのに対し、TrueCrypt はプロジェクト単体への依存が大きく、終了後にその弱さが露出した。

配布物の信頼性も重要だった。暗号ソフトでは、ソースコードが公開されているだけでは十分ではない。利用者が実際に実行するのは、多くの場合、配布されたバイナリである。そのバイナリが公開ソースから作られたものか、ビルド環境に不正がないか、古いコンパイラーや外部ライブラリーに問題がないか、配布サイトが改ざんされていないかという点まで含めて確認できなければならない。TrueCrypt 監査で deterministic build やビルド環境が論点になったのは、このためである。暗号ソフトでは、コードの安全性と配布物の真正性は切り離せない。

このように見ると、TrueCrypt の問題化は、単なるソフトウェア終了ではなく、暗号化資産の保全に必要な条件を利用者に突きつけた出来事だったといえる。暗号化済みデータは、作成時に安全であれば終わりではない。将来も復号できること、復号手順が残っていること、対応ツールが入手できること、媒体が読めること、鍵ファイルとパスフレーズが失われていないこと、必要に応じてより新しい形式へ移行できることが必要である。TrueCrypt の終了は、暗号化とは「データを読めなくする技術」であると同時に、「必要なときに正しく読める状態を維持する運用」でもあることを示した。

したがって、現在の実務判断では、TrueCrypt を危険物として単純に扱うのではなく、保守停止済みのレガシー暗号資産として扱うのが正確である。監査結果は、過去に作成された TrueCrypt 7.1a 資産が直ちに破綻しているわけではないことを示す材料になる。一方で、匿名開発、独自ライセンス、突然の終了、保守主体の不在、配布経路の不透明性は、新規利用を避ける十分な理由になる。この二つを同時に認めることが重要である。つまり、既存資産は保全し、読み出し手順を確保し、可能なものから LUKS へ移行する。しかし、TrueCrypt を新しい暗号化基盤として使い続けるべきではない。この判断こそが、TrueCrypt 問題の本質である。

4. ライセンス問題は暗号破綻ではなく保守継続性の問題である

TrueCrypt のライセンス問題は、暗号アルゴリズムの強度とは別の層にある。AES、Serpent、Twofish のような暗号方式が十分に強いかどうかと、TrueCrypt のソースコードや派生物をどのような条件で再配布、改変、保守できるかは、直接には別の問題である。しかし、暗号ソフトを長期運用する場合、この二つは完全には切り離せない。なぜなら、暗号化データの安全性は、作成時点の暗号強度だけでなく、将来も対応ソフトが入手でき、脆弱性が修正され、OS の変化に追従し、利用者が安全な実装を使い続けられることによって維持されるからである。

TrueCrypt のライセンスは、一般的な GPL、BSD、Apache License のような標準的な自由ソフトウェアライセンスではない。TrueCrypt License Version 3.0 は、利用、複製、改変、再配布に独自条件への同意を求め、ソフトウェアを無保証で提供することを明記している[5]。TrueCrypt のソースコード配布ページも同じライセンス条件を示しており、ソースコードが読めることと、自由ソフトウェアとして標準的に再配布、修正、保守しやすいことは別問題である[6]。

ここで本質的なのは、「ソースがあるなら誰かが引き継げる」という単純な理解が成り立たないことである。ソースコードが公開されていても、ライセンスが曖昧だったり、標準的な自由ソフトウェアライセンスとして扱いにくかったりすれば、ディストリビューションは標準パッケージとして組み込みにくくなる。組み込みにくければ、セキュリティ修正、依存ライブラリーの更新、ビルド環境の変更、署名、配布、監査、バグ報告、保守体制の継承が弱くなる。暗号ソフトでは、この弱さは単なる配布上の不便ではなく、利用者が将来もデータを安全に読み出せるかどうかに関わる。

GNU/Linux の長期運用では、この差は大きい。LUKS と cryptsetup は、Linux の標準的な暗号化基盤としてディストリビューションに統合され、パッケージ管理、セキュリティアップデート、マニュアル、テスト、カーネルとの互換性維持の流れに乗っている。利用者は、個別の暗号化ソフトを手動で探し、古いバイナリを保管し、実行環境を固定しなくても、ディストリビューションの標準機能として暗号化領域を扱える。一方、TrueCrypt は独自プロジェクトとして広く使われたが、ライセンスと開発体制の制約により、同じ意味での標準基盤にはなりにくかった。

この問題は、既存データを復号するだけなら直ちに致命傷ではない。手元に既存ボリュームがあり、正しいパスフレーズがあり、鍵ファイルがあり、読み出しツールがあるなら、TrueCrypt のライセンス問題によってデータがその場で読めなくなるわけではない。つまり、ライセンス問題は、暗号化済みデータの即時破綻を意味しない。しかし、長期保全の観点では無視できない。読み出しツールが配布されなくなり、古いバイナリが現在の OS で動かなくなり、脆弱性が見つかっても修正されず、正統な後継実装が確立しなければ、データが暗号的に破られなくても、実務上は読みにくくなる。

暗号資産の保全では、「攻撃者に読まれないこと」と「正当な利用者が将来も読めること」の両方が必要である。ライセンス問題は、主に後者に関わる。暗号化は、情報を読めなくするための技術である。しかし、保全対象として見るなら、必要なときに正しく読める状態を維持する技術でもある。TrueCrypt の独自ライセンスは、既存ボリュームの暗号強度を直接下げるものではないが、将来の読み出し環境、保守主体、再配布、フォーク、検証可能性を弱くする。ここに、この問題の本質がある。

また、ライセンスはフォークの正統性にも影響する。あるソフトウェアが保守停止した場合、標準的な自由ソフトウェアライセンスであれば、共同体や企業やディストリビューションが引き継ぎ、修正し、再配布し、保守を続ける道筋を作りやすい。しかし、ライセンスが扱いづらい場合、派生プロジェクトは法的・制度的な不確実性を抱える。暗号ソフトでは、この不確実性がそのまま利用者の判断負荷になる。どの派生版を信頼するのか、どの実装が正統なのか、どの配布物が安全なのか、どのバージョンで既存ボリュームを開くべきなのかを、利用者自身が判断しなければならなくなる。

したがって、TrueCrypt のライセンス問題は、「ライセンスが好ましくないから既存データは危険である」という話ではない。より正確には、「既存データを読むことはできるが、その形式を長期的な主系として維持する制度的条件が弱い」という話である。ここを取り違えると、判断を誤る。既存 TrueCrypt 資産を直ちに廃棄する必要はない。一方で、今後も TrueCrypt 形式で新規資産を増やし続けるべきでもない。既存資産は読み出し手順を確保し、重要データから LUKS へ移し、移行困難なものはレガシー暗号資産として凍結保管するのが妥当である。

5. 監査は何を調べ、何を調べなかったのか

TrueCrypt の監査を読むときに最初に確認すべきなのは、監査が「TrueCrypt は安全である」と一括して証明したものではないという点である。監査とは、対象範囲、期間、予算、脅威モデル、手法を定め、その範囲内で実装や設計を調べる作業である。したがって、監査結果は常に「何を見たのか」「何を見なかったのか」「どの攻撃者を想定したのか」「どの利用形態を想定したのか」とセットで読まなければならない。TrueCrypt の場合も、Phase I と Phase II は役割が異なる。Phase I は主に低レイヤー実装のソースコード監査であり、Phase II は暗号実装と保存状態の暗号データ保護に焦点を当てた暗号レビューである。

Open Crypto Audit Project が重要だったのは、匿名開発者による保守停止済みソフトを、外部の専門家が独立に調べる枠組みを作った点である。TrueCrypt は広く使われていたにもかかわらず、開発主体、配布物、ビルド手順、ライセンス、将来保守に不透明さを抱えていた。利用者にとって問題だったのは、暗号アルゴリズム名だけを見ても判断できないことである。AES、Serpent、Twofish といった強い暗号方式を使っていても、実装、乱数生成、鍵導出、ヘッダー処理、カーネルドライバー、ブートローダー、配布バイナリ、ビルド環境に問題があれば、実際の安全性は下がる。監査は、このような「暗号名だけでは分からない部分」を分解して確認するために行われた。

Phase I は iSEC Partners、後の NCC Group によるソースコード監査であり、主に Windows カーネルコード、ブートローダー、ファイルシステムドライバー、および周辺コードを対象にした[7]。これは、TrueCrypt の利用者が直接意識しにくいが、実装上の危険度が高い領域である。ディスク暗号化ソフトは、単なるアプリケーションではなく、OS のストレージ層、カーネル、ブート過程、ファイルシステムと結びつく。低レイヤーの実装に問題があれば、権限昇格、情報漏洩、メモリー破壊、ブート処理の改ざん、ファイルシステム処理の不整合などにつながりうる。Phase I は、こうした危険領域を優先して確認した監査であり、TrueCrypt 全機能の完全な数学的証明ではない。

Bruce Schneier も当時、Phase I はソースコード監査であり、次の段階が形式的な暗号解析になると整理している[8]。この整理は重要である。ソースコード監査は、バッファー処理、ポインター処理、カーネルインターフェイス、ドライバー実装、入力検証、権限境界などを確認する。一方、暗号解析や暗号実装レビューは、鍵導出、乱数生成、暗号モード、ヘッダー構造、認証、サイドチャネル耐性、鍵ファイル処理などを見る。両者は重なる部分もあるが、同じ作業ではない。したがって、Phase I の結果だけで「暗号設計まで完全に問題ない」とは言えず、Phase II の結果だけで「OS 統合や低レイヤー実装まで完全に問題ない」とも言えない。

Phase II は、TrueCrypt 7.1a を対象に、暗号実装、乱数生成、鍵導出、暗号スイート、ボリュームヘッダー処理などを調べる監査として再始動した。Matthew Green は、TrueCrypt 7.1a が後継フォークの基準になるため、これを評価する意義があると述べている[9]。NCC Group Cryptography Services も、Phase II では iSEC による Phase I に続いて暗号部分を扱うと説明した[10]。この段階で想定された中心的な脅威モデルは、攻撃者が TrueCrypt で暗号化されたノート PC、外付けディスク、ファイルコンテナーなどを入手し、その保存状態の暗号データから平文を回復できるかどうかである。つまり Phase II は、利用中のマルウェア感染やキーロガー、マウント後の平文漏洩、利用者のパスフレーズ管理失敗を主対象にしたものではなく、暗号化されたボリュームそのものが静的にどれほど堅いかを見る監査だった。

この二段階構成を理解しないと、監査結果の読み方を誤る。Phase I で重大なバックドアが見つからなかったからといって、暗号実装の細部まで完全に検証されたわけではない。Phase II で暗号実装上の問題が見つかったからといって、通常利用のすべてが破綻したわけでもない。監査結果は、対象範囲、時点、脅威モデル、発見事項、未検証領域を分けて読む必要がある。とくに既存 TrueCrypt 資産の保全では、「攻撃者に読まれるか」という機密性の問題だけでなく、「正当な利用者が将来も読めるか」という復元可能性の問題がある。監査は前者に重要な材料を与えるが、後者を自動的に保証するものではない。

さらに、監査は時間にも制約される。2014 年から 2015 年時点で確認されなかった問題が、将来も存在しないことを意味しない。CPU、OS、コンパイラー、攻撃技術、サイドチャネル研究、仮想化環境、パッケージング、配布経路は変化する。TrueCrypt は保守停止済みであるため、監査後に見つかった問題が公式に修正され続ける構造を持たない。したがって、監査結果は「既存ボリュームを即時に廃棄しなくてよい理由」にはなるが、「今後も TrueCrypt を主系として使い続けてよい理由」にはならない。ここが、監査結果を実務判断に接続する際の本質である。

6. Phase I 監査の結果

Phase I 監査の結論は、TrueCrypt が 2014 年時点で「明白なバックドア入りソフトだったのか」という疑念を評価するうえで重要である。iSEC は、監査対象範囲において high severity と評価される問題を確認せず、バックドアや意図的な欠陥の証拠も見つけなかった。一方で、kernel pointer disclosure など、いくつかの弱点や典型的なカーネル系の問題は確認された。ただし、それらは直ちに悪用可能な exploit vector を示すものではなく、発見事項は意図的ではなく偶発的なものに見えたと整理された[7]。

この結果の意味は、慎重に読む必要がある。第一に、Phase I は TrueCrypt に対する強い疑念を一定程度弱めた。匿名開発者、突然の終了、公式サイトの警告によって、TrueCrypt には「意図的なバックドアがあるのではないか」という不安が生じていた。その状況で、低レイヤー実装を対象にした独立監査が、少なくとも high severity 問題や意図的欠陥の証拠を見つけなかったことは大きい。これは、過去に作成された TrueCrypt 資産を直ちに廃棄しなければならないという判断を弱める材料になる。

第二に、Phase I は TrueCrypt の全体安全性を証明したわけではない。対象は主に Windows 側のカーネルコード、ブートローダー、ファイルシステムドライバー、および周辺コードである。GNU/Linux 上で既存 TrueCrypt 7.1a 資産を cryptsetup から読み出すという本稿の主題に対しては、低レイヤー Windows 実装の評価がそのまま直接適用されるわけではない。たとえば Windows のシステム暗号化やブートローダーに関する評価は、Linux 上でファイルコンテナーを読み出す場面とは異なる。一方で、TrueCrypt プロジェクト全体に意図的な欠陥が埋め込まれていたかという疑念を評価する材料としては意味がある。

第三に、kernel pointer disclosure のような発見事項は、暗号そのものの破綻とは違う。kernel pointer disclosure は、カーネル内部のアドレス情報が外部に漏れる種類の問題であり、ASLR などの防御機構を弱める可能性がある。これは望ましくないが、単独で暗号化済みボリュームの平文が直ちに復元されることを意味しない。低レイヤー実装では、このような情報漏洩や境界処理の問題が別の脆弱性と組み合わさることで攻撃面を広げる場合がある。Phase I の読み方として重要なのは、「問題が何もなかった」のではなく、「発見された問題は重大な即時悪用経路や意図的バックドアを示すものではなかった」という点である。

第四に、Phase I は暗号ソフトにおける低レイヤー実装の難しさを示している。ディスク暗号化ソフトは、暗号ライブラリーを呼び出すだけのアプリケーションではない。ボリュームをブロックデバイスとして見せ、ファイルシステムと接続し、OS の I/O 経路に入り、場合によってはブート前認証やドライバー処理に関与する。このようなソフトでは、暗号アルゴリズムが強くても、カーネルインターフェイスやドライバー境界に問題があれば、別種のリスクが生じる。Phase I は、TrueCrypt の問題を暗号名だけでなく、OS 統合の問題として見る必要があることを示した。

既存資産保全という観点では、Phase I の結論は「過去の TrueCrypt 7.1a 資産を恐怖だけで捨てる必要はない」という方向に働く。しかし同時に、「TrueCrypt を今後も主系として使い続けてよい」という結論にはならない。監査対象は限定され、保守は停止しており、発見された弱点を公式に改善し続ける主体もない。したがって、Phase I の結果は、既存資産を冷静に保全するための材料であり、新規利用を正当化する材料ではない。

7. Phase II 監査の結果

Phase II 監査は、TrueCrypt 7.1a の暗号実装により深く踏み込んだ。Phase I が主に低レイヤー実装を見たのに対し、Phase II は暗号化済みボリュームが保存状態でどれほど安全に保護されているかを評価する性格が強い。対象になったのは、暗号実装、乱数生成、鍵導出、暗号スイート、ボリュームヘッダー処理、鍵ファイル処理、サイドチャネル耐性などである。これは、攻撃者が TrueCrypt で暗号化されたノート PC、外付けディスク、ファイルコンテナーを入手したとき、パスフレーズなしに平文を回復できるような設計上または実装上の欠陥があるかを見る監査である。

最終報告書では、意図的なバックドアや通常利用を全面的に破壊するような重大設計欠陥は確認されなかった一方で、4 つの主要な発見事項が示された[11]。SecurityWeek も、監査では 2 件の high severity、1 件の low severity、1 件の undetermined severity が示されたが、一般的な利用シナリオで機密性を完全に迂回するものではなかったと整理している[12]。この結果は、単純な「安全」でも「危険」でもない。TrueCrypt 7.1a は、当時の暗号ソフトとして比較的よく設計されていたが、暗号実装として改善すべき問題を持っていた、という読み方が正確である。

4 つの発見事項は、第一に keyfile mixing が暗号学的に健全ではないこと、第二にボリュームヘッダー内の暗号文が十分に認証されていないこと、第三に Windows API の CryptAcquireContext が特殊状況で静かに失敗しうること、第四に AES 実装が cache timing attack に弱い可能性があることである。Schneier の紹介でも、乱数生成、ヘッダー改ざん検出、鍵ファイル混合、AES のキャッシュタイミング耐性が主な懸念として挙げられている[13]。これらは、それぞれ影響する場面が異なる。新規ボリューム作成時に重い問題、鍵ファイル利用時に効く問題、ローカル実行環境に攻撃者が近い場合に効く問題、媒体改ざん検出に関わる問題を分けなければならない。

CryptAcquireContext の問題は、Windows 上での乱数生成に関係する。暗号化ボリュームを新規作成するとき、暗号鍵や関連する乱数が十分に強くなければ、後からどれほど強い暗号アルゴリズムを使っても安全性は落ちる。Phase II で high severity とされた理由は、特殊な状況で Windows API が静かに失敗し、TrueCrypt 側がそれを適切に扱えない可能性があるためである。ただし、本稿の前提は GNU/Linux 上で既存 TrueCrypt 7.1a 資産を読み出すことであり、Windows 上で新規ボリュームを作成することではない。このため、既存ボリュームの読み出しにおいては、CryptAcquireContext 問題は直接の主リスクではなく、過去に Windows 上でボリュームを作成した時点の品質に関わる問題として扱うべきである。

AES cache timing の問題は、暗号実装が CPU キャッシュの動作を通じて情報を漏らす可能性に関わる。暗号アルゴリズムとしての AES が破られたという意味ではない。問題は、ソフトウェア実装がテーブル参照などを使う場合、処理時間やキャッシュ状態から鍵に関する情報が推測される可能性があることである。この攻撃は、攻撃者が実行環境に近い位置にいる場合、たとえば同一マシン上でコードを実行できる場合や、仮想化環境で隣接する場合に現実味を持つ。したがって、既存資産を保全目的で読み出す場合、信頼できない常用デスクトップや共有環境でマウントするより、ネットワークから切り離した信頼できる環境で読み出すほうがよい。

Keyfile mixing の問題は、鍵ファイルを使えば単純に強くなるという理解に注意を促す。TrueCrypt はパスフレーズに加えて鍵ファイルを利用できるが、その混合方法が暗号学的に健全ではないと指摘された。これは、強いランダムパスフレーズを使っている既存ボリュームに対して直ちに致命的であるという話ではない。しかし、弱いパスフレーズを鍵ファイルで補っている設計では、鍵ファイル利用を過信できない。既存資産保全では、鍵ファイルを使っているかどうか、鍵ファイルが失われていないか、鍵ファイルをどうバックアップするかを明確にする必要がある。

Unauthenticated ciphertext in volume headers は、ボリュームヘッダー内の暗号文に対する認証の弱さに関係する。これは、攻撃者がヘッダーを改ざんした場合に、その改ざんを明確に検出できる構造になっているかという問題である。ヘッダーは、暗号ボリュームの復号に必要な重要情報を含むため、破損や改ざんは読み出し不能につながりうる。既存資産保全では、この発見事項は、コンテナーやデバイスイメージのハッシュ値を記録し、複数媒体へ複製し、読み出し確認を定期的に行う必要性を高める。つまり、これは単に攻撃者対策ではなく、媒体劣化や誤操作による破損を早期に検出する運用上の問題でもある。

Phase II の結果から言えることは、TrueCrypt 7.1a は完全ではないが、一般的な保存データ保護の用途で直ちに全面破綻しているとは評価されなかったということである。強いパスフレーズで作成された通常ボリュームを、信頼できる環境で読み出すという用途では、監査結果は過度な恐怖を支持しない。一方で、弱いパスフレーズ、鍵ファイル依存、Windows 上での新規作成、信頼できない実行環境、共有マシン、長期保守の不在を軽視してよいわけでもない。したがって、既存資産保全では、暗号解読の恐怖よりも、読み出し環境、媒体劣化、手順喪失、誤った書き込み、鍵ファイル紛失を現実的なリスクとして管理すべきである。

8. 監査結果から言えることと言えないこと

TrueCrypt 監査の結果から言えることは、TrueCrypt 7.1a が「明白なバックドア入りソフト」だったとは確認されなかった、ということである。Phase I では、主に Windows カーネルコード、ブートローダー、ファイルシステムドライバー、および周辺コードが確認され、監査対象範囲では high severity の問題や意図的なバックドアの証拠は見つからなかった。Phase II では、暗号実装、乱数生成、鍵導出、鍵ファイル処理、ボリュームヘッダー、AES 実装などが確認され、複数の弱点は指摘されたが、通常利用を全面的に破壊するような重大設計欠陥や意図的なバックドアは確認されなかった。したがって、監査結果は、過去に作成された TrueCrypt 7.1a 資産を即時に危険物として廃棄すべきだという判断を支持しない。

ただし、監査結果が示しているのは、「調査された範囲で重大な意図的欠陥や全面的な暗号破綻が確認されなかった」ということであり、「TrueCrypt は完全に安全である」ということではない。Phase I は低レイヤー実装を中心にした監査であり、暗号実装の詳細は Phase II の対象だった。Phase II は暗号実装に踏み込んだが、それでも監査は特定時点、特定範囲、特定の脅威モデルに基づく評価である。監査は、将来発見される脆弱性、OS 互換性問題、配布物の信頼性、古い実行環境の維持、媒体劣化、利用者の操作ミスまで保証するものではない。

この区別は重要である。TrueCrypt をめぐる判断は、「安全だったのか、危険だったのか」という二択では整理できない。監査結果は、TrueCrypt 7.1a が直ちに全面破綻しているわけではないことを示す。一方で、TrueCrypt が保守停止済みであり、ライセンス上も標準的な自由ソフトウェア基盤に乗りにくく、開発主体も不透明であり、将来の修正や正統な継続保守を期待できないことも事実である。つまり、監査結果は既存資産を冷静に扱う根拠にはなるが、TrueCrypt を今後も主系の暗号化基盤として使い続ける根拠にはならない。

既存資産保全の観点では、監査結果の意味はさらに限定して読むべきである。十分に強いパスフレーズで作成された通常ボリュームを、信頼できる環境で読み出す場合、監査結果は「暗号解読を過度に恐れて即時破棄する必要はない」という方向に働く。しかし、弱いパスフレーズ、鍵ファイル紛失、ヘッダー破損、媒体劣化、古いツールへの依存、誤ったデバイス指定、外側ボリュームへの不用意な書き込み、隠しボリューム破壊といった運用リスクは、監査によって消えない。暗号が破られなくても、正当な利用者が将来読めなくなれば、保全には失敗している。

したがって、現在の実務判断は明確である。TrueCrypt 資産は、直ちに破棄すべき危険物ではなく、保守停止済みのレガシー暗号資産として扱うべきである。新規作成や常用には使わず、GNU/Linux では cryptsetup の TCRYPT 対応などで読み出し可能性を確認し、コンテナーやデバイスイメージのハッシュ値、鍵ファイル、パスフレーズ管理、マウント手順、cryptsetup のバージョン、検証日を記録する。そのうえで、重要データから LUKS へ段階的に移行し、移行困難なものは読み取り専用アーカイブとして凍結保管する。この判断が、監査結果から導ける最も現実的な結論である。

9. 十分に強いパスフレーズでは総当たりより運用リスクが大きい

既存 TrueCrypt 資産が、十分な長さを持つランダムな英数記号列で保護されている場合、現実的なリスクはパスフレーズ総当たりよりも運用側へ移る。ここでいう十分に強いパスフレーズとは、辞書語、個人情報、生年月日、語句の単純な組み合わせ、過去に使い回したパスワードではなく、乱数によって生成された長い文字列を指す。たとえば、20 文字以上を目安とするランダムな英数記号列であれば、人間が覚えやすい短いパスワードとはまったく異なる探索空間を持つ。もちろん、これは「絶対に破られない」という意味ではない。しかし、攻撃者が暗号化済みボリュームだけを入手し、オフラインで総当たりする状況では、弱い記憶用パスワードと十分に長いランダム文字列では、リスクの性質が大きく異なる。

この前提では、TrueCrypt 資産の主なリスクは、暗号そのものの即時破綻よりも、復元可能性の喪失に寄る。つまり、コンテナーやデバイスが壊れる、バックアップ媒体が劣化する、鍵ファイルの有無を忘れる、隠しボリュームの存在を忘れる、読み出しに必要なコマンドを忘れる、cryptsetup の挙動を検証していない、将来の GNU/Linux 環境で開けなくなる、外側ボリュームへ不用意に書き込んで隠し領域を破壊する、といった問題である。十分に強いパスフレーズは、攻撃者に対する防御としては重要である。しかし、正当な利用者が将来も読めることを保証するものではない。

暗号化資産の長期保全では、「攻撃者に読まれないこと」と「自分が将来も読めること」を同時に満たす必要がある。強いパスフレーズは前者には有効だが、後者には直接効かない。後者を満たすには、コンテナーやデバイスイメージのハッシュ値、鍵ファイルの有無、マウント手順、cryptsetup のバージョン、検証日、読み出しに成功した環境、ファイルシステム種別、保管媒体の所在を記録する必要がある。暗号が破られていなくても、手順と媒体と鍵情報が失われれば、実務上はデータを失ったのと同じである。

したがって、十分に強いパスフレーズで守られた既存 TrueCrypt 資産については、総当たり攻撃だけを過度に恐れるよりも、読み出し環境を確認し、保全手順を固定し、重要データから LUKS へ移すことを優先すべきである。一方、短い記憶用パスワード、辞書語、個人情報ベースの文字列、使い回しパスワードで守られた古いボリュームは、同じ TrueCrypt 資産でもリスクが大きく異なる。その場合は、読めるうちに優先的に復号し、現在保守されている暗号化基盤へ移すべきである。

10. 今後破られる可能性をどう見るか

TrueCrypt 資産が今後破られる可能性を考えるときは、「暗号が破られる」という言葉を分解する必要がある。暗号化済みデータが読まれる経路は 1 つではない。AES、Serpent、Twofish のような暗号アルゴリズムそのものが破られる場合もあれば、XTS のような利用モードの性質によって改ざん検出が不十分になる場合もある。PBKDF2 のような鍵導出関数が現在の計算資源に対して相対的に古くなる場合もある。実装がキャッシュタイミング攻撃のようなサイドチャネルを持つ場合もある。さらに、最も現実的には、弱いパスフレーズ、鍵ファイル紛失、媒体劣化、読み出し環境の消滅、誤ったデバイス指定、マウント後の平文漏洩といった運用上の失敗によって、暗号の強度とは別の形でデータ保全に失敗する場合がある。

まず事実として、AES は NIST の FIPS 197 として標準化された対称ブロック暗号であり、現在でも広く使われている[14]。この事実から言えるのは、AES という暗号アルゴリズム名だけを見て、既存 TrueCrypt 資産が直ちに危険であるとは言えないということである。一方で、AES が標準暗号であることは、TrueCrypt の実装、鍵導出、ヘッダー処理、パスフレーズ管理、読み出し環境まで安全であることを意味しない。暗号アルゴリズムの強度は重要な土台だが、暗号化ソフト全体の安全性は、その土台の上にある実装と運用によって決まる。

ストレージ暗号化では、暗号アルゴリズムだけでなく利用モードも重要である。NIST SP 800-38E は XTS-AES をストレージデバイスの機密性保護用の選択肢として承認している。ただし、同時に、XTS-AES はデータやデータの発信元を認証しないことも明記している[15]。ここから言える事実は、XTS 系のディスク暗号化は主に機密性を守る仕組みであり、完全な改ざん検出や完全性保証の仕組みではないということである。したがって、既存 TrueCrypt 資産を保全する場合、攻撃者に読まれないことだけでなく、ボリュームやデバイスイメージが破損・改ざんされていないことを別途確認する必要がある。ハッシュ値の記録、複数媒体への複製、読み出し確認は、この観点から重要になる。

鍵導出については、PBKDF2 が PKCS #5 v2.1 として RFC 8018 に整理されている[16]。PBKDF2 は標準化された鍵導出関数であり、TrueCrypt が使っていたこと自体が即座に危険というわけではない。しかし、PBKDF2 は現代のパスワードハッシュやディスク暗号化で重視されるメモリーハード性を持たない。LUKS2 で利用される Argon2 系 KDF と比べると、GPU や専用計算資源に対する抵抗の設計思想は古い。ここから言える事実は、TrueCrypt 時代の PBKDF2 設定は、現在の最良の鍵導出設計とは言いにくいということである。

ただし、ここでリスクの大きさはパスフレーズの性質によって大きく変わる。短い記憶用パスワード、辞書語、個人情報、過去に使い回した文字列で保護されたボリュームでは、PBKDF2 の古さは現実的なリスクになりやすい。攻撃者が暗号化済みボリュームを入手し、オフラインで大量試行できるためである。一方、十分な長さを持つランダムな英数記号列で保護されている場合、探索空間そのものが大きくなるため、PBKDF2 の古さはリスクを増やす要素ではあるものの、短いパスワードの場合ほど決定的ではない。ここは事実と推測を分ける必要がある。事実として、PBKDF2 は現代的なメモリーハード KDF より古い。推測として、十分に強いランダムパスフレーズを使っている既存資産では、短期から中期の主リスクは総当たりよりも運用側に寄る可能性が高い。

実装リスクとしては、キャッシュタイミング攻撃を無視できない。Bernstein は AES 実装に対する cache-timing attack を示しており、これは AES というアルゴリズムそのものではなく、実装がメモリーアクセスや CPU キャッシュ状態を通じて情報を漏らす問題である[17]。TrueCrypt Phase II で AES 実装のキャッシュタイミング耐性が問題視されたのも、この文脈に属する。ここでの事実は、暗号アルゴリズムが強くても、実装がサイドチャネルを持つと鍵情報が漏れる可能性があるということである。一方、既存資産を信頼できるオフライン GNU/Linux 環境で短時間読み出すだけであれば、攻撃者が同一マシン上で精密なサイドチャネル攻撃を実行できる状況を避けやすい。このため、実務上の優先度は、共有環境、常時マウント、仮想化環境、マルウェア感染環境での利用を避けることにある。

量子計算については、過大評価しないほうがよい。Grover 型の探索高速化は、対称鍵探索に理論的な影響を与える。しかし、これは対称鍵暗号が突然無意味になるという話ではない。探索空間に対して平方根的な高速化があるとしても、十分な鍵長を持つ対称暗号が直ちに現実的に崩れるという結論にはならない。ここでの事実は、量子計算が対称鍵探索に理論的影響を持つことである。一方、推測として、既存 TrueCrypt 資産の実務リスクでは、量子計算よりも、媒体劣化、パスフレーズ喪失、鍵ファイル喪失、読み出しツールの消滅、手順喪失、誤操作のほうが先に問題化する可能性が高い。

もう 1 つ重要なのは、「破られる」という言葉には、暗号解読以外の経路が含まれることである。暗号化済みボリュームをオフラインで総当たりされるリスクと、マウント後の平文をマルウェアに読まれるリスクは別である。TrueCrypt コンテナーを復号してマウントした瞬間、その内部のファイルは通常のファイルシステムとして読める状態になる。したがって、実行環境が侵害されていれば、暗号が破られなくてもデータは漏洩する。この点は、監査結果や暗号アルゴリズムの強度とは別の問題である。既存資産の読み出しは、日常利用している汚染リスクのある環境ではなく、できるだけ信頼できる環境で、必要な時間だけ、読み取り専用を基本に行うべきである。

以上を踏まえると、既存 TrueCrypt 資産の今後のリスクは、単一の年数で断定すべきではない。暗号アルゴリズムそのものが近い将来に突然破られる可能性は高くないと見るのが合理的である。十分に強いランダムパスフレーズを使っている場合、オフライン総当たりが最初の主リスクになる可能性も低い。一方、TrueCrypt は保守停止済みであり、PBKDF2 設定は古く、実装上の弱点も指摘されており、VeraCrypt の TrueCrypt Mode も削除されている。したがって、現実的な結論は、今すぐ恐怖で廃棄することではなく、読めるうちに cryptsetup で読み出し確認を行い、ハッシュ値、手順、ツールバージョン、検証日を記録し、重要データから LUKS へ移すことである。

11. VeraCrypt は永続的な TrueCrypt 救済策ではない

TrueCrypt 終了後、VeraCrypt は有力な後継系として使われてきた。VeraCrypt は TrueCrypt のコードと設計を出発点にしつつ、鍵導出の反復回数増加、脆弱性修正、対応 OS の維持、機能追加を行ってきたため、TrueCrypt の利用者にとって自然な移行先に見えた。実際、一定期間の VeraCrypt は TrueCrypt Mode を備えており、TrueCrypt 6.x / 7.x の通常ボリュームや隠しボリュームを開けた[18]。そのため、TrueCrypt 資産は VeraCrypt で読めばよい、という理解が広がった。この理解は、ある時期までは実務上かなり有効だった。

しかし、ここで区別すべきことがある。VeraCrypt は TrueCrypt 資産を救済するための互換ツールとしてだけ存在しているわけではない。VeraCrypt 自身は、現在も保守される独立した暗号化ソフトであり、TrueCrypt 形式を永久に維持することよりも、VeraCrypt 形式としての安全性、保守性、実装の整理を優先する。したがって、VeraCrypt が一時期 TrueCrypt Mode を持っていたことは、TrueCrypt 資産の長期可読性が VeraCrypt によって永続的に保証されることを意味しない。後継プロジェクトであることと、旧形式を永久に読み出せることは別問題である。

この点が明確になったのが、VeraCrypt 1.26 以降における TrueCrypt Mode の削除である。VeraCrypt のドキュメントは、Version 1.26 以降で TrueCrypt Mode が削除されたことを明記している[19]。GitHub のリリース情報でも、TrueCrypt Mode support の削除と、TrueCrypt ボリュームのマウントや変換には 1.25.9 を使う必要があることが示されている[20]。つまり、現在の VeraCrypt 最新版を入れておけば TrueCrypt 資産をいつでも読める、という状態ではすでにない。

この変更は、VeraCrypt が不親切になったという単純な話ではない。古い互換機能を維持することには、実装の複雑化、テスト範囲の拡大、古い暗号仕様や KDF の温存、利用者の誤解、保守負担というコストがある。TrueCrypt Mode を残し続ければ、過去資産の救済には役立つが、同時に「TrueCrypt 形式をこれからも使ってよい」という誤った印象を与えかねない。保守される暗号化ソフトとしては、旧形式を切り離し、自身の形式と安全性維持に集中する判断も理解できる。したがって、TrueCrypt Mode の削除は、TrueCrypt 資産が即座に危険になったことを意味しないが、TrueCrypt 資産を VeraCrypt だけに依存して保全する設計が弱くなったことは意味する。

既存資産保全の観点では、この事実はかなり重要である。過去に作成した TrueCrypt コンテナーや暗号化デバイスがあり、それを将来も読む必要がある場合、「VeraCrypt があるから大丈夫」と考えるだけでは不十分である。TrueCrypt Mode を持つ VeraCrypt 1.25.9 以前を保管しておくことは救済策になるが、そのバージョンが将来の GNU/Linux 環境で動くとは限らない。依存ライブラリー、GUI、パッケージ形式、署名、ビルド環境、CPU アーキテクチャ、ディストリビューションの変更によって、古い VeraCrypt をそのまま実行し続けることは難しくなる可能性がある。つまり、VeraCrypt 旧版の保管は有効な保険ではあるが、唯一の保全経路にすべきではない。

ここで GNU/Linux では、別の読み出し経路がある。cryptsetup は TCRYPT 形式に対応しており、TrueCrypt / tcplay / VeraCrypt 互換ボリュームを Linux の device-mapper / dm-crypt にマッピングできる。これは、TrueCrypt や VeraCrypt のアプリケーション本体を使ってマウントするのではなく、TCRYPT ヘッダーを解釈し、復号に必要な情報を取り出し、復号済みブロックデバイスとして /dev/mapper 以下に公開する仕組みである。したがって、既存 TrueCrypt 資産の GNU/Linux 保全では、古い VeraCrypt を温存することに加えて、cryptsetup で読み出せるかを確認することが実務上重要になる。

ただし、cryptsetup TCRYPT は TrueCrypt 資産を近代化する仕組みではない。TCRYPT ヘッダーを LUKS ヘッダーに変換するわけではなく、PBKDF2 を Argon2 に更新するわけでもなく、TrueCrypt ボリュームを内部的に LUKS2 へ昇格させるわけでもない。cryptsetup TCRYPT は、あくまで既存の TCRYPT 形式を読み出し、Linux の標準的なブロックデバイス暗号化レイヤーに接続するための互換機能である。したがって、これを使って読み出せた場合でも、長期的な結論は「そのまま TrueCrypt 形式を使い続ける」ではなく、「読めるうちに必要なデータを LUKS 側へ移す」になる。

このように見ると、TrueCrypt 資産の保全経路は 3 つに整理できる。第一に、TrueCrypt 7.1a そのものを使う経路である。これは当時の本体なので互換性は高いが、保守停止済みであり、現代の GNU/Linux で安全に維持するには向かない。第二に、VeraCrypt 1.25.9 以前を使う経路である。これは TrueCrypt Mode によって既存資産を開ける可能性があるが、1.26 以降では削除済みであり、将来の主経路にはしにくい。第三に、cryptsetup TCRYPT を使う経路である。これは GNU/Linux の標準的な運用に近く、既存資産の読み出し確認に向くが、TCRYPT 形式そのものを更新するものではない。

したがって、既存 TrueCrypt 資産を保全する場合、VeraCrypt だけを救済策として考えるべきではない。VeraCrypt 旧版を保管することは有効だが、それは補助的な保険である。GNU/Linux を前提にするなら、まず cryptsetup で読み出せるかを確認し、そのコマンド、cryptsetup のバージョン、対象ファイルやデバイスのハッシュ値、鍵ファイルの有無、マウント結果、検証日を記録するべきである。そのうえで、重要データは LUKS 側へ移し、TrueCrypt 側は読み取り専用のレガシーアーカイブとして扱う。この方針なら、VeraCrypt の互換機能削除に左右されにくくなる。

12. GNU/Linux では cryptsetup が TCRYPT を標準的に扱える

GNU/Linux では、TrueCrypt 7.1a や VeraCrypt 1.25.9 本体がなくても、cryptsetup によって TrueCrypt 形式の資産を開ける場合がある。cryptsetup の man page は、TCRYPT 拡張として TrueCrypt、tcplay、VeraCrypt 互換の暗号化パーティションを Linux カーネル API でマッピングできると説明している[21]。これは、既存 TrueCrypt 資産の保全において非常に重要である。なぜなら、保守停止済みの TrueCrypt 本体や、TrueCrypt Mode を削除した VeraCrypt 最新版に依存しなくても、GNU/Linux 側の標準的な暗号化ブロックデバイス機構を使って、既存資産を読み出せる可能性があるからである。

ここで重要なのは、cryptsetup が TrueCrypt のアプリケーションそのものを代替しているわけではないことである。cryptsetup は、TrueCrypt の GUI、ボリューム作成画面、システム暗号化機能、隠し OS 機能、各種ウィザードを再現するものではない。cryptsetup が行うのは、TCRYPT 形式の暗号ボリュームを Linux の device-mapper / dm-crypt に接続することである。つまり、TrueCrypt 形式のヘッダーを読み、パスフレーズや鍵ファイルから復号に必要な情報を導出し、その情報を Linux カーネルの暗号化ブロックデバイス層へ渡す。その結果として、/dev/mapper/ 以下に復号済みのブロックデバイスが現れる。

この仕組みを理解するには、TrueCrypt 資産を「暗号化されたファイル」ではなく、「暗号化されたブロックデバイス」として見る必要がある。ファイルコンテナーの場合、見た目には 1 個の通常ファイルである。しかし、その内部には暗号化された仮想ブロックデバイスがあり、マウント後には、その上に存在する FAT、NTFS、ext 系などのファイルシステムを通常のファイルシステムとして扱える。デバイス丸ごと暗号化の場合も同じである。外付け HDD、USB メモリー、パーティション全体が TCRYPT 形式の暗号化ブロックデバイスになっており、cryptsetup で開くと /dev/mapper/ 以下に復号済みデバイスが作られる。

したがって、cryptsetup TCRYPT の実務上の役割は、既存 TrueCrypt 資産を GNU/Linux の標準的なブロックデバイス処理へ接続することである。利用者は、TrueCrypt 本体を起動するのではなく、cryptsetup で暗号ボリュームを開き、その結果として作られた /dev/mapper/ 以下のデバイスを mount する。読み出しだけを行うなら、cryptsetup 側でも読み取り専用にし、mount 側でも読み取り専用にすることで、既存資産を変更せずに確認できる。この性質は、保全対象の古い TrueCrypt 資産を扱ううえで重要である。

現時点の事実として、GNU/Linux では cryptsetup に TCRYPT 対応があり、TrueCrypt、tcplay、VeraCrypt 互換ボリュームを扱う説明が man page に存在する。これは、VeraCrypt 1.26 以降で TrueCrypt Mode が削除された現在でも、GNU/Linux には既存 TrueCrypt 資産を読み出す実務的な経路が残っていることを意味する。一方で、この事実から、将来も永久に TCRYPT 対応が同じ形で維持されると断言することはできない。TCRYPT は新規利用を推奨する主形式ではなく、互換目的のレガシー形式である。将来のディストリビューション方針、保守負担、テスト範囲、利用者数の変化によって、扱いが変わる可能性はある。

したがって、cryptsetup TCRYPT は、既存資産の読み出し経路として非常に有用だが、最終的な保管形式として TrueCrypt を延命する根拠にはしないほうがよい。実務上は、現在の GNU/Linux 環境で cryptsetup による読み出し確認を行い、そのときのコマンド、cryptsetup のバージョン、対象ファイルや対象デバイスの識別情報、鍵ファイルの有無、ファイルシステム種別、検証日を記録する。そのうえで、重要データは LUKS 側へ移す。つまり、cryptsetup TCRYPT は「既存資産を読めるうちに確認し、移行するための経路」として扱うべきである。

13. cryptsetup の TCRYPT 対応は変換ではなくマッピングである

前章で述べたように、cryptsetup TCRYPT は、GNU/Linux 上で既存 TrueCrypt 資産を読み出すための有力な経路である。しかし、この章で明確にしておくべきなのは、それが変換機能ではないという点である。cryptsetup で TrueCrypt ボリュームを開けることと、TrueCrypt ボリュームが LUKS に変換されることはまったく違う。cryptsetup の man page は、TCRYPT ヘッダーのフォーマットや TCRYPT ヘッダー変更をサポートせず、オンデバイスの TCRYPT ヘッダーを変更しないと明記している[21]。したがって、cryptsetup で開いても、TCRYPT ヘッダーが LUKS2 ヘッダーへ置き換わるわけではない。

この違いは実務上きわめて大きい。LUKS では、鍵スロットを追加する、鍵を削除する、ヘッダーをバックアップする、LUKS2 のメタデータを管理する、KDF の設定を扱う、といった操作が標準機能として提供される。LUKS は、Linux における暗号化ブロックデバイスの管理形式として設計されているため、暗号化領域を長期運用するためのメタデータ管理機能を持つ。一方、TCRYPT を cryptsetup で開く場合、cryptsetup は既存の TCRYPT ヘッダーを読み、復号用のマッピングを作るだけである。TrueCrypt 形式そのものを保守・近代化するわけではない。

つまり、cryptsetup TCRYPT でできるのは、既存 TrueCrypt 資産を開くこと、読み出すこと、必要に応じて書き込むこと、そして内部ファイルシステムを通常のブロックデバイスとして扱うことである。できないのは、TrueCrypt ボリュームをその場で LUKS 化すること、TCRYPT ヘッダーを LUKS2 ヘッダーへ置換すること、PBKDF2 を Argon2 に更新すること、LUKS の鍵スロット管理へ移行すること、TrueCrypt の隠しボリューム保護を LUKS 的な管理へ変換することである。この違いを理解しないと、「cryptsetup で開けるから、このまま TrueCrypt 形式を保守できる」という誤解につながる。

長期的な近代化は、TCRYPT 内部の更新ではなく、データ移行によって行う必要がある。手順としては、まず TrueCrypt コンテナーまたは暗号化デバイスを cryptsetup TCRYPT で読み取り専用または必要に応じて通常モードで開く。次に、/dev/mapper/ 以下に現れた復号済みデバイスを mount する。そこで内部データを確認し、新しく作成した LUKS 領域へコピーする。最後に、コピー先の LUKS 領域でデータが読めることを確認し、元の TrueCrypt 資産は読み取り専用アーカイブとして保全する。この流れが、TrueCrypt 形式から LUKS 形式へ移行する現実的な方法である。

ここで注意すべきなのは、書き込み可能で開けることと、書き込み運用を続けるべきことは別である。cryptsetup TCRYPT で開いた後、内部ファイルシステムを読み書き可能にマウントすれば、TrueCrypt ボリューム内のデータを変更できる。しかし、既存資産保全の文脈では、まず読み取り専用で確認するのが基本である。特に隠しボリュームの可能性がある場合、外側ボリュームへの書き込みは隠し領域を破壊する可能性がある。また、古いコンテナーや古い外付け媒体では、ファイルシステムの整合性、媒体劣化、ヘッダー破損の問題もある。書き込みが必要な場合でも、先にコンテナー全体またはデバイスイメージ全体の複製を取り、ハッシュ値を記録してから作業すべきである。

現時点の事実として、cryptsetup TCRYPT は既存 TrueCrypt 資産の読み出しに有用である。しかし、今後の推測として、TCRYPT 形式が LUKS と同じ重みで保守され続けるとは限らない。LUKS は GNU/Linux の暗号化ストレージにおける主形式であり、今後もディストリビューション、インストーラー、運用手順、ドキュメント、テストの中心に残る可能性が高い。一方、TCRYPT は過去資産との互換のための形式であり、新規利用の中心ではない。このため、長期保全の戦略としては、TCRYPT を「読めるうちに開くための経路」と位置づけ、主データは LUKS 側へ移すほうが安定する。

したがって、cryptsetup TCRYPT の評価は二面的である。読み出し経路としては非常に価値がある。TrueCrypt 本体や VeraCrypt 旧版に依存せず、GNU/Linux の標準的な仕組みで既存資産を扱えるためである。しかし、保守・近代化の経路としては限界がある。TCRYPT ヘッダーを更新せず、LUKS 化もせず、KDF も更新しないためである。既存資産の保全では、この二面性を前提に、cryptsetup TCRYPT を「開くための入口」として使い、LUKS を「今後の保管先」として使うのが合理的である。

14. TrueCrypt ファイルコンテナーを読み出す手順

通常の TrueCrypt 7.1a ファイルコンテナーを読み出す場合、まず作業対象を複製したうえで、複製側を読み取り専用で確認するのが安全である。コンテナーが 1 個のファイルであれば、まずファイルのハッシュ値を記録する。これにより、後日の検証時に、コンテナーが変化していないか確認できる。ハッシュ値は暗号を強くするものではないが、保全対象の同一性を確認するうえで重要である。

次に、cryptsetup で TCRYPT として開く。最初は必ず読み取り専用を標準にする。cryptsetup レベルで –readonly を指定し、mount 側でも -o ro を指定する。これにより、暗号レイヤーとファイルシステムレイヤーの両方で読み取り専用にする。

作業後は、必ずファイルシステムをアンマウントしてから cryptsetup のマッピングを閉じる。順序を逆にしてはいけない。マウント中のファイルシステムを残したまま暗号デバイスを閉じると、整合性問題や後続作業の混乱を招く。

読み出し確認に成功したら、作業記録として、対象ファイル名、ハッシュ値、cryptsetup のバージョン、実行したコマンド、ファイルシステム種別、確認日、鍵ファイルの有無を残す。重要なのは「今読めた」だけで終わらせないことである。長期保全では、将来の自分または別環境が同じ手順を再現できる必要がある。

15. TrueCrypt で丸ごと暗号化したデバイスを読み出す手順

TrueCrypt で丸ごと暗号化したデバイスを扱う場合、ファイルコンテナーよりも慎重に対象を確認する必要がある。デバイスを間違えると、別ディスクを開こうとしたり、誤ってマウントしたり、最悪の場合は別媒体に書き込む可能性がある。したがって、/dev/sdX のような可変名だけに頼らず、/dev/disk/by-id/ を優先して使うべきである。

対象デバイスを確認したら、ファイルコンテナーと同じく、最初は読み取り専用で開く。外付け HDD や USB メモリーの場合、デバイス名は接続順で変わりうるため、作業記録には /dev/sdX ではなく /dev/disk/by-id/ のパスと、その readlink -f の結果を残すのがよい。

終了時は、ファイルコンテナーの場合と同じく、先に umount、後で cryptsetup close である。

デバイス全体暗号化の場合、内部にパーティションテーブルがあるか、直接ファイルシステムが置かれているかによって、マウント対象が異なる場合がある。cryptsetup で開いた後に /dev/mapper/tc_disk を直接 mount できない場合は、lsblk でマッピング後の構造を確認する。必要に応じて partprobe や kpartx を使う場面もあるが、保全作業では最初から複雑な操作に進まず、まず現在の構造を観察するほうが安全である。

16. 読み取り専用で確認する手順

既存暗号資産の保全では、最初の確認作業を読み取り専用にすることが重要である。TrueCrypt 資産は古く、最後に正常終了した時点、ファイルシステムの整合性、隠しボリュームの有無、バックアップヘッダーの状態が不明な場合がある。この状態でいきなり読み書き可能で開くと、ファイルシステムの自動修復、メタデータ更新、アクセス時刻更新、ジャーナル処理、隠し領域破壊などを起こす可能性がある。

読み取り専用確認では、cryptsetup レベルと mount レベルの両方で read-only を指定する。cryptsetup-open の man page は、TCRYPT 形式を open –type tcrypt で開けること、–key-file を使えること、TCRYPT の鍵ファイル処理は LUKS の鍵ファイル処理とは異なることを説明している[22]。この違いを踏まえ、まずは標準的なパスフレーズ入力だけで開けるか確認し、鍵ファイルが必要な場合だけ明示的に追加する。

読み取り専用確認で見るべきものは、ファイル一覧、主要ディレクトリー、ファイル数、代表ファイルのハッシュ値、ファイルシステム種別、文字化けの有無、マウントエラーの有無である。ここで重要なのは、すぐに全コピーへ進むことではなく、対象資産が現在の GNU/Linux 環境で再現可能に開けることを確認し、その記録を残すことである。

17. 書き込み可能で扱う場合の手順とリスク

TrueCrypt 資産を GNU/Linux 上で扱う場合、読み取り専用確認だけで済むとは限らない。内部のファイルを整理したい、不要ファイルを削除したい、別媒体へ移す前に一時的にメタデータを更新したい、ファイルを追加してから LUKS 側へ移したい、といった場面では、読み書き可能でマウントする必要が出る。ただし、既存資産保全の文脈では、読み書き可能にすることは単なる操作モードの違いではない。読み書き可能にした時点で、コンテナーまたは暗号化デバイスの内容は変化しうる。ファイルを明示的に編集しなくても、ファイルシステムのジャーナル処理、メタデータ更新、アクセス時刻更新、空き領域管理、ファイルシステム修復によって、暗号化領域内部の状態が変わる可能性がある。

したがって、書き込み可能で扱う場合の原則は、元資産を直接更新しないことである。ファイルコンテナーであれば、まず元ファイルを複製し、複製側を作業対象にする。丸ごと暗号化デバイスであれば、可能であればデバイス全体のイメージを取得し、そのイメージまたは複製媒体を作業対象にする。元資産は読み取り専用アーカイブとして残し、作業用コピーに対してだけ読み書き可能マウントを行う。この方針を取れば、書き込み作業中にファイルシステムを壊した場合でも、元資産へ戻れる。

ファイルコンテナーの場合、まず元コンテナーのハッシュ値を記録し、作業用コピーを作成する。コピー後にもハッシュ値を確認し、元ファイルと作業用コピーが同一であることを確認する。以後、読み書き可能で開く対象は作業用コピーだけにする。書き込み後は、作業用コピーのハッシュ値が変わるのは正常である。これは暗号化領域内部に変更が入ったためであり、異常ではない。一方、元コンテナーのハッシュ値が変わっていないことを確認できれば、元資産が保全されていることを確認できる。

作業用コピーを読み書き可能で開く場合は、cryptsetup に –readonly を付けない。mount 側でも -o ro を付けない。ただし、不要なメタデータ更新を抑えたい場合は noatime を付ける。noatime はファイルアクセス時刻の更新を抑えるため、余計な書き込みを減らす効果がある。ただし、書き込み可能マウントであること自体は変わらない。内部ファイルを変更すれば、当然ながら作業用コピーは更新される。

書き込み可能で開けたことを確認するには、いきなり重要ファイルを変更しない。まず作業用コピー上でテストファイルを作成し、sync、アンマウント、再オープン、再読み出しを行う。この一連の確認により、書き込み、ファイルシステム同期、暗号マッピング終了、再マウント後の読み出しが成立していることを確認できる。テストファイルが不要であれば、確認後に削除して再度 sync する。削除も書き込みであるため、作業用コピーに対してだけ行う。

丸ごと暗号化したデバイスを書き込み可能で扱う場合は、ファイルコンテナーよりさらに慎重にする。物理デバイスを直接読み書き可能で開くと、その媒体自体が変更される。安全側に倒すなら、元デバイスから作業用イメージを作成し、そのイメージを対象にする。デバイスのイメージ化は容量が大きく時間もかかるが、元媒体を守るという意味では最も安全である。作業用イメージを使う場合、cryptsetup の対象は /dev/disk/by-id/ の実デバイスではなく、作成したイメージファイルになる。

作業用イメージを読み書き可能で開く手順は、ファイルコンテナーの場合と同じである。ただし、内部にパーティションテーブルがある場合は、/dev/mapper/tc_disk_work を直接マウントできないことがある。この場合は、まず lsblk で構造を確認し、必要に応じてパーティションマッピングを作成してから該当パーティションをマウントする。保全作業では、構造が分からない状態で fsck や mount を繰り返すのではなく、まず lsblk、file、blkid で観察する。

もし /dev/mapper/tc_disk_work を直接マウントできず、内部にパーティションがある場合は、kpartx でパーティションマッピングを作成してからマウントする。ただし、これは対象構造を理解した後に行うべきである。作業後は、マウント解除、kpartx の解除、cryptsetup close の順に閉じる。順序を誤ると、マッピングが残ったり、後続作業で混乱したりする。

書き込み可能で扱う場合の影響範囲は、暗号レイヤー、ファイルシステムレイヤー、保全記録の 3 つに分けて考えると分かりやすい。暗号レイヤーでは、TCRYPT ヘッダーが更新されるわけではないが、暗号化されたデータ領域の内容は変化する。ファイルシステムレイヤーでは、ファイル追加、削除、更新だけでなく、ジャーナル、ディレクトリーエントリー、空き領域管理、アクセス時刻などが変化しうる。保全記録の面では、作業用コピーのハッシュ値は変わるため、作業前ハッシュと作業後ハッシュを別物として記録する必要がある。

書き込み後に確認すべきことは、単にコマンドが成功したかどうかではない。第一に、変更対象のファイルが期待通り作成、更新、削除されていることを確認する。第二に、sync、umount、cryptsetup close が正常終了することを確認する。第三に、再度 cryptsetup で開き直し、変更結果が再現して読めることを確認する。第四に、必要であれば代表ファイルのハッシュ値を取得し、LUKS 側へコピーしたデータと一致することを確認する。第五に、作業用コピーのハッシュ値、作業内容、作業日時、cryptsetup のバージョンを記録する。

書き込み可能運用を許容してよい場面は限定的である。たとえば、作業用コピー上でファイルを整理してから LUKS 側へ移す場合、ファイルシステムの状態を確認するために一時的にテスト書き込みする場合、または元資産を別途保全済みで、作業用コピーを編集対象として明確に分けている場合である。反対に、元コンテナーや元デバイスを直接書き込み可能で開くこと、媒体劣化が疑われるデバイスへ直接書き込むこと、内部構造が不明なまま fsck による自動修復を行うこと、作業記録なしにファイルを更新することは避けるべきである。

以上を踏まえると、書き込み可能で扱う場合の判断基準は明確である。元資産を保全したまま、作業用コピーに対して、目的を限定し、作業前後を記録し、再オープン確認まで行える場合には、読み書き可能マウントは実務上許容できる。一方、元資産しか存在しない場合、媒体劣化が疑われる場合、内部構造が不明な場合、隠しボリュームの有無が不明な場合、作業内容を記録できない場合は、読み取り専用にとどめるべきである。リスクがあるから禁止、ではなく、影響範囲を作業用コピーに閉じ込め、確認可能な形にしてから書き込む、という整理が正確である。

18. 隠しボリュームは外側ボリュームの書き込み安全性を変える

TrueCrypt の隠しボリュームは、通常ボリュームとは異なる前提を持つ。通常ボリュームでは、暗号化領域を開くと、その内部に 1 つのファイルシステムが存在し、そのファイルシステムの空き領域は実際に空き領域として扱われる。しかし、隠しボリュームを使う場合、外側ボリュームのファイルシステムからは空き領域に見える場所に、別の暗号ボリュームが存在しうる。TrueCrypt 7.1a のドキュメントでは、隠しボリュームは標準ボリュームと同様に、外側またはホストボリュームを選択し、隠しボリューム用のパスワードを入力してマウントするものとして説明されている[23]。この設計は plausible deniability を意識したものであり、単なる「二重暗号化」ではない。

隠しボリュームの本質は、存在を外側から確定しにくくするために、外側ボリューム側へ隠し領域の位置情報を明示しない点にある。もし外側ボリュームのメタデータに「ここから先は隠しボリュームなので書いてはいけない」という情報を記録すれば、隠しボリュームの存在を示す証拠になってしまう。そのため、外側ボリュームのファイルシステムは、隠しボリュームの存在を知らない。外側ボリュームから見れば、その領域は単なる未使用領域であり、ファイル追加、ファイル更新、空き領域再利用、デフラグ、ファイルシステム修復などによって書き込まれうる。ここに、外側ボリュームへの書き込みが危険になる構造的理由がある。

このリスクは、隠しボリュームを実際に使っている場合に最も重要である。外側ボリュームを読み書き可能にマウントし、新しいファイルを追加したり、大きなファイルを更新したりすると、外側ファイルシステムが空き領域と判断した場所へデータを書き込む。その場所に隠しボリュームのデータがあれば、隠しボリュームは部分的または全面的に破壊される。しかも、破壊は暗号化された領域の内部で起きるため、通常のファイル削除のように簡単に戻せるものではない。暗号ボリュームの一部が破損すれば、内部ファイルシステムの整合性も失われうる。

ただし、本稿の主対象は、普通の TrueCrypt 7.1a ファイルコンテナーと、外付け HDD、USB メモリー、非システムパーティションなどを丸ごと暗号化した通常のデータ用ボリュームである。隠しボリュームを使っていないことが運用上明確であれば、隠しボリューム特有のリスクを中心問題として扱う必要はない。この場合、主なリスクは、外側ボリュームへの書き込みではなく、作業対象の取り違え、元資産への直接更新、媒体劣化、ファイルシステム破損、手順喪失である。したがって、隠しボリュームを使っていない資産については、通常ボリュームとして読み取り専用確認を行い、必要に応じて作業用コピーへ書き込み、LUKS 側へ移すという主線でよい。

一方、作成履歴が不明な資産、第三者から引き継いだ資産、古い記録しか残っていない資産、複数のパスフレーズ候補が存在する資産では、隠しボリュームの可能性を完全には否定できない。この場合は、通常ボリュームとして開けたからといって、外側ボリュームへ自由に書き込んでよいとは限らない。まず読み取り専用で開き、内部データを確認し、必要なファイルを別の LUKS 領域へコピーする。隠しボリュームの存在が不明なまま、外側ボリュームを作業用の保存先として使い続けるべきではない。

cryptsetup では、隠しボリュームを開く場合に –tcrypt-hidden を使う。ただし、このオプションは「隠しボリュームを安全に保護しながら外側ボリュームへ自由に書き込める」ことを意味しない。これは、隠しボリューム側を開くための指定である。保全作業で重要なのは、どのパスフレーズでどちらのボリュームを開いているのかを混同しないこと、そして外側ボリュームへの書き込みが隠し領域を破壊しうることを理解することである。

TRIM や discard も、既存 TrueCrypt 資産の保全作業では避けるべきである。discard は、ストレージ側に未使用領域の情報を伝える操作であり、暗号化デバイスの使用状況に関する情報を外部へ漏らす可能性がある。また、隠しボリュームが存在する場合、外側ファイルシステムから見た未使用領域と、実際に保護すべき隠し領域の関係が問題になる。隠しボリュームを使っていないことが明確な通常資産でも、レガシー暗号資産を保全する局面では、discard を有効にする積極的な理由は乏しい。読み出し確認と移行が目的なら、余計な最適化は不要である。

19. システム暗号化やバックアップヘッダーは失敗時の切り分けとして扱う

本稿の主対象は、普通の TrueCrypt 7.1a ファイルコンテナーと、外付け HDD、USB メモリー、非システムパーティションなどを丸ごと暗号化した通常のデータ用ボリュームである。しかし、TrueCrypt には Windows システム暗号化、隠しボリューム、バックアップヘッダーといった通常ボリュームとは異なる形式も存在する。cryptsetup には、これらに対応する TCRYPT 用の補助オプションとして、–tcrypt-system、–tcrypt-hidden、–tcrypt-backup などがある。これらの存在を知っておくことは重要だが、最初から特殊オプションを乱用するべきではない。

この章の本質は、特殊形式を網羅的に使いこなすことではなく、通常手順で開けない場合に何を順番に疑うかを決めることである。暗号化資産の保全作業では、成功したことだけでなく、失敗した条件を記録することが重要になる。どのファイルまたはデバイスを対象にしたのか、どのパスフレーズを使ったのか、鍵ファイルを指定したのか、どの cryptsetup オプションを使ったのか、どのエラーが出たのかを記録しないと、試行を重ねるほど状態が分からなくなる。特に、通常ボリューム、隠しボリューム、システム暗号化、バックアップヘッダーを混同すると、失敗の原因を切り分けにくくなる。

Windows システム暗号化は、通常のデータ用ボリュームとは性質が異なる。起動前認証、ブートローダー、Windows 固有のディスク構成、システム領域の暗号化が関係するため、単に外付けディスクをマウントする話ではない。cryptsetup の –tcrypt-system は、このようなシステム暗号化形式を扱うための補助オプションである。したがって、普通のファイルコンテナーや外付けデータディスクに対して、理由なく指定するものではない。対象が本当に Windows システム暗号化由来である場合に限って検討するべきである。

バックアップヘッダーも、通常手順の代替ではなく、復旧時の切り分けとして扱うべきである。TrueCrypt のボリューム形式では、ヘッダーにメタデータとマスターキーが含まれ、データ領域とは別に暗号化される。TrueCrypt Volume Format Specification は、通常ヘッダー、隠しボリューム、バックアップヘッダーなどの構造を説明している[24]。ヘッダーが壊れると、データ領域そのものが残っていても復号できない。したがって、通常ヘッダーで開けない場合に、バックアップヘッダーを試すことには意味がある。

ただし、バックアップヘッダーを最初から使うべきではない。通常ヘッダーで問題なく開ける資産に対して特殊オプションを使うと、どの条件で成功したのか分からなくなる。保全作業では、まず標準手順で読み取り専用に開く。次に、パスフレーズ、鍵ファイル、対象デバイス、ファイルコンテナーとデバイス暗号化の違いを確認する。それでも開けない場合に、対象がシステム暗号化か、隠しボリュームか、通常ヘッダー破損かを切り分ける。そのうえで、必要に応じて –tcrypt-system、–tcrypt-hidden、–tcrypt-backup を使う。この順序を守ることで、復旧作業が偶然頼みになりにくくなる。

デバイス丸ごと暗号化の場合は、対象デバイスの取り違えも重要な失敗要因になる。/dev/sdX は接続順で変わる可能性があるため、外付けディスクや USB メモリーを扱う場合は、/dev/disk/by-id/ で対象を確認する。さらに、パーティション全体が TrueCrypt ボリュームなのか、ディスク全体が TrueCrypt ボリュームなのかも切り分ける必要がある。開けない原因がヘッダー破損ではなく、単に指定するデバイス階層を間違えているだけの場合もある。特殊オプションを試す前に、まず対象を正しく識別するべきである。

この章での結論は単純である。通常の TrueCrypt ファイルコンテナーや非システムデバイスは、まず –type tcrypt だけで読み取り専用に開く。開けない場合は、特殊オプションを足す前に、対象、パスフレーズ、鍵ファイル、デバイス階層、エラーメッセージを記録して切り分ける。–tcrypt-system や –tcrypt-backup は、対象形式や失敗原因に根拠がある場合にだけ使う。特殊オプションは便利な近道ではなく、原因を絞った後に使う復旧手段である。

20. tcryptDump は診断情報と秘密情報の境界を意識して使う

cryptsetup には、TCRYPT ヘッダー情報を表示する tcryptDump がある。これは、TCRYPT デバイスのヘッダー情報を確認するためのコマンドであり、保全作業では診断用途として有用である。通常の読み出し手順では、cryptsetup open –type tcrypt で開き、/dev/mapper/ 以下に作られたデバイスを mount できるかを確認するのが主線である。一方、開けない場合や、鍵ファイル指定の有無を切り分けたい場合、対象が TCRYPT として妥当かを確認したい場合には、tcryptDump が補助的に役立つ。

ただし、tcryptDump を使うときは、診断情報と秘密情報の境界を明確に分ける必要がある。ヘッダー情報の確認は診断である。一方、生のボリュームキーを出力する操作は、診断ではなく秘密情報の抽出である。cryptsetup では、–dump-volume-key を指定すると、TCRYPT デバイスのボリュームキーそのものを出力できる。Arch Linux の man page は、ボリュームキーが漏洩すると、パスフレーズなしで TCRYPT コンテナー内のデータを復号できるため、漏洩時にはデバイス全体を消去する必要があると警告している[25]。

ボリュームキーは、パスフレーズや鍵ファイルとは性質が異なる。パスフレーズや鍵ファイルは、ボリュームキーを導出するための入力である。ボリュームキーは、暗号化データ本体の復号に直結する秘密情報である。したがって、ボリュームキーを出力して保存することは、復旧性を単純に高める操作ではない。むしろ、管理すべき最重要秘密を 1 つ増やす操作である。生鍵が端末ログ、シェル履歴、スクリーンショット、クリップボード、エディターの一時ファイル、クラウド同期フォルダー、バックアップ媒体に残れば、強いパスフレーズで守っている意味が大きく損なわれる。

通常の既存資産保全では、–dump-volume-key を標準手順に含めるべきではない。必要なのは、ボリュームを開けること、読み取り専用で内部データを確認できること、LUKS 側へコピーできること、手順と検証日を記録することである。生鍵を取り出さなくても、これらは実行できる。むしろ、生鍵を扱わないほうが、保全手順は単純で安全になる。暗号資産の管理では、秘密情報の数を増やすほど漏洩面も増える。

研究、フォレンジック、専門的な復旧作業などで –dump-volume-key を使う場合は、通常の個人運用とは別の管理設計が必要になる。完全に隔離された環境、ログの無効化、出力先の厳格管理、作業後の消去手順、記録媒体の保管、関係者のアクセス制御まで決めなければならない。少なくとも、一般的なブログ記事の手順や、通常の個人保全作業に、生のボリュームキー抽出を含める必要はない。

したがって、tcryptDump の位置づけは限定的である。通常の読み出しでは open と mount を主手順にする。開けない場合の切り分けでは tcryptDump を使う。生のボリュームキーは、明確な専門的必要がない限り出力しない。この 3 つを分けることで、診断と秘密情報管理を混同せずに済む。

21. 読み出せた後に何をすべきか

TrueCrypt 資産を cryptsetup で読み出せた後にすべきことは、TrueCrypt 側をそのまま使い続けることではない。読み出し成功はゴールではなく、保全作業の開始点である。ここで行うべきことは、内部データを確認し、必要なデータを現在保守されている LUKS 側へ移し、移行結果を検証し、TrueCrypt 側を読み取り専用アーカイブとして残すことである。これは、TrueCrypt の暗号が明日破られるからではない。TrueCrypt が保守停止済みであり、VeraCrypt 1.26 以降で TrueCrypt Mode が削除され、今後のツール環境やディストリビューション環境が変化し、媒体劣化や手順喪失も起こりうるためである。長期保全の主系は、読み出せるうちに LUKS 側へ移したほうがよい。

読み出せた後に最初に行うべきことは、移行方針を決めることである。選択肢は大きく 3 つある。第一に、TrueCrypt 内部の全データを LUKS 側へ全量コピーする方法である。これは最も単純で、後から漏れを確認しやすい。第二に、必要なディレクトリーや重要ファイルだけを選別してコピーする方法である。容量を節約できるが、選別漏れのリスクがある。第三に、TrueCrypt 資産全体をアーカイブとして残しつつ、日常的に必要なデータだけを LUKS 側へ移す方法である。既存資産が大きい場合や、全内容をすぐ整理できない場合は、この方法が現実的である。

移行作業では、まず TrueCrypt 側を読み取り専用でマウントし、コピー先に LUKS 領域を用意する。TrueCrypt 側を書き込み可能にする必要がないなら、最後まで読み取り専用で扱うほうが安全である。コピー先の LUKS 領域は、新規に作成した暗号化領域でも、既存の LUKS バックアップ領域でもよい。ただし、コピー先が十分な容量を持つこと、ファイルシステムが想定するファイル名・権限・サイズを扱えること、移行後に別媒体へバックアップできることを確認してから作業する。

コピーには rsync を使うのが実務上扱いやすい。たとえば、Linux 同士のファイルシステムで、所有者、権限、シンボリックリンク、ハードリンク、ACL、拡張属性をできるだけ保持したい場合は、次のように実行できる。

ただし、rsync のオプションは元ファイルシステムとコピー先ファイルシステムに応じて調整する必要がある。元の TrueCrypt 内部が FAT や exFAT の場合、Unix 的な所有者、パーミッション、ACL、拡張属性は十分に意味を持たない。NTFS の場合も、Linux 上で見える属性と Windows 本来の ACL は同一ではない。したがって、すべてのケースで -aHAX が完全な属性保存を保証するわけではない。重要なのは、機械的に強いオプションを付けることではなく、移したい対象が通常ファイルなのか、写真・文書・アーカイブなのか、実行ファイルや Unix 権限を持つ作業データなのかを理解し、必要な属性を確認することである。

移行後の検証では、単に rsync が終了したことを成功条件にしてはいけない。最低限、コピー元とコピー先のファイル数、総容量、代表ファイルのハッシュ値、rsync の終了コード、エラー出力を確認する。ファイル名に日本語や空白や記号が含まれる場合は、文字化けが起きていないことも確認する。写真、文書、圧縮ファイル、ソースコード、設定ファイルなど、種類の異なる代表ファイルを選び、LUKS 側から実際に開けることを確認する。

より厳密に検証したい場合は、ファイル一覧とハッシュ一覧を作成して比較する。ただし、大量のファイルに対して全件ハッシュを取ると時間がかかり、古い媒体には負荷をかける。媒体劣化が疑われる場合は、全件ハッシュよりも、まず全量コピーを完了させることを優先する。検証は、媒体状態、データ量、重要度に応じて段階を分けるべきである。

この比較では、同じ相対パスで同じ内容がコピーされていれば一致する。ただし、コピー先でファイル名やディレクトリー構造を変更した場合、この方法では単純比較できない。また、ファイル数が非常に多い場合や、ファイル名に特殊文字が多い場合は、一覧の扱いにも注意が必要である。全件比較が現実的でない場合でも、重要ディレクトリー単位、代表ファイル単位、アーカイブ単位で検証する価値はある。

コピー後は、LUKS 側をいったんアンマウントし、再度マウントして読めることを確認する。これは重要である。コピー直後に見えているファイルは、ページキャッシュや未同期の状態に依存している可能性がある。sync、umount、再マウント、再読み出しまで確認することで、LUKS 側のファイルシステムに実際に書き込まれ、再度復号して読めることを確認できる。

TrueCrypt 側は、移行直後に削除しないほうがよい。LUKS 側へのコピーが成功しても、しばらく運用してから不足ファイルや見落としに気づくことがある。また、コピー先の LUKS 領域にまだバックアップがない段階で TrueCrypt 側を消すと、単一障害点を作ることになる。したがって、TrueCrypt 側は少なくとも一定期間、読み取り専用アーカイブとして残す。削除や廃棄を検討するのは、LUKS 側のデータを別媒体へバックアップし、復元確認まで終えた後でよい。

作業記録も保全対象である。最低限、元 TrueCrypt 資産のファイル名またはデバイス識別子、元資産のハッシュ値、使用した cryptsetup のバージョン、実行したコマンド、鍵ファイルの有無、マウント先、コピー先 LUKS 領域、rsync の実行日時、検証方法、代表ファイルのハッシュ値、作業結果を記録する。暗号化資産の移行では、データそのものだけでなく、どの手順で移したかを後から説明できることが重要である。

22. 長期保全では暗号より復元可能性を管理する

TrueCrypt 資産を長期保全する場合、管理対象はコンテナーや暗号化デバイスだけではない。暗号化データ本体が残っていても、パスフレーズ、鍵ファイル、読み出しコマンド、対象デバイスの指定、ファイルシステム種別、検証履歴が失われれば、実務上は復元不能になる。暗号化資産の保全では、「攻撃者に読まれないこと」と同じくらい、「正当な利用者が将来も読めること」が重要である。十分に強いパスフレーズで守られた TrueCrypt 資産では、総当たり攻撃よりも、媒体劣化、手順喪失、鍵ファイル紛失、読み出し環境の消滅、デバイス指定ミスのほうが現実的な失敗要因になりやすい。

したがって、長期保全では、暗号化ファイルまたはデバイスイメージ、パスフレーズ管理方針、鍵ファイル、cryptsetup のバージョン、読み出しコマンド、対象デバイスの識別情報、ファイルシステム種別、確認日、ハッシュ値、保管媒体、複製先、復元確認結果を一体として扱う必要がある。これは単なる作業メモではなく、復元可能性を維持するための台帳である。どれか 1 つが欠けると、暗号化データは物理的に存在していても、将来の自分が安全に開けない状態になりうる。

コンテナー形式の場合は、ファイル名、ファイルサイズ、SHA-256 などのハッシュ値、保管場所、複製先、最終検証日を記録する。ファイル名だけでは不十分である。後から同名ファイルを複製したり、別媒体に移したり、作業用コピーを作ったりすると、どれが原本でどれが作業用か分からなくなるためである。ハッシュ値を記録しておけば、後からファイルが同一であるか、作業によって変化したか、媒体劣化や誤コピーが起きていないかを確認できる。

デバイス丸ごと暗号化の場合は、さらに慎重に管理する必要がある。/dev/sdX のような名前は接続順で変わるため、長期保全の識別子としては弱い。外付け HDD や USB メモリーでは、モデル名、シリアル番号、容量、接続方式、/dev/disk/by-id/ のパス、取得したデバイスイメージのファイル名とハッシュ値を記録する。デバイス全体が TrueCrypt ボリュームなのか、特定パーティションが TrueCrypt ボリュームなのかも明記する。ここを曖昧にすると、将来の読み出し時に対象を誤りやすい。

パスフレーズと鍵ファイルは、データ本体とは別の復元要素である。パスフレーズそのものを通常の作業記録に平文で書くべきではないが、保管方針は定めておく必要がある。鍵ファイルを使っている場合は、鍵ファイル本体、ハッシュ値、サイズ、保管場所、複製先、指定順序を記録する。鍵ファイルは、失うと正当な利用者も復元できなくなる一方、漏洩すると防御要素としての価値を失う。したがって、鍵ファイルは「便利な追加情報」ではなく、パスフレーズと同じく復元可能性を左右する中核情報として扱うべきである。

読み出し手順も保全対象である。cryptsetup の TCRYPT 対応は有用だが、将来の環境で同じコマンドを迷わず再現できるとは限らない。したがって、cryptsetup のバージョン、実行した open コマンド、読み取り専用指定、鍵ファイル指定、隠しボリュームを使っていないこと、mount コマンド、ファイルシステム種別、成功した検証日を記録する。開けたという事実だけでなく、どの条件で開けたのかを残すことが重要である。

dm-crypt は Linux カーネルの device-mapper における crypt target として、カーネル crypto API を使い、ブロックデバイスに対する透過的な暗号化を提供する[26]。cryptsetup は、この仕組みを扱うユーザー空間の主要ツールであり、LUKS だけでなく TCRYPT のような互換形式も扱う。cryptsetup の FAQ も、復旧、バックアップ、データリカバリーを含む運用上の観点を整理している[27]。この標準基盤に寄せられることが、GNU/Linux で TrueCrypt 資産を読むうえでの大きな利点である。ただし、cryptsetup が使えることは、台帳化や復元確認を省略してよいことを意味しない。

23. 保持可能年数の現実的な見積もり

TrueCrypt 資産をあと何年保持できるかは、単一の年数で断定できない。暗号秘匿性、パスフレーズ強度、媒体寿命、読み出しツール、作業手順、鍵ファイル管理、検証頻度によって、寿命を決める要因が異なるためである。十分に長いランダムな英数記号列で守られた TrueCrypt 7.1a 資産について、暗号秘匿性だけを見れば、短期で直ちに読まれる可能性は高くないと見るのが合理的である。一方で、長期保全で先に問題化しやすいのは、暗号解読よりも、読める環境、媒体、手順、鍵情報の欠落である。

ここで事実と推測を分ける必要がある。事実として、TrueCrypt は保守停止済みである。事実として、VeraCrypt 1.26 以降では TrueCrypt Mode が削除されている。事実として、cryptsetup には TCRYPT 対応があるが、TCRYPT ヘッダーを LUKS へ変換するものではない。事実として、ストレージ媒体は劣化し、外付け HDD、USB メモリー、SSD、光学媒体、バックアップ HDD はいずれも永続媒体ではない。一方、推測として、十分に強いランダムパスフレーズを使い、媒体を複製し、cryptsetup での読み出し手順を記録し、定期的に復元確認するなら、15 年から 20 年程度の保全は現実的である。さらに、媒体更新と LUKS への移行を継続するなら、20 年超も不可能ではない。

ただし、これは「TrueCrypt 形式のまま 20 年以上放置してよい」という意味ではない。放置された暗号資産では、暗号より先に周辺条件が崩れる。古い外付け HDD が読めなくなる、USB メモリーが劣化する、保管場所が分からなくなる、鍵ファイルが失われる、当時のメモが曖昧になる、VeraCrypt 旧版が動かない、cryptsetup の挙動を確認していない、ファイルシステムが古い、文字コードや所有者情報の扱いが分からない、といった問題が先に来る可能性が高い。暗号が破られていなくても、復元できなければ保全には失敗している。

保持可能年数は、運用状態ごとに分けて見るべきである。何もせず放置するだけなら、5 年から 10 年程度で読み出し不安が増す。これは暗号が破られるという意味ではなく、媒体、手順、ツール、鍵情報のどれかが不確実になるという意味である。cryptsetup で読み出し確認を行い、作業手順書を残し、ハッシュ値を記録するなら、10 年から 15 年程度の保全見通しは立てやすくなる。さらに、複数媒体に複製し、定期的に読み出し検証し、LUKS 側へ段階移行するなら、15 年から 20 年程度は現実的な範囲に入る。継続的に媒体更新と移行を行うなら、20 年超も不可能ではない。

もっとも、最善の結論は「TrueCrypt のまま何年耐えるか」を競うことではない。既存 TrueCrypt 資産は、読めるうちに読み出し確認を行い、必要なデータを LUKS 側へ移し、TrueCrypt 側は読み取り専用アーカイブとして一定期間残すのがよい。保持可能年数の見積もりは、TrueCrypt 形式を延命するためではなく、移行優先度を決めるために使うべきである。重要度が高く、更新頻度があるデータほど早く LUKS へ移す。参照頻度が低く、すでに内容が固定されたアーカイブは、読み取り確認と複製を行ったうえで凍結保管する。

24. TrueCrypt 資産の最終的な扱い

TrueCrypt 資産の最終的な扱いは明確である。新規作成しない。常用しない。読めるうちに確認する。重要データから LUKS 側へ段階移行する。移行困難なものは、読み取り専用アーカイブとして凍結する。この方針なら、TrueCrypt を過剰に恐れず、かといって保守停止済み形式へ依存し続けることも避けられる。TrueCrypt は、今後の主系暗号化基盤ではなく、既存データを失わないために扱うレガシー形式である。

この判断は、監査結果とも矛盾しない。独立監査では、TrueCrypt 7.1a に明白なバックドアや通常利用を全面的に破壊する重大設計欠陥は確認されなかった。一方で、監査は保守停止、ライセンス、将来の互換性、読み出し環境、媒体劣化、鍵管理、手順喪失を解決するものではない。したがって、監査結果から導ける結論は、「既存資産を恐怖で即時廃棄しなくてよい」であって、「今後も TrueCrypt を使い続けてよい」ではない。

VeraCrypt についても、補助経路としては有用だが、永続的な保証として扱うべきではない。BSI の VeraCrypt 評価は、VeraCrypt が TrueCrypt 由来の問題をどのように引き継ぎ、どの問題が修正済みまたは未修正かを確認している[28]。このことからも、後継ソフトであっても監査、修正、互換性、仕様変更が継続的に問題になることが分かる。VeraCrypt 1.25.9 以前を保険として残すことは有用だが、既存 TrueCrypt 資産の出口を VeraCrypt 旧版への恒久依存にすべきではない。

GNU/Linux を前提にするなら、出口はより明確である。cryptsetup TCRYPT で読み出し確認を行い、必要なデータを LUKS 側へコピーし、LUKS 側で再マウント確認とバックアップ確認を行う。TrueCrypt 側は、原本または旧資産として読み取り専用で残す。日常利用、更新、追加、バックアップ運用は LUKS 側へ移す。このように分ければ、TrueCrypt 資産を失わずに、今後の保守基盤を GNU/Linux 標準側へ寄せられる。

25. BSI の VeraCrypt 評価は、後継ソフトにも保守と継承の問題があることを示している

TrueCrypt 資産の最終的な扱いを考えるとき、VeraCrypt の位置づけも整理しておく必要がある。VeraCrypt は TrueCrypt 終了後の有力な後継ソフトであり、一定期間は TrueCrypt Mode によって TrueCrypt 6.x / 7.x の通常ボリュームや隠しボリュームを開く経路を提供していた。その意味で、既存 TrueCrypt 資産の救済策として重要な役割を持っていた。しかし、VeraCrypt を「TrueCrypt 資産の永続的な出口」と見なすのは危うい。VeraCrypt 自体も、TrueCrypt 由来コード、独自の実装、開発体制、互換性変更、暗号実装の近代化という問題から自由ではないためである。

この点を考えるうえで参考になるのが、ドイツの BSI、すなわち Federal Office for Information Security が公開した VeraCrypt のセキュリティ評価である。この評価は Fraunhofer Institute for Secure Information Technology によって実施され、VeraCrypt の暗号機能、コンテナー処理、カーネルドライバーとのインターフェイス、コード品質、開発プロセス、TrueCrypt 由来コードの継承などを対象としている[28]。ここで重要なのは、この報告書が TrueCrypt 7.1a そのものの監査ではなく、TrueCrypt の後継として使われてきた VeraCrypt の評価であるという点である。したがって、TrueCrypt 資産を直接どう開くかの根拠ではなく、後継ソフトに依存することの限界を考える材料として読むべきである。

評価の大枠は、VeraCrypt に対して直ちに利用を否定するような重大な脆弱性が確認された、というものではない。むしろ、基本的な暗号機能やコンテナー処理について、通常利用を全面的に破壊するような結論を出しているわけではない。その一方で、開発プロセス、コード品質、古い暗号コード、TrueCrypt 由来コードの継承、暗号実装の近代化については課題があると整理されている。つまり、この評価は「VeraCrypt は危険だから使うな」という単純な資料ではなく、「後継ソフトであっても、保守、監査、コード品質、暗号実装の更新は継続的な問題である」ということを示す資料である。

この報告書が TrueCrypt 資産保全の文脈で重要なのは、TrueCrypt の問題が後継ソフトへ完全に吸収されて消えたわけではないことを示している点である。VeraCrypt は TrueCrypt から派生したソフトであり、TrueCrypt 由来のコードや設計上の前提を多く引き継いでいる。そのため、VeraCrypt を使えば TrueCrypt の歴史的問題がすべて解決する、とは言えない。もちろん、VeraCrypt は独自に修正や改善を重ねてきた後継プロジェクトであり、TrueCrypt そのものより現代的に保守されてきた。しかし、後継であることは、無期限の互換性、無条件の安全性、永続的な読み出し保証を意味しない。

実際に、VeraCrypt 1.26 以降では TrueCrypt Mode が削除されている。これは、VeraCrypt の最新版があれば TrueCrypt 資産をいつでも読める、という前提がすでに成立しないことを意味する。VeraCrypt 1.25.9 以前を保険として保管しておくことには実務上の価値がある。しかし、その旧版を将来の主な復元手段として固定するのは、別のレガシー依存を作ることになる。古い VeraCrypt バイナリー、古いライブラリー、古い OS 互換性、配布物の真正性確認、実行環境の再現性を将来も維持しなければならないためである。

BSI の VeraCrypt 評価は、この判断を補強する。後継ソフトであっても、監査、開発体制、コード品質、暗号実装、互換性変更は継続的に問題になる。したがって、既存 TrueCrypt 資産の出口を「VeraCrypt に任せる」だけに置くべきではない。VeraCrypt は補助経路であり、過去資産を開くための保険としては有用である。しかし、長期保全の主戦略は、GNU/Linux で cryptsetup TCRYPT による読み出しを確認し、必要なデータを LUKS 側へ移すことである。これにより、保全対象を TrueCrypt / VeraCrypt 互換性の問題から切り離し、現在の GNU/Linux 標準基盤へ寄せられる。

この点は、TrueCrypt 資産の評価を過度に単純化しないためにも重要である。TrueCrypt は保守停止済みだから直ちに危険、VeraCrypt は後継だから完全に安全、という二分法では不十分である。より正確には、TrueCrypt は既存資産として冷静に読み出すべきレガシー形式であり、VeraCrypt はその補助経路の一つであり、cryptsetup TCRYPT は GNU/Linux 上での重要な読み出し経路であり、LUKS は今後の主な保管先である。この役割分担を明確にすれば、どのソフトを信頼するかという抽象論ではなく、どの形式をいつまで主系として扱うかという運用設計として判断できる。

したがって、BSI の VeraCrypt 評価を本稿に入れる意味は、VeraCrypt を否定することではない。むしろ、VeraCrypt を適切な位置に置くことである。VeraCrypt は TrueCrypt の後継として重要であり、旧版は既存 TrueCrypt 資産を開くための保険になりうる。しかし、既存 TrueCrypt 資産の最終的な出口は VeraCrypt への恒久依存ではない。GNU/Linux では、cryptsetup TCRYPT で読み出しを確認し、重要データを LUKS 側へ移し、TrueCrypt 側は読み取り専用アーカイブとして凍結する。この方針が、後継ソフトの評価結果とも整合する現実的な保全戦略である。

26. 結論

TrueCrypt 7.1a 資産をどう扱うべきかという問いは、単純に「安全か危険か」で答えられるものではない。TrueCrypt は、かつて実用上広く使われた暗号化ソフトであり、ファイルコンテナー、非システムデバイス暗号化、ディスク全体暗号化、隠しボリュームなどを提供していた。一方で、開発は突然終了し、公式サイトは使用継続に警告を出し、開発者は匿名であり、ライセンスは標準的な自由ソフトウェアライセンスではなく、現在では保守主体も存在しない。したがって、TrueCrypt 資産の問題は、暗号アルゴリズムが直ちに破られたという単純な問題ではなく、保守停止済み形式を将来どう読める状態に保つかという、暗号資産の復元可能性管理の問題である。

独立監査の結果は、この判断を冷静にするための重要な材料になる。Phase I では、主に Windows カーネルコード、ブートローダー、ファイルシステムドライバーなどの低レイヤー実装が確認され、監査対象範囲で high severity の問題や意図的バックドアの証拠は確認されなかった。Phase II では、TrueCrypt 7.1a の暗号実装、乱数生成、鍵導出、鍵ファイル処理、ボリュームヘッダー、AES 実装などが確認され、複数の弱点は指摘されたが、通常利用を全面的に破壊するような重大設計欠陥や意図的バックドアは確認されなかった。これは、既存 TrueCrypt 資産を恐怖だけで即時廃棄する必要はない、という判断を支える。

しかし、監査結果は TrueCrypt を現在の主系暗号化基盤として使い続ける根拠にはならない。監査は、特定時点、特定範囲、特定の脅威モデルに基づく評価であり、保守停止後に発見される脆弱性、将来の OS 互換性、配布物の真正性、ビルド環境、読み出しツール、媒体劣化、鍵ファイル紛失、手順喪失を保証しない。したがって、監査結果から導ける結論は、「既存資産を冷静に保全できる」であって、「TrueCrypt を今後も使い続けてよい」ではない。この区別を誤ると、監査結果を過大評価することになる。

VeraCrypt についても同じである。TrueCrypt 終了後、VeraCrypt は有力な後継系として機能し、一定期間は TrueCrypt Mode によって TrueCrypt 6.x / 7.x の通常ボリュームや隠しボリュームを開けた。しかし、VeraCrypt 1.26 以降では TrueCrypt Mode が削除されている。つまり、最新版 VeraCrypt があれば TrueCrypt 資産をいつでも読める、という前提はすでに成立しない。VeraCrypt 1.25.9 以前を保険として保管する価値はあるが、旧版 VeraCrypt への恒久依存は、長期保全の主戦略にはならない。

GNU/Linux を前提にするなら、重要なのは cryptsetup の TCRYPT 対応である。cryptsetup は、TCRYPT 拡張によって TrueCrypt、tcplay、VeraCrypt 互換ボリュームを Linux の device-mapper / dm-crypt へマッピングできる。これは、TrueCrypt 本体や VeraCrypt 旧版に依存せず、既存 TrueCrypt 資産を GNU/Linux の標準的な暗号化ブロックデバイス基盤へ接続できるという点で、非常に大きな救済経路である。ただし、cryptsetup TCRYPT は変換機能ではない。TCRYPT ヘッダーを LUKS2 ヘッダーへ置き換えず、PBKDF2 を Argon2 に更新せず、TrueCrypt の鍵管理を LUKS の鍵スロット管理へ移行しない。できるのは、既存形式を開き、復号済みブロックデバイスとして扱うことである。

このため、TrueCrypt 資産の近代化は、内部変換ではなくデータ移行として行う必要がある。具体的には、まず cryptsetup TCRYPT で読み取り専用に開き、内部ファイルシステムを確認する。次に、必要なデータを LUKS 側へコピーする。移行後は、ファイル数、容量、代表ファイルのハッシュ値、再マウント確認、バックアップ確認を行う。TrueCrypt 側はすぐに削除せず、少なくとも一定期間は読み取り専用アーカイブとして残す。これにより、移行漏れや検証不足が見つかった場合でも、元資産に戻れる。

強いパスフレーズを使っている既存資産では、当面の主問題は総当たり攻撃ではなく、復元可能性である。十分に長いランダムなパスフレーズで保護されている場合、暗号化済みボリュームだけを入手した攻撃者が短期に総当たりで突破する可能性は高くないと見るのが合理的である。一方で、媒体が壊れる、鍵ファイルを失う、読み出しコマンドを忘れる、どのデバイスが対象だったか分からなくなる、cryptsetup で開けるか確認していない、LUKS 側へ移したつもりで検証していない、といった事故は現実的に起こりうる。暗号が破られていなくても、正当な利用者が読めなくなれば、保全には失敗している。

したがって、TrueCrypt 資産の長期保全では、暗号化ファイルまたはデバイスイメージ、パスフレーズ管理方針、鍵ファイル、cryptsetup のバージョン、読み出しコマンド、対象デバイスの識別情報、ファイルシステム種別、ハッシュ値、検証日、保管媒体、複製先、LUKS 側への移行記録を一体として管理する必要がある。これは単なるメモではなく、復元可能性を維持するための台帳である。暗号資産は、データ本体だけを保存しても保全したことにはならない。復元に必要な条件をそろえて初めて、保全したと言える。

読み書き可能に扱う場合も、結論は明確である。元資産を直接更新しない。必要がある場合は、コンテナーまたはデバイスイメージの作業用コピーを作り、そのコピーに対してのみ書き込み可能マウントを行う。書き込み後は、sync、umount、cryptsetup close、再 open、再 mount、再読み出しまで確認する。通常運用で隠しボリュームを使っていないなら、そのリスクを過度に中心化する必要はないが、作成履歴が不明な資産では外側ボリュームへの書き込みを避けるべきである。既存 TrueCrypt 資産の保全では、書けるかどうかではなく、書いた結果を元に戻せるか、検証できるか、影響範囲を作業用コピーに閉じ込められるかが重要である。

保持可能年数についても、暗号だけで見るべきではない。十分に強いパスフレーズで守られた TrueCrypt 7.1a 資産は、暗号秘匿性だけを見れば、短期で直ちに破綻する可能性は高くない。しかし、放置すれば 5 年から 10 年程度で読み出し不安が増す。手順化すれば 10 年から 15 年程度の見通しを立てやすくなり、複数媒体、検証履歴、読み出し環境、LUKS 側への段階移行を含めれば 15 年から 20 年程度の保全は現実的になる。継続的に媒体更新と移行を続ければ 20 年超も不可能ではない。ただし、これは TrueCrypt 形式をそのまま延命するための見積もりではなく、移行優先度を決めるための見積もりである。

最終方針は単純である。TrueCrypt 形式で新規作成しない。TrueCrypt 資産を常用しない。既存資産は読めるうちに cryptsetup で確認する。必要なデータを LUKS 側へ段階移行する。移行困難なものは、ハッシュ値、手順、検証日、保管媒体、複製先を記録したうえで、読み取り専用アーカイブとして凍結する。削除は急がない。LUKS 側のバックアップと復元確認が終わるまで、TrueCrypt 側は旧資産として残す。この方針なら、TrueCrypt を過剰に恐れず、過剰に信頼せず、既存暗号データ資産を現実的に扱える。

結論として、TrueCrypt 7.1a 資産は、捨てるべき危険物ではなく、使い続けるべき現役基盤でもない。過去に作られたレガシー暗号資産として、読めるうちに確認し、記録し、LUKS へ移し、必要に応じて凍結保管する対象である。この整理に立てば、TrueCrypt の監査結果、VeraCrypt の互換性削除、cryptsetup の TCRYPT 対応、LUKS への移行、長期保全の年数見積もりは、すべて一つの方針に収束する。すなわち、暗号の強さを信じ続けるのではなく、復元可能性を設計することで既存暗号データ資産を守る、という方針である。

参考文献

1. id774, LUKS 暗号化の手順と運用（2026-05-11）. https://blog.id774.net/entry/2026/05/11/4746/
2. id774, バックアップとは復元可能性を設計することである（2026-05-07）. https://blog.id774.net/entry/2026/05/07/4728/
3. id774, バックアップ・リカバリー戦略における物理媒体管理（2026-05-10）. https://blog.id774.net/entry/2026/05/10/4743/
4. id774, 未来の自分に意味を残す（2026-05-12）. https://blog.id774.net/entry/2026/05/12/4750/
5. TrueCrypt, TrueCrypt License Version 3.0. https://www.truecrypt.org/docs/license
6. TrueCrypt, Source Code. https://www.truecrypt.org/sourcecode
7. NCC Group, iSEC Completes TrueCrypt Audit. https://www.nccgroup.com/research/isec-completes-truecrypt-audit/
8. Schneier on Security, Auditing TrueCrypt. https://www.schneier.com/blog/archives/2014/04/auditing_truecr.html
9. Matthew Green, Another update on the Truecrypt audit. https://blog.cryptographyengineering.com/2015/02/18/another-update-on-truecrypt-audit/
10. NCC Group Cryptography Services, Truecrypt Phase Two Audit Announced. https://cryptoservices.github.io/blog/2015-02-18-truecrypt-phase-two/
11. Open Crypto Audit Project, TrueCrypt Phase II NCC OCAP final report. https://pentestreports.com/files/reports/isec-partners/TrueCrypt_Phase_II_NCC_OCAP_final.pdf
12. SecurityWeek, TrueCrypt Not Plagued by Backdoors, Severe Design Flaws. https://www.securityweek.com/truecrypt-not-plagued-backdoors-severe-design-flaws-auditors/
13. Schneier on Security, TrueCrypt Security Audit Completed. https://www.schneier.com/blog/archives/2015/04/truecrypt_secur.html
14. NIST, FIPS 197 Advanced Encryption Standard. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf
15. NIST, SP 800-38E Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. https://csrc.nist.gov/pubs/sp/800/38/e/final
16. IETF, RFC 8018 PKCS #5: Password-Based Cryptography Specification Version 2.1. https://datatracker.ietf.org/doc/html/rfc8018
17. Daniel J. Bernstein, Cache-timing attacks on AES. https://cr.yp.to/antiforgery/cachetiming-20050414.pdf
18. VeraCrypt, TrueCrypt Support. https://veracrypt.io/en/TrueCrypt%20Support.html
19. VeraCrypt, Converting TrueCrypt Volumes & Partitions. https://veracrypt.io/en/Converting%20TrueCrypt%20volumes%20and%20partitions.html
20. VeraCrypt GitHub Releases. https://github.com/veracrypt/VeraCrypt/releases
21. Linux man-pages, cryptsetup(8). https://man7.org/linux/man-pages/man8/cryptsetup.8.html
22. Debian manpages, cryptsetup-open(8). https://manpages.debian.org/testing/cryptsetup-bin/cryptsetup-open.8.en.html
23. TrueCrypt 7.1a documentation, Hidden Volume. https://www.truecrypt71a.com/documentation/plausible-deniability/hidden-volume/
24. TrueCrypt 7.1a documentation, TrueCrypt Volume Format Specification. https://www.truecrypt71a.com/documentation/technical-details/truecrypt-volume-format-specification/
25. Arch Linux man pages, cryptsetup-tcryptDump(8). https://man.archlinux.org/man/cryptsetup-tcryptDump.8.en
26. Linux Kernel Documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
27. cryptsetup project, FAQ. https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md
28. BSI, Security Evaluation of VeraCrypt. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Veracrypt/Veracrypt.pdf?__blob=publicationFile&v=1