DigiNotar: 認証局破綻が運用上の被害制御の試金石に

概要

• DigiNotar の2011年の侵害により、不正な証明書が作成されました。これには、主にイランにいる Google ユーザーに対する中間者攻撃の試みに使用された証明書が含まれ、ブラウザーおよび OS ベンダーは DigiNotar の証明書を削除または信用しないことを余儀なくされました。
• Mozilla は、DigiNotar が数週間前にいくつかの不正な証明書を検知・失効させていながら Mozilla に通知しなかったことを公に批判しました。Microsoft は後に、全ての DigiNotar 証明書は信頼できないと判断しました。ENISA はこの事件を、安全な電子通信の基盤に対する攻撃と評しました。
• オランダの公共部門の依存により、この事件はブラウザーベンダーのクリーンアップにとどまらないものになりました。DigiNotar は政府の PKI サービスに関連する証明書を発行しており、信頼の喪失は政府のウェブサイトやサービスに継続性の問題をもたらし、緊急の移行を迫られました。
• この記録は、認証局の運用管理、通知の遅延、ルートプログラムのガバナンスに関する高い確度のアカウンタビリティ所見を裏付けています。全ての証明書が悪用された、全ての政府サービスが停止した、あるいは現在の PKI 慣行が2011年から変わっていないという主張を裏付けるものではありません。

証拠記録とその利用方法

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

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

DigiNotar の事件が深刻だったのは、認証局が不可視の信頼の経路上に位置しているからです。よく使うサイトにアクセスするユーザーは、通常は認証局を選びません。ブラウザーや OS は既に一連のルートを信頼しています。もし認証局が管理していないドメインに対して不正な証明書を発行できてしまえば、攻撃者はその認証局を信頼するクライアントに対して当該ドメインをなりすますことができるかもしれません。ユーザーは有効な暗号化接続を見ていますが、その信頼の表明は偽りです。

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

VASCO の SEC 提出書類を通じて公表された Fox-IT の中間報告書は、その目的を、ステークホルダーが自身のリスク分析を行うために十分な情報を提供することでありながら、一部の機微な詳細は伏せていると述べています。これはまさに認証局インシデントにおけるジレンマです。公衆は、信頼が安全であり続けるかどうかを判断するために十分な情報を必要とします。調査者は、攻撃者を助ける技術を全て公開することはできません。認証局は信頼を維持しようとするインセンティブがあります。ブラウザーベンダーは、自らのユーザーが晒されているため、迅速に行動しなければなりません。

したがって、DigiNotar の被害に対する制御は、公衆がその被害を知る以前から存在していました。認証局は、発行システム、ネットワークの分離、ログ記録、失効、インシデント検知、通知、政府関連の中間証明書の完全性を管理していました。不正な証明書がひとたび存在すれば、ブラウザーベンダーと政府は緊急の信頼撤回と移行を管理しました。ユーザーは、警告を受けた後にソフトウェアを更新するか、影響を受けたサービスの利用を中止するか以外に、ほとんど何も管理できませんでした。

通知の遅延は単なる広報上の欠陥ではなかった

Mozilla の削除後フォローアップは、記録上最も明快なアカウンタビリティ文書の一つです。そこには、DigiNotar が Mozilla に通知することなく、6週間前に一部の不正な証明書を検知し失効させており、それらの中には Mozilla 自身のドメイン向けの証明書も含まれていたと記されています。問題はエチケットではありません。ルートプログラムは、タイムリーなインシデント通知に依存しています。なぜなら、ブラウザーベンダーこそが、信頼判断を更新することによって大規模にユーザーを保護できる当事者だからです。

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

通知の遅延は被害の曲線を変えます。遅延の間中、依拠当事者は信頼できないかもしれない証明書を引き続き信頼しています。ブラウザーベンダーは信頼撤回の更新を配布できません。ドメイン所有者は不正な証明書を探すべきことを知りません。政府サービスは、認証局が無傷であるかのように計画を続けるかもしれません。ユーザーは、認証局の障害を検知する意味のある機会もなく、中間者攻撃の標的にされる可能性があります。

これが、認証局に対するインシデント開示が通常のベンダー開示よりも迅速かつ完全でなければならない理由です。認証局は自社の顧客だけを保護しているのではありません。そのルートを信頼する全てのソフトウェアのユーザーを保護しているのです。遅延した通知は、依拠当事者のエコシステム全体を、警告を受けていないリスク集団に変えてしまいます。

