(57)【要約】【課題】  xビット(xは64未満)の subnet prefix がユーザに割り当てられる場合に、装置に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。【解決手段】  ホスト210から匿名アドレスを含む証明書要求パケットがCA201に送られる際に、遮断装置204が、同一の送信元アドレスを持つ異なる証明書要求パケットを遮断する。また、証明書を含むパケットがCA201からホスト210に送られる際に、遮断装置204が、同一の宛先アドレスを持つ異なる証明書パケット、および、以前に受信されていないアドレスを宛先とする証明書パケットを遮断する。【選択図】  図２
2005191646.tif 000002
【特許請求の範囲】
【請求項１】
パケットを受信する受信手段と、同一の送信元アドレスあるいは同一の宛先アドレスを持つ異なるパケットを遮断する遮断手段とを有することを特徴とする遮断装置。
【請求項２】
遮断装置と、公開鍵証明書発行装置を有するシステムであって、
匿名アドレスを使用する装置から匿名アドレスを含む証明書要求パケットが前記公開鍵証明書発行装置に送られる際に、前記遮断装置が、前記証明書要求パケットの送信元アドレスを監視して、同一の送信元アドレスを持つ異なる証明書要求パケットを遮断し、前記公開鍵証明書発行装置が、前記証明書要求パケットに含まれる匿名アドレスと前記証明書要求パケットの送信元アドレスが一致していることを確認して匿名アドレス宛に証明書を発行することを特徴とする匿名性を持つ公開鍵証明書を発行するシステム。
【請求項３】
パケットを受信する受信手段と、匿名アドレスを使用する装置から匿名アドレスを含む証明書要求パケットが公開鍵証明書発行装置に送られる際に、同一の送信元アドレスを持つ異なる証明書要求パケットを遮断する遮断手段とを有することを特徴とする匿名性を持つ公開鍵証明書を発行する遮断装置。
【請求項４】
遮断装置と、公開鍵証明書発行装置を有するシステムであって、
証明書を含むパケットが前記公開鍵証明書発行装置から匿名アドレスを使用する装置に送られる際に、前記遮断装置が、前記パケットの宛先アドレスを監視して、同一の宛先アドレスを持つ異なる証明書パケットを遮断することを特徴とする匿名性を持つ公開鍵証明書を発行するシステム。
【請求項５】
遮断装置と、公開鍵証明書発行装置を有するシステムであって、
証明書を含むパケットが前記公開鍵証明書発行装置から匿名アドレスを使用する装置に送られる際に、前記遮断装置が、以前に受信されていないアドレスを宛先とする証明書パケットを遮断することを特徴とする匿名性を持つ公開鍵証明書を発行するシステム。
【請求項６】
パケットを受信する受信手段と、証明書を含むパケットが公開鍵証明書発行装置から匿名アドレスを使用する装置に送られる際に、同一の宛先アドレスを持つ異なる証明書パケットを遮断する遮断手段とを有することを特徴とする遮断装置。
【請求項７】
パケットを受信する受信手段と、証明書を含むパケットが公開鍵証明書発行装置から匿名アドレスを使用するＩＰｖ６装置に送られる際に、以前に受信されていないアドレスを宛先とする証明書パケットを遮断する遮断手段とを有することを特徴とする遮断装置。
【請求項８】
公開鍵証明書を要求する装置と公開鍵証明書発行装置の間でＩＫＥを実行してＩＰｓｅｃ通信を確立し、匿名公開鍵証明書発行プロトコルを実行する際に、ＩＫＥのＩＤ  ｐｒｏｔｅｃｔｉｏｎ機能と公開鍵証明書を用いて通信相手の確認を行うこと、ＩＫＥを実行する際に公開鍵証明書を要求する装置の匿名アドレスを使用すること、公開鍵証明書発行装置はＩＫＥのパケットの送信元アドレスと証明書要求パケットに含まれる匿名アドレスが一致することを確認することを特徴とする匿名性を持つ公開鍵証明書を発行するシステム。
【請求項９】
通信相手との間でＩＫＥを実行してＩＰｓｅｃ通信を確立する確立手段と、匿名公開鍵証明書発行プロトコルを実行する際に、ＩＫＥのＩＤ  ｐｒｏｔｅｃｔｉｏｎ機能と公開鍵証明書を用いて通信相手を確認し、ＩＫＥのパケットの送信元アドレスと証明書要求パケットに含まれる匿名アドレスが一致することを確認する確認手段とを有することを特徴とする匿名性を持つ公開鍵証明書を発行する公開鍵証明書発行装置。
【請求項１０】
遮断装置と、公開鍵証明書発行装置を有するシステムであって、
前記遮断装置と前記公開鍵証明書発行装置の間でＩＰｓｅｃ通信が行われ、匿名アドレスを使用する装置から匿名アドレスを含む証明書要求パケットが前記公開鍵証明書発行装置に送られる際に、前記遮断装置が、前記パケットの送信元アドレスを監視して同一の送信元アドレスを持つ異なる証明書要求パケットを遮断し、前記公開鍵証明書発行装置が、前記証明書要求パケットに含まれる匿名アドレスと前記証明書要求パケットの送信元アドレスが一致していることを確認して匿名アドレス宛に証明書を発行することを特徴とする匿名性を持つ公開鍵証明書を発行するシステム。
【請求項１１】
公開鍵証明書発行装置との間でＩＰｓｅｃ通信を行うＩＰｓｅｃ通信手段と、匿名アドレスを使用する装置から匿名アドレスを含む証明書要求パケットが前記公開鍵証明書発行装置に送られる際に、前記パケットの送信元アドレスを監視して同一の送信元アドレスを持つ異なる証明書要求パケットを遮断する遮断手段とを有することを特徴とする遮断装置。
【請求項１２】
コンピュータを、請求項１、３、６、７、１１のいずれか１項の遮断装置、または、請求項９の公開価値証明書発行装置として動作させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、遮断装置、および、匿名公開鍵証明書発行システムに関するものである。
【背景技術】
【０００２】
IPv6に対応する装置とネットワークとのリンクには通常はイーサネット（登録商標）が用いられ、リンクには subnet prefix が割り当てられ、装置にはIPv6アドレスが割り当てられる。イーサネット（登録商標）が持つ IEEE identifier (MAC address)を元にしてインターフェイスIDが生成され、subnet prefixとインターフェイスIDを連接したものがIPv6アドレスになる。この方法によって生成されたアドレスをIEEE EUI-64形式のIPv6アドレスと呼ぶ。subnet prefixは、通常はそのリンクの default gateway がリンクに送出するRouter Advertisement (RA)に含まれる。
【０００３】
なお、gatewayは異なるネットワークを接続する装置であり、あるネットワークにおける default gateway とはそのネットワークにおけるパケットのデフォルトの宛先として指定される gateway である。default gateway を単にルーターと呼ぶことも多い。
【０００４】
IPv6アドレスの詳細や構成方法などのアドレス体系は、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アドレスは、temporary addressあるいは匿名アドレスと呼ばれる。
【０００８】
装置が匿名アドレスを使う場合に、IPsecを用いて暗号通信を行うことを考える。IPsecは、インターネット上の２つの装置が他のだれも知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行うプロトコルであり、通信に際して秘密データやお互いの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対応装置と表す)に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は、特許文献１や特許文献２に記載されている。確実に発行するとは、ある匿名アドレスを使う装置がその匿名アドレスを使ってIPsecを実行する際に、他の装置になりすまされたり、装置の公開鍵をすりかえられたりしないことを意味する。
【００１７】
そのため、特許文献１や特許文献２では、リンク層の情報を利用してなりすましやすりかえを検出することを目的に、証明書発行対象の装置と同じリンクにCAが位置する、あるいは同じリンクに接続されている別の装置とCAが互いに信頼関係を結ぶことを仮定していた。これらの方法は会社内部のネットワークのように、管理者が各リンクとルーターを管理するような場合に、特に適している。
【００１８】
一方、IPv6のネットワーク運用方法として、48ビットのsubnet prefixをユーザに割り当てる方法がある。この場合、ユーザは128ビットのIPv6アドレスのうち80(=128-48)ビットを自由に使えるので、2^80個に相当するアドレス・ブロックを割り当てるとも言う(a^bは、aのb乗を意味する)。subnet prefixに着目すると、ユーザは64ビットのsubnet prefixのうち16(=64-48)ビットを自由に割り当てて使えるので、ユーザが使える範囲内で自由にサブネットを定めて任意のネットワーク構成を実現できる。
【００１９】
このような場合、64ビットのsubnet prefixが割り当てられるリンクおよびそのdefault gatewayはユーザの配下にあるが、そのリンクに存在する装置が信頼できる（悪意を持たない）ことが保証されない場合があり得る。
【特許文献１】特願２００３−０８５３３５号
【特許文献２】特願２００３−１０７５３４号
【発明の開示】
【発明が解決しようとする課題】
【００２０】
xビット(xは64未満)の subnet prefix がユーザに割り当てられる場合に、装置に対して使い捨て匿名公開鍵証明書を効率的に確実に発行する方法は知られていない。具体的には、同じ匿名アドレスを含む異なる匿名公開鍵証明書が存在しないように発行する効率的な方法は知られていない。
【課題を解決するための手段】
【００２１】
本出願に係る発明は、上記課題を解決するために、パケットを監視する手段を設け、ユーザ管理下の装置が使い捨て匿名公開鍵証明書の発行を要求する際に前記装置から公開鍵証明書発行装置に送られるパケットを監視する。さらに、同一の送信元アドレスあるいは同一の宛先アドレスを持つパケットを検出した場合は、そのパケットの転送を中断する。
【００２２】
上記構成において、ユーザ管理下の装置が公開鍵証明書発行装置に送る使い捨て匿名公開鍵証明書の発行要求パケットを監視し、その送信元アドレスに含まれる匿名アドレスを記録し、その発行要求パケットを公開鍵証明書発行装置に転送する。同じ匿名アドレスを送信元アドレスとする異なる発行要求パケットが公開鍵証明書発行装置に送られる場合は、その(２つ目以降の)パケットを公開鍵証明書発行装置に転送しない。また、公開鍵証明書発行装置からユーザ管理下に向けて送られる匿名公開鍵証明書発行パケットを監視し、同じ匿名アドレス宛に異なる匿名公開鍵証明書発行パケットが送られる場合、そのパケットを転送しない。
【００２３】
また、公開鍵証明書発行装置が、ユーザ管理下の装置から送られてくる使い捨て匿名公開鍵証明書要求メッセージの中に含まれる匿名アドレスと、前記要求メッセージを含むパケットの送信元アドレスが一致することを確認する。
【００２４】
また、本出願に係る発明は、匿名アドレスを使うユーザ管理下の装置と公開鍵証明書発行装置の間でID protectionと公開鍵証明書を用いたIKEを実行する手段を設け、IPsec通信において、使い捨て匿名公開鍵証明書の発行要求と発行のプロトコルを、通信相手の確認を行いながら実行する。
【００２５】
また、本出願に係る発明は、パケット監視遮断手段と公開鍵証明書発行装置の間でIPsec通信を行い、ユーザ管理下の装置が使い捨て匿名公開鍵証明書の発行を要求する際に前記装置から公開鍵証明書発行装置に送られるパケットを監視する。さらに、同一の送信元アドレスを持つ異なる証明書要求パケットを検出した場合は、そのパケットの転送を中断する。
【００２６】
上記構成において、ユーザ管理下の装置が公開鍵証明書発行装置に送る使い捨て匿名公開鍵証明書の発行要求パケットを監視し、その送信元アドレスに含まれる匿名アドレスを記録し、その発行要求パケットを公開鍵証明書発行装置に転送する。同じ匿名アドレスを送信元アドレスとする異なる発行要求パケットが公開鍵証明書発行装置に送られる場合は、その(２つ目以降の)パケットを公開鍵証明書発行装置に転送しない。
【００２７】
また、公開鍵証明書発行装置からユーザ管理下に向けて送られる匿名公開鍵証明書発行パケットを監視し、同じ匿名アドレス宛に異なる匿名公開鍵証明書発行パケットが送られる場合、そのパケットを転送しない。
【００２８】
以上により、ある匿名アドレスを含む匿名公開鍵証明書は一つしか発行されない。
【発明の効果】
【００２９】
以上説明したように、本発明によれば、xビット(xは64未満)の subnet prefix がユーザに割り当てられる場合に、装置に対して使い捨て匿名公開鍵証明書を効率的に確実に発行することができる。
【００３０】
具体的には、同じ匿名アドレスを含む異なる匿名公開鍵証明書が存在しないように発行することができる。
【００３１】
本出願に係る発明によれば、送信元アドレスあるいは宛先アドレスが同じパケットを監視し、同一の送信元アドレスあるいは同一の宛先アドレスを持つ異なるパケットを遮断することにより、ユーザ管理下のノードが不正行為を働いたときに、ある匿名アドレスを含む匿名公開鍵証明書が複数発行されることを防ぐことが実現できる。
【００３２】
また、本出願に係る発明によれば、匿名アドレスを含む証明書要求パケットが発行装置に送られる際に、同一の送信元アドレスを持つ異なる証明書要求パケットを検出した際は遮断装置が遮断し、前記証明書要求パケットに含まれる匿名アドレスと前記証明書要求パケットの送信元アドレスが一致していることを前記発行装置が確認して匿名アドレス宛に証明書を発行することにより、ユーザ管理下とは限らないノードが匿名公開鍵証明書を要求するパケットを複数、公開鍵証明書発行装置に送り、同じ匿名アドレスを含む複数の匿名公開鍵証明書を発行させようとする攻撃を防ぐことができる。
【００３３】
また、本出願に係る発明によれば、同一の宛先アドレスを持つ異なる証明書パケットを検出した際は遮断装置が遮断することにより、匿名公開鍵証明書を発行するパケットがユーザ管理下のノードに複数送られることを防ぐことができる。
【００３４】
また、以前に監視・記録されていないアドレスを宛先とする証明書パケットを検出した際は遮断装置が遮断することにより、匿名公開鍵証明書を要求するパケットがそこから送られていないアドレスに対して、匿名公開鍵証明書を発行するパケットが送られることを防ぐことができる。
【００３５】
また、本出願に係る発明によれば、公開鍵証明書を要求する装置と公開鍵証明書発行装置の間でIKEを実行してIPsec通信を確立し、匿名公開鍵証明書発行プロトコルを実行する際に、IKEのID protection機能と公開鍵証明書を用いて通信相手の確認を行うこと、IKEを実行する際に匿名アドレスを使用すること、公開鍵証明書発行装置はIKEのパケットの送信元アドレスと証明書要求パケットに含まれる匿名アドレスが一致することを確認することにより、パケットのアドレス書き換えを行って匿名公開鍵証明書を要求するパケットを公開鍵証明書発行装置に送り、同じ匿名アドレスを含む複数の匿名公開鍵証明書を発行させようとする攻撃を防ぐことができる。
【００３６】
また、本出願に係る発明によれば、遮断装置と公開鍵証明書発行装置の間でIPsec通信が行われ、匿名アドレスを含む証明書要求パケットが前記発行装置に送られる際に、前記パケットの送信元アドレスを前記遮断装置が監視して同一の送信元アドレスを持つ異なる証明書要求パケットを検出した際は前記遮断装置が遮断し、前記証明書要求パケットに含まれる匿名アドレスと前記証明書要求パケットの送信元アドレスが一致していることを前記発行装置が確認して匿名アドレス宛に証明書を発行することパケットのアドレス書き換えを行うような方法によって匿名公開鍵証明書を発行させようとする攻撃を防ぐことができる。
【００３７】
よって、ADSL環境におけるユーザ管理下のネットワークにおいて、匿名アドレスを用いてIPsecを安全に実行することができる。
【発明を実施するための最良の形態】
【００３８】
本発明を実施するための最良の形態は、遮断装置と、公開鍵証明書発行装置からなるシステムにより実現される。
【００３９】
前記遮断装置は、匿名アドレスを含む証明書要求パケットが前記発行装置に送られる際に、前記パケットの送信元アドレスを監視して同一の送信元アドレスを持つ異なる証明書要求パケットを検出した際は遮断する。前記発行装置は、前記証明書要求パケットに含まれる匿名アドレスと前記証明書要求パケットの送信元アドレスが一致していることを確認して匿名アドレス宛に証明書を発行する。
【００４０】
また、遮断装置は、証明書を含むパケットが前記公開鍵証明書発行装置から公開鍵証明書を要求した装置に送られる際に、前記パケットの送信元アドレスおよび宛先パケットを監視して、同一の宛先アドレスを持つ異なる証明書パケットを検出した際、あるいは以前に監視・記録されていないアドレスを宛先とする証明書パケットを検出した際は遮断する。
【００４１】
詳細は、以下の実施例により、説明する。
【実施例１】
【００４２】
本実施例では、ユーザ管理下のネットワークがISPのネットワークを経由してインターネットと接続されている場合を説明する。最初に現状を説明し、その後に本実施例を説明する。
【００４３】
１．想定環境
図２は、本実施例の環境（ユーザ管理下のネットワークがISPのネットワークを経由してインターネットに接続される環境）を模式的に示したものである。
【００４４】
インターネット202とISP管理のネットワーク(206で示した領域)とユーザ管理下のネットワーク(216で示した領域)とがリンク207で接続されている。リンクとは、それに接続された装置がそれを介して通信することができる設備もしくはメディアであり、IP層の下側に接する。リンクにはイーサネット（登録商標）や、無線LAN(IEEE 802．11)、PSTN(Public Switched Telephone Network)やISDN(Integrated Services Digital Network)やADSL(Asymmetric Digital Subscriber Line)を用いたPPPリンク、 X．25、フレームリレー、ATMネットワーク等がある。
【００４５】
ユーザ管理下のネットワーク216には、ユーザ・ルーター208、ホスト210、ホスト211、ユーザ・ルーター212、ホスト213、ホスト214等の装置が、リンク209やリンク215で接続されている。ユーザ・ルーター212はリンク215に接続する装置に対してdefault gatewayとして機能し、ユーザ・ルーター208はリンク209に接続する他の装置に対してdefault gatewayとして機能する。
【００４６】
ISP管理のネットワーク206には、ISPルーター205、後述するdetector204、ISP core network203があり、インターネット202とユーザ管理下のネットワーク216を接続する。
【００４７】
リンクに接続されたIPv6対応装置をノードと呼ぶ。ノードの内部構成の典型例を図３に示す。なお、CA(Certification Authority)201やdetector(遮断装置)204も、図３示のようなコンピュータにより構成することが可能である。CA201は、認証局であり、公開鍵証明書を発行する公開鍵証明書発行装置である。
【００４８】
ノードには、ルーター（205、208、212）とホスト（210、211、213、214）があり、ルーター（205、208、212）は自分宛ではないパケットを転送するがホスト（210、211、213、214）は転送しない。図３からわかるように、ノード300は、ネットワーク・インターフェイス301、302、CPU303、ROM304、RAM305、HD(ハードディスク)306、電源307、キーボード／ポインティングデバイスのインターフェイス308、モニターのインターフェイス309、バス310等を有する計算機である。ノードによってはHDを持たないものもある。
【００４９】
ルーター（205、208、212）は複数のネットワーク・インターフェイス301、302を持つのに対し、ホスト（210、211、213、214）は多くの場合は一つのネットワーク・インターフェイス301を持つ。例えば、ホスト210、ホスト211は、ネットワーク・インターフェイス301により、リンク209を介して、リンク209に接続された他のノード、あるいは、更に、リンク209におけるdefault gatewayであるユーザ・ルーター208を介して、インターネット202上のサイトと通信する。
【００５０】
ユーザにxビット(xは64未満)のsubnet prefixが割り当てられる場合、ユーザ管理下のネットワーク216は複数のsubnetから構成される場合がある。例えば、図２では、リンク215がユーザ・ルーター212を介してリンク209と接続されているので、リンク209とリンク215を別のsubnet(異なるsubnet prefixが割り当てられている)にできる。
【００５１】
なお以下の処理内容(手順)は、プログラムもしくはモジュールとして実現され、そのプログラムがROM 304もしくはHD 306に格納されたノードが実行、もしくはそのモジュールを有するノードが実行する。例えば、プログラムとして実現される場合は、そのプログラムをコンピュータであるCPU 303が読み込み、必要に応じてRAM 305を計算のための空間として利用しながらバス310を介してインターフェイス301にアドレスを割り当てる、というような動作を行う。モジュールの場合は、プログラムがCPUやRAM等と協調して実行する上述の動作と同等の動作を実行する実体が、例えばLSIとして実現され、ノードに組み込まれている。ノードのCPUからモジュール(LSI)へ指示が発行され、それをきっかけにモジュールが動作し、処理を実行する。
【００５２】
ここでは、ノード300がアドレスをインターフェイスに割り当てる、というように手順の本質を説明する。
【００５３】
２．想定環境における各装置の動作
以下では、ISPのネットワーク206とユーザ管理下のネットワーク216との間のリンク207がADSLであり、48ビットのsubnet prefixがISPからユーザに割り当てられる場合を説明する。
【００５４】
ISPがユーザにsubnet prefixを割り当てる仕組みは prefix delegation と呼ばれ、RFC3315、“Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”を利用する方法が提案されている。DHCPv6は、ノードに使わせたいIPv6アドレスやDNSサーバーのIPv6アドレスをノード(DHCPクライアント)に伝達するために、DHCPサーバーとDHCPクライアントの間で実行されるUDPのプロトコルである。
【００５５】
簡単に説明すると、DHCPクライアントはDHCPサーバーを特定するために a Solicit message をマルチキャストで送る。その Solicit message を受けたDHCPサーバーは an Advertise message を返す。その Advertise messageを受けたDHCPクライアントは、IPv6アドレスや他の情報を求めて a Request message をそのDHCPサーバーに送る。そのDHCPサーバーは、IPv6アドレスや他の情報を含めた a Reply message で返答する。DHCPサーバーとDHCPクライアントの間をとりもつDHCP relay agentが存在すれば、DHCPサーバーとDHCPクライアントが異なるリンク上にいても機能する。
【００５６】
DHCPv6を利用するprefix delegationは、DHCPv6のプロトコルにおいて伝達される情報(Option)に prefix(es) を加え、prefix delegationのみを実行すること、あるいはIPv6アドレスの割り当てや他の情報の伝達と一緒にprefix delegationを実行することを可能とする仕組みである。2003年11月時点では、draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05.txt が最新の文献である。以下では、この仕組みを DHCPv6-PDと記す。
【００５７】
DHCPv6-PDにおいては、ユーザのルーターがDHCPクライアント、ISPのルーターがDHCPサーバーとなり、prefix(es)が伝達される。このとき、ユーザのルーターをrequesting router、ISPのルーターをdelegating routerと呼ぶ。図２では、ユーザ・ルーター208がrequesting router、ISPルーター205がdelegating routerになる。
【００５８】
ISP管理下のISPルーター205とユーザ管理下のユーザ・ルーター208 が、ADSLにより接続されている場合、両方のルーターの電源が入れられると電気的な調整が行われて、ADSLリンク207が確立し、電気信号が伝達可能になる。次に PPPによってISPルーター205が ユーザ・ルーター208を認証し、IPパケットの送受信が行えるようになる。最後に、DHCPv6-PDが実行され、ISPルーター205(delegating router)がユーザ・ルーター208 (requesting router)に48ビットのprefix(／48 prefixと記す)を割り当てる。／48 prefixを受け取ったユーザ・ルーター208 (requesting router)は、／64 prefixと自分のIPv6アドレスを生成し、後者を自分のインターフェイス（リンク209を接続するネットワーク・インターフェイス302）に割り当て、前者をRAに含めてリンク209に流す。
【００５９】
なお、ユーザはISPによって認証されてはじめてインターネットにアクセスできるので、PPPにおいて何らかのユーザ認証が行われる。現状では、ISPがユーザにユーザ名とパスワードを事前に発行し、ユーザはユーザ・ルーター208にユーザ名とパスワードを設定し、ISPルーター205とユーザ・ルーター208の間でユーザ認証プロトコルとしてCHAPを用いた認証を行うことが多いと思われる。CHAPは、RFC1994、 “PPP Challenge Handshake Authentication Protocol”に記載されている。ISPがユーザを認証する方法として、ユーザ名とパスワードのみならず後述の公開鍵証明書を用いる方法もある。
【００６０】
次に、リンク209に接続しているホスト210の動作を説明する。ホスト210の電源が入れられると、インターフェイスIDが生成され、リンク209に流されているRAを取得し、RAに含まれる／64 prefixから、前述のIEEE EUI-64形式のアドレスを生成し、自分のインターフェイス（リンク209を接続するネットワーク・インターフェイス301）に割り当てる。また、(RAを送出している)ユーザ・ルーター208をdefault gatewayに設定する。これにより、(グローバルな) IPv6アドレスが定まり、インターネットを介して遠隔地の通信相手と通信できる。
【００６１】
なお、図２のように、ユーザ管理下のネットワーク216内部で異なるサブネットを運用する場合は、リンク209に割り当てる／64 prefixとリンク215に割り当てる／64 prefixを別の値とし、前者をユーザ・ルーター208がリンク209に(RAに含めて)流し、後者をユーザ・ルーター 212がリンク215に(RAに含めて)流すように両方のユーザ・ルーターを設定する。また、ユーザ・ルーター208がリンク209のdefault gatewayとして、ユーザ・ルーター212がリンク215のdefault gatewayとして動作するように設定し、両ルーター間で経路情報が交換されるようにプログラムを動作させる。これらの設定は通常はユーザが手動で行う。
【００６２】
また、DNS(Domain Name System)サーバーのアドレスを必要に応じて各ルーターおよび各ホストにユーザが手動で設定する。DNSサーバーの自動設定方法は現時点では標準化されていない。
【００６３】
３．匿名公開鍵証明書
匿名公開鍵証明書は、学術的には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、851としても開示されている。これらの方式では、証明書のユーザの匿名性は計算量的に保たれていた。
【００６４】
より強力な匿名性を提供する方式として、情報量的な匿名性を有する匿名公開鍵証明書の実現方法が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は、必要に応じてエンティティの身元を物理的手段等で確認し、提示されたエンティティ名(ユーザ名)とパスワード、公開鍵v_iを記憶する。エンティティの身元を物理的手段等で確認する代わりに、他の信頼できるCAによって発行された公開鍵証明書と対応する秘密鍵を所持していることの証明の提示によって身元確認を行ってもよい。
【００６８】
匿名公開鍵証明書を発行する際、CAは、乱数r(1以上q以下)を生成し、(g'、v_i')=(g^r mod p、 (v_i)^(r) mod p)を計算する。公開のパラメータや証明書の有効期限、v_caに対する公開鍵証明書(後述)等の証明書の管理・属性情報をXとし、(g'、v_i')とXを含むメッセージ(のハッシュ値)に対してディジタル署名を生成する。CAは離散対数問題に基づくディジタル署名方式、例えば、Schnorr署名方式を使うことができる。このディジタル署名を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を秘密鍵として離散対数問題に基づく公開鍵暗号やディジタル署名を利用できる。
【００７０】
匿名公開鍵証明書(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)上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能であり、その場合は乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。
【００７２】
４．本実施例の前提
次に、本実施例を、図１を参照しながら説明する。図１は、CA201、detector204、ISPルーター205、ユーザ・ルーター208、ホスト210の間で行われるプロトコルを示し、電源を入れられてからの基本的な動作は既に述べたようにして実行されるものとする。CA201は、匿名公開鍵証明書におけるエンティティCAの役割のうち、証明書の発行に関する役割を果たす。すなわち、CA201は、匿名公開鍵証明書を発行する公開鍵証明書発行装置である。
【００７３】
図２のdetector204は、ISPによって管理されている装置であり、特定のIPv6アドレスを送信元あるいは宛先とするIPv6パケットを監視・記録する。必要に応じてIPv6パケットの内部の解析を行い、条件に合致するIPv6パケットを検出した場合は、そのIPv6パケットの転送を遮断する機能を有する。すなわち、detector204は、遮断装置である。detector204は、ユーザ管理下では無い場所(ユーザネットワーク216の外)に設けられている。detector204は、ユーザ管理下の装置(ユーザネットワーク216内の装置)が使い捨て匿名公開鍵証明書の発行を要求する際に前記装置から公開鍵証明書発行装置CA201に送られるパケットを監視する。
【００７４】
detector204が監視・記録するIPv6アドレスは、ISPによって設定される。本実施例の場合、CA201のIPv6アドレスと、ユーザに割り当てられる／48 prefixを持つIPv6アドレスが設定され、ユーザ管理下のネットワーク216からCA201宛に送られる匿名公開鍵証明書要求パケットと、CA201からユーザ管理下のネットワーク216に送られる匿名公開鍵証明書発行パケットが監視される。detecotor204は、CA201のアドレスなどを、RAM305に記憶し、受信したパケットのアドレスと比較する。
【００７５】
前提として、ホスト210(のHD306)にはその装置もしくはユーザに対して発行された(匿名ではない)公開鍵証明書とその証明書に対応する秘密鍵と、(匿名ではない)公開鍵証明書を発行したエンティティの公開鍵証明書が格納されており、秘密鍵は安全に管理されているものとする。
【００７６】
装置に対して発行された公開鍵証明書の場合、装置の種類、型番、シリアル番号等の装置に関する情報と装置の公開鍵とを含むメッセージに対して、製造者がディジタル署名を生成し、前記メッセージと前記ディジタル署名の組を公開鍵証明書として使うことが可能である。
【００７７】
ユーザに対して発行された公開鍵証明書の場合、ユーザを識別する情報とユーザの公開鍵とを含むメッセージに対して前記公開鍵証明書を発行したエンティティがディジタル署名を生成し、前記メッセージと前記ディジタル署名の組を公開鍵証明書として使うことが可能である。ISPがユーザに公開鍵証明書を発行することにより、前記PPPにおけるユーザ認証においてユーザ名とパスワードの代わりに公開鍵暗号を用いる認証を実行できるようになるので安全性が高まる。ISPがユーザに発行した公開鍵証明書を装置に設定して使うこともあり得る。
【００７８】
以下では装置もしくはユーザを総称してエンド・エンティティと呼ぶ。
【００７９】
CA201は、エンド・エンティティに公開鍵証明書を発行したエンティティ(製造者やISP)の公開鍵証明書を入手したとき、それを用いて前記エンド・エンティティの公開鍵証明書の正当性を確認することが可能であるとする。CA201が別のCAの公開鍵を知っており、エンド・エンティティに公開鍵証明書を発行したエンティティ(製造者やISP)の公開鍵証明書をその別のCAが作成した場合は、この確認は容易に行われる。
【００８０】
なお、(匿名ではない)公開鍵証明書を発行するエンティティと匿名公開鍵証明書を発行するCA201は同じエンティティとは限らない。
【００８１】
エンド・エンティティに対して発行された(匿名ではない)公開鍵証明書は、CA201がエンド・エンティティを特定するために利用する。前述の匿名公開鍵証明書の論文においては、そのCAが、各(エンド・)エンティティの身元を物理的手段等で確認する役割と、匿名公開鍵証明書を発行する役割を兼ねていたが、本実施例におけるCA201は各(エンド・)エンティティの身元を物理的手段等で確認する役割を有するとは限らず、エンド・エンティティの身元を確認する手段として(匿名ではない)公開鍵証明書を用いることもできる。証明書の形式はX.509v3を採用できる。証明書の形式は本質的ではないので詳細は省く。以降では、CA201は各エンド・エンティティの身元を物理的手段等で確認する役割を有さないものとして説明する。
【００８２】
匿名公開鍵証明書で使われるpやq、g、H等のパラメータは定められており、各装置はそれらをあらかじめ知っている(HD306などに記憶している)ものとする。
【００８３】
また、CA201の公開鍵(もしくは自己署名証明書)はホスト210(のHD306)にあらかじめ記録されている、あるいはCA201のIPアドレスあるいはFQDNと一緒に公開鍵証明書(あるいは自己署名証明書)も後述の方法で伝達される、あるいはDNSが利用可能で、CA201のIPv6アドレスもしくはFQDNが判明すれば、公開鍵ディレクトリからCA201の公開鍵(もしくは自己署名証明書)を検索してCA201の公開鍵を得ることができるものとする。あるいは、CA201のIPv6アドレスに対してCA201の公開鍵証明書を開示するように要求するパケットをホストが送り、その返答としてCA201の公開鍵証明書をホストが得る。いずれにせよ、CA201の公開鍵(もしくは自己署名証明書)をホスト201が入手する方法が存在することが必要であり、その方法は複数存在し得る。従って、本実施例においては特定の方法を仮定せず、いずれかの方法によって入手するものとして説明する。
【００８４】
５．本実施例の具体的な動作
図１のステップS101までに、ISPルーター205とユーザ・ルーター208の間では前述のDHCPv6-PDが実行されて、／48 prefixが割り当てられ、／64 prefixおよびIPv6アドレスがユーザ・ルーター208に設定されているとする。
【００８５】
ステップS101で、ISPルーター205(のネットワーク・インターフェイス302)からユーザ・ルーター208(のネットワーク・インターフェイス301)にCA201のFQDNもしくはIPv6アドレスが伝達される。この伝達は、例えばDHCPv6のOPTIONにCA201のIPv6アドレスを追加し、ISPルーター205がDHCPサーバー、ユーザ・ルーター208がDHCPクライアントとしてDHCPを実行することで実現できる。DHCPv6のOPTIONを拡張することにより、IPv6アドレスだけではなくFQDNも伝達可能である、あるいは公開鍵証明書(あるいは自己署名証明書)も伝達可能である。このIPv6アドレスなどは、ISPルーター205(のHD306)に登録されている。
【００８６】
上記のようにして伝達されたCA201のIPv6アドレスは、次に述べる、拡張したRS／RAプロトコルにおいて、ユーザ・ルーター208(のネットワーク・インターフェイス302)からホスト210(のネットワーク・インターフェイス301)に伝えられる。
【００８７】
RS(Router Solicitaion)とRA(Router Advertisement)のプロトコルの詳細は、前述のRFC 2461 “Neighbor Discovery for IP Version 6 (IPv6)”に記述されているのでそれを参照するものとする。本実施例では、CA201のIPv6アドレスをユーザ・ルーター208からホスト210に伝えるために拡張した部分について説明する。
【００８８】
RSとRAは、ICMPv6パケットであり、そのメッセージ・フォーマットにOptionが定義されており、Optionの拡張も認められている。5種類のOptionが定義されており、RSにおいて効力があるオプション(valid option)として Source link-layer address が、RAにおいて効力があるオプション(possible options)として Source link-layer address とMTUとPrefix Informationが定められている。Optionの種類は、Option中のTypeフィールドに格納される値によって定まる。本実施例においては、そのTypeフィールドに新たな値(例えば、6)を割り当て、その値のときはCA201のIPv6アドレスもしくはFQDNもしくは公開鍵証明書がOptionとして格納されるものとする。Option中にはTypeフィールドの他にLengthやアドレスを格納するフィールドがある。
【００８９】
以上のように拡張したRSと拡張したRAを用いて、以下のようなプロトコルによってCA201のアドレスがユーザ・ルーター208からホスト210に伝わる。
【００９０】
最初にホスト210は、Optionに上記新たな値を格納したRS(例えば、Option中のTypeフィールドに6を格納したRS)をネットワーク・インターフェイス301からリンク209に送る(全ルーター宛にマルチキャストする)。図１のステップS102に相当する。
【００９１】
ユーザ・ルーター208は、ネットワーク・インターフェイス302で、前記RSを受信したら、そのOptionを解析し、その値からCA201のアドレスを求められていることを知る。そこで、CA201のIPv6アドレスあるいはFQDNあるいは公開鍵証明書をOptionに格納したRA(例えば、Option中のTypeフィールドに6を格納し、Option中のデータフィールドにCA201のIPv6アドレスあるいはFQDNあるいは公開鍵証明書を格納したRS)を用意し、それをネットワーク・インターフェイス302からホスト210に送る。図１のステップS103に相当する。
【００９２】
ホスト210は、ネットワーク・インターフェイス301で、前記RAを受信したら、そのOptionを解析し、CA201のアドレスもしくはFQDNもしくは公開鍵証明書を得る。
【００９３】
ステップS104でホスト210は、／64 prefixとインターフェイスIDからIEEE EUI-64形式のIPv6アドレス(public addressと呼ぶ)、／64 prefixとRFC3041の方法等でランダムに生成したインターフェイスIDからtemporary address(匿名アドレス)を生成する。次に、前述のように拡張したRAからCA201のアドレスもしくはFQDNもしくは公開鍵証明書を取出す。CA201の公開鍵証明書が得られない場合は、前述のように公開鍵ディレクトリにアクセスし、CA201のアドレスもしくはFQDNからCA201の公開鍵証明書を取得する。あるいは、ホスト210がCA201のIPv6アドレスに対してCA201の公開鍵証明書を開示要求するパケットを送り、その返答としてCA201の公開鍵証明書を含むパケットがホスト210に送られるとしてもよい。
【００９４】
そして、(ホスト210がエンティティiに対応すると考えて)前述のように秘密鍵s_iおよび公開鍵v_iを生成し、匿名公開鍵証明書要求メッセージを生成する。なお、s_iとv_iは最初に一度だけ生成して記録し、2回目以降の匿名公開鍵証明書要求メッセージのときにはそれらを利用してもよい。匿名公開鍵証明書要求メッセージは、例えば、PKCS#10に従って生成することができる。
【００９５】
このとき、v_iおよび匿名アドレス(テンポラリアドレス、temporary address)をメッセージに含める。X.509v3の場合、extensionとして匿名公開鍵証明書用公開鍵を定義して格納すればよい。IPアドレスは、既にextension(のsubjectaAltName)として定義されている。具体的には、ホスト210は自分の(匿名ではない)公開鍵証明書のSubjectの内容を匿名公開鍵証明書要求メッセージのSubjectにコピーし、extensionに匿名公開鍵証明書用公開鍵として(gとpと)v_i、subjectAltNameにtemporary address(テンポラリアドレス、匿名アドレス)を格納したメッセージを作成する。なお、Subjectとは、その証明書の被発行者(つまり、持ち主)を示す。
【００９６】
次に、そのメッセージに対して(ホスト210あるいはそのユーザの公開鍵証明書の)秘密鍵を用いてディジタル署名を生成する。メッセージとディジタル署名と公開鍵証明書の組が匿名公開鍵証明書要求メッセージである。その他の詳細は、X.509v3およびPKCS#10の仕様に従う。
【００９７】
また、ホスト210は前記匿名公開鍵証明書要求メッセージをCA201が復号できるように暗号化する。暗号化は、例えば、共通鍵暗号と公開鍵暗号を組み合わせたいわゆるハイブリッド方式あるいはCA201の公開鍵で直接暗号化する方式が用いられる。本実施例ではこの暗号化した匿名公開鍵証明書要求メッセージをCR(Certification Request)と呼ぶことにする。
【００９８】
ステップS105でホスト210は、CA201のIPv6アドレス宛に前記CRを送る。ただし、送信元アドレスとしてtemporary address(匿名アドレス)を使う。このとき、転送プロトコルは、IPv6上のプロトコルであり、パケットの損失が無い(再送制御が可能)方法であり、かつdetector204が理解できる方法であればよく、例えばTCPが使える。用いる転送プロトコルをあらかじめ定めておき、それ以外の転送プロトコルは、別途定めるプロトコルを除き、detector204が遮断する。
【００９９】
別途定めるプロトコルとしては、前述したようにホストがCA201の公開鍵証明書を開示要求するプロトコルが考えられる。このプロトコルは、例えば、TCPを使い、TCPのペイロード・データの形式および値を事前に定めておきペイロード・データは暗号化しないものとする。このように、やりとりされるデータをdetector204が確実に把握できるように定義されたプロトコルであれば、遮断すべきプロトコルとの識別が容易に行える。
【０１００】
CRおよび後述するCMを転送するプロトコルをCR／CMプロトコル、遮断しなくてもよい別途定められるプロトコルを通過許可プロトコル、CR／CMプロトコルと通過許可プロトコル以外のプロトコルを通過禁止プロトコルと呼ぶことにする。
【０１０１】
ステップS106でdetector204は、宛先アドレスとしてCA201のIPv6アドレスを含むパケットを監視し、そのペイロードに含まれるプロトコルを解析する。detector204は、ホスト210からのパケットをネットワーク・インターフェイス302により受信し、CPU303が、宛先アドレス、および、(宛先アドレスがCA201のアドレスであれば)プロトコルを解析する。監視・解析対象のプロトコルが通過禁止プロトコルの場合、転送せず遮断する(パケットを破棄し、転送しない)。監視・解析対象のプロトコルが通過許可プロトコルであってCR／CMプロトコルではない場合は、ネットワーク・インターフェイス301から転送する。
【０１０２】
監視・解析対象パケットのプロトコルがCR／CMプロトコルの場合、その送信元アドレスをRAM305に記録する。既にその送信元アドレスがRAM305に記録されている場合はそのIPv6パケットを遮断する。記録されていない場合は、ステップS107でそのパケットをネットワーク・インターフェイス301からCA201に転送する。
【０１０３】
以後、今回のIPv6パケットと同じ送信元アドレス及び宛先アドレスを持つIPv6パケットを継続監視し、そのパケットによって実行される転送プロトコル(CR／CMプロトコル)において、例えばTCPにおいて再送制御がおこなわれているのか、あるいは異なるコネクションが開始されようとしているのか否かを判別する。TCPであれば、異なるコネクションが開始されようとしている場合は、TCPヘッダ中のportの組(source port(送信元ポート)とdestination port(宛先ポート))が異なる値をもつIPv6-TCPパケットが観測されるので、そのIPv6-TCPパケットの転送を遮断する。ただし、再送制御の場合は、TCPヘッダ中のport(ポート)の組は変化しないのでパケットの転送は遮断されない。以下ではCR／CMプロトコルがTCPであるものとして説明する。監視された送信元アドレス(および送信元ポート)は、RAM305内のデータベースに記録する。
【０１０４】
このように、detector204は、パケットを受信する受信手段(ネットワーク・インターフェイス302)を有し、送信元アドレスが同じパケットを監視する。detector204は、同一の送信元アドレスを持つ異なるパケットを遮断する遮断手段(CPU303)を有する遮断装置である。detector204は、テンポラリアドレスを使用する(IPv6)装置(ホスト210)からテンポラリアドレスを含む証明書要求パケット(メッセージ)CRが公開鍵証明書発行装置(CA201)に送られる際に、証明書要求パケット(メッセージ)CRの送信元アドレスを監視する。detector204の遮断手段であるCPU303は、同一の送信元アドレスを持つ異なる証明書要求パケットを遮断する。すなわち、detector204は、同じ匿名アドレスを送信元アドレスとする異なる発行要求パケットCRが公開鍵証明書発行装置CA201に送られる場合は、その(２つ目以降の)パケットを公開鍵証明書発行装置CA201に転送しない。ただし、同一の公開鍵証明書要求パケットCRが再送される場合は、転送する。
【０１０５】
detector204のCPU303は、HD306またはROM304に格納されたプログラムを読み出して処理することにより、以上のような動作を行う。
【０１０６】
ステップS108でCA201は、ネットワーク・インターフェイス301によりCRを受け取る。復号した匿名公開鍵証明書要求メッセージが、匿名公開鍵証明書要求メッセージとして正しいか否かをチェックする。つまり、匿名公開鍵証明書要求メッセージの中に、署名対象メッセージとディジタル署名と公開鍵証明書が形式に従って含まれていることを確認し、公開鍵証明書が正しいこと(その証明書を発行したエンティティによる正しいディジタル署名であること)を(その証明書を発行したエンティティの公開鍵で)確認し、署名対象メッセージとディジタル署名の対応関係が正しいことを公開鍵証明書に含まれていた公開鍵で確認し、CRを送るために使われた送信元IPアドレス(証明書要求パケットの送信元アドレス)と署名対象メッセージ内部のsubjectAltNameのIPアドレス(証明書要求パケット(メッセージ)に含まれる匿名アドレス)が等しいことを確認する。
【０１０７】
これらを確認できたならば、正しい匿名公開鍵証明書要求メッセージと判定し、その中の(gとpと) v_iから前述のように匿名公開鍵証明書APC_ca(i)を生成する。このとき、前記subjectAltNameのIPアドレスをXに格納してAPC_ca(i)を生成する。すなわち、CA201は、ユーザ管理下の装置であるホスト210から送られてくる証明書要求パケット(メッセージ)CRに含まれるテンポラリアドレス(匿名アドレス)と証明書要求パケット(メッセージ)CRの送信元アドレスが一致していることを確認してテンポラリアドレス宛に証明書を発行する公開鍵証明書発行装置である。なお、CA201は、どのエンティティ(ホスト210)にどの匿名公開鍵証明書を発行したか、その有効期限や匿名アドレス、匿名公開鍵証明書要求メッセージを記録してもよい。
【０１０８】
ステップS109でCA201は、APC_ca(i)を前記ホスト210のtemporary address(匿名アドレス)宛に送る。このとき、ホスト210のみが復号できるように暗号化してもよい。暗号化は、例えば、共通鍵暗号と公開鍵暗号を組み合わせたいわゆるハイブリッド方式あるいはホスト210の公開鍵で直接暗号化する方式が用いられる。本実施例ではこの暗号化した(あるいは暗号化しない)匿名公開鍵証明書APC_ca(i)をCM(Certificate Message)と呼ぶことにする。
【０１０９】
ステップS110でdetector204は、TCPコネクションの監視を継続している。ホスト210やCA201が正常に動作している場合は、ステップS106の際に開設された(CR／CMプロトコルとしての)TCPコネクションの中でCMがホスト210に送られるのでそのIPパケットが遮断されることはない。
【０１１０】
このとき、ユーザ管理下のネットワーク216に存在するアドレス(匿名アドレスとは限らない)宛に新しいTCPコネクションがCA201から開設される場合(別のCR／CMプロトコルを開設するようなIPパケットであり、宛先アドレスがユーザ管理下のネットワーク216に属するパケットが検出された場合)は、detector204はそのIPパケットを遮断する。なお、detector204は、このIPパケットをネットワーク・インターフェイス301で受信する。新しいTCPコネクションか否かは、detector204が管理するデータベース（RAM305内）の記録を参照して、過去にそのアドレスおよびポートにCMが送信されたか否かを確認することで判断できる(過去にCMが送信されていれば新しいTCPコネクションである)。また、過去にそのアドレスおよびポートからCRが送信されていない場合も、新しいTCPコネクションである。
【０１１１】
なお、detector204は、証明書パケットCMの宛先アドレス(および宛先ポート)を監視し、監視された宛先アドレス(および宛先ポート)を、RAM305内のデータベースに記録する。そして、detector204は、過去に監視、記録された宛先アドレス(および宛先ポート)が宛先アドレス(および宛先ポート)になっている証明書パケットCMを遮断する。
【０１１２】
また、detector204は、証明書要求パケットCRの送信元アドレス(および送信元ポート)を監視し、監視された送信元アドレス(および送信元ポート)を、RAM305内のデータベースに記録する。そして、detector204は、過去に監視、記録されていない送信元アドレス(および送信元ポート)が宛先アドレス(および宛先ポート)になっている証明書パケットCMを遮断する。
【０１１３】
以上のように、detector204は、証明書を含むパケットCMが公開鍵証明書発行装置CA201からテンポラリアドレスを使用する(IPv6)装置(ホスト210)に送られる際に、パケットCMをネットワーク・インターフェイス301により受信し、パケットCMの宛先アドレスを、監視する。detector204のCPU303は、同一の宛先アドレスを持つ異なる証明書パケットを遮断する。すなわち、同じ匿名アドレス宛に異なる匿名公開鍵証明書発行パケットCMが送られる場合、そのパケットCMを転送しない。過去に受信あるいは転送した公開鍵証明書発行パケットCMの宛先アドレスと同じ宛先アドレス宛ての公開鍵証明書発行パケットCMは、遮断する。ただし、同一の匿名公開鍵証明書発行パケットCMが再送される場合は、転送する。また、detector204のCPU303は、 以前に監視・記録されていないアドレスを宛先とする証明書パケットを遮断する。すなわち、受信した公開鍵証明書発行パケットCMの宛先アドレスが、過去に受信あるいは転送した公開鍵証明書要求パケットCRの送信元アドレスに一致しない場合、その公開鍵証明書発行パケットCMを遮断する。要求していないアドレスに発行された公開鍵証明書発行パケットCMは、遮断する。
【０１１４】
遮断しない場合、detector204は、IPパケットをネットワーク・インターフェイス302から転送する。
【０１１５】
detector204のCPU303は、HD306またはROM304に格納されたプログラムを読み出して処理することにより、以上のような動作を行う。
【０１１６】
ステップS111で、ステップS110で遮断されなかったIPパケットによってTCPでCMがホスト210に届く。
【０１１７】
ステップS112でホスト210は、受け取ったCM(を必要ならば復号して)からAPC_ca(i)を取出し、それが正しいことを前述のように確認する。
【０１１８】
同様の効果を得るために、detector204が行う監視をCA201が実行してもよいが、この場合はCA201の負荷が増える。本実施例の方式ではISPがdetector204を管理するので、現実のCAやISPの業務と整合性が取りやすい。つまり、CAは証明書の発行業務のみに専念すればよく、ISPは自分が管理するISPネットワーク206の構成に応じてdetector204を複数に分散したり、メンテナンスをしたりすることができ、維持管理が行いやすい。
【実施例２】
【０１１９】
実施例１では、detector204がISP管理下に存在した。本実施例では、detector204に相当する機能をCAが有する場合を説明する。実施例１で述べたようにCAの負荷は第一の実施例より増えるが、次に述べるように安全性は向上する(強い攻撃に対して安全である)。
【０１２０】
本実施例は、何らかの手段によって複数の匿名公開鍵証明書要求メッセージがCA201に送られ、CA201に複数の匿名公開鍵証明書を発行させる攻撃を想定している。
【０１２１】
例えば、図２のインターネット202上に悪意を持った攻撃者(図示せず)が存在し、その攻撃者が、ユーザ管理下のネットワーク216に存在するホスト211(のユーザ)と結託し、ホスト210にDoS(Deniable of Service)攻撃を加えることを考える。例えば、ホスト211がCA201に送る匿名公開鍵証明書要求パケットを攻撃者に密かに送り、その要求パケット(CRを含む)を攻撃者からCA201に送る。このとき、攻撃者は、CRを含む要求パケットの送信元アドレスを、ホスト210が使う匿名アドレスに書き換えて送る。
【０１２２】
この要求パケットを受け取ったCA201は、実施例１で説明したような確認を行い、前記匿名アドレスを含む匿名公開鍵証明書を生成し、前記匿名アドレス宛にCMを送る。攻撃者は、CMを含むパケットを横取りし、宛先アドレスをホスト211のアドレスに書き換え、転送する。
【０１２３】
同じ匿名アドレスを含む異なる匿名公開鍵証明書が存在すると、同じ匿名アドレスを用いるIPsec通信が同時に複数存在しうる。例えばホスト210とホストAがIPsec通信を行っているときに、ホスト210が使っている匿名アドレスを使ってホスト211がホストBとIPsec通信を行うとすると、ホスト210はホストAおよびホストBから匿名アドレス宛に送られてくるIPパケットを処理しなければならない。これにより、ホスト210の負荷は増える。同じ匿名アドレスを用いるIPsec通信が増えれば増えるほどホスト210の負荷は増えるので、ホスト210が行いたい通信が阻害される可能性がある。すなわち、DoS攻撃が成立し得る。
【０１２４】
以上のようなアドレス書き換えを伴う攻撃は、detector204のようなアドレス監視・遮断装置をISP管理のネットワークに設けるだけでは防ぐことが困難である。一方、IPsecは、IPパケットのアドレスが経路上で書き換えられたときにそれを検出する仕組みを提供する。
【０１２５】
そこで、匿名アドレスを使って匿名公開鍵証明書の発行要求を行う際に、ホストとCAの間でIKEを実行してIPsec通信を確立し、その通信の中で匿名公開鍵証明書要求と発行のプロトコルを実行すれば、前記攻撃を防ぐことができる。
【０１２６】
この場合、次のようなプロトコルになる。環境や前提は実施例１と同様とする。図4を参照して説明する。ただし、detector204は、不要である。
【０１２７】
ステップS401からステップS404までは実施例１のステップS101からステップS104までと同様である。
【０１２８】
ステップS405において、ホスト210は、CA201に対してIKE通信を開始する。このときホスト210は匿名アドレス(テンポラリアドレス)を使う。IKEにおいて、ID protectionと公開鍵証明書による認証(相手確認)を実行する。例えばMain modeとディジタル署名に基づく相手確認を採用する。公開鍵証明書はエンド・エンティティに対して発行されたものを使う。ID protectionが有効なので、インターネット上の第三者がIKEのパケットを全て観測していてもホストのIDおよび公開鍵証明書が盗聴されることはない。
【０１２９】
以上により、ある特定のホストがある匿名アドレスを使って通信していることをCA201は確認でき、そのパケットが第三者に改竄されたときはその事実を検出できる。ステップS405が完了した時点でIPsec通信が可能になる。
【０１３０】
次にステップS406でホスト210は、IPsec通信において、匿名公開鍵証明書要求パケットをCAに送信する。その中には使用中の匿名アドレスが含まれる。
【０１３１】
ステップS407でCA201は、そのパケットを受け取り、正当性を確認し、匿名アドレスを含む匿名公開鍵証明書が発行されていないことを、RAM205あるいはHD306に設けられたデータベースを検索して確認する。
【０１３２】
既にその匿名アドレスを含む匿名公開鍵証明書が発行されている場合は、プロトコルの続行を中止する。発行されていない場合は、その匿名アドレスを含む匿名公開鍵証明書を生成し、データベースにその事実を記載し、ステップS408で証明書を匿名アドレス宛に送信する。匿名公開鍵証明書には有効期限があるので、有効期限がきた証明書の記録はデータベースから削除する。
【０１３３】
ステップS409でホスト210は、受け取ったCM(を必要ならば復号して)からAPC_ca(i)を取出し、それが正しいことを前述のように確認する。
【０１３４】
以上のプロトコルのように、匿名アドレスを使うユーザ管理下の装置であるホスト210と公開鍵証明書発行装置CA201の間でID protectionと公開鍵証明書を用いたIKEを実行する手段を設け、IPsec通信において、使い捨て匿名公開鍵証明書の発行要求と発行のプロトコルを、通信相手の確認を行いながら実行する。すなわち、IPv6装置(ホスト210)と公開鍵証明書発行装置CA201の間でIKEを実行してIPsec通信（S405）を確立し、匿名公開鍵証明書発行プロトコルを実行する際に、IKEのID protection機能と公開鍵証明書を用いて通信相手の確認を行うこと、IKEを実行する際にIPv6装置(ホスト210)のテンポラリアドレスを使用すること、公開鍵証明書発行装置CA201はIKEのパケットの送信元アドレスと証明書要求パケットに含まれるテンポラリアドレスが一致することを確認する。公開鍵証明書発行装置CA201は、ネットワーク・インターフェイス301を用いて、IPv6装置(ホスト210)との間でIKEを実行してIPsec通信を確立する確立手段と、CPU303により、匿名公開鍵証明書発行プロトコルを実行する際に、IKEのID protection機能と公開鍵証明書を用いて通信相手を確認し、IKEのパケットの送信元アドレスと証明書要求パケットに含まれるテンポラリアドレスが一致することを確認する。
【０１３５】
CA201のCPU303は、HD306またはROM304に格納されたプログラムを読み出して処理することにより、以上のような動作を行う。
【０１３６】
したがって、同じ匿名アドレスを含む匿名公開鍵証明書が複数発行されることがなく、かつ前記DoSのような強い攻撃に対しても安全な証明書発行プロトコルが実現できる。
【実施例３】
【０１３７】
実施例１では、detector204がISP管理下に存在した。実施例２では、detector204に相当する機能をCAが有した。本実施例では、実施例１よりもISPとCAの負荷は増えるが、detector204がISP管理下に存在し、強い攻撃に対しても実施例２と同様に安全な方法を説明する。
【０１３８】
実施例２で説明した攻撃は、匿名公開鍵証明書要求パケットを攻撃者がCA201に送ることが可能で、CA201がその正当性を確認しないために成立した。実施例２では、正当性の確認の代わりエンド・エンティティとCAの間でIPsec通信を行い、CA201のデータベースで重複チェックを行った。
【０１３９】
本実施例では、正当性を確認するために、ISPとCAの間でIPsec通信を行う。これにより、CAは特定のISPとしか通信できないので、攻撃者が匿名公開鍵証明書要求パケットを送りつけることができなくなり、CA201がデータベースで重複チェックを行う必要もなくなる。
【０１４０】
この場合、次のようなプロトコルになる。環境や前提は実施例１と同様とする。図５を参照して説明する。
【０１４１】
図２のISPコア・ネットワーク203とCA201の間をIPsec通信とする。例えば、事前に公開鍵証明書を交換しておけばIKEを用いて自動的にIPsec通信が行える。図５では、便宜上detector204をISPコア・ネットワークとみなしている。
【０１４２】
ステップS500においてdetector204とCA201の間でIPsec通信を確立する。以後のプロトコル(ステップS501からステップS512)は、実施例１(ステップS101からステップS112)と同じである。例えば、detector204は、ステップS506において、ユーザ管理下の装置であるホスト210が公開鍵証明書発行装置CA201に送る使い捨て匿名公開鍵証明書の発行要求パケットCRを監視し、その送信元アドレスに含まれる匿名アドレスを記録し、ステップS506において、その発行要求パケットCRをネットワーク・インターフェイス301から公開鍵証明書発行装置CA201に転送する。同じ匿名アドレスを送信元アドレスとする異なる発行要求パケットCRが公開鍵証明書発行装置CA201に送られる場合は、その(２つ目以降の)パケットを公開鍵証明書発行装置CA201に転送しない。
【０１４３】
さらに、detector204は、公開鍵証明書発行装置CA201からユーザ管理下に向けて送られる匿名公開鍵証明書発行パケットCMを監視し(ネットワーク・インターフェイス301で受信する)、同じ匿名アドレス宛に異なる匿名公開鍵証明書発行パケットCMが送られる場合、そのパケットをネットワーク・インターフェイス302からの転送は、行わない。また、detector204は、受信した公開鍵証明書発行パケットCMの宛先アドレスが、過去に受信あるいは転送した公開鍵証明書要求パケットCRの送信元アドレスに一致しない場合、その公開鍵証明書発行パケットCMを遮断する。
【０１４４】
すなわち、本実施例では、遮断装置であるdetector204がテンポラリアドレス(匿名アドレス)を使用するユーザ管理下のIPv6装置(ホスト210)と公開鍵証明書発行装置CA201間の全ての通信を把握できる位置に設けられている。detector204は、ネットワーク・インターフェイス301を用いて、公開鍵証明書発行装置CA201との間でIPsec通信を行い、テンポラリアドレスを使用するユーザ管理下のIPv6装置(ホスト210)からテンポラリアドレスを含む証明書要求パケットCRが公開鍵証明書発行装置CA201に送られる際に、detector204のCPU303が、ステップS506において、パケットCRの送信元アドレスを監視して同一の送信元アドレスを持つ異なる証明書要求パケットを遮断する。公開鍵証明書発行装置CA201は、証明書要求パケットCRに含まれるテンポラリアドレスと証明書要求パケットCRの送信元アドレスが一致していることを確認してテンポラリアドレス宛に証明書を発行する。
【０１４５】
detector204のCPU303は、HD306またはROM304に格納されたプログラムを読み出して処理することにより、以上のような動作を行う。
【図面の簡単な説明】
【０１４６】
【図１】実施例１における匿名公開鍵証明書発行プロトコル図である。
【図２】想定ネットワークの模式図である。
【図３】ノードの構成図である。
【図４】実施例２における匿名公開鍵証明書発行プロトコル図である。
【図５】実施例３における匿名公開鍵証明書発行プロトコル図である。
【符号の説明】
【０１４７】
２０６  ＩＳＰ管理のネットワーク
２１６  ユーザ管理下のネットワーク
【図１】
2005191646.tif 000003
【図２】
2005191646.tif 000004
【図３】
2005191646.tif 000005
【図４】
2005191646.tif 000006
【図５】
2005191646.tif 000007