JP7267294B2 - トランザクションコネクタ及びブローカサービスを使用してブロックチェーンネットワークのバージョン化されたブロックとしてデバイスライフサイクルトランザクションを記録するためのシステム及び方法 - Google Patents

Description

関連出願の相互参照

本出願は、２０１７年１１月３０日に出願された米国仮出願第６２／５９２，８６８号、２０１８年２月１９日に出願された米国特許出願第１５／８９８，９５０号、及び２０１８年１１月５日に出願された一部継続出願第１６／１８０，２００号に対する優先権の利益を主張し、それぞれの内容が参照により本明細書に組み込まれる。

本開示は、エンロールメントサービス及びアイデンティティ（identity）プルーフィングに基づく認証局により暗号的に署名されたアーティファクトの発行と、デバイス管理サービスによる発行されたアーティファクトの使用とに基づく、インターネット・オブ・シングス（ＩｏＴ）のためのデバイス保護の分野に関する。

サイバーセキュリティは、産業、自動車、及びホームオートメーションの分野の至る所に展開されているＩｏＴデバイスに対するオペレーションテクノロジー（ＯＴ）の新興分野において深刻なリスクをもたらす。サプライチェーンにわたる改ざん耐性デバイスは、証明書ベースのエンロールメントを必要とする。アップデートサービスでは、無線又はネットワーク経由でリモートデバイスにアップデートを安全に配布するために、高度に保証された暗号署名が必要である。ゼロタッチプロビジョニング（例えば、典型的にはデバイスインストールにおける、ユーザ対話なしにデバイスを構成する能力）は、デバイス登録及びデバイス管理サービスに必要とされる。デバイス登録の現在のアプローチには、保証鍵又は証明書（Ｘ．５０９）のユーザ生成デジタルハッシュ（ダイジェスト）を使用したｗｅｂポータルを使用した手動プロビジョニング、或いは割り当てられたデバイス識別子に基づくサービスプロバイダ独自のＪＳＯＮウェブトークン（ＪＷＴ）の使用が含まれる。自動化は、動作のスケーラビリティのためにバッチ処理のスクリプトを使用して実現される。他の新しいアプローチは、非集中型認証に基づいて参加者を登録するためのプライベートの／許可されたブロックチェーン技術の使用と、暗号署名のための公開鍵インフラストラクチャ（ＰＫＩ）の使用である。ブロックチェーンの使用に基づく代替方法は、データ改ざんに対する強力な保護、スケーラビリティのための分散制御、並びにデジタル資産及びトランザクションの所有権を保護するための公開鍵暗号化及びデジタル署名を提供する。

これらの方法の制限には、非現実のアイデンティティの不十分なプルーフの所有、安全でないアイデンティティプルーフィング方法、証明書管理のプロトコルベースではない独自の方法、ベンダロックイン、及びデバイス登録ユースケースのみに対処することが含まれ、その後、これらのアプリケーションは安全な鍵／ストレージ及び証明書管理を処理しなければならず、アプリケーションを脆弱にする。他のアプローチは、グループメンバーシップベースの鍵ペアを使用して、サプライチェーンを通じた所有権の、署名ベースの安全な変更を提供する。しかしながら、これは、オペレーションの情報技術（ＩＴ）及びＯＴドメインの外部のワークフローにおける集中型ブローカを必要とする。ブロックチェーンベースのアプローチは、通信において否認不可なデバイスアイデンティティを欠いており、デバイス登録は、アイデンティティの信頼できるプルーフを欠いており、同時トランザクションの量においてスケーラビリティを欠いている。

ブロックチェーン技術は、デジタル資産及びトランザクションの所有権を保護するために、公開鍵暗号及びデジタル署名に基づいて、スケーラビリティ、データ署名、及び署名検証のための分散制御の方法を提供する。しかしながら、通信において否認不可なデバイスアイデンティティが存在しない場合があり、ＩｏＴデバイス登録は、アイデンティティの信頼できるプルーフなしに実行される場合があり、ＩｏＴデバイスは、データを暗号化し、復号化するために必要な計算能力を欠いている場合がある。ブロックチェーンアプリケーションは、ネットワークにトランザクションリクエストを送信する。ネットワーク上のピアは、スマートコントラクト（コードチェーン）を使用してトランザクションリクエストを処理し、台帳（ledger）をアップデートし、システム間のオーケストレーションのためにトランザクションのブロックを発行する。

現在のアプローチは、デバイス検出、識別、及び登録のために様々な方法を使用する。これらの方法は、ヘッドレスデバイス（すなわち、対話型ユーザなしで動作するデバイス）に対するユーザ介入を必要とするか、或いは登録のための信頼できる検出及び識別の前にデバイスを事前登録するための管理アクションを必要とする。このような方法には、（ａ）ネットワーク（ＩＰ）アドレス及びパーソナリティに基づく検出（たとえば、周知のサービスポート、アプリケーションプロトコルの一意のクエリ検査など）、（ｂ）デバイスタイプによるエンロールメントルールを適用するデバイス事前登録、（ｃ）共有秘密を使用するヘッドレスデバイスの検出、（ｄ）デバイスのタイプによるエンロールメントポリシー、（ｅ）発行された証明書がデバイスの通信アドレスに関連付けられる、機器と認証局との信頼できる関連付け、（ｆ）既存の暗号鍵ペアの使用、（ｇ）構成データベースのデバイスパスワード又はデバイスの事前登録がリクエストされる、内部及び外部エンドポイントと中間支援ゲートウェイデバイスとの信頼関係、（ｈ）デバイスの一意の識別子を使用してネットワークデバイスを、サービスにより識別すること、（ｉ）ネットワークに接続された第１のデバイスを、第２のユーザデバイスを使用して識別すること、さらに、第１のデバイスがＤＨＣＰを介してＩＰを取得すること、（ｊ）コントローラとアプライアンスと間の安全なエンドポイントを作成するための、資産管理システムによるＨＳＭの使用、及び（ｋ）他のデバイスのための既存の証明書又はトークンを必要とする、デバイス識別子により他のデバイスに接続するための、ネットワーク接続された支援デバイスの使用、が含まれる。

例えばインテル（商標登録）のエンハンスドプライバシーＩＤ（ＥＰＩＤ）スキームなどの、プライバシー保護及び匿名性の必要性に基づく技術は、メンバのアイデンティティを開示することなく、メンバがグループの信頼されたメンバであることをベリファイヤ（verifier）に証明するために、メンバのグループ公開鍵及びメンバ一意の秘密鍵を使用する。しかしながら、これらの方法は、データ交換におけるメッセージ完全性の検証に限定され、グループを作成してメンバーシップを管理するために集中イシュアラー（issuer）を必要とする。ＥＰＩＤ署名は、シリコンベンダからＩｏＴサービスプロバイダへの所有権の証明ベースの転送を促進するが、デバイスライフサイクル管理は、データの機密性のために、デバイス証明書及びＰＫＩに基づく管理、運用、及び保守を必要とする。

ブロックチェーンに基づく他のアプローチは、データハッシュに署名及び検証するための集中型ブローカ及びＲＥＳＴ（Representational State Transfer） ＡＰＩを使用して、クライアントとサーバとの間の保存データ、データ署名、及び署名検証を保護するための署名鍵を提供する。このようなＰＫＩ又は証明書に依存しない鍵不要（キーレス）署名の使用は、データ完全性のためのメッセージ署名に限定される。サーバ上の署名スキームでは、周期的な（月単位の）アップデートが必要である。

不変のハードウェア構成に基づくデバイスの一意のデジタルフィンガープリントの使用に基づく代替アプローチ、及びフィラーコードのために少なくとも１つのユーザ構成可能パラメータを必要とするアルゴリズム処理は、何百万もの分散型ＩｏＴデバイスにわたるヘッドレスデバイス又はスケーラビリティのための実行可能な解決策ではない。デバイスのデジタルフィンガープリントに基づく秘密鍵を使用し、発行されたデバイスの公開証明書にデバイスのデジタルフィンガープリントを含めることは、プライバシー及び匿名性保護を取消し、デバイスをリバースエンジニアリング及びハッカー攻撃にさらす。

上述の方法とは全く対照的に、本開示のデバイス登録のためのシステムは、（ａ）デバイス検出及び識別前のデバイス事前登録、（ｂ）共有秘密の使用、（ｃ）認証局によるデバイスの事前発行証明書、（ｄ）ユーザデバイスとの推論された信頼関係、（ｅ）ＴＣＰ／ＩＰネットワークへの内部エンドポイントの接続性、又は（ｆ）デバイスのために発行された既存の暗号鍵の使用、を必要としないが、事前共有秘密を任意に使用して、アイデンティティの高度な所有のプルーフを提供することができる。開示されたシステムの開示された方法は、実装に応じて、（ａ）グループ及びメンバ鍵管理のための集中イシュアラーを必要とせずに分散制御を提供し、（ｂ）分散制御のブロックチェーン概念に準拠した集中ブローカ、並びに、データ改ざんに対するデジタル資産及びトランザクションのためのＰＫＩベースの強力な保護を必要とせず、（ｃ）ヘッドレスデバイスを登録するために必要とされるユーザ構成可能パラメータを伴わないゼロタッチプロビジョニングを提供し、（ｄ）デバイスフィンガープリントをデバイス証明書に含めることを必要としないプライバシー保護を提供することができる。エンドポイントデバイスは、検出前にエンロールメントサービスへの事前登録を必要としない不変のデバイス識別子と、信頼の基点（root of trust）アンカーとして機能するローカル又はリモートセキュアエレメントを持つ関連付けられたゲートウェイデバイス（非ＩＰエンドポイントデバイスの場合のみ）とを必要とするのみである。

例示的な実施形態では、開示されたシステムの方法は、デバイスエンロールメント及びデバイス登録を別個のワークフローとして区別する。デバイス登録は、デバイスの信頼の基点として機能するセキュアエレメントによる、デバイスのアイデンティティプルーフィングに基づくデバイスクレデンシャルの最初の割り当てである。デバイスエンロールメント（enrollment）は、許可されたドメイン及びブロックチェーンにデバイスを追加する（又は参加させる）ために必要とされる。デバイス登録（registration）は、例えばデバイス管理サービス、ポリシーサービス、又はアップデートサービスなどの、接続されたサービスへの、登録されたデバイスの追加（すなわち、エンロールメントの後工程）である。デバイス登録は、管理されたネットワークにデバイスを追加するため、デバイス管理サービスへのデバイス所有権の割り当て又は転送のため、ポリシーベースの遠隔操作、管理、保守、及びプロビジョニング機能のために必要とされる。デバイスエンロールメントリクエストは、オーケストレーションされたワークフロー動作として、（証明書ベースの登録のための）デバイスエンロールメント及びデバイス登録を含んでもよい。同様に、デバイス除籍リクエストは、オーケストレーションワークフロー動作として、（証明書ベースの登録のための）デバイス除籍（disenrollment）及びデバイス登録解除（deregistration）を含んでもよい。

従来のＩＴ脅威モデルは、脅威情報、文法、式、及びベースラインからの逸脱に基づく異常検出を中心とする多層防衛マインドセットを使用する。ＩｏＴは、システムの安全性を中心に、検出から保護へのパラダイムシフトを必要とする。これは、埋め込み安全管理の悪用に対する、リスクの予想、先制対策、及びアプリケーションの回復力を必要とする。

ローカルエリアネットワーク（ＬＡＮ）又はワイドエリアネットワーク（ＷＡＮ）を介したデータ転送には、ネットワークサービスによって静的又は動的に割り当てられたインターネットプロトコル（ＩＰ）アドレスが必要である。従来のブラウンフィールドデバイスは、ポイントツーポイントインタフェース及びリンクプロトコル（例えばＲＳ－２３２、ＲＳ－４２２、ＲＳ－４８５、ＨＡＲＴ（ハイウェイアドレッサブルリモートトランスデューサ）、Ｍｏｄｂｕｓ、ＣＡＮ（コントローラエリアネットワーク）バス、航空無線（ＡＲＩＮＣ）、汎用入出力（ＧＰＩＯ）を使用し、ネットワーク用のＩＰプロトコルスタックがない場合がある。

