JP2016526844A - 制約リソースデバイスのための鍵確立 - Google Patents

Abstract

クライアントデバイス（５０６）と制約リソースデバイス（５０２、７０、９０）との間で第１の秘密鍵を確立するための方法および制約リソースデバイスが開示される。本発明はまた、クライアントデバイス（５０６）と制約リソースデバイスとの間で第１の秘密鍵を確立することを可能にする方法および認可サーバ（５０４、６０、８０）に関する。制約ＲＤとＡＳとの間で共有される第２の秘密鍵に基づき、制約リソースデバイスとクライアントデバイスとの間で共有される（５０８）第１の秘密鍵を確立することができる。リソース制約のあるデバイスは、セキュア識別情報を共有するために追加メッセージが必要となるようなプロトコルを利用することができない。本発明の実施形態の利点は、認証プロトコル内で秘密識別情報を確立できること、および秘密識別情報を確立するために追加メッセージが必要ないことである。【選択図】図５

Description

本開示は、制約リソースデバイスのための鍵確立に関する。より詳細には、クライアントデバイスと制約リソースデバイスとの間で秘密鍵を確立するための方法および制約リソースデバイスに関する。本開示はまた、クライアントデバイスと制約リソースデバイスとの間で秘密鍵の確立を可能にする方法および認可サーバに関する。

モノのインターネット（ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）は、ネットワーク化社会へと向かう現在の情報技術動向を表すのに、最近よく使われる用語である。ネットワーク化社会では、接続による恩恵を受けられるあらゆるものがインターネットプロトコルを用いて接続される。これはつまり、かつては主として携帯電話とコンピュータがインターネットを介して世界規模で相互接続されていたのに対し、今やありとあらゆる種類の電子機器がオンライン化されようとしていることを意味する。このようなすう勢は、ハードウェアおよびネットワークのコスト低減ならびにインターネット技術の成熟に伴い、今後何年にもわたって加速していくものと思われる。

ＩｏＴデバイスの中心的特性は、これらデバイスがインターネットプロトコル（ＩＰ）アドレスを持ち、インターネットに接続されていることである。さらに、このようなデバイスは、例えば、中央処理装置の処理速度が遅い、あるいはデバイスのエネルギー源が限られているといった理由から、リソース制約があることが多い。例えばハイパーテキスト転送プロトコル（ＨＴＴＰ）などＩｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ（ＩＥＴＦ）による要求／応答のための共通プロトコルは、シンプルなＩｏＴデバイスを扱うのに非効率的どころか複雑すぎると考えられる。

そこで、処理量および電力消費を抑えるべく新たなインターネット規格が出現しつつある。ＩＥＴＦは、Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ（ＣｏＡＰ）と称する、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）ｆｕｌメッセージ交換のための新しい軽量版アプリケーションプロトコルを策定中である。このプロトコルは、ユーザデータグラムプロトコル（ＵＤＰ）に基づいて、伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ステートの設定および保持の必要性を回避するものである。簡単に言うと、ＲＥＳＴｆｕｌ（ＲＥＳＴ的）とは、統一されたインターフェースによりクライアントをステートレスサーバから分離する、ワールドワイドウェブ（ＷＷＷ）などの分散システム用のソフトウェアアーキテクチャである。

ＣｏＡＰは、エネルギー消費の制限という観点からはＨＴＴＰよりはるかに効率的ではあるが、特に不要なメッセージ交換などの無駄な処理を最小限に減らすことは、なお重要である。無線デバイスのメッセージ送受信におけるエネルギー消費は、同じメッセージの典型的な暗号操作に比べて１桁以上多いということが知られている。

ＣｏＡＰのプロトコルセキュリティには、データグラムトランスポート層セキュリティ（ＤＴＬＳ：Ｄａｔａｇｒａｍ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルを用いることができる。ＤＴＬＳプロトコルは、ユーザデータグラムプロトコル（ＵＤＰ）などのデータグラムプロトコルに通信上のセキュリティを提供するものであり、伝送制御プロトコル（ＴＣＰ）などのコネクション指向プロトコルと共に用いられるトランスポート層セキュリティ（ＴＬＳ：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）プロトコルに似ている。

ＴＬＳプロトコルは、ハンドシェイクプロトコルフェーズとレコードプロトコルフェーズとに分かれている。ハンドシェイクプロトコルフェーズは認証を行ってセキュリティコンテキストを確立するのに対し、レコードプロトコルフェーズは確立されたセキュリティコンテキストを使ってペイロードを保護する。ＴＬＳハンドシェイクプロトコルには、通常、４パスメッセージ交換が含まれている。

図１は、クライアント１０２とサーバ１０４との間のＴＬＳプロトコルを示す概略図である。１０６で、クライアントはＣｌｉｅｎｔ ｈｅｌｌｏメッセージをサーバへ送信する。１０８で、サーバが応答し、Ｓｅｒｖｅｒ ｈｅｌｌｏメッセージを送信する。１１０で、ｃｌｉｅｎｔ ｃｅｒｔｉｆｉｃａｔｅ、ｋｅｙ ｅｘｃｈａｎｇｅがサーバへ送信される。サーバ１０４がクライアントを信頼すると、セキュリティが確立され、１１２でｓｅｒｖｅｒ ｆｉｎｉｓｈｅｄメッセージが送信される。したがって、ハンドシェイクプロトコルには１０６〜１１２が含まれるのに対し、レコードプロトコルフェーズには、確立されたセキュリティコンテキストを使ってアプリケーションデータが送信される、１１４が含まれる。

図２Ａおよび図２Ｂは、さまざまなトランスポート層プロトコルとアプリケーション層プロトコルとの間のプロトコル関係を示す。ＨＴＴＰアプリケーションプロトコル２０２はＴＬＳプロトコル２０４を使用し、ＴＬＳプロトコルは伝送制御プロトコル（ＴＣＰ）２０６を使用する。図２Ｂに示すように、ＣｏＡＰ２０８はＤＴＬＳプロトコル２１０を使用し、ＤＴＬＳプロトコルはトランスポート層のＵＤＰプロトコル２１２を使用する。

図１のサーバ１０４はＣｏＡＰ／ＤＴＬＳサーバであってもよい。３番目のメッセージパス１１０、ハンドシェイクプロトコルの「Ｃｌｉｅｎｔ Ｆｉｎｉｓｈｅｄメッセージ」で、クライアントとされる相手に対する完全性の検証が行われる。このステップで正規のクライアントを装ったクライアントが検出されると、プロトコルはアボート（中止）される。

