特表 2024-542109 デバイスの認証

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

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

(11)【公表番号】

(43)【公表日】2024-11-13

(54)【発明の名称】デバイスの認証

(51)【国際特許分類】

   H04L 9/32 20060101AFI20241106BHJP

   G06F 21/44 20130101ALI20241106BHJP

【ＦＩ】

H04L9/32 200B

G06F21/44

H04L9/32 200F

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2024526650

(86)(22)【出願日】2022-10-17

(85)【翻訳文提出日】2024-06-04

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

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

(87)【国際公開日】2023-05-11

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

(32)【優先日】2021-11-03

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

(81)【指定国・地域】

(71)【出願人】

【識別番号】523382100

【氏名又は名称】ダブコ・リミテッド

【氏名又は名称原語表記】ＤＡＢＣＯ ＬＩＭＩＴＥＤ

(74)【代理人】

【識別番号】110001195

【氏名又は名称】弁理士法人深見特許事務所

(72)【発明者】

【氏名】ポシュケ，ニルス

(57)【要約】

分散台帳のノードにおいて、デバイスから認証要求を受信することを含み、認証要求は、認証方法の１つまたは複数の工程を示すデータを含む、デバイスを認証するための方法およびシステム。分散台帳の複数のノードにわたってデバイスを認証し、複数のノードの各々は、デバイスから受信したデータによって示される１つまたは複数の工程に従う。

【特許請求の範囲】

【請求項1】

デバイスを認証するための方法であって、
分散台帳のノードにおいて、前記デバイスから、認証方法の１つまたは複数の工程を示すデータを含む認証要求を受信する工程と、
前記分散台帳の複数のノードにわたって前記デバイスを認証する工程であって、前記複数のノードの各々は、前記デバイスから受信した前記データによって示される前記１つまたは複数の工程に従う、認証する工程と、を含む、方法。

【請求項2】

前記要求は資格情報をさらに含み、前記分散台帳の前記複数のノードにわたって前記デバイスを認証する前記工程は、前記資格情報を認証することをさらに含む、請求項１に記載の方法。

【請求項3】

前記複数のノードのうちの２つ以上のノードが、前記デバイスから受信した前記データによって示される前記１つまたは複数の工程に従って前記デバイスを認証しない限り、前記デバイスの認証は失敗する、請求項１または２に記載の方法。

【請求項4】

前記認証に関与する前記複数のノードの過半数が前記デバイスを認証しない限り、前記デバイスの認証は失敗する、先行する請求項のいずれかに記載の方法。

【請求項5】

認証方法の１つまたは複数の工程を示す前記データは、前記要求のヘッダに含まれる、先行する請求項のいずれかに記載の方法。

【請求項6】

認証方法の１つまたは複数の工程が、複数の認証プロトコルのうちの１つの認証プロトコルを示す、先行する請求項のいずれかに記載の方法。

【請求項7】

前記複数の認証プロトコルは、対称暗号化；非対称暗号化；公開鍵インフラストラクチャ（PKI：public key infrastructure）；SIM Trust；IoT SAFE；TLS；DTLS；および汎用ブートストラッピング・アーキテクチャ（GBA：Generic Bootstrapping Architecture）を含む、請求項６に記載の方法。

【請求項8】

前記デバイスが、選択された認証方法の前記１つまたは複数の工程を示すデータを含む前記要求を生成する前に、前記デバイスが利用可能な複数の認証方法から前記認証方法を選択する工程をさらに含む、先行する請求項のいずれかに記載の方法。

【請求項9】

認証システムであって、
１つまたは複数のデバイスであって、前記１つまたは複数のデバイスの各々は、認証要求を生成するように構成され、前記認証要求は、認証方法の１つまたは複数の工程を示すデータを含む、１つまたは複数のデバイスと、
複数のノードを有する分散台帳であって、前記複数のノードの各々は、
前記デバイスのうちの１つから、前記認証方法の前記１つまたは複数の工程を示す認証要求を受信し、
前記デバイスから受信した前記データによって指示される前記１つまたは複数の工程に従って前記デバイスを認証するように構成されている、複数のノードを有する分散台帳と、を備える認証システム。

【請求項10】

前記１つまたは複数のデバイスのうちの別のデバイスは、前記認証方法の前記１つまたは複数の工程とは異なる第２の認証方法の別の１つまたは複数の工程を示す別の認証要求を生成するように構成されている、請求項９に記載の認証システム。

【請求項11】

