パディングオラクル攻撃とは？CBC暗号の脆弱性を突いた解読手法の仕組みと対策をわかりやすく解説

暗号化しているから安全だ、と思っていませんか。実は、暗号化のモードの選び方や実装の細部によっては、暗号文を繰り返し送りつけるだけで平文を丸ごと復元されてしまう攻撃が成立することがあります。それが「パディングオラクル攻撃」です。

セッションクッキーや認証トークンの暗号化に古い方式を使い続けているシステムは、今この瞬間も攻撃者の標的になりえます。

この記事では、パディングオラクル攻撃の仕組みを防御目的で解説し、暗号化ライブラリを使うすべての開発者・情シス担当者が把握すべき対策を具体的に紹介します。暗号の深い数学知識がなくても、仕組みと対策の要点を理解できる構成にしています。

パディングオラクル攻撃とは？

パディングオラクル攻撃（Padding Oracle Attack）とは、ブロック暗号のCBC（Cipher Block Chaining）モードで暗号化されたデータを、攻撃者が平文（元のデータ）に復元できてしまう攻撃です。

「オラクル（oracle）」とは「神託・お告げ」を意味する英単語で、セキュリティの文脈では「攻撃者が質問を投げると正誤を教えてくれる仕組み」を指します。パディングオラクル攻撃では、サーバーのエラーレスポンスがそのオラクルの役割を果たします。

2010年にASP.NETの暗号化実装に存在することが公開されたCVE-2010-3332は、まさにこの攻撃によってセッショントークンが復号される脆弱性でした。WebフォームやView Stateの保護に使われていた暗号化機構が標的になったことで、世界中のASP.NETサイトに影響が及びました。この例はパディングオラクル攻撃の深刻さを示した代表的なケースとして今も参照されています。

攻撃の仕組み（敵を知る）

1. CBCモードとパディングの基礎

CBCモードは、平文をブロック（通常16バイト）に分割して順番に暗号化する方式です。各ブロックを暗号化する前に、1つ前の暗号文ブロックとXOR（排他的論理和）演算をかけることで、同じ平文でも異なる暗号文が生成される設計になっています。

平文の長さがブロック長の倍数にならないとき、最後のブロックを埋めるためにパディング（Padding）が追加されます。代表的な方式がPKCS#7で、「不足バイト数と同じ値を並べる」というルールです。

想定例として：
・平文が15バイトなら、1バイト不足 → 末尾に「0x01」を1個追加
・平文が14バイトなら、2バイト不足 → 末尾に「0x02 0x02」を追加
・平文がちょうどブロック長なら、16バイト分の「0x10」を追加（最終ブロック全体がパディング）

復号後にサーバーはこのパディングを検証します。パディングが正しくなければエラーを返す、この動作こそが攻撃者に利用されます。

2. オラクルとしてのエラーレスポンス

攻撃が成立する条件は、サーバーが復号結果に応じて以下の2種類の異なる反応を返すことです。

・パディング正常: HTTPステータス 200 OK や「データが不正です」
・パディング異常: HTTPステータス 500 や「暗号化エラー」

この差分が「オラクル」として機能します。攻撃者は暗号文の特定バイトを1ビットずつ変化させ、サーバーの反応を観察しながら元の平文を1バイトずつ推定できます。256通りの値を試すだけで1バイトが特定でき、16バイトブロック全体を復元するには最大4,096回のリクエストで十分です。現代のネットワーク速度では、これを自動化すれば数分以内に完了します。

3. 攻撃が成立するシナリオ

以下のような実装がある場合、攻撃リスクが高まります。

・CBCモード（AES-CBC・3DES-CBC）で暗号化したセッショントークンやCookieを使っている
・復号の成否をHTTPステータスコードやエラーメッセージで区別して返している
・暗号文を外部から送り込める（URLパラメータ・Cookie・POSTボディ）

エラーメッセージが「Invalid padding」「Decryption error」のような詳細な文言を返す場合は特に危険です。エラー内容を伏せても、応答時間の差（タイミングオラクル）で攻撃が成立することもあります。

具体的な防御手順

1. 認証付き暗号化（AEAD）へ移行する

最も根本的な対策は、CBCモードをやめてAEAD（Authenticated Encryption with Associated Data）に移行することです。AEADは暗号化と改ざん検知を同時に行うため、パディングオラクル攻撃の前提となる「任意の暗号文を復号させる」が原理的にできなくなります。

代表的なAEADアルゴリズム：
・AES-GCM: TLS 1.3やJWTで標準的に使われる。高速でハードウェアアクセラレーション対応
・AES-CCM: IoT・組み込み向けに適したAEADモード
・ChaCha20-Poly1305: AES命令セット非搭載の環境（ARMなど）でも高速

