概要

  • DigiNotar の2011年の侵害は、不正な証明書を生み出し、その中には主にイランの Google ユーザーを標的とした中間者攻撃に使用された証明書が含まれており、ブラウザや OS ベンダーに DigiNotar の証明書を削除または信頼しないよう強制した。
  • Mozilla は、DigiNotar が数週間前に不正な証明書を検出・失効させていたにもかかわらず Mozilla に通知しなかったことを公に批判した。その後 Microsoft はすべての DigiNotar 証明書を信頼できないとみなした。ENISA はこの事件を安全な電子通信の基盤への攻撃と評した。
  • オランダの公共部門の依存関係により、この事件はブラウザベンダーによる整理を超えるものとなった。DigiNotar は政府の PKI サービスに関連する証明書を発行しており、信頼の喪失は、緊急の圧力の下で移行を余儀なくされた政府のウェブサイトやサービスに継続性の問題を引き起こした。
  • 記録は、CA の運用管理、通知の遅れ、ルートプログラムガバナンスに関する確信度の高い説明責任の結論を支持する。すべての証明書が悪用された、すべての政府サービスが機能しなくなった、あるいは現在の PKI 慣行が2011年から変わっていないという主張を支持するものではない。

証拠記録とその利用方法

この記事は、Fox-IT、ENISA、Mozilla、Google、Microsoft、VASCO、HKCERT、CCDCOE、学術文献、CA/Browser Forum、ルートプログラム、RFC、Certificate Transparency、NIST、ENISA DNS の情報源を利用して、インシデントの事実、公共信頼ガバナンス、運用継続性の教訓を区別しています。

#公開記録この分析での使用
1Fox-IT 中間報告書、Operation Black Tulip侵害のタイムライン、利害関係者への警告の目的、開示されたフォレンジック詳細の限界に関する主要な調査証拠。
2ENISA、Operation Black Tulip:認証局が権威を失う管理の失敗、ブラウザと政府の対応、公共信頼の教訓に関する欧州の評価。
3Mozilla セキュリティブログ、DigiNotar 削除のフォローアップMozilla のルートプログラムによる措置、通知失敗の分析、完全削除の声明。
4Google オンラインセキュリティブログ、試みられた中間者攻撃に関する最新情報Google の声明:不正な DigiNotar 証明書が主にイランのユーザーを標的とした中間者攻撃の試みに使用された。
5Microsoft MSRC、DigiNotar 侵害に対する Microsoft の対応についてMicrosoft の対応、削除、信頼できない証明書ストアのコンテキスト。
6Microsoft MSRC、セキュリティアドバイザリ2607712を更新Microsoft によるすべての DigiNotar 証明書が信頼できないとする判断。
7Mozilla アドバイザリ MFSA 2011-34アクティブな MITM、誤発行された証明書、完全な侵害範囲の不明を示すブラウザセキュリティアドバイザリの証拠。
8HKCERT、DigiNotar CA セキュリティ侵害による偽造証明書の発行CSIRT 警告のコンテキスト、偽造証明書の例、エンドユーザー向け緩和ガイダンス。
9VASCO、DigiNotar BV の破産申請を発表信頼喪失後の企業破産記録と時期。
10CCDCOE サイバー法ツールキット、DigiNotar(2011年)侵害の法的・戦略的概要、オランダ政府の関与、国際サイバー法の枠組み。
11Journal of Strategic Security、DigiNotar:最初のオランダデジタル災害の解剖国家政府依存の学術的分析と、なぜこの事件がオランダのデジタル災害事例となったか。
12CA/Browser Forum ベースライン要件現代の公共信頼証明書ガバナンスの語彙とライフサイクル要件。
13Mozilla ルートストアポリシー現在のルートプログラムガバナンスと条件付きブラウザ信頼のコンテキスト。
14Microsoft 信頼されたルートプログラム要件プラットフォームルート信頼ガバナンスと信頼できないストアの運用上の重要性。
15RFC 5280証明書チェーン、CA、CRL、依拠当事者の語彙。
16Google Certificate Transparency プロジェクト後のエコシステム対応のコンテキスト:公開ログと監視による静かな誤発行リスクの低減。
17NIST SP 800-57 Part 1 Rev. 5鍵管理ライフサイクルと暗号鍵保護の期待事項。
18ENISA DNS Identity レポートドメイン ID、委任管理、公共信頼の境界の関係。

認証局の侵害は、ユーザーが知る前にユーザーの現実を変える

