【ITニュース解説】The Most Embarrassing Private Key in Web PKI History

eMudhraという証明書発行機関で、ウェブサイトの安全性を保証する仕組みの根幹に関わる重大な問題が発生した。一見すると正常に見えるウェブサイト証明書が、実は極めて脆弱なプライベートキーに基づいて発行されていたという事件である。この問題は、証明書を発行する「中間証明書」のプライベートキーにあり、本来は高度な暗号技術で守られるべき秘密の情報が、驚くほど簡単な方法で攻撃者に推測される可能性があった。

ウェブサイトが安全であることを示すブラウザの鍵マークの裏側には、「信頼の連鎖」と呼ばれる仕組みが存在する。この連鎖の頂点には「ルートCA」と呼ばれる最も信頼される機関があり、その証明書はブラウザやOSに予め組み込まれている。ルートCAは直接すべてのウェブサイトに証明書を発行する代わりに、その権限を「中間CA」に委譲する。中間CAは日々のウェブサイトやソフトウェアの証明書発行を担っており、そのプライベートキーは多くのウェブサイトやプログラムの信頼性を保証する非常に重要な秘密情報である。もしこの中間CAのプライベートキーが攻撃者の手に渡れば、攻撃者は正規のものと見分けのつかない偽の証明書を無制限に発行できてしまうため、その影響は甚大である。この事件は、特定のウェブサイトが危険にさらされたのではなく、多くのウェブサイトや署名されたプログラムを信頼できるものに見せかける能力を持つ機関が危険にさらされたことを意味する。

今回の事件で問題となったのは、楕円曲線暗号という技術を使ったプライベートキーである。この暗号方式では、プライベートキーは非常に大きなランダムな数字であるべきだ。しかし、今回のeMudhraの事件では、キー生成の儀式で生成された八つの中間CAのプライベートキーが、本来384ビット相当の巨大なランダムな数値であるべきところが、256以下の極めて小さい値であったと報告されている。例えば、あるキーは「4」という値であったと広く議論された。これは、金庫の鍵が本来何百桁もあるはずなのに、たった4桁の数字だったというような、セキュリティ上の致命的な欠陥である。

楕円曲線暗号では、公開キー（Q）はプライベートキー（d）と、その暗号曲線で定められた固定の基準点（G）を掛け合わせる（Q = d × G）という関係で計算される。もしdが巨大でランダムな数字であれば、公開キーQからプライベートキーdを逆算することは、現在の計算能力では事実上不可能である。しかし、もしdが「4」のように非常に小さい場合、攻撃者は「1×G」「2×G」「3×G」「4×G」…と順番に計算していき、公開キーQと一致するものを探すだけで、わずか1秒もかからずにプライベートキーdを特定できてしまう。これは暗号アルゴリズムそのものが突然弱くなったわけではなく、キー生成プロセスが、アルゴリズムが本来のセキュリティを発揮できるような条件（十分に大きくランダムなプライベートキー）を満たしていなかったことが原因である。

この問題は、一つの偶発的なミスではなく、複数の失敗が積み重なって発生した「多重事故」であったと公開されている。キー生成の儀式中に、本来の安全なキーペアとは別に、儀式の手順の不具合により、脆弱な楕円曲線キーペアのセットが意図せず生成されてしまった。生成されたキーセットのラベルが似ていたため、担当者が誤って脆弱なキーを選んでしまい、それが中間CA証明書として署名され、公開されてしまった。安全なキーはハードウェアセキュリティモジュール（HSM）内に残っていたものの、公開された証明書には脆弱なキーが紐付けられていた。

さらに問題は深まる。約数週間後、この中間CAが発行する「証明書失効リスト（CRL）」の署名が検証エラーを起こすという警告が発生した。これは「このCRLに署名されたプライベートキーと、中間CAの公開キーが一致しない」という明確な警告であった。このような署名検証の失敗は、CAにとっては重大なインシデントとして扱われるべきだが、この警告は深く調査されず、「署名するキーの設定を変更して検証が通るようにする」という形で一時的に解決されてしまった。これは、警報が鳴った原因を突き止めることなく、単に警報を止めただけに近い行為で、根本的な問題を深く掘り下げる機会を逃したことを意味する。

