JP2004007512A

JP2004007512A - Public key certificate providing device

Info

Publication number: JP2004007512A
Application number: JP2003085335A
Authority: JP
Inventors: Kazuomi Oishi; 大石　和臣
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2002-04-17
Filing date: 2003-03-26
Publication date: 2004-01-08
Anticipated expiration: 2023-03-26
Also published as: JP3782788B2

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method for surely and efficiently issuing a disposable anonymous public key certificate to an IPv6 apparatus capable of IPv6 communication. <P>SOLUTION: A host 206 makes communication with a gateway 202 or a DHCP server 203 to determine an IPv6 address and receives a public key certificate from the gateway 202 or the DHCP server 203, and also transmits the public key certificate including the IPv6 address to a communication opposite party. The host 206 receives a new public key certificate from the gateway 202 or the DHCP server 203 to realize privacy protection and transmits the public key certificate including the IPv6 address to the communication opposite party to prevent impersonation. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、公開鍵証明書を提供する提供装置に関する。
【０００２】
【従来の技術】
ＩＰｖ６の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けディジタルカメラである。
【０００３】
ＩＰｖ６に対応するパーソナル・コンピュータやワークステーションの場合、ネットワークとの接続のインターフェイスには通常はイーサネット（Ｒ）が用いられ、それが持つ　ＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）を元にしてＩＰｖ６アドレスが構成されるようになっている。
【０００４】
ＩＰｖ６アドレスには、後述するようにリンクローカルアドレス、サイトローカルアドレスと（集約可能）、グローバルアドレスの３種類が存在する。
【０００５】
それらの詳細や構成方法などのアドレス体系は、ＲＦＣ　２３７３　｀｀ＩＰ　Ｖｅｒｓｉｏｎ　６　Ａｄｄｒｅｓｓｓｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ、’’　ＲＦＣ　２３７４　｀｀Ａｎ　ＩＰｖ６　Ａｇｇｒｅｇａｔａｂａｌｅ　Ｇｌｏｂａｌ　Ｕｎｉｃａｓｔ　Ａｄｄｒｅｓｓ　Ｆｏｒｍａｔ、’’　ＲＦＣ　２３７５　｀｀ＩＰｖ６　Ｍｕｌｔｉｃａｓｔ　Ａｄｄｒｅｓｓ　Ａｓｓｉｇｎｍｅｎｔ、’’　ＲＦＣ　２４５０　｀｀Ｐｒｏｐｏｓｅｄ　ＴＬＡ　ａｎｄ　ＮＬＡ　Ａｓｓｉｇｎｍｅｎｔ　Ｒｕｌｅ、’’　ＲＦＣ　２４６１　｀｀Ｎｅｉｇｈｂｏｒ　Ｄｉｓｃｏｖｅｒｙ　ｆｏｒ　ＩＰ　Ｖｅｒｓｉｏｎ　６　（ＩＰｖ６）、’’　ＲＦＣ　２４６２　｀｀ＩＰｖ６　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、’’　等に記述されている。
【０００６】
ところで、ＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）のようにハードウェアに１対１に対応する情報を固定的に用いると、それが装置もしくはその装置のユーザと１対１に対応する情報とみなされ、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。
【０００７】
この課題に対しては、ランダムなＩＰｖ６アドレス（正確にはインターフェイスＩＤ）を生成する方法が、ＲＦＣ３０４１　｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒ　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’　等において提案されている。
【０００８】
生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算／生成し、ユニークなランダムな値を定めるプロトコル（の拡張）も記述されている。
【０００９】
上記のような解決方法を利用して生成したランダムなＩＰｖ６アドレスを装置が使う場合に、ＩＰｓｅｃを用いて暗号通信を行なうことを考える。
【００１０】
ＩＰｓｅｃは、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであり、通信に際して秘密データやお互いのＩＰｖ６アドレス等を安全に共有する必要がある。秘密データやお互いのＩＰｖ６アドレス等のデータはＳＡ（Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）と呼ばれる。
【００１１】
ＳＡを安全に共有するプロトコルはＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）と呼ばれ、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ　（ＩＫＥ）’’において規定されている。ここで、ＳＡを安全に共有するという意味は、意図する相手のみと確実にＳＡを共有するという意味であり、相手を確実に認証することを必要とする。ＩＫＥには、１）　ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙを用いる方法、２）　ディジタル署名を用いる方法、３）公開鍵暗号による暗号化による方法、４）公開鍵暗号による暗号化の改訂モードによる方法、の計４つの認証方法が規定されている。
【００１２】
ところが、プライバシ保護（身元を明らかにする情報を与えない）を実現する状況を考えると、例えばユーザが買い物サイトとのＩＰｓｅｃ通信を行なうような場合は、買い物サイトの立場で考えれば、あらかじめ定まっていない不特定多数の通信相手と　ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ　をＩＰｓｅｃ通信に先だって共有することは現実には不可能であるから、ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ　を用いる方法は使えない。
【００１３】
その他の方法の場合は、ディジタル署名あるいは公開鍵暗号の使用に必要な情報（多くの場合は公開鍵）を確実に入手可能ならば、不特定多数の通信相手同士でＩＫＥを実行することが可能である。そのために最も有望視されているのが、ＰＫＩ（Ｐｕｂｌｉｃ−ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）と呼ばれる環境・仕組みであり、その中で中心的な役割を果たすのが、公開鍵証明書である。
【００１４】
公開鍵証明書は、信頼できる第三者がエンティティ（通信をする主体、計算機や人間）とそのエンティティの公開鍵の対応関係を確認し、それを保証するために、エンティティのＩＤ情報等と公開鍵の組みに対して信頼できる第三者が発行するディジタル署名である。信頼できる第三者はＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）と呼ばれ、ＣＡのディジタル署名の正当性を確認するための公開鍵は、広く一般に知られている。
【００１５】
しかし、現在運用されている公開鍵証明書の中には、その持ち主（Ｓｕｂｊｅｃｔ）を示すＩＤ情報、例えば、ＦＱＤＮ（Ｆｕｌｌｙ　Ｑｕａｌｉｆｉｅｄ　Ｄｏｍａｉｎ　Ｎａｍｅ）が含まれるので、そのままではプライバシ保護を実現できない。
【００１６】
公開鍵証明書の中にその持ち主のＩＤ情報を含めない方法も考えられ、匿名公開鍵証明書と呼ばれる。
【００１７】
しかし、匿名公開鍵証明書にも上述のＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）と同じ課題が存在する。つまり、同一の匿名公開鍵証明書を使い続ける限り、複数の（公開鍵証明書に基づくＩＰｓｅｃ等の）通信を結び付けることは可能であり、もしも一度でも匿名公開鍵証明書とその持ち主の対応関係が明らかになったときは、プライバシが侵害されることにつながるので、やはりプライバシ保護の程度は弱い。
【００１８】
以上の課題に対して、例えば、異なる通信相手と通信する際に異なるＩＰｖ６アドレスおよび匿名公開鍵証明書を使うことが可能ならば、強いプライバシ保護が実現できると考えられる。これらを使い捨てＩＰｖ６アドレスおよび使い捨て匿名公開鍵証明書と呼ぶ。使い捨てる間隔としては、通信相手が変る度に新しい使い捨てＩＰｖ６アドレスを用いる、あるいはパケット毎に変えるなど、いくつかが考えられる。
【００１９】
【発明が解決しようとする課題】
しかしながら、使い捨てＩＰｖ６アドレスに関しては、前述のＲＦＣ３０４１｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒ　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’　が知られているが、ＩＰｖ６通信が可能な装置（以下では、ＩＰｖ６対応装置と表す）に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。
【００２０】
さらに、次の課題も存在する。すなわち、通信相手のＩＤ情報がわからない場合、通信相手の識別はＩＰアドレスでのみ行なうことになる。しかし、例えばイーサネット（Ｒ）のＬＡＮ上で送受されるパケットはそのＬＡＮ上のノード全てがアクセスできるので、本来はエンティティＡとエンティティＢが通信をするはずのところを、Ａと同じＬＡＮ上の悪意を持ったＣがＡになりすますこともありうる。つまり、ＡとＢの間で使い捨て匿名公開鍵証明書に基づくＩＰｓｅｃ通信を行なうために、Ａの公開鍵証明書がＢに送られる際に、Ａの公開鍵証明書をＣのものとすり替えることでＣはＡに成りすますことができてしまう。
【００２１】
ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバーやルーターに対してＤｏＳ（Ｄｅｎｉａｌ　ｏｆ　Ｓｅｒｖｉｃｅｓ）攻撃を加え、その間に偽のＤＮＳサーバーやルーターが偽の情報を与えるようにすれば、ＬＡＮに限定されないより広域な範囲でのなりすましも可能となる。通信相手のＩＤが判明していれば、それを確認することで対処できたが、上記に示したような匿名性の高い状況において、この種の攻撃を防ぐ方法は今まで知られていない。
【００２２】
本発明の他の目的は、ＩＰｖ６対応装置が用いるＩＰｖ６アドレスの一意性を公開鍵証明書発行者が容易に確認することを可能とし、その上で公開鍵証明書を発行できるようにすることにある。
【００２３】
本発明の他の目的は、ＩＰｖ６アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することにある。
【００２４】
本発明の他の目的は、ＩＰｖ６アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を利用して、ＩＫＥ及びＩＰｓｅｃ通信を行なうことにある。
【００２５】
本発明の他の目的は、ランダムなＩＰｖ６アドレスを含む、毎回異なる匿名公開鍵証明書を使うＩＰｓｅｃ通信が効率的に実現可能とし、強力なプライバシ保護を実現し、かつなりすましを防ぐことができるようにすることにある。
【００２６】
【課題を解決するための手段】
上記課題を解決するために、本出願に関わる発明は、ＩＰｖ６対応装置が位置するローカルリンク内に存在するＩＰｖ６対応装置を公開鍵証明書発行者として運用することを特徴とする。
【００２７】
【発明の実施の形態】
（第１の実施の形態）
本実施の形態では、ホストがイーサネット（Ｒ）のＬＡＮ経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本実施の形態を説明する。
【００２８】
図２は、本発明が適用される接続環境（ホストがイーサネット（Ｒ）のＬＡＮ経由でインターネットと接続する環境）を模式的に示したものである。
【００２９】
図２は、ＬＡＮに接続されたホスト２０４、２０５、２０６が　ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ゲートウェイ）２０２経由でインターネット２０１にアクセスする環境を示す。本実施の形態では、各ホストはリンク２０７で接続するものとし、リンク２０７は具体的にはイーサネット（Ｒ）であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、ＩＰ層の下側に接する。リンクにはイーサネット（Ｒ）の他に、ＰＰＰリンク、Ｘ．２５、フレームリレー、ＡＴＭネットワークがある。
【００３０】
リンクに接続されたＩＰｖ６対応装置をノードと呼ぶ。
【００３１】
ノードの内部構成の典型例を図３に示す。
【００３２】
ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノード３００は、ネットワーク・インターフェイス３０１、３０２、ＣＰＵ３０３、ＲＯＭ３０４、ＲＡＭ３０５、ＨＤ（ハードディスク）３０６、電源３０７、キーボード／ポインティングデバイスのインターフェイス３０８、モニターのインターフェイス３０９、バス３１０等を有する計算機である。
【００３３】
ルーターは複数のネットワーク・インターフェイス３０１、３０２を持つのに対し、ホストは多くの場合は一つのネットワーク・インターフェイス３０１を持つ。ホスト２０４、２０５、２０６は、ネットワーク・インターフェイス３０１により、リンク２０７を介して、リンク２０７に接続された他のノード、あるいは、更に、ゲートウェイ２０２を介して、インターネット２０１上のサイトと通信する。ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は、ネットワーク・インターフェイス３０１により、リンク２０７に接続された他のノードと通信すると共に、ネットワーク・インターフェイス３０２により、インターネット２０１を介して、通信する。ノードによってはＨＤを持たないものもある。
【００３４】
なお以下の処理内容（手順）は、装置もしくはプログラムとして実現され、その装置を有するノードが実行、もしくはそのプログラムがＲＯＭ　３０４もしくはＨＤ　３０６に格納されたノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをコンピュータであるＣＰＵ　３０３が読み込み、必要に応じてＲＡＭ　３０５を計算のための空間として利用しながらバス３１０を介してインターフェイス３０１にアドレスを割当てる、というような動作を行なう。
【００３５】
ここでは、ノード３００がアドレスをインターフェイスに割当てる、というように手順の本質を説明する。
【００３６】
本実施の形態におけるイーサネット（Ｒ）ＬＡＮ環境で各ホストがＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２のアドレスを取得するプロトコルの仕組みを簡単に説明し、その次に本発明を適用した具体的な実施の形態を説明する。
【００３７】
図２のリンク２０７に接続されたノード３００が、電源を入れられたあるいはリブートされた場合に行なう動作のフローチャートを図８に示す。この動作はＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）と呼ばれる。以下では図８の流れに沿って、ノード３００がＤＡＤを終えるまでの処理内容を説明する。
【００３８】
ステップＳ８０１でノード３００が電源を入れられたあるいはリブートされた後、まずインターフェイス３０１に割当てられているイーサネット（Ｒ）の　ＭＡＣ　ａｄｄｒｅｓｓ（ＭＡＣアドレス）（図４参照）からインターフェイスＩＤ（図５参照）を作成し、それをｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ（図６参照）とする（ステップＳ８０２）。
【００３９】
次に、そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓがリンク上で一意かどうかを判断するために、ノード（ホスト）３００は以下の処理を行なう。
【００４０】
最初に、インターフェイス３０１の初期設定をする。すなわち、インターフェイス３０１に、ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ（ＦＦ０２：：１）とそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　を割当てる（図７参照）。この結果、そのインターフェイス３０１は、ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ宛のパケットあるいはそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　宛のパケットを見つけたときはそれを自分のインターフェイス宛のパケットとして受け取る。
【００４１】
前者（ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ）を割当てることによって、既にそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを使っている他のノードからのデータを受信することが可能になる。また、後者（そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ）を割当てることによって、同じｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを同時に使おうとしている他のノードの存在を検出することが可能になる。
【００４２】
あるｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　とは、ＲＦＣ２４６１のｐａｇｅ　９１に定義されているように、ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓの下位２４ビットをプレフィックスＦＦ０２：０：０：０：０：１：ＦＦ００：：／１０４に付加したデータであり、ｌｉｎｋ−ｌｏｃａｌ　ｓｃｏｐｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　である。図６と図７にそれらの関係を示す。以上のアドレス割当てが図８のステップＳ８０３である。
【００４３】
次に　Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　を作る。Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　の　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓ（ターゲット　アドレス）には判断対象のｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを、ＩＰ　Ｓｏｕｒｃｅ（送信元アドレス）には　ｕｎｓｐｅｃｉｆｉｅｄ　ａｄｄｒｅｓｓ（１２８ビット全てが０）を、ＩＰ　ｄｅｓｔｉｎａｔｉｏｎ（宛先アドレス）には判断対象のｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓを設定する。
【００４４】
この　Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　をＲｅｔｒａｎｓＴｉｍｅｒミリセカンド間隔で、　ＤｕｐＡｄｄｒＤｅｔｅｃｔＴｒａｎｓｍｉｔｓ個イーサネット（Ｒ）（リンク）２０７に送出する。図８のステップＳ８０４がこの処理である。
【００４５】
Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取ったノードは、その送信元アドレスが　ｕｎｓｐｅｃｉｆｉｅｄ　ａｄｄｒｅｓｓ　ならば、その　ｍｅｓｓａｇｅ　がＤＡＤを行っているノードからのデータであると判断する。
【００４６】
同時に複数のノードが同じアドレスを対象としてＤＡＤをしている場合、そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　を割当てられた複数のノードが、同じアドレスを　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓに含む複数のＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅｓを受け取る（自分が送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅと、同時にそのアドレスを対象としてＤＡＤをしている他のノードが送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取る）ので、重複していることがわかる。その場合にはどのノードもそのアドレスは使わない。
【００４７】
なお、受け取ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　が、自分が送ったもの（マルチキャストのパケットをループバックしているため）であるならば、他にそれを使っているあるいは使おうとしているノードが存在することを示さない。自分が送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅに加えて、同じアドレスを　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓに含むＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅｓを受け取った場合に、同時に複数のノードが同じアドレスを対象としてＤＡＤをしていると判断する。
【００４８】
一方、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取ったノードが、その　ｍｅｓｓａｇｅ　の　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓに含まれるアドレスを既に使っていれば、Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓ（ターゲット　アドレス）にそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓが設定されたａ　ｍｕｌｔｉｃａｓｔ　Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　をａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ宛に返す。従って、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを送ったノードが　ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ宛のａ　ｍｕｌｔｉｃａｓｔ　Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取り、その　ｔａｒｇｅｔ　ａｄｄｒｅｓｓ　が　（判断対象の）　ｔｅｎｔａｔｉｖｅ　ａｄｄｒｅｓｓ　である場合（図８のＳ８０５ステップの「はい」の場合）は判断対象の　ｔｅｎｔａｔｉｖｅ　ａｄｄｒｅｓｓ　が唯一ではない（つまり、重複している）ことがわかる。
【００４９】
以上のＤＡＤの結果、判断対象の　ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　がリンク上で唯一であることが確認された（図８のＳ８０５ステップの「いいえ」の場合）ならば、そのアドレスをリンクローカルアドレスとしてインターフェイス３０１に割当てる。これが図８のステップＳ８０６である。以上でＤＡＤは終了する。
【００５０】
以上に説明した図８の動作は、図２のリンク２０７に接続されたノードであるｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２、ＤＨＣＰ　ｓｅｒｖｅｒ　２０３、ホスト２０４、ホスト２０５、ホスト２０６のそれぞれが、リンク２０７を収容するネットワーク・インターフェイス３０１について、実行することができる。
【００５１】
図２のホスト、例えばホスト２０６は、リンクローカルアドレスをインターフェイス３０１に割当てたら、次はサイトローカルアドレスやグローバルアドレスを決定するために必要な情報（Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔと呼ばれる）をｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２から入手することを試みる。この動作を図９に示す。
【００５２】
ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は通常はルーターと呼ばれるので以下ではルーター２０２と記す。ルーター２０２は管理者によって必要な設定が行われ、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を定期的にリンク２０７に送っている。ホスト２０６が　Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を早く入手したい場合は、ホスト２０６は　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　と呼ばれるデータをルーター２０２に送る。ホスト２０６はリンクローカルアドレスを割当てた直後にはルーター２０２の存在はわからないので、実際にはＲｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎはリンク２０７上のルーター全てに対するマルチキャストとして送られる。図９のステップＳ９０１はこの処理を示す。
【００５３】
Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　を受け取ったルーター２０２は　Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を送る。図９のステップＳ９０２の「はい」の場合に示すように、Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　のみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを受け取ったホスト２０６は、その受け取ったメッセージ中のプレフィックスの有効性（既にその装置によって使われていないこと等）を確認し、それ（ら）に適当なインターフェイスＩＤを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとし、インターフェイス３０１に割当てる。図９のステップＳ９０３がこの処理である。
【００５４】
図９のステップＳ９０２の「いいえ」の場合に示すように、ホスト２０６が　ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎのみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取らなかった場合は、次の二つの場合に分けられる。Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取った場合（ステップＳ９０４のはいの場合）と、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合（ステップＳ９０４のいいえの場合）である。後者の場合はｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、すなわちＤＨＣＰｖ６のみを実行する。これがステップＳ９０６であり、その詳細を図１０に示す。
【００５５】
ＤＨＣＰサーバー２０３は管理者によって必要な設定が行われている。具体的には、ノードとして自分のリンクローカルアドレスをネットワーク・インターフェイス３０１に割当ててあり、ＤＨＣＰサーバーとして振る舞うために必要なサイトローカルアドレスもしくはグローバルアドレスのためのプレフィックス等が設定されている。
【００５６】
図１０のステップＳ１００１で、ホスト２０６はＤＨＣＰサーバーにＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅを送る。ホスト２０６はどこにＤＨＣＰサーバー２０３が存在するのかわからないのでＤＨＣＰサーバー２０３に対するマルチキャストとしてリンク２０７に送出する。ホスト２０６の接続されているリンク２０７とは異なるリンク（図示せず）にＤＨＣＰサーバー２０３がいる場合には、ＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅは、実際はＤＨＣＰリレー（図示せず）によって中継されてＤＨＣＰサーバー２０３に届く。
【００５７】
ＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅを受け取ったＤＨＣＰサーバー２０３はそれに対する返答としてＤＨＣＰ　Ａｄｖｅｒｔｉｓｅ　Ｍｅｓｓａｇｅをホスト２０６に返す。これは（別リンクの場合はＤＨＣＰリレーによって中継されて）、ホスト２０６に届く。これがステップＳ１００２である。この時点でホスト２０６はＤＨＣＰサーバー２０３のアドレスがわかる。
【００５８】
次にステップＳ１００３でホスト２０６は　ＤＨＣＰ　Ｒｅｑｕｅｓｔ　ＭｅｓｓａｇｅをＤＨＣＰサーバー２０３に送る。ＤＨＣＰサーバー２０３はＤＨＣＰ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅを受け取ると、ＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅをホスト２０６に送る。
【００５９】
ステップＳ１００４でＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅを受け取ったホスト２０６は、それからサイトローカルアドレスもしくはグローバルアドレスを決めて、そのアドレスの中のインターフェイスＩＤが重複しているか否かを確認するために、ＤＡＤ処理に必要な処理を行なう。つまり、ステップＳ８０３と同様に、インターフェイス３０１にマルチキャストアドレス等を設定する。これがステップＳ１００５である。
【００６０】
次に、ステップＳ８０４と同様のＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅ　をステップＳ１００６で送り、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取るかどうかをステップＳ１００７で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをＤＨＣＰサーバー２０３から受け取るためにステップＳ１００３に戻り、同じ処理を繰り返す。
【００６１】
ホスト２０６は、図１０のステップＳ１００７でＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取らなかった場合は、そのアドレスは重複していないので、ＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅから決めたサイトローカルアドレスもしくはグローバルアドレスをステップＳ１００８でインターフェイス３０１に割当てる。
【００６２】
以上で図９のステップＳ９０６が終わる。ステップＳ９０４でＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合はこれで正常終了する。
【００６３】
ステップＳ９０４でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを受け取った場合は、ステップＳ９０５でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を行なう。処理内容はステップＳ９０３とＳ９０６と同じである。
【００６４】
以上のようにして、イーサネット（Ｒ）２０７をインターフェイスとして持つホスト２０６はｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　とｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　（ＤＨＣＰｖ６）を任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、グローバルアドレス、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ等を自動設定することができる。
【００６５】
以上のプロトコルにおいて、インターフェイスＩＤにランダムな値を用いて、その値を対象にしてＤＡＤを行ない、リンク２０７における一意性を確認することにより、ゲートウェイ２０２あるいはＤＨＣＰ　サーバー２０３から得たグローバルアドレスのプレフィックスと組み合わせて使い捨てのＩＰｖ６グローバルアドレスを利用することができる。詳細は、ＲＦＣ３０４１　｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒ　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’に記述されている。
【００６６】
次に本発明の実施の形態を説明する。上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。最初に、匿名公開鍵証明書の例を説明し、次にそれを効率的に発行するためのプロトコルを説明する。
【００６７】
匿名公開鍵証明書は、学術的にはＫａｚｕｏｍｉ　Ｏｉｓｈｉ、　Ｍａｓａｈｉｒｏ　Ｍａｍｂｏ、　Ｅｉｊｉ　Ｏｋａｍｏｔｏ、　｀｀Ａｎｏｎｙｍｏｕｓ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｃｅｒｔｉｆｉｃａｔｅｓ　ａｎｄ　ｔｈｅｉｒ　Ａｐｐｌｉｃａｔｉｏｎｓ　’’　ＩＥＩＣＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｆｕｎｄａｍｅｎｔａｌｓ　ｏｆ　Ｅｌｅｃｔｒｏｎｉｃｓ、　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ａｎｄ　Ｃｏｍｐｕｔｅｒ　Ｓｃｉｅｎｃｅｓ、　Ｅ８１−Ａ、　１、　ｐｐ．　５６−−６４、　１９９８においてその概念と具体的な実現方法が提案されており、その基本的な実現方法はＵＳＡの特許６、１５４、８４１としても開示されている。これらの方式では、証明書のユーザの匿名性は計算量的に保たれていた。より強力な匿名性を提供する方式として、情報量的な匿名性を有する匿名公開鍵証明書の実現方法がＫａｚｕｏｍｉ　Ｏｉｓｈｉ、　｀｀Ｕｎｃｏｎｄｉｔｉｏｎａｌｌｙ　ａｎｏｎｙｍｏｕｓ　ｐｕｂｌｉｃ　ｋｅｙ　ｃｅｒｔｉｆｉｃａｔｅｓ、’’　Ｔｈｅ　２０００　Ｓｙｍｐｏｓｉｕｍ　ｏｎ　Ｃｒｙｐｔｏｇｒａｐｈｙ　ａｎｄ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｃｕｒｉｔｙ、　ＳＣＩＳ２０００−Ｃ３２、　２０００において開示されている。
【００６８】
本発明においては、前述の論文Ｋａｚｕｏｍｉ　Ｏｉｓｈｉ、　Ｍａｓａｈｉｒｏ　Ｍａｍｂｏ、　Ｅｉｊｉ　Ｏｋａｍｏｔｏ、　｀｀Ａｎｏｎｙｍｏｕｓ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｃｅｒｔｉｆｉｃａｔｅｓ　ａｎｄ　ｔｈｅｉｒ　Ａｐｐｌｉｃａｔｉｏｎｓ　’’に記載されている任意の方式を利用することができる。効率が劣ることを許容できるならば、前記論文中のＳｃｈｅｍｅ　１、Ｓｃｈｅｍｅ　２、Ｓｃｈｅｍｅ　３を利用することも可能であり、それらも本発明に含まれる。本実施の形態では計算量的な匿名性を有する匿名公開鍵証明書方式を用いる形態を取り上げる。詳細は前述の文献を参照するものとし、説明の都合上必要な記号等を定義・導入してから本実施の形態のプロトコルを説明する。
【００６９】
匿名公開鍵証明書を発行するエンティティＣＡは、共通のパラメータとして大きな素数ｐとｑを定める。ｑはｐ−１を割りきる。オーダーｑの生成元ｇとハッシュ関数Ｈを定める。秘密の乱数ｓ＿ｃａ（１以上ｑ以下）を生成し、ｖ＿ｃａ＝ｇ＾（ｓ＿ｃａ）　ｍｏｄ　ｐを計算する。ここで、Ａ　＝　（Ｂ）＾（Ｃ）　ｍｏｄ　Ｄは、整数Ａ、Ｂ、Ｃ、Ｄに対して、ＢをＣ乗した値をＤで割り、その剰余をＡとする計算を表す。エンティティＣＡはｐとｑとｇとＨとｖ＿ｃａを公開する。一方、匿名公開鍵証明書を利用するエンティティｉは、秘密の乱数ｓ＿ｉ（１以上ｑ以下）を生成し、ｖ＿ｉ＝ｇ＾（ｓ＿ｉ）　ｍｏｄ　ｐを計算する。
【００７０】
ｓ＿ｃａやｓ＿ｉを秘密鍵、ｖ＿ｃａやｖ＿ｉ（および公開のパラメータ）を公開鍵と呼び、秘密鍵は自分以外の誰にも知られないように管理する。
【００７１】
エンティティｉは、匿名公開鍵証明書を利用開始する際に、自分のエンティティ名（ユーザ名）とパスワード、公開鍵ｖ＿ｉをエンティティＣＡに登録する。エンティティＣＡは、必要に応じてエンティティｉの身元を物理的手段等で確認し、提示されたエンティティ名（ユーザ名）とパスワード、公開鍵ｖ＿ｉを記憶する。
【００７２】
匿名公開鍵証明書を発行する際、エンティティ　ＣＡは、乱数ｒ（１以上ｑ以下）を生成し、（ｇ’、ｖ＿ｉ’）＝（ｇ＾ｒ　ｍｏｄ　ｐ、　（ｖ＿ｉ）＾（ｒ）　ｍｏｄ　ｐ）を計算する。上述の公開のパラメータやこの匿名公開鍵証明書の有効期限、及び、公開鍵ｖ＿ｃａに対する公開鍵証明書（後述）等の証明書の管理・属性情報をＸとし、（ｇ’、ｖ＿ｉ’）とＸを含むメッセージ（のハッシュ値）に対してディジタル署名を生成する。離散対数問題に基づくディジタル署名方式、例えば、Ｓｃｈｎｏｒｒ署名方式を使うことができる。ここでは、秘密鍵ｓ＿ｃａを用いる。このディジタル署名をＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）と記す。
【００７３】
エンティティｉに対してエンティティＣＡが発行する匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））である。
【００７４】
匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の発行を受けたエンティティｉは、その中から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし　｜　は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。また、ｖ＿ｉ’＝（ｇ’）＾（ｓ＿ｉ）　ｍｏｄ　ｐも確認する。それらが正しいと確認できたならば、ｇ’とｖ＿ｉ’（と共通のパラメータｐ）を公開鍵、ｓ＿ｉを秘密鍵として離散対数問題に基づく公開鍵暗号やディジタル署名を利用できる。このように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含み、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ’とｖ＿ｉ’は、同一のエンティティｉの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【００７５】
匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝　（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））を受け取ったエンティティは、その中から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。それが正しいと確認できたならば、公開鍵であるｇ’とｖ＿ｉ’（と共通のパラメータｐ）を用いて離散対数問題に基づく公開鍵暗号の暗号化やディジタル署名の検証を行なう。
【００７６】
なお、公開鍵ｖ＿ｃａそのものの正当性の確認は、より上位もしくはより普及しているエンティティＣＡ、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に公開鍵ｖ＿ｃａを提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらえば、それを用いて確認できる。匿名公開鍵証明書の管理・属性情報をＸは、公開鍵ｖ＿ｃａに対する公開鍵証明書を含む。この公開鍵ｖ＿ｃａに対する公開鍵証明書を用いて、公開鍵ｖ＿ｃａそのものの正当性を確認することができる。これは、エンティティＣＡを階層的に構築することに相当し、順当なＰＫＩ（Ｐｕｂｌｉｃ−ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）を構成することができる。
【００７７】
なお、上記の説明では乗法群（ｍｏｄ　ｐ）上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能であり、その場合は乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。
【００７８】
以上の匿名公開鍵証明書方式を、図２の環境に適用する場合を説明する。
【００７９】
ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２もしくはＤＨＣＰサーバー　２０３を、匿名公開鍵証明書を発行するエンティティＣＡ、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。あるいは、証明書発行のみを担う専用ＣＡサーバーを設けることも可能である。以下では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２を、匿名公開鍵証明書を発行するエンティティＣＡとし、ランダムなＩＰｖ６アドレスを証明書の中に含める例を説明するが、ＤＨＣＰサーバーや専用ＣＡサーバーを、匿名公開鍵証明書を発行するエンティティＣＡとすること、ランダムなＩＰｖ６アドレスを証明書に含めないことも可能である。ここでは、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は、ホスト２０６に、ＩＰｖ６のグローバルアドレスのプレフィックスを提供する。前述のように、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は多くの場合ルーターなので、ルーター２０２と呼ぶことにする。
【００８０】
ルーター２０２の管理者は、上述の公開パラメータｐ、ｇ等を定め、公開する。匿名公開鍵証明書を発行するエンティティＣＡとしての公開鍵ｖ＿ｃａを定め、より上位もしくはより普及しているＣＡ（図２の２０９）、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらう。
【００８１】
ルーター（ｇａｔｅｗａｙ）２０２は、パケットの転送を制御する役目を持ち、そのルーターの管轄するサブネットと外部との間で不適当なパケットが出入りしないように管理者の責任のもとで運用される。あるサブネットがインターネットに接続されるためにはそのサブネットの管理者は身元をＪＰＮＩＣ（日本の場合）に登録し、ＩＰアドレスの割当てを受ける。従って、サブネットにおけるルーターは管理責任が明確であり、かつ安全面も考慮されたうえで運用や管理にコストがかけられると期待されるので、匿名公開鍵証明書を発行するエンティティＣＡの機能を担わせるのにふさわしいと考えられる。
【００８２】
ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＬＡＮの管理者（ルーター２０２の管理者）に提出する。ＬＡＮの管理者（ルーター２０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０４もしくはＨＤ３０６に登録する。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。
【００８３】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１に示す。図１は、匿名公開鍵証明書を利用するエンティティ　（ユーザｉが用いるＩＰｖ６端末）をホスト２０６、匿名公開鍵証明書を発行するＣＡをルーター２０２とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。すなわち、ＩＰｖ６対応装置２０６が位置するローカルリンク２０７内に存在するＩＰｖ６対応装置２０２を公開鍵証明書発行者として運用する。
【００８４】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター２０２とエンティティ（この場合は、ホスト２０６）の間でなんらかの特定（認証）プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１の流れに沿って動作を説明する。
【００８５】
ホスト２０６はステップＳ１０１でＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成する。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎは、匿名公開鍵証明書を要求するメッセージであり、匿名公開鍵証明書を要求する旨とホスト２０６のインターフェイスＩＤを含むデータであることをルーター２０２が理解できる形式で生成する。内容は、エンティティ名（ユーザ名）とパスワードとシリアル番号から計算される。シリアル番号は、例えば、ホスト２０６のＩＰｖ６リンクローカルアドレスとｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２のＩＰｖ６リンクローカルアドレスとそのときの時刻の３つを連接して一つのデータにした値である。再送攻撃となりすましを防ぐために、秘密鍵ｓ＿ｉを用いて、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名（認証用ｓｉｇｎａｔｕｒｅ）　（Ｓｉｇ＿ｉ（ｈａｓｈ（エンティティ名、パスワード、シリアル番号）））が、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれる。
【００８６】
次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ　ＳｏｌｉｃｉｔａｔｉｏｎをステップＳ１０２でリンク２０７を介してルーター２０２に送る。
【００８７】
ステップＳ１０３で、ルーター２０２はステップＳ１０２で受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（通信装置（ホスト）２０６の識別子）から登録された公開鍵ｖ＿ｉをＲＡＭ　３０５もしくはＨＤ３０６から検索し、それを用いて認証用ｓｉｇｎａｔｕｒｅの正当性を確認する。具体的には、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数の入力とし、そのハッシュ値を求め、認証用ｓｉｇｎａｔｕｒｅがそれに対する正しいディジタル署名であることを公開鍵ｖ＿ｉで確認する。
【００８８】
認証が成功したら、ルーター２０２に割当てられたＩＰｖ６のグローバルアドレスのプレフィックスとホスト２０６のインターフェイスＩＤ　とからＩＰｖ６グローバルアドレスを生成し、そのライフタイム（使用期限、例えば２４時間）等を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。具体的には、前述のＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６グローバルアドレスやライフタイム等が含まれる。なお、ＩＰｖ６グローバルアドレスのライフタイム（使用期限）と匿名公開鍵証明書の有効期限は同じとは限らない。
【００８９】
そして、ステップＳ１０４でルーター２０２はＩＰｖ６グローバルアドレスのプレフィックスとｄｅｆａｕｌｔ　ｒｏｕｔｅｒ　２０２　のアドレスと匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）からなるＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを、リンク２０７を介して、認証されたホスト２０６に送る。本発明のある形態では、このＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。
【００９０】
ステップＳ１０５でホスト２０６は受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔからプレフィックスを取り出し、インターフェイスＩＤを付加して、ＩＰｖ６グローバルアドレスを生成するとともに、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する。このように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含み、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ’とｖ＿ｉ’は、同一のエンティティｉ（ホスト２０６）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。ホスト２０６は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１の匿名公開鍵発行プロトコルを実行し、使用する公開鍵ｇ’とｖ＿ｉ’を変更する。
【００９１】
以上のプロトコルを既存のＲｏｕｔｅｒ　ＳｏｌｉｃｉｔａｔｉｏｎとＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔの送受信プロトコルと組み合わせた拡張プロトコルのホストの動作フローチャートを図１１に示す。
【００９２】
ホスト２０６は、図１１のステップＳ１１０１において、図９のステップ９０１で送られるＲｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅと図１のステップＳ１０２で送られるＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎの両方を含むデータであるＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅを、リンク２０７を介して送る。
【００９３】
また、ステップＳ１１０２で、図９のステップＳ９０２で受け取るＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅと図１のステップＳ１０４で受け取るＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔの両方を含むデータであるＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取る。
【００９４】
Ｒｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを、リンク２０７を介して、受け取った場合、すなわち、ステップＳ１１０２で「はい」の場合、ホスト２０６は、ステップＳ１１０３では、図９のステップＳ９０３と同様に、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅ中のプレフィックスにインターフェイスＩＤを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとして、インターフェイス３０１に割当てるとともに、図１におけるステップＳ１０５を行なって、公開鍵ｇ’とｖ＿ｉ’を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を入手する。
【００９５】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書をホスト２０６に発行することができる。
【００９６】
なお、ルーター２０２の代りにＤＨＣＰサーバー２０３が匿名公開鍵証明書を発行するエンティティＣＡの役割を行なう場合は、図１１におけるステップＳ１１０６において図１と同様のプロトコルを実行する。ここでは、ＤＨＣＰサーバー２０３が、ホスト２０６に、グローバルアドレスのプレフィックスを提供する。この場合には図１１のステップＳ１１０６で、ホストはｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの拡張プロトコル、つまりＤＨＣＰサーバーからアドレスと証明書を取得するプロトコルを実行する。その動作フローチャートを図１２に示す。
【００９７】
図１０のプロトコルとの違いは、ステップＳ１２０３とステップＳ１２０４の二カ所である。
【００９８】
ステップＳ１２０３では、図１０のステップＳ１００３で送るＤＨＣＰ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅ　と図１のステップＳ１０２で送られるＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ相当のデータ（ＣＡがルーター２０２ではなくＤＨＣＰサーバー２０３である点が異なる）の両方を含むデータであるＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅを、リンク２０７を介して送る。
【００９９】
このＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅを受け取ると、ＤＨＣＰサーバー２０３は、ＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅを生成し、生成したＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅを、リンク２０７を介して送る。ここで、ＤＨＣＰサーバー２０３は、図１のＳ１０３のように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を生成し、ＤＨＣＰサーバー２０３のグローバルアドレスのプレフィックスとＤＨＣＰサーバー２０３のアドレスと匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）からなるＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ相当のデータと、図１のステップＳ１００４のＤＨＣＰ　Ｒｅｐｌｙ　ＭｅｓｓａｇｅをＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅに含める。
【０１００】
ホスト２０６は、ステップＳ１２０４で、ＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅ受け取る。このＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅは、図１０のステップＳ１００４で受け取るＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅと図１のステップＳ１０４で受け取るＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ相当のデータ（ＣＡがルーターではなくＤＨＣＰサーバーである点が異なる）の両方を含むデータである。したがって、ＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅからサイトローカルアドレスもしくはグローバルアドレスを決めるとともに、公開鍵ｇ’とｖ＿ｉ’を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を入手する。
【０１０１】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書をホスト２０６に発行することができる。
【０１０２】
ルーター２０２およびＤＨＣＰサーバー２０３の両方がＣＡの役割を行なう場合は、図１１におけるステップＳ１１０４で　ｓｔａｔｅｌｅｓｓ　と　ｓｔａｔｅｆｕｌ　の両方を指定するＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取った場合（「はい」の場合）に相当し、上記に示した二つの拡張プロトコルを任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、使い捨てＩＰｖ６グローバルアドレスとそれに対応する使い捨て匿名公開鍵証明書、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ等を自動設定および取得することができる。この場合、ルーター２０２及び　ＤＨＣＰサーバー２０３は、公開鍵証明書を提供する通信装置群に相当する。
【０１０３】
ホスト２０６は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１１の匿名公開鍵証明書を受け取るためのプロトコルを実行し、使用する公開鍵ｇ’とｖ＿ｉ’を変更する。
【０１０４】
なお、ＤＨＣＰサーバー２０３がＩＰｖ６アドレスのプレフィックスをホスト２０６に提供する形態を説明したが、ＩＰｖ６アドレスそのものを提供する形態ではプレフィックスのかわりにアドレスが送られる点とホストがアドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１０５】
（第２の実施の形態）
第１の実施の形態では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ルーター）兼ＣＡがホストを認証してから匿名公開鍵証明書とプレフィックスを含む　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　をホストに送った。本実施の形態では、プレフィックスの送付と匿名公開鍵証明書の発行が独立な例を説明する。
【０１０６】
第１の実施の形態と同様に、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２もしくはＤＨＣＰサーバー　２０３を、匿名公開鍵証明書を発行するエンティティＣＡとし、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉとする。あるいは、証明書発行のみを担う専用ＣＡサーバーを設けることも可能である。以下では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２を、匿名公開鍵証明書を発行するエンティティＣＡとし、ランダムなＩＰｖ６アドレスを証明書の中に含める例を説明するが、ＤＨＣＰサーバーや専用ＣＡサーバーを、匿名公開鍵証明書を発行するエンティティＣＡとすること、ランダムなＩＰｖ６アドレスを証明書に含めないことも可能である。ここでは、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は、ホスト２０６に、ＩＰｖ６のグローバルアドレスのプレフィックスを提供する。前述のように、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は多くの場合ルーターなので、ルーター２０２と呼ぶことにする。
【０１０７】
ルーター２０２の管理者は、前述の公開パラメータｐ、ｇ等を定め、公開する。匿名公開鍵証明書を発行するエンティティＣＡとしての公開鍵ｖ＿ｃａを定め、より上位もしくはより普及しているＣＡ（図２の２０９）、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらう。
【０１０８】
ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＬＡＮの管理者（ルーター２０２の管理者）に提出する。ＬＡＮの管理者（ルーター２０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０４もしくはＨＤ３０６に登録する。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。
【０１０９】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１５に示す。図１５は、匿名公開鍵証明書を利用するエンティティ　（ユーザｉが用いるＩＰｖ６端末）をホスト２０６、プレフィックスを提供するＩＰｖ６端末でありかつ匿名公開鍵証明書を発行するＣＡをｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルの動作フローを表している。すなわち、ＩＰｖ６対応装置２０６が位置するローカルリンク２０７内に存在するＩＰｖ６対応装置２０２を公開鍵証明書発行者として運用する。
【０１１０】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター２０２とエンティティ（この場合は、ホスト２０６）の間でなんらかの特定（認証）プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１５を参照しながら動作を説明する。
【０１１１】
ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。そして、ＭＡＣアドレスから生成したインターフェイスＩＤに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（ＲＳ）　をルーターに送る（ステップＳ１５０１）。ＲＳは前述のようにリンク上のルーター全て宛の　ｍｕｌｔｉｃａｓｔ　である。
【０１１２】
ルーター２０２は、ＲＳを受け取ったら、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　（ＲＡ）を送る（ステップＳ１５０２）。
【０１１３】
ＲＡを受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤと抽出したプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ　ａｄｄｒｅｓｓと呼ぶ）を生成する。また、ランダムなインターフェイスＩＤ　と抽出したプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓと呼ぶ）を作る。そして、ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ　とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割当てる（ステップＳ１５０３）。
【０１１４】
次に、ホスト２０６はＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成する（ステップＳ１５０４）。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎは、匿名公開鍵証明書を要求するメッセージであり、ホスト２０６が匿名公開鍵証明書を要求する旨を含むデータであることをルーター２０２が理解できる形式で生成する。例えば、ＲＦＣ２９８６，　｀｀ＰＫＣＳ　＃１０：Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ　Ｓｙｎｔａｘ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｖｅｒｓｉｏｎ　１．７，’’で規定されているＰＫＣＳ＃１０や、ＲＦＣ２５１１，　｀｀Ｉｎｔｅｒｎｅｔ　Ｘ．５０９　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｑｕｅｓｔ　ＭｅｓｓａｇｅＦｏｒｍａｔ’’等がそれらの形式を規定している。形式の詳細な説明は省くが、このＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎは、証明書要求メッセージと、それに対する（ホストの）署名からなるデータであるとする。
【０１１５】
次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを、リンク２０７を介してルーター２０２に送る（ステップＳ１５０５）。なお、この時点でルーター２０２の（ユニキャスト）アドレスをホスト２０６は知っているので　ｕｎｉｃａｓｔ　することが可能である。
【０１１６】
ルーター２０２は、ステップＳ１５０５で受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（ホスト２０６の識別子もしくはホスト２０６を利用するユーザの名前）から登録された公開鍵ｖ＿ｉをＲＡＭ　３０５もしくはＨＤ３０６から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト２０６の匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。具体的には、前述のＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６グローバルアドレスやライフタイム等が含まれる（ステップＳ１５０６）。
【０１１７】
そして、ルーター２０２は匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを、リンク２０７を介して、認証されたホスト２０６に送る（ステップＳ１５０７）。本発明のある形態では、このＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。このとき、ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓ宛のｕｎｉｃａｓｔとして送ることが可能である。
【０１１８】
ホスト２０６は受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔから匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する（ステップＳ１５０８）。
【０１１９】
以上のプロトコルを既存のｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎおよびｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎと組み合わせた拡張プロトコルのホストの動作フローチャートを図１７に示す。
【０１２０】
ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。そして、ＭＡＣアドレスから生成したインターフェイスＩＤに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（ＲＳ）　をルーターに送る（ステップＳ１７０１）。ＲＳは前述のようにリンク上のルーター全て宛の　ｍｕｌｔｉｃａｓｔ　である。
【０１２１】
ステップＳ１７０２の「はい」の場合に示すように、Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　のみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージ（ＲＡ）を受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤと抽出したプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ　ａｄｄｒｅｓｓと呼ぶ）を生成する。また、ランダムなインターフェイスＩＤ　と抽出したプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓと呼ぶ）を作る。
【０１２２】
そして、ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ　とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割当てる（ステップＳ１７０３）。
【０１２３】
次に、ホスト２０６は、証明書要求と証明書発行のプロトコルを実行する（ステップＳ１７０７）。すなわち、ホスト２０６は、図１５のステップＳ１５０４、Ｓ１５０５で示したように、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成し、ルーター２０２に送る。ホスト２０６は、ルーター２０２からＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取り、その中に含まれる匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する。
【０１２４】
なお、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合は（ステップＳ１７０４のいいえの場合）、ｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、すなわちＤＨＣＰｖ６のみを実行する。これがステップＳ１７０６であり、その詳細は図１０のプロトコルと同じである。
【０１２５】
ステップＳ１７０４でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを受け取った場合は、ステップＳ１７０５でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を行なう。処理内容はステップＳ１７０３とＳ１７０６と同じである。
【０１２６】
以上の説明では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ２０２（ルーター）がＣＡを兼ねていたが、一般にはｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ルーター）とＣＡが同一のＩＰｖ６装置とは限らない。Ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ルーター）とＣＡが異なるＩＰｖ６装置の場合の動作フローを図１６に示す。
【０１２７】
ＣＡの管理者は、前述の公開パラメータｐ、ｇ等を定め、公開する。匿名公開鍵証明書を発行するエンティティＣＡとしての公開鍵ｖ＿ｃａを定め、より上位もしくはより普及しているＣＡ（図２の２０９）、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらう。
【０１２８】
ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＣＡの管理者に提出する。ＣＡの管理者は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０４もしくはＨＤ３０６に登録する。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。
【０１２９】
なお、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　（ルーター）２０２の管理者とＣＡの管理者が同一であってもよいし、同一でなくてもよい。図１６は、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２（ルーター）とＣＡが別のＩＰｖ６装置であり、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ２０２にＣＡのＩＰｖ６アドレスが設定されているものとする。
【０１３０】
ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。前述のようにリンクローカルアドレスの生成等を行ない、Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ拡張（ＲＳ拡張）　をｒｏｕｔｅｒに送る（ステップＳ１６０１）。ＲＳ拡張は、ＣＡのアドレスを要求する旨のメッセージをＲｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎに追加した情報であり、前述のＲＡと同じくリンク上のルーター全て宛の　ｍｕｌｔｉｃａｓｔ　である。
【０１３１】
ルーター２０２は、ＲＳ拡張を受け取ったら、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ拡張　（ＲＡ拡張）を送る（ステップＳ１６０２）。ＲＡ拡張は、ＣＡのアドレスを　Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔに追加した情報である。
【０１３２】
ＲＡ拡張を受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤとプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ）を生成する。また、ランダムなインターフェイスＩＤ　とプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓと呼ぶ）を作る。そして、ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ　とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる。また、ＲＡ拡張からＣＡのアドレスを抽出する（ステップＳ１６０３）。
【０１３３】
次に、ホスト２０６はＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成し（ステップＳ１６０４）、Ｃｅｒｔｉｆｉｃａｔｅ　ＳｏｌｉｃｉｔａｔｉｏｎをＣＡに送る（ステップＳ１６０５）。
【０１３４】
ＣＡはステップＳ１６０５で受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（通信装置（ホスト）２０６の識別子）から登録された公開鍵ｖ＿ｉをＲＡＭ３０５もしくはＨＤ３０６から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト２０６の匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。具体的には、前述のＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６グローバルアドレスやライフタイム等が含まれる（ステップＳ１６０６）。
【０１３５】
そして、ＣＡは匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを、ホスト２０６に送る（ステップＳ１６０７）。本発明のある形態では、このＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。
【０１３６】
ホスト２０６は受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔから匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する（ステップＳ１６０８）。
【０１３７】
以上のプロトコルを既存のｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎおよびｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎと組み合わせた拡張プロトコルのホストの動作フローチャートは、図１７とほぼ同様であるが、以下の２点が異なる。すなわち、ステップＳ１７０１で、Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅの代わりに、Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　拡張　Ｍｅｓｓａｇｅ　を送る。また、ステップＳ１７０７で、証明書要求と証明書発行のプロトコルとして、図１６で示したプロトコルを実行する。
【０１３８】
（第３の実施の形態）
本実施の形態では、ホストがダイヤルアップあるいはＡＤＳＬのような方式でインターネットと接続する形態を説明する。最初に現状を説明し、その後に本発明の実施の形態を説明する。
【０１３９】
図１４は、本発明が適用される接続環境を模式的に示したものである。図１４は、ホスト１４０６がＰＳＴＮ（Ｐｕｂｌｉｃ　Ｓｗｉｔｃｈｅｄ　Ｔｅｌｅｐｈｏｎｅ　Ｎｅｔｗｏｒｋ）経由でＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）の提供するインターネット１４０１とアクセスする環境を示す。本実施の形態では、ＩＳＰとホスト１４０１はＰＰＰリンクで接続するものとする。
【０１４０】
図１４において、ＩＳＰのＰＰＰ　ｐｅｅｒ　１４０２はノードであり、ｍｏｄｅｍ　１４０３を用いてＰＳＴＮ　１４０４を介してホスト１４０６からのＰＰＰ接続の要求を受け付ける。ホスト１４０６はｍｏｄｅｍ　１４０５を用いてＰＰＰ　ｐｅｅｒ　１４０２にＰＰＰ接続でアクセスする。ホスト１４０６の構成は、図３と同様であり、ネットワーク・インターフェイス３０１を介して、モデム１４０５を接続する。また、ＰＰＰ　ｐｅｅｒ　１４０２の構成も、図３と同様であり、ネットワーク・インターフェイス３０１を介して、モデム１４０３を接続し、ネットワーク・インターフェイス３０２を介して、インターネット１４０１と接続する。ＰＰＰ　ｐｅｅｒ　１４０２は、図１４に示すように、　ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　ｍｏｄｕｌｅ　１４０２１、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３として、機能する。ホスト１４０６とＰＰＰ　ｐｅｅｒ　１４０２が通信する場合、ホスト１４０６は、モデム１４０５を介して、通信を行ない、ＰＰＰ　ｐｅｅｒ　１４０２は、モデム１４０３を介して、通信を行なう。
【０１４１】
本実施の形態では、ｍｏｄｅｍとＰＳＴＮを例として取り上げて説明するが、ＴＡ（Ｔｅｒｍｉｎａｌ　Ａｄａｐｔｅｒ）とＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ　Ｓｅｒｖｉｃｅｓ　Ｄｉｇｉｔａｌ　Ｎｅｔｗｏｒｋ）、ＰＨＳ通信アダプターとＰＨＳ通信網、専用線接続装置と専用線等の他の通信形態であったとしてもＰＰＰ接続が確立できる環境であれば本質的には同じである。ＰＰＰ接続の詳細は、ＲＦＣ　１６６１｀｀Ｔｈｅ　Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ　Ｐｒｏｔｏｃｏｌ　（ＰＰＰ）’’　に記述されている。
【０１４２】
ホスト１４０６がモデム１４０５、ＰＳＴＮ１４０４、モデム１４０３を介してＰＰＰ接続の要求を、ＰＰＰ　ｐｅｅｒ　１４０２に伝える。ＰＰＰ　ｐｅｅｒ　１４０２は、その接続要求を受け、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３がホストの認証を行なう。典型的な認証方式は、ユーザ名とパスワードに基づく認証プロトコルＣＨＡＰであり、詳細はＲＦＣ１９９４｀｀ＰＰＰ　Ｃｈａｌｌｅｎｇｅ　Ｈａｎｄｓｈａｋｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ’’に記述されている。
【０１４３】
認証が完了したら、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２が、その設定に従い、ＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６アドレス等をホスト１４０６に伝える。ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２は、ＩＳＰの管理者がその運用方針に従った設定を行なっている。
【０１４４】
なお、図１４では説明を簡単にするため、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　とＤＨＣＰサーバーとＡｕｔｈｅｎｔｉｃａｔｉｏｎ　サーバーをそれぞれｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　ｍｏｄｕｌｅ　１４０２１、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３としてＰＰＰ　ｐｅｅｒ内部に存在するものとしているが、実際にはリンク１４０７上にそれぞれ異なるノードとして存在することもある。いずれの実現形態であっても、それらのｍｏｄｕｌｅあるいはノードが、ＩＳＰの管理者の管理下で安全に運用されていれば構わないので、以下では、図１４の形態でホスト１４０６とＰＰＰ　ｐｅｅｒ　１４０２の間のＰＰＰリンクが確立したものとして説明する。
【０１４５】
ホスト１４０６は、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２からＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６アドレス等を受け取ったならば、ＩＰｖ６グローバルアドレスのプレフィックスと自分の（ＲＦＣ３０４１等の方法で生成した）ランダムなインターフェイスＩＤとを組み合わせて、ランダムなＩＰｖ６グローバルアドレスを生成し、それがリンクにおいて重複していないことを確認してから、それをインターフェイス３０１に割当て、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　のＩＰｖ６アドレスを記憶する。
【０１４６】
以上の動作により、ホスト１４０６は使い捨てＩＰｖ６アドレスを使ってインターネットの任意の相手と通信できる。
【０１４７】
次に、本発明の実施の形態を説明する。上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。
【０１４８】
以下では、匿名公開鍵証明書方式を、図１４の環境に適用する場合を説明する。ＰＰＰ　ｐｅｅｒ　１４０２が匿名公開鍵証明書を発行するＣＡ、ホスト１４０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。以下では、ランダムなＩＰｖ６アドレスを証明書の中に含める形態を説明するが、ランダムなＩＰｖ６アドレスを含めないことも可能である。
【０１４９】
ＩＳＰは、前述の公開パラメータｐ、ｇ等を定め、公開する。自分の公開鍵ｖ＿ｃａを定め、より上位もしくはより普及しているＣＡ（図１４の１４０８）、例えば、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等に提出して、ｖ＿ｃａに対する公開鍵証明書を発行してもらう。
【０１５０】
ユーザｉがＩＳＰに加入を申請する際に、ＩＳＰが公開しているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＩＳＰに提出する。ＩＳＰの管理者（ＰＰＰ　ｐｅｅｒ１４０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、ユーザ名に対応して公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０５もしくはＨＤ３０６に登録する。公開パラメータや公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト１４０６で安全に利用可能になっているものとする。
【０１５１】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１３に示す。図１３は、エンティティ（ユーザｉが用いるＩＰｖ６端末）をホスト１４０６、匿名公開鍵証明書を発行するＣＡをＰＰＰ　ｐｅｅｒ　１４０２とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。
【０１５２】
ＰＰＰ接続におけるデータリンク層の処理が終わった後、前述のように、ホスト１４０６からのＰＰＰ接続の要求を受けたＰＰＰ　ｐｅｅｒ　１４０２は、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３で、ユーザ名（識別子）とパスワードに基づき、認証プロトコルＣＨＡＰによるホストの認証を行なう。
【０１５３】
すなわち、ホスト１４０６はステップＳ１３０１でエンティティ名（ユーザ名）をＰＰＰ　ｐｅｅｒ１４０２に送る。ステップＳ１３０２でＰＰＰ　ｐｅｅｒ　１４０２はＣＨＡＰ−ｃｈａｌｌｅｎｇｅを生成し、ステップＳ１３０３でそれをホスト１４０６に送る。
【０１５４】
ホスト１４０６はステップ　Ｓ１３０４でエンティティ名とパスワードとＣＨＡＰ−ｃｈａｌｌｅｎｇｅをハッシュ関数に入力してＣＨＡＰ−ｒｅｓｐｏｎｓｅを求め、求めた結果のＣＨＡＰ−ｒｅｓｐｏｎｓｅの値をステップＳ１３０５でＰＰＰ　ｐｅｅｒ　１４０２に送る。
【０１５５】
ステップＳ１３０６でＰＰＰ　ｐｅｅｒ　１４０２は、ＣＨＡＰ−ｒｅｓｐｏｎｓｅの正当性を確認する。確認出来たならば認証は成功なので、その認証されたホスト１４０６に対してＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　のアドレスをステップＳ１３０７で伝える。
【０１５６】
ホスト１４０６は、ステップＳ１３０８でＩＰｖ６グローバルアドレスのプレフィックスとランダムなインターフェイスＩＤとからＩＰｖ６グローバルアドレスを生成し、それが重複していないことを確認してから、それをネットワーク・インターフェイス３０１に割当て、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙのアドレスも記憶する。次に匿名公開鍵証明書を要求するメッセージとしてＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　をステップＳ１３０９でＰＰＰ　ｐｅｅｒ
１４０２に送る。
【０１５７】
Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　は、第１の実施の形態と同様に、匿名公開鍵証明書を要求する旨とインターフェイスＩＤを含むデータであることをＰＰＰ　ｐｅｅｒ　１４０２が理解できる形式で生成される。内容は、エンティティ名（ユーザ名）とパスワードとシリアル番号から計算され、シリアル番号は、例えば、ホスト２０６のＩＰｖ６リンクローカルアドレスとｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６リンクローカルアドレスとそのときの時刻の３つを連接して一つのデータにした値である。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎには、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名（認証用ｓｉｇｎａｔｕｒｅ）が含まれる。
【０１５８】
ＰＰＰ　ｐｅｅｒ　１４０２は、エンティティ名（通信装置（ホスト）２０６のユーザ名）に対応する登録された公開鍵ｖ＿ｉをＲＡＭ　３０５もしくはＨＤ３０６から検索し、前述の図１のＳ１０３で説明した匿名公開鍵証明書の生成をステップＳ１３１０で実行する。すなわち、ＰＰＰ　ｐｅｅｒ　１４０２に割当てられたＩＰｖ６のグローバルアドレスのプレフィックスとホスト１４０６のインターフェイスＩＤ　とからＩＰｖ６グローバルアドレスを生成し、そのライフタイム等を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。具体的には、前述のＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６グローバルアドレスやライフタイム等が含まれる。
【０１５９】
そして、図１のＳ１０４と同様に、生成された匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）等を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔをホスト１４０６に対してステップＳ１３１１で送る。ホスト１４０６は受け取った匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性をステップＳ１３１２で確認する。このように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含み、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ’とｖ＿ｉ’は、同一のエンティティｉ（ホスト１４０６）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１６０】
以上のプロトコルにおいて、ステップＳ１３０５とＳ１３０９で送受されるデータを一つにまとめてステップＳ１３０５で送ることも可能である。図示しないが、その場合、ホスト１４０６はランダムなインターフェイスＩＤと図１３のステップＳ１３０５のＣＨＡＰ−ｒｅｓｐｏｎｃｅとステップＳ１３０９の　Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（第１の実施の形態と同様）をステップＳ１３０５’でＰＰＰ　ｐｅｅｒ１４０２に送る。
【０１６１】
そして、ステップＳ１３０６’で、ＰＰＰ　ｐｅｅｒ　１４０２は、ＣＨＡＰ−ｒｅｓｐｏｎｓｅの正当性を確認し、登録された公開鍵ｖ＿ｉを検索し、ＩＰｖ６プレフィックスとインターフェイスＩＤとからＩＰｖ６グローバルアドレスを生成し、それとそのライフタイム（使用期限、例えば２４時間等）等を含めたデータを生成し、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を生成する。生成された匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔをホスト１４０６に対してステップＳ１３０７’で送る。
【０１６２】
ホスト１４０６は受け取った匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性をステップＳ１３０８’で確認する。このステップＳ１３０８’で図１３のステップＳ１３１２に相当する処理まで終了するので、これ以降のステップは存在しない。
【０１６３】
以上のプロトコルで、ＰＰＰ　ｐｅｅｒ　１４０２は、ホスト１４０６に、使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書を発行する。
【０１６４】
ホスト１４０６は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１３の匿名公開鍵証明書発行プロトコルを実行し、使用する公開鍵ｇ’とｖ＿ｉ’を変更する。
【０１６５】
なお、以上の説明ではＰＰＰ　Ｐｅｅｒ　１４０２がＩＰｖ６プレフィックスをｈｏｓｔ１４０６に伝え、ｈｏｓｔ１４０６がＩＰｖ６プレフィックスとインターフェイスＩＤからＩＰｖ６アドレスを生成する場合を述べたが、ＰＰＰ　Ｐｅｅｒ　１４０２がＩＰｖ６アドレスをｈｏｓｔ１４０６に伝え、ｈｏｓｔ１４０６がそれを使う場合も同様のプロトコルで実現される．その場合、図３のステップＳ１３０７でＩＰｖ６プレフィックスの代わりにＩＰｖ６アドレスが送られる点とステップＳ１３０８でプレフィックスからＩＰｖ６アドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１６６】
（第４の実施の形態）
第１の実施の形態や第２の実施の形態、第３の実施の形態で発行された使い捨てＩＰｖ６アドレスと使い捨て匿名公開鍵証明書を用いてＩＰｓｅｃ通信を行なう形態を説明する。
【０１６７】
まず、秘密データやお互いのＩＰｖ６アドレス等のデータであるＳＡ（Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）を安全に共有するプロトコルであるＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）の公開鍵暗号による暗号化の改訂モードによる認証方法を簡単に説明し、匿名公開鍵証明書を用いる方法を説明する。
【０１６８】
ＩＫＥは二つのｐｈａｓｅからなり、Ｐｈａｓｅ　１において安全な通信路を確立し、ｐｈａｓｅ　２では、ＩＰｓｅｃ等の通信で使用されるＳＡが前記安全な通信路を用いて合意される。以下では、Ｐｈａｓｅ　１のみを説明する。ＩＫＥのＰｈａｓｅ　１にはＭａｉｎ　ｍｏｄｅとＡｇｇｒｅｓｓｉｖｅ　ｍｏｄｅが存在するが、以下に説明するのは、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ（ＩＫＥ）’’のｐｐ．　１３−１５の５．３　Ｐｈａｓｅ　１　Ａｕｔｈｅｎｔｉｃａｔｅｄ　ｗｉｔｈ　ａ　Ｒｅｖｉｓｅｄ　ｍｏｄｅ　ｏｆ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｅｎｃｒｙｐｔｉｏｎ　の　Ｍａｉｎ　ｍｏｄｅ　である。
【０１６９】
ＩＫＥにおいて、通信する２エンティティはＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒと呼ばれる。Ｉｎｉｔｉａｔｏｒが通信を開始する。最初に、Ｉｎｉｔｉａｔｏｒが複数のＳＡをＲｅｓｐｏｎｄｅｒに送り、Ｒｅｓｐｏｎｄｅｒが使って良いと判断した一つのＳＡをＩｎｉｔｉａｔｏｒに送ることで、ｐｈａｓｅ　１用のＳＡを決定する。
【０１７０】
Ｉｎｉｔｉａｔｏｒは、乱数（Ｎｏｎｃｅと呼ばれる）を生成し、Ｒｅｓｐｏｎｄｅｒの公開鍵で暗号化したデータをＲｅｓｐｏｎｄｅｒに送る。Ｒｅｓｐｏｎｄｅｒは乱数を生成し、Ｉｎｉｔｉａｔｏｒの公開鍵で暗号化したデータをＩｎｉｔｉａｔｏｒに送る。これにより、それぞれの生成したｎｏｎｃｅを共有できるので、他の通信で用いられる暗号の鍵を、共有したｎｏｎｃｅから生成する。詳細は、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ　（ＩＫＥ）’’に記載されている。以上の説明から明らかなように、通信相手の公開鍵をＩＰｓｅｃ通信に先だって知る必要がある。
【０１７１】
以下のような状況を考える。ある買い物サイト等のインターネット上のサイトにユーザがアクセスする。ユーザは、図２の形態では、例えば、ホスト２０６であり、図１４の形態では、ホスト１４０６である。買い物サイトは、図２の形態では、インターネット２０１、ゲートウェイ２０２を介して、ユーザであるホスト２０６に接続され、図１４の形態では、インターネット１４０１、ＰＰＰ　ｐｅｅｒ　１４０２を介して、ユーザであるホスト１４０６に接続される。ホスト２０６、１４０６は、この買い物サイトなどのサイトを通信相手とする通信を開始する前に、上述したプロトコルで、Ｉｐｖ６アドレス、及び、公開鍵を含む公開鍵証明書を得ておく。この形態において、上述した公開鍵証明書に基づき鍵交換・更新・変更プロトコルを実行して暗号・認証通信を行なう手順を行なう。
【０１７２】
このとき、ユーザは買い物サイトのＩＰｖ６アドレス（識別子）を（明示的か非明示的かは問わないが）知っている。実際にアクセスして、そこがユーザにとって正しいサイトであるときに、通信相手のＩＰｖ６アドレスを確認することでユーザは明示的にアドレスを知ることができる。通信している最中には、買い物サイトも通信相手のアドレス（識別子）はわかる。以上の通信は使い捨てＩＰｖ６アドレスで行なえる。
【０１７３】
本形態では、送受信者が確定した時点で、使い捨てＩＰｖ６アドレスは（更新せず）、同一のアドレスを使うこととする。この時点で、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）　＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））をお互いに送り合う。すると、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）中の管理・属性情報Ｘには、ＩＰｖ６グローバルアドレスが含まれているので、そのＩＰｖ６アドレスが実際に通信している相手のＩＰｖ６アドレスと一致するか否かを確認し、かつ使い捨て匿名公開鍵証明書の正当性を確認すれば、それが本当に通信相手の使い捨て匿名公開鍵証明書か否かを判断でき、その中に含まれる公開鍵（ｇ’、ｖ＿ｉ’）が本当に通信相手の公開鍵か否かを確認できる。
【０１７４】
使い捨て匿名公開鍵証明書の正当性は、次のように確認できる。証明書の管理・属性情報ＸにはＣＡ（前述のルーター２０２やＤＨＣＰサーバー２０３、又は、ＰＰＰ　ｐｅｅｒ　１４０２）の公開鍵ｖ＿ｃａとそれに対する公開鍵証明書（商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等が発行した証明書）が含まれている。サイトは、それらの対応関係が正しいか否かを、商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等の公開鍵（広く知られているので容易に入手できる）を用いて確認できる。正当性が確認できたｖ＿ｃａを用いて、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の正当性、すなわち、（ｇ’、ｖ＿ｉ’）とＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）の対応関係の正しさを確認できる。匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含み、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ’とｖ＿ｉ’は、同一のエンティティｉの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１７５】
ホスト２０６、１４０６は、通信相手が変る度に（すなわち、新たに、サイトに接続する度に）、若しくは、セッションが変る毎に、図１１、図１３のプロトコルを実行し、使用するＩＰｖ６アドレス及び公開鍵ｇ’とｖ＿ｉ’を更新・変更する。なお、公開鍵ｇ’とｖ＿ｉ’は、通信パケットの送信毎に、更新・変更してもよい。
【０１７６】
以上により、使い捨てＩＰｖ６アドレスとそれを含む使い捨て匿名公開鍵証明書を用いて、ＩＰｖ６アドレスで定義される通信相手の公開鍵を確実に入手できる。このようにして交換した公開鍵を用いて前述のＩＫＥ　の　ｐｈａｓｅ　１　の　Ｍａｉｎ　ｍｏｄｅ　を行なうことにより、そのＩＰｖ６アドレスを持つ通信相手とのＩＰｓｅｃ通信が実行できる。
【０１７７】
すなわち、本形態では、ＩＰｖ６対応装置が位置するローカルリンク内に存在するＩＰｖ６対応装置を公開鍵証明書発行者として運用し、使い捨て匿名公開鍵証明書の中にＩＰｖ６アドレスを含めて、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであるＩＰｓｅｃ通信、及び、ＩＰｓｅｃに際して、秘密データやお互いのＩＰｖ６アドレス等のＳＡ（Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）を安全に共有するプロトコルであるＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）を行なう。
【０１７８】
従って、課題で述べたような通信相手のなりすましは防がれる。
【０１７９】
【発明の効果】
以上説明したように、本出願に関わる発明によれば、使い捨てＩＰｖ６アドレスとそれを含む使い捨て匿名公開鍵証明書を実現できる。
【０１８０】
また、匿名公開鍵を生成するためのホストが計算する負荷を軽減することができる。
【０１８１】
さらに、プライバシ保護の程度が高く、低コストで実現可能であり、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能である。
【０１８２】
また、強力なプライバシ保護を実現し、かつなりすましを防ぎながらＩＫＥによるＩＰｓｅｃ通信を行なうことができる。
【図面の簡単な説明】
【図１】第１の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（Ｒ）ＬＡＮの場合）の図である。
【図２】イーサネット（Ｒ）ＬＡＮの模式図である。
【図３】ノードの構成図である。
【図４】イーサネット（Ｒ）のＭＡＣアドレスの構成図である。
【図５】インターフェイスＩＤの構成図である。
【図６】ａ　ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓの構成図である。
【図７】あるｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓの構成図である。
【図８】ホストがＤＡＤを終えるまでの動作を説明するフローチャート図である。
【図９】ホストがアドレス自動設定を終えるまでの動作を説明するフローチャート図である。
【図１０】ホストがＤＨＣＰでアドレスを取得するまでの動作フローチャート図である。
【図１１】ホストがアドレス自動設定を行ない、匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１２】ホストがＤＨＣＰでアドレスと匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１３】第３の実施の形態における匿名公開鍵証明書発行プロトコル（ＰＰＰの場合）の図である。
【図１４】ダイヤルアップ／ＡＤＳＬ接続の模式図である。
【図１５】第２の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（Ｒ）ＬＡＮの場合）の図である。
【図１６】匿名公開鍵証明書発行プロトコルの一般形の図である。
【図１７】ホストが証明書を取得するまでの動作フローチャート図である。
【符号の説明】
３００　ノード
３０１　ネットワーク・インターフェイス
３０２　ネットワーク・インターフェイス
３０６　ＨＤ（ハードディスク）
３０８　キーボード／ポインティングデバイスのインターフェイス
３０９　モニターのインターフェイス
１４０２　ＩＳＰのＰＰＰ　ｐｅｅｒ
１４０４　ＰＳＴＮ　（Ｐｕｂｌｉｃ　Ｓｗｉｔｃｈｅｄ　Ｔｅｌｅｐｈｏｎｅ　Ｎｅｔｗｏｒｋ）[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a providing device that provides a public key certificate.
[0002]
[Prior art]
With the advent of IPv6, a situation has been considered in which a device that could not conventionally be considered to connect to a network connects to the network. For example, an end-user digital camera that can be directly connected to the Internet.
[0003]
In the case of a personal computer or a workstation corresponding to IPv6, Ethernet (R) is usually used as an interface for connection to a network, and an IPv6 address is configured based on an IEEE identifier (MAC address) of the personal computer or workstation. It has become.
[0004]
As will be described later, there are three types of IPv6 addresses: a link local address, a site local address, and (aggregatable) a global address.
[0005]
Address systems such as details and a configuration method thereof are described in RFC 2373 @ IP Version 6 Addressing Architecture, `` RFC 2374 @ An IPv6 Aggregatable Global Global Unicast Address Dictionary <<'> 2450 @ Proposed TLA and NLA Assignment Rule, "RFC 2461 @ Neighbor Discovery for IP Version 6 (IPv6)," RFC 2462 @ IPv6 State Audition, etc.
[0006]
By the way, when information corresponding to one-to-one is fixedly used in hardware such as IEEE identifier (MAC address), it is regarded as information corresponding to one-to-one with a device or a user of the device, and its address is considered. There is a strong possibility that privacy will be violated by monitoring communications that use.
[0007]
To solve this problem, a method of generating a random IPv6 address (accurately, an interface ID) has been proposed in RFC3041 {Privacy Extensions for Stateless Address Autoconfiguration in IPv6, ″, and the like.
[0008]
If the generated random value is already used, a protocol (extension) for detecting the random value, calculating / generating another random value, and defining a unique random value is also described.
[0009]
When the device uses a random IPv6 address generated by using the above-described solution, it is assumed that encrypted communication is performed using IPsec.
[0010]
IPsec is a protocol in which two devices on the Internet share secret data that no one else knows, and perform encryption and authentication based on the secret data. In communication, the secret data and each other's IPv6 address are secured. Need to share to. Data such as confidential data and each other's IPv6 address is called SA (Security Association).
[0011]
A protocol for securely sharing an SA is called IKE (Internet Key Exchange), and is defined in RFC2409 "The Internet Key Exchange (IKE)". Here, the meaning of safely sharing the SA means that the SA is securely shared only with the intended partner, and it is necessary to reliably authenticate the partner. IKE includes 1) a method using a pre-shared key, 2) a method using a digital signature, 3) a method using encryption using public key encryption, and 4) a method using a revised mode of encryption using public key encryption. Two authentication methods are specified.
[0012]
However, considering a situation in which privacy protection (information that does not reveal identity) is realized, for example, in a case where a user performs IPsec communication with a shopping site, it is predetermined from the viewpoint of the shopping site. Since it is actually impossible to share the pre-shared key with an unspecified number of communication partners prior to the IPsec communication, the method using the pre-shared key cannot be used.
[0013]
In the case of other methods, IKE can be executed between an unspecified number of communication partners if information necessary for using digital signatures or public key encryption (in many cases, a public key) can be reliably obtained. It is. The most promising for that purpose is an environment and mechanism called PKI (Public-Key Infrastructure), and a public key certificate plays a central role in the environment and mechanism.
[0014]
The public key certificate is used by a trusted third party to confirm the correspondence between an entity (communicating entity, computer or human) and the public key of the entity, and to publish the entity's ID information etc. A digital signature issued by a trusted third party to a key set. A trusted third party is called a CA (Certification Authority), and a public key for verifying the validity of a digital signature of the CA is widely and generally known.
[0015]
However, since the public key certificate currently in operation includes ID information indicating its owner (Subject), for example, FQDN (Fully Qualified Domain Name), privacy protection cannot be realized as it is.
[0016]
A method of not including the owner's ID information in the public key certificate is also considered, and is called an anonymous public key certificate.
[0017]
However, the anonymous public key certificate has the same problem as the above-mentioned IEEE identifier (MAC address). In other words, as long as the same anonymous public key certificate is used, it is possible to link a plurality of communications (such as IPsec based on the public key certificate), and the correspondence between the anonymous public key certificate and its owner even once. When privacy becomes evident, privacy is violated, so the degree of privacy protection is also weak.
[0018]
With respect to the above problem, for example, if it is possible to use different IPv6 addresses and anonymous public key certificates when communicating with different communication partners, it is considered that strong privacy protection can be realized. These are called disposable IPv6 addresses and disposable anonymous public key certificates. There are several possible disposable intervals, such as using a new disposable IPv6 address each time the communication partner changes, or changing it for each packet.
[0019]
[Problems to be solved by the invention]
However, regarding the disposable IPv6 address, the above-mentioned RFC3041 @ Privacy Extensions for Stateless Address Autoconfiguration in IPv6, '' is known, but it is to a device capable of IPv6 communication (hereinafter, referred to as an IPv6-compatible device). There is no known method for efficiently and reliably issuing disposable anonymous public key certificates.
[0020]
In addition, there are the following problems. That is, when the ID information of the communication partner is not known, the identification of the communication partner is performed only by the IP address. However, for example, packets transmitted and received on an Ethernet LAN can be accessed by all nodes on the LAN, so that the entity A and the entity B should originally communicate with each other. C with A can pretend to be A. That is, in order to perform IPsec communication based on a disposable anonymous public key certificate between A and B, when A's public key certificate is sent to B, A's public key certificate is replaced with C's. Then C can be impersonated as A.
[0021]
If a DNS (Domain Name System) server or router is subjected to a DoS (Denial of Services) attack on a server or router, and a fake DNS server or router gives false information during the attack, a broader range is not limited to the LAN. Impersonation is also possible. If the ID of the communication partner is known, it could be dealt with by confirming it, but a method of preventing this kind of attack in a situation of high anonymity as described above has not been known until now.
[0022]
Another object of the present invention is to enable a public key certificate issuer to easily confirm the uniqueness of an IPv6 address used by an IPv6-compatible device, and to issue a public key certificate on the basis thereof. is there.
[0023]
It is another object of the present invention to efficiently and reliably issue a disposable anonymous public key certificate including an IPv6 address in a certification target, that is, quickly issue a certification target without mistake.
[0024]
Another object of the present invention is to perform IKE and IPsec communication using a disposable anonymous public key certificate including an IPv6 address as a certification target.
[0025]
Another object of the present invention is to make it possible to efficiently realize IPsec communication including a random IPv6 address and using a different anonymous public key certificate each time, to realize strong privacy protection, and to prevent spoofing. It is to be.
[0026]
[Means for Solving the Problems]
In order to solve the above problem, the invention according to the present application is characterized in that an IPv6-compatible device existing in a local link where an IPv6-compatible device is located is operated as a public key certificate issuer.
[0027]
BEST MODE FOR CARRYING OUT THE INVENTION
(First Embodiment)
In the present embodiment, a case where a host connects to the Internet via an Ethernet LAN is described. First, the present situation will be described, and then this embodiment will be described.
[0028]
FIG. 2 schematically shows a connection environment to which the present invention is applied (an environment in which a host connects to the Internet via an Ethernet LAN).
[0029]
FIG. 2 shows an environment in which hosts 204, 205, and 206 connected to a LAN access the Internet 201 via a default gateway (gateway) 202. In the present embodiment, it is assumed that each host is connected by a link 207, and the link 207 is specifically an Ethernet (R). A link is a piece of equipment or media through which devices connected to it can communicate, and touches below the IP layer. In addition to Ethernet (R), PPP links, X. 25, frame relay and ATM networks.
[0030]
An IPv6-compatible device connected to the link is called a node.
[0031]
FIG. 3 shows a typical example of the internal configuration of the node.
[0032]
A node has a router and a host, and the router forwards packets not addressed to itself, but the host does not. As can be seen from FIG. 3, the node 300 includes a network interface 301, 302, CPU 303, ROM 304, RAM 305, HD (hard disk) 306, power supply 307, keyboard / pointing device interface 308, monitor interface 309, bus 310, and the like. Computer.
[0033]
A router often has one network interface 301 while a router has a plurality of network interfaces 301 and 302. The hosts 204, 205, and 206 communicate with other nodes connected to the link 207 via the network interface 301 via the link 207, or with a site on the Internet 201 via the gateway 202. The default gateway 202 communicates with another node connected to the link 207 via the network interface 301 and communicates via the Internet 201 via the network interface 302. Some nodes do not have an HD.
[0034]
The following processing contents (procedure) are realized as an apparatus or a program, and are executed by a node having the apparatus, or executed by a node in which the program is stored in the ROM 304 or the HD 306. For example, when implemented as a program, the CPU 303 reads the program and assigns an address to the interface 301 via the bus 310 while using the RAM 305 as a space for calculation as necessary. Such operation is performed.
[0035]
Here, the essence of the procedure will be described, such as the node 300 assigning an address to an interface.
[0036]
In this embodiment, a mechanism of a protocol in which each host acquires a prefix of an IPv6 global address and an address of a default gateway 202 in an Ethernet (R) LAN environment will be briefly described, and then a specific embodiment of the present invention will be described. An embodiment will be described.
[0037]
FIG. 8 shows a flowchart of an operation performed when the node 300 connected to the link 207 in FIG. 2 is powered on or rebooted. This operation is called DAD (Duplicate Address Detection). Hereinafter, the processing contents until the node 300 finishes the DAD will be described along the flow of FIG.
[0038]
After the power of the node 300 is turned on or rebooted in step S801, first, the interface ID (see FIG. 5) is obtained from the Ethernet (MAC) address (MAC address) (see FIG. 4) assigned to the interface 301. It is created and used as a tentative link-local address (see FIG. 6) (step S802).
[0039]
Next, the node (host) 300 performs the following processing to determine whether the tentative link-local address is unique on the link.
[0040]
First, the interface 301 is initialized. That is, an all-nodes multicast address (FF02 :: 1) and a solicited-node multicast address of the tentative link-local address are assigned to the interface 301 (see FIG. 7). As a result, when the interface 301 finds a packet addressed to the all-nodes multicast address or a packet addressed to the committed-node multicast address of the tentative link-local address, the interface 301 receives it as a packet addressed to its own interface.
[0041]
Assigning the former (all-nodes multicast address) makes it possible to receive data from other nodes that are already using that tentative link-local address. In addition, by allocating the latter (a solicited-node multicast address of the tentative link-local address), it is possible to detect the presence of another node that is trying to use the same tentative link-local address at the same time.
[0042]
The solicited-node multicast address of a certain tentative link-local address is defined as the page 91 of RFC2461 and the lower 24 bits of the tentative link-local address are prefixed with FF02: 0: 0 as defined in page 91 of RFC2461. This is data added to FF00 :: / 104, which is link-local scope multicast address. 6 and 7 show the relationship between them. The above address assignment is step S803 in FIG.
[0043]
Next, a Neighbor Solicitation message is created. The target address (target address) of the Neighbor Solicitation message is a tentative link-local address to be determined, the IP source (source address) is unspecified address (the address of all 128 bits is 0), and the unspecified address (all 128 bits are 0). Set the targeted-link multi-address of the tentative link-local address to be determined.
[0044]
This Neighbor Solicitation message is transmitted to the Ethernet (R) (link) 207 by DupAddrDetectTransmits at an interval of TransTimer milliseconds. Step S804 in FIG. 8 is this processing.
[0045]
If the source address is unspecified address, the node that has received the Neighbor Solicitation message determines that the message is data from a node performing DAD.
[0046]
In the case where a plurality of nodes are performing DAD for the same address at the same time, a plurality of nodes to which a tentative link-local address of the "solicited-node multicast address" is assigned include a plurality of Neighboring Neighborhoods including the same address in the Target Address. (The Neighbor Solicitation message sent by itself and the Neighbor Solicitation message sent by another node performing DAD for the address at the same time). In that case, no node uses that address.
[0047]
If the received Neighbor Solicitation message is sent by itself (because a multicast packet is looped back), it indicates that there is another node that uses or intends to use it. Absent. When receiving Neighbor Solicitation messages including the same address in the Target Address in addition to the Neighbor Solicitation message sent by itself, it is determined that a plurality of nodes are simultaneously performing DAD for the same address.
[0048]
On the other hand, if the node that has received the Neighbor Solicitation message has already used the address included in the Target Address of the message, the target address is set to the Target Address (target address). -Return to nodes multicast address. Therefore, the node that sent the Neighbor Solicitation message receives an a multicast Neighbor Advertisement addressed to the all-nodes multicast address, and in the case where the target address is 8 in the case of the target of step 8 in the case where the target address is "8", the target address is "8". ) Indicates that the tentative address to be determined is not unique (that is, overlaps).
[0049]
As a result of the above DAD, it is confirmed that the tentative link-local address to be determined is unique on the link (in the case of “No” in step S805 of FIG. 8), the address is set as the link local address and the interface is used. Assign to 301. This is step S806 in FIG. Thus, the DAD is completed.
[0050]
The above-described operation of FIG. 8 is performed in such a manner that the default gateway 202, the DHCP server 203, the host 204, the host 205, and the host 206, which are the nodes connected to the link 207 of FIG. For 301, it can be performed.
[0051]
After allocating the link local address to the interface 301, the host in FIG. 2, for example, obtains information (referred to as Router Advertisement) necessary for determining the site local address and the global address from the default gateway 202. Try. This operation is shown in FIG.
[0052]
The default gateway 202 is usually called a router, and will be referred to as a router 202 below. The router 202 is set as required by an administrator, and periodically sends a Router Advertisement to the link 207. If the host 206 wants to obtain the Router Advertisement early, the host 206 sends data called Router Solicitation to the router 202. Since the host 206 does not know the existence of the router 202 immediately after assigning the link local address, the Router Solicitation is actually sent as a multicast to all the routers on the link 207. Step S901 in FIG. 9 shows this processing.
[0053]
The router 202 that has received the Router Solicitation sends a Router Advertisement. As shown in the case of “Yes” in step S902 in FIG. 9, the host 206 that has received the Router Advertisement message that specifies only the Stateless address autoconfiguration receives the validity of the prefix in the received message (already used by the device). Is confirmed, and an address created by adding an appropriate interface ID to them is set as a site local address or a global address and assigned to the interface 301. Step S903 in FIG. 9 is this processing.
[0054]
As shown in the case of “No” in step S902 of FIG. 9, when the host 206 does not receive the Router Advertisement that specifies only the stateless address autoconfiguration, the following two cases are performed. If a Router Advertisement that specifies both Stateless address autoconfiguration and stateful address autoconfiguration is received (Yes in step S904), and if Router Advertisement is not received in step S904, then step S90 is not received. In the latter case, stateful address autoconfiguration, that is, only DHCPv6 is executed. This is step S906, the details of which are shown in FIG.
[0055]
Necessary settings are made for the DHCP server 203 by an administrator. Specifically, its own link local address is assigned to the network interface 301 as a node, and a prefix or the like for a site local address or a global address necessary for acting as a DHCP server is set.
[0056]
In step S1001 of FIG. 10, the host 206 sends a DHCP Solicit Message to the DHCP server. Since the host 206 does not know where the DHCP server 203 exists, the host 206 sends the multicast to the link 207 as a multicast to the DHCP server 203. When the DHCP server 203 is located on a link (not shown) different from the link 207 to which the host 206 is connected, the DHCP Solicit Message is actually relayed by a DHCP relay (not shown) and reaches the DHCP server 203. .
[0057]
The DHCP server 203 that has received the DHCP Solicit Message returns a DHCP Advertise Message to the host 206 as a response to the DHCP Solicit Message. This reaches the host 206 (relayed by a DHCP relay in the case of another link). This is step S1002. At this point, the host 206 knows the address of the DHCP server 203.
[0058]
Next, the host 206 sends a DHCP Request Message to the DHCP server 203 in step S1003. Upon receiving the DHCP Request Message, the DHCP server 203 sends a DHCP Reply Message to the host 206.
[0059]
The host 206, which has received the DHCP Reply Message in step S1004, determines a site local address or a global address therefrom, and performs processing necessary for the DAD processing in order to confirm whether or not the interface ID in the address is duplicated. Perform That is, similarly to step S803, a multicast address or the like is set to the interface 301. This is step S1005.
[0060]
Next, the same Neighbor Solicitation Message as in step S804 is sent in step S1006, and it is determined in step S1007 whether or not a Neighbor Advertisement Message is received. If received, the address is duplicated, so the process returns to step S1003 to receive another address from the DHCP server 203, and the same processing is repeated.
[0061]
If the host 206 does not receive the Neighbor Advertisement Message in step S1007 of FIG. 10, the address is not duplicated, and the host 206 assigns the site local address or global address determined from the DHCP Reply Message to the interface 301 in step S1008.
[0062]
This is the end of step S906 in FIG. If no Router Advertisement is received in step S904, the process ends normally.
[0063]
If a Router Advertisement message that specifies both stateless address autoconfiguration and stateful address autoconfiguration is received in step S904, stateless authentication in both step S905 is performed. The processing content is the same as steps S903 and S906.
[0064]
As described above, the host 206 having the Ethernet (R) 207 as an interface can apply the stateless address autoconfiguration and the stateful addressautoconfiguration (DHCPv6) in an arbitrary combination to form a link local address, a site local address, a global address, a default gateway, and the like. Can be set automatically.
[0065]
In the above protocol, using a random value for the interface ID, performing DAD on the value, and confirming the uniqueness of the link 207, the prefix of the global address obtained from the gateway 202 or the DHCP server 203 is obtained. A single use IPv6 global address can be used in combination. The details are described in RFC3041 {Privacy Extensions for Stateless Address Autoconfiguration in IPv6, ″.
[0066]
Next, an embodiment of the present invention will be described. A protocol for extending the above-described operation (protocol) to enable use of a disposable anonymous public key certificate will be described. First, an example of an anonymous public key certificate will be described, and then a protocol for efficiently issuing the certificate will be described.
[0067]
Anonymous public key certificate, the academic Kazuomi Oishi, Masahiro Mambo, Eiji Okamoto, `` Anonymous Public Key Certificates and their Applications '' IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, E81-A, 1, pp . 56-64, 1998, the concept and a concrete realization method are proposed, and the basic realization method is also disclosed in US Pat. No. 6,154,841. In these schemes, the anonymity of the user of the certificate was kept computationally complex. As a method of providing stronger anonymity, a method of realizing an anonymous public key certificate having informational anonymity is described in Kazuomi Oishi, @Unconditionally anonymous public key certificates, '' The 2000 Symposium ryptography Society, SCIS2000-C32, 2000.
[0068]
In the present invention, any method described in the above-mentioned papers, Kazuomi Oishi, Masahiro Mambo, Eiji Okamoto, {Anonymous Public Key Certificates and their Applications} can be used. If the inefficiency can be tolerated, it is also possible to use Scheme 1, Scheme 2, and Scheme 3 in the above-mentioned paper, which are also included in the present invention. In the present embodiment, an embodiment using an anonymous public key certificate system having computational anonymity will be described. For details, reference is made to the above-mentioned document. The protocol of the present embodiment will be described after defining and introducing necessary symbols and the like for the sake of explanation.
[0069]
The entity CA that issues the anonymous public key certificate determines large prime numbers p and q as common parameters. q divides p-1. A generator g of the order q and a hash function H are determined. A secret random number s_ca (1 or more and q or less) is generated, and v_ca = g ＾ (s_ca) mod p is calculated. Here, A = (B) ＾ (C) mod D represents a calculation in which a value obtained by raising B to the power C is divided by D with respect to the integers A, B, C, and D, and the remainder is A. The entity CA publishes p, q, g, H, and v_ca. On the other hand, the entity i using the anonymous public key certificate generates a secret random number s_i (1 or more and q or less) and calculates v_i = g ＾ (s_i) mod p.
[0070]
s_ca and s_i are called a secret key, v_ca and v_i (and public parameters) are called a public key, and the secret key is managed so that it cannot be known to anyone except yourself.
[0071]
When starting using the anonymous public key certificate, the entity i registers its own entity name (user name), password, and public key v_i in the entity CA. The entity CA confirms the identity of the entity i by physical means or the like as necessary, and stores the presented entity name (user name), password, and public key v_i.
[0072]
When issuing an anonymous public key certificate, the entity CA generates a random number r (1 or more and q or less), and (g ′, v_i ′) = (g ＾ r mod p, (v_i) ＾ (r) mod p ) Is calculated. The above-mentioned public parameters, the expiration date of this anonymous public key certificate, and the management and attribute information of a certificate such as a public key certificate (described later) for the public key v_ca are X, and (g ′, v_i ′) Generate a digital signature for (the hash value of) the message containing X. A digital signature scheme based on the discrete logarithm problem, for example, a Schnorr signature scheme can be used. Here, a secret key s_ca is used. This digital signature is referred to as Sig_ca (g ′, v_i ′, X).
[0073]
The anonymous public key certificate APC_ca (i) issued by the entity CA to the entity i is APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)).
[0074]
The entity i to which the anonymous public key certificate APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) is issued, (g ′, v_i ′, X) ) And compute its hash value (eg, H (g ′ | v_i ′ | X), where | indicates concatenation), and Sig_ca (g ′, v_i ′, X) is the correct digital signature for the hash value. Whether or not there is is confirmed using the public key v_ca. Also check v_i ′ = (g ′) ＾ (s_i) mod p. If they can be confirmed to be correct, public key cryptography or digital signature based on the discrete logarithm problem can be used with g ′ and v_i ′ (and common parameter p) as public keys and s_i as a secret key. As described above, the anonymous public key certificate APC_ca (i) includes an expiration date in the management / attribute information X, and the public keys g ′ and v_i ′ included in the anonymous public key certificate APC_ca (i) are the same. Is the public key of the entity i, which is changed over time.
[0075]
The entity which has received the anonymous public key certificate APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) extracts (g ′, v_i ′, X) from the entity , And calculates the hash value, and confirms using the public key v_ca whether Sig_ca (g ′, v_i ′, X) is a correct digital signature for the hash value. If it is confirmed that it is correct, the public key encryption and the digital signature verification based on the discrete logarithm problem are performed using the public keys g ′ and v_i ′ (and the common parameter p).
[0076]
The validity of the public key v_ca itself is confirmed by submitting the public key v_ca to a higher or more widespread entity CA, for example, VeriSign providing a commercial authentication service, and checking the public key v_ca. If you have a public key certificate issued, you can use it to confirm. The management / attribute information X of the anonymous public key certificate includes the public key certificate for the public key v_ca. Using the public key certificate for the public key v_ca, the validity of the public key v_ca itself can be confirmed. This corresponds to constructing the entity CA hierarchically, and can configure a proper PKI (Public-key Infrastructure).
[0077]
In the above description, the signature scheme based on the difficulty of the discrete logarithm problem on the multiplicative group (mod p) has been described. However, a signature scheme based on the difficulty of the discrete logarithm problem on an elliptic curve can be applied. In that case, the same degree of security can be expected with a key having a smaller number of bits than in the case of the multiplicative group, so that the efficiency is higher.
[0078]
A case where the above anonymous public key certificate method is applied to the environment of FIG. 2 will be described.
[0079]
The default gateway 202 or the DHCP server 203 becomes the entity CA that issues the anonymous public key certificate, and the host 206 (or the user who uses it) becomes the entity i that uses the anonymous public key certificate. Alternatively, it is also possible to provide a dedicated CA server that is solely responsible for issuing certificates. In the following, an example will be described in which the default gateway 202 is an entity CA that issues an anonymous public key certificate, and a random IPv6 address is included in the certificate. May be used as the entity CA that issues the certificate, and a random IPv6 address may not be included in the certificate. Here, the default gateway 202 provides the host 206 with the prefix of the IPv6 global address. As described above, the default gateway 202 is often referred to as a router 202 because it is often a router.
[0080]
The administrator of the router 202 determines and publishes the public parameters p and g described above. A public key v_ca as an entity CA that issues an anonymous public key certificate is determined and submitted to a higher-ranking or more widespread CA (209 in FIG. 2), such as VeriSign, which provides a commercial authentication service. Then, a public key certificate for the public key v_ca is issued.
[0081]
The router (gateway) 202 has a role of controlling the transfer of packets, and is operated under the responsibility of an administrator so that inappropriate packets do not enter and exit between the subnet under the control of the router and the outside. In order for a subnet to be connected to the Internet, the administrator of the subnet registers his / her identity with JPNIC (in the case of Japan) and receives an IP address. Therefore, routers in the subnet are expected to have clear management responsibilities and to be costly to operate and manage while taking security into consideration, so they are responsible for the function of the entity CA that issues anonymous public key certificates. It is thought to be suitable to make.
[0082]
When the user i applies for access to the LAN, the user i generates his / her private key s_i using the publicly available parameters p, g, and the like, calculates the corresponding public key v_i, and obtains a user name and a password. The public key v_i is submitted to the LAN administrator (the administrator of the router 202). The LAN administrator (the administrator of the router 202) confirms the identity of the user i, checks the password, and the like in accordance with the operation policy, and permits access. The administrator registers the public key v_i in the RAM 304 or the HD 306 so that the corresponding public key v_i can be searched based on the entity name. It is assumed that the user i manages the public parameters p, g, and the like, and the public key v_i, particularly the secret key s_i, and makes it available to the host 206 safely.
[0083]
FIG. 1 shows a protocol according to the present embodiment, which is executed after the above preparations are made. FIG. 1 shows an entity using an anonymous public key certificate (an IPv6 terminal used by a user i) as a host 206 and a CA issuing an anonymous public key certificate as a router 202, and an anonymous public key certificate performed between them. Is an issuance protocol. That is, the IPv6-capable device 202 existing in the local link 207 where the IPv6-capable device 206 is located is operated as a public key certificate issuer.
[0084]
Since it is necessary to identify an entity in order to issue an anonymous public key certificate, some identification (authentication) protocol is executed between the router 202 and the entity (in this case, the host 206). In the present embodiment, a method based on the following public key cryptosystem will be described as an example. The operation will be described along the flow of FIG.
[0085]
The host 206 generates a Certificate Solicitation in step S101. The Certificate Solicitation is a message requesting an anonymous public key certificate, and is generated in a format that allows the router 202 to understand that the request is for an anonymous public key certificate and that the data includes an interface ID of the host 206. The content is calculated from the entity name (user name), password and serial number. The serial number is, for example, a value obtained by concatenating the IPv6 link local address of the host 206, the IPv6 link local address of the default gateway 202, and the time at that time into one data. In order to prevent a retransmission attack and spoofing, a digital signature (authentication signature) (Sig_i (hash ( Entity name, password, serial number))) are included in Certificate Solicitation.
[0086]
Next, the host 206 sends the Certificate Solicitation to the router 202 via the link 207 in step S102.
[0087]
In step S103, the router 202 searches the RAM 305 or the HD 306 for the public key v_i registered from the entity name (identifier of the communication device (host) 206) included in the Certificate Solicitation received in step S102, and performs authentication using the public key v_i. Confirm the validity of the signature for use. Specifically, an entity name (user name), a password, and a serial number are input to a hash function, a hash value thereof is obtained, and it is confirmed by the public key v_i that the authentication signature is a correct digital signature for the signature.
[0088]
If the authentication is successful, an IPv6 global address is generated from the prefix of the IPv6 global address assigned to the router 202 and the interface ID of the host 206, and an anonymous public key certificate including its lifetime (expiration date, for example, 24 hours). A letter APC_ca (i) is created. Specifically, the certificate management / attribute information X in APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) described above contains an IPv6 global address or Lifetime etc. are included. The lifetime (expiration date) of the IPv6 global address and the expiration date of the anonymous public key certificate are not always the same.
[0089]
Then, in step S104, the router 202 sends a Certificate Advertisement including the prefix of the IPv6 global address, the address of the default router 202, and the anonymous public key certificate APC_ca (i) to the authenticated host 206 via the link 207. In one embodiment of the present invention, the certificate advertisement is encrypted using a registered public key and transmitted.
[0090]
In step S105, the host 206 extracts the prefix from the received Certificate Advertisement, adds an interface ID, generates an IPv6 global address, and checks the validity of the anonymous public key certificate APC_ca (i). As described above, the anonymous public key certificate APC_ca (i) includes an expiration date in the management / attribute information X, and the public keys g ′ and v_i ′ included in the anonymous public key certificate APC_ca (i) are the same. Is the public key of the entity i (host 206), but is changed over time. The host 206 executes the anonymous public key issuance protocol of FIG. 1 every time the communication partner changes, each time the session changes, or each time a communication packet is transmitted, and obtains the public keys g ′ and v_i ′ to be used. change.
[0091]
FIG. 11 shows an operation flowchart of a host of an extended protocol in which the above protocol is combined with the existing transmission and reception protocols of Router Solicitation and Router Advertisement.
[0092]
In step S1101 of FIG. 11, the host 206 transmits a Router Certificate Solicitation Message, which is data including both the Router Solicitation Message sent in step 901 of FIG. 9 and the Certificate Solicitation sent in step S102 of FIG. Send.
[0093]
Also, in step S1102, a Router AdvertisementMessage, which is data containing both Router Advertisement Message received in step S902 in FIG. 9 and Certificate Advertisement received in step S104 in FIG. 1, is received.
[0094]
If the Router Certificate Advertisement Message is received via the link 207, that is, if “Yes” in step S1102, the host 206 proceeds to step S1103, similar to step S903 in FIG. 9, in the Router Advertisement Message in the Router Advertisement Message. Is assigned to the interface 301 as a site-local address or a global address, and an anonymous public key certificate APC_ca including the public keys g ′ and v_i ′ is performed by performing step S105 in FIG. Obtain (i).
[0095]
According to the above protocol, a disposable anonymous public key certificate corresponding to a disposable IPv6 address can be issued to the host 206 simply by increasing data without changing the number of steps of the conventional protocol.
[0096]
When the DHCP server 203 plays the role of the entity CA that issues the anonymous public key certificate instead of the router 202, the same protocol as that in FIG. 1 is executed in step S1106 in FIG. Here, the DHCP server 203 provides the host 206 with the prefix of the global address. In this case, in step S1106 in FIG. 11, the host executes an extended protocol of stateful address autoconfiguration, that is, a protocol for acquiring an address and a certificate from a DHCP server. FIG. 12 shows a flowchart of the operation.
[0097]
The difference from the protocol of FIG. 10 lies in two places: step S1203 and step S1204.
[0098]
In step S1203, data including both the DHCP Request Message sent in step S1003 in FIG. 10 and the data corresponding to the Certificate Solicitation sent in step S102 in FIG. 1 (except that the CA is the DHCP server 203 instead of the router 202) is used. Send a DHCP Certificate Request Message via link 207.
[0099]
Upon receiving the DHCP Certificate Request Message, the DHCP server 203 generates a DHCP Certificate Reply Message, and sends the generated DHCP Certificate Reply Message via the link 207. Here, the DHCP server 203 generates the anonymous public key certificate APC_ca (i) as in S103 of FIG. 1, and prefixes the global address of the DHCP server 203, the address of the DHCP server 203, and the anonymous public key certificate APC_ca. The data corresponding to the Certificate Advertisement (i) and the DHCP Reply Message of step S1004 in FIG. 1 are included in the DHCP Certificate Reply Message.
[0100]
In step S1204, the host 206 receives the DHCP Certificate Reply Message. This DHCP Certificate Reply Message is the DHCP Reply Message received in step S1004 in FIG. 10 and the data corresponding to the Certificate Advertisement received in step S104 in FIG. 1 (the difference is that the CA is not a router but a DHCP server). is there. Therefore, the site local address or the global address is determined from the DHCP Reply Message, and the anonymous public key certificate APC_ca (i) including the public keys g ′ and v_i ′ is obtained.
[0101]
According to the above protocol, a disposable anonymous public key certificate corresponding to a disposable IPv6 address can be issued to the host 206 simply by increasing data without changing the number of steps of the conventional protocol.
[0102]
In the case where both the router 202 and the DHCP server 203 perform the role of CA, this corresponds to the case where a Router Certificate Advertisement Message specifying both stateless and stateful is received in step S1104 in FIG. 11 (in the case of “Yes”), Automatic setting and acquisition of link local address, site local address, disposable IPv6 global address and corresponding disposable anonymous public key certificate, default gateway, etc. by applying the above two extended protocols in any combination. Can be. In this case, the router 202 and the DHCP server 203 correspond to a communication device group that provides a public key certificate.
[0103]
The host 206 executes the protocol for receiving the anonymous public key certificate shown in FIG. 11 every time the communication partner changes, each time the session changes, or each time a communication packet is transmitted, and uses the public key g to be used. 'And v_i' are changed.
[0104]
Although the DHCP server 203 provides a form in which the IPv6 address prefix is provided to the host 206, the form in which the IPv6 address itself is provided eliminates the point that the address is sent instead of the prefix and the host does not need to generate the address. Others are realized by the same protocol except for the following.
[0105]
(Second embodiment)
In the first embodiment, a default gateway (router) / CA authenticates the host, and then sends a Certificate Advertisement including an anonymous public key certificate and a prefix to the host. In the present embodiment, an example will be described in which the transmission of the prefix and the issuance of the anonymous public key certificate are independent.
[0106]
As in the first embodiment, the default gateway 202 or the DHCP server 203 is an entity CA that issues an anonymous public key certificate, and the host 206 (or a user using the same) uses the anonymous public key certificate. Let it be entity i. Alternatively, it is also possible to provide a dedicated CA server that is solely responsible for issuing certificates. In the following, an example will be described in which the default gateway 202 is an entity CA that issues an anonymous public key certificate, and a random IPv6 address is included in the certificate. May be used as the entity CA that issues the certificate, and a random IPv6 address may not be included in the certificate. Here, the default gateway 202 provides the host 206 with the prefix of the IPv6 global address. As described above, the default gateway 202 is often referred to as a router 202 because it is often a router.
[0107]
The administrator of the router 202 determines and publishes the public parameters p and g described above. A public key v_ca as an entity CA that issues an anonymous public key certificate is determined and submitted to a higher-ranking or more widespread CA (209 in FIG. 2), such as VeriSign, which provides a commercial authentication service. Then, a public key certificate for the public key v_ca is issued.
[0108]
When the user i applies for access to the LAN, the user i generates his / her private key s_i using the publicly available parameters p, g, and the like, calculates the corresponding public key v_i, and obtains a user name and a password. The public key v_i is submitted to the LAN administrator (the administrator of the router 202). The LAN administrator (the administrator of the router 202) confirms the identity of the user i, checks the password, and the like in accordance with the operation policy, and permits access. The administrator registers the public key v_i in the RAM 304 or the HD 306 so that the corresponding public key v_i can be searched based on the entity name. It is assumed that the user i manages the public parameters p, g, and the like, and the public key v_i, particularly the secret key s_i, and the host i can safely use it.
[0109]
FIG. 15 shows a protocol according to the present embodiment, which is executed after the above preparations are made. FIG. 15 shows an entity using an anonymous public key certificate (IPv6 terminal used by user i) as a host 206 and a CA that is an IPv6 terminal providing a prefix and issuing an anonymous public key certificate as a default gateway 202. 2 shows an operation flow of an anonymous public key certificate issuance protocol performed between the two. That is, the IPv6-capable device 202 existing in the local link 207 where the IPv6-capable device 206 is located is operated as a public key certificate issuer.
[0110]
Since it is necessary to identify an entity in order to issue an anonymous public key certificate, some identification (authentication) protocol is executed between the router 202 and the entity (in this case, the host 206). In the present embodiment, a method based on the following public key cryptosystem will be described as an example. The operation will be described with reference to FIG.
[0111]
When the host 206 is powered on or rebooted, it generates an interface ID from the MAC address of the network interface (301 in FIG. 3). Further, the host 206 generates a random interface ID by, for example, an algorithm of RFC3041. Then, it generates a link local address in which a predetermined prefix is added to the interface ID generated from the MAC address, and sends a Router Solicitation (RS) to the router (step S1501). The RS is a multicast for all routers on the link as described above.
[0112]
Upon receiving the RS, the router 202 sends a Router Advertisement (RA) (step S1502).
[0113]
The host 206 that has received the RA extracts a prefix included in the RA, and generates a global address (called a public address) from the interface ID generated from the MAC address and the extracted prefix. Also, a disposable IPv6 address (referred to as temporary address) is created from the random interface ID and the extracted prefix. Then, a duplicate address DAD (Duplicate Address Detection) of the public address and the temporary address is performed, the uniqueness of the address in the link is confirmed, and the address is assigned to the interface (step S1503).
[0114]
Next, the host 206 generates a Certificate Solicitation (step S1504). The Certificate Solicitation is a message requesting an anonymous public key certificate, and is generated in a format that allows the router 202 to understand that the host 206 requests the anonymous public key certificate. For example, PKCS # 10 defined in RFC 2986, @PKCS # 10: Certification Request Syntax Specification Version 1.7, '' and RFC2511, @Internet X. 509 Certificate Request Message Format '' and the like define their formats. Although the detailed description of the format is omitted, it is assumed that the Certificate Solicitation is data including a certificate request message and a signature (of the host) for the message.
[0115]
Next, the host 206 sends the Certificate Solicitation to the router 202 via the link 207 (step S1505). At this time, since the host 206 knows the (unicast) address of the router 202, it is possible to perform a unicast.
[0116]
The router 202 searches the RAM 305 or the HD 306 for the public key v_i registered from the entity name (identifier of the host 206 or the name of the user using the host 206) included in the Certificate Solicitation received in step S1505, and uses it. To confirm the validity of the signature. If the confirmation is successful, an anonymous public key certificate APC_ca (i) of the host 206 is created. Specifically, the certificate management / attribute information X in APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) described above contains an IPv6 global address or A life time and the like are included (step S1506).
[0117]
Then, the router 202 sends a Certificate Advertisement including the anonymous public key certificate APC_ca (i) to the authenticated host 206 via the link 207 (step S1507). In one embodiment of the present invention, the certificate advertisement is encrypted using a registered public key and transmitted. At this time, it can be sent as a unicast addressed to the temporary address.
[0118]
The host 206 confirms the validity of the anonymous public key certificate APC_ca (i) from the received Certificate Advertisement (step S1508).
[0119]
FIG. 17 shows an operation flowchart of the host of the extended protocol in which the above-described protocol is combined with the existing stateless address autoconfiguration and stateful address autoconfiguration.
[0120]
When the host 206 is powered on or rebooted, it generates an interface ID from the MAC address of the network interface (301 in FIG. 3). Further, the host 206 generates a random interface ID by, for example, an algorithm of RFC3041. Then, it generates a link local address in which a predetermined prefix is added to the interface ID generated from the MAC address, and sends a Router Solicitation (RS) to the router (step S1701). The RS is a multicast for all routers on the link as described above.
[0121]
As shown in the case of “Yes” in step S1702, the host 206 that has received the Router Advertisement message (RA) that specifies only the Stateless address autoconfiguration extracts the prefix included in the RA, and extracts the interface ID and the interface ID generated from the MAC address. A global address (called a public address) is generated from the extracted prefix. Also, a disposable IPv6 address (referred to as temporary address) is created from the random interface ID and the extracted prefix.
[0122]
Then, a duplicate address DAD (Duplicate Address Detection) of the public address and the temporary address is performed, the uniqueness of the address on the link is confirmed, and those addresses are assigned to the interface (step S1703).
[0123]
Next, the host 206 executes a certificate request and a certificate issuing protocol (step S1707). In other words, the host 206 generates Certificate Solicitation and sends it to the router 202 as shown in steps S1504 and S1505 in FIG. The host 206 receives the Certificate Advertisement from the router 202 and checks the validity of the anonymous public key certificate APC_ca (i) included therein.
[0124]
If no Router Advertisement is received (No in step S1704), only stateful address autoconfiguration, that is, only DHCPv6 is executed. This is step S1706, the details of which are the same as in the protocol of FIG.
[0125]
In step S1704, if a Router Advertisement message that specifies both status address autoconfiguration and stateful address autoconfiguration is received, both step S1705 and stateless authorization coordination are performed in step S1705. The processing contents are the same as those in steps S1703 and S1706.
[0126]
In the above description, the default gateway 202 (router) also serves as the CA. However, in general, the default gateway (router) and the CA are not necessarily the same as the IPv6 device. FIG. 16 shows an operation flow in the case where the default gateway (router) and the CA are different IPv6 devices.
[0127]
The administrator of the CA determines and publishes the public parameters p, g, and the like described above. A public key v_ca as an entity CA that issues an anonymous public key certificate is determined and submitted to a higher-ranking or more widespread CA (209 in FIG. 2), such as VeriSign, which provides a commercial authentication service. Then, a public key certificate for the public key v_ca is issued.
[0128]
When the user i applies for access to the LAN, the user i generates his / her private key s_i using the publicly available parameters p, g, and the like, calculates the corresponding public key v_i, and obtains a user name and a password. Submit the public key v_i to the CA administrator. The CA administrator confirms the identity of the user i, checks the password, and the like according to the operation policy, and permits access. The administrator registers the public key v_i in the RAM 304 or the HD 306 so that the corresponding public key v_i can be searched based on the entity name. It is assumed that the user i manages the public parameters p, g, and the like, and the public key v_i, particularly the secret key s_i, and the host i can safely use it.
[0129]
Note that the administrator of the default gateway (router) 202 and the administrator of the CA may or may not be the same. In FIG. 16, it is assumed that the default gateway 202 (router) and the CA are different IPv6 devices, and the default gateway 202 is set to the IPv6 address of the CA.
[0130]
When the host 206 is powered on or rebooted, it generates an interface ID from the MAC address of the network interface (301 in FIG. 3). Further, the host 206 generates a random interface ID by, for example, an algorithm of RFC3041. As described above, a link local address is generated, and a Router Solicitation extension (RS extension) is sent to the router (step S1601). The RS extension is information in which a message requesting the address of the CA is added to the Router Solicitation, and is a multicast that is addressed to all routers on the link as in the case of the RA.
[0131]
Upon receiving the RS extension, the router 202 sends a Router Advertisement extension (RA extension) (step S1602). RA extension is information in which the address of a CA is added to Router Advertisement.
[0132]
The host 206 that has received the RA extension extracts the prefix included in the RA, and generates a global address (public address) from the interface ID and the prefix generated from the MAC address. Further, a disposable IPv6 address (referred to as a temporary address) is created from the random interface ID and the prefix. Then, a duplicate address DAD (Duplicate Address Detection) of the public address and the temporary address is performed, the uniqueness of the address in the link is confirmed, and those addresses are assigned to the interface. The address of the CA is extracted from the RA extension (step S1603).
[0133]
Next, the host 206 generates a Certificate Solicitation (step S1604), and sends the Certificate Solicitation to the CA (step S1605).
[0134]
The CA searches the RAM 305 or the HD 306 for the registered public key v_i from the entity name (identifier of the communication device (host) 206) included in the Certificate Solicitation received in step S1605, and uses it to confirm the validity of the signature. . If the confirmation is successful, an anonymous public key certificate APC_ca (i) of the host 206 is created. Specifically, the certificate management / attribute information X in APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) described above contains an IPv6 global address or A life time and the like are included (step S1606).
[0135]
Then, the CA sends a Certificate Advertisement including the anonymous public key certificate APC_ca (i) to the host 206 (Step S1607). In one embodiment of the present invention, the certificate advertisement is encrypted using a registered public key and transmitted.
[0136]
The host 206 checks the validity of the anonymous public key certificate APC_ca (i) from the received Certificate Advertisement (step S1608).
[0137]
The operation flowchart of the host of the extended protocol in which the above protocol is combined with the existing stateless address autoconfiguration and stateful address autoconfiguration is almost the same as that of FIG. 17, but differs in the following two points. That is, in step S1701, a Router Solicitation extension message is sent instead of the Router Solicitation Message. Also, in step S1707, the protocol shown in FIG. 16 is executed as the protocol for the certificate request and the certificate issuance.
[0138]
(Third embodiment)
In this embodiment, a mode in which a host connects to the Internet by a method such as dial-up or ADSL will be described. First, the present situation will be described, and then embodiments of the present invention will be described.
[0139]
FIG. 14 schematically shows a connection environment to which the present invention is applied. FIG. 14 illustrates an environment in which the host 1406 accesses the Internet 1401 provided by an ISP (Internet Service Provider) via a PSTN (Public Switched Telephone Network). In this embodiment, the ISP and the host 1401 are connected by a PPP link.
[0140]
In FIG. 14, a PPP peer 1402 of the ISP is a node, and accepts a request for a PPP connection from the host 1406 via the PSTN 1404 using the modem 1403. The host 1406 uses the mode 1405 to access the PPP peer 1402 via a PPP connection. The configuration of the host 1406 is the same as that of FIG. 3, and a modem 1405 is connected via the network interface 301. Also, the configuration of the PPP peer 1402 is the same as that of FIG. 3. The modem 1403 is connected via the network interface 301, and the Internet 1401 is connected via the network interface 302. As shown in FIG. 14, the PPP peer 1402 functions as a default gateway module 14021, a DHCP module 14022, and an Authentication module 14023. When the host 1406 communicates with the PPP peer 1402, the host 1406 performs communication via the modem 1405, and the PPP peer 1402 performs communication via the modem 1403.
[0141]
In the present embodiment, description will be made taking modem and PSTN as an example, but TA (Terminal Adapter) and ISDN (Integrated Services Digital Network), PHS communication adapter and PHS communication network, dedicated line connection device and dedicated line, and the like. This is essentially the same as long as it is an environment where a PPP connection can be established even if the communication mode is the above. Details of the PPP connection are described in RFC 1661 {The Point-to-Point Protocol (PPP) ″.
[0142]
The host 1406 transmits a PPP connection request to the PPP peer 1402 via the modem 1405, PSTN 1404, and modem 1403. The PPP peer 1402 receives the connection request, and the Authentication module 14023 authenticates the host. A typical authentication method is an authentication protocol CHAP based on a user name and a password, which is described in detail in RFC 1994 {PPP Challenge Handshake Authentication Protocol}.
[0143]
When the authentication is completed, the DHCP module 14022 transmits the prefix of the IPv6 global address, the IPv6 address of the default gateway, and the like to the host 1406 according to the setting. In the DHCP module 14022, the administrator of the ISP makes settings according to the operation policy.
[0144]
In FIG. 14, for simplicity of explanation, the default gateway, the DHCP server, and the Authentication server are respectively the default gateway module 14021, the DHCP module 14022, and the Authentication module 14023. There may be different nodes on 1407 respectively. In any of the embodiments, the modules or nodes may be operated safely under the control of the administrator of the ISP. Therefore, the host 1406 and the PPP peer 1402 in the form of FIG. The description will be made assuming that the PPP link between them has been established.
[0145]
When the host 1406 receives the prefix of the IPv6 global address, the IPv6 address of the default gateway, and the like from the DHCP module 14022, the host 1406 combines the prefix of the IPv6 global address with its own random interface ID (generated by a method such as RFC3041). Then, it generates a random IPv6 global address, confirms that it is not duplicated on the link, assigns it to the interface 301, and stores the default gateway IPv6 address.
[0146]
With the above operation, the host 1406 can communicate with any other party on the Internet using the disposable IPv6 address.
[0147]
Next, an embodiment of the present invention will be described. A protocol for extending the above-described operation (protocol) to enable use of a disposable anonymous public key certificate will be described.
[0148]
Hereinafter, a case will be described in which the anonymous public key certificate method is applied to the environment of FIG. The CA that the PPP peer 1402 issues the anonymous public key certificate becomes, and the host 1406 (or a user using it) becomes the entity i that uses the anonymous public key certificate. In the following, a form in which a random IPv6 address is included in the certificate will be described, but it is also possible to exclude a random IPv6 address.
[0149]
The ISP determines and publishes the public parameters p and g described above. Determines its own public key v_ca and submits it to a higher or more widespread CA (1408 in FIG. 14), such as VeriSign, which provides a commercial authentication service, and issues a public key certificate for v_ca do that for me.
[0150]
When a user i applies for a subscription to the ISP, his / her own secret key s_i is generated using the parameters p, g, etc. published by the ISP, a corresponding public key v_i is calculated, and a user name and a password are obtained. , Submit the public key v_i to the ISP. The administrator of the ISP (the administrator of the PPP peer 1402) confirms the identity of the user i, checks the password, and the like according to the operation policy, and permits access. The administrator registers the public key v_i in the RAM 305 or the HD 306 so that the public key v_i can be searched for in correspondence with the user name. It is assumed that the public parameter and the public key v_i, particularly the secret key s_i, are managed by the user i and can be used safely by the host 1406.
[0151]
FIG. 13 shows the protocol of the present embodiment, which is executed after the above preparations have been made. FIG. 13 shows a protocol for issuing an anonymous public key certificate performed between an entity (an IPv6 terminal used by a user i) as a host 1406 and a CA for issuing an anonymous public key certificate as a PPP peer 1402.
[0152]
After the processing of the data link layer in the PPP connection is completed, as described above, the PPP peer 1402 that has received the request for the PPP connection from the host 1406 uses the Authentication module 14023 to perform authentication based on the user name (identifier) and the password. The host is authenticated by the protocol CHAP.
[0153]
That is, the host 1406 sends the entity name (user name) to the PPP peer 1402 in step S1301. In step S1302, the PPP peer 1402 generates a CHAP-challenge, and sends it to the host 1406 in step S1303.
[0154]
In step S1304, the host 1406 inputs the entity name, the password, and the CHAP-challenge into the hash function to obtain a CHAP-response, and sends the value of the CHAP-response obtained in step S1305 to the PPP peer 1402.
[0155]
In step S1306, the PPP peer 1402 checks the validity of the CHAP-response. If it can be confirmed, the authentication is successful, so the prefix of the IPv6 global address and the address of the default gateway are transmitted to the authenticated host 1406 in step S1307.
[0156]
The host 1406 generates an IPv6 global address from the prefix of the IPv6 global address and the random interface ID in step S1308, confirms that it is not duplicated, assigns it to the network interface 301, and assigns the default gateway to the default gateway. Is also stored. Next, Certificate Solicitation is sent as a message requesting an anonymous public key certificate in step S1309 to the PPP peer.
Send to 1402.
[0157]
Similar to the first embodiment, the Certificate Solicitation is generated in a format that allows the PPP peer 1402 to understand that the request includes the request for the anonymous public key certificate and the interface ID. The content is calculated from the entity name (user name), the password, and the serial number. The serial number is, for example, a link between the IPv6 link local address of the host 206, the IPv6 link local address of the default gateway, and the time at that time. It is a value that is converted into one data. The Certificate Solicitation includes a digital signature (authentication signature) generated for a value obtained by inputting an entity name (user name), a password, and a serial number to a hash function.
[0158]
The PPP peer 1402 searches the RAM 305 or the HD 306 for a registered public key v_i corresponding to the entity name (user name of the communication device (host) 206), and retrieves the anonymous public key certificate described in S103 of FIG. Is generated in step S1310. That is, an IPv6 global address is generated from the prefix of the IPv6 global address assigned to the PPP peer 1402 and the interface ID of the host 1406, and an anonymous public key certificate APC_ca (i) including its lifetime is created. Specifically, the certificate management / attribute information X in APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) described above contains an IPv6 global address or Lifetime etc. are included.
[0159]
Then, similar to S104 in FIG. 1, the certificate advertisement including the generated anonymous public key certificate APC_ca (i) and the like is sent to the host 1406 in step S1311. The host 1406 checks the validity of the received anonymous public key certificate APC_ca (i) in step S1312. As described above, the anonymous public key certificate APC_ca (i) includes an expiration date in the management / attribute information X, and the public keys g ′ and v_i ′ included in the anonymous public key certificate APC_ca (i) are the same. Is the public key of the entity i (host 1406), but is changed over time.
[0160]
In the above protocol, the data transmitted and received in steps S1305 and S1309 can be combined and transmitted in step S1305. Although not shown, in this case, the host 1406 sends the random interface ID, the CHAP-response in step S1305 in FIG. 13, and the Certificate Solicitation in step S1309 (similar to the first embodiment) to the PPP peer 1402 in step S1305 ′.
[0161]
Then, in step S1306 ′, the PPP peer 1402 confirms the validity of the CHAP-response, searches for the registered public key v_i, generates an IPv6 global address from the IPv6 prefix and the interface ID, and generates the IPv6 global address and its lifetime. Data including the expiration date (for example, 24 hours) is generated, and the anonymous public key certificate APC_ca (i) is generated. A Certificate Advertisement including the generated anonymous public key certificate APC_ca (i) is sent to the host 1406 in step S1307 ′.
[0162]
The host 1406 checks the validity of the received anonymous public key certificate APC_ca (i) in step S1308 '. In this step S1308 ', the processing up to the processing corresponding to step S1312 in FIG. 13 is completed, so that there are no subsequent steps.
[0163]
With the above protocol, the PPP peer 1402 issues the disposable anonymous public key certificate corresponding to the disposable IPv6 address to the host 1406.
[0164]
The host 1406 executes the anonymous public key certificate issuing protocol of FIG. 13 every time the communication partner changes, every time the session changes, or each time a communication packet is transmitted, and uses the public keys g ′ and v_i to be used. 'To change.
[0165]
In the above description, the case where the PPP Peer 1402 transmits the IPv6 prefix to the host 1406 and the host 1406 generates an IPv6 address from the IPv6 prefix and the interface ID has been described. However, the PPP Peer 1402 transmits the IPv6 address to the host 1406, and the host 1406 transmits the IPv6 address to the host 1406. The same protocol is used when is used. In this case, the same protocol is used except that an IPv6 address is sent instead of the IPv6 prefix in step S1307 of FIG. 3 and that the process of generating an IPv6 address from the prefix is not required in step S1308.
[0166]
(Fourth embodiment)
A mode in which IPsec communication is performed using the disposable IPv6 address and the disposable anonymous public key certificate issued in the first embodiment, the second embodiment, and the third embodiment will be described.
[0167]
First, a brief description will be given of an authentication method in a revised mode of encryption using public key cryptography of IKE (Internet Key Exchange) which is a protocol for securely sharing SA (Security Association) which is data such as secret data and mutual IPv6 addresses. Then, a method using an anonymous public key certificate will be described.
[0168]
The IKE is composed of two phases, and establishes a secure communication path in Phase 1, and in Phase 2, an SA used for communication such as IPsec is agreed using the secure communication path. Hereinafter, only Phase 1 will be described. Main mode and Aggressive mode exist in Phase 1 of IKE, but the description below is based on the pp. Of RFC2409 {The Internet Key Exchange (IKE) ″. 13-15, 5.3 Phase 1 Authenticated with a Revised mode of Public Key Encryption Main mode.
[0169]
In IKE, two communicating entities are called an Initiator and a Responder. The initiator starts communication. First, the initiator sends a plurality of SAs to the responder, and sends one SA determined to be usable by the responder to the initiator, thereby determining an SA for phase 1.
[0170]
The initiator generates a random number (called Nonce) and sends data encrypted with the responder's public key to the responder. The responder generates a random number, and sends data encrypted with the public key of the initiator to the initiator. As a result, each generated nonce can be shared, and an encryption key used in another communication is generated from the shared nonce. The details are described in RFC2409 “The Internet Key Exchange (IKE)”. As is apparent from the above description, it is necessary to know the public key of the communication partner prior to the IPsec communication.
[0171]
Consider the following situation. A user accesses a site on the Internet such as a shopping site. The user is, for example, the host 206 in the embodiment of FIG. 2, and is the host 1406 in the embodiment of FIG. In the embodiment of FIG. 2, the shopping site is connected to the user host 206 via the Internet 201 and the gateway 202. In the embodiment of FIG. 14, the shopping site is connected to the user host 1406 via the Internet 1401 and the PPP peer 1402. Connected. Before starting communication with a site such as the shopping site as a communication partner, the hosts 206 and 1406 obtain an Ipv6 address and a public key certificate including a public key by the above-described protocol. In this embodiment, a procedure for executing a key exchange / update / change protocol based on the above-mentioned public key certificate and performing encryption / authentication communication is performed.
[0172]
At this time, the user knows the IPv6 address (identifier) of the shopping site (whether explicit or implicit). When the user actually accesses the site and finds that the site is correct for the user, the user can explicitly know the address by confirming the IPv6 address of the communication partner. During communication, the shopping site knows the address (identifier) of the communication partner. The above communication can be performed using a disposable IPv6 address.
[0173]
In this embodiment, it is assumed that the disposable IPv6 address uses the same address (not updated) when the sender and receiver are determined. At this point, the disposable anonymous public key certificate APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) is sent to each other. Then, since the management / attribute information X in the disposable anonymous public key certificate APC_ca (i) includes the IPv6 global address, does the IPv6 address match the IPv6 address of the other party with whom communication is actually being performed? Confirming the validity of the disposable anonymous public key certificate and confirming the validity of the disposable anonymous public key certificate, it is possible to determine whether or not it is truly the disposable anonymous public key certificate of the communication partner, and the public key (g ′, v_i ′) can be confirmed whether it is really the public key of the communication partner.
[0174]
The validity of the disposable anonymous public key certificate can be confirmed as follows. The certificate management / attribute information X includes a public key v_ca of a CA (the router 202, the DHCP server 203, or the PPP peer 1402 described above) and a public key certificate corresponding to the public key v_ca (VeriSign, which provides a commercial authentication service, etc.). Issued by the company). The site can confirm whether or not the correspondence is correct by using a public key such as VeriSign, which provides a commercial authentication service (it is widely known and can be easily obtained). Using the verified validity v_ca, the validity of the disposable anonymous public key certificate APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)), that is, (g ', V_i') and Sig_ca (g ', v_i', X). The anonymous public key certificate APC_ca (i) includes an expiration date in its management / attribute information X, and the public keys g ′ and v_i ′ included in the anonymous public key certificate APC_ca (i) are associated with the same entity i. The public key is a public key that changes over time.
[0175]
The hosts 206 and 1406 execute the protocol of FIGS. 11 and 13 each time the communication partner changes (that is, each time a new connection is made to the site) or each time the session changes, and Update / change public keys g ′ and v_i ′. Note that the public keys g ′ and v_i ′ may be updated or changed every time a communication packet is transmitted.
[0176]
As described above, using the disposable IPv6 address and the disposable anonymous public key certificate including the same, the public key of the communication partner defined by the IPv6 address can be reliably obtained. By performing the IKE phase 1 Main mode using the public key thus exchanged, IPsec communication with the communication partner having the IPv6 address can be executed.
[0177]
That is, in the present embodiment, an IPv6-compatible device existing in a local link where an IPv6-compatible device is located is operated as a public key certificate issuer, and the IPv6 address is included in the disposable anonymous public key certificate, and the IPv6 address is used on the Internet. Two devices share secret data that no one else knows, and perform IPsec communication, which is a protocol for performing encryption and authentication based on the secret data. In IPsec, SA (such as secret data and each other's IPv6 address) is used. IKE (Internet Key Exchange), which is a protocol for securely sharing Security Association, is performed.
[0178]
Therefore, impersonation of the communication partner as described in the problem is prevented.
[0179]
【The invention's effect】
As described above, according to the invention relating to the present application, a disposable IPv6 address and a disposable anonymous public key certificate including the same can be realized.
[0180]
In addition, the load on the host for generating the anonymous public key can be reduced.
[0181]
Further, the degree of privacy protection is high, it can be realized at low cost, and a disposable anonymous public key certificate with a small load at the time of execution can be efficiently realized.
[0182]
In addition, strong privacy protection can be realized, and IPsec communication by IKE can be performed while preventing spoofing.
[Brief description of the drawings]
FIG. 1 is a diagram of an anonymous public key certificate issuing protocol (in the case of an Ethernet® LAN) according to a first embodiment.
FIG. 2 is a schematic diagram of an Ethernet® LAN.
FIG. 3 is a configuration diagram of a node.
FIG. 4 is a configuration diagram of a MAC address of Ethernet (R).
FIG. 5 is a configuration diagram of an interface ID.
FIG. 6 is a configuration diagram of a tentative link-local address.
FIG. 7 is a configuration diagram of a solicited-node multicast address of a certain tentative link-local address.
FIG. 8 is a flowchart illustrating an operation until the host finishes DAD.
FIG. 9 is a flowchart illustrating an operation until the host finishes automatic address setting.
FIG. 10 is an operation flowchart diagram until a host acquires an address by DHCP.
FIG. 11 is an operation flowchart from when a host performs automatic address setting to when an anonymous public key certificate is received.
FIG. 12 is an operation flowchart diagram until a host receives an address and an anonymous public key certificate by DHCP.
FIG. 13 is a diagram of an anonymous public key certificate issuing protocol (in the case of PPP) in the third embodiment.
FIG. 14 is a schematic diagram of a dial-up / ADSL connection.
FIG. 15 is a diagram of an anonymous public key certificate issuance protocol (in the case of an Ethernet (R) LAN) according to the second embodiment.
FIG. 16 is a diagram of a general form of an anonymous public key certificate issuing protocol.
FIG. 17 is an operation flowchart diagram until a host acquires a certificate.
[Explanation of symbols]
300 nodes
301 Network Interface
302 Network Interface
306 HD (hard disk)
308 Keyboard / Pointing Device Interface
309 Monitor interface
1402 ISP PPP peer
1404 PSTN (Public Switched Telephone Network)

Claims

Generating means for generating a certificate of a first public key;
Providing means for providing a certificate of the first public key generated by the generating means,
The certificate of the first public key generated by the generation unit is a certificate of the second public key issued by the authentication service provider, and the validity can be confirmed using the second public key. A public key certificate providing device including a digital signature.

2. The public key certificate providing apparatus according to claim 1, wherein said providing means provides the first public key certificate to a host in a subnet.

2. The public key certificate providing apparatus according to claim 1, wherein said providing means provides the host with a first public key certificate and information for determining an address of the host. Document providing device.

2. The public key certificate providing apparatus according to claim 1, further comprising a connection unit that connects a host to which the first public key certificate is provided by the providing unit to the Internet. Providing device.

Generate a certificate for the first public key,
A public key certificate providing program that provides a certificate of the generated first public key,
The certificate of the first public key generated in the generation step is a certificate of the second public key issued by the authentication service provider, and the validity can be confirmed using the second public key. A public key certificate providing program including a digital signature.

6. The public key certificate providing program according to claim 5, wherein said providing step provides a first public key certificate to a host in a subnet.

6. The public key certificate providing program according to claim 5, wherein the providing step provides the host with a first public key certificate and information for determining an address of the host. Letter providing program.

6. The public key certificate providing program according to claim 5, further comprising a connection step of connecting a host to which the first public key certificate is provided by the providing step to the Internet. Provided program.

A public key certificate providing apparatus provided in a subnet, comprising: a providing unit that provides information for determining an address, and a certificate of a first public key to a host in the subnet,
Generating means for generating a certificate of the first public key,
The certificate of the first public key generated by the generation unit is a certificate of the second public key issued by the authentication service provider, and the validity can be confirmed using the second public key. A public key certificate providing device including a digital signature.

Internet connection means for connecting the Internet,
Host connection means for connecting to the host;
Providing means for providing a certificate of a first public key,
The certificate of the first public key provided by the providing unit is a certificate of the second public key issued by the authentication service provider, and the validity can be confirmed using the second public key. A connection device comprising a digital signature.

Communication means;
Determining means for determining its own address based on the result of communication with the first partner,
The communication device, wherein the communication unit notifies the second party of the public key certificate received from the first party in order to perform encrypted communication with the second party.

According to the result of communication with the first partner, determine your own address,
A communication program for notifying a second party of a public key certificate received from a first party in order to perform cryptographic communication with a second party.