前記複数のノードのうちの２つ以上のノードが、前記デバイスから受信した前記データによって示される前記１つまたは複数の工程に従って前記デバイスを認証しない限り、前記デバイスの認証は失敗する、請求項９または請求項１０に記載の認証システム。

【請求項12】

前記１つまたは複数のデバイスの各々は、選択された認証方法の前記１つまたは複数の工程を示すデータを含む前記要求を生成する前に、前記デバイスが利用可能な複数の認証方法から前記認証方法を選択するようにさらに構成されている、請求項９～１１のいずれかに記載の認証システム。

【請求項13】

前記１つまたは複数のデバイスの各々は、別の認証要求で使用するための新しい認証方法を定義するデータを受信するようにさらに構成されている、請求項９～１２のいずれかに記載の認証システム。

【請求項14】

元の認証方法および／または新しい認証方法は有効期限を有する、請求項１３に記載の認証システム。

【請求項15】

前記１つまたは複数のデバイスは、前記要求を保護するように構成されたUICCまたはSIMをさらに備える、請求項９～１４のいずれかに記載の認証システム。

【発明の詳細な説明】

【技術分野】

【0001】

発明の分野
本発明は、デバイスを認証するための、特にブロックチェーン技術を使用する分散システム内の認証デバイスのためのシステムおよび方法に関する。

【背景技術】

【0002】

発明の背景
価値を交換するために、または他の目的のために、異なるエンティティが互いに相互作用し、取引することが一般的に必要とされている。しかしながら、これが取引の各当事者にとって安全かつセキュアな方法で行われるためには、取引エンティティ間に信頼のレベルが存在する必要がある。そのような信頼がない場合、強制可能な契約および第三者機関または仲介者などの他の構造および手順が必要である。

【0003】

異なるエンティティ間のセキュアな認証は、これがなければ遠隔または無関係である当事者間の安全な相互作用を可能にする。例えば、SIMは、発行局に知られている個々の鍵で事前にロードされてもよい。発行局は、これらの個々の（対称）鍵をSIMの所有者と安全に共有することができる。SIMはこれらの鍵をコピーすることを可能にしないため、特定のSIMを有するデバイスが所有者（または所有者の制御下にあるシステム）と通信するとき、所有者はデバイスのアイデンティティを確実にすることができ、セキュアな通信を確立することができる。このシステムは、物理的なSIMをデバイスに分散させることが簡便かつ効率的である場合に、電気通信通信において効果的である。

【0004】

セキュアな通信を必要とする短期間の相互作用では、認証局のような信頼できる仲介者を使用して鍵素材を共有および検証することができる。しかしながら、これはそのような信頼できる仲介者の確立を必要とし、これは常に効率的または望ましいとは限らず、レイテンシを導入する可能性もある。

【0005】

さらに、異なるセキュリティおよび認証機能を有する異なるデバイスタイプは、異なる目的のために様々なエンティティから認証される必要があり得る。これにより、システムの複雑さが増したり、セキュリティを備える必要が生じたりする可能性がある。

【0006】

したがって、これらの問題を克服する方法およびシステムが必要とされている。

【発明の概要】

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

【0007】

発明の概要
モバイルデバイス、低電力商品または他の構成要素などのデバイスは、異なる認証プロトコルおよび方法にアクセスすることができ、これらを可能にすることができる。個々のデバイスは、複数の認証方法を使用する能力を有してもよく、または単一の方法に限定されてもよい。いくつかの例示的な実装形態では、デバイスは異なる認証方法で更新することができ、または特定の利用可能な認証方法は異なる時間に非アクティブ化およびアクティブ化することができる。デバイスが特定のシステムまたはサービスからの認証を必要とする場合、デバイスは認証要求を生成する。要求は、使用される特定の認証方法を定義または記述する情報またはデータを含む。異なるデバイスは、異なる認証方法を用いて（または認証方法の１つまたは複数の工程を定義して）要求を生成することができる。

【0008】

分散台帳（または分散台帳の単一ノード）は、１つまたは複数のデバイスからこれらの要求を受信する。要求は、使用する認証方法または工程を識別または記述する情報を含むので、異なる認証方法が可能なデバイスからそのような要求を受信することができる。分散台帳のノードは、各要求で説明または参照される認証方法を使用してデバイスを認証しようと試みる。好ましくは、認証方法の詳細を含むかまたは認証方法を識別する要求はまた、認証方法に従ってデバイスを認証するために使用される資格情報または暗号材料を含む。有利には、認証方法を記述または識別する情報は、要求のヘッダに含まれ、暗号材料は、要求のペイロードまたはボディ内に含まれるが、他のフォーマットを使用することもできる。

