JP2007166552A - 通信装置及び暗号通信方法 - Google Patents

Abstract

【課題】ＣＧＡによる暗号通信と、身元確認を行っての暗号通信とを可能にすることを目的とする。
【解決手段】ネットワークを介して通信を行う通信装置であって、ネットワークを介して接続された他の通信装置に対して、暗号的に生成されたアドレスに対応する公開鍵を証明対象とする匿名公開鍵証明書の発行要求を送信する発行要求送信手段と、発行要求に応じて発行された匿名公開鍵証明書を、他の通信装置より受信する証明書受信手段と、アドレスに基づいて暗号通信を行う第一の暗号通信手段と、匿名公開鍵証明書に基づいて暗号通信を行う第二の暗号通信手段と、を有することによって上記課題を解決する。
【選択図】図１０

Description

本発明は、通信装置及び暗号通信方法に関する。

ＩＰｖ６の登場により、従来はネットワークに接続することが考えられなかった装置がネットワークに接続する場面が考えられてきた。例えば、インターネットに直接接続可能なエンドユーザ向けのディジタルカメラ等である。

ＩＰｖ６で通信するパーソナル・コンピュータやワークステーションの場合、ネットワークとの接続のインターフェイスには通常はイーサネット（登録商標）が用いられる。

イーサネット（登録商標）では、ＩＥＥＥ ｉｄｅｎｔｉｆｉｅｒ（ＭＡＣ ａｄｄｒｅｓｓ）を元にしてインターフェイスＩＤが生成され、インターフェイスＩＤとｓｕｂｎｅｔ ｐｒｅｆｉｘとからＩＰｖ６アドレスが構成されるようになっている。この構成はＭｏｄｉｆｉｅｄ ＥＵＩ−６４ ｆｏｒｍａｔと呼ばれ、ＲＦＣ３５１３"Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ ６ （ＩＰｖ６） Ａｄｄｒｅｓｓｉｎｇ Ａｒｃｈｉｔｅｃｔｕｒｅ"に定義されている。

ところが、Ｍｏｄｉｆｉｅｄ ＥＵＩ−６４ ｆｏｒｍａｔのＩＰｖ６アドレスのようにハードウェアに１対１で対応する情報を固定的に用いると、それが装置もしくはその装置のユーザと１対１で対応する情報とみなされる。そして、そのアドレスを使う通信をモニターされることによりプライバシが侵害される恐れが強い。

この課題に対して、ランダムなＩＰｖ６アドレスを生成する方法が、ＲＦＣ３０４１"Ｐｒｉｖａｃｙ Ｅｘｔｅｎｓｉｏｎｓ ｆｏｒ Ｓｔａｔｅｌｅｓｓ Ａｄｄｒｅｓｓ Ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎｉｎ ＩＰｖ６"等において定義されている。また、生成したランダムな値が既に使われている場合には、それを検出し、別のランダムな値を計算／生成し、ユニークなランダムな値を定めるプロトコル（の拡張）も記述されている。このランダムな値を用いたアドレスはｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓと呼ばれる。

ここで、ＩＰｖ６で通信する装置が、ＩＰｓｅｃを用いて暗号通信を行なうことを考える。ＩＰｓｅｃは、インターネット上の２つの装置が他の誰も知らない秘密データを共有し、その秘密データに基づいて暗号化や認証を行なうプロトコルであり、通信に際して秘密データやお互いのＩＰｖ６アドレス等を安全に共有する必要がある。

秘密データやお互いのＩＰｖ６アドレス等のデータはＳＡ（Ｓｅｃｕｒｉｔｙ Ａｓｓｏｃｉａｔｉｏｎ）と呼ばれる。ＳＡを安全に共有するプロトコルはＩＫＥ（Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ）と呼ばれ、ＲＦＣ２４０９"Ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｋｅｙ Ｅｘｃｈａｎｇｅ（ＩＫＥ）"において規定されている。ここで、ＳＡを安全に共有するという意味は、意図する相手のみと確実にＳＡを共有するという意味であり、相手を確実に認証することを必要とする。ＩＫＥでは秘密データを共有する方法としてＤｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵配送方式（以下、ＤＨと記す）が使われ、４つの認証方法が規定されている。

一つはｐｒｅ−ｓｈａｒｅｄ ｋｅｙを用いる方法で、残りは公開鍵暗号（暗号化或いはディジタル署名）を用いる方法である。ｐｒｅ−ｓｈａｒｅｄ ｋｅｙは予め送信者と受信者との間で何らかの方法でそのｐｒｅ−ｓｈａｒｅ ｋｅｙを共有しておかなければならないので、不特定多数とＩＫＥを実行してＩＰｓｅｃ通信を行う場合には使えない。公開鍵暗号に基づく認証方法は、公開鍵と、その公開鍵の持ち主との対応関係を保証する公開鍵証明書を用いて通信者の身元の確認を行うので、不特定多数とＩＫＥを実行してＩＰｓｅｃ通信を行う場合に適する。

上述のように、ＩＰｖ６にはｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓと呼ばれるアドレスがあり、プライバシ保護のために使われる。従って、インターネット上での盗聴や改ざんをＩＰｓｅｃで防ぎながら、しかも第三者のみならず通信相手にも身元を隠してＩＰｖ６で通信する方法があれば、従来以上に安全で安心したインターネット通信を実現できる。

ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓを用いて、通信相手にも身元を隠してＩＰｓｅｃを行う方法として、特許文献１や特許文献２がある。

特許文献１及び特許文献２共に、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓを記載した匿名公開鍵証明書を用いてＩＫＥを実行してＩＰｓｅｃ通信を行う方式である。ここで、匿名公開鍵証明書とは、複数の匿名公開鍵証明書の持ち主が同じエンティティ（装置又は装置のユーザ）か否かが第三者には判別困難な証明書であり、証明書の持ち主のプライバシ保護に役立つ（例えば、非特許文献１参照。）。

特許文献１及び特許文献２においては、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓと、公開鍵暗号とを用いて匿名公開鍵証明書の要求と、発行とを行う。よって、あるｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓを本当に使用するエンティティのみが発行された匿名公開鍵証明書を利用して公開鍵暗号を利用でき、匿名にも係らず、なりすましを防ぐことができる。

一方、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓが最初に与えられるという状況とは異なる状況を想定して、公開鍵から計算したｉｎｔｅｒｆａｃｅ ＩＤを用いるＩＰｖ６アドレスが提案されている。これは、装置が生成した公開鍵をハッシュ関数に入力して計算した値をｉｎｔｅｒｆａｃｅ ＩＤとして使う方法である。つまり、公開鍵からＩＰｖ６アドレスを生成するとみなすことができる。この考え方と、その応用とが述べられている文献として、特許文献３、非特許文献２、非特許文献３、非特許文献４がある。

特許文献３の目的は、あるＩＰｖ６アドレスを使うホスト（装置）が、本当にその
ＩＰｖ６アドレスを使うホストであるか否かを確認可能にすることである。

非特許文献２の目的は、Ｍｏｂｉｌｅ ＩＰｖ６において、ＩＰｓｅｃのＡＨを使えない時にｂｉｎｄｉｎｇ ｕｐｄａｔｅｓの一方向的な認証を行うことが目的である。

非特許文献３は、非特許文献２の欠点を補い、より一般的な用途にも使えるよう
に拡張した方式を提案している。

非特許文献４は、ＣＧＡ（Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓ）を用いてＮｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙを安全にするプロトコルを提案している。

以下では、特許文献３、非特許文献２、非特許文献３、非特許文献４で述べられている方式に基づくＩＰｖ６アドレスを総称してＣＧＡ（Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ ＧｅｎｅｒａｔｅｄＡｄｄｒｅｓｓ）と記す。

特開２００４−７５１２号公報 特開２００４−３２６９９号公報 英国特許第２３６７９８６号明細書 Ｋａｚｕｏｍｉ Ｏｉｓｈｉ、Ｍａｓａｈｉｒｏ Ｍａｍｂｏ、Ｅｉｊｉ Ｏｋａｍｏｔｏ"Ａｎｏｎｙｍｏｕｓ Ｐｕｂｌｉｃ Ｋｅｙ Ｃｅｒｔｉｆｉｃａｔｅｓ ａｎｄ ｔｈｅｉｒ Ａｐｐｌｉｃａｔｉｏｎｓ"ＩＥＩＣＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｆｕｎｄａｍｅｎｔａｌｓ ｏｆ Ｅｌｅｃｔｒｏｎｉｃｓ、Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ａｎｄＣｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅｓ、Ｅ８１−Ａ、１、ｐｐ５６−６４、 １９９８． Ｇｒｅｇ Ｏ’Ｓｈｅａ、 Ｍｉｃｈａｅｌ Ｒｏｅ、"Ｃｈｉｌｄ−ｐｒｏｏｆ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｆｏｒ ＭＩＰｖ６（ＣＡＭ）"Ｃｏｍｐｕｔｅｒ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｒｅｖｉｅｗ、 ３１（２）、 Ａｐｒｉｌ ２００１． Ｔｕｏｍａｓ Ａｕｒａ"Ｃｒｙｐｔｏｇｒａｐｈｙｃａｌｌｙ ｇｅｎｅｒａｔｅｄ ａｄｄｒｅｓｓｅｓ （ＣＧＡ）"６ｔｈ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｅｃｕｒｉｔｙ Ｃｏｎｆｅｒｅｎｃｅ（ＩＳＣ'０３）、Ｂｒｉｓｔｏｌ、ＵＫ、Ｏｃｔｏｂｅｒ ２００３． Ｔｕｏｍａｓ Ａｕｒａ"ＡｕｒａＣｒｙｐｔｏｇｒａｐｈｙｃａｌｌｙ ｇｅｎｅｒａｔｅｄ ａｄｄｒｅｓｓｅｓ （ＣＧＡ）"ｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｃｇａ−０６．ｔｘｔ、Ａｐｒｉｌ １６、２００４．

ＣＧＡの特徴の一つは、ＣＡ（Ｃｅｒｔｉｆｉｃａｔｉｏｎ Ａｕｔｈｏｒｉｔｙ）が不要なことである。しかし、これは長所にも短所にもなる。

