JP2004030610A - Ｐｎｒｐセキュリティ・インフラストラクチャおよび方法 - Google Patents
Ｐｎｒｐセキュリティ・インフラストラクチャおよび方法 Download PDFInfo
- Publication number
- JP2004030610A JP2004030610A JP2003125926A JP2003125926A JP2004030610A JP 2004030610 A JP2004030610 A JP 2004030610A JP 2003125926 A JP2003125926 A JP 2003125926A JP 2003125926 A JP2003125926 A JP 2003125926A JP 2004030610 A JP2004030610 A JP 2004030610A
- Authority
- JP
- Japan
- Prior art keywords
- node
- message
- pac
- peer
- cache
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F15/00—Digital computers in general; Data processing equipment in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/104—Peer-to-peer [P2P] networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/45—Network directories; Name-to-address mapping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
- H04L63/126—Applying verification of the received information the source of the received data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1441—Countermeasures against malicious traffic
- H04L63/1458—Denial of Service
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99931—Database or file accessing
- Y10S707/99939—Privileged access
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
Abstract
【課題】悪意のあるノードがピアツーピアネットワークの通常のオペレーションを妨害する能力を抑制するセキュリティ・インフラストラクチャおよび方法を提供すること。
【解決手段】本発明の方法は、ノードを自己検証型にすることにより、ノードがセキュア識別とインセキュア識別の両方を使用することを可能にする。必要なとき、または適当なときに、既存のメッセージに対する検証を便乗させることにより、ＩＤ所有権が検証される。悪意のあるノードに最初に接続する確率を、接続先のノードをランダムに選択することにより減少させる。さらに、悪意のあるノードからの情報は、将来の応答を必要とする以前の通信についての情報を維持することにより、識別され、それを廃棄することができる。
【選択図】 図２
【解決手段】本発明の方法は、ノードを自己検証型にすることにより、ノードがセキュア識別とインセキュア識別の両方を使用することを可能にする。必要なとき、または適当なときに、既存のメッセージに対する検証を便乗させることにより、ＩＤ所有権が検証される。悪意のあるノードに最初に接続する確率を、接続先のノードをランダムに選択することにより減少させる。さらに、悪意のあるノードからの情報は、将来の応答を必要とする以前の通信についての情報を維持することにより、識別され、それを廃棄することができる。
【選択図】 図２
Description
【０００１】
【発明の属する技術分野】
本発明は、一般的にはピアツーピアプロトコルに関し、より詳細には、ピアツーピアプロトコルのためのセキュリティ・フレームワーク・インフラストラクチャに関する。
【０００２】
【従来の技術】
ピアツーピア通信、実際にはすべての種類の通信は、選択されたエンティティ間の有効な接続を確立する可能性に依存する。しかし、エンティティがネットワーク内で移動し、トポロジが変化し、またはアドレス・リース（ａｄｄｒｅｓｓ ｌｅａｓｅ）を更新することができないために、エンティティは、変動する可能性のある１または複数のアドレスを有することができる。したがって、このアドレス指定問題に対する古典的なアーキテクチャ上の解決策は、各エンティティに安定な名前を割り当て、接続が必要なときにこの名前を現在アドレスに「解決（ｒｅｓｏｌｖｅ）」することである。名前からアドレスへの変換は、非常に堅固でなければならず、容易かつ高速な更新も可能でなければならない。
【０００３】
エンティティへの接続を捜すことによって、エンティティのアドレスを見つける可能性を増加させるために、多くのピアツーピアプロトコルは、エンティティが様々な機構を介してエンティティのアドレスを発行することを可能にする。一部のプロトコルは、クライアントが、ネットワーク中の他のエンティティからの要求を処理することによって、他のエンティティのアドレスの知識を獲得することを可能にする。実際、このアドレス知識の獲得により、これらピアツーピアネットワークを首尾よく運用することが可能となる。すなわち、ネットワーク中の他のピアについての情報が良好であるほど、特定のリソースの検索が収束する可能性が高くなる。
【０００４】
しかし、ピアツーピアプロトコルの基礎となる堅固なセキュリティ・インフラストラクチャがなければ、悪意のあるエンティティは、このようなピアツーピアシステムの収束する能力を容易に破壊することができる。このような破壊は、例えば識別情報の盗用に関わるエンティティによって引き起こされる可能性がある。ピアツーピアネットワーク上のこのような識別情報の盗用攻撃において、悪意のあるノードは、許可された関係にない、すなわちその所有者でもグループのメンバなどでもないＩＤについてのアドレス情報を発行する。悪意のあるエンティティは、良好なノード応答の前に、最初に傍受および／または応答することができ、したがって良好なノードのように見える。
【０００５】
悪意のあるエンティティは、ネットワークに不良な情報をあふれさせることによってＰＮＲＰ解決を妨害することができ、ネットワーク中の他のエンティティが、存在しないノードに要求を転送する傾向を有し（このことは検索の収束に悪影響を与える）、または攻撃者によって制御されるノードに要求を転送する傾向を有する。このことは、リソースを見つけるために使用するＲＥＳＯＬＶＥパケットを転送する前に変更することによって、またはＲＥＳＯＬＶＥパケットを生成した要求者側に無効なＲＥＳＰＯＮＳＥを返送することによって達成される。悪意のあるエンティティは、例えば、ＩＤが近く検索の収束を助ける、悪意のあるエンティティのキャッシュ内のノードに検索を転送する代わりに、要求されたＩＤから非常に離れたノードに検索を転送することによって、ピアツーピアネットワークのオペレーションを妨害しようと試みることもできる。あるいは、悪意のあるエンティティは、単に検索要求に全く応答しないこともできる。ＰＮＲＰ解決は、有効なＩＤの代わりに無効なＢＹＥメッセージを送信する悪意のあるノードによってさらに妨害される可能性がある。その結果、クラウド（ｃｌｏｕｄ）内の他のノードは、そのノードのキャッシュからこの有効なＩＤを除去し、それらに格納された有効なノードの数が減少する。
【０００６】
アドレス証明書の検証は、識別情報の盗用問題を防止することができるが、ＰＮＲＰ解決を妨害する第２の種類の攻撃に対しては効果がない。攻撃者は、検証可能なアドレス証明書を生成し続け（またはそれを事前に生成し）、対応するＩＤをピアツーピアクラウド内にあふれさせることができる。ノードのいずれかがＩＤの所有権を検証しようと試みる場合、攻撃者は、実際そのノードが、あふれたＩＤの所有者であるので、そのことを検証することができる。しかし、攻撃者が十分なＩＤを生成するならば、攻撃者は、ピアツーピア検索の大部分を、攻撃者により制御されるノードのうちの１つに導くことができる。この点、攻撃者は、ネットワークのオペレーションをかなり制御し、管理することができる。
【０００７】
【発明が解決しようとする課題】
上述した識別情報の盗用問題を防止するために、すべての新しいアドレス情報を最初に検証することをピアツーピアプロトコルが要求する場合に、第３の種類の攻撃を悪意のあるエンティティが利用できるようになる。これら種類のピアツーピアネットワークが影響を受けやすい攻撃は、サービス妨害（ＤｏＳ）攻撃の形式である。新しいレコードについて理解するすべてのノードがＩＤ所有権のチェックを実施しようとする場合に、開示されたＩＤ所有者に対してネットワークアクティビティが殺到する。この弱点を利用して、攻撃者は、非常に一般化されたターゲットに対してＩＰ ＤｏＳ攻撃を仕掛けることができる。例えば、悪意のあるエンティティが、ＭｉｃｒｏｓｏｆｔのウェブＩＰアドレスをＩＤのＩＰとして公示した場合、開示されたＩＰを受信するピアツーピアネットワーク中のすべてのノードは、そのＩＰ（ＭｉｃｒｏｓｏｆｔのウェブサーバのＩＰ）に接続してレコードの真性を検証しようとする。もちろん、攻撃者がこの情報を生成したので、ＭｉｃｒｏｓｏｆｔのサーバがＩＤの所有権を検証することはできない。しかし、損害は既に生じている。すなわち、攻撃者は、ピアツーピアコミュニティの良好な部分にＭｉｃｒｏｓｏｆｔを攻撃させている。
【０００８】
１または複数のリソースを消耗させることによって、ノードまたはクラウドを圧倒する別の種類のＤｏＳ攻撃は、例えば、ＦＬＯＯＤ／ＲＥＳＯＬＶＥ／ＳＯＬＩＣＩＴパケットを使用することにより、大量の無効／有効ＰＡＣを単一のノードに送信する悪意のあるノードによって仕掛けられる。これらのＰＡＣを受信するノードは、ＰＡＣのすべてを検証しようとして、ノードのすべてのＣＰＵを消費することになる。同様に、無効ＦＬＯＯＤ／ＲＥＳＯＬＶＥパケットを送信することによって、悪意のあるノードは、クラウド内でパケットの増殖を達成する。すなわち、悪意のあるノードは、少数のそのようなパケットを使用して、ＰＮＲＰクラウド用のネットワーク帯域幅を消費することができる。このパケットの送信先のノードは、追加のパケットを送信することによって応答するからである。ネットワーク帯域幅の増殖は、悪意のあるノードが偽のＲＥＱＵＥＳＴメッセージを送信し、そのＲＥＱＵＥＳＴメッセージに対して、良好なノードがＲＥＱＵＥＳＴよりも大きいサイズのＰＡＣをＦＬＯＯＤすることによって応答することによっても達成される。
【０００９】
悪意のあるノードは、初期ノードのシンクアップ（ｓｙｎｃｈ ｕｐ）を妨害することによってＰＮＲＰクラウドに攻撃を仕掛けることもできる。すなわち、ＰＮＲＰクラウドに加わるために、ノードは、ＰＮＲＰクラウド内の既に存在しているノードのうちの１つに接続しようと試みる。ノードが悪意のあるにノードに接続しようと試みる場合に、ノードは、悪意のあるノードによって完全に制御されてしまう。さらに、悪意のあるノードは、２つの良好なノードが同期プロセスに関係しているとき、無効なＲＥＱＵＥＳＴパケットを送信することができる。無効なＲＥＱＵＥＳＴパケットにより、それに応答してＦＬＯＯＤメッセージの生成が開始されるので、これはシンクアップを妨害する一種のＤｏＳ攻撃である。
【００１０】
したがって、このような攻撃の効果を防止または軽減することによって、Ｐ２Ｐクラウドの保全性を保証するセキュリティ機構が当技術分野で求められている。
【００１１】
【課題を解決するための手段】
本願で開示される発明の概念は、悪意のあるノードがピアツーピアネットワークの通常のオペレーションを妨害することを抑制する、新規で改良された方法を含む。具体的には、本発明は、識別情報の盗用攻撃、サービス妨害攻撃、単にピアツーピアネットワーク中のアドレス解決を妨害しようと試みる攻撃、およびピアツーピアネットワークに加わり、参加する新しいノードの能力を妨害しようと試みる攻撃を含む、悪意のあるノードによって仕掛けられる可能性のある様々な種類の攻撃に対処する方法を提示する。
【００１２】
提示されたセキュリティ・インフラストラクチャおよび方法は、ノードを自己検証型にすることにより、ノードがセキュア識別とインセキュア識別の両方を使用することを可能にする。必要なとき、または適当なときに、既存のメッセージに対する検証を便乗させることにより、または必要であれば小さい紹介メッセージを送信することにより、ＩＤ所有権が検証される。接続先のノードをランダムに選択することにより、悪意のあるノードに最初に接続する確率が減少する。さらに、将来の応答を必要とする以前の通信についての情報を維持することにより、悪意のあるノードからの情報が識別され、それを廃棄することができる。ノードのリソース使用率が所定の限界を超えたときに、ノードが要求を廃棄することを可能にすることにより、サービス妨害攻撃が抑制される。除去されるノードが取消し証明書を署名することを要求することにより、悪意のあるノードが有効ノードを除去する能力は低下する。
【００１３】
本発明の一実施形態によれば、自己検証可能なインセキュアピアアドレス証明書（ＰＡＣ）を生成する方法が提示される。これは、悪意のあるノードが、ピアツーピアネットワーク内のインセキュアＰＡＣにおいて別のノードのセキュア識別を発行することを防止する、この方法は、ピアツーピアネットワーク内で見つけることができるリソースに対するインセキュアＰＡＣを生成するステップを含む。このリソースは、ピアツーピア識別子（ＩＤ）を有する。この方法は、ピアツーピアＩＤが導出されるインセキュアＰＡＣ内に、ユニフォームリソース識別子（ＵＲＩ）を含めるステップをさらに含む。ＵＲＩは、好ましくは、「ｐ２ｐ：／／ＵＲＩ」のフォーマットである。ピアツーピアＩＤは、インセキュアでもよい。
【００１４】
別の実施形態では、ピアツーピアネットワーク内の第１ノードでピアアドレス証明書を適当なときに検証する方法が提示される。この第１ノードは、ピアアドレス証明書を格納するために複数レベルのキャッシュを使用し、この方法は、第２ノードから意図的にピアアドレス証明書（ＰＡＣ）を受信するステップと、複数レベルのキャッシュのどのレベルにＰＡＣを格納すべきかを決定するステップとを含む。２つの最低のキャッシュレベルの一方にＰＡＣを格納すべきとき、この方法は、ＰＡＣを保留リストに配置し、検証すべきＰＡＣのＩＤを含むＩＮＱＵＩＲＥメッセージを生成し、ＩＮＱＵＩＲＥメッセージを第２ノードに送信する。２つの最低のキャッシュレベル以外の上位のキャッシュレベルにＰＡＣを格納すべきとき、この方法は、「未検証」としてマークされる上位のキャッシュレベルにＰＡＣを格納する。この場合、ＰＡＣは、それが使用される最初に検証される。この方法は、ＰＡＣを求める証明書チェーンを要求することもできる。
【００１５】
好ましい実施形態では、ＩＮＱＵＩＲＥメッセージの生成は、ＩＮＱＵＩＲＥメッセージに含めるべきトランザクションＩＤを生成するステップを含む。ＩＮＱＵＩＲＥメッセージに応答して第２ノードからＡＵＴＨＯＲＩＴＹメッセージが受信されたとき、ＰＡＣは、保留リストから除去され、２つの最低のキャッシュレベルの一方に格納される。証明書チェーンが要求された場合、ＡＵＴＨＯＲＩＴＹメッセージが検査され、証明書チェーンが存在し、かつ有効であるかどうかが判定される。そうである場合に、ＰＡＣは、２つの最低のキャッシュレベルの一方に格納され、そうでない場合に、ＰＡＣは削除される。本発明の実施形態では、ＡＵＴＨＯＲＩＴＹメッセージが以前の通信に対する応答であることを保証するためにトランザクションＩＤを使用することもできる。
【００１６】
本発明の別の実施形態では、悪意のあるノードに接続する確率が減少するようにピアツーピアネットワーク内のノードを見つける方法が提示される。この方法は、ピアツーピアネットワーク内で、ローカルに登録されたＩＤを含めずに発見メッセージを同報通信するステップと、ピアツーピアネットワーク内のノードから応答を受信するステップと、ノードとピアリング関係を確立するステップとを含む。一実施形態では、ノードから応答を受信するステップは、ピアツーピアネットワーク内の少なくとも２つのノードから応答を受信するステップを含む。この状況では、ノードとピアリング関係を確立するステップは、少なくとも２つのノードの一方をランダムに選択するステップと、少なくとも２つのノードのうちランダムに選択された一方とピアリング関係を確立するステップとを含む。
【００１７】
本発明のさらに別の実施形態では、ピアツーピアネットワーク内の同期プロセスに基づくサービス妨害攻撃を抑制する方法が提示される。この方法は、キャッシュ同期を要求する、ピアアドレス証明書（ＰＡＣ）を含むＳＯＬＩＣＩＴメッセージ要求を第１ノードから受信するステップと、ＰＡＣを検査して、ＰＡＣの有効性を判定するステップと、ＰＡＣを検査するステップが、ＰＡＣが有効でないと判定したとき、ＳＯＬＩＣＩＴパケットを除去するステップとを含む。好ましくは、ＰＡＣを検査するステップが、ＰＡＣが有効であると判定したとき、この方法は、ナンス（ｎｏｎｃｅ）を生成するステップと、ナンスを第１ノードの公開鍵で暗号化するステップと、暗号化ナンスを含むＡＤＶＥＲＴＩＳＥメッセージを生成するステップと、ＡＤＶＥＲＴＩＳＥメッセージを第１ノードに送信するステップとをさらに含む。ＲＥＱＵＥＳＴメッセージが第１ノードから受信されたとき、この方法は、ＲＥＱＵＥＳＴメッセージを検査して、第１ノードが暗号化ナンスを暗号化解除することができたかどうかを判定し、第１ノードが暗号化ナンスを暗号化解除することができたとき、ＲＥＱＵＥＳＴメッセージを処理する。
【００１８】
好ましくは、この方法は、第１ノードとの通信を具体的に識別する接続情報を維持するステップと、ＲＥＱＵＥＳＴメッセージを検査し、ＲＥＱＵＥＳＴメッセージが具体的にＡＤＶＥＲＴＩＳＥメッセージと関係することを保証するステップと、ＲＥＱＵＥＳＴメッセージが具体的にＡＤＶＥＲＴＩＳＥメッセージと関係しないとき、ＲＥＱＵＥＳＴメッセージを拒絶するステップとをさらに含む。一実施形態では、第１ノードとの通信を具体的に識別する接続情報を維持するステップは、ナンスおよび第１ノードの識別のハッシュとして第１ビット位置を計算するステップと、ビットベクトル中の第１ビット位置でビットをセットするステップとを含む。これを行ったとき、ＲＥＱＵＥＳＴメッセージを検査するステップは、ＲＥＱＵＥＳＴメッセージからナンスおよび第１ノードの識別を抽出するステップと、ナンスおよび第１ノードの識別のハッシュとして第２ビット位置を計算するステップと、ビットベクトルを検査し、ビットベクトルが第２ビット位置に対応するビットセットを有するかどうかを判定するステップと、ビットベクトルを検査するステップで第２ビット位置に対応するビットセットが見つからないとき、ＲＥＱＵＥＳＴがＡＤＶＥＲＴＩＳＥメッセージに具体的に関係しないことを示すステップとを含む。あるいは、ナンスをビット位置として直接的に使用することもできる。この場合、ＲＥＱＵＥＳＴが受信されたとき、同封のナンスに対応するビット位置がチェックされる。このビット位置がセットされている場合、これは有効なＲＥＱＵＥＳＴであり、ビット位置がクリアされる。そうでない場合、これは無効なＲＥＱＵＥＳＴまたは応答攻撃であり、このＲＥＱＵＥＳＴは廃棄される。
【００１９】
本発明のさらに別の実施形態では、ピアツーピアネットワーク内の同期プロセスに基づくサービス妨害攻撃を抑制する方法は、第１ノードから意図的に要求メッセージを受信するステップと、ＲＥＱＵＥＳＴメッセージが第１ノードとの以前の通信に対する応答であるかどうかを判定するステップと、ＲＥＱＵＥＳＴメッセージが第１ノードとの以前の通信に対する応答でないとき、ＲＥＱＵＥＳＴメッセージを拒絶するステップとを含む。好ましくは、ＲＥＱＵＥＳＴメッセージが以前の通信に対する応答であるかどうかを判定するステップは、ＲＥＱＵＥＳＴメッセージから、第１ノードのナンスおよび識別を意図的に抽出するステップと、ナンスおよび識別のハッシュとしてビット位置を計算するステップと、ビットベクトルを検査し、ビットベクトルがビット位置に対応するビットセットを有するかどうかを判定するステップと、ビット位置に対応するビットセットが存在しないとき、ＲＥＱＵＥＳＴが第１ノードとの以前の通信の応答ではないことを示すステップとを含む。
【００２０】
ピアツーピアネットワーク内のノードリソースの消費に基づくサービス妨害攻撃を抑制する方法も提示される。この方法は、ピアツーピアネットワーク内のノードからメッセージを受信するステップと、現在のリソース使用率を検査するステップと、現在のリソース使用率が所定のレベルを超えているとき、メッセージの処理を拒絶するステップとを含む。ＲＥＳＯＬＶＥメッセージが受信されたとき、メッセージの処理を拒絶するステップは、ＡＵＴＨＯＲＩＴＹメッセージを第１ノードに送信するステップを含む。このＡＵＴＨＯＲＩＴＹメッセージは、現在のリソース使用率が高過ぎるためにＲＥＳＯＬＶＥメッセージが処理されないことの表示を含む。ピアアドレス証明書（ＰＡＣ）を含むＦＬＯＯＤメッセージが受信され、かつＰＡＣを２つの最低のキャッシュレベルの一方に格納すべきであることをこの方法が決定したとき、メッセージの処理を拒絶するステップは、後の処理のために保留リスト内にＰＡＣを配置するステップを含む。２つの最低のキャッシュレベルよりも高いキャッシュレベルにＰＡＣを格納すべきであることをこの方法が決定した場合には、メッセージの処理を拒絶するステップは、ＦＬＯＯＤメッセージを拒絶するステップを含む。
【００２１】
本発明の別の実施形態では、ピアツーピアネットワーク内のノード帯域幅消費に基づくサービス妨害攻撃を抑制する方法が提示される。この方法は、ピアツーピアネットワーク内のノードからキャッシュ同期を求める要求を受信するステップと、過去に実施されたキャッシュ同期の数を示すメトリック（ｍｅｔｒｉｃ）を検査するステップと、過去に実施されたキャッシュ同期の数が所定の最大値を超えているとき、キャッシュ同期を求める要求の処理を拒絶するステップとを含む。別の実施形態では、この方法はメトリックを検査し、所定の先行期間に実施されたキャッシュ同期の数を判定する。この実施形態では、要求の処理を拒絶するステップは、所定の先行期間に実施されたキャッシュ同期の数が所定の最大値を超えているとき、キャッシュ同期を求める要求の処理を拒絶するステップを含む。
【００２２】
本発明の別の実施形態では、ピアツーピアネットワーク内の検索ベースのサービス妨害攻撃を抑制する方法は、既知のピアアドレス証明書のキャッシュエントリを検査し、解決要求を送信する適切なノードを決定するステップと、適切なノードのうち１つをランダムに選択するステップと、ランダムに選択したノードに解決要求を送信するステップとを含む。一実施形態では、適切なノードのうち１つをランダムに選択するステップは、ターゲットＩＤからのＰＮＲＰ ＩＤの距離に基づいて、適切なノードごとに、重み付けした確率を計算するステップを含む。特定の次のホップを選ぶ確率は、そのノードとターゲットノードの間のＩＤ距離に対する反比例として決定される。
【００２３】
本発明の別の実施形態では、ピアツーピアネットワーク内の検索ベースのサービス妨害攻撃を抑制する方法は、ＲＥＳＰＯＮＳＥメッセージを受信するステップと、ＲＥＳＰＯＮＳＥメッセージが以前のＲＥＳＯＬＶＥメッセージに対する応答であるかどうかを判定するステップと、ＲＥＳＰＯＮＳＥメッセージが以前のＲＥＳＯＬＶＥメッセージに対する応答でないとき、ＲＥＱＵＥＳＴメッセージを拒絶するステップとを含む。好ましくは、ＲＥＳＰＯＮＳＥメッセージが以前のＲＥＳＯＬＶＥメッセージに対する応答であるかどうかを判定するステップは、ＲＥＳＰＯＮＳＥメッセージ内の情報のハッシュとしてビット位置を計算するステップと、ビットベクトルを検査し、ビット位置に対応するビットがビットベクトル内にセットされているかどうかを判定するステップとを含む。
【００２４】
一実施形態では、ＲＥＳＰＯＮＳＥメッセージはアドレスリストを含み、この方法は、解決を妨害する試みにおいてＲＥＳＰＯＮＳＥメッセージが変更されているかどうかを判定するステップと、解決を妨害する試みにおいてＲＥＳＰＯＮＳＥメッセージが変更されているとき、ＲＥＳＰＯＮＳＥメッセージを拒絶するステップとをさらに含む。好ましくは、解決を妨害する試みにおいてＲＥＳＰＯＮＳＥメッセージが変更されているかどうかを判定するステップは、ＲＥＳＰＯＮＳＥメッセージ内のアドレスリストのハッシュとしてビット位置を計算するステップと、ビットベクトルを検査し、ビット位置に対応するビットがビットベクトル内にセットされているかどうかを判定するステップとを含む。
【００２５】
本発明の別の実施形態では、悪意のあるノードがピアツーピアネットワークから有効ノードを除去することを抑制する方法は、キャッシュ内に格納されたピアアドレス証明書（ＰＡＣ）を有する有効ノードから、取消し証明書を意図的に受信するステップと、取消し証明書が有効ノードによって署名されていることを検証するステップとを含む。
【００２６】
本明細書に含まれ、本明細書の一部を形成する添付の図面は、本発明のいくつかの態様と、本発明の原理を説明するのに用いるための開示とを示す。
【００２７】
【発明の実施の形態】
ある好ましい実施形態に関連して本発明を説明するが、本発明をその実施形態に限定することを意図するものではない。むしろ、すべての代替方法、修正形態、および均等物が、頭記の特許請求の範囲で定義される本発明の精神および範囲内に含まれるものとする。
【００２８】
図面を参照すると、同様の参照符号は同様の要素を指しており、本発明が、適切なコンピューティング環境に実装されているものとして示されている。必須ではないが、パーソナルコンピュータによって実行中の、プログラムモジュールなどのコンピュータ実行可能命令の一般的文脈で本発明を説明する。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ種類を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースの消費者向け電子機器またはプログラマブル消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成を用いて本発明を実施できることを当業者は理解されよう。本発明はまた、通信ネットワークを介してリンクされるリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルメモリ記憶装置とリモートメモリ記憶装置のどちらにも位置することができる。
【００２９】
図１に、本発明を実装することができる適切なコンピューティング環境１００の例を示す。例示的コンピューティング環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用および機能の範囲に関して何らかの制限を示唆するものではない。例示的動作環境１００に図示する構成要素のうちのいずれか１つ、あるいはそれらの組合せに関係する何らかの依存関係または要件をコンピューティング環境１００が有するものと解釈すべきでもない。
【００３０】
本発明は、他の多数の汎用コンピューティングシステム環境または構成、あるいは他の多数の特殊目的コンピューティングシステム環境または構成で動作可能である。本発明と共に使用するのに適した周知のコンピューティングシステム、環境、および／または構成の例には、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド装置またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ならびに上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。
【００３１】
本発明は、コンピュータによって実行中の、プログラムモジュールなどのコンピュータ実行可能命令の一般的文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データ種類を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介してリンクされるリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体のどちらにも位置することができる。
【００３２】
図１を参照すると、本発明を実装するための例示的システムは、コンピュータ１１０の形式の汎用コンピューティング装置を含む。コンピュータ１１０の構成要素は、限定はしないが、処理装置１２０と、システムメモリ１３０と、システムメモリを含む様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１とを含むことができる。システムバス１２１は、様々なバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラと、周辺バスと、ローカルバスとを含むいくつかの種類のバス構造のうちのいずれでもよい。例えば、限定はしないが、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００３３】
コンピュータ１１０は、一般に様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０がアクセス可能である入手可能などんな媒体でもよく、それには揮発性媒体と不揮発性媒体の両方、取外し可能媒体と取外し不能媒体の両方が含まれる。例えば、限定はしないが、コンピュータ可読媒体はコンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するための何らかの方法または技術で実装される、揮発性媒体と不揮発性媒体、取外し可能媒体と取外し不能媒体のどちらも含む。コンピュータ記憶媒体には、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶装置、あるいは、所望の情報を格納するのに使用することができ、コンピュータ１１０でアクセスすることができる他のどんな媒体も含まれる。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の移送機構などの被変調データ信号で実施し、その通信媒体にはどんな情報送達媒体も含まれる。「被変調データ信号」という用語は、その特徴のうちの１または複数を有する信号、または情報を符号化するように変化する信号を意味する。例えば、限定はしないが、通信媒体には、ワイヤードネットワークまたはダイレクトワイヤード接続などのワイヤード媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、および他のワイヤレス媒体などのワイヤレス媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
【００３４】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。始動中などにコンピュータ１１０内の要素間で情報を転送する助けになる基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３が、一般にＲＯＭ１３１内に記憶される。ＲＡＭ１３２は、一般に、処理装置１２０に即座にアクセス可能であり、かつ／または処理装置１２０が現在操作しているデータおよび／またはプログラムモジュールを含む。例えば、限定はしないが、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
【００３５】
コンピュータ１１０は、他の取外し可能／取外し不能な、揮発性／不揮発性コンピュータ記憶媒体も含むことができる。単なる一例であるが、図１に、取外し不能不揮発性磁気媒体を読み書きするハードディスクドライブ１４１と、取外し可能不揮発性磁気ディスク１５２を読み書きする磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭまたは他の光媒体などの取外し可能不揮発性光ディスク１５６を読み書きする光ディスクドライブ１５５とを示す。例示的動作環境で使用することのできる他の取外し可能／取外し不能な揮発性／不揮発性コンピュータ記憶媒体には、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタルバーサタイルディスク、デジタルビデオテープ、固体ＲＡＭ、および固体ＲＯＭが含まれる。ハードディスクドライブ１４１は一般に、インタフェース１４０などの取外し不能メモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、インタフェース１５０などの取外し可能メモリインタフェースによってシステムバス１２１に接続される。
【００３６】
上述した、図１に図示するドライブとその関連するコンピュータ記憶媒体は、コンピュータ１１０に対してコンピュータ可読命令データ構造、データ構造、プログラムモジュール、および他のデータの記憶を実現する。例えば図１では、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして図示している。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じにすることも、異なるものにすることもできることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが相異なるコピーであることを示すために異なる符号を付けてある。ユーザは、キーボード１６２や、マウス、トラックボール、またはタッチパッドと一般に呼ばれるポインティングデバイス１６１などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含めることができる。これらの入力装置や他の入力装置はしばしば、システムバスに結合されるユーザ入力インタフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインタフェースおよびバス構造によって接続することもできる。モニタ１９１または他の種類のディスプレイ装置もまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはまた、スピーカ１９７およびプリンタ１９６などの他の周辺出力装置も含むことができ、その周辺出力装置は、出力周辺インタフェース１９５を介して接続することができる。
【００３７】
コンピュータ１１０は、リモートコンピュータ１８０などの１または複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境で動作することができる。リモートコンピュータ１８０は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードでよく、一般にコンピュータ１１０に関して上記で述べた要素のうちの多くまたはすべてを含むが、図１にはメモリ記憶装置１８１だけを示してある。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含めることができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。
【００３８】
ＬＡＮネットワーキング環境で使用する際、パーソナルコンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する際、コンピュータ１１０は一般に、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インタフェース１６０、または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１００に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置内に格納することができる。例えば、限定はしないが、図１に、リモートアプリケーションプログラム１８５をメモリ装置１８１上に常駐するものとして示す。図示するネットワーク接続は例示的なものであって、コンピュータ間の通信リンクを確立する他の手段も使用できることを理解されたい。
【００３９】
以下の説明では、別段の表示がない限り、１または複数のコンピュータによって実行される動作と、オペレーションの象徴的表現とを参照しながら本発明を説明する。したがって、このような動作およびオペレーションは、コンピュータで実行される動作およびオペレーションと呼ばれることもあり、構造化形式のデータを表す電気信号の、コンピュータの処理装置による操作を含むことを理解されよう。この操作は、データを変換し、またはデータをコンピュータのメモリシステム内の位置に維持し、このデータは、当業者の理解する方式でコンピュータのオペレーションを再構成し、あるいは変更する。データを維持するデータ構造は、データのフォーマットによって定義される特定の特性を有するメモリの物理位置である。しかし、上記の状況で本発明を説明するものの、当業者は理解するであろうが、以下で説明する様々な動作およびオペレーションをハードウェアでも実装できることを制限することを意味するわけではない。
【００４０】
上述したように、ピアツーピア（Ｐ２Ｐ）プロトコルの成功は、選択されたエンティティ間の有効な接続を確立するプロトコルの能力に依存する。特定のユーザは、異なるアドレスを有する様々な位置で、様々な方式でネットワークに接続することができるので、好ましい手法は、ユーザに対して固有の識別を割り当て、次にプロトコルを介してその識別を特定のアドレスに変換することである。Ｐｅｅｒ−Ｔｏ−Ｐｅｅｒ Ｎａｍｅ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＰＮＲＰ） Ａｎｄ Ｍｕｌｔｉｌｅｖｅｌ Ｃａｃｈｅ Ｆｏｒ Ｕｓｅ Ｔｈｅｒｅｗｉｔｈという名称の２００１年８月２９日出願の同時係属出願第０９／９４２１６４号には、本発明のセキュリティ・インフラストラクチャの特定の適用範囲が見出されるＰＮＲＰが記載されている。この同時係属出願の教示および開示全体を参照により組み込む。しかし、本発明のセキュリティ・インフラストラクチャおよび方法が、この同時係属出願の特定のピアツーピアプロトコルに限定されず、他のプロトコルにも等しい効力で適用できることを、以下の教示から当業者は理解されよう。
【００４１】
上記で組み込んだ同時係属出願で論じられているように、ＰＮＲＰは、ピアベースの名前−アドレス解決プロトコルである。名前は、ＰＮＲＰ ＩＤと呼ばれる２５６ビットの数である。アドレスは、ＩＰｖ４アドレスまたはＩＰｖ６アドレス、ポート、ならびにプロトコル番号からなる。ＰＮＲＰ ＩＤがアドレスに変換されるとき、ピアアドレス証明書（ＰＡＣ）が返される。この証明書は、ターゲットのＰＮＲＰ ＩＤ、現ＩＰアドレス、公開鍵、およびその他の多くのフィールドを含む。ＰＮＲＰプロトコルのインスタンスは、ノードと呼ばれる。ノードは、ローカルに登録された１または複数のＰＮＲＰ ＩＤを有することができる。ノードは、登録を介してＰＮＲＰで見つけることができるＩＤ−アドレスマッピングを作成する。各登録は、ローカルに構築されたピア証明書を含み、ＰＮＲＰキャッシュの適切なビューを必要とする。ＰＮＲＰノードではないホストは、ＰＮＲＰ ＤＮＳゲートウェイを介してＰＮＲＰ ＩＤをＩＰアドレスに変換することができる。ＰＮＲＰ ＤＮＳゲートウェイは、ＤＮＳ「Ａ」および「ＡＡＡＡ」照会を受諾し、指定のホスト名のサブセットを求めるＰＮＲＰ検索を実行し、結果をＤＮＳ照会回答として返す。
【００４２】
上述したように、ＰＮＲＰは、Ｐ２ＰおよびＰＮＲＰ ＩＤをピアアドレス証明書（ＰＡＣ）と関連付けるピアベースの機構を提供する。Ｐ２Ｐ ＩＤは、永続的な１２８ビット識別子である。Ｐ２Ｐ ＩＤは、正しくフォーマットされたＰ２Ｐ名をハッシングすることによって作成される。Ｐ２Ｐ ＩＤには、セキュアとインセキュアの２つの種類がある。セキュアＰ２Ｐ ＩＤは、公開鍵と検証可能な関係を有するＩＤである。インセキュアＰ２Ｐ ＩＤは、セキュアでない任意のＩＤである。所与のＰ２Ｐ ＩＤは、多くの異なるノードによって発行することができる。ＰＮＲＰは、発行される各インスタンスが固有のＰＮＲＰ ＩＤを有することを保証するために、「サービス位置」サフィックスを使用する。「サービス位置」は、固有ネットワークサービスエンドポイントに対応する１２８ビットの数である。サービス位置は、いくつかの認識可能な要素を有するが、ＰＮＲＰクライアントからは不透明とみなされるべきである。サービス位置は、２つの重要な特性を有する。どの時点でも、クラウド内の１つのソケットだけが所与のサービス位置に対応する。２つのサービス位置を比較したとき、各サービス位置についての共通プレフィックスの長さは、ネットワークの近さの妥当な指標である。同一の４ビットで始まる２つのサービス位置は、同一の３ビットで始まる２つのサービス位置よりも遠くに離れていない。
【００４３】
Ｐ２Ｐ ＩＤは、サービス位置との連鎖によって一意的に識別される。得られる２５６ビット（３２バイト）識別子は、ＰＮＲＰ ＩＤと呼ばれる。ＰＮＲＰノードは、Ｐ２Ｐ名、権限、およびその他のいくつかのパラメータを用いてＰＮＲＰサービスを起動することによってＰＮＲＰ ＩＤを登録する。ＰＮＲＰサービスは、提供されたデータを含むピアアドレス証明書（ＰＡＣ）を作成し、維持する。ＰＡＣは少なくとも、ＰＮＲＰ ＩＤ、証明書有効期間、サービスアドレスおよびＰＮＲＰアドレス、公開鍵、ならびに選択ＰＡＣ内容を介して生成された暗号署名を含む。
【００４４】
ＰＮＲＰ ＩＤの作成および登録は、ＰＮＲＰサービスの一部に過ぎない。ＰＮＲＰサービス実行は、４つの段階に分割することができる。第１段階は、ＰＮＲＰクラウドディスカバリである。この段階の間に、新しいノードは、加わりたいと望むクラウド内の既存のノードを見つけなければならない。クラウドは、グローバルＰＮＲＰクラウド、サイトローカル（企業）クラウド、リンクローカルクラウドとすることができる。見つかった後、ＰＮＲＰクラウドに加わるについての第２段階に入る。新しいノードが既存のノードを見つけた後、新しいノードはＳＹＮＣＨＲＯＮＩＺＥ手順を実施し、既存のノードトップキャッシュレベルのコピーを得る。単一のキャッシュレベルにより、新しいノードがクラウドに参加することを開始するための十分の基礎が与えられる。ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮを達成した後、次の段階であるクラウドへのアクティブな参加を開始することができる。初期化を完了した後、ノードは、ＰＮＲＰ ＩＤ登録およびＰＮＲＰ ＩＤ解決に参加することができる。この段階の間、ピアは定期的なキャッシュの保守を実施する。ノードが終了したとき、ノードは第４段階に入り、クラウドを離れる。ノードは、ローカルに登録した任意のＰＮＲＰ ＩＤを登録解除し、次いで終了する。
【００４５】
ＰＮＲＰプロトコルは、９個の異なる種類のパケットからなる。その一部は上述した。しかし、本願では、パケットの名前は、単にパケットの機能を理解しやすくするために使用しているのであって、パケットの名前を、パケットの形式またはフォーマット、あるいはメッセージ自体を制限するものとみなすべきでないことに留意されたい。ＲＥＳＯＬＶＥパケットは、ターゲットＰＮＲＰ ＩＤをＰＡＣに変換することを要求する。ＲＥＳＯＰＮＳＥパケットは、完了したＲＥＳＯＬＶＥ要求の結果である。ＦＬＯＯＤパケットは、受信側のＰＮＲＰキャッシュのためのＰＡＣを含む。ＳＯＬＩＣＩＴパケットは、ＰＮＲＰノードのトップレベルキャッシュをＡＤＶＥＲＴＩＳＥするようＰＮＲＰノードに依頼するために使用される。要求されるＡＤＶＥＲＴＩＳＥパケットは、ノードのトップレベルキャッシュ内のＰＡＣに関するＰＮＲＰ ＩＤのリストを含む。ＲＥＱＵＥＳＴパケットは、ＡＤＶＥＲＴＩＳＥされたＰＡＣのサブセットをフラッディングするようにノードに依頼するために使用される。ＩＮＱＵＩＲＥパケットは、特定のＰＮＲＰ ＩＤがそのノードに登録されたかどうかをインセキュアにノードに問い合わせるのに使用される。ＰＮＲＰ ＩＤのローカル登録を確認するために、ＡＵＴＨＯＲＩＴＹパケットが使用される。このパケットは、任意選択で、そのＩＤに関するＰＡＣを検証する助けとなるように証明書チェーンを提供する。ＡＣＫパケットは、あるメッセージの受信、および／または処理の成功を確認する。最後に、ＲＥＰＡＩＲパケットは、分割されている可能性のあるクラウドをマージするよう試みるために使用される。
【００４６】
ノードが完全に開始された後、ノードは、５つの種類のアクティビティを実施することによってＰＮＲＰクラウドに参加することができる。第１に、ノードは、ＰＮＲＰ ＩＤを登録および登録解除することができる。ＰＮＲＰ ＩＤを登録するとき、ＰＮＲＰサービスは、ＰＮＲＰ ＩＤ、サービスアドレスポートおよびプロトコル、ＰＮＲＰアドレスポートおよびプロトコル、ならびに公開鍵を関連付けるピアアドレス証明書（ＰＡＣ）を作成する。このＰＡＣは、ローカルキャッシュに入り、ＲＥＳＯＬＶＥを、新しいＰＡＣをソースとして使用し、かつ［ＰＮＲＰ ＩＤ＋１］をターゲットとして使用して開始する。このＲＥＳＯＬＶＥは、登録されるＩＤと非常に類似したＰＮＲＰ ＩＤを有するいくつかのノードによって処理される。ＲＥＳＯＬＶＥの各受信側は、新しいノードのＰＡＣをそれぞれのキャッシュに追加し、それによってクラウド内で新しいＰＮＲＰＩＤを公示する。ＰＮＲＰ ＩＤを登録解除するとき、更新後のＰＡＣは、「取消し」フラグセットを用いて作成される。更新後のＰＡＣは、ローカルキャッシュの最低レベルにおけるすべてのエントリにフラッディングされる。ＦＬＯＯＤの各受信側は、ＰＡＣのバージョンが古いかについて、それぞれのキャッシュをチェックする。そのようなキャッシュが見つかった場合、受信側は、受信側のキャッシュからＰＡＣを除去する。ＰＡＣが最低のキャッシュレベルから除去される場合、受信側は、受信側の最低のキャッシュレベルにおけるその他のすべてのＰＡＣによって提示されるＰＮＲＰノードに対して取消しをＦＬＯＯＤする。
【００４７】
ＰＮＲＰノードは、ＰＮＲＰ ＩＤ解決に参加することもできる。上記で組み込んだ出願に論じられているように、ＰＮＲＰ ＩＤは、ターゲットＰＮＲＰ ＩＤに近づくように、次々にＲＥＳＯＬＶＥメッセージを経路指定することによってＰＡＣに変換される。ノードがＲＥＳＯＬＶＥを受信したとき、ノードは、ＲＥＳＯＬＶＥを拒否して以前のホップに戻し、以前のホップにＲＥＳＰＯＮＳＥで応答し、またはＰＮＲＰ ＩＤがノード自体よりもターゲットＩＤに近いノードにＲＥＳＯＬＶＥを転送することができる。ノードは、ＲＥＳＰＯＮＳＥパケットを解決の一部として受信し、転送する。ＰＮＲＰノードは、ローカルクライアントの代わりにＲＥＳＯＬＶＥＳを開始することができる。ＰＮＲＰサービスは、非同期の解決要求が可能となるようにＡＰＩを提供する。ローカルノードは、ＲＥＳＯＬＶＥパケットを生成し、対応するＲＥＳＰＯＮＳＥを最終的に受信する。
【００４８】
ＰＮＲＰノードは、キャッシュ同期要求を受ける。ＳＯＬＩＣＩＴパケットを受信する際、ノードは、ＰＮＲＰ ＩＤを最高キャッシュレベル中にリストするＡＤＶＥＲＴＩＳＥパケットで応答する。次に、ソリシターノード（ｓｏｌｉｃｉｔｏｒ ｎｏｄｅ）は、ＡＤＶＥＲＴＩＳＥされた望みのＰＡＣに関するＰＮＲＰ ＩＤをリストする要求を送信する。ＲＥＱＵＥＳＴされた各キャッシュエントリは、ＲＥＱＵＥＳＴ側にＦＬＯＯＤされる。最後に、以下により十分に論じるように、ＰＮＲＰは、識別の検証も実施する。識別の検証は、ＰＡＣを検証するのに使用する脅威を軽減する装置である。識別の検証は、基本的に２つの目的を有する。第１に、識別の検証は、ＰＡＣで指定されるＰＮＲＰノードが、ローカルに登録されたそのＰＡＣからのＰＮＲＰ ＩＤを有することを保証する。第２に、セキュアＰＮＲＰ ＩＤの場合（以下で論じる）、識別の検証は、ＰＮＲＰ ＩＤにおける権限に対して暗号的に実証可能な関係を有する鍵を使用して、ＰＡＣが署名されたことを保証する。
【００４９】
ここまで、本発明のセキュリティ・インフラストラクチャの実施形態と特定の関連性が見出されるＰＮＲＰシステムの実際に役立つ知識を与えたので、ここで、本発明のセキュリティ・インフラストラクチャによって提供されるセキュリティ機構に注意を向ける。これらの機構は、上述したようなＰ２Ｐクラウドにおいて悪意のあるノードによってもたらされる可能性のある様々な攻撃の効果をなくし、または少なくとも緩和するために、本発明のシステムによって提供される。ＰＮＲＰプロトコルは、これらの攻撃を防止する機構を有さず、これら脅威のすべてに対処する単一の解決策があるわけでもない。しかし、本発明のセキュリティ・インフラストラクチャは、悪意のあるノードによって引き起こされる可能性のある破壊を最小にし、かつ、ＰＮＲＰプロトコロルに組み込むことができる。
【００５０】
成功している多くのＰ２Ｐプロトコルの場合と同じく、容易に見つけることができるようにエンティティを発行することができる。しかし、Ｐ２Ｐプロトコルに対してセキュリティおよび保全性を実現するために、各識別は、添付の識別証明書を含むことが好ましい。しかし、堅固なセキュリティアーキテクチャは、セキュアエンティティとインセキュアエンティティのどちらも扱うことができる。本発明の実施形態によれば、この堅固性は、自己検証型ＰＡＣを使用することによって実現される。
【００５１】
セキュアＰＡＣは、ＩＤと公開鍵との間のマッピングを提供することによって自己検証型にされる。これにより、セキュアＰＡＣに署名するための秘密鍵を有することなく誰かがそのＰＡＣを発行することが防止され、したがって、多くの識別の盗用攻撃が防止される。ＩＤ秘密鍵の保持者は、証明書を使用して、ＩＰアドレス、フレンドリネームなどの追加の情報をＩＤに添付する。好ましくは、各ノードは、ノード自体の秘密鍵−公開鍵対を生成し、信頼されるサプライヤが提供することもできる。公開鍵は、ノード識別子の一部として含められる。その１対の鍵を作成したノードだけが、ノード識別の作成者であることを証明することができる秘密鍵を有する。このようにして、識別の盗用を見つけることができ、したがってそれを防止することができる。
【００５２】
このような証明書に関する汎用フォーマットは、［Ｖｅｒｓｉｏｎ， ＩＤ， ＜ＩＤ Ｒｅｌａｔｅｄ Ｉｎｆｏ＞， Ｖａｌｉｄｉｔｙ， Ａｌｇｏｒｉｔｈｍｓ， ＰＩｓｓｕｅｒ］ＫＩｓｓｕｅｒと表すことができる。実際、セキュアＩＤであるか、それともインセキュアＩＤであるかに関わらず、Ｐ２Ｐ名／ＵＲＬは、基本的な証明書フォーマットの一部である。この証明書の表現で使用しているように、Ｖｅｒｓｉｏｎは、証明書のバージョンであり、ＩＤは、発行すべき識別子であり、＜ＩＤ Ｒｅｌａｔｅｄ Ｉｎｆｏ＞は、ＩＤと関連付けるべき情報を表し、Ｖａｌｉｄｉｔｙは、世界日時（別名ＧＭＴ）として表される１対のＦｒｏｍ−Ｔｏ ｄａｔｅで表される有効期間を表し、Ａｌｇｏｒｉｔｈｍｓは、鍵の対を生成し、署名するのに使用するアルゴリズムを指し、ＰＩｓｓｕｅｒは、証明書発行者の公開鍵である。証明書発行者がＩＤ所有者と同じである場合、これは、ＩＤ所有者の公開鍵ＰＩＤである。項ＫＩｓｓｕｅｒは、ＰＩｓｓｕｅｒに対応する秘密鍵である。証明書発行者がＩＤ所有者である場合、これは、ＩＤ所有者の秘密鍵ＫＩＤである。
【００５３】
好ましい実施形態では、＜ＩＤ ｒｅｌａｔｅｄ ｉｎｆｏ＞は、このＩＤを見つけることができるアドレスタプルと、発行者のＰＮＲＰサービスに関するアドレスタプルを含む。この実施形態では、アドレス証明書は、［Ｖｅｒｓｉｏｎ， ＩＤ， ＜Ａｄｄｒｅｓｓ＞ＩＤ， ＜Ａｄｄｒｅｓｓ＞ＰＮＲＰ， Ｖａｌｉｄｉｔｙ， Ｒｅｖｏｋｅ Ｆｌａｇ， Ａｌｇｏｒｉｔｈｍｓ， ＰＩｓｓｕｅｒ］ＫＩｓｓｕｅｒとなる。この拡張された表現では、ＩＤは発行すべき識別子であり、Ｇｒｏｕｐ ＩＤまたはＰｅｅｒ ＩＤでよい。＜Ａｄｄｒｅｓｓ＞は、ＩＰｖ６アドレス、ポート、およびプロトコルのタプルである。＜Ａｄｄｒｅｓｓ＞ＩＤは、ＩＤに関連付けるべきアドレスタプルである。＜Ａｄｄｒｅｓｓ＞ＰＮＲＰは、発行者のマシンにおけるＰＮＲＰサービス（または他のＰ２Ｐサービス）のアドレスタプルである。これは、発行者のＰＮＲＰアドレスのアドレスであることが好ましい。これは、証明書の有効性を検証するために、他のＰＮＲＰノードによって使用される。Ｖａｌｉｄｉｔｙは、１対のＦｒｏｍ−Ｔｏ ｄａｔｅで表される有効期間を表す。取消しフラグは、セットされたとき取消し証明書をマークする。ＰＩｓｓｕｅｒは、証明書発行者の公開鍵であり、ＫＩｓｓｕｅｒは、ＰＩｓｓｕｅｒに対応する秘密鍵である。証明書発行者がＩＤ所有者である場合、これは、ＩＤの秘密鍵ＫＩＤである。
【００５４】
本発明の好ましい実施形態では、証明書が有効であるためには以下の条件を満たさなければならない。証明書署名が有効でなければならず、証明書は満了することができない。すなわち、ＵＤＴとして表される現在の日付は、Ｖａｌｉｄｉｔｙフィールドで指定される範囲内になければならない。公開鍵のハッシュもまた、ＩＤと一致しなければならない。発行者がＩＤ所有者と同じである場合、発行者の公開鍵の、ＩＤへのハッシングを検証しなければならない。ＰＩｓｓｕｅｒがＰＩＤと異なる場合、ＫＩＤで署名された証明書に導く証明書のチェーンが存在しなければならない。このようなチェーンにより、発行者とＩＤ所有者との間の関係が検証される。加えて、証明取消しリスト（ＣＲＬ）が、ＩＤのそのクラスに関して発行され、ＣＲＬがアクセス可能である場合、オーセンティケータは、チェーン中の証明書がＣＲＬ内に出現しないことを検証することができる。
【００５５】
本発明のセキュリティ・インフラストラクチャはまた、インセキュアＰＡＣも扱う。本発明によれば、インセキュアＰＡＣは、ＩＤの導出元のユニフォームリソース識別子（ＵＲＩ）を含めることによって自己検証型となる。実際、セキュアＩＤとインセキュアＩＤはどちらも、ＰＡＣ内にＵＲＩを含む。ＵＲＩは、「ｐ２ｐ：／／ＵＲＩ」というフォーマットである。これにより、悪意のあるノードが、インセキュアＰＡＣで別のノードのセキュアＩＤを発行することが防止される。
【００５６】
本発明のセキュリティ・インフラストラクチャは、インセキュアＩＤの使用も可能にする。このようなインセキュアＩＤに伴う問題は、偽造が非常に容易であることである。悪意のあるノードは、他の任意のノードのインセキュアＩＤを発行することができる。インセキュアＩＤは、良好なノードの発見を困難にすることが可能となるセキュリティホールも開く。しかし、本発明に従ってＵＲＩを含めることにより、インセキュアＩＤは、決してセキュアＩＤに影響を及ぼすことがない。さらに、本発明のインフラストラクチャにより、インセキュアＩＤを含むＰＡＣが、セキュアＰＡＣと同じフォーマットとなることが必要となる。すなわち、これらは公開鍵と秘密鍵を含む。セキュアＰＡＣに対する構造と同じ構造をインセキュアＰＡＣに対して実施することにより、ＰＡＣを生成するためのバー（ｂａｒ）は低下しない。さらに、ＰＡＣ内にＵＲＩを含めることにより、特定のセキュアＩＤにマッピングするＵＲＩを生成することは、計算上実現不可能となる。
【００５７】
ここで生じる１つの問題は、Ｐ２Ｐクラウドセキュリティの向上とオーバヘッドの増加との兼ね合いを認識した上で、ＰＡＣをいつ検証するかということである。しかし、上述した様々なパケットに含まれるＰＡＣは、ある時点で検証しなければならない。このＰＡＣ検証は、ＩＤの署名が有効かどうかをチェックすること、およびＩＤがセキュアＩＤについての公開鍵に対応するかどうかをチェックすることを含む。オーバヘッドとセキュリティの問題の平衡をとるため、本発明の一実施形態では、そのパケットのどんな処理を行うよりも前にＰＡＣを検証する。これにより、無効データは決して処理されないことが保証される。しかし、ＰＡＣ検証がパケットの処理を低下させる可能性があり、そのことは、あるクラスのパケット、例えばＲＥＳＯＬＶＥパケットには適さないことを認識して、本発明の代替実施形態ではこのパケット中のＰＡＣを検証しない。
【００５８】
ＰＡＣの検証に加えて、本発明のセキュリティ・インフラストラクチャはまた、ＩＤ所有権のチェックを実施してＰＡＣを検証する。上述したように、個人情報の盗用は、ＰＮＲＰまたは他のＰ２Ｐプロトコルでアドレスを使用する前に、そのアドレス証明書の単純な検証によって見つけることができる。この検証は、ＩＤが、証明書に含まれる公開鍵のハッシュであることを単に検証することを伴うことがある。所有権の検証は、そのＰＡＣ中のアドレスにＩＮＱＵＩＲＥパケットを発行することも伴う。ＩＮＱＵＩＲＥパケットは、検証すべきＩＤと、トランザクションＩＤを含む。ＩＤがそのアドレスに存在する場合、ノードはそのＩＮＱＵＩＲＥを確認すべきである。ＩＤがそのアドレスに存在しない場合、ノードはそのＩＮＱＵＩＲＥを確認すべきではない。識別を検証するのに証明書チェーンが必要である場合、ノードは、完全な証明書チェーンを返す。供給される証明書チェーンにおける承認のチェーンを検証するのと同様に、署名およびＩＤ−＞ＵＲＬの検証は、依然として複雑であり、本発明のシステムは、ＰＡＣの検証に追加の複雑さを加えることになるあらゆるチャレンジ／応答プロトコルを回避する。さらに、トランザクションＩＤを含めることにより、悪意のあるノードがＩＮＱＵＩＲＥＳに対する応答を事前生成することを防止する。加えて、この機構は、ＰＡＣが完全な証明書チェーンを搬送するという要件が不要となる。
【００５９】
標準ＲＥＳＯＬＶＥパケットを変更することにより、本発明のシステムにおいて、ＩＤ所有権チェックを容易にし、標準ＲＥＳＯＬＶＥパケットがＩＤ所有権チェックも実施することができるようにする。変更されたＲＥＳＯＬＶＥパケットは、ＲＥＳＯＬＶＥの転送先アドレスのＩＤを含む。ＩＤがそのアドレスにある場合はＡＣＫを送信し、そうでない場合はＮＡＣＫを送信する。ＩＤがＲＥＳＯＬＶＥを処理しない場合、またはＮＡＣＫが受信される場合、ＩＤはキャッシュから除去される。このようにして、ある種のチャレンジ／応答プロトコルに頼ることなしに、特別などんなＩＮＱＵＩＲＥパケットも送信することなく、本質的には、ＩＮＱＵＩＲＥメッセージをＲＥＳＯＬＶＥに便乗させることによってＰＡＣを検証する。この便乗プロセスを、図２に参照して以下で再度論じる。この手順により、無効なＰＡＣ、または古いＰＡＣを見つけることが容易になる。
【００６０】
この識別検証チェックは、２つの相異なる時刻に行われる。最初は、ノードが、ノードの最低の２つのキャッシュレベルの一方にＰＡＣを加えようとしているときである。最低の２つのキャッシュレベルにおけるＰＡＣ有効性は、ＰＮＲＰＩＤを変換するＰＮＲＰの能力にとって重要である。これらの２つのレベルの一方にＰＡＣを加える前に、識別検証を実施することにより、いくつかの攻撃が軽減される。ＰＡＣをより高位のレベルのキャッシュに加えるべき場合、これらの高位レベルでは入替りがあるために、ＩＤ所有権は実施されない。キャッシュの高位レベルのすべてのＰＡＣエントリのほぼ８５％は、それが使用される前に置換され、または有効期限が切れることが確認されている。したがって、これらの高位レベルに無効ＰＡＣを有することによる何らかの効果を確認する確率は、無効ＰＡＣが入ったときにＩＤ検証を実施することが正当化されないほどに十分低い。
【００６１】
エントリが最低の２つのキャッシュレベルの一方に属すると判定されるとき、ＰＡＣは、その識別を検証することができるまで、保留リスト内に配置される。この第１種の識別検証は、ＩＮＱＵＩＲＥメッセージを使用する。このような識別検証は、ＰＡＣがその発信側ノードで依然として有効である（登録されている）ことを確認し、発信側ノードの検証権限がそのＰＡＣを発行する助けになる情報を要求する。ＩＮＱＵＩＲＥメッセージ中の１つのフラグは、ＡＵＴＨＯＲＩＴＹ応答内の証明書チェーン（それが存在する場合）を送信するように受信側に要求する「フラグ」フィールド、すなわちＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮに対して定義される。ＩＮＱＵＩＲＥの受信側がＰＡＣを発行する権限を有さない場合、またはＰＡＣがもはやローカルに登録されていない場合、受信側は単にＩＮＱＵＩＲＥメッセージを除去する。ローカルノードがＡＵＴＨＯＲＩＴＹメッセージを介して適切な応答を受信しないので、不良なＰＡＣは、そのキャッシュ内に決して入らず、したがって、Ｐ２Ｐクラウドにおけるオペレーションに対して悪意のある効果を有さないようにすることができる。
【００６２】
ＩＮＱＵＩＲＥの受信側がＰＡＣを発行する権限を有し、および依然としてローカルに登録されている場合、そのノードは、図２に示すように、ＡＵＴＨＯＲＩＴＹメッセージでＩＮＱＵＩＲＥメッセージに応答する（２００）。図２には示していないが、本発明の実施形態での受信側ノードは、ＡＵＴＨＯＲＩＴＹを送信したノードでＩＤが依然として登録されているとＡＵＴＨＯＲＩＴＹメッセージが示すか否かを確認するためにチェックする。ローカルノードが、このＡＵＴＨＯＲＩＴＹメッセージがＩＮＱＵＩＲＥに対する応答であると判定した後（２０２）、ローカルノードは、保留リストからＰＡＣを除去する（２０４）。証明書チェーンが要求された場合（２０６）、証明書チェーンが存在し、有効であるかどうかを確認するためにＡＵＴＨＯＲＩＴＹメッセージをチェックする（２０８）。証明書チェーンが存在し、有効である場合、ＰＡＣがキャッシュに追加され、有効なものとしてマークされる（２１０）。そうでない場合、ＰＡＣは削除される（２１２）。証明書チェーンが要求されなかった場合（２０６）、単にＰＡＣがキャッシュに追加され、有効なものとしてマークされる（２１０）。
【００６３】
今や明らかであろうが、このＡＵＴＨＯＲＩＴＹメッセージは、ＰＮＲＰ ＩＤが依然としてローカルノードに登録されていることを確認または否定するのに使用され、任意選択で、このＡＵＴＨＯＲＩＴＹメッセージは、ＡＵＴＨＯＲＩＴＹ受信側がノードの権利を検証してターゲットＩＤに対応するＰＡＣを発行することを可能にする証明書チェーンを提供する。ＩＮＱＵＩＲＥメッセージに加えて、ＡＵＴＨＯＲＩＴＹメッセージは、以下に論じるようにＲＥＳＯＬＶＥメッセージに対する適切な応答でよい。ＡＵＴＨＯＲＩＴＹメッセージは、否定的応答を示すために受信側ノードがセットすることができる様々なフラグを含む。このような１つのフラグは、ＲＥＳＯＬＶＥに対する応答においてのみ有効であるＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹフラグである。このフラグは、ホストが非常にビジーであるためにＲＥＳＯＬＶＥを受諾することができないことを示し、送信側に、処理のためにＲＥＳＯＬＶＥを別のところに転送すべきであることを伝える。識別検証では助けとはならないが、以下でより完全に論じるように、このフラグは、ＤｏＳ攻撃を防止するための本発明の別のセキュリティ機構である。フラグＡＦ＿ＩＮＶＡＬＩＤ＿ＳＯＵＲＣＥは、ＲＥＳＯＬＶＥに対する応答においてのみ有効であり、ＲＥＳＯＬＶＥ内のＳｏｕｒｃｅ ＰＡＣが無効であることを示す。ＡＦ＿ＩＮＶＡＬＩＤ＿ＢＥＳＴ＿ＭＡＴＣＨフラグは、ＲＥＳＯＬＶＥに対する応答においてのみ有効であり、ＲＥＳＯＬＶＥ内の「最良マッチ」ＰＡＣが無効であることを示す。ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤフラグは、指定された「検証」ＰＮＲＰ ＩＤがこのホストで登録されていないことを示す。ＡＵＴＨＯＲＩＴＹメッセージ内の他のフラグは、要求された情報が含まれていることを受信側ノードに示す。ＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮフラグは、「検証」ＰＮＲＰ ＩＤと、そのＰＡＣに署名するのに使用する公開鍵との関係を検証することを可能にする証明書チェーンが含まれていることを示す。ＡＵＴＨＯＲＩＴＹメッセージは、ＩＮＱＵＩＲＥメッセージまたはＲＥＳＯＬＶＥメッセージのどちらかに対する確認／応答としてのみ送信される。ＡＵＴＨＯＲＩＴＹがこの状況外で受信される場合、ＡＵＴＨＯＲＩＴＹは廃棄される。
【００６４】
識別検証が実施される第２のときは、ＲＥＳＯＬＶＥプロセスの間の適当なときに実施される。上述したように、ＰＮＲＰキャッシュは、高速に入れ替わる。したがって、キャッシュ内の大部分のキャッシュエントリは、それが使用される前に上書きされる。したがって、本発明のセキュリティ・インフラストラクチャは、これらのＰＡＣが実際に使用されるまで、かつ実際に使用されない限り、これらのＰＡＣを検証しない。ＰＡＣを使用してＲＥＳＯＬＶＥ経路を経路指定するとき、本発明のシステムは、上述したＲＥＳＯＬＶＥパケットに加えて識別検証を便乗させる。ＲＥＳＯＬＶＥは、ＩＮＱＵＩＲＥパケット中の「ターゲットＩＤ」と同様に扱われる「次のホップ」ＩＤを含む。次に、ＲＥＳＯＬＶＥは、上述したＩＮＱＵＩＲＥに対して予想されるのと同様に、ＡＵＴＨＯＲＩＴＹパケットを用いて確認される。適当なときの識別検証が失敗した場合、ＲＥＳＯＬＶＥの受信側は、送信側が受信側であると信じるものではない。したがって、ＲＥＳＯＬＶＥは別のところに経路指定され、無効ＰＡＣがキャッシュから除去される。
【００６５】
このプロセスもまた図２に示す。ＰＮＲＰノードＰが、ＲＥＳＯＬＶＥをセットする（２０２）ヘッダのＭｅｓｓａｇｅ Ｔｙｐｅフィールドを有するＡＵＴＨＯＲＩＴＹパケットを受信するとき（２００）、上述したように、受信側ノードは、ＡＵＴＨＯＲＩＴＹフラグを検査し、このＡＵＴＨＯＲＩＴＹフラグが否であるかどうかを判定する（２１４）。ＡＵＴＨＯＲＩＴＹメッセージに、否定的な応答フラグのいずれかがセットされている場合、ＰＡＣをキャッシュから削除し、ＲＥＳＯＬＶＥを別のところに経路指定する（２１６）。ＲＥＳＯＬＶＥの送信先のアドレスをＲＥＳＯＬＶＥ経路に追加し、ＲＥＪＥＣＴＥＤとマークする。次に、ＲＥＳＯＬＶＥを新しい宛先に転送する。ＡＵＴＨＯＲＩＴＹが否でなく、かつ証明書チェーンが要求された場合（２１８）、ＡＵＴＨＯＲＩＴＹメッセージフラグＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮをチェックし、証明書チェーンが存在するかどうかを確認する。証明書チェーンが存在する場合、受信側ノードは、検証で指定されたＰＮＲＰ ＩＤに関するキャッシュされたＰＡＣに対するチェーン検証オペレーションを実施すべきである。チェーンをチェックして、チェーン内のすべての証明書が有効であり、かつチェーンのルートとリーフの間の関係が有効であることを保証すべきである。チェーンルートに関する公開鍵のハッシュは、少なくとも、ＰＡＣのＰ２Ｐ名での権限と比較して、確実にそれらがマッチするようにすべきである。チェーンリーフに関する公開鍵は、ＰＡＣを署名するのに使用する鍵と比較して、確実にそれらが一致するようにすべきである。これらのチェックのいずれかが失敗し、または要求時に証明書チェーンが存在しない場合（２２０）、キャッシュ２２２からＰＡＣを除去し、ＲＥＳＯＬＶＥを再処理すべきである。要求された証明書チェーンが含まれており、かつ検証された場合（２２０）、検証ＰＮＲＰ ＩＤに対応するＰＡＣを、完全に検証したものとしてマークすべきである（２２４）。望むなら、ＰＮＲＰ ＩＤ、ＰＮＲＰサービスアドレス、および検証時間を、ＰＡＣから保持することができ、ＰＡＣ自体は、メモリを節約するためにキャッシュから削除することができる。
【００６６】
この識別検証の一例として、ＰがＰＮＲＰ ＩＤ「Ｔ」に関する識別検証を要求するノードであると仮定する。Ｎが、識別検証要求を受信するノードである。このことは、ターゲットＩＤ＝ＴのＩＮＱＵＩＲＥパケット、または次のホップ＝ＴであるＲＥＳＯＬＶＥパケットのどちらかを受信するＰの結果として生じる可能性がある。Ｎは、ローカルに登録されたＰＮＲＰ ＩＤのリストをチェックする。Ｔがそのリスト中に存在しない場合、受信したパケットの種類をチェックする。パケット種類がＩＮＱＵＩＲＥであった場合、Ｎは暗黙のうちにＩＮＱＵＩＲＥ要求を除去する。通常の再送信の試行が満了した後、Ｐは、ＰＡＣを無効なものとして廃棄し、処理は終了する。パケット種類がＲＥＳＯＬＶＥであった場合、Ｎは、ＩＤ Ｔがローカルに登録されていないことを示すＡＵＴＨＯＲＩＴＹパケットで応答する。次に、Ｐは、ＲＥＳＯＬＶＥを別のところに送信する。ＴがＮのＰＮＲＰ ＩＤのリスト中に存在する場合、Ｎは、ＡＵＴＨＯＲＩＴＹパケットを構築し、ターゲットＩＤをＴにセットする。ＴがインセキュアＩＤである場合、Ｎは、ＡＵＴＨＯＲＩＴＹパケットをＰに送信する。ＴがセキュアＩＤであり、かつセキュアＩＤに関する権限が、ＰＡＣに署名するのに使用する鍵である場合、ＮはＡＵＴＨＯＲＩＴＹパケットをＰに送信する。これらのどれも真ではなく、かつＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮフラグがセットされている場合、Ｎは、ＰＮＲＰ ＩＤ Ｔに関する権限に対してＰＡＣに署名するのに使用する鍵に関する証明書チェーンを取り出す。証明書チェーンは、ＡＵＴＨＯＲＩＴＹパケットに挿入され、Ｎは、ＡＵＴＨＯＲＩＴＹパケットをＰに送信する。この点で、ＴがインセキュアＩＤである場合、処理は完了する。そうでない場合、Ｐは、ＰＡＣに署名する鍵と、ＰＮＲＰ ＩＤ Ｔを生成するのに使用する権限との関係を検証する。検証が失敗した場合、ＰＡＣを廃棄する。検証が失敗し、かつ開始メッセージがＲＥＳＯＬＶＥであった場合、Ｐは、別のところにＲＥＳＯＬＶＥを転送する。
【００６７】
ここで識別所有権検証を２回実施したことから今や理解するであろうが、ＩＮＱＵＩＲＥパケット、または修正後のＲＥＳＯＬＶＥパケットにより、ＦＬＯＯＤを使用してＰ２Ｐクラウド全体にわたって無効ＰＡＣを一般化することができず、検索は、存在しないＩＤまたは無効なＩＤに転送されない。ＦＬＯＯＤパケットが検証なしにネットワーク中を伝播することが可能である場合、ＦＬＯＯＤパケットがＤｏＳ攻撃を引き起こす可能性があるので、ＦＬＯＯＤに対してＰＡＣ検証が必要である。これらの機構により、一般ノードのＩＤが非常に少数のノードの最低の２つのキャッシュレベルのみに属することになるので、一般ノードがＩＤ所有権チェックでフラッディングを受けることはない。
【００６８】
上述した同時係属出願により完全に記載されているように、ＰＮＲＰノードＮは、４つの方式のうちの１つにより、新しいＩＤについて認識する。ＰＮＲＰノードＮは、近隣のキャッシュの初期フラッディングによって新しいＩＤを認識することができる。具体的には、Ｐ２Ｐノードが浮上するとき、Ｐ２Ｐノードは、Ｐ２Ｐクラウドの別のノードメンバと接触し、キャッシュ同期シーケンスを開始する。Ｐ２Ｐノードは、近隣がその最低のキャッシュの新しいレコードをフラッディングする結果として、新しいＩＤを認識することができる。例えば、ノードＮがノードＭの最低レベルのキャッシュ内のエントリとして出現すると仮定する。Ｍが新しいＩＤについて認識するとき、ＩＤがＭの最低レベルのキャッシュと適合する場合、Ｍは、そのキャッシュレベル内の他のエントリと、ＮにそのＩＤをそれぞれフラッディングする。ノードは、検索要求の結果として新しいＩＤを認識することができる。検索要求の発信元は、要求内に発信元のアドレス証明書を挿入し、検索要求に対する「最良マッチ」のＰＡＣもまた、そのＰＡＣを要求内に挿入する。このようにして、検索要求経路に沿うノードのすべては、検索発信元のアドレス、および最良マッチのアドレスでノードのキャッシュを更新することになる。同様に、ノードは、検索応答の結果として新しいＩＤを認識することができる。検索要求の結果は、要求経路のサブセットを逆の順序で移動する。この経路に沿うノードは、検索結果でノードのキャッシュを更新する。
【００６９】
ＰＮＲＰによれば、ノードが最初に浮上するとき、ノードは近隣を見つける。しかし、上述したように、最初に見つかったノードが悪意のあるノードである場合、その新しいノードは、悪意のあるノードによって制御される可能性がある。このような発生の可能性を防止し、または最小にするため、本発明のセキュリティ・インフラストラクチャは、セキュアノードブートアップを保証するための２つの機構を提供する。第１の機構は、ランダム化されたディスカバリである。ノードが、そのノードがＰＮＲＰクラウドに加わることを可能にする別のノードを見つけようと試みるとき、見つけるための最後の選択肢は、マルチキャスト／同報通信を使用することである。マルチキャスト／同報通信は、最もインセキュアなＰＮＲＰの発見方法だからである。ディスカバリの性質のために、良好なノードと不良なノードとを区別することが非常に難しい。したがって、このマルチキャスト／同報通信方法が必要なとき、本発明のセキュリティ・インフラストラクチャは、同報通信ディスカバリ（ＭＡＲＣＯＰＯＬＯまたは既存のマルチキャストディスカバリプロトコル。例えばＳＳＤＰ）メッセージに応答したノードのうちの１つを、ノードにランダムに選択させる。ランダムなノードを選択することにより、本発明のシステムは、不良なノードを選択する確率を最小にする。本発明のシステムは、そのＩＤのいずれも使用せずにこのディスカバリを実施する。ディスカバリ中にＩＤを使用しないことにより、本発明のシステムは、悪意のあるノードが特定のＩＤをターゲットにすることを防止する。
【００７０】
ノードがその間にビットベクトルを維持する修正された同期段階により、第２のセキュアノードブートアップ機構が提供される。修正された同期段階機構は、図３の単純化した流れ図に示す例により、最もよく理解できる。アリス２２６が、アリス２２６のＰＡＣが含まれるＳＯＬＩＣＩＴ ２２８をボブ２３０に送信すると仮定する。アリスのＰＡＣが有効でない場合（２３２）、ボブ２３０は、単にＳＯＬＩＣＩＴ ２３４を除去する。ＰＡＣが有効である場合、ボブ２３０は、この接続の状態を格納するためにビットベクトルを維持する。このＳＯＬＩＣＩＴを受信したとき、ボブ２３０は、ナンスを生成し、それをアリスのＰＮＲＰ ＩＤでハッシュする（２３６）。得られる数は、ボブがセットするこのビットベクトルの索引として使用される。次に、ボブ２３０は、ＡＤＶＥＲＴＩＳＥメッセージでアリス２２６に応答する（２３８）。このＡＤＶＥＲＴＩＳＥは、他の情報とは別にアリスの公開鍵で暗号化されたボブのＰＡＣおよびナンスを含み、ボブ２３０によって署名される。アリス２２６がこのＡＤＶＥＲＴＩＳＥを受信したとき、アリス２２６は、署名およびボブのＰＡＣを検証する（２４０）。それを検証することができない場合、除去される（２４１）。それを検証することができる場合、アリス２２６は、ナンスを暗号化解除する（２４２）。次に、アリス２２６は、このナンスおよびアリスのＰＮＲＰ ＩＤを含むＲＥＱＵＥＳＴを生成する（２４４）。ボブ２３０は、ＲＥＱＵＥＳＴパケットで送信されたナンスでアリスのＰＮＲＰ ＩＤをハッシングすることによって、このＲＥＱＵＥＳＴを処理する（２４６）。ハッシングされた結果を索引として有するビットベクトルにビットがセットされている場合（２４８）、ボブは、ビットをクリアし、ＲＥＱＵＥＳＴの処理を開始する（２５０）。そうでない場合、ＲＥＱＵＥＳＴは応答攻撃である可能性があるので、ボブは、ＲＥＱＵＥＳＴを無視する（２５２）。
【００７１】
これにより、シーケンスを再生することができないので、ノードブートアップは、セキュアプロセスになる。これにより、ＣＰＵ、ネットワークポート、およびネットワークトラフィックを含む、消費されるリソースの点で、必要なオーバヘッドが最小となる。状態情報に対して維持すべきタイマは不要であり、シンクアップを開始したＩＤだけが送信データとなる。実際、修正された同期段階は、非同期であり、それにより、ノードが複数のＳＯＬＩＣＩＴを同時に処理することが可能となる。
【００７２】
パケットを処理する速度を制御し、すなわちノードリソース消費を制限することにより、上述した脅威の多くを最小にすることができる。この背後にある考えは、ノードは、ＰＮＲＰパケットを処理しようとするノードのＣＰＵを１００％消費すべきでないということである。したがって、本発明の実施形態によれば、あるメッセージの処理が、ノードが効果的に機能することを妨害するとノードが検出したとき、ノードは、そのようなメッセージの処理を拒絶することができる。
【００７３】
処理しないとノードが判断することができるそのような１つのメッセージは、別のノードから受信したＲＥＳＯＬＶＥメッセージである。図４に、このプロセスを単純化した形で示す。ＲＥＳＯＬＶＥメッセージを受信した後（２５４）、ノードは、所定の限界を超えるＣＰＵ能力でノードが現在動作しているかどうかをチェックする（２５６）。ノードのＣＰＵが非常にビジーであるためにＲＥＳＯＬＶＥメッセージを処理することができない場合、ノードは、ノードが非常にビジーであるために要求を処理することに失敗したことを示すＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹフラグセットを有するＡＵＴＨＯＲＩＴＹメッセージを送信する（２５８）。ＣＰＵがそれほどビジーではない場合（２５６）、ノードは、ＲＥＳＯＬＶＥメッセージ内のＰＡＣのすべてが有効であるかどうかを判定し（２６０）、いずれかが無効であることが判明した場合、メッセージを拒絶する（２６２）。ＰＡＣのすべてが有効である場合（２６０）、ノードはＲＥＳＯＬＶＥを処理する（２６４）。
【００７４】
ノードがＲＥＳＯＬＶＥに応答することができる場合（２６６）、ノードはＲＥＳＯＬＶＥをＲＥＳＰＯＮＳＥに変換し、それをＲＥＳＯＬＶＥの送信元のノードに送信する（２６８）。しかし、ターゲットＩＤがローカルに登録されていない場合、ノードはＲＥＳＯＬＶＥ内のフィールドのハッシュとしてビット位置を計算し、対応するビット位置をビットベクトルにセットする（２７０）。上記で簡潔に論じたように、このビットベクトルは、応答が期待されるどんなメッセージもノードが送信していないときに、誤り応答メッセージの処理を防止するためのセキュリティ機構として使用される。ノードは、ノードがメッセージを処理したことを証明する適切な変更と共にＲＥＳＯＬＶＥを転送する次のホップを見つける。ＲＥＳＯＬＶＥを転送すべき転送先のノードが既に検証されている場合（２７２）、ノードは単に、ＲＥＳＯＬＶＥをその次のホップに転送する（２７６）。この選択された次のホップがまだ検証されていない場合（２７２）、ノードは、ＲＥＳＯＬＶＥにＩＤ所有権要求を便乗させ（２７４）、それをそのノードに転送する（２７６）。便乗させたＩＤ所有権要求に応答して、ノードは、上述したようにＡＵＴＨＯＲＩＴＹメッセージを受信することを期待する。そのプロセスを図２に示す。図２に示すように、ステップ２１４で検証ＡＵＴＨＯＲＩＴＹが受信されていない場合、ＲＥＳＯＬＶＥが転送されたノードのＰＡＣがキャッシュから削除され（２１６）、ＲＥＳＯＬＶＥが図４のステップ２５４から再処理される。
【００７５】
ノードのＣＰＵが非常にビジーであるためにノードが処理しないと判断することができる別のメッセージは、ＦＬＯＯＤメッセージである。図５に単純化した形で示すこのプロセスでは、ＦＬＯＯＤ中に存在する新しい情報が最低の２つのキャッシュレベルの一方に進んだ場合（２７８）、ＰＡＣをチェックして、ＰＡＣが有効であるかどうかを判定する（２８０）。ＰＡＣが有効でない場合、ＦＬＯＯＤを拒絶する（２８４）。しかし、ＰＡＣが有効である場合（２８０）、ＰＡＣを保留リストに入れる（２８２）。保留リスト中のエントリは、ランダムな間隔でとられ、ＣＰＵがそれほどビジーでないときに処理される。これらのエントリがキャッシュの最低の２つのレベルに入ろうとしているので、上述したように、ＩＤ検証と所有権検証が共に実施される。ＦＬＯＯＤ中に存在する新しい情報がより高いキャッシュレベルに進み（２７８）、かつＣＰＵが非常にビジーでそれを処理することができない場合（２８６）、それは廃棄される（２８８）。ノードが利用可能なＣＰＵ処理能力を有する場合（２８６）、ＰＡＣをチェックし、それが有効であるかどうかを判定する（２９０）。有効である場合、ＰＡＣをキャッシュに追加し（２９２）、そうでない場合ＦＬＯＯＤを拒絶する（２９４）。
【００７６】
ノードブートアップ（ＳＹＮＣＨＲＯＮＩＺＥ）は、ＣＰＵ処理能力だけでなく、ネットワーク帯域幅も含むかなりのリソースをノードで消費する別のプロセスである。しかし、新しいノードがＰ２Ｐクラウドに完全に参加することを可能にするためには、同期プロセスが必要である。したがって、ノードが所与の時間に利用可能なリソースを十分に有する場合、ノードは、ブートアップを求める別のノードの要求に応答する。すなわち、これまで議論した２つのメッセージと同様に、ノードのＣＰＵ稼働率が非常に高い場合、ノードは、ブートアップへの参加を拒絶することができる。しかし、このプロセスは非常に多くの能力を消費するので、悪意のあるノードが、多数のこのようなシーケンスを立ち上げることにより、依然としてこのプロセスを利用する可能性がある。したがって本発明のセキュリティ・インフラストラクチャの実施形態は、この攻撃を防止するために、所与のノードによって処理することができるノード同期の数を制限する。加えて、この制限を時間限定とすることができ、その結果、悪意のあるノードは、このような同期を将来再び実施できないようにノードを使用不能にすることができない。
【００７７】
悪意のあるノードによって立ち上げられ、または引き起こされる可能性のある多数の検索ベースの攻撃を上述した。このような検索ベースの攻撃の効果をなくし、または最小にするため、本発明のシステムは２つの機構を提供する。第１の機構はランダム化である。すなわち、ノードが、検索要求（ＲＥＳＯＬＶＥ）の転送先の適切な次のホップを検索しているとき、ノードは、いくつかの可能な候補ノードを識別し、次に、これらの候補ＩＤから、ＲＥＳＯＬＶＥの転送先となる１つのＩＤをランダムに選択する。一実施形態では、ランダムな選択のために３つの候補ノードが識別される。ＩＤは、全ランダム化の代替方法として、重み付けした確率に基づいて選択することができる。ＩＤが悪意のないノードに属することの重み付けした確率を計算する１つの方法は、ターゲットＩＤからのＰＮＲＰ ＩＤの距離に基づく。次に、そのノードとターゲットノードとの間のＩＤ距離の反比例として確率が決定される。いずれにしても、このランダム化により、悪意のあるノードにＲＥＳＯＬＶＥ要求を送信する確率が減少する。
【００７８】
検索ベースの攻撃に対して効果的な第２のセキュリティ機構は、上述したビットベクトルを使用して状態情報を維持する。すなわち、ノードは、ノードが処理したＲＥＳＯＬＶＥメッセージであって、それに対する応答がまだ受信されていないＲＥＳＯＬＶＥメッセージのすべてを識別する情報を維持する。状態情報を維持するために使用するフィールドは、ターゲットＩＤと、ＲＥＳＯＬＶＥパケット中のアドレスリストである。この２番目のフィールドを、検索を妨害しようとする悪意のあるノードによってアドレスリストが変更されていないことを保証するために使用する。ビットベクトルの他の例に関して上述したように、ノードは、ＲＥＳＯＬＶＥからこれらのフィールドのハッシュを生成し、ビットベクトル中の対応するビット位置をセットして、そのＲＥＳＯＬＶＥの処理の履歴を維持する。
【００７９】
図６の単純化した流れ図に示すように、別のノードからＲＥＳＰＯＮＳＥメッセージを受信したとき（２９６）、このＲＥＳＰＯＮＳＥメッセージ中のフィールドをハッシュし、ビット位置を計算する（２９８）。次に、ノードは、ビットベクトルをチェックし、ビット位置がセットされているかどうかを確認する（３００）。ビットがセットされていない場合、このＲＥＳＰＯＮＳＥが以前に処理したＲＥＳＯＬＶＥとは関係がないことを意味し、パケットを廃棄する（３０２）。ビット位置がセットされている場合、このＲＥＳＰＯＮＳＥが以前に処理したＲＥＳＯＬＶＥと関係していることを示し、ビット位置をリセットする（３０４）。ビット位置をリセットすることにより、ノードは、悪意のあるノードからの再生攻撃の一部として送信された可能性のある、別の同一のＲＥＳＰＯＮＳＥメッセージを無視することになる。次に、ノードは、ＲＥＳＰＯＮＳＥを処理してそれを次のホップに転送する前に、ＲＥＳＰＯＮＳＥメッセージ中のＰＡＣのすべてが有効であるかどうかを確認するためにチェックを行う（３０６）。ＰＡＣのいずれかが無効である場合（３０６）、ノードはパケットを拒絶する（３１０）。
【００８０】
ＲＥＳＯＬＶＥプロセスは、ＲＥＳＯＬＶＥ要求をＲＥＳＰＯＮＳＥに変換することに触れる。ここで論じたこのＲＥＳＰＯＮＳＥの処理は、ＲＥＳＰＯＮＳＥが最近受信したＲＥＳＯＬＶＥに対応することを保証すること、および指定された次のホップにＲＥＳＰＯＮＳＥを転送することを含む。例えば、ノードＰが、ターゲットＰＮＲＰ ＩＤと、ＢｅｓｔＭａｔｃｈ ＰＡＣと、このノードの前に元のＲＥＳＯＬＶＥを処理したすべてのノードのアドレスをリストする経路とを含み、このノードがＰＮＲＰアドレスを所有することで終了するＲＥＳＰＯＮＳＥパケットＳを受信すると仮定する。ノードＰは、ＲＥＳＰＯＮＳＥの受信をＡＣＫで確認する。ノードＰは、それ自体のアドレスについてＲＥＳＰＯＮＳＥ経路をチェックする。ノードＰのアドレスは、このパケットが有効となるために、アドレスリスト中の最後のエントリでなければならない。ノードＰは、ＲＥＳＰＯＮＳＥが最近確認したＲＥＳＯＬＶＥとマッチすることを保証するために、受信したビットベクトルをチェックする。ＲＥＳＰＯＮＳＥが、受信したビットベクトル中のフィールドと一致しない場合、またはＰのアドレスが経路リスト中の最後のアドレスでない場合、ＲＥＳＰＯＮＳＥを暗黙のうちに除去し、処理は停止する。Ｐは、ＢｅｓｔＭａｔｃｈ ＰＡＣを検証し、それをＰのローカルキャッシュに追加する。ＢｅｓｔＭａｔｃｈが無効である場合、ＲＥＳＰＯＮＳＥを暗黙のうちに除去し、処理は停止する。Ｐは、ＲＥＳＰＯＮＳＥ経路の最後からそのアドレスを除去する。Ｐは、対応するＲＥＳＯＬＶＥ要求をＡＣＣＥＰＴしたノードを示すフラグセットを有する最後のエントリまで、ＲＥＳＰＯＮＳＥ経路の最後からエントリを除去することを続行する。経路がそのときに空である場合、対応するＲＥＳＯＬＶＥがローカルに生成される。ＰＮＲＰは、ＢｅｓｔＭａｔｃｈに対する識別検証チェックを行う。識別検証チェックが成功した場合、ＢｅｓｔＭａｔｃｈが要求マネージャに渡され、そうでない場合、失敗の表示が渡される。経路が空である場合、処理は完了する。経路が空でない場合、ノードは、ＲＥＳＰＯＮＳＥパケットを経路リスト中の最後のエントリに転送する。
【００８１】
発行されたアドレス証明書が証明書満了日（Ｖａｌｉｄｉｔｙ／Ｔｏフィールド）より前に無効になったときはいつでも、ＰＮＲＰアドレス証明書を取り消す必要がある。このようなイベントの例は、ノードがスムーズにＰ２Ｐネットワークから切断されるとき、またはノードがグループから離脱しつつあるときなどである。本発明の取消し機構は、取消し証明書の発行を利用する。取消し証明書は、Ｒｅｖｏｋｅ Ｆｌａｇセットと、現在時刻（または証明書を取り消すべき時刻）にセットされたＶａｌｉｄｉｔｙフィールドのＦｒｏｍ ｄａｔｅと、以前に公示された証明書と同じ値にセットされたＴｏフィールドとを有する。以下の条件すべてを満たす証明書すべてが取り消されるとみなされる。その証明書が同じ発行者によって署名されていること、ＩＤが取消し証明書のＩＤと一致すること、Ａｄｄｒｅｓｓフィールドが、取消し証明書のＡｄｄｒｅｓｓフィールドと一致すること、ＶａｌｉｄａｔｉｏｎフィールドのＴｏ ｄａｔｅが、取消し証明書のＶａｌｉｄａｔｉｏｎフィールドのＴｏ ｄａｔｅと同じであること、およびＶａｌｉｄａｔｉｏｎフィールドのＦｒｏｍ ｄａｔｅが、取消し証明書のＶａｌｉｄａｔｉｏｎフィールドのＦｒｏｍ ｄａｔｅに先行することである。取消し証明書が署名されるので、悪意のあるノードがクラウドからどれかを切断することができないことが保証される。
【００８２】
本発明の様々な実施形態の上記の説明は、例示および説明のために提示した。上記の説明は、包括的なものではなく、または開示される厳密な実施形態に本発明を限定するものではない。上記の教示に照らして、多数の修正形態または変形形態が可能である。本発明の原理およびその実際的な応用例を最良に例示し、それによって当業者が、企図される特定の使用法に適するように本発明を様々な実施形態で、様々な修正を加えて利用することが可能となるように、上記で議論した実施形態を選び、説明した。このような修正形態および変形形態は、頭記の特許請求の範囲が公平に、法律的に、かつ公正に権利を有する幅に従って解釈されるとき、頭記の特許請求の範囲に記載される本発明の範囲内にある。
【図面の簡単な説明】
【図１】本発明が常駐する例示的コンピュータシステムを一般的に示すブロック図である。
【図２】本発明の実施形態にかかるＡＵＴＨＯＲＩＴＹパケット処理のセキュリティ面を示す、単純化した流れ図である。
【図３】本発明の実施形態にかかるＰ２Ｐディスカバリの同期段階のセキュリティ面を示す、単純化した通信処理の流れ図である。
【図４】本発明の実施形態にかかるＲＥＳＯＬＶＥパケット処理のセキュリティ面を示す、単純化した流れ図である。
【図５】本発明の実施形態によるＦＬＯＯＤパケット処理のセキュリティ面を示す、単純化した流れ図である。
【図６】本発明の実施形態によるＲＥＳＰＯＮＳＥパケット処理のセキュリティ面を示す、単純化した流れ図である。
【符号の説明】
１００ コンピューティング環境
１１０ コンピュータ
１２０ 処理装置
１２１ システムバス
１３０ システムメモリ
１３１ 読取り専用メモリ
１３２ ランダムアクセスメモリ
１３３ 基本入出力システム
１３４、１４４ オペレーティングシステム
１３５、１４５ アプリケーションプログラム
１３６、１４６ 他のプログラムモジュール
１３７、１４７ プログラムデータ
１４０、１５０ インタフェース
１６０ ユーザ入力インタフェース
１６１ ポインティングデバイス
１６２ キーボード
１７０ ネットワークインタフェースまたはアダプタ
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ 広域ネットワーク
１８０ リモートコンピュータ
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ
【発明の属する技術分野】
本発明は、一般的にはピアツーピアプロトコルに関し、より詳細には、ピアツーピアプロトコルのためのセキュリティ・フレームワーク・インフラストラクチャに関する。
【０００２】
【従来の技術】
ピアツーピア通信、実際にはすべての種類の通信は、選択されたエンティティ間の有効な接続を確立する可能性に依存する。しかし、エンティティがネットワーク内で移動し、トポロジが変化し、またはアドレス・リース（ａｄｄｒｅｓｓ ｌｅａｓｅ）を更新することができないために、エンティティは、変動する可能性のある１または複数のアドレスを有することができる。したがって、このアドレス指定問題に対する古典的なアーキテクチャ上の解決策は、各エンティティに安定な名前を割り当て、接続が必要なときにこの名前を現在アドレスに「解決（ｒｅｓｏｌｖｅ）」することである。名前からアドレスへの変換は、非常に堅固でなければならず、容易かつ高速な更新も可能でなければならない。
【０００３】
エンティティへの接続を捜すことによって、エンティティのアドレスを見つける可能性を増加させるために、多くのピアツーピアプロトコルは、エンティティが様々な機構を介してエンティティのアドレスを発行することを可能にする。一部のプロトコルは、クライアントが、ネットワーク中の他のエンティティからの要求を処理することによって、他のエンティティのアドレスの知識を獲得することを可能にする。実際、このアドレス知識の獲得により、これらピアツーピアネットワークを首尾よく運用することが可能となる。すなわち、ネットワーク中の他のピアについての情報が良好であるほど、特定のリソースの検索が収束する可能性が高くなる。
【０００４】
しかし、ピアツーピアプロトコルの基礎となる堅固なセキュリティ・インフラストラクチャがなければ、悪意のあるエンティティは、このようなピアツーピアシステムの収束する能力を容易に破壊することができる。このような破壊は、例えば識別情報の盗用に関わるエンティティによって引き起こされる可能性がある。ピアツーピアネットワーク上のこのような識別情報の盗用攻撃において、悪意のあるノードは、許可された関係にない、すなわちその所有者でもグループのメンバなどでもないＩＤについてのアドレス情報を発行する。悪意のあるエンティティは、良好なノード応答の前に、最初に傍受および／または応答することができ、したがって良好なノードのように見える。
【０００５】
悪意のあるエンティティは、ネットワークに不良な情報をあふれさせることによってＰＮＲＰ解決を妨害することができ、ネットワーク中の他のエンティティが、存在しないノードに要求を転送する傾向を有し（このことは検索の収束に悪影響を与える）、または攻撃者によって制御されるノードに要求を転送する傾向を有する。このことは、リソースを見つけるために使用するＲＥＳＯＬＶＥパケットを転送する前に変更することによって、またはＲＥＳＯＬＶＥパケットを生成した要求者側に無効なＲＥＳＰＯＮＳＥを返送することによって達成される。悪意のあるエンティティは、例えば、ＩＤが近く検索の収束を助ける、悪意のあるエンティティのキャッシュ内のノードに検索を転送する代わりに、要求されたＩＤから非常に離れたノードに検索を転送することによって、ピアツーピアネットワークのオペレーションを妨害しようと試みることもできる。あるいは、悪意のあるエンティティは、単に検索要求に全く応答しないこともできる。ＰＮＲＰ解決は、有効なＩＤの代わりに無効なＢＹＥメッセージを送信する悪意のあるノードによってさらに妨害される可能性がある。その結果、クラウド（ｃｌｏｕｄ）内の他のノードは、そのノードのキャッシュからこの有効なＩＤを除去し、それらに格納された有効なノードの数が減少する。
【０００６】
アドレス証明書の検証は、識別情報の盗用問題を防止することができるが、ＰＮＲＰ解決を妨害する第２の種類の攻撃に対しては効果がない。攻撃者は、検証可能なアドレス証明書を生成し続け（またはそれを事前に生成し）、対応するＩＤをピアツーピアクラウド内にあふれさせることができる。ノードのいずれかがＩＤの所有権を検証しようと試みる場合、攻撃者は、実際そのノードが、あふれたＩＤの所有者であるので、そのことを検証することができる。しかし、攻撃者が十分なＩＤを生成するならば、攻撃者は、ピアツーピア検索の大部分を、攻撃者により制御されるノードのうちの１つに導くことができる。この点、攻撃者は、ネットワークのオペレーションをかなり制御し、管理することができる。
【０００７】
【発明が解決しようとする課題】
上述した識別情報の盗用問題を防止するために、すべての新しいアドレス情報を最初に検証することをピアツーピアプロトコルが要求する場合に、第３の種類の攻撃を悪意のあるエンティティが利用できるようになる。これら種類のピアツーピアネットワークが影響を受けやすい攻撃は、サービス妨害（ＤｏＳ）攻撃の形式である。新しいレコードについて理解するすべてのノードがＩＤ所有権のチェックを実施しようとする場合に、開示されたＩＤ所有者に対してネットワークアクティビティが殺到する。この弱点を利用して、攻撃者は、非常に一般化されたターゲットに対してＩＰ ＤｏＳ攻撃を仕掛けることができる。例えば、悪意のあるエンティティが、ＭｉｃｒｏｓｏｆｔのウェブＩＰアドレスをＩＤのＩＰとして公示した場合、開示されたＩＰを受信するピアツーピアネットワーク中のすべてのノードは、そのＩＰ（ＭｉｃｒｏｓｏｆｔのウェブサーバのＩＰ）に接続してレコードの真性を検証しようとする。もちろん、攻撃者がこの情報を生成したので、ＭｉｃｒｏｓｏｆｔのサーバがＩＤの所有権を検証することはできない。しかし、損害は既に生じている。すなわち、攻撃者は、ピアツーピアコミュニティの良好な部分にＭｉｃｒｏｓｏｆｔを攻撃させている。
【０００８】
１または複数のリソースを消耗させることによって、ノードまたはクラウドを圧倒する別の種類のＤｏＳ攻撃は、例えば、ＦＬＯＯＤ／ＲＥＳＯＬＶＥ／ＳＯＬＩＣＩＴパケットを使用することにより、大量の無効／有効ＰＡＣを単一のノードに送信する悪意のあるノードによって仕掛けられる。これらのＰＡＣを受信するノードは、ＰＡＣのすべてを検証しようとして、ノードのすべてのＣＰＵを消費することになる。同様に、無効ＦＬＯＯＤ／ＲＥＳＯＬＶＥパケットを送信することによって、悪意のあるノードは、クラウド内でパケットの増殖を達成する。すなわち、悪意のあるノードは、少数のそのようなパケットを使用して、ＰＮＲＰクラウド用のネットワーク帯域幅を消費することができる。このパケットの送信先のノードは、追加のパケットを送信することによって応答するからである。ネットワーク帯域幅の増殖は、悪意のあるノードが偽のＲＥＱＵＥＳＴメッセージを送信し、そのＲＥＱＵＥＳＴメッセージに対して、良好なノードがＲＥＱＵＥＳＴよりも大きいサイズのＰＡＣをＦＬＯＯＤすることによって応答することによっても達成される。
【０００９】
悪意のあるノードは、初期ノードのシンクアップ（ｓｙｎｃｈ ｕｐ）を妨害することによってＰＮＲＰクラウドに攻撃を仕掛けることもできる。すなわち、ＰＮＲＰクラウドに加わるために、ノードは、ＰＮＲＰクラウド内の既に存在しているノードのうちの１つに接続しようと試みる。ノードが悪意のあるにノードに接続しようと試みる場合に、ノードは、悪意のあるノードによって完全に制御されてしまう。さらに、悪意のあるノードは、２つの良好なノードが同期プロセスに関係しているとき、無効なＲＥＱＵＥＳＴパケットを送信することができる。無効なＲＥＱＵＥＳＴパケットにより、それに応答してＦＬＯＯＤメッセージの生成が開始されるので、これはシンクアップを妨害する一種のＤｏＳ攻撃である。
【００１０】
したがって、このような攻撃の効果を防止または軽減することによって、Ｐ２Ｐクラウドの保全性を保証するセキュリティ機構が当技術分野で求められている。
【００１１】
【課題を解決するための手段】
本願で開示される発明の概念は、悪意のあるノードがピアツーピアネットワークの通常のオペレーションを妨害することを抑制する、新規で改良された方法を含む。具体的には、本発明は、識別情報の盗用攻撃、サービス妨害攻撃、単にピアツーピアネットワーク中のアドレス解決を妨害しようと試みる攻撃、およびピアツーピアネットワークに加わり、参加する新しいノードの能力を妨害しようと試みる攻撃を含む、悪意のあるノードによって仕掛けられる可能性のある様々な種類の攻撃に対処する方法を提示する。
【００１２】
提示されたセキュリティ・インフラストラクチャおよび方法は、ノードを自己検証型にすることにより、ノードがセキュア識別とインセキュア識別の両方を使用することを可能にする。必要なとき、または適当なときに、既存のメッセージに対する検証を便乗させることにより、または必要であれば小さい紹介メッセージを送信することにより、ＩＤ所有権が検証される。接続先のノードをランダムに選択することにより、悪意のあるノードに最初に接続する確率が減少する。さらに、将来の応答を必要とする以前の通信についての情報を維持することにより、悪意のあるノードからの情報が識別され、それを廃棄することができる。ノードのリソース使用率が所定の限界を超えたときに、ノードが要求を廃棄することを可能にすることにより、サービス妨害攻撃が抑制される。除去されるノードが取消し証明書を署名することを要求することにより、悪意のあるノードが有効ノードを除去する能力は低下する。
【００１３】
本発明の一実施形態によれば、自己検証可能なインセキュアピアアドレス証明書（ＰＡＣ）を生成する方法が提示される。これは、悪意のあるノードが、ピアツーピアネットワーク内のインセキュアＰＡＣにおいて別のノードのセキュア識別を発行することを防止する、この方法は、ピアツーピアネットワーク内で見つけることができるリソースに対するインセキュアＰＡＣを生成するステップを含む。このリソースは、ピアツーピア識別子（ＩＤ）を有する。この方法は、ピアツーピアＩＤが導出されるインセキュアＰＡＣ内に、ユニフォームリソース識別子（ＵＲＩ）を含めるステップをさらに含む。ＵＲＩは、好ましくは、「ｐ２ｐ：／／ＵＲＩ」のフォーマットである。ピアツーピアＩＤは、インセキュアでもよい。
【００１４】
別の実施形態では、ピアツーピアネットワーク内の第１ノードでピアアドレス証明書を適当なときに検証する方法が提示される。この第１ノードは、ピアアドレス証明書を格納するために複数レベルのキャッシュを使用し、この方法は、第２ノードから意図的にピアアドレス証明書（ＰＡＣ）を受信するステップと、複数レベルのキャッシュのどのレベルにＰＡＣを格納すべきかを決定するステップとを含む。２つの最低のキャッシュレベルの一方にＰＡＣを格納すべきとき、この方法は、ＰＡＣを保留リストに配置し、検証すべきＰＡＣのＩＤを含むＩＮＱＵＩＲＥメッセージを生成し、ＩＮＱＵＩＲＥメッセージを第２ノードに送信する。２つの最低のキャッシュレベル以外の上位のキャッシュレベルにＰＡＣを格納すべきとき、この方法は、「未検証」としてマークされる上位のキャッシュレベルにＰＡＣを格納する。この場合、ＰＡＣは、それが使用される最初に検証される。この方法は、ＰＡＣを求める証明書チェーンを要求することもできる。
【００１５】
好ましい実施形態では、ＩＮＱＵＩＲＥメッセージの生成は、ＩＮＱＵＩＲＥメッセージに含めるべきトランザクションＩＤを生成するステップを含む。ＩＮＱＵＩＲＥメッセージに応答して第２ノードからＡＵＴＨＯＲＩＴＹメッセージが受信されたとき、ＰＡＣは、保留リストから除去され、２つの最低のキャッシュレベルの一方に格納される。証明書チェーンが要求された場合、ＡＵＴＨＯＲＩＴＹメッセージが検査され、証明書チェーンが存在し、かつ有効であるかどうかが判定される。そうである場合に、ＰＡＣは、２つの最低のキャッシュレベルの一方に格納され、そうでない場合に、ＰＡＣは削除される。本発明の実施形態では、ＡＵＴＨＯＲＩＴＹメッセージが以前の通信に対する応答であることを保証するためにトランザクションＩＤを使用することもできる。
【００１６】
本発明の別の実施形態では、悪意のあるノードに接続する確率が減少するようにピアツーピアネットワーク内のノードを見つける方法が提示される。この方法は、ピアツーピアネットワーク内で、ローカルに登録されたＩＤを含めずに発見メッセージを同報通信するステップと、ピアツーピアネットワーク内のノードから応答を受信するステップと、ノードとピアリング関係を確立するステップとを含む。一実施形態では、ノードから応答を受信するステップは、ピアツーピアネットワーク内の少なくとも２つのノードから応答を受信するステップを含む。この状況では、ノードとピアリング関係を確立するステップは、少なくとも２つのノードの一方をランダムに選択するステップと、少なくとも２つのノードのうちランダムに選択された一方とピアリング関係を確立するステップとを含む。
【００１７】
本発明のさらに別の実施形態では、ピアツーピアネットワーク内の同期プロセスに基づくサービス妨害攻撃を抑制する方法が提示される。この方法は、キャッシュ同期を要求する、ピアアドレス証明書（ＰＡＣ）を含むＳＯＬＩＣＩＴメッセージ要求を第１ノードから受信するステップと、ＰＡＣを検査して、ＰＡＣの有効性を判定するステップと、ＰＡＣを検査するステップが、ＰＡＣが有効でないと判定したとき、ＳＯＬＩＣＩＴパケットを除去するステップとを含む。好ましくは、ＰＡＣを検査するステップが、ＰＡＣが有効であると判定したとき、この方法は、ナンス（ｎｏｎｃｅ）を生成するステップと、ナンスを第１ノードの公開鍵で暗号化するステップと、暗号化ナンスを含むＡＤＶＥＲＴＩＳＥメッセージを生成するステップと、ＡＤＶＥＲＴＩＳＥメッセージを第１ノードに送信するステップとをさらに含む。ＲＥＱＵＥＳＴメッセージが第１ノードから受信されたとき、この方法は、ＲＥＱＵＥＳＴメッセージを検査して、第１ノードが暗号化ナンスを暗号化解除することができたかどうかを判定し、第１ノードが暗号化ナンスを暗号化解除することができたとき、ＲＥＱＵＥＳＴメッセージを処理する。
【００１８】
好ましくは、この方法は、第１ノードとの通信を具体的に識別する接続情報を維持するステップと、ＲＥＱＵＥＳＴメッセージを検査し、ＲＥＱＵＥＳＴメッセージが具体的にＡＤＶＥＲＴＩＳＥメッセージと関係することを保証するステップと、ＲＥＱＵＥＳＴメッセージが具体的にＡＤＶＥＲＴＩＳＥメッセージと関係しないとき、ＲＥＱＵＥＳＴメッセージを拒絶するステップとをさらに含む。一実施形態では、第１ノードとの通信を具体的に識別する接続情報を維持するステップは、ナンスおよび第１ノードの識別のハッシュとして第１ビット位置を計算するステップと、ビットベクトル中の第１ビット位置でビットをセットするステップとを含む。これを行ったとき、ＲＥＱＵＥＳＴメッセージを検査するステップは、ＲＥＱＵＥＳＴメッセージからナンスおよび第１ノードの識別を抽出するステップと、ナンスおよび第１ノードの識別のハッシュとして第２ビット位置を計算するステップと、ビットベクトルを検査し、ビットベクトルが第２ビット位置に対応するビットセットを有するかどうかを判定するステップと、ビットベクトルを検査するステップで第２ビット位置に対応するビットセットが見つからないとき、ＲＥＱＵＥＳＴがＡＤＶＥＲＴＩＳＥメッセージに具体的に関係しないことを示すステップとを含む。あるいは、ナンスをビット位置として直接的に使用することもできる。この場合、ＲＥＱＵＥＳＴが受信されたとき、同封のナンスに対応するビット位置がチェックされる。このビット位置がセットされている場合、これは有効なＲＥＱＵＥＳＴであり、ビット位置がクリアされる。そうでない場合、これは無効なＲＥＱＵＥＳＴまたは応答攻撃であり、このＲＥＱＵＥＳＴは廃棄される。
【００１９】
本発明のさらに別の実施形態では、ピアツーピアネットワーク内の同期プロセスに基づくサービス妨害攻撃を抑制する方法は、第１ノードから意図的に要求メッセージを受信するステップと、ＲＥＱＵＥＳＴメッセージが第１ノードとの以前の通信に対する応答であるかどうかを判定するステップと、ＲＥＱＵＥＳＴメッセージが第１ノードとの以前の通信に対する応答でないとき、ＲＥＱＵＥＳＴメッセージを拒絶するステップとを含む。好ましくは、ＲＥＱＵＥＳＴメッセージが以前の通信に対する応答であるかどうかを判定するステップは、ＲＥＱＵＥＳＴメッセージから、第１ノードのナンスおよび識別を意図的に抽出するステップと、ナンスおよび識別のハッシュとしてビット位置を計算するステップと、ビットベクトルを検査し、ビットベクトルがビット位置に対応するビットセットを有するかどうかを判定するステップと、ビット位置に対応するビットセットが存在しないとき、ＲＥＱＵＥＳＴが第１ノードとの以前の通信の応答ではないことを示すステップとを含む。
【００２０】
ピアツーピアネットワーク内のノードリソースの消費に基づくサービス妨害攻撃を抑制する方法も提示される。この方法は、ピアツーピアネットワーク内のノードからメッセージを受信するステップと、現在のリソース使用率を検査するステップと、現在のリソース使用率が所定のレベルを超えているとき、メッセージの処理を拒絶するステップとを含む。ＲＥＳＯＬＶＥメッセージが受信されたとき、メッセージの処理を拒絶するステップは、ＡＵＴＨＯＲＩＴＹメッセージを第１ノードに送信するステップを含む。このＡＵＴＨＯＲＩＴＹメッセージは、現在のリソース使用率が高過ぎるためにＲＥＳＯＬＶＥメッセージが処理されないことの表示を含む。ピアアドレス証明書（ＰＡＣ）を含むＦＬＯＯＤメッセージが受信され、かつＰＡＣを２つの最低のキャッシュレベルの一方に格納すべきであることをこの方法が決定したとき、メッセージの処理を拒絶するステップは、後の処理のために保留リスト内にＰＡＣを配置するステップを含む。２つの最低のキャッシュレベルよりも高いキャッシュレベルにＰＡＣを格納すべきであることをこの方法が決定した場合には、メッセージの処理を拒絶するステップは、ＦＬＯＯＤメッセージを拒絶するステップを含む。
【００２１】
本発明の別の実施形態では、ピアツーピアネットワーク内のノード帯域幅消費に基づくサービス妨害攻撃を抑制する方法が提示される。この方法は、ピアツーピアネットワーク内のノードからキャッシュ同期を求める要求を受信するステップと、過去に実施されたキャッシュ同期の数を示すメトリック（ｍｅｔｒｉｃ）を検査するステップと、過去に実施されたキャッシュ同期の数が所定の最大値を超えているとき、キャッシュ同期を求める要求の処理を拒絶するステップとを含む。別の実施形態では、この方法はメトリックを検査し、所定の先行期間に実施されたキャッシュ同期の数を判定する。この実施形態では、要求の処理を拒絶するステップは、所定の先行期間に実施されたキャッシュ同期の数が所定の最大値を超えているとき、キャッシュ同期を求める要求の処理を拒絶するステップを含む。
【００２２】
本発明の別の実施形態では、ピアツーピアネットワーク内の検索ベースのサービス妨害攻撃を抑制する方法は、既知のピアアドレス証明書のキャッシュエントリを検査し、解決要求を送信する適切なノードを決定するステップと、適切なノードのうち１つをランダムに選択するステップと、ランダムに選択したノードに解決要求を送信するステップとを含む。一実施形態では、適切なノードのうち１つをランダムに選択するステップは、ターゲットＩＤからのＰＮＲＰ ＩＤの距離に基づいて、適切なノードごとに、重み付けした確率を計算するステップを含む。特定の次のホップを選ぶ確率は、そのノードとターゲットノードの間のＩＤ距離に対する反比例として決定される。
【００２３】
本発明の別の実施形態では、ピアツーピアネットワーク内の検索ベースのサービス妨害攻撃を抑制する方法は、ＲＥＳＰＯＮＳＥメッセージを受信するステップと、ＲＥＳＰＯＮＳＥメッセージが以前のＲＥＳＯＬＶＥメッセージに対する応答であるかどうかを判定するステップと、ＲＥＳＰＯＮＳＥメッセージが以前のＲＥＳＯＬＶＥメッセージに対する応答でないとき、ＲＥＱＵＥＳＴメッセージを拒絶するステップとを含む。好ましくは、ＲＥＳＰＯＮＳＥメッセージが以前のＲＥＳＯＬＶＥメッセージに対する応答であるかどうかを判定するステップは、ＲＥＳＰＯＮＳＥメッセージ内の情報のハッシュとしてビット位置を計算するステップと、ビットベクトルを検査し、ビット位置に対応するビットがビットベクトル内にセットされているかどうかを判定するステップとを含む。
【００２４】
一実施形態では、ＲＥＳＰＯＮＳＥメッセージはアドレスリストを含み、この方法は、解決を妨害する試みにおいてＲＥＳＰＯＮＳＥメッセージが変更されているかどうかを判定するステップと、解決を妨害する試みにおいてＲＥＳＰＯＮＳＥメッセージが変更されているとき、ＲＥＳＰＯＮＳＥメッセージを拒絶するステップとをさらに含む。好ましくは、解決を妨害する試みにおいてＲＥＳＰＯＮＳＥメッセージが変更されているかどうかを判定するステップは、ＲＥＳＰＯＮＳＥメッセージ内のアドレスリストのハッシュとしてビット位置を計算するステップと、ビットベクトルを検査し、ビット位置に対応するビットがビットベクトル内にセットされているかどうかを判定するステップとを含む。
【００２５】
本発明の別の実施形態では、悪意のあるノードがピアツーピアネットワークから有効ノードを除去することを抑制する方法は、キャッシュ内に格納されたピアアドレス証明書（ＰＡＣ）を有する有効ノードから、取消し証明書を意図的に受信するステップと、取消し証明書が有効ノードによって署名されていることを検証するステップとを含む。
【００２６】
本明細書に含まれ、本明細書の一部を形成する添付の図面は、本発明のいくつかの態様と、本発明の原理を説明するのに用いるための開示とを示す。
【００２７】
【発明の実施の形態】
ある好ましい実施形態に関連して本発明を説明するが、本発明をその実施形態に限定することを意図するものではない。むしろ、すべての代替方法、修正形態、および均等物が、頭記の特許請求の範囲で定義される本発明の精神および範囲内に含まれるものとする。
【００２８】
図面を参照すると、同様の参照符号は同様の要素を指しており、本発明が、適切なコンピューティング環境に実装されているものとして示されている。必須ではないが、パーソナルコンピュータによって実行中の、プログラムモジュールなどのコンピュータ実行可能命令の一般的文脈で本発明を説明する。一般に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ種類を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。さらに、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサベースの消費者向け電子機器またはプログラマブル消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含む他のコンピュータシステム構成を用いて本発明を実施できることを当業者は理解されよう。本発明はまた、通信ネットワークを介してリンクされるリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、ローカルメモリ記憶装置とリモートメモリ記憶装置のどちらにも位置することができる。
【００２９】
図１に、本発明を実装することができる適切なコンピューティング環境１００の例を示す。例示的コンピューティング環境１００は、適切なコンピューティング環境の一例に過ぎず、本発明の使用および機能の範囲に関して何らかの制限を示唆するものではない。例示的動作環境１００に図示する構成要素のうちのいずれか１つ、あるいはそれらの組合せに関係する何らかの依存関係または要件をコンピューティング環境１００が有するものと解釈すべきでもない。
【００３０】
本発明は、他の多数の汎用コンピューティングシステム環境または構成、あるいは他の多数の特殊目的コンピューティングシステム環境または構成で動作可能である。本発明と共に使用するのに適した周知のコンピューティングシステム、環境、および／または構成の例には、限定はしないが、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルド装置またはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラマブル消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、ならびに上記のシステムまたは装置のいずれかを含む分散コンピューティング環境などが含まれる。
【００３１】
本発明は、コンピュータによって実行中の、プログラムモジュールなどのコンピュータ実行可能命令の一般的文脈で説明することができる。一般に、プログラムモジュールは、特定のタスクを実施し、または特定の抽象データ種類を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。本発明はまた、通信ネットワークを介してリンクされるリモート処理装置によってタスクが実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶装置を含む、ローカルコンピュータ記憶媒体とリモートコンピュータ記憶媒体のどちらにも位置することができる。
【００３２】
図１を参照すると、本発明を実装するための例示的システムは、コンピュータ１１０の形式の汎用コンピューティング装置を含む。コンピュータ１１０の構成要素は、限定はしないが、処理装置１２０と、システムメモリ１３０と、システムメモリを含む様々なシステム構成要素を処理装置１２０に結合するシステムバス１２１とを含むことができる。システムバス１２１は、様々なバスアーキテクチャのうちのいずれかを用いる、メモリバスまたはメモリコントローラと、周辺バスと、ローカルバスとを含むいくつかの種類のバス構造のうちのいずれでもよい。例えば、限定はしないが、このようなアーキテクチャには、ＩＳＡ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＭＣＡ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、ＥＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ＶＥＳＡ（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカルバス、およびメザニンバスとも呼ばれるＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスが含まれる。
【００３３】
コンピュータ１１０は、一般に様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータ１１０がアクセス可能である入手可能などんな媒体でもよく、それには揮発性媒体と不揮発性媒体の両方、取外し可能媒体と取外し不能媒体の両方が含まれる。例えば、限定はしないが、コンピュータ可読媒体はコンピュータ記憶媒体および通信媒体を含むことができる。コンピュータ記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を格納するための何らかの方法または技術で実装される、揮発性媒体と不揮発性媒体、取外し可能媒体と取外し不能媒体のどちらも含む。コンピュータ記憶媒体には、限定はしないが、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、または他のメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、または他の光記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶装置、あるいは、所望の情報を格納するのに使用することができ、コンピュータ１１０でアクセスすることができる他のどんな媒体も含まれる。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを、搬送波または他の移送機構などの被変調データ信号で実施し、その通信媒体にはどんな情報送達媒体も含まれる。「被変調データ信号」という用語は、その特徴のうちの１または複数を有する信号、または情報を符号化するように変化する信号を意味する。例えば、限定はしないが、通信媒体には、ワイヤードネットワークまたはダイレクトワイヤード接続などのワイヤード媒体、ならびに音響媒体、ＲＦ媒体、赤外線媒体、および他のワイヤレス媒体などのワイヤレス媒体が含まれる。上記のいずれかの組合せも、コンピュータ可読媒体の範囲内に含まれるべきである。
【００３４】
システムメモリ１３０は、読取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの揮発性メモリおよび／または不揮発性メモリの形態のコンピュータ記憶媒体を含む。始動中などにコンピュータ１１０内の要素間で情報を転送する助けになる基本ルーチンを含む基本入出力システム（ＢＩＯＳ）１３３が、一般にＲＯＭ１３１内に記憶される。ＲＡＭ１３２は、一般に、処理装置１２０に即座にアクセス可能であり、かつ／または処理装置１２０が現在操作しているデータおよび／またはプログラムモジュールを含む。例えば、限定はしないが、図１に、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。
【００３５】
コンピュータ１１０は、他の取外し可能／取外し不能な、揮発性／不揮発性コンピュータ記憶媒体も含むことができる。単なる一例であるが、図１に、取外し不能不揮発性磁気媒体を読み書きするハードディスクドライブ１４１と、取外し可能不揮発性磁気ディスク１５２を読み書きする磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭまたは他の光媒体などの取外し可能不揮発性光ディスク１５６を読み書きする光ディスクドライブ１５５とを示す。例示的動作環境で使用することのできる他の取外し可能／取外し不能な揮発性／不揮発性コンピュータ記憶媒体には、限定はしないが、磁気テープカセット、フラッシュメモリカード、デジタルバーサタイルディスク、デジタルビデオテープ、固体ＲＡＭ、および固体ＲＯＭが含まれる。ハードディスクドライブ１４１は一般に、インタフェース１４０などの取外し不能メモリインタフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、インタフェース１５０などの取外し可能メモリインタフェースによってシステムバス１２１に接続される。
【００３６】
上述した、図１に図示するドライブとその関連するコンピュータ記憶媒体は、コンピュータ１１０に対してコンピュータ可読命令データ構造、データ構造、プログラムモジュール、および他のデータの記憶を実現する。例えば図１では、ハードディスクドライブ１４１がオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして図示している。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じにすることも、異なるものにすることもできることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくともこれらが相異なるコピーであることを示すために異なる符号を付けてある。ユーザは、キーボード１６２や、マウス、トラックボール、またはタッチパッドと一般に呼ばれるポインティングデバイス１６１などの入力装置を介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどを含めることができる。これらの入力装置や他の入力装置はしばしば、システムバスに結合されるユーザ入力インタフェース１６０を介して処理装置１２０に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの他のインタフェースおよびバス構造によって接続することもできる。モニタ１９１または他の種類のディスプレイ装置もまた、ビデオインタフェース１９０などのインタフェースを介してシステムバス１２１に接続される。モニタに加えて、コンピュータはまた、スピーカ１９７およびプリンタ１９６などの他の周辺出力装置も含むことができ、その周辺出力装置は、出力周辺インタフェース１９５を介して接続することができる。
【００３７】
コンピュータ１１０は、リモートコンピュータ１８０などの１または複数のリモートコンピュータへの論理接続を使用して、ネットワーク環境で動作することができる。リモートコンピュータ１８０は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の共通ネットワークノードでよく、一般にコンピュータ１１０に関して上記で述べた要素のうちの多くまたはすべてを含むが、図１にはメモリ記憶装置１８１だけを示してある。図１に示す論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１および広域ネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含めることができる。このようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネット、およびインターネットで一般的なものである。
【００３８】
ＬＡＮネットワーキング環境で使用する際、パーソナルコンピュータ１１０は、ネットワークインタフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境で使用する際、コンピュータ１１０は一般に、インターネットなどのＷＡＮ１７３を介して通信を確立するためのモデム１７２または他の手段を含む。モデム１７２は内蔵でも外付けでもよく、ユーザ入力インタフェース１６０、または他の適切な機構を介してシステムバス１２１に接続することができる。ネットワーク環境では、コンピュータ１００に関して示したプログラムモジュールまたはその一部を、リモートメモリ記憶装置内に格納することができる。例えば、限定はしないが、図１に、リモートアプリケーションプログラム１８５をメモリ装置１８１上に常駐するものとして示す。図示するネットワーク接続は例示的なものであって、コンピュータ間の通信リンクを確立する他の手段も使用できることを理解されたい。
【００３９】
以下の説明では、別段の表示がない限り、１または複数のコンピュータによって実行される動作と、オペレーションの象徴的表現とを参照しながら本発明を説明する。したがって、このような動作およびオペレーションは、コンピュータで実行される動作およびオペレーションと呼ばれることもあり、構造化形式のデータを表す電気信号の、コンピュータの処理装置による操作を含むことを理解されよう。この操作は、データを変換し、またはデータをコンピュータのメモリシステム内の位置に維持し、このデータは、当業者の理解する方式でコンピュータのオペレーションを再構成し、あるいは変更する。データを維持するデータ構造は、データのフォーマットによって定義される特定の特性を有するメモリの物理位置である。しかし、上記の状況で本発明を説明するものの、当業者は理解するであろうが、以下で説明する様々な動作およびオペレーションをハードウェアでも実装できることを制限することを意味するわけではない。
【００４０】
上述したように、ピアツーピア（Ｐ２Ｐ）プロトコルの成功は、選択されたエンティティ間の有効な接続を確立するプロトコルの能力に依存する。特定のユーザは、異なるアドレスを有する様々な位置で、様々な方式でネットワークに接続することができるので、好ましい手法は、ユーザに対して固有の識別を割り当て、次にプロトコルを介してその識別を特定のアドレスに変換することである。Ｐｅｅｒ−Ｔｏ−Ｐｅｅｒ Ｎａｍｅ Ｒｅｓｏｌｕｔｉｏｎ Ｐｒｏｔｏｃｏｌ （ＰＮＲＰ） Ａｎｄ Ｍｕｌｔｉｌｅｖｅｌ Ｃａｃｈｅ Ｆｏｒ Ｕｓｅ Ｔｈｅｒｅｗｉｔｈという名称の２００１年８月２９日出願の同時係属出願第０９／９４２１６４号には、本発明のセキュリティ・インフラストラクチャの特定の適用範囲が見出されるＰＮＲＰが記載されている。この同時係属出願の教示および開示全体を参照により組み込む。しかし、本発明のセキュリティ・インフラストラクチャおよび方法が、この同時係属出願の特定のピアツーピアプロトコルに限定されず、他のプロトコルにも等しい効力で適用できることを、以下の教示から当業者は理解されよう。
【００４１】
上記で組み込んだ同時係属出願で論じられているように、ＰＮＲＰは、ピアベースの名前−アドレス解決プロトコルである。名前は、ＰＮＲＰ ＩＤと呼ばれる２５６ビットの数である。アドレスは、ＩＰｖ４アドレスまたはＩＰｖ６アドレス、ポート、ならびにプロトコル番号からなる。ＰＮＲＰ ＩＤがアドレスに変換されるとき、ピアアドレス証明書（ＰＡＣ）が返される。この証明書は、ターゲットのＰＮＲＰ ＩＤ、現ＩＰアドレス、公開鍵、およびその他の多くのフィールドを含む。ＰＮＲＰプロトコルのインスタンスは、ノードと呼ばれる。ノードは、ローカルに登録された１または複数のＰＮＲＰ ＩＤを有することができる。ノードは、登録を介してＰＮＲＰで見つけることができるＩＤ−アドレスマッピングを作成する。各登録は、ローカルに構築されたピア証明書を含み、ＰＮＲＰキャッシュの適切なビューを必要とする。ＰＮＲＰノードではないホストは、ＰＮＲＰ ＤＮＳゲートウェイを介してＰＮＲＰ ＩＤをＩＰアドレスに変換することができる。ＰＮＲＰ ＤＮＳゲートウェイは、ＤＮＳ「Ａ」および「ＡＡＡＡ」照会を受諾し、指定のホスト名のサブセットを求めるＰＮＲＰ検索を実行し、結果をＤＮＳ照会回答として返す。
【００４２】
上述したように、ＰＮＲＰは、Ｐ２ＰおよびＰＮＲＰ ＩＤをピアアドレス証明書（ＰＡＣ）と関連付けるピアベースの機構を提供する。Ｐ２Ｐ ＩＤは、永続的な１２８ビット識別子である。Ｐ２Ｐ ＩＤは、正しくフォーマットされたＰ２Ｐ名をハッシングすることによって作成される。Ｐ２Ｐ ＩＤには、セキュアとインセキュアの２つの種類がある。セキュアＰ２Ｐ ＩＤは、公開鍵と検証可能な関係を有するＩＤである。インセキュアＰ２Ｐ ＩＤは、セキュアでない任意のＩＤである。所与のＰ２Ｐ ＩＤは、多くの異なるノードによって発行することができる。ＰＮＲＰは、発行される各インスタンスが固有のＰＮＲＰ ＩＤを有することを保証するために、「サービス位置」サフィックスを使用する。「サービス位置」は、固有ネットワークサービスエンドポイントに対応する１２８ビットの数である。サービス位置は、いくつかの認識可能な要素を有するが、ＰＮＲＰクライアントからは不透明とみなされるべきである。サービス位置は、２つの重要な特性を有する。どの時点でも、クラウド内の１つのソケットだけが所与のサービス位置に対応する。２つのサービス位置を比較したとき、各サービス位置についての共通プレフィックスの長さは、ネットワークの近さの妥当な指標である。同一の４ビットで始まる２つのサービス位置は、同一の３ビットで始まる２つのサービス位置よりも遠くに離れていない。
【００４３】
Ｐ２Ｐ ＩＤは、サービス位置との連鎖によって一意的に識別される。得られる２５６ビット（３２バイト）識別子は、ＰＮＲＰ ＩＤと呼ばれる。ＰＮＲＰノードは、Ｐ２Ｐ名、権限、およびその他のいくつかのパラメータを用いてＰＮＲＰサービスを起動することによってＰＮＲＰ ＩＤを登録する。ＰＮＲＰサービスは、提供されたデータを含むピアアドレス証明書（ＰＡＣ）を作成し、維持する。ＰＡＣは少なくとも、ＰＮＲＰ ＩＤ、証明書有効期間、サービスアドレスおよびＰＮＲＰアドレス、公開鍵、ならびに選択ＰＡＣ内容を介して生成された暗号署名を含む。
【００４４】
ＰＮＲＰ ＩＤの作成および登録は、ＰＮＲＰサービスの一部に過ぎない。ＰＮＲＰサービス実行は、４つの段階に分割することができる。第１段階は、ＰＮＲＰクラウドディスカバリである。この段階の間に、新しいノードは、加わりたいと望むクラウド内の既存のノードを見つけなければならない。クラウドは、グローバルＰＮＲＰクラウド、サイトローカル（企業）クラウド、リンクローカルクラウドとすることができる。見つかった後、ＰＮＲＰクラウドに加わるについての第２段階に入る。新しいノードが既存のノードを見つけた後、新しいノードはＳＹＮＣＨＲＯＮＩＺＥ手順を実施し、既存のノードトップキャッシュレベルのコピーを得る。単一のキャッシュレベルにより、新しいノードがクラウドに参加することを開始するための十分の基礎が与えられる。ＳＹＮＣＨＲＯＮＩＺＡＴＩＯＮを達成した後、次の段階であるクラウドへのアクティブな参加を開始することができる。初期化を完了した後、ノードは、ＰＮＲＰ ＩＤ登録およびＰＮＲＰ ＩＤ解決に参加することができる。この段階の間、ピアは定期的なキャッシュの保守を実施する。ノードが終了したとき、ノードは第４段階に入り、クラウドを離れる。ノードは、ローカルに登録した任意のＰＮＲＰ ＩＤを登録解除し、次いで終了する。
【００４５】
ＰＮＲＰプロトコルは、９個の異なる種類のパケットからなる。その一部は上述した。しかし、本願では、パケットの名前は、単にパケットの機能を理解しやすくするために使用しているのであって、パケットの名前を、パケットの形式またはフォーマット、あるいはメッセージ自体を制限するものとみなすべきでないことに留意されたい。ＲＥＳＯＬＶＥパケットは、ターゲットＰＮＲＰ ＩＤをＰＡＣに変換することを要求する。ＲＥＳＯＰＮＳＥパケットは、完了したＲＥＳＯＬＶＥ要求の結果である。ＦＬＯＯＤパケットは、受信側のＰＮＲＰキャッシュのためのＰＡＣを含む。ＳＯＬＩＣＩＴパケットは、ＰＮＲＰノードのトップレベルキャッシュをＡＤＶＥＲＴＩＳＥするようＰＮＲＰノードに依頼するために使用される。要求されるＡＤＶＥＲＴＩＳＥパケットは、ノードのトップレベルキャッシュ内のＰＡＣに関するＰＮＲＰ ＩＤのリストを含む。ＲＥＱＵＥＳＴパケットは、ＡＤＶＥＲＴＩＳＥされたＰＡＣのサブセットをフラッディングするようにノードに依頼するために使用される。ＩＮＱＵＩＲＥパケットは、特定のＰＮＲＰ ＩＤがそのノードに登録されたかどうかをインセキュアにノードに問い合わせるのに使用される。ＰＮＲＰ ＩＤのローカル登録を確認するために、ＡＵＴＨＯＲＩＴＹパケットが使用される。このパケットは、任意選択で、そのＩＤに関するＰＡＣを検証する助けとなるように証明書チェーンを提供する。ＡＣＫパケットは、あるメッセージの受信、および／または処理の成功を確認する。最後に、ＲＥＰＡＩＲパケットは、分割されている可能性のあるクラウドをマージするよう試みるために使用される。
【００４６】
ノードが完全に開始された後、ノードは、５つの種類のアクティビティを実施することによってＰＮＲＰクラウドに参加することができる。第１に、ノードは、ＰＮＲＰ ＩＤを登録および登録解除することができる。ＰＮＲＰ ＩＤを登録するとき、ＰＮＲＰサービスは、ＰＮＲＰ ＩＤ、サービスアドレスポートおよびプロトコル、ＰＮＲＰアドレスポートおよびプロトコル、ならびに公開鍵を関連付けるピアアドレス証明書（ＰＡＣ）を作成する。このＰＡＣは、ローカルキャッシュに入り、ＲＥＳＯＬＶＥを、新しいＰＡＣをソースとして使用し、かつ［ＰＮＲＰ ＩＤ＋１］をターゲットとして使用して開始する。このＲＥＳＯＬＶＥは、登録されるＩＤと非常に類似したＰＮＲＰ ＩＤを有するいくつかのノードによって処理される。ＲＥＳＯＬＶＥの各受信側は、新しいノードのＰＡＣをそれぞれのキャッシュに追加し、それによってクラウド内で新しいＰＮＲＰＩＤを公示する。ＰＮＲＰ ＩＤを登録解除するとき、更新後のＰＡＣは、「取消し」フラグセットを用いて作成される。更新後のＰＡＣは、ローカルキャッシュの最低レベルにおけるすべてのエントリにフラッディングされる。ＦＬＯＯＤの各受信側は、ＰＡＣのバージョンが古いかについて、それぞれのキャッシュをチェックする。そのようなキャッシュが見つかった場合、受信側は、受信側のキャッシュからＰＡＣを除去する。ＰＡＣが最低のキャッシュレベルから除去される場合、受信側は、受信側の最低のキャッシュレベルにおけるその他のすべてのＰＡＣによって提示されるＰＮＲＰノードに対して取消しをＦＬＯＯＤする。
【００４７】
ＰＮＲＰノードは、ＰＮＲＰ ＩＤ解決に参加することもできる。上記で組み込んだ出願に論じられているように、ＰＮＲＰ ＩＤは、ターゲットＰＮＲＰ ＩＤに近づくように、次々にＲＥＳＯＬＶＥメッセージを経路指定することによってＰＡＣに変換される。ノードがＲＥＳＯＬＶＥを受信したとき、ノードは、ＲＥＳＯＬＶＥを拒否して以前のホップに戻し、以前のホップにＲＥＳＰＯＮＳＥで応答し、またはＰＮＲＰ ＩＤがノード自体よりもターゲットＩＤに近いノードにＲＥＳＯＬＶＥを転送することができる。ノードは、ＲＥＳＰＯＮＳＥパケットを解決の一部として受信し、転送する。ＰＮＲＰノードは、ローカルクライアントの代わりにＲＥＳＯＬＶＥＳを開始することができる。ＰＮＲＰサービスは、非同期の解決要求が可能となるようにＡＰＩを提供する。ローカルノードは、ＲＥＳＯＬＶＥパケットを生成し、対応するＲＥＳＰＯＮＳＥを最終的に受信する。
【００４８】
ＰＮＲＰノードは、キャッシュ同期要求を受ける。ＳＯＬＩＣＩＴパケットを受信する際、ノードは、ＰＮＲＰ ＩＤを最高キャッシュレベル中にリストするＡＤＶＥＲＴＩＳＥパケットで応答する。次に、ソリシターノード（ｓｏｌｉｃｉｔｏｒ ｎｏｄｅ）は、ＡＤＶＥＲＴＩＳＥされた望みのＰＡＣに関するＰＮＲＰ ＩＤをリストする要求を送信する。ＲＥＱＵＥＳＴされた各キャッシュエントリは、ＲＥＱＵＥＳＴ側にＦＬＯＯＤされる。最後に、以下により十分に論じるように、ＰＮＲＰは、識別の検証も実施する。識別の検証は、ＰＡＣを検証するのに使用する脅威を軽減する装置である。識別の検証は、基本的に２つの目的を有する。第１に、識別の検証は、ＰＡＣで指定されるＰＮＲＰノードが、ローカルに登録されたそのＰＡＣからのＰＮＲＰ ＩＤを有することを保証する。第２に、セキュアＰＮＲＰ ＩＤの場合（以下で論じる）、識別の検証は、ＰＮＲＰ ＩＤにおける権限に対して暗号的に実証可能な関係を有する鍵を使用して、ＰＡＣが署名されたことを保証する。
【００４９】
ここまで、本発明のセキュリティ・インフラストラクチャの実施形態と特定の関連性が見出されるＰＮＲＰシステムの実際に役立つ知識を与えたので、ここで、本発明のセキュリティ・インフラストラクチャによって提供されるセキュリティ機構に注意を向ける。これらの機構は、上述したようなＰ２Ｐクラウドにおいて悪意のあるノードによってもたらされる可能性のある様々な攻撃の効果をなくし、または少なくとも緩和するために、本発明のシステムによって提供される。ＰＮＲＰプロトコルは、これらの攻撃を防止する機構を有さず、これら脅威のすべてに対処する単一の解決策があるわけでもない。しかし、本発明のセキュリティ・インフラストラクチャは、悪意のあるノードによって引き起こされる可能性のある破壊を最小にし、かつ、ＰＮＲＰプロトコロルに組み込むことができる。
【００５０】
成功している多くのＰ２Ｐプロトコルの場合と同じく、容易に見つけることができるようにエンティティを発行することができる。しかし、Ｐ２Ｐプロトコルに対してセキュリティおよび保全性を実現するために、各識別は、添付の識別証明書を含むことが好ましい。しかし、堅固なセキュリティアーキテクチャは、セキュアエンティティとインセキュアエンティティのどちらも扱うことができる。本発明の実施形態によれば、この堅固性は、自己検証型ＰＡＣを使用することによって実現される。
【００５１】
セキュアＰＡＣは、ＩＤと公開鍵との間のマッピングを提供することによって自己検証型にされる。これにより、セキュアＰＡＣに署名するための秘密鍵を有することなく誰かがそのＰＡＣを発行することが防止され、したがって、多くの識別の盗用攻撃が防止される。ＩＤ秘密鍵の保持者は、証明書を使用して、ＩＰアドレス、フレンドリネームなどの追加の情報をＩＤに添付する。好ましくは、各ノードは、ノード自体の秘密鍵−公開鍵対を生成し、信頼されるサプライヤが提供することもできる。公開鍵は、ノード識別子の一部として含められる。その１対の鍵を作成したノードだけが、ノード識別の作成者であることを証明することができる秘密鍵を有する。このようにして、識別の盗用を見つけることができ、したがってそれを防止することができる。
【００５２】
このような証明書に関する汎用フォーマットは、［Ｖｅｒｓｉｏｎ， ＩＤ， ＜ＩＤ Ｒｅｌａｔｅｄ Ｉｎｆｏ＞， Ｖａｌｉｄｉｔｙ， Ａｌｇｏｒｉｔｈｍｓ， ＰＩｓｓｕｅｒ］ＫＩｓｓｕｅｒと表すことができる。実際、セキュアＩＤであるか、それともインセキュアＩＤであるかに関わらず、Ｐ２Ｐ名／ＵＲＬは、基本的な証明書フォーマットの一部である。この証明書の表現で使用しているように、Ｖｅｒｓｉｏｎは、証明書のバージョンであり、ＩＤは、発行すべき識別子であり、＜ＩＤ Ｒｅｌａｔｅｄ Ｉｎｆｏ＞は、ＩＤと関連付けるべき情報を表し、Ｖａｌｉｄｉｔｙは、世界日時（別名ＧＭＴ）として表される１対のＦｒｏｍ−Ｔｏ ｄａｔｅで表される有効期間を表し、Ａｌｇｏｒｉｔｈｍｓは、鍵の対を生成し、署名するのに使用するアルゴリズムを指し、ＰＩｓｓｕｅｒは、証明書発行者の公開鍵である。証明書発行者がＩＤ所有者と同じである場合、これは、ＩＤ所有者の公開鍵ＰＩＤである。項ＫＩｓｓｕｅｒは、ＰＩｓｓｕｅｒに対応する秘密鍵である。証明書発行者がＩＤ所有者である場合、これは、ＩＤ所有者の秘密鍵ＫＩＤである。
【００５３】
好ましい実施形態では、＜ＩＤ ｒｅｌａｔｅｄ ｉｎｆｏ＞は、このＩＤを見つけることができるアドレスタプルと、発行者のＰＮＲＰサービスに関するアドレスタプルを含む。この実施形態では、アドレス証明書は、［Ｖｅｒｓｉｏｎ， ＩＤ， ＜Ａｄｄｒｅｓｓ＞ＩＤ， ＜Ａｄｄｒｅｓｓ＞ＰＮＲＰ， Ｖａｌｉｄｉｔｙ， Ｒｅｖｏｋｅ Ｆｌａｇ， Ａｌｇｏｒｉｔｈｍｓ， ＰＩｓｓｕｅｒ］ＫＩｓｓｕｅｒとなる。この拡張された表現では、ＩＤは発行すべき識別子であり、Ｇｒｏｕｐ ＩＤまたはＰｅｅｒ ＩＤでよい。＜Ａｄｄｒｅｓｓ＞は、ＩＰｖ６アドレス、ポート、およびプロトコルのタプルである。＜Ａｄｄｒｅｓｓ＞ＩＤは、ＩＤに関連付けるべきアドレスタプルである。＜Ａｄｄｒｅｓｓ＞ＰＮＲＰは、発行者のマシンにおけるＰＮＲＰサービス（または他のＰ２Ｐサービス）のアドレスタプルである。これは、発行者のＰＮＲＰアドレスのアドレスであることが好ましい。これは、証明書の有効性を検証するために、他のＰＮＲＰノードによって使用される。Ｖａｌｉｄｉｔｙは、１対のＦｒｏｍ−Ｔｏ ｄａｔｅで表される有効期間を表す。取消しフラグは、セットされたとき取消し証明書をマークする。ＰＩｓｓｕｅｒは、証明書発行者の公開鍵であり、ＫＩｓｓｕｅｒは、ＰＩｓｓｕｅｒに対応する秘密鍵である。証明書発行者がＩＤ所有者である場合、これは、ＩＤの秘密鍵ＫＩＤである。
【００５４】
本発明の好ましい実施形態では、証明書が有効であるためには以下の条件を満たさなければならない。証明書署名が有効でなければならず、証明書は満了することができない。すなわち、ＵＤＴとして表される現在の日付は、Ｖａｌｉｄｉｔｙフィールドで指定される範囲内になければならない。公開鍵のハッシュもまた、ＩＤと一致しなければならない。発行者がＩＤ所有者と同じである場合、発行者の公開鍵の、ＩＤへのハッシングを検証しなければならない。ＰＩｓｓｕｅｒがＰＩＤと異なる場合、ＫＩＤで署名された証明書に導く証明書のチェーンが存在しなければならない。このようなチェーンにより、発行者とＩＤ所有者との間の関係が検証される。加えて、証明取消しリスト（ＣＲＬ）が、ＩＤのそのクラスに関して発行され、ＣＲＬがアクセス可能である場合、オーセンティケータは、チェーン中の証明書がＣＲＬ内に出現しないことを検証することができる。
【００５５】
本発明のセキュリティ・インフラストラクチャはまた、インセキュアＰＡＣも扱う。本発明によれば、インセキュアＰＡＣは、ＩＤの導出元のユニフォームリソース識別子（ＵＲＩ）を含めることによって自己検証型となる。実際、セキュアＩＤとインセキュアＩＤはどちらも、ＰＡＣ内にＵＲＩを含む。ＵＲＩは、「ｐ２ｐ：／／ＵＲＩ」というフォーマットである。これにより、悪意のあるノードが、インセキュアＰＡＣで別のノードのセキュアＩＤを発行することが防止される。
【００５６】
本発明のセキュリティ・インフラストラクチャは、インセキュアＩＤの使用も可能にする。このようなインセキュアＩＤに伴う問題は、偽造が非常に容易であることである。悪意のあるノードは、他の任意のノードのインセキュアＩＤを発行することができる。インセキュアＩＤは、良好なノードの発見を困難にすることが可能となるセキュリティホールも開く。しかし、本発明に従ってＵＲＩを含めることにより、インセキュアＩＤは、決してセキュアＩＤに影響を及ぼすことがない。さらに、本発明のインフラストラクチャにより、インセキュアＩＤを含むＰＡＣが、セキュアＰＡＣと同じフォーマットとなることが必要となる。すなわち、これらは公開鍵と秘密鍵を含む。セキュアＰＡＣに対する構造と同じ構造をインセキュアＰＡＣに対して実施することにより、ＰＡＣを生成するためのバー（ｂａｒ）は低下しない。さらに、ＰＡＣ内にＵＲＩを含めることにより、特定のセキュアＩＤにマッピングするＵＲＩを生成することは、計算上実現不可能となる。
【００５７】
ここで生じる１つの問題は、Ｐ２Ｐクラウドセキュリティの向上とオーバヘッドの増加との兼ね合いを認識した上で、ＰＡＣをいつ検証するかということである。しかし、上述した様々なパケットに含まれるＰＡＣは、ある時点で検証しなければならない。このＰＡＣ検証は、ＩＤの署名が有効かどうかをチェックすること、およびＩＤがセキュアＩＤについての公開鍵に対応するかどうかをチェックすることを含む。オーバヘッドとセキュリティの問題の平衡をとるため、本発明の一実施形態では、そのパケットのどんな処理を行うよりも前にＰＡＣを検証する。これにより、無効データは決して処理されないことが保証される。しかし、ＰＡＣ検証がパケットの処理を低下させる可能性があり、そのことは、あるクラスのパケット、例えばＲＥＳＯＬＶＥパケットには適さないことを認識して、本発明の代替実施形態ではこのパケット中のＰＡＣを検証しない。
【００５８】
ＰＡＣの検証に加えて、本発明のセキュリティ・インフラストラクチャはまた、ＩＤ所有権のチェックを実施してＰＡＣを検証する。上述したように、個人情報の盗用は、ＰＮＲＰまたは他のＰ２Ｐプロトコルでアドレスを使用する前に、そのアドレス証明書の単純な検証によって見つけることができる。この検証は、ＩＤが、証明書に含まれる公開鍵のハッシュであることを単に検証することを伴うことがある。所有権の検証は、そのＰＡＣ中のアドレスにＩＮＱＵＩＲＥパケットを発行することも伴う。ＩＮＱＵＩＲＥパケットは、検証すべきＩＤと、トランザクションＩＤを含む。ＩＤがそのアドレスに存在する場合、ノードはそのＩＮＱＵＩＲＥを確認すべきである。ＩＤがそのアドレスに存在しない場合、ノードはそのＩＮＱＵＩＲＥを確認すべきではない。識別を検証するのに証明書チェーンが必要である場合、ノードは、完全な証明書チェーンを返す。供給される証明書チェーンにおける承認のチェーンを検証するのと同様に、署名およびＩＤ−＞ＵＲＬの検証は、依然として複雑であり、本発明のシステムは、ＰＡＣの検証に追加の複雑さを加えることになるあらゆるチャレンジ／応答プロトコルを回避する。さらに、トランザクションＩＤを含めることにより、悪意のあるノードがＩＮＱＵＩＲＥＳに対する応答を事前生成することを防止する。加えて、この機構は、ＰＡＣが完全な証明書チェーンを搬送するという要件が不要となる。
【００５９】
標準ＲＥＳＯＬＶＥパケットを変更することにより、本発明のシステムにおいて、ＩＤ所有権チェックを容易にし、標準ＲＥＳＯＬＶＥパケットがＩＤ所有権チェックも実施することができるようにする。変更されたＲＥＳＯＬＶＥパケットは、ＲＥＳＯＬＶＥの転送先アドレスのＩＤを含む。ＩＤがそのアドレスにある場合はＡＣＫを送信し、そうでない場合はＮＡＣＫを送信する。ＩＤがＲＥＳＯＬＶＥを処理しない場合、またはＮＡＣＫが受信される場合、ＩＤはキャッシュから除去される。このようにして、ある種のチャレンジ／応答プロトコルに頼ることなしに、特別などんなＩＮＱＵＩＲＥパケットも送信することなく、本質的には、ＩＮＱＵＩＲＥメッセージをＲＥＳＯＬＶＥに便乗させることによってＰＡＣを検証する。この便乗プロセスを、図２に参照して以下で再度論じる。この手順により、無効なＰＡＣ、または古いＰＡＣを見つけることが容易になる。
【００６０】
この識別検証チェックは、２つの相異なる時刻に行われる。最初は、ノードが、ノードの最低の２つのキャッシュレベルの一方にＰＡＣを加えようとしているときである。最低の２つのキャッシュレベルにおけるＰＡＣ有効性は、ＰＮＲＰＩＤを変換するＰＮＲＰの能力にとって重要である。これらの２つのレベルの一方にＰＡＣを加える前に、識別検証を実施することにより、いくつかの攻撃が軽減される。ＰＡＣをより高位のレベルのキャッシュに加えるべき場合、これらの高位レベルでは入替りがあるために、ＩＤ所有権は実施されない。キャッシュの高位レベルのすべてのＰＡＣエントリのほぼ８５％は、それが使用される前に置換され、または有効期限が切れることが確認されている。したがって、これらの高位レベルに無効ＰＡＣを有することによる何らかの効果を確認する確率は、無効ＰＡＣが入ったときにＩＤ検証を実施することが正当化されないほどに十分低い。
【００６１】
エントリが最低の２つのキャッシュレベルの一方に属すると判定されるとき、ＰＡＣは、その識別を検証することができるまで、保留リスト内に配置される。この第１種の識別検証は、ＩＮＱＵＩＲＥメッセージを使用する。このような識別検証は、ＰＡＣがその発信側ノードで依然として有効である（登録されている）ことを確認し、発信側ノードの検証権限がそのＰＡＣを発行する助けになる情報を要求する。ＩＮＱＵＩＲＥメッセージ中の１つのフラグは、ＡＵＴＨＯＲＩＴＹ応答内の証明書チェーン（それが存在する場合）を送信するように受信側に要求する「フラグ」フィールド、すなわちＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮに対して定義される。ＩＮＱＵＩＲＥの受信側がＰＡＣを発行する権限を有さない場合、またはＰＡＣがもはやローカルに登録されていない場合、受信側は単にＩＮＱＵＩＲＥメッセージを除去する。ローカルノードがＡＵＴＨＯＲＩＴＹメッセージを介して適切な応答を受信しないので、不良なＰＡＣは、そのキャッシュ内に決して入らず、したがって、Ｐ２Ｐクラウドにおけるオペレーションに対して悪意のある効果を有さないようにすることができる。
【００６２】
ＩＮＱＵＩＲＥの受信側がＰＡＣを発行する権限を有し、および依然としてローカルに登録されている場合、そのノードは、図２に示すように、ＡＵＴＨＯＲＩＴＹメッセージでＩＮＱＵＩＲＥメッセージに応答する（２００）。図２には示していないが、本発明の実施形態での受信側ノードは、ＡＵＴＨＯＲＩＴＹを送信したノードでＩＤが依然として登録されているとＡＵＴＨＯＲＩＴＹメッセージが示すか否かを確認するためにチェックする。ローカルノードが、このＡＵＴＨＯＲＩＴＹメッセージがＩＮＱＵＩＲＥに対する応答であると判定した後（２０２）、ローカルノードは、保留リストからＰＡＣを除去する（２０４）。証明書チェーンが要求された場合（２０６）、証明書チェーンが存在し、有効であるかどうかを確認するためにＡＵＴＨＯＲＩＴＹメッセージをチェックする（２０８）。証明書チェーンが存在し、有効である場合、ＰＡＣがキャッシュに追加され、有効なものとしてマークされる（２１０）。そうでない場合、ＰＡＣは削除される（２１２）。証明書チェーンが要求されなかった場合（２０６）、単にＰＡＣがキャッシュに追加され、有効なものとしてマークされる（２１０）。
【００６３】
今や明らかであろうが、このＡＵＴＨＯＲＩＴＹメッセージは、ＰＮＲＰ ＩＤが依然としてローカルノードに登録されていることを確認または否定するのに使用され、任意選択で、このＡＵＴＨＯＲＩＴＹメッセージは、ＡＵＴＨＯＲＩＴＹ受信側がノードの権利を検証してターゲットＩＤに対応するＰＡＣを発行することを可能にする証明書チェーンを提供する。ＩＮＱＵＩＲＥメッセージに加えて、ＡＵＴＨＯＲＩＴＹメッセージは、以下に論じるようにＲＥＳＯＬＶＥメッセージに対する適切な応答でよい。ＡＵＴＨＯＲＩＴＹメッセージは、否定的応答を示すために受信側ノードがセットすることができる様々なフラグを含む。このような１つのフラグは、ＲＥＳＯＬＶＥに対する応答においてのみ有効であるＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹフラグである。このフラグは、ホストが非常にビジーであるためにＲＥＳＯＬＶＥを受諾することができないことを示し、送信側に、処理のためにＲＥＳＯＬＶＥを別のところに転送すべきであることを伝える。識別検証では助けとはならないが、以下でより完全に論じるように、このフラグは、ＤｏＳ攻撃を防止するための本発明の別のセキュリティ機構である。フラグＡＦ＿ＩＮＶＡＬＩＤ＿ＳＯＵＲＣＥは、ＲＥＳＯＬＶＥに対する応答においてのみ有効であり、ＲＥＳＯＬＶＥ内のＳｏｕｒｃｅ ＰＡＣが無効であることを示す。ＡＦ＿ＩＮＶＡＬＩＤ＿ＢＥＳＴ＿ＭＡＴＣＨフラグは、ＲＥＳＯＬＶＥに対する応答においてのみ有効であり、ＲＥＳＯＬＶＥ内の「最良マッチ」ＰＡＣが無効であることを示す。ＡＦ＿ＵＮＫＮＯＷＮ＿ＩＤフラグは、指定された「検証」ＰＮＲＰ ＩＤがこのホストで登録されていないことを示す。ＡＵＴＨＯＲＩＴＹメッセージ内の他のフラグは、要求された情報が含まれていることを受信側ノードに示す。ＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮフラグは、「検証」ＰＮＲＰ ＩＤと、そのＰＡＣに署名するのに使用する公開鍵との関係を検証することを可能にする証明書チェーンが含まれていることを示す。ＡＵＴＨＯＲＩＴＹメッセージは、ＩＮＱＵＩＲＥメッセージまたはＲＥＳＯＬＶＥメッセージのどちらかに対する確認／応答としてのみ送信される。ＡＵＴＨＯＲＩＴＹがこの状況外で受信される場合、ＡＵＴＨＯＲＩＴＹは廃棄される。
【００６４】
識別検証が実施される第２のときは、ＲＥＳＯＬＶＥプロセスの間の適当なときに実施される。上述したように、ＰＮＲＰキャッシュは、高速に入れ替わる。したがって、キャッシュ内の大部分のキャッシュエントリは、それが使用される前に上書きされる。したがって、本発明のセキュリティ・インフラストラクチャは、これらのＰＡＣが実際に使用されるまで、かつ実際に使用されない限り、これらのＰＡＣを検証しない。ＰＡＣを使用してＲＥＳＯＬＶＥ経路を経路指定するとき、本発明のシステムは、上述したＲＥＳＯＬＶＥパケットに加えて識別検証を便乗させる。ＲＥＳＯＬＶＥは、ＩＮＱＵＩＲＥパケット中の「ターゲットＩＤ」と同様に扱われる「次のホップ」ＩＤを含む。次に、ＲＥＳＯＬＶＥは、上述したＩＮＱＵＩＲＥに対して予想されるのと同様に、ＡＵＴＨＯＲＩＴＹパケットを用いて確認される。適当なときの識別検証が失敗した場合、ＲＥＳＯＬＶＥの受信側は、送信側が受信側であると信じるものではない。したがって、ＲＥＳＯＬＶＥは別のところに経路指定され、無効ＰＡＣがキャッシュから除去される。
【００６５】
このプロセスもまた図２に示す。ＰＮＲＰノードＰが、ＲＥＳＯＬＶＥをセットする（２０２）ヘッダのＭｅｓｓａｇｅ Ｔｙｐｅフィールドを有するＡＵＴＨＯＲＩＴＹパケットを受信するとき（２００）、上述したように、受信側ノードは、ＡＵＴＨＯＲＩＴＹフラグを検査し、このＡＵＴＨＯＲＩＴＹフラグが否であるかどうかを判定する（２１４）。ＡＵＴＨＯＲＩＴＹメッセージに、否定的な応答フラグのいずれかがセットされている場合、ＰＡＣをキャッシュから削除し、ＲＥＳＯＬＶＥを別のところに経路指定する（２１６）。ＲＥＳＯＬＶＥの送信先のアドレスをＲＥＳＯＬＶＥ経路に追加し、ＲＥＪＥＣＴＥＤとマークする。次に、ＲＥＳＯＬＶＥを新しい宛先に転送する。ＡＵＴＨＯＲＩＴＹが否でなく、かつ証明書チェーンが要求された場合（２１８）、ＡＵＴＨＯＲＩＴＹメッセージフラグＡＦ＿ＣＥＲＴ＿ＣＨＡＩＮをチェックし、証明書チェーンが存在するかどうかを確認する。証明書チェーンが存在する場合、受信側ノードは、検証で指定されたＰＮＲＰ ＩＤに関するキャッシュされたＰＡＣに対するチェーン検証オペレーションを実施すべきである。チェーンをチェックして、チェーン内のすべての証明書が有効であり、かつチェーンのルートとリーフの間の関係が有効であることを保証すべきである。チェーンルートに関する公開鍵のハッシュは、少なくとも、ＰＡＣのＰ２Ｐ名での権限と比較して、確実にそれらがマッチするようにすべきである。チェーンリーフに関する公開鍵は、ＰＡＣを署名するのに使用する鍵と比較して、確実にそれらが一致するようにすべきである。これらのチェックのいずれかが失敗し、または要求時に証明書チェーンが存在しない場合（２２０）、キャッシュ２２２からＰＡＣを除去し、ＲＥＳＯＬＶＥを再処理すべきである。要求された証明書チェーンが含まれており、かつ検証された場合（２２０）、検証ＰＮＲＰ ＩＤに対応するＰＡＣを、完全に検証したものとしてマークすべきである（２２４）。望むなら、ＰＮＲＰ ＩＤ、ＰＮＲＰサービスアドレス、および検証時間を、ＰＡＣから保持することができ、ＰＡＣ自体は、メモリを節約するためにキャッシュから削除することができる。
【００６６】
この識別検証の一例として、ＰがＰＮＲＰ ＩＤ「Ｔ」に関する識別検証を要求するノードであると仮定する。Ｎが、識別検証要求を受信するノードである。このことは、ターゲットＩＤ＝ＴのＩＮＱＵＩＲＥパケット、または次のホップ＝ＴであるＲＥＳＯＬＶＥパケットのどちらかを受信するＰの結果として生じる可能性がある。Ｎは、ローカルに登録されたＰＮＲＰ ＩＤのリストをチェックする。Ｔがそのリスト中に存在しない場合、受信したパケットの種類をチェックする。パケット種類がＩＮＱＵＩＲＥであった場合、Ｎは暗黙のうちにＩＮＱＵＩＲＥ要求を除去する。通常の再送信の試行が満了した後、Ｐは、ＰＡＣを無効なものとして廃棄し、処理は終了する。パケット種類がＲＥＳＯＬＶＥであった場合、Ｎは、ＩＤ Ｔがローカルに登録されていないことを示すＡＵＴＨＯＲＩＴＹパケットで応答する。次に、Ｐは、ＲＥＳＯＬＶＥを別のところに送信する。ＴがＮのＰＮＲＰ ＩＤのリスト中に存在する場合、Ｎは、ＡＵＴＨＯＲＩＴＹパケットを構築し、ターゲットＩＤをＴにセットする。ＴがインセキュアＩＤである場合、Ｎは、ＡＵＴＨＯＲＩＴＹパケットをＰに送信する。ＴがセキュアＩＤであり、かつセキュアＩＤに関する権限が、ＰＡＣに署名するのに使用する鍵である場合、ＮはＡＵＴＨＯＲＩＴＹパケットをＰに送信する。これらのどれも真ではなく、かつＲＦ＿ＳＥＮＤ＿ＣＨＡＩＮフラグがセットされている場合、Ｎは、ＰＮＲＰ ＩＤ Ｔに関する権限に対してＰＡＣに署名するのに使用する鍵に関する証明書チェーンを取り出す。証明書チェーンは、ＡＵＴＨＯＲＩＴＹパケットに挿入され、Ｎは、ＡＵＴＨＯＲＩＴＹパケットをＰに送信する。この点で、ＴがインセキュアＩＤである場合、処理は完了する。そうでない場合、Ｐは、ＰＡＣに署名する鍵と、ＰＮＲＰ ＩＤ Ｔを生成するのに使用する権限との関係を検証する。検証が失敗した場合、ＰＡＣを廃棄する。検証が失敗し、かつ開始メッセージがＲＥＳＯＬＶＥであった場合、Ｐは、別のところにＲＥＳＯＬＶＥを転送する。
【００６７】
ここで識別所有権検証を２回実施したことから今や理解するであろうが、ＩＮＱＵＩＲＥパケット、または修正後のＲＥＳＯＬＶＥパケットにより、ＦＬＯＯＤを使用してＰ２Ｐクラウド全体にわたって無効ＰＡＣを一般化することができず、検索は、存在しないＩＤまたは無効なＩＤに転送されない。ＦＬＯＯＤパケットが検証なしにネットワーク中を伝播することが可能である場合、ＦＬＯＯＤパケットがＤｏＳ攻撃を引き起こす可能性があるので、ＦＬＯＯＤに対してＰＡＣ検証が必要である。これらの機構により、一般ノードのＩＤが非常に少数のノードの最低の２つのキャッシュレベルのみに属することになるので、一般ノードがＩＤ所有権チェックでフラッディングを受けることはない。
【００６８】
上述した同時係属出願により完全に記載されているように、ＰＮＲＰノードＮは、４つの方式のうちの１つにより、新しいＩＤについて認識する。ＰＮＲＰノードＮは、近隣のキャッシュの初期フラッディングによって新しいＩＤを認識することができる。具体的には、Ｐ２Ｐノードが浮上するとき、Ｐ２Ｐノードは、Ｐ２Ｐクラウドの別のノードメンバと接触し、キャッシュ同期シーケンスを開始する。Ｐ２Ｐノードは、近隣がその最低のキャッシュの新しいレコードをフラッディングする結果として、新しいＩＤを認識することができる。例えば、ノードＮがノードＭの最低レベルのキャッシュ内のエントリとして出現すると仮定する。Ｍが新しいＩＤについて認識するとき、ＩＤがＭの最低レベルのキャッシュと適合する場合、Ｍは、そのキャッシュレベル内の他のエントリと、ＮにそのＩＤをそれぞれフラッディングする。ノードは、検索要求の結果として新しいＩＤを認識することができる。検索要求の発信元は、要求内に発信元のアドレス証明書を挿入し、検索要求に対する「最良マッチ」のＰＡＣもまた、そのＰＡＣを要求内に挿入する。このようにして、検索要求経路に沿うノードのすべては、検索発信元のアドレス、および最良マッチのアドレスでノードのキャッシュを更新することになる。同様に、ノードは、検索応答の結果として新しいＩＤを認識することができる。検索要求の結果は、要求経路のサブセットを逆の順序で移動する。この経路に沿うノードは、検索結果でノードのキャッシュを更新する。
【００６９】
ＰＮＲＰによれば、ノードが最初に浮上するとき、ノードは近隣を見つける。しかし、上述したように、最初に見つかったノードが悪意のあるノードである場合、その新しいノードは、悪意のあるノードによって制御される可能性がある。このような発生の可能性を防止し、または最小にするため、本発明のセキュリティ・インフラストラクチャは、セキュアノードブートアップを保証するための２つの機構を提供する。第１の機構は、ランダム化されたディスカバリである。ノードが、そのノードがＰＮＲＰクラウドに加わることを可能にする別のノードを見つけようと試みるとき、見つけるための最後の選択肢は、マルチキャスト／同報通信を使用することである。マルチキャスト／同報通信は、最もインセキュアなＰＮＲＰの発見方法だからである。ディスカバリの性質のために、良好なノードと不良なノードとを区別することが非常に難しい。したがって、このマルチキャスト／同報通信方法が必要なとき、本発明のセキュリティ・インフラストラクチャは、同報通信ディスカバリ（ＭＡＲＣＯＰＯＬＯまたは既存のマルチキャストディスカバリプロトコル。例えばＳＳＤＰ）メッセージに応答したノードのうちの１つを、ノードにランダムに選択させる。ランダムなノードを選択することにより、本発明のシステムは、不良なノードを選択する確率を最小にする。本発明のシステムは、そのＩＤのいずれも使用せずにこのディスカバリを実施する。ディスカバリ中にＩＤを使用しないことにより、本発明のシステムは、悪意のあるノードが特定のＩＤをターゲットにすることを防止する。
【００７０】
ノードがその間にビットベクトルを維持する修正された同期段階により、第２のセキュアノードブートアップ機構が提供される。修正された同期段階機構は、図３の単純化した流れ図に示す例により、最もよく理解できる。アリス２２６が、アリス２２６のＰＡＣが含まれるＳＯＬＩＣＩＴ ２２８をボブ２３０に送信すると仮定する。アリスのＰＡＣが有効でない場合（２３２）、ボブ２３０は、単にＳＯＬＩＣＩＴ ２３４を除去する。ＰＡＣが有効である場合、ボブ２３０は、この接続の状態を格納するためにビットベクトルを維持する。このＳＯＬＩＣＩＴを受信したとき、ボブ２３０は、ナンスを生成し、それをアリスのＰＮＲＰ ＩＤでハッシュする（２３６）。得られる数は、ボブがセットするこのビットベクトルの索引として使用される。次に、ボブ２３０は、ＡＤＶＥＲＴＩＳＥメッセージでアリス２２６に応答する（２３８）。このＡＤＶＥＲＴＩＳＥは、他の情報とは別にアリスの公開鍵で暗号化されたボブのＰＡＣおよびナンスを含み、ボブ２３０によって署名される。アリス２２６がこのＡＤＶＥＲＴＩＳＥを受信したとき、アリス２２６は、署名およびボブのＰＡＣを検証する（２４０）。それを検証することができない場合、除去される（２４１）。それを検証することができる場合、アリス２２６は、ナンスを暗号化解除する（２４２）。次に、アリス２２６は、このナンスおよびアリスのＰＮＲＰ ＩＤを含むＲＥＱＵＥＳＴを生成する（２４４）。ボブ２３０は、ＲＥＱＵＥＳＴパケットで送信されたナンスでアリスのＰＮＲＰ ＩＤをハッシングすることによって、このＲＥＱＵＥＳＴを処理する（２４６）。ハッシングされた結果を索引として有するビットベクトルにビットがセットされている場合（２４８）、ボブは、ビットをクリアし、ＲＥＱＵＥＳＴの処理を開始する（２５０）。そうでない場合、ＲＥＱＵＥＳＴは応答攻撃である可能性があるので、ボブは、ＲＥＱＵＥＳＴを無視する（２５２）。
【００７１】
これにより、シーケンスを再生することができないので、ノードブートアップは、セキュアプロセスになる。これにより、ＣＰＵ、ネットワークポート、およびネットワークトラフィックを含む、消費されるリソースの点で、必要なオーバヘッドが最小となる。状態情報に対して維持すべきタイマは不要であり、シンクアップを開始したＩＤだけが送信データとなる。実際、修正された同期段階は、非同期であり、それにより、ノードが複数のＳＯＬＩＣＩＴを同時に処理することが可能となる。
【００７２】
パケットを処理する速度を制御し、すなわちノードリソース消費を制限することにより、上述した脅威の多くを最小にすることができる。この背後にある考えは、ノードは、ＰＮＲＰパケットを処理しようとするノードのＣＰＵを１００％消費すべきでないということである。したがって、本発明の実施形態によれば、あるメッセージの処理が、ノードが効果的に機能することを妨害するとノードが検出したとき、ノードは、そのようなメッセージの処理を拒絶することができる。
【００７３】
処理しないとノードが判断することができるそのような１つのメッセージは、別のノードから受信したＲＥＳＯＬＶＥメッセージである。図４に、このプロセスを単純化した形で示す。ＲＥＳＯＬＶＥメッセージを受信した後（２５４）、ノードは、所定の限界を超えるＣＰＵ能力でノードが現在動作しているかどうかをチェックする（２５６）。ノードのＣＰＵが非常にビジーであるためにＲＥＳＯＬＶＥメッセージを処理することができない場合、ノードは、ノードが非常にビジーであるために要求を処理することに失敗したことを示すＡＦ＿ＲＥＪＥＣＴ＿ＴＯＯ＿ＢＵＳＹフラグセットを有するＡＵＴＨＯＲＩＴＹメッセージを送信する（２５８）。ＣＰＵがそれほどビジーではない場合（２５６）、ノードは、ＲＥＳＯＬＶＥメッセージ内のＰＡＣのすべてが有効であるかどうかを判定し（２６０）、いずれかが無効であることが判明した場合、メッセージを拒絶する（２６２）。ＰＡＣのすべてが有効である場合（２６０）、ノードはＲＥＳＯＬＶＥを処理する（２６４）。
【００７４】
ノードがＲＥＳＯＬＶＥに応答することができる場合（２６６）、ノードはＲＥＳＯＬＶＥをＲＥＳＰＯＮＳＥに変換し、それをＲＥＳＯＬＶＥの送信元のノードに送信する（２６８）。しかし、ターゲットＩＤがローカルに登録されていない場合、ノードはＲＥＳＯＬＶＥ内のフィールドのハッシュとしてビット位置を計算し、対応するビット位置をビットベクトルにセットする（２７０）。上記で簡潔に論じたように、このビットベクトルは、応答が期待されるどんなメッセージもノードが送信していないときに、誤り応答メッセージの処理を防止するためのセキュリティ機構として使用される。ノードは、ノードがメッセージを処理したことを証明する適切な変更と共にＲＥＳＯＬＶＥを転送する次のホップを見つける。ＲＥＳＯＬＶＥを転送すべき転送先のノードが既に検証されている場合（２７２）、ノードは単に、ＲＥＳＯＬＶＥをその次のホップに転送する（２７６）。この選択された次のホップがまだ検証されていない場合（２７２）、ノードは、ＲＥＳＯＬＶＥにＩＤ所有権要求を便乗させ（２７４）、それをそのノードに転送する（２７６）。便乗させたＩＤ所有権要求に応答して、ノードは、上述したようにＡＵＴＨＯＲＩＴＹメッセージを受信することを期待する。そのプロセスを図２に示す。図２に示すように、ステップ２１４で検証ＡＵＴＨＯＲＩＴＹが受信されていない場合、ＲＥＳＯＬＶＥが転送されたノードのＰＡＣがキャッシュから削除され（２１６）、ＲＥＳＯＬＶＥが図４のステップ２５４から再処理される。
【００７５】
ノードのＣＰＵが非常にビジーであるためにノードが処理しないと判断することができる別のメッセージは、ＦＬＯＯＤメッセージである。図５に単純化した形で示すこのプロセスでは、ＦＬＯＯＤ中に存在する新しい情報が最低の２つのキャッシュレベルの一方に進んだ場合（２７８）、ＰＡＣをチェックして、ＰＡＣが有効であるかどうかを判定する（２８０）。ＰＡＣが有効でない場合、ＦＬＯＯＤを拒絶する（２８４）。しかし、ＰＡＣが有効である場合（２８０）、ＰＡＣを保留リストに入れる（２８２）。保留リスト中のエントリは、ランダムな間隔でとられ、ＣＰＵがそれほどビジーでないときに処理される。これらのエントリがキャッシュの最低の２つのレベルに入ろうとしているので、上述したように、ＩＤ検証と所有権検証が共に実施される。ＦＬＯＯＤ中に存在する新しい情報がより高いキャッシュレベルに進み（２７８）、かつＣＰＵが非常にビジーでそれを処理することができない場合（２８６）、それは廃棄される（２８８）。ノードが利用可能なＣＰＵ処理能力を有する場合（２８６）、ＰＡＣをチェックし、それが有効であるかどうかを判定する（２９０）。有効である場合、ＰＡＣをキャッシュに追加し（２９２）、そうでない場合ＦＬＯＯＤを拒絶する（２９４）。
【００７６】
ノードブートアップ（ＳＹＮＣＨＲＯＮＩＺＥ）は、ＣＰＵ処理能力だけでなく、ネットワーク帯域幅も含むかなりのリソースをノードで消費する別のプロセスである。しかし、新しいノードがＰ２Ｐクラウドに完全に参加することを可能にするためには、同期プロセスが必要である。したがって、ノードが所与の時間に利用可能なリソースを十分に有する場合、ノードは、ブートアップを求める別のノードの要求に応答する。すなわち、これまで議論した２つのメッセージと同様に、ノードのＣＰＵ稼働率が非常に高い場合、ノードは、ブートアップへの参加を拒絶することができる。しかし、このプロセスは非常に多くの能力を消費するので、悪意のあるノードが、多数のこのようなシーケンスを立ち上げることにより、依然としてこのプロセスを利用する可能性がある。したがって本発明のセキュリティ・インフラストラクチャの実施形態は、この攻撃を防止するために、所与のノードによって処理することができるノード同期の数を制限する。加えて、この制限を時間限定とすることができ、その結果、悪意のあるノードは、このような同期を将来再び実施できないようにノードを使用不能にすることができない。
【００７７】
悪意のあるノードによって立ち上げられ、または引き起こされる可能性のある多数の検索ベースの攻撃を上述した。このような検索ベースの攻撃の効果をなくし、または最小にするため、本発明のシステムは２つの機構を提供する。第１の機構はランダム化である。すなわち、ノードが、検索要求（ＲＥＳＯＬＶＥ）の転送先の適切な次のホップを検索しているとき、ノードは、いくつかの可能な候補ノードを識別し、次に、これらの候補ＩＤから、ＲＥＳＯＬＶＥの転送先となる１つのＩＤをランダムに選択する。一実施形態では、ランダムな選択のために３つの候補ノードが識別される。ＩＤは、全ランダム化の代替方法として、重み付けした確率に基づいて選択することができる。ＩＤが悪意のないノードに属することの重み付けした確率を計算する１つの方法は、ターゲットＩＤからのＰＮＲＰ ＩＤの距離に基づく。次に、そのノードとターゲットノードとの間のＩＤ距離の反比例として確率が決定される。いずれにしても、このランダム化により、悪意のあるノードにＲＥＳＯＬＶＥ要求を送信する確率が減少する。
【００７８】
検索ベースの攻撃に対して効果的な第２のセキュリティ機構は、上述したビットベクトルを使用して状態情報を維持する。すなわち、ノードは、ノードが処理したＲＥＳＯＬＶＥメッセージであって、それに対する応答がまだ受信されていないＲＥＳＯＬＶＥメッセージのすべてを識別する情報を維持する。状態情報を維持するために使用するフィールドは、ターゲットＩＤと、ＲＥＳＯＬＶＥパケット中のアドレスリストである。この２番目のフィールドを、検索を妨害しようとする悪意のあるノードによってアドレスリストが変更されていないことを保証するために使用する。ビットベクトルの他の例に関して上述したように、ノードは、ＲＥＳＯＬＶＥからこれらのフィールドのハッシュを生成し、ビットベクトル中の対応するビット位置をセットして、そのＲＥＳＯＬＶＥの処理の履歴を維持する。
【００７９】
図６の単純化した流れ図に示すように、別のノードからＲＥＳＰＯＮＳＥメッセージを受信したとき（２９６）、このＲＥＳＰＯＮＳＥメッセージ中のフィールドをハッシュし、ビット位置を計算する（２９８）。次に、ノードは、ビットベクトルをチェックし、ビット位置がセットされているかどうかを確認する（３００）。ビットがセットされていない場合、このＲＥＳＰＯＮＳＥが以前に処理したＲＥＳＯＬＶＥとは関係がないことを意味し、パケットを廃棄する（３０２）。ビット位置がセットされている場合、このＲＥＳＰＯＮＳＥが以前に処理したＲＥＳＯＬＶＥと関係していることを示し、ビット位置をリセットする（３０４）。ビット位置をリセットすることにより、ノードは、悪意のあるノードからの再生攻撃の一部として送信された可能性のある、別の同一のＲＥＳＰＯＮＳＥメッセージを無視することになる。次に、ノードは、ＲＥＳＰＯＮＳＥを処理してそれを次のホップに転送する前に、ＲＥＳＰＯＮＳＥメッセージ中のＰＡＣのすべてが有効であるかどうかを確認するためにチェックを行う（３０６）。ＰＡＣのいずれかが無効である場合（３０６）、ノードはパケットを拒絶する（３１０）。
【００８０】
ＲＥＳＯＬＶＥプロセスは、ＲＥＳＯＬＶＥ要求をＲＥＳＰＯＮＳＥに変換することに触れる。ここで論じたこのＲＥＳＰＯＮＳＥの処理は、ＲＥＳＰＯＮＳＥが最近受信したＲＥＳＯＬＶＥに対応することを保証すること、および指定された次のホップにＲＥＳＰＯＮＳＥを転送することを含む。例えば、ノードＰが、ターゲットＰＮＲＰ ＩＤと、ＢｅｓｔＭａｔｃｈ ＰＡＣと、このノードの前に元のＲＥＳＯＬＶＥを処理したすべてのノードのアドレスをリストする経路とを含み、このノードがＰＮＲＰアドレスを所有することで終了するＲＥＳＰＯＮＳＥパケットＳを受信すると仮定する。ノードＰは、ＲＥＳＰＯＮＳＥの受信をＡＣＫで確認する。ノードＰは、それ自体のアドレスについてＲＥＳＰＯＮＳＥ経路をチェックする。ノードＰのアドレスは、このパケットが有効となるために、アドレスリスト中の最後のエントリでなければならない。ノードＰは、ＲＥＳＰＯＮＳＥが最近確認したＲＥＳＯＬＶＥとマッチすることを保証するために、受信したビットベクトルをチェックする。ＲＥＳＰＯＮＳＥが、受信したビットベクトル中のフィールドと一致しない場合、またはＰのアドレスが経路リスト中の最後のアドレスでない場合、ＲＥＳＰＯＮＳＥを暗黙のうちに除去し、処理は停止する。Ｐは、ＢｅｓｔＭａｔｃｈ ＰＡＣを検証し、それをＰのローカルキャッシュに追加する。ＢｅｓｔＭａｔｃｈが無効である場合、ＲＥＳＰＯＮＳＥを暗黙のうちに除去し、処理は停止する。Ｐは、ＲＥＳＰＯＮＳＥ経路の最後からそのアドレスを除去する。Ｐは、対応するＲＥＳＯＬＶＥ要求をＡＣＣＥＰＴしたノードを示すフラグセットを有する最後のエントリまで、ＲＥＳＰＯＮＳＥ経路の最後からエントリを除去することを続行する。経路がそのときに空である場合、対応するＲＥＳＯＬＶＥがローカルに生成される。ＰＮＲＰは、ＢｅｓｔＭａｔｃｈに対する識別検証チェックを行う。識別検証チェックが成功した場合、ＢｅｓｔＭａｔｃｈが要求マネージャに渡され、そうでない場合、失敗の表示が渡される。経路が空である場合、処理は完了する。経路が空でない場合、ノードは、ＲＥＳＰＯＮＳＥパケットを経路リスト中の最後のエントリに転送する。
【００８１】
発行されたアドレス証明書が証明書満了日（Ｖａｌｉｄｉｔｙ／Ｔｏフィールド）より前に無効になったときはいつでも、ＰＮＲＰアドレス証明書を取り消す必要がある。このようなイベントの例は、ノードがスムーズにＰ２Ｐネットワークから切断されるとき、またはノードがグループから離脱しつつあるときなどである。本発明の取消し機構は、取消し証明書の発行を利用する。取消し証明書は、Ｒｅｖｏｋｅ Ｆｌａｇセットと、現在時刻（または証明書を取り消すべき時刻）にセットされたＶａｌｉｄｉｔｙフィールドのＦｒｏｍ ｄａｔｅと、以前に公示された証明書と同じ値にセットされたＴｏフィールドとを有する。以下の条件すべてを満たす証明書すべてが取り消されるとみなされる。その証明書が同じ発行者によって署名されていること、ＩＤが取消し証明書のＩＤと一致すること、Ａｄｄｒｅｓｓフィールドが、取消し証明書のＡｄｄｒｅｓｓフィールドと一致すること、ＶａｌｉｄａｔｉｏｎフィールドのＴｏ ｄａｔｅが、取消し証明書のＶａｌｉｄａｔｉｏｎフィールドのＴｏ ｄａｔｅと同じであること、およびＶａｌｉｄａｔｉｏｎフィールドのＦｒｏｍ ｄａｔｅが、取消し証明書のＶａｌｉｄａｔｉｏｎフィールドのＦｒｏｍ ｄａｔｅに先行することである。取消し証明書が署名されるので、悪意のあるノードがクラウドからどれかを切断することができないことが保証される。
【００８２】
本発明の様々な実施形態の上記の説明は、例示および説明のために提示した。上記の説明は、包括的なものではなく、または開示される厳密な実施形態に本発明を限定するものではない。上記の教示に照らして、多数の修正形態または変形形態が可能である。本発明の原理およびその実際的な応用例を最良に例示し、それによって当業者が、企図される特定の使用法に適するように本発明を様々な実施形態で、様々な修正を加えて利用することが可能となるように、上記で議論した実施形態を選び、説明した。このような修正形態および変形形態は、頭記の特許請求の範囲が公平に、法律的に、かつ公正に権利を有する幅に従って解釈されるとき、頭記の特許請求の範囲に記載される本発明の範囲内にある。
【図面の簡単な説明】
【図１】本発明が常駐する例示的コンピュータシステムを一般的に示すブロック図である。
【図２】本発明の実施形態にかかるＡＵＴＨＯＲＩＴＹパケット処理のセキュリティ面を示す、単純化した流れ図である。
【図３】本発明の実施形態にかかるＰ２Ｐディスカバリの同期段階のセキュリティ面を示す、単純化した通信処理の流れ図である。
【図４】本発明の実施形態にかかるＲＥＳＯＬＶＥパケット処理のセキュリティ面を示す、単純化した流れ図である。
【図５】本発明の実施形態によるＦＬＯＯＤパケット処理のセキュリティ面を示す、単純化した流れ図である。
【図６】本発明の実施形態によるＲＥＳＰＯＮＳＥパケット処理のセキュリティ面を示す、単純化した流れ図である。
【符号の説明】
１００ コンピューティング環境
１１０ コンピュータ
１２０ 処理装置
１２１ システムバス
１３０ システムメモリ
１３１ 読取り専用メモリ
１３２ ランダムアクセスメモリ
１３３ 基本入出力システム
１３４、１４４ オペレーティングシステム
１３５、１４５ アプリケーションプログラム
１３６、１４６ 他のプログラムモジュール
１３７、１４７ プログラムデータ
１４０、１５０ インタフェース
１６０ ユーザ入力インタフェース
１６１ ポインティングデバイス
１６２ キーボード
１７０ ネットワークインタフェースまたはアダプタ
１７１ ローカルエリアネットワーク
１７２ モデム
１７３ 広域ネットワーク
１８０ リモートコンピュータ
１９０ ビデオインタフェース
１９１ モニタ
１９５ 出力周辺インタフェース
１９６ プリンタ
１９７ スピーカ
Claims (49)
- ピアツーピアネットワークにおいて、自己検証可能なインセキュアピアアドレス証明書を生成して、悪意のあるノードがインセキュアピアアドレス証明書内で別のノードのセキュア識別を発行することを防止する方法であって、
前記ピアツーピアネットワーク内で見つけることができ、ピアツーピア識別（ＩＤ）を有するリソースに対するインセキュアピアアドレス証明書（ＰＡＣ）を生成するステップと、
前記ピアツーピアＩＤの導出元の前記インセキュアＰＡＣ内に、ユニフォームリソース識別子（ＵＲＩ）を含めるステップと
を備えたことを特徴とする方法。 - 前記ピアツーピアＩＤの導出元の前記インセキュアＰＡＣ内にＵＲＩを含める前記ステップは、「ｐ２ｐ：／／ＵＲＩ」フォーマットの前記ＵＲＩを含めるステップを備えたことを特徴とする請求項１に記載の方法。
- 前記ピアツーピアＩＤは、インセキュアであることを特徴とする請求項１に記載の方法。
- ピアツーピアネットワークにおいて、第１ノードでピアアドレス証明書を適当なときに検証する方法であって、前記第１ノードは、ピアアドレス証明書を格納するために複数レベルのキャッシュを使用し、
第２ノードから意図的にピアアドレス証明書（ＰＡＣ）を受信するステップと、
前記複数レベルのキャッシュのどのレベルに前記ＰＡＣを格納すべきかを決定するステップと、
前記ＰＡＣが、２つの最低のキャッシュレベルの一方に格納すべきとき、
（ａ）前記ＰＡＣを保留リストに配置するステップと、
（ｂ）検証すべき前記ＰＡＣのＩＤを含むＩＮＱＵＩＲＥメッセージを生成するステップと、
（ｃ）前記ＩＮＱＵＩＲＥメッセージを前記第２ノードに送信するステップと、
前記ＰＡＣが、前記２つの最低のキャッシュレベル以外の上位のキャッシュレベルに格納すべきとき、前記ＰＡＣを前記上位のキャッシュレベルに格納するステップと
を備えたことを特徴とする方法。 - 前記ＩＮＱＵＩＲＥメッセージを送信するステップは、前記ＰＡＣに関する証明書チェーンを要求するステップを含むことを特徴とする請求項４に記載の方法。
- 前記ＩＮＱＵＩＲＥメッセージを生成する前記ステップは、前記ＩＮＱＵＩＲＥメッセージに含めるべきトランザクションＩＤを生成するステップを備えたことを特徴とする請求項４に記載の方法。
- 前記ＩＮＱＵＩＲＥメッセージに応答して、前記第２ノードからＡＵＴＨＯＲＩＴＹメッセージを受信するステップと、
前記保留リストから前記ＰＡＣを除去するステップと、
前記２つの最低のキャッシュレベルの前記一方に前記ＰＡＣを格納するステップと
をさらに備えたことを特徴とする請求項４に記載の方法。 - 前記ＩＮＱＵＩＲＥメッセージに応答して、前記第２ノードからＡＵＴＨＯＲＩＴＹメッセージを受信するステップと、
前記保留リストから前記ＰＡＣを除去するステップと、
前記ＡＵＴＨＯＲＩＴＹメッセージを検査して、前記証明書チェーンが存在し、かつ有効であるか否かを判定するステップと、
前記証明書チェーンが存在し、かつ有効であるとき、前記２つの最低のキャッシュレベルの前記一方に前記ＰＡＣを格納するステップと、
前記証明書チェーンが存在せず、かつ有効でないとき、前記ＰＡＣを削除するステップと
をさらに備えたことを特徴とする請求項５に記載の方法。 - 前記ＩＮＱＵＩＲＥメッセージに応答して、前記第２ノードからＡＵＴＨＯＲＩＴＹメッセージを受信するステップと、
前記保留リストから前記ＰＡＣを除去するステップと、
前記ＡＵＴＨＯＲＩＴＹメッセージを検査して、前記トランザクションＩＤが存在するか否かを判定するステップと、
前記トランザクションＩＤが存在するとき、前記２つの最低のキャッシュレベルの前記一方に前記ＰＡＣを格納するステップと、
前記トランザクションＩＤが存在しないとき、前記ＰＡＣを削除するステップと
をさらに備えたことを特徴とする請求項６に記載の方法。 - 前記２つの最低のキャッシュレベルの一方以外の上位のキャッシュレベル格納された前記ＰＡＣを選択し、ＲＥＳＯＬＶＥパケットを経路指定するステップと、
便乗されたＩＤ所有権検証情報を有する前記ＲＥＳＯＬＶＥパケットを前記第２ノードに送信するステップと、
前記第２ノードがＩＤ所有権を検証したとき、前記ＰＡＣを有効なものとしてマークするステップと
をさらに備えたことを特徴とする請求項４に記載の方法。 - 前記第２ノードがＩＤ所有権を検証することができないとき、前記２つの最低のキャッシュレベルの一方以外の上位のキャッシュレベルから前記ＰＡＣを削除するステップと、
異なるＰＡＣで前記ＲＥＳＯＬＶＥパケットを再処理するステップと
をさらに備えたことを特徴とする請求項１０に記載の方法。 - 前記第２ノードがＩＤ所有権を検証することができないとき、前記２つの最低のキャッシュレベルの一方以外の上位のキャッシュレベルから前記ＰＡＣを削除するステップは、前記ＰＡＣを削除する前に、前記第２ノードがＩＤ所有権を検証するために所定の期間待機するステップを備えたことを特徴とする請求項１１に記載の方法。
- 前記第２ノードがＩＤ所有権を検証することができないとき、前記２つの最低のキャッシュレベルの一方以外の上位のキャッシュレベルから前記ＰＡＣを削除するステップは、
前記第２ノードからＡＵＴＨＯＲＩＴＹメッセージを受信するステップと、
前記ＡＵＴＨＯＲＩＴＹメッセージを検査して、前記第２ノードがＩＤ所有権を検証することができたかどうかを判定するステップと、
前記第２ノードがＩＤ所有権を検証することができなかったことを判定するステップと、
前記ＰＡＣを削除するステップと
を備えたことを特徴とする請求項１１に記載の方法。 - 前記第２ノードがＩＤ所有権を検証することができなかったことを判定するステップは、前記第２ノードが、前記ＰＡＣのＩＤ所有権を検証することができなかったことを示す前記ＡＵＴＨＯＲＩＴＹメッセージ内のフラグをセットすることを決定するステップを備えたことを特徴とする請求項１３に記載の方法。
- 前記第２ノードがＩＤ所有権を検証することができなかったことを判定するステップは、前記ＡＵＴＨＯＲＩＴＹメッセージを検査して、証明書チェーンが存在せず、かつ有効でないことを判定するステップを備えたことを特徴とする請求項１３に記載の方法。
- 前記第２ノードがＩＤ所有権を検証したとき、前記ＰＡＣを有効なものとしてマークするステップは、ＩＤ所有権を検証する前記第２ノードから、ＡＵＴＨＯＲＩＴＹメッセージを受信するステップを備えたことを特徴とする請求項１０に記載の方法。
- 前記第２ノードがＩＤ所有権を検証したとき、前記ＰＡＣを有効なものとしてマークするステップは、ＩＤ所有権を検証する証明書チェーンを有する前記第２ノードから、ＡＵＴＨＯＲＩＴＹメッセージを受信するステップを備えたことを特徴とする請求項１０に記載の方法。
- ピアツーピアネットワークにおいてノードを見つける方法であって、
前記ピアツーピアネットワークにおいて、ローカルに登録されたＩＤを含めずに発見メッセージを同報通信するステップと、
前記ピアツーピアネットワーク内のノードから応答を受信するステップと、
前記ノードとピアリング関係を確立するステップと
を備えたことを特徴とする方法。 - ノードから応答を受信するステップは、前記ピアツーピアネットワーク内の少なくとも２つのノードから応答を受信するステップを備え、前記ノードとピアリング関係を確立するステップは、前記少なくとも２つのノードの一方をランダムに選択するステップと、前記少なくとも２つのノードのうちのランダムに選択された一方とピアリング関係を確立するステップとを備えたことを特徴とする請求項１８に記載の方法。
- ピアツーピアネットワークにおいて、同期プロセスに基づくサービス妨害攻撃を抑制する方法であって、
キャッシュ同期を要求し、第１ノードに関するピアアドレス証明書（ＰＡＣ）を含むＳＯＬＩＣＩＴメッセージを前記第１ノードから受信するステップと、
前記ＰＡＣを検査して、その有効性を判定するステップと、
前記ＰＡＣを検査する前記ステップが、前記ＰＡＣが有効でないと判定したとき、前記ＳＯＬＩＣＩＴパケットを除去するステップと
を備えたことを特徴とする方法。 - 前記ＰＡＣが有効であることを判定する前記ＰＡＣを検査するステップは、
ナンスを生成するステップと、
前記ナンスを前記第１ノードの公開鍵で暗号化するステップと、
前記暗号化それたナンスを含むＡＤＶＥＲＴＩＳＥメッセージを生成するステップと、
前記ＡＤＶＥＲＴＩＳＥメッセージを前記第１ノードに送信するステップと、
前記第１ノードからＲＥＱＵＥＳＴメッセージを受信するステップと、
前記ＲＥＱＵＥＳＴメッセージを検査して、前記第１ノードが前記暗号化されたナンスを暗号化解除することができたかどうかを判定するステップと、
前記ＲＥＱＵＥＳＴメッセージを検査するステップが、前記第１ノードが前記暗号化されたナンスを暗号化解除することができたことを示すとき、前記ＲＥＱＵＥＳＴメッセージを処理するステップと
をさらに備えたことを特徴とする請求項２０に記載の方法。 - 前記第１ノードとの通信を具体的に識別する接続情報を維持するステップと、
前記ＲＥＱＵＥＳＴメッセージを検査し、それが具体的に前記ＡＤＶＥＲＴＩＳＥメッセージと関係することを保証するステップと、
前記ＲＥＱＵＥＳＴメッセージを検査し、前記ＲＥＱＵＥＳＴメッセージが具体的に前記ＡＤＶＥＲＴＩＳＥメッセージと関係することを保証するステップが、それが具体的に前記ＡＤＶＥＲＴＩＳＥメッセージと関係しないことを示すとき、前記ＲＥＱＵＥＳＴメッセージを拒絶するステップと
をさらに備えたことを特徴とする請求項２１に記載の方法。 - 前記第１ノードとの前記通信を具体的に識別する接続情報を維持するステップは、
前記ナンスおよび前記第１ノードの識別のハッシュとして第１ビット位置を計算するステップと、
ビットベクトル中の前記第１ビット位置でビットをセットするステップと
を備えたことを特徴とする請求項２２に記載の方法。 - 前記ＲＥＱＵＥＳＴメッセージを検査し、前記ＲＥＱＵＥＳＴメッセージが具体的に前記ＡＤＶＥＲＴＩＳＥメッセージと関係することを保証するステップは、
前記ＲＥＱＵＥＳＴメッセージから前記ナンスおよび前記第１ノードの識別を抽出するステップと、
前記ナンスおよび前記第１ノードの識別のハッシュとして第２ビット位置を計算するステップと、
前記ビットベクトルを検査し、それが前記第２ビット位置に対応するビットセットを有するかどうかを判定するステップと、
前記ビットベクトルを検査するステップが、前記第２ビット位置に対応するビットセットを見つけないとき、前記ＲＥＱＵＥＳＴが前記ＡＤＶＥＲＴＩＳＥメッセージに具体的に関係しないことを示すステップと
を備えたことを特徴とする請求項２３に記載の方法。 - ピアツーピアネットワークにおいて、同期プロセスに基づくサービス妨害攻撃を抑制する方法であって、
第１ノードから意図的にＲＥＱＵＥＳＴメッセージを受信するステップと、
前記ＲＥＱＵＥＳＴメッセージが前記第１ノードとの以前の通信に対する応答であるかどうかを判定するステップと、
前記ＲＥＱＵＥＳＴメッセージが前記第１ノードとの以前の通信に対する応答でないとき、前記ＲＥＱＵＥＳＴメッセージを拒絶するステップと
を備えたことを特徴とする方法。 - 前記ＲＥＱＵＥＳＴメッセージが前記第１ノードとの以前の通信に対する応答であるかどうかを判定するステップは、
前記ＲＥＱＵＥＳＴメッセージから前記第１ノードのナンスおよび識別を意図的に抽出するステップと、
前記ナンスおよび前記識別のハッシュとしてビット位置を計算するステップと、
前記ビットベクトルを検査し、それが前記ビット位置に対応するビットセットを有するかどうかを判定するステップと、
前記ビットベクトルを検査するステップが、前記ビット位置に対応するビットセットを見つけないとき、前記ＲＥＱＵＥＳＴが前記第１ノードとの以前の通信の応答ではないことを示すステップと
を備えたことを特徴とする請求項２５に記載の方法。 - ピアツーピアネットワークにおいて、ノードリソースの消費に基づくサービス妨害攻撃を抑制する方法であって、
前記ピアツーピアネットワーク内のノードからメッセージを受信するステップと、
現在のリソース使用率を検査するステップと、
現在のリソース使用率を検査するステップが、前記現在のリソース使用率が所定のレベルを超えていることを示すとき、前記メッセージの処理を拒絶するステップと
を備えたことを特徴とする方法。 - メッセージを受信するステップは、ＲＥＳＯＬＶＥメッセージを受信するステップを含み、前記メッセージの処理を拒絶するステップは、ＡＵＴＨＯＲＩＴＹメッセージを前記第１ノードに送信するステップを含み、前記ＡＵＴＨＯＲＩＴＹメッセージは、前記現在のリソース使用率が高過ぎるために前記ＲＥＳＯＬＶＥメッセージが処理されないという表示を含むことを特徴とする請求項２７に記載の方法。
- メッセージを受信するステップは、ピアアドレス証明書（ＰＡＣ）を含むＦＬＯＯＤメッセージを受信するステップを含み、前記ＰＡＣが２つの最低のキャッシュレベルの一方に格納すべきことを決定するステップをさらに備え、前記メッセージの処理を拒絶するステップは、後の処理のために保留リスト内に前記ＰＡＣを配置するステップを備えたことを特徴とする請求項２７に記載の方法。
- メッセージを受信するステップは、ピアアドレス証明書（ＰＡＣ）を含むＦＬＯＯＤメッセージを受信するステップを含み、前記ＰＡＣが２つの最低のキャッシュレベルよりも高いキャッシュレベルに格納すべきことを決定するステップをさらに備え、前記メッセージの処理を拒絶するステップは、前記ＦＬＯＯＤメッセージを拒絶するステップを備えたことを特徴とする請求項２７に記載の方法。
- ピアツーピアネットワークにおいて、ノード帯域幅の消費に基づくサービス妨害攻撃を抑制する方法であって、
前記ピアツーピアネットワーク内のノードからキャッシュ同期の要求を受信するステップと、
過去に実施されたキャッシュ同期の数を示すメトリックを検査するステップと、
メトリックを検査するステップが、前記過去に実施されたキャッシュ同期の数が所定の最大値を超えていることを示すとき、前記キャッシュ同期の要求の処理を拒絶するステップと
を備えたことを特徴とする方法。 - メトリックを検査する前記ステップは、前記メトリックを検査し、所定の先行期間に実施されたキャッシュ同期の数を判定するステップを備え、前記要求の処理を拒絶するステップは、前記メトリックを検査するステップが前記所定の先行期間に実施されたキャッシュ同期の数が所定の最大値を超えていることを示すとき、前記キャッシュ同期の要求の処理を拒絶するステップを備えたことを特徴とする請求項３１に記載の方法。
- ピアツーピアネットワークにおいて、検索ベースのサービス妨害攻撃を抑制する方法であって、
既知のピアアドレス証明書のキャッシュエントリを検査し、解決要求を送信する適切なノードを決定するステップと、
前記適切なノードのうち１つをランダムに選択するステップと、
前記ランダムに選択されたノードに前記解決要求を送信するステップと
を備えたことを特徴とする方法。 - 前記適切なノードのうち１つをランダムに選択するステップは、前記ノードまでの距離の反比例に基づいて、前記適切なノードごとに重み付けした確率を計算するステップを備えたことを特徴とする請求項３３に記載の方法。
- ピアツーピアネットワークにおいて、検索ベースのサービス妨害攻撃を抑制する方法であって、
ＲＥＳＰＯＮＳＥメッセージを受信するステップと、
前記ＲＥＳＰＯＮＳＥメッセージが以前のＲＥＳＯＬＶＥメッセージに対する応答であるかどうかを判定するステップと、
前記ＲＥＳＰＯＮＳＥメッセージが前記以前のＲＥＳＯＬＶＥメッセージに対する応答でないとき、前記ＲＥＱＵＥＳＴメッセージを拒絶するステップと
を備えたことを特徴とする方法。 - 前記ＲＥＳＰＯＮＳＥメッセージが以前のＲＥＳＯＬＶＥメッセージに対する応答であるかどうかを判定するステップは、前記ＲＥＳＰＯＮＳＥメッセージ内の情報のハッシュとしてビット位置を計算するステップと、ビットベクトルを検査し、前記ビット位置に対応するビットがビットベクトル内にセットされているかどうかを判定するステップとを備えたことを特徴とする請求項３５に記載の方法。
- 前記ＲＥＳＰＯＮＳＥメッセージは、アドレスリストを含み、解決を妨害する試みにおいて前記ＲＥＳＰＯＮＳＥメッセージが変更されているかどうかを判定するステップと、解決を妨害する試みにおいて前記ＲＥＳＰＯＮＳＥメッセージが変更されているとき、前記ＲＥＳＰＯＮＳＥメッセージを拒絶するステップとをさらに備えたことを特徴とする請求項３５に記載の方法。
- 解決を妨害する試みにおいて前記ＲＥＳＰＯＮＳＥメッセージが変更されているかどうかを判定するステップは、前記ＲＥＳＰＯＮＳＥメッセージ内の前記アドレスリストのハッシュとしてビット位置を計算するステップと、ビットベクトルを検査し、前記ビット位置に対応するビットがビットベクトル内にセットされているかどうかを判定するステップとを備えたことを特徴とする請求項３７に記載の方法。
- 悪意のあるノードがピアツーピアネットワークから有効ノードを除去することを抑制する方法であって、
キャッシュ内に格納されたピアアドレス証明書（ＰＡＣ）を有する前記有効ノードから、意図的に取消し証明書を受信するステップと、
前記取消し証明書が前記有効ノードによって署名されていることを検証するステップと
を備えたことを特徴とする方法。 - 請求項１に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項４に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項１８に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項２０に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項２５に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項２７に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項３１に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項３３に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項３５に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
- 請求項３９に記載のステップを実行するコンピュータ実行可能命令を有することを特徴とするコンピュータ読取り可能媒体。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/134,780 US7051102B2 (en) | 2002-04-29 | 2002-04-29 | Peer-to-peer name resolution protocol (PNRP) security infrastructure and method |
| US10/134,780 | 2002-04-29 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004030610A true JP2004030610A (ja) | 2004-01-29 |
| JP4716648B2 JP4716648B2 (ja) | 2011-07-06 |
Family
ID=22464960
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003125926A Expired - Fee Related JP4716648B2 (ja) | 2002-04-29 | 2003-04-30 | ピアツーピアネットワークにおいてサービス妨害攻撃を抑制する方法 |
Country Status (17)
| Country | Link |
|---|---|
| US (7) | US7051102B2 (ja) |
| EP (1) | EP1361728B1 (ja) |
| JP (1) | JP4716648B2 (ja) |
| KR (1) | KR100965716B1 (ja) |
| CN (1) | CN100474851C (ja) |
| AU (1) | AU2003203717B2 (ja) |
| BR (1) | BR0301300A (ja) |
| CA (1) | CA2424067C (ja) |
| ES (1) | ES2384964T3 (ja) |
| HK (1) | HK1060459A1 (ja) |
| MX (1) | MXPA03003318A (ja) |
| MY (1) | MY135693A (ja) |
| NO (1) | NO334257B1 (ja) |
| PL (1) | PL359916A1 (ja) |
| RU (1) | RU2320008C2 (ja) |
| TW (1) | TWI310649B (ja) |
| ZA (1) | ZA200302690B (ja) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006279682A (ja) * | 2005-03-30 | 2006-10-12 | Nec Corp | トラフィック制御装置及びトラフィック制御方法並びにプログラム |
| US7379967B2 (en) | 2005-01-28 | 2008-05-27 | Grid Solutions, Inc. | Download method for file by bit torrent protocol |
| JP2009516308A (ja) * | 2005-11-15 | 2009-04-16 | タイヴァーサ・インコーポレーテッド | Ｐ２ｐネットワーク・ソフトウェア・アプリケーションの存在を識別するシステム |
| US8165036B2 (en) | 2006-05-31 | 2012-04-24 | Brother Kogyo Kabushiki Kaisha | Network device, information processing device, and computer readable storage medium therefor |
| US9288216B2 (en) | 2008-06-19 | 2016-03-15 | Qualcomm Incorporated | Methods and apparatus for reducing the effectiveness of chosen location attacks in a peer-to-peer overlay network |
Families Citing this family (142)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7111168B2 (en) * | 2000-05-01 | 2006-09-19 | Digimarc Corporation | Digital watermarking systems |
| WO2002057917A2 (en) * | 2001-01-22 | 2002-07-25 | Sun Microsystems, Inc. | Peer-to-peer network computing platform |
| US7065587B2 (en) * | 2001-04-02 | 2006-06-20 | Microsoft Corporation | Peer-to-peer name resolution protocol (PNRP) and multilevel cache for use therewith |
| US7051102B2 (en) * | 2002-04-29 | 2006-05-23 | Microsoft Corporation | Peer-to-peer name resolution protocol (PNRP) security infrastructure and method |
| AU2003247700A1 (en) * | 2002-07-02 | 2004-01-23 | Netscaler, Inc | System, method and computer program product to avoid server overload by controlling http denial of service (dos) attacks |
| AU2003272404A1 (en) * | 2002-09-16 | 2004-04-30 | Clearcube Technology, Inc. | Distributed computing infrastructure |
| US7613812B2 (en) | 2002-12-04 | 2009-11-03 | Microsoft Corporation | Peer-to-peer identity management interfaces and methods |
| US8261062B2 (en) | 2003-03-27 | 2012-09-04 | Microsoft Corporation | Non-cryptographic addressing |
| US7209929B2 (en) * | 2003-04-17 | 2007-04-24 | Salesforce.Com, Inc. | Java object cache server for databases |
| US7533184B2 (en) * | 2003-06-13 | 2009-05-12 | Microsoft Corporation | Peer-to-peer name resolution wire protocol and message format data structure for use therein |
| US7397922B2 (en) | 2003-06-27 | 2008-07-08 | Microsoft Corporation | Group security |
| US7769866B2 (en) | 2003-07-14 | 2010-08-03 | Microsoft Corporation | Virtual connectivity with subscribe-notify service |
| US7581010B2 (en) * | 2003-07-14 | 2009-08-25 | Microsoft Corporation | Virtual connectivity with local connection translation |
| US7516482B2 (en) * | 2003-07-21 | 2009-04-07 | Microsoft Corporation | Secure hierarchical namespaces in peer-to-peer networks |
| US7188254B2 (en) * | 2003-08-20 | 2007-03-06 | Microsoft Corporation | Peer-to-peer authorization method |
| WO2005020897A2 (en) | 2003-08-22 | 2005-03-10 | Dendreon Corporation | Compositions and methods for the treatment of disease associated with trp-p8 expression |
| WO2005022397A1 (en) * | 2003-08-28 | 2005-03-10 | Trihedron Co., Ltd. | Method of data synchronization in multiplayer network games |
| US7336623B2 (en) * | 2003-10-30 | 2008-02-26 | Microsoft Corporation | Peer-to-peer cloud-split detection and repair methods |
| US8156175B2 (en) | 2004-01-23 | 2012-04-10 | Tiversa Inc. | System and method for searching for specific types of people or information on a peer-to-peer network |
| US7761569B2 (en) | 2004-01-23 | 2010-07-20 | Tiversa, Inc. | Method for monitoring and providing information over a peer to peer network |
| US7716726B2 (en) | 2004-02-13 | 2010-05-11 | Microsoft Corporation | System and method for protecting a computing device from computer exploits delivered over a networked environment in a secured communication |
| US7603716B2 (en) | 2004-02-13 | 2009-10-13 | Microsoft Corporation | Distributed network security service |
| US7814543B2 (en) | 2004-02-13 | 2010-10-12 | Microsoft Corporation | System and method for securing a computer system connected to a network from attacks |
| US7392295B2 (en) * | 2004-02-19 | 2008-06-24 | Microsoft Corporation | Method and system for collecting information from computer systems based on a trusted relationship |
| US7467303B2 (en) * | 2004-03-25 | 2008-12-16 | International Business Machines Corporation | Grid mutual authorization through proxy certificate generation |
| US7363513B2 (en) * | 2004-04-15 | 2008-04-22 | International Business Machines Corporation | Server denial of service shield |
| US7478120B1 (en) | 2004-04-27 | 2009-01-13 | Xiaohai Zhang | System and method for providing a peer indexing service |
| US7966661B2 (en) * | 2004-04-29 | 2011-06-21 | Microsoft Corporation | Network amplification attack mitigation |
| US20060010251A1 (en) * | 2004-06-16 | 2006-01-12 | Nokia Corporation | Global community naming authority |
| US20060004837A1 (en) * | 2004-06-30 | 2006-01-05 | Genovker Victoria V | Advanced switching peer-to-peer protocol |
| US7929689B2 (en) | 2004-06-30 | 2011-04-19 | Microsoft Corporation | Call signs |
| JP4664050B2 (ja) | 2004-07-01 | 2011-04-06 | 株式会社エヌ・ティ・ティ・ドコモ | 認証ベクトル生成装置、加入者認証モジュール、移動通信システム、認証ベクトル生成方法、演算方法及び加入者認証方法 |
| WO2006018843A2 (en) * | 2004-08-16 | 2006-02-23 | Beinsync Ltd. | A system and method for the synchronization of data across multiple computing devices |
| EP1646205A1 (en) * | 2004-10-08 | 2006-04-12 | Deutsche Thomson-Brandt Gmbh | Method for establishing communication between peer-groups |
| US7716727B2 (en) | 2004-10-29 | 2010-05-11 | Microsoft Corporation | Network security device and method for protecting a computing device in a networked environment |
| US20060136512A1 (en) * | 2004-12-20 | 2006-06-22 | International Business Machines Corporation | Method and system for replicating data between a community of distributed entities |
| US7647394B2 (en) * | 2005-02-15 | 2010-01-12 | Microsoft Corporation | Scaling UPnP v1.0 device eventing using peer groups |
| US7640329B2 (en) * | 2005-02-15 | 2009-12-29 | Microsoft Corporation | Scaling and extending UPnP v1.0 device discovery using peer groups |
| US20060193265A1 (en) * | 2005-02-25 | 2006-08-31 | Microsoft Corporation | Peer-to-peer name resolution protocol with lightweight traffic |
| US7826396B2 (en) * | 2005-03-07 | 2010-11-02 | Miller John L | System and method for implementing PNRP locality |
| US7656810B2 (en) * | 2005-03-25 | 2010-02-02 | Microsoft Corporation | System and method for monitoring and reacting to peer-to-peer network metrics |
| US7350074B2 (en) * | 2005-04-20 | 2008-03-25 | Microsoft Corporation | Peer-to-peer authentication and authorization |
| US7817647B2 (en) * | 2005-04-22 | 2010-10-19 | Microsoft Corporation | Flower-petal resolutions for PNRP |
| US8036140B2 (en) | 2005-04-22 | 2011-10-11 | Microsoft Corporation | Application programming interface for inviting participants in a serverless peer to peer network |
| US7603482B2 (en) * | 2005-04-22 | 2009-10-13 | Microsoft Corporation | DNS compatible PNRP peer name encoding |
| US7836306B2 (en) | 2005-06-29 | 2010-11-16 | Microsoft Corporation | Establishing secure mutual trust using an insecure password |
| US20070011171A1 (en) * | 2005-07-08 | 2007-01-11 | Nurminen Jukka K | System and method for operation control functionality |
| US7467155B2 (en) * | 2005-07-12 | 2008-12-16 | Sand Technology Systems International, Inc. | Method and apparatus for representation of unstructured data |
| EP1934772A4 (en) * | 2005-09-15 | 2010-12-29 | Fringland Ltd | INTEGRATING A MOBILE DEVICE INTO A PEER-TO-PEER NETWORK |
| US8255546B2 (en) * | 2005-09-30 | 2012-08-28 | Microsoft Corporation | Peer name resolution protocol simple application program interface |
| US20070094304A1 (en) * | 2005-09-30 | 2007-04-26 | Horner Richard M | Associating subscription information with media content |
| US8161549B2 (en) * | 2005-11-17 | 2012-04-17 | Patrik Lahti | Method for defending against denial-of-service attack on the IPV6 neighbor cache |
| US20080005562A1 (en) * | 2005-12-13 | 2008-01-03 | Microsoft Corporation | Public key infrastructure certificate entrustment |
| EP1801720A1 (en) * | 2005-12-22 | 2007-06-27 | Microsoft Corporation | Authorisation and authentication |
| EP1826695A1 (en) * | 2006-02-28 | 2007-08-29 | Microsoft Corporation | Secure content descriptions |
| US7680937B2 (en) * | 2005-12-22 | 2010-03-16 | Microsoft Corporation | Content publication |
| US8370928B1 (en) * | 2006-01-26 | 2013-02-05 | Mcafee, Inc. | System, method and computer program product for behavioral partitioning of a network to detect undesirable nodes |
| US7480656B2 (en) | 2006-03-20 | 2009-01-20 | Sony Computer Entertainment America Inc. | Active validation of network devices |
| US8771061B2 (en) * | 2006-03-20 | 2014-07-08 | Sony Computer Entertainment America Llc | Invalidating network devices with illicit peripherals |
| US8622837B2 (en) * | 2006-03-20 | 2014-01-07 | Sony Computer Entertainment America Llc | Managing game metrics and authorizations |
| US20070233832A1 (en) * | 2006-03-30 | 2007-10-04 | Matsushita Electric Industrial Co., Ltd. | Method of distributed hash table node ID collision detection |
| US20070230468A1 (en) * | 2006-03-31 | 2007-10-04 | Matsushita Electric Industrial Co., Ltd. | Method to support mobile devices in a peer-to-peer network |
| US7881223B2 (en) * | 2006-03-31 | 2011-02-01 | Panasonic Corporation | Method for on demand distributed hash table update |
| US8510404B2 (en) * | 2006-04-03 | 2013-08-13 | Kinglite Holdings Inc. | Peer to peer Synchronization system and method |
| US8086842B2 (en) | 2006-04-21 | 2011-12-27 | Microsoft Corporation | Peer-to-peer contact exchange |
| US8041942B2 (en) * | 2006-09-05 | 2011-10-18 | Panasonic Corporation | Robust peer-to-peer networks and methods of use thereof |
| GB2446169A (en) * | 2006-12-01 | 2008-08-06 | David Irvine | Granular accessibility to data in a distributed and/or corporate network |
| US20080137663A1 (en) * | 2006-12-06 | 2008-06-12 | Electronics And Telecommunications Research Institute | Identifier verification method in peer-to-peer networks |
| US8069216B2 (en) * | 2006-12-08 | 2011-11-29 | Motorola Solutions, Inc. | Method and apparatus for alerting nodes of a malicious node in a mobile ad-hoc communication system |
| US8489701B2 (en) * | 2007-01-30 | 2013-07-16 | Microsoft Corporation | Private virtual LAN spanning a public network for connection of arbitrary hosts |
| CA2727548A1 (en) * | 2007-06-11 | 2008-12-18 | Tiversa, Inc. | System and method for advertising on a peer-to-peer network |
| US7991910B2 (en) | 2008-11-17 | 2011-08-02 | Amazon Technologies, Inc. | Updating routing information based on client location |
| US8312541B2 (en) * | 2007-07-17 | 2012-11-13 | Cisco Technology, Inc. | Detecting neighbor discovery denial of service attacks against a router |
| US9088605B2 (en) * | 2007-09-19 | 2015-07-21 | Intel Corporation | Proactive network attack demand management |
| US8935748B2 (en) * | 2007-10-31 | 2015-01-13 | Microsoft Corporation | Secure DNS query |
| CN101436926B (zh) * | 2007-11-16 | 2011-11-16 | 华为技术有限公司 | 一种在p2p网络中防止攻击的方法、网络节点及*** |
| US8464045B2 (en) * | 2007-11-20 | 2013-06-11 | Ncr Corporation | Distributed digital certificate validation method and system |
| US8448218B2 (en) * | 2008-01-17 | 2013-05-21 | Josep Bori | Method and apparatus for a cryptographically assisted computer system designed to deter viruses and malware via enforced accountability |
| US7958261B2 (en) * | 2008-02-14 | 2011-06-07 | Microsoft Corporation | Domain name cache control system generating series of varying nonce-bearing domain names based on a function of time |
| US7865618B2 (en) * | 2008-02-22 | 2011-01-04 | Micorsoft Corporation | Defeating cache resistant domain name systems |
| US7962597B2 (en) | 2008-03-31 | 2011-06-14 | Amazon Technologies, Inc. | Request routing based on class |
| US9198017B2 (en) * | 2008-05-19 | 2015-11-24 | Qualcomm Incorporated | Infrastructure assisted discovery in a wireless peer-to-peer network |
| US9848314B2 (en) | 2008-05-19 | 2017-12-19 | Qualcomm Incorporated | Managing discovery in a wireless peer-to-peer network |
| WO2010045706A1 (en) * | 2008-10-22 | 2010-04-29 | Research In Motion Limited | Pushing certificate chains to remote devices |
| US8498230B2 (en) * | 2009-03-03 | 2013-07-30 | Nokia Corporation | Power management in wireless communication systems |
| US20100226309A1 (en) | 2009-03-03 | 2010-09-09 | Nokia Corporation | Beaconing mode for wireless communication |
| US9055105B2 (en) | 2009-05-29 | 2015-06-09 | Nokia Technologies Oy | Method and apparatus for engaging in a service or activity using an ad-hoc mesh network |
| GB0910657D0 (en) | 2009-06-22 | 2009-08-05 | Unilever Plc | Antiperspirant compositions |
| US8538188B2 (en) * | 2009-08-04 | 2013-09-17 | Mitre Corporation | Method and apparatus for transferring and reconstructing an image of a computer readable medium |
| US8769285B2 (en) * | 2009-08-13 | 2014-07-01 | Qualcomm Incorporated | Methods and apparatus for deriving, communicating and/or verifying ownership of expressions |
| CN101631056A (zh) * | 2009-08-18 | 2010-01-20 | 腾讯科技（深圳）有限公司 | 一种点对点应用中种子群的构建方法及装置 |
| KR101598886B1 (ko) * | 2009-10-13 | 2016-03-03 | 삼성전자주식회사 | 이동통신 단말기에서 무선랜을 이용한 피어투피어 연결 방법 및 장치 |
| US20110142028A1 (en) * | 2009-12-10 | 2011-06-16 | Nokia Corporation | Synchronization via additional beacon transmission |
| US8842605B2 (en) * | 2009-12-10 | 2014-09-23 | Nokia Corporation | Network discovery in wireless communication systems |
| US8774021B2 (en) | 2009-12-10 | 2014-07-08 | Nokia Corporation | Data-related task support in wireless communication systems |
| US8898513B2 (en) * | 2010-05-19 | 2014-11-25 | Cleversafe, Inc. | Storing data in multiple dispersed storage networks |
| US8924304B2 (en) * | 2010-06-04 | 2014-12-30 | Apple Inc. | Methods for using unique identifiers to identify systems in collaborative interaction in a mesh network |
| CN101895541B (zh) * | 2010-07-09 | 2012-12-26 | 浙江省公众信息产业有限公司 | 一种P2P网络中协作抵抗覆盖层DDoS攻击的方法 |
| US8566596B2 (en) * | 2010-08-24 | 2013-10-22 | Cisco Technology, Inc. | Pre-association mechanism to provide detailed description of wireless services |
| US9003035B1 (en) | 2010-09-28 | 2015-04-07 | Amazon Technologies, Inc. | Point of presence management in request routing |
| US9636589B2 (en) | 2010-11-02 | 2017-05-02 | Sony Interactive Entertainment America Llc | Detecting lag switch cheating in game |
| KR101225013B1 (ko) * | 2010-12-29 | 2013-02-07 | (주)트라이디커뮤니케이션 | 리소스 제공 시스템 및 방법 |
| US10467042B1 (en) | 2011-04-27 | 2019-11-05 | Amazon Technologies, Inc. | Optimized deployment based upon customer locality |
| US8806192B2 (en) * | 2011-05-04 | 2014-08-12 | Microsoft Corporation | Protected authorization for untrusted clients |
| US8964741B2 (en) * | 2011-06-21 | 2015-02-24 | Cisco Technology, Inc. | Adjacency discovery through multicast and single-hop messaging |
| KR101796532B1 (ko) * | 2011-06-22 | 2017-11-10 | 삼성전자주식회사 | 수면 모드 제어를 통한 에너지 절감 시스템 및 시스템의 동작 방법 |
| US8874769B2 (en) * | 2011-06-30 | 2014-10-28 | Qualcomm Incorporated | Facilitating group access control to data objects in peer-to-peer overlay networks |
| US9021278B2 (en) * | 2011-08-10 | 2015-04-28 | Qualcomm Incorporated | Network association of communication devices based on attenuation information |
| US8804589B2 (en) | 2011-10-14 | 2014-08-12 | Nokia Corporation | Adaptive awake window |
| CN102368740A (zh) * | 2011-12-01 | 2012-03-07 | 北京交通大学 | 一种网络寻址方法 |
| US9154551B1 (en) | 2012-06-11 | 2015-10-06 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
| TWI476626B (zh) | 2012-08-24 | 2015-03-11 | Ind Tech Res Inst | 電子裝置之認證方法及密碼設定方法及認證系統 |
| US9042828B2 (en) | 2012-11-26 | 2015-05-26 | Nokia Corporation | Method, apparatus, and computer program product for optimized discovery between mobile devices |
| US9154483B1 (en) * | 2013-02-21 | 2015-10-06 | Amazon Technologies, Inc. | Secure device configuration |
| US9294563B2 (en) * | 2013-02-27 | 2016-03-22 | Omnivision Technologies, Inc. | Apparatus and method for level-based self-adjusting peer-to-peer media streaming |
| US9294365B2 (en) | 2013-05-08 | 2016-03-22 | Vringo, Inc. | Cognitive radio system and cognitive radio carrier device |
| CN104348614B (zh) * | 2013-07-24 | 2019-02-01 | 腾讯科技（深圳）有限公司 | 身份合法性验证的方法、装置及服务器 |
| CN103619011B (zh) * | 2013-11-21 | 2016-08-03 | 东南大学 | 一种无线传感器网络中的恶意节点容忍方法 |
| US9485145B1 (en) * | 2013-11-25 | 2016-11-01 | Vce Company, Llc | System, method, apparatus, and computer program product for determining a configuration of a converged infrastructure |
| US9794218B2 (en) | 2014-04-29 | 2017-10-17 | Trustiosity, Llc | Persistent network addressing system and method |
| US10097448B1 (en) | 2014-12-18 | 2018-10-09 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
| US9832141B1 (en) | 2015-05-13 | 2017-11-28 | Amazon Technologies, Inc. | Routing based request correlation |
| US20160335609A1 (en) * | 2015-05-15 | 2016-11-17 | Gareth Jenkins | Representation of digital asset structure, ownership and evolution by virtue of a hierarchical, compounding tagging mechanism on a transaction-based network |
| US9673937B2 (en) * | 2015-10-12 | 2017-06-06 | International Business Machines Corporation | Adaptive network communication protocols |
| US10075551B1 (en) | 2016-06-06 | 2018-09-11 | Amazon Technologies, Inc. | Request management for hierarchical cache |
| US10110694B1 (en) | 2016-06-29 | 2018-10-23 | Amazon Technologies, Inc. | Adaptive transfer rate for retrieving content from a server |
| US10349259B2 (en) * | 2016-09-23 | 2019-07-09 | Apple Inc. | Broadcasting a device state in a wireless communication network |
| US10616250B2 (en) * | 2016-10-05 | 2020-04-07 | Amazon Technologies, Inc. | Network addresses with encoded DNS-level information |
| DE102016219475A1 (de) * | 2016-10-07 | 2018-04-12 | Robert Bosch Gmbh | Verfahren und Vorrichtung zum Betreiben eines Bussystems |
| US10831549B1 (en) | 2016-12-27 | 2020-11-10 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
| US10601591B2 (en) * | 2017-01-25 | 2020-03-24 | Microsoft Technology Licensing, Llc | Close proximity inner circle discovery |
| WO2018216671A1 (ja) | 2017-05-23 | 2018-11-29 | 大正製薬株式会社 | 飴 |
| EP3506547A1 (en) * | 2017-12-28 | 2019-07-03 | Flytxt B.V. | Providing security against user collusion in data analytics using random group selection |
| KR102651436B1 (ko) | 2018-11-02 | 2024-03-25 | 아싸 아브로이 에이비 | 액세스 제어를 위한 시스템들, 방법들, 및 디바이스들 |
| US10841393B2 (en) * | 2018-11-12 | 2020-11-17 | Citrix Systems, Inc. | Systems and methods for secure peer-to-peer caching |
| KR102650599B1 (ko) | 2019-03-25 | 2024-03-21 | 아싸 아브로이 에이비 | 액세스 제어 판독기 시스템을 위한 초광대역 디바이스 |
| CN118135693A (zh) | 2019-03-25 | 2024-06-04 | 亚萨合莱有限公司 | 具有基于定位的意图检测的物理访问控制*** |
| US11102243B1 (en) * | 2019-06-26 | 2021-08-24 | Amazon Technologies, Inc. | Resource address resolution based on resource ownership changes to block communications with computing resources |
| WO2021003450A1 (en) * | 2019-07-04 | 2021-01-07 | Vikatron, Inc. | Ad hoc neural network for proof of wallet |
| GB2594684A (en) | 2020-02-19 | 2021-11-10 | Nchain Holdings Ltd | Layered network |
| CN111414321B (zh) * | 2020-02-24 | 2022-07-15 | 中国农业大学 | 一种基于动态映射机制的cache防护方法及装置 |
| CN114118811A (zh) * | 2021-11-29 | 2022-03-01 | 深圳壹账通智能科技有限公司 | 服务代码的生成、执行方法、装置、设备及存储介质 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08249249A (ja) * | 1995-03-08 | 1996-09-27 | Nippon Telegr & Teleph Corp <Ntt> | メッセージ中継装置及びメッセージ中継方法 |
| JPH11122283A (ja) * | 1997-10-15 | 1999-04-30 | Toshiba Corp | ネットワーク管理システム |
| JP2000057112A (ja) * | 1998-08-11 | 2000-02-25 | Fuji Xerox Co Ltd | ネットワーク上で遠隔手続き呼び出しを実行するための方法、及び、遠隔手続き呼び出しを実行可能なネットワーク・システム |
| JP2001202014A (ja) * | 1999-12-02 | 2001-07-27 | Sony Internatl Europ Gmbh | データ認証方法、メッセージ伝送方法及び分散型システム |
| JP2002057701A (ja) * | 2000-08-07 | 2002-02-22 | Bitto Aato:Kk | マルチメディア通信方法および装置 |
| JP2002064495A (ja) * | 2000-08-21 | 2002-02-28 | Nippon Telegraph & Telephone East Corp | ネットワークシステム、及びネットワーク管理方法 |
| JP2002111713A (ja) * | 2000-09-28 | 2002-04-12 | Toshiba Corp | ネットワークシステム、ネームサーバ、サーバ、およびネットワークシステムのｉｐ通信方法 |
Family Cites Families (70)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP0449242A3 (en) * | 1990-03-28 | 1992-10-28 | National Semiconductor Corporation | Method and structure for providing computer security and virus prevention |
| US5999711A (en) * | 1994-07-18 | 1999-12-07 | Microsoft Corporation | Method and system for providing certificates holding authentication and authorization information for users/machines |
| JP3724001B2 (ja) * | 1994-12-12 | 2005-12-07 | 富士通株式会社 | 情報処理装置 |
| US6223255B1 (en) * | 1995-02-03 | 2001-04-24 | Lucent Technologies | Microprocessor with an instruction level reconfigurable n-way cache |
| US5666486A (en) * | 1995-06-23 | 1997-09-09 | Data General Corporation | Multiprocessor cluster membership manager framework |
| US5671279A (en) * | 1995-11-13 | 1997-09-23 | Netscape Communications Corporation | Electronic commerce using a secure courier system |
| US5793365A (en) * | 1996-01-02 | 1998-08-11 | Sun Microsystems, Inc. | System and method providing a computer user interface enabling access to distributed workgroup members |
| US6167279A (en) * | 1996-03-13 | 2000-12-26 | Telcordia Technologies, Inc. | Method and system for supporting PACS using a GSM mobile switching center |
| US5832514A (en) * | 1996-06-26 | 1998-11-03 | Microsoft Corporation | System and method for discovery based data recovery in a store and forward replication process |
| US6046833A (en) * | 1997-02-10 | 2000-04-04 | Optical Networks, Inc. | Method and apparatus for operation, protection, and restoration of heterogeneous optical communication networks |
| US5987376A (en) | 1997-07-16 | 1999-11-16 | Microsoft Corporation | System and method for the distribution and synchronization of data and state information between clients in a distributed processing system |
| US6557102B1 (en) * | 1997-09-05 | 2003-04-29 | Koninklijke Philips Electronics N.V. | Digital trust center for medical image authentication |
| US6130876A (en) * | 1997-09-24 | 2000-10-10 | At&T Corp | Method and apparatus for restoring a network |
| US6061794A (en) * | 1997-09-30 | 2000-05-09 | Compaq Computer Corp. | System and method for performing secure device communications in a peer-to-peer bus architecture |
| US6038296A (en) * | 1997-10-07 | 2000-03-14 | Lucent Technologies Inc. | Internet/intranet user interface to a multimedia messaging system |
| US5999712A (en) * | 1997-10-21 | 1999-12-07 | Sun Microsystems, Inc. | Determining cluster membership in a distributed computer system |
| US20010037453A1 (en) * | 1998-03-06 | 2001-11-01 | Mitty Todd Jay | Secure electronic transactions using a trusted intermediary with non-repudiation of receipt and contents of message |
| US6161181A (en) * | 1998-03-06 | 2000-12-12 | Deloitte & Touche Usa Llp | Secure electronic transactions using a trusted intermediary |
| US6199052B1 (en) * | 1998-03-06 | 2001-03-06 | Deloitte & Touche Usa Llp | Secure electronic transactions using a trusted intermediary with archive and verification request services |
| US6718470B1 (en) * | 1998-06-05 | 2004-04-06 | Entrust Technologies Limited | System and method for granting security privilege in a communication system |
| US6314501B1 (en) * | 1998-07-23 | 2001-11-06 | Unisys Corporation | Computer system and method for operating multiple operating systems in different partitions of the computer system and for allowing the different partitions to communicate with one another through shared memory |
| GB9822550D0 (en) * | 1998-10-15 | 1998-12-09 | British Telecomm | Computer communications |
| US6233606B1 (en) * | 1998-12-01 | 2001-05-15 | Microsoft Corporation | Automatic cache synchronization |
| US6480473B1 (en) * | 1998-12-29 | 2002-11-12 | Koninklijke Philips Electronics N.V. | Verification of active nodes in an open network |
| US6507908B1 (en) * | 1999-03-04 | 2003-01-14 | Sun Microsystems, Inc. | Secure communication with mobile hosts |
| US6513062B1 (en) * | 1999-05-25 | 2003-01-28 | Grischa Corporation | Method, apparatus, and computer program product for efficient server response generation using intermediate state caching |
| US6532494B1 (en) * | 1999-05-28 | 2003-03-11 | Oracle International Corporation | Closed-loop node membership monitor for network clusters |
| US6405290B1 (en) * | 1999-06-24 | 2002-06-11 | International Business Machines Corporation | Multiprocessor system bus protocol for O state memory-consistent data |
| US6397303B1 (en) * | 1999-06-24 | 2002-05-28 | International Business Machines Corporation | Data processing system, cache, and method of cache management including an O state for memory-consistent cache lines |
| KR20020021404A (ko) * | 1999-08-12 | 2002-03-20 | 윌리암 제이. 버크 | 피어-투-피어 네트워크 사용자 인증 프로토콜 |
| US6704692B1 (en) * | 1999-10-25 | 2004-03-09 | The Boeing Company | Method and system for tracking multiple objects |
| US7107347B1 (en) * | 1999-11-15 | 2006-09-12 | Fred Cohen | Method and apparatus for network deception/emulation |
| US20020056025A1 (en) * | 2000-11-07 | 2002-05-09 | Qiu Chaoxin C. | Systems and methods for management of memory |
| US6973040B1 (en) * | 2000-03-13 | 2005-12-06 | Netzentry, Inc. | Method of maintaining lists of network characteristics |
| EP1134644A3 (en) * | 2000-03-14 | 2004-08-18 | International Business Machines Corporation | Method and system for verifying access to a network environment |
| US20020032592A1 (en) * | 2000-04-17 | 2002-03-14 | Steve Krasnick | Online meeting planning program |
| WO2001084285A2 (en) * | 2000-04-28 | 2001-11-08 | Internet Security Systems, Inc. | Method and system for managing computer security information |
| US20010051927A1 (en) * | 2000-06-08 | 2001-12-13 | Blinkspeed, Inc. | Increasing web page browsing efficiency by periodically physically distributing memory media on which web page data are cached |
| US6738868B2 (en) * | 2000-06-10 | 2004-05-18 | Hewlett-Packard Development Company, L.P. | System for minimizing directory information in scalable multiprocessor systems with logically independent input/output nodes |
| US7107269B2 (en) * | 2000-06-13 | 2006-09-12 | Lucent Technologies Inc. | Methods and apparatus for providing privacy-preserving global customization |
| US6941384B1 (en) * | 2000-08-17 | 2005-09-06 | International Business Machines Corporation | Methods, systems and computer program products for failure recovery for routed virtual internet protocol addresses |
| US6636854B2 (en) * | 2000-12-07 | 2003-10-21 | International Business Machines Corporation | Method and system for augmenting web-indexed search engine results with peer-to-peer search results |
| US7333482B2 (en) * | 2000-12-22 | 2008-02-19 | Interactive People Unplugged Ab | Route optimization technique for mobile IP |
| US6941366B2 (en) * | 2001-01-17 | 2005-09-06 | International Business Machines Corporation | Methods, systems and computer program products for transferring security processing between processors in a cluster computing environment |
| US7146432B2 (en) * | 2001-01-17 | 2006-12-05 | International Business Machines Corporation | Methods, systems and computer program products for providing failure recovery of network secure communications in a cluster computing environment |
| US7209479B2 (en) * | 2001-01-18 | 2007-04-24 | Science Application International Corp. | Third party VPN certification |
| US20020161850A1 (en) | 2001-01-29 | 2002-10-31 | Ulrich Thomas R. | Data path accelerator for storage systems |
| US7065587B2 (en) | 2001-04-02 | 2006-06-20 | Microsoft Corporation | Peer-to-peer name resolution protocol (PNRP) and multilevel cache for use therewith |
| WO2002084948A1 (en) | 2001-04-05 | 2002-10-24 | Imahima, Inc. | Real-time mobile communication system for chatting |
| US7721110B2 (en) * | 2001-04-06 | 2010-05-18 | Mcafee, Inc. | System and method for secure and verified sharing of resources in a peer-to-peer network environment |
| US7272636B2 (en) * | 2001-04-24 | 2007-09-18 | Sun Microsystems, Inc. | Peer group name server |
| US6950821B2 (en) * | 2001-05-04 | 2005-09-27 | Sun Microsystems, Inc. | System and method for resolving distributed network search queries to information providers |
| US7171415B2 (en) * | 2001-05-04 | 2007-01-30 | Sun Microsystems, Inc. | Distributed information discovery through searching selected registered information providers |
| US7031314B2 (en) * | 2001-05-16 | 2006-04-18 | Bytemobile, Inc. | Systems and methods for providing differentiated services within a network communication system |
| US7028179B2 (en) * | 2001-07-03 | 2006-04-11 | Intel Corporation | Apparatus and method for secure, automated response to distributed denial of service attacks |
| US7299351B2 (en) * | 2001-09-19 | 2007-11-20 | Microsoft Corporation | Peer-to-peer name resolution protocol (PNRP) security infrastructure and method |
| US20030097410A1 (en) * | 2001-10-04 | 2003-05-22 | Atkins R. Travis | Methodology for enabling multi-party collaboration across a data network |
| US7047564B2 (en) * | 2001-10-31 | 2006-05-16 | Computing Services Support Solutions, Inc. | Reverse firewall packet transmission control system |
| US20030177190A1 (en) * | 2001-11-27 | 2003-09-18 | International Business Machines Corporation | Method and apparatus for interaction with electronic mail from multiple sources |
| US7076803B2 (en) * | 2002-01-28 | 2006-07-11 | International Business Machines Corporation | Integrated intrusion detection services |
| US7051049B2 (en) * | 2002-02-21 | 2006-05-23 | International Business Machines Corporation | Real-time chat and conference contact information manager |
| US6912622B2 (en) * | 2002-04-15 | 2005-06-28 | Microsoft Corporation | Multi-level cache architecture and cache management method for peer-to-peer name resolution protocol |
| US7206862B2 (en) * | 2002-04-24 | 2007-04-17 | Microsoft Corporation | Method and apparatus for efficiently matching responses to requests previously passed by a network node |
| US7051102B2 (en) * | 2002-04-29 | 2006-05-23 | Microsoft Corporation | Peer-to-peer name resolution protocol (PNRP) security infrastructure and method |
| US20040145608A1 (en) | 2003-01-24 | 2004-07-29 | International Business Machines Corporation | User interface for conducting chats over a network |
| JP2004302751A (ja) * | 2003-03-31 | 2004-10-28 | Hitachi Ltd | 計算機システムの性能管理方法、および、記憶装置の性能を管理する計算機システム |
| NO318975B1 (no) * | 2003-06-20 | 2005-05-30 | Tandberg Telecom As | System og fremgangsmate for oppsett av moter og konferanser |
| US8001187B2 (en) * | 2003-07-01 | 2011-08-16 | Apple Inc. | Peer-to-peer active content sharing |
| US20050027800A1 (en) * | 2003-07-28 | 2005-02-03 | International Business Machines Corporation | Agenda-driven meetings |
| WO2005029372A1 (en) | 2003-09-25 | 2005-03-31 | Synthetron Nv | Method and apparatus for scalable meetings in a discussion synthesis environment |
-
2002
- 2002-04-29 US US10/134,780 patent/US7051102B2/en not_active Expired - Fee Related
-
2003
- 2003-04-01 MY MYPI20031209A patent/MY135693A/en unknown
- 2003-04-01 CA CA2424067A patent/CA2424067C/en not_active Expired - Fee Related
- 2003-04-02 NO NO20031496A patent/NO334257B1/no not_active IP Right Cessation
- 2003-04-07 ES ES03007907T patent/ES2384964T3/es not_active Expired - Lifetime
- 2003-04-07 EP EP03007907A patent/EP1361728B1/en not_active Expired - Lifetime
- 2003-04-07 TW TW092107940A patent/TWI310649B/zh not_active IP Right Cessation
- 2003-04-07 ZA ZA200302690A patent/ZA200302690B/xx unknown
- 2003-04-14 AU AU2003203717A patent/AU2003203717B2/en not_active Ceased
- 2003-04-15 MX MXPA03003318A patent/MXPA03003318A/es active IP Right Grant
- 2003-04-21 KR KR1020030025170A patent/KR100965716B1/ko not_active IP Right Cessation
- 2003-04-24 RU RU2003112059/09A patent/RU2320008C2/ru not_active IP Right Cessation
- 2003-04-24 BR BR0301300-6A patent/BR0301300A/pt not_active Application Discontinuation
- 2003-04-29 PL PL03359916A patent/PL359916A1/xx not_active Application Discontinuation
- 2003-04-29 CN CNB031241549A patent/CN100474851C/zh not_active Expired - Fee Related
- 2003-04-30 JP JP2003125926A patent/JP4716648B2/ja not_active Expired - Fee Related
-
2004
- 2004-05-12 HK HK04103318.5A patent/HK1060459A1/xx not_active IP Right Cessation
-
2006
- 2006-03-15 US US11/375,748 patent/US7251694B2/en not_active Expired - Fee Related
- 2006-03-15 US US11/375,749 patent/US7720962B2/en not_active Expired - Fee Related
- 2006-03-15 US US11/376,397 patent/US7418479B2/en not_active Expired - Fee Related
- 2006-03-15 US US11/375,726 patent/US7444372B2/en not_active Expired - Fee Related
-
2008
- 2008-06-13 US US12/138,421 patent/US7725567B2/en not_active Expired - Fee Related
- 2008-06-13 US US12/138,419 patent/US7680930B2/en not_active Expired - Fee Related
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH08249249A (ja) * | 1995-03-08 | 1996-09-27 | Nippon Telegr & Teleph Corp <Ntt> | メッセージ中継装置及びメッセージ中継方法 |
| JPH11122283A (ja) * | 1997-10-15 | 1999-04-30 | Toshiba Corp | ネットワーク管理システム |
| JP2000057112A (ja) * | 1998-08-11 | 2000-02-25 | Fuji Xerox Co Ltd | ネットワーク上で遠隔手続き呼び出しを実行するための方法、及び、遠隔手続き呼び出しを実行可能なネットワーク・システム |
| JP2001202014A (ja) * | 1999-12-02 | 2001-07-27 | Sony Internatl Europ Gmbh | データ認証方法、メッセージ伝送方法及び分散型システム |
| JP2002057701A (ja) * | 2000-08-07 | 2002-02-22 | Bitto Aato:Kk | マルチメディア通信方法および装置 |
| JP2002064495A (ja) * | 2000-08-21 | 2002-02-28 | Nippon Telegraph & Telephone East Corp | ネットワークシステム、及びネットワーク管理方法 |
| JP2002111713A (ja) * | 2000-09-28 | 2002-04-12 | Toshiba Corp | ネットワークシステム、ネームサーバ、サーバ、およびネットワークシステムのｉｐ通信方法 |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7379967B2 (en) | 2005-01-28 | 2008-05-27 | Grid Solutions, Inc. | Download method for file by bit torrent protocol |
| JP2006279682A (ja) * | 2005-03-30 | 2006-10-12 | Nec Corp | トラフィック制御装置及びトラフィック制御方法並びにプログラム |
| JP4572719B2 (ja) * | 2005-03-30 | 2010-11-04 | 日本電気株式会社 | トラフィック制御装置及びトラフィック制御方法並びにプログラム |
| JP2009516308A (ja) * | 2005-11-15 | 2009-04-16 | タイヴァーサ・インコーポレーテッド | Ｐ２ｐネットワーク・ソフトウェア・アプリケーションの存在を識別するシステム |
| US8165036B2 (en) | 2006-05-31 | 2012-04-24 | Brother Kogyo Kabushiki Kaisha | Network device, information processing device, and computer readable storage medium therefor |
| US9288216B2 (en) | 2008-06-19 | 2016-03-15 | Qualcomm Incorporated | Methods and apparatus for reducing the effectiveness of chosen location attacks in a peer-to-peer overlay network |
Also Published As
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4716648B2 (ja) | ピアツーピアネットワークにおいてサービス妨害攻撃を抑制する方法 | |
| US7299351B2 (en) | Peer-to-peer name resolution protocol (PNRP) security infrastructure and method | |
| KR101021360B1 (ko) | 피어 투 피어 네임 레졸루션 와이어 프로토콜 및 프로토콜에 사용하기 위한 메세지 포맷 데이터 구조를 생성 및 발송하기 위한 방법 및 컴퓨터 판독가능 기록매체 | |
| US7068789B2 (en) | Peer-to-peer name resolution protocol (PNRP) group security infrastructure and method | |
| JP4944845B2 (ja) | インターネットプロトコルのアドレス機構 | |
| JP5291725B2 (ja) | Ｉｐアドレス委任 | |
| Liu et al. | Secure name resolution for identifier-to-locator mappings in the global internet | |
| Sethom et al. | A secure P2P architecture for location management | |
| Hammouda et al. | An enhanced secure ARP protocol and LAN switch for preveting ARP based attacks |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060227 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090626 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090928 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20100625 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20100927 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20101203 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110303 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20110318 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20110329 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140408 Year of fee payment: 3 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |