JP2005333684A - 公開鍵生成装置、方法、及び、公開鍵証明書発行方法 - Google Patents

Abstract

【課題】 ＩＰｖ６通信が可能なＩＰｖ６対応装置に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。また、エンティティＡと同じＬＡＮ上のエンティティＣがエンティティＡになりすますこともありうる。
【解決手段】 ホスト２０６は、ゲートウェイ２０２に匿名公開鍵証明書を要求し、ゲートウェイ２０２は、匿名公開鍵を生成し、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ（ＣＡ）２０９に匿名公開鍵証明書を要求する。ＣＡ２０９は、匿名公開鍵証明書を作成し、この匿名公開鍵証明書は、ゲートウェイ２０２を介して、ホスト２０６に送られる。ホスト２０６は、必要に応じて、新たな匿名公開証明書を要求して、受け取り、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を送る。
【選択図】 図１

Description

本発明は、公開鍵を生成する公開鍵生成装置、方法、及び、公開鍵証明書を発行する公開鍵証明書発行方法に関する。

ＩＰｖ６の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けディジタルカメラである。

ＩＰｖ６に対応するパーソナル・コンピュータやワークステーションの場合、ネットワークとの接続のインターフェイスには通常はイーサネット（登録商標）が用いられ、それが持つ ＩＥＥＥ ｉｄｅｎｔｉｆｉｅｒ （ＭＡＣ ａｄｄｒｅｓｓ）を元にしてＩＰｖ６アドレスが構成されるようになっている。

ＩＰｖ６アドレスには、後述するようにリンクローカルアドレス、サイトローカルアドレスと（集約可能）グローバルアドレスの３種類が存在する。

それらの詳細や構成方法などのアドレス体系は、ＲＦＣ ２３７３ “ＩＰＶｅｒｓｉｏｎ ６ Ａｄｄｒｅｓｓｓｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ、’’ＲＦＣ ２３７４“Ａｎ ＩＰｖ６ Ａｇｇｒｅｇａｔａｂａｌｅ Ｇｌｏｂａｌ Ｕｎｉｃａｓｔ Ａｄｄｒｅｓｓ Ｆｏｒｍａｔ、’’ＲＦＣ ２３７５“ＩＰｖ６ Ｍｕｌｔｉｃａｓｔ Ａｄｄｒｅｓｓ Ａｓｓｉｇｎｍｅｎｔ、’’ＲＦＣ ２４５０“Ｐｒｏｐｏｓｅｄ ＴＬＡ ａｎｄ ＮＬＡ Ａｓｓｉｇｎｍｅｎｔ Ｒｕｌｅ、’’ＲＦＣ ２４６１“Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ ｆｏｒ ＩＰ Ｖｅｒｓｉｏｎ ６（ＩＰｖ６）、’’ＲＦＣ ２４６２“ＩＰｖ６ Ｓｔａｔｅｌｅｓｓ Ａｄｄｒｅｓｓ Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、’’等に記述されている。

ところで、ＩＥＥＥ ｉｄｅｎｔｉｆｉｅｒ（ＭＡＣ ａｄｄｒｅｓｓ）のようにハードウェアに１対１に対応する情報を固定的に用いると、それが装置もしくはその装置のユーザと１対１に対応する情報とみなされ、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。

この課題に対しては、ランダムなＩＰｖ６アドレス（正確にはインターフェイスＩＤ）を生成する方法が、ＲＦＣ３０４１“Ｐｒｉｖａｃｙ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｓｔａｔｅｌｅｓｓ Ａｄｄｒｅｓｓ Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎ ＩＰｖ６、’’等において提案されている。生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算／生成し、ユニークなランダムな値を定めるプロトコル（の拡張）も記述されている。

上記のような解決方法を利用して生成したランダムなＩＰｖ６アドレスを装置が使う場合に、ＩＰｓｅｃを用いて暗号通信を行なうことを考える。ＩＰｓｅｃは、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであり、通信に際して秘密データやお互いのＩＰｖ６アドレス等を安全に共有する必要がある。秘密データやお互いのＩＰｖ６アドレス等のデータはＳＡ（Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ）と呼ばれる。

ＳＡを安全に共有するプロトコルはＩＫＥ（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と呼ばれ、ＲＦＣ２４０９ “Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ（ＩＫＥ）’’において規定されている。ここで、ＳＡを安全に共有するという意味は、意図する相手のみと確実にＳＡを共有するという意味であり、相手を確実に認証することを必要とする。ＩＫＥには、１）ｐｒｅ−ｓｈａｒｅｄ ｋｅｙを用いる方法、２）ディジタル署名を用いる方法、３）公開鍵暗号による暗号化による方法、４）公開鍵暗号による暗号化の改訂モードによる方法、の計４つの認証方法が規定されている。

ところが、プライバシ保護（身元を明らかにする情報を与えない）を実現する状況を考えている、例えばユーザが買い物サイトとのＩＰｓｅｃ通信を行なうような場合であるので、買い物サイトの立場で考えれば、あらかじめ定まっていない不特定多数の通信相手とｐｒｅ−ｓｈａｒｅｄ ｋｅｙをＩＰｓｅｃ通信に先だって共有することは現実には不可能であるから、ｐｒｅ−ｓｈａｒｅｄ ｋｅｙを用いる方法は使えない。

その他の方法の場合は、ディジタル署名あるいは公開鍵暗号の使用に必要な情報（多くの場合は公開鍵）を確実に入手可能ならば、不特定多数の通信相手同士でＩＫＥを実行することが可能である。そのために最も有望視されているのが、ＰＫＩ（Ｐｕｂｌｉｃ−ｋｅｙ Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）と呼ばれる環境・仕組みであり、その中で中心的な役割を果たすのが、公開鍵証明書である。

公開鍵証明書は、信頼できる第三者がエンティティ（通信をする主体、計算機や人間）とそのエンティティの公開鍵の対応関係を確認し、それを保証するためにエンティティのＩＤ情報等と公開鍵の組みに対して信頼できる第三者が発行するディジタル署名である。信頼できる第三者はＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ）と呼ばれ、ＣＡのディジタル署名の正当性を確認するための公開鍵は、広く一般に知られている。

しかし、現在運用されている公開鍵証明書の中には、その持ち主（Ｓｕｂｊｅｃｔ）を示すＩＤ情報、例えば、ＦＱＤＮ（Ｆｕｌｌｙ Ｑｕａｌｉｆｉｅｄ Ｄｏｍａｉｎ Ｎａｍｅ）が含まれるので、そのままではプライバシ保護を実現できない。

公開鍵証明書の中にその持ち主のＩＤ情報を含めない方法も考えられ、匿名公開鍵証明書と呼ばれる。

しかし、匿名公開鍵証明書にも上述のＩＥＥＥ ｉｄｅｎｔｉｆｉｅｒ（ＭＡＣ ａｄｄｒｅｓｓ）と同じ課題が存在する。つまり、同一の匿名公開鍵証明書を使い続ける限り、複数の（公開鍵証明書に基づくＩＰｓｅｃ等の）通信を結び付けることは可能であり、もしも一度でも匿名公開鍵証明書とその持ち主の対応関係が明らかになったときは、プライバシが侵害されることにつながるので、やはりプライバシ保護の程度は弱い。

以上の課題に対して、例えば、異なる通信相手と通信する際に異なるＩＰｖ６アドレスおよび匿名公開鍵証明書を使うことが可能ならば、強いプライバシ保護が実現できると考えられる。これらを使い捨てＩＰｖ６アドレスおよび使い捨て匿名公開鍵証明書と呼ぶ。使い捨てる間隔としては、通信相手が変る度に新しい使い捨てＩＰｖ６アドレスを用いる、あるいはパケット毎に変えるなど、いくつかが考えられる。

しかし、使い捨てＩＰｖ６アドレスに関しては、前述のＲＦＣ３０４１“Ｐｒｉｖａｃｙ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｓｔａｔｅｌｅｓｓ Ａｄｄｒｅｓｓ Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎ ＩＰｖ６、’’が知られているが、ＩＰｖ６通信が可能な装置（以下では、ＩＰｖ６対応装置と表す）に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。

さらに、次の課題も存在する。通信相手のＩＤ情報がわからない場合、通信相手の識別はＩＰアドレスでのみ行なうことになる。しかし、例えばイーサネット（登録商標）のＬＡＮ上で送受されるパケットはそのＬＡＮ上のノード全てがアクセスできるので、本来はエンティティＡとエンティティＢが通信をするはずのところを、Ａと同じＬＡＮ上の悪意を持ったＣがＡになりすますこともありうる。つまり、ＡとＢの間で使い捨て匿名公開鍵証明書に基づくＩＰｓｅｃ通信を行なうために、Ａの公開鍵証明書がＢに送られる際に、Ａの公開鍵証明書をＣのものとすり替えることでＣはＡに成りすますことができてしまう。

ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバーやルーターに対してＤｏＳ（Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅｓ）攻撃を加え、その間に偽のＤＮＳサーバーやルーターが偽の情報を与えるようにすれば、ＬＡＮに限定されないより広域な範囲でのなりすましも可能となる。通信相手のＩＤが判明していれば、それを確認することで対処できたが、上記に示したような匿名性の高い状況において、この種の攻撃を防ぐ方法は今まで知られていない。

本発明の目的は、強力なプライバシ保護を実現することにある。

また、本発明の他の目的は、なりすましを防ぐことにある。

本発明の他の目的は、ＩＰｖ６アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することにある。

本発明の他の目的は、プライバシ保護の程度が高く、低コストで実現が可能で、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能にすることにある。

本発明の他の目的は、ＩＰｓｅｃの通信を効率的に実現することにある。

本発明の他の目的は、強力なプライバシ保護を実現し、かつなりすましを防ぎながらＩＫＥによるＩＰｓｅｃ通信を行なうことにある。

上記課題を解決するために、本出願に関わる発明は、ネットワークを介して通信装置と通信する通信手段と、公開のパラメータから匿名公開鍵を生成する生成手段と、前記通信装置から匿名公開鍵証明書を要求されると、前記生成手段により生成された匿名公開鍵を公開鍵証明書発行装置に送信する送信手段とを有し、前記匿名公開鍵は、前記通信装置が、前記通信装置の秘密鍵と共に前記匿名公開鍵を利用できるように生成されることを特徴とする。

以上説明したように、本出願に関わる発明によれば、強力なプライバシ保護を実現することができる。

また、なりすましを防ぐことができる。

また、ＩＰｖ６アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することができる。

また、プライバシ保護の程度が高く、低コストで実現が可能で、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能にすることができる。

また、ＩＰｓｅｃの通信を効率的に実現することができる。

また、強力なプライバシ保護を実現し、かつなりすましを防ぎながらＩＫＥによるＩＰｓｅｃ通信を行なうことができる。

（第１の実施の形態）
本実施の形態では、ホストがイーサネット（登録商標）のＬＡＮ経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本発明の実施の形態を説明する。

図２は、本発明が適用される接続環境（ホストがイーサネット（登録商標）のＬＡＮ経由でインターネットと接続する環境）を模式的に示したものである。

図２は、ＬＡＮに接続されたホスト２０４、２０５、２０６がｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２経由でインターネット２０１にアクセスする環境を示す。本実施の形態では、各ホストはリンク２０７で接続するものとし、具体的にはイーサネット（登録商標）であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、ＩＰ層の下側に接する。リンクにはイーサネット（登録商標）の他に、ＰＰＰリンク、Ｘ．２５、フレームリレー、ＡＴＭネットワークがある。