開示された方法は、従来のデバイスを改良して保護及びリモートデバイス管理をするために、著しい改善及び効率を提供することができる。（例えばメモリ、バッテリ駆動などの）リソース制約及びポイントツーポイント接続性を有しており、ＩＰネットワークを介してアクセス可能ではない、非ＩＰアドレス割り当てデバイス（以下、「非ＩＰデバイス」）は、デバイスのエンロールメント及び管理のために検出され得る。ネットワークＩＰアドレスを持たない非ＩＰデバイスは、接続されたＩＰゲートウェイデバイスに関連付けられてもよく、その逆も、識別及び証明書ベースの管理のために関連付けられてもよい。デバイス設定、ファームウェア、又はアプリケーションソフトウェアのアップデートを含む、非ＩＰデバイスへの／からのデータ転送は、機密性と一体性のためにデバイス関連証明書を使用して、ＩＰ(ＬＡＮ又はＷＡＮ）ネットワーク経由の接続されたＩＰゲートウェイデバイスにより代理され得る。接続されたゲートウェイデバイスへの非ＩＰデバイスの動的な関連付けは、デバイス管理サービスによって監視され得る。接続されたエンドポイント及びゲートウェイデバイスは、ブロックチェーンアプリケーションとして参加して、非ＩＰ又はＩＰデバイス検出を開始し、オーケストレーションルール（すなわち、スマートコントラクト又はコードチェーン）に基づいて、認証されたトランザクションをブロックチェーン内のネットワークピアに関連付け、デバイスの棚卸及びデバイスのライフサイクルにわたるステータス管理のために、分散台帳（distributed ledger）にトランザクションレコードを生成することができる。

開示された方法は、（ａ）追加されるデバイスのために構成されたポリシーサービスを使用した証明書ベースの登録におけるＩＰデバイス及び非ＩＰデバイスの自動登録、（ｂ）削除されるデバイスのために構成されたポリシーサービスを使用した証明書取消におけるＩＰデバイス及び非ＩＰデバイスの自動登録解除、（ｃ）コネクタの属性には少なくとも証明書のコストと期間が含まれ得る、証明書発行及び取消のための複数の認証局を使用したポリシーベースの動的関連付け（コネクタ）、（ｄ）接続されたエンドポイントデバイスの証明書リクエストがゲートウェイデバイス証明書を使用して署名され、ゲートウェイデバイス証明書がゲートウェイデバイス上の基礎となるローカルセキュアエレメントの保証証明書（信頼の基点）を使用して署名される、マルチシステムトラストチェーンを確立するためのエンロールメントサービスにおけるエンドポイント及び接続されたゲートウェイデバイスの認証を伴う、スケーラビリティのための大幅なプロセス向上及び効率を提供することができる。

例えばトランスポート層セキュリティ（ＴＳＬ）又はインターネットプロトコルセキュリティ（ＩＰｓｅｃ）などの、一般的に使用されるセキュアなトランスポートプロトコルに基づくフィールドデバイスへのアップデートの任意のフォームは、ピアツーピア通信での送信者（サーバ）とオプションで受信者（クライアント）の検証によって転送時のデータの機密性のみを提供する。サプライチェーンの一体性の検証は、行われない。ファームウェアアップデート、設定アップデート、ファイアウォールルール、ソフトウェアアップデート、オペレーティングシステムパッチなどの、デバイスに配布されるアップデートは、プロバイダから、ディストリビュータを介してパブリッシャに送信される。この流路には、複数ホップの蓄積及び転送サイロが含まれる。このような配達機構において、サプライチェーンにわたるアップデートパッケージの漏えい耐性パッケージングを高度に保証するためのプロビジョニングはない。開示される方法は、革新的な暗号技術の使用とディストリビューションチェーン内の全てのエンティティの信頼できるアイデンティティプルーフィングとに基づいて、エンドツーエンドのデータの機密性及び一体性のためのサプライチェーンの起源（provenance）を組み込むためのスケーラブルかつ自動化されたアプローチを記載する。

エンロールメント及び登録、並びにセキュアなアップデートのためのデバイス識別の開示された方法は、非ＩＰ及びＩＰエンドポイントデバイス並びにＩＰゲートウェイデバイスに適用可能である。業界用語では、エンドポイントデバイスは、エッジデバイス又はセンサとも称され、ゲートウェイデバイスは、コアデバイスとも称される。

本開示の例示的な実施形態は、ゲートウェイデバイスに接続されたエンドポイントデバイスのエンロールメント及び登録のためのデバイス識別の方法を提供する。本方法は、多段階検証ブートローダ、エンドポイントデバイスでの検出エージェント、ゲートウェイデバイスでの検出サービス、エンロールメントサービス、ポリシーサービス、及びデバイス管理サービスを使用する。本方法は、エンドポイントデバイスの検出エージェントにより、ゲートウェイデバイスの検出サービスに、エンドポイントデバイスプロファイルを有する認証されたアイデンティティビーコンを送信することを含む。本方法は、検出サービスにより、エンドポイントデバイスの認証及びエンドポイントデバイスプロファイルを検証することと、検出サービスにより、プライバシー認証局からのエンドポイントデバイスの証明書リクエストを生成することと、を含む。本方法は、検出サービスにより、エンドポイントデバイスの証明書リクエストをエンロールメントサービスに送信することを含む。本方法は、エンロールメントサービスにより、受信されたエンドポイントデバイスの証明書リクエストを処理して、認証局への証明書リクエストに変換することと、エンロールメントサービスにより、変換されたエンドポイントデバイスの証明書リクエストを認証局に送信することと、を含む。本方法は、エンロールメントサービスにより、認証局により発行されたエンドポイントデバイスの証明書を受信することと、エンロールメントサービスにより、受信されたエンドポイントデバイスの証明書を処理して、受信されたエンドポイントデバイスの証明書を、プライバシー認証局を表すように変換することと、を含む。本方法は、エンロールメントサービスにより、エンドポイントデバイスの証明書を検出サービスに送信することと、エンロールメントサービスにより、エンドポイントデバイス登録の通知をポリシーサービスに送信することと、を含む。本方法は、ポリシーサービスにより、エンドポイントデバイスをデバイス管理サービスに追加する指令を送信することと、検出サービスにより、発行されたエンドポイントデバイスの証明書をローカル証明書ストアに保存することと、を含む。

本開示の例示的な実施形態は、アドミニストレーションダッシュボード、エンロールメントサービス、ポリシーサービス、及びデバイス管理サービスを使用してデバイスを登録解除する方法を提供する。本方法は、認証された特権ユーザにより、アドミニストレーションダッシュボードから、デバイス証明書を取消す動作を開始することと、エンロールメントサービスにより、認証局に取消コマンドを送信することと、を含む。本方法は、エンロールメントサービスにより、デバイス証明書取消の通知をポリシーサービスに送信することを含む。本方法は、ポリシーサービスにより、デバイス管理サービスに、デバイスを削除する指令を送信することを含む。

本開示の例示的な実施形態は、ブロックチェーンアプリケーションとしてゲートウェイデバイスにおける検出サービスと、ブロックチェーンネットワークピアとしてネットワークにおけるエンロールメントサービスとを使用した、エンドポイントデバイスエンロールメントの方法を提供する。本方法は、検出サービスにより、エンドポイントデバイスのエンロールメントリクエストをネットワークのエンロールメントサービスに送信することを含む。本方法は、エンロールメントサービスにより、エンロールメントリクエストの受信し、ゲートウェイデバイスを認証することを含み得る。本方法は、エンロールメントサービスにより、ネットワークのネットワークサービスのために確立されたオーケストレーションルールに基づいて、認証局によって発行されたエンドポイントデバイスの証明書を生成することを含む。本方法は、エンロールメントサービスにより、エンドポイントデバイスの証明書をゲートウェイデバイスに送信することを含む。本方法は、アップデートサービスにより、エンドポイントデバイスのリクエストログをトランザクションレコードとしてローカル台帳に記録し、トランザクションレコードのブロックをブロックチェーンピアに配布して、デバイス履歴を再現するために分散台帳を維持することを含む。

本開示の例示的な実施形態は、アップデートプロバイダにより操作されるディベロップメントシステム及びリリース管理システム、アップデートパブリッシャにより操作されるアップデートサービス、デバイスのアップデートクライアント、及びデバイスのローカルセキュアエレメントを使用して、登録されたデバイスをアップデートする方法を提供する。本方法は、ディベロップメントシステムに、ファームウェアアップデート、ソフトウェアアップデート、構成アップデート、及びアップデートスクリプトの少なくとも１つを含むアップデートパッケージを構築することを含む。本方法は、リリース管理システムにより、プロバイダ署名鍵を使用してアップデートパッケージに署名することを含み、ここで、第１のデジタル署名はアップデートパッケージに含まれる。本方法は、リリース管理システムにより、アップデートパッケージの初期暗号化のために、アップデートパブリッシャのためのパブリッシャ証明書からのパブリッシャ公開鍵を使用して署名されたアップデートパッケージを暗号化することを含む。本方法は、リリース管理システムにより、署名及び暗号化されたアップデートパッケージをアップデートサービスに送信することを含む。本方法は、デバイスのアップデートクライアントにより、アップデートパッケージをリクエストすることを含む。リクエストは、デバイスマニフェストと、少なくともそのデバイスのベンダ識別子、型番、及びデバイス証明書を含み得る。本方法は、アップデートサービスにより、受信したデバイスマニフェストに基づいて、構成されたデバイスのオーケストレーションルールに基づいて、デバイスの署名されたアップデートパッケージのセットを準備することを含む。本方法は、アップデートサービスにより、アップデートパブリッシャのパブリッシャ秘密鍵を使用して初期暗号化を復号化することによって署名されたアップデートパッケージを再暗号化及び再署名し、アップデートパブリッシャの署名鍵を使用してアップデートパッケージを署名し、最後に、アップデートパッケージの最終暗号化のために、デバイス証明書からのデバイス公開鍵を使用してアップデートパッケージを暗号化することを含む。第２のデジタル署名は、アップデートパッケージに含まれる。本方法は、アップデートサービスにより、暗号化され二重に署名されたアップデートパッケージをデバイスのアップデートクライアントに送信することを含む。本方法は、アップデートクライアントにより、デバイスのデバイス秘密鍵を使用して暗号化されたアップデートパッケージを復号化することを含む。本方法は、アップデートクライアントにより、アップデートプロバイダからの各々の公開鍵と認証局によって発行されたパブリッシャ証明書とを使用して、第１及び第２のデジタル署名を検証することを含む。例示的な実施形態では、アップデートスクリプトは、アップデートパッケージをデバイスに適用するためにデバイスで実行される。

本開示の例示的な実施形態は、ブロックチェーンアプリケーションとしてのデバイスのアップデートクライアント、ブロックチェーンネットワークピアとしてのネットワークのアップデートサービス、オーケストレーションルール、及び台帳を使用してデバイスをアップデートする方法を提供する。本方法は、アップデートクライアントにより、ネットワークのアップデートサービスからデバイスのアップデートパッケージのデバイスリクエストを送信することを含む。本方法は、アップデートサービスにより、デバイスリクエストを受信し、デバイスを認証することを含む。本方法は、アップデートサービスにより、ネットワークのネットワークサービスのために確立されたオーケストレーションルールに基づいて、署名され暗号化されたアップデートパッケージを準備することを含む。本方法は、アップデートサービスにより、署名及び暗号化されたアップデートパッケージをデバイスに送信することを含む。本方法は、アップデートサービスにより、デバイスのリクエストログをエントリとして台帳に記録し、トランザクションレコードのブロックをブロックチェーンピアに配布して、デバイス履歴を再現するために分散台帳を維持することを含む。

本開示の例示的な実施形態は、検出エージェント、検出サービス、エンロールメントサービス、ポリシーサービス、及びデバイス管理サービスを使用して、ＩＰアドレスを有さないエンドポイントデバイスと、エンドポイントデバイスに接続されるゲートウェイデバイスとの間のデータ転送を安全にする方法を提供する。本方法は、エンドポイントデバイスの検出エージェントにより、ゲートウェイデバイスの検出サービスに、エンドポイントデバイスのデバイスプロファイルを有する認証されたアイデンティティビーコンを送信することを含む。本方法には、検出サービスにより、エンドポイントデバイス及びデバイスプロファイルの認証を検証することと、検出サービスにより、プライバシー認証局からエンロールメントサービスへのエンドポイントデバイスの証明書リクエストを生成することを含む。本方法は、エンロールメントサービスにより、受信されたエンドポイントデバイスの証明書リクエストを処理して、認証局への証明書リクエストに変換することを含む。本方法は、エンロールメントサービスにより、エンドポイントデバイスの証明書リクエストを認証局に送信することと、エンロールメントサービスにより、認証局により発行されたエンドポイントデバイスの証明書を受信することと、を含む。本方法は、エンロールメントサービスにより、受信されたエンドポイントデバイスの証明書を処理して、プライバシー認証局を表すように変換することを含む。本方法は、エンロールメントサービスにより、エンドポイントデバイスの証明書を検出サービスに送信することを含む。本方法は、エンロールメントサービスにより、エンドポイントデバイス登録の通知をポリシーサービスに送信することと、ポリシーサービスにより、エンドポイントデバイスを追加する指令をデバイス管理サービスに送信することとを含む。本方法は、検出サービスにより、発行されたエンドポイントデバイスの証明書をゲートウェイデバイスのローカル証明書ストアに格納することを含む。本方法は、安全なデータ転送のために、ゲートウェイデバイスのアプリケーションにより、エンドポイントデバイスから／への送信中のデータを受信し、ローカル証明書ストアからのエンドポイントデバイスの証明書を使用して、データに対して暗号化動作を実行することを含む。

本開示は、添付の図面に関連して読まれるとき、以下の詳細な説明から最も良く理解される。一般的な慣行によれば、図面の種々の特徴／要素は縮尺通りに描かれていない場合もある。共通の参照番号は、同様の特徴／要素を表す。以下の図面が、添付の図面に含まれる。
図１は、開示されたシステムの様々な例示的な実施形態における、エンドポイント及びゲートウェイデバイスのデバイスライフサイクル管理システムを図示したものである。 図２は、開示されたシステムの様々な例示的な実施形態における、接続されたＩＰゲートウェイデバイスに物理的に接続された非ＩＰエンドポイントデバイスを検出するための方法を示す模式図である。 図３は、開示されたシステムの様々な例示的な実施形態における、リモートセキュアエレメントを使用する非ＩＰエンドポイント又はＩＰゲートウェイデバイスのエンロールメントを示す模式図である。 図４は、開示されたシステムの様々な例示的な実施形態における、ローカルセキュアエレメント及び認証局を使用する非ＩＰエンドポイント又はＩＰゲートウェイデバイスの登録を示す模式図である。 図５は、開示されたシステムの様々な例示的な実施形態における、ローカルセキュアエレメント、認証局、ポリシーサービス、及びデバイス管理サービスを使用する、追加（on-boarding）のためのデバイスのエンロールメント及び登録の方法を示すフローチャートである。 図６は、開示されたシステムの様々な例示的な実施形態における、アップデートサービス、アップデートクライアント、及びローカルセキュアエレメントを使用するエンドポイント又はゲートウェイデバイスの安全なアップデートの方法を示すフローチャートである。 図７は、開示されたシステムの様々な例示的な実施形態における、削除（off-boarding）のためのデバイスの除籍及び登録解除の方法を示すフローチャートである。 図８は、開示されたシステムの様々な例示的な実施形態における、複数のデバイスの安全なアップデートをオーケストレーションするためのブロックチェーンアプリケーション及びネットワークサービスのための、プロバイダ、パブリッシャ、及びデバイスのクラスを含むエンティティリレーションシップモデルを示す模式図である。 図９は、開示されたシステムの様々な例示的な実施形態における、複数のデバイスの安全なアップデートをオーケストレーションするためのブロックチェーンアプリケーション及びネットワークサービスのための、アップデートパッケージのプロバイダ、パブリッシャ、及び消費者を含むワークフローモデルを示す模式図である。 図１０は、開示されたシステムの様々な例示的な実施形態における、複数のデバイスのデバイスエンロールメントをオーケストレーションするためのブロックチェーンアプリケーション及びネットワークサービスのための、エンロールメントサービス、認証局サービス、デバイスドメイン、及び複数のタイプのデバイスを含むエンティティリレーションシップモデルを示す模式図である。 図１１は、開示されたシステムの様々な例示的な実施形態における、複数のデバイスのデバイスエンロールメントをオーケストレーションするためのブロックチェーンアプリケーション及びネットワークサービスのための、エンロールメントサービス、認証局サービス、デバイスドメイン、及び複数のタイプのデバイスを含むワークフローモデルを示す模式図である。 図１２は、開示されたシステムの様々な例示的な実施形態における、エンロールメントサービス、アップデートクライアント、及びアップデートサービスのクラウドサービスとのオーケストレーションのワークフローモデルを示す模式図である。 図１３は、開示されたシステムの様々な例示的な実施形態における、多段階検証ブート方法によるプログラムイメージ検証と、攻撃者により偽装された秘密署名鍵の悪用に対する保護対策とを示す模式図である。 図１４はデータプライバシー及び保護のために、エンティティ識別子のポリシーベースの匿名化と、トランザクションレコード内のコンテンツの項目別フィルタリングとを提供するシステム及び方法を示す模式図である。 図１５は、シリコン製造工場、相手先製品製造業者（ＯＥＭ）、プラットフォーム所有者からデバイスの所有者までのデバイスの管理のチェーンを、ブロックチェーンの分散台帳として追跡する、ブロックスキーマを示す模式図である。 図１６は、シリコン製造工場、相手先製品製造業者（ＯＥＭ）、プラットフォーム所有者からデバイス所有者までのデバイスのアプリケーショントラストチェーンを、ブロックチェーンの分散台帳として追跡する、ブロックスキーマを示す模式図である。 図１７は、シリコン製造工場、相手先商標製造業者（ＯＥＭ）、プラットフォーム所有者からデバイス所有者までのサプライチェーンを通じたデバイスの変更管理を、ブロックチェーンの分散台帳として追跡する、ブロックスキーマを示す模式図である。 図１８は、デバイス識別、検出、エンロールメント、及び登録の方法の実施形態が実装され得る例示的なコンピュータシステムの図である。

本開示の更なる適用可能性の領域は、以下に提供される詳細な説明から明らかになるのであろう。例示的な実施形態の詳細な説明は、例示のみを目的としたものであり、したがって、必ずしも本開示の範囲を限定することを目的としたものではないことを理解されたい。

本開示は、特定の実施形態を参照して本明細書に例示され、説明されるが、本開示は、本明細書に示される詳細事項に限定されることを意図するものではない。むしろ、本開示のスコープから逸脱することなく、特許請求の範囲と同等のスコープ及び範囲内で、細部に様々な修正を行うことができる。

例えば商用ＣＡなどの認証局(ＣＡ：Certificate Authority)は、（Ｘ．５０９スタンダードに基づく証明書などの）証明書を発行する証明書サービスプロバイダを指す。プライバシーＣＡは、セキュアエレメント(例えば、トラステッドコンピューティンググループ（ＴＣＧ)仕様に基づくトラステッドプラットフォームモジュール（ＴＰＭ）、製造元が発行した保証鍵に基づくデバイス認証用のネットワーク又はクラウドベースのハードウェアセキュリティモジュール（ＨＳＭ）、又は物理複製困難関数（ＰＵＦ：Physically Unclonable Function)により生成されたデバイスの一意の識別子などのデバイス認証アーティファクトなど）によりサポートされるアイデンティティ証明方法に参加する証明書サービスプロバイダを指す。

