JP2019146196A - エンドツーエンドサービス層認証 - Google Patents

Abstract

【課題】多様な能力（例えば、処理、メモリ等）を有し、いかなる事前セキュリティアソシエーションも伴わないエンティティの間でエンドツーエンド認証を行う機構を提供する。【解決手段】セキュリティプロビジョニングおよび構成プロセスは、適切なセキュリティ証明書、機能、スコープ、およびパラメータがエンティティにプロビジョンされ得るように行われ、サービス層またはセッション層においてエンドツーエンド認証を行うために証明書を使用し、直接または委託モードを使用する、セキュリティ証明書を他のエンティティに配布する。【選択図】図２

Description

（関連出願の引用）
本願は、米国仮出願第６２／０７３，５７８号（２０１４年１０月３１日出願）に対する優先権を主張し、上記出願の開示は、参照により本明細書に引用される。

マシンツーマシン（Ｍ２Ｍ）技術は、有線および無線通信システムを使用して、デバイスが互いにより直接通信することを可能にする。Ｍ２Ｍ技術は、モノのインターネット（ＩｏＴ）、固有に識別可能なオブジェクトのシステム、およびインターネット等のネットワークを経由して通信するそのようなオブジェクトの仮想表現のさらなる実現を可能にする。ＩｏＴは、食料品店内の商品等のありふれた毎日のオブジェクトとさえも通信を促進し、それによって、そのようなオブジェクトの知識を向上させることによって費用および無駄を削減し得る。例えば、店は、在庫にあり得るか、または販売された場合があり得るオブジェクトと通信するか、もしくはそこからデータを取得することができることによって、非常に精密な在庫データを維持し得る。理解されるであろうように、ＩｏＴは、何百万個ものデバイスを含む可能性がある。

図１Ａは、例示的ｏｎｅＭ２Ｍ機能的アーキテクチャ１００を図示する略図である。開発中のｏｎｅＭ２Ｍ規格は、図１Ａ−Ｂに図示されるような「共通サービスエンティティ（ＣＳＥ）」と呼ばれるサービス層を定義する。サービス層の目的は、ｅ−ヘルス、保有車両管理、およびスマートホーム等の異なる「バーティカル」Ｍ２Ｍサイロシステムならびにアプリケーションによって利用されることができる「ホリゾンタル」サービスを提供することである。ＣＳＥは、４つの基準点をサポートする。Ｍｃａ基準点は、アプリケーションエンティティ（ＡＥ）とインターフェースをとる。Ｍｃｃ基準点は、同一サービスプロバイダドメイン内の別のＣＳＥとインターフェースをとり、Ｍｃｃ”基準点は、異なるサービスプロバイダドメイン内の別のＣＳＥとインターフェースをとる。Ｍｃｎ基準点は、下層ネットワークサービスエンティティ（ＮＳＥ）とインターフェースをとる。ＮＳＥは、デバイス管理、場所サービス、およびデバイストリガ等の下層ネットワークサービスをＣＳＥに提供する。ＣＳＥは、「発見」、「データ管理およびリポジトリ」等の「共通サービス機能（ＣＳＦ）」と呼ばれる複数の論理機能を含む。

図１Ｂは、ｏｎｅＭ２Ｍアーキテクチャのために開発中のＣＳＦを図示する略図である。

ｏｎｅＭ２Ｍは、以下のタイプのノード、すなわち、アプリケーションサービスノード（ＡＳＮ）、アプリケーション専用ノード（ＡＤＮ）、中間ノード（ＭＮ）、およびインフラストラクチャノード（ＩＮ）を有効にする。

アプリケーションサービスノード（ＡＳＮ）は、１つのＣＳＥを含み、かつ少なくとも１つのＡＥを含むノードである。物理的マッピングの実施例は、Ｍ２Ｍデバイス内に常駐するＡＳＮである。

アプリケーション専用ノード（ＡＤＮ）は、少なくとも１つのＡＥを含み、ＣＳＥを含まないノードである。物理的マッピングの実施例は、制約されたＭ２Ｍデバイス内に常駐するＡＤＮである。

中間ノード（ＭＮ）は、１つのＣＳＥを含み、かつゼロまたはそれを上回るＡＥを含むノードである。物理的マッピングの実施例は、Ｍ２Ｍゲートウェイ内に常駐するＭＮである。

インフラストラクチャノード（ＩＮ）は、１つのＣＳＥを含み、かつゼロまたはそれを上回るＡＥを含むノードである。物理的マッピングの実施例は、Ｍ２Ｍサービスインフラストラクチャ内に常駐するＩＮである。

現在、ｏｎｅＭ２Ｍエンドノードがセキュアな様式で互いに通信したいとき、ノードおよび中間ノードは、ホップ毎の様式で互いにセキュリティアソシエーションを確立する。ホップ毎のセキュリティアソシエーションは、対称キーを用いて、証明書を使用して、または、直接プロセスによってもしくはインフラストラクチャを用いて行われ得るブートストラッピングプロセスによって、確立され得る。また、ＴＳ−０００３−セキュリティソリューション文書は、「サービス層レベルで、セキュリティアソシエーション確立は、隣接するＡＥ／ＣＳＥの間で交換されているメッセージを保護するＴＬＳまたはＤＴＬＳセッションをもたらす（すなわち、ホップ毎）。それらの情報交換のプライバシーを信頼できない中間ノードから保つ必要があるＡＥは、それらの間の直接セキュリティアソシエーションをサポートするようにプロビジョンされ得る」と述べている。

多様な能力（例えば、処理、メモリ等）を有し、いかなる事前セキュリティアソシエーションも伴わない、エンティティの間でエンドツーエンド認証を行う種々の機構が使用される。セキュリティプロビジョニングおよび構成プロセスは、適切なセキュリティ証明書、機能、スコープ、およびパラメータがエンティティにプロビジョンされ得るように行われる。そして、サービス層またはセッション層においてエンドツーエンド認証を行うために証明書を使用し得、直接または委託モードを使用する、セキュリティ証明書を他のエンティティに配布する機構が使用される。

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

より詳細な理解が、添付図面と併せて一例として挙げられる、以下の説明から取得され得る。
図１Ａ−Ｂは、ｏｎｅＭ２Ｍサービス層の略図である。 図１Ａ−Ｂは、ｏｎｅＭ２Ｍサービス層の略図である。 図２は、エンドツーエンド（Ｅ２Ｅ）セキュリティ段階を図示する略図である。 図３Ａ−Ｂは、エンティティＡとエンティティＢとの間の例示的Ｅ２Ｅ動作を図示する略図である。 図３Ａ−Ｂは、エンティティＡとエンティティＢとの間の例示的Ｅ２Ｅ動作を図示する略図である。 図４Ａ−Ｂは、ｏｎｅＭ２Ｍ実施形態を図示する略図である。 図４Ａ−Ｂは、ｏｎｅＭ２Ｍ実施形態を図示する略図である。 図５Ａ−Ｂは、セキュリティ証明書請求およびプロビジョニング（ＳＣＲＰ）段階を図示する略図である。 図５Ａ−Ｂは、セキュリティ証明書請求およびプロビジョニング（ＳＣＲＰ）段階を図示する略図である。 図６Ａ−Ｂは、第三者証明書要求段階を図示する略図である。 図６Ａ−Ｂは、第三者証明書要求段階を図示する略図である。 図７Ａ−Ｂは、ＡＥ１がＣＳＥ３上でホストされる遠隔リソースへの更新動作を要求する、Ｅ２Ｅ認証を図示する。 図７Ａ−Ｂは、ＡＥ１がＣＳＥ３上でホストされる遠隔リソースへの更新動作を要求する、Ｅ２Ｅ認証を図示する。 図８Ａ−Ｂは、委託モードアプローチを使用する、サービス層におけるＥ２Ｅ認証を図示する略図である。 図８Ａ−Ｂは、委託モードアプローチを使用する、サービス層におけるＥ２Ｅ認証を図示する略図である。 図９は、委託モードを使用してセッション層（ＤＴＬＳ／ＴＬＳ）において行われるＥ２Ｅ認証を図示する略図である。 図１０は、直接モードを使用するセッション層におけるＥ２Ｅ認証を図示する略図である。 図１１Ａ−Ｂは、グループ認証を図示する略図である。 図１１Ａ−Ｂは、グループ認証を図示する略図である。 図１２は、一実施形態のインターフェースを図示する略図である。 図１３は、エンドツーエンドメッセージ認証のためのＭＡＣの作成を図示する略図である。 図１４は、一実施形態のブートストラッピングプロセスを図示する略図である。 図１５Ａ−Ｂは、ＡＥとのリソース表現関連付けと、ホップ毎のセキュリティ証明書ならびにエンドツーエンド証明書という属性を有する、＜ｓｅｃｕｒｉｔｙＰａｒａｍｅｔｅｒｓ＞リソース構造とを図示する略図である。 図１５Ａ−Ｂは、ＡＥとのリソース表現関連付けと、ホップ毎のセキュリティ証明書ならびにエンドツーエンド証明書という属性を有する、＜ｓｅｃｕｒｉｔｙＰａｒａｍｅｔｅｒｓ＞リソース構造とを図示する略図である。 図１６Ａ−Ｃは、エンティティプロファイル、デバイスプロファイル、およびセキュリティプロファイルのリソース表現を図示する略図である。 図１６Ａ−Ｃは、エンティティプロファイル、デバイスプロファイル、およびセキュリティプロファイルのリソース表現を図示する略図である。 図１６Ａ−Ｃは、エンティティプロファイル、デバイスプロファイル、およびセキュリティプロファイルのリソース表現を図示する略図である。 図１７は、対称キーを用いたエンドツーエンドメッセージ認証および完全性チェックを図示する略図である。 図１８は、互いから複数のサービス層ホップを離れている２つのエンティティＡＥ２とＣＳＥ１との間の対称キー機構を用いた、エンドツーエンドメッセージ認証および完全性チェックの両方、さらにメッセージ機密性を図示する略図である。 図１９は、信頼される、またはあまり信頼できない、もしくは信頼できない中間ホップを横断して、互いから複数のサービス層ホップだけ離れている２つのエンティティＡＥ２とＣＳＥ１との間の対称キー機構を用いた、エンドツーエンドメッセージ認証および完全性チェックの両方、さらにメッセージ機密性を図示する略図である。 図２０は、ＣＳＥもしくはサービスプロバイダと登録プロセスを開始し、ホップ毎および／またはエンドツーエンドセキュリティのための適切なセキュリティ証明書のプロビジョニングを含む、エンティティＡＥ１を図示する略図である。 図２１Ａは、ＩｏＴイベント管理システムおよび方法の１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）もしくはモノのインターネット（ＩｏＴ）通信システムの略図である。 図２１Ｂは、図２１Ａに図示されるＭ２Ｍ／ＩｏＴ通信システム内で使用され得る、例示的アーキテクチャの系統図である。 図２１Ｃは、図２１Ａに図示される通信システム内で使用され得る、例示的Ｍ２Ｍ／ＩｏＴ端末またはゲートウェイデバイスの系統図である。 図２１Ｄは、図２１Ａの通信システムの側面が具現化され得る、例示的コンピュータシステムのブロック図である。

現在のｏｎｅＭ２Ｍ仕様は、ホップ毎の認証のみを提供し、したがって、遠隔でホストされたサービス／リソース上でＣＲＵＤ（Ｃｒｅａｔｅ、Ｒｅｔｒｉｅｖｅ、Ｕｐｄａｔｅ、Ｄｅｌｅｔｅ）動作を行うことを要求しているエンティティは、リソースをホストしているエンティティによって明示的に認証されない。問題は、以下を含む。
・ 標的エンティティは、それから１ホップ離れているエンティティを認証することしかできず、したがって、アクセス制御が容易に実施可能ではない場合があるので、リソースをホストするエンティティは、リソース上で動作を行おうとしているエンティティを完全には認証できない。
・ ホップ毎の機構により、任意の中間エンティティ（例えば、ＭＮ−ＣＳＥ、ＩＮ−ＣＳＥ）が、他の中間エンティティの代わりにメッセージになりすますことが可能であり得る。
・ ホップ毎の機構が（Ｄ）ＴＬＳを使用して保護されるべきであるので、各ホップにおいて、（Ｄ）ＴＬＳセッションが設定される必要があり、各ホップにおける完全性保護および認証、ならびにおそらくホップの各々における暗号化および暗号解読、したがって、追加の動作オーバーヘッドが、セッション／サービス層において負わされる。セキュリティプロビジョニングおよびセキュリティアソシエーション確立プロシージャは、ホップの各々に関与する２つのエンティティのみによって行われる。

図２は、エンドツーエンド（Ｅ２Ｅ）セキュリティ段階を図示する略図である。エンドツーエンド認証プロセスを行うことは、以下のステップを伴い得る。

図２のステップ１は、サービス有効化およびセキュリティ構成プロセスを示す。このステップでは、エンティティＡ２０２が、サービス有効化機能（ＳＥＦ）２０４とのアソシエーションを確立する。確立されるアソシエーションは、帯域内または帯域外であり得、アソシエーションが確立される前に相互認証プロセスも伴い得る。アソシエーション確立プロセスの一部として、エンティティＡ２０２によって要求または提供されるサービスの性質が、ＳＥＦ２０４によって識別される。エンティティＡ２０２によって必要とされる、または要求されるセキュリティ要件および特徴も、ＳＥＦ２０４によって識別される。要するに、エンティティＡ２０２のセキュリティプロファイル（ＳＰ）、および随意に、プライバシープロファイル（ＰＰ）が、エンティティＡ２０２から取得されるか、またはＳＥＦによって決定／推論および作成されるか、もしくは第３のエンティティから取得される。展開シナリオに基づいて、各エンティティは、固有のＳＰ−Ｉｄによって識別され得る異なるＳＰと、随意に、ＰＰ−Ｉｄによって識別される関連付けられたＰＰとを有し得る。

図２のステップ２は、セキュリティ証明書プロビジョニングプロセスを示す。ＳＰならびに識別された対応するセキュリティ要件および特徴に基づいて、エンティティＡ２０２は、適切なセキュリティ証明書をプロビジョンされる。エンティティＡ２０２に発行されたセキュリティ証明書は、エンティティＡ２０２とセキュリティアソシエーションを確立したいエンティティの認証を行うために、エンティティＡ２０２によって使用される。加えて、エンティティのＥ２Ｅ証明書を提供されているであろう認証されたエンティティのリストが作成される。ある場合、セキュリティ証明書プロビジョニングプロセス中、セキュリティ証明書を生成するために必要とされるシーディング材料のみが、エンティティＡ２０２に提供される。シーディング材料は、適切なセキュリティ証明書を生成するために、既存のセキュリティ証明書とともに使用され得る。シーディング材料はまた、適切なエンドツーエンドセキュリティ（エンドツーエンドメッセージ認証、エンドツーエンドメッセージ機密性）証明書を生成するために、証明書ブートストラッピングプロセスとともに使用され得る。ブートストラッピングプロセスは、下位層（例えば、ネットワーク層／ＭＡＣ層）に存在するセキュリティアソシエーションに基づき得るか、または上位層（例えば、アプリケーション層もしくはサービス層）との既存のセキュリティアソシエーションに基づき得る。既存のセキュリティアソシエーションが存在しない、ある場合、エンドツーエンドセキュリティ証明書が生成される前に、新たなブートストラッピングプロセス（例えば、ＧＢＡ、ＭＥＦベース）が実行される必要があり得る。

図２のステップ３は、第三者証明書請求プロセスを示す。エンティティＮ２０８がエンティティＡ２０２によって提供されるサービス／リソースにアクセスすることができ、その逆も同様であるように、セキュリティアソシエーションがエンティティＮ２０８とエンティティＡ２０２との間で確立され得るために、別のエンティティＮも、エンティティＡ２０２によって設定されたセキュリティ証明書をプロビジョンされ得る。証明書をプロビジョンされる許可を与えられたこれらのエンティティのみが、証明書を提供される。

図２のステップ４は、エンドツーエンド認証プロセスを示す。このステップでは、エンティティＡ２０２およびエンティティＮ２０８が、２つのエンティティの間で直接的に、または随意に、別のエンティティ（例えば、ＳＥＦ）によって有効にされる、エンドツーエンド認証プロセスを行ない得る。

図２に図示されるステップを行うエンティティは、図２１Ｃまたは２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図２に図示される方法は、図２１Ｃまたは２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図２に図示されるステップを行う。図２に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

（サービス有効化およびセキュリティ構成（ＳＥＳＣ）プロセス）
ＳＣＳＣステップ中、ＳＥＦ２０４は、エンティティＡの働きに適するであろう適切なセキュリティ要件および特徴を決定する。セキュリティ要件および特徴は、エンティティによって提供されるＳＰおよびＰＰに基づいて、ＳＥＦ２０４によって決定され得る。ＳＰ、および随意に、ＰＰは、ある推論プロセスを使用して作成され得るか、またはエンティティによって明示的に提供され得るか、もしくはシステムを設定し得る個人（例えば、管理者）によって構成され得る。

表１には、ＳＥＳＣプロセスの一部として、エンティティによってＳＥＦ２０４に提供され得る例示的ＳＰが描写されている。代替として、ＳＰは、エンティティによって提供されるサービスのタイプに基づいて、ＳＥＦによって推論され得る。他の場合では、ＳＰは、特定のエンティティのために管理者によって構成され得、ＳＰは、サービス／ネットワークプロバイダにおけるサーバ等の第３のエンティティからＳＥＦによってフェッチされる。

エンティティ２０２は、エンティティがホストされているデバイスのプロファイル（ＤＰ）を提供し得る。表２は、エンティティ２０２によってＳＥＦ２０４に提供されるか、またはＳＥＦ２０４がエンティティ２０２と同一のデバイス上に実装される場合にデバイスのオペレーティングシステムにクエリを行うことによってＳＥＦによって取得される例示的ＤＰを描写する。代替として、ＳＥＦ２０４は、第３のエンティティからＤＰを取得し得る。

エンティティ２０２はまた、加えて、エンティティプロファイル（ＥＰ）またはアプリケーションプロファイル（ＡＰ）をＳＥＦ２０４に提供し得る。用語ＥＰとＡＰとは、以後、同義的に使用され得る。例示的ＥＰ／ＡＰが、表３に描写されている。代替として、ＳＥＦ２０４は、ＥＰを推論し得るか、または第３のエンティティからＥＰを取得し得る。エンティティは、「医療」に属し、「リアルタイム」サービスを提供し、「重大」な影響を及ぼし、「高い」セキュリティおよび「高い」プライバシーを必要とするアプリケーションである。ある場合、ＳＥＦは、ＳＰまたはセキュリティ要件を直接決定するために、ＥＰおよびＤＰのみを使用し得る。

表４は、別のエンティティであるエンティティＢの例示的ＡＰまたはＥＰを描写する。エンティティは、ホームオートメーションに属し、システムが故障した場合に影響は「低い」と見なされるアプリケーションであり、「中程度」のセキュリティプロファイルおよび「低い」プライバシー影響を有する。

ＳＥＦ２０４は、エンティティ２０２のために適切であるセキュリティ要件を決定するために、ＳＰ、ＤＰ、およびＥＰを使用し得る。セキュリティ要件を決定することにおける推論プロセスは、ＳＰ、および／またはＤＰ、および／またはＥＰ内に提供されている情報の組み合わせを使用することによって行われ得る。プロファイルのうちのいずれかが存在しない場合、ＳＥＦ２０４は、それがアクセスを有するプロファイルに基づいて最良の判断を使用する。ＳＥＦ２０４がプロファイルへのアクセスを有していない場合、第３のエンティティからプロファイルを取得し得る。ＳＥＦ２０４が、適切なセキュリティ要件、したがって、セキュリティ特徴を決定するために、最低でもＥＰおよびＤＰへのアクセスが必要とされ得る。そして、ＳＥＦ２０４は、ＳＰを作成するためにＥＰおよびＤＰを使用し得る。エンティティ２０２がＳＰを供給することができるか、またはＳＥＦ２０４が取得できる場合、ＳＥＦ２０４は、より粒度の細かいセキュリティ要件リストを作成することができるであろう。非常に詳細なセキュリティ要件を決定することができるために、ＳＥＦ２０４が、エンティティＡ２０２のＳＰ、ＤＰ、およびＥＰへのアクセスを有することが理想的であろう。

エンティティによって提供される上記の情報に基づいて、適切なセキュリティ要件が決定され得る。ＳＥＦ２０４は、ＳＰによって強調表示される必要なセキュリティ、ＤＰによって提供されるデバイス能力、および、ＥＰによってエンティティにより提供されているサービスのタイプの組み合わせに基づいて、適切なセキュリティ要件を選択し得る。

