JP2013530650A - 通信ネットワークにおける属性の遠隔検証 - Google Patents

Abstract

装置が提供され、この装置は、要求者デバイスから受け取った要求者特性情報が所定の要求者属性に対応するかどうかをチェックするように構成された特性チェック手段と、この特性チェック手段によりチェックした要求者特性情報が所定の要求者属性に対応する場合にのみ肯定の結果を取得するように構成された取得手段と、装置に記憶された所定の要求者永久鍵から第１の要求者中間鍵を生成するように構成された鍵生成手段と、安全なプロトコルを使用して第１の要求者中間鍵を要求者デバイスに供給するように構成された供給手段とを備え、鍵生成手段及び供給手段の少なくとも一方は、結果が肯定の場合にのみ、第１の要求者中間鍵の生成及び供給をそれぞれ行うように構成される。
【選択図】図３

Description

本発明は、通信ネットワークにおける属性の遠隔検証に関連する装置、方法、システム及びコンピュータプログラム製品に関する。より詳細には、本発明は、通信ネットワークにおけるリレーノードの属性を遠隔検証するための装置、方法、システム及びコンピュータプログラム製品に関する。

進化型パケットシステム（ＥＰＳ）は、ロングタームエボリューション（ＬＴＥ）ネットワークというブランド名で知られている。これには、Ｅ−ＵＴＲＡＮ無線アクセスネットワーク及び進化型パケットコア（ＥＰＣ）が含まれる。第３世代パートナーシッププロジェクト（３ＧＰＰ）は、ＥＰＳアーキテクチャにいわゆるリレーノード（ＲＮ）を導入する進化型パケットシステムへの強化を定義する過程にある。ＲＮを含むＥＰＳアーキテクチャは、（ＥＰＳ）リレーノードアーキテクチャとも呼ばれる。３ＧＰＰは、さらなる精緻化のために特定のＥＰＳリレーノードアーキテクチャを選択した。この選択したアーキテクチャは、３ＧＰＰ技術仕様書（ＴＳ）３６．８０６に文書化されており、「代替案２」と呼ばれるｆｔｐ：／／ｆｔｐ．３ｇｐｐ．ｏｒｇ／Ｓｐｅｃｓ／ｈｔｍｌ−ｉｎｆｏ／３６８０６．ｈｔｍを参照されたい。３ＧＰＰ ＴＳ ３６．３００にさらなる資料を見出すことができ、これについてはｆｔｐ：／／ｆｔｐ．３ｇｐｐ．ｏｒｇ／Ｓｐｅｃｓ／ｈｔｍｌ−ｉｎｆｏ／３６３００．ｈｔｍを参照されたい。このアーキテクチャの概要を、３ＧＰＰ ＴＳ ３６．３００ ｖ１０．０．０（図４．７．２−１）から引用した図１に示しており、以下これについて説明する。

ＲＮは、ユーザ装置（ＵＥ）と別の基地局（進化型ＮｏｄｅＢ、ｅＮＢ）、ドナー基地局（ＤｅＮＢ）の間のトラフィックをリレーする基地局である。ＵＥとＲＮの間のＵｕインターフェイス、及びＲＮとＤｅＮＢの間のＵｎインターフェイスは、いずれも無線インターフェイスである。ＵｕとＵｎは非常に似ている。リレーノードを含まないＥＰＳアーキテクチャにおけるＵＥとｅＮＢの間のＵｕインターフェイスは、ＵＥとＲＮの間のＵｕインターフェイスと同一であり、すなわちＵＥはＲＮの存在を認識しない。

ＲＮには２つの側面があり、ＵＥに対してはｅＮＢとして機能し、ＤｅＮＢに対してはＵＥのように機能する。ＲＮのＵＥ特性は、特にいわゆるＲＮ始動期間中に無線インターフェイスＵｎを介した接続が確立されると働き始める。これについては、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｏｒｇ／ｆｔｐ／ｔｓｇ ｒａｎ／ＷＧ２ ＲＬ２／ＴＳＧＲ２ ６９ｂｉｓ／Ｄｏｃｓ／Ｒ２−１０２０８５．ｚｉｐ．で入手可能な３ＧＰＰ文書Ｒ２−１０２０８５を参照されたい。ＲＮはネットワークに接続し、ＲＮとそのＤｅＮＢの間のＵｎ上の無線ベアラが確立されるが、この方法は、ＵＥがネットワークに接続し、Ｕｕインターフェイスを介してＵＥとｅＮＢの間に無線ベアラを確立する方法と同じである。

従って、ＲＮがＵＥとしての役割にあることを認識し、特にＲＮ始動期間中に作動するモビリティ管理エンティティ（ＭＭＥ）が存在する。このＭＭＥは、リレーＵＥのＭＭＥ、又は略してＭＭＥ−ＲＮと呼ばれる。ＭＭＥ−ＲＮは、始動期間中にＲＮを認証し、通常はこの目的でホーム加入者サーバ（ＨＳＳ）と情報をやり取りする。ＨＳＳは、ＵＥの役割にあるＲＮの加入データを含む。

正式なＵＥと同様に、ＲＮも、認証を可能にするために汎用ＩＣカード（ＵＩＣＣ）上に汎用加入者識別モジュール（ＵＳＩＭ）を含む。このＵＳＩＭは、ＵＥに挿入されたＵＳＩＭと区別するためにＵＳＩＭ−ＲＮと呼ばれる（図１には図示せず）。リレーノードを含まないＥＰＳに対して定義されるように、Ｕｎインターフェイス上のシグナリング及びユーザプレーンを保護するとともにＲＮとＭＭＥ−ＲＮの間の非アクセス層（ＮＡＳ）シグナリングを保護するためのセキュリティキーを導出し、又は適当に修正することができる。

ＥＰＳアーキテクチャにリレーノードを導入すると、新たなセキュリティ上の課題が生じる。ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｍｏｂｉ／ｆｔｐ／ｔｓｇ ｓａ／ＷＧ３ Ｓｅｃｕｒｉｔｙ／ＴＳＧＳ３ ６０ Ｍｏｎｔｒｅａｌ／Ｄｏｃｓ／で入手可能な３ＧＰＰ文書Ｓ３−１００８９６に、２０１０年７月の３ＧＰＰにおけるセキュリティに関する考察の状況を見出すことができる。

Ｅ−ＵＴＲＡＮにおいてリレーノード（ＲＮ）がドナー基地局（ＤｅＮＢ）に接続すると、ＤｅＮＢを制御する、ＥＰＣ内のリレーノードのモビリティ管理エンティティ（ＭＭＥ−ＲＮ）は、接続を要求しているエンティティがリレーノードのクラスに属し、リレーノードに必要ないくつかの特性（属性）、特にＲＮ上のセキュアな環境におけるいくつかのＲＮ固有機能の実行、及びＲＮプラットフォームの完全性（すなわち、ハードウェア（ＨＷ）及びソフトウェア（ＳＷ）の正確性）を満たすかどうかを検証する必要がある。

しかしながら、本技術仕様によるＭＭＥ−ＲＮは、必要なＲＮ属性を直接検証するための手段を有していない。

この問題を解決するための１つの方法として、ＤｅＮＢ及びＭＭＥ−ＲＮなどの関連するネットワークノードの、これらのネットワークノードがこのＲＮ属性の検証を直接実行できるようにする機能を強化することができる。このような解決策が、３ＧＰＰにより、ｈｔｔｐ：／／ｗｗｗ．３ｇｐｐ．ｍｏｂｉ／ｆｔｐ／ｔｓｇ ｓａ／ＷＧ３ Ｓｅｃｕｒｉｔｙ／ＴＳＧＳ３ ６０ Ｍｏｎｔｒｅａｌ／Ｄｏｃｓ／から入手可能な文書Ｓ３−１００８９６に公開されている。Ｓ３−１００８９６によれば、証明書を使用してＤｅＮＢ及びＭＭＥ−ＲＮの特定の機能を強化することができる。

非公開特許出願ＰＣＴ／ＥＰ２０１０／０５８７４９によるこの問題の別の解決策は、Ｕｎインターフェイス上のアクセス層を保護するための鍵を、セキュアなチャネルを介してＵＳＩＭ−ＲＮから取得するという点で、Ｓ３−１００８９６のセクション７．５の解決策を強化するものである。

欧州特許出願２０１０／０５８７４９号明細書

３ＧＰＰ技術仕様書（ＴＳ）３６．８０６ ３ＧＰＰ ＴＳ ３６．３００ ３ＧＰＰ文書Ｒ２−１０２０８５ ３ＧＰＰ文書Ｓ３−１００８９６ ３ＧＰＰ ＴＳ ３３．４０１ ＥＴＳＩ ＴＳ １０２ ４８４「スマートカード、ＵＩＣＣとエンドポイント端末との間のセキュアなチャネル」 ＴＳ ３３．３１０ ＩＥＴＦ ＲＦＣ２５６０

本発明の目的は、先行技術を改善することである。

具体的には、ネットワーク移行の観点からすれば、今日のＬＴＥネットワークにあるのと同程度のネットワークエンティティを残すことが望ましいと理解されたい。

このことは、ＲＮに近いエンティティが、必要なＲＮの属性の検証を行なうならば、かつ、今日の標準規格に従う手続が、検証がうまくいった事実をＭＭＥ−ＲＮ及びＤｅＮＢに伝えるために使用されるならば、可能となる。

このリレー強化ＥＰＳにおける問題は、任意の通信ネットワークにおいても同様に生じ得る。