デバイスの一意の識別子は、不変の静的な識別子であってもよく、又はデバイスのＰＵＦエンジンを使用して電源投入時に動的に再生成されてもよい。従来のデバイスでは、デジタルフィンガープリントは、プログラム可読デバイスシリアル番号、ブートＲＯＭ内の秘密鍵のワンタイムプログラマブル（ＯＴＰ）ハッシュ、又はハードウェアレジスタベースの一意のデジタル値などのデバイス特性及び属性に基づく暗号署名から構成され得る。

開示されたシステムの例示的な実施形態では、デバイス管理サービスを伴うゲートウェイエンロールメントが、ゲートウェイの一意の識別子を使用して実行されてもよく、セキュアエレメントの保証証明書が、ゲートウェイ証明書リクエストにデジタル署名するために使用されてもよい。発行されたゲートウェイ証明書は、その後、デバイスの一意の識別子を使用して、接続されたデバイスの証明書リクエストにデジタル署名するために使用されてもよい。

開示されたシステムの更に他の例示的な実施形態では、発行されたゲートウェイ証明書は、その後、一意の識別子としてアプリケーション又はサービスプリンシパル名を使用して、ゲートウェイにインストールされ実行されるアプリケーション又はサービスの証明書リクエストにデジタル署名するために使用されてもよい。

図１及び図２を参照すると、非ＩＰエンドポイントデバイス１０１の検出エージェント１０９は、電源投入時に、任意で、構成された周期的間隔に、アイデンティティビーコン１１０を、通信インタフェース１００を介して、接続されたＩＰゲートウェイデバイス１０２の検出サービス１１１に送信する。通信インタフェース１００は、シリアル、パラレル、バス、ＵＳＢインタフェースなどでよい。ステップ１２６で、検出サービス１１１は、ゲートウェイデバイス１０２の適切なインタフェースドライバを介してアイデンティティビーコン１１０を受信する。ステップ１１２で、検出サービス１１１は、デバイス認証及びプロファイリング１１３を実行して、少なくともエンドポイントデバイス識別子２３１を含むアイデンティティビーコン１１０及びデバイスプロファイル２３２の完全性を検証する。ステップ１１５で、検出サービスは、ゲートウェイプロファイル１１４から、少なくともゲートウェイデバイスのゲートウェイ識別子１１５、タイプ、メイク及びモデルを含むゲートウェイデバイス１０２の不変の識別子を取得する。ステップ１１６で、検出サービス１１１は、少なくともエンドポイントデバイスプロファイル２３２及びゲートウェイデバイスプロファイル１１４を含むエンドポイントデバイス１０１の証明書リクエスト１１６を構築し、エンロールメントサービス１０３に送信する。ステップ１１７で、エンロールメントサービス１０３は、エンドポイントデバイスプロファイル２３２及び接続されたゲートウェイプロファイル１１４を拡張属性として有する、エンドポイントデバイス１０１の認証局により発行された証明書を応答する。ステップ１１８で、接続されたエンドポイントデバイス１０１の発行された証明書は、ローカル証明書ストア１２７に格納される。

図１を参照すると、ステップ１１９で、非ＩＰエンドポイントデバイス１０１は、接続されたＩＰゲートウェイデバイス１０２の通信インタフェース１００を介して、接続されたサービス１０６とのデータ交換を開始する。ステップ１２０で、デバイスデータ１２０は、エンドポイントデバイス１０１と接続されたサービス１０６との間でデータ交換を転送するためのプロキシサービスとして機能するクライアントアプリケーション１２１によって受信される。ステップ１２２で、接続されたエンドポイントデバイス１０１に関連付けられた証明書が、ローカル証明書ストア１２７からクライアントアプリケーション１２１により取得される。取得された証明書は、ステップ１２３で、接続されたサービス１０６との安全な通信を確立するために相互認証に使用されてもよく、ステップ１２４で、安全なアップデートのためにアップデートサービス１０７からアップデートパッケージをリクエストするために使用されてもよい。

図１及び図２を参照すると、ステップ１２４で、ゲートウェイデバイス１０２のアップデートクライアント１０８は、構成されたアップデートサービス１０７からアップデートパッケージをリクエストする。アップデートパッケージリクエストは、接続されたエンドポイントデバイス１０１又はゲートウェイデバイス１０２のいずれかのデバイス証明書と、少なくともデバイスの識別子、タイプ、メイク及びモデルを含む関連付けられたデバイスプロファイル１１４、２３２とを含む。

図１を参照すると、ステップ１２５で、デバイス管理サービス１０５は、接続された非ＩＰエンドポイントデバイスに発行された証明書についてゲートウェイデバイス１０２に問い合わせる。

図１及び図２を参照すると、ステップ１２８で、エンロールメントサービス１０３は、エンドポイントデバイス登録の通知をポリシーサービス１０４に送信する。ステップ１２９で、ポリシーサービス１０４は、エンドポイントデバイス１０１をデバイス管理サービス１０５に追加する指令を送信する。ステップ１３０で、エンロールメントサービス１０３は、エンドポイントデバイス１０１の証明書リクエストを認証局４０６に送信し、受信されたエンドポイントデバイス１０１の証明書を処理して、（エンロールメントサービス１０３により認証局４０６から）受信された証明書を、プライバシー認証局を表すように変換し、エンドポイントデバイス１０１の証明書を検出サービス１１１に送信する。（例えばＴＰＭなどの）セキュアエレメント２３５は、例えば、対応する秘密鍵を使用してのみ復号化され得るセキュアエレメント２３５の公開鍵を使用することにより、発行された証明書を暗号化するためにプライバシーＣＡにより利用されるべきアイデンティティ（すなわち秘密）の高度な所有のプルーフをサポートし得る。代替の方法には、鍵導出機能及び保護されたシードを使用して生成された対称鍵を使用することが含まれてもよい。したがって、エンドポイントデバイス１０１のセキュアエレメント２３５が本当に秘密を所有していない限り、証明書は、セキュアエレメント２３５により解読されることができない。商用ＣＡ４０６は、このようなメカニズムをサポートしないことがある。したがって、検出サービス１１１と商用ＣＡ４０６との間のプロキシサービスとして機能するエンロールメントサービス１０３で、変換が実行されてもよい。商用ＣＡ４０６は証明書を発行し、エンロールメントサービス１０３は、アイデンティティの高度な所有のプルーフをサポートするために暗号化された、発行された証明書を含むコンテンツを有する応答メッセージを準備する。

図２を参照すると、ステップ２０２で、イメージサイナー（signer）２０１は、署名仕様２３３に基づいて、公開－秘密非対称鍵ペアを生成し、プログラムイメージ２５０にデジタル署名して、署名されたプログラムイメージ２０３を生成する。ステップ２０４で、生成された鍵ペアに関連付けられた公開鍵が、多段階検証ブートローダ２４０に含まれる。エンドポイントデバイス１０１の電源投入時に、ブロック２０５で、第１段階のブートローダは、制御を実行し、次の段階の多段階検証ブートローダ２４０に制御を転送する。ステップ２０９で、多段階検証ブートローダ２４０は、デバイスプロファイラ２１０を呼び出す。ステップ２１１で、エンドポイントデバイス識別子は、例えばデータバスのエンドポイントアドレス、又はエンドポイントデバイス１０１の不揮発性ストレージ内のワンタイムプログラマブルシリアル番号のような、エンドポイントデバイス１０１の複数のインジケータに基づいて、デバイスプロファイラ２１０により生成される。ステップ２１２で、少なくともエンドポイントデバイス１０１の識別子、タイプ、メイク及びモデルを含むデバイスプロファイル２３２は、プロファイル送信機能２１３により、非対称鍵ペアの公開鍵２１４を使用して署名される。ステップ２１６で、署名されたデバイスプロファイル２３２は、例えばシリアルＲＳ－２３２、ＲＳ－４８５、ＲＳ－４２２、ＣＡＮバス、Ｍｏｄｂｕｓ、ＨＡＲＴ、ＧＰＩＯ、ユニバーサルシリアルバス（ＵＳＢ）インタフェース等の通信リンクを介して、接続されたゲートウェイＩＰデバイス１０２に、通信インタフェース１００を介して送信される。

図２を参照すると、ステップ２０６で、イメージベリファイヤ（verifier）２０７は、多段階検証ブートローダ２４０により実行される。ステップ２０８で、イメージベリファイヤ２０７は、署名されたプログラムイメージ２０３のデジタル署名を再生成し検証する。検証の成功に基づいて、署名されたプログラムイメージがメモリにロードされ、実行される。

図２及び図１を参照すると、ステップ２１７で、署名されたデバイスプロファイル２３２は、ゲートウェイデバイス１０２の物理インタフェース２００を介して、アイデンティティビーコン１１０として受信される。ステップ２１９で、デバイスプロファイル２３２は、プロファイル受信機能２１８により処理される。ステップ２２０で、検出サービス１１１は、プロファイル検証機能２２１を使用して、関連付けられた秘密鍵２２２を使用して、署名されたデバイスプロファイル２３２の完全性を検証する。検出サービス１１１は、デバイスプロファイル２３２を、物理通信インタフェース２００に接続されたエンドポイントデバイス１０１に関連付ける。

開示されたシステムの例示的な一実施形態では、図２を参照すると、ステップ２３４で、イメージサイナー２０１は、例えばトラステッドプラットフォームモジュール（ＴＰＭ）、ネットワークハードウェアセキュリティモジュール（ネットワークＨＳＭ）、クラウドＨＳＭなどのセキュアエレメント２３５を使用して、署名鍵ペアを生成し、秘密署名鍵はセキュアエレメント２３５内で保護される。

開示されたシステムの例示的な一実施形態では、多段階検証ブートローダ２４０は複数の公開鍵を使用してもよく、イメージサイナー２０１は複数の同等の署名鍵を使用して、署名されたプログラムイメージ２０３の署名仕様２３３を使用して複数のデジタル署名を生成してもよい。本方法は、複数の署名鍵をリクエストすることにより、エンドポイントデバイス１０１（又はゲートウェイデバイス１０２）を、紛失及び／又は盗まれた秘密鍵により偽装されることから保護し、迅速なリスク軽減のための対策を提供する。複数の署名鍵の使用は、偽装された署名鍵を使用して署名されたプログラムイメージ２０３のインフィールドアップデートに対する強化された保護のための論理的な「ＡＮＤ」演算として実装されてもよく、或いは、ミッションクリティカルなシステムの冗長性及び高可用性のための論理的な「ＯＲ」演算として実装されてもよい。公開鍵の証明書ベースの検証がない場合、複数の鍵ペアに対する論理的な「ＡＮＤ」及び「ＯＲ」演算は、偽装された鍵に基づく検証をブロックするための効果的な対策を提供する。発行されたＰＫＩ公開鍵の偽装は、例えばリターンオブカッパースミスアタック（ＲＯＣＡ）として記述され、公表された脆弱性などの技術を使用して設計され得る。

開示されたシステムの更に他の例示的な実施形態では、多段階検証ブート２４０の署名仕様２３３は、署名されたプログラムイメージ２０３内にゆるい配置順序で存在するデジタル署名のみの、及びそのうちの少なくとも２つの検証と、一意性のために鍵ペアごとに異なる署名仕様の使用とを必要とし得る。本方法は、多段階検証ブートローダ２４０に埋め込まれた偽装された公開鍵が交換されるまで（すなわち、鍵のリニューアルまで）、署名されたプログラムイメージ２０３のパブリッシャが、デバイスの偽装された公開鍵を使用することなく、デバイスをアップデートすることを可能にする。

開示されたシステムの更に他の例示的な実施形態では、多段階検証ブートローダ２４０の署名仕様２３３は、多段階検証ブートローダ２４０の公開鍵の厳密な配置順序を一致させるための、署名されたプログラムイメージ２０３のデジタル署名の順序付けられたリストと、ただ１つの偽装された公開－秘密鍵ペアの潜在的な乱用からの保護のための、一意性のために鍵ペアごとに異なる署名仕様の使用とを必要とし得る。偽装された署名鍵を使用して署名されたプログラムイメージ２０３のアップデートの誤りは、論理「ＡＮＤ」演算の使用及び署名仕様２３３による厳格な配置順序を必要とするこのような対策により保護される。

ブロック２０３で検証される署名されたプログラムイメージ２５０は、第１段階のブートローダ、次の段階（例えば第２段階等）のブートローダ、又はデバイスのオペレーティングシステム（ＯＳ）ローダであってもよい。ブロック２０５の多段検証ブートローダ２４０は、ブートシーケンスの任意の段階で導入されてもよく、ＯＳを検証しロードするデバイスのブートＲＯＭと同じくらい初期段階から導入されてもよい。多段階検証ブートローダ２４０は、後続段階のブートローダへのいかなる修正も必要とせずに、複数の後続段階のブートローダ、イメージ、構成及びデータファイルを検証するために、ブートシーケンス（又はチェーン）に導入されてもよい。

図３、図１及び図２を参照すると、ステップ３０１で、ゲートウェイデバイス１０２の検出サービス１１１は、エンロールメントサービス１０３に対するエンドポイントデバイスプロファイル２３２及びゲートウェイデバイスプロファイル１１４を含むエンロールメントサービス１０３の一方向証明書検証を伴う、安全な転送により、エンドポイントデバイス１０１のエンロールメントリクエストを送信する。ステップ３０４で、エンロールメントサービス１０３は、ゲートウェイデバイス１０２及びエンドポイントデバイス１０１の認証と、構成されたオーケストレーションルール３０５に基づくエンロールメントリクエストの検証とを実行する。デバイスの認証は、Ｘ．５０９証明書又はＪＷＴベースの方法を使用して実行されてもよい。ステップ３０６で、エンロールメントサービス１０３は、リモートセキュアエレメント３０７を使用してＰＫＩ公開鍵－秘密鍵ペアを生成する。ステップ３０８で、生成されたエンドポイントデバイス１０１に関連付けられた公開鍵は、安全な転送により、検出サービス１１１に送信される。エンドポイントデバイス１０１に関連付けられた秘密鍵は、リモートセキュアエレメント３０７に安全に格納される。ステップ３１２で、エンドポイントデバイス１０１に関連付けられた公開鍵は、エンドポイントデバイス１０１による暗号化又は署名のためにローカル鍵ストア３１３に格納され、或いは、ステップ１２３で、エンドポイントデバイス１０１の安全なアップデートのためにローカル鍵ストア３１３に格納される。

開示されたシステムの例示的な一実施形態では、ネットワーク又はクラウドベースのＨＳＭが、リモートセキュアエレメント３０７として構成され得る。

開示されたシステムの他の例示的な実施形態では、ステップ３０９で、デバイスエンロールメントのトランザクションレコードは、エンロールメントサービス１０３により、データベース機能３１１を含むローカル台帳３１０に追加されてもよい。ステップ３１４で、ローカル台帳３１０は、ブロックチェーン内のアプリケーションとのオーケストレーションのためのデバイスエンロールメントトランザクションのブロックを表すイベント３１５を発する。