同様に、エンティティＢのためにＳＥＦによって推論されるセキュリティ要件が、表６に示されている。

詳細なセキュリティ特徴が、表７に示されている。

したがって、「低い」セキュリティを必要とするサービスのみを提供する、低出力・低メモリデバイス、そして、セキュリティ機能、選択されるアルゴリズム、およびキーサイズが、適切に選択され得る。例えば、選択されるメッセージ認証機構が、１６０ビットキーを伴うＨＭＡＣ−ＳＨＡ１であり得る一方で、より多くの処理およびメモリを伴い、より高いセキュリティを必要とするエンティティは、ＨＭＡＣ−ＳＨＡ２機構とともに使用され得る２５６ビットキーをプロビジョンされるであろう。例えば、ＳＥＦによって推論されるか、またはエンティティＡ２０２によって提供されるセキュリティ要件のリストは、順番もしくは優先順に、以下である。
・ 信号伝達／制御メッセージのメッセージ認証および／または完全性
○ サポートされるアルゴリズム：ＨＭＡＣ−ＳＨＡ２（好ましい）
○ キー長：２５６／５１２／１０２４…
・ データ機密性
○ サポートされるアルゴリズム：ＡＥＳ、ＤＥＳ…
○ キー長：１２８／２５６／５１２・・
・ データの完全性：必要とされる
・ 認証機構：
○ 対称キーおよび／または
○ 証明書および／または
○ ブートストラッピングプロセス
・ 認証されていないユーザをサポートする能力
・ サポートされたプロトコル：ＥＡＰ／ＩＰＳｅｃ／（Ｄ）ＴＬＳ／ＪＷＴ
・ 認証：直接／委託／部分委託アプローチ。

ＳＥＳＣプロセスの終了時、ＳＥＦ２０４は、完全なプロファイルと、エンティティの能力とを有する。エンティティの能力の知識を有することは、エンティティの働き、エンティティによって提供されるデータおよびサービス、ならびにエンティティとの通信を保護するために実装されなければならない適切なセキュリティ対策および特徴をＳＥＦ２０４が決定することに役立つ。ＳＥＦ２０４は、エンティティの能力のテーブルを維持する。ＳＥＦにおいて維持される例示的な表が、以下に示される。

（セキュリティ証明書プロビジョニング（ＳＣＰ）プロセス）
ＳＣＰプロセスは、セキュリティ証明書要求プロセスおよびセキュリティ証明書プロビジョニングプロセスのステップを伴い得る。

セキュリティ証明書要求プロセスは、エンティティによって、またはエンティティの代わりにＳＥＦ２０４によって開始され得る。エンティティによって提供されるサービスの能力および／またはタイプに基づいて、適切なセキュリティ証明書、および加えて、他の構成パラメータが、好ましくは信頼される第三者（ＴＴＰ）上でホストされるキー導出機能（ＫＤＦ）２０６に要求される。エンティティとＴＴＰとの間の認証は、随意であり得る。ＳＥＦ２０４は、ＫＤＦ２０６の役割を果たし得るが、拡張可能性の視点から、ＴＴＰ／ＫＤＦ２０６機能性は、異なるエンティティによって果たされ得る。ＳＥＦ２０４は、ＳＥＦ２０４がエンティティＡ２０２の代わりに証明書を要求している場合に、ＴＴＰ／ＫＤＦ２０６と互いに認証され得る。

セキュリティ証明書プロビジョニングプロセスでは、ＫＤＦ２０６は、キーを生成し、どのようにして、かつどのような目的でキーが使用され得るか（ＭＡＣ、暗号化、どの層で保護が適用されるべきか、および含まれるべき関連付けられたパラメータ等）、どのようにしてキーが使用され得るかというスコープおよびそれが使用されるコンテキスト、随意に、生成される新しいＩＤおよび使用されるべき推奨アルゴリズムを説明する。ＴＴＰ／ＫＤＦ２０６は、以下に示されるような類似し得る表を維持する。

コンテキストＩＤ、関連付けられたキー、ならびに他の関連付けられたパラメータおよびスコープが、要求エンティティまたはＳＥＦ２０４に提供される。認証パラメータは、セキュリティプロセス（例えば、認証プロセス）の一部として含まれ得る、セキュリティ情報を示し得る。確立される各セキュリティコンテキストは、有効存続期間を有し、有効存続期間後、コンテキストが更新され得るか、または新しいものが作成され得る。コンテキストＩＤは、証明書（キー、アルゴリズム等）ならびに関連付けられたスコープおよびパラメータを識別するために使用され得る。

（第三者証明書請求プロセス）
第三者証明書請求ステップでは、別のエンティティ（エンティティＡ２０２等）とエンドツーエンド認証を行うことを要求されるエンティティＮ２０８が、Ｅ２Ｅセキュリティアソシエーションが作成され得るように、キーイング材料、キーに関連付けられるスコープ、メッセージ認証を実証するために使用され得るパラメータ、および他の情報を要求する。要求エンティティは、随意に、ＴＴＰ／ＫＤＦ２０６で認証され得、エンティティがＥ２Ｅキーをプロビジョンされる許可を与えられているかどうかも決定する。今後、ＴＴＰおよび／またはＫＤＦ２０６は、ＴＴＰと称されるであろう。エンティティは、コンテキストＩＤ、ＵＲＩ、ポート番号、関連付けられたキー、スコープ、および関連付けられたパラメータをプロビジョンされる。生成されるキーは、２つのエンドエンティティにさらに適するように適合され得る。随意に、別のレベルのキー生成プロセスが起こってもよい。エンティティＮにおいて、エンティティＮは、セキュリティアソシエーションを作成して維持したいエンティティとともに以下のパラメータを維持し得る。

上記の表では、エンティティＮ２０８がエンティティＡ２０２とＥ２Ｅ認証を行うために、随意のパラメータであり得るコンテキストＩＤ（エンティティＡ−コンテキスト１）をそれが提供され得ることが観察されることができる。

コンテキストＩＤ：Ｅ２Ｅ認証を確立するために使用されるセキュリティ特徴／パラメータを識別するために使用され得る。コンテキストＩＤは、Ｅ２Ｅセキュリティ証明書ならびに関連付けられたスコープおよびパラメータを識別するために使用される。コンテキストＩＤは、無作為に、または暗号プロセスを使用して生成され得る。コンテキストＩＤは、エンティティまたはトランザクションの一時識別として使用され得る。

リソースＩＤ：これは、エンティティＮが、それを用いてＥ２Ｅ認証プロセスおよびアソシエーションを作成したいエンティティの識別（例えば、エンティティのＵＲＩまたはドメイン名、ＩＰ＠等）である。

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

プロトコル：サービス層Ｅ２Ｅの場合、プロトコルは、使用されるべきメッセージ認証アルゴリズム（例えば、ＨＭＡＣ−ＳＨＡ２）を単に示すが、セッション層の場合、プロトコルは、（ＤＴＬＳまたはＴＬＳもしくは任意のその他であり得る）プロトコルを示す。これは、セッションまたはサービス層のみに制約されず、アプリケーション層（例えば、セキュアＲＴＰ）に関連付けられるプロトコル、もしくはＩＰＳｅｃ、ＥＡＰ等の他の下位層プロトコルを伴い得る。

パラメータ：キー保有／メッセージ認証の証拠を提供するために使用され得る値（例えば、ノンス、時間、ランダムチャレンジ等）を示す。

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

エンティティＡ２０２に関連付けられるエンドツーエンド証明書が、ＴＴＰによってエンティティＮと称される第三者にプロビジョンされ得るか、または、エンティティＮ２０８が、エンティティＡ２０２とエンティティＮ２０８との間で、エンドツーエンドセキュリティ保護（すなわち、エンドツーエンドメッセージ認証、エンドツーエンドメッセージ機密性、エンドツーエンドデータ機密性、およびエンドツーエンドデータ完全性）を検証もしくは提供するために使用される適切なセキュリティ証明書を生成することができるように、必要なキーイング材料がエンティティＮ２０８にプロビジョンされる。生成され得る証明書のタイプのリストが、表参照において提供される。

（キーイング材料を生成する）
ＫＤＦ２０６を採用するＴＴＰは、エンティティＮ２０８の認証を行ない得、その後、エンティティＮが認可された場合、エンティティＮは、適切なＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ特定のエンドツーエンドキーでプロビジョンされる。エンティティＡ２０２によって事前プロビジョンされた、事前構成されたＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ特定のキーは、エンティティＮ２０８に提供される。Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒがプロビジョンされた場合、ＴＴＰは、適切なＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ特定のキーを生成し、それらをエンティティＮ２０８にプロビジョンする。代替として、ＴＴＰは、Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮキーのみをエンティティＮ２０８に提供し、エンティティＮ２０８がエンティティＮ２０８によるセキュリティ保護のために必要な種々のキーを生成することができるように、エンティティＮ２０８に必要なシーディング材料も提供する。生成される種々のキーは、文書内でメッセージ認証のためのＥ２Ｅ＿ＭＡＣ＿Ｋｅｙとも称されるＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈ、メッセージ機密性のためのＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ｃｏｎｆ、データ機密性を提供するためのＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｄａｔａ＿ｃｏｎｆ、およびエンドツーエンドデータ完全性を提供するためのＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｄａｔａ＿ａｕｔｈであり得る。

注記：ある略図では、エンドツーエンドＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈおよびＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈは、一般的に、ＫｐｓａＥ２Ｅと称され得る。

Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒは、エンティティＡ２０２およびＴＴＰによって実行される認証プロセスに基づいて、エンティティＡ２０２およびＴＴＰによって生成され得る。Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒは、エンティティＡ２０２とＴＴＰとの間で実行されるブートストラッピングプロセスの結果であり得る。加えて、Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒは、認証に結び付けられたチャネルおよびエンティティＡ２０２とＴＴＰとの間で認証（例えば、ＴＬＳまたはＤＴＬＳもしくはＧＢＡ）を行うために使用される認証チャネルであり得る。ブートストラップされたプロセス：ＧＢＡ等のブートストラッピング機構は、各エンティティペアに関連付けられ得るＫｅ２ｅキーを導出するために使用され得る。Ｅ２Ｅ視点からエンティティを認証したいエンティティ（例えば、エンティティＡ）は、ＧＢＡを使用してＴＴＰで認証され得る。ＧＢＡプロセスを使用してエンティティＡを認証する結果として生成される、マスタＥ２Ｅキーは、以下の形態であり得る。
Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒ：１４８７３５８８０６５２Ｃ６５２３８Ｂ４３２Ａ…（２５６ビット）
Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒは、エンティティＡ２０２とＴＴＰとの間の成功した相互認証に基づいて、エンティティＡ２０２ならびにＴＴＰブートストラッピングによって生成され得る。

エンティティ特定のキーが、ＴＴＰによって生成およびプロビジョンされるか、またはエンティティ特定のエンドツーエンドキーが生成されることができるように、シーディング材料が、エンドエンティティの各々に提供される。エンドツーエンドキーを生成する例示的機構が、以下に示される。
Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＢ＝ＨＭＡＣ−ＳＨＡ２５６（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒ，”Ｂｏｏｔｓｔｒａｐ Ｐｒｏｃｅｓｓ”｜｜Ｅｎｔｉｔｙ＿Ｂ−ＩＤ｜｜Ｒａｎｄｏｍ１）
Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＣ＝ＨＭＡＣ−ＳＨＡ２５６（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒ，”Ｂｏｏｔｓｔｒａｐ Ｐｒｏｃｅｓｓ”｜｜Ｅｎｔｉｔｙ＿Ｃ−ＩＤ｜｜Ｒａｎｄｏｍ２）
Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＝ＨＭＡＣ−ＳＨＡ２５６（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒ，”ＢｏｏｔｓｔｒａｐＰｒｏｃｅｓｓ”｜｜Ｅｎｔｉｔｙ＿Ｎ−ＩＤ｜｜Ｒａｎｄｏｍ３）
関連付けＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈおよびＫｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ｃｏｎｆキーを生成するために、キー拡張機構がエンティティＡおよびエンティティＮによって使用され得、それらは、それぞれ、エンティティＡとエンティティＮとの間のメッセージのためのエンドツーエンドメッセージ真正性ならびにエンドツーエンドメッセージ機密性を提供するために使用される。エンドツーエンドキーのためのキー拡張の実施例が提供される：
Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈ＝ＨＭＡＣ−Ｈａｓｈ（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍａｓｔｅｒ，Ｔ（０）｜”Ｅ２Ｅ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｋｅｙ”｜０ｘ０１）
Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ｃｏｎｆ＝ＨＭＡＣ−Ｈａｓｈ（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍａｓｔｅｒ，Ｔ（１）｜”Ｅ２Ｅ Ｍｅｓｓａｇｅ Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ Ｋｅｙ”｜０ｘ０２）
単一のキーに基づくＡＥＡＤ暗号プロセスが使用される場合、上記のキーのうちの１つのみが生成される。

サービス層：サービス層におけるＥ２Ｅ認証、ホップ毎の保護機構が依然として使用され得るが、加えて、Ｅ２Ｅメッセージ発信認証が使用される。加えて、セキュリティ重要性があると見なされる情報およびパラメータが、サービス層において保護され得る。保護は、ＪＳＯＮウェブ署名（ＪＷＳ）を用いて提供され得る。メタデータのみが、中間ノードによって処理され得る。メタデータは、メッセージ認証コード（ＭＡＣ）キーの役割を果たすＥ２Ｅキーに基づいてＥ２Ｅ ＪＳＯＮウェブ署名によって完全性保護され、ＪＳＯＮウェブ署名等のＪＳＯＮフォーマットを使用して表され得る。データに関連付けられた認証暗号化（ＡＥＡＤ）クラスのアルゴリズム等の暗号アルゴリズム（ＡＥＳ−ＣＣＭおよびＡＥＳ−ＧＣＭ等）を使用することは、エンドツーエンドメッセージ真正性ならびにメッセージ機密性の両方を提供することができる。メッセージ真正性を提供し、チェックするために使用される関連付けられたデータを識別すること。関連付けられたデータは、メッセージヘッダで構成され得、それは、メッセージ機密性が必要とされる場合において暗号化されない。代替として、いかなる中間ノードによっても修正されないメッセージ全体が、メッセージ認証コードを作成するために使用され得る。前述のように、メッセージのメタデータと呼ばれる、メッセージヘッダの一部が、ＡＥＡＤアルゴリズム内で関連付けられたデータとして使用され得、それは、そして、ＭＡＣの計算のために使用される。ＭＡＣが他の手段を使用して生成され、専用手段を使用して表されることも可能であり得る。ＭＡＣを生成するために使用される機構およびメッセージング内のＭＡＣの表現に関係なく、中間ノードによって修正または除去されない全体的メッセージは、時間成分に関連付けられるノンス、またはメッセージが作成された時間とノンス（時間依存性であり得る非常に大きいランダム値）との両方の組み合わせを利用することによって、再生攻撃に対して保護され得る。代替として、メッセージが送信される度にインクリメントされる各メッセージのシーケンス番号が、署名作成プロセス中に使用され得るか、またはノンスとともに時間の代わりに使用され得る。代替として、メッセージのシーケンス番号は、再生保護のために時間およびノンスとともに含まれる。例えば、署名またはＭＡＣもしくは認証タグ（Ａｕｔｈ＿Ｔａｇ）は、以下のように導出され得る：
ＭＡＣ＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈ，”Ｅ２Ｅ＿ＳｅｒｖｉｃｅＬａｙｅｒＭＡＣ”｜｜ＯｒｉｇｉｎＤａｔａ｜｜Ｔｉｍｅ｜｜Ｎｏｎｃｅ）
または、
ＭＡＣ＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈ，”Ｅ２Ｅ＿ＳｅｒｖｉｃｅＬａｙｅｒＭＡＣ”｜｜ＯｒｉｇｉｎＤａｔａ｜｜Ｍｅｓｓａｇｅ Ｓｅｑｕｅｎｃｅ Ｎｕｍｂｅｒ｜｜Ｎｏｎｃｅ）
「ＯｒｉｇｉｎＤａｔａ」のみの代わりに、完全なメッセージまたはメッセージに関連付けられるメタデータが使用され得る。

Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈ：Ｅ２Ｅ認証を要求するエンティティにプロビジョンされるキー。ここでは、これは、エンティティＡとエンティティＮとの間のエンドツーエンドメッセージ認証キーを示唆する。概して、２つのエンティティ（例えば、エンティティＡ２０２およびエンティティＮ２０８）によって共有される対称キーである。公開キーイング機構の場合、Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈは、（署名エンティティのみに知られている）メッセージに署名することにおいて使用され、公開キーを含む証明書を使用して他方のエンティティによって検証される秘密キー（Ｅ２Ｅ＿ＤＳ＿Ｋｅｙ：エンドツーエンドデジタル署名キーとも称される）であり得る。証明書がない公開キー機構の場合、エンドエンティティは、Ｅ２Ｅ認証が行われているエンティティの公開キーをプロビジョンされなければない。代替実施形態では、公開キー機構は、本質的に対称であり、エンティティによって共有される、Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈを導出するために使用され得る。

ＯｒｉｇｉｎＤａｔａ：元の要求についての情報を含むデータであり、このデータは、実際のメッセージのメタデータと見なされ得るが、実際のメッセージの発信者についての情報も含む。「ＯｒｉｇｉｎＤａｔａ」は、いかなる中間ノードによっても修正されていないと仮定される。ＯｒｉｇｉｎＤａｔａは、メッセージヘッダ内に含まれる情報の一部、すなわち、Ｏｒｉｇｉｎａｔｏｒ−Ｉｄ、Ｄｅｓｔｉｎａｔｉｏｎ−Ｉｄ、Ｒｅｓｏｕｒｃｅ−Ｉｄ、Ｔｙｐｅ−ｏｆ−Ｏｐｅｒａｔｉｏｎ、ならびにＳｅｓｓｉｏｎ−Ｉｄを含み得る。

時間：随意であり得、元のメッセージが作成されたときのタイムスタンプを提供する。

ノンス：時間成分に関連付けられ、かつセッションに関連付けられる、ランダム値であり、再生攻撃から保護する。

シーケンス番号（Ｓｅｑ＃）：これは、メッセージを識別する固有の番号である。ある場合、Ｓｅｑ＃は、Ｓｅｓｓｉｏｎ−Ｉｄと同一であり得る。

セッション層：ＤＴＬＳまたはＴＬＳを用いたＥ２Ｅ認証が使用される。これは、ホップ毎のセキュリティ機構を回避するであろう。エンドエンティティが互いに認証され、セキュリティアソシエーションが確立される。これは、真のＥ２Ｅ様式（直接）または委託モードにおいてエンティティの間で行われ得る。

（エンドツーエンド認証プロセス）
Ｅ２Ｅ認証プロセスは、真のＥ２Ｅ様式で、または委託もしくは部分的委託様式で行われ得る。エンティティによって提供または選択されたスコープに基づいて、Ｅ２Ｅ認証プロセスは、以下を使用して実行され得る。

対称キー：以前に説明されたように、Ｅ２Ｅ認証証明書を要求したエンティティは、Ｅ２Ｅ認証を行うために使用されるべき対称キー、スコープ、およびパラメータをプロビジョンされ得る。対称キーは、直接または委託シナリオでサービス層Ｅ２Ｅもしくはセッション層Ｅ２Ｅ認証に使用され得る。スコープおよび関連付けられたパラメータが提供される限り、それに応じて、エンティティがキーを使用し得る。Ｅ２Ｅ認証キー（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ＥｎｔｉｔｙＮ＿ｍｓｇ＿ａｕｔｈ）は、周期的に再生され得る。同様に、Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒは、証明書の各々に関連付けられる存続期間に基づいて、周期的に生成され得る。

証明書ベース／公開キー：プロビジョンされる証明書は、証明書の形態で表される公開キー、または単に公開／秘密キー、識別ベースの暗号化、もしくは公開キーイング機構に基づく他の機構に基づき得る。セッション層認証のためのＥ２Ｅ認証キー（ｋｅ２ｅ）が、認証のために証明書を使用する、認証されたディフィ・ヘルマンプロセスを使用して、エンティティの間で生成され得る。

