JP2024503921A

JP2024503921A - トラストレス鍵プロビジョニングのシステムおよび方法

Info

Publication number: JP2024503921A
Application number: JP2023544603A
Authority: JP
Inventors: バリーチャイルド; ジョンダプレ; デイヴィッドウェブ; デイヴィッドウィリアムズ; ジェイムズブラウン; マイケルマリ
Original assignee: アーキットリミテッド
Priority date: 2021-01-22
Filing date: 2022-01-21
Publication date: 2024-01-29
Also published as: GB202100910D0; CA3204281A1; AU2022210852A1; EP4282122A1; GB2603128B; WO2022157501A1; GB2603128A

Abstract

暗号化キー・プロビジョニングの方法で、量子コンピューティング安全方法による共有秘密データのデバイスおよびセキュリティサービスへの提供、ルートキーを提供するための提供された共有秘密データの使用、および一連の段階の基礎としてのルートキーの使用を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、同じ段階がデバイスおよびセキュリティサービスで並行して行われ、またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用され、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーは対称鍵である。

Description

本出願は鍵プロビジョニング・システムのトラストレス鍵プロビジョニング、特に量子セーフキーのトラストレス鍵プロビジョニングの方法、システムおよびソフトウェアに関するものである。

これらのみに限らないが、例えばオンラインショッピングやオンラインバンキングのトランスポート層セキュリティ（ＴＬＳ）から超安全な政府通信まで、日々の数十億もの取引を保護するために暗号技術が使用される。これらの取引は、少なくとも２者またはそれ以上の取引当事者が秘密鍵を共有し、ある当事者がデータの暗号化をしたら、その後他の当事者が復号できる、信頼性と安全性のある手段に依存している。

量子コンピュータの出現と、ショアのアルゴリズムの発明により、古典的な非対称暗号はもはや安全とは見なされない。最もよく知られている安全な通信プロトコル（例：ＴＬＳ）は、通信経路の両端に同一の対称鍵を送る際、非対称暗号に依存している（ディフィー・ヘルマン鍵共有を介する等）ため、量子コンピュータの出現によりこれらのプロトコルは不安定になると予測される。

安全な暗号化への他のアプローチとして、通信経路の両端に対称鍵を提供する方法がある。もし、非対称暗号を使わずに対称鍵を通信経路の両端に送ることができれば、望ましい量子コンピュータ耐性暗号化の基礎が提供できるかもしれない。しかし、安全な対称鍵プロビジョニングの周知の技術では、通常手作業で分配するキーマテリアルが必要となる。これには時間がかかるしコストも高く、関わる作業者の信用性を当てにしなければならない。さらに、手作業の鍵プロビジョニングのプロセスで分配する作業者が多量のキーマテリアルを所有することになるため、偶然、または作業当事者への不正アクセスにより、このキーマテリアルが紛失または不正アクセスされた場合、キーマテリアルを取り消して新たなキーを発行しなければならず、同じような遅い手作業によるプロセスが繰り返されることになる。

よって、対称鍵プロビジョニングを行うための量子コンピュータ耐性アプローチ、さらには鍵プロビジョニング・プロセスでキーマテリアルが紛失または不正アクセスされるリスクを回避するアプローチが切望されている。

以下に説明する実施形態は、上述の、周知のアプローチにある問題の一部または全部の解決を実現するだけにとどまらない。

この概要はコンセプトの選択範囲について簡潔に紹介するものであり、詳細は下記の詳細な説明で解説する。この概要は、特許出願対象物の重要または本質的な特徴を明らかにしたり、対象物の範囲を決めるために利用することを目的としていない。本発明の実施を促したり、および／または実質的に同様な技術的効果を達成するのに役立つ、異なる代わりの特徴も本書で公開する本発明の範囲に入ると考えるべきである。

第１の側面で、本開示は暗号化キー・プロビジョニングの方法を実現する。これは、量子コンピューティング安全方法による共有秘密データのデバイスおよびセキュリティサービスへの提供、ルートキーを提供するための提供された共有秘密データの使用、一連の段階の基礎としてのルートキーの使用を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、同じ段階がデバイスおよびセキュリティサービスで並行して行われ、またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用され、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーは対称鍵である。

第２の側面で、本公開はデバイス認証の方法を実現する。これは、量子コンピューティング安全方法による共有秘密データのデバイスおよびセキュリティサービスへの提供、ルートキーを提供するための提供された共有秘密データの使用、一連の段階の基礎としてのルートキーの使用を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、同じ段階がデバイスおよびセキュリティサービスで並行して行われ、またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用される。さらに、デバイスをセキュリティサービスに認証するための、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーの使用も含む。

第３の側面で、本開示は暗号化キー・プロビジョニングの方法を実現する。これは量子コンピューティング安全方法によるデバイスの秘密データから得られるデータのセキュリティサービスへの提供、ルートキーを提供するための秘密データから得られたデータの使用、一連の段階の基礎としてのルートキーの使用を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、同じ段階がデバイスおよびセキュリティサービスで並行して行われ、またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用され、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーは対称鍵である。

第４の側面で、本開示はデバイス認証の方法を実現する。これは量子コンピューティング安全方法によるデバイスの秘密データから得られるデータのセキュリティサービスへの提供、ルートキーを提供するための秘密データから得られたデータの使用、一連の段階の基礎としてのルートキーの使用を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、同じ段階がデバイスおよびセキュリティサービスで並行して行われ、またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用される。さらに、デバイスをセキュリティサービスに認証するための、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーの使用も含む。

第５の側面で、本開示は暗号化キー・プロビジョニング・システムを実現する。これは、量子コンピューティング安全方法により共有秘密データをデバイスおよびセキュリティサービスへ提供するために用意された手段、ルートキーを提供するよう提供された共有秘密データを使用するために用意された手段、および一連の段階の基礎としてルートキーを使用するために用意された手段を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、システムはデバイスとセキュリティサービスで同じ段階を並行して行うよう手配され、またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用され、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーは対称鍵である。

第６の側面で、本開示はデバイス認証システムを実現する。これは、量子コンピューティング安全方法により共有秘密データをデバイスおよびセキュリティサービスへ提供するために用意された手段、ルートキーを提供するよう提供された共有秘密データを使用するために用意された手段、および一連の段階の基礎としてルートキーを使用するために用意された手段を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、同じ段階がデバイスとセキュリティサービスで並行して行われ、またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用される。さらに、デバイスをセキュリティサービスに認証するため、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーを使用するために用意された手段も含む。

第７の側面で、本開示は暗号化キー・プロビジョニング・システムを実現する。これは、量子コンピューティング安全方法によりデバイスの秘密データから得られるデータをセキュリティサービスへ提供するために用意された手段、ルートキーを提供するよう秘密データから得られたデータを使用するために用意された手段、および一連の段階の基礎としてルートキーを使用するために用意された手段を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、同じ段階がデバイスとセキュリティサービスで並行して行われ、またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用され、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーは対称鍵である

第８の側面で、本開示はデバイス認証システムを実現する。これは、量子コンピューティング安全方法によりデバイスの秘密データから得られるデータをセキュリティサービスへ提供するために用意された手段、ルートキーを提供するよう秘密データから得られたデータを使用するために用意された手段、および一連の段階の基礎としてルートキーを使用するために用意された手段を含む。ここで各段階はスタートキーを違う生成キーに変換する演算で構成され、同じ段階がデバイスとセキュリティサービスで並行して行われる。またルートキーがシーケンスの最初の段階のスタートキーとして使用され、シーケンスの各段階で作られた生成キーは、シーケンスの最後の段階を除いて、シーケンスの次の段階のスタートキーとして使用される。さらに、デバイスをセキュリティサービスに認証するための、デバイスおよびセキュリティサービスでシーケンスの最後の段階で作られた生成キーを使用するために用意された手段も含む。

第９の側面で、本開示はコンピュータに読み込み可能な媒体を実現する。これには、ここに保存されたコードまたはコンピュータ命令が含まれ、プロセッサで実行されるとプロセッサは１～４の側面のいずれかに従った方法を実行するようになる。

第１０の側面で、本開示はコンピュータプログラム命令を実現する。これがプロセッサで実行されるとプロセッサは１～４の側面のいずれかに従った方法を実行するようになる。

本書で説明する方法は、有形的記録媒体においてソフトウェアが機械可読フォームで実行することができる。コンピュータ上でプログラムが起動しており、コンピュータプログラムがコンピュータ可読媒体で具体化させることができる場合に、本書で説明するいずれかの方法の全ステップを実行するよう適応させたコンピュータプログラムコード手段を含むコンピュータプログラムのフォームで実行するなどがその例である。有形的（または持続性）記録媒体の例にはディスク、サムドライブ、メモリカード等を含むが伝搬信号は含まれない。ソフトウェアではこの方法の段階がどのような適切な順序でも、または同時にでも実行できるため、パラレルプロセッサまたはシリアルプロセッサ上での実行にはソフトウェアが適切である場合もある。

このアプリケーションはファームウェアとソフトウェアが高価で別々に取引可能な商品であり得ることを認識している。データ処理能力のない、または標準的なハードウェアで起動するまたはそれをコントロールするソフトウェアが、求められる機能を実行することを目的としている。さらに、シリコンチップの設計またはユニバーサル・プログラマブル・チップの設定に使用するようなハードウェア記述言語（ＨＤＬ）ソフトウェアなど、ハードウェアのコンフィギュレーションを「説明する」または定義するソフトウェアが、求められる機能を実行することも目的としている。

当業者には明らかなように、好きな機能を適宜組み合わせることができ、本発明のいずれの側面とも組み合わせ可能である。
本発明の実施形態を以下の図面を例として参照しながら説明する。その中で、

図１は、本発明の第１実施形態によるサテライト量子鍵プロビジョニング・システムを説明する概略図である。図２は、本発明の第２実施形態によるテレストリアル量子鍵プロビジョニング・システムを説明する概略図である。図３は、図１または図２の第１または第２実施形態によるキーフィル・プロセスを説明する概略図である。図４は、図３のキーフィル・プロセスで使用できるデバイス記録のスキーマを説明する概略図である。図５は、図１の第１実施形態および図２の第２実施形態で使用できるユーザー登録プロセスを説明する概略図である。図６は、図１の第１実施形態および図２の第２実施形態で使用できるユーザー認証プロセスを説明する概略図である。図７は、図１の第１実施形態および図２の第２実施形態で使用できるユーザーの役割設定プロセスを説明する概略図である。図８は、図３のプロセスで使用できるワークフロー・ステップ方針設定プロセスを説明する概略図である。図９は、図３のプロセスで使用できるブートストラップ鍵投入プロセスを説明する概略図である。図１０は、図３のプロセスで使用できるデバイス認証プロセスを説明する概略図である。図１１は、図３のプロセスで使用できるデバイス登録プロセスを説明する概略図である。図１２は、図３のプロセスで使用できるコミッショナー承認プロセスを説明する概略図である。図１３は、図３のプロセスで使用できる鍵取り消しプロセスを説明する概略図である。図１４は、本発明の第３実施形態によるテレストリアル量子鍵プロビジョニング・システムを説明する概略図である。図１５は、図１４の第３実施形態によるキーフィル・プロセスを説明する概略図である。図全体にわたって共通参照番号を使い、同様の機能を示す。

本発明の実施形態をほんの一例としてのみ以下に説明する。これらの例は発明を実現するうえで出願者が現在わかっている最善の方法を表しているが、これを達成可能にする唯一の方法ではない。説明では例の機能、および例を構築し作動させるための一連のステップを明記する。ただし、同じまたは同等の機能およびシーケンスが別の例でも達成できることもある。

全体として、本公開はクラウドサービスへの認証で使用する、当事者およびクラウドサービス用の認証キーにシード値を設定する方法を実現する。一部の例では当事者がデバイスで、クラウドサービスがセキュリティサービスであるが、これはそれほど重要ではない。この方法は対称鍵を設定することによって、当事者およびクラウドサービスに量子コンピュータ耐性セキュリティを提供する。当事者とクラウドサービスとの間の安全なコミュニケーションまたはその他のやり取りに、この共有対称鍵を信頼の起点として使用することができる。
本公開は信頼の起点として作用する、またその全部または一部を自律的にできる、この対称鍵がプロセスを通して計算装置にキーフィルする方法を実現する。そこではサポートするクラウドサービス、全ての人間の当事者、および全ての盗聴者は対称鍵へのアクセスを得ることはできない。

図１は本発明の第１実施形態によるサテライトベースの量子安全トラストレス鍵プロビジョニング・システム１００の一例の概要を説明する概略図である。サテライトトラストレス鍵プロビジョニング・システム１００は、少なくとも地球の軌道にある１機の量子鍵プロビジョニング（ＱＫＤ）サテライト１および複数のオプティカル・グラウンド・レシーバ（ＯＧＲ）２から成る。それぞれのＯＧＲ２はＯＫＤサテライト１から量子安全暗号化キーを受け取ることができ、それを少なくとも他の１つのＯＧＲ２と共有する。サテライトから暗号化キーを配信する方法は知られているため、ここで詳細に述べる必要はない。

図１に示す通り、最初のＯＧＲ２ａは製造施設５と関連があり、２番目のＯＧＲ２ｂはクラウドサービス６と関連がある。ＯＧＲ２ａと２ｂはそれぞれ製造施設５およびクラウドサービス６に配置することができる。または他の場所に配置して製造施設５またはクラウドサービス６それぞれとのコミュニケーションができるよう手配することもできる。クラウドサービスは固有のＩＤを持つことができる。このＩＤはクラウドサービスをホストしているデータセンターまたはサーバー固有のものにできる。これによりクラウドサービスをホストするデータセンターまたはサーバーを特定することができる。図１はＯＧＲ２ａと２ｂの両方とコミュニケーションするサテライト１を示す。当然のことながら、これはサテライトがＯＧＲ２ａと２ｂの両方と同時にコミュニケーションできることが絶対必要であることを示す意図はない。

それぞれのＯＧＲ２は、少なくとも１機のＯＫＤサテライト１と光通信をするための光通信システム３を少なくとも１機と、光通信システム３から配信された暗号化キーマテリアルを安全に格納および管理するためのハードウェア・セキュリティ・モジュール（ＨＳＭ）４で構成される。ＨＳＭ４は鍵を不正に抜き出そうという試みをいずれも確実にブロックまたは検出できるようにする。ＨＳＭは、カプセル化されたメモリモジュールを包囲するワイヤケージ、過電圧、不足電圧、温度などの検出等、改ざん検出センサを提供する。このリストは包括的であることを目的としていない。一部の例ではＨＳＭ４がＦＩＰＳ１４０認証を受けている場合がある。システム１００の運転では、対称ＱＫＤ鍵が製造施設５とクラウドサービス６の両方に配信され、ＨＳＭ４ａおよび４ｂにそれぞれ安全に格納される。

当業者には当然であるように、サテライトベースの量子鍵プロビジョニング・システム１００は、実際には例えばサテライト・コントロールおよび／またはセキュリティオペレーションセンター等、他にも多くの構成要素があるが、簡素化と明確化のためこれらは省略する。

簡素化と明確化のため、１機のサテライト１と２機のＯＧＲ２のみを図１に示す。当然のことながら、実際には量子鍵プロビジョニング・システム１００を構成する一連のサテライト１およびＯＧＲ２の機数はどのような数にもなり得る。

クラウドサービス６はセキュリティサービス、つまり光ファイバーリンクを使用する等、安全なコミュニケーションを提供するシステムで、安全なデータ格納を提供することができる。さらに、クラウドサービス６はデバイスおよびユーザーの認証ができるが、これについては以下に詳細に説明する。このアプリケーションでは「安全な」および「安全に」という用語は、非対称アルゴリズムを使わずに確立されたリンクを超えたコミュニケーションに言及する場合にのみ使用する。上述の通り、非対称アルゴリズムは通常、量子コンピューティングに対するセキュリティを提供することはできないと考えられている。クラウドサービス６は量子安全鍵の生成、格納、配信、および検証のレジストリ、および量子安全鍵を使用する、クラウドサービス６に関連するデバイスおよびユーザーの認証と検証のレジストリを提供する。クラウドサービス６内部、およびクラウドサービス６とのコミュニケーションは全て量子安全保護がされている。クラウドサービス６は、例えばＡｒｑｉｔＱｕａｎｔｕｍＣｌｏｕｄ^TMである可能性がある。

クラウドサービス６はパブリッククラウドまたはプライベートデータセンターでホストされる場合がある。クラウドサービス６は、クラウドサービス６にデータストレージを提供するデータベース７に支援またはサポートされている。データベース７は例えば従来のデータベース、ＮｏＳＱＬデータベース、分散型データベース、または分散型台帳技術（ＤＬＴ）を支援するデータベースなどの場合がある。データベース７は、例えば分散型台帳技術（ＤＬＴ）、分散型データベース技術（ＤＤＴ）、ハッシュチェーンベースのロギング／監査、その他のデータベース技術（ＤＬＴ以外）およびハッシュチェーンベースのロギング／監査、および／またはメッセージベースの技術およびハッシュチェーンベースのロギング／監査等を使って動作することができる。このリストは一例にすぎず、包括的とする意図はない。これ以外のデータベース技術およびアーキテクチャが使用される場合もある。

ハッシュチェーンとは、あるデータに対して暗号学的ハッシュ関数を繰り返し適用したものである。また、否認防止のために、データの追加部分に対してハッシュ関数を次々に適用することで、データの存在を時系列に沿って記録するのにも使われる。ハッシュチェーンの使用またはロギングおよび／または監査についてはよく知られているため、ここで詳細に述べる必要はない。

製造施設５は、顧客がコントロールする対象デバイス８への暗号化キーの配信を望む顧客がコントロールし、対象デバイス８からクラウドサービス６へのアクセスを可能にすることができる。一部の例では、製造施設５はクラウドサービス６のオペレータがコントロールする場合もある。

図２は、本発明の第２実施形態によるテレストリアル量子安全トラストレス鍵プロビジョニング・システム２００の一例の概要を説明する概略図である。テレストリアル・トラストレス鍵プロビジョニング・システム２００は光ファイバーリンク１０でつながっている複数のテレストリアル・トランシーバ９で構成される。テレストリアル・トランシーバ９は相互間で、光ファイバーリンク１０を通じて量子暗号化キーの送受信をすることができる。光ファイバーリンクを通じた暗号化キーの送受信については知られているため、ここで詳細に述べる必要はない。

テレストリアル量子安全トラストレス鍵プロビジョニング・システム２００は、テレストリアル・トランシーバ９がＯＧＲ２に代わっていることを除けば、第１実施形態によるサテライトベースの量子安全トラストレス鍵プロビジョニング・システム１００に類似している。

図２に示す通り、最初のテレストリアル・トランシーバ９ａは製造施設５に関連しており、２番目のテレストリアル・トランシーバ９ｂはクラウドサービス６に関連している。テレストリアル・トランシーバ９ａおよび９ｂはそれぞれ製造施設５とクラウドサービス６に配置することができる。または他の場所に配置して製造施設５またはクラウドサービス６それぞれとのコミュニケーションができるよう手配することもできる。それぞれのテレストリアル・トランシーバ９は、光ファイバーリンク１０を通して暗号化キーを伝達できるよう手配された、少なくとも１機の光学量子トランシーバ１１と、光学量子トランシーバ１１を通して配信される暗号化キーマテリアルを安全に格納および管理するためのハードウェア・セキュリティ・モジュール（ＨＳＭ）４で構成される。クラウドシステム６は第１実施形態のクラウドシステム６に対応する。システム２００の動作で、対称ＱＫＤキーは製造施設５とクラウドサービス６の両方に配信され、それぞれのＨＳＭ４ａおよび４ｂに安全に格納される。

当業者には当然であるように、実際にはテレストリアル・トラストレス鍵プロビジョニング・システム２００にはセキュリティオペレーションセンター等、他にも多くの構成要素があるが、簡素化と明確化のためこれらは省略する。

簡素化と明確化のため、図２には２機のテレストリアル・トランシーバ９のみが示されている。当然のことながら、実際にはテレストリアル・トラストレス鍵プロビジョニング・システム２００を構成するネットワークが持つテレストリアル・トランシーバ９の機数はどのような数にもなり得る

トラストレス鍵プロビジョニング・システム１００および２００は両方とも、１個またはそれ以上の暗号化キーを対象デバイス８にロードすることにより、１機またはそれ以上の対象デバイス８をキーフィルするよう動作する。明確化と簡素化のため、ここでは１個の暗号化キーの１機の対象デバイスへのロードを説明する。ただし当然のことながら、システム１００および２００はロードするいずれの数量の暗号化キーにも、いずれの数量の対象デバイス８にも対応できる。

図３は、第１および第２実施形態による量子鍵プロビジョニング（ＱＫＤ）システム１００および２００が実行する、鍵プロビジョニングプロセス３００全体のワークフロー概要を示す。当然のことながら、第１および第２実施形態による量子鍵プロビジョニング・システム１００および２００の違いは、製造施設５とクラウドサービス６に関連するＨＳＭ４ａおよび４ｂで量子安全暗号化キーが利用できるようになるメカニズムだけである。