本発明の第１の態様によれば、装置が提供され、この装置は、要求者デバイスから受け取った要求者特性情報が所定の要求者属性に対応するかどうかをチェックするように構成された特性チェック手段と、この特性チェック手段によりチェックした要求者特性情報が所定の要求者属性に対応する場合にのみ肯定の結果を取得するように構成された取得手段と、装置に記憶された所定の要求者永久鍵から第１の要求者中間鍵を生成するように構成された鍵生成手段と、安全なプロトコルを使用して第１の要求者中間鍵を要求者デバイスに供給するように構成された供給手段とを備え、鍵生成手段及び供給手段の少なくとも一方は、結果が肯定の場合にのみ、第１の要求者中間鍵の生成及び供給をそれぞれ行うように構成される。

この装置では、安全なプロトコルを、証明書に基づく暗号プロトコルとすることができる。

この装置は、証明書が有効であるかどうかをチェックするように構成された証明書チェック手段をさらに備えることができ、取得手段を、証明書が有効な場合にのみ肯定の結果を取得するようにさらに構成することができる。

この装置では、要求者特性情報を証明書に含めることができる。

この装置は、安全なプロトコルの鍵及び要求者永久鍵の少なくとも一方を安全に記憶して、対応する許可を有していない装置から安全に記憶された鍵を引き出せないようにするよう構成された安全記憶手段をさらに備えることができる。

この装置では、鍵生成手段を、認証及び鍵共有プロトコルを使用して第１の要求者中間鍵を生成するように構成することができる。

本発明の第２の態様によれば、第１の態様による装置を含む改ざん防止モジュールが提供される。

本発明の第３の態様によれば、装置が提供され、この装置は、安全なプロトコルを使用して装置の要求者特性情報を評価デバイスに供給するように構成された特性情報供給手段と、有効な要求者セッション鍵に基づいて、評価デバイスとは異なる実施デバイスとの通信を確立するように構成された確立手段とを備え、有効な要求者セッション鍵は、評価デバイスから受け取った第１の要求者中間鍵に基づく。

この装置では、安全なプロトコルを、証明書に基づく暗号プロトコルとすることができる。

この装置では、要求者特性情報が、証明書に含まれる。

この装置では、要求者特性情報が、安全なプロトコルの鍵を安全に記憶して、対応する許可を有していない装置から鍵を引き出せないようにするよう構成された安全記憶手段が装置内に存在すること、装置のハードウェア及びソフトウェアの完全性を保証する自律的プラットフォーム検証を実行する能力、及び装置により、存在及び能力とは別の所定の機能が与えられることのうちの少なくとも１つを満たすか否かについての情報を含むことができる。

この装置は、第１の要求者中間鍵から有効な要求者セッション鍵を生成するように構成された鍵生成手段をさらに備えることができ、確立手段を、有効な要求者セッション鍵を使用して実施デバイスとの通信を確立するように構成することができる。

この装置は、有効な要求者セッション鍵に基づいて、実施デバイスとの通信を保護するように構成することができる。

本発明の第４の態様によれば、本発明の第３の態様による装置を含むリレーノードが提供される。

本発明の第５の態様によれば、装置が提供され、この装置は、受け取ったデバイスクラス情報が所定のデバイスクラスに対応するかどうかを検証するように構成された検証手段と、この検証手段によりチェックしたデバイスクラス情報が所定のデバイスクラスに対応する場合にのみ肯定の結果を取得するように構成された取得手段と、装置内に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するように構成された鍵生成手段と、第２の要求者セッション鍵及び結果を実施デバイスに供給するように構成された供給手段とを備え、鍵生成手段及び供給手段の少なくとも一方は、結果が肯定の場合にのみ第２の要求者セッション鍵の生成及び供給をそれぞれ行うように構成される。

本発明の第６の態様によれば、要求者との間に、この要求者とは異なる検証デバイスから受け取った第２の要求者セッション鍵が要求者の有効な要求者セッション鍵に対応することを必要とする通信を確立するように構成された確立手段と、検証デバイスから受け取った結果が肯定でありかつ確立手段が通信を確立した場合にのみ、要求者の通信リソースへのアクセスを許可するように構成された許可手段とを備えた装置が提供される。

この装置は、第２の要求者セッション鍵から第３の要求者セッション鍵を生成するように構成された鍵生成手段をさらに備えることができ、通信は、第３の要求者セッション鍵が有効な要求者セッション鍵に一致することを必要とすることができる。

本発明の第７の態様によれば、第１の態様による装置を含む評価装置と、第３の態様による装置を含む要求者装置と、検証装置と、実施装置とを備えたシステムが提供され、評価装置、要求者装置及び検証装置は互いに異なり、実施装置は、評価装置及び要求者装置とは異なり、検証装置は、この検証装置に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するように構成された鍵生成手段と、この第２の要求者セッション鍵を実施装置に供給するように構成された供給手段とを備え、実施装置は、検証装置から受け取った第２の要求者セッション鍵が要求者装置の有効な要求者セッション鍵に対応することを必要とする通信を要求者装置との間に確立するように構成された確立手段と、この確立手段が通信を確立した場合にのみ、要求者装置の通信リソースへのアクセスを許可するように構成された許可手段とを備え、要求者装置は、評価装置の要求者デバイスを含み、評価装置は、要求者装置の評価デバイスを含み、要求者装置により供給される要求者特性情報は、評価装置により受け取られる要求者特性情報に対応し、評価装置により供給される第１の要求者中間鍵は、要求者装置により受け取られる第１の要求者中間鍵に対応し、評価装置の安全なプロトコルは、要求者装置の安全なプロトコルと同じものである。

このシステムでは、検証デバイスが第５の態様による装置を含むこと、及び実施デバイスが第６の態様による装置を含むことの少なくとも一方を満たすことができる。

第８の態様によれば、方法が提供され、この方法は、要求者デバイスから受け取った要求者特性情報が所定の要求者属性に対応するかどうかをチェックするステップと、このチェックステップでチェックした要求者特性情報が所定の要求者属性に対応する場合にのみ肯定の結果を取得するステップと、方法を実行する装置に記憶された所定の要求者永久鍵から第１の要求者中間鍵を生成するステップと、安全なプロトコルを使用して第１の要求者中間鍵を要求者デバイスに供給するステップとを含み、生成ステップ及び供給ステップの少なくとも一方は、結果が肯定の場合にのみ実行される。

この方法では、安全なプロトコルを、証明書に基づく暗号プロトコルとすることができる。

この方法は、証明書が有効であるかどうかをチェックするステップをさらに含むことができ、取得ステップの結果を、証明書が有効な場合にのみ肯定の結果とすることができる。

この方法では、要求者特性情報を証明書に含めることができる。

この方法は、安全なプロトコルの鍵及び要求者永久鍵の少なくとも一方を安全に記憶して、方法を実行する対応する許可を有していない装置から安全に記憶された鍵を引き出せないようにするステップをさらに含むことができる。

この方法では、第１の要求者中間鍵を生成するステップが、認証及び鍵共有プロトコルを使用することができる。

この方法は、評価方法とすることができる。

本発明の第９の態様によれば、方法が提供され、この方法は、安全なプロトコルを使用して、この方法を実行する装置の要求者特性情報を評価デバイスに供給するステップと、有効な要求者セッション鍵に基づいて、評価デバイスとは異なる実施デバイスとの通信を確立するステップとを含み、有効な要求者セッション鍵は、評価デバイスから受け取った第１の要求者中間鍵に基づく。

この方法では、安全なプロトコルを、証明書に基づく暗号プロトコルとすることができる。

この方法では、要求者特性情報を証明書に含めることができる。

この方法では、要求者特性情報が、安全なプロトコルの鍵を安全に記憶して、対応する許可を有していない装置から鍵を引き出せないようにするよう構成された安全記憶手段が装置内に存在すること、装置のハードウェア及びソフトウェアの完全性を保証する自律的プラットフォーム検証を実行する能力、及び装置により、存在及び能力とは別の所定の機能が与えられること、のうちの少なくとも１つを満たすか否かについての情報を含むことができる。

この方法は、第１の要求者中間鍵から有効な要求者セッション鍵を生成するステップをさらに含むことができ、確立ステップは、有効な要求者セッション鍵を使用して実施デバイスとの通信を確立することができる。

この方法は、有効な要求者セッション鍵に基づいて、実施デバイスとの通信を保護するステップをさらに含むことができる。

この方法は、要求者方法とすることができる。

本発明の第１０の態様によれば、方法が提供され、この方法は、受け取ったデバイスクラス情報が所定のデバイスクラスに対応するかどうかを検証するステップと、この検証ステップでチェックしたデバイスクラス情報が所定のデバイスクラスに対応する場合にのみ肯定の結果を取得するステップと、方法を実行する装置内に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するステップと、第２の要求者セッション鍵及び結果を実施デバイスに供給するステップとを含み、生成ステップ及び供給ステップの少なくとも一方は、結果が肯定の場合にのみ実行される。

この方法は、検証方法とすることができる。

本発明の第１１の態様によれば、要求者との間に、この要求者とは異なる検証デバイスから受け取った第２の要求者セッション鍵が要求者の有効な要求者セッション鍵に対応することを必要とする通信を確立するステップと、検証デバイスから受け取った結果が肯定でありかつ通信が確立された場合にのみ、要求者の通信リソースへのアクセスを許可するステップとを含む方法が提供される。

この方法は、第２の要求者セッション鍵から第３の要求者セッション鍵を生成するステップをさらに含むことができ、通信は、第３の要求者セッション鍵が有効な要求者セッション鍵に一致することを必要とすることができる。

この方法は、実施方法とすることができる。

