特許 7440026 分散化認証方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-02-19

(45)【発行日】2024-02-28

(54)【発明の名称】分散化認証方法

(51)【国際特許分類】

   H04L 9/32 20060101AFI20240220BHJP

   G06F 21/44 20130101ALI20240220BHJP

【ＦＩ】

H04L9/32 200D

G06F21/44 350

【請求項の数】 19

(21)【出願番号】P 2021519003

(86)(22)【出願日】2019-05-31

(65)【公表番号】

(43)【公表日】2021-10-21

(86)【国際出願番号】 GB2019051524

(87)【国際公開番号】W WO2019239108

(87)【国際公開日】2019-12-19

【審査請求日】2022-05-18

(31)【優先権主張番号】1809887.1

(32)【優先日】2018-06-15

(33)【優先権主張国・地域又は機関】GB

(73)【特許権者】

【識別番号】520494024

【氏名又は名称】イオシック エルティディ

(74)【代理人】

【識別番号】110001807

【氏名又は名称】弁理士法人磯野国際特許商標事務所

(72)【発明者】

【氏名】オートリ、クリストファー パトリック

(72)【発明者】

【氏名】ロスコ、アンドルー ウィリアム

(72)【発明者】

【氏名】マーガル、ミハイロ

【審査官】行田 悦資

(56)【参考文献】

【文献】韓国公開特許第２０１８－０００３１９６（ＫＲ，Ａ）

【文献】特表２００９－５１５４４８（ＪＰ，Ａ）

【文献】米国特許出願公開第２００６／０２８２６６２（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｌ ９／３２

Ｇ０６Ｆ ２１／４４

(57)【特許請求の範囲】

【請求項1】

プロキシデバイスを用いて第２デバイスに対して第１デバイスが真正であることを証明する方法であって、
前記第１デバイスは第１デバイスデータと第１デバイス秘密鍵を保存し、
前記第２デバイスは第２デバイスデータと第２デバイス秘密鍵を保存し、
前記第１デバイスデータはさらに前記第２デバイスおよび前記プロキシデバイスによって保存され、
前記第２デバイスデータはさらに前記第１デバイスおよび前記プロキシデバイスによって保存され、
前記方法はコミットメント段階では、
前記第１デバイスが前記第１デバイスデータおよび第１デバイス秘密鍵情報を用いて、ワンタイム第１デバイスコミットメント値を発生するステップであって、前記第１デバイス秘密鍵情報は前記第１デバイス秘密鍵および第１ランダムノンスを有するか、または前記第１デバイス秘密鍵および前記第１ランダムノンスから導出されたものであるステップと、
前記第１デバイスは前記ワンタイム第１デバイスコミットメント値を前記プロキシデバイスに送るステップと、
前記第２デバイスが前記第２デバイスデータおよび第２デバイス秘密鍵情報を用いて、ワンタイム第２デバイスコミットメント値を発生するステップであって、前記第２デバイス秘密鍵情報は前記第２デバイス秘密鍵および第２ランダムノンスを有するか、または前記第２デバイス秘密鍵および前記第２ランダムノンスから導出されたものであるステップと、
前記第２デバイスが前記ワンタイム第２デバイスコミットメント値を前記プロキシデバイスに送るステップと、を含み
前記方法は前記コミットメント段階の後で行われるチェック段階でさらに
前記第１デバイスが前記第１デバイス秘密鍵情報を前記プロキシデバイスに伝送するステップと、
前記第２デバイスが前記第２デバイス秘密鍵情報を前記プロキシデバイスに伝送するステップと、
前記プロキシデバイスが、前記プロキシデバイスが保存する前記第１デバイスデータと前記第１デバイスから受け取った前記第１デバイス秘密鍵情報を用いて、前記第１デバイスから受け取った前記ワンタイム第１デバイスコミットメント値が真正であることを確認するステップと、
前記プロキシデバイスが、前記プロキシデバイスが保存する前記第２デバイスデータと前記第２デバイスから受け取った前記第２デバイス秘密鍵情報を用いて、前記第２デバイスから受け取った前記ワンタイム第２デバイスコミットメント値が真正であることを確認するステップと、を含み、
前記方法は前記コミットメント段階で前記ワンタイム第１デバイスコミットメント値および前記ワンタイム第２デバイスコミットメント値が真正であることを確認した後に行われるダイジェスト段階でさらに、
前記プロキシデバイスが
ｉ）前記プロキシデバイスが保存する前記第１デバイスデータと、
ｉｉ）前記プロキシデバイスが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイスから受け取った前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイスから受け取った前記第２デバイス秘密鍵情報と、
からワンタイムダイジェスト値を算出するステップと、
前記プロキシデバイスが前記ワンタイムダイジェスト値を前記第２デバイスに送るステップと、
前記第２デバイスが少なくとも、
ｉ）前記第２デバイスが保存する前記第１デバイスデータと、
ｉｉ）前記第２デバイスが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイスから受け取った前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイス秘密鍵情報と、を用いて前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認することによって、前記第２デバイスが前記第１デバイスを認証するステップと、を含む。

【請求項2】

前記プロキシデバイスが前記ワンタイムダイジェスト値を前記第１デバイスに送るステップと、
前記第１デバイスが少なくとも、
ｉ）前記第１デバイスが保存する前記第１デバイスデータと、
ｉｉ）前記第１デバイスが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイスから受け取った前記第２デバイス秘密鍵情報と、を用いて前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認することによって、前記第１デバイスが前記第２デバイスを認証するステップと、をさらに含む請求項１に記載する方法。

【請求項3】

前記プロキシデバイスが前記ワンタイム第１デバイスコミットメント値および前記ワンタイム第２デバイスコミットメント値が真正であることを確認し、さらに前記第１デバイスおよび前記第２デバイスが一つ以上のワンタイムコミットメント値が真正であることを確認する請求項１または２に記載する方法。

【請求項4】

前記プロキシデバイスはプロキシデータおよびプロキシデバイス秘密鍵を保存しており、
前記プロキシデバイスが前記プロキシデータおよびプロキシデバイス秘密鍵情報を用いてワンタイムプロキシデバイスコミットメント値を発生するステップであって、前記プロキシデバイス秘密鍵情報は前記プロキシデバイス秘密鍵と第３ランダムノンスを含むか、または前記プロキシデバイス秘密鍵と前記第３ランダムノンスから導出されるステップをさらに含む請求項１乃至３のいずれかに記載する方法。

【請求項5】

前記第２デバイスは前記プロキシデータを保存し、
前記プロキシデバイスが前記ワンタイムプロキシデバイスコミットメント値を前記第２デバイスに送るステップと、
前記プロキシデバイスが前記プロキシデバイス秘密鍵情報を前記第２デバイスに伝送するステップと、
前記第２デバイスが前記第２デバイス中に保存された前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムプロキシデバイスコミットメント値が真正であることを確認するステップと、をさらに含む請求項４に記載する方法。

【請求項6】

前記プロキシデバイスが前記プロキシデータおよび前記プロキシデバイス秘密鍵情報を用いて、さらに前記ワンタイムダイジェスト値を計算するステップと、
前記第２デバイスが前記第１デバイスを認証する時に、前記第２デバイスがさらに前記第２デバイスが保存する前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認するステップと、をさらに含む請求項５に記載する方法。

【請求項7】

前記第１デバイスは前記プロキシデータを保存し、
前記プロキシデバイスが前記ワンタイムプロキシデバイスコミットメント値を前記第１デバイスに送るステップと、
前記プロキシデバイスが前記プロキシデバイス秘密鍵情報を前記第１デバイスに伝送するステップと、
前記第１デバイスが前記第１デバイス中に保存された前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記ワンタイムプロキシデバイスコミットメント値が真正であることを確認するステップと、をさらに含む請求項４乃至６のいずれかに記載する方法。

【請求項8】

前記プロキシデバイスが前記プロキシデータおよび前記プロキシデバイス秘密鍵情報を用いて、さらに前記ワンタイムダイジェスト値を計算するステップと、
前記第１デバイスが前記第２デバイスを認証する時に、前記第１デバイスが、前記第１デバイスが保存する前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認するステップと、をさらに含む請求項７に記載する方法。

【請求項9】

第１デバイスと、
第２デバイスと、
プロキシデバイスと、を有する通信システムであって、
前記第１デバイスは第１デバイスデータと第１デバイス秘密鍵を保存し、
前記第２デバイスは第２デバイスデータと第２デバイス秘密鍵を保存し、
前記第１デバイスデータはさらに前記第２デバイスおよび前記プロキシデバイスによって保存され、
前記第２デバイスデータはさらに前記第１デバイスおよび前記プロキシデバイスによって保存され、
コミットメント段階では、
前記第１デバイスが前記第１デバイスデータおよび第１デバイス秘密鍵情報を用いて、ワンタイム第１デバイスコミットメント値を発生し、前記第１デバイス秘密鍵情報は前記第１デバイス秘密鍵および第１ランダムノンスを有するか、または前記第１デバイス秘密鍵および前記第１ランダムノンスから導出されたものであり、
前記第１デバイスは前記ワンタイム第１デバイスコミットメント値を前記プロキシデバイスに送り、
前記第２デバイスが前記第２デバイスデータおよび第２デバイス秘密鍵情報を用いて、ワンタイム第２デバイスコミットメント値を発生し、前記第２デバイス秘密鍵情報は前記第２デバイス秘密鍵および第２ランダムノンスを有するか、または前記第２デバイス秘密鍵および前記第２ランダムノンスから導出されたものであり、
前記第２デバイスが前記ワンタイム第２デバイスコミットメント値を前記プロキシデバイスに送り、
前記コミットメント段階の後に行われるチェック段階では、
前記第１デバイスが前記第１デバイス秘密鍵情報を前記プロキシデバイスに伝送し、
前記第２デバイスが前記第２デバイス秘密鍵情報を前記プロキシデバイスに伝送し、
前記プロキシデバイスが、前記プロキシデバイスが保存する前記第１デバイスデータと前記第１デバイスから受け取った前記第１デバイス秘密鍵情報を用いて、前記第１デバイスから受け取った前記ワンタイム第１デバイスコミットメント値が真正であることを確認し、
前記プロキシデバイスが、前記プロキシデバイスが保存する前記第２デバイスデータと前記第２デバイスから受け取った前記第２デバイス秘密鍵情報を用いて、前記第２デバイスから受け取った前記ワンタイム第２デバイスコミットメント値が真正であることを確認し、
さらに前記チェック段階で前記ワンタイム第１デバイスコミットメント値および前記ワンタイム第２デバイスコミットメント値が真正であることを確認すると、前記プロキシデバイスはダイジェスト段階に移行し、
前記ダイジェスト段階では、
前記プロキシデバイスが
ｉ）前記プロキシデバイスが保存する前記第１デバイスデータと、
ｉｉ）前記プロキシデバイスが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイスから受け取った前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイスから受け取った前記第２デバイス秘密鍵情報と、
からワンタイムダイジェスト値を算出し、
前記プロキシデバイスが前記ワンタイムダイジェスト値を前記第２デバイスに送り、
前記第２デバイスが少なくとも、
ｉ）前記第２デバイスが保存する前記第１デバイスデータと、
ｉｉ）前記第２デバイスが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイスから受け取った前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイス秘密鍵情報と、を用いて前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認することによって、前記第２デバイスが前記第１デバイスを認証する通信システム。