DigiNotar 事件は、認証局が目に見えない信頼の経路に位置するため深刻だった。ユーザーがよく知るサイトを訪れるとき、通常 CA を選択しない。ブラウザまたは OS はすでに一連のルートを信頼している。CA が管理していないドメインに対して不正な証明書を発行できる場合、攻撃者はその CA を信頼するクライアントに対してそのドメインを偽装できる可能性がある。ユーザーは有効な暗号化接続を見るが、信頼の主張は偽りである。

Google の2011年8月のセキュリティ投稿は、主にイランの Google ユーザーを標的とした、DigiNotar が発行した不正な証明書を使用した SSL 中間者攻撃の試みの報告を説明した。Mozilla のアドバイザリも同様に、Google サーバーへの安全な SSL 接続に対するアクティブな MITM 攻撃を説明し、不正な証明書が DigiNotar によって誤発行されたと述べた。これらは抽象的な PKI リスクではない。CA の管理失敗のユーザーに向き合った結果である。

VASCO の SEC 提出書類を通じて公開された Fox-IT 中間報告書は、その目的を、利害関係者が独自のリスク分析を行うのに十分な情報を提供しつつ、機密性の高い詳細の一部を控えることと位置づけた。それがまさに CA インシデントにおける緊張である。一般市民は信頼が安全かどうかを判断するのに十分な情報を必要とする。調査者は攻撃者を助けるすべての手法を公開できない。CA には信頼を維持するインセンティブがある。ブラウザベンダーはユーザーがさらされているため迅速に行動する必要がある。

したがって、DigiNotar の危害に対する管理は、公衆が危害を知る前に存在していた。CA は発行システム、ネットワークセグメンテーション、ログ記録、失効、インシデント検出、通知、政府関連の中間者の完全性を管理していた。不正な証明書が存在すると、ブラウザベンダーと政府が緊急の不信と移行を管理した。ユーザーは、他の誰かが警告した後にソフトウェアを更新するか、影響を受けるサービスの使用を停止する以外ほとんど制御できなかった。

通知の遅れは広報上の欠陥ではなかった

Mozilla の削除フォローアップは、記録の中で最も明確な説明責任文書の一つである。DigiNotar が数週間前に不正な証明書を検出・失効させていたにもかかわらず Mozilla に通知せず、その中には Mozilla 自身のドメインの証明書も含まれていたと述べている。問題はエチケットではない。ルートプログラムはタイムリーなインシデント通知に依存している。なぜならブラウザベンダーは信頼判断を更新することで大規模にユーザーを保護できる当事者だからである。

CA は、既知の悪意のある証明書を失効させ、侵入を封じ込めたと信じるかもしれない。その信念は、CA が侵害の全容を証明できない場合には十分ではない。Mozilla のアドバイザリは、DigiNotar が他の不正な証明書が発行され活発に使用されているという証拠を報告したが、全容は不明であると述べた。Microsoft は最初に2つの DigiNotar ルートを信頼リストから削除し、その後すべての DigiNotar 証明書を信頼できない証明書ストアに移動するよう対応を更新した。不確実性がエスカレーションを引き起こした。

通知の遅れは危害曲線を変える。遅延の間、依拠当事者は信頼できない可能性のある証明書を信頼し続ける。ブラウザベンダーは不信アップデートを出荷できない。ドメイン所有者は不正な証明書を探すべきことを知らない。政府サービスは CA が無傷であるかのように計画を続ける可能性がある。ユーザーは CA の失敗を検出する有意義な機会なしに MITM 攻撃の標的になる可能性がある。

このため、CA のインシデント開示は通常のベンダー開示よりも迅速かつ完全でなければならない。CA は自社の顧客を保護するだけではない。そのルートを信頼するすべての人のソフトウェアを保護している。通知の遅れは、依拠当事者エコシステム全体を警告されていないリスク集団に変える。

オランダ政府の依存関係が爆発半径を変えた

DigiNotar は商業 CA だけではなかった。公開情報源は、オランダ政府の証明書インフラにおけるその役割を説明している。その役割により、不信は運用上困難になった。ブラウザベンダーが直ちにすべての DigiNotar 信頼を削除すれば、DigiNotar 関連の証明書を使用する政府サービスへのアクセスが困難または不可能になる可能性があった。信頼が一時的に維持されれば、ユーザーは不正な証明書にさらされる可能性があった。それが公共部門の PKI 依存の罠である。