本発明の第１２の態様によれば、第８の態様による方法を含む評価方法を評価装置によって実行するステップと、第９の態様による方法を含む要求者方法を要求者装置によって実行するステップと、検証装置によって検証方法を実行するステップと、実施装置によって実施方法を実行するステップとを含む方法が提供され、評価装置、要求者装置及び検証装置は互いに異なり、実施装置は、評価装置及び要求者装置とは異なり、検証方法は、検証装置に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するステップと、この第２の要求者セッション鍵を実施装置に供給するステップとを含み、実施方法は、検証装置から受け取った第２の要求者セッション鍵が要求者装置の有効な要求者セッション鍵に対応することを必要とする通信を要求者装置との間に確立するステップと、この通信が確立された場合にのみ、要求者装置の通信リソースへのアクセスを許可するステップとを含み、要求者方法は、評価方法の要求者デバイスを含み、評価方法は、要求者方法の評価デバイスを含み、要求者装置により供給される要求者特性情報は、評価装置により受け取られる要求者特性情報に対応し、評価装置により供給される第１の要求者中間鍵は、要求者装置により受け取られる第１の要求者中間鍵に対応し、評価装置の安全なプロトコルは、要求者装置の安全なプロトコルと同じものである。

この方法では、検証方法が第１０の態様による方法を含むこと、及び実施方法が第１１の態様による方法を含むことの少なくとも一方を満たすことができる。

この方法は、遠隔検証方法とすることができる。

本発明の第１３の態様によれば、コンピュータ上で実行された時に、第８から第１２の態様のいずれかに記載の方法を動作させるコンピュータ実行可能要素を含むコンピュータプログラム製品が提供される。

このコンピュータプログラム製品は、コンピュータ可読記憶媒体として具体化することができる。

本発明の第１４の態様によれば、装置が提供され、この装置は、要求者デバイスから受け取った要求者特性情報が、所定の要求者属性に対応するかどうかをチェックするように構成された特性チェックプロセッサと、この特性チェックプロセッサによりチェックした要求者特性情報が所定の要求者属性に対応する場合にのみ肯定の結果を取得するように構成された取得プロセッサと、装置に記憶された所定の要求者永久鍵から第１の要求者中間鍵を生成するように構成された鍵生成プロセッサと、安全なプロトコルを使用して第１の要求者中間鍵を要求者デバイスに供給するように構成された供給プロセッサとを備え、鍵生成プロセッサ及び供給プロセッサの少なくとも一方は、結果が肯定の場合にのみ、第１の要求者中間鍵の生成及び供給をそれぞれ行うように構成される。

この装置では、安全なプロトコルを、証明書に基づく暗号プロトコルとすることができる。

この装置は、証明書が有効であるかどうかをチェックするように構成された証明書チェックプロセッサをさらに備えることができ、取得プロセッサを、証明書が有効な場合にのみ肯定の結果を取得するようにさらに構成することができる。

この装置では、要求者特性情報を証明書に含めることができる。

この装置は、安全なプロトコルの鍵及び要求者永久鍵の少なくとも一方を安全に記憶して、対応する許可を有していない装置から安全に記憶された鍵を引き出せないようにするよう構成された安全な記憶装置をさらに備えることができる。

この装置では、鍵生成プロセッサを、認証及び鍵共有プロトコルを使用して第１の要求者中間鍵を生成するように構成することができる。

本発明の第１５の態様によれば、第１４の態様による装置を含む改ざん防止モジュールが提供される。

本発明の第１６の態様によれば、装置が提供され、この装置は、安全なプロトコルを使用して装置の要求者特性情報を評価デバイスに供給するように構成された特性情報供給プロセッサと、有効な要求者セッション鍵に基づいて、評価デバイスとは異なる実施デバイスとの通信を確立するように構成された確立プロセッサとを備え、有効な要求者セッション鍵は、評価デバイスから受け取った第１の要求者中間鍵に基づく。

この装置では、安全なプロトコルを、証明書に基づく暗号プロトコルとすることができる。

この装置では、要求者特性情報が、証明書に含まれる。

この装置では、要求者特性情報が、安全なプロトコルの鍵を安全に記憶して、対応する許可を有していない装置から鍵を引き出せないようにするよう構成された安全な記憶装置が装置内に存在すること、装置のハードウェア及びソフトウェアの完全性を保証する自律的プラットフォーム検証を実行する能力、及び装置により、存在及び能力とは別の所定の機能が与えられることのうちの少なくとも１つを満たすか否かについての情報を含むことができる。

この装置は、第１の要求者中間鍵から有効な要求者セッション鍵を生成するように構成された鍵生成プロセッサをさらに備えることができ、確立プロセッサを、有効な要求者セッション鍵を使用して実施デバイスとの通信を確立するように構成することができる。

この装置は、有効な要求者セッション鍵に基づいて、実施デバイスとの通信を保護するように構成することができる。

本発明の第１７の態様によれば、本発明の第１６の態様による装置を含むリレーノードが提供される。

本発明の第１８の態様によれば装置が提供され、この装置は、受け取ったデバイスクラス情報が所定のデバイスクラスに対応するかどうかを検証するように構成された検証プロセッサと、この検証プロセッサによりチェックしたデバイスクラス情報が所定のデバイスクラスに対応する場合にのみ肯定の結果を取得するように構成された取得プロセッサと、装置内に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するように構成された鍵生成プロセッサと、第２の要求者セッション鍵及び結果を実施デバイスに供給するように構成された供給プロセッサとを備え、鍵生成プロセッサ及び供給プロセッサの少なくとも一方は、結果が肯定の場合にのみ第２の要求者セッション鍵の生成及び供給をそれぞれ行うように構成される。

本発明の第１９の態様によれば、要求者との間に、この要求者とは異なる検証デバイスから受け取った第２の要求者セッション鍵が要求者の有効な要求者セッション鍵に対応することを必要とする通信を確立するように構成された確立プロセッサと、検証デバイスから受け取った結果が肯定でありかつ確立プロセッサが通信を確立した場合にのみ、要求者の通信リソースへのアクセスを許可するように構成された許可プロセッサとを備えた装置が提供される。

この装置は、第２の要求者セッション鍵から第３の要求者セッション鍵を生成するように構成された鍵生成プロセッサをさらに備えることができ、通信は、第３の要求者セッション鍵が有効な要求者セッション鍵に一致することを必要とすることができる。

発明の第２０の態様によれば、第１４の態様による装置を含む評価装置と、第１５の態様による装置を含む要求者装置と、検証装置と、実施装置とを備えたシステムが提供され、評価装置、要求者装置及び検証装置は互いに異なり、実施装置は、評価装置及び要求者装置とは異なり、検証装置は、この検証装置に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するように構成された鍵生成プロセッサと、この第２の要求者セッション鍵を実施装置に供給するように構成された供給プロセッサとを備え、実施装置は、検証装置から受け取った第２の要求者セッション鍵が要求者装置の有効な要求者セッション鍵に対応することを必要とする通信を要求者装置との間に確立するように構成された確立プロセッサと、この確立プロセッサが通信を確立した場合にのみ、要求者装置の通信リソースへのアクセスを許可するように構成された許可プロセッサとを備え、要求者装置は、評価装置の要求者デバイスを含み、評価装置は、要求者装置の評価デバイスを含み、要求者装置により供給される要求者特性情報は、評価装置により受け取られる要求者特性情報に対応し、評価装置により供給される第１の要求者中間鍵は、要求者装置により受け取られる第１の要求者中間鍵に対応し、評価装置の安全なプロトコルは、要求者装置の安全なプロトコルと同じものである。

このシステムでは、検証デバイスが第１８の態様による装置を含むこと、及び実施デバイスが第１９の態様による装置を含むことの少なくとも一方を満たすことができる。

上記の改良型はいずれも、代替案を除外すると明確に記載していない限り、これらの改良型が参照するそれぞれの態様に単独で又は組み合わせて適用できると理解されたい。

一般的な通信ネットワークでは、例えば、本発明による手順に４つのエンティティが関与することができる。
・要求者（Ｃｌａ）：ネットワークリソースを要求し、属性の組により定義されるエンティティのクラスのメンバである。
・遠隔検証エンティティ（ＲＶＥ）：Ｃｌａのクラスメンバシップに基づいてリソース要求の許容性を決定する必要があるが、Ｃｌａに必要な属性を直接検証することはできない。
・ローカル検証エンティティ（ＬＶＥ）：必要なＣｌａの属性の検証を実行する。
・実施ポイント（ＥｎＰ）：許容できる要求者のみがリソースを取得することを保証する。

本発明による実施形態では、特に以下の問題点の少なくともいくつかが解決される。
ａ）好適なローカル検証エンティティ（ＬＶＥ）の例を特定すること
ｂ）ＬＶＥがＣｌａの属性を検証できるようにする手段を特定すること
ｃ）既に他のコンテキストから利用可能なＬＶＥとＲＶＥの間の好適なプロトコル手段により、ＲＮ属性の検証に成功した事実をＬＶＥからＲＶＥに伝達すること
ｄ）ＥｎＰが、許容できる要求者のみが実際にリソースを取得することを実施できるようにすること

この解決策は、ＭＭＥ−ＲＮとすることができるＲＶＥがオフロードされるという追加の利点をもたらすことができる。

これらの一般的な通信ネットワークの問題が、リレーノードを遠隔検証する実施形態に関連する場合、上述した解決される問題は以下のように理解される。
ａ）好適なローカル検証エンティティ（ＬＶＥ）を識別すること
ｂ）ＬＶＥがＲＮの属性を検証できるようにする手段を識別すること
ｃ）ＲＮ属性の検証に成功した事実をＬＶＥからＭＭＥ−ＲＮに伝達すること
ｄ）ＤｅＮＢが、リレーノードのクラスの真のメンバのみが実際にリレーノードとして接続できることを実施できるようにすること

