特開 2015-146567 モノのインターネットのためのデータグラム転送における軽量認証のためのコンピュータ実施システムおよび方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2015-146567(P2015-146567A)

(43)【公開日】2015年8月13日

(54)【発明の名称】モノのインターネットのためのデータグラム転送における軽量認証のためのコンピュータ実施システムおよび方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20150717BHJP

   H04L 9/08 20060101ALI20150717BHJP

   G06F 21/44 20130101ALI20150717BHJP

【ＦＩ】

   H04L9/00 675A

   H04L9/00 601B

   G06F21/44 350

【審査請求】未請求

【請求項の数】20

【出願形態】ＯＬ

【外国語出願】

【全頁数】40

(21)【出願番号】特願2014-253636(P2014-253636)

(22)【出願日】2014年12月16日

(31)【優先権主張番号】377/MUM/2014

(32)【優先日】2014年2月3日

(33)【優先権主張国】IN

(71)【出願人】

【識別番号】510337621

【氏名又は名称】タタ コンサルタンシー サービシズ リミテッド

【氏名又は名称原語表記】ＴＡＴＡ Ｃｏｎｓｕｌｔａｎｃｙ Ｓｅｒｖｉｃｅｓ Ｌｉｍｉｔｅｄ

(74)【代理人】

【識別番号】100083286

【弁理士】

【氏名又は名称】三浦 邦夫

(74)【代理人】

【識別番号】100166408

【弁理士】

【氏名又は名称】三浦 邦陽

(72)【発明者】

【氏名】アブヒジャン バッタチャリャ

(72)【発明者】

【氏名】ソマ バンドヨパドヒャイ

(72)【発明者】

【氏名】アリジット ウキル

(72)【発明者】

【氏名】アルパン パル

【テーマコード（参考）】

5J104

【Ｆターム（参考）】

5J104AA07

5J104AA12

5J104AA16

5J104AA18

5J104EA17

5J104GA05

5J104JA03

5J104KA02

5J104KA04

5J104KA06

5J104KA21

5J104NA02

5J104NA37

5J104NA38

5J104PA07

(57)【要約】      （修正有）

【課題】事前共有秘密を共有する２つのエンドポイント間のチャレンジレスポンス交換に基づく強固で軽量な認証スキームを提供する。
【解決手段】セキュリティメカニズムでは、鍵管理が認証と統合される。システム内のエンドポイントはプロビジョニング処理の間には事前共有秘密が設定され、クライアントのデータベースがサーバー側で用意されることによって、相互認証を提供する。システムは、一回だけ使用される乱数（ノンス）発生のための乱数発生器と、秘密鍵及びセッション鍵を生成する鍵生成器を備えている。ノンスと鍵は、単一のセッションの間有効であり、セッション間で安全な認証を提供することに役立つ。さらに、データグラムトランスポート層セキュリティプロトコル（ＤＴＬＳ）に適合させることができ、制約付きデバイスのために制限付きアプリケーション層プロトコル（ＣｏＡＰ）と統合する。
【選択図】図２

【特許請求の範囲】

【請求項1】

サーバーとクライアント間のデータグラム転送に関する２つの相互認証のためのコンピュータにより実施される、システムプロセッサとを含むシステムであって、
I） 前記システムプロセッサと協働し、第１の乱数を発生する第１の乱数発生器；
II） 前記システムプロセッサと協働し、第２の乱数を発生する第２の乱数発生器；
III） 前記システムプロセッサと協働し、プロビジョニング処理の間の双方向認証の前に、システムプロセッサの生成コマンド及び送信コマンドを受けて秘密鍵を生成してサーバー及びクライアントに送信する秘密鍵生成器；
IV） すべてのクライアントのクライアントＩＤを記憶する第１のリポジトリ；
Ｖ） 前記システムプロセッサの転送コマンドを受けて、クライアントの固有ＩＤを含む第１のメッセージをクライアントからサーバーに送信するセッションイニシエータ；
VI） 前記システムプロセッサと協働して、システムプロセッサの受信コマンドを受けて前記第１のメッセージを受信し、受信したクライアントＩＤと第１のリポジトリに格納されたクライアントを識別するためのクライアントＩＤを照合するマッチングエンジンを搭載する受信機；
VII） 固有時間制限付きセッション鍵を生成し、前記システムプロセッサの送信コマンドを受けて生成したセッション鍵を転送するセッション鍵生成器；
VIII） 前記システムプロセッサと協働して、前記セッション鍵を受け取り、第１の乱数発生器によって発生された第１の乱数と前記セッション鍵を含むチャレンジコードを、システムプロセッサの発生コマンドを受けて生成し、プロセッサの送信コマンドを受けて送信するチャレンジコード生成器；
IX） 前記チャレンジコード生成器と協働して、システムプロセッサからのコマンドに応じて、前記秘密鍵生成器により秘密鍵とともに生成されたチャレンジコードを受信し、該生成されたチャレンジコードを受信して暗号化し、さらにシステムプロセッサからの送信コマンドを受けて、前記暗号化されたチャレンジコードを特定クライアントに送信する第１の暗号器；
Ｘ） 前記システムプロセッサと協働して、前記暗号化されたチャレンジコードを受信し、さらに、システムプロセッサからのコマンドに応じて、秘密鍵生成器によって生成された秘密鍵で暗号化されたチャレンジコードを復号化し、復号化された第１の乱数及びセッション鍵を得る第１の復号器；
XI） 前記第１の復号器から受信したセッション鍵を格納する第２のリポジトリ；
XII） 前記システムプロセッサと協働し、前記復号化された第１の乱数とセッション鍵を受信し、さらにシステムプロセッサからの送信コマンドを受けて、復号化された第１の乱数と、第２の乱数発生器によって生成され、セッション鍵で暗号化された第２の乱数を含む第２のメッセージを送信する第２暗号器；
XIII） 前記システムプロセッサと協働し、前記第２のメッセージを受信し、さらにシステムプロセサからのコマンドに応じて、前記第１の乱数と第２の乱数を、セッション鍵生成器によって生成されたセッション鍵を用いて復号化する第２の復号器；
XIV） 前記システムプロセッサからのコマンドに応じて、前記第２のメッセージから復号化された第１の乱数と前記第１の乱数発生器で生成された第１の乱数を比較してクライアントを認証する第１のコンパレータと認証器；
XV） 前記システムプロセッサからのコマンドに応じて、受信したセッション鍵生成器によって生成されたセッション鍵が含まれる第２のメッセージの中の第２の乱数を復号化し、システムプロセッサの送信コマンドを受けて、復号化された第２の乱数を送信する第３の暗号器；
XVI） 前記システムプロセッサからのコマンドに応じて受信し、さらにシステムプロセッサからの送信コマンドに応じて、第２のリポジトリから受信したセッション鍵で暗号化された第２の乱数を復号化する第３の復号器；及び
XVII） 前記システムプロセッサからのコマンドに応じて、前記復号化した第２の乱数と前記第２の乱数発生器によって発生された第２の乱数を比較し、サーバーの認証と相互認証を達成する第２のコンパレータと認証器；
を含むことを特徴とするシステム。

