その4：証明書失効の難しさについて

前回のブログでは、一般的なPKIシステムフレームワークと、それが車載通信（V2X）を実現するためにどのように使われるかについてに述べ、特定の状況下に於いて証明書を失効させる必要性について述べました。今回のブログでは、この失効をさせるメカニズムとその難しさについて考察します。

今回の話は証明書の失効に関する一般的な話であり、必ずしも車載通信（V2X）向けV-PKIシステム固有の話ではありません。しかし、V‐PKIにおいても同様の事柄が適応されるのでこの点を理解することは重要であると考えます。

前回のブログで述べた通り、ある状況に於いて証明書を取り消す必要が生じます。証明書が取り消された場合、その事実をその証明書を使用する可能性のある他のもの（V2Xの場合は車両全般）に伝達する必要があります。これによって初めて、他のものは当該証明書が無効で、それを含むメッセージは無視すべきであるということを正しく認識できることになります。

証明書の無効化のメカニズム

ここで問題となるのは、「他者」（証明書の利用者）が特定の証明書が失効した状況をどのように把握するかであります。これに対するソリューションとして今まで複数のものがありましたが、あまりうまく機能してきてはいないと言えます。当初のソリューションの問題点を直すため、次のソリューションが作られましたが、それで前ソリューションの問題をある程度解決はしたものの、結果として意図せず新たな問題を生み出す結果となりました。さらにその次に、二つ目のソリューションが生み出した新たな問題を解決するため、さらに別の3つ目のソリューションが考案されましたが、これもまた新たな別の問題を生み出し、その繰り返しが続いたという結果になりました。結果として今ある標準化された失効のソリューションは（私の意見では）不完全なままの状態となっています。この状況を受け、その後証明書の無効化に関するソリューションの方向性は全く別のものに変わっていきました（が、これもまた不完全な状態となっています）。この点については、このブログの後半で説明します。これは理屈の上ではうまくいくが、諸々の理由により現実ではうまくいかないソリューションの一例では、というのが私の見解です。

今回のブログの大部分では、ユースケースとしてインターネットブラウザとウェブサーバー間のTLSセッション設定を例としています。その点ではV2X通信とは直接の関係が薄い説明となりますが、問題の本質はV-PKIシステムにも同様に適用されるものです。

インターネットブラウザ（Chrome、Edge、Firefoxなど）における証明書の無効化のチェックでは、各ブラウザベンダーが独自の解決策を実装し始めたため、状況はかなり複雑化してしました。「ちゃんと機能するソリューションを実装する」という意味では各ベンダーのやらんとすることは同じです。そのため、目的は似ているものの手法が異なり、結果としてブラウザー間の互換性はない、という状況に陥ってしまいました。現在、ブラウザベンダーは標準化されたソリューションをほぼ無視し、証明書の失効チェックの実装においては自分たち独自のやり方で主導権を握っているという状況となっており、これは今後も多分変わらないのではと思われます（ブラウザーのソリューションは、基本的に証明書の失効の情報をブラウザーのソフトそのものの一部とし、ソフトウェア更新としてブラウザに定期的にプッシュするという方式になっています）。

証明書失効の過去の経緯は次の図のように示されます。これに関する詳細な議論はこちらの論文を参照ください。本ブログでは、詳細にはあまり踏み込まず、大雑把な説明に留めます。

Certificate Revocation List (CRL)

一番最初の証明書無効化のメカニズムは証明書失効リスト（CRL）と呼ばれます。このソリューションでは、認証局（CA）が定期的に失効された証明書のリストを生成し、それを証明書利用者に提供します。CRLの問題点には以下のものが挙げられます：(1)スケーラビリティ、(2)可用性、(3)適時性、(4)証明書ユーザー依存の取得：

