【テクニカル・上級編】 RSA暗号におけるパディング方式(PKCS#1 v1.5 vs OAEP)の脆弱性と推奨 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

RSAパディングの墓場：PKCS#1 v1.5が現代のアーキテクトに突きつける「終わらない悪夢」

暗号技術の世界において、RSAはもはや「古典」に近い。しかし、その実装の細部――特にパディング方式の選択――は、今なお多くのシステムを奈落の底へ突き落とすトリガーとなっている。

多くのエンジニアは「RSAを使っていれば安全だ」と錯覚しているが、それは鍵長の話であって、中身の構造の話ではない。今日は、PKCS#1 v1.5という古い亡霊がなぜ現代のインフラを蝕み続けているのか、そしてなぜOAEP（Optimal Asymmetric Encryption Padding）が唯一の現実的な解なのか、その深淵を覗いてみよう。

—

1. なぜPKCS#1 v1.5は「死んでいる」のか

PKCS#1 v1.5の根本的な欠陥は、「オラクル（占い師）」の存在を許容してしまう設計にある。

攻撃者は、暗号化されたメッセージをサーバに送りつけ、その復号結果が「パディングが正しいか否か」というエラー情報だけで判断できる状況を作り出す。これが、有名な「Bleichenbacher攻撃」の核心だ。サーバがパディングエラーを詳細に返す（あるいは処理時間に微細な差が出る）だけで、攻撃者は数万回の試行で平文を完全に復元できてしまう。

現代のネットワークスタックにおいて、パケットの到達時間（Timing Side-Channel）を完全に隠蔽するのは不可能に近い。つまり、PKCS#1 v1.5を採用している時点で、君のシステムは「サイドチャネル攻撃に対して無防備である」と宣言しているに等しい。

2. OAEP：数学的な防御壁の再構築

一方で、OAEPは「Feistelネットワーク」を用いた変換プロセスを介在させることで、暗号文の改ざんを検知可能にする。

OAEPは「暗号化前にランダムなデータを混ぜ込み、かつ完全性チェックを組み込む」というアプローチをとる。これにより、攻撃者が暗号文を少しでも改ざんすれば、復号後のパディングチェックで確実に弾かれる。これは、現代の暗号アーキテクチャが求める「暗号学的完全性（Cryptographic Integrity）」の最低ラインだ。

実装におけるベストプラクティス（Node.jsの例）

古いライブラリを使い続け、脆弱な設定を放置しているテックリードは、今すぐコードの構造を見直すべきだ。以下は、OAEPを利用した安全なRSA暗号化の基本形である。

const crypto = require('crypto');

// 現代的な暗号化の実装例
const encryptData = (publicKey, plainText) => {
  const buffer = Buffer.from(plainText, 'utf8');
  
  return crypto.publicEncrypt({
    key: publicKey,
    // 【重要】PKCS1_v1_5は絶対に指定しない。OAEPを選択する。
    padding: crypto.constants.RSA_PKCS1_OAEP_PADDING,
    // ハッシュアルゴリズムもSHA-256以上を強制する
    oaepHash: 'sha256'
  }, buffer);
};

3. 次の防衛線：耐量子暗号（PQC）への過渡期

「RSAを使っていること自体が古い」という議論もある。確かに、Shorのアルゴリズムが実用化される未来において、現在のRSAは砂上の楼閣だ。

しかし、いきなりすべてを耐量子暗号（Kyberなど）に置き換えるのは、レガシーシステムを抱える現場では現実的ではない。今、君たちがアーキテクトとしてやるべきことは、「ハイブリッド暗号の実装」だ。

1. 既存のRSA-OAEPを堅牢に維持する：少なくともパディングの脆弱性は排除する。
2. 鍵交換にECDH（楕円曲線ディフィー・ヘルマン）を組み合わせる：前方秘匿性（Forward Secrecy）を確保し、万が一の鍵漏洩時の影響を最小化する。
3. ガードレイルの構築：生成AIがプロンプトインジェクション等で暗号設定を動的に書き換えるようなエッジケースを想定し、セキュリティポリシーはハードコードされた不変のモジュールで管理する。

4. 監査担当者への提言：泥臭い検証のすすめ

最高峰のセキュリティを求めるなら、コードレビューだけで満足してはいけない。

サイドチャネル測定：復号処理にかかるミリ秒単位の時間を計測し、パディングエラーの有無による時間差が発生していないか、実際の通信環境でトラフィックをキャプチャせよ。
負のテスト（Negative Testing）の強化：意図的に不正なパディングを施した暗号文をサーバに送り、エラーレスポンスが「汎用的（Generic）」であるかを確認する。特定のパディングエラーを詳細に返す実装は、即座に修正の対象だ。

最後に

セキュリティは「魔法の杖」ではない。PKCS#1 v1.5のような「過去の遺物」を捨て去る勇気と、暗号理論の基礎となる数式を信頼しつつも、実装上のサイドチャネルを疑い続ける「疑心暗鬼の精神」こそが、真のホワイトハッカーの武器になる。

システムは、君たちが許容した脆弱性の分だけ、崩壊に近づく。今夜、君のプロダクトのパディング設定を確認することは、無駄な作業ではない。それが、次の大規模インシデントを防ぐ最後の一手になるかもしれないのだから。