【0009】

各デバイスは、事前に登録されてもよいし、登録されずに認証の要求を発行してもよい。しかしながら、事前に登録することにより、要求を処理するための高度な準備を行うことができるため、追加のパフォーマンスおよびセキュリティ強化を提供することができる。

【0010】

第１の態様によれば、デバイスを認証するための方法が提供され、本方法は、
分散台帳のノードにおいて、デバイスから、認証方法の１つまたは複数の工程を示すデータを含む認証要求を受信する工程と、
分散台帳の複数のノードにわたってデバイスを認証する工程であって、複数のノードの各々は、デバイスから受信したデータによって示される１つまたは複数の工程に従う、認証する工程と、を含む。したがって、異なる認証プロトコルを使用する異なるデバイスの認証を処理し、同じ分散台帳を使用して認証することができる。したがって、異なる認証方法を使用する異なるデバイスは、同じ１つまたは複数のシステムでより容易に認証することができる。

【0011】

好ましくは、要求は資格情報をさらに含むことができ、分散台帳の複数のノードにわたってデバイスを認証する工程は、資格情報を認証することをさらに含むことができる。例えば、要求内のペイロードは、デバイス（またはデバイスのUICCまたはSIM）のみが知っている秘密鍵で署名することができる。別の例では、要求は、対称鍵で暗号化されたトークンを含むことができる。これにより、分散台帳のノードによって実行される認証のためのシードを提供することができる。

【0012】

任意選択で、デバイスの認証は、複数のノードのうちの２つ以上のノードが、デバイスから受信したデータによって示される１つまたは複数の工程に従ってデバイスを認証しない限り、失敗し得る。したがって、２つ以上のノードが認証を正常に確認しなければならないため、セキュリティを高めることができる。

【0013】

任意選択で、デバイスの認証は、認証に関与する複数のノードの過半数がデバイスを認証しない限り、失敗し得る。したがって、２つ以上のノードが認証を確認しなければならないため、セキュリティを高めることができる。認証に関与するノードのうちの少数は、様々な理由（例えば、完了できない、タイムアウトなど）で認証に失敗する可能性があり、認証は、ノードの過半数が認証を完了することで成功する可能性がある。

【0014】

好ましくは、認証方法の１つまたは複数の工程を示すデータは、要求のヘッダに含まれてもよい。要求は、例えば、認証方法の詳細を含むヘッダと、ノードによって実行される認証で使用される資格情報または他の暗号材料を含むペイロードとを含むことができる。

【0015】

任意選択で、認証方法の１つまたは複数の工程の指示は、複数の可能なまたは代替の認証プロトコルのうちの１つの認証プロトコルを示す。例えば、この指示は、使用する特定の認証方法の識別子を含むことができる。デバイスが利用可能ないくつかの異なる認証プロトコルが存在する場合があり、データは、特定の認証にどの認証プロトコルを使用するかを要求内で示す。デバイスは、単一の認証方法を使用してのみ認証できる場合がある。ここでも、データは、そのデバイスで使用する特定の認証方法を示すことができる。異なるデバイスまたはデバイスのグループは、異なる認証方法を使用し得る。

【0016】

任意選択で、複数の認証プロトコルは、対称暗号化；非対称暗号化；公開鍵インフラストラクチャ（PKI：public key infrastructure）；SIM Trust；IoT SAFE；TLS；DTLS；および汎用ブートストラッピング・アーキテクチャ（GBA：Generic Bootstrapping Architecture）を含むことができる。他の認証方法またはプロトコルが使用されてもよい。

【0017】

任意選択的に、本方法は、デバイスが、選択された認証方法の１つまたは複数の工程を示すデータを含む要求を生成する前に、デバイスが利用可能な複数の認証方法から認証方法を選択する工程をさらに含むことができる。したがって、デバイスは、特定のシステムまたは目的ごとにどの認証方法を使用するかを制御することができる。デバイスは、異なる状況下で、または異なるシステムで使用するために、特定の認証方法を使用する命令を事前に受信することができる。

【0018】

