概要
- 確認された公的記録:Comodo のインシデント報告書によると、2011 年 3 月 15 日に登録局（RA）アカウントが侵害され、7 つのドメインに対して 9 件の不正な証明書が発行された。また、発見次第全ての証明書が直ちに失効され、失効後の OCSP レスポンダトラフィックの監視では使用試行は検出されなかったと述べている。(Comodo インシデント報告書)
- ブラウザとプラットフォームの対応:Mozilla、Microsoft、他のブラウザおよびプラットフォーム事業者は、この事象を単なる発行者の内部管理問題以上のものと見なした。Mozilla は証明書ブラックリストの更新を配布し、Microsoft はセキュリティアドバイザリ 2524375 と、9 件の証明書を Windows の信頼されていない証明書ストアに追加する更新を公開した。Mozilla のフォローアップでは、侵害された登録局の経路が説明された。(Mozilla アドバイザリ、Microsoft アドバイザリ、Mozilla フォローアップ)
- 責任の境界:公開証拠は、委任された発行における失敗を示しており、Comodo のルート鍵やハードウェアセキュリティモジュールが侵害されたという公的な結論はない。Comodo は、自社の CA インフラと HSM 鍵は侵害されなかったと述べている。この区別は技術的主張を狭めるが、責任の問題を狭めるものではない。委任されたアカウントは依然として、高価値ドメイン向けのブラウザ信頼証明書を生成したのである。
- 評価:攻撃者は侵入と悪用の試みに責任がある。Comodo は委任発行モデル、リセラ認証、インシデント後対応を管理していた。ブラウザと OS ベンダーは緊急時の不信頼対応を管理し、ルートプログラムは継続的な信頼を管理し、依拠当事者のサービスとユーザーは直接観察できない結果を負った。
認証局はルート鍵から遠く離れた場所でも失敗しうる
認証局のインシデントは、しばしば単一の劇的な侵害として想像される。攻撃者がルート秘密鍵を盗み出し、ウェブ全体を偽造し、信頼システム全体が崩壊する、というものだ。Comodo の事例はより平凡でありながら、より教訓に富んでいた。Comodo は、自社の CA インフラストラクチャは侵害されておらず、ハードウェアセキュリティモジュール内の鍵も侵害されていないと述べた。不正な証明書は、登録局（RA）アカウントを通じて発行された。これは証明書発行プラットフォームへの委任された入り口である。(Comodo インシデント報告書)
この違いは重要である。ルート鍵の侵害は、基盤となる暗号のアンカーが引き続き使用可能かどうかを問う。委任発行の侵害は、より難しい運用上の問いを投げかける。パートナーアカウント、リセラのワークフロー、検証スタッフ、自動化システム、緊急失効チャネルに、どれだけの実質的な CA 権限が委ねられているのか。もし委任されたアカウントによって、mail.google.com、www.google.com、login.yahoo.com、login.skype.com、addons.mozilla.org、login.live.com といったドメイン向けの証明書が発行されうるなら、信頼システムは数学的なルートでは破綻していないかもしれないが、管理上の境界で破綻しているのである。
管理上の境界こそ、公衆インターネットが存在する場である。ユーザーは、どの登録局が証明書要求を検証したかを決定しない。ユーザーはロックアイコン、ドメイン名、そしてブラウザがチェーンを受け入れたことだけを見る。ブラウザベンダーとルートプログラムは、単一の企業本社を信頼しているだけではない。彼らは秘密鍵を取り巻く運用システム全体を信頼しているのである。そのシステムには、検証手順、アカウントセキュリティ、リセラ監督、監査証跡、失効サービス能力、インシデント報告、そして障害が再発した場合に信頼を除去または制限する意思が含まれる。
したがって、Comodo の記録は有用なアカウンタビリティ事例である。不正な証明書の数が少なかったからだ。9 件の証明書は、教訓を何千ものエッジケースに埋もれさせることなく、障害モードを示すのに十分である。このインシデントは、ガバナンス上の問題を露呈するために、大規模な傍受キャンペーンが既知となる必要はなかった。委任されたアカウントが、認証局のブラウザルートとしての地位を、インターネット上で最もセンシティブなアイデンティティ宛先のための証明書へと転換し得ることを示したのである。
名前自体が問題を内包している。ログインエンドポイント用の証明書は単なる装飾的な産物ではない。それはブラウザに対して暗号化されたアイデンティティを提示するための資格情報である。攻撃者がそのような証明書をトラフィックリダイレクション、DNS 操作、ローカルネットワーク制御、ルーティング妨害、マルウェア、または国家レベルのネットワークアクセスと組み合わせることができれば、ユーザーにはその接続が意図したサービスではないことを認識する通常の手段がない可能性がある。Microsoft は、これらの証明書がコンテンツのなりすまし、フィッシング攻撃、またはブラウザユーザーに対する中間者攻撃に使用される可能性があると警告した。(Microsoft アドバイザリ 2524375)
正しい所見は境界付けられている。公的記録は、9 件の証明書すべてが成功裏の大規模傍受に使用されたことを示していない。Comodo は、そのうち 1 件のみがインターネット上で実際に観測されたとし、失効後の OCSP レスポンダトラフィックの監視では使用試行は検出されなかったと述べた。それでも Microsoft と Mozilla は、証明書の信頼は設計上予防的なものであるため、この事象を緊急とみなした。主要なログインドメインを偽装できる証明書は、インシデント後の証拠が大量悪用を証明する前から危険なのである。
公開されている時系列は異例なほど具体的である
Comodo のインシデント報告書が、最初の確固たる骨格を与えている。それによると、2011 年 3 月 15 日に、ある登録局が攻撃を受け、その RA のユーザーアカウント 1 件が侵害された。そのアカウントがその後、不正に使用され、7 つのドメインにわたり 9 件の証明書が発行された。Comodo は、発見次第すべての証明書を直ちに失効させたと述べている。同じ報告書は、影響を受けたドメインとシリアル番号を列挙し、実際に観測された証明書と観測されなかった証明書を区別している。(Comodo インシデント報告書)
Mozilla のフォローアップは、そのアカウントレベルの障害をブラウザの信頼と結びつけた。Mozilla は、Comodo の RA パートナーが内部セキュリティ侵害を受け、攻撃者がその RA の Comodo アカウントを使って 9 件の不正な証明書を発行させたと述べた。また、証明書は失効され、Firefox がそれらをブラックリスト化する更新を配布し、Mozilla が Comodo や他の CA と追加措置について協議中であることも指摘した。(Mozilla フォローアップ)
Mozilla Foundation Security Advisory 2011-11 は簡潔ながら重要である。2011 年 3 月 22 日付けで HTTPS 証明書ブラックリストの更新を発表し、Firefox と SeaMonkey に影響する高い重要度とし、不正使用を防ぐために複数の不正な HTTPS 証明書がブラックリストに追加されたと説明している。ブロック作業に関する Bugzilla の記録は、ブラウザ側の対応を示す公開された証跡である。(MFSA 2011-11、Mozilla Bugzilla 642395)
Microsoft のセキュリティアドバイザリ 2524375 は、プラットフォーム層を追加した。Microsoft は、Comodo から 2011 年 3 月 16 日に、第三者の身元を十分に確認しないまま 9 件の証明書が署名されたと通告されたと述べた。Microsoft は影響を受けた対象を列挙し、なりすまし、フィッシング、中間者攻撃のリスクを説明し、Comodo が証明書を失効させ証明書失効リストに掲載したと述べた。それでも Microsoft は、すべてのネットワーク状況で保護を保証できるほど失効チェックが強固ではないため、9 件の証明書をローカルの信頼されていない証明書ストアに追加する更新をリリースした。(Microsoft アドバイザリ 2524375)
この最後の点が重要な接点である。もし失効だけで十分信頼できるなら、OS の更新はそれほど緊急ではない。Microsoft のアドバイザリは問題を明白に説明している。CRL や OCSP エンドポイントに到達できない場合、ブラウザやアプリケーションはユーザーを危険にさらす形で動作し続ける可能性があると。証明書は発行者によって失効されていたが、依拠当事者のソフトウェアは依然として不確実性を取り除くためにローカルな不信頼ロジックを必要とした。これこそが、CA インシデントがブラウザ、OS、エコシステムのインシデントとなる瞬間である。
Comodo 報告書の後半（3 月 26 日）の詳細も明らかになった。Comodo は、3 月 26 日にリセラユーザーアカウントへの侵入を検知して阻止し、3 月 15 日のインシデント後に実装された新たな管理策により、不正な証明書発行のリスクは除去されたと述べた。また、攻撃は同じ実行者によるものと考えられるとした。この更新は単なる補足ではない。最初の侵害後に委任発行に対する再試行があったことを示唆し、インシデント後の管理策を精査の対象とするものである。(Comodo インシデント報告書)
公的なアカウンタビリティ記録としては、この時系列は強力だが不完全である。日付、委任されたアカウントの経路、証明書の数、影響を受けたドメイン、失効の主張、ブラウザと OS の対応、後の阻止された試行の存在を公に示しているが、完全な独立したフォレンジックレポート、正確な初期アクセス手法、リセラの完全な管理環境、監査上の結果、ルートプログラムとの非公開コミュニケーション、ブラウザベンダーが使用した正確な判断基準などは公開されていない。
委任は責任の抜け穴ではない
委任発行において最も魅力的な防御は、同時に最も弱いアカウンタビリティ防御でもある。すなわち、「ルート CA は侵害されていないから、失敗は他の場所にある」というものだ。技術的にはその通りかもしれないが、ガバナンスの観点では不十分である。認証局は、検証や発注機能を委任するかどうか、パートナーをどのように認証するか、どのドメインに追加チェックが必要か、発行の異常をどのように検出するか、どの委任先がブラウザ信頼のある発行への実質的なアクセスを得るか、を選択するのである。
これは、すべての委任モデルが無謀であるという意味ではない。大規模な証明書発行は常に分散に依存してきた。企業、ホスティングプロバイダー、リセラ、マネージドサービスチャネルは、組織が迅速に証明書を取得するのを助けることができる。自動化と委任はコストを削減し、採用を促進する。アカウンタビリティの問題は、委任モデルが、委任されたアカウントが実行できることに見合った管理策を備えているかどうかである。
Comodo の不正証明書は、悪用価値の低い不明瞭なドメイン向けではなかった。それらはウェブメール、検索、ソフトウェア配布、ブラウザ拡張機能、ログインといった用途に関連するドメインだった。有用な委任発行システムは、高価値ドメイン向けの証明書が、小規模ビジネスドメインの定常的な更新とは異なるリスクプロファイルを持つことを認識すべきである。その認識は、より強固なドメイン管理検証、帯域外承認、高リスク名の監視、異常検出、レート制限、パートナーアカウント制限、顧客の事前承認、またはリセラアカウントがグローバルにセンシティブな名前に対して発行を試みた場合の即時エスカレーションとして現れうる。
現代のベースライン要件とルートストアポリシーは、2011 年のエコシステムよりもこれらの問題をより明確に扱っている。CA/Browser Forum のベースライン要件は現在、サーバー証明書の発行、検証、失効、CA 運用に関する公開要件を提供している。Mozilla のルートストアポリシーと執行資料は、Mozilla 製品によって信頼される認証局を含めるかどうか、また懲戒する際の条件を定義している。(CA/Browser Forum Baseline Requirements、Mozilla Root Store Policy、Mozilla CA enforcement policy)
これらの現行文書を、特定の 2011 年の管理策が現在のルールに違反していたという証明として遡及的に読むべきではない。それらが関連するのは、エコシステムがどのように信頼を公開された運用要件へと変換することを学んだかを示しているからである。委任は、CA が結果に対して責任を負い続ける場合にのみ許容される。CA はブラウザ信頼証明書の社会的意味を外部委託することはできない。検証の一部を外部委託することはできるが、ブラウザルートプログラムとユーザーは依然としてその証明書を CA の信頼として経験する。
ここで、悪用連絡先の経済学が物語に加わる。不正な証明書発行は、委任の決定を下していない当事者にコストを課す。ブラウザベンダーは緊急更新を配布しなければならず、OS ベンダーは不信頼ストアを維持しなければならず、サイト運営者はなりすましを監視しなければならず、セキュリティチームはユーザーが傍受されたかどうかを調査しなければならず、エンドユーザーは目に見えない修復に依存しなければならない。発行者とその委任パートナーは調査と評判のコストを負うかもしれないが、緊急作業はエコシステム全体に分散される。
したがって、このインシデントは、誰がスピードに対して支払うのかを問うている。迅速で摩擦の少ない発行は、すべてがうまくいっている時には証明書販売者と顧客に利益をもたらす。委任されたアカウントが機能不全に陥ると、同じスピードが攻撃者の資産となり、他の当事者が結果を遅延させたり元に戻したりするためにコストを支払うことになる。成熟したアカウンタビリティモデルは、より強固なパートナー管理、より高いリスクの発行ゲート、義務的な報告、ルートプログラムが利用可能な証拠を通じて、CA がそのリスクのより多くを内部化することを要求する。
失効は機能したが、問題を終わらせるには不十分だった
Comodo は、発見次第 9 件の証明書すべてを直ちに失効させたと述べている。これは重要な事実である。失効は、証明書が誤って発行された場合の最初の緊急ブレーキである。しかし、このインシデントは、失効が信頼できるユーザー保護と同じではないことを示した。証明書は CA で失効させられ、CRL に掲載され、OCSP によって不良とマークされることができるが、現実世界の失効チェックは不均一であるため、依然としてクライアント側の更新が必要とされるのである。
Microsoft のアドバイザリは、依拠当事者の問題を異例の明快さで説明した。CRL および OCSP チェックは到達可能であれば有用だが、ネットワーク障害やクライアントの動作により隙間が生じうる。そのため Microsoft は、不正な証明書を Windows の信頼されていない証明書ストアに追加する更新を発行した。この決定により、通常の失効検索が保護を提供できない場合でも、プラットフォームはそれらの証明書を信頼されていないものとして扱うことになった。(Microsoft アドバイザリ 2524375)
基礎となる標準規格が、構造を説明するのに役立つ。RFC 5280 はインターネット X.509 公開鍵基盤証明書と CRL プロファイルを定義し、RFC 6960 はクライアントが証明書ステータス情報を取得する方法として OCSP を定義している。これらのツールは発行と失効に関する公開された語彙を生み出すが、すべてのユーザー、ブラウザ、デバイス、ネットワーク、アプリケーションが同じ瞬間に同じ障害動作を強制することを保証するものではない。(RFC 5280、RFC 6960)
その強制力のギャップが、ブラウザのブラックリストが重要だった理由である。Mozilla の更新は、不正使用を防ぐために不正な HTTPS 証明書をブラックリストに追加した。ブラウザのブラックリストは鈍器だが、決定的である。攻撃者がブロック、傍受、または失敗させる可能性のあるネットワーク呼び出しへの依存を取り除く。コストは、ベンダーが更新を配布し、ユーザーが迅速に受け取らなければならないことである。(MFSA 2011-11)
したがって、Comodo のインシデントは層状の緊急モデルを示した。CA が失効させる。ブラウザベンダーがローカルで不信頼する。OS ベンダーがローカルで不信頼する。サイト運営者が監視する。ルートプログラムが CA の管理策を問いただす。ユーザーは目に見えない機構が機能するのを待つ。複数の層が存在することは強みであるが、単一の層では不十分だったことの証拠でもある。
この点は、賞賛と批判の両方を和らげるはずである。失効後の広範な使用が公的記録に示されなかったほど迅速に、Comodo が証明書を検出、開示、失効させたことを評価するのは公正である。同時に、即時失効だけでは不十分だったと言うのも公正である。このインシデントは、依拠当事者の保護を完全にリアルタイムの失効だけに委ねることができなかったため、Mozilla と Microsoft に製品更新を要求した。これは矛盾ではない。誤った証明書が既に流出した場合の証明書インシデント対応の通常の形なのである。
その後の Certificate Transparency の進化は、この教訓に別の枠組みを与える。RFC 6962 は証明書の実験的な公開ログ設計を記述し、RFC 9162 は後に Certificate Transparency バージョン 2 を規定した。Google の Chrome 向け Certificate Transparency ポリシーは、公開ログに記録された証明書は検出と監査が容易であるという考えを反映している。(RFC 6962、RFC 9162、Chrome Certificate Transparency policy)
Certificate Transparency は、2011 年の Comodo インシデントを遡及的に不可能にしたわけではない。それは、隠れた発行をより隠しにくくし、ドメイン所有者、監視者、ブラウザが観測しやすくすることで、後のインシデントに対するアカウンタビリティ環境を変えたのである。Comodo の事例は、その可視性がなぜ重要かを説明するのに役立つ。もし委任されたアカウントが高価値ドメイン向けに発行できるなら、ドメイン所有者とブラウザエコシステムは、非公開の発見だけに頼るべきではない。
ルートストアの信頼は、民間プログラムによって運営される公共財である
Comodo のインシデントは、ルートストアガバナンスの事例でもある。認証局が強力になるのは、ブラウザや OS がそのルート証明書を、またはそのルートに連なる中間証明書を、数十億人が使用するソフトウェアに含めているからである。ユーザーの信頼判断はプリロードされている。そのため、ルートプログラムは、たとえ民間企業によって運営されている場合でも、事実上、公共のセキュリティリソースの管理者となる。
Mozilla のルートプログラム資料は、Mozilla 製品での信頼を求める CA に対する公開された期待事項を述べている。Chromium と Apple も独自のルートプログラム要件とポリシーを公開している。Microsoft もまた、信頼されたルートプログラムを維持している。これらのプログラムは同一ではないが、ブラウザとプラットフォームの信頼は条件付きであるという中心的前提を共有している。(Mozilla Root Store Policy、Chromium Root Program policy、Apple Root Certificate Program、Microsoft Trusted Root Program)
条件付き信頼は、説明するよりも強制する方が難しい。主要な CA を削除または制限すると、ウェブサイト、企業、政府サービス、地域ポータル、組み込みシステム、旧式のデバイスが破壊される可能性がある。管理の不十分な CA をトラストストアに残せば、ユーザーを傍受にさらす可能性がある。したがって、ルートプログラムは困難なアカウンタビリティの負担を負う。すなわち、ユーザーを保護するのに十分強力に CA を懲戒しなければならないが、ウェブが不必要な可用性障害を被らない程度に予測可能でなければならない。
2011 年当時、Mozilla の公開文書はその緊張を示していた。当面の作業は、不正な証明書をブラックリストに登録することだった。より広範な作業は、何が起こったのかを議論し、追加措置が必要かどうかを問い、CA の管理策と対応が継続的信頼を正当化するかどうかを判断することだった。それは一行の判断ではない。侵害された経路、封じ込め、パートナー管理、監視、監査、再発の可能性に関する証拠を必要とする。
Comodo のインシデントは、ウェブ全体で Comodo の信頼が単純に公的に消去されるという結果には至らなかった。その結果自体が示唆に富む。ルートプログラムは、CA が効果的に対応し、障害を封じ込め、管理策を改善し、十分な証拠を提供したと信じるなら、インシデントを許容するかもしれない。しかし、許容を免罪と混同すべきではない。継続的信頼は将来を見据えたリスク判断であり、そのインシデントが無害だったという宣言ではない。
また、公衆は、ルートストアプログラムが CA レポートの受動的な消費者ではなく、対応チェーンの一部であることを学んだ。Mozilla はセキュリティアドバイザリを公開した。Microsoft はセキュリティアドバイザリと更新を公開した。ブラウザベンダーはコードを配布した。ルートプログラムとベンダーは、RA アカウントや Comodo リセラとは無関係のユーザーにもインシデントを理解可能にした。信頼システムの公的な顔は、証明書ベンダーではなく、ブラウザと OS だったのである。
これにより、有用なアカウンタビリティの分担が生まれる。Comodo は発行と失効を管理した。ブラウザとプラットフォームベンダーは緊急時の不信頼とユーザー保護を管理した。ルートプログラムは将来の信頼を管理した。サイト運営者は自ドメインの監視を管理した。どの主体もシステム全体を管理してはいなかったが、いくつかの主体が重要なゲートを管理していた。CA が自社のインフラは侵害されていないと言うとき、それは一つのゲートに答えたかもしれないが、すべてのゲートに答えたわけではない。
Sectigo はブランド名以上のものを継承した
本記事の主題が Sectigo であるのは、現在の事業体が Comodo の認証局事業の後継ブランドだからである。Sectigo の公開資料は、Comodo CA のリブランドと、その証明書ライフサイクルおよびデジタル信託事業について説明している。(Comodo CA is now Sectigo、Sectigo about page)
これは、現在の Sectigo が、2011 年の Comodo 経営陣と同様に、2011 年の運用上の詳細すべてに責任を負うという意味ではない。企業史には正確さが必要である。2011 年のインシデントは Comodo 認証局の記録に属する。Sectigo のアカウンタビリティは、信頼、市場での地位、監査期待、ルートプログラムとの関係、そして過去の CA インシデントからの教訓が現在の管理策に取り込まれていることを示す義務の継承である。
認証局市場において信頼の歴史が重要であるのは、証明書が通常の製品ではないからである。CA は、ブラウザと依拠当事者が受け入れるであろうという主張を販売している。その主張の価値は、蓄積された信頼、すなわち監査、ルートインクルージョン、コンプライアンス、稼働時間、失効サービス、ブランド認知、そして誤発行が真剣に扱われているという繰り返しの証拠から生じる。リブランドは所有権と戦略を明確にできるが、信頼アンカーの公的なインシデント履歴を消去することはできない。
顧客にとって実際的な問題は、2011 年の RA アカウントが 2026 年において直接的な技術的リスクとして依然として関連するかどうかではない。文字通りの意味では、おそらく関連しない。実際的な問題は、現代の CA が委任発行、アカウントセキュリティ、高リスクドメイン、インシデント開示、証明書透明性ログ、失効サービス品質、ルートプログラムとのコミュニケーションに対して強力な管理策を示せるかどうかである。歴史的な委任発行の失敗は、なぜそれらの管理策が重要なのかの証拠である。
ルートプログラムにとって、歴史的な問いはさらに鋭い。大規模な発行フットプリントと多くの委任または自動化チャネルを持つ CA は、迅速に異常を検出し、何か問題が発生した場合に公開インシデント報告を提供できることを証明しなければならない。Common CA Database は、一部には CA とルートプログラムコンプライアンスに関する公開情報を調整するために存在する。(CCADB) インシデント報告と修復証拠が、研究者、顧客、依拠当事者が孤立した声明ではなくパターンを評価できるほど可視化されると、公的アカウンタビリティは改善される。
この継承問題は Sectigo に特有のものではない。CA エコシステムは、誤発行、弱い検証、侵害された中間証明書、監査の失敗、開示をめぐる論争を伴う複数のインシデントを経験してきた。各インシデントは同じ不快な教訓を教える。ブラウザの信頼は粘着性が高く、CA を不信頼するコストは高くなりうる。この粘着性が CA に経済的価値を与えるが、同時に信頼が損なわれた場合の証拠基準も引き上げる。
高価値ドメインが悪用の政治経済学を明らかにする
影響を受けた名前は無作為ではなかった。Comodo と Microsoft の記録は、主要な通信およびアイデンティティの宛先向けの証明書を特定している。Google、Yahoo、Skype、Mozilla アドオン、Microsoft Live、そして「Global Trustee」という名前である。これらの標的は、ユーザーが認証を行ったり、信頼されたコードをダウンロードしたり、機密通信を受信したりする可能性のある場所であるため、意味がある。
技術的リスクは中間者傍受である。経済的・政治的リスクは、誰かが CA システムを悪用して、被害者サービスから正当性を借り受けることができる点にある。被害ドメインの所有者は、自社のサーバーを保護し、HTTPS を強制し、秘密鍵を注意深く管理し、ユーザーにロックアイコンを信頼するよう教育してきたかもしれない。信頼された CA によって発行された不正な証明書は、トラフィックがネットワーク層でリダイレクトまたは傍受された場合、その労力の多くを無効化しうる。
これが、DNS 委任の権限が問題の表面に現れる理由である。DNS と証明書は別個のシステムだが、ユーザーの「自分は今どこにいるのか」という感覚の点で収束する。DNS はユーザーをあるアドレスにルーティングできる。TLS 証明書は、エンドポイントがそのドメインに対して受け入れられるアイデンティティを提示できるかどうかをブラウザに伝える。どちらかのシステムが破壊されれば、ユーザーは危険にさらされる。両方が攻撃者または強制的なネットワーク環境によって影響を受けうる場合、リスクはさらに悪化する。
悪用連絡先の経済学は醜い。ドメイン所有者は、侵害された CA やリセラから何も購入していないかもしれない。それでも、自らの名前に対する不正な証明書に対応しなければならない。ブラウザベンダーは発行を引き起こしていないかもしれない。それでも更新をプッシュしなければならない。ユーザーはすべて正しく行ってきたかもしれない。それでも失効、ブラックリスト、プラットフォーム更新に依存している。低摩擦の発行市場から利益を得る当事者が、発行が失敗した場合の緊急コストを負う当事者とは限らない。
現代の CT 監視は、ドメイン所有者が不正な証明書をより迅速に発見するのに役立つが、可視性は経済学の一部にすぎない。誰かが依然としてログを監視し、アラートをトリアージし、CA に連絡し、失効を要求し、必要に応じて顧客に通知し、トラフィックが傍受された可能性があるかどうかを評価しなければならない。大規模なプラットフォームにとって、その作業は実行可能である。小規模な組織にとっては、それはもう一つの隠れたセキュリティ税である。小規模ドメインが関与する CA インシデントは、その組織にとって、主要ドメインのインシデントがエコシステムに恥をかかせるのと同じくらい存続を脅かす可能性がある。
したがって、Comodo の事例は単に有名なインターネットブランドに関するものではない。有名ブランドが出来事を可視化したのである。同じ委任発行モデルは、はるかに公的監視の少ない、反体制的なニュースサイト、小さな銀行、地方自治体のサービス、医療ポータル、ベンダーのログインページに損害を与ええたであろう。信頼システムは、標的が世界的に有名な場合にどれだけ迅速に連携するかだけでなく、最も可視性の低い依拠当事者をどのように保護するかによって判断されなければならない。
優れたインシデント対応でも未回答の疑問が残った
Comodo の公開対応には有用な事実が含まれていた。日付、RA アカウントの侵害、9 件の証明書、ドメイン名とシリアル番号、即時失効、OCSP 監視の文言、CA インフラと HSM 侵害の否定、後の阻止された試みである。ブラウザとプラットフォームベンダーは公的アドバイザリを追加した。2011 年当時としては、これは多くのインシデントよりも優れた記録である。
それでも、公的記録はアカウンタビリティにとって重要な未回答の疑問を残している。RA アカウントの使用を許した正確な管理上の欠陥は何だったのか？3 月 15 日の前後で、どのような認証と認可が必要だったのか？高リスクドメインチェックは存在したか、存在しなかったのならなぜか？どの監視が不正な発行に気づいたのか？証明書は失効までどれだけ存在していたのか？どの当事者がどの順序で通知されたのか？どの独立した監査証拠が管理策をレビューしたのか？委任されたパートナー関係はどうなったのか？
これらの回答の一部は、ブラウザのルートプログラムや監査人と非公開で共有されたかもしれない。機密詳細を含む場合、非公開の証拠は適切でありうる。しかし、公共の信頼は完全に非公開で構築されるものではない。すべての意味のある修復詳細が機密であるなら、ユーザーと依拠当事者は CA の信頼性を評価できない。秘訣は、攻撃者に操作マニュアルを渡すことなく、管理策の改善を示すのに十分な証拠を公開することである。
3 月 26 日の阻止された試みは、これを特に重要にする。Comodo は、後の試行では新たな管理策が不正な発行を防止したと述べた。これは強力かつ有用な主張である。しかし、公衆はそれらの管理策について簡潔な説明しか受け取らなかった。より堅牢な公開インシデント後記録であれば、機微な詳細なしに管理策のカテゴリー、すなわち、より強固なリセラ認証、発行異常検出、高リスクドメイン承認、パートナー認証情報ローテーション、監査レビュー、追加監視、ルートプログラム報告などを説明していたであろう。
教訓は、Comodo の公開対応が一意に不十分だったということではない。CA インシデントは、通常のソフトウェア脆弱性とは異なる事後分析スタイルを要求するということである。ブラウザに信頼された CA は、共有されたアイデンティティインフラの一部である。それが誤発行した場合、その回復証拠は自社の顧客だけでなく、契約したことのないドメイン所有者、その存在を知らなかったブラウザユーザー、下流の信頼の結果を負うルートプログラムをも満足させなければならない。
このインシデントが信頼をめぐる対話にもたらした変化
Comodo の出来事は、ウェブ PKI が CA の信頼を目に見えない背景配管のように扱うことをますます是としなくなっていた、より広範な時期に位置している。2011 年はまた、より深刻な CA 障害である DigiNotar の侵害をもたらし、広範な不信頼へとつながった。共に、こうした出来事はエコシステムを、より強力な公開インシデント処理、CT、より良いルートプログラム執行、より詳細なベースライン要件へと押し進めた。
Comodo だけがこれらの改革を引き起こしたと言うのはあまりに単純化であろう。また、Comodo を除外するのもあまりに単純化であろう。この出来事は、高価値ドメインを標的とし、緊急のブラウザおよび OS の対応を必要とする、委任された権限を通じた不正発行の明確な例を提供した。それはまさに、隠れた信頼関係を可視化する種類のインシデントである。
今日の標準規格とポリシーの状況は、その変化を反映している。CA/Browser Forum のベースライン要件は、ドメイン検証と失効に、より正式な公開ベースラインを与えている。Mozilla、Chromium、Apple、Microsoft はルートプログラムの期待事項を公開している。CT ログは、発行された証明書に関する公開データソースをドメイン所有者とブラウザに提供する。CCADB はルートプログラムの調整と公開 CA 情報を提供する。これらのメカニズムのどれも完璧ではないが、共に CA がインシデントを単に私的な顧客サービスの問題として扱うのを難しくしている。(CA/Browser Forum Baseline Requirements、CCADB、Chrome Certificate Transparency policy)
残る弱点は、疲弊によるアカウンタビリティである。エコシステムは、ポリシー、監査、バグスレッド、メーリングリストの投稿、インシデント報告、ルートプログラムの課題の洪水を生み出しうる。それらを注意深く読むのは小さなコミュニティだけである。これは透明性のパラドックスを生む。情報は公開されているかもしれないが、実質的なアカウンタビリティは依然として、それを監視する時間を持つ専門家に依存している。CA は開示フォームを順守できるが、より広い公衆は何が問題だったのかを理解できないままである。
Daniel Kade のリスクフレームは、結果変数を誰が管理していたかを問うことで、その書類手続きを切り裂く。Comodo の事例では、答えは神秘的なものではない。Comodo は委任発行、リセラ認証、失効、公開対応を管理していた。ブラウザとプラットフォームベンダーはローカルな不信頼と更新を管理していた。ルートプログラムは継続的インクルージョンを管理していた。ドメイン所有者は監視と顧客コミュニケーションを管理していた。攻撃者は悪意ある行為を管理していた。ユーザーはほとんど何も管理していなかった。
この最後の事実こそが、CA のアカウンタビリティが厳格でなければならない理由である。ユーザーは HTTPS を探し、警告を回避し、ブラウザを信頼するよう言われている。CA システムが上流で故障した場合、ユーザーはリセラアカウント、RA 侵害、OCSP レスポンダ、CRL、ブラックリスト、ルートプログラムの議論を精査することはできない。彼らは制度的な管理策に依存している。制度的な管理策には制度的なアカウンタビリティが伴うべきである。
委任発行に対するより良いアカウンタビリティテスト
次の委任発行インシデントに対する真剣なアカウンタビリティテストは、証明書の数を数える前から始めるべきである。第一に、CA は、どの委任アカウントがどの証明書を、どの認証の下で、どのような高リスク名制限と独立した承認を得て要求できるかを示せなければならない。第二に、CA は、主要プラットフォーム、機微なログイン名、公共セクタードメイン、金融サービス、ソフトウェア配布、医療システム、その他の高価値ターゲットを含む要求に対する異常検出を示せなければならない。
第三に、CA は失効の速度と失効の信頼性を証明できなければならない。これは、証明書が失効されたと言うだけでなく、失効チェックが失敗するかブロックされた場合に、依拠当事者がどのように保護されたかを説明することを意味する。ブラウザとプラットフォームベンダーは依然としてローカルな不信頼更新を必要とするかもしれないが、CA は緊急連絡先と証拠パッケージをそれらのベンダーのために準備しておくべきである。第四に、CA は、何が起こったか、何が起こらなかったか、何が未だ不明か、どの管理策が変更されたかを述べる、境界付けられたインシデント報告を公開できるべきである。
第五に、ルートプログラムは、インシデント後に継続的信頼が適切である理由を説明できなければならない。その説明は非公開の監査記録を公開する必要はないが、レビューされた証拠のカテゴリー、すなわち封じ込め、パートナー管理、検証変更、監査フォローアップ、監視、失効サービスパフォーマンス、インシデント透明性を述べるべきである。第六に、ドメイン所有者は、不正な発行を監視し、アラートが現れた場合に迅速に CA に連絡する実用的な方法を持つべきである。
Comodo のインシデントは、各部分がなぜ重要かを示している。攻撃者は Comodo のルート鍵を必要としなかった。委任されたアカウントで十分だった。失効はブラウザと OS の対応の必要性を取り除かなかった。公開アドバイザリはパートナー管理に関するすべての疑問を取り除かなかった。証明書の数が少なかったからといって、インシデントが小さかったわけではない。標的はアイデンティティクリティカルなドメインであり、影響を受けた信頼はグローバルだったからである。
Sectigo にとって、継承された教訓は明確である。現代の認証局は、大規模に証明書を発行するだけでなく、いかなるパートナー、リセラ、自動化経路、サポートアカウントも、その規模を静かに公衆に逆なでるようには使用できないことを証明することで、信頼を獲得する。歴史的なインシデントは永続的な罪ではない。それらは、設計、監査、監視、説明によって防がなければならない障害モードの永続的な証拠である。
2011 年の記録に対する最も擁護可能な読み方は、パニックでも矮小化でもない。Comodo は不正な証明書を検出して失効させ、自社のルートインフラは侵害されなかったと述べた。Mozilla と Microsoft は依然として保護的な更新を配布しなければならなかった。攻撃者は、委任発行が主要ドメイン向けにブラウザ信頼アイデンティティを作成できることを示した。エコシステムは、失効、ルート信頼、リセラ管理は別個のトピックではないことを学んだ。それらは一つのアカウンタビリティ表面なのである。
これこそが、このインシデントが 15 年後もリスクとアカウンタビリティのシリーズに属する理由である。目に見える成果物は証明書だった。真の資産は、ブラウザがあるドメインと別のドメインを区別できるという公衆の信頼だった。その信頼が侵害された委任アカウントを通じて借用され得るとなると、問題はもはやルート鍵が HSM 内で安全に保たれていたかどうかではない。問題は、委任された信頼に対して実質的な管理権限を持っていたすべての者が、グローバルな依存が要求する規律をもってそれを使用したかどうかである。