（委託対直接セキュリティ機構：）
エンティティが認証のために「高い完全性」または「高度な保証」を必要とする場合、処理要件は、比例してより高くあり得、エンティティの能力（例えば、メモリ／処理）が限定される場合、エンティティは、委託様式でセキュリティ機能を果たすことを選び得る。エンティティは、より複雑なセキュリティ機能（例えば、Ｅ２Ｅ認証、セキュアな記憶、転送秘密保持）を果たすために、認証および他のセキュリティ機能を信頼される第３のエンティティ（例えば、ＳＥＦ２０４）に委託し得る。委託認証を行うことの他の利点は、委託エージェント（例えば、ＳＥＦ）がいくつかのＥ２Ｅ認証を一緒に組み合わせることが可能であり得ることである。

エンティティが単独でＥ２Ｅ認証および他のセキュアな動作を行うことが可能である場合、エンティティは、委託を必要とすることなく、単独で直接認証を行うことを選び得る。ＳＥＦ２０４は、デバイス能力またはサービス要件に基づいて、自分で委託のオプションを選択し得る（例えば、信号伝達または他の動作オーバーヘッドを低減させる）。セキュリティ機能の一部が委託される一方で、他のセキュリティ機能が直接果たされるとき、ハイブリッドアプローチが使用される。

図３Ａ−Ｂは、エンティティＡ２０２とエンティティＢ３０２との間の例示的Ｅ２Ｅ動作を図示する略図である。

図３Ａ−Ｂのステップ１では、エンティティＡ２０２とＳＥＦ１ ２０４（例えば、事前にプロビジョンされた相互信頼を有する第１のホップエンティティ）が、有効にされたセキュアな通信を用いて認証される（Ｄ）ＴＬＳトンネルを確立する。セキュアなトンネルを使用して、サービス有効化セキュリティ構成（ＳＥＳＣ）プロセスが起こり、エンティティＡのプロファイルが作成され、セキュリティ要件が決定される。

図３Ａ−Ｂのステップ２では、エンティティＡ２０２が、随意に、それ自体とエンティティの認可リスト（例えば、エンティティＢ３０２、エンティティＣ…エンティティＮ）との間のＥ２Ｅキーの確立を要求し得る。要求は、エンティティＡ２０２によってＳＥＦ１ ２０４に送信され、ＳＥＦ１ ２０４は、要求をＴＴＰ／ＫＤＦ２０６に送信し得る。代替として、ＳＥＦ１ ２０４は、エンティティＡからの明示的メッセージを必要とすることなく、ＴＴＰ２０６を用いたＥ２Ｅキーの作成を要求し得る。そのシナリオでは、ＳＥＦ１ ２０４は、Ｅ２Ｅキーを提供されるであろう、エンティティの認可リストを決定するであろう。代替として、エンティティＡ２０２は、エンティティＡ２０２とＴＴＰ２０６との間に信頼関係がある場合、キー請求およびエンティティの認可リストをＴＴＰ／ＫＤＦ２０６に直接送信し得る。エンティティＡ２０２がＴＴＰの証明書をプロビジョンされるか、またはＴＴＰとエンティティＡ２０２との間の共有秘密が事前プロビジョンされることが可能であり得る。そのシナリオが機能するために、ＳＥＦ１ ２０４に依拠する必要なくエンティティＡ２０２を直接認証するために、ＴＴＰ２０６が証明書を有していなければならないことに留意されたい。

図３Ａ−Ｂのステップ３では、エンティティＡ２０２の能力、スコープに基づいて、ＴＴＰは、Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒを生成し、エンティティＡ２０２に関連付けられ、証明書請求がＳＥＦ１から起こった場合、生成されるマスタキーは、Ｋｅ２ｅ＿ＳＥＦ１＿ｍａｓｔｅｒであり、ＳＥＦ１ ２０４に関連付けられ得る。キーが使用され得る方法についての追加のパラメータ、ならびにキーおよびキー使用を識別するＣｏｎｔｅｘｔＩＤも生成される。随意に、ＴＴＰは、以下の様式でＭａｓｔｅｒＫｅｙを使用するＥ２Ｅエンティティ特定のキーであるＥ２Ｅ対称キーを生成し得る：
ａ． 例えば、Ｋｅ２ｅ＿ＥｎｔｉｔｉｙＡ＿ＥｎｔｉｔｙＢ＿ｍａｓｔｅｒ＝（Ｋｅ２ｅ＿ＥｎｔｉｔｙＡ＿ｍａｓｔｅｒ，”ＥｎｔｉｔｙＢＩＤ｜｜Ｐａｒａｍｅｔｅｒｓ”）
エンティティＢ ＩＤは、エンティティＡ２０２またはＳＥＦ１によって提供されるエンティティＢの識別（例えば、エンティティＢのＵＲＩ）である。
Ｋｅ２ｅ＿ＥｎｔｉｔｉｙＡ＿ＥｎｔｉｔｙＢ−ｍａｓｔｅｒ：エンティティＡ２０２をエンティティＢに、および逆も同様に認証するために使用されるべきＥ２Ｅ対称キーである。

図３Ａ−Ｂのステップ４では、ＴＴＰが、エンティティＡのＥ２Ｅマスタキーを含むキー、および随意に、Ｅ２Ｅエンティティ特定の対称キーのリストをＳＥＦ１ ２０４に提供する。ＳＥＦ１ ２０４は、キーをエンティティＡ２０２に転送し得る。代替として、ＳＥＦ１ ２０４が請求を行なった場合、キーは、ＳＥＦ１ ２０４に記憶され、エンティティＡ２０２に転送されない。これは、ＳＥＦ１ ２０４がエンティティＡ２０２の代わりに委託認証を行うときに適用可能である。

図３Ａ−Ｂのステップ５では、エンティティ（例えば、エンティティＢ３０２）が、ＳＥＦ２ ３０４とＳＥＳＣプロセスを行う。いくつかのシナリオでは、ＳＥＦ１ ２０４およびＳＥＦ２ ３０４が同一でることが可能であり、該当する場合、Ｅ２Ｅ認証プロセスが省略され得るか、またはキー請求がＴＴＰを伴う必要なく簡略化される可能性がある。

図３Ａ−Ｂのステップ６では、エンティティＢ３０２は、エンティティＡ２０２と通信するためにＥ２Ｅ対称キーが使用されるべきことを要求するために、ＴＴＰに要求する。エンティティＢ３０２は、随意に、ＴＴＰで直接認証され得るか、または代替として、ＴＴＰは、（Ｄ）ＴＬＳ接続に基づいてＳＥＦ２ ３０４を信頼する。代替実施形態では、ＳＥＦ２ ３０４は、エンティティＢの代わりにＴＴＰへの要求を行ない得る。別の実施形態では、ＳＥＦ２ ３０４は、それ自体のためにＥ２Ｅエンティティ特定を要求し得、その場合、より動的なキー生成機構がＴＴＰによって使用され得る。

図３Ａ−Ｂのステップ７では、ＴＴＰは、エンティティＢ３０２が、エンティティＡ２０２によって、エンティティＡのＥ２Ｅキーをプロビジョンされる許可を与えられていることを決定する。そして、ＴＴＰ２０６は、Ｅ２Ｅエンティティ特定のキー（Ｋｅ２ｅ＿ＥｎｔｉｔｉｙＡ＿ＥｎｔｉｔｙＢ＿ｍａｓｔｅｒ）をＳＥＦ２ ３０４に転送し、ＳＥＦ２ ３０４は、それをエンティティＢ３０２に転送する。ＳＥＦ２ ３０４は、代替として、ＳＥＦ２ ３０４が委託認証を提供する場合、キーを記憶し得る。委託認証に対して、ＴＴＰによってプロビジョンされるキーは、Ｋｅ２ｅ＿ＥｎｔｉｔｉｙＡ＿ＳＥＦ２−ｍａｓｔｅｒであり得る。エンティティＡ２０２は、ＳＥＦ２ ３０４を認可していないが、ＴＴＰは、ＳＥＦ２特定のキーを生成し、パラメータ内で適切な情報を提供して、それが委託認証を使用していたことを示し得る。そのようなシナリオでは、エンティティＡ２０２は、提供されたパラメータとともにそれにプロビジョンされたマスタキーを使用して、ＳＥＦ２特定のキーを導出するであろう。

図３Ａ−Ｂのステップ８では、セッション層を経由して起こり得るメッセージングと、実行される対応する動作（例えば、作成、読み出し、更新、または削除）とが、ＭＡＣまたはＪＳＯＮウェブ署名（ＪＷＳ）、または、パラメータおよびキープロビジョニングプロセス中に提供されたＥ２Ｅエンティティ特定のキーに基づいてメッセージ発信者認証を証明することができる任意の他の手段を使用して、保護され得る。

図３Ａ−Ｂに図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図３Ａ−Ｂに図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図３Ａ−Ｂに図示されるステップを行う。図３Ａ−Ｂに図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

（実施形態）
本開示に説明される機構は、認証を伴う環境、より具体的に、制約されると見なされるエンティティ（例えば、ＩｏＴ／Ｍ２Ｍデバイス）のＥ２Ｅ認証に適用可能である。しかしながら、これは、ＩｏＴデバイスのみに限定されず、複雑なセキュリティ機能を果たすことから制約されたデバイスを解放することに加えて、全体としてシステムに関与するメッセージングオーバーヘッドを解放するために、信頼されるエンティティが、適切なセキュリティ特徴、機能、および証明書を決定し得る場合、使用されることができる。以下の項で説明される実施形態は、ｏｎｅＭ２Ｍ仕様に関する。ここでは、ホスティングＣＳＥにおいてＳＥＦ２０４をホストすることを提案する。ＣＳＥはまた、ある場合、ＴＴＰ／ＫＤＦ２０６サポートを提供し得るが、拡張可能性の視点から、ＴＴＰ／ＫＤＦ２０６は、Ｍ２ＭサービスプロバイダＣＳＥにおいて、または証明機関としてホストされ得るが、本開示に説明されるような追加機能性を伴う。

図４Ａ−Ｂは、ｏｎｅＭ２Ｍ実施形態を図示する略図である。ｏｎｅＭ２Ｍは、能力サービス機能（ＣＳＦｓ４０４）と称されるｏｎｅＭ２Ｍサービス層によってサポートされる能力を定義する。ｏｎｅＭ２Ｍサービス層は、能力サービスエンティティ（ＣＳＥ４０２）と称される。一実施形態では、図４Ａに示されるように、提案されたサービス有効化機能２０４は、ｏｎｅＭ２Ｍ ＣＳＦとしてＣＳＦ４０８でホストされ得る。図１８Ｂに示されるように、キー配信機能２０６が、ｏｎｅＭ２Ｍ ＣＳＦとしてＣＳＦ４１２でホストされ得る。

（サービス有効化およびセキュリティ構成（ＳＥＳＣ））
ＳＥＳＣは、図５Ａ−Ｂに図示されるセキュリティ証明書請求およびプロビジョニング（ＳＣＲＰ）段階を含み得、エンティティＣＳＥ３ ５０２は、Ｅ２Ｅ認証証明書の設定を要求する。Ｅ２Ｅ証明書は、Ｅ２Ｅ認証がＣＳＥ３ ５０２を用いて実行されるために、他のエンティティによって使用され得る。メッセージング詳細：
図５Ａ−Ｂのステップ０は、ホップ毎の認証証明書を設定するためのキープロビジョニングステップである。このステップは、現在のｏｎｅＭ２Ｍ仕様に基づいて実行され得る。これは、オフラインで行われ得る。キープロビジョニングステップの結果として、ＣＳＥ３ ５０２およびホスティングＣＳＥ（ＨＣＳＥ）５０４は、対称キー（Ｋｐｓａ１）をプロビジョンされる。

図５Ａ−Ｂのステップ１では、ＣＳＥ３ ５０２およびＨＣＳＥ５０４が、認証のための基礎としてＫｐｓａ１を使用して、ＤＴＬＳ接続を設定する。

図５Ａ−Ｂのステップ２では、ＤＴＬＳ認証の一部として、セッションキーが確立される。

図５Ａ−Ｂのステップ３では、ＣＳＥ３ ５０２が、ｏｎｅＭ２Ｍリソースの作成の必要性を示し、Ｅ２Ｅ証明書の作成の要求も示す「Ｃｒｅａｔｅ Ｒｅｑｕｅｓｔ」メッセージを送信する。ＣＲＥＡＴＥ Ｒｅｑｕｅｓｔメッセージは、ＤＴＬＳセッションキーによって保護される。ＣＳＥ３ ５０２は、Ｅ２Ｅ証明書を使用することができる認可エンティティのリストを提供する。

図５Ａ−Ｂのステップ４では、ＨＣＳＥ５０４は、ＤＴＬＳセッションキーを使用することによって、メッセージの発信元が実際にＡＥ１からであるかどうかを検証する。

図５Ａ−Ｂのステップ５では、ＣＳＥ３ ５０２のためのホスティングＣＳＥであるＨＣＳＥ５０４が、ｏｎｅＭ２Ｍ仕様で規定されるような機構に基づいて、ＣＳＥ３ ５０２のためのリソースを作成する。加えて、上記で説明されるようなサービス有効化プロセス中に推論または取得され得る、ＣＳＥ３ ５０２の能力に基づいて、ＨＣＳＥ５０４は、デバイスの能力に基づいて、適切であるＥ２Ｅ証明書に対する要求を作成する。それは、使用され得るセキュリティ証明書およびパラメータの使用のためのスコープも提供する。スコープは、サービス層／セッション層Ｅ２Ｅ認証であり得、パラメータは、再生保護に使用され得る情報と、（例えば、メッセージまたはメタデータ等の発信者の真の識別を識別する）メッセージ認証に使用される情報とを含む。

図５Ａ−Ｂのステップ６では、ＴＬＳセッションが、事前に確立されたセキュリティ証明書（ＰＳＫ）を使用して、ＨＣＳＥ５０４とＴＴＰ／ＫＤＦ２０６との間で設定される。

図５Ａ−Ｂのステップ７では、証明書、スコープ、使用、およびパラメータに対する要求が、セキュアなＴＬＳトンネルを使用して、ＨＣＳＥ５０４からＴＴＰに送信される。

図５Ａ−Ｂのステップ８では、ＴＴＰが、ＨＣＳＥ５０４によって提供されるデバイス能力情報に基づいて、ＨＣＳＥによる要求に応じて適切な証明書を生成する。デバイス能力が低い場合、適切なアルゴリズム（例えば、ＨＭＡＣ−ＳＨＡ１または３ＤＥＳ、もしくは他の低リソース要求アルゴリズム）が、正しいキーサイズとともに選択される。証明書は、スコープ、パラメータとともに、データベースに記憶される。生成される証明書は、「Ｋｅ２ｅ＿ＣＳＥ３＿ｍａｓｔｅｒ」キーと称され、それは、それに関連付けられる適切なキーハンドル／コンテキストＩＤを有し得る。ＣＳＥ３ ５０２がＴＴＰとの直接接続を有する場合、Ｋｅ２ｅ＿ＣＳＥ３＿ｍａｓｔｅｒキーは、ＴＴＰによってＣＳＥ３ ５０２に直接転送され得る。キーは、ＣＳＥ３ ５０２とＴＴＰとの間に確立される（Ｄ）ＴＬＳ接続を使用して、トランスポートされ得る。

図５Ａ−Ｂのステップ９では、そして、証明書が、必要なスコープおよびパラメータとともにＨＣＳＥ５０４に転送される。

図５Ａ−Ｂのステップ１０では、ＨＣＳＥ５０４が、他の関連付け情報とともに証明書をＣＳＥ３ ５０２に転送する。

図５Ａ−Ｂのステップ１１では、メッセージが、ＨＣＳＥ５０４から受信されたことを検証される。

図５Ａ−Ｂのステップ１２では、スコープおよびパラメータとともに証明書をキー記憶部に記憶する。

図５Ａ−Ｂに図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図５Ａ−Ｂに図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図５Ａ−Ｂに図示されるステップを行う。図５Ａ−Ｂに図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図２０は、ＣＳＥもしくはサービスプロバイダと登録プロセスを開始するエンティティＡＥ１ ６０２を図示し、図は、ホップ毎セキュリティおよび／またはエンドツーエンドセキュリティのための適切なセキュリティ証明書のプロビジョニングを含む。適切な証明書が、ＡＥ１ ６０２に関連付けられるＤＰ、ＳＰ、および／またはＥＰに基づいて決定され得る。

図２０のステップ１では、ＡＥ１ ６０２が、ＣＳＥ１ ６０４との接続要求を開始する。接続要求は、登録要求であり得る。

図２０のステップ２では、ＣＳＥ１ ６０４が、プロファイル、すなわち、ＡＥ１ ６０２に関連付けられるパラメータを有しておらず、したがって、ステップ３においてＩＮ−ＣＳＥ２００２から加入プロファイルを要求する。

図２０のステップ４では、ＩＮ−ＣＳＥ２００２が、ＡＥ１ ６０２に関連付けられるＭ２Ｍ加入プロファイルをＣＳＥ１ ６０４に送信する。

図２０のステップ５では、ＣＳＥ１ ６０４が、サービスまたはネットワークプロバイダネットワークの外側に位置し得るＳＰリポジトリ２００４にＳＰを要求し得る。ＡＥ１ ６０２に関連付けられるＡＥ１＿ＳＰを含む応答が、図２０のステップ６においてＣＳＥ１ ６０４に送信される。

図２０のステップ７では、ＣＳＥ１ ６０４が、ＤＰ／ＥＰリポジトリ２００６から、ＡＥ１＿ＤＰ、ＡＥ１ ６０２に関連付けられるＤＰ、および／またはＡＥ１＿ＥＰ、ＡＥ１ ６０２に関連付けられるＥＰもしくはＡＰを要求し得る。ＡＥ１＿ＤＰおよび／またはＡＥ１＿ＥＰを含む応答は、ステップ８においてＣＳＥ１ ６０４に送信される。

図２０のステップ９では、ＳＰ、ＤＰ、および／またはＥＰに基づいて、ＣＳＥ１ ６０４が、セキュリティ要件の正しい組、したがって、ＡＥ１ ６０２との通信を確保するためのアソシエーションセキュリティ特徴およびパラメータを決定する。

図２０のステップ１０では、ＣＳＥ１ ６０４が、ＣＳＥ１ ６０４によって行われた査定に基づいて、Ｍ２Ｍ登録機能（ＴＴＰ／ＫＤＦ）に適切なセキュリティ証明書を要求する。証明書要求は、明示的または暗示的であり得、粒度の細かいセキュリティ要件またはあまり粒度の細かくない要件のいずれかを提供し得る。

図２０のステップ１１では、Ｍ２Ｍ登録機能（ＭＥＦ）２００８が、ＡＥ１ ６０２とブートストラッピングプロセスを開始し、適切なブートストラップされたセッション証明書を生成する。

図２０のステップ１２では、ＭＥＦ２００８が、ＡＥ１ ６０２に関連付けられるＣＳＥ１特定のエンドツーエンド証明書（Ｋｅ２ｅ＿ＡＥ１＿ＣＳＥ１＿ｍａｓｔｅｒ）を生成し、それをＣＳＥ１ ６０４にプロビジョンする。ＭＥＦ２００８は、代替として、Ｋｐｓａ＿ＡＥ１＿ＣＳＥ１を生成し得、それをＣＳＥ１ ６０４にプロビジョンする。加えて、ＭＥＦ２００８は、証明書に関連付けられるＵｓａｇｅＩｎｆｏおよびＣｏｎｔｅｘｔＩｎｆｏもプロビジョンし得る。

図２０のステップ１３では、ＡＥ１ ６０２が、ＣＳＥ１特定のエンドツーエンド証明書：、Ｋｅ２ｅ＿ＡＥ１＿ＣＳＥ１＿ｍａｓｔｅｒを生成し、関連付けられたＫｅ２ｅ＿ＡＥ１＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈおよび／またはＫｅ２ｅ＿ＡＥ１＿ＣＳＥ１＿ｍｓｇ＿ｃｏｎｆ証明書も、ポリシーならびにＵｓａｇｅＩｎｆｏおよびＣｏｎｔｅｘｔＩｎｆｏに応じて生成され得る。ＡＥ１ ６０２は、代替として、ホップ毎のセキュリティに使用されるＫｐｓａ＿ＡＥ１＿ＣＳＥ１を生成し得る。

図２０のステップ１４では、ＣＳＥ１ ６０４が、ＭＥＦ２００８によってＫｅ２ｅ証明書をプロビジョンされず、Ｋｅ２ｅ＿ＡＥ１＿ＣＳＥ１＿ｍａｓｔｅｒならびにエンドツーエンド証明書の生成のために必要とされるシーディング材料のみをプロビジョンされた場合、Ｋｅ２ｅ＿ＡＥ１＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈおよび／またはｅ２ｅ＿ＡＥ１＿ＣＳＥ１＿ｍｓｇ＿ｃｏｎｆを生成する。