第２の態様によれば、認証システムが提供され、認証システムは、
１つまたは複数のデバイスであって、１つまたは複数のデバイスの各々は、認証要求を生成するように構成され、認証要求は、認証方法の１つまたは複数の工程を示すデータを含む、１つまたは複数のデバイスと、
複数のノードを有する分散台帳であって、複数のノードの各々は、
デバイスのうちの１つから、認証方法の１つまたは複数の工程を示す認証要求を受信し、
デバイスから受信したデータによって指示される１つまたは複数の工程に従ってデバイスを認証するように構成されている、複数のノードを有する分散台帳と、を備える。

【0019】

有利には、１つまたは複数のデバイスのうちの別のデバイスは、認証方法の１つまたは複数の工程とは異なる第２の認証方法の別の１つまたは複数の工程を示す別の認証要求を生成するように構成され得る。したがって、任意の数の異なるデバイス（またはデバイス、または異なるもしくは同じタイプ）は各々、同じ分散台帳で異なる認証方法を使用することができる。

【0020】

任意選択で、デバイスの認証は、複数のノードのうちの２つ以上のノードが、デバイスから受信したデータによって示される１つまたは複数の工程に従ってデバイスを認証しない限り、失敗し得る。

【0021】

任意選択で、１つまたは複数のデバイスの各々は、選択された認証方法の１つまたは複数の工程を示すデータを含む要求を生成する前に、デバイスが利用可能な複数の認証方法から認証方法を選択するようにさらに構成されてもよい。

【0022】

有利には、１つまたは複数のデバイスの各々は、別の認証要求で使用するための新しい認証方法を定義するデータを受信するようにさらに構成されてもよい。したがって、デバイスは、使用する１つまたは複数の認証方法（または方法工程）を変更することができる。これは柔軟性を追加し、制限された再構成でデバイスが新しいまたは改善された認証方法で動作し続けることを可能にする。新しい認証方法定義は、例えば、分散台帳の１つまたは複数のノードから、または別のエンティティまたはサーバから受信することができる。

【0023】

好ましくは、元の認証方法および／または新しい認証方法は有効期限を有することができる。したがって、認証方法を定期的に、または所定のもしくは構成された期間の後にリフレッシュすることによって、セキュリティを向上させることができる。

【0024】

好ましくは、１つまたは複数のデバイスは、要求を保護するように構成されたUICCまたはSIMをさらに備える。あるいは、他の技術を使用して、要求を保護し、および／または定義された認証方法によって使用される暗号材料を生成することができる。

【0025】

第３の態様によれば、登録の工程と上述した認証方法のいずれかまたはすべての工程を組み込んだ認証方法およびシステムが提供される。登録は、デバイスまたはデバイスの属性から、どの１つまたは複数の認証方法が可能であるかを決定することと、デバイスが要求（認証方法の１つまたは複数の工程を示すデータを含む）を生成するためにこの情報を使用することを可能にすることと、を含むことができる。

【0026】

上述の方法は、コンピュータを動作させるためのプログラム命令を含むコンピュータプログラムとして実施することができる。コンピュータプログラムは、コンピュータ可読媒体に記憶されてもよい。

【0027】

コンピュータシステムは、中央処理装置（CPU：Central Processing unit）などの１つまたは複数のプロセッサ（例えば、ローカル、仮想、またはクラウドベース）、および／または単一もしくは集合のグラフィックス処理装置（GPU：Graphics Processing Units）を含むことができる。プロセッサは、ソフトウェアプログラムの形態の論理を実行することができる。コンピュータシステムは、揮発性および不揮発性記憶媒体を含むメモリを含むことができる。論理またはプログラム命令を記憶するためにコンピュータ可読媒体が含まれてもよい。システムの異なる部分は、ネットワーク（例えば、無線ネットワークおよび有線ネットワーク）を使用して接続されてもよい。コンピュータシステムは、１つまたは複数のインターフェースを含むことができる。コンピュータシステムは、例えば、UNIX（登録商標）、Windows（RTM）またはLinux（登録商標）などの適切なオペレーティングシステムを含むことができる。

【0028】

上記の任意の特徴は、本発明の任意の特定の態様または実施形態で使用され得ることに留意されたい。

【0029】

図面の簡単な説明
本開示は、いくつかの方法で実施することができ、ここで、添付の図面を参照して、単なる例として実施形態を説明する。

【図面の簡単な説明】

【0030】

【図1】デバイスを認証するための方法のフローチャートを示す。

【図2】図１の認証方法で使用する１つまたは複数のデバイスを登録するためのシステムおよびデータフローの概略図を示す。

【図3】認証要求を含む、１つまたは複数のデバイスを認証するためのシステムおよびデータフローの概略図を示す。

