## 定義 暗号利用モード(mode of operation)は、固定長のブロックしか扱えないブロック暗号を、任意長のメッセージに拡張して使うための構成方式である。安全でないモードを既定に使わせる暗号ライブラリが実際の脆弱性の主要な原因になってきたため、モードの選択は暗号アルゴリズム自体の選択と同じかそれ以上に重要とされる。**ECB(Electronic Code Book)モード**はブロックごとに独立して暗号化するため実装が単純だが、平文の反復パターンがそのまま暗号文に現れ、また複数ブロックのメッセージに対しては切り貼り攻撃(cut-and-splice attack)を許すため、単一ブロックのプロトコル(チャレンジ・レスポンスなど)以外では使うべきではない。**CBC(Cipher Block Chaining)モード**は直前の暗号文ブロックを平文に XOR してから暗号化することでパターンを隠すが、完全性保護がないため 2 ブロック単位の改ざんを許し、パディングの検証方法によってはパディングオラクル攻撃(padding oracle attack、Serge Vaudenay, 2002 年)を招く。**CTR(カウンタモード)**はカウンタを暗号化して鍵ストリームとして使う加法的ストリーム暗号で、並列化しやすい一方、鍵ストリームの再利用や完全性の欠如というストリーム暗号一般の弱点を継承する。レガシーなストリームモードとして OFB(出力フィードバック)・CFB(暗号文フィードバック)があるが、誕生日定理により周期が 2^(n/2) ブロックに制限される問題を持つ。メッセージ認証コード(MAC)は CBC モードで最後の暗号文ブロックだけを残す構成で作れる。現代の既定は認証付き暗号(authenticated encryption)であり、**GCM(Galois Counter Mode)**は 2007 年に NIST が承認した方式で、カウンタモードの暗号化とガロア体上のユニバーサルハッシュによる認証タグ生成を、ブロック暗号 1 回の呼び出しで両立し並列化・インクリメンタル計算が可能である。ディスク暗号化のように平文長を保つ必要がある用途では、セクタ番号由来のトゥイーク鍵でホワイトニングする**XTS**モードが使われる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 5 Cryptography]], ch.5 §5.5〜§5.5.7) ## 横断的知見 - **GCMは暗号技術としては第5章が扱う認証付き暗号利用モードだが、その起源は第15章が扱う核指揮統制向けの無条件安全な一回限り認証符号(unconditionally secure authentication)の研究にある**: 第5章はGCMを「2007年にNISTが承認した認証付き暗号の現代的な既定」として、カウンタモードの暗号化とガロア体上のユニバーサルハッシュを組み合わせた技術仕様の観点から説明する。第15章はこれと同じGCMを名指しし、「認証研究からの興味深い副産物の1つがブロック暗号のGCM利用モードであり、現代の暗号スイートで最も一般的な利用モードになった」と述べ、GCMの祖先が核兵器の起爆コマンドを検証するための無条件安全な認証符号(鍵を一度しか使わないことで計算資源によらず安全性を保証する符号)の研究にあることを明かす。第5章単独では技術仕様しか分からないが、第15章と突き合わせることで、現代の暗号ライブラリが既定にするGCMという実装上の選択が、軍事的な脅威モデル(核兵器の不正起爆防止)から生まれた理論の民生転用であることが分かる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 5 Cryptography]] ch.5 §5.5.6, [[@2020__Wiley__Security Engineering 3e - Chapter 15 Nuclear Command and Control]] ch.15 §15.3) - **XTSモードは第5章では抽象的な仕様として、第20章では具体的な製品史として現れ、突き合わせるとモードの理論上の設計と実運用の間にあるギャップが見える**: 第5章はXTSを「セクタ番号由来のトゥイーク鍵でホワイトニングするモード」として簡潔に定義するに留まる。第20章は、XTS-AESが2010年からフルディスク暗号化(FDE)専用モードとして使われ始め、AES対応CPU上ではオーバーヘッドが数%に留まると具体的な性能を報告する一方、XTSモード自体は暗号文の完全性を保護しないため、2008年のコールドブートアタック(DRAMを冷却して一時鍵を読み出す)のような「鍵の物理的な残留」に起因する攻撃には無力であることを示す。これは、モードの選択(XTS)だけでは実運用の脅威(鍵管理・ハードウェアからの鍵の露出)を防げず、[[耐タンパ性]]・鍵のライフサイクル管理が別途必要であることを、単一の章では見えない形で明らかにする。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 5 Cryptography]] ch.5 §5.5.7, [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]] ch.20 §20.2) ## 未解決の問い - 暗号ライブラリが ECB を既定にしてしまう UX 上の理由(API 設計の問題か、後方互換性の問題か)は、本章では言及されていない。第 3 章(Psychology and Usability)との関連を確認する価値がある。 - CCM モード(Bluetooth 4.0 以降で使用、CBC-MAC とカウンタモードの組み合わせ)は GCM に比べて計算コストが 2 倍で並列化・インクリメンタル再計算ができないとされるが、それでも採用され続けている理由(ハードウェア制約か標準化の経緯か)は要確認。 - ~~XTS モードは高層の完全性保護機構と組み合わせる必要があるとされるが、実際のディスク暗号化製品(BitLocker 等)がどのような完全性機構を上乗せしているかは、本章の範囲外(第 20 章以降)。~~ → 第20章で部分的に解決。[[フルディスク暗号化]] を参照(XTS-AESの採用時期・性能・鍵管理の詳細)。ただしXTS自体の完全性保護の欠如をどう補っているかの具体的な機構(BitLocker/FileVaultの内部設計)までは第20章でも踏み込まれておらず、この点は未解決のまま残る。 ## 関連 - [[@2020__Wiley__Security Engineering 3e - Chapter 5 Cryptography]] — ECB・CBC・CTR・GCM・XTS の詳細 - [[@2020__Wiley__Security Engineering 3e - Chapter 15 Nuclear Command and Control]] — GCMの起源となった一回限り認証符号研究 - [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]] — XTS-AESの実運用(フルディスク暗号化)での採用 - [[ブロック暗号設計原則]] — モードが前提とするブロック暗号自体の内部構造(AES・DES) - [[ランダムオラクルモデル]] — ランダム順列(ブロック暗号)を複数ブロックに拡張する際の理論的背景 - [[秘密分散]] — 同じ核指揮統制研究から派生したもう1つの暗号数学分野 - [[フルディスク暗号化]] — XTSモードの具体的な応用先 ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 5, §5.5. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 15, §15.3. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 20, §20.2.