特許 7394867 デバイスの識別と監視のための方法およびシステム

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

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

(11)【特許番号】

(24)【登録日】2023-11-30

(45)【発行日】2023-12-08

(54)【発明の名称】デバイスの識別と監視のための方法およびシステム

(51)【国際特許分類】

   H04L 9/08 20060101AFI20231201BHJP

   G06Q 10/083 20230101ALI20231201BHJP

   G06Q 10/0836 20230101ALI20231201BHJP

   H04W 12/06 20210101ALI20231201BHJP

【ＦＩ】

H04L9/08 F

G06Q10/083 320

G06Q10/0836

H04W12/06

【請求項の数】 5

(21)【出願番号】P 2021560974

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

(65)【公表番号】

(43)【公表日】2022-06-23

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

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

(87)【国際公開日】2020-11-19

【審査請求日】2021-10-14

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

(32)【優先日】2019-05-10

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

【前置審査】

(73)【特許権者】

【識別番号】517451940

【氏名又は名称】エヌイーシー ラボラトリーズ ヨーロッパ ゲーエムベーハー

(74)【代理人】

【識別番号】100124811

【弁理士】

【氏名又は名称】馬場 資博

(74)【代理人】

【識別番号】100088959

【弁理士】

【氏名又は名称】境 廣巳

(74)【代理人】

【識別番号】100097157

【弁理士】

【氏名又は名称】桂木 雄二

(74)【代理人】

【識別番号】100187724

【弁理士】

【氏名又は名称】唐鎌 睦

(72)【発明者】

【氏名】カラメ ガッサン

(72)【発明者】

【氏名】ソリエンテ クラウディオ

(72)【発明者】

【氏名】リー ウェンティン

【審査官】中里 裕正

(56)【参考文献】

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

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

【文献】国際公開第２０１８／２３０３０５（ＷＯ，Ａ１）

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

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

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

Ｈ０４Ｌ ９／０８

Ｇ０６Ｑ １０／０８３

Ｇ０６Ｑ １０／０８３６

Ｈ０４Ｗ １２／０６

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

【請求項1】

複数の参加エンティティによって提供および／または操作されるネットワーク（１）のデバイス（４）を識別および監視するための方法であって、
前記参加エンティティがノード（６）を介して分散型台帳ネットワーク（５）の台帳またはブロックチェーンとの間でレコードを発行および取得することができるよう構成されており、前記参加エンティティのそれぞれの１つ以上のノード（６）が配置された分散型台帳ネットワーク（５）が構築され、
各デバイス（４）に固有の認証済み公開鍵を割り当てる公開鍵インフラストラクチャを設定し、
前記分散型台帳ネットワーク（５）の台帳に、デバイス（４）の更新されたステータスを保存し、
前記参加エンティティのノードが、デバイス（４）のステータスが変更されると、デバイス（４）の公開鍵が記録されたデバイス（４）のステータスの変更に関連するトランザクションを前記台帳に発行し、
デバイスの秘密鍵は各デバイス内に隠されており、デバイスの公開鍵は外部から認識可能であり、
さらに、ハードウェアベンダー（２）またはネットワークオペレーター（３）のノードは、サプライチェーンメンバーからのデバイス（４）の受領に応じて、
デバイス（４）の公開鍵を読み出し、
前記台帳にデバイス情報を問い合わせ、
前記台帳からのデバイス情報がデバイス（４）の公開鍵と一致した場合に、前記台帳にレコードを発行して、デバイスのステータスを受領済みとして更新する、
ことを特徴とする方法。

【請求項2】

前記ネットワーク（１）が、４Ｇ ＬＴＥ／ＬＴＥ-Ａｄｖａｎｃｅｄ ネットワークまたは５Ｇネットワークなどの大規模動的ネットワークである、
請求項１に記載の方法。

【請求項3】

前記複数の参加エンティティは、ハードウェアベンダー（２）、サプライチェーンメンバー、およびネットワークオペレーター（３）を含む、
請求項１または２に記載の方法。

【請求項4】

ハードウェアベンダー（２）またはネットワークオペレーター（３）からデバイス（４）の配送を行うサプライチェーンメンバーのノードは、デバイス（４）のステータスが出荷済みであることを表す情報と共に、デバイス（４）の公開鍵と、ハードウェアベンダー（２）またはネットワークオペレーター（３）の識別情報と、を含むレコードを前記台帳に発行する、
請求項１乃至３のいずれかに記載の方法。

【請求項5】

ネットワーク（１）のデバイス（４）を識別および監視するためのシステムであって、
ネットワーク（１）のデバイス（４）を提供および／または操作する複数の参加エンティティのそれぞれの１つ以上のノードが配置された分散型台帳ネットワーク（５）と、
各デバイス（４）に固有の認証済み公開鍵を割り当てる公開鍵インフラストラクチャと、
を備え、
前記参加エンティティのノードは、デバイスのステータスが変化されると、デバイス（４）の公開鍵が記録されたデバイス（４）のステータスの変更に関連するトランザクションを台帳に発行することによって、前記分散型台帳ネットワーク（５）の台帳にデバイス（４）の更新されたステータスを保存するよう構成されており、
デバイスの秘密鍵は各デバイス内に隠されており、デバイスの公開鍵は外部から認識可能であり、
さらに、ハードウェアベンダー（２）またはネットワークオペレーター（３）のノードは、サプライチェーンメンバーからのデバイス（４）の受領に応じて、
デバイス（４）の公開鍵を読み出し、
前記台帳にデバイス情報を問い合わせ、
前記台帳からのデバイス情報がデバイス（４）の公開鍵と一致した場合に、前記台帳にレコードを発行して、デバイスのステータスを受領済みとして更新する、
ように構成されている、
ことを特徴とするシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークのデバイスを識別及び監視するための方法およびシステムに関する。