例えば、不特定多数が利用可能な無線ＬＡＮのアクセスポイントがレストランや図書館のような公共の場に設けられているとする。このような環境では、不特定多数の利用を前提としているのでユーザの身元確認の必要は無いが、ＬＡＮの設備が安全とは限らず、しかも無線で通信するので通信内容の盗聴や改ざんの恐れがあり暗号化や認証（データの改ざん検出）は必要である。更に、ユーザのプライバシの侵害を防ぐために、ＭＡＣ ａｄｄｒｅｓｓから生成されたＭｏｄｉｆｉｅｄＥＵＩ−６４ ｆｏｒｍａｔのＩＰｖ６アドレスを使うのではなく、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓを使う方が望ましい。

このような状況では、安全な通信路を確保する手段としてＣＧＡを用いてインターネット上の通信相手との間で公開鍵暗号に基づく認証（データがＣＧＡから送られたことの確認）を実行して、ＩＫＥ及びＩＰｓｅｃを実行する方法が適していると考えられる。このとき、ＣＡが不要であることは長所とみなせる。

一方、企業や大学のような組織のネットワークにおいてＣＧＡに基づく暗号通信を許可すると、身元の不明な装置或いはユーザでも暗号通信を行えることになる。この場合、ウイルスの配布や違法な通信をそのネットワークを使って行われても、その行為を検出することが困難になるのでネットワークの管理と、セキュリティとの観点から考えると短所になる。このようなネットワークでは、身元が不明な装置はＣＧＡに基づく暗号通信を禁止される場合も考えられる。

本発明は上記の問題点に鑑みなされたもので、ＣＧＡによる暗号通信と、身元確認を行っての暗号通信とを可能にすることを目的とする。

そこで、上記問題を解決するため、本発明は、ネットワークを介して通信を行う通信装置であって、前記ネットワークを介して接続された他の通信装置に対して、暗号的に生成されたアドレスに対応する公開鍵を証明対象とする匿名公開鍵証明書の発行要求を送信する発行要求送信手段と、前記発行要求に応じて発行された前記匿名公開鍵証明書を、前記他の通信装置より受信する証明書受信手段と、前記アドレスに基づいて暗号通信を行う第一の暗号通信手段と、前記匿名公開鍵証明書に基づいて暗号通信を行う第二の暗号通信手段と、を有することを特徴とする。

係る構成とすることにより、暗号的に生成されたアドレス（ＣＧＡ）による暗号通信と、身元確認を行っての暗号通信とを可能にすることができる。

また、上記問題を解決するため、本発明は、暗号通信方法としてもよい。

本発明によれば、ＣＧＡによる暗号通信と、身元確認を行っての暗号通信とを可能にすることができる。

以下、本発明の実施形態について図面に基づいて説明する。

始めに、ＯＧＡについて説明を行う。
ＣＧＡは、ＩＰｖ６アドレスである。そのｉｎｔｅｒｆａｃｅ ＩＤは、公開鍵を含むパラメータをハッシュ関数に入力して計算した値から作られる。

パラメータは、Ｍｏｄｉｆｉｅｒ、Ｓｕｂｎｅｔ Ｐｒｅｆｉｘ、Ｃｏｌｌｉｓｉｏｎ Ｃｏｕｎｔ、Ｐｕｂｌｉｃ Ｋｅｙ、Ｅｘｔｅｎｓｉｏｎ Ｆｉｅｌｄｓからなる。そして、これらを格納する構造体はＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅと呼ばれる。Ｍｏｄｉｆｉｅｒは１２８ビット、Ｓｕｂｎｅｔ Ｐｒｅｆｉｘは６４ビット、Ｃｏｌｌｉｓｉｏｎ Ｃｏｕｎｔは８ビットである。また、Ｐｕｂｌｉｃ Ｋｅｙは可変長、Ｅｘｔｅｎｓｉｏｎ Ｆｉｅｌｄは可変長、Ｅｘｔｅｎｓｉｏｎ Ｆｉｅｌｄｓはオプションである。

ＣＧＡを生成するときは、６４ビットのｓｕｂｎｅｔ ｐｒｅｆｉｘ、ＤＥＲ−ｅｎｃｏｄｅｄ ＡＳＮ．１ ｓｔｒｕｃｔｕｒｅ ｏｆ ｔｈｅ ｔｙｐｅ ＳｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏの公開鍵、セキュリティパラメータＳｅｃを入力値とする。Ｓｅｃは３ビットの整数（０、１、．．．、７）で、ブルートフォースアタックに対する強度を定める。

エンティティは、ＨＡＳＨ２と、ＨＡＳＨ１とを後述するように計算し、ｉｎｔｅｒｆａｃｅ ＩＤが重複しているか否かを検証する。重複していないｉｎｔｅｒｆａｃｅ ＩＤが求められた時、Ｍｏｄｉｆｉｅｒと、Ｃｏｌｌｉｓｉｏｎ Ｃｏｕｎｔとの値が定まる。

図１は、Ｈａｓｈ２の計算方法を模式的に示す図である。
エンティティは、Ｍｏｄｉｆｉｅｒに、１２８ビットの乱数若しくは擬似乱数の値を格納し、Ｓｕｂｎｅｔ Ｐｒｅｆｉｘには６４ビットのゼロを格納する。また、エンティティは、Ｃｏｌｌｉｓｉｏｎ Ｃｏｕｎｔには８ビットのゼロを格納し、Ｐｕｂｌｉｃ ＫｅｙにはＤＥＲ−ｅｎｃｏｄｅｄ ＡＳＮ．１ ｓｔｒｕｃｔｕｒｅ ｏｆ ｔｈｅ ｔｙｐｅ ＳｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏを格納する。

そして、エンティティは、ＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅをＳＨＡ−１に入力して計算し、１６０ビットのハッシュ値を求める。このハッシュ値の最上位１１２ビットがＨａｓｈ２である。

エンティティは、Ｈａｓｈ２の値の最上位１６＊Ｓｅｃビットがゼロか否か比較し、全てゼロ（或いはＳｅｃ＝０）ではないならばＭｏｄｉｆｉｅｒの値を１増加させ、再びＨａｓｈ２を計算する。

エンティティは、最上位１６＊Ｓｅｃビットがゼロになるまで以上の処理を繰り返し、最終のＭｏｄｉｆｉｅｒの値を定める。エンティティは、Ｃｏｌｌｉｓｉｏｎ Ｃｏｕｎｔの値はゼロにする。

図２は、Ｈａｓｈ１の計算方法を模式的に示す図である。

エンティティは、ＭｏｄｉｆｉｅｒにＨａｓｈ２の計算によって求められた最終のＭｏｄｉｆｉｅｒの値を格納する。また、エンティティは、Ｓｕｂｎｅｔ ＰｒｅｆｉｘにＨａｓｈ２の計算によって求められたＳｕｂｎｅｔ Ｐｒｅｆｉｘの値を格納する。また、エンティティは、Ｃｏｌｌｉｓｉｏｎ ＣｏｕｎｔにＨａｓｈ２の計算によって求められた最終のＣｏｌｌｉｓｉｏｎ Ｃｏｕｎｔの値を格納する。また、エンティティは、Ｐｕｂｌｉｃ ＫｅｙにＤＥＲ−ｅｎｃｏｄｅｄ ＡＳＮ．１ ｓｔｒｕｃｔｕｒｅ ｏｆ ｔｈｅ ｔｙｐｅ ＳｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏを格納する。

そして、エンティティは、ＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅをＳＨＡ−１に入力して計算し、１６０ビットのハッシュ値を求める。このハッシュ値の最上位６４ビットがＨａｓｈ１である。エンティティは、Ｈａｓｈ１の最上位３ビットにＳｅｃの値を書き込み、ビット６と、ビット７とを共にゼロにした６４ビットを求める。この６４ビットがｉｎｔｅｒｆａｃｅ ＩＤである。

エンティティは、以上のようにして求めたｉｎｔｅｒｆａｃｅ ＩＤをＳｕｂｎｅｔ Ｐｒｅｆｉｘに付加してＩＰｖ６アドレスを生成する。そして、エンティティは生成したＩＰｖ６アドレスがＬＡＮ内部で重複しているか否かをＤＡＤ（Ｄｕｐｌｉｃａｔｅｄ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ）で検証する。エンティティは、重複している場合は、Ｃｏｌｌｉｓｉｏｎ Ｃｏｕｎｔの値を１増加させ、Ｈａｓｈ１を再計算し、ｉｎｔｅｒｆａｃｅ ＩＤを求める。この処理はＣｏｌｌｉｓｉｏｎ Ｃｏｕｎｔの値が３まで繰り返される。重複していないｉｎｔｅｒｆａｃｅ ＩＤを含むＩＰｖ６アドレスが求められたならば、それがＣＧＡである。求められない場合は、エンティティは、エラーを出力する。

以上のようにして求められたＣＧＡは、対応するＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅと一緒に、エンティティのメモリ等に記録される。ここで、対応するＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅとは、最終のＭｏｄｉｆｉｅｒの値、Ｓｕｂｎｅｔ Ｐｒｅｆｉｘの値、最終のＣｏｌｌｉｓｉｏｎ Ｃｏｕｎｔの値、を含む。また、対応するＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅには、更に公開鍵のＤＥＲ−ｅｎｃｏｄｅｄ ＡＳＮ．１ ｓｔｒｕｃｔｕｒｅ ｏｆ ｔｈｅ ｔｙｐｅ ＳｕｂｊｅｃｔＰｕｂｌｉｃＫｅｙＩｎｆｏが含まれる。

ＣＧＡを使った通信をするときに、ＣＧＡそのものはＩＰパケットのソースアドレスとして用いられる。対応するＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅは、何らかのフォーマットに従って通信相手に伝えられる。

下記に示す非特許文献５には、Ｎｅｉｇｈｂｏｒ ＤｉｓｃｏｖｅｒｙにＣＧＡを応用した場合が提案されている。非特許文献５では、新しいＮＤＰ ｏｐｔｉｏｎとしてＣＧＡ ｏｐｔｉｏｎが定義され、公開鍵と対応するＣＧＡパラメータはＣＧＡ ｏｐｔｉｏｎに入れて通信相手に伝えられるとされている。
（非特許文献５）Ｊ． Ａｒｋｋｏ、 Ｊ． Ｋｅｍｐｆ、 Ｂ． Ｓｏｍｍｅｒｆｅｌｄ、 Ｂ． Ｚｉｌｌ、Ｐ． Ｎｉｋａｎｄｅｒ、"ＳＥｃｕｒｅ Ｎｅｉｇｈｂｏｒ Ｄｉｓｃｏｖｅｒｙ （ＳＥＮＤ）"ｄｒａｆｔ−ｉｅｔｆ−ｓｅｎｄ−ｎｄｏｐｔ−０６．ｔｘｔ、Ｊｕｌｙ １７、２００４．

