# 認証局とPKIの信頼モデル ## 定義 認証局(CA)とPKIの信頼モデルとは、公開鍵を組織・人物・デバイスの名前や役割に結びつける証明書を発行・管理する仕組みが、誰を信頼の起点とし、その信頼をどう検証・失効・監査するかという設計問題を指す。X.509系のPKI機構はもともと電話帳の電子的な置き換えとして設計され、誰もが一意な名前と一意な鍵を持つという「オープンPKI」を前提に設計された。汎用アプリケーションに開放されたPKIを**オープンPKI**、単一目的に限定されたものを**クローズドPKI**と呼び分ける。ドットコムブーム期に多数のCAが乱立し企業が買収・統合を繰り返した後、各国政府がブラウザのルート証明書ストアに自国CAを組み込もうとする中央集権的な圧力が生じ、分散的な信頼(誰でもCAになれる)と政府による乗っ取り圧力の綱引きが続いている。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] ch.21 §21.6) ## 信頼の崩壊と再建(§21.6) 2011年、オランダのCA DigiNotarがイラン当局にハッキングされ、Gmail用のワイルドカード証明書が不正発行され、30万人のイラン国内Gmailユーザーの監視に悪用された。Mozilla・Googleは即座にDigiNotarのルート証明書を失効させ、Microsoft・Appleも追随したが、DigiNotar証明書に依存していたオランダ政府の複数のオンラインサービスが大きく混乱した。これに先立ちComodo社も攻撃を受けていたが、同社は不正発行された証明書をすべて失効済みと主張した。この事件を機にブラウザのルートストア運営者からCA・監査法人への圧力が強まった。この綱引きを是正する技術的対応として、(1) certificate transparency(全ての発行証明書を公開ログに記録し、ドメイン所有者が不正発行を即座に発見できるようにする仕組み。Googleが2013年に最初のログを開始し、2018年に全CAへ義務化)、(2) 証明書の最大有効期間の段階的短縮(8年→3年→27ヶ月、2020年にAppleが398日超を拒否)、(3) Let's Encrypt(非営利のISRGが運営、2015年開始、証明書取得・更新を完全自動化し無料化。2020年時点で最大のCA、発行数10億件超、年間予算300万ドルのみで1億超のサイトを支える)による証明書取得の民主化、という3つが挙げられる。Let's Encryptの結果、平文接続の比率は4年前の60%から20%まで低下した。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] ch.21 §21.6) ## 自前構築 CA の設計・運用(ch.11) [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] は、公的に信頼される CA を「買う」のではなく「作る」側の視点から、上記の信頼モデルを支える運用の内実を具体的に示す。公的に信頼される CA になるには WebTrust・ETSI の基準に基づく監査と CA/Browser Forum Baseline Requirements への準拠が必須で、典型的な CA は年間の少なくとも四半期をこれらの監査に費やす。Google が自前 CA を構築した理由は、第三者 CA が高水準の信頼を満たしているか確信が持てなかったこと(DigiNotar のような公的 CA での重大な失態が念頭にあった)、数百万件規模の証明書発行・ローテーションを自動化する必要に第三者 CA の API/SLA が応えられなかったこと、そしてコスト効率の 3 点である。商用 CA ソフトウェアの購入ではなく自前実装を選んだのは、コード・サプライチェーンの監査可能性、Spanner のような既存の安全な基盤インフラとの統合容易性、そして Certificate Transparency やドメイン検証手法のような新しいエコシステムの取り組みに早期追従できる柔軟性が理由である。設計面では、証明書リクエスト解析・登録局(RA)機能・署名という 3 層アーキテクチャと、信頼できない入力を扱う層と重要な操作を扱う層を分けるデュアル信頼ゾーンを組み合わせ、コンポーネントの機能を限定することで攻撃の影響範囲を抑えている。鍵の保護については、root 鍵をオフラインに置き各アクセス層に二者承認を要する多層の物理的保護を施す一方、日常の発行には online な中間鍵を使うという業界標準的な構成を採用し、公的 CA がエコシステム全体に広く信頼されるまで年単位を要するために鍵の危殆化後のローテーションが容易でないことへの備えとして、代替 root 鍵材料をあらかじめエコシステムに配布して「成熟」させている。証明書の発行・失効の運用面では、発行の複数段階でリンタ(ZLint 等)を通し、検証済み証明書を Certificate Transparency ログに登録し、複数の独立したログシステムをエントリ単位で突き合わせることで不正発行に対する最終防衛線としている。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] §Background on Publicly Trusted Certificate Authorities, §Why Did We Need a Publicly Trusted CA?, §The Build or Buy Decision, §Design, Implementation, and Maintenance Considerations) ## 横断的知見 - **同じ DigiNotar 事件が、ブラウザ/ルートストア側からの是正策(ch.21)と、相互不信を抱いた relying party 自身による自前構築(ch.11)という 2 つの異なる対応を生んだことが、2 つの章を突き合わせて初めて分かる**: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] は DigiNotar 事件を、ブラウザベンダーがルート証明書を即座に失効させ、証明書の最大有効期間短縮や Certificate Transparency 義務化といった業界横断のエコシステム規制を強化する契機として描く。一方 [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] は同じ事件(を含む「公的 CA での重大な失態」)を、第三者 CA に自社の信頼を委ねることへの不安の根拠として引用し、Google 自身が公的に信頼される CA を自前で運用するという、個々の relying party による垂直統合の判断につなげる。同一の歴史的事件が、業界規制の強化(ch.21)と個別事業者の build-vs-buy 判断(ch.11)という異なるレイヤーの対応を同時に引き起こしたことになる。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] ch.21 §21.6, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] §Why Did We Need a Publicly Trusted CA?) - **Certificate Transparency は、ch.21 が描く「業界エコシステムの是正策」という外形と、ch.11 が描く「1 つの CA 運用者が発行パイプラインに組み込む具体的な仕組み」という内実の、2 つの相補的な粒度で記述される**: ch.21 は CT を 2013 年に Google が開始し 2018 年に全 CA へ実質義務化された、公開ログによる不正発行検知の業界標準的な取り組みとして年表的に説明する。ch.11 はその CT を、自社 CA の発行プロセスの一部として――リンタ通過後の証明書を CT ログへ登録し、さらに複数の独立ログシステムをエントリ単位で突き合わせ、ログ自体を署名する――という運用手順のレベルまで具体化する。ch.21 だけでは CT が「なぜ・いつ」導入されたかは分かるが「CA 運用者は実際に何をするのか」は分からず、ch.11 だけでは逆に CT がなぜ業界標準になったかの経緯が分からない。両者を合わせて初めて、規制史と実装の両輪が見える。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] ch.21 §21.6, [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] §Design, Implementation, and Maintenance Considerations > Data Validation, [[Certificate Transparency]]) ## 未解決の問い - 本章はPKIの限界として「名前が難しい」ことを分散システムの章([[@2020__Wiley__Security Engineering 3e - Chapter 7 Distributed Systems]])に遡って参照するが、[[セキュリティにおける命名]] が記録するNeedhamの命名十原則(特にグローバル一意名は思うほどの利益をもたらさない、名前は早期に束縛すべきでない)は、本概念のCA/PKIの設計判断(証明書の有効期間短縮・オープンPKI対クローズドPKI)にどこまで直接適用できるか、本章では明示的に接続されていない。 - Let's Encryptの自動化されたcertbotプロトコル(RFC 8555)がもたらした「証明書取得の民主化」は、本章が指摘する「dotcomブーム期の認証局ゴールドラッシュ」が繰り返した誤り(投機的な期待とその崩壊)を回避できているのか、それとも別の集中(Let's Encrypt自体への一極集中)を生んでいるのか、本章では定量的な評価に至っていない。 - DigiNotar事件・Comodo攻撃はいずれもヨーロッパのCAだったが、本章はアジア・アフリカ地域のCAエコシステムの脆弱性については扱っていない。地域的な偏りがあるかは未検証。 - 「オープンPKI/クローズドPKI」という区別は本章独自の用語法であり、業界標準の用語(public PKI/private PKIなど)との対応関係は本章内では明示されていない。 - ch.11 は WebTrust・ETSI・CA/Browser Forum Baseline Requirements の監査を「年間最低四半期を要する」と述べるにとどまり、[[セキュリティ評価制度]] が指摘するフォーラムショッピング(被評価者が評価者を選べることで審査が緩む構造)がこれら CA 監査にも同型で存在するかは、本章の範囲では検証されていない。CA が監査法人を自ら選定する点は Common Criteria の構造と類似するが、両者の監査の厳格さを直接比較できる記述は本章にない。 - ch.11 は root 鍵を侵害後にローテーションする「復旧」が容易でないと述べ、代替 root 鍵材料をあらかじめエコシステムに「成熟」させておく対策を挙げるが、この成熟プロセスの具体的な期間・手続きは記述されていない。ローテーションの困難さが実際にどの程度の時間・コストを要するかは未解決のまま残る。 ## 関連 - ソース: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]](§21.6 CA・PKI・certificate transparency・Let's Encrypt) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]](公的 CA の build-vs-buy 判断・監査要件・鍵保護・発行運用) - 概念: [[ゼロトラスト]](認証の単位が場所からトランザクションへ移る点で信頼モデルの設計思想を共有) / [[ネットワークセキュリティアーキテクチャ]](セキュリティを個別メカニズムでなくアーキテクチャとして捉える視点) / [[セキュリティにおける命名]](証明書に載せる名前の設計問題) / [[セキュリティ評価制度]](CA 監査という評価制度の一事例) / [[HSM APIセキュリティ]](CA 鍵材料保護に使う HSM という同じコンポーネントへの異なる脅威モデル) - 実体: [[Certificate Transparency]] - 章: [[@2020__Wiley__Security Engineering 3e - Chapter 21 Network Attack and Defence]] / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 11 Case Study - Designing, Implementing, and Maintaining a Publicly Trusted CA]] ## 出典 - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 21, §21.6. - Andy Warner, James Kasten, Rob Smits, Piotr Kucharski, and Sergey Simakov, in Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 11.