平成29年度 秋期 情報処理安全確保支援士試験｜秘密鍵が「推測」された日——情報処理安全確保支援士で学ぶSSL/TLS危殆化の実例

この記事で扱うセキュリティ事例

• 試験区分: 情報処理安全確保支援士

• 出典: 平成29年度 秋期 情報処理安全確保支援士試験 午後Ⅰ 問3

• 主なテーマ: SSL/TLSの秘密鍵危殆化、疑似乱数生成器の不備、証明書失効、POODLE攻撃、前方秘匿性（PFS）、EV証明書

この記事は「情報処理安全確保支援士 午後問題 全70問」シリーズの1本です。→ 全70問の一覧・テーマ別索引はこちら

導入: なぜこの事例が重要なのか

Webブラウザに表示される錠前のアイコン。あれが「安全な通信」の証だと、私たちは当たり前のように信じています。しかし、その信頼の土台が崩れたとき何が起きるのか——この事例は、まさにその「当たり前の崩壊」を描いています。

情報処理安全確保支援士試験で出題されたこのセキュリティインシデントは、ECサイトの秘密鍵が第三者に推測されるという、現実のビジネスに置き換えれば信用そのものが吹き飛ぶ事態を扱っています。しかも原因は「暗号の強度が低かった」からではありません。鍵の長さは十分だった。問題は、その鍵を作り出す過程——乱数の質——にありました。

この記事を読むと、なぜ「正しく生成されたはずの鍵」が推測されてしまうのか、鍵が漏れると実際に何が起きるのか、そしてインシデント発生後にどういう順番で何をすべきかが見えてきます。受験対策としてはもちろん、実務でサーバを運用する人にとっても「自分のサーバは大丈夫か」を確かめる判断軸が得られるはずです。

インシデントの概要

舞台は、中堅の衣料品メーカーであるC社。ビジネスの拡大を狙って独自のECサイトを立ち上げた企業です。顧客が商品を選び、クレジットカード情報を入力して決済する——その通信をSSL/TLS（インターネット上の通信内容を暗号化して盗聴やなりすましから守る仕組み）で保護していました。

サーバ証明書はきちんと取得し、暗号化は有効でした。運用開始からしばらくは、とくに問題は報告されていません。証明書を発行するために、C社はあるソフトウェア——仮にZソフトと呼びます——を使って公開鍵と秘密鍵のペアを生成しました。鍵長はRSA 2048bit。2017年時点では十分に強固とされる長さです。技術的にはすべてが「正しく」見えていた。

ところが運用開始から3ヶ月後、予想もしない形でその安心は崩れます。

何が起きたのか

C社のECサイトが順調に稼働していたある日、外部から一本の通報が入りました。「あなたの会社のサーバ証明書に対応する秘密鍵が、インターネット上のあるWebサイトに掲載されている」——。

C社の管理者はすぐに確認に動きます。通報で示された「Qサイト」と呼ばれるWebページにアクセスすると、そこにはたしかに秘密鍵らしきデータが掲示されていました。管理者は自社サーバに保管されている秘密鍵と照合します。結果——一致。本物でした。

秘密鍵が外部に知られた。この状態を「危殆化」（きたいか）と呼びます。暗号鍵の機密性が失われ、もはや暗号としての役割を果たせなくなった状態です。

しかし不思議な点がありました。C社のサーバから直接鍵ファイルが盗まれた形跡はなかったのです。ログを洗っても、不正アクセスの痕跡は見つからない。では、Qサイトの運営者はどうやって鍵を手に入れたのか。

調査の結果、原因はC社が鍵生成に使ったZソフトの内部にありました。Zソフトに組み込まれた疑似乱数生成器（PRNG。乱数のように見える数列を計算で作り出す仕組み）に、致命的な設計上の欠陥があったのです。

暗号鍵の強さは、突き詰めれば「その鍵がどれだけ予測困難か」で決まります。RSA 2048bitという鍵長は、完全にランダムな数から作られていれば、現在の計算能力では到底破れません。しかしZソフトのPRNGは、生成する数列が【予測不可能である】という性質を満たしていなかった。つまり、アルゴリズムの癖を知っている者であれば、出力される鍵のパターンを絞り込むことができたのです。

Qサイトの運営者は、まさにこの欠陥を突きました。Zソフトが生成し得る鍵の候補を計算によって列挙し、C社のサーバ証明書（公開鍵は証明書に含まれるため誰でも閲覧可能）と突き合わせることで、対応する秘密鍵を特定した。鍵を「盗んだ」のではなく「推測した」のです。

2048bitもの長さがある鍵が推測される。直感的には信じがたいかもしれません。しかし、入力の乱数に偏りがあれば、探索空間は劇的に狭まります。家の鍵が10桁のダイヤル錠であっても、1〜3しか使わないと分かっていれば、試す組み合わせは一気に絞り込めるのと同じ理屈です。

ここからが本当に怖い話です。秘密鍵を手にした攻撃者は、単に通信を盗聴できるだけではありません。DNSキャッシュポイズニング（DNS応答を偽装し、正規のドメイン名へのアクセスを攻撃者のサーバに誘導する手法）と組み合わせることで、完璧な「なりすまし」が可能になります。

通常、DNSポイズニングで偽サイトに誘導されたとしても、攻撃者のサーバには正規のサーバ証明書がありません。ブラウザは「この証明書は信頼できません」と警告を表示し、利用者は異変に気づけます。ところが——攻撃者がC社の本物の秘密鍵を持っている場合、偽サイトであっても正規のサーバ証明書を用いた暗号化通信が成立してしまう。ブラウザには正常な錠前アイコンが表示され、URLも正規のドメイン名のまま。利用者が異常を検知する手がかりは、何一つありません。

利用者はいつもどおりIDとパスワードを入力し、商品を選び、クレジットカード番号を入力する——そのすべてが、気づかないまま攻撃者の手に渡る。秘密鍵の危殆化とは、こういう結末を招くのです。