ＣＧＡの認証は、ＩＰｖ６アドレスと、ＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅとを入力として行われる。認証が成功するとき、その公開鍵がアドレスの使用者の公開鍵であることが確認される。ＣＧＡの認証が成功した後は、その公開鍵を用いてディジタル署名を利用することで、データの偽造や改ざん、使用者へのなりすましを防ぐことができる。

ＣＧＡの認証は以下のように行われる。
エンティティは、ＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅからＣｏｌｌｉｓｉｏｎ Ｃｏｕｎｔの値を取り出し、０、１、２の何れかであることを確認する。Ｃｏｌｌｉｓｉｏｎ Ｃｏｕｎｔの値が、０、１、２の何れでもない場合は認証失敗である。

エンティティは、ＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅからＳｕｂｎｅｔ Ｐｒｅｆｉｘの値を取り出し、ＩＰｖ６アドレスと比較して同じ値であることを確認する。Ｓｕｂｎｅｔ Ｐｒｅｆｉｘの値が、ＩＰｖ６アドレスと異なる場合は、認証失敗である。

エンティティは、ＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅをＳＨＡ−１に入力し、出力からＨａｓｈ１を求める。そして、エンティティは、Ｈａｓｈ１と、ＩＰｖ６アドレスのｉｎｔｅｒｆａｃｅ ＩＤとが同じか否か確認する（但し、最初の３ビットや、ビット６、ビット７の比較は行わない。）。Ｈａｓｈ１と、ＩＰｖ６アドレスのｉｎｔｅｒｆａｃｅ ＩＤとが同じでない場合は認証失敗である。

エンティティは、ｉｎｔｅｒｆａｃｅ ＩＤの最初の３ビットを取り出し、Ｓｅｃの値とする。また、エンティティは、ＣＧＡ Ｐａｒａｍｅｔｅｒｓ ｄａｔａ ｓｔｒｕｃｔｕｒｅのＳｕｂｎｅｔ Ｐｒｅｆｉｘと、Ｃｏｌｌｉｓｉｏｎ Ｃｏｕｎｔとの値をゼロにしたデータをＳＨＡ−１に入力し、出力からＨａｓｈ２を求める。

エンティティは、Ｈａｓｈ２の最初の１６＊Ｓｅｃビットが全てゼロであるか否かを確認する。全てゼロでは無い場合は、認証失敗である。なお、Ｓｅｃの値がゼロの時は、このステップで認証が失敗することは無い。

以上の確認を全て成功した場合、ＣＧＡの認証は成功となる。

あるＣＧＡから送られたデータが本当にそのＣＧＡから送られたデータであるか否かを確認可能にするために、ＣＧＡの使用者（又はエンティティ）はデータに対してディジタル署名を生成する。そして、ＣＧＡの使用者（又はエンティティ）はデータ及び公開鍵を含むＣＧＡのパラメータと、ディジタル署名とをＣＧＡから通信相手に送る。

通信相手はＣＧＡの認証を行い、認証が成功すれば公開鍵がそのＩＰｖ６アドレスの使用者の公開鍵であるとみなす。そして、通信相手は、その公開鍵でデータと、ディジタル署名との対応関係を検証し、検証が成功した場合は、そのデータがそのＩＰｖ６アドレスの使用者からのデータであるとみなす。

次に、ＣＧＡを用いるＩＫＥの説明をする。
ＩＫＥにおいては、通信相手の身元を識別する情報としてＩＰｖ６アドレスを利用することができる。通信相手の身元確認は、ｐｒｅ−ｓｈａｒｅｄ ｋｅｙ或いは公開鍵証明書を用いて行われる。

従って、ディジタル署名を用いる認証方式を採用し、ディジタル署名の公開鍵としてＣＧＡで用いられる公開鍵を使う方法がＣＧＡを用いるＩＫＥの実現方法として考えられる。但し、ＩＫＥはＣＧＡをサポートしているわけではないので、ＣＧＡをサポートするように変更し、且つＣＧＡを公開鍵証明書と関連付ける必要がある。

ＣＧＡと、公開鍵証明書との対応付けの方法の一つとして、自己署名証明書を用いる方法が下記に示す非特許文献６で述べられている。
（非特許文献６）Ｊ． Ｌａｇａｎｉｅｒ、 Ｇ． Ｍｏｎｔｅｎｅｇｒｏ、"Ｕｓｉｎｇ ＩＫＥ ｗｉｔｈ ＩＰｖ６ Ｃｒｙｐｔｏｇｒａｐｈｉｃａｌｌｙ Ｇｅｎｅｒａｔｅｄ Ａｄｄｒｅｓｓ" ｄｒａｆｔ−ｌａｇａｎｉｅｒ−ｉｋｅ−ｉｐｖ６−ｃｇａ−０１、 Ｊｕｎｅ ３０、 ２００３．

自己署名証明書は、公開鍵証明書の持ち主であるエンティティが公開鍵証明書を生成・発行するエンティティを兼ねる場合の公開鍵証明書である。つまり、あるエンティティが自分の公開鍵に対する公開鍵証明書を自分で作る。このとき、公開鍵証明書の検証に用いる公開鍵と、公開鍵証明対象の公開鍵とは同一になる。

ＣＧＡの公開鍵を用いて、ＣＧＡの使用者（ノードＡとする）が自己署名証明書を生成し、ＩＫＥの実行中に通信相手（ノードＢとする）に送る。

ノードＢは、ＩＫＥにおいてＩＤ Ｐａｙｌｏａｄに含められて送られてくるＩＰｖ６アドレスがＣＧＡであるならば（それがＣＧＡであることを示すＩＤ Ｔｙｐｅか否かで判別）ＣＧＡの認証を行い、対応する公開鍵を知る。ＣＧＡの認証が失敗したら、ＩＫＥは中断する。

ノードＢは、送られてきた自己署名証明書がディジタル署名として正しいか否かを、前記公開鍵を用いて確認する。ディジタル署名として正しいことが確認されたならば、ノードＢは、その公開鍵を用いて、ＩＫＥにおける認証データ（ＨＡＳＨ＿Ｉ或いはＨＡＳＨ＿Ｒに対するディジタル署名）の正当性を確認する。

以上の確認が成功したならば、ＣＧＡを用いるＩＫＥにおいてノードＢが通信相手の
身元をＩＰｖ６アドレス（ＣＧＡ）で確認出来たとみなす。

次に、匿名公開鍵証明書を用いたＩＫＥの説明をする。
なお、以下ではホストがイーサネット（登録商標）のＬＡＮ経由でインターネットと接続する場合を説明する。

図３は、本実施形態が適用される接続環境（ホストがイーサネット（登録商標）のＬＡＮ経由でインターネットと接続する環境）を模式的に示した図である。図３は、ＬＡＮに接続されたホスト２０４、２０５、２０６がｄｅｆａｕｌｔ ｇａｔｅｗａｙ（ゲートウェイ）２０２経由でインターネット２０１にアクセスする環境を示している。本実施形態では、各ホストはリンク２０７で接続するものとし、リンク２０７は具体的にはイーサネット（登録商標）であるとする。ここで、リンクとは、それに接続された装置がそれを介して通信することができる設備若しくはメディアであり、ＩＰ層の下側に接する。

リンクにはイーサネット（登録商標）の他に、ＩＥＥＥ８０２．１１ｇやＩＥＥＥ８０２．１１ａ等の所謂無線ＬＡＮ、ＰＰＰリンク、Ｘ．２５、フレームリレー、ＡＴＭネットワークがある。

以下、リンクに接続されたＩＰｖ６対応装置をノードと呼ぶ。図４は、ノードの構成を示す図である。ノードには、ルーターと、ホストとがあり、ルーターは自分宛ではないパケットを転送するがホストは転送しない。図４に示されるように、ノード３００は、ネットワーク・インターフェイス３０１、３０２、ＣＰＵ３０３、ＲＯＭ３０４、ＲＡＭ３０５、ＨＤ（ハードディスク）３０６、電源３０７を含む。また、図４に示されるように、ノード３００は、キーボード／ポインティングデバイス等のインターフェイス３０８、モニター等のインターフェイス３０９、バス３１０等を含む。

ルーターは複数のネットワーク・インターフェイス３０１、３０２を持つのに対し、ホストは多くの場合は一つのネットワーク・インターフェイス３０１を持つ。

ホスト２０４、２０５、２０６は、ネットワーク・インターフェイス３０１により、リンク２０７を介して、リンク２０７に接続された他のノード或いは、更に、ゲートウェイ２０２を介して、インターネット２０１上のサイトと通信する。

ｄｅｆａｕｌｔ ｇａｔｅｗａｙ２０２は、ネットワーク・インターフェイス３０１により、インターネット２０１を介して、ホスト等と通信する。なお、ノードによってはＨＤ３０６やキーボード／ポインティングデバイスのインターフェイス３０８、モニターのインターフェイス３０９を持たないものもある。

なお以下の処理内容（手順）は、プログラム又はモジュールで実現される。例えば、プログラムで実現される場合、ＣＰＵ３０３は、ＲＯＭ３０４又はＨＤ３０６に格納されたプログラムをＲＡＭ３０５上に読み込み、必要に応じてＲＡＭ３０５を計算のためのデータ一時保管空間として利用しながら処理を実行する。また、例えばモジュールで実現される場合、プログラムがＣＰＵやＲＡＭ等と協調して実行する上述の動作と同等の動作を実行する実体が、例えばＬＳＩとして実現され、ノードに組み込まれている。ノードのＣＰＵからモジュール（ＬＳＩ）へ指示が発行され、それをきっかけにモジュールが動作し、処理を実行する。

以下、ノードがアドレスをインターフェイスに割当てる処理を説明する。
始めに、本実施形態のイーサネット（登録商標）ＬＡＮ環境で各ホストがＩＰｖ６グローバルアドレスのプレフィックスやｄｅｆａｕｌｔ ｇａｔｅｗａｙ ２０２のアドレスを取得するプロトコルの仕組みを説明する。