開示されたシステムの更に他の例示的な実施形態では、ステップ３０１で、エンロールメントリクエストは、ゲートウェイデバイス１０２に対するものであってもよい。ステップ３１２で、ゲートウェイデバイス１０２に関連付けられた公開鍵は、ゲートウェイデバイス１０２による暗号化又は署名のために、或いはゲートウェイデバイス１０２の安全なアップデートのために、ローカル鍵ストア３１３に格納される。

図４、図１、図２、及び図３を参照すると、ステップ４０２で、検出サービス１１１は、鍵ペアの秘密鍵を保護するために、ローカルセキュアエレメント４０１を使用してＰＫＩ非対称鍵ペアを生成する。ステップ４０３で、検出サービス１１１は、エンドポイントデバイスプロファイル２３２及びゲートウェイデバイスプロファイル１１４を含むデバイスの証明書署名リクエスト（ＣＳＲ）を送信する。ＣＳＲは、認証局４０６により暗号化された証明書を、保証公開鍵を使用して復号化するための、秘密鍵の所有のプルーフとして、保証公開鍵又はローカルセキュアエレメント４０１の証明書を含んでもよい。ステップ４０４で、エンロールメントサービス１０３は、ゲートウェイデバイス１０２及びエンドポイントデバイス１０１の認証と、構成されたオーケストレーションルール３０５に基づくエンロールメントリクエストの検証とを実行する。ステップ４０５で、エンロールメントサービス１０３は、構成されたコネクタ属性、例えばコスト、証明書タイプ、証明書プロバイダなどに基づいて、コネクタを使用して、複数の認証局４０６のうちの１つに、デバイスの証明書をリクエストする。ステップ４０７で、認証局（ＣＡ）が発行したエンドポイントデバイスの証明書は、少なくともエンドポイントデバイスプロファイル２３２及び接続されたゲートウェイデバイスプロファイル１１４を拡張属性として含んでもよく、エンロールメントサービス１０３からゲートウェイデバイス１０２の検出サービス１１１に送信される。ステップ４０９で、検出サービス１１１は、受信されたエンドポイントデバイスの証明書をローカル証明書ストア１２７に格納して、（ステップ１２３で）セキュアなデータ転送を提供し、（ステップ１２４で）エンドポイントデバイス１０１のアップデートパッケージをリクエストする。

開示されたシステムの他の例示的な実施形態では、ステップ４０８で、デバイスエンロールメントのトランザクションレコードは、エンロールメントサービス１０３により、データベース機能を実行するデータベース３１１を含むローカル台帳３１０に追加されてもよい。ステップ４１０で、台帳３１０は、ブロックチェーン内のアプリケーションとのオーケストレーションのためのデバイスエンロールメント及び登録トランザクションのブロックを表すイベント４１１を発する。

図５及び図１を参照すると、ステップ５０１で、エンロールメントサービス１０３は、デバイスエンロールメントの通知を、少なくともエンドポイントデバイスプロファイル２３２及び発行されたエンドポイントデバイスの証明書とともに、ＡＰＩを介して、又はメッセージバスインタフェースでの発行（publish）を介して、ポリシーサービス１０４に送信する。ステップ５０２で、ポリシーサービス１０４は、ＡＰＩを介して、又は、メッセージバスインタフェースでの発行を介して、デバイス管理サービス１０５にデバイスを追加する。

図６、図１、図３、及び図４を参照すると、アップデートプロバイダ６０１は、ディベロップメントシステム６０４及びリリース管理システム６０８を含み、アップデートパブリッシャ６０２は、アップデートサービス１０７、ローカル台帳６２５、オーケストレーションルール６２４、及びイベント６２３を含み、エンドポイントデバイス１０１又はゲートウェイデバイス１０２は、アップデートクライアント６０３及びローカルセキュアエレメント４０１を含む。ステップ６０５で、ディベロップメントシステム６０４のディベロッパは、アップデートスクリプトと、例えばファームウェアアップデート、ソフトウェアアップデート、構成アップデート、オペレーティングシステムパッチ／アップデート、デバイスポリシーなどの複数のコンポーネントアップデートを含むパッケージエレメント６０６から、署名されていないアップデートパッケージ６０７を構築する。ステップ６０７で、署名されていないアップデートパッケージは、リリース管理システム６０８のリリースマネージャにより処理され、ローカルレジストリ（例えば、データベースなど）に格納される。リリース管理システム６０８は、署名及び暗号化されたアップデートパッケージを構築し、署名はプロバイダ署名鍵６０９を使用して実行され、暗号化はパブリッシャ証明書６１０を使用して実行される。ステップ６１１で、アップデートパブリッシャ６０２のアップデートサービス１０７は、アップデートパブリッシャ６０２の公開鍵を使用して暗号化された、署名及び暗号化されたアップデートパッケージを調達し、ローカルレジストリ（例えばデータベースなど）に格納する。アップデートプロバイダ６０１は、複数のアップデートパブリッシャ６０２のための署名及び暗号化されたパッケージを構築するように構成されてもよい。ステップ６１２で、アップデートサービス１０７は、プロビジョニングされたオーケストレーションルール６２４を使用して、アップデートパッケージを、例えばデバイスタイプ、メイク、モデル、ベンダ識別子などの複数のデバイス属性により、指定されたデバイスクラスに構成する。ステップ６１６で、ゲートウェイデバイス１０２のアップデートクライアント６０３は、自ら、或いは接続されたエンドポイントデバイス１０１に代わって、アップデートパッケージのリクエストをアップデートサービス１０７に送信する。リクエストは、拡張属性としてデバイスプロファイル（例えば、エンドポイントデバイスプロファイル２３２又は接続されたゲートウェイデバイスプロファイル１１４）を有するデバイス証明書（すなわち、エンドポイントデバイス１０１又はゲートウェイデバイス１０２の暗号化証明書）を少なくとも含む。デバイスリクエストは、デバイス署名鍵を使用してデジタル署名されたデバイスマニフェスト（すなわち、デジタル署名を検証するためにアップデートサービスのデバイスリクエストにも含まれるデバイス署名証明書に関連付けられた）を含んでもよく、デバイスマニフェストは、アップデートサービスとの事前の（過去の）相互作用に基づいて、現在インストールされているアップデートパッケージのリストである。このステップは、潜在的なマンインザミドル（ＭＩＴＭ）攻撃、デバイスへの正当なアップデートパッケージの配布をブロックする偽装攻撃、及び／又は脆弱性を悪用するリバースエンジニアリングのためのアップデートパッケージの傍受から保護する。ステップ６１９で、リクエストされたアップデートパッケージは、受信されたデバイス証明書を使用して再暗号化され、アップデートサービス１０７によりパブリッシャ署名鍵６１８を使用して再署名される。

開示されたシステムの他の例示的な実施形態では、ステップ６２０で、少なくとも署名及び暗号化されたデバイスリクエストログを含む、デバイスアップデートのためのトランザクションレコードが生成され、データベース機能３１１を含むローカル台帳３１０に格納される。ステップ６１７で、ローカル台帳６２５は、ブロックチェーン内のアプリケーションとのオーケストレーションのためのデバイスアップデートトランザクションのブロックを表すイベント６２３を発する。ステップ６２１で、アップデートクライアント６０３は、まず、プロバイダ証明書６１５からの公開鍵及びパブリッシャ証明書６１４からの公開鍵を使用して、受信されたアップデートパッケージの完全性を検証する。ステップ６２２で、アップデートクライアント６０３は、（自己のアップデートのための）エンドポイントデバイス１０１（又はゲートウェイデバイス１０２）の秘密鍵並びにローカルセキュアエレメント４０１を使用して、受信されたアップデートパッケージを復号化する。

開示されたシステムの例示的な一実施形態では、複数のデバイスは、デバイス証明書及び関連付けられた秘密鍵を共有するように構成されてもよい。アップデートサービス１０７は、このような構成で、パフォーマンス最適化のためのデバイス証明書のハッシュと、多数のデバイスに対するアップデートのスケーラビリティとを使用して、ステップ６１９で、生成されたアップデートパッケージをキャッシュしてもよい。

図７、図１、図３、及び図４を参照すると、アドミニストレータ７００は、アドミニストレーションダッシュボード７０１において、登録及びエンロールメントされたエンドポイントデバイス１０１又はゲートウェイデバイス１０２の登録解除及び除籍のためのアクションを実行する。ステップ７０２で、アドミニストレーションダッシュボード７０１は、デバイス証明書の証明書取消リクエストをエンロールメントサービス１０３に送信する。ステップ７０３で、エンロールメントサービス１０３は、構成されたオーケストレーションルール３０５に基づいて、アドミニストレータ認証及び取消リクエストの検証を行う。ステップ７０４で、エンロールメントサービス１０３は、証明書取消リクエストを、コネクタを介して発行した認証局４０６に送信する。ステップ７０６で、エンロールメントサービス１０３は、ＡＰＩを介して、又はメッセージバスインタフェースでの発行を介して、ポリシーサービス１０４にデバイス除籍の通知を送信する。ステップ７０７で、ポリシーサービス１０４は、ＡＰＩ又はメッセージバスインタフェースでの発行を介して、デバイスをデバイス管理サービス１０５から除去する。

開示されたシステムの他の例示的な実施形態では、ステップ７０５で、デバイス除籍のトランザクションレコードは、エンロールメントサービス１０３により、データベース機能３１１を含むローカル台帳３１０に追加されてもよい。ステップ７０８で、台帳３１０は、ブロックチェーン内のアプリケーションとのオーケストレーションのためのデバイス除籍及び登録解除トランザクションのブロックを表すイベント７０９を発する。

図８を参照すると、エンドポイントデバイス１０１又はゲートウェイデバイス１０２の安全なデバイスアップデートをオーケストレーションするためのエンティティ及びエンティティリレーションシップが示されている。任意の２つのエンティティ間のコネクタ８００は、１対多のリレーションシップを示す。表１（下記）では、エンティティオブジェクトと属性が示される。

図９、図８及び図６を参照すると、エンドポイントデバイス１０１又はゲートウェイデバイス１０２に安全なアップデートをオーケストレーションするためのワークフローが示されている。ステップ９０２で、プロバイダ９０３のディベロッパ９０１は、アップデートパッケージを構築する。ステップ９０４で、プロバイダ９０３のリリースマネージャは、プロバイダ秘密鍵を使用してアップデートパッケージに署名し、パブリッシャ公開鍵を使用してアップデートパッケージを暗号化して、プロバイダパッケージ８３３を構築する。ステップ９１２で、パブリッシャ９１３により操作されるアップデートサービス９１１のアドミニストレータは、プロバイダパッケージ８３３を承認する。ステップ９１５で、アドミニストレータはデバイスタイプ９２３を定義し、さらに、ステップ９２２で、デバイス９２１をデバイスタイプ９２３に属するようにプロビジョニングする。ステップ９１６で、アドミニストレータは、プロバイダパッケージを復号化し、パブリッシャ秘密鍵を使用してアップデートパッケージに再署名し（ステップ９０４でのプロバイダによる第１の署名を保持）、安全なストレージのためにパブリッシャ公開鍵を使用してアップデートパッケージを再暗号化する。プロバイダにより保持された第１の署名は、サプライチェーンワークフローにおける改ざん保護を提供する。ステップ９１８で、アップデートサービス９１１のアドミニストレータは、パブリッシャアップデートパッケージ９１７をデバイスタイプ９２３に関連付ける。ステップ９２４で、デバイス９２１は、パブリッシャアップデートパッケージ９１７の、デバイス証明書を含む署名されたリクエストを、アップデートサービス９１１に送信する。ステップ９２５で、アップデートサービス９１１は、パブリッシャ秘密鍵を使用してパブリッシャアップデートパッケージを復号化し、受信されたデバイス証明書から抽出されたデバイス公開鍵を使用してアップデートパッケージを再暗号化する。ステップ９２６で、アップデートサービス９１１は、ローカル台帳６２５のデバイスリクエストストレージ９２７に、少なくとも署名及び暗号化されたデバイスリクエストログを含むトランザクションレコードを生成する。

図１０を参照すると、エンドポイントデバイス１０１又はゲートウェイデバイス１０２のエンロールメントをオーケストレーションするためのエンティティ及びエンティティリレーションシップが示されている。任意の２つのエンティティ間のコネクタ８００は、１対多のリレーションシップを示す。表２（下記）では、エンティティオブジェクトと属性が示される。

図１１を参照すると、エンドポイントデバイス１１０１、ゲートウェイデバイス１０２、又はエンロールメントされたデバイスのアプリケーションのエンロールメントをオーケストレーションするためのワークフローが示されている。ステップ１１０２で、デバイス１１０１は、一意のデバイス識別子を含むエンロールメントリクエストをエンロールメントサービス１１０３に送信する。ステップ１１０４で、エンロールメントサービス１１０３はデバイス認証を実行し、任意で、認証局に関連付けられたドメインサーバ１１０５とともにエンロールメントリクエストを検証してもよい。ステップ１１０６で、エンロールメントサービスは、ＡＰＩを介して、又はメッセージバスインタフェースでの発行を介して、認証局サービス１１０７にデバイスエンロールメントリクエストを送信する。ステップ１１０８で、認証局サービス１１０７は、デバイス証明書１１０９を生成し、ステップ１１１０で、デバイス証明書１１０９は、エンロールメントサービス１１０３によりデバイス１１０１に発行される。

開示されたシステムの例示的な一実施形態では、ステップ１１１２で、デバイス１１０１のアプリケーション１１１１は、アプリケーション（又はサービス）プリンシパル名に基づく一意の識別子を含むエンロールメントリクエストを、エンロールメントサービス１１０３に送信する。ステップ１１１６で、エンロールメントサービス１１０３は、エンロールメントドメインに関連付けられたドメインサーバ１１０５とともにアプリケーション認証を実行する。ステップ１１０６で、エンロールメントサービスは、ＡＰＩを介して、又はメッセージバスインタフェースでの発行を介して、認証局サービス１１０７にアプリケーションエンロールメントリクエストを送信する。ステップ１１１３で、認証局サービス１１０７は、アプリケーション証明書１１１４を生成し、ステップ１１１５で、アプリケーション証明書１１１４は、エンロールメントサービス１１０３によりアプリケーション１１１１に発行される。

図１２及び図１を参照すると、それぞれエンロールメントサービス１０３及びアップデートサービス１０７をクラウドサービス１２０２と統合することにより、エンドポイントデバイス１０１又はゲートウェイデバイス１０２のデバイスエンロールメント及び安全なアップデート動作を統合するためのワークフローが示されている。クラウドサービスプロバイダは、パブリック、プライベート、又はコミュニティのクラウド事業者であってもよく、サービスは、ソフトウェアアズアサービス（ＳａａＳ）又はプラットフォームアズアサービス（ＰａａＳ)ソリューションとして提供されてもよい。ＩｏＴデバイスは、エンロールメント及びアップデートサービスのためにクラウドサービス１２０２に直接登録されてもよい。クラウドサービス１２０２は、サードパーティのエンロールメント及びアップデートサービスのためのＡＰＩベースのコネクタを提供してもよい。

開示されたシステムの例示的な一実施形態では、図１２及び図１を参照すると、ステップ１２０３で、エンロールメントサービス１０３は、デバイスの登録（又は登録解除）通知をクラウドサービス１２０２に送信して、クラウド接続されたデバイスに追加（又は削除）する。ステップ１０２で、エンロールメントサービス１０３は、ポリシーサービス１０４に通知し、ステップ１２０５で、ポリシーサービスは、ＡＰＩを介して、又は、メッセージバスインタフェースでの発行を介して、デバイスをデバイス管理サービス１０５に追加又は削除する。

