JP2018518854A - 公開キー機構を用いたサービス層におけるエンドツーエンド認証 - Google Patents

Abstract

マシンツーマシン／モノのインターネット環境では、複数のホップによって分離されるデバイスのエンドツーエンド認証が、事前プロビジョニングされたホップ毎の証明書、固有に生成されたホップ毎の証明書、および／または公開キー認証書を使用して、直接もしくは委託／仲介ネゴシエーションを介して達成され、それによって、遠隔リソースおよびサービスが、単一ホップ通信を介して達成され得、そして、遠隔リソースとのセキュアな通信が、リソースおよびサービスならびにエンドデバイスの能力のために適切であるセキュアなプロトコルを使用して確立され得、その後、オーバーヘッドまたはリスクがホップ毎の変換から生じることなく、通信が直接行われる。

Description

（関連出願の引用）
本願は、米国仮特許出願第６２／１３３，８３９号（２０１５年３月１６日出願、名称「Ｅｎｄ−ｔｏ−ｅｎｄ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｔ ｔｈｅ Ｓｅｒｖｉｃｅ Ｌａｙｅｒ Ｕｓｉｎｇ Ｐｕｂｌｉｃ Ｋｅｙｉｎｇ Ｍｅｃｈａｎｉｓｍｓ」）の利益を主張し、上記出願の内容は、その全体が参照により本明細書に引用される。

マシンツーマシン（Ｍ２Ｍ）およびモノのインターネット（ＩｏＴ）ネットワーク展開は、Ｍ２Ｍ／ＩｏＴアプリケーションならびにサービスをホストするＭ２Ｍ／ＩｏＴサーバ、ゲートウェイ、およびデバイス等のノードにわたって動作するｏｎｅＭ２Ｍ、ＥＴＳＩ Ｍ２Ｍ、および、ＯＭＡ ＬＷＭ２Ｍ等のＭ２Ｍ／ＩｏＴサービス層をサポートし得る。これらの種類の動作は、例えば、ｏｎｅＭ２Ｍ−ＴＳ−０００１ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ｖ−１．６．１、ｏｎｅＭ２Ｍ−ＴＳ−０００３ Ｓｅｃｕｒｉｔｙ Ｓｏｌｕｔｉｏｎｓ−Ｖ−１．０．１、Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＴＬＳ）Ｐｒｏｔｏｃｏｌ Ｖｅｒｓｉｏｎ １．２，ＩＥＴＦ−ＲＦＣ ５２４６、Ｄａｔａｇｒａｍ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ（ＤＴＬＳ） Ｖｅｒｓｉｏｎ １．２，ＩＥＴＦ−ＲＦＣ ６３４７、およびＳｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ（ＩＰＳｅｃ），ＩＥＴＦ−ＲＦＣ ４３０１で説明されている。

サービス有効化およびセキュリティ構成（ＳＥＳＣ）方法が、説明される。これは、セキュアな通信が確立され得るために、Ｍ２Ｍネットワーク内のエンティティによって使用され得るセキュリティ特徴、関連付けられる属性、およびパラメータの正しい組を識別することを伴う。ステップは、エンティティの能力およびエンティティによって提供されるサービスを識別することと、セキュリティ特徴の決定を行うこととを伴う。例えば、エンティティが「重要」なサービスを提供しない場合、高価なＥ２Ｅ認証プロセスが回避され得る。しかしながら、エンティティによって提供されるサービスまたは情報が「重要」と見なされ、したがって、Ｅ２Ｅ認証を要求する場合、重要サービスに関与する任意のメッセージングが、Ｅ２Ｅ様式で認証されることを要求され得る。この決定を行う機構が、本書で説明される。サービス有効化機能（ＳＥＦ）は、随意に、Ｅ２Ｅ認証のみが要求され、したがって、高価なホップ毎（ＨｂＨ）のセキュアな接続を回避することを示し得る。同様に、ＳＥＦは、随意に、それが証明書レジストリ（ＣＲ）機能性も果たすことを示し得る。ＳＥＦはまた、随意に、リンクを提供し得るか、または証明書が請求され得るＣＲへの場所を示し得る。

セキュアな証明書請求／登録プロセス（ＳＣＲＰ）が、説明される。これは、動的様式でＥ２Ｅ認証に使用され得る公開キー証明書を要求することを伴う。このプロセスはまた、証明書レジストリを用いた証明書の登録を伴い得る。サービス層におけるサービスとしての動的証明書登録／請求（ＣＲａａＳ）も、証明書の再プロビジョニングを含み得る、証明書のライフサイクル管理とともに説明される。

第三者証明書請求（ＴＰＲＣ）方法が、説明される。これは、エンティティによる第三者の証明書の請求のための機構を含む。メッセージ発信側のＥ２Ｅ認証を要求し得る任意のエンティティは、アクセス制御特権が評価されているならば、Ｅ２Ｅ認証に使用され得るＥ２Ｅ証明書を提供され得る。証明書請求は、それによって証明書および関連付けられるパラメータがリソースの一部として利用可能であり得る、暗示的手段によって行われ得る。代替として、証明書請求は、それによって証明書が信頼される第三者（ＴＴＰ）からフェッチされ得る、明示的手段によって行われ得る。

エンドツーエンド認証プロセス（Ｅ２ＥＡＰ）が、説明される。これは、Ｅ２Ｅメッセージ発信側の認証を行うための機構と、委託または非委託モードで認証を行う能力とを含む。Ｅ２Ｅ認証は、一方向認証または相互Ｅ２Ｅ認証を伴い得る。例えば、Ｅ２Ｅ認証を行うために使用されることができるメタデータを作成するために使用され得る、「メッセージ発信側情報」を作成するための機構が説明される。委託モードでは、エンティティは、Ｅ２Ｅ認証機構を信頼されるエンティティにオフロードする。本開示に説明される機構は、認証を伴う環境、より具体的には、制約されると見なされるエンティティ（例えば、ＩｏＴ／Ｍ２Ｍデバイス）のＥ２Ｅ認証に適用可能である。しかしながら、このプロセスは、ＩｏＴデバイスのみに限定されない。これは、信頼されるエンティティが、複雑なセキュリティ機能を果たすことから制約されたデバイスを解放することに加えて、全体としてシステムに関与するメッセージングオーバーヘッドを緩和するために、適切なセキュリティ特徴、機能、および証明書を決定し得る場合、使用されることができる。ここで説明される機構はまた、Ｅ２Ｅ様式でサービス層メッセージの機密保持および完全性を提供するために使用され得る。

本概要は、発明を実施するための形態において以下でさらに説明される、簡略化形態の一連の概念を導入するように提供される。本概要は、請求される主題の主要な特徴または不可欠な特徴を識別することを意図せず、請求される主題の範囲を限定するために使用されることも意図していない。さらに、請求される主題は、本開示の任意の部分で記述されるいずれかまたは全ての不利点を解決する制限に限定されない。

さらに詳細な理解が、添付図面と併せて一例として挙げられる以下の説明からもたらされ得る。
図１は、ネットワークプロトコルスタック内の種々の層においてプロトコルおよびサービスの一部として実装された通信セッションを図示する。 図２は、例示的共通サービス機能／共通サービスエンティティ（ＣＳＥ）を図示する。 図３は、ホップ毎のセキュリティアソシエーションの例を図示する。 図４は、例示的Ｍ２Ｍシナリオを図示する。 図５は、メッセージの発信側を認証することができないという問題を図示する。 図６は、より新しいメッセージを、悪意を持って作成し、レジストラＣＳＥに転送するＩＮ−ＣＳＥの問題を図示する。 図７は、例示的組のエンドツーエンドセキュリティ認証ステップを図示する。 図８は、例示的サービス有効化およびセキュリティ構成（ＳＥＳＣ）要求／応答メッセージングを図示する。 図９は、例示的高レベル証明書請求プロセスを図示する。 図１０は、アプリケーションエンティティ（ＡＥ）またはＣＳＥにプロビジョニングされ得る、キーの例示的Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）表現を図示する。 図１１は、例示的第三者証明書請求（ＴＰＣＲ）プロセスフローを図示する。 図１２は、デジタル署名を作成するための例示的高レベル機構を示す、フローチャートである。 図１３は、委託エンティティ（ＤＥ）を用いた例示的一方向Ｅ２Ｅ認証プロセスを図示する。 図１４は、サービス有効化機能（ＳＥＦ）および証明書レジストリ（ＣＲ）機能性を組み込む、例示的セキュリティ共通サービス機能／ＣＳＥを図示する。 図１５は、サービス有効化およびセキュリティ構成（ＳＥＳＣ）機能がレジストラＣＳＥ（ＲＣＳＥ）に常駐するＣＳＥに登録することの例を図示する。 図１６は、ホップ毎の証明書が信頼される第三者（ＴＴＰ）によってプロビジョニングされる例を図示する。 図１７は、ＡＥリソースの例示的構造を図示する。 図１８は、ホップ毎の証明書プロビジョニング後のＡＥリソースを図示する。 図１９は、証明書レジストリ（ＣＲ）からＥ２Ｅ公開キー証明書を要求するＡＥの例を図示する。 図２０は、Ｅ２Ｅ公開キー証明書を用いて更新されたＡＥリソースの例を図示する。 図２１は、ＣＲ機能性をホストするＲＣＳＥの例を図示する。 図２２は、暗示的手段を使用する第三者への証明書配布の例を図示する。 図２３は、直接モードを使用するＡＥによるセンサメッセージのＥ２Ｅ認証の例を図示する。 図２４は、委託モードを使用するＥ２Ｅ認証の例を図示する。 図２５は、直接モードにおけるアクチュエータによるシステムまたはアプリケーションのＥ２Ｅ認証の例を図示する。 図２６は、アクチュエータの代わりにＲＣＳＥによるシステムまたはアプリケーションのＥ２Ｅ認証の例を図示する。 図２７は、Ｅ２Ｅデジタル署名をｏｎｅＭ２Ｍメッセージに追加することの例を図示する。 図２８は、多重Ｅ２Ｅ認証の例を図示する。 図２９は、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システムの系統図である。 図３０は、図２９に図示されるＭ２Ｍ／ＩｏＴ／ＷｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図３１は、図２９および３０で図示される通信システム内で使用され得る、Ｍ２Ｍ／ＩｏＴ／ＷｏＴデバイス、ゲートウェイ、またはサーバ等の例示的通信ネットワークノードの系統図である。 図３２は、図２９および３０の通信システムのノードが具現化され得る、例示的コンピューティングシステムのブロック図である。

本書は、多様な能力（例えば、異なる処理能力、メモリサイズ等）を有し、事前セキュリティアソシエーションを伴わないエンティティの間でエンドツーエンド認証を行う機構を説明する。適切な公開キーベースのセキュリティ証明書、機能、範囲、およびパラメータが、エンティティにプロビジョニングされ得るように、セキュリティプロビジョニングならびに構成プロシージャが、説明される。サービス層において、セキュリティ証明書を要求し、次いでエンドツーエンド認証を行うために証明書を使用し得る他のエンティティにそれを配布する機構も、開発される。

サービス有効化およびセキュリティ構成（ＳＥＳＣ）方法が、説明される。これは、セキュリティ特徴、関連付けられる属性、およびパラメータの正しい組を識別することを伴い、それらは、セキュアな通信が確立され得るために、Ｍ２Ｍネットワーク内のエンティティによって使用され得る。ステップは、エンティティの能力およびエンティティによって提供されるサービスを識別することと、セキュリティ特徴の決定を行うこととを伴う。例えば、エンティティが「重要」なサービスを提供しない場合、高価なＥ２Ｅ認証プロセスが回避され得る。しかしながら、エンティティによって提供されるサービスまたは情報が「重要」と見なされ、したがって、Ｅ２Ｅ認証を要求する場合、重要サービスに関与する任意のメッセージングが、Ｅ２Ｅ様式で認証されることを要求され得る。この決定を行う機構が、本書で説明される。

ＳＥＳＣプロセスの一部として、ＳＥＦは、随意に、Ｅ２Ｅ認証のみが要求され、したがって、高価なホップ毎（ＨｂＨ）のセキュアな接続を回避することを示し得る。同様に、ＳＥＦは、随意に、それがＣＲ機能性も果たすことを示し得る。さらに、ＳＥＦは、随意に、証明書が請求され得るＣＲへのリンクを提供し得るか、または証明書が請求され得るＣＲへの場所を示し得る。

セキュアな証明書請求／登録プロセス（ＳＣＲＰ）が、説明される。これは、動的様式でＥ２Ｅ認証に使用され得る公開キー証明書に対して要求することを伴う。このプロセスはまた、証明書レジストリへの証明書の登録を伴い得る。サービス層におけるサービスとしての動的証明書登録／請求（ＣＲａａＳ）が、説明される。証明書の再プロビジョニングを含み得る証明書のライフサイクル管理が説明される。

第三者証明書請求（ＴＰＲＣ）プロセスが、説明される。これは、エンティティによる第三者の証明書の請求のための機構を含む。メッセージ発信側のＥ２Ｅ認証を要求し得る任意のエンティティは、アクセス制御特権が評価されているならば、Ｅ２Ｅ認証に使用され得るＥ２Ｅ証明書を提供され得る。証明書請求は、暗示的手段によって行われ得、証明書および関連付けられるパラメータは、リソースの一部として利用可能であり得る。逆に、証明書請求は、明示的手段によって行われ得、証明書は、ＴＴＰからフェッチされ得る。

エンドツーエンド認証プロセス（Ｅ２ＥＡＰ）が、説明される。Ｅ２Ｅメッセージ発信側の認証を行うための機構が、説明される。委託または非委託モードで認証を行う能力が、解説される。Ｅ２Ｅ認証は、一方向認証または相互Ｅ２Ｅ認証を伴い得る。「メッセージ発信側情報」を作成するための機構が説明され、メッセージ発信側情報は、メタデータを作成するために使用され得、そして、メタデータは、Ｅ２Ｅ認証を行うために使用されることができる。委託モードでは、エンティティは、Ｅ２Ｅ認証機構を信頼されるエンティティにオフロードする。

本明細書に説明される機構は、認証を伴う環境、より具体的には、制約されると見なされるエンティティ（例えば、あるＩｏＴ／Ｍ２Ｍデバイス）のＥ２Ｅ認証に適用可能である。しかしながら、本明細書に説明されるシステムおよび方法は、ＩｏＴデバイスのみに限定されないことが理解される。そのようなシステムおよび方法は、信頼されるエンティティが適切なセキュリティ特徴、機能、および証明書を決定し得るならば、複雑なセキュリティ機能を果たすことから制約されたデバイスを解放することに加えて、全体としてシステムに関与するメッセージングオーバーヘッドを緩和するために、使用されることができる。たとえ本書内の例証的例が、多くの場合、メッセージ発信側のＥ２Ｅ認証に関するとしても、ここで説明される機構は、Ｅ２Ｅ様式におけるサービス層メッセージの機密保持および完全性を提供するために使用され得る。

（通信セッション）
典型的通信セッションは、典型的には、２つ以上の通信エンティティ（例えば、デバイス、アプリケーション等）間の情報の持続的双方向交換を伴う。しかしながら、現在のＲＥＳＴｆｕｌアプローチの場合、実際の持続的接続はなく、オンデマンド要求／応答メッセージがある。通信セッションは、ある時点で確立され、種々の状況に基づいて、後の時点で解除される（例えば、セッションがタイムアウトした後、またはエンティティのうちの１つがセッションを終了させることを決定するとき）。通信セッションは、典型的には、エンティティ間での複数のメッセージの交換を伴い、典型的には、ステートフルであり、それは、通信エンティティのうちの少なくとも１つが、通信セッションを維持することができるためにセッション履歴についての情報（例えば、証明書、識別子等のセキュリティコンテキスト）を保存する必要があることを意味する。通信セッションは、ネットワークプロトコルスタック内の種々の層においてプロトコルおよびサービスの一部として実装され得る。例として、図１は、トランスポートプロトコル層、アプリケーションプロトコル層、アプリケーションサービス層におけるネットワークノード間、およびアプリケーション間で確立された通信セッションを示す。

（アプリケーションサービス層）
Ｍ２Ｍサービス層は、具体的には、Ｍ２Ｍタイプデバイスおよびアプリケーションのための付加価値サービスを提供することを標的にした、１つのタイプのアプリケーションサービス層の例である。例えば、Ｍ２Ｍサービス層は、サービス層によってサポートされるＭ２Ｍ中心能力の集合へのアクセスをアプリケーションおよびデバイスに提供するアプリケーションプログラミングインターフェース（ＡＰＩ）をサポートすることができる。いくつかの例は、セキュリティ、課金、データ管理、デバイス管理、発見、プロビジョニング、および接続性管理を含む。図１は、ｏｎｅＭ２Ｍ仕様によって規定される共通サービス機能（ＣＳＦ）を描写する。

これらの機能／能力は、Ｍ２Ｍサービス層によって定義されるメッセージフォーマット、リソース構造、およびリソース表現を利用するＡＰＩを介して、アプリケーションに利用可能にされる。Ｍ２Ｍネットワーク技術の標準化の高まる動向が、Ｍ２Ｍサービス層の標準化であった。例は、ｏｎｅＭ２Ｍ ＴＳ−０００１ Ｆｕｎｃｔｉｏｎａｌ Ａｒｃｈｉｔｅｃｔｕｒｅ Ｖ−１．６．１を含む。