【請求項2】

請求項１記載のシステムにおいて、前記第１の乱数発生器は、前記システムプロセッサからのコマンドに応じて第１のタイマー値を生成する第１のタイマーを有するシステム。

【請求項3】

請求項１記載のシステムにおいて、前記第１の乱数発生器によって発生された第１の乱数は、前記第１のタイマー値を付加した第１の疑似乱数であるシステム。

【請求項4】

請求項１記載のシステムにおいて、前記第２の乱数発生器は、前記システムプロセッサからのコマンドに応じて第２のタイマー値を生成する第２のタイマーを有するシステム。

【請求項5】

請求項１記載のシステムにおいて、前記第２の乱数発生器によって発生された第２の乱数は、前記第２のタイマー値を付加した第２の擬似乱数であるシステム。

【請求項6】

請求項１記載のシステムにおいて、前記秘密鍵生成器によって生成された秘密鍵は、前記セッションの開始時に生成された固有の鍵であって、進行中のセッションの間のみ有効であるシステム。

【請求項7】

請求項１記載のシステムにおいて、前記セッション鍵生成器は、前記システムプロセッサからのコマンドに応じて動作するセッション鍵タイマーを有し、セッション鍵タイマーの満了により、生成されたセッション鍵を無効にし、新しいセッションの確立の要件を示すシステム。

【請求項8】

請求項１記載のシステムにおいて、前記第１の乱数発生器及び第２の乱数発生器によって発生された乱数は、再現不能であり、異なるセッションによって変化するシステム。

【請求項9】

請求項１記載のシステムにおいて、前記クライアントは、前記サーバーがクライアントの実行要求のステータスに応答しないように前記サーバーと通信することができるシステム。

【請求項10】

請求項１記載のシステムにおいて、前記システムは、ＤＴＬＳを含むトランスポート層セキュリティ方式を統合することができるシステム。

【請求項11】

請求項１記載のシステムにおいて、前記システムは、制約付きデバイスのためのＣｏＡＰ含むアプリケーション層プロトコルを統合することができるシステム。

【請求項12】

サーバーとクライアント間のデータグラム転送に関する２つの相互認証のためのコンピュータにより実施される、システム処理コマンドを含む方法であって、
第１の乱数発生器を利用して、第１の乱数を発生するステップ；
第２の乱数発生器を利用して、第２の乱数を発生するステップ；
秘密鍵生成器を利用して、システム処理コマンドに応じて秘密鍵を生成するステップ；
システム処理コマンドに応じて、双方向認証の前であって、プロビジョニング処理の間に、前記生成された秘密鍵をサーバーとクライアントに送信するステップ；
すべてのクライアントのクライアントＩＤを第１のリポジトリに記憶するステップ；
システム処理コマンドに応じて、クライアントの固有ＩＤを含む第１のメッセージを送信するステップ；
システム処理コマンドに応じて、前記第１のメッセージを受信し、受信したクライアントＩＤを第１のリポジトリに格納されているクライアントＩＤと照合するステップ；
前記受信したクライアントＩＤに基づいてクライアントを識別するステップ；
セッション鍵生成器を利用して、固有時間制限付きセッション鍵を生成するステップ；
セッション鍵を受信し、システム処理コマンドを受けて、第１の乱数発生器によって生成された第１の乱数と、前記セッション鍵を含むチャレンジコードを生成するステップ；
前記チャレンジコード生成器により生成されたチャレンジコードを受信し、システム処理コマンドに応じて、前記第１の暗号化部を利用して前記秘密鍵生成器により生成された秘密鍵で前記受信したチャレンジコードを暗号化し、暗号化したチャレンジコードをシステム処理コマンドに応じて送信するステップと；
前記暗号化されたチャレンジコードを受信し、システム処理コマンドに応じて、前記第１の復号化器を利用して、前記秘密鍵生成器により生成された秘密鍵で暗号化されたチャレンジコードを復号化し、第１の乱数とセッション鍵を取得するステップ；
前記第１の復号器からセッション鍵を受信し、第２のリポジトリに格納するステップ；
システムの処理コマンドに応じて、前記復号化された第１の乱数とセッション鍵を受信し、該復号化された第１の乱数及び前記第２の乱数発生器により発生された第２の乱数を含むセッション鍵で暗号化された第２のメッセージを送信するステップ；
システム処理コマンドに応じて、第２のメッセージを受信し、第１の乱数と第２の乱数を、前記セッション鍵生成器により生成されたセッション鍵を用いて復号化するステップ；
システムの処理コマンドに応じて、第２のメッセージからの復号化された第１の乱数と第１の乱数発生器によって発生された第１の乱数を比較するステップ；
システム処理コマンドを受けて、前記復号化された第１の乱数が前記第１の乱数発生器によって発生された第１の乱数と一致したとき、前記クライアントを認証するステップ；
システムの処理コマンドに応じて、前記セッション鍵発生器によって生成されたセッション鍵とともに受信した第２のメッセージ中の第２の乱数を暗号化し、暗号化された第２の乱数を送信するステップ；
システム処理コマンドに応じて受信し、第２のリポジトリから受信したセッション鍵で暗号化された第２の乱数を復号化するステップ；
システム処理コマンドに応じて、前記復号化された第２の乱数と前記第２の乱数発生器によって発生された第２の乱数を比較するステップ；及び
システム処理コマンドに応じて、前記復号化された第２の乱数と前記第２の乱数発生器によって発生された第２の乱数が一致するとき、相互認証を確立するためにサーバーを認証するステップ；
を含むことを特徴とする方法。