制約のあるデバイスの処理を最小限に抑えるため、ＤＴＬＳのセキュリティのブートストラップを行う初期鍵マテリアルとして、事前共有鍵（ＰＳＫ）を配備してもよい。

８ビット／１６ ＭＨｚプロセッサ、８〜１６ ｋＢのランダムアクセスメモリ（ＲＡＭ）を搭載したマイクロコントローラなど、リソース制約の大きいデバイスの場合、ＤＴＬＳ事前共有鍵のハンドシェイクは、処理を完了するだけでなお数秒かかることがあり、無線通信が想定される場合はさらに時間がかかる。ここでＤＴＬＳプロトコルは制約のあるデバイスを想定して策定されたわけではないことに留意すべきである。

現行のＣｏＡＰでは、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）と認可（ａｕｔｈｏｒｉｚａｔｉｏｎ）との間に差異がない。制約リソースデバイスは、典型的には、ＤＴＬＳセッションを開始できる相手として信頼できるクライアントの「アクセス制御リスト」を備えている。

しかしながら、事前プロビジョニングが行われた信頼できるユーザにアクセスを制限するというのは柔軟性に欠ける。

したがって、鍵プロビジョニング、認証、および認可のための代替的なセキュリティメカニズムが必要とされている。

本発明の実施形態の目的は、上に概説した問題の少なくともいくつかに対処することであり、この目的およびその他は、添付の独立請求項に従う、制約リソースデバイス、認可サーバ、制約リソースデバイスとクライアントノードとの間で共有される秘密鍵を確立するための方法、および制約リソースデバイスとクライアントデバイスとの間で共有される秘密鍵の確立を可能にする方法によって、ならびに従属請求項に従う実施形態によって達成される。

第１の態様によれば、本発明は、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にする方法を提供する。本方法は、制約ＲＤと共有する第２の秘密鍵を有するＡＳにおいて実行され、ＡＳはクライアントデバイスと関連付けられている。本方法は、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵に対する要求をクライアントデバイスから受信することを含む。本方法はまた、クライアントデバイスから受信した要求に基づき、要求の識別子を決定することと、要求の識別子および第２の秘密鍵に基づき、要求の識別子と関連付けられた第１の秘密鍵を生成することとを含む。さらに本方法は、要求の識別子および生成された第１の秘密鍵をクライアントデバイスへ送信することを含み、それによりクライアントデバイスが制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にする。

第２の態様によれば、本発明は、制約リソースデバイス（ＲＤ）とクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にするように構成された認可サーバ（ＡＳ）を提供する。ＡＳは、制約ＲＤと共有する第２の秘密鍵を有しクライアントデバイスと関連付けられるように構成されている。ＡＳは、プロセッサと、コンピュータプログラムコードを含むコンピュータプログラムを格納するメモリとを備え、コンピュータプログラムコードがプロセッサ内で実行されたとき、コンピュータプログラムコードは、認可サーバに、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵に対する要求をクライアントデバイスから受信することを行わせる。コンピュータプログラムコードはまた、認可サーバに、クライアントデバイスから受信した要求に基づき、要求の識別子を決定することと、要求の識別子および第２の秘密鍵に基づき、要求の識別子と関連付けられた第１の秘密鍵を生成することとを行わせる。加えてコンピュータプログラムコードは、認可サーバに、要求の識別子および生成された第１の秘密鍵をクライアントデバイスへ送信することを行わせて、クライアントデバイスが制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にする。

第３の態様によれば、本発明は、制約リソースデバイス（ＲＤ）とクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にするように構成された認可サーバ（ＡＳ）を提供する。ＡＳは、制約ＲＤと共有する第２の秘密鍵を有しクライアントデバイスと関連付けられるように構成されている。ＡＳは、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵に対する要求をクライアントデバイスから受信するように構成された受信部を備えている。ＡＳはまた、クライアントデバイスから受信した要求に基づき、要求の識別子を決定するように構成された決定部を備えている。ＡＳはまた、要求の識別子および第２の秘密鍵に基づき、要求の識別子と関連付けられた第１の秘密鍵を生成するように構成された生成部を備えている。加えてＡＳは、要求の識別子および生成された第１の秘密鍵をクライアントデバイスへ送信するように構成された送信部であって、クライアントデバイスが制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にする、送信部を備えている。

第４の態様によれば、本発明は、クライアントデバイスと制約ＲＤとの間で共有される第１の秘密鍵を確立するための方法を提供する。制約ＲＤは、認可サーバ（ＡＳ）と共有する第２の秘密鍵を有する。本方法は、制約ＲＤにおいて実行され、ＡＳはクライアントデバイスと関連付けられている。本方法は、デジタル署名および第１の秘密鍵に対する要求の識別子をクライアントデバイスから受信することを含む。本方法はまた、要求の識別子および第２の秘密鍵に基づき、第１の秘密鍵を導出することと、導出された第１の秘密鍵に基づき、デジタル署名を生成することとを含む。本方法は、受信したデジタル署名が生成されたデジタル署名に等しいか否かを判断することをさらに含む。加えて本方法は、受信したデジタル署名が生成されたデジタル署名に等しい場合、導出された第１の秘密鍵がＡＳの第１の秘密鍵に等しく、かつ受信した要求の識別子がＡＳによって決定された要求の識別子に等しいと推論することもまた含む。

第５の態様によれば、本発明は、クライアントデバイスと制約リソースデバイスＲＤとの間で共有される第１の秘密鍵を確立するように構成された制約リソースデバイス（ＲＤ）を提供する。制約ＲＤは、認可サーバ（ＡＳ）と共有する第２の秘密鍵を有するように構成され、ＡＳはクライアントデバイスと関連付けられている。制約ＲＤは、プロセッサと、コンピュータプログラムコードを含むコンピュータプログラムを格納するメモリとを備える。コンピュータコードがプロセッサ内で実行されたとき、コンピュータコードは、制約リソースデバイスに、デジタル署名および第１の秘密鍵に対する要求の識別子をクライアントデバイスから受信することを行わせる。コンピュータプログラムコードはまた、制約ＲＤに、要求の識別子および第２の秘密鍵に基づき、第１の秘密鍵を導出することと、導出された第１の秘密鍵に基づき、デジタル署名を生成することとを行わせる。加えてコンピュータプログラムコードは、制約ＲＤに、受信したデジタル署名が生成されたデジタル署名に等しいか否かを判断することを行わせる。加えて、コンピュータプログラムコードは、プロセッサ内で実行されたとき、受信したデジタル署名が生成されたデジタル署名に等しい場合、導出された第１の秘密鍵がＡＳの第１の秘密鍵に等しく、かつ受信した要求の識別子がＡＳによって決定された要求の識別子に等しいと制約ＲＤに推論することを行わせる。