# Python（cryptography ライブラリ）でAES-GCMを使う例
from cryptography.hazmat.primitives.ciphers.aead import AESGCM
import os

# 鍵とnonceは毎回ランダム生成する（使い回し禁止）
key = AESGCM.generate_key(bit_length=256)
aesgcm = AESGCM(key)
nonce = os.urandom(12)  # 96ビット推奨

# 暗号化
ciphertext = aesgcm.encrypt(nonce, plaintext, associated_data)

# 復号（改ざんがあれば InvalidTag 例外が発生する）
plaintext = aesgcm.decrypt(nonce, ciphertext, associated_data)

2. エラーレスポンスを均一化する

CBCモードを即座に変更できない場合の緩和策として、エラーメッセージを均一化します。

・パディングエラーであっても、復号後の処理エラーであっても、クライアントには同一のエラー文を返す
・HTTPステータスコードも同じにする（200/500の差で判別されないようにする）
・エラー発生時の処理にランダムなスリープを挟み、タイミング差を消す

これはあくまで緩和であり、根本解決にはなりません。AEAD移行と並行して実施します。

3. ライブラリと実装の見直し

暗号化処理は自前実装せず、実績あるライブラリに任せることが基本です。

・Python: ライブラリの AESGCM または Fernet（AES-CBC+HMAC）
・Java: で AES/GCM/NoPadding を指定
・Node.js: を使用
・古い の直接指定は避ける

暗号化の失敗（OWASP Top 10 A02）の脆弱性全般については、姉妹記事「暗号化の失敗（Cryptographic Failures）とは？OWASP Top 10第2位の脆弱性と対策をわかりやすく解説」もあわせて参照してください。

中小企業でも今日からできること

「自社でAEADを実装する体力がない」という現場も多いでしょう。以下は即日対処可能なチェックリストです。

・Cookieのセッショントークンを点検する: Base64デコードしてブロック長（16バイト）の倍数になっていたら、CBCモードの可能性がある。JWT（アルゴリズムRS256/ES256）やHMACベースのトークンに切り替えると安全
・ミドルウェアのアップデート状況を確認する: 古いASP.NET Framework・Ruby on Rails・Javaフレームワークはパディングオラクル脆弱性の修正が積み重なっているため、最新版に保つ
・WAF（Webアプリケーションファイアウォール）で異常リクエストを検知する: 同一エンドポイントへの短時間での大量リクエストはパディングオラクル攻撃のシグネチャに合致する。レート制限が有効
・TLS 1.3への移行を優先する: TLS 1.3はCBCモードを廃止し、AES-GCMのみをサポートするため、通信経路上のパディングオラクル攻撃リスクを排除できる。TLS 1.3移行の実践設定は「TLS 1.3移行完全ガイド」を参照

LinuxサーバーでOpenSSLのバージョンやTLS設定を確認したい場合は、姉妹サイトLinuxMaster.JPでコマンドラインでの暗号設定確認手順を解説しています。

よくある誤解と注意点

【誤解1】「HTTPS通信中だから攻撃されない」

TLS（HTTPS）で通信を保護していても、アプリケーション層の暗号化ロジックは別物です。WebアプリがCookieやパラメータをCBCで独自暗号化している場合、TLSで包まれていても攻撃者がCookieを改ざんしてサーバーの反応を観察できます。

【誤解2】「エラーメッセージを隠せば大丈夫」

エラー文を「エラーが発生しました」に統一しても、レスポンスタイムが違えばタイミングオラクルとして機能します。根本解決はAEADへの移行のみです。

【誤解3】「攻撃は複雑だから実際には来ない」

Padding Oracle Exploiter（padBuster）などのツールが公開されており、攻撃の実行は決して難しくありません。スクリプトを走らせるだけで自動的に平文が復元されます。このような自動化ツールの存在を念頭に置いた設計が必要です。

【注意】AES-GCMのnonce再利用は致命的

AES-GCMに移行した後も、同じ鍵で同じnonce（初期化ベクトル）を2回使うと認証の整合性が崩れ、平文が復元されるリスクがあります。nonceは毎回ランダム生成し、絶対に再利用しないようにしてください。

本記事のまとめ

暗号化の実装は「難しいことをライブラリに任せる」のが安全の基本です。CBCモードは15年以上前から危険性が指摘されており、新規システムでの採用は避けてください。既存システムを棚卸しして、CBCモードが残っていないかを確認することが第一歩です。