（Ｍ２Ｍサービス層セッション）
Ｍ２Ｍサービス層セッションは、Ｍ２Ｍサービス層インスタンスとＭ２ＭアプリケーションまたはＭ２Ｍサービス層インスタンスのいずれかとの間で確立される通信セッションである。

Ｍ２Ｍサービス層セッションは、接続性、セキュリティ、スケジューリング、データ、コンテキスト等に関連するＭ２Ｍサービス層状態から成ることができる。この状態は、Ｍ２Ｍサービス層、Ｍ２Ｍアプリケーション、または両方によって維持されることができる。

Ｍ２Ｍサービス層セッションは、１つ以上の下にあるより低い層の通信セッションの上に重ねられることが可能である。そうすることにおいて、セッション状態は、異なるセッション間で共有されて活用されることができる（例えば、セキュリティ証明書、輻輳情報等）。加えて、Ｍ２Ｍサービス層セッションは、Ｍ２Ｍサービス層セッションが持続し、設定および解除されているより低い層のセッションから独立して維持され得るように、より低い層のセッションに対して持続性をサポートすることができる。

Ｍ２Ｍサービス層セッションが重ねられることが可能なより低い層のセッションのいくつかの例は、トランスポート層セキュリティ（ＴＣＰ用のＴＬＳ）またはデータグラムトランスポート層セキュリティ（ＵＤＰ用のＤＴＬＳ）等のプロトコルを使用して保証され得る、アプリケーションプロトコル層セッション（例えば、ＨＴＴＰまたはＣｏＡＰ）およびトランスポートプロトコル層セッション（例えば、ＴＣＰならびに／もしくはＵＤＰ）を含むが、それらに限定されない。

（ＯＮＥＭ２Ｍサービス層セキュリティ）
現在、ｏｎｅＭ２Ｍエンドポイントがセキュアな様式で互いに通信するとき、ノードおよび中間ノードは、ホップ毎の様式で互いにセキュリティアソシエーションを確立する。各ホップ（ＡＥ＜−＞ＣＳＥまたはＣＳＥ＜−＞ＣＳＥ）は、互いから独立した別個のセキュリティアソシエーションを有する。ホップ毎のセキュリティアソシエーションは、対称キーを用いて、認証書を使用して、または、ブートストラッピングプロセス（直接プロセスによって、またはインフラストラクチャを用いて行われ得る）によって、確立され得る。ｏｎｅＭ２Ｍ−ＴＳ−０００３ Ｓｅｃｕｒｉｔｙ Ｓｏｌｕｔｉｏｎｓ−Ｖ−１．０．１は、「サービス層レベルで、セキュリティアソシエーション確立は、隣接するＡＥ／ＣＳＥの間で、すなわち、ホップ毎に交換されているメッセージを保護する、ＴＬＳまたはＤＴＬＳセッションをもたらす」ことも記述している。

図３は、関与する２つの通信エンティティに対して固有かつ機密である証明書を使用する（Ｄ）ＴＬＳセキュアアソシエーションを用いた、エンティティ間のホップ毎（ＨｂＨ）のセキュリティアソシエーションを強調表示する。観察されることができるように、ＡＥ１およびＲＣＳＥ１は、２つのエンティティ（ＡＥ１、ＲＣＳＥ１）によって共有されるＨｂＨ証明書（Ｈ１）に基づいて、セキュアな（Ｄ）ＴＬＳ接続を作成する。同様に、ＲＣＳＥ１およびＩＮ−ＣＳＥ１は、Ｈ２証明書を使用してセキュアな（Ｄ）ＴＬＳ接続を設定しており、Ｈ３は、ＩＮ−ＣＳＥとＲＣＳＥ２との間で（Ｄ）ＴＬＳ接続を作成するために使用され、同様に、Ｈ４は、ＡＥ２とＲＣＳＥ２との間でセキュアな接続を作成するために使用される。

ＲＣＳＥ１が情報をＡＥ２に通信することを欲した場合、情報は、最初に、ＲＣＳＥ１とＩＮ−ＣＳＥとの間の（Ｄ）ＴＬＳ接続を通して送信される。次いで、情報は、サービス層において処理され、次いで、再パッケージされて送信され、ＩＮ−ＣＳＥとＲＣＳＥ２との間のより新しい（Ｄ）ＴＬＳトンネルを通して送信される。ＲＣＳＥ２は、メッセージを処理し、次いで、ＲＣＳＥ２とＡＥ２との間の異なるセキュアなトンネルを通して、メッセージを再通過させる。観察されることができるように、どの２つのＨｂＨエンティティ間の通信も、（Ｄ）ＴＬＳによって保証され、したがって、エンティティの間で移動中であるメッセージの機密保持または完全性の侵害は、それらが（Ｄ）ＴＬＳ接続によって保護されるので、極めて困難である。よって、移動中のメッセージを侵害することは極めて困難であるが、しかしながら、メッセージは、セキュアな接続を介して次のホップに転送される前、メッセージを処理しているノードにおいて保護されない場合がある。

（ＩＯＴおよびセキュリティ用語）
認証側：アプリケーション、サービス、リソース、またはネットワークへのアクセスが、別のエンティティに提供され得るように、その別のエンティティを認証するために認証プロシージャを行うエンティティ。

被認証側：リソース、アプリケーション、サービス、またはネットワークへのアクセスを要求し、認証側によって認証される過程にあるエンティティ。

認証：エンティティに関連付けられた識別への信頼を確立するプロセス。

機密保持：権限を与えられたエンティティのみがデータを閲覧することができることを確実にするプロセス。

エンティティ：アプリケーション、アプリケーションのサブセット、サービス有効化機能、デバイス（例えば、センサデバイス）。

エンドツーエンド認証：メッセージの一部として供給された別のエンティティの識別の正当性を確認する能力をエンティティに提供する。通信しているエンティティは、複数ホップ離れていると仮定される。認証は、相互または一方向性であり得る。

完全性：メッセージまたはシステムが権限を与えられていないエンティティによって改変されていないという信頼、もしくは信頼を確立するプロセス。

ＩｏＴ：固有に識別可能なオブジェクトおよびそれらの仮想表現をインターネットに接続すること。

Ｍ２Ｍサービス層：アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通してＭ２Ｍアプリケーションならびにデバイスのための付加価値サービスをサポートするソフトウェアミドルウェア層。

Ｍ２Ｍサービス層ホップ：２つのＭ２Ｍサービス層間、またはＭ２Ｍサービス層とＭ２Ｍアプリケーションとの間のＭ２Ｍサービス層通信セッション。

Ｍ２Ｍサービス層セッション：典型的には、性質がステートフルである２つ以上の通信エンティティ間のメッセージの確立された交換。

Ｍ２Ｍサービス層セッションエンドポイント：Ｍ２Ｍサービス層セッション通信のソースまたはシンクであることができる論理エンティティ。

Ｍ２Ｍサービス層セッションマネージャ：Ｍ２Ｍサービス層セッション管理のためのサービスを提供する論理エンティティ。

ノンス：セッションに関連付けられ得る乱数値であり、その有効性は、セッション／時間成分に関連付けられ得る。

（対処される例示的課題）
サービスプロバイダは、顧客のための遠隔防火等のサービスを提供するために、サービス層機能を使用して、センサ、アプリケーションエンティティ、およびアクチュエータを利用する。種々の使用事例（強盗検出、監視工業システム、および整流等）があり、遠隔Ｍ２Ｍシステムが、検出、アクション、ならびに軽減の両方に使用され得、我々がここで説明しているものと類似するセキュリティ要件を有し得る。例示的シナリオが、図４で描写されている。センサ１−４は、中間ノードを介してアプリケーションにトランスポートされ得るセンサデータを、サービス層メッセージングを介して提供する。次に、センサデータに基づくアプリケーションは、あるアクションを行うようにアクチュエータをトリガし得る。

住居が、火災検出および消火サービス会社へのアラームをトリガするために使用される煙検出センサを具備する、使用事例がある。会社におけるシステムは、アラームに基づいて、センサ情報を処理し、煙が、料理をすることによるか、誰かが煙草を吸っていることによるか、または煙センサ不良によるかを推測し得る。システムは、それが本当に火災であるかどうかを決定するために、住居または隣人の住居内等の他のセンサも使用し、加えて、火災がＡクラス火災であるか、他のタイプの火災であるかを決定するために他のセンサも使用し得る。それが電気火災である場合、スプリンクラシステムは、オンにされてはならない。次いで、システムは、オンにされるようにアクチュエータが散水システムを制御する前に、遮断されるように電気を制御するアクチュエータをトリガし得る。または、工業設定では、次いで、ある化学物質が使用され得、何が使用されるかについての決定も、人／ペットが住居／建物内に閉じ込められているかどうかに基づいて決定され得る。

セキュリティ観点から、より精密には、本書の焦点である認証観点から、システム（アプリケーション）は、煙アラームの指示が、システムが信頼関係を有するエンティティ（例えば、煙アラーム）によって実際にトリガされたことを確認しなければならず、高度な確信を持って、メッセージが実際にその特定のセンサから生じたことを検証することができる。アクチュエータの観点から、アクチュエータは、水スプリンクラをオンにするメッセージが、それが信頼関係を有するシステム（アプリケーション）から生じたことを知っている必要があり、それは、スプリンクラシステムがシステム（アプリケーション）を認証することができることを意味する。

現在のｏｎｅＭ２Ｍ仕様は、ホップ毎のセキュリティ機構のみを提供する。ｏｎｅＭ２Ｍメッセージングを使用して煙センサによって送信された煙アラームは、高度な確信を持って、センサから生じたことがシステム（アプリケーション）によって認証されることができない。センサからシステムにサービス層においてホップ毎の様式でメッセージをトランスポートする１つまたは複数のエンティティは、メッセージタイプを変更することが可能であり得る。実際には火災のタイプが「クラスＣ火災」であった可能性があるときに、それが「クラスＡ火災」（例えば、紙を燃やすことに由来する通常の火災）であることを示すように、中間エンティティがメッセージを変更することが可能である。中間エンティティは、悪意があり得るが、ある場合、あるバグの多いコードを有していた可能性があり、したがって、適切にメッセージを送信しなかった。システム（アプリケーション）からアクチュエータへのメッセージが中間エンティティによって修正される場合、それが悲惨な結果も有し得る。

ｏｎｅＭ２Ｍ ＴＳ−０００３ Ｓｅｃｕｒｉｔｙ Ｓｏｌｕｔｉｏｎｓ Ｖ−１．０．１は、ホップ毎の認証のみを提供し、したがって、遠隔でホストされるサービス層リソース上でＣｒｅａｔｅ／Ｒｅｔｒｉｅｖｅ／Ｕｐｄａｔｅ／Ｄｅｌｅｔｅ／Ｎｏｔｉｆｙ動作を行うことを要求しているエンティティは、遠隔ホストによって明示的に認証されない。遠隔ホストは、リソースまたはリソースを作成したエンティティのいずれかをホストしているエンティティであり得る。加えて、元のメッセージ発信側を認証することを希望するエンティティは、高度な確信を持って認証を行う能力を有していない。前述のように、いずれか２つのＨｂＨエンティティの間で移動中であるメッセージのその機密保持または完全性の侵害は、極めて困難であるが、しかしながら、それは、侵害されたエンティティがなりすましメッセージを別の「信頼される」と推定されるエンティティに送信することを阻止せず、それは、一種の介入者攻撃であるが、より精密には、なりすまし攻撃である。エンドエンティティは、そのような検証能力の欠如により、メッセージが正しいエンティティから生じたかどうかを検証することができない。侵害の種類は、悪意のある意図または悪意のない機構（例えば、コード不良、構成問題等）のいずれかによって引き起こされ得る。

図５は、エンティティＡＥ１がＲＣＳＥ１においてホストされるリソースを作成し、別のエンティティＡＥ２がリソースにサブスクライブすることを欲するシナリオを図示する。ＡＥ２は、リソースにサブスクライブする要求を送信するが、しかしながら、ＲＣＳＥ１は、リソースにサブスクライブする実際の要求が、実際にＡＥ２から生じたかどうかを把握していない。サブスクライブするメッセージは、ＡＥ２からその次のホップ（例えば、ＩＮ−ＣＳＥ）へ、およびＩＮ−ＣＳＥからＲＣＳＥ１へのＨｂＨ機構を使用して、保護されている場合があるが、しかしながら、ＨｂＨ認証のみがホップの各々において行われるので、ＲＣＳＥ１は、ＩＮ−ＣＳＥまたは任意の他のエンティティのいずれかが、それらの独自のメッセージを作成したかどうか、およびＩＮ−ＣＳＥがＡＥ２になりすましているかどうかを検証することができない場合がある。同様に、ＲＣＳＥ１が「通知」メッセージをＡＥ２に送信するとき、ＡＥ２は、「Ｎｏｔｉｆｙ」メッセージが実際にＲＣＳＥ１から生じたことを高度な確信を持って検証することができない。

図６には、そのレジストラＣＳＥ（ＲＣＳＥ１）に登録されたリソースを更新する動作を行うエンティティＡＥ１が図示されている。ＲＣＳＥ１は、ＡＥ１に関連付けられるリソースをサブスクライブしている場合があるエンティティに通知メッセージを送信する。通知は、ＩＮ−ＣＳＥを介してＲＣＳＥ１からＲＣＳＥ２にホップ毎の様式で転送され得る。ＩＮ−ＣＳＥは、悪意のあるまたは悪意のないエンティティのいずれかによって侵害された場合があり、したがって、ＩＮ−ＣＳＥが、「Ｕｐｄａｔｅ」を示す通知を転送する代わりに、「Ｄｅｌｅｔｅ」通知を送信し得ることが仮定される。侵害は、システム上に存在する脆弱性を活用することを伴い、および／または、ＨｂＨ証明書の窃盗、および／またはＩＮ−ＣＳＥ上で起動するコードの承認されていない変更、および／または構成パラメータの修正等を伴い得る。第３のホップでは、ＩＮ−ＣＳＥにおけるサービス層で処理された後、メッセージがホップ毎のセキュリティアソシエーションを使用して保護され、セキュアな（Ｄ）ＴＬＳ接続を介してトランスポートされるので、ＲＣＳＥ２は、メッセージがそうであるため信頼するであろう。したがって、侵害されたエンティティから生じたメッセージさえも、セキュアなトンネル内でトランスポートされるので信頼されるであろう。加えて、ＩＮ−ＣＳＥは、任意の数のメッセージをそれ自身で作成し、ＡＥまたはＲＣＳＥ１にさえもなりすますことが可能であり得る。リソースをホストする、またはリソースの作成に責任がある、もしくはリソースへの更新に基づいてアクションをとる責任があるエンティティが、それから離れている直接ホップのみを認証することしかできないので、したがって、エンティティから２つ以上のホップで離れて生じる任意のメッセージは、高度な確信を持って認証されることができない。

標的エンティティが、それから１ホップ離れているエンティティを認証することしかできないので、リソースをホストするエンティティは、リソースに対して動作を行おうとしているエンティティを完全には認証することができない。したがって、エンドエンティティが、誰が実際にメッセージを開始したかに関して高度な確信を持って検証することができないので、アクセス制御は、容易に実施可能ではあり得ない。エンドエンティティの観点から、Ｅ２Ｅ認証機構の欠如により、転送者のみが認証される。

任意の中間エンティティ（ＩＮ−ＣＳＥ）が、ホップ毎の機構により、他の中間エンティティの代わりにメッセージになりすますことが可能であり得る。

ホップ毎の機構が（Ｄ）ＴＬＳを使用して保護されるものであるので、各ホップにおいて、（Ｄ）ＴＬＳセッションが設定され、各ホップにおいて完全性を保護し、認証し、ならびに、おそらく、リソース制約された中間ノード上の多くのセキュリティ関連オーバーヘッド（例えば、メッセージングオーバーヘッドならびに暗号化動作オーバーヘッド）を伴い得るホップの各々における暗号化および暗号解読をする必要があろう。

エンティティが、２つ以上のホップで離れ得る別のエンティティを認証することが可能であるので、それは、認証側と称される認証エンティティが、被認証側（認証されるであろうエンティティ）に関連付けられる証明書をプロビジョニングされることを要求するであろう。

