ライフライン通信の受信と検証

2.4.1 発信者情報通知の受信

ライフライン通信のリクエストを受けた着信側端末の画面例を図5.3にて示す。

この例では、緊急通報型となっていて、ライフラインサービス機関して仮想的な警 察が着信側であり、発信側で指定したSIPアドレスsip:[email protected] を受理する着信側端末となっている。なお、緊急通報型以外においても、以下の 説明は同様となる。

今回の実証実験例では、このSIPアドレスsip:[email protected] で呼 び出されて着信できる端末は簡単に一つだけとなっているが、一般的な運用では、

SIPが持つ標準的な機能にて、複数の端末へと着信を振り分けて、ライフライン 通信リクエストを受信することができる。

図5.3の着信側端末において、行03から行05におけるSIPによるINVITEリク エストと呼び出し確認は、図5.2の発信側端末における、行13から行15における

SIPによるINVITEリクエストと呼び出し確認と、送信（Send）と受信（Recv）

がちょうど入れ替わって逆になっているだけで、全く同じものとなっている。ま た、図5.3の着信側端末においての、行06と行07におけるGPS情報と、行08と 行10における地理的位置情報証明書と、行11と行13におけるユーザ情報証明書

の通知についても、同様に、図5.2の発信側端末での行24から行29が対応して いる。

図 5.3 着信側の端末画面

2.4.2 地理的位置情報証明書の検証

このようにして各情報の通知を受けた接続先（この例では緊急通報先のライフ ラインサービス機関）である着信側においては、各情報の通知を受けたあと、各 証明書が正当であるかどうかの検証を行なう。

図5.3の行09の Verify OKの行は、行08で通知を受けた地理的位置情報証明 書の検証結果がOKであったことを示している。これにより、行10において発信 側端末へOKを返している。検証結果は、この行09をクリックすることで見る ことができ、これを、図5.4にて示す。ここには、地理的位置情報証明書で得ら

れたデータ内容と、GPS情報で得られたデータ内容と、地理的位置情報証明書が 正当であるかどうかの検証結果の三つが示されている。

図 5.4 地理的位置情報証明書の検証

この地理的位置情報証明書の検証は、第4章第2.3節で示した図4.3のアルゴ リズムにて行なう。まず、通知を受けた地理的位置情報証明書に対し、地理的位 置情報証明のためのIPアドレス空間管理のルートCAからたどることで証明書 の署名者、すなわち、この証明書を発行した地理的位置情報管理サーバの正当性 を検証できる。これにより、地理的位置情報証明書が正規に発行されたものであ ると確認される。

なお、地理的位置情報証明書自体は使い捨て型であるため証明書失効リストは 存在しないが、IPアドレス空間公開鍵証明書のほうはIPアドレス空間の割り当 てを受けている間のみ有効とするため、root CAによる証明書失効リストの発行 と、この検証過程における検査が必要となる。

その次に、地理的位置情報証明書に書かれているデータに対して検証を行なう。

まず、時刻情報が、発信側との通信開始時刻よりも以降であることを確認する。

次に、IPアドレス（図5.5における 2001:200:169:242:20）が、発信側のIPアド レスと一致することを確認する。そして、このIPアドレスが、地理的位置情報 証明書の署名者、すなわち、この証明書を発行した地理的位置情報管理サーバが 管轄するIPアドレス空間（図5.5における2001:200:169::/48）の中に入っている かどうかを確認する。これらを確認した上で問題なければ、発信側の地理的位置 情報を確かなものとして入手利用することができる。

なお、通知で受け取ったGPS情報については、その性質から発信側による自 己申告されたデータに過ぎないものであるが、地理的位置情報証明書によって示 されている保証されたおおよその地理的位置情報のデータと比較することで、全 く異なる場所からの詐称などを防ぐことができる。

2.4.3 ユーザ情報証明書の検証

図5.3の行12の Verify OKの行は、行11で通知を受けたユーザ情報証明書の 検証結果がOKであったことを示している。これにより、行13において発信側端 末へOKを返している。検証結果は、この行12をクリックすることで見ること ができ、これを、図5.5にて示す。ここには、ユーザ情報証明書で得られたデー タ内容と、ユーザ情報証明書が正当であるかどうかの検証結果の二つが示されて いる。

このユーザ情報証明書の検証は、第4章第3.2節で示した図4.6のアルゴリズム にて行なう。まず、通知を受けたユーザ情報証明書に対し、ユーザ情報証明のた めのドメイン管理のルートCAからたどることで証明書の署名者、すなわち、こ の証明書を発行したユーザ情報管理サーバの正当性を検証できる。これにより、

ユーザ情報証明書が正規に発行されたものであると確認される。

なお、ユーザ情報証明書自体は使い捨て型であるため証明書失効リストは存在 しないが、ドメイン名公開鍵証明書のほうはドメイン名の割り当てを受けている 間のみ有効とするため、root CAによる証明書失効リストの発行と、この検証過 程における検査が必要となる。

その次に、ユーザ情報証明書に書かれているデータに対して検証を行なう。ま

図 5.5 ユーザ情報証明書の検証

ず、時刻情報が、発信側との通信開始時刻よりも以降であることを確認する。次に、

IPアドレス（図5.5における2001:200:169:242:20）が、発信側のIPアドレスと一 致することを確認する。また、ユーザアドレス（図5.5における[email protected]）

が、発信側のユーザアドレスと一致することを確認する。そして、このユーザア ドレスが、ユーザ情報証明書の署名者、すなわち、この証明書を発行したユーザ 情報管理サーバが管轄するドメイン名（図5.5におけるtest.demo）の中に入って いるかどうかを確認する。これらを確認した上で問題なければ、発信側のユーザ 情報を確かなものとして入手利用することができる。

これら、両証明書の検証とその結果に対する実際の運用方法としては、着信側 であるライフラインサービス機関側などの通信相手の方針に応じて様々な運用方 法が考えられる。例えば、各情報の通知を待たず、ライフライン通信リクエスト を受理して通信確立するといった方法や、検証結果に関わらず参考データとして みて、通信確立するといった方法もありうる。今回の例のにおいては、もっとも 厳しい運用方法として、発信側の地理的位置情報とユーザ情報が正しく通知され てきているのを確認をしてから初めて、ライフライン通信リクエストを受理する といった運用方法となっている。すなわち、検証の成功をもってはじめて、図5.3 の行15のように、SIPのINVITEリクエストに対するOKを送信している。