図２０に図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図２０に図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図２０に図示されるステップを行う。図２０に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

（第三者証明書請求段階）
エンティティ（例えば、ＡＥ１ ６０２）が、別のエンティティ（例えば、ＣＳＥ３ ５０２）によってホストされるリソースを読み出したく、かつ他方のエンティティのＥ２Ｅ証明書を要求したい実施形態が、以下の図に図示される。図６Ａ−Ｂは、第三者証明書要求段階を図示する略図である。

ＡＥ１ ６０２およびＣＳＥ１ ６０４ならびにＴＴＰ２０６は全て、エンティティの各々におけるｏｎｅＭ２Ｍ仕様によって規定されるように、キー記憶部内に記憶された対称キーを事前プロビジョンされていることが仮定される。ＡＥ１ ６０２が、ＴＴＰ２０６のＥ２Ｅ証明書のみを事前プロビジョンされ、ＴＴＰ２０６は、ＡＥとホスティングＣＳＥとの間にホップ毎のアソシエーションを設定するための証明書を取得するために使用されることを想定することも可能あり得る。メッセージング詳細：
図６Ａ−Ｂのステップ１では、ＡＥ１ ６０２が、ＣＳＥ１ ６０４とともにＫｐｓａ１を使用してＤＴＬＳセキュリティアソシエーションを設定する。

図６Ａ−Ｂステップ２では、各エンティティが、互いに認証し、セッションキーを設定する。

図６Ａ−Ｂのステップ３では、ＡＥ１ ６０２が、随意のＥ２Ｅ証明書要求メッセージとともに、ＣＳＥ３ ５０２によってホストされるリソースを標的にする「ＲＥＴＲＩＥＶＥ Ｒｅｑｕｅｓｔ」メッセージを送信する。Ｅ２Ｅ証明書要求は、Ｅ２Ｅ認証証明書が要求される場合、ＣＳＥ１ ６０４が決定を行い得るので、随意であり得る。

図６Ａ−Ｂのステップ４では、ＲＥＴＲＩＥＶＥ Ｒｅｑｕｅｓｔメッセージが、ＤＴＬＳトンネル内で転送され、メッセージの発信元が、ＣＳＥ１ ６０４によって検証される。

図６Ａ−Ｂのステップ５では、ＣＳＥ１ ６０４が、ＡＥ１ ６０２の能力に基づいて、ＣＳＥ３ ５０２のための証明書、スコープ、およびパラメータに対する要求を作成する。

図６Ａ−Ｂのステップ６では、ＣＳＥ１ ６０４が、ＰＳＫを使用してＴＴＰとのＴＬＳ接続を設定する。

図６Ａ−Ｂのステップ７では、ＣＳＥ３の証明書、スコープ、パラメータに対する要求、随意に、ＡＥ１の好ましいセキュリティ能力も、提供され得る。

図６Ａ−Ｂのステップ８では、ＡＥ１ ６０２が、ＳＣＲＰ段階中にエンティティＣＳＥ３ ５０２によって認可されており、認可エンティティのリストの中にある場合、ＣＳＥ３証明書対する要求に基づいて、ＴＴＰが、ＣＳＥ３ ６０４に関連付けられる証明書を読み出す。

図６Ａ−Ｂのステップ９では、スコープ、パラメータ等の他の関連付け情報とともに、ＣＳＥ３ ６０４の証明書が、ＴＬＳトンネルを使用してＣＳＥ１に送信される。ＣＳＥ１は、随意に、委託認証が実行されている場合、証明書を記憶し得る。

図６Ａ−Ｂのステップ１０では、ＣＳＥ１が、ＣＳＥ３の証明書および関連付け情報とともに、ＲＥＴＲＩＶＥ ＲｅｓｐｏｎｓｅメッセージをＡＥ１に送信する。

図６Ａ−Ｂのステップ１１では、メッセージが、ＡＥ１によって検証される。

図６Ａ−Ｂのステップ１２では、ＡＥ１ ６０２が、ＣＳＥ３の証明書および関連付けられたパラメータをキー記憶部内に記憶する。

図６Ａ−Ｂに図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図６Ａ−Ｂに図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図６Ａ−Ｂに図示されるステップを行う。図６Ａ−Ｂに図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

ブートストラッピングプロセスに基づく実施形態が、図１４に図示され、ここで説明される。マスタ証明書およびマスタ証明書識別子、またはプロビジョンされたセキュア接続キー（Ｋｐｓａ）およびプロビジョンされたセキュア接続キー識別子（ＫｐｓａＩｄ）の遠隔プロビジョニングを必要とするＡＥもしくはＣＳＥは、登録者と呼ばれる。登録者がセキュリティアソシエーションを確立することができるＡＥまたはＣＳＥは、登録者Ｂと呼ばれる。登録者が共有キーを確立することができるＡＥまたはＣＳＥもしくはＭ２Ｍ認証機能（ＭＡＦ）は、登録標的と呼ばれる。ｏｎｅＭ２Ｍシステムは、事前プロビジョンされた対称登録者キーをサポートし、事前プロビジョンされた対称登録者キーは、登録者と、これらのエンティティの相互認証のためのＭ２Ｍ登録機能（ＭＥＦ）とに事前プロビジョンされる対称キーである。同様に、証明書ベースの機構または未加工公開キーが、登録者において、およびＭＥＦにおいてプロビジョンされ得る。登録者およびＭＥＦは、証明書内の公開検証キーを信頼する前に、互いの証明書の正当性を確認するものとする。セキュリティハンドシェイク内で、Ｍ２Ｍ登録機能は、その秘密署名キーを使用して、セッションパラメータのデジタル署名を作成し、登録者は、Ｍ２Ｍ登録機能の公開検証キーを使用して、デジタル署名を検証する。そして、役割が逆転させられ、登録者が、デジタル署名を作成し、Ｍ２Ｍ登録機能が、それを検証する。代替として、ＧＢＡベースのプロビジョニング機構が使用される。この場合、ＭＥＦの役割は、ＧＢＡブートストラップサーバ機能（ＢＳＦ）によって果たされる。このフレームワークは、登録者およびＭＥＦ（ＧＢＡ ＢＳＦでもある）を認証するために、３ＧＰＰまたは３ＧＰＰ２対称キーを使用する。詳細は、３ＧＰＰ ＴＳ ３３．２２０および３ＧＰＰ２Ｓ．Ｓ０１０９−Ａによって規定される。

登録者およびＭ２Ｍ登録機能は、エンティティがそれ自体を他方のエンティティに認証するために使用するであろうブートストラップ証明書を事前プロビジョンされる。この事前プロビジョニングのための機構は、デバイスマネージャ機能を使用して、またはＧｌｏｂａｌ Ｐｌａｔｆｏｒｍによって規定されるような信頼されるサービスマネージャ（ＴＳＭ）等の機構を使用して、工場で自動化され、管理者によって行われる。Ｋｐｓａと称される「Ｍ２Ｍセキュリティ確立のためのプロビジョンされた証明書」およびその関連付けられた識別子ＫｐｓａＩｄと、Ｋｍと称される「マスタ証明書」およびその関連付けられた「マスタ証明書識別子」ＫｍＩｄとを確立するプロセスは、ｏｎｅＭ２ＭのためのＴＳ−０００３仕様内の第８．３．１．２節で説明されるような機構に従う。Ｋｍおよび／またはＫｐｓａが生成されると、それらは、Ｅ２Ｅ証明書を生成するために「マスタ証明書」として使用され得る。仕様は、以下を行う機構を説明する：ブートストラップ証明書構成、ブートストラップ命令構成、ブートストラップ登録ハンドシェイク、登録キー生成、およびアソシエーションセキュリティハンドシェイクプロシージャへの統合。本開示では、「エンドツーエンド証明書の生成」と呼ばれる、追加のプロセスを追加することを提案している。

出願人は、少なくとも以下のパラメータを提供することによって、登録標的またはＭＡＦにエンドツーエンド証明書を生成する能力を提供する機構を用いて、「登録段階」を増進することを提案している：コンテンツ情報、標識、およびソルト。コンテンツ情報は、登録標的に、生成されるべき証明書のタイプ、エンドツーエンド証明書を生成することができるために従うべき機構または規格等についての十分な情報を提供する。証明書の例示的タイプは、エンドツーエンドメッセージ認証証明書、エンドツーエンドデータセキュリティ証明書、証明書が公開キーであり得るか、または対称キーであり得るかについての情報、キーの長さ、従われるべきアルゴリズム／プロトコル等であり得る。標識は、ＲＦＣ５８０９またはＲＦＣ５２４６もしくはＲＦＣ５７０５によって説明されるような使用法、または任意の他の標準化キー導出機能およびキー拡張に基づいて、これらの証明書の生成に使用される必要な情報を提供する。コンテキストインフォおよび標識は、登録標的に、登録者によって直接提供され得るか、またはＭＥＦによって提供され得る。ソルトは、キー生成機構の一部として使用されるランダム値である。好ましいアプローチは、登録段階の一部として、登録者が初期メッセージ中にソルトを登録標的に提供することである。ソルトはまた、登録者と登録標的との間の初期通信に基づいて計算されるハッシュ値であり得る。

「エンドツーエンド証明書の生成」プロセスの一部として、登録者および登録標的は、エンドツーエンドマスタキーＫｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｍａｓｔｅｒを生成するためのマスタキーとしてＫｐｓａ＿ＡＥ＿ＣＳＥを使用して、エンドツーエンド証明書を生成する。代替として、標的がＭＡＦである場合、Ｋｍが、エンドツーエンドマスタキーを生成するためのマスタキーとして使用されるであろう。ＲＦＣ５８０９を使用するエンドツーエンドキー生成の実施例が、以下に提供される：
Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｍａｓｔｅｒ＝ＨＭＡＣ−Ｈａｓｈ（Ｓａｌｔ，Ｋｐｓａ＿ＡＥ＿ＣＳＥ）
Ｔ（０）＝空の文字列（ゼロ長）
Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｍｓｇ＿ａｕｔｈ＝Ｔ（１）＝ＨＭＡＣ−Ｈａｓｈ（Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｍａｓｔｅｒ，Ｔ（０）｜”Ｅ２Ｅ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｋｅｙ”｜０ｘ０１）
Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｍｅｓｓａｇｅ＿ｃｏｎｆｉｄｅｎｔｉａｌｔｉｙ＝Ｔ（２）＝ＨＭＡＣ−Ｈａｓｈ（Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｍａｓｔｅｒ，Ｔ（１）｜”Ｅ２Ｅ Ｍｅｓｓａｇｅ Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ Ｋｅｙ”｜０ｘ０２）
同様に、データ機密性およびデータ完全性キーが、登録標的ならびに登録者によって生成される。このプロセスは、登録者と登録標的との間で共有される固有のＥｎｒｏｌｌｅｅ−ＥｎｒｏｌｍｅｎｔＴａｒｇｅｔ＿Ｋｅ２ｅ＿ｍａｓｔｅｒ（例えば、ＡＥおよびＣＳＥ特定のエンドツーエンドキー）に基づいて、各登録者および関連付けられた登録標的によって繰り返される。ある場合、複数の登録標的によって共有され、ＭＥＦによって登録標的にプロビジョンされ得る１つのみのＫｅ２ｅ＿ｍａｓｔｅｒが、登録者のために生成され、そして、それは、エンドエンティティの各々のための固有のエンドツーエンドキーを生成し得る。

ある場合において、Ｋｐｓａ／Ｋｍは、Ｋｅ２ｅ＿ｍａｓｔｅｒとして使用され得、上記で説明されるプロセスは、各エンドツーエンドセキュリティ保護、すなわち、メッセージ認証、メッセージ完全性、データ完全性、およびデータ機密性のための固有のキーを生成するために使用される。

ある他の場合では、単一のキーのみ、すなわち、ＫｐｓａまたはＫｍが、メッセージ認証、メッセージ、メッセージ機密性、データ完全性、データ機密性、キー生成キー等に使用される。

ある他の場合では、セッションキーは、ＫｐｓａまたはＫｍから生成され、そして、それは、エンドツーエンドセキュリティ保護機構の各々、すなわち、メッセージ認証、メッセージ機密性、データ完全性、およびデータ機密性のための固有のキーを生成するために使用される。

ある他の場合では、ＫｐｓａまたはＫｐｍから生成される単一のセッションキーのみが、エンドツーエンドメッセージ認証、機密性、データ完全性、およびデータ機密性を提供するために使用される。

ある他の場合では、ＭＥＦは、Ｋｅ２ｅ＿ｍａｓｔｅｒまたは以下のキーの組もしくは一部のいずれかを登録標的またはＭＡＦにプロビジョンし得る：Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｍｓｇ＿ａｕｔｈ、Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｍｓｇ＿ｃｏｎｆ、Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｄａｔａ＿ａｕｔｈ、Ｋｅ２ｅ＿ＡＥ＿ＣＳＥ＿ｄａｔａ＿ｃｏｎｆ、ならびにＫｅ２ｅ＿ｋｅｙ＿ｇｅｎｅｒａｔｉｏｎ。

図１５Ａ−Ｂは、ＡＥとのリソース表現関連付けと、それぞれ、ホップ毎のセキュリティ証明書ならびにエンドツーエンド証明書という属性を有する、＜ｓｅｃｕｒｉｔｙＰａｒａｍｅｔｅｒｓ＞リソース構造とを提供する。図１６Ａ−Ｃは、以前に説明された、エンティティプロファイル、デバイスプロファイル、およびセキュリティプロファイルのリソース表現を描写する。

（Ｅ２Ｅ認証段階）
Ｅ２Ｅ認証段階中、キー生成段階中に以前に決定されたスコープに基づいて、認証は、アプリケーション、サービス、セッション、または他の層において行われ得る。さらに、認証は、直接モードで、または委託モードを使用して行われ得る。

（直接モードを使用するサービス層におけるＥ２Ｅ認証）
図７Ａ−Ｂは、Ｅ２Ｅ認証を図示し、ＡＥ１ ６０２は、ＣＳＥ３ ５０２上でホストされる遠隔リソースへの更新動作を要求する。図は、直接モードを使用するサービス層Ｅ２Ｅ認証を図示する。図示される機構は、ｏｎｅＭ２Ｍ仕様に非常に密接に従う。メッセージング詳細：
図７Ａ−Ｂのステップ１では、ＡＥ１ ６０２が、Ｋｐｓａ１を使用して、ＣＳＥ１ ６０４とのＤＴＬＳ接続を設定する。

図７Ａ−Ｂのステップ２では、ＡＥ１ ６０２が、ＣＳＥ３ ５０２上でホストされるリソースにＵＰＤＡＴＥ動作を行う要求を送信する。ＡＥ１ ６０２は、上記で説明されるような第三者証明書請求段階中、以前に取得されたＥ２Ｅ認証キー（Ｋｅ２ｅ＿ＣＳＥ３＿ＡＥ１＿ｍｓｇ＿ａｕｔｈ）を使用して、メッセージ認証コード（ＭＡＣ）を作成する。ＭＡＣは、提供されたスコープに基づいて作成され、使用されるべきアルゴリズム、元の認証を提供するために使用されるべきパラメータ、再生保護等を含む。ＭＡＣは、要求メッセージの一部として提供され、ＤＴＬＳトンネルを使用して保護される。

図７Ａ−Ｂのステップ３では、ｏｎｅＭ２Ｍ仕様によって規定される機構を使用して、要求を処理する。

図７Ａ−Ｂのステップ４では、要求が処理されると、応答がＡＥ１に送信される。

図７Ａ−Ｂのステップ５では、ＣＳＥ１ ６０４が、Ｋｐｓａ２を使用して、次のホップＣＳＥ２ ７０２とのＤＴＬＳ接続を作成する。

図７Ａ−Ｂのステップ６では、ＣＳＥ１ ６０４が、配信リソース要求メッセージを作成し、ＡＥ１ ６０２によって含まれたＭＡＣとともに、それを次のホップＣＳＥ２ ７０２に転送する。

図７Ａ−Ｂのステップ７では、ＣＳＥ２において要求を処理する。ＣＳＥ２は、ＣＳＥ３のＵＲＩおよび他の関連情報を見出すために、配信要求データを処理する。

図７Ａ−Ｂのステップ８では、応答をＣＳＥ１ ６０４に送信する。

図７Ａ−Ｂのステップ９では、ＣＳＥ２ ７０２が、Ｋｐｓａ３を使用して、ＣＳＥ３ ５０２とのＤＴＬＳ接続を設定する。

図７Ａ−Ｂのステップ１０では、ＣＳＥ２ ７０２が、配信リソース要求メッセージを作成し、ＡＥ１によって含まれたＭＡＣとともに、それを次のホップＣＳＥ３に転送する。

図７Ａ−Ｂのステップ１１では、ＣＳＥ３ ５０２が、メッセージ発信を検証する。

図７Ａ−Ｂのステップ１２では、ＣＳＥ３ ５０２が、ＡＥ１ ６０２に関連付けられたメッセージに含まれたＭＡＣを検証する。ＣＳＥ３ ５０２がＥ２Ｅ証明書（ＫｐｓａＥ２Ｅ）を有していなかった場合、ＣＳＥ３ ５０２は、ＴＴＰからマスタキーを取得し、そして、ＡＥ１の識別に基づいて、Ｅ２Ｅキーを生成する。ＣＳＥ３ ５０２はまた、メッセージがパラメータ（例えば、ノンス／タイムスタンプ）を使用して再生されていないこと、およびＡＥ１ ６０２が元のメッセージの発信者として検証されていること、ならびにＭＡＣがＡＥ１によって実際に計算されて挿入されたことも検証する。

図７Ａ−Ｂのステップ１３では、要求への応答が、ＣＳＥ３ ５０２によってＣＳＥ２ ７０２に戻るように提供される。

代替として、ステップ４および８のメッセージは、１３までのステップが実行された後に送信され得る。ＣＳＥ２ ７０２がＣＳＥ３ ５０２から応答を受信する（メッセージ１３）と、ＣＳＥ２は、応答をＣＳＥ１ ６０４に送信し（ステップ８のメッセージ）、そして、ＣＳＥ１は、応答をエンティティに送信する（ステップ４のメッセージ）。

図７Ａ−Ｂに図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図７Ａ−Ｂに図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図７Ａ−Ｂに図示されるステップを行う。図７Ａ−Ｂに図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

（委託モードを使用するサービス層におけるＥ２Ｅ認証）
図８Ａ−Ｂは、委託モードアプローチを使用する、サービス層におけるＥ２Ｅ認証を図示する。図７Ａ−Ｂに関して説明されるような直接モードとここで説明されるアプローチとの間の主要な差異は、ＣＳＥ１ ６０４（ホスティングＣＳＥ）がＡＥ１ ６０２の代わりにＥ２Ｅ認証を行うことである。ＣＳＥ１ ６０４は、ＡＥ１ ６０２の代わりに、上記で説明される第三者証明書請求プロセスを行う。さらに、わずかに異なる実施形態は、スコープ情報が、ＭＡＣの代わりにＪＳＯＮウェブ署名（ＪＷＳ）／ＪＳＯＮウェブトークン表現の使用を示唆することである。使用されるパラメータは、ＭＡＣ計算に使用されるものに類似し得、表現は、ＪＷＴに基づき、上記で説明されるセキュリティプロビジョニングプロセス中に合意される。メッセージング詳細は、以下のメッセージ以外、図７Ａ−Ｂに関して説明されるものに非常に類似する：
図８Ａ−Ｂのステップ１では、要求メッセージは、ＭＡＣを含まず、したがって、ＡＥ１ ６０２は、Ｅ２Ｅ様式で認証されることができない。

図８Ａ−Ｂのステップ３−５は、以前に説明されたシナリオに類似する。

図８Ａ−Ｂのステップ６では、エンドエンティティＣＳＥ３ ５０２がＣＳＥ１ ６０４を認証することができるために、ＣＳＥ１ ６０４は、ＭＡＣに類似するＪＷＳを作成する。ここでは、ＣＳＥ１ ６０４は、ＡＥ１ ６０２の代わりに認証を行うことを委託されている。ＪＷＳは、要求メッセージ内に組み込まれる。ＪＷＳは、ＴＴＰから取得されたＫｅ２ｅ＿ＡＥ１＿ＣＳＥ１＿ｍｓｇ−ａｕｔｈを使用して、計算され得る。

図８Ａ−Ｂのステップ７−９は、以前に説明されたシナリオに類似する。