【請求項10】

前記第１デバイス、前記第２デバイスおよび前記プロキシデバイスのうち少なくとも一つはセンサーまたはセンサーハブである請求項９に記載する通信システム。

【請求項11】

前記プロキシデバイスがさらに前記ワンタイムダイジェスト値を前記第１デバイスに送り、
前記第１デバイスが少なくとも、
ｉ）前記第１デバイスが保存する前記第１デバイスデータと、
ｉｉ）前記第１デバイスが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイスから受け取った前記第２デバイス秘密鍵情報と、を用いて
から前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認することによって、前記第１デバイスが前記第２デバイスを認証する請求項９または１０に記載する通信システム。

【請求項12】

前記プロキシデバイスはプロキシデータおよびプロキシデバイス秘密鍵を保存しており、
前記プロキシデバイスが前記コミットメント段階で前記プロキシデータおよびプロキシデバイス秘密鍵情報を用いてワンタイムプロキシデバイスコミットメント値を発生し、前記プロキシデバイス秘密鍵情報は前記プロキシデバイス秘密鍵と第３ランダムノンスを含むか、または前記プロキシデバイス秘密鍵と前記第３ランダムノンスから導出された請求項９乃至１１のいずれかに記載する通信システム。

【請求項13】

前記第２デバイスは前記プロキシデータを保存し、
前記プロキシデバイスが前記ワンタイムプロキシデバイスコミットメント値を前記第２デバイスに送り、
前記プロキシデバイスが前記プロキシデバイス秘密鍵情報を前記第２デバイスに伝送し、
前記第２デバイスが前記第２デバイス中に保存された前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムプロキシデバイスコミットメント値が真正であることを確認する請求項１２に記載する通信システム。

【請求項14】

前記プロキシデバイスが前記プロキシデータおよび前記プロキシデバイス秘密鍵情報を用いて、さらに前記ワンタイムダイジェスト値を計算し、
前記第２デバイスが前記第１デバイスを認証する時に、前記第２デバイスがさらに前記第２デバイスが保存する前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認する請求項１３に記載する通信システム。

【請求項15】

前記第１デバイスは前記プロキシデータを保存し、
前記プロキシデバイスが前記ワンタイムプロキシデバイスコミットメント値を前記第１デバイスに送り、さらに前記プロキシデバイス秘密鍵情報を前記第１デバイスに伝送し、
前記第１デバイスが前記第１デバイス中に保存された前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムプロキシデバイスコミットメント値が真正であることを確認する請求項１２乃至１４のいずれかに記載する通信システム。

【請求項16】

前記プロキシデバイスがさらに前記プロキシデータおよび前記プロキシデバイス秘密鍵情報を用いて前記ワンタイムダイジェスト値を計算し、
前記第１デバイスが前記第２デバイスを認証する時に、前記第１デバイスが、前記第１デバイスが保存する前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認する請求項１５に記載する通信システム。

【請求項17】

前記第１デバイスデータは、前記第１デバイスを特定する第１デバイス識別データを含み、前記第２デバイスデータは前記第２デバイスを特定する第２デバイス識別データを含む請求項９乃至１６のいずれかに記載する通信システム。

【請求項18】

前記第１デバイス、前記第２デバイスおよび前記プロキシデバイスは無線機を含み、無線で通信する請求項９乃至１７のいずれかに記載する通信システム。

【請求項19】

前記第１デバイス、前記第２デバイスおよび前記プロキシデバイスは一つ以上の有線の中継器を介して通信する請求項９乃至１７のいずれかに記載する通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本願発明はデバイスを認証するための方法およびシステムに関する。

【背景技術】

【0002】

認証のプロセスは、暗号化システム中の中心概念である。認証を行うことにより互いに情報交換したい２つのパーティ同士の信用が確立される。認証を行うことにより、あるパーティがそのパーティが申告する者または物であるかどうかを判定できる。認証は承認とは異なる。承認はあるパーティが行ってよいことを、例えばそのパーティが他のどのパーティと通信してよいかを判定する。

【0003】

従来、認証は公開鍵基盤（以下、「ＰＫＩ」という）を用いて行われていた。ＰＫＩの中では、証明機関（以下、「ＣＡ」という）とも言われる、一か所に集まった複数の信頼できる第三者機関（以下、「ＴＴＰ」という）が、パーティの身元を注意深くチェックし、（一対の非対称鍵のうちの）そのパーティの公開鍵を認証する。

【0004】

第２のパーティがこの証明書を見ると、その第２のパーティは第１のパーティのみが解読できるメッセージを作成する方法がわかるか、またはその第２のパーティは第１のパーティが暗号化技術を用いて署名された書類の真の著者であったことを証明する署名が真正であることを確認することができる。

【発明の概要】

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

【0005】

しかし、ＰＫＩはあらゆる状況に十分に適したものではない。ＰＫＩは中心に配置された所定のクライアント・サーバーモデル用に設計されたものであり、そのようなクライアント・サーバーモデル中では、取引を完了させるために認証をしてもらいたいすべてのパーティが所定の中心に集まったネットワーク、普通は公共インターネットを介して通信しなければならない。このようなパーティはすべてＴＴＰが高価になる場合がある証明書を保持していることをあてにしなければならない。ＰＫＩが複雑なため、ＰＫＩはモノのインターネット（以下、「ＩｏＴ」という）には余り向いていない。ＩｏＴにおいては、数十億のノードを認証することが望ましいが、それらのノードの多くは、携帯電話によるものであり、少なくとも世界全体から見て共通の意味の身元を有しているものではない。これらのノードが意味のある身元（例えば、ノードの所有権または物理的な位置）を有しているとしても、この規模の効果的なＰＫＩを作って、維持することのコストは極めて高い。ＰＫＩが大きくなればなるほど、さらに構造化されればされるほど、より多くのＣＡの層が通常必要になる。このことによって、ＰＫＩによる認証に必要な複雑な数学計算のために、受け入れられないほどのコンピュータの能力および電力を、単純な電池式のセンサーでもよい複数のデバイスに要求することになる。さらに、複雑なＩｏＴシステムの中では、多くのアセットが他の多くのアセットとリアルタイムで、簡単に言えば一度に大量のデータを通信する必要がある

【0006】

ゲートウェイ・レベルでのＰＫＩ認証を用いて、大規模なＩｏＴネットワーク用の認証を行う試みがなされてきた。しかし、ゲートウェイでの認証に依存すると、センサーおよびセンサーのハブが例えば総当たり攻撃、中間者攻撃およびポスト量子暴露のような様々な攻撃に対して脆弱になる。もしもゲートウェイが露出されれば、ゲートウェイに接続、ルーティングおよび機能を依存するすべての部品も露出されることになる。

【0007】

本願発明は、従来の一か所に集めたＰＫＩ認証方法に存在する前述した欠点のいくつかを解決する、代わりとなる認証方法を提供しようとするものである。

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

【0008】

本願発明の第１の要部は、プロキシを用いて第２デバイスに対して第１デバイスが真正であることを証明する方法を提供するものであって、前記方法において、
前記第１デバイスは第１デバイスデータと第１デバイス秘密鍵を保存し、
前記第２デバイスは第２デバイスデータと第２デバイス秘密鍵を保存し、
前記第１デバイスデータはさらに前記第２デバイスおよび前記プロキシによって保存され、
前記第２デバイスデータはさらに前記第１デバイスおよび前記プロキシによって保存され、
前記方法はコミットメント段階では、
前記第１デバイスが前記第１デバイスデータおよび第１デバイス秘密鍵情報を用いて、ワンタイム第１デバイスコミットメント値を発生するステップであって、前記第１デバイス秘密鍵情報は前記第１デバイス秘密鍵および第１ランダムノンスを有するか、または前記第１デバイス秘密鍵および前記第１ランダムノンスから導出されたものであるステップと、
前記第１デバイスは前記ワンタイム第１デバイスコミットメント値を前記プロキシに送るステップと、
前記第２デバイスが前記第２デバイスデータおよび第２デバイス秘密鍵情報を用いて、ワンタイム第２デバイスコミットメント値を発生するステップであって、前記第２デバイス秘密鍵情報は前記第２デバイス秘密鍵および第２ランダムノンスを有するか、または前記第２デバイス秘密鍵および前記第２ランダムノンスから導出されたステップと、
前記第２デバイスが前記ワンタイム第２デバイスコミットメント値を前記プロキシに送るステップと、を含み
前記方法は前記コミットメント段階の後で行われるチェック段階でさらに
前記第１デバイスが前記第１デバイス秘密鍵情報を前記プロキシに伝送するステップと、
前記第２デバイスが前記第２デバイス秘密鍵情報を前記プロキシに伝送するステップと、
前記プロキシが、前記プロキシが保存する前記第１デバイスデータと前記第１デバイスから受け取った前記第１デバイス秘密鍵情報を用いて、前記第１デバイスから受け取った前記ワンタイム第１デバイスコミットメント値が真正であることを確認するステップと、
前記プロキシが、前記プロキシが保存する前記第２デバイスデータと前記第２デバイスから受け取った前記第２デバイス秘密鍵情報を用いて、前記第２デバイスから受け取った前記ワンタイム第２デバイスコミットメント値が真正であることを確認するステップと、を含み、
前記方法は前記チェック段階で前記ワンタイム第１デバイスコミットメント値および前記ワンタイム第２デバイスコミットメント値が真正であることを確認した後に行われるダイジェスト段階でさらに、
前記プロキシが
ｉ）前記プロキシが保存する前記第１デバイスデータと、
ｉｉ）前記プロキシが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイスから受け取った前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイスから受け取った前記第２デバイス秘密鍵情報と、
からワンタイムダイジェスト値を算出するステップと、
前記プロキシが前記ワンタイムダイジェスト値を前記第２デバイスに送るステップと、
前記第２デバイスが少なくとも、
ｉ）前記第２デバイスが保存する前記第１デバイスデータと、
ｉｉ）前記第２デバイスが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイスから受け取った前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイス秘密鍵情報と、を用いて前記プロキシから受け取った前記ワンタイムダイジェスト値が真正であることを確認することによって、前記第２デバイスが前記第１デバイスを認証するステップと、を含む。

【0009】