第６の態様によれば、本発明は、クライアントデバイスと制約リソースデバイスＲＤとの間で共有される第１の秘密鍵を確立するように構成された制約リソースデバイス（ＲＤ）を提供する。制約ＲＤは、認可サーバ（ＡＳ）と共有する第２の秘密鍵を有するように構成され、ＡＳはクライアントデバイスと関連付けられている。制約ＲＤは、デジタル署名および第１の秘密鍵に対する要求の識別子をクライアントデバイスから受信するように構成された受信部を備えている。制約ＲＤはまた、要求の識別子および第２の秘密鍵に基づき、第１の秘密鍵を導出するように構成された導出部を備えている。さらに制約ＲＤは、導出された第１の秘密鍵に基づき、デジタル署名を生成するように構成された生成部を備えている。加えて制約ＲＤは、受信したデジタル署名が生成されたデジタル署名に等しいか否かを判断するように構成された判断部を備えている。生成部は、受信したデジタル署名が生成されたデジタル署名に等しい場合、導出された第１の秘密鍵がＡＳの第１の秘密鍵に等しく、かつ受信した要求の識別子がＡＳによって決定された要求の識別子に等しいと推論するようにさらに構成されている。

本発明の実施形態の利点は、アクセス制御リストを更新できるようにするために制約リソースデバイスによって追加のメッセージを送受信する必要がないことである。

本発明の実施形態のさらなる利点は、少ないコストで制約ＲＤによる処理のみの観点から見て柔軟性に富んだアクセス制御モデルを採用できることである。

次に、以下の添付図面を参照しながら実施形態についてさらに詳しく説明する。

従来技術に従うクライアント−サーバ関係のシグナリング図である。 既知のプロトコルアーキテクチャを示す概略図である。 既知のプロトコルアーキテクチャを示す概略図である。 本発明の実施形態による方法の流れ図である。 本発明の実施形態による方法の流れ図である。 本発明の実施形態のシグナリング図である。 本発明の実施形態による認可サーバの概略図である。 本発明の実施形態による制約リソースデバイスの概略図である。 本発明の実施形態による認可サーバの概略図である。 本発明の実施形態による制約リソースデバイスの概略図である。

以下の記述では、添付図面を参照しながら、本発明のさまざまな実施形態についてさらに詳しい説明を行う。限定ではなく説明を目的として、理解の徹底を期すために具体例および技法などの特定の詳細を説明する。

上述のように、事前プロビジョニングが行われた信頼できるユーザにアクセスを制限することは、いかなるクライアントまたはユーザについても、制約リソースデバイスにアクセスするためには制約リソースデバイスにおける事前プロビジョニングが必要になることから、柔軟性に欠ける。これは全く以て欠点である。

事前プロビジョニングが行われた信頼できるクライアントだけに制限しないようにするため、制約リソースデバイスの再プロビジョニングを行うことなく新しいクライアントにアクセスを許可するように、信頼できる第三者機関（ＴＴＰ：Ｔｒｕｓｔｅｄ Ｔｈｉｒｄ Ｐａｒｔｙ）が導入される。デバイスの所有者を代理するＴＴＰは、必然的に制約リソースデバイスと信頼関係を有している。この信頼関係は、共有鍵または交換された真正な公開鍵の形態で記録される。

制約リソースデバイスとＴＴＰとの間で確立された信頼関係は、柔軟性の高いメカニズムにおいて新しいクライアントにアクセスを許可するために使用することができる。

しかしながら、事前設定がなされていないクライアントの設定には、制約リソースデバイスのアクセス制御リスト内に新しく認可されたクライアントの識別子／鍵を確立するために、いくつかの追加のメッセージ交換およびデバイス処理が追加される。その結果、セットアップ時間が長引き、エネルギー消費が増加することになる。

したがって、信頼できるクライアントデバイスの識別子を確立するために制約リソースデバイスが行うメッセージ交換の回数および処理を最小限にする必要もある。

アクセス制御リストの更新を認証プロトコルに組み込んで、制約ＲＤと認可サーバ（ＡＳ）との間で共有される秘密鍵に基づく秘密鍵を使うことにより、認証プロトコルにおいて追加メッセージを送信する必要がなくなる。

制約ＲＤとＡＳとの間で共有される秘密鍵に基づき、制約ＲＤは、クライアントデバイスと制約ＲＤとの間で共有される秘密鍵をハンドシェイクプロトコルメッセージで搬送される情報に基づいて導出することができる。

このようにして、制約ＲＤのアクセス制御リストは認証プロトコルにおいて更新される。

制約ＲＤがＡＳと共有する秘密鍵を有しており、かつＡＳがクライアントデバイスと関連付けられていれば、制約ＲＤは任意のクライアントデバイスと通信を行うことができるようになる。

このように、ＡＳと制約ＲＤとは鍵Ｋを共有している。制約ＲＤとクライアントデバイスとは鍵を共有しておらず、相互に認識していないことさえあり得る。

本発明の実施形態を例示するために、ここで図５について議論する。

図５は、クライアントデバイスと制約ＲＤ５０２との間で共有される第１の秘密鍵を確立するための、制約ＲＤ５０２、ＡＳ５０４、およびクライアントデバイス５０６の間のシグナリングを示すシグナリング図である。ＡＳはクライアントデバイスと関連付けられている。制約ＲＤ、ＡＳ、およびクライアントデバイスが属する通信ネットワークは、同じであっても異なっていてもよい。５０８で、制約ＲＤとＡＳは第２の秘密鍵を共有する。この第２の秘密鍵は、制約ＲＤ５０２およびＡＳ５０４を製造する際にインストールされてもよい。典型的には、この鍵は５１０以降へ進む前に共有される。

５１０で、クライアントデバイスは鍵に対する要求を制約ＲＤへ送信し、この要求はＡＳ５０４へ送信される。この要求はクライアントデバイス識別子を含んでいてもよい。