オランダ政府の依存が影響範囲を拡大した

DigiNotar は単なる商用認証局ではありませんでした。公的情報源は、オランダ政府の証明書インフラにおける同社の役割を記述しています。その役割ゆえに、信頼撤回は運用上困難なものになりました。もしブラウザーベンダーが即座に全ての DigiNotar 信頼を削除すれば、DigiNotar 関連の証明書を使用する政府サービスはアクセスが困難または不可能になりかねません。もし信頼を一時的に維持すれば、ユーザーは不正な証明書に晒される可能性があります。これが公共部門の PKI 依存の罠です。

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

継続性の問題は理論上のものではありませんでした。政府サービスは、アイデンティティ、機密性、信頼のために TLS 証明書に依存しています。省庁やシステム全体で証明書を置き換えるには、調整が必要です。新しいプロバイダー、検証、展開、テスト、ユーザーガイダンス、ブラウザー互換性。認証局が信頼を失っている場合、移行の一日一日がリスクを伴います。移行が急がれれば、サービスが停止するかもしれません。

このため、DigiNotar は公共部門の継続性ケースとなります。政府は証明書発行を外部委託できますが、信頼崩壊の公的影響だけは外部委託できません。調達では、認証局が強力な運用管理、独立した監査、インシデント通知義務、緊急移行計画、ルートプログラムでの地位を有しているかどうかを問わなければなりません。また、信頼が突然撤回された場合に、どれだけ迅速に証明書を置き換えられるかも問う必要があります。

ブラウザーベンダーは緊急時のガバナーとして機能した

公開信頼システムが機能不全に陥ると、ブラウザーと OS ベンダーは緊急時のガバナーになります。Mozilla は信頼を削除しました。Microsoft は DigiNotar 証明書を「信頼できない証明書ストア」に移動しました。Google はユーザーに警告し、ブラウザーのセキュリティ機構を用いて対応しました。HKCERT は公開ガイダンスを発行しました。これらの措置はユーザーを保護しましたが、同時に DigiNotar に依存するサービスへのアクセスを断ち、あるいは脅かしました。

この二重の役割は居心地の悪いものですが、必要なものです。ルートプログラムは受動的なリストではありません。それはガバナンスシステムです。現在の Mozilla Root Store Policy や Microsoft Trusted Root Program 要件は、DigiNotar の事例が示したことを明文化しています。すなわち、ルート証明書の受け入れは、継続的なコンプライアンス、開示、監査、セキュリティ管理を条件とする、ということです。信頼されるルートは、公衆の安全のための特権であり、恒久的な財産権ではありません。

緊急時の信頼撤回は、鈍的な制御手段です。ユーザーを不正な証明書から保護することはできても、サービス継続性を全て維持する形で、正当なレガシー証明書と悪意ある証明書を区別することはできません。だからこそ、上流での認証局の管理とタイムリーな開示が極めて重要なのです。もしブラウザーベンダーがグローバルな信頼撤回と継続的なエクスポージャーの間で選択を迫られるならば、その時点で認証局は、下流のアクターが優雅に修復できないレベルで既に失敗しているのです。

この事件は、より強力なエコシステムメカニズムへの動機付けにもなりました。現在では公開ウェブ PKI の中心的要素となっている Certificate Transparency は、証明書を公に可視化し、ドメイン所有者、ブラウザー、監視者が不正発行を早期に検知できるようにします。CT は認証局セキュリティの完全な代替手段ではありませんが、不正な証明書が数週間も発見されずにいる可能性を低減します。DigiNotar は、静かな認証局の行動を許容しにくくした歴史の一部です。

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

「被害に対する運用管理」という表現は意図的なものです。DigiNotar は攻撃者を管理していたわけではありません。しかし、認証局のシステムが分離され、パッチが適用され、監視され、ログが記録され、適切な鍵保護の下で管理されていたかどうかは管理できました。異常な発行が検知され、エスカレーションされたかどうかも管理できました。不正な証明書が発見された際にブラウザーベンダーに通知されたかどうかも管理できました。調査者がどれだけの証拠を復旧できたかも管理できました。

