JP2004040762A - アドレスに基づく鍵を使用することによる近隣発見の保護 - Google Patents

Abstract

【課題】ＩＰネットワーキングシステム内での近隣発見を保護する。
【解決手段】ホストのＩＰアドレス値とルータのルーテッドプレフィックスを使用することにより公開鍵が生成される。そして、識別子に基づく秘密鍵生成器（ＩＰＫＧ）が、ホストあるいはルータの公開鍵に対応する秘密鍵を公開の暗号のパラメータを使用することにより生成する。そして、近隣発見が公開／秘密鍵と公開のパラメータにより認証される。
【選択図】　　　図１

Description

【０００１】
【関連出願】
本願は、仮米国特許出願番号６０／３５８，２８６（２００２年２月１９日出願）の「アドレスに基づく鍵（ＡＢＫ）を使用することによるＩＰＶ６近隣発見の保護」に基づいて優先権主張する。なお、これらの文献は本文中でも参照した。
【０００２】
【従来の技術】
インターネット規定コメント要求（ＲＦＣ）２４６１に記載されているインターネットプロトコルバージョン６（ＩＰｖ６）近隣発見プロトコルは、ＩＰｖ６ネットワークノードへの最終ホップのネットワークアクセスの便宜を図る。最終ホップとは、ネットワークに入る前のホストと第一／最終ルータ間のリンクである。プロトコルにより、リンクに加わっているＩＰホストがルータを発見することができ、ルータを含むリンク上のノードはＩＰトラヒックが配信されるリンク上のＩＰノードのリンクレイヤアドレスを見つけることができる。プロトコルの崩壊は、ノードによるＩＰトラヒックの送受信の能力に深刻な影響を与えかねない。
【０００３】
【発明が解決しようとする課題】
しかし、プロトコルに対するセキュリティは不十分である。ＲＦＣに記載されているように、プロトコルはどの近隣が特定の種類のメッセージを送信することを認められているかを判断する構造を含んでいない。仮に、認証のもとにあったとしても、あらゆる近隣がルータ広告メッセージを送信することができる上、それによってネットワークサービスの拒否を引き起こすことも可能である。更に、あらゆる近隣がサービス不能攻撃である可能性のあるプロキシ近隣広告および迷惑な近隣広告を送信することができる。
【０００４】
マルチアクセスリンク上のＩＰｖ６近隣発見には、様々な脅威が起こる可能性がある。これらの脅威は、有線及び無線の公共のマルチアクセスリンクに起こる可能性がある。この脅威は、特に無線リンクにとっては問題である。交換とは逆の、共有アクセス上の個人マルチアクセスリンク、８０２．１ｘポートに基づくアクセス制御などのリンクレベルの認証機構を伴った媒体、地方及び都市地域のネットワークへの２００１ＩＥＥＥ規格でさえも、ホストがシステムを惑わそうとした場合は崩壊の対象となる。
【０００５】
ＲＦＣ２４６１は、セキュリティの関連付けが存在する場合はＩＰセキュリティ認証ヘッダ（ＩＰｓｅｃＡＨ）による認証を利用することを勧めているが、これによる解決は複雑で公共のアクセスネットワークに広く適用可能であるとは考えにくい。特に、遠隔の公共のアクセスネットワークのローミングホストは、ローカルアクセスルータあるいは同一のリンクの他のホストとセキュリティの関連付けを持たない傾向にある。真に、同一リンク上のほとんどのノードが、ローミングノード同様同一のホームインターネットサービスプロバイダ（ＩＳＰ）を持っていない場合さえある。
【０００６】
【課題を解決するための手段】
ＩＰネットワーキングシステムにおける近隣発見を保護するシステム及び方法を開示する。ホストのＩＰアドレス値を使用することにより公開鍵が生成される。そして、識別子に基づく秘密鍵生成器（ＩＰＫＧ）が、ホストの公開鍵に対応する秘密鍵を公開の暗号のパラメータを使用することにより生成する。そして、近隣発見が秘密鍵により認証される。
【０００７】
【発明の実施の形態】
電気通信における近隣発見を保護するための構造の、本好適な実施形態を、同一の構成要素を同一の参照で特定される図を参照することにより説明する。近隣発見保護のための構造は、暗号技術を使用することにより近隣発見を最も効果的に行う目的として説明される。保護のための構造は、デジタル署名の計算のための対に基づくウェイルペアリングおよび暗号化からの識別子に基づく暗号化を利用するアドレスに基づく鍵（ＡＢＫ）の利用を含む。個々に含まれる記述は、例示の目的であり、発明の範囲を制限するためのものではない。
【０００８】
図１はインターネットプロトコル（ＩＰ）ネットワーク１００の一例を示すものである。ＩＰネットワーク１００は、ＩＰｖ６または他のネットワーク１１０を含む。データは、ここで参照することにより盛り込まれるＩＥＴＦ　ＲＦＣ２４６０として特定されるインターネットプロトコルバージョン６（ＩＰｖ６）に従って、ネットワーク内及びネットワーク上で通信される。ＩＰｖ６ネットワーク１１０にはルータ１３０の集団が構築される。ルータ１３０は、従来のインターネットアドレッシング及びルーティングプロトコルに従い、データのパケットをネットワーク１００に接続されたソースノードと宛先ノード間で送る。ルータ１３０はそれ自体がノードであり、ネットワーク１００上での通信のために固有のＩＰアドレスを持つ。ルータ１３０はまた、ホスト１３５とインターフェース接続されることができる。ホスト１３５は、電話、コンピュータおよび携帯情報端末（ＰＤＡ）などの異なる種類の装置を含む。情報は、有線または無線通信、携帯通信、衛星などによって通信されてもよい。
【０００９】
ＩＰｖ６近隣発見を保護するにあたり、容易に実行できるプロトコルについて説明する。プロトコルは、ローカルサブネットプレフィックスのホスト１３５広告ルーティングがプレフィックスを送ることを可能にし、近隣発見メッセージで提供される情報が信憑性がある旨をＩＰホストが確認することを可能にする。現在ある公共アクセスＩＰネットワークのための電気通信のインフラ以外、付加的なものは必要ない。プロトコルは、識別子に基づいた暗号システムからの出力を利用する。公知の識別子、例えば、ノードのＩＰアドレスの一部が、公開鍵として使われる。アドレスに基づくキー（ＡＢＫ）が、ＩＰアドレスから公開／秘密鍵を生成するために使用される。
【００１０】
ＡＢＫは、ホスト１３５ＩＰｖ６プレフィックスあるいはインターフェース識別子からホスト１３５の公開鍵および秘密鍵を生成するのに使用されることができる。識別子に基づく暗号システムは、ＩＰｖ６アドレスなどの公知の識別子を認証、鍵の一致、及び暗号化のための公開鍵としての使用を可能にする。識別子に基づく秘密鍵生成器（ＩＰＫＧ）は、公開鍵としての役割を果たす公開識別子を示された際、秘密鍵を生成するために識別子に基づく暗号のアルゴリズムを実行する。ＩＰＫＧアルゴリズムは、ホームネットワークあるいは遠隔ネットワーク認証サーバから実行することができる。公開の暗号パラメータは、選択された定数から形成された公知のパラメータの集団を含む。ＩＰＫＧは、ホストの秘密鍵を生成するために、公知のパラメータの集団とホストのＩＰアドレスから抽出されたホストの公開鍵を使用する。メッセージの保護あるいは暗号化に関係するホスト１３５は、暗号化の動作を実行するために、公開鍵／秘密鍵の対を使用する。
【００１１】
識別子に基づく暗号システムは、Ｅメールアドレスや本願におけるホスト１３５のＩＰアドレスなどの公知の識別子を、公開鍵／秘密鍵の対の公開鍵として機能させる暗号技術の集団を含む。暗号システムは、デジタル署名の計算、鍵の一致、及び暗号化を実行する。楕円曲線（ＥＣ）アルゴリズムが、小さな鍵のサイズとして機能すること、小規模な無線装置などの小規模なホストにおいてコンピュータとして効率がよいこと、及びより小さな署名を生成することから、識別子に基づく鍵としてよく機能する。他の非ＥＣアルゴリズムも識別子に基づくデジタル署名の計算に使用されてもよいが、ＥＣアルゴリズムのように効率的に機能しない場合がある。
【００１２】
識別子に基づく暗号システムは、ＩＰＫＧへ渡される公知の識別子とともに機能する。公知の識別子は、例えば６４ビットサブネットプレフィックスあるいはＩＰｖ６アドレスの固有の６２ビットインターフェース識別子を含むことができる。ＩＰＫＧは、秘密鍵を生成するために特定のアルゴリズムを使用し、例えばホスト１３５などのシステムに秘密鍵を返送する。ＩＰＫＧとホスト１３５間の接続は、例えば暗号化された、あるいは他の安全な方法で返送される鍵など非公開であるべきである。そして、公開鍵及び秘密鍵は典型的な暗号システム同様認証及び暗号化のために使用されることができる。
【００１３】
識別子に基づく暗号のアルゴリズムは、ホスト１３５などの公開鍵及び秘密鍵のクライアントによって使用される公開の暗号パラメータを生成するためにＩＰＫＧのみに把握されている秘密の鍵を使用する。その結果、ディフィー・ヘルマンアルゴリズムとは異なり、公開の暗号パラメータは固定されることなく、よってクライアントへ予めプログラムされることはない。秘密の鍵は失効するか妥協されてもよく、妥協される場合は、公開の暗号パラメータは更新されることが望ましい。
【００１４】
デジタル署名は、以下のアルゴリズムを使用することにより、計算される。
ｓｉｇ＝ＳＩＧＮ（ｈａｓｈ（ｃｏｎｔｅｎｔｓ），ＩＰｒＫ，Ｐａｒａｍｓ）
上記アルゴリズムにおいて、
ｓｉｇ・・・デジタル署名
ＳＩＧＮ・・・署名を計算するために使用される識別子に基づいたデジタル署名アルゴリズム
ｈａｓｈ・・・ＨＭＡＣ−ＳＨＡ１一方向ハッシュアルゴリズム
ＩＰｒＫ・・・識別子に基づく秘密鍵
Ｐａｒａｍｓ・・・公開の暗号パラメータ
ｃｏｎｔｅｎｔｓ・・・署名されるメッセージコンテンツ
【００１５】
デジタル署名は、以下のアルゴリズムを使用することにより照合される。
ＩＰｕＫ＝ＩＢＣ−ＨＡＳＨ（ＩＤ）
ｖａｌｉｄ＝ＶＥＲＩＦＹ（ｈａｓｈ（ｃｏｎｔｅｎｔｓ），ｓｉｇ，ＩＰｕＫ）
上記アルゴリズムにおいて
ＩＢＣ−ＨＡＳＨ・・・公開の識別子から公開鍵を生成する識別子に基づくアルゴリズムへの特定のハッシュ関数
ＩＤ・・・鍵を生成するために使用される公知の識別子
ＩＰｕＫ・・・識別子に基づく公開鍵
ｓｉｇ・・・デジタル署名
ＶＥＲＩＦＹ・・・鍵を照合するために使用される識別子に基づく公開鍵アルゴリズム
Ｐａｒａｍｓ・・・公開の暗号パラメータ
ｖａｌｉｄ・・・照合された場合は１、されない場合は０
【００１６】
近隣発見に関係するホスト１３５と最終ホップルータ１３０は、メッセージングを保護する前にそれぞれ識別子に基づいた秘密鍵と暗号パラメータにより構成される。ＩＳＰあるいはネットワークの所有者が最終ホップルータを設定する場合、ルータは６４ビットサブネットプレフィックスあるいは他の公然のプレフィックスで構成される。加えて、ＩＳＰはプレフィックスへの秘密鍵を生成するためにＩＰＫＧを使用する。ルータ１３０は、ルータ広告へのデジタル署名を生成するために秘密鍵を使用する。秘密鍵と公開の暗号パラメータは、安全なチャンネルを介してルータ１３０に設定される。可能である安全なチャンネルの例としては、ネットワーク管理人による設定、セキュアキー配信が可能なＮＡＳに基づくＡＡＡネットワークを介した設定、ＩＰＳｅｃセキュリティの関連をもつルータ１３０とのサーバとのセキュアメッセージ交換を介した設定を含む。
【００１７】
ホスト１３５は、例えばＩＰｖ６アドレスのボトム６２ビット（６４ビットから“ｕ”ビットと“ｇ”ビットを除いたもの）などの６２ビットインターフェース識別子に関連した秘密鍵に基づく識別子と公開の暗号パラメータを使用する。ホスト１３５は、例えばＮＡＳとのセキュアコネクションを介したネットワークアクセスのために最初に認証され許可された場合は動的に構成されてもよい。更に、ホスト１３５は、例えばホームＩＳＰがインターフェース識別子を指定した場合は静的に設定されてもよい。
【００１８】
現在、公共のアクセスネットワークのほとんどがホスト１３５に対して、ネットワークを使用できるようになる前にＮＡＳを介したセキュア認証と許可交換を受けることを求めている。この交換は、典型としてはあらゆるＩＰ信号伝達の前に第２層で行われることから、あらゆる近隣発見信号伝達の前に実現されることができる。ホスト１３５は、ＮＡＳへのメッセージの中にインターフェース識別子を含ませる。ＮＡＳは、秘密鍵が生成されるＩＰＫＧへインターフェース識別子を送信する。そして、秘密鍵と公開の暗号パラメータは、これらが設定されるホスト１３５へ安全に返信される。安全な送信は、ＰＰＰ上のＥＡＰ上のＴＬＳあるいは他の第２層プロトコルを使用することにより実現される。そして、ローカルリンク上のホスト１３５と最終ホップルータは、公開の暗号パラメータと秘密鍵を遠隔のネットワークのために、ＩＰｖ６近隣発見の信号伝達を保護する目的で使用する。
【００１９】
公共のアクセスネットワークの中には、ホスト１３５に近隣発見を実行させる前にセキュア第２層認証と許可を行わないものもある。これらの類のネットワークへの便宜を図るために、ホスト１３５はホームＩＰＳあるいはネットワークオペレータにより公開の暗号パラメータと秘密鍵によって構成される。安全な近隣発見のためのメッセージングは、範囲に基づく識別子（大抵ネットワークアクセス識別子（ＮＡＩ）の、例えば“ｄｏｃｏｍｏｌａｂｓ−ｕｓａ．ｃｏｍ”などのＤＮＳドメイン名）を含む。この識別子は、ホスト１３５とローカルリンクのルータ１３０に、ゲストホストの信号伝達の認証を可能にする。ローミング共同体は、ＩＰＫＧを調整する。ローミング共同体とは、ビジネスの関係をもち、クライアントのビジネス間でのローミングを可能にするものである。ローミング共同体は、ＩＰＫＧが認証、許可及び顧客の会計のために必要とされる他の情報の交換を調整する際に、ＩＰＫＧを調整する。共同体内の様々なＩＳＰが、ゲストホストの便宜を図ることができる。静的構成が使用される際は、ルータ１３０及びホスト１３５の両方の認証のための暗号とパラメータが、それらが同一である必要がないために設定される。
【００２０】
ＩＰｖ６のルータ広告のために以下のプロトコルが使用されてもよい。６４ビットプレフィックスキーによって構成されるルータによって送信されるルータ広告は、デジタル署名を含む。署名は、ＩＣＭＰメッセージオプションを含むメッセージ内の該当するフィールドへ行われる（存在する場合）。ＩＣＭＰメッセージオプションは、以下のものを含む。
＊現在のホップの限度（ｃｈｌ）
＊フラグ（ｆｌ）
＊ルータの寿命（ｒｏｌ）
＊可到達寿命（ｒｅｌ）
＊再送信タイマー（ｒｔｔ）
＊ソースリンク層アドレスオプション（存在する場合）（ｓｌｌａｏ）
＊ＭＴＵオプション（存在する場合）（ｍｔｕｏ）
＊プレフィックスオプション（ｐｒｏ）
＊署名なしのＡＢＫデジタル署名オプション（ｉｄｓｏ）
＊他のあらゆるオプション（．．．）
【００２１】
信号伝達アルゴリズムにおいて、一方向ハッシュとしてのメッセージ認証コードを生成するＨＭＡＣ−ＳＨＡ１アルゴリズムへの入力は、以下のものを含む
コンテンツ＝（ｃｈｌ，ｆｌ，ｒｏｌ，ｒｅｌ，ｒｔｔ，ｓｌｌａｏ，ｍｔｕｏ，ｐｒｏ，ｄｓｏ，．．．）
信号伝達アルゴリズムのＩＰｒＫは、ルータの６４ビットサブネットプレフィックスである。
【００２２】
デジタル署名は、署名、アルゴリズム、および範囲識別子とともにＡＢＫデジタル署名オプションに含まれている。ＩＣＭＰオプション（インターネット制御メッセージプロトコル、すなわちインターネット上で制御メッセージを交換するために使用されるプロトコル）が、ＩＰＳｅｃＡＨ（パケットの認証のために使用されるインターネットプロトコルセキュリティ認証ヘッダ）の代わりに使用されてもよい。ホスト１３５によって認識されない近隣発見オプションは無視される。署名を認証することができなくとも、安全対策が施されていないルータ広告を使用することができるホスト１３５は、ＩＰＳｅｃ処理によりルータ広告を拒否させる代わりに標準の近隣発見処理の結果としてオプションを無視することができる。
【００２３】
ルータ広告は、鍵が指定されたプレフィックスとのプレフィックスオプションを含む。ルータ１３０が単一のプレフィックスよりも多くのプレフィックスを送る場合、ルータはそれらを別途のルータ広告を使用することにより表す。ルータ１３０が複数の識別子に基づくアルゴリズムに対応する場合、ルータ１３０はパスＭＴＵ（セグメンテーションが求められる前に、送られることができるパケットの最大のサイズ）に至るまでの、例えばボネー・フランクリンアルゴリズムなどの様々なアルゴリズムによって計算される署名による複数のＡＢＫデジタル署名オプションを含むことができる。
【００２４】
ＡＢＫデジタル署名オプションでルータ広告を受信しているホスト１３５などのＩＰｖ６ホストは、広告ノードが広告を送信することを許可されている旨を確認する。ルータ広告がルーティングプレフィックスのオプションを含まない、あるいはルータ広告が一つよりも多いルーティングプレフィックスオプションを含んでいて、ホスト１３５が安全対策が施されていないルータ広告をあえて使うことができないときには、ホスト１３５はルータ広告を切り捨てる。ホスト１３５がメッセージの信号伝達に使用されるアルゴリズムの一つに対応せず、安全対策が施されていないルータ広告をあえて使用しない場合にはルータ広告を切り捨てることが望ましい。
【００２５】
ホスト１３５は、単一のルーティングプレフィックスオプションを見つけ、例えばルータ１３０等の送信ノードが送ろうと試みているサブネットプレフィックスを抽出する。そして、ホスト１３５はルータ広告署名の計算と同様のコンテンツの値を使用しデジタル署名を照合するために照合アルゴリズムを使用する。この計算において、プレフィックスオプション内のサブネットプレフィックスを使用することにより公開鍵が生成される。識別子に基づくアルゴリズムと、ルータの公開の暗号パラメータは、ＡＢＫデジタル署名オプションのアルゴリズムと範囲識別子に基づく。
【００２６】
識別子に基づくアルゴリズムのうち、どれを使用するかを決定する際に長い交渉の処理が行われないことが望ましい。アルゴリズムは時を経て変化することから、ホスト１３５は、ルータの請求においてどのアルゴリズムに対応するかを示すことができる。ルータ１３０がどのアルゴリズムにも認証符号を提供することができない場合、ホスト１３５は許容可能な場合に認証されていないルータ広告を返信し処理を続行することができる。認証が提供されない場合、ホスト１３５は識別子アルゴリズムを使用することができる。
【００２７】
マルチキャストのルータ広告には、ルータ１３０はパスＭＴＵに至るまでの、それぞれの対応するアルゴリズムへのＡＢＫデジタル署名オプションを含ませることができる。その代わりに、ホスト１３５はＡＢＫアルゴリズムオプションでルータ広告を求めることと、どのアルゴリズムに対応するかをルータ１３０に知らせることを要求されるようにしてもよい。ＩＰｖ６近隣発見メッセージを保護するために同様の処理が使用されてもよい。近隣発見メッセージへの応答として送信される近隣広告は、６２ビットインターフェース識別子とホストの公開の暗号パラメータから生成され秘密鍵で計算されるデジタル署名を含む。署名は、存在する場合は全てのオプションを含むメッセージ内の該当するフィールドを使用することにより計算されてもよい。フィールドは、以下のものを含む。
＊フラグ（ｆｌｇ）
＊宛先アドレス（ａｄｄｒ）
＊宛先リンクレイヤアドレスオプション（ｌ２ａｄｄｒ）
＊署名なしの、ＡＢＫデジタル署名オプションそのもの（ｉｄｓｏ）
宛先リンクレイヤアドレスオプションは、含まれることが望ましい。
【００２８】
署名アルゴリズムでは、ハッシュアルゴリズムへの入力は以下の通りであってもよい。
コンテンツ＝（ｆｌｇ，ａｄｄｒ，ｌ２ａｄｄｒ）
ＩＰｒＫは、インターフェース識別子の秘密鍵である。
【００２９】
デジタル署名は、署名、アルゴリズム及び範囲識別子とともにＡＢＫデジタル署名オプションの中に含まれる。ホスト１３５によって認識されない近隣発見オプションは無視されてもよいことから、ＩＣＭＰオプションがＩＰＳｅｃＡＨの代わりにここでも使用されてもよい。ＡＢＫデジタル署名とともに近隣広告を受信するＩＰｖ６は、アドバタイジングホストが広告を送信することを認められている旨を確認する。受信するホスト１３５が署名を暗号化するのに使用されたアルゴリズムの一つに対応せず、安全が施されていない近隣広告をあえて使用しない場合以外には、近隣広告を切り捨てるべきである。
【００３０】
ホスト１３５は、近隣広告への署名の計算と同様に、コンテンツへの値を使用することによりデジタル署名を照合するために照合アルゴリズムを使用する。この計算において、ＩＤはホスト１３５の６２ビットインターフェース識別子を含む。識別子に基づくアルゴリズムとホストの公開の暗号パラメータは、ＡＢＫデジタル署名オプションのアルゴリズムと範囲識別子に基づく。
【００３１】
ＡＢＫデジタル署名オプションのフォーマットの一例を図２に示す。例えばホスト１３５などの、近隣請求メッセージを送信しているノードは、メッセージにＡＢＫアルゴリズムオプションを含ませることにより、ノードがどのアルゴリズムを受け付けることができるのかを示すことができる。ＡＢＫデジタル署名オプションは、アドレスに基づく秘密鍵を使用することにより計算されたデジタル署名を含み、リスト中の最後のオプションであることが望ましい。タイプフィールドは、例えばインターネットの数字割り当て機関ＩＡＮＡによって割り当てられたオプションタイプの８ビットの識別子を含む。長フィールドは、例えば８バイトなど８オクテットによる単位のタイプ及び長フィールドを含むオプション長を表す８ビットの署名されていない整数値を含む。アルゴリズム識別子フィールドは、ＩＡＮＡによって割り当てられ、メッセージに署名するために使用される識別子に基づくアルゴリズムを示す１６ビットの０以外のアルゴリズム識別子を含む。範囲識別子は、ホスト及びホストのホームネットワークを特定するために使用されるネットワークアクセス識別子（ＮＡＩ）の範囲の部分の１６ビットの０以外のＨＭＡＣ−ＳＨＡ１ハッシュ、あるいはホストとホームネットワークの固有の識別子を得るための他の方法を含む。その代わりに、範囲識別子は、現在のネットワークのＩＰＫＧ及び公開の暗号パラメータが使用されるべきことを示す０を含んでもよい。デジタル署名フィールドは、デジタル署名を含むＮビットフィールドを含む。フィールドは、例えばサイズが偶数のオクテットよりも小さく、残りのフィールドが０で満たされている場合、一番近い８バイトの境界に０で揃えられている。異なるビット量が使用されてもよく、ビット数は識別子に基づくアルゴリズムとシステムの利用に基づく。
【００３２】
図３は、ＡＢＫアルゴリズムオプションの一例を示すものである。ＡＢＫアルゴリズムオプションは、ホストに対してルータ広告あるいは近隣広告を要求する際、特定の範囲に対してどの識別子に基づくキーイングアルゴリズムに対応するかを示すことを可能にする。ＡＢＫアルゴリズムオプションは、例えばＩＡＮＡによって割り当てられたオプションタイプに対する８ビットの識別子などのタイプフィールドを含んでもよい。長は、８オクテットの単位によるタイプ及び長フィールドを含むオプション長を表す８ビットの署名されていない正数を含んでいてもよい。アルゴリズム識別子フィールドは、メッセージに署名するのに識別子に基づくアルゴリズムが使用されている旨を示すＩＡＮＡによって割り当てられた１６ビットの０以外のアルゴリズム識別子を含む。範囲識別子フィールドは、例えばＮＡＩの範囲部分のＨＭＡＣ−ＳＨＡ１ハッシュアルゴリズムを使用して計算された１６ビットの０以外の数字、あるいは現在のネットワークのアルゴリズムの使用を示す０の値を含むことができる。残りのオプションのフィールドは、ホスト１３５が対応する優先度の順序によるアルゴリズム識別子―範囲識別子の対を含むことができる。オプションは、８バイトの倍数で増える０の値を含むことができる。
【００３３】
ＡＢＫは、公開鍵を形成するためにインターフェース識別子あるいはサブネットプレフィックスを細分する。ＡＢＫは、ホスト１３５のアドレスを割り当てる実体によって、ホスト１３５に秘密鍵が提供されることを要求する。ＡＢＫは、秘密鍵生成を実行する際に共有の秘密を使用し、また共有の秘密は失効あるいは妥協されることもあることから、公開の暗号パラメータによる構成を要求する。
【００３４】
ＡＢＫにより実行される暗号化に使用されるアドレスは、動的ホスト構成プロトコルＤＨＣＰ、あるいはホストをＩＰアドレスにより構成するのに使用される他のプロトコルによって恣意的に割り当てられるものではない。ＡＢＫの暗号化に使用されるアドレスは、ホストが実行しているステートレスアドレス自動構成がＡＢＫインターフェース識別子とアドレスの接尾６４ビットの秘密鍵を含み、複写が検知されない場合にＩＰｖ６のステートレスアドレス自動構成を使用することにより構成されてもよい。近隣発見を保護するために説明されている構造はまた、ステートレスアドレス自動構成を保護するために使用されてもよい。
【００３５】
識別子に基づくアルゴリズムにより、ＩＰＫＧは公開鍵と秘密鍵のコピーである“キーエスクロー”の特性を維持する。したがって、アドレス委託者のＩＰＫＧは全てのアドレスへの秘密鍵を保存し、認証されたあるいは暗号化されたトラヒックへアクセスできる場合がある。ただし、ＡＢＫはＩＰｖ６信号伝達トラヒックを保護するためのみに使用されるのが望ましく、機密性のある個人のデータに使用されないようにするべきである。ＩＳＰあるいはネットワークオペレータおよび正当なクライアント／ユーザは、ネットワークの効率的な動作を望んでいる。ＩＳＰがクレジットカード番号を保護するのに使用されている方法により、ＡＢＫの情報を保護することができる。
【００３６】
ローミング共同体のＩＳＰの集団が、ＡＢＫに対応する選択をした場合はマスターキーを共有するための調整をしてもよい。そのような事情においては、例えばＨＩＤＥ階層的識別に基づく暗号化といったＡＢＫの生成の保護を可能にする技術があるが、ローミング共同体内のＩＳＰは概ね請求および合意の点ではお互いに信用している。ビジネスの処理および特別に許可された情報の保護のための計算の構造は、恐らく配備されている。ＩＰＫＧの契約を共有するＩＳＰの集団は、ネットワークの安全な使用を顧客に対して可能にするが、他のネットワークは現在のローミングとは異なり安全でないサービスを受けるか、全くサービスを受けないかのどちらかである。
【００３７】
識別子に基づく仕組みは、公知かつ広く配信された暗号のライブラリによって実行を可能にするＲＳＡや楕円曲線暗号システム（ＥＣＣ）などの標準的な暗号の構成要素を要求する。広く様々な識別子に基づく暗号化が、Ｄ．ボネーとＭ．フランクリンの暗号化に適切な“ウェイルペアリングからの識別子に基づく暗号化”とＲ．サカイ、Ｋ．オーギシ及びＭ．カサハラによるデジタル署名の計算に適切な“対に基づく暗号化システム”などのＡＢＫに使用されてもよい。
【００３８】
以上の通り、本発明を様々な実施形態を参照することにより説明したが、多様な変化及び変形が、発明の範囲を離れることなく行われてもよい。よって、前述の詳細な説明は発明の現在の好適な実施形態を示すものとして理解されるべきであり、発明の定義として理解されるべきではない。全ての相当語句を含む請求の範囲のみが、本発明の範囲を定義するものである。
【００３９】
【発明の効果】
以上の方法により、まず、ホストのＩＰアドレス値とルータのルーテッドプレフィックスを使用することにより公開鍵が生成される。そして、識別子に基づく秘密鍵生成器（ＩＰＫＧ）が、ホストあるいはルータの公開鍵に対応する秘密鍵を公開の暗号のパラメータを使用することにより生成する。そして、近隣発見が公開／秘密鍵と公開のパラメータにより認証され、その結果保護される。
【図面の簡単な説明】
【図１】インターネットプロトコルネットワークの一例を示すものである。
【図２】ＡＢＫデジタル署名オプションのフォーマットの一例を示すものである。
【図３】ＡＢＫアルゴリズムオプションのフォーマットの一例を示すものである。
【符号の説明】
１００・・・インターネットプロトコルネットワーク　１１０・・・ＩＰｖ６ネットワーク　１３０・・・ルータ　１３５・・・ホスト