鍵プロビジョニングプロセス３００はクラウドサービス６と対象デバイス８の両方にＱＫＤキーを配信する。鍵プロビジョニングプロセス３００はその後これら２つの鍵（つまり、同じ対称キーの２つのコピー）を、クラウドサービス６と対象デバイス８の両方の環境で、それぞれラチェット動作から成る同じ歩調で徐々に前へ進め、クラウドサービス６と対象デバイス８の同じキーに到達する。各ステップで、スタートキーはラチェット動作により異なる、新しいまたは生成されたキーに変換される。ここで、これらの最終的な同一キーは信頼の起点として機能する対称キーとして使用できるようになる。これは、クラウドサービス６と対象デバイス８の間の量子計算安全コミュニケーションに、またはその他あらゆる望みのタスクを実行するのに使用できる。その結果、鍵プロビジョニングプロセス３００は並行して実行される２つのブランチまたはアームを持つようになる。これは対象デバイス８で実行される図３の上部ブランチ、第１ブランチ３００ａと、クラウドサービス６で実行される図３の下部ブランチ、第２ブランチ３００ｂで構成される。この例では、ＱＫＤキーはクラウドサービス６と対象デバイス８の両方に配信される。好都合なことに、このＱＫＤキーは対称暗号化キーであり得る。他の例では一般的にＱＫＤキーは共有暗号化キーとして使用したり、または共有暗号化キーの基礎として使用できる何らかの形態の共有秘密データである。

鍵プロビジョニングプロセス３００のそれぞれのブランチ３００ａ、３００ｂでは、対象デバイス８がクラウドサービス６への認証をする認証キーとして鍵を使用してから、チェーンの次のキーを生成することができる。最終キーは、例えばセッションキーを生成させる、またはその他の目的で、引き続き認証に使用することができる。

ワークフローは方針により定義されるため、デバイスや一連のデバイスに異なる方針を割り当てることにより、状況によって異なるワークフローを定義することができる。方針は特定のケースにおけるシステム１００または２００のランタイムオペレーションを定義する、関連する方針オプションの一群と見なすことができる。製造施設５には、クラウドサービス６の対象デバイス８に割り当てられた既定の方針がある。この既定方針は、製造施設５の全ての対象デバイス８に適用されるデフォルト方針とすることもできれば、または対象デバイス８のある分類または種類に割り当てられる特定の方針とすることもできる。または要望によって例えば製造施設５を運用する顧客、またはデバイス８を運用する顧客団体により特定の対象デバイス８に割り当てる特定の方針とすることもできる。鍵プロビジョニングプロセス３００を通したキーの動作またはラチェッティングは多くの制御装置（図１～３にはない）の承認を必要とする場合がある。制御装置は方針に規定する通り、対象デバイス８へのキーフィルの承認に使用されることがある。一部の例では、制御装置は以前にキーフィルを行って、それぞれの制御装置のクラウドサービス６との安全な通信を可能にしていた場合もある。また他の例では、制御装置がブラウザまたはその他のアプリケーションを起動して、クラウドサービス６との安全な通信を可能にするのに適したデバイスであるかもしれない。制御装置は、対象デバイス８がワークフローを移動する間、コミッショニング担当者が対象デバイス８の次のラチェットを承認するために使用する。前方へのラチェッティングと対象デバイス８へのキーフィルを承認するのに必要な、制御装置とコミッショニング担当者の数およびアイデンティティは、製造施設５、または対象デバイス８の顧客が決める方針により定義される。通常、コミッショニング担当者は製造施設５を運用する顧客が指名して選定するが、これは必須ではない。コミッショニング担当者は例えば、暗号通貨管理人、キー取扱者、現場セキュリティ担当者等がなり得るが、通常は、周知の鍵プロビジョニングプロセスの実行責任者に相当する。コミッショニング担当者は正式に訓練を受け、吟味される。コミッショニング担当者の選定手順は具体的な実施顧客の要件に基づいて決められるもので、ここで詳細に述べる必要はない。

一部の例では、制御装置はクラウドサービス６と安全に通信できるように、鍵プロビジョニングプロセス３００により安全なキーでキーフィルされている場合があり、制御装置が対象デバイス８であったかもしれない。

図３に、クラウドサービス６と対象デバイス８への共通ＱＫＤキーの最初の提供を示す。これは、第１実施形態のシステム１００により、サテライト１とＯＧＲ２ａおよび２ｂを使って実行されているところである。もし代わりに第２実施形態によるシステム２００が使用されていたら、ここに描写されているサテライト１とＯＧＲ２ａおよび２ｂは、光ファイバーリンク１０とテレストリアル・トランシーバ９ａおよび９ｂに取って代わられていただろう。

第１および第２実施形態による鍵プロビジョニングプロセス３００は、以下の通り多くの目的がある。今後のキー交渉任務のため（例：他のデバイスとのセッションキーについて交渉）、方針を利用して、対象デバイス８のクラウドサービス６への認証に使うキーチェーンを定義する一連のワークフロー・ステップを明らかにする。対象デバイス８をワークフロー・ステップ方針と関連付け、そこでそれぞれのワークフロー・ステップが、ステップにユーザーの認証および／またはコミッショニング担当者の承認を必要とするかを定義する。製造時にブートストラップキーを対象デバイス８で使えるよう設定し、それにより同じＱＫＤ配信キーに由来する２か所に送られたブートストラップキーを製造施設５とクラウドサービスで別々に計算し、それによりキーが製造施設５とクラウドサービス６の間の古典的な通信チャンネルを送信中に傍受できないようにする。対象デバイス８がブートストラップキーを使ってクラウドサービス６につなげられるようにし、既定の方針に従ったラチェットメカニズムを使い新しい認証キーに移行できるようにし、その後、対象デバイス８が最新のラチェットキーを使ってクラウドサービス６につなげられるようにし、既定の方針に従ったラチェットメカニズムを使い新しい認証キーに移行できるようにする。

第１および第２実施形態による図３の鍵プロビジョニングプロセス３００の概要は以下の通りとする。

鍵プロビジョニングプロセス３００の全ての工程および／またはシステム１００または２００が実行する全ての工程は、検証可能な量子的安全なハッシュチェーンを使って安全にログおよび／または監査される。ログ／監査の痕跡を変更不可能にし、攻撃者などからの変更が検出されないということがないようにこれが必要となる。システム１００または２００がＤＬＴに基づいている例では、ＤＬＴが不正加工防止のロギング／監査機能を提供できる。また、システム１００または２００がＤＬＴに基づいていない例では、ハッシュチェーンをベースとしたロギング／監査を使って、ロギング／監査を不正加工できないようにすることができる。

明確化のため、また不必要な繰り返しを避けるため、以下に提示する発明の実施形態の運用についての詳細説明に、ロギングについてははっきりと述べられていない。ただし当然のことながら、方法３００のそれぞれのステップはログされる。これは、例えばクラウドサービス６が提供する集中型ロギングサービスなどにより実行される場合がある。

明確化のため、また不必要な繰り返しを避けるため、以下に提示する発明の実施形態の運用についての詳細説明に、監査についてははっきりと述べられていない。ただし当然のことながら、方法３００のそれぞれのワークフロースタート、エラー、および成功は監査される。これは、例えばクラウドサービス６が提供する集中型監査サービスなどにより実行される場合がある

鍵プロビジョニングプロセス３００を実行する前に、システム１００または２００のユーザーはクラウドサービス６にサインアップまたは登録する。クラウドサービス６はユーザーのＥメールアドレスを使ったユーザー・サインアップ・サービスを提供する。ユーザーのＥメールアドレスを検証してからユーザーのサインアップが許可される。説明している実施形態では、新しいユーザーをサインアップする際、２要素認証を利用している。Ｅメールアドレスの検証と２要素認証はよく知られた手順であるため、ここで詳しく説明する必要はない。新しいユーザーのサインアップの際、Ｅメールアドレスの検証と２要素認証の使用は必須ではなく、他の異なるサインアップ手順の例が使われる場合もある。

ユーザーがクラウドサービス６にサインアップする際、クラウドサービス６は各ユーザーにランダムな対称ユーザーキーを割り当てるが、これはそれぞれのユーザーパスワードのハッシュを使って暗号化されているクラウドサービス６のデータベース７に格納される。当然のことながらこれは必須ではなく、他の手段を使ってユーザーキーおよび関連パスワードを格納および保護する場合もある。

好都合なことに、所定のいずれかの団体から最初にサインアップしたユーザーに管理者の役割が割り当てられる。それに続く同じ団体からのユーザーには、団体の管理者から役割が割り当てられる。ただしこれは必須ではなく、これの替わりの例では役割について他の割り当て方法が利用される場合もある。

クラウドサービス６にサインアップしたユーザーは、管理者またはそれぞれの団体の管理者から複数の色々な役割を割り当てられる場合がある。それに応じて、クラウドサービス６は、管理者がクラウドサービス６の他のユーザーの役割を変更できるプロセスを提供する。このプロセスの詳細、および特定の管理者がどのような変更ができるのかは、それぞれの団体の要件に基づき必要に応じて決定する。

ユーザーは管理者の役割を割り当てられる場合がある。管理者はクラウドサービス６を管理し、鍵プロビジョニングプロセス３００の間に適用する方針を定義し、他のユーザーに役割を割り当て、その他のタスクを実行する。ユーザーは監査の役割を割り当てられる場合がある。さらに、上述の監査の一環として管理者または特定の監査役に、その責任下にあるシステムおよびプロセスの一部に関する監査通知が送られる場合がある。管理者または監査役は、例えば、特定の監査または監査の類を受けた時Ｅメールを受け取るなど、自分の監査通知を適切に設定することができる。監査役は、管理者の役割とは異なる保証活動として、システム内の全ての監査関連データのアクセスを提供したりロックダウンを行ったりすることもできる。これは、内部管理レベルシステム役割による不正なシステムレベル活動の破壊、削除または隠蔽の試みを防ぐには望ましいかもしれない。

ユーザーはコミッショニング担当者の役割を割り当てられる場合がある。コミッショニング担当者は、ワークフロー・ステップ方針によっては、制御装置を使った自動キーフィル・プロセスの一環として、対象デバイスのチェーン内の次のキーへ、キーがラチェットするのを承認することが求められる場合がある。これについては以下に詳細を記述する。

ユーザーはユーザーの役割を割り当てられる場合がある。ユーザーは特定の対象デバイスを使う権限を与えられたユーザーで、ワークフロー・ステップ方針によっては、対象デバイスが次のキーへラチェットできるよう認証情報を提供するよう求められる場合がある。これについては以下に詳細を記述する。

上記に特定した役割以外にも、例えば、ユーザーにＡＰＩを介したＯＴＰの作成、使用を許可するかどうかなど、他の役割または範囲が各ユーザーに適用される場合がある。

上記のとおり、クラウドシステム６にサインアップしたユーザーに提供される機能性の他に、クラウドシステム６はユーザーが、ウェブポータルまたはアプリを使って管理業務を実行するためのクラウドサービスキーを使えるよう設定していないデバイスからクラウドサービスに認証できるプロセスを提供する場合がある。

図３を参照すると、システム１００または２００は、責任ある管理者が、鍵プロビジョニングプロセス３００のブランチ３００ａ、３００ｂを形成するキー・ラチェット・パイプラインを定義する一連のワークフロー・ステップを特定できる非環式状態機械を提供している。非環式状態機械は有限状態機械で、ここではこれまでにアクセスした状態に再アクセスすることはできない、つまり、開始状態から終了状態まで直線を形成し、循環はしない。

対象デバイス８で、図３の鍵プロビジョニングプロセス３００が実行できるようになる前に、責任ある管理者は１つまたはそれ以上のワークフロー・ステップを定義するワークフロー・ステップ方針を明示して、キー配信プロセス３００のワークフローにおける一連のステップを定義しなければならない。そして、この定義されたワークフロー・ステップ方針はクラウドサービス６のデータベース７に格納される。さらに、個々のワークフロー・ステップも定義しなければならず、このように定義されたワークフロー・ステップも、クラウドシステム６のデータベース７に格納される。

それぞれに定義されたワークフロー方針により、対象デバイス８が鍵プロビジョニングプロセス３００の各ワークフロー状態から次のワークフロー状態へ移行するために満たさなければならない要件が定義される。それぞれに定義されたワークフロー・ステップにより、対象デバイス８が特定のワークフロー状態から次のワークフロー状態へ移行するために満たさなければならない要件が定義される。ワークフロー・ステップが、次のワークフロー状態へ移行するために対象デバイスでのユーザー認証が必要かどうか、または、次のワークフロー状態へ移行するために別の制御装置であるいはウェブポータルを介してなどによりコミッショニング担当者の承認が必要かどうか、いくつ必要か、そして、そのワークフロー・ステップにおけるラチェットキーでクラウドサービスへ認証する際に許可されるＡＰＩ範囲などを定義する場合がある。

簡素化および明確化のため、この説明は１つのワークフロー方針による１つの対象デバイス８のキーフィリングについてのものとする。当然のことながら、システム１００または２００を使用する団体によって設定するワークフロー方針は様々であり、それぞれの団体が異なる対象デバイス８または対象デバイス８群について複数の異なるワークフロー方針を設定する場合もある。

図３に示す通り、それぞれの対象デバイス８について、鍵プロビジョニングプロセス３００はブートストラップキーを対象デバイス８に入れることから始まり（３０２）対象デバイス８をブートストラップ状態にする（３０４）。製造施設５は、必要に応じてＯＧＲ３ａまたはテレストリアル・トランシーバ９ａのＨＳＭ４ａに格納されているＱＫＤキーを選択し、その選択したキーから新しいブートストラップキーを派生させて、その派生させたブートストラップキーを対象デバイス８へ入れる。するとブートストラップキーは、例えばデバイスストレージまたはチップ内に格納する、または他の何らかの方法で対象デバイス８へ格納される。このブートストラップキーの投入は対象デバイス８の初期製造で実行されることもあれば、その後いずれかのタイミングで実行されることもある。上記で述べた通り、ＱＫＤキーは共有暗号化キーとして使用したり、または共有暗号化キーの基礎として使用できる何らかの形態の共有秘密データである。好都合なことに、ＱＫＤキーは対称暗号化キーであり得る。

その後、または同時に製造施設５は、ブートストラップ・プロビジョニング・ターミナルまたはクラウドサービス６との安全な通信を提供するサービスを使って、３０６ブートストラップキーをクラウドサービス６へ登録する。プロビジョニング３０６を実行するために、製造施設５はクラウドサービス６に、例えば、デバイスＩＤおよび／または製造社、およびＱＫＤキーからブートストラップキーを派生させるのに使ったＱＫＤキーのＩＤなどのデータ等、対象デバイス８に関するメタデータを知らせる。しかし、製造施設５はブートストラップキーまたはＱＫＤキーをクラウドサービス６へ送らない。よって、これらのキーは他の当事者から傍受やアクセスをされることはない。

クラウドサービス６は、ＱＫＤアイデンティティ、メタデータ、および製造施設５から提供されたデータをデータベース７に格納する。製造施設５がブートストラップキーを派生させるためにＨＳＭ４ａから選択したＱＫＤキーは対称キーで、これをクラウドサービス６はＨＳＭ４ｂからも入手できる。よって、クラウドサービス６は要求に応じて、必要な時に、格納された提供済みのＱＫＤＩＤおよびデータ、そして格納されたＱＫＤキーを使って同じブートストラップキーを計算できる。

プロビジョニング３０６の一環として、クラウドサービス６は対象デバイス８に関するデバイス記録をデータベース７に生成する。このデバイス記録は、関連する管理者および／または製造施設５が選んだ対象デバイス８に関連するワークフロー方針のコピーを保管、またはそこへリンクする。さらに、クラウドサービス６は対象デバイス８に関するコミッショニングの署名欄およびコミッショニング当事者欄をゼロに初期化し、その対象デバイス８でコミッショニング担当者の承認が必要なそれぞれのワークフロー・ステップで利用できるよう、ランダムなコミッショニング・ソルトを生成して格納する。コミッショニングの署名欄はデバイス記録の対象デバイス８に関する欄で、コミッショニング担当者が署名したという証拠となる署名済みのランダムな数字を並べたものである。

クラウドサービス６は対象デバイス８のデータベース７にあるデバイス記録を、ワークフロー状態ブートストラップ３０８で初期化する。

その結果、対象デバイス８のワークフロー状態は既知の状態ブートストラップ３０４で開始し、クラウドサービス６にある対象デバイス８のデバイス記録のワークフロー状態はそれに対応する既知の状態ブートストラップ３０８となる。次のワークフロー状態の要件がその対象デバイス８に割り当てられたワークフロー・ステップ方針に定義する通り満たされていれば、対象デバイス８は次のワークフロー状態に移行することができる。これについては以下に詳細を記する。

従って、ブートストラップ鍵は、製造時またはその後にデバイスに挿入されるＱＫＤ配送鍵から形成される鍵であり、またクラウドサービスで計算することもできる。
ブートストラップ鍵は、クラウドサービスＡＰＩの限られた集合、具体的にはラチェットパイプラインの進行に関係するものにアクセスを許可する。

システム１００または２００は目的のデバイス８がブートストラップ鍵またはブートストラップ鍵からラチェットされた鍵を使ってクラウドサービスへ認証を行う手段を与える。各ケースにおいて、クラウドサービス６は最初のＨＳＭ４ｂに保存されたＱＫＤ鍵から、ブートストラップ鍵の生成を行うための認証に必要なキーチェーンを構築する。ブートストラップに基づいて作られる鍵はクラウドサービス６によってオンデマンドで、データベース７に保持される保存ラチェット値を使って計算できる。ターゲットデバイス８はクラウドサービス６に対して、ブートストラップ鍵またはそれにラチェットされた鍵を使って認証されたとき、クラウドサービス６は、ＪＳＯＮＷｅｂトークン（ＪＷＴ）などのトークンを返す。それらのスコープはワークフローのステップで、ターゲットデバイス８に対して定義される。クラウドサービス６によるターゲットデバイス８の認証にはチャレンジ－レスポンスによって、その時の鍵から（ブートストラップ鍵またはブートストラップ鍵にラチェットされた鍵）セッション鍵及び、ターゲットデバイス８とクラウドサービス６の間で交換されてその後破棄される、二つのチャレンジコードを生成する。

ＪＷＴは任意署名および／または任意暗号化付きのデータを作成するインターネットの標準的方法で、そのペイロードは少なくともクレームまたは範囲の一部の数字をアサートするＪＳＯＮを保持する。

クラウドサービス６は鍵を使って対象デバイス８のクライアント状態、Ｋ＿ＣＳ暗号化する。これはＲＥＳＴｆｕｌＡＰＩｓを許可し、それによってクラウドサービス６サーバーはセッションとセッションの間で対象デバイス８のクライアント状態を格納することはできない。クライアント状態はむしろクライアントに戻され、次のＲＥＳＴｆｕｌコールで再送される。これを使って例えば、セッションキーを対象デバイス８クライアントに１回サービス分戻し、次のコールでロードバランシングなどによる違うサービスのために供給でき、クラウドサービス６がコールとコールの間にセッションキーを格納したり、セッションキーを多くのサービスで配信する必要がなくなる。

ワークフロー・ステップで対象デバイス８が移行するためにコミッショニング担当者の承認が必要な場合、必要とされているコミッショニング担当者全員が制御装置の使用についての承認のリクエストを許可しなければならない。通常は安全なモバイルアプリケーションまたはウェブアプリケーションを制御装置で起動してこれを行う。一部の例では、コミッショニング担当者はその代わりに、Ｅメールリンクを使って、またはリンクをアクティベートするＱＲコードをスキャンして、またはモバイルアプリケーションまたはウェブアプリケーションを信頼できないデバイスで起動させて、承認のリクエストを許可することができる。コミッショニング担当者が承認のリクエストを許可する際、コミッショニング担当者のユーザーキーを使ってそれまでにクラウドサービス６により生成および格納されたコミッショニング・ソルトを暗号化したコミッショニング担当者の制御装置の中の承認結果と、データベース７の中に格納された対象デバイスのデバイス記録のコミッショニング署名フィールドにある署名のリストに追加された結果、およびデータベース７に格納された対象デバイスのデバイス記録のコミッショニング当事者フィールドへ追加されたコミッショニング担当者のユーザー名。

必要に応じてブートストラップキーまたはブートストラップキーからラチェットしたキーを使って対象デバイス８をクラウドサービス６へ認証し、クラウドサービス６とセッションキーについて交渉する対象デバイス８、そしてクラウドサービス６からのＪＷＴなどの認証トークンを受け取ったら、対象デバイス８のユーザーはクラウドサービス６と対象デバイス８のプロビジョニング・プロセスを始め、ブートストラップキーまたはブートストラップキーからラチェットしたキーのいずれかである最新のキーのラチェットをトリガすることができる。