【背景技術】

【0002】

4G（LTE / LTE-Advanced）や5Gネットワークなどの大規模な動的ネットワークは、さまざまなメーカーが製造し、さまざまなネットワーク事業者が管理する数十億の異種デバイスを接続する。その結果として、デバイスが信頼できるかどうかを判断することなどを目的にデバイスを識別することは複雑な作業となる。第１に、ほとんどのデバイスには認証手段がない。第２に、デバイスのソフトウェアまたはハードウェア構成が異なり、複数の関係者によって処理されている可能性がある。これらにより、デバイスが信頼できる状態にあるかどうかを確認するためのタスクは妨げられている。

【発明の概要】

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

【0003】

実行可能なオプションの一つとしては、デバイスのライフサイクルに関する情報を収集する、ということがある。しかしながら、ネットワークデバイスのライフサイクル情報は、利用可能であったとしても、現在、メーカー、サプライチェーン関係者、ネットワーク会社、クラウドサービスプロバイダー、およびエンドユーザーのデータベースの間で断片化されている。また、ほとんどの場合において、上記のようなデータベースはプライベートなものとなる。加えて、公開されている場合であっても、得られる情報が悪意を持って操作されていないことを確認する手段はない。したがって、デバイスに関する情報を収集し、それが信頼できるかどうかを判断することは難しい。

【0004】

したがって、本発明の目的は、デバイスが信頼できるかどうかの決定を容易にする方法であって、ネットワークのデバイスを識別および監視するための方法およびシステムを改善し、さらに開発することである。

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

【0005】

本発明によれば、上述した目的は、複数の参加エンティティによって提供および／または操作されるネットワークのデバイスを識別および監視するための方法によって達成される。
その方法は、
参加エンティティのそれぞれが１つ以上のノードを維持している分散型台帳ネットワークを設定し、
ネットワークに展開される前に、各デバイスに固有の認証済み公開鍵を割り当てる公開鍵インフラストラクチャを設定し、
実行に対して提供することによって、分散型台帳ネットワークの台帳に、デバイスの更新されたステータスを保存し、
参加エンティティによって、デバイスのステータスの変更を識別し、デバイスの公開鍵が記録された、デバイスのステータスの変更に関連するトランザクションを台帳に発行する、
ように構成されている。

【0006】

さらに、上述した目的は、ネットワークのデバイスを識別および監視するためのシステムによって達成される。
そのシステムは、
ネットワークのデバイスを提供および／または操作する複数の参加エンティティと、
ネットワークに展開される前に、各デバイスに固有の認証済み公開鍵を割り当てる公開鍵インフラストラクチャと、
参加エンティティのそれぞれが１つ以上のノードを維持している分散型台帳ネットワークと、
を備え、
参加エンティティは、デバイスのステータスの変化を識別し、デバイスの公開鍵が記録されたデバイスのステータスの変更に関連するトランザクションを台帳に発行することによって、分散型台帳ネットワークの台帳にデバイスの更新されたステータスを保存するよう構成されている。

【0007】

本発明の方法およびシステムは、大規模動的ネットワークのデバイスを識別および監視するための分散型アプローチを提供する。このような環境では、さまざまなオペレーターがさまざまなメーカーの異種デバイスを展開している。そのため、特定のデバイス上の情報は管理ドメイン間で断片化されており、一般的に、真正なデバイスと偽造されたデバイスを区別することは困難である。

【0008】

この問題に対処し、グローバル動的ネットワークで簡略化されたデバイス識別を可能にするために、本発明の実施形態における方法およびシステムは、公開鍵インフラストラクチャ（ＰＫＩ）および許可型分散型台帳技術（ＤＬＴ）、およびいくつかの実施形態では、ｔｒｕｓｔｅｄ ｅｘｅｃｕｔｉｏｎ ｅｎｖｉｒｏｎｍｅｎｔs（ＴＥＥ）を組み合わせる。公開鍵インフラストラクチャは、ａ）各デバイスに識別情報を提供し、ｂ）デバイスの識別情報を証明するための手段を提供する。このような状況では、ＴＥＥは、デバイスの秘密鍵が漏洩しないことを保証でき、デバイスのハードウェアおよびソフトウェア構成を（例えば、リモート認証を介して）検証することが可能となる。

【0009】

分散型台帳は、参加しているノード間で分散型ストレージを提供する。具体的は、台帳は、デバイス識別情報管理、デバイス履歴管理、ソフトウェア更新管理を統合するために使用される。各利害関係者、すなわち参加している各エンティティは、分散型台帳ネットワーク内に少なくとも１つのノードを保持する。利害関係者は、分散型台帳ネットワーク内のノードを使用して、分散型台帳ネットワークの台帳との間でレコードを発行したり読み出すことができる。

