Author: takahitoyoshizawa

前回のブログでは、一般的な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通信から締め出される、ということになります。

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

このブログでは、自動車通信（V2X)向けのデジタル証明書を発行するバックエンドシステムであるV-PKIシステムについて解説します。

前回のブログでは、デジタル証明書と、署名アルゴリズムや公開鍵暗号技術とを組み合わせて送信者の真正性とコンテンツの完全性を保証する方法について説明しました。その議論の最後に、受信側（ボブ）が最初にデジタル証明書をどのように入手するのかという疑問を提起しました。今回のブログでは、その背後にある仕組みについて解説します。

デジタル証明書は、ウェブトラフィックを暗号化するためのセッションキー確立（「https」または「TLS」）を含む、様々な目的で使用されています。実際、V2X通信はこのPKIの枠組みを基にして、V2X用にシステムを再定義しているものと言えます。

パブリックキーインフラストラクチャー（PKI）

公開鍵基盤（PKI）とはデジタル証明書を管理するバックエンドシステムです。「管理」という言葉には、証明書の生成、配信、配布、使用、失効、およびその他の関連機能が含まれます。概念的には、データベース操作におけるCRUD（作成、読み取り、更新、削除）に相当するのもであると考えます。言ってみれば、デジタル証明書に関する一種の「ライフサイクル管理システム」とも言えます。名称が示す通り、PKIはデジタル証明書の利用を可能にする基盤（ハードウェア、ソフトウェア、手順／プロトコル、ポリシー／ルール、基盤となる通信など）から構成されるものです。

PKIシステムは、認証局（CA）と呼ばれる複数のエンティティで構成されます。これらは階層的に定義されており、最上位のものは「ルートCA」（RCA）と呼ばれます。RCAの1つ下のレベルには1つまたはそれ以上の「中間CA」（ICA）が存在し、そのさらに下のレベルは「発行CA」と呼ばれ、「エンドエンティティ」（証明書の利用者）に対して証明書を生成します。下図でこの階層的概念を示します。

一つのレベルで発行された証明書は、その一つ下のレベルのエンティティの真正性を保証します。例えば、RCA（証明書の「発行者」）がICAに発行する証明書は、ICA（証明書「保持者」）の真正性を保証します。同様に、この保証の連鎖は次のレベルで行われ、最終的なエンティティ（インターネットのウェブサイトの場合では、TLS/SSLを実行するWebサーバー）に至るまで続きます。RCAの信頼性は事前に担保されており、それがこのPKI概念の本質的な点です。証明書のつながりによって定義されたこの信頼関係は、「信頼の連鎖」と呼ばれます。言い換えれば、PKIシステムは本質的に、証明書内の公開鍵をその所有者に結びつける仕組みである、と言えます。

V-PKIシステム

自動車通信（V2X）では、この一般的なPKIフレームワークを基にして、車両への証明書発行の目的に特化したものとなっており、ここでは「V-PKIシステム」と呼ぶことにします。V-PKIシステムでは、中間認証局（ICA）は特に定義されてはおらず、登録機関（RA）と認可機関（AA）の二つのエンティティが定義されています。RAとAAの両者は自身の真正性を保証するため、RCAから独自の証明書を発行されます。

RAとAAのうち、後者がV-PKIシステムへの車両の登録時にAAが車両に対して証明書を発行する機能を有するものであるため「発行CA」となります。これはです。前者のRAは、ETSI ITS規格で規定された通信プロトコルに基づく登録手続きを通じて、エンドエンティティ（この場合は車両）をV-PKIシステムに登録する機能を有します。前述の通り、RAへの車両の登録が成功した後に、AAが車両に対して証明書を発行します。以下の図でETSI定義のV-PKIアーキテクチャでこの関係性を示します。

米国の仕様として、同等のV-PKIアーキテクチャがIEEE 1609.2で定義されています。ETSIのC-ITSアーキテクチャは実はこれを基にして定義したものという背景があります。下図に示すように、IEEE 1609.2アーキテクチャではより多くのシステムエンティティが定義され、それらの間の相互関係もより複雑化したものとなっています。このより複雑なアーキテクチャを採用した根本的な考え方として、いかなるシステムエンティティも単独（他のエンティティと共謀せずには）では車両（およびその所有者）を特定できないようにすることで、車両のプライバシーと匿名性を担保する、という考えが反映されたものと言えます。複数エンティティに渡る機能の分割や、情報のアクセスを制限することでその目的が達せられます。

異常動作の検出と証明書の無効化

証明書発行（エンドエンティティへの証明書発行を含む）に加え、PKIシステムが提供する重要な機能として証明書の無効化の機能があります。デジタル証明書は様々な理由で無効化されることがあります。例えばウェブホストの場合では、ウェブサーバーがハッカーにより乗っ取られたり、ウェブサイト自体が閉鎖されたり、それを運営する会社が倒産・廃業したり、あるいは他社による事業買収などにより会社自体が存在しなくなった場合、などが証明書の無効化の理由となります。

