(57)【要約】【課題】モビリティ管理のためのモバイルＩＰｖ６（インターネット・プロトコル・バージョン６）またはアドレス供給のためのＤＨＣＰを利用するＩＰｖ６ノードが、自分自身で、または、ＳＥＮＤプロトコルによるプロキシを介して、ネットワークアドレスをセキュアに要求および保護することを可能とする。【解決手段】ネットワークノードは、ネットワークアドレスを要求および保護するメッセージを署名・検証する。要求および保護されるネットワークアドレスは自動設定されてもよいし、もしくは、ＤＨＣＰｖ６プロトコルを用いてサーバから取得されてもよい。ＭＣＧＡがモバイルＩＰｖ６ノードによってモバイルＩＰｖ６ホームアドレスとして生成される場合、当該ＭＣＧＡは、モバイルノードがホームリンク外に移動した後、モバイルＩＰｖ６ホームエージェントによってセキュアにプロキシされる。しかしながら、ＭＣＧＡが外部のサブネットにいるモバイルＩＰｖ６ノードによってモバイルＩＰｖ６気付アドレスとして生成される場合、当該ＭＣＧＡは、モバイルノードがリンクに移動する前には新規アクセスルータによって、リンクから移動した後は現アクセスルータによって、セキュアにプロキシされる。
2008541566.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークデバイスのためのネットワークアドレスを取得する方法であって、
前記ネットワークデバイスからサーバに対して、前記ネットワークデバイスに関連付けられている公開鍵を含む、前記ネットワークアドレスの要求を送信する工程と、
前記ネットワークデバイスに関連付けられている前記公開鍵と前記サーバに関連付けられている公開鍵とを用いて生成された前記ネットワークアドレスを、前記サーバから受信する工程とを有することを特徴とする方法。
【請求項２】
サーバが、ネットワークデバイスに対してネットワークアドレスを提供する方法であって、
前記ネットワークデバイスから、前記ネットワークデバイスに関連付けられている公開鍵を含む、前記ネットワークアドレスの要求を受信する工程と、
前記ネットワークデバイスに関連付けられている前記公開鍵と前記サーバに関連付けられている公開鍵とを用いて生成された前記ネットワークアドレスを、前記ネットワークデバイスに送信する工程とを有することを特徴とする方法。
【請求項３】
移動端末が、プロキシによって保護可能なネットワークアドレスを生成する方法であって、
前記プロキシに対して要求を送信する工程と、
前記要求に応じて、前記プロキシから、前記移動端末に関連付けられている公開鍵と前記移動端末に関連付けられている署名とを含む応答を受信する工程と、
前記移動端末に関連付けられている前記公開鍵と前記プロキシに関連付けられている公開鍵とから前記ネットワークアドレスを生成する工程とを有することを特徴とする方法。
【請求項４】
プロキシが、移動端末に関連付けられているネットワークアドレスを提供する方法であって、
前記移動端末から要求を受信する工程と、
前記要求に応じて、前記移動端末に関連付けられている署名を含む応答を前記移動端末に送信する工程と、
前記移動端末から、前記移動端末に関連付けられている公開鍵と前記プロキシに関連付けられている公開鍵とを用いて生成された前記ネットワークアドレスを受信する工程とを有することを特徴とする方法。
【請求項５】
ネットワークデバイスに関連付けられている公開鍵をサーバに提供することによって、前記サーバからのネットワークアドレスを要求するネットワークデバイスと、
前記要求を受信した場合、前記ネットワークデバイスに関連付けられている前記公開鍵と前記サーバに関連付けられている公開鍵とを用いて前記ネットワークアドレスを生成するサーバとを具備することを特徴とするシステム。
【請求項６】
ネットワーク端末と
前記ネットワーク端末からの要求を受信した場合、前記ネットワーク端末に対して、前記ネットワーク端末に関連付けられている公開鍵と、プロキシに関連付けられている公開鍵とを提供するプロキシとを具備し、
前記プロキシに関連付けられている前記公開鍵は、該ネットワーク端末に関連付けられている前記公開鍵と該プロキシに関連付けられている前記公開鍵とを用いて前記ネットワーク端末がネットワークアドレスを生成可能とするために提供されることを特徴とするシステム。
【請求項７】
ネットワークデバイスに関連付けられている公開鍵を含む、前記ネットワークデバイスからサーバに対するネットワークアドレスの要求を受信し、
前記サーバから、前記ネットワークデバイスの前記公開鍵と前記サーバに関連付けられている公開鍵とを用いて生成された前記ネットワークアドレスを送信する、コンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
【請求項８】
移動端末からの要求を受信し、
プロキシから、前記要求に応じた応答を送信する、コンピュータ実行可能命令を有し、
前記応答は、前記移動端末に関連付けられているリング署名を含み、前記移動端末に関連付けられている公開鍵と前記プロキシに関連付けられている第二公開鍵とから前記移動端末がネットワークアドレスを生成することを可能とすることを特徴とするコンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
（関連出願の説明）
本願は、「マルチ鍵暗号化生成アドレスを用いたセキュアなアドレスプロキシ」と題される米国仮特許出願第６０／６７７，１３８号（出願日：２００５年５月２日、譲受人：本願と同一）に関連し、該出願に対する優先権を主張する。本願は、「マルチ鍵暗号化生成アドレス」と題される同時係属中の特許出願（「同時係属出願」）（出願日：本願と同一、出願者：本願の発明者ら、譲受人：本願の現譲受人）にも関連する。当該同時係属出願は、その全体が本願明細書中において参照のために援用される。
【０００２】
本発明は、コンピューターネットワークにおいて、ノードのためのネットワークアドレスのセキュアな要求と保護とに関する。特に、本発明は、ネットワークアドレスを生成するネットワークノード以外のネットワークノードによる、当該ネットワークアドレスのセキュアな要求と保護と要求に関する。
【背景技術】
【０００３】
「インターネットプロトコルにおけるアドレスメカニズム」と題される米国特許出願第2002/0133607号公報（以下「Nikander出願」）では、一方向符号化関数を用いて、インターネットプロトコル（ＩＰ）アドレスを、当該ＩＰアドレスを要求するホストに個別の１つ以上の要素から生成することが開示されている。Nikander出願において、当該ホストからのメッセージの受信者は、当該要素を用いて、ＩＰアドレスの再構成および確認を行う。当該IPアドレスの要求ホストは、認証プロトコルまたは公開鍵暗号プロトコルを用いて、メッセージデータの完全性、すなわち、上記要素と上記アドレスとの関連付けを確立する。
【０００４】
「メッセージの片方向認証のための方法およびシステム」と題される米国特許出願第2002/0152384号公報（以下「Schelest出願」）では、要求ホストの公開鍵をハッシュ化して、ＩＰバージョン６（ＩＰｖ６）アドレスを取得することが開示されている。Schelest出願では、要求ホストからのメッセージの受信者は、ＩＰｖ６アドレスのハッシュを確認し、メッセージ中の暗号署名を確認することで、そのデータの完全性を検証する。ＩＰｖ６アドレスと添付されている署名との両方が検証された場合、受信者は、当該ＩＰｖ６アドレスの所有についてのホストの要求を受け入れる。
【０００５】
「暗号に基づく識別子（ＣＢＩＤｓ）：概念および応用」（以下「Montenegro論文」）（Ｇａｂｒｉｅｌ  ＭｏｎｔｅｎｅｇｒｏおよびＣｌａｕｄｅ  Ｃａｓｔｅｌｌｕｃｉａ、  ＡＣＭ  Ｔｒａｎｓａｃｔｉｏｎｓ  ｏｎ  Ｉｎｆｏｒｍａｔｉｏｎ  ａｎｄ  Ｓｙｓｔｅｍ  Ｓｅｃｕｒｉｔｙ、２００４年２月）では、暗号化生成識別子の分野についての検討と、一つのホストがアドレスの利用権限を要求するための認証を確立する場合の当該暗号化生成識別子の利用についての検討とが行われている。
【０００６】
「モバイルＩＰにおけるアドレス化機構」と題される米国特許出願第2003/00849293号公報（以下「Arkko出願」）では、アドレスが生成される場合に、所有者ノードが、第２ノードに対して、そのＩＰアドレスに対する責任を委譲することが開示されている。Arkko出願では、ＩＰアドレスは、上記Nikander出願またはSchelest出願に開示される方法を用いて、暗号化生成されてもよい。Arkko出願に記載の方法によれば、所有者ノードは、第二ノードから、公開鍵・秘密鍵ペアのうちの公開鍵を取得し、取得した公開鍵に所有者ノード自身の秘密鍵を用いて署名することによって、認証証明書を生成する。その後、認証証明書は、第二ノードに提供する。なお、当該第二ノードは、当該認証証明書を、所有者ノードのＩＰアドレスに係るメッセージに含めて配信してもよい。第二ノードは、当該第二ノードの秘密鍵を用いて、当該認証証明書を含むメッセージに署名する。受信者ノードは、第二ノードの公開鍵を用いて当該メッセージを検証し、また、所有者ノードの公開鍵を用いて認証証明書を検証する。アドレスの暗号化ハッシュによって、所有者ノードのアドレスに対する権限が検証され、認証証明書内の検証された第二ノードの公開鍵によって、所有者ノードに代わって第二ノードがメッセージを送信する権限が確立される。
【０００７】
IETF Request for Comment (RFC) 3972（Thomas Aura、２００５年３月）では、暗号的にＩＰｖ６アドレスの生成し、近隣探索プロトコル（ＲＦＣ２４６１およびＲＦＣ２４６２）におけるＩＰｖ６アドレスの認証の要求をセキュアにすることが開示されている。ＩＰｖ６アドレスは、所有者ノードの公開鍵の暗号化ハッシュと付加的情報との両方を用いて生成される。６４ビットの暗号化ハッシュは、ＩＰｖ６アドレスのインターフェース識別子として機能する。
【０００８】
「メッセージの片方向認証のための方法およびシステム」と題される米国特許出願第2002/0152380号公報（以下「O’Shea出願」）では、Schelest出願に記載されているように、公開鍵を単一のホストに使用し、モバイルＩＰｖ６ホームアドレスと気付アドレスとを暗号的に生成することが開示されている。ホームネットワークにおけるモバイルＩＰｖ６ホームエージェントは、モバイルノードがホームサブネット外にある場合、ホームアドレス宛てのデータパケットを気付アドレスへ転送する。モバイルノードは、ホームアドレスを経由してではなく、直接気付アドレスにパケットを送信するよう、通信相手のノードに要求してもよい。かかる要求により、ルーティング性能、すなわち「ルート最適化のためのバインディング更新」と呼ばれる処理が向上する。このようなシグナリングによるルーティングの最適化には、モバイルノードによる新規気付アドレスの要求が認証されているという証明が必要である。当該証明は、ネットワークアドレスの暗号特性とシグナリングパケットに対する公開鍵署名とを用いて提供することが可能である。モバイルノードは、ネットワークアドレスを生成するのに使用した公開鍵に対応する秘密鍵を用いて、バインディング更新シグナリングパケットに署名する。当該シグナリングパケットは、送信元アドレスとして、新しく暗号化生成された気付アドレスを設定して送信される。また、シグナリングパケットには、暗号化生成されたホームアドレスと、公開鍵とが含まれる。シグナリングパケットを受信後、通信相手のノードは、送信元アドレスとホームアドレスとが、パケットに含まれる公開鍵から生成可能かどうかを確認し、その後署名を検証する。送信元アドレスと公開鍵との両方が予想通りである場合、通信相手のノードはそのシグナリングパケットを受け入れる。
【０００９】
ＲＦＣ３９７１（Jari Arkko, James Kempf,  Brian Zill及びPekka Nikander、２００５年３月）では、ネットワークアドレスのセキュアな広告及び保護や、最終ホップＩＰルータのセキュアな検索のために、ＩＰｖ６近隣探索プロトコル（Neighbor Discovery Protocol）（ＲＦＣ２４６１および２４６２参照）を拡張することが開示されている。ノードは、ＲＦＣ３９７２に記載のアルゴリズムに従って、暗号化生成アドレスを生成し、ＲＳＡ署名を近隣広告パケット（Neighbor Advertisement packets）に付与する。近隣広告パケットは、アドレスの利用権限を要求する。当該要求は、アドレスの暗号特性によって検証され、パケット上の署名は、パケットのデータ送信元の認証を確立する。この結果、受信ノードは、要求された送信元アドレスからパケットが送信されたことを信頼することができる。そして、メッセージは、ネットワークアドレスを要求するための認証を確立する。さらに、ＳＥＮＤプロトコルは、最終ホップルータの検索をセキュアなものにする。ＲＦＣ３９７２には、最終ホップルータの証明書用のフォーマットが指定されている。上記証明書を有するルータは、その認証された公開鍵に対応する秘密鍵を用いて、ルータ広告メッセージ（Router Advertisement message）に署名する。最終ホップルータを要求するノードは、ルータの証明書と、当該ルータから共有のトラストルートへと戻る証明書チェーンとを取得する。ノードは、ルータの認証された鍵を用いて、ルータ広告における署名を検証し、それによって認証された最終ホップルータを取得する。
【発明の開示】
【発明が解決しようとする課題】
【００１０】
以上から、Nikander出願、Schelest出願、Montenegro論文、ＲＦＣ３９２７およびＲＦＣ３９７１が関連しているのは、ネットワークアドレスを利用するための認証が一つのホストによって要求される場合にすぎない。しかしながら、一つ以上のホストによるアドレスの利用を認証することが必要である場合も多い。モバイルＩＰｖ６ネットワークおよびＤＨＣＰの適用では、いくつかの例がある。
【００１１】
モバイルＩＰｖ６ネットワークにおいては、モバイルノードに割り当てられるホームネットワーク上のホームアドレスを用いて、当該モバイルノードに到達することができる。ホームアドレスは、モバイルノードがインターネット上のどこに位置するかに関係なく、変化しない。モバイルノードがホームサブネット外のリモートサブネットにある場合、「ホームエージェント」（例えば、モバイルノードのホームサブネット上のルータ）は、ホームアドレス宛てのメッセージを、リモートサブネット内のローカルアドレスである「気付」アドレスに転送する。モバイルノードがホームネットワーク外にある場合、当該モバイルノードのホームアドレスを他者が要求するのを防ぐために、ホームエージェントは、当該モバイルノードのホームアドレスをプロキシ又は保護しなければならない。しかしながら、モバイルノードが、その公開鍵に関連付けられている暗号化識別子を用いてホームアドレスを生成する場合、セキュアに保護できるのはホームアドレスのみである。ホームエージェントによるプロキシ保護は、セキュリティなしに行われなければならない。
【００１２】
モバイルノードが高速モバイルＩＰｖ６（ＦＭＩＰｖ６）プロトコルを用いてハンドオーバを最適化する場合に、同様の問題がモバイルＩＰｖ６の気付アドレスにも見られる。ハンドオーバのように、モバイルノードがどのサブネットでもない場合、旧アクセスルータ上のモバイルノードの旧気付アドレス、又は、新規アクセスルータ上の新規気付アドレスが一時的に保護される必要がある。この時、モバイルノードのトラフィックパケットは、紛失されることがないように、アクセスルータ間で転送される。アクセスルータは、モバイルノードに代わって、アドレスをプロキシしなければならないが、既存の手法ではアドレスをセキュアにプロキシすることはできない。
【００１３】
ＩＰｖ６近隣探索プロトコルによれば、ホストのアドレスがＤＨＣＰ（Dynamic host configuration protocol）サーバから取得されたとしても、ホストは、依然としてネットワーク上において、当該アドレスを要求および保護する必要がある。しかしながら、上記アドレスはＤＨＣＰサーバによってホストの公開鍵なしで生成されているため、暗号化生成アドレスを用いて、上記要求および保護をセキュアに行うことはできない。また、上記アドレスはホストによって生成されたものではないため、当該ホストは、秘密鍵を用いて当該アドレスに関係するメッセージに署名することもできない。
【００１４】
一方、Arkko出願では、所有者ノードがそのアドレスの広告および保護を他者に委譲することが開示されているが、Arkko出願における解決法は煩雑なものである。Arkko出願では、所有者ノードと委譲されたノードとの両方の公開鍵に加えて、属性証明書も必要となる。アドレスを生成した後、属性証明書は、所有者ノードにより委譲されたノードに送られる。Arkko出願に記載されているように、Arkko出願における解決法によれば、要求者が、所有者ノードであるか、または委譲されたノードであるかを特定する。この情報は、所有者ホストの位置または所有者ホストに関するその他の情報を推定するために攻撃者によって利用される可能性がある。
【課題を解決するための手段】
【００１５】
本発明の一態様に係る方法によれば、ネットワークアドレスをセキュアにプロキシすることが可能である。一実施形態において、ＤＨＣＰサーバは、ＤＨＣＰクライアントからネットワークアドレスの要求を受信する。当該ＤＨＣＰクライアントは、当該ＤＨＣＰクライアントの公開鍵を上記要求に含める。当該ＤＨＣＰクライアントの公開鍵とＤＨＣＰサーバの公開鍵とを用いて、マルチ鍵暗号化生成アドレス（ＭＣＧＡ）が生成される。このＭＣＧＡが、当該ＤＨＣＰクライアントに戻される。一実施形態において、ＤＨＣＰサーバは、当該ネットワークアドレスとＤＨＣＰクライアントの公開鍵とをキャッシュに格納する。
【００１６】
本発明の他の態様によれば、要請ノードが、ネットワークアドレスの生成に用いられる複数の公開鍵を用いて、アドレスを有するノードのネットワークアドレスを確認することにより、当該ノードの権限を検証することを可能とするセキュアなプロトコルが生成される。さらに、当該アドレスを有するノードは、ネットワークアドレスを生成するのに用いられる公開鍵に対応する秘密鍵を用いた署名をその要求に含ませる。当該署名は、ネットワークアドレスを形成する全ての公開鍵を用いて形成された環状の署名であってもよい。あるいは、他の複数の署名者の一つに属する従来の公開鍵署名であってもよい。その場合、どの公開鍵が、署名を生成するのに用いられる秘密鍵に対応するかも、メッセージによって示される。
【００１７】
本発明は、ルータがネットワークアドレスをプロキシすることを可能にする方法である。当該方法は、モバイルノードの公開鍵と第二公開鍵とからネットワークアドレスを生成する工程と、ルータにネットワークアドレスをプロキシすることを要求するメッセージを送信する工程とを含む。一実施形態において、当該第二公開鍵は、ルータの公開鍵である。当該メッセージは、ルータ内のホームエージェントへのバインディング更新メッセージから構成される。あるいは、当該第二公開鍵は、予定ルータの公開鍵であってもよい。かかる場合、ネットワークアドレスは、予定気付アドレスに対応する。当該予定気付アドレスは、モバイルノードが第二ルータとのリンクに移行するまで第一ルータによってプロキシされるべき気付アドレスである。
【００１８】
本発明の一実施形態によれば、ネットワークアドレスは、モバイルノードによって自動的に設定されてもよい。あるいは、当該ネットワークアドレスは、ＤＨＣＰサーバによって生成されてもよい。当該ネットワークアドレスを生成するモバイルノードは、適切なプロトコルを用いて、ルータの公開鍵を取得してもよい。適切なプロトコルの例としては、ＳＥＮＤプロトコル、CARDプロトコル、または、モバイルノードキーごとの拡張ＩＰｖ６ルータ探索が挙げられる。モバイルノードが、プロキシを要求するメッセージに当該モバイルノードの公開鍵を含ませることによって、ルータが、当該モバイルノードの公開鍵を取得しても良い。
【００１９】
一実施形態において、ＤＨＣＰサーバは、ホームエージェントが属するルータと共同設置され、ネットワークアドレスは、モバイルノードの公開鍵と、ＤＨＣＰとホームエージェントとの共通公開鍵とを用いて生成されたＭＣＧＡである。
【００２０】
本発明は、ネットワークノードが、セキュアに、ネットワークアドレスを要求および保護するための方法である。一実施形態において、前記方法は、複数の公開鍵から形成されるネットワークアドレスのアドレス解決要求を受信する工程を備える。ここで、前記複数の公開鍵の一つは、ネットワークノードの公開鍵である。当該方法では、当該アドレス解決要求の送信者にメッセージを送信することにより、当該アドレス解決要求に応答する。当該メッセージには、上述の複数の公開鍵が添付されている。当該アドレス解決要求の送信者は、受信した複数の公開鍵を用いてネットワークアドレスを確認し、当該ネットワークノードの秘密鍵を用いて署名されているメッセージの署名を検証する。
【００２１】
このように、本発明によれば、モビリティ管理のためのモバイルＩＰｖ６またはアドレス供給のためのＤＨＣＰを利用するＩＰｖ６ノードは、自分自身で、または、例えば、SENDプロトコルを用いたプロキシを介して、アドレスをセキュアに要求および保護することが可能である。
【発明を実施するための最良の形態】
【００２２】
本発明に関しては、添付図面と共に考察されることで、より良い理解が得られる。
【００２３】
本発明によれば、モビリティ管理のためのモバイルＩＰｖ６（インターネット・プロトコル・バージョン６）またはアドレス供給のためのＤＨＣＰを利用するＩＰｖ６ノードは、自分自身で、または、ＳＥＮＤプロトコルを使ったプロキシを介して、ネットワークアドレスをセキュアに要求および保護することが可能である。例えば、一実施形態によると、ＩＰｖ６ネットワークノードは、上記参照により援用される同時係属出願に記載されている適切な方法で、マルチ鍵暗号化生成ＩＰｖ６アドレス（ＭＣＧＡ）を生成または取得する。また、ネットワークノードは、ＳＥＮＤプロトコルに基づきネットワークアドレスを要求および保護するためのメッセージに署名し、当該メッセージを検証してもよい。要求および保護されるネットワークアドレスは自動設定されてもよいし、もしくは、ＤＨＣＰｖ６プロトコルを用いてサーバから取得されてもよい。上記ＭＣＧＡが、モバイルＩＰｖ６ノードによって、モバイルＩＰｖ６ホームアドレスとして生成される場合、当該ＭＣＧＡは、モバイルＩＰｖ６ホームエージェントによって、モバイルノードがホームリンクを離れた後に、セキュアにプロキシされる。一方、上記ＭＣＧＡが、外部のサブネットにいるモバイルＩＰｖ６ノードによって、モバイルＩＰｖ６気付アドレスとして生成される場合、当該ＭＣＧＡは、現アクセスルータまたは新規アクセスルータによって、それぞれ、モバイルノードがリンクに到着する前とリンクから離れた後とにセキュアにプロキシされる。
【００２４】
図１は、ＤＨＣＰサーバからＤＨＣＰを用いてＭＣＧＡを取得することによって、ネットワークノード（例えば、ＩＰｖ６ノード）がSENDプロトコルを用いて当該ＭＣＧＡをセキュアに要求および保護することが可能となる動作を示す図である。図１に示すように、ステップ１０１において、ＩＰｖ６ノード（例えば、ノードＡ）は、ＤＨＣＰサーバを探索するために、ＲＦＣ３３１５に従って、ＩＰｖ６のマルチキャストアドレス「Ａｌｌ＿ＤＨＣＰ＿Ｒｅｌａｙ＿Ａｇｅｎｔｓ＿ａｎｄ＿Ｓｅｒｖｅｒｓ」宛のＤＨＣＰ要請メッセージ（DHCP Solicit message）をマルチキャストする。それに応じて、ステップ１０２において、ＤＨＣＰサーバ（例えば、ノードＢ）、または、任意的には、ノードＢと通信するリレーエージェントは、ＤＨＣＰ広告メッセージ（DHCP Advertise message）によって、ノードＡからのＤＨＣＰ要請メッセージに応答する。ステップ１０３において、ノードＡは、ＤＨＣＰ広告メッセージに応じて、ＤＨＣＰ要求メッセージ（DHCP Request message）をノードＢに送信する。当該ＤＨＣＰ要求メッセージは、新規ＤＨＣＰアドレス公開鍵オプションの中に、ノードＡの公開鍵を含む。ステップ１０４において、ＤＨＣＰサーバＢは、ノードＡの公開鍵および自身の公開鍵（すなわち、Ｂの公開鍵）を用いて、ＭＣＧＡ（「アドレスＡＢ」）を生成する。このＭＣＧＡは、例えば、同時係属出願またはＲＦＣ３９７２に記載されている適切な方法で生成されてもよい。ステップ１０５において、ＤＨＣＰサーバＢは、後で参照できるように、アドレスＡＢとＡの公開鍵との関連付けを記録する。その後、ステップ１０６において、ＤＨＣＰサーバＢは、ＤＨＣＰ応答メッセージ（DHCP Reply message）により、アドレスＡＢをノードＡに送り返す。当該ＤＨＣＰ応答メッセージにおいて、ノードＢは、ＤＨＣＰアドレス公開鍵オプションの中に、Ｂの公開鍵を含める。ステップ１０７において、ＤＨＣＰ応答メッセージの受信後、ノードＡは、アドレスＡＢを、送信元アドレスとして、ＩＰトラフィックのために利用することが可能である。また、ノードＡは、以下に詳しく説明されるように、Ａの公開鍵と、Ｂの公開鍵と、（Ａの公開鍵に対応する）Ａの秘密鍵とを用いて、ネットワークアドレ
スをセキュアに要求および保護する近隣検索メッセージ（Neighbor Discovery message）に署名してもよい。攻撃者によるＡの公開鍵を用いた要求・応答の交換に対するスプーフィングを防止するために、ノードＡおよびＢは、ＤＨＣＰメッセージ用のＲＦＣ３１１８認証、または、ＲＦＣ３３１５に記載されるような遅延認証を活用してもよい。
【００２５】
また、ＤＨＣＰサーバＢは、ネットワークアドレスの暗号特性を利用して、ＤＨＣＰ更新などの、ネットワークアドレス上の動作が許可されているかどうかを確認することもできる。このため、ノードＡは、Ａの公開鍵をメッセージに含め、Ａの秘密鍵で当該メッセージに署名する。ＤＨＣＰサーバＢは、同時係属出願に記載されているように、要求された動作を行う前に、Ａの公開鍵がネットワークアドレスの構成要素であるかどうかと当該署名が正しいかどうかとを確認する。
【００２６】
図２では、モバイルＩＰｖ６モバイルノードが、ＳＥＮＤプロトコルを用いてプロキシ（モバイルＩＰｖ６ホームエージェント、または、ＦＭＩＰｖ６アクセスルータ）によりセキュアに要求および保護できるＭＣＧＡを自動設定する動作を示す。図２では、ＩＰｖ６ノード自身の鍵とルータ（例えば、モバイルＩＰｖ６ホームエージェント、または、ＦＭＩＰｖ６アクセスルータ）の鍵とを用いて、ＭＣＧＡを自動設定するＩＰｖ６ノードを示す。ＩＰｖ６ノードの要求に応じて、ルータは、そのプロキシとして機能してもよい。ＲＦＣ３９７１に従って、ＩＰｖ６ノードＡは、ＳＥＮＤプロトコルを用いたルータ要請（Router Solicitation）をルータに送信する（ステップ２０１）。ルータ（すなわち、ノードＢ）は、ルータ広告メッセージ（Router Advertisement message）で応答する（ステップ２０２）。当該ルータ広告メッセージには、ルータの認証された公開鍵と、モバイルノードのために個別に生成された公開鍵（Ｂの公開鍵）とを用いて構成されるリング署名が付与されている。当該署名は、ＲＦＣ３９７１により、ＳＥＮＤ ＲＳＡ署名オプションに挿入されている。ルータ広告メッセージの送信元アドレスは、ＭＣＧＡとして生成されるＩＰｖ６リンクローカルアドレスである。ルータの認証済みの公開鍵とＢの公開鍵とは、ＲＦＣ３７９２における拡張SEND ＣＧＡパラメタオプションに含まれる。ノードＡは、ＲＦＣ３９７１に従って、ルータの証明書チェーンを、まだ保持していなければ取得する（ステップ２０３）。ノードＡは、認証された公開鍵とＢの公開鍵とを用いて、ルータ広告上のＲＳＡリング署名を検証する（ステップ２０４）。そして、ノードＡは、Ａの公開鍵とＢの公開鍵とを連結することによって、ＭＣＧＡ（すなわち、アドレスＡＢ）を構築する（ステップ２０５）。そのようなＭＣＧＡの例は、上記参照により援用される同時係属出願に記載されている。モバイルノードのために個別に生成されたＢの公開鍵を利用することにより、リンク上の他のノードが、ＭＣＧＡ生成に用いられた公開鍵とルータの認証された鍵とを比較することによって、ルータのプロキシ中にモバイルノードがリンクから離れたところにあるかどうかを判断することを防ぐ。
【００２７】
なお、ノードＡがまだ属していないリンクのアドレスを構成している場合（例えば、ＦＭＩＰｖ６を用いている場合）、ＳＥＮＤプロトコルを用いて、公開鍵証明書を取得することはできない。かかる場合、ノードＡは、例えば、ＣＡＲＤプロトコルを用いて、公開鍵証明書とアクセスルータ（例えば、ノードＢ）のために個別に生成された鍵とを取得する。
【００２８】
このときには、アドレスＡＢは、使用され、セキュアに要求されてもよい（ステップ２０６）。ノードＡおよびＢの各々は、ＳＥＮＤプロトコルに変更を加えて、ＭＣＧＡを要求および保護してもよい。図３は、ネットワークデバイスがＳＥＮＤプロトコルを用いてアドレスＡＢを要求および保護するプロトコルを示す。図３に示すように、ステップ３０１において、アドレスＡＢが要求されるリンク上のＩＰｖ６ノード（例えば、ノードＣ）は、アドレスＡＢの解決をリンク層アドレスに要求する。なお、ノードＣは、ノードＡおよびＢのいずれかであっても、他のノードであってもよい。ノードＡは、例えば、ＲＦＣ２４６２に基づいて、重複アドレスを検出するために、アドレスＡＢの解決を要求してもよい。ルータとして、ノードＢは、データトラフィックをノードＢにルーティングするために、アドレスＡＢの解決を要求してもよい。アドレスＡＢの解決要求は、例えば、ＲＦＣ２４６１およびＲＦＣ３９７１に従って、ノードＣがＳｏｌｉｃｉｔｅｄ＿Ｎｏｄｅ＿Ｍｕｌｔｉｃａｓｔ＿Ａｄｄｒｅｓｓ宛の近隣要請メッセージ（Neighbor Solicitation message）をマルチキャストすることによって達成されてもよい。アドレスＡＢは、ターゲットアドレスとして、近隣要請メッセージに含まれる。要求および保護のためのＳＥＮＤメッセージは、ＲＦＣ３７９２の拡張ＣＧＡパラメタオプションにおける公開鍵と、ＲＦＣ３７９１のＲＳＡ署名オプションにおけるリング署名との両方を含む。
【００２９】
公開鍵がアドレスに含まれるノードは、ノードＣのアドレス解決要求に応答することができる。図３では、例えば、ノードＢがステップ３０２および３０３で応答する。ステップ３０２において、ノードＢは、ＲＦＣ２４６１およびＲＦＣ３９７１に従って、近隣広告（Neighbor Advertisement）を構成する。しかしながら、Ａの公開鍵とＢの公開鍵との両方は、標準的な暗号化生成アドレス（ＣＧＡ）オプションに挿入されるのではなく、ＭＣＧＡアドレスＡＢを生成するのに用いられる他のパラメタと共に、当該近隣広告メッセージ内の拡張ＣＧＡパラメタオプションに挿入される。ステップ３０３において、Ｂの秘密鍵を用いて、近隣広告メッセージに対する署名が算出される。この署名は、例えば、リング署名であってもよく、あるいは、Ｂの公開鍵に対応する秘密鍵によって生成された従来の公開鍵署名であってもよい。ここで、上記メッセージには、当該署名がＢの公開鍵に対応することが示されている。リング署名の例は、上記参照により援用される同時係属出願に記載されている。ステップ３０４において、ノードＢは、ノードＣに送信される近隣広告メッセージのＲＳＡ署名オプションに当該署名を含ませる。ステップ３０５において、ノードＣが、近隣広告メッセージを受信した場合、ＣＧＡパラメタオプション内の複数の公開鍵に対するアドレスＡＢを確認し、当該複数の公開鍵を用いてＲＳＡ署名オプション内の署名を検証する。同時係属出願には、そのようなＭＣＧＡを確認し、署名を検証する方法の例が開示されている。ＭＣＧＡが十分に確認され、署名が正常に検証された場合、ステップ３０６において、ノードＣが近隣広告メッセージを受領することにより、セキュアにアドレスＡＢを解決する。
【００３０】
ネットワークアドレスを要求および保護できるのはどの時点においてもリンク上の一つのノードのみである。このため、ノードＡおよびＢはお互いに調整し合って二つノードのどちらがアドレスを要求および保護するのかを決定しなければならない。図４では、モバイルＩＰｖ６モバイルノードが、ホームエージェントに対してモバイルＩＰｖ６のホームアドレスのプロキシを開始するよう要求する動作を示す。
【００３１】
モバイルＩＰｖ６ホームエージェントによるアドレスプロキシでは、図４に示すように、モバイルノード（例えば、ノードＡ）がリンク上にある場合、当該モバイルノードが、アドレスを要求し保護する。ＲＦＣ３７７５によれば、モバイルノードがリンク外に移動する場合、当該モバイルノードは、アクセスネットワークサブネット上の気付アドレスとホームアドレスとを関連付けるために、バインディング更新メッセージ（Binding Update message）をホームエージェントに送信する。ホームエージェント（すなわち、ノードＢ）は、バインディング更新メッセージを受信後、ＭＣＧＡであるホームアドレス（すなわち、アドレスＡＢ）の要求および保護を開始する。ホームエージェントがホームアドレスを要求および保護するために、ホームエージェントは、Ａの公開鍵を要求する。当該Ａの公開鍵は、ノードＡがリンク上にある間に、上述のアドレス解決処理を用いて取得されてもよい。取得された公開鍵は、アドレスＡＢと共にキャッシュに格納される。あるいは、ノードＡが、バインディング更新メッセージによって、新規気付アドレスを報告する場合（図４のステップ４０１）、ノードＡは、当該報告メッセージに含まれるバインディング更新オプションと共に、新規アドレス公開鍵モビリティサブオプションにより当該ノードＡの公開鍵を送信することが可能である。ステップ４０２において、ホームエージェント（例えば、ノードＢ）から確認メッセージが送信されると、ホームエージェントは、ホームアドレスをセキュアに要求および保護することになる（ステップ４０３）。
【００３２】
ＤＨＣＰでは、ノードＡ（例えば、ＩＰｖ６モバイルノードまたは他のＩＰｖ６ノード）は、リース期間が更新される場合を除いて、ネットワークアドレスのリース期間が終了するまで、当該ネットワークアドレスの要求および保護する。
【００３３】
ＦＭＩＰｖ６では、ノードＡ（すなわち、モバイルノード）は、ハンドオーバ前に次に接続するサブネットを把握している場合、当該ノードＡは、現アクセスルータに対して、予定気付アドレスとともに、高速バインディング更新メッセージ（Fast Binding Update message）を送信する。この予定気付アドレス（例えば、アドレスＡＢ）は、新規アクセスルータ（すなわち、ノードＢ）の公開鍵とＡの公開鍵とを用いて構成される。図３を参照して説明したように、当該複数の公開鍵は、気付アドレスの報告メッセージ内の、新規アドレス公開鍵サブオプション内で提供されてもよい。現アクセスルータは、アドレスＡＢを含むハンドオーバ開始メッセージを、新規アクセスルータ（例えば、ノードＢ）に送信する。新規アクセスルータがアドレスＡＢを受け入れる場合、当該新規アクセスルータは、ノードＡが新規リンクへと移動するまで、アドレスＡＢをセキュアに要求し、保護する。ノードＡが新規リンクへと移動した場合、当該ノードＡは、新規リンク上で、高速近隣広告メッセージ（Fast Neighbor Advertise message）を送信する。新規アクセスルータは、当該メッセージを受信後、アドレスＡＢのプロキシを停止する。
【００３４】
ＦＭＩＰｖ６では、ノードＡは、ハンドオーバ前に次に接続するサブネットを把握していない場合、当該ノードＡは、新規リンクへ移動してから新規気付アドレスを生成する。旧気付アドレス（例えば、アドレスＡＢ）は、現アクセスルータ（例えば、ノードＢ）の認証された公開鍵とＡの公開鍵とを用いて、ＭＣＧＡとして構成される。ノードＡは、高速バインディング更新メッセージを旧アクセスルータに送信する。当該高速バインディング更新メッセージは、新規気付アドレスと、旧気付アドレス（例えば、アドレスＡＢ）と、新規アドレス公開鍵サブオプション内のＡの公開鍵とを含む。ＦＭＩＰｖ６プロトコルでは、この高速バインディング更新メッセージを受信後、旧アクセスルータは、アドレスＡＢで受信したトラフィックを、新規サブネット上の新規気付アドレスに転送する。旧アクセスルータは、転送期間が失効するまでアドレスＡＢをセキュアに要求および保護し続ける。
【００３５】
ＩＰｖ６モバイルホスト（例えば、ノードＡ）がＤＨＣＰを利用してアドレスＡＢを取得する場合、ＤＨＣＰサーバによってアドレスＡＢが生成される場合でも、モバイルＩＰｖ６ホームエージェントまたはＦＭＩＰｖ６アクセスルータは、アドレスＡＢのプロキシとなることが可能である。一実施形態において、上記プロキシを可能とするために、ホームエージェントまたはアクセスルータは、ＤＨＣＰサーバと共同設置してもよい。当該共同設置により、ＤＨＣＰサーバと、ホームエージェントまたはアクセスルータとは、同一の認証された公開鍵を共有することができる。この場合、ＤＨＣＰサーバは、ＤＨＣＰアドレス公開鍵オプションにフラグを立てることによって、ホームエージェントまたはアクセスルータが共同設置されていることを示す。あるいは、モバイルノード（例えば、ノードＡ）がプロキシを要求する場合、当該ノードＡは、ホームエージェントまたはアクセスルータに対して、ＤＨＣＰサーバの公開鍵とノードＡ自身の公開鍵との両方を送信する。この場合、ＤＨＣＰアドレス公開鍵オプション内にフラグが立てられていないので、ノードＡは、プロキシを要求する際に、バインディング更新メッセージまたは高速バインディング更新メッセージと共に、二つの鍵を送信する。
【００３６】
以上の詳細な説明は本発明の具体的な実施例を説明するためのものであり、本発明を限定するものではない。本発明の範囲内で多種多様の変形や変更が可能である。本発明は添付図面に記載されている。
【図面の簡単な説明】
【００３７】
【図１】ＤＨＣＰサーバからＤＨＣＰを用いてＭＣＧＡを取得することによって、ネットワークノード（例えば、ＩＰｖ６ノード）がSENDプロトコルを用いて当該ＭＣＧＡをセキュアに要求および保護することが可能となる動作を示す図である。
【図２】モバイルＩＰｖ６モバイルノードが、プロキシ（モバイルＩＰｖ６ホームエージェント、または、ＦＭＩＰｖ６アクセスルータ）によって「SEND」を用いてセキュアに要求および保護できるＭＣＧＡを自動設定する動作を示す図である。
【図３】「SEND」を用いてＭＣＧＡを要求および保護するネットワークデバイスを示す図である。
【図４】モバイルＩＰｖ６モバイルノードが、ホームエージェントに対してホームアドレスのプロキシを開始するよう要求する動作を示す図である。
【図１】
2008541566.tif 000003
【図２】
2008541566.tif 000004
【図３】
2008541566.tif 000005
【図４】
2008541566.tif 000006
【手続補正書】
【提出日】平成20年1月7日(2008.1.7)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークデバイスのためのネットワークアドレスを取得する方法であって、
前記ネットワークデバイスからサーバに対して、前記ネットワークデバイスに関連付けられている公開鍵を含む、前記ネットワークアドレスの要求を送信する工程と、
前記ネットワークデバイスに関連付けられている前記公開鍵と前記サーバに関連付けられている公開鍵とを用いて生成された前記ネットワークアドレスを、前記サーバから受信する工程とを有することを特徴とする方法。
【請求項２】
前記ネットワークデバイスにより送信されるメッセージの送信元アドレスとして、前記ネットワークアドレスを使用する工程をさらに有することを特徴とする請求項１に記載の方法。
【請求項３】
前記ネットワークアドレスの前記要求を送信する工程と前記サーバから前記ネットワークアドレスを受信する工程との間に、前記サーバと前記ネットワークデバイスとが、認証メッセージを交換することを特徴とする請求項１に記載の方法。
【請求項４】
前記サーバから受信した前記ネットワークアドレスは、所定期間後に失効し、
前記ネットワークデバイスが、前記ネットワークデバイスに関連付けられている秘密鍵を用いて署名された更新要求を前記サーバに対して送信することによって、前記ネットワークアドレスのための前記所定期間を更新する工程をさらに有することを特徴とする請求項１に記載の方法。
【請求項５】
サーバが、ネットワークデバイスに対してネットワークアドレスを提供する方法であって、
前記ネットワークデバイスから、前記ネットワークデバイスに関連付けられている公開鍵を含む、前記ネットワークアドレスの要求を受信する工程と、
前記ネットワークデバイスに関連付けられている前記公開鍵と前記サーバに関連付けられている公開鍵とを用いて生成された前記ネットワークアドレスを、前記ネットワークデバイスに送信する工程とを有することを特徴とする方法。
【請求項６】
前記ネットワークアドレスの前記要求を受信する工程と前記ネットワークデバイスに対して前記ネットワークアドレスを送信する工程との間に、前記サーバと前記ネットワークデバイスとが、認証メッセージを交換することを特徴とする請求項５に記載の方法。
【請求項７】
前記ネットワークアドレスは所定期間後に失効し、
前記ネットワークアドレスのための前記所定期間の更新要求を受信する工程をさらに具備し、
前記更新要求は、前記ネットワークデバイスに関連付けられている秘密鍵を用いて署名されていることを特徴とする請求項５に記載の方法。
【請求項８】
前記更新要求における、前記ネットワークデバイスの署名を検証する工程をさらに有することを特徴とする請求項７に記載の方法。
【請求項９】
前記ネットワークアドレスが前記ネットワークデバイスに関連付けられている前記公開鍵を用いて生成されたかどうかを判定する工程をさらに有することを特徴とする請求項７に記載の方法。
【請求項１０】
移動端末が、プロキシによって防御可能なネットワークアドレスを生成する方法であって、
前記プロキシに対して要求を送信する工程と、
前記要求に応じて、前記プロキシから、前記移動端末に関連付けられている公開鍵と前記移動端末に関連付けられている署名とを含む応答を受信する工程と、
前記移動端末に関連付けられている前記公開鍵と前記プロキシに関連付けられている公開鍵とから前記ネットワークアドレスを生成する工程とを有することを特徴とする方法。
【請求項１１】
前記応答に含まれる前記署名は、前記プロキシに関連付けられている前記公開鍵と前記移動端末に関連付けられている前記公開鍵とに対応するリング署名から構成されることを特徴とする請求項１０に記載の方法。
【請求項１２】
前記応答に含まれる前記署名は、前記応答に含まれる前記移動端末に関連付けられている前記公開鍵に対応する秘密鍵を用いて生成された従来の公開鍵署名から構成され、
前記応答は、前記署名を検証可能な前記移動端末の前記公開鍵を示すことを特徴とする請求項１０に記載の方法。
【請求項１３】
前記プロキシに関連付けられている第一公開鍵は、認証された公開鍵であることを特徴とする請求項１０に記載の方法。
【請求項１４】
前記ネットワークアドレスに関するアドレス解決要求を受信する工程をさらに有することを特徴とする請求項１０に記載の方法。
【請求項１５】
バインディング更新メッセージによって、前記プロキシに対してホームエージェントとなるように要求する工程をさらに有することを特徴とする請求項１０に記載の方法。
【請求項１６】
前記ネットワークアドレスを要求する要求を受信する工程をさらに有することを特徴とする請求項１５に記載の方法。
【請求項１７】
前記バインディング更新メッセージは、高速バインディング更新メッセージであることを特徴とする請求項１５に記載の方法。
【請求項１８】
前記バインディング更新メッセージは、予定ネットワークアドレスを含むことを特徴とする請求項１５に記載の方法。
【請求項１９】
プロキシが、移動端末に関連付けられているネットワークアドレスを提供する方法であって、
前記移動端末から要求を受信する工程と、
前記要求に応じて、前記移動端末に関連付けられている署名を含む応答を前記移動端末に送信する工程と、
前記移動端末から、前記移動端末に関連付けられている公開鍵と前記プロキシに関連付けられている公開鍵とを用いて生成された前記ネットワークアドレスを受信する工程とを有することを特徴とする方法。
【請求項２０】
前記応答に含まれる前記署名は、前記プロキシに関連付けられている前記公開鍵と前記移動端末に関連付けられている前記公開鍵とに対応するリング署名から構成されることを特徴とする請求項１９に記載の方法。
【請求項２１】
前記応答に含まれる前記署名は、前記応答に含まれる前記移動端末に関連付けられている前記公開鍵に対応する秘密鍵を用いて生成された従来の公開鍵署名から構成され、
前記応答は、前記署名を検証可能な前記移動端末の前記公開鍵を示すことを特徴とする請求項１９に記載の方法。
【請求項２２】
前記プロキシに関連付けられている第一公開鍵は、認証された公開鍵であることを特徴とする請求項１９に記載の方法。
【請求項２３】
前記ネットワークアドレスは、前記プロキシに対して前記移動端末のホームエージェントになるように要求するバインディング更新メッセージによって、前記移動端末から受信されることを特徴とする請求項１９に記載の方法。
【請求項２４】
前記バインディング更新メッセージは、高速バインディング更新メッセージであることを特徴とする請求項２３に記載の方法。
【請求項２５】
前記バインディング更新メッセージは、予定ネットワークアドレスを含むことを特徴とする請求項２３に記載の方法。
【請求項２６】
前記ネットワークアドレスを要求する工程をさらに有することを特徴とする請求項２１に記載の方法。
【請求項２７】
前記端末アドレスに関するアドレス解決要求を受信する工程をさらに有することを特徴とする請求項２６に記載の方法。
【請求項２８】
前記プロキシに関連付けられている秘密鍵を用いて署名されたメッセージによって、前記アドレス解決要求に応じる工程をさらに有することを特徴とする請求項２７に記載の方法。
【請求項２９】
ネットワークデバイスに関連付けられている公開鍵をサーバに提供することによって、前記サーバからのネットワークアドレスを要求するネットワークデバイスと、
前記要求を受信した場合、前記ネットワークデバイスに関連付けられている前記公開鍵と前記サーバに関連付けられている公開鍵とを用いて前記ネットワークアドレスを生成するサーバとを具備することを特徴とするシステム。
【請求項３０】
前記ネットワークデバイスは、前記ネットワークデバイスにより送信されるメッセージの送信元アドレスとして、前記ネットワークアドレスを使用することを特徴とする請求項２９に記載のシステム。
【請求項３１】
前記サーバから受信した前記ネットワークアドレスは、所定期間後に失効し、
前記ネットワークデバイスは、前記ネットワークデバイスに関連付けられている秘密鍵を用いて署名された更新要求を前記サーバに対して送信することによって、前記ネットワークアドレスのための前記所定期間を更新することを特徴とする請求項２９に記載のシステム。
【請求項３２】
前記サーバは、前記ネットワークアドレスを更新する前に、前記ネットワークアドレスが前記ネットワークデバイスの前記公開鍵を用いて生成されたかどうかを判断することを特徴とする請求項31に記載のシステム。
【請求項３３】
ネットワーク端末と
前記ネットワーク端末からの要求を受信した場合、前記ネットワーク端末に対して、前記ネットワーク端末に関連付けられている公開鍵と、プロキシに関連付けられている公開鍵とを提供するプロキシとを具備し、
前記プロキシに関連付けられている前記公開鍵は、該ネットワーク端末に関連付けられている前記公開鍵と該プロキシに関連付けられている前記公開鍵とを用いて前記ネットワーク端末がネットワークアドレスを生成可能とするために提供されることを特徴とするシステム。
【請求項３４】
前記移動端末は、前記ネットワークアドレスに関するアドレス解決要求を処理することを特徴とする請求項３３に記載のシステム。
【請求項３５】
前記プロキシは、前記ネットワークアドレスに関するアドレス解決要求を処理することを特徴とする請求項３３に記載のシステム。
【請求項３６】
前記プロキシは、バインディング更新メッセージを受信した場合、前記移動端末のホームエージェントとなることを特徴とする請求項３３に記載のシステム。
【請求項３７】
前記バインディング更新メッセージは、高速バインディング更新メッセージであることを特徴とする請求項３６に記載のシステム。
【請求項３８】
前記バインディング更新メッセージは、予定ネットワークアドレスを含むことを特徴とする請求項３６に記載のシステム。
【請求項３９】
前記プロキシは、前記プロキシに関連付けられている秘密鍵を用いて署名されたメッセージによって、アドレス解決要求に応じることを特徴とする請求項３５に記載のシステム。
【請求項４０】
ネットワークデバイスに関連付けられている公開鍵を含む、前記ネットワークデバイスからサーバに対するネットワークアドレスの要求を受信し、
前記サーバから、前記ネットワークデバイスの前記公開鍵と前記サーバに関連付けられている公開鍵とを用いて生成された前記ネットワークアドレスを送信する、コンピュータ実行可能命令を有することを特徴とするコンピュータ可読媒体。
【請求項４１】
前記サーバと前記ネットワークデバイスとの間で認証メッセージを交換する、コンピュータ実行可能命令をさらに有することを特徴とする請求項４０に記載のコンピュータ可読媒体。
【請求項４２】
前記サーバから受信した前記ネットワークアドレスは、所定期間後に失効し、
前記ネットワークデバイスが、前記ネットワークデバイスに関連付けられている秘密鍵を用いて署名された更新要求を前記サーバに送信することによって、前記ネットワークアドレスの前記所定期間を更新する、コンピュータ実行可能命令をさらに有することを特徴とする請求項４０に記載のコンピュータ可読媒体。
【請求項４３】
移動端末からの要求を受信し、
プロキシから、前記要求に応じた応答を送信するためのコンピュータ実行可能命令を有し、
前記応答は、前記移動端末に関連付けられているリング署名を含み、前記移動端末に関連付けられている公開鍵と前記プロキシに関連付けられている第二公開鍵とから前記移動端末がネットワークアドレスを生成することを可能とすることを特徴とするコンピュータ可読媒体。
【請求項４４】
前記応答に含まれる前記署名は、前記プロキシに関連付けられている前記公開鍵と前記移動端末に関連付けられている公開鍵とに対応するリング署名から構成されることを特徴とする請求項４３に記載のコンピュータ可読媒体。
【請求項４５】
前記応答に含まれる前記署名は、前記応答に含まれる前記移動端末に関連付けられている前記公開鍵に対応する秘密鍵を用いて生成された従来の公開鍵署名から構成され、
前記応答は、前記署名を検証可能な前記移動端末の前記公開鍵を示すことを特徴とする請求項４３に記載のコンピュータ可読媒体。
【請求項４６】
前記ネットワークアドレスに関するアドレス解決要求を受信する、コンピュータ実行可能命令をさらに有することを特徴とする請求項４３に記載のコンピュータ可読媒体。
【請求項４７】
バインディング更新メッセージを受信した場合、前記プロキシがホームエージェントとなる、コンピュータ実行可能命令をさらに有することを特徴とする請求項４３に記載のコンピュータ可読媒体。
【請求項４８】
前記プロキシに関連付けられている秘密鍵を用いて署名されたメッセージによって、前記アドレス解決要求に応じる、コンピュータ実行可能命令をさらに有することを特徴とする請求項４７に記載のコンピュータ可読媒体。
【国際調査報告】
2008541566.tif 000007