本願発明の第２の要部は、第１デバイス、第２デバイスおよびプロキシデバイスを有する通信システムを提供するものであって、前記通信システムにおいては、
前記第１デバイスは第１デバイスデータと第１デバイス秘密鍵を保存し、
前記第２デバイスは第２デバイスデータと第２デバイス秘密鍵を保存し、
前記第１デバイスデータはさらに前記第２デバイスおよび前記プロキシデバイスによって保存され、
前記第２デバイスデータはさらに前記第１デバイスおよび前記プロキシデバイスによって保存され、
コミットメント段階では、
前記第１デバイスが前記第１デバイスデータおよび第１デバイス秘密鍵情報を用いて、ワンタイム第１デバイスコミットメント値を発生し、前記第１デバイス秘密鍵情報は前記第１デバイス秘密鍵および第１ランダムノンスを有するか、または前記第１デバイス秘密鍵および前記第１ランダムノンスから導出されたものであり、
前記第１デバイスは前記ワンタイム第１デバイスコミットメント値を前記プロキシデバイスに送り、
前記第２デバイスが前記第２デバイスデータおよび第２デバイス秘密鍵情報を用いて、ワンタイム第２デバイスコミットメント値を発生し、前記第２デバイス秘密鍵情報は前記第２デバイス秘密鍵および第２ランダムノンスを有するか、または前記第２デバイス秘密鍵および前記第２ランダムノンスから導出されたものであり、
前記第２デバイスが前記ワンタイム第２デバイスコミットメント値を前記プロキシデバイスに送り、
前記コミットメント段階の後に行われるチェック段階では、
前記第１デバイスが前記第１デバイス秘密鍵情報を前記プロキシデバイスに伝送し、
前記第２デバイスが前記第２デバイス秘密鍵情報を前記プロキシデバイスに伝送し、
前記プロキシデバイスが、前記プロキシが保存する前記第１デバイスデータと前記第１デバイスから受け取った前記第１デバイス秘密鍵情報を用いて、前記第１デバイスから受け取った前記ワンタイム第１デバイスコミットメント値が真正であることを確認し、
前記プロキシデバイスが、前記プロキシデバイスが保存する前記第２デバイスデータと前記第２デバイスから受け取った前記第２デバイス秘密鍵情報を用いて、前記第２デバイスから受け取った前記ワンタイム第２デバイスコミットメント値が真正であることを確認し、
さらに前記チェック段階で前記ワンタイム第１デバイスコミットメント値および前記ワンタイム第２デバイスコミットメント値が真正であることを確認すると、前記プロキシデバイスはダイジェスト段階に移行し、
前記ダイジェスト段階では、
前記プロキシデバイスが
ｉ）前記プロキシが保存する前記第１デバイスデータと、
ｉｉ）前記プロキシが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイスから受け取った前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイスから受け取った前記第２デバイス秘密鍵情報と、
からワンタイムダイジェスト値を算出し、
前記プロキシデバイスが前記ワンタイムダイジェスト値を前記第２デバイスに送り、
前記第２デバイスが少なくとも、
ｉ）前記第２デバイスが保存する前記第１デバイスデータと、
ｉｉ）前記第２デバイスが保存する前記第２デバイスデータと、
ｉｉｉ）前記第１デバイスから受け取った前記第１デバイス秘密鍵情報と、
ｉｖ）前記第２デバイス秘密鍵情報と、を用いて前記プロキシから受け取った前記ワンタイムダイジェスト値が真正であることを確認することによって、前記第２デバイスが前記第１デバイスを認証する。

【0010】

本願発明の別の要部は、本明細書で開示され前記第１デバイスによって実行される複数のステップを有する方法を実行するデバイスである。本願発明の別の要部は、本明細書で開示され前記第２デバイスによって実行される複数のステップを有する方法を実行するデバイスである。さらに本願発明の別の要部は、本明細書で開示され前記プロキシデバイスによって実行される複数のステップを有する方法を実行するプロキシデバイスを提供する。

【0011】

したがって、本願発明によれば、前記プロキシを用いて前記第２デバイスへ仲介し、前記第２デバイスに対してデータが真正であることを独立して立証し、さらに前記第１デバイスが、同デバイスが申告する者またはものである、すなわち前記第１デバイスは事実前記第１デバイスデータによって特定されるデバイスであるという信頼を前記第２デバイスに与える。コミットメント段階では、前記第１デバイスおよび前記第２デバイスはそれぞれワンタイムコミットメント値を前記プロキシに送信する。このワンタイムコミットメント値は好ましくはそれぞれのデバイスに固有のデバイスデータから導出されたものである。そして、両方のデバイスがそれらのコミットメント値を送信した後、さらに、オプションになるが前記プロキシがそのコミットメント値を送信した後になって始めて、前記第１デバイスおよび前記第２デバイス、さらにオプションになるが前記プロキシはそれぞれの秘密鍵情報を明らかにする。これらの秘密鍵情報によって、前記プロキシは送信されたたコミットメント値が真正であることを確認することができる。さらにオプションになるが、この秘密鍵情報によって、前記第１デバイスおよび／または前記第２デバイスも送信したコミットメント値が真正であることを確認することができる。前記プロキシは自身が保存する前記第１デバイスデータおよび前記第２デバイスデータを用いて、自身に対して前記第１デバイスおよび前記第２デバイスが真正であることを証明する。この認証がうまくいった場合、前記プロキシはダイジェスト値を計算して、前記第２デバイスに送信する。このダイジェスト値によって、前記第２デバイスに対する前記第１デバイスが真正であることの証明が正しいことがわかる。前記第１デバイスが真正であることの証明を前記プロキシがこのように裏付けることによって前記第２デバイスが前記第１デバイスを認証することにより、前記プロキシの関与なしで前記第１デバイスを直接認証しようとする場合に比べて、認証の信頼性を高めることができる。前記したデバイスは、いずれもＩｏＴのセンサーもしくはセンサーハブのような単純なデバイス、または例えばルーターのようなもっと複雑なデバイスでもよい。

【0012】

前記したデバイスデータ（第１デバイスデータ、第２デバイスデータおよび任意のプロキシデバイスデータ）は好ましくはデバイス固有のデータである。前記したデバイスデータはプロビジョニングデータを含むものでよい。前記したデバイスデータはデバイス識別データを含むものでよい。

【0013】

前記プロキシは信頼できるデバイスでよい。特に、前記第２デバイス（およびオプションになるが前記第１デバイス）は、例えば前記方法を実行する前に行われるデータ交換の結果として、前記プロキシを信頼するものでもよい。所定の実施形態では、前記第２デバイス（およびオプションになるが前記第１デバイス）は、本明細書で開示する複数のステップのうちの少なくともいくつかを行うことによって、前記プロキシについての信頼を確立するものでよい。

【0014】

前記プロキシはプロキシデータおよびプロキシデバイス秘密鍵を保存する。オプションになるが、このプロキシデータはさらに前記第２デバイスにより保存され、さらにオプションになるが前記第１デバイスによっても保存される。

【0015】

所定の実施形態では、前記プロキシが前記プロキシデータおよびプロキシデバイス秘密鍵情報を用いてワンタイムプロキシデバイスコミットメント値を発生するものでよい。ここで、前記プロキシデバイス秘密鍵情報は前記プロキシデバイス秘密鍵と第３ランダムノンスを含むか、または前記プロキシデバイス秘密鍵と前記第３ランダムノンスから導出されたものである。好ましい実施形態では、前記プロキシが前記ワンタイムプロキシデバイスコミットメント値を前記第２デバイスに送るものでよい。前記プロキシは前記ワンタイムプロキシデバイスコミットメント値を前記第１デバイスにも送るものでよい。

【0016】

前記第１ランダムノンスは前記第１デバイスが発生するものでよい。前記第２ランダムノンスは前記第２デバイスが発生するものでよい。前記第３ランダムノンスは前記プロキシデバイスが発生するものでよい。各ランダムノンスは真の乱数の発生源から発生する、または疑似乱数発生機が発生するものでよい。

【0017】

所定の実施形態では、前記チェック段階の間に前記プロキシが前記プロキシデバイス秘密鍵情報を前記第２デバイスに伝送する。前記プロキシは前記プロキシデバイス秘密鍵情報を前記第１デバイスにも伝送してもよい。

【0018】

所定の実施形態では、前記第２デバイスが、前記第２デバイスが保存する前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムプロキシデバイスコミットメント値が真正であることを確認する。所定の実施形態では、前記第１デバイスが、前記第１デバイスが保存する前記プロキシデータおよび前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムプロキシデバイスコミットメント値が真正であることを確認する。

【0019】

所定の実施形態では、前記チェック段階で前記ワンタイム第１デバイスコミットメント値および前記ワンタイムプロキシデバイスコミットメント値が真正であることを前記第２デバイスが確認して初めて、前記プロキシデバイスはダイジェスト段階に移行する。所定の実施形態では、前記チェック段階で前記ワンタイム第１デバイスコミットメント値および前記ワンタイムプロキシデバイスコミットメント値が真正であることを前記第２デバイスが確認して始めて、前記プロキシデバイスはダイジェスト段階に移行する。前記第１デバイスおよび／または前記第２デバイスはこれらのコミットメント値が真正であることが確認できたことを前記プロキシデバイスに伝えることができる。前記第１デバイスおよび／または前記第２デバイスは、前記第１デバイスおよび／または前記第２デバイスが再計算した一つ以上のコミットメント値、それぞれ前記プロキシデバイスに送ることができる。前記プロキシデバイスの前記ダイジェスト段階への移行は、前記第１デバイスおよび前記第２デバイスの一方または両方によって、ワンタイム第１デバイスコミットメント値およびワンタイム第２デバイスコミットメント値が真正であることを確認できただけでなく、ワンタイムプロキシデバイスコミットメント値が真正であることを確認できた後になって始めてできる。

【0020】

所定の実施形態では、前記プロキシはさらにプロキシデータおよびプロキシデバイス秘密鍵情報を用いてワンタイムダイジェスト値を算出する。

【0021】

前記第２デバイス（オプションになるが、および前記第１デバイス）は、さらに前記プロキシデータおよび前記プロキシデバイス秘密鍵情報を用いて、前記プロキシデバイスから受け取った前記ワンタイムダイジェスト値が真正であることを確認することによって、前記第１デバイスを認証することができる。

【0022】

前記第１デバイスおよび／または前記第２デバイスは任意の電子デバイスでよい。これらデバイスは無線デバイスでもよい。これらのデバイスはルーターおよび／またはサーバーでもよい。これらのデバイスは携帯型デバイスでもよい。これらのデバイスは電池駆動されるものでもよい。好ましい実施形態の組では、これらのデバイスは無線センサーデバイスである。これらのデバイスはＩＥＥＥ８０２．１Ｘプロトコル、例えば８０２．１１（Ｗｉｆｉ（登録商標））を用いて、互いに通信する、および／または前記プロキシデバイス通信する、ものでよい。これらのデバイスは、例えばＺｉｇＢｅｅ（登録商標）のようなＩＥＥＥ８０２．１５プロトコルを用いて、および／またはＷｉｆｉもしくはブルートゥース（登録商標）あるいは他の短距離範囲、中距離範囲、もしくは長距離範囲無線プロトコルを用いて、互いに通信する、および／または前記プロキシデバイスと通信する、ことができる。しかしながら、このことは重要ではなく、これらのデバイスは、一つ以上の無線光学チャンネル、マイクロ波中継器。８０２．３Ｘ（イーサネット（登録商標））のような有線中継器、電線、光ファイバ等を用いて通信してもよい。前記第１デバイスおよび／または前記第２デバイスはインターネットのインタフェースを有してもよい。これらのデバイスはそれぞれＩＰアドレスを有してもよく、またＩＰアドレスを有してなくてもよい。これらのデバイスはＩｏＴデバイスでもよい。