対象デバイス８をクラウドサービス６へ登録するために、対象デバイス８はプロビジョニング機能をコールし、認証トークンおよび（任意で）ワークフロー・ステップで求められればユーザー認証を渡す。オプションとして、クラウドサービス６はユーザーにパスワードの使用およびオプションで２要素認証（２ＦＡ）の使用を認証する場合もある。他の認証方法が追加で、または代替として使用されることもある。アイデンティティサービスからのユーザーＪＷＴなどの認証コードがその例である。トークンの受け取りに対し、また、オプションでのユーザー認証が成功したら、クラウドサービス６はランダムなデータを生成し、これを使ってラチェット値を作成する。ラチェット値は最新のラチェットキーを次のラチェットキーにラチェットするために使用し、対象デバイス８に関連するラチェット値の配列の中のデータベース７にこの値を格納する。オプションとして、対象デバイス８の現在のワークフロー・ステップがコミッショニング担当者の承認を必要としており、必要とされる承認がワークフロー・ステップに関連するコミッショニング署名フィールドに格納されている場合、コミッショニング署名のリストはワークフロー・ステップのラチェット値に統合される。このラチェット値はラチェット値チェーンの最新のものとして使われ、今後、要求に応じたオリジナルＱＫＤキーからの新しい認証キーを計算するのに使用することができる。

ここでクラウドサービス６はラチェット値を対象デバイス８へ返し、対象デバイス８もそのチェーンの中の最新のキーから新しいラチェットキーを作成できるようになり、新しい認証キーを形成できる。その結果、最初の登録で新しいラチェットキーがブートストラップキーから、またはその後の登録では前回の登録で作成されたキーから作成される。

図３に示す通り、対象デバイス８がブートストラップ状態３０４の時、鍵プロビジョニングプロセス３００は対象デバイス８により継続され、上記の認証とプロビジョニングプロセスを使ってクラウドサービス６を認証し、プロビジョニングを行う。一部の例では、対象デバイス８のクラウドサービス６との認証およびプロビジョニングはユーザーの行動によりトリガされる場合もある。その他の例では、対象デバイス８のクラウドサービス６との認証およびプロビジョニングは、例えば、方針によりユーザー認証が必要でない場合、対象デバイス８の最初のブートによるなど、対象デバイス８が自ら自動的にトリガする。ターゲット・デバイス８の認証およびプロビジョニング・プロセスが成功し、任意のユーザ認証が成功し、ターゲット・デバイス８に適用されるワークフロー・ステップ・ポリシーの次のワークフロー・ステップによって必要であると識別された委託担当者の承認が受信された場合、クラウドサービス６は、上述のようにラチェット値を生成し、ラチェット値を使用して、ブートストラップ鍵からラチェット認証鍵を作成し、このラチェット認証鍵は、上述のように選択されたＱＫＤ鍵から作成される。ターゲット・デバイスは、データベース７のデバイスレコード内のターゲット・デバイス８のステータスを、ブートストラップ状態３０８から次のワークフロー状態（図３の例では、この例では「検疫」と名付けられた状態３１２）にラチェット３１０転送する。

クラウドサービス６は、次に、または同時に、ラチェット値をターゲット・デバイス８に送信し、ターゲット・デバイス８は、ブートストラップ鍵から同じラチェット認証鍵を作成し、このラチェット認証鍵は、上述したように、選択されたＱＫＤ鍵から順番に以前に作成されたものであり、ターゲット・デバイス８は、ブートストラップ状態３０４から次のワークフロー状態、図３の例では「検疫」と名付けられた状態３１６に、その状態３１４をラチェットする。

図３の例では、「検疫」という名前の状態３１６にあり、「検疫」という名前の対応する状態３１０にあるデータベース７のデバイスレコード内のターゲット・デバイス８のステータスを有するターゲット・デバイス８は、ターゲット・デバイス８がクラウドサービス６との認証および登録に成功することを条件として、クラウドサービス６によって制限されたシステムおよびネットワーク接続性を提供される。この制限された接続性は、状態３１６にあるターゲットデバイス８が、クラウドサービス６に危害を加えたり、クラウドサービス６のセキュリティを侵害したりするために使用できないことを保証するために選択される。いくつかの例では、状態３１６にあるターゲット・デバイス８に提供されクラウドサービス性は、閉鎖された検疫ネットワークへの接続のみを許可するようにすることができる。

その後、ターゲット・デバイス８が状態３１６にあるとき、鍵プロビジョニング・プロセス３００は、ターゲット・デバイス８が上述の認証および登録プロセスを使用してクラウドサービス６と再び認証およびプロビジョニングすることによって継続する。認証およびプロビジョニング・プロセスが成功し、任意のユーザ認証が成功し、ターゲット・デバイス８に適用されるワークフロー・ステップ・ポリシーの次のワークフロー・ステップによって必要であると識別された委託担当者の承認が受信された場合、クラウドサービス６は、上述のようにさらなるラチェット値を生成し、さらなるラチェット値を使用して、ラチェット鍵から新しいラチェット認証鍵を作成する。次に、クラウドサービス６は、データベース７内のデバイスレコード内のターゲット・デバイス８のステータスを、状態３１２から次のワークフロー状態（図３の例では、「ｐｒｏｄｕｃｔクラウドサービスの状態３２０）にラチェット３１８転送する。

クラウドサービス６は、その後、または同時に、さらなるラチェット値をターゲット・デバイス８に送信し、ターゲット・デバイス８は、上述したように、ブートストラップ鍵および選択されたＱＫＤ鍵から順番に以前に作成されたラチェット鍵から、同じ新しいラチェット認証鍵を作成し、ターゲット・デバイス８は、状態３１６から次のワークフロー状態、図３の例では「ｐｒｏｄｕｃｔｉｏｎ」と名付けられた状態３２４に、その状態３２２をラチェットする。

図３の例では、状態３２４にあり、対応する状態３２０にあるデータベース７のデバイスレコードにターゲット・デバイス８のステータスを有するターゲット・デバイス８は、ターゲット・デバイス８がクラウドサービス６との認証およびプロビジョニングに成功することを条件として、クラウドサービス６によって完全なシステムおよびネットワーク接続性を提供される。提供される接続性は、ターゲット・デバイス８を制御する組織の接続性ポリシーによって設定される場合がある。最終的な「本番」キーは、「検疫」状態よりも広範囲のクラウドサービス機能へのアクセスを許可し、提供されるアクセスは、関連するワークフローポリシーのスコープによって定義される。

図３の例は、ターゲット・デバイス８が、初期ブートストラップ状態３０４から、中間「検疫」状態３１６、完全なシステムおよびネットワーク接続性を提供する最終「本番」状態３２４へと段階的に移行するキープロビジョニング・プロセス３００を示している。他の例では、初期ブートストラップ状態と最終状態との間に、特定の組織のポリシーによって要求される任意の数の中間状態が存在する可能性があり、各状態はワークフロー・ステップポリシーで定義され、命名される。ターゲット・デバイス８がある状態から次の状態へラチェットフォワードできるようにするための要件は、必要に応じて設定することができ、特に、ユーザ認証が必要かどうか、コミッショニングオフィサーの承認が必要かどうか、およびその数は、必要に応じて設定することができる。制限された接続性を提供する中間の「隔離」状態を提供することは必須ではない。初期ブートストラップ状態、および最終状態に加えて、いくつかの例では、以下の１つ以上の名前が付けられた中間状態を構成することができる：「ＩｎｉｔｉａｌＣｏｎｆｉｇｕｒｅｄＦａｃｔｏｒｙ」、「ＭＮＯＰｅｎｄｉｎｇ」、「ＭＮＯＰｒｏｖｉｓｉｏｎｅｄ」、「ＣｕｓｔｏｍｅｒＰｅｎｄｉｎｇ」、「ＣｕｓｔｏｍｅｒＰｒｏｖｉｓｉｏｎｅｄ」、および／または「Ｑｕａｒａｎｔｉｎｅ」。

状況によっては、ターゲット装置８に関連するすべてのキーを失効させ、ターゲット装置８をブートストラップキーで元の製造設備状態に戻すことが必要な場合がある。これは、すべての委託当事者と委託署名フィールドをゼロにし、すべてのラチェットフィールドとラチェットアレイをゼロにし、現在のワークフロー・ステップをスタートに戻すことによって行うことができる。これにより、データベース７内の対象デバイス８のレコードは、ブートストラップ状態３０８にリセットされる。したがって、例えば状態３２４に関連するキーラチェットを使用した次の認証は失敗し、工場出荷時リセットが発生したことを通知するエラーコードがターゲット機器８に返され、ターゲット機器８がブートストラップ状態３０４にリセットされる。その後、ターゲット機器８は、適切な時点で、登録プロセスを再び開始することができる。

代替例では、ブートストラップ鍵が、製造業者とクラウドサービスの両方の場所でＱＫＤ配信鍵から導出される代わりに、ブートストラップ鍵は、古典的に安全な、ポスト量子暗号的に安全な、または物理的なメカニズムによってクラウドサービス６に配信されてもよい。

開示された実施形態が上記の目標を達成することができることは、上記および以下の詳細な例から理解されるであろう。

図４は、ターゲット・デバイス８のデバイスレコードとしてクラウドサービス６のデータベース７に保持され得るスキーマ４００の例示である。スキーマ４００は、対象デバイス８に関するデバイスデータ４０２から構成される。デバイスデータ４０２は、製造者ＩＤ、デバイスＩＤ、ＱＫＤ鍵ＩＤ、ブートストラップｎｏｎｃｅ、ワークフロー・ステップポリシー識別子、ワークフローラチェット値、ワークフローコミッショニング識別子、およびワークフローステップインデックスから構成される。製造者ＩＤは、製造施設５を識別することもできるし、ターゲット機器８を担当する組織を識別することもできる。ブートストラップ・ノンスは、ＱＫＤ鍵からブートストラップ鍵を導出するために使用されるデータである。

デバイス・データ４０２のワークフロー・ステップ・ポリシー識別子は、ターゲット・デバイス８に適用されるワークフロー・ステップ・ポリシーのワークフロー・ステップ・ポリシー・データ４０４にリンクする。ワークフロー・ステップ・ポリシー・データ４０４は、ワークフロー・ステップ・ポリシーＩＤ、名前、およびワークフロー・ステップ識別子の数から構成される。

ワークフロー・ステップ・ポリシー・データ４０４の各ワークフロー・ステップ識別子は、ワークフロー・ステップデータ４０６にリンクしている。各ワークフロー・ステップデータ４０６は、ワークフロー・ステップＩＤ、ワークフロー・ステップを実行することによって到達した状態の名前を識別する名前、ワークフロー・ステップがユーザ認証を必要とするかどうか、ワークフロー・ステップが委託担当者の認可を必要とするかどうか、およびそのワークフロー・ステップを実行することによって到達したキーに付与されたスコープ、すなわち操作許可から構成される。

ワークフロー・ステップが委託担当者認可を必要とする場合、ワークフロー・ステップデータ４０６は、多数の委託担当者認可データ４０８にリンクされる。各委託担当者認可データ４０８は、認可ＩＤ、委託担当者のユーザ名、電子メールアドレス、パスワードソルト、パスワードダイジェスト、暗号化されたユーザキー、状態、およびユーザロールから構成される。図示された実施例では、ワークフロー・ステップデータ４０６は、単純明快にするために、単一の委託担当者認可データ４０８に直接リンクされている。各ワークフロー・スワークフロー・ステップ６は、任意の数の委託担当者権限データ４０８にリンクされてもよいことが理解されよう。さらに、ワークフロー・ステップでどの委託担当者または委託担当者の組み合わせが必要かを定義するルールを設定することができる。例えば、承認は、特定の個人、定義されたグループの１人以上のメンバー、または論理的に定義された組み合わせ、例えば、コミッショニングオフィサーＡによる承認およびコミッショニングオフィサーグループＢのメンバー、またはコミッショニングオフィサーＣによる承認またはコミッショニングオフィサーグループＤの２人のメンバーおよびコミッショニングオフィサーグループＥのメンバーによって要求されるかもしれない。

機器データ４０２のワークフロー・ステップ・ポリシー識別子は、承認状態が保存されている対象機器８のワークフロー・ステップ承認データ４１０にもリンクしている。ワークフロー・ステップ承認データ４１０は、ワークフロー・ステップ承認ＩＤ、承認する委託担当者の委託担当者署名の記録、承認する委託担当者の名前、委託担当者によって暗号化または署名されるソルト、および必要に応じて、このワークフロー・ステップのために認証を提供したユーザの記録から構成される。

図４の例では、ワークフロー・ステップデータ４０６をワークフロー・ステップ・ポリシー・データ４０４にリンクしている行のインジケータ１：ｎで示されているように、スキーマ４００にリンクされているワークフロー・ステップデータ４０６が１つ以上存在する可能性があり、委託担当者承認データ４０８をワークフロー・ステップデータ４０６にリンクしている行のインジケータＯ．ｎで示されているように、各ワークフロー・ステップデータ４０６にリンクされている委託担当者承認データ４０８が０つ、または任意の数だけ存在する可能性がある。さらに、ワークフロー・ステップ承認４１０をデバイスデータ４０２にリンクするユーザ上のインジケータ１：ｎで示されるように、スキーマ４００にリンクされた１つ以上のワークフロー・ステップ承認４１０が存在する。ワークフロー・ステップポリシーの各ワークフロー・ステップに対応するワークフロー・ステップデータ４０６が存在する。さらに、各ワークフロー・ステップは、委託担当者の承認を必要としないか、または任意の希望する数の委託担当者の承認を必要とする可能性があるため、ワークフロー・ステップデータ４０６は、対応する数の（ゼロを含む）委託担当者承認データ４０８にリンクされる。

図５は、図示された第１および第２の実施形態で使用され得る詳細なユーザ登録プロセスの例示である。

図５に示すユーザ登録プロセス５００では、ユーザ５０２がクラウドサービス６でアカウントを作成することを選択すると、プロセス５００が開始する。ユーザは、ユーザ名ＵＮ＿Ｕ、電子メールアドレスＥおよびパスワードＰ＿Ｕからなるサインアップ情報５０４を提供する。ユーザ５０２は、モバイルユーザのアプリ、ウェブアプリユーザはその他の方法でサインアップ情報を提供することができる。

次に、ユーザプリはクラウドサービス６を呼び出し、ＵＮ＿ＵとＰＪＪを渡し、新しいアカウントを要求する。

クラウドサービス６は、ユーザ５０２のアカウントがすでに存在するかどうかをチェックする。チェックの結果、アカウントがすでに存在することが示された場合、クラウドサービス６はエラーメッセージ５１０を返し、登録は終了する。あるいは、チェック５０８が、アカウントのユーザが存在しないことを示す場合、クラウドサービス６は、ユーザ５０２のデータベースに新しいレコード５１２を作成し、対称ユーザ鍵Ｋ＿Ｕを作成する。

次に、クラウドサービス６は、ＰＤＫＤＦ２（またはｓｈａ２５６以上を使用する他のパスワードハッシュアルゴリズム）を使用して、Ｐ＿ＵからパスワードキーＫ＿Ｐを導出し、Ｋ＿ＵをＫ＿Ｐで暗号化してＫ＿ＵＥを形成し、その結果をユーザレコードに格納する：
Ｋ＿Ｐ＝ＰＢＫＤＦ２（Ｐ＿Ｕ）ｏｒＫ＿Ｐ＝ＰＢＫＤＦ２（Ｐ＿Ｕ，＜ｎｕｍｉｔｅｒａｔｉｏｎｓ＞）及び
Ｋ＿ＵＥ＝｛Ｋ＿Ｕ｝Ｋ＿Ｐ

次に、クラウドサービス６は、ランダムなパスワードソルトＳ＿Ｕを生成５１６し、それを使用してＰ＿Ｕをハッシュ化し、パスワードのダイジェストＤ＿Ｐを作成し、Ｓ＿ＵとＤ＿Ｐを格納する：
Ｄ＿Ｐ＝＃（Ｓ＿Ｕ，Ｐ＿Ｕ）

次に、クラウドサービスは、少なくとも以下のフィールドと値を持つユーザのレコード５１８をデータベースに作成する（必要に応じて、テナントＩＤ、会社名などの他のフィールドを追加することもできる）：

次に、クラウドサービス６は、ユーザの電子メールアドレスＥに検証電子メール５２０を送信し、この電子メールには、ソース電子メールアドレスを検証するために使用できる匿名リンク、および／またはリンクを効果的にクリックするためにスキャンできるＱＲＣｏｄｅが含まれている。

ユーザ５０２が電子メールを受信すると、ユーザはリンク５２２をクリックするか、ＱＲＣｏｄｅをスキャンし、これによりクラウドサービス６に通知５２４が送信される。

クラウドサービス６が通知を受信すると、クラウドサービス６は、リンク内の匿名データからユーザレコードを検索し、ユーザ状態を検証済みとしてマークする。

その後、クラウドサービス６は、新しいユーザカウントが開設されたことを確認するためのメッセージ５３０をユーザ５０２に送り返す。

ユーザ登録プロセス５００は、単一組織またはシングルテナントシステム、あるいは、組織またはテナントがユーザの電子メールアドレスで指定されたドメインと一致することによって、または本発明でカバーされない他の方法によって選択される、複数組織またはマルチテナントシステムのいずれかを想定している。

ユーザ登録プロセス５００において、ＯＡｕｔｈ２または他の標準的なユーザ認証パターンをユーザ認証およびパスワード管理に使用することができるが、この場合、ユーザ鍵をクラウドサービス６のデータベース７に平文で保持する必要があるか、またはユーザ鍵を完全に省略することができる。

ユーザ登録プロセス５００では、二要素認証を（ユーザ）認証フローに組み込むことができる。

図６は、図示された第１および第２の実施形態においてユーザ管理を可能にするために使用され得る、詳細なユーザのみの認証プロセスの例示的な例である。図６のユーザのみ認証プロセスは、図３の鍵プロビジョニング・プロセス３００では使用されない。

図６に示すユーザのみの認証プロセス６００では、プロセス６００は、ユーザ６０２が、ユーザ名ＵＮ＿Ｕ’、または電子メールＥ’、およびパスワードＰ＿Ｕ’を提供するログイン要求６０６をクラウドサービス６に対して開始するとき６０４に開始する。

ログイン要求６０６を受信すると、クラウドサービス６は、対応するユーザカウントが存在するかどうか６１０をチェックし、存在しない場合はエラー６１２を返す。あるいは、対応するユーザカウントが存在する場合、クラウドサービス６は、データベース７内のユーザレコードを検索し、ユーザレコードからＳ＿Ｕを使用して、新しいダイジェスト６１４を作成する：
Ｄ＿Ｐ’＝＃（Ｓ＿Ｕ，Ｐ＿Ｕ’）

次に、クラウドサービス６は、新しいダイジェストがデータベース内のダイジェストと一致するかどうかを検証し、提供されたパスワードが正しいかどうかをチェックする６１６。提供されたパスワードが正しくない場合、クラウドサービス６はエラーメッセージ６１８を返す。あるいは、提供されたパスワードが正しい場合、クラウドサービス６は、ユーザＪＷＴを作成し６２０、将来のＡＰＩ呼び出しで使用するために、ユーザＪＷＴ６２２をユーザ６０２のブラウザまたはアプリに送信する。その後、クラウドサービス６は、ユーザＪＷＴスコープにユーザ６０ユーザと権限を記録する。

上述のユーザ登録プロセユーザと同様に、ＯＡｕｔｈ２または他の標準パターンを代わりに使用することもできる。

図７は、図示された第１および第２の実施形態においてユーザ・ロールが設定されることを可能にするために使用され得る詳細なユーザ・ロール設定プロセスの例示である。このプロセスは、上述したように、新しい組織またはテナントのために作成される最初のユーザが、その組織またはテナントの最初の管理者になることを想定している。

図７に示すユーザ・ロール設定プロセス７００では、プロセス７００は、図６に示すユーザのみ認証プロセス６００を使用してユーザ６０２が認証し、ユーザＪＷＴを取得したときに開始する。

次に、ユーザ６０２は、クラウドサービス６が、ユーザＪＷＴを渡して、ユーザＵの役割を指定された役割Ｒに設定することを要求７０２する。たとえば、ユーザ６０２は、クラウドサービス６がユーザＵの役割を「委託担当者」に設定することを要求することができる。

ユーザ認証プロセス６００からユーザＪＷＴが返されたことを条件として、クラウドサービス６は、次に、ユーザＪＷＴスコープが、ユーザ・ロールの設定を許可するスコープを含むかどうかをチェックする。これは、ユーザ６０２を管理者として識別するユーザＪＷＴスコープとみなすことができる。ユーザＪＷＴスコープがこのスコープを含んでいない場合、またはユーザＪＷＴが渡されなかった場合、クラウドサービス６は７０６エラーを返し、操作は終了する。あるいは、ユーザＪＷＴスコープがこのスコープを含む場合、クラウドサービス６は、ユーザＵのレコードを見つけ、ユーザ・ロールを指定されたロールユーザ・ロール。

その後、クラウドサービス６は、ユーザＵのユーザ・ロールが指定されたロールＲに設定されたことを確認する電子メール７１０を管理者ユーザ６０２に送信する。任意選択で、クラウドサービス６は、ユーザＵ、および任意選択で、同じ組織／テナント内の管理者ロールまたは監査ロールを持つ一部またはすべてのユーザに電子メール７１２を送信して、ロールの変更を通知し、変更を認識していない場合は変更を報告するよう要求することもできる。