【請求項13】

請求項１２に記載の方法において、前記第１の乱数を発生するステップは、システム処理コマンドに応じて、第１の乱数を発生するために、第１のタイマー値の生成と該第１のタイマー値を第１の疑似乱数に付加するステップを含む方法。

【請求項14】

請求項１２に記載の方法において、前記第２の乱数を発生するステップは、システム処理コマンドに応じて、第２の乱数を発生するために、第２のタイマー値の生成と該第２のタイマー値を第２の擬似乱数に付加するステップを含む方法。

【請求項15】

請求項１２に記載の方法において、前記秘密鍵を生成するステップは、進行中のセッションの間のみ有効な、セッションの開始時に固有鍵の生成を含む方法。

【請求項16】

請求項１２に記載の方法において、前記セッション鍵を生成するステップは、セッション鍵タイマー値の満了に基づいてセッション鍵を無効にし、満了の上で新しいセッションの確立の要求を示すステップを含む方法。

【請求項17】

請求項１２に記載の方法において、乱数を発生するステップは、システムの処理コマンドに応じて生成する数値を含み、該数値は再現不能であって異なるセッションによって変化する方法。

【請求項18】

請求項１２に記載の方法において、クライアントは、サーバーがクライアントの実行要求のステータスに応答しないようにサーバーと通信できる方法。

【請求項19】

請求項１２に記載の方法は、ＤＴＬＳを含むトランスポート層セキュリティ方式と統合することができる方法。

【請求項20】

請求項１２に記載の方法は、制約付きデバイスのためのＣｏＡＰ含むアプリケーション層プロトコルと統合することができる方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、モノのインターネットのための認証とセキュリティに関するものである。

【背景技術】

【0002】

本明細書において以下使用される「IoT」という表現は、モノのインターネットであって、インターネットのような構造で一意に識別可能なものを指す。
本明細書において以下使用される「M2M」という表現は、無線と有線の両方のシステムにより異種のノードを含むネットワークを介してお互いの間で通信することを可能にするマシンツーマシン通信技術を指す。
本明細書において以下使用される「ノンス（nonce)」という表現は、一度だけ使用される乱数を指す。
本明細書において以下使用される「データグラム転送」という表現は、コネクションレスのトランスポートプロトコルであって、例示的で一般的な機能は、ユーザーデータグラムプロトコル（UDP）である。
本明細書において以下使用される「プロビジョニング処理」という表現は、通信前にクライアント側とサーバー側における準備をするプロセスを指す。これは、事前共有秘密を埋め込むようなステップを含む。
本明細書において以下使用される「セッションイニシエータ」という表現は、サーバーに最初の「HELLO」メッセージを送信してセッションを開始する装置を指す。これらの定義は、当該技術分野において表現されたものに追加される。

【0003】

IoT / M2Mは、物理的な実体を含み；アイデンティティまたは状態が、インターネットインフラを介してやりとりできる。 M2Mは、IoTの部分集合と考えることができる。M2Mにより動作するIoTの上に転写されるデータのパターンは、データトラフィックモデル及び参加ノード数の点で従来のインターネットとは異なる。M2Mは、従来のインターネット上での人対人（H2H）系の繋がりよりもはるかに多くのノードを扱っている。

【0004】

IoT / M2Mシステムは、通常、無線および／または有線ネットワークを介して通信が許可されたセンサのような制約付きデバイスで構成されている。この無線通信ネットワークは、通常、帯域幅の観点から制約される。そのような制約下においてドメイン認証付きの、堅牢で低オーバーヘッドの安全な通信手段を配備することが課題である。従来の公開鍵暗号方式を利用した、制約付きデバイス用の強固な証明書ベースのスキームは、処理とエネルギーと帯域幅条件にコストがかかりすぎる。さらに、もしIPレイヤにおけるセキュリティ、例えばIPSecを考慮すれば、リソースの使用およびメンテナンスの点で最適とはいえない。また、TLSのようなトランスポート層セキュリティ方式は、非常に堅牢であるにもかかわらず、制約付きデバイスのためにコストがかかることがあるので、そのリソース要件には適用されない。

【0005】

制約付きアプリケーションプロトコル（CoAP）は、インターネット上で制約付きデバイス間の双方向のコミュニケーションをRESTful（REST原則に基づいた）アーキテクチャーによって可能にする典型的なネットワークアプリケーション層プロトコルである。CoAPは、インターネットエンジニアリングタスクフォース（IETF）から主に軽量なソリューションを作成するためにユーザデータグラムプロトコル（UDP）上で動作するように設計されたIoT/ M2Mのためのセキュリティ層解法としてデータグラムトランスポート層セキュリティ（DTLS）を提案している。しかし、本格的な証明書ベースの公開鍵基盤（PKI）用のDTLSは、制約付きデバイスには最適ではない。そこで、DTLSの事前共有鍵（PSK）モードは、制約付きデバイス用の軽量代替物として定義される。このような方式は、軽量であるが堅牢性を犠牲にする。また、エンドポイントの認証を欠いている。

【0006】