ENISA の Operation Black Tulip 概要は、Google や Skype を含む数百のウェブサイトに対して偽造証明書が作成され、インシデントが公になるとオランダ政府とブラウザベンダーが措置を講じたと述べている。Journal of Strategic Security の分析は、この事件を最初のオランダデジタル災害として扱っている。なぜなら民間 CA の失敗を国家公共サービス依存に結びつけたからである。VASCO の破産発表は企業の結末を示している:DigiNotar は自主破産を申請し、2011年9月に破産宣告された。

継続性の問題は理論上のものではなかった。政府サービスは ID、機密性、信頼のために TLS 証明書に依存している。省庁やシステム間で証明書を交換するには、調整が必要である:新しいプロバイダー、検証、展開、テスト、ユーザーガイダンス、ブラウザ互換性。CA が信頼を失った場合、移行の毎日がリスクを伴う。移行が急がれれば、サービスが壊れる可能性がある。

これにより DigiNotar は公共部門の継続性事例となった。政府は証明書発行を外部委託できるが、信頼崩壊の公共の結果を外部委託することはできない。調達は、CA が強力な運用管理、独立した監査、インシデント通知義務、緊急移行計画、ルートプログラムでの地位を持っているかどうかを問わなければならない。また、信頼が突然撤回された場合にどれだけ迅速に証明書を交換できるかも問わなければならない。

ブラウザベンダーは緊急時の統治者として行動した

公共信頼システムが失敗すると、ブラウザベンダーと OS ベンダーが緊急時の統治者となる。Mozilla は信頼を削除した。Microsoft は DigiNotar 証明書を信頼できない証明書ストアに移動した。Google はユーザーに警告し、ブラウザセキュリティメカニズムを使用して対応した。HKCERT は公開ガイダンスを発行した。これらの措置はユーザーを保護したが、DigiNotar に依存するサービスへのアクセスを壊すか脅かした。

この二重の役割は不快だが不可欠である。ルートプログラムは受動的なリストではない。それはガバナンスシステムである。今日の Mozilla のルートストアポリシーと Microsoft の信頼されたルートプログラム要件は、DigiNotar 事件が示したことを明確にしている:包含は継続的なコンプライアンス、開示、監査、セキュリティ管理に条件づけられている。信頼されたルートは公共セキュリティの特権であり、永久的な財産権ではない。

緊急時の不信は鈍い管理手段である。不正な証明書からユーザーを保護できるが、すべての正当なレガシー証明書を悪意のあるものから区別してすべてのサービス継続性を維持することはできない。そのため、CA の管理とタイムリーな開示が上流で非常に重要である。ブラウザベンダーがグローバルな不信と継続的な露出の間で選択しなければならない場合、CA は下流のアクターが優雅に修復できないレベルで既に失敗している。

この事件はまた、より強力なエコシステムメカニズムを動機付ける助けとなった。Certificate Transparency は現在公開ウェブ PKI の中心的な部分であり、証明書を公開可視にして、ドメイン所有者、ブラウザ、モニターが早期に誤発行を検出できるようにする。CT は CA セキュリティの完全な代替ではないが、不正な証明書が何週間も隠れたままになる可能性を減らす。DigiNotar は、静かな CA の振る舞いが許容されにくくなった歴史の一部である。

運用管理は危害を限定する能力に従う

「危害に対する運用管理」というフレーズは意図的である。DigiNotar は攻撃者を管理していなかった。しかし、CA システムがセグメント化され、パッチ適用され、監視され、ログ記録され、適切な鍵保護で管理されているかどうかは管理していた。異常な発行が検出されエスカレーションされるかどうかを管理していた。不正な証明書が発見されたときにブラウザベンダーに通知されるかどうかを管理していた。調査者が回復できる証拠の量を管理していた。

Fox-IT と ENISA の資料は、基本的なセキュリティ対策の失敗と広範な侵害の懸念を指摘している。正確な技術的詳細は慎重に扱うべきだが、公開記録は、公に信頼された CA として管理慣行が不十分であったことを示すのに十分強い。CA のシステムは通常の企業 IT ではない。ブラウザと OS がグローバルに受け入れる主張を行うための機械である。その層での基本的な管理失敗は公共の危害となる。

CA/B Forum ベースライン要件と NIST の鍵管理ガイダンスは、この義務のための現代の語彙を提供する:ライフサイクル管理、ID 確認、監査、鍵保護、失効、システムセキュリティ。これらの基準は、すべての2026年の管理が2011年に同じように存在していたかのように読むべきではない。それらはエコシステムが形式化することを学んだものを示すので有用である。CA は証明書が発行されることだけでなく、発行権限が静かに乗っ取られないことを証明できなければならない。