リンクに接続されたＩＰｖ６対応装置をノードと呼ぶ。

ノードの内部構成の典型例を図３に示す。

ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノード３００は、ネットワーク・インターフェイス３０１、３０２、ＣＰＵ３０３、ＲＯＭ３０４、ＲＡＭ３０５、ＨＤ（ハードディスク）３０６、電源３０７、キーボード／ポインティングデバイスのインターフェイス３０８、モニターのインターフェイス３０９、バス３１０等を有する計算機である。

ルーターは複数のインターフェイス３０１、３０２を持つのに対し、ホストは多くの場合は一つのインターフェイス３０１を持つ。ネットワーク・インターフェイス３０１は、リンク２０７に接続され、リンク２０７に接続された他のノードと通信する。ホスト２０４、２０５、２０６は、ネットワーク・インターフェイス３０１により、リンク２０７を介して、リンク２０７に接続された他のノード、あるいは、更に、ゲートウェイ２０２を介して、インターネット２０１上のサイトと通信する。ゲートウェイ（ルーター）２０２においては、ネットワーク・インターフェイス３０２は、インターネット２０１と接続され、ゲートウェイ（ルーター）２０２は、ネットワーク・インターフェイス３０２により、インターネット２０１を介して通信する。なお、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９も、図３と同様の構成を有する。Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９は、ネットワーク・インターフェイス３０１を介して、インターネット２０１に接続されている。ノードによってはＨＤを持たないものもある。

なお以下の処理内容（手順）は、装置もしくはプログラムとして実現される。すなわち、装置で実現する形態では、その装置を有するノード３００が、以下の処理内容（手順）を実行する。また、プログラムとして実現する形態では、そのプログラムがＲＯＭ３０４もしくはＨＤ３０６に格納されたノードが、以下の処理内容（手順）を実行する。例えば、プログラムとして実現される場合は、そのプログラムをＣＰＵ３０３が読み込み、必要に応じてＲＡＭ３０５を計算のための空間として利用しながらバス３１０を介してインターフェイス３０１、３０２にアドレスを割当てる、というような動作を行なう。

本実施の形態のイーサネット（登録商標）ＬＡＮ環境で各ホストがＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ ｇａｔｅｗａｙのアドレスを取得するプロトコルの仕組みを簡単に説明し、その次に本発明を適用した具体的な実施の形態を説明する。

図３のノードが、電源を入れられたあるいはリブートされた場合に行なう動作のフローチャートを図８に示す。この動作はＤＡＤ（Ｄｕｐｌｉｃａｔｅ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ）と呼ばれる。以下では図８の流れに沿って処理内容を説明する。

ステップＳ８０１でノード３００が電源を入れられたあるいはリブートされた後、まずネットワーク・インターフェイス３０１のイーサネット（登録商標）の ＭＡＣ ａｄｄｒｅｓｓ（図４参照）からインターフェイスＩＤ（図５参照）を作成し、それをｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓ（図６参照）とする（ステップＳ８０２）。

次に、そのｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓがリンク２０７上で一意かどうかを判断するために、ノード３００は以下の処理を行なう。

最初に、インターフェイス３０１の初期設定をする。すなわち、インターフェイス３０１に、ａｌｌ−ｎｏｄｅｓ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ（ＦＦ０２：：１）とそのｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓを割当てる（図７参照）。つまり、そのインターフェイス３０１がａｌｌ−ｎｏｄｅｓ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ宛のパケットあるいはそのｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ宛のパケットを見つけたときはそれを自分のインターフェイス宛のパケットとして受け取る。

前者（ａｌｌ−ｎｏｄｅｓ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ）を割当てることによって、既にそのｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓを使っている他のノードからのデータを受信することが可能になる。また、後者（そのｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ）を割当てることによって、同じｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓを同時に使おうとしている他のノードの存在を検出することが可能になる。

あるｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓとは、ＲＦＣ２４６１のｐａｇｅ ９１に定義されているように、ｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓの下位２４ビットをプレフィックスＦＦ０２：０：０：０：０：１：ＦＦ００：：／１０４に付加したデータであり、ｌｉｎｋ−ｌｏｃａｌ ｓｃｏｐｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓである。図６と図７にそれらの関係を示す。以上のアドレス割当てが図８のステップＳ８０３である。

次にＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅを作る。Ｎｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅのＴａｒｇｅｔ Ａｄｄｒｅｓｓ（ターゲットアドレス）には判断対象のｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓを、ＩＰ Ｓｏｕｒｃｅ（送信元アドレス）には ｕｎｓｐｅｃｉｆｉｅｄ ａｄｄｒｅｓｓ（１２８ビット全てが０）を、ＩＰ ｄｅｓｔｉｎａｔｉｏｎ（宛先アドレス）には判断対象のｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓを設定する。

このＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅをＲｅｔｒａｎｓＴｉｍｅｒミリセカンド間隔でＤｕｐＡｄｄｒＤｅｔｅｃｔＴｒａｎｓｍｉｔｓ個イーサネット（登録商標）２０７に送出する。図８のステップＳ８０４がこの処理である。

Ｎｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅを受け取ったノードは、その送信元アドレスがｕｎｓｐｅｃｉｆｉｅｄ ａｄｄｒｅｓｓならば、そのｍｅｓｓａｇｅがＤＡＤを行っているノードからのデータであることと判断する。

同時に複数のノードが同じアドレスを対象としてＤＡＤをしている場合は、自分が送ったＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅｓ以外にも、同じアドレスを Ｔａｒｇｅｔ Ａｄｄｒｅｓｓに含むＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅｓを受け取る（自分が送ったＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅと、同時にそのアドレスを対象としてＤＡＤをしている他のノードが送ったＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅを受け取る）ので、重複していることがわかる。その場合にはどのノードもそのアドレスは使わない。

なお、受け取ったＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅが、自分が送ったもの（マルチキャストのパケットをループバックしているため）であるならば、他にそれを使っているあるいは使おうとしているノードが存在することを示さない。自分が送ったＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅに加えて、同じアドレスを Ｔａｒｇｅｔ Ａｄｄｒｅｓｓに含むＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅｓを受け取った場合に、同時に複数のノードが同じアドレスを対象としてＤＡＤをしていると判断する。

一方、Ｎｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅを受け取ったノードが、そのｍｅｓｓａｇｅのＴａｒｇｅｔ Ａｄｄｒｅｓｓ（ターゲットアドレス）に含まれるアドレスを既に使っていれば、Ｔａｒｇｅｔ Ａｄｄｒｅｓｓにそのｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓが設定されたａ ｍｕｌｔｉｃａｓｔ Ｎｅｉｇｈｂｏｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔをａｌｌ−ｎｏｄｅｓ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ宛てに返す。従って、Ｎｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅを送ったノードがａｌｌ−ｎｏｄｅｓ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ宛てのａ ｍｕｌｔｉｃａｓｔ Ｎｅｉｇｈｂｏｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取り、そのｔａｒｇｅｔ ａｄｄｒｅｓｓが（判断対象の）ｔｅｎｔａｔｉｖｅ ａｄｄｒｅｓｓ である場合（図８のＳ８０５ステップの「はい」の場合）は判断対象のｔｅｎｔａｔｉｖｅ ａｄｄｒｅｓｓが唯一ではない（つまり、重複している）。

以上のＤＡＤの結果、判断対象のｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓがリンク２０７上で唯一であることが確認された（図８のＳ８０５ステップの「いいえ」の場合）ならば、そのアドレスをリンクローカルアドレスとしてインターフェイス３０１に割当てる。これが図８のステップＳ８０６である。以上でＤＡＤは終了する。

以上に説明した図８の動作は図２のｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２、ＤＨＣＰ ｓｅｒｖｅｒ ２０３、ホスト２０４、ホスト２０５、ホスト２０６のそれぞれが実行することができる。

図２のホスト、例えばホスト２０６は、リンクローカルアドレスをインターフェイス３０１に割当てたら、次はサイトローカルアドレスやグローバルアドレスを決定するために必要な情報（Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔと呼ばれる）をｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２から入手することを試みる。

この動作を図９に示す。ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２は通常はルーターと呼ばれるので以下ではルーター２０２と記す。ルーター２０２は管理者によって必要な設定が行われ、Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを定期的にリンク２０７に送っている。ホスト２０６が Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを早く入手したい場合は、ホスト２０６はＲｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎと呼ばれるデータをルーター２０２に送る。ホスト２０６はリンクローカルアドレスを割当てた直後にはルーター２０２の存在はわからないので、実際にはＲｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎはリンク上のルーター全てに対するマルチキャストとして送られる。図９のステップＳ９０１はこの処理を示す。

Ｒｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎを受け取ったルーター２０２はＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを送る。図９のステップＳ９０２の「はい」の場合に示すように、Ｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎのみを指定するＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取ったホスト２０６は、そのメッセージに含まれるプレフィックスの有効性（既にその装置によって使われていないこと等）を確認し、それ（ら）にインターフェイスＩＤを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとし、インターフェイス３０１に割当てる。図９のステップＳ９０３がこの処理である。

図９のステップＳ９０２の「いいえ」の場合に示すように、ホスト２０６がｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎのみを指定するＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取らなかった場合は、次の二つの場合に分けられる。Ｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取った場合（ステップＳ９０４のはいの場合）と、Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合（ステップＳ９０４のいいえの場合）である。

後者の場合はｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、すなわちＤＨＣＰｖ６のみを実行する。これがステップＳ９０６であり、その基本的な動作フローチャートを図１０に示す。

なお、ｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｔａｔｉｏｎ においてやり取りされるメッセージの内容や形式等の詳細は、”ｄｒａｆｔ−ｉｅｔｆ−ｄｈｃ−ｄｈｃｐｖ６−ｘｘ．ｔｘｔ”（２００２年３月においてｘｘ＝２３が最新版）に説明されている。以下では図１０の番号に沿って基本的な動作の流れを説明する。

ＤＨＣＰサーバー２０３は管理者によって必要な設定が行われている。具体的には、ノードとして自分のリンクローカルアドレスをインターフェイス３０１に割当ててあり、ＤＨＣＰサーバーとして振る舞うために必要なサイトローカルアドレスもしくはグローバルアドレスのためのプレフィックス等が設定されている。

図１０のステップＳ１００１で、ホスト２０４はＤＨＣＰサーバーにＤＨＣＰ Ｓｏｌｉｃｉｔ Ｍｅｓｓａｇｅを送る。ホスト２０６はどこにＤＨＣＰサーバーが存在するのかわからないのでＤＨＣＰサーバーに対するマルチキャストとしてリンク２０７に送出する。ホスト２０６の接続されているリンク２０７とは異なるリンク（図示せず）にＤＨＣＰサーバーがいる場合には、ＤＨＣＰ Ｓｏｌｉｃｉｔ Ｍｅｓｓａｇｅは、実際にはＤＨＣＰリレー（図示せず）によって中継されてＤＨＣＰサーバー２０３に届く。