【0023】

前記プロキシは任意のデバイスでよい。前記プロキシは前記第１デバイスおよび／または前記第２デバイスの有する特徴のうちどれかを有するものでもよい。特に、前記プロキシは別のセンサーデバイスでもよい。所定の実施形態では、前記プロキシはセンサーハブまたはゲートウェイである。

【0024】

前記第１デバイス、前記第２デバイスおよび前記プロキシは、すべてそれぞれの近傍にあるものでよい。例えば、これらのデバイスは、１ｋｍ以内、１００ｍ以内または１０ｍ以内にあるものでよい。または、これらのデバイスは長距離の範囲にわたって分散しているものでよく、地球上に分散しているものでもよい。

【0025】

所定の実施形態では、前記第１デバイスまたは前記第２デバイスがさらに前記プロキシとしても働くものでもよい。すなわち、一つの物理的なデバイスが、前記第１デバイスおよび前記プロキシの両方に、または前記第２デバイスおよび前記プロキシの両方になるものでもよい。しかし、他の実施形態では、前記プロキシは前記第１デバイスとも前記第２デバイスとも別体でよい。

【0026】

所定の実施形態では、前記方法を用いて第２の複数のデバイスまたは複数のデバイスからなる第２の組に対して、第１の複数のデバイスまたは複数のデバイスからなる第１の組が真正であることを証明することができる。

【0027】

所定の実施形態では、前記方法を用いて第１の複数のデバイスまたは複数のデバイスからなる第１の組と第２の複数のデバイスまたは複数のデバイスからなる第２の組の一方に対して、他方が真正であることを証明することができる。

【0028】

前記方法は、前記ダイジェスト段階で前記プロキシがワンタイムダイジェスト値を前記第１デバイスに送るステップをさらに含むものでよい。前記第１デバイスは、ｉ）前記第１デバイスが保存する前記第１デバイスデータと、ｉｉ）前記第１デバイスが保存する前記第２デバイスデータと、ｉｉｉ）前記第１デバイス秘密鍵情報と、ｉｖ）前記第２デバイスから受け取った前記第２デバイス秘密鍵情報と、を用いて前記プロキシから受け取った前記ワンタイムダイジェスト値が真正であることを確認することによって、前記第２デバイスを認証することができる。このようにして、前記方法は第１デバイスと第２デバイスが相互に認証することを可能にするものでよい。

【0029】

前記第２デバイスは、前記第１デバイスを認証する時に、さらに前記第２デバイスが保存する前記プロキシデバイスデータと前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて前記プロキシデバイスから受け取ったワンタイムダイジェスト値が真正であること確認することができる。前記第１デバイスは、前記第２デバイスを認証する時に、さらに前記第１デバイスが保存する前記プロキシデバイスデータと前記プロキシデバイスから受け取った前記プロキシデバイス秘密鍵情報を用いて前記プロキシデバイスから受け取ったワンタイムダイジェスト値が真正であることを確認することができる。

【0030】

所定の実施形態では、前記プロキシが前記ワンタイム第１デバイスコミットメント値および前記ワンタイム第２デバイスコミットメント値が真正であることを確認し、さらに前記第１デバイスおよび／または前記第２デバイスが一つ以上のワンタイムコミットメント値が真正であることを確認するものでよい。このステップにより、攻撃に対する認証プロトコルの堅牢性を高める。特に、所定の実施形態は、前記コミットメント段階で前記第１デバイスがさらに前記ワンタイム第１デバイスコミットメント値を前記第２デバイスに送るステップを有するものでよい。所定の実施形態は、前記第２デバイスがさらに前記ワンタイム第２デバイスコミットメント値を前記第１デバイスに送るステップを有するものでよい。所定の実施形態は、チェック段階で前記第１デバイスがさらに前記第１デバイス秘密鍵情報を前記第２デバイスに伝送するステップを含むものでよい。前記第２デバイスはその後前記第２デバイスが保存する前記第１デバイスデータと受け取った前記第１デバイス秘密鍵情報を用いて、前記第１デバイスから受け取った前記ワンタイム第１デバイスコミットメント値が真正であることを確認できる。所定の実施形態は、前記第２デバイスが前記第２デバイス秘密鍵情報を前記第１デバイスに送るステップを含むものでよい。前記第１デバイスはその後前記第１デバイスが保存する前記第２デバイスデータと受け取った前記第２デバイス秘密鍵情報を用いて、前記第２デバイスから受け取った前記ワンタイム第２デバイスコミットメント値が真正であることを確認できる。

【0031】

前記第１デバイスおよび／または前記第２デバイスが一か所に集まった証明機関と通信しないことが好ましい。これらのデバイスは公開鍵の暗号化するためのメカニズムを有する必要はない。このことにより、ＰＫＩ認証プロトコルを使用するのに比べて、これらのデバイスの構成を単純にして、プロセスの必要な要件および使用電力を減らすことができる。

【0032】

所定の実施形態は、ＳＨＡ関数のようなハッシュ演算を用いて、デバイスごとにコミットメント値を発生するものでよい。このようにすれば、非対称キー演算を行う場合よりも、これらのデバイスにかかる計算負荷は小さくなる。

【0033】

前記方法は、前記第１デバイス、前記第２デバイスおよび前記プロキシデバイスのうちの一つ以上のデバイスが前記第１デバイス、前記第２デバイスおよび前記プロキシデバイスのうちの一つ以上のデバイスによって識別されるハンドシェイク段階を有するものでよい。このデバイスの識別は厳しい認証なしで行われる。このデバイスの識別は一つ以上の比較的短いハッシュ値、を交換するものでよい。このハッシュ値は、これらのデバイスのうちの一つ以上のデバイスのデバイスデータから導出されたものであり、例えば、２０ビットのハッシュ値である。すべてのハッシュ値がワンタイム値となるように、各ハッシュ値はそのハッシュ値へ入力されたランダムノンスを含むものでよい。各ハッシュ値はそのハッシュ値に入力されたタイムスタンプを含むものでよい。各ランダムノンスは対応するデバイスによって他のデバイスのうちの少なくとも一つに伝送される。ハンドシェイクは、前記第１デバイスが、前記第１デバイスが保存する前記第２デバイスデータと前記第２デバイスから受け取ったランダムノンスに基づいてハッシュ値を再計算することにより、前記第１デバイスが前記第２デバイスの身元を判定するステップを含むものでよい。前記第１デバイスは再計算したハッシュ値を前記第２デバイスから受け取ったハッシュ値と比較し、これらのハッシュ値が一致するとき前記第１デバイスは前記第２デバイスが本物であることを確認できる。同様に、ハンドシェイクは、前記第２デバイスが、前記第２デバイスが保存する前記第１デバイスデータと前記第１デバイスから受け取ったランダムノンスに基づいてハッシュ値を再計算することにより、前記第２デバイスが前記第１デバイスの身元を判定するステップを含むものでよい。前記第２デバイスは再計算したハッシュ値を前記第１デバイスから受け取ったハッシュ値と比較し、これらのハッシュ値が一致するとき前記第２デバイスは前記第１デバイスが本物であることを確認する。

【0034】

前記方法はさらに、前記第２デバイスおよび前記プロキシデバイスに前記第１デバイスデータを与え、前記第１デバイスおよび前記プロキシデバイスに前記第２デバイスデータを与えるデプロイメント前ハンドシェイク段階を含むものでよい。

【0035】

前記プロキシデバイスが算出するワンタイムダイジェスト値は、前記複数のデバイスのうちの一つ以上からのタイムスタンプ情報にさらに依存するものでよい。前記第２デバイスおよび／または前記第１デバイスはこのタイムスタンプ情報を用いて前記ワンタイムダイジェスト値が新しいものであることに相違ないことを確認することができる。この確認は、リプレー攻撃を防ぐのに役立つ。

【0036】

前記第１デバイスが発生する前記第１デバイスコミットメント値または前記第２デバイスが発生する前記第２デバイスコミットメント値はそれぞれのデバイスの内部クロックからのタイムスタンプ情報にも依存するものでよい。コミットメント値を受け取るデバイス（例えば、プロキシ）は、コミットメント値が真正であることを確認することの一部として、受け取ったコミットメント値が新しさの条件（例えば、新しさを確認するプロキシのクロックの現在時間よりも０．１秒よりも前ではない）を満たしていることをチェックするものでよい。

【0037】

前記第１デバイスは一つの組を構成する認証プロトコルの複数の段階を実行したことをチェックするマイルストーンチェックを行うものでよい。この一つの組を構成する複数の段階には、前記コミットメント段階および／または前記チェック段階および／または前記ダイジェスト段階が含まれるものでよい。この一つの組を構成する複数の段階にはさらに、ハンドシェイク段階が含まれてもよい。前記チェック段階は鍵交換マイルストーンと別個のチェックマイルストーンを与えるものでよい。もしもこのマイルストーンチェックがうまくいかないと、前記第１デバイスはこの認証方法から撤退できる。前記第１デバイスは、マイルストーンの組を構成する複数の段階をすべて実行したことを前記プロキシデバイスに対して証明することができる。前記第２デバイスは同様にこれらのマイルストーン作業の一部またはすべてを行うことができる。

【0038】

前記複数のデバイス同士の通信は、２つ異なる無線プロトコルのような２つ以上のチャンネルに、または有線のチャンネルと無線のチャンネルに分けることができる。 このことにより安全性が向上する。

【0039】

前記複数のデバイスは暗号化鍵、例えばＡＥＳ鍵を共有し、この暗号化鍵を用いて前記複数のデバイス間でやりとりするデータ情報のすべて、または一部を暗号化できる。しかし、認証の完全性はＡＥＳ鍵の安全性に依存しないことが好ましい。

【0040】

前記プロキシデバイスおよび／または第１デバイスあるいは第２デバイスは成功した認証を、例えばブロックチェーン中に記録することができる。

【0041】

好ましくは、前記システムは、認証プロトコルを実行するたびに異なるデータが前記複数のデバイス間でやり取りされるような構成を有する。このような構成は、本明細書で説明するようにノンスを用いることにより実現される。このようにすれば、データのやり取りをするたびに認証が行われ、これにより攻撃者が鍵または証明書を解読するのを防ぐことができる。実施形態は耐量子攻撃性を高めることができる。

【0042】

前記複数のデバイス同士の認証が永久でないことが好ましい。認証は必要な時のみ行われる。所定の場合では、認証された状態が続くのは、数秒またはそれより短い間しか続かない一つの通信セッションの間だけである。このことが特にあてはまるのは、前記複数のデバイスが携帯型デバイスであり、数秒間だけ互いに近くにある場合（例えば、近距離無線範囲内にある場合）である。

【0043】

前記コミットメント段階、前記チェック段階および前記ダイジェスト段階は、好ましくは複数の異なるノンスを用いて同じ第１および第２デバイスによって複数回行うことができる。これらの第１および第２デバイスは、条件が合致したら必ずこれらの段階を実行できる（すなわち再認証できる）。例えばこれらのデバイス間の無線チャンネルが（再）確立したら必ず、これらの段階を実行できる。

【0044】