上述のプロセス５００および６００と同様に、ＯＡｕｔｈ２または他の標準パターンを代わりに使用することもできる。

図８は、図示された第１および第２の実施形態で使用され得るワークフロー・ステップポリシー設定プロセスの例示である。

図８に示すワークフロー・ステップポリシー設定プロセス８００では、プロセス８００は、図６に示すユーザのみ認証プロセス６００を使用してユーザ６０２が認証し、ユーザＪＷＴを取得するときに開始する。

次に、ユーザ６０２は、クラウドサービス６がユーザＪＷＴを渡す指定されたワークフロー・ステップポリシーを作成または更新することを８０２に要求する。

ユーザ認証プロセス６００からユーザＪＷＴが返されたことを前提として、リクエスト８０２がワークフロー・ステップを作成することであった場合、クラウドサービス６は、次に、ユーザＪＷＴスコープがワークフロー・ステップの作成を許可するスコープを含むかどうかをチェックする。ユーザＪＷＴスコープがこのスコープを含まないか、またはユーザＪＷＴが渡されなかった場合、クラウドサービス６は８０６エラーを返し、操作は終了する。あるいは、リクエスト８０２がワークフロー・ステップを更新することであった場合、クラウドサービス６は、ユーザＪＷＴスコープがワークフロー・ステップの変更を許可するスコープを含むかどうかをチェックする。ユーザＪＷＴスコープがこのスコープを含まないか、またはユーザＪＷＴが渡されなかった場合、クラウドサービス６は８０６エラーを返し、操作は終了する。さらに、ユーザＵのレコードが見つからない場合、クラウドサービス６は７０６のエラーを返し、操作を終了すワークフロー・ステップあるいは、ユーザＪＷＴスコープが、要求されたワークフローステップの作成または更新のスコープを含む場合、クラウドサービス６は、要求された作成または更新されたワークフロー・ステップポリシーを格納する。

または、もしユーザーＪＷＴのスコープに、要求されたワークフローのステップの作成または更新が含まれているならば、クラウドサービス６には８１０、要求されて作成または更新されたワークフローのステップのポリシーが保存される。

次に、クラウドサービス６は、要求された変更がなされたことの確認を管理者ユーザ６０２に送信する。任意選択で、クラウドサービス６はまた、ユーザＵ、および任意選択で、同じ組織／テナント内の管理者ロールまたは監査ロールを有する一部またはすべてのユーザに、ワークフロー・ステップポリシーの変更を通知し、変更を認識しない場合は変更を報告するよう要求する電子メール８１４を送信することができる。

図９は、図示された第１及び第２の実施形態で使用され得るブートストラップ鍵注入プロセスの例示である。

ブートストラップ・キー注入プロセスを実行するためには、製造時点、例えば製造施設５で利用可能なワークフロー・ステップポリシーがなければならない。これは、デフォルトのワークフロー・ステップポリシーであってもよい。ワークフロー・ステップポリシーは、適切な権限を持つユーザによって後で上書きすることができる。このような権限付与及び役割管理が組織間でどのように実施されるかは、本明細書では規定しない。

図９に示すブートストラップ鍵注入プロセス９００において、プロセス９００は、製造施設５が、例えば製造施設５のブートストラップ・プロビジョニング端末において、ブートストラップ・ノンスＮ＿Ｂを生成９０２するときに開始する。

次に、製造施設５は、ローカルＯＧＲ２ａのＨＳＭ４ａからＱＫＤ鍵のＩＤ、ＩＤ＿Ｋを選択する９０４が、このＱＫＤ鍵は、クラウドサービス６に接続されたＯＧＲ２ｂとも共有される。

次に、ＭａｎｕｆａｃｔｕｒｉｎｇＦａｃｉｌｉｔｙ５は、９０４Ｎ＿ＢおよびＩＤ＿ＫをＯＧＲ２ａに接続されたＨＳＭ４ａに送信し、ブートストラップ鍵Ｋ＿Ｂの作成を依頼する。ＯＧＲ２ａのＨＳＭ４ａは、９０６Ｋ＿Ｂを作成する：
Ｋ＿Ｂ＝＃（ＳｅｌｅｃｔＫｅｙ（ＩＤ＿Ｋ），Ｎ＿Ｂ）

その後、ＯＧＲ２ａは、９０８Ｋ＿ＢをＭａｎｕｆａｃｔｕｒｉｎｇＦａｃｉｌｉｔｙ５に返戻する。

次に、ＭａｎｕｆａｃｔｕｒｉｎｇＦａｃｉｌｉｔｙは、以下のプロパティ、製造者ＩＤ、およびデバイスＩＤを有し、ブーストラップノンスＮ＿Ｂを渡す、新しいターゲット・デバイス８を９１０クラウドサービス６に通知する。いくつかの例では、追加のパラメータがあってもよいし、識別子は代わりに、例えば３２バイトの乱数やＩＭＥＩ番号のような、デバイスのための単純な保証された一意のＩＤであってもよい。

次に、クラウドサービスは、ターゲット・デバイスのレコード９１２を作成し、データベース７に少なくとも以下を格納する（サービス・プロバイダなど、必要に応じて他のフィールドを追加してもよい）：

さらに、クラウドサービス５は、レコードの委託署名フィールドをランダムなソルトに初期化し、９１６レコードの委託当事者フィールドを空に初期化する。

クラウドサービスは、ＭａｎｕｆａｃｔｕｒｉｎｇＦａｃｉｌｉｔｙ５に成功コードを返戻し、ＭａｎｉｆａｃｔｕｒｉｎｇＦａｃｉｌｉｔｙは、ターゲットデバイス８に以下のデータを注入する：

その後、ターゲット装置８は、８２２に注入９２０が行われたことの確認８２４をＭａｎｕｆａｃｔｕｒｉｎｇＦａｃｉｌｉｔｙ５に送信する。

上述のように、計算されたブートストラップ・キーをクラウド・サービス５のデータベース７に保存することは任意である。上記の例では、計算されたブートストラップ鍵は、ＨＳＭ４ｂが将来のブートストラップ鍵計算のためにＱＫＤ鍵を無期限に保持しなければならないことを回避するために（すなわち、各認証がブートストラップ鍵を新たに計算しなければならないことを回避するために）、データベース７に格納される。これにより、ブートストラップ・キーをデータベース攻撃者が読み取ることが可能になるため、潜在的な攻撃ベクトルが開放されるが、ＨＳＭ４ｂからＱＫＤキーを削除することで、ブートストラップ・キーに由来するターゲット・デバイス８が認証できなくなるという別の攻撃ベクトルも低減される。いくつかの例では、ブートストラップ・キーを保護するために、例えばテナント固有のＨＳＭに保存されたキーでラップしてデータベース７に保存することができる。別の例では、計算されたブートストラップ・キーはデータベース７に保存されず、各認証はＱＫＤキーからブートストラップ・キーを新たに計算する。

別のアプローチでは、ＱＫＤを使用してブートストラップ・キーを計算し、それをターゲット・デバイスに注入する代わりに、製造施設５または他の企業は、独自のブートストラップ・キーを生成してターゲット・デバイス８に注入し、このブートストラップ・キーまたはブートストラップ・キーのハッシュを、古典的に安全な、ポスト量子暗号的に安全な、量子的に安全な、または手動で安全なリンクを介してクラウドサービス５に登録することができる。その後、認証フローは、データベース７のブートストラップ・キー・フィールドに格納された、製造施設５のブートストラップ・キー、またはこのブートストラップ・キーのハッシュを、ノンスとＱＫＤキーとを組み合わせることによってＯＧＲ／ＨＳＭによって計算されたキーの代わりに、チェーンの最初のキーとして使用する。

上記の例は、第１の実施形態による衛星システム１００を参照して説明される。第２の実施形態による地上システム２００では、ＯＧＲ２ａは、地上トランシーバ９ａによって置き換えられる。

状況によっては、ターゲット装置８に関連するワークフロー・ステップポリシーを変更することが望ましい場合がある。上述したように、これは、例えば、デフォルトのワークフロー・ステップポリシーを使用してブートストラップキーがターゲット機器８に注入された場合に必要となる可能性がある。

認証プロセス６００を使用して認証され、クラウドサービス５が所定のターゲット・デバイス８に新しいワークフロー・ステップポリシーを関連付けることを要求するＪＷＴを取得したユーザによって、ワークフロー・ステップポリシーを変更することができる。次に、クラウドサービス５は、ＪＷＴスコープが、ターゲット・デバイス８に対してワークフロー・ステップを関連付けることを許可するスコープを含むことを確認する。次に、クラウドサービス５は、ターゲットデバイス８に関するレコードを検索し、ターゲットデバイス８に関するデバイスレコードを更新して、新しいワークフロー・ステップポリシーを指すようにし、ターゲットデバイス８に関するデバイスレコードのワークフローラチェットおよびワークフローコミッショニングレコードをゼロにする。任意選択で、クラウドサービス６は、ユーザ、および任意選択で管理者または監査ロールを有する一部またはすべてのユーザに電子メールを送信し、特定のターゲット・デバイス８に割り当てられたワークフローまたはポリシーの変更を通知し、変更を認識していない場合は変更を報告するよう要求することができる。

ターゲット・デバイス８のワークフロー・ステップを更新すると、すべてのラチェット・キーがゼロになるため、ターゲット・デバイス８は、初期化されていないブートストラップまたは工場出荷時の状態にリセットされ、ブートストラップ・キーのみが正常に認証できる状態になる。

図１０は、図示された第１および第２の実施形態において、ターゲット・デバイス１０をクラウド・システム６に認証するために使用され得る、詳細なターゲット・デバイス認証プロセスの例示である。

図１０に示すターゲットデバイス認証プロセス１０００では、プロセス１０００は、ターゲットデバイス８が何らかの外部刺激に応答して認証フロー１００２を開始するときに開始する。この外部刺激は、たとえば、ターゲット・デバイス８をクラウド・システム６に接続しようとするユーザ１００４であってもよいし、たとえば、ターゲット・デバイス８が起動し、認証フローを開始するブートローダを実行することであってもよい。ターゲットデバイス８は、チャターゲットデバイス、およびオプションとしてタイムスタンプＴ＿Ｄを作成し、クラウドサービス６に認証を要求し、以下の情報１００８を渡す：ＩＤ＿Ｍ、ＩＤ＿Ｄ、Ｃ＿Ｄ、Ｔ＿Ｄ。

認証要求の受信に応答して、クラウドサービス６は、ターゲットデバイス８に対応するデータベース７内のデバイスレコード１０１０を検索し、ターゲットデバイス８のブートストラップキーがデータベース７に格納されているか否かを判定する。

ブートストラップ・キーがデータベース７に格納されている場合、クラウドサービス６はブートストラップ・キーを回復する。あるいは、ブートストラップ・キーがデータベース７に格納されていない場合、クラウクラウドサービスデータベース７からＩＤ＿Ｋを回復し、Ｎ＿ＢおよびＩＤ＿Ｋを、クラウドサービス６のＯＧＲ２ｂに接続されたＨＳＭ４ｂに送信し、１０１４として、ブートストラップ・キーＫ＿Ｂを計算するようにＨＳＭ４ｂに要求する：
Ｋ＿Ｂ＝＃（ＳｅｌｅｃｔＫｅｙ（ＩＤ＿Ｋ），Ｎ＿Ｂ）

次に、ＨＳＭ４ｂは、要求されたブートストラップ・キーをクラウドサービス６に提供する。

データベース７内のデバイスレコードが、ターゲット・デバイス８がブートストラップ状態にあることを示す場合、キーＫは、１０１８ブートストラップ・キーＫ＿Ｂに設定される。あるいは、デバイスレコードが，ターゲット・デバイス８がブートストラップ状態にないことを示す場合、クラウドサービスは、ターゲットデバイスレコードのワークフローラチェット配列に格納されたキーラチェットをウォークスルーし、キーをラチェットして、１０２０キーＫを計算する：
Ｋ［０］＝＃ＴＫ＿Ｂ，Ｒ［０］）および
Ｋ［ｎ］＝＃（Ｋ［ｎ－１］，Ｒ［ｎ］）ｆｏｒｎ＝１ｔｏ（ワークフローステップインデックス－１），その結果として
Ｋ＝Ｋ［ｎ］

あるいは、ラチェットが単一の値Ｋ＿ＣＸ（下記参照）に折り畳まれている場合、キーＫは、１０２０のように計算することができる：
Ｋ＝Ｋ＿ＢＸＯＲＫ＿ＣＸ

その後、クラウドサービス６は、１０２２チャレンジコードＣ＿Ｃと、オプションとしてタイムスタンプＴ＿Ｃを作成し、１０２４チャレンジコードとタイムスタンプ（該当する場合）をターゲット・デバイス８に返戻する。クラウドサービス６は、クラウドサービスのＩＤであるＩＤ＿ＣＳをターゲット・デバイス８に返すこともある。

クラウドサービス６とターゲット・デバイス８がタイムスタンプを交換した場合、クラウドサービス６とターゲット・デバイス８の両方は、交換したタイムスタンプが所定の時間ウィンドウ内にあることを確認することができる。例えば、クラウドサービス６とターゲット装置８は、交換したタイムスタンプが互いに１秒以内であることを確認することができる。タイムスタンプが所定の時間ウィンドウ内にないと判断された場合、認証は拒否される。

次に、並行して、クラウドサービス６およびターゲット・デバイス８は、認証に使用すると予想される鍵Ｋを使用して、認証値１０２６ａおよび１０２６ｂを計算する：
Ｘ＿Ｄ＝＃ｆＫ，Ｃ＿Ｄ，０）
Ｘ＿Ｃ＝＃ｆＫ，Ｃ＿Ｃ，１）
Ｒ＿Ｄ＝＃（Ｘ＿ＤＣ＿Ｃ）
Ｒ＿Ｃ＝＃（Ｘ＿Ｃ，Ｃ＿Ｄ）
０と１は方向性を追加し、不正なサーバーが単にＣ＿ＤをＣ＿Ｃとして返し、Ｋ＿Ｓ＝（０，０，０，０，０，０，０，０，０，０．．．．．．）を導く場合、ミラー攻撃が起こり得ないことを保証する。

あるいは、クラウドサービス６およびターゲットデバイス８は、それぞれ（かつ並行して）、以下のプロセスに従って、認証に使用すると予想される鍵Ｋを使用して認証値１０２６ａおよび１０２６ｂを計算してもよい：
Ｎ＿Ｄ＝＃Ｃ＿Ｄ，ＩＤ＿Ｍ，ＩＤ＿Ｄ，Ｔ＿Ｄ）
Ｎ＿Ｃ＝＃（Ｃ＿Ｃ，ＩＤ＿ＣＳ，Ｔ＿Ｃ）
Ｘ＿Ｄ＝＃（Ｋ，Ｎ＿Ｄ，０）
Ｘ＿Ｃ＝＃（Ｋ，Ｎ＿Ｃ，１）
Ｒ＿Ｄ＝＃（Ｘ＿Ｄ，Ｎ＿Ｃ）
Ｒ＿Ｃ＝＃（Ｘ＿Ｃ，Ｎ＿Ｄ）

次に、ターゲット・デバイス８は、１０２８Ｒ＿Ｄをクラウドサービス６に送信する。クラウドサービス６は、ターゲット機器８から受信したＲ＿Ｄと、クラウドサービス６によって計算されたＲ＿Ｄとを比較し、ターゲット機器から受信したＲ＿Ｄがクラウドサービス６によって計算されたＲ＿Ｄと一致する場合、クラウドサービス６は、１０３０セッション鍵Ｋ＿Ｓを作成する：
Ｋ＿Ｓ＝Ｘ＿ＤＸＯＲＸ＿Ｃ

さらに、クラウドサービス６は、認証に使用される鍵に適切なスコープを持つ１０３２ＪＷＴを作成する。

その後、クラウドサービス６は、計算した１０３４Ｒ＿Ｃ、ＪＷＴ、およびクラウドサービス６のみが知っている鍵であるＫ＿ＣＳで暗号化されたセッション鍵を、すべてセッション鍵で暗号化してターゲット・デバイス８に返戻する。Ｋ＿ＣＳは、ＲＥＳＴｆｕｌＡＰＩを使用できるようにするために提供され、将来のＡＰＩ呼び出しでは、クラウドサービス６にキャッシュする必要がないように、暗号化されたセッションキーが渡される。Ｋ＿ＣＳとＲＥＳＴｆｕｌＡＰＩの使用は任意である。
Ｒ＿Ｃ，｛ＪＷＴ，｛Ｋ＿Ｓ｝Ｋ＿ＣＳ｝Ｋ＿Ｓ

次に、ターゲット装置８は、クラウドサービスから返されたＲ＿Ｃと、ターゲット装置８で計算されたＲ＿Ｃとを比較する。クラウドサービス６から返されたＲ＿Ｃが、ターゲット装置８で計算されたＲ＿Ｃと一致しない場合、ターゲット装置８は、ユーザ１００４にエラーメッセージ１０３６を表示する。あるいは、クラウドサービス６から返されたＲ＿Ｃがターゲット機器８で計算されたＲ＿Ｃと一致する場合、ターゲット機器８はローカルに計算された値からセッションキーＫ＿Ｓを計算する：
Ｋ＿Ｓ＝Ｘ＿ＤＸＯＲＸ＿Ｃ

その後、ターゲット・デバイス８は、クラウドサービスから受信したＪＷＴを復号化１０４０し、｛Ｋ＿Ｓ｝Ｋ＿ＣＳを復号化１０４２する。

その後、ターゲット・デバイスは、このセッションでさらにＡＰＩコールを行うときに、セッションキー、Ｋ＿Ｓ、ＪＷＴ、および｛Ｋ＿Ｓ｝Ｋ＿ＣＳを使用することができる。

あるいは、ターゲット・デバイス８から受信したＲ＿Ｄが、クラウドサービス６によって計算されたＲ＿Ｄと一致しない場合、クラウドサービス６は、ターゲット・デバイス８にエラーメッセージ１０４４を返戻する。

このエラーメッセージ１０４４に応答して、ターゲット・デバイス８は、鍵失効（工場出荷時リセット）プロセスが発生し、クラウドサービス６内のすべての鍵ラチェットが削除された可能性があるため、ブートストラップ鍵を使用して再度認証を試みるべきである。このさらなる認証の試みが失敗した場合、ターゲット・デバイス８は認証できず、失敗の監査とログが作成される。例えば、１時間以内に特定のＩＰアドレスから指定された回数（例えば３回）を超える認証の試行が行われないようにしたり、１時間以内に任意のＩＰアドレスからデバイスのさらなる認証の試行が行われないようにしたりするなど、さらなる防御策を採用することもできる。

オプションとして、ブートストラップキーではない認証キーで認証に成功すると、前方セキュリティを提供するために、ブートストラップキー（またはターゲットデバイスとクラウドサービスの両方が知っている他の値）を使用して、現在のラチェットキーを前方にラチェットすることができる：
Ｋ’＝＃（Ｋ＿Ｂ，Ｋ），ここで、Ｋは対象デバイス上のキーの配列における最新のキーであり、Ｋ＿Ｂはブートストラップ・キーである。

これが実行される例では、エラーメッセージ１０４４に応答して、ターゲット・デバイス８は、まず、認証後のラチェットがクラウドサービスでは成功したが、ターゲット・デバイスでは最後の認証で失敗した場合に、認証成功後に使用されたスキームと同等のスキームを使用して、最後のラチェットをラチェットフォワードした後に再度認証を試みるべきである。その後、この認証の試みも失敗した場合、ターゲット・デバイス８は、上述したように、ブートストラップ・キーを使用して再度認証を試みるべきである。

さらに、または代替的に、（ブートストラップ・キー自体が最初の認証に使用された場合）現在のラチェットを初期化するか、または以下のように置き換えることができる：
Ｋ＝＃（Ｘ＿Ｄ，Ｘ＿Ｃ），ブートストラップ・キーが最初の認証に使用された場合、Ｋはデータベースで初期化されたワークフロー・ラチェットもしくは、
Ｋ’＝＃（Ｋ，Ｘ＿Ｄ，Ｘ＿Ｃ），Ｋが、ワークフローステップインデックスに関連する現在のワークフローラチェットであり、Ｋ’はデータベース内のＫを置き換える場合。

図１１は、図示された第１および第２の実施形態において、ターゲット・デバイス１０をクラウドシステム６に登録するために使用され得る、詳細なターゲット・デバイス・エンロールメント・プロセスの例示的な例である。

図１１に示すターゲット・デバイス登録プロセス１１００では、プロセス１１００は、ユーザによって、または何らかの他の方法を介してトリガされる。ターゲット・デバイス８は、所有している最新のラチェット・キーを使用してデバイス認証プロセス１０００を実行する。クラウドサービス６は、ターゲット・デバイス８のワークフロー・ステップの連鎖における現在のワークフロー・ステップを定義する、ターゲット・デバイス８の状態を維持する。この状態は０から始まり、ターゲット・デバイス８による最初の登録ステップは、ターゲットデバイス８用のワークフロー・ステップポリシーで定義されたワークフロー・ステップのアレイの最初のワークフロー・ステップを使用することを意味する。

