認証方法および認証フレームワーク
アドホックなネットワーク内の認証が、第１のデバイス（例えばサービス要求デバイス）と第２のデバイス（例えばサービス提供デバイス）の間で、第３のデバイス（ピアデバイス）を使用して確立される。前記第１のデバイスから前記第２のデバイスに認証要求が送信される。前記第２のデバイスが、少なくとも１台の第３のデバイス（すなわちピアデバイス）に問い合せメッセージを送信する。前記ピアデバイスが前記第１のデバイスによって以前に認証されている場合、前記ピアデバイスは、前記第１のデバイスと前記第２のデバイスとに認証資格証明（例えば認証キー）を送信する。前記第１のデバイスは、前記認証資格証明を受信すると、前記第２のデバイスに前記認証資格証明を送信する。次に、前記第２のデバイスは、前記第１のデバイスから受信した前記認証資格証明と、前記第３のデバイスから受信した前記認証資格証明とを比較して、前記認証資格証明同士が一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証する。好ましくは、前記第３の（ピア）デバイスから前記第１のデバイスに送信される前記認証資格証明が暗号化される。
【代表図】図４
【代表図】図４
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証方法および認証フレームワークに関し、より詳細には、超広帯域通信ネットワークなどの無線通信ネットワークにおけるピアツーピアの分散認証フレームワークおよびそのための方法に関する。
【背景技術】
【０００２】
超広帯域とは、極めて広い周波数範囲（３．１〜１０．６ＧＨｚ）にわたってデジタルデータを伝送する無線技術である。広い帯域幅に無線周波数エネルギーを拡散させると、送信信号が、従来の周波数選択無線周波数技術では事実上検出不可能となる。しかし、送信電力が低いため、通信距離が通常１０〜１５ｍ未満に制限される。
【０００３】
超広帯域（ＵＷＢ）には、ＵＷＢ特性によってパルス波形から信号を構成する時間領域のアプローチと、複数の（周波数）バンドにわたって従来のＦＦＴをベースとした直交波周波数分割多重（ＯＦＤＭ）を使用し、ＭＢ−ＯＦＤＭを与える周波数領域変調のアプローチの２つのアプローチがある。この２つのＵＷＢのアプローチは、周波数スペクトル内に、極めて広い帯域幅にまたがるスペクトル成分を生じさせ（このため超広帯域と呼ばれている）、この帯域幅は、中心周波数の２０パーセント超、通常は少なくとも５００ＭＨｚを占める。
【０００４】
このような超広帯域の特性と、極めて広い帯域幅とにより、ＵＷＢは、通信しているデバイス同士が１０〜１５ｍの範囲にあるホーム環境またはオフィス環境に高速無線通信を提供する理想的な技術となる。
【０００５】
図１は、超広帯域通信のためのマルチバンド直交周波数分割多重（ＭＢ−ＯＦＤＭ）システムにおける周波数バンドの構成を示す。ＭＢ−ＯＦＤＭシステムは、それぞれ５２８ＭＨｚの１４のサブバンドを含み、アクセス方式として、各サブバンド間に３１２.５ナノ秒の周波数ホッピングを使用している。各サブバンド内では、データの伝送にＯＦＤＭおよびＱＰＳＫまたはＤＣＭ符号化が使用される。なお、５ＧＨｚを中心としたサブバンド（現在では５．１〜５．８ＧＨｚ）は、例えば８０２．１１ａＷＬＡＮシステム、保安機関の通信システムまたは航空産業などの既存の狭帯域システムとの干渉を避けるために使用されていない。
【０００６】
１４のサブバンドは、５つのバンドグループに編成されており、そのうち４つのバンドグループは５２８ＭＨｚのサブバンドを３つ有するが、１つのバンドグループは、５２８ＭＨｚのサブバンドを２つ有する。図１に示すように、第１のバンドグループは、サブバンド１、サブバンド２およびサブバンド３を有する。例として挙げるＵＷＢシステムは、バンドグループのサブバンド間に周波数ホッピングを使用しており、第１の３１２．５ナノ秒の時間インターバルに、第１のデータシンボルがバンドグループの第１の周波数サブバンドで送信され、第２の３１２．５ナノ秒の時間インターバルに、第２のデータシンボルがバンドグループの第２の周波数サブバンドで送信され、第３の３１２．５ナノ秒の時間インターバルに、第３のデータシンボルがバンドグループの第３の周波数サブバンドで送信される。このため、各時間インターバルの間に、データシンボルが、帯域幅５２８ＭＨｚのそれぞれのサブバンド（例えば、中心周波数３９６０ＭＨｚの５２８ＭＨｚのベースバンド信号を含むサブバンド２）で送信される。
【０００７】
各データシンボルが送信される３つの周波数のシーケンスは、時間周波数符号（ＴＦＣ）チャネルを表す。第１のＴＦＣチャネルは、シーケンス１、２、３、１、２、３と続き、１が第１のサブバンド、２が第２のサブバンド、３が第３のサブバンドである。第２および第３のＴＦＣチャネルは、それぞれシーケンス１、３、２、１、３、２、および１、１、２、２、３、３と続きうる。ＥＣＭＡ−３６８規格によれば、最初の４つのバンドグループのそれぞれに７つのＴＦＣチャネルが定義されており、５番目のバンドグループに２つのＴＦＣチャネルが定義されている。
【０００８】
超広帯域の技術的な性質は、データ通信の分野において各種用途に利用されつつあるということである。例えば、以下の環境において、ケーブルの代替として注目した、さまざまな用途が存在する。
−ＰＣと、周辺機器、すなわち外部デバイス（ハードディスクドライブ、ＣＤライタ、プリンタ、スキャナなど）との間の通信
−無線手段によって接続されたテレビとデバイス、無線スピーカなどのホームエンターテイメント
−例えば、携帯電話、ＰＤＡなどのハンドへルドデバイスおよびＰＣ、デジタルカメラ、ＭＰ３プレーヤなどの間の通信
【０００９】
ＵＷＢネットワークなどの無線ネットワークでは、１台以上のデバイスが、ビーコン期間中に定期的にビーコンフレームを送信する。ビーコンフレームの主な目的は、媒体にタイミング構造を提供すること、すなわち、時間を、いわゆるスーパーフレームに分割して、ネットワークのデバイスが、近くのデバイスと同期できるようにすることにある。
【００１０】
図２に示すように、ＵＷＢシステムの基本的なタイミング構造は、スーパーフレームである。欧州電子計算機工業会（ＥＣＭＡ）（ＥＣＭＡ−３６８第２版）によるスーパーフレームは、それぞれが定義済みの期間（例えば２５６マイクロ秒）を有する２５６のメディアアクセススロット（ＭＡＳ）からなる。各スーパーフレームは、１つのビーコン期間で開始し、１以上の隣接するＭＡＳの間続く。ビーコン期間を形成している各ＭＡＳは、３つのビーコンスロットを含み、ビーコンスロットにおいてデバイスが自身の個々のビーコンフレームを送信する。ビーコン期間の先頭のＭＡＳの始点は、「ビーコン期間の始点（ＢＰＳＴ）」と呼ばれている。特定のデバイスのビーコングループは、その特定のデバイスとビーコン期間の始点を共有（±１マイクロ秒）しており、その特定のデバイスの送信範囲に存在するデバイスのグループとして定義される。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上で説明したＵＷＢシステムなどの無線システムは、アドホックのピアツーピア構成で使用される場合が増えている。つまり、ネットワークが中心的な制御または組織を持たずに存在しており、各デバイスが、範囲内の全ての他のデバイスと通信する可能性があるということである。このアプローチには、自発性と柔軟な対話などのいくつかの利点もある。しかし、このような柔軟な構成は、解決の必要のあるほかの問題も引き起こす。
【００１２】
例えば、監督する権限（authority）が存在しないため、ネットワーク内の個々のデバイスまたはユーザが、このような権限が担うべき役割を負わなければならない。多くのタスクでは、これは各デバイスが独立して行うことができるが、タスクのなかにはこれが機能できないものもある。従来の一元化された認証アーキテクチャは、アドホックなネットワークでは機能できない点に留意することが特に重要である。これは、中央のセキュリティサーバとして動作させるに足る信頼できるピアが存在しないためである。
【００１３】
「認証」とは、デバイスまたはユーザの「識別情報」を検査して検証するプロセスでり、偽装攻撃に対抗するために必要とされる。図３は、複数の個々のデバイスまたはユーザ４（Ａ〜Ｃで示す）を有するネットワーク２において認証を与えるための従来のアプローチを示す。この従来のアプローチに係る認証は、中央の認証サーバ「Ｄ」（例えばＡｐａｃｈｅなどのウェブサーバアプリケーションまたはＵＮＩＸ上のログインサーバ）のメモリ５に識別情報（例えばユーザ名およびパスワード）のリストと、各識別情報の所有者が保持する資格証明（credential）とを記憶することによって実行される。次に、別のユーザ「Ｂ」に対して自身の識別情報を証明したいユーザ「Ａ」が、認証サーバＤに自身の資格証明を提供し、認証サーバＤは、その資格証明の妥当性を「Ｂ」に通知する。このアプローチは、「Ａ」と「Ｂ」の両方が「Ｄ」を信頼している場合（Ｄがネットワークのコントローラによって実行されている場合に多い）には、認証を与える非常に単純かつ有効な方法である。このようなシステムでは、サービス提供デバイスが、ユーザごとに認証を実行し、要求ごとに認可を実行する必要がある。
【００１４】
アドホックなピアツーピアネットワークには、Ｄのような信頼されたサーバが１台も存在しないため、この役割を果たすことができない。更に、認証資格証明のリストが複数必要となり、セットアップ段階を完了してから各サービスを使用しなければならないことになる。このように資格証明を事前に共有することは、長期の使用には適切であるが、アドホックな状況では役に立たない。
【００１５】
例えばネットワークアクセス中のデバイス認証に対する他の解決策としては、１つの鍵またはパスワードを共有する方法がある（例えば、Ｗｉ−Ｆｉアライアンスの２００３年"Wi-Fi
Protected Access: Strong, standards-based, interoperable security for today's
Wi-Fi networks"に記載されているＩＥＥＥ８０２．１１のＷＰＡ−ＰＳＫ）。
【００１６】
無線ネットワークで使用される、広く用いられている分散認証プロトコルフレームワークとして、拡張認証プロトコル（ＥＡＰ）があり、Ａｂｏｂａらによる２００４年６月のＲＦＣ３７４８、"Extensible
Authentication Protocol (EAP)"の文献に記載されている。この文脈における「分散」とは、認証サーバが、サービス提供デバイスや未認証のユーザとは異なるネットワークに存在しうることを指す。このため、ＥＡＰは、実際上一元化されており、その主な利点は、多くの場所から利用可能な１つの認証サーバを持つ点にある。換言すれば、この２番目の公知のアプローチは、上で説明したアプローチと似ているが、認証情報を一元化している。これには、資格証明の別個のリストの数を減らせるという利点があり、各ユーザデバイスに対してセットアップ段階を１回行うだけで済むことになる。しかし、アドホックなピアツーピアネットワークは、定義上、信頼された中央の認証サーバを持つことができない。
【００１７】
このため、本発明の目的は、アドホックなピアツーピアネットワークで使用することができる認証方法および認証フレームワークを提供することにある。
【課題を解決するための手段】
【００１８】
本発明の第１の態様によれば、通信ネットワークにおいて、第２のデバイスにより第１のデバイスを認証する方法が提供され、前記方法は、前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれと、既存のセキュアな認証を有する第３のデバイスを使用するステップを有する。
【００１９】
下記の請求項１に記載の方法は、ネットワーク全体に権限を分散させることによって、アドホックなネットワークにおける認証の不都合を解決する。このようにすることで、認証プロセスのために１つの実体を信頼する必要がなくなる。更に、ネットワークのデバイスまたはユーザから入手可能な情報の量が増えることで、本発明を使用して、従来のアプローチよりも柔軟な認証を実現することができる。
【図面の簡単な説明】
【００２０】
【図１】超広帯域通信のためのマルチバンド直交周波数分割多重（ＭＢ−ＯＦＤＭ）システムにおける周波数バンドの構成を示す。
【図２】ＵＷＢシステムにおけるスーパーフレームの基本的なタイミング構造を示す。
【図３】従来のネットワークを示す。
【図４】本発明に係る認証フレームワークを示す。
【図５】ネットワークのサービス提供デバイスで実行されるステップを示す。
【図６】ネットワークのサービス要求デバイスで実行されるステップを示す。
【図７】ネットワークのピアデバイスで実行されるステップを示す。
【発明を実施するための形態】
【００２１】
本発明をよりよく理解し、本発明を実施することができる方法を明瞭に示すために、例示のみを目的として添付の図面を参照する。
【００２２】
本発明を、超広帯域無線通信ネットワークに関して以下に説明する。しかし、本発明が他の通信ネットワークにも利用可能であることはいうまでもない。
【００２３】
また、本発明を、サービス要求デバイスの形の未認証のデバイスと、サービス提供デバイスの形のセキュアなデバイスまたは認証されたデバイスとに関して説明する。しかし、本発明がどのような形のデバイスにも利用可能であることはいうまでもない。
【００２４】
図４は、未認証のユーザ４０（例えばサービス要求デバイス）を、別のデバイス４２（例えばサービス提供デバイス）により認証可能にするプロトコルフレームワークを示す。本発明によれば、ネットワーク内の１台以上の他のデバイス４４１〜４４ｎから認証関連の情報をセキュアに取得するために、複数ステージのプロトコルが使用される。これにより、サービス提供デバイス４２は、サービスの提供を続けるべきかどうかを決定するために、サービス要求デバイス４０の識別情報を検証することができる。
【００２５】
図４は、一般的なプロトコルフレームワークは５つのステップ５１〜５５を含むことを示す。これらのステップは、時間順に、「５１−要求」、「５２−問い合せ」、「５３−応答」、「５４−通知」および「５５−認証」である。このステップのそれぞれの目的については、後で更に詳細に説明する。しかし、このフレームワークから生成されるプロトコルが、この特定のステップに限定される必要はなく、一部のアプリケーションではフレームワークのステップの前か後に追加のメッセージが必要となったり、別のアプリケーションではステップ数が少なくてもよいという点に留意されたい。また、これらのメッセージフローが、必ずしもレイヤ２（例えばＯＳＩモデルのデータリンク層）において行われるとは限らず、任意のデバイスが、マルチホップネットワークを介して別のデバイスと通信してもよいという点にも留意されたい。
【００２６】
未認証のデバイス（例えばサービス要求デバイス４０）がセキュアなデバイス（例えばサービス提供デバイス４２）にサービス要求を送信すると、プロトコルが開始する。サービス要求デバイス４０が認証されていない場合、サービス提供デバイス４２は、サービス提供デバイス４２のピア４４１〜４４ｎの１つ以上に問い合せメッセージ５２を送信する。一実施形態によれば、サービス提供デバイス４２は、自身のピア４４１〜４４ｎの全てに問い合せメッセージを送信する。問い合せメッセージ５２には、未認証のデバイス４０に対応する一意の名前が含まれ、この名前がアドレスとして使用される。ピアデバイス４４は、サービス提供デバイス４２との間で認証されているデバイスであり、サービス提供デバイス４２との間で現在認証されているか、以前に認証されている点に留意されたい。
【００２７】
問い合せメッセージ５２を受信し、未認証のデバイス４０とセキュアな関係（association）を有する任意のピアデバイス４４は、２通のメッセージを送信する。１番目のメッセージは、サービス提供デバイス４２宛の応答メッセージ５３である。２番目のメッセージは、未認証のデバイス４０宛の通知メッセージ５４である。応答メッセージ５３と通知メッセージ５４のいずれにも、認証資格証明「Ｒ」が含まれる。例えば、認証資格証明「Ｒ」は、認証キーでも、ほかのどのような形の認証データでもよい。一例によれば、認証資格証明「Ｒ」は、ランダムに生成された認証キーである。
【００２８】
未認証のデバイス４０とピアデバイス４４の間に既にセキュアな関係が存在するため、ピアデバイス４４は、暗号化されたフォーマットで通知メッセージ５４を送信し、これにより、本当の未認証のデバイス４０のみがこの通知メッセージ４０を読むことができる。未認証のデバイス４０は、認証資格証明「Ｒ」を復号化して、サービス提供デバイス４２に認証メッセージ５５を送信する。
【００２９】
サービス提供デバイス４２は、サービス要求デバイス４０から認証メッセージ５５を受信すると、認証資格証明「Ｒ」と、応答メッセージ５３においてピアデバイス４４から受信した認証資格証明とを比較する。認証メッセージ５５で受信した認証資格証明が、応答メッセージ５３で受信した認証資格証明と一致する場合、サービスを提供できるように、認証メッセージ５５の正当性が認められる。
【００３０】
いうまでもなく、本当のサービス要求デバイス４０のみがサービス提供デバイス４２に認証メッセージ５５を送信することができるため、偽装が阻止され、認証を行うことが可能となる。
【００３１】
上で説明した実施形態では、認証の判定が、１台のピア４４から受信した応答メッセージ５３に基づいて、サービス提供デバイス４２によって行われる。本発明の別の態様によれば、認証の判定が、個々に認証資格証明を有する複数台のピアデバイス４４から受信した複数の応答メッセージ５３に基づいて行われてもよい。この場合、サービス提供デバイス４２は、サービス要求デバイス４０からも対応する複数の認証資格証明を受信する。この複数の認証資格証明は、同じであっても、異なってもよい。
【００３２】
図５は、未認証のデバイスから要求を受信したときに、例えば、未認証のサービス要求デバイスにサービスを提供するために、セキュアなデバイスで実行されるステップを示すフローチャートである。ステップ５０１において、デバイスは、サービス要求を受信すると、サービス要求デバイスが既に認証されているかどうかを判定する（ステップ５０３）。サービス要求デバイスが既に認証されている場合、ステップ５１５において、サービス提供デバイスは要求されたサービスを提供する。
【００３３】
しかし、サービス要求デバイスが未だ認証されていないと判定された場合、サービス提供デバイスは、サービス提供デバイスのピアデバイスの１台以上に問い合せメッセージを送信する（ステップ５０５）。次に、サービス提供デバイスは、サービス要求デバイスから少なくとも１つの認証資格証明を、ピアデバイスから少なくとも１つの対応する認証資格証明をそれぞれ受信する（ステップ５０７）。ステップ５０９において、サービス提供デバイスは、サービス要求デバイスから受信した認証資格証明が、対応するピアデバイスから受信した認証資格証明と一致するかどうかを判定する。認証資格証明が一致する場合、サービス提供デバイスはサービス要求デバイスを認証し（ステップ５１３）、要求されたサービスを提供する（ステップ５１５）。
【００３４】
サービス要求デバイスから受信した認証資格証明が、ピアデバイスから受信した認証資格証明と一致しない場合、サービス要求デバイスの認証が拒否される（ステップ５１１）。
【００３５】
上の説明から、ほかのデバイスから認証要求を受信したデバイスは、未認証のデバイスに関する情報を、自身のピアの１台以上に問い合せるということはいうまでもない。このようなピアの一部はサービス提供デバイスと未認証のデバイスの両方に応答し、未認証のデバイスが、サービス提供デバイスにコンタクトして、自身の識別情報を提示する。
【００３６】
上で説明したように、認証ステップ５０９が、１台のピアデバイスのみから受信した認証資格証明に基づいて行われても、あるいは複数台のピアデバイスから受信した複数の認証資格証明に基づいて行われてもよい。このため、後者によれば、未認証のデバイスは、認証が許可される前に、サービス提供デバイスの２台以上のピアデバイスと既にセキュアな認証を有している必要がある。
【００３７】
図６は、セキュアなデバイスにより認証を受けるときに、未認証のデバイスで実行されるステップを示すフローチャートである。ステップ６０１において、未認証のデバイスが、サービス提供デバイスにサービス要求を送信する。
【００３８】
次に、未認証のデバイスは、別のピアデバイスから認証資格証明を受信する（ステップ６０３）。受信した認証資格証明が暗号化されたフォーマットである場合、未認証のデバイスは、認証資格証明を復号化してから（ステップ６０５）、サービス提供デバイスに認証資格証明を送信する（ステップ６０７）。サービス提供デバイスが、ピアデバイスから、ピアデバイスの認証資格証明（its
own version of the authentication credential）を受信して、認証資格証明同士が一致した場合、未認証のデバイスは、認証されて、サービス提供デバイスからサービスを受ける（ステップ６０９）。
【００３９】
図７は、サービス提供デバイスと、サービス提供デバイスとの間で認証されていないサービス要求デバイスとの間の認証プロセスに参加するときに、ピアデバイスで実行されるステップを示すフローチャートである。ステップ７０１において、ピアデバイスは、サービス提供デバイスから、未認証のサービス要求デバイスのアドレスを含む問い合せを受信する。
【００４０】
ステップ７０３において、ピアデバイスは、未認証のサービス要求デバイスがピアデバイスとの間で認証されているかどうかを判定する。好ましくは、この際、未認証のサービス要求デバイスがピアデバイスとの間で現在認証されているかどうかが判定される。サービス要求デバイスがピアデバイスとの間で現在認証されているかどうかを判定する代わりに、ステップ７０３において、サービス要求デバイスがピアデバイスとの間で以前に（おそらく所定期間以内に）認証されているかどうかが判定されてもよい。
【００４１】
ピアデバイスが、サービス要求デバイスとの間で認証されている場合、ピアデバイスは、サービス要求デバイスとサービス提供デバイスの両方に認証資格証明を送信する（ステップ７０５）。一実施形態によれば、ピアデバイスは、未認証のデバイスに送信する認証資格証明を暗号化する。暗号化は、ピアデバイスと未認証のデバイスの間の認証設定に基づいて実行される。
【００４２】
ステップ７０３において、ピアデバイスがサービス要求デバイスとの間にセキュアな認証を有さないと判定されると、応答が送信されない（ステップ７０７）。別の実施形態では、ピアデバイスが、サービス要求デバイスとの間に認証を有さないことを示す応答を、サービス提供デバイスのみに送信するように、ピアデバイスが構成されてもよい。
【００４３】
上で説明した本発明は、ネットワーク全体に権限を分散させることによって、アドホックなネットワークにおける認証の不都合を解決する。このようにすることで、認証プロセスのために１つの実体を信頼する必要がなくなる。更に、ネットワークのデバイスまたはユーザから入手可能な情報の量が増えることで、本発明を使用して、従来のアプローチよりも柔軟な認証を実現することができる。
【００４４】
上で説明したプロトコルフレームワークはアプリケーション層で動作することができ、下位レベルの拡張または変更を一切必要としない点に留意されたい。
【００４５】
本発明は中央の認証サーバを必要としないという利点を有し、これにより、ネットワーク管理を簡素化できる。中央の認証サーバに代えて、潜在的な認証情報をピアのネットワークから取得できる一方で、認証プロトコルによって、偽装が不可能であることが保証される。
【００４６】
また、本発明は、サービスを要求した後に、ユーザと直接対話する必要がないという利点も有する。サービスを、ユーザとの対話を行う必要なく、簡単かつ容易に認証することができる。
【００４７】
本発明により、サービス提供デバイスは、必要なときに、アドホックなネットワークから認証情報を取得することができる。その際、セットアップ段階が不要であり、中央の信頼されたサーバが不要であり、長期にわたる一元化された資格証明のリストを収集する必要がない。
【技術分野】
【０００１】
本発明は、認証方法および認証フレームワークに関し、より詳細には、超広帯域通信ネットワークなどの無線通信ネットワークにおけるピアツーピアの分散認証フレームワークおよびそのための方法に関する。
【背景技術】
【０００２】
超広帯域とは、極めて広い周波数範囲（３．１〜１０．６ＧＨｚ）にわたってデジタルデータを伝送する無線技術である。広い帯域幅に無線周波数エネルギーを拡散させると、送信信号が、従来の周波数選択無線周波数技術では事実上検出不可能となる。しかし、送信電力が低いため、通信距離が通常１０〜１５ｍ未満に制限される。
【０００３】
超広帯域（ＵＷＢ）には、ＵＷＢ特性によってパルス波形から信号を構成する時間領域のアプローチと、複数の（周波数）バンドにわたって従来のＦＦＴをベースとした直交波周波数分割多重（ＯＦＤＭ）を使用し、ＭＢ−ＯＦＤＭを与える周波数領域変調のアプローチの２つのアプローチがある。この２つのＵＷＢのアプローチは、周波数スペクトル内に、極めて広い帯域幅にまたがるスペクトル成分を生じさせ（このため超広帯域と呼ばれている）、この帯域幅は、中心周波数の２０パーセント超、通常は少なくとも５００ＭＨｚを占める。
【０００４】
このような超広帯域の特性と、極めて広い帯域幅とにより、ＵＷＢは、通信しているデバイス同士が１０〜１５ｍの範囲にあるホーム環境またはオフィス環境に高速無線通信を提供する理想的な技術となる。
【０００５】
図１は、超広帯域通信のためのマルチバンド直交周波数分割多重（ＭＢ−ＯＦＤＭ）システムにおける周波数バンドの構成を示す。ＭＢ−ＯＦＤＭシステムは、それぞれ５２８ＭＨｚの１４のサブバンドを含み、アクセス方式として、各サブバンド間に３１２.５ナノ秒の周波数ホッピングを使用している。各サブバンド内では、データの伝送にＯＦＤＭおよびＱＰＳＫまたはＤＣＭ符号化が使用される。なお、５ＧＨｚを中心としたサブバンド（現在では５．１〜５．８ＧＨｚ）は、例えば８０２．１１ａＷＬＡＮシステム、保安機関の通信システムまたは航空産業などの既存の狭帯域システムとの干渉を避けるために使用されていない。
【０００６】
１４のサブバンドは、５つのバンドグループに編成されており、そのうち４つのバンドグループは５２８ＭＨｚのサブバンドを３つ有するが、１つのバンドグループは、５２８ＭＨｚのサブバンドを２つ有する。図１に示すように、第１のバンドグループは、サブバンド１、サブバンド２およびサブバンド３を有する。例として挙げるＵＷＢシステムは、バンドグループのサブバンド間に周波数ホッピングを使用しており、第１の３１２．５ナノ秒の時間インターバルに、第１のデータシンボルがバンドグループの第１の周波数サブバンドで送信され、第２の３１２．５ナノ秒の時間インターバルに、第２のデータシンボルがバンドグループの第２の周波数サブバンドで送信され、第３の３１２．５ナノ秒の時間インターバルに、第３のデータシンボルがバンドグループの第３の周波数サブバンドで送信される。このため、各時間インターバルの間に、データシンボルが、帯域幅５２８ＭＨｚのそれぞれのサブバンド（例えば、中心周波数３９６０ＭＨｚの５２８ＭＨｚのベースバンド信号を含むサブバンド２）で送信される。
【０００７】
各データシンボルが送信される３つの周波数のシーケンスは、時間周波数符号（ＴＦＣ）チャネルを表す。第１のＴＦＣチャネルは、シーケンス１、２、３、１、２、３と続き、１が第１のサブバンド、２が第２のサブバンド、３が第３のサブバンドである。第２および第３のＴＦＣチャネルは、それぞれシーケンス１、３、２、１、３、２、および１、１、２、２、３、３と続きうる。ＥＣＭＡ−３６８規格によれば、最初の４つのバンドグループのそれぞれに７つのＴＦＣチャネルが定義されており、５番目のバンドグループに２つのＴＦＣチャネルが定義されている。
【０００８】
超広帯域の技術的な性質は、データ通信の分野において各種用途に利用されつつあるということである。例えば、以下の環境において、ケーブルの代替として注目した、さまざまな用途が存在する。
−ＰＣと、周辺機器、すなわち外部デバイス（ハードディスクドライブ、ＣＤライタ、プリンタ、スキャナなど）との間の通信
−無線手段によって接続されたテレビとデバイス、無線スピーカなどのホームエンターテイメント
−例えば、携帯電話、ＰＤＡなどのハンドへルドデバイスおよびＰＣ、デジタルカメラ、ＭＰ３プレーヤなどの間の通信
【０００９】
ＵＷＢネットワークなどの無線ネットワークでは、１台以上のデバイスが、ビーコン期間中に定期的にビーコンフレームを送信する。ビーコンフレームの主な目的は、媒体にタイミング構造を提供すること、すなわち、時間を、いわゆるスーパーフレームに分割して、ネットワークのデバイスが、近くのデバイスと同期できるようにすることにある。
【００１０】
図２に示すように、ＵＷＢシステムの基本的なタイミング構造は、スーパーフレームである。欧州電子計算機工業会（ＥＣＭＡ）（ＥＣＭＡ−３６８第２版）によるスーパーフレームは、それぞれが定義済みの期間（例えば２５６マイクロ秒）を有する２５６のメディアアクセススロット（ＭＡＳ）からなる。各スーパーフレームは、１つのビーコン期間で開始し、１以上の隣接するＭＡＳの間続く。ビーコン期間を形成している各ＭＡＳは、３つのビーコンスロットを含み、ビーコンスロットにおいてデバイスが自身の個々のビーコンフレームを送信する。ビーコン期間の先頭のＭＡＳの始点は、「ビーコン期間の始点（ＢＰＳＴ）」と呼ばれている。特定のデバイスのビーコングループは、その特定のデバイスとビーコン期間の始点を共有（±１マイクロ秒）しており、その特定のデバイスの送信範囲に存在するデバイスのグループとして定義される。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
上で説明したＵＷＢシステムなどの無線システムは、アドホックのピアツーピア構成で使用される場合が増えている。つまり、ネットワークが中心的な制御または組織を持たずに存在しており、各デバイスが、範囲内の全ての他のデバイスと通信する可能性があるということである。このアプローチには、自発性と柔軟な対話などのいくつかの利点もある。しかし、このような柔軟な構成は、解決の必要のあるほかの問題も引き起こす。
【００１２】
例えば、監督する権限（authority）が存在しないため、ネットワーク内の個々のデバイスまたはユーザが、このような権限が担うべき役割を負わなければならない。多くのタスクでは、これは各デバイスが独立して行うことができるが、タスクのなかにはこれが機能できないものもある。従来の一元化された認証アーキテクチャは、アドホックなネットワークでは機能できない点に留意することが特に重要である。これは、中央のセキュリティサーバとして動作させるに足る信頼できるピアが存在しないためである。
【００１３】
「認証」とは、デバイスまたはユーザの「識別情報」を検査して検証するプロセスでり、偽装攻撃に対抗するために必要とされる。図３は、複数の個々のデバイスまたはユーザ４（Ａ〜Ｃで示す）を有するネットワーク２において認証を与えるための従来のアプローチを示す。この従来のアプローチに係る認証は、中央の認証サーバ「Ｄ」（例えばＡｐａｃｈｅなどのウェブサーバアプリケーションまたはＵＮＩＸ上のログインサーバ）のメモリ５に識別情報（例えばユーザ名およびパスワード）のリストと、各識別情報の所有者が保持する資格証明（credential）とを記憶することによって実行される。次に、別のユーザ「Ｂ」に対して自身の識別情報を証明したいユーザ「Ａ」が、認証サーバＤに自身の資格証明を提供し、認証サーバＤは、その資格証明の妥当性を「Ｂ」に通知する。このアプローチは、「Ａ」と「Ｂ」の両方が「Ｄ」を信頼している場合（Ｄがネットワークのコントローラによって実行されている場合に多い）には、認証を与える非常に単純かつ有効な方法である。このようなシステムでは、サービス提供デバイスが、ユーザごとに認証を実行し、要求ごとに認可を実行する必要がある。
【００１４】
アドホックなピアツーピアネットワークには、Ｄのような信頼されたサーバが１台も存在しないため、この役割を果たすことができない。更に、認証資格証明のリストが複数必要となり、セットアップ段階を完了してから各サービスを使用しなければならないことになる。このように資格証明を事前に共有することは、長期の使用には適切であるが、アドホックな状況では役に立たない。
【００１５】
例えばネットワークアクセス中のデバイス認証に対する他の解決策としては、１つの鍵またはパスワードを共有する方法がある（例えば、Ｗｉ−Ｆｉアライアンスの２００３年"Wi-Fi
Protected Access: Strong, standards-based, interoperable security for today's
Wi-Fi networks"に記載されているＩＥＥＥ８０２．１１のＷＰＡ−ＰＳＫ）。
【００１６】
無線ネットワークで使用される、広く用いられている分散認証プロトコルフレームワークとして、拡張認証プロトコル（ＥＡＰ）があり、Ａｂｏｂａらによる２００４年６月のＲＦＣ３７４８、"Extensible
Authentication Protocol (EAP)"の文献に記載されている。この文脈における「分散」とは、認証サーバが、サービス提供デバイスや未認証のユーザとは異なるネットワークに存在しうることを指す。このため、ＥＡＰは、実際上一元化されており、その主な利点は、多くの場所から利用可能な１つの認証サーバを持つ点にある。換言すれば、この２番目の公知のアプローチは、上で説明したアプローチと似ているが、認証情報を一元化している。これには、資格証明の別個のリストの数を減らせるという利点があり、各ユーザデバイスに対してセットアップ段階を１回行うだけで済むことになる。しかし、アドホックなピアツーピアネットワークは、定義上、信頼された中央の認証サーバを持つことができない。
【００１７】
このため、本発明の目的は、アドホックなピアツーピアネットワークで使用することができる認証方法および認証フレームワークを提供することにある。
【課題を解決するための手段】
【００１８】
本発明の第１の態様によれば、通信ネットワークにおいて、第２のデバイスにより第１のデバイスを認証する方法が提供され、前記方法は、前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれと、既存のセキュアな認証を有する第３のデバイスを使用するステップを有する。
【００１９】
下記の請求項１に記載の方法は、ネットワーク全体に権限を分散させることによって、アドホックなネットワークにおける認証の不都合を解決する。このようにすることで、認証プロセスのために１つの実体を信頼する必要がなくなる。更に、ネットワークのデバイスまたはユーザから入手可能な情報の量が増えることで、本発明を使用して、従来のアプローチよりも柔軟な認証を実現することができる。
【図面の簡単な説明】
【００２０】
【図１】超広帯域通信のためのマルチバンド直交周波数分割多重（ＭＢ−ＯＦＤＭ）システムにおける周波数バンドの構成を示す。
【図２】ＵＷＢシステムにおけるスーパーフレームの基本的なタイミング構造を示す。
【図３】従来のネットワークを示す。
【図４】本発明に係る認証フレームワークを示す。
【図５】ネットワークのサービス提供デバイスで実行されるステップを示す。
【図６】ネットワークのサービス要求デバイスで実行されるステップを示す。
【図７】ネットワークのピアデバイスで実行されるステップを示す。
【発明を実施するための形態】
【００２１】
本発明をよりよく理解し、本発明を実施することができる方法を明瞭に示すために、例示のみを目的として添付の図面を参照する。
【００２２】
本発明を、超広帯域無線通信ネットワークに関して以下に説明する。しかし、本発明が他の通信ネットワークにも利用可能であることはいうまでもない。
【００２３】
また、本発明を、サービス要求デバイスの形の未認証のデバイスと、サービス提供デバイスの形のセキュアなデバイスまたは認証されたデバイスとに関して説明する。しかし、本発明がどのような形のデバイスにも利用可能であることはいうまでもない。
【００２４】
図４は、未認証のユーザ４０（例えばサービス要求デバイス）を、別のデバイス４２（例えばサービス提供デバイス）により認証可能にするプロトコルフレームワークを示す。本発明によれば、ネットワーク内の１台以上の他のデバイス４４１〜４４ｎから認証関連の情報をセキュアに取得するために、複数ステージのプロトコルが使用される。これにより、サービス提供デバイス４２は、サービスの提供を続けるべきかどうかを決定するために、サービス要求デバイス４０の識別情報を検証することができる。
【００２５】
図４は、一般的なプロトコルフレームワークは５つのステップ５１〜５５を含むことを示す。これらのステップは、時間順に、「５１−要求」、「５２−問い合せ」、「５３−応答」、「５４−通知」および「５５−認証」である。このステップのそれぞれの目的については、後で更に詳細に説明する。しかし、このフレームワークから生成されるプロトコルが、この特定のステップに限定される必要はなく、一部のアプリケーションではフレームワークのステップの前か後に追加のメッセージが必要となったり、別のアプリケーションではステップ数が少なくてもよいという点に留意されたい。また、これらのメッセージフローが、必ずしもレイヤ２（例えばＯＳＩモデルのデータリンク層）において行われるとは限らず、任意のデバイスが、マルチホップネットワークを介して別のデバイスと通信してもよいという点にも留意されたい。
【００２６】
未認証のデバイス（例えばサービス要求デバイス４０）がセキュアなデバイス（例えばサービス提供デバイス４２）にサービス要求を送信すると、プロトコルが開始する。サービス要求デバイス４０が認証されていない場合、サービス提供デバイス４２は、サービス提供デバイス４２のピア４４１〜４４ｎの１つ以上に問い合せメッセージ５２を送信する。一実施形態によれば、サービス提供デバイス４２は、自身のピア４４１〜４４ｎの全てに問い合せメッセージを送信する。問い合せメッセージ５２には、未認証のデバイス４０に対応する一意の名前が含まれ、この名前がアドレスとして使用される。ピアデバイス４４は、サービス提供デバイス４２との間で認証されているデバイスであり、サービス提供デバイス４２との間で現在認証されているか、以前に認証されている点に留意されたい。
【００２７】
問い合せメッセージ５２を受信し、未認証のデバイス４０とセキュアな関係（association）を有する任意のピアデバイス４４は、２通のメッセージを送信する。１番目のメッセージは、サービス提供デバイス４２宛の応答メッセージ５３である。２番目のメッセージは、未認証のデバイス４０宛の通知メッセージ５４である。応答メッセージ５３と通知メッセージ５４のいずれにも、認証資格証明「Ｒ」が含まれる。例えば、認証資格証明「Ｒ」は、認証キーでも、ほかのどのような形の認証データでもよい。一例によれば、認証資格証明「Ｒ」は、ランダムに生成された認証キーである。
【００２８】
未認証のデバイス４０とピアデバイス４４の間に既にセキュアな関係が存在するため、ピアデバイス４４は、暗号化されたフォーマットで通知メッセージ５４を送信し、これにより、本当の未認証のデバイス４０のみがこの通知メッセージ４０を読むことができる。未認証のデバイス４０は、認証資格証明「Ｒ」を復号化して、サービス提供デバイス４２に認証メッセージ５５を送信する。
【００２９】
サービス提供デバイス４２は、サービス要求デバイス４０から認証メッセージ５５を受信すると、認証資格証明「Ｒ」と、応答メッセージ５３においてピアデバイス４４から受信した認証資格証明とを比較する。認証メッセージ５５で受信した認証資格証明が、応答メッセージ５３で受信した認証資格証明と一致する場合、サービスを提供できるように、認証メッセージ５５の正当性が認められる。
【００３０】
いうまでもなく、本当のサービス要求デバイス４０のみがサービス提供デバイス４２に認証メッセージ５５を送信することができるため、偽装が阻止され、認証を行うことが可能となる。
【００３１】
上で説明した実施形態では、認証の判定が、１台のピア４４から受信した応答メッセージ５３に基づいて、サービス提供デバイス４２によって行われる。本発明の別の態様によれば、認証の判定が、個々に認証資格証明を有する複数台のピアデバイス４４から受信した複数の応答メッセージ５３に基づいて行われてもよい。この場合、サービス提供デバイス４２は、サービス要求デバイス４０からも対応する複数の認証資格証明を受信する。この複数の認証資格証明は、同じであっても、異なってもよい。
【００３２】
図５は、未認証のデバイスから要求を受信したときに、例えば、未認証のサービス要求デバイスにサービスを提供するために、セキュアなデバイスで実行されるステップを示すフローチャートである。ステップ５０１において、デバイスは、サービス要求を受信すると、サービス要求デバイスが既に認証されているかどうかを判定する（ステップ５０３）。サービス要求デバイスが既に認証されている場合、ステップ５１５において、サービス提供デバイスは要求されたサービスを提供する。
【００３３】
しかし、サービス要求デバイスが未だ認証されていないと判定された場合、サービス提供デバイスは、サービス提供デバイスのピアデバイスの１台以上に問い合せメッセージを送信する（ステップ５０５）。次に、サービス提供デバイスは、サービス要求デバイスから少なくとも１つの認証資格証明を、ピアデバイスから少なくとも１つの対応する認証資格証明をそれぞれ受信する（ステップ５０７）。ステップ５０９において、サービス提供デバイスは、サービス要求デバイスから受信した認証資格証明が、対応するピアデバイスから受信した認証資格証明と一致するかどうかを判定する。認証資格証明が一致する場合、サービス提供デバイスはサービス要求デバイスを認証し（ステップ５１３）、要求されたサービスを提供する（ステップ５１５）。
【００３４】
サービス要求デバイスから受信した認証資格証明が、ピアデバイスから受信した認証資格証明と一致しない場合、サービス要求デバイスの認証が拒否される（ステップ５１１）。
【００３５】
上の説明から、ほかのデバイスから認証要求を受信したデバイスは、未認証のデバイスに関する情報を、自身のピアの１台以上に問い合せるということはいうまでもない。このようなピアの一部はサービス提供デバイスと未認証のデバイスの両方に応答し、未認証のデバイスが、サービス提供デバイスにコンタクトして、自身の識別情報を提示する。
【００３６】
上で説明したように、認証ステップ５０９が、１台のピアデバイスのみから受信した認証資格証明に基づいて行われても、あるいは複数台のピアデバイスから受信した複数の認証資格証明に基づいて行われてもよい。このため、後者によれば、未認証のデバイスは、認証が許可される前に、サービス提供デバイスの２台以上のピアデバイスと既にセキュアな認証を有している必要がある。
【００３７】
図６は、セキュアなデバイスにより認証を受けるときに、未認証のデバイスで実行されるステップを示すフローチャートである。ステップ６０１において、未認証のデバイスが、サービス提供デバイスにサービス要求を送信する。
【００３８】
次に、未認証のデバイスは、別のピアデバイスから認証資格証明を受信する（ステップ６０３）。受信した認証資格証明が暗号化されたフォーマットである場合、未認証のデバイスは、認証資格証明を復号化してから（ステップ６０５）、サービス提供デバイスに認証資格証明を送信する（ステップ６０７）。サービス提供デバイスが、ピアデバイスから、ピアデバイスの認証資格証明（its
own version of the authentication credential）を受信して、認証資格証明同士が一致した場合、未認証のデバイスは、認証されて、サービス提供デバイスからサービスを受ける（ステップ６０９）。
【００３９】
図７は、サービス提供デバイスと、サービス提供デバイスとの間で認証されていないサービス要求デバイスとの間の認証プロセスに参加するときに、ピアデバイスで実行されるステップを示すフローチャートである。ステップ７０１において、ピアデバイスは、サービス提供デバイスから、未認証のサービス要求デバイスのアドレスを含む問い合せを受信する。
【００４０】
ステップ７０３において、ピアデバイスは、未認証のサービス要求デバイスがピアデバイスとの間で認証されているかどうかを判定する。好ましくは、この際、未認証のサービス要求デバイスがピアデバイスとの間で現在認証されているかどうかが判定される。サービス要求デバイスがピアデバイスとの間で現在認証されているかどうかを判定する代わりに、ステップ７０３において、サービス要求デバイスがピアデバイスとの間で以前に（おそらく所定期間以内に）認証されているかどうかが判定されてもよい。
【００４１】
ピアデバイスが、サービス要求デバイスとの間で認証されている場合、ピアデバイスは、サービス要求デバイスとサービス提供デバイスの両方に認証資格証明を送信する（ステップ７０５）。一実施形態によれば、ピアデバイスは、未認証のデバイスに送信する認証資格証明を暗号化する。暗号化は、ピアデバイスと未認証のデバイスの間の認証設定に基づいて実行される。
【００４２】
ステップ７０３において、ピアデバイスがサービス要求デバイスとの間にセキュアな認証を有さないと判定されると、応答が送信されない（ステップ７０７）。別の実施形態では、ピアデバイスが、サービス要求デバイスとの間に認証を有さないことを示す応答を、サービス提供デバイスのみに送信するように、ピアデバイスが構成されてもよい。
【００４３】
上で説明した本発明は、ネットワーク全体に権限を分散させることによって、アドホックなネットワークにおける認証の不都合を解決する。このようにすることで、認証プロセスのために１つの実体を信頼する必要がなくなる。更に、ネットワークのデバイスまたはユーザから入手可能な情報の量が増えることで、本発明を使用して、従来のアプローチよりも柔軟な認証を実現することができる。
【００４４】
上で説明したプロトコルフレームワークはアプリケーション層で動作することができ、下位レベルの拡張または変更を一切必要としない点に留意されたい。
【００４５】
本発明は中央の認証サーバを必要としないという利点を有し、これにより、ネットワーク管理を簡素化できる。中央の認証サーバに代えて、潜在的な認証情報をピアのネットワークから取得できる一方で、認証プロトコルによって、偽装が不可能であることが保証される。
【００４６】
また、本発明は、サービスを要求した後に、ユーザと直接対話する必要がないという利点も有する。サービスを、ユーザとの対話を行う必要なく、簡単かつ容易に認証することができる。
【００４７】
本発明により、サービス提供デバイスは、必要なときに、アドホックなネットワークから認証情報を取得することができる。その際、セットアップ段階が不要であり、中央の信頼されたサーバが不要であり、長期にわたる一元化された資格証明のリストを収集する必要がない。
【特許請求の範囲】
【請求項１】
通信ネットワークにおいて、第２のデバイスにより第１のデバイスを認証する方法であって、前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれとの間でセキュアな認証を有する第３のデバイスを使用するステップを有する方法。
【請求項２】
前記第２のデバイスが、前記第１のデバイスから認証要求を受信すると、前記第２のデバイスから前記第３のデバイスに問い合せメッセージを送信するステップと、
前記第３のデバイスが、前記第２のデバイスが、前記第１のデバイスを認証すべきかどうかの判定を支援するための情報を提供するステップと、を更に有する請求項１に記載の方法。
【請求項３】
前記問い合せメッセージは、前記第１のデバイスの識別情報を含む請求項２に記載の方法。
【請求項４】
情報を提供する前記ステップは、前記第３のデバイスから、前記第１のデバイスと前記第２のデバイスとに認証資格証明を送信するステップを有する請求項２または３に記載の方法。
【請求項５】
前記第１のデバイスにおいて受信した前記認証資格証明を前記第２のデバイスに送信するステップと、
前記第２のデバイスにおいて、前記第１のデバイスから受信した前記認証資格証明と、前記第３のデバイスから受信した前記認証資格証明とを比較するステップと、
前記第１のデバイスから受信した前記認証資格証明と、前記第２のデバイスから受信した前記認証資格証明とが一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証するステップと、を更に有する請求項４に記載の方法。
【請求項６】
前記第３のデバイスから前記第１のデバイスに送信される前記認証資格証明を暗号化するステップと、
前記第１のデバイスにおいて前記認証資格証明を復号化してから、前記第１のデバイスから前記第２のデバイスに前記認証資格証明を送信するステップと、を更に有する請求項４に記載の方法。
【請求項７】
前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれとの間でセキュアな認証を有する第４のデバイスを使用するステップを更に有する請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記第４のデバイスから、前記第１のデバイスと前記第２のデバイスとに第２の認証資格証明を送信するステップと、
前記第１のデバイスにおいて受信した前記第２の認証資格証明を前記第２のデバイスに送信するステップと、
前記第２のデバイスにおいて、前記第１のデバイスから受信した前記第２の認証資格証明と、前記第３のデバイスから受信した前記第２の認証資格証明とを比較して、前記認証資格証明同士が一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証するステップと、を更に有する請求項７に記載の方法。
【請求項９】
前記認証資格証明をランダムに生成するステップを更に有する請求項４〜８のいずれか１項に記載の方法。
【請求項１０】
前記認証資格証明は認証キーである請求項９に記載の方法。
【請求項１１】
前記第３のデバイスと前記第１のデバイスとの間のセキュアな認証は、前記第３のデバイスと第１のデバイスとが現在認証されていることに基づく請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】
前記第３のデバイスと前記第１のデバイスとの間のセキュアな認証は、前記第３のデバイスと第１のデバイスとが以前に認証されていることに基づく請求項１〜１０のいずれか１項に記載の方法。
【請求項１３】
前記第３のデバイスと前記第１のデバイスとが所定期間以内に認証されている請求項１２に記載の方法。
【請求項１４】
サービス提供デバイスにおいて認証を実行する方法であって、
サービス要求デバイスから認証要求を受信するステップと、
前記サービス提供デバイスとの間で認証されている１台以上のピアデバイスに問い合せメッセージを送信するステップと、
ピアデバイスから認証資格証明を受信するステップと、
前記サービス要求デバイスから認証資格証明を受信するステップと、
前記ピアデバイスからの前記認証資格証明が前記サービス要求デバイスからの前記認証資格証明と一致した場合に、前記サービス要求デバイスを認証するステップと、を有する方法。
【請求項１５】
サービス要求デバイスにおいて認証を実行する方法であって、
サービス提供デバイスに認証要求を送信するステップと、
前記サービス提供デバイスとの間で認証されているピアデバイスから認証資格証明を受信するステップと、
前記サービス提供デバイスが認証の判定を実行することができるように、前記受信した認証資格証明を前記サービス提供デバイスに送信するステップと、を有する方法。
【請求項１６】
サービス要求デバイスとサービス提供デバイスとの間の認証を支援するために使用されるピアデバイスにおいて、前記認証を実行する方法であって、
前記ピアデバイスとの間で認証されている前記サービス提供デバイスから、前記サービス要求デバイスの識別情報を含む問い合せメッセージを受信するステップと、
前記ピアデバイスが前記サービス要求デバイスとの間で認証されているかどうかを判定するステップと、認証されている場合に、
前記サービス提供デバイスに認証資格証明を送信するステップと、
前記サービス要求デバイスに認証資格証明を送信するステップと、を有する方法。
【請求項１７】
前記認証資格証明は認証キーである請求項１４〜１６のいずれか１項に記載の方法。
【請求項１８】
第１のデバイスと第２のデバイスとの間に認証を与えるように構成された通信ネットワークであって、前記ネットワークは、前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれとの間でセキュアな認証を有する第３のデバイスを使用するように適合されているネットワーク。
【請求項１９】
前記ネットワークは、
前記第１のデバイスから前記第２のデバイスに認証要求を送信し、
前記第２のデバイスから前記第３のデバイスに問い合せメッセージを送信し、
前記第３のデバイスから、前記第１のデバイスと前記第２のデバイスとに認証資格証明を送信し、
前記第１のデバイスにおいて受信した前記認証資格証明を前記第２のデバイスに送信し、
前記第２のデバイスにおいて、前記第１のデバイスから受信した前記認証資格証明と、前記第３のデバイスから受信した前記認証資格証明とを比較して、前記第１のデバイスから受信した前記認証資格証明と、前記第３のデバイスから受信した前記認証資格証明とが一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証するように構成されている請求項１８に記載のネットワーク。
【請求項２０】
前記第２のデバイスから前記第３のデバイスに送信される前記問い合せメッセージは、前記第１のデバイスの識別情報を含む請求項１９に記載のネットワーク。
【請求項２１】
前記第３のデバイスから前記第１のデバイスに送信される前記認証資格証明は、暗号化されており、前記認証資格証明は前記第１のデバイスにおいて復号化されてから、前記認証資格証明が前記第１のデバイスから前記第２のデバイスに送信される請求項１９または２０に記載のネットワーク。
【請求項２２】
前記ネットワークは、前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれとの間でセキュアな認証を有する第４のデバイスを使用するように更に構成されている請求項１８〜２１のいずれか１項に記載のネットワーク。
【請求項２３】
前記ネットワークは、
前記第４のデバイスから、前記第１のデバイスと前記第２のデバイスとに第２の認証資格証明を送信し、
前記第１のデバイスにおいて受信した前記第２の認証資格証明を前記第２のデバイスに送信し、
前記第２のデバイスにおいて、前記第１のデバイスから受信した前記第２の認証資格証明と、前記第３のデバイスから受信した前記第２の認証資格証明とを比較して、前記第２の認証資格証明同士が一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証するように更に構成されている請求項２２に記載のネットワーク。
【請求項２４】
前記認証資格証明はランダムに生成される請求項１９〜２３のいずれか１項に記載のネットワーク。
【請求項２５】
前記認証資格証明は認証キーである請求項２４に記載のネットワーク。
【請求項２６】
未認証のデバイスを認証するために使用されるデバイスであって、前記デバイスは、
前記未認証のデバイスから認証要求を受信し、
前記デバイスとの間で現在認証されている１台以上のピアデバイスに問い合せメッセージを送信し、
ピアデバイスから認証資格証明を受信し、
前記未認証のデバイスから認証資格証明を受信し、
前記未認証のデバイスから受信した前記認証資格証明が前記ピアデバイスから受信した前記認証資格証明と一致する場合に、前記未認証のデバイスを認証するように構成された送受信器を有するデバイス。
【請求項２７】
第２のデバイスに認証要求を送信するための手段と、
前記第２のデバイスとの間で現在認証されている１台以上のピアデバイスから認証資格証明を受信するための手段と、
前記受信した認証資格証明を前記第２のデバイスに送信するための手段と、を有するデバイス。
【請求項２８】
第２のデバイスにより第１のデバイスを認証するために使用されるデバイスであって、前記デバイスは前記第２のデバイスとの間で認証されており、前記デバイスは、
前記第２のデバイスから、前記第１のデバイスの識別情報を含む問い合せメッセージを受信し、
前記デバイスが前記第１のデバイスとの間で認証されているかどうかを判定し、認証されている場合に、
前記第１のデバイスに認証資格証明を送信し、
前記第２のデバイスに認証資格証明を送信するように構成されているデバイス。
【請求項２９】
前記認証資格証明は認証キーである請求項２６〜２８のいずれか１項に記載のデバイス。
【請求項１】
通信ネットワークにおいて、第２のデバイスにより第１のデバイスを認証する方法であって、前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれとの間でセキュアな認証を有する第３のデバイスを使用するステップを有する方法。
【請求項２】
前記第２のデバイスが、前記第１のデバイスから認証要求を受信すると、前記第２のデバイスから前記第３のデバイスに問い合せメッセージを送信するステップと、
前記第３のデバイスが、前記第２のデバイスが、前記第１のデバイスを認証すべきかどうかの判定を支援するための情報を提供するステップと、を更に有する請求項１に記載の方法。
【請求項３】
前記問い合せメッセージは、前記第１のデバイスの識別情報を含む請求項２に記載の方法。
【請求項４】
情報を提供する前記ステップは、前記第３のデバイスから、前記第１のデバイスと前記第２のデバイスとに認証資格証明を送信するステップを有する請求項２または３に記載の方法。
【請求項５】
前記第１のデバイスにおいて受信した前記認証資格証明を前記第２のデバイスに送信するステップと、
前記第２のデバイスにおいて、前記第１のデバイスから受信した前記認証資格証明と、前記第３のデバイスから受信した前記認証資格証明とを比較するステップと、
前記第１のデバイスから受信した前記認証資格証明と、前記第２のデバイスから受信した前記認証資格証明とが一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証するステップと、を更に有する請求項４に記載の方法。
【請求項６】
前記第３のデバイスから前記第１のデバイスに送信される前記認証資格証明を暗号化するステップと、
前記第１のデバイスにおいて前記認証資格証明を復号化してから、前記第１のデバイスから前記第２のデバイスに前記認証資格証明を送信するステップと、を更に有する請求項４に記載の方法。
【請求項７】
前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれとの間でセキュアな認証を有する第４のデバイスを使用するステップを更に有する請求項１〜６のいずれか１項に記載の方法。
【請求項８】
前記第４のデバイスから、前記第１のデバイスと前記第２のデバイスとに第２の認証資格証明を送信するステップと、
前記第１のデバイスにおいて受信した前記第２の認証資格証明を前記第２のデバイスに送信するステップと、
前記第２のデバイスにおいて、前記第１のデバイスから受信した前記第２の認証資格証明と、前記第３のデバイスから受信した前記第２の認証資格証明とを比較して、前記認証資格証明同士が一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証するステップと、を更に有する請求項７に記載の方法。
【請求項９】
前記認証資格証明をランダムに生成するステップを更に有する請求項４〜８のいずれか１項に記載の方法。
【請求項１０】
前記認証資格証明は認証キーである請求項９に記載の方法。
【請求項１１】
前記第３のデバイスと前記第１のデバイスとの間のセキュアな認証は、前記第３のデバイスと第１のデバイスとが現在認証されていることに基づく請求項１〜１０のいずれか１項に記載の方法。
【請求項１２】
前記第３のデバイスと前記第１のデバイスとの間のセキュアな認証は、前記第３のデバイスと第１のデバイスとが以前に認証されていることに基づく請求項１〜１０のいずれか１項に記載の方法。
【請求項１３】
前記第３のデバイスと前記第１のデバイスとが所定期間以内に認証されている請求項１２に記載の方法。
【請求項１４】
サービス提供デバイスにおいて認証を実行する方法であって、
サービス要求デバイスから認証要求を受信するステップと、
前記サービス提供デバイスとの間で認証されている１台以上のピアデバイスに問い合せメッセージを送信するステップと、
ピアデバイスから認証資格証明を受信するステップと、
前記サービス要求デバイスから認証資格証明を受信するステップと、
前記ピアデバイスからの前記認証資格証明が前記サービス要求デバイスからの前記認証資格証明と一致した場合に、前記サービス要求デバイスを認証するステップと、を有する方法。
【請求項１５】
サービス要求デバイスにおいて認証を実行する方法であって、
サービス提供デバイスに認証要求を送信するステップと、
前記サービス提供デバイスとの間で認証されているピアデバイスから認証資格証明を受信するステップと、
前記サービス提供デバイスが認証の判定を実行することができるように、前記受信した認証資格証明を前記サービス提供デバイスに送信するステップと、を有する方法。
【請求項１６】
サービス要求デバイスとサービス提供デバイスとの間の認証を支援するために使用されるピアデバイスにおいて、前記認証を実行する方法であって、
前記ピアデバイスとの間で認証されている前記サービス提供デバイスから、前記サービス要求デバイスの識別情報を含む問い合せメッセージを受信するステップと、
前記ピアデバイスが前記サービス要求デバイスとの間で認証されているかどうかを判定するステップと、認証されている場合に、
前記サービス提供デバイスに認証資格証明を送信するステップと、
前記サービス要求デバイスに認証資格証明を送信するステップと、を有する方法。
【請求項１７】
前記認証資格証明は認証キーである請求項１４〜１６のいずれか１項に記載の方法。
【請求項１８】
第１のデバイスと第２のデバイスとの間に認証を与えるように構成された通信ネットワークであって、前記ネットワークは、前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれとの間でセキュアな認証を有する第３のデバイスを使用するように適合されているネットワーク。
【請求項１９】
前記ネットワークは、
前記第１のデバイスから前記第２のデバイスに認証要求を送信し、
前記第２のデバイスから前記第３のデバイスに問い合せメッセージを送信し、
前記第３のデバイスから、前記第１のデバイスと前記第２のデバイスとに認証資格証明を送信し、
前記第１のデバイスにおいて受信した前記認証資格証明を前記第２のデバイスに送信し、
前記第２のデバイスにおいて、前記第１のデバイスから受信した前記認証資格証明と、前記第３のデバイスから受信した前記認証資格証明とを比較して、前記第１のデバイスから受信した前記認証資格証明と、前記第３のデバイスから受信した前記認証資格証明とが一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証するように構成されている請求項１８に記載のネットワーク。
【請求項２０】
前記第２のデバイスから前記第３のデバイスに送信される前記問い合せメッセージは、前記第１のデバイスの識別情報を含む請求項１９に記載のネットワーク。
【請求項２１】
前記第３のデバイスから前記第１のデバイスに送信される前記認証資格証明は、暗号化されており、前記認証資格証明は前記第１のデバイスにおいて復号化されてから、前記認証資格証明が前記第１のデバイスから前記第２のデバイスに送信される請求項１９または２０に記載のネットワーク。
【請求項２２】
前記ネットワークは、前記認証プロセスにおいて、前記第１のデバイスと前記第２のデバイスとのそれぞれとの間でセキュアな認証を有する第４のデバイスを使用するように更に構成されている請求項１８〜２１のいずれか１項に記載のネットワーク。
【請求項２３】
前記ネットワークは、
前記第４のデバイスから、前記第１のデバイスと前記第２のデバイスとに第２の認証資格証明を送信し、
前記第１のデバイスにおいて受信した前記第２の認証資格証明を前記第２のデバイスに送信し、
前記第２のデバイスにおいて、前記第１のデバイスから受信した前記第２の認証資格証明と、前記第３のデバイスから受信した前記第２の認証資格証明とを比較して、前記第２の認証資格証明同士が一致した場合に、前記第２のデバイスにより前記第１のデバイスを認証するように更に構成されている請求項２２に記載のネットワーク。
【請求項２４】
前記認証資格証明はランダムに生成される請求項１９〜２３のいずれか１項に記載のネットワーク。
【請求項２５】
前記認証資格証明は認証キーである請求項２４に記載のネットワーク。
【請求項２６】
未認証のデバイスを認証するために使用されるデバイスであって、前記デバイスは、
前記未認証のデバイスから認証要求を受信し、
前記デバイスとの間で現在認証されている１台以上のピアデバイスに問い合せメッセージを送信し、
ピアデバイスから認証資格証明を受信し、
前記未認証のデバイスから認証資格証明を受信し、
前記未認証のデバイスから受信した前記認証資格証明が前記ピアデバイスから受信した前記認証資格証明と一致する場合に、前記未認証のデバイスを認証するように構成された送受信器を有するデバイス。
【請求項２７】
第２のデバイスに認証要求を送信するための手段と、
前記第２のデバイスとの間で現在認証されている１台以上のピアデバイスから認証資格証明を受信するための手段と、
前記受信した認証資格証明を前記第２のデバイスに送信するための手段と、を有するデバイス。
【請求項２８】
第２のデバイスにより第１のデバイスを認証するために使用されるデバイスであって、前記デバイスは前記第２のデバイスとの間で認証されており、前記デバイスは、
前記第２のデバイスから、前記第１のデバイスの識別情報を含む問い合せメッセージを受信し、
前記デバイスが前記第１のデバイスとの間で認証されているかどうかを判定し、認証されている場合に、
前記第１のデバイスに認証資格証明を送信し、
前記第２のデバイスに認証資格証明を送信するように構成されているデバイス。
【請求項２９】
前記認証資格証明は認証キーである請求項２６〜２８のいずれか１項に記載のデバイス。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２０１１−５０３９２６（Ｐ２０１１−５０３９２６Ａ）
【公表日】平成２３年１月２７日（２０１１．１．２７）
【国際特許分類】
【出願番号】特願２０１０−５２７５３８（Ｐ２０１０−５２７５３８）
【出願日】平成２０年１０月６日（２００８．１０．６）
【国際出願番号】ＰＣＴ／ＧＢ２００８／００３３８３
【国際公開番号】ＷＯ２００９／０４４１７４
【国際公開日】平成２１年４月９日（２００９．４．９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＵＮＩＸ
【出願人】（５０７３４５５３８）アイティーアイ スコットランド リミテッド (34)
【Ｆターム（参考）】
【公表日】平成２３年１月２７日（２０１１．１．２７）
【国際特許分類】
【出願日】平成２０年１０月６日（２００８．１０．６）
【国際出願番号】ＰＣＴ／ＧＢ２００８／００３３８３
【国際公開番号】ＷＯ２００９／０４４１７４
【国際公開日】平成２１年４月９日（２００９．４．９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＵＮＩＸ
【出願人】（５０７３４５５３８）アイティーアイ スコットランド リミテッド (34)
【Ｆターム（参考）】
[ Back to top ]