添付図面とともに検討すべき以下の本発明の好ましい実施形態についての詳細な説明から、さらなる詳細、特徴、目的及び利点が明らかになる。

３ＧＰＰ ＴＳ ３６．３００ ｖ１０．０．０によるＥＰＳアーキテクチャを示す図である。 本発明の実施形態によるシステムを示す図である。 本発明の実施形態による方法を示す図である。 本発明の実施形態によるＬＶＥを示す図である。 本発明の実施形態による要求者を示す図である。 本発明の実施形態によるＲＶＥを示す図である。 本発明の実施形態によるＥｎＰを示す図である。 本発明の実施形態によるＬＶＥの動作方法を示す図である。 本発明の実施形態による要求者の動作方法を示す図である。 本発明の実施形態によるＲＶＥの動作方法を示す図である。 本発明の実施形態によるＥｎＰの動作方法を示す図である。

以下、添付図面を参照しながら本発明のいくつかの実施形態を詳細に説明するが、他に指定しない限り、これらの実施形態の特徴は互いに自由に組み合わせることができる。しかしながら、これらの実施形態の説明はほんの一例として示すものであり、開示する詳細に本発明を限定するものであるとは決して理解すべきでない。

さらに、装置は、対応する方法を実行するように構成されているが、場合によっては装置のみ又は方法のみについて説明していると理解されたい。

図２に示すように、本発明の実施形態によるシステムは、ローカル検証エンティティ（ＬＶＥ）１００、要求者（Ｃｌａ）２００、遠隔検証エンティティ（ＲＶＥ）３００、及び実施ポイント（ＥｎＰ）４００を含むことができる。ＬＶＥ１００とＣｌａ２００は互いに動作可能に接続され、ＲＶＥ３００とＥｎＰ４００は互いに動作可能に接続される。また、本発明の実施形態による方法が正常に行われると、Ｃｌａ２００とＥｎＰ４００が互いに動作可能に接続される。

なお、図２に示す動作可能な接続は機能的接続である。この機能的接続が依拠する物理接続は、機能的接続とは異なることがある。

また、図２のブロック１００、２００、３００及び４００は機能ブロックである。ＬＶＥ１００、Ｃｌａ２００及びＲＶＥ３００は互いに異なる。ＥｎＰ４００は、ＬＶＥ１００及びＣｌａ２００とは異なる。いくつかの実施形態では、ＥｎＰ４００がＲＶＥ３００と異なるが、他の実施形態では、これらが同じ機能ブロックに属する。機能ブロックは、通信ネットワーク内で異なってアドレス指定される場合には異なることがある。

ＬＶＥ１００、Ｃｌａ２００、ＲＶＥ３００及びＥｎＰ４００の各々は、異なるハードウェアに基づくこともでき、或いはこれらのエンティティの一部又は全部が同じハードウェアに基づくこともできる。

図３に、本発明の実施形態による方法を示す。

ステップＳ８１０によれば、ＬＶＥ１００によって評価方法が実施される。この評価方法は、要求者２００の要求者方法Ｓ８２０と相互作用する。

同時に、ＲＶＥ３００によって検証方法Ｓ８３０が実施される。この検証方法は、ＥｎＰ４００の実施方法Ｓ８４０と相互作用する。

ステップＳ８１０、Ｓ８２０、Ｓ８３０及びＳ８４０が正常に実行されると、実施ポイント４００によって要求者２００にリソースが与えられる（ステップＳ８５０）。

ステップＳ８１０、Ｓ８２０、Ｓ８３０及びＳ８４０による方法の各々のさらなる詳細については、以下で図８〜図１１を参照しながら示す。

視点を変えて相互作用に注目すると、本発明の実施形態による方法は、複合ステップ１．１〜１．５によって説明するように機能することができる。

１．１ 属性の組により定義されるエンティティのクラスＣのメンバである要求者（Ｃｌａ）は、遠隔検証エンティティ（ＲＶＥ）により制御されるネットワークリソースを要求しようとする場合、まずローカル検証エンティティ（ＬＶＥ）とのセキュアな接続を確立する。この接続を確立する過程で、ＬＶＥはＣｌａを認証し、Ｃｌａの属性をチェックすることによってＣｌａがＣのメンバであることを検証する。これらのステップは、図３のステップＳ８１０及びＳ８２０に含まれる。

１．２ ＲＶＥの検証方法は、例えばＣｌａからのリソースを求める要求によって開始することができる。Ｃｌａのクラスメンバシップに基づいてリソース要求の許容性を決定する必要があるＲＶＥは、このような要求を受け取ると、ＬＶＥとの認証及び鍵共有プロトコルを実行して、ＬＶＥとＲＶＥの間で互いに共有されるセッション鍵を確立させる。これらのステップは、図３のステップＳ８１０及びＳ８３０に含まれる。

１．３ ＬＶＥは、ステップ１．１のクラスメンバシップの検証に成功した場合にのみ、セッション鍵又はこのあらゆる派生物をＣｌａに転送する。このステップは、図３のステップＳ８１０及びＳ８２０に含まれる。

１．４ ＲＶＥは、セッション鍵又はこのあらゆる派生物をＥｎＰに転送して、これらがクラスＣの要求者のリソース要求を実施するのに適している旨を示す。このステップは、図３のステップＳ８３０及びＳ８４０に含まれる。

１．５ ＥｎＰは、適当なプロトコル手段を通じてＣｌａがセッション鍵を所有していることを検証できる場合にのみ、Ｃｌａによるリソース要求を承認する。このステップは、図３のステップＳ８２０及びＳ８４０に含まれる。

以下、エンティティＬＶＥ、Ｃｌａ、ＲＶＥ及びＥｎＰについてより詳細に説明する。

図４に、本発明によるＬＶＥ１００の実施形態を示す。

図４によれば、特性チェック手段１１０が、要求者から受け取った特性情報が所定の属性に対応するかどうかをチェックする。例えば、この特性チェック手段は、要求者がリレーノードのクラスに属するか否かをチェックすることができる。

特性チェック手段が、受け取った特性情報が所定のクラスに属することを検証した場合にのみ、取得手段が肯定の結果を取得する。肯定の結果の代わりに、フラグを真（ｔｒｕｅ）にセットすること、又は別の論理的に同等の条件を満たすこともできる。

鍵生成手段１３０は、ＬＶＥに記憶された所定の鍵から鍵（第１の要求者中間鍵）を生成する。この所定の鍵は、改ざんを防止する形でＬＶＥ内に恒久的に記憶されることが好ましい。

供給手段１４０は、この生成された鍵を要求者に供給する。

鍵生成手段１３０及び供給手段１４０の少なくとも一方は、取得手段１２０が取得した結果が肯定の場合にのみ、それぞれ生成及び供給を行う。

図５に、本発明による要求者（Ｃｌａ）２００の実施形態を示す。

特性情報供給手段２１０は、安全なプロトコルを使用して、要求者の特性情報を評価デバイスに供給する。例えば、この特性情報は、要求者がリレーノードのクラスに属していることであってもよい。

要求者が評価デバイスから鍵を受け取ると、確立手段２２０が、受け取った鍵又はその派生物に基づいて、評価デバイスとは異なる実施デバイスとの通信を確立することができる。確立手段２２０が通信の確立に成功すると、実施デバイス４００が、要求者２００にリソースへのアクセスを許可することができる。

図６に、本発明の実施形態によるＲＶＥを示す。

検証手段３１０は、受け取ったデバイスクラス情報が所定のデバイスクラスに対応するかどうかを検証する。例えば、検証手段３１０は、デバイスクラス情報がリレーノードを示すかどうかをチェックすることができる。デバイスクラス情報は、ＬＴＥ内のホーム加入者サーバ（ＨＳＳ）などのバックエンドサーバから受け取ることができる。

取得手段３２０は、検証手段がチェックしたデバイスクラス情報が所定のデバイスクラスに対応する場合にのみ肯定の結果を取得する。或いは、取得手段３２０は、フラグを肯定に設定してもよく、又は他の何らかの論理的に同等の動作を実行してもよい。

鍵生成手段３３０は、装置内に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成する。

供給手段３４０は、この第２の要求者セッション鍵、及び取得手段の結果を実施デバイスに供給する。

鍵生成手段３３０及び供給手段３４０の少なくとも一方は、結果が肯定の場合にのみ、それぞれ第２の要求者セッション鍵の生成及び供給を行う。

図７に、本発明の実施形態によるＥｎＰ４００を示す。

確立手段４１０は、要求者との間に、要求者とは異なる検証デバイスから受け取った第２の要求者セッション鍵が要求者の有効な要求者セッション鍵に対応することを必要とする通信を確立する。

一方の鍵は、所定のルールに従って一方の鍵から他方の鍵を導出できる場合に他方の鍵に対応する。このようなルールは、それぞれのデバイスの識別符号などを含むことができる。具体的には、いくつかの実施形態では、一方の鍵が他方の鍵に一致することが対応する鍵の意味である。

許可手段４２０は、検証デバイスから受け取った結果が肯定でありかつ確立手段が通信を確立した場合にのみ、要求者の通信リソースへのアクセスを許可する。

ＬＶＥ１００、Ｃｌａ２００、ＲＶＥ３００及びＥｎＰ４００の各々は、属性、鍵、プログラムコードなどを記憶するように構成された、ハードディスク、ＣＤ、ＤＶＤ、ランダムアクセスメモリ（ＲＡＭ）又は読み出し専用メモリ（ＲＯＭ）などの記憶装置を含むことができる。さらに、これらの各々は、接続されたエンティティと通信するために１又はそれ以上の送信機及び受信機を含むことができる。