【0010】

実施形態では、台帳は、許可されたピアのみが台帳にアクセス／更新できるように許可を与えている。いずれの場合も、台帳のデータの分散コピーにより、障害又は攻撃が一か所で生じても許容されるため、台帳は堅牢なシステムを提供する。一方、台帳の合意プロトコルは、情報ブロードキャスト、トランザクション検証、およびブロックマイニングによって、参加しているすべてのノード間でデータの一貫性を保証する。従って、本発明は、デバイスが信頼できるかどうかを決定するためにデバイスの履歴およびステータスを照会することができる分散型データベースを提供する。現在の状況では、このような情報は、スケーラビリティと整合性の観点から問題に直面している複数のデータベースにわたって断片化されている。

【0011】

実施形態では、デバイス製造業者またはハードウェアベンダーは、ＰＫＩ認証局として機能し、製造時に各デバイスに固有の認証された公開鍵を事前にロードすることができる。ＰＫＩ情報は、既存のネットワークデバイスとその公開鍵の改ざん防止ログを取得するために、分散型台帳に提供またはキャストされる場合がある。さらに、ネットワークデバイスがある利害関係者から別の利害関係者に移動するとき（たとえば、製造業者からサプライチェーンメンバー（例えば、運送会社）に荷下ろしされるとき、または運送会社から受取人（たとえば、ネットワークオペレーター）に配達されるとき）はいつでも、レコードが分散型台帳に追加される。製造元は、デバイスのファームウェア／ソフトウェアの更新を配布し、分散型台帳で更新が可能であることを通知することもできる。

【0012】

実施形態では、デバイス所有者、例えばネットワークオペレーターは、例えば定期的またはイベントベースで、自身のデバイスのステータスを認証するように構成された証明サービスを実行することができる。認証のタイプは、認証されるデバイスによって異なる場合がある。デバイスにＴＥＥがある場合、認証では、デバイスで実行されているソフトウェアを検証し、デバイスの公開鍵が承認されていることを検証する。デバイスにＴＥＥがないが公開鍵を提示している場合、認証では、デバイスが対応する秘密鍵を保持していること、およびデバイス製造業者が公開鍵を承認していることを検証する。デバイスにＴＥＥも公開鍵もない場合、認証サービスは、デバイスの識別／指紋認証を試みる場合がある。実際に適用される認証メカニズムとは関係なく、デバイスが認証されるたびに、ネットワークオペレーターが認証の結果とともにレコードを分散型台帳に追加する、ことが提供される。

【0013】

従って、分散型台帳は、許可された関係者により、特定のデバイスについて、公開鍵と、ａ）製造から展開までの出荷、ｂ）ファームウェア／ソフトウェアの更新、およびｃ）認証、に関する履歴と、を取得するために問い合わせられる。取得された情報は、分散型台帳から取得されたデバイス情報に基づいて、予め定義された又は設定されたリスク評価ルールを適用することにより、デバイスが信頼できるかどうかを決定するよう構成されたリスク評価サービスに提供される。リスク評価に合格した場合、デバイスは信頼できるまたは本物であると認定され、ネットワークオペレーターはデバイスを稼働させ、ネットワークへのデバイス接続を提供することができる。さもなければ、ネットワークオペレーターは、デバイスが危険にさらされている、または偽造されていると見なし、デバイスを拒否する可能性がある。

【0014】

本発明における教示内容を設計し、さらに発展させる好適な方法はいくつかある。このため、一方では、従属請求項を参照し、他方では、図面によって示されるような例示の方法による本発明の実施形態の説明を参照する必要がある。図面を用いた本発明の好ましい実施形態の説明に関連して、一般的に好ましい実施形態と教示内容のさらなる改良が説明されうる。

【図面の簡単な説明】

【0015】

【図1】本発明の実施形態における分散型台帳およびネットワークインフラストラクチャーの構造を示すシステムの概略図である。

【図2】本発明の実施形態における、デバイス展開前のネットワークオペレーターによるデバイス検証プロセスを示す概略図である。

【図3】本発明の実施形態における委任されたデバイス認証サービスを示す概略図である。

【図4】本発明の実施形態におけるデバイスのＴＥＥによる遠隔デバイス認証を示す概略図である。

【図5】疑似ランダムメモリトラバーサルに基づくソフトウェア認証の実行を示す概略図である。

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

【0016】

本発明は、ネットワーク、特に４Ｇ／５Ｇ通信ネットワークなどの大規模動的ネットワーク内のデバイスを識別および監視するための方法およびシステムに関するものである。デバイスは、複数の参加エンティティによって提供され、操作され、および／または制御されるものである。以下に詳細に説明する実施形態では、ハードウェアベンダー、サプライチェーンメンバー、およびネットワークオペレーターが、ネットワークの参加エンティティを構成することとする。しかしながら、当業者によって理解されるように、本発明では、これら特定の参加エンティティに限定されない。すなわち、異なる機能、義務、活動領域および／または責任を有するさらなるエンティティが、ネットワーク内でデバイスを提供し、操作し、および／または制御することによって、ネットワークに参加してもよい。