図７を参照すると、アプリケーションであり得るエンティティＮ（認証側）が、センサであり得るエンティティＡ（被認証側）から生じるメッセージを認証することを欲する場合、エンティティＮは、エンティティＡの公開キー証明書をプロビジョニングされる必要があろう。しかしながら、証明書を配布することのみならず、証明書が暗号化プロセスから使用される方法、より精密には、メッセージ認証が実施される方法のスコープについての情報を提供することも十分ではない。スコープは、メッセージヘッダまたはメッセージヘッダの一部、もしくは、認証タグを作成するために使用されるメッセージの部分またはメッセージ全体自体、ならびにキーサイズ、デジタル署名の長さ、乱数値が使用される必要があるかどうか等を定義し得る。加えて、機構は、エンティティの全てではないがいくつかが、リソースおよび計算観点から制約され得ることを考慮して、そのエンティティ（例えば、被認証側）との使用のために好適である、適切な公開キー証明書および関連付けられるスコープを選択し、プロビジョニングする立場になければならない。認証側への被認証側の証明書の証明書配布も設定されなければならず、証明書およびスコープが認証側のために適切であることも確実にされなければならない。計算観点から適切であり得る正しいタイプの証明書が利用可能にされない場合、代替的認証機構が実施され、Ｅ２Ｅ認証が、より高い計算リソースを有し得る別のエンティティに委託され得るか、または、代替として、認証側および被認証側の両方のために好適であり得るより新しい証明書が導出され得る。認証側および被認証側以外に、サービス有効化機能（ＳＥＦ）および証明書レジストリ（ＣＲ）等の他の機能が、Ｅ２Ｅ認証プロセスを実施するために要求され得る。

ＳＥＦの役割は、セキュアな動作を有効にするために、セキュリティのためのポリシ、有効にされるセキュリティ特徴、生成／プロビジョニングされるべき証明書のタイプ、使用され得る暗号法アルゴリズムおよびプロトコルのタイプ、ならびに他の補足構成パラメータおよびスコープの正しい組をエンティティにプロビジョニングすることである。ＳＥＦは、エンティティによって提供されるサービスのタイプに基づいて、セキュリティ特徴の正しい組の決定を行い、したがって、エンティティのサービス能力を認識している必要があり得る。加えて、ＳＥＦは、セキュリティ特徴の正しい組を決定することにおいて、デバイス能力（例えば、バッテリ、計算、およびメモリ）を考慮し得る。ある実施形態では、ＳＥＦは、随意に、デバイス管理サーバと相互作用することによって、セキュアな機能を有効にするためのアプリケーションパッケージの正しい組をエンティティにプロビジョニングするための機構を提供し得る。

ＣＲは、同一のＭ２Ｍ ＳＰネットワーク内で別のエンティティの一部として常駐し得、ＣＲの主要な役割は、適切な証明書および証明書が使用され得る方法についてのコンテキストならびにスコープをエンティティにプロビジョニングすることである。ＳＥＦおよびＣＲ機能性は、Ｍ２Ｍサービスプロバイダ（ＳＰ）ネットワークの一部として異なるエンティティ上に常駐する機能として実装され得るか、またはネットワーク内の単一のエンティティ上に常駐し得る。代替として、ＣＲは、随意に、Ｍ２Ｍ ＳＰネットワーク外の信頼される第三者エンティティに属し、その上に常駐し得る別のＣＲまたは認証局（ＣＡ）に接続し得る。ＣＲの役割は、ローカルまたはグローバル識別に関連付けられ得る証明書の正しい組をプロビジョニングすることである。

代替的実施形態では、エンティティ（認証側：エンティティＮ）の代わりに認証を実施し得る委託エンティティ（ＤＥ）も、存在し得る。公開キー証明書に基づいてサービス層においてＥ２Ｅ認証を有効にすることに関与し得る、種々のステップの高レベル説明が、ここで簡潔に説明される。

エンドツーエンド認証は、図７に図示されるような以下のステップを伴い得る。

ステップ１、サービス有効化およびセキュリティ構成（ＳＥＳＣ）：このステップでは、エンティティＡが、サービス有効化機能（ＳＥＦ）とのアソシエーションを確立する。ＳＥＦは、エンティティＡによって提供されるサービスのタイプを認識する必要があり得、したがって、ＳＥＦは、エンティティＡに対して適切であるセキュリティ特徴を選択する。加えて、ＳＥＦは、セキュリティ特徴の正しい組を決定することにおいて、デバイス能力（例えば、バッテリ、計算、およびメモリ）を考慮し得る。ここでは、エンティティＮが、事前にそれ自身のＳＥＦを用いてＳＥＳＣプロセスを行っている場合があると仮定される。ＳＥＳＣプロセスの主要な目標のうちの１つは、ＳＥＦにおいてエンティティＡによって要求また提供されるサービスのタイプを登録することであり得る。加えて、エンティティＡによって必要とされるか、または要求されるセキュリティ要件および特徴も、ＳＥＦによって識別される。ＳＥＦは、例えば、Ｍ２Ｍサービスプロバイダによって、またはエンティティＡの製造業者によって、もしくはアプリケーションプロバイダ／デバイスマネージャ（ＤＭ）によってホストされ得る。いくつかの場合において、エンティティが、適切なセキュリティ特徴および機能、ならびに特徴／機能の使用を統制する関連付けられるポリシを事前プロビジョニングされた場合、ＳＥＳＣプロセスは、省略され得る。プロビジョニングされたセキュリティ特徴および機能は、エンドツーエンドセキュリティ特徴のみに限定されないこともある。そのようなシナリオでは、ステップ２−４のみが行われ得る。

ステップ２は、セキュリティ証明書登録／請求プロセス（ＳＣＲＰ）である。ステップ１の一部として識別されたセキュリティ要件および特徴に基づいて、または、セキュリティ特徴が事前プロビジョニングされた場合、エンティティＡは、その公開キー証明書を登録するか、またはＣＲによって、適切な公開キー証明書によってプロビジョニングされる。登録される証明書は、Ｅ２Ｅ認証のために適用可能であり得るものである。その証明書が登録されている場合、それらは、未加工公開キー、または関連付けられる公開キー認証書（例えば、Ｘ．５０９）を有し得る公開キーであり得る。ＣＲが認証書を発行するとき、ＣＲは、いくつかの場合において、大域的に容認可能であり得る公開キー認証書を発行するために、他のネットワークエンティティ（例えば、ＣＡ）を使用し得る。発行される証明書は、認証書であり得るか、またはプロセスは、ローカルＣＲ内への、またはエンティティＡが信頼関係を有し得る外部ＣＡへの未加工公開キー証明書の登録のみを含み得る。信頼関係はまた、ＣＲ／ＣＡとのＳＰの信頼関係に基づく推移的信頼関係であり得る。エンティティＡに発行された未加工公開キー証明書は、デジタル署名に基づいてソース認証（より適切にはメッセージソース認証）および否認防止を保証するために、エンティティＡによって使用され得る。ステップ２は、ＳＥＦを使用して促進され得ることも想定され得る。

ステップ３は、第三者証明書請求プロセス（ＴＰＣＲＰ）である。権限を与えられたエンティティへの証明書の配布は、証明書請求または暗示的証明書プロビジョニングプロセスを行う第三者エンティティを含むであろう。エンティティのＥ２Ｅ証明書を受信する権限を与えられているエンティティを決定することは、アクセス制御リスト、属性ベースのアクセス制御、役割ベースのアクセス制御、または動的承認機構に基づき得るアクセス制御ポリシに基づいて決定され得る。エンティティ、例えば、エンティティＮも、公開証明書をプロビジョニングされ得、公開証明書は、セキュアな様式で、エンティティＮがエンティティＡによって提供されるサービスにアクセスすることができ、その逆も同様であるように、セキュリティアソシエーションがエンティティＮとエンティティＡとの間で確立され得るために、エンティティＡによって登録されたか、またはエンティティＡにプロビジョニングされたかのいずれかである。エンティティＮは、エンティティＡから生じるメッセージを認証するために、公開キー証明書を使用し得る。

ステップ４ａは、エンドツーエンド認証プロセス（Ｅ２ＥＡＰ）である。ＳＥＳＣ、ＳＣＲＰ、およびＴＰＣＲＰステップ後、エンティティＮは、エンティティＮによって取得された、またはＴＰＣＲＰ中にエンティティＮにプロビジョニングされた証明書に基づいて、このステップでエンティティＡのメッセージのＥ２Ｅ認証を行う。

ステップ４ｂは、委託モードを使用するＥ２ＥＡＰである。代替的方式では、エンティティＮは、その代わりにエンティティＡから生じるメッセージを認証するために、認証プロセスを信頼される第３のエンティティ（例えば、ＤＥ）に委託し得る。

（サービス有効化およびセキュリティ構成（ＳＥＳＣ）プロセス）
このプロセス中、ＳＥＦは、エンティティによって提供または要求されるサービスおよびリソースに適するであろう適切なセキュリティ要件および特徴を決定する。セキュリティ要件および特徴は、ある推測プロセスを使用して決定され得るか、エンティティによって明示的に提供され得るか、またはシステムを設定し得る管理者によって構成され得る。エンティティは、認証側または被認証側であり得、役割に基づいて、適切なセキュリティ特徴が決定され得る。セキュリティ要件についての推測は、デバイスタイプ／能力および提供されるサービス／リソースのタイプ等のエンティティによって提供される情報を使用して決定され得る。デバイスタイプ／能力は、処理能力、メモリ、電力消費量、および／または使用されている無線技術（例えば、帯域幅制限）を含み得る。提供されるサービス／リソースのタイプは、セキュリティ要件およびセキュリティ等級に関連し、データの完全性（例えば、高）、メッセージ発信側認証（例えば、高）、否認防止（例えば、高）、および／または機密保持（例えば、低）を含み得る。エンティティは、セキュリティ要件および等級、ならびにデバイス能力およびサービスのタイプをセキュアな様式でＳＥＦに提供し得る。

図８は、ＳＥＳＣ要求／応答メッセージングの例示的コールフローを図示する。メッセージ１では、エンティティＡは、ＳＥＳＣプロセスがＳＥＦと開始されることを要求する。メッセージの一部として、エンティティＡは、そのデバイスタイプ、固有のデバイスＩＤ（ＤＩＤ）または能力、もしくは両方、および随意に、セキュリティ能力を提供し、エンティティが提供するサービス／アプリケーションのリストも提供し得る。

ステップ２では、ＳＥＦは、要求を受信することに応じて、その能力（例えば、デバイス、セキュリティ）に基づいて、エンティティＡのために適切であり得るセキュリティ特徴／属性および関連付けられるパラメータのリストの決定を行う。そして、エンティティＡが提供するサービス／アプリケーションのタイプに基づいて、ＳＥＦは、セキュリティ特徴および関連付けられる属性ならびにパラメータの狭いリストを選択し得る。加えて、特徴が使用され得る方法、属性に関連付けられる存続期間等についてのポリシも、ＳＥＦによって決定され得る。代替として、ＳＥＦは、エンティティＡによって使用され得る特徴の優先順位リストを作成し得る。

メッセージ３は、ポリシとともに、セキュリティ特徴および関連付けられる属性ならびにパラメータを含むＳＥＦからの応答である。ＳＥＦはまた、以下のフラグおよび／またはデータを示し得る：ＨｂＨセキュリティの回避（例えば、Ｅ２Ｅセキュリティのみを使用する）、ＨｂＨおよびＥ２Ｅの両方の使用、またはＨｂＨのみの使用；ＳＥＦがＣＲ機能性も果たすかどうか；および、ＣＲの場所またはＵＲＩ。

ステップ４では、エンティティＡは、随意に、セキュリティポリシ、および／または、属性および関連付けられるパラメータを拒否し得る。

メッセージ５では、エンティティＡは、属性および対応するパラメータが合意されるまで、セキュリティ属性ネゴシエーションプロセスに参入し得る（随意のステップ）。ネゴシエーションは、メッセージ３の中で取得される情報に基づき得るか、またはメッセージ３の中で取得される情報から独立し得る。

適切なセキュリティ特徴および関連付けられる属性／パラメータの選択は、一次的に、デバイスの能力（例えば、デバイス、セキュリティ）に基づき、二次的に、エンティティによって提供されるサービスのタイプに基づき得る。例として、「低」セキュリティ機能を要求するサービスのみを提供する低電力の低メモリデバイス、選択されるアルゴリズム、および、低メモリ占有面積を使用し、あまり計算集中的ではない動作を選択することによってバッテリリソースを失わせないものであり得るキーサイズである。例えば、限定された能力を伴うエンティティに対して、選択されるデジタル署名が、２０４８ビットキーを伴う２５６バイトであり得る一方で、より多くの処理およびメモリを伴い、メッセージ認証のためのより高い確信を要求するエンティティは、ＳＨＡ−２５６機構（よりセキュアなアルゴリズム）とともに使用され得る４０９６ビットキーをプロビジョニングされ得る。

代替として、エンティティは、明示的セキュリティ要件のリストを提供し、承認および構成のためにそれをＳＥＦに送信し得る。代替として、ＳＥＳＣプロセスは、エンティティが適切なセキュリティ属性およびパラメータで事前構成される場合、省略され得る。表２は、セキュリティ要件の例示的リストである。

代替として、エンドエンティティ、すなわち、エンティティＮは、エンティティＡから生じるメッセージに対してＥ２Ｅ証明書を含むことをＭ２Ｍ ＳＰ（またはより具体的にはＳＥＦ）を要求することが可能であり得る。

ＳＥＳＣプロセスの終了時、ＳＥＦは、エンティティの完全なプロファイルおよび能力を有する。エンティティの能力の知識を有することは、ＳＥＦがエンティティの作業を保護するために実装されなければならない適切なセキュリティ対策を決定することに役立つ。ＳＥＦは、エンティティの能力の表を維持する。表３は、ＳＥＦにおいて維持される種類の例である。

表３は、セキュリティ特徴のタイプおよび使用される証明書のタイプを割り当てられたエンティティ（エンティティＡおよびＢ）の例示的リストを図示する。各セキュリティ特徴に対して、使用されるプロトコル／アルゴリズム、関連付けられるキー／証明書サイズ、および様々な情報を示し得る関連付けられる値／パラメータがあり得る。エンティティＢが、より強力な暗号化アルゴリズム／プロトコルを用いて設定されるように割り当てられているので、エンティティＢは、より重要なメッセージングおよび／または情報を提供し、おそらく、より多くの計算リソースを有し得る。エンティティＢは、Ｅ２Ｅ手段を使用して認証される能力も有する。

ＳＥＦは、以下のサービスおよび同サービスの指示をエンティティに提供し得る：ＳＥＦがＣＲ機能性を果たすかどうかという指示；ＳＥＦがＣＲ機能性を提供しない場合、ＣＲの場所またはＵＲＩ；ＨｂＨセキュリティがリソースを保存するために回避され得、Ｅ２Ｅ認証のみが使用され得るかどうかの指示等。

（委託セキュリティ機構対直接セキュリティ機構）
公開キーベースの認証機構は、より高い計算コストを招き得、したがって、より低い計算リソース（メモリ、処理）を有するあるデバイスのために好適ではないこともある。そのような状況では、認証または認証の検証は、信頼されるエンティティ（例えば、ＤＥ）に委託され得る。

エンティティまたはリソースの真正性について高度な確信を要求するシステムに対して、委託が回避され得、代わりに、「直接」機構が使用され得る。直接機構では、エンティティは、公開キー証明書を提供され、公開キー証明書は、デジタル署名を作成するために、またはデジタル署名を検証するためにそのエンティティによって使用され得る。エンティティがそれ自身でＥ２Ｅ認証および他のセキュアな動作を行うことが可能である場合、エンティティは、委託を必要とすることなく、それ自身で直接認証を行うことを選び得る。ＳＥＦは、エンティティによって提供または使用されるデバイス能力もしくはサービス要件に基づいて、勝手にエンティティの代わりに委託のオプションを選択し得る。ハイブリッドアプローチも、採用され得る（例えば、信号伝達または他の動作オーバーヘッドを低減させる）。これは、セキュリティ機能の一部が委託される一方で、他のセキュリティ機能が直接果たされるときである。エンティティがエンドエンティティとの暗号化／解読を行うことが可能であり得る一方で、エンドツーエンド認証は、その代わりに、ＤＥによって（例えば、ＳＥＦによって、または逆も同様に）行われる。

（セキュリティ証明書請求／登録プロセス（ＳＣＲＰ））
ＳＣＲＰプロセスは、エンティティによって、またはエンティティの代わりにＳＥＦによって開始されるセキュリティ証明書請求プロセスを伴い得る。エンティティによって提供または要求される能力および／またはサービスのタイプに基づいて、適切なセキュリティ証明書、および加えて、他の構成パラメータが、好ましくは信頼される第三者上でホストされる証明書レジストリ（ＣＲ）から要求される。エンティティとＣＲとの間の認証は、ＳＣＲＰ要求が処理される前に実施されることが大いに推奨されるが、エンティティがいかなる証明書も有していないある場合、かつエンティティおよびＣＲが同一の信頼されるドメイン内に属する場合、認証は、随意であり得る。代替として、ＣＲ機能性は、ＳＥＦ上でホストされ得るが、しかしながら、拡張可能性の観点から、ＣＲ機能性は、ＴＴＰ等の異なるエンティティによって果たされ得る。ＣＲは、公開キー証明書を生成し得、証明書が使用され得る方法のスコープ、使用される推奨アルゴリズム等を提供する。そして、ＣＲは、直接、または随意に、ＳＥＦを介して、生成された証明書をエンティティに転送する。ＣＲによって生成される証明書は、例えば、公開キー認証書（例えば、Ｘ．５０９認証書）または未加工公開キー（認証書を伴わない）であり得る。

