(57)【特許請求の範囲】
【請求項１】
ネットワークを介して通信装置と通信する通信手段と、
前記通信装置の第１の公開鍵から匿名公開鍵を生成する生成手段と、
前記通信装置から匿名公開鍵証明書を要求されると、前記生成手段により生成された匿名公開鍵をインターネットを介して公開鍵証明書発行装置に送信する送信手段とを有し、
前記通信装置を接続する前記ネットワークは、ローカルリンクであって、
前記通信装置が前記匿名公開鍵証明書を要求するために送信するメッセージは、前記通信装置のインターフェイスＩＤあるいは使い捨てＩＰｖ６アドレスを含み、
前記匿名公開鍵は、前記通信装置が、前記通信装置の秘密鍵と共に前記匿名公開鍵を利用できるように生成されることを特徴とする公開鍵生成装置。
【請求項２】
前記通信手段は、前記公開鍵証明書発行装置から発行された匿名公開鍵証明書を前記インターネットを介して取得して、前記通信装置に送信することを特徴とする請求項１の公開鍵生成装置。
【請求項３】
前記生成手段は、乱数を生成し、前記第１の公開鍵をｖ＿ｉ、前記乱数をｒ、公開のパラメータをｐとした場合に、ｖ＿ｉをｒ乗した値をｐで割った場合の剰余を、前記匿名公開鍵として生成することを特徴とする請求項１の公開鍵生成装置。
【請求項４】
ネットワークを介して通信装置と通信する公開鍵生成装置において匿名公開鍵を生成する公開鍵生成方法において、
前記通信装置の第１の公開鍵から前記匿名公開鍵を生成する生成ステップと、
前記通信装置が発生した匿名公開鍵証明書要求メッセージを、前記ネットワークを介して受信する受信ステップと、
前記匿名公開鍵証明書要求メッセージに応じて、前記生成された匿名公開鍵をインターネットを介して公開鍵証明書発行装置に送信する送信ステップとを有し、
前記通信装置と前記公開鍵生成装置を接続する前記ネットワークは、ローカルリンクであって、
前記匿名公開鍵証明書要求メッセージは、前記通信装置のインターフェイスＩＤあるいは使い捨てＩＰｖ６アドレスを含み、
前記匿名公開鍵は、前記通信装置が、前記通信装置の秘密鍵と共に前記匿名公開鍵を利用できるように生成されることを特徴とする公開鍵生成方法。
【請求項５】
前記公開鍵証明書発行装置から発行された匿名公開鍵証明書を前記インターネットを介して取得して前記通信装置に送信する送信ステップを更に有することを特徴とする請求項４の公開鍵生成方法。
【請求項６】
前記生成ステップでは、乱数を生成し、前記第１の公開鍵をｖ＿ｉ、前記乱数をｒ、公開のパラメータをｐとした場合に、ｖ＿ｉをｒ乗した値をｐで割った場合の剰余を、前記匿名公開鍵として生成することを特徴とする請求項４の公開鍵生成方法。
【請求項７】
公開鍵生成装置は、通信装置の第１の公開鍵から匿名公開鍵を生成し、前記通信装置が発生した匿名公開鍵証明書要求メッセージを、ネットワークを介して受信し、前記匿名公開鍵証明書要求メッセージに応じて、前記生成された匿名公開鍵をインターネットを介して公開鍵証明書発行装置に送信し、
前記公開鍵証明書発行装置は、前記公開鍵生成装置から受信した匿名公開鍵の証明書を発行し、
前記通信装置と前記公開鍵生成装置を接続する前記ネットワークは、ローカルリンクであって、
前記匿名公開鍵証明書要求メッセージは、前記通信装置のインターフェイスＩＤあるいは使い捨てＩＰｖ６アドレスを含み、
前記匿名公開鍵は、前記通信装置が、前記通信装置の秘密鍵と共に前記匿名公開鍵を利用できるように生成されることを特徴とする公開鍵証明書発行方法。
【請求項８】
前記公開鍵生成装置は、前記公開鍵証明書発行装置から発行された匿名公開鍵証明書をインターネットを介して取得して前記通信装置に送信することを特徴とする請求項７の公開鍵証明書発行方法。
【請求項９】
前記公開鍵生成装置は、乱数を生成し、前記第１の公開鍵をｖ＿ｉ、前記乱数をｒ、公開のパラメータをｐとした場合に、ｖ＿ｉをｒ乗した値をｐで割った場合の剰余を、前記匿名公開鍵として生成することを特徴とする請求項７の公開鍵証明書発行方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、公開鍵を生成する公開鍵生成装置、方法、及び、公開鍵証明書を発行する公開鍵証明書発行方法に関する。
【０００２】
【従来の技術】
IPv6の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けディジタルカメラである。
【０００３】
IPv6に対応するパーソナル・コンピュータやワークステーションの場合、ネットワークとの接続のインターフェイスには通常はイーサネット（Ｒ）が用いられ、それが持つ IEEE identifier (MAC address)を元にしてIPv6アドレスが構成されるようになっている。
【０００４】
IPv6アドレスには、後述するようにリンクローカルアドレス、サイトローカルアドレスと(集約可能)グローバルアドレスの３種類が存在する。
【０００５】
それらの詳細や構成方法などのアドレス体系は、RFC 2373 ``IPVersion 6 Addresssing Architecture、'' RFC 2374 ``An IPv6 Aggregatabale Global Unicast Address Format、'' RFC 2375 ``IPv6 Multicast Address Assignment、'' RFC 2450 ``Proposed TLA and NLA Assignment Rule、'' RFC 2461 ``Neighbor Discovery for IP Version 6 (IPv6)、'' RFC 2462 ``IPv6 Stateless Address Autoconfiguration、'' 等に記述されている。
【０００６】
ところで、IEEE identifier (MAC address)のようにハードウェアに１対１に対応する情報を固定的に用いると、それが装置もしくはその装置のユーザと１対１に対応する情報とみなされ、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。
【０００７】
この課題に対しては、ランダムなIPv6アドレス(正確にはインターフェイスID)を生成する方法が、RFC3041 ``Privacy Extensions for Stateless Address Autoconfiguration in IPv6、'' 等において提案されている。生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算／生成し、ユニークなランダムな値を定めるプロトコル(の拡張)も記述されている。
【０００８】
上記のような解決方法を利用して生成したランダムなIPv6アドレスを装置が使う場合に、IPsecを用いて暗号通信を行なうことを考える。IPsecは、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであり、通信に際して秘密データやお互いのIPv6アドレス等を安全に共有する必要がある。秘密データやお互いのIPv6アドレス等のデータはSA(Security Association)と呼ばれる。
【０００９】
SAを安全に共有するプロトコルはIKE(Internet Key Exchange)と呼ばれ、RFC2409 ``The Internet Key Exchange (IKE)''において規定されている。ここで、SAを安全に共有するという意味は、意図する相手のみと確実にSAを共有するという意味であり、相手を確実に認証することを必要とする。IKEには、１)pre-shared keyを用いる方法、２)ディジタル署名を用いる方法、３)公開鍵暗号による暗号化による方法、４)公開鍵暗号による暗号化の改訂モードによる方法、の計４つの認証方法が規定されている。
【００１０】
ところが、プライバシ保護(身元を明らかにする情報を与えない)を実現する状況を考えている、例えばユーザが買い物サイトとのIPsec通信を行なうような場合であるので、買い物サイトの立場で考えれば、あらかじめ定まっていない不特定多数の通信相手と pre-shared key をIPsec通信に先だって共有することは現実には不可能であるから、pre-shared key を用いる方法は使えない。
【００１１】
その他の方法の場合は、ディジタル署名あるいは公開鍵暗号の使用に必要な情報(多くの場合は公開鍵)を確実に入手可能ならば、不特定多数の通信相手同士でIKEを実行することが可能である。そのために最も有望視されているのが、PKI(Public-key Infrastructure)と呼ばれる環境・仕組みであり、その中で中心的な役割を果たすのが、公開鍵証明書である。
【００１２】
公開鍵証明書は、信頼できる第三者がエンティティ(通信をする主体、計算機や人間)とそのエンティティの公開鍵の対応関係を確認し、それを保証するためにエンティティのID情報等と公開鍵の組みに対して信頼できる第三者が発行するディジタル署名である。信頼できる第三者はCA(Certification Authority)と呼ばれ、CAのディジタル署名の正当性を確認するための公開鍵は、広く一般に知られている。
【００１３】
しかし、現在運用されている公開鍵証明書の中には、その持ち主(Subject)を示すID情報、例えば、FQDN(Fully Qualified Domain Name)が含まれるので、そのままではプライバシ保護を実現できない。
【００１４】
公開鍵証明書の中にその持ち主のID情報を含めない方法も考えられ、匿名公開鍵証明書と呼ばれる。
【００１５】
しかし、匿名公開鍵証明書にも上述のIEEE identifier (MAC address)と同じ課題が存在する。つまり、同一の匿名公開鍵証明書を使い続ける限り、複数の(公開鍵証明書に基づくIPsec等の)通信を結び付けることは可能であり、もしも一度でも匿名公開鍵証明書とその持ち主の対応関係が明らかになったときは、プライバシが侵害されることにつながるので、やはりプライバシ保護の程度は弱い。
【００１６】
以上の課題に対して、例えば、異なる通信相手と通信する際に異なるIPv6アドレスおよび匿名公開鍵証明書を使うことが可能ならば、強いプライバシ保護が実現できると考えられる。これらを使い捨てIPv6アドレスおよび使い捨て匿名公開鍵証明書と呼ぶ。使い捨てる間隔としては、通信相手が変る度に新しい使い捨てIPv6アドレスを用いる、あるいはパケット毎に変えるなど、いくつかが考えられる。
【００１７】
【発明が解決しようとする課題】
しかし、使い捨てIPv6アドレスに関しては、前述のRFC3041 ``Privacy Extensions for Stateless Address Autoconfiguration in IPv6、'' が知られているが、IPv6通信が可能な装置(以下では、IPv6対応装置と表す)に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。
【００１８】
さらに、次の課題も存在する。通信相手のID情報がわからない場合、通信相手の識別はIPアドレスでのみ行なうことになる。しかし、例えばイーサネット（Ｒ）のLAN上で送受されるパケットはそのLAN上のノード全てがアクセスできるので、本来はエンティティAとエンティティBが通信をするはずのところを、Aと同じLAN上の悪意を持ったCがAになりすますこともありうる。つまり、AとBの間で使い捨て匿名公開鍵証明書に基づくIPsec通信を行なうために、Aの公開鍵証明書がBに送られる際に、Aの公開鍵証明書をCのものとすり替えることでCはAに成りすますことができてしまう。
【００１９】
DNS(Domain Name System)サーバーやルーターに対してDoS(Denial of Services)攻撃を加え、その間に偽のDNSサーバーやルーターが偽の情報を与えるようにすれば、LANに限定されないより広域な範囲でのなりすましも可能となる。通信相手のIDが判明していれば、それを確認することで対処できたが、上記に示したような匿名性の高い状況において、この種の攻撃を防ぐ方法は今まで知られていない。
【００２０】
本発明の目的は、強力なプライバシ保護を実現することにある。
【００２１】
また、本発明の他の目的は、なりすましを防ぐことにある。
【００２２】
本発明の他の目的は、IPv6アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することにある。
【００２３】
本発明の他の目的は、プライバシ保護の程度が高く、低コストで実現が可能で、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能にすることにある。
【００２６】
【課題を解決するための手段】
上記課題を解決するために、本出願に関わる発明は、ネットワークを介して通信装置と通信する通信手段と、前記通信装置の第１の公開鍵から匿名公開鍵を生成する生成手段と、前記通信装置から匿名公開鍵証明書を要求されると、前記生成手段により生成された匿名公開鍵をインターネットを介して公開鍵証明書発行装置に送信する送信手段とを有し、前記匿名公開鍵は、前記通信装置が、前記通信装置の秘密鍵と共に前記匿名公開鍵を利用できるように生成されることを特徴とする。
【００２７】
【発明の実施の形態】
（第１の実施の形態）
本実施の形態では、ホストがイーサネット（Ｒ）のLAN経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本発明の実施の形態を説明する。
【００２８】
図２は、本発明が適用される接続環境（ホストがイーサネット（Ｒ）のLAN経由でインターネットと接続する環境）を模式的に示したものである。
【００２９】
図２は、LANに接続されたホスト204、205、206が default gateway 202経由でインターネット201にアクセスする環境を示す。本実施の形態では、各ホストはリンク207で接続するものとし、具体的にはイーサネット（Ｒ）であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、IP層の下側に接する。リンクにはイーサネット（Ｒ）の他に、PPPリンク、X．25、フレームリレー、ATMネットワークがある。
【００３０】
リンクに接続されたIPv6対応装置をノードと呼ぶ。
【００３１】
ノードの内部構成の典型例を図３に示す。
【００３２】
ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノード300は、ネットワーク・インターフェイス301、302、CPU 303、ROM 304、RAM 305、HD(ハードディスク)306、電源307、キーボード/ポインティングデバイスのインターフェイス308、モニターのインターフェイス309、バス310等を有する計算機である。
【００３３】
ルーターは複数のインターフェイス301、302を持つのに対し、ホストは多くの場合は一つのインターフェイス301を持つ。ネットワーク・インターフェイス301は、リンク207に接続され、リンク207に接続された他のノードと通信する。ホスト204、205、206は、ネットワーク・インターフェイス301により、リンク207を介して、リンク207に接続された他のノード、あるいは、更に、ゲートウェイ202を介して、インターネット201上のサイトと通信する。ゲートウェイ（ルーター）202においては、ネットワーク・インターフェイス302は、インターネット201と接続され、ゲートウェイ（ルーター）202は、ネットワーク・インターフェイス302により、インターネット201を介して通信する。なお、Certification Authority 209も、図３と同様の構成を有する。Certification Authority 209は、ネットワーク・インターフェイス301を介して、インターネット201に接続されている。ノードによってはHDを持たないものもある。
【００３４】
なお以下の処理内容(手順)は、装置もしくはプログラムとして実現される。すなわち、装置で実現する形態では、その装置を有するノード300が、以下の処理内容(手順)を実行する。また、プログラムとして実現する形態では、そのプログラムがROM304もしくはHD306に格納されたノードが、以下の処理内容(手順)を実行する。例えば、プログラムとして実現される場合は、そのプログラムをCPU303が読み込み、必要に応じてRAM305を計算のための空間として利用しながらバス310を介してインターフェイス301、302にアドレスを割当てる、というような動作を行なう。
【００３５】
本実施の形態のイーサネット（Ｒ）LAN環境で各ホストがIPv6グローバルアドレスのプレフィックスやdefault gatewayのアドレスを取得するプロトコルの仕組みを簡単に説明し、その次に本発明を適用した具体的な実施の形態を説明する。
【００３６】
図３のノードが、電源を入れられたあるいはリブートされた場合に行なう動作のフローチャートを図８に示す。この動作はDAD(Duplicate Address Detection)と呼ばれる。以下では図８の流れに沿って処理内容を説明する。
【００３７】
ステップS801でノード300が電源を入れられたあるいはリブートされた後、まずネットワーク・インターフェイス301のイーサネット（Ｒ）の MAC address(図４参照)からインターフェイスID(図５参照)を作成し、それをtentative link-local address(図６参照)とする（ステップS802）。
【００３８】
次に、そのtentative link-local addressがリンク207上で一意かどうかを判断するために、ノード300は以下の処理を行なう。
【００３９】
最初に、インターフェイス301の初期設定をする。すなわち、インターフェイス301に、all-nodes multicast address (FF02::1)と そのtentative link-local address の solicited-node multicast address を割当てる（図７参照）。つまり、そのインターフェイス301が all-nodes multicast address宛のパケットあるいはそのtentative link-local address の solicited-node multicast address 宛のパケットを見つけたときはそれを自分のインターフェイス宛のパケットとして受け取る。
【００４０】
前者(all-nodes multicast address)を割当てることによって、既にそのtentative link-local addressを使っている他のノードからのデータを受信することが可能になる。また、後者(そのtentative link-local address の solicited-node multicast address)を割当てることによって、同じtentative link-local addressを同時に使おうとしている他のノードの存在を検出することが可能になる。
【００４１】
あるtentative link-local address の solicited-node multicast address とは、RFC2461のpage 91に定義されているように、tentative link-local addressの下位24ビットをプレフィックスFF02:0:0:0:0:1:FF00::/104に付加したデータであり、link-local scope multicast address である。図６と図７にそれらの関係を示す。以上のアドレス割当てが図８のステップS803である。
【００４２】
次に Neighbor Solicitation message を作る。Neighbor Solicitation message の Target Address（ターゲットアドレス）には判断対象のtentative link-local addressを、IP Source(送信元アドレス)には unspecified address(128ビット全てが0)を、IP destination(宛先アドレス)には判断対象のtentative link-local address の solicited-node multicast addressを設定する。
【００４３】
この Neighbor Solicitation message をRetransTimerミリセカンド間隔でDupAddrDetectTransmits個イーサネット（Ｒ）207に送出する。図８のステップS804がこの処理である。
【００４４】
Neighbor Solicitation messageを受け取ったノードは、その送信元アドレスが unspecified address ならば、その message がDADを行っているノードからのデータであることと判断する。
【００４５】
同時に複数のノードが同じアドレスを対象としてDADをしている場合は、自分が送ったNeighbor Solicitation messages以外にも、同じアドレスを Target Addressに含むNeighbor Solicitation messagesを受け取る（自分が送ったNeighbor Solicitation messageと、同時にそのアドレスを対象としてDADをしている他のノードが送ったNeighbor Solicitation messageを受け取る）ので、重複していることがわかる。その場合にはどのノードもそのアドレスは使わない。
【００４６】
なお、受け取った Neighbor Solicitation message が、自分が送ったもの(マルチキャストのパケットをループバックしているため)であるならば、他にそれを使っているあるいは使おうとしているノードが存在することを示さない。自分が送ったNeighbor Solicitation messageに加えて、同じアドレスを Target Addressに含むNeighbor Solicitation messagesを受け取った場合に、同時に複数のノードが同じアドレスを対象としてDADをしていると判断する。
【００４７】
一方、Neighbor Solicitation messageを受け取ったノードが、その message の Target Address（ターゲットアドレス）に含まれるアドレスを既に使っていれば、Target Addressにそのtentative link-local addressが設定されたa multicast Neighbor Advertisement をall-nodes multicast address宛てに返す。従って、Neighbor Solicitation messageを送ったノードが all-nodes multicast address 宛てのa multicast Neighbor Advertisementを受け取り、その target address が (判断対象の) tentative address である場合(図８のS805ステップの「はい」の場合)は判断対象の tentative address が唯一ではない(つまり、重複している)。
【００４８】
以上のDADの結果、判断対象の tentative link-local address がリンク207上で唯一であることが確認された(図８のS805ステップの「いいえ」の場合)ならば、そのアドレスをリンクローカルアドレスとしてインターフェイス301に割当てる。これが図８のステップS806である。以上でDADは終了する。
【００４９】
以上に説明した図８の動作は図２のdefault gateway 202、DHCP server 203、ホスト204、ホスト205、ホスト206のそれぞれが実行することができる。
【００５０】
図２のホスト、例えばホスト206は、リンクローカルアドレスをインターフェイス301に割当てたら、次はサイトローカルアドレスやグローバルアドレスを決定するために必要な情報(Router Advertisementと呼ばれる)をdefault gateway 202から入手することを試みる。
【００５１】
この動作を図９に示す。default gateway 202は通常はルーターと呼ばれるので以下ではルーター202と記す。ルーター202は管理者によって必要な設定が行われ、Router Advertisement を定期的にリンク207に送っている。ホスト206が Router Advertisement を早く入手したい場合は、ホスト206は Router Solicitation と呼ばれるデータをルーター202に送る。ホスト206はリンクローカルアドレスを割当てた直後にはルーター202の存在はわからないので、実際にはRouter Solicitationはリンク上のルーター全てに対するマルチキャストとして送られる。図９のステップS901はこの処理を示す。
【００５２】
Router Solicitation を受け取ったルーター202は Router Advertisement を送る。図９のステップS902の「はい」の場合に示すように、Stateless address autoconfiguration のみを指定するRouter Advertisement を受け取ったホスト206は、そのメッセージに含まれるプレフィックスの有効性(既にその装置によって使われていないこと等)を確認し、それ(ら)にインターフェイスIDを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとし、インターフェイス301に割当てる。図９のステップS903がこの処理である。
【００５３】
図９のステップS902の「いいえ」の場合に示すように、ホスト206が stateless address autoconfigurationのみを指定するRouter Advertisement を受け取らなかった場合は、次の二つの場合に分けられる。Stateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementを受け取った場合(ステップS904のはいの場合)と、Router Advertisementを何も受け取らなかった場合(ステップS904のいいえの場合)である。
【００５４】
後者の場合はstateful address autoconfiguration、すなわちDHCPv6のみを実行する。これがステップS906であり、その基本的な動作フローチャートを図１０に示す。
【００５５】
なお、stateful address autoconfigtation においてやり取りされるメッセージの内容や形式等の詳細は、"draft-ietf-dhc-dhcpv6-xx．txt"(2002年3月においてxx=23が最新版)に説明されている。以下では図１０の番号に沿って基本的な動作の流れを説明する。
【００５６】
DHCPサーバー203は管理者によって必要な設定が行われている。具体的には、ノードとして自分のリンクローカルアドレスをインターフェイス301に割当ててあり、DHCPサーバーとして振る舞うために必要なサイトローカルアドレスもしくはグローバルアドレスのためのプレフィックス等が設定されている。
【００５７】
図１０のステップS1001で、ホスト204はDHCPサーバーにDHCP Solicit Messageを送る。ホスト206はどこにDHCPサーバーが存在するのかわからないのでDHCPサーバーに対するマルチキャストとしてリンク207に送出する。ホスト206の接続されているリンク207とは異なるリンク(図示せず)にDHCPサーバーがいる場合には、DHCP Solicit Messageは、実際にはDHCPリレー(図示せず)によって中継されてDHCPサーバー203に届く。
【００５８】
DHCP Solicit Messageを受け取ったDHCPサーバー203はそれに対する返答としてDHCP Advertise Messageをホスト206に返す。これは(別リンクの場合はDHCPリレーによって中継されて)ホスト206に届く。これがステップS1002である。この時点でホスト206はDHCPサーバー203のアドレスがわかる。
【００５９】
次にステップS1003でホスト206は DHCP Request Message をDHCPサーバー203に送る。DHCPサーバー 203はDHCP Request Messageを受け取ると、ステップS1004でDHCP Reply Messageをホスト206に送る。
【００６０】
ステップS1004でDHCP Reply Message受け取ったホスト206は、それからサイトローカルアドレスもしくはグローバルアドレスがわかるので、そのアドレスの中のインターフェイスIDが重複しているか否かを確認するために、DAD処理に必要な処理を行なう。つまり、インターフェイス301に前述のマルチキャストアドレス等を設定する。これがステップS1005である。
【００６１】
次に、ステップS1006でNeighbor Solicitation Message を送り、Neighbor Advertisement Messageを受け取るかどうかをステップS1007で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをDHCPサーバー203から受け取るためにステップS1003に戻り、同じ処理を繰り返す。
【００６２】
ホスト206は、図１０のステップS1007でNeighbor Advertisement Messageを受け取らなかった場合はそのアドレスは重複していないので、ステップS1008でそのアドレスをインターフェイス301に割当てる。
【００６３】
以上で図９のステップS906が終わる。ステップS904でRouter Advertisementを何も受け取らなかった場合はこれで正常終了する。
【００６４】
ステップS902でstateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementを受け取った場合は、ステップS905でstateless address autoconfigurationとstateful address autoconfigurationの両方を行なう。処理内容はステップS903とS906と同じである。
【００６５】
以上のようにして、イーサネット（Ｒ）をインターフェイスとして持つホスト206はstateless address autoconfiguration とstateful address autoconfiguration (DHCPv6)を任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、グローバルアドレス、default gateway等を自動設定することができる。
【００６６】
以上のプロトコルにおいて、インターフェイスIDにランダムな値を用いる場合、その値を対象にしてDADを行ない、リンク207における一意性を確認すれば、グローバルアドレスのプレフィックスと組み合わせて、使い捨てのIPv6グローバルアドレスを利用することができる。詳細は、RFC3041 ``Privacy Extensions for Stateless Address Autoconfiguration in IPv6、''に記述されている。
【００６７】
次に本発明の実施の形態を説明する。上述した動作(プロトコル)を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。最初に、匿名公開鍵証明書の例を説明し、次にそれを効率的に発行するためのプロトコルを説明する。
【００６８】
匿名公開鍵証明書は、学術的には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においてその概念と具体的な実現方法が提案されており、その基本的な実現方法はUSAの特許6、154、841としても開示されている。これらの方式では、証明書のユーザの匿名性は計算量的に保たれていた。
【００６９】
より強力な匿名性を提供する方式として、情報量的な匿名性を有する匿名公開鍵証明書の実現方法がKazuomi Oishi、 ``Unconditionally anonymous public key certificates、'' The 2000 Symposium on Cryptography and Information Security、 SCIS2000-C32、 2000において開示されている。
【００７０】
本発明においては、前述の論文Kazuomi Oishi、 Masahiro Mambo、 Eiji Okamoto、 ``Anonymous Public Key Certificates and their Applications ''に記載されている任意の方式を利用することができる。効率が劣ることを許容できるならば、前記論文中のScheme 1、Scheme 2、Scheme 3を利用することも可能であり、それらも本発明に含まれる。
【００７１】
本実施の形態では計算量的な匿名性を有する匿名公開鍵証明書方式を用いる場合を例として取り上げる。説明の都合上必要な記号等を定義・導入してから、本実施の形態のプロトコルを説明する。
【００７２】
匿名公開鍵証明書を発行するエンティティCAは、共通のパラメータとして大きな素数pとqを定める。qはp-1を割りきる。オーダーqの生成元gとハッシュ関数Hを定める。秘密の乱数s_ca(1以上q以下)を生成し、v_ca=g^(s_ca) mod pを計算する。ここで、A = (B)^(C) mod Dは、整数A、B、C、Dに対して、BをC乗した値をDで割り、その剰余をAとする計算を表す。エンティティCAはpとqとgとHとv_caを公開する。したがって、エンティティiは、pとqとgとHとv_caを把握している。
【００７３】
一方、匿名公開鍵証明書を利用するエンティティiは、秘密の乱数s_i(1以上q以下)を生成し、v_i=g^(s_i) mod pを計算する。s_caやs_iを秘密鍵、v_caやv_i(および公開のパラメータ（gなど）)を公開鍵と呼び、秘密鍵は自分以外の誰にも知られないように管理する。エンティティCA、および、iは、公開鍵v_caやv_i(および公開のパラメータ（gなど）)を、把握している。
【００７４】
エンティティiは、匿名公開鍵証明書を利用開始する際に、自分のエンティティ名(ユーザ名)とパスワード、公開鍵v_iをエンティティCAに登録する。エンティティCAは、必要に応じてエンティティの身元を物理的手段等で確認し、提示されたエンティティ名(ユーザ名)とパスワード、公開鍵v_iを記憶する。
【００７５】
匿名公開鍵証明書を発行する際、エンティティCAは、乱数r(1以上q以下)を生成し、(g'、v_i')=(g^r mod p、 (v_i)^(r) mod p)を計算する。公開のパラメータ（pなど）やこの匿名公開鍵証明書の有効期限、公開鍵v_caに対する公開鍵証明書等の証明書の管理・属性情報をXとし、(g'、v_i')とXを含むメッセージ(のハッシュ値)に対してディジタル署名を生成する。CAは離散対数問題に基づくディジタル署名方式、例えば、Schnorr署名方式を使うことができる。ここでは、秘密鍵s_caを用いて、ディジタル署名を生成する。このディジタル署名をSig_ca(g'、v_i'、X)と記す。
【００７６】
エンティティiに対してCAが発行する匿名公開鍵証明書APC_ca(i)は、APC_ca(i)=(g'、v_i'、X、Sig_ca(g'、v_i'、X))である。なお、本発明の変形例では、匿名公開鍵証明書の管理・属性情報Xには、v_caに対する公開鍵証明書を含めない。
【００７７】
匿名公開鍵証明書APC_ca(i)=(g'、v_i'、X、 Sig_ca(g'、v_i'、X))の発行を受けたエンティティiは、その中から(g'、v_i'、X)を取り出し、そのハッシュ値(例えば、H(g'|v_i'|X)、ただし | は連接を示す)を計算し、Sig_ca(g'、v_i'、X)がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵v_caを用いて確認する。また、v_i'=(g')^(s_i) mod pも確認する。それらが正しいと確認できたならば、g'とv_i'(と共通のパラメータp)を公開鍵、s_iを秘密鍵として離散対数問題に基づく公開鍵暗号やディジタル署名を利用できる。
【００７８】
匿名公開鍵証明書(g'、v_i'、X、 Sig_ca(g'、v_i'、X))を受け取ったエンティティは、その中から(g'、v_i'、X)を取り出し、そのハッシュ値を計算し、Sig_ca(g'、v_i'、X)がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵v_caを用いて確認する。それが正しいと確認できたならば、g'とv_i'(と共通のパラメータp)を用いて離散対数問題に基づく公開鍵暗号の暗号化やディジタル署名の検証を行なう。
【００７９】
なお、上記の説明では乗法群(mod p)上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能であり、その場合は乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。
【００８０】
以上の匿名公開鍵証明書方式を、図２の環境に適用する場合を説明する。
【００８１】
Ｃｅｒｔｉｆｉｃａｉｔｏｎ  Ａｕｔｈｏｒｉｔｙ  ２０９がエンティティＣＡ、ホスト２０６（もしくはそれを利用するユーザ）が匿名公開鍵証明書を利用するエンティティｉになる。但し、Ｃｅｒｔｉｆｉｃａｉｔｏｎ  Ａｕｔｈｏｒｉｔｙ  ２０９が上記匿名公開鍵証明書方式におけるＣＡの全ての機能を有するわけではない。以下では、公開鍵証明書を利用するＩＰｖ６対応装置（ホスト２０６）の位置するローカルリンク２０７内に存在し、かつ、公開鍵証明書発行者（ＣＡ、つまりＣｅｒｔｉｆｉｃａｔｉｏｎ  Ａｕｔｈｏｒｉｔｙ  ２０９）が信用するＩＰｖ６対応装置がｄｅｆａｕｌｔ  ｇａｔｅｗａｙ  ２０２である場合を説明する。つまり、匿名公開鍵証明書方式におけるエンティティＣＡの機能の一部は、Ｃｅｒｔｉｆｉｃａｉｔｏｎ  Ａｕｔｈｏｒｉｔｙ  ２０９の代わりに、ｄｅｆａｕｌｔ  ｇａｔｅｗａｙ  ２０２が有する場合を説明する。
【００８２】
なお、CA 209が信用するIPv6対応装置はDHCPサーバー203や専用CAサーバーでもよい。また、以下では、ランダムなIPv6アドレスを証明書の中に含める形態を説明するが、ランダムなIPv6アドレスを証明書に含めない形態もあるかもしれない。前述のように、default gateway 202をルーター202と呼ぶことにする。
【００８３】
Certification Authority 209の管理者は、上述の公開パラメータp、g等を定め、公開する。また、エンティティCAとしての公開鍵v_caを定める。
【００８４】
Certification Authority 209がdefault gateway 202(あるいはDHCPサーバーや専用CAサーバー)を信用するということは、ここでは、default gateway 202等の管理元がはっきりしており、問題が生じたときにその管理元が責任を負う条件がCertification Authority 209とその管理元との間で合意されていることとする。例えば、ある匿名公開鍵に関するトラブルが起ったとき、その匿名公開鍵のユーザを特定し責任をとらせる処理をdefault gateway 202等の管理元が責任を持って行なうことが、Certification Authority 209と default gateway 202等の管理元との間で契約書によって合意されている場合等である。
【００８５】
また、この場合には、Certification Authority 209とdefault gateway 202(あるいはDHCPサーバーや専用CAサーバー)は、例えば、公開鍵暗号を安全に交換してあるとか秘密の暗号化鍵を安全に共有してある等により、それらの間では、インターネットを介して確実で安全な通信が行なえるものとする。
【００８６】
ルーター(gateway)202は、パケットの転送を制御する役目を持ち、そのルーター202の管轄するサブネットと外部との間で不適当なパケットが出入りしないように管理者の責任のもとで運用される。あるサブネットがインターネット201に接続されるためにはそのサブネットの管理者は身元をJPNIC(日本の場合)に登録し、IPアドレスの割当てを受ける。従って、サブネットにおけるルーター202は管理責任が明確であり、かつ安全面も考慮されたうえで運用や管理にコストがかけられると期待されるので、Certification Authority 209が信用するにふさわしいと考えられる。
【００８７】
ユーザiがLANへのアクセスを申請する際に、公開されているパラメータp、g等を用いて、自分の秘密鍵s_iを生成し、対応する公開鍵v_iを計算して、ユーザ名とパスワード、公開鍵v_iをLANの管理者(ルーター202の管理者)に提出する。LANの管理者(ルーター202の管理者)は、その運用方針に応じてユーザiの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、ユーザiのエンティティ名からユーザiの公開鍵v_iが検索できるように、ルーター202のRAM 305あるいはHD 306に登録する。公開パラメータや公開鍵v_i、特に秘密鍵s_iはユーザiが管理し、ホスト206で安全に利用可能になっているものとする。
【００８８】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１に示す。図１は、エンティティ(ユーザiが用いるIPv6端末)をホスト206、CAを Certification Authority 209とし、Certification Authority 209はルーター202を信用するものであり、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。ここで、ルーター202は、アドレスを設定するためのアドレス情報をホスト（通信装置）206に提供するアドレス情報提供装置、あるいは、提供者である。なお、アドレス情報は、IPv6のグローバルアドレスのプレフィックス、あるいは、IPv6のグローバルアドレス自体である。
【００８９】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター202とエンティティ(この場合は、ホスト206)の間でなんらかの特定(認証)プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１の流れに沿って動作を説明する。
【００９０】
ホスト206はステップS101でCertificate Solicitationを生成する。Certificate Solicitationは、匿名公開鍵証明書を要求するメッセージであり、その旨とインターフェイス301のインターフェイスIDを含むデータであることをルーター202が理解できる形式であるとする。内容は、エンティティ名(ユーザ名)とパスワードとシリアル番号から計算される。シリアル番号は、例えばホスト206のIPv6リンクローカルアドレスとdefault gatewayのIPv6リンクローカルアドレスとそのときの時刻の3つを連接して一つのデータにした値を採用できる。再送攻撃となりすましを防ぐために、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数に入力した値に対して、秘密鍵s_iを用いて生成したディジタル署名(認証用signature)（= Sig_i(hash(エンティティ名、パスワード、シリアル番号))）がCertificate Solicitationに含まれる。
【００９１】
次に、ホスト206は、Certificate SolicitationをステップS102でネットワーク・インターフェイス301からルーター202に送る。
【００９２】
ステップS103で、ルーター202はステップS102でネットワーク・インターフェイス301から受け取ったCertificate Solicitationに含まれるエンティティ名（識別子）から登録された公開鍵v_iをRAM 305あるいはHD 306から検索し、それを用いて認証用signatureの正当性を確認する。具体的には、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数の入力とし、そのハッシュ値を求め、認証用signatureがそれに対する正しいディジタル署名であることを公開鍵v_iで確認する。すなわち、ディジタル署名を含むCertificate Solicitationをインターフェイス301がホスト206から受信すると、CPU 303は、ホスト206の公開鍵v_iを用いて、ディジタル署名の正当性を確認する。以上のように、ルーター202は、公開鍵暗号に基づき、ホスト206を認証する。
【００９３】
認証が成功したら、ルーター202は、IPv6のグローバルアドレスのプレフィックスとホスト206のインターフェイス301のインターフェイスID とからホスト206のIPv6グローバルアドレスを生成する。そして、S103Aで、乱数rを生成し、生成元gと公開鍵v_iから前述のように、 (g'、v_i')=(g^r mod p、 (v_i)^(r) mod p) を求める(このg'とv_i'の二つを匿名公開鍵と呼ぶ)。すなわち、CPU 303は、公開鍵v_iから公開鍵v_i'を生成する。そして、ホスト206のIPv6グローバルアドレスと匿名公開鍵(g'、v_i')に対するrouter 202の署名である認証用signature(2)を生成する。
【００９４】
なお、ここでは、認証の成功後、公開鍵v_i'を生成したが、変形例では、認証の成功前、あるいは、匿名公開鍵証明書が要求される前に、予め、公開鍵v_i'を生成して、RAM305、HD306に登録しておく。
【００９５】
最後に、IPv6のグローバルアドレスと匿名公開鍵とそれらに対する認証用signature(2)を含む匿名公開鍵証明書要求メッセージ={IPv6グローバルアドレス、匿名公開鍵、認証用signature(2)}を、ステップS104でネットワーク・インターフェイス302からインターネット201経由でCertification Authority 209に送る。すなわち、インターフェイス302は、CPU 303の制御の元に、匿名公開鍵(g'、v_i')に対する公開鍵証明書の発行を要求する公開鍵証明書要求メッセージを、Certification Authority 209に送信する。Certification Authority 209は、公開鍵証明書を発行する発行者、あるいは、発行装置である。ルーター202は、公開鍵生成装置である。ルーター202のインターフェイス301は、ネットワーク207を介して通信装置（ホスト206）と通信する通信手段であり、CPU303は、公開鍵を生成する生成手段である。また、ルーター202のインターフェイス302は、通信装置（ホスト206から公開鍵証明書を要求されると、CPU302により生成された公開鍵を公開鍵証明書発行者（CA209）に送信する送信手段である。
【００９６】
前述のように、router 202とCertification Authority 209は、インターネット201を介して確実で安全な通信が行なえるので、データ内容が改竄されたり第三者になりすまされたりすることはない。
【００９７】
ステップS105で Certification Authority 209は、ネットワーク・インターフェイス301から受け取った認証用signature(2)が本当に正しいrouter 202に生成されたか否かを確認する。前述の確実で安全な通信によって受け取った場合は、データを受け取った事実自体が正しいrouter 202に生成されたデータであることを証明する場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合もある。
【００９８】
いずれにせよ、認証用signature(2)の正当性を確認したCertification Authority 209は、証明書要求メッセージの中に含まれるIPv6グローバルアドレスと匿名公開鍵(g'、v_i')に、それらに関する管理・属性情報Xを付加したメッセージ(のハッシュ値)に対してディジタル署名Sig_ca(g'、v_i'、X)を生成する。このディジタル署名には、秘密鍵s_caを用いる。証明書の管理・属性情報Xは、公開のパラメータや証明書の有効期限、v_caに対する公開鍵証明書等を含む。本発明の変形例では、この情報Xには、v_caに対する公開鍵証明書は、含めない。匿名公開鍵証明書APC_ca(i)は、IPv6グローバルアドレスと匿名公開鍵(g'、v_i')とそれらに関する管理・属性情報Xとそれらに対するディジタル署名からなるデータである。すなわち、インターフェイス301が、ルーター202から公開鍵証明書要求メッセージを受信すると、CPU 303は、公開鍵証明書要求メッセージに含まれるIPv6グローバルアドレスのアドレス情報と公開鍵(g'、v_i')（および証明書の管理・属性情報X）を含むメッセージに対して、ディジタル署名を生成する。ルーター202は、アドレスを設定するためのアドレス情報をホスト202（通信装置）に提供する提供者である。
【００９９】
そして、ステップS106で匿名公開鍵証明書APC_ca(i)=(g'、v_i'、X、Sig_ca(g'、v_i'、X))をネットワーク・インターフェイス301からインターネット201経由でrouter 202に送る。すなわち、インターフェイス301は、IPv6グローバルアドレスのアドレス情報と、公開鍵(g'、v_i')と、ディジタル署名を含む公開鍵証明書を発行する。
【０１００】
匿名公開鍵証明書をネットワーク・インターフェイス302から受け取ったrouter 202は、ステップS107で、IPv6グローバルアドレスのプレフィックスとdefault router 202のアドレスと匿名公開鍵証明書からなるCertificate Advertisementを認証されたホスト206にネットワーク・インターフェイス301から送る。ここで、本発明の一実施例では、登録された公開鍵v_iを用いて暗号化して、送信する。すなわち、インターフェイス301は、Certification Authority 209により公開鍵(g'、v_i')に対して発行された公開鍵証明書を、ホスト206に送信する。ホスト206は、S103において認証された通信装置であり、S103において正当性が確認されたディジタル署名を含むCertificate Solicitationの送信元である。
【０１０１】
ステップS108でホスト206はネットワーク・インターフェイス301から受け取ったCertificate Advertisementからプレフィックスを取り出し、IPv6グローバルアドレスを生成し、匿名公開鍵証明書の正当性を確認する。
【０１０２】
ここで、ホスト206は、Certification Authority 209の公開鍵 v_caを用いて、匿名公開鍵証明書APC_ca(i)=(g'、v_i'、X、Sig_ca(g'、v_i'、X))の正当性、すなわち、(g'、v_i')とSig_ca(g'、v_i'、X)の対応関係の正しさを確認する。例えば、ホスト206は、匿名公開鍵証明書APC_ca(i)から(g'、v_i'、X)を取り出し、そのハッシュ値(例えば、H(g'|v_i'|X)、ただし | は連接を示す)を計算し、Sig_ca(g'、v_i'、X)がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵v_caを用いて確認する。ホスト206は、Certification Authority 209の公開鍵 v_caを予め記憶している。匿名公開鍵証明書の管理・属性情報Xに公開鍵 v_caの公開鍵証明書が含まれている形態では、ホスト206は、予め記憶している公開鍵 v_caが、匿名公開鍵証明書の管理・属性情報Xに含まれている公開鍵 v_caの公開鍵証明書中の公開鍵v_caと一致することを確認してから、この公開鍵v_caを用いて、匿名公開鍵証明書の正当性を確認する。
【０１０３】
以上のプロトコルを既存のRouter SolicitationとRouter Advertisementの送受信プロトコルと組み合わせた拡張プロトコルのホストの動作フローチャートを図１１に示す。
【０１０４】
図１１のステップS1101におけるRouter Certificate Solicitationメッセージとは、図９のステップ901のRouter Solicitationと図１のステップS102で送られるCertificate Solicitationの両方を含むデータである。ルーター202は、このデータを受信すると、図１のS103、S103A、S104の処理を行ない、S106と同様に、Certification Authority 209から匿名公開鍵証明書を受け取る。そして、ルーター202は、Stateless address autoconfiguration のみを指定するRouter AdvertisementとCertificate Advertisementの両方を含むRouter Certificate Advertisement Messageを、ホスト206に送る。
【０１０５】
したがって、ステップS1102で受け取るRouter Certificate Advertisement Messageとは、図９のステップS902で受け取るRouter Advertisement Messageと図１のステップS107で受け取るCertificate Advertisementの両方を含むデータである。
【０１０６】
図１におけるステップS108を行なって正当性が確認できたならば、ステップS1102で「はい」の場合となり、ステップS1103において、IPv6グローバルアドレスを生成し、インターフェイス301に割当てるとともに、匿名公開鍵証明書の正当性を確認する。ここでは、S108と同様に、Certification Authority 209の公開鍵 v_caを用いて、匿名公開鍵証明書の正当性を確認する。
【０１０７】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なIPv6アドレスと対応する使い捨て匿名公開鍵証明書を発行することができる。
【０１０８】
なお、ルーター202の代りにDHCPサーバー203がCertification Authority 209に信用されている場合は、Router Certificate Advertisement Messageが受信されないので、図１１におけるステップS1106において図１と同様のプロトコルをルーター202の代りにDHCPサーバー203が実行する。なお、DHCPサーバーの管理元はdefault gateway202の管理元と同様にトラブルの際の責任を持つものとする。
【０１０９】
この場合には図１１のステップS1106で、ホストはstateful address autoconfigurationの拡張プロトコル、つまりDHCPサーバーからアドレスと証明書を取得するプロトコルを実行する。その動作フローチャートを図１２に示す。
【０１１０】
図１０のプロトコルとの違いは、ステップS1203とステップS1204の二カ所である。
【０１１１】
ステップS1203で送るDHCP Certificate Request Messageは、図１０のステップS1003で送るDHCP Request Message と図１のステップS102で送られるCertificate Solicitation相当のデータ(送信先が、ルーター202ではなくDHCPサーバー203である点が異なる)の両方を含むデータである。
【０１１２】
このメッセージを受け取ると、DHCPサーバー203は、図１のS103、S103A、S104の処理を行ない、S106と同様に、Certification Authority 209から匿名公開鍵証明書を受け取る。そして、DHCPサーバー203は、DHCP Reply MessageとCertificate Advertisement相当のデータの両方を含むDHCP Certificate Reply Messageを、ホスト206に送る。
【０１１３】
したがって、ステップS1204で受け取るDHCP Certificate Reply Messageは、図１０のステップS1004で受け取るDHCP Reply Messageと図１のステップS107で受け取るCertificate Advertisement相当のデータ(送信元がルーター202ではなくDHCPサーバー203である点が異なる)の両方を含むデータである。そして、IPv6グローバルアドレスを生成し、インターフェイス301に割当てるとともに、匿名公開鍵証明書の正当性を確認する。ここでは、S108と同様に、Certification Authority 209の公開鍵 v_caを用いて、匿名公開鍵証明書の正当性を確認する。
【０１１４】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なIPv6アドレスと対応する使い捨て匿名公開鍵証明書を発行することができる。
【０１１５】
ルーター202およびDHCPサーバー203の両方がCAのCertification Authority 209に信用されている場合は、図１１におけるステップS1104で stateless と stateful の両方を指定するRouter Certificate Advertisement Messageを受け取った場合(「はい」の場合)が相当し、上記に示した二つの拡張プロトコルを任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、使い捨てIPv6グローバルアドレスとそれに対応する使い捨て匿名公開鍵証明書、default gateway等を自動設定および取得する。この場合、ルーター202およびDHCPサーバー203は、アドレスを設定するためのアドレス情報をホスト（通信装置）206に提供する情報処理装置群に相当し、この情報処理装置群であるルーター202およびDHCPサーバー203は、公開鍵証明書をCertification Authority 209に要求し、Certification Authority 209が発行した公開鍵証明書をホスト206に送信する。
【０１１６】
ルーター202でもDHCPサーバー203でもない別のIPv6対応装置の専用CAサーバーが公開鍵証明書発行者209に信用されており、専用CAサーバーと公開鍵証明書発行者209とが協調して動作して公開鍵証明書をあるホストに発行する場合、その専用CAサーバーが対象ホストと同一のローカルリンク207内に存在するならば、図１示のルーター202の動作とほぼ同様の動作によって、公開鍵証明書を発行できる。
【０１１７】
図２において、対象ホストがホスト206であり、専用CAサーバーがホスト204である場合、それらの間の動作は図１と同様である。ただし、専用CAサーバーはそのサブネット、図２の場合で言えばリンク207に割当てられている正しいIPv6プレフィクスを知っているという前提を必要とする。したがってルーター202の管理者と同様の責任を有する管理者によって専用CAサーバーは管理されており、問題がおこったときの対応等についてもルーター202の場合と同様にCertification Authority 209と管理者との間で合意がなされている必要がある。
【０１１８】
ホスト206は、通信相手が変る度に、あるいは、セッションが変る度に、若しくは、通信パケット送信の度に、図１１のS1101のRouter Certificate Solicitationメッセージ（図１のS101の匿名公開鍵証明書を要求するメッセージであるCertificate Solicitation）を、インターフェイス301から、リンク207に送出し、Certificate Authority 209からの匿名公開鍵証明書を受け取る。すなわち、ホスト２０６は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、IPv6アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。ここで、公開鍵(g'、v_i')は、同一のエンティティの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１１９】
なお、ルーター202あるいはDHCPサーバー203がIPv6アドレスのプレフィックスをホスト206に提供する形態を説明したが、IPv6アドレスそのものを提供する形態ではプレフィックスのかわりにアドレスが送られる点とホストがアドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１２０】
（第２の実施の形態）
第1の実施の形態では、default gateway(ルーター)がホストを認証してから、default gateway(ルーター)とCertification Authorityが協調動作して、匿名公開鍵証明書とプレフィックスを含む Certificate Advertisement をホストに送った。本実施の形態では、プレフィックスの送付と匿名公開鍵証明書の発行が独立な例を説明する。
【０１２１】
第1の実施の形態と同様に、Certification Authority 209がエンティティCA、ホスト206(もしくはそれを利用するユーザ)が匿名公開鍵証明書を利用するエンティティiになる。但し、Certificaiton Authority 209が前述の匿名公開鍵証明書方式におけるCAの全ての機能を有するわけではない。以下では、匿名公開鍵証明書を利用するIPv6対応装置(ホスト206)の位置するローカルリンク207内に存在し、かつ、公開鍵証明書発行者(CA、つまりCertification Authority209)が信用するIPv6対応装置がdefault gateway 202である場合を説明する。つまり、匿名公開鍵証明書方式におけるエンティティCAの機能の一部は、Certificaiton Authority 209の代わりに、default gateway 202が有する場合を説明する。
【０１２２】
なお、Certification Authority 209が信用するIPv6対応装置はDHCPサーバーや専用サーバーでもよい。また、以下では、ランダムなIPv6アドレスを証明書の中に含める形態を説明するが、ランダムなIPv6アドレスを証明書に含めない形態もあるかもしれない。前述のように、default gateway 202をルーター202と呼ぶことにする。ここでは、default gateway 202は、ホスト206に、IPv6のグローバルアドレスのプレフィックスを提供する。
【０１２３】
また、この場合には、Certification Authority 209とdefault gateway 202(あるいはDHCPサーバーや専用サーバー)は、例えば、公開鍵暗号を安全に交換してあるとか秘密の暗号化鍵を安全に共有してある等により、それらの間では、インターネットを介して確実で安全な通信が行なえるものとする。Certification Authority 209の管理者は、CAとしての公開鍵v_caを定める。ルーター202の管理者は、前述の公開パラメータp、g等を定め、公開する。ルーター202の公開鍵v_routerも定め、公開する。
【０１２４】
ユーザiがLANへのアクセスを申請する際に、公開されているパラメータp、g等を用いて、自分の秘密鍵s_iを生成し、対応する公開鍵v_iを計算して、ユーザ名とパスワード、公開鍵v_iをLANの管理者(ルーター202の管理者)に提出する。LANの管理者(ルーター202の管理者)は、その運用方針に応じてユーザiの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵v_iが検索できるように、RAM 304もしくはHD306に登録する。公開パラメータp、g等や公開鍵v_i、特に秘密鍵s_iはユーザiが管理し、ホスト206で安全に利用可能になっているものとする。
【０１２５】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１５に示す。図１５は、匿名公開鍵証明書を利用するエンティティ (ユーザiが用いるIPv6端末)をホスト206、プレフィックスを提供するIPv6端末をdefault gateway 202、匿名公開鍵証明書を発行するCAをCertification Authority 209とし,それらの間で行なわれる匿名公開鍵証明書の発行プロトコルの動作フローを表している。
【０１２６】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター202とエンティティ(この場合は、ホスト206)の間でなんらかの特定(認証)プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１５を参照しながら動作を説明する。
【０１２７】
ホスト206は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス(図３の301)のMACアドレスからインターフェイスIDを生成する。また、ホスト206は、例えばRFC3041のアルゴリズムによってランダムなインターフェイスIDを生成する。そして、MACアドレスから生成したインターフェイスIDに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない Router Solicitation (RS)をルーターに送る(ステップS1501)。RSは前述のようにリンク上のルーター全て宛の multicast である。
【０１２８】
ルーター202は、RSを受け取ったら、Router Advertisement (RA)を送る(ステップS1502)。
【０１２９】
RAを受け取ったホスト206は、RAに含まれるプレフィックスを抽出し、MACアドレスから生成したインターフェイスIDとプレフィックスとから、グローバルアドレス(public addressと呼ぶ)を生成する。また、ランダムなインターフェイスIDとプレフィックスとから、使い捨てIPv6アドレス(temporary addressと呼ぶ)を作る。そして、public address とtemporary addressの重複検出DAD(Duplicate Address Detection)を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる(ステップS1503)。
【０１３０】
次に、ホスト206はCertificate Solicitationを生成する(ステップS1504)。Certificate Solicitationは、匿名公開鍵証明書を要求するメッセージであり、ホスト206が匿名公開鍵証明書を要求する旨を含むデータであることをルーター202が理解できる形式で生成する。例えば、RFC2986, ``PKCS #10:Certification Request Syntax Specification Version 1.7,''で規定されているPKCS#10や、RFC2511, ``Internet X.509 Certificate Request Message Format''等がそれらの形式を規定している。詳細の説明は省くが、証明書要求メッセージと、それに対する(ホストの)署名からなるデータであるとする。証明書要求メッセージには、temporary addressが含まれている。
【０１３１】
次に、ホスト206は、Certificate Solicitationを、リンク207を介してルーター202に送る(ステップS1505)。なお、この時点でルーター202の(ユニキャスト)アドレスをホスト206は知っているので unicast することが可能である。
【０１３２】
ルーター202はステップS1505で受け取ったCertificate Solicitationに含まれるエンティティ名（ホスト206の識別子もしくはホスト206を利用するユーザの名前）から登録された公開鍵v_iをRAM 305もしくはHD306から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト206の匿名公開鍵を作成する。具体的には、前述のg'、v_i'、p、qが匿名公開鍵である。そして、匿名公開鍵に対する証明書をCertification Authority 209に発行してもらうため、匿名公開鍵証明書要求メッセージを生成する(ステップS1506)。
【０１３３】
次に、ルーター202は、匿名公開鍵証明書要求メッセージをCertification Authority209に送る(ステップS1507)。この匿名公開鍵証明書要求メッセージの形式は前述の証明書要求メッセージと同様とし、匿名公開鍵証明書要求メッセージとそれに対するルーターの署名からなるデータ等であるとする。この匿名公開鍵証明書要求メッセージにはホスト206のtemporary addressが含まれている。
【０１３４】
匿名公開鍵証明書要求メッセージをルーター202から受け取ったCertification Authority209は、それがルーター202によって作成されたか正しいデータであるか否かを確認する。例えば、前述の確実で安全な通信によって受け取った場合は、データを受け取った事実自体が正しいrouter 202に生成されたデータであることを証明するとみなせる場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合にはルーターの公開鍵v_routerで確認できる場合もある。
【０１３５】
いずれにせよ、匿名公開鍵証明書要求メッセージの正当性を確認したCertification Authority 209は、証明書要求メッセージの中に含まれる匿名公開鍵(g'、v_i'、p、q)とtemporary address、それらに関する管理・属性情報を付加したメッセージ(のハッシュ値)に対してディジタル署名を生成し、そのメッセージと、署名からなる匿名公開鍵証明書を生成する(ステップS1508)。本発明のある形態では、この匿名公開鍵証明書は、Certification Authority 209の公開鍵を含む。
【０１３６】
そして、Certification Authority 209は匿名公開鍵証明書を、ルーター202に送る(ステップS1509)。本発明のある形態では、この匿名公開鍵証明書を登録された公開鍵を用いて暗号化して、送信する。
【０１３７】
ルーター202は、匿名公開鍵証明書を含むCertificate Advertisementを、ホスト206に送る(ステップS1510)。本発明のある形態では、このCertificateAdvertisementを登録された公開鍵を用いて暗号化して、送信する。なお、このとき、temporary address宛のunicastとして、Certification Authority209から直接ホスト206に送ることも可能である。
【０１３８】
ホスト206は受け取ったCertificate Advertisementから匿名公開鍵証明書の正当性を確認する(ステップS1511)。
【０１３９】
以上のプロトコルを既存のstateless address autoconfigurationおよびstateful address autoconfigurationと組み合わせた拡張プロトコルのホストの動作フローチャートを図１６に示す。
【０１４０】
ホスト206は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス(図３の301)のMACアドレスからインターフェイスIDを生成する。また、ホスト206は、例えばRFC3041のアルゴリズムによってランダムなインターフェイスIDを生成する。そして、MACアドレスから生成したインターフェイスIDに所定のプレフィックスが付加されたリンクローカルアドレスの生成等を行ない Router Solicitation (RS) をルーターに送る(ステップS1701)。RSは前述のようにリンク上のルーター全て宛の multicast である。
【０１４１】
ステップS1702の「はい」の場合に示すように、Stateless address autoconfiguration のみを指定するRouter Advertisementメッセージ（RA）を受け取ったホスト206は、RAに含まれるプレフィックスを抽出し、MACアドレスから生成したインターフェイスIDと抽出したプレフィックスとから、グローバルアドレス(public addressと呼ぶ)を生成する。また、ランダムなインターフェイスID と抽出したプレフィックスとから、使い捨てIPv6アドレス(temporary addressと呼ぶ)を作る。そして、public address とtemporary addressの重複検出DAD(Duplicate Address Detection)を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる(ステップS1703)。
【０１４２】
次に、ホスト206は、証明書要求と証明書発行のプロトコルを実行する（ステップS1707）。すなわち、ホスト206は、図１５のステップS1504、S1505で示したように、Certificate Solicitationを生成し、ルーター202に送る。ホスト206は、ルーター202からCertificate Advertisementを受け取り、その中に含まれる匿名公開鍵証明書の正当性を確認する。なお、Router Advertisementを何も受け取らなかった場合は(ステップS1704のいいえの場合)、stateful address autoconfiguration、すなわちDHCPv6のみを実行する。これがステップS1706であり、その詳細は図１０のプロトコルと同じである。
【０１４３】
ステップS1704でstateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementメッセージを受け取った場合は、ステップS1705でstateless address autoconfigurationとstateful address autoconfigurationの両方を行なう。処理内容はステップS1703とS1706と同じである。
【０１４４】
（第３の実施の形態）
本実施の形態では、ホストがダイヤルアップあるいはADSLのような方式でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本発明の形態を説明する。
【０１４５】
図１４は、本発明が適用される接続環境を模式的に示したものである。図１４は、ホスト1406がPSTN(Public Switched Telephone Network)経由でISP(Internet Service Provider)の提供するインターネット1401とアクセスする環境を示す。本実施の形態では、ISPとホストはPPPリンクで接続するものとする。
【０１４６】
図１４において、ISPのPPP peer 1402はノードであり、modem 1403を用いてPSTN 1404を介してホスト1406からのPPP接続の要求を受け付ける。PPP peer 1402は、default gateway module 14021、DHCP module 14022、Authentication module 14023としての機能を有する。ホスト1406はmodem 1405を用いてPPP peer 1402にPPP接続でアクセスする。ホスト1406の構成は、図３と同様であり、ネットワーク・インターフェイス301を介して、モデム1405を接続する。また、PPP peer 1402の構成も、図３と同様であり、ネットワーク・インターフェイス301を介して、モデム1403を接続し、ネットワーク・インターフェイス302を介して、リンク1407（さらに、インターネット1401）と接続する。PPP peer 1402は、アドレスを設定するためのアドレス情報をホスト1406（通信装置）に提供するアドレス情報提供装置である。
【０１４７】
本実施の形態では、modemとPSTNを例として取り上げて説明するが、TA(Terminal Adapter)とISDN(Integrated Services Digital Network)、PHS通信アダプターとPHS通信網、専用線接続装置と専用線等の他の通信形態であったとしてもPPP接続が確立できる環境であれば本質的には同じである。PPP接続の詳細は、RFC 1661 ``The Point-to-Point Protocol (PPP)'' に記述されている。
【０１４８】
ホスト1406がモデム1405、PSTN1404、モデム1403を介してPPP接続の要求をPPP peer 1402に伝える。PPP peer 1402は、その接続要求を受け、Authentication module 14023がホストの認証を行なう。典型的な認証方式は、ユーザ名とパスワードに基づく認証プロトコルCHAPであり、詳細はRFC1994 ``PPP Challenge Handshake Authentication Protocol''に記述されている。
【０１４９】
認証が完了したら、DHCP module 14022がその設定に従いIPv6グローバルアドレス(のプレフィックス)やdefault gatewayのIPv6アドレス等をホスト1406に伝える。DHCP module 14022は、ISPの管理者がその運用方針に従った設定を行なっている。
【０１５０】
なお、図１４では説明を簡単にするため、default gateway とDHCPサーバーとAuthentication サーバーをそれぞれdefault gateway module 14021、DHCP module 14022、Authentication module 14023としてPPP peer内部に存在するものとしているが、実際にはリンク1407上にそれぞれ異なるノードとして存在することもある。いずれの実現形態にせよ、それらのmoduleあるいはノードはISPの管理者の元で安全に運用されていれば、構わないので、以下では、図１４の形態でホストとPPP peerの間のPPPリンクが確立したものとして説明する。
【０１５１】
ホスト1406は、DHCP module 14022からIPv6グローバルアドレス(のプレフィックス)やdefault gatewayのIPv6アドレス等を受け取ったならば、IPv6グローバルアドレス(のプレフィックスと自分の(RFC3041等の方法で生成した)ランダムなインターフェイスIDとを組み合わせてランダムなIPv6グローバルアドレスを生成し、それがリンクにおいて重複していないことを確認してから それをインターフェイス301に割当て、default gateway のIPv6アドレスを記憶する。
【０１５２】
以上の動作により、ホスト1406は使い捨てIPv6アドレスを使ってインターネットの任意の相手と通信できる。
【０１５３】
次に、本発明の実施の形態を説明する。上述した動作(プロトコル)を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。
【０１５４】
以下では、匿名公開鍵証明書方式を、図１４の環境に適用した形態を説明する。Certification Authority 1408がCA、ホスト1406(もしくはそれを利用するユーザ)が匿名公開鍵証明書を利用するエンティティiになる。以下では、ランダムなIPv6アドレスを証明書の中に含める形態を説明するが、ランダムなIPv6アドレスを含めないことも可能である。
【０１５５】
Certification Authority 1408 は、前述の公開パラメータp、g等を定め、自分の秘密鍵s_caと公開鍵v_caを定め、公開する。Certification Authority1408 は PPP peer 1402 を信用するものとする。つまり、PPP peer 1402 の管理元、すなわちISPとの間で、問題が生じたときの責任について合意がなされており、Certification Authority 1408 と PPP peer 1402 との間では確実で安全な通信が行なえるようになっている。
【０１５６】
ユーザiがISPに加入を申請する際に、Certification Authority 1408 が公開しているパラメータp、g等を用いて、自分の秘密鍵s_iを生成し、対応する公開鍵v_iを計算して、ユーザ名とパスワード、公開鍵v_iをISPに提出する。ISPの管理元(PPP peer1402の管理元)は、その運用方針に応じてユーザiの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、ユーザ名に対応して公開鍵v_iが検索できるように、RAM 305もしくはHD306に登録する。公開パラメータや公開鍵v_i、特に秘密鍵s_iはユーザiが管理し、ホスト1406で安全に利用可能になっているものとする。
【０１５７】
以上の準備を行なった上で実行される、本実施の形態のプロトコルを図１３に示す。図１３は、エンティティ(ユーザiが用いるIPv6通信装置)をホスト1406、CAをCertification Authority 1408とし、Certification Authority 1408 は PPP peer 1402 を信用し、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。
【０１５８】
PPP接続におけるデータリンク層の処理が終わった後、前述のユーザ名とパスワードに基づく認証プロトコルCHAPによる認証を行なう。
【０１５９】
すなわち、ホスト1406はステップS1301でエンティティ名(ユーザ名)をインターフェイス301からPPP peer1402に送る。ステップS1302でエンティティ名（識別子）をインターフェイス301から受信すると、PPP peer 1402はCHAP-challengeを生成し、ステップS1303でそれをホスト1406にインターフェイス301から送る。
【０１６０】
ホスト1406は、ステップ S1304でCHAP-challengeをインターフェイス301から受信すると、エンティティ名とパスワードとCHAP-challengeをハッシュ関数に入力して求めた結果の値CHAP-responseをステップS1305でPPP peer 1402にインターフェイス301から送る。
【０１６１】
ステップS1306でPPP peer 1402は、CHAP-response をインターフェイス301から受信し、CHAP-responseの正当性を確認する。確認出来たならば認証は成功なので、その認証されたホスト1406に対してIPv6グローバルアドレス(のプレフィックス)やdefault gateway のアドレスをステップS1307でインターフェイス301から伝える。
【０１６２】
ホスト1406は、ステップS1308で、インターフェイス301から受信したIPv6グローバルアドレス(のプレフィックスとランダムなインターフェイスIDとからIPv6グローバルアドレスを生成し、それ)が重複していないことを確認してからそれをインターフェイス301に割当て、default gatewayのアドレスも記憶する。次に匿名公開鍵証明書を要求するメッセージとしてCertificate Solicitation をステップS1309でPPP peer 1402にインターフェイス301から送る。
【０１６３】
Certificate Solicitation は、第1の実施の形態と同様に、匿名公開鍵証明書を要求する旨とインターフェイスIDを含むデータであることをPPP peer 1402が理解できる形式で生成される。内容は、エンティティ名(ユーザ名)とパスワードとシリアル番号から計算され、シリアル番号は、例えば、ホスト206のIPv6リンクローカルアドレスとdefault gatewayのIPv6リンクローカルアドレスとそのときの時刻の3つを連接して一つのデータにした値である。Certificate Solicitationには、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名(認証用signature)が含まれる。
【０１６４】
PPP peer 1402は、ステップS1310で、Certificate Solicitation をインターフェイス301から受信すると、図１のS103Aと同様に、エンティティ名(ホスト（通信装置）206の識別子であるユーザ名)に対応する登録された公開鍵v_iをRAM 305もしくはHD306から検索し、前述のように乱数rを生成して匿名公開鍵(g'とv_i') （=(g^r mod p、 (v_i)^(r) mod p)）を生成し、ホスト1406のIPv6グローバルアドレスと匿名公開鍵(g'とv_i')に対する認証用signatureを生成する。そして、ホスト1406のIPv6グローバルアドレスと匿名公開鍵(g'、v_i')と認証用signatureからなる証明書要求メッセージをステップS1311でCertification Authority 1408にネットワーク・インターフェイス302から送る。
【０１６５】
前述の確実で安全な通信によって受け取った場合は、Certification Authority 1408が、PPP Peer 1402からのデータをネットワーク・インターフェイス301から受け取った事実自体が正しい PPP Peer 1402に生成されたデータであることを証明する場合がある。あるいは公開鍵暗号に基づくディジタル署名である場合もある。
【０１６６】
いずれにせよ、図１のS105と同様に、ステップS1312で認証用signatureの正当性を確認したCertification Authority 1408は、ホスト1406のIPv6グローバルアドレスと匿名公開鍵(g'、v_i')と管理・属性情報Xに対するディジタル署名Sig_ca(g'、v_i'、X)を生成し、ホスト1406のIPv6グローバルアドレスと匿名公開鍵(g'、v_i')と管理・属性情報Xとそれらに対するディジタル署名からなる匿名公開鍵証明書を生成する。そして、Certification Authority 1408は、ステップS1313でネットワーク・インターフェイス301からPPP Peer 1402にその匿名公開鍵証明書を送る。なお、管理・属性情報Xには、この匿名公開鍵証明書の有効期限などが含まれる。
【０１６７】
PPP Peer 1402は、それをネットワーク・インターフェイス302から受け取り、ステップS1314でCertificate Advertisementすなわち匿名公開鍵証明書をインターフェイス301からホスト1406に送る。ホスト1406はネットワーク・インターフェイス301から受け取った匿名公開鍵証明書の正当性をステップS1315で確認する。
【０１６８】
ここで、ホスト1406は、Certification Authority 1408の公開鍵 v_caを用いて、匿名公開鍵証明書APC_ca(i)=(g'、v_i'、X、Sig_ca(g'、v_i'、X))の正当性、すなわち、(g'、v_i')とSig_ca(g'、v_i'、X)の対応関係の正しさを確認する。例えば、ホスト1406は、匿名公開鍵証明書APC_ca(i)から(g'、v_i'、X)を取り出し、そのハッシュ値(例えば、H(g'|v_i'|X)、ただし | は連接を示す)を計算し、Sig_ca(g'、v_i'、X)がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵v_caを用いて確認する。ホスト1406は、Certification Authority 1408の公開鍵 v_caを予め記憶している。匿名公開鍵証明書の管理・属性情報Xに公開鍵 v_caの公開鍵証明書が含まれている形態では、ホスト1406は、予め記憶している公開鍵 v_caが、匿名公開鍵証明書の管理・属性情報Xに含まれている公開鍵 v_caの公開鍵証明書中の公開鍵v_caと一致することを確認してから、この公開鍵v_caを用いて、匿名公開鍵証明書の正当性を確認する。
【０１６９】
以上のプロトコルにおいて、ステップS1305とS1309で送受されるデータを一つにまとめてステップS1305で送ることも可能である。図示しないが、その場合、ホスト1406はランダムなインターフェイスIDとCHAP-responceと Certificate Solicitation (第1の実施例と同様)をステップS1305'でPPP peer1402に送る。
【０１７０】
ステップS1306'で、PPP peer 1402は、CHAP-responseの正当性を確認し、登録された公開鍵v_iを検索し、(IPv6プレフィックスとインターフェイスIDとから)ホスト1406 に割当てるIPv6グローバルアドレス(を生成し、それ)とそのライフタイム(使用期限、例えば24時間等)等を含めたデータを生成し、認証用sigantureと証明書要求メッセージを生成してステップS1307'でCertification Authority 1408に送る。
【０１７１】
Certification Authority 1408はステップS1308'でステップS1312と同様の処理を行ない、ステップS1309'で匿名公開鍵証明書をPPP Peer 1402に送る。PPP Peer 1402はステップS1310'でCertificate Advertisementをホスト1406に送る。ホスト1406は受け取った匿名公開鍵証明書の正当性をステップS1311'で確認する。
【０１７２】
ホスト1406は、通信相手が変る度に、あるいは、セッションが変る度に、若しくは、通信パケット送信の度に、図１３の手順を実行し、 Certificate Authority 1408からの匿名公開鍵証明書を受け取る。すなわち、ホスト1406は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、IPv6アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。ここで、公開鍵(g'、v_i')は、同一のエンティティの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１７３】
なお、以上の説明ではPPP Peer 1402がIPv6プレフィックスをhost 1406に伝え、host1406がIPv6プレフィックスとインターフェイスIDからIPv6アドレスを生成する場合を述べたが、PPP Peer 1402がIPv6アドレスをhost1406に伝え、host 1406がそれを使う場合も同様のプロトコルで実現される。その場合、図３のステップS1307でIPv6プレフィックスの代わりにIPv6アドレスが送られる点とステップS1308でプレフィックスからIPv6アドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１７４】
（第４の実施の形態）
第１の実施の形態、第２の実施の形態や第３の実施の形態で発行された使い捨てIPv6アドレスと使い捨て匿名公開鍵証明書を用いてIPsec通信を行なう形態を説明する。
【０１７５】
まず、秘密データやお互いのIPv6アドレス等のデータであるSA(Security Association)を安全に共有するプロトコルであるIKE(Internet Key Exchange)における公開鍵暗号による暗号化の改訂モードによる認証方法を簡単に説明し、匿名公開鍵証明書を用いる方法を説明する。
【０１７６】
IKEは二つのphaseからなり、Phase 1において安全な通信路を確立し、phase 2では、IPsec等の通信で使用されるSAが前記安全な通信路上で合意される。以下では、Phase 1のみを説明する。IKEのPhase 1にはMain modeとAggressive modeが存在するが、以下に説明するのは、RFC2409 ``The Internet Key Exchange (IKE)''のpp．13-15の5．3 Phase 1 Authenticated with a Revised mode of Public Key Encryption の Main mode である。
【０１７７】
IKEにおいて、通信する2エンティティはInitiatorとResponderと呼ばれる。Initiatorが通信を開始する。最初に、Initiatorが複数のSA（秘密データやお互いのIPv6アドレス等のデータ）をResponderに送り、Responderが使って良いと判断した一つのSAをInitiatorに送ることで、phase 1用のSAを決定する。
【０１７８】
Initiatorは、乱数(Nonceと呼ばれる)を生成し、Responderの公開鍵で暗号化したデータをResponderに送る。Responderは乱数を生成し、Initiatorの公開鍵で暗号化したデータをInitiatorに送る。これにより、それぞれの生成したnonceを共有できるので、他の通信で用いられる暗号の鍵を共有したnonceから生成する。この詳細は、RFC2409 ``The Internet Key Exchange (IKE)''に記載されている。以上の説明から明らかなように、通信相手の公開鍵をIPsec通信に先だって知る必要がある。
【０１７９】
以下のような状況を考える。ある買い物サイトにユーザ206（図２）、1406（図１４）がアクセスする。このサイトは、インターネット201（図２）、1401（図１４）に接続されている（不図示）。このサイトは、図３と同様の構成を有し、インターフェイス301により、インターネット201、1401に接続される。なお、サイトの種類は、買い物サイトに限らない。ホスト206、1406は、この買い物サイトなどのサイトを通信相手とする通信を開始する前に、上述したプロトコルで、Ipv6アドレス、及び、公開鍵を含む公開鍵証明書を得ておく。この形態において、上述した公開鍵証明書に基づき鍵交換・更新・変更プロトコルを実行して暗号・認証通信を行なう手順を行なう。
【０１８０】
このとき、ユーザは買い物サイトのIPv6アドレスを(明示的か非明示的かは問わないが)知っている。実際にアクセスして、そこがユーザにとって正しいサイトであるときに、通信相手のIPv6アドレスを確認することで、ユーザは明示的にアドレスを知ることができる。通信している最中には、買い物サイトも通信相手206、1406のアドレスがわかる。以上の通信は使い捨てIPv6アドレスで行なえる。
【０１８１】
本形態では、送受信者が確定した時点で、使い捨てIPv6アドレスは(更新せず)同一のアドレスを使う。更に、この時点で、サイトとユーザ206、1406は、使い捨て匿名公開鍵証明書APC_ca(i)をお互いに送り合う。IPv6アドレスが使い捨て匿名公開鍵証明書APC_ca(i)のXの中に含まれているので、両者は、そのIPv6アドレスが実際に通信している相手のIPv6アドレスと一致するか否かを確認する。更に、両者は、使い捨て匿名公開鍵証明書の正当性を確認し、それが本当に通信相手の使い捨て匿名公開鍵証明書か否かを判断して、その中に含まれる公開鍵が本当に通信相手の公開鍵か否かを確認する。
【０１８２】
すなわち、ユーザ206、1406は、使い捨て匿名公開鍵証明書を、インターフェイス301から、サイトに送信する。インターネット201、1401に接続されたサイトは、ユーザ206、1406からインターフェイス301を介して受信した使い捨て匿名公開鍵証明書APC_ca(i)に含まれるIPv6アドレスが、ユーザ206、1406のIPv6アドレスと一致するか確認する。更に、サイトは、Certification Authority 209、1408の公開鍵 v_caを用いて、使い捨て匿名公開鍵証明書APC_ca(i)の正当性を確認する。ユーザ206、1406も、同様に、受信した公開鍵証明書に含まれるIPv6アドレスが、サイトのアドレスと一致するか確認するとともに、Certification Authority 209、1408の公開鍵 v_caを用いて、公開鍵証明書の正当性を確認する。
【０１８３】
使い捨て匿名公開鍵証明書の正当性は、次のように確認する。ホスト206、1406は、CA(商用の認証サービスを提供しているVeriSign等)209（図２）、1408（図１４）の公開鍵 v_caを用いて、使い捨て匿名公開鍵証明書APC_ca(i)=(g'、v_i'、X、Sig_ca(g'、v_i'、X))の正当性、すなわち、(g'、v_i')とSig_ca(g'、v_i'、X)の対応関係の正しさを確認する。例えば、ホスト206、1406は、匿名公開鍵証明書APC_ca(i)から(g'、v_i'、X)を取り出し、そのハッシュ値(例えば、H(g'|v_i'|X)、ただし | は連接を示す)を計算し、Sig_ca(g'、v_i'、X)がハッシュ値に対する正しいディジタル署名であるか否かを公開鍵v_caを用いて確認する。ホスト206、1406は、CA(商用の認証サービスを提供しているVeriSign等)209（図２）、1408（図１４）の広く知られている公開鍵 v_caを、予め記憶している。匿名公開鍵証明書の管理・属性情報Xに公開鍵 v_caの公開鍵証明書が含まれている形態では、ホスト206、1406は、予め記憶している公開鍵 v_caが、匿名公開鍵証明書の管理・属性情報Xに含まれている公開鍵 v_caの公開鍵証明書中の公開鍵v_caと一致することを確認してから、この公開鍵v_caを用いて、匿名公開鍵証明書の正当性を確認する。
【０１８４】
ホスト206、1406は、通信相手が変る度に（すなわち、新たに、サイトに接続する度に）、若しくは、セッションが変る毎に、図１１、図１３のプロトコルを実行し、使用するIPv6アドレス及び公開鍵g'とv_i'を更新・変更する。なお、公開鍵g'とv_i'は、通信パケットの送信毎に、更新・変更してもよい。すなわち、ホスト206、1406は、必要に応じて、新たな公開証明書を要求して、受け取ることにより、プライバシ保護を実現し、更に、通信相手に、IPv6アドレスを含む公開鍵証明書を送ることにより、なりすましを防ぐ。
【０１８５】
以上により、使い捨てIPv6アドレスとそれを含む使い捨て匿名公開鍵証明書を用いて、IPv6アドレスで定義される通信相手の公開鍵を確実に入手できる。このようにして交換した公開鍵を用いて前述のIKE の phase 1 の Main mode を行ない、そのIPv6アドレスを持つ通信相手とのIPsec通信を行なう。
【０１８６】
すなわち、前述のサイトは、ユーザ206、1406から受信した使い捨て匿名公開鍵証明書が正当な使い捨て公開鍵証明書であることを確認すると、その使い捨て公開鍵証明書の公開鍵(g'、v_i')を用いて、インターフェイス301により、前述のIKE の phase 1 の Main mode を行ない、そのIPv6アドレスを持つユーザ206、1406とのIPsec通信を行なう。ユーザ206、1406も同様に、インターフェイス301により、前述のIKE の phase 1 の Main mode を行ない、そのIPv6アドレスを持つサイトとのIPsec通信を行なう。
【０１８７】
従って、課題で述べたような通信相手のなりすましを防ぐことができる。
【０１８８】
【発明の効果】
以上説明したように、本出願に関わる発明によれば、以下のような効果を奏するものである。
すなわち、通信装置の秘密鍵を、通信装置以外に知られることなく、通信装置の匿名公開鍵の証明書を発行することができるので、強力なプライバシ保護を実現することができ、公開鍵を通信装置で生成する必要がないので、匿名公開鍵の証明書を効率的に実現することができ、また、公開鍵生成装置は、匿名公開鍵証明書要求メッセージに含まれるインターフェイスＩＤあるいは使い捨てＩＰｖ６アドレスが、その匿名公開鍵証明書要求メッセージを送信した通信装置のインターフェイスＩＤあるいは使い捨てＩＰｖ６アドレスと同じか否かを確認することができる。
【０１８９】
また、なりすましを防ぐことができる。
【０１９０】
また、IPv6アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することができる。
【０１９１】
また、プライバシ保護の程度が高く、低コストで実現が可能で、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能にすることができる。
【図面の簡単な説明】
【図１】第1の実施の形態における匿名公開鍵証明書発行プロトコル(イーサネット（Ｒ）LANの場合)図である。
【図２】イーサネット（Ｒ）LANの模式図である。
【図３】ノードの構成図である。
【図４】イーサネット（Ｒ）のMACアドレスの構成図である。
【図５】インターフェイスIDの構成図である。
【図６】  a tentative link-local addressの構成図である。
【図７】あるtentative link-local addressのsolicited-node multicast addressの構成図である。
【図８】ホストがDADを終えるまでの動作を説明するフローチャート図である。
【図９】ホストがアドレス自動設定を終えるまでの動作を説明するフローチャート図である。
【図１０】ホストがDHCPでアドレスを取得するまでの動作フローチャート図である。
【図１１】ホストがアドレス自動設定を行ない、匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１２】ホストがDHCPでアドレスと匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１３】第３の実施の形態における匿名公開鍵証明書発行プロトコル(PPPの場合)図である。
【図１４】ダイヤルアップ／ADSL接続の模式図である。
【図１５】第２の実施の形態における匿名公開鍵証明書発行プロトコル（イーサネット（Ｒ）ＬＡＮの場合）図である。
【図１６】ホストが証明書を取得するまでの動作フローチャート図である。
【符号の説明】
３００  ノード
３０１  ネットワーク・インターフェイス
３０２  ネットワーク・インターフェイス
３０６  HD(ハードディスク)
３０８  キーボード/ポインティングデバイスのインターフェイス
３０９  モニターのインターフェイス
３１０  バス
１４０２  ISPのPPP peer
１４０４  PSTN (Public Switched Telephone Network)
１４０７  ISPとインターネットとの間のリンク
【図１】
0004280536.tif 000002
【図２】
0004280536.tif 000003
【図３】
0004280536.tif 000004
【図４】
0004280536.tif 000005
【図５】
0004280536.tif 000006
【図６】
0004280536.tif 000007
【図７】
0004280536.tif 000008
【図８】
0004280536.tif 000009
【図９】
0004280536.tif 000010
【図１０】
0004280536.tif 000011
【図１１】
0004280536.tif 000012
【図１２】
0004280536.tif 000013
【図１３】
0004280536.tif 000014
【図１４】
0004280536.tif 000015
【図１５】
0004280536.tif 000016
【図１６】
0004280536.tif 000017