Claims (27)

1. 電気通信システムにおける近隣発見を保護する方法であって、
   ホストのインターネットプロトコルアドレス値を使用することにより公開鍵を生成する過程と、
   前記公開鍵から秘密鍵を生成する過程と、
   前記近隣発見を保護するために前記公開鍵と前記秘密鍵を使用する過程と、
   を備えることを特徴とする方法。
2. 前記ホストが、前記公開鍵を生成する請求項１に記載の方法。
3. 前記ホストが、前記秘密鍵を受信する請求項１に記載の方法。
4. 前記秘密鍵が、セキュアチャンネルを介して受信される請求項３に記載の方法。
5. 前記秘密鍵が、識別子に基づく秘密鍵生成器により生成される請求項３に記載の方法。
6. ルータが前記公開鍵を生成する請求項１に記載の方法。
7. ルータが識別子に基づく秘密鍵生成器により生成された前記秘密鍵をセキュアチャンネルを介して受信する請求項１に記載の方法。
8. 前記近隣発見が、公開鍵・秘密鍵の対及び公開の暗号パラメータにより保証される請求項１に記載の方法。
9. 暗号パラメータが識別子に基づく秘密鍵生成器から受信される請求項８に記載の方法。
10. 電気通信システムにおいて近隣発見を保護するためのシステムであって、
    ホストのインターネットプロトコルアドレス値を使用することにより公開鍵が生成され、前記公開鍵から秘密鍵が生成され、前記公開鍵と前記秘密鍵が前記近隣発見を保護するために使用される、ルータと接続されたホスト
    を備えることを特徴とするシステム。
