Loading article…
公開鍵暗号方式では、証明書は有効期限が切れる前に失効させることができ、これにより証明書が無効になったことを示します。失効させなければ、攻撃者は有効期限が切れるまで、侵害された、または誤って発行された証明書を悪用する可能性があります。したがって、失効は公開鍵インフラストラクチャの重要な要素です。失効は、証明書を発行した認証局によって実行され、認証局は暗号的に認証された失効声明を作成します。
クライアントに失効情報を配信する場合、失効の発見の迅速性（ひいては、侵害された証明書を攻撃者が悪用できる期間）は、失効ステータスの照会におけるリソース使用量やプライバシー上の懸念とトレードオフの関係にあります。失効情報が利用できない場合（事故または攻撃による場合）、クライアントは、証明書が失効しているものとして扱う（可用性が低下する）か、失効していないものとして扱う（攻撃者が失効を回避できるようにする）かを決定する必要があります。
失効チェックのコストと、信頼性の低い可能性のあるリモートサービスによる可用性への影響を考慮し、Webブラウザは失効チェックの実行回数を制限し、実行時にはソフトフェイルオーバーを採用しています。証明書失効リストは日常的な使用には帯域幅を過剰に消費し、オンライン証明書ステータスプロトコルは接続遅延とプライバシーの問題を引き起こします。他にもフェイルハードチェックを可能にするための方式が提案されていますが、まだ実用化には至っていません。
2014年に公表されたHeartbleed脆弱性により、秘密鍵が漏洩した可能性があるため、証明書の大量失効が引き起こされました。GlobalSignは発行した証明書の50%以上を失効させました。StartComは無料の証明書を発行しておきながら、失効に料金を請求したとして批判されました。[ 1 ]
2015年の調査では、Webで使用される証明書の全体的な失効率は8%であることが判明したが[ 2 ]、これはHeartbleedの影響で上昇した可能性がある[ 3 ] 。
ほとんどのブラウザにとってウェブセキュリティは優先事項であるにもかかわらず、OCSPとCRLに関連する遅延と帯域幅の要件のため、ブラウザは証明書の状態を確認することに制限を設けています。[ 4 ] 2015年、Google Chromeは拡張検証証明書のみを積極的にチェックし、モバイルブラウザは有効性チェックを一切実行せず、すべての証明書を完全にチェックしたブラウザもありませんでした。[ 5 ] ChromeとFirefoxは、重要とみなされる少数のドメインに対してプッシュベースのチェックを実行します。[ 6 ] ChromeはこれらをCRLセットと呼び、2025年には、1日あたり600kBのダウンロードコストで、すべての失効の約1%をカバーすることになります。[ 7 ]ブラウザは証明書の有効性に関する特殊なケースではほとんど一致しておらず、経験豊富なユーザーでさえ混乱する可能性があります。[ 8 ]
Web PKIの証明書の数は、2010 年代後半に大幅に増加し、2017 年 1 月の 3,000 万から 2020 年 1 月には 4億 3,400 万に達しました。この増加の大きな要因は、Let's Encrypt が無料のドメイン検証済み証明書を提供していることです。失効する可能性のある証明書のセットの規模は、失効メカニズムのスケーラビリティに要件を課します。[ 4 ]
Chuat et al. (2020)は、失効を「非常に困難な問題」と呼んでいます。[ 9 ] 2022 年の RFC 9325 では、証明書の失効は「完全かつ効率的な解決策がない」重要な問題であると特徴づけられています。OCSP と OCSP ステープリングは、「可能な解決策の基盤」として推奨されています。[ 10 ]
Firefoxは2025年にCRLiteをすべてのデスクトップユーザーに展開しました。これは包括的なプライバシー保護失効チェックをWebブラウザに展開した最初の事例です。[ 7 ]
証明書の失効は、攻撃や偶発的な侵害に対処するための「重要なツール」です。RFC 9325 は、TLS 実装に証明書を信頼しないための何らかの手段を持つことを規範的に要求しています。[ 10 ]失効がない場合、攻撃者は侵害された証明書を使用して、有効期限が切れるまで所有者になりすますことができます。[ 4 ]
有効期限が十分に短い証明書（数時間から数日程度）の場合、失効は必要ないかもしれません。これはOCSP応答の有効期間に匹敵します。関連する頻繁な証明書の発行は通常、自動化（ACMEプロトコルなど）を必要とし、他のインフラストラクチャ要素（透明性ログなど）に負荷をかける可能性があります。[ 11 ]有効期限の短い証明書は、必ずしも克服できないわけではありませんが、 TLS接続の再開にも複雑な問題を引き起こします。[ 12 ]
失効は、証明書保有者（例えば、秘密鍵が侵害されたことを知っている場合）が認証局に通知することで開始できます。認証局は、証明書が失効したことを示す暗号的に認証された証明書を作成して配布します。[ 13 ] CA/B 要件では、認証局が侵害の可能性を認識している場合、認証局が自律的に証明書を失効することも認められています。[ 14 ]誰でもそのような証拠を提出できます。[ 15 ]
失効ステータスは通常、証明書の有効期限が切れた後も長期間保存およびアーカイブされないため、失効動作の調査や監査が困難になります。[ 16 ]この問題を解決するための提案の1つは、失効ごとに「postcertificates」を証明書透明性ログに送信することです。これにより、CAによるアクションなしで失効を実行することも可能になります。[ 17 ]証明書透明性に基づく別の提案では、CAがCRVをCTログに送信することになっています。[ 18 ]
失効状態が利用できない場合（これは無害な場合もあれば、攻撃による場合もある）、クライアントは証明書を評価する際にジレンマに直面します。つまり、証明書がまだ有効であると仮定してフェイルソフトを実行するか、証明書が失効したと仮定してフェイルハードを実行するかのどちらかです。これはセキュリティと可用性のトレードオフです。フェイルソフトではダウングレード攻撃が許容されますが、フェイルハードでは（攻撃による）サービス拒否や可用性の低下が許容されます。 [ 19 ]
侵害された証明書を提示できる攻撃者は、クライアントがオンラインで失効状態チェックを実行するのを阻止する能力も持っている可能性が高い。この場合、フェイルソフトは事実上全く保護を提供しない。ブラウザはこのジレンマのこの側面を選択し、セキュリティよりも可用性を優先した。[ 20 ]
フェイルハードは、新たなサービス拒否攻撃ベクトルをもたらす可能性があります。たとえば、クライアントがOCSPステープリングを期待し、そうでない場合はフェイルハードを実行する場合、OCSPレスポンダーに対するサービス拒否は、それらのOCSPレスポンスを使用しようとするすべてのサービスに対するサービス拒否に拡大されます。[ 11 ]
リソース使用状況の評価には、通常の状態と大量取り消しイベントの 2 つのシナリオがあります。取り消しスキームは通常の状態では効率的である必要があり、大量取り消しイベント中も機能する必要があります。[ 4 ]
失効情報の取得には、クライアントにとって帯域幅と遅延のコストが発生します。[ 21 ]
2014年のHeartbleedによる大量失効イベントでは、失効率が1%から11%に上昇しましたが、CloudflareはGlobalSignがCRLを配信するために使用した帯域幅に40万ドル（2025年換算で54万ドル相当）の費用がかかった可能性があると推定しました[ 22 ]。[ 23 ]
失効状態がチェックごとに最新の状態で取得されない場合（キャッシュや定期的な取得など）、証明書が失効してからすべてのクライアントが失効を確実に認識するまでに遅延が生じます。これは、レイテンシ、効率、セキュリティのトレードオフとなります。キャッシュ時間を長くしたり、更新頻度を低くしたりすると、使用するリソースが少なくなり、レイテンシも減少しますが、侵害された証明書がより長く悪用される可能性があります。[ 24 ]
プルベースのチェックを実行するクライアントは、ユーザーの閲覧情報を第三者、つまり失効情報の配信者に漏洩する可能性があります。[ 25 ]
PKIでは信頼できる第三者を作ることは避けることが望ましい。スキーム内のアクターが監査可能であれば、クライアント（またはクライアントに代わって行動するエージェント）はアクターが正しく動作していることを証明して検証できる。[ 26 ]
CAに大きな負担をかける失効ステータスの分布は、特にCAが実装から相殺する利益を得られない場合には、成功しない可能性がある。採用するために変更を行う必要のある関係者の数を減らすことも、展開を容易にする。潜在的に関係するのは、CA、クライアント、サーバー管理者、サーバーソフトウェア製造業者である。前方互換性は諸刃の剣であり、古いクライアントやサーバーは新しいスキームによって混乱しないが、そのユーザーは失効のメリットを逃していることに気づかない可能性がある。[ 27 ]
クライアントが失効ステータスにアクセスする方法には、大きく分けて 3 つのアーキテクチャがあります。プルベースでは、クライアントは検証時に失効ステータスを取得します。プッシュベースでは、クライアントは検証前に失効ステータスを取得してキャッシュします。ネットワーク支援では、失効チェックが TLS プロトコルと密接に統合されており、個別のチェックは必要ない場合があります。[ 28 ]
プルベースのチェックは、通常、レイテンシと可用性の問題を抱えています。プルベースのチェックを実行するクライアントは、通常、応答を短期間キャッシュします。純粋なプルベースのチェックとフェイリングソフトを組み合わせても、セキュリティは向上しません。[ 29 ]
プッシュ型チェックはプル型チェックよりも帯域幅効率は劣りますが、可用性とプライバシーが向上します。証明書ごとに異なる方法を使用することで、トレードオフを細かく調整できます。Google ChromeとMozilla Firefox はどちらも、少数の重要な証明書に対してプッシュ型チェックを実行します。[ 29 ]
証明書失効リスト（CRL）には、失効した証明書が列挙されています。これらは発行CAによって暗号的に認証されます。[ 30 ]
CRLにはスケーラビリティの問題があり、証明書のステータスを確認する前にクライアントがCRLをダウンロードするのに十分なネットワークアクセスを持っていることを前提としている。[ 10 ]
CRLにはCAによって取り消されたすべての証明書に関する情報が含まれているため、ディストリビューターとクライアントは、おそらく無関係な情報のために転送コストを負担しなければなりません。[ 31 ] 2015年の調査では、証明書のCRLのサイズの中央値は51kB、最大のCRLは76MBであることがわかりました。[ 2 ]
オンライン証明書ステータスプロトコル（OCSP）は、クライアントがサーバー（OCSPレスポンダー）に証明書のステータスについて対話的に問い合わせ、発行CAによって暗号的に認証された応答を受け取ることを可能にします。 [ 30 ]これはCRLの問題に対処するために設計されました。[ 31 ]一般的なOCSP応答は1kB未満です。[ 32 ]
OCSP はスケーラビリティの問題を抱えています。証明書の失効状態を確認する際にクライアントがネットワークにアクセスできることを前提としています。さらに、OCSP レスポンダーがアクセス可能で、使用可能な応答を生成しなければ、チェックは失敗し、クライアントはソフトフェイルとハードフェイルのどちらかを選択する必要があります。多くの認証局は、中間証明書に対して有用な OCSP 応答を公開していません。[ 10 ]
ユーザーのブラウジングに応じてレスポンダーにリクエストが送信されるため、OCSP レスポンダーはユーザーのブラウジングについて知ることができ、これはプライバシーの問題となります。また、新しい接続を使用する前にレスポンダーに問い合わせる必要があるため、接続に遅延が発生します。[ 19 ]
2018年の調査では、応答者へのリクエストの1.7%がネットワークレベルで利用できず、さらに約2%が使用できないOCSP応答を生成し、CAとクライアントの視点間で大きなばらつきがあることが判明した。[ 33 ]
OCSPステープリングはTLS拡張機能であり、接続開始時に証明書とともにOCSP応答をクライアントに提供するものです。[ 31 ]
OCSPステープリングは、OCSPの運用上の課題、すなわち追加のネットワーク要求による遅延やプライバシーの低下を解決できます。[ 34 ]ただし、オンパス攻撃者によるダウングレード攻撃を受けやすい場合があります。 [ 10 ] RFC 7633では、有効なOCSP応答にステープリングされる証明書に要件を埋め込む拡張機能が定義されています。[ 35 ]この拡張機能を使用すると、証明書が適切に発行された後に侵害された場合にステープリングが有効になりますが、拡張機能なしで証明書が誤って発行される可能性がある場合は、ステープリングはセキュリティを提供しない可能性があります。[ 36 ]
クライアントと CA がステープリングと must-staple 拡張機能を有効にするだけでなく、サーバー管理者も定期的に応答を取得し、ハンドシェイク中にクライアントに提供することでステープリングをサポートする措置を講じる必要があります。2018 年時点では、Firefox だけが must-staple をサポートしており、最もよく使用されている 2 つの Web サーバー ( Apache httpdとNginx ) はどちらも OCSP ステープリングをまったくサポートしていませんでした。[ 37 ]
CRLite は、近似メンバーシップクエリフィルタを使用して、証明書ステータスの高度に圧縮された静的表現をクライアントに提供し、効率的な生成、配布、およびクエリを可能にします。[ 38 ] CRLite はクライアントが完全な失敗を許容し、すべてのクライアントが同じ情報を取得するため、CRLite にはプライバシーに関する懸念はありません。[ 24 ]
CRLite は展開可能で、アグリゲーターが CA から CRL を取得し、フィルタ カスケードとそれへの更新を提供し、クライアントがそれを使用するだけで済みます。CA や証明書所有者によるアクションは必要ありません。[ 24 ]アグリゲーターは信頼できる第三者である必要はありません。フィルタ カスケードは、入力 CRL を正確に反映していることを証明するために監査できます。[ 39 ]プライベート CAも CRLite 内で特別な処理が必要です。[ 40 ] Firefox のデータによると、証明書の 5% はプライベート CA またはマージの遅延のために CT ログにありません。[ 41 ]
当初の設計では、CRLite はブルームフィルタのカスケードでした。[ 38 ]失効証明書のリストから構築された単一のフィルタは、偽陽性を生成します。オープン ドメインでは、これは失効チェックにとって克服できない問題です。しかし、証明書の透明性を使用してすべての有効期限が切れていない証明書を列挙すると、偽陽性の網羅的なリストを作成できます。このリストは、2 番目のフィルタを構築するために使用され、証明書が最初のフィルタと一致する場合 (したがって、厳密に小さいドメインを持つ場合) に参照されます。2 番目のフィルタが一致しない場合は、真陽性であり、証明書は失効しています。ただし、2 番目のフィルタでの一致は偽陰性である可能性があり、3 番目のフィルタが必要になります。
1 月の Web PKI 内のすべての証明書の失効ステータスは、ブルームフィルタカスケードを使用した場合、10 MB のサイズと推定され、1 日あたり 580 kB の更新が必要でした。2018 年 3 月には、これが 18 MB に増加しました。[ 29 ] 1 億の証明書、1 日あたりの有効期限が 1%、失効率が 2% のシミュレーションでは、CRLite は最初に 3.1 MB のプロビジョニングが必要で、その後は更新のために 1 日あたり 408 kB が必要でした。[ 43 ] Mozilla は、CRLite の試験展開で、2024 年に償却ダウンロード速度が 10 日で 26 MB であることがわかりました。[ 38 ]
CRLiteはその後、データ使用量を削減する、より効率的な新しいアルゴリズムであるclubcardsを使用するように改訂され、また、失効がCA間で均一に分布していないこと（つまり、一部のCAは他のCAよりも継続的に高い失効率を持っている）、また時間的にも分布していないこと（たとえば、大量失効イベントのため）を観察し、これらのパラメータで証明書を分割することで効率を改善できることも確認されました。[ 44 ] 2024年のclubcardメンバーシップテストデータの最初のダウンロードは7.0 MBで、9億300万の有効な証明書と870万の失効した証明書をカバーしていました。6時間ごとに生成される更新は平均95.5 kBでしたが、26.0 kBに圧縮できました。発行者による分割のみの場合、これは理論上の下限の12%以内です。有効期限/発行日を使用したより高度な分割では、悪用できる残りの量は最大116%に達します。[ 45 ]
Firefox バージョン 68 で CRLite の初期設計の機能フラグの背後で試験的に展開した後、 [ 38 ] Mozilla は Firefox バージョン 137 で改訂された設計を実装し、2025 年 8 月に Firefox 142 でドメイン検証証明書の OCSP を無効にし、[ 7 ]事実上CRLite の本番使用に切り替えました。[ 46 ]ラボ テストでは、失効チェックは証明書あたりわずか 10 μs で済むことがわかりました。また、フィールド データでは、平均 TLS ハンドシェイク時間が 172.4 ms から 143.4 ms に短縮され、これは OCSP 応答を取得する必要がないためと考えられます。[ 45 ]
Let's Revoke は、失効状態のビット ベクトル(証明書失効ベクトル、または CRV と呼ばれる) を使用して、大量の失効状態をクライアントが効率的に取得できるようにします。[ 4 ] CA は、有効期限ごとに 1 つの CRV を持つ、独自の証明書の CRV を生成します。CA の CRV のメンテナンスは、発行された証明書の数に比例します。CA は、発行された各証明書に失効番号という新しいフィールドを追加する必要があります。これにより、単一の CA からの証明書を証明書の有効期限と失効番号のタプルで識別できます。このタプルにより、クライアントは、識別された証明書のステータスを示すビットを CRV 内で効率的に見つけることができます。CRV は圧縮できます。ほとんどのビットはほとんどの場合設定されていないため、非常にうまく圧縮できると予想されます。各 CRV は固定の有効期限に関連付けられているため、古い CRV は効率的に破棄できます。CRV の更新はバッチ処理され、更新にはタイムスタンプが付けられ、署名されてクライアントに配布されます。[ 47 ]更新は3つの形式のいずれかで行われる可能性があり、最適な選択は失効率に応じて決まり、効率的な通常運用と大量失効イベントの両方に対応できます。[ 48 ]
CRV はプッシュ ベースのチェックを可能にするのに十分な小ささであると予想されますが、より制約のあるクライアントはプル ベースのチェックを実行し、特定の CRV にのみアクセスするか、証明書の検証まで CRV の取得を延期する可能性があります。[ 49 ]プッシュ ベースのチェックで Let's Revoke を使用するクライアントは、失効番号を持つ証明書に対して完全に失敗することができます。[ 24 ] Let's Revoke のプライバシーへの影響と可用性はアーキテクチャに依存します。すべてのチェックがプッシュ ベースであれば、プライバシーの漏洩はなく、サービス拒否やダウンタイムに対する脆弱性が軽減されます。ただし、プル ベースのチェックを使用すると、ユーザーのアクティビティに関する情報 (どの CRV にアクセスしたかという形式) が漏洩し、検証時に CRV にアクセスできなくなる可能性があります。[ 24 ]
1億個の証明書、1日の有効期限切れ率1%、失効率2%のシミュレーションでは、Let's Revokeは初期プロビジョニングに2.2MB、その後は更新に1日あたり114kBを必要とした。[ 50 ]
Let's Revoke はまだ広く展開されていません。[ 10 ]クライアントの実装に加えて、CA が運用上の変更を行う必要があり、[ 51 ] CRL や OCSP ほど多くの情報を提供しません (証明書ごとに有効性に関する情報のみ)。CRL や OCSP は、Let's Revoke を補完し、追加情報を提供するために引き続き使用できます。[ 52 ]展開は CA ごとに実行でき、クライアントは段階的にフェイルハード動作の恩恵を受けます。CRV は CRL や OCSP 応答よりも効率的であるため、CA は Let's Revoke を展開するインセンティブを持つ可能性があります。[ 51 ]
プライベート情報検索技術は、プルベースのチェックによるプライバシーの懸念を軽減できる。[ 53 ]クライアントが失効チェックを実行する代わりに、ミドルボックスが失効チェックのコストを集中管理し、それを多数の接続に分散させることができる。クライアントは失効情報のためにストレージを占有する必要がない。[ 54 ]別の提案では、FMラジオで失効情報を放送することが含まれていた。[ 42 ]
{{cite journal}}:ジャーナルを引用するには|journal=（ヘルプ）