一つの組を構成する複数の実施形態では、前記第１デバイスは第１ゲートウェイ（例えば、ルーターまたは前記第１デバイスと前記第２デバイスを接続するローカルネットワークにデータが入ってくること、および同ローカルネットワークからデータが出ていくことを可能にする他のデバイス）である。所定のそのような実施形態では、前記第２ゲートウェイは第２ゲートウェイとなり、この第２ゲートウェイは前記第１ゲートウェイがインタフェースとなって接続するのと同じ外部ネットワークをインタフェース接続するものでもよいし、他の外部ネットワークをインタフェース接続するものでもよい。

【0045】

前記第１および第２ゲートウェイは、静止したデバイス（すなわち、携帯型デバイスではない）でよい。これらゲートウェイの間には有線中継器のような永続的な通信チャンネルがあってもよい。しかし、前記通信チャンネルが永続的なものであっても、コミットメント段階、チェック段階およびダイジェスト段階を周期的に行うことがやはり望ましい。これらの複数のデバイスは１秒間に１回、またはもっと頻繁に、例えば１秒間に５０回以上、再認証してもらうことができる。このようにすれば、いかなる認証セッションの継続時間よりも総当たり攻撃でセキュリティを破るのにかかる時間の方がはるかに長くすることを確実にできるので潜在的な攻撃者に対する抵抗力を高めることができる。これにより、量子計算に基づく攻撃に対しても耐える可能性がある。

【0046】

所定の実施形態では、前記システムは前記第１および第２デバイスの間に２つの通信チャンネルを設けてもよい。これらの２つ通信チャンネルは単一のイーサネットケーブルのような一つの普通の媒体で繋がった２つの多重化チャンネルでもよいし、一対のイーサネットケーブルのような２つの異なる媒体を用いる２つの多重化チャンネルでもよい。前記システムの構成は、いずれの時点においても、これら２つのチャンネルのうちの一つのみが認証されたチャンネルとなり、そのチャンネルを用いて本明細書で記載するコミットメント段階、チェック段階およびダイジェスト段階を行い、一方、もう一つのチャンネルは非接続（すなわち、データ通信には用いられない）とするか、または応答が必要でない通信のみに用いられる。 認証されたチャンネルを用いて応答をする通信をすることもできる。前記複数のデバイスは、これらの２つのチャンネルのうちのどれを認証されたチャンネルとするかを一定の周期で交代させてもよい。認証されるチャンネルの身元が変わるたびに、再認証を行えばよい。この認証チャンネルの交代は１秒間に１回、またはもっと頻繁に、例えば１秒間に５０回以上行うことができる。このようにすることにより、どの認証されたチャンネルの継続時間よりも総当たり攻撃でセキュリティを壊すにかかる時間の方がはるかに長くすることが確実になるので、可能性のある攻撃者に対する安全性を高めることができ、量子計算に基づく攻撃に対しても耐えられる可能性がある。もちろん、３つまたは４つのチャンネルがあってもよく、これらのうちの一部は任意の時間に認証される。

【0047】

前記デバイスデータは、モデル番号、固有のＩＤ、クラス、所有者等のような一つ以上の属性を含むものでよい。これらの属性は、特定のデバイスまたは複数のデバイスからなる特定のクラスに固有なものである。適切な属性を選択する、さらに／または組み合わせることによって、ネットワーク内の各デバイスに固有なデバイスデータが定まる。前記秘密鍵はデバイス属性を用いて発行される。前記秘密鍵は各デバイスが起動される間に発行される。

【0048】

前記複数のデバイスは互いに通信するように設定されている。この設定（プロビジョニング）は認証とは通常異なるものである。前記複数のデバイスが認証プロトコルを開始する前に、前記複数のデバイスが互いに通信できるように設定されることは必要なことである。

【0049】

各デバイスは、本明細書で開示する一つ以上のステップを実行するため、プロセッサによって実行されるソフトウェア命令を有する。このソフトウェアは前記デバイスのメモリに保存される。各デバイスは、ＣＰＵ、ＤＳＰ、ＧＰＵ、ＦＰＧＡ、ＡＳＩＣ、揮発性メモリ、不揮発性メモリ、入力装置、出力装置、ディスプレー、ネットワーク接続、電源、無線機、クロック、および他の適切な部品を有するものでよい。各デバイスは認証の結果を保存、表示または出力する。

【0050】

本明細書中で説明する本願発明のどの実施形態またはどの要部の特徴も、適宜本明細書中で説明する本願発明の他の実施形態または他の要部のいずれにも適用できる。複数の異なる実施形態または複数の実施形態からなる組に言及するときは、これらは必ずしも全く異なるものではなく、一部重複するものでもよい。

【図面の簡単な説明】

【0051】

本願発明の所定の好ましい実施形態は、以下、実施例により次の図面を参照して説明される。

【図1】図１は本願発明の実施形態を構成する認証プロトコルに参加する２個のアセットとプロキシを示す概略図である。

【図2】図２は本願発明の実施形態を構成する認証プロトコルの主要な段階を示すフローチャートである。

【図3】図３は前記２個のアセットの初期デプロイメントの間に実行される認証プロトコルの「ハンドシェイク」段階が実行されるときの、認証プロトコルの「ハンドシェイク」段階の詳細を示すフローチャートである。

【図4a】図４ａは前記２個のアセットが初期デプロイメントの後に、前記２個のアセットの認証を行うときに実行される前記認証プロトコルの「ハンドシェイク」段階の第１部の詳細を示すフローチャートである。

【図4b】図４ｂは前記認証プロトコルのデプロイメント後「ハンドシェイク」段階の第２部の詳細を示すフローチャートである。

【図5A】図５Ａは前記認証プロトコルの「コミットメント」段階の詳細を示すフローチャートである。

【図5B】図５Ｂは前記認証プロトコルの「コミットメント」段階の詳細を示すフローチャートである。

【図6】図６は、複数のコミットメント値のチェックが行われる、前記認証プロトコルの「チェック」段階の詳細を示すフローチャートである。

【図7】図７は、最終ダイジェスト値が発生され、共有される、前記認証プロトコルの「最終ダイジェスト」段階の詳細を示すフローチャートである。

【図8】図８は、各アセットが要求されるマイルストーンの各々を経たことをチェックする、前記認証プロトコルの最終「マイルストーン」段階の詳細を示すフローチャートである。

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

【0052】

図１は、本願発明の実施形態を構成する認証プロトコルに参加する、アセットＡ１００とアセットＢ１０１とプロキシ１０２またはアセットＰと呼ぶ第３アセットと、を有する無線センサーネットワークの複数の部品を示す。このネットワークはこの図よりももっと多くのアセットを有するものでもよい。これらのアセットの各々は個別のメモリ１０３、クロック１０４、無線機１０５およびプロセッサ１０６を有する。これらのメモリ１０３は本明細書で説明されるステップのいくつか、またはすべてを実行するために、それぞれのプロセッサで実行される命令を有するソフトウェアを保存するものでよい。代わりの例では、複数のアセット１００、１０１、１０２は前記ステップの少なくとも一部を実行するためのクリプト・アクセラレーター（図示されていない）のような専用ハードウェアを有するものでよい。複数のアセット１００、１０１、１０２は電池、ユーザーインタフェース、センサー等を含むものでよい。 これらのアセットは無線機により互いに通信する。

【0053】

これらのアセットは、例えば、ＩｏＴセンサーまたはＩｏＴセンサーのハブでもよい。例えば、アセットＡ１００は街灯柱の中に配置されたセンサーで、アセットＢ１０１が車両内に配置されたセンサーで、プロキシ１０２が前記街灯柱の近くの道路の中に埋め込まれたセンサーとなることもある。前記車両が前記街灯柱と前記道路センサーに電波近接した場所を通過する短い時間窓の間に、車両センサーＢは、街灯柱センサーＡとセンサーデータをやりとりする前に街灯柱センサーＡにより認証されることを望む。以下でさらに詳細に説明するように、道路センサー１０２とも通信することにより、この認証が確実に行われる。所定の実施形態では、複数のアセットＡ１００，Ｂ１０１の一つまたは両方が、ローカルエリアネットワークとインターネットのような２つの異なるネットワークの間のインタフェースとなるゲートウェイデバイスになりうる。

【0054】

図２は本願発明の一実施形態である認証プロトコルの概略を示す。この認証プロトコルは図１のセンサーネットワーク内または別のネットワーク内で実行されるものでよい。

【0055】

このプロトコルは、アセットＡと呼ぶ、アセット（例えば、アセットＡ１００）または複数のアセットからなる組が、認証信号を発行して、アセットＢと呼ぶ、別のアセット（例えば、アセットＢ１０１）または複数のアセットからなる別の組に対して送信することから始まる。この認証信号を受信すると、アセットＢは認証要求を発行して、「プロキシ」またはアセットＰと呼ぶ第３のアセット（例えば、プロキシ１０２）に送る。それから、このプロキシは追加の要求を発行してアセットＡとアセットＢの両方に送り、各アセットがこの追加の要求をプロキシから受け取ると認証プロセスが進行する。このプロセスはすべて、図２のフローチャートの「要求」ステップ２で行われる。このステップは図３および図４中に詳細に示されている。

【0056】

認証が必要なときは必ず要求がなされ、アセットの認証は、認証を必要とする所定の通信が終了するとすぐに終了する。その結果、アセットの認証は、その認証が意図的に使用されている時以外は「常にオフ」になっていて、そうすることで、いかなるアセットに対する認証も永続的にならないように、言い換えれば、認証は必要にのみ基づいて発生するようしているので、認証プロトコルの安全性が高められている。

【0057】

これらの要求はすべて、バンド１と呼ばれる第１通信バンドを用いて発行される。第１通信バンドは８０２．１５．ｘチャンネルになることがある。

【0058】

もっと一般的に言えば、プロトコルはすべての通信が単一の通信バンドである、バンド１上を用いて伝送されることにより実行できる。 しかし、好ましい実施形態では、プロトコル実行中の複数の異なる時点で２つの異なる通信バンドを用いてデータを伝送する。これらの通信バンドは、例えばＷｉｆｉ接続、ブルート_ウ―ス、または有線接続のうちのいずれでもよく、例えば、バンド１は８０２．１１．ｘ無線チャンネルにして、バンド２を８０２．１５．ｘ無線チャンネルにすることも可能である。

【0059】

アセットＡがアセットＢおよびプロキシによって認証されるためには、この特別な例の実施形態ではこれらのすべてのアセットの設定（プロビジョニング）の特徴が同一であることが必要であり、これはこれらのアセットが通信することが許されるのは同じアセットだけであることを意味する。これらのアセットは同一の固有の属性（ＮＰ）を有していなければならず、ここで固有の属性に含まれるのは、英数字、実数、年月日、時間または組の身元の任意の組み合わせでよい。他の実施形態ではこの要件がなくてもよい。

【0060】

