Block Cipher Modes

暗号利用モード（Block Cipher Modes of Operation）とは、AESなどのブロック暗号を実際のデータに適用する際の処理方式を定めた規格です。ブロック暗号は固定長（AESの場合128ビット）のデータブロック単位でしか処理できないため、可変長のメッセージを暗号化するには「どのようにブロックを連鎖させるか」を決める暗号利用モードが不可欠です。

暗号利用モードの選択は、暗号システムの安全性を根本的に左右します。同じAES-256を使用していても、モードの選択を誤ればデータのパターンが暗号文に漏洩したり、改ざんを検知できなかったりする深刻な脆弱性が生じます。特に近年では、暗号化と同時にデータの完全性・真正性を保証するAEAD（Authenticated Encryption with Associated Data）モードの使用が強く推奨されています。

代表的な暗号利用モードには、ECB、CBC、CTR、GCM、CCMなどがあり、それぞれ異なるセキュリティ特性と用途を持っています。現在のベストプラクティスでは、AES-GCMまたはChaCha20-Poly1305の使用が標準とされています。

ECBモード（Electronic Codebook）

ECBは最も単純な暗号利用モードで、各ブロックを独立に暗号化します。しかし、同一の平文ブロックが同一の暗号文ブロックになるため、データのパターンが暗号文に保存されてしまいます。有名な「ECBペンギン」の例では、画像をECBモードで暗号化してもペンギンのシルエットが判別可能であることが示されています。ECBモードは絶対に使用してはならないモードとして、すべてのセキュリティガイドラインで警告されています。

CBCモード（Cipher Block Chaining）

CBCは各ブロックの暗号化前に、前のブロックの暗号文とXOR演算を行うことでブロック間に依存関係を持たせるモードです。最初のブロックにはIV（初期化ベクトル）と呼ばれるランダムな値が使用されます。CBCは長年にわたり広く使用されてきましたが、パディングオラクル攻撃に対して脆弱であること、並列処理ができないこと、そして暗号化のみで認証機能を持たないことが欠点です。CBCを使用する場合は、必ずHMAC等による認証を追加するEncrypt-then-MAC構成が必要です。

CTRモード（Counter）

CTRはカウンター値をブロック暗号で暗号化し、その出力と平文をXORすることで暗号化を行うストリーム暗号的なモードです。各ブロックの処理が独立しているため完全な並列処理が可能であり、高速な暗号化・復号が実現できます。ただし、CTR単体では認証機能がないため、改ざん検知ができません。

GCMモード（Galois/Counter Mode）

GCMはCTRモードによる暗号化とGalois体上のMAC計算を組み合わせたAEADモードです。暗号化と認証を同時に行い、暗号文の改ざんを検知できます。さらに、暗号化されない「関連データ（Associated Data）」にも認証タグを適用できるため、ヘッダ情報などの完全性も保証できます。GCMはTLS 1.3、IPsec、SSH、各種APIで標準的に採用されており、ハードウェアアクセラレーション（AES-NI）との組み合わせにより極めて高い処理性能を発揮します。

ただし、GCMにはノンス（Nonce）の一意性に関する厳格な要件があります。同一鍵で同じノンスを再利用すると、認証機能が完全に崩壊し、認証タグの偽造や平文の復元が可能になります。96ビットのノンスを使用する場合、同一鍵で暗号化できるメッセージ数は安全性の観点から約2^32（約43億）に制限されます。

CCMモード（Counter with CBC-MAC）

CCMはCTRモードとCBC-MACを組み合わせたAEADモードです。GCMと同様に暗号化と認証を同時に提供しますが、2パス処理が必要なため GCMより処理速度が劣ります。主にIoTデバイスやBluetooth（BLE）、Wi-Fi（WPA2のCCMP）などリソース制約のある環境で使用されています。

パディングオラクル攻撃

CBCモードでは平文をブロック長に合わせるためにパディング（PKCS#7等）が必要です。パディングオラクル攻撃は、復号時のパディング検証結果（正しい/不正）がサーバーの応答から判別できる場合に成立する攻撃です。攻撃者は暗号文を操作してサーバーに送信し、パディングの検証結果を観察することで、1バイトずつ平文を復元できます。この攻撃は理論的なものではなく、ASP.NETの「Padding Oracle On Downgraded Legacy Encryption（POODLE）」攻撃やJavaのCBC実装など、多数の実システムで悪用されました。AEADモードを使用すれば、暗号文の改ざんが認証タグの検証で検知されるため、パディングオラクル攻撃は成立しません。

AEAD（認証付き暗号）の重要性

従来の暗号利用モード（ECB、CBC、CTR等）は暗号化のみを提供し、データの完全性・真正性は保証しません。これに対し、AEADは暗号化と認証を単一の処理で統合的に提供します。AEADにより、暗号文の改ざん、切り詰め、再配置といった攻撃をすべて検知できます。現在のセキュリティ標準では、暗号化には必ずAEADモードを使用し、自前で「暗号化＋MAC」を組み合わせる実装は避けるべきとされています。

• 01
  AEADモードの採用を必須化：新規開発では必ずGCMまたはChaCha20-Poly1305などのAEADモードを使用してください。ECBは絶対に使用禁止、CBCも新規採用は推奨されません。AEADモードは暗号化と認証を単一のAPIで提供するため、「暗号化はしたが認証を忘れた」という実装ミスを防止できます。
• 02
  GCMのノンスを絶対に再利用しない：GCMモードでは同一鍵に対するノンスの一意性が安全性の前提条件です。ノンスの再利用は認証機能の完全な崩壊を招きます。カウンターベースの生成（推奨）またはランダム生成（96ビットノンスの場合は2^32メッセージ以下に制限）を採用し、鍵のローテーションと組み合わせてノンス空間の枯渇を防いでください。
• 03
  IVの安全な生成と管理：CBCモードのIVは暗号論的擬似乱数生成器（CSPRNG）で毎回新たに生成し、予測不可能であることを保証してください。IVは機密ではありませんが、暗号文と一緒に送信・保存する必要があります。固定IVや予測可能なIVの使用は、BEAST攻撃のような選択平文攻撃の原因となります。
• 04
  ECBモードの使用を組織全体で禁止：コードレビュー、静的解析ツール（Semgrep、CodeQL等）にECBモード検出ルールを導入し、ECBの使用を自動的に検出・ブロックしてください。AES-ECBはライブラリのデフォルト設定になっている場合があるため、暗号化APIの呼び出し箇所を重点的にレビューすることが重要です。
• 05
  パディングオラクルの防止：CBCモードを使用するレガシーシステムでは、復号エラーとパディングエラーを区別できないよう、一定時間応答（constant-time comparison）を実装してください。ただし、最善の対策はAEADモードへの移行です。AEADでは認証タグの検証が先に行われるため、パディングオラクルは原理的に成立しません。
• 06
  暗号利用モードの選定基準を文書化：組織の暗号ポリシーとして、用途別の暗号利用モード選定基準を策定・文書化してください。TLS通信にはAES-256-GCMまたはChaCha20-Poly1305、ディスク暗号化にはXTS-AES、データベース暗号化にはAES-GCMなど、具体的な推奨構成を明記し、開発者が迷わない環境を整備しましょう。