図５は、図３のリンク２０７に接続された図４のノードが、電源を入れられた、或いはリブートされた場合に行なう処理のフローチャートである。なお、この処理はＤＡＤ（Ｄｕｐｌｉｃａｔｅ Ａｄｄｒｅｓｓ Ｄｅｔｅｃｔｉｏｎ）と呼ばれる。

ステップＳ８０１において、ノードは、電源を入れられた或いはリブートされる。ステップＳ８０２において、ノードは、ネットワーク・インターフェイス３０１に割当てられているイーサネット（登録商標）のＭＡＣ ａｄｄｒｅｓｓ（ＭＡＣアドレス）からインターフェイスＩＤを作成する。そして、ノードは、作成したインターフェイスＩＤをｔｅｎｔａｔｉｖｅ ｌｉｎｋ−ｌｏｃａｌ ａｄｄｒｅｓｓ（以下、文書中において、仮リンクローカルアドレス）とする。

次に、その仮リンクローカルアドレスがリンク上で一意か否かを判断するため、ノード（ホスト）３００は以下の処理を行なう。

最初に、ステップＳ８０３において、ノードは、ネットワーク・インターフェイス３０１の初期設定をする。即ち、ノードは、ネットワーク・インターフェイス３０１に、ａｌｌ−ｎｏｄｅｓ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ（ＦＦ０２：：１）を割り当てる。なお、以下、文書中において、ａｌｌ−ｎｏｄｅｓ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓを全ノードマルチキャストアドレスと記す。また、ノードは、ネットワーク・インターフェイス３０１に、その仮リンクローカルアドレスのｓｏｌｉｃｉｔｅｄ−ｎｏｄｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓ（以下、文書中において、要請ノードマルチキャストアドレスと記す）を割当てる。

この結果、ネットワーク・インターフェイス３０１は全ノードマルチキャストアドレス宛のパケットを見つけたときはそれを自分のインターフェイス宛のパケットとして受け取る。またネットワーク・インターフェイス３０１はその仮リンクローカルアドレスの要請ノードマルチキャストアドレス宛のパケットを見つけたときはそれを自分のインターフェイス宛のパケットとして受け取る。

ノードは、上述したように、全ノードマルチキャストアドレスをネットワーク・インターフェイス３０１に割当てる。このことによって、ネットワーク・インターフェイス３０１は、既にその仮リンクローカルアドレスを使っている他のノードからのデータを受信することができる。
また、ノードは、上述したように、その仮リンクローカルアドレスの要請ノードマルチキャストアドレスをネットワーク・インターフェイス３０１に割当てる。このことによって、ネットワーク・インターフェイス３０１は、同じ仮リンクローカルアドレスを同時に使おうとしている他のノードの存在を検出することができる。

仮リンクローカルアドレスの要請ノードマルチキャストアドレスとは、ｌｉｎｋ−ｌｏｃａｌ ｓｃｏｐｅ ｍｕｌｔｉｃａｓｔ ａｄｄｒｅｓｓである。つまり、ＲＦＣ２４６１のｐａｇｅ ９１に定義されているように、仮リンクローカルアドレスの下位２４ビットをプレフィックスＦＦ０２：０：０：０：０：１：ＦＦ００：：／１０４に付加したデータである。

次に、ステップＳ８０４において、ノードは、各パラメータに以下の値を設定し、Ｎｅｉｇｈｂｏｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅ（以下、文書中において、ＮＳメッセージと記す）を作成する。
つまり、ノードは、ターゲット アドレス（Ｔａｒｇｅｔ Ａｄｄｒｅｓｓ）に判断対象の仮リンクローカルアドレスを設定する。また、ノードは、ＩＰ Ｓｏｕｒｃｅ（送信元アドレス）にｕｎｓｐｅｃｉｆｉｅｄ ａｄｄｒｅｓｓ（１２８ビット全てが０）を設定する。また、ノードは、ＩＰ ｄｅｓｔｉｎａｔｉｏｎ（宛先アドレス）に判断対象の仮リンクローカルアドレスの要請ノードマルチキャストアドレスを設定する。

ノードは、このようにして作成したＮＳメッセージをＲｅｔｒａｎｓＴｉｍｅｒミリセカンド間隔で、ＤｕｐＡｄｄｒＤｅｔｅｃｔＴｒａｎｓｍｉｔｓ個、リンク２０７に送出する。

ＮＳメッセージを受け取ったノードは、その送信元アドレスがｕｎｓｐｅｃｉｆｉｅｄ ａｄｄｒｅｓｓならば、そのメッセージを、ＤＡＤを行っているノードからのデータであると判断する。

同時に複数のノードが同じアドレスを対象としてＤＡＤをしている場合、その仮リンクローカルアドレスの要請ノードマルチキャストアドレスを割当てられた複数のノードは、同じアドレスをターゲットアドレスに含む複数のＮＳメッセージを受け取る。

ノードは、自分が送ったＮＳメッセージと同じＮＳメッセージを同じアドレスを対象としてＤＡＤをしている他のノードより受け取るので、重複していることがわかる。このような場合、どのノードもそのアドレスは使わない。

なお、受け取ったＮＳメッセージが、自分が送ったものであるならば、他にそれを使っている或いは使おうとしているノードが存在することを示さない。ノードは、自分が送ったＮＳメッセージに加えて、同じアドレスをターゲットアドレスに含むＮＳメッセージを受け取る。このような場合、ノードは、同時に複数のノードが同じアドレスを対象としてＤＡＤをしていると判断する。

ＮＳメッセージを受け取ったノードが、そのメッセージのターゲットアドレスに含まれるアドレスを既に使っていれば、ターゲットアドレスにその仮リンクローカルアドレスが設定されたマルチキャストＮＡメッセージを全ノードマルチキャストアドレス宛に返す。ここで、ＮＡメッセージとは、Ｎｅｉｇｈｂｏｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ ｍｅｓｓａｇｅの略である。

従って、ＮＳメッセージを送ったノードが、全ノードマルチキャストアドレス宛のマルチキャストＮＡメッセージを受け取る。そして、そのターゲットアドレスが判断対象の仮リンクローカルアドレスである場合（Ｓ８０５ステップの「はい」の場合）、ノードは、判断対象の仮リンクローカルアドレスが唯一ではない、つまり重複している、ことがわかる。

以上のＤＡＤの結果、判断対象の仮リンクローカルアドレスがリンク上で唯一であることが確認された（Ｓ８０５ステップの「いいえ」の場合）ならば、ノードは、そのアドレスをリンクローカルアドレスとしてネットワーク・インターフェイス３０１に割当てる。これが図５のステップＳ８０６である。以上でＤＡＤは終了する。

以上に説明した図５の動作は、ノードであるゲートウェイ２０２、ＤＨＣＰ ｓｅｒｖｅｒ２０３、ホスト２０４、ホスト２０５、ホスト２０６のそれぞれが、リンク２０７を収容するネットワーク・インターフェイス３０１について、実行することができる。

ホスト、例えばホスト２０６は、リンクローカルアドレスをネットワーク・インターフェイス３０１に割当てたら、次はグローバルアドレスを決定するために必要な情報をゲートウェイ２０２から入手することを試みる。この動作を図６に示す。ここで、グローバルアドレスを決定するために必要な情報は、Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ ｍｅｓｓａｇｅ（以下、文書中において、ＲＡメッセージと記す）と呼ばれる。

ゲートウェイ２０２は通常はルーターと呼ばれるので以下ではルーター２０２と記す。ルーター２０２は管理者によって必要な設定が行われ、ＲＡメッセージを定期的にリンク２０７に送っている。ホスト２０６がＲＡメッセージを早く入手したい場合は、Ｒｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎ ｍｅｓｓａｇｅ（以下、文書中において、ＲＳメッセージと記す）と呼ばれるデータをルーター２０２に送る。

なお、ホスト２０６はリンクローカルアドレスを割当てた直後にはルーター２０２の存在はわからないので、実際にはＲＳメッセージはリンク２０７上のルーター全てに対するマルチキャストとして送られる。ステップＳ９０１はこの処理を示す。

ＲＳメッセージを受け取ったルーター２０２は、ＲＡメッセージを送る。ステップＳ９０２の「はい」の場合に示すように、ｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎのみを指定するＲＡメッセージを受け取ったホスト２０６は、ステップＳ９０３に進む。なお、以下、文書中において、ｓｔａｔｅｌｅｓｓ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎは、ステートレスアドレス自動設定と記す。

ホスト２０６は、受け取ったメッセージ中のプレフィックスの有効性（既にその装置によって使われていないこと等）を確認し、それ（ら）に適当なインターフェイスＩＤを付加して作ったアドレスをグローバルアドレスとする。そして、ホスト２０６は、このグローバルアドレスをネットワーク・インターフェイス３０１に割当てる。ステップＳ９０３がこの処理である。

ステップＳ９０２の「いいえ」の場合に示すように、ホスト２０６がステートレスアドレス自動設定のみを指定するＲＡメッセージを受け取らなかった場合、ステップＳ９０４に進む。

ステップＳ９０４において、ステートレスアドレス自動設定と、ステートフルアドレス自動設定との両方を指定するＲＡメッセージを受け取った場合（ステップＳ９０４の「はい」の場合）、ホスト２０６は、ステップＳ９０５に進む。ここで、ステートフルアドレス自動設定とは、ｓｔａｔｅｆｕｌ ａｄｄｒｅｓｓ ａｕｔｏｃｏｎｆｉｇｕｒａｔｉｏｎと同一である。

一方、ステップＳ９０４において、ＲＡメッセージを何も受け取らなかった場合（ステップＳ９０４の「いいえ」）、ホスト２０６は、ステップＳ９０６に進む。ステップＳ９０６において、ホスト２０６は、ステートフルアドレス自動設定、即ちＤＨＣＰｖ６のみを実行する。これがステップＳ９０６であり、詳細を図７に示す。

ＤＨＣＰサーバー２０３は管理者によって必要な設定が行われている。即ち、ノードとして自分のリンクローカルアドレスをネットワーク・インターフェイス３０１に割当ててあり、ＤＨＣＰサーバーとして振る舞うために必要なサイトローカルアドレス若しくはグローバルアドレスのためのプレフィックス等が設定されている。

