10月20日、Mozillaは、インドの認証局eMudhraが発行した中間証明書8件の秘密鍵が誰にでも復元できる状態だったとして、主要なブラウザが一斉に遮断したことを公表しました。鍵の値が256未満の小さな整数だったためで、研究者は手元のパソコンで1秒かからずに全部の鍵を取り出したと報告しています。
この事例は、電子署名の信頼が、数学の強さだけでなく鍵の扱いで決まることを示しています。仕組みを順に説明し、この事例で何が崩れたのか、PQC（耐量子暗号）移行で何が変わるのかを整理します。
電子署名が証明する2つのこと
電子署名が証明するのは、「その署名者が作った」という本人性と、「作られた後に変わっていない」という完全性の2つです。
手書きの署名と違い、電子署名は文書ごとに異なる値になります。同じ人が署名しても、文書が1文字違えば署名の値は変わります。署名を別の文書に貼り付けても検証は通りません。検証は計算で行うため、誰がやっても同じ結果になります。
契約書の電子化、ソフトウェアの配布元の確認、Webサイトの証明書、メールの送信元の確認。これらはすべて電子署名の応用です。
仕組み：ハッシュと鍵のペア
手順は3段階です。
- 文書を要約する。まず、文書全体をハッシュ関数で一定の長さの値に変換します。文書が少しでも変わればこの値は大きく変わり、同じ値になる別の文書を作ることは事実上できません
- 秘密鍵で署名を作る。署名者だけが持つ秘密鍵で、この要約値から署名を計算します。秘密鍵を持たない人は同じ署名を作れません
- 公開鍵で検証する。受け取った側は、署名者の公開鍵を使って、署名が確かにその文書の要約値に対応しているかを確かめます
公開鍵暗号の記事で説明した鍵のペアを、暗号化とは逆向きに使っています。暗号化は「公開鍵で閉じて秘密鍵で開ける」、署名は「秘密鍵で作って公開鍵で確かめる」です。方式には、RSA署名、楕円曲線を使うECDSAやEd25519があります。
その公開鍵は本当に本人のものか
検証に使う公開鍵が、本当に名乗っている相手のものかを確かめる仕組みが要ります。ここで登場するのが証明書と認証局です。
証明書は、「この公開鍵はこの組織のもの」という対応に、認証局が自分の秘密鍵で署名したものです。認証局の証明書にはさらに上位の認証局が署名し、頂点のルート証明書はブラウザやOSがあらかじめ信頼しています。ブラウザは、サイトの証明書から上へ署名をたどり、信頼しているルートに行き着けば本物と判断します。この連鎖の仕組みはTLSとPKIの記事で詳しく書いています。
連鎖のどこか1か所の秘密鍵が他人の手に渡れば、その下にある証明書はすべて偽造できます。今回の事例は、まさにこの場所で起きました。
信頼はどこで崩れたのか：eMudhraの事例
秘密鍵は本来、途方もなく広い範囲から無作為に選ばれた数です。ところがeMudhraの中間証明書8件では、2025年4月の鍵生成作業で使ったスクリプトの不備により、極めて弱い鍵のペアが誤って作られ、名前が似ていたために本番に使われたと同社は説明しています。Mozillaの調査では、8件の秘密鍵はすべて256未満の整数で、最後の1バイト以外は実質的にゼロでした。
公開鍵は証明書に載っていますから、候補を1から255まで順に試して公開鍵と一致するものを探せば、秘密鍵は一瞬で分かります。研究者が10月17日に各社へ報告した後、複数の人が独自に鍵を復元しました。この状態は1年半近く続いていました。
対応は速いものでした。Chromeは報告当日の17日に8件の遮断を始め、Firefoxは報告から3時間足らずで失効リストを配信、eMudhraは18日に8件を失効させ、Appleは19日、Microsoftは20日に遮断しました。Mozillaは上位のルート証明書の信頼を取り消し、eMudhraは同じルートの下にある約3万件の証明書を別のルートへ移す方針です。この中間証明書から発行された証明書は1件もなく、実際の悪用も確認されていないとされています。
ここから分かることが2つあります。崩れたのは暗号の方式ではなく、鍵を作るという運用でした。そして、数日で遮断と入れ替えができたのは、失効を配信し、信頼するルートを入れ替える体制があったからです。一方で、ブラウザ以外のソフトウェア（コマンドラインのツール、プログラミング言語の標準ライブラリ、パッケージ管理ツールなど）は失効情報を見ないものが多く、個別の更新が要ります。
PQC移行で署名に起きること
HNDLの記事で書いたとおり、署名は「今盗んで後で解読する」攻撃の対象ではありません。ただし、将来の量子コンピュータで秘密鍵が導き出せるようになれば、署名を偽造できるようになります。契約書、ソフトウェアの配布、証明書のように、長い期間にわたって検証される署名は、移行の対象です。
後継として標準化されたのがML-DSAとSLH-DSAです（NISTのPQC標準化の記事）。署名のサイズは現在の方式より大きくなり、証明書の連鎖全体が重くなります。
今回のeMudhraの事例で動いた「失効を配信し、ルートを入れ替える」体制は、PQC移行でそのまま必要になるものです。方式を入れ替えられる状態を保つ考え方は暗号アジリティの記事で書きました。信頼の連鎖は、入れ替えられるように設計されていて初めて機能します。
実務者の持ち帰り
- 自社のWebサイトの証明書について、発行元と上位の連鎖を確認する。eMudhraのルートの下にある証明書は、発行元の案内に従って差し替える
- ブラウザ以外で証明書を検証している自社のソフトウェア（連携のスクリプト、バッチ処理、組み込み機器）が、失効情報やルートの更新をどの経路で受け取るかを把握する
- 長期にわたって検証される署名（契約書、配布するソフトウェア、自社で運用する証明書）を一覧にする。PQC移行で署名の方式を切り替える優先候補になる