開示されたシステムの更に他の例示的な実施形態では、図１２、図６、及び図１を参照すると、ステップ１２０６で、エンドポイントデバイス１０１又はゲートウェイデバイス１０２のアップデートクライアント６０３は、少なくともデバイス証明書を含む、アップデートパッケージのリクエストをクラウドサービス１２０２に送信する。ステップ１２０７で、クラウドサービス１２０２は、受信されたアップデートパッケージのリクエストをデバイスからアップデートサービス１０７に転送してもよい。代替の方法では、クラウドサービスは、複数のデバイスタイプの署名及び暗号化されたアップデートパッケージをプレロードし、キャッシュしてもよい。ステップ１２０８で、アップデートサービス１０７は、デバイスの署名及び暗号化されたアップデートパッケージをクラウドサービス１２０２に送信して、（ステップ１２０９で）デバイスに転送する。

開示されたシステムの例示的な実施形態では、エンドポイントデバイス１０１又はゲートウェイデバイス１０２は、複数のアップデートパブリッシャ６０１に関連付けられた複数のアップデートサービスを使用して、複数のアップデートプロバイダ６０２のアップデートパッケージをリクエストしてもよい。

開示されたシステムの例示的な実施形態では、ローカル台帳３１０内のトランザクションレコード３０９、４０８、６２０、７０５は、ネットワークピアに配布され、エンロールメントサービス１０３又はアップデートサービス１０７により、エンドポイント又はゲートウェイデバイスの署名及び暗号化されたデバイスリクエストログのハッシュを使用してチェーン接続される。さらに、ブロックチェーン内の分散台帳内のトランザクションレコードは、アップデートパッケージプロバイダ６０１及びパブリッシャ６０２のサプライチェーンにわたるクロスドメイントレーサビリティのためのデバイス及びサービストランザクションの再現可能な履歴を提供する。

開示されたシステムの例示的な実施形態では、複数の中間パブリッシャが、アップデートパッケージのディストリビュータとして機能することができ、各々の中間パブリッシャがアップデートパッケージに署名する。

開示されたシステムの例示的な実施形態では、エンロールメントサービス１０３が、エンドポイントデバイス１０１又はゲートウェイデバイス１０２の証明書のデジタルハッシュダイジェストを使用して、ＡＰＩを介してクラウドサービスと統合し、デバイスをエンロールメントする。さらに、アップデートサービス１０７は、ＡＰＩを介してクラウドサービスと統合し、クラウドサービスにエンロールメントされたデバイスにアップデートパッケージを配布する。

開示されたシステムの例示的な実施形態では、ローカルセキュアエレメント４０１は、例えばトラステッドプラットフォームモジュール（ＴＰＭ）、サブスクライバアイデンティティモジュール（ＳＩＭ）、安全な鍵生成及び鍵記憶能力を有するマイクロコントローラベースの暗号エンジンなどであってもよい。リモートセキュアエレメント３０７は、ネットワーク又はクラウドベースのＨＳＭであってもよい。

図１３及び図２を参照すると、ブロック１３００で、多段階検証ブートローダ１３０１（ブロック２０５の実施形態２４０）は、プログラムイメージ１３０２（ブロック２０３の実施形態２５０）のデジタル署名を検証する。ステップ１３０３、１３０４、１３０５で、デジタル署名Ａ、Ｂ、及びＣは、検証され得る複数の鍵及びデジタル署名の例として、それぞれ鍵Ａ、Ｂ、及びＣを使用して検証される。本方法は、真正なパブリッシャが複数の署名鍵を使用してプログラムイメージに署名する論理ＡＮＤ演算を示す。ブロック１３２０で、多段階検証ブートローダ１３２１（ブロック２０５の実施形態２４０）は、プログラムイメージ１３２３、１３２５、又は１３２７（ブロック２０３の実施形態２５０）のデジタル署名を検証する。ステップ１３２２、１３２４、及び１３２６で、デジタル署名Ａ、Ｂ、又はＣは、検証され得る複数の鍵及びデジタル署名の例として、鍵Ａ、Ｂ、又はＣを使用して検証される。本方法は、真正なパブリッシャが複数の署名鍵のうちの１つだけを使用してプログラムイメージに署名する論理ＯＲ演算を示す。

ブロック１３４０で、ワークフローは、一例として、公開鍵Ａに関連付けられた偽装された秘密署名鍵を扱うための対策を示す。プログラムイメージの真正なパブリッシャ（ブロック２０３の実施形態２５０）は、偽装された鍵Ａの使用を期限切れにし、鍵Ｂ及びＣを使用してプログラムイメージに署名する。ステップ１３４３及び１３４４で、多段階検証ブートローダ１３４１（ブロック２０５の実施形態２４０）は、署名されたプログラムイメージに含まれる一意のデジタル署名のすべて、及び少なくとも２つを検証する。偽装された鍵Ａの使用は、パブリッシャによって除外された。本方法は、複数の鍵のペアを使用した非ブロック論理ＡＮＤ演算を示す。ステップ１３４６で、多段階検証ブートローダ１３４１は、偽装された鍵を所有する攻撃者により偽装された署名鍵Ａを使用して生成された、署名されたプログラムイメージ１３４５内のデジタル署名を検証する。しかしながら、署名されたプログラムイメージの少なくとも２つのデジタル署名に対する署名仕様２３３の要件は、プログラムイメージ検証を不適格にし、攻撃者のプログラムイメージ１３４５からデバイスを保護する。ステップ１３４９で、多段階検証ブートローダ１３４１は、偽装された鍵を所有する攻撃者により偽装された署名鍵Ａを使用して生成された、署名されたプログラムイメージ１３４７内の２つのデジタル署名を検証する。しかしながら、署名されたプログラムイメージにおけるデジタル署名の一意性の署名仕様２３３の要件は、プログラムイメージ検証を不適格にし、攻撃者のプログラムイメージ１３４７からデバイスを保護する。

例示的な実施形態は、ゲートウェイデバイス１０２に接続されたエンドポイントデバイス１０１のエンロールメント及び登録のためのデバイス識別の方法を対象とする。本方法は、多段階検証ブートローダ２４０、エンドポイントデバイス１０１における検出エージェント１０９、ゲートウェイデバイス１０２における検出サービス１１１、エンロールメントサービス１０３、ポリシーサービス１０４、及びデバイス管理サービス１０５を使用する。本方法は、エンドポイントデバイス１０１の検出エージェント１０９により、ゲートウェイデバイス１０２の検出サービス１１１に、エンドポイントデバイスプロファイル２３２を有する認証されたアイデンティティビーコン１１０を送信することを含み得る。本方法は、検出サービス１１１により、エンドポイントデバイス１０１及びエンドポイントデバイスプロファイル２３２の認証を検証することと、検出サービス１１１により、プライバシー認証局からエンドポイントデバイス１０１の証明書リクエスト１１６を生成することとを含み得る。本方法は、検出サービス１１１により、エンドポイントデバイス１０１の証明書リクエストをエンロールメントサービス１０３に送信することを含み得る。本方法は、エンロールメントサービス１０３により、受信されたエンドポイントデバイス１０１の証明書リクエストを処理して認証局４０６への証明書リクエストに変換することと、エンロールメントサービス１０３により、変換されたエンドポイントデバイス１０１の証明書リクエストを認証局４０６に送信することとを含み得る。本方法は、エンロールメントサービス１０３により、認証局４０６により発行されたエンドポイントデバイス１０１の証明書を受信することと、エンロールメントサービス１０３により、エンドポイントデバイス１０１の受信された証明書を処理して、受信されたエンドポイントデバイス１０１の証明書を、プライバシー認証局を表すように変換することとを含むことができる。本方法は、エンロールメントサービス１０３により、エンドポイントデバイス１０１の証明書を検出サービス１１１に送信することと、エンロールメントサービス１０３により、エンドポイントデバイス登録の通知をポリシーサービス１０４に送信することとを含み得る。本方法は、ポリシーサービス１０４により、エンドポイントデバイス１０１をデバイス管理サービス１０５に追加するための指令を送信することと、検出サービス１１１により、発行されたエンドポイントデバイスの証明書をローカル証明書ストア１２７に格納することとを含み得る。

例示的な実施形態では、アイデンティティビーコン１１０は、一意のエンドポイントデバイス識別子２３１、エンドポイントデバイスタイプ、エンドポイントデバイスメイク、及びエンドポイントデバイスモデルを含み、エンドポイントデバイス識別子２３１は、電源投入からのエンドポイントデバイスの多段階検証ブートシーケンスに基づいて認証される。

例示的な実施形態では、多段階検証ブートシーケンスは、イメージサイナー２０１により対応する秘密署名鍵を使用して生成されたデジタル署名を検証するために、公開鍵の複数のマッチングセットを使用して、エンドポイントデバイス１０１の署名されたプログラムイメージに関連付けられた複数セットのデジタル署名を検証する多段階検証ブートローダによって実行される。

例示的な実施形態では、検証されるプログラムイメージは、エンドポイントデバイス１０１の第１段階のブートローダ、第２段階のブートローダ、及びオペレーティングシステムローダのうちの少なくとも１つであって、多段階検証ブートローダ２４０は、ブートシーケンスの任意の段階に導入されてもよい。

例示的な実施形態では、デジタル署名は、署名及び検証プロセスに関連付けられた１つ又は複数の公開－秘密鍵ペアの偽装を検出するための対策として、論理ＡＮＤ又はＯＲ演算子に基づいて検証され、デジタル署名及び署名一致基準の配置順序は、署名仕様に基づく。

例示的な実施形態では、論理ＡＮＤ演算は、検証されるべき署名されたプログラムイメージ内の少なくとも２つの一意のデジタル署名を必要とする。

例示的な実施形態では、多段階検証ブートローダ２４０は、後続段階のブートローダへのいかなる修正も必要とせずに、複数の後続段階のブートローダ、イメージ、構成、及びデータファイルの検証を進めるためにブートシーケンスに導入される。

例示的な実施形態は、アドミニストレーションダッシュボード７０１、エンロールメントサービス１０３、ポリシーサービス１０４、及びデバイス管理サービス１０５を使用してデバイス１０１、１０２を登録解除する方法を対象とする。本方法は、認証された特権ユーザにより、アドミニストレーションダッシュボード７０１から、デバイス証明書を取消す動作を開始することと、エンロールメントサービス１０３により、取消コマンド７０４を認証局４０６に送信することとを含み得る。本方法は、エンロールメントサービス１０３により、デバイス証明書取消の通知をポリシーサービス１０４に送信することを含み得る。本方法は、ポリシーサービス１０４により、デバイス管理サービス１０５に、デバイス１０１、１０２を削除する指令を送信することを含み得る。

例示的な実施形態は、ゲートウェイデバイス１０２の検出サービス１１１をブロックチェーンアプリケーションとして使用し、ネットワークのエンロールメントサービス１０３をブロックチェーンネットワークピアとして使用する、エンドポイントデバイス１０１のエンロールメントの方法を対象とする。本方法は、検出サービス１１１により、エンドポイントデバイス１０１のエンロールメントリクエスト３０１をネットワークのエンロールメントサービスに送信することを含む。本方法は、エンロールメントサービス１０３により、エンロールメントリクエスト３０１を受信し、ゲートウェイデバイス１０２を認証することを含み得る。本方法は、エンロールメントサービス１０３により、ネットワークのネットワークサービスのために確立されたオーケストレーションルール３０５に基づいて、認証局４０６により発行されたエンドポイントデバイス１０１の証明書を生成することを含み得る。本方法は、エンロールメントサービス１０３により、エンドポイントデバイス１０１の証明書をゲートウェイデバイス１０２に送信することを含み得る。本方法は、アップデートサービス１０７により、エンドポイントデバイスのリクエストログをトランザクションレコード３０９としてローカル台帳３１０に記録することと、トランザクションレコード３０９のブロックをブロックチェーンピアに配布して、デバイス履歴を再現するために、分散台帳を維持することとを含み得る。

例示的な実施形態では、エンドポイントデバイスのリクエストログは、署名され、暗号化され、少なくとも、リクエストカウンタ、リクエスト動作データ、リクエストタイムスタンプ、リクエストノンス、デバイスリクエスト署名、リクエストハッシュ、デバイス署名、デバイス証明書識別子、パブリッシャ署名、パブリッシャ証明書識別子、パッケージ識別子、デバイス識別子、プロバイダ識別子、及びパブリッシャ識別子を含む。

例示的な実施形態では、ブロックチェーン内の分散台帳は、アップデートパッケージプロバイダ及びパブリッシャのサプライチェーンにわたるクロスドメイントレーサビリティのために、デバイス及びサービストランザクションの履歴を再現するのに十分なトランザクションレコードを有する。

例示的な実施形態では、エンドポイントデバイス１０１の除籍のために認証局４０６への証明書取消リクエスト７０４をエンロールメントサービス１０３により生成し、エンドポイントデバイス１０１のリクエストログをトランザクションレコードとしてローカル台帳に記録するために、デバイス除籍リクエスト７０２がアドミニストレーションダッシュボード７０１から発行され得る。

例示的な実施形態は、アップデートプロバイダ６０１により操作されるディベロップメントシステム６０４及びリリース管理システム６０８、アップデートパブリッシャ６０２により操作されるアップデートサービス１０７、デバイス１０１、１０２上のアップデートクライアント６０３、並びにデバイス１０１、１０２上のローカルセキュアエレメント４０１を使用して、登録されたデバイス（例えば、エンドポイントデバイス１０１、ゲートウェイデバイス１０２）をアップデートする方法を対象とする。本方法は、ディベロップメントシステム６０４に、ファームウェアアップデート、ソフトウェアアップデート、構成アップデート、及びアップデートスクリプトの少なくとも１つを含むアップデートパッケージを構築することを含み得る。本方法は、リリース管理システム６０８により、プロバイダ署名鍵６０９を使用してアップデートパッケージ６０７に署名することを含むことができ、ここで、第１のデジタル署名がアップデートパッケージに含まれる。本方法は、リリース管理システム６０８により、アップデートパッケージの初期暗号化のために、アップデートパブリッシャ６０２のパブリッシャ証明書６１０からのパブリッシャ公開鍵を使用して、署名されたアップデートパッケージを暗号化することを含み得る。本方法は、リリース管理システム６０８により、署名及び暗号化されたアップデートパッケージ６１１をアップデートサービス１０７に送信することを含み得る。本方法は、デバイス１０１、１０２上のアップデートクライアント６０３により、アップデートパッケージをリクエストすることを含み得る。リクエストは、少なくとも、デバイスのベンダ識別子、型番、及びデバイス証明書６１３を含み得る。本方法は、アップデートサービス１０７により、パブリッシャ署名鍵６１８を使用して、署名されたアップデートパッケージを再署名することを含み得る。第２のデジタル署名は、アップデートパッケージに含まれる。本方法は、アップデートサービス１０７により、アップデートパッケージの最終暗号化のために、アップデートパブリッシャ６０２からのパブリッシャ秘密鍵を使用して初期暗号化を復号化し、デバイス証明書６１３からのデバイス公開鍵を使用してアップデートパッケージを暗号化することにより、二重に署名されたアップデートパッケージを再暗号化することを含み得る。本方法は、アップデートサービス１０７により、暗号化され二重に署名されたアップデートパッケージ６１９をデバイス１０１、１０２上のアップデートクライアント６０３に送信することを含み得る。本方法は、アップデートクライアント６０３により、デバイス１０１、１０２のデバイス秘密鍵を使用して、暗号化されたアップデートパッケージを復号化することを含み得る。本方法は、アップデートクライアント６０３により、アップデートプロバイダ６０１と認証局４０６により発行されたパブリッシャ証明書とのそれぞれの公開鍵を使用して、第１及び第２のデジタル署名を検証することを含み得る。例示的な実施形態では、アップデートスクリプトは、アップデートパッケージをデバイス１０１、１０２に適用するために、デバイスで実行される。