図７のステップＳ１００１において、ホスト２０６は、ＤＨＣＰサーバー２０３にＤＨＣＰ Ｓｏｌｉｃｉｔ Ｍｅｓｓａｇｅを送る。ホスト２０６は、どこにＤＨＣＰサーバー２０３が存在するのかわからないのでＤＨＣＰサーバー２０３に対するマルチキャストとしてリンク２０７に送出する。ホスト２０６の接続されているリンク２０７とは異なるリンク（図示せず）にＤＨＣＰサーバー２０３が存在する場合は、ＤＨＣＰ Ｓｏｌｉｃｉｔ Ｍｅｓｓａｇｅは、実際はＤＨＣＰリレー（図示せず）によって中継されてＤＨＣＰサーバー２０３に届く。

ＤＨＣＰ Ｓｏｌｉｃｉｔ Ｍｅｓｓａｇｅを受け取ったＤＨＣＰサーバー２０３はそれに対する返答としてＤＨＣＰ Ａｄｖｅｒｔｉｓｅ Ｍｅｓｓａｇｅをホスト２０６に返す。ＤＨＣＰ Ａｄｖｅｒｔｉｓｅ Ｍｅｓｓａｇｅは、（別リンクの場合はＤＨＣＰリレーによって中継されて）、ホスト２０６に届く。これがステップＳ１００２である。この時点でホスト２０６は、ＤＨＣＰサーバー２０３のアドレスがわかる。

次にステップＳ１００３においてホスト２０６は ＤＨＣＰ Ｒｅｑｕｅｓｔ ＭｅｓｓａｇｅをＤＨＣＰサーバー２０３に送る。ＤＨＣＰサーバー２０３はＤＨＣＰ Ｒｅｑｕｅｓｔ Ｍｅｓｓａｇｅを受け取ると、ＤＨＣＰ ＲｅｐｌｙＭｅｓｓａｇｅをホスト２０６に送る。

ステップＳ１００４において、ホスト２０６は、ＤＨＣＰ Ｒｅｐｌｙ Ｍｅｓｓａｇｅを受け取る。ステップＳ１００５において、ホスト２０６は、ＤＨＣＰ Ｒｅｐｌｙ Ｍｅｓｓａｇｅからグローバルアドレスを決め、グローバルアドレスの中のインターフェイスＩＤが重複しているか否かを確認するために、ＤＡＤ処理に必要な処理を行なう。つまり、ホスト２０６は、図５のステップＳ８０３と同様に、ネットワーク・インターフェイス３０１にマルチキャストアドレス等を設定する。

ステップＳ１００６において、ホスト２０６は、図５のステップＳ８０４と同様、ＮＳメッセージを送信する。ステップＳ１００７において、ホスト２０６は、図５のステップＳ８０５と同様、ＮＡメッセージを受信したか否かを判定する。

ホスト２０６は、ＮＡメッセージを受信した場合は、そのアドレスが重複しているので、別のアドレスをＤＨＣＰサーバー２０３から受け取るためにステップＳ１００３に戻る。一方、ホスト２０６は、ＮＡメッセージを受信しなかった場合は、そのアドレスは重複していないので、ＤＨＣＰ Ｒｅｐｌｙ Ｍｅｓｓａｇｅから決めたグローバルアドレスをステップＳ１００８において、ネットワーク・インターフェイス３０１に割当てる。

以上で図６のステップＳ９０６における処理が終了する。つまり、図６のステップＳ９０４においてＲＡメッセージを何も受け取らなかった場合はこれで正常終了する。

一方、図６のステップＳ９０５において、ホスト２０６は、ステートレスアドレス自動設定と、ステートフルアドレス自動設定と、の両方を行なう。処理内容はステップＳ９０３及びステップＳ９０６と同じである。

以上のようにして、イーサネット（登録商標）２０７をインターフェイスとして持つホスト２０６は、ステートレスアドレス自動設定と、ステートフルアドレス自動設定（ＤＨＣＰｖ６）と、を任意の組み合わせで適用する。そして、ホスト２０６は、リンクローカルアドレス、グローバルアドレス、ｄｅｆａｕｌｔ ｇａｔｅｗａｙ等を自動設定することができる。

上述したように、ホスト２０６は、インターフェイスＩＤにランダムな値を用いて、その値を対象にしてＤＡＤを行ない、リンク２０７における一意性を確認する。よって、ゲートウェイ２０２或いはＤＨＣＰサーバー２０３から得たグローバルアドレスのプレフィックスと組み合わせて使い捨てのＩＰｖ６グローバルアドレスを利用することができる。なお、ＣＧＡの場合は、Ｈａｓｈ１の上位６４ビットがインターフェイスＩＤに利用される。

次に、上述した動作（プロトコル）を拡張して、使い捨て匿名公開鍵証明書を利用可能にするプロトコルを説明する。最初に、匿名公開鍵証明書の例を説明し、次にそれを効率的に発行するためのプロトコルを説明する。

匿名公開鍵証明書を発行するエンティティＣＡは、共通のパラメータとして大きな素数ｐと、ｑとを定める。なお、素数ｑは、ｐ−１を割りきることができる素数である。エンティティＣＡは、オーダーｑの生成元ｇと、ハッシュ関数Ｈとを定める。

エンティティＣＡは、秘密の乱数ｓ＿ｃａ（１以上ｑ以下）を生成し、ｖ＿ｃａ＝ｇ＾（ｓ＿ｃａ）ｍｏｄ ｐを計算する。ここで、Ａ＝（Ｂ）＾（Ｃ）ｍｏｄ Ｄは、整数Ａ、Ｂ、Ｃ、Ｄに対して、ＢをＣ乗した値をＤで割り、その剰余をＡとする計算を表す。エンティティＣＡは、ｐと、ｑと、ｇと、Ｈと、ｖ＿ｃａと、を公開する。

一方、匿名公開鍵証明書を利用するエンティティｉは、秘密の乱数ｓ＿ｉ（１以上ｑ以下）を生成し、ｖ＿ｉ＝ｇ＾（ｓ＿ｉ） ｍｏｄ ｐを計算する。ｓ＿ｃａや、ｓ＿ｉを秘密鍵、ｖ＿ｃａや、ｖ＿ｉ及び公開のパラメータを公開鍵と呼ぶ。エンティティＣＡは、秘密鍵ｓ＿ｃａを自分以外の誰にも知られないように、例えばハードディスク等に格納し、管理する。また、エンティティｉは、秘密鍵ｖ＿ｉを自分以外の誰にも知られないように、例えばハードディスク等に格納し、管理する。

上述した特許文献１或いは特許文献２の方法では、エンティティは最初に、匿名公開鍵証明書を発行するエンティティＣＡに身元を登録する。例えば、エンティティｉは、匿名公開鍵証明書を利用開始する際に、自分のエンティティ名（ユーザ名）と、パスワードと、公開鍵ｖ＿ｉとをエンティティＣＡに登録する。エンティティＣＡは、必要に応じてエンティティｉの身元を物理的手段等で確認し、提示されたエンティティ名（ユーザ名）と、パスワードと、公開鍵ｖ＿ｉとを記憶する。

しかし、エンティティの身元確認の方法は本実施形態に特有の事柄ではないので、本実施形態では、何らかの手段によってエンティティの身元を確認可能で、身元が確認されたエンティティはその公開鍵をエンティティＣＡに登録しているものと仮定する。

匿名公開鍵証明書を発行する際、エンティティＣＡは、乱数ｒ（１以上ｑ以下）を生成し、（ｇ'、ｖ＿ｉ'）＝（ｇ＾ｒ ｍｏｄ ｐ、 （ｖ＿ｉ）＾（ｒ） ｍｏｄ ｐ）を計算する。エンティティＣＡは上述の公開鍵や、この匿名公開鍵証明書の有効期限、及び公開鍵ｖ＿ｃａに対する後述する公開鍵証明書等の証明書の管理・属性情報をＸとし、（ｇ'、ｖ＿ｉ'）と、Ｘとを含むメッセージ（のハッシュ値）に対してディジタル署名を生成する。

エンティティＣＡは、離散対数問題に基づくディジタル署名方式、例えば、ＤＳＡ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｔｕｒｅ Ａｌｇｏｒｉｔｈｍ）署名方式を使うことができる。本実施形態では、エンティティＣＡは、秘密鍵ｓ＿ｃａを用いるものとする。このディジタル署名をＳｉｇ＿ｃａ（ｇ'、ｖ＿ｉ'、Ｘ）と記す。

エンティティｉに対してエンティティＣＡが発行する匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、ＡＰＣ＿ｃａ（ｉ）＝（ｇ'、ｖ＿ｉ'、Ｘ、Ｓｉｇ＿ｃａ（ｇ'、ｖ＿ｉ'、Ｘ））である。

匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）＝（ｇ'、ｖ＿ｉ'、Ｘ、Ｓｉｇ＿ｃａ（ｇ'、ｖ＿ｉ'、Ｘ））の発行を受けたエンティティｉは、その中から（ｇ'、ｖ＿ｉ'、Ｘ）を取り出す。そして、エンティティｉは、そのハッシュ値（例えば、Ｈ（ｇ'｜ｖ＿ｉ'｜Ｘ）、但し ｜ は連接を示す）を計算し、Ｓｉｇ＿ｃａ（ｇ'、ｖ＿ｉ'、Ｘ）がハッシュ値に対する正しいディジタル署名であるか否かを、公開鍵ｖ＿ｃａを用いて確認する。

正しいディジタル署名であると確認できると、エンティティｉは、公開鍵であるｇ'と、ｖ＿ｉ'と、共通のパラメータｐとを用いて離散対数問題に基づく公開鍵暗号の暗号化やディジタル署名の検証を行なう。

なお、公開鍵ｖ＿ｃａそのものの正当性の確認は、より上位若しくはより普及しているエンティティＣＡに公開鍵ｖ＿ｃａを提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらえば、それを用いて確認できる。

匿名公開鍵証明書の管理・属性情報をＸは、公開鍵ｖ＿ｃａに対する公開鍵証明書を含む。この公開鍵ｖ＿ｃａに対する公開鍵証明書を用いて、公開鍵ｖ＿ｃａそのものの正当性を確認することができる。これは、エンティティＣＡを階層的に構築することに相当し、順当なＰＫＩ（Ｐｕｂｌｉｃ−ｋｅｙＩｎｆｒａｓｔｒｕｃｔｕｒｅ）を構成することもできる。

なお、上記の説明では乗法群（ｍｏｄ ｐ）上の離散対数問題の困難性に基づく署名方式を説明したが、楕円曲線上の離散対数問題の困難性に基づく署名方式を適用することも可能である。この場合、乗法群の場合よりも少ないビット数の鍵で同じ程度の安全性が見込まれるので、より効率がよくなる。