運用管理には危害の伝達も含まれる。不正な証明書のセットを限定できない CA は、世界に信頼を継続するよう責任を持って求めることはできない。不正な証明書を知りながら通知を遅らせる CA は、他者が知らずにさらされる期間を管理する。政府機能を果たす CA は、省庁が移行しなければならないタイムテーブルを管理する。それぞれの場合において、証拠の管理は危害の管理である。

失効は不十分だった。なぜなら信頼は既に崩壊していたから

通常の証明書運用では、失効は特定の証明書を信頼すべきでないと言うメカニズムである。DigiNotar 事件は通常の失効を超えていた。発行者自体が侵害され、不正な証明書の完全なセットを証明できない場合、依拠当事者は既知の証明書だけが悪いと安全に想定できない。そのためブラウザベンダーは特定のルートの失効や不信からより広範な不信へと移行した。

この区別は中心である。失効は既知の悪いリーフを扱う。ルート不信は発行者の信頼性を扱う。前者は外科的である。後者は全身的である。DigiNotar の失敗は全身的になった。なぜなら公開記録は CA 環境が信頼でき、すべての不正な証明書が既知で失効されたという確信を支持できなかったからである。

ユーザーはこの区別をほとんど理解しない。彼らはソフトウェアアップデート、警告ページ、またはブロックされたサービスとして経験する。サービス事業者は緊急の証明書交換として経験する。政府は継続性計画として経験する。ブラウザベンダーは不確実性の下でのリスク判断として経験する。CA が範囲を証明できないことは、他のすべての者に高価な対応を強いる。

現代の CT ログ、より厳格な監査、ルートプログラムのインシデントプロセスは、この不確実性を減らすために設計されている。それらはそれを排除しない。発行管理を失った CA は依然として危機を生み出す。運用上の疑問は、ルートレベルの不信を避けるのに十分迅速に範囲を測定できるかどうかである。

公共サービスの購入者は CA の選択をコモディティとして扱うべきではない

TLS 証明書はしばしば安価で自動化され、日常的である。そのため CA の選択を調達の脚注として扱うのは魅力的である。DigiNotar はなぜそれが公共サービスにとって危険かを示している。CA の信頼ステータスは、市民が安全に政府サイトに到達できるかを決定できる。CA のインシデント処理は、ブラウザベンダーが信頼を維持するかを決定できる。CA の監査品質は、侵害が不正な証明書が悪用される前に検出されるかを決定できる。

公共サービスの購入者は証拠を求めるべきである。どのルートプログラムが CA を含むか?どの監査が公開されているか?発行システムはどのようにセグメント化されているか?秘密鍵はどのように保護されているか?異常な発行はどのように検出されるか?インシデントはどのくらい迅速にルートプログラム、規制当局、加入者、影響を受けるドメイン所有者に報告されるか?緊急交換を発行できる代替 CA はいくつあるか?証明書は省庁間でどのようにインベントリ化されているか?完全な移行はどの程度迅速に実行できるか?

また、集中を避けるべきである。単一の CA または管理された証明書プロバイダーは効率的かもしれないが、共通モードの依存関係になる可能性がある。多くの省庁のために一つの CA に依存する政府は、検証記録、自動化、テスト済みの展開手順を含む、他のプロバイダーへの緊急経路を維持すべきである。そうでなければ、一つのサプライヤーの不信が公共サービスの停止になる。

DNS 委任権限は、証明書がドメイン名を公開鍵にバインドするためここで重要である。ドメイン管理、CA 検証、DNS レコード、公共信頼はリンクしている。ドメイン ID プロセスが弱ければ、証明書発行が悪用される可能性がある。証明書が信頼されなければ、ドメイン名は正しく解決されてもブラウザで安全に失敗する。公共の継続性は DNS と PKI の両方の管理に依存する。

記録が証明しないこと

公開記録は、すべての不正な証明書がアクティブな攻撃で使用されたことを証明しない。すべてのオランダ政府サービスが同じ期間または理由で利用できなかったことを証明しない。すべての DigiNotar 従業員が失敗を知っていたか引き起こしたことを証明しない。攻撃者の完全な最終帰属を証明しない。また、現在の CA ガバナンスが2011年と同一であることを証明しない。

これらの限界は説明責任の結論を弱めない。それらはそれを鋭くする。CA インシデントは、不正な証明書、使用法、影響を受ける当事者の完全なセットが不確かであるときにまさに危険である。完全な知識の欠如は信頼を維持する理由ではない。それはルートプログラムが信頼を削除しなければならない理由である。