５１２で、ＡＳ５０４は要求の識別子を決定する。この要求の識別子はクライアントデバイス識別子に基づいて決定されてもよい。

要求の識別子はノンスを含んでいてもよい。要求の識別子が、ＡＳと制約ＲＤとの間で暗号化データのための完全性保護チャネルとして使用される場合、このデータはランダムに見えるため、ノンスとして使用することができる。要求の識別子がいかなる固有の意味もないランダムデータを伝送するチャネルとして使用される場合、ランダムデータもノンスとして使用することができる。

５１４で、ＡＳ５０４は、決定された要求の識別子および第２の秘密鍵に基づき、第１の秘密鍵を生成する。

５１６で、ＡＳは、生成された第１の秘密鍵および決定された要求の識別子をクライアントデバイス５０６へ送信する。この目的のために、ＡＳは、通常、クライアントデバイス５０６へのセキュアな接続または暗号化接続を用いる。

５１８で、クライアントデバイスは、ＤＴＬＳプロトコルなどの４パスハンドシェイクプロトコルのメッセージとして「ｃｌｉｅｎｔ ｈｅｌｌｏ」メッセージを制約ＲＤ５０２へ送信する。

５２０で、制約ＲＤ５０２は、４パスハンドシェイクプロトコルの別のメッセージである「ｓｅｒｖｅｒ ｈｅｌｌｏ」メッセージでクライアントデバイス５０６に応答する。

５２２で、クライアントデバイス５０６は、５１６で受信した第１の秘密鍵に基づき、デジタル署名を生成する。このデジタル署名はメッセージ認証コード（ＭＡＣ）であってもよい。

５２４で、クライアントデバイス５０６は、デジタル署名と、５１６でＡＳから受信した要求の識別子とを制約ＲＤ５０２へ送信する。デジタル署名および要求の識別子は、「ｃｌｉｅｎｔ ｆｉｎｉｓｈｅｄ」メッセージで制約ＲＤ５０２へ送信されてもよい。あるいは、別々のメッセージ、例えば、上記の５１８のように「ｃｌｉｅｎｔ ｈｅｌｌｏ」メッセージで要求の識別子を送信し、５２４のように「ｃｌｉｅｎｔ ｆｉｎｉｓｈｅｄ」メッセージでデジタル署名を送信することもできる。

要求の識別子はさまざまなメッセージフィールドに埋め込むことができる。要求の識別子を埋め込む一つの選択肢として、「ｃｌｉｅｎｔ ｈｅｌｌｏ」の「ランダム」もしくは「セッション識別情報（ＩＤ）」フィールド、または「ｃｌｉｅｎｔ ｋｅｙ ｅｘｃｈａｎｇｅ」の「事前共有鍵（ｐｓｋ）−識別情報」など、ＴＬＳまたはＤＴＬＳメッセージの既存のフィールドを再利用する方法がある。

もう一つの選択肢は、カスタムデータ構造を定義してＴＬＳで送信することができる、ＴＬＳ拡張を使用することである。ある種のＴＬＳ拡張には、要求の識別子に加えて、オプションとして、認可サーバの識別子、またはクライアントデバイスと制約ＲＤとの間で共有される第１の秘密鍵の導出に認可サーバが使用する秘密鍵を含めることができる。

ＴＬＳ拡張の別の利用法として、ＴＬＳ認可拡張（ＴＬＳ Ａｕｔｈｏｒｉｚａｔｉｏｎ Ｅｘｔｅｎｓｉｏｎ）の「補足データ（ｓｕｐｐｌｅｍｅｎｔａｌ ｄａｔａ）」として搬送される認可アサーションに要求の識別子を埋め込む方法がある。

５２６で、制約ＲＤ５０２は、受信した要求の識別子およびＡＳ５０４と共有する第２の秘密鍵に基づき、第１の秘密鍵を導出する。

５２８で、制約ＲＤ５０２は、導出された第１の秘密鍵でデジタル署名を検証する。この動作は、導出された第１の秘密鍵に基づき、デジタル署名を生成すること４０６と、生成されたデジタル署名が５２４で受信したデジタル署名に等しいか否かを判断すること４０８とによって遂行されてもよい。

５２８でデジタル署名の真正性が検証された場合、あるいは生成されたデジタル署名が受信したデジタル署名に等しいと判断された場合、制約ＲＤ５０２は、導出された第１の秘密鍵がＡＳによって生成された第１の秘密鍵に等しいと推論する。制約ＲＤ５０２はまた、５２４で受信した要求の識別子が５１２でＡＳ５０４によって決定された要求の識別子に等しいと推論してもよい。５１０におけるクライアントデバイスの要求に従い、制約ＲＤ５０２とクライアントデバイス５０６との間には秘密鍵が確立されている。したがってこの秘密鍵は、ＴＬＳまたはＤＴＬＳなどの認証プロトコルにおいて確立されてもよい。あるいは、制約ＲＤとクライアントデバイスとの間で秘密鍵を確立する際に、他の４パス認証プロトコル、例えばインターネットキー交換（ＩＫＥ）を用いてもよい。

デジタル署名の真正性を検証できなかった場合、あるいは生成されたデジタル署名が受信したデジタル署名に等しくないと判断された場合は、このために制約ＲＤ５０２とクライアントデバイス５０６との間で秘密鍵を確立することができず、それ以上の動作は実行されない。

図３を参照しながら、本発明の実施形態による、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にする方法のフローチャートを説明する。本方法は、制約ＲＤと共有する第２の秘密鍵を有するＡＳにおいて実行され、ＡＳはクライアントデバイスと関連付けられている。本方法は、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵に対する要求をクライアントデバイスから受信すること３２を含む。本方法はまた、クライアントデバイスから受信した要求に基づき、要求の識別子を決定すること３４と、要求の識別子および第２の秘密鍵に基づき、要求の識別子と関連付けられた第１の秘密鍵を生成すること３６とを含む。加えて本方法は、要求の識別子および生成された第１の秘密鍵をクライアントデバイスへ送信すること３８を含み、それによりクライアントデバイスが制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にする。

第１の秘密鍵に対する要求はクライアントデバイス識別子を含んでもよく、本方法は、クライアントデバイス識別子に基づき、クライアントデバイスを認証することをさらに含んでもよい。

要求の識別子を決定することがクライアントデバイス識別子にさらに基づいていてもよい。