以上の匿名公開鍵証明書方式を、図２の環境に適用する場合を説明する。なお、インターネット２０１を介して通信可能なノード２０９を、匿名公開鍵証明書を発行するエンティティＣＡ、ホスト２０６（若しくはそれを利用するユーザ）を、匿名公開鍵証明書を利用するエンティティｉとする。

以下では、ＩＰｖ６装置（ホスト２０６）がエンティティｉである場合、その装置には公開鍵証明書が格納され安全に利用可能になっているとする。或いはホスト２０６の使用者であって日本国の住民基本台帳カードのような個人向け公開鍵証明書と、その実行プラットフォームを有するユーザとがエンティティｉである場合、実行プラットフォームをホスト２０６が安全に利用可能になっているものとする。従って、装置若しくはそれを利用するユーザの何れかエンティティｉ自身であるかは特に区別せず、単にエンティティｉと記す。

ゲートウェイ２０２は、ホスト２０６に、ＩＰｖ６のグローバルアドレスのプレフィックスを提供する。上述のように、ゲートウェイ２０２は多くの場合ルーターなので、ルーター２０２と呼ぶことにする。

ノード２０９（エンティティＣＡ）の管理者は、上述の公開パラメータｐ、ｇ等を定め、公開する。例えば、ノード２０９の管理者は、匿名公開鍵証明書を発行するエンティティＣＡとしての公開鍵ｖ＿ｃａを定め、必要であれば、より上位若しくはより普及しているＣＡ等に提出して、公開鍵ｖ＿ｃａに対する公開鍵証明書を発行してもらう。

エンティティｉは匿名公開鍵証明書を要求するときは、公開されているパラメータｐ、ｇ等を用いて、自分の秘密鍵ｓ＿ｉを生成し、対応する公開鍵ｖ＿ｉを計算して、エンティティ名と、公開鍵ｖ＿ｉとをノード２０９に提出する。

ノード２０９は、その運用方針に応じてエンティティｉの身元確認を行なう。ノード２０９は、例えば、公開鍵証明書に基づく認証プロトコルを実行することで、エンティティ名が正しいか否かを確認でき、そのエンティティの公開鍵が識別できる。

また、エンティティｉが提出した公開鍵ｖ＿ｉが本当にエンティティｉによって提出された公開鍵であるか否かは、公開鍵証明書を用いて公開鍵ｖ＿ｉに対するディジタル署名をエンティティｉが生成し、ｖ＿ｉと一緒に提出することでノード２０９は確認できる。

上記のエンティティ名と、公開鍵ｖ＿ｉとの正当性を確認したら、ノード２０９（エンティティＣＡ）の管理者は、エンティティ名を検索キーとして公開鍵ｖ＿ｉが検索できるように、ＲＡＭ３０４若しくはＨＤ３０６に登録してもよい。公開パラメータｐ、ｇ等や公開鍵ｖ＿ｉ、特に秘密鍵ｓ＿ｉはエンティティｉが管理し、ホスト２０６で安全に利用可能になっているものとする。

以上の準備を行なった上で実行される公開鍵証明書発行プロトコルの一般形を図８に示す。図８は、匿名公開鍵証明書を利用するエンティティｉがホスト２０６、匿名公開鍵証明書を発行するＣＡがノード２０９であり、それらの間で行なわれる匿名公開鍵証明書の発行プロトコルである。

匿名公開鍵証明書を発行するためにはエンティティを特定する必要があるので、ノード２０９（エンティティＣＡ）と、エンティティｉ（この場合は、ホスト２０６）との間でなんらかの特定（認証）プロトコルを実行する。本実施形態では、以下のような公開鍵暗号に基づく方式を例として説明する。図８の流れに沿って動作を説明する。

ホスト２０６は、ステップＳ１６０１でＲｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎ拡張を送る。ＲｏｕｔｅｒＳｏｌｉｃｉｔａｔｉｏｎ拡張にはノード２０９（エンティティＣＡ）のアドレスを要求するメッセージが含まれる。

Ｒｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎ拡張を受け取ったルーター２０２はステップＳ１６０２でＲｏｕｔｅｒＡｄｖｅｒｔｉｓｅｍｅｎｔ拡張を送る。Ｒｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ拡張にはノード２０９（エンティティＣＡ）のアドレスが含まれる。

なお、ルーター２０２にはノード２０９（エンティティＣＡ）のＩＰアドレスが予め設定されているものとする。企業や大学の場合であればルーター２０２がしかるべき管理者によって管理されているので、その管理者がノード２０９（エンティティＣＡ）のＩＰアドレスを設定すると仮定することは現実的である。

ルーター２０２が仮定で使われている場合、例えばＩＳＰと契約してＡＤＳＬでインターネットに接続する場合、ルーター２０２にＩＳＰ側のルーターが情報を設定することが可能である。例えば、ＤＨＣＰ−ＰＤ（ＤＨＣＰ Ｐｒｅｆｉｘ Ｄｅｌｅｇａｔｉｏｎ）が使える。そのような機能を用いてノード２０９（エンティティＣＡ）のＩＰアドレスが設定されると仮定することも現実的である。

ホスト２０６は、ステップＳ１６０３で、ｐｕｂｌｉｃ ａｄｄｒｅｓｓ（ＭＡＣ ａｄｄｒｅｓｓから生成されたＭｏｄｉｆｉｅｄ ＥＵＩ−６４ ｆｏｒｍａｔのグローバルアドレス）を生成する。また、ホスト２０６は、ステップＳ１６０３で、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓを生成する。そして、ホスト２０６は、ノード２０９（エンティティＣＡ）のアドレスを取得する。

ホスト２０６はステップＳ１６０４で、匿名公開鍵証明書を要求するメッセージである、Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎを生成する。ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎを、匿名公開鍵証明書を要求する旨と、ホスト２０６のＩＰｖ６アドレスとを含むデータであることをノード２０９（エンティティＣＡ）が理解できる形式で生成する。

Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎの内容は、エンティティ名（ユーザ名、装置名、型番、装置シリアル番号等）と、証明書のシリアル番号と、登録した公開鍵ｖ＿ｉとから計算される。なお、公開鍵ｖ＿ｉがノード２０９（エンティティＣＡ）に記録されている場合はｖ＿ｉを含めなくてもよい。証明書のシリアル番号は、例えば、ホスト２０６のｐｕｂｌｉｃ ａｄｄｒｅｓｓ或いは、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓ、或いはＣＧＡと、そのときの時刻と、を連接して一つのデータにした値である。一度だけ使われるカウンタ値を時刻の代わりに使ってもよいが、最後に使われたカウンタ値をエンティティ２０９（ＣＡ）が記録する必要がある。

再送攻撃や、なりすましを防ぐために、秘密鍵を用いて、エンティティ名と、証明書のシリアル番号とをハッシュ関数に入力した値に対して生成したディジタル署名が、Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるのが望ましい。ここで、ディジタル署名は、認証用ｓｉｇｎａｔｕｒｅであり、例えば、Ｓｉｇ＿ｉ（ｈａｓｈ（エンティティ名、パスワード、シリアル番号））である。

次に、ホスト２０６は、Ｃｅｒｔｉｆｉｃａｔｅ ＳｏｌｉｃｉｔａｔｉｏｎをステップＳ１６０５でノード２０９に送る。

ステップＳ１６０６で、ノード２０９は、ステップＳ１６０５で受け取ったＣｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎに含まれる公開鍵を取り出す。或いはノード２０９は、Ｃｅｒｔｉｆｉｃａｔｅ Ｓｏｌｉｃｉｔａｔｉｏｎに含まれるエンティティ名を検索語として、登録された公開鍵ｖ＿ｉをＲＡＭ３０５若しくはＨＤ３０６から検索し、公開鍵を取得する。

そして、ノード２０９は、公開鍵ｖ＿ｉを用いて認証用ｓｉｇｎａｔｕｒｅの正当性を確認する。より具体的に説明すると、ノード２０９は、エンティティ名と証明書のシリアル番号をハッシュ関数の入力とし、そのハッシュ値を求め、認証用ｓｉｇｎａｔｕｒｅがそれに対する正しいディジタル署名であることを公開鍵ｖ＿ｉで確認する。

認証が成功したら、ノード２０９は、ライフタイム（使用期限、例えば２４時間）等を含む匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を作成する。より具体的に説明すると、上述のＡＰＣ＿ｃａ（ｉ）＝（ｇ'、ｖ＿ｉ'、Ｘ、Ｓｉｇ＿ｃａ（ｇ'、ｖ＿ｉ'、Ｘ））の中の証明書の管理・属性情報Ｘの中にＩＰｖ６アドレスやライフタイム等が含まれる。なお、ＩＰｖ６アドレスのライフタイム（使用期限）と、匿名公開鍵証明書の有効期限とは同じとは限らない。

そして、ステップＳ１６０７でノード２０９は、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を含むＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔを、認証されたホスト２０６に送る。本実施形態では、ノード２０９は、このＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔを登録された公開鍵を用いて暗号化して、送信する。

ステップＳ１６０８において、ホスト２０６は、受け取ったＣｅｒｔｉｆｉｃａｔｅ Ａｄｖｅｒｔｉｓｅｍｅｎｔから匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）を取り出し、その正当性を確認する。このように、匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）は、その管理・属性情報Ｘ中に有効期限を含む。匿名公開鍵証明書ＡＰＣ＿ｃａ（ｉ）に含まれる公開鍵ｇ'と、ｖ＿ｉ'とは、同一のエンティティｉ（ホスト２０６）の公開鍵であるが、時間の経過に伴い変更される公開鍵である。

ホスト２０６は、通信相手が変る度に、或いは、セッションが変る毎に、若しくは、通信パケットの送信毎に、図８の匿名公開鍵発行プロトコルを実行し、使用する公開鍵ｇ'と、ｖ＿ｉ'とを変更する。

以上のプロトコルと、既存のステートレスアドレス自動設定及びステートフルアドレス自動設定とを組み合わせた拡張プロトコルのホストの動作フローチャートが図９である。ホスト２０６は、ステップＳ１７０１において、図６のステップ９０１で送られるＲＳメッセージの代わりにＲｏｕｔｅｒ Ｓｏｌｉｃｉｔａｔｉｏｎ拡張を送る。

