JP2004032699A

JP2004032699A - Apparatus for issuing public key certificate

Info

Publication number: JP2004032699A
Application number: JP2003107534A
Authority: JP
Inventors: Kazuomi Oishi; 大石　和臣
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2002-05-09
Filing date: 2003-04-11
Publication date: 2004-01-29
Anticipated expiration: 2023-04-11
Also published as: JP4280536B2

Abstract

<P>PROBLEM TO BE SOLVED: To efficiently achieve a disposable, anonymous public key certificate that efficiently, reliably, and rapidly issues the disposable, anonymous public key certificate which includes an IPv6 address as a target to be certified, without making errors in a target to be issued to, has a high degree of privacy protection, is achieved at low cost, and has a small load at execution. <P>SOLUTION: A host 206 requests a public key certificate to a gateway 202, and the gateway 202 requests the public key certificate to a Certification Authority (CA) 209. The CA209 creates the public key certificate, which is sent to the host 206 via the gateway 202. The host 206 sets the IPv6 address, based on the information from the gateway 202. The host 206 requests a new public certificate, as needed, receives it, and sends the public key certificate including the IPv6 address to the other end of communication. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、公開鍵証明書を発行する発行装置に関する。
【０００２】
【従来の技術】
ＩＰｖ６の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けディジタルカメラである。
【０００３】
ＩＰｖ６に対応するパーソナル・コンピュータやワークステーションの場合、ネットワークとの接続のインターフェイスには通常はイーサネット（Ｒ）が用いられ、それが持つ　ＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）を元にしてＩＰｖ６アドレスが構成されるようになっている。
【０００４】
ＩＰｖ６アドレスには、後述するようにリンクローカルアドレス、サイトローカルアドレスと（集約可能）グローバルアドレスの３種類が存在する。
【０００５】
それらの詳細や構成方法などのアドレス体系は、ＲＦＣ　２３７３　｀｀ＩＰＶｅｒｓｉｏｎ　６　Ａｄｄｒｅｓｓｓｉｎｇ　Ａｒｃｈｉｔｅｃｔｕｒｅ、’’　ＲＦＣ　２３７４　｀｀Ａｎ　ＩＰｖ６　Ａｇｇｒｅｇａｔａｂａｌｅ　Ｇｌｏｂａｌ　Ｕｎｉｃａｓｔ　Ａｄｄｒｅｓｓ　Ｆｏｒｍａｔ、’’　ＲＦＣ　２３７５　｀｀ＩＰｖ６　Ｍｕｌｔｉｃａｓｔ　Ａｄｄｒｅｓｓ　Ａｓｓｉｇｎｍｅｎｔ、’’　ＲＦＣ　２４５０　｀｀Ｐｒｏｐｏｓｅｄ　ＴＬＡ　ａｎｄ　ＮＬＡ　Ａｓｓｉｇｎｍｅｎｔ　Ｒｕｌｅ、’’　ＲＦＣ　２４６１　｀｀Ｎｅｉｇｈｂｏｒ　Ｄｉｓｃｏｖｅｒｙ　ｆｏｒ　ＩＰ　Ｖｅｒｓｉｏｎ　６　（ＩＰｖ６）、’’　ＲＦＣ　２４６２　｀｀ＩＰｖ６　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、’’　等に記述されている。
【０００６】
ところで、ＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）のようにハードウェアに１対１に対応する情報を固定的に用いると、それが装置もしくはその装置のユーザと１対１に対応する情報とみなされ、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。
【０００７】
この課題に対しては、ランダムなＩＰｖ６アドレス（正確にはインターフェイスＩＤ）を生成する方法が、ＲＦＣ３０４１　｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒ　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’　等において提案されている。生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算／生成し、ユニークなランダムな値を定めるプロトコル（の拡張）も記述されている。
【０００８】
上記のような解決方法を利用して生成したランダムなＩＰｖ６アドレスを装置が使う場合に、ＩＰｓｅｃを用いて暗号通信を行なうことを考える。ＩＰｓｅｃは、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであり、通信に際して秘密データやお互いのＩＰｖ６アドレス等を安全に共有する必要がある。秘密データやお互いのＩＰｖ６アドレス等のデータはＳＡ（Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）と呼ばれる。
【０００９】
ＳＡを安全に共有するプロトコルはＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）と呼ばれ、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ　（ＩＫＥ）’’において規定されている。ここで、ＳＡを安全に共有するという意味は、意図する相手のみと確実にＳＡを共有するという意味であり、相手を確実に認証することを必要とする。ＩＫＥには、１）ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙを用いる方法、２）ディジタル署名を用いる方法、３）公開鍵暗号による暗号化による方法、４）公開鍵暗号による暗号化の改訂モードによる方法、の計４つの認証方法が規定されている。
【００１０】
ところが、プライバシ保護（身元を明らかにする情報を与えない）を実現する状況を考えている、例えばユーザが買い物サイトとのＩＰｓｅｃ通信を行なうような場合であるので、買い物サイトの立場で考えれば、あらかじめ定まっていない不特定多数の通信相手と　ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ　をＩＰｓｅｃ通信に先だって共有することは現実には不可能であるから、ｐｒｅ−ｓｈａｒｅｄ　ｋｅｙ　を用いる方法は使えない。
【００１１】
その他の方法の場合は、ディジタル署名あるいは公開鍵暗号の使用に必要な情報（多くの場合は公開鍵）を確実に入手可能ならば、不特定多数の通信相手同士でＩＫＥを実行することが可能である。そのために最も有望視されているのが、ＰＫＩ（Ｐｕｂｌｉｃ−ｋｅｙ　Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）と呼ばれる環境・仕組みであり、その中で中心的な役割を果たすのが、公開鍵証明書である。
【００１２】
公開鍵証明書は、信頼できる第三者がエンティティ（通信をする主体、計算機や人間）とそのエンティティの公開鍵の対応関係を確認し、それを保証するためにエンティティのＩＤ情報等と公開鍵の組みに対して信頼できる第三者が発行するディジタル署名である。信頼できる第三者はＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ）と呼ばれ、ＣＡのディジタル署名の正当性を確認するための公開鍵は、広く一般に知られている。
【００１３】
しかし、現在運用されている公開鍵証明書の中には、その持ち主（Ｓｕｂｊｅｃｔ）を示すＩＤ情報、例えば、ＦＱＤＮ（Ｆｕｌｌｙ　Ｑｕａｌｉｆｉｅｄ　Ｄｏｍａｉｎ　Ｎａｍｅ）が含まれるので、そのままではプライバシ保護を実現できない。
【００１４】
公開鍵証明書の中にその持ち主のＩＤ情報を含めない方法も考えられ、匿名公開鍵証明書と呼ばれる。
【００１５】
しかし、匿名公開鍵証明書にも上述のＩＥＥＥ　ｉｄｅｎｔｉｆｉｅｒ　（ＭＡＣ　ａｄｄｒｅｓｓ）と同じ課題が存在する。つまり、同一の匿名公開鍵証明書を使い続ける限り、複数の（公開鍵証明書に基づくＩＰｓｅｃ等の）通信を結び付けることは可能であり、もしも一度でも匿名公開鍵証明書とその持ち主の対応関係が明らかになったときは、プライバシが侵害されることにつながるので、やはりプライバシ保護の程度は弱い。
【００１６】
以上の課題に対して、例えば、異なる通信相手と通信する際に異なるＩＰｖ６アドレスおよび匿名公開鍵証明書を使うことが可能ならば、強いプライバシ保護が実現できると考えられる。これらを使い捨てＩＰｖ６アドレスおよび使い捨て匿名公開鍵証明書と呼ぶ。使い捨てる間隔としては、通信相手が変る度に新しい使い捨てＩＰｖ６アドレスを用いる、あるいはパケット毎に変えるなど、いくつかが考えられる。
【００１７】
【発明が解決しようとする課題】
しかし、使い捨てＩＰｖ６アドレスに関しては、前述のＲＦＣ３０４１　｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒ　Ｓｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’　が知られているが、ＩＰｖ６通信が可能な装置（以下では、ＩＰｖ６対応装置と表す）に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。
【００１８】
さらに、次の課題も存在する。通信相手のＩＤ情報がわからない場合、通信相手の識別はＩＰアドレスでのみ行なうことになる。しかし、例えばイーサネット（Ｒ）のＬＡＮ上で送受されるパケットはそのＬＡＮ上のノード全てがアクセスできるので、本来はエンティティＡとエンティティＢが通信をするはずのところを、Ａと同じＬＡＮ上の悪意を持ったＣがＡになりすますこともありうる。つまり、ＡとＢの間で使い捨て匿名公開鍵証明書に基づくＩＰｓｅｃ通信を行なうために、Ａの公開鍵証明書がＢに送られる際に、Ａの公開鍵証明書をＣのものとすり替えることでＣはＡに成りすますことができてしまう。
【００１９】
ＤＮＳ（Ｄｏｍａｉｎ　Ｎａｍｅ　Ｓｙｓｔｅｍ）サーバーやルーターに対してＤｏＳ（Ｄｅｎｉａｌ　ｏｆ　Ｓｅｒｖｉｃｅｓ）攻撃を加え、その間に偽のＤＮＳサーバーやルーターが偽の情報を与えるようにすれば、ＬＡＮに限定されないより広域な範囲でのなりすましも可能となる。通信相手のＩＤが判明していれば、それを確認することで対処できたが、上記に示したような匿名性の高い状況において、この種の攻撃を防ぐ方法は今まで知られていない。
【００２０】
本発明の目的は、強力なプライバシ保護を実現することにある。
【００２１】
また、本発明の他の目的は、なりすましを防ぐことにある。
【００２２】
本発明の他の目的は、ＩＰｖ６アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することにある。
【００２３】
本発明の他の目的は、プライバシ保護の程度が高く、低コストで実現が可能で、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能にすることにある。
【００２４】
本発明の他の目的は、ＩＰｓｅｃの通信を効率的に実現することにある。
【００２５】
本発明の他の目的は、強力なプライバシ保護を実現し、かつなりすましを防ぎながらＩＫＥによるＩＰｓｅｃ通信を行なうことにある。
【００２６】
【課題を解決するための手段】
上記課題を解決するために、本出願に関わる発明は、ネットワークを介して通信装置と通信する通信手段と、公開鍵を生成する生成手段と、通信装置から公開鍵証明書を要求されると、前記生成手段により生成された公開鍵を公開鍵証明書発行者に送信する送信手段とを有することを特徴とする。
【００２７】
【発明の実施の形態】
（第１の実施の形態）
本実施の形態では、ホストがイーサネット（Ｒ）のＬＡＮ経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本発明の実施の形態を説明する。
【００２８】
図２は、本発明が適用される接続環境（ホストがイーサネット（Ｒ）のＬＡＮ経由でインターネットと接続する環境）を模式的に示したものである。
【００２９】
図２は、ＬＡＮに接続されたホスト２０４、２０５、２０６が　ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２経由でインターネット２０１にアクセスする環境を示す。本実施の形態では、各ホストはリンク２０７で接続するものとし、具体的にはイーサネット（Ｒ）であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、ＩＰ層の下側に接する。リンクにはイーサネット（Ｒ）の他に、ＰＰＰリンク、Ｘ．２５、フレームリレー、ＡＴＭネットワークがある。
【００３０】
リンクに接続されたＩＰｖ６対応装置をノードと呼ぶ。
【００３１】
ノードの内部構成の典型例を図３に示す。
【００３２】
ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノード３００は、ネットワーク・インターフェイス３０１、３０２、ＣＰＵ　３０３、ＲＯＭ　３０４、ＲＡＭ　３０５、ＨＤ（ハードディスク）３０６、電源３０７、キーボード／ポインティングデバイスのインターフェイス３０８、モニターのインターフェイス３０９、バス３１０等を有する計算機である。
【００３３】
ルーターは複数のインターフェイス３０１、３０２を持つのに対し、ホストは多くの場合は一つのインターフェイス３０１を持つ。ネットワーク・インターフェイス３０１は、リンク２０７に接続され、リンク２０７に接続された他のノードと通信する。ホスト２０４、２０５、２０６は、ネットワーク・インターフェイス３０１により、リンク２０７を介して、リンク２０７に接続された他のノード、あるいは、更に、ゲートウェイ２０２を介して、インターネット２０１上のサイトと通信する。ゲートウェイ（ルーター）２０２においては、ネットワーク・インターフェイス３０２は、インターネット２０１と接続され、ゲートウェイ（ルーター）２０２は、ネットワーク・インターフェイス３０２により、インターネット２０１を介して通信する。なお、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９も、図３と同様の構成を有する。Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９は、ネットワーク・インターフェイス３０１を介して、インターネット２０１に接続されている。ノードによってはＨＤを持たないものもある。
【００３４】
なお以下の処理内容（手順）は、装置もしくはプログラムとして実現される。すなわち、装置で実現する形態では、その装置を有するノード３００が、以下の処理内容（手順）を実行する。また、プログラムとして実現する形態では、そのプログラムがＲＯＭ３０４もしくはＨＤ３０６に格納されたノードが、以下の処理内容（手順）を実行する。例えば、プログラムとして実現される場合は、そのプログラムをＣＰＵ３０３が読み込み、必要に応じてＲＡＭ３０５を計算のための空間として利用しながらバス３１０を介してインターフェイス３０１、３０２にアドレスを割当てる、というような動作を行なう。
【００３５】
本実施の形態のイーサネット（Ｒ）ＬＡＮ環境で各ホストがＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ　ｇａｔｅｗａｙのアドレスを取得するプロトコルの仕組みを簡単に説明し、その次に本発明を適用した具体的な実施の形態を説明する。
【００３６】
図３のノードが、電源を入れられたあるいはリブートされた場合に行なう動作のフローチャートを図８に示す。この動作はＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）と呼ばれる。以下では図８の流れに沿って処理内容を説明する。
【００３７】
ステップＳ８０１でノード３００が電源を入れられたあるいはリブートされた後、まずネットワーク・インターフェイス３０１のイーサネット（Ｒ）の　ＭＡＣ　ａｄｄｒｅｓｓ（図４参照）からインターフェイスＩＤ（図５参照）を作成し、それをｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ（図６参照）とする（ステップＳ８０２）。
【００３８】
次に、そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓがリンク２０７上で一意かどうかを判断するために、ノード３００は以下の処理を行なう。
【００３９】
最初に、インターフェイス３０１の初期設定をする。すなわち、インターフェイス３０１に、ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　（ＦＦ０２：：１）と　そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　を割当てる（図７参照）。つまり、そのインターフェイス３０１が　ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ宛のパケットあるいはそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　宛のパケットを見つけたときはそれを自分のインターフェイス宛のパケットとして受け取る。
【００４０】
前者（ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ）を割当てることによって、既にそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを使っている他のノードからのデータを受信することが可能になる。また、後者（そのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ）を割当てることによって、同じｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを同時に使おうとしている他のノードの存在を検出することが可能になる。
【００４１】
あるｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　とは、ＲＦＣ２４６１のｐａｇｅ　９１に定義されているように、ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓの下位２４ビットをプレフィックスＦＦ０２：０：０：０：０：１：ＦＦ００：：／１０４に付加したデータであり、ｌｉｎｋ−ｌｏｃａｌ　ｓｃｏｐｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　である。図６と図７にそれらの関係を示す。以上のアドレス割当てが図８のステップＳ８０３である。
【００４２】
次に　Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　を作る。Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　の　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓ（ターゲットアドレス）には判断対象のｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓを、ＩＰ　Ｓｏｕｒｃｅ（送信元アドレス）には　ｕｎｓｐｅｃｉｆｉｅｄ　ａｄｄｒｅｓｓ（１２８ビット全てが０）を、ＩＰ　ｄｅｓｔｉｎａｔｉｏｎ（宛先アドレス）には判断対象のｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　の　ｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓを設定する。
【００４３】
この　Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　をＲｅｔｒａｎｓＴｉｍｅｒミリセカンド間隔でＤｕｐＡｄｄｒＤｅｔｅｃｔＴｒａｎｓｍｉｔｓ個イーサネット（Ｒ）２０７に送出する。図８のステップＳ８０４がこの処理である。
【００４４】
Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取ったノードは、その送信元アドレスが　ｕｎｓｐｅｃｉｆｉｅｄ　ａｄｄｒｅｓｓ　ならば、その　ｍｅｓｓａｇｅ　がＤＡＤを行っているノードからのデータであることと判断する。
【００４５】
同時に複数のノードが同じアドレスを対象としてＤＡＤをしている場合は、自分が送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅｓ以外にも、同じアドレスを　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓに含むＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅｓを受け取る（自分が送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅと、同時にそのアドレスを対象としてＤＡＤをしている他のノードが送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取る）ので、重複していることがわかる。その場合にはどのノードもそのアドレスは使わない。
【００４６】
なお、受け取った　Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅ　が、自分が送ったもの（マルチキャストのパケットをループバックしているため）であるならば、他にそれを使っているあるいは使おうとしているノードが存在することを示さない。自分が送ったＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅに加えて、同じアドレスを　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓに含むＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅｓを受け取った場合に、同時に複数のノードが同じアドレスを対象としてＤＡＤをしていると判断する。
【００４７】
一方、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを受け取ったノードが、その　ｍｅｓｓａｇｅ　の　Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓ（ターゲットアドレス）に含まれるアドレスを既に使っていれば、Ｔａｒｇｅｔ　Ａｄｄｒｅｓｓにそのｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓが設定されたａ　ｍｕｌｔｉｃａｓｔ　Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　をａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ宛てに返す。従って、Ｎｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　ｍｅｓｓａｇｅを送ったノードが　ａｌｌ−ｎｏｄｅｓ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓ　宛てのａ　ｍｕｌｔｉｃａｓｔ　Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取り、その　ｔａｒｇｅｔ　ａｄｄｒｅｓｓ　が　（判断対象の）　ｔｅｎｔａｔｉｖｅ　ａｄｄｒｅｓｓ　である場合（図８のＳ８０５ステップの「はい」の場合）は判断対象の　ｔｅｎｔａｔｉｖｅ　ａｄｄｒｅｓｓ　が唯一ではない（つまり、重複している）。
【００４８】
以上のＤＡＤの結果、判断対象の　ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓ　がリンク２０７上で唯一であることが確認された（図８のＳ８０５ステップの「いいえ」の場合）ならば、そのアドレスをリンクローカルアドレスとしてインターフェイス３０１に割当てる。これが図８のステップＳ８０６である。以上でＤＡＤは終了する。
【００４９】
以上に説明した図８の動作は図２のｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２、ＤＨＣＰ　ｓｅｒｖｅｒ　２０３、ホスト２０４、ホスト２０５、ホスト２０６のそれぞれが実行することができる。
【００５０】
図２のホスト、例えばホスト２０６は、リンクローカルアドレスをインターフェイス３０１に割当てたら、次はサイトローカルアドレスやグローバルアドレスを決定するために必要な情報（Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔと呼ばれる）をｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２から入手することを試みる。
【００５１】
この動作を図９に示す。ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は通常はルーターと呼ばれるので以下ではルーター２０２と記す。ルーター２０２は管理者によって必要な設定が行われ、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を定期的にリンク２０７に送っている。ホスト２０６が　Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を早く入手したい場合は、ホスト２０６は　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　と呼ばれるデータをルーター２０２に送る。ホスト２０６はリンクローカルアドレスを割当てた直後にはルーター２０２の存在はわからないので、実際にはＲｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎはリンク上のルーター全てに対するマルチキャストとして送られる。図９のステップＳ９０１はこの処理を示す。
【００５２】
Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　を受け取ったルーター２０２は　Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を送る。図９のステップＳ９０２の「はい」の場合に示すように、Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　のみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を受け取ったホスト２０６は、そのメッセージに含まれるプレフィックスの有効性（既にその装置によって使われていないこと等）を確認し、それ（ら）にインターフェイスＩＤを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとし、インターフェイス３０１に割当てる。図９のステップＳ９０３がこの処理である。
【００５３】
図９のステップＳ９０２の「いいえ」の場合に示すように、ホスト２０６が　ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎのみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　を受け取らなかった場合は、次の二つの場合に分けられる。Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取った場合（ステップＳ９０４のはいの場合）と、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合（ステップＳ９０４のいいえの場合）である。
【００５４】
後者の場合はｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、すなわちＤＨＣＰｖ６のみを実行する。これがステップＳ９０６であり、その基本的な動作フローチャートを図１０に示す。
【００５５】
なお、ｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｔａｔｉｏｎ　においてやり取りされるメッセージの内容や形式等の詳細は、”ｄｒａｆｔ−ｉｅｔｆ−ｄｈｃ−ｄｈｃｐｖ６−ｘｘ．ｔｘｔ”（２００２年３月においてｘｘ＝２３が最新版）に説明されている。以下では図１０の番号に沿って基本的な動作の流れを説明する。
【００５６】
ＤＨＣＰサーバー２０３は管理者によって必要な設定が行われている。具体的には、ノードとして自分のリンクローカルアドレスをインターフェイス３０１に割当ててあり、ＤＨＣＰサーバーとして振る舞うために必要なサイトローカルアドレスもしくはグローバルアドレスのためのプレフィックス等が設定されている。
【００５７】
図１０のステップＳ１００１で、ホスト２０４はＤＨＣＰサーバーにＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅを送る。ホスト２０６はどこにＤＨＣＰサーバーが存在するのかわからないのでＤＨＣＰサーバーに対するマルチキャストとしてリンク２０７に送出する。ホスト２０６の接続されているリンク２０７とは異なるリンク（図示せず）にＤＨＣＰサーバーがいる場合には、ＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅは、実際にはＤＨＣＰリレー（図示せず）によって中継されてＤＨＣＰサーバー２０３に届く。
【００５８】
ＤＨＣＰ　Ｓｏｌｉｃｉｔ　Ｍｅｓｓａｇｅを受け取ったＤＨＣＰサーバー２０３はそれに対する返答としてＤＨＣＰ　Ａｄｖｅｒｔｉｓｅ　Ｍｅｓｓａｇｅをホスト２０６に返す。これは（別リンクの場合はＤＨＣＰリレーによって中継されて）ホスト２０６に届く。これがステップＳ１００２である。この時点でホスト２０６はＤＨＣＰサーバー２０３のアドレスがわかる。
【００５９】
次にステップＳ１００３でホスト２０６は　ＤＨＣＰ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅ　をＤＨＣＰサーバー２０３に送る。ＤＨＣＰサーバー　２０３はＤＨＣＰ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅを受け取ると、ステップＳ１００４でＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅをホスト２０６に送る。
【００６０】
ステップＳ１００４でＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅ受け取ったホスト２０６は、それからサイトローカルアドレスもしくはグローバルアドレスがわかるので、そのアドレスの中のインターフェイスＩＤが重複しているか否かを確認するために、ＤＡＤ処理に必要な処理を行なう。つまり、インターフェイス３０１に前述のマルチキャストアドレス等を設定する。これがステップＳ１００５である。
【００６１】
次に、ステップＳ１００６でＮｅｉｇｈｂｏｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　Ｍｅｓｓａｇｅ　を送り、Ｎｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取るかどうかをステップＳ１００７で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをＤＨＣＰサーバー２０３から受け取るためにステップＳ１００３に戻り、同じ処理を繰り返す。
【００６２】
ホスト２０６は、図１０のステップＳ１００７でＮｅｉｇｈｂｏｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取らなかった場合はそのアドレスは重複していないので、ステップＳ１００８でそのアドレスをインターフェイス３０１に割当てる。
【００６３】
以上で図９のステップＳ９０６が終わる。ステップＳ９０４でＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合はこれで正常終了する。
【００６４】
ステップＳ９０２でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取った場合は、ステップＳ９０５でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を行なう。処理内容はステップＳ９０３とＳ９０６と同じである。
【００６５】
以上のようにして、イーサネット（Ｒ）をインターフェイスとして持つホスト２０６はｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　とｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　（ＤＨＣＰｖ６）を任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、グローバルアドレス、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ等を自動設定することができる。
【００６６】
以上のプロトコルにおいて、インターフェイスＩＤにランダムな値を用いる場合、その値を対象にしてＤＡＤを行ない、リンク２０７における一意性を確認すれば、グローバルアドレスのプレフィックスと組み合わせて、使い捨てのＩＰｖ６グローバルアドレスを利用することができる。詳細は、ＲＦＣ３０４１　｀｀Ｐｒｉｖａｃｙ　Ｅｘｔｅｎｓｉｏｎｓ　ｆｏｒＳｔａｔｅｌｅｓｓ　Ａｄｄｒｅｓｓ　Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　ｉｎ　ＩＰｖ６、’’に記述されている。
【００６７】
次に本発明の実施の形態を説明する。上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。最初に、匿名公開鍵証明書の例を説明し、次にそれを効率的に発行するためのプロトコルを説明する。
【００６８】
匿名公開鍵証明書は、学術的にはＫａｚｕｏｍｉ　Ｏｉｓｈｉ、　Ｍａｓａｈｉｒｏ　Ｍａｍｂｏ、　Ｅｉｊｉ　Ｏｋａｍｏｔｏ、　｀｀Ａｎｏｎｙｍｏｕｓ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｃｅｒｔｉｆｉｃａｔｅｓ　ａｎｄ　ｔｈｅｉｒ　Ａｐｐｌｉｃａｔｉｏｎｓ　’’　ＩＥＩＣＥ　Ｔｒａｎｓａｃｔｉｏｎｓ　ｏｎ　Ｆｕｎｄａｍｅｎｔａｌｓ　ｏｆ　Ｅｌｅｃｔｒｏｎｉｃｓ、　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ａｎｄ　Ｃｏｍｐｕｔｅｒ　Ｓｃｉｅｎｃｅｓ、　Ｅ８１−Ａ、　１、　ｐｐ。　５６−−６４、　１９９８においてその概念と具体的な実現方法が提案されており、その基本的な実現方法はＵＳＡの特許６、１５４、８４１としても開示されている。これらの方式では、証明書のユーザの匿名性は計算量的に保たれていた。
【００６９】
より強力な匿名性を提供する方式として、情報量的な匿名性を有する匿名公開鍵証明書の実現方法がＫａｚｕｏｍｉ　Ｏｉｓｈｉ、　｀｀Ｕｎｃｏｎｄｉｔｉｏｎａｌｌｙ　ａｎｏｎｙｍｏｕｓ　ｐｕｂｌｉｃ　ｋｅｙ　ｃｅｒｔｉｆｉｃａｔｅｓ、’’　Ｔｈｅ　２０００　Ｓｙｍｐｏｓｉｕｍ　ｏｎ　Ｃｒｙｐｔｏｇｒａｐｈｙ　ａｎｄ　Ｉｎｆｏｒｍａｔｉｏｎ　Ｓｅｃｕｒｉｔｙ、　ＳＣＩＳ２０００−Ｃ３２、　２０００において開示されている。
【００７０】
本発明においては、前述の論文Ｋａｚｕｏｍｉ　Ｏｉｓｈｉ、　Ｍａｓａｈｉｒｏ　Ｍａｍｂｏ、　Ｅｉｊｉ　Ｏｋａｍｏｔｏ、　｀｀Ａｎｏｎｙｍｏｕｓ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｃｅｒｔｉｆｉｃａｔｅｓ　ａｎｄ　ｔｈｅｉｒ　Ａｐｐｌｉｃａｔｉｏｎｓ　’’に記載されている任意の方式を利用することができる。効率が劣ることを許容できるならば、前記論文中のＳｃｈｅｍｅ　１、Ｓｃｈｅｍｅ　２、Ｓｃｈｅｍｅ　３を利用することも可能であり、それらも本発明に含まれる。
【００７１】
本実施の形態では計算量的な匿名性を有する匿名公開鍵証明書方式を用いる場合を例として取り上げる。説明の都合上必要な記号等を定義・導入してから、本実施の形態のプロトコルを説明する。
【００７２】
匿名公開鍵証明書を発行するエンティティＣＡは、共通のパラメータとして大きな素数ｐとｑを定める。ｑはｐ−１を割りきる。オーダーｑの生成元ｇとハッシュ関数Ｈを定める。秘密の乱数ｓ＿ｃａ（１以上ｑ以下）を生成し、ｖ＿ｃａ＝ｇ＾（ｓ＿ｃａ）　ｍｏｄ　ｐを計算する。ここで、Ａ　＝　（Ｂ）＾（Ｃ）　ｍｏｄ　Ｄは、整数Ａ、Ｂ、Ｃ、Ｄに対して、ＢをＣ乗した値をＤで割り、その剰余をＡとする計算を表す。エンティティＣＡはｐとｑとｇとＨとｖ＿ｃａを公開する。したがって、エンティティｉは、ｐとｑとｇとＨとｖ＿ｃａを把握している。
【００７３】
一方、匿名公開鍵証明書を利用するエンティティｉは、秘密の乱数ｓ＿ｉ（１以上ｑ以下）を生成し、ｖ＿ｉ＝ｇ＾（ｓ＿ｉ）　ｍｏｄ　ｐを計算する。ｓ＿ｃａやｓ＿ｉを秘密鍵、ｖ＿ｃａやｖ＿ｉ（および公開のパラメータ（ｇなど））を公開鍵と呼び、秘密鍵は自分以外の誰にも知られないように管理する。エンティティＣＡ、および、ｉは、公開鍵ｖ＿ｃａやｖ＿ｉ（および公開のパラメータ（ｇなど））を、把握している。
【００７４】
エンティティｉは、匿名公開鍵証明書を利用開始する際に、自分のエンティティ名（ユーザ名）とパスワード、公開鍵ｖ＿ｉをエンティティＣＡに登録する。エンティティＣＡは、必要に応じてエンティティの身元を物理的手段等で確認し、提示されたエンティティ名（ユーザ名）とパスワード、公開鍵ｖ＿ｉを記憶する。
【００７５】
匿名公開鍵証明書を発行する際、エンティティＣＡは、乱数ｒ（１以上ｑ以下）を生成し、（ｇ’、ｖ＿ｉ’）＝（ｇ＾ｒ　ｍｏｄ　ｐ、　（ｖ＿ｉ）＾（ｒ）　ｍｏｄ　ｐ）を計算する。公開のパラメータ（ｐなど）やこの匿名公開鍵証明書の有効期限、公開鍵ｖ＿ｃａに対する公開鍵証明書等の証明書の管理・属性情報をＸとし、（ｇ’、ｖ＿ｉ’）とＸを含むメッセージ（のハッシュ値）に対してディジタル署名を生成する。ＣＡは離散対数問題に基づくディジタル署名方式、例えば、Ｓｃｈｎｏｒｒ署名方式を使うことができる。ここでは、秘密鍵ｓ＿ｃａを用いて、ディジタル署名を生成する。このディジタル署名をＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）と記す。
【００７６】
エンティティｉに対してＣＡが発行する匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））である。なお、本発明の変形例では、匿名公開鍵証明書の管理・属性情報Ｘには、ｖ＿ｃａに対する公開鍵証明書を含めない。
【００７７】
匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、　Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の発行を受けたエンティティｉは、その中から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし　｜　は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。また、ｖ＿ｉ’＝（ｇ’）＾（ｓ＿ｉ）　ｍｏｄ　ｐも確認する。それらが正しいと確認できたならば、ｇ’とｖ＿ｉ’（と共通のパラメータｐ）を公開鍵、ｓ＿ｉを秘密鍵として離散対数問題に基づく公開鍵暗号やディジタル署名を利用できる。
【００７８】
匿名公開鍵証明書（ｇ’、ｖ＿ｉ’、Ｘ、　Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））を受け取ったエンティティは、その中から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。それが正しいと確認できたならば、ｇ’とｖ＿ｉ’（と共通のパラメータｐ）を用いて離散対数問題に基づく公開鍵暗号の暗号化やディジタル署名の検証を行なう。
【００７９】
なお、上記の説明では乗法群（ｍｏｄ　ｐ）上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能であり、その場合は乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。
【００８０】
以上の匿名公開鍵証明書方式を、図２の環境に適用する場合を説明する。
【００８１】
Ｃｅｒｔｉｆｉｃａｉｔｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９がエンティティＣＡ、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。但し、Ｃｅｒｔｉｆｉｃａｉｔｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９が上記匿名公開鍵証明書方式におけるＣＡの全ての機能を有するわけではない。以下では、公開鍵証明書を利用するＩＰｖ６対応装置（ホスト２０６）の位置するローカルリンク２０７内に存在し、かつ、公開鍵証明書発行者（ＣＡ、つまりＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９）が信用するＩＰｖ６対応装置がｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２である場合を説明する。つまり、匿名公開鍵証明書書方式におけるエンティティＣＡの機能の一部は、Ｃｅｒｔｉｆｉｃａｉｔｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の代わりに、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２が有する場合を説明する。
【００８２】
なお、ＣＡ　２０９が信用するＩＰｖ６対応装置はＤＨＣＰサーバー２０３や専用ＣＡサーバーでもよい。また、以下では、ランダムなＩＰｖ６アドレスを証明書の中に含める形態を説明するが、ランダムなＩＰｖ６アドレスを証明書に含めない形態もあるかもしれない。前述のように、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２をルーター２０２と呼ぶことにする。
【００８３】
Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の管理者は、上述の公開パラメータｐ、ｇ等を定め、公開する。また、エンティティＣＡとしての公開鍵ｖ＿ｃａを定める。
【００８４】
Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９がｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２（あるいはＤＨＣＰサーバーや専用ＣＡサーバー）を信用するということは、ここでは、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２等の管理元がはっきりしており、問題が生じたときにその管理元が責任を負う条件がＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９とその管理元との間で合意されていることとする。例えば、ある匿名公開鍵に関するトラブルが起ったとき、その匿名公開鍵のユーザを特定し責任をとらせる処理をｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２等の管理元が責任を持って行なうことが、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９と　ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２等の管理元との間で契約書によって合意されている場合等である。
【００８５】
また、この場合には、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９とｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２（あるいはＤＨＣＰサーバーや専用ＣＡサーバー）は、例えば、公開鍵暗号を安全に交換してあるとか秘密の暗号化鍵を安全に共有してある等により、それらの間では、インターネットを介して確実で安全な通信が行なえるものとする。
【００８６】
ルーター（ｇａｔｅｗａｙ）２０２は、パケットの転送を制御する役目を持ち、そのルーター２０２の管轄するサブネットと外部との間で不適当なパケットが出入りしないように管理者の責任のもとで運用される。あるサブネットがインターネット２０１に接続されるためにはそのサブネットの管理者は身元をＪＰＮＩＣ（日本の場合）に登録し、ＩＰアドレスの割当てを受ける。従って、サブネットにおけるルーター２０２は管理責任が明確であり、かつ安全面も考慮されたうえで運用や管理にコストがかけられると期待されるので、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９が信用するにふさわしいと考えられる。
【００８７】
ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＬＡＮの管理者（ルーター２０２の管理者）に提出する。ＬＡＮの管理者（ルーター２０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、ユーザｉのエンティティ名からユーザｉの公開鍵ｖ＿ｉが検索できるように、ルーター２０２のＲＡＭ３０５あるいはＨＤ　３０６に登録する。公開パラメータや公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。
【００８８】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１に示す。図１は、エンティティ（ユーザｉが用いるＩＰｖ６端末）をホスト２０６、ＣＡを　Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９とし、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９はルーター２０２を信用するものであり、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。ここで、ルーター２０２は、アドレスを設定するためのアドレス情報をホスト（通信装置）２０６に提供するアドレス情報提供装置、あるいは、提供者である。なお、アドレス情報は、ＩＰｖ６のグローバルアドレスのプレフィックス、あるいは、ＩＰｖ６のグローバルアドレス自体である。
【００８９】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター２０２とエンティティ（この場合は、ホスト２０６）の間でなんらかの特定（認証）プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１の流れに沿って動作を説明する。
【００９０】
ホスト２０６はステップＳ１０１でＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成する。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎは、匿名公開鍵証明書を要求するメッセージであり、その旨とインターフェイス３０１のインターフェイスＩＤを含むデータであることをルーター２０２が理解できる形式であるとする。内容は、エンティティ名（ユーザ名）とパスワードとシリアル番号から計算される。シリアル番号は、例えばホスト２０６のＩＰｖ６リンクローカルアドレスとｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６リンクローカルアドレスとそのときの時刻の３つを連接して一つのデータにした値を採用できる。再送攻撃となりすましを防ぐために、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数に入力した値に対して、秘密鍵ｓ＿ｉを用いて生成したディジタル署名（認証用ｓｉｇｎａｔｕｒｅ）（＝　Ｓｉｇ＿ｉ（ｈａｓｈ（エンティティ名、パスワード、シリアル番号）））がＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれる。
【００９１】
次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ　ＳｏｌｉｃｉｔａｔｉｏｎをステップＳ１０２でネットワーク・インターフェイス３０１からルーター２０２に送る。
【００９２】
ステップＳ１０３で、ルーター２０２はステップＳ１０２でネットワーク・インターフェイス３０１から受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（識別子）から登録された公開鍵ｖ＿ｉをＲＡＭ　３０５あるいはＨＤ　３０６から検索し、それを用いて認証用ｓｉｇｎａｔｕｒｅの正当性を確認する。具体的には、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数の入力とし、そのハッシュ値を求め、認証用ｓｉｇｎａｔｕｒｅがそれに対する正しいディジタル署名であることを公開鍵ｖ＿ｉで確認する。すなわち、ディジタル署名を含むＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎをインターフェイス３０１がホスト２０６から受信すると、ＣＰＵ　３０３は、ホスト２０６の公開鍵ｖ＿ｉを用いて、ディジタル署名の正当性を確認する。以上のように、ルーター２０２は、公開鍵暗号に基づき、ホスト２０６を認証する。
【００９３】
認証が成功したら、ルーター２０２は、ＩＰｖ６のグローバルアドレスのプレフィックスとホスト２０６のインターフェイス３０１のインターフェイスＩＤ　とからホスト２０６のＩＰｖ６グローバルアドレスを生成する。そして、Ｓ１０３Ａで、乱数ｒを生成し、生成元ｇと公開鍵ｖ＿ｉから前述のように、　（ｇ’、ｖ＿ｉ’）＝（ｇ＾ｒ　ｍｏｄ　ｐ、　（ｖ＿ｉ）＾（ｒ）　ｍｏｄ　ｐ）　を求める（このｇ’とｖ＿ｉ’の二つを匿名公開鍵と呼ぶ）。すなわち、ＣＰＵ　３０３は、公開鍵ｖ＿ｉから公開鍵ｖ＿ｉ’を生成する。そして、ホスト２０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）に対するｒｏｕｔｅｒ　２０２の署名である認証用ｓｉｇｎａｔｕｒｅ（２）を生成する。
【００９４】
なお、ここでは、認証の成功後、公開鍵ｖ＿ｉ’を生成したが、変形例では、認証の成功前、あるいは、匿名公開鍵証明書が要求される前に、予め、公開鍵ｖ＿ｉ’を生成して、ＲＡＭ３０５、ＨＤ３０６に登録しておく。
【００９５】
最後に、ＩＰｖ６のグローバルアドレスと匿名公開鍵とそれらに対する認証用ｓｉｇｎａｔｕｒｅ（２）を含む匿名公開鍵証明書要求メッセージ＝｛ＩＰｖ６グローバルアドレス、匿名公開鍵、認証用ｓｉｇｎａｔｕｒｅ（２）｝を、ステップＳ１０４でネットワーク・インターフェイス３０２からインターネット２０１経由でＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９に送る。すなわち、インターフェイス３０２は、ＣＰＵ　３０３の制御の元に、匿名公開鍵（ｇ’、ｖ＿ｉ’）に対する公開鍵証明書の発行を要求する公開鍵証明書要求メッセージを、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９に送信する。Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９は、公開鍵証明書を発行する発行者、あるいは、発行装置である。ルーター２０２は、公開鍵生成装置である。ルーター２０２のインターフェイス３０１は、ネットワーク２０７を介して通信装置（ホスト２０６）と通信する通信手段であり、ＣＰＵ３０３は、公開鍵を生成する生成手段である。また、ルーター２０２のインターフェイス３０２は、通信装置（ホスト２０６から公開鍵証明書を要求されると、ＣＰＵ３０２により生成された公開鍵を公開鍵証明書発行者（ＣＡ２０９）に送信する送信手段である。
【００９６】
前述のように、ｒｏｕｔｅｒ　２０２とＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９は、インターネット２０１を介して確実で安全な通信が行なえるので、データ内容が改竄されたり第三者になりすまされたりすることはない。
【００９７】
ステップＳ１０５で　Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９は、ネットワーク・インターフェイス３０１から受け取った認証用ｓｉｇｎａｔｕｒｅ（２）が本当に正しいｒｏｕｔｅｒ　２０２に生成されたか否かを確認する。前述の確実で安全な通信によって受け取った場合は、データを受け取った事実自体が正しいｒｏｕｔｅｒ　２０２に生成されたデータであることを証明する場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合もある。
【００９８】
いずれにせよ、認証用ｓｉｇｎａｔｕｒｅ（２）の正当性を確認したＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９は、証明書要求メッセージの中に含まれるＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）に、それらに関する管理・属性情報Ｘを付加したメッセージ（のハッシュ値）に対してディジタル署名Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）を生成する。このディジタル署名には、秘密鍵ｓ＿ｃａを用いる。証明書の管理・属性情報Ｘは、公開のパラメータや証明書の有効期限、ｖ＿ｃａに対する公開鍵証明書等を含む。本発明の変形例では、この情報Ｘには、ｖ＿ｃａに対する公開鍵証明書は、含めない。匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、ＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）とそれらに関する管理・属性情報Ｘとそれらに対するディジタル署名からなるデータである。すなわち、インターフェイス３０１が、ルーター２０２から公開鍵証明書要求メッセージを受信すると、ＣＰＵ　３０３は、公開鍵証明書要求メッセージに含まれるＩＰｖ６グローバルアドレスのアドレス情報と公開鍵（ｇ’、ｖ＿ｉ’）（および証明書の管理・属性情報Ｘ）を含むメッセージに対して、ディジタル署名を生成する。ルーター２０２は、アドレスを設定するためのアドレス情報をホスト２０２（通信装置）に提供する提供者である。
【００９９】
そして、ステップＳ１０６で匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））をネットワーク・インターフェイス３０１からインターネット２０１経由でｒｏｕｔｅｒ　２０２に送る。すなわち、インターフェイス３０１は、ＩＰｖ６グローバルアドレスのアドレス情報と、公開鍵（ｇ’、ｖ＿ｉ’）と、ディジタル署名を含む公開鍵証明書を発行する。
【０１００】
匿名公開鍵証明書をネットワーク・インターフェイス３０２から受け取ったｒｏｕｔｅｒ　２０２は、ステップＳ１０７で、ＩＰｖ６グローバルアドレスのプレフィックスとｄｅｆａｕｌｔｒｏｕｔｅｒ　２０２のアドレスと匿名公開鍵証明書からなるＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを認証されたホスト２０６にネットワーク・インターフェイス３０１から送る。ここで、本発明の一実施例では、登録された公開鍵ｖ＿ｉを用いて暗号化して、送信する。すなわち、インターフェイス３０１は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９により公開鍵（ｇ’、ｖ＿ｉ’）に対して発行された公開鍵証明書を、ホスト２０６に送信する。ホスト２０６は、Ｓ１０３において認証された通信装置であり、Ｓ１０３において正当性が確認されたディジタル署名を含むＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎの送信元である。
【０１０１】
ステップＳ１０８でホスト２０６はネットワーク・インターフェイス３０１から受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔからプレフィックスを取り出し、ＩＰｖ６グローバルアドレスを生成し、匿名公開鍵証明書の正当性を確認する。
【０１０２】
ここで、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の公開鍵　ｖ＿ｃａを用いて、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の正当性、すなわち、（ｇ’、ｖ＿ｉ’）とＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）の対応関係の正しさを確認する。例えば、ホスト２０６は、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし　｜　は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の公開鍵　ｖ＿ｃａを予め記憶している。匿名公開鍵証明書の管理・属性情報Ｘに公開鍵　ｖ＿ｃａの公開鍵証明書が含まれている形態では、ホスト２０６は、予め記憶している公開鍵　ｖ＿ｃａが、匿名公開鍵証明書の管理・属性情報Ｘに含まれている公開鍵　ｖ＿ｃａの公開鍵証明書中の公開鍵ｖ＿ｃａと一致することを確認してから、この公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。
【０１０３】
以上のプロトコルを既存のＲｏｕｔｅｒ　ＳｏｌｉｃｉｔａｔｉｏｎとＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔの送受信プロトコルと組み合わせた拡張プロトコルのホストの動作フローチャートを図１１に示す。
【０１０４】
図１１のステップＳ１１０１におけるＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎメッセージとは、図９のステップ９０１のＲｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎと図１のステップＳ１０２で送られるＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎの両方を含むデータである。ルーター２０２は、このデータを受信すると、図１のＳ１０３、Ｓ１０３Ａ、Ｓ１０４の処理を行ない、Ｓ１０６と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９から匿名公開鍵証明書を受け取る。そして、ルーター２０２は、Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　のみを指定するＲｏｕｔｅｒ　ＡｄｖｅｒｔｉｓｅｍｅｎｔとＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔの両方を含むＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを、ホスト２０６に送る。
【０１０５】
したがって、ステップＳ１１０２で受け取るＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅとは、図９のステップＳ９０２で受け取るＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅと図１のステップＳ１０７で受け取るＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔの両方を含むデータである。
【０１０６】
図１におけるステップＳ１０８を行なって正当性が確認できたならば、ステップＳ１１０２で「はい」の場合となり、ステップＳ１１０３において、ＩＰｖ６グローバルアドレスを生成し、インターフェイス３０１に割当てるとともに、匿名公開鍵証明書の正当性を確認する。ここでは、Ｓ１０８と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の公開鍵　ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。
【０１０７】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書を発行することができる。
【０１０８】
なお、ルーター２０２の代りにＤＨＣＰサーバー２０３がＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９に信用されている場合は、Ｒｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅが受信されないので、図１１におけるステップＳ１１０６において図１と同様のプロトコルをルーター２０２の代りにＤＨＣＰサーバー２０３が実行する。なお、ＤＨＣＰサーバーの管理元はｄｅｆａｕｌｔ　ｇａｔｅｗａｙ２０２の管理元と同様にトラブルの際の責任を持つものとする。
【０１０９】
この場合には図１１のステップＳ１１０６で、ホストはｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの拡張プロトコル、つまりＤＨＣＰサーバーからアドレスと証明書を取得するプロトコルを実行する。その動作フローチャートを図１２に示す。
【０１１０】
図１０のプロトコルとの違いは、ステップＳ１２０３とステップＳ１２０４の二カ所である。
【０１１１】
ステップＳ１２０３で送るＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅは、図１０のステップＳ１００３で送るＤＨＣＰ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅ　と図１のステップＳ１０２で送られるＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ相当のデータ（送信先が、ルーター２０２ではなくＤＨＣＰサーバー２０３である点が異なる）の両方を含むデータである。
【０１１２】
このメッセージを受け取ると、ＤＨＣＰサーバー２０３は、図１のＳ１０３、Ｓ１０３Ａ、Ｓ１０４の処理を行ない、Ｓ１０６と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９から匿名公開鍵証明書を受け取る。そして、ＤＨＣＰサーバー２０３は、ＤＨＣＰ　Ｒｅｐｌｙ　ＭｅｓｓａｇｅとＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ相当のデータの両方を含むＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅを、ホスト２０６に送る。
【０１１３】
したがって、ステップＳ１２０４で受け取るＤＨＣＰ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅは、図１０のステップＳ１００４で受け取るＤＨＣＰ　Ｒｅｐｌｙ　Ｍｅｓｓａｇｅと図１のステップＳ１０７で受け取るＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ相当のデータ（送信元がルーター２０２ではなくＤＨＣＰサーバー２０３である点が異なる）の両方を含むデータである。そして、ＩＰｖ６グローバルアドレスを生成し、インターフェイス３０１に割当てるとともに、匿名公開鍵証明書の正当性を確認する。ここでは、Ｓ１０８と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の公開鍵　ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。
【０１１４】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なＩＰｖ６アドレスと対応する使い捨て匿名公開鍵証明書を発行することができる。
【０１１５】
ルーター２０２およびＤＨＣＰサーバー２０３の両方がＣＡのＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９に信用されている場合は、図１１におけるステップＳ１１０４で　ｓｔａｔｅｌｅｓｓ　と　ｓｔａｔｅｆｕｌ　の両方を指定するＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　Ｍｅｓｓａｇｅを受け取った場合（「はい」の場合）が相当し、上記に示した二つの拡張プロトコルを任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、使い捨てＩＰｖ６グローバルアドレスとそれに対応する使い捨て匿名公開鍵証明書、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ等を自動設定および取得する。この場合、ルーター２０２およびＤＨＣＰサーバー２０３は、アドレスを設定するためのアドレス情報をホスト（通信装置）２０６に提供する情報処理装置群に相当し、この情報処理装置群であるルーター２０２およびＤＨＣＰサーバー２０３は、公開鍵証明書をＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９に要求し、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９が発行した公開鍵証明書をホスト２０６に送信する。
【０１１６】
ルーター２０２でもＤＨＣＰサーバー２０３でもない別のＩＰｖ６対応装置の専用ＣＡサーバーが公開鍵証明書発行者２０９に信用されており、専用ＣＡサーバーと公開鍵証明書発行者２０９とが協調して動作して公開鍵証明書をあるホストに発行する場合、その専用ＣＡサーバーが対象ホストと同一のローカルリンク２０７内に存在するならば、図１示のルーター２０２の動作とほぼ同様の動作によって、公開鍵証明書を発行できる。
【０１１７】
図２において、対象ホストがホスト２０６であり、専用ＣＡサーバーがホスト２０４である場合、それらの間の動作は図１と同様である。ただし、専用ＣＡサーバーはそのサブネット、図２の場合で言えばリンク２０７に割当てられている正しいＩＰｖ６プレフィクスを知っているという前提を必要とする。したがってルーター２０２の管理者と同様の責任を有する管理者によって専用ＣＡサーバーは管理されており、問題がおこったときの対応等についてもルーター２０２の場合と同様にＣｅｒｔｉｆｉｃａｔｉｏｎＡｕｔｈｏｒｉｔｙ　２０９と管理者との間で合意がなされている必要がある。
【０１１８】
ホスト２０６は、通信相手が変る度に、あるいは、セッションが変る度に、若しくは、通信パケット送信の度に、図１１のＳ１１０１のＲｏｕｔｅｒ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎメッセージ（図１のＳ１０１の匿名公開鍵証明書を要求するメッセージであるＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ）を、インターフェイス３０１から、リンク２０７に送出し、Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ　２０９からの匿名公開鍵証明書を受け取る。すなわち、ホスト２０６は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。ここで、公開鍵（ｇ’、ｖ＿ｉ’）は、同一のエンティティの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１１９】
なお、ルーター２０２あるいはＤＨＣＰサーバー２０３がＩＰｖ６アドレスのプレフィックスをホスト２０６に提供する形態を説明したが、ＩＰｖ６アドレスそのものを提供する形態ではプレフィックスのかわりにアドレスが送られる点とホストがアドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１２０】
（第２の実施の形態）
第１の実施の形態では、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ルーター）がホストを認証してから、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ（ルーター）とＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙが協調動作して、匿名公開鍵証明書とプレフィックスを含む　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　をホストに送った。本実施の形態では、プレフィックスの送付と匿名公開鍵証明書の発行が独立な例を説明する。
【０１２１】
第１の実施の形態と同様に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９がエンティティＣＡ、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。但し、Ｃｅｒｔｉｆｉｃａｉｔｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９が前述の匿名公開鍵証明書方式におけるＣＡの全ての機能を有するわけではない。以下では、匿名公開鍵証明書を利用するＩＰｖ６対応装置（ホスト２０６）の位置するローカルリンク２０７内に存在し、かつ、公開鍵証明書発行者（ＣＡ、つまりＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ２０９）が信用するＩＰｖ６対応装置がｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２である場合を説明する。つまり、匿名公開鍵証明書方式におけるエンティティＣＡの機能の一部は、Ｃｅｒｔｉｆｉｃａｉｔｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の代わりに、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２が有する場合を説明する。
【０１２２】
なお、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９が信用するＩＰｖ６対応装置はＤＨＣＰサーバーや専用サーバーでもよい。また、以下では、ランダムなＩＰｖ６アドレスを証明書の中に含める形態を説明するが、ランダムなＩＰｖ６アドレスを証明書に含めない形態もあるかもしれない。前述のように、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２をルーター２０２と呼ぶことにする。ここでは、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２は、ホスト２０６に、ＩＰｖ６のグローバルアドレスのプレフィックスを提供する。
【０１２３】
また、この場合には、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９とｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２（あるいはＤＨＣＰサーバーや専用サーバー）は、例えば、公開鍵暗号を安全に交換してあるとか秘密の暗号化鍵を安全に共有してある等により、それらの間では、インターネットを介して確実で安全な通信が行なえるものとする。Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の管理者は、ＣＡとしての公開鍵ｖ＿ｃａを定める。ルーター２０２の管理者は、前述の公開パラメータｐ、ｇ等を定め、公開する。ルーター２０２の公開鍵ｖ＿ｒｏｕｔｅｒも定め、公開する。
【０１２４】
ユーザｉがＬＡＮへのアクセスを申請する際に、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＬＡＮの管理者（ルーター２０２の管理者）に提出する。ＬＡＮの管理者（ルーター２０２の管理者）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０４もしくはＨＤ３０６に登録する。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト２０６で安全に利用可能になっているものとする。
【０１２５】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１５に示す。図１５は、匿名公開鍵証明書を利用するエンティティ　（ユーザｉが用いるＩＰｖ６端末）をホスト２０６、プレフィックスを提供するＩＰｖ６端末をｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　２０２、匿名公開鍵証明書を発行するＣＡをＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９とし，それらの間で行なわれる匿名公開鍵証明書の発行プロトコルの動作フローを表している。
【０１２６】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター２０２とエンティティ（この場合は、ホスト２０６）の間でなんらかの特定（認証）プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１５を参照しながら動作を説明する。
【０１２７】
ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。そして、ＭＡＣアドレスから生成したインターフェイスＩＤに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（ＲＳ）をルーターに送る（ステップＳ１５０１）。ＲＳは前述のようにリンク上のルーター全て宛の　ｍｕｌｔｉｃａｓｔ　である。
【０１２８】
ルーター２０２は、ＲＳを受け取ったら、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔ　（ＲＡ）を送る（ステップＳ１５０２）。
【０１２９】
ＲＡを受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤとプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ　ａｄｄｒｅｓｓと呼ぶ）を生成する。また、ランダムなインターフェイスＩＤとプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓと呼ぶ）を作る。そして、ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ　とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる（ステップＳ１５０３）。
【０１３０】
次に、ホスト２０６はＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成する（ステップＳ１５０４）。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎは、匿名公開鍵証明書を要求するメッセージであり、ホスト２０６が匿名公開鍵証明書を要求する旨を含むデータであることをルーター２０２が理解できる形式で生成する。例えば、ＲＦＣ２９８６，　｀｀ＰＫＣＳ　＃１０：Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ｒｅｑｕｅｓｔ　Ｓｙｎｔａｘ　Ｓｐｅｃｉｆｉｃａｔｉｏｎ　Ｖｅｒｓｉｏｎ　１．７，’’で規定されているＰＫＣＳ＃１０や、ＲＦＣ２５１１，　｀｀Ｉｎｔｅｒｎｅｔ　Ｘ．５０９　Ｃｅｒｔｉｆｉｃａｔｅ　Ｒｅｑｕｅｓｔ　Ｍｅｓｓａｇｅ　Ｆｏｒｍａｔ’’等がそれらの形式を規定している。詳細の説明は省くが、証明書要求メッセージと、それに対する（ホストの）署名からなるデータであるとする。証明書要求メッセージには、ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓが含まれている。
【０１３１】
次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを、リンク２０７を介してルーター２０２に送る（ステップＳ１５０５）。なお、この時点でルーター２０２の（ユニキャスト）アドレスをホスト２０６は知っているので　ｕｎｉｃａｓｔ　することが可能である。
【０１３２】
ルーター２０２はステップＳ１５０５で受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名（ホスト２０６の識別子もしくはホスト２０６を利用するユーザの名前）から登録された公開鍵ｖ＿ｉをＲＡＭ　３０５もしくはＨＤ３０６から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト２０６の匿名公開鍵を作成する。具体的には、前述のｇ’、ｖ＿ｉ’、ｐ、ｑが匿名公開鍵である。そして、匿名公開鍵に対する証明書をＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９に発行してもらうため、匿名公開鍵証明書要求メッセージを生成する（ステップＳ１５０６）。
【０１３３】
次に、ルーター２０２は、匿名公開鍵証明書要求メッセージをＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ２０９に送る（ステップＳ１５０７）。この匿名公開鍵証明書要求メッセージの形式は前述の証明書要求メッセージと同様とし、匿名公開鍵証明書要求メッセージとそれに対するルーターの署名からなるデータ等であるとする。この匿名公開鍵証明書要求メッセージにはホスト２０６のｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓが含まれている。
【０１３４】
匿名公開鍵証明書要求メッセージをルーター２０２から受け取ったＣｅｒｔｉｆｉｃａｔｉｏｎＡｕｔｈｏｒｉｔｙ２０９は、それがルーター２０２によって作成されたか正しいデータであるか否かを確認する。例えば、前述の確実で安全な通信によって受け取った場合は、データを受け取った事実自体が正しいｒｏｕｔｅｒ　２０２に生成されたデータであることを証明するとみなせる場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合にはルーターの公開鍵ｖ＿ｒｏｕｔｅｒで確認できる場合もある。
【０１３５】
いずれにせよ、匿名公開鍵証明書要求メッセージの正当性を確認したＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９は、証明書要求メッセージの中に含まれる匿名公開鍵（ｇ’、ｖ＿ｉ’、ｐ、ｑ）とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓ、それらに関する管理・属性情報を付加したメッセージ（のハッシュ値）に対してディジタル署名を生成し、そのメッセージと、署名からなる匿名公開鍵証明書を生成する（ステップＳ１５０８）。本発明のある形態では、この匿名公開鍵証明書は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９の公開鍵を含む。
【０１３６】
そして、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９は匿名公開鍵証明書を、ルーター２０２に送る（ステップＳ１５０９）。本発明のある形態では、この匿名公開鍵証明書を登録された公開鍵を用いて暗号化して、送信する。
【０１３７】
ルーター２０２は、匿名公開鍵証明書を含むＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを、ホスト２０６に送る（ステップＳ１５１０）。本発明のある形態では、このＣｅｒｔｉｆｉｃａｔｅＡｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。なお、このとき、ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓ宛のｕｎｉｃａｓｔとして、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ２０９から直接ホスト２０６に送ることも可能である。
【０１３８】
ホスト２０６は受け取ったＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔから匿名公開鍵証明書の正当性を確認する（ステップＳ１５１１）。
【０１３９】
以上のプロトコルを既存のｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎおよびｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎと組み合わせた拡張プロトコルのホストの動作フローチャートを図１６に示す。
【０１４０】
ホスト２０６は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス（図３の３０１）のＭＡＣアドレスからインターフェイスＩＤを生成する。また、ホスト２０６は、例えばＲＦＣ３０４１のアルゴリズムによってランダムなインターフェイスＩＤを生成する。そして、ＭＡＣアドレスから生成したインターフェイスＩＤに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない　Ｒｏｕｔｅｒ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（ＲＳ）　をルーターに送る（ステップＳ１７０１）。ＲＳは前述のようにリンク上のルーター全て宛の　ｍｕｌｔｉｃａｓｔ　である。
【０１４１】
ステップＳ１７０２の「はい」の場合に示すように、Ｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ　のみを指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージ（ＲＡ）を受け取ったホスト２０６は、ＲＡに含まれるプレフィックスを抽出し、ＭＡＣアドレスから生成したインターフェイスＩＤと抽出したプレフィックスとから、グローバルアドレス（ｐｕｂｌｉｃ　ａｄｄｒｅｓｓと呼ぶ）を生成する。また、ランダムなインターフェイスＩＤ　と抽出したプレフィックスとから、使い捨てＩＰｖ６アドレス（ｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓと呼ぶ）を作る。そして、ｐｕｂｌｉｃ　ａｄｄｒｅｓｓ　とｔｅｍｐｏｒａｒｙ　ａｄｄｒｅｓｓの重複検出ＤＡＤ（Ｄｕｐｌｉｃａｔｅ　Ａｄｄｒｅｓｓ　Ｄｅｔｅｃｔｉｏｎ）を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる（ステップＳ１７０３）。
【０１４２】
次に、ホスト２０６は、証明書要求と証明書発行のプロトコルを実行する（ステップＳ１７０７）。すなわち、ホスト２０６は、図１５のステップＳ１５０４、Ｓ１５０５で示したように、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎを生成し、ルーター２０２に送る。ホスト２０６は、ルーター２０２からＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを受け取り、その中に含まれる匿名公開鍵証明書の正当性を確認する。なお、Ｒｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔを何も受け取らなかった場合は（ステップＳ１７０４のいいえの場合）、ｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎ、すなわちＤＨＣＰｖ６のみを実行する。これがステップＳ１７０６であり、その詳細は図１０のプロトコルと同じである。
【０１４３】
ステップＳ１７０４でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を指定するＲｏｕｔｅｒ　Ａｄｖｅｒｔｉｓｅｍｅｎｔメッセージを受け取った場合は、ステップＳ１７０５でｓｔａｔｅｌｅｓｓ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎとｓｔａｔｅｆｕｌ　ａｄｄｒｅｓｓ　ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎの両方を行なう。処理内容はステップＳ１７０３とＳ１７０６と同じである。
【０１４４】
（第３の実施の形態）
本実施の形態では、ホストがダイヤルアップあるいはＡＤＳＬのような方式でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本発明の形態を説明する。
【０１４５】
図１４は、本発明が適用される接続環境を模式的に示したものである。図１４は、ホスト１４０６がＰＳＴＮ（Ｐｕｂｌｉｃ　Ｓｗｉｔｃｈｅｄ　Ｔｅｌｅｐｈｏｎｅ　Ｎｅｔｗｏｒｋ）経由でＩＳＰ（Ｉｎｔｅｒｎｅｔ　Ｓｅｒｖｉｃｅ　Ｐｒｏｖｉｄｅｒ）の提供するインターネット１４０１とアクセスする環境を示す。本実施の形態では、ＩＳＰとホストはＰＰＰリンクで接続するものとする。
【０１４６】
図１４において、ＩＳＰのＰＰＰ　ｐｅｅｒ　１４０２はノードであり、ｍｏｄｅｍ　１４０３を用いてＰＳＴＮ　１４０４を介してホスト１４０６からのＰＰＰ接続の要求を受け付ける。ＰＰＰ　ｐｅｅｒ　１４０２は、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　ｍｏｄｕｌｅ　１４０２１、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３としての機能を有する。ホスト１４０６はｍｏｄｅｍ　１４０５を用いてＰＰＰ　ｐｅｅｒ　１４０２にＰＰＰ接続でアクセスする。ホスト１４０６の構成は、図３と同様であり、ネットワーク・インターフェイス３０１を介して、モデム１４０５を接続する。また、ＰＰＰ　ｐｅｅｒ　１４０２の構成も、図３と同様であり、ネットワーク・インターフェイス３０１を介して、モデム１４０３を接続し、ネットワーク・インターフェイス３０２を介して、リンク１４０７（さらに、インターネット１４０１）と接続する。ＰＰＰ　ｐｅｅｒ　１４０２は、アドレスを設定するためのアドレス情報をホスト１４０６（通信装置）に提供するアドレス情報提供装置である。
【０１４７】
本実施の形態では、ｍｏｄｅｍとＰＳＴＮを例として取り上げて説明するが、ＴＡ（Ｔｅｒｍｉｎａｌ　Ａｄａｐｔｅｒ）とＩＳＤＮ（Ｉｎｔｅｇｒａｔｅｄ　Ｓｅｒｖｉｃｅｓ　Ｄｉｇｉｔａｌ　Ｎｅｔｗｏｒｋ）、ＰＨＳ通信アダプターとＰＨＳ通信網、専用線接続装置と専用線等の他の通信形態であったとしてもＰＰＰ接続が確立できる環境であれば本質的には同じである。ＰＰＰ接続の詳細は、ＲＦＣ　１６６１　｀｀Ｔｈｅ　Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ　Ｐｒｏｔｏｃｏｌ　（ＰＰＰ）’’　に記述されている。
【０１４８】
ホスト１４０６がモデム１４０５、ＰＳＴＮ１４０４、モデム１４０３を介してＰＰＰ接続の要求をＰＰＰｐｅｅｒ　１４０２に伝える。ＰＰＰ　ｐｅｅｒ　１４０２は、その接続要求を受け、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３がホストの認証を行なう。典型的な認証方式は、ユーザ名とパスワードに基づく認証プロトコルＣＨＡＰであり、詳細はＲＦＣ１９９４　｀｀ＰＰＰ　Ｃｈａｌｌｅｎｇｅ　Ｈａｎｄｓｈａｋｅ　Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　Ｐｒｏｔｏｃｏｌ’’に記述されている。
【０１４９】
認証が完了したら、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２がその設定に従いＩＰｖ６グローバルアドレス（のプレフィックス）やｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６アドレス等をホスト１４０６に伝える。ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２は、ＩＳＰの管理者がその運用方針に従った設定を行なっている。
【０１５０】
なお、図１４では説明を簡単にするため、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　とＤＨＣＰサーバーとＡｕｔｈｅｎｔｉｃａｔｉｏｎ　サーバーをそれぞれｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　ｍｏｄｕｌｅ　１４０２１、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２、Ａｕｔｈｅｎｔｉｃａｔｉｏｎ　ｍｏｄｕｌｅ　１４０２３としてＰＰＰ　ｐｅｅｒ内部に存在するものとしているが、実際にはリンク１４０７上にそれぞれ異なるノードとして存在することもある。いずれの実現形態にせよ、それらのｍｏｄｕｌｅあるいはノードはＩＳＰの管理者の元で安全に運用されていれば、構わないので、以下では、図１４の形態でホストとＰＰＰ　ｐｅｅｒの間のＰＰＰリンクが確立したものとして説明する。
【０１５１】
ホスト１４０６は、ＤＨＣＰ　ｍｏｄｕｌｅ　１４０２２からＩＰｖ６グローバルアドレス（のプレフィックス）やｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６アドレス等を受け取ったならば、ＩＰｖ６グローバルアドレス（のプレフィックスと自分の（ＲＦＣ３０４１等の方法で生成した）ランダムなインターフェイスＩＤとを組み合わせてランダムなＩＰｖ６グローバルアドレスを生成し、それがリンクにおいて重複していないことを確認してから　それをインターフェイス３０１に割当て、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　のＩＰｖ６アドレスを記憶する。
【０１５２】
以上の動作により、ホスト１４０６は使い捨てＩＰｖ６アドレスを使ってインターネットの任意の相手と通信できる。
【０１５３】
次に、本発明の実施の形態を説明する。上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。
【０１５４】
以下では、匿名公開鍵証明書方式を、図１４の環境に適用した形態を説明する。Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８がＣＡ、ホスト１４０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。以下では、ランダムなＩＰｖ６アドレスを証明書の中に含める形態を説明するが、ランダムなＩＰｖ６アドレスを含めないことも可能である。
【０１５５】
Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８　は、前述の公開パラメータｐ、ｇ等を定め、自分の秘密鍵ｓ＿ｃａと公開鍵ｖ＿ｃａを定め、公開する。Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ１４０８　は　ＰＰＰ　ｐｅｅｒ　１４０２　を信用するものとする。つまり、ＰＰＰ　ｐｅｅｒ　１４０２　の管理元、すなわちＩＳＰとの間で、問題が生じたときの責任について合意がなされており、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８　と　ＰＰＰ　ｐｅｅｒ　１４０２　との間では確実で安全な通信が行なえるようになっている。
【０１５６】
ユーザｉがＩＳＰに加入を申請する際に、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８　が公開しているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、ユーザ名とパスワード、公開鍵ｖ＿ｉをＩＳＰに提出する。ＩＳＰの管理元（ＰＰＰ　ｐｅｅｒ１４０２の管理元）は、その運用方針に応じてユーザｉの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、ユーザ名に対応して公開鍵ｖ＿ｉが検索できるように、ＲＡＭ　３０５もしくはＨＤ３０６に登録する。公開パラメータや公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはユーザｉが管理し、ホスト１４０６で安全に利用可能になっているものとする。
【０１５７】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１３に示す。図１３は、エンティティ（ユーザｉが用いるＩＰｖ６通信装置）をホスト１４０６、ＣＡをＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８とし、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８　は　ＰＰＰｐｅｅｒ　１４０２　を信用し、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。
【０１５８】
ＰＰＰ接続におけるデータリンク層の処理が終わった後、前述のユーザ名とパスワードに基づく認証プロトコルＣＨＡＰによる認証を行なう。
【０１５９】
すなわち、ホスト１４０６はステップＳ１３０１でエンティティ名（ユーザ名）をインターフェイス３０１からＰＰＰ　ｐｅｅｒ１４０２に送る。ステップＳ１３０２でエンティティ名（識別子）をインターフェイス３０１から受信すると、ＰＰＰ　ｐｅｅｒ　１４０２はＣＨＡＰ−ｃｈａｌｌｅｎｇｅを生成し、ステップＳ１３０３でそれをホスト１４０６にインターフェイス３０１から送る。
【０１６０】
ホスト１４０６は、ステップ　Ｓ１３０４でＣＨＡＰ−ｃｈａｌｌｅｎｇｅをインターフェイス３０１から受信すると、エンティティ名とパスワードとＣＨＡＰ−ｃｈａｌｌｅｎｇｅをハッシュ関数に入力して求めた結果の値ＣＨＡＰ−ｒｅｓｐｏｎｓｅをステップＳ１３０５でＰＰＰ　ｐｅｅｒ　１４０２にインターフェイス３０１から送る。
【０１６１】
ステップＳ１３０６でＰＰＰ　ｐｅｅｒ　１４０２は、ＣＨＡＰ−ｒｅｓｐｏｎｓｅ　をインターフェイス３０１から受信し、ＣＨＡＰ−ｒｅｓｐｏｎｓｅの正当性を確認する。確認出来たならば認証は成功なので、その認証されたホスト１４０６に対してＩＰｖ６グローバルアドレス（のプレフィックス）やｄｅｆａｕｌｔ　ｇａｔｅｗａｙ　のアドレスをステップＳ１３０７でインターフェイス３０１から伝える。
【０１６２】
ホスト１４０６は、ステップＳ１３０８で、インターフェイス３０１から受信したＩＰｖ６グローバルアドレス（のプレフィックスとランダムなインターフェイスＩＤとからＩＰｖ６グローバルアドレスを生成し、それ）が重複していないことを確認してからそれをインターフェイス３０１に割当て、ｄｅｆａｕｌｔ　ｇａｔｅｗａｙのアドレスも記憶する。次に匿名公開鍵証明書を要求するメッセージとしてＣｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　をステップＳ１３０９でＰＰＰ　ｐｅｅｒ　１４０２にインターフェイス３０１から送る。
【０１６３】
Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　は、第１の実施の形態と同様に、匿名公開鍵証明書を要求する旨とインターフェイスＩＤを含むデータであることをＰＰＰ　ｐｅｅｒ　１４０２が理解できる形式で生成される。内容は、エンティティ名（ユーザ名）とパスワードとシリアル番号から計算され、シリアル番号は、例えば、ホスト２０６のＩＰｖ６リンクローカルアドレスとｄｅｆａｕｌｔ　ｇａｔｅｗａｙのＩＰｖ６リンクローカルアドレスとそのときの時刻の３つを連接して一つのデータにした値である。Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎには、エンティティ名（ユーザ名）とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名（認証用ｓｉｇｎａｔｕｒｅ）が含まれる。
【０１６４】
ＰＰＰ　ｐｅｅｒ　１４０２は、ステップＳ１３１０で、Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　をインターフェイス３０１から受信すると、図１のＳ１０３Ａと同様に、エンティティ名（ホスト（通信装置）２０６の識別子であるユーザ名）に対応する登録された公開鍵ｖ＿ｉをＲＡＭ　３０５もしくはＨＤ３０６から検索し、前述のように乱数ｒを生成して匿名公開鍵（ｇ’とｖ＿ｉ’）　（＝（ｇ＾ｒ　ｍｏｄ　ｐ、　（ｖ＿ｉ）＾（ｒ）　ｍｏｄ　ｐ））を生成し、ホスト１４０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’とｖ＿ｉ’）に対する認証用ｓｉｇｎａｔｕｒｅを生成する。そして、ホスト１４０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）と認証用ｓｉｇｎａｔｕｒｅからなる証明書要求メッセージをステップＳ１３１１でＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８にネットワーク・インターフェイス３０２から送る。
【０１６５】
前述の確実で安全な通信によって受け取った場合は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８が、ＰＰＰ　Ｐｅｅｒ　１４０２からのデータをネットワーク・インターフェイス３０１から受け取った事実自体が正しい　ＰＰＰ　Ｐｅｅｒ　１４０２に生成されたデータであることを証明する場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合もある。
【０１６６】
いずれにせよ、図１のＳ１０５と同様に、ステップＳ１３１２で認証用ｓｉｇｎａｔｕｒｅの正当性を確認したＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８は、ホスト１４０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）と管理・属性情報Ｘに対するディジタル署名Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）を生成し、ホスト１４０６のＩＰｖ６グローバルアドレスと匿名公開鍵（ｇ’、ｖ＿ｉ’）と管理・属性情報Ｘとそれらに対するディジタル署名からなる匿名公開鍵証明書を生成する。そして、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８は、ステップＳ１３１３でネットワーク・インターフェイス３０１からＰＰＰ　Ｐｅｅｒ　１４０２にその匿名公開鍵証明書を送る。なお、管理・属性情報Ｘには、この匿名公開鍵証明書の有効期限などが含まれる。
【０１６７】
ＰＰＰ　Ｐｅｅｒ　１４０２は、それをネットワーク・インターフェイス３０２から受け取り、ステップＳ１３１４でＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔすなわち匿名公開鍵証明書をインターフェイス３０１からホスト１４０６に送る。ホスト１４０６はネットワーク・インターフェイス３０１から受け取った匿名公開鍵証明書の正当性をステップＳ１３１５で確認する。
【０１６８】
ここで、ホスト１４０６は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８の公開鍵　ｖ＿ｃａを用いて、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の正当性、すなわち、（ｇ’、ｖ＿ｉ’）とＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）の対応関係の正しさを確認する。例えば、ホスト１４０６は、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし　｜　は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。ホスト１４０６は、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８の公開鍵　ｖ＿ｃａを予め記憶している。匿名公開鍵証明書の管理・属性情報Ｘに公開鍵　ｖ＿ｃａの公開鍵証明書が含まれている形態では、ホスト１４０６は、予め記憶している公開鍵　ｖ＿ｃａが、匿名公開鍵証明書の管理・属性情報Ｘに含まれている公開鍵　ｖ＿ｃａの公開鍵証明書中の公開鍵ｖ＿ｃａと一致することを確認してから、この公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。
【０１６９】
以上のプロトコルにおいて、ステップＳ１３０５とＳ１３０９で送受されるデータを一つにまとめてステップＳ１３０５で送ることも可能である。図示しないが、その場合、ホスト１４０６はランダムなインターフェイスＩＤとＣＨＡＰ−ｒｅｓｐｏｎｃｅと　Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｏｌｉｃｉｔａｔｉｏｎ　（第１の実施例と同様）をステップＳ１３０５’でＰＰＰ　ｐｅｅｒ１４０２に送る。
【０１７０】
ステップＳ１３０６’で、ＰＰＰ　ｐｅｅｒ　１４０２は、ＣＨＡＰ−ｒｅｓｐｏｎｓｅの正当性を確認し、登録された公開鍵ｖ＿ｉを検索し、（ＩＰｖ６プレフィックスとインターフェイスＩＤとから）ホスト１４０６　に割当てるＩＰｖ６グローバルアドレス（を生成し、それ）とそのライフタイム（使用期限、例えば２４時間等）等を含めたデータを生成し、認証用ｓｉｇａｎｔｕｒｅと証明書要求メッセージを生成してステップＳ１３０７’でＣｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ
１４０８に送る。
【０１７１】
Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　１４０８はステップＳ１３０８’でステップＳ１３１２と同様の処理を行ない、ステップＳ１３０９’で匿名公開鍵証明書をＰＰＰ　Ｐｅｅｒ　１４０２に送る。ＰＰＰ　Ｐｅｅｒ　１４０２はステップＳ１３１０’でＣｅｒｔｉｆｉｃａｔｅ　Ａｄｖｅｒｔｉｓｅｍｅｎｔをホスト１４０６に送る。ホスト１４０６は受け取った匿名公開鍵証明書の正当性をステップＳ１３１１’で確認する。
【０１７２】
ホスト１４０６は、通信相手が変る度に、あるいは、セッションが変る度に、若しくは、通信パケット送信の度に、図１３の手順を実行し、　Ｃｅｒｔｉｆｉｃａｔｅ　Ａｕｔｈｏｒｉｔｙ　１４０８からの匿名公開鍵証明書を受け取る。すなわち、ホスト１４０６は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。ここで、公開鍵（ｇ’、ｖ＿ｉ’）は、同一のエンティティの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１７３】
なお、以上の説明ではＰＰＰ　Ｐｅｅｒ　１４０２がＩＰｖ６プレフィックスをｈｏｓｔ　１４０６に伝え、ｈｏｓｔ１４０６がＩＰｖ６プレフィックスとインターフェイスＩＤからＩＰｖ６アドレスを生成する場合を述べたが、ＰＰＰ　Ｐｅｅｒ　１４０２がＩＰｖ６アドレスをｈｏｓｔ１４０６に伝え、ｈｏｓｔ　１４０６がそれを使う場合も同様のプロトコルで実現される。その場合、図３のステップＳ１３０７でＩＰｖ６プレフィックスの代わりにＩＰｖ６アドレスが送られる点とステップＳ１３０８でプレフィックスからＩＰｖ６アドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１７４】
（第４の実施の形態）
第１の実施の形態、第２の実施の形態や第３の実施の形態で発行された使い捨てＩＰｖ６アドレスと使い捨て匿名公開鍵証明書を用いてＩＰｓｅｃ通信を行なう形態を説明する。
【０１７５】
まず、秘密データやお互いのＩＰｖ６アドレス等のデータであるＳＡ（Ｓｅｃｕｒｉｔｙ　Ａｓｓｏｃｉａｔｉｏｎ）を安全に共有するプロトコルであるＩＫＥ（Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ）における公開鍵暗号による暗号化の改訂モードによる認証方法を簡単に説明し、匿名公開鍵証明書を用いる方法を説明する。
【０１７６】
ＩＫＥは二つのｐｈａｓｅからなり、Ｐｈａｓｅ　１において安全な通信路を確立し、ｐｈａｓｅ　２では、ＩＰｓｅｃ等の通信で使用されるＳＡが前記安全な通信路上で合意される。以下では、Ｐｈａｓｅ　１のみを説明する。ＩＫＥのＰｈａｓｅ　１にはＭａｉｎ　ｍｏｄｅとＡｇｇｒｅｓｓｉｖｅ　ｍｏｄｅが存在するが、以下に説明するのは、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ　（ＩＫＥ）’’のｐｐ．１３−１５の５．３　Ｐｈａｓｅ　１　Ａｕｔｈｅｎｔｉｃａｔｅｄ　ｗｉｔｈ　ａ　Ｒｅｖｉｓｅｄ　ｍｏｄｅ　ｏｆ　Ｐｕｂｌｉｃ　Ｋｅｙ　Ｅｎｃｒｙｐｔｉｏｎ　の　Ｍａｉｎ　ｍｏｄｅ　である。
【０１７７】
ＩＫＥにおいて、通信する２エンティティはＩｎｉｔｉａｔｏｒとＲｅｓｐｏｎｄｅｒと呼ばれる。Ｉｎｉｔｉａｔｏｒが通信を開始する。最初に、Ｉｎｉｔｉａｔｏｒが複数のＳＡ（秘密データやお互いのＩＰｖ６アドレス等のデータ）をＲｅｓｐｏｎｄｅｒに送り、Ｒｅｓｐｏｎｄｅｒが使って良いと判断した一つのＳＡをＩｎｉｔｉａｔｏｒに送ることで、ｐｈａｓｅ　１用のＳＡを決定する。
【０１７８】
Ｉｎｉｔｉａｔｏｒは、乱数（Ｎｏｎｃｅと呼ばれる）を生成し、Ｒｅｓｐｏｎｄｅｒの公開鍵で暗号化したデータをＲｅｓｐｏｎｄｅｒに送る。Ｒｅｓｐｏｎｄｅｒは乱数を生成し、Ｉｎｉｔｉａｔｏｒの公開鍵で暗号化したデータをＩｎｉｔｉａｔｏｒに送る。これにより、それぞれの生成したｎｏｎｃｅを共有できるので、他の通信で用いられる暗号の鍵を共有したｎｏｎｃｅから生成する。この詳細は、ＲＦＣ２４０９　｀｀Ｔｈｅ　Ｉｎｔｅｒｎｅｔ　Ｋｅｙ　Ｅｘｃｈａｎｇｅ　（ＩＫＥ）’’に記載されている。以上の説明から明らかなように、通信相手の公開鍵をＩＰｓｅｃ通信に先だって知る必要がある。
【０１７９】
以下のような状況を考える。ある買い物サイトにユーザ２０６（図２）、１４０６（図１４）がアクセスする。このサイトは、インターネット２０１（図２）、１４０１（図１４）に接続されている（不図示）。このサイトは、図３と同様の構成を有し、インターフェイス３０１により、インターネット２０１、１４０１に接続される。なお、サイトの種類は、買い物サイトに限らない。ホスト２０６、１４０６は、この買い物サイトなどのサイトを通信相手とする通信を開始する前に、上述したプロトコルで、Ｉｐｖ６アドレス、及び、公開鍵を含む公開鍵証明書を得ておく。この形態において、上述した公開鍵証明書に基づき鍵交換・更新・変更プロトコルを実行して暗号・認証通信を行なう手順を行なう。
【０１８０】
このとき、ユーザは買い物サイトのＩＰｖ６アドレスを（明示的か非明示的かは問わないが）知っている。実際にアクセスして、そこがユーザにとって正しいサイトであるときに、通信相手のＩＰｖ６アドレスを確認することで、ユーザは明示的にアドレスを知ることができる。通信している最中には、買い物サイトも通信相手２０６、１４０６のアドレスがわかる。以上の通信は使い捨てＩＰｖ６アドレスで行なえる。
【０１８１】
本形態では、送受信者が確定した時点で、使い捨てＩＰｖ６アドレスは（更新せず）同一のアドレスを使う。更に、この時点で、サイトとユーザ２０６、１４０６は、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）をお互いに送り合う。ＩＰｖ６アドレスが使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）のＸの中に含まれているので、両者は、そのＩＰｖ６アドレスが実際に通信している相手のＩＰｖ６アドレスと一致するか否かを確認する。更に、両者は、使い捨て匿名公開鍵証明書の正当性を確認し、それが本当に通信相手の使い捨て匿名公開鍵証明書か否かを判断して、その中に含まれる公開鍵が本当に通信相手の公開鍵か否かを確認する。
【０１８２】
すなわち、ユーザ２０６、１４０６は、使い捨て匿名公開鍵証明書を、インターフェイス３０１から、サイトに送信する。インターネット２０１、１４０１に接続されたサイトは、ユーザ２０６、１４０６からインターフェイス３０１を介して受信した使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれるＩＰｖ６アドレスが、ユーザ２０６、１４０６のＩＰｖ６アドレスと一致するか確認する。更に、サイトは、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９、１４０８の公開鍵　ｖ＿ｃａを用いて、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）の正当性を確認する。ユーザ２０６、１４０６も、同様に、受信した公開鍵証明書に含まれるＩＰｖ６アドレスが、サイトのアドレスと一致するか確認するとともに、Ｃｅｒｔｉｆｉｃａｔｉｏｎ　Ａｕｔｈｏｒｉｔｙ　２０９、１４０８の公開鍵　ｖ＿ｃａを用いて、公開鍵証明書の正当性を確認する。
【０１８３】
使い捨て匿名公開鍵証明書の正当性は、次のように確認する。ホスト２０６、１４０６は、ＣＡ（商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等）２０９（図２）、１４０８（図１４）の公開鍵　ｖ＿ｃａを用いて、使い捨て匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ’、ｖ＿ｉ’、Ｘ、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ））の正当性、すなわち、（ｇ’、ｖ＿ｉ’）とＳｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）の対応関係の正しさを確認する。例えば、ホスト２０６、１４０６は、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）から（ｇ’、ｖ＿ｉ’、Ｘ）を取り出し、そのハッシュ値（例えば、Ｈ（ｇ’｜ｖ＿ｉ’｜Ｘ）、ただし　｜　は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ’、ｖ＿ｉ’、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵ｖ＿ｃａを用いて確認する。ホスト２０６、１４０６は、ＣＡ（商用の認証サービスを提供しているＶｅｒｉＳｉｇｎ等）２０９（図２）、１４０８（図１４）の広く知られている公開鍵　ｖ＿ｃａを、予め記憶している。匿名公開鍵証明書の管理・属性情報Ｘに公開鍵　ｖ＿ｃａの公開鍵証明書が含まれている形態では、ホスト２０６、１４０６は、予め記憶している公開鍵　ｖ＿ｃａが、匿名公開鍵証明書の管理・属性情報Ｘに含まれている公開鍵　ｖ＿ｃａの公開鍵証明書中の公開鍵ｖ＿ｃａと一致することを確認してから、この公開鍵ｖ＿ｃａを用いて、匿名公開鍵証明書の正当性を確認する。
【０１８４】
ホスト２０６、１４０６は、通信相手が変る度に（すなわち、新たに、サイトに接続する度に）、若しくは、セッションが変る毎に、図１１、図１３のプロトコルを実行し、使用するＩＰｖ６アドレス及び公開鍵ｇ’とｖ＿ｉ’を更新・変更する。なお、公開鍵ｇ’とｖ＿ｉ’は、通信パケットの送信毎に、更新・変更してもよい。すなわち、ホスト２０６、１４０６は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、ＩＰｖ６アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。
【０１８５】
以上により、使い捨てＩＰｖ６アドレスとそれを含む使い捨て匿名公開鍵証明書を用いて、ＩＰｖ６アドレスで定義される通信相手の公開鍵を確実に入手できる。このようにして交換した公開鍵を用いて前述のＩＫＥ　の　ｐｈａｓｅ　１　の　Ｍａｉｎ　ｍｏｄｅ　を行ない、そのＩＰｖ６アドレスを持つ通信相手とのＩＰｓｅｃ通信を行なう。
【０１８６】
すなわち、前述のサイトは、ユーザ２０６、１４０６から受信した使い捨て匿名公開鍵証明書が正当な使い捨て公開鍵証明書であることを確認すると、その使い捨て公開鍵証明書の公開鍵（ｇ’、ｖ＿ｉ’）を用いて、インターフェイス３０１により、前述のＩＫＥ　の　ｐｈａｓｅ　１　の　Ｍａｉｎ　ｍｏｄｅ　を行ない、そのＩＰｖ６アドレスを持つユーザ２０６、１４０６とのＩＰｓｅｃ通信を行なう。ユーザ２０６、１４０６も同様に、インターフェイス３０１により、前述のＩＫＥ　の　ｐｈａｓｅ　１　の　Ｍａｉｎ　ｍｏｄｅ　を行ない、そのＩＰｖ６アドレスを持つサイトとのＩＰｓｅｃ通信を行なう。
【０１８７】
従って、課題で述べたような通信相手のなりすましを防ぐことができる。
【０１８８】
【発明の効果】
以上説明したように、本出願に関わる発明によれば、強力なプライバシ保護を実現することができる。
【０１８９】
また、なりすましを防ぐことができる。
【０１９０】
また、ＩＰｖ６アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することができる。
【０１９１】
また、プライバシ保護の程度が高く、低コストで実現が可能で、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能にすることができる。
【０１９２】
また、ＩＰｓｅｃの通信を効率的に実現することができる。
【０１９３】
また、強力なプライバシ保護を実現し、かつなりすましを防ぎながらＩＫＥによるＩＰｓｅｃ通信を行なうことができる。
【図面の簡単な説明】
【図１】第１の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（Ｒ）ＬＡＮの場合）図である。
【図２】イーサネット（Ｒ）ＬＡＮの模式図である。
【図３】ノードの構成図である。
【図４】イーサネット（Ｒ）のＭＡＣアドレスの構成図である。
【図５】インターフェイスＩＤの構成図である。
【図６】ａ　ｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓの構成図である。
【図７】あるｔｅｎｔａｔｉｖｅ　ｌｉｎｋ−ｌｏｃａｌ　ａｄｄｒｅｓｓのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ　ｍｕｌｔｉｃａｓｔ　ａｄｄｒｅｓｓの構成図である。
【図８】ホストがＤＡＤを終えるまでの動作を説明するフローチャート図である。
【図９】ホストがアドレス自動設定を終えるまでの動作を説明するフローチャート図である。
【図１０】ホストがＤＨＣＰでアドレスを取得するまでの動作フローチャート図である。
【図１１】ホストがアドレス自動設定を行ない、匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１２】ホストがＤＨＣＰでアドレスと匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１３】第３の実施の形態における匿名公開鍵証明書発行プロトコル（ＰＰＰの場合）図である。
【図１４】ダイヤルアップ／ＡＤＳＬ接続の模式図である。
【図１５】第２の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（Ｒ）ＬＡＮの場合）図である。
【図１６】ホストが証明書を取得するまでの動作フローチャート図である。
【符号の説明】
３００　ノード
３０１　ネットワーク・インターフェイス
３０２　ネットワーク・インターフェイス
３０６　ＨＤ（ハードディスク）
３０８　キーボード／ポインティングデバイスのインターフェイス
３０９　モニターのインターフェイス
３１０　バス
１４０２　ＩＳＰのＰＰＰ　ｐｅｅｒ
１４０４　ＰＳＴＮ　（Ｐｕｂｌｉｃ　Ｓｗｉｔｃｈｅｄ　Ｔｅｌｅｐｈｏｎｅ　Ｎｅｔｗｏｒｋ）
１４０７　ＩＳＰとインターネットとの間のリンク[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to an issuing device that issues 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 described later, there are three types of IPv6 addresses: a link local address, a site local address, and a (aggregatable) global address.
[0005]
An address system such as details and a configuration method thereof is described in RFC 2373 @IP Version 6 Addressing Architecture, `` RFC 2374 @An IPv6 Aggregatable Global Global Unicast Address News Format 24th Adv. ＲｏProposed TLA and NLA Assignment Rule, '' RFC 2461, ｀｀ Neighbor Discovery for IP Version 6 (IPv6), '' RFC 2462, ６ Description of IPv6 Statistics, 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. 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.
[0008]
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. 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).
[0009]
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 revision mode of encryption using public key encryption. Two authentication methods are specified.
[0010]
However, considering a situation of realizing privacy protection (not giving information that reveals the identity), for example, in a case where a user performs IPsec communication with a shopping site, from the viewpoint of a shopping site, Since it is actually impossible to share the pre-shared key with an unspecified number of unspecified communication partners prior to the IPsec communication, the method using the pre-shared key cannot be used.
[0011]
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.
[0012]
A public key certificate is used by a trusted third party to confirm the correspondence between an entity (a communicating entity, a computer or a human) and the public key of the entity, and to assure the identity information of the entity and the public key. Is a digital signature issued by a trusted third party. 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.
[0013]
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.
[0014]
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.
[0015]
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.
[0016]
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.
[0017]
[Problems to be solved by the invention]
However, with regard to the disposable IPv6 address, the above-mentioned RFC3041 @Privacy Extensions for Stateless Address Autoconfiguration in IPv6, '' is known. There is no known method for efficiently and reliably issuing disposable anonymous public key certificates.
[0018]
In addition, there are the following problems. If the ID information of the communication partner is not known, the communication partner is identified 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.
[0019]
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.
[0020]
An object of the present invention is to realize strong privacy protection.
[0021]
Another object of the present invention is to prevent spoofing.
[0022]
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.
[0023]
It is another object of the present invention to efficiently realize a disposable anonymous public key certificate which has a high degree of privacy protection, can be realized at low cost, and has a small load at the time of execution.
[0024]
It is another object of the present invention to efficiently realize IPsec communication.
[0025]
Another object of the present invention is to realize strong privacy protection and perform IPsec communication by IKE while preventing spoofing.
[0026]
[Means for Solving the Problems]
In order to solve the above problems, the invention according to the present application provides a communication unit that communicates with a communication device via a network, a generation unit that generates a public key, and a request for a public key certificate from the communication device. Transmitting means for transmitting the public key generated by the generating means to 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 embodiments of the present invention 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 the hosts 204, 205, and 206 connected to the LAN access the Internet 201 via the default gateway 202. In the present embodiment, each host is assumed to be connected by a link 207, and specifically, is assumed to be 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 network interfaces 301 and 302, a CPU 303, a ROM 304, a RAM 305, an HD (hard disk) 306, a power supply 307, a keyboard / pointing device interface 308, a monitor interface 309, and a bus. It is a computer having 310 and the like.
[0033]
A router often has one interface 301 while a router has a plurality of interfaces 301 and 302. Network interface 301 is connected to link 207 and communicates with other nodes connected to link 207. 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. In the gateway (router) 202, the network interface 302 is connected to the Internet 201, and the gateway (router) 202 communicates via the Internet 201 through the network interface 302. Note that the Certification Authority 209 also has the same configuration as that of FIG. The Certification Authority 209 is connected to the Internet 201 via the network interface 301. Some nodes do not have an HD.
[0034]
The following processing contents (procedure) are realized as an apparatus or a program. That is, in a mode implemented by a device, the node 300 having the device executes the following processing contents (procedure). Further, in the embodiment realized as a program, a node in which the program is stored in the ROM 304 or the HD 306 executes the following processing contents (procedure). For example, when the program is implemented as a program, the CPU 303 reads the program and assigns addresses to the interfaces 301 and 302 via the bus 310 while using the RAM 305 as a space for calculation as necessary. Perform
[0035]
In the Ethernet LAN environment of this embodiment, a mechanism of a protocol for each host to acquire a prefix of an IPv6 global address and an address of a default gateway will be briefly described, and then a specific embodiment of the present invention will be described. The form will be described.
[0036]
FIG. 8 shows a flowchart of the operation performed when the node in FIG. 3 is turned on or rebooted. This operation is called DAD (Duplicate Address Detection). Hereinafter, the processing content will be described along the flow of FIG.
[0037]
After the node 300 is turned on or rebooted in step S801, first, an interface ID (see FIG. 5) is created from the Ethernet (MAC) address (see FIG. 4) of the network interface 301, and it is tentative. Link-local address (see FIG. 6) (step S802).
[0038]
Next, the node 300 performs the following processing to determine whether or not the tentative link-local address is unique on the link 207.
[0039]
First, the interface 301 is initialized. That is, an all-nodes multicast address (FF02 :: 1) and a linked-node multicast address of the tentative link-local address are assigned to the interface 301 (see FIG. 7). That is, when the interface 301 finds a packet addressed to the all-nodes multicast address or a packet addressed to the solicited-node multicast address of the tentative link-local address, it receives it as a packet addressed to its own interface.
[0040]
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.
[0041]
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.
[0042]
Next, a Neighbor Solicitation message is created. The target address (target address) of the Neighbor Solicitation message is the 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 is 0). Set the targeted-link multi-address of the tentative link-local address to be determined.
[0043]
The Neighbor Solicitation message is transmitted to the Ethernet (R) 207 by DupAddrDetectTransmits at the interval of TransTimer milliseconds. Step S804 in FIG. 8 is this processing.
[0044]
If the source address of the Neighbor Solicitation message is unspecified address, the node determines that the message is data from a node performing DAD.
[0045]
When a plurality of nodes are performing DAD for the same address at the same time, in addition to the Neighbor Solicitation messages sent by itself, the Neighbor Solicitation messages including the same address in the Target Address are received (Neighbor Solicitation messages sent by oneself). At the same time, a Neighbor Solicitation message sent by another node performing DAD for that address is received), so that it can be seen that they are duplicated. In that case, no node uses that address.
[0046]
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.
[0047]
On the other hand, if the node that has received the Neighbor Solicitation message has already used the address included in the Target Address (target address) of the message, the target address is set to the target address and the most recent update is set to the Target Address. -Return to nodes multicast address. Therefore, the node that sent the Neighbor Solicitation message receives an multicast Neighbor Advertisement addressed to the all-nodes multicast address, and if the target address is the target address in the case of the target address in the case of a target address of "8", the target address is the target address (in the case of step 8), the target address is the target address. ), The tentative address to be determined is not unique (that is, duplicated).
[0048]
As a result of the above DAD, it is confirmed that the tentative link-local address to be determined is unique on the link 207 (in the case of “No” in step S805 in FIG. 8), the address is set as the link local address. Assigned to interface 301. This is step S806 in FIG. Thus, the DAD is completed.
[0049]
The above-described operation in FIG. 8 can be executed by each of the default gateway 202, the DHCP server 203, the host 204, the host 205, and the host 206 in FIG.
[0050]
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.
[0051]
This operation is shown in FIG. 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 routers on the link. Step S901 in FIG. 9 shows this processing.
[0052]
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 that specifies only the Stateless address autoconfiguration checks the validity of the prefix included in the message (not already used by the device). Is confirmed, and an address created by adding an 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.
[0053]
As shown in the case of "No" in step S902 in 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.
[0054]
In the latter case, stateful address autoconfiguration, that is, only DHCPv6 is executed. This is step S906, and the basic operation flowchart is shown in FIG.
[0055]
The details such as the contents and format of messages exchanged in stateful address autoconfiguration are described in “draft-ietf-dhc-dhcpv6-xx.txt” (xx = 23 in March 2002). . The basic operation flow will be described below along the numbers in FIG.
[0056]
Necessary settings are made for the DHCP server 203 by an administrator. Specifically, its own link local address is assigned to the interface 301 as a node, and a prefix for a site local address or a global address necessary for acting as a DHCP server is set.
[0057]
In step S1001 in FIG. 10, the host 204 sends a DHCP Solicit Message to the DHCP server. Since the host 206 does not know where the DHCP server exists, the host 206 transmits the multicast to the link 207 to the DHCP server. When the DHCP server 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) to the DHCP server 203. reach.
[0058]
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.
[0059]
Next, in step S1003, the host 206 sends a DHCP Request Message to the DHCP server 203. Upon receiving the DHCP Request Message, the DHCP server 203 sends a DHCP Reply Message to the host 206 in step S1004.
[0060]
The host 206, which has received the DHCP Reply Message in step S1004, knows the site local address or the global address therefrom, and performs a process necessary for the DAD process to confirm whether the interface ID in the address is duplicated. Do. That is, the above-described multicast address and the like are set in the interface 301. This is step S1005.
[0061]
Next, in step S1006, Neighbor Solicitation Message is sent, and it is determined in step S1007 whether or not 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.
[0062]
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 address to the interface 301 in step S1008.
[0063]
This is the end of step S906 in FIG. If no Router Advertisement is received in step S904, the process ends normally.
[0064]
In step S902, if a Router Advertisement that specifies both stateless autoconfiguration and stateful address autoconfiguration is received, both state addressing and autoregulation are performed in step S905. The processing content is the same as steps S903 and S906.
[0065]
As described above, the host 206 having the Ethernet (R) as an interface can apply the stateless address autoconfiguration and the stateful address autoconfiguration (DHCPv6) in any combination to provide a link local address, a site local address, a global address, a default gateway, and the like. Can be set automatically.
[0066]
In the above protocol, when a random value is used for the interface ID, DAD is performed on the value, and if uniqueness in the link 207 is confirmed, a disposable IPv6 global address is used in combination with the prefix of the global address. can do. The details are described in RFC3041 {Privacy Extensions for Stateless Address Autoconfiguration in IPv6, ″.
[0067]
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.
[0068]
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.
[0069]
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.
[0070]
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.
[0071]
In the present embodiment, an example in which an anonymous public key certificate scheme having computational anonymity is used will be described. After defining and introducing necessary symbols and the like for the sake of explanation, the protocol of the present embodiment will be described.
[0072]
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. Therefore, the entity i knows p, q, g, H, and v_ca.
[0073]
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. s_ca and s_i are referred to as secret keys, and v_ca and v_i (and public parameters (g and the like)) are referred to as public keys, and the secret keys are managed so as not to be known to anyone other than themselves. The entities CA and i know the public keys v_ca and v_i (and public parameters (g and the like)).
[0074]
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 by physical means or the like as necessary, and stores the presented entity name (user name), password, and public key v_i.
[0075]
When issuing the 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. X is a public parameter (such as p), the expiration date of this anonymous public key certificate, and management / attribute information of a certificate such as a public key certificate for the public key v_ca, and includes (g ′, v_i ′) and X Generate a digital signature for (the hash value of) the message. The CA can use a digital signature scheme based on the discrete logarithm problem, for example, a Schnorr signature scheme. Here, a digital signature is generated using the secret key s_ca. This digital signature is referred to as Sig_ca (g ′, v_i ′, X).
[0076]
The anonymous public key certificate APC_ca (i) issued by the CA to the entity i is APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)). In the modification of the present invention, the public key certificate for v_ca is not included in the management / attribute information X of the anonymous public key certificate.
[0077]
The entity i that has been issued the anonymous public key certificate APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) has (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.
[0078]
The entity that has received the anonymous public key certificate (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) extracts (g ′, v_i ′, X) from the entity and extracts the hash value. Calculate and confirm 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 encryption of the public key cryptography based on the discrete logarithm problem and the verification of the digital signature are performed using g ′ and v_i ′ (and the common parameter p).
[0079]
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.
[0080]
A case where the above anonymous public key certificate method is applied to the environment of FIG. 2 will be described.
[0081]
The Certificate Authority 209 is the entity CA, and the host 206 (or a user using the same) is the entity i using the anonymous public key certificate. However, the Certificate Authority 209 does not have all the functions of the CA in the anonymous public key certificate scheme. In the following, an IPv6 compatible device that exists in the local link 207 where the IPv6 compatible device (host 206) using the public key certificate is located and is trusted by the public key certificate issuer (CA, ie, the Certification Authority 209). Is the default gateway 202. That is, a case will be described in which the default gateway 202 has a part of the function of the entity CA in the anonymous public key certificate scheme instead of the certificate authority 209.
[0082]
Note that the IPv6-compatible device trusted by the CA 209 may be the DHCP server 203 or a dedicated CA server. In the following, a form in which a random IPv6 address is included in a certificate will be described. However, there may be a form in which a random IPv6 address is not included in a certificate. As described above, the default gateway 202 will be referred to as the router 202.
[0083]
The administrator of the Certification Authority 209 determines and publishes the public parameters p, g, and the like described above. Further, a public key v_ca as the entity CA is determined.
[0084]
The fact that the Certification Authority 209 trusts the default gateway 202 (or a DHCP server or a dedicated CA server) means here that the management source of the default gateway 202 and the like is clear, and the management source is responsible when a problem occurs. Is assumed to be agreed between the Certification Authority 209 and its management source. For example, when a trouble related to a certain anonymous public key occurs, it is required that a management source such as the default gateway 202 and the like perform the process of identifying the user of the anonymous public key and taking responsibility, by using the Certification Authority 209 and the default. This is the case where a contract has been agreed with a management source such as gateway 202 or the like.
[0085]
Further, in this case, the Certification Authority 209 and the default gateway 202 (or a DHCP server or a dedicated CA server) securely exchange public key cryptography or securely share a secret encryption key. For example, it is assumed that reliable and secure communication can be performed between them through the Internet.
[0086]
The router (gateway) 202 has a role of controlling the transfer of packets, and is operated under the responsibility of the administrator so that inappropriate packets do not enter and exit between the subnet under the control of the router 202 and the outside. . In order for a certain subnet to be connected to the Internet 201, the administrator of the subnet registers his / her identity with JPNIC (in the case of Japan) and receives an IP address assignment. Therefore, it is expected that the router 202 in the subnet has clear management responsibilities and is expected to be costly to operate and manage in consideration of security, so that the Certification Authority 209 is considered to be worthy of trust.
[0087]
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 of the user i in the RAM 305 or the HD 306 of the router 202 so that the public key v_i of the user i can be retrieved from the entity name of the user i. 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 206.
[0088]
FIG. 1 shows a protocol according to the present embodiment, which is executed after the above preparations are made. FIG. 1 shows an entity (IPv6 terminal used by the user i) as a host 206, a CA as a certification authority 209, and a certification authority 209 that trusts the router 202 and issues an anonymous public key certificate between them. Protocol. Here, the router 202 is an address information providing device or a provider that provides address information for setting an address to the host (communication device) 206. The address information is a prefix of the IPv6 global address or the IPv6 global address itself.
[0089]
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.
[0090]
The host 206 generates a Certificate Solicitation in step S101. The Certificate Solicitation is a message for requesting an anonymous public key certificate, and has a format that allows the router 202 to understand that the message is a data including the message and an interface ID of the interface 301. The content is calculated from the entity name (user name), password and serial number. As the serial number, for example, a value obtained by connecting the IPv6 link local address of the host 206, the IPv6 link local address of the default gateway, and the time at that time into one data can be adopted. In order to prevent a retransmission attack and impersonation, a digital signature (authentication signature) (= Sig_i (hash) generated using a secret key s_i with respect to a value obtained by inputting an entity name (user name), a password, and a serial number into a hash function (Entity name, password, serial number))) is included in Certificate Solicitation.
[0091]
Next, the host 206 sends a Certificate Solicitation from the network interface 301 to the router 202 in step S102.
[0092]
In step S103, the router 202 searches the RAM 305 or the HD 306 for the registered public key v_i from the entity name (identifier) included in the Certificate Solicitation received from the network interface 301 in step S102, and uses it for authentication. Check the validity of the signature. 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. That is, when the interface 301 receives a Certificate Solicitation including a digital signature from the host 206, the CPU 303 confirms the validity of the digital signature using the public key v_i of the host 206. As described above, the router 202 authenticates the host 206 based on public key encryption.
[0093]
If the authentication is successful, the router 202 generates the IPv6 global address of the host 206 from the prefix of the IPv6 global address and the interface ID of the interface 301 of the host 206. Then, in S103A, a random number r is generated, and (g ′, v_i ′) = (g ＾ r mod p, (v_i) ＾ (r) mod p) from the generator g and the public key v_i, as described above. (The two of g 'and v_i' are called anonymous public keys). That is, the CPU 303 generates a public key v_i ′ from the public key v_i. Then, a signature (2) for authentication, which is a signature of the router 202 with respect to the IPv6 global address of the host 206 and the anonymous public key (g ′, v_i ′), is generated.
[0094]
In this case, the public key v_i ′ is generated after the successful authentication. However, in the modified example, the public key v_i ′ is generated in advance before the successful authentication or before the anonymous public key certificate is requested. Then, it is registered in the RAM 305 and the HD 306.
[0095]
Finally, an anonymous public key certificate request message including an IPv6 global address, an anonymous public key, and an authentication signature (2) for them = {IPv6 global address, anonymous public key, authentication signature (2)} is sent to step S104. To the Certification Authority 209 from the network interface 302 via the Internet 201. That is, the interface 302 transmits a public key certificate request message requesting issuance of a public key certificate for the anonymous public key (g ′, v_i ′) to the Certification Authority 209 under the control of the CPU 303. The Certification Authority 209 is an issuer or an issuing device that issues a public key certificate. The router 202 is a public key generation device. The interface 301 of the router 202 is a communication unit that communicates with the communication device (host 206) via the network 207, and the CPU 303 is a generation unit that generates a public key. The interface 302 of the router 202 is a transmission unit that transmits a public key generated by the CPU 302 to a public key certificate issuer (CA209) when a public key certificate is requested from the communication device (host 206).
[0096]
As described above, since the router 202 and the Certification Authority 209 can perform reliable and secure communication via the Internet 201, the data contents are not falsified or impersonated by a third party.
[0097]
In step S105, the Certification Authority 209 checks whether or not the authentication signature (2) received from the network interface 301 is actually generated in the correct router 202. If received by the secure and secure communication described above, the fact that the data was received may itself prove that the data was generated by the correct router 202. Alternatively, it may be a digital signature based on public key encryption.
[0098]
In any case, the Certification Authority 209, which has confirmed the validity of the authentication signature (2), manages the IPv6 global address and the anonymous public key (g ′, v_i ′) included in the certificate request message with respect to them. A digital signature Sig_ca (g ′, v_i ′, X) is generated for (the hash value of) the message to which the attribute information X has been added. The secret key s_ca is used for this digital signature. The certificate management / attribute information X includes public parameters, certificate expiration dates, public key certificates for v_ca, and the like. In a modification of the present invention, this information X does not include a public key certificate for v_ca. The anonymous public key certificate APC_ca (i) is data comprising an IPv6 global address, an anonymous public key (g ′, v_i ′), management / attribute information X relating to them, and a digital signature for them. That is, when the interface 301 receives the public key certificate request message from the router 202, the CPU 303 sets the address information of the IPv6 global address included in the public key certificate request message and the public key (g ′, v_i ′) (and A digital signature is generated for a message including certificate management / attribute information X). The router 202 is a provider that provides address information for setting an address to the host 202 (communication device).
[0099]
Then, in step S106, the anonymous public key certificate APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)) is sent from the network interface 301 to the router 202 via the Internet 201. That is, the interface 301 issues the public key certificate including the address information of the IPv6 global address, the public key (g ′, v_i ′), and the digital signature.
[0100]
In step S107, the router 202, which has received the anonymous public key certificate from the network interface 302, transmits to the host 206 that has been authenticated the Certificate Advertisement, which is composed of the prefix of the IPv6 global address, the address of the default router 202, and the anonymous public key certificate, in step S107. Sent from interface 301. Here, in one embodiment of the present invention, the data is encrypted using the registered public key v_i and transmitted. That is, the interface 301 transmits the public key certificate issued for the public key (g ′, v_i ′) by the Certification Authority 209 to the host 206. The host 206 is the communication device that has been authenticated in S103, and is the source of the Certificate Solicitation including the digital signature that has been verified valid in S103.
[0101]
In step S108, the host 206 extracts the prefix from the Certificate Advertisement received from the network interface 301, generates an IPv6 global address, and confirms the validity of the anonymous public key certificate.
[0102]
Here, the host 206 uses the public key v_ca of the Certification Authority 209 to validate the anonymous public key certificate APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)). Gender, that is, correctness of the correspondence between (g ′, v_i ′) and Sig_ca (g ′, v_i ′, X). For example, the host 206 extracts (g ′, v_i ′, X) from the anonymous public key certificate APC_ca (i), and obtains a hash value (eg, H (g ′ | v_i ′ | X), where | Is calculated, and whether or not Sig_ca (g ′, v_i ′, X) is a correct digital signature for the hash value is confirmed using the public key v_ca. The host 206 stores the public key v_ca of the Certification Authority 209 in advance. In a mode in which the management / attribute information X of the anonymous public key certificate includes the public key certificate of the public key v_ca, the host 206 stores the public key v_ca stored in advance in the management / attribute of the anonymous public key certificate. After confirming that the public key v_ca included in the attribute information X matches the public key v_ca in the public key certificate, the validity of the anonymous public key certificate is confirmed using the public key v_ca. .
[0103]
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.
[0104]
The Router Certificate Solicitation message in step S1101 in FIG. 11 is data including both the Router Solicitation in step 901 in FIG. 9 and the Certificate Solicitation sent in step S102 in FIG. Upon receiving this data, the router 202 performs the processing of S103, S103A, and S104 in FIG. 1 and receives the anonymous public key certificate from the Certification Authority 209, as in S106. Then, the router 202 sends a Router Certificate Advertisement message to the Router Certificate Advertisement Host that includes both Router Advertisement and Certificate Advertisement that specify only the Stateless address autoconfiguration and the Certificate Advertisement.
[0105]
Therefore, the Router Certificate Advertisement Message received in step S1102 is the Router Advertisement Message received in step S902 in Fig. 9 and the Certificate Advertisement data including both the Certificate Advertisement received in step S107 in Fig. 1.
[0106]
If the validity can be confirmed by performing step S108 in FIG. 1, the result is “Yes” in step S1102. In step S1103, an IPv6 global address is generated and assigned to the interface 301. Check for legitimacy. Here, similarly to S108, the validity of the anonymous public key certificate is confirmed using the public key v_ca of the Certification Authority 209.
[0107]
According to the above protocol, it is possible to issue a disposable anonymous public key certificate corresponding to a disposable IPv6 address simply by increasing data without changing the number of steps of the conventional protocol.
[0108]
Note that if the DHCP server 203 is trusted by the Certification Authority 209 instead of the router 202, the Router Certificate Advertisement Message is not received. Therefore, in step S1106 of FIG. 11, the same protocol as that of FIG. The server 203 executes. It is assumed that the management server of the DHCP server is responsible for trouble in the same way as the management server of the default gateway 202.
[0109]
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.
[0110]
The difference from the protocol of FIG. 10 lies in two places: step S1203 and step S1204.
[0111]
The DHCP Certificate Request Message sent in step S1203 includes 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 (the DHCP server 203 whose destination is not the router 202 but the router 203). Different).
[0112]
Upon receiving this message, the DHCP server 203 performs the processing of S103, S103A, and S104 in FIG. 1, and receives the anonymous public key certificate from the Certification Authority 209, as in S106. Then, the DHCP server 203 sends, to the host 206, a DHCP Certificate Reply Message including both the DHCP Reply Message and the data equivalent to the Certificate Advertisement.
[0113]
Therefore, the DHCP Reply Message received in step S1204 is composed of the DHCP Reply Message received in step S1004 in FIG. 10 and the data corresponding to the Certificate Advertisement received in step S107 in FIG. Different). Then, an IPv6 global address is generated and assigned to the interface 301, and the validity of the anonymous public key certificate is confirmed. Here, similarly to S108, the validity of the anonymous public key certificate is confirmed using the public key v_ca of the Certification Authority 209.
[0114]
According to the above protocol, it is possible to issue a disposable anonymous public key certificate corresponding to a disposable IPv6 address simply by increasing data without changing the number of steps of the conventional protocol.
[0115]
If both the router 202 and the DHCP server 203 are trusted by the CA's Certification Authority 209, in step S1104 in FIG. 11, if the Router Certificate Advertisement Message that specifies both the statusless and the stateful is received (if "Received Message" is received). ), The above-mentioned two extended protocols are applied in an arbitrary combination to automatically generate a link local address, a site local address, a disposable IPv6 global address and a corresponding disposable anonymous public key certificate, default gateway, and the like. Set and get. In this case, the router 202 and the DHCP server 203 correspond to an information processing device group that provides address information for setting an address to the host (communication device) 206, and the router 202 and the DHCP server 203 that are the information processing device group. Requests the Certification Authority 209 for the public key certificate, and sends the public key certificate issued by the Certification Authority 209 to the host 206.
[0116]
A dedicated CA server of another IPv6-compatible device that is neither the router 202 nor the DHCP server 203 is trusted by the public key certificate issuer 209, and the dedicated CA server and the public key certificate issuer 209 operate in cooperation. When a public key certificate is issued to a certain host, if the dedicated CA server exists in the same local link 207 as the target host, the operation of the public key certificate is performed by substantially the same operation as that of the router 202 shown in FIG. Can issue a letter.
[0117]
In FIG. 2, when the target host is the host 206 and the dedicated CA server is the host 204, the operation between them is the same as in FIG. However, the dedicated CA server requires the assumption that it knows the correct IPv6 prefix assigned to its subnet, in the case of FIG. 2, link 207. Therefore, the dedicated CA server is managed by an administrator having the same responsibility as the administrator of the router 202, and when a problem occurs, the correspondence between the Certification Authority 209 and the administrator is the same as in the case of the router 202. There needs to be agreement.
[0118]
The host 206 sends the Router Certificate Solicitation message in S1101 in FIG. 11 (requests the anonymous public key certificate in S101 in FIG. 1) every time the communication partner changes, the session changes, or each time a communication packet is transmitted. The certificate 301 is transmitted from the interface 301 to the link 207, and the certificate 209 receives the anonymous public key certificate from the certificate authority 209. That is, the host 206 realizes privacy protection by requesting and receiving a new public certificate as necessary, and further, by sending a public key certificate including an IPv6 address to a communication partner, Prevent spoofing. Here, the public key (g ′, v_i ′) is a public key of the same entity, but is a public key that changes over time.
[0119]
Although the embodiment in which the router 202 or the DHCP server 203 provides the prefix of the IPv6 address to the host 206 has been described, in the mode in which the IPv6 address itself is provided, the point that the address is sent instead of the prefix and the processing of generating the address by the host are performed. Others are realized by the same protocol except that is unnecessary.
[0120]
(Second embodiment)
In the first embodiment, after a default gateway (router) authenticates a host, a default gateway (router) and a Certification Authority cooperate to send a Certificate Advertisement containing an anonymous public key certificate and a prefix to the host. Was. 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.
[0121]
As in the first embodiment, the Certification Authority 209 is the entity CA, and the host 206 (or a user using the host) is the entity i using the anonymous public key certificate. However, the Certificate Authority 209 does not have all the functions of the CA in the anonymous public key certificate scheme described above. In the following, an IPv6-compatible device that exists in the local link 207 where the IPv6-compatible device (host 206) using the anonymous public key certificate is located and is trusted by the public key certificate issuer (CA, ie, the Certification Authority 209). Is the default gateway 202. That is, a case will be described in which the default gateway 202 has a part of the function of the entity CA in the anonymous public key certificate system, instead of the certificate authority 209.
[0122]
Note that the IPv6-compatible device trusted by the Certification Authority 209 may be a DHCP server or a dedicated server. In the following, a form in which a random IPv6 address is included in a certificate will be described. However, there may be a form in which a random IPv6 address is not included in a certificate. As described above, the default gateway 202 will be referred to as the router 202. Here, the default gateway 202 provides the host 206 with the prefix of the IPv6 global address.
[0123]
In this case, the Certification Authority 209 and the default gateway 202 (or a DHCP server or a dedicated server), for example, exchange public key cryptography safely or share a secret encryption key securely. Accordingly, reliable and secure communication can be performed between them through the Internet. The administrator of the Certification Authority 209 defines a public key v_ca as a CA. The administrator of the router 202 determines and publishes the public parameters p and g described above. The public key v_router of the router 202 is also determined and made public.
[0124]
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.
[0125]
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, an IPv6 terminal providing a prefix as a default gateway 202, and a CA issuing an anonymous public key certificate as a Certification Authority 209. And the operation flow of an anonymous public key certificate issuing protocol performed between them.
[0126]
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.
[0127]
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, a link local address in which a predetermined prefix is added to the interface ID generated from the MAC address is generated, and the like, and Router Solicitation (RS) is sent to the router (step S1501). The RS is a multicast for all routers on the link as described above.
[0128]
Upon receiving the RS, the router 202 sends a Router Advertisement (RA) (step S1502).
[0129]
The host 206 that has received the RA extracts the prefix included in the RA, and generates a global address (called a public address) from the interface ID and the prefix generated from the MAC address. Also, a disposable IPv6 address (referred to as a temporary address) is created from a random interface ID and a 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 (step S1503).
[0130]
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 a detailed description is omitted, it is assumed that the data is a data including a certificate request message and a (host) signature for the certificate request message. The certificate request message includes the temporary address.
[0131]
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.
[0132]
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. Check the validity of the signature. If the confirmation is successful, an anonymous public key for the host 206 is created. Specifically, g ', v_i', p, and q are anonymous public keys. Then, an anonymous public key certificate request message is generated in order to have the certificate for the anonymous public key issued to the Certification Authority 209 (step S1506).
[0133]
Next, the router 202 sends an anonymous public key certificate request message to the Certification Authority 209 (step S1507). The format of the anonymous public key certificate request message is the same as that of the above-described certificate request message, and it is assumed that the message is data composed of the anonymous public key certificate request message and the signature of the router corresponding thereto. This anonymous public key certificate request message includes the temporary address of the host 206.
[0134]
Upon receiving the anonymous public key certificate request message from the router 202, the Certification Authority 209 checks whether it is created by the router 202 or is correct data. For example, when the data is received by the above-described secure and secure communication, the fact that the data was received may be regarded as proof that the data itself is data generated in the correct router 202. Alternatively, when the digital signature is based on public key cryptography, the digital signature may be confirmed by the public key v_router of the router.
[0135]
In any case, the Certification Authority 209 that has confirmed the validity of the anonymous public key certificate request message includes the anonymous public key (g ′, v_i ′, p, q) and the temporary address included in the certificate request message. A digital signature is generated for the (hash value of) the message to which the management / attribute information is added, and an anonymous public key certificate including the message and the signature is generated (step S1508). In one aspect of the invention, the anonymous public key certificate includes a Certification Authority 209 public key.
[0136]
Then, the Certification Authority 209 sends the anonymous public key certificate to the router 202 (step S1509). In an embodiment of the present invention, the anonymous public key certificate is encrypted using a registered public key and transmitted.
[0137]
The router 202 sends a Certificate Advertisement including the anonymous public key certificate to the host 206 (step S1510). In one embodiment of the present invention, the CertificateAdvertisement is encrypted using a registered public key and transmitted. At this time, it is also possible to send directly from the Certification Authority 209 to the host 206 as a unicast addressed to the temporary address.
[0138]
The host 206 confirms the validity of the anonymous public key certificate from the received Certificate Advertisement (step S1511).
[0139]
FIG. 16 shows an operation flowchart of the host of the extended protocol in which the above-mentioned protocol is combined with the existing stateless address autoconfiguration and stateful address autoconfiguration.
[0140]
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.
[0141]
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. 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 S1703).
[0142]
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 included in the certificate advertisement. 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.
[0143]
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.
[0144]
(Third embodiment)
In the present embodiment, a case where the 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 the embodiment of the present invention will be described.
[0145]
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 the present embodiment, the ISP and the host are connected by a PPP link.
[0146]
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 PPP peer 1402 has functions as a default gateway module 14021, a DHCP module 14022, and an Authentication module 14023. 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. The configuration of the PPP peer 1402 is also the same as that of FIG. 3, and a modem 1403 is connected via the network interface 301, and a link 1407 (further, the Internet 1401) is connected via the network interface 302. The PPP peer 1402 is an address information providing device that provides address information for setting an address to the host 1406 (communication device).
[0147]
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)".
[0148]
The host 1406 transmits a request for PPP connection 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}.
[0149]
When the authentication is completed, the DHCP module 14022 informs the host 1406 of the (prefix) of the IPv6 global address, the IPv6 address of the default gateway, and the like according to the setting. In the DHCP module 14022, the administrator of the ISP makes settings according to the operation policy.
[0150]
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 case, the modules or nodes may be operated safely under the control of the ISP, so that the PPP link between the host and the PPP peer will be described below with reference to FIG. Explanation will be given as having been established.
[0151]
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 and the prefix of the IPv6 global address (and a random interface ID generated by a method such as RFC3041). To generate a random IPv6 global address, make sure that it is not duplicated on the link, then assign it to interface 301 and store the default gateway IPv6 address.
[0152]
With the above operation, the host 1406 can communicate with any other party on the Internet using the disposable IPv6 address.
[0153]
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.
[0154]
Hereinafter, an embodiment in which the anonymous public key certificate scheme is applied to the environment of FIG. 14 will be described. The Certification Authority 1408 is the CA, and the host 1406 (or a user using the CA) is the entity i using 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.
[0155]
The Certification Authority 1408 determines the above-mentioned public parameters p, g, etc., determines its own secret key s_ca and public key v_ca, and publishes it. The Certification Authority 1408 trusts the PPP peer 1402. That is, agreement has been reached between the management of the PPP peer 1402, that is, the ISP, and the responsibility in the event of a problem, so that reliable and secure communication can be performed between the Certification Authority 1408 and the PPP peer 1402. It has become.
[0156]
When the user i applies for a subscription to the ISP, the user i generates his / her own secret key s_i using parameters p, g, etc. published by the Certification Authority 1408, calculates the corresponding public key v_i, and And the password and the public key v_i to the ISP. The management source of the ISP (the management source 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.
[0157]
FIG. 13 shows the protocol of the present embodiment, which is executed after the above preparations have been made. FIG. 13 shows an entity (IPv6 communication device used by user i) as host 1406, CA as Certification Authority 1408, Certification Authority 1408 trusts PPP Peer 1402, and is an anonymous public key certificate issuing protocol performed between them. is there.
[0158]
After the processing of the data link layer in the PPP connection is completed, the authentication is performed by the authentication protocol CHAP based on the user name and the password.
[0159]
That is, the host 1406 sends the entity name (user name) from the interface 301 to the PPP peer 1402 in step S1301. Upon receiving the entity name (identifier) from the interface 301 in step S1302, the PPP peer 1402 generates a CHAP-challenge and sends it to the host 1406 from the interface 301 in step S1303.
[0160]
Upon receiving the CHAP-challenge from the interface 301 in step S1304, the host 1406 inputs the entity name, the password, and the CHAP-challenge to the hash function, and outputs the value CHAP-response obtained in step S1305 to the PPP peer 1402 in step S1305. Sent from
[0161]
In step S1306, the PPP peer 1402 receives the CHAP-response from the interface 301, and confirms the validity of the CHAP-response. If the confirmation is successful, the authentication is successful, so the (prefix) of the IPv6 global address and the address of the default gateway are transmitted from the interface 301 to the authenticated host 1406 in step S1307.
[0162]
In step S1308, the host 1406 generates an IPv6 global address from the (prefix of the IPv6 global address received from the interface 301 and the random interface ID, and confirms that the IPv6 global address is not duplicated. , And the address of the default gateway is also stored. Next, Certificate Solicitation is sent from the interface 301 to the PPP peer 1402 in step S1309 as a message requesting the anonymous public key certificate.
[0163]
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.
[0164]
Upon receiving the Certificate Solicitation from the interface 301 in step S1310, the PPP peer 1402 registers the registered public key corresponding to the entity name (user name which is the identifier of the host (communication device) 206) in the same manner as in S103A of FIG. v_i is retrieved from the RAM 305 or the HD 306, a random number r is generated as described above, and an anonymous public key (g ′ and v_i ′) (= (g ＾ r mod p, (v_i) ＾ (r) mod p)) Is generated, and a signature for authentication with respect to the IPv6 global address of the host 1406 and the anonymous public key (g ′ and v_i ′) is generated. Then, a certificate request message including the IPv6 global address of the host 1406, the anonymous public key (g ′, v_i ′), and the signature for authentication is sent from the network interface 302 to the Certification Authority 1408 in step S1311.
[0165]
If received by the secure and secure communication described above, the Certification Authority 1408 proves that the fact that the data from the PPP interface 1402 was received from the network interface 301 is itself the data generated by the correct PPP peer 1402. There are cases. Alternatively, it may be a digital signature based on public key encryption.
[0166]
In any case, similarly to S105 of FIG. 1, the Certification Authority 1408, which has confirmed the validity of the authentication signature in step S1312, sets the IPv6 global address of the host 1406, the anonymous public key (g ′, v_i ′), and the management / attribute. A digital signature Sig_ca (g ', v_i', X) for the information X is generated, and an anonymous name including the IPv6 global address of the host 1406, the anonymous public key (g ', v_i'), the management / attribute information X, and the digital signature for them Generate a public key certificate. Then, the Certification Authority 1408 sends the anonymous public key certificate to the PPP Peer 1402 from the network interface 301 in step S1313. The management / attribute information X includes the expiration date of the anonymous public key certificate.
[0167]
The PPP Peer 1402 receives it from the network interface 302, and sends a Certificate Advertisement, that is, an anonymous public key certificate from the interface 301 to the host 1406 in step S1314. The host 1406 checks the validity of the anonymous public key certificate received from the network interface 301 in step S1315.
[0168]
Here, the host 1406 uses the public key v_ca of the Certification Authority 1408 to validate the anonymous public key certificate APC_ca (i) = (g ′, v_i ′, X, Sig_ca (g ′, v_i ′, X)). Gender, that is, correctness of the correspondence between (g ′, v_i ′) and Sig_ca (g ′, v_i ′, X). For example, the host 1406 extracts (g ′, v_i ′, X) from the anonymous public key certificate APC_ca (i), and obtains a hash value (eg, H (g ′ | v_i ′ | X), where | Is calculated, and whether or not Sig_ca (g ′, v_i ′, X) is a correct digital signature for the hash value is confirmed using the public key v_ca. The host 1406 stores the public key v_ca of the Certification Authority 1408 in advance. In a mode in which the management / attribute information X of the anonymous public key certificate includes the public key certificate of the public key v_ca, the host 1406 stores the public key v_ca stored in advance in the management / attribute information of the anonymous public key certificate. After confirming that the public key v_ca included in the attribute information X matches the public key v_ca in the public key certificate, the validity of the anonymous public key certificate is confirmed using the public key v_ca. .
[0169]
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 a random interface ID, CHAP-response, and Certificate Solicitation (similar to the first embodiment) to the PPP peer 1402 in step S1305 ′.
[0170]
In step S1306 ′, the PPP peer 1402 checks the validity of the CHAP-response, searches for the registered public key v_i, and generates an IPv6 global address (from the IPv6 prefix and interface ID) to be assigned to the host 1406. , And its life time (expiration date, for example, 24 hours), and the like, generate an authentication signature and a certificate request message, and in step S1307 ', the Certification Authority.
Send to 1408.
[0171]
The Certification Authority 1408 performs the same processing as the step S1312 in the step S1308 ′, and sends the anonymous public key certificate to the PPP Peer 1402 in the step S1309 ′. The PPP Peer 1402 sends the Certificate Advertisement to the host 1406 in step S1310 '. The host 1406 checks the validity of the received anonymous public key certificate in step S1311 '.
[0172]
The host 1406 executes the procedure of FIG. 13 every time the communication partner changes, each time the session changes, or each time a communication packet is transmitted, and receives the anonymous public key certificate from the Certificate Authority 1408. That is, the host 1406 realizes privacy protection by requesting and receiving a new public certificate as necessary, and further, by sending a public key certificate including an IPv6 address to a communication partner, Prevent spoofing. Here, the public key (g ′, v_i ′) is a public key of the same entity, but is a public key that changes over time.
[0173]
In the above description, the case where the PPP Peer 1402 transmits the IPv6 prefix to the host 1406 and the host 1406 generates the IPv6 address from the IPv6 prefix and the interface ID is described. However, the PPP Peer 1402 transmits the IPv6 address to the host 1406, and the host 1406. Is also implemented using a similar protocol. 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.
[0174]
(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.
[0175]
First, a brief description will be given of an authentication method in a revised mode of encryption using public key encryption in IKE (Internet Key Exchange), which is a protocol for securely sharing SA (Security Association), which is secret data and data such as each other's IPv6 addresses. Then, a method using an anonymous public key certificate will be described.
[0176]
The IKE consists of two phases, and establishes a secure communication path in Phase 1, and in Phase 2, SAs used for communication such as IPsec are agreed on the secure communication path. Hereinafter, only Phase 1 will be described. Main mode and Aggressive mode exist in Phase 1 of IKE, but the following description 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.
[0177]
In IKE, two communicating entities are called an Initiator and a Responder. The initiator starts communication. First, the initiator sends a plurality of SAs (secret data and data such as each other's IPv6 addresses) to the responder, and sends one SA determined to be usable by the responder to the initiator, thereby determining an SA for phase 1. I do.
[0178]
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 a cryptographic key used in another communication is generated from the shared nonce. This is described in detail 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.
[0179]
Consider the following situation. A user 206 (FIG. 2) and 1406 (FIG. 14) access a certain shopping site. This site is connected to the Internet 201 (FIG. 2) and 1401 (FIG. 14) (not shown). This site has a configuration similar to that of FIG. 3 and is connected to the Internet 201 and 1401 by an interface 301. The type of site is not limited to a shopping site. 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.
[0180]
At this time, the user knows the IPv6 address of the shopping site (whether explicit or implicit). By actually accessing and confirming the IPv6 address of the communication partner when the site is correct for the user, the user can know the address explicitly. During communication, the shopping site also knows the addresses of the communication partners 206 and 1406. The above communication can be performed using a disposable IPv6 address.
[0181]
In this embodiment, when the sender and the receiver are determined, the disposable IPv6 address uses the same address (not updated). Further, at this point, the site and the users 206 and 1406 send the disposable anonymous public key certificate APC_ca (i) to each other. Since the IPv6 address is included in X of the disposable anonymous public key certificate APC_ca (i), both parties confirm whether or not the IPv6 address matches the IPv6 address of the communicating party. . Further, both parties confirm the validity of the disposable anonymous public key certificate, judge whether or not it is really the disposable anonymous public key certificate of the communication partner, and make sure that the public key contained therein is truly the public of the communication partner. Check if it is a key.
[0182]
That is, the users 206 and 1406 transmit the disposable anonymous public key certificate from the interface 301 to the site. In the sites connected to the Internets 201 and 1401, the IPv6 address included in the disposable anonymous public key certificate APC_ca (i) received from the user 206 or 1406 via the interface 301 matches the IPv6 address of the user 206 or 1406. Check if Further, the site uses the public key v_ca of the Certification Authority 209, 1408 to confirm the validity of the disposable anonymous public key certificate APC_ca (i). Similarly, the users 206 and 1406 confirm whether the IPv6 address included in the received public key certificate matches the address of the site, and use the public key v_ca of the Certification Authority 209 and 1408 to generate the public key certificate. Check the legitimacy of
[0183]
The validity of the disposable anonymous public key certificate is confirmed as follows. The hosts 206 and 1406 use the public key v_ca of the CA (VeriSign or the like that provides a commercial authentication service) 209 (FIG. 2) and 1408 (FIG. 14) to use the disposable anonymous public key certificate APC_ca (i) = (G ', v_i', X, Sig_ca (g ', v_i', X)), that is, the correctness of the correspondence between (g ', v_i') and Sig_ca (g ', v_i', X) Check. For example, the hosts 206 and 1406 fetch (g ′, v_i ′, X) from the anonymous public key certificate APC_ca (i), and obtain a hash value (eg, H (g ′ | v_i ′ | X), where | Is calculated and Sig_ca (g ′, v_i ′, X) is checked using the public key v_ca to determine whether it is a correct digital signature for the hash value. The hosts 206 and 1406 store in advance publicly known public keys v_ca of CAs (VeriSign or the like providing commercial authentication services) 209 (FIG. 2) and 1408 (FIG. 14). In the form in which the management / attribute information X of the anonymous public key certificate includes the public key certificate of the public key v_ca, the hosts 206 and 1406 determine that the public key v_ca stored in advance is After confirming that the public key v_ca included in the management / attribute information X matches the public key v_ca in the public key certificate, the validity of the anonymous public key certificate is determined using the public key v_ca. Confirm.
[0184]
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. That is, the hosts 206 and 1406 request and receive a new public certificate as necessary, thereby realizing privacy protection, and further sending a public key certificate including an IPv6 address to a communication partner. Prevents spoofing.
[0185]
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 using the public key exchanged in this way, the main mode of the IKE phase 1 is performed, and the IPsec communication with the communication partner having the IPv6 address is performed.
[0186]
That is, when the site confirms that the disposable anonymous public key certificate received from the user 206 or 1406 is a valid disposable public key certificate, the public key (g ′, v_i ′) of the disposable public key certificate is used. ), The interface 301 performs the main mode of the IKE phase 1 and performs IPsec communication with the users 206 and 1406 having the IPv6 address. Similarly, the users 206 and 1406 also perform the Main mode of the IKE phase 1 by the interface 301 and perform the IPsec communication with the site having the IPv6 address.
[0187]
Therefore, it is possible to prevent impersonation of a communication partner as described in the problem.
[0188]
【The invention's effect】
As described above, according to the invention relating to the present application, strong privacy protection can be realized.
[0189]
In addition, spoofing can be prevented.
[0190]
Also, a disposable anonymous public key certificate including an IPv6 address as a certification target can be issued efficiently and reliably, that is, quickly without making a mistake in the issuance target.
[0191]
Further, it is possible to efficiently realize a disposable anonymous public key certificate which has a high degree of privacy protection, can be implemented at low cost, and has a small load at the time of execution.
[0192]
In addition, communication of IPsec can be efficiently realized.
[0193]
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 illustrating 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 illustrating an anonymous public key certificate issuing protocol (in the case of PPP) according to the third embodiment.
FIG. 14 is a schematic diagram of a dial-up / ADSL connection.
FIG. 15 is a diagram illustrating an anonymous public key certificate issuance protocol (for an Ethernet LAN) according to the second embodiment;
FIG. 16 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
310 bus
1402 ISP PPP peer
1404 PSTN (Public Switched Telephone Network)
1407 Link between ISP and Internet

Claims

Communication means for communicating with a communication device via a network;
Generating means for generating a public key;
Transmitting means for transmitting a public key generated by the generating means to a public key certificate issuer when a public key certificate is requested from a communication device.

The public key generation device according to claim 1, wherein the communication unit transmits a public key certificate issued by a public key certificate issuer to a communication device.

The transmitting unit transmits a second public key generated by the generating unit to a public key certificate issuer in correspondence with a first public key of a communication device that has requested a public key certificate. The public key generation device according to claim 1.

The communication means, upon receiving a public key certificate request message including a digital signature from the communication device, uses the first public key of the communication device to confirm the validity of the digital signature. Public key generation device.

2. The public key generation device according to claim 1, wherein the transmission unit transmits address information of the communication device to a public key certificate issuer.

Generate a public key;
Receiving, via a network, a public key certificate request message generated by the communication device;
A public key generation program for transmitting the generated public key to a public key certificate issuer in response to a public key certificate request message.

7. The method according to claim 6, wherein in the transmitting step, a second public key generated in accordance with the first public key of the communication device requesting the public key certificate is transmitted to a public key certificate issuer. Public key generation program.

7. The method according to claim 6, wherein in the receiving step, when a public key certificate request message including a digital signature is received from the communication device, the validity of the digital signature is confirmed using the first public key of the communication device. Public key generation program.

The public key generation device generates a public key, receives a public key certificate request message generated by the communication device via a network, and publishes the generated public key in response to the public key certificate request message. Sent to the key certificate issuer,
A public key certificate issuing method, wherein the public key certificate issuer issues a public key certificate of a public key received from a public key generation device.

The public key generation device transmits a second public key generated according to a first public key of a communication device that has requested a public key certificate to the public key certificate issuer. The public key certificate issuing method according to claim 9.

Upon receiving a public key certificate request message including a digital signature from the communication device, the public key generation device checks the validity of the digital signature using the first public key of the communication device. Item 9. A public key certificate issuance method.