認証プロトコルにおける次の段階は、図２のステップ４に示される「ハンドシェイク」と呼ばれるものである。二者択一となる２つの「ハンドシェイク」の段階がある。図３に詳細が示される第１「ハンドシェイク」段階４ａは複数のアセットの組が始めのデプロイメントの間のみ、例えばすべてのアセットが工場で設定されるときにのみ起きる。第２の代わりとなる「ハンドシェイク」段階４ｂがおきるのは、「デプロイメント後」（例えば、工場からの初期デプロイメントの後）におきる、例えば複数のセンサーが他のデバイス中に設置されたときにおきる任意の認証の間である。段階４ｂはその詳細が図４ａおよび４ｂ中に示される。図３の段階４ａで詳細に説明されているように、複数のアセットが初期デプロイメントの間にハンドシェイクがおきるときは、各アセットまたは各複数のアセットからなる組が所定の属性を圧縮し、圧縮した属性を暗号化し、さらに暗号化した属性を他のアセットと共有する。このような属性には、アセットのハードウェアＩＤ（ＨＩＤ）、仮想ＩＤ（ＶＩＤ）および顧客ＩＤ（ＣＩＤ）を連結した固有のＩＤである「ＵＩＤ」だけでなく、アセットｘの固有の属性に加えて所定のアセットの内部クロックに基づくタイムスタンプ値を表すデータの組である「ＩＮＦＯｘ」およびアセットが有する設定の仕様または許可である「ＰＳｘ」（例えば、オン時間／オフ時間、一回の仕事の継続時間、仕事の間隔、条件つきの、例外、暗示された、である／でない、もっと多い／もっと少ない、少なくとも等の許可）を含むものでよい。複数のセンサーの内部クロックは、既知の同期方法を用いて、最初のセットアップの段階の間、および／またはその後周期的に同期化されるものでよい。ハードウェアＩＤはアセットが製造されている時に焼き付けられた固有のＩＤである。仮想ＩＤは、アセットの第１スタートの間に作られたアセットの名前空間の複数の値の中から無作為に選ばれた一つのＳＨＡ－３ハッシュ値である。顧客ＩＤはアセットが属する顧客の固有の顧客ＩＤであり、初期プロトコル・デプロイメントの間に作られる。各アセットはさらに顧客または製造者によってすべてのアセットに予め設けられた鍵であるＡＥＳ鍵を用いて前記した属性を暗号化する。これらの圧縮されてさらに暗号化された属性は認証プロセスに参加しているすべてのアセットの間で通信バンド１を介して共有される。各アセットはその後他のすべてのアセットからこれらの属性の受領の確認連絡を待ち、この確認連絡を受け取るか、またはタイムアウトになるまでは、これらの属性を再び送る。これらの共有される属性はすべて、各アセットがそのメモリ１０３中に永久に保存する。

【0061】

各アセットは、ハードウェアＩＤ。モデル名、モデルＩＤ、シリアル番号等を含む予め設定された値を有する。各アセットは起動されると、その固有ＩＤ＝ハードウェア＿ＩＤ、仮想＿ＩＤ、顧客＿ＩＤを発行する。

【0062】

信用されたプロキシを含め、各アセットは認証を始める前に次の値を定めてもらう必要がある。
― 認証に参加するためのＩＮＦＯデータ（認証プロセス中に加えられるタイムスタンプは除く）
― 認証に参加するための暫定仕様データ
― 複数のアセットの間で暗号化されたデータの共有を始めるための共通のＡＥＳ－１２８暗号鍵
― ハンドシェイク タイムアウト
― コミットメント交換タイムアウト
― 秘密鍵交換タイムアウト

【0063】

図４ａおよび４ｂの段階４ｂで示される、複数のアセットの初期デプロイメントの後にハンドシェイクがおきるときは、プロトコルの安全性を高めるようにアセットの属性はいずれも直接は共有されていない。
もっと正確に言えば、（プロキシを含む）各アセットは段階３０において、２０ビットの使い捨て乱数データ（以下、「ノンス」という）、すなわち一度のみ用いられる乱数を発生する。各アセットは、その後段階３１において、タイムスタンプを発行し、このタイムスタンプをそのアセットのＩＮＦＯアレーに書き込む。各アセットはその後段階３２において、自身の属性、すなわちＵＩＤ、ＩＮＦＯ、ＰＳ、の連結から２０ビットのＳＨＡ－３ハッシュ値、すなわちＰＨ（属性ハッシュ）を計算する。各アセットは、その後段階３４において、段階３０からのノンスと段階３２からの属性ハッシュ値の連結から、別のＳＨＡ－３ハッシュ値、すなわちＮＰＨ（使い捨て乱数データが付いた属性ハッシュ）を計算する。各アセットはその後、そのＮＰＨハッシュ値およびそのノンスの両方を他のすべてのアセットにバンド１を介して送り、図４ｂ中の段階３６に示すように受領確認連絡を受け取るまで、またはタイムアウトまで、これらの値をずっと共有する。いずれの段階においても、アセットが認証に参加している他のすべてのアセットに伝送される詳細の受領の確認を受け取ることなく、タイムアウトになった場合、図４ｂのフローチャートの黒丸で示されるように、そのアセットは認証のセッションに参加するのを取り止める。もしもそのような状態になったのがプロキシであった場合、そのプロキシは（そのプロキシの参加だけでなく）認証のセッションすべてを停止させる。

【0064】

ステップ３８において示されているように、各アセットは、他のアセットからＮＰＨとノンスの値を受け取ると、デプロイメント段階４ａの間にそのアセットが取得した保存されたレコードを用いて、受け取ったＮＰＨ値を再計算して参加しているアセットの属性を特定する。

【0065】

二者択一の「ハンドシェイク」ステップ４ａ、４ｂのいずれかが完了したことが、第１の「マイルストーン」として、参加しているアセットの各々によって記録される。図２に示すように、各アセットは、そのアセットが認証された地位を認められる前には、認証プロトコルの最終段階だけでなく、認証プロトコル中の５個のマイルストーンのステップを経なければならない。したがって、認証プロセスに参加しているアセットは、必要とされる５個のマイルストーンのそれぞれを経たことを記録する（例えば、メモリ中にフラグを保存する）必要がある。マイルストーンをチェックするやり方については、図８を参照して後で説明する。

【0066】

「ハンドシェイク」の後、図２に簡単に示すようにアセットはすべて「コミットメント」段階６に進む。詳細は図５Ａおよび図５Ｂに示す。この段階６においては、参加している各アセットはまずステップ４０で２０４ビットのノンスを発生する。その後各アセットは、ステップ４２で、そのアセットのオペレーティング・システムを起動する間にそのアセットのＵＩＤに基づいて作られ、けっして共有されることのないそのアセット固有の２０ビットの鍵である、そのアセットが有する秘密鍵を読み出し、この秘密鍵をステップ４０で発生したノンスと連結させて、ワンタイム２２４ビット秘密鍵を作る。この秘密鍵はノンスを含んでいるので、各認証セッションで異なるものであり、各セッションに固有のものである。

【0067】

ステップ４４で、各アセットはそのコミットメント値Ｃｘを計算する。コミットメント値はＳＨＡ－３ハッシュ関数として計算される。

Ｃｘ＝ハッシュ_Ｓｘ（ＵＩＤｘ、ＩＮＦＯｘ、ＰＳｘ）

ここで、Ｓｘはステップ４２で作られたアセットｘの第２鍵であり、ＵＩＤｘはアセットｘのハードウェアＩＤ、仮想ＩＤおよび顧客ＩＤの連結したものであり、ＩＮＦＯｘはアセットｘを表すデータ（すなわち、アセットｘの固有の属性）の組である。このＩＮＦＯｘはタイム－ピリオド・スタンプを含むので、このＩＮＦＯ値は特定の認証セッションに特有なものになり、時間と結びついたものである。このタイムスタンプは各アセットの内部クロックに基づくものであり、すべてのアセットのクロックは最初のセットアップ工程の間に同期化される。ＰＳｘはアセットｘの暫定的な仕様または許可である。したがって、これらのコミットメント値は認証セッションごとに異なり、各セッションに特有な値になる。各認証セッションのたびに、複数のアセットのそれぞれに固有の鍵が作られるため、攻撃者が不正にアクセスできる永続的な鍵や証明はない。

【0068】

ステップ４６になると、各アセットは共通のＡＥＳ鍵を用いてそのアセット自身のコミットメント値を暗号化し、暗号化したコミットメント値を第２の通信チャンネルすなわちバンド２を介して他のすべての参加しているアセットに送る（第２のバンドを用いることにより、安全性が高まるが、所定の実施形態では、たった一つのバンドであるバンド１のみを用いる）。各アセットは他のすべての参加しているアセットから受け取ったコミットメント値を復号化して、保存する。各アセットは、受領確認を受け取るまで、またはコミットメント交換のタイムアウトになるまで。暗号化されたコミットメント値を再び送り続ける。アセット、例えば、アセットＡが、アセットＡが送った暗号化されたコミットメント値を他のすべてのアセットが受け取ったという受領確認を受け取ると、アセットＡは第２のマイルストーンＭ２に到達したとみなされる。

【0069】

図５Ｂの段階４８および図２の段階８で示すように、各アセットはすべてのアセットが保存しているＡＥＳ鍵を用いてそのアセットのワンタイム秘密鍵を暗号化し、暗号化した秘密鍵を他のすべての参加しているアセットに通信バンド１を介して送る。コミットメント値と同様に、各アセットは他のすべてのアセットから暗号化した秘密鍵の受領確認を受け取るまでまたはタイムアウトの限度に到達するまで、この暗号化した秘密鍵値を繰り返し送る。タイムアウトの限度に到達する場合、符号１６が示すようにタイムアウトの限度に到達した特定のアセットは認証プロトコルに参加するのを取り止める。アセットがそのアセットの秘密鍵値の受領確認を他のすべてのアセットから受け取ると、このアセットは第３のマイルストーンＭ３に到達したとみなされる。各アセットは、所定の認証セッションに用いる受領した他のアセットの秘密鍵を、その所定のセッションの継続時間の間保存する。

【0070】

認証プロトコルにおける次の段階は、図２の段階１０で示すように、さらに図６中で詳細に示すように、「コミットメント値をチェックする」段階で、この段階では各アセットが他のすべてのアセットが送ってきたコミットメント値をチェックする。この段階では、段階５０で示されるように、各アセットは前の段階の後に保存された秘密鍵値とともに各アセット自身が有する他の認証をしてもらうアセットの属性のレコードを用いて、他の参加しているアセットそれぞれのすべてのコミットメント値の予測値を計算する。ここで、他の認証をしてもらうアセットの属性のレコードは、最初のデプロイメント前ハンドシェイク段階４ａの間に保存された属性のレコード、およびハンドシェイク段階４ｂに間に特定された属性のレコードである。

【0071】

例えば、アセットＡは段階４ｂで保存されているどのＵＩＤ値、ＰＳ値およびＩＮＦＯ値がアセットＢに対応するのかを決定する。アセットＡは段階４ｂの後にこれらの決定した値（ＩＮＦＯ値中のアセットＡの内部クロックにしたがう現在のタイムスタンプを含む）を用いて、さらに通信バンド１によってアセットＡに以前に送られてきたアセットＢ用の秘密鍵を用いて、前記したコミットメント値ハッシュ関数を計算する。

【0072】