図４〜図７に示すモジュールは、機能モジュールである。これらの各々は、別個のハードウェアに基づくものであってもよく、或いはこれらの一部又は全部が同じハードウェアに基づくものであってもよい。さらに、ソフトウェアで実現される場合、これらの各々を別個のプログラムコードによって実現してもよく、或いはこれらの一部又は全部が同じプログラムコードに属していてもよい。

図８〜図１１に、本発明の実施形態によるＳ８１０〜Ｓ８４０の方法の詳細をそれぞれ示す。

図８には、本発明の実施形態による、ＬＶＥ１００などのＬＶＥにより実行されることが好ましい図３のステップＳ８１０に対応する方法を示している。

ステップＳ１１０において、ＬＶＥが初期化される。ステップＳ１２０において、ＬＶＥが、要求者デバイスから受け取った要求者特性情報が所定の要求者属性に対応するかどうかをチェックする。ステップＳ１３０において結果が取得され、この結果は、チェックステップＳ１２０でチェックした要求者特性情報が所定の要求者属性に対応する場合にのみ肯定となる。

ステップＳ１４０において、取得ステップＳ１３０の結果が肯定であるかどうか、又は論理的に同等の条件が満たされてフラグが真（ｔｒｕｅ）になっているかどうかをチェックする。満たされていない場合、この方法は終了する（Ｓ１８０）。

満たされている場合、ステップＳ１５０により、ＬＶＥ内に記憶された所定の要求者永久鍵から第１の要求者中間鍵を生成する。ステップ１６０により、安全なプロトコルを使用して、この第１の要求者中間鍵を要求者に供給する。

上記とは別に又は上記に加えて、いくつかの実施形態では、ステップＳ１５０とＳ１６０の間にステップＳ１４０を実行することもできる。

図９には、本発明の実施形態による、要求者２００などの要求者により実行されることが好ましい図３のステップＳ８２０に対応する方法を示している。

ステップＳ２１０によれば、この方法を実行する要求者を初期化し、セルフチェックを実行し、要求者の属性を取得することによって方法が開始される。安全なプロトコルを使用して、要求者の特性情報をＬＶＥに供給する（ステップＳ２２０）。

ステップＳ２３０により、ＥｎＰなどの、ＬＶＥ以外のエンティティとの通信を確立する。この通信は、ＬＶＥから受け取った鍵に基づくセッション鍵に基づく。例えば、セッション鍵は、ＬＶＥから受け取った鍵と同じものであってもよく、或いはＬＶＥから受け取った鍵に基づいてＣｌａがセッション鍵を生成してもよい。その後、この方法は終了する（ステップＳ２４０）。すなわち、ＣｌａがＥｎＰとの通信を正常に確立した場合、ＥｎＰは、要求者にリソースへのアクセスを許可することができる。

図１０には、本発明の実施形態による、ＲＶＥ３００などのＲＶＥにより実行されることが好ましい図３のステップＳ８３０に対応する方法を示している。

ステップＳ３１０において、方法が初期化される。例えば、ＲＶＥは、リソースへのアクセス許可要求をデバイスから受け取ることができる。この要求は、ＵＳＩＭ−ＲＮの識別符号などの、デバイスに関連するアイデンティティを含む。デバイスが属するクラスが、ホーム加入者サーバ（ＨＳＳ）などのバックエンドサーバ又は独自のデータベースに記憶されている場合、ＲＶＥは、この情報をＨＳＳ又は独自のデータベースから読み出すことができる。

ステップＳ３２０において、受け取ったデバイスクラス情報の特性情報が所定のデバイスクラスに対応するかどうかを検証する。ステップＳ３３０において結果が取得され、この結果は、検証ステップＳ３２０でチェックした受け取ったデバイスクラス情報が所定のデバイスクラス情報に対応する場合にのみ肯定となる。

ステップＳ３４０において、取得ステップＳ３３０の結果が肯定であるかどうか、又は論理的に同等の条件が満たされてフラグが真（ｔｒｕｅ）になっているかどうかをチェックする。満たされていない場合、この方法は終了する（Ｓ３８０）。

満たされている場合、ステップＳ３５０により、ＲＶＥ内に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成する。ステップ３６０により、好ましくは安全なプロトコルを使用して、第２の要求者セッション鍵及び結果がＥｎＰに供給される。

上記とは別に又は上記に加えて、いくつかの実施形態では、ステップＳ３５０とＳ３６０の間にステップＳ３４０を実行することもできる。

本発明の実施形態によるシステムのいくつかの実装では、ＲＶＥがＥｎＰに結果を提供しない。例えば、全てのＣｌａがリソースを要求していることがＬＶＥのローカル検証のみによって推測的に分かる場合、ＥｎＰに結果を転送する必要はない。一方、様々なタイプのＣｌａがリソースを要求し、これらの一部がＬＶＥによって検証されない場合、ＥｎＰに結果を提供することで、検証されたＣｌａのみがリソースにアクセスできることを確実にすることができる。この状況は、リリースのアップグレード中などに生じることがある。

図１１には、本発明の実施形態による、ＥｎＰ４００などのＥｎＰにより実行されることが好ましい図３のステップＳ８４０に対応する方法を示している。

ステップＳ４１０によれば、この方法を実行するＥｎＰを初期化し、セルフチェックなどを実行することにより、方法が開始される。

ステップＳ４２０において、要求者との通信を確立する。この通信では、ＲＶＥから受け取った第２の要求者セッション鍵が要求者の有効な要求者セッション鍵に対応する必要がある。例えば、いくつかの実施形態では、これらの鍵が一致しなければならず、他の実施形態では、ＥｎＰが第２の要求者セッション鍵から第３の要求者セッション鍵を生成し、この第３の要求者セッション鍵が有効な要求者セッション鍵に一致しなければならない。

ステップＳ４３０において、要求者との通信が正常に確立されたかどうかをチェックする。ステップＳ４４０において、ＲＶＥから受け取った結果又は対応するフラグが肯定であるかどうか、又は対応する論理条件が満たされて受け取ったフラグが設定されているかどうかがチェックされる。これらの条件の一方が満たされていない場合、この方法は終了する（Ｓ４７０、Ｓ４８０）。

満たされている場合、ステップＳ４５０により、ＥｎＰが、要求されたリソースへのアクセスを要求者に許可する。ステップＳ４６０において、この方法は終了する。

ＲＶＥの方法８３０（図１０）に関して説明したように、本発明によるシステムのいくつかの実施形態では、全ての要求者がリソースを要求していることがＬＶＥのローカル検証のみによって確実である場合、結果が肯定であるかどうかをチェックするステップＳ４４０を省くことができる。

上述の方法及び装置のいくつかの変形例も可能である。

ＣｌａとＬＶＥの間の接続は、証明書ベースの暗号プロトコルを使用して保護及び確立することができる。いくつかの例として、インターネット鍵交換（ＩＫＥ）、ＩＫＥバージョン２、及びトランスポートレイヤセキュリティ（ＴＬＳ）が挙げられる。

ＬＶＥは、Ｃｌａの認証されたアイデンティティを、アイデンティティ及びこれらの関連する属性を含むテーブルに照らしてチェックすることにより、Ｃｌａの属性を検証することができる。これに関して、ＬＶＥは、証明書内のパラメータをチェックすることにより、Ｃｌａの属性を検証することもできる。ＬＶＥは、ＯＣＳＰ（オンライン証明書ステータスプロトコル−ＲＦＣ２５６０）を使用して、Ｃｌａの証明書の有効性をチェックすることもできる。

ＬＶＥは、攻撃者がＬＶＥから秘密鍵材料を引き出せないようにするセキュアな環境を含むことができる。

クラスＣの特性を示す属性は、攻撃者がＣのメンバから秘密鍵材料を引き出せないようにするセキュアな環境の存在、Ｃのメンバを実現するＨＷ及びＳＷの完全性を保証する自律的プラットフォーム検証を実行する能力、及び要求者にとって必要なリレーノードなどの機能の存在のうちの少なくとも１つを含むことができる。

ＲＶＥとＬＶＥの間の認証及び鍵共有プロトコルは、例えば３ＧＰＰ ＴＳ ３３．４０１に定義されるＥＰＳ ＡＫＡであってもよい。

ＬＶＥは、ＵＩＣＣなどのスマートカードのような改ざん防止モジュールに含まれてもよく、又はこの一部であってもよい。これには、ＵＳＩＭを含むＵＩＣＣを、厳しい環境にあっても信頼できると思われるセキュアなコンピュータ環境と見なすことができるという利点がある。

ＲＶＥは、（３ＧＰＰ ＴＳ ３３．４０１に定義される）ＭＭＥの機能を含むことができる。

ＥｎＰは、（３ＧＰＰ ＴＳ ３６．３００に定義される）ＤｅＮＢの機能を含むことができる。

Ｃｌａは、（３ＧＰＰ ＴＳ ３６．３００に定義される）リレーノードの機能を含むことができる。

セッション鍵又はこのあらゆる派生物は、例えば３ＧＰＰ ＴＳ ３３．４０１による、ＣＫ、ＩＫ、Ｋ_ASME、及びこれらに由来するいずれかの鍵を含むことができる。

セッション鍵又はこのあらゆる派生物を使用して、ＣｌａとＥｎＰの間のインターフェイス、及び／又はＣｌａとＲＶＥの間のインターフェイスを保護することができる。

ＣｌａとＲＶＥの間で実行されるプロトコルは、ＣｌａのアイデンティティをＲＶＥに伝えることができる。このアイデンティティは、ネットワーク内で、又はＣｌａが属するネットワークの関連するサブセクション内で一意とすべきである。