11. 前記ホストが前記公開鍵を生成する請求項１０に記載のシステム。
12. 前記ホストが前記秘密鍵を受信する請求項１０に記載のシステム。
13. 前記秘密鍵がセキュアチャンネルを介して受信される請求項１２に記載のシステム。
14. 前記秘密鍵が識別子に基づく秘密鍵生成器によって生成される請求項１２に記載のシステム。
15. ルータが前記公開鍵を生成する請求項１０に記載のシステム。
16. ルータが識別子に基づく秘密鍵生成器によって生成された前記秘密鍵をセキュアチャンネルを介して受信する請求項１０に記載のシステム。
17. 前記近隣発見が、公開鍵・秘密鍵の対と公開の暗号パラメータによって保証される請求項１０に記載のシステム。
18. 前記暗号パラメータが識別子に基づく秘密鍵生成器から受信される請求項１７に記載のシステム。
19. 電気通信システムで使用されるホストであって、
    ホストのインターネットプロトコルアドレス値を使用することにより公開鍵が生成され、前記公開鍵から秘密鍵が生成され、前記公開鍵と前記秘密鍵が近隣発見を保護するために使用されるルータとホストを接続することができるインターフェース
    を備えることを特徴とするホスト。
20. 前記公開鍵を生成するために適合される請求項１９に記載のホスト。
21. 秘密鍵を受信するために適合される請求項１９に記載のホスト。
22. 前記秘密鍵がセキュアチャンネルを介して受信される請求項２１に記載のホスト。
23. 前記秘密鍵が識別子に基づく秘密鍵生成器によって生成される請求項２１に記載のホスト。
24. 前記ルータが前記公開鍵を生成する請求項１９に記載のホスト。
25. 前記ルータが、識別子に基づく秘密鍵生成器により生成された前記秘密鍵をセキュアチャンネルを介して受信するために適合された請求項１９に記載のホスト。
26. 前記近隣発見が、公開鍵・秘密鍵の対及び公開の暗号パラメータにより保証される請求項１９に記載のホスト。
27. 前記暗号パラメータが、識別子に基づく秘密鍵生成器から受信される請求項２６に記載のホスト。

Images