JP3782788B2 - 公開鍵証明書提供装置、方法、及び、接続装置 - Google Patents
公開鍵証明書提供装置、方法、及び、接続装置 Download PDFInfo
- Publication number
- JP3782788B2 JP3782788B2 JP2003085335A JP2003085335A JP3782788B2 JP 3782788 B2 JP3782788 B2 JP 3782788B2 JP 2003085335 A JP2003085335 A JP 2003085335A JP 2003085335 A JP2003085335 A JP 2003085335A JP 3782788 B2 JP3782788 B2 JP 3782788B2
- Authority
- JP
- Japan
- Prior art keywords
- public key
- certificate
- address
- ipv6
- key certificate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、公開鍵証明書を提供する提供装置、提供方法、及び、インターネットとＩＰｖ６接続装置を接続する接続装置に関する。
【０００２】
【従来の技術】
IPv6の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けディジタルカメラである。
【０００３】
IPv6に対応するパーソナル・コンピュータやワークステーションの場合、ネットワークとの接続のインターフェイスには通常はイーサネット（Ｒ）が用いられ、それが持つ IEEE identifier (MAC address)を元にしてIPv6アドレスが構成されるようになっている。
【０００４】
IPv6アドレスには、後述するようにリンクローカルアドレス、サイトローカルアドレスと(集約可能)、グローバルアドレスの3種類が存在する。
【０００５】
それらの詳細や構成方法などのアドレス体系は、RFC 2373 ``IP Version 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)のようにハードウェアに1対1に対応する情報を固定的に用いると、それが装置もしくはその装置のユーザと1対1に対応する情報とみなされ、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。
【０００７】
この課題に対しては、ランダムなIPv6アドレス(正確にはインターフェイスID)を生成する方法が、RFC3041 ``Privacy Extensions for Stateless Address Autoconfiguration in IPv6、'' 等において提案されている。
【０００８】
生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算／生成し、ユニークなランダムな値を定めるプロトコル(の拡張)も記述されている。
【０００９】
上記のような解決方法を利用して生成したランダムなIPv6アドレスを装置が使う場合に、IPsecを用いて暗号通信を行なうことを考える。
【００１０】
IPsecは、インターネット上の2つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであり、通信に際して秘密データやお互いのIPv6アドレス等を安全に共有する必要がある。秘密データやお互いのIPv6アドレス等のデータはSA(Security Association)と呼ばれる。
【００１１】
SAを安全に共有するプロトコルはIKE(Internet Key Exchange)と呼ばれ、RFC2409 ``The Internet Key Exchange (IKE)''において規定されている。ここで、SAを安全に共有するという意味は、意図する相手のみと確実にSAを共有するという意味であり、相手を確実に認証することを必要とする。IKEには、1) pre-shared keyを用いる方法、2) ディジタル署名を用いる方法、3)公開鍵暗号による暗号化による方法、4)公開鍵暗号による暗号化の改訂モードによる方法、の計4つの認証方法が規定されている。
【００１２】
ところが、プライバシ保護(身元を明らかにする情報を与えない)を実現する状況を考えると、例えばユーザが買い物サイトとの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対応装置が用いるIPv6アドレスの一意性を公開鍵証明書発行者が容易に確認することを可能とし、その上で公開鍵証明書を発行できるようにすることにある。
【００２３】
本発明の他の目的は、IPv6アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することにある。
【００２４】
本発明の他の目的は、IPv6アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を利用して、IKE及びIPsec通信を行なうことにある。
【００２５】
本発明の他の目的は、ランダムなIPv6アドレスを含む、毎回異なる匿名公開鍵証明書を使うIPsec通信が効率的に実現可能とし、強力なプライバシ保護を実現し、かつなりすましを防ぐことができるようにすることにある。
【００２６】
【課題を解決するための手段】
上記課題を解決するために、本出願に関わる発明は、第二の公開鍵の証明書、及び、第二の秘密鍵を有する公開鍵証明書提供装置であって、第一の公開鍵、ディジタル署名、及び、前記第一の公開鍵の匿名公開鍵証明書を生成する生成手段と、前記生成手段により生成された第一の公開鍵の匿名公開鍵証明書をＩＰｖ６対応装置に提供する提供手段とを有し、前記生成手段により生成される第一の公開鍵は、第一の秘密鍵を有する前記ＩＰｖ６対応装置が前記第一の公開鍵を前記第一の秘密鍵と共に利用できるように生成され、前記生成手段により生成されるディジタル署名は、前記第二の公開鍵を用いて正当性が確認できるように、前記第二の秘密鍵を用いて生成され、前記生成手段により生成される第一の公開鍵の匿名公開鍵証明書は、前記第二の公開鍵の証明書、及び、前記ディジタル署名を含み、前記第二の公開鍵の証明書は、認証サービス提供者により発行された証明書であることを特徴とする。
【００２７】
【発明の実施の形態】
（第１の実施の形態）
本実施の形態では、ホストがイーサネット（Ｒ）のLAN経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本実施の形態を説明する。
【００２８】
図２は、本発明が適用される接続環境（ホストがイーサネット（Ｒ）のLAN経由でインターネットと接続する環境）を模式的に示したものである。
【００２９】
図２は、LANに接続されたホスト204、205、206が default gateway（ゲートウェイ）202経由でインターネット201にアクセスする環境を示す。本実施の形態では、各ホストはリンク207で接続するものとし、リンク207は具体的にはイーサネット（Ｒ）であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、IP層の下側に接する。リンクにはイーサネット（Ｒ）の他に、PPPリンク、X.25、フレームリレー、ATMネットワークがある。
【００３０】
リンクに接続されたIPv6対応装置をノードと呼ぶ。
【００３１】
ノードの内部構成の典型例を図３に示す。
【００３２】
ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノード300は、ネットワーク・インターフェイス301、302、CPU303、ROM304、RAM305、HD(ハードディスク)306、電源307、キーボード/ポインティングデバイスのインターフェイス308、モニターのインターフェイス309、バス310等を有する計算機である。
【００３３】
ルーターは複数のネットワーク・インターフェイス301、302を持つのに対し、ホストは多くの場合は一つのネットワーク・インターフェイス301を持つ。ホスト204、205、206は、ネットワーク・インターフェイス301により、リンク207を介して、リンク207に接続された他のノード、あるいは、更に、ゲートウェイ202を介して、インターネット201上のサイトと通信する。default gateway 202は、ネットワーク・インターフェイス301により、リンク207に接続された他のノードと通信すると共に、ネットワーク・インターフェイス302により、インターネット201を介して、通信する。ノードによってはHDを持たないものもある。
【００３４】
なお以下の処理内容(手順)は、装置もしくはプログラムとして実現され、その装置を有するノードが実行、もしくはそのプログラムがROM 304もしくはHD 306に格納されたノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをコンピュータであるCPU 303が読み込み、必要に応じてRAM 305を計算のための空間として利用しながらバス310を介してインターフェイス301にアドレスを割当てる、というような動作を行なう。
【００３５】
ここでは、ノード300がアドレスをインターフェイスに割当てる、というように手順の本質を説明する。
【００３６】
本実施の形態におけるイーサネット（Ｒ）LAN環境で各ホストがIPv6グローバルアドレスのプレフィックスやdefault gateway 202のアドレスを取得するプロトコルの仕組みを簡単に説明し、その次に本発明を適用した具体的な実施の形態を説明する。
【００３７】
図２のリンク207に接続されたノード300が、電源を入れられたあるいはリブートされた場合に行なう動作のフローチャートを図８に示す。この動作はDAD(Duplicate Address Detection)と呼ばれる。以下では図８の流れに沿って、ノード300がDADを終えるまでの処理内容を説明する。
【００３８】
ステップS801でノード300が電源を入れられたあるいはリブートされた後、まずインターフェイス301に割当てられているイーサネット（Ｒ）の MAC address（MACアドレス）(図４参照)からインターフェイスID(図５参照)を作成し、それをtentative link-local address(図６参照)とする（ステップS802）。
【００３９】
次に、そのtentative link-local addressがリンク上で一意かどうかを判断するために、ノード（ホスト）300は以下の処理を行なう。
【００４０】
最初に、インターフェイス301の初期設定をする。すなわち、インターフェイス301に、all-nodes multicast address(FF02::1)とそのtentative link-local address の solicited-node multicast address を割当てる（図7参照）。この結果、そのインターフェイス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 である。図６と図７にそれらの関係を示す。以上のアドレス割当てが図8のステップ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をしている場合、そのtentative link-local address の solicited-node multicast address を割当てられた複数のノードが、同じアドレスを 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 がリンク上で唯一であることが確認された(図８のS805ステップの「いいえ」の場合)ならば、そのアドレスをリンクローカルアドレスとしてインターフェイス301に割当てる。これが図８のステップS806である。以上でDADは終了する。
【００５０】
以上に説明した図８の動作は、図２のリンク207に接続されたノードであるdefault gateway 202、DHCP server 203、ホスト204、ホスト205、ホスト206のそれぞれが、リンク207を収容するネットワーク・インターフェイス301について、実行することができる。
【００５１】
図２のホスト、例えばホスト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はリンク207上のルーター全てに対するマルチキャストとして送られる。図９のステップ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であり、その詳細を図１０に示す。
【００５５】
DHCPサーバー203は管理者によって必要な設定が行われている。具体的には、ノードとして自分のリンクローカルアドレスをネットワーク・インターフェイス301に割当ててあり、DHCPサーバーとして振る舞うために必要なサイトローカルアドレスもしくはグローバルアドレスのためのプレフィックス等が設定されている。
【００５６】
図１０のステップS1001で、ホスト206はDHCPサーバーにDHCP Solicit Messageを送る。ホスト206はどこにDHCPサーバー203が存在するのかわからないのでDHCPサーバー203に対するマルチキャストとしてリンク207に送出する。ホスト206の接続されているリンク207とは異なるリンク(図示せず)にDHCPサーバー203がいる場合には、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を受け取ると、DHCP Reply Messageをホスト206に送る。
【００５９】
ステップS1004でDHCP Reply Messageを受け取ったホスト206は、それからサイトローカルアドレスもしくはグローバルアドレスを決めて、そのアドレスの中のインターフェイスIDが重複しているか否かを確認するために、DAD処理に必要な処理を行なう。つまり、ステップS803と同様に、インターフェイス301にマルチキャストアドレス等を設定する。これがステップS1005である。
【００６０】
次に、ステップS804と同様のNeighbor Solicitation Message をステップS1006で送り、Neighbor Advertisement Messageを受け取るかどうかをステップS1007で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをDHCPサーバー203から受け取るためにステップS1003に戻り、同じ処理を繰り返す。
【００６１】
ホスト206は、図１０のステップS1007でNeighbor Advertisement Messageを受け取らなかった場合は、そのアドレスは重複していないので、DHCP Reply Messageから決めたサイトローカルアドレスもしくはグローバルアドレスをステップS1008でインターフェイス301に割当てる。
【００６２】
以上で図９のステップS906が終わる。ステップS904でRouter Advertisementを何も受け取らなかった場合はこれで正常終了する。
【００６３】
ステップS904でstateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementメッセージを受け取った場合は、ステップS905でstateless address autoconfigurationとstateful address autoconfigurationの両方を行なう。処理内容はステップS903とS906と同じである。
【００６４】
以上のようにして、イーサネット（Ｒ）207をインターフェイスとして持つホスト206はstateless address autoconfiguration とstateful addressautoconfiguration (DHCPv6)を任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、グローバルアドレス、default gateway等を自動設定することができる。
【００６５】
以上のプロトコルにおいて、インターフェイスIDにランダムな値を用いて、その値を対象にしてDADを行ない、リンク207における一意性を確認することにより、ゲートウェイ202あるいはDHCP サーバー203から得たグローバルアドレスのプレフィックスと組み合わせて使い捨ての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は、秘密の乱数s_i(1以上q以下)を生成し、v_i=g^(s_i) mod pを計算する。
【００７０】
s_caやs_iを秘密鍵、v_caやv_i(および公開のパラメータ)を公開鍵と呼び、秘密鍵は自分以外の誰にも知られないように管理する。
【００７１】
エンティティiは、匿名公開鍵証明書を利用開始する際に、自分のエンティティ名(ユーザ名)とパスワード、公開鍵v_iをエンティティCAに登録する。エンティティCAは、必要に応じてエンティティiの身元を物理的手段等で確認し、提示されたエンティティ名(ユーザ名)とパスワード、公開鍵v_iを記憶する。
【００７２】
匿名公開鍵証明書を発行する際、エンティティ CAは、乱数r(1以上q以下)を生成し、(g'、v_i')=(g^r mod p、 (v_i)^(r) mod p)を計算する。上述の公開のパラメータやこの匿名公開鍵証明書の有効期限、及び、公開鍵v_caに対する公開鍵証明書(後述)等の証明書の管理・属性情報をXとし、(g'、v_i')とXを含むメッセージ(のハッシュ値)に対してディジタル署名を生成する。離散対数問題に基づくディジタル署名方式、例えば、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))である。
【００７４】
匿名公開鍵証明書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を秘密鍵として離散対数問題に基づく公開鍵暗号やディジタル署名を利用できる。このように、匿名公開鍵証明書APC_ca(i)は、その管理・属性情報X中に有効期限を含み、匿名公開鍵証明書APC_ca(i)に含まれる公開鍵g'とv_i'は、同一のエンティティiの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【００７５】
匿名公開鍵証明書APC_ca(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)を用いて離散対数問題に基づく公開鍵暗号の暗号化やディジタル署名の検証を行なう。
【００７６】
なお、公開鍵v_caそのものの正当性の確認は、より上位もしくはより普及しているエンティティCA、例えば、商用の認証サービスを提供しているVeriSign等に公開鍵v_caを提出して、公開鍵v_caに対する公開鍵証明書を発行してもらえば、それを用いて確認できる。匿名公開鍵証明書の管理・属性情報をXは、公開鍵v_caに対する公開鍵証明書を含む。この公開鍵v_caに対する公開鍵証明書を用いて、公開鍵v_caそのものの正当性を確認することができる。これは、エンティティCAを階層的に構築することに相当し、順当なPKI(Public-key Infrastructure)を構成することができる。
【００７７】
なお、上記の説明では乗法群(mod p)上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能であり、その場合は乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。
【００７８】
以上の匿名公開鍵証明書方式を、図２の環境に適用する場合を説明する。
【００７９】
default gateway 202もしくはDHCPサーバー 203を、匿名公開鍵証明書を発行するエンティティCA、ホスト206(もしくはそれを利用するユーザ)が匿名公開鍵証明書を利用するエンティティiになる。あるいは、証明書発行のみを担う専用CAサーバーを設けることも可能である。以下では、default gateway 202を、匿名公開鍵証明書を発行するエンティティCAとし、ランダムなIPv6アドレスを証明書の中に含める例を説明するが、DHCPサーバーや専用CAサーバーを、匿名公開鍵証明書を発行するエンティティCAとすること、ランダムなIPv6アドレスを証明書に含めないことも可能である。ここでは、default gateway 202は、ホスト206に、IPv6のグローバルアドレスのプレフィックスを提供する。前述のように、default gateway 202は多くの場合ルーターなので、ルーター202と呼ぶことにする。
【００８０】
ルーター202の管理者は、上述の公開パラメータp、g等を定め、公開する。匿名公開鍵証明書を発行するエンティティCAとしての公開鍵v_caを定め、より上位もしくはより普及しているCA（図２の209）、例えば、商用の認証サービスを提供しているVeriSign等に提出して、公開鍵v_caに対する公開鍵証明書を発行してもらう。
【００８１】
ルーター(gateway)202は、パケットの転送を制御する役目を持ち、そのルーターの管轄するサブネットと外部との間で不適当なパケットが出入りしないように管理者の責任のもとで運用される。あるサブネットがインターネットに接続されるためにはそのサブネットの管理者は身元をJPNIC(日本の場合)に登録し、IPアドレスの割当てを受ける。従って、サブネットにおけるルーターは管理責任が明確であり、かつ安全面も考慮されたうえで運用や管理にコストがかけられると期待されるので、匿名公開鍵証明書を発行するエンティティCAの機能を担わせるのにふさわしいと考えられる。
【００８２】
ユーザ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、匿名公開鍵証明書を発行するCAをルーター202とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。すなわち、IPv6対応装置206が位置するローカルリンク207内に存在するIPv6対応装置202を公開鍵証明書発行者として運用する。
【００８４】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター202とエンティティ(この場合は、ホスト206)の間でなんらかの特定(認証)プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１の流れに沿って動作を説明する。
【００８５】
ホスト206はステップS101でCertificate Solicitationを生成する。Certificate Solicitationは、匿名公開鍵証明書を要求するメッセージであり、匿名公開鍵証明書を要求する旨とホスト206のインターフェイスIDを含むデータであることをルーター202が理解できる形式で生成する。内容は、エンティティ名(ユーザ名)とパスワードとシリアル番号から計算される。シリアル番号は、例えば、ホスト206のIPv6リンクローカルアドレスとdefault gateway 202のIPv6リンクローカルアドレスとそのときの時刻の3つを連接して一つのデータにした値である。再送攻撃となりすましを防ぐために、秘密鍵s_iを用いて、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名(認証用signature) （Sig_i(hash(エンティティ名、パスワード、シリアル番号))）が、Certificate Solicitationに含まれる。
【００８６】
次に、ホスト206は、Certificate SolicitationをステップS102でリンク207を介してルーター202に送る。
【００８７】
ステップS103で、ルーター202はステップS102で受け取ったCertificate Solicitationに含まれるエンティティ名（通信装置（ホスト）206の識別子）から登録された公開鍵v_iをRAM 305もしくはHD306から検索し、それを用いて認証用signatureの正当性を確認する。具体的には、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数の入力とし、そのハッシュ値を求め、認証用signatureがそれに対する正しいディジタル署名であることを公開鍵v_iで確認する。
【００８８】
認証が成功したら、ルーター202に割当てられたIPv6のグローバルアドレスのプレフィックスとホスト206のインターフェイスID とからIPv6グローバルアドレスを生成し、そのライフタイム(使用期限、例えば24時間)等を含む匿名公開鍵証明書APC_ca(i)を作成する。具体的には、前述のAPC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))の中の証明書の管理・属性情報Xの中にIPv6グローバルアドレスやライフタイム等が含まれる。なお、IPv6グローバルアドレスのライフタイム(使用期限)と匿名公開鍵証明書の有効期限は同じとは限らない。
【００８９】
そして、ステップS104でルーター202はIPv6グローバルアドレスのプレフィックスとdefault router 202 のアドレスと匿名公開鍵証明書APC_ca(i)からなるCertificate Advertisementを、リンク207を介して、認証されたホスト206に送る。本発明のある形態では、このCertificate Advertisementを登録された公開鍵を用いて暗号化して、送信する。
【００９０】
ステップS105でホスト206は受け取ったCertificate Advertisementからプレフィックスを取り出し、インターフェイスIDを付加して、IPv6グローバルアドレスを生成するとともに、匿名公開鍵証明書APC_ca(i)の正当性を確認する。このように、匿名公開鍵証明書APC_ca(i)は、その管理・属性情報X中に有効期限を含み、匿名公開鍵証明書APC_ca(i)に含まれる公開鍵g'とv_i'は、同一のエンティティi（ホスト206）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。ホスト206は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１の匿名公開鍵発行プロトコルを実行し、使用する公開鍵g'とv_i'を変更する。
【００９１】
以上のプロトコルを既存のRouter SolicitationとRouter Advertisementの送受信プロトコルと組み合わせた拡張プロトコルのホストの動作フローチャートを図１１に示す。
【００９２】
ホスト206は、図１１のステップS1101において、図９のステップ901で送られるRouter Solicitation Messageと図１のステップS102で送られるCertificate Solicitationの両方を含むデータであるRouter Certificate Solicitation Messageを、リンク207を介して送る。
【００９３】
また、ステップS1102で、図９のステップS902で受け取るRouter Advertisement Messageと図１のステップS104で受け取るCertificate Advertisementの両方を含むデータであるRouter Certificate Advertisement Messageを受け取る。
【００９４】
Router Certificate Advertisement Messageを、リンク207を介して、受け取った場合、すなわち、ステップS1102で「はい」の場合、ホスト206は、ステップS1103では、図９のステップS903と同様に、Router Advertisement Message中のプレフィックスにインターフェイスIDを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとして、インターフェイス301に割当てるとともに、図１におけるステップS105を行なって、公開鍵g'とv_i'を含む匿名公開鍵証明書APC_ca(i)を入手する。
【００９５】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なIPv6アドレスと対応する使い捨て匿名公開鍵証明書をホスト206に発行することができる。
【００９６】
なお、ルーター202の代りにDHCPサーバー203が匿名公開鍵証明書を発行するエンティティCAの役割を行なう場合は、図１１におけるステップS1106において図１と同様のプロトコルを実行する。ここでは、DHCPサーバー203が、ホスト206に、グローバルアドレスのプレフィックスを提供する。この場合には図１１のステップS1106で、ホストはstateful address autoconfigurationの拡張プロトコル、つまりDHCPサーバーからアドレスと証明書を取得するプロトコルを実行する。その動作フローチャートを図１２に示す。
【００９７】
図１０のプロトコルとの違いは、ステップS1203とステップS1204の二カ所である。
【００９８】
ステップS1203では、図１０のステップS1003で送るDHCP Request Message と図１のステップS102で送られるCertificate Solicitation相当のデータ(CAがルーター202ではなくDHCPサーバー203である点が異なる)の両方を含むデータであるDHCP Certificate Request Messageを、リンク207を介して送る。
【００９９】
このDHCP Certificate Request Messageを受け取ると、DHCPサーバー203は、DHCP Certificate Reply Messageを生成し、生成したDHCP Certificate Reply Messageを、リンク207を介して送る。ここで、DHCPサーバー203は、図１のS103のように、匿名公開鍵証明書APC_ca(i)を生成し、DHCPサーバー203のグローバルアドレスのプレフィックスとDHCPサーバー203のアドレスと匿名公開鍵証明書APC_ca(i)からなるCertificate Advertisement相当のデータと、図１のステップS1004のDHCP Reply MessageをDHCP Certificate Reply Messageに含める。
【０１００】
ホスト206は、ステップS1204で、DHCP Certificate Reply Message受け取る。このDHCP Certificate Reply Messageは、図１０のステップS1004で受け取るDHCP Reply Messageと図１のステップS104で受け取るCertificate Advertisement相当のデータ(CAがルーターではなくDHCPサーバーである点が異なる)の両方を含むデータである。したがって、DHCP Reply Messageからサイトローカルアドレスもしくはグローバルアドレスを決めるとともに、公開鍵g'とv_i'を含む匿名公開鍵証明書APC_ca(i)を入手する。
【０１０１】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なIPv6アドレスと対応する使い捨て匿名公開鍵証明書をホスト206に発行することができる。
【０１０２】
ルーター202およびDHCPサーバー203の両方がCAの役割を行なう場合は、図１１におけるステップS1104で stateless と stateful の両方を指定するRouter Certificate Advertisement Messageを受け取った場合(「はい」の場合)に相当し、上記に示した二つの拡張プロトコルを任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、使い捨てIPv6グローバルアドレスとそれに対応する使い捨て匿名公開鍵証明書、default gateway等を自動設定および取得することができる。この場合、ルーター202及び DHCPサーバー203は、公開鍵証明書を提供する通信装置群に相当する。
【０１０３】
ホスト206は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１１の匿名公開鍵証明書を受け取るためのプロトコルを実行し、使用する公開鍵g'とv_i'を変更する。
【０１０４】
なお、DHCPサーバー203がIPv6アドレスのプレフィックスをホスト206に提供する形態を説明したが、IPv6アドレスそのものを提供する形態ではプレフィックスのかわりにアドレスが送られる点とホストがアドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１０５】
(第２の実施の形態)
第１の実施の形態では、default gateway(ルーター)兼CAがホストを認証してから匿名公開鍵証明書とプレフィックスを含む Certificate Advertisement をホストに送った。本実施の形態では、プレフィックスの送付と匿名公開鍵証明書の発行が独立な例を説明する。
【０１０６】
第１の実施の形態と同様に、default gateway 202もしくはDHCPサーバー 203を、匿名公開鍵証明書を発行するエンティティCAとし、ホスト206(もしくはそれを利用するユーザ)が匿名公開鍵証明書を利用するエンティティｉとする。あるいは、証明書発行のみを担う専用CAサーバーを設けることも可能である。以下では、default gateway 202を、匿名公開鍵証明書を発行するエンティティCAとし、ランダムなIPv6アドレスを証明書の中に含める例を説明するが、DHCPサーバーや専用CAサーバーを、匿名公開鍵証明書を発行するエンティティCAとすること、ランダムなIPv6アドレスを証明書に含めないことも可能である。ここでは、default gateway 202は、ホスト206に、IPv6のグローバルアドレスのプレフィックスを提供する。前述のように、default gateway 202は多くの場合ルーターなので、ルーター202と呼ぶことにする。
【０１０７】
ルーター202の管理者は、前述の公開パラメータp、g等を定め、公開する。匿名公開鍵証明書を発行するエンティティCAとしての公開鍵v_caを定め、より上位もしくはより普及しているCA（図２の209）、例えば、商用の認証サービスを提供しているVeriSign等に提出して、公開鍵v_caに対する公開鍵証明書を発行してもらう。
【０１０８】
ユーザ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端末でありかつ匿名公開鍵証明書を発行するCAをdefault gateway 202とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルの動作フローを表している。すなわち、IPv6対応装置206が位置するローカルリンク207内に存在するIPv6対応装置202を公開鍵証明書発行者として運用する。
【０１１０】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター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 MessageFormat''等がそれらの形式を規定している。形式の詳細な説明は省くが、このCertificate Solicitationは、証明書要求メッセージと、それに対する(ホストの)署名からなるデータであるとする。
【０１１５】
次に、ホスト206は、Certificate Solicitationを、リンク207を介してルーター202に送る(ステップS1505)。なお、この時点でルーター202の(ユニキャスト)アドレスをホスト206は知っているので unicast することが可能である。
【０１１６】
ルーター202は、ステップS1505で受け取ったCertificate Solicitationに含まれるエンティティ名（ホスト206の識別子もしくはホスト206を利用するユーザの名前）から登録された公開鍵v_iをRAM 305もしくはHD306から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト206の匿名公開鍵証明書APC_ca(i)を作成する。具体的には、前述のAPC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))の中の証明書の管理・属性情報Xの中にIPv6グローバルアドレスやライフタイム等が含まれる(ステップS1506)。
【０１１７】
そして、ルーター202は匿名公開鍵証明書APC_ca(i)を含むCertificate Advertisementを、リンク207を介して、認証されたホスト206に送る(ステップS1507)。本発明のある形態では、このCertificate Advertisementを登録された公開鍵を用いて暗号化して、送信する。このとき、temporary address宛のunicastとして送ることが可能である。
【０１１８】
ホスト206は受け取ったCertificate Advertisementから匿名公開鍵証明書APC_ca(i)の正当性を確認する(ステップS1508)。
【０１１９】
以上のプロトコルを既存の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を受け取り、その中に含まれる匿名公開鍵証明書APC_ca(i)の正当性を確認する。
【０１２４】
なお、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と同じである。
【０１２６】
以上の説明では、default gateway202(ルーター)がCAを兼ねていたが、一般にはdefault gateway(ルーター)とCAが同一のIPv6装置とは限らない。Default gateway(ルーター)とCAが異なるIPv6装置の場合の動作フローを図１６に示す。
【０１２７】
CAの管理者は、前述の公開パラメータp、g等を定め、公開する。匿名公開鍵証明書を発行するエンティティCAとしての公開鍵v_caを定め、より上位もしくはより普及しているCA（図２の209）、例えば、商用の認証サービスを提供しているVeriSign等に提出して、公開鍵v_caに対する公開鍵証明書を発行してもらう。
【０１２８】
ユーザiがLANへのアクセスを申請する際に、公開されているパラメータp、g等を用いて、自分の秘密鍵s_iを生成し、対応する公開鍵v_iを計算して、ユーザ名とパスワード、公開鍵v_iをCAの管理者に提出する。CAの管理者は、その運用方針に応じてユーザiの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵v_iが検索できるように、RAM 304もしくはHD306に登録する。公開パラメータp、g等や公開鍵v_i、特に秘密鍵s_iはユーザiが管理し、ホスト206で安全に利用可能になっているものとする。
【０１２９】
なお、default gateway (ルーター)202の管理者とCAの管理者が同一であってもよいし、同一でなくてもよい。図１６は、default gateway 202(ルーター)とCAが別のIPv6装置であり、default gateway202にCAのIPv6アドレスが設定されているものとする。
【０１３０】
ホスト206は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス(図３の301)のMACアドレスからインターフェイスIDを生成する。また、ホスト206は、例えばRFC3041のアルゴリズムによってランダムなインターフェイスIDを生成する。前述のようにリンクローカルアドレスの生成等を行ない、Router Solicitation拡張(RS拡張) をrouterに送る(ステップS1601)。RS拡張は、CAのアドレスを要求する旨のメッセージをRouter Solicitationに追加した情報であり、前述のRAと同じくリンク上のルーター全て宛の multicast である。
【０１３１】
ルーター202は、RS拡張を受け取ったら、Router Advertisement拡張 (RA拡張)を送る(ステップS1602)。RA拡張は、CAのアドレスを Router Advertisementに追加した情報である。
【０１３２】
RA拡張を受け取ったホスト206は、RAに含まれるプレフィックスを抽出し、MACアドレスから生成したインターフェイスIDとプレフィックスとから、グローバルアドレス(public address)を生成する。また、ランダムなインターフェイスID とプレフィックスとから、使い捨てIPv6アドレス(temporary addressと呼ぶ)を作る。そして、public address とtemporary addressの重複検出DAD(Duplicate Address Detection)を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる。また、RA拡張からCAのアドレスを抽出する(ステップS1603)。
【０１３３】
次に、ホスト206はCertificate Solicitationを生成し(ステップS1604)、Certificate SolicitationをCAに送る(ステップS1605)。
【０１３４】
CAはステップS1605で受け取ったCertificate Solicitationに含まれるエンティティ名（通信装置（ホスト）206の識別子）から登録された公開鍵v_iをRAM305もしくはHD306から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト206の匿名公開鍵証明書APC_ca(i)を作成する。具体的には、前述のAPC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))の中の証明書の管理・属性情報Xの中にIPv6グローバルアドレスやライフタイム等が含まれる(ステップS1606)。
【０１３５】
そして、CAは匿名公開鍵証明書APC_ca(i)を含むCertificate Advertisementを、ホスト206に送る(ステップS1607)。本発明のある形態では、このCertificate Advertisementを登録された公開鍵を用いて暗号化して、送信する。
【０１３６】
ホスト206は受け取ったCertificate Advertisementから匿名公開鍵証明書APC_ca(i)の正当性を確認する(ステップS1608)。
【０１３７】
以上のプロトコルを既存のstateless address autoconfigurationおよびstateful address autoconfigurationと組み合わせた拡張プロトコルのホストの動作フローチャートは、図１７とほぼ同様であるが、以下の２点が異なる。すなわち、ステップS1701で、Router Solicitation Messageの代わりに、Router Solicitation 拡張 Message を送る。また、ステップS1707で、証明書要求と証明書発行のプロトコルとして、図１６で示したプロトコルを実行する。
【０１３８】
（第３の実施の形態）
本実施の形態では、ホストがダイヤルアップあるいはADSLのような方式でインターネットと接続する形態を説明する。最初に現状を説明し、その後に本発明の実施の形態を説明する。
【０１３９】
図１４は、本発明が適用される接続環境を模式的に示したものである。図１４は、ホスト1406がPSTN(Public Switched Telephone Network)経由でISP(Internet Service Provider)の提供するインターネット1401とアクセスする環境を示す。本実施の形態では、ISPとホスト1401はPPPリンクで接続するものとする。
【０１４０】
図１４において、ISPのPPP peer 1402はノードであり、modem 1403を用いてPSTN 1404を介してホスト1406からのPPP接続の要求を受け付ける。ホスト1406はmodem 1405を用いてPPP peer 1402にPPP接続でアクセスする。ホスト1406の構成は、図３と同様であり、ネットワーク・インターフェイス301を介して、モデム1405を接続する。また、PPP peer 1402の構成も、図３と同様であり、ネットワーク・インターフェイス301を介して、モデム1403を接続し、ネットワーク・インターフェイス302を介して、インターネット1401と接続する。PPP peer 1402は、図１４に示すように、 default gateway module 14021、DHCP module 14022、Authentication module 14023として、機能する。ホスト1406とPPP peer 1402が通信する場合、ホスト1406は、モデム1405を介して、通信を行ない、PPP peer 1402は、モデム1403を介して、通信を行なう。
【０１４１】
本実施の形態では、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の管理者の管理下で安全に運用されていれば構わないので、以下では、図１４の形態でホスト1406とPPP peer 1402の間のPPPリンクが確立したものとして説明する。
【０１４５】
ホスト1406は、DHCP module 14022からIPv6グローバルアドレスのプレフィックスやdefault gatewayのIPv6アドレス等を受け取ったならば、IPv6グローバルアドレスのプレフィックスと自分の(RFC3041等の方法で生成した)ランダムなインターフェイスIDとを組み合わせて、ランダムなIPv6グローバルアドレスを生成し、それがリンクにおいて重複していないことを確認してから、それをインターフェイス301に割当て、default gateway のIPv6アドレスを記憶する。
【０１４６】
以上の動作により、ホスト1406は使い捨てIPv6アドレスを使ってインターネットの任意の相手と通信できる。
【０１４７】
次に、本発明の実施の形態を説明する。上述した動作(プロトコル)を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。
【０１４８】
以下では、匿名公開鍵証明書方式を、図１４の環境に適用する場合を説明する。PPP peer 1402が匿名公開鍵証明書を発行するCA、ホスト1406(もしくはそれを利用するユーザ)が匿名公開鍵証明書を利用するエンティティiになる。以下では、ランダムなIPv6アドレスを証明書の中に含める形態を説明するが、ランダムなIPv6アドレスを含めないことも可能である。
【０１４９】
ISPは、前述の公開パラメータp、g等を定め、公開する。自分の公開鍵v_caを定め、より上位もしくはより普及しているCA（図１４の1408）、例えば、商用の認証サービスを提供しているVeriSign等に提出して、v_caに対する公開鍵証明書を発行してもらう。
【０１５０】
ユーザiがISPに加入を申請する際に、ISPが公開しているパラメータ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をPPP peer 1402とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。
【０１５２】
PPP接続におけるデータリンク層の処理が終わった後、前述のように、ホスト1406からのPPP接続の要求を受けたPPP peer 1402は、Authentication module 14023で、ユーザ名（識別子）とパスワードに基づき、認証プロトコルCHAPによるホストの認証を行なう。
【０１５３】
すなわち、ホスト1406はステップS1301でエンティティ名(ユーザ名)をPPP peer1402に送る。ステップS1302でPPP peer 1402はCHAP-challengeを生成し、ステップS1303でそれをホスト1406に送る。
【０１５４】
ホスト1406はステップ S1304でエンティティ名とパスワードとCHAP-challengeをハッシュ関数に入力してCHAP-responseを求め、求めた結果のCHAP-responseの値をステップS1305でPPP peer 1402に送る。
【０１５５】
ステップS1306でPPP peer 1402は、CHAP-responseの正当性を確認する。確認出来たならば認証は成功なので、その認証されたホスト1406に対してIPv6グローバルアドレスのプレフィックスやdefault gateway のアドレスをステップS1307で伝える。
【０１５６】
ホスト1406は、ステップS1308でIPv6グローバルアドレスのプレフィックスとランダムなインターフェイスIDとからIPv6グローバルアドレスを生成し、それが重複していないことを確認してから、それをネットワーク・インターフェイス301に割当て、default gatewayのアドレスも記憶する。次に匿名公開鍵証明書を要求するメッセージとしてCertificate Solicitation をステップS1309でPPP peer
1402に送る。
【０１５７】
Certificate Solicitation は、第１の実施の形態と同様に、匿名公開鍵証明書を要求する旨とインターフェイスIDを含むデータであることをPPP peer 1402が理解できる形式で生成される。内容は、エンティティ名(ユーザ名)とパスワードとシリアル番号から計算され、シリアル番号は、例えば、ホスト206のIPv6リンクローカルアドレスとdefault gatewayのIPv6リンクローカルアドレスとそのときの時刻の3つを連接して一つのデータにした値である。Certificate Solicitationには、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名(認証用signature)が含まれる。
【０１５８】
PPP peer 1402は、エンティティ名(通信装置（ホスト）206のユーザ名)に対応する登録された公開鍵v_iをRAM 305もしくはHD306から検索し、前述の図１のS103で説明した匿名公開鍵証明書の生成をステップS1310で実行する。すなわち、PPP peer 1402に割当てられたIPv6のグローバルアドレスのプレフィックスとホスト1406のインターフェイスID とからIPv6グローバルアドレスを生成し、そのライフタイム等を含む匿名公開鍵証明書APC_ca(i)を作成する。具体的には、前述のAPC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))の中の証明書の管理・属性情報Xの中にIPv6グローバルアドレスやライフタイム等が含まれる。
【０１５９】
そして、図１のS104と同様に、生成された匿名公開鍵証明書APC_ca(i)等を含むCertificate Advertisementをホスト1406に対してステップS1311で送る。ホスト1406は受け取った匿名公開鍵証明書APC_ca(i)の正当性をステップS1312で確認する。このように、匿名公開鍵証明書APC_ca(i)は、その管理・属性情報X中に有効期限を含み、匿名公開鍵証明書APC_ca(i)に含まれる公開鍵g'とv_i'は、同一のエンティティi（ホスト1406）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１６０】
以上のプロトコルにおいて、ステップS1305とS1309で送受されるデータを一つにまとめてステップS1305で送ることも可能である。図示しないが、その場合、ホスト1406はランダムなインターフェイスIDと図１３のステップS1305のCHAP-responceとステップS1309の Certificate Solicitation (第１の実施の形態と同様)をステップS1305'でPPP peer1402に送る。
【０１６１】
そして、ステップS1306'で、PPP peer 1402は、CHAP-responseの正当性を確認し、登録された公開鍵v_iを検索し、IPv6プレフィックスとインターフェイスIDとからIPv6グローバルアドレスを生成し、それとそのライフタイム(使用期限、例えば24時間等)等を含めたデータを生成し、匿名公開鍵証明書APC_ca(i)を生成する。生成された匿名公開鍵証明書APC_ca(i)を含むCertificate Advertisementをホスト1406に対してステップS1307'で送る。
【０１６２】
ホスト1406は受け取った匿名公開鍵証明書APC_ca(i)の正当性をステップS1308'で確認する。このステップS1308'で図１３のステップS1312に相当する処理まで終了するので、これ以降のステップは存在しない。
【０１６３】
以上のプロトコルで、PPP peer 1402は、ホスト1406に、使い捨て可能なIPv6アドレスと対応する使い捨て匿名公開鍵証明書を発行する。
【０１６４】
ホスト1406は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１３の匿名公開鍵証明書発行プロトコルを実行し、使用する公開鍵g'とv_i'を変更する。
【０１６５】
なお、以上の説明ではPPP Peer 1402がIPv6プレフィックスをhost1406に伝え、host1406がIPv6プレフィックスとインターフェイスIDからIPv6アドレスを生成する場合を述べたが、PPP Peer 1402がIPv6アドレスをhost1406に伝え、host1406がそれを使う場合も同様のプロトコルで実現される．その場合、図３のステップ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を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、ゲートウェイ202を介して、ユーザであるホスト206に接続され、図１４の形態では、インターネット1401、PPP peer 1402を介して、ユーザであるホスト1406に接続される。ホスト206、1406は、この買い物サイトなどのサイトを通信相手とする通信を開始する前に、上述したプロトコルで、Ipv6アドレス、及び、公開鍵を含む公開鍵証明書を得ておく。この形態において、上述した公開鍵証明書に基づき鍵交換・更新・変更プロトコルを実行して暗号・認証通信を行なう手順を行なう。
【０１７２】
このとき、ユーザは買い物サイトのIPv6アドレス（識別子）を(明示的か非明示的かは問わないが)知っている。実際にアクセスして、そこがユーザにとって正しいサイトであるときに、通信相手のIPv6アドレスを確認することでユーザは明示的にアドレスを知ることができる。通信している最中には、買い物サイトも通信相手のアドレス（識別子）はわかる。以上の通信は使い捨てIPv6アドレスで行なえる。
【０１７３】
本形態では、送受信者が確定した時点で、使い捨てIPv6アドレスは(更新せず)、同一のアドレスを使うこととする。この時点で、使い捨て匿名公開鍵証明書APC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))をお互いに送り合う。すると、使い捨て匿名公開鍵証明書APC_ca(i)中の管理・属性情報Xには、IPv6グローバルアドレスが含まれているので、そのIPv6アドレスが実際に通信している相手のIPv6アドレスと一致するか否かを確認し、かつ使い捨て匿名公開鍵証明書の正当性を確認すれば、それが本当に通信相手の使い捨て匿名公開鍵証明書か否かを判断でき、その中に含まれる公開鍵(g'、v_i')が本当に通信相手の公開鍵か否かを確認できる。
【０１７４】
使い捨て匿名公開鍵証明書の正当性は、次のように確認できる。証明書の管理・属性情報XにはCA(前述のルーター202やDHCPサーバー203、又は、PPP peer 1402)の公開鍵v_caとそれに対する公開鍵証明書(商用の認証サービスを提供しているVeriSign等が発行した証明書)が含まれている。サイトは、それらの対応関係が正しいか否かを、商用の認証サービスを提供しているVeriSign等の公開鍵(広く知られているので容易に入手できる)を用いて確認できる。正当性が確認できたv_caを用いて、使い捨て匿名公開鍵証明書APC_ca(i)=(g'、v_i'、X、Sig_ca(g'、v_i'、X))の正当性、すなわち、(g'、v_i')とSig_ca(g'、v_i'、X)の対応関係の正しさを確認できる。匿名公開鍵証明書APC_ca(i)は、その管理・属性情報X中に有効期限を含み、匿名公開鍵証明書APC_ca(i)に含まれる公開鍵g'とv_i'は、同一のエンティティiの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１７５】
ホスト206、1406は、通信相手が変る度に（すなわち、新たに、サイトに接続する度に）、若しくは、セッションが変る毎に、図１１、図１３のプロトコルを実行し、使用するIPv6アドレス及び公開鍵g'とv_i'を更新・変更する。なお、公開鍵g'とv_i'は、通信パケットの送信毎に、更新・変更してもよい。
【０１７６】
以上により、使い捨てIPv6アドレスとそれを含む使い捨て匿名公開鍵証明書を用いて、IPv6アドレスで定義される通信相手の公開鍵を確実に入手できる。このようにして交換した公開鍵を用いて前述のIKE の phase 1 の Main mode を行なうことにより、そのIPv6アドレスを持つ通信相手とのIPsec通信が実行できる。
【０１７７】
すなわち、本形態では、IPv6対応装置が位置するローカルリンク内に存在するIPv6対応装置を公開鍵証明書発行者として運用し、使い捨て匿名公開鍵証明書の中にIPv6アドレスを含めて、インターネット上の2つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであるIPsec通信、及び、IPsecに際して、秘密データやお互いのIPv6アドレス等のSA(Security Association)を安全に共有するプロトコルであるIKE(Internet Key Exchange)を行なう。
【０１７８】
従って、課題で述べたような通信相手のなりすましは防がれる。
【０１７９】
【発明の効果】
以上説明したように、本出願に関わる発明によれば、使い捨て匿名公開鍵証明書を必要とするＩＰｖ６対応装置に対して、匿名公開鍵証明書を効率的に確実に発行することができ、ＩＰｖ６対応装置は、公開鍵証明書提供装置から受け取った匿名公開鍵証明書を、使い捨て匿名公開鍵証明書として、使い捨てることが可能になる。
さらに、匿名公開鍵証明書の正当性の確認に用いられるディジタル署名を確認するための公開鍵の正当性も、確認することができる。
【０１８０】
また、匿名公開鍵を生成するためのホストが計算する負荷を軽減することができる。
【０１８１】
さらに、プライバシ保護の程度が高く、低コストで実現可能であり、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能である。
【０１８２】
また、強力なプライバシ保護を実現し、かつなりすましを防ぎながらIKEによるIPsec通信を行なうことができる。
【図面の簡単な説明】
【図１】第１の実施の形態における匿名公開鍵証明書発行プロトコル(イーサネット（Ｒ）LANの場合)の図である。
【図２】イーサネット（Ｒ）LANの模式図である。
【図３】ノードの構成図である。
【図４】イーサネット（Ｒ）のMACアドレスの構成図である。
【図５】インターフェイスIDの構成図である。
【図６】 a tentative link-local addressの構成図である。
【図７】あるtentative link-local addressのsolicited-node multicast addressの構成図である。
【図８】ホストがDADを終えるまでの動作を説明するフローチャート図である。
【図９】ホストがアドレス自動設定を終えるまでの動作を説明するフローチャート図である。
【図１０】ホストがDHCPでアドレスを取得するまでの動作フローチャート図である。
【図１１】ホストがアドレス自動設定を行ない、匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１２】ホストがDHCPでアドレスと匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１３】第３の実施の形態における匿名公開鍵証明書発行プロトコル(PPPの場合)の図である。
【図１４】ダイヤルアップ／ADSL接続の模式図である。
【図１５】第２の実施の形態における匿名公開鍵証明書発行プロトコル(イーサネット（Ｒ）LANの場合)の図である。
【図１６】匿名公開鍵証明書発行プロトコルの一般形の図である。
【図１７】ホストが証明書を取得するまでの動作フローチャート図である。
【符号の説明】
300 ノード
301 ネットワーク・インターフェイス
302 ネットワーク・インターフェイス
306 HD(ハードディスク)
308 キーボード/ポインティングデバイスのインターフェイス
309 モニターのインターフェイス
1402 ISPのPPP peer
1404 PSTN (Public Switched Telephone Network)
【発明の属する技術分野】
本発明は、公開鍵証明書を提供する提供装置、提供方法、及び、インターネットとＩＰｖ６接続装置を接続する接続装置に関する。
【０００２】
【従来の技術】
IPv6の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けディジタルカメラである。
【０００３】
IPv6に対応するパーソナル・コンピュータやワークステーションの場合、ネットワークとの接続のインターフェイスには通常はイーサネット（Ｒ）が用いられ、それが持つ IEEE identifier (MAC address)を元にしてIPv6アドレスが構成されるようになっている。
【０００４】
IPv6アドレスには、後述するようにリンクローカルアドレス、サイトローカルアドレスと(集約可能)、グローバルアドレスの3種類が存在する。
【０００５】
それらの詳細や構成方法などのアドレス体系は、RFC 2373 ``IP Version 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)のようにハードウェアに1対1に対応する情報を固定的に用いると、それが装置もしくはその装置のユーザと1対1に対応する情報とみなされ、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。
【０００７】
この課題に対しては、ランダムなIPv6アドレス(正確にはインターフェイスID)を生成する方法が、RFC3041 ``Privacy Extensions for Stateless Address Autoconfiguration in IPv6、'' 等において提案されている。
【０００８】
生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算／生成し、ユニークなランダムな値を定めるプロトコル(の拡張)も記述されている。
【０００９】
上記のような解決方法を利用して生成したランダムなIPv6アドレスを装置が使う場合に、IPsecを用いて暗号通信を行なうことを考える。
【００１０】
IPsecは、インターネット上の2つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであり、通信に際して秘密データやお互いのIPv6アドレス等を安全に共有する必要がある。秘密データやお互いのIPv6アドレス等のデータはSA(Security Association)と呼ばれる。
【００１１】
SAを安全に共有するプロトコルはIKE(Internet Key Exchange)と呼ばれ、RFC2409 ``The Internet Key Exchange (IKE)''において規定されている。ここで、SAを安全に共有するという意味は、意図する相手のみと確実にSAを共有するという意味であり、相手を確実に認証することを必要とする。IKEには、1) pre-shared keyを用いる方法、2) ディジタル署名を用いる方法、3)公開鍵暗号による暗号化による方法、4)公開鍵暗号による暗号化の改訂モードによる方法、の計4つの認証方法が規定されている。
【００１２】
ところが、プライバシ保護(身元を明らかにする情報を与えない)を実現する状況を考えると、例えばユーザが買い物サイトとの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対応装置が用いるIPv6アドレスの一意性を公開鍵証明書発行者が容易に確認することを可能とし、その上で公開鍵証明書を発行できるようにすることにある。
【００２３】
本発明の他の目的は、IPv6アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を効率的かつ確実に、つまり発行対象を間違えることなしに素早く発行することにある。
【００２４】
本発明の他の目的は、IPv6アドレスを証明対象に含めた使い捨て匿名公開鍵証明書を利用して、IKE及びIPsec通信を行なうことにある。
【００２５】
本発明の他の目的は、ランダムなIPv6アドレスを含む、毎回異なる匿名公開鍵証明書を使うIPsec通信が効率的に実現可能とし、強力なプライバシ保護を実現し、かつなりすましを防ぐことができるようにすることにある。
【００２６】
【課題を解決するための手段】
上記課題を解決するために、本出願に関わる発明は、第二の公開鍵の証明書、及び、第二の秘密鍵を有する公開鍵証明書提供装置であって、第一の公開鍵、ディジタル署名、及び、前記第一の公開鍵の匿名公開鍵証明書を生成する生成手段と、前記生成手段により生成された第一の公開鍵の匿名公開鍵証明書をＩＰｖ６対応装置に提供する提供手段とを有し、前記生成手段により生成される第一の公開鍵は、第一の秘密鍵を有する前記ＩＰｖ６対応装置が前記第一の公開鍵を前記第一の秘密鍵と共に利用できるように生成され、前記生成手段により生成されるディジタル署名は、前記第二の公開鍵を用いて正当性が確認できるように、前記第二の秘密鍵を用いて生成され、前記生成手段により生成される第一の公開鍵の匿名公開鍵証明書は、前記第二の公開鍵の証明書、及び、前記ディジタル署名を含み、前記第二の公開鍵の証明書は、認証サービス提供者により発行された証明書であることを特徴とする。
【００２７】
【発明の実施の形態】
（第１の実施の形態）
本実施の形態では、ホストがイーサネット（Ｒ）のLAN経由でインターネットと接続する場合を説明する。最初に現状を説明し、その後に本実施の形態を説明する。
【００２８】
図２は、本発明が適用される接続環境（ホストがイーサネット（Ｒ）のLAN経由でインターネットと接続する環境）を模式的に示したものである。
【００２９】
図２は、LANに接続されたホスト204、205、206が default gateway（ゲートウェイ）202経由でインターネット201にアクセスする環境を示す。本実施の形態では、各ホストはリンク207で接続するものとし、リンク207は具体的にはイーサネット（Ｒ）であるとする。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、IP層の下側に接する。リンクにはイーサネット（Ｒ）の他に、PPPリンク、X.25、フレームリレー、ATMネットワークがある。
【００３０】
リンクに接続されたIPv6対応装置をノードと呼ぶ。
【００３１】
ノードの内部構成の典型例を図３に示す。
【００３２】
ノードには、ルーターとホストがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図３からわかるように、ノード300は、ネットワーク・インターフェイス301、302、CPU303、ROM304、RAM305、HD(ハードディスク)306、電源307、キーボード/ポインティングデバイスのインターフェイス308、モニターのインターフェイス309、バス310等を有する計算機である。
【００３３】
ルーターは複数のネットワーク・インターフェイス301、302を持つのに対し、ホストは多くの場合は一つのネットワーク・インターフェイス301を持つ。ホスト204、205、206は、ネットワーク・インターフェイス301により、リンク207を介して、リンク207に接続された他のノード、あるいは、更に、ゲートウェイ202を介して、インターネット201上のサイトと通信する。default gateway 202は、ネットワーク・インターフェイス301により、リンク207に接続された他のノードと通信すると共に、ネットワーク・インターフェイス302により、インターネット201を介して、通信する。ノードによってはHDを持たないものもある。
【００３４】
なお以下の処理内容(手順)は、装置もしくはプログラムとして実現され、その装置を有するノードが実行、もしくはそのプログラムがROM 304もしくはHD 306に格納されたノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをコンピュータであるCPU 303が読み込み、必要に応じてRAM 305を計算のための空間として利用しながらバス310を介してインターフェイス301にアドレスを割当てる、というような動作を行なう。
【００３５】
ここでは、ノード300がアドレスをインターフェイスに割当てる、というように手順の本質を説明する。
【００３６】
本実施の形態におけるイーサネット（Ｒ）LAN環境で各ホストがIPv6グローバルアドレスのプレフィックスやdefault gateway 202のアドレスを取得するプロトコルの仕組みを簡単に説明し、その次に本発明を適用した具体的な実施の形態を説明する。
【００３７】
図２のリンク207に接続されたノード300が、電源を入れられたあるいはリブートされた場合に行なう動作のフローチャートを図８に示す。この動作はDAD(Duplicate Address Detection)と呼ばれる。以下では図８の流れに沿って、ノード300がDADを終えるまでの処理内容を説明する。
【００３８】
ステップS801でノード300が電源を入れられたあるいはリブートされた後、まずインターフェイス301に割当てられているイーサネット（Ｒ）の MAC address（MACアドレス）(図４参照)からインターフェイスID(図５参照)を作成し、それをtentative link-local address(図６参照)とする（ステップS802）。
【００３９】
次に、そのtentative link-local addressがリンク上で一意かどうかを判断するために、ノード（ホスト）300は以下の処理を行なう。
【００４０】
最初に、インターフェイス301の初期設定をする。すなわち、インターフェイス301に、all-nodes multicast address(FF02::1)とそのtentative link-local address の solicited-node multicast address を割当てる（図7参照）。この結果、そのインターフェイス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 である。図６と図７にそれらの関係を示す。以上のアドレス割当てが図8のステップ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をしている場合、そのtentative link-local address の solicited-node multicast address を割当てられた複数のノードが、同じアドレスを 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 がリンク上で唯一であることが確認された(図８のS805ステップの「いいえ」の場合)ならば、そのアドレスをリンクローカルアドレスとしてインターフェイス301に割当てる。これが図８のステップS806である。以上でDADは終了する。
【００５０】
以上に説明した図８の動作は、図２のリンク207に接続されたノードであるdefault gateway 202、DHCP server 203、ホスト204、ホスト205、ホスト206のそれぞれが、リンク207を収容するネットワーク・インターフェイス301について、実行することができる。
【００５１】
図２のホスト、例えばホスト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はリンク207上のルーター全てに対するマルチキャストとして送られる。図９のステップ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であり、その詳細を図１０に示す。
【００５５】
DHCPサーバー203は管理者によって必要な設定が行われている。具体的には、ノードとして自分のリンクローカルアドレスをネットワーク・インターフェイス301に割当ててあり、DHCPサーバーとして振る舞うために必要なサイトローカルアドレスもしくはグローバルアドレスのためのプレフィックス等が設定されている。
【００５６】
図１０のステップS1001で、ホスト206はDHCPサーバーにDHCP Solicit Messageを送る。ホスト206はどこにDHCPサーバー203が存在するのかわからないのでDHCPサーバー203に対するマルチキャストとしてリンク207に送出する。ホスト206の接続されているリンク207とは異なるリンク(図示せず)にDHCPサーバー203がいる場合には、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を受け取ると、DHCP Reply Messageをホスト206に送る。
【００５９】
ステップS1004でDHCP Reply Messageを受け取ったホスト206は、それからサイトローカルアドレスもしくはグローバルアドレスを決めて、そのアドレスの中のインターフェイスIDが重複しているか否かを確認するために、DAD処理に必要な処理を行なう。つまり、ステップS803と同様に、インターフェイス301にマルチキャストアドレス等を設定する。これがステップS1005である。
【００６０】
次に、ステップS804と同様のNeighbor Solicitation Message をステップS1006で送り、Neighbor Advertisement Messageを受け取るかどうかをステップS1007で判断する。受け取った場合はそのアドレスが重複しているので、別のアドレスをDHCPサーバー203から受け取るためにステップS1003に戻り、同じ処理を繰り返す。
【００６１】
ホスト206は、図１０のステップS1007でNeighbor Advertisement Messageを受け取らなかった場合は、そのアドレスは重複していないので、DHCP Reply Messageから決めたサイトローカルアドレスもしくはグローバルアドレスをステップS1008でインターフェイス301に割当てる。
【００６２】
以上で図９のステップS906が終わる。ステップS904でRouter Advertisementを何も受け取らなかった場合はこれで正常終了する。
【００６３】
ステップS904でstateless address autoconfigurationとstateful address autoconfigurationの両方を指定するRouter Advertisementメッセージを受け取った場合は、ステップS905でstateless address autoconfigurationとstateful address autoconfigurationの両方を行なう。処理内容はステップS903とS906と同じである。
【００６４】
以上のようにして、イーサネット（Ｒ）207をインターフェイスとして持つホスト206はstateless address autoconfiguration とstateful addressautoconfiguration (DHCPv6)を任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、グローバルアドレス、default gateway等を自動設定することができる。
【００６５】
以上のプロトコルにおいて、インターフェイスIDにランダムな値を用いて、その値を対象にしてDADを行ない、リンク207における一意性を確認することにより、ゲートウェイ202あるいはDHCP サーバー203から得たグローバルアドレスのプレフィックスと組み合わせて使い捨ての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は、秘密の乱数s_i(1以上q以下)を生成し、v_i=g^(s_i) mod pを計算する。
【００７０】
s_caやs_iを秘密鍵、v_caやv_i(および公開のパラメータ)を公開鍵と呼び、秘密鍵は自分以外の誰にも知られないように管理する。
【００７１】
エンティティiは、匿名公開鍵証明書を利用開始する際に、自分のエンティティ名(ユーザ名)とパスワード、公開鍵v_iをエンティティCAに登録する。エンティティCAは、必要に応じてエンティティiの身元を物理的手段等で確認し、提示されたエンティティ名(ユーザ名)とパスワード、公開鍵v_iを記憶する。
【００７２】
匿名公開鍵証明書を発行する際、エンティティ CAは、乱数r(1以上q以下)を生成し、(g'、v_i')=(g^r mod p、 (v_i)^(r) mod p)を計算する。上述の公開のパラメータやこの匿名公開鍵証明書の有効期限、及び、公開鍵v_caに対する公開鍵証明書(後述)等の証明書の管理・属性情報をXとし、(g'、v_i')とXを含むメッセージ(のハッシュ値)に対してディジタル署名を生成する。離散対数問題に基づくディジタル署名方式、例えば、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))である。
【００７４】
匿名公開鍵証明書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を秘密鍵として離散対数問題に基づく公開鍵暗号やディジタル署名を利用できる。このように、匿名公開鍵証明書APC_ca(i)は、その管理・属性情報X中に有効期限を含み、匿名公開鍵証明書APC_ca(i)に含まれる公開鍵g'とv_i'は、同一のエンティティiの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【００７５】
匿名公開鍵証明書APC_ca(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)を用いて離散対数問題に基づく公開鍵暗号の暗号化やディジタル署名の検証を行なう。
【００７６】
なお、公開鍵v_caそのものの正当性の確認は、より上位もしくはより普及しているエンティティCA、例えば、商用の認証サービスを提供しているVeriSign等に公開鍵v_caを提出して、公開鍵v_caに対する公開鍵証明書を発行してもらえば、それを用いて確認できる。匿名公開鍵証明書の管理・属性情報をXは、公開鍵v_caに対する公開鍵証明書を含む。この公開鍵v_caに対する公開鍵証明書を用いて、公開鍵v_caそのものの正当性を確認することができる。これは、エンティティCAを階層的に構築することに相当し、順当なPKI(Public-key Infrastructure)を構成することができる。
【００７７】
なお、上記の説明では乗法群(mod p)上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能であり、その場合は乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。
【００７８】
以上の匿名公開鍵証明書方式を、図２の環境に適用する場合を説明する。
【００７９】
default gateway 202もしくはDHCPサーバー 203を、匿名公開鍵証明書を発行するエンティティCA、ホスト206(もしくはそれを利用するユーザ)が匿名公開鍵証明書を利用するエンティティiになる。あるいは、証明書発行のみを担う専用CAサーバーを設けることも可能である。以下では、default gateway 202を、匿名公開鍵証明書を発行するエンティティCAとし、ランダムなIPv6アドレスを証明書の中に含める例を説明するが、DHCPサーバーや専用CAサーバーを、匿名公開鍵証明書を発行するエンティティCAとすること、ランダムなIPv6アドレスを証明書に含めないことも可能である。ここでは、default gateway 202は、ホスト206に、IPv6のグローバルアドレスのプレフィックスを提供する。前述のように、default gateway 202は多くの場合ルーターなので、ルーター202と呼ぶことにする。
【００８０】
ルーター202の管理者は、上述の公開パラメータp、g等を定め、公開する。匿名公開鍵証明書を発行するエンティティCAとしての公開鍵v_caを定め、より上位もしくはより普及しているCA（図２の209）、例えば、商用の認証サービスを提供しているVeriSign等に提出して、公開鍵v_caに対する公開鍵証明書を発行してもらう。
【００８１】
ルーター(gateway)202は、パケットの転送を制御する役目を持ち、そのルーターの管轄するサブネットと外部との間で不適当なパケットが出入りしないように管理者の責任のもとで運用される。あるサブネットがインターネットに接続されるためにはそのサブネットの管理者は身元をJPNIC(日本の場合)に登録し、IPアドレスの割当てを受ける。従って、サブネットにおけるルーターは管理責任が明確であり、かつ安全面も考慮されたうえで運用や管理にコストがかけられると期待されるので、匿名公開鍵証明書を発行するエンティティCAの機能を担わせるのにふさわしいと考えられる。
【００８２】
ユーザ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、匿名公開鍵証明書を発行するCAをルーター202とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。すなわち、IPv6対応装置206が位置するローカルリンク207内に存在するIPv6対応装置202を公開鍵証明書発行者として運用する。
【００８４】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター202とエンティティ(この場合は、ホスト206)の間でなんらかの特定(認証)プロトコルを実行する。本実施の形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図１の流れに沿って動作を説明する。
【００８５】
ホスト206はステップS101でCertificate Solicitationを生成する。Certificate Solicitationは、匿名公開鍵証明書を要求するメッセージであり、匿名公開鍵証明書を要求する旨とホスト206のインターフェイスIDを含むデータであることをルーター202が理解できる形式で生成する。内容は、エンティティ名(ユーザ名)とパスワードとシリアル番号から計算される。シリアル番号は、例えば、ホスト206のIPv6リンクローカルアドレスとdefault gateway 202のIPv6リンクローカルアドレスとそのときの時刻の3つを連接して一つのデータにした値である。再送攻撃となりすましを防ぐために、秘密鍵s_iを用いて、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名(認証用signature) （Sig_i(hash(エンティティ名、パスワード、シリアル番号))）が、Certificate Solicitationに含まれる。
【００８６】
次に、ホスト206は、Certificate SolicitationをステップS102でリンク207を介してルーター202に送る。
【００８７】
ステップS103で、ルーター202はステップS102で受け取ったCertificate Solicitationに含まれるエンティティ名（通信装置（ホスト）206の識別子）から登録された公開鍵v_iをRAM 305もしくはHD306から検索し、それを用いて認証用signatureの正当性を確認する。具体的には、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数の入力とし、そのハッシュ値を求め、認証用signatureがそれに対する正しいディジタル署名であることを公開鍵v_iで確認する。
【００８８】
認証が成功したら、ルーター202に割当てられたIPv6のグローバルアドレスのプレフィックスとホスト206のインターフェイスID とからIPv6グローバルアドレスを生成し、そのライフタイム(使用期限、例えば24時間)等を含む匿名公開鍵証明書APC_ca(i)を作成する。具体的には、前述のAPC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))の中の証明書の管理・属性情報Xの中にIPv6グローバルアドレスやライフタイム等が含まれる。なお、IPv6グローバルアドレスのライフタイム(使用期限)と匿名公開鍵証明書の有効期限は同じとは限らない。
【００８９】
そして、ステップS104でルーター202はIPv6グローバルアドレスのプレフィックスとdefault router 202 のアドレスと匿名公開鍵証明書APC_ca(i)からなるCertificate Advertisementを、リンク207を介して、認証されたホスト206に送る。本発明のある形態では、このCertificate Advertisementを登録された公開鍵を用いて暗号化して、送信する。
【００９０】
ステップS105でホスト206は受け取ったCertificate Advertisementからプレフィックスを取り出し、インターフェイスIDを付加して、IPv6グローバルアドレスを生成するとともに、匿名公開鍵証明書APC_ca(i)の正当性を確認する。このように、匿名公開鍵証明書APC_ca(i)は、その管理・属性情報X中に有効期限を含み、匿名公開鍵証明書APC_ca(i)に含まれる公開鍵g'とv_i'は、同一のエンティティi（ホスト206）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。ホスト206は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１の匿名公開鍵発行プロトコルを実行し、使用する公開鍵g'とv_i'を変更する。
【００９１】
以上のプロトコルを既存のRouter SolicitationとRouter Advertisementの送受信プロトコルと組み合わせた拡張プロトコルのホストの動作フローチャートを図１１に示す。
【００９２】
ホスト206は、図１１のステップS1101において、図９のステップ901で送られるRouter Solicitation Messageと図１のステップS102で送られるCertificate Solicitationの両方を含むデータであるRouter Certificate Solicitation Messageを、リンク207を介して送る。
【００９３】
また、ステップS1102で、図９のステップS902で受け取るRouter Advertisement Messageと図１のステップS104で受け取るCertificate Advertisementの両方を含むデータであるRouter Certificate Advertisement Messageを受け取る。
【００９４】
Router Certificate Advertisement Messageを、リンク207を介して、受け取った場合、すなわち、ステップS1102で「はい」の場合、ホスト206は、ステップS1103では、図９のステップS903と同様に、Router Advertisement Message中のプレフィックスにインターフェイスIDを付加して作ったアドレスを、サイトローカルアドレスあるいはグローバルアドレスとして、インターフェイス301に割当てるとともに、図１におけるステップS105を行なって、公開鍵g'とv_i'を含む匿名公開鍵証明書APC_ca(i)を入手する。
【００９５】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なIPv6アドレスと対応する使い捨て匿名公開鍵証明書をホスト206に発行することができる。
【００９６】
なお、ルーター202の代りにDHCPサーバー203が匿名公開鍵証明書を発行するエンティティCAの役割を行なう場合は、図１１におけるステップS1106において図１と同様のプロトコルを実行する。ここでは、DHCPサーバー203が、ホスト206に、グローバルアドレスのプレフィックスを提供する。この場合には図１１のステップS1106で、ホストはstateful address autoconfigurationの拡張プロトコル、つまりDHCPサーバーからアドレスと証明書を取得するプロトコルを実行する。その動作フローチャートを図１２に示す。
【００９７】
図１０のプロトコルとの違いは、ステップS1203とステップS1204の二カ所である。
【００９８】
ステップS1203では、図１０のステップS1003で送るDHCP Request Message と図１のステップS102で送られるCertificate Solicitation相当のデータ(CAがルーター202ではなくDHCPサーバー203である点が異なる)の両方を含むデータであるDHCP Certificate Request Messageを、リンク207を介して送る。
【００９９】
このDHCP Certificate Request Messageを受け取ると、DHCPサーバー203は、DHCP Certificate Reply Messageを生成し、生成したDHCP Certificate Reply Messageを、リンク207を介して送る。ここで、DHCPサーバー203は、図１のS103のように、匿名公開鍵証明書APC_ca(i)を生成し、DHCPサーバー203のグローバルアドレスのプレフィックスとDHCPサーバー203のアドレスと匿名公開鍵証明書APC_ca(i)からなるCertificate Advertisement相当のデータと、図１のステップS1004のDHCP Reply MessageをDHCP Certificate Reply Messageに含める。
【０１００】
ホスト206は、ステップS1204で、DHCP Certificate Reply Message受け取る。このDHCP Certificate Reply Messageは、図１０のステップS1004で受け取るDHCP Reply Messageと図１のステップS104で受け取るCertificate Advertisement相当のデータ(CAがルーターではなくDHCPサーバーである点が異なる)の両方を含むデータである。したがって、DHCP Reply Messageからサイトローカルアドレスもしくはグローバルアドレスを決めるとともに、公開鍵g'とv_i'を含む匿名公開鍵証明書APC_ca(i)を入手する。
【０１０１】
以上のプロトコルにより、従来のプロトコルのステップ数を変えることなしにデータを増やすのみで使い捨て可能なIPv6アドレスと対応する使い捨て匿名公開鍵証明書をホスト206に発行することができる。
【０１０２】
ルーター202およびDHCPサーバー203の両方がCAの役割を行なう場合は、図１１におけるステップS1104で stateless と stateful の両方を指定するRouter Certificate Advertisement Messageを受け取った場合(「はい」の場合)に相当し、上記に示した二つの拡張プロトコルを任意の組み合わせで適用して、リンクローカルアドレス、サイトローカルアドレス、使い捨てIPv6グローバルアドレスとそれに対応する使い捨て匿名公開鍵証明書、default gateway等を自動設定および取得することができる。この場合、ルーター202及び DHCPサーバー203は、公開鍵証明書を提供する通信装置群に相当する。
【０１０３】
ホスト206は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１１の匿名公開鍵証明書を受け取るためのプロトコルを実行し、使用する公開鍵g'とv_i'を変更する。
【０１０４】
なお、DHCPサーバー203がIPv6アドレスのプレフィックスをホスト206に提供する形態を説明したが、IPv6アドレスそのものを提供する形態ではプレフィックスのかわりにアドレスが送られる点とホストがアドレスを生成する処理が不要になる点を除いて他は同じプロトコルで実現される。
【０１０５】
(第２の実施の形態)
第１の実施の形態では、default gateway(ルーター)兼CAがホストを認証してから匿名公開鍵証明書とプレフィックスを含む Certificate Advertisement をホストに送った。本実施の形態では、プレフィックスの送付と匿名公開鍵証明書の発行が独立な例を説明する。
【０１０６】
第１の実施の形態と同様に、default gateway 202もしくはDHCPサーバー 203を、匿名公開鍵証明書を発行するエンティティCAとし、ホスト206(もしくはそれを利用するユーザ)が匿名公開鍵証明書を利用するエンティティｉとする。あるいは、証明書発行のみを担う専用CAサーバーを設けることも可能である。以下では、default gateway 202を、匿名公開鍵証明書を発行するエンティティCAとし、ランダムなIPv6アドレスを証明書の中に含める例を説明するが、DHCPサーバーや専用CAサーバーを、匿名公開鍵証明書を発行するエンティティCAとすること、ランダムなIPv6アドレスを証明書に含めないことも可能である。ここでは、default gateway 202は、ホスト206に、IPv6のグローバルアドレスのプレフィックスを提供する。前述のように、default gateway 202は多くの場合ルーターなので、ルーター202と呼ぶことにする。
【０１０７】
ルーター202の管理者は、前述の公開パラメータp、g等を定め、公開する。匿名公開鍵証明書を発行するエンティティCAとしての公開鍵v_caを定め、より上位もしくはより普及しているCA（図２の209）、例えば、商用の認証サービスを提供しているVeriSign等に提出して、公開鍵v_caに対する公開鍵証明書を発行してもらう。
【０１０８】
ユーザ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端末でありかつ匿名公開鍵証明書を発行するCAをdefault gateway 202とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルの動作フローを表している。すなわち、IPv6対応装置206が位置するローカルリンク207内に存在するIPv6対応装置202を公開鍵証明書発行者として運用する。
【０１１０】
匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ルーター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 MessageFormat''等がそれらの形式を規定している。形式の詳細な説明は省くが、このCertificate Solicitationは、証明書要求メッセージと、それに対する(ホストの)署名からなるデータであるとする。
【０１１５】
次に、ホスト206は、Certificate Solicitationを、リンク207を介してルーター202に送る(ステップS1505)。なお、この時点でルーター202の(ユニキャスト)アドレスをホスト206は知っているので unicast することが可能である。
【０１１６】
ルーター202は、ステップS1505で受け取ったCertificate Solicitationに含まれるエンティティ名（ホスト206の識別子もしくはホスト206を利用するユーザの名前）から登録された公開鍵v_iをRAM 305もしくはHD306から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト206の匿名公開鍵証明書APC_ca(i)を作成する。具体的には、前述のAPC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))の中の証明書の管理・属性情報Xの中にIPv6グローバルアドレスやライフタイム等が含まれる(ステップS1506)。
【０１１７】
そして、ルーター202は匿名公開鍵証明書APC_ca(i)を含むCertificate Advertisementを、リンク207を介して、認証されたホスト206に送る(ステップS1507)。本発明のある形態では、このCertificate Advertisementを登録された公開鍵を用いて暗号化して、送信する。このとき、temporary address宛のunicastとして送ることが可能である。
【０１１８】
ホスト206は受け取ったCertificate Advertisementから匿名公開鍵証明書APC_ca(i)の正当性を確認する(ステップS1508)。
【０１１９】
以上のプロトコルを既存の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を受け取り、その中に含まれる匿名公開鍵証明書APC_ca(i)の正当性を確認する。
【０１２４】
なお、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と同じである。
【０１２６】
以上の説明では、default gateway202(ルーター)がCAを兼ねていたが、一般にはdefault gateway(ルーター)とCAが同一のIPv6装置とは限らない。Default gateway(ルーター)とCAが異なるIPv6装置の場合の動作フローを図１６に示す。
【０１２７】
CAの管理者は、前述の公開パラメータp、g等を定め、公開する。匿名公開鍵証明書を発行するエンティティCAとしての公開鍵v_caを定め、より上位もしくはより普及しているCA（図２の209）、例えば、商用の認証サービスを提供しているVeriSign等に提出して、公開鍵v_caに対する公開鍵証明書を発行してもらう。
【０１２８】
ユーザiがLANへのアクセスを申請する際に、公開されているパラメータp、g等を用いて、自分の秘密鍵s_iを生成し、対応する公開鍵v_iを計算して、ユーザ名とパスワード、公開鍵v_iをCAの管理者に提出する。CAの管理者は、その運用方針に応じてユーザiの身元確認やパスワードのチェック等を行ない、アクセスを許可する。管理者は、エンティティ名を元に対応する公開鍵v_iが検索できるように、RAM 304もしくはHD306に登録する。公開パラメータp、g等や公開鍵v_i、特に秘密鍵s_iはユーザiが管理し、ホスト206で安全に利用可能になっているものとする。
【０１２９】
なお、default gateway (ルーター)202の管理者とCAの管理者が同一であってもよいし、同一でなくてもよい。図１６は、default gateway 202(ルーター)とCAが別のIPv6装置であり、default gateway202にCAのIPv6アドレスが設定されているものとする。
【０１３０】
ホスト206は電源を入れられたあるいはリブートされた場合、ネットワーク・インターフェイス(図３の301)のMACアドレスからインターフェイスIDを生成する。また、ホスト206は、例えばRFC3041のアルゴリズムによってランダムなインターフェイスIDを生成する。前述のようにリンクローカルアドレスの生成等を行ない、Router Solicitation拡張(RS拡張) をrouterに送る(ステップS1601)。RS拡張は、CAのアドレスを要求する旨のメッセージをRouter Solicitationに追加した情報であり、前述のRAと同じくリンク上のルーター全て宛の multicast である。
【０１３１】
ルーター202は、RS拡張を受け取ったら、Router Advertisement拡張 (RA拡張)を送る(ステップS1602)。RA拡張は、CAのアドレスを Router Advertisementに追加した情報である。
【０１３２】
RA拡張を受け取ったホスト206は、RAに含まれるプレフィックスを抽出し、MACアドレスから生成したインターフェイスIDとプレフィックスとから、グローバルアドレス(public address)を生成する。また、ランダムなインターフェイスID とプレフィックスとから、使い捨てIPv6アドレス(temporary addressと呼ぶ)を作る。そして、public address とtemporary addressの重複検出DAD(Duplicate Address Detection)を行ない、リンクにおけるアドレスの一意性を確認し、インターフェイスにそれらのアドレスを割り当てる。また、RA拡張からCAのアドレスを抽出する(ステップS1603)。
【０１３３】
次に、ホスト206はCertificate Solicitationを生成し(ステップS1604)、Certificate SolicitationをCAに送る(ステップS1605)。
【０１３４】
CAはステップS1605で受け取ったCertificate Solicitationに含まれるエンティティ名（通信装置（ホスト）206の識別子）から登録された公開鍵v_iをRAM305もしくはHD306から検索し、それを用いて署名の正当性を確認する。確認が成功したら、ホスト206の匿名公開鍵証明書APC_ca(i)を作成する。具体的には、前述のAPC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))の中の証明書の管理・属性情報Xの中にIPv6グローバルアドレスやライフタイム等が含まれる(ステップS1606)。
【０１３５】
そして、CAは匿名公開鍵証明書APC_ca(i)を含むCertificate Advertisementを、ホスト206に送る(ステップS1607)。本発明のある形態では、このCertificate Advertisementを登録された公開鍵を用いて暗号化して、送信する。
【０１３６】
ホスト206は受け取ったCertificate Advertisementから匿名公開鍵証明書APC_ca(i)の正当性を確認する(ステップS1608)。
【０１３７】
以上のプロトコルを既存のstateless address autoconfigurationおよびstateful address autoconfigurationと組み合わせた拡張プロトコルのホストの動作フローチャートは、図１７とほぼ同様であるが、以下の２点が異なる。すなわち、ステップS1701で、Router Solicitation Messageの代わりに、Router Solicitation 拡張 Message を送る。また、ステップS1707で、証明書要求と証明書発行のプロトコルとして、図１６で示したプロトコルを実行する。
【０１３８】
（第３の実施の形態）
本実施の形態では、ホストがダイヤルアップあるいはADSLのような方式でインターネットと接続する形態を説明する。最初に現状を説明し、その後に本発明の実施の形態を説明する。
【０１３９】
図１４は、本発明が適用される接続環境を模式的に示したものである。図１４は、ホスト1406がPSTN(Public Switched Telephone Network)経由でISP(Internet Service Provider)の提供するインターネット1401とアクセスする環境を示す。本実施の形態では、ISPとホスト1401はPPPリンクで接続するものとする。
【０１４０】
図１４において、ISPのPPP peer 1402はノードであり、modem 1403を用いてPSTN 1404を介してホスト1406からのPPP接続の要求を受け付ける。ホスト1406はmodem 1405を用いてPPP peer 1402にPPP接続でアクセスする。ホスト1406の構成は、図３と同様であり、ネットワーク・インターフェイス301を介して、モデム1405を接続する。また、PPP peer 1402の構成も、図３と同様であり、ネットワーク・インターフェイス301を介して、モデム1403を接続し、ネットワーク・インターフェイス302を介して、インターネット1401と接続する。PPP peer 1402は、図１４に示すように、 default gateway module 14021、DHCP module 14022、Authentication module 14023として、機能する。ホスト1406とPPP peer 1402が通信する場合、ホスト1406は、モデム1405を介して、通信を行ない、PPP peer 1402は、モデム1403を介して、通信を行なう。
【０１４１】
本実施の形態では、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の管理者の管理下で安全に運用されていれば構わないので、以下では、図１４の形態でホスト1406とPPP peer 1402の間のPPPリンクが確立したものとして説明する。
【０１４５】
ホスト1406は、DHCP module 14022からIPv6グローバルアドレスのプレフィックスやdefault gatewayのIPv6アドレス等を受け取ったならば、IPv6グローバルアドレスのプレフィックスと自分の(RFC3041等の方法で生成した)ランダムなインターフェイスIDとを組み合わせて、ランダムなIPv6グローバルアドレスを生成し、それがリンクにおいて重複していないことを確認してから、それをインターフェイス301に割当て、default gateway のIPv6アドレスを記憶する。
【０１４６】
以上の動作により、ホスト1406は使い捨てIPv6アドレスを使ってインターネットの任意の相手と通信できる。
【０１４７】
次に、本発明の実施の形態を説明する。上述した動作(プロトコル)を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。
【０１４８】
以下では、匿名公開鍵証明書方式を、図１４の環境に適用する場合を説明する。PPP peer 1402が匿名公開鍵証明書を発行するCA、ホスト1406(もしくはそれを利用するユーザ)が匿名公開鍵証明書を利用するエンティティiになる。以下では、ランダムなIPv6アドレスを証明書の中に含める形態を説明するが、ランダムなIPv6アドレスを含めないことも可能である。
【０１４９】
ISPは、前述の公開パラメータp、g等を定め、公開する。自分の公開鍵v_caを定め、より上位もしくはより普及しているCA（図１４の1408）、例えば、商用の認証サービスを提供しているVeriSign等に提出して、v_caに対する公開鍵証明書を発行してもらう。
【０１５０】
ユーザiがISPに加入を申請する際に、ISPが公開しているパラメータ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をPPP peer 1402とし、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。
【０１５２】
PPP接続におけるデータリンク層の処理が終わった後、前述のように、ホスト1406からのPPP接続の要求を受けたPPP peer 1402は、Authentication module 14023で、ユーザ名（識別子）とパスワードに基づき、認証プロトコルCHAPによるホストの認証を行なう。
【０１５３】
すなわち、ホスト1406はステップS1301でエンティティ名(ユーザ名)をPPP peer1402に送る。ステップS1302でPPP peer 1402はCHAP-challengeを生成し、ステップS1303でそれをホスト1406に送る。
【０１５４】
ホスト1406はステップ S1304でエンティティ名とパスワードとCHAP-challengeをハッシュ関数に入力してCHAP-responseを求め、求めた結果のCHAP-responseの値をステップS1305でPPP peer 1402に送る。
【０１５５】
ステップS1306でPPP peer 1402は、CHAP-responseの正当性を確認する。確認出来たならば認証は成功なので、その認証されたホスト1406に対してIPv6グローバルアドレスのプレフィックスやdefault gateway のアドレスをステップS1307で伝える。
【０１５６】
ホスト1406は、ステップS1308でIPv6グローバルアドレスのプレフィックスとランダムなインターフェイスIDとからIPv6グローバルアドレスを生成し、それが重複していないことを確認してから、それをネットワーク・インターフェイス301に割当て、default gatewayのアドレスも記憶する。次に匿名公開鍵証明書を要求するメッセージとしてCertificate Solicitation をステップS1309でPPP peer
1402に送る。
【０１５７】
Certificate Solicitation は、第１の実施の形態と同様に、匿名公開鍵証明書を要求する旨とインターフェイスIDを含むデータであることをPPP peer 1402が理解できる形式で生成される。内容は、エンティティ名(ユーザ名)とパスワードとシリアル番号から計算され、シリアル番号は、例えば、ホスト206のIPv6リンクローカルアドレスとdefault gatewayのIPv6リンクローカルアドレスとそのときの時刻の3つを連接して一つのデータにした値である。Certificate Solicitationには、エンティティ名(ユーザ名)とパスワードとシリアル番号をハッシュ関数に入力した値に対して生成したディジタル署名(認証用signature)が含まれる。
【０１５８】
PPP peer 1402は、エンティティ名(通信装置（ホスト）206のユーザ名)に対応する登録された公開鍵v_iをRAM 305もしくはHD306から検索し、前述の図１のS103で説明した匿名公開鍵証明書の生成をステップS1310で実行する。すなわち、PPP peer 1402に割当てられたIPv6のグローバルアドレスのプレフィックスとホスト1406のインターフェイスID とからIPv6グローバルアドレスを生成し、そのライフタイム等を含む匿名公開鍵証明書APC_ca(i)を作成する。具体的には、前述のAPC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))の中の証明書の管理・属性情報Xの中にIPv6グローバルアドレスやライフタイム等が含まれる。
【０１５９】
そして、図１のS104と同様に、生成された匿名公開鍵証明書APC_ca(i)等を含むCertificate Advertisementをホスト1406に対してステップS1311で送る。ホスト1406は受け取った匿名公開鍵証明書APC_ca(i)の正当性をステップS1312で確認する。このように、匿名公開鍵証明書APC_ca(i)は、その管理・属性情報X中に有効期限を含み、匿名公開鍵証明書APC_ca(i)に含まれる公開鍵g'とv_i'は、同一のエンティティi（ホスト1406）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１６０】
以上のプロトコルにおいて、ステップS1305とS1309で送受されるデータを一つにまとめてステップS1305で送ることも可能である。図示しないが、その場合、ホスト1406はランダムなインターフェイスIDと図１３のステップS1305のCHAP-responceとステップS1309の Certificate Solicitation (第１の実施の形態と同様)をステップS1305'でPPP peer1402に送る。
【０１６１】
そして、ステップS1306'で、PPP peer 1402は、CHAP-responseの正当性を確認し、登録された公開鍵v_iを検索し、IPv6プレフィックスとインターフェイスIDとからIPv6グローバルアドレスを生成し、それとそのライフタイム(使用期限、例えば24時間等)等を含めたデータを生成し、匿名公開鍵証明書APC_ca(i)を生成する。生成された匿名公開鍵証明書APC_ca(i)を含むCertificate Advertisementをホスト1406に対してステップS1307'で送る。
【０１６２】
ホスト1406は受け取った匿名公開鍵証明書APC_ca(i)の正当性をステップS1308'で確認する。このステップS1308'で図１３のステップS1312に相当する処理まで終了するので、これ以降のステップは存在しない。
【０１６３】
以上のプロトコルで、PPP peer 1402は、ホスト1406に、使い捨て可能なIPv6アドレスと対応する使い捨て匿名公開鍵証明書を発行する。
【０１６４】
ホスト1406は、通信相手が変る度に、あるいは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図１３の匿名公開鍵証明書発行プロトコルを実行し、使用する公開鍵g'とv_i'を変更する。
【０１６５】
なお、以上の説明ではPPP Peer 1402がIPv6プレフィックスをhost1406に伝え、host1406がIPv6プレフィックスとインターフェイスIDからIPv6アドレスを生成する場合を述べたが、PPP Peer 1402がIPv6アドレスをhost1406に伝え、host1406がそれを使う場合も同様のプロトコルで実現される．その場合、図３のステップ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を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、ゲートウェイ202を介して、ユーザであるホスト206に接続され、図１４の形態では、インターネット1401、PPP peer 1402を介して、ユーザであるホスト1406に接続される。ホスト206、1406は、この買い物サイトなどのサイトを通信相手とする通信を開始する前に、上述したプロトコルで、Ipv6アドレス、及び、公開鍵を含む公開鍵証明書を得ておく。この形態において、上述した公開鍵証明書に基づき鍵交換・更新・変更プロトコルを実行して暗号・認証通信を行なう手順を行なう。
【０１７２】
このとき、ユーザは買い物サイトのIPv6アドレス（識別子）を(明示的か非明示的かは問わないが)知っている。実際にアクセスして、そこがユーザにとって正しいサイトであるときに、通信相手のIPv6アドレスを確認することでユーザは明示的にアドレスを知ることができる。通信している最中には、買い物サイトも通信相手のアドレス（識別子）はわかる。以上の通信は使い捨てIPv6アドレスで行なえる。
【０１７３】
本形態では、送受信者が確定した時点で、使い捨てIPv6アドレスは(更新せず)、同一のアドレスを使うこととする。この時点で、使い捨て匿名公開鍵証明書APC_ca(i) =(g'、v_i'、X、Sig_ca(g'、v_i'、X))をお互いに送り合う。すると、使い捨て匿名公開鍵証明書APC_ca(i)中の管理・属性情報Xには、IPv6グローバルアドレスが含まれているので、そのIPv6アドレスが実際に通信している相手のIPv6アドレスと一致するか否かを確認し、かつ使い捨て匿名公開鍵証明書の正当性を確認すれば、それが本当に通信相手の使い捨て匿名公開鍵証明書か否かを判断でき、その中に含まれる公開鍵(g'、v_i')が本当に通信相手の公開鍵か否かを確認できる。
【０１７４】
使い捨て匿名公開鍵証明書の正当性は、次のように確認できる。証明書の管理・属性情報XにはCA(前述のルーター202やDHCPサーバー203、又は、PPP peer 1402)の公開鍵v_caとそれに対する公開鍵証明書(商用の認証サービスを提供しているVeriSign等が発行した証明書)が含まれている。サイトは、それらの対応関係が正しいか否かを、商用の認証サービスを提供しているVeriSign等の公開鍵(広く知られているので容易に入手できる)を用いて確認できる。正当性が確認できたv_caを用いて、使い捨て匿名公開鍵証明書APC_ca(i)=(g'、v_i'、X、Sig_ca(g'、v_i'、X))の正当性、すなわち、(g'、v_i')とSig_ca(g'、v_i'、X)の対応関係の正しさを確認できる。匿名公開鍵証明書APC_ca(i)は、その管理・属性情報X中に有効期限を含み、匿名公開鍵証明書APC_ca(i)に含まれる公開鍵g'とv_i'は、同一のエンティティiの公開鍵であるが、時間の経過に伴い変更される公開鍵である。
【０１７５】
ホスト206、1406は、通信相手が変る度に（すなわち、新たに、サイトに接続する度に）、若しくは、セッションが変る毎に、図１１、図１３のプロトコルを実行し、使用するIPv6アドレス及び公開鍵g'とv_i'を更新・変更する。なお、公開鍵g'とv_i'は、通信パケットの送信毎に、更新・変更してもよい。
【０１７６】
以上により、使い捨てIPv6アドレスとそれを含む使い捨て匿名公開鍵証明書を用いて、IPv6アドレスで定義される通信相手の公開鍵を確実に入手できる。このようにして交換した公開鍵を用いて前述のIKE の phase 1 の Main mode を行なうことにより、そのIPv6アドレスを持つ通信相手とのIPsec通信が実行できる。
【０１７７】
すなわち、本形態では、IPv6対応装置が位置するローカルリンク内に存在するIPv6対応装置を公開鍵証明書発行者として運用し、使い捨て匿名公開鍵証明書の中にIPv6アドレスを含めて、インターネット上の2つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであるIPsec通信、及び、IPsecに際して、秘密データやお互いのIPv6アドレス等のSA(Security Association)を安全に共有するプロトコルであるIKE(Internet Key Exchange)を行なう。
【０１７８】
従って、課題で述べたような通信相手のなりすましは防がれる。
【０１７９】
【発明の効果】
以上説明したように、本出願に関わる発明によれば、使い捨て匿名公開鍵証明書を必要とするＩＰｖ６対応装置に対して、匿名公開鍵証明書を効率的に確実に発行することができ、ＩＰｖ６対応装置は、公開鍵証明書提供装置から受け取った匿名公開鍵証明書を、使い捨て匿名公開鍵証明書として、使い捨てることが可能になる。
さらに、匿名公開鍵証明書の正当性の確認に用いられるディジタル署名を確認するための公開鍵の正当性も、確認することができる。
【０１８０】
また、匿名公開鍵を生成するためのホストが計算する負荷を軽減することができる。
【０１８１】
さらに、プライバシ保護の程度が高く、低コストで実現可能であり、実行時の負荷が小さい使い捨て匿名公開鍵証明書を効率的に実現可能である。
【０１８２】
また、強力なプライバシ保護を実現し、かつなりすましを防ぎながらIKEによるIPsec通信を行なうことができる。
【図面の簡単な説明】
【図１】第１の実施の形態における匿名公開鍵証明書発行プロトコル(イーサネット（Ｒ）LANの場合)の図である。
【図２】イーサネット（Ｒ）LANの模式図である。
【図３】ノードの構成図である。
【図４】イーサネット（Ｒ）のMACアドレスの構成図である。
【図５】インターフェイスIDの構成図である。
【図６】 a tentative link-local addressの構成図である。
【図７】あるtentative link-local addressのsolicited-node multicast addressの構成図である。
【図８】ホストがDADを終えるまでの動作を説明するフローチャート図である。
【図９】ホストがアドレス自動設定を終えるまでの動作を説明するフローチャート図である。
【図１０】ホストがDHCPでアドレスを取得するまでの動作フローチャート図である。
【図１１】ホストがアドレス自動設定を行ない、匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１２】ホストがDHCPでアドレスと匿名公開鍵証明書を受け取るまでの動作フローチャート図である。
【図１３】第３の実施の形態における匿名公開鍵証明書発行プロトコル(PPPの場合)の図である。
【図１４】ダイヤルアップ／ADSL接続の模式図である。
【図１５】第２の実施の形態における匿名公開鍵証明書発行プロトコル(イーサネット（Ｒ）LANの場合)の図である。
【図１６】匿名公開鍵証明書発行プロトコルの一般形の図である。
【図１７】ホストが証明書を取得するまでの動作フローチャート図である。
【符号の説明】
300 ノード
301 ネットワーク・インターフェイス
302 ネットワーク・インターフェイス
306 HD(ハードディスク)
308 キーボード/ポインティングデバイスのインターフェイス
309 モニターのインターフェイス
1402 ISPのPPP peer
1404 PSTN (Public Switched Telephone Network)
Claims (12)
- 第二の公開鍵の証明書、及び、第二の秘密鍵を有する公開鍵証明書提供装置であって、
第一の公開鍵、ディジタル署名、及び、前記第一の公開鍵の匿名公開鍵証明書を生成する生成手段と、
前記生成手段により生成された第一の公開鍵の匿名公開鍵証明書をＩＰｖ６対応装置に提供する提供手段とを有し、
前記生成手段により生成される第一の公開鍵は、第一の秘密鍵を有する前記ＩＰｖ６対応装置が前記第一の公開鍵を前記第一の秘密鍵と共に利用できるように生成され、
前記生成手段により生成されるディジタル署名は、前記第二の公開鍵を用いて正当性が確認できるように、前記第二の秘密鍵を用いて生成され、
前記生成手段により生成される第一の公開鍵の匿名公開鍵証明書は、前記第二の公開鍵の証明書、及び、前記ディジタル署名を含み、
前記第二の公開鍵の証明書は、認証サービス提供者により発行された証明書であることを特徴とする公開鍵証明書提供装置。 - 請求項１の公開鍵証明書提供装置において、前記生成手段により生成される第一の公開鍵の匿名公開鍵証明書は、ＩＰｖ６アドレスをさらに含むことを特徴とする公開鍵証明書提供装置。
- 請求項１の公開鍵証明書提供装置において、前記提供手段は、サブネット内のＩＰｖ６対応装置に、前記第一の公開鍵の匿名公開鍵証明書を提供することを特徴とする公開鍵証明書提供装置。
- 請求項１の公開鍵証明書提供装置において、前記提供手段は、前記ＩＰｖ６対応装置に、前記第一の公開鍵の匿名公開鍵証明書、及び、前記ＩＰｖ６対応装置のアドレスを決定するための情報を提供することを特徴とする公開鍵証明書提供装置。
- 請求項１の公開鍵証明書提供装置において、前記提供手段により第一の公開鍵の匿名公開鍵証明書が提供される前記ＩＰｖ６対応装置を、インターネットに接続する接続手段を、更に有することを特徴とする公開鍵証明書提供装置。
- 第二の公開鍵の証明書、及び、第二の秘密鍵を有する公開鍵証明書提供装置からＩＰｖ６対応装置に第一の公開鍵の匿名公開鍵証明書を提供する公開鍵証明書提供方法であって、
前記第一の公開鍵、ディジタル署名、及び、前記第一の匿名公開鍵公開鍵の証明書を生成し、
生成された第一の公開鍵の匿名公開鍵証明書を前記ＩＰｖ６対応装置に提供し、
前記生成ステップで生成される第一の公開鍵は、第一の秘密鍵を有する前記ＩＰｖ６対応装置が前記第一の公開鍵を前記第一の秘密鍵と共に利用できるように生成され、
前記生成ステップで生成されるディジタル署名は、前記第二の公開鍵を用いて正当性が確認できるように、前記第二の秘密鍵を用いて生成され、
前記生成ステップで生成される第一の公開鍵の匿名公開鍵証明書は、前記第二の公開鍵の証明書、及び、前記ディジタル署名を含み、
前記第二の公開鍵の証明書は、認証サービス提供者により発行された証明書であることを特徴とする公開鍵証明書提供方法。 - 請求項６の公開鍵証明書提供方法において、前記生成ステップで生成される第一の公開鍵の匿名公開鍵証明書は、ＩＰｖ６アドレスをさらに含むことを特徴とする公開鍵証明書提供方法。
- 請求項６の公開鍵証明書提供方法において、前記提供ステップは、サブネット内のＩＰｖ６対応装置に、前記第一の公開鍵の匿名公開鍵証明書を提供することを特徴とする公開鍵証明書提供方法。
- 請求項６の公開鍵証明書提供方法において、前記提供ステップは、前記ＩＰｖ６対応装置に、前記第一の公開鍵の匿名公開鍵証明書、及び、前記ＩＰｖ６対応装置のアドレスを決定するための情報を提供することを特徴とする公開鍵証明書提供方法。
- 請求項６の公開鍵証明書提供方法において、前記提供ステップにより第一の公開鍵の匿名公開鍵証明書が提供されるＩＰｖ６対応装置を、インターネットに接続する接続ステップを、更に有することを特徴とする公開鍵証明書提供方法。
- アドレスを決めるための情報、及び、第一の公開鍵の匿名公開鍵証明書を、サブネット内のＩＰｖ６対応装置に提供する提供手段を、サブネット内に設け、第二の公開鍵の証明書、及び、第二の秘密鍵を有する公開鍵証明書提供装置であって、
第一の公開鍵、ディジタル署名、及び、前記第一の公開鍵の匿名公開鍵証明書を生成する生成手段を、更に有し、
前記生成手段により生成された第一の公開鍵は、第一の秘密鍵を有する前記ＩＰｖ６対応装置が前記第一の公開鍵を前記第一の秘密鍵と共に利用できるように生成され、
前記生成手段により生成されるディジタル署名は、前記第二の公開鍵を用いて正当性が確認できるように、前記第二の秘密鍵を用いて生成され、
前記生成手段により生成される第一の公開鍵の匿名公開鍵証明書は、前記第二の公開鍵の証明書、及び、前記ディジタル署名を含み、
前記第二の公開鍵の証明書は、認証サービス提供者により発行された証明書であることを特徴とする公開鍵証明書提供装置。 - 第二の公開鍵の証明書、及び、第二の秘密鍵を有する接続装置であって、
インターネットを接続するインターネット接続手段、
ＩＰｖ６対応装置と接続するＩＰｖ６対応装置接続手段と、
第一の公開鍵、ディジタル署名、及び、前記第一の公開鍵の匿名公開鍵証明書を生成する生成手段と、
前記第一の公開鍵の証明書を前記ＩＰｖ６対応装置に提供する提供手段とを有し、
前記生成手段により生成された第一の公開鍵は、第一の秘密鍵を有する前記ＩＰｖ６対応装置が前記第一の公開鍵を前記第一の秘密鍵と共に利用できるように生成され、
前記生成手段により生成されるディジタル署名は、前記第二の公開鍵を用いて正当性が確認できるように、前記第二の秘密鍵を用いて生成され、
前記提供手段により提供される第一の公開鍵の匿名公開鍵証明書は、前記第二の公開鍵の証明書、及び、前記ディジタル署名を含み、
前記第二の公開鍵の証明書は、認証サービス提供者により発行された証明書であることを特徴とする接続装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003085335A JP3782788B2 (ja) | 2002-04-17 | 2003-03-26 | 公開鍵証明書提供装置、方法、及び、接続装置 |
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002115095 | 2002-04-17 | ||
| JP2003085335A JP3782788B2 (ja) | 2002-04-17 | 2003-03-26 | 公開鍵証明書提供装置、方法、及び、接続装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004007512A JP2004007512A (ja) | 2004-01-08 |
| JP3782788B2 true JP3782788B2 (ja) | 2006-06-07 |
Family
ID=30447117
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003085335A Expired - Fee Related JP3782788B2 (ja) | 2002-04-17 | 2003-03-26 | 公開鍵証明書提供装置、方法、及び、接続装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3782788B2 (ja) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR100803272B1 (ko) | 2004-01-29 | 2008-02-13 | 삼성전자주식회사 | 아이피 브이 식스 네트워크에서 인증을 처리하는 방법 및그 장치 |
| JP4654613B2 (ja) * | 2004-06-17 | 2011-03-23 | 株式会社日立製作所 | 通信システム、通信方法、アドレス配布システム、アドレス配布方法、通信端末 |
| JP4879524B2 (ja) * | 2005-06-30 | 2012-02-22 | ブラザー工業株式会社 | 通信装置、通信システム及びプログラム |
| JP4148246B2 (ja) | 2005-06-30 | 2008-09-10 | ブラザー工業株式会社 | 通信システム、証明書更新装置、証明書更新プログラム、通信装置及び代替更新プログラム |
| JP2007189620A (ja) * | 2006-01-16 | 2007-07-26 | Kddi Corp | Ｉｐアドレス管理サーバ、利用者端末、およびプログラム |
| JP4890867B2 (ja) | 2006-01-17 | 2012-03-07 | キヤノン株式会社 | 情報処理装置およびその制御方法 |
| JP4410791B2 (ja) | 2006-12-20 | 2010-02-03 | 富士通株式会社 | アドレス詐称チェック装置およびネットワークシステム |
| JP4128610B1 (ja) | 2007-10-05 | 2008-07-30 | グローバルサイン株式会社 | サーバ証明書発行システム |
| JP2009038512A (ja) * | 2007-07-31 | 2009-02-19 | Panasonic Corp | 暗号化情報通信装置、暗号化情報通信システム、暗号化情報通信方法及びプログラム |
| JP2011130251A (ja) * | 2009-12-18 | 2011-06-30 | Of Networks:Kk | Ｇｅｐｏｎシステム及び新規加入者側端末の通信設定方法 |
| JP5120431B2 (ja) * | 2010-09-15 | 2013-01-16 | 株式会社日立製作所 | 通信システム、通信方法、アドレス配布システム、アドレス配布方法、通信端末 |
| US10447665B2 (en) * | 2017-03-31 | 2019-10-15 | Konica Minolta Laboratory U.S.A., Inc. | IPv6 link local secure network with biometric security to secure IOT devices |
-
2003
- 2003-03-26 JP JP2003085335A patent/JP3782788B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004007512A (ja) | 2004-01-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP1361694B1 (en) | Public key certification issuing apparatus | |
| EP1355447B1 (en) | Public key certification providing apparatus | |
| JP4033868B2 (ja) | ＩＰｖ６ネットワークで認証を処理する方法及びその装置 | |
| US7590843B1 (en) | Key exchange for a network architecture | |
| US20040240669A1 (en) | Securing neighbor discovery using address based keys | |
| JP4006403B2 (ja) | ディジタル署名発行装置 | |
| JP2009503916A (ja) | マルチ鍵暗号化生成アドレス | |
| WO2007005101A2 (en) | System and method for establishing a shared key between network peers | |
| JP3782788B2 (ja) | 公開鍵証明書提供装置、方法、及び、接続装置 | |
| CN110392128B (zh) | 提供准无地址IPv6公开万维网服务的方法及系统 | |
| WO2009082950A1 (fr) | Procédé, dispositif et système de distribution de clés | |
| Lee et al. | Mobile IP and WLAN with AAA authentication protocol using identity-based cryptography | |
| JP4280536B2 (ja) | 公開鍵生成装置、方法、及び、公開鍵証明書発行方法 | |
| EP3340530B1 (en) | Transport layer security (tls) based method to generate and use a unique persistent node identity, and corresponding client and server | |
| Shete et al. | DHCP protocol using OTP based two-factor authentication | |
| CN115580498B (zh) | 融合网络中的跨网通信方法及融合网络系统 | |
| JP4208868B2 (ja) | 公開鍵証明書発行方法 | |
| JP2007166552A (ja) | 通信装置及び暗号通信方法 | |
| EP2210397A1 (en) | Simplified protocol for carrying authentication for network access | |
| JP2005191646A (ja) | 遮断装置、匿名公開鍵証明書発行装置、システム、および、プログラム | |
| Fathi et al. | Protocols for purpose-restricted anonymous communications in IP-based wireless networks | |
| Yaacob et al. | IKE authentication using certificateless signature | |
| Sarma | Securing IPv6’s neighbour and router discovery using locally authentication process | |
| Oishi et al. | Anonymous IPsec with Plug and Play: a prototype of IPsec with IKE using IPv6 temporary addresses and anonymous public-key certificates | |
| KR100738353B1 (ko) | 홈 네트워크 보안성 최적화 장치 및 그 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20050621 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20050811 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060307 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060310 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100317 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100317 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110317 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120317 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130317 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140317 Year of fee payment: 8 |
|
| LAPS | Cancellation because of no payment of annual fees |