Padding Oracle攻撃を詳しく学ぶ

CBC（Cipher Block Chaining）モードでは、各ブロックを復号する際、まずブロック暗号で暗号文ブロックを復号し、その結果と直前の暗号文ブロックのXORを取ります。このXOR操作には重要な性質があります。攻撃者は暗号文ブロックのビットを変更することで、次のブロックで復号される平文の特定のビットに予測可能な影響を与えられます。この性質によって、パディングオラクル攻撃が可能になります。

ブロック暗号では、入力を固定サイズのブロックにする必要があります。PKCS#7パディングは最後のブロックを埋めます。たとえば、3バイトのパディングが必要な場合は、値がそれぞれ0x03の3バイトを追加します。ブロックがすでに完全に埋まっている場合は、16バイトすべてが0x10である完全なパディングブロックを追加します。復号時には、パディングバイトに一貫性があること（Nバイトすべての値がNであること）を検証してから削除します。パディングが無効な場合、復号は失敗させる必要があります。

パディングオラクルとは、復号された暗号文のPKCS#7パディングが有効かどうかを明らかにするシステムです。オラクルには、明示的なエラーメッセージ（「Invalid padding」）、異なるHTTPステータスコード（500と403）、異なるエラーレスポンス本文、さらにはタイミングの違い（有効なパディングの復号はわずかに高速になる）などがあります。攻撃者は鍵を知る必要がなく、「パディングが有効かどうか」という二値の信号だけを必要とします。

攻撃者は特定の暗号文ブロックを標的にします。平文の最後のバイトを復元するには、直前の暗号文ブロックの最後のバイトを反転し、変更した暗号文をオラクルに送信します。オラクルが有効なパディングを報告するまで、256通りの値を順に試します。有効なパディング（0x01）を生成する値が見つかると、中間復号値が判明します。つまり、中間復号値と変更後のバイトのXORが0x01になります。これを元の暗号文バイトとXORすると、平文バイトが明らかになります。

最後のバイトを復元したら、次に最後から2番目のバイトを標的にします。最後のバイトの中間値はすでに判明しているため、それが0x02になるように変更できます。次に最後から2番目のバイトについて256通りの値を試し、0x02 0x02というパディングが有効になるまで繰り返します。この処理を各バイトについて繰り返すことで、256 * 16 = 4,096回のオラクルクエリを平均して1ブロックあたりに実行し、16バイトのブロック全体を復元できます。オラクルが高速であれば、数秒で完了します。

この処理を各暗号文ブロックに対して繰り返します（IV は前のブロックなしでは復元できないため除きます）。128 バイトの暗号文（AES ブロック 8 個）を完全に復号するには、平均で約 32,000 回のオラクルへのクエリが必要です。毎秒数百件のリクエストを処理する Web サーバーに対しては、数分で完了します。攻撃者は暗号化鍵を一度も知ることなく、平文全体を復元できます。

POODLE（Padding Oracle On Downgraded Legacy Encryption）は、SSL 3.0 の CBC パディング検証を悪用しました。SSL 3.0 は PKCS#7 とは異なるパディング方式を使用していましたが、この攻撃ではオラクルの概念が応用されました。攻撃者が SSL 3.0 セッションにコンテンツを注入し、クライアントを SSL 3.0 にダウングレードさせることができると、パディングオラクル攻撃によってセッション Cookie を復元できました。POODLE により SSL 3.0 は廃止されることになりました。

Lucky Thirteen（2013 年）は、TLS の CBC MAC-then-encrypt 方式におけるタイミングサイドチャネルを悪用しました。パディングが有効かどうかによって MAC 検証にかかる時間が数ナノ秒異なり、タイミングオラクルが生じました。BEAST（2011 年）は、TLS 1.0 の CBC モードで予測可能な IV を悪用し、セッション Cookie に対して選択平文攻撃を行いました。どちらの攻撃も、TLS で CBC モードを正しく実装することが根本的に難しいことを示しました。

パディングオラクル攻撃に対する決定的な防御策は、CBC ではなく AEAD（Authenticated Encryption with Associated Data）モードを使用することです。AES-256-GCM や ChaCha20-Poly1305 などの AEAD モードでは、復号やパディングのチェックを行う前に認証を検証します。認証タグが無効な場合は復号が行われないため、パディングに関する情報が漏洩しません。TLS 1.3 は AEAD を必須とし、CBC を完全に廃止しています。

AEAD を利用できない場合は、Encrypt-then-MAC 方式によって暗号文（平文ではありません）に対する MAC を付加します。復号やパディングのチェックを行う前に MAC を検証します。MAC の検証に失敗した場合は、パディングに関する情報を一切明らかにせず、直ちに処理を中止します。タイミングオラクルを防ぐため、この処理は一定時間で行う必要があります。MAC の検証失敗から、パディングが有効だったかどうかが知られることはありません。

パディングオラクルの脆弱性をテストするには、既知のメッセージを暗号化してから、変更を加えた暗号文をアプリケーションに送信し、応答を観察します。有効なパディングと無効なパディングで、エラーメッセージ、ステータスコード、応答時間などの観測可能な違いが生じる場合は、パディングオラクルが存在します。padbuster や PadBuster などの自動化ツールは、暗号文を体系的に変更して応答を分析することで、Web アプリケーションのパディングオラクルを具体的にテストします。

鍵なしで暗号文を復号するために、パディングオラクル攻撃では標的システムから何が必要でしょうか。

パディングオラクル攻撃の要点：CBC 復号の XOR 特性によって平文のバイトを意図的に操作でき、PKCS#7 パディングの検証によって二値のオラクルが得られます。攻撃者はバイト値を順に試し、有効・無効の応答を観察して平文を 1 バイトずつ復元します。実際の攻撃事例には POODLE、Lucky Thirteen、BEAST があり、防御策は AEAD（GCM、ChaCha20-Poly1305）へ切り替えることです。AEAD では復号前に認証を検証します。