図８Ａ−Ｂのステップ１０では、ＪＷＳを含む要求メッセージが、ホップ毎の様式でＣＳＥ３ ５０２に転送される。

図８Ａ−Ｂのステップ１１では、ＣＳＥ３ ５０２は、それがメッセージの標的であることを検証する。

図８Ａ−Ｂのステップ１２では、ＣＳＥ３ ５０２は、元の要求がＡＥ１ ６０２の代わりにＣＳＥ１ ６０４によって送信されたことを検証する。ＪＷＳを検証することによって、発信者が実際にＣＳＥ１ ６０４であったこと、およびそれが再生されなかったことを検証する。

図８Ａ−Ｂに図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図８Ａ−Ｂに図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図８Ａ−Ｂに図示されるステップを行う。図８Ａ−Ｂに図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１７は、２つのエンティティＡＥ２とＣＳＥ１ ６０４との間の対称キー機構を用いたエンドツーエンドメッセージ認証および完全性チェックを図示する実施形態を説明し、２つのエンティティは、信頼される、またはあまり信頼できない、もしくは信頼できない中間ホップを横断して互いから複数のサービス層ホップだけ離れている。クライアントアプリケーション（ＡＥ２）は、別のアプリケーションエンティティ（ＡＥ１ ６０２）のリソースに更新動作を行うことを望む。リソースがホスティングＣＳＥ（ＣＳＥ１ ６０４）上でホストされるので、ＡＥ２は、リソースの場所を事前プロビジョンされているか、またはリソース場所（／ＣＳＥ１／Ｒ−ＩＤ）を発見するために発見サービスを使用する。ＣＳＥ１ ６０４は、認可エンティティのみが、ＡＥ１リソースに作成、読み出し、更新、削除、または通知動作のうちのいずれかを行うことができることを確実にすることを望む。ＣＳＥ１ ６０４が、認可エンティティのみがＣＲＵＤ動作を行うことできることを確実にできるために、ＣＳＥ１ ６０４は、メッセージのソースが認証されていること、およびメッセージの発信者によるキーの保有を検証することによって、メッセージが完全性保護されることを要求し得る。メッセージの作成に備えて、ＡＥ２は、ＴＴＰから適切なメッセージ認証キーＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈを取得する必要があるか、またはそれにプロビジョンされた、もしくは上記で説明された「第三者証明書請求プロセス」を使用するブートストラッピングプロセスを使用して生成されたエンドツーエンドマスタキーＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍａｓｔｅｒからそのキーを生成する必要があるかのいずれかである。キーに加えて、コンテキスト情報、使用法情報、および標識が、取得されるか、生成されるか、またはＡＥ２にプロビジョンされ、それらは、ＡＥ２が正しい認証タグを生成することができるために必要とされ、正しい認証タグは、ＡＥ２のメッセージの真正性および完全性を検証するためにＣＳＥ１ ６０４によって使用され得る。ＡＥ２は、エンドツーエンドメッセージ認証を行うために、キー記憶部から適切な証明書を選択する。

図１７のステップ１では、ＡＥ２が、それ自体とＣＳＥ２ ７０２との間に（Ｄ）ＴＬＳ接続を設定するために、Ｋｐｓａ＿ＡＥ２＿ＣＳＥ２を使用する。接続確立プロセスは、リリース１のためのＴＳ−０００３ ｏｎｅＭ２Ｍ仕様に説明される機構に従う。

図１７のステップ２では、ＡＥ１ ６０２が、ＣＳＥ１ ６０４上にホストされる（／ＣＳＥ／Ｒ−ＩＤとして識別される）ＡＥ１のリソースに「更新」動作を行うために使用されるｏｎｅＭ２Ｍ「要求」メッセージを生成する。要求メッセージは、Ｍ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤ１によって固有に識別される。ＡＥ２は、ＯｒｉｇｉｎＤａｔａとも称される、メッセージヘッダ情報を使用して、認証タグ（Ａｕｔｈ＿Ｔａｇ）またはメッセージ認証コード（ＭＡＣ）を生成する。代替として、メッセージ全体が、Ａｕｔｈ＿Ｔａｇを作成するための入力として使用される。以下の情報が、Ａｕｔｈ＿Ｔａｇ生成の一部として使用され得る：
Ａｕｔｈ＿Ｔａｇ＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ，”Ｍｅｓｓａｇｅ Ｈｅａｄｅｒ”｜Ｎｏｎｃｅ｜Ｔｉｍｅ）
代替として、Ａｕｔｈ＿Ｔａｇ＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ，”Ｅｎｔｉｒｅ Ｍｅｓｓａｇｅ”｜Ｎｏｎｃｅ｜Ｔｉｍｅ） ノンス（Ｎｏｎｃｅ）、時間（Ｔｉｍｅ）、または両方のいずれか一方が、Ａｕｔｈ＿Ｔａｇの生成に含まれ得る。ある場合、各セッションにとって固有と見なされるＭ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤが、各メッセージとともに含まれるので、それらの両方が除外され得る。Ａｕｔｈ＿Ｔａｇを計算するために使用されるメッセージ全体を使用することが好ましく、代替として、メッセージヘッダが、Ａｕｔｈ＿Ｔａｇを生成するために使用され得る。しかしながら、メッセージ内のあるコンポーネントが、ＣＳＥ２ ７０２等の中間エンティティによって変更され得る場合、メッセージの真正性および意図を保証するために使用されることができる、メッセージのこれらのコンポーネントのみが使用され得る。完全性保護される必要があるメッセージの絶対不可欠なコンポーネントは、フィールドから「ｆｒ」、フィールドへ「ｔｏ」、動作フィールド「ｏｐ」、リソースｉｄ「ｒｅｓ−ｉｄ」、「ｔｏ」フィールドと異なる場合、セッション識別子「Ｍ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤ」であろう。メッセージに「ｄａｔａ」が含まれる場合、これも完全性保護され得る。前述のように、好ましいアプローチは、メッセージ全体を完全性保護することであるが、ある実装では、コンポーネントのうちのいくつかは、ルーティング目的で中間エンティティによって合法的に変更され得、そのような場合において、コンポーネントが中間エンティティによって変更されないが、同時に、ＡＥ２の要求の真正性ならびに完全性を提供できる、これらのコンポーネントのみが、確実にされる必要がある。

図１７のステップ３では、ＡＥ２が、Ａｕｔｈ＿Ｔａｇを作成するために使用されたセキュリティ属性とともにＡｕｔｈ＿Ｔａｇを搬送するために、ｏｎｅＭ２Ｍメッセージングのために修正され得る、ＪＳＯＮベースの表現、ＪＳＯＮウェブ署名を作成する。ＪＷＳは、以下のセキュリティ属性を含むであろう：この場合、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ−ＩＤである証明書またはキーを識別するために使用される証明書ＩＤである「ｃｒｅｄ−ｉｄ」、Ａｕｔｈ＿Ｔａｇを計算するために使用されるアルゴリズム「ａｌｇ」、「ＨＭＡＣ−ＳＨＡ−２５６」、データとともにメッセージまたはメッセージヘッダを含むペイロード「ｐａｙｌｏａｄ」、Ａｕｔｈ＿Ｔａｇ／ＭＡＣである署名「ｓｉｇ」。代替として、Ｂａｓｅ６４の代わりに簡潔バイナリオブジェクト表現（ＣＢＯＲ）ベースの表現が、ＣＢＯＲオブジェクト署名および暗号化規格で説明される機構によって使用され得る。ｏｎｅＭ２Ｍメッセージ「Ｒｅｑｕｅｓｔ」
図１７のステップ４では、既存の（Ｄ）ＴＬＳ接続がＣＳＥ１ ６０４とＣＳＥ２ ７０２との間に存在しない場合、（Ｄ）ＴＬＳ接続が、対称キーとしてＫｐｓａ＿ＣＳＥ２＿ＣＳＥ１を使用して、ｏｎｅＭ２Ｍ仕様の通りにＣＳＥ１ ６０４とＣＳＥ２ ７０２との間に確立される。

図１７のステップ５では、ＡＥ２によって作成されるメッセージが、ＣＳＥ１ ６０４に転送される。署名に使用されたアルゴリズムが公開キーベースの機構であった場合、ＣＳＥ２ ７０２は、メッセージをＣＳＥ１ ６０４に転送する前に、それを認証することが可能であり得るが、ここでは、対称キーが使用される場合、メッセージの認証は、ＡＥ２とＣＳＥ２ ７０２との間に存在する信頼に基づいて、および（Ｄ）ＴＬＳ接続に基づいて確立されたセキュリティアソシエーションに基づいて示唆され、メッセージは、信頼できるＡＥ２から着信することが予期される。ＣＳＥ２ ７０２は、主要メッセージヘッダを修正することなく、メッセージをＣＳＥ１ ６０４に転送する。メッセージヘッダがＣＳＥ２ ７０２によって変更される場合において、ＣＳＥ２ ７０２は、メッセージヘッダのコピーを作製し、Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓとともにデータの一部として含まれる。ＡＥ２がＳｅｃ−Ａｔｔｒｉｂｕｔｅｓ（ＪＷＳ）を作成するためにメッセージ全体を使用した場合において、ＣＳＥ２ ７０２は、ＣＳＥ１ ６０４に転送する前に、ヘッダおよびＳｅｃ−Ａｔｔｒｉｂｕｔｅｓ（ＪＷＳ）とともにメッセージ全体をデータペイロード部分の中へコピーする。このメッセージは、ステップ４において設定されたセキュアな（Ｄ）ＴＬＳ接続を経由して、ＣＳＥ２ ７０２によってＣＳＥ１ ６０４に送信される。

図１７のステップ６では、ＣＳＥ１ ６０４は、それがメッセージの標的であったかどうかを検証する。Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓ（ＪＷＳ）を使用して、正しい証明書を識別し、セキュアなキー記憶部（例えば、ＳＩＭカード等のセキュアな要素）からそれをフェッチし、適切なコンテキスト情報および使用法パラメータを決定するために、証明書ＩＤ（ｃｒｅｄ−ｉｄ）を使用する。セキュリティのタイプ（署名）、関与するエンティティ等、および使用法（アルゴリズム、ノンスの可用性等）を決定するコンテキスト情報に基づいて、メッセージが特性の正しい組を有するかどうかを検証し、そして、最初にＡＥ２ １１０２によって使用されたメッセージ全体であり得るメッセージ、またはメッセージのメッセージヘッダもしくはメタデータとともに、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈキーを使用し、コンテキスト情報とともに存在し得るノンスを使用し、この場合、偶然ＨＭＡＣ−ＳＨＡ−２５６であり、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇを生成する、ＪＷＳ内で識別される「ａｌｇ」への入力としてパラメータを提供する。ＣＳＥ１ ６０４は、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇが、ＪＷＳ内に含まれるＡｕｔｈ＿Ｔａｇと同一であるかどうかを検証し、該当する場合、ＡＥ２のメッセージが認証されている。そして、ＣＳＥ１ ６０４は、ＡＥ２ １１０２がＡＥ１リソースに「更新」動作を行う権限を与えられているかどうかを確認するためにチェックする。

図１７のステップ７では、ＡＥ２ １１０２が「更新」動作を行う権限を与えられている場合、ＣＳＥ１ ６０４が、Ｒ−ＩＤによって識別されるＡＥ１リソースを更新する。ＣＳＥ１ ６０４は、応答メッセージを作成し、異なるＡｕｔｈ＿Ｔａｇ２を生成するために、図１のステップ２でＡＥ２によって使用されるプロシージャに類似するプロセスを使用する。毎回、新しいノンスを使用し、ＪＷＳの一部としてそれを含み、既存のノンスを再利用しないことが推奨される。全てのＳｅｃ−Ａｔｔｒｉｂｕｔｅｓ（例えば、ノンス、Ａｕｔｈ−Ｔａｇ２、証明書ＩＤ、メッセージ、またはメッセージのメッセージヘッダもしくはメタデータ）が、ＪＷＳ２を作成するために含まれる。

図１７のステップ８では、既存の（Ｄ）ＴＬＳ接続がＡＥ１ ６０２とＣＳＥ１ ６０４との間に存在しない場合、ｏｎｅＭ２Ｍ技術仕様ＴＳ−０００３リリース１に基づいて、共有対称キーＫｐｓａ＿ＡＥ１＿ＣＳＥ１を使用することによって、新しいものが作成される。

図１７のステップ９では、ＣＳＥ１ ６０４が、ＡＥ１のリソース「Ｒ−ＩＤ」への「更新」を示す、「通知」メッセージをＡＥ１ ６０２に送信する。このメッセージは、図１７のステップ８において設定されたセキュアな（Ｄ）ＴＬＳ接続を経由して送信される。

図１７のステップ１０では、図１７のステップ７に説明されるように作成された、応答メッセージを作成した後、ＣＳＥ１ ６０４が、ステップ４において確立されたセキュアな（Ｄ）ＴＬＳ接続を経由して、メッセージをＣＳＥ２ ７０２に送信する。そのような接続が存在しない場合、図１７のステップ４において作成されたものと同様に、新しい（Ｄ）ＴＬＳ接続が作成される必要があり得る。メッセージ１０は、図１７のステップ８と並行して送信され得るが、ある重要な場合において、ステップ８が、図１７のステップ１０より早く行われる。

図１７のステップ１１では、ＣＳＥ２ ７０２が、ＪＷＳ内のデジタル署名の正当性を確認することによって、公開キー機構がＪＷＳを生成するために使用された場合に、真正性／完全性について、ＣＳＥ１ ６０４から受信されるメッセージを検証し得る。対称キーイングが使用されているので、ＣＳＥ２ ７０２は、メッセージがセキュアな（Ｄ）ＴＬＳ接続を経由して受信されたので、示唆された信頼を使用し、図１７のステップ１において設定されたセキュアな（Ｄ）ＴＬＳ接続を経由してメッセージをＡＥ２ １１０２に転送する。上記で説明されるように、有効（Ｄ）ＴＬＳ接続が存在しない場合、新しい（Ｄ）ＴＬＳ接続が、Ｋｐｓａ＿ＡＥ２＿ＣＳＥ２対称キーを使用して、かつｏｎｅＭ２Ｍ技術仕様ＴＳ−０００３リリース１で説明される機構を使用して、ＣＳＥ２ ７０２とＡＥ２ １１０２との間に確立される必要がある。

図１７のステップ１２では、ＡＥ２ １１０２が、ＪＷＳ内のＡｕｔｈ＿Ｔａｇ２を検証し、図１７のステップ６で説明されるような類似機構を使用して、メッセージを認証する。使用されるセキュリティ属性は、ステップ６のものと異なるであろうが、プロセスは、同一であろう。

図１７に図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１７に図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１７に図示されるステップを行う。図１７に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１８は、互いから複数のサービス層ホップ離れている２つのエンティティＡＥ２ １１０２とＣＳＥ１ ６０４との間の対称キー機構を用いたエンドツーエンドメッセージ認証および完全性チェックの両方、さらにメッセージ機密性を図示する実施形態を説明し、２つのエンティティは、信頼される、またはあまり信頼できない、もしくはさらに信頼できない中間ホップを横断している。クライアントアプリケーション（ＡＥ２ １１０２）は、別のアプリケーションエンティティ（ＡＥ１ ６０２）のリソースに更新動作を行うことを望む。リソースがホスティングＣＳＥ（ＣＳＥ１ ６０４）上でホストされるので、ＡＥ２ １１０２は、リソースの場所を事前プロビジョンされているか、またはリソース場所（／ＣＳＥ１／Ｒ−ＩＤ）を発見するために発見サービスを使用する。ＣＳＥ１ ６０４は、認可エンティティのみが、ＡＥ１リソースに作成、読み出し、更新、削除、または通知動作のうちのいずれかを行うことができることを確実にすることを望む。ＣＳＥ１ ６０４が、認可エンティティのみがＣＲＵＤ動作を行うことできることを確実にできるために、ＣＳＥ１ ６０４は、メッセージのソースが認証され、メッセージの発信者によるキーの保有を検証することによって、メッセージが完全性保護されることを要求し得る。加えて、データおよびメッセージングは、機密性保護されることを要求される。メッセージの作成に備えて、ＡＥ２ １１０２は、ＴＴＰから適切なメッセージ認証およびメッセージ機密性キー、すなわち、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈおよびＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ｃｏｎｆを取得する必要があるか、またはそれにプロビジョンされた、もしくは上記で説明された「第三者証明書請求プロセス」を使用するブートストラッピングプロセスを使用して生成された、エンドツーエンドマスタキーＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍａｓｔｅｒからキーを生成する必要があるかのいずれかである。代替として、単一のＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆが、認証暗号化および関連付けられたデータ（ＡＥＡＤ）ベースの暗号化機構（例えば、ＡＥＳ−ＣＣＭ、ＡＥＳ−ＧＣＭ）を使用して、メッセージ認証ならびにメッセージ機密性の両方のために使用され得る。キーに加えて、ＡＥ２ １１０２が、ＡＥ２のメッセージの真正性および完全性を検証するためにＣＳＥ１ ６０４によって使用され得る正しい認証タグを生成することができるために必要とされるコンテキスト情報、使用法情報、および標識が、取得されるか、生成されるか、またはＡＥ２ １１０２にプロビジョンされる。そして、適切なアルゴリズム、動作しているモード、ならびに初期化ベクトル（ＩＶ）の要件等を決定するための機密性に対して、ＡＥ２ １１０２は、エンドツーエンドメッセージ認証およびメッセージ機密性を行うためにキー記憶部から適切な証明書を選択し、したがって、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆキーが選択される。

図１８のステップ１では、ＡＥ２ １１０２が、それ自体とＣＳＥ２ ７０２との間に（Ｄ）ＴＬＳ接続を設定するために、Ｋｐｓａ＿ＡＥ２＿ＣＳＥ２を使用する。接続確立プロセスは、リリース１のためのＴＳ−０００３ｏｎｅＭ２Ｍ仕様に説明される機構に従う。

図１８のステップ２では、ＡＥ１ ６０２が、ＣＳＥ１ ６０４上にホストされる（／ＣＳＥ／Ｒ−ＩＤとして識別される）ＡＥ１のリソースに「更新」動作を行うために使用されるｏｎｅＭ２Ｍ「要求」メッセージを生成する。要求メッセージは、Ｍ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤ１によって固有に識別される。ＡＥ２ １１０２は、ＯｒｉｇｉｎＤａｔａとも称されるメッセージヘッダ情報を使用して、認証タグ（Ａｕｔｈ＿Ｔａｇ）またはメッセージ認証コード（ＭＡＣ）を生成する。代替として、メッセージ全体が、Ａｕｔｈ＿Ｔａｇを作成するための入力として使用される。前述のように、好ましいアプローチは、メッセージ全体を完全性保護することであるが、ある実装では、コンポーネントのうちのいくつかは、ルーティング目的で中間エンティティによって合法的に変更され得、そのような場合において、コンポーネントが中間エンティティによって変更されず、同時に、ＡＥ２の要求の真正性ならびに完全性を提供できる場合、これらのコンポーネントのみが、確実にされる必要がある。ｏｎｅＭ２Ｍ層ルーティングに使用される必要があるメッセージまたはメッセージヘッダもしくはメタデータは、暗号化されず、関連付けデータ（ＡＡＤ）として分類される。ＡＡＤは、完全性保護され得る。メッセージヘッダまたはメタデータは、「ＡＡＤ」値を割り当てられるための良好な候補である。

Ａｕｔｈ＿Ｔａｇ＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆ，ＡＡＤ｜Ｎｏｎｃｅ｜Ｔｉｍｅ）
ＡＡＤは、メッセージヘッダ全体を割り当てられ得るか、または代替として、ＡＡＤは、メッセージヘッダまたはメッセージのメタデータの一部として割り当てられ得る。

ノンス、時間、または両方のいずれかが、Ａｕｔｈ＿Ｔａｇの生成に含まれ得る。ある場合、各セッションに対して固有と見なされるＭ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤが、各メッセージとともに含まれるので、それらの両方が除外され得る。Ａｕｔｈ＿Ｔａｇを計算するために使用されるべきメッセージ全体を使用することが好ましく、代替として、メッセージヘッダが、Ａｕｔｈ＿Ｔａｇを生成するために使用され得る。しかしながら、メッセージ内のあるコンポーネントが、ＣＳＥ２ ７０２等の中間エンティティによって変更され得る場合、メッセージの真正性および意図を保証するために使用されることができる、メッセージのこれらのコンポーネントのみが使用され得る。完全性保護される必要があるメッセージの絶対不可欠なコンポーネントは以下であろう：フィールドから「ｆｒ」、フィールドへ「ｔｏ」、動作フィールド「ｏｐ」、リソースｉｄ「ｒｅｓ−ｉｄ」、「ｔｏ」フィールドと異なる場合、セッション識別子「Ｍ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤ」。データペイロードを含むメッセージの残りの部分は、コンテキスト情報および使用法パラメータ（例えば、暗号化アルゴリズム、暗号化のモード、およびＩＶ・・）の通りに暗号化され得る。