ＤＨＣＰ Ｓｏｌｉｃｉｔ Ｍｅｓｓａｇｅを受け取ったＤＨＣＰサーバー２０３はそれに対する返答としてＤＨＣＰ Ａｄｖｅｒｔｉｓｅ Ｍｅｓｓａｇｅをホスト２０６に返す。これは（別リンクの場合はＤＨＣＰリレーによって中継されて）ホスト２０６に届く。これがステップＳ１００２である。この時点でホスト２０６はＤＨＣＰサーバー２０３のアドレスがわかる。

次にステップＳ１００３でホスト２０６は ＤＨＣＰ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ をＤＨＣＰサーバー２０３に送る。ＤＨＣＰサーバー ２０３はＤＨＣＰ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅを受け取ると、ステップＳ１００４でＤＨＣＰ Ｒｅｐｌｙ Ｍｅｓｓａｇｅをホスト２０６に送る。

ステップＳ１００４でＤＨＣＰ Ｒｅｐｌｙ Ｍｅｓｓａｇｅ受け取ったホスト２０６は、それからサイトローカルアドレスもしくはグローバルアドレスがわかるので、そのアドレスの中のインターフェイスＩＤが重複しているか否かを確認するために、ＤＡＤ処理に必要な処理を行なう。つまり、インターフェイス３０１に前述のマルチキャストアドレス等を設定する。これがステップＳ１００５である。

次に、ステップＳ１００６でＮｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ Ｍｅｓｓａｇｅ を送り、Ｎｅｉｇｈｂｏｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｍｅｓｓａｇｅを受け取るかどうかをステップＳ１００７で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをＤＨＣＰサーバー２０３から受け取るためにステップＳ１００３に戻り、同じ処理を繰り返す。

ホスト２０６は、図１０のステップＳ１００７でＮｅｉｇｈｂｏｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｍｅｓｓａｇｅを受け取らなかった場合はそのアドレスは重複していないので、ステップＳ１００８でそのアドレスをインターフェイス３０１に割当てる。

以上で図９のステップＳ９０６が終わる。ステップＳ９０４でＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合はこれで正常終了する。

ステップＳ９０２でｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取った場合は、ステップＳ９０５でｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を行なう。処理内容はステップＳ９０３とＳ９０６と同じである。

以上のようにして、イーサネット（登録商標）をインターフェイスとして持つホスト２０６はｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ とｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ （ＤＨＣＰｖ６）を任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、グローバルアドレス、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ等を自動設定することができる。

以上のプロトコルにおいて、インターフェイスＩＤにランダムな値を用いる場合、その値を対象にしてＤＡＤを行ない、リンク２０７における一意性を確認すれば、グローバルアドレスのプレフィックスと組み合わせて、使い捨てのＩＰｖ６グローバルアドレスを利用することができる。詳細は、ＲＦＣ３０４１ “Ｐｒｉｖａｃｙ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒＳｔａｔｅｌｅｓｓ Ａｄｄｒｅｓｓ Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ ｉｎ ＩＰｖ６、’’に記述されている。

次に本発明の実施の形態を説明する。上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。最初に、匿名公開鍵証明書の例を説明し、次にそれを効率的に発行するためのプロトコルを説明する。

匿名公開鍵証明書は、学術的にはＫａｚｕｏｍｉ Ｏｉｓｈｉ、Ｍａｓａｈｉｒｏ Ｍａｍｂｏ、 Ｅｉｊｉ Ｏｋａｍｏｔｏ、“Ａｎｏｎｙｍｏｕｓ Ｐｕｂｌｉｃ Ｋｅｙ Ｃｅｒｔｉｆｉｃａｔｅｓ ａｎｄ ｔｈｅｉｒ Ａｐｐｌｉｃａｔｉｏｎｓ’’ＩＥＩＣＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｆｕｎｄａｍｅｎｔａｌｓ ｏｆ Ｅｌｅｃｔｒｏｎｉｃｓ、Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅｓ、Ｅ８１−Ａ、１、ｐｐ。５６−−６４、１９９８においてその概念と具体的な実現方法が提案されており、その基本的な実現方法はＵＳＡの特許６、１５４、８４１としても開示されている。これらの方式では、証明書のユーザの匿名性は計算量的に保たれていた。

より強力な匿名性を提供する方式として、情報量的な匿名性を有する匿名公開鍵証明書の実現方法がＫａｚｕｏｍｉ Ｏｉｓｈｉ、“Ｕｎｃｏｎｄｉｔｉｏｎａｌｌｙ ａｎｏｎｙｍｏｕｓ ｐｕｂｌｉｃ ｋｅｙ ｃｅｒｔｉｆｉｃａｔｅｓ、’’Ｔｈｅ ２０００ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｃｒｙｐｔｏｇｒａｐｈｙ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｃｕｒｉｔｙ、ＳＣＩＳ２０００−Ｃ３２、２０００において開示されている。

本発明においては、前述の論文Ｋａｚｕｏｍｉ Ｏｉｓｈｉ、Ｍａｓａｈｉｒｏ Ｍａｍｂｏ、Ｅｉｊｉ Ｏｋａｍｏｔｏ、“Ａｎｏｎｙｍｏｕｓ Ｐｕｂｌｉｃ Ｋｅｙ Ｃｅｒｔｉｆｉｃａｔｅｓ ａｎｄ ｔｈｅｉｒ Ａｐｐｌｉｃａｔｉｏｎｓ’’に記載されている任意の方式を利用することができる。効率が劣ることを許容できるならば、前記論文中のＳｃｈｅｍｅ １、Ｓｃｈｅｍｅ ２、Ｓｃｈｅｍｅ ３を利用することも可能であり、それらも本発明に含まれる。

本実施の形態では計算量的な匿名性を有する匿名公開鍵証明書方式を用いる場合を例として取り上げる。説明の都合上必要な記号等を定義・導入してから、本実施の形態のプロトコルを説明する。

匿名公開鍵証明書を発行するエンティティＣＡは、共通のパラメータとして大きな素数ｐとｑを定める。ｑはｐ−１を割りきる。オーダーｑの生成元ｇとハッシュ関数Ｈを定める。秘密の乱数ｓ＿ｃａ（１以上ｑ以下）を生成し、ｖ＿ｃａ＝ｇ＾（ｓ＿ｃａ）ｍｏｄ ｐを計算する。ここで、Ａ＝（Ｂ）＾（Ｃ）ｍｏｄ Ｄは、整数Ａ、Ｂ、Ｃ、Ｄに対して、ＢをＣ乗した値をＤで割り、その剰余をＡとする計算を表す。エンティティＣＡはｐとｑとｇとＨとｖ＿ｃａを公開する。したがって、エンティティｉは、ｐとｑとｇとＨとｖ＿ｃａを把握している。

一方、匿名公開鍵証明書を利用するエンティティｉは、秘密の乱数ｓ＿ｉ（１以上ｑ以下）を生成し、ｖ＿ｉ＝ｇ＾（ｓ＿ｉ）ｍｏｄ ｐを計算する。ｓ＿ｃａやｓ＿ｉを秘密鍵、ｖ＿ｃａやｖ＿ｉ（および公開のパラメータ（ｇなど））を公開鍵と呼び、秘密鍵は自分以外の誰にも知られないように管理する。エンティティＣＡ、および、ｉは、公開鍵ｖ＿ｃａやｖ＿ｉ（および公開のパラメータ（ｇなど））を、把握している。

エンティティｉは、匿名公開鍵証明書を利用開始する際に、自分のエンティティ名（ユーザ名）とパスワード、公開鍵ｖ＿ｉをエンティティＣＡに登録する。エンティティＣＡは、必要に応じてエンティティの身元を物理的手段等で確認し、提示されたエンティティ名（ユーザ名）とパスワード、公開鍵ｖ＿ｉを記憶する。

匿名公開鍵証明書を発行する際、エンティティＣＡは、乱数ｒ（１以上ｑ以下）を生成し、（ｇ’、ｖ＿ｉ’）＝（ｇ＾ｒ ｍｏｄ ｐ、（ｖ＿ｉ）＾（ｒ）ｍｏｄ ｐ）を計算する。公開のパラメータ（ｐなど）やこの匿名公開鍵証明書の有効期限、公開鍵ｖ＿ｃａに対する公開鍵証明書等の証明書の管理・属性情報をＸとし、（ｇ’、ｖ＿ｉ’）とＸを含むメッセージ（のハッシュ値）に対してディジタル署名を生成する。ＣＡは離散対数問題に基づくディジタル署名方式、例えば、Ｓｃｈｎｏｒｒ署名方式を使うことができる。ここでは、秘密鍵ｓ＿ｃａを用いて、ディジタル署名を生成する。このディジタル署名をＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）と記す。

エンティティｉに対してＣＡが発行する匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））である。なお、本発明の変形例では、匿名公開鍵証明書の管理・属性情報Ｘには、ｖ＿ｃａに対する公開鍵証明書を含めない。

匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の発行を受けたエンティティｉは、その中から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし｜は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。また、ｖ＿ｉ’＝（ｇ’）＾（ｓ＿ｉ）ｍｏｄ ｐも確認する。それらが正しいと確認できたならば、ｇ’とｖ＿ｉ’（と共通のパラメータｐ）を公開鍵、ｓ＿ｉを秘密鍵として離散対数問題に基づく公開鍵暗号やディジタル署名を利用できる。

匿名公開鍵証明書（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））を受け取ったエンティティは、その中から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。それが正しいと確認できたならば、ｇ’とｖ＿ｉ’（と共通のパラメータｐ）を用いて離散対数問題に基づく公開鍵暗号の暗号化やディジタル署名の検証を行なう。

なお、上記の説明では乗法群（ｍｏｄ ｐ）上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能であり、その場合は乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。

以上の匿名公開鍵証明書方式を、図２の環境に適用する場合を説明する。

Ｃｅｒｔｉｆｉｃａｉｔｏｎ Ａｕｔｈｏｒｉｔｙ ２０９がエンティティＣＡ、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。但し、Ｃｅｒｔｉｆｉｃａｉｔｏｎ Ａｕｔｈｏｒｉｔｙ ２０９が上記匿名公開鍵証明書方式におけるＣＡの全ての機能を有するわけではない。以下では、公開鍵証明書を利用するＩＰｖ６対応装置（ホスト２０６）の位置するローカルリンク２０７内に存在し、かつ、公開鍵証明書発行者（ＣＡ、つまりＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９）が信用するＩＰｖ６対応装置がｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２である場合を説明する。つまり、匿名公開鍵証明書方式におけるエンティティＣＡの機能の一部は、Ｃｅｒｔｉｆｉｃａｉｔｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の代わりに、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２が有する場合を説明する。

なお、ＣＡ ２０９が信用するＩＰｖ６対応装置はＤＨＣＰサーバー２０３や専用ＣＡサーバーでもよい。また、以下では、ランダムなＩＰｖ６アドレスを証明書の中に含める形態を説明するが、ランダムなＩＰｖ６アドレスを証明書に含めない形態もあるかもしれない。前述のように、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２をルーター２０２と呼ぶことにする。

Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の管理者は、上述の公開パラメータｐ、ｇ等を定め、公開する。また、エンティティＣＡとしての公開鍵ｖ＿ｃａを定める。

Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９がｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２（あるいはＤＨＣＰサーバーや専用ＣＡサーバー）を信用するということは、ここでは、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２等の管理元がはっきりしており、問題が生じたときにその管理元が責任を負う条件がＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９とその管理元との間で合意されていることとする。例えば、ある匿名公開鍵に関するトラブルが起ったとき、その匿名公開鍵のユーザを特定し責任をとらせる処理をｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２等の管理元が責任を持って行なうことが、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９と ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２等の管理元との間で契約書によって合意されている場合等である。