デバイス認証プロセス１０００から返戻されたＪＷＴが、クレーム「ｒｅｑｕｉｒｅｕｓｅｒａｕｔｈ」を含むか、またはクラウドサービス６が、ユーザ認証が必要であることをターゲット・デバイス８に通知するフラグを返す場合、ターゲット・デバイス８は、ユーザ１００４から１１０２ユーザ名およびパスワードを要求し、ユーザ１００４は、１１０４ユーザ名およびパスワードを提供する。いくつかの例では、パスワードの代わりに、またはパスワードに加えて、代替の認証方法が使用されてもよい。

次に、ターゲット・デバイス８は、クラウド・サービス６に対して、ターゲット・デバイス８を登録するように１１０６を要求し、要求１１０６は、セッション鍵、ＪＷＴ、および暗号化セッション鍵によって保護されたユーザ名とパスワード（必要な場合）を提供する：
｛Ｋ＿Ｓ｝Ｋ＿ＣＳ，｛ＪＷＴ｝Ｋ＿Ｓ，および任意で｛ＵＮ＿Ｕ’，Ｐ＿Ｕ’｝Ｋ＿Ｓ

次に、クラウドサービス６は、Ｋ＿ＣＳを使用してセッションキーを復号化および検証し、セッションキーが有効でない場合はエラーを返す。セッションキーが有効な場合、クラウドサービス６は、セッションキーを使用してＪＷＴを復号化および検証し、デバイスＪＷＴが有効でないか、ＡＰＩにアクセスするために必要なスコープを含んでいない場合、エラー１１０８を返戻する。

あるいは、セッションキーおよびデバイスＪＷＴが有効である場合、クラウドサービス６は、データベース７内のターゲット・デバイス８のレコードから、ターゲット・デバイス８用の１１１０ワークフロー・ステップポリシー、ワークフローラチェット、およびワークフローコミッショニングをロードし、ランダム・ソルトＳ＿Ｅを作成する。

次に、アクティブなワークフロー・ステップ（ワークフローステップインデックスによって定義される）がユーザ認証を必要とする場合、クラウドサービス６は、ユーザ名ＵＮ＿ＵおよびパスワードＰ＿Ｕを復号化する。次に、クラウドサービス６は、データベース７内のユーザレコード１１１４を検索し、Ｓ＿Ｕを使用してＰ＿Ｕから新しいダイジェストを作成する。次に、クラウドサービス６は、新しいダイジェストを使用して、新しいダイジェストがデータベース７内のダイジェストと一致するかどうかを１１１６検証することによって、パスワードが正しいかどうかをチェックする。

ダイジェストが一致しない場合、パスワードは不正であり、クラウドサービス６は１１１８エラーを返す。あるいは、ダイジェストが一致する場合、パスワードは正しく、クラウドサービス６は、ＰＢＫＤＦ２（Ｐ＿Ｕ’）または同等のものを使用して、ユーザ鍵Ｋ＿Ｕを復号化し、ラチェットＲを１１２２初期化する：
Ｒ＝＃（Ｋ＿Ｕ，Ｋ，Ｓ＿Ｅ）ここでＫはデバイス認証キーである。

その後、ユーザ名は、ワークフロー・ステップインデックスによって定義される、ターゲット・デバイス８の最新のワークフロー委託記録のユーザ認証フィールドに格納される。

あるいは、アクティブなワークフロー・ステップがユーザ認証を必要としない場合、ラチェットＲは１１２４初期化される：
Ｒ＝＃（Ｋ，Ｓ＿Ｅ）ここでＫはデバイス認証キーである。

ワークフロー・ステップポリシー内のアクティブなワークフロー・ステップが委託担当者の承認を必要とする場合、クラウドサービス６は、アクティブなステップ（ワークフロー・ステップインデックスによって定義される）の委託担当者の署名および委託担当者の関係者フィールドで識別される必要な署名が、そのステップのワークフロー・ステップポリシー内のものと一致することをチェックする。これらが一致しない場合、登録は失敗し、クラウドサービス６はエラー１１２６を送信し、適切な監査およびログが作成される。あるいは、アクティブなステップの委託担当者の署名および委託担当者の関係者フィールドが、そのステップのワークフロー・ステップポリシーのものと一致する場合、クラウドサービス６は、ラチェットＲを委託署名Ｓ＿Ｃと結合１１２８し、新しいラチェットＲ’を形成する：
Ｒ’＝＃（Ｒ，Ｓ＿Ｃ）

その後、クラウドサービス６は、前者のラチェット１１３０、Ｒ、または後者のラチェット、Ｒ’を、（ワークフロー・ステップインデックスによって定義される）現在のワークフローラチェット配列インデックスに適宜格納し、その後、デバイスのワークフロー・ステップインデックスをインクリメントして、ターゲット・デバイスを次の状態に遷移させる。

ワークフロー・ステップポリシー内のアクティブなワークフロー・ステップがユーザ認証と委託担当者の承認の両方を必要とする場合、クラウドサービス６は、ユーザパスワードと委託担当者の署名と委託担当者の当事者フィールドの両方の一致が確認されるまで、新しいラチェットの初期化に進まない。

オプションとして、以前のラチェットを秘匿できるようにするために、クラウドサービス６は、すべてのラチェットを単一の折りたたまれたＸＯＲ値、Ｋ＿ＣＸに折りたたむことができ、これは、次に、ブートストラップ・キーとＸＯＲされ、最新のラチェット・キーを形成する：
Ｋ＿ＣＸ＝＃（Ｋ，Ｒ）ＸＯＲＫ＿ＢここでＫはデバイス認証キーである
または、
Ｋ＿ＣＸ＝＃（Ｋ，Ｒ’）ＸＯＲＫＢここでＫはデバイス認証キーである
そしてその後、次の認証に使用される最新のラチェット・キーは単純にこうなる：
ＫＲ＝Ｋ＿ＢＸＯＲＫ＿ＣＸ

いずれの場合も、クラウド・サービス６は、セッション鍵によって暗号化された新しいラチェットＲまたはＲ’をターゲット・デバイス８に１１３２を返戻する：
｛Ｒ｝Ｋ＿Ｓｏｒ｛Ｒ’｝Ｋ＿Ｓ

その後、ターゲット・デバイス８は、セッション鍵を使用してＲまたはＲ’を復号し、ＲまたはＲ’を使用して、保持している最新のラチェット鍵Ｋ＿Ｒから１１３４最新のラチェット鍵Ｋ＿Ｒ’を計算する：
Ｋ＿Ｒ’＝＃（Ｋ＿Ｒ，Ｒ）ｏｒ
Ｋ＿Ｒ’＝＃ｆＫ＿Ｒ，Ｒ’）

その後、ターゲット機器８は、Ｋ＿Ｒ’をターゲット機器８に保持されている鍵の配列に追加し、今後はこの鍵を認証に使用し、ターゲット機器は、ＯＫメッセージ１１３６をユーザ１００４に返す。

図１２は、図示された第１および第２の実施形態においてワークフローのステップを承認するために使用され得るコミッショナー承認プロセスの例示的な例である。

図１２に示されるコミッショナー承認プロセス１２００において、プロセス１２００は、上記に規定されたプロセスによって以前に認可された制御装置１２０４を使用する委託役割ユーザ１２０２によってトリガーされる。この制御装置１２０４は、制御装置ＪＷＴを取得するために、所有している最新のラチェット鍵を使用して装置認証プロセス１０００を実行する。

制御装置１２０４は、コミッショニング・ユーザ１２０２から１２０６ユーザ名とパスワードを要求し、コミッショニング・ユーザ１２０２は、１２０８ユーザ名とパスワードを制御装置１２０４に提供する。いくつかの例では、パスワードの代わりに、またはパスワードに加えて、代替の認証方法が使用されてもよい。

任意に、制御装置１２０４は、いくらかのエントロピーＥを提供することができる；これは、例えば、制御装置１２０４内の加速度計がいくらかのエントロピーを生成する間、委託者１２０２が制御装置１２０４を数秒間振ることによって、または委託者１２０２が制御装置１２０４のスクリーン上に何かを描くことによって、または制御装置が乱数発生器（ＲＮＧ）、あるいはＯＧＲ２からエントロピーを取ることによって行われ得る。

制御デバイス１２０４は、デバイス認証プロセス１０００の間に計算されたセッションキーＫ＿Ｓを取得し、セッションキーによって暗号化された制御デバイスＪＷＴと、やはりセッションキーによって暗号化されたターゲットデバイス識別子ＩＤ＿ＭおよびＩＤ＿Ｄと、ユーザ名ＵＮ＿Ｕ’およびパスワードＰ＿Ｕ’とを渡して、クラウドサービス６が所定のデバイスの次の登録状態を承認する１２１２を要求する。
｛Ｋ＿Ｓ｝Ｋ＿ＣＳ，｛ＪＷＴ｝Ｋ＿Ｓ，｛ＵＮ＿Ｕ’，Ｐ＿Ｕ’，ＩＤ＿Ｍ，ＩＤ＿Ｄ｝Ｋ＿Ｓ，ｏｒ
｛Ｋ＿Ｓ｝Ｋ＿ＣＳ，｛ＪＷＴ｝Ｋ＿Ｓ，｛ＵＮ＿Ｕ’，Ｐ＿Ｕ’，ＩＤ＿Ｍ，ＩＤ＿Ｄ，Ｅ｝Ｋ＿Ｓ，エントロピーが提供されている場合

次に、クラウドサービス６は、Ｋ＿ＣＳを使用してセッションキーを復号化および検証し、制御デバイスＪＷＴを復号化および１２１４検証し、制御デバイスＪＷＴが有効でない場合、またはこの関数に許可を与えるスコープを含まない場合、エラー１２１６を返す。

あるいは、セッションキーおよび制御デバイスＪＷＴが有効である場合、クラウドサービス６は、１２１８ユーザ名ＵＮ＿Ｕ’、パスワードＰ＿Ｕ’、およびオプションとしてエントロピーＥを復号化する。次いで、クラウドサービス６は、１２２０ユーザレコードを検索し、Ｓ＿Ｕを使用して新しいダイジェストを作成する：
ＤＰ’＝＃（Ｓ＿Ｕ，Ｐ＿Ｕ’）

次に、クラウドサービス６は、新しいダイジェストを使用して、新しいダイジェストがデータベース内のものと一致すること、およびユーザ役割がコミッショナーであることを１２２２チェックすることによって、パスワードが正しいかどうかをチェックし、一致しない場合、クラウドサービス６は１２２４エラーを返戻し、操作は終了する（監査およびログが作成される）。

あるいは、新しいダイジェストがデータベース内のものと一致し、ユーザの役割がコミッショナーである場合、クラウドサービス６は、ＰＢＫＤＦ２（Ｐ＿Ｕ’）または同等のものを使用して、ユーザ鍵Ｋ＿Ｕを１２２６復号化する。次に、クラウドサービス６は、指定されたターゲット・デバイス８の現在のワークフロー・ステップ承認レコード（ワークフロー・ステップインデックスによって定義される）１２２８を探し出し、そのレコードから１２３０コミッショニングソルトＳ＿Ｃをロードする。次に、クラウドサービス６は、コミッショニングソルトＳ＿ＣをＫ＿Ｕで暗号化、署名またはハッシュ化し、オプションとして、デバイスＩＤ、ワークフロー・ステップＩＤ＿Ｗ、現在時刻、および必要に応じて他のデータを含み、その結果をそのレコードのコミッショニング担当者署名フィールドに１２３２格納する：
Ｓ／Ｇ＝｛Ｓ＿Ｃ｝Ｋ＿Ｕｏｒ｛Ｓ＿Ｃ，ＩＤ＿Ｍ，ＩＤ＿Ｄ，ＩＤ＿Ｗ，ＴＩＭＥ｝Ｋ＿Ｕ

あるいは、エントロピーが提供される場合、クラウドサービス６は、指定されたターゲット・デバイス８の現在のワークフローステップ承認レコード（ワークフローステップインデックスによって定義される）を検索し、委託塩Ｓ＿Ｃをエントロピーで暗号化し、署名し、またはハッシュ化し、任意選択で上記に規定されるようなさらなるデータを含み、その結果をそのレコードの委託担当者署名フィールドに格納する。
Ｓ／Ｇ＝｛Ｓ＿Ｃ，Ｅ｝Ｋ＿Ｕ，ｏｒ｛Ｓ＿Ｃ，Ｅ，ＩＤ＿Ｍ，ＩＤ＿Ｄ，ＩＤ＿Ｗ，ＴＩＭＥ｝Ｋ＿Ｕ

クラウドサービス６は、ユーザ名１２３４をそのレコードの委託先フィールドに追加し、１２３６ＯＫメッセージを制御装置１２０４に返し、制御装置１２０４は、１２３８ＯＫメッセージをユーザ１２０２に表示する。

図１２を参照して説明したプロセス１２００は、「ＡＮＤ」ポリシーであり、ワークフローのステップを承認するためには、指定されたすべての委託担当者が署名しなければならない。いくつかの代替例では、異なる承認ポリシーが使用されてもよい。代替ポリシーとしては“ＯＲ”ポリシーが可能なタイプと考えられるが、そうすると、あらかじめ指名されたコミッショニング（性能検証）担当者のうち１人の承認のみが必要となる。または、より複雑なポリシーではあるが、あらかじめ指名されたコミッショニング担当者のうち“少なくとも＜ｎ＞人”による承認を必要とすることも可能である。さらには、あらかじめ指名された承認権限を持つ複数人のコミッショニング担当者がアクティブディレクトリ内または他のディレクトリサービス内で定義された１つのグループとなるような例もある。こうすると、人事異動の際など、コミッショニング担当者で構成されるグループのメンバーを変更することが簡単になる。

図１３は、ターゲットデバイス１０をブートストラップに戻すために使用する詳細な鍵リボケーションプロセスの実例であり、第１と第２の実施形態で図示されている。これを工場出荷時リセットとも呼ぶ。

図１３では鍵リボケーションプロセス１３００を示している。プロセス１３００は、管理者ユーザ１３０２が図６に示されているユーザ限定の認証プロセス６００を用いてユーザＪＷＴを取得し認証すると、開始する。

次に、ユーザ１３０２は１３０４に対して、クラウドサービス６がユーザＪＷＴをパスする証明ＩＤを有する特定のターゲットデバイス８からキーをリボークする（取り消す）よう要求する。

クラウドサービス６は、ユーザＪＷＴが有効であるか、そしてそのユーザが管理者であることを確認するスコープを含んでいるかどうかを確認する。そのユーザＪＷＴが無効である場合、またはそのユーザが管理者であると確認できなかった場合は、クラウドサービス６は１３０８でエラーを返し、オペレーションは終了する（そして監査ログが作成される）。

あるいは、ユーザＪＷＴが有効であり、そのユーザが管理者であると確認するスコープを含んでいる場合、クラウドサービス６はデータベース７内のＩＤによってターゲットデバイス８のデバイスレコードを検索し、１３１８でワークフロー・ラチェット値をリセットまたはクリアする。さらに、クラウドサービス６は１３２０でワークフローコミッショニングをリセットまたはクリアし、ワークフローステップのインデックスをゼロに設定する。

クラウドサービス６は１３２２にＯＫを返し、監査ログが作成される。

オプションとして、クラウドサービス６は新しいノンスＮ＿Ｂを生成することができる。この新しいノンスＮ＿Ｂは、ＱＫＤ鍵（量子暗号通信鍵）と共に新しいブートストラップ鍵を計算することに用いられ、一時的にメモリー／キャッシュに保持される。そして、クラウドサービス６はターゲットデバイス８に対して全てのキーがリボークされていると通知することが可能となり、ターゲットデバイス８は現在のブートストラップ鍵を用いてクラウドサービス６を認証し、新しいブートストラップ鍵へのアクセスを要求する。ターゲットデバイス８が新しいブートストラップ鍵を受け取ったことを確認すると、新しいノンスＮ＿Ｂがデータベース内に記憶され、古いノンスは上書きされる。ターゲットデバイス８に接触できない場合は、古いブートストラップ鍵をそのまま残しておく必要がある。

上述の実施形態から、最後の暗号鍵が対称暗号鍵であり、セッション鍵のネゴシエーションや他の目的のために、クラウドサービス６によるターゲットデバイス８の認証を可能とするための共有秘密鍵として、ターゲットデバイス８とクラウドサービス６が使用できるということが理解できるだろう。最後の暗号鍵はＡＥ２５６対称鍵でもよい。

図１４は、本発明の第３の実施形態に従った、トラストレス（管理者による承認を必要としない）鍵プロビジョニング・システム１４００の一例の概要を示す回路図である。本発明の第３の実施形態は、ブートストラップ対称鍵をキーフィルすることを意図したものであり、ＳＩＭカードを含むコンピューティングデバイス上でＳＩＭカード内に存在するシークレットを使用することによって、ＲｏＴとしての機能を果たすことができる。このＳＩＭカードは、ネットワーク事業者またはその他当事者にも知られているものである。第１と第２の実施形態と同様に、このキーフィルは部分的または全体的に自律的処理が可能なプロセスを通じて行われ、そこではサポートするクラウドサービス、全ての人的行為者、および全ての者は、対称鍵へのアクセスを入手することが不可能である。

図１４に示すように、製造施設１４０１はＳＩＭ１４０２を製造し、続いてコンピューティングデバイス１４０３に組み込まれる。コンピューティングデバイス１４０３は、スマートフォンやその他の類の伝達機能を有するデバイスであってもよい。各々のＳＩＭ１４０２にはアクセス不可能な多数の対称暗号鍵が含まれており、それらは製造施設１４０１がＳＩＭ１４０２を製造する際にＳＩＭカード１４０２に埋め込まれる。通常は、これらのアクセス不可能な対称暗号鍵は「プリ・パーソナライゼーション」と呼ばれる初期化レイヤーの間にＳＩＭにロードされ、その後により高度なレベルの初期化によってアクセスをロックダウンするものである。アクセス不可能な対称暗号鍵は、通常はＯＴＡ鍵と認証キーＫで構成されるが、さらにＰＩＮとＰＵＫキーで構成されることもある。

埋め込まれた対称暗号鍵は特に、モバイルネットワーク事業者（ＭＮＯ）１４０４が運営しているワイヤレス通信ネットワークへのＳＩＭのアクセスを認証するために、ＭＮＯ１４０４が使用する。その結果、ＳＩＭ認証に使用される埋め込まれた対称暗号鍵は少なくとも、製造施設１４０１およびＭＮＯ１４０４の両方がある時点で使用可能でなければならないことが分かるだろう。通常は、製造施設１４０１がＭＮＯ１４０４のためにＳＩＭ１４０２のバッチを生成すると、製造施設１４０１（または製造施設１４０１と連携して運用を行うＳＩＭ事業者）が、ＳＩＭ１４０２用の暗号鍵を含んだ１４０５プリ・パーソナライゼーション・データを、例えばＶＰＮ経由など安全な方法でＭＮＯ１４０４に送信する。次に、製造施設１４０１および／またはＳＩＭ事業者はプリ・パーソナライゼーション・データを記録から削除する。通常のＳＩＭプロビジョニング・プロセスを実行するためには、製造施設１４０１とＭＮＯ１４０４が、ＳＩＭ１４０２にロードされた対称鍵の安全な受け渡しができる手段を有していなければならないことが分かるだろう。

第３の実施形態では、ＳＩＭ１４０２に埋め込まれた鍵の１つから生成されるデータ１４０６を、ＭＮＯ１４０４がクラウドサービス６に安全なチャネル経由で送信する。この安全なチャネルとは、第１および第２の実施形態のクラウドサービス６に対応するものである。ＭＮＯ１４０４が、クラウドサービス６に安全な量子通信を提供するセキュアノードを備えてもよい。

いくつかの例では、生成されたデータはＳＩＭ１４０２上のアクセス不可能な対称鍵の１つのハッシュ、またはハッシュで多様化されたラチェットである場合がある。他の例では、ＯＴＡ鍵や認証キーなどのＳＩＭ１４０２上のアクセス不可能な対称秘密鍵の１つを用いて固定または動的なデータの一部に署名して導出データが生成され、任意で結果をハッシュ化する場合もある。アクセス不可能な対称鍵から導出データを導き出すために、代替的および／または追加的なプロセスが使用される場合があり、同じ導出データを計算するために、ターゲットデバイス上でも同じ関数が適用されることが理解できるだろう。他の例では、導出データは認証キーから導き出される場合がある。ＳＩＭ１４０２製造中のいかなるポイントであっても、ＳＩＭ１４０２上に安全にロードされた対称鍵は全て、導出データの土台として使用される可能性がある。

クラウドサービス６は、受け取った導出データをデータベース７内に格納する。このデータベース７とは、第１および第２実施形態のデータベース７に相当する。

図１５は、第３の実施形態に従って鍵プロビジョニング・システム１４００が実行する鍵プロビジョニング・プロセス１５００の全般的なワークフロー概要を示している。