例示的な実施形態では、アップデートパッケージの初期暗号化は、対称鍵を使用して実行され、さらに、対称鍵は、パブリッシャ公開鍵を使用して暗号化される。アップデートパッケージのメッセージダイジェストが生成され、メッセージダイジェストの第１のデジタル署名が、アップデートプロバイダ６０１からのプロバイダ秘密鍵を使用して生成される。第１のデジタル署名は、パブリッシャ公開鍵を使用してさらに暗号化される。

例示的な実施形態では、アップデートパッケージの最終暗号化は対称鍵を使用して実行され、さらに、対称鍵はデバイス公開鍵を使用して暗号化される。アップデートパッケージのメッセージダイジェストが生成され、メッセージダイジェストの第２のデジタル署名が、アップデートプロバイダ６０１からのパブリッシャ秘密鍵を使用して生成される。第２のデジタル署名は、デバイス公開鍵を使用してさらに暗号化される。

例示的な実施形態では、暗号化のためのデバイス秘密－公開鍵ペアは、デバイス１０１、１０２上のセキュアエレメント４０１により生成されてもよく、デバイス秘密鍵は、セキュアエレメント４０１内で保護される。デバイス公開鍵のデバイス証明書は、認証局４０６により発行される。

例示的な実施形態は、ブロックチェーンアプリケーションとしてのデバイス１０１、１０２上のアップデートクライアント６０３、ブロックチェーンネットワークピアとしてのネットワークのアップデートサービス１０７、オーケストレーションルール６２４、及び台帳６２５を使用して、デバイス（例えば、エンドポイントデバイス１０１、ゲートウェイデバイス１０２）をアップデートする方法を対象とする。本方法は、アップデートクライアント６０３により、ネットワークのアップデートサービス１０７からデバイス１０１、１０２のアップデートパッケージのデバイスリクエスト６１６を送信することを含み得る。本方法は、アップデートサービス１０７により、デバイスリクエストを受信し、デバイス１０１、１０２を認証することを含み得る。本方法は、アップデートサービス１０７により、受信したデバイスマニフェストに基づいて、ネットワークのネットワークサービスのために確立されたオーケストレーションルール６２４に基づいて、署名及び暗号化されたアップデートパッケージを準備することを含み得る。本方法は、アップデートサービス１０７により、署名及び暗号化されたアップデートパッケージをデバイス１０１、１０２に送信することを含み得る。本方法は、アップデートサービス１０７により、デバイスのリクエストログをエントリとして台帳６２５の記録することと、トランザクションレコードのブロックをブロックチェーンピアに配布して、デバイス１０１、１０２の履歴を再現するために分散台帳を維持することとを含み得る。

例示的な実施形態では、デバイスのリクエストログが署名され、暗号化され、少なくともリクエストカウンタ、リクエスト動作データ、リクエストタイムスタンプ、リクエストノンス、デバイスリクエスト署名、リクエストハッシュ、デバイス署名、デバイス証明書識別子、パブリッシャ署名、パブリッシャ証明書識別子、パッケージ識別子、デバイス識別子、プロバイダ識別子、及びパブリッシャ識別子を含む。

例示的な実施形態では、ブロックチェーン内の分散台帳は、アップデートパッケージプロバイダ及びパブリッシャのサプライチェーンにわたるクロスドメイントレーサビリティのために、デバイス１０１、１０２の履歴及びサービストランザクションを再現するのに十分なトランザクションレコードを有する。

例示的な実施形態は、検出エージェント１０９、検出サービス１１１、エンロールメントサービス１０３、ポリシーサービス１０４、及びデバイス管理サービス１０５を使用して、ＩＰアドレスを持たないエンドポイントデバイス１０１と、エンドポイントデバイスに接続されるゲートウェイデバイス１０２との間のデータ転送を保護する方法を対象とする。本方法は、エンドポイントデバイス１０１の検出エージェント１０９により、ゲートウェイデバイス１０２の検出サービス１１１に、エンドポイントデバイスのデバイスプロファイルを有する、認証されたアイデンティティビーコン１１０を送信することを含み得る。本方法は、検出サービス１１１により、エンドポイントデバイス１０１の認証及びデバイスプロファイルを検証することと、検出サービス１１１により、プライバシー認証局からエンロールメントサービス１０３へのエンドポイントデバイス１０１の証明書リクエストを生成することとを含み得る。本方法は、エンロールメントサービス１０３により、受信されたエンドポイントデバイス１０１の証明書リクエストを処理して、認証局４０６への証明書リクエストに変換することを含み得る。本方法は、エンロールメントサービス１０３により、認証局４０６に、エンドポイントデバイス１０１の証明書リクエストを送信することと、エンロールメントサービス１０３により、認証局４０６により発行されたエンドポイントデバイス１０１の証明書を受信することとを含み得る。本方法は、エンロールメントサービス１０３により、受信されたエンドポイントデバイス１０１の証明書を処理して、受信されたエンドポイントデバイス１０１の証明書を、プライバシー認証局を表すように変換することを含み得る。本方法は、エンロールメントサービス１０３により、検出サービス１１１に、エンドポイントデバイス１０１の証明書を送信することを含み得る。本方法は、エンロールメントサービス１０３により、エンドポイントデバイスの登録の通知をポリシーサービス１０４に送信することと、ポリシーサービス１０４により、デバイス管理サービス１０５に、エンドポイントデバイス１０１を追加する指令を送信することとを含み得る。本方法は、検出サービス１１１により、発行されたエンドポイントデバイスの証明書をゲートウェイデバイス１０２のローカル証明書ストアに格納することを含み得る。本方法は、安全なデータ転送のために、ゲートウェイデバイス１０２のアプリケーションにより、エンドポイントデバイス１０１から／への送信中のデータを受信し、ローカル証明書ストアからのエンドポイントデバイス１０１の証明書を使用して、データに暗号化動作を実行することを含み得る。

例示的な実施形態では、アイデンティティビーコン１１０は、一意のエンドポイントデバイス識別子２３１、エンドポイントデバイスタイプ、エンドポイントデバイスメイク、及びエンドポイントデバイスモデルを含む。エンドポイントデバイス識別子は、電源投入からのエンドポイントデバイス１０１の多段階検証ブートシーケンスに基づいて認証される。

例示的な実施形態では、多段階検証ブートシーケンスは、イメージサイナー２０１により対応する秘密署名鍵を使用して生成されたデジタル署名を検証するために、公開鍵の複数のマッチングセットを使用して、エンドポイントデバイス１０１の署名されたプログラムイメージに関連付けられたデジタル署名の複数のセットを検証する多段階検証ブートローダにより実行される。

例示的な実施形態では、検証されるプログラムイメージは、エンドポイントデバイス１０１の第１段階のブートローダ、第２段階のブートローダ、及びオペレーティングシステムローダのうちの少なくとも１つである。多段検証ブートローダ２４０は、ブートシーケンスの任意の段階で導入されてもよい。

例示的な実施形態では、デジタル署名は、署名及び検証プロセスに関連付けられた１つ又は複数の公開－秘密鍵ペアの偽装を検出するための対策として、論理ＡＮＤ又はＯＲ演算子に基づいて検証される。デジタル署名及び署名一致基準の配置順序は、署名仕様に基づく。

例示的な実施形態では、論理ＡＮＤ演算は、検証されるべき署名されたプログラムイメージ内の少なくとも２つの一意のデジタル署名を必要とする。

例示的な実施形態では、多段階検証ブートローダ２４０は、後続段階のブートローダへのいかなる修正も必要とせずに、複数の後続段階のブートローダ、イメージ、構成及びデータファイルを検証するためにブートシーケンスに導入される。

例示的な実施形態では、エンドポイントデバイス１０１又はゲートウェイデバイス１０２のアップデートクライアント１０８は、デバイス特性（例えば、プロファイル）、プラットフォーム特性（例えば、プロセッサアーキテクチャ、オペレーティングシステムタイプ及びバージョン）、及び拡張特性（例えば、工場で構成された設定）を含み得る動的デバイス属性を検出することができる。

図１４は、複数のインターネットプロトコル（ＩＰ）対応及び非ＩＰ配布デバイス（例えば、ＩｏＴフィールド及びエッジデバイス及びゲートウェイ）、デバイス管理サービス（例えば、エンロールメントサービス、アップデートサービス、ポリシーサービス、分析サービス）、ブロックチェーンネットワーク内のノードとして機能するブロックチェーンブローカサービス、及びデバイス管理サービスからブロックチェーンブローカサービスへのトランザクションコネクタを備えるシステム及び方法を示す。一実施形態では、デバイス及びデバイス管理サービスのどちらもブロックチェーンに直接参加しない。一実施形態では、ブロックチェーンブローカサービスは、デバイス及びデバイス管理サービスのためのブロックチェーンネットワークにプロキシノードとして参加する。さらに、ブロックチェーンブローカサービスは、データプライバシー及び保護のために、バージョン化されたブロックとしてトランザクションを提出する前に、ポリシーベースの（例えば、スマートコントラクト、ローカルルールなどの）エンティティ識別子の匿名化、及びトランザクションレコード内のコンテンツの項目化されたフィルタリングを提供することができる。

図１４を参照すると、ステップ１４０４で、エンドポイントデバイス１０１又はゲートウェイデバイス１０２は、少なくとも認証及び識別アーティファクトを含むエンロールメントリクエストをエンロールメントサービス１０３に送信し得る。エンロールメントサービス１０３は、受信されたアーティファクトを検証し、デバイス１０１、１０２に関連付けられた証明書を発行、更新、又は鍵再付与するための動作リクエストを処理し得る。エンロールメント動作のレコードは、デバイスエンロールメントに関連付けられ、否認不可である、複数の検証されたアーティファクトを含み、トランザクションコネクタ１４１２を介して、ブロックチェーンブローカサービス１４１４に送信され得る。ステップ１４１６で、ブロックチェーンブローカサービスは、エンロールメント動作のためのバージョン化されたブロックを生成し、ブロックチェーンネットワークに送信して、分散台帳をアップデートし得る。当業者であれば、ブロックチェーンにブロックを追加する多くの方法が存在し、本明細書に記載される機構と実質的に同一であり得ることは理解されよう。

ステップ１４０６で、エンドポイントデバイス１０１又はゲートウェイデバイス１０２は、少なくとも認証及び識別アーティファクトを含むアップデートリクエストをアップデートサービス１０７に送信し得る。アップデートサービス１０７は、受信したアーティファクトを検証し、構成されたポリシーに基づいてアップデートパッケージを準備し、デバイス１０１、１０２に送信するために動作リクエストを処理し得る。アップデート動作のレコードは、アップデートパッケージサプライチェーンの出所、アップデートパッケージの配布及び発行にそれぞれ関連付けられたプロバイダ及びパブリッシャの動作に関連付けられた、否認不可である、複数の検証されたアーティファクトアーティファクトを含み、トランザクションコネクタ１４１２を介して、ブロックチェーンブローカサービス１４１４に送信され得る。ステップ１４１６で、ブロックチェーンブローカサービスは、アップデート動作のためのバージョン化されたブロックを生成し、ブロックチェーンネットワークに送信して、分散台帳をアップデートし得る。当業者であれば、ブロックチェーンにブロックを追加する多くの方法が存在し、本明細書に記載される機構と実質的に同一であり得ることは理解されよう。

一実施形態では、アップデートプロバイダ６０１のリリース管理システム６０８は、トランザクションコネクタ１４１２を介して、アップデート配布動作のレコードをブロックチェーンブローカサービス１４１４に送信し得る。

一実施形態では、アップデートパブリッシャ６０２のアップデートサービス１０７は、トランザクションコネクタ１４１２を介して、アップデート発行動作のレコードをブロックチェーンブローカサービス１４１４に送信することができる。

ステップ１４０８で、エンドポイントデバイス１０１又はゲートウェイデバイス１０２は、少なくとも認証及び識別アーティファクトを含むポリシーリクエストをポリシーサービス１０４に送信し得る。ポリシーサービスは、受信されたアーティファクトを検証し、動作リクエストを処理して、デバイスタイプ及び認定基準に基づいて、連続ランタイムモニタリングのためのポリシーを準備し、デバイス１０１、１０２に送信し得る。ポリシー構成動作のレコードは、一意のポリシー及びルール識別子及び文法を含み、トランザクションコネクタ１４１２を介して、ブロックチェーンブローカサービス１４１４に送信され得る。ステップ１４１６で、ブロックチェーンブローカサービスは、ポリシー構成動作のためのバージョン化されたブロックを生成し、ブロックチェーンネットワークに送信して、分散台帳をアップデートし得る。当業者であれば、ブロックチェーンにブロックを追加する多くの方法が存在し、本明細書に記載される機構と実質的に同一であり得ることは理解されよう。

ステップ１４１０で、エンドポイントデバイス１０１又はゲートウェイデバイス１０２は、少なくとも認証、識別、及び署名されたイベント関連データアーティファクトを含むポリシートリガイベントを分析サービス１４０２に送信し得る。分析サービスは、受信されたアーティファクトを検証し、動作リクエストを処理して、少なくともエピソード情報、ランタイム状態測定値、及びデバイス完全性スコアを含む、ポリシートリガに基づいて、検出されたインフィールドデバイスアクティビティのレコードを準備し、トランザクションコネクタ１４１２を介して、ブロックチェーンブローカサービス１４１４に送信し得る。ステップ１４１６で、ブロックチェーンブローカサービスは、エピソード情報、ランタイム状態測定値、及びデバイス完全性スコアのバージョン化されたブロックを生成し、ブロックチェーンネットワークに送信して、分散台帳をアップデートし得る。当業者であれば、ブロックチェーンにブロックを追加する多くの方法が存在し、本明細書に記載される機構と実質的に同一であり得ることは理解されよう。

一実施形態では、ブロックチェーンブローカサービス１４１４は、情報フィルタリング及び匿名化のために、構成されたブローカサービスポリシーに基づいてトランザクションフィルタを適用し得る。

図１５は、ブロックチェーンの分散台帳として、シリコン製造工場、相手先製品製造業者（ＯＥＭ）、プラットフォーム所有者からデバイスの所有者までのデバイスの管理のチェーンを追跡するためのブロックスキーマを示し、ここで、デバイスに関連付けられたリモートエンロールメントサービス及びエンロールメントサービスに関連付けられたトランザクションコネクタは、（作業のプルーフ及び許可のプルーフに相当する）トランザクションを、ブロックチェーンネットワークのブロックチェーンブローカサービスノードにサブミットする。