ステップ３では、ＡＥ２ １１０２は、Ａｕｔｈ＿Ｔａｇを作成するために使用されたセキュリティ属性ならびに暗号化されたメッセージおよびデータとともにＡｕｔｈ＿Ｔａｇを搬送するために、ｏｎｅＭ２Ｍメッセージングのために修正および適合され得るＪＳＯＮベースの表現、ＪＳＯＮウェブ暗号化表現（ＪＷＥ）を作成する。ＪＷＥは、以下のセキュリティ属性を含むであろう：この場合、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ−ＩＤである証明書またはキーを識別するために使用される証明書ＩＤである「ｃｒｅｄ−ｉｄ」。代替として、別個のメッセージ認証キーならびに別個のメッセージ機密性キーが使用される場合、両方の関連付けられた証明書ＩＤが送信されるべきである。使用されるアルゴリズム「ａｌｇ」、（例として）「ＡＥＳ−ＣＣＭ」、データとともにメッセージまたはメッセージヘッダを含む、ペイロード「ｐａｙｌｏａｄ」、およびＡｕｔｈ＿Ｔａｇ／ＭＡＣである署名「ｓｉｇ」。加えて、使用される初期化ベクトルである「ｉｖ」、および暗号化プロセスに基づく生成された暗号テキストである「ｃｉｐｈｅｒｔｅｘｔ」も、ＪＷＥの一部として含まれる。代替として、Ｂａｓｅ６４の代わりに簡潔バイナリオブジェクト表現（ＣＢＯＲ）ベースの表現が、ＣＢＯＲオブジェクト署名および暗号化規格で説明される機構によって使用され得る。メッセージヘッダならびにＪＷＥとして表されるＳｅｃ−Ａｔｔｒｉｂｕｔｅｓを含む、ｏｎｅＭ２Ｍメッセージ「要求」が生成される。

図１８のステップ４では、既存の（Ｄ）ＴＬＳ接続がＣＳＥ１ ６０４とＣＳＥ２ ７０２との間に存在しない場合、（Ｄ）ＴＬＳ接続が、対称キーとしてＫｐｓａ＿ＣＳＥ２＿ＣＳＥ１を使用して、ｏｎｅＭ２Ｍ仕様の通りにＣＳＥ１ ６０４とＣＳＥ２ ７０２との間に確立される。

図１８のステップ５では、ＡＥ２ １１０２によって作成されるメッセージが、ＣＳＥ１ ６０４に転送される。署名に使用されたアルゴリズムが公開キーベースの機構であった場合、ＣＳＥ２ ７０２は、メッセージをＣＳＥ１ ６０４に転送する前に、それを認証することが可能であり得るが、ここでは、対称キーが使用されるので、メッセージの認証は、ＡＥ２ １１０２とＣＳＥ２ ７０２との間に存在する信頼に基づいて、および（Ｄ）ＴＬＳ接続に基づいて確立されたセキュリティアソシエーションに基づいて示唆され、メッセージは、信頼できるＡＥ２ １１０２から着信することが予期される。ＣＳＥ２ ７０２は、主要メッセージヘッダを修正することなく、メッセージをＣＳＥ１ ６０４に転送する。メッセージヘッダがＣＳＥ２ ７０２によって変更される場合において、ＣＳＥ２ ７０２は、メッセージヘッダのコピーを作製し、Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓとともにデータの一部として含まれる。ＡＥ２ １１０２がＳｅｃ−Ａｔｔｒｉｂｕｔｅｓ（ＪＷＳ）を作成するためにメッセージ全体を使用した場合において、Ａｕｔｈ＿Ｔａｇ１が受信者（例えば、ＣＳＥ１）によって適切に構築されることができるように、全ての必要なメッセージヘッダ情報が保存されるために、ＣＳＥ２ ７０２は、ＣＳＥ１ ６０４に転送する前に、ヘッダおよびＳｅｃ−Ａｔｔｒｉｂｕｔｅｓ（ＪＷＳ）とともにメッセージ全体をデータペイロード部分の中へコピーする。このメッセージは、図１８のステップ４において設定されたセキュアな（Ｄ）ＴＬＳ接続を経由して、ＣＳＥ２ ７０２によってＣＳＥ１に送信される。

図１８のステップ６では、ＣＳＥ１ ６０４は、それがメッセージの標的であったかどうかを検証する。Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓ（ＪＷＳ）を使用して、ＣＳＥ１ ６０４は、正しい証明書を識別し、セキュアなキー記憶部（例えば、ＳＩＭカード等のセキュアな要素）からそれをフェッチし、適切なコンテキスト情報および使用法パラメータを決定するために、証明書ＩＤ（ｃｒｅｄ−ｉｄ）を使用する。別個のキーがメッセージ認証ならびにメッセージ機密性の両方に使用される場合において、両方のキーが、キー記憶部からフェッチされる必要があろう。ＪＷＥ情報「ａｌｇ」ならびに「ｃｒｅｄ−ｉｄ」を使用して、ＣＳＥ１ ６０４は、ＡＥＡＤがセキュリティ保護のために使用されるかどうかを決定することができ、該当する場合、ｃｒｅｄ−ｉｄによって識別される単一の関連付け証明書のみが読み出され得る。セキュリティのタイプ（署名、暗号化）、関与するエンティティ等、および使用法（アルゴリズム、ノンスの可用性等）を決定する、コンテキスト情報に基づいて、メッセージが特性の正しい組を有するかどうかを検証し、ＡＡＤ、ＩＶ、ノンス、および他のパラメータを識別し、「ｃｉｐｈｅｒｔｅｘｔ」を解読するためにＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆキーを使用し、メッセージならびにデータペイロードを含み得る、「ｐｌａｉｎｔｅｘｔ」を抽出する。ＣＳＥ１ ６０４は、メッセージまたはメッセージヘッダもしくはメッセージのメタデータを使用するか、またはＧｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇを計算するためにＡＡＤとして識別されている情報を使用する。ある場合、最初にＡＥ２ １１０２によって送信されたメッセージ全体、またはメッセージヘッダもしくはメッセージのメタデータを使用し、この場合、偶然ＡＥＳ−ＣＣＭであり、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇを生成する、ＪＷＳ内で識別される「ａｌｇ」への入力としてパラメータを提供する、コンテキスト情報とともに存在し得るノンスを使用する。ＣＳＥ１ ６０４は、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇが、ＪＷＳ内に含まれるＡｕｔｈ＿Ｔａｇと同一であるかどうかを検証し、該当する場合、ＡＥ２のメッセージが認証されている。そして、ＣＳＥ１ ６０４は、ＡＥ２ １１０２がＡＥ１ ６０２リソースに「更新」動作を行う権限を与えられているかどうかを確認するようにチェックする。

図１８のステップ７では、ＡＥ２ １１０２が「更新」動作を行う権限を与えられている場合、ＣＳＥ１ ６０４が、Ｒ−ＩＤによって識別されるＡＥ１リソースを更新する。

図１７のステップ８では、既存の（Ｄ）ＴＬＳ接続がＡＥ１ ６０２とＣＳＥ１ ６０４との間に存在しない場合、ｏｎｅＭ２Ｍ技術仕様ＴＳ−０００３リリース１に基づいて、共有対称キーＫｐｓａ＿ＡＥ１＿ＣＳＥ１を使用することによって、新しいものが作成される。

図１８のステップ９では、ＣＳＥ１ ６０４が、ＡＥ１のリソース「Ｒ−ＩＤ」への「更新」を示す、「通知」メッセージをＡＥ１ ６０２に送信する。このメッセージは、ステップ８において設定されたセキュアな（Ｄ）ＴＬＳ接続を経由して送信される。

図１８のステップ１０では、ＣＳＥ１ ６０４が、応答メッセージを作成し、異なるＡｕｔｈ＿Ｔａｇ２、暗号化されたメッセージ、およびＪＷＥを生成するために、図１８のステップ２でＡＥ２ １１０２によって使用されるプロシージャに類似するプロセスを使用する。毎回、新しいノンスおよびＩＶを使用し、ＪＷＳの一部としてそれを含み、既存のノンスを再利用しないことが推奨される。全てのＳｅｃ−Ａｔｔｒｉｂｕｔｅｓ（例えば、ノンス、Ａｕｔｈ−Ｔａｇ２、証明書ＩＤ、ＡＡＤとして識別される、メッセージまたはメッセージヘッダもしくはメッセージのメタデータ、ＩＶ、およびｃｉｐｈｅｒｔｅｘｔ）が、ＪＷＥ２を作成するために含まれ得る。

図１８のステップ１１では、ＣＳＥ１ ６０４が、ステップ４において確立されたセキュアな（Ｄ）ＴＬＳ接続を経由して、メッセージをＣＳＥ２ ７０２に送信する。そのような接続が存在しない場合、図１８のステップ４において作成されたものと同様に、新しい（Ｄ）ＴＬＳ接続が作成される必要があり得る。メッセージ１０は、ステップ８と並行して送信され得るが、ある重要な場合において、図１８のステップ８が、図１８のステップ１０より先に行われる。

図１８のステップ１２では、ＣＳＥ２ ７０２は、ＪＷＳ内のデジタル署名の正当性を確認することによって、公開キー機構がＪＷＳを生成するために使用された場合に、真正性／完全性に対して、ＣＳＥ１ ６０４から受信されるメッセージを検証し得る。対称キーイングがここで使用されているので、ＣＳＥ２ ７０２は、メッセージがセキュアな（Ｄ）ＴＬＳ接続を経由して受信されたので、示唆された信頼を使用し、ステップ１において設定されたセキュアな（Ｄ）ＴＬＳ接続を経由してメッセージをＡＥ２ １１０２に転送する。上記で説明されるように、有効（Ｄ）ＴＬＳ接続が存在しない場合、新しい（Ｄ）ＴＬＳ接続が、Ｋｐｓａ＿ＡＥ２＿ＣＳＥ２対称キーを使用して、かつｏｎｅＭ２Ｍ技術仕様ＴＳ−０００３リリース１で説明される機構を使用して、ＣＳＥ２ ７０２とＡＥ２ １１０２との間に確立される必要がある。

図１８のステップ１３では、ＡＥ２ １１０２が、図１８のステップ６で説明されるような類似機構を使用して、メッセージを解読した後、ＪＷＳ内のＡｕｔｈ＿Ｔａｇ２を検証する。使用されるセキュリティ属性は、図１８のステップ６のものと異なるであろうが、プロセスは、同一であろう。

図１９は、互いから複数のサービス層ホップ離れている２つのエンティティＡＥ２ １１０２とＣＳＥ１ ６０４との間の対称キー機構を用いたエンドツーエンドメッセージ認証および完全性チェックの両方、さらにメッセージ機密性を図示する実施形態を説明し、２つのエンティティは、信頼される、またはあまり信頼できない、もしくはさらに信頼できない中間ホップを横断している。クライアントアプリケーション（ＡＥ２ １１０２）は、別のアプリケーションエンティティ（ＡＥ１ ６０２）のリソースに更新動作を行うことを望む。リソースがホスティングＣＳＥ（ＣＳＥ１ ６０４）上でホストされるので、ＡＥ２ １１０２は、リソースの場所を事前プロビジョンされているか、またはリソース場所（／ＣＳＥ１／Ｒ−ＩＤ）を発見するために発見サービスを使用する。ＣＳＥ１ ６０４は、認可エンティティのみが、ＡＥ１ ６０２リソースに作成、読み出し、更新、削除、または通知動作のうちのいずれかを行うことができることを確実にすることを望む。ＣＳＥ１ ６０４が、認可エンティティのみがＣＲＵＤ動作を行うことできることを確実にできるために、ＣＳＥ１ ６０４は、メッセージのソースが認証され、メッセージの発信者によるキーの保有を検証することによって、メッセージが完全性保護されることを要求し得る。加えて、データおよびメッセージングは、機密性保護されることを要求される。メッセージの作成に備えて、ＡＥ２ １１０２は、ＴＴＰから適切なメッセージ認証およびメッセージ機密性キー、すなわち、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈおよびＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ｃｏｎｆを取得する必要があるか、またはそれにプロビジョンされた、もしくは上記で説明された「第三者証明書請求プロセス」を使用するブートストラッピングプロセスを使用して生成されたエンドツーエンドマスタキーＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍａｓｔｅｒからキーを生成する必要があるかのいずれかである。代替として、単一のＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆが、認証暗号化および関連付けられたデータ（ＡＥＡＤ）ベースの暗号化機構（例えば、ＡＥＳ−ＣＣＭ、ＡＥＳ−ＧＣＭ）を使用して、メッセージ認証ならびにメッセージ機密性の両方のために使用され得る。キーに加えて、ＡＥ２ １１０２が、ＡＥ２のメッセージの真正性および完全性を検証するためにＣＳＥ１ ６０４によって使用され得る、正しい認証タグを生成することができるために必要とされるコンテキスト情報、使用法情報、および標識が、取得される、生成されるか、またはＡＥ２ １１０２にプロビジョンされる。そして、適切なアルゴリズム、動作しているモード、ならびに初期化ベクトル（ＩＶ）の要件等を決定するための機密性に対して、ＡＥ２ １１０２は、エンドツーエンドメッセージ認証およびメッセージ機密性を行うためにキー記憶部から適切な証明書を選択し、したがって、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆキーが選択される。

前のシナリオと異なり、ＡＥ２ １１０２とＣＳＥ２ ７０２との間で（Ｄ）ＴＬＳベースのセキュアな接続確立を行うためのキーが存在しておらず、代わりに、利用可能である証明書が、オブジェクトベースのセキュリティモデルを使用して、サービス層においてＡＥ２ １１０２とＣＳＥ２ ７０２との間のメッセージ認証を提供するために使用される。Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ２＿ｍｓｇ＿ａｕｔｈは、エンドツーエンドキーまたはホップ毎の証明書のいずれかと称され得、いずれにしろ、証明書の使用法およびコンテキストが重要である。使用法およびコンテキスト情報は、どのようにして証明書が使用されるものであるかについて指針を提供する。使用法およびコンテキスト情報は、ＴＴＰから、第三者証明書請求プロセス中に取得またはプロビジョンされ得る。ＴＴＰは、順に、エンティティ登録プロセス中にサービスプロバイダもしくはエンティティから取得された、ＳＰ、ＤＰ、および／またはＥＰに基づいて、適切な使用法およびコンテキスト情報ならびにアソシエーションセキュリティ要件および特徴を取得または推論し得る。機構は、Ｍ２Ｍ加入プロファイル内に含まれる参照リンクを使用することによって、ＩＮ−ＣＳＥ２００２からＳＰ、ＤＰ、および／またはＥＰを取得すべきである。

図１８に図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１８に図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１８に図示されるステップを行う。図１８に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

図１９のステップ１では、ＡＥ２ １１０２は、ホップ毎の認証およびセキュアな通信確立機構を使用しない。ＡＥ１ ６０２は、ＣＳＥ１ ６０４上にホストされる（／ＣＳＥ／Ｒ−ＩＤとして識別される）ＡＥ１のリソースに「更新」動作を行うために使用されるｏｎｅＭ２Ｍ「要求」メッセージを生成する。要求メッセージは、Ｍ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤ１によって固有に識別される。ＡＥ２ １１０２は、ＯｒｉｇｉｎＤａｔａとも称されるメッセージヘッダ情報を使用して、認証タグ（Ａｕｔｈ＿Ｔａｇ）またはメッセージ認証コード（ＭＡＣ）を生成する。代替として、メッセージ全体が、Ａｕｔｈ＿Ｔａｇを作成するための入力として使用される。前述のように、好ましいアプローチは、メッセージ全体を完全性保護することであるが、ある実装では、コンポーネントのうちのいくつかは、ルーティング目的で中間エンティティによって合法的に変更され得、そのような場合において、コンポーネントが中間エンティティによって変更されないが、同時に、ＡＥ２の要求の真正性ならびに完全性を提供できる場合、これらのコンポーネントのみが、確実にされる必要がある。ｏｎｅＭ２Ｍ層ルーティングに使用される必要があるメッセージまたはメッセージヘッダもしくはメタデータは、暗号化されず、関連付けデータ（ＡＡＤ）として分類される。ＡＡＤは、完全性保護され得る。メッセージヘッダまたはメタデータは、「ＡＡＤ」値を割り当てられるための良好な候補である。

Ａｕｔｈ＿Ｔａｇ＝ＨＭＡＣ−ＳＨＡ−２５６（Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆ，ＡＡＤ｜Ｎｏｎｃｅ｜Ｔｉｍｅ）
ＡＡＤは、メッセージヘッダ全体を割り当てられ得るか、または代替として、ＡＡＤは、メッセージヘッダまたはメッセージのメタデータの一部として割り当てられ得る。

ノンス、時間、または両方のいずれかが、Ａｕｔｈ＿Ｔａｇの生成に含まれ得る。ある場合、各セッションに対して固有と見なされるＭ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤが、各メッセージとともに含まれるので、それらの両方が除外され得る。Ａｕｔｈ＿Ｔａｇを計算するために使用されるメッセージ全体を使用することが好ましく、代替として、メッセージヘッダが、Ａｕｔｈ＿Ｔａｇを生成するために使用され得る。しかしながら、メッセージ内のあるコンポーネントが、ＣＳＥ２ ７０２等の中間エンティティによって変更され得る場合、メッセージの真正性および意図を保証するために使用されることができる、メッセージのこれらのコンポーネントのみが使用され得る。完全性保護される必要があるメッセージの絶対不可欠なコンポーネントは、以下であろう：フィールドから「ｆｒ」、フィールドへ「ｔｏ」、動作フィールド「ｏｐ」、リソースｉｄ「ｒｅｓ−ｉｄ」、「ｔｏ」フィールドと異なる場合、セッション識別子「Ｍ２Ｍ−Ｒｅｑｕｅｓｔ−ＩＤ」。データペイロードを含む、メッセージの残りの部分は、コンテキスト情報および使用法パラメータ（例えば、暗号化アルゴリズム、暗号化のモード、およびＩＶ・・）の通りに暗号化され得る。

図１９のステップ２では、ＡＥ２ １１０２が、Ａｕｔｈ＿Ｔａｇを作成するために使用されたセキュリティ属性ならびに暗号化されたメッセージおよびデータとともにＡｕｔｈ＿Ｔａｇを搬送するために、ｏｎｅＭ２Ｍメッセージングのために修正および適合され得るＪＳＯＮベースの表現、ＪＳＯＮウェブ暗号化表現（ＪＷＥ）を作成する。ＪＷＥは、以下のセキュリティ属性」を含むであろう：この場合、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ−ＩＤである証明書またはキーを識別するために使用される証明書ＩＤである「ｃｒｅｄ−ｉｄ。代替として、別個のメッセージ認証キーならびに別個のメッセージ機密性キーが使用される場合、両方の関連付け証明書ＩＤが送信されるべきである。使用されるアルゴリズム「ａｌｇ」、（例として）「ＡＥＳ−ＣＣＭ」、データとともにメッセージまたはメッセージヘッダを含む、ペイロード「ｐａｙｌｏａｄ」、およびＡｕｔｈ＿Ｔａｇ／ＭＡＣである署名「ｓｉｇ」。加えて、使用される初期化ベクトルである「ｉｖ」、および暗号化プロセスに基づく、生成された暗号テキストである「ｃｉｐｈｅｒｔｅｘｔ」も、ＪＷＥの一部として含まれる。代替として、Ｂａｓｅ６４の代わりに簡潔バイナリオブジェクト表現（ＣＢＯＲ）ベースの表現が、ＣＢＯＲオブジェクト署名および暗号化規格で説明される機構によって使用され得る。メッセージヘッダならびにＪＷＥ１として表されるＳｅｃ−Ａｔｔｒｉｂｕｔｅｓを含む、ｏｎｅＭ２Ｍメッセージ「要求」が生成される。