【0017】

図１は、本発明の一実施形態を示し、上記の利害関係者（ハードウェアベンダー２、サプライチェーンメンバー（図１には明示的に示されていない）およびネットワークオペレーター３）が、参加エンティティとして関与するモバイル通信ネットワーク１を示している。一般的に、ハードウェアベンダー２は、ネットワークルーター、スイッチ、サーバー、スマートフォンなどを含むネットワークデバイス４を製造および商品化するエンティティである。サプライチェーンメンバーは、デバイス４の出荷と配送に使用される流通ネットワークに属するエンティティである。ネットワークオペレーター３（クラウドネットワークサービスプロバイダー３ａを含む）は、ハードウェアベンダー２からデバイス４を取得するエンティティであり、取得したデバイス４を展開して維持する責任を有する。ネットワークオペレーター３はまた、他のネットワークオペレーター３からデバイス４を取得することができる。

【0018】

実施形態では、分散型台帳ネットワーク５は、上記のエンティティのそれぞれが分散型台帳ネットワーク５のメンバーである場合に確立される。分散型台帳ネットワーク５のメンバーであるということは、各参加エンティティが分散型台帳ネットワーク５内に１つまたは複数のノード６を維持することを意味する。すなわち、それらのノード６を介して、参加エンティティは、分散型台帳ネットワーク５の台帳またはブロックチェーンにレコードを発行し、台帳またはブロックチェーンからレコードを取得できる。さらに、上記のエンティティのいずれかが「マイナー」としても機能し、それによって分散型台帳の合意アルゴリズムに参加する場合がある。以下、分散型台帳とブロックチェーンという用語は同義語として使用される。

【0019】

実施形態では、許可型分散型台帳として実装されうる分散型台帳は、識別サービスを特徴とする。識別サービスは、モバイル通信ネットワーク１の参加エンティティのそれぞれに承認された公開鍵を提供するために使用されうる。そのため、任意の２つの参加エンティティ間の通信が認証され、また、分散型台帳に発行されたレコードが認証される。

【0020】

実施形態では、分散型台帳は、複数の異なる管理ドメイン７内で、モバイル通信ネットワーク１に関与するすべてのネットワークデバイス４のライフサイクル情報を保持する。例えば、これにより、ネットワークオペレーター３は、以下でより詳細に説明されるように、出荷中および動作中の両方において、任意のデバイス４のステータスをチェックすることができる。

【0021】

図１は、分散型台帳ネットワーク５の構造を、通信ネットワークインフラと関連するエンティティとともに示している。実施形態では、参加エンティティまたは利害関係者として、ハードウェアベンダーＡ、ネットワークオペレーターＢ、クラウドプロバイダーＣ、およびネットワークオペレーターＤが含まれる。点線で示されているように、すべての利害関係者は、分散型台帳ネットワーク５内に１つまたは複数のノード６を維持している。

【0022】

ハードウェアベンダー２は、ネットワークデバイス４の公開鍵インフラストラクチャー（ＰＫＩ）を維持する。一方、ネットワークデバイス４の秘密鍵は、それぞれのデバイス４がＴＥＥを備えている場合にはトラステッドコンピューティングベース（ＴＣＢ）で保護され、それぞれのデバイス４がＴＥＥを備えていない場合には読み取り専用メモリ（ＲＯＭ）で保護されうる。デバイス４の公開鍵は、参加エンティティが分散型台帳ネットワーク５の台帳に発行するトランザクションに記録される。デバイス４のステータスが更新されるか変更されるときはいつでも、更新または変更されたデバイスステータスを示すそれぞれのトランザクションが分散型台帳ネットワーク５に発行され、その結果、台帳は常に最新のデバイス情報を格納する。このデバイス情報には、デバイスの所有者、維持者、ステータス（出荷／受け取り／展開／無効）、認証結果、ファームウェアバージョンなどの情報が含まれる場合がある。本発明の実施形態では、ネットワークオペレーター３は、ネットワークオペレーター３のネットワーク／管理ドメイン７に接続するためにデバイス４にアクセスを許可する前に、デバイス４のステータスを常にチェックするように構成される。他方、設定データベース１８に示されるようなルーティングポリシーなどの各ネットワーク内のデバイス４の設定は、デバイス４のライフサイクル情報に関係するので、各ネットワークオペレーター３によって独立して維持されうる。

【0023】

実施形態では、分散型台帳は、すべてのデバイス４の識別管理に使用可能である。特に、サプライチェーン内および稼働中のデバイスステータスは、台帳で更新される可能性があり、そのため、すべての利害関係者が利用できる。さらに、分散型台帳は、例えば、すべてのデバイス４上で実行されているソフトウェアの管理ばかりでなく、すべてのデバイス４の所有権／リース／レンタルの履歴の管理のためにも使用されうる。当業者によって理解されるように、さらなる使用例が想定されてもよい。

【0024】