また、ホスト２０６は、ステップＳ１７０２で、図６のステップＳ９０２で受け取るＲＡメッセージの代わりにＲｏｕｔｅｒ Ａｄｖｅｒｔｉｓｅｍｅｎｔ拡張を受け取る。

ステップＳ１７０３からステップＳ１７０６までの処理は、図６に示したステップＳ９０３からステップＳ９０６までの処理と同様のため、説明を省略する。

ステップＳ１７０７において、ホスト２０６は、図８に示したプロトコルを実行する。

以上が、匿名公開鍵証明書の発行プロトコルの一般形である。

本実施形態の特徴は、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓの代わりにＣＧＡを対象とする匿名公開鍵証明書が要求・発行されること、ＣＧＡ候補の生成が代理計算されることである。また、本実施形態の特徴は、ＣＧＡ候補が重複しないことが確認されたならばそのＣＧＡを用いて匿名公開鍵証明書を要求すること、ＣＧＡを用いる通信を検出・禁止すること、ＣＧＡと、匿名公開鍵証明書とを適応的に選択してＩＫＥを実行することである。

以下では、エンティティＣＡによって代理計算されるＣＧＡ候補の生成、ＣＧＡを用いるエンティティｉと、匿名公開鍵証明書を発行するエンティティＣＡとが行う証明書発行プロトコルを説明する。また、以下では、ＣＧＡを用いるエンティティｉがＩＫＥを実行するときにＣＧＡを使う場合と、匿名公開鍵証明書を使う場合との両方の場合に対応可能なプロトコルを説明する。

始めに、図１０を参照しながら、ＣＧＡを対象とする匿名公開鍵証明書発行プロトコルを説明する。エンティティｉは、ステップＳ１０１において、図６に示された動作フローチャートに従い、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓを生成する。また、エンティティｉは、ＣＧＡ候補を要求するメッセージと、ＣＧＡを対象とする匿名公開鍵証明書を要求するメッセージとを生成する。

エンティティｉは、ステップＳ１０２において、ＣＧＡ候補を要求するメッセージと、ＣＧＡを対象とする匿名公開鍵証明書を要求するメッセージとをエンティティＣＡに送る。このとき、エンティティｉは、ｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓをソースＩＰアドレスとする。前記２つのメッセージは、エンティティｉの公開鍵証明書によるディジタル署名（及び公開鍵証明書）が添付されているものとする。

エンティティＣＡは、ステップＳ１０３で、ＣＧＡ候補を要求するメッセージと、ＣＧＡを対象とする匿名公開鍵証明書を要求するメッセージと、を受け取り、それらの正当性をエンティティｉの公開鍵証明書を用いて検証する。検証が成功したら、エンティティＣＡは、ＣＧＡ候補と、ＣＧＡ候補に対応するＣＧＡパラメータとを生成する。

エンティティＣＡは、登録済みの公開鍵ｖ＿ｉから匿名公開鍵証明書を生成するときと同様に乱数ｒを生成し、（ｇ'、ｖ＿ｉ'）＝（ｇ＾ｒ ｍｏｄ ｐ、（ｖ＿ｉ）＾（ｒ） ｍｏｄ ｐ）によって、ＣＧＡ候補の公開鍵を求める。

エンティティＣＡは、ＣＧＡ候補の公開鍵と、ＣＧＡパラメータとから上述のようにＨａｓｈ２と、Ｈａｓｈ１とを生成し、ＣＧＡパラメータを確定させ、ｉｎｔｅｒｆａｃｅ ＩＤを求める。

ＣＧＡ候補の公開鍵を生成する他の方法として、エンティティＣＡは、秘密鍵ｓと、公開鍵ｖとのペアを（ｓ、ｖ）＝（ｓ、ｇ＾ｓ ｍｏｄ ｐ）によって求め（ｓは乱数とする）、公開鍵ｖ＿Ｉ'をｖ＊（ｖ＿ｉ ｍｏｄ ｐ）としてもよい。

このとき、対応する秘密鍵ｓ＿ｉ'は、秘密鍵ｓを送られたエンティティｉが、ｓ＿ｉ'＝ｓ ＋ ｓ＿ｉ ｍｏｄ （ｐ−１）によって計算する。但し、この場合は、鍵ペア（ｓと、ｖと）は暗号化されてエンティティｉに送られる必要がある。暗号化されないで平文で送られる場合、登録された公開鍵と、送られた鍵ペアから公開鍵ｖ＿ｉ'が容易に計算できるので、公開鍵の匿名性が保たれずプライバシ保護に役立たない。

エンティティＣＡは、ステップＳ１０４で、ＣＧＡ候補と、ＣＧＡ候補に対応するＣＧＡパラメータとをｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓ宛に送る。このとき、場合によっては（前記鍵ペア（ｓ、ｖ）が生成され送られる場合には）エンティティＣＡは、エンティティｉの公開鍵証明書を用いて暗号化して送る。

エンティティｉは、ステップＳ１０５で受け取ったＣＧＡ候補と、ＣＧＡパラメータとからＣＧＡとして正しく計算されているか否かをＨａｓｈ２と、Ｈａｓｈ１と、ｉｎｔｅｒｆａｃｅ ＩＤとを生成して確認する。次に、エンティティｉは、その正当性が確認されたＣＧＡを対象にＤＡＤを実行し、接続しているＬＡＮ（リンク２０７）でそのＩＰｖ６アドレスが重複しているか否かを判断する。

エンティティｉは、重複していない（ｕｎｉｑｕｅ）ならばそのＣＧＡを使い、重複している（ＮＧ）ならばそのＣＧＡは使わない。エンティティｉは、ｒｅｓｕｌｔにＤＡＤの結果（ｕｎｉｑｕｅ或いはＮＧ）を格納し、ＣＧＡに対応する公開鍵を用いるディジタル署名をｒｅｓｕｌｔに対して生成する。

エンティティｉはステップＳ１０６で、ＣＧＡをソースＩＰアドレスとしてｒｅｓｕｌｔ（ｕｎｉｑｕｅ）、或いはｔｅｍｐｏｒａｒｙ ａｄｄｒｅｓｓをソースＩＰアドレスとしてｒｅｓｕｌｔ（ＮＧ）、をエンティティＣＡに送る。

リンク２０７と、インターネット２０１との間のどこかに位置するＦｉｒｅｗａｌｌは、ステップＳ１０７で、ＣＧＡに基づくディジタル署名（ｒｅｓｕｌｔに対する署名）を検出する。

ｒｅｓｕｌｔのデータ形式が定められていれば、ＦｉｒｅｗａｌｌにおけるＣＧＡに基づくディジタル署名の検出は容易である。ＣＧＡを使わせないポリシーで運用されている場合、Ｆｉｒｅｗａｌｌは、ＣＧＡに基づくディジタル署名（ｒｅｓｕｌｔに対する署名）を検出したら、そのパケットを転送せず、破棄する。ＣＧＡを使わせるポリシーで運用されている場合、Ｆｉｒｅｗａｌｌは、ＣＧＡに基づくディジタル署名（ｒｅｓｕｌｔに対する署名）を検出しても廃棄せず、そのパケットを転送する。なお、どのようなポリシーで運用するかの情報は、Ｆｉｒｅｗａｌｌのメモリ等に格納されており、Ｆｉｒｅｗａｌｌは、この情報に基づいて、動作を行う。

エンティティＣＡはステップＳ１０８で、ＣＧＡと、ディジタル署名を含むｒｅｓｕｌｔと、を受け取り、ＣＧＡの認証と、ディジタル署名の認証とを行い、ｒｅｓｕｌｔの内容の正当性を確認する。エンティティＣＡは、ｒｅｓｕｌｔの内容がｕｎｉｑｕｅならば、前記ＣＧＡを含む匿名公開鍵証明書を生成し、それをステップＳ１０９でＣＧＡ宛に送る。

このとき、エンティティＣＡは、エンティティｉの公開鍵証明書を用いて、ＣＧＡを含む匿名公開鍵証明書を暗号化して送ってもよい。エンティティＣＡは、ｒｅｓｕｌｔの内容がＮＧならば、別のＣＧＡ候補を生成し、ステップＳ１０４からステップＳ１０８までを中断条件が成立するまで繰り返す。

中断条件は、いろいろな内容を設定できる。例えば、「ＣＧＡ候補を規定の回数生成する」、「ＣＧＡ候補を要求するメッセージの到達からｒｅｓｕｌｔの到達が規定時間以内であれば回数に制限なくＣＧＡ候補を生成する」等である。中断条件は、例えばＨＤ３０６等に格納されている。エンティティＣＡは中断条件が成立すると、中断条件が成立した旨を示すメッセージを作成し、ステップＳ１０９でエンティティｉに送る。

エンティティｉは、ステップＳ１１０で、匿名公開鍵証明書、或いは中断条件が成立した旨のメッセージを受け取る。エンティティｉは、中断を示すメッセージを受け取ると処理を中断する。

以上の手順により、ＣＧＡを対象とする匿名公開鍵証明書がエンティティｉと、エンティティＣＡとの間で要求・発行される。公開鍵証明書と、登録された公開鍵ｖ＿ｉと、を基にしてＣＧＡ候補の公開鍵が生成されるので、エンティティｉではないエンティティがエンティティｉ用のＣＧＡを受け取って対応する秘密鍵を使ってディジタル署名を生成することはできない。ＣＧＡ用の公開鍵から対応するエンティティを特定することは計算量的に困難なので匿名性が保たれる。

ＣＧＡ候補の生成はエンティティＣＡによって行われるので、鍵ペアの生成をエンティティｉが行わなくてすむ。また、Ｓｅｃの値が０ではない場合に必要とされるＭｏｄｉｆｉｅｒを定めるための総当り計算をエンティティｉが行わなくてすむ。

なお、上記の匿名公開鍵証明書の要求・発行プロトコルでは、ＣＧＡはエンティティＣＡによって生成された。エンティティＣＡがＣＧＡの代理計算を行わず、エンティティｉがＣＧＡを生成する場合の匿名公開鍵証明書の要求・発行プロトコルを図１１に示す。

図１０と、図１１との違いは、エンティティｉがＣＧＡを生成してＤＡＤを実行してから匿名公開鍵証明書の要求を行う点である。また、匿名公開鍵証明書要求メッセージに添付するエンティティｉが生成するディジタル署名が、公開鍵証明書に基づくか、ＣＧＡに基づくかも異なる点である。従って、エンティティｉの身元をエンティティＣＡは確認できるとは限らない。

