2026.05.25

【AES入門編】ECB・CBC・パディングオラクルの基本攻撃｜CTF思考フレームワーク #54

安全に生きたい編集部

広告・PRを含みます。この記事にはアフィリエイトリンクが含まれます。掲載内容は編集方針に基づいて作成していますが、価格・在庫・キャンペーン内容はリンク先で最新情報を確認してください。

AESって、現代の標準暗号だよね？それでも破れることあるの？🔑

AES自体は破られていません。でも『使い方を間違えると』破られます。ECBモード（パターンが見える）、CBCモード（パディングオラクル）、Nonce再利用――どれもCTFと現実世界で頻出する穴です。

AES（Advanced Encryption Standard）は、2001年に米国標準となった対称鍵暗号。アルゴリズム自体は安全ですが、ECB・CBC・CTR・GCM などの『暗号利用モード』の選択と、パディング・IV・Nonce の使い方によって安全性が大きく変わります。実装ミスが攻撃面になります。

AES自体は強くても、使い方間違えたら穴になるんだ…

この記事は、CTF思考フレームワーク第54回。AES の基本（ECB/CBC/CTR/GCM）と、CTFで頻出の攻撃（ECB Block Shuffle・Padding Oracle・CBC Bit-Flip）、開発側の正しい使い方を整理します。

📖 この記事はシリーズの一部です
「CTF思考フレームワーク」 #54 / 全86記事　→　シリーズ一覧を見る →

🔒 AESは現代対称暗号の主役。中身を解読するのは現実的に不可能ですが、「使い方の弱点」は山ほどあります。ECBで構造が見える、CBCのIV使い回し、パディングオラクル。

AES自体は強くても、運用モード（ECB/CBC/CTR/GCM）の選び方や鍵管理を間違えると一気に崩壊します。CTFのCryptoでも、AESを直接破るのではなく「使い方の隙」を突くのが定石。

難易度：★★☆（中級）

ECB・CBC・パディングオラクルの基本攻撃をおさらいします🧊

AESはアルゴリズムは強い、でも使い方を間違えると即破綻するブロック暗号だよ🧊

この記事で出てくる言葉

先に意味を押さえておくと読みやすい用語です。

CTF: セキュリティの練習問題を解く競技。必ず許可された環境だけで試します。
権限昇格: 一般ユーザーから管理者権限など、より強い権限を得ることです。
脆弱性: ソフトや仕組みにある弱点。攻撃者に悪用されると不正アクセスにつながります。

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：実際の手口
🛡️ 防御フェーズ：どう守る？
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい
✍️ 学んだことを発信する
⚖️ 大事なお約束

👀 観察フェーズ：まず何を見る？

まずモード(ECB / CBC / CTR / GCM)を見抜こう！同じ平文を渡したときの暗号文の差が手掛かり🔍

暗号文を見たら、まずモードを推測。ブロックサイズ16の倍数か、IVが先頭にあるか、同じ平文ブロックが繰り返されているか（ECBの動かぬ証拠）。

長さが16の倍数かチェック（パディング有無）
同一16バイトブロックの繰り返し（ECBの匂い）
IV/Nonce が先頭16バイト or 12バイト（CBC/GCM）
タグ末尾16バイト（GCM）
パディングオラクル兆候（”invalid padding”のメッセージ差）
同一鍵×同一nonceの再利用（CTR/GCMで致命）

ECBは同じブロックは同じ暗号文。画像を暗号化したのにペンギンの輪郭が見えるのが古典例👀

モード次第で「同じ強度のAESが安全にも危険にもなる」って覚えておくべきだね💡

🤔 仮説フェーズ：攻撃者は何を考える？

AES基本攻撃の典型は4パターン。

🕶️ 攻撃者は「ECBなら平文構造が漏れる」「CBCならパディングオラクルや bit-flipping」「CTR/GCMはnonce再利用で全壊」と発想します。CTFでは「ECBペンギン画像」「CBCのIV既知」「Padding Oracle Attack」が三大定番。

🐧 仮説①：ECBペンギン

同一平文ブロックは同一暗号文に。パターンが透けるから重要情報には絶対使うな。

🔁 仮説②：CBCバイトフリッピング

前ブロックの暗号文を1バイト変えると次ブロック平文の対応位置が変化。認証なしCBCは改ざん可能。

🪪 仮説③：パディングオラクル

CBC復号時のパディングエラーを返すサーバがあれば、ブロックごとに1バイトずつ平文を復元できる。

🧂 仮説④：IV再利用