また、この場合には、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９とｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２（あるいはＤＨＣＰサーバーや専用ＣＡサーバー）は、例えば、公開鍵暗号を安全に交換してあるとか秘密の暗号化鍵を安全に共有してある等により、それらの間では、インターネットを介して確実で安全な通信が行なえるものとする。

ルーター（ｇａｔｅｗａｙ）２０２は、パケットの転送を制御する役目を持ち、そのルーター２０２の管轄するサブネットと外部との間で不適当なパケットが出入りしないように管理者の責任のもとで運用される。あるサブネットがインターネット２０１に接続されるためにはそのサブネットの管理者は身元をＪＰＮＩＣ（日本の場合）に登録し、ＩＰアドレスの割当てを受ける。従って、サブネットにおけるルーター２０２は管理責任が明確であり、かつ安全面も考慮されたうえで運用や管理にコストがかけられると期待されるので、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９が信用するにふさわしいと考えられる。

ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＬＡＮの管理者（ルーター２０２の管理者）に提出する。ＬＡＮの管理者（ルーター２０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、ユーザｉのエンティティ名からユーザｉの公開鍵ｖ＿ｉが検索できるように、ルーター２０２のＲＡＭ３０５あるいはＨＤ ３０６に登録する。公開パラメータや公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。

以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１に示す。図１は、エンティティ（ユーザｉが用いるＩＰｖ６端末）をホスト２０６、ＣＡを Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９とし、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９はルーター２０２を信用するものであり、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。ここで、ルーター２０２は、アドレスを設定するためのアドレス情報をホスト（通信装置）２０６に提供するアドレス情報提供装置、あるいは、提供者である。なお、アドレス情報は、ＩＰｖ６のグローバルアドレスのプレフィックス、あるいは、ＩＰｖ６のグローバルアドレス自体である。

匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター２０２とエンティティ（この場合は、ホスト２０６）の間でなんらかの特定（認証）プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１の流れに沿って動作を説明する。

ホスト２０６はステップＳ１０１でＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎを生成する。Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎは、匿名公開鍵証明書を要求するメッセージであり、その旨とインターフェイス３０１のインターフェイスＩＤを含むデータであることをルーター２０２が理解できる形式であるとする。内容は、エンティティ名（ユーザ名）とパスワードとシリアル番号から計算される。シリアル番号は、例えばホスト２０６のＩＰｖ６リンクローカルアドレスとｄｅｆａｕｌｔ ｇａｔｅｗａｙのＩＰｖ６リンクローカルアドレスとそのときの時刻の３つを連接して一つのデータにした値を採用できる。再送攻撃となりすましを防ぐために、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数に入力した値に対して、秘密鍵ｓ＿ｉを用いて生成したディジタル署名（認証用ｓｉｇｎａｔｕｒｅ）（＝Ｓｉｇ＿ｉ（ｈａｓｈ（エンティティ名、パスワード、シリアル番号）））がＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎに含まれる。

次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ ＳｏｌｉｃｉｔａｔｉｏｎをステップＳ１０２でネットワーク・インターフェイス３０１からルーター２０２に送る。

ステップＳ１０３で、ルーター２０２はステップＳ１０２でネットワーク・インターフェイス３０１から受け取ったＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（識別子）から登録された公開鍵ｖ＿ｉをＲＡＭ ３０５あるいはＨＤ ３０６から検索し、それを用いて認証用ｓｉｇｎａｔｕｒｅの正当性を確認する。具体的には、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数の入力とし、そのハッシュ値を求め、認証用ｓｉｇｎａｔｕｒｅがそれに対する正しいディジタル署名であることを公開鍵ｖ＿ｉで確認する。すなわち、ディジタル署名を含むＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎをインターフェイス３０１がホスト２０６から受信すると、ＣＰＵ ３０３は、ホスト２０６の公開鍵ｖ＿ｉを用いて、ディジタル署名の正当性を確認する。以上のように、ルーター２０２は、公開鍵暗号に基づき、ホスト２０６を認証する。

認証が成功したら、ルーター２０２は、ＩＰｖ６のグローバルアドレスのプレフィックスとホスト２０６のインターフェイス３０１のインターフェイスＩＤ とからホスト２０６のＩＰｖ６グローバルアドレスを生成する。そして、Ｓ１０３Ａで、乱数ｒを生成し、生成元ｇと公開鍵ｖ＿ｉから前述のように、（ｇ’、ｖ＿ｉ’）＝（ｇ＾ｒ ｍｏｄ ｐ、（ｖ＿ｉ）＾（ｒ）ｍｏｄ ｐ）を求める（このｇ’とｖ＿ｉ’の二つを匿名公開鍵と呼ぶ）。すなわち、ＣＰＵ ３０３は、公開鍵ｖ＿ｉから公開鍵ｖ＿ｉ’を生成する。そして、ホスト２０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）に対するｒｏｕｔｅｒ ２０２の署名である認証用ｓｉｇｎａｔｕｒｅ（２）を生成する。

なお、ここでは、認証の成功後、公開鍵ｖ＿ｉ’を生成したが、変形例では、認証の成功前、あるいは、匿名公開鍵証明書が要求される前に、予め、公開鍵ｖ＿ｉ’を生成して、ＲＡＭ３０５、ＨＤ３０６に登録しておく。

最後に、ＩＰｖ６のグローバルアドレスと匿名公開鍵とそれらに対する認証用ｓｉｇｎａｔｕｒｅ（２）を含む匿名公開鍵証明書要求メッセージ＝｛ＩＰｖ６グローバルアドレス、匿名公開鍵、認証用ｓｉｇｎａｔｕｒｅ（２）｝を、ステップＳ１０４でネットワーク・インターフェイス３０２からインターネット２０１経由でＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９に送る。すなわち、インターフェイス３０２は、ＣＰＵ ３０３の制御の元に、匿名公開鍵（ｇ’、ｖ＿ｉ’）に対する公開鍵証明書の発行を要求する公開鍵証明書要求メッセージを、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９に送信する。Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９は、公開鍵証明書を発行する発行者、あるいは、発行装置である。ルーター２０２は、公開鍵生成装置である。ルーター２０２のインターフェイス３０１は、ネットワーク２０７を介して通信装置（ホスト２０６）と通信する通信手段であり、ＣＰＵ３０３は、公開鍵を生成する生成手段である。また、ルーター２０２のインターフェイス３０２は、通信装置（ホスト２０６から公開鍵証明書を要求されると、ＣＰＵ３０２により生成された公開鍵を公開鍵証明書発行者（ＣＡ２０９）に送信する送信手段である。

前述のように、ｒｏｕｔｅｒ ２０２とＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９は、インターネット２０１を介して確実で安全な通信が行なえるので、データ内容が改竄されたり第三者になりすまされたりすることはない。

ステップＳ１０５で Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９は、ネットワーク・インターフェイス３０１から受け取った認証用ｓｉｇｎａｔｕｒｅ（２）が本当に正しいｒｏｕｔｅｒ ２０２に生成されたか否かを確認する。前述の確実で安全な通信によって受け取った場合は、データを受け取った事実自体が正しいｒｏｕｔｅｒ ２０２に生成されたデータであることを証明する場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合もある。

いずれにせよ、認証用ｓｉｇｎａｔｕｒｅ（２）の正当性を確認したＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９は、証明書要求メッセージの中に含まれるＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）に、それらに関する管理・属性情報Ｘを付加したメッセージ（のハッシュ値）に対してディジタル署名Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）を生成する。このディジタル署名には、秘密鍵ｓ＿ｃａを用いる。証明書の管理・属性情報Ｘは、公開のパラメータや証明書の有効期限、ｖ＿ｃａに対する公開鍵証明書等を含む。本発明の変形例では、この情報Ｘには、ｖ＿ｃａに対する公開鍵証明書は、含めない。匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、ＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）とそれらに関する管理・属性情報Ｘとそれらに対するディジタル署名からなるデータである。すなわち、インターフェイス３０１が、ルーター２０２から公開鍵証明書要求メッセージを受信すると、ＣＰＵ ３０３は、公開鍵証明書要求メッセージに含まれるＩＰｖ６グローバルアドレスのアドレス情報と公開鍵（ｇ’、ｖ＿ｉ’）（および証明書の管理・属性情報Ｘ）を含むメッセージに対して、ディジタル署名を生成する。ルーター２０２は、アドレスを設定するためのアドレス情報をホスト２０２（通信装置）に提供する提供者である。

そして、ステップＳ１０６で匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））をネットワーク・インターフェイス３０１からインターネット２０１経由でｒｏｕｔｅｒ ２０２に送る。すなわち、インターフェイス３０１は、ＩＰｖ６グローバルアドレスのアドレス情報と、公開鍵（ｇ’、ｖ＿ｉ’）と、ディジタル署名を含む公開鍵証明書を発行する。

匿名公開鍵証明書をネットワーク・インターフェイス３０２から受け取ったｒｏｕｔｅｒ ２０２は、ステップＳ１０７で、ＩＰｖ６グローバルアドレスのプレフィックスとｄｅｆａｕｌｔｒｏｕｔｅｒ ２０２のアドレスと匿名公開鍵証明書からなるＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔを認証されたホスト２０６にネットワーク・インターフェイス３０１から送る。ここで、本発明の一実施例では、登録された公開鍵ｖ＿ｉを用いて暗号化して、送信する。すなわち、インターフェイス３０１は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９により公開鍵（ｇ’、ｖ＿ｉ’）に対して発行された公開鍵証明書を、ホスト２０６に送信する。ホスト２０６は、Ｓ１０３において認証された通信装置であり、Ｓ１０３において正当性が確認されたディジタル署名を含むＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎの送信元である。

ステップＳ１０８でホスト２０６はネットワーク・インターフェイス３０１から受け取ったＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔからプレフィックスを取り出し、ＩＰｖ６グローバルアドレスを生成し、匿名公開鍵証明書の正当性を確認する。

ここで、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の正当性、すなわち、（ｇ’、ｖ＿ｉ’）とＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）の対応関係の正しさを確認する。例えば、ホスト２０６は、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし｜は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の公開鍵ｖ＿ｃａを予め記憶している。匿名公開鍵証明書の管理・属性情報Ｘに公開鍵ｖ＿ｃａの公開鍵証明書が含まれている形態では、ホスト２０６は、予め記憶している公開鍵ｖ＿ｃａが、匿名公開鍵証明書の管理・属性情報Ｘに含まれている公開鍵ｖ＿ｃａの公開鍵証明書中の公開鍵ｖ＿ｃａと一致することを確認してから、この公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。

以上のプロトコルを既存のＲｏｕｔｅｒ ＳｏｌｉｃｉｔａｔｉｏｎとＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔの送受信プロトコルと組み合わせた拡張プロトコルのホストの動作フローチャートを図１１に示す。