また、記録はすべての CA サービスの外部委託が安全でないと主張するために使用されるべきではない。公共信頼 PKI はエコシステムである。なぜなら単一のウェブサイトや省庁が単独でグローバルなブラウザ信頼を維持できないからである。教訓は自己発行による孤立ではない。教訓は、公開証拠、緊急移行、通知の明確な責任を伴う規律ある外部委託である。

DigiNotar の破産は関連するが、危害の尺度ではない。企業は信頼を失った後に商業的に失敗する可能性があるが、より広い公共の危害は、ユーザー、政府、ブラウザが不確実性の下で運用しなければならなかった期間である。それが説明責任の表面である。

実用的な説明責任テスト

認証局はインシデントの前にいくつかの質問に答えられるべきである。発行システムが通常の企業侵害から隔離されていることを証明できるか?不正な証明書生成を迅速に検出できるか?完全な証明書インベントリを生成できるか?大規模に失効できるか?ルートプログラムと加入者に即座に通知できるか?攻撃者による削除からログを保護できるか?政府または高リスクの中間者が別途保護されていることを実証できるか?

ルートプログラムは、インシデント報告が迅速、具体的、独立して検証可能であるかどうかを問うべきである。ドメイン所有者と依拠当事者が行動するのに十分な公開情報を要求すべきである。緊急時の不信メカニズムを準備しておくべきである。なぜならユーザー保護は完全な法的記録を待つことができないからである。

政府の購入者は証明書インベントリと緊急交換プレイブックを維持すべきである。どの公共サービスがどの CA に依存しているか、どの代替 CA が交換を発行できるか、どの DNS 検証手順が必要か、どの省庁が危機時に変更をプッシュする権限を持っているかを知っておくべきである。信頼の失敗を説明し、安全でないクリックスルー行動を奨励しないユーザー向けメッセージをテストすべきである。

ドメイン所有者は、CT ログおよび関連サービスを通じて自社ドメインの証明書発行を監視すべきである。ニュースがないことは誤発行がないことを意味すると想定すべきではない。DigiNotar の記録は、不正な証明書が CA の外部および被害ドメイン所有者の通常の運用の外部で発見される方法を示している。

危害管理はインシデントの最初の1時間に属する

CA インシデントの最初の1時間は封じ込めのためだけではない。それは他に誰が封じ込められるかを決定するためである。DigiNotar の遅れはその理由を示している。CA がすべてを理解するまでインシデントを自社の壁の中に留めておけば、自社の選択肢を維持する一方で、ブラウザ、オペレーティングシステム、ドメイン所有者、政府、ユーザーから選択肢を奪う可能性がある。これらの下流のアクターは、依拠当事者を大規模に保護できる唯一の管理手段を持っているかもしれない。

したがって、現代の CA インシデント計画は2つのトラックを含むべきである。フォレンジックトラックは証拠を保存し、攻撃者の動きを特定し、証明書を列挙し、ルートまたは中間者の露出を判断する。エコシステムトラックは、ルートプログラム、加入者、影響を受けるドメイン所有者、ブラウザベンダー、規制当局、公共サービスパートナーに限定された事実を通知する。エコシステムトラックは完全なフォレンジックの終了を待つべきではない。既知のこと、疑われること、失効されたこと、まだ排除できないこと、次の更新がいつ到着するかを述べるべきである。

政府サービスにとって、危害管理は移行権限も必要とする。CA が不信された場合、誰かが省庁間での証明書交換を命令し、新しい証明書を検証し、DNS または ACME の変更を調整し、文書を更新し、市民に通知し、サービスの復旧を測定できなければならない。散在するスプレッドシートとしてのみ存在する公共部門の証明書インベントリは十分ではない。緊急移行はリハーサルされていなければならない。なぜならルート不信は通常の調達と変更のウィンドウを数時間または数日に圧縮するからである。

したがって、DigiNotar の記録は証拠の待ち時間に関する警告である。影響を受ける証明書セットを知るのに時間がかかるほど、ブラウザは信頼と広範な不信の間で選択しなければならない時間が長くなる。政府事業者に通知するのに時間がかかるほど、優雅に移行する時間が少なくなる。ユーザーが更新なしで放置される時間が長くなるほど、無効な保証を信頼し続ける可能性が高くなる。運用上の危害管理は、CA がエコシステムに行動するのに十分な情報を伝えたときに始まる。

政府サービスの問題は不信下での移行だった