CTRやGCMで同じIV(nonce)を異なる平文に再利用すると鍵ストリーム差分から平文復元。

AESは「鍵」よりも「モードとIVと認証」が事故源なんだね💡

🔬 検証フェーズ：どうやって確かめる？

CTFでパディングオラクルが見えたらpadbusterや自作スクリプトで自動化🧪

ECB判定は同一ブロック数の検出が最速。CBCはバイト書き換えで「直前ブロックの平文をflipできる」ことを実験。Padding OracleはサーバのHTTP応答差分で判定。

# ECB検出（重複16バイトブロック）
def looks_ecb(ct, blk=16):
    blocks = [ct[i:i+blk] for i in range(0, len(ct), blk)]
    return len(blocks) - len(set(blocks))

# CBC bit-flip：直前ブロックのc_iをXORで書き換え
# C'_i = C_i ^ (P_{i+1} ^ desired_P_{i+1})
# 結果としてP_{i+1}の指定バイトが書き換わる

# Padding Oracle (PoCサンプル)
# サーバが「padding error」と「decryption ok」を別レスで返すなら勝ち

IV再利用は2平文の暗号文をXORすると平文XORが出てくるんだね💡

⚔️ 攻撃フェーズ：実際の手口

AES基本攻撃トップ3。

基本攻撃：①ECBペンギン（同一ブロック繰り返し）、②CBC bit-flip（権限昇格や cookie書換）、③Padding Oracle（CBC全体の復号）、④CTR/GCMでnonce再利用（XOR攻撃）。

# Padding Oracle Attack（概念）
# 1) 直前ブロック C_{i-1} の最終バイトを総当たり
# 2) サーバが「padding ok」を返した値で P_i 最終バイトを復元
# 3) 1バイトずつ後ろから埋める（256回×ブロック長）

# CTR nonce再利用 → XORで平文関係露呈
P1 ^ P2 = C1 ^ C2  # 既知平文があれば全部解ける

AES-GCMはnonce再利用すると認証鍵まで漏れます（forbidden attack）。同一鍵×同一nonceは絶対NG、これだけは死守🛡️

① パディングオラクルで全文復号

CBC復号サーバが「パディングエラー」と「他のエラー」を区別するなら全文復元可能。

② Bit-flipで認証回避

CBCで「user=guest」を「user=admin」に書き換える古典攻撃。

③ IV/nonce再利用

CTR/GCMで同じnonce再利用→2平文XORが見える＋GCMなら認証鍵まで取れる。

🛡️ 防御フェーズ：どう守る？

AES安全運用の3鉄則！🛡️

AES運用の鉄則は「認証付き暗号（GCM/ChaCha20-Poly1305）を使う」「nonceは絶対に再利用しない」「鍵管理はKMSへ」。素のCBCはほぼ全シナリオで非推奨。

原則 AES-GCM または ChaCha20-Poly1305
nonce生成は 暗号学的乱数 または カウンタ
鍵は KMS / HSM で集中管理
CBCを使うなら必ず HMAC + Encrypt-then-MAC
パディングエラーとMAC検証エラーで応答時間を揃える
TLSのレガシーCipher Suiteを全廃

✅ AES-GCM(AEAD)を使う

機密性＋完全性をワンパッケージで提供。ChaCha20-Poly1305も同等候補。

🚫 ECBは使わない / 自前パディング検査をしない

ECBは禁止。CBCを使うなら必ずMACで認証(Encrypt-then-MAC)。

🎲 IV/nonceは適切に管理

GCMは96bit nonceをカウンタかランダムで。絶対に再利用しない。

「AES-GCMで全部終わる」って覚えておくと事故りにくい💪

⚠️ よくある落とし穴

ECBで暗号化して「データが見えないからOK」と判断
IVを定数や0埋めで運用
nonce再利用（特にステートレスサーバの起動毎リセット）
パディングエラーをHTTP 400で個別に返す（オラクル化）
AES-CBC + 自作MACで順序を間違える（MAC-then-Encryptは脆弱）
AES-GCMの2^32 ブロック上限を超えて運用

🧰 ツール早見表

ツール	用途	備考
CyberChef	ECB/CBC/CTR/GCM変換	ブラウザだけで完結
PyCryptodome	Python実装	Crypto.Cipher.AES
padbuster	Padding Oracle自動化	CBC復号
BLEACH (Bleichenbacher)	有名Crypto脆弱性ツール	ROBOTテスト
NIST SP 800-38系	モード仕様の規範	実装確認の根拠