図１５に示すように、各ＳＩＭ１４０２に対して、ＳＩＭ１４０２上にロード済みのアクセス不可能な対称鍵から鍵プロビジョニング・プロセス１５００が開始する。このアクセス不可能な対称鍵は、製造施設１４０１での製造過程で既にＳＩＭ１４０２上にロード済みである。続いて、ＭＮＯ１４も同じく自身のデータベース内にアクセス不可能な対称鍵を保持しているので、定義済みの導出オペレーション１５０２を実行し、アクセス不可能な対称鍵から導出データ１５０４を導出する。前述の通り、アクセス不可能な鍵のハッシュを生成、またはアクセス不可能な鍵を用いてデータの一部の署名し、場合によっては任意のハッシュ化オペレーションを実行することから、導出オペレーションが構成される。

次にＭＮＯ１４０４は、安全なチャネルを介してクラウドサービス６に、１５０６で導出データ１５０４をプロビジョニングする。この時、クラウドサービス６との安全な通信を実行するために、場合によってはセキュアノードを使用する。プロビジョニング１５０６を実行するために、ＭＮＯ１４０４がクラウドサービス６に、例えばセキュアノードを使用するなどして、導出データ１５０４がＳＩＭ１４０２と紐づいていることを通知する。クラウドサービス６は、ＭＮＯ１４０４によって提供された導出データをデータベース７内に格納する。

プロセス１５００は、第１および第２実施形態で使用されたプロセス３００と同じように動作し、そこで導出されたデータはプロセス３００のブートストラップ鍵として、またはブートストラップ鍵の代わりとして使用される。ブートストラップ鍵として使用された導出データは、ＳＩＭ１４０２上に記憶されているキーから導出されたものである。したがって、ＳＩＭ１４０２は必要な時にオンデマンドで、記憶されているキーからブートストラップ鍵を再生成することが可能である。例えば、記憶されているキーのハッシュを繰り返す、または同じデータの署名を繰り返す、場合によっては任意のハッシュを使用するなどの方法によって、ブートストラップ鍵をコンピューティングデバイス１４０３に提供することができる。よって、ＳＩＭ１４０２にサポートされているコンピューティングデバイス１４０３は、認証フローを実行して、ブートストラップ鍵および必要に応じてブートストラップ鍵からラチェットされた後続キーを生成することが可能である。同様に、クラウドサービス６はデータベース７内に格納されている導出データをブートストラップ鍵として保持しているので、クラウドサービス６はブートストラップ鍵および必要に応じてブートストラップ鍵からラチェットされた後続キーを用いて、認証フローを実行することが可能である。

鍵プロビジョニング・プロセス１５００は、導出データをクラウドサービス６に安全に提供する。上述の通り、ＳＩＭ１４０２による導出データが既にコンピューティングデバイス１４０３で使用可能である。したがって、コンピューティングデバイス１４０３およびクラウドサービス６は、導出データ（または導出データから導出されたデータ）を対称鍵のペアとして使用し、これら２つの鍵（すなわち、同じ対称鍵／導出データの２つの複製）をラチェットして同一のステップへと進ませ、その各々がラチェット・オペレーションを構成する。クラウドサービス６とデバイス１４０３のどちらの環境においても、同一のキーに到達することとなる。各ステップにおいて、スタート鍵はラチェット・オペレーションによって別の新しい、または生成されたキーへと変換される。これらの最終的に同一となるキーは、ＲｏＴとして動作する対称鍵としての使用が可能となり、クラウドサービス６とデバイス１４０３間の量子コンピューティングによる安全な通信の実行、または他のいかなる希望するタスクに使用することができる。したがって、鍵プロビジョニング・プロセス１５００は２つに分岐しており、それらが平行して実行され、第１の分岐１５００ａは図１５では上部分岐となり、デバイス１４０３を実行、第２の分岐１５００ｂは図１５で下部分岐となり、クラウドサービス６を実行する。

第３の実施形態の図例では、導出データは対称暗号鍵から導出されている。他の例では、一般的には、導出データはいかなる形式の共有秘密データから導出されるものであり、共有暗号鍵または共有暗号鍵の土台として使用することができる。

この鍵は、鍵プロビジョニング・プロセス１５００の各分岐１５００ａ、１５００ｂにおいて、デバイス１４０３にクラウドサービス６への認証を与える認証キーとして使用することができ、その後にチェーン内の次のキーを生成する。最終的なキーは、例えばセッション鍵の生成またはその他の目的のためなど、引き続き認証に使用することができる。

ワークフローはポリシーによって定義されるので、デバイスまたはデバイスのグループに対して異なるポリシーを割り当てることによって、状況に応じた異なるワークフローを定義することができる。これは、上記の第１および第２の実施形態に関して詳述した方法と同様である。

第３の実施形態にしたがって、鍵プロビジョニング・プロセス１５００は以下のような多数の目的を有している。ポリシーを使用して、将来の鍵ネゴシエーション・タスク（例えば、他のデバイスとのセッション鍵のネゴシエーション）または他の目的に備えて、デバイス１４０３がクラウドサービス６を認証する際に用いるキーチェーンを定義するワークフローステップのシーケンスを定義すること。各ステップにユーザ認証および／またはコミッショニング担当者の承認が必要かどうかを定義するためのワークフローステップ・ポリシーに、デバイス１４０３を関連付けること。デバイス１４０３のＳＩＭ１４０２上に記憶されている対称鍵から算出された導出データがブートストラップ鍵としてデバイス１４０３上に存在しているので、そのデバイス１４０３上のブートストラップ鍵をプロビジョニングすること。そして、製造施設１４０１またはＭＮＯ１４０４が、古典的またはポスト量子暗号的に安全確保された方法によって、または物理学的メカニズムによって、ブートストラップ鍵／導出データをクラウドサービス６へと送信すると、デバイス１４０３とクラウドサービス６間での古典的通信チャネルを介した送信中にブートストラップ鍵が傍受されることは確実に不可能となる。ブートストラップ鍵を使用して、デバイス１４０３によるクラウドサービス６への接触を可能にし、定義済みポリシーに準拠したラチェットメカニズムを用いて新たな認証キーへ移行すること。その後、最新のラチェット鍵を用いてデバイス１４０３によるクラウドサービス６への接触を可能にし、定義済みポリシーに準拠したラチェットメカニズムを用いて新たな認証キーへ移行すること。

第３の実施形態にしたがった図１５の鍵プロビジョニング・プロセス１５００の概要は、以下の通りである。鍵プロビジョニング・プロセス１５００および／またはシステム１４００が実行するオペレーションは全て、上述の実施形態と同様の方法で、検証可能な量子セキュア・ハッシュチェーンを用いて安全に、ログおよび／または監査されることとなる。

鍵プロビジョニング・プロセス１５００の実行前に、システム１４００のユーザがクラウドサービス６にサインナップまたは登録を行い、上述の実施形態と同様の方法で役割が割り当てられる。

図１５を参照すると、システム１４００は非サイクル型のステートマシンを提供している。このステートマシンの中で、責任管理者が一連のワークフローステップを特定することができ、それによって鍵プロビジョニング・プロセス１５００の分岐１５００ａ、１５００ｂを形成する鍵ラチェット・パイプラインが定義される。上述の実施形態と同様に、図１５で鍵プロビジョニング・プロセス１５００がデバイス１４０３のために実行可能となる前に、責任管理者（たち）はワークフローステップ・ポリシーを定義して１つ以上のワークフローステップを定義付ける必要がある。したがって、鍵プロビジョニング・プロセス１５００のワークフロー内にある一連のステップを定義することによって、定義付けされたワークフローステップ・ポリシーがクラウドサービス６のデータベース７内に格納される。さらに、個々のワークフローステップについても定義が必要であり、これらの定義付けされたワークフローステップもクラウドサービス６のデータベース７内に格納される。

簡潔かつ明確にするために、単一のワークフロー・ポリシーに従っての単一のデバイス１４０３によるキーフィリングについて、本書では説明する。システム１４００を使用している異なる組織によって異なるワークフロー・ポリシーが設定される可能性があること、そして各組織が異なるデバイス１４０３またはデバイス１４０３のグループ用に複数の異なるワークフロー・ポリシーを有する可能性があることが分かるだろう。

図１５に示す通り、各デバイス１４０３に関して、デバイス１４０３のＳＩＭ１４０２に記憶されており、ＭＮＯ１４０４が知っている対称鍵からデバイス１４０３用のブートストラップ鍵として使用される導出データ１５０３を１５０２で導出する。そして、この導出データ／ブートストラップ鍵１５０３をクラウドサービス６に提供することで、鍵プロビジョニング・プロセス１５００が開始される。さらに、プロビジョニング１５０６の一部として、ＭＮＯ１４０４は、例えばデバイスＩＤおよび／または製造業者および／またはＳＩＭＩＤなどの、デバイス１４０３および／またはＳＩＭ１４０２に関連するメタデータを、クラウドサービス６に対して通知する。上述したように、対称暗号鍵から導出する代わりに、ブートストラップ鍵として使用される導出データはいかなる形式の共有秘密データから導出することができる。この共有秘密データとは共有暗号鍵、または共有暗号鍵の土台として使用することができるものである。鍵プロビジョニング・プロセス１５００はデバイス１４０３およびＳＩＭ１４０２の寿命内であればいつでも開始することができ、ＳＩＭ１４０２の製造中やその付近で実行しなければならないという要件はない。

クラウドサービス６は、ＭＮＯ１４０４から提供された導出データ／ブートストラップ鍵をクラウドサービス６のＨＳＭに記憶している。導出データ／ブートストラップ鍵はＳＩＭ１４０２上に記憶されている対称鍵から導出されるので、ＳＩＭ１４０２ブートストラップ鍵を導出し、デバイス１４０３からブートストラップ鍵が要求された時にオンデマンドで、デバイス１４０３に提供することができる。

上述の実施形態と同様に、プロビジョニング１５０６の一部として、クラウドサービス６はデータベース７内にデバイス１４０３向けのデバイスレコードを生成する。このデバイスレコードは、関連する管理者（たち）および／またはＭＮＯ１４０４および／または製造施設１４０１によってデバイス１４０３用に選定されたワークフロー・ポリシーの複製を保管、またはそのワークフロー・ポリシーに接続する。さらに、クラウドサービス６はデバイス１４０３のコミッショニング署名フィールドとコミッショニング関係者フィールドをゼロへと初期化し、そのデバイス１４０３でコミッショニング担当者の承認を必要とする各ワークフローステップでの使用に備えて、ランダムなコミッショニングソルトを生成して保管する。

クラウドサービス６は、ワークフローステート・ブートストラップ１５０８で、デバイス１４０３のためにデータベース７内のデバイスレコードを初期化する。さらに、デバイス１４０３が初めてクラウドサービス６を認証しようとする時に、デバイス１４０３はＳＩＭ１４０２上に記憶されている対称鍵からＳＩＭ１４０２によって導出された導出データ／ブートストラップ鍵を使用して、既知のステートであるブートストラップ１５０４から開始する。

したがって、デバイス１５０３のワークフローステートは、既知のステートであるブートストラップ１５０４から開始することとなり、クラウドサービス６内のデバイス１５０３に関するデバイスレコードのワークフローステートは対応する既知のステートであるブートストラップ１５０８となる。デバイス１５０３に割り当てられたワークフローステップ・ポリシーに定義された通りに次のワークフローステートの要件が満たされれば、デバイス１５０３は次のワークフローステートへと移行することができる。ブートストラップ鍵は、クラウドサービスＡＰＩセットへのアクセスを限定的に許可する。

システム１４００は、ブートストラップ鍵またはブートストラップ鍵からラチェットしたキーのいずれかを使用して、デバイス１４０３がクラウドサービス６を認証するための手段を提供する。その都度、クラウドサービス６は当初の導出データから認証に必要なキーチェーンを構築するが、これはブートストラップ鍵を生成するためにＨＳＭに保管されている可能性がある。ブートストラップ鍵を土台とする後続のキーは、データベース７内で保有されている記憶されたラチェット値を用いて、クラウドサービス６によって算出することができる。ブートストラップ鍵、または、そのブートストラップ鍵にラチェットされたキーのいずれかを用いて、デバイス１４０３がクラウドサービス６に対して認証されると、クラウドサービス６は、例えばジェイソン・ウェブ・トークン（ＪＷＴ）のようにワークフローステップによってスコープが定義されるようなトークンを、デバイス１４０３に対して返す。クラウドサービス６によるデバイス１４０３の認証には、チャレンジ・レスポンスを使用して現在のキー（ブートストラップ鍵、または、そのブートストラップ鍵からラチェットされたキー）と、デバイス１４０３とクラウドサービス６間で交換し、その後破棄されることとなる２つのチャレンジコードの組み合わせから、セッション鍵を生成する。

クラウドサービス６は、上述の実施形態と同様に、デバイス１４０３のクライアントステートＫ＿ＣＳを暗号化するキーを使用して、ＲＥＳＴｆｕｌＡＰＩｓを許可する。

ターゲットデバイス８を移行させるために、ワークフローステップにコミッショニング担当者の承認が必要な場合、上述の実施形態について説明したものと同様のプロセスが使用される。

ブートストラップ鍵またはそのブートストラップ鍵からラチェットされたキーを用いて、デバイス１４０３のクラウドサービス６に対する認証が適切に実行されると、デバイス１４０３はクラウドサービス６からＪＷＴのような認証トークンを受信し、クラウドサービス６との間でセッション鍵をネゴシエーションする。デバイス１４０３のユーザは、クラウドサービス６とデバイス１４０３のプロビジョニング・プロセスを開始することができる。

デバイス１４０３をクラウドサービス６に登録するために、デバイス１４０３はプロビジョニング関数を呼び出し、認証トークンと（任意で）ワークフローステップに要求される場合はユーザ・クレデンシャル情報を渡す。任意でパスワードを用いて、任意で２ファクタ認証（２ＦＡ）を用いて、クラウドサービス６はユーザを認証することができる。トークン受信に対する応答として、任意で選択したユーザ認証が成功した場合、クラウドサービス６はランダムなデータをいくつか生成し、これを使用してラチェット値を作成する。このラチェット値は、現在の最新ラチェット鍵を次のラチェット鍵へとラチェットするのに用いる。そして、この値をデバイス１４０３に関連付けられたラチェット値の配列内のデータベース７内に格納する。任意で、現在のデバイス１４０３のワークフローステップがコミッショニング担当者の承認を必要とし、その必要とされる承認がそのワークフローステップに関連付けられたコミッショニング署名フィールドに保管されている場合、コミッショニング署名リストはワークフローステップのラチェット値と組み合わされる。このラチェット値が、一連のラチェット値の中で最新のものとして使用され、保存された導出データから将来的にオンデマンドで新たな認証キーを算出するのに使用することができる。

それから、クラウドサービス６はデバイス１４０３に対してラチェット値を返し、ターゲットデバイス１４０３もその一連のラチェット値内での最新のキーから新たなラチェット値を作成し、新たな認証キーを作成できるようにする。したがって、新たなラチェット値は、最初の登録時は導出データ／ブートストラップ鍵から、それ以降の登録時には前回の登録時に作成されたキーから、作成される。

図１５に示す通り、デバイス１４０３がブートストラップ・ステート１５０４の状態にあるとき、鍵プロビジョニング・プロセス１５００は、クラウドサービス６を認証し登録するデバイス１４０３のユーザによって、上述の認証およびプロビジョニング・プロセスを用いて継続して実行される。認証およびプロビジョニング・プロセスが成功し、デバイス１４０３に適用されているワークフローステップ・ポリシーの次のワークフローステップによって必要であると識別されたコミッショニング担当者の承認が受信された場合、クラウドサービス６は上述のラチェット値を生成し、そのラチェット値を用いてブートストラップ鍵からラチェット認証鍵を作り出す。そして、クラウドサービス６は、データベース７内のデバイスレコードにあるデバイス１４０３のステータスをブートストラップ・ステート１５０８から次のワークフローステート、図１５の例だと「検疫（クアランティン）」という名称の中間ステート１５１２へと、１５１０でラチェットフォワードする（ラチェットで前方へ進める）。

次に、または同時に、クラウドサービス６は、そのラチェット値をデバイス１４０３に送信し、デバイス１４０３はブートストラップ鍵から同じラチェット認証鍵を作成する。これは上述したように対称鍵を用いて事前に作成されていたものであり、ターゲットデバイス８はそのステータスをブートストラップ・ステート１５０４から次のワークフローステート、例えば図３の例だと「検疫（クアランティン）」という名称の中間ステート１５１６へと、１５１４でラチェットフォワードする（ラチェットで前方へ進める）。

図１５の例において、デバイス１４０３が中間ステート「検疫（クアランティン）」１５１６にあり、データベース７内のデバイスレコードのデバイス１４０３のステータスも中間ステート「検疫（クアランティン）」１５１０にある場合、デバイス１４０３がクラウドサービス６への認証および登録を無事に完了していれば、デバイス１４０３はクラウドサービス６によって、システムおよびネットワークへの限定的な接続が与えられる。この限定的な接続性を選択したのは、デバイス１４０３が中間ステート「検疫（クアランティン）」１５１４にあるときに、クラウドサービス６に害を及ぼしたり、そのセキュリティを侵害したりすることができないようにするためである。いくつかの実例では、デバイス１４０３が中間ステート「検疫（クアランティン）」１５１６にあり、そこで限定的な接続性を与えられたとき、クローズドの検疫（クアランティン）ネットワークのみへの接続を許可することもできる。

次に、デバイス１４０３が中間ステート「検疫（クアランティン）」にある状態で、デバイス１４０３のユーザが、上述の認証およびプロセスを用いてデバイス１４０３のクラウドサービス６に対する認証と登録を再度行い、鍵プロビジョニング・プロセス１５００を継続する。認証およびプロビジョニング・プロセスが無事に完了し、デバイス１４０３に適用されているワークフローステップ・ポリシーの次のワークフローステップによって必要であると識別されたコミッショニング担当者の承認が受信された場合、クラウドサービス６は上述のラチェット値をさらに生成し、この追加生成されたラチェット値を使用してラチェット鍵から新たなラチェット認証鍵を作成する。このラチェット鍵は上述のように、ブートストラップ鍵と選択したＱＫＤキーから順番に作成される。クラウドサービス６は次に、データベース７内のデバイスレコードのデバイス１４０３のステータスを、中間ステート「検疫（クアランティン）」１５１２から次のワークフローステート、例えば図１５の例だと「成果（プロダクション）」という名称の最終ステート１５２０へと、１５１８でラチェットフォワードする（ラチェットで前方へ進める）。

クラウドサービス６は次に、または同時に、追加生成されたラチェット値をデバイス１４０３に送信し、デバイス１４０３はそのラチェット鍵から同様の新たなラチェット認証鍵を作成する。このラチェット鍵は上述のように、ブートストラップ鍵と対称鍵から順番に事前に作成されたものである。そして、デバイス１４０３はそのステータスを中間ステート「検疫（クアランティン）」１５１６から次のワークフローステート、例えば図１５の例だと最終ステート「成果（プロダクション）」１５２４へと、１５２２でラチェットフォワードする（ラチェットで前方へ進める）。

図１５の実例において、デバイス１４０３が最終ステート「成果（プロダクション）」１５２４にあり、データベース７内のデバイスレコードのデバイス１４０３のステートも最終ステート「成果（プロダクション）」である場合、デバイス１４０３がクラウドサービス６に対する認証と登録を無事に完了していれば、クラウドサービス６から完全な接続性を与えられる。ここで提供される接続性については、デバイス１４０３を管理する組織であるＭＮＯ１４０４の接続ポリシーによって設定することができる。最後の「成果（プロダクション）」鍵によって、「検疫（クアランティン）」ステートより広範囲のクラウドサービス機能へのアクセスが許可されることとなる。提供されるアクセスは、関連するワークフロー・ポリシーのスコープによって定義されている。

図１５の例は、デバイス１４０３が当初のブートストラップ・ステート１５０４から中間ステート「検疫（クアランティン）」１５１６、最終ステート「成果（プロダクション）」１５２４へとラチェットされ、システムとネットワークへの完全な接続性を提供する、鍵プロビジョニング・プロセス１５００を示している。他の例では、当初のブートストラップ・ステートと最終プロダクション・ステートとの間に、特定の組織の方針が必要とする、幾つもの中間ステートが存在する可能性がある。これらの中間ステートは、図３の例で示されたものと同じ例が含まれるように設定されている。デバイス１４０３をあるステートから次のステートへとラチェットさせる要件は、要望通りに設定することが可能であり、具体的にはユーザ認証やコミッショニング担当者の承認が必要かどうかや、その数の設定などについて、必要に応じて設定することが可能である。限定的な接続性を提供する中間ステート「検疫（クアランティン）」を提供することは必須ではない。

ある状況下においては、デバイス１４０３と関連付けられる全てのキーをリボークし、デバイス１４０３を元の製造施設の状態へ戻す必要性が生じるかもしれない。これを実行するには、全てのコミッショニング関係者およびコミッショニング署名のフィールドをゼロ化、全てのラチェットフィールドをゼロ化、そして現在のワークフローステップをスタートに戻す設定を行う。これによって、デバイス１４０３とデータベース７内のデバイス１４０３のレコードの両方が、それぞれブートストラップ・ステート１５０４と１５０８へとリセットされる。その後、デバイス１４０３は、要望に応じて再び、登録プロセスを開始することができる。