この問題は複数回の監査を通過していたという事実があるため、監査が無意味だと考える人もいるかもしれないが、それは正しくない。監査は通常、文書化された手順が存在し、それが遵守されているかを確認することに重点を置く。監査人がキー生成の儀式に立ち会ったり、記録を検証したりするものの、生成された個々の暗号キーが暗号学的に安全な品質を持っているかを再計算して検証するわけではない。そのため、手続き上は問題がなくても、キーの品質自体に問題があるケースを見落とす可能性がある。本来であれば、キー生成後に公開キーのフィンガープリントを照合する、意図したキーペアが一つだけ存在するかを確認する、キーの品質を独立したツールでチェックするなど、より詳細な暗号学的検証が必要だった。

問題発覚後、eMudhraは影響を受けた中間証明書を失効させた。これは必要不可欠な措置であったが、失効情報がすべてのクライアントにすぐに届き、適用されるとは限らない。ブラウザは緊急措置として素早く該当証明書をブロックできたものの、古いデバイス、特定のコマンドラインツール、カスタムのモバイルアプリケーション、組み込みデバイス、Java実行環境、独自の信頼ストア、あるいはピン留めされたCAバンドルを持つアプリケーションなど、ブラウザ以外の様々な環境では、失効情報が届きにくく、脆弱な証明書を使い続けてしまうリスクが残る。さらに、この中間証明書はSectigo社の「AAA Certificate Services」によっても「クロス署名」されており、複数の信頼パスが存在したため、影響範囲はさらに複雑だった。クロス署名は古いデバイスとの互換性を保つために行われるが、この事例ではそれがリスクを拡大させる要因となった。

今回の事件は、システムエンジニアを目指す我々にとって多くの重要な教訓を残している。 一つに、セキュリティチェックが発する警告は単なる「うるさいもの」ではなく、重要なセキュリティ問題の兆候であるということだ。システムからの警告やエラーが発生した場合は、安易にそれを無視したり、一時的な設定変更でごまかしたりするのではなく、原因を徹底的に調査し、根本的な問題を解決するべきである。多くの高額な損害を伴うインシデントは、誰かが「うるさい」と分類した警告から始まる。

また、自動化されたプロセスにおける独立した検証の重要性も示している。自動化は作業を効率化するが、もしその自動化スクリプトに誤りがあれば、間違った決定を非常に速く、広範囲にわたって繰り返してしまう可能性がある。特に認証情報、証明書、署名キーなどの機密性の高いものを生成する自動化においては、その出力が本当に正しいかを、自動化スクリプト自身ではなく、独立した別のツールや制御プレーンで検証するべきだ。

さらに、自分のシステムがどのような信頼の依存関係を持っているかを正確に把握することも重要である。どのアプリケーションが独自の信頼ストアを使用しているか、古いJavaのバンドルに依存しているか、あるいは組み込みファームウェアや特別なプロキシ設定を使っているかなどを事前に把握しておくことで、緊急事態が発生した際に迅速に対応できる。

最後に、キーや証明書を定期的に、そして迅速に更新する「ローテーション速度」は、それ自体がセキュリティ上の重要な管理策となる。高速なキーおよび証明書のローテーションは、万が一の信頼性に関するインシデントが発生した際に、その影響期間を数時間、数日、数ヶ月といった形でコントロールする要因となる。

今回の事件は、暗号アルゴリズムそのものが破られたわけではない。最も重要な教訓は、「公開した公開キーが、本当に意図した安全なプライベートキーに属しているのか」という、セキュリティの根幹に関わる最も単純な問いを、キー生成から公開、そしてその後の監視に至る複数の段階で、誰もが十分に確認しなかったことにある。強力な暗号技術も、キーの生成、ラベリング、検証、レビュー、監視、そして初期の警告に対するチームの真摯な対応がなければ、その力を十分に発揮できないことを示す重大な事例である。