なお、図１１において、ＣＧＡによるディジタル署名を用いるのではなく公開鍵証明書に基づくディジタル署名を用いることもできる。この場合、エンティティｉの身元をエンティティＣＡは確認できる。

次に、ＣＧＡに基づく暗号通信と、身元確認を行っての暗号通信とを適応的に実行可能にするプロトコルを、図１２を参照しながら説明する。図１２のプロトコルは、エンティティｉがＩＫＥ ＩｎｉｔｉａｔｏｒとしてＩＫＥ（Ｍａｉｎ Ｍｏｄｅ）を実行し、通信相手ｐｅｅｒ（ＩＫＥ ｒｅｓｐｏｎｄｅｒ）がＣＧＡに対応する場合としない場合の手順を含む。なお、ＩＫＥ Ｒｅｓｐｏｎｄｅｒは公開鍵証明書をサポートすると仮定する。

エンティティｉは、ステップＳ１９０１で、ＩＫＥ ｐｈａｓｅ１を開始する。エンティティｉは、ＣＧＡをソースＩＰアドレスとして用いる。エンティティｉは、ステップＳ１９０２で、ＳＡの提案を複数ｐｅｅｒに送る。ｐｅｅｒは、ステップＳ１９０３で、ＳＡを一つ選ぶ。

ｐｅｅｒは、ステップＳ１９０４で、選んだＳＡをエンティティｉに送り返す、或いはＮＧを返し、ＩＫＥの続行を中止する。エンティティｉは、ステップＳ１９０５で、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵交換プロトコルを開始する。

エンティティｉは、ステップＳ１９０６で、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵交換プロトコルで最初に送るデータＫＥをｐｅｅｒに送る。ｐｅｅｒは、ステップＳ１９０６で、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ公開鍵交換プロトコルで送るデータＫＥをエンティティｉに送る。エンティティｉと、ｐｅｅｒとは交換したデータＫＥを基にして秘密の共有鍵を生成する（図示せず）。

エンティティｉは、ステップＳ１９０８で、認証データを生成する。認証データは、ＨＡＳＨ＿Ｉに対するディジタル署名を含む。エンティティｉは、ＣＧＡの公開鍵を用いてディジタル署名を生成する。

エンティティｉは、ステップＳ１９０９で、認証データと、ＣＧＡパラメータとをｐｅｅｒに送る。このとき、エンティティｉと、ｐｅｅｒとで共有した暗号化鍵によってデータは暗号化されている。

ｐｅｅｒは、ステップＳ１９１０で、暗号化されたデータを受け取り、復号する。そして、ｐｅｅｒは、ＣＧＡの認証を行う。ｐｅｅｒは、認証が失敗したらＩＫＥの続行は中断し、認証が成功したら、復号された認証データが正当か否かをＣＧＡの公開鍵を用いて確認する。ｐｅｅｒは、ＣＧＡの認証と、認証データの認証とが成功したら、ＨＡＳＨ＿Ｒに対する認証データを生成し、暗号化してステップＳ１９１１でエンティティｉに送る。

エンティティｉは、ステップＳ１９１２で、受け取ったデータを復号し、認証データの正当性を確認する。エンティティｉは、確認が成功したら、ＩＫＥ ｐｈａｓｅ２を開始する。エンティティｉは、確認が失敗した場合（タイムアウトを含む）は、再びＩＫＥ ｐｈａｓｅ１を開始する。

ステップＳ１９１３からステップＳ１９１８までの処理は、ステップＳ１９０２からステップＳ１９０７までの処理と同様である。

エンティティｉは、ステップＳ１９１９で、匿名公開鍵証明書に基づく認証データを生成する。ここで、匿名公開鍵証明書に基づく認証データとは、例えば、ＨＡＳＨ＿Ｉに対するディジタル署名である。なお、匿名公開鍵証明書に含まれるＩＰｖ６アドレスはＣＧＡである。

エンティティｉは、ステップＳ１９２０で、匿名公開鍵証明書に基づく認証データと、匿名公開鍵証明書とをｐｅｅｒに送る。このとき、エンティティｉと、ｐｅｅｒとで共有した暗号化鍵によってデータは暗号化されている。

ｐｅｅｒは、ステップＳ１９２１で、暗号化されたデータを受け取り、復号する。そして、ｐｅｅｒは、匿名公開鍵証明書の正当性を確認する。ｐｅｅｒは、匿名公開鍵証明書の正当性が確認できなかったらＩＫＥの続行は中断し、匿名公開鍵証明書の正当性が確認できたら、その公開鍵を用いて認証データの正当性を確認する。

ｐｅｅｒは、匿名公開鍵証明書の正当性確認と、認証データの正当性確認とに成功すると、ＨＡＳＨ＿Ｒに対する認証データを生成し、暗号化してステップＳ１９２２でエンティティｉに送る。

エンティティｉは、ステップＳ１９２３で、受け取ったデータを復号し、認証データの
正当性を確認する。エンティティｉは、確認が成功すると、ＩＫＥ ｐｈａｓｅ２を開始し、確認が失敗すると、ＩＫＥの続行を止める。

以上のプロトコルによって、ＣＧＡによる暗号通信と、身元確認を行っての暗号通信とを適応的に実行することが可能になり、状況によってＣＧＡによる暗号通信が行えなかった場合でも身元確認を行っての暗号通信を行うことができる。

例えば、図１０や図１１におけるＦｉｒｅｗａｌｌが設けられている場合、ＣＧＡに基づくＩＫＥの実行は、ＩＫＥパケットが途中で破棄されて実行できないときがある。このとき、遅くとも図１２のステップＳ１９１２においてタイムアウトとなる。すると、匿名公開鍵証明書を用いるＩＫＥが実行され、エラーが起こらない限りはＩＫＥが成功し、ＩＰｓｅｃが行えるようになる。従って、従来ならば暗号通信を断念しなければならない状況でも暗号通信を実行可能にしている。

もちろん、最初から匿名公開鍵証明書を用いてＩＫＥを実行することも可能である。従って、本実施形態は、ＣＧＡに基づく暗号通信と、身元確認を行っての暗号通信と、を適応的に実行可能にしている。

以上、上述したように、本実施形態によれば、ＣＧＡを用いる場合でも公開鍵証明書に基づく暗号通信、即ちＩＫＥを実行してＩＰｓｅｃ通信を行うことができる。従って、ＣＧＡに基づく暗号通信が禁止されている状況においても暗号通信を行うことができ、しかもプライバシ保護も確保される。

また、本実施形態によれば、ＣＧＡによる暗号通信と、身元確認を行っての暗号通信とを適応的に実行することが可能になり、状況によって暗号通信が行えなかった場合でも暗号通信を行うことができる。

また、本実施形態によれば、異なる公開鍵に基づくＣＧＡを使う際にＣＧＡの生成を行わずとも済み、装置のレスポンスの低下や使い勝手の低下を防ぐことができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

Ｈａｓｈ２の計算方法を模式的に示す図である。 Ｈａｓｈ１の計算方法を模式的に示す図である。 本実施形態が適用される接続環境を模式的に示した図である。 ノードの構成を示す図である。 ホストがＤＡＤを終えるまでの動作を説明するフローチャートである。 ホストがアドレス自動設定を終えるまでの動作を説明するフローチャートである。 ホストがＤＨＣＰでアドレスを取得するまでの動作を説明するフローチャートである。 匿名公開鍵証明書の発行プロトコルを説明する図である。 ホストが匿名公開鍵証明書を取得するまでの動作を説明するフローチャートである。 ＣＧＡを対象とする匿名公開鍵証明書発行プロトコルを説明する図である。 ＣＧＡを用いる匿名公開鍵証明書発行プロトコルを説明する図である。 ＣＧＡと、匿名公開鍵証明書とを併用してＩＫＥを実行するプロトコルを説明する図である。

符号の説明

３００ ノード
３０１ ネットワーク・インターフェイス
３０２ ネットワーク・インターフェイス
３０３ ＣＰＵ
３０４ ＲＯＭ
３０５ ＲＡＭ
３０６ ＨＤ（ハードディスク）
３０７ 電源
３０８ キーボード／ポインティングデバイスのインターフェイス
３０９ モニターのインターフェイス

Claims (5)

1. ネットワークを介して通信を行う通信装置であって、
   前記ネットワークを介して接続された他の通信装置に対して、暗号的に生成されたアドレスに対応する公開鍵を証明対象とする匿名公開鍵証明書の発行要求を送信する発行要求送信手段と、
   前記発行要求に応じて発行された前記匿名公開鍵証明書を、前記他の通信装置より受信する証明書受信手段と、
   前記アドレスに基づいて暗号通信を行う第一の暗号通信手段と、
   前記匿名公開鍵証明書に基づいて暗号通信を行う第二の暗号通信手段と、
   を有することを特徴とする通信装置。
2. 前記第一の暗号通信手段において暗号通信を行うことができない場合、前記第二の暗号通信手段において暗号通信を行うよう制御する通信制御手段を更に有することを特徴とする請求項１に記載の通信装置。
3. 前記ネットワークを介して接続された他の通信装置に対して、前記アドレスの代理生成要求を送信する生成要求送信手段と、
   前記代理生成要求に応じて発行された前記アドレスを、前記他の通信装置より受信するアドレス受信手段と、
   を更に有することを特徴とする請求項１又は２に記載の通信装置。
4. ネットワークを介して通信を行う通信装置における暗号通信方法であって、
   前記ネットワークを介して接続された他の通信装置に対して、暗号的に生成されたアドレスに対応する公開鍵を証明対象とする匿名公開鍵証明書の発行要求を送信する発行要求送信ステップと、
   前記発行要求に応じて発行された前記匿名公開鍵証明書を、前記他の通信装置より受信する証明書受信ステップと、
   前記アドレスに基づいて暗号通信を行う第一の暗号通信手段において暗号通信を行うことができない場合、前記匿名公開鍵証明書に基づいて暗号通信を行う第二の暗号通信手段において暗号通信を行うよう制御する通信制御ステップと、
   を有することを特徴とする暗号通信方法。
5. 前記ネットワークを介して接続された他の通信装置に対して、前記アドレスの代理生成要求を送信する生成要求送信ステップと、
   前記代理生成要求に応じて発行された前記アドレスを、前記他の通信装置より受信するアドレス受信ステップと、
   を更に有することを特徴とする請求項４に記載の暗号通信方法。

Images