第３の実施形態によると、ＡＰＰプロバイダは、ＳＤＫを提供されることによって、安全なセッションを形成し、クラウドサービス上のＡＰＩをＳＩＭまたはＳＩＭ上の対称鍵の情報を漏らすことなく呼び出すことができる。

導出データはＭＮＯによってクラウドサービスへと提供されるが、ブートストラップ鍵はＭＮＯにとって既知の情報であるため潜在的に脆弱なので、ブートストラップ鍵からラチェットプロセスによって生成される後続のキーはＭＮＯにとって未知の情報であるということが、理解されるだろう。

上記から、開示された第３の実施形態は上記に設定した到達目標を達成できることが、理解されるだろう。

第３の実施形態は、第１と第２の実施形態に関連して上記に示し、そして図４から図１３を参照して説明した、より詳細な例に沿って実行することができる。

上述した第３の実施形態の図例では、ＭＮＯがクラウドサービスへの導出データのプロビジョニングを実行する。

上述した第３の実施形態の図例では、クラウドサービス６に対して提供された導出データはブートストラップ鍵として使用される。他の例では、クラウドサービス６とＳＩＭ１４０２を有するデバイス１４０３の両方が同じ追加処理を実行することができるのであれば、導出データはブートストラップ鍵を生成するために、さらなるプロセスで処理される可能性がある。

上述の第３の実施形態の図例において、ＳＩＭは例えば、物理的ＳＩＭカード、またはｅＳＩＭなどである。

上述の第３の実施形態の例では、対称鍵を有するＳＩＭを使用している。他の例では、既存の共有秘密がインストールされている任意のユーザデバイスを使用することができるが、このインストール済みの共有秘密は導出データの土台として使用されているものである。いくつかの例では、既存の共有秘密が対称暗号鍵である場合がある。このようなデバイスの例として、トラステッドプラットフォームモジュール（ＴＰＭ）がある。

第３の実施形態は、デバイスが製造業者を離れた後も含めて、いつでも使用することができ、エンドユーザの管理下である。デバイスが携帯電話またはモバイル通信用のＳＩＭを備えた他のデバイスである例では、第３の実施形態は、その携帯電話の寿命中であればいつでも、配置されて何年も経過した後であっても、使用することができる。なぜなら、その携帯電話のアプリがブートストラップ鍵を導出することができ、そのブートストラップ鍵をクラウドサービスが格納することが可能、またはＭＮＯがクラウドサービスに対してブートストラップ鍵を提供することが可能だからである。

上記から理解できるように、開示された実施形態によって、デバイスは対称暗号鍵でキーフィルされることが可能である。コミッショニング担当者は、そのデバイスに配備された最終的に出力された暗号鍵について、そのアクセスまたは情報を持つことはない。さらに、デバイス上に鍵を格納するために使用される記憶保護機能があるため、デバイスのユーザは、そのデバイスに配布されたブートストラップ鍵または最終的に出力された暗号鍵についての情報は一切持つことがない。したがって、デバイスに配布されたプロダクション暗号鍵の安全性が保証され、そのプロダクション暗号鍵がトラストレス（管理者による承認を必要としない）な形でデバイスにロードすることができる。ここで、クラウドサービス以外で、デバイスに配布されたプロダクション暗号鍵を関係者の誰かが保有していることを期待する必要はない。当然のことながら、デバイスを認証し、サービスを提供するためには、対称プロダクション暗号鍵の共有コピーを保有していなければならない。デバイスへのキーフィルは、セキュリティ担当者が物理的にデバイスのある場所へ移動し手動でデバイスにキーフィルすることなく、可能である。

いくつかの例では、ユーザは、自身のデバイスを使用してクラウドサービスにログオンを試みる際にユーザが入力できる「強制使用」コードを提供されることがある。クラウドサービスは、強制使用コードに応答して、そのデバイスで出力された暗号鍵をリボークすることによって、不正使用を防止する。いくつかの例では、クラウドサービスは、強制使用コードに応答して、そのデバイスをリモートワイプする可能性がある。いくつかの例では、強制使用コードに応答して、第三者に対して強制使用コードの使用を隠すために、そのデバイスに変造、偽造したデータをロードする可能性がある。

出力された暗号鍵は、そのデバイスによるクラウドサービスへのアクセスを可能とする。デバイスによるウェブ利用は、クラウドサービス内の承認設定によって、そのデバイスを管理する組織によって選択され、権限を与えられた宛先に限定することができる。デバイスによるウェブ利用および他のリソースへのアクセスは、クラウドサービス内で提供されるサービスによって完全に規制、ログ、検証される可能性がある。

様々な暗号鍵の使用によって、異なる段階での鍵の配布プロセスが可能となり、これによって鍵プロビジョニング・プロセスを安全な方法で一元的に管理制御することができる。そして、プロセスに関与するデバイス、アプリケーション、ユーザがネットワークにさらされる可能性を制限することができる。

本出願の方法によって、クラウドサービスを用いて、鍵プロビジョニングとコミッショニングのプロセスを安全で検証済みのトランザクションとすることができ、完全な監査が可能となる。

簡潔かつ明確にするために、上記の例は単一のターゲットデバイスに対する単一の暗号鍵の配布に関するものであるが、この方法によって、自動化されたトラストレス（管理者による承認を必要としない）なキーフィルによって、任意の数のターゲットデバイスに対して、任意の数の暗号鍵を配布することが可能である。

本出願の方法は、Ｂ２ＢやＢ２Ｃモデル上で、自動化キーやデバイスのブートストラップ鍵などの大量のキー、例えばネットワーク通信会社を基盤とするサービスプロバイダ、デバイス製造業者、政府、大企業体、そして個々の組織／ユーザグループなどに対して、配送するのに使用することができる。

上記から理解できるように、本出願の方法は、量子セキュア・鍵プロビジョニングおよび対称鍵の管理に対するグローバルな解決策を提供するものである。これによって、安全なプライベート・チャネル上のデータや情報のグローバルな流通、行為者のグローバルな流通と管理、デバイス、ユーザ、システム、アクセスのグローバルな認証をサポートすることができる。

図示された実施形態では、暗号鍵がターゲットデバイスへと配備される。ターゲットデバイスは、例えばエンドポイントデバイス（ＥＰＤ）など、任意のタイプのデバイスが使用できる。暗号鍵が配備される対象のターゲットデバイスが個別のデバイスである必要はなく、「ターゲットデバイス」はシステム、またはいかなるタイプのエンドポイントでもよい。

いくつかの例では、デバイスが検疫（クアランティン）ステートにあるときに、ソフトウェアやプロファイル、メンテナンス、システムアクセスの更新など、デバイスに必要な更新が実行されることがあるが、クラウドサービスがそのデバイスに完全な接続性を与えるものではない。このリストは網羅的列挙を意図したものではない。

上述の実施形態において、システムは第１の実施形態にしたがって、少なくとも１つの衛星１を含む。いくつかの例では、システムは、例えば異なる光通信性能および／または異なる量子鍵プロビジョニング技法をサポートする性能などの、異なる性能を有する衛星を含めた衛星の集まりを有することがある。

上述の実施形態において、システムは、２つの光地上受信機（ＯＧＲ）２を含む。システムは、任意の数のＯＧＲ２を有することが可能である。例えば、１０，０００以上など、多数のＯＧＲ２となる可能性もある。

上述の実施形態において、ＨＳＭ４は物理的であってもバーチャルであってもよい。

上述の実施形態において、ＨＳＭ４はＯＧＲ２内で構成される。他の例では、一部と言うよりむしろ全てにおいて、ＨＳＭ４はＯＧＲ２に安全に接続することができる。いくつかの例では、ＨＳＭ４はシステムのユーザによってコントロールされる。

上述の実施形態には、製造施設５を含む。他の例ではむしろ、あらゆるタイプの施設がブートストラップ鍵をデバイスにインジェクトすることが可能であり、安全な方法でクラウドサービスと通信を行うことができる。

上述の実施形態において、製造施設は、ブートストラップ・ターミナルを用いて、クラウドサービスと通信を行う。これは必須ではなく、他の手段を使用することができる。

上述の実施形態において、システムは量子鍵プロビジョニング・システムである。他の例では、暗号鍵に加えて、または暗号鍵の代替として、他の暗号化アイテムがプロビジョン、配布、配信される可能性がある。他の暗号化アイテムの例には、暗号トークン、暗号コイン、価値移転が含まれる。

上述の実施形態は完全に自動化されている。いくつかの例では、システムのユーザまたはオペレータが、そのメソッドのステップを実行させるために手動で指示を出すことができる。

本発明の実施形態の説明において、システムのパーツは、コンピューティングデバイスおよび／または電子デバイスの形式で実装することができる。このようなデバイスは、マイクロプロセッサ、コントローラ、または他の適切なタイプのプロセッサなど、１つ以上のプロセッサを含むことができる。これらのプロセッサによって、デバイスのオペレーションを制御するためのコンピュータが実行可能な命令を処理し、ルーティング情報を収集し記録することができる。いくつかの例では、例えばシステム・オン・チップ構造が使用されている事例では、プロセッサには１つ以上の固定のファンクションブロック（アクセラレータとも呼ばれる）を含めることができ、ハードウェア内に（ソフトウェアまたはファームウェアではなく）メソッドの一部を実装することとなる。オペレーティングシステムまたは他の適切なプラットフォームソフトウェアから構成されているプラットフォームのソフトウェアは、アプリケーションソフトウェアをデバイス上で実行可能にするために、コンピューティングベースのデバイスにて提供される可能性がある。

本書で説明する様々な機能は、ハードウェア、ソフトウェア、またはそれらの組み合わせで実装することが可能である。ソフトウェアに実装する場合、コンピュータで読み込み可能な媒体上の１つ以上の命令またはコードとして、保存または転送することができる。コンピュータで読み込み可能な媒体には、例えばコンピュータで読み込み可能なストレージ媒体がある。コンピュータで読み込み可能なストレージ媒体には、揮発性または不揮発性、取り外し可能または取り外しができない媒体を含めることが可能であり、これらは情報記憶のための任意のメソッドまたは技術、例えばコンピュータ可読命令、データ構造、プログラムモジュールや他のデータによって実装される。コンピュータで読み込み可能なストレージ媒体は、コンピュータがアクセス可能なストレージ媒体であればよい。例としてであり限定的ではないが、そのようなコンピュータで読み込み可能なストレージ媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリや他のメモリデバイス、ＣＤ－ＲＯＭや他の光学ディスク記憶装置、磁気ディスク記憶装置や他の磁気記憶装置、または要求したプログラムコードを送信または保管するために命令形式またはデータ構造の形式で使用することができ、コンピュータによるアクセスが可能である他の任意の媒体が含まれる。本書で使用するディスクおよびディスクには、コンパクトディスク（ＣＤ）、レーザーディスク、光ディスク、デジタル多用途ディスク（ＤＶＤ）、フロッピーディスクおよびブルーレイディスク（ＢＤ）が含まれる。さらに言うと、電波信号はコンピュータで読み込み可能なストレージ媒体のスコープには含まれていない。コンピュータで読み込み可能な媒体には、ある場所から別の場所へとコンピュータプログラムの転送を手助けするあらゆる媒体を含む通信媒体も含まれる。コネクションとは、例えば通信媒体がなり得る。例えば、ソフトウェアが、ウェブサイト、サーバー、または他のリモートソースから、同軸ケーブル、光ファイバー・ケーブル、ツイストペア、ＤＳＬ、または赤外線や無線、マイクロ波などのワイヤレス技術を用いて送信される場合、通信媒体の定義に含まれる。上記の組み合わせについても、コンピュータで読み込み可能な媒体の範囲内に含むこととする。

代替的、または追加的に、本書で説明した機能は、少なくとも部分的に、１つ以上のハードウェアロジックコンポーネントによって、実行することができる。例えば、限定的ではないが、使用することができるハードウェアロジックコンポーネントには、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、プログラムスペシフィックインテグレイティッドサーキット（ＡＳＩＣ）、プログラムスペシフィックスタンダードプロダクト（ＡＳＳＰ）、システム・オン・チップ・システム（ＳＯＣ）、コンプレックスプログラマブルロジックデバイス（ＣＰＬＤ）などが含まれる。

単一のシステムとして図示されているが、第１と第２の実施形態のシステムは分散型システムでもあり得ることを理解されたい。

上述の有益性および有効性は、１つの実施形態に関連するものでも、複数の実施形態に関連するものでもよい。実施形態は、記載された問題のいずれかまたは全てを解決するもの、または記載された有益性および有効性のいずれかまたは全てを有するものに限定されるものではない。バリアントは、本発明の範囲に含まれると考えるべきである。

ある１つのアイテムに言及することは、それらのアイテムの１つ以上に言及することである。本書で使用された「構成される／含む」という語句には、認識されたメソッドのステップや要素を含めた意味であるが、そのようなステップや要素は排他的リストを構成するものではなく、メソッドおよび装置には追加的なステップや要素が含まれる可能性がある。

本書では、「コンポーネント」と「システム」という語句は、プロセッサが実行したときに特定の機能が実行されるように、コンピュータで実行可能な命令で設定されたコンピュータで読み込み可能なデータストレージを含有することが意図されている。コンピュータで実行可能な命令には、ルーティン、関数、または同類のものが含まれる。コンポーネントまたはシステムは、単一のデバイス上にローカライズされることもあれば、複数のデバイスに分散される場合があることも理解されたい。

さらに、本書で使用された「例示的」という語句は、「何かの図示や例示として扱われる」という意味を意図する。

さらに、「含める」という語句が詳細な説明か特許請求範囲のどちらかで使用される限りにおいては、「構成する／含む」という語句が特許請求範囲における暫定的な語句として用いられる場合があるのと同様に、そのような語句は包括的であることが意図されている。

図は例示的メソッドを説明している。メソッドは、特定のシーケンス内で実行されている一連の動作として示され、説明されているが、そのメソッドはシーケンスの順序によって限定されるものではないことを理解されたい。例えば、いくつかの動作が、本書に記載されたのと異なる順序で発生する可能性もある。さらに付け加えると、ある動作が別の動作と同時に発生する可能性もある。さらに、時には、全ての動作が本書に記載されたメソッドを実行するのに必要とされるわけではない。

さらに、本書に記載した動作は、コンピュータが実行可能な命令から成り立つものである。この命令は、１つ以上のプロセッサによって実行される、および／またはコンピュータで読み込み可能な媒体上に記憶される。コンピュータが実行可能な命令には、ルーティン、サブルーティン、プログラム、実行スレッド、および／または同類のものを含む。さらに、メソッドの動作の結果は、コンピュータで読み込み可能な媒体への記憶、ディスプレイ装置上への表示、および／または同類のことが可能である。

本書に記載したメソッドのステップの順序は例示的であるが、任意の適切な順序にて実行することができる。または、適切である場合には同時に実行することもできる。さらに、本書に記載した主題を逸脱しない範囲で、ステップを追加または置換、または個々のステップを任意のメソッドから削除することもできる。
上述の例のいずれも、その態様は、求められる効果を失うことなく、記載された他の例のいずれかの態様と組み合わせて、さらなる事例を形成する可能性がある。

上記の出願された実施形態の説明は、ほんの一例として挙げられたものであり、当業者による様々な変更が可能であることを理解されたい。上記に記載した内容には、１つ以上の実施形態の例が含まれる。もちろん、前述の態様を説明する目的において、上記のデバイスまたはメソッドに関して、全ての想定可能な修正および変更について記載することは可能ではないが、当業者の１人であれば、様々な態様に関して、多くのさらなる修正および置換が可能であると認識できる。

Claims

