【実務・中級編】暗号化アルゴリズムの選択と実装の落とし穴 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

「暗号化しておけば安心」という幻想を捨てる：ECBモードが招く惨劇とAEADによる堅牢な実装

「AESで暗号化しています」。そう胸を張るエンジニアほど、実は致命的な穴を空けていることが多い。

現場でインシデント対応をしていると、いまだに AES-ECB モードを採用しているシステムに遭遇する。これは「鍵さえあれば中身は守れる」という甘い考えが生んだ遺物だ。暗号理論をかじっただけの設計者が陥るこの罠について、今日は徹底的に掘り下げよう。

なぜECBモードは「暗号」として機能しないのか

ECB（Electronic Codebook）モードの最大の問題点は、「同じ平文ブロックが常に同じ暗号文ブロックになる」という性質にある。

例えば、ユーザーの権限情報が暗号化されてクッキーに保存されているとしよう。攻撃者は、暗号化の仕組みを理解していなくても、パケットをキャプチャし、特定のブロックを入れ替えるだけで、一般ユーザーの権限を管理者権限にすり替えることが可能だ。

攻撃者視点のPoC（概念実証）

1. キャプチャ: ログイン後のリクエストを傍受し、暗号化されたクッキーを取得。
2. パターン分析: 同じ権限を持つ複数のユーザーのクッキーを比較し、権限に関連するブロックを特定。
3. ブロック置換: 管理者のクッキーから「管理者権限ブロック」を抽出し、自分のクッキーの「一般権限ブロック」と差し替える。
4. 実行: サーバー側は復号結果の整合性を検証しないため、そのまま管理者として処理される。

ECBはデータの「機密性」を部分的に隠すだけで、「完全性（改ざんされていないこと）」を一切保証しない。これが今のWebアプリケーションにおいて致命的となる理由だ。

現代の正解：AEAD (Authenticated Encryption with Associated Data)

現代の暗号実装において、我々が選択すべきは AES-GCM のような認証付き暗号（AEAD）だ。これはデータの機密性だけでなく、「改ざん検知（認証タグ）」をセットで提供してくれる。復号時にタグが一致しなければ、即座にエラーを吐き出して処理を中断する。これにより、ブロック置換攻撃は物理的に不可能になる。

実装サンプル：Pythonによるセキュアな暗号化

Pythonの cryptography ライブラリを用いた、現場レベルで即採用すべき実装例を紹介する。

import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

# 鍵は環境変数等で安全に管理し、決してソースコードにハードコードしないこと
# AES-GCMでは256ビット(32バイト)の鍵を推奨
key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(key)

def encrypt_data(plaintext: str) -> bytes:
    # ノンス(nonce)は毎回生成し、暗号文と一緒に保存する
    nonce = os.urandom(12)
    ciphertext = aesgcm.encrypt(nonce, plaintext.encode(), None)
    # ノンスと暗号文を結合して返す
    return nonce + ciphertext

def decrypt_data(encrypted_data: bytes) -> str:
    # 先頭12バイトからノンスを取り出す
    nonce = encrypted_data[:12]
    actual_ciphertext = encrypted_data[12:]
    
    # 復号時にタグの検証が自動で行われる
    # 改ざんがあれば InvalidTag 例外が発生する
    try:
        decrypted = aesgcm.decrypt(nonce, actual_ciphertext, None)
        return decrypted.decode()
    except Exception:
        raise ValueError("データの改ざん、または鍵の不一致が検出されました")

運用で守るべき「鉄の掟」

コードが正しくても、運用がずさんなら意味がない。以下のルールを徹底してほしい。

1. ノンス（IV）の使い回し厳禁

AES-GCM において、同じ鍵とノンスの組み合わせを二度使ってはいけない。一度でも再利用すれば、暗号文から鍵が推測されるリスクが跳ね上がる。常に os.urandom(12) 等で一意な値を生成すること。

2. 鍵管理は「Vault」で

ソースコードに key = "secret123" などと書くのは論外だ。

AWS環境: AWS KMS や AWS Secrets Manager を利用し、アプリケーションには権限だけを渡す。
オンプレ: HashiCorp Vault 等のシークレット管理ツールを導入する。

3. WAFでの多層防御

もし暗号化通信に脆弱性が残っていたとしても、異常なリクエストを弾くのはWAFの役割だ。

# Nginx設定例: 異常な長さや形式のクッキーを弾く
# 攻撃者がブロック置換を試みる際、クッキーが不自然に長くなるケースを想定
location / {
    if ($http_cookie ~* ".{512,}") {
        return 403;
    }
}

最後に：なぜ「泥臭さ」が必要なのか

セキュリティの現場では、教科書通りの実装をしたつもりでも、ライブラリのバージョンアップや依存関係の齟齬で脆弱性が生まれることがある。

「暗号化されているから大丈夫」という思考停止が、攻撃者にとっての最大の入り口だ。常に「もしこのパケットを操作されたらどうなるか？」「復号時にゴミデータが混入したらどうなるか？」と疑い、実装の各段階で「期待外れの入力」を投げてみるテストを習慣づけてほしい。

完璧な防御は存在しない。だが、我々が実装する暗号が「攻撃者にとってコストが見合わない」と言わせるレベルまで高めることはできる。今日からECBモードのコードを見つけたら、即座にリファクタリングのタスクを切るように。それが君たちのプロジェクトを救うことになる。