■ 1. eMudhra インシデントの深刻さ
- PHP2Shell との比較:
- PHP2Shell は総理大臣も対応を発信し、一般ニュースでも大きく報じられた
- 同時期の eMudhra のインシデントの方が比較にならないほど深刻
- Web の信頼を失墜させるほどの事態
■ 2. CA とトラストアンカーの仕組み
- eMudhra とは:
- "Mudhra" は「印」を意味し、"e" + "印" でデジタル認証局を表す
- インドの Root CA
- HTTPS のサーバ証明書:
- サーバ内部で秘密鍵を作り、対になる公開鍵をクライアントに提示する
- なりすましでないことを示すため、広く普及した CA に証明書への署名を依頼する
- Let's Encrypt などに発行を依頼する証明書がこれにあたる
- クライアント側の検証:
- デバイス内の証明書リストから対応する CA の証明書を取り出し、署名を検証する
- 検証が成功して初めて、サーバの証明書がなりすまされていないと確認できる
- トラストアンカー:
- リスト内の CA は健全かつ安全に運営され、証明書を適切に発行しているという前提に立つ
- そこを信用の起点とし、数珠つなぎで上位の信頼を構築する基盤
■ 3. CA の誤発行と監視の仕組み
- 誤発行の問題:
- CA が侵害され、サービスの意図しない証明書が発行される事例が近年よく話題になる
- 原因はバグの悪用や内部の操作ミスなど様々
- 正規の google.com の証明書が勝手に発行されれば、Google がどれほど対策しても中間者攻撃を防げない
- CT Log:
- 自社サービスの証明書が知らないところで発行されないよう、CA を監視するための仕組み
- CT Log 登録時に発行される SCT が無い証明書はブラウザが無視する
- 攻撃者も登録をバイパスできず、登録すれば CT Log を監視する Google に発覚して失効される
- 誤発行した CA の末路:
- CA/Browser Forum で信頼できないと判断され、ブラウザやデバイスから Distrust される
- そうして消えていった CA も存在する
■ 4. CA に求められる運用水準
- Root CA の秘密鍵の重み:
- その鍵さえあれば全世界のドメインに対して証明書を発行できる
- 10 年などのスパンで使われるため、厳重に管理される
- OpenSSL で生成して chmod 400 で保存するような Web サービスの鍵運用とは根本から違う
- Hardware Security Module (HSM):
- 内部で鍵ペアを生成し、公開鍵だけを外に出す
- 秘密鍵はハード内にあり、基本的に取り出せない
- 外から署名を依頼すると、内部の鍵で生成した署名が返る
- 物理的な保護:
- データセンター内で物理的にも厳重に管理される
- 盗み出して破壊し鍵をサルベージしようとしても、その瞬間に揮発して消える耐タンパー性を持つ
- キーセレモニー:
- HSM 内で秘密鍵を生成する際に行う、文字通りの「儀式」
- IANA の DNSSEC の Root KSK Ceremony が YouTube で公開されている
- 関係者が集まり、手順を確認しながら全員で進行を見守る
- たかが数 Byte のデータのために 5 時間を超える儀式を行うが、それに値するデータである
- WebTrust 監査:
- 運用が適切に行われているかを第三者がチェックするため、CA は WebTrust の監査を受ける
- Let's Encrypt は監査報告書を公開している
- これらの資料をもとに、CA/Browser Forum などで信用に値する CA かを議論する
- 信頼された CA:
- 信用された CA の証明書がデバイスに入る
- Mac の Keychain や Windows の Certificate Store に収められた CA のリストがそれにあたる
- デバイスを選んだユーザは推移的にその CA を信頼し、その CA の証明書を Valid と検証する
■ 5. eMudhra が起こしたこと
- キーセレモニーの不備:
- eMudhra も広く信頼された Root CA であり、キーセレモニーと監査を経ているはずだった
- スクリプトのバグで本来の鍵とは別に非常に弱い鍵が生成された
- 取り違えにより、その弱い鍵が中間 CA の鍵として採用された
- 鍵の弱さ:
- 楕円曲線暗号 P-384 の秘密鍵は本来ランダムな 48 byte であるべきもの
- 実際には上位 47 byte が全部 0 で、実質 1 byte の鍵だった
- 該当する 8 つの鍵は 4, 56, 66, 115, 155, 156, 230, 237
- 復元の容易さ:
- 離散対数問題の困難性と無関係に、256 回ほどの総当たりで逆算できる
- 弱さに気づきさえすれば、本来 HSM に保管されるはずの CA の鍵が手に入る
- 想定される被害:
- この鍵で署名した証明書はデバイスにとって正規の証明書として Valid になる
- 誰でも世界中のドメインの正規の証明書を複製できる
- 端末のテザリングを「Airport Free WiFi」などにして空港に置けば、接続ユーザの通信を全てキャプチャできる
- HTTPS の接続先をすべて改ざんしても警告は出ない
- PHP 利用時などの限定は無く、すべての Web で攻撃が成立するポテンシャルがある
■ 6. 信頼の破綻
- 秘密鍵の重要性:
- Google には「秘密鍵のセキュリティレベルはプルトニウムと同じ」という逸話がある
- その能力と影響を考えれば妥当な扱いである
- ただし Google が失敗しても困るのは Google だけである
- 実質的な鍵漏洩:
- 広く信頼された CA の秘密鍵の漏洩は決してあってはならない
- 今回漏洩自体はしていないが、攻撃者が鍵を手に入れられる状態は CA の秘密鍵漏洩と等価
- Web において絶対に起こってはいけないことが実際に起こった
- トラストアンカーの前提:
- インターネットの信頼はトラストアンカーが信用できるという前提の上に積み上げられている
- その前提を崩すと、何かを信頼することが原理的に不可能になる
- その健全性維持のためにコストをかけ、多くの人間が運用を確認してきたことが PKI の資産そのもの
- 運用と監査への疑問:
- CA なら小規模でもキーセレモニーを行うはずである
- 「スクリプトのバグ」でこのミスが起こるなら、セレモニーが真面目に行われていたか疑わしい
- ずさんな運営体制が監査に引っかからなかったなら、監査の意味が問われる
- 問題の次元:
- 中間証明書であまり使っておらず、すぐ失効したから問題は無いでは済まない
- プログラムのバグを修正版で直すような話とは次元の違う問題
■ 7. ブラウザにおける対応
- CT Log による防御の限界:
- 偽装証明書は CT Log に登録しなければ SCT が無く、ブラウザは信用しない
- 攻撃者が CT Log に登録して SCT を取得すれば、発覚までは使える
- CT Log の監視まで行える業者ばかりではなく、発覚から失効までにもラグがある
- 防ぐには eMudhra 自体をまるごと Distrust する必要がある
- Cross Root の問題:
- 問題の中間 CA は Sectigo の Cross Root である
- 新興 CA は証明書がデバイスに行き渡るまで、既存 CA にも署名を依頼して信頼を得る
- Let's Encrypt も出始めは IdenTrust との Cross Root であり、珍しい仕組みではない
- Allow List の弱点:
- 証明書ストアは基本的に Allow List である
- eMudhra を外しても、Sectigo の中間証明書を偽装証明書に添えれば信頼される経路が残る
- Sectigo まで外すと、その Root 配下の Sectigo の証明書も全て Distrust される
- 明示的な失効:
- 通常の失効は eMudhra が CRL や OCSP で提供するが、今回は中間 CA 自体の問題である
- ブラウザは CRLSet や OneCRL などの失効ファイルをアップデートとは別に同期している
- ここに eMudhra を入れれば、Sectigo を Root から外さずに問題の中間 CA を Distrust できる
■ 8. 個別の証明書ストアの問題
- OS 依存の実装:
- CLI や言語が OS のネットワーク実装と証明書ストアを使っていれば、一緒に更新される
- 自前で HTTPS を実装し、証明書リストを同梱するものも少なくない
- Electron アプリ:
- Chromium は自前の証明書ストアを同梱し、Node も持つ
- Chromium や Node を更新して再ビルドしないとストアが更新されない
- Slack, Discord, VSCode など全てをすぐに更新する必要がある
- 更新の止まった Electron アプリは利用をやめ、Web 版があればそちらを使うべき
- CLI と言語実装:
- curl などの CLI やプログラミング言語の HTTPS 実装にも個別のストアを持つものがある
- 筆頭は Mozilla がメンテしていた cacert.pem で、実態は PEM の並んだ Allow List
- 失効リストや OCSP、CT の確認の仕組みが無いことが多く、Cross Root の問題が残る
- 取りうる選択:
- eMudhra と Sectigo を両方リストから外し、巻き添えの Valid な証明書を捨てる
- 最悪の場合、実装側に問題の中間証明書の Deny をハードコードする必要がある
■ 9. Sectigo と Comodo
- Sectigo の前身:
- Sectigo はもともと大手 CA の Comodo である
- Comodo は 2011 年に侵害され google.com などの証明書を誤発行し、事業売却を経て Sectigo になった
- Google が Public Key Pinning を開始し、後の CT につながる監視体制を模索するきっかけとなった事件の 1 つ
- 既存の Distrust:
- Sectigo は既に Mozilla に Distrust され、cacert.pem から外されていた
- cacert.pem 以外でも、同じ影響範囲を許容できれば 2 つの CA を Allow List から外せばよい
- Cross Root が Let's Encrypt だった場合を考えると、不幸中の幸いにすぎない
■ 10. 暫定策
- 更新対象の広さ:
- サーバだけでなくローカル PC、スマホ、IoT 機器まで全てが対象となる
- HTTPS を話す全実装を洗い出し、個々の証明書リストを更新する必要がある
- MDM でアップデートを配れば終わりとはいかない
- 組織管理の限界:
- 端末を厳格に管理すれば更新漏れはある程度防げる
- 開発者に不自由な環境を強いると人が辞めてしまうため現実的でない
- リテラシーのある開発者には「AI でも何でも使って全部更新しろ」という通達が効くかもしれない
- 非エンジニアの社員も同じリスクを抱えている
- VPN による対症療法:
- 悪用には中間者攻撃が必要で、Free WiFi などで簡単に成立する
- VPN 接続中は通信が暗号化経路を通るため、その区間の単純な中間者攻撃は成立しにくい
- 「全部更新しろ」と並行して「仕事中はしばらく VPN を必ず使え」と号令するのもありかもしれない
- 全部更新には時間がかかることを考えれば、無いよりはマシ
- トンネル環境の有用性:
- VPN の脆弱性を突いた侵入もあり、ゼロトラストで非 VPN へ移行する流れもある
- それでもこういう時はトンネル環境が便利
- 社内で VPN を使っていなくても、自衛のために Cloudflare WARP などを入れるのもありかもしれない
- 一般ユーザの保護:
- OS やアプリの更新すら行き渡らない世の中で、誰がどう守り切れるかは不明
- 更新をきちんと行うユーザにも付け入る隙は残りやすい
- 家族にはしばらくフリー WiFi を使わないよう助言するべきかもしれない
■ 11. eMudhra の撤退表明
- Bugzilla での返答:
- Mozilla の Bugzilla で、Chrome の Root Program 関係者も交えて議論されている
- 実質 CA/Browser Forum の Issue のような場所である
- eMudhra は SNS や投資家、顧客からの詮索により有意義な分析が事実上不可能だと返答した
- CA にとってこの件の調査以上に大事なことは無いはずだが、ビジネス上は SNS や投資家対応が優先らしい
- 撤退アナウンスの内容:
- eMudhra は TLS 証明書事業からの撤退をあっさり発表した
- 発見から 14 時間以内に CA を失効し速やかに公表した、真摯に対処したと主張した
- 影響 CA からエンドエンティティ証明書の発行は無く、インフラ侵害やデータ漏洩も無いと主張した
- Root CA として守るべき最後の一線を守れなかったことへの反省が無い
- 撤退の理由:
- グローバル SSL/TLS 事業は売上の約 1% にすぎないと説明した
- データ主権やコンプライアンス要件の強化で、複雑さとコストが年々増加していると説明した
- 大手が無償で発行していることもあり、投資収益率が大幅に低下したと説明した
- 要するに金にもならない面倒な事業はやっていられないということ
- SNS での反響への言及:
- SNS での反響が事業規模に見合わないほどの批判を招いたと述べた
- 取締役会は撤退が eMudhra と株主にとって正しい決断だと結論づけた
- SSL/TLS 以外のエンタープライズソリューションとトラストサービスに注力すると述べた
- 撤退姿勢への憤り:
- 炎上も割に合わず、大した事業ではないので損切りするという言い草である
- 小規模でも Web のトラストアンカーを担った組織からその言葉が出ること自体が腹立たしい
■ 12. CA の今後
- Root の数と品質:
- Mac の Keychain には約 158 の Root 証明書がある
- その全てが同じ責任感と品質で運用されているとは考えにくい
- 何人で見張っても人間のやることにミスは必ず起こる
- 署名できる範囲を絞るべきという指摘も以前からある
- CA 業界の変化:
- 無料で参入した Let's Encrypt は ACME, PQC, Short-lived などで他の CA を先導してきた
- Let's Encrypt により事業が縮小し、小さいチームで運営する CA もある
- トラストアンカーの重要度が増した今、リターンが見合わずやる気を失う CA も出るかもしれない
- Google や Amazon に続き Cloudflare も参入表明し、生態系はさらに変わる
- 等しく持つ能力:
- 健全な CA も雑に運営される CA も、世界中のドメインを署名できる能力は等しい
- 失敗しても事業を放り投げず、次の信頼につながる責任を果たすべき
- 問題の種類:
- インシデントニュースの多さで麻痺しがちだが、AI のせいや誰にでも起こる話とは種類が違う
- 信頼に足る責任を果たしていると思っていた相手が、それを裏切った話である
■ 13. まとめ
- CA への要望:
- CA 事業者にとって良い時代ではないかもしれない
- それでも CA をやる以上は責任を全うすべき
- 証明書ストアに Root CA 証明書を入れた状態で信頼を投げ出すべきではない
- CA はトラストアンカーであり、その信頼によって Web の安全が担保されている