実施形態では、各ハードウェアベンダー２は、デバイスが工場を出荷される前に、デバイス４それぞれに承認された公開鍵を埋め込む独自のＰＫＩ（公開鍵インフラストラクチャー）を設定することが提供されうる。公開鍵はデバイス４の識別情報として使用される。デバイス４がＴＥＥ（Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ）を有している場合、デバイス４の秘密鍵は、デバイスのＴＥＥのＴＣＢのセキュアストレージに保存される。あるいは、秘密鍵は、デバイス４のファームウェア／ＯＳ（オペレーティングシステム）に、特にＲＯＭなどの変更が難しいメモリ領域に、ハードコードされてもよい。秘密鍵はデバイス４内に安全に隠されているが、デバイス４の公開鍵は、外部から認識できるようにすることができる。一例として、実施形態では、公開鍵は、例えばデバイス４のパッケージに印刷することによって（ＱＲコードの形式など）、可視化されうる。デバイス４の公開鍵をパッケージに表示することにより、デバイスの認証をデバイスの出荷履歴に関連付けることができる。

【0025】

実施形態では、ハードウェアベンダー２は、デバイス４の公開鍵の失効も処理する。失効の決定では、分散型台帳で入手可能なアカウント情報、または他のソースから取得した情報を考慮に入れる場合がある。

【0026】

最後に、ハードウェアベンダー２は、新しいファームウェアを公開することでファームウェアの更新に対応する。デバイス４上のファームウェアの更新は、無線でハードウェアベンダー２によって実行されてもよく、あるいは、デバイス所有者（例えば、ネットワークオペレーター３またはクラウドプロバイダー３ａ）の手動介入を必要とされてもよい。後者の場合、ハードウェアベンダー２は、単に更新されたファームウェアを配布または公開すればよい。

【0027】

図1に示すように、ハードウェアベンダー2は、次のいずれかのイベントが発生したときに、分散型台帳にレコードを発行できる。

【0028】

１）新しいデバイス４が製造された：この場合、トランザクションレコードが、デバイスの公開鍵を含む新しいデバイス４に関する情報（例えば、モデル、ハードウェア特性、シリアル番号）を保持するよう実行される。
２）デバイス４が所定のサプライチェーンメンバーを介して出荷された：この場合、トランザクションレコードが、デバイス４の公開鍵およびサプライチェーンメンバーの識別情報を保持するよう実行される。
３）既存のデバイスを廃止する必要がある：この場合、レコードが、廃止されるデバイスの公開鍵と、廃止理由などの追加情報を保持するよう実行される。
４）新しいファームウェアが特定のデバイスモデルで利用可能となる：この場合、レコードが、デバイスモデル、ファームウェアの署名付きダイジェスト、およびファームウェアを取得するＵＲＬを含むよう実行される。
５）デバイスＸのファームウェアがバージョンＹに更新された：この場合、レコードにはデバイスの公開鍵とファームウェアのダイジェストが含まれる。

【0029】

上記リストはすべてではなく、ハードウェアベンダー２が台帳にレコードを発行するきっかけとなるさまざまなイベントが想定される場合がある。

【0030】

より具体的には、デバイス４が製造されると、ハードウェアベンダー２は、以下の数１のように構成されうるそれぞれのトランザクションメッセージを生成する。

【数1】

【0031】

トランザクションメッセージは分散型台帳に公開される。トランザクションメッセージには、上記の例では「produced」と設定された「現在のステータス」パラメータが含まれていることに注意が必要である。デバイス４の「id」は固有である必要がある。例えば、簡単に検索できるように、「id」はデバイス４の公開鍵「public_key」の暗号化されたハッシュ値にすることができる。「firmware_version」には、バージョン番号、ダイジェスト、ファームウェアをダウンロードするためのＵＲＬなどの情報が含まれている。

【0032】

トランザクションメッセージ「Tx_create」を作成して分散型台帳に公開すると、トランザクションメッセージの内容が台帳に保存される。このコンテキストでは、特定のユースケースで別のことが明記されていないことを除いて、「id、model_name、manufacturer、serial_number、public_key」の情報は、台帳では不変であるべきことに注意することが重要である。その他の情報は、後続のトランザクションメッセージを介して更新できる。

【0033】

例えば、デバイスのファームウェアが更新されると、それぞれのハードウェアベンダー２は、ファームウェア情報を更新するために、以下の数２のような新しいトランザクションメッセージを、分散型台帳に送信することができる。

【数2】

【0034】

さらに、デバイス４の公開鍵が無効とされると、それぞれのハードウェアベンダー２は、ステータスを「revoked」として更新するために、以下の数３のような新しいトランザクションメッセージを分散型台帳に送信することができる。

【数3】

【0035】

実施形態では、上記のトランザクションメッセージはまた、それぞれのハードウェアベンダー２の認証情報を運ぶ。この認証情報は、「Tx_create、Tx_upgrade、Tx_revoke」メッセージを受け入れるために、分散型台帳ネットワーク７のすべてのノード６によって検証できる。このコンテキストでは、それぞれのトランザクションメッセージが検証されるときに、アクセス制御アプローチが、トランザクションメッセージの送信者が認証され承認されることにより実行されうる。さらに、すべてのトランザクションメッセージを受け入れると、分散型台帳によってタイムスタンプが付与される場合がある。

【0036】