その後段階５２で、各アセットは他のすべてのアセットの各々から最初に送られてきたコミットメント値と再計算されたコミットメント値が一致しているかをチェックする。もしもこれらのコミットメント値が一致していないならば、そのアセットは認証プロセスへの参加を止める。もしも所定のアセット、例えばアセットＡに対するこれらのコミットメント値が一致するならば、この所定のアセットは認証プロセスの第４のマイルストーンＭ４に到達したとみなされる。これらのコミットメント値が一致する場合、段階５４で各アセットは再計算されたコミットメント値をプロキシ１０２に送り、プロキシ１０２は他のすべてのアセット（例えば、アセットＡおよびアセットＢ）から最初に送られてきたコミットメント値とこれらの他のアセットから受け取った再計算されたコミットメント値が一致しているかどうかをチェックする。 もしもこれらのコミットメント値が一致しないならば、これらのコミットメント値が一致しないアセットは認証プロセスへの参加を止める。所定の実施形態では、プロキシがこの追加のチェックを実行するまで、各アセットは第４のマイルストーンＭ４に到達しない。

【0073】

【0074】

認証プロトコルは２つのアセットと一つのプロキシの場合に対応する例を説明したが、認証プロトコルは任意の数のアセットに拡張できることがわかる。この場合、ＩＮＦＯＳは参加しているすべてのアセットを表す情報を連結したものになり、ｋは参加しているすべてのアセットの秘密鍵のビットごとのＸＯＲになる。

【0075】

段階６２で、ＯＭＥＧＡ値はプロキシから各アセットに通信バンド２を介して送られる。 各アセットは段階６２でそのアセットが有し保存している、他のすべての認証をしてもらうアセットについてのデータを用いてＯＭＥＧＡ値を再計算し、これらのＯＭＥＧＡ値が一致するかを示す。 アセット（例えば、アセットＡ）が再計算したＯＭＥＧＡ値が、プロキシが送ってきたＯＭＥＧＡ値と一致することがそのアセットによって確認されると、このアセットは第５のマイルストーンＭ５に到達したとみなされる。このＯＭＥＧＡ値を再計算し、真正な値であることを確認する各アセットは、このようにしてこのＯＭＥＧＡ値が最初から認証セッションに参加した本物のプロキシから与えられたものであると判断する。

【0076】

プロキシの役割は、（プロキシは既に認証されていて、所定のバンドを用いて所定のタイプのデバイスの認証をするためのプロキシの役割等を果たす権限を与えられているので）一定レベルの信用を有する独立した第三者として振る舞って、認証セッションを独立して促進する、すなわちアセットＡ，Ｂおよび（もしもあるとすれば）他の参加しているアセットによって作られたコミットメントが真正なものであることを確認することを確実に行い、さらに認証をしてもらう複数のアセットに、これらのアセットによって変えることのできない最終ダイジェスト値Ωをブロードキャストで送信する。しかし、値Ωはすべての認証をしてもらうすべてのアセットが受け取り、これらのアセットによって再計算され、プロキシになりすましている可能性を排除する。

【0077】

認証プロトコルの最終段階は、図２の段階１４に示すように、さらに図８中に詳細に示すように各アセットが必要とされるすべてのマイルストーンを経たことをチェックすることである。この段階によって、認証プロトコル中に悪意のあるアセットが不正に参加できなくすることが確実になる。特定のアセット、例えばアセットＡが必要とされる５個のすべてのマイルストーンを経たことをチェックするため、アセットｘが２２４ビットの長さのストリングＭを発生するステップ７０が行われる。

Ｍ＝ハッシュ（Ｈ_Ｐ、Ｃ_Ｐ、Ｃ_Ｘ、Ω）

ここで、図６を参照して説明したように、Ｈ_Ｐはプロキシの圧縮されたＡＥＳで暗号化された属性、Ｃ_Ｐはプロキシのコミットメント値、Ｃ_Ｘはアセット自身のコミットメント値、さらにΩは最終ダイジェスト値である。これらの属性値のそれぞれは、必要とされるすべてのマイルストーンのそれぞれの前にアセットにより計算された、または受領されるので、所定のマイルストーンに対応する。したがって、これらの値が正しく発生していることは、所定のアセットがすべてのマイルストーンを経ていることに間違いないことになる。

【0078】

図８のチェックステップ７０中に明示的に示してはいないが、この発生した値はプロキシに送られ、プロキシは、プロキシが有する必要とされる値のレコードを用いて値Ｍを再計算する。これらの値が一致するならば、プロキシは２２４ビットの固有の認証番号（ＵＡＮ）、

ＵＡＮ＝ハッシュ（Ｍ）

を発生して、このＵＡＮ番号を認証プロトコルに参加しているすべてのアセットに送る。この番号を受け取った後、各アセット（例えば、アセットＡ）は、プロキシおよび他のすべての参加しているアセットにより「認証された」地位を受け取る。この手順は図８中の「Ｙｅｓ」の枝で示されており、この枝は「認証された」のボックスにつながっている。同じプロセスは認証プロセスに参加している他のすべてのアセットに適用される。これらのＵＡＮ番号は必要であれば、記録して保存することができ、例えばＵＡＮ番号をブロックチェーンの中に入れて記録することができる。

【0079】

すべてのアセットが認証された後、各アセットが設定（プロビジョニング）されることにより、そのアセットは所定の許可を有することになり、所定のタイプのデータを所定のポートを介して所定のアセットに送ること、および／または所定のデータ源にアクセスすることが可能になる。 例えば、ＰＳｘデータが設定されると、初期プロトコル・デプロイメントがうまくいくことにより、参加しているアセットはＰＳｘ中に定められた所定の行動を完了させることが自動的に許可されることになる。（デプロイメント後ハンドシェイクを用いて）すべてのアセットに対する認証の実行が結果的に成功した場合は必ず、認証されたアセットは自動的に同じ行動を完了することが許可され、同じ行動を再び実行するための許可を設定する必要がない。

【0080】

以上の説明中においては、アセットＡがいろんな場所で例として用いられてきたが、以上の説明はアセットＢにも同じようにあてはまるし、これらのアセットの一つまたは両方が複数のアセットの組を有する場合にもあてはまるし、プロキシに加えて互いに認証をしてもらう３個以上のアセットがある状況にもあてはまる。認証プロトコルによって、任意の数のアセットを同時に認証することが可能になる。

【0081】

前述した例では、２つの通信バンド、すなわちバンド１およびバンド２が用いられ、バンド２はコミットメント値と最終オメガ値を共有するために用いられ、バンド１は認証セッションの間の他のすべてのデータ交換用に用いられる。利用できる通信バンドがたった一つの場合、すべての情報がバンド１またはバンド２のいずれかの単一のバンドにより伝送されることにより認証プロトコルは進行する。

【0082】

前記した認証プロトコルの実施形態は、２個のデジタルアセットまたは２個の複数アセットからなる組が、第三者の証明や公共鍵基盤を必要としないで安心して互いに認証し合うことを可能にする耐量子攻撃性のある２点間認証の方法を提供すると考えられる。さらに、アセットまたは複数のアセットからなる組のいずれも、インターネット接続、中心に集まった通信手段、または第三者のデータベースを必ずしも必要とすることなく、認証プロセスを完了して、それによってリアルタイムで、「新たな」、常にオフで、必要な時に使える分散化した認証が可能になる。図３の初期デプロイメント「ハンドシェイク」段階の後、認証セッションの実行の間に参加しているアセット間で交換されるすべてのデータの値は乱数化され、ワンタイムであり、一方向であり、二度と同じ値にならない（ＳＨＡ－３の能力範囲内で）ものであり、これは、通信バンドを介していかなる身元データを開示することなく各アセットは他の参加しているアセットにその身元を証明しているのであり、証明がゼロ知識であることを意味する。このことにより、プロトコルの耐量子攻撃性を飛躍的に高め、リプレーまたは盗聴される原因がなくなる。このことは、例えば、複数回用いられ、対照的なブロック暗号である共有される認証用のＡＥＳ鍵を用いたりすることや、同ＡＥＳ鍵にのみ依存ことよりも有利である。もしもＡＥＳ鍵が敵対者に知られると、認証プロセスは不正アクセスされる。対照的に、前記した認証プロトコルの実施形態では、コミットメント値とアセット間で共有される秘密鍵はすべて各セッションに特有の唯一のワンタイム値であるから、不正アクセスするものはない。

【0083】

前記した認証プロトコルの実施形態の利点をさらに説明するため、次に前記した認証
プロトコルに対して配備される、いくつかの可能な悪意のある攻撃を説明する。前記した認証プロトコルが可能の攻撃のそれぞれに対していかにして反撃するかについて説明する。これらの説明は、添付する図面を参照して開示する例となる実施形態についてのみに関するものであり、これらの説明が必ずしも本願発明のすべての実施形態に同じようにあてはまるものではない。

【0084】

盗聴攻撃
攻撃者は有線で、または無線で伝送される情報を盗聴し、その情報を将来の目的のために使う。これはリプレー攻撃の一種である。これはネットワーク盗聴またはオフライン盗聴にもなる。

【0085】

デプロイメント後認証セッションの間に交換されたすべてのデータは、乱数化されたワンタイムで一方向（非可逆）の値であるから、前記した認証プロトコルの実行の間には盗聴される原因がない。すべてのアセットが初めて前記認証プロトコルを実行するのに、この実施形態では必須である初期プロトコル・デプロイメントのセッションに、アセット攻撃者は参加していないので、アセット攻撃者は、アセットＡ（プロキシおよび組の中の他のアセットだけでなく）の真の属性（ＵＩＤ、ＩＮＦＯ、ＰＳ）を初めは知らない。その結果、アセット攻撃者は他の参加しているアセットの正しいコミットメント値を再計算して、図６中に示す前記した認証プロトコルのコミットメント値チェック段階でコミットメント値が一致していることを証明できない。

【0086】

アセット攻撃者は他のアセットによって作られたコミットメントの再計算値（一致を示す、正しい、または誤りの論理信号だけではなく）を送らなければならず、プロキシが他のアセットによってもともと送られた当該他のアセットのコミットメント値と盗聴されたアセットに代わってアセット攻撃者が送った当該他のアセットのコミットメント値とが一致しているかをチェックする。もしもこれらのコミットメント値が一致していないことをプロキシがわかると、一致していないコミットメント値を再計算したアセット（すなわちアセット攻撃者）は拒絶されて、報告される。

【0087】

進行中のセッション中に盗聴されたデータは、それが再生されたとしても次のセッションには役立たない。なぜならば、図４ａおよび図４ｂ中に示すハンドシェイク段階では、アセット攻撃者は、他の参加しているアセットおよびプロキシの真の属性（ＵＩＤ，ＩＮＦＯ、ＰＳ）について初めから知らないため、受け取ったハッシュ値から当該他の参加しているアセットおよびプロキシの真の属性を導き出すことができないからである。このことから、アセット攻撃者は図６中に示すコミットメント値チェック段階で他の参加しているアセットおよびプロキシに対応する正しいコミットメント値を再計算できない。再び言うが、コミットメント値が一致していることをプロキシが証明しない場合、一致しないコミットメント値を再計算したアセット（すなわちアセット攻撃者）は拒絶されて、報告される。初期デプロイメントの間、すべてのアセットはＵＩＤ、ＩＮＦＯおよびＰＳのＡＥＳで暗号化された値を共有しているが、図３のハンドシェイク段階の間、この初期デプロイメントがおきるのは１回のみであり、再び言うが、この共有されたデータは、その後のデプロイメント後認証セッションのどれでも価値がない。