CoAPでは、DTLSは、攻撃者によって増幅攻撃を起動するために送信されたClientHelloメッセージによるサービス拒否（DoS）攻撃を軽減するためにクッキー交換技術を使用している。特に、PSKモードでは、クライアントは、事前共有鍵からプレマスターシークレットとマスターシークレットを生成し、サーバーで必須の事前共有鍵を調べるためにサーバーによって使用されるクライアント鍵交換（ClientKeyExchange）メッセージを、psk_identityを含むサーバーに送信する。しかし、プレーンテキストによるクッキー交換は堅牢ではない。また、クッキー交換メカニズムは、接続確立のためのオーバーヘッドが限られた環境のため高くつくことが分かっている。

【0007】

したがって、IoT/ M2Mの制約下で使用可能な、認証された軽量でありながら堅牢なシステムにおいて明確なホワイトスペースがあることは明らかである。さらに、また、一般的なネットワーキング／通信システムの認証要件に対応できるシステムと方法が必要とされている。

【発明の概要】

【発明が解決しようとする課題】

【0008】

本発明の目的は、典型的な制約付きのIoT / M2M環境でエンドポイントを相互に認証する軽量堅牢なシステムを提供することにある。
本発明のさらに別の目的は、ハンドシェイクメッセージの少ない数を使用するという点でセキュリティ方式の軽量事前共有シークレットモードを使用するシステムを提供することにある。
本発明のさらに別の目的は、一般的なネットワーキング／通信システムの認証要求に応えるために、一般的なシステムを提供することにある。
本発明のシステムのもう1つの目的は、対称暗号化を使用して、クライアントによって開始ペイロードが埋め込まれた認証及び鍵管理を可能にするシステムを提供することである。
さらに、本発明のさらに別の目的は、DTLSのようなトランスポート層セキュリティ方式と統合することができるシステムを提供し、既存DTLSスキームを強化し、交換の数を減らすことにより、より軽量化することである。
本発明のさらなる目的は、新しいヘッダオプションが付加された、制約付きデバイスのために、CoAPのようなアプリケーション層と統合することができるシステムを提供することである。

【0009】

本発明の範囲を限定するものではない添付の図面と併せて読めば、他の目的および本発明の利点は以下の説明からより明らかになるであろう。

【課題を解決するための手段】

【0010】

本発明は、サーバーとクライアント間のデータグラム転送（移送）の２つの相互認証のためのコンピュータにより実施されるシステムを想定している。

【0011】

本発明は、サーバーとクライアント間のデータグラム転送に関する２つの相互認証のためのコンピュータにより実施される、システムプロセッサとを含むシステムであって、前記システムプロセッサと協働し、第１の乱数を発生する第１の乱数発生器；前記システムプロセッサと協働し、第２の乱数を発生する第２の乱数発生器；前記システムプロセッサと協働し、プロビジョニング処理の間の双方向認証の前に、システムプロセッサの生成コマンド及び送信コマンドを受けて秘密鍵を生成してサーバー及びクライアントに送信する秘密鍵生成器；すべてのクライアントのクライアントＩＤを記憶する第１のリポジトリ；前記システムプロセッサの転送コマンドを受けて、クライアントの固有ＩＤを含む第１のメッセージをクライアントからサーバーに送信するセッションイニシエータ；前記システムプロセッサと協働して、システムプロセッサの受信コマンドを受けて前記第１のメッセージを受信し、受信したクライアントＩＤと第１のリポジトリに格納されたクライアントを識別するためのクライアントＩＤを照合するマッチングエンジンを搭載する受信機；固有時間制限付きセッション鍵を生成し、前記システムプロセッサの送信コマンドを受けて生成したセッション鍵を転送するセッション鍵生成器；前記システムプロセッサと協働して、前記セッション鍵を受け取り、セッション鍵を受け取り、第１の乱数発生器によって発生された第１の乱数と前記セッション鍵を含むチャレンジコードをシステムプロセッサの発生コマンドを受けて生成し、プロセッサの送信コマンドを受けて送信するチャレンジコード生成器；前記チャレンジコード生成器と協働して、システムプロセッサからのコマンドに応じて、前記秘密鍵生成器により秘密鍵とともに生成されたチャレンジコードを受信し、前記チャレンジコード生成器によって生成されたチャレンジコードを受信して暗号化し、さらにシステムプロセッサの送信コマンドを受けて、前記復号化されたチャレンジコードを特定されたクライアントに送信する第１の暗号器；前記システムプロセッサと協働して、暗号化されたチャレンジコードを受信し、さらに、システムプロセッサからのコマンドに応じて秘密鍵生成器によって生成された秘密鍵で暗号化されたチャレンジコードを復号化し、復号化された第１の乱数及びセッション鍵を得る第１の復号器；前記第１の復号器から受信したセッション鍵を格納する第２のリポジトリ；前記システムプロセッサと協働し、前記復号化された第１の乱数とセッション鍵を受信し、さらにシステムプロセッサからの送信コマンドを受けて、復号化された第１の乱数と、第２の乱数発生器によって発生され、セッション鍵で暗号化された第２の乱数を含む第２のメッセージを送信する第２暗号器；前記システムプロセッサと協働し、前記第２のメッセージを受信し、さらにシステムプロセサからのコマンドに応じて、前記第１の乱数と第２の乱数を、セッション鍵生成器によって生成されたセッション鍵を用いて復号化する第２の復号器；前記システムプロセッサからのコマンドに応じて、前記第２のメッセージから復号化された第１の乱数と前記第１の乱数発生器により発生された第１の乱数をを比較してクライアントを認証する第１のコンパレータと認証器；前記システムプロセッサからのコマンドに応じて、受信したセッション鍵生成器によって生成されたセッション鍵が含まれる第２のメッセージの中の第２の乱数を復号化し、システムプロセッサの送信コマンドを受けて、復号化された第２の乱数を送信する第３の暗号器；前記システムプロセッサからのコマンドに応じて受信し、さらにシステムプロセッサの送信コマンドを受けて、第２のリポジトリから受信したセッション鍵で暗号化された第２の乱数を復号化する第３の復号器；及び前記システムプロセッサからのコマンドに応じて、前記復号化した第２の乱数と前記第２の乱数発生器によって発生された第２の乱数を比較し、サーバーの認証と相互認証を達成する第２のコンパレータと認証器；を含むことを特徴とする。