Fox-IT と ENISA の資料は、基本的なセキュリティ対策の失敗と広範な侵害の懸念を指摘しています。正確な技術的詳細は慎重に扱う必要がありますが、公開記録は、公的に信頼される認証局としての管理慣行が不十分であったことを裏付けるに足るものです。認証局のシステムは、通常の企業 IT ではありません。それらは、ブラウザーや OS がグローバルに受け入れる表明を行うための機構なのです。その層での基本的な管理の失敗は、公的な被害となります。

CA/B Forum Baseline Requirements や NIST の鍵管理ガイダンスは、この義務に対する現代の語彙を提供します。ライフサイクル管理、アイデンティティ証明、監査、鍵保護、失効、システムセキュリティです。これらの標準は、2026年の全ての管理策が2011年に同一の形で存在していたかのように読むべきではありません。これらが有用なのは、エコシステムが何を形式化するよう学んだかを示すからです。認証局は、証明書が発行されたことだけでなく、発行権限が密かに取得され得ないことを証明できなければなりません。

運用管理には、被害の伝達も含まれます。不正な証明書のセットを特定できない認証局は、責任を持って世界に信頼を継続するよう求めることはできません。不正な証明書を知りながら通知を遅らせる認証局は、他者が無自覚に晒される時間枠を管理しているのです。政府機能を担う認証局は、政府機関が移行しなければならないスケジュールを管理しています。いずれの場合も、証拠に対する管理は被害に対する管理なのです。

信頼が既に崩壊していたため、失効だけでは不十分だった

通常の証明書運用では、失効は特定の証明書をもはや信頼すべきでないと伝えるメカニズムです。DigiNotar の事件は、通常の失効の域を超えていました。発行主体自体が侵害されており、不正な証明書の全セットを証明できない場合、依拠当事者は既知の証明書だけが悪いと安全に仮定することはできません。だからこそ、ブラウザーベンダーは特定のルートの失効や信頼撤回から、より広範な信頼撤回へと舵を切ったのです。

この区別は中核的です。失効は既知の悪いリーフに対処します。ルート信頼撤回は発行者の信頼性欠如に対処します。前者は外科的、後者は全身的です。DigiNotar の失敗が全身的になったのは、公開記録が、認証局の環境が信頼でき、全ての不正な証明書が既知かつ失効済みであるという確信を裏付けられなかったからです。

ユーザーがこの区別を理解することは稀です。彼らはそれをソフトウェアアップデート、警告ページ、あるいはブロックされたサービスとして経験します。サービス事業者はそれを緊急の証明書交換として経験します。政府はそれを継続性計画として経験します。ブラウザーベンダーは、不確実性の下でのリスク判断として経験します。認証局がスコープを証明できないことは、他の全ての者を高コストの対応へと追い込みます。

現代の CT ログ、より厳格な監査、ルートプログラムのインシデントプロセスは、この不確実性を低減するように設計されています。それらは不確実性を排除するわけではありません。発行管理を失った認証局は、依然として危機を引き起こします。運用上の問いは、ルートレベルの信頼撤回を回避できるほど迅速にスコープを計測できるかどうかです。

公共サービスの発注者は、認証局選択をコモディティとして扱うべきではない

TLS 証明書は多くの場合安価で、自動化され、日常的です。そのため、認証局の選択を調達上の脚注のように扱いたくなる誘惑に駆られます。DigiNotar は、それが公共サービスにとっていかに危険かを示しています。認証局の信頼状況が、市民が政府サイトに安全にアクセスできるかどうかを左右する可能性があります。認証局のインシデント対応が、ブラウザーベンダーが信頼を維持するかどうかを左右する可能性があります。認証局の監査品質が、不正な証明書が悪用される前に侵害が検知されるかどうかを左右する可能性があります。

公共サービスの発注者は証拠を求めるべきです。その認証局はどのルートプログラムに含まれているのか？どのような監査が公開されているのか？発行システムはどのように分離されているのか？秘密鍵はどのように保護されているのか？異常な発行はどのように検知されるのか？インシデントはルートプログラム、規制当局、加入者、影響を受けたドメイン所有者にどれだけ迅速に報告されるのか？緊急時に代わりとなる認証局はどれだけあるのか？証明書は省庁全体でどのように台帳管理されているのか？完全な移行をどれだけ迅速に実行できるのか？

また、集中を避けるべきです。単一の認証局やマネージド証明書プロバイダーは効率的かもしれませんが、それは共通モードの依存関係になり得ます。多数の省庁で一つの認証局に依存している政府は、検証記録、自動化、テスト済みの展開手順を含む、他のプロバイダーへの緊急パスを維持しておくべきです。さもなければ、一つの供給者への信頼撤回が公共サービスの停止となります。