【図4】図４の認証要求の概略図を示す。

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

【0031】

図面は簡略化のために示されており、必ずしも縮尺通りに描かれていないことに留意されたい。同様の特徴には同じ参照番号が付されている。

【0032】

好ましい実施形態の詳細な説明
「モノのインターネット」は成長しており、「モノの経済」（EoT：Economy of Things）に移行している。IoTデバイスの数は増加しており、大量のデータを生成している。IoTデバイスおよびスマートサービスは、所有権ドメインにわたって相互作用および相互運用し、データおよびスマートサービス価値取引をほぼリアルタイムで自動的にサポートする可能性を提供する。これにより、相互運用性および機能性を向上させることができる。

【0033】

「モノの経済」は、デバイス／サービスが互いに識別し、信頼し、必要に応じて直接またはピアツーピア機能を使用して自動的に価値を取引する能力を必要とする。デジタルID、連合セキュリティ、ならびにIoTに必要な取引アプリケーションおよびサービスをサポートする分散台帳、セキュアエレメント、暗号およびデバイスウォレットに及ぶ様々な技術があるが、それらは断片化されており、コストが高く、十分にスケーラブルではない。

【0034】

分散台帳などの分散暗号通貨の基礎となる技術は、他のタイプの取引を記録するために使用することもでき、エンティティ間に信頼が存在することを必要とせずに、交換または他の形態のデータの検証可能な履歴を形成することができる。ブロックチェーンなどの分散台帳は、信頼がない場合に取引、価値の交換および検証可能なイベント記録を行うことを可能にする。これには、個々の当事者またはエンティティによる破壊または制御が困難な分散台帳のノード間のコンセンサスを形成するためのブロックチェーンの使用が必要である。これは、通常、プルーフオブワークに基づくコンセンサス競争という形をとる。

【0035】

個々のデバイスは、異なるシステムおよび異なる理由で認証を必要とする。これらのシステムは、電気通信システム、サービスプロバイダ、コンピュータネットワークまたは他のタイプを含むことができる。デバイスはまた、サービスにアクセスするために分散ネットワークからの認証を必要とし得る。システムは、分散システムを使用してサービスを提供することができる。有利には、サービスを提供する同じ分散システムはまた、個々のデバイスの認証を実行することができる。分散台帳を使用してデバイスを認証することにより、認証局（CA：certificate authority）などの信頼できるエンティティに対する要件がなくなる。これは、デバイスの認証が成功する前に、分散システムの複数のノード（例えば、分散台帳）が必要になる可能性があるためである。例えば、デバイスの認証は、２つ以上のノードまたは過半数のノードの各々がデバイスを個別に認証するまで行われない。これにより、単一の認証局が破損するリスクが大幅に低減される。

【0036】

異なるデバイスが異なるセキュリティプロトコルまたは認証方法を使用できるようにするために、認証の要求として各デバイスから受信される情報またはデータは、認証方法の１つまたは複数の工程を示すデータを含む。これは、要求の暗号ヘッダ内に含まれてもよく、要求はまた、指定された認証方法を使用してデバイスIDを認証するための情報を含んでもよい。この暗号ヘッダは、暗号化ノンス、例えば、デバイスのみが知っている秘密鍵で署名されたトークン、または分散台帳と共有される対称鍵で暗号化されたトークンを含むことができる。

【0037】

図１は、このシステムを使用してデバイスの認証を実行するための方法１０のフローチャートを示す。工程２０において、デバイスは認証要求を生成する。これは、最初の電源投入時または別の時点であってもよい。要求には、認証方法（例えば、認証方法のレシピ）を含む、記述する、あるいは定義または識別するデータまたは情報が含まれる。

【0038】

デバイスはこの要求をシステム（例えば、分散台帳のノード）に送信する。これは、デバイスとノードとの間の直接通信であっても、間接ルートを介した（例えば、電気通信ネットワークを介した）通信であってもよい。工程３０において、分散台帳のノードは、デバイスから要求を受信する。

【0039】

要求は、分散台帳の１つまたは複数の他のノードに分散される。この要求を受信したノードは、要求内のデータによって定義された特定の認証方法を使用してデバイスを認証しようと試みる。ノードは、特定の認証方法（例えば、特定のセキュリティプロトコル）に既にアクセスしていてもよいし、ノードが特定の要求された認証方法を実行することを可能にするソフトウェアまたはパラメータを受信してもよい。これは、例えば、要求内の認証工程を示すデータに基づいて、異なるエンティティから受信されてもよい。