【0012】

本発明の方法は、サーバーとクライアント間のデータグラム転送に関する２つの相互認証のためのコンピュータにより実施されるシステム処理コマンドを含む方法であって、第１の乱数発生器利用して、第１の乱数を発生するステップ；第２の乱数発生器を利用して、第２の乱数を発生するステップ；秘密鍵生成器を利用して、システム処理コマンドに応じて秘密鍵を生成するステップ；システム処理コマンドに応じて、双方向認証の前であって、プロビジョニング処理の間に、前記生成された秘密鍵をサーバーとクライアントに送信するステップ；すべてのクライアントのクライアントＩＤを第１のリポジトリに記憶するステップ；システム処理コマンドに応じて、クライアントの固有ＩＤを含む第１のメッセージを送信するステップ；システム処理コマンドに応じて、前記第１のメッセージを受信し、受信したクライアントＩＤを第１のリポジトリに格納されているクライアントＩＤと照合するステップ；前記受信したクライアントＩＤに基づいてクライアントを識別するステップ；セッション鍵生成器を利用して、固有時間制限付きセッション鍵を生成するステップ；セッション鍵を受信し、システム処理コマンドを受けて、第１の乱数発生器によって生成された第１の乱数と、前記セッション鍵を含むチャレンジコードを生成するステップ；前記チャレンジコード生成器により生成されたチャレンジコードを受信し、システム処理コマンドに応じて、前記第１の暗号化部を利用して前記秘密鍵生成器により生成された秘密鍵で前記受信したチャレンジコードを暗号化し、暗号化したチャレンジコードをシステム処理コマンドに応じて送信するステップと；前記暗号化されたチャレンジコードを受信し、システム処理コマンドに応じて、前記第１の復号化器を利用して、前記秘密鍵生成器により生成された秘密鍵で暗号化されたチャレンジコードを復号化し、第１の乱数とセッション鍵を取得するステップ；前記第１の復号器からセッション鍵を受信し、第２のリポジトリに格納するステップ；システムの処理コマンドに応じて、前記復号化された第１の乱数とセッション鍵を受信し、該復号化された第１の乱数及び前記第２の乱数発生器により発生された第２の乱数を含むセッション鍵で暗号化された第２のメッセージを送信するステップ；システム処理コマンドに応じて、第２のメッセージを受信し、第１の乱数と第２の乱数を、前記セッション鍵生成器により生成されたセッション鍵を用いて復号化するステップ；システムの処理コマンドに応じて、第２のメッセージからの復号化された第１の乱数と第１の乱数発生器によって発生された第１の乱数を比較するステップ；システム処理コマンドを受けて、前記復号化された第１の乱数が前記第１の乱数発生器によって発生された第１の乱数と一致したとき、前記クライアントを認証するステップ；システムの処理コマンドに応じて、前記セッション鍵発生器によって生成されたセッション鍵とともに受信した第２のメッセージ中の第２の乱数を暗号化し、暗号化された第２の乱数を送信するステップ；システム処理コマンドに応じて受信し、第２のリポジトリから受信したセッション鍵で暗号化された第２の乱数を復号化するステップ；システム処理コマンドに応じて、前記復号化された第２の乱数と前記第２の乱数発生器によって発生された第２の乱数を比較するステップ；及びシステム処理コマンドに応じて、前記復号化された第２の乱数と前記第２の乱数発生器によって発生れた第２の乱数が一致するとき、相互認証を確立するためにサーバーを認証するステップ；を含むことを特徴とする。

【発明の効果】

【0013】

本発明によれば、制約付きのIoT / M2M環境においてエンドポイントを相互に認証する軽量堅牢なシステムと方法を提供することができる。

【図面の簡単な説明】

【0014】

本発明のシステムについて、添付の図面を参照して説明する。

【図1】サーバーとクライアント間の相互認証を提供するシステムの概略を示す図である。

【図2】相互認証と安全な通信を実現するためのシステムフローを示す図である。

【図3】サーバーとクライアント間のハンドシェイク中に含まれる手順を示す図である。

【図4】本発明の実施形態として、既存のアプリケーション層プロトコルに埋め込むためにCoAPメッセージ形式の導入ヘッダーオプションを示す図である。

【図5】センサデバイス（クライアント）とサーバー間の典型的な認証ハンドシェイクを示す図である。

【図6】DTLSのようなセキュリティ層と認証のための追加の層として、本発明のシステムの統合を示す図である。

【図7】事前共有鍵モード（PSK）での安全なセッション開始のための通常のDTLSハンドシェイクのタイミングを示す図である。

【図8】本発明に係る事前共有秘密により修正されたDTLSハンドシェイクの様子を示す図である。

【発明を実施するための形態】

【0015】

本発明のシステムを、添付図面に示した実施形態に基づいて説明する。この実施形態は、本発明の範囲と領域を限定するものではない。説明は単に例を示すものであり、また本発明の好ましい実施形態及び推奨する応用を示すためのものである。

【0016】

本明細書において、システム、さまざまな特徴及びその利点の詳細を以下のいくつかの実施形態によって説明するが、これらは本発明の範囲を限定するものではない。実施形態の説明を明確にするため、既知の構成部品や処理技術については省略する。ここで取り上げる各例は、その実行と当分野の技術者が各例を実施するための理解を容易にする目的でのみ示されるものである。よって、これらの例は実施形態の範囲を限定するものと解釈すべきではない。

【0017】

本発明によれば、システムは、事前共有秘密を共有する二つのエンドポイント間におけるチャレンジ−レスポンス交換に基づいて、軽量かつ強固な認証方式を提供する。本発明が提案するセキュリティソリューションは、鍵管理が認証と統合された、対称鍵に基づくセキュリティメカニズムである。これは、サーバーとクライアント間のデータグラムの転送上の双方向認証を提供するIoT / M2Mに適している。