ここで DNS の委任権限が問題となります。証明書はドメイン名を公開鍵に結び付けるからです。ドメイン管理、認証局による検証、DNS レコード、公開信頼は連鎖しています。ドメインアイデンティティプロセスが脆弱であれば、証明書発行が悪用され得ます。証明書が信頼されなければ、ドメイン名は正しく解決されても、ブラウザーで安全に失敗します。公共の継続性は、DNS と PKI の両方の管理に依存します。

本記録が証明していないこと

公開記録は、不正な証明書の全てが実際の攻撃に使用されたことを証明していません。全てのオランダ政府サービスが同じ期間あるいは理由で利用不能になったことも証明していません。全ての DigiNotar 従業員がその失敗を知っていたか、あるいは引き起こしたことも証明していません。攻撃者の最終的な帰属確定も証明していません。また、現在の認証局ガバナンスが2011年と同一であることも証明していません。

これらの限界はアカウンタビリティ所見を弱めるものではなく、むしろそれを鮮明にします。認証局インシデントは、まさに悪い証明書、その使用、影響を受けた当事者の全セットが不確実であるときに危険なのです。完全な知識の欠如は、信頼を維持する理由にはなりません。それは、ルートプログラムが信頼を撤回しなければならないかもしれない理由なのです。

また、この記録は、認証局サービスの全ての外部委託が安全でないと主張するために用いられるべきではありません。公開信頼 PKI は、どの単一のウェブサイトや機関も単独でグローバルなブラウザー信頼を維持できないがゆえに、エコシステムなのです。教訓は、自前での孤立ではありません。教訓は、公的証拠、緊急移行、通知に関する明確な責任を伴う、規律ある外部委託です。

DigiNotar の破産は関連しますが、被害の尺度ではありません。企業は信頼喪失後に商業的に破綻し得ますが、より広範な公的被害は、ユーザー、政府、ブラウザーが不確実性の下で行動しなければならなかった期間です。それがアカウンタビリティの表層なのです。

実践的なアカウンタビリティテスト

認証局は、インシデントが発生する前に、いくつかの質問に答えられるべきです。発行システムが通常の企業内の侵害から隔離されていることを証明できるか？不正な証明書生成を迅速に検知できるか？完全な証明書台帳を作成できるか？大規模に失効できるか？ルートプログラムと加入者に直ちに通知できるか？攻撃者による削除からログを保護できるか？政府向けや高リスクの中間証明書が別途保護されていることを示せるか？

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

政府の発注者は、証明書台帳と緊急交換プレイブックを維持すべきです。どの公共サービスがどの認証局に依存しているか、どの代替認証局が交換用証明書を発行できるか、どの DNS 検証手順が必要か、危機の際に変更を実施する権限を持つ省庁はどこかを把握すべきです。また、安全でないクリックスルー行動を助長することなく信頼障害を説明するユーザー向けメッセージをテストすべきです。

ドメイン所有者は、CT ログや関連サービスを通じて、自身のドメインに対する証明書発行を監視すべきです。ニュースがないことは不正発行がないことを意味すると考えてはなりません。DigiNotar の記録は、不正な証明書が認証局の外部や被害ドメイン所有者の通常業務の外で発見され得ることを示しています。

被害制御はインシデント発生の最初の1時間に属する

認証局インシデントの最初の1時間は、封じ込めのためだけのものではありません。他に誰が封じ込めを行える必要があるかを決定するためのものです。DigiNotar の遅延はその理由を示しています。認証局が全てを把握するまでインシデントを自らの壁の内側に留めておくならば、自らの選択肢を維持する一方で、ブラウザー、OS、ドメイン所有者、政府、ユーザーから選択肢を奪うことになりかねません。それらの下流のアクターこそが、大規模に依拠当事者を保護できる唯一の管理手段を握っている可能性があるのです。

したがって、現代の認証局インシデント計画は二つのトラックを含むべきです。フォレンジックトラックは、証拠を保全し、攻撃者の動きを特定し、証明書を列挙し、ルートまたは中間証明書の曝露を判断します。エコシステムトラックは、ルートプログラム、加入者、影響を受けたドメイン所有者、ブラウザーベンダー、規制当局、公共サービスパートナーに、範囲を限定した事実を通知します。エコシステムトラックは、完全なフォレンジックの結論を待つべきではありません。既知の事項、疑われる事項、失効済みの事項、まだ除外できない事項、次回更新の時期を伝えるべきです。