図１１のステップＳ１１０１におけるＲｏｕｔｅｒ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎメッセージとは、図９のステップ９０１のＲｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎと図１のステップＳ１０２で送られるＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎの両方を含むデータである。ルーター２０２は、このデータを受信すると、図１のＳ１０３、Ｓ１０３Ａ、Ｓ１０４の処理を行ない、Ｓ１０６と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９から匿名公開鍵証明書を受け取る。そして、ルーター２０２は、Ｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ のみを指定するＲｏｕｔｅｒ ＡｄｖｅｒｔｉｓｅｍｅｎｔとＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔの両方を含むＲｏｕｔｅｒ Ｃｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｍｅｓｓａｇｅを、ホスト２０６に送る。

したがって、ステップＳ１１０２で受け取るＲｏｕｔｅｒ Ｃｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｍｅｓｓａｇｅとは、図９のステップＳ９０２で受け取るＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｍｅｓｓａｇｅと図１のステップＳ１０７で受け取るＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔの両方を含むデータである。

図１におけるステップＳ１０８を行なって正当性が確認できたならば、ステップＳ１１０２で「はい」の場合となり、ステップＳ１１０３において、ＩＰｖ６グローバルアドレスを生成し、インターフェイス３０１に割当てるとともに、匿名公開鍵証明書の正当性を確認する。ここでは、Ｓ１０８と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。

以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書を発行することができる。

なお、ルーター２０２の代りにＤＨＣＰサーバー２０３がＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９に信用されている場合は、Ｒｏｕｔｅｒ Ｃｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｍｅｓｓａｇｅが受信されないので、図１１におけるステップＳ１１０６において図１と同様のプロトコルをルーター２０２の代りにＤＨＣＰサーバー２０３が実行する。なお、ＤＨＣＰサーバーの管理元はｄｅｆａｕｌｔ ｇａｔｅｗａｙ２０２の管理元と同様にトラブルの際の責任を持つものとする。

この場合には図１１のステップＳ１１０６で、ホストはｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの拡張プロトコル、つまりＤＨＣＰサーバーからアドレスと証明書を取得するプロトコルを実行する。その動作フローチャートを図１２に示す。

図１０のプロトコルとの違いは、ステップＳ１２０３とステップＳ１２０４の二カ所である。

ステップＳ１２０３で送るＤＨＣＰ Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅは、図１０のステップＳ１００３で送るＤＨＣＰ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅと図１のステップＳ１０２で送られるＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎ相当のデータ（送信先が、ルーター２０２ではなくＤＨＣＰサーバー２０３である点が異なる）の両方を含むデータである。

このメッセージを受け取ると、ＤＨＣＰサーバー２０３は、図１のＳ１０３、Ｓ１０３Ａ、Ｓ１０４の処理を行ない、Ｓ１０６と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９から匿名公開鍵証明書を受け取る。そして、ＤＨＣＰサーバー２０３は、ＤＨＣＰ Ｒｅｐｌｙ ＭｅｓｓａｇｅとＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ相当のデータの両方を含むＤＨＣＰ Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｐｌｙ Ｍｅｓｓａｇｅを、ホスト２０６に送る。

したがって、ステップＳ１２０４で受け取るＤＨＣＰ Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｐｌｙ Ｍｅｓｓａｇｅは、図１０のステップＳ１００４で受け取るＤＨＣＰ Ｒｅｐｌｙ Ｍｅｓｓａｇｅと図１のステップＳ１０７で受け取るＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ相当のデータ（送信元がルーター２０２ではなくＤＨＣＰサーバー２０３である点が異なる）の両方を含むデータである。そして、ＩＰｖ６グローバルアドレスを生成し、インターフェイス３０１に割当てるとともに、匿名公開鍵証明書の正当性を確認する。ここでは、Ｓ１０８と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。

以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書を発行することができる。

ルーター２０２およびＤＨＣＰサーバー２０３の両方がＣＡのＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９に信用されている場合は、図１１におけるステップＳ１１０４で ｓｔａｔｅｌｅｓｓとｓｔａｔｅｆｕｌの両方を指定するＲｏｕｔｅｒ Ｃｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ Ｍｅｓｓａｇｅを受け取った場合（「はい」の場合）が相当し、上記に示した二つの拡張プロトコルを任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、使い捨てＩＰｖ６グローバルアドレスとそれに対応する使い捨て匿名公開鍵証明書、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ等を自動設定および取得する。この場合、ルーター２０２およびＤＨＣＰサーバー２０３は、アドレスを設定するためのアドレス情報をホスト（通信装置）２０６に提供する情報処理装置群に相当し、この情報処理装置群であるルーター２０２およびＤＨＣＰサーバー２０３は、公開鍵証明書をＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９に要求し、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９が発行した公開鍵証明書をホスト２０６に送信する。

ルーター２０２でもＤＨＣＰサーバー２０３でもない別のＩＰｖ６対応装置の専用ＣＡサーバーが公開鍵証明書発行者２０９に信用されており、専用ＣＡサーバーと公開鍵証明書発行者２０９とが協調して動作して公開鍵証明書をあるホストに発行する場合、その専用ＣＡサーバーが対象ホストと同一のローカルリンク２０７内に存在するならば、図１示のルーター２０２の動作とほぼ同様の動作によって、公開鍵証明書を発行できる。

図２において、対象ホストがホスト２０６であり、専用ＣＡサーバーがホスト２０４である場合、それらの間の動作は図１と同様である。ただし、専用ＣＡサーバーはそのサブネット、図２の場合で言えばリンク２０７に割当てられている正しいＩＰｖ６プレフィクスを知っているという前提を必要とする。したがってルーター２０２の管理者と同様の責任を有する管理者によって専用ＣＡサーバーは管理されており、問題がおこったときの対応等についてもルーター２０２の場合と同様にＣｅｒｔｉｆｉｃａｔｉｏｎＡｕｔｈｏｒｉｔｙ ２０９と管理者との間で合意がなされている必要がある。

ホスト２０６は、通信相手が変る度に、あるいは、セッションが変る度に、若しくは、通信パケット送信の度に、図１１のＳ１１０１のＲｏｕｔｅｒ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎメッセージ（図１のＳ１０１の匿名公開鍵証明書を要求するメッセージであるＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎ）を、インターフェイス３０１から、リンク２０７に送出し、Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ ２０９からの匿名公開鍵証明書を受け取る。すなわち、ホスト２０６は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。ここで、公開鍵（ｇ’、ｖ＿ｉ’）は、同一のエンティティの公開鍵であるが、時間の経過に伴い変更される公開鍵である。

なお、ルーター２０２あるいはＤＨＣＰサーバー２０３がＩＰｖ６アドレスのプレフィックスをホスト２０６に提供する形態を説明したが、ＩＰｖ６アドレスそのものを提供する形態ではプレフィックスのかわりにアドレスが送られる点とホストがアドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。

（第２の実施の形態）
第１の実施の形態では、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ（ルーター）がホストを認証してから、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ（ルーター）とＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙが協調動作して、匿名公開鍵証明書とプレフィックスを含む Ｃｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔ をホストに送った。本実施の形態では、プレフィックスの送付と匿名公開鍵証明書の発行が独立な例を説明する。

第１の実施の形態と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９がエンティティＣＡ、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。但し、Ｃｅｒｔｉｆｉｃａｉｔｏｎ Ａｕｔｈｏｒｉｔｙ ２０９が前述の匿名公開鍵証明書方式におけるＣＡの全ての機能を有するわけではない。以下では、匿名公開鍵証明書を利用するＩＰｖ６対応装置（ホスト２０６）の位置するローカルリンク２０７内に存在し、かつ、公開鍵証明書発行者（ＣＡ、つまりＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ２０９）が信用するＩＰｖ６対応装置がｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２である場合を説明する。つまり、匿名公開鍵証明書方式におけるエンティティＣＡの機能の一部は、Ｃｅｒｔｉｆｉｃａｉｔｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の代わりに、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２が有する場合を説明する。

なお、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９が信用するＩＰｖ６対応装置はＤＨＣＰサーバーや専用サーバーでもよい。また、以下では、ランダムなＩＰｖ６アドレスを証明書の中に含める形態を説明するが、ランダムなＩＰｖ６アドレスを証明書に含めない形態もあるかもしれない。前述のように、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２をルーター２０２と呼ぶことにする。ここでは、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２は、ホスト２０６に、ＩＰｖ６のグローバルアドレスのプレフィックスを提供する。

また、この場合には、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９とｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２（あるいはＤＨＣＰサーバーや専用サーバー）は、例えば、公開鍵暗号を安全に交換してあるとか秘密の暗号化鍵を安全に共有してある等により、それらの間では、インターネットを介して確実で安全な通信が行なえるものとする。Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の管理者は、ＣＡとしての公開鍵ｖ＿ｃａを定める。ルーター２０２の管理者は、前述の公開パラメータｐ、ｇ等を定め、公開する。ルーター２０２の公開鍵ｖ＿ｒｏｕｔｅｒも定め、公開する。

ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＬＡＮの管理者（ルーター２０２の管理者）に提出する。ＬＡＮの管理者（ルーター２０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵ｖ＿ｉが検索できるように、ＲＡＭ ３０４もしくはＨＤ３０６に登録する。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。

以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１５に示す。図１５は、匿名公開鍵証明書を利用するエンティティ（ユーザｉが用いるＩＰｖ６端末）をホスト２０６、プレフィックスを提供するＩＰｖ６端末をｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２、匿名公開鍵証明書を発行するＣＡをＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９とし，それらの間で行なわれる匿名公開鍵証明書の発行プロトコルの動作フローを表している。

匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター２０２とエンティティ（この場合は、ホスト２０６）の間でなんらかの特定（認証）プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１５を参照しながら動作を説明する。

ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。そして、ＭＡＣアドレスから生成したインターフェイスＩＤに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ないＲｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎ（ＲＳ）をルーターに送る（ステップＳ１５０１）。ＲＳは前述のようにリンク上のルーター全て宛のｍｕｌｔｉｃａｓｔである。

ルーター２０２は、ＲＳを受け取ったら、Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ（ＲＡ）を送る（ステップＳ１５０２）。

ＲＡを受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤとプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ ａｄｄｒｅｓｓと呼ぶ）を生成する。また、ランダムなインターフェイスＩＤとプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓと呼ぶ）を作る。そして、ｐｕｂｌｉｃ ａｄｄｒｅｓｓとｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる（ステップＳ１５０３）。

次に、ホスト２０６はＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎを生成する（ステップＳ１５０４）。Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎは、匿名公開鍵証明書を要求するメッセージであり、ホスト２０６が匿名公開鍵証明書を要求する旨を含むデータであることをルーター２０２が理解できる形式で生成する。例えば、ＲＦＣ２９８６，“ＰＫＣＳ ＃１０：Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｓｙｎｔａｘ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．７，’’で規定されているＰＫＣＳ＃１０や、ＲＦＣ２５１１，“Ｉｎｔｅｒｎｅｔ Ｘ．５０９ Ｃｅｒｔｉｆｉｃａｔｅ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅ Ｆｏｒｍａｔ’’等がそれらの形式を規定している。詳細の説明は省くが、証明書要求メッセージと、それに対する（ホストの）署名からなるデータであるとする。証明書要求メッセージには、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓが含まれている。

次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎを、リンク２０７を介してルーター２０２に送る（ステップＳ１５０５）。なお、この時点でルーター２０２の（ユニキャスト）アドレスをホスト２０６は知っているので ｕｎｉｃａｓｔ することが可能である。

