『プロフェッショナルSSL/TLS』読書会3章
- 2. • インターネットPKI（Public Key Infrastructure） • いわゆるインターネットで使われるPKI • 最近web PKIという用語も • ブラウザにおける証明書の利用と検証 • 目的 • お互いにあったことがないものどうしでの安全な通信の実現 • 認証局CA（Certification Authority） • 全員が無条件に信頼する証明書を発行する機関 • 現在のPKIはCAに信頼をゆだねるモデル 公開鍵基盤 2 / 23
- 3. • 証明書所有者（Subscriber） • 証明書を必要としている人（End-Entityとも） • 証明書 • 証明書所有者の本人性を保証するもの • 登録局（RA:Registration Authority） • 証明書発行の際の本人性確認 • 実在していること、身元調査など • 認証局（CA:Certification authority） • 証明書を発行する機関 • 証明書利用者（Relying party） • 証明書を検証したり使う人 登場人物 3 / 23
- 4. • 証明書 • PKIの基本的な構成要素 • デジタル文章で次のものを含む • 公開鍵 • 公開鍵に紐づけられた主体に関する情報 • 証明書を発行した主体のデジタル署名 • X.509 • PKIの国際標準 • PKIXワーキンググループがRFC5280を作成 • 証明書のフォーマット • 信頼パス • 証明書失効リスト（CRL:Certificate Revocation List） 証明書の標準 4 / 23
- 5. • ASN.1 • 複雑なデータ構造をやりとりするためのルール集 • BER（Basic Encoding Rules） • ASN.1と別の標準 • DER（Distinguished Encoding Rules） • BERのサブセット • ASN.1の値が一意になるように定めたもの • PEM（Privacy-Enhanced Mail） • DERをASCIIコードでエンコードしたもの 証明書のフォーマット 5 / 23
- 6. • バージョン（通常3） • シリアル番号 • 証明書を一意に識別する番号 20ビットの予測不能な値 • 署名アルゴリズム • 発行者（Issuer） • 証明書の発行者の識別名（DN:Distinguished Name） • 国（Country） • 組織（Organization） • 部門（Organizational unit） • 例:VeriSignのルートCA証明書のDN • /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority 証明書のフィールド（1/2） 6 / 23
- 7. • 有効性（Validity） • 証明書の有効期間 • 主体者（Subject） • 証明書の発行を受けた者の識別名 • 自己証明書ならSubjectとIssuerフィールドが同じ • 公開鍵 • Subject Public-Key Info構造体（RFC3279で規定） 証明書のフィールド（2/2） 7 / 23
- 8. • 追加されたもの • 一意の識別子オブジェクト（OID:Object Identifier） • 拡張子の重要度（critical） • 値 • 主体者の別名（Subject Alternative Name） • 主体と公開鍵を結びつける • より柔軟なSAN拡張（Subject Alternative Name）が使われる • 名前制約（Name Constraints） • CAが証明書を発行できる主体に制約を課す • 自分が所有しているドメイン名に対してのみ証明書を発行で きる 証明書の拡張（1/3） 8 / 23
- 9. • 基本制約（Basic Constraints） • 証明書パスの深さを制御する • どれだけ下位CAを入れ子に出来るか • 鍵用途（Key Usage） • CA証明書なら署名とCRL署名の検証用を設定 • 鍵拡張用途（Extended Key Usage） • 公開鍵の用途を柔軟に決定できる • id-kp-serverAuth ; エンドエンティティ用証明書 • id-kp-codeSigning ; コード署名用証明書 • 証明書ポリシー（Certificate Policies） • 複数のポリシーを指定 証明書の拡張（2/3） 9 / 23
- 10. • CRL配布点（CRL Distribution POints） • CRLの場所を示す • 認証機関アクセス情報 • AIA : Authority Information Access • CAが提供する情報にアクセスする方法を示す • 例 : OCSPレスポンダの場所 • ここにアクセスして失効情報をリアルタイムに確認する • 主体者鍵識別子（Subject Key Identifier） • 特定の公開鍵を含む証明書を識別するためのハッシュ値 • 機関鍵識別子（Authority Key Identifier） • 証明書に対する署名の鍵を一意に特定する識別子 証明書の拡張（3/3） 10 / 23
- 11. • エンドエンティティ用証明書を検証する証明書の列 • 最後はルートCA証明書 • チェーンにする理由 • ルートCAの鍵を安全に保つ • 非常に重要なためルート鍵の扱いは自動化禁止のルール • オフラインで保管すべき • ルートCAでエンドエンティティ用の証明書の発行禁止 • 相互認証証明書（Cross-certification） • 新しくCAの運用を始めるには相互認証するしかない • 他の稼働してるCAに自分たちのルート鍵を署名してもらう 証明書チェーン（1/2） エンドエンティティ 証明書 中間CA証明書 ルートCA証明書 ブラウザやOSが保持サーバが提供 11 / 23
- 12. • 区画化（Compartmentalization） • 複数の下位CA証明書間で運用を分割する • 鍵が暴かれるリスクを分散 • 委譲（Deligation） • CAが自分たちの関連組織でない別の組織を下位CAにする場合 証明書チェーン（2/2） 12 / 23
- 13. • 証明書利用者 • OSやブラウザはルートCAの一覧を持っている • Apple, Chrome, Microsoft, Mozilla • CA • パブリックCAになるためには • 競争力のあるCAを構築すること • PKI, CAの運用に関して深い専門知識 • CA証明書の鍵を守る強固なネットワークの設計 • 様々なルールにしたがう • baseline requirements • EV SSL certificate Guidelines • 各国の法律 etc. 証明書利用者とCA 13 / 23
- 14. • DV証明書（Domain validation） • ドメイン名を管轄していること • 大抵の場合申請証人用メールアドレスが使われる • 自動化されている • 数時間で発行 • OV証明書（Organization validation） • サイトを運営している組織が実在していること • EV証明書（Extended validation） • 厳格な本人性の検証 • 詳細な検証の手順 • 発行まで数日から数週間 証明書の種類 14 / 23
- 15. • 発行 • 証明書所有者がCSR（Certificate Signing Request）を用意して CAに送信 • CAは証明書の検証をして発行 • 失効 • 有効期限がくれば失効 • 秘密鍵が危殆化したり証明書が不要になって失効することも 証明書のライフサイクル 15 / 23
- 16. • CRL • 期限前に失効した全ての証明書のシリアル番号の一覧 • 肥大化してリアルタイム検索が遅くなる • OCSP（Online Certificate Status Protocol） • 証明書利用者が単一の証明書の失効状態を取得できるように する仕組み • OCSPレスポンダ（OCSPのサーバ）に問い合わせる • リアルタイムに確認できる • プライバシーの問題 • その解決のためOCSPステープリングという仕組み • サーバがOCSPレスポンダに問い合わせてクライアントに 送信 失効の確認 16 / 23
- 17. • 現在 • 商業的に多少の問題はあるがある程度うまく動いてる • 問題点 • 証明書の発行のときにドメイン所有者の許可が不要 • 全てのCAが任意のドメイン名の証明書を発行できる • 全てのCAは監査を受ける必要はあるがその質の保証はない • CAは公共の利益のために仕事をしているのか • 2011 Trustwaveが任意のwebサイト用の証明書を発行 • あるCAが政府のいいなりになっていないか PKIの弱点（1/3） 17 / 23
- 18. • 信頼の回復に時間がかかる • 信頼を迅速に回復する性質（trust agility）がない • たくさんの数を発行しているCAの証明書を除去するのは困難 • ドメインの検証が弱い • WHOISプロトコル（安全ではない）経由でドメイン名の所有 者を検証 • 電子メールも安全ではない可能性 PKIの弱点（2/3） 18 / 23
- 19. • 失効がうまくいかない • 失効が波及するのに時間がかかる（最低10日） • ソフトフェイル（soft-fail）ポリシー • 失効情報の取得に失敗すると無視する仕様 • 能動的攻撃者がOCSPサーバに負荷をかけてエラーにする • 証明書の検証が手ぬるい • 検証が不完全なライブラリやアプリケーションが多い • HSTS（HTTP Strict Transport Security） • 警告をエラーにする方向 PKIの弱点（3/3） 19 / 23
- 20. • PKIに対する最も確実な攻撃 • 政府機関がCAに秘密鍵の提供を要求する • 1億円あれば新規にCAを設置してルート証明書をトラストス トアに埋め込める? • 中間CA証明書の攻撃 • 1024ビットRSAは複数の政府機関によって破られていると考 えるべき • 目立たないので攻撃対象になりやすい ルートCA証明書の鍵の危殆化 20 / 23
- 21. • 2010年著者ら • 12億のドメイン名について調査 • 証明書とTLSサーバのセキュリティを分析 • 2011年 Holzら • IPv4全体のスキャンニング • Alexaリスト上位100万件のHTTPSサーバのスキャンニング • 2013年 Durumericら • インターネット全体のスキャンニング14カ月に110回 • たくさんの小さな問題点を明らかにした エコシステムの観測 21 / 23
- 22. • 公開鍵ピンニング（Public key pinning） • 信頼できるCAをサイトの所有者が選択できる • HPKP • Google主導 • CT（Certificate Transparency） • 公開証明書を証明書ログに記録 • ドメイン所有者はログを監視 • Google主導 • DANE • DNSSECとTLSの認証を橋渡しする • 中央集権的なのが問題 • OS/ブラウザの対応が必要 改善プロトコル提案 22 / 23
- 23. • Perspectives • TLSの認証を補助する独立した公証人サーバ • Convergence • Prespectivesのフォーク • プライバシー改善のため複数プロキシを介在(~2013) • ソブリン鍵（Soveeign Keys） • 公的に検証可能なログに記録される鍵を使ってドメイン名を 主張 • MECAI, TACK, etc. その他アイデア段階 23 / 23