図９は、エンティティＡがＣＲ／ＣＡにセキュリティ証明書を要求するＳＣＲＰプロセスを図示する。ステップ０では、相互認証が、エンティティＡとＣＲ／ＣＡとの間のメッセージングを介して実施され得る。ある場合、認証は、特に、エンティティＡがいかなる証明書も有していない場合において、および／または、ＣＲ／ＣＡが同一のセキュリティドメイン内に位置する場合に、随意であり得る。全ての他の場合において、認証ステップは、必須であり得る。認証が起こるかどうかにかかわらず、完全性および機密保持のために保護されるセキュアな接続が確立され得る（例えば、ディフィ・ヘルマン機構を使用する）。

メッセージ１では、エンティティＡは、ローカルスコープを有する認証書を要求し、要求は、ステップ１で確立されたセキュアなトンネルを通して行われる。証明書のタイプおよびスコープは、以前に実施されている場合があるＳＥＳＣプロセスに基づき得る。代替として、エンティティＡは、認証書を必要とすることなく、未加工公開キーを要求し得る。

ステップ２では、ＣＲは、要求を処理し、公開／秘密キーペアを生成する。要求がローカルスコープに対するものである場合、ＣＲは、公開キーとともに、エンティティＡの識別に割り当てられる認証書を作成し得、ＣＲの秘密キーを使用して認証書に署名する。スコープが大域的であった場合、ＣＲは、公開キーをＣＡに送信し、認証書の発行を要求し得、ＣＡは、認証書を生成し、署名し、それをＣＲに送信する。ＣＡは、ＣＲよりも大域的なスコープを有すると仮定されている。

メッセージ３では、ＣＲは、セキュアな様式で認証書ならびに秘密キーをエンティティＡに送信する。

秘密キーは、セキュアな様式でエンティティにプロビジョニングされ、別のチャネルを使用し得る。あるフォーマットが証明書の配信に使用されることが想定され得る。公開キー暗号化規格（ＰＫＣＳ）プロトコルが、要求およびプロビジョニングプロセスに使用され得る。代替として、公開キー証明書は、例えば、ＪＳＯＮウェブキー（ＪＷＫ）構造を使用して、ＣＲからエンティティにトランスポートされ得る。エンティティは、証明書が配布されるフォーマットを要求し得るか、または、フォーマットは、証明書がＣＲによってエンティティにプロビジョニングされる前にＳＣＲＰ要求／応答メッセージを使用してネゴシエートされ得る。

代替として、セキュリティ証明書登録プロセスでは、エンティティは、証明書（公開／秘密キーペア）を生成し、次いで、証明書がＣＲに登録されることを要求し得る。登録プロセスの結果として、エンティティに関連付けられる秘密キーは、エンティティ上に残留するが、しかしながら、公開キーは、公開キー暗号化規格（例えば、ＰＫＣＳ）を使用して、ＣＲに登録されるためにエンティティによって送信される。秘密キーが、セキュアな様式で（例えば、セキュアな要素、すなわち、エンティティ上のＳＩＭ／ＵＩＣＣ／ＴＥＥ内で）記憶されることが確実にされるべきである。エンティティに関連付けられた固有の識別も、証明書要求の一部として含まれる。登録プロセスは、複数の往復メッセージを伴い得る。プロセスの終了時、認証書が生成されてエンティティにプロビジョニングされるか、または、未加工公開キーがレジストリ内に登録され、エンティティＡに関連付けられた固有のＩＤに関連付けられる。

エンティティ（例えば、アプリケーションまたはデバイスもしくはサーバ）は、１つ以上の証明書を要求し得るか、もしくは１つ以上の証明書をＣＲに登録し得る。エンティティは、種々のコンテキストのための証明書を使用し得る。コンテキストは、どのようにして証明書が使用されることを意図されているかに基づいて、エンティティによって定義されることができる。コンテキストは、エンティティ内で固有であり得、エンティティに関連付けられるとき、それは、ＣＲのドメイン内で固有でなければならない。したがって、いかなる２つのコンテキストも、同一の識別、したがって、同一の公開キーを有することはできない。エンティティがそれらの証明書をＣＲに登録するとき、ＣＲは、エンティティ内のコンテキストが固有に識別可能であることを確認しなければならず、ＣＲのドメイン内で固有に識別可能なエンティティがある場合、公開キー証明書は、固有であり、正常にＣＲ内に登録され得る。

エンティティが証明書を要求する場合において、エンティティＩＤ（例えば、ＵＲＩ）、コンテキストＩＤ、関連付けられるキー、および他の関連付けられるパラメータならびに「スコープ」が、要求するエンティティに提供され得る。「スコープ」は、暗号化プロセスのタイプについての詳細を提供し得る。スコープは、使用されているアルゴリズムのタイプ、使用され得るパラメータ、ＤＳ／ＭＡＣの導出に使用される「ヘッダ」情報（メッセージ発信元情報詳細）、鮮度情報が使用される必要があるかどうかについての標識情報（例えば、「ＧＢＡ標識」）等を含み得る。スコープは、どのようなタイプのメッセージが認証され得るかも含み得る。例えば、「Ｎｏｔｉｆｙ」メッセージは、アプリケーションのために非重要と見なされ得、認証タグを全てのＮｏｔｉｆｙメッセージに提供しないことを選定し得る一方で、全ての「ｕｐｄａｔｅ」メッセージは、認証タグを提供され得る。ＳＥＦは、エンティティＡによって提供されるサービスの能力およびタイプに基づいて、Ｅ２Ｅ認証のスコープを調整することが可能であり得る。代替として、エンティティＩＤ、随意に、コンテキストＩＤを含む要求が、エンティティによってＣＲに送信され得る。認証パラメータは、エンティティが認証タグ（例えば、デジタル署名）を作成するときに、セキュリティプロセス（例えば、認証プロセス）の一部として含まれ得る、セキュリティ情報を示し得る。確立される各セキュリティコンテキストは、有効存続期間を有し、その後、コンテキストが更新され得るか、または新しいものが作成され得る。

Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）を使用してエンティティ２にプロビジョニングされるキーの例示的表現が、図１０に示されている。

（第三者証明書請求（ＴＰＣＲ）プロセス）
このステップでは、別のエンティティ（例えば、エンティティＡまたはエンティティＢ）のエンドツーエンド認証を行うことを要求されるエンティティＮは、Ｅ２Ｅ認証が実施され得るように、認証書または公開キーイング材料、キーに関連付けられるスコープ、メッセージ認証を実証するために使用され得るパラメータ（例えば、デジタル署名）、および他の情報を要求し得る。要求するエンティティＮは、ＣＲと互いに認証され得、エンティティＮの承認は、随意に、エンティティＡの公開キー証明書（認証書または未加工公開キー）がエンティティＮに公表される前に行われ得る。ある場合において、エンティティＮの認証は、証明書が公開証明書であるので省略される。ＣＲによるエンティティＮの認証に加えて、ＣＲは、エンティティＮがエンティティＡに関連付けられる証明書を取得する権限を与えられているかどうかを検証するためにチェックし得る。エンティティＮが正常に認証され、権限を与えられていると見なされた場合、エンティティＮは、エンティティＡの証明書、コンテキストＩＤ／ＵＲＩ、ポート番号、関連付けられるキー、スコープ、および関連付けられるパラメータをプロビジョニングされる。

図１１は、ＴＰＣＲプロセスを描写するコールフローを描写する。メッセージ０では、ＣＲは、証明書請求サービスをエンティティにアドバタイズする。

ステップ１では、エンティティＮとＣＲとは、相互認証を行う。このステップは、エンティティＮとＣＲとの間に信頼関係がある場合、随意であり得る。

メッセージ２では、エンティティＮは、エンティティＡのＥ２Ｅ公開キー証明書、パラメータ、スコープ等を取得するために、エンティティＡのＩＤ（例えば、エンティティＡのＵＲＩ）を含むことによって、エンティティＡの証明書を要求するＴＰＣＲを送信する。

ステップ３では、ＣＲは、エンティティＮが実際にエンティティＡの公開証明書を取得する権限を与えられているかどうかを確認するために、随意のアクセス制御チェックを行い得る。

メッセージ４では、ＣＲは、エンティティＡの公開キー証明書（例えば、認証書、未加工公開キー）および関連付けられるスコープ、ならびに要求されたパラメータをエンティティＮに送信する。

エンティティＮにおいて、エンティティＮは、ＴＰＣＲプロセスの完了後、それがセキュリティアソシエーションを作成して維持することを欲するエンティティ（例えば、エンティティＡ）に関する以下のパラメータを維持し得る。

表５では、エンティティＮがエンティティＡとＥ２Ｅ認証を行うために、エンティティＮは、エンティティＩＤ、コンテキストＩＤ、認証のタイプ、ポート番号、認証プロトコル、証明書、プロトコル、有効性時間、および種々の関連付けられるパラメータを提供され得る。

エンティティＩＤ情報は、アプリケーション、デバイス、サーバソフトウェアプログラム等であるエンティティを参照し得る。リソース識別子を使用するサービスプロバイダドメイン内で固有に識別可能であり得るあらゆるものが、エンティティＩＤを与えられ得る。

コンテキストＩＤ情報は、証明書が使用され得るエンティティ内のコンテキストを識別するために使用され得る。コンテキストは、定義され得るが、署名動作（例えば、デジタル署名を計算すること）または暗号化動作もしくは任意の他の暗号動作に限定されない。

認証情報のタイプは、認証が実行され得る層を決定する。これらは、サービス、セッション、ネットワーク、ＭＡＣ層において実行され得る認証を含む。サービスおよびセッション層における認証機構が、本開示のために着目される。

セッション層Ｅ２Ｅ認証の場合、ポート番号が、随意に、提供され得る。

認証プロトコル情報は、証明書が使用され得るプロトコルの選定を示し得る。これは、随意であり得る。例えば、公開キー証明書は、限定された計算またはメモリリソースを有し得る、エンティティのための暗号化目的で使用されないこともある。

証明書情報は、タイプ（例えば、Ｅ２Ｅ、ＲＳＡ）ならびに実際の証明書（例えば、公開キーまたは認証書全体）を含み得る。

プロトコル情報は、例えば、ＴＬＳ、ＤＴＬＳ、ＩＰＳｅｃ、またはＥＡＰ等の使用され得る、もしくは使用されなければならない特定のプロトコルであり得る。プロトコル情報は、例えば、デジタル署名、ＭＡＣ、またはＪＷＳを使用して、使用され得る検証のタイプ等についての情報も含み得る。

有効性情報は、各証明書に関連し得る。例えば、各証明書は、それが有効である日数（例えば、秒／分／日等）または証明書が満了し得る日付のいずれかによって表される存続期間に関連付けられ得る。

パラメータは、キー保有／メッセージ認証の証拠を提供するために使用され得る値を含み得る。ホップ毎の保護機構が依然として使用され得るサービス層におけるＥ２Ｅ認証は、加えて、Ｅ２Ｅデジタル署名を組み込み得る。加えて、性質が機密と見なされる情報およびパラメータも、サービス層において保護され得る。メッセージ完全性保護および／またはメッセージ認証は、ＪＳＯＮウェブ署名（ＪＷＳ）を用いて、もしくはＪＳＯＮウェブ暗号化（ＪＷＥ）を用いて、提供され得る。メタデータまたはルーティング可能なデータのみが、中間ノードによって処理され得る。メタデータは、完全性を保護され、Ｅ２Ｅセキュリティのための公開キーに関連付けられる秘密キーを使用して作成されるＥ２Ｅ ＪＳＯＮウェブ署名によって認証され得る。代替として、いかなる中間ノードによっても修正されないメッセージ全体が、メッセージ全体のデジタル署名（ＤＳ）を表すＪＳＯＮウェブ署名またはＪＳＯＮウェブ暗号化（ＪＷＥ）を作成するために使用され得る。署名（ＤＳまたはＪＷＳ）が他の手段を使用して生成され、専用機構を使用して表されることも可能であり得る。メッセージング内の署名および署名の表現を生成するために使用される機構にかかわらず、中間ノードによって処理／除去されない全体的メッセージは、時間成分、または時間とノンスとの両方の組み合わせに関連付けられるノンス／乱数値を利用することによって、再生攻撃に対して保護され得る。例えば、署名は、ＣＲによって、秘密キーを使用して導出され、Ｅ２Ｅ認証を要求するエンティティにプロビジョニングされるか、または、エンティティによって生成され、セキュアな様式でローカルに記憶され得る。

同様に、発信側情報が、メッセージの発信側を認証するために使用され得る。メッセージ情報の正しい組がメタデータの作成に使用される場合、それは、メッセージの発信側のＥ２Ｅ認証だけでなく、メッセージの「意図」も認証するために使用され得る。メッセージの意図は、メッセージのソース（発信側）、メッセージの宛先（受信側）、メッセージのタイプ、メッセージがトリガし得る動作のタイプ、および動作（Ｃｒｅａｔｅ、Ｄｅｌｅｔｅ、Ｕｐｄａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｎｏｔｉｆｙ）が行われるリソース（例えば、センサリソース）を示し得る。「発信側情報」が、いかなる中間ノードによっても修正されていないことが仮定される。メッセージが中間ノードによって修正されないとき、「発信側情報」は、メッセージ全体を含み得る。発信側情報に関連付けられる例示的パラメータは、メッセージのソース／発信側に関連付けられる識別子を伴う「ｆｒ」（ｆｒｏｍ）フィールド；メッセージの宛先を示す「ｔｏ」フィールド；実施される動作のタイプ、例えば、Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ、またはＮｏｔｉｆｙを示す「ｏｐ」フィールド；固有のリソース識別またはリソースのタイプを示す「ｒｅｓ−ＩＤ」フィールド；固有のセッションを示す「ｓｅｓｓｉｏｎ−ｉｄ」フィールドを含み得る。セッションＩＤは、連続順の数字または乱数値（例えば、ノンス）であり得、時間成分（例えば、ＮＴＰ）に関連付けられる場合もあり、関連付けられない場合もある。

パラメータは、セキュリティパラメータを含み得る。例えば、セキュリティパラメータは、１つ以上の乱数値、ノンス、または元のメッセージが作成されたときのタイムスタンプ等の時間パラメータを含み得る。ノンスは、固有にセッションと関連するために使用され得る。加えて、セキュリティパラメータは、使用されるべき暗号化パッケージソフト、使用されるべき証明書等の方法／タイプについての情報を含み得る。

セキュリティパラメータは、セッション層の指示を含み得る。ＤＴＬＳまたはＴＬＳを用いたＥ２Ｅ認証が、使用される。これは、ホップ毎のセキュリティ機構を回避するであろう。エンドエンティティが互いに認証され、セキュリティアソシエーションが確立される。これは、真のＥ２Ｅ様式（直接）または委託モードで、エンティティの間で行われ得る。Ｅ２Ｅ公開キーが、ＨＴＴＰＳ／ＣｏＡＰＳ等のアプリケーション層プロトコルを使用して、２つのエンドポイントの間で認証するために使用され得る。

（エンドツーエンド認証プロセス（Ｅ２ＥＡＰ））
Ｅ２Ｅ認証プロセスは、直接Ｅ２Ｅ様式で、または委託もしくは部分的委託（ハイブリッド）様式で行われ得る。Ｅ２Ｅ認証は、相互Ｅ２Ｅ認証を伴うことも、伴わないこともあり、Ｅ２Ｅ様式で一方向認証のみを伴うこともある。多くの場合、Ｅ２Ｅ認証は、別のエンティティを認証するエンティティＮ（認証側）、エンティティＡ（被認証側）のみを伴い得、その逆は同様ではない。使用事例およびＳＥＳＣプロセスに応じて、Ｅ２Ｅ相互認証が要求され得ることが決定され得る。本書で説明される機構は、相互Ｅ２Ｅ認証ならびに一方向Ｅ２Ｅ認証の両方を行うために使用されることができる。そのような場合において、エンティティＡは、被認証側ならびに認証側の両方として挙動する。同様に、エンティティＮは、被認証側ならびに認証側の役割を果たす。そのようなシナリオでは、エンティティＮは、ＳＥＳＣおよびＳＣＲＰプロセスを事前に行った場合があり、エンティティＡは、ＴＰＣＲプロセスを行ったことが仮定される。Ｅ２Ｅ認証の概念を解説するために、本書では、類似プロセスが相互認証を行うために実施され得るため、一方向認証のみが詳細に説明され、そのような場合において、ＳＥＳＣ、ＳＣＲＰ、ＴＰＣＲプロセスを行うことにおけるエンティティＡおよびエンティティＮの役割は、逆転させられる。本書の他の部分に対して、Ｅ２Ｅ認証という用語は、メッセージの発信側の一方向または相互認証のいずれか、および／またはメッセージの実際の意図の認証もしくはメッセージ全体の認証を意味するであろう。