【0040】

デバイスの認証は、定義された認証方法または方法工程に従ってデバイスを正常に認証するために、ノードのうちの少なくとも２つを必要とする。特定の例示的な実装形態では、全体的な認証が成功するためには、最小数のノードがデバイスを認証しなければならない。他の例では、ノードの過半数は、デバイス認証が成功するためにデバイスを認証しなければならない。要求はそのような基準を定義することができ、またはこれは予め決定されていてもよい（または顧客バックエンドによって設定されていてもよい）。したがって、要求に応じてセキュリティを強化することができる。成功は、ブロックチェーンにブロックを追加するプロセスによって示すことができ、このブロックチェーンは、分散台帳のノード全体にわたって最終的な次のブロックになる。例えば、成功を示すブロックが追加されると、サービスが提供されてもよい。

【0041】

この例示的な実装形態では、工程５０は、同じ分散ネットワーク内（すなわち、ノード間）の認証の結果（成功または失敗）を格納する。他の例では、デバイス認証の成功は、他の形態（例えば、特定のサービスが提供される）をとることができる。

【0042】

したがって、システム（分散台帳を含む）は、「サービスとしての認証」を提供することができる。各デバイスは、最初の電源投入時または別の時に、分散台帳（または分散台帳の少なくとも１つのノード）での登録要求をトリガするソフトウェア開発キット（SDK：software development kit）をインストールすることができる。図２は、方法１０を使用または実行することを可能にするためにデバイスを登録または設定するために使用されるシステム１００内のデータフローを示す。

【0043】

デバイスを登録することは、デバイスの属性、およびデバイスが利用できる認証方法（またはそれが可能なもの）を決定することを含むことができる。登録プロセスはまた、デバイスのハードウェア（例えば、モデム、SIM、ハードウェアセキュリティモジュールなど）の説明を含むことができる。したがって、登録は、（将来使用される）認証方法の詳細をデバイスに追加することができる。この特定の認証方法（または方法に含まれる工程）は、デバイス属性（例えば、ハードウェア）に基づくことができる。登録に続いて、デバイスは、この特定の認証方法を定義するデータを含む将来の認証要求を生成することができる。言い換えれば、事前登録は、デバイスがこれらの方法自体を決定する必要なしに、可能な認証方法の要求をデバイスが送出することを可能にする。これは、新しい認証方法が定義され展開される場合に有用であり得る。デバイスの再登録は、新しい認証方法を便利に取得または有効にすることができる。

【0044】

例えば、デバイスがシステムまたはシステムの特定のサービスに登録するとき、デバイスの属性を決定することができる。これは、その特定の属性を含む登録の要求を発行するデバイスで明示的であってもよく、またはこれらは登録の要求から推測されてもよい。要求は、SIMの存在を意味する形式をとることができ、要求の通信フォーマットは、SIMに特定のSDK（または他の処理ロジック）がインストールされていることを示すことができる。

【0045】

デバイス１１０は、異なるセキュリティ機能のうちの任意の１つまたは複数を有することができる。図２は、SIM（またはUICC）ならびにIoT SAFEおよびSIM Trust機能を有するデバイス１１０を示す。しかしながら、デバイスは、これらの機能のいずれか、両方を有していてもよく、または何も有していなくてもよい。IoT SAFEは、エンドツーエンドのセキュアな通信を提供するためにSIMアプレットを使用するセキュリティ技術の一例である。IoT SAFEは、SIMに格納された事前共有鍵を使用してGSMA規格に従って定義された動作を実行することができる。SIM Trustは、３GPP（登録商標）汎用ブートストラップアーキテクチャ（GBA：Generic Bootstrapping Architecture）に基づいており、必要に応じて新しい鍵をプロビジョニングすることができる。セキュリティアーキテクチャのいずれかまたは両方を特定のデバイスで使用することができる。

【0046】

SIM（およびそれと共にデバイス）に一意かつ不変のアイデンティティを提供するために、SIM上のセキュア要素（標準化されたインターフェースを有し、IoT SAFE規格に従って定義された動作を実行することができる－GSMA）を使用して、HSM（SIM上のPKI）内に非対称鍵の１つまたは複数のセットを作成することができる。

【0047】

IoT SAFEはまた、デバイスとIoTバックエンドとの間にセキュアチャネル（（D）TLS）を作成するために使用され得る。これは、（D）TLS接続に必要な非対称鍵を保持するためにSIM上のセキュア要素を使用するが、これらの鍵は他の目的に使用されてもよい。