スケーラビリティー： その性質上、CRLは巨大化する可能性がある。そのため、過去から現在までに複数のCRLをダウンロードすると、ユーザー側でのストレージを使うこととなり、その維持や管理が必要となります。端的に言ってにスケーラブルではないものである、と言えます。ブラウザーの場合では、失効した証明書に対応するウェブサイトにアクセスしない限り、CRLに関する一連の処理は単に無駄な労力に終わることになります。
可用性： CRLサーバーに接続しようとした際、サーバーが応答しないまたは利用不可の場合、CRLはダウンロードできません（「しばらくしてから再度お試しください…」の状況になります　:-o）。
適時性： CRLの内容が最新でない場合、その内容は信頼性を欠くものになります。ユーザー（ブラウザ）が最新であると思ってそのCRLを使い証明書の有効性を判断した場合、誤った判断を下す可能性があるということになります。例えば、最新のCRLがたまたま3日前に生成されたものだったとします。ということは、そのCRLが作られた後から今までの過去3日間に発生した失効のイベントはそれには反映されていない、ということになります。例えば、ある特定の証明書が昨日失効した場合、そのCRL上では「失効されていない」（まだ有効である）、ということになります。つまり、最新の情報ではなく、古い情報を参照しているための「ずれ」が生ずるという結果になります。
ユーザー依存性： 最新のCRLがあるとしても、それをダウンロードしなければ当然最新の情報は見れません。また、前述と同様のCRLの生成とダウンロードをする時間的な「ずれ」の問題も生じます。

Online Certificate Status Protocol (OCSP)

上記のCRLの問題への対処としてOCSPが規定されました（ただし、対処されているのはスケーラビリティの側面のみ）。また証明書利用者（ウエブブラウザー等）が必要なチェックを始めねばならない状況は依然として変わりありません。

ブラウザの場合では、ウェブサイトにアクセスしようとした時に起動される「TLSハンドシェイク」中に、ウェブサーバーがブラウザーに対してサーバーの証明書を発行します。その後、ブラウザは「OCSPレスポンダー」（証明書の失効状態を管理するサーバー）に問い合わせ、ウェブサーバーから受け取ったサーバー証明書がまだ有効かどうかを確認します。応答は「有効・無効・不明」（OCSP仕様では「good/revoked/unknown」）のいずれかとなります。

OCSPの利点は前述したスケーラビリティの問題を解決することです。つまり、CRLを盲目的にダウンロードして後で必要に応じてチェックするのではなく、特定の単一の証明書のステータスを問い合わせるようになります。しかし、その証明書の失効ステータスチェックを起動する責任は依然としてブラウザー側にあります。さらに、このアプローチは新たなプライバシー問題も生じさせる結果となります。「OCSPレスポンダー」で特定のウェブサイトの失効ステータスを確認するため、ユーザー自身の閲覧行動を実質的に露呈する結果になります。例えばあなたがアダルト向けのサイトにアクセスしようとした場合、「OCSPレスポンダーさん、xxx.comにアクセスしようとしていますが、この証明書はまだ有効ですか？」と言っているのと同じことになります。これによりレスポンダーにあなたが当該サイトへアクセスしていることがバレてしまいます。レスポンダーはあなたの名前はしらないかもしれませんが、その依頼が来た元のIPアドレスはわかるため、ある特定のプライバシー関連情報（例：位置情報（住所）や閲覧行動）が漏洩する可能性がある、ということを意味します［注：VPNやTorなどの技術で位置情報を偽装することは可能ですが、それはまた別の話です…］。

OCSPのもう一つの問題は、証明書ユーザーとレスポンダー間のOCSPのやりとりが「ブロッキングイベント」である点です。つまり、レスポンダーがリクエストに応答しない場合、ブラウザは待たざるを得ません。結果として、ユーザーはウェブサイトのコンテンツではなく空白の画面に遭遇することになりかねません。これは控えめに言ってもこ良いユーザー体験とは言えません（ユーザーから見たこのような動作はユーザーの印象を悪くし、ひいては市場シェアに影響を与える可能性があるため、ブラウザーベンダーとしてもその点は気にするのでは、と思います）。この問題に対処するため、ブラウザベンダーはタイマーを設定し、この「応答なし」状態を無視するロジックを組み込みました。いわゆる「ソフトフェイル」と呼ばれるものです。このソフトフェイルでは、ブラウザはレスポンダーの応答を待機するタイマーを設定し、タイムアウトが発生した場合はすべてが正常であるとみなし、何もなかったかのごとく画面上にウェブサイトのコンテンツを表示します。言い換えれば「応答なし」状態を無視していることになります。私の個人的意見では「？？？」と思ってしまうことですが。エラー状態を無視するのであれば、そもそも何のためにチェックをしたのか？と思ってしまいます。しかし残念ながら、ブラウザベンダーはセキュリティメカニズムよりもユーザー体験を重視しているようです（少なくとも私にはそのように思われます）。やっぱりユーザーの観点からはブラウザーの「サクサク感」が重要な点であることは否めないと思います。