エンティティによって提供または選択されたスコープに基づいて、Ｅ２Ｅ認証プロセスは、ＪＷＳ／ＪＷＥにおいてＤＳを検証することによって実施され得る。例えば、認証書ベースの機構が使用され得、それによって、プロビジョニングされる証明書は、認証書の形態で表され、適用可能であるコンテキストのために権限を与えられたエンティティのみによって使用される公開キーに基づき得る。Ｅ２Ｅセキュリティアソシエーションを確立することを希望するエンティティは、認証書に関連付けられる公開キーに基づく認証およびメッセージ認証のために認証書を使用し得る。認証書は、ＣＲとのＥ２Ｅ認証プロセス中に（ＴＰＣＲ段階中に）事前プロビジョニングまたは取得され得る。代替として、公開キーは、エンティティによって別のエンティティに登録され、特定のコンテキストに関連付けられ得る。エンティティは、秘密キーの保有を検証するために、ランダムハンドル（ノンス）を使用してチャレンジされ得る。ある場合、チャレンジは、随意であり得るが、鮮度情報が、生成された固有のランダムハンドル／ノンスを使用することによって、メッセージの発信側および署名によって提供され得る。

別のエンティティから生じるメッセージのＥ２Ｅ認証を行うエンティティは、ＴＰＣＲ段階中に適切なＥ２Ｅ証明書を取得し得る。加えて、エンティティは、スコープ等の他の関連情報も取得し得る。認証プロセスの一部として、エンティティは、スコープ情報に基づいて、どのようなタイプのメッセージ（例えば、Ｃｒｅａｔｅ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ等）が認証タグで保護されることが予期されるかを確認するためにチェックし得る。メッセージが受信されると、エンティティは、そのリソースに関連付けられるスコープ情報を確認するためにチェックし、ＴＰＣＲプロセス中にローカルで記憶されている場合がある適切な証明書を取得するか、またはＴＴＰから明示的にそれを取得する。スコープ情報および証明書、ならびに元のメッセージのメッセージ発信元情報またはメッセージ意図（例えば、メタデータ）に基づいて、エンティティは、ＤＳまたはＡｕｔｈタグを計算する。エンティティは、Ａｕｔｈタグをメッセージの一部として送信されたＡｕｔｈタグと比較し、任意の相違がある場合に、メッセージは、破棄され得る。

図１３は、エンティティＮの代わりにＤＥによる、エンティティＡのメッセージの一方向認証を描写する、例示的コールフローである。エンティティＡは、Ａｕｔｈ−Ｔａｇ１（例えば、ＤＳまたはＭＡＣ）も含むメッセージ１を送信する。メッセージは、メッセージが、メッセージ発信側認証目的で使用されることができるＡｕｔｈタグを有することを示す随意のフラグ１を含み得る。

ステップ２では、エンティティＮの代わりにメッセージ認証を行うようにエンティティＮによって権限が与えられているＤＥが、暗示的機構を使用して、またはＴＰＣＲプロセスを行うことによって明示的に、エンティティＡの公開キー証明書を取得し得る。次いで、ＤＥは、Ａｕｔｈ−Ｔａｇ１を検証する。ＤＥは、フラグ１に基づいて認証を行うことを決定し得る。非委託モードでは、エンティティＮは、単独でＡｕｔｈ−Ｔａｇ１を検証し、メッセージ３は、省略される。

ＤＥは、メッセージ３をエンティティＮに転送する。メッセージ３は、メッセージ発信側がＥ２Ｅの観点から正常に認証されているかどうかを示すフラグ２を含み得る。

ステップ４では、エンティティＮは、フラグを検証し、フラグに基づいて、メッセージを処理する。

（例示的実施形態）
ここで説明される実施形態は、主にｏｎｅＭ２Ｍアーキテクチャに焦点を当てている。以前に説明された一般的機能（例えば、ＳＥＦ、ＣＲ）は、「セキュリティ」ＣＳＦの一部としてｏｎｅＭ２Ｍアーキテクチャに組み込まれ得、図１４で描写されている。

前の節で説明されるように、Ｅ２Ｅ認証プロセスは、４つのステップを伴い得る。ある実装／実施形態では、ステップは、関与するエンティティおよびエンティティと採用されるプロトコルとの間のそれらの信頼関係に基づいて、組み合わせられ得る、または最適化され得る。サービス層を使用するソリューション（例えば、ｏｎｅＭ２Ｍ）の高レベル説明が、以下で説明される。

（サービス有効化およびセキュリティ構成（ＳＥＳＣ））
ＳＥＳＣ機能は、共通サービスエンティティ（ＣＳＥ）上でホストされ得る。ＳＥＳＣは、ｏｎｅＭ２Ｍ登録プロセスに先立って、アプリケーションエンティティとＣＳＥとの間で実施され得る。ＳＥＳＣ機能は、随意に、サービスプロバイダドメイン内に常駐するエンティティ上でホストされ得、その場合、ＡＥは、Ｍ２Ｍサービスプロバイダ（ＳＰ）ネットワーク上でホストされるエンティティとＳＥＳＣプロセスを行う。ＳＥＳＣプロセスは、ＴＴＰ、例えば、信頼イネーブラ機能（ＴＥＦ）、Ｍ２Ｍ登録機能（ＭＥＦ）、またはＭ２Ｍ認証機能（ＭＡＦ）によって実施され得る。通常のｏｎｅＭ２Ｍ登録プロセスの結果として、ホップ毎のセキュリティのための適切な証明書が、ＡＥおよびＣＳＥにプロビジョニングされ得る。ＳＥＳＣプロセスの一部として、適切な証明書、スコープ、およびパラメータの識別が実施される。レジストラＣＳＥがＳＥＳＣ機能も果たしている場合、Ｅ２Ｅ証明書プロビジョニングおよび登録プロセスも、ＳＥＳＣプロセス中に実施され得る。

図１５は、ＣＳＥに登録することの例を図示し、サービス有効化およびセキュリティ構成（ＳＥＳＣ）機能は、レジストラＣＳＥ（ＲＣＳＥ）に常駐する。ステップ０では、ＡＥ１は、ＡＥ１がペアにされ、そしで、（現在のｏｎｅＭ２Ｍ仕様で説明される機構に従う）レジストラＣＳＥ（ＲＣＳＥ）に登録されることができるために構成され得る証明書をプロビジョニングされる。ＡＥ１の構成は、ＧＵＩ、ウェブインターフェース、またはコンソールからのインターフェースを用いて、例えば、ＲＣＳＥの共有秘密をＡＥに入れることによって行われ得る。任意の数のＡＥが、最初に、同一の秘密をＲＣＳＥと共有し得る。または、１回限りのパスワードが、ＲＣＳＥとＡＥとをペアにするために使用され得る。代替として、ＡＥ認証書が、認証書または公開キーを用いて、ＲＣＳＥと認証するために使用され得、その逆も同様である。代替として、ＲＣＳＥおよびＡＥは、ディフィ・ヘルマンプロセスを用いて、セキュアな接続を使用し得る。

ステップ１では、固有のホップ毎の（ＨｂＨ）証明書が、ＲＣＳＥによって、導出され、ＡＥ１にプロビジョニングされるか、または、キーイング材料が、ＣＳＥによって、ホップ毎の証明書がプロビジョニングされるためにＡＥ１に提供される。ＡＥ１およびＲＣＳＥのみが、新たにプロビジョニングされた証明書を共有する。ＡＥによって提供されるサービスのタイプに基づいて、適切な証明書が、証明書とともに使用され得る適切なコンテキストおよびパラメータとともに、（第５．１節で議論される基準に基づいて）ＡＥにプロビジョニングされ得る。このステップ中、エンティティ（ＲＣＳＥならびにＡＥ１）の両方によって容認可能である証明書を生成または導出するために、ネゴシエーションプロセスがあり、したがって、２つのエンティティが選択された証明書に合意するまで、ＲＣＳＥとＡＥ１との間でいずれの方向にも進む、２つ以上のメッセージを伴い得る可能性があり得る。ＲＣＳＥは、ＡＥ１によって提供される（デバイス、セキュリティ能力に基づいて導出される）要件に基づいて、この段階でＥ２Ｅ証明書をプロビジョニングすることも可能であり得る。代替として、Ｅ２Ｅ公開キー証明書は、ＳＣＲＰ段階でプロビジョニングされ得るか、または代替として、Ｅ２Ｅ公開キー証明書は、ステップ３でプロビジョニングされ得る。

ステップ２では、ＡＥ１およびＲＣＳＥは、ＨｂＨ証明書を使用して、セキュアなＤＴＬＳトンネルを作成する。

ステップ３では、ＡＥ１は、セキュアなトンネルを使用して、登録プロセスを行う。

代替として、ＳＥＳＣプロセスは、ＴＴＰ（例えば、ＴＥＦ、ＭＥＦ、ＭＡＦ）によって実施され、ホップ毎の証明書のプロビジョニングは、ＴＴＰによってＡＥおよびレジストラＣＳＥにプロビジョニングされる。加えて、ＳＥＦは、セキュリティ特徴の正しい組を決定することにおいて、デバイス能力（例えば、バッテリ、計算、およびメモリ）を考慮し得る。ＴＴＰが、ＣＲをホストし得るＴＴＰによって、Ｅ２Ｅ公開キー証明書をＡＥにプロビジョニングすることも可能であり得る。

図１６は、ホップ毎の証明書が信頼される第三者（ＴＴＰ）によってプロビジョニングされる、例を図示する。ステップ０では、ＲＣＳＥは、ＲＣＳＥとＴＴＰとの間の事前プロビジョニングされた証明書を使用して、ＴＴＰと認証する。ステップ１では、ＡＥ１は、ＡＥ１とＴＴＰとの間の事前プロビジョニングされた証明書に基づいて、ＴＴＰと認証する。

ステップ２では、ＴＴＰは、両方のエンティティへのセキュアな接続を使用して、ＲＣＳＥとＡＥ１との間で共有されるべきホップ毎の証明書をプロビジョニングする。証明書は、ＲＣＳＥとＴＴＰとの間の認証、ならびにＡＥ１とＴＴＰとの間の認証に基づいて導出された証明書に基づいて、ブートストラップされている場合がある。そして、例えば、固有のホップ毎の（ＨｂＨ）証明書が、導出され、ＴＴＰによってＡＥ１に、ならびにＲＣＳＥにプロビジョニングされ得る。ＡＥ１およびＲＣＳＥのみが、新たにプロビジョニングされた証明書を共有する。ＡＥによって提供されるサービスのタイプに基づいて（第５．１節で議論される基準に基づいて）、適切な証明書が、証明書とともに使用され得る適切なコンテキストおよびパラメータとともに、ＡＥ１ならびにＲＣＳＥにプロビジョニングされ得る。ＲＣＳＥは、ＡＥ１によって提供される要件に基づいて、この段階でＥ２Ｅ証明書をプロビジョニングすることも可能であり得る。代替として、Ｅ２Ｅ公開キー証明書は、ＳＣＲＰ段階でプロビジョニングされ得る。

ステップ３では、ＡＥ１およびＲＣＳＥは、ＨｂＨ証明書を使用して、セキュアな（Ｄ）ＴＬＳトンネルを作成する。ステップ４では、ＡＥ１は、セキュアなトンネルを使用して、登録プロセスを行う。

図１７は、プロビジョニングされたＨｂＨ証明書に基づいて＜ＡＥ＞リソース構造に追加されたリソースタイプ「ｓｅｃｕｒｉｔｙＰａｒａｍｔｅｒｓ」を伴う、高レベル＜ＡＥ＞リソース構造を描写する。セキュリティパラメータが使用され得るコンテキストに適用可能である、＜ＡＥ＞リソースに関連付けられる、０−Ｎ個のそのような「ｓｅｃｕｒｉｔｙＰａｒａｍｔｅｒｓ」があり得る。

図１８は、ＨｂＨ証明書がプロビジョニングされた後のＡＥリソースを描写する。ＨｂＨ証明書は、ｃｒｅｄｅｎｔｉａｌＣｈａｒａｃｔｅｒｉｓｔｉｃｓとともに、ｃｒｅｄｅｎｔｉａｌＩＤ属性によって識別され、ｃｒｅｄｅｎｔｉａｌＣｈａｒａｃｔｅｒｉｓｔｉｃｓは、証明書のタイプ（例えば、公開キーまたはＰＳＫ ＨｂＨ）、証明書とともに使用されるアルゴリズム、署名または暗号化用であるスコープ、証明書特有のパラメータ（例えば、キー、公開キーパラメータ）、および使用された、または使用されるであろうノンス／乱数値、時間成分、使用されることが予期されるメタデータ情報等のような成分を有し得る、ｍｉｓｃｅｌｌａｎｅｏｕｓＰａｒａｍｓを記述するために使用され得る。

（セキュリティ証明書請求／登録プロセス（ＳＣＲＰ））
ＳＣＲＰプロセスは、主にエンドツーエンド認証のための公開キー証明書の請求および／または登録に集中されている。ここで説明されるＳＣＲＰプロセスは、主にＡＥのＥ２Ｅ証明書に対して焦点を当てる。しかしながら、類似プロセスが、ＴＴＰまたはＣＳＥのＲＣＳＥとＳＣＲＰを行うＣＳＥのために、ＳＣＲＰを行うために使用され得る。

図１９は、証明書レジストリ（ＣＲ）からＥ２Ｅ公開キー証明書を要求するＡＥの例を図示する。ステップ０では、ＣＲは、ｏｎｅＭ２Ｍサービス層を使用して、証明書プロビジョニングサービスを提供し得る。ＣＲは、そのサービスをＣＳＥにアナウンス＜Ａｎｎｃ＞し得る。ＲＣＳＥはまた、随意に、サービスにサブスクライブし得る。ＣＲは、随意に、ＲＣＳＥにおいてリソースを作成し得るが、リソースは、完全なＣＲ機能性ではなく、ＣＲおよび到達可能性（リンク）についての情報のみをＣＲ（ＣＳＥ）に提供し得る。

ステップ１では、ＡＥ１は、レジストラＣＳＥ（ＲＣＳＥ）とともにＨｂＨ証明書を使用して（Ｄ）ＴＬＳ接続を確立する。既存の（Ｄ）ＴＬＳ接続が存在する場合、新しい接続は、確立されない。

ステップ２では、ＡＥ１は、まだ存在していない場合、ＲＣＳＥにおいて＜ＡＥ＞リソースを作成する。ＡＥ１は、Ｅ２Ｅ証明書がプロビジョニングされると、ある時点でリソースが更新されることを予期する。

ステップ３では、ＡＥ１は、ＲＣＳＥにクエリを行うことによって、ＣＲによって提供されるサービスを発見し、ＣＲによって提供される到達可能性およびサービスに関する情報を取得する。

ステップ４では、ＡＥ１は、ＣＲリソース要求を用いて、ＣＲとのリソースの作成にサブスクライブする。これは、ＡＥ１のために調整された子リソースであり得、ＣＲは、ＳＣＲＰプロセスを要求した各ＡＥに関連付けられる複数の子リソースを維持し得る。ＣＲは、証明書を登録／請求するためにＡＥ１によって使用されるべきセキュリティパラメータのリストを提供する。

ステップ５では、ＡＥ１は、その公開キーを用いてリソースを更新する。メッセージは、随意に、ＡＥ１の秘密キーを使用して署名され得る。

ステップ６では、ＣＲは、随意に、存在する場合に署名を検証し得、全ての要求されたチェックを検証した後、デジタル認証書を発行し得る。ＣＲは、認証書が作成されたとき、ＡＥ１に通知し、それをＡＥ１にプロビジョニングし得る。

ステップ７では、ＡＥ１は、プロビジョニングされた証明書およびパラメータを用いてＲＣＳＥ上のそのリソースを更新し得る。随意に、ＲＣＳＥは、ステップ５でＲＣＳＥ上のＡＥ１のリソースを更新し得る。

ＡＥ１リソースが、ＲＣＳＥにおいてセキュリティパラメータを用いて更新されると、リソースは、図２０で描写される形態を成し得る。

代替として、ＣＲ機能性は、ＲＣＳＥまたはＨＣＳＥにおいてホストされ得る。ＡＥは、図２１に図示されるように、認証書を要求すること、または公開キー証明書をＲＣＳＥに登録することを要求することが可能であり得る。

図２１のステップ１では、ＡＥ１は、ＲＣＳＥとともにＨｂＨ証明書を使用してＤＴＬＳ接続を確立する。既存のＤＴＬＳ接続が存在する場合、新しい接続は確立されない。

ステップ２では、ＲＣＳＥは、ＣＲ機能性を実装する証明書プロビジョニングサービスを提供し得る。ＲＣＳＥは、そのサービスを他のＣＳＥにアナウンス＜Ａｎｎｃ＞し得る。証明書請求サービスを要求するＡＥは、ＲＣＳＥによってホストされるサービスを発見し得る。ＡＥ１は、ＲＣＳＥがＣＲサービスを提供することを発見する。

ステップ３では、ＡＥ１は、ＣＲとのリソースの作成を要求する。これは、ＡＥ１のために調整された子リソースであり得、ＣＲは、ＳＣＲＰプロセスを要求した各ＡＥに関連付けられる複数の子リソースを維持し得る。ＣＲは、証明書を登録／請求するためにＡＥ１によって使用されるセキュリティパラメータのリストを提供する。

ステップ４では、ＡＥ１は、その公開キーを用いてリソースを更新する。メッセージは、随意に、ＡＥ１の秘密キーを使用して署名され得る。

ステップ５では、ＣＲは、署名を検証し得（これは随意であり得る）、全ての要求されたチェックを検証した後、デジタル認証書を発行し得る。ＣＲは、認証書が作成されたとき、ＡＥ１に通知し、それをＡＥ１にプロビジョニングし得る。