政府サービスにとって、被害制御は移行権限も必要とします。認証局が信頼されなくなった場合、誰かが省庁横断的に証明書交換を命じ、新しい証明書を検証し、DNS や ACME の変更を調整し、文書を更新し、市民に通知し、サービス復旧を計測できなければなりません。散在するスプレッドシートとしてのみ存在する公共部門の証明書台帳では不十分です。緊急移行はリハーサルされていなければなりません。なぜなら、ルート信頼撤回は通常の調達や変更枠を数時間あるいは数日に圧縮するからです。

したがって、DigiNotar の記録は証拠の遅延に関する警告でもあります。影響を受けた証明書セットの把握に時間がかかればかかるほど、ブラウザーは信頼と広範な信頼撤回の間で選択を長く迫られます。政府事業者への通知が遅れれば遅れるほど、彼らが円滑に移行する時間は短くなります。ユーザーがアップデートなしで放置されればされるほど、無効な保証を信頼し続ける可能性が高まります。運用上の被害制御は、認証局がエコシステムに対して行動に足る十分な情報を伝えたときに始まるのです。

政府サービスの問題は、信頼撤回下での移行だった

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

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

公衆へのコミュニケーション問題も同様に重要です。認証局危機の最中に市民が政府サイトで証明書警告を目にした場合、当局は二つの悪いメッセージを避けなければなりません。第一の悪いメッセージは「警告を無視せよ」です。それは安全でない行動を助長します。第二は「デジタルサービスを無期限に使用停止せよ」です。それは法的義務、給付、許可、必要不可欠な通信を中断させかねません。成熟した対応は、どの公式ドメインが影響を受けているか、いつ交換が予定されているか、どのチャネルが安全なままか、更新情報をどう確認するかを市民に伝えます。

ここに、DigiNotar が単なる認証局セキュリティのケースではなく、ガバナンスのケースとなる理由があります。民間認証局の障害が、公的当局に対して公共サービスの信頼撤回を管理することを強いたのです。国家は、ルートプログラムのセキュリティ判断を市民の継続性へと変換しなければなりませんでした。その変換は、重要なデジタル公共サービスについては事前に計画されるべきです。

インシデント証拠が遅延すれば、監査だけでは不十分である

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

認証局のインシデント証拠は、ライブの公共安全機能として扱われるべきです。最も重要な事実は内部だけのものではありません。影響を受けた証明書名とシリアル番号、発行時刻、失効時刻、疑われる範囲、ルートまたは中間証明書の曝露、保存されたログ、連絡を受けた加入者、通知を受けたルートプログラム、および推奨されるクライアントアクションです。機微な詳細の一部は秘密にされ得ますが、行動に繋がる事実は迅速に動かねばなりません。Mozilla の通知遅延批判が強力なのは、それが単なる技術防御の失敗ではなく、証拠ルーティングの失敗を特定しているからです。

現代の公開 PKI には、2011年当時よりも多くのメカニズムが存在します。Certificate Transparency ログは発行された証明書を露わにできます。CCADB とルートプログラムポリシーはインシデント報告を構造化できます。ブラウザーベンダーは信頼撤回の判断を調整できます。CA/B Forum 要件は期待事項を定義できます。しかし、認証局がそれらを使うことを躊躇するならば、メカニズムは役に立ちません。DigiNotar からのガバナンスの教訓は、信頼は問題が起きていないときの文書上の成功だけでなく、障害時の行動に依存するということです。

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

DigiNotar は、ルート信頼撤回が最も害の少ない選択肢であり得る理由を説明する

ルート信頼撤回は破壊的であるため、それを回避しようとする圧力が常に存在します。ウェブサイトは動作しなくなり得ます。政府ポータルは機能不全に陥り得ます。古いクライアントはアクセスを失い得ます。企業は深刻な事業上の結果を被り得ます。DigiNotar の破産は、信頼撤回が商業的に致命的であり得ることを示しています。それらのコストは現実であり、軽視されるべきではありません。