リレーノードアーキテクチャの詳細な実装
以下、本発明の実施形態によるＥＰＳにおけるリレーノードアーキテクチャに照らした第１の詳細な実装について説明するが、ここでは、ＭＭＥ及びドナーｅＮＢ（ＤｅＮＢ）が、例えば３ＧＰＰ ＴＳ ３６．３００に準拠することができる。

以下を前提とする。

Ｃｌａは、リレーノード（ＲＮ）である。ＬＶＥは、ＵＳＩＭ−ＲＮと呼ばれるＵＳＩＭを含むＵＩＣＣであり、ＲＮが、３ＧＰＰ ＴＳ３６．３００に定義されるようなＲＮ接続手順を実行する際にこれを使用する。ＲＶＥは、ＭＭＥ−ＲＮと呼ばれるＭＭＥであり、ＲＮとのＲＮ接続手順を実行する。ＥｎＰは、ＤｅＮＢである。このシステムは、図２に示すシステムに対応する。

ＬＶＥとＣｌａの間にはセキュアな接続が存在することができ、この接続は、例えばＥＴＳＩ ＴＳ １０２ ４８４「スマートカード、ＵＩＣＣとエンドポイント端末の間のセキュアなチャネル」に定義されるような、ＴＬＳなどを使用するＵＳＩＭ−ＲＮとＲＮの間のセキュアなチャネルである。

クラスＣは、そのメンバの以下の特性のうちの少なくとも１つによって定義することができる。
− リレーノードであること
− プライベートＴＬＳ鍵を含むセキュアな環境を有すること
− 例えばＥＴＳＩ ＴＳ １０２ ４８４によるセキュアなチャネルを確立する前に、自律的プラットフォーム検証を実行すること
− セッション鍵又はこのあらゆる派生物への無許可のアクセスを防ぐこと
− 要求時に、ＭＭＥ−ＲＮに正しいアイデンティティを提供すること

ＵＩＣＣ上のＭＭＥ−ＲＮとＵＳＩＭ−ＲＮの間の認証及び鍵共有プロトコルは、（ＴＳ ３３．４０１に定義される）ＥＰＳ ＡＫＡとすることができる。リソース要求は、ＲＮ接続手順とすることができる。

次に、この手順は、以下で説明するステップを含む。ステップの１つが、関連するエンティティのいずれかにおいて失敗すると、このエンティティによって手順が停止されることがある。

ＲＮ接続手順前の手順
Ｅ１． ＲＮは、ＲＮプラットフォームの自律的検証を実行することができる。次に、ＲＮは、ＵＥとしての役割でネットワークに接続し、ＵＳＩＭ−ＩＮＩと呼ばれるＵＳＩＭを使用してＩＰ接続性を確立することができる。この確立は、ＲＮ接続手順を構成するものではない。

Ｅ２． ＲＮは、例えばＴＳ ３３．３１０に定義されるような登録手順を通じて、任意に通信事業者の証明書を取得する。

Ｅ３． ＲＮは、任意にＯＡＭサーバへのセキュアな接続を確立する。

Ｅ４． ＲＮ及びＵＳＩＭ−ＲＮは、例えばＥＴＳＩ ＴＳ １０２ ４８４で規定されるセキュアなチャネル機構により、両方の側で又はＲＮ側のみで証明書を使用してＴＬＳ接続を確立することができる。ＲＮは、事前に確立された証明書又はステップＥ２において登録された証明書を使用することができる。ステップＥ１において検証されたＲＮプラットフォームのセキュアな環境に、ＲＮ証明書に対応するプライベート鍵を記憶することができ、ＴＬＳ接続はここで終了する。このステップ以降、ＵＳＩＭ−ＲＮとＲＮの間の全ての通信をセキュアなチャネルによって保護することができる。

Ｅ５． 例えばＵＩＣＣ上のＩＥＴＦ ＲＦＣ２５６０によるＯＣＳＰクライアントが、ＯＣＳＰサーバとのセキュアなチャネル設定で使用するＲＮ証明書の有効性をチェックすることができる。ＯＣＳＰは自己保護型であるため、ＵＳＩＭ−ＲＮとＲＮの間のセキュアなチャネルを通じてＯＣＳＰ通信を送信する必要はないが、これを行うことに問題はない。なお、ＯＣＳＰクライアントは、ＵＩＣＣ上に常駐することができるが、ＵＳＩＭの定義により、ＵＳＩＭの一部ではない。従って、セキュアなチャネル外でＯＣＳＰ通信を送信することは、Ｅ４の最後の文に矛盾するものではない。

Ｅ６． ＲＮは、ステップＥ２、Ｅ３又はＥ５を実行するために接続していた場合にはネットワークから離れることができ、ＲＮ及びＵＳＩＭ−ＩＮＩ内にＥＰＳセキュリティコンテキストが存在する場合には、これを削除することができる。

ステップＥ１〜Ｅ５は、上記で大まかに説明した方法のステップ１．１に対応する。

ステップＥ６により、ＲＮ接続手順の直前に、ＲＮ又はＵＳＩＭ−ＲＮ内にＥＰＳセキュリティコンテキストが存在しないことが確実になる。

ＲＮ接続手順
ＲＮは、ＴＳ ３６．３００に定義されるような、ＥＰＳのためのＲＮ接続手順を実行することができる。セキュリティの観点から、この手順は、以下のステップを含むことができる。

Ａ１． ＲＮは、ＲＮ接続手順において、ＵＳＩＭ−ＲＮに関連する国際移動体加入者識別番号（ＩＭＳＩ）（又は関連する一時的グローバル一意識別子、ＧＵＴＩ）を使用することができる。このステップは、上記で大まかに説明した方法のステップ１．２の一部である。

Ａ２． ＭＭＥ−ＲＮは、ＲＮ及びＵＳＩＭ−ＲＮとＥＰＳ ＡＫＡを開始して、ＮＡＳセキュリティを確立することができる。このステップは、上記で大まかに説明した方法のステップ１．２の一部及びステップ１．３に対応する。

Ａ３． ＭＭＥ−ＲＮは、ＨＳＳから受け取ったＲＮ固有の加入データから、ＲＮ接続手順においてＵＳＩＭ−ＲＮの使用が認められていることをチェックすることができる。ＭＭＥ−ＲＮは、この事実を拡張Ｓ１ ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰメッセージでＤｅＮＢに伝えることができる。このステップは、上記で大まかに説明した方法のステップ１．４に対応する。

Ａ４． ＤｅＮＢは、拡張Ｓ１ ＩＮＩＴＩＡＬ ＣＯＮＴＥＸＴ ＳＥＴＵＰメッセージを受け取ると、Ｕｎを介してＲＮ固有のアクセス層（ＡＳ）セキュリティを設定することができ、このセキュリティは、Ｓ１／Ｘ２メッセージを搬送するＰＤＣＰフレームに完全性保護を提供する際のＵｕを介したＡＳセキュリティとは異なる。このステップは、上記で大まかに説明した方法のステップ１．５に対応する。

これで、セキュリティの観点からのＲＮ始動が完了し、ＵＥは、ＲＮへの接続を開始することができる。

ＵＳＩＭの側面
セキュアなチャネル機構のサポートには、ＵＳＩＭ−ＲＮが証明書を使用する必要があり得る。この証明書は、通信事業者によってＵＩＣＣにプレインストールされることが好ましい。

リレーノードアーキテクチャの背景においては、証明書が、（例えば、適当な名前構造、又は検証パス内の特定の中間ＣＡ、或いはＯＩＤフィールド内の属性などを通じて）ＵＳＩＭに対してその使用を制限できるようにすべきである。

ＲＮの登録手順
ＲＮは、例えば３ＧＰＰ ＴＳ ３３．３１０によるマクロｅＮＢと同様に、ＲＮ接続手順よりも前にＤｅＮＢにデバイス証明書を登録することができる。その後、ＲＮとＵＳＩＭの間のセキュアなチャネルの確立に、この証明書を使用することができる。

証明書登録手順は、ＡＳレベルのセキュリティに依拠しなくてもよく、アプリケーション層で保護することができる。従って、Ｕｎインターフェイス上のセキュリティが確立される前に証明書登録手順を実行することができる。しかしながら、ＲＮは、登録機関（ＲＡ）に到達できるように、登録手順にＩＰ接続性を必要とすることがある。ＩＰ接続性は、例えば以下のような様々な方法の１つで確立することができる。

（１）ＲＮが、登録目的で固定ネットワークに接続することができる。ＵＳＩＭは不要である。

（２）ＲＮが、ＤｅＮＢへのＲＮ接続手順で使用されるＵＳＩＭ−ＲＮと呼ばれるものとは異なるＵＳＩＭ−ＩＮＩと呼ばれるＵＳＩＭを使用してｅＮＢに接続することができる。ＲＮとＵＳＩＭ−ＩＮＩの間にはセキュアなチャネルは必要なく、ＵＳＩＭ−ＲＮは、ＯＣＳＰがチェックした端末証明書を有するセキュアなチャネルのみを介してあらゆる端末と通信すべきである。今日では、１つのＵＩＣＣ上に２つのＵＳＩＭを有することは、利用可能な標準的特徴である。同時に１つのＵＳＩＭのみが作動していれば十分である。

いずれの場合にも、ＲＮ接続手順よりも前にＲＡとの通信が行われる場合、ネットワークは、ＲＮが到達できる宛先が、例えば、ＲＡ、ＯＡＭサーバ及びＯＣＳＰサーバのみに限定されることを確実にすべきであることが好ましい。（２）の場合には、完全性保護を伴わずにパケットデータコンバージェンスプロトコル（ＰＤＣＰ）を介して送信されるＲＮからのＩＰトラフィックをいくつかの宛先（アクセスポイント名、ＡＰＮ）のみに制限することにより、このことを確実にすることができる。このシナリオは、特定の制限の実施に限定されるものではない。