【0048】

高レベルでは、これらの２つの機構の主な違いは暗号手法にある。IoT SAFEアプレットは、主に非対称暗号化（公開鍵基盤、PKI：Public Key Infrastructureとも呼ばれる）のためにSIM上のセキュア要素を使用して鍵を格納および管理し、公開鍵と秘密鍵のペアが生成および格納される。GBA（例えば、SIM Trust）手法では、SIMとエンドポイント（例えば、DABサーバなどのサーバ）との間の対称暗号化を確立するためにモバイルネットワーク機能が使用される。

【0049】

非対称暗号化またはPKIは、公開／秘密鍵ペアを使用してhttpsおよびサーバ間の他の接続を保護するために多くのITインフラストラクチャによって使用される技術である。デバイスが（デバイスからの）要求に応じて様々なシステムで認証するために使用できるのは、これらの暗号材料である。

【0050】

分散台帳１２０は、工程１で要求（この例では「デバイスの登録」）を受信するものとして図２に示されている。分散台帳１２０の内部（例えば、分散台帳１２０の１つまたは複数のノードのSDK内）では、デバイスによってどの特定の認証方法が使用およびサポートされ得るかが検出される。これは、登録の要求内の明示的な定義から導出されてもよく、またはデバイス（例えば、デバイスタイプ）、モデム、SIM（例えば、識別子またはタイプ）、および任意の他のハードウェアまたは属性の組み合わせから決定されてもよい。しかしながら、この情報はまた、受信した要求から決定されてもよい。

【0051】

例えば、以下のシナリオが、登録の要求からノードによって遭遇され、決定され得る。
１）デバイス１１０が（SIM上のセキュア要素にPKIを提供する）IoT SAFEアプレットを備えたSIMを搬送する場合、このデバイスに対して選択される認証方法または方法工程は「IoT SAFE」である。

【0052】

２）デバイスおよびモデムおよびSIMがIoT SIM Trust APNにアクセスできるが、SIMがIoT SAFE SIMアプレットを搬送しない場合、認証方法または方法工程「SIM Trust」が選択される。

【0053】

３）SIMが利用できない（または存在しない）場合、デバイスはハードウェア（HW：hardware）セキュア要素または他のセキュア機構を運ぶ必要がある。この場合、認証方法は「SIMなしのセキュア要素」と決定される。

【0054】

４）将来の認証方法は、例えば、（PCRFのような）ネットワーク認証に基づきうる。
この検出または決定フェーズの間、分散台帳１２０の各ノード内のSDK（または他の処理ロジック）は、それ自体を自動的に構成し、選択された認証方法を使用して暗号情報を生成する（例えば、上記の例１のSIM上のPKIから公開鍵を抽出する）。２つ以上の認証方法が利用可能である（例えば、デバイスはIoT SAFEおよびSIM Trustにアクセスできる）場合、ノードおよび／またはデバイス１１０によって選択を行うことができる。好ましくは、SDK（デバイス１１０またはノードのいずれかまたは両方）内の事前構成された規則または属性によって定義されるように、最も安全な組み合わせが選択される。さらに、SDKを使用するデバイス開発者は、２つ以上の認証方法がデバイスで利用可能である場合、事前構成された認証方法を手動でオーバーライドすることができる（例えば、要求は、使用する認証方法工程を定義することができる）。

【0055】

認証方法が選択（選択、推測、または指示）されると、分散台帳１２０に対するデバイス１１０の登録「サービスとしての認証」手順は、デバイス１１０の次の電源投入時に自動的に開始することができる。この登録は、分散台帳１２０のノード内にデータを取り込むことにつながり、デバイス１１０の信頼できるデジタル識別子を生成するために使用することができる。いくつかの例では、デバイス１１０に関連する暗号材料（例えば、デバイスのIoT SAFE公開鍵、SIM Trust対称鍵など）は、分散台帳１２０のノード内に格納することができる。この格納は、（従来のCAのように）集中的に行われるのではなく、分散台帳技術を使用して分散的に行われる。これは、障害点がなく、２つ以上のノードが暗号証明の信頼性を管理するため、より高いレベルのセキュリティが可能になる。

【0056】

次いで、デバイス１１０が顧客バックエンド１３０または別のデバイスまたはエンティティにデータを送信すると、データストリームは、必要な認証方法を記述している暗号ヘッダを含み、図１を参照して説明した方法１０に従ってデータの信頼性を証明するための分散台帳用の「レシピ」を提供する。