しかし、代替案はさらに悪くなり得ます。認証局がどの証明書が不正に発行されたかを証明できない場合、信頼を継続することは、全ての依拠ユーザーが未知のなりすましの可能性に晒され続けることを意味します。そうなると、ブラウザーベンダーは不完全な証拠をもってユーザーを保護する責任を負うことになります。その状況では、信頼撤回は「フェイルクローズド」するため、最も害の少ない選択肢となり得ます。それは、もはや検証できない信頼関係の継続性よりも、ユーザー保護を優先します。

これが、認証局の運用上のアカウンタビリティが通常のベンダーのアカウンタビリティよりも厳格である理由です。通常の SaaS の障害は、復旧を待つことで緩和されるかもしれません。認証局の信頼障害は、エコシステムがベンダーの調査完了を待たずにそのベンダーを信用するのを止める必要を生じさせるかもしれません。認証局が安全性を証明できないことは、継続的信頼に対する反証となります。これは厳しい基準ですが、認証局の特権に由来します。すなわち、認証局は、ブラウザーがグローバルに受け入れる、他者のドメインに対する表明を行うことができるのです。

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

ユーザー安全のレンズが修復を導くべきである

認証局の侵害は、容易に機関同士の論争になり得ます。認証局、その親会社、監査人、ブラウザーベンダー、政府、規制当局の間での論争です。ユーザー安全のレンズは、論争の土台を保ちます。ユーザーはなりすましから保護されるために何を必要としているか？市民は正当な公共サービスにアクセスするために何を必要としているか？ドメイン所有者は、自分の名前が悪用されたかどうかを知るために何を必要としているか？ブラウザーベンダーは安全なアップデートを配布するために何を必要としているか？政府は、人々に警告を無視するよう促すことなく移行するために何を必要としているか？

これらの質問が修復を導くとき、責任のマップはより明確になります。DigiNotar は、証拠を提供し、安全でない発行を停止しなければなりませんでした。ブラウザーベンダーは、証拠が不十分な場合には信頼を撤回しなければなりませんでした。政府事業者は移行し、コミュニケーションを行わねばなりませんでした。ドメイン所有者は監視し、対応せねばなりませんでした。ユーザーはアップデートを受け取る必要がありましたが、PKI 問題を自分で解決するよう求められるべきではありませんでした。

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

DigiNotar の永続的な価値は、見えない認証局ガバナンスを可視的な公共の安全へと転換したことです。この侵害は、ウェブの信頼の構造は最も弱い信頼された発行者と同程度にしか強くなく、最も迅速な正直な証拠と同程度にしかアカウンタブルでないことを明らかにしました。それは、全ての公開信頼認証局にとって、現在もなお妥当な基準です。

継続性計画は信頼ストアの伝播を含まねばならない

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

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

この伝播問題は、通知遅延がそれほど深刻であるもう一つの理由です。ブラウザーベンダーや政府が行動するに足るだけの情報を得るまでに失われた一日一日は、既に遅い配布チェーンに加算される一日です。認証局は発見後迅速に証明書を失効するかもしれませんが、実際のユーザー保護は依然として下流のアップデート経路に依存します。DigiNotar の記録は、証拠、信頼撤回判断、証明書交換、そしてクライアントアップデートの伝播の全てが依拠集団に届いたときに初めて、運用上の被害が限定されることを示しています。

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

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

アカウンタビリティの核心

DigiNotar の破綻は、認証局の信頼の実際的な意味を変えました。それは、認証局の内部管理がグローバルなユーザー安全の問題になり得ること、通知の遅延が初期侵入と同様に重大な結果をもたらし得ること、政府の PKI 依存が公共の継続性リスクを生むこと、そしてブラウザーベンダーは認証局が範囲を証明できない場合に緊急信頼撤回を選択せざるを得ない可能性があることを示しました。

アカウンタブルであることの基準は、あらゆる攻撃者に対する完全無欠さではありません。それは証明です。公開認証局は、発行権限が保護されていること、ログと台帳が悪用を明らかにできること、インシデントが迅速に開示されること、失効と移行が運用上可能であること、そしてルートプログラムの信頼が継続的に値することを証明しなければなりません。それができないならば、被害はもはや認証局の顧客リストに限定されません。

したがって、DigiNotar は単に歴史的な教訓譚ではありません。それは、公開ウェブ PKI に依存するあらゆる組織にとっての管理マップです。信頼は委任されますが、被害はユーザー、機関、銀行、病院、裁判所、学校、企業によって局所的に経験されます。信頼の機構を管理する当事者は、その被害を限定する最初の機会を管理するのです。