CRLiteについて
catatsuy
こちらの要約。
1. 背景と課題
TLS/SSL証明書は、ウェブ通信の信頼性や暗号化、認証を支える重要な仕組みですが、誤発行や秘密鍵漏洩などの問題が発生した際には、速やかに証明書を失効させる必要があります。従来の証明書失効確認方法であるCRL（証明書失効リスト）やOCSP（オンライン証明書状態プロトコル）には、以下のような問題があります：
-
帯域幅と遅延の増加
CRLはファイルサイズが非常に大きい場合があり、OCSPは通信が遅延するため、TLS接続の確立に負荷がかかります。 -
プライバシーの懸念
OCSPの場合、各証明書の状態確認のために第三者にリクエストを送る必要があるため、ユーザの閲覧履歴が漏れるリスクがあります。 -
信頼性の低下
ネットワーク障害や攻撃により失効情報が取得できない場合、現状のブラウザは安全性より可用性を優先する「fail-open」モデルを採用しており、結果的に失効すべき証明書が有効と判断される危険があります。
また、GoogleのCRLSetやMozillaのOneCRLといったプッシュ型の仕組みは、収録件数が限られているため、すべての失効証明書をカバーできないという課題もあります。
2. CRLite の概要と設計理念
CRLiteは、全ての既知のTLS証明書に対して失効情報を包括的かつ効率的に配信するシステムです。その主な特徴は以下の通りです：
-
全証明書のカバー
IPv4スキャンやGoogleのCTログなどから集めた膨大な証明書データ（数千万件）を基に、全体の有効証明書と失効証明書の状態を正確に把握します。 -
圧縮された失効情報の配信
集約された失効情報は、複数段のBloom Filter（「Filter Cascade」と呼ばれる）を用いて圧縮され、全体でわずか10MB程度にまとめられます。 -
クライアントでのローカル検証
ブラウザは日次で全体のフィルタまたは差分更新（平均約580KB）をダウンロードし、TLS接続時にローカルで証明書の失効状態を迅速に確認できます。これにより、外部への問い合わせが不要になり、プライバシーも保護されます。 -
fail-closedの採用
失効情報をローカルに保持しているため、ネットワーク障害や攻撃によって情報が一時的に入手できなくなった場合でも、失効すべき証明書を安全に拒否することが可能です。 -
監査可能な運用
サーバ側では、使用したCRLやOCSPレスポンス、そして検証に用いた証明書のコピーを含む監査ログを署名付きで生成しており、第三者による正当性の検証が可能です。
3. Filter Cascadeによる誤検出ゼロの実現
3.1 通常のBloom Filterの特性
単一のBloom Filterは、挿入された要素に対しては必ず「含む」と判定するため、失効すべき証明書が確実に検出される一方、挿入されていない要素（有効な証明書）に対しても、一定の確率で誤って「含む」と判定してしまいます。これが通常のBloom Filterの誤検出（false positive）の問題です。
3.2 多段のBloom Filter（Filter Cascade）のアイディア
CRLiteでは、全TLS証明書という有限で既知の集合だけを対象にするという前提を利用しています。ここでの基本戦略は、複数段のBloom Filterを順次適用して、各段で発生した誤検出の要素だけを次の段で補正していくというものです。
-
第1段では、失効証明書を挿入しますが、誤って有効な証明書が「含む」と判断されることがあります（これを第1段の誤検出とします）。
-
第2段では、第1段で誤って含まれた有効な証明書の集合を対象にして、再度チェックを行い、誤検出の一部を除外します。しかし、第2段でも若干の誤判定が発生する可能性があります。
-
こうした処理を必要な段数だけ繰り返すことで、誤検出の要素は段階的に幾何級数的に減少し、最終的には全く誤検出が残らない状態にまで到達します。
3.3 誤検出ゼロの理論的背景
ここで重要なのは、Bloom Filterの問い合わせ対象が任意の全ての可能性ではなく、既知の有限集合（全証明書の集合）に限られている点です。この前提により、各段で発生する誤検出の数は非常に小さくなり、十分な段数（適切なパラメータ選択のもと）を用いることで、実際の運用上は誤検出が完全に排除される状態にできます。
具体的には、各段での誤検出は前段での誤判定の一部だけとなり、これを連続して除去していくことで、最終段においては全く誤検出が残らず、すべての証明書について正確に「失効か有効か」が判定できるようになります。各段の判定結果の偶奇（奇数段か偶数段か）によって最終的な判断が決まるため、段階的な補正効果により、理論上は誤検出ゼロが実現されます。
4. サーバ・クライアントの実装と運用
4.1 サーバ側の運用
-
データ収集
大規模なIPv4スキャンとGoogleのCTログから得られる数億件の証明書情報の中から、実際に有効な証明書を抽出し、さらに各証明書に関連するCRLおよびOCSPの情報を収集します。これにより、全体として約数千万件の有効証明書と失効証明書の情報を確実に把握します。 -
フィルタの構築と更新
収集した失効情報は、Filter Cascadeとして複数段のBloom Filterに圧縮されます。初回は約10MB程度のサイズとなり、その後は日々の証明書集合の変化に応じて、平均して580KB程度の差分アップデートが生成されます。これにより、日次で最新の失効情報がクライアントに提供されます。 -
監査ログの生成
失効情報の正当性を保証するために、使用したCRLやOCSPレスポンス、そして検証に使用した証明書情報を署名付きで保存する監査ログも生成されます。これにより、第三者がCRLiteサーバの動作を検証できる仕組みが確立されます。
4.2 クライアント側の実装
-
ローカルでの失効確認
ブラウザ（現在はFirefox拡張機能として実装）により、毎日サーバから最新のFilter Cascadeまたは差分更新を受信し、TLS接続時に証明書の失効状態をローカルで迅速にチェックします。これにより、オンラインでの問い合わせが不要になり、接続の高速化とプライバシー保護が実現されます。 -
キャッシュによる高速化
多くのユーザは頻繁に同じウェブサイトへアクセスするため、最近確認された証明書については、キャッシュを用いて高速に判定を行います。差分が適用されるたびにキャッシュは更新される仕組みです。
5. セキュリティと運用上の利点
-
fail-closedの実現
ローカルに最新の失効情報を保持するため、ネットワーク障害や攻撃下でも正確な判定が可能です。従来のfail-openモデルで生じるリスクを大幅に低減します。 -
プライバシー保護
失効チェックをローカルで完結させるため、第三者にユーザの閲覧履歴が漏れるリスクがありません。 -
運用の容易さ
CRLiteは、既存の証明書、CRL、OCSPの仕組みをそのまま利用し、CAsやTLSプロトコルへの改修を必要としないため、すぐに導入可能です。 -
監査性と透明性
署名付きの監査ログにより、CRLiteサーバのフィルタ生成が正しく行われたかどうかを、独立した第三者が検証できるため、信頼性が高まります。 -
帯域幅と遅延の最適化
初期の全フィルタのサイズは約10MB、日次更新は580KBと低コストで済むため、帯域幅の消費や接続遅延を最小限に抑えられます。
6. まとめ
CRLiteは、従来のCRLやOCSPが抱える帯域幅、レイテンシ、プライバシー、そしてfail-open問題などの課題を解決するために設計されたシステムです。
その中心となるFilter Cascade技術では、複数段のBloom Filterを用いて、誤って有効な証明書が失効と誤判定される問題を段階的に除去し、最終的には誤検出が全く残らない状態を実現します。
また、サーバ側では大規模な証明書情報の収集・圧縮、日次の差分更新と監査ログの生成を行い、クライアント側ではローカルで高速に証明書の失効状態を確認できるため、全体として安全で効率的な証明書失効チェックが実現されます。
このように、CRLiteは現行のウェブPKI環境における証明書失効チェックの問題を根本から解決する有望なアプローチとして、即時導入が可能な実用的ソリューションとなっています。