図１に示す実施形態では、明示的に示されていないサプライチェーンメンバーは、ハードウェアベンダー２とネットワークオペレーター３との間におけるデバイス４の輸送を行う。そのため、ハードウェアベンダー２とネットワークオペレーター３は、それぞれサプライチェーンの最初と最後のノードである。サプライチェーンのメンバーは、分散型台帳を介して、集荷して配送したデバイス４を通知することができる。

【0037】

一般的に、サプライチェーンメンバーが分散型台帳に発行するレコードは、デバイス４の出荷履歴を反映している。実施形態では、サプライチェーンメンバーは、以下のイベントの際に分散型台帳にレコードを発行する。

【0038】

１）デバイス４がハードウェアベンダー２またはネットワークオペレーター３から配送された場合：この場合、レコード（図１の下部に「tx₁」および「tx₃」として示されている）には、デバイス４の公開鍵と、ハードウェアベンダー２またはネットワークオペレーター3の識別情報が含まれる。
２）デバイスがネットワークオペレーター3によって受け取られた：この場合、レコード（図１では「tx₂」および「tx₄」として示されている）には、デバイス４の公開鍵と、受け取ったネットワークオペレーター３の識別情報が含まれる。

【0039】

上述したイベントとは異なるが、ハードウェアベンダー２の場合と同様に、サプライチェーンメンバーが台帳にレコードを発行するきっかけとなる他のイベントが想定される。

【0040】

より具体的には、デバイス４がサプライチェーンメンバーを介して出荷されると、以下の数４のようなトランザクションを介して、デバイス４のステータスは、受信者情報（すなわち、ネットワークオペレーター３）と共に「sipped」に更新される。

【数4】

【0041】

ネットワークオペレーター３は、新しいデバイス４を受け取ると、最初に、デバイス４の公開鍵（またはＩＤ）を取得するためのアクションを実行することができる。例えば、具体的な実装に応じて、ネットワークオペレーター３は、スキャンを実行してもよい。（例えばデバイス４のパッケージ上など、公開鍵が目に見えるように表示または示されている場合）。別の実施形態では、ネットワークオペレーター３は、分散型台帳からデバイス情報を照会してもよい。台帳からのデバイス情報が受け取ったパッケージの記載と一致している場合には、ネットワークオペレーター３は、トランザクションを台帳に送信して、デバイスのステータスを「received」に更新する。このトランザクションの形式は、数５に示すとおりである。

【数5】

【0042】

図１に示されるように、ネットワークオペレーター３は、ネットワークオペレーターＢおよびネットワークオペレーターＤについて、それら自身のネットワークドメイン７内でデバイス４を管理する責任がある。デバイス４をそれらのネットワークドメイン７に展開する前に、ネットワークオペレーター３は、それぞれのデバイス４（例えば、デバイスのＯＳ、ファームウェア、ＴＥＥ）に埋め込まれている秘密鍵が、例えばデバイス４の外面やデバイスのパッケージに視覚的に表示されるなど公然とアクセスできるデバイス４の公開鍵と一致することを検証する。実施形態では、この検証が失敗した場合、ネットワークオペレーター３は、デバイス４がネットワーク１，７に参加することを許可しない。他方、検証が成功した場合、ネットワークオペレーター３は、デバイス４がネットワーク１，７に参加することを許可することができる。

【0043】

より具体的には、図２に示すように、デバイス４を展開する前におけるネットワークオペレーター３によるデバイス４の検証は、以下のステップを含む。最初に、ネットワークオペレーター３は、デバイス４の公開鍵「ＰＫ」を取得し、ステップ２０１に示すように、デバイス４にチャレンジとしてランダムノンスを送信する。応答として、デバイス４は、ステップ２０２に示すように、チャレンジに対して署名「sig」、つまり、デバイス４の秘密鍵／セキュア鍵「SK」とノンスを返す。次に、ステップ２０３に示すように、デバイス４の公開鍵「PK」を使用して、ネットワークオペレーター３によって署名が検証される。

【0044】

どのような場合においても、すなわち検証が失敗したか成功したかに関係なく、ネットワークオペレーター３は、検証に関する情報を提供する新しいレコードを分散型台帳に発行する。このトランザクションレコードは、以下の数６のように実装されうる。

【数6】

【0045】

ネットワークオペレーター３がデバイス４を展開すると、ブロックチェーンが検証結果が肯定であることを確認した場合にのみ、ステータスを「deployed」に更新できる。

【数7】

【0046】

ネットワークオペレーター３は、ハードウェアベンダー２が無線で実行できないファームウェア更新を管理する場合もある。本発明の実施形態では、ネットワークオペレーター３は、それぞれのデバイス４がデバイス製造業者例えばそれぞれのハードウェアベンダー２によって分散型台帳に投稿された場合にのみ、ドメイン７内の特定のデバイス４を特定のファームウェアバージョンで更新する。ファームウェア更新処理の結果は、分散型台帳にレコードを発行することによって再度通知される場合がある。これにより、分散型台帳ネットワーク５のメンバーは、所定のデバイス４上で実行されているソフトウェア／ファームウェアのバージョンを認識することができる。デバイスファームウェア更新の結果を通知するトランザクションレコードは、以下の数８のように実装されうる。