（第三者証明書請求プロセス）
証明書は、暗示的様式で、または明示的に配布もしくはプロビジョニングされ得る。証明書は、リソースを伴う読み出しプロセスの結果として、暗示的に配布され得、証明書は、リソースの属性である。明示的プロセスでは、証明書は、ＲＣＳＥにおいてホストされるリソースの属性として利用可能ではないこともあるが、証明書は、（サービスプロバイダの一部であり得る）別のＴＴＰサーバ上でホストされ得、それを取得することを希望するＡＥは、証明書の明示的要求を行う必要があろう。

図２２は、第三者への証明書の暗示的配布を描写する。

ステップ０では、ＡＥ１は、そのＲＣＳＥ１にリソースの作成を要求する。要求に基づいて、ＲＣＳＥ１は、リソースを作成する。要求およびＳＥＳＣプロセス中に行われる分析に基づいて、適切なＥ２Ｅ証明書がプロビジョニングされ得る。

ステップ１では、ＲＣＳＥ１は、ＣＳＥ（ＲＣＳＥ１およびＲＣＳＥ２）によって共有されるＨｂＨ証明書を使用して、ＲＣＳＥ２とのＤＴＬＳ接続を設定する。

ステップ２では、ＲＣＳＥ１は、ＡＥ１リソースの可用性をＲＣＳＥ２にアナウンスする。

ステップ３では、ＡＥ２は、ＡＥ２とＲＣＳＥ２との間で共有されるＨｂＨ証明書を使用して、ＲＣＳＥ２とセキュアなＤＴＬＳ接続を設定する。

ステップ４では、ＡＥ２は、リソース発見動作を行い、アナウンスされたリソースＡＥ１についての情報を取得する。

ステップ５では、ＡＥ２は、ＡＥ１のＥ２Ｅ証明書に関連付けられるＡＥ１子リソースを読み出すことを要求する。

ステップ６では、関連アクセス制御チェックを行った後（チェックは、ＲＣＳＥ２またはＲＣＳＥ１によって実施され得る）、ＡＥ２は、ＡＥ１のＥ２Ｅ証明書をプロビジョニングされる。

（エンドツーエンド認証プロセス）
Ｅ２Ｅ認証プロセスは、直接モードで、または委託モードを介して、行われ得る。直接モードでは、メッセージのソースおよびシンクであり得る、２つのエンドエンティティは、それら自身でＥ２Ｅ認証を行ない得る。エンティティのいずれかへのリソース制約は、ある公開キー動作が、よりリソースが豊富なエンティティ上で行われることを要求し得る。よって、スプリンクラシステムを制御するアクチュエータの場合、Ｅ２Ｅ認証は、アクチュエータ（ＡＥ）自体の上で認証を行う代わりに、アクチュエータが実際に登録されているＲＣＳＥ等のエンティティによって行われ得る。したがって、第三者証明書請求は、ＡＥではなくＲＣＳＥによって行われる必要があろう。メッセージが委託モードまたは直接モードを使用して認証され得ることを示す、リソースに関連付けられる属性が、ＲＣＳＥにおいて示され得る。

図２３は、センサＡＥ１、ＡＥ２、およびＡＥ３が、規則的または不規則的間隔でセンサメッセージを生成し、それらのＲＣＳＥ１によってホストされるそれらのそれぞれのリソースを更新するシナリオを図示する。これらのセンサは、類似動作を行う場合もあり、行わない場合もあり、異なるＲＣＳＥによってホストされるように想定されることができる。簡単にするために、全てのＡＥが同一のＲＣＳＥ１に登録されることが描写されている。ＡＥ１、ＡＥ２、およびＡＥ３の「ｓｕｂｓｃｒｉｂｅｄ−ｔｏ」リソースをサブスクライブしているＡＥ４は、サブスクリプション承認プロシージャまたはＴＰＣＲ段階中にそれらのそれぞれのＥ２Ｅ公開キー証明書を事前プロビジョニングされていることもあるか、または明示的にプロビジョニングされていることもある。

ＡＥ１は、動作を示すメッセージ（例えば、リソースを更新する要求）を送信し、メッセージは、その秘密キーを使用して、ＡＥ１によってデジタルで署名されている。そのリソースに関連付けられる、適切なメタデータおよびセキュリティパラメータが使用されなければならない。簡単にするために、ＤＳが、ここでは、Ｅ２Ｅ認証に使用されるデジタル署名を表す一方で、Ｈ１、Ｈ２・・・は、ホップ毎のセキュリティアソシエーションに関連付けられるデジタル署名またはＭＡＣのいずれかを表す。デジタル署名ＤＳ１と、随意に、ＡＥ１とＲＣＳＥ１との間で関連付けられるＨｂＨ証明書に関連付けられるＭＡＣまたはＤＳであり得るＨ１とが、（Ｄ）ＴＬＳメッセージの一部として送信され得る。Ｈ１は、ＲＣＳＥがＡＥ１を認証するためにＤＳ１を使用することが可能であり得るので、随意であり、したがって、Ｈ１は、冗長であり得る。しかしながら、Ｈ１が対称キーに基づき、ＲＣＳＥ１がそれ自身で公開キー証明書検証を行うことを欲しない場合、Ｈ１も含まれ得る。ＲＣＳＥ１は、メッセージをＩＮ−ＣＳＥに転送し、メタデータＤＳ１およびＨ４を含め、Ｈ４は、ＩＮ−ＣＳＥによってＲＣＳＥ１を認証するために使用され、ＲＣＳＥ１およびＩＮ−ＣＳＥに関連付けられるＨｂＨ証明書に基づく、ＤＳまたはＭＡＣであり得る。随意に、使用されるメタデータは、メッセージ全体が使用され得ることであり得るか、または使用されるメタデータは、認証に使用される、関連付けられるデータであり得るかのいずれかであり得る。同様に、ＩＮ−ＣＳＥは、（元のメタデータＤＳ１を含む）メッセージおよびＨ７をＲＣＳＥ２に転送する。ＲＣＳＥ２が暫定メッセージ発信側ＩＮ−ＣＳＥを認証すると、ＲＣＳＥ２は、メッセージ、メタデータＤＳ１およびＨ１０を含む通知をＡＥ４に送信する。ＡＥ４は、Ｈ１０を検証することによってＲＣＳＥ２を認証し、次いで、メタデータまたはメッセージ全体を処理し始め、セキュリティパラメータ、ならびにＡＥ１を認証する際に使用されるアルゴリズム、証明書等を決定するために、サブスクリプションプロセス中に取得された情報を使用する。ＡＥ４は、ＤＳ１を検証するためにＡＥ１の公開キーを使用し、成功した場合、ＡＥ１によって更新されている場合があるコンテンツは、ＡＥ４によって使用され、そうでなければ、メッセージは拒否される。同様に、ＡＥ４は、ＤＳ２を検証するためにＡＥ２の公開キーを使用して、ＡＥ２からのメッセージを認証し、ＤＳ３を検証するためにＡＥ３の公開キーを使用して、ＡＥ３からのメッセージを検証する。

メッセージがＲＣＳＥ２またはＡＥ４に到達する前に、権限を与えられ得るＲＣＳＥ１、ＩＮ−ＣＳＥ、または任意の他の中間エンティティが、ＡＥ１（ＤＳ１）を認証することが可能であり得る。公開キー証明書が、概して、承認を要求することなく、公的に取得可能であるので、ポリシが、そのような認証が起こることを可能にするならば、任意のエンティティが、メッセージを認証することが可能であり得、要するに、中間エンティティは、そのような認証を行う権限を与えられる必要があり得る。したがって、ＲＣＳＥ１またはＩＮ−ＣＳＥが、ＡＥ１からのＤＳ１が認証に失敗したことを決定する場合、ＲＣＳＥ１／ＩＮ−ＣＳＥは、ＲＣＳＥ１／ＩＮ−ＣＳＥの動作を統制するポリシに基づいて、メッセージを破棄し得る。代替として、メッセージは、転送され得るが、しかしながら、メッセージが認証に失敗したことを示すフラグが、ＲＣＳＥ１／ＩＮ−ＣＳＥによってメッセージに追加され、次いで、ＲＣＳＥ２／ＡＥ４に転送され得る。フラグが、メッセージが認証に失敗したことを示すので、ＲＣＳＥ２および／またはＡＥ４は、随意に、ＤＳを処理することを省略し得る。

図２４は、ＲＣＳＥ１が、ＡＥ１、ＡＥ２、およびＡＥ３の代わりに、ＡＥ４によって認証されるであろうエンティティとしの役割りを果たすシナリオを描写する。ＡＥ１、ＡＥ２、およびＡＥ３のためにＲＣＳＥ１において登録されるリソースは、これらのリソースが委託モードで動作しており、ＲＣＳＥ１に関連付けられる情報およびセキュリティパラメータが、第三者段階への証明書配布中に含まれ得ることを示し得る。したがって、ＡＥ１から生じるメッセージを認証することを欲する、任意のエンティティは、ＡＥ１が委託モードで動作しており、ＡＥ１から生じるメッセージの真正性に責任があるエンティティが、ＲＣＳＥ１に委託またはオフロードされていることを認識しなければならない。したがって、認証エンティティ（例えば、ＡＥ４）は、ＲＣＳＥ１の関連公開キー証明書およびセキュリティパラメータをプロビジョニングされなければならない。

ＡＥ１は、ＡＥ１とＲＣＳＥ１との共有セキュリティアソシエーションを使用して保護され得るメッセージをＲＣＳＥ１に送信し、メッセージは、ＨｂＨセキュリティのためにＡＥ１とＲＣＳＥ１との間で関連付けられるＭＡＣまたはＤＳであり得る、Ｈ１を含み得る。ＲＣＳＥ１がＨ１を使用してＡＥ１を認証すると、ＲＣＳＥは、メッセージのデジタル署名を（メッセージ全体またはメッセージのメタデータのいずれかを使用して）作成し、デジタル署名は、ＡＥ１からの元のメッセージからの随意のメタデータ、ならびにそのメッセージの随意のメタデータを含み得、適切なセキュリティパラメータとともに、その秘密キーを使用し、メッセージをＩＮ−ＣＳＥに転送する。ＩＮ−ＣＳＥは、前述のような類似プロセスに従い、Ｈ７を検証し、メッセージをＡＥ４に転送する。ＡＥ４は、サブスクリプションプロセス中に取得される情報に基づいて、メッセージがＡＥ１において生じているが、ＲＣＳＥ１によって署名されていることもあることを認識する。ＡＥ４は、メッセージを認証するために、ＡＥ１からの随意のメタデータまたはメッセージ全体、およびＲＣＳＥ１の公開キーならびに要求されたセキュリティパラメータを使用し得る。ＡＥ４は、ＡＥ１を認証するために、ＲＣＳＥ１によって作成されるメッセージからのメタデータまたはメッセージ全体らのメタデータを使用すること、または、随意に、代理によってＡＥ１を認証するために、ＡＥ１ならびにＲＣＳＥ１の両方からのメタデータを含むことが可能であり得る。

図２５は、直接モードを使用するアクチュエータによるシステムまたはアプリケーションのＥ２Ｅ認証の例を図示する。ＡＥは、アプリケーション（ＡＥ４）の公開キー証明書を用いて事前プロビジョニングされていると仮定される。アプリケーションからのアクションメッセージは、アクション（例えば、水または任意の他の化合物を噴霧すること）を開始するアクチュエータ（例えば、スプリンクラシステム）のためであり得る。アクションメッセージは、アクチュエータに関連付けられるリソースに関連付けられる更新メッセージ、またはアプリケーションに関連付けられるリソースの変更の通知の組み合わせであり得る。どのようにしてアクションが開始されるかにかかわらず、アクションを開始させるためのメッセージが実際にシステム／アプリケーション（ＡＥ４）から生じたかどうかという検証が、認証され得る。

ＡＥ４は、その秘密キーならびに関連付けられるセキュリティパラメータを使用して、メッセージのデジタル署名（例えば、ＡＥ１へのメッセージに使用されるＤＳ１）を作成する。メッセージは、セキュアなＤＴＬＳトンネルを使用してＲＣＳＥ２に転送され、メッセージは、随意に、ＨｂＨ証明書に関連付けられるＭＡＣ（Ｈ１）を含み得る。ＲＣＳＥ２は、Ｈ１を認証し（随意）、代わりに、ＤＳ１を認証し得、メッセージをＩＮ−ＣＳＥに転送する。ＩＮ−ＣＳＥは、Ｈ４を検証することによってＲＣＳＥ２を認証し、メッセージをＲＣＳＥ１に転送する。ＲＣＳＥ１は、Ｈ７を認証し、メッセージをＡＥ１に転送する。ＡＥ１は、ポリシおよび関連付けられるサブスクリプション情報に基づいて、それは、含まれている場合があるメッセージのメタデータを使用することによって、または、コンテキストおよびセキュリティパラメータに基づくメッセージ全体、ならびにサブスクリプションもしくはＴＰＣＲ中に事前プロビジョニングされている場合があるＡＥ４の公開キーに基づいてＡＥ４のＥ２Ｅ認証を行う。同様に、ＡＥ２およびＡＥ３は、明白に異なる署名を有する、それらのそれぞれのメッセージを検証するために、ＡＥ４の公開キーを使用する。

図２６は、認証の委託モードを描写し、デジタル署名は、ＡＥ１ならびにＡＥ２およびＡＥ３の代わりにＲＣＳＥ１によって、検証され、認証される。ＡＥ４の公開キーは、ＲＣＳＥ１がＤＳ１、ＤＳ２、およびＤＳ３を検証するために、セキュリティパラメータとともに使用される。

（例示的実施形態）
本節は、ｏｎｅＭ２Ｍ仕様に基づく詳細な実施形態を説明し、関連付けられる説明図が、図２７で描写されている。ＨｂＨセキュリティ保護（例えば、（Ｄ）ＴＬＳ）が、２つの通信エンティティの間で使用されることがデフォルトで仮定される。ＡＥと別のＡＥとの間のホップの数が複数であり得、したがって、複数のＭＮ−ＣＳＥ／ＩＮ−ＣＳＥを用いて、複数の信頼されるドメインをホップし得る場合もある。委託モードならびに非委託Ｅ２Ｅモードの実施形態のメッセージング詳細：
ステップ１では、ＡＥ１は、ＲＣＳＥ１においてリソースを作成することを要求する。適切なチェックに基づいて、ＲＣＳＥ１は、ＲＣＳＥ１に関連付けられるリソースを登録し,
ホストする。

ステップ２では、ＡＥ２は、ＡＥ１リソースにサブスクライブすることを要求し得る。ＲＣＳＥ１またはサービスプロバイダにおけるポリシに基づいて、ＡＥ２は、その公開キー証明書を使用して認証されることを要求され得る。メッセージにサブスクライブするための要求の一部として、ＡＥ２は、その秘密キーを使用することによって作成され得るメッセージのデジタル署名、随意のメタデータまたはメッセージ全体、およびＥ２Ｅ認証のために定義されるスコープに基づく関連付けられるパラメータを含む。

メッセージメタデータ（Ｍ１）を構成するパラメータまたは属性は、メッセージ全体の代わりにメタデータが使用されている場合、ＡＥ２によって作成され、使用される。これらは、少なくとも以下のパラメータまたはそれらの均等物を含む。
ｆｒ＝ＡＥ２−ＩＤ；
ｔｏ＝ＲＣＳＥ１−ＩＤ；
ｒｅｓ−ｉｄ＝ｒｅｓｏｕｒｃｅ−ＩＤ１；
ｏｐ＝“Ｓｕｂｓｃｒｉｐｔｉｏｎ”；
ｓｅｓｓｉｏｎｉｄ＝ＲａｎｄｏｍＶａｌｕｅ１（随意に、時間成分も）
他のパラメータも、メッセージメタデータの一部として含まれ得る。中間ホップがメッセージを修正しないいくつかの場合において、メッセージメタデータは、完全に回避され得るか、またはパラメータもしくはヘッダ情報の一部のみが含まれ得るか、または、メッセージ全体が、ＤＳの作成で使用される。例示的ＤＳ作成プロセスでは：
Ｍ１＝（ＡＥ１−ＩＤ｜｜ＲＣＥＳ１−ＩＤ｜｜ｒｅｓｏｕｒｃｅ−ＩＤ１｜｜“Ｓｕｂｓｃｒｉｐｔｉｏｎ”｜｜ＲａｎｄｏｍＶａｌｕｅ１）；
Ｈａｓｈ＿Ｍｅｔａ＿Ｄａｔａ（Ｈ１）＝Ｈａｓｈ＿Ａｌｇｏｒｉｔｈｍ（Ｍ１）；および
ＤＳ１＝Ｐｕｂｌｉｃ＿Ｋｅｙ＿Ｅｎｃｒｙｐｔｉｏｎ＿Ａｌｇｏｒｉｔｈｍ（Ｈ１，ＡＥ１−ＰｒｉｖａｔｅＫｅｙ）
である。

代替として、メッセージ全体が、ＤＳを生成するために使用され得る。