加えて、ＡＥ１ ６０２は、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ２＿ｍｓｇ＿ａｕｔｈを使用し、新しいノンスを生成し、内側Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓ／ＪＷＥ１パラメータを含む要求メッセージ上でＡｕｔｈ＿Ｔａｇ２を生成する。外側Ａｕｔｈ＿Ｔａｇ２は、ＣＳＥ２ ７０２を用いた認証のために使用される。ＡＥ２ １１０２は、その証明書ＩＤ、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ２＿ｍｓｇ＿ａｕｔｈ−ＩＤによって識別可能な関連付けられた証明書Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ２＿ｍｓｇ＿ａｕｔｈとともに提供される、コンテキスト情報および使用法情報の中で提供される指針に基づいて、Ａｕｔｈ＿Ｔａｇ２（ＭＡＣ）を含むＪＷＳ１を生成する。ＡＥ２ １１０２によって作成されるメッセージは、ＣＳＥ１ ６０４に転送される。

図１９のステップ３では、ＣＳＥ２ ７０２が、使用法情報およびコンテキスト情報とともにキー記憶部から証明書ＩＤに基づいて関連付けられた証明書を取得するために、受信されたメッセージ内に含まれるＪＷＳ１情報を使用する。ＣＳＥ２ ７０２は、ノンス、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ２＿ｍｓｇ＿ａｕｔｈ、およびメッセージ／メッセージヘッダを使用して、Ａｕｔｈ＿Ｔａｇを生成し、それをＪＷＳ１内に含まれるＡｕｔｈ＿Ｔａｇと比較し、それらが合致した場合、ＡＥ２のメッセージが認証されていることを示唆し、ＡＥ２ １１０２がそのようなメッセージを送信する権限を与えられている場合、ＣＳＥ２ ７０２が要求メッセージを処理する。ＣＳＥ２ ７０２は、メッセージから外側ＪＷＳ１／ＭＡＣを取り除く。

図１９のステップ４では、ＣＳＥ２ ７０２が、ＪＷＳ２またはＭＡＣを生成し、それを要求メッセージに付加する。ＪＷＳ２内のＡｕｔｈ＿Ｔａｇは、新たに生成されたノンス、メッセージ、またはメッセージヘッダもしくはメタデータとともに、Ｋｅ２ｅ＿ＣＳＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈキーを使用して、証明書／キーに関連付けられるコンテキスト情報および使用法情報に基づいて生成される。ＣＳＥ２ ７０２は、ＪＷＳ２／ＭＡＣを要求メッセージに付加し、それをＣＳＥ１ ６０４に送信する。依然としてアクティブである（Ｄ）ＴＬＳ接続を用いて作成されるホップ毎のセキュリティアソシエーションがある場合、ＪＷＳ２／ＭＡＣを生成する代わりに、要求メッセージが、そのセキュアな接続を経由して送信され得ることが留意されなければならない。（例えば、ＪＷＳを使用する）オブジェクトセキュリティの代わりに、（Ｄ）ＴＬＳの使用が、サービスプロバイダポリシー、デバイス能力等に基づいて決定され得る。メッセージ機密性が必要とされない場合、オブジェクトセキュリティを使用することが好ましくあり得る。ある場合において、たとえメッセージおよびデータ機密性が必要とされ得る場合でも、ポリシーが（Ｄ）ＴＬＳの代わりにＪＷＥの使用を指示し得る。なぜなら、（Ｄ）ＴＬＳが計算的および／または空間的により集約的であり得る場合、下位層セキュリティに依拠する代わりに、または性能の理由で、サービス層がセキュリティサービスを提供することが可能であり得るからである。

図１９のステップ５では、ＣＳＥ１ ６０４は、それがメッセージの標的であったかどうかを検証する。Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓ（ＪＷＳ２／ＭＡＣ）を使用して、ＣＳＥ１ ６０４は、正しい証明書を識別し、セキュアなキー記憶部（例えば、ＳＩＭカード等のセキュアな要素）からそれをフェッチし、適切なコンテキスト情報および使用法パラメータを決定するために、関連付けられた証明書ＩＤ（ｃｒｅｄ−ｉｄ）を使用する。この場合、Ｋｅ２ｅ＿ＣＳＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈキーが、ＪＷＳ２内のノンスとともに読み出され、メッセージ、またはメッセージのメッセージヘッダもしくはメタデータを使用して、ＣＳＥ１ ６０４は、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇを生成し、それをＪＷＳ２／ＭＡＣ内のＡｕｔｈ＿Ｔａｇと比較し、それらが合致する場合、ＣＳＥ１ ６０４は、メッセージが信頼されるＣＳＥ１ ６０４を通して送信されたことを認証する。

ＣＳＥ１ ６０４は、外側ＪＷＳ２／ＭＡＣを破棄し、内側Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓ／ＪＷＥ１を処理する。ＪＷＥ１内から、ＣＳＥ１ ６０４は、証明書ＩＤを取得し、別個のキーがメッセージ認証ならびにメッセージ機密性の両方のために使用される場合において、両方のキーが、証明書ＩＤに基づいてキー記憶部からフェッチされる必要があろう。ＪＷＥ情報「ａｌｇ」ならびに「ｃｒｅｄ−ｉｄ」を使用して、ＣＳＥ１ ６０４は、ＡＥＡＤがセキュリティ保護のために使用されるかどうかを決定することができ、該当する場合、ｃｒｅｄ−ｉｄによって識別される単一の関連付けられた証明書のみが読み出され得る。セキュリティのタイプ（署名、暗号化）、関与するエンティティ等、および使用法（アルゴリズム、ノンスの可用性等）を決定するコンテキスト情報に基づいて、メッセージが特性の正しい組を有するかどうかを検証し、ＡＡＤ、ＩＶ、ノンス、および他のパラメータを識別し、「ｃｉｐｈｅｒｔｅｘｔ」を解読するためにＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆキーを使用し、メッセージならびにデータペイロードを含み得る「ｐｌａｉｎｔｅｘｔ」を抽出する。ＣＳＥ１ ６０４は、メッセージまたはメッセージヘッダもしくはメッセージのメタデータを使用する、またはＧｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇを計算するためにＡＡＤとして識別されている情報を使用する。ある場合、最初にＡＥ２ １１０２によって送信されたメッセージ全体、またはメッセージヘッダもしくはメッセージのメタデータを使用し、この場合、偶然ＡＥＳ−ＣＣＭであり、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇを生成する、ＪＷＥ内で識別される「ａｌｇ」への入力としてパラメータを提供する、コンテキスト情報とともに存在し得るノンスを使用する。ＣＳＥ１ ６０４は、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇが、ＪＷＥ内に含まれるＡｕｔｈ＿Ｔａｇと同一であるかどうかを検証し、該当する場合、ＡＥ２のメッセージが認証されている。

図１９のステップ６では、そして、ＣＳＥ１ ６０４が、ＡＥ２ １１０２がＡＥ１ ６０２リソースに「更新」動作を行う権限を与えられているかどうかを確認するためにチェックする。ＡＥ２ １１０２が「更新」動作を行う権限を与えられている場合、ＣＳＥ１ ６０４が、Ｒ−ＩＤによって識別されるＡＥ１ ６０２リソースを更新する。

図１９のステップ７では、ＣＳＥ１ ６０４が、ＡＥ１のリソースに行われた更新動作を示す「通知」メッセージをＡＥ１ ６０２に送信するための準備をする。既存の（Ｄ）ＴＬＳ接続がＡＥ１ ６０２とＣＳＥ１ ６０４との間に存在しない場合、またはホップ毎のセキュリティアソシエーションを行うために使用される証明書がＣＳＥ１ ６０４とＡＥ１ ６０２との間に存在しない場合、もしくは（Ｄ）ＴＬＳを用いたホップ毎のセキュリティアソシエーションが使用されないことをポリシーが指示する場合、ＪＷＳを用いたオブジェクトセキュリティ機構が、メッセージ認証を提供するために使用される。ＣＳＥ１ ６０４は、メッセージ、メッセージヘッダ、またはメッセージのメタデータとともに、新たに生成されたノンスを使用して、Ｋｅ２ｅ＿ＣＳＥ１＿ＡＥ１＿ｍｓｇ＿ａｕｔｈキーに関連付けられるコンテキスト情報および使用法情報に基づいてＪＷＳ３／ＭＡＣを生成する。ＪＷＳ３／ＭＡＣは、ＣＳＥ１ ６０４によって生成される「通知」要求メッセージに付加され、ＡＥ１のリソース「Ｒ−ＩＤ」への「更新」を示してＡＥ１ ６０２に送信される。（Ｄ）ＴＬＳを用いたホップ毎のセキュリティがＣＳＥ１ ６０４とＡＥ１ ６０２との間の通信を確保するために使用されるべきことをポリシーが指示する場合、ｏｎｅＭ２Ｍ技術仕様ＴＳ−０００３リリース１に基づいてプロビジョンまたは生成される必要があり得る、共有対称キーＫｐｓａ＿ＡＥ１＿ＣＳＥ１を使用することによって、（Ｄ）ＴＬＳ接続が作成され得る。「通知」メッセージは、オブジェクトセキュリティ機構を使用する代わりに、セキュアな接続を経由して送信され得る。

図１９のステップ８では、ＡＥ１ ６０２が、ＪＷＳ３／ＭＡＣを検証し、「通知」メッセージを認証する。

図１９のステップ９では、ＣＳＥ１ ６０４が、ＡＥ２ １１０２によって送信される要求メッセージへの応答である応答メッセージを作成する。ＣＳＥ１ ６０４は、ＡＥ２ １１０２とＣＳＥ１ ６０４との間で関連付けられるＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆを使用して、Ａｕｔｈ＿Ｔａｇ２、暗号化されたメッセージ、およびＪＷＥ２を生成するために、ステップ２でＡＥ２ １１０２によって使用されるプロシージャに類似するプロセスを使用する。Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓ／ＪＷＥ２は、メッセージヘッダまたはＡＡＤに付加される。毎回、新しいノンスおよびＩＶを使用し、ＪＷＥの一部としてそれを含み、既存のノンスを再利用しないことが推奨される。全てのＳｅｃ−Ａｔｔｒｉｂｕｔｅｓ（例えば、ノンス、Ａｕｔｈ−Ｔａｇ２、証明書ＩＤ、ＡＡＤとして識別される、メッセージまたはメッセージヘッダもしくはメッセージのメタデータ、ＩＶ、およびｃｉｐｈｅｒｔｅｘｔ）が、ＪＷＥ２を作成するために含まれ得る。随意に、ＣＳＥ１ ６０４はまた、メッセージ認証をＣＳＥ２ ７０２に提供するために使用される、外側ＪＷＳ４／ＭＡＣ（Ａｕｔｈ＿Ｔａｇ）も生成する。ＪＷＳ４は、以前に説明された適切なパラメータとともにＫｅ２ｅ＿ＣＳＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈを使用することによって生成される。

図１９のステップ１０では、ＣＳＥ１ ６０４が、ＪＷＳ４／ＭＡＣとともに応答メッセージをＣＳＥ２ ７０２に送信する。ポリシーがＣＳＥ１ ６０４とＣＳＥ２ ７０２との間の（Ｄ）ＴＬＳ接続の設定を必要とする場合、応答メッセージが、セキュアな接続を経由して送信され、ＪＷＳ４の生成を省略し得る。

図１９のステップ１１では、ＣＳＥ２ ７０２が、ＪＷＳ４を検証することによって、真正性／完全性についてＣＳＥ１ ６０４から受信されるメッセージを検証し得、メッセージからＪＷＳ４／ＭＡＣを取り除く。そして、ＣＳＥ２ ７０２は、Ｋｅ２ｅ＿ＡＥ２＿ＣＳＥ２＿ｍｓｇ＿ａｕｔｈおよび上記で説明されるような他のパラメータ（例えば、新しいノンス、メッセージヘッダまたはメッセージもしくはメッセージのメタデータ、コンテキスト情報、および他のパラメータ）を使用して、Ａｕｔｈ＿Ｔａｇを生成し、ＪＷＳ５上にＡｕｔｈ＿Ｔａｇを組み込む。

図１９のステップ１２では、ＡＥ２ １１０２が、ＪＷＳ５を検証し、図１９のステップ５で説明されるような類似機構を使用して、応答メッセージ上のＫｅ２ｅ＿ＡＥ２＿ＣＳＥ２＿ｍｓｇ＿ａｕｔｈキーを使用することによって、Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓ／ＪＷＥ２も含む応答メッセージを認証する。したがって、ＡＥ２ １１０２は、応答メッセージが信頼できるＣＳＥ２ ７０２によって転送されたことを決定する。

ＡＥ２ １１０２は、外側ＪＷＳ２／ＭＡＣを破棄し、内側Ｓｅｃ−Ａｔｔｒｉｂｕｔｅｓ／ＪＷＥ２を処理する。ＪＷＥ２内から、ＡＥ２ １１０２は、証明書ＩＤを取得し、別個のキーがメッセージ認証ならびにメッセージ機密性の両方のために使用される場合において、両方のキーが、証明書ＩＤに基づいてキー記憶部からフェッチされる必要があろう。ＪＷＥ情報「ａｌｇ」ならびに「ｃｒｅｄ−ｉｄ」を使用して、ＡＥ２ １１０２は、ＡＥＡＤがセキュリティ保護のために使用されるかどうかを決定することができ、該当する場合、ｃｒｅｄ−ｉｄによって識別される単一の関連付けられた証明書のみが読み出され得る。セキュリティのタイプ（署名、暗号化）、関与するエンティティ等、および使用法（アルゴリズム、ノンスの可用性等）を決定するコンテキスト情報に基づいて、メッセージが特性の正しい組を有するかどうかを検証し、ＡＡＤ、ＩＶ、ノンス、および他のパラメータを識別し、「ｃｉｐｈｅｒｔｅｘｔ」を解読するためにＫｅ２ｅ＿ＡＥ２＿ＣＳＥ１＿ｍｓｇ＿ａｕｔｈ＿ｃｏｎｆキーを使用し、メッセージならびにデータペイロードを含み得る「ｐｌａｉｎｔｅｘｔ」を抽出する。ＡＥ２ １１０２は、メッセージまたはメッセージヘッダもしくはメッセージのメタデータを使用する、またはＧｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇを計算するためにＡＡＤとして識別されている情報を使用する。ある場合、最初にＣＳＥ１ ６０４によって送信されたメッセージ全体、またはメッセージヘッダもしくはメッセージのメタデータを使用し、この場合、偶然ＡＥＳ−ＣＣＭであり、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇを生成する、ＪＷＥ内で識別される「ａｌｇ」への入力としてパラメータを提供する、コンテキスト情報とともに存在し得るノンスを使用する。ＡＥ２ １１０２は、Ｇｅｎｅｒａｔｅｄ＿Ａｕｔｈ＿Ｔａｇが、ＪＷＥ内に含まれるＡｕｔｈ＿Ｔａｇと同一であるかどうかを検証し、該当する場合、ＣＳＥ１のメッセージが認証されている。

図１９に図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１９に図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１９に図示されるステップを行う。図１９に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

（委託モードを使用するセッション層におけるＥ２Ｅ認証）
図９は、委託モードを使用してセッション層（ＤＴＬＳ／ＴＬＳ）において行われるＥ２Ｅ認証を図示する。ここでは、２つのＥ２Ｅエンティティ（ＣＳＥ１ ６０４およびＣＳＥ３ ５０２）間に別個のセッション層接続を設定することによって認証が行われることを除いて、上記で使用されるアプローチに類似する。ＣＳＥ１ ６０４およびＣＳＥ３ ５０２は、要求メッセージ内で搬送されているＥ２Ｅ認証ＭＡＣを用いてホップ毎の認証を行う代わりに、ＤＴＬＳまたはＴＬＳベースの認証を行う。メッセージング詳細：
図９のステップ１−４は、図８Ａ−Ｂに関するメッセージング機構に類似する。

図９のステップ５では、ＣＳＥ１ ６０４が、ＫｐｓａＥ２Ｅを使用して、ＣＳＥ３ ５０２とのＤＴＬＳ接続を確立する。パラメータプロビジョニングプロセスの一部として、ＣＳＥ１ ６０４は、ＣＳＥ３ ５０２のＵＲＩと、ＣＳＥ１ ６０４とＣＳＥ３ ５０２との間のＥ２Ｅ ＤＴＬＳ接続を設定するために使用されるべきであるポート番号とを取得することができる。

図９のステップ６では、ＣＳＥ１ ６０４からの要求メッセージが、ＤＴＬＳトンネル内でＣＳＥ３ ５０２に転送される。ここで、ＣＳＥ３は、ＣＳＥ１ ６０４からＤＴＬＳトンネルを介した別の次のホップと仮定される。

図９のステップ７では、ＣＳＥ３ ５０２が、偶然ＣＳＥ１ ６０４である、メッセージ発信者情報を検証する。

図９に図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図９に図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図９に図示されるステップを行う。図９に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

（直接モードを使用するセッション層におけるＥ２Ｅ認証）
図１０は、直接モードを使用するセッション層におけるＥ２Ｅ認証を図示し、以前に説明された機構と異なり、ＡＥ１ ６０２は、ＣＳＥ３ ５０２に関連付けられるＴＴＰから取得される証明書に基づいて、ＣＳＥ３ ５０２との直接ＤＴＬＳ接続を設定する。ＵＲＩ、ポート番号、およびＡＥ ＩＤを使用して、リソースが適切に構成される。ＣＳＥ３ ５０２は、メッセージの発信者であるかどうかを検証する。

図１０に図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１０に図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１０に図示されるステップを行う。図１０に図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

（グループ認証）
エンティティは、これらのエンティティによって提供される能力および機能性に基づいてグループ化され得る。同一タイプのサービスを提供するエンティティの各々は、「サービス識別」を用いて識別され得るか、またはｏｎｅＭ２Ｍの場合、Ｍ２Ｍサービスプロバイダドメイン内で固有もしくは大域的に固有でさえあり得る、「アプリケーション識別」として識別され得ることが想定され得る。

事例１：グループ認証が、いくつかの方法で行われ得る：
○ 各グループに関連付けられる固有のグループキー
○ サービス有効化およびセキュリティ構成プロセス中にプロビジョンされる
○ 同一のグループに属する全てのエンティティが、同一のＥ２Ｅグループキーを共有する
○ Ｅ２Ｅが、プロビジョニング段階中に事前プロビジョンされ得るグループ認証キーを使用して互いに認証する
○ グループセッションキーが、認証後に導出され、グループマネージャ（例えば、ＣＳＥ）によってプロビジョンされるグループメンバーの間で共有され得る。

事例２：固有のグループキーはないが、固有のＥ２Ｅ認証キーがある（Ｅ２Ｅメッセージングを低減させる）−委託認証の特殊事例
○ グループが、グループマネージャ（例えば、ホスティングＣＳＥ）によって管理され得る
○ 全てのグループメンバーが、ホスティングＣＳＥに登録される
○ グループの各メンバーが、固有のＥ２Ｅ認証キーを有する
○ グループメンバーが、上記の節で以前に説明されたような固有のＥ２Ｅ Ａｕｔｈキーを使用して、遠隔ＣＳＥまたは任意の他のエンティティを用いて認証される。

事例３：ハイブリッドモード：
○ グループが、それ自身のグループマネージャキー（ＧＭキー）を事前プロビジョンされるグループマネージャによって管理される
○ 全てのグループメンバーが、グループマネージャに登録される
○ グループの各メンバーが、固有のＥ２Ｅ認証キーを有する
○ グループマネージャが、初期グループ認証のためにＥ２ＥグループキーとしてＧＭキーを使用する
○ 各エンティティのための固有のＥ２Ｅ認証キーが、追加の多因子／多層認証のために使用される
○ グループの新しいメンバーが、それらの固有のＥ２Ｅキーを取得するためにＥ２Ｅグループキーを使用し得るか、または、それらは、サービス有効化およびセキュリティ構成プロセス中にプロビジョンされ得る。

グループ認証プロシージャは、以下を含み得る：
○ グループのために使用されるべきため共通セキュリティパラメータのためのグループマネージャとグループメンバーとの間の交渉
○ グループの新しい／将来のメンバーに使用されるべき証明書ならびにグループメンバー情報および関連付け証明書の撤回ためのグループマネージャとＴＴＰとの間の交渉、
委託認証モードシナリオにおいて、グループキーはプロビジョンされないが、エンティティの間で固有のＥ２Ｅキーを使用するグループ認証の実施形態が、図１１Ａ−Ｂに図示されている。グループは、グループマネージャ（例えば、ＣＳＥ１ ６０４）によって管理される。関連ステップが説明される：
図１１Ａ−Ｂのステップ１−６は、前の節で説明される機構に従う。