【0018】

本発明のシステムは、低オーバーヘッドの相互認証を提供する。相互認証を達成するために、システム内のエンドポイントは、プロビジョニング処理中に事前共有鍵を使用して事前設定（provisioned）され、クライアントのデータベースは、クライアントを識別するためのサーバー側に設けられている。システムはまた、擬似乱数（PRN）モジュール及びナンス(nonces)を生成するためのタイマー（システム時間）、およびサーバー鍵生成モジュールを含む。ナンスと鍵は、安全な認証を提供する助けになる。チャレンジメッセージは、認証プロセス中にサーバーとクライアント側の両方から生成される。 AES暗号化および復号（解読）化は、クライアント側とサーバー側で使用される。

【0019】

本発明のシステムは、さらに、PSKモードを使用してDTLSのようなトランスポート層セキュリティプロトコルに適合させることができる。適合させるための手順は、DTLSの上に暗号化されたノンスに基づいたチャレンジレスポンスを使用して認証セッションを確立し、使用するための安全なチャネルを確立することを含む。

【0020】

添付の図面を参照すると、図1は、システムプロセッサ１０２のコマンドに基づいて、サーバー５０とクライアント２０との間で相互認証をするシステム１００の概略図である。本発明のシステム１００は、事前共有秘密を共有する２つのエンドポイント間のチャレンジ-レスポンス交換に基づく認証スキームを提案する。この事前共有秘密は、システムプロセッサ１０２からの生成コマンドに基づいて秘密鍵生成器１０によって生成される。本発明のセキュリティソリューションは鍵管理が認証と統合された、対称鍵に基づくセキュリティメカニズムである。プロビジョニング処理の間、エンドポイントは、事前共有秘密と共に構成されている。クライアント２０のセッションイニシエータ２２は、サーバー５０からクライアントに固有の識別子（ＩＤ）を使用してHELLOメッセージを送信して、セッションを開始する。サーバー５０の受信機５４は、システムプロセッサ１０２からのコマンドを受けてメッセージを受信し、最初にすべてのクライアントＩＤを格納したリポジトリ５２内から前記ＩＤを検索する。
しかし、悪意のあるクライアントによるスプーフィングを防ぐために、サーバー５０は、チャレンジコードジェネレータ６０を利用してチャレンジコードを生成する。このチャレンジコードは、セッション鍵生成部５８によって生成された固有のセッション鍵「ｋ」と第１の乱数発生器５６によって発生された乱数「nonce1」からなる。セッション鍵生成部５８は、生成するセッション鍵の有効性を判断するために適切なセッション鍵タイマー値を生成するセッション鍵タイマー（図示せず）を有する。従って、セッション鍵「ｋ」は、セッション鍵タイマー値に基づいて無効にされる。セッション鍵タイマー値の満了は、その鍵の失効と新しいセッション鍵を使用して新しいセッションを確立するための必要性を示す。
第1の乱数発生部５６は、第１のタイマー値を生成する第１のタイマー（図示せず）を有する。第1の乱数発生器５６によって発生される「nonce1」は、この第１のタイマー値を付加した擬似乱数（PRN）である。そしてチャレンジコードは、秘密鍵生成器１０によって生成及び共有された事前共有鍵を使用して第１の暗号化部６２によって暗号化される。このチャレンジコードはクライアントに送信される。正当なクライアント２０は、チャレンジコードを、秘密鍵生成器１０によって共有された秘密鍵を利用して第１の復号化部２４を介して復号化し、さらに「nonce1」およびサーバー５０によって供給されるセッション鍵「ｋ」を取得できる。復号化されたセッション鍵「k」は、第２のレポジトリ２６に格納される。さらに、クライアント２０は、チャレンジコードに応じて、サーバー５０から受信した「nonce1」とクライアント２０において第２の乱数発生器３０が発生した「nonce2」を含む応答メッセージを生成する。第２の乱数発生部３０は、第２のタイマー値を生成する第２のタイマー（図示せず）を有する。この第２のタイマー値は、「nonce2」を形成するために、別の疑似乱数（PRN）に付加される。応答メッセージは、第１の復号器２４によって先に解読されたセッション鍵「ｋ」を用いて第２の暗号化部２８によって暗号化される。応答メッセージを受信すると、サーバー５０の第２の復号器６４は、クライアント２０からの応答を解読し、その「nonce1」が、サーバー５０が所有する（第１の乱数発生器５６からの）複製である「nonce1」と一致するか否か第１のコンパレータと認証器６６を用いて照合する。それらが一致したとき、サーバー５０は、第１のコンパレータ及び認証器６６によりそのクライアント２０を認証し、さらに、システムプロセッサ１０２からのコマンドに基づいてクライアント２０に、セッション鍵「ｋ」と第３の暗号化器６８を利用して暗号化された受信「nonce2」を含むメッセージを送信する。クライアントは、「nonce2」を、第３の復号化器３２を利用して第２のレポジトリ２６に格納されたセッション鍵「ｋ」を使用して解読する。復号化された「nonce2」は、第２のコンパレータ及び認証器３４を利用して第２の乱数発生器３０によって生成された「nonce2」と一致する。復号化された「nonce2」がクライアント２０の「nonce2」と一致したとき、サーバー５０は第２のコンパレータ及び認証器６６により認証され、相互認証が実現する。

【0021】

ナンスと鍵は、異なるセッションを切り替えるために使用される。生成されたナンスは、タイマー（カウンタ）からのタイマー値が付加された擬似乱数（PRN）からなるので、再現不能である。これは、反射攻撃に対する耐性を提供する。

【0022】