ステップ３では、ＲＣＳＥ１におけるポリシに基づいて、ＲＣＳＥ１は、「サブスクリプション」メッセージのＥ２Ｅ認証が行われる必要があろうことを認識する。公開キーをまだプロビジョニングされていない場合、ＲＣＳＥ１は、随意のメタデータを処理し、ＡＥ２の公開キーを取得し、そして、証明書に関連付けられるスコープに基づいて、ＲＣＳＥ１は、メタデータが使用されている場合、以下の様式でＤＳ１を処理する：メッセージ全体がＤＳを生成するために使用されている場合、類似機構が使用され得る。メッセージ全体がＤＳを作成するために使用されているとき、Ｄ−Ｈ１、Ｍ１、およびＣ−Ｈ１の計算は、メッセージ全体のＤＳの解読と置換され得る。
Ｄｅｃｒｙｐｔｅｄ＿Ｈ１（Ｄ−Ｈ１）＝Ｐｕｂｌｉｃ＿Ｋｅｙ＿Ｅｎｃｒｙｔｉｏｎ＿Ａｌｇｏｒｉｔｈｍ（ＤＳ，ＡＥ１−ＰｕｂｌｉｃＫｅｙ）および
Ｃｏｍｐｕｔｅｄ＿Ｈａｓｈ＿Ｍｅｔａ＿Ｄａｔａ（Ｃ−Ｈ１）＝Ｈａｓｈ＿Ａｌｇｏｒｉｔｈｍ（Ｍ１）
Ｄ−Ｈ１＝＝Ｃ−Ｈ１である場合、メッセージ発信側およびメッセージが認証される。

ステップ４では、ＲＣＳＥ１は、「通知」メッセージを作成し、適切なメッセージおよび随意のメタデータ（Ｍ２）ならびに関連付けられるデジタル署名（ＤＳ２）を含み、ＡＥ２宛のメッセージを転送する。前述の機構を使用して、Ｍ２が作成され得、ＤＳ２が以下のように計算され得る。
ｆｒ＝ＲＣＳＥ１−ＩＤ；
ｔｏ＝ＡＥ２−ＩＤ；
ｒｅｓ−ｉｄ＝ｒｅｓｏｕｒｃｅ−ＩＤ１；
ｏｐ＝“Ｎｏｔｉｆｉｃａｔｉｏｎ”；
ｓｅｓｓｉｏｎｉｄ＝ＲａｎｄｏｍＶａｌｕｅ２；
Ｍ２＝（ＲＣＥＳ１−ＩＤ｜｜ＡＥ１−ＩＤ｜｜ｒｅｓｏｕｒｃｅ−ＩＤ１｜｜“Ｎｏｔｉｆｉｃａｔｉｏｎ”｜｜ＲａｎｄｏｍＶａｌｕｅ２）；
Ｈａｓｈ＿Ｍｅｔａ＿Ｄａｔａ（Ｈ２）＝Ｈａｓｈ＿Ａｌｇｏｒｉｔｈｍ（Ｍ２）；および
ＤＳ２＝Ｐｕｂｌｉｃ＿Ｋｅｙ＿Ｅｎｃｒｙｐｔｉｏｎ＿Ａｌｇｏｒｉｔｈｍ（Ｈ２，ＲＣＳＥ１−ＰｒｉｖａｔｅＫｅｙ）
メッセージ全体がＤＳ２の作成に使用される場合において、Ｈａｓｈ＿Ｍｅｔａ＿Ｄａｔａ、すなわち、Ｈ２が、メッセージ全体のハッシュと置換される。

ステップ５では、前述の類似機構を使用して、ＡＥ２は、メタデータがＤＳ２を作成するために使用された場合、メッセージメタデータ（Ｍ２）、ＲＣＳＥ１の公開キーを使用し、スコープ情報に基づいて、ＤＳ２を検証する。ＡＥ２がＤＳ２を検証することができず、したがって、ＲＣＳＥ１を認証することができない場合、「Ｎｏｔｉｆｙ」メッセージは、破棄され得る。

両方のエンドエンティティが、真のＥ２Ｅ様式で互いから生じるメッセージを認証することができる別の実施形態が、図２８で描写されている。しかしながら、ここでは、図２７で描写されるコールフローと同様に、ＡＥ２は、ＲＣＳＥ１から通知メッセージをトリガしていることもあるＡＥ１からの元のメッセージを認証することを欲する。

図２８のステップ１では、ＡＥ２は、ＲＣＳＥ１においてホストされるリソースにサブスクライブする。ＡＥ２は、メッセージメタデータ（Ｍ１）、ならびにＡＥ２の秘密キー、Ｍ１を使用し、暗号化動作の使用のために定義されるスコープに基づいて計算される関連付けられるＤＳ１を提供する。

ステップ２では、ＲＣＳＥ１は、Ｍ１とともにＡＥ２の公開キーを使用することによって、定義されたスコープに基づいて、ＡＥ２によって送信されるＤＳ１を検証する。

ステップ３では、ＡＥ１は、ＲＣＳＥ１上でホストされるリソースへの更新動作を行い得る。更新動作を行うメッセージングは、メッセージメタデータ（Ｍ２）またはメッセージ全体に基づいてデジタル署名を作成し、それをＡＥ１の秘密キーで署名することによって、認証され得る。ＡＥ１は、ＤＳを作成するために、以下のプロシージャを使用し得る。
ｆｒ＝ＡＥ１−ＩＤ；
ｔｏ＝ＲＣＳＥ１−ＩＤ；
ｒｅｓ−ｉｄ＝ｒｅｓｏｕｒｃｅ−ＩＤ１；
ｏｐ＝“Ｕｐｄａｔｅ”；
ｓｅｓｓｉｏｎｉｄ＝ＲａｎｄｏｍＶａｌｕｅ２；
Ｍ２＝（ＡＥ１−ＩＤ｜｜ＲＣＳＥ１−ＩＤ｜｜ｒｅｓｏｕｒｃｅ−ＩＤ１｜｜“Ｕｐｄａｔｅ”｜｜ＲａｎｄｏｍＶａｌｕｅ２）；
Ｈａｓｈ＿Ｍｅｔａ＿Ｄａｔａ（Ｈ２）＝Ｈａｓｈ＿Ａｌｇｏｒｉｔｈｍ（Ｍ２）；
ＤＳ２＝Ｐｕｂｌｉｃ＿Ｋｅｙ＿Ｅｎｃｒｙｐｔｉｏｎ＿Ａｌｇｏｒｉｔｈｍ（Ｈ２，ＲＣＳＥ１−ＰｒｉｖａｔｅＫｅｙ）；
ＡＥ１は、Ｍ２および対応するＤＳ２とともに、更新メッセージをＲＣＳＥ１に送信する。メッセージ全体が、ＤＳ２を生成するために使用される場合において、Ｍ２、Ｈ２の計算が省略され、メッセージ全体がＨ２の代わりにＤＳ２の生成に使用される。

ステップ４では、ＲＣＳＥ１は、随意に、Ｍ２とともにＡＥ１の公開キーを使用して、スコープパラメータに基づいて、メッセージを認証し得る。メッセージが認証されることができない場合、更新メッセージは、破棄され得る。ＤＳが検証された場合、ＲＣＳＥ１は、随意に、それが作成する通知メッセージのためのメッセージメタデータ（Ｍ３）を作成し、ＲＣＳＥ１の秘密キーを使用して、それをデジタルで署名し、ＤＳ３を作成し得る。ＲＣＳＥ１は、随意に、通知メッセージの一部として、Ｍ２／ＤＳ２ならびにＭ３／ＤＳ３の両方を送信し得る。

ステップ５では、ＡＥ２は、ＤＳ３を認証して検証するために、ＲＣＳＥ１の公開キーを使用し、それによって、通知メッセージを認証し、ＤＳ２を検証するために、ＡＥ１の公開キーを使用し、それによって、初期更新メッセージがＡＥ１によって実際に送信されたことを認証し得る。

本明細書に説明される種々の技法は、ハードウェア、ファームウェア、ソフトウェア、もしくは適切である場合、それらの組み合わせに関連して実装され得る。そのようなハードウェア、ファームウェア、およびソフトウェアは、通信ネットワークの種々のノードに位置する装置の中に常駐し得る。装置は、本明細書に説明される方法をもたらすように、単独で、または互いに組み合わせて動作し得る。本明細書で使用されるように、「装置」、「ネットワーク装置」、「ノード」、「デバイス」、および「ネットワークノード」という用語は、同義的に使用され得る。

図２９は、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノード、ならびにＩｏＴ／ＷｏＴサービス層等であり得る。図３−９、１１−１３、１５、１６、１８、１９、および２１−２８のうちのいずれかに図示されるクライアント、プロキシ、またはサーバデバイスのうちのいずれかは、図２、４、および１４に図示されるもの等の通信システムのノードを備え得る。

図２９に示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、通信ネットワーク１２を含む。通信ネットワーク１２は、固定ネットワーク（例えば、Ｅｔｈｅｒｎｅｔ（登録商標）、Ｆｉｂｅｒ、ＩＳＤＮ、ＰＬＣ等）、または無線ネットワーク（例えば、ＷＬＡＮ、セルラー等）、もしくは異種ネットワークのネットワークであり得る。例えば、通信ネットワーク１２は、音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを複数のユーザに提供する、多重アクセスネットワークから成り得る。例えば、通信ネットワーク１２は、符号分割多重アクセス（ＣＤＭＡ）、時分割多重アクセス（ＴＤＭＡ）、周波数分割多重アクセス（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ−ＦＤＭＡ）等の１つ以上のチャネルアクセス方法を採用し得る。さらに、通信ネットワーク１２は、例えば、コアネットワーク、インターネット、センサネットワーク、工業制御ネットワーク、パーソナルエリアネットワーク、融合個人ネットワーク、衛星ネットワーク、ホームネットワーク、または企業ネットワーク等の他のネットワークを備え得る。

図２９に示されるように、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０は、インフラストラクチャドメインと、フィールドドメインとを含み得る。インフラストラクチャドメインは、エンドツーエンドＭ２Ｍ展開のネットワーク側を指し、フィールドドメインは、通常、Ｍ２Ｍゲートウェイの背後にある、エリアネットワークを指す。フィールドドメインおよびインフラストラクチャドメインは両方とも、ネットワークの種々の異なるノード（例えば、サーバ、ゲートウェイ、デバイス等）を備え得る。例えば、フィールドドメインは、Ｍ２Ｍゲートウェイ１４と、デバイス１８とを含み得る。任意の数のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８が、所望に応じて、Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム１０に含まれ得ることが理解されるであろう。Ｍ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８の各々は、通信回路を使用して、通信ネットワーク１２または直接無線リンクを介して、信号を伝送ならびに受信するように構成される。Ｍ２Ｍゲートウェイ１４は、無線Ｍ２Ｍデバイス（例えば、セルラーおよび非セルラー）ならびに固定ネットワークＭ２Ｍデバイス（例えば、ＰＬＣ）が、通信ネットワーク１２等のオペレータネットワークを通して、または直接無線リンクを通してのいずれかで、通信することを可能にする。例えば、Ｍ２Ｍデバイス１８は、データを収集し、通信ネットワーク１２または直接無線リンクを介して、データをＭ２Ｍアプリケーション２０もしくは他のＭ２Ｍデバイス１８に送信し得る。Ｍ２Ｍデバイス１８はまた、Ｍ２Ｍアプリケーション２０またはＭ２Ｍデバイス１８からデータを受信し得る。さらに、データおよび信号は、以下で説明されるように、Ｍ２Ｍサービス層２２を介して、Ｍ２Ｍアプリケーション２０に送信され、そこから受信され得る。Ｍ２Ｍデバイス１８およびゲートウェイ１４は、例えば、セルラー、ＷＬＡＮ、ＷＰＡＮ（例えば、Ｚｉｇｂｅｅ（登録商標）、６ＬｏＷＰＡＮ、Ｂｌｕｅｔｏｏｔｈ（登録商標））、直接無線リンク、および有線を含む、種々のネットワークを介して通信し得る。例示的Ｍ２Ｍデバイスは、タブレット、スマートフォン、医療デバイス、温度および気象モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、保健および健康モニタ、照明、サーモスタット、電化製品、ガレージドア、および他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図３０を参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイ１４、およびＭ２Ｍデバイス１８ならびに通信ネットワーク１２のためのサービスを提供する。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍデバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワークで、クラウドで等の種々の方法で実装され得る。

図示されるＭ２Ｍサービス層２２と同様に、インフラストラクチャドメイン内にＭ２Ｍサービス層２２’がある。Ｍ２Ｍサービス層２２’は、インフラストラクチャドメイン内のＭ２Ｍアプリケーション２０’および下層通信ネットワーク１２’のためのサービスを提供する。Ｍ２Ｍサービス層２２’はまた、フィールドドメイン内のＭ２Ｍゲートウェイデバイス１４およびＭ２Ｍデバイス１８のためのサービスも提供する。Ｍ２Ｍサービス層２２’は、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ、およびＭ２Ｍデバイスと通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２’は、異なるサービスプロバイダによってサービス層と相互作用し得る。Ｍ２Ｍサービス層２２’は、サーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウドコンピューティング／記憶ファーム等）等を備え得る、ネットワークの１つ以上のノードによって実装され得る。

図３０も参照すると、Ｍ２Ｍサービス層２２および２２’は、多様なアプリケーションおよびバーティカルが活用することができるサービス配信能力のコアの組を提供する。これらのサービス能力は、Ｍ２Ｍアプリケーション２０および２０’がデバイスと相互作用し、データ収集、データ分析、デバイス管理、セキュリティ、請求、サービス／デバイス発見等の機能を果たすことを可能にする。本質的に、これらのサービス能力は、これらの機能性を実装する負担をアプリケーションから取り除き、したがって、アプリケーション開発を単純化し、市場に出すコストおよび時間を削減する。サービス層２２および２２’はまた、Ｍ２Ｍアプリケーション２０および２０’が、サービス層２２および２２’が提供するサービスと関連して、種々のネットワーク１２および１２’を通して通信することも可能にする。

Ｍ２Ｍアプリケーション２０および２０’は、限定ではないが、輸送、保健および健康、コネクテッドホーム、エネルギー管理、アセット追跡、ならびにセキュリティおよび監視等の種々の業界での用途を含み得る。上記のように、システムのデバイス、ゲートウェイ、サーバ、および他のノードにわたって起動するＭ２Ｍサービス層は、例えば、データ収集、デバイス管理、セキュリティ、請求、場所追跡／ジオフェンシング、デバイス／サービス発見、およびレガシーシステム統合等の機能をサポートし、サービスとしてこれらの機能をＭ２Ｍアプリケーション２０および２０’に提供する。

概して、図２９ならびに３０に図示されるサービス層２２および２２’等のサービス層（ＳＬ）は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層を定義する。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍアーキテクチャは両方とも、サービス層を定義する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、ＥＴＳＩ Ｍ２Ｍアーキテクチャの種々の異なるノード内に実装され得る。例えば、サービス層のインスタンスは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内で実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上でホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。第３世代パートナーシッププロジェクト（３ＧＰＰ）はまた、マシンタイプ通信（ＭＴＣ）のためのアーキテクチャも定義している。そのアーキテクチャでは、サービス層、およびそれが提供するサービス能力は、サービス能力サーバ（ＳＣＳ）の一部として実装される。ＥＴＳＩ Ｍ２ＭアーキテクチャのＤＳＣＬ、ＧＳＣＬ、もしくはＮＳＣＬで、３ＧＰＰ ＭＴＣアーキテクチャのサービス能力サーバ（ＳＣＳ）で、ｏｎｅＭ２ＭアーキテクチャのＣＳＦもしくはＣＳＥで、またはネットワークのある他のノードで具現化されるかどうかにかかわらず、サービス層のインスタンスが、サーバ、コンピュータ、および他のコンピューティングデバイスもしくはノードを含むネットワーク内の１つ以上の独立型ノード上で、または１つ以上の既存のノードの一部としてのいずれかで実行する論理エンティティ（例えば、ソフトウェア、コンピュータ実行可能命令等）として実装され得る。例として、サービス層またはそのコンポーネントのインスタンスは、以下で説明される図３１または図３２に図示される一般アーキテクチャを有する、ネットワークノード（例えば、サーバ、コンピュータ、ゲートウェイ、デバイス等）上で起動するソフトウェアの形態で実装され得る。

さらに、本明細書に説明される方法および機能性は、サービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装され得る。

図３１は、図２９および３０に図示されるもの等のＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして動作し得る、図３−９、１１−１３、１５、１６、１８、１９、および２１−２８に図示されるクライアント、サーバ、またはプロキシのうちの１つ等のネットワークのノードの例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。図３１に示されるように、ノード３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。ノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるエンドツーエンド認証機能性の側面を実装する、ノードであり得る。

プロセッサ３２は、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、状態マシン等であり得る。一般に、プロセッサ３２は、ノードの種々の要求される機能を果たすために、ノードのメモリ（例えば、メモリ４４および／またはメモリ４６）内に記憶されたコンピュータ実行可能命令を実行し得る。例えば、プロセッサ３２は、信号符号化、データ処理、電力制御、入出力処理、および／またはノード３０が無線もしくは有線環境内で動作することを可能にする任意の他の機能性を果たし得る。プロセッサ３２は、アプリケーション層プログラム（例えば、ブラウザ）および／または無線アクセス層（ＲＡＮ）プログラムならびに／もしくは他の通信プログラムを起動し得る。プロセッサ３２はまた、例えば、アクセス層および／またはアプリケーション層等で、認証、セキュリティキー一致、ならびに／もしくは暗号化動作等のセキュリティ動作を行い得る。

