(57)【要約】【課題】  インターネットで通信する装置の中には、複雑な操作や厳重な管理を期待することが困難だと思われる装置も考えられ、必ずしも計算能力や記憶容量が大きいとは限らない。【解決手段】  Ｉｎｉｔｉａｔｏｒは、Ｒｅｓｐｏｎｄｅｒとの間で、ｙ＿ｉｒを共有し、ｙ＿ｉｒを元に、ＨＡＳＨ＿Ｉを計算し、ＨＡＳＨ＿Ｉを、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒに送信し、ＨＡＳＨ＿Ｉ及びＩｎｉｔｉａｔｏｒのアドレスに対して生成されたディジタル署名ＳＩＧ＿ＳをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒから受信し、ディジタル書名ＳＩＧ＿ＩをＲｅｓｐｏｎｄｅｒに送信する。【選択図】  図１
2005210285.tif 000002
【特許請求の範囲】
【請求項１】
通信装置であって、
データを生成する生成手段と、
ディジタル署名の発行装置に前記生成したデータを送信する通信手段とを有し、
前記通信手段は、前記生成したデータ及び当該通信装置が使用中のアドレスとに対して前記ディジタル署名の発行装置により発行されたディジタル署名を受信して、前記発行されたディジタル署名を通信相手に送信する送信することを特徴とする通信装置。
【請求項２】
前記生成手段は、鍵生成のために前記通信相手と交換したデータを元に、鍵及び前記データを生成し、前記通信手段は、前記発行されたディジタル書名を、前記鍵を用いて暗号化して、前記通信相手に送信することを特徴とする請求項１記載の通信装置。
【請求項３】
装置からの依頼に応じて暗号化に用いる秘密データを共有するための依頼計算を実行するステップと、
前記装置によって生成されるデータと前記装置が使用中のアドレスとに対してディジタル署名を生成し前記装置に発行するステップとを実行することを特徴とするディジタル署名発行方法。
【請求項４】
前記実行ステップでは、Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）実行中の装置が使用するＩＰアドレスを監視しながら前記装置の依頼に応じてＩＫＥにおけるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算を実行することを特徴とする請求項３記載のディジタル署名発行方法。
【請求項５】
前記発行ステップは、前記装置によって生成されるハッシュ値と前記装置が使用中のＩＰアドレスとに対してディジタル署名を生成し前記装置に発行することを特徴とする請求項３記載のディジタル署名発行方法。
【請求項６】
公開鍵と秘密鍵を有する装置が用いるＩＰアドレスと、前記公開鍵と、前記署名生成を行う装置であることを定義する情報をも含む公開鍵証明書を、ＩＫＥを実行する前記装置に提供することを特徴とする請求項３記載のディジタル署名発行方法。
【請求項７】
前記装置のデフォルトゲートウエイ上で実行されることを特徴とする請求項３記載のディジタル署名発行方法。
【請求項８】
第１の装置と暗号通信を行う第２の装置からデータを受信する受信ステップと、
前記受信したデータと前記第２の装置が使用しているアドレスに対して秘密鍵によりディジタル署名を生成する生成ステップと、
前記秘密鍵に対応する公開鍵の証明書、及び、前記生成したディジタル署名を前記第２の装置に送信する送信ステップとを実行することを特徴とするディジタル署名発行方法。
【請求項９】
第１の装置と暗号通信を行う第２の装置にディジタル署名を発行するディジタル署名発行装置であって、
前記第２の装置と通信する通信手段と、
前記第２の装置から受信したデータと前記第２の装置が使用しているアドレスに対して秘密鍵によりディジタル署名を生成する生成手段を有し、
前記通信手段は、前記秘密鍵に対応する公開鍵の証明書、及び、前記生成したディジタル署名を前記第２の装置に送信することを特徴とするディジタル署名発行装置。
【請求項１０】
通信装置が通信相手のディジタル署名を送信する送信方法であって、
前記通信相手との間で、秘密データを共有し、
前記秘密データを元に、ハッシュ値を計算し、
前記ハッシュ値を、ディジタル署名の発行装置に送信し、
前記ハッシュ値及び前記通信装置のアドレスに対して生成されたディジタル署名を前記ディジタル署名の発行装置から受信し、
前記ディジタル書名を前記通信相手に送信することを特徴とするディジタル署名送信方法。
【請求項１１】
請求項３から８のいずれか１項のディジタル署名発行方法又は請求項１０のディジタル署名の送信方法を実行するプログラム。
【請求項１２】
公開鍵と秘密鍵を有する装置が用いるＩＰアドレスと、前記公開鍵を証明書の内容として含む公開鍵証明書であって、請求項３記載のディジタル署名発行方法における前記署名生成を行う装置であることを定義する情報をも含むことを特徴とする公開鍵証明書。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ディジタル署名発行方法、ディジタル署名送信方法、及び、プログラムに関する。
【背景技術】
【０００２】
ＩＰｓｅｃは、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行うプロトコルであり、通信に際して秘密データやお互いのＩＰアドレス等を安全に共有する必要がある。秘密データやお互いのＩＰアドレス等のデータはＳＡ（Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎ）と呼ばれる。
【０００３】
ＳＡを安全に共有するプロトコルはＩＫＥ（Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ）と呼ばれ、ＲＦＣ２４０９“Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）”において規定されている。ＩＫＥでは秘密データを共有する方法としてＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式（以下、ＤＨと記す）が使われ、４つの認証方法が規定されている。１つの認証方法はｐｒｅ−ｓｈａｒｅｄ  ｋｅｙを用いるのでインターネットのように不特定多数の相手と通信する場合には適さない。残り３つの認証方法では公開鍵暗号を用いる。公開鍵はランダムに見える数値なので、ある公開鍵がどの装置に対応する公開鍵であるかを保証するために、公開鍵証明書が使われる。
【０００４】
つまり、ＩＫＥを用いてインターネットで不特定多数とＩＰｓｅｃを実行するためには、公開鍵証明書を発行された装置でなければならない。また、公開鍵に対応する秘密鍵およびＩＫＥの実行により生成される鍵は、装置のみが使用できるように安全に生成・管理されなければならない。
【０００５】
計算能力や記憶容量の制約を解決する一つの方法として、ＩＫＥを代行するサーバーを設ける方法が考えられる。例えば、特許文献１には、鍵交換代行サーバーがＤＨと認証を代行する方法が述べられている。しかし、この方法では、ＩＫＥの実行により生成される鍵と署名ペイロードを生成するために必要な秘密鍵の二つの鍵を鍵交換代行サーバーが知る。つまり、装置のみが使用できるように鍵が生成・管理されない。
【０００６】
従って、現在知られている方法としては、鍵を他に知られないために装置が証明書とＩＫＥを完全にサポートし単独で処理する方法か、鍵を別装置に知られることを許して証明書とＩＫＥの処理を別装置に代行させる方法が存在する。装置が単独処理せずに別装置に代行処理をさせるが鍵を知られずにすむ方法が存在すれば、その方法は既存の方法より装置を低コストで製作可能にし、かつセキュリティ上好ましいが、現在はそのような方法は知られていない。
【特許文献１】特開２００３−１７９５９２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、インターネットで通信する装置の中には、複雑な操作や厳重な管理を期待することが困難だと思われる装置も考えられ、必ずしも計算能力や記憶容量が大きいとは限らない。
【０００８】
本発明は、厳重な管理を必要とせずに、公開鍵暗号を使用可能とするものである。
【課題を解決するための手段】
【０００９】
本出願に関わる発明は、通信装置であって、データを生成する生成手段と、ディジタル署名の発行装置に前記生成したデータを送信する通信手段とを有し、前記通信手段は、前記生成したデータ及び当該通信装置が使用中のアドレスとに対して前記ディジタル署名の発行装置により発行されたディジタル署名を受信して、前記発行されたディジタル署名を通信相手に送信する送信することを特徴とする。
【００１０】
したがって、通信装置は、ディジタル署名を発行するための管理をしなくて済む。
【００１１】
また、本出願に関わる発明では、前記生成手段は、鍵生成のために前記通信相手と交換したデータを元に、鍵及び前記データを生成し、前記通信手段は、前記発行されたディジタル書名を、前記鍵を用いて暗号化して、前記通信相手に送信することを特徴とする。
【００１２】
したがって、通信相手が、前記データを交換した当該通信装置を認証することが可能になる。
【００１３】
また、本出願に関わる発明では、装置からの依頼に応じて暗号化に用いる秘密データを共有するための依頼計算を実行するステップと、前記装置によって生成されるデータと前記装置が使用中のアドレスとに対してディジタル署名を生成し前記装置に発行するステップとを実行することを特徴とする。
【００１４】
したがって、計算能力に乏しく、厳重な管理がされない装置に、秘密データの共有、及び、ディジタル署名の使用を可能とすることができる。
【００１５】
また、本出願に関わる発明では、装置が使用するＩＰアドレスを監視しながら、前記依頼計算、又は、ディジタル署名の発行を行うことを特徴とする。
【００１６】
したがって、なりすましを防止することができる。
【００１７】
また、本出願に関わる発明は、公開鍵と秘密鍵を有する装置が用いるＩＰアドレスと、前記公開鍵と、前記署名生成を行う装置であることを定義する情報をも含む公開鍵証明書を、ＩＫＥを実行する前記装置に提供することを特徴とする。
【００１８】
したがって、装置は証明書の被発行や管理の機能をサポートしなくてすむ。また、装置と通信する相手は、前記装置が使用しているＩＰアドレスの正当性を確認できる。
【００１９】
また、本出願に関わる発明では、依頼計算及びディジタル署名の発行を、デフォルトゲートウエイ上で実行することを特徴とする。
【００２０】
したがって、依頼計算及びディジタル署名の発行が簡単化される。
【発明の効果】
【００２１】
以上説明したように、本出願に関わる発明によれば、生成したデータ及び当該通信装置が使用中のアドレスとに対してディジタル署名の発行装置により発行されたディジタル署名を受信して、前記発行されたディジタル署名を通信相手に送信する送信するので、通信装置は、ディジタル署名を発行するための管理をしなくて済む。
【００２２】
また、鍵生成のために前記通信相手と交換したデータを元に、鍵及び前記データを生成し、前記発行されたディジタル書名を、前記鍵を用いて暗号化して、前記通信相手に送信するので、通信相手が、前記データを交換した当該通信装置を認証することが可能になる。
【００２３】
また、装置からの依頼に応じて暗号化に用いる秘密データを共有するための依頼計算を実行するステップと、前記装置によって生成されるデータと前記装置が使用中のアドレスとに対してディジタル署名を生成し前記装置に発行するステップとを実行するので、計算能力に乏しく、厳重な管理がされない装置に、秘密データの共有、及び、ディジタル署名の使用を可能とすることができる。
【００２４】
また、装置が使用するＩＰアドレスを監視しながら、前記依頼計算、又は、ディジタル署名の発行を行うので、なりすましを防止することができる。
【００２５】
また、公開鍵と秘密鍵を有する装置が用いるＩＰアドレスと、前記公開鍵と、前記署名生成を行う装置であることを定義する情報をも含む公開鍵証明書を、ＩＫＥを実行する前記装置に提供するので、装置は証明書の被発行や管理の機能をサポートしなくてすむ。また、装置と通信する相手は、前記装置が使用しているＩＰアドレスの正当性を確認できる。
【００２６】
また、依頼計算及びディジタル署名の発行を、デフォルトゲートウエイ上で実行することを特徴とする。
【００２７】
したがって、依頼計算及びディジタル署名の発行が簡単化される。
【００２８】
また、装置が使うＩＰアドレスの正当性を、証明書をサポートせずに通信相手に確認可能にするので、使用するＩＰアドレスを含む証明書を用意する必要がない。従って、ＩＰｖ６匿名アドレスのように短時間で使い捨てられるＩＰアドレスを使う場合にも対応可能である。
【発明を実施するための最良の形態】
【００２９】
発明を実施するための最良の形態を説明する。本形態の接続環境（図２）、装置の構成（図３）は、実施例１と共通である。図２、図３は、実施例１の説明において、詳述する。
【００３０】
本形態は、ホスト（通信装置）２０６が、ホスト（通信相手）２０９と通信する場合に、ホスト２０９との間で、秘密データを共有し、その秘密データを元に、ハッシュ値を計算し、そのハッシュ値を、ディジタル署名の発行装置であるｄｅｆａｕｌｔ  ｇａｔｅｗａｙ（ルーター）２０２又はホスト２０４に送信し、そのハッシュ値及びホスト２０６のアドレスに対して生成されたディジタル署名をｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２又はホスト２０４（ディジタル署名の発行装置）から受信し、そのディジタル書名をホスト２０９に送信する。
【００３１】
ディジタル署名の発行装置であるｄｅｆａｕｌｔ  ｇａｔｅｗａｙ（ルーター）２０２又はホスト２０４は、ホスト（第１の装置）２０９と暗号通信を行うホスト（第２の装置）２０６からデータを受信し、受信したデータとホスト２０６が使用しているアドレスに対して秘密鍵によりディジタル署名を生成し、秘密鍵に対応する公開鍵の証明書、及び、生成したディジタル署名をホスト２０６に送信する。
【００３２】
また、ディジタル署名の発行装置であるｄｅｆａｕｌｔ  ｇａｔｅｗａｙ（ルーター）２０２又はホスト２０４は、ホスト２０６からの依頼に応じて暗号化に用いる秘密データを共有するための依頼計算を実行する。
【００３３】
ホスト２０６は、図３のように構成され、データを生成するＣＰＵ（生成手段）３０３と、ディジタル署名の発行装置にその生成したデータを送信するネットワーク・インターフェイス（通信手段）３０１とを有する。ネットワーク・インターフェイス３０１は、その生成したデータ及びホスト２０６が使用中のアドレスとに対してディジタル署名の発行装置（ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２又はホスト２０４）により発行されたディジタル署名を受信して、その発行されたディジタル署名をホスト（通信相手）２０９に送信する送信する。
【００３４】
また、ホスト（第１の装置）２０９と暗号通信を行うホスト（第２の装置）２０６にディジタル署名を発行するディジタル署名発行装置であるｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２又はホスト２０４も、図３のように構成される。ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２は、ホスト２０６と通信するネットワーク・インターフェイス（通信手段）３０２を有し、ホスト２０４は、ホスト２０６と通信するネットワーク・インターフェイス（通信手段）３０１を有する。ｄｅｆａｕｌｔ  ｇｅｔｅｗａｙ２０２及びホスト２０４は、ホスト２０６からデータから受信したデータとホスト２０６が使用しているアドレスに対して秘密鍵によりディジタル署名を生成するＣＰＵ（生成手段）３０３を有し、通信手段により、その秘密鍵に対応する公開鍵の証明書、及び、その生成したディジタル署名をホスト２０６に送信する。
【実施例１】
【００３５】
本実施の形態では、ホストがイーサネット（登録商標）のＬＡＮ経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本実施例１を説明する。なお、以下ではＩＰｖ６の場合を説明するが、ＩＰｖ４にも適用可能である。ＩＰｖ４とＩＰｖ６で形態が異なる点のみについて付加的な説明を加えるものとし、ＩＰｖ４とＩＰｖ６に共通な説明はＩＰｖ６の場合を説明する。
【００３６】
１．１で環境を、１．２でＩｎｔｅｒｎｅｔ  Ｋｅｙ  ＥｘｃｈａｎｇｅとＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式を、１．３で依頼計算を、１．４で公開鍵証明書、ＩＰアドレスの正当性、ＩＫＥ−Ｐｒｏｘｙ−Ｓｅｒｖｅｒの信頼度を、１．５で本実施例のプロトコルを説明する。
【００３７】
１．１  環境
図２は、本実施例の接続環境（ホストがイーサネット（登録商標）のＬＡＮ経由でインターネットと接続する環境）を模式的に示したものである。
【００３８】
図２は、ＬＡＮに接続されたホスト２０４、２０５、２０６がｄｅｆａｕｌｔ  ｇａｔｅｗａｙ（デフォルトゲートウエイ）２０２経由でインターネット２０１にアクセスする環境を示す。本実施例では、各ホストはリンク２０７で接続するものとし、リンク２０７は具体的にはイーサネット（登録商標）であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、ＩＰ層の下側に接する。リンクにはイーサネット（登録商標）の他に、無線ＬＡＮ（ＩＥＥＥ８０２．１１）、ＰＰＰリンク、Ｘ．２５、フレームリレー、ＡＴＭネットワークがある。
【００３９】
リンクに接続されたＩＰｖ６対応装置（ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２、ＤＨＣＰサーバー２０３、ホスト２０４、２０５、２０６、２０９）をノードと呼ぶ。ノード（ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２、ＤＨＣＰサーバー２０３、ホスト２０４、２０５、２０６、２０９）の内部構成の典型例を図３に示す。
【００４０】
ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノード３００は、ネットワーク・インターフェイス３０１、３０２、ＣＰＵ３０３、ＲＯＭ３０４、ＲＡＭ３０５、ＨＤ（ハードディスク）３０６、電源３０７、キーボード／ポインティングデバイスのインターフェイス３０８、モニターのインターフェイス３０９、バス３１０等を有する計算機である。
【００４１】
ルーターは複数のネットワーク・インターフェイス３０１、３０２を持つのに対し、ホストは多くの場合は一つのネットワーク・インターフェイス３０１を持つ。ホスト２０４、２０５、２０６は、ネットワーク・インターフェイス３０１により、リンク２０７を介して、リンク２０７に接続された他のノード、あるいは、更に、ゲートウェイ２０２を介して、インターネット２０１上のノードと通信する。ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２は、ネットワーク・インターフェイス３０１により、インターネット２０１を介して、通信する。ノードによってはＨＤを持たないものもある。
【００４２】
なお以下の処理内容（手順）は、プログラムもしくはモジュールとして実現され、そのプログラムがＲＯＭ３０４もしくはＨＤ３０６に格納されたノードが実行、もしくはそのモジュールを有するノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをコンピュータであるＣＰＵ３０３が読み込み、必要に応じてＲＡＭ３０５を計算のための空間として利用しながらバス３１０を介してインターフェイス３０１にアドレスを割当てる、というような動作を行う。モジュールの場合は、プログラムがＣＰＵやＲＡＭ等と協調して実行する上述の動作と同等の動作を実行する実体が、例えばＬＳＩとして実現され、ノードに組み込まれている。ノードのＣＰＵからモジュール（ＬＳＩ）へ指示が発行され、それをきっかけにモジュールが動作し、処理を実行する。
【００４３】
ここでは、ノード３００がアドレスをインターフェイスに割当てる、というように手順の本質を説明する。
【００４４】
図２のリンク２０７に接続されたノード３００が、電源を入れられたあるいはリブートされた場合、Ｓｔａｔｅｌｅｓｓ  Ａｄｄｏｒｅｓｓ  Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎによって、そのリンクにおいて一意なインターフェイスＩＤ（ＭＡＣアドレスからＩＥＥＥ  ＥＵＩ−６４形式で生成される）が定められ、そのリンクに割当てられた（集約可能）グローバル・アドレス用ｓｕｂｎｅｔ  ｐｒｅｆｉｘがＲｏｕｔｅｒ  Ａｄｖｅｒｔｉｓｅｍｅｎｔ（ＲＡ）から取得されれば、ｓｕｂｎｅｔ  ｐｒｅｆｉｘとインターフェイスＩＤから構成される（集約可能）グローバル・アドレスがノード３００のアドレスとして使われるように自動設定される。また、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２（通常はルーターと呼ばれる）のアドレスも自動設定される。ＲＡは、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２がリンクに送出することが多い。詳細は、ＲＦＣ２４６２“ＩＰｖ６  Ｓｔａｔｅｌｅｓｓ  Ａｄｄｒｅｓｓ  Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ”に記載されている。
【００４５】
このＳｔａｔｅｌｅｓｓ  Ａｄｄｒｅｓｓ  Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの実行において、インターフェイスＩＤにランダムかつリンクにおいて一意な値を用いることにより、ノードとの対応関係をインターネット上の第三者に把握されることが困難な匿名アドレスを利用することができる。詳細は、ＲＦＣ３０４１“Ｐｒｉｖａｃｙ  Ｅｘｔｅｎｓｉｏｎｓ  ｆｏｒ  Ｓｔａｔｅｌｅｓｓ  Ａｄｄｒｅｓｓ  Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ  ｉｎ  ＩＰｖ６、”に記載されている。
【００４６】
ＩＰｖ４の場合、ノード３００が使用するＩＰｖ４アドレスとｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２（ルーター）のアドレスは、ユーザによって手動であるいはＤＨＣＰサーバー２０３によって自動で設定される。手動設定されるＩＰｖ４アドレスは変更されない限り固定となるが、ＤＨＣＰサーバー２０３によって自動設定される場合は、必ずしも固定のアドレスとは限らない。ＩＰｖ４アドレスには、プライベート・アドレスとグローバル・アドレスの２種類があり、そのネットワークの運用方針によって使い分けられる。ノードがプライベート・アドレスを使う場合でも、Ｎｅｔｗｏｒｋ  Ａｄｄｒｅｓｓ  Ｔｒａｎｓｌａｔｉｏｎ、通称ＮＡＴを（ｇａｔｅｗａｙが）行ってプライベート・アドレスをグローバル・アドレスに変換することで、インターネットに接続している他の装置と通信ができる。
【００４７】
ノード３００が使用する（グローバル・）アドレスとｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２（ルーター）のアドレスが設定されることにより、ノード３００はインターネット２０１に接続している他のリンク上のノード、例えばホスト２０９と通信ができる。
【００４８】
１．２  Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）とＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式（ＤＨ）
次にＩＫＥとＤＨの概要を説明する。
【００４９】
ＩＫＥは、Ｐｈａｓｅ１とＰｈａｓｅ２からなる。通信相手の認証方法としてディジタル署名を用いる場合のＰｈａｓｅ１を図７に示す。添字ｉやＩはＩｎｉｔｉａｔｏｒが送る情報を示し、添字ｒやＲはＲｅｓｐｏｎｄｅｒが送る情報を示す。ＨＤＲはＩＳＡＫＭＰヘッダを示し、その右に記載されたデータがペイロードを示す。例えば、“ＨＤＲ、ＳＡ”は、ＩＳＡＫＭＰパケットのペイロードがＳＡであることを示す。ＨＤＲ＊は、そのパケットのペイロードが暗号化されていることを示す。
【００５０】
図７のＳＡは、Ｓｅｃｕｒｉｔｙ  Ａｓｓｏｃｉａｔｉｏｎの候補が格納されたＳＡ  ｎｅｇｏｔｉａｔｉｏｎ  ｐａｙｌｏａｄ、ＫＥはＤｉｆｆｉｅ−Ｈｅｌｌｍａｎにおいて交換される後述の情報ｙ＿ｉ、ｙ＿ｒ（図４）である。ＮｉとＮｒはＮｏｎｃｅ、ＩＤｉｉとＩＤｉｒはＩＳＡＫＭＰ  ｉｎｉｔｉａｔｏｒとＩＳＡＫＭＰ  ｒｅｓｐｏｎｄｅｒのｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｐａｙｌｏａｄ、ＣＥＲＴは、ＩｎｉｔｉａｔｏｒあるいはＲｅｓｐｏｎｄｅｒの公開鍵証明書である。記号が鉤括弧に囲まれているのは省略可を意味する。ＳＩＧ＿Ｉは、ＨＡＳＨ＿Ｉに対してＩｎｉｔｉａｔｏｒが生成したディジタル署名である。ＳＩＧ＿Ｒは、ＨＡＳＨ＿Ｒに対してＲｅｓｐｏｎｄｅｒが生成したディジタル署名である。
【００５１】
ＨＡＳＨ＿ＩとＨＡＳＨ＿Ｒは、それまでに交換したデータから以下のようにして生成したハッシュ値である。
【００５２】
ＨＡＳＨ＿Ｉ＝ｐｒｆ（ＳＫＥＹＩＤ、ｇ＾ｘｉ｜ｇ＾ｘｒ｜ＣＫＹ−Ｉ｜ＣＫＹ−Ｒ｜ＳＡｉ＿ｂ｜ＩＤｉｉ＿ｂ）
ＨＡＳＨ＿Ｒ＝ｐｒｆ（ＳＫＥＹＩＤ、ｇ＾ｘｒ｜ｇ＾ｘｉ｜ＣＫＹ−Ｒ｜ＣＫＹ−Ｉ｜ＳＡｉ＿ｂ｜ＩＤｉｒ＿ｂ）
ただし、ｐｒｆ（ｋｅｙ、ｍｓｇ）は、鍵付ｐｓｅｕｄｏ−ｒａｎｄｏｍ  ｆｕｎｃｔｉｏｎであり、ｋｅｙとｍｓｇを入力すると疑似乱数を出力する。ＳＫＥＹＩＤは、Ｎｉ、ＮｒとＤＨにより共有されたデータをｐｒｆに入力して計算された値である。ｘｉとｘｒはＩｎｉｔｉａｔｏｒが生成した秘密とＲｅｓｐｏｎｄｅｒが生成した秘密で、ｇはＤＨにおける生成元である。ＣＫＹ−ＩとＣＫＹ＿ＲはＩｎｉｔｉｔｏｒとＲｅｓｐｏｎｄｅｒのｃｏｏｋｉｅ（ＩＳＡＫＭＰヘッダの中に含まれる）、ＳＡｉ＿ｂはｔｈｅ  ｅｎｔｉｒｅ  ｂｏｄｙ  ｏｆ  ｔｈｅ  ＳＡ  ｐａｙｌｏａｄ（ｍｉｎｕｓ  ｔｈｅ  ＩＳＡＫＭＰ  ｇｅｎｅｒｉｃ  ｈｅａｄｅｒ）、ＩＤｉｉ＿ｂとＩＤｉｒ＿ｂは、ＩＤｉｉペイロードのボディとＩＤｉｒペイロードのボディである。
【００５３】
図４に、ＤＨを示す。図４のｅｎｔｉｔｙ  ｉを図７のＩｎｉｔｉａｔｏｒ、図４のｅｎｔｉｔｙ  ｒを図７のＲｅｓｐｏｎｄｅｒに対応させると、図７の最初から３番目にＩｎｉｔｉａｔｏｒからＲｅｓｐｏｎｄｅｒに送られるＫＥが図４ステップＳ４０３ｉのｙ＿ｉに相当し、図７の最初から４番目にＲｅｓｐｏｎｄｅｒからＩｎｉｔｉａｔｏｒに送られるＫＥが図４ステップＳ４０３ｒのｙ＿ｒに相当する。
【００５４】
ＤＨを実行した結果、ｙ＿ｉｒ＝ｙ＿ｒｉ＝ｇ＾（ｘｉ＊ｘｒ）ｍｏｄ  ｐがｅｎｔｉｔｙ  ｉとｅｎｔｉｔｙ  ｒの間で共有されるが、パラメータｐやｇ、交換されるデータｙ＿ｉやｙ＿ｒを観測する第三者は、共有されたデータｙ＿ｉｒ＝ｙ＿ｒｉ＝ｇ＾（ｘｉ＊ｘｒ）ｍｏｄ  ｐを知ることはできない。
【００５５】
従って、図７の最初から３番目と４番目のデータのやり取りによりＤＨを実行したＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒは、その時点でそれぞれが暗号化鍵を生成できる。図７の５番目と６番目にやりとりされる２つの暗号化データは、この暗号化鍵を用いて暗号化される。暗号化鍵の詳細な生成方法は、ＲＦＣ２４０９“Ｔｈｅ  Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）”に記載されている。
【００５６】
Ｐｈａｓｅ１の終了時点で、ＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒの間は暗号化によって保護され（ＩＳＡＫＭＰ  ＳＡが確立したと呼ぶ）、他の装置は暗号化された通信を解読できない。
【００５７】
この暗号通信を利用して、図８に示すＰｈａｓｅ２（Ｑｕｉｃｋ  Ｍｏｄｅ）を実行し、ＩｎｉｔｉａｔｏｒからＲｅｓｐｏｎｄｅｒへの通信用のＩＰｓｅｃ  ＳＡとＲｅｓｐｏｎｄｅｒからＩｎｉｔｉａｔｏｒへの通信用のＩＰｓｅｃ  ＳＡを共有する。図８の記号の意味は図７と同様である。Ｐｈａｓｅ２においてＤＨを実行することも実行しないことも可能である。
【００５８】
また、ＩＰｓｅｃをトンネル・モードで実行する場合は、図９に示すように、ＩＳＡＫＭＰを実行するＩｎｉｔｉａｔｏｒ９０４とＲｅｓｐｏｎｄｅｒ９０７（トンネルの両端となる）とは異なる二つのノード（例えば９０１と９０８）がＩＰｓｅｃの両端となりうる。トンネル９０５を利用して通信する両端のノード（９０１、９０２、９０３、９０８、９０９、９１０）はｃｌｉｅｎｔと呼ばれ、それらのｃｌｉｅｎｔのＩＤペイロードをＩＤｃｉ、ＩＤｃｒ（それぞれＩｎｉｔｉａｔｏｒ側のｃｌｉｅｎｔ、Ｒｅｓｐｏｎｄｅｒ側のｃｌｉｅｎｔ）と表す。その他の詳細はＲＦＣ２４０９を参照するものとする。
【００５９】
Ｐｈａｓｅ２を終了すると、ＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒの間の双方向の通信路それぞれにＩＰｓｅｃ  ＳＡが定まるので、以降はそれらのＳＡを用いてＩＰｓｅｃ通信を実行できる。
【００６０】
１．３  依頼計算
本実施例では、リンク２０７に接続するホスト２０６が、インターネット２０１に接続している他のリンク上のホスト２０９と、ＩＫＥを実行してＩＰｓｅｃ通信を行う例を説明する。その際に、ホスト２０６はＩＫＥの処理の全てを単独で実行せず、自分の証明書は使わない。ホスト２０６のリンク２０７に接続している別の装置、例えばｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２やホスト２０４等が、ＩＫＥ内のＤＨの計算をホスト２０６と協調して行う。この協調計算として依頼計算と呼ばれる方式を利用することができる。依頼計算とは、計算能力の小さな装置（クライアント）が計算能力の大きな装置（サーバー）に計算を依頼する方式であって、計算に必要な秘密情報を隠しながら依頼する方法である。
【００６１】
この依頼計算を、図５を参照しながら説明する。図５は、クライアントとサーバーがＤＨの依頼計算を実行するときに行われるプロトコルを示す。これは特願２００３−３１４０００号において提案した方式であり、本実施例の説明においては概要を説明する。
【００６２】
クライアント（ノードＡ）２０６は秘密情報ｘ＿Ａを有し、ＩＰｓｅｃ通信を行う通信相手（ノードＢ、図５に示されていない、図２のホスト２０９）との間で最終的に共有するｙ＿ＡＢ＝（ｙ＿Ｂ）＾（ｘ＿Ａ）ｍｏｄ  ｐと、そのｙ＿ＡＢを求めるために途中で必要なｙ＿Ａ＝ｇ＾（ｘ＿Ａ）ｍｏｄ  ｐを、依頼計算プロトコルを利用して求めたい。ｘ＿Ａはクライアント２０６の秘密で、ｇとｐは公開である。ｐのＣａｒｍｉｃｈａｅｌ  Ｆｕｎｃｔｉｏｎをλ（ｐ）と記す。クライアント２０６はサーバー（２０２又は２０４）のＩＰアドレスを知っている。
【００６３】
ステップＳ５０１で、クライアント２０６は乱数ｒ＿ｉｎｉｔとｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐを用意する。ｒ＿ｉｎｉｔは、１以上ｐ未満の整数である。図５で説明するプロトコルが過去に実行されている場合、前回計算したｒとｇ＾ｒ  ｍｏｄ  ｐをｒ＿ｉｎｉｔとｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐとして利用する。初めてプロトコルを実行する場合は、クライアント２０６はＩＰｖ６装置なので、例えば、製造時に乱数ｒ＿ｉｎｉｔが生成され、計算済みのｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）  ｍｏｄ  ｐを記録した状態で出荷されることが考えられる。あるいは、待機状態（依頼計算プロトコルを実行していない状態）のときに乱数ｒ＿ｉｎｉｔを生成してｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）  ｍｏｄ  ｐを計算しておき、その結果を記録しておくことも考えられる。
【００６４】
ステップＳ５０２で、クライアント２０６はｒ＿１ｓｔ≡ｆ＿１＊ｄ＿１＋ｆ＿２＊ｄ＿２＋．．．＋ｆ＿Ｍ＊ｄ＿Ｍ（ｍｏｄ  λ（ｐ））となるような整数ベクトルＤ＝［ｄ＿１、ｄ＿２、．．．、ｄ＿Ｍ］とバイナリーベクトルＦ＝［ｆ＿１、ｆ＿２、．．．、ｆ＿Ｍ］をランダムに生成する、ただし、ＭとＬをある整数として、ｄ＿ｉは１以上ｐ未満、Ｆの重み（Ｆの要素ｆ＿１、ｆ＿２、．．．、ｆ＿Ｍのうち値が１である要素の個数）はＬ以下である。ステップＳ５０３で、クライアント２０６はｐとＤとｇをサーバー（２０２又は２０４）に送る。
【００６５】
ステップＳ５０４で、サーバー（２０２又は２０４）はｚ＿ｉ＝ｇ＾（ｄ＿ｉ）ｍｏｄ  ｐなるＺ＝［ｚ＿１、ｚ＿２、．．．、ｚ＿Ｍ］を計算する。ステップＳ５０５で、サーバーはＺをクライアントに送る。
【００６６】
ステップＳ５０６で、クライアント２０６は、ステップＳ５０２で生成したＦ及びステップＳ５０５で受信したＺを元に、以下のようにしてｙ＿１ｓｔ＝ｙ＿Ｍを計算する。すなわち、ｙ＿０＝１とし、ｉ＝１、２、．．．、Ｍに対してｆ＿ｉ＝１ならばｙ＿ｉ＝ｙ＿（ｉ−１）＊ｚ＿ｉ  ｍｏｄ  ｐとし、ｆ＿ｉ＝０ならばｙ＿ｉ＝ｙ＿（ｉ−１）とする。そして、クライアントは、ｒ＿１ｓｔとｙ＿１ｓｔ（＝ｇ＾（ｒ＿１ｓｔ）ｍｏｄ  ｐ）を記録し、ｙ＿Ａ＝ｙ＿ｉｎｉｔ＊ｙ＿１ｓｔ  ｍｏｄ  ｐとしてｙ＿Ａを求める。なお、クライアント（ノードＡ）２０６はノードＢ（２０９）とＩＫＥを実行しているので、ｙ＿ＡをノードＢに送り、ｙ＿ＢをノードＢから受け取る（図示せず）。
【００６７】
ステップＳ５０７で、クライアント２０６はｒ＿ｉｎｉｔ＋ｒ＿１ｓｔ≡ｆ＿１'＊ｄ＿１'＋ｆ＿２'＊ｄ＿２'＋．．．＋ｆ＿Ｍ'＊ｄ＿Ｍ'（ｍｏｄ  λ（ｐ））となるような整数ベクトルＤ'＝［ｄ＿１'、ｄ＿２'、．．．、ｄ＿Ｍ'］とバイナリーベクトルＦ'＝［ｆ＿１'、ｆ＿２'、．．．、ｆ＿Ｍ'］をランダムに生成する、ただし、ＭとＬをある整数として、ｄ＿ｉ'は１以上ｐ未満、Ｆ'の重み（Ｆ'の要素ｆ＿１'、ｆ＿２'、．．．、ｆ＿Ｍ'のうち値が１である要素の個数）はＬ以下である。ステップＳ５０８で、クライアント２０６はｐとＤ'とｙ＿Ｂをサーバー（２０２又は２０４）に送る。
【００６８】
ステップＳ５０９で、サーバー（２０２又は２０４）は、ｚ＿ｉ'＝（ｙ＿Ｂ）＾（ｄ＿ｉ'）ｍｏｄ  ｐなるＺ'＝［ｚ＿１'、ｚ＿２'、．．．、ｚ＿Ｍ'］を計算する。ステップＳ５１０で、サーバーはＺ'をクライアントに送る。
【００６９】
ステップＳ５１１で、クライアント２０６は以下のようにしてｙ＿２ｎｄ＝ｙ＿Ｍ'を計算する。すなわち、ｙ＿０'＝１とし、ｉ＝１、２、．．．、Ｍに対してｆ＿ｉ'＝１ならばｙ＿ｉ'＝ｙ＿（ｉ−１）'＊ｚ＿ｉ'ｍｏｄ  ｐとし、ｆ＿ｉ'＝０ならばｙ＿ｉ'＝ｙ＿（ｉ−１）'とする。求めたｙ＿２ｎｄをｙ＿ＡＢとする（ｙ＿ＡＢ：＝ｙ＿２ｎｄ）。
【００７０】
以上の依頼計算プロトコル２回の実行によってＤＨが１回実行される。次にＤＨを実行する際は、乱数ｒ＿ｉｎｉｔとｙ＿ｉｎｉｔ＝ｇ＾（ｒ＿ｉｎｉｔ）ｍｏｄ  ｐとして今回計算して記憶したｒ＿１ｓｔとｙ＿１ｓｔ＝ｇ＾（ｒ＿１ｓｔ）ｍｏｄ  ｐを用いる。
【００７１】
１．４  公開鍵証明書、ＩＰアドレスの正当性、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒの信頼度
本実施例では、ノード２０６が使うＩＰアドレスを、ノード２０６と同じリンク２０７に接続している別のノード（ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒと呼ぶ）が監視しながらＩＫＥが実行される。この監視により、ノード２０６が使用するＩＰアドレスをノード２０６でもＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒでもないノードが使用することによるなりすましが起らないことを保証可能になる。具体的には、ノード２０６と同じリンク２０７上に前記ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒが接続しているので、リンク層の情報（ＭＡＣアドレス等）を利用することで実現される。監視方法は複数考えられるが、例えば、ＭＡＣアドレスとＩＰアドレスの対応関係を記録・監視することで、同じＩＰアドレスを別のノード（別のＭＡＣアドレスを有する）が使おうとする試みを検出できる。本実施例では、ＩＰｓｅｃ通信を行う装置２０６と同じリンクに接続する別装置２０２が前記装置２０６のＩＰアドレスを監視する。したがって、ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋを検出することが可能であり、前記装置２０６が使うＩＰアドレスを他の装置が使って前記装置２０６になりすまそうとする行為をリンク層のデータを用いて検出することができる。
【００７２】
また、本実施例では、ＩＫＥにおいて通信相手の認証に用いられるデータ（ＨＡＳＨ＿ＩあるいはＨＡＳＨ＿Ｒ）とノード２０６が使うＩＰアドレスとを対象にして、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒがその公開鍵証明書を用いてディジタル署名を生成し、それが通信相手のホスト２０９に認証のため送られる。ホスト２０９は、受け取った証明書の内容を確認してリンク２０７を特定し、受け取ったディジタル署名の正当性を確認することにより、ＤＨを実行した相手からのデータであることと、リンク２０７上の相手のＩＰアドレスの正当性の両方を確認できる。
【００７３】
ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒが監視とＩＰアドレスの正当性を、証明書を用いて保証するので、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒは信頼できる（嘘をつかない）と仮定する。しかし、何らかの原因により信頼できない状態になった場合に、ノード２０６が受ける被害の程度を見積もることが好ましい。
【００７４】
また、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒは、ＩＫＥにおいてｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋを仕掛けることができる。この攻撃では、ノードＡとノードＢがＤＨを実行するときに、攻撃者であるノードＣがノードＡとノードＢの間で通信内容をすり替えて、ノードＡに対してはノードＢになりすまし、ノードＢに対してはノードＡになりすます。その結果、ノードＡがノードＢと共有したと思っている秘密データは、実際はノードＡとノードＣの間で共有される。同様にノードＢがノードＡと共有したと思っている秘密データは、実際はノードＢとノードＣの間で共有される。
【００７５】
各ノード間で共有された秘密データから生成された暗号化鍵＝復号鍵をＫ＿ＡＢ（ノードＡとノードＢの間の鍵）、Ｋ＿ＡＣ（ノードＡとノードＣの間の鍵）、Ｋ＿ＢＣ（ノードＢとノードＣの間の鍵）と表すと、ノードＡがノードＢと共有したと思っている鍵は、実際はＫ＿ＡＣであり、ノードＢがノードＡと共有したと思っている鍵は、実際はＫ＿ＢＣである。従って、ノードＡがノードＢ宛に暗号化して送ったデータは、その暗号化データをノードＣが横取りしてＫ＿ＡＣで復号し、ノードＣは復号したデータをＫ＿ＢＣで暗号化してノードＢに送る。ノードＢは、受け取った暗号化データをＫ＿ＢＣで復号する。ノードＢがノードＡに送る暗号化データも同様のやり方で処理される。従って、ノードＡが暗号化して送ったデータをノードＢは暗号化された状態で受け取るが、ノードＡとノードＢの間の暗号化通信は、実際はノードＣによって盗聴されている。
【００７６】
ＩＫＥでは、このｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋを検出して盗聴を防止するために、通信相手の認証を行う。通信相手の認証は、ｐｒｅ−ｓｈａｒｅｄ  ｋｅｙを用いる方法と公開鍵を用いる方法に分けられる。インターネットで不特定多数とＩＫＥでＩＰｓｅｃを実行するためにはｐｒｅ−ｓｈａｒｅｄ  ｋｅｙは使えない。公開鍵を用いる場合は、公開鍵証明書によってノード（のＩＤとその公開鍵の対応）の確認を行うが、本実施例ではホスト２０６は証明書を持たないので、ホスト２０６の通信相手は、ホスト２０６の確認を行えない。
【００７７】
しかし、本発明がＩｎｉｔｉａｔｏｒに適用される場合（ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒと同一のリンク上に存在するホスト２０６がＩｎｉｔｉａｔｏｒである場合）、Ｒｅｓｐｏｎｄｅｒ（ホスト２０９）が自分の公開鍵証明書を持っていれば、Ｉｎｉｔｉａｔｏｒ（ホスト２０６）がｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋを検出することが可能である。つまり、ディジタル署名により通信相手の認証を行うＩＫＥにおいて、Ｒｅｓｐｏｎｄｅｒは自分の公開鍵証明書に対応する秘密鍵を用いて相手確認データ（ディジタル署名）を生成するが、ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋを仕掛ける攻撃者はＲｅｓｐｏｎｄｅｒの公開鍵証明書に対応する秘密鍵を持たないため、Ｒｅｓｐｏｎｄｅｒに成り済まして相手確認データ（ディジタル署名）を生成できない。
【００７８】
そこで、本発明をＩｎｉｔｉａｔｏｒに実施する場合、少なくともＲｅｓｐｏｎｄｅｒが自分の公開鍵証明書を有すれば、Ｉｎｉｔｉａｔｏｒがｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋを検出できる。そうではない場合、例えばＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒの両方が本発明を利用するような場合は、ＩＫＥ  Ｐｒｏｘｙ  ＳｅｒｖｅｒがＩＰｓｅｃ通信の盗聴を行う可能性があるので、それを許容するか否かをｓｅｃｕｒｉｔｙ  ｐｏｌｉｃｙに定めておき、対処することが望ましい。
【００７９】
後者の場合、リンク２０７上のノード２０６とＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ（ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２とする）以外のノード、例えばノード２０５はｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ−ａｔｔａｃｋを行えない、つまり盗聴できないことに注意する。ＩＰｓｅｃのトンネル・モードを用いた場合、トンネル外部のリンク上のデータは平文のままなので、同一リンクの他のノードは盗聴できてしまうが、本実施例の場合は同一リンクの他のノードは盗聴できないという特徴を持つ。
【００８０】
図９にＩＰｓｅｃのトンネル・モードを用いた場合の模式図を示す。Ｉｎｉｔｉａｔｏｒ９０４とＲｅｓｐｏｎｄｅｒ９０７はＩＫＥを実行しインターネット９０６上でＩＰｓｅｃのトンネル９０５を形成する。Ｉｎｉｔｉａｔｏｒ９０４をｇａｔｅｗａｙとするノード群（ｃｌｉｅｎｔ９０１、ｃｌｉｅｎｔ９０２、．．．ｃｌｉｅｎｔ９０３）と、Ｒｅｓｐｏｎｄｅｒ９０７をｇａｔｅｗａｙとするノード群（ｃｌｉｅｎｔ９０８、ｃｌｉｅｎｔ９０９、．．．ｃｌｉｅｎｔ９１０）との間でＩＰｓｅｃトンネル９０５により保護された通信が出来るが、例えば、ｃｌｉｅｎｔ９０１とｃｌｉｅｎｔ９０８が通信する場合、ｃｌｉｅｎｔ９０１と同じリンク上のｃｌｉｅｎｔ９０２は、ｃｌｉｅｎｔ９０１とｃｌｉｅｎｔ９０８の間の通信を盗聴できる。これに対し、本実施例は、図２の場合ノード２０６とノード２０９の間の通信はｅｎｄ−ｔｏ−ｅｎｄで暗号化されているので、リンク２０７上のＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒではないノード、例えばノード２０５が盗聴することはできない。従って、ＩＰｓｅｃのトンネル・モードを用いた場合よりも安全である。
【００８１】
１．５  本実施例のプロトコル
次に本実施例のプロトコルの説明をする。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒとしてｄｅｆａｕｌｔ  ｒｏｕｔｅｒ２０２（ルーター）を用いる場合と、リンク２０７上のｄｅｆａｕｌｔ  ｒｏｕｔｅｒ２０２（ルーター）以外のノード（例えばホスト２０４）を用いる場合に分けられる。図１に前者の場合のプロトコルを、図６に後者の場合のプロトコルを示す。図１と図６では、Ｉｎｉｔｉａｔｏｒがホスト２０６を、Ｒｅｓｐｏｎｄｅｒがホスト２０９を示す。ホスト２０４（、２０５、２０６）は、ネットワーク・インターフェイス３０１により、リンク２０７を介して、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２と通信する。ホスト２０９は、ネットワーク・インターフェイス３０１により、インターネット２０１を介して、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２と通信する。ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２は、ネットワーク・インターフェイス３０１により、インターネット２０１を介して、ホスト２０９と通信し、ネットワーク・インターフェイス３０２により、リンク２０７を介して、ホスト２０４、２０５、２０６と通信する。図１の場合は、ＩｎｉｔｉａｔｏｒからＲｅｓｐｏｎｄｅｒへの経路上にＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒが位置するので、図６の場合よりもＩｎｉｔｉａｔｏｒが送受信する回数が少なくなり効率が良い。
【００８２】
本実施例の前提を説明する。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒは自分の公開鍵と秘密鍵を有し（ＨＤ２０６に記憶し）、秘密鍵はＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒのみがアクセスできるように安全に管理されているものとする。ＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ）からＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ用の公開鍵証明書ＣＥＲＴ＿Ｓが発行されており、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ（のＨＤ３０６）にはその公開鍵証明書ＣＥＲＴ＿Ｓが格納されているものとする。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒの公開鍵証明書ＣＥＲＴ＿Ｓには、ＩＫＥ  Ｐｒｏｘｙ  ＳｅｒｖｅｒのＩＰｖ６グローバル・アドレスと、その装置がＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒである旨の記載が含まれている。例えば、公開鍵証明書の形式としてＸ．５０９ｖ３を用いる場合、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒであることを示す情報をｓｕｂｊｅｃｔＡｌｔＮａｍｅに定義し、記載することが考えられる。他の定義・記載方法が採用されてもかまわないが、ＩＫＥを実行する相手装置（本実施例の場合はＲｅｓｐｏｎｄｅｒ）がその定義・記載方法に合意していることが前提である。
【００８３】
Ｒｅｓｐｏｎｄｅｒは、ＣＡからＲｅｓｐｏｎｄｅｒに発行された公開鍵証明書ＣＥＲＴ＿Ｒを（ＨＤ３０６に）保持しているものとする。例えば、ＲｅｓｐｏｎｄｅｒがＷｅｂサイトであればそのＦＱＤＮ（Ｆｕｌｌｙ  Ｑｕａｌｉｆｉｅｄ  Ｄｏｍａｉｎ  Ｎａｍｅ）がＲｅｓｐｏｎｄｅｒの公開鍵証明書に記載され、固定のＩＰｖ６アドレスを使っているノードであれば、その固定のＩＰｖ６アドレスがＲｅｓｐｏｎｄｅｒの公開鍵証明書に記載されている。ＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒは、ＣＡの公開鍵証明書（ＣＡの公開鍵を含む）を（ＨＤ３０６に）保持している。
【００８４】
Ｉｎｉｔｉａｔｏｒは、ＩＫＥ  Ｐｒｏｘｙ  ＳｅｒｖｅｒのＩＰアドレスを知っているもの（ＨＤ３０６に記憶している）とする。また、Ｒｅｓｐｏｎｄｅｒ及びＩｎｉｔｉａｔｏｒは、ＣＡの公開鍵を知っている（ＨＤ３０６に記憶している）ものとする。
【００８５】
以下、図１を参照しながら、本実施例のプロトコルの流れと動作の詳細な説明を行う。
【００８６】
Ｉｎｉｔｉａｔｏｒ２０６は、Ｒｅｓｐｏｎｄｅｒ２０９のＦＱＤＮからＤＮＳによってＲｅｓｐｏｎｄｅｒのＩＰｖ６アドレスを知った、あるいは別の手段でＲｅｓｐｏｎｄｅｒのＩＰｖ６アドレスを知ったと仮定し、ＩｎｉｔｉａｔｏｒがＲｅｓｐｏｎｄｅｒとＩＰｓｅｃトランスポート・モードの通信を行おうとしている状態から動作を説明する。
【００８７】
ステップＳ１０１で、Ｉｎｉｔｉａｔｏｒ２０６は、ｙ＿ｉ＝ｇ＾ｘｉ  ｍｏｄ  ｐの依頼計算に必要なパラメータをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２に送り、かつＩｎｉｔｉａｔｏｒ２０６が複数のＳＡプロポーサルをＲｅｓｐｏｎｄｅｒ２０９宛に送る。ｙ＿ｉ＝ｇ＾ｘｉ  ｍｏｄ  ｐの依頼計算に必要なパラメータとは、図５の記号で言えばＤであるので、図１にＤと表す。図１ではステップＳ１０１の転送が一本の矢印で示されているが、実際には異なるパケットである。なお、Ｉｎｉｔｉａｔｏｒ２０６は、図５のステップＳ５０１と同様に、乱数ｒ＿ｉｎｉｔとｙ＿ｉｎｉｔを用意しておく。
【００８８】
ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２はｄｅｆａｕｌｔ  ｇａｔｅｗａｙなので、Ｒｅｓｐｏｎｄｅｒ２０９宛のＳＡのプロポーザルはＲｅｓｐｏｎｄｅｒ宛に転送し、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ宛のパラメータは自分が受け取る。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、他のノードがＩｎｉｔｉａｔｏｒになりすまさないように、Ｉｎｉｔｉａｔｏｒ２０６が使用するＩＰｖ６アドレスＩＰ＿Ｉ（ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ宛のパケットから取得）の監視及びＩｎｉｔｉａｔｏｒ２０６とＲｅｓｐｏｎｄｅｒ２０９の間の通信内容の監視を開始する。すなわち、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）実行中の装置（Ｉｎｉｔｉａｔｏｒ２０６）が使用するＩＰアドレスを監視しながら前記装置（Ｉｎｉｔｉａｔｏｒ）の依頼に応じてＩＫＥにおけるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算（図５）を実行する。
【００８９】
ステップＳ１０２でＲｅｓｐｏｎｄｅｒ２０９は、複数のＳＡのプロポーザルを受け取り、複数のＳＡのプロポーザルの中から使用するＳＡを選ぶ。ステップＳ１０３でＲｅｓｐｏｎｄｅｒは、選択したＳＡをＩｎｉｔｉａｔｏｒ２０６宛に送る。
【００９０】
ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、Ｉｎｉｔｉａｔｏｒ２０６宛のＳＡを受け取ると、その内容からＤＨのパラメータｇとｐを取出し、ステップＳ１０１で受け取ったＤとこのｇとｐからｙ＿ｉ＝ｇ＾ｘｉ  ｍｏｄ  ｐの依頼計算を行う。この依頼計算とは、図５で言えばステップＳ５０４の計算である。ステップＳ１０４でＩＫＥ  Ｐｒｏｘｙ  ＳｅｒｖｅｒはＳＡと依頼計算結果をＩｎｉｔｉａｔｏｒ２０６宛に送る。依頼計算結果とは図５で言えばＺであるので、図１にＺと表す。このように、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、Ｉｎｉｔｉａｔｏｒ２０６からの依頼に応じて依頼計算を実行する。
【００９１】
ステップＳ１０５でＩｎｉｔｉａｔｏｒ２０６は依頼計算結果Ｚから（ｙ＿１ｓｔ、さらに）ｙ＿ｉを求める。図５で言えばステップＳ５０６においてｙ＿Ａを求める計算であり、まず、ｙ＿１ｓｔを求め、さらに、ｙ＿１ｓｔ及びｙ＿ｉｎｉｔからｙ＿ｉを求める。この１回目の依頼計算は、ｒ＿１ｓｔからｙ＿１ｓｔを求めるための計算の一部を依頼する依頼計算であり、Ｉｎｉｔｉａｔｏｒ２０４は、ｒ＿１ｓｔを送る代わりに、パラメータＤをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２に送っている。
【００９２】
ステップＳ１０６でｙ＿ｒ＾ｘｉ  ｍｏｄ  ｐの依頼計算に必要なパラメータをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２に送り、ｙ＿ｉとＮ＿ｉをＲｅｓｐｏｎｄｅｒ２０９宛に送る。ｙ＿ｒ＾ｘｉ  ｍｏｄ  ｐの依頼計算に必要なパラメータとは、図５の記号で言えばＤ’であるので、図１にＤ’と表す。ｙ＿ｉは、Ｒｅｓｐｏｎｄｅｒ２０９がｙ＿ｒｉを求めるために用いられる。図１ではステップＳ１０６の転送が一本の矢印で示されているが、実際には異なるパケットである。
【００９３】
ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ宛のパラメータは自分が受け取り、Ｒｅｓｐｏｎｄｅｒ宛のｙ＿ｉとＮｉはステップＳ１０７でＲｅｓｐｏｎｄｅｒ２０６宛に転送する。ステップＳ１０８でＲｅｓｐｏｎｄｅｒ２０９はｙ＿ｒ（＝ｇ＾ｘ＿ｒ  ｍｏｄ  ｐ）とＮｒをＩｎｉｔｉａｔｏｒ２０６宛に送る。このｙ＿ｒとＮｒは、図７の最初から４番目にＲｅｓｐｏｎｄｅｒからＩｎｉｔｉａｔｏｒに送られるＫＥ、Ｎｒに対応する。Ｒｅｓｐｏｎｄｅｒ２０９は、ｙ＿ｉ及びｘ＿ｒを元に、ｙ＿ｒｉ（＝ｙ＿ｉｒ）を求める。
【００９４】
ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、Ｉｎｉｔｉａｔｏｒ２０６宛のｙ＿ｒとＮｒを受け取ると、ｙ＿ｒ＾ｘｉ  ｍｏｄ  ｐの依頼計算を行う。この依頼計算とは、図５で言えばステップＳ５０９の計算である。ステップＳ１０９でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は依頼計算結果とｙ＿ｒとＮｒをＩｎｉｔｉａｔｏｒ宛に送る。依頼計算結果とは、図５で言えばＺ'であるので、図１にＺ'と表す。このように、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、Ｉｎｉｔｉａｔｏｒ２０６からの依頼に応じて依頼計算を実行する。
【００９５】
Ｉｎｉｔｉａｔｏｒ２０６は、依頼計算結果Ｚ'とｙ＿ｒとＮｒを受け取り、依頼計算結果Ｚ'からＲｅｓｐｏｎｄｅｒ２０９とのＤＨの結果を求める。図５で言えばステップＳ５１１においてｙ＿ＡＢを求める計算である。ここで、この依頼計算は、ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔからｙ＿ｉｒを求める依頼計算である。Ｉｎｉｔｉａｔｏｒ２０６は、ｒ＿ｉｎｉｔ＋ｒ＿１ｓｔの代わりに、パラメータＤ'をＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２に送る。このようにして、Ｒｅｓｐｏｎｄｅｒ（通信相手）２０９との間で、秘密データｙ＿ｉｒを共有する。すなわち、Ｉｎｉｔｉａｔｏｒ２０６は、依頼計算の結果により、暗号化に用いる秘密データｙ＿ｉｒを共有する。それを基にしてＨＡＳＨ＿Ｉ（ハッシュ値）を計算する。
【００９６】
ステップＳ１１０でＨＡＳＨ＿ＩをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２（ディジタル署名の発行装置）に送る。Ｉｎｉｔｉａｔｏｒ（ホスト）２０６は、データであるＨＡＳＨ＿Ｉを生成するＣＰＵ（生成手段）と、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２（ディジタル署名の発行装置）にその生成したデータを送信するネットワーク・インターフェイス（通信手段）３０１を有する。なお、ＣＰＵ３０３は、鍵生成のためにＲｅｓｐｏｎｄｅｒ（通信相手）２０９と交換したデータを元に、鍵（Ｒｅｓｐｏｎｄｅｒ２０９との間で共有した暗号化鍵）及びデータＨＡＳＨ＿Ｉを生成する。
【００９７】
すなわち、Ｒｅｓｐｏｎｄｅｒ（通信相手）２０９とｙ＿ｉｒ（第１のデータ）を共有する場合に、ｙ＿１ｓｔ（第２のデータ）をｒ＿１ｓｔ（第３のデータ）から依頼計算を用いて求め、Ｒｅｓｐｏｎｄｅｒ（通信相手）２０９がｙ＿ｒｉ（＝ｙ＿ｉｒ（第１のデータ））を求めるためのｙ＿ｉ（第４のデータ）を、ｙ＿１ｓｔ（第２のデータ）及びｙ＿ｉｎｉｔ（第５のデータ）から生成し、Ｒｅｓｐｏｎｄｅｒ（通信相手）と共有するｙ＿ｉｒ（第１のデータ）を、ｒ＿１ｓｔ（第３のデータ）及びｒ＿ｉｎｉｔ（第７のデータ）から生成されるｒ＿ｉｎｉｔ＋ｒ＿１ｓｔ（第６のデータ）から、依頼計算を用いて求める。このように代理計算するので、代理計算するＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２に鍵を知られずに済む。
【００９８】
ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、Ｒｅｓｐｏｎｄｅｒ（第１の装置）２０９と暗号通信を行うＩｎｉｔｉａｔｏｒ（第２の装置）２０６からデータＨＡＳＨ＿Ｉを受信する。
【００９９】
ステップＳ１１１でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２はＨＡＳＨ＿Ｉ（ハッシュ値）とＩＰ＿Ｉ（Ｉｎｉｔｉａｔｏｒが使用するＩＰｖ６アドレス）に対するディジタル署名ＳＩＧ＿Ｓを計算する。その形式は様々なものが採用できるが、本実施例では、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２の秘密鍵を用いて、ＨＡＳＨ＿ＩとＩＰ＿Ｉを連接したデータに対するディジタル署名ＳＩＧ＿Ｓを生成する。
【０１００】
ステップＳ１１２でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２はＣＥＲＴ＿ＳとＳＩＧ＿ＳをＩｎｉｔｉａｔｏｒ２０６宛に送る。ＣＥＲＴ＿Ｓは（ＣＡにより発行された）ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２の（ＳＩＧ＿Ｓの生成に用いた秘密鍵に対応する公開鍵の）公開鍵証明書である。この公開鍵証明書ＣＥＲＴ＿Ｓは、公開鍵と秘密鍵を有する装置（ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２）が用いるＩＰアドレスと、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２の公開鍵と、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２が署名生成を行う装置であることを定義する情報をも含む。すなわち、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、Ｒｅｓｐｏｎｄｅｒ（第１の装置）２０９と暗号通信を行うＩｎｉｔｉａｔｏｒ（第２の装置）２０６にディジタル署名を発行するディジタル署名発行装置であって、Ｉｎｉｔｉａｔｏｒ２０６と通信するネットワーク・インターフェイス（通信手段）３０２と、Ｉｎｉｔｉａｔｏｒ２０２から受信したデータとＩｎｉｔｉａｔｏｒ２０６が使用しているアドレスに対して秘密鍵によりディジタル署名を生成するＣＰＵ（生成手段）３０３を有する。ネットワーク・インターフェイス３０２は、その秘密鍵に対応する公開鍵の証明書、及び、その生成したディジタル署名をＩｎｉｔｉａｔｏｒ２０６に送信する。Ｉｎｉｔｉａｔｏｒ２０６は、ハッシュ値ＨＡＳＨ＿Ｉ及びＩｎｉｔｉａｔｏｒ（通信装置）２０６のアドレスに対して生成されたディジタル署名をＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ（ディジタル署名の発行装置）２０２から受信する。
【０１０１】
ステップＳ１１３でＩｎｉｔｉａｔｏｒ２０６は、Ｒｅｓｐｏｎｄｅｒ２０９との間で共有した暗号化鍵を用いてＩＤｉｉとＣＥＲＴ＿ＳとＳＩＧ＿Ｓを暗号化し、Ｒｅｓｐｏｎｄｅｒ２０９宛に送る。このように、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２により生成されたディジタル署名は、Ｒｅｓｐｏｎｄｅｒ（通信相手）２０９に送信される。ステップＳ１１４でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２はＩｎｉｔｉａｔｏｒ２０６から受け取ったデータをＲｅｓｐｏｎｄｅｒ２０９宛に送る。すなわち、図７では、Ｉｎｉｔｉａｔｏｒが、ディジタル署名ＳＩＧ＿Ｉを生成し、ディジタル署名ＳＩＧ＿Ｉ（及びＩｎｉｔｉａｔｏｒの公開鍵証明書ＣＥＲＴ）をＲｅｓｐｏｎｄｅｒに送信したが、図１では、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２が、ディジタル署名ＳＩＧ＿Ｓを生成し、Ｉｎｉｔｉａｔｏｒ２０６が、ディジタル署名ＳＩＧ＿Ｓ及びＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２の公開鍵証明書ＣＥＲＴ＿Ｓを、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２から受け取り、暗号化してから、Ｒｅｓｐｏｎｄｅｒ２０９に送信する。
【０１０２】
ここで、Ｉｎｉｔｉａｔｏｒ（ホスト）２０６は、ネットワーク・インターフェイス３０１により、先に生成したデータＨＡＳＨ＿Ｉ及びＩｎｉｔｉａｔｏｒ（ホスト）２０６が使用中のアドレスとに対してＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ（ディジタル署名の発行装置）２０２により発行されたディジタル署名を受信して、その発行されたディジタル署名をＲｅｓｐｏｎｄｅｒ（通信相手）２０９に送信する。なお、ＣＰＵ３０３は、その発行されたディジタル書名を、生成した鍵（Ｒｅｓｐｏｎｄｅｒ２０９との間で共有した暗号化鍵）を用いて暗号化して、ネットワーク・インターフェイス３０１により、Ｒｅｓｐｏｎｄｅｒ（通信相手）２０９に送信する。
【０１０３】
ステップＳ１１５でＲｅｓｐｏｎｄｅｒ２０９は、受け取ったデータを、Ｉｎｉｔｉａｔｏｒ２０６との間で共有した暗号化鍵を用いて復号する。そして、ＣＥＲＴ＿Ｓ（ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２の公開鍵証明書）の正当性をＣＡの公開鍵で確認し、ＣＥＲＴ＿Ｓに含まれるＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２の公開鍵の正当性と、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２のＩＰｖ６グローバル・アドレスと、その装置がＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒであることを確認する。
【０１０４】
次に、ＨＡＳＨ＿Ｉを計算し、受け取ったＳＩＧ＿Ｓ（ＨＡＳＨ＿ＩとＩＰ＿Ｉを連接したデータに対してＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２が生成したディジタル署名）が、ＨＡＳＨ＿Ｉと今までＩｎｉｔｉａｔｏｒ２０６と通信するときに使用していた宛先アドレスＩＰ＿Ｉ'（Ｓ１０３におけるＳＡ、Ｓ１０８におけるｙ＿ｒ、Ｎｒの宛先アドレス）に対するＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２の署名であることをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２の公開鍵で確認する。
【０１０５】
また、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２のＩＰｖ６グローバル・アドレスのｓｕｂｎｅｔ  ｐｒｅｆｉｘ（／６４）とＩＰ＿Ｉ'のｓｕｂｎｅｔ  ｐｒｅｆｉｘ（／６４）が同じであることも確認する。ＩＰｓｅｃ通信を行う装置２０６のＩＰアドレスが別装置であるｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２によって保証されていることを、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２が代行するＩＫＥにおいて用いられるｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２の証明書を用いて確認することにより、装置２０６と通信する相手であるホスト２０９は、装置２０６が使用しているＩＰアドレスの正当性を確認できる。確認が成功したら、Ｒｅｓｐｏｎｄｅｒ２０９は、ＨＡＳＨ＿Ｒを計算し、ＨＡＳＨ＿Ｒに対する署名ＳＩＧ＿Ｒを生成する。
【０１０６】
ステップＳ１１６でＲｅｓｐｏｎｄｅｒ２０９は、Ｉｎｉｔｉａｔｏｒ２０６との間で共有した暗号化鍵を用いてＩＤｉｒとＣＥＲＴ＿ＲとＳＩＧ＿Ｒを暗号化し、Ｉｎｉｔｉａｔｏｒ２０６宛に送る。ステップＳ１１７でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２はＲｅｓｐｏｎｄｅｒ２０９から受け取ったデータをＩｎｉｔｉａｔｏｒ２０６宛に送り、Ｉｎｉｔｉａｔｏｒ２０６は、Ｒｅｓｐｏｎｄｅｒ２０９からのデータを受け取る。ＣＥＲＴ＿Ｒは、Ｒｅｓｐｏｎｄｅｒの公開鍵証明書である。
【０１０７】
ステップＳ１１８でＩｎｉｔｉａｔｏｒ２０６は、受け取ったデータを、Ｒｅｓｐｏｎｄｅｒ２０９との間で共有した暗号化鍵を用いて復号する。そして、ＣＥＲＴ＿Ｒの正当性をＣＡの公開鍵で確認し、ＣＥＲＴ＿Ｒに含まれるＲｅｓｐｏｎｄｅｒ２０９の公開鍵の正当性を確認し、ＣＥＲＴ＿Ｒに含まれるＦＱＤＮもしくはＩＰｖ６アドレスが、ステップＳ１０１開始の際に用いたＦＱＤＮもしくはＩＰｖ６アドレスと等しいことを確認する。そして、ＨＡＳＨ＿Ｒを計算し、ＳＩＧ＿ＲがＨＡＳＨ＿Ｒに対するＲｅｓｐｏｎｄｅｒ２０９の署名であることをＲｅｓｐｏｎｄｅｒの公開鍵で確認する。
【０１０８】
以上の動作により、ＩＫＥのＰｈａｓｅ１が終了し、Ｉｎｉｔｉａｔｏｒ２０６とＲｅｓｐｏｎｄｅｒ２０９の間にＩＳＡＫＭＰ  ＳＡが確立・設定される。この後は、前述のようにＰｈａｓｅ２を実行し、ＩＰｓｅｃ  ＳＡを設定し、ＩＰｓｅｃ通信を行う。
【０１０９】
なお、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、他のノードによるＩｎｉｔｉａｔｏｒへのなりすましを検出すると、その検出の以降の処理を中止する。この中止の対象となる処理は、（ＳＡと）依頼計算結果ＺのＩｎｉｔｉａｔｏｒ２０６宛への送信（Ｓ１０４）、（ｙ＿ｉとＮｉのＲｅｓｐｏｎｄｅｒ２０６宛への転送（ステップＳ１０７））、依頼計算結果Ｚ'（とｙ＿ｒとＮｒ）のＩｎｉｔｉａｔｏｒ宛への送信（ステップＳ１０９）、ＣＥＲＴ＿ＳとＳＩＧ＿ＳのＩｎｉｔｉａｔｏｒ２０６宛への送信（ステップＳ１１２）である。ＩＰｓｅｃ通信を行う装置２０６と同じリンクに接続する別装置であるｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２が装置２０６のＩＰアドレスを監視することにより、装置２０６が使うＩＰアドレスを他の装置が使って装置２０６になりすまそうとする行為をリンク層のデータを用いて検出可能になる。
【０１１０】
以上のように、本実施例では、ホスト２０６は、通信装置であって、データを生成するＣＰＵ（生成手段）３０３と、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ（ディジタル署名の発行装置）２０２にその生成したデータを送信するネットワーク・インターフェイス（通信手段）３０１とを有する。ネットワーク・インターフェイス３０１は、その生成したデータ及びホスト２０６が使用中のアドレスとに対してｄｅｆａｕｌｔ  ｇａｔｅｗｙａ２０２により発行されたディジタル署名を受信して、その発行されたディジタル署名をホスト２０９に送信する。
【０１１１】
詳細には、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算を行い、装置が使用するＩＰアドレスと装置の対応関係を監視する。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、ＩＫＥ実行中の装置（Ｉｎｉｔｉａｔｏｒ２０６）によって生成されるデータＨＡＳＨとその装置２０６が使用中のＩＰアドレスとに対してディジタル署名を生成しその装置２０６に発行する。そのディジタル署名は、その監視を行う旨を記載した公開鍵証明書によって正当性が確認される。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２は、ＩＫＥ実行中の装置２０６が使用するＩＰアドレスを監視しながらその装置２０６の依頼に応じてＩｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）におけるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算を実行し、その装置２０６のＩＰアドレスとＨＡＳＨに対してディジタル署名を生成発行する。ＩＫＥ実行中の装置２０６は、その発行された署名をＩＫＥ通信相手（Ｒｅｓｐｏｎｄｅｒ２０９）に送り、ＩＫＥ通信相手２０９は、署名によってその装置２０６の使用するアドレスの正当性を確認する。その装置２０６は、ＩＫＥ通信相手２０９の署名によってＩＫＥ通信相手２０９の認証を行う。
【実施例２】
【０１１２】
実施例１では、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２（ルーター）がＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒとして機能した。本実施例では、図６を参照しながら、リンク２０７上のｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２（ルーター）以外のノード、例えばホスト２０４がＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒとして機能する場合の実施例のプロトコルの流れと動作の詳細な説明を行う。
【０１１３】
前提および基本的な流れは図１の実施例１と同じである。なお以下の処理内容（手順）は、プログラムもしくはモジュールとして実現され、そのプログラムがＲＯＭ３０４もしくはＨＤ３０６に格納されたノードが実行、もしくはそのモジュールを有するノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをコンピュータであるＣＰＵ３０３が読み込み、必要に応じてＲＡＭ３０５を計算のための空間として利用しながらバス３１０を介してインターフェイス３０１にアドレスを割当てる、というような動作を行う。モジュールの場合は、プログラムがＣＰＵやＲＡＭ等と協調して実行する上述の動作と同等の動作を実行する実体が、例えばＬＳＩとして実現され、ノードに組み込まれている。ノードのＣＰＵからモジュール（ＬＳＩ）へ指示が発行され、それをきっかけにモジュールが動作し、処理を実行する。
【０１１４】
Ｉｎｉｔｉａｔｏｒ２０６は、Ｒｅｓｐｏｎｄｅｒ２０９のＦＱＤＮからＤＮＳによってＲｅｓｐｏｎｄｅｒのＩＰｖ６アドレスを知った、あるいは別の手段でＲｅｓｐｏｎｄｅｒのＩＰｖ６アドレスを知ったと仮定し、Ｉｎｉｔｉａｔｏｒ２０６がＲｅｓｐｏｎｄｅｒ２０９とＩＰｓｅｃ通信を行おうとしている状態から動作を説明する。また、Ｉｎｉｔｉａｔｏｒ２０６はＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４のＩＰアドレスを知っているとする。
【０１１５】
ステップＳ６０１で、Ｉｎｉｔｉａｔｏｒ２０６が複数のＳＡプロポーサルをＲｅｓｐｏｎｄｅｒ２０９宛に送る。ステップＳ６０２でＲｅｓｐｏｎｄｅｒ２０９は、複数のＳＡのプロポーザルを受け取り、複数のＳＡのプロポーザルの中から使用するＳＡを選び、選択したＳＡをＩｎｉｔｉａｔｏｒ宛に送る。
【０１１６】
ステップＳ６０３でＩｎｉｔｉａｔｏｒ２０６は、ｙ＿ｉ＝ｇ＾ｘｉ  ｍｏｄ  ｐの依頼計算に必要なパラメータをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４に送る。ｙ＿ｉ＝ｇ＾ｘｉ  ｍｏｄ  ｐの依頼計算に必要なパラメータとは、図５の記号で言えばｐとＤとｇであるので、図６にそのように表す。
【０１１７】
ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、ｐとＤとｇを受け取り、他のノードがＩｎｉｔｉａｔｏｒになりすまさないように、Ｉｎｉｔｉａｔｏｒ２０６が使用するＩＰｖ６アドレスＩＰ＿Ｉの監視を開始する。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４からの依頼に応じて依頼計算を実行する。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、受け取ったｐとＤとｇからｙ＿ｉ＝ｇ＾ｘｉ  ｍｏｄ  ｐの依頼計算を行う。この依頼計算とは、図５で言えばステップＳ５０４の計算である。ステップＳ６０４でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４はＳＡと依頼計算結果をＩｎｉｔｉａｔｏｒ２０６宛に送る。依頼計算結果とは図５で言えばＺであるので、図６にＺと表す。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）実行中のＩｎｉｔｉａｔｏｒ２０６が使用するＩＰアドレスを監視しながらＩＫＥにおけるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算を実行する。
【０１１８】
ステップＳ６０５でＩｎｉｔｉａｔｏｒ２０６は依頼計算結果Ｚからｙ＿ｉを求める。図５で言えばステップＳ５０６においてｙ＿Ａを求める計算である。ステップＳ６０６でｙ＿ｉとＮ＿ｉをＲｅｓｐｏｎｄｅｒ２０９宛に送る。ステップＳ６０７でＲｅｓｐｏｎｄｅｒ２０９はｙ＿ｒとＮｒをＩｎｉｔｉａｔｏｒ２０６宛に送る。
【０１１９】
ステップＳ６０８で、Ｉｎｉｔｉａｔｏｒ２０６はｙ＿ｒ＾ｘｉ  ｍｏｄ  ｐの依頼計算に必要なパラメータをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４に送る。ｙ＿ｒ＾ｘｉ  ｍｏｄ  ｐの依頼計算に必要なパラメータとは、図５の記号で言えばｐとＤ'とｙ＿Ｂであるので、図６では、ｐとＤ'とｙ＿ｒと表す。ここで、図５のｙ＿Ｂは、ノードＢが計算したｇ＾（ｘ＿Ｂ）  ｍｏｄ  ｐであり、図６のｙ＿ｒは、Ｒｅｓｐｏｎｄｅｒ２０９が計算したｇ＾（ｘ＿ｒ）ｍｏｄ  ｐである。
【０１２０】
ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、ｐとＤ'とｙ＿ｒを受け取ると、ｙ＿ｒ＾ｘｉ  ｍｏｄ  ｐの依頼計算を行う。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４からの依頼に応じて依頼計算を実行する。この依頼計算とは、図５で言えばステップＳ５０９の計算である。ステップＳ６０９でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は依頼計算結果をＩｎｉｔｉａｔｏｒ２０６宛に送る。依頼計算結果とは、図５で言えばＺ'であるので、図６にＺ'と表す。
【０１２１】
Ｉｎｉｔｉａｔｏｒ２０６は、依頼計算結果Ｚ'を受け取り、それからＲｅｓｐｏｎｄｅｒ２０９とのＤＨの結果を求める。図５で言えばステップＳ５１１においてｙ＿ＡＢを求める計算である。すなわち、Ｉｎｉｔｉａｔｏｒ（通信装置）２０６は、Ｒｅｓｐｏｎｄｅｒ（通信相手）との間で、秘密データｙ＿ｉｒを共有する。それを基にしてＨＡＳＨ＿Ｉ（ハッシュ値）を計算する。すなわち、Ｒｅｓｐｏｎｄｅｒ（通信相手）２０９とｙ＿ｉｒ（第１のデータ）を共有する場合に、ｙ＿１ｓｔ（第２のデータ）をｒ＿１ｓｔ（第３のデータ）から依頼計算を用いて求め、Ｒｅｓｐｏｎｄｅｒ（通信相手）２０９がｙ＿ｒｉ（＝ｙ＿ｉｒ（第１のデータ））を求めるためのｙ＿ｉ（第４のデータ）を、ｙ＿１ｓｔ（第２のデータ）及びｙ＿ｉｎｉｔ（第５のデータ）から生成し、Ｒｅｓｐｏｎｄｅｒ（通信相手）と共有するｙ＿ｉｒ（第１のデータ）を、ｒ＿１ｓｔ（第３のデータ）及びｒ＿ｉｎｉｔ（第７のデータ）から生成されるｒ＿ｉｎｉｔ＋ｒ＿１ｓｔ（第６のデータ）から、依頼計算を用いて求める。このように代理計算するので、代理計算するＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０２に鍵を知られずに済む。
【０１２２】
ステップＳ６１０でＨＡＳＨ＿ＩをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４（ディジタル署名の発行装置）に送る。すなわち、Ｉｎｉｔｉａｔｏｒ２０６は、図３のように構成され、データであるＨＡＳＨ＿Ｉを生成するＣＰＵ（生成手段）３０３、及び、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４（ディジタル署名の発行装置）に、データであるＨＡＳＨ＿Ｉを送信するネットワーク・インターフェイス（通信手段）３０１を有する。ＣＰＵ３０３は、鍵生成のためにＲｅｓｐｏｎｄｅｒ（通信相手）２０９と交換したデータを元に、鍵（Ｒｅｓｐｏｎｄｅｒ２０９との間で共有した暗号化鍵）及びＨＡＳＨ＿Ｉ（データ）を生成する。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、Ｒｅｓｐｏｎｄｅｒ（第１の装置）２０９と暗号通信を行うＩｎｉｔｉａｔｏｒ（第２の装置）２０６からＨＡＳＨ＿Ｉ（データ）を受信する。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、Ｒｅｓｐｏｎｄｅｒ（第１の装置）２０９と暗号通信を行うＩｎｉｔｉａｔｏｒ（第２の装置）２０６にディジタル署名を発行するディジタル署名発行装置である。
【０１２３】
ステップＳ６１１でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４はＨＡＳＨ＿Ｉ（ハッシュ値）とＩＰ＿Ｉ（Ｉｎｉｔｉａｔｏｒ２０６が使用中のＩＰアドレス）に対して、暗号鍵によりディジタル署名を計算する。ＩＰ＿Ｉは、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４がステップＳ６０３から監視している、Ｉｎｉｔｉａｔｏｒが使用しているＩＰｖ６アドレスである。ＨＡＳＨ＿ＩとＩＰ＿Ｉを連接したデータに対するディジタル署名ＳＩＧ＿Ｓを生成する。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、Ｉｎｉｔｉａｔｏｒ２０６と通信するネットワーク・インターフェイス（通信手段）３０２と、Ｉｎｉｔｉａｔｏｒ２０６から受信したデータＨＡＳＨ＿ＩとＩｎｉｔｉａｔｏｒ２０６が使用しているアドレスＩＰ＿Ｉに対して秘密鍵によりディジタル署名ＳＩＳ＿Ｓを生成するＣＰＵ（生成手段）３０３を有する。
【０１２４】
ステップＳ６１２でＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４はＣＥＲＴ＿Ｓ（ディジタル署名に使用した秘密鍵に対応する公開鍵の証明書）とＳＩＧ＿ＳをＩｎｉｔｉａｔｏｒ２０６宛に送る。ＣＥＲＴ＿ＳはＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４の公開鍵証明書である。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、秘密鍵に対応する公開鍵の証明書ＣＥＲＴ＿Ｓ、及び、生成したディジタル署名ＳＩＧ＿ＳをＩｎｉｔｉａｔｏｒ２０６に送信する。この公開鍵証明書ＣＥＲＴ＿Ｓは、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ（公開鍵と秘密鍵を有する装置）２０４が用いるＩＰアドレスと、公開鍵と、署名生成を行う装置であることを定義する情報をも含む。生成したデータであるＨＡＳＨ＿Ｉ及びＲｅｓｐｏｎｄｅｒ（通信装置）２０６が使用中のアドレスＩＰ＿Ｉとに対してＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ（ディジタル署名の発行装置）２０２により発行されたディジタル署名ＳＩＧ＿Ｓを、Ｉｎｉｔｉａｔｏｒ２０６は、ネットワーク・インターフェイス３０１により、受信する。
【０１２５】
ステップＳ６１３でＩｎｉｔｉａｔｏｒ２０６は、Ｒｅｓｐｏｎｄｅｒ２０９との間で共有した暗号化鍵を用いてＩＤｉｉと公開鍵証明書ＣＥＲＴ＿Ｓとディジタル署名ＳＩＧ＿Ｓを暗号化し、Ｒｅｓｐｏｎｄｅｒ２０９宛に送る。Ｉｎｉｔｉａｔｏｒ２０６のＣＰＵ３０３は、ディジタル書名ＳＩＧ＿Ｓ（及び公開鍵証明書ＣＥＲＴ＿Ｓ）を、鍵（Ｒｅｓｐｏｎｄｅｒ２０９との間で共有した暗号化鍵）を用いて暗号化する。そして、公開鍵証明書ＳＩＧ＿Ｓ（及びＣＥＲＴ＿Ｓ）を、ネットワーク・インターフェイス３０１からＲｅｓｐｏｎｄｅｒ（通信相手）２０９に送信する。
【０１２６】
ステップＳ６１４でＲｅｓｐｏｎｄｅｒ２０９は、受け取ったデータを、Ｉｎｉｔｉａｔｏｒ２０６との間で共有した暗号化鍵を用いて復号する。そして、ＣＥＲＴ＿Ｓの正当性をＣＡの公開鍵で確認し、ＣＥＲＴ＿Ｓに含まれるＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４の公開鍵の正当性と、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４のＩＰｖ６グローバル・アドレスと、その装置がＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒであることを確認する。
【０１２７】
次に、ＨＡＳＨ＿Ｉを計算し、受け取ったＳＩＧ＿Ｓが、ＨＡＳＨ＿Ｉと今までＩｎｉｔｉａｔｏｒ２０６と通信するときに使用していた宛先アドレスＩＰ＿Ｉ'（Ｓ６０２のＳＡ、Ｓ６０７のｙ＿ｒ、Ｎｒの宛先アドレス）に対するＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒの署名であることをＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４の公開鍵で確認する。また、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４のＩＰｖ６グローバル・アドレスのｓｕｂｎｅｔ  ｐｒｅｆｉｘ（／６４）とＩＰ＿Ｉのｓｕｂｎｅｔ  ｐｒｅｆｉｘ（／６４）が同じであることも確認する。ＩＰｓｅｃ通信を行う装置２０６のＩＰアドレスが別装置であるＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４によって保証されていることを、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４が代行するＩＫＥにおいて用いられるＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４の証明書を用いて確認することにより、装置２０６と通信する相手であるＲｅｓｐｏｎｄｅｒ２０９は、装置２０６が使用しているＩＰアドレスの正当性を確認できる。確認が成功したら、Ｒｅｓｐｏｎｄｅｒ２０９は、ＨＡＳＨ＿Ｒを計算し、ＨＡＳＨ＿Ｒに対する署名ＳＩＧ＿Ｒを生成する。
【０１２８】
ステップＳ６１５でＲｅｓｐｏｎｄｅｒ２０９は、Ｉｎｉｔｉａｔｏｒ２０６との間で共有した暗号化鍵を用いてＩＤｉｒとＣＥＲＴ＿ＲとＳＩＧ＿Ｒを暗号化し、Ｉｎｉｔｉａｔｏｒ２０６宛に送る。
【０１２９】
ステップＳ６１６でＩｎｉｔｉａｔｏｒ２０６は、Ｒｅｓｐｏｎｄｅｒ２０９からのデータを受け取り、受け取ったデータを、Ｒｅｓｐｏｎｄｅｒ２０９との間で共有した暗号化鍵を用いて復号する。そして、ＣＥＲＴ＿Ｒの正当性をＣＡの公開鍵で確認し、ＣＥＲＴ＿Ｒに含まれるＲｅｓｐｏｎｄｅｒ２０９の公開鍵の正当性を確認し、ＣＥＲＴ＿Ｒに含まれるＦＱＤＮもしくはＩＰｖ６アドレスが、ステップＳ６０１開始の際に用いたＦＱＤＮもしくはＩＰｖ６アドレスと等しいことを確認する。そして、ＨＡＳＨ＿Ｒを計算し、ＳＩＧ＿ＲがＨＡＳＨ＿Ｒに対するＲｅｓｐｏｎｄｅｒ２０９の署名であることをＲｅｓｐｏｎｄｅｒ２０９の公開鍵で確認する。
【０１３０】
以上の動作により、ＩＫＥのＰｈａｓｅ１が終了し、ＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒの間にＩＳＡＫＭＰ  ＳＡが確立・設定される。この後は、前述のようにＰｈａｓｅ２を実行し、ＩＰｓｅｃ  ＳＡを設定し、ＩＰｓｅｃ通信を行う。
【０１３１】
なお、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、他のノードによるＩｎｉｔｉａｔｏｒへのなりすましを検出すると、その検出の以降の処理を中止する。この中止の対象となる処理は、依頼計算結果ＺのＩｎｉｔｉａｔｏｒ２０６宛への送信（Ｓ６０４）、依頼計算結果Ｚ'のＩｎｉｔｉａｔｏｒ宛への送信（ステップＳ６０９）、ＣＥＲＴ＿ＳとＳＩＧ＿ＳのＩｎｉｔｉａｔｏｒ２０６宛への送信（ステップＳ６１２）である。ＩＰｓｅｃ通信を行う装置２０６と同じリンクに接続する別装置であるホスト２０４が装置２０６のＩＰアドレスを監視することにより、装置２０６が使うＩＰアドレスを他の装置が使って装置２０６になりすまそうとする行為をリンク層のデータを用いて検出可能になる。
【０１３２】
本実施例でも、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算を行い、装置が使用するＩＰアドレスと装置の対応関係を監視する。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、ＩＫＥ実行中の装置（Ｉｎｉｔｉａｔｏｒ２０６）によって生成されるデータＨＡＳＨとその装置２０６が使用中のＩＰアドレスとに対してディジタル署名を生成しその装置２０６に発行する。そのディジタル署名は、その監視を行う旨を記載した公開鍵証明書によって正当性が確認される。ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒ２０４は、ＩＫＥ実行中の装置２０６が使用するＩＰアドレスを監視しながらその装置２０６の依頼に応じてＩｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）におけるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算を実行し、その装置２０６のＩＰアドレスとＨＡＳＨに対してディジタル署名を生成発行する。ＩＫＥ実行中の装置２０６は、その発行された署名をＩＫＥ通信相手（Ｒｅｓｐｏｎｄｅｒ２０９）に送り、ＩＫＥ通信相手２０９は、署名によってその装置２０６の使用するアドレスの正当性を確認する。その装置２０６は、ＩＫＥ通信相手２０９の署名によってＩＫＥ通信相手２０９の認証を行う。
【実施例３】
【０１３３】
実施例１、２では、依頼計算とディジタル署名の作成を、同じ装置が実行したが、別の装置が実行するように、構成してもよい。
【０１３４】
例えば、依頼計算は、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２が実行し、ディジタル署名の作成は、ホスト２０４が実行する。この例では、図１において、ホスト２０６は、ステップＳ１１０とＳ１１２の通信を、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２ではなく、ホスト２０４との間で行う。
【０１３５】
また、例えば、依頼計算は、ホスト２０４が実行し、ディジタル署名の作成は、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２が実行する。この例では、図６において、ホスト２０６は、ステップＳ６１０とＳ６１２の通信を、ホスト２０４ではなく、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２との間で行う。
【０１３６】
また、リンク２０７上のｄｅｆａｕｌｔ  ｇａｔｅｗａｙ２０２（ルーター）以外の２つのノードが、依頼計算とディジタル署名の作成を、分担して実行してもよい。この例では、図６において、ホスト２０６は、ステップＳ６１０とＳ６１２の通信を、ホスト２０４以外のホストとの間で行う。
【０１３７】
なお、Ｒｅｓｐｏｎｄｅｒが、ＩＫＥ  Ｐｒｏｘｙ  Ｓｅｒｖｅｒに、署名の作成（及び、公開鍵証明書、依頼計算）を依頼してもよい。
【図面の簡単な説明】
【０１３８】
【図１】第１の実施例においてｄｅｆａｕｌｔ  ｇａｔｅｗａｙがＩＫＥ代行する場合のプロトコル図である。
【図２】イーサネット（登録商標）ＬＡＮの模式図である。
【図３】ノードの構成図である。
【図４】Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ  Ｐｕｂｌｉｃ−ｋｅｙ  Ｄｉｓｔｒｉｂｕｔｉｏｎ  Ｓｃｈｅｍｅの図である。
【図５】ＤＨ依頼計算のプロトコルの図である。
【図６】第２の実施例においてｄｅｆａｕｌｔ  ｇａｔｅｗａｙではない装置がＩＫＥ代行する場合のプロトコル図である。
【図７】ディジタル署名で相手確認する場合のＩＫＥのＰｈａｓｅ１の図である。
【図８】ＩＫＥのＰｈａｓｅ２（Ｑｕｉｃｋ  Ｍｏｄｅ）の図である。
【図９】ＩＰｓｅｃのトンネル・モードの模式図である。
【符号の説明】
【０１３９】
２０１  インターネット
２０２  ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ
２０３  ＤＨＣＰサーバ
２０４  ホスト
２０５  ホスト
２０６  ホスト
【図１】
2005210285.tif 000003
【図２】
2005210285.tif 000004
【図３】
2005210285.tif 000005
【図４】
2005210285.tif 000006
【図５】
2005210285.tif 000007
【図６】
2005210285.tif 000008
【図７】
2005210285.tif 000009
【図８】
2005210285.tif 000010
【図９】
2005210285.tif 000011
【手続補正書】
【提出日】平成16年11月19日(2004.11.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
通信装置であって、
データを生成する生成手段と、
ディジタル署名の発行装置に前記生成したデータを送信する通信手段とを有し、
前記通信手段は、前記生成したデータ及び当該通信装置が使用中のアドレスとに対して前記ディジタル署名の発行装置により発行されたディジタル署名を受信して、前記発行されたディジタル署名を通信相手に送信することを特徴とする通信装置。
【請求項２】
前記生成手段は、鍵生成のために前記通信相手と交換したデータを元に、鍵及び前記データを生成し、前記通信手段は、前記発行されたディジタル署名を、前記鍵を用いて暗号化して、前記通信相手に送信することを特徴とする請求項１記載の通信装置。
【請求項３】
装置からの依頼に応じて暗号化に用いる秘密データを共有するための依頼計算を実行するステップと、
前記装置によって生成されるデータと前記装置が使用中のアドレスとに対してディジタル署名を生成し前記装置に発行するステップとを実行することを特徴とするディジタル署名発行方法。
【請求項４】
前記実行ステップでは、Ｉｎｔｅｒｎｅｔ  Ｋｅｙ  Ｅｘｃｈａｎｇｅ（ＩＫＥ）実行中の装置が使用するＩＰアドレスを監視しながら前記装置の依頼に応じてＩＫＥにおけるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式の依頼計算を実行することを特徴とする請求項３記載のディジタル署名発行方法。
【請求項５】
前記発行ステップは、前記装置によって生成されるハッシュ値と前記装置が使用中のＩＰアドレスとに対してディジタル署名を生成し前記装置に発行することを特徴とする請求項３記載のディジタル署名発行方法。
【請求項６】
公開鍵と秘密鍵を有する装置が用いるＩＰアドレスと、前記公開鍵と、前記署名生成を行う装置であることを定義する情報を含む公開鍵証明書を、ＩＫＥを実行する前記装置に提供することを特徴とする請求項３記載のディジタル署名発行方法。
【請求項７】
前記装置のデフォルトゲートウエイ上で実行されることを特徴とする請求項３記載のディジタル署名発行方法。
【請求項８】
第１の装置と暗号通信を行う第２の装置からデータを受信する受信ステップと、
前記受信したデータと前記第２の装置が使用しているアドレスに対して秘密鍵によりディジタル署名を生成する生成ステップと、
前記秘密鍵に対応する公開鍵の証明書、及び、前記生成したディジタル署名を前記第２の装置に送信する送信ステップとを実行することを特徴とするディジタル署名発行方法。
【請求項９】
第１の装置と暗号通信を行う第２の装置にディジタル署名を発行するディジタル署名発行装置であって、
前記第２の装置と通信する通信手段と、
前記第２の装置から受信したデータと前記第２の装置が使用しているアドレスに対して秘密鍵によりディジタル署名を生成する生成手段を有し、
前記通信手段は、前記秘密鍵に対応する公開鍵の証明書、及び、前記生成したディジタル署名を前記第２の装置に送信することを特徴とするディジタル署名発行装置。
【請求項１０】
通信装置が通信相手にディジタル署名を送信する送信方法であって、
前記通信相手との間で、秘密データを共有し、
前記秘密データを元に、ハッシュ値を計算し、
前記ハッシュ値を、ディジタル署名の発行装置に送信し、
前記ハッシュ値及び前記通信装置のアドレスに対して生成されたディジタル署名を前記ディジタル署名の発行装置から受信し、
前記ディジタル署名を前記通信相手に送信することを特徴とするディジタル署名送信方法。
【請求項１１】
請求項３から８のいずれか１項のディジタル署名発行方法又は請求項１０のディジタル署名の送信方法を実行するプログラム。
【請求項１２】
公開鍵と秘密鍵を有する装置が用いるＩＰアドレスと、前記公開鍵を証明書の内容として含む公開鍵証明書であって、請求項３記載のディジタル署名発行方法における前記署名生成を行う装置であることを定義する情報をも含むことを特徴とする公開鍵証明書。