添付の図面を参照すると、図２は、相互認証と安全な通信を実現するためのシステムフローを示す図である。サーバーとクライアントは、プロビジョニング処理中に事前共有秘密（ｙ）で設定されている２つのエンドポイントである。プロビジョニング処理が完了した後、クライアントは、認証要求をサーバーに送信する（２００）。このセッションは、固有クライアントIDに従って「HELLO」メッセージをサーバーに送信することにより開始される。サーバーは、このメッセージを受信した後、事前構成済データベース内のクライアントIDを検索する。しかし、サーバーは、固有鍵（k）およびランダムノンス（nonce1）を含むチャレンジコードを生成し（２０２）、悪意あるクライアントのなりすまし（スプーフィング）を防止する。
チャレンジコードは、事前共有秘密（y）により暗号化され、クライアントに送信される。正当なクライアントは、チャレンジコードを事前共有秘密（Y）により復号化し（２０４）、サーバーから供給されたナンスと鍵を取得することができる。応じて、クライアントは、サーバーから受信したノンス（nonce1）と、クライアントにより生成されたノンス（nonce2）を含み、受信した固有鍵（k）を使用して暗号化された応答メッセージを作成する（２０６）。サーバーは、クライアントからの応答を復号化し、nonce1をサーバーが所有する複製であるnonce1と照合する（２０８）。２つのナンスが一致していないとき、クライアントは認証されない（２１２）。２つのナンスが一致しているとき、クライアントは認証され、鍵の共有は完了する（２１０）。クライアントの承認後、サーバーは、ｋと連結され、ｙで暗号化されたnonce2によりクライアントチャレンジに応答する（２１４）。クライアント側では、サーバーの応答がクライアントのチャレンジを満たすとき、サーバーから受信したnonce2がクライアントが複製したnonce2と一致するか否かチェックする（２１６）。クライアントは、nonce2を自身のコピーと照合することができ、それらが一致したとき、サーバーを認証する（２１８）。ナンスが一致しなかったとき、サーバーは認証されない（２２０）。一度クライアントとサーバーの双方が認証されると、これらの間で安全なチャンネルが確立される（２２２）。

【0023】

ナンスと鍵は、異なるセッションを切り替える認証プロセスの間に使用される。セッションは、タイマーを使用してリフレッシュされる。本発明のシステムは、各セッション中に固有の鍵と固有の128ビットのノンスを提供するために、タイマー（カウンタ）を付加した擬似乱数発生器（PRNG）を含む。ナンスは、単調増加の自然Ｔ_j（タイマー）に従うランダム性により再現不能な乱数Ｒ_j（PRN）である。Ｒ_jは、擬似乱数発生方法で生成され、Ｔ_jに包含されているので、リプレイ攻撃される可能性が極めて低いことを保証する。

攻撃の衝突確率は、２^-56程度である。
ナンスの間で予測可能な非再現性は１６ビットのＴ_jによって支配され、非予測可能な部分はＲ_jによって支配されている。

【0024】

添付の図面を参照すると、図３は、サーバーとクライアントとの間のハンドシェイク中に含まれるステップを示す図である。それは、鍵管理アルゴリズムと軽量相互認証を示していて、Ｄ_iはクライアントを表し、Gはサーバーを表している。認証プロセスが開始される前に、秘密

は、プロビジョニング処理がオフラインのとき、Ｄ_iとGの間で共有される。認証プロセスは、クライアントＤ_iが「HELLO、＃Ｄ_i」をサーバーＧ３００に送信するセッション開始とともに開始される（３００）。ここで、＃Ｄ_iは固有のクライアントデバイスＩＤである。一度セッションが開始されると、サーバーGは、

及びメッセージサイズ２５６ビットのチャレンジコード

をクライアントに送信することによって応答する（３０２）。クライアントは、チャレンジコードを復号化し、サーバーに、nonce1と追加のnonce２を含む他のチャレンジコード

を送信する（３０４）。これは、クライアントの応答及びチャレンジである。サーバー側では、サーバーは、nonce1を検証し、

としてのｋ_iで暗号化されたnonce2をクライアントに送信することで応答する（３０６）。クライアントとサーバーの両側がnonceの検証と認証を完了すると、クライアントはデータρ_iを

としてサーバーに送信する（３０８）。

【0025】

添付の図面を参照すると、図４および図５は、一般的なスキームの例示的な用途とセンサデバイス（クライアント）とサーバーそれぞれの間の一般的な認証ハンドシェイクなどの既存のアプリケーション層プロトコル（４００）に、本発明のシステムを埋め込んだ後の修正されたＣｏＡＰメッセージフォーマットを示している。

【0026】

CoAPの一般的な相互作用モデルは、HTTPのクライアント／サーバーモデルに類似しており、RESTfulである。しかし、HTTPとは異なり、CoAPは、UDPのようなデータグラム指向のトランスポート上のインターチェンジと非同期で対応する。通常CoAPは、「確認可能」、「確認不能」、「承認」及び「リセット」の４種類のメッセージを含みむ。これらのメッセージは、メソッドまたはレスポンスコードに応じた要求または応答を運ぶ。

【0027】

本発明の認証方式は、CoAPに埋め込まれたRESTfulのペイロードとして統合することができる。それは図５に見られるように、確認可能な（CON）データ転送モードとPOSTメソッドは、センサデバイス（クライアント）とサーバー間の相互認証を達成するために適用される。新しいフィールド「AUTH」は、セキュア（認証）モード４００を有効にするためにCoAPヘッダに導入される。このフィールドは、重要なオプションクラスを示す未使用のオプションに使用される。「AUTH_MSG_TYPE」という別のオプションは、認証セッションを確立するための別のメッセージを示すために、「AUTH」と一緒に導入される。

【0028】

CoAPヘッダ内のオプションフィールドは、CoAPメッセージ内の任意の要求／応答の機能を運ぶ。本発明のために定義されたフィールドは、次の通りである。
＊ AUTH：認証／無効認証モードの有効化を示している。
TrueまたはFalseの値がこのフィールドに設定することができる。
＊ AUTH_MSG_TYPE：このフィールドは、「０」または「１」のいずれかであり、ここで、0 = auth_init、1 = 「response_against_challenge」である。