DigiNotar 記録における最も難しい運用上の問題は、信頼が失敗したと判断することだけではなかった。その判断の後、正当なサービスを信頼アンカーから遠ざけることであった。政府サービスは通常、公開証明書を即興で変更できない。検証、展開ウィンドウ、テスト、DNS または ACME の手順、サービス所有者の承認、ユーザーガイダンス、古い証明書がもはや依存されていないことを確認する方法が必要である。CA が不信された場合、これらの通常の手順はセキュリティの緊急性によって圧縮される。

その圧縮は2つのリスクを生み出す。遅すぎると、ユーザーを不正な証明書にさらすか、サービスが本物かどうかについての不確実性にさらす。速すぎると、特に脆弱なクライアント、ハードコードされた中間者、ピン留めされた証明書、サプライヤー管理のエンドポイントを持つシステムへの公共アクセスを壊す可能性がある。したがって、説明責任のある政府の購入者は、危機の前にどの省庁がどの CA を使用しているか、どの代替プロバイダーが交換を発行できるか、どの検証記録が準備されているか、どの技術所有者が変更を展開できるかを知っておくべきである。DigiNotar は、証明書インベントリが事務的な資産ではなく、継続性の資産であることを示している。

公衆コミュニケーションの問題も同様に重要である。CA 危機の際に市民が政府サイトで証明書の警告を見た場合、当局は2つの悪いメッセージを避けなければならない。最初の悪いメッセージは警告を無視することである。それは安全でない行動を教える。2つ目は、デジタルサービスを無期限に使用しないことである。それは法的義務、給付、許可、必須の通信を中断させる可能性がある。成熟した対応は、市民に影響を受ける公式ドメイン、交換が期待される時期、安全なチャネル、更新を確認する方法を伝える。

ここで DigiNotar は CA セキュリティの事例だけでなくガバナンスの事例となる。民間 CA の失敗が公共当局に公共サービスのための信頼撤回を管理させた。国家はルートプログラムのセキュリティ判断を市民の継続性に変換しなければならなかった。この変換は、重要なデジタル公共サービスごとに事前に計画されるべきである。

インシデント証拠が遅れる場合、監査だけでは十分ではない

認証局は長い間、監査、ポリシー、コンプライアンスの成果物と関連づけられてきた。これらの成果物は重要だが、DigiNotar は活発な侵害中のそれらの限界を示している。監査はある時点での管理環境を記述できる。インシデントは、何が起こったか、何が発行されたか、何が失効されたか、どのシステムが触られたか、どのログが信頼できるか、誰が通知されたかについての証拠を必要とする。その証拠が遅れたり不完全だったりすると、依拠当事者は次の監査サイクルを待つことができない。

CA のインシデント証拠は、生きた公共安全機能として扱われるべきである。最も重要な事実は内部的なものだけではない:影響を受ける証明書名とシリアル、発行時間、失効時間、疑われる範囲、ルートまたは中間者の露出、保存されたログ、連絡済みの加入者、通知されたルートプログラム、推奨されるクライアントアクション。機密性の高い詳細は秘密にできるが、行動の事実は迅速に動かなければならない。Mozilla の通知遅延批判は強力である。なぜならそれは証拠ルーティングの失敗を特定し、技術的防御の失敗だけではないからである。

現代の公開 PKI は2011年よりもこれに対するメカニズムが多い。Certificate Transparency ログは発行された証明書を公開できる。CCADB とルートプログラムポリシーはインシデント報告を構造化できる。ブラウザベンダーは不信判断を調整できる。CA/B Forum 要件は期待事項を定義できる。しかし、CA がそれらを使用することを躊躇すれば、メカニズムは役に立たない。DigiNotar からのガバナンスの教訓は、信頼は成功した年次事務処理だけでなく、失敗時の行動に依存するということである。

顧客と政府にとって、これはデューデリジェンスがインシデント証拠について明示的に問うべきであることを意味する。CA はどのくらい迅速にルートプログラムに通知するか?ドメイン所有者は疑わしい発行についてどのように警告されるか?ログはどの程度完全か?CA が範囲を証明できない場合はどうなるか?どの公開レポートが利用可能になるか?これらの質問に答えられないサプライヤーは、重要なサービスのための公共信頼を保持する準備ができていない。

DigiNotar は、なぜルート不信が最も悪くない選択肢になり得るかを説明する

ルート不信は破壊的であるため、それを避ける圧力が常にある。ウェブサイトが壊れる可能性がある。政府ポータルが機能しなくなる可能性がある。古いクライアントがアクセスを失う可能性がある。企業は深刻なビジネス上の結果に苦しむ可能性がある。DigiNotar の破産は、不信が商業的に致命的であり得ることを示している。これらのコストは現実であり、無視されるべきではない。