また、要求の識別子はクライアントデバイス識別子を含み、制約ＲＤがクライアントデバイスを認証することをさらに可能にしてもよい。

要求の識別子はクライアントデバイスのアクセス情報を含み、制約ＲＤが制約ＲＤに対するクライアントデバイスのアクセスを認可することをさらに可能にしてもよい。

第１の秘密鍵の確立を可能にする方法における要求の識別子はノンスを含んでいてもよい。要求の識別子がＡＳと制約ＲＤとの間で暗号化データのための完全性保護チャネルとして使用される場合、このデータはランダムに見えるため、ノンスとして使用することができる。要求の識別子がいかなる固有の意味もないランダムデータを伝送するチャネルとして使用される場合、ランダムデータはノンスとして使用することができる。

第１の秘密鍵の確立を可能にする方法は、認証プロトコル内で実行されてもよい。

第１の秘密鍵の確立を可能にする方法が実行される認証プロトコルは、トランスポート層セキュリティ（ＴＬＳ）プロトコルまたはデータグラムトランスポート層セキュリティ（ＤＴＬＳ）プロトコルを含んでもよい。

図４を参照しながら、本発明の実施形態による、クライアントデバイスと制約ＲＤとの間で共有される第１の秘密鍵を確立するための方法のフローチャートを説明する。制約ＲＤはＡＳと共有する第２の秘密鍵を有する。本方法は制約ＲＤにおいて実行され、ＡＳはクライアントデバイスと関連付けられている。本方法は、デジタル署名および第１の秘密鍵に対する要求の識別子をクライアントデバイスから受信すること４０２を含む。本方法はまた、要求の識別子および第２の秘密鍵に基づき、第１の秘密鍵を導出すること４０４と、導出された第１の秘密鍵に基づき、デジタル署名を生成すること４０６とを含む。本方法は、受信したデジタル署名が生成されたデジタル署名に等しいか否かを判断すること４０８をさらに含む。加えて本方法は、受信したデジタル署名が生成されたデジタル署名に等しい場合、導出された第１の秘密鍵がＡＳの第１の秘密鍵に等しく、かつ受信した要求の識別子がＡＳによって決定された要求の識別子に等しいと推論することもまた含む。受信したデジタル署名が生成されたデジタル署名に等しくない場合、本方法は動作を実行しないこと４１２を含む。

第１の秘密鍵を確立するための方法における要求の識別子はノンスを含んでいてもよい。

第１の秘密鍵を確立するための方法における要求の識別子はクライアントデバイス識別子を含んでもよく、本方法は、クライアントデバイス識別子に基づき、クライアントデバイスを認証してもよい。

第１の秘密鍵を確立するための方法における要求の識別子は、クライアントデバイスのアクセス情報を含んでもよく、このアクセス情報に基づき、本方法は制約ＲＤに対するクライアントデバイスのアクセスを認可することをさらに含んでもよい。

第１の秘密鍵を確立するための方法は、導出した第１の秘密鍵に基づき第２のデジタル署名を生成することと、第２のデジタル署名をクライアントデバイスへ送信することとを含んでもよい。

デジタル署名がメッセージ認証コード（ＭＡＣ）を含んでもよい、第１の秘密鍵を確立するための方法。

第１の秘密鍵を確立するための方法は、認証プロトコル内で実行されてもよい。

第１の秘密鍵を確立するための方法が実行される認証プロトコルは、トランスポート層セキュリティ（ＴＬＳ）プロトコルまたはデータグラムトランスポート層セキュリティ（ＤＴＬＳ）プロトコルを含んでもよい。

図６を参照すると、制約ＲＤ５０２とクライアントデバイス５０６との間で共有される第１の秘密鍵の確立を可能にする認可サーバ５０４、６０が概略的に提示されている。認可サーバ５０４、６０は、制約ＲＤ５０２とクライアントデバイス５０６との間で共有される第１の秘密鍵の確立を可能にするように構成されている。ＡＳは、制約ＲＤと共有する第２の秘密鍵を有しクライアントデバイスと関連付けられるように構成されている。ＡＳは、プロセッサ６２と、コンピュータプログラムコードを含むコンピュータプログラムを格納するメモリ６４とを備えている。コンピュータプログラムコードがプロセッサ内で実行されたとき、コンピュータプログラムコードは、認可サーバに、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵に対する要求をクライアントデバイスから受信すること３２、５１０を行わせる。コンピュータプログラムコードはまた、認可サーバに、クライアントデバイスから受信した要求に基づき、要求の識別子を決定すること３４、５１２と、要求の識別子および第２の秘密鍵に基づき、要求の識別子と関連付けられた第１の秘密鍵を生成すること３６、５１４とを行わせる。加えてコンピュータプログラムコードは、認可サーバに、要求の識別子および生成された第１の秘密鍵をクライアントデバイスへ送信すること３８、５１６を行わせて、クライアントデバイスが制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にする。

認可サーバ内のメモリのコンピュータプログラムコードでは、このコードがプロセッサ内で実行されたとき、認可サーバに、第１の秘密鍵に対する要求の中のクライアントデバイス識別子を受信することと、受信したクライアントデバイス識別子に基づき、クライアントデバイス５０６を認証することとを行わせてもよい。

認可サーバ内のメモリのコンピュータプログラムコードは、このコードがプロセッサ内で実行されたとき、認可サーバに、要求の識別子を決定することを行わせてもよく、要求の識別子はノンスを含んでいてもよい。

要求の識別子は、ＡＳと制約ＲＤとの間で暗号化データのための完全性保護チャネルとして使用することができる。暗号化データはランダムに見えるため、ノンスとして使用することができる。要求の識別子がいかなる固有の意味もないランダムデータを伝送するチャネルとして使用される場合、そのようなランダムデータはノンスとして使用することができる。