図１５を参照すると、ブロック１５０１で、ブロック＃１５０２は、ブロックチェーン内のブロックシーケンス番号を表し、ノンス１５０３は、ブロックチェーン内のブロックをハッシュするための要件に基づく乱数である。ヘッダセクション１５０４は、少なくとも、産業セクタ、ブロックデータのタイプ、及びブロックデータフォーマット（又はスキーマ）のバージョンを含む。動作１５０５、１５２１、１５４１は、デバイスによりリクエストされた動作（トランザクション）のタイプ（例えば、登録、アップデート、鍵再付与、取消）を記述する。デバイスセクション１５０６は、少なくとも、デバイス名、デバイスタイプ、認証アカウント（クレデンシャル）、及びデバイスの一意の識別子（ＩＤ）を含む。証明書セクション１５０７は、少なくとも、証明書に関連付けられたサブジェクト名、証明書シリアル番号（ＣＳＮ）、証明書のイシュアラーの一意の識別子（ＵＩＤ）、サブジェクトの一意の識別子、証明書のサブジェクトの代替名（ＳＡＮ）、デバイス（ハードウェア、ファームウェア又はソフトウェアに基づく信頼の基点）に関連付けられたルート（公開）鍵、デバイスに発行されたプラットフォーム（公開）鍵、デバイスの所有に関連付けられた所有者（公開）鍵、鍵の意図された使用（署名、暗号化など）、及び動作の日時のタイムスタンプを含む。前１５０８は、ブロックチェーン内の先行するブロック（図示せず）のハッシュであり、ハッシュ１５０９は、ブロック１５０１のハッシュである。ブロック１５２０で、前１５２２は、ブロックチェーン内のブロック１５０１のハッシュ１５０９を参照する。ブロック１５４０で、証明書１５４２は、鍵再付与動作１５４１に関連付けられた取消鍵を含む。

一実施形態では、デバイス鍵の取消は、取消リクエスト動作タイプとして実行され得る。

図１６は、ブロックチェーンの分散台帳として、シリコン製造工場、相手先製品製造業者（ＯＥＭ）、プラットフォーム所有者からデバイスの所有者までのデバイスのアプリケーショントラストチェーンを追跡するためのブロックスキーマを示し、ここで、デバイスに関連付けられたリモートエンロールメントサービス及びエンロールメントサービスに関連付けられたトランザクションコネクタは、（作業のプルーフ及び許可のプルーフに相当する）トランザクションを、ブロックチェーンネットワークのブロックチェーンブローカサービスノードにサブミットする。

図１６を参照すると、ブロック１６０１で、ブロック＃１６０２は、ブロックチェーン内のブロックシーケンス番号を表し、ノンス１６０３は、ブロックチェーン内のブロックをハッシュするための要件に基づく乱数である。ヘッダセクション１６０４は、少なくとも産業セクタ、ブロックデータのタイプ、及びブロックデータフォーマット（又はスキーマ）のバージョンを含む。動作１６０５は、アプリケーションによりリクエストされた動作（トランザクション）のタイプ（例えば、登録、アップデート、鍵再付与、取消）を記述する。アプリケーションセクション１６０６は、少なくともアプリケーション名、アプリケーションタイプ、認証アカウント（クレデンシャル又はサービスアカウント）、及びアプリケーションの一意の識別子（ＩＤ）を含む。証明書セクション１６０７は、少なくとも、証明書に関連付けられたサブジェクト名、証明書シリアル番号（ＣＳＮ）、証明書のイシュアーの一意の識別子（ＵＩＤ）、サブジェクトの一意の識別子、証明書のサブジェクトの代替名（ＳＡＮ）、デバイス（ハードウェア、ファームウェア又はソフトウェアベースの信頼の基点）に関連付けられたルート（公開）鍵、デバイスに発行されたプラットフォーム（公開）鍵、デバイスの所有に関連付けられた所有者（公開）鍵、（例えば、クラウドサービス、ピアツーピア通信などの）リモートサービスにアクセスするアプリケーションに関連付けられたサービス（公開）鍵、鍵の意図された使用（署名、暗号化など）、及び動作の日時のタイムスタンプを含む。前１６０８は、ブロックチェーン内の先行するブロック（図示せず）のハッシュであり、ハッシュ１６０９は、ブロック１６０１のハッシュである。ブロック１６２０で、前１６２２は、ブロックチェーン内のブロック１６０１のハッシュ１６０９を参照する。ブロック１６４０で、証明書１６４２は、鍵再付与動作１６４１に関連付けられた取消鍵を含む。

一実施形態では、アプリケーション鍵の取消は、取消リクエスト動作タイプとして実行され得る。

図１７は、ブロックチェーンの分散台帳として、シリコン製造工場、相手先製品製造業者（ＯＥＭ）、プラットフォーム所有者からデバイスの所有者までのサプライチェーンを通じたデバイスの変更管理を追跡するためのブロックスキーマを示し、ここで、デバイスに関連付けられたリモートアップデートサービス及びアップデートサービスに関連付けられたトランザクションコネクタは、（作業のプルーフ及び許可のプルーフに相当する）トランザクションブロックチェーンネットワークのブロックチェーンブローカサービスノードにサブミットする。

一実施形態では、ブロックチェーンのブロックは、プロバイダ識別子を、サプライチェーン内のオリジナルコンテンツプロバイダ（ソース）として識別し、パブリッシャ識別子をサプライチェーン内のリモートアップデートサービス（例えば、デバイス所有者又は管理サービスプロバイダにより操作されるデバイスマネージャ）として識別し、これは、トランザクションの直接的に接続された（ポイントツーポイント）エンティティを識別するための単なる手段として機能するメッセージ（又はコンテンツ）の送信者及び受信者の一般的な概念とは明らかに区別される。

一実施形態では、ブロックチェーンのブロックは、何百万台のＩｏＴデバイスのサービスポイントにおいて、さらにマルチテナントサービス構成において、事前に構成され、暗黙的に推論されるデバイス属性の、スケーラブルではない方法ではなく、動作に関連付けられた、分散された動的なアーチファクト（明示的プロパティ）を含む。

一実施形態では、デバイスヒストリアンが、ブロックチェーン内のブロックに基づいて構築（インスタンス化）されてもよく、ここで、ブロックは、接続されたデバイス並びにデバイスのハードウェア、ファームウェア、及びソフトウェアコンポーネントに関連付けられた複数のプロバイダのサプライチェーン内の複数の接続されたサービスによってサブミットされた、複数の分散されたトランザクションを表す。さらに、バージョン化されたブロックは、オペレーションタイプにより、及びエンティティとしてのデバイス、アプリケーション、又は（ポータル又はサービス）オペレータを使用して、特定の産業セクタのために準備されてもよい。

図１７を参照すると、ブロック１７０１で、ブロック＃１７０２は、ブロックチェーン内のブロックシーケンス番号を表し、ノンス１７０３は、ブロックチェーン内のブロックをハッシュするための要件に基づく乱数である。ヘッダセクション１７０４は、少なくとも産業セクタ、ブロックデータのタイプ、及びブロックデータフォーマット（又はスキーマ）のバージョンを含む。動作１７０５、１７２１、１７４１は、デバイスアップデートパッケージ（例えば、プロバイダによる配布、パブリッシャによる発行、デバイスによるリクエスト）に関連付けられた動作（トランザクション）のタイプを記述する。オペレータセクション１７０６は、少なくともポータル又はサービスユーザアカウント、（例えば、公開署名鍵又はＵＲＬによる）ディストリビューション内のパブリッシャ識別子のリストを含み、アップデートパッケージが配布されるデバイスのクラスを含む。パッケージセクション１７０７は少なくとも、アップデートパッケージ名、アップデートパッケージタイプ、アップデートパッケージバージョン、アップデートパッケージが対象とするデバイスカテゴリ、サイナー公開鍵のリスト（例えば、サプライチェーン内のプロバイダ及びパブリッシャ）、デバイス暗号化公開鍵、及び動作の日時のタイムスタンプを含む。前１７０８は、ブロックチェーン内の先行するブロック（図示せず）のハッシュであり、ハッシュ１７０９は、ブロック１７０１のハッシュである。ブロック１７２０で、前１７２４は、ブロックチェーン内のブロック１７０１のハッシュ１７０９を参照する。オペレータセクション１７２２は、アップデートパッケージが関連付けられたデバイスタイプを含み、パッケージセクション１７２３は、パブリッシャによりアップデートパッケージに関連付けられたタグを含む。

図１８は、本開示の実施形態又はその一部がコンピュータ可読コードとして実装され得る例示的なコンピュータシステム１８００を示す。例えば、本明細書で開示されたネットワークシステム及びアーキテクチャ（エンドポイントデバイス１０１、ゲートウェイデバイス１０２、エンロールメントサービス１０３、データベース３１１、アップデートプロバイダ６０１、アップデートパブリッシャ６０２、クラウドサービス１２０２など）は、ハードウェア、ソフトウェア、ファームウェア、命令を記憶した非一時的コンピュータ可読媒体、又はこれらの組み合わせを使用してコンピュータシステム１８００で実装されてもよく、１つ又は複数のコンピュータシステム又は他の情報処理で実装されてもよい。ハードウェア、ソフトウェア、又はこれらの任意の組み合わせは、本明細書で開示されるアーキテクチャ及びシステムを実装するために使用される任意のモジュール及び構成要素を具現化し得る。

プログラマブルロジックが使用される場合、これらのロジックは、市販の処理プラットフォーム又は専用デバイスで動作し得る。当業者であれば、開示された主題の実施形態は、マルチコアマルチプロセッサシステム、ミニコンピュータ、メインフレームコンピュータ、分散された機能とリンクされた又はクラスタ化されたコンピュータ、並びに実質的に任意のデバイスに埋め込まれ得るパーベイシブ又はミニチュアコンピュータを含む、様々なコンピュータシステム構成で実施され得ることを理解されよう。

例えば、少なくとも１つのプロセッサデバイス及びメモリを使用して、上述の実施形態を実装することができる。プロセッサデバイスは、単一のプロセッサ、複数のプロセッサ、又はこれらの組み合わせとすることができる。プロセッサデバイスは、１つ又は複数のプロセッサ「コア」を有することができる。

本開示の様々な実施形態が、本例示的なコンピュータシステム１８００に関して説明される。本説明を読んだ後、どのように他のコンピュータシステム及び／又はコンピュータアーキテクチャを使用して本開示を実装するかは、当業者には明らかになろう。動作は連続的なプロセスとして記述され得るが、動作のいくつかは実際には並列に、同時に、及び／又は分散環境において実行されてもよく、シングル又はマルチプロセッサマシンによるアクセスのためにローカル又はリモートに記憶されたプログラムコードを用いて実行されてもよい。さらに、いくつかの実施形態では、動作の順序は、開示された主題の趣旨から逸脱することなく再構成されてもよい。

プロセッサデバイス１８０２は、特定用途又は汎用プロセッサデバイスであってもよい。当業者には理解されるように、プロセッサデバイス１８０２は、単独で動作するシステムのような、マルチコア／マルチプロセッサシステム内の単一のプロセッサであってもよいし、クラスタ又はサーバファームで動作するコンピューティングデバイスのクラスタ内の単一のプロセッサであってもよい。プロセッサデバイス１８０２は、例えば、バス、メッセージキュー、ネットワーク、又はマルチコアメッセージパッシングスキームなどの、通信インフラストラクチャ１８２６に接続される。

コンピュータシステム１８００は、メインメモリ１８０４、例えばランダムアクセスメモリ（ＲＡＭ）又はフラッシュメモリを含み、セカンダリメモリ１８０６を含んでもよい。セカンダリメモリ１８０６は、例えば、ハードディスクドライブ１８０８、リムーバブルストレージドライブ１８１０を含んでもよい。リムーバブルストレージドライブ１８１０は、フロッピーディスクドライブ、磁気テープドライブ、光ディスクドライブ、フラッシュメモリなどであってもよい。

リムーバブルストレージドライブ１８１２は、周知の方法でリムーバブルストレージユニット１８１２からの読取り及び／又は書込みを行う。リムーバブルストレージユニット１８１２は、リムーバブルストレージドライブ１８１０により読み書きされるフロッピーディスク、磁気テープ、光ディスク等であってもよい。当業者には理解されるように、リムーバブルストレージユニット１８１２は、コンピュータソフトウェア及び／又はデータが記憶された非一時的コンピュータ使用可能記憶媒体を含む。

代替の実施形態では、セカンダリメモリ１８０６は、コンピュータプログラム又は他の命令をコンピュータシステム１８００にロードすることを可能にする他の同様の手段を含んでもよい。これらの手段は、例えば、リムーバブルストレージユニット１８１６及びインタフェース１８１４を含んでもよい。これらの手段の例には、（ビデオゲームデバイスに見られるような）プログラムカートリッジ及びカートリッジインタフェース、リムーバブルメモリチップ（ＥＰＲＯＭ又はＰＲＯＭなど）及び関連付けられたソケット、並びにソフトウェア及びデータをリムーバブルストレージユニット１８１６からコンピュータシステム１８００に転送可能にする他のリムーバブルストレージユニット１８１６及びインタフェース１８１４が含まれてもよい。

コンピュータシステム１８００は、通信インタフェース１８１８を含んでもよい。通信インタフェース１８１８は、ソフトウェア及びデータをコンピュータシステム１８００と外部デバイスとの間で転送可能にする。通信インタフェース１８１８は、モデム、ネットワークインタフェース（イーサネットカード等）、通信ポート、ＰＣＭＣＩＡスロット及びカード等を含んでもよい。通信インタフェース１８１８を介して転送されるソフトウェア及びデータは、通信インタフェース１８１８により受信可能な電子的、電磁気的、光学的、又は他の信号を含む、信号の形態であってもよい。これらの信号は、通信経路１８２０を介して、通信インタフェース１８１８に提供されてもよい。通信経路１８２０は、信号を搬送し、ワイヤ又はケーブル、光ファイバ、電話回線、携帯電話リンク、ＲＦリンク、又は他の通信チャンネルを使用して実装されてもよい。

コンピュータシステム１８００は、コンピュータディスプレイ１８２４及びディスプレイインタフェース１８２２を含んでもよい。実施形態によれば、上述された図１～図１３に示されるＧＵＩ及びダッシュボードを表示するために使用されるディスプレイは、コンピュータディスプレイ１８２４であってもよく、コンソールインタフェースはディスプレイインタフェース１８２２であってもよい。

本明細書において、「コンピュータプログラム媒体」、「非一時的コンピュータ可読媒体」、「コンピュータ使用可能媒体」という用語は、一般に、リムーバブルストレージユニット１８１２、リムーバブルストレージユニット１８１６、及びハードディスクドライブ１８０８に用いられるハードディスクのような媒体を指すために使用される。通信経路１８２０を介して搬送される信号は、本明細書で説明されるロジックを具現化することもできる。コンピュータプログラム媒体及びコンピュータ使用可能媒体は、メインメモリ１８０４及びセカンダリメモリ１８０６などのメモリを指すことができ、メモリ半導体（例えば、ＤＲＡＭなど）とすることができる。これらのコンピュータプログラムプロダクトは、コンピュータシステム１８００にソフトウェアを提供するための手段である。

コンピュータプログラム（コンピュータ制御ロジックとも称される）は、メインメモリ１８０４及び／又はセカンダリメモリ１８０６に記憶される。コンピュータプログラムは、通信インタフェース１８１８を介して、受信されてもよい。そのようなコンピュータプログラムは、実行されると、コンピュータシステム１８００が本明細書で説明された本開示を実施することを可能にする。具体的には、コンピュータプログラムは、実行されると、プロセッサデバイス１８０２が、上述された図１～１３のフローチャートにより示される方法のステージなど、本開示のプロセスを実施することを可能にする。したがって、これらのコンピュータプログラムは、コンピュータシステム１８００のコントローラを表す。本開示がソフトウェアを使用して実装される場合、ソフトウェアは、コンピュータプログラムプロダクトに記憶され、リムーバブルストレージドライブ１８１２、インタフェース１８１４、及びハードディスクドライブ１８０８、又は通信インタフェース１８１８を使用して、コンピュータシステム１８００にロードされてもよい。