しかし、代替案はより悪い可能性がある。CA がどの証明書が不正に発行されたかを証明できない場合、信頼を継続することは、すべての依拠ユーザーが未知の可能性のあるなりすましのセットにさらされたままであることを意味する。ブラウザベンダーは、不完全な証拠でユーザーを保護する責任を負う。その状況では、不信は閉じた状態で失敗するため、最も悪くない選択肢かもしれない。それは、もはや検証できない信頼関係の継続よりもユーザー保護を優先する。

このため、CA の運用説明責任は通常のベンダー説明責任よりも厳しい。通常の SaaS 停止は、復旧を待つことで軽減されるかもしれない。CA の信頼失敗は、ベンダーが調査を終える前にエコシステムがベンダーを信頼するのを停止することを要求するかもしれない。CA が安全性を証明できないことは、継続的な信頼に対する証拠となる。それは厳しい基準だが、CA の特権に従う:他者のドメインに対してブラウザがグローバルに受け入れる主張を行うことができる。

公共部門の継続性のための教訓は、緊急時の不信が計画に含まれなければならないということである。政府はすべての信頼されたルートが信頼され続けると想定できない。大規模に証明書を交換する方法、不信イベントを伝える方法、ユーザーセキュリティを弱めずにサービスアクセスを維持する方法を知っておくべきである。DigiNotar はその必要性を可視化した。

ユーザー安全のレンズが修復を統治すべきである

CA 侵害は容易に機関間の議論になる可能性がある:CA、その親会社、監査人、ブラウザベンダー、政府、規制当局。ユーザー安全のレンズは議論を地に足のついたものに保つ。ユーザーはなりすましから保護されるために何を必要とするか?市民は正当な公共サービスにアクセスするために何を必要とするか?ドメイン所有者は自社の名前が悪用されたかどうかを知るために何を必要とするか?ブラウザベンダーは安全な更新を出荷するために何を必要とするか?政府は人々に警告を無視するように言わずに移行するために何を必要とするか?

これらの質問が修復を導くとき、責任の地図はより明確になる。DigiNotar は証拠を提供し、安全でない発行を停止しなければならなかった。ブラウザベンダーは証拠が不十分な場合に信頼を削除しなければならなかった。政府事業者は移行し、伝達しなければならなかった。ドメイン所有者は監視し、対応しなければならなかった。ユーザーは更新を受け取るべきだったが、PKI 問題を自分で解決するよう求められるべきではなかった。

このユーザー安全のレンズはまた、過度な主張を制限する。行動を起こす前にすべての不正な証明書が悪用されたという証明を要求しない。エコシステムによって信頼されたルートを信頼したすべての依拠当事者を非難することを要求しない。緊急時の不信が無痛であるふりをすることを要求しない。CA 内部を検査できない人々にとってどの行動が最も危害を限定するかを問う。

DigiNotar の永続的な価値は、隠れた CA ガバナンスを可視的な公共安全に変えることにある。侵害は、ウェブの信頼ファブリックが最も弱い信頼された発行者の強さと最も速い正直な証拠の説明責任しか持たないことを明らかにした。それはすべての公共信頼 CA にとって関連する基準のままである。

継続性計画には信頼ストアの伝播を含める必要がある

DigiNotar はまた、過小評価されがちな伝播問題を露呈する。ブラウザベンダーと OS ベンダーは CA を迅速に不信にすることを決定できるが、保護はソフトウェアアップデートが到着し、管理された企業が承認し、古いデバイスが受信し、アプリケーションが実際に更新されたストアを使用したときにのみユーザーに届く。一部のクライアントは、OS に従わないプライベートバンドルまたはアプライアンスを使用する場合がある。他のクライアントは、証明書検証動作を変更するエンタープライズプロキシの背後にある場合がある。したがって、ルートプログラムの決定は保護の開始であり、保護の終わりではない。

政府サービスにとって、それは継続性計画が移行の両側を追跡しなければならないことを意味する。公共サービスは自社の疑わしい証明書を交換しなければならないが、市民と公務員がなりすましから保護する不信アップデートを受け取ったかどうかも理解しなければならない。コールセンターはブラウザアップデートがなぜ重要かを説明する必要があるかもしれない。システム管理者は管理されたデスクトップ、キオスク、モバイルデバイスが最新のルートストアを持っていることを確認する必要があるかもしれない。セキュリティチームは、いずれかのトラフィックがまだ不信されたチェーンを受け入れているかどうかを監視する必要があるかもしれない。