図７は、クライアントデバイス５０６と制約ＲＤ５０２、７０との間で共有される第１の秘密鍵を確立するように構成された制約ＲＤを示す概略図である。制約ＲＤは、ＡＳ５０４、６０と共有する第２の秘密鍵を有するように構成され、ＡＳはクライアントデバイス５０６と関連付けられている。制約ＲＤは、プロセッサ７２と、コンピュータプログラムコードを含むコンピュータプログラムを格納するメモリ７４とを備えている。コンピュータプログラムコードがプロセッサ内で実行されたとき、コンピュータプログラムコードは、制約リソースデバイスに、デジタル署名および第１の秘密鍵に対する要求の識別子をクライアントデバイスから受信すること４０２、５２４を行わせる。コンピュータプログラムコードはまた、制約ＲＤに、要求の識別子および第２の秘密鍵に基づき、第１の秘密鍵を導出すること４０４、５２６と、導出された第１の秘密鍵に基づき、デジタル署名を生成すること４０６、５２８とを行わせる。さらにコンピュータプログラムコードは、制約ＲＤに、受信したデジタル署名が生成されたデジタル署名に等しいか否かを判断すること４０８、５２８を行わせる。加えて、コンピュータプログラムコードは、プロセッサ内で実行されたとき、制約ＲＤに、受信したデジタル署名が生成されたデジタル署名に等しい場合、導出された第１の秘密鍵がＡＳの第１の秘密鍵に等しく、かつ受信した要求の識別子がＡＳによって決定された要求の識別子に等しいと推論することを行わせる。

制約ＲＤのコンピュータプログラムコードは、このコードがプロセッサ内で実行されたとき、制約リソースデバイスに、要求の識別子がクライアントデバイスのアクセス情報を含む場合に、アクセス情報に基づき、制約ＲＤに対するクライアントデバイスのアクセスを認可することを行わせてもよい。

制約ＲＤのコンピュータプログラムコードは、このコードがプロセッサ内で実行されたとき、制約リソースデバイスに、ノンスを含む要求の識別子を受信することを行わせてもよい。

制約ＲＤのコンピュータプログラムコードは、このコードがプロセッサ内で実行されたとき、制約リソースデバイスに、導出された第１の秘密鍵に基づき第２のデジタル署名を生成することと、第２のデジタル署名をクライアントデバイスへ送信することとを行わせてもよい。

制約リソースデバイスには、制約リソースサーバを含んでもよい。

図８は、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にするように構成された認可サーバ（ＡＳ）８０を示す概略図である。ＡＳは、制約ＲＤと共有する第２の秘密鍵を有しクライアントデバイスと関連付けられるように構成されている。ＡＳ８０は、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵に対する要求をクライアントデバイスから受信する３２、５１０ように構成された受信部８２を備えている。ＡＳはまた、クライアントデバイスから受信した要求に基づき、要求の識別子を決定する３４、５１２ように構成された決定部８４を備えている。ＡＳは、要求の識別子および第２の秘密鍵に基づき、要求の識別子と関連付けられた第１の秘密鍵を生成する３６、５１４ように構成された生成部８６をさらに備えている。加えてＡＳは、要求の識別子および生成された第１の秘密鍵をクライアントデバイスへ送信する３８、５１６ように構成された送信部８８を備え、クライアントデバイスが制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、制約ＲＤとクライアントデバイスとの間で共有される第１の秘密鍵の確立を可能にする。

図９は、クライアントデバイス５０６と制約ＲＤ５０２、９０との間で共有される第１の秘密鍵を確立するように構成された制約ＲＤ５０２、９０を示す概略図である。制約ＲＤは、ＡＳ５０４、６０、８０と共有する第２の秘密鍵を有するように構成され、ＡＳはクライアントデバイスと関連付けられている。制約ＲＤは、デジタル署名および第１の秘密鍵に対する要求の識別子をクライアントデバイスから受信するように構成された受信部９２を備えている。制約ＲＤはまた、要求の識別子および第２の秘密鍵に基づき、第１の秘密鍵を導出するように構成された導出部９４を備えている。さらに制約ＲＤは、導出された第１の秘密鍵に基づき、デジタル署名を生成するように構成された生成部９６を備えている。加えて制約ＲＤは、受信したデジタル署名が生成されたデジタル署名に等しいか否かを判断するように構成された判断部９８を備えている。生成部９６は、受信したデジタル署名が生成されたデジタル署名に等しい場合、導出された第１の秘密鍵がＡＳの第１の秘密鍵に等しく、かつ受信した要求の識別子がＡＳによって決定された要求の識別子に等しいと推論するようにさらに構成されている。

本開示は、このように認可サーバ、制約リソースデバイス、およびそれらの方法を提示するものである。

本発明には次の利点がある。

アクセス制御リストを更新できるようにするために制約リソースデバイスによって追加のメッセージを送受信する必要がない。したがって、少ないコストで制約ＲＤによる処理のみの観点から見てより柔軟性に富んだアクセス制御モデルを採用できる。

上述の実施形態は例示としてのみ与えられ、他の解決策、用途、目的、および機能は明らかに添付の特許請求の範囲にかかる発明の範囲内にあるため、これらの実施形態は本発明を限定するものではないことをさらに指摘しておいてもよいだろう。

略語
ＡＳ 認可サーバ
ＣｏＡＰ Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ
ＤＴＬＳ データグラムＴＬＳ
ＨＴＴＰ ハイパーテキスト転送プロトコル
ＩＤ 識別情報
ＩＥＴＦ Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ
ＩＫＥ インターネットキー交換
ＩｏＴ モノのインターネット
ＰＳＫ 事前共有鍵
ＲＡＭ ランダムアクセスメモリ
ＲＤ リソースデバイス
ＴＣＰ 伝送制御プロトコル
ＴＬＳ トランスポート層セキュリティ
ＴＴＰ 信頼できる第三者機関
ＵＤＰ ユーザデータグラムプロトコル

Claims (27)

1. 制約リソースデバイス（ＲＤ）（５０２、７０、９０）とクライアントデバイス（５０６）との間で共有される第１の秘密鍵の確立を可能にする方法であって、前記制約ＲＤと共有する第２の秘密鍵を有し前記クライアントデバイスと関連付けられている認可サーバ（ＡＳ）（５０４、６０、８０）において実行される方法であり、
   − 前記制約ＲＤと前記クライアントデバイスとの間で共有される第１の秘密鍵に対する要求を前記クライアントデバイスから受信すること（３２、５１０）と、
   − 前記クライアントデバイスから受信した前記要求に基づき、前記要求の識別子を決定すること（３４、５１２）と、
   − 前記要求の前記識別子および前記第２の秘密鍵に基づき、前記要求の前記識別子と関連付けられた前記第１の秘密鍵を生成すること（３６、５１４）と、
   − 前記要求の前記識別子および生成された前記第１の秘密鍵を前記クライアントデバイスへ送信すること（３８、５１６）であって、それにより前記クライアントデバイスが前記制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、前記制約ＲＤと前記クライアントデバイスとの間で共有される前記第１の秘密鍵の確立を可能にする、送信することと
   を含む方法。