OCSP Stapling

このようにOCSPはCRLのある問題に対処する一方で新たな問題を生み出す結果となりました。この状況に対する次の解決策が、いわゆる「OCSPステープリング」と呼ばれるものです。その名が示す通り、これは前述の本来のOCSPの拡張版と言えるものです。

このソリューションは前述のプライバシー関連の問題に対処したものです。具体的には、証明書の所有者（例：ウエブサーバー）が、TLSセッション確立時に自発的にOCSPレスポンダーの検証結果を証明書に添付してブラウザーに送ります。これにより、ブラウザーはレスポンダに自分から証明書の失効如何を問い合わせる必要がなくなり、自身の閲覧来歴を漏らすことがなくなります。この「ステープリング」は、証明書の所有者が証明書とその失効チェック結果を「ホチキスで留める」ように結合し、証明書利用者（ユーザー、つまりブラウザー）に提供するという比喩です。言い換えれば、OCSPステープリングはOCSPでの立場を逆転させ、証明書所有者（ウエブサーバー）にOCSPレスポンダとの証明書ステータス確認をする責任を負わせたわけです。これによりユーザー（ブラウザー）は証明書の失効チェックについては何もしなくてよくなった、ということになります。

OCSP Must-Staple

OCSP Stapleからさらに一歩踏み込んだものとして、OCSP 「Must-Staple」オプションでは、証明書の保有者（ウエブサーバー）が前述のOCSPステープルソリューションをサポートすることを必須とします。これは本質的に、従来のOCSPでは証明書利用者（ブラウザー）が負担していたレスポンダーとのOCSPチェックの処理を、ウェブサーバーに負担させることを義務付けるものです。これは当然の結果として、ウェブホスト側の負荷が増えることになります。このソリューションがウェブサーバーであまり普及していないとしてもそれほど驚くべきことではないのでは、と思います。

証明書の失効に関する根本的な問題

ここまで、過去の証明書失効チェック機能について議論しました。しかし、根本的な問題は未解決のままとなっています。その理由は、失効チェックの考え方が「ブラックリストをベースにしたアプローチ」であるということにあります。失効のチェックでは、「この証明書は失効しているか否か？」という質問をします。答えは「Yes」か「No」かのどちらかです。答えが「Yes」であれば、それは失効しており、それ以外に曖昧さや誤解の余地はありません。しかし、答えが「No」の場合、それはどのように理解するべきでしょうか？　一見「No=まだ有効である」ことを意味すると思いがちかもですが、必ずしもそうとは限りません。この質問の仕方は、否定的な応答を得た際に曖昧さを生じさせる結果となります。たとえ否定的な応答を得たとしても、それを伝えた側（CRLやOCSPレスポンダー）が実際に失効していることを（まだ）知らない可能性があります。これはCRLのところで議論したタイミングの「ずれ」の問題です。したがって、質問を投げる相手が本当（最新）の情報を基にして回答しているかどうか確信できない相手に質問すること自体が疑念を生む原因である、ということになります。さらに、OCSPレスポンダから「不明」という回答を得た場合、どう対応すべきでしょうか？　そのような状況（例：サーバーの応答なし状態）を想定してこのような第三の答えを定義する必要があることは容易に想像できます。しかしながら、これは曖昧さを助長するという意味であまり良いプロトコル設計とは言えないのではないか、と思ってしまいます。

短期型証明書への移行

この一連の試行錯誤を経て、標準化団体（IETF)は証明書の失効問題について全く違った方向に舵を切ることにしたようです。これでは、リアルタイム（または準リアルタイム）での精度の高い有効性の検証を行う代りに、新たな方向性として証明書の有効期間を短く設定し、この短い期間後が経過したあとに自然消滅（失効）する、というアプローチを採用したようです。TLS設定の証明書での主流となっている有効期間は90日間ですが、当該の標準仕様ではこれを数日間（4日間前後）まで短縮することを推奨しています。この4日間という数字はOCSP応答の有効期間と同値です。つまり、この短期証明書は積極的な有効性のチェックを伴わずにOCSPの動作を再現しようとするものとも言えます。

