(57)【要約】【課題】ＩＰｖ６通信が可能なＩＰｖ６対応装置に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。また、エンティティＡと同じＬＡＮ上のエンティティＣがエンティティＡになりすますこともありうる。【解決手段】ホスト２０６は、ゲートウェイ２０２又はＤＨＣＰサーバー２０３と通信して、ＩＰｖ６アドレスを決めるとともに、ゲートウェイ２０２又はＤＨＣＰサーバー２０３から公開鍵証明書を受け取る。更に、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を送る。ホスト２０６は、必要に応じて、新たな公開証明書をゲートウェイ２０２又はＤＨＣＰサーバー２０３から受け取ることにより、プライバシ保護を実現し、更に、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を贈ることにより、なりすましを防ぐ。【選択図】　　　　図２
2004007512.tif 000002
【特許請求の範囲】
【請求項１】
第一の公開鍵の証明書を生成する生成手段と、
前記生成手段により生成された第一の公開鍵の証明書を提供する提供手段とを有し、
前記生成手段により生成される第一の公開鍵の証明書は、認証サービス提供者により発行された第二の公開鍵の証明書、及び、第二の公開鍵を用いて正当性が確認可能なディジタル署名を含むことを特徴とする公開鍵証明書提供装置。
【請求項２】
請求項１の公開鍵証明書提供装置において、前記提供手段は、サブネット内のホストに、第一の公開鍵証明書を提供することを特徴とする公開鍵証明書提供装置。
【請求項３】
請求項１の公開鍵証明書提供装置において、前記提供手段は、ホストに、第一の公開鍵証明書、及び、ホストのアドレスを決定するための情報を提供することを特徴とする公開鍵証明書提供装置。
【請求項４】
請求項１の公開鍵証明書提供装置において、前記提供手段により第一の公開鍵の証明書が提供されるホストを、インターネットに接続する接続手段を、更に有することを特徴とする公開鍵証明書提供装置。
【請求項５】
第一の公開鍵の証明書を生成し、
生成された第一の公開鍵の証明書を提供する公開鍵証明書提供プログラムであって、
前記生成ステップで生成される第一の公開鍵の証明書は、認証サービス提供者により発行された第二の公開鍵の証明書、及び、第二の公開鍵を用いて正当性が確認可能なディジタル署名を含むことを特徴とする公開鍵証明書提供プログラム。
【請求項６】
請求項５の公開鍵証明書提供プログラムにおいて、前記提供ステップは、サブネット内のホストに、第一の公開鍵証明書を提供することを特徴とする公開鍵証明書提供プログラム。
【請求項７】
請求項５の公開鍵証明書提供プログラムにおいて、前記提供ステップは、ホストに、第一の公開鍵証明書、及び、ホストのアドレスを決定するための情報を提供することを特徴とする公開鍵証明書提供プログラム。
【請求項８】
請求項５の公開鍵証明書提供プログラムにおいて、前記提供ステップにより第一の公開鍵の証明書が提供されるホストを、インターネットに接続する接続ステップを、更に有することを特徴とする公開鍵証明書提供プログラム。
【請求項９】
アドレスを決めるための情報、及び、第一の公開鍵の証明書を、サブネット内のホストに提供する提供手段を、サブネット内に設けた公開鍵証明書提供装置であって、
第一の公開鍵の証明書を生成する生成手段を、更に有し、
前記生成手段により生成される第一の公開鍵の証明書は、認証サービス提供者により発行された第二の公開鍵の証明書、及び、第二の公開鍵を用いて正当性が確認可能なディジタル署名を含むことを特徴とする公開鍵証明書提供装置。
【請求項１０】
インターネットを接続するインターネット接続手段、
ホストと接続するホスト接続手段と、
第一の公開鍵の証明書を提供する提供手段とを有し、
前記提供手段により提供される第一の公開鍵の証明書は、認証サービス提供者により発行された第二の公開鍵の証明書、及び、第二の公開鍵を用いて正当性が確認可能なディジタル署名を含むことを特徴とする接続装置。
【請求項１１】
通信手段と、
第一の相手との通信の結果により、自分のアドレスを決定する決定手段とを有し、
前記通信手段は、第一の相手から受信された公開鍵証明書を、第二の相手と暗号通信を行なうために、第二の相手に通知することを特徴とする通信装置。
【請求項１２】
第一の相手との通信の結果により、自分のアドレスを決定し、
第一の相手から受信された公開鍵証明書を、第二の相手と暗号通信を行なうために、第二の相手に通知することを特徴とする通信プログラム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、公開鍵証明書を提供する提供装置に関する。
【０００２】
【従来の技術】
ＩＰｖ６の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けディジタルカメラである。
【０００３】
ＩＰｖ６に対応するパーソナル・コンピュータやワークステーションの場合、ネットワークとの接続のインターフェイスには通常はイーサネット（Ｒ）が用いられ、それが持つ　ＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）を元にしてＩＰｖ６アドレスが構成されるようになっている。
【０００４】
ＩＰｖ６アドレスには、後述するようにリンクローカルアドレス、サイトローカルアドレスと（集約可能）、グローバルアドレスの３種類が存在する。
【０００５】
それらの詳細や構成方法などのアドレス体系は、ＲＦＣ　２３７３　｀｀ＩＰ　Ｖｅｒｓｉｏｎ　６　Ａｄｄｒｅｓｓｓｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ、’’　ＲＦＣ　２３７４　｀｀Ａｎ　ＩＰｖ６　Ａｇｇｒｅｇａｔａｂａｌｅ　Ｇｌｏｂａｌ　Ｕｎｉｃａｓｔ　Ａｄｄｒｅｓｓ　Ｆｏｒｍａｔ、’’　ＲＦＣ　２３７５　｀｀ＩＰｖ６　Ｍｕｌｔｉｃａｓｔ　Ａｄｄｒｅｓｓ　Ａｓｓｉｇｎｍｅｎｔ、’’　ＲＦＣ　２４５０　｀｀Ｐｒｏｐｏｓｅｄ　ＴＬＡ　ａｎｄ　ＮＬＡ　Ａｓｓｉｇｎｍｅｎｔ　Ｒｕｌｅ、’’　ＲＦＣ　２４６１　｀｀Ｎｅｉｇｈｂｏｒ　Ｄｉｓｃｏｖｅｒｙ　ｆｏｒ　ＩＰ　Ｖｅｒｓｉｏｎ　６　（ＩＰｖ６）、’’　ＲＦＣ　２４６２　｀｀ＩＰｖ６　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、’’　等に記述されている。
【０００６】
ところで、ＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）のようにハードウェアに１対１に対応する情報を固定的に用いると、それが装置もしくはその装置のユーザと１対１に対応する情報とみなされ、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。
【０００７】
この課題に対しては、ランダムなＩＰｖ６アドレス（正確にはインターフェイスＩＤ）を生成する方法が、ＲＦＣ３０４１　｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒ　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’　等において提案されている。
【０００８】
生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算／生成し、ユニークなランダムな値を定めるプロトコル（の拡張）も記述されている。
【０００９】
上記のような解決方法を利用して生成したランダムなＩＰｖ６アドレスを装置が使う場合に、ＩＰｓｅｃを用いて暗号通信を行なうことを考える。
【００１０】
ＩＰｓｅｃは、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであり、通信に際して秘密データやお互いのＩＰｖ６アドレス等を安全に共有する必要がある。秘密データやお互いのＩＰｖ６アドレス等のデータはＳＡ（Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）と呼ばれる。
【００１１】
ＳＡを安全に共有するプロトコルはＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）と呼ばれ、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ　（ＩＫＥ）’’において規定されている。ここで、ＳＡを安全に共有するという意味は、意図する相手のみと確実にＳＡを共有するという意味であり、相手を確実に認証することを必要とする。ＩＫＥには、１）　ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙを用いる方法、２）　ディジタル署名を用いる方法、３）公開鍵暗号による暗号化による方法、４）公開鍵暗号による暗号化の改訂モードによる方法、の計４つの認証方法が規定されている。
【００１２】
ところが、プライバシ保護（身元を明らかにする情報を与えない）を実現する状況を考えると、例えばユーザが買い物サイトとのＩＰｓｅｃ通信を行なうような場合は、買い物サイトの立場で考えれば、あらかじめ定まっていない不特定多数の通信相手と　ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ　をＩＰｓｅｃ通信に先だって共有することは現実には不可能であるから、ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ　を用いる方法は使えない。
【００１３】
その他の方法の場合は、ディジタル署名あるいは公開鍵暗号の使用に必要な情報（多くの場合は公開鍵）を確実に入手可能ならば、不特定多数の通信相手同士でＩＫＥを実行することが可能である。そのために最も有望視されているのが、ＰＫＩ（Ｐｕｂｌｉｃ−ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）と呼ばれる環境・仕組みであり、その中で中心的な役割を果たすのが、公開鍵証明書である。
【００１４】
公開鍵証明書は、信頼できる第三者がエンティティ（通信をする主体、計算機や人間）とそのエンティティの公開鍵の対応関係を確認し、それを保証するために、エンティティのＩＤ情報等と公開鍵の組みに対して信頼できる第三者が発行するディジタル署名である。信頼できる第三者はＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）と呼ばれ、ＣＡのディジタル署名の正当性を確認するための公開鍵は、広く一般に知られている。
【００１５】
しかし、現在運用されている公開鍵証明書の中には、その持ち主（Ｓｕｂｊｅｃｔ）を示すＩＤ情報、例えば、ＦＱＤＮ（Ｆｕｌｌｙ　Ｑｕａｌｉｆｉｅｄ　Ｄｏｍａｉｎ　Ｎａｍｅ）が含まれるので、そのままではプライバシ保護を実現できない。
【００１６】
公開鍵証明書の中にその持ち主のＩＤ情報を含めない方法も考えられ、匿名公開鍵証明書と呼ばれる。
【００１７】
しかし、匿名公開鍵証明書にも上述のＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）と同じ課題が存在する。つまり、同一の匿名公開鍵証明書を使い続ける限り、複数の（公開鍵証明書に基づくＩＰｓｅｃ等の）通信を結び付けることは可能であり、もしも一度でも匿名公開鍵証明書とその持ち主の対応関係が明らかになったときは、プライバシが侵害されることにつながるので、やはりプライバシ保護の程度は弱い。
【００１８】
以上の課題に対して、例えば、異なる通信相手と通信する際に異なるＩＰｖ６アドレスおよび匿名公開鍵証明書を使うことが可能ならば、強いプライバシ保護が実現できると考えられる。これらを使い捨てＩＰｖ６アドレスおよび使い捨て匿名公開鍵証明書と呼ぶ。使い捨てる間隔としては、通信相手が変る度に新しい使い捨てＩＰｖ６アドレスを用いる、あるいはパケット毎に変えるなど、いくつかが考えられる。
【００１９】
【発明が解決しようとする課題】
しかしながら、使い捨てＩＰｖ６アドレスに関しては、前述のＲＦＣ３０４１｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒ　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’　が知られているが、ＩＰｖ６通信が可能な装置（以下では、ＩＰｖ６対応装置と表す）に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。
【００２０】
さらに、次の課題も存在する。すなわち、通信相手のＩＤ情報がわからない場合、通信相手の識別はＩＰアドレスでのみ行なうことになる。しかし、例えばイーサネット（Ｒ）のＬＡＮ上で送受されるパケットはそのＬＡＮ上のノード全てがアクセスできるので、本来はエンティティＡとエンティティＢが通信をするはずのところを、Ａと同じＬＡＮ上の悪意を持ったＣがＡになりすますこともありうる。つまり、ＡとＢの間で使い捨て匿名公開鍵証明書に基づくＩＰｓｅｃ通信を行なうために、Ａの公開鍵証明書がＢに送られる際に、Ａの公開鍵証明書をＣのものとすり替えることでＣはＡに成りすますことができてしまう。
【００２１】
ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバーやルーターに対してＤｏＳ（Ｄｅｎｉａｌ　ｏｆ　Ｓｅｒｖｉｃｅｓ）攻撃を加え、その間に偽のＤＮＳサーバーやルーターが偽の情報を与えるようにすれば、ＬＡＮに限定されないより広域な範囲でのなりすましも可能となる。通信相手のＩＤが判明していれば、それを確認することで対処できたが、上記に示したような匿名性の高い状況において、この種の攻撃を防ぐ方法は今まで知られていない。
【００２２】
本発明の他の目的は、ＩＰｖ６対応装置が用いるＩＰｖ６アドレスの一意性を公開鍵証明書発行者が容易に確認することを可能とし、その上で公開鍵証明書を発行できるようにすることにある。
【００２３】
本発明の他の目的は、ＩＰｖ６アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することにある。
【００２４】
本発明の他の目的は、ＩＰｖ６アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を利用して、ＩＫＥ及びＩＰｓｅｃ通信を行なうことにある。
【００２５】
本発明の他の目的は、ランダムなＩＰｖ６アドレスを含む、毎回異なる匿名公開鍵証明書を使うＩＰｓｅｃ通信が効率的に実現可能とし、強力なプライバシ保護を実現し、かつなりすましを防ぐことができるようにすることにある。
【００２６】
【課題を解決するための手段】
上記課題を解決するために、本出願に関わる発明は、ＩＰｖ６対応装置が位置するローカルリンク内に存在するＩＰｖ６対応装置を公開鍵証明書発行者として運用することを特徴とする。
【００２７】
【発明の実施の形態】
（第１の実施の形態）
本実施の形態では、ホストがイーサネット（Ｒ）のＬＡＮ経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本実施の形態を説明する。
【００２８】
図２は、本発明が適用される接続環境（ホストがイーサネット（Ｒ）のＬＡＮ経由でインターネットと接続する環境）を模式的に示したものである。
【００２９】
図２は、ＬＡＮに接続されたホスト２０４、２０５、２０６が　ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ゲートウェイ）２０２経由でインターネット２０１にアクセスする環境を示す。本実施の形態では、各ホストはリンク２０７で接続するものとし、リンク２０７は具体的にはイーサネット（Ｒ）であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、ＩＰ層の下側に接する。リンクにはイーサネット（Ｒ）の他に、ＰＰＰリンク、Ｘ．２５、フレームリレー、ＡＴＭネットワークがある。
【００３０】
リンクに接続されたＩＰｖ６対応装置をノードと呼ぶ。
【００３１】
ノードの内部構成の典型例を図３に示す。
【００３２】
ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノード３００は、ネットワーク・インターフェイス３０１、３０２、ＣＰＵ３０３、ＲＯＭ３０４、ＲＡＭ３０５、ＨＤ（ハードディスク）３０６、電源３０７、キーボード／ポインティングデバイスのインターフェイス３０８、モニターのインターフェイス３０９、バス３１０等を有する計算機である。
【００３３】
ルーターは複数のネットワーク・インターフェイス３０１、３０２を持つのに対し、ホストは多くの場合は一つのネットワーク・インターフェイス３０１を持つ。ホスト２０４、２０５、２０６は、ネットワーク・インターフェイス３０１により、リンク２０７を介して、リンク２０７に接続された他のノード、あるいは、更に、ゲートウェイ２０２を介して、インターネット２０１上のサイトと通信する。ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は、ネットワーク・インターフェイス３０１により、リンク２０７に接続された他のノードと通信すると共に、ネットワーク・インターフェイス３０２により、インターネット２０１を介して、通信する。ノードによってはＨＤを持たないものもある。
【００３４】
なお以下の処理内容（手順）は、装置もしくはプログラムとして実現され、その装置を有するノードが実行、もしくはそのプログラムがＲＯＭ　３０４もしくはＨＤ　３０６に格納されたノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをコンピュータであるＣＰＵ　３０３が読み込み、必要に応じてＲＡＭ　３０５を計算のための空間として利用しながらバス３１０を介してインターフェイス３０１にアドレスを割当てる、というような動作を行なう。
【００３５】
ここでは、ノード３００がアドレスをインターフェイスに割当てる、というように手順の本質を説明する。
【００３６】
本実施の形態におけるイーサネット（Ｒ）ＬＡＮ環境で各ホストがＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２のアドレスを取得するプロトコルの仕組みを簡単に説明し、その次に本発明を適用した具体的な実施の形態を説明する。
【００３７】
図２のリンク２０７に接続されたノード３００が、電源を入れられたあるいはリブートされた場合に行なう動作のフローチャートを図８に示す。この動作はＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）と呼ばれる。以下では図８の流れに沿って、ノード３００がＤＡＤを終えるまでの処理内容を説明する。
【００３８】
ステップＳ８０１でノード３００が電源を入れられたあるいはリブートされた後、まずインターフェイス３０１に割当てられているイーサネット（Ｒ）の　ＭＡＣ　ａｄｄｒｅｓｓ（ＭＡＣアドレス）（図４参照）からインターフェイスＩＤ（図５参照）を作成し、それをｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ（図６参照）とする（ステップＳ８０２）。
【００３９】
次に、そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓがリンク上で一意かどうかを判断するために、ノード（ホスト）３００は以下の処理を行なう。
【００４０】
最初に、インターフェイス３０１の初期設定をする。すなわち、インターフェイス３０１に、ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ（ＦＦ０２：：１）とそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　を割当てる（図７参照）。この結果、そのインターフェイス３０１は、ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ宛のパケットあるいはそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　宛のパケットを見つけたときはそれを自分のインターフェイス宛のパケットとして受け取る。
【００４１】
前者（ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ）を割当てることによって、既にそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを使っている他のノードからのデータを受信することが可能になる。また、後者（そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ）を割当てることによって、同じｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを同時に使おうとしている他のノードの存在を検出することが可能になる。
【００４２】
あるｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　とは、ＲＦＣ２４６１のｐａｇｅ　９１に定義されているように、ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓの下位２４ビットをプレフィックスＦＦ０２：０：０：０：０：１：ＦＦ００：：／１０４に付加したデータであり、ｌｉｎｋ−ｌｏｃａｌ　ｓｃｏｐｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　である。図６と図７にそれらの関係を示す。以上のアドレス割当てが図８のステップＳ８０３である。
【００４３】
次に　Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　を作る。Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　の　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓ（ターゲット　アドレス）には判断対象のｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを、ＩＰ　Ｓｏｕｒｃｅ（送信元アドレス）には　ｕｎｓｐｅｃｉｆｉｅｄ　ａｄｄｒｅｓｓ（１２８ビット全てが０）を、ＩＰ　ｄｅｓｔｉｎａｔｉｏｎ（宛先アドレス）には判断対象のｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓを設定する。
【００４４】
この　Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　をＲｅｔｒａｎｓＴｉｍｅｒミリセカンド間隔で、　ＤｕｐＡｄｄｒＤｅｔｅｃｔＴｒａｎｓｍｉｔｓ個イーサネット（Ｒ）（リンク）２０７に送出する。図８のステップＳ８０４がこの処理である。
【００４５】
Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取ったノードは、その送信元アドレスが　ｕｎｓｐｅｃｉｆｉｅｄ　ａｄｄｒｅｓｓ　ならば、その　ｍｅｓｓａｇｅ　がＤＡＤを行っているノードからのデータであると判断する。
【００４６】
同時に複数のノードが同じアドレスを対象としてＤＡＤをしている場合、そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　を割当てられた複数のノードが、同じアドレスを　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓに含む複数のＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅｓを受け取る（自分が送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅと、同時にそのアドレスを対象としてＤＡＤをしている他のノードが送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取る）ので、重複していることがわかる。その場合にはどのノードもそのアドレスは使わない。
【００４７】
なお、受け取ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　が、自分が送ったもの（マルチキャストのパケットをループバックしているため）であるならば、他にそれを使っているあるいは使おうとしているノードが存在することを示さない。自分が送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅに加えて、同じアドレスを　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓに含むＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅｓを受け取った場合に、同時に複数のノードが同じアドレスを対象としてＤＡＤをしていると判断する。
【００４８】
一方、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取ったノードが、その　ｍｅｓｓａｇｅ　の　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓに含まれるアドレスを既に使っていれば、Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓ（ターゲット　アドレス）にそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓが設定されたａ　ｍｕｌｔｉｃａｓｔ　Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　をａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ宛に返す。従って、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを送ったノードが　ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ宛のａ　ｍｕｌｔｉｃａｓｔ　Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取り、その　ｔａｒｇｅｔ　ａｄｄｒｅｓｓ　が　（判断対象の）　ｔｅｎｔａｔｉｖｅ　ａｄｄｒｅｓｓ　である場合（図８のＳ８０５ステップの「はい」の場合）は判断対象の　ｔｅｎｔａｔｉｖｅ　ａｄｄｒｅｓｓ　が唯一ではない（つまり、重複している）ことがわかる。
【００４９】
以上のＤＡＤの結果、判断対象の　ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　がリンク上で唯一であることが確認された（図８のＳ８０５ステップの「いいえ」の場合）ならば、そのアドレスをリンクローカルアドレスとしてインターフェイス３０１に割当てる。これが図８のステップＳ８０６である。以上でＤＡＤは終了する。
【００５０】
以上に説明した図８の動作は、図２のリンク２０７に接続されたノードであるｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２、ＤＨＣＰ　ｓｅｒｖｅｒ　２０３、ホスト２０４、ホスト２０５、ホスト２０６のそれぞれが、リンク２０７を収容するネットワーク・インターフェイス３０１について、実行することができる。
【００５１】
図２のホスト、例えばホスト２０６は、リンクローカルアドレスをインターフェイス３０１に割当てたら、次はサイトローカルアドレスやグローバルアドレスを決定するために必要な情報（Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔと呼ばれる）をｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２から入手することを試みる。この動作を図９に示す。
【００５２】
ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は通常はルーターと呼ばれるので以下ではルーター２０２と記す。ルーター２０２は管理者によって必要な設定が行われ、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を定期的にリンク２０７に送っている。ホスト２０６が　Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を早く入手したい場合は、ホスト２０６は　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　と呼ばれるデータをルーター２０２に送る。ホスト２０６はリンクローカルアドレスを割当てた直後にはルーター２０２の存在はわからないので、実際にはＲｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎはリンク２０７上のルーター全てに対するマルチキャストとして送られる。図９のステップＳ９０１はこの処理を示す。
【００５３】
Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　を受け取ったルーター２０２は　Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を送る。図９のステップＳ９０２の「はい」の場合に示すように、Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　のみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを受け取ったホスト２０６は、その受け取ったメッセージ中のプレフィックスの有効性（既にその装置によって使われていないこと等）を確認し、それ（ら）に適当なインターフェイスＩＤを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとし、インターフェイス３０１に割当てる。図９のステップＳ９０３がこの処理である。
【００５４】
図９のステップＳ９０２の「いいえ」の場合に示すように、ホスト２０６が　ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎのみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取らなかった場合は、次の二つの場合に分けられる。Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取った場合（ステップＳ９０４のはいの場合）と、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合（ステップＳ９０４のいいえの場合）である。後者の場合はｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、すなわちＤＨＣＰｖ６のみを実行する。これがステップＳ９０６であり、その詳細を図１０に示す。
【００５５】
ＤＨＣＰサーバー２０３は管理者によって必要な設定が行われている。具体的には、ノードとして自分のリンクローカルアドレスをネットワーク・インターフェイス３０１に割当ててあり、ＤＨＣＰサーバーとして振る舞うために必要なサイトローカルアドレスもしくはグローバルアドレスのためのプレフィックス等が設定されている。
【００５６】
図１０のステップＳ１００１で、ホスト２０６はＤＨＣＰサーバーにＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅを送る。ホスト２０６はどこにＤＨＣＰサーバー２０３が存在するのかわからないのでＤＨＣＰサーバー２０３に対するマルチキャストとしてリンク２０７に送出する。ホスト２０６の接続されているリンク２０７とは異なるリンク（図示せず）にＤＨＣＰサーバー２０３がいる場合には、ＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅは、実際はＤＨＣＰリレー（図示せず）によって中継されてＤＨＣＰサーバー２０３に届く。
【００５７】
ＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅを受け取ったＤＨＣＰサーバー２０３はそれに対する返答としてＤＨＣＰ　Ａｄｖｅｒｔｉｓｅ　Ｍｅｓｓａｇｅをホスト２０６に返す。これは（別リンクの場合はＤＨＣＰリレーによって中継されて）、ホスト２０６に届く。これがステップＳ１００２である。この時点でホスト２０６はＤＨＣＰサーバー２０３のアドレスがわかる。
【００５８】
次にステップＳ１００３でホスト２０６は　ＤＨＣＰ　Ｒｅｑｕｅｓｔ　ＭｅｓｓａｇｅをＤＨＣＰサーバー２０３に送る。ＤＨＣＰサーバー２０３はＤＨＣＰ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅを受け取ると、ＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅをホスト２０６に送る。
【００５９】
ステップＳ１００４でＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅを受け取ったホスト２０６は、それからサイトローカルアドレスもしくはグローバルアドレスを決めて、そのアドレスの中のインターフェイスＩＤが重複しているか否かを確認するために、ＤＡＤ処理に必要な処理を行なう。つまり、ステップＳ８０３と同様に、インターフェイス３０１にマルチキャストアドレス等を設定する。これがステップＳ１００５である。
【００６０】
次に、ステップＳ８０４と同様のＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅ　をステップＳ１００６で送り、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取るかどうかをステップＳ１００７で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをＤＨＣＰサーバー２０３から受け取るためにステップＳ１００３に戻り、同じ処理を繰り返す。
【００６１】
ホスト２０６は、図１０のステップＳ１００７でＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取らなかった場合は、そのアドレスは重複していないので、ＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅから決めたサイトローカルアドレスもしくはグローバルアドレスをステップＳ１００８でインターフェイス３０１に割当てる。
【００６２】
以上で図９のステップＳ９０６が終わる。ステップＳ９０４でＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合はこれで正常終了する。
【００６３】
ステップＳ９０４でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを受け取った場合は、ステップＳ９０５でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を行なう。処理内容はステップＳ９０３とＳ９０６と同じである。
【００６４】
以上のようにして、イーサネット（Ｒ）２０７をインターフェイスとして持つホスト２０６はｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　とｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　（ＤＨＣＰｖ６）を任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、グローバルアドレス、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ等を自動設定することができる。
【００６５】
以上のプロトコルにおいて、インターフェイスＩＤにランダムな値を用いて、その値を対象にしてＤＡＤを行ない、リンク２０７における一意性を確認することにより、ゲートウェイ２０２あるいはＤＨＣＰ　サーバー２０３から得たグローバルアドレスのプレフィックスと組み合わせて使い捨てのＩＰｖ６グローバルアドレスを利用することができる。詳細は、ＲＦＣ３０４１　｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒ　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’に記述されている。
【００６６】
次に本発明の実施の形態を説明する。上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。最初に、匿名公開鍵証明書の例を説明し、次にそれを効率的に発行するためのプロトコルを説明する。
【００６７】
匿名公開鍵証明書は、学術的にはＫａｚｕｏｍｉ　Ｏｉｓｈｉ、　Ｍａｓａｈｉｒｏ　Ｍａｍｂｏ、　Ｅｉｊｉ　Ｏｋａｍｏｔｏ、　｀｀Ａｎｏｎｙｍｏｕｓ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｃｅｒｔｉｆｉｃａｔｅｓ　ａｎｄ　ｔｈｅｉｒ　Ａｐｐｌｉｃａｔｉｏｎｓ　’’　ＩＥＩＣＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｆｕｎｄａｍｅｎｔａｌｓ　ｏｆ　Ｅｌｅｃｔｒｏｎｉｃｓ、　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ａｎｄ　Ｃｏｍｐｕｔｅｒ　Ｓｃｉｅｎｃｅｓ、　Ｅ８１−Ａ、　１、　ｐｐ．　５６−−６４、　１９９８においてその概念と具体的な実現方法が提案されており、その基本的な実現方法はＵＳＡの特許６、１５４、８４１としても開示されている。これらの方式では、証明書のユーザの匿名性は計算量的に保たれていた。より強力な匿名性を提供する方式として、情報量的な匿名性を有する匿名公開鍵証明書の実現方法がＫａｚｕｏｍｉ　Ｏｉｓｈｉ、　｀｀Ｕｎｃｏｎｄｉｔｉｏｎａｌｌｙ　ａｎｏｎｙｍｏｕｓ　ｐｕｂｌｉｃ　ｋｅｙ　ｃｅｒｔｉｆｉｃａｔｅｓ、’’　Ｔｈｅ　２０００　Ｓｙｍｐｏｓｉｕｍ　ｏｎ　Ｃｒｙｐｔｏｇｒａｐｈｙ　ａｎｄ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｃｕｒｉｔｙ、　ＳＣＩＳ２０００−Ｃ３２、　２０００において開示されている。
【００６８】
本発明においては、前述の論文Ｋａｚｕｏｍｉ　Ｏｉｓｈｉ、　Ｍａｓａｈｉｒｏ　Ｍａｍｂｏ、　Ｅｉｊｉ　Ｏｋａｍｏｔｏ、　｀｀Ａｎｏｎｙｍｏｕｓ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｃｅｒｔｉｆｉｃａｔｅｓ　ａｎｄ　ｔｈｅｉｒ　Ａｐｐｌｉｃａｔｉｏｎｓ　’’に記載されている任意の方式を利用することができる。効率が劣ることを許容できるならば、前記論文中のＳｃｈｅｍｅ　１、Ｓｃｈｅｍｅ　２、Ｓｃｈｅｍｅ　３を利用することも可能であり、それらも本発明に含まれる。本実施の形態では計算量的な匿名性を有する匿名公開鍵証明書方式を用いる形態を取り上げる。詳細は前述の文献を参照するものとし、説明の都合上必要な記号等を定義・導入してから本実施の形態のプロトコルを説明する。
【００６９】
匿名公開鍵証明書を発行するエンティティＣＡは、共通のパラメータとして大きな素数ｐとｑを定める。ｑはｐ−１を割りきる。オーダーｑの生成元ｇとハッシュ関数Ｈを定める。秘密の乱数ｓ＿ｃａ（１以上ｑ以下）を生成し、ｖ＿ｃａ＝ｇ＾（ｓ＿ｃａ）　ｍｏｄ　ｐを計算する。ここで、Ａ　＝　（Ｂ）＾（Ｃ）　ｍｏｄ　Ｄは、整数Ａ、Ｂ、Ｃ、Ｄに対して、ＢをＣ乗した値をＤで割り、その剰余をＡとする計算を表す。エンティティＣＡはｐとｑとｇとＨとｖ＿ｃａを公開する。一方、匿名公開鍵証明書を利用するエンティティｉは、秘密の乱数ｓ＿ｉ（１以上ｑ以下）を生成し、ｖ＿ｉ＝ｇ＾（ｓ＿ｉ）　ｍｏｄ　ｐを計算する。
【００７０】
ｓ＿ｃａやｓ＿ｉを秘密鍵、ｖ＿ｃａやｖ＿ｉ（および公開のパラメータ）を公開鍵と呼び、秘密鍵は自分以外の誰にも知られないように管理する。
【００７１】
エンティティｉは、匿名公開鍵証明書を利用開始する際に、自分のエンティティ名（ユーザ名）とパスワード、公開鍵ｖ＿ｉをエンティティＣＡに登録する。エンティティＣＡは、必要に応じてエンティティｉの身元を物理的手段等で確認し、提示されたエンティティ名（ユーザ名）とパスワード、公開鍵ｖ＿ｉを記憶する。
【００７２】
匿名公開鍵証明書を発行する際、エンティティ　ＣＡは、乱数ｒ（１以上ｑ以下）を生成し、（ｇ’、ｖ＿ｉ’）＝（ｇ＾ｒ　ｍｏｄ　ｐ、　（ｖ＿ｉ）＾（ｒ）　ｍｏｄ　ｐ）を計算する。上述の公開のパラメータやこの匿名公開鍵証明書の有効期限、及び、公開鍵ｖ＿ｃａに対する公開鍵証明書（後述）等の証明書の管理・属性情報をＸとし、（ｇ’、ｖ＿ｉ’）とＸを含むメッセージ（のハッシュ値）に対してディジタル署名を生成する。離散対数問題に基づくディジタル署名方式、例えば、Ｓｃｈｎｏｒｒ署名方式を使うことができる。ここでは、秘密鍵ｓ＿ｃａを用いる。このディジタル署名をＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）と記す。
【００７３】
エンティティｉに対してエンティティＣＡが発行する匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））である。
【００７４】
匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の発行を受けたエンティティｉは、その中から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし　｜　は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。また、ｖ＿ｉ’＝（ｇ’）＾（ｓ＿ｉ）　ｍｏｄ　ｐも確認する。それらが正しいと確認できたならば、ｇ’とｖ＿ｉ’（と共通のパラメータｐ）を公開鍵、ｓ＿ｉを秘密鍵として離散対数問題に基づく公開鍵暗号やディジタル署名を利用できる。このように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含み、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ’とｖ＿ｉ’は、同一のエンティティｉの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【００７５】
匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝　（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））を受け取ったエンティティは、その中から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。それが正しいと確認できたならば、公開鍵であるｇ’とｖ＿ｉ’（と共通のパラメータｐ）を用いて離散対数問題に基づく公開鍵暗号の暗号化やディジタル署名の検証を行なう。
【００７６】
なお、公開鍵ｖ＿ｃａそのものの正当性の確認は、より上位もしくはより普及しているエンティティＣＡ、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に公開鍵ｖ＿ｃａを提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらえば、それを用いて確認できる。匿名公開鍵証明書の管理・属性情報をＸは、公開鍵ｖ＿ｃａに対する公開鍵証明書を含む。この公開鍵ｖ＿ｃａに対する公開鍵証明書を用いて、公開鍵ｖ＿ｃａそのものの正当性を確認することができる。これは、エンティティＣＡを階層的に構築することに相当し、順当なＰＫＩ（Ｐｕｂｌｉｃ−ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を構成することができる。
【００７７】
なお、上記の説明では乗法群（ｍｏｄ　ｐ）上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能であり、その場合は乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。
【００７８】
以上の匿名公開鍵証明書方式を、図２の環境に適用する場合を説明する。
【００７９】
ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２もしくはＤＨＣＰサーバー　２０３を、匿名公開鍵証明書を発行するエンティティＣＡ、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。あるいは、証明書発行のみを担う専用ＣＡサーバーを設けることも可能である。以下では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２を、匿名公開鍵証明書を発行するエンティティＣＡとし、ランダムなＩＰｖ６アドレスを証明書の中に含める例を説明するが、ＤＨＣＰサーバーや専用ＣＡサーバーを、匿名公開鍵証明書を発行するエンティティＣＡとすること、ランダムなＩＰｖ６アドレスを証明書に含めないことも可能である。ここでは、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は、ホスト２０６に、ＩＰｖ６のグローバルアドレスのプレフィックスを提供する。前述のように、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は多くの場合ルーターなので、ルーター２０２と呼ぶことにする。
【００８０】
ルーター２０２の管理者は、上述の公開パラメータｐ、ｇ等を定め、公開する。匿名公開鍵証明書を発行するエンティティＣＡとしての公開鍵ｖ＿ｃａを定め、より上位もしくはより普及しているＣＡ（図２の２０９）、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらう。
【００８１】
ルーター（ｇａｔｅｗａｙ）２０２は、パケットの転送を制御する役目を持ち、そのルーターの管轄するサブネットと外部との間で不適当なパケットが出入りしないように管理者の責任のもとで運用される。あるサブネットがインターネットに接続されるためにはそのサブネットの管理者は身元をＪＰＮＩＣ（日本の場合）に登録し、ＩＰアドレスの割当てを受ける。従って、サブネットにおけるルーターは管理責任が明確であり、かつ安全面も考慮されたうえで運用や管理にコストがかけられると期待されるので、匿名公開鍵証明書を発行するエンティティＣＡの機能を担わせるのにふさわしいと考えられる。
【００８２】
ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＬＡＮの管理者（ルーター２０２の管理者）に提出する。ＬＡＮの管理者（ルーター２０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０４もしくはＨＤ３０６に登録する。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。
【００８３】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１に示す。図１は、匿名公開鍵証明書を利用するエンティティ　（ユーザｉが用いるＩＰｖ６端末）をホスト２０６、匿名公開鍵証明書を発行するＣＡをルーター２０２とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。すなわち、ＩＰｖ６対応装置２０６が位置するローカルリンク２０７内に存在するＩＰｖ６対応装置２０２を公開鍵証明書発行者として運用する。
【００８４】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター２０２とエンティティ（この場合は、ホスト２０６）の間でなんらかの特定（認証）プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１の流れに沿って動作を説明する。
【００８５】
ホスト２０６はステップＳ１０１でＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成する。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎは、匿名公開鍵証明書を要求するメッセージであり、匿名公開鍵証明書を要求する旨とホスト２０６のインターフェイスＩＤを含むデータであることをルーター２０２が理解できる形式で生成する。内容は、エンティティ名（ユーザ名）とパスワードとシリアル番号から計算される。シリアル番号は、例えば、ホスト２０６のＩＰｖ６リンクローカルアドレスとｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２のＩＰｖ６リンクローカルアドレスとそのときの時刻の３つを連接して一つのデータにした値である。再送攻撃となりすましを防ぐために、秘密鍵ｓ＿ｉを用いて、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名（認証用ｓｉｇｎａｔｕｒｅ）　（Ｓｉｇ＿ｉ（ｈａｓｈ（エンティティ名、パスワード、シリアル番号）））が、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれる。
【００８６】
次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ　ＳｏｌｉｃｉｔａｔｉｏｎをステップＳ１０２でリンク２０７を介してルーター２０２に送る。
【００８７】
ステップＳ１０３で、ルーター２０２はステップＳ１０２で受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（通信装置（ホスト）２０６の識別子）から登録された公開鍵ｖ＿ｉをＲＡＭ　３０５もしくはＨＤ３０６から検索し、それを用いて認証用ｓｉｇｎａｔｕｒｅの正当性を確認する。具体的には、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数の入力とし、そのハッシュ値を求め、認証用ｓｉｇｎａｔｕｒｅがそれに対する正しいディジタル署名であることを公開鍵ｖ＿ｉで確認する。
【００８８】
認証が成功したら、ルーター２０２に割当てられたＩＰｖ６のグローバルアドレスのプレフィックスとホスト２０６のインターフェイスＩＤ　とからＩＰｖ６グローバルアドレスを生成し、そのライフタイム（使用期限、例えば２４時間）等を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。具体的には、前述のＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６グローバルアドレスやライフタイム等が含まれる。なお、ＩＰｖ６グローバルアドレスのライフタイム（使用期限）と匿名公開鍵証明書の有効期限は同じとは限らない。
【００８９】
そして、ステップＳ１０４でルーター２０２はＩＰｖ６グローバルアドレスのプレフィックスとｄｅｆａｕｌｔ　ｒｏｕｔｅｒ　２０２　のアドレスと匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）からなるＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを、リンク２０７を介して、認証されたホスト２０６に送る。本発明のある形態では、このＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。
【００９０】
ステップＳ１０５でホスト２０６は受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔからプレフィックスを取り出し、インターフェイスＩＤを付加して、ＩＰｖ６グローバルアドレスを生成するとともに、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する。このように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含み、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ’とｖ＿ｉ’は、同一のエンティティｉ（ホスト２０６）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。ホスト２０６は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１の匿名公開鍵発行プロトコルを実行し、使用する公開鍵ｇ’とｖ＿ｉ’を変更する。
【００９１】
以上のプロトコルを既存のＲｏｕｔｅｒ　ＳｏｌｉｃｉｔａｔｉｏｎとＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔの送受信プロトコルと組み合わせた拡張プロトコルのホストの動作フローチャートを図１１に示す。
【００９２】
ホスト２０６は、図１１のステップＳ１１０１において、図９のステップ９０１で送られるＲｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅと図１のステップＳ１０２で送られるＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎの両方を含むデータであるＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅを、リンク２０７を介して送る。
【００９３】
また、ステップＳ１１０２で、図９のステップＳ９０２で受け取るＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅと図１のステップＳ１０４で受け取るＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔの両方を含むデータであるＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取る。
【００９４】
Ｒｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを、リンク２０７を介して、受け取った場合、すなわち、ステップＳ１１０２で「はい」の場合、ホスト２０６は、ステップＳ１１０３では、図９のステップＳ９０３と同様に、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅ中のプレフィックスにインターフェイスＩＤを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとして、インターフェイス３０１に割当てるとともに、図１におけるステップＳ１０５を行なって、公開鍵ｇ’とｖ＿ｉ’を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を入手する。
【００９５】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書をホスト２０６に発行することができる。
【００９６】
なお、ルーター２０２の代りにＤＨＣＰサーバー２０３が匿名公開鍵証明書を発行するエンティティＣＡの役割を行なう場合は、図１１におけるステップＳ１１０６において図１と同様のプロトコルを実行する。ここでは、ＤＨＣＰサーバー２０３が、ホスト２０６に、グローバルアドレスのプレフィックスを提供する。この場合には図１１のステップＳ１１０６で、ホストはｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの拡張プロトコル、つまりＤＨＣＰサーバーからアドレスと証明書を取得するプロトコルを実行する。その動作フローチャートを図１２に示す。
【００９７】
図１０のプロトコルとの違いは、ステップＳ１２０３とステップＳ１２０４の二カ所である。
【００９８】
ステップＳ１２０３では、図１０のステップＳ１００３で送るＤＨＣＰ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅ　と図１のステップＳ１０２で送られるＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ相当のデータ（ＣＡがルーター２０２ではなくＤＨＣＰサーバー２０３である点が異なる）の両方を含むデータであるＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅを、リンク２０７を介して送る。
【００９９】
このＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅを受け取ると、ＤＨＣＰサーバー２０３は、ＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅを生成し、生成したＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅを、リンク２０７を介して送る。ここで、ＤＨＣＰサーバー２０３は、図１のＳ１０３のように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を生成し、ＤＨＣＰサーバー２０３のグローバルアドレスのプレフィックスとＤＨＣＰサーバー２０３のアドレスと匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）からなるＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ相当のデータと、図１のステップＳ１００４のＤＨＣＰ　Ｒｅｐｌｙ　ＭｅｓｓａｇｅをＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅに含める。
【０１００】
ホスト２０６は、ステップＳ１２０４で、ＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅ受け取る。このＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅは、図１０のステップＳ１００４で受け取るＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅと図１のステップＳ１０４で受け取るＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ相当のデータ（ＣＡがルーターではなくＤＨＣＰサーバーである点が異なる）の両方を含むデータである。したがって、ＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅからサイトローカルアドレスもしくはグローバルアドレスを決めるとともに、公開鍵ｇ’とｖ＿ｉ’を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を入手する。
【０１０１】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書をホスト２０６に発行することができる。
【０１０２】
ルーター２０２およびＤＨＣＰサーバー２０３の両方がＣＡの役割を行なう場合は、図１１におけるステップＳ１１０４で　ｓｔａｔｅｌｅｓｓ　と　ｓｔａｔｅｆｕｌ　の両方を指定するＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取った場合（「はい」の場合）に相当し、上記に示した二つの拡張プロトコルを任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、使い捨てＩＰｖ６グローバルアドレスとそれに対応する使い捨て匿名公開鍵証明書、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ等を自動設定および取得することができる。この場合、ルーター２０２及び　ＤＨＣＰサーバー２０３は、公開鍵証明書を提供する通信装置群に相当する。
【０１０３】
ホスト２０６は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１１の匿名公開鍵証明書を受け取るためのプロトコルを実行し、使用する公開鍵ｇ’とｖ＿ｉ’を変更する。
【０１０４】
なお、ＤＨＣＰサーバー２０３がＩＰｖ６アドレスのプレフィックスをホスト２０６に提供する形態を説明したが、ＩＰｖ６アドレスそのものを提供する形態ではプレフィックスのかわりにアドレスが送られる点とホストがアドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１０５】
（第２の実施の形態）
第１の実施の形態では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ルーター）兼ＣＡがホストを認証してから匿名公開鍵証明書とプレフィックスを含む　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　をホストに送った。本実施の形態では、プレフィックスの送付と匿名公開鍵証明書の発行が独立な例を説明する。
【０１０６】
第１の実施の形態と同様に、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２もしくはＤＨＣＰサーバー　２０３を、匿名公開鍵証明書を発行するエンティティＣＡとし、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉとする。あるいは、証明書発行のみを担う専用ＣＡサーバーを設けることも可能である。以下では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２を、匿名公開鍵証明書を発行するエンティティＣＡとし、ランダムなＩＰｖ６アドレスを証明書の中に含める例を説明するが、ＤＨＣＰサーバーや専用ＣＡサーバーを、匿名公開鍵証明書を発行するエンティティＣＡとすること、ランダムなＩＰｖ６アドレスを証明書に含めないことも可能である。ここでは、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は、ホスト２０６に、ＩＰｖ６のグローバルアドレスのプレフィックスを提供する。前述のように、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は多くの場合ルーターなので、ルーター２０２と呼ぶことにする。
【０１０７】
ルーター２０２の管理者は、前述の公開パラメータｐ、ｇ等を定め、公開する。匿名公開鍵証明書を発行するエンティティＣＡとしての公開鍵ｖ＿ｃａを定め、より上位もしくはより普及しているＣＡ（図２の２０９）、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらう。
【０１０８】
ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＬＡＮの管理者（ルーター２０２の管理者）に提出する。ＬＡＮの管理者（ルーター２０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０４もしくはＨＤ３０６に登録する。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。
【０１０９】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１５に示す。図１５は、匿名公開鍵証明書を利用するエンティティ　（ユーザｉが用いるＩＰｖ６端末）をホスト２０６、プレフィックスを提供するＩＰｖ６端末でありかつ匿名公開鍵証明書を発行するＣＡをｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルの動作フローを表している。すなわち、ＩＰｖ６対応装置２０６が位置するローカルリンク２０７内に存在するＩＰｖ６対応装置２０２を公開鍵証明書発行者として運用する。
【０１１０】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター２０２とエンティティ（この場合は、ホスト２０６）の間でなんらかの特定（認証）プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１５を参照しながら動作を説明する。
【０１１１】
ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。そして、ＭＡＣアドレスから生成したインターフェイスＩＤに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（ＲＳ）　をルーターに送る（ステップＳ１５０１）。ＲＳは前述のようにリンク上のルーター全て宛の　ｍｕｌｔｉｃａｓｔ　である。
【０１１２】
ルーター２０２は、ＲＳを受け取ったら、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　（ＲＡ）を送る（ステップＳ１５０２）。
【０１１３】
ＲＡを受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤと抽出したプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ　ａｄｄｒｅｓｓと呼ぶ）を生成する。また、ランダムなインターフェイスＩＤ　と抽出したプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓと呼ぶ）を作る。そして、ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ　とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割当てる（ステップＳ１５０３）。
【０１１４】
次に、ホスト２０６はＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成する（ステップＳ１５０４）。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎは、匿名公開鍵証明書を要求するメッセージであり、ホスト２０６が匿名公開鍵証明書を要求する旨を含むデータであることをルーター２０２が理解できる形式で生成する。例えば、ＲＦＣ２９８６，　｀｀ＰＫＣＳ　＃１０：Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ　Ｓｙｎｔａｘ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｖｅｒｓｉｏｎ　１．７，’’で規定されているＰＫＣＳ＃１０や、ＲＦＣ２５１１，　｀｀Ｉｎｔｅｒｎｅｔ　Ｘ．５０９　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｑｕｅｓｔ　ＭｅｓｓａｇｅＦｏｒｍａｔ’’等がそれらの形式を規定している。形式の詳細な説明は省くが、このＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎは、証明書要求メッセージと、それに対する（ホストの）署名からなるデータであるとする。
【０１１５】
次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを、リンク２０７を介してルーター２０２に送る（ステップＳ１５０５）。なお、この時点でルーター２０２の（ユニキャスト）アドレスをホスト２０６は知っているので　ｕｎｉｃａｓｔ　することが可能である。
【０１１６】
ルーター２０２は、ステップＳ１５０５で受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（ホスト２０６の識別子もしくはホスト２０６を利用するユーザの名前）から登録された公開鍵ｖ＿ｉをＲＡＭ　３０５もしくはＨＤ３０６から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト２０６の匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。具体的には、前述のＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６グローバルアドレスやライフタイム等が含まれる（ステップＳ１５０６）。
【０１１７】
そして、ルーター２０２は匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを、リンク２０７を介して、認証されたホスト２０６に送る（ステップＳ１５０７）。本発明のある形態では、このＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。このとき、ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓ宛のｕｎｉｃａｓｔとして送ることが可能である。
【０１１８】
ホスト２０６は受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔから匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する（ステップＳ１５０８）。
【０１１９】
以上のプロトコルを既存のｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎおよびｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎと組み合わせた拡張プロトコルのホストの動作フローチャートを図１７に示す。
【０１２０】
ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。そして、ＭＡＣアドレスから生成したインターフェイスＩＤに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（ＲＳ）　をルーターに送る（ステップＳ１７０１）。ＲＳは前述のようにリンク上のルーター全て宛の　ｍｕｌｔｉｃａｓｔ　である。
【０１２１】
ステップＳ１７０２の「はい」の場合に示すように、Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　のみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージ（ＲＡ）を受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤと抽出したプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ　ａｄｄｒｅｓｓと呼ぶ）を生成する。また、ランダムなインターフェイスＩＤ　と抽出したプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓと呼ぶ）を作る。
【０１２２】
そして、ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ　とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割当てる（ステップＳ１７０３）。
【０１２３】
次に、ホスト２０６は、証明書要求と証明書発行のプロトコルを実行する（ステップＳ１７０７）。すなわち、ホスト２０６は、図１５のステップＳ１５０４、Ｓ１５０５で示したように、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成し、ルーター２０２に送る。ホスト２０６は、ルーター２０２からＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取り、その中に含まれる匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する。
【０１２４】
なお、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合は（ステップＳ１７０４のいいえの場合）、ｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、すなわちＤＨＣＰｖ６のみを実行する。これがステップＳ１７０６であり、その詳細は図１０のプロトコルと同じである。
【０１２５】
ステップＳ１７０４でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを受け取った場合は、ステップＳ１７０５でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を行なう。処理内容はステップＳ１７０３とＳ１７０６と同じである。
【０１２６】
以上の説明では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ２０２（ルーター）がＣＡを兼ねていたが、一般にはｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ルーター）とＣＡが同一のＩＰｖ６装置とは限らない。Ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ルーター）とＣＡが異なるＩＰｖ６装置の場合の動作フローを図１６に示す。
【０１２７】
ＣＡの管理者は、前述の公開パラメータｐ、ｇ等を定め、公開する。匿名公開鍵証明書を発行するエンティティＣＡとしての公開鍵ｖ＿ｃａを定め、より上位もしくはより普及しているＣＡ（図２の２０９）、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらう。
【０１２８】
ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＣＡの管理者に提出する。ＣＡの管理者は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０４もしくはＨＤ３０６に登録する。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。
【０１２９】
なお、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　（ルーター）２０２の管理者とＣＡの管理者が同一であってもよいし、同一でなくてもよい。図１６は、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２（ルーター）とＣＡが別のＩＰｖ６装置であり、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ２０２にＣＡのＩＰｖ６アドレスが設定されているものとする。
【０１３０】
ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。前述のようにリンクローカルアドレスの生成等を行ない、Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ拡張（ＲＳ拡張）　をｒｏｕｔｅｒに送る（ステップＳ１６０１）。ＲＳ拡張は、ＣＡのアドレスを要求する旨のメッセージをＲｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎに追加した情報であり、前述のＲＡと同じくリンク上のルーター全て宛の　ｍｕｌｔｉｃａｓｔ　である。
【０１３１】
ルーター２０２は、ＲＳ拡張を受け取ったら、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ拡張　（ＲＡ拡張）を送る（ステップＳ１６０２）。ＲＡ拡張は、ＣＡのアドレスを　Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔに追加した情報である。
【０１３２】
ＲＡ拡張を受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤとプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ）を生成する。また、ランダムなインターフェイスＩＤ　とプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓと呼ぶ）を作る。そして、ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ　とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる。また、ＲＡ拡張からＣＡのアドレスを抽出する（ステップＳ１６０３）。
【０１３３】
次に、ホスト２０６はＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成し（ステップＳ１６０４）、Ｃｅｒｔｉｆｉｃａｔｅ　ＳｏｌｉｃｉｔａｔｉｏｎをＣＡに送る（ステップＳ１６０５）。
【０１３４】
ＣＡはステップＳ１６０５で受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（通信装置（ホスト）２０６の識別子）から登録された公開鍵ｖ＿ｉをＲＡＭ３０５もしくはＨＤ３０６から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト２０６の匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。具体的には、前述のＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６グローバルアドレスやライフタイム等が含まれる（ステップＳ１６０６）。
【０１３５】
そして、ＣＡは匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを、ホスト２０６に送る（ステップＳ１６０７）。本発明のある形態では、このＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。
【０１３６】
ホスト２０６は受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔから匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する（ステップＳ１６０８）。
【０１３７】
以上のプロトコルを既存のｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎおよびｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎと組み合わせた拡張プロトコルのホストの動作フローチャートは、図１７とほぼ同様であるが、以下の２点が異なる。すなわち、ステップＳ１７０１で、Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅの代わりに、Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　拡張　Ｍｅｓｓａｇｅ　を送る。また、ステップＳ１７０７で、証明書要求と証明書発行のプロトコルとして、図１６で示したプロトコルを実行する。
【０１３８】
（第３の実施の形態）
本実施の形態では、ホストがダイヤルアップあるいはＡＤＳＬのような方式でインターネットと接続する形態を説明する。最初に現状を説明し、その後に本発明の実施の形態を説明する。
【０１３９】
図１４は、本発明が適用される接続環境を模式的に示したものである。図１４は、ホスト１４０６がＰＳＴＮ（Ｐｕｂｌｉｃ　Ｓｗｉｔｃｈｅｄ　Ｔｅｌｅｐｈｏｎｅ　Ｎｅｔｗｏｒｋ）経由でＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）の提供するインターネット１４０１とアクセスする環境を示す。本実施の形態では、ＩＳＰとホスト１４０１はＰＰＰリンクで接続するものとする。
【０１４０】
図１４において、ＩＳＰのＰＰＰ　ｐｅｅｒ　１４０２はノードであり、ｍｏｄｅｍ　１４０３を用いてＰＳＴＮ　１４０４を介してホスト１４０６からのＰＰＰ接続の要求を受け付ける。ホスト１４０６はｍｏｄｅｍ　１４０５を用いてＰＰＰ　ｐｅｅｒ　１４０２にＰＰＰ接続でアクセスする。ホスト１４０６の構成は、図３と同様であり、ネットワーク・インターフェイス３０１を介して、モデム１４０５を接続する。また、ＰＰＰ　ｐｅｅｒ　１４０２の構成も、図３と同様であり、ネットワーク・インターフェイス３０１を介して、モデム１４０３を接続し、ネットワーク・インターフェイス３０２を介して、インターネット１４０１と接続する。ＰＰＰ　ｐｅｅｒ　１４０２は、図１４に示すように、　ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　ｍｏｄｕｌｅ　１４０２１、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３として、機能する。ホスト１４０６とＰＰＰ　ｐｅｅｒ　１４０２が通信する場合、ホスト１４０６は、モデム１４０５を介して、通信を行ない、ＰＰＰ　ｐｅｅｒ　１４０２は、モデム１４０３を介して、通信を行なう。
【０１４１】
本実施の形態では、ｍｏｄｅｍとＰＳＴＮを例として取り上げて説明するが、ＴＡ（Ｔｅｒｍｉｎａｌ　Ａｄａｐｔｅｒ）とＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ　Ｓｅｒｖｉｃｅｓ　Ｄｉｇｉｔａｌ　Ｎｅｔｗｏｒｋ）、ＰＨＳ通信アダプターとＰＨＳ通信網、専用線接続装置と専用線等の他の通信形態であったとしてもＰＰＰ接続が確立できる環境であれば本質的には同じである。ＰＰＰ接続の詳細は、ＲＦＣ　１６６１｀｀Ｔｈｅ　Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ　Ｐｒｏｔｏｃｏｌ　（ＰＰＰ）’’　に記述されている。
【０１４２】
ホスト１４０６がモデム１４０５、ＰＳＴＮ１４０４、モデム１４０３を介してＰＰＰ接続の要求を、ＰＰＰ　ｐｅｅｒ　１４０２に伝える。ＰＰＰ　ｐｅｅｒ　１４０２は、その接続要求を受け、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３がホストの認証を行なう。典型的な認証方式は、ユーザ名とパスワードに基づく認証プロトコルＣＨＡＰであり、詳細はＲＦＣ１９９４｀｀ＰＰＰ　Ｃｈａｌｌｅｎｇｅ　Ｈａｎｄｓｈａｋｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ’’に記述されている。
【０１４３】
認証が完了したら、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２が、その設定に従い、ＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６アドレス等をホスト１４０６に伝える。ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２は、ＩＳＰの管理者がその運用方針に従った設定を行なっている。
【０１４４】
なお、図１４では説明を簡単にするため、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　とＤＨＣＰサーバーとＡｕｔｈｅｎｔｉｃａｔｉｏｎ　サーバーをそれぞれｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　ｍｏｄｕｌｅ　１４０２１、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３としてＰＰＰ　ｐｅｅｒ内部に存在するものとしているが、実際にはリンク１４０７上にそれぞれ異なるノードとして存在することもある。いずれの実現形態であっても、それらのｍｏｄｕｌｅあるいはノードが、ＩＳＰの管理者の管理下で安全に運用されていれば構わないので、以下では、図１４の形態でホスト１４０６とＰＰＰ　ｐｅｅｒ　１４０２の間のＰＰＰリンクが確立したものとして説明する。
【０１４５】
ホスト１４０６は、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２からＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６アドレス等を受け取ったならば、ＩＰｖ６グローバルアドレスのプレフィックスと自分の（ＲＦＣ３０４１等の方法で生成した）ランダムなインターフェイスＩＤとを組み合わせて、ランダムなＩＰｖ６グローバルアドレスを生成し、それがリンクにおいて重複していないことを確認してから、それをインターフェイス３０１に割当て、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　のＩＰｖ６アドレスを記憶する。
【０１４６】
以上の動作により、ホスト１４０６は使い捨てＩＰｖ６アドレスを使ってインターネットの任意の相手と通信できる。
【０１４７】
次に、本発明の実施の形態を説明する。上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。
【０１４８】
以下では、匿名公開鍵証明書方式を、図１４の環境に適用する場合を説明する。ＰＰＰ　ｐｅｅｒ　１４０２が匿名公開鍵証明書を発行するＣＡ、ホスト１４０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。以下では、ランダムなＩＰｖ６アドレスを証明書の中に含める形態を説明するが、ランダムなＩＰｖ６アドレスを含めないことも可能である。
【０１４９】
ＩＳＰは、前述の公開パラメータｐ、ｇ等を定め、公開する。自分の公開鍵ｖ＿ｃａを定め、より上位もしくはより普及しているＣＡ（図１４の１４０８）、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に提出して、ｖ＿ｃａに対する公開鍵証明書を発行してもらう。
【０１５０】
ユーザｉがＩＳＰに加入を申請する際に、ＩＳＰが公開しているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＩＳＰに提出する。ＩＳＰの管理者（ＰＰＰ　ｐｅｅｒ１４０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、ユーザ名に対応して公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０５もしくはＨＤ３０６に登録する。公開パラメータや公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト１４０６で安全に利用可能になっているものとする。
【０１５１】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１３に示す。図１３は、エンティティ（ユーザｉが用いるＩＰｖ６端末）をホスト１４０６、匿名公開鍵証明書を発行するＣＡをＰＰＰ　ｐｅｅｒ　１４０２とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。
【０１５２】
ＰＰＰ接続におけるデータリンク層の処理が終わった後、前述のように、ホスト１４０６からのＰＰＰ接続の要求を受けたＰＰＰ　ｐｅｅｒ　１４０２は、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３で、ユーザ名（識別子）とパスワードに基づき、認証プロトコルＣＨＡＰによるホストの認証を行なう。
【０１５３】
すなわち、ホスト１４０６はステップＳ１３０１でエンティティ名（ユーザ名）をＰＰＰ　ｐｅｅｒ１４０２に送る。ステップＳ１３０２でＰＰＰ　ｐｅｅｒ　１４０２はＣＨＡＰ−ｃｈａｌｌｅｎｇｅを生成し、ステップＳ１３０３でそれをホスト１４０６に送る。
【０１５４】
ホスト１４０６はステップ　Ｓ１３０４でエンティティ名とパスワードとＣＨＡＰ−ｃｈａｌｌｅｎｇｅをハッシュ関数に入力してＣＨＡＰ−ｒｅｓｐｏｎｓｅを求め、求めた結果のＣＨＡＰ−ｒｅｓｐｏｎｓｅの値をステップＳ１３０５でＰＰＰ　ｐｅｅｒ　１４０２に送る。
【０１５５】
ステップＳ１３０６でＰＰＰ　ｐｅｅｒ　１４０２は、ＣＨＡＰ−ｒｅｓｐｏｎｓｅの正当性を確認する。確認出来たならば認証は成功なので、その認証されたホスト１４０６に対してＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　のアドレスをステップＳ１３０７で伝える。
【０１５６】
ホスト１４０６は、ステップＳ１３０８でＩＰｖ６グローバルアドレスのプレフィックスとランダムなインターフェイスＩＤとからＩＰｖ６グローバルアドレスを生成し、それが重複していないことを確認してから、それをネットワーク・インターフェイス３０１に割当て、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙのアドレスも記憶する。次に匿名公開鍵証明書を要求するメッセージとしてＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　をステップＳ１３０９でＰＰＰ　ｐｅｅｒ
１４０２に送る。
【０１５７】
Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　は、第１の実施の形態と同様に、匿名公開鍵証明書を要求する旨とインターフェイスＩＤを含むデータであることをＰＰＰ　ｐｅｅｒ　１４０２が理解できる形式で生成される。内容は、エンティティ名（ユーザ名）とパスワードとシリアル番号から計算され、シリアル番号は、例えば、ホスト２０６のＩＰｖ６リンクローカルアドレスとｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６リンクローカルアドレスとそのときの時刻の３つを連接して一つのデータにした値である。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎには、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名（認証用ｓｉｇｎａｔｕｒｅ）が含まれる。
【０１５８】
ＰＰＰ　ｐｅｅｒ　１４０２は、エンティティ名（通信装置（ホスト）２０６のユーザ名）に対応する登録された公開鍵ｖ＿ｉをＲＡＭ　３０５もしくはＨＤ３０６から検索し、前述の図１のＳ１０３で説明した匿名公開鍵証明書の生成をステップＳ１３１０で実行する。すなわち、ＰＰＰ　ｐｅｅｒ　１４０２に割当てられたＩＰｖ６のグローバルアドレスのプレフィックスとホスト１４０６のインターフェイスＩＤ　とからＩＰｖ６グローバルアドレスを生成し、そのライフタイム等を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。具体的には、前述のＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６グローバルアドレスやライフタイム等が含まれる。
【０１５９】
そして、図１のＳ１０４と同様に、生成された匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）等を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔをホスト１４０６に対してステップＳ１３１１で送る。ホスト１４０６は受け取った匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性をステップＳ１３１２で確認する。このように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含み、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ’とｖ＿ｉ’は、同一のエンティティｉ（ホスト１４０６）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１６０】
以上のプロトコルにおいて、ステップＳ１３０５とＳ１３０９で送受されるデータを一つにまとめてステップＳ１３０５で送ることも可能である。図示しないが、その場合、ホスト１４０６はランダムなインターフェイスＩＤと図１３のステップＳ１３０５のＣＨＡＰ−ｒｅｓｐｏｎｃｅとステップＳ１３０９の　Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（第１の実施の形態と同様）をステップＳ１３０５’でＰＰＰ　ｐｅｅｒ１４０２に送る。
【０１６１】
そして、ステップＳ１３０６’で、ＰＰＰ　ｐｅｅｒ　１４０２は、ＣＨＡＰ−ｒｅｓｐｏｎｓｅの正当性を確認し、登録された公開鍵ｖ＿ｉを検索し、ＩＰｖ６プレフィックスとインターフェイスＩＤとからＩＰｖ６グローバルアドレスを生成し、それとそのライフタイム（使用期限、例えば２４時間等）等を含めたデータを生成し、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を生成する。生成された匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔをホスト１４０６に対してステップＳ１３０７’で送る。
【０１６２】
ホスト１４０６は受け取った匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性をステップＳ１３０８’で確認する。このステップＳ１３０８’で図１３のステップＳ１３１２に相当する処理まで終了するので、これ以降のステップは存在しない。
【０１６３】
以上のプロトコルで、ＰＰＰ　ｐｅｅｒ　１４０２は、ホスト１４０６に、使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書を発行する。
【０１６４】
ホスト１４０６は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１３の匿名公開鍵証明書発行プロトコルを実行し、使用する公開鍵ｇ’とｖ＿ｉ’を変更する。
【０１６５】
なお、以上の説明ではＰＰＰ　Ｐｅｅｒ　１４０２がＩＰｖ６プレフィックスをｈｏｓｔ１４０６に伝え、ｈｏｓｔ１４０６がＩＰｖ６プレフィックスとインターフェイスＩＤからＩＰｖ６アドレスを生成する場合を述べたが、ＰＰＰ　Ｐｅｅｒ　１４０２がＩＰｖ６アドレスをｈｏｓｔ１４０６に伝え、ｈｏｓｔ１４０６がそれを使う場合も同様のプロトコルで実現される．その場合、図３のステップＳ１３０７でＩＰｖ６プレフィックスの代わりにＩＰｖ６アドレスが送られる点とステップＳ１３０８でプレフィックスからＩＰｖ６アドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１６６】
（第４の実施の形態）
第１の実施の形態や第２の実施の形態、第３の実施の形態で発行された使い捨てＩＰｖ６アドレスと使い捨て匿名公開鍵証明書を用いてＩＰｓｅｃ通信を行なう形態を説明する。
【０１６７】
まず、秘密データやお互いのＩＰｖ６アドレス等のデータであるＳＡ（Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）を安全に共有するプロトコルであるＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）の公開鍵暗号による暗号化の改訂モードによる認証方法を簡単に説明し、匿名公開鍵証明書を用いる方法を説明する。
【０１６８】
ＩＫＥは二つのｐｈａｓｅからなり、Ｐｈａｓｅ　１において安全な通信路を確立し、ｐｈａｓｅ　２では、ＩＰｓｅｃ等の通信で使用されるＳＡが前記安全な通信路を用いて合意される。以下では、Ｐｈａｓｅ　１のみを説明する。ＩＫＥのＰｈａｓｅ　１にはＭａｉｎ　ｍｏｄｅとＡｇｇｒｅｓｓｉｖｅ　ｍｏｄｅが存在するが、以下に説明するのは、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ（ＩＫＥ）’’のｐｐ．　１３−１５の５．３　Ｐｈａｓｅ　１　Ａｕｔｈｅｎｔｉｃａｔｅｄ　ｗｉｔｈ　ａ　Ｒｅｖｉｓｅｄ　ｍｏｄｅ　ｏｆ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｅｎｃｒｙｐｔｉｏｎ　の　Ｍａｉｎ　ｍｏｄｅ　である。
【０１６９】
ＩＫＥにおいて、通信する２エンティティはＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒと呼ばれる。Ｉｎｉｔｉａｔｏｒが通信を開始する。最初に、Ｉｎｉｔｉａｔｏｒが複数のＳＡをＲｅｓｐｏｎｄｅｒに送り、Ｒｅｓｐｏｎｄｅｒが使って良いと判断した一つのＳＡをＩｎｉｔｉａｔｏｒに送ることで、ｐｈａｓｅ　１用のＳＡを決定する。
【０１７０】
Ｉｎｉｔｉａｔｏｒは、乱数（Ｎｏｎｃｅと呼ばれる）を生成し、Ｒｅｓｐｏｎｄｅｒの公開鍵で暗号化したデータをＲｅｓｐｏｎｄｅｒに送る。Ｒｅｓｐｏｎｄｅｒは乱数を生成し、Ｉｎｉｔｉａｔｏｒの公開鍵で暗号化したデータをＩｎｉｔｉａｔｏｒに送る。これにより、それぞれの生成したｎｏｎｃｅを共有できるので、他の通信で用いられる暗号の鍵を、共有したｎｏｎｃｅから生成する。詳細は、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ　（ＩＫＥ）’’に記載されている。以上の説明から明らかなように、通信相手の公開鍵をＩＰｓｅｃ通信に先だって知る必要がある。
【０１７１】
以下のような状況を考える。ある買い物サイト等のインターネット上のサイトにユーザがアクセスする。ユーザは、図２の形態では、例えば、ホスト２０６であり、図１４の形態では、ホスト１４０６である。買い物サイトは、図２の形態では、インターネット２０１、ゲートウェイ２０２を介して、ユーザであるホスト２０６に接続され、図１４の形態では、インターネット１４０１、ＰＰＰ　ｐｅｅｒ　１４０２を介して、ユーザであるホスト１４０６に接続される。ホスト２０６、１４０６は、この買い物サイトなどのサイトを通信相手とする通信を開始する前に、上述したプロトコルで、Ｉｐｖ６アドレス、及び、公開鍵を含む公開鍵証明書を得ておく。この形態において、上述した公開鍵証明書に基づき鍵交換・更新・変更プロトコルを実行して暗号・認証通信を行なう手順を行なう。
【０１７２】
このとき、ユーザは買い物サイトのＩＰｖ６アドレス（識別子）を（明示的か非明示的かは問わないが）知っている。実際にアクセスして、そこがユーザにとって正しいサイトであるときに、通信相手のＩＰｖ６アドレスを確認することでユーザは明示的にアドレスを知ることができる。通信している最中には、買い物サイトも通信相手のアドレス（識別子）はわかる。以上の通信は使い捨てＩＰｖ６アドレスで行なえる。
【０１７３】
本形態では、送受信者が確定した時点で、使い捨てＩＰｖ６アドレスは（更新せず）、同一のアドレスを使うこととする。この時点で、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））をお互いに送り合う。すると、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）中の管理・属性情報Ｘには、ＩＰｖ６グローバルアドレスが含まれているので、そのＩＰｖ６アドレスが実際に通信している相手のＩＰｖ６アドレスと一致するか否かを確認し、かつ使い捨て匿名公開鍵証明書の正当性を確認すれば、それが本当に通信相手の使い捨て匿名公開鍵証明書か否かを判断でき、その中に含まれる公開鍵（ｇ’、ｖ＿ｉ’）が本当に通信相手の公開鍵か否かを確認できる。
【０１７４】
使い捨て匿名公開鍵証明書の正当性は、次のように確認できる。証明書の管理・属性情報ＸにはＣＡ（前述のルーター２０２やＤＨＣＰサーバー２０３、又は、ＰＰＰ　ｐｅｅｒ　１４０２）の公開鍵ｖ＿ｃａとそれに対する公開鍵証明書（商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等が発行した証明書）が含まれている。サイトは、それらの対応関係が正しいか否かを、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等の公開鍵（広く知られているので容易に入手できる）を用いて確認できる。正当性が確認できたｖ＿ｃａを用いて、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の正当性、すなわち、（ｇ’、ｖ＿ｉ’）とＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）の対応関係の正しさを確認できる。匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含み、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ’とｖ＿ｉ’は、同一のエンティティｉの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１７５】
ホスト２０６、１４０６は、通信相手が変る度に（すなわち、新たに、サイトに接続する度に）、若しくは、セッションが変る毎に、図１１、図１３のプロトコルを実行し、使用するＩＰｖ６アドレス及び公開鍵ｇ’とｖ＿ｉ’を更新・変更する。なお、公開鍵ｇ’とｖ＿ｉ’は、通信パケットの送信毎に、更新・変更してもよい。
【０１７６】
以上により、使い捨てＩＰｖ６アドレスとそれを含む使い捨て匿名公開鍵証明書を用いて、ＩＰｖ６アドレスで定義される通信相手の公開鍵を確実に入手できる。このようにして交換した公開鍵を用いて前述のＩＫＥ　の　ｐｈａｓｅ　１　の　Ｍａｉｎ　ｍｏｄｅ　を行なうことにより、そのＩＰｖ６アドレスを持つ通信相手とのＩＰｓｅｃ通信が実行できる。
【０１７７】
すなわち、本形態では、ＩＰｖ６対応装置が位置するローカルリンク内に存在するＩＰｖ６対応装置を公開鍵証明書発行者として運用し、使い捨て匿名公開鍵証明書の中にＩＰｖ６アドレスを含めて、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであるＩＰｓｅｃ通信、及び、ＩＰｓｅｃに際して、秘密データやお互いのＩＰｖ６アドレス等のＳＡ（Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）を安全に共有するプロトコルであるＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）を行なう。
【０１７８】
従って、課題で述べたような通信相手のなりすましは防がれる。
【０１７９】
【発明の効果】
以上説明したように、本出願に関わる発明によれば、使い捨てＩＰｖ６アドレスとそれを含む使い捨て匿名公開鍵証明書を実現できる。
【０１８０】
また、匿名公開鍵を生成するためのホストが計算する負荷を軽減することができる。
【０１８１】
さらに、プライバシ保護の程度が高く、低コストで実現可能であり、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能である。
【０１８２】
また、強力なプライバシ保護を実現し、かつなりすましを防ぎながらＩＫＥによるＩＰｓｅｃ通信を行なうことができる。
【図面の簡単な説明】
【図１】第１の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（Ｒ）ＬＡＮの場合）の図である。
【図２】イーサネット（Ｒ）ＬＡＮの模式図である。
【図３】ノードの構成図である。
【図４】イーサネット（Ｒ）のＭＡＣアドレスの構成図である。
【図５】インターフェイスＩＤの構成図である。
【図６】ａ　ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓの構成図である。
【図７】あるｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓの構成図である。
【図８】ホストがＤＡＤを終えるまでの動作を説明するフローチャート図である。
【図９】ホストがアドレス自動設定を終えるまでの動作を説明するフローチャート図である。
【図１０】ホストがＤＨＣＰでアドレスを取得するまでの動作フローチャート図である。
【図１１】ホストがアドレス自動設定を行ない、匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１２】ホストがＤＨＣＰでアドレスと匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１３】第３の実施の形態における匿名公開鍵証明書発行プロトコル（ＰＰＰの場合）の図である。
【図１４】ダイヤルアップ／ＡＤＳＬ接続の模式図である。
【図１５】第２の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（Ｒ）ＬＡＮの場合）の図である。
【図１６】匿名公開鍵証明書発行プロトコルの一般形の図である。
【図１７】ホストが証明書を取得するまでの動作フローチャート図である。
【符号の説明】
３００　ノード
３０１　ネットワーク・インターフェイス
３０２　ネットワーク・インターフェイス
３０６　ＨＤ（ハードディスク）
３０８　キーボード／ポインティングデバイスのインターフェイス
３０９　モニターのインターフェイス
１４０２　ＩＳＰのＰＰＰ　ｐｅｅｒ
１４０４　ＰＳＴＮ　（Ｐｕｂｌｉｃ　Ｓｗｉｔｃｈｅｄ　Ｔｅｌｅｐｈｏｎｅ　Ｎｅｔｗｏｒｋ）
【図１】
2004007512.tif 000003
【図２】
2004007512.tif 000004
【図３】
2004007512.tif 000005
【図４】
2004007512.tif 000006
【図５】
2004007512.tif 000007
【図６】
2004007512.tif 000008
【図７】
2004007512.tif 000009
【図８】
2004007512.tif 000010
【図９】
2004007512.tif 000011
【図１０】
2004007512.tif 000012
【図１１】
2004007512.tif 000013
【図１２】
2004007512.tif 000014
【図１３】
2004007512.tif 000015
【図１４】
2004007512.tif 000016
【図１５】
2004007512.tif 000017
【図１６】
2004007512.tif 000018
【図１７】
2004007512.tif 000019