図１１Ａ−Ｂのステップ７では、メッセージングの標的に基づいて推論される情報に基づいて、ＣＳＥ１が、（エンティティＡに関連付けられるＫｐｓａ＿Ｅ２Ｅ１を使用して生成される）ＭＡＣ１とともにメッセージ２の関連部分と、（Ｋｐｓａ＿Ｅ２Ｅ２関連付けエンティティＢを使用して生成される）ＭＡＣ２とともにメッセージ６の関連部分とを含む連結メッセージを作成する。

図１１Ａ−Ｂのステップ８は、以前の節で説明されたものと同一である。

図１１Ａ−Ｂのステップ９では、ＣＳＥ１ ６０４は、ＫｐｓａＥ２Ｅを使用して、ＣＳＥ３ ５０２（標的）との（Ｄ）ＴＬＳ接続を作成する。

図１１Ａ−Ｂのステップ１０では、ステップ７において作成される連結メッセージが、ＣＳＥ１ ６０４によって、（Ｄ）ＴＬＳ接続を経由してＣＳＥ３ ５０２に安全に送信される。

図１１Ａ−Ｂのステップ１１では、ＣＳＥ３ ５０２が、２つのエンティティ（ＡＥ１ ６０２およびｃｓｅ１１０２）から発信する２つのサービス層メッセージがあることを検証し、発信者またはメッセージを検証することによって、それぞれのＭＡＣをそこで検証し、メッセージが再生されていないことも確実にする。

図１１Ａ−Ｂに図示されるステップを行うエンティティは、図２１Ｃまたは図２１Ｄに図示されるもの等のネットワークノードもしくはコンピュータシステムのメモリ内に記憶され、そのプロセッサ上で実行するソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得る論理エンティティであることを理解されたい。すなわち、図１１Ａ−Ｂに図示される方法は、図２１Ｃまたは図２１Ｄに図示されるノードもしくはコンピュータシステム等のネットワークノードのメモリ内に記憶されたソフトウェア（すなわち、コンピュータ実行可能命令）の形態で実装され得、そのコンピュータ実行可能命令は、ノードのプロセッサによって実行されると、図１１Ａ−Ｂに図示されるステップを行う。図１１Ａ−Ｂに図示される任意の伝送および受信ステップは、ノードのプロセッサならびにそれが実行するコンピュータ実行可能命令（例えば、ソフトウェア）の制御下でノードの通信回路によって行われ得ることも理解されたい。

（インターフェース）
グラフィカルユーザインターフェース（ＧＵＩ）等のインターフェースが、エンドツーエンド承認に関連する機能性を制御および／または構成するようにユーザを支援するために使用されることができる。図１２は、ユーザが、サービス有効化機能およびキー配信機能を含む、エンドツーエンド認証を選択して構成することを可能にするインターフェース１２０２を図示する略図である。ユーザインターフェース１２０２は、Ｍ２Ｍデバイス／ゲートウェイ／サーバにおいてエンドツーエンドセキュリティポリシーおよびアソシエーションセキュリティパラメータを構成／表示するために使用されることができる。インターフェース２１０２は、以下で説明される図２１Ｃ−Ｄに示されるもの等のディスプレイを使用して生成されることができると理解されたい。

（例示的Ｍ２Ｍ／ＩｏＴ／ＷｏＴ通信システム）
図２１Ａは、１つ以上の開示される実施形態が実装され得る、例示的マシンツーマシン（Ｍ２Ｍ）、モノのインターネット（ＩｏＴ）、もしくはモノのウェブ（ＷｏＴ）通信システム１０の略図である。概して、Ｍ２Ｍ技術は、ＩｏＴ／ＷｏＴのための基礎的要素を提供し、任意のＭ２Ｍデバイス、Ｍ２Ｍゲートウェイ、Ｍ２Ｍサーバ、またはＭ２Ｍサービスプラットフォームは、ＩｏＴ／ＷｏＴのコンポーネントまたはノード、ならびにＩｏＴ／ＷｏＴサービス層等であり得る。通信システム１０は、開示される実施形態の機能性を実装するために使用されることができ、サービス有効化機能２０４および３０４、キー配信機能２０６、信頼される第三者、ＣＳＥ４０２、５０２、５０４、６０４、７０４、および２００２、ＣＳＦ４０８および４１２、ＡＥ１ ６０２、ＡＥ２ １１０２、ＳＰリポジトリ２００４、ＤＰ／ＥＰリポジトリ２００６、ＭＥＦ２００８、ならびにユーザインターフェース１２０２を生成するための論理エンティティ等の機能性および論理エンティティを含むことができる。

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

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

例示的Ｍ２Ｍ端末デバイス１８は、タブレット、スマートフォン、医療デバイス、温度および天候モニタ、コネクテッドカー、スマートメータ、ゲームコンソール、携帯情報端末、健康およびフィットネスモニタ、照明、サーモスタット、電気器具、車庫のドアおよび他のアクチュエータベースのデバイス、セキュリティデバイス、ならびにスマートコンセントを含むが、それらに限定されない。

図２１Ｂを参照すると、フィールドドメイン内の図示されるＭ２Ｍサービス層２２は、Ｍ２Ｍアプリケーション２０、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍ端末デバイス１８、ならびに通信ネットワーク１２のためのサービスを提供する。通信システムネットワーク１２は、開示される実施形態の機能性を実装するために使用されることができ、サービス有効化機能２０４および３０４、キー配信機能２０６、信頼される第三者、ＣＳＥ４０２、５０２、５０４、６０４、７０４、および２００２、ＣＳＦ４０８および４１２、ＡＥ１ ６０２、ＡＥ２ １１０２、ＳＰリポジトリ２００４、ＤＰ／ＥＰリポジトリ２００６、ＭＥＦ２００８、ならびにユーザインターフェース１２０２を生成するための論理エンティティ等の機能性および論理エンティティを含むことができる。Ｍ２Ｍサービス層２２は、例えば、以下で説明される図２１Ｃおよび２１Ｄに図示されるデバイスを含む、１つ以上のサーバ、コンピュータ、デバイス、仮想マシン（例えば、クラウド／記憶ファーム等）等によって実装され得る。Ｍ２Ｍサービス層２２は、所望に応じて、任意の数のＭ２Ｍアプリケーション、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍ端末デバイス１８、および通信ネットワーク１２と通信し得ることが理解されるであろう。Ｍ２Ｍサービス層２２は、サーバ、コンピュータ、デバイス等を備え得る、ネットワークの１つ以上のノードによって実装され得る。Ｍ２Ｍサービス層２２は、Ｍ２Ｍ端末デバイス１８、Ｍ２Ｍゲートウェイデバイス１４、およびＭ２Ｍアプリケーション２０に適用されるサービス能力を提供する。Ｍ２Ｍサービス層２２の機能は、例えば、ウェブサーバとして、セルラーコアネットワーク内で、クラウド内で等、種々の方法で実装され得る。

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

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

本願の方法は、サービス層２２および２２”の一部として実装され得る。サービス層２２および２２”は、アプリケーションプログラミングインターフェース（ＡＰＩ）および下層ネットワーキングインターフェースの組を通して付加価値サービス能力をサポートするソフトウェアミドルウェア層である。ＥＴＳＩ Ｍ２ＭおよびｏｎｅＭ２Ｍの両方は、本願の接続方法を含み得るサービス層を使用する。ＥＴＳＩ Ｍ２Ｍのサービス層は、サービス能力層（ＳＣＬ）と称される。ＳＣＬは、Ｍ２Ｍデバイス（デバイスＳＣＬ（ＤＳＣＬ）と称される）、ゲートウェイ（ゲートウェイＳＣＬ（ＧＳＣＬ）と称される）、および／またはネットワークノード（ネットワークＳＣＬ（ＮＳＣＬ）と称される）内に実装され得る。ｏｎｅＭ２Ｍサービス層は、共通サービス機能（ＣＳＦ）（すなわち、サービス能力）の組をサポートする。１つ以上の特定のタイプのＣＳＦの組のインスタンス化は、異なるタイプのネットワークノード（例えば、インフラストラクチャノード、中間ノード、特定用途向けノード）上にホストされ得る共通サービスエンティティ（ＣＳＥ）と称される。さらに、本願の接続方法は、本願の接続方法等のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

いくつかの実施形態では、Ｍ２Ｍアプリケーション２０および２０”は、開示されるシステムならびに方法とともに使用され得る。Ｍ２Ｍアプリケーション２０および２０”は、ＵＥまたはゲートウェイと相互作用するアプリケーションを含み得、さらに、他の開示されるシステムならびに方法とともに使用され得る。

一実施形態では、サービス有効化機能２０４および３０４、キー配信機能２０６、信頼される第三者、ＣＳＥ４０２、５０２、５０４、６０４、７０４、および２００２、ＣＳＦ４０８および４１２、ＡＥ１ ６０２、ＡＥ２ １１０２、ＳＰリポジトリ２００４、ＤＰ／ＥＰリポジトリ２００６、ＭＥＦ２００８、ならびにユーザインターフェース１２０２を生成するための論理エンティティ等の論理エンティティが、図２１Ｂに示されるように、Ｍ２Ｍサーバ、Ｍ２Ｍゲートウェイ、またはＭ２Ｍデバイス等のＭ２ＭノードによってホストされるＭ２Ｍサービス層インスタンス内でホストされ得る。例えば、サービス有効化機能２０４および３０４、キー配信機能２０６、信頼される第三者、ＣＳＥ４０２、５０２、５０４、６０４、７０４、ＣＳＦ４０８および４１２、ＡＥ１ ６０２、ＡＥ２ １１０２、ならびにユーザインターフェース１２０２を生成するための論理エンティティ等の論理エンティティは、Ｍ２Ｍサービス層インスタンス内で、または既存のサービス能力内のサブ機能として、個々のサービス能力を備え得る。

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

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

さらに、サービス有効化機能２０４および３０４、キー配信機能２０６、信頼される第三者、ＣＳＥ４０２、５０２、５０４、６０４、および７０４、ＣＳＦ４０８および４１２、ＡＥ１ ６０２、ＡＥ２ １１０２、ならびにユーザインターフェース１２０２を生成するための論理エンティティ等の論理エンティティは、本願のサービスにアクセスするために、サービス指向アーキテクチャ（ＳＯＡ）および／またはリソース指向アーキテクチャ（ＲＯＡ）を使用する、Ｍ２Ｍネットワークの一部として実装されることができる。

図２１Ｃは、Ｍ２Ｍデバイス１８、Ｍ２Ｍゲートウェイ１４、Ｍ２Ｍサーバ等のＭ２Ｍネットワークノード３０の例示的ハードウェア／ソフトウェアアーキテクチャのブロック図である。ノード３０は、サービス有効化機能２０４および３０４、キー配信機能２０６、信頼される第三者、ＣＳＥ４０２、５０２、５０４、６０４、７０４、および２００２、ＣＳＦ４０８および４１２、ＡＥ１ ６０２、ＡＥ２ １１０２、ＳＰリポジトリ２００４、ＤＰ／ＥＰリポジトリ２００６、ＭＥＦ２００８、ならびにユーザインターフェース１２０２を生成するための論理エンティティ等の論理エンティティを実行するか、またはそれらを含むことができる。デバイス３０は、図２１Ａ−Ｂに示されるようなＭ２Ｍネットワークの一部、または非Ｍ２Ｍネットワークの一部であり得る。図２１Ｃに示されるように、Ｍ２Ｍノード３０は、プロセッサ３２と、非取り外し可能メモリ４４と、取り外し可能メモリ４６と、スピーカ／マイクロホン３８と、キーパッド４０と、ディスプレイ、タッチパッド、および／またはインジケータ４２と、電源４８と、全地球測位システム（ＧＰＳ）チップセット５０と、他の周辺機器５２とを含み得る。ノード３０はまた、送受信機３４および伝送／受信要素３６等の通信回路を含み得る。Ｍ２Ｍノード３０は、実施形態と一致したままで、先述の要素の任意の副次的組み合わせを含み得ることが理解されるであろう。このノードは、本明細書に説明されるＳＭＳＦ機能性を実装する、ノードであり得る。

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

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

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

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

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

プロセッサ３２は、非取り外し可能メモリ４４および／または取り外し可能メモリ４６等の任意のタイプの好適なメモリから情報にアクセスし、その中にデータを記憶し得る。例えば、プロセッサ３２は、上記で説明されるように、セッションコンテキストをそのメモリ内に記憶し得る。非取り外し可能メモリ４４は、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハードディスク、または任意の他のタイプのメモリ記憶デバイスを含み得る。取り外し可能メモリ４６は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ３２は、サーバまたはホームコンピュータ上等のＭ２Ｍノード３０上に物理に位置しないメモリから情報にアクセスし、その中にデータを記憶し得る。プロセッサ３２は、ディスプレイまたはインジケータ４２上の照明パターン、画像、もしくは色を制御し、Ｍ２Ｍサービス層セッション移行または共有のステータスを反映させる、もしくはノードのセッション移行または共有能力もしくは設定についての入力をユーザから得るか、または情報をユーザに表示するように構成され得る。別の実施例では、ディスプレイは、セッション状態に関する情報を示し得る。本開示は、ｏｎｅＭ２Ｍ実施形態においてＲＥＳＴｆｕｌユーザ／アプリケーションＡＰＩを定義する。ディスプレイ上に示され得る、グラフィカルユーザインターフェースは、ＡＰＩの上部に層化され、ユーザが、本明細書に説明される下層サービス層セッション機能性を介して、Ｅ２Ｅセッション、またはその移行もしくは共有を双方向に確立および管理することを可能にするために、ＡＰＩの上部に層化され得る。

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

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

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

図２１Ｄは、Ｍ２Ｍサーバ、ゲートウェイ、デバイス、もしくは他のノード等のＭ２Ｍネットワークの１つ以上のノードを実装するためにも使用され得る、例示的コンピュータシステム９０のブロック図である。コンピュータシステム９０は、コンピュータまたはサーバを備え得、主に、ソフトウェアの形態であり得るコンピュータ読み取り可能な命令によって制御され得、どこでもまたはどのような手段を用いても、そのようなソフトウェアが記憶またはアクセスされる。コンピュータシステム９０は、サービス有効化機能２０４および３０４、キー配信機能２０６、信頼される第三者、ＣＳＥ４０２、５０２、５０４、６０４、７０４、および２００２、ＣＳＦ４０８および４１２、ＡＥ１ ６０２、ＡＥ２ １１０２、ＳＰリポジトリ２００４、ＤＰ／ＥＰリポジトリ２００６、ＭＥＦ２００８、ならびにユーザインターフェース１２０２を生成するための論理エンティティ等の論理エンティティを実行するか、またはそれらを含むことができる。コンピュータシステム９０は、Ｍ２Ｍデバイス、ユーザ機器、ゲートウェイ、ＵＥ／ＧＷ、または、例えば、モバイルコアネットワーク、サービス層ネットワークアプリケーションプロバイダ、端末デバイス１８、もしくはＭ２Ｍゲートウェイデバイス１４のノードを含む任意の他のノードであり得る。そのようなコンピュータ読み取り可能な命令は、コンピュータシステム９０を稼働させるように、中央処理装置（ＣＰＵ）９１等のプロセッサ内で実行され得る。多くの公知のワークステーション、サーバ、およびパーソナルコンピュータでは、中央処理装置９１は、マイクロプロセッサと呼ばれる単一チップＣＰＵによって実装される。他のマシンでは、中央処理装置９１は、複数のプロセッサを備え得る。コプロセッサ８１は、追加の機能を果たす、またはＣＰＵ９１を支援する、主要ＣＰＵ９１とは異なる随意のプロセッサである。ＣＰＵ９１および／またはコプロセッサ８１は、セッション証明書の受信またはセッション証明書に基づく認証等のＥ２Ｅ Ｍ２Ｍサービス層セッションのための開示されるシステムおよび方法に関連するデータを受信、生成、および処理し得る。

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

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

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

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

さらに、コンピュータシステム９０は、コンピュータシステム９０がネットワークの他のノードと通信することを可能にするために、例えば、図２１Ａおよび図２１Ｂのネットワーク１２等の外部通信ネットワークにコンピュータシステム９０を接続するために使用され得るネットワークアダプタ９７等の通信回路を含み得る。

ユーザ機器（ＵＥ）は、通信するためにエンドユーザによって使用される任意のデバイスであり得る。これは、手持ち式電話、モバイルブロードバンドアダプタを具備されたラップトップコンピュータ、または任意の他のデバイスであり得る。例えば、ＵＥは、図２１Ａ−ＢのＭ２Ｍ端末デバイス１８または図２１Ｃのデバイス３０として実装されることができる。

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

図に例証されるような本開示の主題の好ましい実施形態を説明する際に、明確にするために、具体的用語が採用される。しかしながら、請求される主題は、そのように選択された具体的用語に限定されることを意図しておらず、各具体的要素は、類似目的を達成するように同様に動作する、全ての技術的均等物を含むことを理解されたい。

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

Claims (8)

1. 方法であって、
   サービス層エンティティから、一又は二以上のセキュリティ証明書を受信することと、
   前記サービス層エンティティに関連するセキュリティプロファイルにアクセスすることであって、前記セキュリティプロファイルは、前記サービス層エンティティに関連する一又は二以上のセキュリティ要件を含み、前記一又は二以上のセキュリティ要件は、前記サービス層エンティティに関連するセキュリティレベルとセキュリティ保護メカニズムタイプのうち少なくとも一つを示す情報を含むことと、
   前記セキュリティプロファイルに基づいて、前記一又は二以上のセキュリティ証明書を生成することと、
   前記サービス層エンティティに対して、前記一又は二以上のセキュリティ証明書を送信することを含み、
   前記一又は二以上のセキュリティ証明書は、前記サービス層エンティティが少なくとも一つの他のサービス層エンティティとセキュリティアソシエーションを確立することを可能にし、
   前記他のサービス層エンティティは、前記サービス層エンティティが実装されている装置が接続するネットワークにおける他の装置に実装され、
   前記サービス層エンティティと前記他のサービス層エンティティは、一又は二以上の中間サービス層エンティティを介して接続される、方法。
2. 前記セキュリティプロファイルは、サービス可能化とセキュリティ設定プロセスの一部として受信される、請求項１に記載の方法。
3. 前記セキュリティプロファイルは、前記サービス層エンティティから提供されるサービスタイプに基づく、請求項２に記載の方法。
4. 前記一又は二以上のセキュリティ証明書は、前記サービス層エンティティに関連するデバイスプロファイルに基づいて生成され、前記デバイスプロファイルは、前記サービス層エンティティの一又は二以上のケイパビリティを示す情報を含む、請求項１に記載の方法。
5. 前記一又は二以上のセキュリティ証明書は、前記サービス層エンティティに関連するエンティティプロファイルに基づいて生成され、前記エンティティプロファイルは、前記サービス層エンティティのサービスクラス、サービスタイプ、セキュリティレベル、プライバシーレベルのうち、少なくとも一つを含む、請求項１に記載の方法。
6. 前記一又は二以上のセキュリティ証明書は、一又は二以上の鍵を含む、請求項１に記載の方法。
7. 前記一又は二以上の鍵のサイズは、前記サービス層エンティティに関連するセキュリティレベルとセキュリティ保護メカニズムタイプのうち少なくとも一つを示す情報に基づいて決定される、請求項６に記載の方法。
8. 装置であって、
   一又は二以上のプロセッサと、前記一又は二以上のプロセッサと通信可能に結合されているメモリとを備え、前記メモリには、実行可能な命令が記憶されており、前記命令は、実行時、
   サービス層エンティティから、一又は二以上のセキュリティ証明書を受信することと、
   前記サービス層エンティティに関連するセキュリティプロファイルにアクセスすることであって、前記セキュリティプロファイルは、前記サービス層エンティティに関連する一又は二以上のセキュリティ要件を含み、前記一又は二以上のセキュリティ要件は、前記サービス層エンティティに関連するセキュリティレベルとセキュリティ保護メカニズムタイプのうち少なくとも一つを示す情報を含むことと、
   前記セキュリティプロファイルに基づいて、前記一又は二以上のセキュリティ証明書を生成することと、
   前記サービス層エンティティに対して、前記一又は二以上のセキュリティ証明書を送信することを、前記一又は二以上のプロセッサに実行させ、
   前記一又は二以上のセキュリティ証明書は、前記サービス層エンティティが少なくとも一つの他のサービス層エンティティとセキュリティアソシエーションを確立することを可能にし、
   前記他のサービス層エンティティは、前記サービス層エンティティが実装されている装置が接続するネットワークにおける他の装置に実装され、
   前記サービス層エンティティと前記他のサービス層エンティティは、一又は二以上の中間サービス層エンティティを介して接続される、装置。

Images