セキュリティ
証明書の生成に必要なハードウェアを調達できず、回避策としてコードを書いて対応しようとしていた
元認証局（CA）のeMudhraは、お粗末なほど安全性の低いデジタル証明書を発行した主因は、バグのあるPythonスクリプトだったと主張しています。
同社は、この件に関する説明をBugzillaに投稿しました。投稿したのは「Naveen Kumar ML」というハンドルネームのユーザーで、次のように記しています。「2025年4月30日に実施した1回の鍵生成セレモニーで、eMudhraの『B』系列と『C』系列にあたる下位（発行）CAの鍵ペア16組は、ハードウェアセキュリティモジュール上で正しく生成されました。その後、カスタムのPython鍵処理スクリプトを使い、承認済みのラップ／アンラップの往復処理を行いました」
eMudhraが作成しようとしていたのは、ECDSA P-384の秘密鍵8本で、本来は48バイトの長さになるはずでした。ところがスクリプトには、Kumar氏の言葉を借りれば「インポート用コードにバグ／欠陥があり、アンラップしたオブジェクトからの読み戻し時に秘密値が切り詰められた」といいます。その結果、「認証された公開鍵に対応する秘密スカラー値が想定範囲を下回り、公開情報から復元できる状態になった」としています。
問題の核心は、この切り詰めです。eMudhraは48バイトのうち47バイトを無視していたとみられ、その結果、「4」という数字のような、悪名高い1バイトの鍵が生成されました。
バグの性質がどうであれ、Kumar氏は「これは隔離されたセレモニー用ホストでのみ実行したカスタムスクリプトであり、emCAソフトウェアの機能によるものではない」と主張しています。
eMudhraがこのスクリプトを必要としたのは、「世界的なサプライチェーンの制約」により、米国向け証明書一式の作成時に使いたかったハードウェアセキュリティモジュール（HSM）を入手できなかったためです。HSMは暗号鍵を生成・保管する装置です。
そこで同社は、Utimaco社製のHSMで鍵を生成し、生成した鍵をCrypto4A社製の別のHSM群へ移す計画を立てました。
Kumar氏によると、この珍しい手順を採ったのは、証明書の出所に関するポリシーが変わり、5月末までに新しい証明書を生成する必要があったためです。
しかし、同社はスクリプトのエラーに気付かず、生成した鍵のテストも行わなかったため、計画は失敗に終わりました。
その後の経緯は周知のとおりです。Mozillaのチームメンバーが、同社の鍵が極めて脆弱であることに気付き、攻撃者が不正な証明書を発行してサーバーになりすましたり、通信を盗み見たり、転送中のデータを改ざんしたりできると指摘しました。ブラウザーメーカーは直ちにソフトウェアを修正し、eMudhraの証明書を認識しないようにしました。
このインドの企業は、その後SSL/TLS証明書事業から撤退しました。同社によると、この事業は主要な収益源だったことはなく、突如として深刻な恥辱の種になってしまったといいます。
Kumar氏の新たな投稿では、eMudhraが認証事業を畳むために講じる3つの措置が挙げられています。その1つが、「独立した調査で得られた知見を踏まえた改善を実施し、PKI運用全般を強化する」ことです。
もっともな計画のようです。®