2. 前記第１の秘密鍵に対する前記要求がクライアントデバイス識別子を含み、前記クライアントデバイス識別子に基づき、前記クライアントデバイス（５０６）を認証することをさらに含む、請求項１に記載の第１の秘密鍵の確立を可能にする方法。
3. 前記要求の前記識別子を決定すること（３４、５１２）が前記クライアントデバイス識別子にさらに基づく、請求項２に記載の第１の秘密鍵の確立を可能にする方法。
4. 前記要求の前記識別子が前記クライアントデバイス識別子を含み、前記制約ＲＤが前記クライアントデバイスを認証することをさらに可能にする、請求項２または３に記載の第１の秘密鍵の確立を可能にする方法。
5. 前記要求の前記識別子が前記クライアントデバイスのアクセス情報を含み、前記制約ＲＤが前記制約ＲＤ（５０２、７０、９０）に対する前記クライアントデバイスのアクセスを認可することをさらに可能にする、請求項２ないし４のいずれか一項に記載の第１の秘密鍵の確立を可能にする方法。
6. 前記要求の前記識別子がノンスを含む、請求項１ないし３のいずれか一項に記載の第１の秘密鍵の確立を可能にする方法。
7. 認証プロトコル内で実行される、請求項１ないし６のいずれか一項に記載の第１の秘密鍵の確立を可能にする方法。
8. 前記認証プロトコルがトランスポート層セキュリティ（ＴＬＳ）プロトコルまたはデータグラムトランスポート層セキュリティ（ＤＴＬＳ）プロトコルを含む、請求項７に記載の第１の秘密鍵の確立を可能にする方法。
9. 制約リソースデバイス（ＲＤ）（５０２、７０、９０）とクライアントデバイス（５０６）との間で共有される第１の秘密鍵の確立を可能にするように構成され、かつ前記制約ＲＤと共有する第２の秘密鍵を有し前記クライアントデバイスと関連付けられるように構成された認可サーバ（ＡＳ）（５０４、６０）であって、
   − プロセッサ（６２）と、
   − コンピュータプログラムコードを含むコンピュータプログラムを格納するメモリ（６４）とを備え、
   前記コンピュータプログラムコードが前記プロセッサ内で実行されたとき、前記コンピュータプログラムコードは、前記認可サーバに、
   − 前記制約ＲＤと前記クライアントデバイスとの間で共有される第１の秘密鍵に対する要求を前記クライアントデバイスから受信すること（３２、５１０）と、
   − 前記クライアントデバイスから受信した前記要求に基づき、前記要求の識別子を決定すること（３４、５１２）と、
   − 前記要求の前記識別子および前記第２の秘密鍵に基づき、前記要求の前記識別子と関連付けられた前記第１の秘密鍵を生成すること（３６、５１４）と、
   − 前記要求の前記識別子および生成された前記第１の秘密鍵を前記クライアントデバイスへ送信すること（３８、５１６）と
   を行わせて、前記クライアントデバイスが前記制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、前記制約ＲＤと前記クライアントデバイスとの間で共有される前記第１の秘密鍵の確立を可能にする、
   認可サーバ。
10. 前記コンピュータプログラムコードが、前記プロセッサ内で実行されたとき、前記認可サーバに、前記第１の秘密鍵に対する前記要求の中のクライアントデバイス識別子を受信することと、受信した前記クライアントデバイス識別子に基づき、前記クライアントデバイス（５０６）を認証することとをさらに行わせる、請求項９に記載の認可サーバ（ＡＳ）（５０４、６０）。
11. 前記コンピュータプログラムコードが、前記プロセッサ内で実行されたとき、前記認可サーバに、前記要求の識別子を決定することを行わせ、前記要求の前記識別子がノンスを含む、請求項９または１０に記載の認可サーバ（ＡＳ）（５０４、６０）。
12. 制約リソースデバイス（ＲＤ）（５０２、７０、９０）とクライアントデバイス（５０６）との間で共有される第１の秘密鍵の確立を可能にするように構成され、かつ前記制約ＲＤと共有する第２の秘密鍵を有し前記クライアントデバイスと関連付けられるように構成された認可サーバ（ＡＳ）（５０４、８０）であって、
    − 前記制約ＲＤと前記クライアントデバイスとの間で共有される第１の秘密鍵に対する要求を前記クライアントデバイスから受信する（３２、５１０）ように構成された受信部（８２）と、
    − 前記クライアントデバイスから受信した前記要求に基づき、前記要求の識別子を決定する（３４、５１２）ように構成された決定部（８４）と、
    − 前記要求の前記識別子および前記第２の秘密鍵に基づき、前記要求の前記識別子と関連付けられた前記第１の秘密鍵を生成する（３６、５１４）ように構成された生成部（８６）と、
    − 前記要求の前記識別子および生成された前記第１の秘密鍵を前記クライアントデバイスへ送信する（３８、５１６）ように構成された送信部（８８）と
    を備え、
    前記クライアントデバイスが前記制約ＲＤとの通信に用いられるデジタル署名を生成することを可能にし、前記制約ＲＤと前記クライアントデバイスとの間で共有される前記第１の秘密鍵の確立を可能にする、認可サーバ。
13. クライアントデバイス（５０６）と、前記クライアントデバイスと関連付けられている認可サーバ（ＡＳ）（５０４、６０、８０）と共有する第２の秘密鍵を有する制約リソースデバイス（ＲＤ）（５０２、７０、９０）との間で共有される第１の秘密鍵を確立するための方法であって、前記制約ＲＤにおいて実行される方法であり、
    − デジタル署名および前記第１の秘密鍵に対する要求の識別子を前記クライアントデバイスから受信すること（４０２、５２４）と
    − 前記要求の前記識別子および前記第２の秘密鍵に基づき、第１の秘密鍵を導出すること（４０４、５２６）と、
    − 導出された前記第１の秘密鍵に基づき、デジタル署名を生成すること（４０６、５２８）と、
    − 受信した前記デジタル署名が生成された前記デジタル署名に等しいか否かを判断すること（４０８、５２８）と、
    − 受信した前記デジタル署名が生成された前記デジタル署名に等しい場合、導出された前記第１の秘密鍵が前記ＡＳの第１の秘密鍵に等しく、かつ受信した前記要求の前記識別子が前記ＡＳによって決定された前記要求の識別子に等しいと推論することと
    を含む方法。