暗号鍵プロビジョニング方法の構成要素：
量子コンピューティングの安全な方法にて、共有秘密データをデバイスへ提供し、セキュリティサービスにも提供すること；
共有秘密データを用いて、ルート鍵を提供すること；および
ルート鍵を一連のステージの土台として使用し、各ステージに含むオペレーションで、スタート鍵を異なる生成鍵へと変換する。そして、これと平行して、同じステージがデバイスおよびセキュリティサービスで実行されること；
前記のルート鍵は、シーケンスの第１ステージのスタート鍵として使用され、シーケンスの各ステージで生成された生成鍵は、シーケンスの最終ステージのものは除き、シーケンスの次のステージのスタート鍵として使用すること；および
前記の生成鍵は、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成されたものであり、対称鍵であること。
請求項１に記載の、デバイスおよびセキュリティサービスの最終ステージによって生成された生成鍵を用いて、さらにデバイスをセキュリティサービスに対して認証させる方法。
請求項１または請求項２に記載の、前記の共有秘密データは対称暗号鍵、または対称暗号鍵から導出されたデータである方法。
先行する請求項に記載の、前記の一連のステージの各ステージのスタート鍵を、デバイスおよびセキュリティサービスにて対称鍵として使用し、デバイスをセキュリティサービスに対して認証させ、デバイスとセキュリティサービス間における安全な通信を可能にする方法。
請求項４に記載の、デバイスがセキュリティサービスに対して認証された後、前記のセキュリティサービスがデバイスにデータを送信し、ステップのシーケンスのうち現在のステージのために、このデータを用いて開始キーを異なるキーへと変換することをさらに含める方法。
先行する請求項に記載の、前記の各ステージがラチェット・オペレーションから構成される方法。
請求項６に記載の、請求項５に従属した状態にあるとき、前記の送信されたデータがラチェット値である方法。
先行する請求項に記載の、ステージのシーケンス内に複数のステージが存在している方法。
請求項８に記載の、ステージのシーケンスによって、対応する鍵のシーケンスが生成され、デバイスをセキュリティサービスに対して認証させるために対称鍵として使用する時に、鍵のシーケンスの異なる鍵が異なるスコープまたはパーミッションと関連付けられている方法。
請求項３に記載の、前記の提供された対称暗号鍵または対称暗号鍵から導出されたデータがルート鍵として使用される方法。
請求項３に記載の、前記の提供された対称暗号鍵または対称暗号鍵から導出されたデータが、ルート鍵を提供するためにさらに処理される方法。
請求項３、１０または１１のいずれか一項に記載の、前記の対称暗号鍵または対称暗号鍵から導出したデータが、量子鍵配送（ＱＫＤ）メソッドによって、デバイスとセキュリティサービスに提供される方法。
請求項３、１０または１１のいずれか一項に記載の、前記の対称暗号鍵または対称暗号鍵から導出されたデータが、古典的に安全なまたは物理的なメカニズムによって、デバイスとセキュリティサービスに提供される方法。
請求項３、１０または１１のいずれか一項に記載の、前記の対称暗号鍵が、量子鍵配送（ＱＫＤ）メソッドによって、デバイスとセキュリティサービスに提供されたキーから導出される方法。
請求項３、１０または１１のいずれか一項に記載の、前記の対称暗号鍵が、古典的に安全なまたは物理的なメカニズムによって、デバイスとセキュリティサービスに提供されたキーから導出される方法。
請求項３、１０または１１のいずれか一項に記載の、前記の対称暗号鍵から導出されたデータが、デバイス上に記憶された対称暗号鍵から導出されたものである方法。
請求項１６に記載の、前記のデバイスがＳＩＭである、またはＳＩＭから構成されており、対称暗号鍵がＳＩＭ上に記憶される方法。
請求項１７に記載の、前記の対称暗号鍵がＯＴＡ鍵である方法。
請求項１６または請求項１７に記載の、前記のＳＩＭ上の対称暗号鍵から導出されたデータが、そのＳＩＭに関連するモバイル通信事業者（ＭＮＯ）によって、提供される方法。
先行する請求項に記載の、ステージのシーケンスのうち少なくとも１つのステージが、そのステージを完了させるためにユーザ認証を必要とする方法。
先行する請求項に記載の、ステージのシーケンスのうち少なくとも１つのステージが、そのステージを完了させるために権限付与を必要とする方法。
請求項２１に記載の、前記の権限付与がコミッショニング担当者によって提供されなければならない方法。
先行する請求項に記載の、前記のステージのシーケンスが、ワークフローによって定義される方法。
請求項２３に記載の、前記のワークフローが、ステージのシーケンスのうち１つ、いくつか、または全てのステージを完了させるためにユーザ認証を必要とするように設定可能である方法。
請求項２３または請求項２４に記載の、前記のワークフローが、ステージのシーケンスのうち１つ、いくつか、または全てのステージを完了させるために、１つまたは複数の権限付与を必要とするように設定可能である方法。
請求項２５に記載の、前記のワークフローが、１つまたは複数の権限付与それぞれについて、誰が行うよう要求されるかを特定するための設定が可能である方法。
請求項２から４のいずれか一項に記載の、または請求項２から４のいずれか一項のいずれかの従属請求項に記載の、デバイスのセキュリティサービスに対する認証に続いて、セキュリティサービスが、認証を実行するために使用された鍵のステージに関連するスコープを有するトークンを、デバイスに対して発行する方法。
請求項２７に記載の、前記のトークンがジェイソン・ウェブ・トークン（ＪＷＴ）である方法。
先行する請求項に記載の、前記のセキュリティサービスがクラウドサービスである方法。
デバイスの認証方法の構成要素：
量子コンピューティングによる安全なメソッドによって、共有秘密データをデバイスに提供すること、およびセキュリティサービスにも提供すること；
ルート鍵を提供するために、提供された共有秘密データを使用すること；および
ルート鍵をステージのシーケンスの土台として使用し、前記の各ステージがスタート鍵を異なる生成鍵へと変換するオペレーションから構成され、同じステージがデバイスとセキュリティサービスで平行して実行されること；
前記のルート鍵がシーケンスの最初のステージのためのスタート鍵として使用され、シーケンスの各ステージで生成された生成鍵が、シーケンスの最終ステージを除いて、シーケンスの次のステージのためのスタート鍵として使用されること；
さらに、デバイスのセキュリティサービスに対する認証を行うために、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵を使用することを含む。
請求項３０に記載の、前記の共有秘密データは対称暗号鍵または対称暗号鍵から導出されたデータである方法。
請求項３０または請求項３１に記載の、デバイスとセキュリティサービスにおけるステージのシーケンスの各ステージのためのスタート鍵が、デバイスをセキュリティサービスに対して認証しデバイスとセキュリティサービス間の安全な通信を可能とするために、対称鍵として使用される方法。
請求項３２に記載の、デバイスがセキュリティサービスに対して認証された後、セキュリティサービスがデバイスにデータを送信し、このデータを用いて、一連のステップの現在のステージのためにスタート鍵を異なる生成鍵に変換することをさらに含む方法。
請求項３０から３３のいずれか一項に記載の、各ステージがラチェット・オペレーションから構成される方法。
請求項３４に記載の、請求項３３に従属した状態にあるとき、前記の送信されたデータがラチェット値である方法。
請求項３０から３５のいずれか一項に記載の、ステージのシーケンス内に複数のステージが存在している方法。
請求項３６に記載の、前記のステージのシーケンスが対応するキーのシーケンスを生成し、キーのシーケンスの異なるキーが、デバイスをセキュリティサービスに対して認証するために対称鍵として使用される場合、異なるスコープまたはパーミッションに関連付けられている方法。
請求項３１に記載の、前記の提供された対称暗号鍵または対称暗号鍵から導出されたデータが、ルート鍵として使用される方法。
請求項３１に記載の、前記の提供された対称暗号鍵または対称暗号鍵から導出されたデータが、ルート鍵を提供するためにさらに処理される方法。
請求項３１、３８、または３９のいずれか一項に記載の、前記の対称暗号鍵または対称暗号鍵から導出されたデータが、量子鍵配送（ＱＫＤ）メソッドによって、デバイスとセキュリティサービスに提供される方法。
請求項３１、３８、または３９のいずれか一項に記載の、対称暗号鍵または対称暗号鍵から導出されたデータが、古典的に安全なまたは物理的なメカニズムによって、デバイスとセキュリティサービスに提供される方法。
請求項３１、３８、または３９のいずれか一項に記載の、前記の対称暗号鍵が、量子鍵配送（ＱＫＤ）メソッドによってデバイスとセキュリティサービスに提供された鍵から導出される方法。
請求項３１、３８、または３９のいずれか一項に記載の、前記の対称暗号鍵が、古典的に安全なまたは物理的なメカニズムによってデバイスとセキュリティサービスに提供された鍵から導出される方法。
請求項３１、３８、または３９のいずれか一項に記載の、前記の対称暗号鍵から導出されたデータが、デバイス上に記憶された対称暗号鍵から導出される方法。
請求項４４に記載の、前記のデバイスがＳＩＭである、またはＳＩＭから構成されており、対称暗号鍵がＳＩＭ上に記憶される方法。
請求項４５に記載の、前記の対称暗号鍵がＯＴＡ鍵である方法。
請求項４５または請求項４６に記載の、前記の対称暗号鍵から導出されたデータが、そのＳＩＭに関連するモバイル通信事業者（ＭＮＯ）によって、提供される方法。
請求項３０から４７のいずれか一項に記載の、ステージのシーケンスのうち少なくとも１つのステージが、そのステージを完了させるためにユーザ認証を必要とする方法。
請求項３０から４８のいずれか一項に記載の、ステージのシーケンスのうち少なくとも１つのステージが、そのステージを完了させるために権限付与を必要とする方法。
請求項４９に記載の、前記の権限付与がコミッショニング担当者によって提供される方法。
請求項３０から５０のいずれか一項に記載の、前記のステージのシーケンスがワークフローによって定義される方法。
請求項５１に記載の、前記のワークフローが、ステージのシーケンスのうち１つ、いくつか、または全てのステージを完了させるためにユーザ認証を必要とするように設定可能である方法。
請求項５１または請求項５２に記載の、前記のワークフローが、ステージのシーケンスのうち１つ、いくつか、または全てのステージを完了させるために、１つまたは複数の権限付与を必要とするように設定可能である方法。
請求項５３に記載の、前記のワークフローが、１つまたは複数の権限付与それぞれについて、誰が行うよう要求されるかを特定するための設定が可能である方法。
請求項３０から５４のいずれか一項に記載の、デバイスのセキュリティサービスに対する認証に続いて、セキュリティサービスが、認証を実行するために使用された鍵のステージに関連するスコープを有するトークンを、デバイスに対して発行する方法。
請求項５５に記載の、前記のトークンがジェイソン・ウェブ・トークン（ＪＷＴ）である方法。
請求項３０から５６のいずれか一項に記載の、前記のセキュリティサービスがクラウドサービスである方法。
対称鍵プロビジョニングの方法の構成要素：
量子コンピューティングの安全な方法にて、デバイス上の秘密データから導出したデータをセキュリティサービスに提供すること；
秘密データから導出した提供データを用いて、ルート鍵を提供すること；
ルート鍵を一連のステージの土台として使用し、各ステージに含むオペレーションで、スタート鍵を異なる生成鍵へと変換する。そして、これと平行して、同じステージがデバイスおよびセキュリティサービスで実行されること；
前記のルート鍵は、シーケンスの第１ステージのスタート鍵として使用され、シーケンスの各ステージで生成された生成鍵は、シーケンスの最終ステージのものは除き、シーケンスの次のステージのスタート鍵として使用すること；
前記の生成鍵は、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成されたものであり、対称鍵であること。
請求項５８に記載の、デバイスのセキュリティサービスに対する認証を行うために、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵を使用することをさらに含む。
請求項５８または請求項５９に記載の、前記の秘密データは対称暗号鍵または対称暗号鍵から導出されたデータである方法。
請求項５８から６０のいずれか一項に記載の、デバイスとセキュリティサービスにおけるステージのシーケンスの各ステージのためのスタート鍵が、デバイスをセキュリティサービスに対して認証しデバイスとセキュリティサービス間の安全な通信を可能とするために、対称鍵として使用される方法。
請求項６１に記載の、デバイスがセキュリティサービスに対して認証された後、セキュリティサービスがデバイスにデータを送信し、このデータを用いて、一連のステップの現在のステージのためにスタート鍵を異なる生成鍵に変換することをさらに含む方法。
請求項５８から６２のいずれか一項に記載の、前記の各ステージがラチェット・オペレーションから構成される方法。
請求項６３に記載の、請求項６２に従属した状態にあるとき、前記の送信されたデータがラチェット値である方法。
請求項５８から６４のいずれか一項に記載の、ステージのシーケンス内に複数のステージが存在している方法。
請求項６５に記載の、前記のステージのシーケンスが対応するキーのシーケンスを生成し、キーのシーケンスの異なるキーが、デバイスをセキュリティサービスに対して認証するために対称鍵として使用される場合、異なるスコープまたはパーミッションに関連付けられている方法。
請求項６０に記載の、前記の提供された対称暗号鍵または対称暗号鍵から導出されたデータが、ルート鍵として使用される方法。
請求項６０に記載の、前記の提供された対称暗号鍵または対称暗号鍵から導出されたデータが、ルート鍵を提供するためにさらに処理される方法。
請求項６０から６７のいずれか一項に記載の、前記の対称暗号鍵または対称暗号鍵から導出されたデータが、量子鍵配送（ＱＫＤ）メソッドによって、デバイスとセキュリティサービスに提供される方法。
請求項６０、６７、または６８のいずれか一項に記載の、対称暗号鍵または対称暗号鍵から導出されたデータが、古典的に安全なまたは物理的なメカニズムによって、デバイスとセキュリティサービスに提供される方法。
請求項６０、６７、または６８のいずれか一項に記載の、前記の対称暗号鍵が、量子鍵配送（ＱＫＤ）メソッドによってデバイスとセキュリティサービスに提供された鍵から導出される方法。
請求項６０、６７、または６８のいずれか一項に記載の、前記の対称暗号鍵が、古典的に安全なまたは物理的なメカニズムによってデバイスとセキュリティサービスに提供された鍵から導出される方法。
請求項６０、６７、または６８のいずれか一項に記載の、前記の対称暗号鍵から導出されたデータが、デバイス上に記憶された対称暗号鍵から導出される方法。
請求項７３に記載の、前記のデバイスがＳＩＭである、またはＳＩＭから構成されており、対称暗号鍵がＳＩＭ上に記憶される方法。
請求項７４に記載の、前記の対称暗号鍵がＯＴＡ鍵である方法。
請求項７４または請求項７５に記載の、前記のＳＩＭ上の対称暗号鍵から導出されたデータが、そのＳＩＭに関連するモバイル通信事業者（ＭＮＯ）によって、セキュリティサービスに提供される方法。
請求項５８から７６のいずれか一項に記載の、ステージのシーケンスのうち少なくとも１つのステージが、そのステージを完了させるためにユーザ認証を必要とする方法。
請求項５８から７７のいずれか一項に記載の、ステージのシーケンスのうち少なくとも１つのステージが、そのステージを完了させるために権限付与を必要とする方法。
請求項７８に記載の、前記の権限付与がコミッショニング担当者によって提供される方法。
請求項５８から７９のいずれか一項に記載の、前記のステージのシーケンスがワークフローによって定義される方法。
請求項８０に記載の、前記のワークフローが、ステージのシーケンスのうち１つ、いくつか、または全てのステージを完了させるためにユーザ認証を必要とするように設定可能である方法。
請求項８０または請求項８１に記載の、前記のワークフローが、ステージのシーケンスのうち１つ、いくつか、または全てのステージを完了させるために、１つまたは複数の権限付与を必要とするように設定可能である方法。
請求項８２に記載の、前記のワークフローが、１つまたは複数の権限付与それぞれについて、誰が行うよう要求されるかを特定するための設定が可能である方法。
請求項５８から８３のいずれか一項に記載の、デバイスのセキュリティサービスに対する認証に続いて、セキュリティサービスが、認証を実行するために使用された鍵のステージに関連するスコープを有するトークンを、デバイスに対して発行する方法。
請求項８４に記載の、前記のトークンがジェイソン・ウェブ・トークン（ＪＷＴ）である方法。
請求項５８から８５のいずれか一項に記載の、前記のセキュリティサービスがクラウドサービスである方法。
デバイス認証の方法の構成要素：
量子コンピューティングの安全な方法にて、デバイス上の秘密データから導出したデータをセキュリティサービスに提供すること；
秘密データから導出した提供データを用いて、ルート鍵を提供すること；および
ルート鍵を一連のステージの土台として使用し、各ステージに含むオペレーションで、スタート鍵を異なる生成鍵へと変換する。そして、これと平行して、同じステージがデバイスおよびセキュリティサービスで実行されること；
前記のルート鍵は、シーケンスの第１ステージのスタート鍵として使用され、シーケンスの各ステージで生成された生成鍵は、シーケンスの最終ステージのものは除き、シーケンスの次のステージのスタート鍵として使用すること；
デバイスのセキュリティサービスに対する認証を行うために、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵を使用することをさらに含む。
請求項８７に記載の、前記の秘密データは対称暗号鍵または対称暗号鍵から導出されたデータである方法。
請求項８７または請求項８８に記載の、デバイスとセキュリティサービスにおけるステージのシーケンスの各ステージのためのスタート鍵が、デバイスをセキュリティサービスに対して認証しデバイスとセキュリティサービス間の安全な通信を可能とするために、対称鍵として使用される方法。
請求項８９に記載の、デバイスがセキュリティサービスに対して認証された後、セキュリティサービスがデバイスにデータを送信し、このデータを用いて、一連のステップの現在のステージのためにスタート鍵を異なる生成鍵に変換することをさらに含む方法。
請求項８７から９０のいずれか一項に記載の、前記の各ステージがラチェット・オペレーションから構成される方法。
請求項９１に記載の、請求項９０に従属した状態にあるとき、前記の送信されたデータがラチェット値である方法。
請求項８７から９２のいずれか一項に記載の、ステージのシーケンス内に複数のステージが存在している方法。
請求項９３に記載の、前記のステージのシーケンスが対応するキーのシーケンスを生成し、キーのシーケンスの異なるキーが、デバイスをセキュリティサービスに対して認証するために対称鍵として使用される場合、異なるスコープまたはパーミッションに関連付けられている方法。
請求項８８に記載の、前記の提供された対称暗号鍵または対称暗号鍵から導出されたデータが、ルート鍵として使用される方法。
請求項８８に記載の、前記の提供された対称暗号鍵または対称暗号鍵から導出されたデータが、ルート鍵を提供するためにさらに処理される方法。
請求項８８、９５、または９６のいずれか一項に記載の、前記の対称暗号鍵または対称暗号鍵から導出されたデータが、量子鍵配送（ＱＫＤ）メソッドによって、デバイスとセキュリティサービスに提供される方法。
請求項８８、９５、または９６のいずれか一項に記載の、対称暗号鍵または対称暗号鍵から導出されたデータが、古典的に安全なまたは物理的なメカニズムによって、デバイスとセキュリティサービスに提供される方法。
請求項８８、９５、または９６のいずれか一項に記載の、前記の対称暗号鍵が、量子鍵配送（ＱＫＤ）メソッドによってデバイスとセキュリティサービスに提供された鍵から導出される方法。
請求項８８、９５、または９６のいずれか一項に記載の、前記の対称暗号鍵が、古典的に安全なまたは物理的なメカニズムによってデバイスとセキュリティサービスに提供された鍵から導出される方法。
請求項８８、９５、または９６のいずれか一項に記載の、前記の対称暗号鍵から導出されたデータが、デバイス上に記憶された対称暗号鍵から導出される方法。
請求項１０１に記載の、前記のデバイスがＳＩＭである、またはＳＩＭから構成されており、対称暗号鍵がＳＩＭ上に記憶される方法。
請求項１０２に記載の、前記の対称暗号鍵がＯＴＡ鍵である方法。
請求項１０１または請求項１０２に記載の、前記の対称暗号鍵から導出されたデータが、ＳＩＭに関連するモバイル通信事業者（ＭＮＯ）によって、セキュリティサービスに提供される方法。
請求項８８から１０４のいずれか一項に記載の、ステージのシーケンスのうち少なくとも１つのステージが、そのステージを完了させるためにユーザ認証を必要とする方法。
請求項８８から１０５のいずれか一項に記載の、ステージのシーケンスのうち少なくとも１つのステージが、そのステージを完了させるために権限付与を必要とする方法。
請求項１０６に記載の、前記の権限付与がコミッショニング担当者によって提供される方法。
請求項８８から１０７のいずれか一項に記載の、前記のステージのシーケンスがワークフローによって定義される方法。
請求項１０８に記載の、前記のワークフローが、ステージのシーケンスのうち１つ、いくつか、または全てのステージを完了させるためにユーザ認証を必要とするように設定可能である方法。
請求項１０８または請求項１０９に記載の、前記のワークフローが、ステージのシーケンスのうち１つ、いくつか、または全てのステージを完了させるために、１つまたは複数の権限付与を必要とするように設定可能である方法。
請求項１１１に記載の、前記のワークフローが、１つまたは複数の権限付与それぞれについて、誰が行うよう要求されるかを特定するための設定が可能である方法。
請求項８８から１１１のいずれか一項に記載の、デバイスのセキュリティサービスに対する認証に続いて、セキュリティサービスが、認証を実行するために使用された鍵のステージに関連するスコープを有するトークンを、デバイスに対して発行する方法。
請求項１１２に記載の、前記のトークンがジェイソン・ウェブ・トークン（ＪＷＴ）である方法。
請求項８８から１１４のいずれか一項に記載の、前記のセキュリティサービスがクラウドサービスである方法。
暗号鍵プロビジョニング・システムの構成要素：
量子コンピューティングによる安全なメソッドによって、共有秘密データをデバイスに提供し、セキュリティサービスにも提供するように設定した手法；
ルート鍵を提供するために、提供された共有秘密データを使用するように設定した手法；および
ルート鍵をステージのシーケンスの土台として使用するように設定し、前記の各ステージがスタート鍵を異なる生成鍵へ変換するオペレーションを含んでおり、これと並行して、システムがデバイスおよびセキュリティサービスにおいて同じステージを実行するように設定した手法；
前記のルート鍵がシーケンスの第１ステージのためのスタート鍵として使用され、シーケンスの各ステージによって生成された生成鍵は、シーケンスの最終ステージのものを除いて、シーケンスの次のステージのためのスタート鍵として使用される；および前記のデバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵は、対称鍵である。
請求項１１５に記載の、デバイスをセキュリティサービスに対して認証するために、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵を使用するように設定された手法を、さらに含めるシステム。
請求項１１５または請求項１１６に記載の、前記の共有秘密データが対称暗号鍵または対称暗号鍵から導出したデータであるシステム。
デバイス認証システムの構成要素：
量子コンピューティングによる安全なメソッドによって、前記の共有秘密データをデバイスに提供し、セキュリティサービスにも提供するように設定した手法；
ルート鍵を提供するために、提供された共有秘密データを使用するように設定した手法；および
ルート鍵をステージのシーケンスの土台として使用するように設定し、前記の各ステージがスタート鍵を異なる生成鍵へ変換するオペレーションを含んでおり、これと並行して、デバイスおよびセキュリティサービスにおいて同じステージを実行するように設定した手法；
前記のルート鍵がシーケンスの第１ステージのためのスタート鍵として使用され、シーケンスの各ステージによって生成された生成鍵は、シーケンスの最終ステージのものを除いて、シーケンスの次のステージのためのスタート鍵として使用される；および
デバイスのセキュリティサービスに対する認証を行うために、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵を使用するように設定した手法をさらに含む。
請求項１１８に記載の、前記の共有秘密データは対称暗号鍵または対称暗号鍵から導出されたデータであるシステム。
暗号鍵プロビジョニング・システムの構成要素：
量子コンピューティングによる安全なメソッドによって、デバイス上の秘密データから導出したデータをセキュリティサービスに提供するように設定した手法；
ルート鍵を提供するために、秘密データから導出した提供データを使用するように設定した手法；および
ルート鍵をステージのシーケンスの土台として使用するように設定し、前記の各ステージがスタート鍵を異なる生成鍵へ変換するオペレーションを含んでおり、これと並行して、デバイスおよびセキュリティサービスにおいて同じステージを実行するように設定した手法；
前記のルート鍵がシーケンスの第１ステージのためのスタート鍵として使用され、シーケンスの各ステージによって生成された生成鍵は、シーケンスの最終ステージのものを除いて、シーケンスの次のステージのためのスタート鍵として使用される；および
前記のデバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵は、対称鍵である。
請求項１２０に記載の、デバイスをセキュリティサービスに対して認証するために、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵を使用するように設定された手法を、さらに含めるシステム。
請求項１２０または請求項１２１に記載の、前記の秘密データが対称暗号鍵または対称暗号鍵から導出したデータであるシステム。
デバイス認証システムの構成要素：
量子コンピューティングによる安全なメソッドによって、デバイス上の秘密データから導出したデータをセキュリティサービスに提供するように設定した手法；
ルート鍵を提供するために、秘密データから導出した提供データを使用するように設定した手法；および
ルート鍵をステージのシーケンスの土台として使用するように設定し、前記の各ステージがスタート鍵を異なる生成鍵へ変換するオペレーションを含んでおり、これと並行して、デバイスおよびセキュリティサービスにおいて同じステージを実行するように設定した手法；
前記のルート鍵がシーケンスの第１ステージのためのスタート鍵として使用され、シーケンスの各ステージによって生成された生成鍵は、シーケンスの最終ステージのものを除いて、シーケンスの次のステージのためのスタート鍵として使用される；
および、デバイスをセキュリティサービスに対して認証するために、デバイスとセキュリティサービスでシーケンスの最終ステージによって生成された生成鍵を使用するように設定された手法を、さらに含めること。
請求項１２３に記載の、前記の秘密データが対称暗号鍵または対称暗号鍵から導出されたデータであるシステム。
プロセッサによって実行されると、請求項１から２９、請求項３０から５７、請求項５８から８７、または請求項８８から１１４のいずれかに記載の方法をプロセッサに実行させるコードまたはコンピュータ命令が記憶された、コンピュータで読み込み可能な媒体。
プロセッサによって実行されると、請求項１から２９、請求項３０から５７、請求項５８から８７、請求項８８から１１４のいずれかに記載の方法をプロセッサに実行させる命令を含む、コンピュータプログラム。