ルーター２０２はステップＳ１５０５で受け取ったＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（ホスト２０６の識別子もしくはホスト２０６を利用するユーザの名前）から登録された公開鍵ｖ＿ｉをＲＡＭ ３０５もしくはＨＤ３０６から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト２０６の匿名公開鍵を作成する。具体的には、前述のｇ’、ｖ＿ｉ’、ｐ、ｑが匿名公開鍵である。そして、匿名公開鍵に対する証明書をＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９に発行してもらうため、匿名公開鍵証明書要求メッセージを生成する（ステップＳ１５０６）。

次に、ルーター２０２は、匿名公開鍵証明書要求メッセージをＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ２０９に送る（ステップＳ１５０７）。この匿名公開鍵証明書要求メッセージの形式は前述の証明書要求メッセージと同様とし、匿名公開鍵証明書要求メッセージとそれに対するルーターの署名からなるデータ等であるとする。この匿名公開鍵証明書要求メッセージにはホスト２０６のｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓが含まれている。

匿名公開鍵証明書要求メッセージをルーター２０２から受け取ったＣｅｒｔｉｆｉｃａｔｉｏｎＡｕｔｈｏｒｉｔｙ２０９は、それがルーター２０２によって作成されたか正しいデータであるか否かを確認する。例えば、前述の確実で安全な通信によって受け取った場合は、データを受け取った事実自体が正しいｒｏｕｔｅｒ ２０２に生成されたデータであることを証明するとみなせる場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合にはルーターの公開鍵ｖ＿ｒｏｕｔｅｒで確認できる場合もある。

いずれにせよ、匿名公開鍵証明書要求メッセージの正当性を確認したＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９は、証明書要求メッセージの中に含まれる匿名公開鍵（ｇ’、ｖ＿ｉ’、ｐ、ｑ）とｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓ、それらに関する管理・属性情報を付加したメッセージ（のハッシュ値）に対してディジタル署名を生成し、そのメッセージと、署名からなる匿名公開鍵証明書を生成する（ステップＳ１５０８）。本発明のある形態では、この匿名公開鍵証明書は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９の公開鍵を含む。

そして、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９は匿名公開鍵証明書を、ルーター２０２に送る（ステップＳ１５０９）。本発明のある形態では、この匿名公開鍵証明書を登録された公開鍵を用いて暗号化して、送信する。

ルーター２０２は、匿名公開鍵証明書を含むＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔを、ホスト２０６に送る（ステップＳ１５１０）。本発明のある形態では、このＣｅｒｔｉｆｉｃａｔｅＡｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。なお、このとき、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓ宛のｕｎｉｃａｓｔとして、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ２０９から直接ホスト２０６に送ることも可能である。

ホスト２０６は受け取ったＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔから匿名公開鍵証明書の正当性を確認する（ステップＳ１５１１）。

以上のプロトコルを既存のｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎおよびｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎと組み合わせた拡張プロトコルのホストの動作フローチャートを図１６に示す。

ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。そして、ＭＡＣアドレスから生成したインターフェイスＩＤに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない Ｒｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎ （ＲＳ） をルーターに送る（ステップＳ１７０１）。ＲＳは前述のようにリンク上のルーター全て宛の ｍｕｌｔｉｃａｓｔ である。

ステップＳ１７０２の「はい」の場合に示すように、Ｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ のみを指定するＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージ（ＲＡ）を受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤと抽出したプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ ａｄｄｒｅｓｓと呼ぶ）を生成する。また、ランダムなインターフェイスＩＤ と抽出したプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓと呼ぶ）を作る。そして、ｐｕｂｌｉｃ ａｄｄｒｅｓｓ とｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる（ステップＳ１７０３）。

次に、ホスト２０６は、証明書要求と証明書発行のプロトコルを実行する（ステップＳ１７０７）。すなわち、ホスト２０６は、図１５のステップＳ１５０４、Ｓ１５０５で示したように、Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎを生成し、ルーター２０２に送る。ホスト２０６は、ルーター２０２からＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取り、その中に含まれる匿名公開鍵証明書の正当性を確認する。なお、Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合は（ステップＳ１７０４のいいえの場合）、ｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、すなわちＤＨＣＰｖ６のみを実行する。これがステップＳ１７０６であり、その詳細は図１０のプロトコルと同じである。

ステップＳ１７０４でｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを受け取った場合は、ステップＳ１７０５でｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を行なう。処理内容はステップＳ１７０３とＳ１７０６と同じである。

（第３の実施の形態）
本実施の形態では、ホストがダイヤルアップあるいはＡＤＳＬのような方式でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本発明の形態を説明する。

図１４は、本発明が適用される接続環境を模式的に示したものである。図１４は、ホスト１４０６がＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏｎｅ Ｎｅｔｗｏｒｋ）経由でＩＳＰ（Ｉｎｔｅｒｎｅｔ Ｓｅｒｖｉｃｅ Ｐｒｏｖｉｄｅｒ）の提供するインターネット１４０１とアクセスする環境を示す。本実施の形態では、ＩＳＰとホストはＰＰＰリンクで接続するものとする。

図１４において、ＩＳＰのＰＰＰ ｐｅｅｒ １４０２はノードであり、ｍｏｄｅｍ １４０３を用いてＰＳＴＮ １４０４を介してホスト１４０６からのＰＰＰ接続の要求を受け付ける。ＰＰＰ ｐｅｅｒ １４０２は、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ ｍｏｄｕｌｅ １４０２１、ＤＨＣＰ ｍｏｄｕｌｅ １４０２２、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｍｏｄｕｌｅ １４０２３としての機能を有する。ホスト１４０６はｍｏｄｅｍ １４０５を用いてＰＰＰ ｐｅｅｒ １４０２にＰＰＰ接続でアクセスする。ホスト１４０６の構成は、図３と同様であり、ネットワーク・インターフェイス３０１を介して、モデム１４０５を接続する。また、ＰＰＰ ｐｅｅｒ １４０２の構成も、図３と同様であり、ネットワーク・インターフェイス３０１を介して、モデム１４０３を接続し、ネットワーク・インターフェイス３０２を介して、リンク１４０７（さらに、インターネット１４０１）と接続する。ＰＰＰ ｐｅｅｒ １４０２は、アドレスを設定するためのアドレス情報をホスト１４０６（通信装置）に提供するアドレス情報提供装置である。

本実施の形態では、ｍｏｄｅｍとＰＳＴＮを例として取り上げて説明するが、ＴＡ（Ｔｅｒｍｉｎａｌ Ａｄａｐｔｅｒ）とＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｄｉｇｉｔａｌ Ｎｅｔｗｏｒｋ）、ＰＨＳ通信アダプターとＰＨＳ通信網、専用線接続装置と専用線等の他の通信形態であったとしてもＰＰＰ接続が確立できる環境であれば本質的には同じである。ＰＰＰ接続の詳細は、ＲＦＣ １６６１“Ｔｈｅ Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ（ＰＰＰ）’’に記述されている。

ホスト１４０６がモデム１４０５、ＰＳＴＮ１４０４、モデム１４０３を介してＰＰＰ接続の要求をＰＰＰｐｅｅｒ １４０２に伝える。ＰＰＰ ｐｅｅｒ １４０２は、その接続要求を受け、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｍｏｄｕｌｅ １４０２３がホストの認証を行なう。典型的な認証方式は、ユーザ名とパスワードに基づく認証プロトコルＣＨＡＰであり、詳細はＲＦＣ１９９４ “ＰＰＰ Ｃｈａｌｌｅｎｇｅ Ｈａｎｄｓｈａｋｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ’’に記述されている。

認証が完了したら、ＤＨＣＰ ｍｏｄｕｌｅ １４０２２がその設定に従いＩＰｖ６グローバルアドレス（のプレフィックス）やｄｅｆａｕｌｔ ｇａｔｅｗａｙのＩＰｖ６アドレス等をホスト１４０６に伝える。ＤＨＣＰ ｍｏｄｕｌｅ １４０２２は、ＩＳＰの管理者がその運用方針に従った設定を行なっている。

なお、図１４では説明を簡単にするため、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ とＤＨＣＰサーバーとＡｕｔｈｅｎｔｉｃａｔｉｏｎ サーバーをそれぞれｄｅｆａｕｌｔ ｇａｔｅｗａｙ ｍｏｄｕｌｅ １４０２１、ＤＨＣＰ ｍｏｄｕｌｅ １４０２２、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｍｏｄｕｌｅ １４０２３としてＰＰＰ ｐｅｅｒ内部に存在するものとしているが、実際にはリンク１４０７上にそれぞれ異なるノードとして存在することもある。いずれの実現形態にせよ、それらのｍｏｄｕｌｅあるいはノードはＩＳＰの管理者の元で安全に運用されていれば、構わないので、以下では、図１４の形態でホストとＰＰＰ ｐｅｅｒの間のＰＰＰリンクが確立したものとして説明する。

ホスト１４０６は、ＤＨＣＰ ｍｏｄｕｌｅ １４０２２からＩＰｖ６グローバルアドレス（のプレフィックス）やｄｅｆａｕｌｔ ｇａｔｅｗａｙのＩＰｖ６アドレス等を受け取ったならば、ＩＰｖ６グローバルアドレス（のプレフィックスと自分の（ＲＦＣ３０４１等の方法で生成した）ランダムなインターフェイスＩＤとを組み合わせてランダムなＩＰｖ６グローバルアドレスを生成し、それがリンクにおいて重複していないことを確認してから それをインターフェイス３０１に割当て、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ のＩＰｖ６アドレスを記憶する。

以上の動作により、ホスト１４０６は使い捨てＩＰｖ６アドレスを使ってインターネットの任意の相手と通信できる。

次に、本発明の実施の形態を説明する。上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。

以下では、匿名公開鍵証明書方式を、図１４の環境に適用した形態を説明する。Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８がＣＡ、ホスト１４０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。以下では、ランダムなＩＰｖ６アドレスを証明書の中に含める形態を説明するが、ランダムなＩＰｖ６アドレスを含めないことも可能である。

Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８は、前述の公開パラメータｐ、ｇ等を定め、自分の秘密鍵ｓ＿ｃａと公開鍵ｖ＿ｃａを定め、公開する。Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ１４０８はＰＰＰ ｐｅｅｒ １４０２を信用するものとする。つまり、ＰＰＰ ｐｅｅｒ １４０２の管理元、すなわちＩＳＰとの間で、問題が生じたときの責任について合意がなされており、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８とＰＰＰ ｐｅｅｒ １４０２との間では確実で安全な通信が行なえるようになっている。

ユーザｉがＩＳＰに加入を申請する際に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８が公開しているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＩＳＰに提出する。ＩＳＰの管理元（ＰＰＰ ｐｅｅｒ１４０２の管理元）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、ユーザ名に対応して公開鍵ｖ＿ｉが検索できるように、ＲＡＭ ３０５もしくはＨＤ３０６に登録する。公開パラメータや公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト１４０６で安全に利用可能になっているものとする。

以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１３に示す。図１３は、エンティティ（ユーザｉが用いるＩＰｖ６通信装置）をホスト１４０６、ＣＡをＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８とし、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８はＰＰＰｐｅｅｒ １４０２を信用し、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。

ＰＰＰ接続におけるデータリンク層の処理が終わった後、前述のユーザ名とパスワードに基づく認証プロトコルＣＨＡＰによる認証を行なう。