【0057】

簡単な例として、ペイロードは、デバイス１１０およびSIMのみが知っている秘密鍵で署名することができ、または対称鍵で暗号化されたトークンを含むことができる。認証のためのこれらのシード（または他の暗号材料）は、登録中に分散台帳１２０と共有することができる（図２を参照）。

【0058】

図３は、図１を参照して説明した方法１０を実施するために使用されるデータの例示的なフローを示す。顧客バックエンド１３０またはデバイス１１０の認証を必要とする他のエンティティは、特定のデバイス１１０から受信した暗号ヘッダを分散台帳１２０のノードと検証することができる。これは、図３の工程２として示されており、アプリケーションプログラミングインターフェース（API：application programming interface）を使用して、または直接ブロックチェーン統合によって達成され得る。これは、非集中型台帳がこれらのデータの検証に使用されるため、従来の集中型CAとは異なる。この例では、認証のためにデバイス１１０から受信した要求は、顧客バックエンド１３０を通過し、分散台帳１２０のノードに渡される。分散台帳１２０上の２つ以上のノードは、要求内の情報（例えば、暗号ヘッダ）から定義または決定された特定の認証方法工程に従って、送信者の暗号証明が本物であるかどうかを検証する。

【0059】

チェックが成功した場合、すなわち暗号情報が信頼でき、任意選択で、デバイスIDが事前登録されたデバイス１１０に関連し、分散台帳１２０内に格納された場合、分散台帳１２０のノードは各々、要求と共に受信した暗号材料に対して定義された認証方法工程を実行する。（ノード内で実行された）これらの個々の認証が成功すると、分散台帳は、デバイスおよび要求内で受信したデータの信頼性を確認する（図３の工程３）。

【0060】

任意選択で、分散台帳１２０は、セキュリティを高めるために暗号情報を頻繁に変更または更新する必要がある場合に、デバイス１１０に新しい認証入力をプッシュすることができる（図３の工程４）。この仕組みは、暗号情報のライフサイクル管理（例えば、証明失効または更新）にも利用できる。

【0061】

したがって、このシステム１００および方法は、異なるデバイスタイプにわたる認証方法を統合し、アーキテクチャにわたる信頼性チェックをより簡単に可能にする。

【0062】

図２および図３に示すパートナーシステム１４０は、デバイス１１０および／または顧客バックエンド１３０にサービスを提供する決済システムまたは他のシステムを含むことができる。

【0063】

図４は、デバイス１１０によって顧客バックエンド１３０に送信された例示的な要求の高レベルの詳細を示す。この要求は、暗号ヘッダ（認証方法工程を記述）および任意の必要な暗号材料を含むペイロードを含む。

【0064】

当業者には理解されるように、上記の実施形態の詳細は、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく変更することができる。

【0065】

例えば、SIMまたはハードウェアセキュリティ要素のないデバイスもこの方法を利用することができる。異なる登録手順が使用されてもよい（または、デバイスは、事前登録なしで方法１０を使用してもよい）。この場合、要求は、例えば、追加のデータ（例えば、識別データ）を含んでもよい。図は１つのデバイスのみを示しているが、システムおよび方法は、同じまたは異なるタイプおよび能力の複数のデバイスと共に使用されてもよい。複数の顧客バックエンドが存在し、同様または異なる方法で構成されてもよい。さらに、例では顧客バックエンドが説明されているが、これは、例えば、異なる外部エンティティまたは分散台帳の別のノードであってもよい。認証方法の１つまたは複数の工程を示すデータは、直接指示（例えば、これらの工程を説明）を提供してもよく、または間接指示（例えば、そのような方法または方法工程の識別子を提供）の形態を取ってもよい。データはまた、データベースエントリ（例えば、分散台帳内または他の場所）へのポインタまたは参照であってもよい。提供されるサービスは、駐車、場所へのアクセス、他のユーティリティの電気、電気通信サービス、支払い、データアクセスなどを含むことができる。認証は、（車両が有料道路または駐車場に接近したときなどに）ユーザの介入なしに自動的に提供され得る。

【0066】

上記の実施形態の特徴に対する多くの組み合わせ、修正、または変更は、当業者には容易に明らかであり、本発明の一部を形成することが意図されている。１つの実施形態または例に具体的に関連して説明された特徴のいずれかは、適切な変更を行うことによって任意の他の実施形態で使用することができる。

【図1】

【図2】

【図3】

【図4】

【国際調査報告】