本開示の実施形態は、任意のコンピュータ使用可能媒体に格納されたソフトウェアを備えるコンピュータプログラムプロダクトを対象としてもよい。これらのソフトウェアは、１つ又は複数のデータ処理デバイスで実行されると、（１つ又は複数の）データ処理デバイスに本明細書で説明するように動作させる。本開示の実施形態は、任意のコンピュータ使用可能媒体又はコンピュータ可読媒体を使用する。コンピュータ使用可能媒体の例には、プライマリストレージデバイス（例えば、任意のタイプのランダムアクセスメモリなど）、セカンダリストレージデバイス（例えば、ハードドライブ、フロッピーディスク、ＣＤ－ＲＯＭ、ＺＩＰディスク、テープ、磁気記憶デバイス、及び光記憶デバイス、ＭＥＭＳ、ナノテクノロジー記憶デバイスなど）、及び通信媒体（例えば、有線及び無線通信ネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、イントラネットなど）が含まれるが、これらに限定されない。

結論
発明の概要及び要約書ではなく、詳細な説明のセクションが、請求項を解釈するために使用されることを意図している。発明の概要及び要約書のセクションは、本発明者により企図される本開示の、１つ又は複数の例示的な実施形態を記載しているが、すべてではなく、したがって、本開示及び添付の特許請求の範囲をいかなる形でも限定することを意図するものとではない。

本開示の実施形態は、特定された機能の実装及びそれらのリレーションシップを示すファンクショナルビルディングブロックを用いて、上述された。これらのファンクショナルビルディングブロックの境界は、説明の便宜上、本明細書において定義されている。特定された機能及それらのリレーションシップが適切に実行される限り、代替の境界が定義されてもよい。

特定の実施形態について上述した説明は、本開示の一般的な性質を十分に明らかにしており、当業者の知識を適用することにより、本開示の一般的な概念から逸脱することなく、過度の実験を行うことなく、これらの特定の実施形態を様々な用途に容易に修正及び／又は適応させることができる。したがって、これらの適応及び修正は、本明細書で提示される教示及びガイダンスに基づいて、開示された実施形態と同等の意味及び範囲内にあることが意図される。本明細書中の語法又は用語は、説明の目的のためのものであって、限定のためのものではなく、したがって、本明細書の用語又は語法は、教示及びガイダンスに照らして当業者によって解釈されるべきであることを理解されたい。単数形の要素への言及は、明示される場合を除き「１つ及び１つのみ」を意味するものではなく、「１つ又は複数」を意味することを意図している。さらに、「Ａ、Ｂ、又はＣのうちの少なくとも１つ」のようなフレーズが特許請求の範囲で使用される場合、そのフレーズはＡが単独で実施形態に存在してもよく、Ｂが単独で実施形態に存在してもよく、Ｃが単独で実施形態に存在してもよく、或いは要素Ａ、Ｂ、及びＣの任意の組み合わせが単一の実施形態に存在してもよく、例えば、Ａ及びＢ、Ａ及びＣ、Ｂ及びＣ、或いは、Ａ及びＢ及びＣであってもよい。本明細書の特許請求の範囲のいかなる要素も、その要素が「のための手段」という句を使用して明示的に列挙されない限り、３５ Ｕ．Ｓ．Ｃ．１１２（ｆ）の規定に基づいて解釈されるものではない。本明細書で使用されるように、用語「備える」、「含む」、又はその任意の他の変形は、要素のリストを備えるプロセス、方法、物品、又はデバイスがそれらの要素だけを含むものではなく、明示的にリストされていない要素、又はこれらのプロセス、方法、物品、又はデバイスに固有の他の要素を含むことができるように、非排他的な包含をカバーすることを意図する。

本開示は特定の実施形態を参照して本明細書に例示され、説明されるが、本開示は示される詳細に限定されることを意図するものではない。むしろ、本開示から逸脱することなく、特許請求の範囲と同等のスコープ及び範囲内で、様々な修正を当該詳細に行うことができる。

Claims (17)

1. アップデートプロバイダにより操作されるディベロップメントシステム及びリリース管理システム、アップデートパブリッシャにより操作されるアップデートサービス、デバイスのアップデートクライアント、及び前記デバイスのローカルセキュアエレメントを使用して、登録されたデバイスをアップデートする方法であって、
   前記ディベロップメントシステムに、ファームウェアアップデート、ソフトウェアアップデート、構成アップデート、及びアップデートスクリプトの少なくとも１つを含むアップデートパッケージを構築することと、
   前記リリース管理システムにより、プロバイダ署名鍵を使用して前記アップデートパッケージに署名することであって、第１のデジタル署名が前記アップデートパッケージに含まれることと、
   前記リリース管理システムにより、前記アップデートパッケージの初期暗号化のために、前記アップデートパブリッシャのためのパブリッシャ証明書からのパブリッシャ公開鍵を使用して署名された前記アップデートパッケージを暗号化することと、
   前記リリース管理システムにより、署名及び暗号化されたアップデートパッケージを前記アップデートサービスに送信することと、
   前記デバイスの前記アップデートクライアントにより、アップデートパッケージをリクエストすることであって、前記リクエストは、デバイスマニフェストと、少なくとも前記デバイスのベンダ識別子、型番、及びデバイス証明書を含むことと、
   前記アップデートサービスにより、前記デバイスのオーケストレーションルールに基づいて構成された前記デバイスの署名されたアップデートパッケージのセットを、前記デバイスマニフェストに基づいて準備することと、
   前記アップデートサービスにより、前記アップデートパブリッシャのパブリッシャ秘密鍵を使用して前記初期暗号化を復号化することによって前記署名されたアップデートパッケージを再暗号化及び再署名し、前記アップデートパブリッシャの署名鍵を使用して前記アップデートパッケージを署名し、最後に、前記アップデートパッケージの最終暗号化のために、前記デバイス証明書からのデバイス公開鍵を使用して前記アップデートパッケージを暗号化することであって、第２のデジタル署名が前記アップデートパッケージに含まれることと、
   前記アップデートサービスにより、暗号化され二重に署名された前記アップデートパッケージを前記デバイスの前記アップデートクライアントに送信することと、
   前記アップデートクライアントにより、前記デバイスのデバイス秘密鍵を使用して、前記暗号化されたアップデートパッケージを復号化することと、
   前記アップデートクライアントにより、前記アップデートプロバイダ及び認証局によって発行されたパブリッシャ証明書からの前記パブリッシャ公開鍵及び前記デバイス公開鍵を使用して、前記第１及び第２のデジタル署名を検証することと、
   を含み、
   前記アップデートスクリプトは、前記アップデートパッケージを前記デバイスに適用するために前記デバイスで実行される、方法。
2. 前記アップデートパッケージの前記初期暗号化は、対称鍵を使用して実行され、前記対称鍵は、前記パブリッシャ公開鍵を使用してさらに暗号化され、
   前記アップデートパッケージのメッセージダイジェストが生成され、前記メッセージダイジェストの前記第１のデジタル署名は、前記アップデートプロバイダからのプロバイダ秘密鍵を使用して生成され、
   前記第１のデジタル署名は、前記パブリッシャ公開鍵を使用してさらに暗号化される、請求項１に記載の方法。
3. 前記アップデートパッケージの前記最終暗号化は、対称鍵を使用して実行され、前記対称鍵は、前記デバイス公開鍵を使用してさらに暗号化され、
   前記アップデートパッケージのメッセージダイジェストが生成され、前記メッセージダイジェストの前記第２のデジタル署名は、前記アップデートプロバイダからのパブリッシャ秘密鍵を使用して生成され、
   前記第２のデジタル署名は、前記デバイス公開鍵を使用してさらに暗号化される、請求項１に記載の方法。
4. 前記暗号化のためのデバイス秘密－公開鍵ペアは、前記デバイス上の前記セキュアエレメントにより生成されることができ、前記デバイス秘密鍵は、前記セキュアエレメント内で保護され、
   前記デバイス公開鍵のデバイス証明書は、認証局により発行される、請求項１に記載の方法。
5. ブロックチェーンアプリケーションとしてのデバイスのアップデートクライアントにより検出されたデバイス属性、ブロックチェーンネットワークピアとしてのネットワークのアップデートサービス、オーケストレーションルール、及び台帳を使用して、認証されたデバイスをアップデートする方法であって、
   前記デバイスの前記アップデートクライアントにより、前記ネットワークの前記アップデートサービスからの前記デバイスのアップデートパッケージのデバイスリクエストを送信することであって、前記デバイスリクエストは、前記検出されたデバイス属性を含むことと、
   前記アップデートサービスにより、前記デバイスリクエストを受信することと、
   前記アップデートサービスにより、前記ネットワークのネットワークサービスのために確立された前記オーケストレーションルールに基づいて、二重に署名され再暗号化されたアップデートパッケージを準備することと、
   前記アップデートサービスにより、前記二重に署名され再暗号化されたアップデートパッケージを前記デバイスに送信することと、
   前記アップデートサービスにより、前記デバイスのリクエストログをエントリとして前記台帳に記録し、トランザクションレコードのブロックをブロックチェーンピアに配布して、サプライチェーンの複数のパブリッシャにより複数のデバイスに送信されたアップデートパッケージの履歴を再現するために分散台帳を維持することと、
   を含む、方法。
6. 前記デバイスの前記リクエストログは、二重に署名され、再暗号化され、少なくとも、リクエストカウンタ、リクエスト動作データ、リクエストノンス、デバイスリクエスト署名、リクエストハッシュ、デバイス署名、デバイス証明書識別子、パブリッシャ署名、パブリッシャ証明書識別子、パブリッシャパッケージ識別子、前記検出されたデバイス属性に基づくデバイス識別子、及びパブリッシャ識別子を含む、請求項５に記載の方法。
7. 前記ブロックチェーン内の前記分散台帳は、中間パブリッシャのサプライチェーンへのクロスドメイントレーサビリティのために、デバイスアップデート及びサービストランザクションの履歴を再現するのに十分なトランザクションレコードを有する、請求項６に記載の方法。
8. ブロックチェーンアプリケーションとしてのデバイスのアップデートクライアントにより検出されたデバイス属性、複数のアップデートパッケージのプロバイダ、ブロックチェーンネットワークピアとしてのネットワークの複数のパブリッシャのアップデートサービス、オーケストレーションルール、及び台帳を使用して、認証されたデバイスをアップデートする方法であって、
   前記デバイスの前記アップデートクライアントにより、前記ネットワークの前記アップデートサービスからの前記デバイスのアップデートパッケージのデバイスリクエストを送
   信することであって、前記デバイスリクエストは、前記検出されたデバイス属性を含むことと、
   前記アップデートサービスにより、前記デバイスリクエストを受信することと、
   前記アップデートサービスにより、前記ネットワークのネットワークサービスのために確立された前記オーケストレーションルールに基づいて、二重に署名され再暗号化されたアップデートパッケージを準備することと、
   前記アップデートサービスにより、前記二重に署名され再暗号化されたアップデートパッケージを前記デバイスに送信することと、
   前記アップデートサービスにより、前記デバイスのリクエストログをエントリとして前記台帳に記録し、トランザクションレコードのブロックをブロックチェーンピアに配布して、サプライチェーンの複数のプロバイダ及びパブリッシャにより複数の認証されたデバイスに送信されたプロバイダパッケージの履歴を再現するために分散台帳を維持することと、
   を含む、方法。
9. 前記デバイスの前記リクエストログは、二重に署名され、再暗号化され、少なくとも、リクエストカウンタ、リクエスト動作データ、リクエストノンス、デバイスリクエスト署名、リクエストハッシュ、デバイス署名、デバイス証明書識別子、パブリッシャ署名、パブリッシャ証明書識別子、パブリッシャパッケージ識別子、検出されたデバイス属性に基づくデバイス識別子、パブリッシャ識別子、及びプロバイダパッケージ識別子を含む、請求項８に記載の方法。
10. 前記ブロックチェーン内の前記分散台帳は、アップデートパッケージプロバイダのサプライチェーンへのクロスドメイントレーサビリティのために、デバイスアップデート及びサービストランザクションの履歴を再現するのに十分なトランザクションレコードを有する、請求項９に記載の方法。
11. ブロックチェーンアプリケーションとしてのデバイスのアップデートクライアント、ブロックチェーンネットワークピアとしてのネットワークのアップデートサービス、オーケストレーションルール、及び台帳を使用して、デバイスをアップデートする方法であって、
    前記アップデートクライアントにより、前記ネットワークの前記アップデートサービスからの前記デバイスのアップデートパッケージのデバイスリクエストを送信することと、
    前記アップデートサービスにより、前記デバイスリクエストを受信し、前記デバイスを認証することと、
    前記アップデートサービスにより、前記ネットワークのネットワークサービスのために確立された前記オーケストレーションルールに基づいて、署名及び暗号化されたアップデートパッケージを準備することと、
    前記アップデートサービスにより、前記署名及び暗号化されたアップデートパッケージを前記デバイスに送信することと、
    前記アップデートサービスにより、前記デバイスのリクエストログをエントリとして前記台帳に記録し、トランザクションレコードのブロックをブロックチェーンピアに配布して、前記デバイスの履歴を再現するために分散台帳を維持することであって、前記リクエストログは、パブリッシャ識別子又はプロバイダ識別子を含むことと、
    を含む、方法。
12. エンロールメントサービス、アップデートサービス、ポリシーサービス、及び分析サービスを含む複数のデバイス管理サービスと、トランザクションコネクタと、ブロックチェーンネットワークのノードとして参加するブロックチェーンブローカサービスと、トランザクションフィルタとにより、デバイスの製造業者及び管理者のサプライチェーンにわた
    るデバイスヒストリアンを構築する方法であって、
    前記複数のデバイス管理サービスにより、前記トランザクションコネクタを介して、トランザクションレコードを前記ブロックチェーンブローカサービスに送信することと、
    前記ブロックチェーンブローカサービスにより、前記トランザクションレコードを受信することと、
    前記ブロックチェーンブローカサービスにより、前記トランザクションフィルタに基づいて前記トランザクションレコード内の情報をフィルタリングすることと、
    前記ブロックチェーンブローカサービスにより、前記トランザクションレコードからフィルタリングされた前記情報に基づいてバージョン化されたブロックを準備することと、
    前記ブロックチェーンブローカサービスにより、前記バージョン化されたブロックを前記ブロックチェーンネットワークに追加することと、
    を含む、方法。
13. 前記バージョン化されたブロックは、エンティティとしてデバイス、アプリケーション、及びオペレータの少なくとも１つとともに、オペレーションタイプにより特定の産業セクタのために構成され、前記オペレータは、ポータルユーザ及びサービスユーザの少なくとも１つを含む、請求項１２に記載の方法。
14. 前記バージョン化されたブロックは、ルート証明書、プラットフォーム証明書、及び所有者証明書のトラストチェーンに基づいて、前記デバイスの管理のチェーンを追跡するように構成される、請求項１２に記載の方法。
15. 前記バージョン化されたブロックは、ルート証明書、プラットフォーム証明書、所有者証明書、及びサービス証明書のトラストチェーンに基づいて、前記デバイスのアプリケーションを追跡するように構成される、請求項１２に記載の方法。
16. 前記バージョン化されたブロックは、複数のプロバイダ証明書、パブリッシャ署名証明書、及びデバイス暗号化証明書にわたって確立されたトラストチェーンに基づいて、デバイスアップデートパッケージのサプライチェーンの起源を追跡するように構成される、請求項１２に記載の方法。
17. 前記バージョン化されたブロックは、前記ブロックチェーンネットワークの分散台帳内にあり、シリコン製造工場、相手先製品製造業者、デバイスの所有者、前記複数のデバイス管理サービスのデバイス管理サービス、及びインフィールド動作から、前記サプライチェーンにわたってオーケストレーションされたデバイス管理動作の履歴を追跡するために使用される、請求項１６に記載の方法。

Images