すなわち、ホスト１４０６はステップＳ１３０１でエンティティ名（ユーザ名）をインターフェイス３０１からＰＰＰ ｐｅｅｒ１４０２に送る。ステップＳ１３０２でエンティティ名（識別子）をインターフェイス３０１から受信すると、ＰＰＰ ｐｅｅｒ １４０２はＣＨＡＰ−ｃｈａｌｌｅｎｇｅを生成し、ステップＳ１３０３でそれをホスト１４０６にインターフェイス３０１から送る。

ホスト１４０６は、ステップ Ｓ１３０４でＣＨＡＰ−ｃｈａｌｌｅｎｇｅをインターフェイス３０１から受信すると、エンティティ名とパスワードとＣＨＡＰ−ｃｈａｌｌｅｎｇｅをハッシュ関数に入力して求めた結果の値ＣＨＡＰ−ｒｅｓｐｏｎｓｅをステップＳ１３０５でＰＰＰ ｐｅｅｒ １４０２にインターフェイス３０１から送る。

ステップＳ１３０６でＰＰＰ ｐｅｅｒ １４０２は、ＣＨＡＰ−ｒｅｓｐｏｎｓｅをインターフェイス３０１から受信し、ＣＨＡＰ−ｒｅｓｐｏｎｓｅの正当性を確認する。確認出来たならば認証は成功なので、その認証されたホスト１４０６に対してＩＰｖ６グローバルアドレス（のプレフィックス）やｄｅｆａｕｌｔ ｇａｔｅｗａｙのアドレスをステップＳ１３０７でインターフェイス３０１から伝える。

ホスト１４０６は、ステップＳ１３０８で、インターフェイス３０１から受信したＩＰｖ６グローバルアドレス（のプレフィックスとランダムなインターフェイスＩＤとからＩＰｖ６グローバルアドレスを生成し、それ）が重複していないことを確認してからそれをインターフェイス３０１に割当て、ｄｅｆａｕｌｔ ｇａｔｅｗａｙのアドレスも記憶する。次に匿名公開鍵証明書を要求するメッセージとしてＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎ をステップＳ１３０９でＰＰＰ ｐｅｅｒ １４０２にインターフェイス３０１から送る。

Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎは、第１の実施の形態と同様に、匿名公開鍵証明書を要求する旨とインターフェイスＩＤを含むデータであることをＰＰＰ ｐｅｅｒ １４０２が理解できる形式で生成される。内容は、エンティティ名（ユーザ名）とパスワードとシリアル番号から計算され、シリアル番号は、例えば、ホスト２０６のＩＰｖ６リンクローカルアドレスとｄｅｆａｕｌｔ ｇａｔｅｗａｙのＩＰｖ６リンクローカルアドレスとそのときの時刻の３つを連接して一つのデータにした値である。Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎには、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名（認証用ｓｉｇｎａｔｕｒｅ）が含まれる。

ＰＰＰ ｐｅｅｒ １４０２は、ステップＳ１３１０で、Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎをインターフェイス３０１から受信すると、図１のＳ１０３Ａと同様に、エンティティ名（ホスト（通信装置）２０６の識別子であるユーザ名）に対応する登録された公開鍵ｖ＿ｉをＲＡＭ ３０５もしくはＨＤ３０６から検索し、前述のように乱数ｒを生成して匿名公開鍵（ｇ’とｖ＿ｉ’）（＝（ｇ＾ｒ ｍｏｄ ｐ、（ｖ＿ｉ）＾（ｒ） ｍｏｄ ｐ））を生成し、ホスト１４０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’とｖ＿ｉ’）に対する認証用ｓｉｇｎａｔｕｒｅを生成する。そして、ホスト１４０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）と認証用ｓｉｇｎａｔｕｒｅからなる証明書要求メッセージをステップＳ１３１１でＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８にネットワーク・インターフェイス３０２から送る。

前述の確実で安全な通信によって受け取った場合は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８が、ＰＰＰ Ｐｅｅｒ １４０２からのデータをネットワーク・インターフェイス３０１から受け取った事実自体が正しい ＰＰＰ Ｐｅｅｒ １４０２に生成されたデータであることを証明する場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合もある。

いずれにせよ、図１のＳ１０５と同様に、ステップＳ１３１２で認証用ｓｉｇｎａｔｕｒｅの正当性を確認したＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８は、ホスト１４０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）と管理・属性情報Ｘに対するディジタル署名Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）を生成し、ホスト１４０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）と管理・属性情報Ｘとそれらに対するディジタル署名からなる匿名公開鍵証明書を生成する。そして、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８は、ステップＳ１３１３でネットワーク・インターフェイス３０１からＰＰＰ Ｐｅｅｒ １４０２にその匿名公開鍵証明書を送る。なお、管理・属性情報Ｘには、この匿名公開鍵証明書の有効期限などが含まれる。

ＰＰＰ Ｐｅｅｒ １４０２は、それをネットワーク・インターフェイス３０２から受け取り、ステップＳ１３１４でＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔすなわち匿名公開鍵証明書をインターフェイス３０１からホスト１４０６に送る。ホスト１４０６はネットワーク・インターフェイス３０１から受け取った匿名公開鍵証明書の正当性をステップＳ１３１５で確認する。

ここで、ホスト１４０６は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８の公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の正当性、すなわち、（ｇ’、ｖ＿ｉ’）とＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）の対応関係の正しさを確認する。例えば、ホスト１４０６は、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし｜は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。ホスト１４０６は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８の公開鍵ｖ＿ｃａを予め記憶している。匿名公開鍵証明書の管理・属性情報Ｘに公開鍵ｖ＿ｃａの公開鍵証明書が含まれている形態では、ホスト１４０６は、予め記憶している公開鍵ｖ＿ｃａが、匿名公開鍵証明書の管理・属性情報Ｘに含まれている公開鍵ｖ＿ｃａの公開鍵証明書中の公開鍵ｖ＿ｃａと一致することを確認してから、この公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。

以上のプロトコルにおいて、ステップＳ１３０５とＳ１３０９で送受されるデータを一つにまとめてステップＳ１３０５で送ることも可能である。図示しないが、その場合、ホスト１４０６はランダムなインターフェイスＩＤとＣＨＡＰ−ｒｅｓｐｏｎｃｅと Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎ（第１の実施例と同様）をステップＳ１３０５’でＰＰＰ ｐｅｅｒ１４０２に送る。

ステップＳ１３０６’で、ＰＰＰ ｐｅｅｒ １４０２は、ＣＨＡＰ−ｒｅｓｐｏｎｓｅの正当性を確認し、登録された公開鍵ｖ＿ｉを検索し、（ＩＰｖ６プレフィックスとインターフェイスＩＤとから）ホスト１４０６ に割当てるＩＰｖ６グローバルアドレス（を生成し、それ）とそのライフタイム（使用期限、例えば２４時間等）等を含めたデータを生成し、認証用ｓｉｇａｎｔｕｒｅと証明書要求メッセージを生成してステップＳ１３０７’でＣｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ１４０８に送る。

Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ １４０８はステップＳ１３０８’でステップＳ１３１２と同様の処理を行ない、ステップＳ１３０９’で匿名公開鍵証明書をＰＰＰ Ｐｅｅｒ １４０２に送る。ＰＰＰ Ｐｅｅｒ １４０２はステップＳ１３１０’でＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔをホスト１４０６に送る。ホスト１４０６は受け取った匿名公開鍵証明書の正当性をステップＳ１３１１’で確認する。

ホスト１４０６は、通信相手が変る度に、あるいは、セッションが変る度に、若しくは、通信パケット送信の度に、図１３の手順を実行し、Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ １４０８からの匿名公開鍵証明書を受け取る。すなわち、ホスト１４０６は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。ここで、公開鍵（ｇ’、ｖ＿ｉ’）は、同一のエンティティの公開鍵であるが、時間の経過に伴い変更される公開鍵である。

なお、以上の説明ではＰＰＰ Ｐｅｅｒ １４０２がＩＰｖ６プレフィックスをｈｏｓｔ １４０６に伝え、ｈｏｓｔ１４０６がＩＰｖ６プレフィックスとインターフェイスＩＤからＩＰｖ６アドレスを生成する場合を述べたが、ＰＰＰ Ｐｅｅｒ １４０２がＩＰｖ６アドレスをｈｏｓｔ１４０６に伝え、ｈｏｓｔ １４０６がそれを使う場合も同様のプロトコルで実現される。その場合、図３のステップＳ１３０７でＩＰｖ６プレフィックスの代わりにＩＰｖ６アドレスが送られる点とステップＳ１３０８でプレフィックスからＩＰｖ６アドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。

（第４の実施の形態）
第１の実施の形態、第２の実施の形態や第３の実施の形態で発行された使い捨てＩＰｖ６アドレスと使い捨て匿名公開鍵証明書を用いてＩＰｓｅｃ通信を行なう形態を説明する。

まず、秘密データやお互いのＩＰｖ６アドレス等のデータであるＳＡ（Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ）を安全に共有するプロトコルであるＩＫＥ（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ）における公開鍵暗号による暗号化の改訂モードによる認証方法を簡単に説明し、匿名公開鍵証明書を用いる方法を説明する。

ＩＫＥは二つのｐｈａｓｅからなり、Ｐｈａｓｅ １において安全な通信路を確立し、ｐｈａｓｅ ２では、ＩＰｓｅｃ等の通信で使用されるＳＡが前記安全な通信路上で合意される。以下では、Ｐｈａｓｅ １のみを説明する。ＩＫＥのＰｈａｓｅ １にはＭａｉｎ ｍｏｄｅとＡｇｇｒｅｓｓｉｖｅ ｍｏｄｅが存在するが、以下に説明するのは、ＲＦＣ２４０９“Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ（ＩＫＥ）’’のｐｐ．１３−１５の５．３ Ｐｈａｓｅ １ Ａｕｔｈｅｎｔｉｃａｔｅｄ ｗｉｔｈ ａ Ｒｅｖｉｓｅｄ ｍｏｄｅ ｏｆ Ｐｕｂｌｉｃ Ｋｅｙ ＥｎｃｒｙｐｔｉｏｎのＭａｉｎ ｍｏｄｅである。

ＩＫＥにおいて、通信する２エンティティはＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒと呼ばれる。Ｉｎｉｔｉａｔｏｒが通信を開始する。最初に、Ｉｎｉｔｉａｔｏｒが複数のＳＡ（秘密データやお互いのＩＰｖ６アドレス等のデータ）をＲｅｓｐｏｎｄｅｒに送り、Ｒｅｓｐｏｎｄｅｒが使って良いと判断した一つのＳＡをＩｎｉｔｉａｔｏｒに送ることで、ｐｈａｓｅ １用のＳＡを決定する。

Ｉｎｉｔｉａｔｏｒは、乱数（Ｎｏｎｃｅと呼ばれる）を生成し、Ｒｅｓｐｏｎｄｅｒの公開鍵で暗号化したデータをＲｅｓｐｏｎｄｅｒに送る。Ｒｅｓｐｏｎｄｅｒは乱数を生成し、Ｉｎｉｔｉａｔｏｒの公開鍵で暗号化したデータをＩｎｉｔｉａｔｏｒに送る。これにより、それぞれの生成したｎｏｎｃｅを共有できるので、他の通信で用いられる暗号の鍵を共有したｎｏｎｃｅから生成する。この詳細は、ＲＦＣ２４０９“Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ（ＩＫＥ）’’に記載されている。以上の説明から明らかなように、通信相手の公開鍵をＩＰｓｅｃ通信に先だって知る必要がある。