【0088】

中間者攻撃
中間者攻撃は盗聴攻撃の一種である。攻撃者は２個のアセットの間、またはアセットとプロキシの間の中に入って、これらの間の通信がすべて攻撃者を通ることになる。そのため、攻撃者は両方のパーティのそれぞれになりすましてその相手と対し、両方のパーティの間のデータトラフィックの一部をコピー、改竄、消去する、すなわち相互認証への攻撃をする可能性がある。この攻撃は受動的な攻撃または能動的な攻撃になるかもしれない。

【0089】

中間者攻撃を防ぐため、すべてのアセットとプロキシはそれらのＡＥＳにより暗号化された真の属性（ＵＩＤ、ＩＮＦＯ、ＰＳ）を互いに共有することによって、ワンタイム初期プロトコル・デプロイメントの間は相互に認証されている。中間者が認証されたアセットになりすますと仮定すると、その中間者は初期プロトコル・デプロイメント段階を経ていないので、既に認証されたアセットおよびプロキシの真の属性について初めから知らない。この中間者は、図６のコミットメント値チェック段階で認証されたアセットとプロキシに対応する正しいコミットメント値を再計算できず、認証されない、すなわち信用されないので、その中間者はどれかのアセットになりすまそうとするかもしれないが、そのアセットに代わって所定の行動をすることはできない。

【0090】

偽アセット
この攻撃において、アセット攻撃者は（例えば、コピーされた）合法的なアセットのコピー（クローン）として振る舞い、何かの理由で接続が切れた後、合法的なアセットがするようにプロキシに対して認証要求を発行して、他のアセットとともに認証セッションに参加しようとする。

【0091】

ＡＥＳ暗号化鍵を知っているとしても、偽アセットは図６のコミットメント値チェック段階を完了することに成功できない。デプロイメント後プロトコルのデータ交換はゼロ知識証明である、すなわち、アセットおよび／またはプロキシは、その真の身元データを他のアセットに明示することなくその身元データ（ＵＩＤ、ＩＮＦＯ、ＰＳ）の細切れになった値のみを他の参加しているアセットと共有している。

【0092】

たとえ偽アセットが本物のアセットの完全なクローンでそのためＩＮＦＯデータとＰＳデータを知っているとしても、コミットメント値および最終ダイジェスト値を前記したように計算するのに用いる、その偽アセットの乱数化された固有ＩＤ、ＵＩＤ＝ＨＩＤ．ＶＩＤ．ＣＩＤ、は空値か異なる値なので、その偽アセットは図６のコミットメント値チェック段階で拒絶されて、報告される。

【0093】

一番初めのワンタイムプロトコルの初期デプロイメント段階の間にアセット攻撃者が複数のからなる組の中に何とかしてもぐり込んだとしても、その間にはこれらのアセットが自身の属性を共有しているが、この合法的でないアセットも新しいＡＥＳ暗号鍵がインストールされていなければならないため、この攻撃は失敗する。このＡＥＳ鍵は、合法的なアセットが前記した初期デプロイメント型の認証プロトコルを経る前に、その合法的なアセットのみに予めインストールされる。

【0094】

偽プロキシ
この攻撃の中では、攻撃者は他のアセットに対する認証プロセスを促進し、合法的なアセットの認証をしてもらうための申し込み（要求）に対して応答する合法的なプロキシとして振る舞う。認証プロトコルは相互に認証をする手法を実行するので、すべてのアセットはプロキシのコミットメントもチェックする。この特徴があるため、偽プロキシの場合は前述した偽アセットの場合と同様になる。相違点は単に偽プロキシが拒絶されて、報告されるときである。プロキシはアセットが認証プロセスの次の段階に進むかどうかをチェックして判定する図６のコミットメント値チェック段階では、本物の認証をしてもらうアセットはこの段階では偽プロキシであることがわからない。しかし、図７の最終ダイジェスト段階では、すべてのアセットが、偽プロキシが知らせてきたダイジェスト値を再計算して、そのダイジェスト値をこれらのアセットが知っている本物のプロキシの属性に基づいて計算したダイジェスト値を比較した後、これらの本物のアセットは不一致を検出し、このプロキシが合法的なものでないと報告し、認証セッションから撤退する。

【0095】

他のアセットの属性を復号化して、他のアセットのＵＩＤ、ＩＮＦＯおよびＰＳを知るためにプロキシには新しいＡＥＳ暗号鍵がインストールされていなければならないため、もしも偽プロキシが一番初めのワンタイム初期デプロイメント・プロトコルの間に、認証をしてもらう複数のアセットの組の中に何とかしてもぐり込んでも、この偽プロキシはこの攻撃もあきらめる。ＡＥＳ鍵は合法的なアセットのみに、そのアセットが初期デプロイメント・プロトコルを経る前に予めインストールされる。

【0096】

（次に来るデプロイメント後セッション中の）リプレー攻撃
この攻撃では、攻撃者は認証されるため自身が合法的なアセットの一つであるとプロキシと他のアセットに思わせようとして、（前のセッションで盗聴された）特定のアセット認証セッションの値を次のセッションでリプレーしようとする。

【0097】

この場合の攻撃者は図３中に示す初期プロトコル・デプロイメントセッションを経ていなかったので、同攻撃者は（同じ組の、他のアセットアセットＡの真の属性（ＵＩＤ、ＩＮＦＯ、ＰＳ）を初めから知らなかった。その結果、この攻撃者は受け取った細分化されたデータの値のみに基づいて、他のアセットの属性を決められない。結果として、プロキシがコミットメント値の一致を調べるためにチェックするときに、この攻撃者はプロキシおよび他のアセットの正しいコミットメント値を再計算して一致していることを証明することができない。さらに、すべてのアセットのＩＮＦＯ属性はタイム－ピリオド・スタンプも含む。そのため、異なる（時刻＋ｘ秒期間）では、ＩＮＦＯ属性値は異なり、その結果、計算されるコミットメント値および最終ダイジェスト値はすべてのセッションのそれぞれで異なる。この特徴のため、後で行う認証セッション中でのリプレー攻撃を効果的に防ぐことができる。

【0098】

本物のアセット自身が計算したコミットメント値を送らなければならない図６中の認証プロトコルのコミットメント値チェック段階で、攻撃者が新しいコミットメント値を計算しないで、その前に盗聴した攻撃された本物のアセット（例えばアセットＢ）のコミットメント値を単に送るとする。盗聴されたアセットＢのコミットメント値は、プロキシが始めに知っているアセットＢの真の属性（ＵＩＤ、ＩＮＦＯ、ＰＳ）と現在のタイム－ピリオド・スタンプに基づいてプロキシが再計算するアセットＢの現在のコミットメント値とは異なって現れる。その結果、アセットＢの盗聴者はプロキシによって拒絶されて、報告される。

【0099】

（進行中のデプロメント後セッションの範囲内での）リプレー攻撃
この攻撃では、攻撃者は認証されるため自身が合法的なアセットであるとプロキシと他のアセットに思わせるために、目標とするアセットの認証セッションの値を進行中のセッション中でリプレーしようとする。この場合の攻撃者は図３の初期プロトコル・デプロイメントセッションを経ていなかったので、同攻撃者は（同じ組の、他のアセットアセットＡの真の属性（ＵＩＤ、ＩＮＦＯ、ＰＳ）について初めから知らない。その結果、この攻撃者は受け取った細分化されたデータの値のみに基づいて、他のアセットの属性を決められない。結果として、プロキシがコミットメント値が一致しているかチェックするときに、この攻撃者は、「自身」のコミットメント値を計算して、またはプロキシおよび他のアセットの正しいコミットメント値を再計算して、一致していることを証明することができない。

【0100】

デプロイメント後ハンドシェイク段階（図４ａおよび図４Ｂ）の間に伝送される新しい乱数化されたハッシュ値およびノンスはいずれも、アセット受領者がそれを受け取るとすぐに（アセット受領者から見ると）無効になる。攻撃者がデータを盗聴するには、少なくとも一回のワンタイムデータ伝送イベントが必要である。もしも攻撃者が同じセッションで盗聴されたデータを伝送したいとしても、受領者は盗聴しているアセットＢから後で受け取るワンタイム値を既に本物のアセットＢから、受け取っているので、これらの同じデータは受領者によって拒絶される。この状況では、攻撃者は拒絶され、報告される。

【0101】

注入攻撃
この攻撃はリプレー攻撃を切り抜けた後に使われる。この攻撃では、攻撃者は誤ったデータを複数の認証されたアセットの組の中に注入する。この攻撃者はそれをするために認証されていなければならない。前述した認証プロトコルの実施形態はリプレー攻撃を防いでいるので、この注入攻撃も防止できる。

【0102】

セッション・ハイジャック攻撃
この攻撃では、攻撃者はプロキシの代わりとなって、またはセッションの最中にプロキシとしてもぐり込んで認証セッションをコントロールしようとする。

【0103】

認証プロトコルは偽プロキシ（前記参照）を用いる認証の可能性を防ぎ、どのセッションの終わりにも、いかなるアセットも認証プロトコルの必要なすべてのマイルストーンを経ていなかったならばそのアセットが認証される可能性を排除する最終マイルストーンチェック段階（図８参照）があるので、攻撃者が認証セッションをハイジャックしてその認証セッションを完了することは不可能である。

【0104】

総当たり
総当たり攻撃は認証セッションの間に複数のアセットが交換するデータ値を取得するために用いる試行錯誤方法である。総当たり攻撃では、自動化されたソフトウェアを用いて欲しいデータの値についての極めて多数の連続する推測値を発生する。この認証プロトコルの実施形態では、アセットの属性は乱数化された一方向ＳＨＡ－３ハッシュ関数を用いて細分化され、このようなハッシュ値からアセットの属性データをリバースエンジニアリングすることが不可能であることは極めて高い確率で言える。 さらに、セッションの継続時間は極めて短く（認証をしてもらうアセットの数にもよるが、通常０．０１秒未満）、ＳＨＡ－３で細分化されたアセットのコミットメント値はセッションに参加しているすべてのアセットのそれぞれで異なり、ＳＨＡ－３で細分化された最終ダイジェスト値は新しい認証セッションのたびに異なる値になる。したがって、このように極めて短時間の間で交換されるすべての認証値の正しい組み合わせを推測することは、実際には不可能かつ実行不能であり、総当たり攻撃のリスクは最小化されている。

【0105】

本願発明をその一つ以上の実施形態を説明することによって解説したが、本願発明はこれらの実施形態に限定されるものではなく、添付する特許請求の範囲の技術的範囲内で多くの変更および変形が可能であることを、当業者は理解するはずである。

【図1】

【図2】

【図3】

【図4a】

【図4b】

【図5A】

【図5B】

【図6】

【図7】

【図8】