【数8】

【0047】

図３に示すように、本発明の実施形態では、ネットワークオペレーター３は、デバイス４のファームウェアおよびソフトウェアの完全性を検証するために、そのドメイン７に属するデバイス４を認証するための認証サービス８を実行することができる。認証サービス８は、所定のまたは設定された間隔あるいはイベントベースのいずれかで、デバイス認証を実行するように構成される。

【0048】

図３に示すように、ネットワークオペレーター３は、認証タスクを認証サービス８に委託することができる（符号３０１に示すように）。委託時に、認証サービス８は、分散型台帳に連絡することによって、認証される各デバイス４の必要な情報、特にデバイス４のハードウェア性能に関する情報を取得することができる（符号３０２に示すように）。認証サービス８は、取得したデバイス情報に基づいて、それぞれのデバイス４を定期的に認証または指紋認証する（符号３０３に示すように）。認証サービス８は、異なるタイプのＴＥＥまたはスマートカードに対応するように構成される。各認証の結果は、分散型台帳にレコードを発行することによって通知される。

【0049】

一般的に、認証サービス８は、デバイス４のハードウェアセキュリティ性能と共にデバイスタイプを確認し、基礎となるハードウェアの性能に応じて、認証サービス８は以下の処理を実行する。
－ デバイス４のハードウェアが、Intel SGX（Software Guard Extensions）をサポートしている場合は、SGX認証を開始する。
－ デバイス４のハードウェアが、Trustzoneをサポートしている場合は、Trustzone認証を開始する。
－ デバイス４のハードウェアがRISC-Vの場合（参考に、https：//riscv.org/faqを参照）、特定のハードウェア認証を開始する。
－ デバイス４のハードウェアがTPM（Trusted Platform Module）チップを有する場合、TPM認証を開始する。
－ スマートカードまたはSIMカードがある場合、スマートカードベースの認証を開始する（例えば、US2016/0132681A1に記載されている認証手順に従って行われ、この公報の全ての開示事項は参照により本明細書に組み込まれるものとする）。
－ デバイス４が安全なハードウェアサポートを有していない場合、疑似ランダムメモリトラバーサルに基づいてソフトウェア認証を実行する。
－ デバイス４のハードウェアに読み取り専用メモリ（ROM）がある場合、デバイス４のファームウェアの更新は、SUANTセキュアコードアップデートを介して実行できる（参考：US10,346,619B2、及び、「G. Karame and W. Li, "Secure erasure and code update in legacy sensors", Trust and Trustworthy Computing - 8th International Conference, TRUST 2015, Proceedings, Springer Verlag, vol9229, p283-299」、両方の文献の全ての開示事項は参照により本明細書に組み込まれるものとする）。

【0050】

上記のオプションのいずれも利用できない場合、認証サービス８は、ソフトウェアベースの認証を開始することができる。このオプションが実行可能でない場合、認証サービス８は、デバイスの無線指紋認証を実行する可能性がある（例えば、「K. B. Rasmussen及びS.Capkun, "Implications of radio fingerprinting on the security of sensor networks", 2007 Third International Conference on Security and Privacy in Communications Networks and the Workshops - SecureComm 2007」に記載のように実行する。この文献の全ての開示事項は参照により本明細書に組み込まれるものとする）。

【0051】

図４は、ＴＥＥ９を有するデバイス４のコンテキストにおける認証プロトコルの実施形態を示している。デバイス４が起動すると、コンポーネントは、それぞれの下位レベルがロード前にそれぞれの上位レベルの完全性を測定するような順序でロードされる。具体的には、図４に示すように、起動プロセス中に、ブートローダー１０は、カーネル１１の完全性を測定し、カーネル１１はＯＳ１２の完全性を測定し、ＯＳ１２はそれぞれのアプリケーション１３の完全性を測定する。

【0052】

測定結果は、デバイスのＴＥＥ９のＴＣＢ１４（Trusted Computing Base）のセキュアストレージに保存される。図４に示されるように、ストレージは、以下の数９のように、ＴＥＥアプリケーション１５を介して拡張方式で実行される。

【数9】

ここで、Hは暗号化ハッシュ関数、h_iはコンポーネントiの測定値、M_iはコンポーネントiを使用した拡張測定値である。

【0053】

次に、認証プロセス中に、ネットワークオペレーター３は、まず、ＴＥＥアプリケーション１５を用いてセキュアチャネル１６を確立する。これに関連して、ＴＥＥアプリケーション１５は、ネットワークオペレーター３の公開鍵のリスト１７をハードコーディングしているため、ＴＥＥアプリケーション１５は、ネットワークオペレーター３を認証でき、例えば、Diffie-Hellman鍵共有で共有鍵K_sharedを取得することができることに留意されたい。認証プロセスでは、完全性のみを保証する必要があり、必ずしも機密性を保証する必要はない。

【0054】