V-PKIシステムにおいて、車両がハッカーなどに乗っ取られた場合には、周辺車両を惑わすような誤った情報を送信するなど、道路の安全性に悪影響を及ぼす原因となり得ます。よって当該車両に発行された証明書は迅速に無効化されなければなりません。この場合には、乗っ取られた車両を通信チャネル上から排除する必要が生じますが、当該車両に発行された証明書を無効化することで対応する、ということになります。

ある特定の車両が無効化されたことを正しく認識している他車両は、無効化された証明書を所有する車両が送信するすべてのメッセージを検知し、それらメッセージを無視することでその悪影響を排除することができます。これにより、周囲の車両は当該車両から送信される誤解を招く可能性のある情報や誤った情報から自らを保護できということになります。

少なくとも理屈の上ではこうなりますが、現実にはそれほど単純な話ではないと考えます。次回のブログでは、この難しさについてさらに掘り下げて話を進めていきます。

前回のブログに続き、このブログではV2X通信のセキュリティーのソリューションについて話をします。

前回のブログでは、自動車通信の背景についての話をし、その道路の安全に関わる「基本サービス」がブロードキャストで平文（暗号化なし）である必然性について説明しました。つまりV2Xの基本サービスは通信距離内の受信するものすべてに対して平文をそのまま垂れ流し、ということになります。これはセキュリティーの観点からみて到底セキュアなものとは言えません。結局このような通信形態では、受信できるデバイスであればまともなものか悪意のあるものかどうかに関わらず（リアルタイム、あるいは事後に関わらず）メッセージを受信・保持・分析できてしまう、ということになります。更に、V2Xの通信チャネル上で送信できるデバイスはまともなものか如何に関わらず送信できてしまう、ということになります。

言い換えれば、V2X通信の道路安全に関わる「基本サービス」は傍受やありもしない虚偽のメッセージの送信は何でもありのやりたい放題、の状況ともいえます。

この状況はセキュリティの観点から見て明らかに問題ありです。したがって、この環境でセキュア性を担保するには少なくとも以下の点が必要となります　ー　(1) メッセージが（悪意のある偽のものではなく）本物の車両によって送信されていることが確認できること、(2) メッセージの内容が改ざんなどがされていないこと。これにより、受信する側は少なくとも送信する車両の真正性とメッセージの完全性を検証できることになります。

これを実現する策としては、公開鍵基盤（Public Key Infrastructure, PKI）によって発行されたデジタル署名を使用して上記の2点の担保をすることとなります。言い換えれば、V2X通信における「基本サービス」における唯一のセキュリティ対策としては、これら2点のみを検証することだけである、と言えます。

もちろん、V2X通信には道路安全の「基本サービス」以外のサービスもあります。これには遠隔運転やプラトーニング等が含まれます。これらの付加価値的サービスでは、ユニキャストまたはマルチキャストのいずれかが使え、実際、遠隔運転はおそらくV2Xにおいてユニキャストが使用される数少ないユースケースの一つであると考えられます。そのような場合、通信の機密性を保証するために暗号化が適用できます。しかしそのような場合にも、デジタル署名を用いたメッセージの完全性は、V2X通信のセキュリティにとって重要な要素であります。

デジタル証明書

デジタル署名は受信する側がそれをチェックすることによりメッセージが改ざんされていないことを保証します（メッセージが改ざんされていないことの確認）。これには、楕円曲線デジタル署名アルゴリズム（Elliptic Curve Digital Signature Algorithm, ECDSA）などの公開鍵暗号方式（Public Key Cryptography, PKC）が使用されます。

PKC（公開鍵暗号方式）では、公開鍵と秘密鍵という2つの鍵を使用します。言ってみれば、これら2つの鍵は鏡の表裏のような関係にあります。暗号化と復号化には異なる鍵を使うことになります。署名の生成においても同様の原理が適用され、署名生成に使用される鍵と検証に使用される鍵は異なる、ということになります。以下の図はこのメカニズムを説明しています。

この図では、アリスがボブにメッセージを送信する状況を考えます。アリスは、送信するメッセージを生成した後、そのメッセージと秘密鍵（しばしば「Secret Key」を意味するskで表記される）を署名生成アルゴリズム（例えばECDSA）に入力し、署名を生成する。アリスはメッセージに生成された署名を添えてボブに送信する。

このメッセージ（署名を含む）をボブが受信すると、彼はまずメッセージ部分を取り出し、公開鍵（しばしば「Public Key」を意味するpkで表記される）とともにアルゴリズムに入力します。その結果得られる署名を署名’（「プライム」）とします。最後に、ボブは受信したメッセージに添付された署名と計算された署名’を比較し、もし両者が一致すれば、ボブは受信したメッセージが改ざんされていないことを確認できます。逆にそれらの値が一致しなければ改ざんされた可能性があるものと判断し、メッセージを破棄します。

ここまでで、とりあえずデジタル署名の使い方とその確認の仕方を説明しました。ただ、ここで問題となるのは、そもそもボブがどうやってアリスの公開鍵を入手したかということになります。ここで登場するのがPKIですが、その説明にはそれ単独のブログ記事が必要であろうと思われますので次回のブログでその議論をすることにします。