このアプローチは「短期自動更新型」（Short-Term, Automatically Renewed（STAR））と呼ばれ、「自動証明書管理環境」（Automatic Certificate Management Environment（ACME））メカニズムに基づいたものです。ちなみにACMEはウェブサーバーへの証明書発行を人手を介さず自動化で行えるようにする機能です。

つまり、短期証明書の考え方とは、何かの事情で証明書を無効にする必要がある場合でも何もする必要はなく、最大で約4日間ただ時間の経過を待っていれば、その証明書は自然に期限切れになり消えていく、ということになります。わざわざ証明書を失効させる努力をする必要もなく、非常にシンプルな考え方であり、実際、良い解決策のように思えます。結局のところ、これで失効に関わる処理という厄介な作業から解放されるということになります。

しかし有効期間の短縮は、CAが以前よりも短い間隔（90日から4日への短縮）により、より多くの証明書を発行しなければならないことを意味します。認証局（CA）にとってはより多くの証明書を生成する作業が増え、証明書所有者（ウエブサーバー等）にとってはそれらを転送・保管・使用・廃棄する作業が増える結果となります。証明書利用者（ブラウザー）も、所有者から新しい証明書を受け取るたびに期限切れのものを廃棄することになります。現実世界の物理的な「もの」に例えるなら、これは今までより大量のゴミを生み出すことに相当すると言えると思います。

この短期証明書は認証局（CA）と証明書所有者（ウエブサーバー）に余計な作業を強いるため、先の論文で議論されているように、現実には（まったく）普及していないのもある意味では当然とも思われます。

V-PKIシステム（自動車通信（V2X））での証明書の使い方

自動車通信でのV-PKIシステムでは前述の短期証明書のアプローチを採用しています。ウェブトラフィック（TLS）利用における普及の遅れにより、あるいは自動車通信（V2X）がこのアプローチを実際に実装する最初のシステムとなる可能性があると思われます。

V-PKI/V2Xシステムにおいて、V-PKIは複数の短期証明書を生成・発行して車両に配布します。これら証明書は所定の期間内に同時に有効となる証明書の「束」として車両に割り当てられることになります（文献によっては7日間有効な20個の証明書、等の例が示されていますが、標準化としての具体的な数や有効期限の定義はありません）。これにより車両は有効期間中に定期的に証明書を使いまわすことが可能となります。一つの使い方として、車両が数分単位で証明書を別のものに切り替え、このプロセスを繰り返すことになります。その後、1週間（7日間）が経過すると、これらの証明書は有効期限切れとなり、車両はこれらを破棄します。その後V-PKIシステムから新たな証明書セットを取得し、この動作が繰り返されることになります。

この短期間有効な証明書をリサイクルする使い方の背景としては、車両の特定化や追跡することを困難にすることで、ユーザー（車両所有者）のプライバシーを保護することにあります。それぞれの証明書には固有のIDや公開鍵が付与されているため、別の証明書に替えることにより、さっきまでの通信との関連性はなくなり、車両（所有者とその位置、所在、移動パターンなど）の特定化と追跡を防げる、という意図です。端的なたとえを使えば、複数の仮面をとっかえひっかえしていればさっきの私と今の私が同一人物とはわからないでしょ？、ということです。簡単な例を挙げれば、車両が夜間や週の間の日中に留まっている場所は、それぞれがその車両の所有者の家と職場である可能性が高い、ということが推測されますが、それぞれ関連性のない証明書に替えることでプライバシーが保たれる、という考え方です。

V2Xにおける証明書失効については、前節で述べたように、短期証明書の失効処理はされません。その有効期間が経過した結果、自然に失効するので、仮に失効させなければならないような状況が生じた場合もそのまま放置するに任せるということになります。ただ、車両自体の（ハッキング等による）挙動不審や不正行為などの状況が生じた場合には、V-PKIシステムが次回以降の証明書の発行をしない、という処置をすることで当該の車両がV2X通信から締め出される、ということになります。

これらの不正行為の検知やプライバシー保護の仕組みはそれ自体がテーマとなるため、今後のブログで別途取り上げる予定です。次回のブログでは、不正行為検知に関する私の意見を述べる予定でいます。