【0029】

「AUTH = True」に設定することによって認証セッションが有効になったときに、ヘッダに認証処理中に交換されるすべての関連するメッセージのための「Token」の定数値を使用することによって認証セッションが保たれる。

【0030】

図４と図５を参照すると、認証をCoAPに埋め込むために以下のステップが実行される。
＊ 開始時に、センサー−ゲートウェイは、POSTメッセージをCONモードでサーバーの認証URIに、AUTHオプションフィールドTrue、「auth_init」例えば「０」のAUTH_MSG_TYPE値および「デバイス識別子」をペイロードとして送信する（６００）。
＊ サーバーは、ペイロードからデバイス識別子を引き出し、事前共有オプション「AUTH」を受信した後、そのデバイス識別子に関連付けられた秘密、そしてAUTH_MSG_TYPEのための「auth_init'」の値を決定する。その後、ナンス（nonce_1）と鍵（K）を生成する。サーバーは、共有秘密を使用して暗号化されたペイロードを生成する。
＊ サーバーは、新しいリソースを示す応答コードが作成されたことをクライアントに送り返す。応答におけるURIは、認証のために全体のハンドシェイクのための一時的なセッションIDを示している。無効なデバイス識別子の場合には、サーバーは、「不正」の応答コードを送信する。暗号化されたペイロードは、ピギーバックまたは別々にクライアントに送信される（６０２）。
＊ クライアントは、サーバーから受信した応答を解読し、nonce_1と「Ｋ」を得る。そして、クライアントはナンス（nonce_2）を生成し、鍵「K」を用いて暗号化されたペイロードを生成する。それから、クライアントはこのペイロードをオプションフィールド「AUTH」とともに、「response_against_challenge」としてAUTH_MSG_TYPE値、および最後のPOSTメッセージと同じトークン値を持つPOSTメッセージを使用して送信する（６０４）。
＊ 鍵リフレッシュタイマーは、セッションをリフレッシュするために維持されている。（CoAPの場合、この値は、MAX_RETRANSMIT_COUNT × MAX_RETRANSMISSION_TIMEOUT よりも大きくなければならない。）
＊ サーバーは、上記POSTのペイロードをヘッダー内の任意の値とともに「K」を用いて復号化し、受信したナンスをチェックする。サーバーは、nonceが（ステップ２で生成された）前の値と同じであると認証されたとき、リソースの変更が認証されたことを示す応答コード「Changed」を送信し、そうでなければ「認証されていない」ことを示す応答を送信する（６０６）。

【0031】

図５を参照して使用される表記は以下のとおりである。

【0032】

認証処理が終わり、セキュアなチャネルが確立された後、クライアンがサーバーの応答に無関心であることを表示した場合など、サーバー内の一部のリソースを更新している間に、クライアントは、必要に応じて完全なオープンループモードで通信することができる。

【0033】

本発明のシステムの一実施形態では、CoAPはNON（信頼性の無い）モードで使用され、オプションフィールド（例えば無応答）は、サーバーがリソース実行のステータスを応答する必要がないことを示すために導入される。これにより、ネットワーク上の負荷が軽減される。「NO-RESPONSE」フィールド値は、“０”または“１”であり、“０”はサーバーがステータスを応答する必要があることを示し、“１”は、サーバーが応答する必要がないことを示している。

【0034】

添付の図面を参照すると、図６は、DTLSのようなセキュリティ層による認証のための追加の層として本発明のシステムに統合した様子を示している（５００）。

【0035】

添付の図面を参照すると、図７は、事前共有鍵モード（PSK）によるセキュアなセッション開始のためのDTLSハンドシェイクのタイミング図を示し、図８は、本発明の方法を、安全な接続を確立する前に、派生鍵に加えて、事前共有秘密を持つ変更されたDTLSハンドシェークに帰着したDTLSフレームワークと統合した様子を示している。全てのハンドシェイクメッセージは、事前共有秘密または派生鍵Ｋによって暗号化されている。図７の符号“*”は、状況依存型のメッセージを示している。図８は、図３に示すようにメッセージ交換サーバーとクライアント間のハンドシェイク時に含まれるステップ間のマッピングを示している。図7および図8を参照すると、本発明のシステムは、従来６回必要であったハンドシェークを４回まで減少させている。

【0036】

本明細書で説明した本発明によるデータグラムの転送上の軽量認証のためのコンピュータ実施システムおよび方法は、以下の技術的な向上を含むが、これらに限定されない技術的な向上も含む。
＊ セッション鍵リフレッシュタイマーを持つ、統合鍵管理と、ペイロードが埋め込まれた対称鍵ベース認証によりオーバーヘッドを減少するシステム。
＊ リソースに制約されたセンサデバイスを保護するのに最適的なシステム。
＊ 交換の数を減らすことによりDTLSを軽量化するだけでなく、既存のDTLSスキームを強化するためにDTLSのようなトランスポート層セキュリティ方式と統合できるシステム。
＊ ペイロード埋め込み認証スキームとしてアプリケーションプロトコルを適応させることができるシステム。
＊ 制約されたデバイスのためにCoAPのようなアプリケーション層と統合することができるシステム。
＊ 認証された後のリソースの使用を最適化するために、アプリケーション層プロトコルに新しいヘッダオプションを導入することによりCoAPの開ループ通信を可能にするシステムが得られた。
＊ 一般的なネットワーキング／通信システムの認証要件に応えるシステム。

【0037】

特定の実施形態は、現行の知識をもとに、簡単にその変更や適用を行い、基本的概念から出発することなく、即にその広い応用ができるよう、また、類推による理解を深めることのできるよう、発明の性質を全般的に示したものである。本文で使用した表現や用語は説明を目的とするもので、限定を目的としないことを理解すべきである。さらに、実施形態は、好ましい物を取り上げてはいるが、技術者は、それら実施形態に変更を加えて、実施形態の意図と適用範囲を継承しつつその応用ができることを認識できる。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【外国語明細書】