この伝播問題は、通知の遅れが非常に深刻であるもう一つの理由である。ブラウザベンダーと政府が行動するのに十分な情報を得る前に失われた毎日は、すでに遅い配信チェーンに追加される日となる。CA は発見後すぐに証明書を失効させるかもしれないが、実用的なユーザー保護は依然として下流の更新経路に依存する。DigiNotar の記録は、証拠、不信決定、証明書交換、クライアント更新伝播のすべてが依拠人口に届いたときにのみ運用上の危害が限定されることを示している。

同じ配信チェーンは危機の前にテストされるべきである。公共 TLS に依存する省庁、病院ネットワーク、銀行、裁判所は、管理されたデスクトップが OS ストア、ブラウザストア、プロキシストア、Java バンドル、モバイルデバイス管理プロファイル、またはアプライアンス信頼バンドルを使用しているかどうかを知るべきである。各ストアを誰がどのくらい迅速に更新できるかを知るべきである。また、どの公開サービスがダウンタイムなしで証明書を交換できるかを知るべきである。DigiNotar が重要だったのは、これらの静かなインベントリの質問を緊急の継続性の質問に変えたからである。不信の前にそれらに答えることができる組織は、ユーザーに警告をバイパスするように教えずに保護するチャンスがある。

証拠の基準も同様に具体的であるべきである。公共サービスは証明書が交換されたと言うだけでなく、影響を受けるエンドポイントのリスト、交換時間、ユーザー通知、ベンダー連絡先、まだ古い信頼に依存している可能性のあるクライアント集団を保持すべきである。その記録は、後のレビュー担当者が避けられない移行の痛みを回避可能な遅延から分離するのに役立つ。また、アクセスとセキュリティの間の誤った選択から公衆を保護する。目標は、便利さのために失敗した信頼アンカーを生かし続けることではない。目標は、不信がユーザーを立ち往生させずに保護できるように、正当なサービスを迅速に移行することである。

説明責任の最終的なポイント

DigiNotar の失敗は、CA 信頼の実際的な意味を変えた。それは、認証局の内部管理がグローバルなユーザー安全問題になり得ること、通知の遅れが最初の侵入と同じくらい結果的であり得ること、政府 PKI 依存が公共継続性リスクを生み出すこと、ブラウザベンダーが CA が範囲を証明できない場合に緊急不信を選択しなければならない可能性があることを示した。

説明責任のある基準は、すべての攻撃者に対する完璧さではない。それは証明である。公開 CA は、発行権限が保護されていること、ログとインベントリが悪用を明らかにできること、インシデントが迅速に開示されること、失効と移行が運用上可能であること、ルートプログラムの信頼が継続的に値することを証明しなければならない。できない場合、危害はもはや CA の顧客リストに限定されない。

したがって、DigiNotar は単なる歴史的な戒めの物語ではない。それは公開ウェブ PKI に依存するすべての組織のための管理地図である。信頼は委任されるが、危害はユーザー、省庁、銀行、病院、裁判所、学校、企業によって局所的に経験される。信頼機械を管理する当事者は、その危害を限定する最初の機会を管理する。

追加の証拠境界

DigiNotar が認証局の失敗を運用上の危害管理テストにしたため、追加の証拠境界は、確認された事実、証拠に裏付けられた推論、未知の情報を分離することである。この分離は重要である。なぜなら、diginoitar 認証局の失敗による危害管理を含むイベントは、話すアクターに応じて技術的問題、契約問題、または通信問題として説明される可能性があるからである。したがって、説明責任分析は実用的な管理に戻らなければならない:誰が構成を変更でき、露出を制限し、検出を加速し、通知を承認し、修復が影響を受けるユーザーに届いたことを証明できるか。

このレンズは、根本原因とトリガーイベントの注意深いテストを追加する。トリガーは、なぜイベントが特定の瞬間に可視化されたかを説明する;根本原因は、その瞬間の前に存在した設計、管理、ガバナンス、検証の選択に関する証拠を必要とする。依存、委任、変更ウィンドウ、契約、ログ、インセンティブなどの貢献条件は、企業の声明を完全な真実として扱ったり、可能性を確定した結論に変えたりせずに評価されるべきである。

同じ規律が、検出失敗、対応失敗、復旧失敗に適用される。公開記録は、信号がいつ見られたか、誰が行動する権限を持っていたか、顧客または規制当局に何が伝えられたか、どの追加証拠が結論を強めたり弱めたりするかを示すべきである。これらの要素が部分的である間、責任ある結論は追加の非難ではなく、責任、不確実性、後の監査が検証すべき ID およびアクセス制御のより正確な地図である。