ＲＮのセキュアな管理手順
ＲＮは、ＯＡＭサーバへのセキュアな接続を確立することができる。

保守運用（ＯＡＭ）手順は、ＡＳレベルのセキュリティに依存しなくてもよい。従って、Ｕｕインターフェイス上のセキュリティが確立される前にＯＡＭ手順を実行することができる。下位のレイヤ上のセキュリティを利用できない場合、通常、ＲＮとＯＡＭサーバの間の通信は、ＴＬＳを使用して保護される。ＲＮは、ＯＡＭサーバに到達できるように、この手順にＩＰ接続性を必要とする。ＩＰ接続性は、上述した方法と同じ方法で確立することができる。

ＲＮ接続手順よりも前にＯＡＭサーバとの通信が行われる場合、ＲＮが到達できる宛先に対する制限を適用しなければならない。これは、上述した方法と同様の方法で実現することができる。

ＵＩＣＣによるＯＣＳＰチェック
本明細書で上述した詳細な実装では、ＤｅＮＢとのＲＮ接続手順よりも前に、ＵＩＣＣが、セキュアなチャネルの設定に使用するＲＮ証明書のＯＣＳＰチェックを実行することが必要となり得る。ＯＣＳＰプロトコルは自己保護型であり、従ってＵｎインターフェイス上のセキュリティが確立される前に実行することができる。ＯＣＳＰクライアントは、ＯＣＳＰメッセージを搬送するＩＰパケットを、ＲＮを介して送信する必要があり得る。従って、ＲＮは、ＯＣＳＰサーバに到達できるように、この手順にＩＰ接続性を必要とすることがある。ＩＰ接続性は、上述の方法と同じ方法で確立することができる。

ＯＣＳＰ機構の代わりに又はこれに加えて、ＭＭＥ−ＲＮが単独でアクセス制御を行い、従って外部ＯＣＳＰサーバに依存せず、又は証明書失効リスト（ＣＲＬ）を使用することもできる。

以下、本発明の実施形態による、ＥＰＳにおけるリレーノードアーキテクチャに照らした第２の詳細な実装について説明する。この実装は、少なくとも以下の点で異なる以外は上述の詳細な実装のステップと前提を共有し、これに従う。

Ｅ１． ＵＳＩＭ−ＲＮを使用してＩＰ接続性を確立することができる。この確立は、ＲＮ接続手順を構成するものではない。ＲＮ接続手順以外でＵＳＩＭ−ＲＮが使用される時には常に、ＵＳＩＭ−ＲＮが、第１の要求者中間鍵とは異なる修正された要求者中間鍵を生成してこれをＲＮに転送するように、ＵＳＩＭ−ＲＮを適当に修正することができる。

Ａ１． 接続手順がＲＮ接続手順を構成しない時には常に、この事実をＲＮが接続手順の一部としてＭＭＥ−ＲＮに示すように、ＲＮを適当に修正することができる。

Ａ３． 接続手順がＲＮ接続手順を構成しないという通知をＭＭＥ−ＲＮがＲＮから受け取った時には常に、ＭＭＥ−ＲＮが、第２の要求者中間鍵とは異なる第２の修正された要求者中間鍵を生成してこれをＤｅＮＢに転送するように、ＭＭＥ−ＲＮを適当に修正することができる。

登録手順：
ＵＳＩＭ−ＩＮＩの代わりにＵＳＩＭ−ＲＮを使用する。

従って、上記説明によれば、本発明の例示的な実施形態が、例えばスマートカードなどのローカル検証エンティティ又はこの構成要素、これを具体化する装置、これを制御し及び／又は動作させる方法、これを制御し及び／又は動作させるコンピュータプログラム、並びにこのような（単複の）コンピュータプログラムを保持して（単複の）コンピュータプログラム製品を形成する媒体を提供することが明らかなはずである。本発明のさらなる例示的な実施形態は、例えばリレーノードなどの要求者又はこの構成要素、これを具体化する装置、これを制御し及び／又は動作させる方法、これを制御し及び／又は動作させる（単複の）コンピュータプログラム、並びにこのような（単複の）コンピュータプログラムを保持して（単複の）コンピュータプログラム製品を形成する媒体を提供する。

上記説明したブロック、装置、システム、技術又は方法のいずれかの実装は、非限定的な例として、ハードウェア、ソフトウェア、ファームウェア、専用回路又はロジック、汎用ハードウェア又はコントローラ又はその他のコンピュータ装置、或いはこれらの何らかの組み合わせを含む。

上記の説明内容は、現在のところ本発明の好ましい実施形態と見なされるものであると理解されたい。しかしながら、この好ましい実施形態の説明は、ほんの一例として示したものであり、添付の特許請求の範囲により定義される本発明の範囲から逸脱することなく、様々な修正を加えることができる。

Ｓ８１０ 評価方法
Ｓ８２０ 要求者方法
Ｓ８３０ 検証方法
Ｓ８４０ 実施方法
Ｓ８５０ リソースを許可

Claims (38)

1. 装置であって、
   要求者デバイスから受け取った要求者特性情報が所定の要求者属性に対応するかどうかをチェックするように構成された特性チェック手段と、
   前記特性チェック手段によりチェックした前記要求者特性情報が前記所定の要求者属性に対応する場合にのみ肯定の結果を取得するように構成された取得手段と、
   前記装置に記憶された所定の要求者永久鍵から第１の要求者中間鍵を生成するように構成された鍵生成手段と、
   安全なプロトコルを使用して前記第１の要求者中間鍵を前記要求者デバイスに供給するように構成された供給手段と、
   を備え、前記鍵生成手段及び前記供給手段の少なくとも一方が、前記結果が肯定の場合にのみ、前記第１の要求者中間鍵の生成及び供給をそれぞれ行うように構成される、
   ことを特徴とする装置。
2. 前記安全なプロトコルが、証明書に基づく暗号プロトコルである、
   ことを特徴とする請求項１に記載の装置。
3. 前記証明書が有効であるかどうかをチェックするように構成された証明書チェック手段をさらに備え、前記取得手段が、前記証明書が有効な場合にのみ前記肯定の結果を取得するようにさらに構成される、
   ことを特徴とする請求項２に記載の装置。
4. 前記要求者特性情報が、前記証明書に含まれる、
   ことを特徴とする請求項２又は３に記載の装置。
5. 前記安全なプロトコルの鍵及び前記要求者永久鍵の少なくとも一方を安全に記憶して、対応する許可を有していない前記装置から前記安全に記憶された鍵を引き出せないようにするよう構成された安全記憶手段をさらに備える、
   ことを特徴とする請求項１から４のいずれか１項に記載の装置。
6. 前記鍵生成手段が、認証及び鍵共有プロトコルを使用して前記第１の要求者中間鍵を生成するように構成される、
   ことを特徴とする請求項１から５のいずれか１項に記載の装置。
7. 請求項１から６のいずれか１項に記載の装置を含む、
   ことを特徴とする改ざん防止モジュール。
8. 装置であって、
   安全なプロトコルを使用して前記装置の要求者特性情報を評価デバイスに供給するように構成された特性情報供給手段と、
   有効な要求者セッション鍵に基づいて、前記評価デバイスとは異なる実施デバイスとの通信を確立するように構成された確立手段と、
   を備え、前記有効な要求者セッション鍵が、前記評価デバイスから受け取った第１の要求者中間鍵に基づく、
   ことを特徴とする装置。
9. 前記安全なプロトコルが、証明書に基づく暗号プロトコルである、
   ことを特徴とする請求項８に記載の装置。
10. 前記要求者特性情報が、前記証明書に含まれる、
    ことを特徴とする請求項９に記載の装置。
11. 前記要求者特性情報が、
    前記安全なプロトコルの鍵を安全に記憶して、対応する許可を有していない前記装置から前記鍵を引き出せないようにするよう構成された安全記憶手段が前記装置内に存在すること、
    前記装置のハードウェア及びソフトウェアの完全性を保証する自律的プラットフォーム検証を実行する能力、及び
    前記装置により、前記存在及び前記能力とは別の所定の機能が与えられること、
    のうちの少なくとも１つを満たすか否かについての情報を含む、
    ことを特徴とする請求項８から１０のいずれか１項に記載の装置。
12. 前記第１の要求者中間鍵から有効な要求者セッション鍵を生成するように構成された鍵生成手段をさらに備え、前記確立手段が、前記有効な要求者セッション鍵を使用して前記実施デバイスとの前記通信を確立するように構成される、
    ことを特徴とする請求項８から１１のいずれか１項に記載の装置。
13. 前記有効な要求者セッション鍵に基づいて、前記実施デバイスとの前記通信を保護するように構成される、
    ことを特徴とする請求項１２に記載の装置。
14. 請求項８から１３のいずれか１項に記載の装置を含む、
    ことを特徴とするリレーノード。
15. 装置であって、
    受け取ったデバイスクラス情報が所定のデバイスクラスに対応するかどうかを検証するように構成された検証手段と、
    前記検証手段によりチェックした前記デバイスクラス情報が前記所定のデバイスクラスに対応する場合にのみ肯定の結果を取得するように構成された取得手段と、
    前記装置内に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するように構成された鍵生成手段と、
    前記第２の要求者セッション鍵及び前記結果を実施デバイスに供給するように構成された供給手段と、
    を備え、前記鍵生成手段及び前記供給手段の少なくとも一方が、前記結果が肯定の場合にのみ前記第２の要求者セッション鍵の生成及び供給をそれぞれ行うように構成される、
    ことを特徴とする装置。