以下のような状況を考える。ある買い物サイトにユーザ２０６（図２）、１４０６（図１４）がアクセスする。このサイトは、インターネット２０１（図２）、１４０１（図１４）に接続されている（不図示）。このサイトは、図３と同様の構成を有し、インターフェイス３０１により、インターネット２０１、１４０１に接続される。なお、サイトの種類は、買い物サイトに限らない。ホスト２０６、１４０６は、この買い物サイトなどのサイトを通信相手とする通信を開始する前に、上述したプロトコルで、Ｉｐｖ６アドレス、及び、公開鍵を含む公開鍵証明書を得ておく。この形態において、上述した公開鍵証明書に基づき鍵交換・更新・変更プロトコルを実行して暗号・認証通信を行なう手順を行なう。

このとき、ユーザは買い物サイトのＩＰｖ６アドレスを（明示的か非明示的かは問わないが）知っている。実際にアクセスして、そこがユーザにとって正しいサイトであるときに、通信相手のＩＰｖ６アドレスを確認することで、ユーザは明示的にアドレスを知ることができる。通信している最中には、買い物サイトも通信相手２０６、１４０６のアドレスがわかる。以上の通信は使い捨てＩＰｖ６アドレスで行なえる。

本形態では、送受信者が確定した時点で、使い捨てＩＰｖ６アドレスは（更新せず）同一のアドレスを使う。更に、この時点で、サイトとユーザ２０６、１４０６は、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）をお互いに送り合う。ＩＰｖ６アドレスが使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）のＸの中に含まれているので、両者は、そのＩＰｖ６アドレスが実際に通信している相手のＩＰｖ６アドレスと一致するか否かを確認する。更に、両者は、使い捨て匿名公開鍵証明書の正当性を確認し、それが本当に通信相手の使い捨て匿名公開鍵証明書か否かを判断して、その中に含まれる公開鍵が本当に通信相手の公開鍵か否かを確認する。

すなわち、ユーザ２０６、１４０６は、使い捨て匿名公開鍵証明書を、インターフェイス３０１から、サイトに送信する。インターネット２０１、１４０１に接続されたサイトは、ユーザ２０６、１４０６からインターフェイス３０１を介して受信した使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれるＩＰｖ６アドレスが、ユーザ２０６、１４０６のＩＰｖ６アドレスと一致するか確認する。更に、サイトは、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９、１４０８の公開鍵ｖ＿ｃａを用いて、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する。ユーザ２０６、１４０６も、同様に、受信した公開鍵証明書に含まれるＩＰｖ６アドレスが、サイトのアドレスと一致するか確認するとともに、Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ ２０９、１４０８の公開鍵ｖ＿ｃａを用いて、公開鍵証明書の正当性を確認する。

使い捨て匿名公開鍵証明書の正当性は、次のように確認する。ホスト２０６、１４０６は、ＣＡ（商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等）２０９（図２）、１４０８（図１４）の公開鍵ｖ＿ｃａを用いて、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の正当性、すなわち、（ｇ’、ｖ＿ｉ’）とＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）の対応関係の正しさを確認する。例えば、ホスト２０６、１４０６は、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし｜は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。ホスト２０６、１４０６は、ＣＡ（商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等）２０９（図２）、１４０８（図１４）の広く知られている公開鍵ｖ＿ｃａを、予め記憶している。匿名公開鍵証明書の管理・属性情報Ｘに公開鍵ｖ＿ｃａの公開鍵証明書が含まれている形態では、ホスト２０６、１４０６は、予め記憶している公開鍵ｖ＿ｃａが、匿名公開鍵証明書の管理・属性情報Ｘに含まれている公開鍵ｖ＿ｃａの公開鍵証明書中の公開鍵ｖ＿ｃａと一致することを確認してから、この公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。

ホスト２０６、１４０６は、通信相手が変る度に（すなわち、新たに、サイトに接続する度に）、若しくは、セッションが変る毎に、図１１、図１３のプロトコルを実行し、使用するＩＰｖ６アドレス及び公開鍵ｇ’とｖ＿ｉ’を更新・変更する。なお、公開鍵ｇ’とｖ＿ｉ’は、通信パケットの送信毎に、更新・変更してもよい。すなわち、ホスト２０６、１４０６は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。

以上により、使い捨てＩＰｖ６アドレスとそれを含む使い捨て匿名公開鍵証明書を用いて、ＩＰｖ６アドレスで定義される通信相手の公開鍵を確実に入手できる。このようにして交換した公開鍵を用いて前述のＩＫＥのｐｈａｓｅ １のＭａｉｎ ｍｏｄｅを行ない、そのＩＰｖ６アドレスを持つ通信相手とのＩＰｓｅｃ通信を行なう。

すなわち、前述のサイトは、ユーザ２０６、１４０６から受信した使い捨て匿名公開鍵証明書が正当な使い捨て公開鍵証明書であることを確認すると、その使い捨て公開鍵証明書の公開鍵（ｇ’、ｖ＿ｉ’）を用いて、インターフェイス３０１により、前述のＩＫＥのｐｈａｓｅ １のＭａｉｎ ｍｏｄｅ を行ない、そのＩＰｖ６アドレスを持つユーザ２０６、１４０６とのＩＰｓｅｃ通信を行なう。ユーザ２０６、１４０６も同様に、インターフェイス３０１により、前述のＩＫＥのｐｈａｓｅ １のＭａｉｎ ｍｏｄｅを行ない、そのＩＰｖ６アドレスを持つサイトとのＩＰｓｅｃ通信を行なう。

従って、課題で述べたような通信相手のなりすましを防ぐことができる。

第１の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（登録商標）ＬＡＮの場合）図である。 イーサネット（登録商標）ＬＡＮの模式図である。 ノードの構成図である。 イーサネット（登録商標）のＭＡＣアドレスの構成図である。 インターフェイスＩＤの構成図である。 ａ ｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓの構成図である。 あるｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓの構成図である。 ホストがＤＡＤを終えるまでの動作を説明するフローチャート図である。 ホストがアドレス自動設定を終えるまでの動作を説明するフローチャート図である。 ホストがＤＨＣＰでアドレスを取得するまでの動作フローチャート図である。 ホストがアドレス自動設定を行ない、匿名公開鍵証明書を受け取るまでの動作フローチャート図である。 ホストがＤＨＣＰでアドレスと匿名公開鍵証明書を受け取るまでの動作フローチャート図である。 第３の実施の形態における匿名公開鍵証明書発行プロトコル（ＰＰＰの場合）図である。 ダイヤルアップ／ＡＤＳＬ接続の模式図である。 第２の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（登録商標）ＬＡＮの場合）図である。 ホストが証明書を取得するまでの動作フローチャート図である。

符号の説明

３００ ノード
３０１ ネットワーク・インターフェイス
３０２ ネットワーク・インターフェイス
３０６ ＨＤ（ハードディスク）
３０８ キーボード／ポインティングデバイスのインターフェイス
３０９ モニターのインターフェイス
３１０ バス
１４０２ ＩＳＰのＰＰＰ ｐｅｅｒ
１４０４ ＰＳＴＮ（Ｐｕｂｌｉｃ Ｓｗｉｔｃｈｅｄ Ｔｅｌｅｐｈｏ ｎｅ Ｎｅｔｗｏｒｋ）
１４０７ ＩＳＰとインターネットとの間のリンク

Claims (12)

1. ネットワークを介して通信装置と通信する通信手段と、
   公開のパラメータから匿名公開鍵を生成する生成手段と、
   前記通信装置から匿名公開鍵証明書を要求されると、前記生成手段により生成された匿名公開鍵を公開鍵証明書発行装置に送信する送信手段とを有し、
   前記匿名公開鍵は、前記通信装置が、前記通信装置の秘密鍵と共に前記匿名公開鍵を利用できるように生成されることを特徴とする公開鍵生成装置。
2. 前記通信手段は、前記公開鍵証明書発行装置から発行された匿名公開鍵証明書を、前記通信装置に送信することを特徴とする請求項１の公開鍵生成装置。
3. 前記生成手段は、乱数を生成し、前記公開のパラメータをｇ、前記乱数をｒ、第２の公開のパラメータをｐとした場合に、ｇをｒ乗した値をｐで割った場合の剰余を、前記匿名公開鍵として生成することを特徴とする請求項１の公開鍵生成装置。
4. 前記送信手段は、前記通信装置のアドレス情報を前記公開鍵証明書発行装置に送信する請求項１の公開鍵生成装置。
5. 公開のパラメータから匿名公開鍵を生成し、
   前記通信装置が発生した匿名公開鍵証明書要求メッセージを、ネットワークを介して受信し、
   前記匿名公開鍵証明書要求メッセージに応じて、前記生成された匿名公開鍵を公開鍵証明書発行装置に送信し、
   前記匿名公開鍵は、前記通信装置が、前記通信装置の秘密鍵と共に前記匿名公開鍵を利用できるように生成されることを特徴とする公開鍵生成方法。
6. 前記公開鍵証明書発行装置から発行された匿名公開鍵証明書を、前記通信装置に送信する送信ステップを更に有することを特徴とする請求項５の公開鍵生成方法。
7. 前記生成ステップでは、乱数を生成し、前記公開のパラメータをｇ、前記乱数をｒ、第２の公開のパラメータをｐとした場合に、ｇをｒ乗した値をｐで割った場合の剰余を、前記匿名公開鍵として生成することを特徴とする請求項５の公開鍵生成方法。
8. 前記送信ステップでは、前記通信装置のアドレス情報を前記公開鍵証明書発行装置に送信する請求項５の公開鍵生成方法。
9. 公開鍵生成装置は、公開のパラメータから匿名公開鍵を生成し、前記通信装置が発生した匿名公開鍵証明書要求メッセージを、ネットワークを介して受信し、前記匿名公開鍵証明書要求メッセージに応じて、前記生成された匿名公開鍵を公開鍵証明書発行装置に送信し、
   前記公開鍵証明書発行装置は、前記公開鍵生成装置から受信した匿名公開鍵の証明書を発行し、
   前記匿名公開鍵は、前記通信装置が、前記通信装置の秘密鍵と共に前記匿名公開鍵を利用できるように生成されることを特徴とする公開鍵証明書発行方法。
10. 前記公開鍵生成装置は、前記公開鍵証明書発行装置から発行された匿名公開鍵証明書を、前記通信装置に送信することを特徴とする請求項９の公開鍵証明書発行方法。
11. 前記公開鍵生成装置は、乱数を生成し、前記公開のパラメータをｇ、前記乱数をｒ、第２の公開のパラメータをｐとした場合に、ｇをｒ乗した値をｐで割った場合の剰余を、前記匿名公開鍵として生成することを特徴とする請求項９の公開鍵証明書発行方法。
12. 前記公開鍵生成装置は、前記通信装置のアドレス情報を前記公開鍵証明書発行装置に送信し、前記公開鍵証明書発行装置は、前記通信装置のアドレス情報を含む匿名公開鍵証明書を発行することを特徴とする請求項９の公開鍵証明書発行方法。

Images