このトピックに関する一連のブログは、車載通信（V2X）（所謂コネクテッド・インテリジェント交通システム（C-ITS））のセキュリティとプライバシーに関するものです。しかし、セキュリティとプライバシーについて語る前にそのソリューションがなぜそうなっているのかという背景について説明する必要がありますので、その辺りのところからの説明をまずしたいと思います。

V2X 通信の基本サービスとは？

V2X 通信には複数の用途（ユースケース）があります。その目的として、車両に「通信」要素を取り入れることで、道路の安全性を向上させることとなります（便宜上これを「基本サービス」と呼ぶことにします）。これとは対照的に、遠隔運転のようなより高度な付加価値をもたらすユースケースも存在します。ここでは前者の「基本サービス」に焦点を当て、後者のより付加価値的なユースケースは除外することにします。

「基本サービス」には以下の代表的な 2 種類があります。

• 協調的認識（Cooperative Awareness）
• 安全に影響を与える可能性のある状況の通知/警告（Warning / Alerting）

最初のケース（協調的認識）では、車両の動きに関する情報および関連する以下のような情報を送信することにより、自身の存在と動きを通信距離内の他の車両にシェアします。

• 速度
• 方向
• 加速度
• 位置
• その他の関連メタデータ（車両タイプ、物理的サイズなど）

すべての車両が、自身の情報を通信範囲内の他のすべての車両と共有することで、最終的には、すべての車両が周囲の状況（存在する車両の数、その方向や速度など）を認識して把握することになります。自動車は動くものであり、この周囲の状況認識は刻々と変化するので、これは「ダイナミックマップ」と呼ばれます。

これらの情報は、道路上の潜在的な危険な状況（差し迫った衝突など）を検知するのに役立ちます。従来の人間が運転する車両では、この情報はダッシュボードなどにメッセージを表示することで、ドライバーへの警告や注意喚起を引き起こすことができます。自動運転車両（AV）では、この情報は車両の動きを決める上での情報の一つとして使うことができます。

第二のケース（危険な状況の通知）には、周辺車両への警告や注意喚起が必要な状況が含まれます。これには、緊急車両の接近、路肩に停車中の車両、前方渋滞などの事象があります。車両はこれらのメッセージをホップバイホップで伝播させることができ、それにより警告や注意喚起を広いエリアに知らせることができます。

第一のケース（協調的認識（Cooperative Awareness））では、メッセージが刻一刻と変わる車両周辺の動きを正確に反映するために定期的に送信されます。他方、第二のケース（Warning / Alerting）では、警告または通知メッセージは関連する条件が発生した時のみに送信される非定期的な性格のものとなります。

「運用環境」としての自動車通信

車両は本来道路を移動するものです。この自動車の基本的な特徴が、自動車通信を特殊な運用環境にしていると言えます。他にも、携帯電話システム（あるいはWi-Fi）のような無線通信を使い、利用者の移動を伴うシステムは存在します。しかし自動車通信（V2X）がこれらと一線を画すのは、道路安全に関わるリアルタイムシステム（RTS）、つまり「不具合が起こったら事故につながる」という点であるといえます。言い換えれば、V2Xを導入する根本的な目的は道路の安全性を向上させることにあり、その目標を達成できなければ、導入する意味はないと言えると思います。

セキュリティの観点からの意味とは？

ある車両が道路上を移動する中では、様々な方向や速度で移動する不特定多数の誰のものかわからない未知の車両と遭遇することになります。これら他の車両は、その数、進行方向、場所、道路の種類、時間帯、気象条件などの要因によって変動するものです。例えば大都市の平日のラッシュアワーの幹線道路と、日曜日の午前3時の田舎町の一本道では状況が全く異なることが言えます。

この運用環境のため、協調型認識（Cooperative Awareness）および通知／警告（Warning / Alerting）メッセージはブロードキャスト方式で平文で送信されることになります。つまり、周りの全車両へ平文（暗号化）なしでブロードキャストで送信されることになります（注1参照）。極論を言えば、しかるべき受信機能を備えた装置は、誰が所有するどのようなものでさえ、それらメッセージを受信・保存・分析することができてしまう、といえます。この通信方式（平文のブロードキャスト送信）が、セキュリティ対策の実現に制約を課すということになります。

以上が自動車通信（V2X）のセキュリティとプライバシーの背景となります。次回のブログでは、この動作環境に対するソリューションについて掘り下げて行きたいと思います。

[注1:] グループ通信における暗号化を行う方式は存在しますが、そのグループメンバー内での暗号鍵の分配と管理を動的に行う必要があります。自動車の場合は、道路上を動き、不特定多数の車両と遭遇し、それらが刻々と変化するような動作環境では、暗号化鍵を配布・調整・管理することは現実的ではないと考えます。

This is about Zero-Knowledge Proof (ZKP). Content will be coming soon…

This is mostly about certificate validity checking and its variations among different browsers and their behaviors…