14. 前記要求の前記識別子がノンスを含む、請求項１３に記載の第１の秘密鍵を確立するための方法。
15. 前記要求の前記識別子がクライアントデバイス識別子を含み、前記方法が、前記クライアントデバイス識別子に基づき、前記クライアントデバイスを認証することをさらに含む、請求項１３または１４に記載の第１の秘密鍵を確立するための方法。
16. 前記要求の前記識別子がクライアントデバイスのアクセス情報を含み、前記方法が、前記アクセス情報に基づき、前記制約ＲＤに対するクライアントデバイスのアクセスを認可することをさらに含む、請求項１３ないし１５のいずれか一項に記載の第１の秘密鍵を確立するための方法。
17. 導出した前記第１の秘密鍵に基づき第２のデジタル署名を生成することと、前記第２のデジタル署名を前記クライアントデバイスへ送信することとをさらに含む、請求項１３ないし１６のいずれか一項に記載の第１の秘密鍵を確立するための方法。
18. デジタル署名がメッセージ認証コード（ＭＡＣ）を含む、請求項１３ないし１７のいずれか一項に記載の第１の秘密鍵を確立するための方法。
19. 認証プロトコル内で実行される、請求項１３ないし１８のいずれか一項に記載の第１の秘密鍵を確立するための方法。
20. 前記認証プロトコルがトランスポート層セキュリティ（ＴＬＳ）プロトコルまたはデータグラムトランスポート層セキュリティ（ＤＴＬＳ）プロトコルを含む、請求項１９に記載の第１の秘密鍵を確立するための方法。
21. 制約リソースデバイス（ＲＤ）（５０２、７０）であって、クライアントデバイス（５０６）と前記制約リソースデバイス（ＲＤ）（５０２、７０）との間で共有される第１の秘密鍵を確立するように構成され、かつ前記クライアントデバイスと関連付けられている認可サーバ（ＡＳ）（５０４、６０、８０）と共有する第２の秘密鍵を有するように構成された制約リソースデバイスであり、
    − プロセッサ（７２）と、
    − コンピュータプログラムコードを含むコンピュータプログラムを格納するメモリ（７４）とを備え、
    前記コンピュータプログラムコードが前記プロセッサ内で実行されたとき、前記コンピュータプログラムコードは、前記制約リソースデバイスに、
    − デジタル署名および前記第１の秘密鍵に対する要求の識別子を前記クライアントデバイスから受信すること（４０２、５２４）と、
    − 前記要求の識別子および前記第２の秘密鍵に基づき、第１の秘密鍵を導出すること（４０４、５２６）と、
    − 導出された前記第１の秘密鍵に基づき、デジタル署名を生成すること（４０６、５２８）と、
    − 受信した前記デジタル署名が生成された前記デジタル署名に等しいか否かを判断すること（４０８、５２８）と、
    − 受信した前記デジタル署名が生成された前記デジタル署名に等しい場合、導出された前記第１の秘密鍵が前記ＡＳの第１の秘密鍵に等しく、かつ受信した前記要求の前記識別子が前記ＡＳによって決定された前記要求の識別子に等しいと推論することとを行わせる、
    制約リソースデバイス。
22. 前記コンピュータプログラムコードが、前記プロセッサ内で実行されたとき、前記要求の前記識別子がクライアントデバイス識別子を含む場合に、前記制約リソースデバイスに、前記クライアントデバイス識別子に基づき、前記クライアントデバイスを認証することを行わせる、請求項２１に記載の制約リソースデバイス（ＲＤ）（５０２、７０）。
23. 前記コンピュータプログラムコードが、前記プロセッサ内で実行されたとき、前記要求の前記識別子がクライアントデバイスのアクセス情報を含む場合に、前記制約リソースデバイスに、前記アクセス情報に基づき、前記制約ＲＤに対する前記クライアントデバイスのアクセスを認可することを行わせる、請求項２１または２２に記載の制約リソースデバイス（ＲＤ）（５０２、７０）。
24. 前記コンピュータプログラムコードが、前記プロセッサ内で実行されたとき、前記制約リソースデバイスに、ノンスを含む前記要求の前記識別子を受信することを行わせる、請求項２１ないし２３のいずれか一項に記載の制約リソースデバイス（ＲＤ）（５０２、７０）。
25. 前記コンピュータプログラムコードが、前記プロセッサ内で実行されたとき、前記制約リソースデバイスに、導出された前記第１の秘密鍵に基づき第２のデジタル署名を生成することと、前記第２のデジタル署名を前記クライアントデバイスへ送信することとを行わせる、請求項２１ないし２４のいずれか一項に記載の制約リソースデバイス（ＲＤ）（５０２、７０）。
26. 制約リソースサーバを含む、請求項２１ないし２５のいずれか一項に記載の制約リソースデバイス（ＲＤ）（５０２、７０）。
27. 制約リソースデバイス（ＲＤ）（５０２、９０）であって、クライアントデバイス（５０６）と前記制約リソースデバイス（ＲＤ）（５０２、９０）との間で共有される第１の秘密鍵を確立するように構成され、かつ前記クライアントデバイスと関連付けられている認可サーバ（ＡＳ）（５０４、６０、８０）と共有する第２の秘密鍵を有するように構成された制約リソースデバイス（ＲＤ）（５０２、９０）であり、
    − デジタル署名および前記第１の秘密鍵に対する要求の識別子を前記クライアントデバイスから受信するように構成された受信部（９２）と、
    − 前記要求の前記識別子および前記第２の秘密鍵に基づき、第１の秘密鍵を導出するように構成された導出部（９４）と、
    − 導出された前記第１の秘密鍵に基づき、デジタル署名を生成するように構成された生成部（９６）と、
    − 受信した前記デジタル署名が生成された前記デジタル署名に等しいか否かを判断するように構成された判断部（９８）と
    を備え、
    前記生成部（９６）は、受信した前記デジタル署名が生成された前記デジタル署名に等しい場合、導出された前記第１の秘密鍵が前記ＡＳの第１の秘密鍵に等しく、かつ受信した前記要求の前記識別子が前記ＡＳによって決定された前記要求の識別子に等しいと推論するようにさらに構成されている、制約リソースデバイス。

Images