ルート・オブ・トラストを引き抜いた翌朝、それを引き受ける者は誰もいない

意見

2026年6月、GoogleのChrome Root Programは、Entrustが発行する新規のTransport Layer Security(TLS)証明書の信頼を停止すると発表しました。その決定の背景には、長年にわたるコンプライアンス違反と、明確な技術的判断がありました。決定自体は正しいものでした。

しかし、その余波への対応は、誰か別の人間の責任として押し付けられることになりました。

これこそが、私たちが繰り返し間違え続けている部分です。信頼アンカーを取り除くという技術的判断そのものは、私たちも得意としています。Chrome、Mozilla、Microsoft、AppleのルートプログラムはこうしたQ判断を的確に下しています。しかし、その「翌朝」に何が起きるかを調整する仕組みが、私たちには欠けています。信頼の継続性は、ブラウザの設定画面の裏に隠れた、国家レベルの備えの問題なのです。

Web PKIは外から見ると分散型のシステムに見えます。しかし実際はそうではありません。TLS、コード署名、S/MIME、そして経済活動を支えるマシン間認証のすべてを、少数の組み込みルート証明書が支えています。そのうちの一つを引き抜けば、影響が及ぶ範囲は一つのウェブサイトにとどまりません。あらゆるサービスがそのルートに連鎖しているのです。

過去の記録はそれを如実に示しています。2011年のDigiNotarは、500件を超える不正証明書の発行という被害に遭い、この認証局(CA)は事業継続が不可能になりました。Symantecは2017年、長年にわたる不正利用の末に事業を縮小しました。TrustCorは2022年、Entrustは2024年に同様の事態に陥りました。いずれのケースも対応自体は行われましたが、協調的な国家的対応が強制されることはありませんでした。それが不要だったからです。痛みはIT部門の内側にとどまり、顧客が気づく前に証明書は差し替えられました。

ここに落とし穴があります。私たちは4件のきれいな復旧事例を見て、この問題はすでに解決済みだと考えてしまいがちです。しかし、それは誤りです。単に、大規模な形でまだ試されていないだけなのです。

その大規模版を想像してみてください。ある地方銀行が利用する唯一のCAが、信頼を失ったとします。銀行は取引処理もシステム認証もできなくなります。担当チームは対応に奔走しますが、CA側もパンク状態です。数時間のうちに顧客はサービスから締め出され、規制当局は説明を求めてきます。一方、複数のCAから証明書を発行していた競合他社は、何の支障もなく業務を続けます。

そして、過去の出来事を乗り切れた要因そのものが、今や崩れつつあります。二つの力が状況を変えつつあるのです。

暗号技術とAIが状況を一変させる

第一に、あらゆる信頼アンカーの基盤となる暗号技術には、すでにタイムリミットが設定されています。米国立標準技術研究所(NIST)は、耐量子計算機暗号への移行版としてFIPS 203、204、205を標準化しました。これは、あらゆるものに署名しセキュリティを担保するプリミティブを、自分たちではコントロールできないスケジュールに沿って強制的に移行させることを意味します。

第二に、AIは攻撃者が脆弱な鍵を見つけたり、CA職員を狙ったソーシャルエンジニアリングを大規模に展開したり、署名パイプラインの隙を探ったりするコストを引き下げています。これまで稀だった事態が、現実味を帯びてきています。計画的な移行のはずが、突発的な移行に取って代わられる可能性があるのです。

ここに、居心地の悪い現実があります。「翌朝」を引き受ける者が誰もいないのです。Cybersecurity and Infrastructure Security Agency(CISA)はサイバーインシデントの調整役を担いますが、信頼に関する決定そのものの所有者ではありません。CA/Browser Forumは発行ルールを定めますが、国家的な対応を定めるわけではありません。NISTはガイダンスを公表するだけです。Federal PKIは政府自身の証明書を管理するにとどまります。それぞれが一部分を担っているだけで、セクターをまたいだ後始末を担う者は誰もいません。現状では、影響を受けようとしている当事者が、主要なCAが信頼を失うことになる事実を、一般に公表される前に知る信頼できる手段を持っていないのです。

発行者側はすでに動き始めています。2025年7月、CA/Browser Forumはバロット SC-089を可決し、公的に信頼されるすべてのTLS CAに対して、大量失効計画の策定と年次テストの実施を義務付けました。これは正しい発想であり、それを義務化した点も評価できます。しかし、この義務は発行者にのみ課されるものであり、それ以外の私たちには及びません。大量失効の事態を実際に受け止めなければならない企業やセクターには、計画を立て、テストを行い、足並みをそろえる義務が依然として課されていないのです。

信頼の継続性は、電力網のブラックスタートやDNS復旧と同じように扱うべきです。それらの計画は、事態が悪化するはるか以前から、名前を付けられ、訓練されています。公開鍵の信頼も、それと同等の位置づけを与えられるべきです。

実現すべきことは二つあります。まず、国家レベルでの調整役が必要です。新たな機関を新設する必要はなく、信頼失効を決定する側と、その影響を実際に受けるセクターとをつなぐことだけを役割とする存在で十分です。そして、プレイブックは事が起きる前に用意されていなければなりません。緊急のルート削除、中間CAの侵害、コード署名鍵の窃取、アルゴリズムの強制的な廃止、セクター横断的な連鎖的影響――これらはすべて、全員が平静なうちに文書化し、テストしておくことができるはずです。

これらの実現を待つ必要はありません。今四半期のうちに、次の三つの行動を起こしてください。

問題なのは技術的な判断そのものではありません。「翌朝」をどう引き受けるかは、私たち自身の課題です。次にルートが引き抜かれたとき、沈黙こそが、あなたのセクターが混乱に陥っている音になるでしょう。その沈黙を、今のうちに破ってください。