長期運用では、保存したものがそのまま未来に届くわけではない。媒体は劣化し、 OS は更新され、暗号方式の標準は変わり、ファイルシステムの適性も変化し、かつて当然だった作業手順や判断理由は時間とともに失われる。暗号化ディスクは、作成した瞬間には確かに存在していても、数年後、十数年後に同じ意味で復元できるとは限らない。したがって、保存の本質は、物理的なデータを残すことだけではなく、未来の時点でそのデータを正しく取り出し、意味のある状態へ戻せる条件を残すことにある。この問題は、暗号化ディスクではさらに厳しく現れる。データ本体が残っていても、暗号化方式、 LUKS ヘッダー、 key slot、パスフレーズ、 keyfile、対応ソフトウェア、マウント手順、媒体の役割が失われれば、データは存在していても復元できない[1]。
暗号化ディスクは、単に暗号化した領域を作る作業ではない。媒体を紛失しても第三者に読ませないことと、正当な利用者が将来必要な時点で確実に開けることを同時に満たす運用である。この二つの要請は、しばしば緊張関係にある。暗号化は、第三者からデータを守るために復号条件を厳しくする。一方、システムディスク、データディスク、バックアップ媒体はいずれも、障害時、移行時、復旧時に確実に開けることを要求する。つまり、暗号化ディスクでは、守るための条件と戻すための条件を同時に管理しなければならない。 LUKS ヘッダー、 key slot、 KDF、パスフレーズ、ヘッダーバックアップ、媒体台帳、復元テスト、退役条件は、いずれもこの両立のために必要になる。
暗号化ディスクの長期運用では、物理媒体を単なる保存先ではなく、復元可能性を維持する運用対象として扱う必要がある。媒体の状態、 S.M.A.R.T.、読み取り検証、退役基準、暗号化と鍵管理、復元テストは、それぞれ別個の確認項目である。暗号化ディスクでは、これに加えて、暗号形式、鍵導出方式、ヘッダー、解除手順、ソフトウェア互換性が重なる。非暗号化のディスクであれば、ファイルシステムの一部が読めるだけでも救出できる場合がある。しかし、暗号化ブロックデバイスでは、ヘッダーや解除条件が破綻すると、データ本体全体へ到達できなくなることがある。したがって、暗号化ディスクは「保存済みデータ」ではなく、「将来開ける条件を伴った保存状態」として管理しなければならない[2]。
この問題は、長期運用された環境では具体的な形で現れる。 2014 年頃に作成した LUKS1 のシステムディスク領域、近年作成した LUKS2 媒体、過去に使っていた TrueCrypt 資産、 FAT で保持された旧バックアップ、 ext4 へ移行した新バックアップ、性能差の大きい 2.5-inch HDD や SSD が、同じ運用体系の中に併存する。表面上は、 LUKS1 と LUKS2 の混在、 CBC-ESSIV と XTS の違い、 PBKDF2 と Argon2id の違い、 TrueCrypt と LUKS の違いとして見える。しかし本質的には、長期運用によって暗号化ディスクに時間の層ができ、過去の標準と現在の標準が同じ復元体系の中で重なっているという問題である。
すでに LUKS の手順と運用、 TrueCrypt 資産の保全、 2.5-inch HDD における LUKS + ext4 の性能問題は別稿で整理してきた。そこでは、 LUKS は作成して終わりではなく、ヘッダーバックアップ、媒体台帳、復元確認までを含む運用であること、 TrueCrypt は新規採用ではなく既存資産の保全対象として扱うべきこと、さらに同じ LUKS + ext4 でも媒体ごとに性能適性が異なることを確認した[3][4][5]。本稿では、これらをさらに一段深く掘り、 LUKS1 / LUKS2、 CBC-ESSIV / XTS、 PBKDF2 / Argon2id、 TrueCrypt 7.1a の技術差を詳しく整理したうえで、暗号化ディスクをどのようにライフサイクル管理すべきかを論じる。
本稿の中心命題は、暗号化ディスクのレジリエンスとは、古い構成を単純に消すことではなく、古い構成の意味を確定し、必要な期間だけ管理し、役割が終わった時点で退役させる能力だということである。新規主系は現行標準へ寄せるべきである。しかし、古い LUKS1 領域や TrueCrypt 旧資産には、過去の復元経路、移行元、互換バックアップ、比較元としての意味が残っている場合がある。逆に、古い媒体を無期限に残せば、解除条件不明、媒体劣化、保守終了ソフトウェア、用途不明 key slot、退役不能な暗号化資産が増える。本稿では、暗号方式の技術差を出発点にしながら、最終的には、主系、副系、互換バックアップ、移行元、読み取り中心アーカイブ、退役候補を分けて管理するための運用設計へ接続する。
1. 長期運用では暗号化ディスクにも時間の層ができる
長期運用されたサーバーでは、同じ環境の中に異なる時期の標準が混在する。あるディスク領域は 2014 年頃に LUKS1 と AES-CBC-ESSIV で作成され、別の媒体は近年の cryptsetup によって LUKS2 と AES-XTS で作成される。これは設定ミスとは限らない。むしろ、 10 年以上の運用では自然に発生する。作成した時点では妥当だった構成が、時間の経過によってレガシーになるからである。ここでいうレガシーとは、直ちに破られるという意味ではなく、現在の新規主系としては選びにくくなった構成という意味である。長期運用では、このようなレガシー構成を発見すること自体よりも、それをどの役割に置き、どの条件で維持し、どの条件で退役させるかが問題になる。
この現象は、過去の既稿とも直接つながる。 2014 年の記事では、 Linux カーネルの dm-crypt と cryptsetup を使い、 aes-cbc-essiv:sha256 と 256 bit 鍵で暗号化領域を作成し、その上に ext4 ファイルシステムを構築する手順が示されている[6]。当時の手順としては自然だった構成が、 2026 年時点で見ると LUKS1、 CBC-ESSIV、 PBKDF2 という旧世代の構成に見える。この差は、当時の判断が誤っていたことを示すのではない。むしろ、暗号化ディスクは作成時点の標準を固定したまま残り、周囲の OS、 cryptsetup、推奨 KDF、暗号モード、媒体性能、復旧手順だけが更新されていくことを示している。
暗号化ディスクに時間の層ができるとは、単に古いディスクと新しいディスクが並んでいるという意味ではない。媒体の中には、作成時点の暗号形式、暗号モード、鍵導出方式、ファイルシステム、パスフレーズ管理、ヘッダー構造、復旧手順が封じ込められている。 LUKS1 領域には、当時の cryptsetup の既定値や運用判断が残る。 LUKS2 媒体には、現在の Argon2id、 JSON メタデータ、 token や segment を扱える拡張可能な構造が残る。 TrueCrypt 旧媒体には、保守終了したソフトウェアの形式と、過去の互換性や FAT 運用の制約が残る。つまり、暗号化ディスクはデータだけでなく、その時点の技術的前提も保存してしまう。
| 観点 | 古い媒体 | 新しい媒体 | 読み取り方 |
|---|---|---|---|
| コンテナ形式 | LUKS1 で作成されている。 | LUKS2 で作成されている。 | 作成時期によって、 cryptsetup の既定形式が異なる。 |
| データ暗号化 | AES-CBC-ESSIV が使われている。 | AES-XTS が使われている。 | ディスク暗号化における標準的なモード選択が変化している。 |
| 鍵導出 | PBKDF2 が使われている。 | Argon2id が使われている。 | パスフレーズ攻撃への対抗方法が、時間コスト中心からメモリコストも含む設計へ移っている。 |
| 復元条件 | 古い cryptsetup、古い手順、古いヘッダー保全方針に依存している場合がある。 | 現在の OS と cryptsetup で扱いやすいが、将来も同じとは限らない。 | 暗号方式だけでなく、解除条件、ヘッダー、手順、対応ソフトウェアを含めて見る必要がある。 |
| 運用上の意味 | レガシーだが、直ちに危険とは限らない。 | 現行標準として主系にしやすい。 | 古い構成を即廃棄せず、役割を分類して管理する必要がある。 |
ここで重要なのは、古い構成を見つけたときに、単純に危険だと決めつけないことである。古い構成には、過去の標準、過去の復旧環境、過去のバックアップ履歴が含まれている。古い LUKS1 領域は、新規主系として増やすべきではないとしても、移行元、互換バックアップ、過去世代の参照元として価値を持つ場合がある。 TrueCrypt 旧媒体も、新規採用すべきではないとしても、既存資産の読み出し経路として確認すべき場合がある。一方で、古い構成を無制限に主系として残せば、いずれ管理不能になる。解除条件が記憶頼みになり、 key slot の意味が不明になり、媒体が劣化し、対応ソフトウェアが減り、退役条件も分からなくなるからである。
したがって、長期運用では、暗号化ディスクを作成時点の優劣だけで評価してはならない。評価すべきなのは、その媒体または領域が現在どの役割を持ち、実際に開けるか、読み取れるか、復元できるか、現行主系との関係が明確か、退役条件があるかである。 LUKS1 と LUKS2 の併存は、表面上は形式の違いである。しかし、その背後には、時間の経過によって標準が移動し、媒体だけが過去の前提を保持し続けるという構造がある。この構造を理解しないまま最新方式へ一括置換すると、復元経路を失う危険がある。逆に、古い媒体を何となく残し続けると、管理不能な暗号化資産が増える。必要なのは、古い構成を発見した時点で、主系、副系、互換バックアップ、移行元、読み取り中心アーカイブ、退役候補へ分類し、時間の層を管理可能な運用構造へ変えることである。
2. LUKS1 と LUKS2 は何が違うのか
LUKS は Linux Unified Key Setup の略であり、 Linux における暗号化ブロックデバイスの鍵管理形式である。ここで最初に分けるべきなのは、暗号化処理そのものと、その暗号化処理を安全に運用するための管理形式である。実際にディスクの読み書き時に暗号化と復号を行うのは、 Linux カーネル側の dm-crypt である。一方、 cryptsetup は、 LUKS ヘッダー、 key slot、パスフレーズ、鍵導出、デバイスマッピング、ヘッダーバックアップなどを扱うユーザー空間の管理ツールである。 Linux カーネルの dm-crypt 文書でも、 dm-crypt は block device の透過的暗号化を提供し、暗号指定は cipher、chain mode、 IV generator の組み合わせとして扱われると説明されている[7]。cryptsetup プロジェクトは、この dm-crypt と LUKS を利用するための主要なユーザー空間ツールである[8]。
この分離を理解しないと、 LUKS1 と LUKS2 の違いを誤読しやすい。 LUKS1 と LUKS2 は、 AES-CBC や AES-XTS そのものの違いではない。暗号化データ本体をどの暗号モードで守るかは、 LUKS 形式とは別に指定される。 LUKS1 でも AES-XTS を使うことはでき、 LUKS2 でも理論上は別の暗号指定を選べる。したがって、 LUKS1 / LUKS2 の違いは、主に「暗号化コンテナのメタデータ形式」「 key slot の扱い」「 KDF の選択肢」「将来拡張性」「復旧性」「管理情報の表現方法」の違いとして見る必要がある。
| 層 | 役割 | 具体例 | 誤解しやすい点 |
|---|---|---|---|
| dm-crypt | カーネル内でブロックデバイスの暗号化と復号を実行する。 | AES-CBC-ESSIV や AES-XTS によるデータ本体の暗号化を担う。 | LUKS ヘッダー管理そのものを行う仕組みではない。 |
| cryptsetup | LUKS デバイスの作成、解除、 key slot 管理、ヘッダーバックアップなどを行う。 | luksFormat、 luksOpen、 luksDump、 luksHeaderBackup などの操作を提供する。 | データ読み書き時の暗号化処理そのものを毎回ユーザー空間で実行しているわけではない。 |
| LUKS ヘッダー | 暗号方式、 UUID、 key slot、 KDF 情報など、復号に必要な管理情報を保持する。 | LUKS1 では固定的なヘッダー構造、 LUKS2 では JSON メタデータを含む構造になる。 | ヘッダーが壊れると、データ本体が残っていても復号不能になり得る。 |
| key slot | 同じボリュームキーを複数のパスフレーズや解除手段で保護する入口である。 | 複数の key slot が有効なら、複数のパスフレーズで同じ暗号化領域を開ける。 | key slot ごとに別のデータが暗号化されているわけではなく、同じボリュームキーへの入口が複数ある。 |
| データ領域 | 実際のファイルシステムやデータが暗号化された状態で保存される領域である。 | ext4、 XFS、 FAT などのファイルシステムは、 LUKS を開いた後のブロックデバイス上に作られる。 | LUKS 形式とファイルシステム形式は別の層であり、 LUKS2 だから ext4 になるわけではない。 |
2.1 LUKS はパスフレーズでデータを直接暗号化しているわけではない
LUKS の重要な設計は、パスフレーズでデータ本体を直接暗号化しないことである。データ本体は、ランダムに生成されたボリュームキー、またはマスターキーと呼ばれる鍵で暗号化される。パスフレーズは、このボリュームキーを取り出すための key slot を開く材料として使われる。つまり、パスフレーズから KDF によって key slot 用の鍵を作り、その鍵で key slot 内に保護されているボリュームキーを復号し、そのボリュームキーでデータ本体を復号する、という段階構造になっている。
この構造により、パスフレーズを変更してもディスク全体を再暗号化する必要がない。変更されるのは、ボリュームキーそのものではなく、ボリュームキーを包んでいる key slot 側である。したがって、複数のパスフレーズを登録したり、古いパスフレーズを削除したり、緊急用の解除経路を用意したりできる。一方で、弱いパスフレーズが登録された key slot が残っていれば、強いパスフレーズも同じボリュームを守っているから安全だ、とは言えなくなる。攻撃者は最も弱い入口を攻撃すればよいからである。
| 要素 | 何を守るか | 運用上の意味 |
|---|---|---|
| ボリュームキー | データ本体を暗号化する中心の鍵である。 | 通常のパスフレーズ変更では、データ本体の鍵そのものは変わらない。 |
| パスフレーズ | key slot を開くための入力である。 | 弱いパスフレーズが残ると、その key slot が攻撃対象になる。 |
| KDF | パスフレーズから key slot を開くための鍵材料を作る。 | PBKDF2 や Argon2id の設定が、オフライン攻撃への耐性に影響する。 |
| key slot | ボリュームキーを別々の解除手段で保護する。 | 不要な key slot は管理対象であり、残し続けるほど入口が増える。 |
| LUKS ヘッダー | key slot や暗号化設定を含む復号の入口である。 | ヘッダーを失うと、ボリュームキーへ到達できず、データ本体が残っていても復旧できない。 |
2.2 LUKS1 は固定的で単純なオンディスク形式である
LUKS1 は、長く使われてきた従来形式であり、固定的なオンディスク形式を持つ。 LUKS1 の仕様書は、マスターキー、 anti-forensic split、 key slot、 payload offset などを明示し、複数のパスフレーズで同じマスターキーを解除する構造を定義している[9]。この形式では、ヘッダー、 key slot、暗号化データ領域の関係が比較的単純であり、古い環境でも扱いやすい。長期運用の観点では、この単純さは互換性の利点になる。
一方で、 LUKS1 の単純さは、将来拡張性の制約にもなる。 LUKS1 は基本的に PBKDF2 を前提にしており、 Argon2id のような現代的なメモリハード KDF を自然に扱う形式ではない。また、トークン連携、メタデータ冗長化、より柔軟なセグメント管理、将来拡張を表現するには構造が硬い。つまり、 LUKS1 は「古いから直ちに危険」なのではなく、「長く安定して使われたが、現在の要求を表現するには拡張性が不足する形式」と見るべきである。
今回確認された古い媒体では、 Version が 1、 Cipher name が aes、 Cipher mode が cbc-essiv:sha256、 Hash spec が sha256、 Payload offset が 4096 と表示されていた。この出力は、 LUKS1 形式のヘッダーがあり、データ本体の開始位置が 4096 セクター分だけ後ろに置かれ、 AES-CBC-ESSIV で暗号化されていることを示している。さらに Key Slot 0 から Key Slot 3 までが有効な媒体では、同じ暗号化データ領域に到達できる入口が 4 つ存在する。これは便利である一方、不要な入口が残っていないかを確認すべき状態でもある。
2.3 LUKS2 はメタデータを拡張可能にした形式である
LUKS2 は、 LUKS1 の固定構造を拡張するために導入された形式である。 LUKS2 の仕様では、 JSON ベースのメタデータ、 keyslot、 segment、 digest、 token などの構造が導入される[10]。これにより、暗号化データ領域をどの segment として扱うか、どの keyslot がどの digest に対応するか、どの token が解除手段として関与するか、といった管理情報を柔軟に表現できる。これは単に見た目が複雑になったという話ではなく、暗号化ボリュームを長期に管理するための情報表現能力が増えたということである。
cryptsetup 2.0.0 のリリースノートは、 LUKS2 を新しいオンディスク形式として導入し、従来形式を LUKS1 と呼びつつ、後方互換形式としてサポートすると説明している[11]。さらに cryptsetup 2.1.0 以降では、 LUKS2 が既定形式として扱われる流れが強まった[12]。この流れは、 LUKS1 が突然使えなくなったことを意味しない。むしろ、既存の LUKS1 を読み書きできる互換性を維持しながら、新規作成の標準を LUKS2 へ移したという理解が適切である。
今回確認された新しい媒体では、 Version が 2、 Metadata area が 16384 bytes、 Keyslots area が 16744448 bytes、 Data segments の offset が 16777216 bytes と表示されていた。また、 keyslot には luks2、 PBKDF は argon2id、 Time cost、 Memory、 Threads が表示されていた。この出力は、 LUKS2 が単に暗号方式を変えたのではなく、 key slot の KDF パラメーター、メタデータ領域、データセグメント、 digest などをより構造的に管理していることを示している。
| 表示項目 | LUKS1 での意味 | LUKS2 での意味 | 読み取り方 |
|---|---|---|---|
| Version | 1 と表示され、従来の固定形式であることを示す。 | 2 と表示され、拡張可能なメタデータ形式であることを示す。 | まずここで LUKS1 と LUKS2 を判別する。 |
| Cipher mode | cbc-essiv:sha256 のように、暗号モードと IV 生成方式が表示される。 | Data segments 内に aes-xts-plain64 のような暗号方式が表示される。 | LUKS 形式とデータ暗号化方式は別に読む必要がある。 |
| Payload offset | 暗号化データ本体がどこから始まるかを示す。 | Data segments の offset として、データ領域の開始位置が示される。 | ヘッダーと key slot 領域の後ろにデータ本体が置かれる。 |
| Key Slot | Key Slot 0 から 7 までの有効または無効状態が表示される。 | Keyslots として keyslot ごとの KDF、優先度、領域、 digest 対応が表示される。 | 解除入口がいくつあるか、どの KDF で守られているかを確認する。 |
| KDF 情報 | PBKDF2 の iteration が key slot ごとに表示される。 | Argon2id の time cost、 memory、 threads などが表示される。 | パスフレーズ攻撃への耐性を見るための重要情報である。 |
| Tokens | 基本的に LUKS1 の中心機能ではない。 | 外部解除手段やシステム連携を表現するために使える。 | 自動解除や TPM 連携など、将来拡張や運用統合に関わる領域である。 |
| Digests | マスターキー確認用の情報が固定的に扱われる。 | keyslot とボリュームキーの対応確認に使われる digest が構造化される。 | 正しい key slot から正しいボリュームキーへ到達できるかを確認するための仕組みである。 |
2.4 LUKS2 の利点は暗号方式の新しさだけではない
LUKS2 の利点は、 AES-XTS や Argon2id を使えることだけではない。むしろ、長期運用で重要なのは、メタデータを構造化し、拡張可能にし、破損検出や冗長化を含めて管理できる点である。 Red Hat の LUKS 文書も、 LUKS2 では JSON メタデータ、メタデータ冗長化、破損検出、自動修復などが導入され、 LUKS1 より管理性が高まっていることを説明している[13]。つまり、 LUKS2 は単に「新しい暗号方式を使う形式」ではなく、「暗号化ボリュームをより長く管理するための形式」として理解すべきである。
ただし、 LUKS2 だから常に安全という理解も誤りである。 LUKS2 でも、弱いパスフレーズを使えば弱い。不要な key slot が残れば入口が増える。ヘッダーバックアップを取らなければ、メタデータ破損時の復旧性は下がる。 XTS は機密性を提供するが、通常構成では改ざん検出を提供しない。したがって、 LUKS2 は現行標準として自然だが、それ自体が運用設計を不要にするわけではない。
| 観点 | LUKS1 | LUKS2 | 長期運用での判断 |
|---|---|---|---|
| 位置付け | 従来の安定形式であり、既存媒体として残りやすい。 | 現在の拡張可能な標準形式であり、新規作成に向く。 | 既存 LUKS1 は分類して管理し、新規主系は LUKS2 に寄せる。 |
| メタデータ | 固定的で単純な構造を持つ。 | JSON ベースの拡張可能な構造を持つ。 | 復旧手順の単純さでは LUKS1、将来拡張性では LUKS2 に利点がある。 |
| key slot | 最大 8 個の key slot を持つ固定的な構造である。 | keyslot、 digest、 token などと結びついた柔軟な構造である。 | 不要な key slot を残さず、解除入口を台帳化する必要がある。 |
| KDF | 基本的に PBKDF2 を使う。 | PBKDF2 に加えて Argon2i や Argon2id を使える。 | パスフレーズ攻撃耐性を考えるなら、現行主系では Argon2id を優先しやすい。 |
| データ暗号化 | 古い媒体では AES-CBC-ESSIV が残りやすいが、形式としての LUKS1 と暗号モードは別である。 | 現在の新規作成では AES-XTS が標準的に使われることが多い。 | LUKS バージョンだけで安全性を判断せず、実際の cipher と mode を確認する。 |
| 復旧性 | 古い環境との互換性が高く、構造が単純である。 | メタデータ冗長化や破損検出などの改善がある。 | ヘッダーバックアップと復元テストがなければ、どちらも復旧性は不十分である。 |
| レジリエンス上の役割 | 互換バックアップや読み取り中心アーカイブとして意味を持ち得る。 | 主系バックアップや新規媒体の標準構成として意味を持つ。 | 新旧を単純に優劣で消すのではなく、役割を分けて管理する。 |
2.5 ひとくくりに LUKS と呼んでよい場合と、分けるべき場合がある
日常的な説明では、 LUKS1 と LUKS2 をまとめて LUKS と呼んでよい。どちらも Linux における暗号化ブロックデバイスの代表的な鍵管理形式であり、 cryptsetup で扱われ、 dm-crypt の上に成立するからである。しかし、運用設計、復旧設計、暗号強度評価、長期保全、移行判断を行う場合は、 LUKS1 と LUKS2 を分けなければならない。 LUKS1 は固定的で互換性が高い一方、 PBKDF2 前提で拡張性に限界がある。 LUKS2 は拡張性が高く、 Argon2id や token などを扱いやすい一方、メタデータ構造が複雑であり、対応する cryptsetup や復旧環境を前提にする。
cryptsetup の luksFormat man page でも、 LUKS1 と LUKS2 は明示的に指定可能であり、現在の通常運用では LUKS2 を前提に扱うのが自然である[14]。ただし、長期運用では「自然である」と「旧形式を即廃棄すべきである」は同じではない。古い LUKS1 媒体は、新規主系として増やすべきではないが、過去のバックアップ状態を保持する互換バックアップとして価値を持つ場合がある。逆に、 LUKS2 媒体は現行標準として主系に向くが、それも将来はレガシー化する。したがって、 LUKS1 / LUKS2 の違いを理解する目的は、新旧の単純な勝敗を決めることではなく、媒体ごとの役割、点検周期、移行条件、退役条件を正しく設計することにある。
3. CBC-ESSIV は CBC をディスク向けに補強した旧来の実用構成である
古い LUKS1 媒体で見られる aes-cbc-essiv:sha256 は、 AES を CBC モードで使い、 ESSIV と SHA-256 によってセクターごとの IV を生成する構成である。この表記は、ひとつの暗号方式名ではなく、複数の要素を組み合わせた指定である。 aes はブロック暗号として AES を使うことを示し、 cbc は AES を CBC モードで使うことを示し、 essiv はディスクのセクター番号から IV を作る方式を示し、 sha256 は ESSIV の内部で鍵由来の値を作るために SHA-256 を使うことを示している。つまり、 aes-cbc-essiv:sha256 は、 AES、 CBC、 ESSIV、 SHA-256 という複数の部品を組み合わせ、ディスク暗号化の制約に合わせた実用構成である。
ここで最初に理解すべきなのは、 AES そのものは「大きなファイルやディスク全体をそのまま暗号化する仕組み」ではないという点である。 AES はブロック暗号であり、固定長のブロックを鍵で暗号化する部品である。一般的には 16 byte、つまり 128 bit の単位で入力ブロックを暗号化する。ディスクには、数 GB、数 TB のデータが保存されるため、 AES という部品だけでは、巨大なデータをどの順番で、どの単位で、どのように暗号化するかは決まらない。そこで必要になるのが、 CBC や XTS のようなブロック暗号モードである。
| 表記要素 | 意味 | ディスク暗号化での役割 |
|---|---|---|
| aes | ブロック暗号として AES を使うことを示す。 | データを暗号化する基本部品になる。 |
| cbc | AES を CBC モードで使うことを示す。 | 複数のブロックを連鎖させて暗号化する。 |
| essiv | セクター番号から IV を作る方式を示す。 | ディスク上の固定位置に対して予測しにくい IV を与える。 |
| sha256 | ESSIV の内部で SHA-256 を使うことを示す。 | 鍵由来の値を作り、セクター番号をそのまま IV にしないために使われる。 |
3.1 CBC は前の暗号文を次のブロックに混ぜる方式である
CBC は Cipher Block Chaining の略であり、前の暗号文ブロックを次の平文ブロックに混ぜてから暗号化する方式である。単純な説明をすると、 1 個目の平文ブロックを暗号化して 1 個目の暗号文ブロックを作り、その暗号文ブロックを 2 個目の平文ブロックに混ぜてから 2 個目を暗号化し、さらにその結果を 3 個目に混ぜる、という形で処理が連鎖する。この「前の結果を次に混ぜる」という性質によって、同じ平文ブロックが続いていても、単純に同じ暗号文ブロックが並ぶことを避けられる。
ただし、最初のブロックには前の暗号文ブロックが存在しない。そのため、最初のブロックには IV、つまり初期化ベクトルを混ぜる。 IV は秘密鍵ではないが、同じ鍵と同じ平文から毎回同じ暗号文が出ることを避けるために重要である。通常のメッセージ暗号化では、メッセージごとにランダムな IV を生成し、その IV を暗号文と一緒に保存できる。しかし、ディスク暗号化ではこの前提がそのまま使えない。
| 要素 | CBC での役割 | 説明上の注意点 |
|---|---|---|
| 平文ブロック | 暗号化前の固定長データ単位である。 | AES では通常 16 byte 単位で扱われる。 |
| 暗号文ブロック | 暗号化後の固定長データ単位である。 | CBC では前の暗号文ブロックが次の暗号化に影響する。 |
| 連鎖 | 前の暗号文を次の平文に混ぜる構造である。 | 同じ平文ブロックが単純に同じ暗号文ブロックへ出ることを避ける。 |
| IV | 最初のブロックに混ぜる初期値である。 | 最初のブロックには前の暗号文がないため、 IV が必要になる。 |
3.2 ディスク暗号化では IV を保存しにくい
ディスク暗号化で CBC を使う場合、最大の問題は IV の扱いである。通常のファイル暗号化やメッセージ暗号化では、暗号化対象ごとにランダムな IV を作り、それを暗号文の先頭やメタデータに保存できる。しかし、ディスクは固定長のセクターを読み書きする装置であり、あるセクターを暗号化するたびに、そのセクター専用のランダム IV を別領域へ保存する設計は扱いにくい。ディスク上の各セクターは、何度も上書きされ、任意の順番で読み書きされるからである。
さらに、ディスク暗号化ではランダムアクセス性が必要である。ファイルの先頭から順番にすべて読まなければ途中を復号できない方式では、ブロックデバイスとして使いにくい。 OS は、必要なセクターだけを読み、必要なセクターだけを書き込む。そのため、各セクターは独立に暗号化・復号できなければならない。 CBC は本来、前のブロックとの連鎖を使うが、ディスク全体をひとつの長大な CBC チェーンにしてしまうと、途中のセクターだけを効率よく読み書きできなくなる。そこで、ディスク暗号化では、セクターごとに独立した単位として CBC を適用する必要がある。
| 制約 | 通常の暗号化 | ディスク暗号化 |
|---|---|---|
| IV 保存 | メッセージごとにランダム IV を保存しやすい。 | セクターごとにランダム IV を別途保存する余地が基本的にない。 |
| 読み書き順序 | 先頭から順番に処理してもよい場面が多い。 | 任意のセクターを単独で読み書きできなければならない。 |
| 上書き | メッセージ全体を作り直して保存し直せる場合がある。 | 同じセクターが何度も上書きされる。 |
| メタデータ | 暗号文に IV や認証タグを付けやすい。 | ブロックデバイスの見かけ上のサイズや配置を大きく変えにくい。 |
この制約のため、古いディスク暗号化では、セクター番号を使って IV を決める発想が使われた。セクター番号は、ディスク上の位置を表す値であり、同じセクターであれば同じ番号になる。これを使えば、 IV を別途保存しなくても、復号時に同じ IV を再計算できる。しかし、セクター番号をそのまま IV にすると、攻撃者にも予測可能な値になる。ここに CBC のディスク暗号化における難しさがある。
3.3 ESSIV は予測可能なセクター番号をそのまま IV にしないための工夫である
ESSIV は Encrypted Salt-Sector IV の略であり、セクター番号から予測困難な IV を作るための仕組みである。考え方は、セクター番号をそのまま IV にするのではなく、鍵から導いた値でセクター番号を暗号化し、その結果を IV として使う、というものである。これにより、同じセクター番号から常に同じ IV を再計算できる一方、攻撃者から見ると IV の値は単純なセクター番号には見えなくなる。
ESSIV で SHA-256 が出てくるのは、セクター番号そのものをハッシュするためではない。 ESSIV では、暗号鍵から IV 生成用の鍵材料を作る必要がある。その鍵由来の値を作るために SHA-256 が使われる。したがって、 aes-cbc-essiv:sha256 の sha256 は、データ本体を SHA-256 で暗号化するという意味ではない。 SHA-256 は暗号化モードの補助要素であり、 ESSIV の IV 生成に関与する。
| 段階 | 処理 | 目的 |
|---|---|---|
| 鍵由来値の作成 | 暗号鍵から SHA-256 などを使って IV 生成用の値を作る。 | セクター番号をそのまま IV にしないための鍵依存要素を用意する。 |
| セクター番号の変換 | 鍵由来の値を使ってセクター番号を暗号化する。 | 予測可能なセクター番号を、予測しにくい IV へ変換する。 |
| IV として利用 | 変換結果を CBC の IV として使う。 | 各セクターの先頭ブロックが単純な位置情報に依存して露出することを避ける。 |
| 復号時の再計算 | 同じ鍵と同じセクター番号から同じ IV を再計算する。 | IV をディスク上に別途保存せずに復号できる。 |
この設計は、ディスク暗号化における実用上の制約に対する回答である。ランダム IV をセクターごとに保存できない。セクターは任意の順番で読み書きされる。復号時には同じ IV を再計算できなければならない。セクター番号をそのまま使うと予測可能になる。 ESSIV は、これらの条件を同時に満たすために、セクター番号を鍵依存の処理で変換してから IV として使う。
3.4 CBC-ESSIV は当時の合理的な実用解だった
CBC-ESSIV は、現在の視点から見ると旧来の構成である。しかし、それは当時の設計として不合理だったという意味ではない。むしろ、 CBC という広く使われたブロック暗号モードを、ディスク暗号化のランダムアクセス性、固定位置性、 IV 保存困難性に合わせて補強した構成である。 LUKS1 時代の aes-cbc-essiv:sha256 は、ディスク暗号化で CBC を使う場合の現実的な選択肢だった。
この点を誤ると、古い媒体の評価を間違える。 CBC-ESSIV は、単純な CBC や単純なセクター番号 IV よりも、ディスク暗号化の問題をよく意識した構成である。古い LUKS1 媒体に aes-cbc-essiv:sha256 が残っていることは、単に雑な暗号設定が使われていたことを意味しない。むしろ、その時点の Linux 暗号化運用で妥当とされた構成が、長期運用の中で残っていると読むべきである。
| 評価軸 | CBC-ESSIV の意味 | 現在の判断 |
|---|---|---|
| 当時の合理性 | CBC をディスク暗号化に適用するために IV 生成を補強した。 | 過去の標準的な実用構成として理解する。 |
| 現在の新規採用 | ストレージ専用モードとして設計された XTS より古い設計である。 | 新規媒体では基本的に XTS を選ぶ。 |
| 既存媒体 | 強いパスフレーズと適切な key slot 管理があれば、直ちに破綻した構成とは限らない。 | 主系ではなく、互換バックアップや移行対象として分類する。 |
| 運用上の注意 | 暗号モードだけでなく、 KDF、 key slot、ヘッダー、媒体劣化も合わせて見る必要がある。 | luksDump の結果を台帳化し、役割と退役条件を決める。 |
3.5 CBC-ESSIV にも限界がある
CBC-ESSIV は、 CBC をディスク向けに補強した方式であるが、ストレージ暗号化専用に設計された方式ではない。 CBC は本来、ブロックを連鎖させることでメッセージを暗号化する汎用的なモードであり、ディスク上の位置情報を暗号化処理の中心に据えた方式ではない。 ESSIV はセクター番号から IV を作る問題をかなり改善するが、それでも設計の出発点は「 CBC をディスク用途へ適用する」ことである。
これに対して、 XTS は最初からストレージ暗号化を前提にし、セクター番号やブロック位置のような場所情報を tweak として暗号化処理に組み込む。ディスク暗号化では、データの内容だけでなく、どの場所に保存されているかも暗号化結果を変える材料になるべきである。そのため、現在の新規構成では、 CBC-ESSIV よりも XTS のほうが設計として自然である。
ただし、ここでも短絡してはならない。 CBC-ESSIV が古いから、既存媒体を即座に消すべきだという結論にはならない。重要なのは、既存の CBC-ESSIV 媒体を主系として増やさないこと、役割を互換バックアップやアーカイブへ限定すること、ヘッダーと key slot を台帳化すること、復元確認を行うこと、そして新しい媒体へ移行済みであることを確認してから退役させることである。暗号方式の世代差は、即時廃棄の理由ではなく、ライフサイクル管理の判断材料である。
4. XTS はディスク上の位置を暗号化に組み込む方式である
XTS は、ストレージ暗号化を前提に設計されたブロック暗号モードである。ここでいうストレージ暗号化とは、ファイルやメッセージを一括して暗号化する処理ではなく、 HDD、 SSD、 USB ストレージ、暗号化ボリュームのように、固定長のブロックを任意の順番で読み書きする装置を暗号化する処理である。 NIST SP 800-38E は、 XTS-AES をストレージデバイス上のデータの機密性を保護するための方式として承認している[15]。また、 XTS は IEEE Std 1619-2007 に基づく方式であり、ブロック指向ストレージデバイス上のデータ保護を対象にしている[16]。したがって、 XTS は単に CBC より新しい暗号モードというだけではなく、ディスク上の位置、ランダムアクセス、部分更新、固定サイズブロックというストレージ固有の条件を前提にした方式である。
この章で重要なのは、 XTS を「暗号強度が高い方式」とだけ理解しないことである。 XTS の本質は、ディスク上の場所を暗号化処理に組み込む点にある。ディスク暗号化では、同じ内容の 16 byte ブロックが別々の場所に存在することがある。もし暗号化処理が場所を考慮しなければ、同じ平文と同じ鍵から同じ暗号文が出る可能性がある。これは平文そのものを直接読ませるものではないが、「この場所とこの場所には同じ内容がある」「同じパターンが繰り返されている」という構造情報を漏らす。ディスク暗号化では、内容だけでなく、場所によって暗号文が変わる必要がある。
| 条件 | 通常のメッセージ暗号化 | ディスク暗号化 |
|---|---|---|
| 処理単位 | ひとつのメッセージやファイル全体を処理単位にしやすい。 | セクターやブロックを個別に読み書きする必要がある。 |
| 読み書き順序 | 先頭から末尾まで順番に処理してもよい場面が多い。 | 任意の場所だけを読み、任意の場所だけを書き換えられなければならない。 |
| 位置情報 | メッセージ全体の中での位置は暗号化方式の中心問題になりにくい。 | 同じ平文でも保存位置が違えば違う暗号文になる必要がある。 |
| メタデータ追加 | IV や認証タグを暗号文に付けやすい。 | ブロックデバイスの見かけ上のサイズやセクター配置を大きく変えにくい。 |
| 更新 | メッセージ全体を作り直して保存できる場合がある。 | 同じセクターが何度も部分的に上書きされる。 |
4.1 XTS の中心は tweak である
XTS では、ディスク上の位置情報を tweak として扱う。 tweak は、暗号鍵とは別に暗号化処理へ混ぜる値であり、同じ鍵と同じ平文でも、 tweak が違えば暗号文が変わる。ここで重要なのは、 tweak は秘密鍵ではないという点である。セクター番号やブロック位置は、秘密情報ではなく、ディスク上の場所を表す情報である。しかし、その場所情報を暗号化処理に組み込むことで、同じ平文ブロックが別の場所に保存されたときに、同じ暗号文として現れないようにできる。
通常の AES は、同じ鍵で同じ 16 byte の平文ブロックを暗号化すれば、同じ暗号文ブロックを出す。これはブロック暗号としては自然な性質である。しかし、ディスク暗号化ではこの性質がそのまま残ると困る。ディスクにはゼロ埋め領域、同一ファイルのコピー、ファイルシステムの規則的なメタデータ、空き領域のパターンなど、同じ内容や似た内容が複数の場所に現れ得るからである。 XTS は、セクター番号とセクター内のブロック位置から tweak を作り、その tweak を暗号化処理に混ぜることで、場所ごとに暗号文を変える。
| 要素 | 意味 | XTS での役割 |
|---|---|---|
| 平文ブロック | 暗号化前の 16 byte 単位のデータである。 | 同じ平文ブロックでも、保存場所によって異なる暗号文になる。 |
| 暗号鍵 | 暗号化と復号に使う秘密情報である。 | データを秘匿する中心の秘密情報である。 |
| tweak | 暗号化処理に混ぜる位置依存の値である。 | セクター番号やブロック位置に応じて暗号文を変える。 |
| セクター番号 | ディスク上の読み書き単位の位置を表す値である。 | tweak の基礎になる場所情報として使われる。 |
| ブロック位置 | セクター内の何番目のブロックかを表す位置である。 | 同じセクター内でもブロックごとに tweak を変化させるために使われる。 |
4.2 XTS は 2 系統の鍵材料を使う
XTS では、 2 系統の AES 鍵材料を使う。ひとつはデータ本体を暗号化するための鍵であり、もうひとつは tweak を生成するための鍵である。したがって、 LUKS2 の luksDump で Cipher key が 512 bits と表示される場合、それは AES そのものが 512 bit 鍵を持つという意味ではない。 AES-XTS-256 相当では、データ暗号化用の 256 bit 鍵と、 tweak 生成用の 256 bit 鍵を合わせて 512 bit の鍵材料として表示される。
この点は誤解されやすい。 AES には一般に 128 bit、 192 bit、 256 bit の鍵長がある。 AES-512 という標準的な AES 鍵長があるわけではない。 XTS で 512 bits と表示されるのは、 XTS が 2 系統の AES 鍵を使うため、合計の鍵材料が 512 bit になるという意味である。つまり、表示上の 512 bits を見て「通常の AES-256 より 2 倍強い AES-512 が使われている」と読むのは誤りである。
| 表示 | 実際の意味 | 誤読 |
|---|---|---|
| AES-XTS-128 相当 | データ暗号化用 128 bit と tweak 生成用 128 bit を合わせて 256 bit の鍵材料を使う。 | AES が 256 bit 鍵で動いていると誤解しやすい。 |
| AES-XTS-256 相当 | データ暗号化用 256 bit と tweak 生成用 256 bit を合わせて 512 bit の鍵材料を使う。 | AES-512 という方式があるように誤解しやすい。 |
| Cipher key 512 bits | XTS 全体で使う鍵材料の合計が 512 bit であることを示す。 | 単一の AES 鍵が 512 bit であるという意味ではない。 |
この 2 鍵構造は、 XTS の設計上重要である。データ暗号化と tweak 生成に同じ鍵材料をそのまま使うのではなく、役割を分けることで、データそのものを暗号化する処理と、場所ごとの差異を作る処理を分離している。ディスク暗号化では、同じデータが同じ場所に書かれた場合には同じ暗号文になり得るが、同じデータが別の場所に書かれた場合には異なる暗号文になる。この性質を実現するために、 XTS は鍵と tweak を組み合わせている。
4.3 XTS は CBC-ESSIV と何が違うのか
CBC-ESSIV と XTS は、どちらも「同じ平文が単純に同じ暗号文として現れないようにする」という問題意識を持つ。しかし、発想が異なる。 CBC-ESSIV は、 CBC という汎用的なブロック暗号モードをディスク暗号化に適用するために、セクター番号から予測しにくい IV を作る方式である。つまり、中心にあるのは CBC であり、 ESSIV は CBC をディスク向けに使いやすくする補強である。
これに対して XTS は、最初からストレージ暗号化を前提にし、場所情報を tweak として暗号化処理に組み込む。 XTS では、セクター番号とセクター内のブロック位置が暗号化結果に関与する。つまり、 XTS は「汎用モードをディスク向けに補強する」方式ではなく、「ディスク上の位置を暗号化処理の一部として扱う」方式である。この違いが、現在のディスク暗号化で XTS が第一選択になりやすい理由である。
| 観点 | CBC-ESSIV | XTS |
|---|---|---|
| 基本発想 | CBC に予測困難な IV を与えてディスク暗号化に適用する。 | セクター番号とブロック位置を tweak として暗号化に組み込む。 |
| 位置情報 | セクター番号から IV を作る。 | セクター番号とセクター内ブロック位置から tweak を作る。 |
| 鍵材料 | 主にデータ暗号化鍵を中心に使う。 | データ暗号化用と tweak 生成用の 2 系統の鍵材料を使う。 |
| 設計思想 | 汎用的な CBC をディスク向けに補強する。 | 最初からストレージ暗号化向けに設計されている。 |
| 現在の位置付け | 旧来の実用構成である。 | 現行の標準的構成である。 |
| 長期運用上の扱い | 既存媒体では互換バックアップや移行対象として扱う。 | 新規主系媒体の標準構成として扱いやすい。 |
4.4 plain64 はディスク上の位置をどう数えるかに関わる
LUKS2 の luksDump で aes-xts-plain64 と表示される場合、 aes は AES、 xts は XTS モード、 plain64 は IV または tweak の基礎になるセクター番号の扱いを示している。ここで plain64 は、セクター番号を 64 bit の値として扱う方式である。古い plain 方式では 32 bit 幅の制約が問題になる場合があり、大容量ディスクでは plain64 のほうが自然である。現代のディスクやバックアップ媒体は TB 単位であるため、位置情報を十分な幅で扱えることは重要である。
ただし、 plain64 という名前から「暗号化されていない plain な方式だから弱い」と読むのは誤りである。ここでの plain64 は、データを平文で保存するという意味ではない。セクター番号の生成方式、つまり場所情報の表現方法を示している。データ本体は AES-XTS によって暗号化される。したがって、 aes-xts-plain64 は、 AES-XTS を使い、 64 bit のセクター番号表現を tweak の基礎として使うディスク暗号化構成として読むべきである。
| 表記要素 | 意味 | 誤解しやすい点 |
|---|---|---|
| aes | ブロック暗号として AES を使う。 | これだけではディスク暗号化方式全体は決まらない。 |
| xts | ストレージ暗号化向けの XTS モードを使う。 | 機密性を守る方式であり、完全性保証までは提供しない。 |
| plain64 | セクター番号を 64 bit の位置情報として扱う。 | データを平文で保存するという意味ではない。 |
4.5 XTS は完全性を保証しない
XTS は、ストレージ上のデータを読まれにくくするための機密性の方式である。しかし、 XTS は、暗号化されたデータが改ざんされていないことを保証する方式ではない。 NIST SP 800-38E でも、 XTS-AES が提供するのはストレージデバイス上のデータの機密性であり、データや送信元の認証を提供しないことが明確にされている[15]。つまり、 XTS は「暗号文を見られても平文を読みにくくする」方式であり、「暗号文が誰にも変更されていないことを検出する」方式ではない。
この違いは運用上重要である。暗号化しているからといって、ディスク上のビットが壊れたことや、攻撃者が暗号文を改ざんしたことを、 XTS だけで確実に検出できるわけではない。通常の LUKS + XTS 構成では、ファイルシステム側の整合性、バックアップの照合、ハッシュ記録、読み取り検証、別系統のバックアップによって、実運用上の破損や改ざんに対応する必要がある。機密性と完全性は別の性質であり、暗号化ディスクではこの区別を明確にする必要がある。
| 性質 | XTS が提供するか | 運用上の補完 |
|---|---|---|
| 機密性 | 提供する。 | 暗号化により、媒体を紛失しても平文を読まれにくくする。 |
| 完全性 | 通常の XTS だけでは提供しない。 | ハッシュ、検証、ファイルシステム整合性、別系統バックアップで補う。 |
| 認証 | 提供しない。 | 暗号文が正当な作成者によるものかは別の仕組みで扱う。 |
| 破損検出 | 通常の XTS だけでは十分ではない。 | 定期的な読み取り確認、チェックサム、復元テストで補う。 |
4.6 XTS は現在の主系に向くが、永続的な最終回答ではない
XTS は、現在のディスク暗号化では自然な標準構成である。 LUKS2、 AES-XTS、 Argon2id の組み合わせは、新規の暗号化ディスクを作る場合の主系として扱いやすい。 CBC-ESSIV と比べると、 XTS はストレージ暗号化を前提にしており、場所情報を tweak として扱うため、ディスク暗号化の設計思想に合っている。したがって、これから新しく暗号化ディスクを作るなら、古い CBC-ESSIV に戻る理由は基本的にない。
しかし、 XTS も永続的な最終回答ではない。将来、ストレージ暗号化において完全性保護を標準的に含める構成が一般化する可能性はある。 KDF の標準も変わり、鍵管理の考え方も変わり、媒体も HDD や SSD からさらに別の形へ変化する。現在の XTS は、現在のストレージ暗号化における合理的な標準であって、未来永劫にわたって見直し不要な形式ではない。
したがって、長期運用では、 XTS を現在の主系として採用しつつ、その限界も台帳に含めておく必要がある。具体的には、暗号方式として aes-xts-plain64 を記録し、鍵長表示が 512 bits なら 2 系統の 256 bit 鍵材料であることを理解し、完全性保証は別途必要であることを明記し、将来の cryptsetup、 LUKS、 KDF、ストレージ標準の変化に応じて移行可能な状態を保つ。 XTS の採用は、ライフサイクル管理の終了ではなく、現在時点での主系を定義する作業である。
5. KDF と iteration はパスフレーズ攻撃への防御である
暗号化ディスクの安全性を評価するとき、データ本体の暗号化方式だけを見てはいけない。 AES-CBC-ESSIV か AES-XTS かは重要である。しかし、それとは別に、パスフレーズから key slot を開くための鍵材料を作る仕組みも重要である。この仕組みを KDF、つまり Key Derivation Function と呼ぶ。 KDF は、人間が入力するパスフレーズを、そのまま暗号鍵として使うのではなく、暗号処理に使える鍵材料へ変換する関数である。 LUKS では、 KDF はデータ本体の暗号化モードではなく、 LUKS ヘッダー内の key slot を開くために使われる。
この区別は重要である。暗号化ディスクでは、データ本体はボリュームキー、またはマスターキーと呼ばれるランダムな鍵で暗号化される。パスフレーズは、そのボリュームキーを直接置き換えるものではない。パスフレーズを KDF に入力し、 salt、 iteration、メモリコストなどの条件を加えて key slot 用の鍵材料を作り、その鍵材料で key slot 内に保護されているボリュームキーを取り出す。つまり、 KDF は「パスフレーズからデータ暗号化鍵を作る仕組み」と雑に理解すると不正確であり、より正確には「パスフレーズから key slot を開くための鍵材料を作る仕組み」である。
| 要素 | 役割 | 位置付け |
|---|---|---|
| パスフレーズ | 利用者が入力する秘密情報である。 | そのままデータ本体の暗号鍵になるわけではない。 |
| KDF | パスフレーズから key slot を開くための鍵材料を作る。 | オフライン攻撃の試行コストを上げるための中心的な仕組みである。 |
| key slot | ボリュームキーをパスフレーズごとに保護する入口である。 | 複数の key slot がある場合、複数の解除経路が存在する。 |
| ボリュームキー | データ本体を暗号化する中心の鍵である。 | 通常のパスフレーズ変更では、データ本体を再暗号化せずに key slot 側だけを変更できる。 |
| データ暗号化モード | 実際のデータ領域を暗号化する方式である。 | AES-CBC-ESSIV や AES-XTS などが該当し、 KDF とは別の層である。 |
5.1 KDF が必要になる理由は人間のパスフレーズが機械的な鍵より弱いからである
暗号技術では、理想的には十分な長さのランダムな鍵を使う。たとえば 256 bit のランダム鍵は、人間が覚える文字列とは性質がまったく違う。ランダム鍵は、規則性が少なく、候補空間が巨大であり、総当たりで当てることが現実的ではない。一方、人間が覚えられるパスフレーズは、単語、日付、名前、記号の置換、よくある語句、キーボード配列、過去の使い回しなどの影響を受けやすい。人間にとって覚えやすいものは、攻撃者にとって候補として並べやすいものでもある。
攻撃者が暗号化ディスクのコピーを入手した場合、問題はさらに厳しくなる。通常のログイン画面であれば、失敗回数制限、アカウントロック、監視ログ、ネットワーク制限などが効く。しかし、暗号化ディスクの LUKS ヘッダーと暗号化データを丸ごとコピーされた場合、攻撃者は手元の機械で候補パスフレーズを何度でも試せる。このような攻撃をオフライン攻撃と呼ぶ。オフライン攻撃では、サーバー側の失敗回数制限は効かず、攻撃速度は攻撃者の計算資源、 GPU、専用ハードウェア、実装効率に依存する。
| 攻撃形態 | 特徴 | KDF の意味 |
|---|---|---|
| オンライン攻撃 | ログイン画面やサービスに対して候補パスワードを試す。 | 失敗回数制限、ロック、監視、二要素認証などで抑制しやすい。 |
| オフライン攻撃 | 取得済みの暗号化データやヘッダーに対して手元で候補を試す。 | KDF によって 1 回あたりの試行コストを上げる必要がある。 |
| 辞書攻撃 | よくある単語、漏洩パスワード、規則的な変形を試す。 | KDF は試行速度を落とすが、弱いパスフレーズそのものを強くするわけではない。 |
| 総当たり攻撃 | 可能な文字列を機械的に列挙して試す。 | 長くランダム性の高いパスフレーズと重い KDF の組み合わせが必要になる。 |
したがって、 KDF の役割は、パスフレーズを魔法のように強い鍵へ変えることではない。 KDF は、候補パスフレーズを 1 回試すためのコストを増やす。これにより、攻撃者が 1 秒間に試せる候補数を減らす。弱いパスフレーズでも KDF があれば安全になる、という理解は誤りである。正しくは、十分に強いパスフレーズと、十分に重い KDF 設定を組み合わせることで、オフライン攻撃の現実的な成功可能性を下げる、という理解である。
5.2 salt は同じパスフレーズから同じ結果を作らせないための値である
KDF を理解するには、 salt も必要である。 salt は、パスフレーズに混ぜるランダムな値である。 salt の目的は、同じパスフレーズを使っても、媒体ごと、 key slot ごとに異なる鍵材料が作られるようにすることである。 salt がなければ、同じパスフレーズから常に同じ KDF 出力が作られるため、攻撃者はよくあるパスフレーズに対する計算結果をあらかじめ大量に用意できる。 salt があれば、同じパスフレーズでも salt が違うたびに計算結果が変わるため、攻撃者は対象ごとに計算をやり直す必要がある。
salt は秘密情報ではない。 LUKS の luksDump にも salt は表示される。 salt が見えているから弱い、ということではない。 salt の目的は隠すことではなく、同じパスフレーズに対して同じ導出結果を使い回させないことである。したがって、 salt は金庫の鍵ではなく、同じ型の鍵穴を大量に作らせないための個体差に近い。攻撃者が salt を知っていても、候補パスフレーズごとに対象の salt を使って KDF を計算しなければならない。
| 要素 | 秘密か | 役割 |
|---|---|---|
| パスフレーズ | 秘密である。 | 利用者が知っている解除情報である。 |
| salt | 秘密ではない。 | 同じパスフレーズでも対象ごとに異なる導出結果を作る。 |
| iteration | 秘密ではない。 | 候補 1 回あたりの計算量を増やす。 |
| memory cost | 秘密ではない。 | 候補 1 回あたりに必要なメモリ量を増やす。 |
| ボリュームキー | 秘密である。 | データ本体を暗号化する実鍵である。 |
5.3 iteration は候補 1 回あたりの計算回数である
iteration は、 KDF の内部処理を何回繰り返すかを示す値である。 PBKDF2 では、ハッシュ計算を何度も繰り返すことで、候補パスフレーズ 1 つを試すために必要な時間を増やす。たとえば iteration が 300 万回であれば、攻撃者は候補パスフレーズを 1 つ試すたびに、その対象の salt と組み合わせて多くの反復計算を実行しなければならない。これにより、 1 秒あたりに試せる候補数が減る。
ただし、 iteration は多ければ多いほど常に良い、という単純な話ではない。 iteration を増やすと攻撃者の試行は遅くなるが、正当な利用者の unlock も遅くなる。サーバー起動時、バックアップ媒体接続時、緊急復旧時に、解除に過大な時間がかかると運用上の負担になる。また、古い CPU、低速な端末、メモリ制約のある復旧環境では、過度に重い KDF 設定が復旧性を下げることもある。 KDF の設定は、攻撃耐性と運用可能性の均衡で決める必要がある。
| 観点 | iteration が小さい場合 | iteration が大きい場合 |
|---|---|---|
| 攻撃者の試行速度 | 候補を高速に試されやすい。 | 候補 1 回あたりの時間が増え、攻撃速度を下げやすい。 |
| 正当な unlock | 解除が速い。 | 解除に時間がかかる。 |
| 互換性 | 低性能環境でも扱いやすい。 | 古い環境や緊急復旧環境では負担になる場合がある。 |
| 長期運用 | 将来の計算能力向上に対して弱くなりやすい。 | 現在の主系としては望ましいが、設定値を台帳化しておく必要がある。 |
今回確認された LUKS1 媒体では、 key slot ごとに 300 万回前後の iteration が表示されていた。これは、 key slot ごとに salt と反復回数が別々に設定されていることを示している。複数の key slot が有効である場合、それぞれの key slot が独立した入口として存在する。したがって、ある key slot が十分に重い KDF と強いパスフレーズで守られていても、別の key slot に弱いパスフレーズが残っていれば、その弱い入口が全体の攻撃対象になる。
5.4 PBKDF2 は計算時間で攻撃を遅くする古典的な KDF である
PBKDF2 は、パスワードベース暗号で広く使われてきた鍵導出方式であり、 RFC 8018 で定義されている[17]。 PBKDF2 の基本的な考え方は、パスフレーズ、 salt、反復回数、擬似ランダム関数を組み合わせ、同じ処理を多数回繰り返すことで鍵材料を導出することである。計算を何度も繰り返せば、正当な利用者には少し待てばよい程度の負担で済む一方、攻撃者が大量の候補を試す場合には総コストが大きくなる。
PBKDF2 の利点は、実装が広く、仕様が安定しており、古い環境でも扱いやすいことである。これは LUKS1 の長期保全では重要である。 2014 年頃に作成された暗号化ディスクでも、現代の Linux 環境で読み出せる可能性が高いのは、 PBKDF2 と LUKS1 が長く安定して実装されてきたからである。一方、 PBKDF2 の弱点は、基本的に計算時間を増やす設計であり、メモリを大量に使わせる設計ではないことである。
現代の攻撃環境では、 GPU や専用ハードウェアによって単純な反復計算を大量並列化しやすい。 PBKDF2 の iteration を増やせば攻撃は遅くなるが、計算だけを大量に並列処理できる環境に対しては、メモリハード KDF より不利になりやすい。したがって、 PBKDF2 は壊れた方式ではないが、現在の新規主系では、 Argon2id のようなメモリハード KDF が使えるならそちらを優先しやすい。
| 観点 | PBKDF2 の特徴 | 運用上の読み取り |
|---|---|---|
| 標準化 | RFC 8018 で定義された広く使われた方式である。 | 古い環境との互換性が高い。 |
| 防御の中心 | 反復計算によって候補 1 回あたりの時間を増やす。 | iteration の値が攻撃コストに直結する。 |
| メモリ負荷 | 基本的にはメモリを大量に要求する設計ではない。 | 大量並列攻撃への抵抗では Argon2id より不利になりやすい。 |
| LUKS1 との関係 | LUKS1 で基本的に使われる KDF である。 | 既存媒体では互換性の利点として残る。 |
| 現在の新規主系 | 使えないわけではないが、最優先とは言いにくい。 | LUKS2 で Argon2id が使えるなら、主系では Argon2id を選びやすい。 |
5.5 Argon2id は時間だけでなくメモリも使わせる KDF である
Argon2id は、現代的なパスワード保護で重視されるメモリハード KDF である。 RFC 9106 は、 Argon2 をメモリハードな関数として定義し、パスワードハッシュや proof-of-work 用途を説明している[18]。メモリハードとは、候補 1 回を試すために計算時間だけでなく一定量のメモリも必要になる性質を指す。これにより、攻撃者が GPU や専用装置で大量の候補を並列に試そうとしても、各試行に必要なメモリがボトルネックになりやすい。
Argon2 には Argon2d、 Argon2i、 Argon2id という系統がある。 Argon2d はデータ依存のメモリアクセスを使い、 GPU 攻撃に強くしやすい一方、サイドチャネルへの注意が必要になる。 Argon2i はデータ非依存のメモリアクセスを使い、サイドチャネルに配慮しやすい。 Argon2id は、その両方の性質を組み合わせた方式であり、パスワードハッシュや LUKS2 のような用途でバランスの良い選択肢として扱われる。 Argon2 は Password Hashing Competition の勝者であり、その設計思想は現代的なパスワード保護の文脈で重要である[19]。
| 方式 | 特徴 | 位置付け |
|---|---|---|
| Argon2d | データ依存のメモリアクセスを使う。 | GPU 攻撃に強くしやすい一方、サイドチャネルへの注意が必要になる。 |
| Argon2i | データ非依存のメモリアクセスを使う。 | サイドチャネルに配慮しやすいが、攻撃モデルによっては設定の重さが重要になる。 |
| Argon2id | Argon2i と Argon2d の性質を組み合わせる。 | パスワード保護用途でバランスの良い現代的な選択肢である。 |
LUKS2 の luksDump では、 Argon2id の key slot に Time cost、 Memory、 Threads が表示される。 Time cost は処理を何回繰り返すかに関わる値であり、 Memory は使用するメモリ量であり、 Threads は並列処理の数である。たとえば Memory が 1048576 と表示されている場合、単位の読み方を確認する必要はあるが、実質的には大きなメモリ領域を使う設定として理解できる。これは PBKDF2 の iteration だけを見る場合よりも、攻撃者の計算環境に対して複合的な負荷を与える。
| 表示項目 | 意味 | 運用上の読み取り |
|---|---|---|
| PBKDF | key slot を守る KDF の種類である。 | pbkdf2 なら従来型、 argon2id なら現代的なメモリハード KDF と読む。 |
| Time cost | Argon2 系 KDF の時間方向の重さを示す。 | 値が大きいほど試行時間は増えるが、正当な unlock も重くなる。 |
| Memory | Argon2 系 KDF が使用するメモリ量を示す。 | 大量並列攻撃への抵抗に関わるが、低メモリ環境での復旧性にも影響する。 |
| Threads | Argon2 の並列処理数を示す。 | 解除時の CPU 利用や実行環境との相性に影響する。 |
| Salt | key slot ごとのランダム値である。 | 同じパスフレーズでも key slot ごとに異なる導出結果を作る。 |
5.6 KDF の重さは unlock 時に効く
KDF の重さは、主に unlock 時に効く。たとえば、 cryptsetup で暗号化デバイスを開くとき、パスフレーズを追加するとき、 key slot を変更するとき、 LUKS ヘッダー内の解除経路を更新するときに KDF が使われる。このとき、 PBKDF2 なら iteration、 Argon2id なら time cost、 memory、 threads が処理時間に影響する。したがって、 KDF を重くすると、暗号化ボリュームを開くまでの時間は長くなる。
一方で、いったんボリュームを開いた後のファイルコピー速度は、 KDF ではほとんど決まらない。開いた後は、カーネルの dm-crypt がデータ本体を AES-CBC-ESSIV や AES-XTS で暗号化・復号しながら読み書きする。ここで効くのは、 CPU の AES-NI、暗号モード、ファイルシステム、 HDD / SSD の性質、 USB ブリッジ、キャッシュ、 I/O パターン、小ファイルの多さ、 journal 更新、メタデータ更新などである。したがって、 Argon2id を使っているから大量コピーが遅い、という理解は基本的に誤りである。
| 処理 | KDF の影響 | 主に効く要因 |
|---|---|---|
| 暗号化デバイスを開く | 大きい。 | KDF、パスフレーズ、 key slot、 CPU、メモリが効く。 |
| パスフレーズを追加する | 大きい。 | 新しい key slot の KDF 設定が効く。 |
| パスフレーズを削除する | 限定的である。 | key slot 管理処理が中心である。 |
| 大量ファイルをコピーする | 通常は小さい。 | 媒体性能、ファイルシステム、暗号モード、 I/O パターンが効く。 |
| 小ファイルを多数同期する | 通常は小さい。 | metadata 更新、 journal、 seek、 USB、 HDD の記録方式が効く。 |
| 復元テストを行う | 最初の unlock には効くが、その後の読み取り速度は別要因で決まる。 | KDF と I/O 性能の両方を分けて観察する必要がある。 |
これは、 LUKS + ext4 のコピーが遅い原因を分析するときにも重要である。 unlock に数秒から十数秒かかる問題と、全ファイルコピーに 24 時間以上かかる問題は別である。前者は KDF の重さで説明できる可能性がある。後者は、ファイルシステムのメタデータ更新、 journal、 HDD のランダム I/O、 USB 接続、 SMR 的な挙動、 2.5-inch HDD の性能特性、小ファイルの多さなどを疑うべきである。 KDF は「開くまでの遅さ」の要因であり、「開いた後の全コピーの遅さ」の主因とは通常分けて考える。
5.7 複数 key slot は利便性であると同時に攻撃面でもある
LUKS では、複数の key slot を有効にできる。これは運用上便利である。通常用のパスフレーズ、緊急用のパスフレーズ、移行時の一時パスフレーズ、管理者用の解除経路などを分けられるからである。しかし、複数の key slot は、攻撃者から見れば複数の入口でもある。暗号化データ本体は同じでも、どれか 1 つの key slot を開けられれば、最終的に同じボリュームキーへ到達できる。
したがって、 key slot の数は多ければ多いほどよいわけではない。不要になった解除経路は削除する必要がある。特に、過去に一時的に追加したパスフレーズ、短いパスフレーズ、古いルールで作ったパスフレーズ、記録が残っていない key slot は、長期運用ではリスクになる。 luksDump で Key Slot 0 から Key Slot 3 まで有効であれば、 4 つの解除入口があるということであり、それぞれの用途と強度を台帳化しなければならない。
| key slot 状態 | 運用上の意味 | 対応 |
|---|---|---|
| 用途が明確な key slot | 通常用、緊急用、移行用などの役割が分かっている。 | 台帳に用途、作成日、管理者、退役条件を記録する。 |
| 用途不明の key slot | 誰が何のために追加したか分からない入口である。 | 復旧経路を確認したうえで、不要なら削除対象にする。 |
| 弱い可能性のある key slot | 古い短いパスフレーズや使い回しの可能性がある。 | 強い解除経路を確保してから削除または更新する。 |
| 移行用 key slot | 作業中に一時的に追加した入口である。 | 移行完了後に削除し、残留させない。 |
5.8 古い LUKS1 の PBKDF2 はただちに危険とは限らないが主系として増やすべきではない
古い LUKS1 媒体で PBKDF2 が使われていることは、それだけで直ちに危険を意味しない。 PBKDF2 は標準化された KDF であり、長く使われてきた。強いパスフレーズ、十分な iteration、不要な key slot の削除、ヘッダーバックアップ、物理媒体の保護が揃っていれば、既存媒体を互換バックアップや読み取り中心アーカイブとして保持する判断は成立し得る。
しかし、現在の新規主系として PBKDF2 前提の LUKS1 を増やす理由は乏しい。 LUKS2 では Argon2id が使え、メモリハード KDF によって現代的なオフライン攻撃への抵抗を高めやすい。したがって、古い LUKS1 + PBKDF2 は「即時廃棄」ではなく「分類管理」の対象であり、新しい LUKS2 + Argon2id は「主系標準」として扱うのが自然である。
| 構成 | 評価 | 運用判断 |
|---|---|---|
| LUKS1 + PBKDF2 | 古いが、強いパスフレーズと適切な管理があれば直ちに破綻した構成とは限らない。 | 既存媒体は互換バックアップや移行対象として管理する。 |
| LUKS2 + PBKDF2 | LUKS2 形式でも PBKDF2 を使うことは可能だが、現代的な主系としては Argon2id より優先度が下がる。 | 互換性が必要な特殊事情がなければ Argon2id を検討する。 |
| LUKS2 + Argon2id | 現代的なメモリハード KDF を使える構成である。 | 新規主系バックアップ媒体の標準候補として扱う。 |
| 用途不明 key slot が残る構成 | KDF の種類以前に解除入口の管理が不十分である。 | 全 key slot を確認し、不要な入口を削除する。 |
5.9 KDF の評価はパスフレーズ、媒体、ヘッダー管理と一体で行う
KDF だけを見て安全性を断定してはならない。 PBKDF2 でも、非常に長くランダム性の高いパスフレーズで、 key slot が整理され、ヘッダーが保全され、媒体が物理的に守られていれば、実運用上の危険は抑えられる。一方、 Argon2id でも、短いパスフレーズ、使い回し、用途不明の key slot、ヘッダーバックアップなし、媒体台帳なしであれば、運用としては脆い。 KDF は重要な防御層だが、単独で安全性を決めるものではない。
特に暗号化ディスクでは、攻撃耐性と復元可能性を同時に扱う必要がある。 KDF を極端に重くすれば攻撃者の試行は遅くなるが、緊急復旧時に古い端末や低メモリ環境で開けない可能性も出る。逆に、復旧性を優先して KDF を軽くしすぎれば、媒体紛失時のオフライン攻撃に弱くなる。したがって、 KDF 設定は、想定する脅威、媒体の保管場所、パスフレーズ強度、復旧環境、運用頻度を踏まえて決める必要がある。
| 評価対象 | 確認する内容 | 理由 |
|---|---|---|
| KDF 種類 | PBKDF2 か Argon2id かを確認する。 | 攻撃者に与える計算コストとメモリコストが異なる。 |
| KDF パラメーター | iteration、 time cost、 memory、 threads を記録する。 | 同じ KDF 名でも設定値により強度と運用負荷が変わる。 |
| パスフレーズ | 長さ、ランダム性、使い回し有無、管理方法を確認する。 | KDF は弱いパスフレーズを完全には救済できない。 |
| key slot | 有効数、用途、作成時期、不要入口の有無を確認する。 | 最も弱い key slot が全体の入口になり得る。 |
| ヘッダー | ヘッダーバックアップの有無、対象 UUID、取得日を確認する。 | KDF が強くてもヘッダーを失えば復元できない。 |
| 復旧環境 | 将来もその KDF とパラメーターを扱える環境を確保する。 | 重い Argon2id 設定は古い環境や低メモリ環境で問題になる場合がある。 |
5.10 KDF はライフサイクル管理の対象である
KDF の設定は、一度決めれば永久に十分というものではない。計算機の性能は上がり、 GPU や専用ハードウェアの攻撃能力も変わる。現在は十分に重い iteration や memory cost でも、将来には軽すぎる設定になる可能性がある。これは、 LUKS1 + PBKDF2 が長期運用の中でレガシー化して見えるのと同じ構造である。現在の LUKS2 + Argon2id も、将来の標準から見れば古くなる。
したがって、 KDF は暗号化ディスクのライフサイクル管理項目として台帳化すべきである。媒体 ID、 LUKS バージョン、暗号モード、 KDF 種類、 KDF パラメーター、有効 key slot 数、ヘッダーバックアップ、最終 unlock 確認日、退役条件を記録する。これにより、将来の見直し時に「どの媒体が LUKS1 + PBKDF2 か」「どの媒体が LUKS2 + Argon2id か」「どの媒体に用途不明の key slot が残っているか」を判断できる。
結論として、 KDF と iteration は、データコピー速度を説明するための概念ではなく、パスフレーズ攻撃への防御を説明するための概念である。 PBKDF2 は反復計算で攻撃を遅くする古典的な方式であり、 Argon2id は時間とメモリの両方を使わせる現代的な方式である。どちらも、強いパスフレーズ、整理された key slot、ヘッダー保全、復元テスト、媒体台帳と組み合わせて初めて意味を持つ。暗号化ディスクのレジリエンスは、暗号モードだけではなく、 KDF の世代差と運用管理まで含めて設計する必要がある。
6. TrueCrypt 7.1a は単純に LUKS1 より古いとは言えない
TrueCrypt 7.1a は、現在では保守終了した暗号化ソフトウェアである。そのため、新規の主系暗号化基盤として採用するべきものではない。しかし、技術的に見ると、 TrueCrypt 7.1a は単純に LUKS1 より古い、あるいは常に弱い、と言い切れるものではない。 TrueCrypt のユーザーガイドでは、 AES、 Serpent、 Twofish、およびそれらのカスケード暗号が扱われ、データ暗号化モードとして XTS が説明されている[20]。つまり、 TrueCrypt 7.1a はソフトウェアとしては保守終了済みでありながら、ディスク暗号化モードの設計思想だけを見れば、古い LUKS1 媒体で見られる AES-CBC-ESSIV よりも現在の LUKS2 + AES-XTS に近い面を持つ。
この章で扱うべき核心は、古い暗号化ディスクを「古いか新しいか」だけで評価してはならないという点である。暗号化ディスクの安全性と復元可能性は、コンテナ形式、データ暗号化モード、 KDF、ヘッダー構造、ソフトウェア保守状況、対応ツール、ファイルシステム、媒体状態、パスフレーズ管理、復元手順の組み合わせで決まる。 TrueCrypt 7.1a は保守終了しているため新規採用には向かない。一方で、データ暗号化モードは XTS 系であり、単純に LUKS1 + AES-CBC-ESSIV より古い設計と片付けることもできない。この複雑さを分解して評価することが、長期運用におけるレジリエンスの判断になる。
| 評価層 | TrueCrypt 7.1a の特徴 | 読み取り方 |
|---|---|---|
| ソフトウェア保守 | TrueCrypt 本体は保守終了している。 | 新規主系として採用する理由は乏しい。 |
| データ暗号化モード | 後期 TrueCrypt では XTS 系が使われる。 | ディスク暗号化モードの思想としては、古い CBC-ESSIV より現在の XTS 標準に近い。 |
| KDF | PBKDF2 を使うが、 iteration は現代基準では軽い。 | パスフレーズ攻撃への耐性では LUKS2 + Argon2id より不利になりやすい。 |
| ヘッダー | TrueCrypt ヘッダーは暗号化され、外部から形式を平文で読み取りにくい。 | LUKS の luksDump と同じ感覚では管理情報を確認できない。 |
| 長期運用 | 既存資産として残っている場合がある。 | 新規採用ではなく、読み出し確認、台帳化、移行、退役の対象として扱う。 |
6.1 TrueCrypt と LUKS はヘッダーの見え方が根本的に違う
LUKS と TrueCrypt の大きな違いは、ヘッダー情報の見え方である。 LUKS では luksDump によって、 LUKS バージョン、 cipher、 mode、 payload offset、 key slot、 KDF、 salt、 iteration、 Argon2id の time cost や memory などを比較的明示的に確認できる。もちろん、ボリュームキーそのものは表示しないが、暗号化コンテナとしての管理情報はかなり読める。これは、 LUKS が暗号化ブロックデバイスの運用管理形式として、メタデータを確認しやすい構造を持っているからである。
これに対して、 TrueCrypt 系のボリュームは、 LUKS の luksDump と同じ感覚では確認できない。 TrueCrypt のヘッダー自体は暗号化されており、外部から見ただけでは、どの cipher、どの hash、どのモード、どの KDF が使われているかを平文メタデータとして一覧できる設計ではない。正しいパスフレーズと必要な keyfile を使ってヘッダーを復号できてはじめて、そのボリュームの方式を確認できる。したがって、 TrueCrypt の方式確認は「ヘッダーを読む」というより、「正しい解除情報でヘッダー復号を試み、その結果として方式を得る」作業である。
| 観点 | LUKS | TrueCrypt 系 |
|---|---|---|
| メタデータ確認 | luksDump で形式、 cipher、 key slot、 KDF などを確認しやすい。 | ヘッダーが暗号化されており、パスフレーズなしで方式を一覧しにくい。 |
| パスフレーズなしの確認 | 多くの管理情報はパスフレーズなしで確認できる。 | 実質的な方式確認にはパスフレーズや keyfile が必要になる。 |
| 解除入口 | key slot として複数の解除経路を管理する。 | TrueCrypt のヘッダー構造とパスフレーズ、 keyfile、 hidden volume の有無に依存する。 |
| 台帳化 | luksDump の出力を基に項目化しやすい。 | tcryptDump、 tcplay、実際の解除確認結果を基に項目化する必要がある。 |
この違いは、長期運用では非常に重要である。 LUKS 媒体であれば、媒体を接続して luksDump を実行すれば、パスフレーズを入力しなくても LUKS1 か LUKS2 か、 CBC-ESSIV か XTS か、 key slot がいくつあるかを確認できる。一方、 TrueCrypt 媒体では、パスフレーズ、 keyfile、通常ボリュームか hidden volume か、バックアップヘッダーを使うか、といった解除条件が分からなければ、方式確認そのものが難しくなる。つまり、 TrueCrypt 資産の保全では、データ本体だけでなく、解除条件と確認手順を明示的に残す必要がある。
6.2 TrueCrypt ボリュームの方式確認には tcryptDump や tcplay を使う
GNU/Linux で TrueCrypt 系ボリュームの方式を確認する場合、 cryptsetup の TCRYPT 対応を使うのが現実的である。 LUKS では luksDump を使うが、 TrueCrypt 系では tcryptDump を使う。デバイス全体が TrueCrypt ボリュームであれば、 cryptsetup tcryptDump に対象デバイスを指定する。ファイルコンテナであれば、対象のコンテナファイルを指定する。ただし、 TrueCrypt 系ではヘッダー復号が必要になるため、パスフレーズ入力が前提になる。
純粋な TrueCrypt 7.1a ボリュームとして確認したい場合は、 VeraCrypt 互換探索を無効化して確認するのが切り分けとして分かりやすい。 VeraCrypt は TrueCrypt から派生し、 KDF の反復回数などを強化しているため、 TrueCrypt と VeraCrypt のどちらとして解釈しているのかを混同すると、台帳の意味が曖昧になる。 keyfile を使っている場合は keyfile も指定する必要がある。また、 hidden volume を調べる場合、通常ボリュームとは別の解除条件を使う必要があり、バックアップヘッダーを確認する場合も指定が変わる。
| 確認対象 | 確認方法 | 注意点 |
|---|---|---|
| 通常の TrueCrypt デバイス | cryptsetup tcryptDump で対象デバイスを確認する。 | パスフレーズが必要であり、 LUKS の luksDump のように無条件で平文メタデータを読めるわけではない。 |
| TrueCrypt ファイルコンテナ | cryptsetup tcryptDump で対象コンテナファイルを確認する。 | 物理ディスクではなくファイルを対象にする点だけが異なる。 |
| 純粋な TrueCrypt 7.1a 確認 | VeraCrypt 互換探索を無効化して確認する。 | VeraCrypt として解釈された結果を TrueCrypt の仕様と混同しないためである。 |
| keyfile 使用ボリューム | パスフレーズに加えて keyfile を指定して確認する。 | TrueCrypt 系の keyfile は LUKS の keyfile 運用と同一視しない方がよい。 |
| hidden volume | hidden volume 用の解除条件で確認する。 | 外側ボリュームと隠しボリュームは別の確認対象として扱う。 |
| バックアップヘッダー | バックアップヘッダーを指定して確認する。 | 通常ヘッダーが壊れた場合の復旧経路として台帳化する価値がある。 |
| tcplay による確認 | tcplay の info 表示で TrueCrypt 互換デバイスの情報を確認する。 | cryptsetup での運用と併用する場合、表示項目と解釈を揃えて記録する。 |
注意すべきなのは、 volume key を表示する操作を安易に使わないことである。 volume key は、パスフレーズなしでデータ本体を復号できる鍵材料である。これを端末、ログ、履歴、スクリーンショット、作業記録に残すと、そのボリュームの安全性を根本的に損なう。方式確認の目的であれば、暗号方式、ハッシュ、 KDF、通常ボリュームか hidden volume か、 keyfile 使用有無、開封確認日を記録すればよく、 volume key を取り出す必要はない。
6.3 TrueCrypt 7.1a は XTS 系だが KDF と保守状況ではレガシーである
TrueCrypt 7.1a の評価で最も誤解しやすいのは、データ暗号化モードとソフトウェアの保守状況を混同することである。 TrueCrypt 7.1a は保守終了している。したがって、新規の主系暗号化基盤として採用するべきではない。しかし、データ暗号化モードとしては XTS 系を使うため、古い LUKS1 媒体で見られる AES-CBC-ESSIV よりも、ストレージ暗号化モードの設計思想としては新しい面を持つ。これは、 TrueCrypt 7.1a が安全だから使い続けるべきだという意味ではなく、古さの中身を分けて評価すべきだという意味である。
一方で、 TrueCrypt 7.1a の KDF は現代基準では弱い。 TrueCrypt 7.1a は PBKDF2 を使うが、 LUKS2 + Argon2id のように大きなメモリコストを課す設計ではない。また、 iteration も現代の暗号化ディスクにおける主系 KDF と比べれば軽い。攻撃者がボリュームヘッダーを入手し、手元で候補パスフレーズを試せる場合、パスフレーズの強度が非常に重要になる。つまり、 TrueCrypt 7.1a は、データ暗号化モードでは比較的現代的な部分を持つが、 KDF と保守状況ではレガシーである。
| 観点 | TrueCrypt 7.1a | LUKS1 旧媒体 | LUKS2 新媒体 |
|---|---|---|---|
| ソフトウェア保守 | 保守終了している。 | cryptsetup / dm-crypt 側で現在も扱える。 | 現在の cryptsetup の主系として扱いやすい。 |
| コンテナ形式 | TrueCrypt 独自形式であり、ヘッダーは暗号化されている。 | LUKS1 の固定的なオンディスク形式である。 | LUKS2 の拡張可能なオンディスク形式である。 |
| データ暗号化 | XTS 系を使う。 | 古い媒体では AES-CBC-ESSIV が残ることがある。 | AES-XTS が標準的に使われる。 |
| KDF | PBKDF2 だが現代基準では軽い。 | PBKDF2 を使う。 | Argon2id を使える。 |
| 方式確認 | tcryptDump や tcplay で、パスフレーズを使って確認する。 | luksDump で多くの管理情報を確認できる。 | luksDump で KDF パラメーターや segment まで確認できる。 |
| 運用評価 | 新規採用ではなく、既存資産の読み出し、移行、退役の対象である。 | 互換バックアップまたは移行対象として分類する。 | 現在の主系暗号化ディスクとして扱いやすい。 |
6.4 TrueCrypt の暗号アルゴリズムは複数あり、実ボリュームごとの確認が必要である
TrueCrypt 7.1a では、 AES、 Serpent、 Twofish、およびそれらのカスケード暗号が扱われる[20]。したがって、 TrueCrypt ボリュームだから必ず AES 単体であるとは限らない。 AES-Serpent-Twofish、 Serpent-Twofish-AES などのカスケード構成が使われている可能性もある。カスケード暗号は、複数の暗号を順番に適用する構成であり、理論的には単一暗号への依存を下げる意味を持つ。一方で、処理は重くなり、運用上の可搬性や確認項目も複雑になる。
また、 TrueCrypt ではヘッダーキー導出に使うハッシュ関数も構成要素になる。 RIPEMD-160、 SHA-512、 Whirlpool などが関連し、どの PRF が使われているかは、ボリュームの解除と方式確認に関わる。つまり、 TrueCrypt 資産の台帳では、単に TrueCrypt とだけ書いても不十分である。 cipher、 cascade、 mode、 PBKDF2 PRF、 keyfile 使用有無、 hidden volume 有無、通常ヘッダーかバックアップヘッダーか、最終開封確認日を記録すべきである。
| 台帳項目 | 記録する内容 | 理由 |
|---|---|---|
| 対象 | 物理デバイス名、 UUID 相当の識別、ファイルコンテナ名、保管場所を記録する。 | どの媒体がどの TrueCrypt 資産なのかを取り違えないためである。 |
| 確認コマンド | cryptsetup tcryptDump、 tcplay info など、実際に使った確認方法を記録する。 | 後日同じ方法で再確認できるようにするためである。 |
| TrueCrypt / VeraCrypt 判定 | 純粋な TrueCrypt 7.1a か、 VeraCrypt 互換として扱ったかを記録する。 | KDF や iteration の前提が変わるためである。 |
| ボリューム種別 | 通常ボリューム、 hidden volume、バックアップヘッダー確認の有無を記録する。 | 復旧時に外側ボリュームと隠しボリュームを混同しないためである。 |
| cipher / cascade | AES、 Serpent、 Twofish、カスケード構成を記録する。 | 暗号化方式の技術世代と処理負荷を把握するためである。 |
| mode | XTS など、データ暗号化モードを記録する。 | LUKS1 の CBC-ESSIV や LUKS2 の AES-XTS と比較するためである。 |
| PBKDF2 PRF | ヘッダーキー導出に使われるハッシュ関数を記録する。 | パスフレーズ攻撃耐性と互換性を評価するためである。 |
| keyfile | keyfile 使用有無と保管方針を記録する。 | パスフレーズだけでは復旧できない構成を見落とさないためである。 |
| 最終開封確認日 | 実際に開けた日付、読み取り確認結果、マウント確認結果を記録する。 | 存在しているだけの媒体を、復元可能な媒体として管理するためである。 |
6.5 VeraCrypt との関係を分けて扱う必要がある
VeraCrypt は、 TrueCrypt から派生した後継的な暗号化ソフトウェアである。 VeraCrypt は、 TrueCrypt 由来の設計を引き継ぎつつ、 KDF の反復回数などを強化している。 VeraCrypt の文書では、ヘッダーキー導出、 salt、 iteration count が説明されており、 TrueCrypt 由来の構造をより重い KDF 設定へ寄せている[21]。したがって、 VeraCrypt は TrueCrypt 資産を考えるうえで重要な比較対象である。
ただし、既存資産が TrueCrypt 7.1a で作られたものであるなら、 VeraCrypt と混同して評価してはならない。 VeraCrypt は TrueCrypt より KDF が重い場合があり、解除に必要な探索条件も異なる。 cryptsetup で確認する場合にも、 VeraCrypt 互換探索を有効にするか無効にするかで、確認の意味が変わる。純粋な TrueCrypt 7.1a 資産を台帳化するなら、 TrueCrypt として開けるのか、 VeraCrypt として扱っているのかを明確に記録する必要がある。
| 観点 | TrueCrypt 7.1a | VeraCrypt |
|---|---|---|
| 系譜 | 元の TrueCrypt 系ソフトウェアである。 | TrueCrypt から派生した後継的ソフトウェアである。 |
| 保守状況 | 保守終了している。 | TrueCrypt より継続的な保守対象として扱われている。 |
| KDF | PBKDF2 の iteration が現代基準では軽い。 | TrueCrypt より重い KDF 設定を採用している。 |
| 既存資産への関係 | 過去のボリュームとして残っている可能性がある。 | 移行先や比較対象にはなるが、既存 TrueCrypt 資産そのものとは分けて扱う。 |
| 台帳上の注意 | TrueCrypt として開けるかを記録する。 | VeraCrypt 互換として開けた場合は、その事実を別に記録する。 |
6.6 TrueCrypt の監査結果は冷静な移行判断の材料である
TrueCrypt については監査結果も参照する必要がある。 BSI の TrueCrypt セキュリティ分析は、 TrueCrypt の設計と実装上の問題を検討している[22]。また、 TrueCrypt Phase Two Audit では、深刻なバックドアのようなものが確認されたわけではない一方、実装上の問題や設計上の注意点が整理された[23]。これらは、 TrueCrypt を永続利用してよいという保証ではない。同時に、 TrueCrypt 資産を即座にすべて危険物として捨てるべきだという単純な結論でもない。
監査結果から得るべき実務的な結論は、 TrueCrypt 既存資産を冷静に読み出し、保全し、移行し、退役させるというものである。保守終了ソフトウェアを新規主系として増やさない。既存ボリュームは開封確認を行う。 cipher、 mode、 KDF、 keyfile、 hidden volume の有無を台帳化する。必要なデータを LUKS2 + AES-XTS + Argon2id の主系媒体へ移す。移行後もしばらくは旧媒体を互換バックアップとして保持し、復元確認が取れた段階で退役条件を判断する。この段階的な扱いが、レジリエンス上は最も安定している。
| 判断 | 避けるべき極端 | 現実的な対応 |
|---|---|---|
| 新規採用 | TrueCrypt 7.1a を今後も主系として増やす。 | 新規主系は LUKS2 + AES-XTS + Argon2id に寄せる。 |
| 既存資産 | 保守終了だから即座にすべて捨てる。 | 読み出し確認、台帳化、移行、段階的退役を行う。 |
| 安全性評価 | TrueCrypt は古いからすべて弱いと決める。 | データ暗号化、 KDF、保守状況、パスフレーズ、媒体を分けて評価する。 |
| 復旧性 | 開けるはずだという記憶だけに頼る。 | 実際に開封し、マウントし、読み取り確認を行い、確認日を記録する。 |
6.7 TrueCrypt 旧資産は異質冗長性として価値を持つ場合がある
レジリエンスの観点では、 TrueCrypt 旧資産は単なる古い残骸ではなく、異質冗長性として価値を持つ場合がある。 LUKS2 + ext4 の主系バックアップだけに統一すると、管理は単純になる。しかし、同一方式、同一ファイルシステム、同一運用手順、同一ソフトウェア環境への依存も強まる。過去の TrueCrypt + FAT 媒体が読み取り可能な状態で残っていれば、 LUKS2 への移行失敗、 ext4 媒体の性能問題、特定環境でのマウント問題が起きたときの逃げ道になる可能性がある。
ただし、異質冗長性は放置とは違う。 TrueCrypt 媒体を残すなら、更新対象ではなく読み取り中心アーカイブとして扱うべきである。特に FAT は権限、シンボリックリンク、大容量ファイル、メタデータ保持の面で ext4 とは性質が違うため、現代的な Linux バックアップの主系ファイルシステムとしては制約がある。一方で、単純なファイル保管や互換バックアップとしては、過去環境との接続性を保つ意味がある。したがって、 TrueCrypt 旧資産は、更新し続ける主系ではなく、読み出し確認済みの互換バックアップとして意味づけるのが妥当である。
| 役割 | TrueCrypt 旧媒体の扱い | 判断理由 |
|---|---|---|
| 主系バックアップ | 採用しない。 | 保守終了ソフトウェアと軽い KDF を新規主系にする合理性は低い。 |
| 互換バックアップ | 条件付きで保持する。 | 過去の復元経路や異質冗長性として価値を持つ場合がある。 |
| 読み取り中心アーカイブ | 有効な役割として扱える。 | 更新頻度を下げれば、古い形式や FAT の制約を管理しやすい。 |
| 移行元 | 重要な役割を持つ。 | 必要データを LUKS2 主系へ移すまで、旧資産として保全する必要がある。 |
| 永続保管 | 無条件では採用しない。 | 開封確認、台帳化、退役条件なしに残すと管理不能な暗号化ディスクになる。 |
6.8 TrueCrypt 7.1a、 LUKS1、 LUKS2 は単純な一本線の進化ではない
TrueCrypt 7.1a、 LUKS1、 LUKS2 を時間順に並べるだけでは、実態を捉えられない。 LUKS1 は Linux 標準の暗号化ブロックデバイス運用として長く使われ、古い媒体では AES-CBC-ESSIV と PBKDF2 が残る。 TrueCrypt 7.1a は保守終了しているが、データ暗号化モードとしては XTS 系を使う。 LUKS2 は現在の主系として、 AES-XTS と Argon2id を扱いやすい。つまり、それぞれの強みと弱みは層ごとに交差している。
この比較は、古いものを一括して危険とみなす判断の粗さを示している。 TrueCrypt は保守終了しているが、データ暗号化モードだけを見れば XTS である。 LUKS1 は現在も cryptsetup で扱えるが、古い媒体では CBC-ESSIV と PBKDF2 が残る。 LUKS2 は現行標準だが、それも永続的な最終回答ではない。暗号化ディスクを評価するには、形式、モード、 KDF、ソフトウェア保守、媒体、復元手順を分けて見る必要がある。
| 対象 | 強い点 | 弱い点 | 運用上の位置付け |
|---|---|---|---|
| LUKS1 旧媒体 | Linux 標準として長く使われ、 cryptsetup で管理しやすい。 | 古い媒体では AES-CBC-ESSIV と PBKDF2 が残り、拡張性も LUKS2 より低い。 | 既存媒体、互換バックアップ、移行対象として扱う。 |
| TrueCrypt 7.1a | XTS 系のデータ暗号化モードを使い、異質冗長性として価値を持つ場合がある。 | 保守終了しており、 KDF は現代基準では軽く、方式確認も LUKS より扱いにくい。 | 新規採用ではなく、読み出し確認、移行、退役の対象として扱う。 |
| LUKS2 新媒体 | AES-XTS と Argon2id を扱いやすく、メタデータ拡張性も高い。 | 将来はこれもレガシー化し、完全性保証も通常の XTS だけでは提供しない。 | 現在の主系暗号化ディスクとして扱う。 |
結論として、 TrueCrypt 7.1a は単純に LUKS1 より古いとは言えない。ソフトウェアとしては保守終了しており、 KDF と長期保守性では明確にレガシーである。しかし、データ暗号化モードでは XTS 系であり、古い LUKS1 の AES-CBC-ESSIV より現代的な面もある。このねじれを理解することが重要である。長期運用では、最新方式への単純置換だけでなく、既存資産の形式、暗号方式、 KDF、解除条件、復元実績を台帳化し、読み取り確認し、主系、互換バックアップ、移行対象、退役対象へ分類する必要がある。 TrueCrypt 旧資産は、新規採用するものではなく、意味を失わせずに管理し、必要な期間だけ復元経路として残し、役割が終わった時点で退役させる対象である。
7. 古い方式は弱いのか、それとも古いだけなのか
古い暗号化方式を見つけたとき、最初に分けるべきなのは「レガシー」と「危殆化」である。レガシーとは、現在の新規採用では推奨しにくいが、既存利用が直ちに危険とは限らない状態である。危殆化とは、既知の攻撃、短すぎる鍵、弱いハッシュ、実用的に破れる KDF、保守不能な実装、復旧不能な管理状態などにより、実運用上の危険が明確になった状態である。 LUKS1 + AES-CBC-ESSIV + PBKDF2 は、現在の新規主系としては選ばない構成である。しかし、強いパスフレーズで管理され、不要な key slot が削除され、ヘッダーが保全され、読み取り確認と復元手順が存在するなら、ただちに破られる構成とは言いにくい。古いことと、現時点で実用上危険であることは同じではない。
この区別をしないと、長期運用の判断は極端になる。ひとつは、古い方式を見つけただけで即時廃棄し、過去の復元経路を失う判断である。もうひとつは、過去に問題なく使えていたという理由だけで、レガシー構成を主系として使い続ける判断である。どちらも危うい。前者は復元可能性を壊し、後者は計算能力、攻撃手法、ソフトウェア保守、媒体劣化の変化を無視する。必要なのは、暗号方式の世代、 KDF の世代、パスフレーズの強度、 key slot の整理状況、ヘッダー保全、媒体状態、復旧手順を分けて見たうえで、主系、互換バックアップ、移行対象、退役対象へ分類することである。
| 分類 | 意味 | 判断基準 | 対応 |
|---|---|---|---|
| 現行標準 | 新規作成の主系として採用しやすい状態である。 | 現在の cryptsetup、 LUKS2、 AES-XTS、 Argon2id など、現行環境で自然に扱える構成である。 | 新規主系バックアップ媒体として採用し、台帳化と復元テストを行う。 |
| レガシー | 古いが、直ちに実用上危険とは限らない状態である。 | 新規採用には向かないが、強いパスフレーズ、整理された key slot、ヘッダー保全、読み取り確認が成立している。 | 互換バックアップ、読み取り中心アーカイブ、移行元として役割を限定する。 |
| 移行対象 | 主系として残すには不安があり、計画的に新構成へ移すべき状態である。 | KDF が古い、保守終了ソフトウェアに依存する、媒体劣化が疑われる、確認手順が複雑であるなどの要素がある。 | 新媒体へ同期し、復元確認後に旧媒体の保持期間と退役条件を決める。 |
| 危殆化 | 既知の弱点または運用破綻により、実用上危険な状態である。 | 弱いパスフレーズ、用途不明の key slot、失われた keyfile、未保全ヘッダー、既知の深刻な脆弱性、開封不能状態などがある。 | 主系から外し、必要データを安全な構成へ移し、移行完了後に退役または隔離する。 |
7.1 古い方式の評価では層を分ける必要がある
暗号化ディスクの評価では、ひとつの名前だけで安全性を判断してはならない。 LUKS1、 LUKS2、 TrueCrypt、 VeraCrypt という形式名は重要である。しかし、それだけでは不十分である。実際には、その下にデータ暗号化モード、 KDF、パスフレーズ、 key slot、ヘッダー、ファイルシステム、物理媒体、復旧環境がある。たとえば、 LUKS1 という形式だけを見れば古い。しかし、強いパスフレーズと十分な PBKDF2 iteration で管理され、 key slot が整理されていれば、読み取り中心の互換バックアップとして残す判断はあり得る。逆に、 LUKS2 + AES-XTS + Argon2id でも、パスフレーズが短く、ヘッダーバックアップがなく、復元テストもなければ、運用としては脆い。
特に長期運用では、暗号技術上の安全性と、復元可能性がしばしば衝突する。最も新しい方式に統一すれば、暗号方式の説明は単純になる。しかし、旧媒体を急いで消すと、過去の復元経路、古いファイルシステムでしか見えないデータ、移行漏れ、過去のバックアップ世代を失う可能性がある。一方で、復元可能性を理由に古い方式を無期限に主系として使い続ければ、攻撃耐性や保守性が下がる。したがって、古い方式は、残すか消すかの二択ではなく、役割を縮小しながら管理する対象として扱うべきである。
| 評価層 | 見るべき内容 | 誤った判断 | 適切な判断 |
|---|---|---|---|
| 形式 | LUKS1、 LUKS2、 TrueCrypt、 VeraCrypt などのコンテナ形式を見る。 | 形式名だけで安全または危険と断定する。 | 形式は入口として確認し、下位の暗号モードや KDF まで見る。 |
| 暗号モード | AES-CBC-ESSIV、 AES-XTS、 TrueCrypt の XTS 系などを見る。 | 古い形式なら暗号モードも必ず古いと決めつける。 | 形式と暗号モードを分け、実際の設定を確認する。 |
| KDF | PBKDF2、 Argon2id、 iteration、 memory cost などを見る。 | AES-XTS ならパスフレーズ攻撃にも強いと考える。 | データ暗号化とパスフレーズ防御を別層として評価する。 |
| 解除入口 | key slot 数、用途、不要な入口、 keyfile の有無を見る。 | 強い key slot がひとつあれば全体が安全だと考える。 | 最も弱い解除入口が全体の弱点になり得ると見る。 |
| ヘッダー | ヘッダーバックアップ、 UUID、取得日、復元手順を見る。 | 暗号が強ければ復旧できると考える。 | ヘッダー喪失は復号不能につながるため、暗号強度とは別に保全する。 |
| 媒体 | HDD、 SSD、 USB ブリッジ、劣化、読み取り速度、エラーを見る。 | 暗号方式だけでバックアップの安全性を語る。 | 物理媒体の寿命と読み取り確認を含めて判断する。 |
| 復旧環境 | 将来も開ける OS、 cryptsetup、 VeraCrypt、 keyfile、手順があるかを見る。 | 現在開けるから将来も開けると考える。 | 復旧手順と必要ツールを台帳化し、定期的に開封確認する。 |
7.2 レガシーとは新規採用しないが既存利用を即否定しない状態である
レガシーという言葉は、単に古くて悪いという意味ではない。長期運用におけるレガシーとは、現在の新規設計では採用しないが、既存資産として一定の役割を持つ状態である。たとえば、 LUKS1 + AES-CBC-ESSIV + PBKDF2 は、現在の新規主系バックアップとして選ぶ構成ではない。新しく作るなら、 LUKS2 + AES-XTS + Argon2id を基本にする方が自然である。しかし、過去に作られた LUKS1 媒体が読み取り可能であり、パスフレーズが強く、 key slot が整理され、ヘッダーが保存されているなら、それを即座に破棄する理由にはならない。
レガシー媒体の価値は、主系ではなく互換性と復元経路にある。過去の時点のデータを保持していること、別方式のバックアップとして存在すること、移行時の比較対象になること、現行構成に障害が出た場合の代替経路になることが価値である。ただし、その価値は管理されている場合に限られる。何の方式か分からない、誰もパスフレーズを確認していない、 keyfile の所在が不明、ヘッダーバックアップがない、最後に開けた日付が不明、媒体エラーも確認していないという状態なら、それはレガシー資産ではなく、復元できるか分からない不明媒体である。
| 状態 | レガシー資産として成立する条件 | 成立しない条件 |
|---|---|---|
| LUKS1 旧媒体 | luksDump 結果、 key slot 用途、ヘッダーバックアップ、最終開封確認日が記録されている。 | key slot の用途が不明で、ヘッダー保全もなく、最後に開けた時期も分からない。 |
| TrueCrypt 旧媒体 | tcryptDump や tcplay による確認、パスフレーズ、 keyfile、 hidden volume 有無、最終開封確認日が記録されている。 | TrueCrypt か VeraCrypt かも曖昧で、解除条件や keyfile の所在が不明である。 |
| 古い HDD | 読み取り確認、 SMART 情報、バックアップ重複、退役予定が管理されている。 | 物理劣化が疑われるのに唯一のコピーとして残っている。 |
| 古いファイルシステム | 制約を理解したうえで、読み取り中心や互換用途に限定されている。 | 権限、シンボリックリンク、大容量ファイル、文字コードなどの制約を無視して主系にしている。 |
7.3 危殆化とは古いことではなく実用上危険な状態である
危殆化とは、単に古いという意味ではない。実用上の危険が明確になった状態である。暗号アルゴリズムそのものに深刻な既知の弱点がある場合、鍵長が現在の攻撃能力に対して短すぎる場合、 KDF が軽すぎて辞書攻撃に耐えにくい場合、パスフレーズが短い場合、 key slot に用途不明の弱い入口が残っている場合、保守終了ソフトウェアに依存し、かつ代替ツールでも安定して開けない場合、ヘッダーや keyfile を失っている場合、媒体エラーで読み取り不能になり始めている場合などが該当する。
ここで重要なのは、危殆化は暗号理論だけで決まらないという点である。 AES-XTS が十分に強くても、パスフレーズが短ければオフライン攻撃に弱い。 Argon2id を使っていても、ヘッダーバックアップがなく、ヘッダーが壊れれば復元できない。 TrueCrypt の XTS 系が暗号モードとして一定の合理性を持っていても、保守終了ソフトウェア、軽い KDF、 keyfile 不明、方式確認不能が重なれば危険度は上がる。危殆化とは、暗号部品の弱さだけでなく、運用全体として復元または防御が成り立たなくなった状態である。
| 危殆化要因 | 具体例 | 意味 | 対応 |
|---|---|---|---|
| 暗号方式の弱点 | 既知の実用的な攻撃が存在する方式を使い続けている。 | 方式そのものが主系として不適切である。 | 新しい方式へ移行し、旧方式は退役対象にする。 |
| KDF の弱さ | iteration が低い PBKDF2、軽い KDF、古い TrueCrypt 設定などである。 | オフライン攻撃で候補を高速に試されやすい。 | 強いパスフレーズと現行 KDF の媒体へ移行する。 |
| 弱い解除情報 | 短いパスフレーズ、使い回し、用途不明 key slot、所在不明 keyfile である。 | 暗号方式が強くても入口が弱い。 | 解除入口を棚卸しし、不要または弱い入口を削除する。 |
| 保守不能 | 必要なソフトウェアや OS で開ける見通しがない。 | データが残っていても復元できない可能性が高い。 | 開けるうちに移行し、手順とツールを記録する。 |
| ヘッダー喪失 | LUKS ヘッダーや TrueCrypt ヘッダーのバックアップがなく、破損時の復旧経路がない。 | データ本体が残っていても復号不能になり得る。 | ヘッダーバックアップを取得し、対象媒体と対応づけて保管する。 |
| 媒体劣化 | 読み取りエラー、異常な遅延、 SMART 警告、接続不安定がある。 | 暗号方式以前に物理的な復元可能性が下がっている。 | 直ちに別媒体へ退避し、旧媒体は主系から外す。 |
7.4 暗号方式だけでなく key slot が全体の弱点になり得る
LUKS 媒体では、 key slot の管理が安全性に直結する。暗号化データ本体は同じボリュームキーで守られていても、そのボリュームキーへ到達する入口が複数ある。 key slot 0 が強いパスフレーズで守られていても、 key slot 1 に古い短いパスフレーズが残っていれば、攻撃者は key slot 1 を狙えばよい。したがって、最も強い入口ではなく、最も弱い入口が全体の安全性を下げる。この構造を理解しないと、 luksDump で複数の Key Slot が ENABLED と表示されている意味を過小評価する。
これは TrueCrypt 系でも同じ構造を別の形で持つ。 TrueCrypt では LUKS のような key slot 一覧が平文で見えるわけではないが、パスフレーズ、 keyfile、 hidden volume、バックアップヘッダー、解除ツールの組み合わせが復元経路になる。どれかが不明になれば復元性が下がり、どれかが弱ければ攻撃耐性が下がる。つまり、暗号方式の名前だけでなく、解除入口が何であり、誰が管理し、いつ確認され、不要な入口が残っていないかを管理しなければならない。
| 対象 | 弱点になり得る入口 | 点検内容 | 判断 |
|---|---|---|---|
| LUKS1 | 複数の key slot、古い PBKDF2 設定、用途不明のパスフレーズである。 | Key Slot の有効数、 iteration、用途、削除可能性を確認する。 | 不要な key slot は削除し、必要なものだけを台帳化する。 |
| LUKS2 | 複数 keyslot、 token、外部解除手段、弱いパスフレーズである。 | Keyslots、 Tokens、 PBKDF、 memory、 time cost を確認する。 | Argon2id であっても解除入口の棚卸しを行う。 |
| TrueCrypt | パスフレーズ、 keyfile、 hidden volume、バックアップヘッダーである。 | tcryptDump や tcplay で開封確認し、必要条件を記録する。 | 解除条件が不明な媒体は、復元可能資産として扱えない。 |
| VeraCrypt | 強化された KDF、 PIM、 keyfile、互換モードの違いである。 | TrueCrypt として開けるのか、 VeraCrypt として開けるのかを分けて記録する。 | 同じ系譜でも解除条件の違いを台帳化する。 |
7.5 現在安全に見える方式も将来はレガシーになる
現行標準を採用すれば、それで長期運用の問題が終わるわけではない。現在の LUKS2 + AES-XTS + Argon2id は、現時点の Linux の暗号化ディスクとして自然な構成である。しかし、これも将来はレガシーになる。計算機の性能は上がり、 GPU や専用ハードウェアの攻撃能力も変わる。ストレージの標準も変わり、完全性保護を含む構成がより一般化するかもしれない。 cryptsetup の既定値も、 KDF の推奨値も、 LUKS 形式そのものも変わる可能性がある。現在の標準は、未来の最終回答ではない。
このため、暗号化ディスクでは「最強の方式を一度選ぶ」ことよりも、「方式が古くなったときに移行できる運用」を作ることが重要である。媒体ごとに形式、暗号方式、 KDF、 key slot、ヘッダー、最終確認日、移行先、退役条件を記録しておけば、将来の見直し時に判断できる。記録がなければ、将来の自分は、どの媒体が何で暗号化され、どれが主系で、どれが互換バックアップで、どれを消してよいのか分からなくなる。暗号化方式のライフサイクル管理とは、未来の移行判断を可能にするための情報管理でもある。
| 時点 | その時点の標準 | 将来起きること | 必要な運用 |
|---|---|---|---|
| 過去 | LUKS1 + AES-CBC-ESSIV + PBKDF2 や TrueCrypt 7.1a が実用構成だった。 | 現在の目から見ると、レガシー構成として見える。 | 既存資産として分類し、主系から外しつつ復元経路を保つ。 |
| 現在 | LUKS2 + AES-XTS + Argon2id が主系として自然である。 | 将来は KDF、完全性保護、媒体、ツールの標準が変わる。 | 現行主系として使いながら、設定値と復旧手順を台帳化する。 |
| 将来 | 現在とは異なる方式が標準になる可能性がある。 | 現在の LUKS2 構成もレガシーになる。 | 移行条件を定義し、読み取り確認済みの段階的移行を行う。 |
7.6 古い方式を発見したときの対応は即廃棄ではなく棚卸しである
古い方式を発見したときに最初に行うべきことは、即座に削除することではなく、棚卸しである。 LUKS なら luksDump を取得し、 LUKS バージョン、 cipher、 mode、 key slot、 KDF、 payload offset、 UUID を記録する。 TrueCrypt 系なら tcryptDump や tcplay で方式確認を行い、 TrueCrypt か VeraCrypt か、通常ボリュームか hidden volume か、 cipher、 mode、 PBKDF2 PRF、 keyfile の有無、最終開封確認日を記録する。媒体そのものについては、容量、接続方式、ファイルシステム、読み取り速度、エラー、バックアップ重複状況を確認する。
棚卸しの目的は、古い媒体を守ることではない。復元可能性を失わずに更新することである。古い媒体を即廃棄すれば、過去の復元経路を失う。古い媒体を無期限に主系として使い続ければ、セキュリティと保守性が下がる。したがって、棚卸しの後に、役割を決める。主系に残すのか、読み取り中心にするのか、互換バックアップとして一定期間保持するのか、移行後に退役するのかを決める。判断は媒体単位で行い、暗号方式名だけで一括処理しない。
| 手順 | 実施内容 | 目的 |
|---|---|---|
| 識別 | 対象媒体、接続先、容量、ラベル、 UUID、物理保管場所を確認する。 | どの媒体を評価しているのかを取り違えないためである。 |
| 方式確認 | LUKS なら luksDump、 TrueCrypt 系なら tcryptDump や tcplay で確認する。 | 形式、暗号モード、 KDF、解除条件を把握するためである。 |
| 開封確認 | 実際に open し、必要なら読み取り専用でマウントし、内容を確認する。 | 存在している媒体を復元可能な媒体として確認するためである。 |
| 整合性確認 | ファイル数、容量、重要ディレクトリ、チェックサム、読み取りエラーを確認する。 | 開けるだけでなく、データが読めることを確認するためである。 |
| 役割分類 | 主系、互換バックアップ、移行対象、退役対象へ分類する。 | 古い方式を感情的に扱わず、運用上の役割を明確にするためである。 |
| 移行計画 | 必要データを現行主系へ同期し、復元確認後に旧媒体の保持期間を決める。 | 復元可能性を維持したまま暗号方式と媒体を更新するためである。 |
| 退役 | 役割を終えた媒体を安全に消去し、台帳上で退役済みにする。 | 用途不明の古い暗号化ディスクを増やさないためである。 |
7.7 暗号化ディスクの安全性は防御と復元の両方で決まる
暗号化ディスクでは、セキュリティだけを見ても不十分であり、復元可能性だけを見ても不十分である。セキュリティは、媒体を紛失したときに第三者が読めないことを求める。復元可能性は、必要なときに正当な利用者が確実に読めることを求める。この 2 つは同じ方向を向くとは限らない。 KDF を極端に重くすれば攻撃者には強くなるが、緊急復旧環境で開けない可能性が増える。旧媒体をすべて廃棄すれば管理は単純になるが、過去の復元経路が消える。逆に、旧媒体を残しすぎると、弱い解除入口や不明な媒体が増える。
したがって、古い方式を評価する最終基準は、「強いか弱いか」だけではなく、「どの役割なら妥当か」である。 LUKS1 + AES-CBC-ESSIV + PBKDF2 は、新規主系としては妥当ではないが、条件が整えば互換バックアップとして残せる。 TrueCrypt 7.1a は、新規採用すべきではないが、既存資産の読み出しと移行元として価値がある。 LUKS2 + AES-XTS + Argon2id は現在の主系として自然だが、完全性保証や将来のレガシー化を考える必要がある。古い方式は、弱いか古いかの二択ではなく、役割、期限、確認状態、移行計画によって評価すべきである。
| 構成 | 単純評価 | 実際の評価 | 推奨される役割 |
|---|---|---|---|
| LUKS1 + AES-CBC-ESSIV + PBKDF2 | 古い。 | 新規主系には向かないが、強いパスフレーズと管理済み key slot があれば直ちに危険とは限らない。 | 互換バックアップ、読み取り中心アーカイブ、移行対象。 |
| TrueCrypt 7.1a | 保守終了で古い。 | ソフトウェア保守と KDF ではレガシーだが、データ暗号化モードは XTS 系であり、既存資産としての評価は層別に行う必要がある。 | 既存資産の読み出し、移行元、期間限定の互換バックアップ。 |
| LUKS2 + AES-XTS + Argon2id | 新しく強い。 | 現在の主系として自然だが、完全性保証、ヘッダー保全、将来のレガシー化を考慮する必要がある。 | 現行主系バックアップ。 |
| 方式不明の暗号化ディスク | 不明。 | 方式や解除条件が分からなければ、実質的には復元可能資産として扱いにくい。 | 調査対象、開封確認対象、必要なら移行または退役。 |
結論として、古い方式は必ずしも弱いわけではない。しかし、古い方式を主系として増やし続けるべきでもない。古い方式は、暗号モード、 KDF、パスフレーズ、 key slot、ヘッダー、媒体、復旧手順を分けて評価し、役割を限定して管理する必要がある。レガシーは、即時危険ではないが、無期限の主系でもない。危殆化は、古さではなく実用上の危険が明確になった状態である。長期運用のレジリエンスとは、この差を見分け、復元経路を失わずに、主系を現行標準へ移し、旧方式を計画的に縮退させる設計である。
8. 現在の標準もいずれ古くなる
現在の LUKS2 + AES-XTS + Argon2id は、現時点の Linux の暗号化ディスクとして自然な標準構成である。しかし、この構成も長い時間軸ではいずれ古くなる。これは悲観論ではなく、暗号運用の基本前提である。暗号方式は、一度選べば永久に安全性と運用妥当性を保証してくれる固定物ではない。計算能力、攻撃手法、標準化、実装、媒体、復旧環境、運用目的が変化するため、ある時点で合理的だった構成は、時間の経過とともに「現在の主系」から「レガシー」へ移動する。 2014 年頃に作成された LUKS1 + AES-CBC-ESSIV + PBKDF2 の媒体が、当時は自然な実用構成だったにもかかわらず、現在は新規主系としては選びにくくなっているのと同じである。
ここで重要なのは、暗号方式の古さを「方式が突然壊れること」としてだけ理解しないことである。暗号のレガシー化には複数の経路がある。ひとつは、暗号アルゴリズムや鍵長に対する評価が変わることである。もうひとつは、 KDF の推奨パラメーターが計算能力の上昇に追いつかなくなることである。さらに、ソフトウェアが保守されなくなる、復旧環境で扱いにくくなる、媒体が劣化する、ヘッダーや keyfile の管理情報が失われる、運用者が解除条件を再現できなくなる、という経路もある。つまり、暗号化ディスクが古くなるとは、暗号理論だけの問題ではなく、実装、記録、媒体、復元手順を含む運用構造全体が古くなるということである。
| レガシー化の経路 | 起きる変化 | 暗号化ディスクでの意味 |
|---|---|---|
| 暗号方式の評価変化 | 以前は妥当だった暗号モードや鍵長が、新規採用に向かなくなる。 | 既存媒体は直ちに破棄せず、主系から外して移行対象にする。 |
| KDF の相対的弱体化 | 計算能力や GPU 性能の向上により、過去の iteration や memory cost が軽く見えるようになる。 | パスフレーズ攻撃への耐性を再評価し、必要に応じて新しい key slot や新媒体へ移行する。 |
| 実装の保守終了 | ソフトウェアの更新、脆弱性修正、現行 OS との互換性が期待しにくくなる。 | TrueCrypt 7.1a のように、新規採用ではなく読み出しと移行の対象になる。 |
| 復旧環境の喪失 | 将来の OS、 cryptsetup、 VeraCrypt、ドライバー、ファイルシステム対応で開ける保証が弱くなる。 | 開けるうちに確認し、手順と必要ツールを記録する必要がある。 |
| 管理情報の欠落 | パスフレーズ、 keyfile、 key slot 用途、ヘッダーバックアップ、確認日が分からなくなる。 | 暗号方式が強くても、復元可能資産として扱えなくなる。 |
| 物理媒体の劣化 | HDD、 SSD、 USB ブリッジ、ケーブル、筐体、ファイルシステムの状態が悪化する。 | 暗号方式以前に読み取り不能となり、バックアップとしての意味を失う。 |
8.1 現在安全であることと、長期的に十分であることは同じではない
現在の LUKS2 + AES-XTS + Argon2id は、過去の LUKS1 + AES-CBC-ESSIV + PBKDF2 や TrueCrypt 7.1a と比べると、現在の主系として扱いやすい。 LUKS2 はメタデータの拡張性を持ち、 AES-XTS はストレージ暗号化の位置情報を tweak として扱い、 Argon2id は時間だけでなくメモリも使わせる KDF である。したがって、新しく暗号化ディスクを作る場合、この構成を主系にする判断は合理的である。しかし、合理的であることは、将来見直し不要であることを意味しない。
現在安全に見える構成も、時間が経てば相対的に弱くなる。たとえば、 Argon2id の memory cost が現在は十分重く見えても、将来の標準的なメモリ容量、 GPU、専用ハードウェア、攻撃ツールが変われば、同じ設定値の意味は変わる。 AES-XTS も、現在のストレージ暗号化では標準的だが、通常構成では完全性保証を提供しない。将来、暗号化ストレージにおいて完全性保護や認証付き暗号化を含む構成がより一般的になれば、現在の XTS 構成は「機密性は守るが完全性は別層に委ねる旧来構成」として扱われる可能性がある。つまり、現在の標準は、現在の制約に対する最適解であり、永久の最終解ではない。
| 現在の構成要素 | 現在の意味 | 将来の見直し要因 |
|---|---|---|
| LUKS2 | 現在の Linux 暗号化ブロックデバイスで扱いやすい拡張可能な形式である。 | 将来の LUKS 形式、 token 管理、メタデータ方式、復旧手順の変化により、旧形式化する可能性がある。 |
| AES-XTS | ストレージ暗号化の機密性保護として標準的に使いやすい。 | 完全性保護や認証付きストレージ暗号化が標準化すれば、機密性中心の構成として相対的に古くなる可能性がある。 |
| Argon2id | パスフレーズ攻撃に対して時間とメモリの両方を使わせる現代的な KDF である。 | 計算資源の増大により、現在の time cost、 memory、 threads が将来は軽すぎる設定になる可能性がある。 |
| ext4 | Linux のバックアップ媒体として安定した実用ファイルシステムである。 | 媒体特性、メタデータ更新、小ファイル性能、将来のファイルシステム要件によって適性が変わる可能性がある。 |
| 現在の cryptsetup | LUKS2、 Argon2id、 tcrypt 互換などを扱える実用ツールである。 | 将来の既定値、互換性、古い形式の扱い、リカバリー手順が変わる可能性がある。 |
8.2 暗号方式の寿命はアルゴリズム単体では決まらない
暗号方式の寿命を考えるとき、 AES が破られるかどうかだけを見ても足りない。暗号化ディスクの寿命は、アルゴリズム、鍵長、 KDF、実装、メタデータ、ファイルシステム、媒体、運用手順の最短寿命で決まる。たとえば AES-XTS 自体が十分な機密性を持っていても、パスフレーズが弱ければオフライン攻撃に負ける。 Argon2id が十分に重くても、 LUKS ヘッダーを失えば復元できない。ヘッダーが保全されていても、 HDD が読めなければデータに到達できない。媒体が読めても、将来の環境で必要なツールや keyfile が再現できなければ、復元できない。
したがって、現在の標準がいずれ古くなるという話は、単に「新しい暗号方式が出てくる」という話ではない。むしろ、暗号化ディスクを成立させている複数の層のうち、どこかが時間とともに弱くなるという話である。計算能力の上昇は KDF に影響する。標準化の変化は暗号モードに影響する。実装の保守状況はツール選択に影響する。媒体劣化は読み取り可能性に影響する。作業記録の欠落は復元可能性に影響する。長期運用では、暗号方式の寿命を単一部品ではなく、複合システムの寿命として扱う必要がある。
| 層 | 寿命を左右する要因 | 破綻した場合に起きること |
|---|---|---|
| 暗号アルゴリズム | AES、 Serpent、 Twofish などの安全性評価、鍵長、標準化状況である。 | 機密性の前提が崩れ、暗号化ディスクを主系にできなくなる。 |
| 暗号モード | CBC-ESSIV、 XTS、将来の完全性保護付き構成などの適性である。 | ディスク暗号化としての設計が時代遅れになる。 |
| KDF | PBKDF2、 Argon2id、 iteration、 memory cost、攻撃側ハードウェアである。 | パスフレーズ候補を高速に試されやすくなる。 |
| ヘッダー | LUKS ヘッダー、 TrueCrypt ヘッダー、バックアップ、対応媒体の識別である。 | データ本体が残っていても復号不能になる。 |
| 解除情報 | パスフレーズ、 keyfile、 token、 PIM、 hidden volume 条件である。 | 正当な利用者も開けなくなる、または弱い入口が残る。 |
| 物理媒体 | HDD、 SSD、 USB ブリッジ、筐体、ケーブル、記録方式、劣化である。 | 暗号方式以前に読み取り不能になる。 |
| 復旧環境 | OS、 cryptsetup、 VeraCrypt、 tcplay、ファイルシステム対応、手順書である。 | 媒体と鍵があっても開封手順を再現できなくなる。 |
8.3 標準は安全性だけでなく普及、実装、移行可能性で決まる
暗号の標準は、理論的に最も強い方式だけで決まるわけではない。標準として採用されるには、十分な安全性、実装しやすさ、性能、相互運用性、既存データからの移行可能性、障害時の復旧性、運用者が理解できる複雑さが必要になる。暗号化ディスクでは、この条件がさらに厳しい。バックアップは、毎日使うデータではなく、障害時、移行時、事故時、数年後、あるいは十年以上後に開ける必要がある。したがって、暗号方式は「強い」だけでは足りず、「将来も開ける」「移行できる」「記録できる」「検証できる」必要がある。
この点で、 LUKS2 + AES-XTS + Argon2id は現在の実用上の均衡点である。暗号モードとして XTS はストレージ向きであり、 KDF として Argon2id は現代的であり、 cryptsetup は Linux 運用と親和性が高い。しかし、この均衡点は固定ではない。将来、 cryptsetup の既定値が変わるかもしれない。 Argon2id の推奨 memory cost が上がるかもしれない。ストレージ暗号化に完全性保護を含める実装が一般化するかもしれない。あるいは、現実のバックアップ運用では、性能、互換性、媒体寿命の都合から、理想的な暗号構成だけでは判断できない場面が出るかもしれない。標準とは、その時点の安全性、性能、実装、運用可能性の折衷であり、時間とともに動く。
| 標準化の観点 | 必要な性質 | 長期運用での意味 |
|---|---|---|
| 安全性 | 既知の実用攻撃に対して十分な余裕がある。 | 新規主系に採用するための最低条件である。 |
| 性能 | 通常の同期、バックアップ、復旧で現実的な速度が出る。 | 強すぎるが使えない構成は、運用上の失敗を招く。 |
| 実装安定性 | 主要 OS や標準ツールで安定して扱える。 | 復旧時に特殊環境を要求する方式は、長期保全に不利である。 |
| 相互運用性 | 将来の環境でも読み出せる可能性が高い。 | 保管期間が長いバックアップでは、暗号強度と同じくらい重要である。 |
| 移行可能性 | 旧方式から新方式へ段階的に移せる。 | 即時置換ではなく、復元経路を保った更新が可能になる。 |
| 説明可能性 | 運用者が方式、鍵、手順、退役条件を記録できる。 | 理解不能な強方式より、管理可能な強方式の方がレジリエンスに寄与する。 |
8.4 暗号移行は一度の置換ではなく継続的な工程である
暗号移行は、古い媒体を見つけた瞬間に新しい媒体へコピーして終わる作業ではない。暗号化ディスクの移行では、まず既存媒体を識別し、方式を確認し、実際に開封し、内容を読み取り、必要データを新媒体へ同期し、新媒体側の復元確認を行い、その後で旧媒体の役割を縮小する必要がある。新媒体へコピーしただけでは不十分である。新媒体から復元できること、旧媒体にしかない差分がないこと、ヘッダーと解除情報が保存されていること、旧媒体をどの期間保持するかが決まっていることまで確認して、初めて移行として成立する。
この工程を無視して「古い方式だから廃棄」「新しい方式にコピーしたから安全」と判断すると、暗号方式は新しくなってもレジリエンスは下がる。たとえば、 LUKS1 媒体から LUKS2 媒体へコピーしたが、コピー中に一部ファイルが失敗していた、 TrueCrypt 媒体の hidden volume を見落としていた、 keyfile が必要なボリュームを台帳化していなかった、新しい LUKS2 ヘッダーのバックアップを取っていなかった、という状態では、移行したつもりで復元経路を失うことになる。暗号移行は、方式更新と復元検証を一体化した工程でなければならない。
| 工程 | 実施内容 | 不十分な例 | 成立条件 |
|---|---|---|---|
| 識別 | 媒体、容量、接続方式、形式、暗号方式、ファイルシステムを確認する。 | 古い HDD とだけ記録し、何が入っているか分からない。 | 媒体単位で識別子、方式、役割を記録する。 |
| 開封確認 | 実際に暗号化ボリュームを開き、必要に応じて読み取り専用でマウントする。 | パスフレーズは覚えているはず、という記憶だけに頼る。 | 開封成功日、使用ツール、解除条件を記録する。 |
| 内容確認 | ファイル数、容量、重要ディレクトリ、エラー、差分を確認する。 | コピーコマンドを実行しただけで検証しない。 | 移行対象データが新媒体に存在し、読み取れることを確認する。 |
| 新媒体作成 | LUKS2、 AES-XTS、 Argon2id など、現行主系として妥当な構成で作成する。 | 既定値を確認せず、後から方式が分からなくなる。 | luksDump 結果、ヘッダーバックアップ、 key slot 用途を台帳化する。 |
| 復元テスト | 新媒体を閉じ、再度開き、実際にデータを読み出す。 | 作成直後に開いたままコピーし、その後の開封を確認しない。 | 再開封と読み取り確認が成功している。 |
| 旧媒体縮退 | 旧媒体を読み取り中心、互換バックアップ、退役対象へ分類する。 | 旧媒体を無期限に主系と同じ扱いで残す。 | 保持期限、退役条件、再確認周期を決める。 |
8.5 完全性保護は今後の見直し論点になり得る
現在の LUKS2 + AES-XTS 構成を考えるとき、将来の重要論点のひとつは完全性保護である。 XTS は、ストレージ上のデータの機密性を守る方式であり、通常構成では改ざん検出や認証を提供しない。つまり、暗号化ディスクを第三者が読めないようにすることと、暗号文が壊れていない、あるいは改ざんされていないことを検出することは別の問題である。これは現在の構成が直ちに不適切という意味ではないが、長期運用では明確に分けて記録すべき点である。
バックアップ運用では、完全性は別の層で補うことが多い。ファイルシステムの整合性確認、チェックサム、 rsync の検証、重要アーカイブのハッシュ記録、複数媒体への重複保存、定期的な読み取り確認、復元テストがその役割を担う。将来、暗号化ストレージの標準が完全性保護をより強く含む方向へ進めば、現在の XTS 中心構成は「機密性は暗号層、完全性は運用層」という設計として古く見える可能性がある。したがって、現在の主系を採用する際にも、完全性を暗号方式が提供しているのか、別の運用で補っているのかを明記しておく必要がある。
| 性質 | 現在の XTS 構成での扱い | 長期運用での補完 |
|---|---|---|
| 機密性 | AES-XTS によって媒体紛失時の平文漏洩を防ぐ。 | 強いパスフレーズ、 KDF、 key slot 管理、物理保護と組み合わせる。 |
| 完全性 | 通常の XTS だけでは保証しない。 | チェックサム、読み取り確認、ファイルシステム検査、複数媒体で補う。 |
| 認証 | 暗号文の作成者や正当性を XTS だけでは確認しない。 | 署名、ハッシュ台帳、信頼できる保管手順で補う。 |
| 破損検出 | 暗号層だけでは十分に検出できない。 | 定期読み取り、 SMART、 fsck、アーカイブ検証、復元テストで補う。 |
8.6 暗号化ディスクの台帳は将来の移行判断を可能にする
現在の標準もいずれ古くなる以上、最も重要なのは、将来の移行判断に必要な情報を残すことである。暗号化ディスクは、見た目だけでは中身が分からない。 LUKS なら luksDump で多くの情報を確認できるが、 TrueCrypt 系ではパスフレーズなしに方式を一覧しにくい。媒体が増え、年月が経ち、接続先や運用目的が変わると、どの媒体が主系で、どの媒体が互換バックアップで、どの媒体が退役候補で、どの媒体が唯一の復元経路なのかが分からなくなる。台帳は、この不明化を防ぐための技術文書である。
台帳に記録すべきなのは、媒体名だけではない。 LUKS バージョン、暗号モード、 KDF、 KDF パラメーター、有効 key slot 数、 key slot の用途、ヘッダーバックアップの有無、ファイルシステム、媒体型番、容量、接続方式、最終開封確認日、最終読み取り確認日、主系か互換バックアップか、移行先、退役条件を記録する。 TrueCrypt 系なら、 TrueCrypt / VeraCrypt 判定、 cipher、 cascade、 mode、 PBKDF2 PRF、 keyfile 使用有無、 hidden volume 有無、バックアップヘッダー確認の有無も必要になる。これらは単なる記録ではなく、将来の暗号移行、媒体更新、退役判断を可能にするための前提である。
| 台帳項目 | LUKS 媒体での記録 | TrueCrypt 系媒体での記録 | 将来の判断に使う場面 |
|---|---|---|---|
| 形式 | LUKS1 または LUKS2 を記録する。 | TrueCrypt 7.1a、 VeraCrypt、互換モードを記録する。 | 主系、互換バックアップ、移行対象を分ける。 |
| 暗号方式 | AES-CBC-ESSIV、 AES-XTS、 plain64 などを記録する。 | AES、 Serpent、 Twofish、カスケード、 XTS などを記録する。 | 暗号モードの世代差を評価する。 |
| KDF | PBKDF2、 Argon2id、 iteration、 memory、 time cost を記録する。 | PBKDF2 PRF、 iteration、 PIM など該当する解除条件を記録する。 | パスフレーズ攻撃への耐性を見直す。 |
| 解除入口 | key slot 数、用途、 token、削除予定を記録する。 | パスフレーズ、 keyfile、 hidden volume、バックアップヘッダー条件を記録する。 | 不要な入口、弱い入口、復旧不能リスクを把握する。 |
| ヘッダー | ヘッダーバックアップの取得日、保管場所、対応 UUID を記録する。 | 通常ヘッダー、バックアップヘッダー確認、復元方法を記録する。 | ヘッダー破損時の復旧可否を判断する。 |
| 媒体 | 型番、容量、接続方式、ファイルシステム、エラー状況を記録する。 | 同様に物理媒体とコンテナの所在を記録する。 | 媒体寿命、性能問題、退役時期を判断する。 |
| 確認日 | 最終 open、マウント、読み取り、復元確認日を記録する。 | 最終開封確認、読み取り確認、使用ツールを記録する。 | 存在する媒体を復元可能な媒体として扱えるか判断する。 |
8.7 移行可能性を設計しない暗号化は、長期運用では弱い
暗号化ディスクで最も避けるべきなのは、現時点では強く見えるが、将来移行できない構成である。強い暗号方式を使っていても、ヘッダーのバックアップがなく、解除条件が記録されず、 keyfile の所在が不明で、媒体の役割も分からず、復元テストもされていないなら、それは長期運用として弱い。逆に、多少古い方式であっても、役割が限定され、開封確認が済み、移行先があり、退役条件が決まっていれば、レジリエンス上は管理された状態にある。
したがって、暗号化ディスクの設計では、現在の強度だけでなく、将来の変更可能性を設計する必要がある。これは、暗号方式を軽く見るということではない。現在の主系には、現在の標準的で妥当な構成を使うべきである。しかし、それと同時に、その構成が将来レガシー化したときに、何を見ればよいか、どの媒体を先に移行すべきか、どの旧媒体を保持すべきか、どの時点で退役できるかを判断できるようにしておく必要がある。移行可能性は、暗号化ディスクの安全性と復元可能性をつなぐ中間層である。
| 設計要素 | 短期的な意味 | 長期的な意味 |
|---|---|---|
| 現行標準の採用 | 現在の攻撃と実装環境に対して妥当な保護を得る。 | 将来の見直し時点まで主系として運用する基盤になる。 |
| 台帳化 | 媒体の方式、役割、解除条件を把握する。 | 将来の移行優先順位と退役判断を可能にする。 |
| ヘッダー保全 | ヘッダー破損時の復旧経路を確保する。 | 媒体寿命を超えたデータ移行時にも復号可能性を保つ。 |
| 復元テスト | 現在その媒体が開け、読めることを確認する。 | 将来の作業者が信頼できる復旧実績を残す。 |
| 役割分類 | 主系、互換バックアップ、移行対象、退役対象を分ける。 | 古い方式を無期限に主系化せず、復元経路も失わない。 |
| 退役条件 | いつ旧媒体を消してよいかを決める。 | 用途不明の古い暗号化ディスクを増やさない。 |
8.8 現在の標準を使うことと、標準を信仰することは違う
現在の標準を使うことは必要である。新規に暗号化ディスクを作るなら、現行環境で妥当な LUKS2、 AES-XTS、 Argon2id を使うのが自然である。古い LUKS1 + AES-CBC-ESSIV を新たに増やす必要はないし、保守終了した TrueCrypt 7.1a を主系として新規採用する理由も乏しい。しかし、現在の標準を採用することと、現在の標準を永続的な正解として信じ込むことは違う。標準は、ある時点の知識、攻撃能力、実装、性能、互換性、運用上の均衡であり、将来の変更を内包している。
長期運用で必要なのは、標準への追随と、標準の相対化を同時に行うことである。現在の主系には現在の標準を使う。一方で、旧方式を即時に全廃せず、互換バックアップや移行元として意味づける。さらに、現在の標準も将来は旧方式になることを前提に、台帳、ヘッダー保全、復元テスト、移行計画、退役条件を整える。この二重の姿勢がないと、暗号化ディスクは、最新方式への過信か、旧方式への惰性のどちらかに傾く。
| 姿勢 | 問題 | 望ましい運用 |
|---|---|---|
| 最新方式への過信 | 現在の LUKS2 構成なら将来も問題ないと考え、台帳や復元テストを軽視する。 | 現在の標準を採用しつつ、将来のレガシー化を前提に管理する。 |
| 旧方式への惰性 | 過去に使えていたからという理由で LUKS1 や TrueCrypt を主系として残し続ける。 | 旧方式は役割を限定し、現行主系へ段階的に移行する。 |
| 即時置換主義 | 古い方式を見つけると、復元確認なしに削除してしまう。 | 旧媒体を開封確認し、移行後の復元確認を終えてから退役する。 |
| 放置主義 | 古い媒体の方式、解除条件、媒体状態を確認せずに残す。 | 棚卸しし、台帳化し、再確認周期と退役条件を決める。 |
8.9 暗号化ディスクは更新され続ける構造である
現在の標準もいずれ古くなるという事実は、暗号化ディスクを固定された成果物ではなく、更新され続ける構造として扱う必要があることを示している。バックアップは、ある時点のコピーであると同時に、将来の復元可能性を維持する運用でもある。暗号化は、媒体紛失時の機密性を高めるが、鍵、ヘッダー、方式、ツール、媒体のどれかを失えば、正当な利用者にもデータを読ませなくする。したがって、暗号化ディスクは、作った瞬間に完成するのではなく、確認、記録、移行、退役を繰り返すことで維持される。
この観点に立つと、 LUKS1、 TrueCrypt、 LUKS2 は単なる新旧比較ではなく、長期運用の時間断面として見える。 LUKS1 は、過去の Linux 暗号化運用が残した互換層である。 TrueCrypt 7.1a は、保守終了したが XTS 系の設計を含む異質な旧資産である。 LUKS2 は、現在の主系として採用すべき構成である。そして将来には、現在の LUKS2 もまた旧資産になる。暗号化ディスクのレジリエンスとは、この移り変わりを前提に、復元経路を維持しながら主系を更新し、旧方式を意味のある形で縮退させる能力である。
結論として、現在の標準もいずれ古くなる。したがって、永久に安全な暗号方式を探すのではなく、現在の標準を採用し、それが将来レガシー化することを前提に、移行可能な運用を設計するべきである。 NIST の鍵管理ガイドラインは、暗号鍵の生成、使用、保管、アーカイブ、削除といったライフサイクル全体を扱っている[24]。また、 NIST SP 800-131A は、暗号アルゴリズムと鍵長の利用を移行するための考え方を示している[25]。この発想を暗号化ディスクに適用するなら、必要なのは一度きりの最適解ではなく、台帳化、ヘッダー保全、 key slot 管理、パスフレーズ更新方針、復元テスト、移行計画、退役条件を含むライフサイクル設計である。
9. 暗号化ディスクではデータだけでなく復元条件を保存する
暗号化ディスクでは、保存すべきものはデータ本体だけではない。暗号化されていない通常のファイルであれば、ある程度はファイルそのものが残っていることと復元可能性が近い。しかし、暗号化ディスクでは、データ本体が残っていても、それを開くための条件が失われれば復元できない。 LUKS ヘッダー、 key slot、パスフレーズ、 keyfile、 cryptsetup の対応形式、マウント手順、 crypttab や fstab の設定、媒体の物理的識別、最終開封確認日、最終読み取り確認日、退役条件まで含めて、復元条件として扱う必要がある。暗号化は、媒体を紛失したときに第三者からデータを守る一方で、正当な利用者が復元するための条件を鍵、ヘッダー、手順、媒体管理に集中させる。
この章で主張したいのは、バックアップとはファイルの複製ではなく、将来そのファイルを取り戻せる状態の複製だということである。非暗号化ディスクでは、ファイルシステムが一部壊れても、残ったファイルを救出できる場合がある。ディレクトリ構造が壊れても、断片的に読めることがある。ところが、暗号化ブロックデバイスでは、ヘッダー、鍵導出、 key slot、パスフレーズ、 keyfile、暗号方式の解釈が成立しなければ、暗号化されたデータ本体は意味のあるファイルへ戻らない。データは存在しているのに読めない、という状態が起きる。この意味で、暗号化ディスクの本体は、暗号文そのものではなく、暗号文を平文へ戻すための条件全体である。
| 観点 | 通常のバックアップ | 暗号化ディスク |
|---|---|---|
| 保存対象 | 主にファイル本体、ディレクトリ構造、メタデータを保存する。 | ファイル本体に加えて、暗号形式、ヘッダー、解除情報、手順、対応ツールを保存する。 |
| 破損時の救出 | 一部ファイルだけを救出できる場合がある。 | ヘッダーや解除条件が破綻すると、全体を読めなくなる場合がある。 |
| 媒体紛失時 | 第三者に内容を読まれる可能性がある。 | 暗号化により内容を読まれにくくできる。 |
| 正当な復元 | 媒体が読めれば復元できる可能性が比較的高い。 | 媒体、ヘッダー、パスフレーズ、 keyfile、ツール、手順が揃う必要がある。 |
| 管理の中心 | どのファイルをどこへ保存したかが中心になる。 | どの条件が揃えば将来復元できるかが中心になる。 |
9.1 暗号化は復元経路を強くするのではなく、条件付きにする
暗号化は、バックアップを安全にする技術である。しかし、それは復元を簡単にする技術ではない。暗号化の目的は、権限のない者にデータを読ませないことである。そのため、正当な利用者であっても、必要な条件を満たさなければ読めない。これは暗号化の失敗ではなく、暗号化の本質である。 LUKS では、データ本体はランダムなボリュームキーで暗号化され、そのボリュームキーへ到達する入口として key slot が存在する。パスフレーズは KDF によって key slot を開くための鍵材料へ変換され、その結果としてボリュームキーを取り出せる。したがって、データ本体、 LUKS ヘッダー、 key slot、 KDF パラメーター、パスフレーズのどれかが破綻すれば、復元経路は切断される。
この構造は、長期運用では非常に重い意味を持つ。暗号化していないファイルのバックアップでは、媒体が古くなっても、読めるファイルから順に救出するという発想が成立しやすい。暗号化ブロックデバイスでは、まず暗号化層を正しく開かなければファイルシステムに到達できない。 LUKS ヘッダーを失った媒体、パスフレーズが分からない媒体、 keyfile が所在不明の TrueCrypt ボリューム、方式確認ができない暗号化コンテナは、物理的にはデータを保持していても、実務上は復元不能に近い。暗号化ディスクでは、データを保存するだけでなく、復号に至る経路を保存しなければならない。
| 復元条件 | 役割 | 欠けた場合 |
|---|---|---|
| 暗号化データ本体 | 復元したいファイルやファイルシステムを暗号化した実体である。 | 復元対象そのものが失われる。 |
| LUKS ヘッダー | key slot、 KDF、暗号方式、ボリュームキー保護情報を保持する。 | データ本体が残っていても復号不能になり得る。 |
| key slot | パスフレーズごとの解除入口である。 | どの入口で開けるのか分からなくなる、または弱い入口が残る。 |
| パスフレーズ | 正当な利用者が key slot を開くための秘密情報である。 | 正当な利用者でも開けなくなる。 |
| keyfile | パスフレーズに追加される解除条件である。 | パスフレーズが正しくても開けない場合がある。 |
| 対応ツール | cryptsetup、 VeraCrypt、 tcplay など、形式を解釈する実装である。 | 媒体と解除情報があっても開封手順を再現できない。 |
| 手順書 | どの順番で open、 mount、 verify、 close するかを示す。 | 誤操作、同期方向の取り違え、対象デバイスの取り違えが起きやすくなる。 |
9.2 LUKS ヘッダーは暗号化ディスクの生命線である
LUKS では、ヘッダーが特に重要である。 LUKS ヘッダーには、暗号化デバイスを開くために必要な管理情報が含まれる。 LUKS1 であれば、固定的なヘッダー構造、 key slot、 payload offset、 cipher、 mode、 hash、 salt、 iteration などが関係する。 LUKS2 であれば、 JSON ベースのメタデータ、 keyslot、 segment、 digest、 token、 Argon2id の time cost や memory などが関係する。いずれにしても、ヘッダーは暗号化されたデータ領域へ到達するための入口であり、データ本体と同じか、それ以上に慎重に扱う必要がある。
ヘッダーが壊れると、データ本体が完全に残っていても復号できない可能性がある。これは暗号化ディスクの最大の落とし穴のひとつである。非暗号化ファイルなら、ファイルシステムの一部破損から一部ファイルを救えることがある。しかし、 LUKS ヘッダーが壊れ、バックアップヘッダーもなく、 key slot 情報も失われれば、暗号文から平文へ戻る入口が消える。したがって、 LUKS ヘッダーは単なる付属情報ではなく、復元条件そのものである。ヘッダーバックアップを取得し、対象 UUID、取得日、対応媒体、保管場所、復元手順を記録することは、暗号化ディスクの基本的な保全作業である。
| ヘッダー関連項目 | 記録内容 | 理由 |
|---|---|---|
| UUID | どの LUKS 媒体のヘッダーかを記録する。 | ヘッダーバックアップと実媒体を取り違えないためである。 |
| LUKS バージョン | LUKS1 か LUKS2 かを記録する。 | ヘッダー構造、復旧手順、対応ツールの前提が変わるためである。 |
| 暗号方式 | AES-CBC-ESSIV、 AES-XTS、 plain64 などを記録する。 | 媒体の世代と移行優先度を判断するためである。 |
| KDF | PBKDF2、 Argon2id、 iteration、 time cost、 memory を記録する。 | パスフレーズ攻撃への耐性と復旧時の処理負荷を評価するためである。 |
| key slot | 有効数、用途、作成時期、削除予定を記録する。 | 不要な解除入口や用途不明の入口を残さないためである。 |
| ヘッダーバックアップ | 取得日、保管先、対応媒体、復元手順を記録する。 | ヘッダー破損時の復旧経路を確保するためである。 |
9.3 key slot は復旧経路であると同時に攻撃面でもある
LUKS の key slot は、復旧性と攻撃面の両方に関わる。複数の key slot を持てば、通常用、緊急用、移行用など複数の解除経路を用意できる。これは復旧性を高める。一方で、どれか 1 つの key slot が弱ければ、その弱い入口から同じボリュームキーへ到達される可能性がある。暗号化データ本体は同じであり、攻撃者は最も強い入口を破る必要はない。最も弱い入口を狙えばよい。このため、 key slot は増やせばよいものではなく、用途、強度、期限、削除条件を管理する必要がある。
長期運用で危険なのは、用途不明の key slot が残ることである。作業時に一時的に追加したパスフレーズ、古い短いパスフレーズ、退職者や過去環境に由来する解除経路、テスト用の入口が残っていると、暗号化方式が強くても全体の安全性は下がる。逆に、 key slot を減らしすぎて唯一の解除経路だけに依存すると、パスフレーズ喪失時の復旧性が下がる。したがって、 key slot 管理は、最小化と冗長化の均衡である。不要な入口は削除し、必要な入口は用途と保管方針を明確にし、定期的に開封確認する。
| key slot の状態 | 復旧性への影響 | 安全性への影響 | 対応 |
|---|---|---|---|
| 用途が明確な通常用 key slot | 日常的な開封経路として機能する。 | 強いパスフレーズと適切な KDF であれば妥当である。 | 用途、管理者、確認日を台帳化する。 |
| 緊急用 key slot | 通常経路喪失時の復旧経路になる。 | 保管方法が弱いと攻撃面になる。 | 保管場所、利用条件、確認周期を明確にする。 |
| 移行用 key slot | 作業中の一時的な復旧性を高める。 | 作業後に残ると不要な攻撃面になる。 | 移行完了後に削除する。 |
| 用途不明 key slot | 復旧経路として信頼できない。 | 弱い入口の可能性がある。 | 確認後、不要なら削除する。 |
| 唯一の key slot | パスフレーズ喪失時の冗長性がない。 | 入口が少ないため攻撃面は限定される。 | 緊急用経路を設けるか、別媒体の復元経路で補う。 |
9.4 TrueCrypt 系では解除条件そのものを記録しなければならない
TrueCrypt 系の暗号化ボリュームでは、 LUKS とは異なる注意が必要である。 LUKS では luksDump によって、形式、 cipher、 key slot、 KDF などの管理情報を比較的読み取りやすい。一方、 TrueCrypt 系ではヘッダーが暗号化されており、パスフレーズなしで方式を一覧することが難しい。方式確認には cryptsetup tcryptDump や tcplay を使うが、基本的には正しいパスフレーズ、必要なら keyfile、 hidden volume の条件、バックアップヘッダーの指定などを揃えてヘッダー復号を試みる必要がある。つまり、 TrueCrypt 系では、解除条件そのものが復元条件である。
この違いは、台帳化の設計に直結する。 TrueCrypt 7.1a、 VeraCrypt、通常ボリューム、 hidden volume、 keyfile 使用、バックアップヘッダー、 PBKDF2 PRF、 cipher cascade などを曖昧にすると、将来の復元時にどの条件で開けばよいのか分からなくなる。特に hidden volume は、外側ボリュームと内側ボリュームの扱いを混同すると、存在確認や復元手順を誤る可能性がある。 TrueCrypt 系の旧資産を互換バックアップとして残すなら、単に「TrueCrypt 媒体」とだけ書くのではなく、開封確認済みの条件と確認日を残す必要がある。
| TrueCrypt 系の項目 | 記録する内容 | 記録しない場合の問題 |
|---|---|---|
| 形式判定 | TrueCrypt 7.1a として開けたのか、 VeraCrypt 互換として開けたのかを記録する。 | KDF や解除条件の前提を誤る。 |
| ボリューム種別 | 通常ボリューム、 hidden volume、外側ボリューム、バックアップヘッダー確認を記録する。 | 復元対象を取り違える。 |
| cipher / cascade | AES、 Serpent、 Twofish、カスケード構成を記録する。 | 処理負荷や方式世代を評価できない。 |
| mode | XTS などの暗号モードを記録する。 | LUKS1 や LUKS2 との比較ができない。 |
| PBKDF2 PRF | ヘッダーキー導出に使われるハッシュ関数を記録する。 | パスフレーズ攻撃耐性や互換性を評価できない。 |
| keyfile | 使用有無、保管方針、復元時の指定方法を記録する。 | パスフレーズがあっても開けない。 |
| 開封確認 | 使用ツール、確認日、読み取り確認結果を記録する。 | 存在しているだけで復元可能かどうか判断できない。 |
9.5 fstab と crypttab は自動化の設定であり、復旧手順そのものではない
暗号化ディスクを運用していると、 fstab や crypttab に設定を書き、起動時や接続時に自動的にマウントできるようにすることがある。これは便利である。しかし、 fstab や crypttab は復旧手順そのものではない。これらは現在のホスト、現在のデバイス名、現在の UUID、現在の systemd、現在の cryptsetup、現在のマウントポイントに依存した設定である。将来の復旧環境では、デバイス名が変わり、ホスト名が変わり、マウントポイントが存在せず、 crypttab の名前も異なる可能性がある。したがって、自動化設定だけを残しても、復旧条件を保存したことにはならない。
復旧手順として必要なのは、どの媒体を、どのコマンドで、どの名前で open し、どこへ読み取り専用または読み書きでマウントし、何を確認し、どの順序で close するかである。さらに、通常運用と復旧運用は分けるべきである。通常運用では自動マウントや定期同期が便利であっても、復旧時には誤って古い媒体へ書き込まないこと、同期方向を間違えないこと、読み取り専用で確認することが重要になる。 fstab や crypttab は運用設定であり、復旧手順書は判断と手順を含む運用設計書である。
| 項目 | 役割 | 限界 | 補うべき文書 |
|---|---|---|---|
| crypttab | 暗号化デバイスをどの名前で open するかを定義する。 | 現在の OS と起動構成に依存する。 | 手動 open 手順、対象 UUID、緊急時の確認手順を残す。 |
| fstab | ファイルシステムをどこへマウントするかを定義する。 | 現在のマウントポイントとファイルシステム前提に依存する。 | 読み取り専用マウント手順、検証手順、アンマウント手順を残す。 |
| 自動マウント | 日常運用の手間を減らす。 | 復旧時には誤操作や自動書き込みのリスクになる。 | 復旧時は自動化を使うか、手動で開くかを明記する。 |
| 同期スクリプト | 定期的なバックアップや差分同期を実行する。 | 同期方向を誤ると復元対象を上書きする。 | 復旧時の実行禁止条件、 dry-run、読み取り確認手順を残す。 |
9.6 媒体の物理的識別は暗号化ディスクの基本である
暗号化ディスクでは、媒体の物理的識別も復元条件である。暗号化されたブロックデバイスは、見た目だけでは中身が分からない。デバイス名は接続順によって変わるため、 /dev/sdb、 /dev/sdc、 /dev/sdd のような名前に依存すると誤操作が起きる。 luksDump の UUID、物理媒体の型番、容量、シリアル、ラベル、保管場所、接続方式、マウント先、役割を台帳化しなければならない。特に複数の外付け HDD や SSD を使う場合、同じ容量の媒体を取り違える危険は高い。
媒体識別を誤ると、復元失敗だけでなく破壊的な事故につながる。移行先と移行元を逆にして同期する、古い互換バックアップへ新しいデータを上書きする、退役対象ではない媒体を消去する、ヘッダーバックアップを別媒体へ対応づける、といった事故が起きる。暗号化ディスクでは中身をすぐに確認できないため、媒体識別の精度は通常のバックアップ以上に重要である。台帳では、 OS 上の一時的なデバイス名ではなく、 UUID、型番、容量、物理ラベル、保管位置を組み合わせて識別すべきである。
| 識別項目 | 記録内容 | 目的 |
|---|---|---|
| 物理ラベル | 媒体に貼ったラベル名や管理番号を記録する。 | 人間が目視で取り違えないようにする。 |
| 型番 | Seagate、 Transcend などの製品型番を記録する。 | 媒体性能や既知の挙動を後から評価する。 |
| 容量 | 2TB、 5TB などの容量を記録する。 | 同名媒体や同系列媒体の識別を補助する。 |
| シリアル | 取得できる場合はディスクシリアルを記録する。 | 物理個体を一意に近い形で識別する。 |
| LUKS UUID | luksDump に表示される UUID を記録する。 | ヘッダーバックアップや crypttab 設定と対応づける。 |
| 保管場所 | 通常保管場所、持ち出し有無、隔離保管の有無を記録する。 | 災害、盗難、媒体紛失への備えを管理する。 |
| 役割 | 主系、互換バックアップ、移行元、退役候補を記録する。 | 誤って主系と旧媒体を同じ扱いにしないためである。 |
9.7 最終検証日は復元可能性の証拠である
バックアップ媒体は、存在しているだけでは復元可能とは言えない。最後にいつ開けたのか、いつ読み取れたのか、いつ実際に復元テストを行ったのかを記録して初めて、復元可能性を評価できる。暗号化ディスクでは、この確認はさらに重要である。パスフレーズが正しいか、 keyfile が揃っているか、 LUKS ヘッダーが読めるか、 cryptsetup が対応しているか、ファイルシステムがマウントできるか、重要ディレクトリが読めるか、ファイル数や容量が想定と一致するかを確認する必要がある。
最終検証日が古い媒体は、暗号方式が強いか弱いか以前に、現在も復元可能か分からない。特に長期保管した HDD では、接続不良、読み取りエラー、 USB ブリッジの故障、ファイルシステムの不整合、ヘッダー破損が起き得る。 SSD でも、長期無通電保管やコントローラー故障の問題がある。したがって、バックアップの台帳には、作成日だけではなく、最終 open 確認日、最終マウント確認日、最終読み取り確認日、最終復元テスト日を記録すべきである。これらは形式的な履歴ではなく、その媒体を復元可能資産として扱えるかを判断する証拠である。
| 検証項目 | 確認内容 | 意味 |
|---|---|---|
| open 確認 | 暗号化デバイスを正しい条件で開けることを確認する。 | パスフレーズ、 keyfile、 KDF、ヘッダーが成立していることを示す。 |
| マウント確認 | ファイルシステムを読み取り専用または通常モードでマウントできることを確認する。 | 暗号化層の先にファイルシステムとして到達できることを示す。 |
| 読み取り確認 | 重要ディレクトリや代表ファイルを実際に読めることを確認する。 | 見かけ上マウントできるだけではなく、実データが読めることを示す。 |
| 整合性確認 | ファイル数、容量、チェックサム、ログのエラーを確認する。 | コピー漏れ、破損、読み取り不能を検出する。 |
| 復元テスト | 別の場所へ一部または全体を復元して利用可能性を確認する。 | バックアップが実際の復旧に使えることを確認する。 |
| close 確認 | アンマウント、 cryptsetup close、 sync、電源断手順を確認する。 | 安全に作業を終了し、次回も開ける状態を保つ。 |
9.8 復元条件は一箇所に集中させず、守り方を分ける
復元条件を保存するとは、すべてを同じ場所に置くことではない。パスフレーズ、 keyfile、ヘッダーバックアップ、媒体台帳、復旧手順書を同じ媒体にまとめて保存すると、その媒体を失ったときに復元条件全体を失う。逆に、すべてを暗号化ディスクの内部だけに置くと、その媒体を開けないと復元手順を読めないという循環が起きる。復元条件は、機密性が必要な情報と、手順として共有可能な情報を分けて保管する必要がある。
たとえば、ヘッダーバックアップは、それ自体が機密情報ではない場合でも、攻撃者に渡すとオフライン攻撃の材料になるため、保護された場所に保管すべきである。パスフレーズや keyfile は明確に秘密情報であり、媒体本体とは別の安全な保管方法が必要である。一方、復旧手順書、媒体台帳、コマンド手順、マウント方針、退役条件は、秘密そのものではないが、誤操作を防ぐために正確でなければならない。暗号化ディスクの復元条件は、秘密情報、準秘密情報、手順情報に分け、それぞれに応じた保管方針を持つべきである。
| 情報種別 | 例 | 保管方針 | 注意点 |
|---|---|---|---|
| 秘密情報 | パスフレーズ、 keyfile、 volume key などである。 | 媒体本体とは分離し、強く保護された場所に保管する。 | volume key は通常出力せず、ログや作業記録に残さない。 |
| 準秘密情報 | LUKS ヘッダーバックアップ、 TrueCrypt ヘッダー関連情報である。 | 対象媒体と対応づけつつ、アクセス制御された場所に保管する。 | 攻撃者に渡すとオフライン攻撃の材料になる可能性がある。 |
| 手順情報 | open、 mount、 verify、 close、復元手順、退役手順である。 | 暗号化ディスクの外部にも読める形で保管する。 | 秘密を書かず、再現可能な手順として管理する。 |
| 台帳情報 | 媒体名、 UUID、役割、最終確認日、方式、退役条件である。 | 定期的に更新し、復旧時に参照できる場所へ置く。 | 媒体本体と台帳の対応関係を崩さない。 |
| 検証履歴 | 開封確認日、読み取り確認日、復元テスト結果である。 | 作業記録として保存し、次回判断の根拠にする。 | 成功だけでなく失敗や警告も記録する。 |
9.9 復元条件を保存するには台帳、手順書、検証履歴が必要である
暗号化ディスクの復元条件を保存するには、少なくとも 3 種類の文書が必要になる。第一に、媒体台帳である。これは、どの媒体が何で、どの方式で暗号化され、どの役割を持ち、最後にいつ確認されたかを記録する。第二に、作業手順書である。これは、通常運用、読み取り確認、復元、移行、退役の手順を記録する。第三に、検証履歴である。これは、実際にいつ開けたか、何を確認したか、エラーがあったか、どの媒体へ移行したかを記録する。これらが揃って初めて、将来の復元作業は記憶ではなく文書に基づいて実行できる。
この 3 種類を混同すると、運用が曖昧になる。媒体台帳に手順を書きすぎると更新しにくくなる。手順書に媒体ごとの状態を書きすぎると、媒体が増えたときに破綻する。検証履歴がなければ、台帳上は存在している媒体が本当に開けるのか分からない。したがって、媒体台帳は現在状態、手順書は再現可能な操作、検証履歴は過去の実績として分けるのがよい。この分離により、長期運用でも更新しやすく、誤操作を減らしやすい。
| 文書 | 主な内容 | 更新タイミング | 役割 |
|---|---|---|---|
| 媒体台帳 | 媒体 ID、型番、容量、 UUID、暗号方式、 KDF、役割、最終確認日、退役条件を記録する。 | 媒体作成、移行、確認、退役のたびに更新する。 | どの媒体が何であるかを判断する基礎資料である。 |
| 作業手順書 | open、 mount、 verify、 sync、 restore、 close、退役の手順を記録する。 | 手順変更、ツール変更、運用方針変更のたびに更新する。 | 記憶に頼らず安全に作業するための操作基準である。 |
| 検証履歴 | 開封確認、読み取り確認、復元テスト、エラー、警告、移行結果を記録する。 | 確認作業や復元作業のたびに追記する。 | 復元可能性の実績を示す証拠である。 |
| 変更履歴 | 暗号方式、媒体役割、 key slot、手順、退役条件の変更を記録する。 | 設計や運用方針を変更したときに更新する。 | なぜ現在の構成になっているかを説明する。 |
9.10 暗号化ディスクは保存時点ではなく復元時点で評価される
バックアップの価値は、作成した時点ではなく、復元が必要になった時点で決まる。作成時にコピーが成功していても、数年後に媒体が読めなければ意味がない。暗号化方式が当時の標準であっても、将来の環境で開けなければ意味がない。パスフレーズを覚えていたつもりでも、実際に入力して開けなければ意味がない。ヘッダーバックアップを取ったつもりでも、どの媒体に対応するか分からなければ意味がない。バックアップは、保存したことではなく、復元できたことによって初めて価値を証明する。
暗号化ディスクでは、この復元時点の評価がさらに厳しい。復元時には、媒体、暗号方式、ヘッダー、 key slot、パスフレーズ、 keyfile、ツール、 OS、ファイルシステム、手順、判断基準がすべて揃う必要がある。だからこそ、定期的な復元テストが必要になる。復元テストは、単に安心するための儀式ではない。保存された復元条件が現在も成立しているかを検証する作業である。 open できるか、 mount できるか、読めるか、戻せるか、閉じられるかを確認することで、バックアップがただの保管物ではなく、復元可能な資産であることを確認する。
| 評価時点 | 見かけ上の状態 | 本当に確認すべきこと |
|---|---|---|
| 作成直後 | コピーが完了し、媒体が存在する。 | 閉じた後に再度開けるか、別環境でも読めるかを確認する。 |
| 保管中 | 媒体が棚や保管場所に残っている。 | 定期的に接続し、開封、読み取り、エラー確認を行う。 |
| 移行時 | 新媒体へコピーした。 | 新媒体から実際に復元でき、旧媒体にしかない差分がないことを確認する。 |
| 障害時 | バックアップが存在するはずである。 | 手順書と台帳に基づいて、安全に復元できるかを確認する。 |
| 退役時 | 古い媒体を消してよさそうに見える。 | 新媒体の復元確認、重複保存、保持期間、退役条件を満たしているかを確認する。 |
9.11 復元条件を保存することがレジリエンスの中核である
レジリエンスとは、単に壊れないことではない。壊れても戻せること、古くなっても移行できること、方式が変わっても意味を失わないこと、誤操作しても被害を局所化できること、将来の環境で復元判断を再現できることである。暗号化ディスクでは、このレジリエンスはデータ本体の複製だけでは実現できない。復元条件、つまりヘッダー、鍵、手順、媒体識別、検証履歴、退役条件まで保存して初めて成立する。
この観点に立つと、 LUKS1、 LUKS2、 TrueCrypt、 VeraCrypt、 AES-CBC-ESSIV、 AES-XTS、 PBKDF2、 Argon2id といった個別技術は、すべて復元条件を構成する部品である。どれか一つを最新にすれば終わるわけではない。 LUKS2 + AES-XTS + Argon2id を使っていても、ヘッダー保全と復元テストがなければ脆い。 TrueCrypt 7.1a の旧媒体でも、読み取り確認済みで移行元として管理されていれば、期間限定の復元経路として意味を持つ。暗号化ディスクの価値は、方式の新しさだけでなく、復元条件が管理されているかで決まる。
| レジリエンス要素 | 暗号化ディスクでの意味 | 実施内容 |
|---|---|---|
| 冗長性 | 同じデータを複数媒体、複数世代、必要に応じて異なる方式で保持する。 | 主系、互換バックアップ、移行元を分けて管理する。 |
| 可観測性 | 媒体の方式、状態、最終確認日、役割が見える状態にする。 | 媒体台帳、 luksDump、 tcryptDump、検証履歴を残す。 |
| 復元性 | 必要なときに正当な利用者が開け、読め、戻せる状態にする。 | 復元テスト、手順書、ヘッダー保全、解除情報管理を行う。 |
| 移行性 | 方式や媒体が古くなったときに新構成へ移せる状態にする。 | 旧媒体を棚卸しし、新媒体へ同期し、復元確認後に縮退させる。 |
| 縮退性 | 旧方式を無期限に主系化せず、役割を段階的に小さくする。 | 保持期限、再確認周期、退役条件を定義する。 |
| 誤操作耐性 | 同期方向、対象デバイス、削除対象の取り違えを防ぐ。 | 物理ラベル、 UUID、 dry-run、読み取り専用マウント、作業手順書を使う。 |
結論として、バックアップとはデータではなく復元条件を保存することである。暗号化ディスクでは、データ本体、 LUKS ヘッダー、 key slot、パスフレーズ、 keyfile、 cryptsetup や VeraCrypt の対応状況、 fstab や crypttab の設定、媒体識別、最終検証日、復元手順、退役条件が一体となって復元可能性を作る。データ本体が残っていても、ヘッダーが壊れれば開けない。パスフレーズが失われれば開けない。 keyfile がなければ開けない。媒体がどれか分からなければ誤操作が起きる。手順がなければ復旧時に判断を誤る。したがって、暗号化ディスクの設計では、ファイルを複製するだけでなく、将来それを正しく復元できる条件を、台帳、手順書、検証履歴として保存し続ける必要がある。
10. 同質冗長性と異質冗長性を分けて考える
レジリエンスを考えるとき、冗長性を「同じものを複数持つこと」とだけ捉えると不十分である。同じ LUKS2 + AES-XTS + Argon2id + ext4 のバックアップ媒体を複数台持つことは、明確に重要である。媒体故障、紛失、誤削除、同期失敗、単一ディスク障害に対して強くなるからである。しかし、それは同質冗長性である。同質冗長性は、同じ方式、同じファイルシステム、同じ暗号化形式、同じ運用手順、同じ復旧環境に依存する。したがって、同じ構成に共通する実装バグ、設定ミス、運用ミス、ファイルシステム特性、復旧環境の制約に同時に巻き込まれる可能性がある。
これに対して、異質冗長性は、異なる方式、異なる媒体、異なるファイルシステム、異なる暗号化形式、異なる復旧経路を意図的に残す考え方である。たとえば、現在の主系として LUKS2 + AES-XTS + Argon2id + ext4 を使いながら、過去の LUKS1 + AES-CBC-ESSIV + PBKDF2 媒体を移行元または互換バックアップとして一定期間残す。さらに、 TrueCrypt 7.1a + FAT の旧媒体を読み取り中心アーカイブとして保持する。体系としては不揃いであり、管理は複雑になる。しかし、復元経路は多様になる。ある方式、あるファイルシステム、ある媒体特性、あるツールチェーンに問題が出たとき、別経路から復元できる可能性が残る。
| 冗長性の種類 | 意味 | 強い場面 | 弱い場面 |
|---|---|---|---|
| 同質冗長性 | 同じ方式、同じ手順、同じ構成の媒体を複数持つ。 | 単純な媒体故障、紛失、コピー失敗に強い。 | 共通の設計ミス、実装問題、運用ミス、復旧環境依存には弱い。 |
| 異質冗長性 | 異なる方式、異なる媒体、異なるファイルシステム、異なる復旧経路を併存させる。 | 単一方式依存、移行失敗、特定環境での不具合に強い。 | 台帳、手順、確認履歴がないと管理不能になりやすい。 |
10.1 同質冗長性は必要だが、それだけでは単一方式依存を解消できない
同質冗長性は、バックアップの基本である。同じ主系構成の媒体を複数持つことで、 1 台の HDD が壊れても別媒体から復元できる。 1 回の同期で失敗しても、別世代が残る。保管場所を分ければ、盗難、災害、誤操作に対する耐性も上がる。したがって、同質冗長性を軽視してはならない。現在の主系を LUKS2 + AES-XTS + Argon2id + ext4 と決めたなら、その構成で複数媒体を作り、同期し、開封確認し、復元テストすることは、レジリエンスの基礎である。
しかし、同質冗長性には構造的な限界がある。複数台に同じ構成を作ると、管理は単純になるが、同じ前提にも依存する。たとえば、すべての主系媒体が LUKS2 + ext4 であれば、 LUKS2 の扱い、 cryptsetup の互換性、 ext4 のメタデータ更新特性、同じ rsync 手順、同じマウント設計、同じパスフレーズ管理方針に依存する。設定ミスも複製されやすい。同期方向を誤れば、複数媒体へ同じ誤りが伝播する。ファイル削除をバックアップへ即時反映する設計なら、複数台あっても論理削除には弱くなる。つまり、同じ構成を複数持つことは、物理障害には強くても、共通原因故障には必ずしも強くない。
| 同質冗長性の効果 | 具体例 | 残るリスク |
|---|---|---|
| 媒体故障への耐性 | LUKS2 + ext4 の外付け HDD を複数台持つ。 | 同じ同期ミスや削除ミスが複数台へ伝播する可能性がある。 |
| 運用手順の単純化 | すべて同じ cryptsetup open、 mount、 rsync、 close 手順で扱える。 | 手順そのものに誤りがある場合、すべての媒体に同じ影響が出る。 |
| 復旧作業の標準化 | 復旧時に同じ手順書を使える。 | その手順書が想定する OS、 cryptsetup、ファイルシステムに依存する。 |
| 管理負荷の低減 | 台帳項目、暗号方式、 KDF、ファイルシステムを揃えられる。 | 異なる復元経路が存在しないため、単一方式の問題に弱い。 |
10.2 異質冗長性は不揃いさをリスク分散に変える考え方である
異質冗長性は、単に古い媒体を残すことではない。不揃いな方式を、意図を持って役割分担させることである。 LUKS2 + ext4 の主系媒体は、現在の更新対象として使う。 LUKS1 旧媒体は、過去の Linux 暗号化運用を保持する互換バックアップまたは移行対象として扱う。 TrueCrypt + FAT 旧媒体は、保守終了ソフトウェアと古いファイルシステムという弱点を持つが、過去環境との接続性や LUKS2 + ext4 とは異なる復元経路として、読み取り中心アーカイブの役割を持ち得る。これらは同列の主系ではないが、体系全体としては復元経路の多様性を作る。
異質冗長性の本質は、単一の最適化にすべてを賭けないことである。最新方式へ統一すれば、見通しはよくなる。しかし、移行時のコピー漏れ、 ext4 での小ファイル大量更新の性能問題、特定媒体での LUKS + ext4 の遅延、 cryptsetup 設定の誤り、ヘッダー管理の失敗、特定ホストでのマウント問題が起きたとき、過去の別方式が残っていれば逃げ道になる場合がある。これは旧方式を主系として正当化する話ではない。旧方式を、役割を縮小した復元経路として意味づける話である。
| 構成 | 位置付け | 異質冗長性としての意味 | 制約 |
|---|---|---|---|
| LUKS2 + AES-XTS + Argon2id + ext4 | 現在の主系バックアップである。 | 現行標準に近い暗号化と Linux 運用との整合性を持つ。 | 将来はレガシー化し、完全性保護は別層で補う必要がある。 |
| LUKS1 + AES-CBC-ESSIV + PBKDF2 | 旧 Linux 暗号化ディスクである。 | 過去の復元経路、移行元、互換バックアップとして意味を持つ。 | 新規主系には向かず、 key slot とパスフレーズの棚卸しが必要である。 |
| TrueCrypt 7.1a + XTS 系 | 保守終了した旧暗号化資産である。 | LUKS とは異なるヘッダー形式、ツール、ファイルシステム経路を残せる。 | KDF と保守状況ではレガシーであり、方式確認と開封確認が必須である。 |
| TrueCrypt + FAT | 旧互換バックアップまたは読み取り中心アーカイブである。 | ext4 とは異なるファイルシステム特性と過去環境への接続性を持つ。 | 権限、シンボリックリンク、大容量ファイル、文字コード、更新運用に制約がある。 |
10.3 異質冗長性は放置ではなく管理された多様性である
異質冗長性は、古い方式を何となく残すことでは成立しない。むしろ、管理されていない旧媒体はレジリエンス資産ではなくリスクである。媒体の所在が分からない、パスフレーズが不明、 keyfile が見つからない、 TrueCrypt か VeraCrypt か分からない、 LUKS1 の key slot が何のために残っているか分からない、最後に開けた日が不明、媒体の劣化状態を確認していない。このような状態では、古い媒体は復元経路ではなく、将来の混乱要因になる。異質冗長性が価値を持つためには、不揃いな方式を不揃いなまま放置するのではなく、それぞれの役割、制約、復元条件、退役条件を明示する必要がある。
管理された異質冗長性では、旧方式には必ず役割を与える。主系ではなく、互換バックアップ、読み取り中心アーカイブ、移行元、過去世代の保全、移行失敗時の逃げ道として位置づける。さらに、最終開封確認日、読み取り確認日、保管場所、パスフレーズ管理、 keyfile 使用有無、ヘッダーバックアップ、退役条件を台帳化する。これにより、旧媒体を「何となく怖いから残す」のではなく、「この条件を満たす間だけ、この目的で残す」と定義できる。レジリエンスに必要なのは、多様性そのものではなく、管理された多様性である。
| 状態 | 見かけ | 実態 | 評価 |
|---|---|---|---|
| 管理された異質冗長性 | LUKS2、 LUKS1、 TrueCrypt が併存している。 | 各媒体の役割、方式、解除条件、確認日、退役条件が台帳化されている。 | 復元経路の多様性として価値がある。 |
| 放置された旧媒体 | 古い暗号化ディスクが保管されている。 | 方式、パスフレーズ、 keyfile、最終確認日、内容が不明である。 | レジリエンス資産ではなく、管理不能リスクである。 |
| 過剰な統一 | すべてが最新の LUKS2 + ext4 に揃っている。 | 管理は単純だが、単一方式、単一手順、単一ファイルシステムに依存している。 | 物理冗長性はあるが、方式多様性は低い。 |
| 無秩序な多様性 | 複数方式が雑多に残っている。 | 台帳がなく、どれが主系か、どれを消してよいか分からない。 | 多様性ではなく混乱である。 |
10.4 主系バックアップと互換バックアップを同列に扱ってはならない
異質冗長性を採用する場合、最も重要なのは、主系バックアップと互換バックアップを同列に扱わないことである。主系バックアップは、現在の更新対象であり、日常的な同期、復元テスト、ヘッダー保全、 key slot 管理の中心である。現在であれば、 LUKS2 + AES-XTS + Argon2id + ext4 を主系に置くのが自然である。一方、互換バックアップは、主系とは異なる復元経路を保持するための補助的な媒体である。 LUKS1 旧媒体や TrueCrypt + FAT 旧媒体は、この位置づけに近い。これらを主系と同じ頻度で更新し続けようとすると、古い方式の弱点を現在の運用へ持ち込むことになる。
互換バックアップは、更新頻度を下げ、読み取り中心にし、必要な期間だけ保持するのが妥当である。たとえば、 TrueCrypt + FAT 旧媒体は、 FAT の制約により Linux の権限、シンボリックリンク、大容量ファイル、メタデータを忠実に保持する用途には向かない。一方で、過去のファイル群を読み出すための互換アーカイブとしては意味を持ち得る。 LUKS1 媒体も、新規主系として増やすべきではないが、過去世代の暗号化ディスクとして、移行完了まで保持する価値がある。主系と互換バックアップの役割を分けることで、古い方式を活かしつつ、古い方式へ戻ることを避けられる。
| 役割 | 対象例 | 更新方針 | 退役条件 |
|---|---|---|---|
| 主系バックアップ | LUKS2 + AES-XTS + Argon2id + ext4 の現行媒体である。 | 定期同期、復元テスト、ヘッダー保全、 key slot 管理を継続する。 | 次世代主系へ移行し、復元確認が完了した時点で縮退する。 |
| 副系バックアップ | 同じ LUKS2 構成の別媒体である。 | 主系と同じ方式で複数世代または複数媒体を維持する。 | 媒体劣化、容量不足、方式更新時に交換する。 |
| 互換バックアップ | LUKS1 旧媒体や TrueCrypt 旧媒体である。 | 読み取り中心にし、必要時のみ確認する。 | 主系と副系で復元確認が取れ、保持理由がなくなった時点で退役する。 |
| 移行元 | 旧方式から新方式へデータを移すために残す媒体である。 | 移行完了まで保全し、更新は最小限にする。 | 移行先の復元確認と差分確認が完了した時点で退役候補にする。 |
| 読み取り中心アーカイブ | 過去世代のファイル群を参照するための旧媒体である。 | 書き込みを避け、定期的な開封確認と読み取り確認に限定する。 | 内容が現行媒体へ取り込まれ、参照価値がなくなった時点で退役する。 |
10.5 異質冗長性は移行失敗への保険になる
暗号化ディスクの移行では、すべてが計画通りに進むとは限らない。 LUKS1 から LUKS2 へ移したつもりでも、一部ファイルのコピーに失敗しているかもしれない。 TrueCrypt + FAT から LUKS2 + ext4 へ移したときに、ファイル名、文字コード、タイムスタンプ、権限、シンボリックリンク、ファイルサイズ制限、メタデータの扱いで差が出るかもしれない。 rsync の除外ルール、末尾スラッシュ、削除オプション、所有者・グループ保持、マウント先の取り違えにより、想定とは違う結果になることもある。移行先ができた瞬間に旧媒体を消すと、これらの問題が後から判明したときに戻れない。
このため、異質冗長性は移行期間中の保険として機能する。旧媒体を一定期間保持し、移行先の復元テスト、ファイル数確認、容量比較、代表ファイルの読み取り確認、必要ならチェックサム確認を行う。その後、旧媒体を主系から外し、互換バックアップまたは退役候補へ縮退する。ここで重要なのは、旧媒体を永遠に残すことではない。移行失敗を検出できるだけの期間と手順を設け、その役割が終わったら退役させることである。異質冗長性は、移行を遅らせるためではなく、安全に移行を完了させるために使う。
| 移行時のリスク | 起きる問題 | 異質冗長性による緩和 |
|---|---|---|
| コピー漏れ | 除外ルール、権限エラー、ファイル名問題により一部データが移らない。 | 旧媒体を保持し、差分確認と再同期の余地を残す。 |
| ファイルシステム差 | FAT と ext4 で権限、シンボリックリンク、タイムスタンプ、大容量ファイルの扱いが異なる。 | 旧媒体を読み取り中心で残し、必要に応じて元データを確認できるようにする。 |
| 暗号化方式差 | TrueCrypt、 LUKS1、 LUKS2 で開封手順や確認方法が異なる。 | 旧方式の開封手順を台帳化し、移行完了まで復元経路を保持する。 |
| 媒体性能差 | 特定の 2.5-inch HDD で LUKS + ext4 の更新性能が悪化する。 | 別方式または別媒体のバックアップを残し、性能問題で移行が止まっても復元経路を失わない。 |
| 同期方向ミス | 移行元と移行先を取り違え、古い状態で新しいデータを上書きする。 | 旧媒体を読み取り中心にし、主系への書き戻し手順を明確に分ける。 |
10.6 同質冗長性は運用を単純にし、異質冗長性は失敗モードを分散する
同質冗長性と異質冗長性は、どちらか一方を選ぶものではない。役割が違う。同質冗長性は、日常運用を単純にし、復旧手順を標準化し、媒体故障への対応を容易にする。異質冗長性は、単一方式に共通する失敗モードを分散し、移行失敗や特定環境の問題に対する逃げ道を作る。つまり、同質冗長性は「通常運用の安定性」を支え、異質冗長性は「想定外の逃げ道」を支える。
この関係を誤ると、運用が崩れる。すべてを異質にすれば、毎回手順が違い、確認項目が増え、管理不能になる。すべてを同質にすれば、管理は楽だが、単一方式への依存が強くなる。実務上は、主系と副系を同質冗長性で安定させ、その外側に限定的な異質冗長性を置くのが扱いやすい。つまり、日常的に更新する媒体は LUKS2 + ext4 に寄せ、旧 LUKS1 や TrueCrypt + FAT は更新対象ではなく、読み取り確認済みの互換バックアップまたは移行元として限定的に残す。これにより、管理の単純さと復元経路の多様性を両立しやすくなる。
| 設計要素 | 主に支えるもの | 具体的な役割 | 管理上の注意 |
|---|---|---|---|
| 同質冗長性 | 通常運用の安定性 | 同じ方式の複数媒体で、定期同期と復元手順を標準化する。 | 同期ミスや共通設定ミスを複数媒体へ伝播させない。 |
| 異質冗長性 | 想定外への逃げ道 | 旧方式や別ファイルシステムを、互換バックアップや移行元として残す。 | 台帳化し、読み取り確認し、退役条件を決める。 |
| 世代冗長性 | 論理削除や破損への耐性 | 過去時点の状態を保持し、最新同期だけに依存しない。 | 保存期間、容量、削除方針を明確にする。 |
| 場所冗長性 | 災害、盗難、紛失への耐性 | 媒体を異なる場所に保管する。 | 持ち出し媒体の暗号化、確認周期、保管台帳を管理する。 |
10.7 古い方式を残す理由と退役させる理由は同時に成立する
古い方式をめぐる判断で重要なのは、「残すべきか、消すべきか」を単純な二択にしないことである。古い方式を残す理由はある。過去の復元経路になる。移行失敗への保険になる。異なるファイルシステムや異なる暗号化形式によって、単一方式依存を避けられる。古い媒体にしか残っていないデータやメタデータを確認できる場合もある。したがって、旧 LUKS1 や TrueCrypt + FAT を見つけたとき、古いという理由だけで即時廃棄するのは危険である。
同時に、古い方式を退役させる理由も明確にある。 LUKS1 + PBKDF2 は現在の新規主系には向かない。 TrueCrypt 7.1a は保守終了している。 FAT は Linux の権限やシンボリックリンクを十分に保持できない。古い HDD は物理劣化する。古い媒体はパスフレーズや keyfile の記憶が曖昧になりやすい。したがって、古い方式を無期限に残すことも危険である。正しい方針は、残す理由がある間は役割を限定して残し、その役割が終わったら退役させることである。
| 判断 | 理由 | 条件 | 次の行動 |
|---|---|---|---|
| 残す | 過去の復元経路、移行失敗への保険、異質冗長性として価値がある。 | 開封確認済みで、解除条件、保管場所、役割が台帳化されている。 | 読み取り中心にし、再確認周期と退役条件を設定する。 |
| 縮退する | 主系としては古いが、即時廃棄するには復元価値が残る。 | 新主系への移行が進んでいるが、検証期間中である。 | 更新を止め、互換バックアップまたは移行元に役割を限定する。 |
| 退役する | 新主系と副系で復元確認が済み、旧媒体の保持理由がなくなった。 | 差分確認、読み取り確認、保持期間、退役承認が完了している。 | 安全に消去し、台帳を退役済みに更新する。 |
| 隔離する | 方式不明、開封不能、媒体劣化、解除条件不明などの問題がある。 | すぐに消すには内容不明だが、主系として扱えない。 | 調査対象として分け、復旧可否を確認してから移行または退役を判断する。 |
10.8 異質冗長性には境界線が必要である
異質冗長性を採用する場合、どこまで多様性を許容するかを決めなければならない。古い方式を残し始めると、過去の媒体、過去のコンテナ、過去のファイルシステム、過去のディレクトリ構成が際限なく残る。これはレジリエンスではなく、保守不能な複雑性になる。したがって、異質冗長性には境界線が必要である。残してよいのは、役割が明確で、開封確認済みで、内容が把握され、保持期限または退役条件が定義されている媒体に限るべきである。
境界線を決めるには、媒体ごとに「何のために残すのか」を問う必要がある。主系の代替なのか、過去世代の参照なのか、移行漏れ確認なのか、旧環境互換なのか、単に消すのが不安だから残しているだけなのか。この問いに答えられない媒体は、異質冗長性ではなく未整理資産である。未整理資産は、まず棚卸しし、開封確認し、必要なら現行主系へ吸い上げ、不要なら退役させる。異質冗長性は、明確な目的を持つ多様性であり、目的のない残骸を増やすことではない。
| 判定項目 | 残してよい状態 | 残すべきでない状態 |
|---|---|---|
| 役割 | 互換バックアップ、移行元、読み取り中心アーカイブなどの役割が明確である。 | 何のために残しているか説明できない。 |
| 開封確認 | 最近の確認日と使用ツールが記録されている。 | 最後に開けた時期が不明である。 |
| 解除条件 | パスフレーズ、 keyfile、 key slot、 hidden volume 有無が管理されている。 | 解除条件が記憶頼みで、再現できるか不明である。 |
| 内容 | 何のデータが入っているか、現行主系との関係が分かる。 | 中身が不明で、消してよいか判断できない。 |
| 期限 | 保持期間、再確認周期、退役条件が定義されている。 | 無期限に保管され、定期確認もされない。 |
10.9 冗長性は媒体数ではなく失敗モードの分散で評価する
バックアップ媒体の数が多いことは安心材料になるが、それだけでは十分ではない。 5 台の媒体があっても、すべて同じホストで、同じスクリプトで、同じ同期方向で、同じ削除ポリシーで、同じ暗号方式で、同じマウント手順で更新されているなら、共通原因の失敗には弱い。誤った rsync オプション、削除の即時反映、マウント先の取り違え、破損ファイルの同期、暗号化ヘッダーの未保全、 key slot 管理ミスは、媒体数だけでは防げない。冗長性は、媒体数ではなく、どの失敗モードを分散しているかで評価する必要がある。
この観点では、同質冗長性、異質冗長性、世代冗長性、場所冗長性を組み合わせる必要がある。同質冗長性は媒体故障に効く。異質冗長性は方式依存に効く。世代冗長性は論理削除や破損の伝播に効く。場所冗長性は災害や盗難に効く。これらを混同すると、「たくさんコピーがあるのに復元できない」という事態が起きる。暗号化ディスクでは、さらにヘッダー、鍵、手順、台帳が必要になるため、失敗モードの分散は通常のバックアップより重要である。
| 冗長性 | 主に防ぐ失敗 | 防げない失敗 | 補完策 |
|---|---|---|---|
| 媒体冗長性 | 単一ディスク故障、紛失、読み取り不能である。 | 同期ミス、削除伝播、方式依存である。 | 世代管理、異質冗長性、検証履歴を組み合わせる。 |
| 同質冗長性 | 同じ構成の中での個別媒体障害である。 | 同じ方式や手順に共通する失敗である。 | 異質冗長性と手順レビューを組み合わせる。 |
| 異質冗長性 | 単一方式、単一ファイルシステム、単一復旧環境への依存である。 | 台帳不備、解除条件喪失、媒体劣化である。 | 台帳化、開封確認、退役条件を組み合わせる。 |
| 世代冗長性 | 誤削除、破損、ランサムウェア的な上書き、同期ミスである。 | 全世代が同じ場所にある場合の災害や盗難である。 | 場所冗長性とオフライン保管を組み合わせる。 |
| 場所冗長性 | 火災、盗難、災害、同時物理損失である。 | 古い方式の開封不能、台帳不備である。 | 復元手順書、鍵管理、定期確認を組み合わせる。 |
10.10 長期運用では段階的共存が最も現実的である
暗号化ディスクの長期運用では、全面置換より段階的共存の方が現実的である。すべての旧媒体を一気に LUKS2 + ext4 へ移せば、見た目は整理される。しかし、移行中の性能問題、媒体相性、コピー漏れ、確認不足、旧形式にしか残っていない情報、復元手順の未整備があると、かえって復元可能性を失う。特に、 2.5-inch HDD で LUKS + ext4 の性能問題が目立つ場合や、旧 TrueCrypt + FAT では問題が出ていなかった場合、暗号方式だけでなく、媒体性能、ファイルシステム、 I/O パターン、運用目的を分けて判断する必要がある。
段階的共存とは、現行主系を明確にしながら、旧媒体を一定期間だけ役割付きで残すことである。新規更新は LUKS2 + ext4 の主系へ寄せる。旧 LUKS1 は移行対象または互換バックアップにする。 TrueCrypt + FAT は更新し続ける主系ではなく、読み取り中心アーカイブとして扱う。性能問題が出る媒体は、主系から外すか用途を限定する。すべてを一度に統一するのではなく、媒体ごとの性能、容量、方式、復元目的に応じて役割を分ける。これにより、復元経路を維持したまま、主系を現代的な構成へ寄せられる。
| 運用段階 | 主な対象 | 方針 | 目的 |
|---|---|---|---|
| 現状棚卸し | LUKS1、 LUKS2、 TrueCrypt、未分類媒体である。 | 方式確認、開封確認、媒体識別、役割分類を行う。 | 何が復元可能で、何が移行対象かを明確にする。 |
| 主系確立 | LUKS2 + AES-XTS + Argon2id + ext4 の現行媒体である。 | 新規同期と通常復元は主系へ集約する。 | 現在の標準構成を運用の中心にする。 |
| 旧媒体縮退 | LUKS1 旧媒体、 TrueCrypt + FAT 旧媒体である。 | 更新を止め、読み取り中心または互換バックアップに役割を限定する。 | 旧方式を主系から外しつつ、復元経路として残す。 |
| 移行検証 | 旧媒体から新媒体へ移したデータである。 | ファイル数、容量、代表ファイル、必要ならチェックサムで確認する。 | 移行漏れや破損を検出する。 |
| 退役判断 | 役割を終えた旧媒体である。 | 保持理由がなくなった媒体を安全に消去し、台帳を更新する。 | 管理不能な古い暗号化ディスクを増やさない。 |
結論として、レジリエンスでは、同質冗長性と異質冗長性を分けて考える必要がある。同質冗長性は、同じ構成の媒体を複数持つことで、媒体故障や単純な喪失に強くなる。異質冗長性は、異なる方式、異なるファイルシステム、異なる復旧経路を意図的に残すことで、単一方式依存を避ける。ただし、異質冗長性は放置ではない。旧 LUKS1 や TrueCrypt + FAT は、主系ではなく、互換バックアップ、読み取り中心アーカイブ、移行元、移行失敗時の逃げ道として意味づける必要がある。そして、役割が終わった媒体は退役させる。暗号化ディスクのレジリエンスは、最新方式への統一だけでも、古い方式の無期限保持だけでも成立しない。現行主系を明確にし、旧方式を管理された異質冗長性として一時的に活かし、復元確認後に段階的に縮退させることで成立する。
11. 暗号化ディスクをライフサイクル管理する
暗号化ディスクは、作成して保管すれば完了する静的な成果物ではない。作成、初期検証、通常運用、定期点検、方式見直し、媒体更新、移行、縮退、退役までを含むライフサイクル管理対象である。暗号方式は時間とともに古くなり、 KDF の推奨値は計算能力の上昇に応じて見直され、媒体は物理的に劣化し、ファイルシステムの適性は運用対象によって変わり、復旧に使う OS や cryptsetup や VeraCrypt も変化する。したがって、作成時点で LUKS2 + AES-XTS + Argon2id を選んだだけでは不十分である。重要なのは、その構成が将来レガシー化することを前提に、どの情報を記録し、どの周期で確認し、どの条件で移行し、どの状態になれば退役させるかを、最初から運用設計として組み込むことである。
この章で扱うライフサイクル管理は、単なる点検表ではない。暗号化ディスクにおける防御、復元、移行、退役を一体化する設計である。防御とは、媒体を紛失しても第三者に読ませないことである。復元とは、正当な利用者が必要な時点で確実に開けることである。移行とは、暗号方式、媒体、ファイルシステム、運用手順が古くなったとき、復元経路を失わずに新しい構成へ移すことである。退役とは、役割を終えた旧媒体を無期限に残さず、復元確認と代替経路の確保を終えたうえで管理対象から外すことである。暗号化ディスクのライフサイクル管理は、この 4 つを同時に成立させるための運用設計である。
| 管理目的 | 意味 | 失敗した場合 | 必要な設計 |
|---|---|---|---|
| 防御 | 媒体紛失や盗難時に第三者へ平文を読ませない。 | バックアップ媒体が情報漏洩源になる。 | 現行暗号方式、強いパスフレーズ、 KDF、 key slot 管理、物理保管を設計する。 |
| 復元 | 正当な利用者が必要な時点で開け、読め、戻せる状態を維持する。 | データ本体は残っていても、ヘッダー、鍵、手順、媒体識別の欠落により復元できない。 | ヘッダーバックアップ、台帳、作業手順書、検証履歴、復元テストを設計する。 |
| 移行 | 方式や媒体が古くなったときに、復元経路を失わず新構成へ移す。 | 古い方式への依存が残るか、移行時にデータや復元経路を失う。 | 主系、副系、互換バックアップ、移行元、退役候補を分類する。 |
| 退役 | 役割を終えた媒体を安全に消去し、管理対象から外す。 | 用途不明の古い暗号化ディスクが増え、解除条件不明、媒体劣化、誤操作の原因になる。 | 退役条件、保持期限、復元確認条件、安全消去手順を明文化する。 |
11.1 作成段階では暗号方式だけでなく運用単位を決める
暗号化ディスクの作成段階では、暗号方式だけでなく、その媒体をどの運用単位として扱うかを決める必要がある。新規主系であれば、現在の Linux 運用では LUKS2 + AES-XTS + Argon2id + ext4 を基本にするのが自然である。ただし、形式を選ぶだけでは運用設計にならない。媒体 ID、物理ラベル、用途、マウントポイント、同期対象、除外対象、ヘッダーバックアップの取得先、 key slot の用途、パスフレーズ管理、復元手順、検証周期まで決めて初めて、暗号化ディスクとして作成されたことになる。
作成段階で曖昧にしてはいけないのは、その媒体が主系なのか、副系なのか、互換バックアップなのか、移行先なのか、読み取り中心アーカイブなのかという役割である。役割が曖昧な媒体は、後で同期対象、保管対象、退役対象を判断できなくなる。たとえば、 LUKS2 で暗号化した 5TB HDD が主系なのか、旧媒体からの移行先なのか、長期保管用の副系なのかで、同期頻度、保管場所、検証周期、退役条件は変わる。暗号化ディスクでは、媒体を作ることと、媒体に役割を与えることを同時に行う必要がある。
| 作成時の設計項目 | 決める内容 | 理由 |
|---|---|---|
| 媒体 ID | disk1、 disk2、 archive-2026-05 など、人間が識別できる名前を決める。 | 物理媒体、台帳、ヘッダーバックアップ、作業手順を対応づけるためである。 |
| 物理識別 | 型番、容量、シリアル、物理ラベル、保管場所を記録する。 | 同じ容量や似た外観の媒体を取り違えないためである。 |
| 暗号形式 | 新規主系では LUKS2 を基本にし、既存互換用途では LUKS1 や TrueCrypt を分類する。 | 復元に必要なツール、ヘッダー構造、将来の移行対象を明確にするためである。 |
| 暗号方式 | AES-XTS、 sector size、 plain64 など、実際の luksDump 結果を記録する。 | 想定ではなく実媒体の構成を基準に管理するためである。 |
| KDF | Argon2id、 time cost、 memory、 threads、または PBKDF2 iteration を記録する。 | パスフレーズ攻撃耐性と将来の見直し優先度を判断するためである。 |
| ファイルシステム | ext4、 FAT、 exFAT などを記録し、用途と制約を明確にする。 | 権限、シンボリックリンク、大容量ファイル、性能、互換性の前提が変わるためである。 |
| 役割 | 主系、副系、互換バックアップ、移行元、読み取り中心アーカイブ、退役候補を決める。 | 同期頻度、確認周期、保管方針、退役条件を決める基礎になるためである。 |
11.2 初期検証では作成直後に閉じてから再度開く
暗号化ディスクは、作成直後に一度開けたから安全に使えると判断してはならない。作成時の open 状態でファイルシステムを作り、データを書き込み、そのまま満足してしまうと、次回本当に開けるか、別の手順で開けるか、ヘッダーと key slot が期待通りか、マウント先が正しいかを確認しないまま運用に入ることになる。初期検証では、作成後にいったんアンマウントし、 cryptsetup close し、再度 open し、マウントし、読み書きし、必要であれば読み取り専用マウントも確認する必要がある。
初期検証の目的は、媒体が暗号化されていることを確認するだけではない。復元条件が成立していることを確認することである。パスフレーズで開けるか。想定した key slot が有効か。不要な key slot がないか。 LUKS UUID が台帳と一致しているか。ヘッダーバックアップを取得できたか。作成したヘッダーバックアップが対象媒体と対応づいているか。ファイルシステムをマウントできるか。代表ファイルを書き込み、読み出し、削除できるか。これらを確認して初めて、媒体は初期運用可能な状態になる。
| 初期検証項目 | 実施内容 | 確認すること |
|---|---|---|
| luksDump 取得 | LUKS バージョン、暗号方式、 KDF、 key slot、 UUID を確認する。 | 実際の媒体構成が設計方針と一致していることを確認する。 |
| 再 open 確認 | 一度 close してから再度 open する。 | 作成時だけでなく通常復旧手順でも開けることを確認する。 |
| マウント確認 | 通常マウントと必要に応じて読み取り専用マウントを確認する。 | 復元時に安全な確認手順を取れることを確認する。 |
| 読み書き確認 | 代表ファイルの作成、読み取り、削除を行う。 | ファイルシステムとして実際に使えることを確認する。 |
| ヘッダーバックアップ | ヘッダーバックアップを取得し、 UUID、取得日、保管先を記録する。 | ヘッダー破損時の復旧経路を確保する。 |
| 台帳初期登録 | 媒体 ID、型番、容量、暗号方式、 KDF、役割、最終確認日を登録する。 | 作成した媒体を管理対象として追跡できるようにする。 |
| 手順確認 | open、 mount、 verify、 umount、 close、 shutdown までの流れを確認する。 | 復旧時と通常運用時の操作が再現可能であることを確認する。 |
11.3 通常運用では同期そのものより同期結果を管理する
通常運用では、rsync や cp を実行すること自体が目的ではない。目的は、同期対象のデータが、想定した媒体へ、想定した方向で、想定した範囲だけ、復元可能な状態で保存されることである。したがって、通常運用では、コマンドの成功終了だけでなく、同期ログ、転送量、削除件数、エラー件数、除外ルール、マウント先、空き容量、処理時間を確認する必要がある。特に暗号化ディスクでは、誤ったマウント先へ同期してもディレクトリだけは存在することがあるため、マウント確認を省略すると空ディレクトリへ書き込む事故や、別媒体への誤同期が起きる。
また、通常運用では、書き込み性能の観察も重要である。 LUKS + ext4 は現在の Linux 運用として自然な構成であるが、すべての媒体で同じ性能が出るわけではない。 2.5-inch HDD、 3.5-inch HDD、 SSD、 USB ブリッジ、記録方式、キャッシュ、電源供給、ファイル数、ファイルサイズ分布、メタデータ更新量によって体感性能は大きく変わる。特定の 2.5-inch 2TB HDD で LUKS + ext4 の更新が極端に遅い一方、別の 5TB 2.5-inch HDD では顕著な問題が出ないこともある。したがって、通常運用では、暗号方式の理論だけでなく、媒体ごとの実測を台帳へ反映し、主系として継続できるか、読み取り中心へ回すべきかを判断する必要がある。
| 通常運用項目 | 確認内容 | 異常時の判断 |
|---|---|---|
| マウント確認 | 対象の暗号化デバイスが正しいマウントポイントにあることを確認する。 | マウントされていなければ同期を実行しない。 |
| 同期方向 | source と destination が想定通りであることを確認する。 | 移行元と移行先の取り違えが疑われる場合は中断する。 |
| 同期範囲 | 対象ディレクトリ、除外ルール、削除オプションを確認する。 | 想定外の削除や大量差分が出た場合は即時反映しない。 |
| ログ確認 | エラー、警告、転送量、削除件数、処理時間を確認する。 | 成功終了だけでなく、異常な差分や遅延を点検する。 |
| 容量確認 | 使用量、空き容量、急増、想定外の肥大化を確認する。 | 容量逼迫時は同期失敗や不完全コピーを疑う。 |
| 性能観察 | 媒体ごとの処理時間、 I/O 待ち、極端な遅延を記録する。 | 主系に不向きな媒体は用途変更または退役候補にする。 |
| 終了確認 | sync、 umount、 cryptsetup close、電源断までの終了手順を確認する。 | 書き込み途中の切断や閉じ忘れを避ける。 |
11.4 定期点検では媒体、ヘッダー、鍵、手順を別々に確認する
定期点検では、バックアップ媒体が存在しているかだけでなく、復元条件が現在も成立しているかを確認する必要がある。暗号化ディスクの点検対象は、媒体、暗号ヘッダー、 key slot、パスフレーズ、 keyfile、ファイルシステム、データ内容、復元手順、台帳の 9 層に分かれる。どれか 1 つが破綻しても復元性は低下する。たとえば、媒体が読めてもパスフレーズが不明なら開けない。パスフレーズが正しくてもヘッダーが壊れていれば開けない。開けてもファイルシステムが壊れていればデータへ到達できない。マウントできても重要ディレクトリが読めなければ復元できない。
点検周期は媒体の役割によって変えるべきである。主系バックアップは比較的短い周期で、同期ログ、容量、 open、 mount、読み取りを確認する。副系バックアップは主系よりやや長い周期でもよいが、定期的な開封確認は必要である。互換バックアップや読み取り中心アーカイブは更新頻度が低くても、長期間一度も開けない状態にしてはならない。旧 LUKS1 や TrueCrypt 旧媒体は、開けるうちに開封条件を確認し、必要データを主系へ吸い上げ、退役条件を判断する。点検は、媒体を守る作業ではなく、将来の復元判断を更新する作業である。
| 点検層 | 確認内容 | 点検結果の扱い |
|---|---|---|
| 媒体 | 接続可否、読み取りエラー、 SMART、異音、極端な遅延を確認する。 | 劣化が疑われる媒体は移行優先度を上げる。 |
| ヘッダー | luksDump、ヘッダーバックアップ、 UUID 対応関係を確認する。 | ヘッダーバックアップがない媒体は保全を優先する。 |
| key slot | 有効 slot 数、用途、不要 slot、古い解除入口を確認する。 | 用途不明の key slot は確認後に削除または台帳化する。 |
| 解除情報 | パスフレーズ、 keyfile、 token、 TrueCrypt の hidden volume 条件を確認する。 | 解除条件が不明な媒体は復元可能資産として再分類する。 |
| ファイルシステム | マウント可否、必要に応じた fsck、読み取り専用確認を行う。 | 不整合がある場合は書き込みを避け、退避を優先する。 |
| データ内容 | 重要ディレクトリ、代表ファイル、ファイル数、容量、チェックサムを確認する。 | コピー漏れや破損が疑われる場合は移行元と照合する。 |
| 手順 | open、 mount、 verify、 restore、 close の手順が現行環境で再現できるか確認する。 | 手順が古い場合は作業手順書を更新する。 |
| 台帳 | 役割、最終確認日、保管場所、退役条件が現状と一致しているか確認する。 | 実態と台帳がずれている場合は台帳を訂正する。 |
11.5 標準見直しでは新規作成標準と既存媒体の扱いを分ける
暗号化ディスクの標準見直しでは、新規に作る媒体の標準と、既存媒体の扱いを分ける必要がある。新規作成標準は、その時点での推奨構成へ寄せるべきである。現在なら、 LUKS2 + AES-XTS + Argon2id を基本にし、媒体特性に応じてファイルシステムと運用手順を選ぶのが妥当である。一方、既存媒体は、古いから即座に廃棄するのではなく、主系、副系、互換バックアップ、移行対象、退役候補へ分類する。標準見直しとは、過去の全否定ではなく、これから増やす構成と、すでに存在する構成の役割を再定義する作業である。
見直しの契機は、暗号方式の変化だけではない。 cryptsetup の既定値が変わったとき、 OS を更新したとき、バックアップ媒体を増設したとき、旧媒体の性能問題が顕在化したとき、 TrueCrypt 旧資産の開封確認を行ったとき、 LUKS1 媒体が見つかったとき、ヘッダーバックアップが未取得であることに気づいたとき、復元テストで問題が出たときも見直しの契機になる。特に長期運用では、方式の安全性だけでなく、将来も開けるか、移行できるか、退役できるかを判断軸に含める必要がある。
| 見直し契機 | 確認する内容 | 判断すること |
|---|---|---|
| cryptsetup 更新 | LUKS 形式、既定 KDF、推奨パラメーター、互換性を確認する。 | 新規作成標準を更新するか判断する。 |
| OS 更新 | cryptsetup、 systemd-cryptsetup、 ext4、 exFAT、 VeraCrypt 互換性を確認する。 | 復旧手順書を更新するか判断する。 |
| 新媒体導入 | 媒体性能、容量、接続方式、暗号化後の実測速度を確認する。 | 主系、副系、アーカイブのどれに割り当てるか判断する。 |
| 旧媒体発見 | LUKS1、 TrueCrypt、 VeraCrypt、 FAT、 ext4 などの構成を確認する。 | 互換バックアップ、移行元、退役候補のどれに分類するか判断する。 |
| 性能問題 | 暗号方式、ファイルシステム、媒体型番、 I/O パターン、ログを確認する。 | 主系継続、用途限定、旧方式保持、媒体交換を判断する。 |
| 復元テスト失敗 | パスフレーズ、 keyfile、ヘッダー、マウント手順、媒体状態を確認する。 | 復旧計画、移行優先度、退役可否を再評価する。 |
11.6 移行段階では旧媒体をすぐに消さず、復元確認まで並行保持する
暗号化ディスクの移行で最も危険なのは、新媒体へコピーした直後に旧媒体を消すことである。コピーが完了したように見えても、除外ルール、権限エラー、ファイル名、ファイルシステム差、シンボリックリンク、タイムスタンプ、大容量ファイル、途中エラー、マウント先の取り違えにより、完全に移行できていない可能性がある。特に TrueCrypt + FAT から LUKS2 + ext4 へ移す場合、ファイルシステムの性質が違うため、単純なバイト列コピーでは見えない差異が出る。 LUKS1 から LUKS2 への移行でも、 key slot、ヘッダー、 KDF、マウント手順、台帳の更新が必要になる。
移行段階では、旧媒体を移行元として固定し、新媒体を移行先として作成し、同期後に新媒体から復元できることを確認する。確認すべきなのは、コピーコマンドの終了ステータスだけではない。ファイル数、容量、重要ディレクトリ、代表ファイル、必要に応じたチェックサム、ログ中のエラー、削除件数、除外件数を確認する。さらに、新媒体を一度 close し、再度 open し、読み取り確認する。ここまで完了して初めて、旧媒体を主系から外し、互換バックアップまたは退役候補へ移せる。旧媒体は、移行失敗が後から判明した場合に戻れるよう、一定期間は保持する必要がある。
| 移行工程 | 実施内容 | 完了条件 |
|---|---|---|
| 移行元固定 | 旧媒体を読み取り中心にし、移行中の更新を止める。 | 移行元の状態が変化しないことを確認する。 |
| 移行先作成 | 現行標準に基づいて新媒体を作成し、初期検証と台帳登録を行う。 | 新媒体が単独で open、 mount、読み書き可能である。 |
| 同期実行 | 対象範囲、除外ルール、削除オプションを確認して同期する。 | 同期ログに致命的エラーがない。 |
| 差分確認 | ファイル数、容量、重要ディレクトリ、代表ファイルを確認する。 | 移行対象が新媒体に存在し、読めることを確認する。 |
| 再開封確認 | 新媒体を close して再度 open し、読み取り確認する。 | 作成時だけでなく復旧手順でも開ける。 |
| 並行保持 | 旧媒体を一定期間、互換バックアップまたは移行元として保持する。 | 新媒体の復元実績が十分になるまで旧媒体を消さない。 |
| 縮退判断 | 旧媒体を読み取り中心、退役候補、隔離対象へ分類する。 | 保持理由と退役条件が台帳に記録されている。 |
11.7 退役条件は感覚ではなくチェック可能な条件として定義する
暗号化ディスクの退役は、古いから消す、邪魔だから消す、たぶん移行済みだから消す、という感覚で行ってはならない。退役とは、復元経路を失わないことを確認したうえで、役割を終えた媒体を管理対象から外す作業である。旧 LUKS1 媒体を退役させるには、新しい LUKS2 媒体へ対象データが同期済みであること、別系統の副系または世代バックアップにも同等のデータが存在すること、新媒体で復元テストが済んでいること、旧媒体にしかないデータやメタデータがないこと、ヘッダーや key slot の扱いが決まっていること、退役後に復元経路が 1 系統だけにならないことを確認する必要がある。
退役には、消去、隔離、保管停止、読み取り中心アーカイブへの格下げなど複数の形がある。すべての旧媒体を直ちに物理消去する必要はない。特に移行直後は、旧媒体を一定期間読み取り中心で保持し、再確認後に退役する方が安全である。一方で、役割を失った媒体を無期限に残すと、解除条件不明、媒体劣化、情報漏洩、誤操作、管理負荷の原因になる。したがって、退役条件は台帳へ明記し、条件を満たした時点で安全消去または管理対象外への移行を行うべきである。
| 退役条件 | 確認内容 | 満たしていない場合の対応 |
|---|---|---|
| データ移行完了 | 旧媒体の対象データが新媒体へ同期済みであることを確認する。 | 旧媒体を移行元として保持し、差分確認を継続する。 |
| 新媒体復元確認 | 新媒体を close 後に再 open し、重要データを読み取れることを確認する。 | 旧媒体を消さず、新媒体の作成または同期を見直す。 |
| 代替系統確保 | 退役後も主系以外の副系、世代、場所冗長性が残ることを確認する。 | 退役を延期し、別媒体へのバックアップを作成する。 |
| 旧媒体固有情報確認 | 旧媒体にしかないファイル、古い世代、メタデータ、互換価値がないことを確認する。 | 読み取り中心アーカイブまたは移行元として保持する。 |
| 解除条件整理 | パスフレーズ、 keyfile、 key slot、ヘッダーバックアップの扱いを決める。 | 不明な解除情報が残る場合は隔離し、調査対象にする。 |
| 安全消去方針 | 消去、物理破棄、再利用、保管停止のいずれかを決める。 | 媒体の役割が曖昧なまま放置しない。 |
| 台帳更新 | 退役日、理由、処置、代替媒体、確認者を記録する。 | 退役済みか不明な媒体を残さない。 |
11.8 媒体ごとの性能差はライフサイクル上の判断材料である
暗号化ディスクのライフサイクル管理では、セキュリティだけでなく性能も判断材料になる。性能問題は単なる快適性の問題ではない。バックアップに 24 時間以上かかる、更新が極端に遅い、ログが肥大化する、同期作業を避けるようになる、途中で中断される、復元時間が現実的でない、という状態は、復元可能性と継続性を損なう。特に LUKS + ext4 は Linux では自然な構成だが、 2.5-inch HDD、 USB ブリッジ、 SMR / CMR、キャッシュ、電源、ファイル数、メタデータ更新量によって実運用上の差が出る。理論上の暗号強度だけで媒体の役割を決めるべきではない。
したがって、媒体ごとの実測を台帳に反映し、役割を調整する必要がある。更新が多い主系には、書き込み性能と小ファイル処理に耐えられる媒体を使う。更新が遅すぎる 2.5-inch HDD は、主系ではなく読み取り中心アーカイブや互換バックアップへ回す。過去の TrueCrypt + FAT 媒体が更新性能面では扱いやすかったとしても、保守終了ソフトウェアと FAT の制約を考えれば、主系へ戻すのではなく、互換バックアップとして意味づける。性能は暗号方式を否定する材料ではなく、媒体の役割を決める材料である。
| 媒体状態 | 観測される現象 | ライフサイクル上の判断 |
|---|---|---|
| 主系に適した媒体 | LUKS + ext4 で同期時間が現実的で、読み書きが安定している。 | 主系または副系バックアップとして継続利用する。 |
| 更新に遅い媒体 | 小ファイルやメタデータ更新で極端に遅く、通常運用が負担になる。 | 主系から外し、読み取り中心、低頻度同期、移行元、退役候補へ分類する。 |
| 読み取りは安定する媒体 | 書き込みは遅いが、読み取りと保管用途では問題が少ない。 | 互換バックアップまたは読み取り中心アーカイブとして扱う。 |
| 劣化が疑われる媒体 | 読み取りエラー、接続断、異音、 SMART 警告、極端な速度低下がある。 | 直ちに退避し、主系から外し、退役または隔離する。 |
| 方式が古いが開ける媒体 | LUKS1 や TrueCrypt として開封確認でき、内容も読める。 | 移行元、互換バックアップ、期間限定の読み取り中心アーカイブとして扱う。 |
11.9 台帳は媒体一覧ではなく運用判断の基礎資料である
暗号化ディスクの台帳は、単なる媒体一覧ではない。将来の復元、移行、退役を判断するための基礎資料である。台帳に必要なのは、媒体 ID、物理ラベル、型番、容量、シリアル、保管場所、暗号形式、暗号方式、 KDF、 key slot、ヘッダーバックアップ、ファイルシステム、役割、同期対象、最終 open 確認日、最終マウント確認日、最終読み取り確認日、最終復元テスト日、性能所見、移行先、退役条件である。これらがなければ、十年後にその媒体が何で、何を守り、どう開け、まだ必要なのかを判断できない。
台帳の記述は、曖昧な印象ではなく、確認可能な事実に基づくべきである。「古い HDD」「たぶんバックアップ」「開けるはず」という記述は、復旧時には役に立たない。必要なのは、「LUKS1、 aes-cbc-essiv:sha256、 PBKDF2、 key slot 0 と 1 が有効、最終開封確認日、ヘッダーバックアップ取得済み、役割は互換バックアップ、退役条件は LUKS2 主系と副系で復元確認完了後」のような判断可能な記録である。台帳の品質が低いと、暗号方式が強くても運用は弱くなる。台帳は、暗号化ディスクの可観測性を作る中核文書である。
| 台帳項目 | 記録する内容 | 判断に使う場面 |
|---|---|---|
| 媒体 ID | 人間が運用上識別する名前を記録する。 | 作業対象、同期対象、退役対象を取り違えないために使う。 |
| 物理情報 | 型番、容量、シリアル、物理ラベル、保管場所を記録する。 | 媒体の個体識別、性能傾向、劣化判断に使う。 |
| 暗号情報 | LUKS1、 LUKS2、 TrueCrypt、暗号モード、 KDF、 key slot を記録する。 | 移行優先度、復旧手順、互換性判断に使う。 |
| 解除条件 | パスフレーズ管理方針、 keyfile 使用有無、 token、 hidden volume 有無を記録する。 | 復元できるか、攻撃面が増えていないかを判断する。 |
| ヘッダー保全 | ヘッダーバックアップ取得日、保管場所、対象 UUID を記録する。 | ヘッダー破損時の復旧可否を判断する。 |
| 役割 | 主系、副系、互換バックアップ、移行元、退役候補を記録する。 | 更新頻度、確認周期、退役条件を決める。 |
| 検証履歴 | open、 mount、読み取り、復元テスト、エラー確認の日付を記録する。 | その媒体を復元可能資産として扱えるか判断する。 |
| 性能所見 | 同期時間、異常な遅延、媒体ごとの実測傾向を記録する。 | 主系継続、用途限定、退役候補化を判断する。 |
| 退役条件 | 何が完了すれば消去または管理終了できるかを記録する。 | 古い媒体を無期限に残さず、復元性を失わずに縮退させる。 |
11.10 手順書は通常運用、復元、移行、退役を分けて書く
暗号化ディスクの作業手順書は、通常運用だけを書けばよいものではない。通常運用、復元、移行、退役では、目的も危険も異なる。通常運用では、正しい媒体へ正しい方向で同期し、ログを確認し、安全に閉じることが重要である。復元では、誤ってバックアップ媒体へ書き込まないこと、読み取り専用で確認すること、戻し先を取り違えないことが重要である。移行では、旧媒体を移行元として固定し、新媒体で復元確認するまで旧媒体を保持することが重要である。退役では、代替経路があることを確認してから安全消去することが重要である。
これらを 1 つの雑な手順にまとめると、障害時に誤操作が起きる。特に復元時は心理的圧力が高く、通常時には起きない操作ミスが起きやすい。マウント先の取り違え、 rsync の同期方向ミス、削除オプションの誤用、旧媒体への書き込み、ヘッダーバックアップの取り違えは、復旧作業を破壊作業に変える。したがって、手順書は通常運用手順、復元手順、移行手順、退役手順に分け、それぞれに事前確認、実行、検証、終了、記録の項目を持たせるべきである。
| 手順書 | 主な目的 | 特に避けるべき誤操作 |
|---|---|---|
| 通常運用手順 | 定期同期、容量確認、ログ確認、正常終了を行う。 | マウントされていないディレクトリへの同期、同期方向の誤り、ログ未確認である。 |
| 復元手順 | バックアップから必要データを安全に戻す。 | バックアップ媒体への書き込み、戻し先の取り違え、古いデータで新データを上書きすることである。 |
| 移行手順 | 旧方式や旧媒体から新媒体へ復元経路を維持したまま移す。 | 移行完了前の旧媒体削除、コピー漏れ、ヘッダー未保全、台帳未更新である。 |
| 退役手順 | 役割を終えた媒体を安全に管理対象外へ移す。 | 代替系統未確認での消去、退役対象の取り違え、台帳未更新である。 |
| 緊急時手順 | 通常環境が使えない場合に最低限の復旧を行う。 | 焦って自動同期を動かす、壊れかけの媒体へ書き込む、唯一の復元経路を破壊することである。 |
11.11 検証履歴は成功だけでなく失敗と違和感も記録する
検証履歴には、成功した作業だけでなく、失敗、警告、違和感も記録する必要がある。暗号化ディスクの障害は、いきなり完全な読めない状態として現れるとは限らない。以前より異常に遅い、特定ディレクトリで止まる、マウントに時間がかかる、 cryptsetup open はできるが読み取りが遅い、 USB 接続が不安定、ログに軽微な I/O エラーが出る、同期ログに毎回同じファイルの失敗が出る、といった兆候がある。これらを記録しないと、次回の判断材料が失われる。
検証履歴は、将来の移行優先度を決める根拠にもなる。ある媒体で LUKS + ext4 の性能問題が継続的に出ているなら、その媒体は主系から外すべきかもしれない。 TrueCrypt 旧媒体が毎回問題なく読み取れるなら、移行完了まで互換バックアップとして保持する価値がある。逆に、開封に失敗した媒体、 keyfile が見つからない媒体、読み取りエラーが出る媒体は、主系や復元可能資産として扱うべきではない。検証履歴は、単なる作業ログではなく、媒体の信頼性評価である。
| 記録対象 | 記録する内容 | 後で使う判断 |
|---|---|---|
| 成功 | open、 mount、読み取り、同期、復元テストが成功した日付と条件を記録する。 | その媒体を復元可能資産として扱える根拠にする。 |
| 失敗 | 開封失敗、マウント失敗、同期失敗、読み取り失敗を記録する。 | 移行優先度、隔離、退役判断に使う。 |
| 警告 | I/O エラー、 SMART 警告、ログ中のエラー、容量逼迫を記録する。 | 媒体劣化や運用不備の早期検出に使う。 |
| 性能所見 | 処理時間、極端な遅延、媒体ごとの差、作業負荷を記録する。 | 主系継続、用途限定、媒体交換の判断に使う。 |
| 違和感 | 前回と違う挙動、想定外の差分、異常に多い削除件数を記録する。 | 後から障害原因を追跡する材料にする。 |
| 対処 | 再同期、手順変更、 key slot 削除、ヘッダーバックアップ取得などを記録する。 | 現在の構成に至った理由を説明できるようにする。 |
11.12 ライフサイクル管理では LUKS1、 LUKS2、 TrueCrypt を役割で扱う
LUKS1、 LUKS2、 TrueCrypt が混在していること自体は、長期運用では珍しいことではない。 10 年以上運用していれば、その時点で自然だった方式が残る。問題は、混在そのものではなく、混在が未整理であることである。 LUKS2 は現在の主系として扱いやすい。 LUKS1 は旧 Linux の暗号化ディスクとして、互換バックアップ、移行対象、読み取り中心アーカイブへ分類する。 TrueCrypt 7.1a は新規主系として採用せず、既存資産の読み出し、確認、移行、退役の対象として扱う。 VeraCrypt は TrueCrypt との互換や移行先の比較対象として扱うが、既存 TrueCrypt 資産そのものと混同しない。
この役割分類により、古い方式を残す理由と、古い方式を退役させる理由が同時に明確になる。 LUKS1 を見つけたから直ちに危険とみなすのではなく、 key slot、パスフレーズ、ヘッダー、最終確認日を確認し、主系から外す。 TrueCrypt 旧媒体は、 XTS 系というデータ暗号化モードの特徴を理解しつつ、保守終了と KDF の古さを踏まえ、読み取り確認と移行を進める。 LUKS2 は現在の主系だが、将来はこれもレガシー化するため、台帳、ヘッダー保全、復元テスト、退役条件を最初から持たせる。ライフサイクル管理とは、形式名で一括判断せず、役割と状態で扱うことである。
| 形式 | ライフサイクル上の位置付け | 主な管理方針 | 退役または縮退条件 |
|---|---|---|---|
| LUKS2 | 現在の主系または副系バックアップである。 | 新規作成標準として採用し、ヘッダー保全、 key slot 管理、定期復元テストを行う。 | 次世代標準へ移行し、新旧両方で復元確認が完了した時点で縮退する。 |
| LUKS1 | 旧 Linux 暗号化ディスク、互換バックアップ、移行対象である。 | luksDump、 key slot 棚卸し、ヘッダーバックアップ、読み取り確認を行う。 | LUKS2 主系と副系へ移行し、復元確認と保持期間が完了した時点で退役する。 |
| TrueCrypt 7.1a | 保守終了した旧資産、読み取り中心アーカイブ、移行元である。 | tcryptDump や tcplay で確認し、 keyfile、 hidden volume、 cipher、 mode、開封確認日を記録する。 | 必要データの移行と復元確認が完了し、互換バックアップとしての役割がなくなった時点で退役する。 |
| VeraCrypt | TrueCrypt 系の後継的選択肢または互換確認対象である。 | TrueCrypt として開けたのか VeraCrypt として開けたのかを分けて記録する。 | 採用する場合は別方式として台帳化し、混同を避ける。 |
| 方式不明媒体 | 未整理資産または調査対象である。 | 開封確認、方式確認、媒体識別、内容確認を優先する。 | 復元可能なら分類し、復元不能または不要なら隔離または退役する。 |
11.13 ライフサイクルは作成日ではなく次の判断日を持たせる
暗号化ディスクの台帳では、作成日だけでなく、次の判断日を持たせるべきである。作成日は過去の情報であり、その媒体がいつ作られたかを示す。一方、次の判断日は将来の運用を動かす情報である。次にいつ開封確認するのか、いつ読み取り確認するのか、いつ標準見直しするのか、いつ旧媒体の退役可否を判断するのか、いつヘッダーバックアップの所在を確認するのかを決めておかなければ、媒体は存在しているだけで点検されない状態になる。
特に長期運用では、作成した時点で満足し、数年後に開けなくなってから問題に気づくことが最も危険である。主系媒体には短めの確認周期を設定し、副系媒体にも定期的な開封確認を設定し、互換バックアップには低頻度でも読み取り確認を設定する。退役候補には、保持期限または再判断日を設定する。これにより、バックアップ媒体は静的な保管物ではなく、継続的に状態が更新される管理対象になる。
| 日付項目 | 意味 | 運用上の使い方 |
|---|---|---|
| 作成日 | 媒体または暗号化ボリュームを作成した日である。 | 暗号方式と媒体世代の把握に使う。 |
| 最終同期日 | 最後にデータを同期した日である。 | バックアップの新しさを判断する。 |
| 最終開封確認日 | 最後に暗号化ボリュームを開けた日である。 | 解除条件が生きているかを判断する。 |
| 最終読み取り確認日 | 最後に代表ファイルや重要ディレクトリを読んだ日である。 | 媒体とファイルシステムが読めるかを判断する。 |
| 最終復元テスト日 | 最後に実際の復元手順を試した日である。 | バックアップが復旧作業に使えるかを判断する。 |
| 次回点検日 | 次に開封確認、読み取り確認、媒体確認を行う予定日である。 | 点検漏れを防ぎ、媒体を放置しないために使う。 |
| 退役判断日 | 旧媒体を残すか退役させるかを再判断する日である。 | 古い方式を無期限に残さないために使う。 |
11.14 運用設計の結論は、主系を明確にし、旧方式を管理し、退役条件を持つことである
暗号化ディスクをライフサイクル管理するということは、現在の主系を明確にし、旧方式を意味づけ、復元条件を保存し、移行と退役を計画することである。現在の新規主系は、原則として LUKS2 + AES-XTS + Argon2id + ext4 に寄せる。旧 LUKS1 は、主系ではなく互換バックアップ、移行元、読み取り中心アーカイブとして扱う。 TrueCrypt 7.1a は、新規採用せず、既存資産の確認、読み出し、移行、退役の対象として扱う。媒体ごとの性能差は実測に基づいて判断し、主系に不向きな媒体は役割を限定する。これらを台帳、手順書、検証履歴、退役条件へ落とし込むことで、混在は混乱ではなく管理対象になる。
この運用設計では、最新方式への統一だけを目的にしない。統一は管理を単純にするが、移行失敗や復元経路の喪失を招くことがある。一方、古い方式を無期限に残すことも目的にしない。旧方式は、役割がある間だけ、読み取り確認済みの互換バックアップまたは移行元として残す。主系は現行標準へ寄せ、副系で同質冗長性を確保し、必要に応じて旧方式を異質冗長性として限定的に保持し、復元確認が完了したものから退役させる。この段階的な運用こそ、 10 年以上の長期運用で暗号化ディスクを破綻させないための現実的な設計である。
| 設計原則 | 具体化 | 期待する効果 |
|---|---|---|
| 主系明確化 | 新規更新対象を LUKS2 + AES-XTS + Argon2id + ext4 へ寄せる。 | 通常運用と復元手順を安定させる。 |
| 旧方式の役割限定 | LUKS1 や TrueCrypt を互換バックアップ、移行元、読み取り中心アーカイブに分類する。 | 旧方式を主系に戻さず、復元経路として活かす。 |
| 復元条件の保存 | ヘッダー、 key slot、パスフレーズ管理、 keyfile、台帳、手順書、検証履歴を保存する。 | データ本体だけでなく、将来開ける条件を維持する。 |
| 実測ベースの媒体判断 | 媒体ごとの同期速度、遅延、エラー、読み取り可否を記録する。 | 暗号方式だけでなく、現実の運用性能で役割を決める。 |
| 段階的移行 | 新媒体へ同期し、復元確認が完了するまで旧媒体を並行保持する。 | 移行失敗時の復元経路を失わない。 |
| 条件付き退役 | 退役条件を満たした媒体だけを安全消去または管理終了する。 | 用途不明の古い暗号化ディスクを増やさない。 |
結論として、暗号化ディスクはライフサイクル管理されなければならない。作成時点の暗号方式だけで安全性を判断するのではなく、通常運用、定期点検、標準見直し、移行、退役までを一続きの工程として設計する必要がある。 LUKS1、 LUKS2、 TrueCrypt が併存している状態は、 10 年以上の長期運用では自然に発生する。重要なのは、それを放置された混在にしないことである。主系を LUKS2 へ寄せ、旧 LUKS1 を互換バックアップまたは移行対象として扱い、 TrueCrypt 旧資産を読み出し確認と移行の対象にし、媒体ごとの性能差を実測で評価し、台帳、作業手順書、検証履歴、退役条件によって管理する。これにより、暗号化ディスクは、単なる暗号化されたデータの集合ではなく、将来も復元でき、方式更新にも耐え、役割を終えた媒体を安全に退役できる運用構造になる。
12. レジリエンスとは古い構成を消すことではなく管理することである
長期運用におけるレジリエンスは、すべてを最新方式へ置き換えることではない。もちろん、新規作成する主系の暗号化ディスクは、その時点の現行標準へ寄せるべきである。現在であれば、 LUKS2、 AES-XTS、 Argon2id、適切なファイルシステム、ヘッダーバックアップ、媒体台帳、復元手順書、検証履歴を基本にするのが自然である。しかし、長期運用の現場では、現在の標準だけで過去の復元経路を置き換えられるとは限らない。 10 年以上運用された環境には、過去の標準、過去の媒体、過去のファイルシステム、過去の暗号化形式、過去の作業手順、過去のバックアップ状態が残る。それらは見た目には古く、不揃いで、整理対象に見える。しかし、その中には、現在の主系へ移行しきれていないデータ、移行漏れを検出するための比較元、過去世代の復元経路、ある時点の状態を保持するアーカイブが含まれている場合がある。これを不用意に消せば、暗号方式としては新しくなっても、復元可能性としては弱くなる。
一方で、古い構成を無制限に残すこともレジリエンスではない。 LUKS1、 AES-CBC-ESSIV、 PBKDF2、 TrueCrypt 7.1a、 FAT、古い 2.5-inch HDD、用途不明の key slot、最終確認日が不明なヘッダーバックアップは、それぞれ異なるリスクを持つ。古い構成は、単に古いというだけで直ちに危険になるわけではないが、役割が不明になり、解除条件が曖昧になり、媒体が劣化し、対応ツールが減り、復元手順が記憶頼みになると、資産ではなく管理不能リスクへ変わる。つまり、古い構成の問題は、古いことそのものよりも、古い構成が何のために残っているのか、現在も開けるのか、どの媒体に何が入っているのか、いつまで保持するのか、どう退役させるのかが分からなくなることである。
本稿で確認してきた技術差は、単なる暗号方式の優劣比較ではない。 LUKS1 と LUKS2 の違いは、暗号化ブロックデバイスの鍵管理形式にも世代交代があることを示している。 LUKS1 は固定的で単純なオンディスク形式として長く使われ、 LUKS2 は JSON ベースのメタデータ、 token、 segment、 digest、 Argon2 系 KDF などを扱いやすくした拡張可能な形式である。 AES-CBC-ESSIV と AES-XTS の違いは、ディスク暗号化において「データの場所」をどのように暗号化へ組み込むかという設計思想の変化を示している。 CBC-ESSIV は CBC をディスク向けに補強した合理的な旧来構成であり、 XTS は最初からストレージ上の位置情報を tweak として扱う現行標準的な構成である。 PBKDF2 と Argon2id の違いは、パスフレーズ攻撃への防御が、単なる反復計算による遅延から、メモリコストも含めた大量並列攻撃への対抗へ移っていることを示している。 TrueCrypt 7.1a の位置付けは、保守終了した古いソフトウェア、古い KDF 設定、古い媒体運用が、必ずしも単純に古い暗号モードと同義ではないことを示している。
このように分解すると、古い構成を評価するときに必要なのは、「新しいか古いか」という一軸の判断ではない。暗号形式、暗号モード、 KDF、パスフレーズ強度、 key slot、ヘッダー保全、ソフトウェア保守、ファイルシステム、媒体性能、物理劣化、復元手順、台帳、検証履歴を分けて見る必要がある。たとえば、 LUKS1 + AES-CBC-ESSIV + PBKDF2 は、現在の新規主系としては選びにくいが、強いパスフレーズで管理され、 key slot が整理され、ヘッダーバックアップがあり、読み取り確認済みで、移行元として役割が明確なら、直ちに無価値な媒体ではない。逆に、 LUKS2 + AES-XTS + Argon2id であっても、ヘッダーバックアップがなく、 key slot の用途が不明で、復元テストをしておらず、台帳もなければ、長期運用上は脆い。暗号化ディスクの強さは、方式の新しさだけでは決まらない。復元条件が管理されているかどうかで決まる。
| 評価軸 | 見るべき内容 | 長期運用での意味 |
|---|---|---|
| 暗号形式 | LUKS1、 LUKS2、 TrueCrypt、 VeraCrypt などの形式を確認する。 | 復元に必要なツール、ヘッダー構造、移行優先度を判断する。 |
| 暗号モード | AES-CBC-ESSIV、 AES-XTS、 TrueCrypt の XTS 系などを確認する。 | ディスク暗号化としての設計世代と現在の主系適性を判断する。 |
| KDF | PBKDF2、 Argon2id、 iteration、 time cost、 memory cost を確認する。 | パスフレーズ攻撃への耐性と将来の見直し対象を判断する。 |
| 解除条件 | パスフレーズ、 keyfile、 key slot、 token、 hidden volume 条件を確認する。 | 正当な利用者が開けるか、不要な攻撃面が残っていないかを判断する。 |
| ヘッダー保全 | LUKS ヘッダー、 TrueCrypt ヘッダー、バックアップ取得日、対象 UUID を確認する。 | ヘッダー破損時に復号可能性を維持できるかを判断する。 |
| 媒体状態 | 型番、容量、接続方式、 SMART、読み取りエラー、性能所見を確認する。 | 主系継続、読み取り中心化、移行、退役の判断材料にする。 |
| 復元実績 | 最終 open、 mount、読み取り、復元テストの日付を確認する。 | 存在している媒体を復元可能資産として扱えるか判断する。 |
| 役割 | 主系、副系、互換バックアップ、移行元、読み取り中心アーカイブ、退役候補を確認する。 | 古い構成を無期限に残さず、必要な期間だけ管理する。 |
12.1 古い構成は消す前に意味を確定する
古い暗号化ディスクを見つけたとき、最初に行うべきことは削除ではなく意味の確定である。その媒体は何のために作られたのか。現在も開けるのか。どの方式で暗号化されているのか。どの key slot が有効なのか。パスフレーズや keyfile は管理されているのか。ヘッダーバックアップはあるのか。中身は現行主系に移行済みなのか。旧媒体にしか残っていないファイルや世代はないのか。最後に読み取り確認したのはいつか。これらを確認しないまま消すと、古い方式を片付けたように見えて、実際には復元経路を切り捨てることになる。
意味を確定したうえで、古い媒体には役割を与える。まだ移行していないなら移行元である。現行主系と内容が重複しているが、移行確認期間中なら互換バックアップである。更新はしないが過去世代の参照価値があるなら読み取り中心アーカイブである。開封不能または方式不明だが、内容確認が終わっていないなら隔離対象である。すでに現行主系と副系で復元確認が済み、保持理由が消えたなら退役候補である。この分類により、古い媒体は「残すか消すか」ではなく、「どの役割として、いつまで、どの条件で残すか」という管理対象になる。
| 旧媒体の分類 | 状態 | 運用方針 |
|---|---|---|
| 移行元 | 旧方式に必要データが残っており、新方式への移行が未完了である。 | 読み取り中心で保持し、移行先の復元確認が済むまで消さない。 |
| 互換バックアップ | 現行主系とは異なる方式で、過去の復元経路として価値がある。 | 更新頻度を下げ、開封確認と読み取り確認を定期的に行う。 |
| 読み取り中心アーカイブ | 過去世代の参照価値はあるが、現在の更新対象ではない。 | 書き込みを避け、内容確認と移行計画を持たせる。 |
| 隔離対象 | 方式、解除条件、内容、媒体状態のいずれかが不明である。 | 主系として扱わず、調査、開封確認、移行可否判断を行う。 |
| 退役候補 | 現行主系と副系で復元確認が済み、旧媒体の保持理由がなくなっている。 | 退役条件を確認し、安全消去または管理終了する。 |
12.2 最新方式への統一だけではレジリエンスにならない
最新方式への統一は、運用を単純にする。すべてを LUKS2 + AES-XTS + Argon2id + ext4 に寄せれば、手順書、台帳、復元手順、ヘッダーバックアップ、 key slot 管理を揃えやすい。これは重要であり、新規主系ではこの方向を採るべきである。しかし、統一は万能ではない。すべての媒体が同じ方式、同じファイルシステム、同じ同期手順、同じ復旧環境に依存すれば、共通原因故障に弱くなる。同期方向の誤り、削除の伝播、マウント先の取り違え、同じスクリプトの設定ミス、同じファイルシステム特性、同じ cryptsetup 環境への依存は、媒体数だけでは解決できない。
ここで必要になるのが、同質冗長性と異質冗長性の使い分けである。主系と副系は同質冗長性によって安定させる。つまり、現在の標準構成を複数媒体に持ち、通常運用と復元手順を統一する。一方で、旧 LUKS1 や TrueCrypt + FAT のような旧媒体は、主系ではなく、限定的な異質冗長性として扱う。これは古い方式へ戻るという意味ではない。過去の復元経路、移行失敗時の逃げ道、ファイルシステム差の確認元として、必要な期間だけ意味づけるということである。レジリエンスは、最新方式への統一だけでなく、旧方式を管理された異質冗長性として縮退させることで成立する。
| 方針 | 利点 | 限界 | 望ましい扱い |
|---|---|---|---|
| 最新方式への統一 | 管理、復元手順、台帳、ヘッダー保全を標準化しやすい。 | 同じ方式、同じ手順、同じファイルシステムへの依存が強くなる。 | 主系と副系では積極的に採用する。 |
| 旧方式の無期限保持 | 過去の復元経路が残る可能性がある。 | 解除条件不明、媒体劣化、保守終了、管理不能のリスクが増える。 | 避けるべきであり、役割と退役条件を必ず設定する。 |
| 管理された異質冗長性 | 単一方式依存を避け、移行失敗時の逃げ道を残せる。 | 台帳、確認周期、手順書がなければ混乱になる。 | 旧媒体を互換バックアップ、移行元、読み取り中心アーカイブとして限定運用する。 |
| 段階的退役 | 復元経路を失わずに古い媒体を減らせる。 | 退役条件が曖昧だと、消しすぎるか残しすぎる。 | 復元確認、代替系統確保、保持理由消滅を条件に進める。 |
12.3 レジリエンスは復元可能性を中心に評価する
暗号化ディスクの評価軸は、最終的には復元可能性である。暗号方式が新しいか、 KDF が強いか、ファイルシステムが現代的か、媒体が大容量かという要素は重要である。しかし、それらはすべて復元可能性を支える部品であって、目的そのものではない。バックアップの価値は、障害時、移行時、誤削除時、媒体故障時、十年後の復旧時に、必要なデータを正しく取り戻せるかで決まる。暗号化ディスクでは、そこに機密性の条件が加わる。第三者には読ませず、正当な利用者は読める。この両立ができて初めて、暗号化ディスクはレジリエンス資産になる。
復元可能性を中心に置くと、古い構成の扱いも変わる。古い構成は、現在の主系としては退くべきである。しかし、開封確認済みで、読み取り確認済みで、内容が把握され、現行主系との関係が明確で、退役条件が定義されているなら、期間限定の復元経路として意味を持つ。逆に、最新構成であっても、復元テストがなく、ヘッダー保全もなく、台帳もなく、同期ログも見ていないなら、見かけほど強くない。レジリエンスは、方式名ではなく、復元条件の管理状態によって評価すべきである。
| 評価対象 | 表面的な見方 | レジリエンス上の見方 |
|---|---|---|
| LUKS2 新媒体 | 現行標準なので安全である。 | ヘッダー保全、 key slot 管理、復元テスト、台帳があって初めて主系として信頼できる。 |
| LUKS1 旧媒体 | 古いので危険である。 | 新規主系にはしないが、確認済みなら移行元や互換バックアップとして意味を持つ。 |
| TrueCrypt 旧媒体 | 保守終了なので無価値である。 | 新規採用は避けるが、既存資産の読み出し経路としては台帳化と移行確認の対象になる。 |
| 複数媒体 | 台数が多いので安心である。 | 同じ失敗モードを共有していないか、世代、場所、方式、手順が分散しているかを確認する。 |
| 古い媒体の退役 | 整理できるので良いことである。 | 退役後も復元経路が残ることを確認して初めて良い整理になる。 |
12.4 古い構成は役割が終わった時点で退役させる
古い構成を管理するということは、古い構成を永遠に残すことではない。むしろ、役割が終わった時点で退役させるところまで含めて管理である。旧 LUKS1 媒体は、現行 LUKS2 主系と副系へデータが移行され、復元確認が済み、旧媒体にしかないファイルや世代がないことを確認できれば、退役候補になる。 TrueCrypt + FAT 旧媒体も、必要データが現行主系へ移され、ファイルシステム差による取りこぼしが確認され、互換バックアップとしての保持理由が消えれば、退役対象になる。古い媒体を残し続けることは、いつかは復元経路ではなく、情報漏洩、誤操作、媒体劣化、管理負荷の原因になる。
退役は、削除ではなく工程である。退役前には、対象媒体の識別、内容確認、移行先確認、復元テスト、代替系統確認、ヘッダーと解除条件の扱い、安全消去方法、台帳更新が必要である。退役後には、その媒体が管理対象外になったこと、または物理破棄されたこと、または再利用されたことを記録する。これにより、後から「この媒体は消してよかったのか」「この媒体にしかないデータはなかったのか」「このヘッダーバックアップは何に対応していたのか」という疑問が残らない。レジリエンスにおける退役とは、復元可能性を損なわずに複雑性を減らす作業である。
| 退役前確認 | 確認内容 | 未確認の場合 |
|---|---|---|
| 対象識別 | 媒体 ID、型番、容量、 UUID、物理ラベルを確認する。 | 退役対象の取り違えが起きる。 |
| 内容確認 | 旧媒体にしかないデータ、世代、メタデータがないことを確認する。 | 消去後に復元不能な欠落が発覚する可能性がある。 |
| 移行先確認 | 現行主系と副系に必要データが存在することを確認する。 | 旧媒体を消すと復元経路が不足する。 |
| 復元テスト | 移行先から実際に open、 mount、読み取り、復元できることを確認する。 | コピー済みに見えても復旧時に使えない可能性がある。 |
| 解除条件整理 | 旧媒体のパスフレーズ、 keyfile、 key slot、ヘッダーバックアップの扱いを決める。 | 用途不明の秘密情報やヘッダーバックアップが残る。 |
| 安全消去 | 消去、物理破棄、再利用、保管停止の方法を決める。 | 情報漏洩または管理対象不明媒体が残る。 |
| 台帳更新 | 退役日、理由、処置、代替媒体、確認結果を記録する。 | 後から退役済みかどうか判断できなくなる。 |
12.5 長期運用では完全な最終形ではなく更新可能な構造を目指す
暗号化ディスクに完全な最終形はない。現在の LUKS2 + AES-XTS + Argon2id も、長い時間軸ではいずれ古くなる。将来、 KDF の推奨値は変わるかもしれない。ストレージ暗号化で完全性保護をより強く含む構成が一般化するかもしれない。 cryptsetup の既定値や LUKS の形式が変わるかもしれない。 HDD や SSD の媒体特性も変わり、ファイルシステムの選択も変わるかもしれない。つまり、現在の最善は、将来の最善ではない。したがって、暗号化ディスクの設計では、ある時点の完成形を固定するのではなく、将来の見直しと移行を前提にした更新可能な構造を作るべきである。
更新可能な構造とは、主系が明確で、旧方式の役割が定義され、媒体台帳があり、ヘッダーが保全され、 key slot が管理され、復元手順が文書化され、検証履歴が残り、退役条件が設定されている状態である。この状態なら、将来 LUKS2 がレガシー化しても、どの媒体を移行すべきか、どの媒体を残すべきか、どの媒体を退役できるかを判断できる。逆に、現在の方式がどれほど強くても、記録がなく、手順がなく、確認履歴がなければ、将来の更新は困難になる。レジリエンスとは、変化しない構成を作ることではなく、変化に追随できる構成を維持することである。
| 項番 | 固定的な設計 | 更新可能な設計 | 長期運用での差 |
|---|---|---|---|
| 1 | 作成時点の暗号方式だけを記録する。 | 暗号方式、 KDF、 key slot、ヘッダー、役割、確認日を記録する。 | 将来の移行判断に必要な情報量が変わる。 |
| 2 | 最新媒体へコピーしたら旧媒体を消す。 | 新媒体の復元確認が完了するまで旧媒体を移行元として保持する。 | 移行失敗時に戻れるかどうかが変わる。 |
| 3 | 古い媒体を何となく残す。 | 古い媒体に互換バックアップ、読み取り中心アーカイブ、退役候補などの役割を与える。 | 旧媒体が資産になるか混乱要因になるかが変わる。 |
| 4 | 復元手順を記憶に頼る。 | 通常運用、復元、移行、退役の手順書を分けて持つ。 | 障害時の誤操作リスクが変わる。 |
| 5 | 媒体の存在だけを確認する。 | open、 mount、読み取り、復元テストを定期的に記録する。 | 存在している媒体を復元可能資産として扱えるかが変わる。 |
12.6 結論
本稿の結論は、暗号化ディスクのレジリエンスとは、古い構成を一掃することではなく、古い構成の意味を確定し、必要な期間だけ管理し、役割が終わった時点で退役させる能力だということである。新規主系は現行標準へ寄せるべきである。現在なら LUKS2 + AES-XTS + Argon2id を基本にし、ファイルシステム、媒体、ヘッダー保全、 key slot 管理、復元テストを含めて設計するのが自然である。しかし、長期運用では、旧 LUKS1、 TrueCrypt、 FAT、古い HDD、過去の同期状態、過去の復旧手順が残る。これらは、ただ古いから消すべきものではない。同時に、ただ残しておけばよいものでもない。
必要なのは、現在の主系、同質冗長性、異質冗長性、移行元、互換バックアップ、読み取り中心アーカイブ、退役候補を分けることである。古い構成は、主系ではなく、復元経路、比較元、移行失敗時の逃げ道として役割を限定する。役割がある間は、台帳化し、開封確認し、読み取り確認し、解除条件を管理し、退役条件を設定する。役割が終わったら、復元確認と代替系統の確保を済ませたうえで退役させる。この流れがなければ、最新方式への統一は復元経路の喪失になり、旧方式の保持は管理不能な残骸になる。
したがって、長期運用における暗号化ディスクは、暗号方式の選定だけでは完結しない。 LUKS1 と LUKS2、 CBC-ESSIV と XTS、 PBKDF2 と Argon2id、 TrueCrypt と LUKS、 FAT と ext4、 HDD と SSD、主系と互換バックアップ、作成と退役を、すべて時間軸の中で扱う必要がある。暗号方式は必ず古くなる。媒体も劣化する。復旧環境も変わる。だからこそ、必要なのは永久に正しい構成ではなく、将来の見直し、移行、退役に耐える運用構造である。レジリエンスとは、壊れないことではなく、古くなっても意味を失わず、必要なときに戻せ、役割を終えたものを安全に閉じられることである。
参考文献
- id774, 未来の自分に意味を残す（2026-05-12）. https://blog.id774.net/entry/2026/05/12/4750/
- id774, バックアップ・リカバリー戦略における物理媒体管理（2026-05-10）. https://blog.id774.net/entry/2026/05/10/4743/
- 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, 2.5-inch HDD で LUKS + ext4 が遅くなった理由（2026-05-24）. https://blog.id774.net/entry/2026/05/24/4801/
- id774, Linux カーネルを利用して暗号化ファイルシステムを使う（2014-11-17）. https://blog.id774.net/entry/2014/11/17/548/
- The Linux Kernel documentation, dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-crypt.html
- cryptsetup project, Cryptsetup and LUKS. https://gitlab.com/cryptsetup/cryptsetup
- Clemens Fruhwirth, LUKS1 On-Disk Format Specification Version 1.2.3. https://mirrors.chroot.ro/kernel/linux/utils/cryptsetup/LUKS_docs/on-disk-format.pdf
- Milan Broz, LUKS2 On-Disk Format Specification. https://fossies.org/linux/cryptsetup/docs/on-disk-format-luks2.pdf
- cryptsetup 2.0.0 Release Notes. https://cdn.kernel.org/pub/linux/utils/cryptsetup/v2.0/v2.0.0-ReleaseNotes
- cryptsetup 2.1.0 Release Notes. https://www.kernel.org/pub/linux/utils/cryptsetup/v2.1/v2.1.0-ReleaseNotes
- Red Hat Documentation, Chapter 9. Encrypting block devices using LUKS. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/encrypting-block-devices-using-luks_security-hardening
- cryptsetup-luksFormat(8), Linux manual page. https://man7.org/linux/man-pages/man8/cryptsetup-luksFormat.8.html
- Morris Dworkin, 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
- IEEE Std 1619-2007, IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices. https://standards.ieee.org/standard/1619-2007.html
- Kathleen Moriarty, Burt Kaliski, Andreas Rusch, RFC 8018, PKCS #5: Password-Based Cryptography Specification Version 2.1. https://www.rfc-editor.org/rfc/rfc8018.html
- Alex Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, RFC 9106, Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications. https://www.rfc-editor.org/rfc/rfc9106.html
- Jos Wetzels, Open Sesame: The Password Hashing Competition and Argon2. https://arxiv.org/abs/1602.03097
- TrueCrypt Foundation, TrueCrypt User Guide. https://garykessler.net/library/crypto/TrueCrypt%20User%20Guide.pdf
- VeraCrypt Documentation, Header Key Derivation, Salt, and Iteration Count. https://veracrypt.io/en/Header%20Key%20Derivation.html
- BSI, Security Analysis of TrueCrypt. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/Truecrypt/Truecrypt.pdf?__blob=publicationFile&v=2
- NCC Group Cryptography Services, Truecrypt Phase Two Audit Announced. https://cryptoservices.github.io/blog/2015-02-18-truecrypt-phase-two/
- Elaine Barker, NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
- Elaine Barker, Allen Roginsky, NIST SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths. https://csrc.nist.gov/pubs/sp/800/131/a/r2/final