図３１に示されるように、プロセッサ３２は、その通信回路（例えば、送受信機３４および伝送／受信要素３６）に結合される。プロセッサ３２は、コンピュータ実行可能命令の実行を通して、それが接続されるネットワークを介してノード３０に他のノードと通信させるために、通信回路を制御し得る。具体的には、プロセッサ３２は、（例えば、図３−９、１１−１３、１５、１６、１８、１９、および２１−２８で）本明細書ならびに請求項に説明される伝送および受信ステップを行うために、通信回路を制御し得る。図３１は、プロセッサ３２および送受信機３４を別個のコンポーネントとして描写するが、プロセッサ３２および送受信機３４は、電子パッケージまたはチップにともに統合され得ることが理解されるであろう。

伝送／受信要素３６は、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、他のノードに信号を伝送するように、またはそこから信号を受信するように構成され得る。例えば、実施形態では、伝送／受信要素３６は、ＲＦ信号を伝送および／または受信するように構成されるアンテナであり得る。伝送／受信要素３６は、ＷＬＡＮ、ＷＰＡＮ、セルラー等の種々のネットワークならびにエアインターフェースをサポートし得る。実施形態では、伝送／受信要素３６は、例えば、ＩＲ、ＵＶ、もしくは可視光信号を伝送および／または受信するように構成されるエミッタ／検出器であり得る。さらに別の実施形態では、伝送／受信要素３６は、ＲＦおよび光信号の両方を伝送ならびに受信するように構成され得る。伝送／受信要素３６は、無線もしくは有線信号の任意の組み合わせを伝送および／または受信するように構成され得ることが理解されるであろう。

加えて、伝送／受信要素３６は、単一の要素として図３１で描写されているが、ノード３０は、任意の数の伝送／受信要素３６を含み得る。より具体的には、ノード３０は、ＭＩＭＯ技術を採用し得る。したがって、実施形態では、ノード３０は、無線信号を伝送および受信するための２つ以上の伝送／受信要素３６（例えば、複数のアンテナ）を含み得る。

送受信機３４は、伝送／受信要素３６によって伝送される信号を変調するように、および伝送／受信要素３６によって受信される信号を復調するように構成され得る。上記のように、ノード３０は、マルチモード能力を有し得る。したがって、送受信機３４は、ノード３０が、例えば、ＵＴＲＡおよびＩＥＥＥ８０２．１１等の複数のＲＡＴを介して通信することを可能にするための複数の送受信機を含み得る。

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、上記で説明されるように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、サブスクライバ識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のノード３０上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映する、またはノードのセッション移行もしくは共有能力または設定についてユーザから入力を取得する、もしくは情報をユーザに表示するように構成され得る。別の例では、ディスプレイは、セッション状態に関する情報を示し得る。

プロセッサ３２は、電源４８から電力を受電し得、ノード３０内の他のコンポーネントへの電力を分配および／または制御するように構成され得る。電源４８は、ノード３０に給電するための任意の好適なデバイスであり得る。例えば、電源４８は、１つ以上の乾電池バッテリ（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉ−ｉｏｎ）等）、太陽電池、燃料電池等を含み得る。

プロセッサ３２はまた、ノード３０の現在の場所に関する場所情報（例えば、経度および緯度）を提供するように構成される、ＧＰＳチップセット５０に結合され得る。ノード３０は、実施形態と一致したままで、任意の好適な場所決定方法を介して場所情報を獲得し得ることが理解されるであろう。

プロセッサ３２はさらに、追加の特徴、機能性、および／または有線もしくは無線接続性を提供する、１つ以上のソフトウェアならびに／もしくはハードウェアモジュールを含み得る他の周辺機器５２に結合され得る。例えば、周辺機器５２は、加速度計、ｅ−コンパス、衛星送受信機、センサ、デジタルカメラ（写真またはビデオ用）、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動デバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ等を含み得る。

図３２は、図２９および３０に図示されるもの等のＭ２Ｍネットワーク内のＭ２Ｍサーバ、ゲートウェイ、デバイス、または他のノードとして動作し得る、図３−９、１１−１３、１５、１６、１８、１９、および２１−２８に図示されるクライアント、サーバ、もしくはプロキシ等のネットワークの１つ以上のノードを実装するためにも使用され得る、例示的コンピューティングシステム９０のブロック図である。コンピューティングシステム９０は、コンピュータまたはサーバを備え得、主に、そのようなソフトウェアが記憶またはアクセスされる場所もしくは手段にかかわらず、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得る。そのようなコンピュータ読み取り可能な命令は、コンピューティングシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの既知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書を受信すること、もしくはセッション証明書に基づいて認証すること等のＥ２ＥＭ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、ならびに処理し得る。

動作時、ＣＰＵ９１は、命令をフェッチ、復号、および実行し、コンピュータの主要データ転送パスであるシステムバス８０を介して、情報を他のリソースへ、ならびにそこから転送する。そのようなシステムバスは、コンピューティングシステム９０内のコンポーネントを接続し、データ交換のための媒体を定義する。システムバス８０は、典型的には、データを送信するためのデータラインと、アドレスを送信するためのアドレスラインと、インタラプトを送信するため、およびシステムバスを動作させるための制御ラインとを含む。そのようなシステムバス８０の例は、ＰＣＩ（周辺コンポーネント相互接続）バスである。

システムバス８０に結合されるメモリは、ランダムアクセスメモリ（ＲＡＭ）８２と、読み取り専用メモリ（ＲＯＭ）９３とを含む。そのようなメモリは、情報が記憶されて読み出されることを可能にする回路を含む。ＲＯＭ９３は、概して、容易に修正されることができない記憶されたデータを含む。ＲＡＭ８２内に記憶されたデータは、ＣＰＵ９１または他のハードウェアデバイスによって読み取られること、もしくは変更されることができる。ＲＡＭ８２および／またはＲＯＭ９３へのアクセスは、メモリコントローラ９２によって制御され得る。メモリコントローラ９２は、命令が実行されると、仮想アドレスを物理アドレスに変換するアドレス変換機能を提供し得る。メモリコントローラ９２はまた、システム内のプロセスを隔離し、ユーザプロセスからシステムプロセスを隔離するメモリ保護機能を提供し得る。したがって、第１のモードで起動するプログラムは、それ自身のプロセス仮想アドレス空間によってマップされるメモリのみにアクセスすることができ、プロセス間のメモリ共有が設定されていない限り、別のプロセスの仮想アドレス空間内のメモリにアクセスすることができない。

加えて、コンピューティングシステム９０は、ＣＰＵ９１からプリンタ９４、キーボード８４、マウス９５、およびディスクドライブ８５等の周辺機器に命令を通信する責任がある、周辺機器コントローラ８３を含み得る。

ディスプレイコントローラ９６によって制御されるディスプレイ８６は、コンピューティングシステム９０によって生成される視覚出力を表示するために使用される。そのような視覚出力は、テキスト、グラフィックス、動画グラフィックス、およびビデオを含み得る。ディスプレイ８６は、ＣＲＴベースのビデオディスプレイ、ＬＣＤベースのフラットパネルディスプレイ、ガスプラズマベースのフラットパネルディスプレイ、またはタッチパネルを伴って実装され得る。ディスプレイコントローラ９６は、ディスプレイ８６に送信されるビデオ信号を生成するために要求される電子コンポーネントを含む。

さらに、コンピューティングシステム９０は、コンピューティングシステム９０がネットワークの他のノードと通信することを可能にするように、図２９および図３０のネットワーク１２等の外部通信ネットワークにコンピューティングシステム９０を接続するために使用され得る、例えば、ネットワークアダプタ９７等の通信回路を含み得る。通信回路は、単独で、またはＣＰＵ９１と組み合わせて、本明細書で、例えば、図３−９、１１−１３、１５、１６、１８、１９、および２１−２８で、ならびに請求項で説明される、伝送および受信するステップを行うために使用され得る。

図３−９、１１−１３、１５、１６、１８、１９、および２１−２８、その説明、ならびに本明細書の請求項は、エンドツーエンド認証機能性を可能にするための方法および装置の種々の実施形態を図示する。これらの図では、１つ以上のクライアント、サーバ、および／もしくはプロキシによって行われている種々のステップまたは動作が、示されている。これらの図に図示されるクライアント、サーバ、およびプロキシは、通信ネットワーク内の論理エンティティを表し得、本明細書に説明されるような図２９または３０に図示される一般的アーキテクチャのうちの１つを備え得る、そのようなネットワークのノードのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア、すなわち、コンピュータ実行可能命令の形態で実装され得ることが理解される。すなわち、図３−９、１１−１３、１５、１６、１８、１９、および２１−２８ならびに請求項に図示される方法は、例えば、図３１または３２に図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア、すなわち、コンピュータ実行可能命令の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図に図示されるステップを行う。これらの図に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下で、ノードの通信回路（例えば、それぞれ、図３１および３２の回路３４または９７）によって行われ得ることも理解される。

本明細書に説明されるシステム、方法、およびプロセスのうちのいずれかまたは全ては、コンピュータ読み取り可能な記憶媒体上に記憶されたコンピュータ実行可能命令（すなわち、プログラムコード）の形態で具現化され得、その命令は、例えば、Ｍ２Ｍサーバ、ゲートウェイ、デバイス等を含む、Ｍ２Ｍネットワークのノード等のマシンによって実行されると、本明細書に説明されるシステム、方法、およびプロセスを実施ならびに／もしくは実装することが理解される。具体的には、上記で説明されるステップ、動作、または機能のうちのいずれかは、そのようなコンピュータ実行可能命令の形態で実装され得る。コンピュータ読み取り可能な記憶媒体は、情報の記憶のための任意の非一過性（すなわち、有形または物理的）方法もしくは技術で実装される、揮発性および不揮発性媒体、ならびに取り外し可能および非取り外し可能媒体の両方を含むが、そのようなコンピュータ読み取り可能な記憶媒体は、信号を含まない。コンピュータ読み取り可能な記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリもしくは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）もしくは他の光学ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶デバイス、または所望の情報を記憶するために使用され得、コンピュータによってアクセスされ得る、任意の他の有形もしくは物理媒体を含むが、それらに限定されない。

本明細書は、最良の様態を含む、本発明を開示するために、また、当業者が、任意のデバイスまたはシステムを作製して使用することと、任意の組み込まれた方法を行うこととを含む、本発明を実践することを可能にするために、例を使用する。本発明の特許性のある範囲は、請求項によって定義され、当業者に想起される他の例を含み得る。そのような他の例は、請求項の文字通りの用語と異ならない要素を有する場合に、または請求項の文字通りの用語からごくわずかな差異を伴う同等の要素を含む場合に、請求項の範囲内であることを意図している。

Claims (20)

1. プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介して通信ネットワークに接続され、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
   ａ．メッセージ発信側からメッセージのマルチホップ伝送を受信することであって、前記伝送は、第１の中間エンティティを介して受信され、前記マルチホップ伝送は、前記メッセージ発信側によって生成された前記メッセージのデジタル署名を備えている、ことと、
   ｂ．前記メッセージ発信側の公開キーおよび前記メッセージ発信側によって生成された前記メッセージの前記デジタル署名を使用して、前記メッセージ発信側を認証することと
   を前記装置に行わせる、装置。
2. 前記コンピュータ実行可能命令は、信頼される第三者から前記メッセージ発信側の前記公開キーを取得することを前記装置にさらに行わせる、請求項１に記載の装置。
3. 前記マルチホップ伝送は、前記メッセージ発信側とは別個のソースエンティティからであり、マルチホップ伝送は、前記ソースエンティティによって生成されたデジタル署名を含まない、請求項１に記載の装置。
4. 前記マルチホップ伝送は、前記第１の中間エンティティによって生成されたデジタル署名をさらに備え、前記コンピュータ実行可能命令は、前記第１の中間エンティティの公開キーおよび前記第１の中間エンティティによって生成された前記署名を使用して、前記第１の中間エンティティを認証することを前記装置にさらに行わせる、請求項１に記載の装置。
5. 前記伝送は、複数の中間エンティティの各々によって生成されたデジタル署名をさらに備え、前記コンピュータ実行可能命令は、前記公開キーおよび前記複数の中間エンティティの各々によって生成された前記デジタル署名を使用して、前記複数の中間エンティティの各々を認証することを前記装置にさらに行わせる、請求項１に記載の装置。
6. 前記コンピュータ実行可能命令は、前記メッセージ発信側の前記認証に基づいて、前記マルチホップ伝送を宛先エンティティに転送すべきかどうかを決定することを前記装置にさらに行わせる、請求項１に記載の装置。
7. 前記コンピュータ実行可能命令は、
   ａ．前記宛先エンティティの公開キーを使用して、前記宛先エンティティを認証することと、
   ｂ．前記宛先エンティティの前記認証に基づいて、前記第１のマルチホップ伝送を宛先エンティティに転送すべきかどうかを決定することと
   を前記装置にさらに行わせる、請求項６に記載の装置。
8. 前記マルチホップ伝送は、ホップ毎の証明書を備え、前記コンピュータ実行可能命令は、前記ホップ毎の証明書を調査することを前記装置にさらに行わせる、請求項１に記載の装置。
9. 方法であって、前記方法は、
   ａ．第１の中間エンティティを介して、メッセージ発信側からマルチホップ伝送を受信することであって、前記マルチホップ伝送は、前記メッセージ発信側によって生成されたデジタル署名を備えている、ことと、
   ｂ．前記メッセージ発信側の公開キーおよび前記メッセージ発信側によって生成された前記デジタル署名を使用して、前記メッセージ発信側を認証することと
   を含む、方法。
10. 信頼される第三者から前記メッセージ発信側の前記公開キーを取得することをさらに含む、請求項９に記載の方法。
11. 前記マルチホップ伝送は、前記メッセージ発信側とは別個のソースエンティティからであり、マルチホップ伝送は、前記ソースエンティティのデジタル署名を含まない、請求項９に記載の方法。
12. 前記マルチホップ伝送は、前記第１の中間エンティティによって生成された前記メッセージのデジタル署名をさらに備え、前記方法は、前記第１の中間エンティティの公開キーおよび前記第１の中間エンティティによって生成された前記メッセージの前記デジタル署名を使用して、前記第１の中間エンティティを認証することをさらに含む、請求項９に記載の方法。
13. 前記伝送は、複数の中間エンティティの各々によって生成されたデジタル署名を含む複数のメッセージをさらに備え、前記方法は、前記公開キーおよび前記複数の中間エンティティの各々によって生成された前記デジタル署名を使用して、前記複数の中間エンティティを認証することをさらに含む、請求項９に記載の方法。
14. 前記メッセージ発信側の前記認証に基づいて、前記メッセージ発信側によって生成された前記デジタル署名を検証することを介して、前記マルチホップ伝送を宛先エンティティに転送すべきかどうかを決定することをさらに含む、請求項９に記載の方法。
15. ａ．前記メッセージ発信側によって生成された前記デジタル署名および前記宛先エンティティの公開キーを使用して、前記宛先エンティティを認証することと、
    ｂ．前記宛先エンティティの前記認証に基づいて、前記第１のマルチホップ伝送を宛先エンティティに転送すべきかどうかを決定することと
    をさらに含む、請求項１４に記載の方法。
16. 前記マルチホップ伝送は、ホップ毎の証明書を備え、前記方法は、前記ホップ毎の証明書を調査することをさらに含む、請求項９に記載の方法。
17. プロセッサと、メモリと、通信回路とを備えている装置であって、前記装置は、その通信回路を介して通信ネットワークに接続され、前記装置は、前記装置の前記メモリ内に記憶されたコンピュータ実行可能命令をさらに備え、前記命令は、前記装置の前記プロセッサによって実行されると、
    ａ．第１の組のセキュリティ処理能力パラメータを登録し、記憶することであって、前記第１の組のセキュリティ処理能力パラメータは、第１のネットワークエンティティに対応し、前記第１のエンティティは、前記装置とは別個である、ことと、
    ｂ．要求に応じて、前記第１の組のセキュリティ処理能力パラメータを第２のネットワークエンティティに提供することであって、前記第１のエンティティは、前記装置とは別個である、ことと
    を前記装置に行わせる、装置。
18. 前記第１の組のセキュリティ処理能力パラメータは、利用可能なプロセッサ能力、利用可能な電力、利用可能なメモリ、利用可能な無線帯域幅、メッセージ完全性機構、認証機構、否認防止機構、機密保持機構、またはサポートされるセキュリティプロトコルを備えている、請求項１７に記載の装置。
19. 前記セキュリティパラメータは、セキュリティ証明書を備えている、請求項１７に記載の装置。
20. 前記コンピュータ実行可能命令は、エンドツーエンド認証のみが要求されることを前記第２のエンティティに通知することを前記装置にさらに行わせる、請求項１７に記載の装置。