あまり騒がれていませんが、中間CA証明書8枚の秘密鍵が漏洩・破られたというインシデントの方も、重大じゃないですかね。 ブラウザ各社が即日ブロックしたので「もう対処済みでしょ」という空気になっていますが、中身を見るとかなりヤバい話なんですよ。 まず「漏洩」と言っていますが、実態はもっとひどいです。鍵はECDSAで、公開鍵は「秘密鍵d × 基準点G」で作られます。dが巨大な乱数なら、公開鍵から逆算するのは事実上無理です。これがいわゆる楕円曲線離散対数問題で、ECDSAの安全性の根っこです。 ところが今回のdは、4とか56とか115とか、256未満の小さな整数だったんです。1から順番に試せば一瞬で当たります。つまり公開されている証明書さえ見れば、誰でも秘密鍵を計算できてしまう状態でした。 しかもこの鍵が作られたのは2025年4月です。約1年半、世界中の誰でもこの鍵を手にできたことになります。普通の漏洩なら「どこから誰に漏れたか」を追えますが、今回はそれすらできません。すでに誰かが使っていたかもしれない、という前提で考えるしかないんですよね。 で、中間CAの鍵を持っていると何ができるか。ざっくり言えば、どんなドメインの証明書でも「正規品」として自作できます。Googleでも銀行でも何でもです。ルートCAから信頼されている中間CAの署名なので、ブラウザは普通に信じてしまいます。 あとは公衆Wi-FiやDNS汚染、BGPハイジャックあたりで通信経路を押さえれば、鍵マークが付いたままMITM（中間者攻撃）が成立します。ユーザー側からはまず気づけません。 eMudhraは「エンドエンティティ証明書は1枚も発行していない」と説明しています。でもこれ、正直あまり意味がないんですよね。攻撃者はCAに頼まず、手元の秘密鍵で自分で署名すればいいだけなので、CA側に発行記録なんて残りません。CT（Certificate Transparency）ログに載せずに作ることもできます。CTを強制していないクライアントなら、それでも普通に通ってしまいます。 さらに地味に怖いのが、8枚のうち2枚がコード署名用だったことです。マルウェアに「ちゃんとした発行元の署名」を付けられるので、話はWebだけに収まりません。 「でも失効したんでしょ？」という話もありますが、ここも安心できません。 CRLやOCSPによる失効確認は、確認に失敗したらそのまま通すsoft-failの実装がまだまだ多いです。そもそも失効確認をしないものもあります。 ChromeはCRLSet、FirefoxはOneCRLという独自の仕組みで即座に止めたので、ブラウザは比較的大丈夫です。一方で、JavaやPython（certifi）、Goなどが抱えている独自のCAバンドル、古いOS、IoT機器なんかは、トラストストアを更新しない限り無防備のままです。MozillaとGoogleが中間CAだけでなく、署名元のルート（emSign ECC Root CA - G3）ごと信頼ストアから外したのも、たぶんこのあたりを見越してだと思います。 個人的に一番引っかかっているのは原因の方です。キーセレモニーのスクリプトのバグでHSM上に弱い鍵ペアができてしまい、名前が似ていたせいで人為ミスでそっちをCSRに使った、という説明でした。 CAの鍵生成って、監査人立ち会いのもとで厳格にやる、PKIで一番神経を使う手続きのはずなんですよね。そこでこれが起きて、しかも1年半誰も気づかなかった。CAの監査や運用の仕組みそのものへの信頼が問われる話だと思います。 サーバーや開発環境を見ている方は、念のためOSのCAバンドルと各言語のトラストストアを最新にしておくのがおすすめです。 emudhra.we-have-a-problem.co…