セキュアチャネル１６が確立された後、ネットワークオペレーター３は、ＴＥＥ９にノンスをチャレンジし、応答としてのQuoteを待つ。Quoteには、起動シーケンス中に記録されたロードされたコンポーネントの測定結果、ノンス、これらの情報に対する署名、が含まれる。Quoteは、ＴＣＢ１４内のデバイスごとの認証鍵SK_attestで署名されている。この認証鍵は、ＴＥＥアプリケーション１５による認証Quoteに署名するためにのみ使用される。この状況では、認証鍵SK_attestは、デバイス認証またはその他のアプリケーション目的で使用されるアプリケーションごとの秘密鍵SKとは異なることに注意が必要である。

【0055】

次に、返されたQuoteは、図４に示すように、ネットワークオペレーター３自体によって、あるいは、信頼できる第三者によってリモートで、ホストされる認証サービス８により転送および検証される。次に、ネットワークオペレーター３は、認証結果をチェックし、本発明の実施形態におけるブロックチェーンに以下の数１０のようなメッセージを発行することによって、それを分散型台帳に公開する。

【数10】

ＴＥＥ情報には、ＴＥＥ９のタイプとＴＥＥ９のバージョンが含まれる。

【0056】

デバイス４がＴＥＥ９を備えていない場合、ネットワークオペレーター３は、図５に示すように、疑似ランダムメモリトラバーサルに基づいてソフトウェア認証を実行することができる。実施形態では、ネットワークオペレーター３（またはオペレータの認証サービス８）は、チャレンジとしてノンスをデバイス４に送信する。デバイス４は、ノンスに基づいて記憶場所を繰り返し導出し、チェックサムを更新するために使用されるメモリ内容を読み取る。繰り返しの最後に、チェックサムは検証のためにネットワークオペレーター３に送り返される。次に、ネットワークオペレーター３は、受信したチェックサムをデバイス４の推定メモリ内容で検証する。記憶場所を導出する関数も、推定擬似ランダム関数F_RNG：数１１であることに注意が必要である。ここで、m_iは記憶場所であり、m₀=nonceである。

【数11】

【0057】

実施形態では、ネットワークオペレーター３はまた、デバイス４からの応答時間（チャレンジ開始時間t_sと応答終了時間t_e）をチェックする。応答時間が長すぎる場合、つまり数１２が事前定義された閾値を超える場合には、ネットワークオペレーター３は、デバイス４の完全性を疑うように構成されている。

【数12】

【0058】

いずれの場合も、認証結果は以下の数１３のようにブロックチェーンに更新されうる。

【数13】

【0059】

上記のアプローチのいずれも適用できない場合、ネットワークオペレーター３は、デバイス無線指紋認証を実行して、デバイス４のモデルが所定のデバイスモデルから発せられた信号のプロファイルと一致するかどうかを検証することができる。指紋認証の結果は、以下の数１４のようなトランザクションを介して更新されうる。

【数14】

【0060】

特定の認証手順が実際に実装されているかに関係なく、認証結果はブロックチェーンに保存される場合がある。ソフトウェア認証の場合、ソフトウェアの現在の状態を、ブロックチェーンまたはクラウドバックエンドストレージのいずれかに保存されているソフトウェアのホワイトリストと比較できる。

【0061】

本発明の実施形態によれば、ネットワークオペレーター３は、分散型台帳で利用可能なそれぞれのデバイス４に関する情報に応じて、デバイス４への接続を提供するかどうかを決定することができる。これには、デバイスの信用性を判断するために、分散型台帳を介して複数の利害関係者によって維持されているデバイス情報を取得するリスク評価サービスの設定が含まれる場合がある。実施形態では、ネットワークオペレーター３は、デバイス公開鍵、出荷履歴、認証結果、ファームウェアバージョンなどを含む関連するデバイス情報を分散型台帳から読み出し、設定されたリスク評価ルールに従って読み出した情報を分析するように構成されたリスク評価モジュールを備えることができる。デバイス４がリスク評価に合格した場合、ネットワークオペレーター３はデバイス４への接続を申し出て、そうでない場合は、ネットワークオペレーター３は、例えば、デバイス４から受信したそれぞれの要求を拒否することにより、接続を申し出ない。

【0062】

本発明の多くの変形例および実施形態は、上述した説明および関連する図面に記載された教示により、本発明が関係する当業者には思い浮かぶであろう。したがって、本発明は、開示された特定の実施形態に限定されるものではなく、変形例および実施形態は添付の特許請求の範囲内に含まれることが意図されていることを理解されたい。本明細書では特定の用語が使用されているが、それらは一般的かつ説明的な意味でのみ使用されており、限定の目的では使用されていない。

【符号の説明】

【0063】

１ モバイル通信ネットワーク
２ ハードウェアベンダー
３ ネットワークオペレーター
３ａ クラウドネットワークサービスプロバイダー
４ ネットワークデバイス
５ 分散型台帳ネットワーク
６ 分散型台帳ネットワーク内のノード
７ 管理ドメイン
８ 認証サービス
９ Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ（TEE）
１０ ブートローダー
１１ カーネル
１２ オペレーティングシステム（ＯＳ）
１３ アプリケーション
１４ Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｂａｓｅ （ＴＣＢ）
１５ ＴＥＥアプリケーション
１６ セキュアチャネル
１７ ネットワークオペレーターの公開鍵のリスト
１８ 設定データベース

【図1】

【図2】

【図3】

【図4】

【図5】