16. 要求者との間に、該要求者とは異なる検証デバイスから受け取った第２の要求者セッション鍵が前記要求者の有効な要求者セッション鍵に対応することを必要とする通信を確立するように構成された確立手段と、
    前記検証デバイスから受け取った結果が肯定でありかつ前記確立手段が前記通信を確立した場合にのみ、前記要求者の通信リソースへのアクセスを許可するように構成された許可手段と、
    を備えることを特徴とする装置。
17. 前記第２の要求者セッション鍵から第３の要求者セッション鍵を生成するように構成された鍵生成手段をさらに備え、前記通信が、前記第３の要求者セッション鍵が前記有効な要求者セッション鍵に一致することを必要とする、
    ことを特徴とする請求項１６に記載の装置。
18. 請求項１から６のいずれか１項に記載の装置を含む評価装置と、
    請求項８から１３のいずれか１項に記載の装置を含む要求者装置と、
    検証装置と、
    実施装置と、
    を備えたシステムであって、
    前記評価装置、前記要求者装置及び前記検証装置が互いに異なり、
    前記実施装置が、前記評価装置及び前記要求者装置とは異なり、
    前記検証装置が、
    前記検証装置に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するように構成された鍵生成手段と、
    前記第２の要求者セッション鍵を前記実施装置に供給するように構成された供給手段と、
    を備え、前記実施装置が、
    前記検証装置から受け取った前記第２の要求者セッション鍵が前記要求者装置の前記有効な要求者セッション鍵に対応することを必要とする通信を前記要求者装置との間に確立するように構成された確立手段と、
    前記確立手段が前記通信を確立した場合にのみ、前記要求者装置の通信リソースへのアクセスを許可するように構成された許可手段と、
    を備え、
    前記要求者装置が、前記評価装置の前記要求者デバイスを含み、
    前記評価装置が、前記要求者装置の前記評価デバイスを含み、
    前記要求者装置により供給される前記要求者特性情報が、前記評価装置により受け取られる前記要求者特性情報に対応し、
    前記評価装置により供給される前記第１の要求者中間鍵が、前記要求者装置により受け取られる前記第１の要求者中間鍵に対応し、
    前記評価装置の前記安全なプロトコルが、前記要求者装置の前記安全なプロトコルと同じものである、
    ことを特徴とするシステム。
19. 前記検証デバイスが、請求項１５に記載の装置を含むこと、及び
    前記実施デバイスが、請求項１６及び１７のいずれか１項に記載の装置を含むこと、
    の少なくとも一方を満たす、
    ことを特徴とする請求項１８に記載のシステム。
20. 方法であって、
    要求者デバイスから受け取った要求者特性情報が所定の要求者属性に対応するかどうかをチェックするステップと、
    前記チェックステップでチェックした前記要求者特性情報が前記所定の要求者属性に対応する場合にのみ肯定の結果を取得するステップと、
    前記方法を実行する装置に記憶された所定の要求者永久鍵から第１の要求者中間鍵を生成するステップと、
    安全なプロトコルを使用して前記第１の要求者中間鍵を前記要求者デバイスに供給するステップと、
    を含み、前記生成ステップ及び前記供給ステップの少なくとも一方が、前記結果が肯定の場合にのみ実行される、
    ことを特徴とする方法。
21. 前記安全なプロトコルが、証明書に基づく暗号プロトコルである、
    ことを特徴とする請求項２０に記載の方法。
22. 前記証明書が有効であるかどうかをチェックするステップをさらに含み、前記取得ステップの前記結果が、前記証明書が有効な場合にのみ肯定の結果となる、
    ことを特徴とする請求項２１に記載の方法。
23. 前記要求者特性情報が、前記証明書に含まれる、
    ことを特徴とする請求項２１又は２２に記載の方法。
24. 前記安全なプロトコルの鍵及び前記要求者永久鍵の少なくとも一方を安全に記憶して、前記方法を実行する対応する許可を有していない装置から前記安全に記憶された鍵を引き出せないようにするステップをさらに含む、
    ことを特徴とする請求項２０から２３のいずれか１項に記載の方法。
25. 前記第１の要求者中間鍵を生成する前記ステップが、認証及び鍵共有プロトコルを使用する、
    ことを特徴とする請求項２０から２４のいずれか１項に記載の方法。
26. 方法であって、
    安全なプロトコルを使用して、前記方法を実行する装置の要求者特性情報を評価デバイスに供給するステップと、
    有効な要求者セッション鍵に基づいて、前記評価デバイスとは異なる実施デバイスとの通信を確立するステップと、
    を含み、前記有効な要求者セッション鍵が、前記評価デバイスから受け取った第１の要求者中間鍵に基づく、
    ことを特徴とする方法。
27. 前記安全なプロトコルが、証明書に基づく暗号プロトコルである、
    ことを特徴とする請求項２６に記載の方法。
28. 前記要求者特性情報が、前記証明書に含まれる、
    ことを特徴とする請求項２７に記載の方法。
29. 前記要求者特性情報が、
    前記安全なプロトコルの鍵を安全に記憶して、対応する許可を有していない前記装置から前記鍵を引き出せないようにするよう構成された安全記憶手段が前記装置内に存在すること、
    前記装置のハードウェア及びソフトウェアの完全性を保証する自律的プラットフォーム検証を実行する能力、及び
    前記装置により、前記存在及び前記能力とは別の所定の機能が与えられること、
    のうちの少なくとも１つを満たすか否かについての情報を含む、
    ことを特徴とする請求項２６から２８のいずれか１項に記載の方法。
30. 前記第１の要求者中間鍵から有効な要求者セッション鍵を生成するステップをさらに含み、前記確立ステップが、前記有効な要求者セッション鍵を使用して前記実施デバイスとの通信を確立する、
    ことを特徴とする請求項２６から２９のいずれか１項に記載の方法。
31. 前記有効な要求者セッション鍵に基づいて、前記実施デバイスとの前記通信を保護するステップをさらに含む、
    ことを特徴とする請求項３０に記載の方法。
32. 方法であって、
    受け取ったデバイスクラス情報が所定のデバイスクラスに対応するかどうかを検証するステップと、
    前記検証ステップでチェックした前記デバイスクラス情報が前記所定のデバイスクラスに対応する場合にのみ肯定の結果を取得するステップと、
    前記方法を実行する装置内に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するステップと、
    前記第２の要求者セッション鍵及び前記結果を実施デバイスに供給するステップと、
    を含み、前記生成ステップ及び前記供給ステップの少なくとも一方が、前記結果が肯定の場合にのみ実行される、
    ことを特徴とする方法。
33. 要求者との間に、該要求者とは異なる検証デバイスから受け取った第２の要求者セッション鍵が前記要求者の有効な要求者セッション鍵に対応することを必要とする通信を確立するステップと、
    前記検証デバイスから受け取った結果が肯定でありかつ前記通信が確立された場合にのみ、前記要求者の通信リソースへのアクセスを許可するステップと、
    を含むことを特徴とする方法。
34. 前記第２の要求者セッション鍵から第３の要求者セッション鍵を生成するステップをさらに含み、前記通信が、前記第３の要求者セッション鍵が前記有効な要求者セッション鍵に一致することを必要とする、
    ことを特徴とする請求項３３に記載の方法。
35. 請求項２０から２５のいずれか１項に記載の方法を含む評価方法を評価装置によって実行するステップと、
    請求項２６から３１のいずれか１項に記載の方法を含む要求者方法を要求者装置によって実行するステップと、
    検証装置によって検証方法を実行するステップと、
    実施装置によって実施方法を実行するステップと、
    を含む方法であって、
    前記評価装置、前記要求者装置及び前記検証装置が互いに異なり、
    前記実施装置が、前記評価装置及び前記要求者装置とは異なり、
    前記検証方法が、
    前記検証装置に記憶された第２の要求者中間鍵から第２の要求者セッション鍵を生成するステップと、
    前記第２の要求者セッション鍵を前記実施装置に供給するステップと、
    を含み、前記実施方法が、
    前記検証装置から受け取った前記第２の要求者セッション鍵が前記要求者装置の前記有効な要求者セッション鍵に対応することを必要とする通信を前記要求者装置との間に確立するステップと、
    前記通信が確立された場合にのみ、前記要求者装置の通信リソースへのアクセスを許可するステップと、
    を含み、
    前記要求者方法が、前記評価方法の前記要求者デバイスを含み、
    前記評価方法が、前記要求者方法の前記評価デバイスを含み、
    前記要求者装置により供給される前記要求者特性情報が、前記評価装置により受け取られる前記要求者特性情報に対応し、
    前記評価装置により供給される前記第１の要求者中間鍵が、前記要求者装置により受け取られる前記第１の要求者中間鍵に対応し、
    前記評価装置の前記安全なプロトコルが、前記要求者装置の前記安全なプロトコルと同じものである、
    ことを特徴とする方法。
36. 前記検証方法が、請求項３２に記載の方法を含むこと、及び
    前記実施方法が、請求項３３及び３４のいずれかに記載の方法を含むこと、
    の少なくとも一方を満たす、
    ことを特徴とする請求項３５に記載の方法。
37. コンピュータ上で実行された時に、請求項２０から３６のいずれか１項に記載の方法を動作させるコンピュータ実行可能要素を含む、
    ことを特徴とするコンピュータプログラム製品。
38. コンピュータ可読記憶媒体として具体化される、
    ことを特徴とする請求項３７に記載のコンピュータプログラム製品。

Images