JP2020523806A - モノのインターネット（ｉｏｔ）デバイスの管理 - Google Patents

Abstract

本明細書で記載される実施形態は、モノのインターネット（ＩｏＴ）インフラストラクチャにおけるデバイスクレデンシャルの初期の確立に対処するための技術を記載する。実施形態は、エンドポイントのタイプに関係なくセキュアなクレデンシャルの確立を統合することを対象としており、したがって、ＩｏＴデバイス間の大きな多様性のチャレンジに対処している。このアプローチは、ＩｏＴエンドポイントのセキュアなインフラストラクチャへの初期の信頼できる登録のチャレンジに対処するように設計されており、ＩｏＴ環境内のデバイス間のセキュアな通信を可能にする。【選択図】図１

Description

セキュアなシステムおよびアプリケーションの必要性が高まっている。現在、セキュアな集積回路（ＩＣ）は、工場のフロアでセキュリティキーを使用してプログラムされることが多い。セキュアなキーは、例えば、保存されたデータの保護、デジタルコンテンツへのアクセスの制御、トランザクションで使用されるデータの暗号化／認証など、様々な方法で使用できる。これらのキーは、ワンタイムプログラマブルメモリに保存でき、このメモリには、キーを直接保持するか、様々な機能のキーを導出する暗号化機能で使用されるベースキーを保持できる。通常、セキュリティは、セキュリティで保護された施設でキーの読み込みプロセスを実行することにより提供される。モノのインターネット（ＩｏＴ）デバイスおよびＩｏＴアプリケーションの使用も増えている。ＩｏＴデバイスは、ＩｏＴアプリケーションサービスおよびＩｏＴプラットフォームサービスに接続するためにクレデンシャルを必要とする。しかしながら、製造時にクレデンシャルを提供するために必要な機器および専門知識のために、製造時にこれらのクレデンシャルを提供することは困難である。また、ＩｏＴデバイスのコンピューティングリソースおよびストレージリソースは様々であり、多くの場合制限されている。

本開示は、添付図面の図において、限定としてではなく、実施例として示されている。

一実施形態によるＩｏＴデバイス管理（ＩＤＭ）システムのシステム図を示す。 一実施形態によるＩＤＭシステムのデータフローシーケンスを示すフロー図である。 一実施形態による、信頼およびポリシー確立段階中のデバイスプロビジョニングサービスとＲｏＴ認証サービスとの間のデータフローシーケンスを示すフロー図である。 一実施形態による、デバイスプロビジョニング段階中のＩｏＴデバイスとデバイスプロビジョニングサービスとの間のデータフローシーケンスを示すフロー図である。 一実施形態による、デバイスプロビジョニング段階の認証プロセス中のＩｏＴデバイスとＲｏＴ認証サービスとの間のデータフローシーケンスを示すフロー図である。 一実施形態による、デバイスプロビジョニング段階のアクセスプロセス中のＩｏＴデバイス、デバイスプロビジョニングサービス、およびＲｏＴ認証サービス間のデータフローシーケンスを示すフロー図である。 一実施形態による、デバイスプロビジョニング段階中のＩｏＴデバイス、デバイスプロビジョニングサービス、ならびに証明書プロセスおよび登録プロセスのためのＩｏＴアプリケーションサービス間のデータフローシーケンスを示すフロー図である。 一実施形態による、アプリケーションデータ段階中のＩｏＴデバイス、デバイスプロビジョニングサービス、およびＩｏＴアプリケーションサービス間のデータフローシーケンスを示すフロー図である。 一実施形態による、ＩｏＴデバイス、ＲｏＴ認証サービス、デバイスプロビジョニングサービス、およびＩｏＴアプリケーションサービス間の相互作用のシーケンスを示すフロー図である。 一実施形態による、ＩｏＴデバイス、ＲｏＴ認証サービス、デバイスプロビジョニングサービス、ならびに認証およびアイデンティティサービスのためのＩｏＴアプリケーションサービスの間で交換されるメッセージのシーケンスを示すフロー図である。 一実施形態による、図５のシーケンスの関連するコンポーネントのそれぞれに対して実行される様々な動作を示すフロー図である。 一実施形態による、ＩｏＴデバイス、ＲｏＴ認証サービス、デバイスプロビジョニングサービス、およびＩｏＴアプリケーションサービスの間で交換されるＨＴＴＰメッセージのシーケンスを示すフロー図である。 一実施形態による、ＩｏＴデバイス、ＲｏＴ認証サービス、デバイスプロビジョニングサービス、ならびに認証、アイデンティティ、およびデータ立証のためのＩｏＴアプリケーションサービス間の相互作用のシーケンスを示すフロー図である。 一実施形態によるｐｕｂＤＢベースのプロビジョニングプロセスのフロー図である。 一実施形態による、図９のシーケンスの関連するコンポーネントのそれぞれに対して実行される様々な動作を示すフロー図である。 一実施形態による署名ＰＫＩベースのプロビジョニングプロセスのフロー図である。 一実施形態による、図１１のシーケンスの関連するコンポーネントのそれぞれで実行される様々な動作を示すフロー図である。 一実施形態による対称コアのＴＬＳ ＰＫＩベースのプロビジョニングプロセス１８００のフロー図である。 一実施形態による非対称コアのためのＴＬＳ ＰＫＩベースのプロビジョニングプロセス１９００のフロー図である。 一実施形態によるライブセキュリティチェックプロセスのフロー図である。 一実施形態による、ＩｏＴデバイスをセキュアにプロビジョニングする方法のフロー図である。 本明細書に記載の方法のいずれかが一実施形態に従って実行され得るコンピュータシステムの一実施形態の図である。

本明細書の記載は、モノのインターネット（ＩｏＴ）デバイス管理を対象とした技術について記載する。ＩｏＴデバイスは、アプリケーションサービス、プラットフォームサービスなどに接続するためにクレデンシャルを必要とする。しかしながら、必要な機器および専門知識のため、製造においてこれらのクレデンシャルを提供することは困難である。本明細書の記載は、この分野でこれらのＩｏＴデバイスを一意に識別し、ＩｏＴデバイスにチャレンジし、ＩｏＴデバイス内にある暗号素材の知識を獲得し、ＩｏＴデバイスに独自の暗号素材の知識があることを確認するために使用できるＩｏＴセキュリティサービス（ＩＳＳ）インフラストラクチャである。ＩｏＴデバイスがそのアイデンティティの証拠を提供すると、クレデンシャルをそのＩｏＴデバイスに与えて、プラットフォームサービス、アプリケーションサービスなどに接続できる。ＩｏＴデバイスは、一意のアイデンティティおよび暗号化キーを有する。ＩＳＳインフラストラクチャは、デバイス内の暗号化キーに関する知識を有する。ＩｏＴデバイスは、ＩＳＳインフラストラクチャのサーバの１つにメッセージを送信して、特定のプラットフォームサービスのクレデンシャルを要求できる。ＩＳＳインフラストラクチャのサーバは、そのＩｏＴデバイスにチャレンジを送信できる。ＩｏＴデバイスは、キーを使用してチャレンジを計算し、応答で暗号計算をサーバに送信する。サーバは、チャレンジへの応答が正しいこと、およびそのアイデンティティとＩｏＴデバイス内の暗号化キーの事前確認を検証する。チャレンジに対する応答が検証されると、サーバはプラットフォームのクレデンシャルをＩｏＴデバイスに配布できる。

以前は、エンドポイントをＩｏＴドメインに登録する典型的なシナリオでは、手動登録が必要だった。手動登録プロセスでは、デバイス（例えば、ＩｏＴハブまたはプラットフォームデバイス）によってエンドポイントにケーブルを接続して、ＩｏＴデバイスのクレデンシャルを確立する必要があった。これを大規模に実行することは難しく、遠隔で実行することは不可能だった。本明細書で記載される実施形態は、ＩｏＴデバイスの登録を含むＩｏＴデバイスの管理を、遠隔でかつより大規模に可能にする。

一実施形態では、分散信頼ネットワークを確立するためのシステムは、ハードウェアまたはソフトウェアの信頼のルートを備えたデバイス、デバイスにアプリケーションを提供するアプリケーションサービス、およびデバイスの信頼のルートを直接知る信頼サービスのルートを有する。トラストサーバのルートは、アプリケーションサービスがデバイスの信頼ルートを直接知らなくても、デバイスとの信頼できる接続を確立できるように、アプリケーションサービスに認証サービスおよびセキュアなプロビジョニングサービスを提供する。直接的な知識は、デバイスのデバイス製造中にプロビジョニングされた１つ以上のキーに基づいている場合がある。直接的な知識とは、この情報がシステム自体以外の手段で受信されることを意味する。情報は、帯域外（空間における外部）または以前（時間における外部）で交換できる。

図１は、一実施形態によるＩｏＴデバイス管理（ＩＤＭ）システム１００のシステム図を示す。ＩＤＭシステム１００は、ＩｏＴアプリケーションサービス１０８がＩｏＴデバイス１１０のＲｏＴを直接知らなくてもＩｏＴデバイス１１０との信頼できる接続を確立できるように、認証サービス１０４およびデバイスプロビジョニングサービス１０６を提供する信頼のルート（ＲｏＴ）サービス１０２を含む。ＩｏＴデバイス１１０のＲｏＴは、ハードウェアＲｏＴ、ソフトウェアＲｏＴ、またはそれらの任意の組み合わせであり得る。ＲｏＴサービス１０２は、認証および承認ポリシーサーバ１１２（以下、「認証ポリシーサーバ１１２」）およびＲｏＴアイデンティティサーバ１１４を含む。ＩｏＴデバイス１１０は、柔軟性のあるフロントエンドプロトコル１０１（認証および承認のためのＡｕｔｈＮおよびＡｕｔｈＺプロトコルとラベル付けされた）を使用して認証サービス１０４と通信することができる。一実施形態では、認証ポリシーサーバ１１２およびＲｏＴアイデンティティサーバ１１４は、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）などのフロントエンドプロトコル１０１から独立したバックエンドプロトコル１０３を使用して通信する。いくつかの実施形態では、フロントエンドプロトコル１０１はＩｏＴデバイス１１０のステートを保持し、バックエンドプロトコルはステートレスである。フロントエンドプロトコル１０１は、ＩｏＴデバイス１１０に対するチップ製造業者のビジネス要件、通信プロトコル、および認証プロトコルを含むことができる。認証サービス１０４は、セキュリティと柔軟性のトレードオフとして２つのサーバ間で分割できる。ＲｏＴアイデンティティサーバ１１４を認証ポリシーサーバ１１２とは別のサーバとして置くことにより、柔軟性とセキュリティがあり得る。認証ポリシーサーバ１１２は、様々な種類のＩｏＴデバイスとのプロトコル固有の通信に柔軟性を提供できるが、ＲｏＴアイデンティティサーバ１１４に保存されたセキュリティクレデンシャルは保護できる。例えば、ＲｏＴアイデンティティサーバ１１４は、保護される必要があるデバイスキーのデータベースを含むことができる。ＲｏＴアイデンティティサーバ１１４のデータベースへのアクセスは、ＩｏＴデバイス１１０によるＲｏＴアイデンティティサーバ１１４へのより直接的なアクセスと比較して、ＲｏＴアイデンティティサーバ１１４によって保存されたセキュアなクレデンシャルを提供する前に、ＩｏＴデバイスを認証し、ＩｏＴデバイス１１０を承認する認証ポリシーサーバ１１２によって管理できる。実際、ＲｏＴアイデンティティサーバ１１４は、ＩｏＴデバイス１１０から隠されているとみなすことができる。他の実施形態では、認証ポリシーサーバ１１２およびＲｏＴアイデンティティサーバ１１４は、単一のサーバに一緒に実装することができる。一実施形態では、フロントエンドプロトコル１０１は、ＩｏＴデバイス１０１に対するチップ製造業者のビジネス要件、デバイス間の通信に使用される通信プロトコル、およびＩｏＴデバイス１１０を認証するために使用される認証プロトコルを含む。１つの認証ポリシーサーバ１１２および１つのＲｏＴアイデンティティサーバ１１４が示されているが、他の実施形態では、認証サービス１０４は複数の認証ポリシーサーバおよび複数のＲｏＴアイデンティティサーバ、またはそれらの任意の組み合わせを含むことができることに留意されたい。例えば、複数の認証ポリシーサーバがあっても、単一のＲｏＴアイデンティティサーバ１１４がある場合がある。

上記で記載したように、ＲｏＴサービス１０２は、デバイスプロビジョニングサービス１０６を含む。図示されるように、フロントエンドプロビジョニングポリシーサーバ１１６およびバックエンドプロビジョニングサーバ１１８は、デバイスプロビジョニングサービス１０６を提供することができる。ＩｏＴデバイス１１０は、プロトコル固有のフロントエンドプロトコル１０５（ラベル付きデバイスプロビジョニング）を使用して、フロントエンドプロビジョニングポリシーサーバ１１６と通信することができる。一実施形態では、フロントエンドプロビジョニングポリシーサーバ１１６およびバックエンドプロビジョニングサーバ１１８は、ＨＴＴＰＳなどのフロントエンドプロトコル１０５から独立したバックエンドプロトコル１０７を使用して通信する。デバイスプロビジョニングサービス１０６は、認証サービス１０４の認証ポリシーサーバ１１２およびＲｏＴアイデンティティサーバ１１４のように、セキュリティと柔軟性のトレードオフとして２つのサーバ間で分割できる。プロビジョニングサーバ１１８をプロビジョニングポリシーサーバ１１６とは別のサーバとして配置することにより、柔軟性とセキュリティを確保できる。プロビジョニングポリシーサーバ１１６は、様々なタイプのＩｏＴデバイスとのプロトコル固有の通信に柔軟性を提供できるが、プロビジョニングサーバ１１８はＩｏＴデバイス１１０から隠すことができる。他の実施形態では、プロビジョニングポリシーサーバ１１６およびプロビジョニングサーバ１１８は、単一のサーバに一緒に実装することができる。１つのプロビジョニングポリシーサーバ１１６および１つのプロビジョニングサーバ１１８が示されているが、他の実施形態では、デバイスプロビジョニングサービス１０６は、複数のプロビジョニングポリシーサーバおよび複数のプロビジョニングサーバ、またはそれらの組み合わせを含むことができることに留意されたい。例えば、複数のプロビジョニングポリシーサーバがあっても、単一のプロビジョニングサーバ１１８がある場合がある。一実施形態では、フロントエンドプロトコル１０１は、ステートを保持し、バックエンドプロトコル１０３は、ステートレスである。一実施形態では、フロントエンドプロトコル１０５は、ＩｏＴデバイス１０１に対するチップ製造業者のビジネス要件、デバイス間の通信に使用される通信プロトコル、およびＩｏＴデバイス１１０を認証するために使用される認証プロトコルを含む。フロントエンドプロトコル１０５はまた、ＩｏＴデバイス１１０を認証するために使用されるべきＲｏＴ認証サービスを識別してもよい。

図１に示されるように、ポリシープロビジョニングサーバ１１６は、セキュアな接続１０９を介して認証ポリシーサーバ１１２（およびＲｏＴアイデンティティサーバ１１４）と通信することができる。セキュアな接続１０９を介して、ポリシープロビジョニングサーバ１１６は、例えば、以下に記載するメッセージ認証コード（ＭＡＣ）を提供することにより、セキュリティクレデンシャルを交換し、ポリシーを確立し、認証ポリシーサーバ１１２とセッションクレデンシャルを交換することができる。ポリシーは、ＩｏＴデバイス１１０をプロビジョニングするときの、および／またはＩｏＴデバイス１１０をプロビジョニングしないときのルールまたは決定を含むことができる。

上記のように、ＲｏＴサービス１０２は認証サービス１０４およびデバイスプロビジョニングサービス１０６を提供するため、ＩｏＴアプリケーションサービス１０８は、ＩｏＴデバイス１１０のＲｏＴを直接知ることなく、ＩｏＴデバイス１１０との信頼できる接続を確立できる。ＩｏＴアプリケーションサービス１０８は、ＩｏＴアプリケーションをＩｏＴデバイス１１０に提供するために、ＩｏＴアプリケーションゲートウェイ１２０およびＩｏＴアプリケーションサーバ１２２を含む。ＩｏＴデバイス１１０は、プロトコル固有のフロントエンドプロトコル１１１（ラベル付きアプリケーションデータ）を使用してＩｏＴアプリケーションゲートウェイ１２０と通信することができる。一実施形態では、ＩｏＴアプリケーションゲートウェイ１２０およびＩｏＴアプリケーションサーバ１２２は、フロントエンドプロトコル１１１から独立したバックエンドプロトコル１１３を使用して通信することができる。本明細書に記載するように、アプリケーションデータはセキュアな接続を介して通信されるため、このバックエンドプロトコル１１３は必ずしもセキュアではない場合がある。あるいは、ＩｏＴアプリケーションゲートウェイ１２０およびＩｏＴアプリケーションサーバ１２２は、ＨＴＴＰＳを使用して通信することができる。ＩｏＴアプリケーションゲートウェイ１２０は、ＩｏＴ１１０がＩｏＴアプリケーションサーバ１２２にアクセスできるかどうかを決定することができる。つまり、ＩｏＴアプリケーションゲートウェイ１２０は、ＩｏＴアプリケーションサーバ１２２がＩｏＴアプリケーションサービス１０８をＩｏＴデバイス１１０に提供する前に、ＩｏＴデバイス１１０を認証／承認することができる。実際には、ＩｏＴアプリケーションサーバ１２２は、ＩｏＴデバイス１１０から隠されているとみなすことができる。他の実施形態では、ＩｏＴアプリケーションゲートウェイ１２０およびＩｏＴアプリケーションサーバ１２２は、単一のサーバに一緒に実装することができる。１つのＩｏＴアプリケーションゲートウェイ１２０および１つのＩｏＴアプリケーションサーバ１２２が示されているが、他の実施形態では、ＩｏＴアプリケーションサービス１０８は複数のＩｏＴアプリケーションゲートウェイおよび複数のＩｏＴアプリケーションサーバを含むことができることに留意されたい。

図１に示すように、ＩｏＴアプリケーションゲートウェイ１２０は、セキュアな接続１１５を介してプロビジョニングポリシーサーバ１１６（およびプロビジョニングサーバ１１８）と通信することができる。セキュアな接続１１５を介して、プロビジョニングポリシーサーバ１１６は、ＩｏＴデバイス１１０によって提示されるプロビジョニングされた情報を交換して、後述するようにＩｏＴアプリケーションゲートウェイ１２０によってＩｏＴデバイス１１０へのアクセスを許可すべきかどうかをチェックすることができる。

認証サービス１０４は、認証サービスプロバイダーなどの第１のエンティティによって管理され得る。デバイスプロビジョニングサービス１０６は、ＩｏＴプラットフォームプロバイダなどの第２のエンティティによって管理され得る。ＩｏＴアプリケーションサービス１０８は、第３のエンティティによって管理され得る。場合によっては、認証サービス１０４およびデバイスプロビジョニングサービス１０６は、単一のエンティティで管理できる。場合によっては、デバイスプロビジョニングサービス１０６およびＩｏＴアプリケーションサービス１０８は、単一のエンティティで管理できる。また、これらのサービスのサーバは複数のマシンに展開でき、別々の施設に配置することもできることに留意されたい。例えば、認証サービス１０４のサーバはセキュアなデータセンターに展開でき、デバイスプロビジョニングサービス１０６およびＩｏＴアプリケーションサービス１０８のサーバはクラウドデータセンターに展開できる。

別の実施形態では、ＩｏＴセキュア分析サービス１３０は、ＩＳＳインフラストラクチャのデータ分析のための情報を収集するために、認証サービス１０４、デバイスプロビジョニングサービス１０６、およびＩｏＴアプリケーションサービス１０８のそれぞれと通信することができる。図１に示された実施形態では、ＩｏＴセキュア分析サービス１３０は、ＩｏＴアプリケーションゲートウェイ１２０、プロビジョニングサーバ１１８、およびＲｏＴアイデンティティサーバ１１４と通信する。他の実施形態では、ＩｏＴセキュア分析サービスは、それぞれのサービス内の他のサーバと通信して、分析用のデータを収集することができる。

いくつかの実施形態では、ＩｏＴデバイス１１０はハードウェアＲｏＴを含む。他の実施形態では、ＩｏＴデバイス１１０はソフトウェアＲｏＴを含む。一実施形態では、ＩｏＴデバイス１１０の暗号コア（セキュアなコアとも呼ばれる）は、ハードウェアまたはソフトウェアＲｏＴへのアクセスを管理することができる。ユーザーがクレデンシャルを持っている代わりに、ＩｏＴデバイスは認証サービス１０４に保存されている属性を持っている。これらの属性はＲｏＴ属性と呼ばれ、１）セッションキー、２）シーケンス（入力は受け入れられる）、３）コンテナ（プログラム、コードなど）、４）派生キー、またはその任意の組み合わせが含まれる場合がある。認証サービス１０４は、デバイスプロビジョニングサービス１０６、ファームウェアアップデート、グループプライバシーアイデンティティなどの外部パーティに対するＲｏＴ属性の使用を承認することができる。一部の実施形態では、ＲｏＴ属性はデータベースに保存される必要はないが、認証サービス１０４による要求に応じて生成され得る。ＲｏＴ属性は、キーマテリアル、カーネルバージョンなどのデバイスメタデータ、またはその他の属性である。

一実施形態では、認証ポリシーサーバ１１２は、暗号研究部（ＣＲＤ）認証承認（ＡｕｔｈＮ／ＡｕｔｈＺ）ポリシーサーバであり、第１の施設に配置することができる。本明細書で記載するように、認証ポリシーサーバ１１２は、ＡｕｔｈＮ／ＡｕｔｈＺポリシーおよびトークン管理を担当することができる。認証ポリシーサーバ１１２は、トークンをＩｏＴデバイス１１０（クライアント）に返し、ＲｏＴアイデンティティサーバ１１４を使用できる。認証ポリシーサーバ１１２を主に使用して、クライアント側のポリシーとプロトコルをＲｏＴアイデンティティサーバ１１４の１つ以上のアプリケーションプログラミングインターフェース（ＡＰＩ）のセットにマッピングすることができる。ＲｏＴアイデンティティサーバ１１４は、ＩｏＴデバイス１１０内のＲｏＴセキュアコアのＲｏＴ属性を保存および管理する責任を負うことができる。例えば、対称キー暗号システムでは、ＲｏＴアイデンティティサーバ１１４は対称キーを保存できる。

デバイスプロビジョニングサーバ１０６では、プロビジョニングポリシーサーバ１１６は認証ポリシーサーバ１１２と同様であり、ＩｏＴデバイス１１０のプロビジョニングポリシーを管理するフロントエンドサーバとして動作する。プロビジョニングポリシーサーバ１１６は、ＩｏＴデバイス１１０に関する情報をプロビジョニングするための特定のサーバへのフロントエンドとすることができる。例えば、プロビジョニングサーバ１１８は証明書を発行できる。プロビジョニングポリシーサーバ１１６は、プロビジョニングトークン要求の一部としてアクセストークンを期待でき、アクセストークンは認証ポリシーサーバ１１２によって発行されたはずである。プロビジョニングポリシーサーバ１１６は、潜在的にアクセストークンを使用して、関連付けられたＲｏＴの他の属性を要求することができる。トークンおよび要求が有効な場合、プロビジョニングポリシーサーバ１１６は、ＩｏＴデバイス１１０にプロビジョニング情報を発行でき、サービスプロバイダープラットフォーム（例えば、デバイスプロビジョニングサービス１０６のオペレーター）に通知することもできる。これは、プロビジョニングサーバ１１８のＡＰＩを介して行うことができる。プロビジョニングサーバ１１８は、デバイスクレデンシャルを取り消すための追加のＡＰＩコールも含み得る。この場合、プロビジョニングポリシーサーバ１１６は、クレデンシャルを無効にするためにサービスプロバイダーに電話をかけることができる。プロビジョニングサーバ１１８は、認証（ｃｅｒｔｉｆｉｃａｔｅ）局に必要な情報をプロビジョニングする役割を担う。

ＩｏＴアプリケーションサービス１０８において、ＩｏＴアプリケーションゲートウェイ１２０は、ＩｏＴデバイス１１０上のセキュリティステートに関連するＩｏＴクライアントデータを取得し、ＩｏＴデバイス１１０をＩｏＴアプリケーションサーバ１２２にリダイレクトする責任を負う。ＩｏＴアプリケーションゲートウェイ１２０はサーバとして示されているが、他の実施形態では、ＩｏＴアプリケーションゲートウェイ１２０は、ＩｏＴアプリケーションサーバ１２２またはＩｏＴプラットフォームプロバイダによって提供されるＡＰＩに統合されたルールのセットとして実装できる。ＩｏＴアプリケーションサーバ１２２は、有効な証明書を持つＩｏＴデバイス１１０のみがＩｏＴアプリケーションに接続できるように構成することができる。ＩｏＴアプリケーションサーバ１２２は、トランスポート層セキュリティ（ＴＬＳ）を介したメッセージキューイングテレメトリトランスポート（ＭＱＴＴ）をサポートすることができる。あるいは、ＩｏＴアプリケーションサーバ１２２は、他の発行−購読メッセージプロトコルをサポートすることができる。ＩｏＴアプリケーションサーバ１２２は、メッセージブローカーを使用しても使用しなくてもよい。ＩｏＴアプリケーションサーバ１２２は、アプリケーションロジック用のユーザインターフェース（ＵＩ）とともにＩｏＴアプリケーションデータを提供することを可能にすることができる。

ＩｏＴセキュア分析サービス１３０では、サーバがデータの分析とデータの異常の報告を担当する。認証統計の提供に加えて、ＩｏＴセキュア分析サービス１３０を使用して、ポリシー決定またはポリシー決定の変更のためのビジネスロジックの入力または考慮事項となる異常および非クレデンシャルデータを検出できる。

一実施形態において、クライアントソフトウェア開発キット（ＳＤＫまたは開発キット）は、ＩｏＴアプリケーションと相互作用するためのアプリケーションの作成を可能にするＩｏＴデバイス製造業者またはＩｏＴプラットフォームプロバイダに提供され得る。クライアントＳＤＫは、サーバからダウンロードされたスクリプトを実行して特定のプロファイルまたはポリシーを実装する追加機能を備えた機能ベースのプラグインアーキテクチャを提供できる。プラグインは動的にすることができ、追加のプラグインはダウンロードできる。リソースの少ない一部のＩｏＴデバイスには、すべてのプラグインが保存されない場合がある。プラグインは、ダウンロード可能な（認証用に署名された）動的スクリプト（埋め込みＬｕａなど）を介して結合できる。ＩｏＴデバイス１１０は、様々なＡｕｔｈＮ／ＡｕｔｈＺモデルをサポートする認証ライブラリを備えてもよい。これらのライブラリとプラグインは、例えば、Ｏｐｅｎ ＩＤプロトコルでは非常に小さくする必要がある場合がある。Ｘ．５０９証明書のプロビジョニングライブラリサポートも提供できるが、コンピューティングリソースの観点から、プロビジョニングライブラリは非常にシンプルで軽量である必要がある。例えば、ＩｏＴクライアントライブラリには、サードパーティベンダーまたはＩｏＴプラットフォームプロバイダが提供するＩｏＴクライアントライブラリを含めることができる。これらのＩｏＴクライアントライブラリは、ＴＬＳでＭＱＴＴを使用できる。

図２〜３Ｆは、図１の様々なコンポーネント間のデータフローを示すデータフローシーケンス図である。データフローシーケンス図には、認証トークン要求、アイデンティティトークン、およびアクセストークンへの参照がある。認証トークン要求は、ＲｏＴアイデンティティサーバ１１４（例えば、オープンＩｏＴアイデンティティ接続サーバ）からのトークンに対するクライアント要求（すなわち、ＩｏＴデバイス１１０）である場合がある。要求の範囲に応じて、ＲｏＴアイデンティティサーバ１１４はアイデンティティトークン、アクセストークン、またはその両方を返すことができる。アイデンティティトークンは、認証プロセスおよびプロトコルの結果を表す場合がある。アイデンティティトークンは、ＩｏＴデバイス１１０のＲｏＴの識別子を含むことができる。アイデンティティトークンには、ＲｏＴに関する追加情報（例えば、デバイス、カーネル、オペレーティングシステムに関するメタデータ）と、ＲｏＴが認証サービスでどのように認証されるかの詳細を含めることができる。アクセストークンは、ＲｏＴに関するＲｏＴ属性であるリソースなど、リソースへのアクセスを許可できる。アクセストークンには、ＲｏＴに関する情報を含めることができる。情報は、ＩｏＴデバイス１１０、ＩｏＴデバイス１１０のカーネル、オペレーティングシステム（ＯＳ）などに関するメタデータとみなすことができる。外部サービスは、ＲｏＴに関する情報（メタデータ）を使用してＲｏＴ属性にアクセスする。

図２〜３Ｆに関して記載された実施形態は、ＩｏＴ設定におけるデバイスクレデンシャルの初期の確立に対処するアプローチを対象とする。実施形態は、エンドポイントのタイプに関係なくセキュアなクレデンシャルの確立を統合することを対象としており、したがって、ＩｏＴデバイス間の大きな多様性のチャレンジに対処している。このアプローチは、ＩｏＴエンドポイントをセキュアなインフラストラクチャに最初に信頼して登録するというチャレンジに対処するように設計されており、ＩｏＴ環境内のデバイス間でセキュアな通信が可能になる。

図２は、一実施形態によるＩＤＭシステムのデータフローシーケンス２００を示すフロー図である。データフローシーケンス２００は、信頼確立段階２０２、セキュアなデバイスプロビジョニング段階２０４、およびアプリケーションデータ段階２０６に分解される。信頼確立段階２０２の間に、デバイスプロビジョニングサービス１０６およびＲｏＴ認証サービス１０４は、セキュリティクレデンシャル２０１を交換し、ポリシー２０３を確立し、任意選択で通信チャネルを介してセッションクレデンシャル２０５を交換する。通信チャネルは、セキュリティで保護された通信チャネルでも、帯域外の通信チャネルでも、セキュリティを強化できる。確立されたポリシーは、ＩｏＴデバイス１１０をプロビジョニングするかどうか、ＩｏＴデバイス１１０を認証するかどうか、ＩｏＴデバイス１１０を承認するかどうかなどを決定するために使用される決定ロジックを含むことができる。

セキュアなデバイスプロビジョニング段階２０４の間に、ＩｏＴデバイス１１０は、デバイスプロファイル情報２０７を伴う要求をデバイスプロビジョニングサービス１０６に送信する。デバイスプロファイル情報２０７は、製造業者使用記述（ＭＵＤ）ファイルに記述されたユニフォームリソースロケータ（ＵＲＬ）を含むことができる。ＭＵＤファイルは、特定のデバイスと対話する方法を記述できる。ＭＵＤファイルにはプロファイル識別子を含めることができる。ＭＵＤファイルは、ＲｏＴ認証サービスがＩｏＴデバイスの特定のＲｏＴの計算を持つように、使用するＲｏＴ認証サービスを指定することもできる。ブロック２０８で、デバイスプロビジョニングサービス１０６は、デバイスプロファイル情報２０７から、ＲｏＴ認証サービス１０４によってＩｏＴデバイス１１０を認証するために使用される認証方法を決定することができる。認証方法には、識別ポリシー識別子を関連付けることができる。また、ブロック２０８で、デバイスプロビジョニングサービス１０６は、リダイレクト応答２０９のＵＲＬ内の識別ポリシー識別子をエンコードすることができる。デバイスプロビジョニングサービス１０６は、リダイレクト応答２０９をＩｏＴデバイス１１０に送信して、選択されたポリシーで指定されているように、ＩｏＴデバイス１１０をＲｏＴ認証サービス１０４にリダイレクトする。例えば、リダイレクト応答２０９は、ＩｏＴデバイス１１０がＲｏＴ認証サービス１０４に接続するための接続ポイントを含むことができる。ＩｏＴデバイス１１０は、ＲｏＴ情報をＲｏＴ認証サービス１０４に（すなわち、リダイレクト応答２０９内の指定された接続ポイントに）送信する。ブロック２１２で、ＲｏＴ認証サービス１０４は、ポリシーを識別し、ＩｏＴデバイス１１０のアイデンティティを確立し、潜在的にトークン（例えば、アクセストークン）をＩｏＴデバイス１１０に発行するためのポリシーの下で要件を決定する。ＲｏＴ認証サービス１０４は、デバイスが正しいＲｏＴ情報を有するかどうかを評価し得る。ＲｏＴ認証サービス１０４およびＩｏＴデバイス１１０は、指定されたポリシーに従ってアイデンティティ２１３を確立し、ポリシーに従ってアイデンティティ２１３が確立されると、ＲｏＴ認証サービス１０４はポリシーに従ってトークン２１５を発行する。ＲｏＴ認証サービス１０４またはデバイスプロビジョニングサービス１０６は、チャレンジおよびＭＡＣを送信し、ＩｏＴデバイス１００を検証するために応答を評価することができる。トークン２１５は、本明細書で記載されるように、アクセストークンまたは、アクセストークンとアイデンティティトークンとすることができる。次に、ＩｏＴデバイス１１０は、トークン２１７を伴うプロビジョニング要求をデバイスプロビジョニングサービス１０６に送信する。ブロック２１８で、デバイスプロビジョニングサービス１０６は、要求とトークンを検証する。デバイスプロビジョニングサービス１０６は、ＩｏＴアプリケーションサービス１０８にＩｏＴデバイス１１０を登録または取り消すために、任意選択でメッセージ２１９をＩｏＴアプリケーションサービス１０８に送信することができる。ＭＵＤファイルは、デバイスプロビジョニングサービス１０６がＩｏＴデバイス１１０を登録すべきかどうか、ならびにデバイスプロビジョニングサービス１０６がＩｏＴデバイス１１０を登録するために接続すべき場所など、どのＩｏＴアプリケーションサービス１０８がＩｏＴデバイス１１０を登録すべきかを指定することができる。ＩｏＴアプリケーションサービス１０８は、ＲｏＴ認証サービスによって追加されるレジストリまたは登録サービスを提供して、特定のＩｏＴデバイス１１０のクレデンシャルを認識し、ＩｏＴアプリケーションサービス１０８に通知することができる。ブロック２１８で、要求およびトークンが検証される場合、デバイスプロビジョニングサービス１０６は、プロビジョニング情報２２１をＩｏＴデバイス１１０に発行する。

アプリケーションデータ段階２０６の間、ＩｏＴデバイス１１０およびＩｏＴアプリケーションサービス１０８は、プロビジョニング情報２２１を使用して、データ２２３を接続および交換する。

ＩＤＭシステムのデータフローシーケンス２００は、認証がＩｏＴアプリケーションサービス１０８によってＲｏＴ認証サービス１０４に（および／またはデバイスプロビジョニングサービス１０６に関連して）委任されるため、委任認証システムとみなされ得る。

図３Ａは、一実施形態による、信頼およびポリシー確立段階３０２中のデバイスプロビジョニングサービス１０６とＲｏＴ認証サービス１０４との間のデータフローシーケンス３００を示すフロー図である。信頼およびポリシー確立段階３０２の間、デバイスプロビジョニングサービス１０６およびＲｏＴ認証サービス１０４は、セキュリティクレデンシャル３０１を交換する。セキュリティクレデンシャル３０１は、デバイスプロビジョニングサービス１０６とＲｏＴ認証サービス１０４との間にセキュアな接続を確立するためのキー、ＭＡＣなどを含むことができる。デバイスプロビジョニングサービス１０６およびＲｏＴ認証サービス１０４は、通信チャネルを介してセキュリティクレデンシャルを交換することができる。通信チャネルは、セキュアな通信チャネルにすることができる。セキュアな通信チャネルは、よりセキュアにするために帯域外通信チャネルにすることができる。デバイスプロビジョニングサービス１０６は、ＲｏＴ認証サービス１０４から認証方法のリストを要求３０３することができ、ＲｏＴ認証サービス１０４は、認証方法のリストで応答３０４することができる。例えば、ＩｏＴデバイスの特定のクラスでは、特定の認証方法を使用できるが、ＩｏＴデバイスの異なるクラスでは異なる認証方法を使用できる。リスト内の認証方法のそれぞれについて、デバイスプロビジョニングサービス１０６はループ３０５を使用して、認証方法のそれぞれを選択３０７し、それぞれにポリシー識別子を割り当てることができる。ポリシー識別子は、リダイレクト応答のＵＲＬで暗号化できる。各認証方法について、デバイスプロビジョニングサービス１０６は、ポリシー識別子３０９および認証方法のリストをＲｏＴ認証サービス１０４にアップロードすることができる。ポリシー識別子は、検証時にＩｏＴデバイス３１１に返されるトークンの要件３１１も定義できる。デバイスプロビジョニングサービス１０６およびＲｏＴ認証サービス１０４は、セッションキー３１３を交換することもできる。

図３Ｂは、一実施形態による、セキュアなデバイスプロビジョニング段階４０２中のＩｏＴデバイスとデバイスプロビジョニングサービス１０６との間のデータフローシーケンス４００を示すフロー図である。セキュアなデバイスプロビジョニング段階４０２の間に、ＩｏＴデバイス１００は、デバイスプロファイル情報４０１（例えば、ＭＵＤに記述されたＵＲＬ）をデバイスプロビジョニングサービス１０６に送信する。デバイスプロビジョニングサービス１０６は、プロファイル情報４０１のプロファイル識別子に基づいてプロビジョニングポリシー情報４０３を取得する。デバイスプロビジョニングサービス１０６は、どの識別ポリシーを要求４０５するかを決定し、リダイレクト応答４０７をＩｏＴデバイス１１０に送信する。リダイレクト応答４０７は、認証に使用される暗号化されたポリシー識別子を含むＵＲＬ（例えば、ＵＲＬ／Ｔｏｐｉｃ／…）でＩｏＴデバイス１１０をＲｏＴ認証サービス１０４にリダイレクトすることができる。プロビジョニングポリシーは、デバイスとＩＳＳバックエンド間の完全な相互作用の結果として、どのような状況でデバイスに何をプロビジョニングするかを記載していることに留意されたい。識別ポリシーは、デバイスの認証方法をＩＳＳインフラストラクチャのバックエンドに記載する。例えば、デバイスのタイプに応じて、デバイスを認証する方法（複数のキーデータベースなど）がいくつかあるため、後者が必要である。

図３Ｃは、一実施形態による、セキュアなデバイスプロビジョニング段階のＲｏＴ認証プロセス５０２中のＩｏＴデバイスとＲｏＴ認証サービスとの間のデータフローシーケンスを示すフロー図である。ＩｏＴデバイス１１０は、ＲｏＴ情報５０１をＲｏＴ認証サービス１０４に送信する（例えば、デバイスプロビジョニングサービス１０６からのリダイレクトで供給された接続ポイントを使用して）。ブロック５０３で、ＲｏＴ認証サービス１４０は、適用されるポリシー識別子（ＵＲＬで暗号化されている場合）を解読する。ＲｏＴ認証サービス１０４は、チャレンジ５０７をＩｏＴデバイス１１０に送信し、ＩｏＴデバイス１１０は、応答５０９をＲｏＴ認証サービス１０４に送り返す。ブロック５１１で、ＲｏＴ認証サービス１０４は応答を検証する。ＲｏＴ認証サービス１０４は、ポリシー識別子に関連付けられたポリシーで指定された各ポリシーについて、ループ５０５でチャレンジおよび応答を実行することができる。ループ５０５は、プロビジョニングポリシーサービスによって開始でき、ＲｏＴ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｉｃｅ（別名ＲｏＴアイデンティティサーバ）に関連する。しかしながら、代替実施形態では、ＲｏＴ認証サービスによってチャレンジを発行および検証することができる。このフローは示されていないが、より複雑になる可能性があり、基本的にはデバイス認証のチャレンジ／応答に基づいて同じトークン発行を実現できる。

別の実施形態では、ＩｏＴデバイス１１０は、任意選択で、データ５１３をＲｏＴ認証サービス１０４に送信して、ＲｏＴ属性を交渉、生成、または変更する。ＲｏＴ認証サービス１０４は、データ５１５をＩｏＴデバイス１１０に送り返し、許可される場合、ブロック５１７でＲｏＴ属性を生成または変更することができる。

識別ポリシーが検証された後も認証プロセスを続行すると、ＲｏＴ認証サービス１０４はブロック５１９でアクセストークンを生成する。別の実施形態では、ブロック５２１で、ＲｏＴ認証サービス１０４は、任意選択でＲｏＴアイデンティティトークンを生成することができる。ＲｏＴ認証サービス１０４は、トークン５２３（ブロック５１９のアクセストークンおよびブロック５２１の任意選択のアイデンティティトークン）をＩｏＴデバイス１１０に送信する。また、ＲｏＴ認証サービス１０４は、リダイレクト応答５２５をＩｏＴデバイス１１０に送信する。リダイレクト応答５２５は、ＩｏＴデバイス１００をＩｏＴアプリケーションサービス１０８にリダイレクトすることができる。

図３Ｄは、一実施形態による、セキュアなデバイスプロビジョニング段階のアクセスプロセス６０２中のＩｏＴデバイス、デバイスプロビジョニングサービス、およびＲｏＴ認証サービス間のデータフローシーケンスを示すフロー図である。アクセスプロセス６０２の間に、ＩｏＴデバイス１１０は、アクセストークンとともに要求６０１をデバイスプロビジョニングサービス１０６に送信することができる。一実施形態では、デバイスプロビジョニングサービス１０６は、トークン６０３を検証し、アクセストークンをＲｏＴ認証サービス１０４に送信する。ＲｏＴ認証サービス１０４は、アクセストークン６０７を検証し、検証応答６０９をデバイスプロビジョニングサービス１０６に送信する。別の実施形態では、デバイスプロビジョニングサービス１０６は、アクセストークン６１１から属性を抽出し、ＲｏＴ認証サービス１０４から追加のＲｏＴセキュリティ情報を要求する要求６１３を送信する。ＲｏＴ認証サービス１０４は、セキュリティ属性６１５へのアクセスをチェックし、ＲｏＴセキュリティ属性をデバイスプロビジョニングサービス１０６に送り返す。ＲｏＴセキュリティ属性には、ポリシー識別子を含める必要がある。アクセスプロセス６０２を続けると、デバイスプロビジョニングサービス１０６は、ポリシー識別子を含むセキュリティ属性６１９を検証する。

図３Ｅは、一実施形態による、セキュアなデバイスプロビジョニング段階中のＩｏＴデバイス１１０、デバイスプロビジョニングサービス１０６、ならびに証明書プロセスおよび登録プロセスのためのＩｏＴアプリケーションサービス１０８間のデータフローシーケンスを示すフロー図である。デバイスプロビジョニングサービス１０６が要求７０３を送信し、ＩｏＴデバイス１１０から応答７０５を受信するループ７０１の一部として、証明書プロセス７０２、および任意選択の登録プロセス７０４が実行され得る。

証明書プロセス７０２では、ＩｏＴデバイス１１０は、証明書要求７０７をデバイスプロビジョニングサービス１０６に送信することができる。デバイスプロビジョニングサービス１０６は、証明書要求を検証７０９し、証明書７１１をＩｏＴデバイス１１０に送信する。しかしながら、デバイスプロビジョニングサービス１０６が証明書要求を検証しない場合、証明書７１１はＩｏＴデバイス１１０に送信されない。

登録プロセス７０４では、デバイスプロビジョニングサービス１０６は、ＩｏＴデバイス１１０またはその関連するアクセストークンを登録するために、要求７１３をＩｏＴアプリケーションサービス１０８に送信する。ＩｏＴアプリケーションサービス１０８は、要求７１３に対してローカル登録７１５を実行する。登録プロセス７０４の一部として、ＩｏＴアプリケーションサービス１０８は、デバイスプロビジョニングサービス１０６に確認応答（ＡＣＫ）７１７を送信することもできる。

図３Ｆは、一実施形態による、アプリケーションデータ段階８０２中のＩｏＴデバイス１１０、デバイスプロビジョニングサービス１０６、およびＩｏＴアプリケーションサービス１０８間のデータフローシーケンスを示すフロー図である。アプリケーションデータ段階８０２の間に、ＩｏＴデバイス１１０は、プロビジョニング情報を伴う要求８０１を送信することにより、ＩｏＴアプリケーションサービス１０８と接続することができる。ＩｏＴアプリケーションサービス１０８は、要求を許可または拒否８０３することができる。ＩｏＴデバイス１１０は、後続のメッセージ８０５、８０９をＩｏＴアプリケーションサービス１０８に送信し、ＩｏＴアプリケーションサービス１０８からそれぞれの応答８０７、８１１を受信することができる。ＩｏＴデバイス１１０がＩｏＴアプリケーションサービス１０８へのアクセスが完了すると（例えば、ＩｏＴアプリケーションへのアクセスがもはやなくなると）、ＩｏＴデバイス１１０は、ＩｏＴアプリケーションサービスから切断する要求８１３を送信することができる。ＩｏＴアプリケーションサービス１０８は、確認応答８１５（ＡＣＫ）を送信することができる。

別の実施形態では、ＩｏＴアプリケーションサービス１０８は、アクセスチェック８０４を実行して、ＩｏＴデバイス１１０がブラックリストまたはホワイトリスト上にあるかどうかを判定することができる。一実施形態では、ＩｏＴアプリケーションサービス１０８は、プロビジョニングされた情報とともにデバイスプロビジョニングサービス１０６に要求８１７を送信する。デバイスプロビジョニングサービス１０６は、このＩｏＴデバイス１１０がアクセス８１９を有するかどうかをチェックし、その結果８２１をＩｏＴアプリケーションサービス１０８に送り返す。アクセスチェック８０４は、図示されるように、プルベースのモデルであり得る。あるいは、アクセスチェック８０４は、プッシュベースのモデルであり得る。

いくつかの実施形態では、ＩｏＴデバイス１１０は暗号マネージャ（ＣＭ）コアを含み、ＣＭコアデバイスと呼ばれる場合がある。ＣＭコアは、デバイスのプロキシとして動作する場合がある。ＣＭコアは、一連のコマンドを実行できるハードウェアコアである。シーケンスはデジタル署名され、および／または有効性の他の暗号化されたデモンストレーション（例えば、ＭＡＣ）を運ぶことができ、ＣＭコアはそれを検証してシーケンスの元の有効性を確認できる。これにより、シーケンスの配信に使用される通信チャネルが信頼できない場合でも、ＣＭコアが受け入れるデータ（および実行する操作）を制御できる。一実施形態では、ＣＭコアはＣｒｙｐｔｏＭａｎａｇｅｒ（商標）コアである。ＣｒｙｐｔｏＭａｎａｇｅｒ（商標）コアは、機能のアクティブ化、構成管理、およびセキュアなキー管理の暗号化制御を提供するハードウェアコアである。ＣｒｙｐｔｏＭａｎａｇｅｒ（商標）コアは、システムオンチップ（ＳｏＣ）デザインに統合でき、ＳｏＣメインバスにあるレジスタインターフェースを介してアクセスできる。モジュールは、命令とデータの両方を含むプログラムであり、その実行により、シーケンスがセキュアに構築される。シーケンスは、デリゲートアプライアンスデバイス内のハードウェアセキュリティモジュール（ＨＳＭ）で実行されているモジュールによって生成され、ＣＭコアによって消費されるバイナリデータであり得る。

一実施形態では、ＣＭコアは、本明細書で記載されるように、ＩｏＴ識別ならびにＲｏＴ認証および承認を確立するために、それぞれのサービスでセキュアなトランザクション処理を提供してもよい。ＩｏＴデバイス１１０は、モバイルデバイス用のチップセットを生産するファブレス半導体ベンダー、モバイルインターネット接続デバイスを製造するシステムインテグレーター（ＯＥＭ）、およびこれらのデバイスをワイヤレスネットワークに展開するモバイルネットワークオペレーター（ＭＮＯ）などによって製造および／または管理できる。これらの企業は、デバイスまたはコンポーネントの製造の一部を、大量生産サイトなどのリモート製造施設を運営するサードパーティの製造業者に委託する場合がある。顧客の製造および通信システムのミッションクリティカルな部分として、インフラストラクチャの設計上の優先事項は高可用性および整合性である。様々なＩｏＴデバイスおよびしばしば制限されるコンピューティングリソースを考えると、本明細書で記載する実施形態は、図１〜３Ｆに関して上記で記載したＲｏＴアイデンティティ、認証、および承認プロセスを使用して高可用性および整合性を提供し得る。一実施形態では、ＲｏＴ認証サービス１０４（および関連するサーバ）は、マスターキーを保護し、ＩｏＴアプリケーションサービス１０８を用いたＩｏＴデバイス１１０のインストール、構成、および動作を承認するエンティティとして機能することができる。各デバイスには、機密データを保管する金庫として、および機密データに関連するコマンドまたは操作を実行するためのプラットフォームとして動作できるＨＳＭが含まれる場合がある。機密データは、トークン、キー、シリアル番号、デバイス固有の情報、ファームウェアなどであってもよい。

記載の様々な部分は、コンポーネント、デバイス、またはサービスを論理エンティティとして参照していることに留意されたい。論理エンティティの内部構造が重要な場合がある。例えば、サービスには複数のサーバ、共有ファイルシステム、共有データベースなどが含まれる。サービスの内部が重要であり、これらの各サーバが論理エンティティとみなされるコンテキストでは、異なる操作を実行する可能性のある他のデバイスと区別するために、それぞれを個別のサーバデバイスと呼ぶ。各サーバまたはデバイスには、メインコンピューティングデバイス（例えば、プロセッサなど）と任意選択の組み込みＨＳＭが含まれる。一部のＩＤおよびキーはＨＳＭ内に保存されるが、その他はデバイスのハードドライブに保存される。ＩＤまたはキーの正確な位置は、本明細書で記載するように、その感度および実装の詳細に基づいて決定される。ＩＤは、インフラストラクチャ内のコンポーネントを識別するために使用される。また、図２〜３Ｆに関して上記で記載した様々なプロセスまたはデータフローは、ハードウェア（例えば、回路、専用ロジック、プログラマブルロジック、マイクロコードなど）、ソフトウェア、ファームウェア、またはそれらの組み合わせを備え得る処理ロジックによって実行され得ることに留意されたい。

別の実施形態では、アプリケーションサービスに対してデバイスを認証するためのシステムは、ａ）暗号素材を保存するハードウェア／ソフトウェアの信頼のルートを持つデバイス、ｂ）デバイス上の暗号素材と同じまたは同等の認証サービス（ＲｏＴ認証サービス）、ｃ）サービスへのアクセスを許可する前に異なるモードでデバイスを認証するアプリケーションサービス、を含む。認証サービスは、暗号素材を追加の属性セットに関連付ける。これらの属性には、セッションキー、シーケンス、信頼のハードウェアルートで実行可能なセキュリティで保護されたプログラム、派生キー、データとしてエンコードされたリモート関数呼び出し、およびその他のデータが含まれる。さらなる実施形態では、デバイスは、サービスにアクセスしたいアプリケーションサービスに接続し、アプリケーションサービスはデバイスをリダイレクトして、事前に交渉されたポリシーの下で認証サービスに対して認証する。さらなる実施形態では、認証サービスはセキュアなプロトコルを使用してデバイスを認証し、デバイスがポリシー属性を満たしていることを確認し、デバイスと認証サービスは同じことを証明するために信頼のルートを使用して属性を更新し、認証サービスはセキュアに戻る潜在的に複数のトークンを使用して、デバイスにアイデンティティをバインドしたり、情報にアクセスしたりする。属性情報は、トークンに直接エンコードするか、トークンを不透明な識別子として機能させて、アプリケーションサービスが後で属性を取得できるようにすることができる。アプリケーションサービスは、トークンがｉ）まだ有効であること（例えば、トークンに時間制限があるか、認証サービスでチェックバックが必要な場合がある）、ｉｉ）要求されたポリシー識別子の下で発行されたこと、ｉｉｉ）そのアプリケーションサービスに対してのみ有効であること、をチェックできる。アプリケーションサービスは、トークンを使用してデバイスのアイデンティティを確立し、要求されたサービスを提供するために必要な属性にアクセスする。アプリケーションサービスと認証サービスは、異なるエンティティによって運用される場合がある。

本明細書では、ＩｏＴ環境内のデバイス間のセキュアな通信を可能にする、ＩｏＴエンドポイントのセキュアなインフラストラクチャへの初期の信頼できる登録のチャレンジに対処するアプローチについて記載する。以下に記載するのは、ＩｏＴ設定でのデバイスクレデンシャルの初期確立が提案されていることに対処するアプローチの様々な実施形態である。この設計の実施形態は、ＳｏＣ製造などのライフサイクルの初期段階でのデバイスへのセキュリティクレデンシャルのプロビジョニングと、ＰＫＩ（公開キーインフラストラクチャ）などのセキュリティインフラストラクチャにデバイスをセキュアに登録するためのこれらのデバイスのその後の活用に基づいている。インフラストラクチャには、認証サービスおよび委任認証スキームが含まれており、特に、デバイスのライフサイクルの様々な段階で様々な関係者に属する新しいクレデンシャルを確立できる。さらに、提案された設計は、エンドポイントの種類に関係なくセキュアなクレデンシャルの確立を統一することを目的としているため、ＩｏＴデバイス間の大きな多様性のチャレンジに対処している。

図４〜１５は、ＩｏＴデバイスおよびＩＤＭシステム（ＩｏＴインフラストラクチャとも呼ばれる）のデバイスとの相互作用のシーケンスを示すフロー図であり、認証、アイデンティティ、および証明の３つの使用例が含まれる。認証の使用例では、プロビジョニングサービスは認証サービスの助けを借りてデバイスの信頼性を検証できる。アイデンティティの使用例では、認証サービスはプロビジョニングサービスに一意のデバイスエイリアスを提供するか、デバイス自体が提供するエイリアスが他のデバイスによって複製されていないことを確認する。３つの使用例はすべて、図９に記載されている同じベースフローを使用できる。

図４は、一実施形態による、ＩｏＴデバイス１１０、ＲｏＴ認証サービス１０４、デバイスプロビジョニングサービス１０６、およびＩｏＴアプリケーションサービス１０８間の相互作用のシーケンス９００を示すフロー図である。デバイス間の相互作用をもたらす動作は、ハードウェア（例えば、回路、専用ロジック、プログラマブルロジック、マイクロコードなど）、ソフトウェア、ファームウェア、またはそれらの組み合わせを含むことができる処理ロジックによって実行され得る。シーケンス９００は、ＩｏＴデバイス１１０からデバイスプロビジョニングサービス１０６のフロントエンドプロビジョニングポリシーサーバ１１６への初期要求９０１で開始することができる。フロントエンドプロビジョニングポリシーサーバー１１６は、初期要求９０１に応答してＩｏＴデバイス１１０にリダイレクト応答を送り返すことにより、ＩｏＴデバイス１１０を認証ポリシーサーバ１１２にリダイレクトすることができる。ＩｏＴデバイス１１０は、リダイレクトに続いて、ＲｏＴ認証サービス１０４の認証ポリシーサーバ１１２に認証要求９０３を送信することができる。認証ポリシーサーバ１１２は、認証要求９０３をＲｏＴアイデンティティサーバ１１４に送信し、それに応じてアイデンティティトークンおよび任意選択のアクセストークンデータを受信する。認証ポリシーサーバ１１２は、アイデンティティトークン９０５および任意選択のアクセストークンデータをＩｏＴデバイス１１０に送り返す。ＩｏＴデバイス１１０は、アイデンティティトークン９０７（および任意選択のアクセストークンデータ）をフロントエンドプロビジョニングポリシーサーバ１１６に送信する。ブロック９０９で、フロントエンドプロビジョニングポリシーサーバ１１６は、プロビジョニングサーバ１１８にプロビジョニング要求を送信する前にアイデンティティトークン９０７をチェックする。

本明細書で記載するプロトコルは、ＯｐｅｎＩＤ接続（ＯＩＤＣ）プロトコルといくつかの類似点があるが、いくつかの点で異なることに留意されたい。例えば、使用されるプロトコルでは、アイデンティティトークンはＩｏＴデバイスに使用され、ユーザーにもユーザーエージェントにも使用されない。それに基づいて、デバイスはデバイスプロビジョニングサービス１０６へのアクセスを試み、デバイスプロビジョニングサービス１０６は、デバイスを認証するために別のサービス（ＲｏＴ アイデンティティサーバ１１４）を使用する。また、システム内の任意の場所の保持ステータスを除去する（または、不可能な場合は少なくとも最小化する）ようにも設計されている。特に、このプロトコルは両方向のノンスの交換を減らし、複数のデバイスからのメッセージの処理を簡素化する。ノンスはまだあるが、クライアントを介してサーバからサーバに送信される。特に、ノンスは、プロビジョニングポリシーサーバ１１６からＩｏＴデバイス１１０に共有される。交換ごとにリプレイ保護を実行する場合、さらにいくつかのノンスが必要になる。ＩｏＴデバイスとバックエンドサーバー間のセキュアなトランスポートに依存することにより、通常はノンスの使用によって通常提供されるセキュリティ機能、つまりリプレイ保護が提供される。具体的には、このトランスポートはサーバ認証のＴＬＳプロトコルである必要がある。識別（および認証）後、ＩｏＴデバイス１１０は、本明細書で記載されるように、ＴＬＳ／ＤＴＳＬ（ＭＱＴＴ、ＨＴＴＰなど）などの接続を介してデータ９１１をＩｏＴアプリケーションサービス１０８と通信することができる。

図５は、認証の使用事例とデバイスへのドメイン固有のアイデンティティの発行とを組み合わせた交換においてエンティティ間で交換されるメッセージを記載する。

図５は、一実施形態による、ＩｏＴデバイス１１０、ＲｏＴ認証サービス１０４、デバイスプロビジョニングサービス１０６、および認証およびアイデンティティサービスのためのＩｏＴアプリケーションサービス１０８の間で交換されるメッセージのシーケンス１０００を示すフロー図である。シーケンス１０００は、プロビジョニングポリシーサーバ１１６が、ＩｏＴデバイス１１０（図示せず）からの最初の要求に応答してＩｏＴデバイス１１０にリダイレクト応答１００１を送信することで開始することができる。リダイレクト応答１００１は、ノンス、タイムスタンプ（または他の時間情報、および事前共有キー（ＰＳＫ）およびノンス／時間を含むメッセージ認証コード（ＨＭＡＣまたはｈｍａｃ）のハッシュを含むことができる。ＰＳＫは、プロビジョニングポリシーサーバ１１６と認証ポリシーサーバ１１２との間で共有することができる。ノンスは、プロビジョニングポリシーサーバ１１６によって選択されたランダムな値であり得る。

リダイレクト応答１００１に応答して、ＩｏＴデバイス１１０は、認証ポリシーサーバ１１２に送信する認証要求１００３を生成する。認証要求１００３は、不変の信頼のルートＩＤであるＲｏＴ識別子（ｒｏｔＩＤ）、チェックサム、ノンス、タイムスタンプ、およびＨＭＡＣを含むことができる。チェックサム（ｃｈｋｓｕｍ）は、派生ルートキー（ｒｏｔＫｅｙ）、ｒｏｔＩＤ、ノンス、およびタイムスタンプで計算されたチェックサムである。ｒｏｔＫｅｙは、キーツリーを使用して派生する。キーツリーには、ベースキーおよびパスがある。パスは、ベースキーがｒｏｔＫｅｙに変換される方法を定義する。チェックサムは、ＩｏＴデバイス１１０のＣＭコアからのｈａｓｈ１プリミティブおよびｈａｓｈ２プリミティブを使用して計算できる。同様に、ＭＡＣはｈａｓｈ１プリミティブとｈａｓｈ２プリミティブの組み合わせにすることができる。より一般的には、キー付きＭＡＣ（ＨＭＡＣ）は同様の操作を実行できる。その考え方は、バックエンドと実際の一意のコア（ＲｏＴ）キーを共有するのではなく、バックエンドがコアと対話するたびにソリューション固有のキーを導出できるということである。この派生は、一意のコアキーを定数でハッシュすることによって行われる。

一実施形態では、認証要求１００３は、以下のＨＴＴＰリダイレクトである。
ＰＯＳＴ／ＰｒｏｖｉｓｉｏｎＭｅ？ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＝ｃｏｄｅ＆ｓｃｏｐｅ＝ａｕｔｈｎ
ＨＴＴＰ／１．１
Ｈｏｓｔ：ｐｒｏｖｉｓｉｏｎｅｒ．ｉｏｔＰｒｏｖｉｄｅｒ．ｃｏｍ
Ａｃｃｅｐｔ：ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ
｛“ＤｅｖｉｃｅＤａｔａ”：“ＡＡＥＣ．．．ＡｗＱＦＢｇｃ＝”｝

認証ポリシーサーバ１１２は、認証要求１００３を受信し、認証要求１００５としてＲｏＴアイデンティティサーバ１１４に認証要求１００３を送信する。ＲｏＴアイデンティティサーバ１１４は、認証応答１００７で応答し、認証応答１００７は、ノンス、タイムスタンプ、およびＨＭＡＣを含む。認証ポリシーサーバ１１２は、認証応答１００７を受信する。認証応答１００７が認証要求１００５を検証すると仮定すると、認証ポリシーサーバ１１２は、アイデンティティトークン（ｉｄＴｏｋｅｎ）１００９をＩｏＴデバイス１１０に提供する。ｉｄＴｏｋｅｎは、クレームと同様に、ノンス、タイムスタンプ、およびＨＭＡＣを含め得る。立証データ（ａｔｔＤａｔａ）には、その属性を説明するデバイスからのデータが含まれている場合があり、そのデータは、デバイス内の信頼のルートによって検証される。一方、クレームはデバイスの属性であり、バックエンド（ＲｏＴ認証サーバ）によって提供および証明される。通常、クレームにはａｔｔＤａｔａが含まれるが、過去１時間にこのデバイスがバックエンドによって認証された回数など、他の情報が含まれることもある。ノンス、タイムスタンプ、ＨＭＡＣ、およびクレームはデジタル署名されている場合がある。ＩｏＴデバイス１１０は、アイデンティティトークン１００９をアイデンティティトークン１０１１としてプロビジョニングポリシーサーバ１１６に提出する。一実施形態では、以下はアイデンティティトークンの実施例である。
｛
“ｉｓｓ”：ｈｔｔｐｓ：／／ａｕｔｈｎ．ｒａｍｂｕｓ．ｃｏｍ，
“ｓｕｂ”：“ａｌｉａｓ１２３４”，
“ａｕｄ”：ｉｏｔＰｒｏｖｉｄｅｒ１”，
“ｅｘｐ”：１３１１２８１９７０，
“ｉａｔ”：１３１１２８０９７０，
“ａｕｔｈ＿ｔｉｍｅ”：１３１１２８０９６９，
“ａｍｒ”：“ｕｍ：ｒａｍｂｕｓｃｍｖ１”，
“ｎｏｎｃｅ”：“ＡＷＦＱ ．．．Ｇｗｃｇ＝”，
“ｒｅｑ＿ｔｉｍｅ”：１３１１２８０８０２，
“ｍａｃ”：“ＡＡＢｃ ．．． ＣＱＥｆｃｇ＝”｝

プロビジョニングポリシーサーバ１１６は、ブロック１０１３でアイデンティティトークン１０１１を検証する。アイデンティティトークン１０１１を検証するために、プロビジョニングポリシーサーバ１１６は、相互認証されたセキュアなチャネル１０１５を介してプロビジョニングサーバ１１８と通信することができる。同様に、認証ポリシーサーバ１１２およびＲｏＴアイデンティティサーバ１１４は、相互に認証されたセキュアなチャネル１０１７で通信できる。ＩｏＴデバイス１１０および認証ポリシーサーバ１１２は、一方向認証されたセキュアなチャネル１０１９を介して通信し、ＩｏＴデバイスおよびプロビジョニングポリシーサーバ１１６は、一方向認証されたセキュアなチャネル１０２１を介して通信する。プロビジョニングポリシーサーバ１１６は、相互認証されたセキュアなチャネル１０２３を介して認証ポリシーサーバ１１２と通信することができる。

図５は、ＣＭコアで実行されるシーケンスおよびバックエンドで実行されるモジュールに関する、認証フローおよびキャプチャ詳細に集中するための、バックエンドでのモジュールの展開、デバイスでのシーケンス、バックエンドコンポーネント間の信頼確立など、いくつかの予備操作を示していないことに留意されたい。さらに、１つのＩｏＴデバイス１１０が図示および記載されているが、この単一のインフラストラクチャによってサービスされる複数のＩｏＴデバイスがあることに留意されたい。

図５に関して、この単純な構成は、トランスポート層（ＴＬＳ）のセキュアなチャネルに依存して、リプレイ攻撃および中間者攻撃から保護し、不変ＩＤ（ｒｏｔＩＤ）の機密性に依存している。デバイス上のアプリケーションにはシーケンスが含まれる場合があるが、バックエンドはこの単純な構成で単一のモジュールを使用する。ＩｏＴデバイス１１０内のＣＭコアへのチャレンジとして、デバイスプロビジョニングサービス１０６によって追加のシーケンスが使用され、応答が生成されてもよい。ＩｏＴデバイスとサービス間のＴＬＳチャネルのセキュリティプロパティに依存しないセキュアな構成を以下に記載する。

いくつかの実施形態では、この限られたセキュリティの観点から高レベルで、アプリケーションがプロビジョニングサービス１０６（例えば、１００１）にアクセスしようとすると、アプリケーションは認証要求を必要とする対話を開始する（１００３）。プロビジョニングポリシーサーバ１１６は、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔサーバ（ＯＩＤＣサーバ）であり得る認証ポリシーサーバ１１２へのリダイレクトで応答し、図５に示すように、事前共有キーを使用した、ノンス、時間、ノンスと時間のＨＭＡＣなどのいくつかの追加データを送信する。その後、ＩｏＴデバイス１１０は、ＲｏＴおよびＲｏＴ内部計算の助けを借りて要求を生成する。例えば、ＩｏＴデバイス１１０は、動作を実行するためにＣＭコアによって実行されるコマンドのセットである静的シーケンスを使用して、ＣＭコアの助けを借りて要求を提供することができる。シーケンスの実行後、プロビジョニングポリシーサーバ１１６（ノンス、時間、およびＨＭＡＣ）から受信したデータに加えて、ｒｏｔＩＤ（ＣＭコアの識別子）とチェックサムを含む出力がＣＭ コアによって生成されたアプリケーションによってＯＩＤＣサーバ（例えば、１１２）に転送される。これらのデータ項目は、認証ポリシーサーバ１１２によってＲｏＴアイデンティティサーバ１１４にさらに転送され、そこでＨＳＭモジュールが実行される。実行する前に、時間およびＨＭＡＣが検証される。次に、ｒｏｔＩＤを使用して、派生ｒｏｔＫｅｙ（特定のｒｏｔＩＤを持つデバイスに対応するコアとインフラストラクチャ間で共有されるキー）を検索する。派生ｒｏｔＫｅｙのこの値は、チェックサムを検証するためにモジュールによって使用される。それが完了すると、ＲｏＴアイデンティティサーバ１１４は認証ポリシーサーバ１１２に認証応答１００７を返し、認証ポリシーサーバ１１２は認証パラメーターを記述するトークンを返す。このトークンは、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔプロトコルで指定されているｉｄＴｏｋｅｎであり、特にデバイスのアイデンティティ（そのエイリアス）が含まれている。このトークンは、トークン付きＪＳＯＮ（ｊｗｔ）としてフォーマットされ、プロビジョニングポリシーサーバ１１６によって検証される認証ポリシーサーバ１１２（ＡｕｔｈＮ＆ＡｕｔｈＺポリシーサーバ）の非対称キーによって署名できる。

図６は、一実施形態による、図５のシーケンス１０００の関連するコンポーネントのそれぞれに対して実行される様々な動作を示すフロー図である。ブロック１１０１でプロビジョニングポリシーサーバ１１６は、ノンスを生成し、タイムスタンプを記録し、ＰＳＫを使用してＨＭＡＣを作成し、初期応答（リダイレクト応答）を送信する。ブロック１１０３でＩｏＴデバイス１１０のアプリケーションは、ノンスおよびタイムスタンプをＣＭコアのバッファに送信し、シーケンスを実行してチェックサム結果を取得する。アプリケーションは、ブロック１１０３で、認証ポリシーサーバ１１２を介してＲｏＴアイデンティティサーバ１１４に認証要求を作成して送信する。ブロック１１０５で、ＲｏＴ識別サーバ１１４は、ＨＭＡＣを検証し、ｒｏｔＩＤを使用して導出されたｒｏｔＫｅｙをルックアップし、認証要求のチェックサムを検証する。ＲｏＴ識別サーバ１１４はまた、認証応答を作成し、署名し、認証ポリシーサーバ１１２に送り返す。ブロック１１０７で、認証ポリシーサーバ１１２は認証要求を検証する。検証時に、認証ポリシーサーバ１１２は、アイデンティティトークンを作成し、署名し、ＩｏＴデバイス１１０のアプリケーションに送信する。ＩｏＴデバイス１１０でのアプリケーションは、アイデンティティトークンをプロビジョニングポリシーサーバ１１６に送り返し、ブロック１１０９で、アイデンティティトークンの署名を検証し、それ自体のポリシーに対して時間をチェックする。プロビジョニングポリシーサーバ１１６は、プロビジョニング操作も実行する。

上記のフローでは、どのエンティティもステートを保持せず、要求または応答オブジェクトに完全にカプセル化されているため、セッション識別子（セッションＩＤ）の明示的な識別子は必要ないことに留意されたい。要求／応答オブジェクト自体は、ＵＲＬエンコードされた文字列またはＪＳＯＮオブジェクトで表される場合があることにも留意されたい。

別の実施形態では、デバイスの認証に加えて、ＲｏＴアイデンティティサーバ１１４は、特定のＩｏＴアプリケーションのコンテキスト内でのみ有効なデバイスに一意のアイデンティティを提供することができる。これは、デバイスが複数のサービスで同じＩＤを使用できないようにすることにより、デバイス／ユーザーのプライバシーを保護しながら、デバイスを追跡する必要がある場合に役立つ。さらに、プロトコルは不変のＩＤを漏らしてはならない。これらのＩＤは通常、ＲｏＴ認証サービス１０４によって返されるＩＤトークンの「サブ」フィールドで提供される。代わりに、別の実施形態では、プライバシー保護構成では、この特定のアプリケーションのデバイスを表すエイリアスがＩＤトークンの「サブ」フィールドで使用される。

図５〜６は、論理的またはセキュリティの観点からコンポーネント間の相互作用を示し記載しているが、これらのメッセージはＨＴＴＰまたは同様のメカニズムを使用して交換できる。以下の図は、上記の交換をＨＴＴＰメソッドにマップしている。これらは、デバイスの観点から何が起こるかのみを記載し、デバイスに関係しない交換は含まない。また、プロビジョニングポリシーサーバ１１６と認証ポリシーサーバ１１２との間の交換のメカニズムは、展開前に事前共有キーを交換することを含む、様々なタイプのメカニズムであってもよい。

図７は、一実施形態による、ＩｏＴデバイス１１０、ＲｏＴ認証サービス１０４、デバイスプロビジョニングサービス１０６、およびＩｏＴアプリケーションサービス１０８の間で交換されるＨＴＴＰメッセージのシーケンス１２００を示すフロー図である。シーケンス１２００について、ＩｏＴデバイス１１０は最初に要求１２０１をプロビジョニングポリシーサーバ１１６に送信する。要求１２０１は、デバイスデータを含み得る。プロビジョニングポリシーサーバ１１６は、第１のリダイレクト１２０３（リダイレクト１）をＩｏＴデバイス１１０に送り返す。第１のリダイレクト１２０３は、プロビジョニングデータを含む。プロビジョニングデータは、ノンス、タイムスタンプ、ＨＭＡＣ（ノンス｜時間）などのプロビジョニングトランザクションを支援するためにプロビジョニングポリシーサーバ１１６によって生成された値であってもよい。第１のリダイレクト１２０３に続いて、ＩｏＴデバイス１１０は、認証要求１２０５（リダイレクト１に続く）を認証ポリシーサーバ１１２に送信する。認証要求１２０５には、プロビジョニングデータ、立証データ、および承認データが含まれる。立証データは、アプリケーションによってＩｏＴデバイス１１０の暗号化コア（例えば、ＣＭコア）に転送される値であり、暗号化コアによって署名（ＭＡＣ化）する必要がある。立証データは、公開キーまたは証明書署名要求（ＣＳＲ）によって署名される場合がある。認証データは署名またはチェックサムであり、認証サービス１０４が要求デバイスを認証し、着信データを検証できるようにする。認証ポリシーサーバ１１２は、第２のリダイレクト１２０７（リダイレクト１）をＩｏＴデバイス１１０に送り返す。第２のリダイレクト１２０７は、トークンと立証データを含む。第２のリダイレクト１２０７に続いて、ＩｏＴデバイス１１０は、要求１２０９（リダイレクト２に続く）をプロビジョニングポリシーサーバ１１６に送信する。要求１２０９には、トークンおよび立証データが含まれている。プロビジョニングポリシーサーバ１１６は、トークンおよび立証データをチェックする。プロビジョニングポリシーサーバ１１６は、プロビジョニングされたデータ（例えば、デバイスのアプリケーション証明書および他のアプリケーション関連データ）を含むＨＴＴＰ応答１２１３をＩｏＴデバイス１１０に送り返す。デバイスプロビジョニングサービス１０６およびＲｏＴ認証サービス１０４によって認証および承認されると、ＩｏＴデバイスは、ＴＬＳ／ＤＴＬＳ（ＭＱＴＴ、ＨＴＴＰなど）を介したセキュアな接続の使用など、ＩｏＴアプリケーションサービス１０８と通信することができる。

以下の実施例は、図７に関して上記で記載したＨＴＴＰトランザクションである。
１．要求 １２０１：
ＰＯＳＴ／ｐｒｏｖｉｓｉｏｎＭｅ？ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＝ｃｏｄｅ＆ｓｃｏｐｅ＝ａｕｔｈｎ
ＨＴＴＰ／１．１
Ｈｏｓｔ：ｐｒｏｖｉｓｉｏｎｅｒ．ｉｏｔＰｒｏｖｉｄｅｒ．ｃｏｍ
Ａｃｃｅｐｔ：ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ
｛“ＤｅｖｉｃｅＤａｔａ”：“ＡＡＥＣ．．．ＡｗＱＦＢｇｃ＝”｝

２．リダイレクト１ １２０３：
ＨＴＴＰ／１．０ ３０２ Ｆｏｕｎｄ
Ｌｏｃａｔｉｏｎ：ｈｔｔｐｓ：／／ｏｉｄｃｓｅｒｓｚｅｒ．ｃｏｍ／ｐｒｏｖｉｓｉｏｎＭｅ／
｛“ＡｕｔｈＣｈａｉｎ”：“ＡＱＦＡ．．．ＥＡｗＣＢｃｇ＝”，
“ｎｏｎｃｅ”：“ＢＣＸＦ．．ＢＣＥｗＵｘｎ＝”，
“ｒｅｑＴｉｍｅ”：１３１１２８０９６９，
“ｈｍａｃ”：“ＡＦＢＣ．．ＡＡＥｗＯｎｂ＝”｝

３．リダイレクト１に続く １２０５：
ＰＯＳＴ／ｐｒｏｖｉｓｉｏｎＭｅ？ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ＝ｃｏｄｅ＆ｓｃｏｐｅ＝ａｕｔｈｎ ＨＴＴＰ／１．１
Ｈｏｓｔ：ｏｉｄｃｓｅｒｖｅｒ．ｃｏｍ
Ａｃｃｅｐｔ：ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ
｛“ＡｔｔｅｓｔａｔｉｏｎＤａｔａ”：“ＡＡＡｗ．．．ＥＣＱＦＢｃｇ＝”，
“ＡｕｔｈＤａｔａ”：“ＡＡＥＣ．．ＡｗＱＦＢｇｃ＝”，
“ｎｏｎｃｅ”：“ＢＣＸＦ．．ＢＣＥｗＵｘｎ＝”，
“ｒｅｑＴｉｍｅ”：１３１１２８０９６９，
“ｈｍａｃ”：“ＡＦＢＣ．．ＡＡＥｗＱｎｂ＝”｝

４．リダイレクト２ １２０７：
ＨＴＴＰ／１．０ ３０２ Ｆｏｕｎｄ
Ｌｏｃａｔｉｏｎ：ｈｔｔｐｓ：／／ｐｒｏｖｉｓｉｏｎｅｒ．ｉｏｔＰｒｏｖｉｄｅｒ．ｃｏｍ／ｐｒｏｖｉｓｉｏｎＭｅ／ｔｏｋｅｎ／（ｔｏｋｅｎＩＤ＞
＜Ｔｏｋｅｎ＞（以下に例）

５．リダイレクト２に続く １２０９：
ＰＯＳＴ／ｐｒｏｖｉｓｉｏｎＭｅ／ｔｏｋｅｎ／（ｔｏｋｅｎＩＤ＞ＨＴＴＰ／１．１
Ｈｏｓｔ：ｐｒｏｖｉｓｉｏｎｅｒ．ｉｏｔＰｒｏｖｉｄｅｒ．ｃｏｍ
Ａｃｃｅｐｔ：ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ
｛“ＡｔｔｅｓｔａｔｉｏｎＤａｔａ”：“ＡＡＡｗ．．．ＥＣＱＦＢｃｇ＝”｝

６．ＨＴＴＰレスポンス １２１３：
ＨＴＴＰ／１．０ ２００ ＯＫ
Ｃｏｎｔｅｎｔ−Ｔｙｐｅ：ａｐｐｌｉｃａｔｉｏｎ／ｊｓｏｎ
Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈ：ｘｘｘｘ
｛“Ｄａｔａ：“ＡｗＱＦ．．．ＡＡＥＣＢｇｃ＝”｝

上記で記載したように、第２のリダイレクト１２０７は、１つ以上のトークンを含む。トークンはアイデンティティトークンでも、トークンはアイデンティティトークンとアクセストークンでもよい。モジュールの出力、および結果のデータをアイデンティティトークン（ｉｄＴｏｋｅｎ）および任意選択でアクセストークンに変換する方法に関して、いくつかの代替案がある。まず、出力は使用例に依存する。以下は、２つの使用例での２つの実施例の出力である。第１の実施例は、デバイスの認証のみが必要な場合である。第２の実施例は、立証データが含まれる。暗号化コアは、証明書署名要求を立証データとして提供できる。出力は認証の成功または失敗に依存することに留意されたい。成功した認証がＲｏＴアイデンティティサーバ１１４によって完了した場合、以下の実施例１に示す形式などでアイデンティティトークンが発行される。認証に失敗した場合、エラーメッセージを送り返すことができる。あるいは、別のアプローチでは、デバイスまたはＲｏＴアイデンティティサーバ１１４の外部のデバイスにエラーメッセージが返されない。エラーメッセージを送り返すことはシステムのロードに役立つが、エラーメッセージを送り返さないことはセキュリティに役立ち、攻撃者は失敗した認証試行について簡単に知ることができない。

実施例１−認証のみの使用例：第２のリダイレクト１２０７に含まれるモジュール応答（モジュールによって返され、ＲｏＴアイデンティティサーバ１１４から認証ポリシーサーバ１１２に送信される）。
｛“ＩｄｅｎｔｉｔｙＴｏｋｅｎ”：
｛
“ｓｕｂ”：“ａｌｉａｓ１２３４”， ／＊ デバイスのｒｏｔＩＤに基づいて選択されたエイリアス ＊／
“ａｕｔｈ＿ｔｉｍｅ”：１３１１２８０９６９， ／＊ 認証の時間 ＊／
“ｎｏｎｃｅ”：“ＡＷＦＱ．．．Ｇｗｃｇ＝”， ／＊ 要求からコピー ＊／
“ｒｅｑ＿ｔｉｍｅ”：１３１１２８０８０２， ／＊ 要求からコピー ＊／
“ｈｍａｃ”：“ＡＡＢｃ．．．ＣＱＥｆｃｇ＝” ／＊ 要求からコピー ＊／
｝
｝
トークンの内容（ＡｕｔｈＮおよびＡｕｔｈＺポリシーサーバによって作成）：
｛“ＩｄｅｎｔｉｔｙＴｏｋｅｎ”：
｛
“ｉｓｓ”：“ｈｔｔｐｓ：／／ａｕｔｈｎ．ａｂｃ．ｃｏｍ”，／＊ 発行者−特定のサーバの静的な値 ＊／
“ｓｕｂ”：“ａｌｉａｓ１２３４”， ／＊ 別名−モジュールによって与えられる ＊／
“ａｕｄ”：“ｉｏｔＰｒｏｖｉｄｅｒ１”， ／＊ オーディエンス−ソリューションの静的な価値 ＊／
“ｅｘｐ”：１３１１２８１９７０， ／＊ 以下のポリシーと認証時間（ｉａｔ）に基づいて計算 ＊／
“ｉａｔ”：１３１１２８０９７０， ／＊ トークンの発行時間 ＊／
“ａｕｔｈ＿ｔｉｍｅ”：１３１１２８０９６９， ／＊ 認証の時間−モジュールによって与えられる ＊／
“ａｍｒ”：“ｕｒｎ：ａｂｃ：ｃｍｖ１”， ／＊ 認証方法の参照−認証方法に基づく静的な値 ＊／
“ｎｏｎｃｅ”：“ＡＷＦＱ．．．Ｇｗｃｇ＝”， ／＊ 要求からコピー ＊／
“ｒｅｑ＿ｔｉｍｅ”：１３１１２８０８０２， ／＊ 要求からコピー ＊／
“ｈｍａｃ”：“ＡＡＢｃ．．．．ＣＱＥｆｃｇ＝” ／＊ 要求からコピー ＊／
｝
｝
トークン：
ヘッダー：
｛“ａｌｇ”：“ＥＳ２５６”，“ｅｎｃ”：“ｎｏｎｅ”｝．
｛ｔｏｋｅｎ（上からのクレームで）｝．
ｓｉｇｎａｔｕｒｅ
ｅｙＪ０ｅＸＡｉＯｉＪＫＶ１ＱｉＬＡ０ＫＩＣＪｈｂＧｃｉＯｉＪＩＵｚＩ１ＮｉＪ９
．
ｅｙＪｐｃ３ＭｉＯｉＪｑｂ２ＵｉＬＡ０ＫＩＣＪｌｅＨＡｉＯｊＥｚＭＤＡ４ＭＴｋｚＯＤＡｓＤＱｏｇＩｍｈ０ｄＨＡ６Ｌｙ９ｌｅＧＦｔ
ｃＧｘｌＬｍＮｖｂＳ９ｐｃ１９ｙｂ２９０Ｉｊｐ０ｃｎＶｌｆＱ
．
ｄＢｊｆｔＪｅＺ４ＣＶＰ−ｍＢ９２Ｋ２７ｕｈｂＵＪＵ１ｐ１ｒ＿ｗＷ１ｇＦＷＦＯＥｊＸｋ

上記のトークンは、エンコードされたトークンの形式の実施例であるが、現実的なデータは含まれていない。

実施例２−認証および立証データの使用例：第２のリダイレクト１２０７に含まれるモジュール応答（モジュールによって返され、ＲｏＴアイデンティティサーバ１１４から認証ポリシーサーバ１１２に送信される）。
｛“ＩｄｅｎｔｉｔｙＴｏｋｅｎ”：
｛
“ｓｕｂ”：“ａｌｉａｓ１２３４”， ／＊ デバイスのｒｏｔＩＤに基づいて選択されたエイリアス ＊／
“ａｕｔｈ＿ｔｉｍｅ”：１３１１２８０９６９， ／＊ 認証の時間 ＊／
“ｎｏｎｃｅ”：“ＡＷＦＱ．．．Ｇｗｃｇ＝”， ／＊ 要求からコピー ＊／
“ｒｅｑ＿ｔｉｍｅ”：１３１１２８０８０２， ／＊ 要求からコピー ＊／
“ｈｍａｃ”：“ＡＡＢｃ．．．ＣＱＥｆｃｇ＝” ／＊ 要求からコピー ＊／
｝，
“ＡｃｃｅｓｓＴｏｋｅｎ”：
｛
“ａｔｔｅｓｅｔａｔｉｏｎＤａｔａ”：“ＡＱＥｃ．．．．ＣｆＡＢｃｇ＝”， ／＊ ベース６４−エンコードされた立証データ、すなわちＣＳＲ ＊／
｝
｝
トークンの内容（ＡｕｔｈＮおよびＡｕｔｈＺポリシーサーバによって作成）：
｛“ＩｄｅｎｔｉｔｙＴｏｋｅｎ”：
｛
“ｉｓｓ”：“ｈｔｔｐｓ：／／ａｕｔｈｎ．ａｂｃ．ｃｏｍ”，／＊ 発行者−特定のサーバの静的な値 ＊／
“ｓｕｂ”：“ａｌｉａｓ１２３４”， ／＊ 別名−モジュールによって与えられる ＊／
“ａｕｄ”：“ｉｏｔＰｒｏｖｉｄｅｒ１”， ／＊ オーディエンス−ソリューションの静的な価値 ＊／
“ｅｘｐ”：１３１１２８１９７０， ／＊ 以下のポリシーと認証時間（ｉａｔ）に基づいて計算 ＊／
“ｉａｔ”：１３１１２８０９７０， ／＊ トークンの発行時間 ＊／
“ａｕｔｈ＿ｔｉｍｅ”：１３１１２８０９６９， ／＊ 認証の時間−モジュールによって与えられる ＊／
“ａｍｒ”：“ｕｒｎ：ａｂｃ：ｃｍｖ１”， ／＊ 認証方法の参照−認証方法に基づく静的な値 ＊／
“ｎｏｎｃｅ”：“ＡＷＦＱ．．．Ｇｗｃｇ＝”， ／＊ 要求からコピー ＊／
“ｒｅｑ＿ｔｉｍｅ”：１３１１２８０８０２， ／＊ 要求からコピー ＊／
“ｈｍａｃ”：“ＡＡＢｃ．．．．ＣＱＥｆｃｇ＝” ／＊ 要求からコピー ＊／
｝，
“ＡｃｃｅｓｓＴｏｋｅｎ”：
｛
“ａｔｔｅｓｅｔａｔｉｏｎＤａｔａ”：“ＡＱＥｃ．．．．ＣｆＡＢｃｇ＝”， ／＊ ベース６４−エンコードされた立証データ、すなわちＣＳＲ ＊／
｝
｝
トークン：
ヘッダー：
｛“ａｌｇ”：“ＥＳ２５６”，“ｅｎｃ”：“ｎｏｎｅ”｝．
｛ｔｏｋｅｎ（上からのクレームで）｝．
ｓｉｇｎａｔｕｒｅ
ｅｙＪ０ｅＸＡｉＯｉＪＫＶ１ＱｉＬＡ０ＫＩＣＪｈｂＧｃｉＯｉＪＩＵｚＩ１ＮｉＪ９
．
ｅｙＪｐｃ３ＭｉＯｉＪｑｂ２ＵｉＬＡ０ＫＩＣＪｌｅＨＡｉＯｊＥｚＭＤＡ４ＭＴｋｚＯＤＡｓＤＱｏｇＩｍｈ０ｄＨＡ６Ｌｙ９ｌｅＧＦｔ
ｃＧｘｌＬｍＮｖｂＳ９ｐｃ１９ｙｂ２９０Ｉｊｐ０ｃｎＶｌｆＱ
．
ｄＢｊｆｔＪｅＺ４ＣＶＰ−ｍＢ９２Ｋ２７ｕｈｂＵＪＵ１ｐ１ｒ＿ｗＷ１ｇＦＷＦＯＥｊＸｋ

上記のトークンは、エンコードされたトークンの形式の実施例であるが、現実的なデータは含まれていない。

認証および識別サービスは有用であるが、他の実施形態では、インフラストラクチャはデータ立証機能も提供できる。この機能を使用すると、アプリケーションは、暗号化コアによって署名された公開キー（または証明書署名要求）をバックエンドで検証し、プロビジョニングポリシーサーバ１１６で検証することができる。この検証は、デバイスで実行されているアプリケーションに証明書を発行するためのポリシーとして使用できる。暗号コアは、与えられたデータにブラインド署名する場合があるが、このデータの署名は、図８のフローとシーケンスの詳細で示すように、証明書の発行の検証層を提供するのに依然として有用であることに留意されたい。

図８は、一実施形態による、ＩｏＴデバイス１１０、ＲｏＴ認証サービス１０４、デバイスプロビジョニングサービス１０６、および認証、アイデンティティ、ならびにデータ立証サービスのためのＩｏＴアプリケーションサービス１０８間の相互作用のシーケンス１３００を示すフロー図である。シーケンス１３００は、プロビジョニングポリシーサーバ１１６が、ＩｏＴデバイス１１０からの最初の要求に応答してリダイレクト応答１３０１をＩｏＴデバイス１１０に送信することで開始することができる（図示せず）。リダイレクト応答１３０１は、ノンス、タイムスタンプ（または他の時間情報、およびＨＭＡＣ（ＰＳＫ、ノンス｜時間）を含み得る。上記で記載したように、ＰＳＫは、プロビジョニングポリシーサーバ１１６と認証ポリシーサーバ１１２との間の事前共有キーとすることができる。ノンスは、プロビジョニングポリシーサーバ１１６によって選択されたランダムな値であり得る。

リダイレクト応答１３０１に応答して、ＩｏＴデバイス１１０は、認証ポリシーサーバ１１２に送信する認証要求１３０３を生成する。認証要求１３０３は、ｒｏｔＩＤ、チェックサム、ノンス、タイムスタンプ、ＨＭＡＣ、および立証データ（ａｔｔＤａｔａとラベル付けされた）を含むことができる。チェックサム（ｃｈｋｓｕｍ）は、導出されたＰＡＤＡＫ、ｒｏｔＩＤ、およびデバイスデータ（Ｐｕｂ）で計算できる。ＰＡＤＡＫは、他のキーを派生できるベース（またはルート）キーである。ＰＡＤＡＫは、シリコンの製造中にプログラムできるが、最終顧客（例えば、ＯＥＭ）が知られる前である。これらのデバイスは様々なＯＥＭに配布できるため、デバイスとＯＥＭに固有のＰＡＤＡＫに基づいて新しいキーが導出される。チェックサムを使用して、デバイスを認証し、デバイスデータ（Ｐｕｂ）を検証できる。Ｐｕｂは、公開キーへの参照であり、公開キーは、通常、証明書署名要求の基礎となる立証データまたはデバイスデータの一部である。立証データは、アプリケーションによって暗号化コア（例えば、ＣＭコア）に提供される追加データである。暗号化コアは、このデータを認証ポリシーサーバ１１２に送信する前に暗号化して署名する。この立証データは検証され、アクセストークンの一部としてパッケージ化される。そのようなデータの実施例は、プロビジョニングサーバ１１８による証明書発行の基盤として使用できるアプリケーションの公開キーである。一実装形態では、ＩｏＴデバイス１１０によって証明されるデータは、ＩｏＴアプリケーションとのセキュアなトランザクションに使用されるその公開キーである。ＩｏＴデバイス１１０によって証明される公開キーは、証明書を作成するために使用される。その証明書は、ＩｏＴアプリケーションとの相互認証されたトランスポート層セキュリティ（ＴＬＳ）セッション中に使用される。データ１３１７（例えば、ｃｅｒｔ）にはこの公開キーが含まれている。ＲｏＴ ｃｈｋｓｕｍ計算でＴＬＳ公開キーを使用すると、このＩｏＴデバイス１１０とこのデバイスのみがこの公開キーとそれに関連する秘密キーを持っているという証拠が得られる。

認証ポリシーサーバ１１２は、立証データを伴う認証要求１３０３を受信し、認証要求１３０５としてＲｏＴアイデンティティサーバ１１４に認証要求１３０３を送信する。認証要求１３０５は、立証データも含む。ＲｏＴ識別サーバ１１４は、ノンス、タイムスタンプ、ＨＭＡＣ、および立証データを含む認証応答１３０７で応答する。認証ポリシーサーバ１１２は、認証応答１３０７を受信する。認証応答１３０７が認証要求１３０５を検証すると仮定すると、認証ポリシーサーバ１１２は、アイデンティティトークン（ｉｄＴｏｋｅｎ）およびアクセストークン（ａｃｃｅｓｓＴｏｋｅｎ）１３０９をＩｏＴデバイス１１０に提供する。上記のように、アクセストークンは署名された立証データである場合がある。ｉｄＴｏｋｅｎには、ノンス、タイムスタンプ、およびＨＭＡＣが含まれる場合がある。ノンス、タイムスタンプ、およびＨＭＡＣはデジタル署名されている場合がある。ＩｏＴデバイス１１０は、アイデンティティトークンおよびアクセストークン１３０９を、アイデンティティトークンおよびアクセストークン１３１１としてプロビジョニングポリシーサーバ１１６に提出する。

プロビジョニングポリシーサーバ１１６は、ブロック１３１３でアイデンティティトークン１０１１を検証する。アイデンティティトークンを検証するために、プロビジョニングポリシーサーバ１１６は、相互認証されたセキュアなチャネル１０１５を介してプロビジョニングサーバ１１８と通信できる。ブロック１３１５で、プロビジョニングサーバ１１８は、証明書を発行するかどうかを決定する。プロビジョニングサーバ１１８が証明書を発行すると、プロビジョニングポリシーサーバ１１６は、証明書を含むデータ１３１７をＩｏＴデバイス１１０に送り返す。同様に、認証ポリシーサーバ１１２とＲｏＴアイデンティティサーバ１１４は、相互に認証されたセキュアなチャネルで通信できる。ＩｏＴデバイス１１０および認証ポリシーサーバ１１２は、一方向認証されたセキュアなチャネルを介して通信し、ＩｏＴデバイスおよびプロビジョニングポリシーサーバ１１６は、一方向認証されたセキュアなチャネルを介して通信する。

いくつかの実施形態では、この限られたセキュリティの観点から高レベルで、アプリケーションがプロビジョニングサービス１０６（例えば、１３０１）にアクセスしようとすると、アプリケーションは認証要求を必要とする対話を開始する（１３０３）。プロビジョニングポリシーサーバ１１６は、認証ポリシーサーバ１１２へのリダイレクトで応答し、リダイレクトは、図８に示された追加のデータ、例えば、ノンス、時間、およびＨＭＡＣを含む。続いて、ＩｏＴデバイス１１０は、静的シーケンスを使用して、ＣＭコアの助けを借りて要求を生成する。シーケンスの実行後、プロビジョニングポリシーサーバ１１６（ノンス、時間、およびＨＭＡＣ）から受信したデータに加えて、ｒｏｔＩＤ（ＣＭコアの識別子）とチェックサムを含む出力がＣＭ コアによって生成されたアプリケーションによってＯＩＤＣサーバ（例えば、１１２）に転送される。出力には、立証データも含まれる。これらのデータ項目は、認証ポリシーサーバ１１２によってＲｏＴアイデンティティサーバ１１４にさらに転送され、そこでＨＳＭモジュールが実行される。実行する前に、時間およびＨＭＡＣが検証される。次に、ｒｏｔＩＤを使用して、派生ｒｏｔＫｅｙ（特定のｒｏｔＩＤを持つデバイスに対応するコアとインフラストラクチャ間で共有されるキー）を検索する。派生ｒｏｔＫｅｙのこの値は、チェックサムを検証するためにモジュールによって使用される。それが完了すると、ＲｏＴアイデンティティサーバ１１４は認証ポリシーサーバ１１２に認証応答１３０７を返し、認証ポリシーサーバ１１２は認証パラメーターを記述する２つのトークンを返す。１つのトークンは、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔプロトコルで指定されたアイデンティティトークンである場合があり、これには、とりわけデバイスのアイデンティティ（エイリアス）が含まれる。このトークンは、トークン付きＪＳＯＮ（ｊｗｔ）としてフォーマットされ、プロビジョニングポリシーサーバ１１６によって検証される認証ポリシーサーバ１１２（ＡｕｔｈＮ＆ＡｕｔｈＺポリシーサーバ）の非対称キーによって署名できる。他のトークンはアクセストークンである場合があり、アクセストークンには、デバイスプロビジョニングサービス１０６で検証できる署名付き立証データが含まれる。このデータの実施例としては、アプリケーションの公開キーがあり、これは、ブロック１３１５でプロビジョニングサーバ１１８による証明書発行の基盤として使用できる。

上記の様々な実施形態は、デバイス上の信頼のルートが対称キーを使用するＣＭコアであると想定している。しかしながら、インフラストラクチャ内の様々なＩｏＴデバイス（ＩｏＴエンドポイントとも呼ばれる）をＩＤＭでサポートする必要がある。ＣＭコアの実施形態で説明したように、入力検証だけでなく、ｐｕｂＤＢベースのプロビジョニングとＰＫＩベースのプロビジョニングを含む暗号コアのクレデンシャルとして、非対称キーを使用する暗号コアに依存する２つの代替案を以下に記載する。ＰＫＩベースのプロビジョニングでは、パーソナライズの結果はコア証明書である。この代替案は、コアがプロビジョニング公開キーインフラストラクチャ（ＰＫＩ）の一部になるという点で、対称コアの実施形態に似ている。別の代替案であるｐｕｂＤＢベースのプロビジョニングでは、デバイスに非対称キーペアを有するが、証明書は有さない。代わりに、バックエンドには、デバイスの公開キーのデータベースがあり、そのＩＤ（ｒｏｔＩＤ）によってインデックス付けされている。これは、キールックアップデータベースがある対称キーベースのプロビジョニングと、コアのクレデンシャルとして非対称キーがあるＰＫＩベースのプロビジョニングのハイブリッドとみなすことができる。

図９は、一実施形態によるｐｕｂＤＢベースのプロビジョニングプロセスのフロー図である。記載を簡単にするために、プロセス１４００は、同様の参照番号で示されている図８の相互作用の同じシーケンス１３００を使用する。この実施形態は、有用なプロビジョニングケースであるため、立証データを使用する。リダイレクト応答１３０１に応答して、ＩｏＴデバイス１１０は、認証ポリシーサーバ１１２に送信する認証要求１４０３を生成して送信する。認証要求１４０３は、ｒｏｔＩＤ、署名、ノンス、タイムスタンプ、ＨＭＡＣ、および立証データ（ａｔｔＤａｔａとラベル付けされた）を含む。署名はＥＣＤＳＡ署名である場合があり、ｒｏｔＩＤ、時間、およびデバイスデータ（Ｐｕｂ）上のデバイスの秘密キーを使用して計算される場合がある。署名は、上記で詳しく記載したように、デバイスを認証し、デバイスデータ（Ｐｕｂ）を検証するために使用される。シーケンス１３００のように、立証データは、アプリケーションによって非対称暗号化コアに提供される追加データである。暗号化コアは、このデータを認証ポリシーサーバ１１２に送信する前に暗号化して署名する。この立証データは検証され、アクセストークンの一部としてパッケージ化される。そのようなデータの実施例は、プロビジョニングサーバ１１８による証明書発行の基盤として使用できるアプリケーションの公開キーである。

認証ポリシーサーバ１１２は、立証データとデバイス証明書を含む認証要求１４０３を受信し、認証要求１３０５としてＲｏＴアイデンティティサーバ１１４に立証データを有する認証要求１４０３を送信する。ＲｏＴ識別サーバ１１４は、ノンス、タイムスタンプ、ＨＭＡＣ、および立証データを含む認証応答１３０７で応答する。認証ポリシーサーバ１１２は、認証応答１３０７を受信する。認証応答１３０７が認証要求１３０５を検証すると仮定すると、認証ポリシーサーバ１１２は、アイデンティティトークン（ｉｄＴｏｋｅｎ）およびアクセストークン（ａｃｃｅｓｓＴｏｋｅｎ）１３０９をＩｏＴデバイス１１０に提供する。上記のように、アクセストークンは署名された立証データである場合がある。ｉｄＴｏｋｅｎには、ノンス、タイムスタンプ、およびＨＭＡＣが含まれる場合がある。ノンス、タイムスタンプ、およびＨＭＡＣはデジタル署名されている場合がある。ＩｏＴデバイス１１０は、アイデンティティトークンおよびアクセストークン１３０９を、アイデンティティトークンおよびアクセストークン１３１１としてプロビジョニングポリシーサーバ１１６に提出する。

図９の実施形態と図８の実施形態との間の主な違いは、非対称コアによって計算された署名のタイプであることに留意されたい。ここでは、対称コアの場合、署名は対称コア（例えば、ＣＭコア）によって計算された独自のチェックサムであるのに対し、それはＥＣＤＳＡであると想定されている。

図１０は、一実施形態による、図９のシーケンスの関連するコンポーネントのそれぞれに対して実行される様々な動作を示すフロー図である。ブロック１５０１でプロビジョニングポリシーサーバ１１６は、ノンスを生成し、タイムスタンプを記録し、ＰＳＫを使用してＨＭＡＣを作成し、初期応答（リダイレクト応答）を送信する。ブロック１５０３でＩｏＴデバイス１１０のアプリケーションは、ノンスおよびタイムスタンプを非対称コアのバッファに送信し、非対称コアはシーケンスを実行して署名結果を取得する。例えば、署名結果は、ナンス、タイムスタンプ、およびＨＭＡＣを使用して計算されるＥＣＤＳＡ署名である。アプリケーションは、ブロック１５０３で、認証ポリシーサーバ１１２を介してＲｏＴアイデンティティサーバ１１４に認証要求を作成して送信する。ブロック１５０５で、ＲｏＴ識別サーバ１１４は、ＨＭＡＣを検証し、デバイスの公開キーのデータベースでコアの公開キーをルックアップし、それらのＩＤ（ｒｏｔＩＤ）によってインデックス付けされる。ＲｏＴ識別サーバ１１４はまた、認証要求の署名を検証する。ＲｏＴ識別サーバ１１４はまた、認証応答を作成し、署名し、認証ポリシーサーバ１１２に送り返す。ブロック１５０７で、認証ポリシーサーバ１１２は認証要求を検証する。検証時に、認証ポリシーサーバ１１２は、アイデンティティトークン（および任意選択のアクセストークン）を作成し、署名し、ＩｏＴデバイス１１０のアプリケーションに送信する。ＩｏＴデバイス１１０でのアプリケーションは、アイデンティティトークンをプロビジョニングポリシーサーバ１１６に送り返し、ブロック１５０９で、アイデンティティトークンの署名を検証し、それ自体のポリシーに対して時間をチェックする。プロビジョニングポリシーサーバ１１６は、プロビジョニング操作も実行する。

上記のフローでは、どのエンティティもステートを保持せず、要求または応答オブジェクトに完全にカプセル化されているため、セッション識別子（セッションＩＤ）の明示的な識別子は必要ないことに留意されたい。要求／応答オブジェクト自体は、ＵＲＬエンコードされた文字列またはＪＳＯＮオブジェクトで表される場合があることにも留意されたい。

別の実施形態では、デバイスの認証に加えて、ＲｏＴアイデンティティサーバ１１４は、特定のＩｏＴアプリケーションのコンテキスト内でのみ有効なデバイスに一意のアイデンティティを提供することができる。これは、デバイスが複数のサービスで同じＩＤを使用できないようにすることにより、デバイス／ユーザーのプライバシーを保護しながら、デバイスを追跡する必要がある場合に役立つ。さらに、プロトコルは不変のＩＤを漏らしてはならない。これらのＩＤは通常、ＲｏＴ認証サービス１０４によって返されるＩＤトークンの「サブ」フィールドで提供される。代わりに、別の実施形態では、プライバシー保護構成では、この特定のアプリケーションのデバイスを表すエイリアスがＩＤトークンの「サブ」フィールドで使用される。ｐｕｂＤＢベースのプロビジョニングでは、エイリアスはアプリケーションとそのクレデンシャルに関連付けられ、不変ＩＤは公開キーを検索するためにバックエンドによって使用される。

以下で記載するのは、ＰＫＩベースのプロビジョニングの２つのサブケースである。１つのサブケースは、図９〜１０に関して上で例示され記載されたｐｕｂＤＢベースのフローおよび処理と同様のフローおよび処理を使用する。すなわち、非対称コアはＥＣＤＳＡを使用してナンス、時間、ＨＭＡＣ、および立証データの署名を行っており、ＩｏＴデバイス１１０はその結果を認証ポリシーサーバ１１２に送信する。このサブケースは、図１１〜１２に示すように、署名ＰＫＩベースのプロビジョニングプロセスと呼ばれる。別のサブケースは、コアで終端されたＴＬＳ接続を使用し、ホストデバイスから提供されたＴＬＳに依存しないことである。これはセキュリティの観点からはより良い代替案であり得るが、デバイスのオペレーティングシステム（例えば、高レベルオペレーティングシステム（ＨＬＯＳ））は他のすべての場合のようにＴＬＳエンドポイントではなくプロキシとして機能する必要があるため、より複雑な設計になる可能性がある。このサブケースは、図１３〜１４に示すように、ＴＬＳ ＰＫＩベースのプロビジョニングと呼ばれる。

図１１は、一実施形態による署名ＰＫＩベースのプロビジョニングプロセス１６００のフロー図である。記載を簡単にするために、プロセス１６００は、同様の参照番号で示されるように、立証データを含む図９の相互作用の同じシーケンス１４００を使用する。リダイレクト応答１３０１に応答して、ＩｏＴデバイス１１０は、認証ポリシーサーバ１１２に送信する認証要求１６０３を生成して送信する。認証要求１６０３は、ノンスの署名、タイムスタンプ、ＨＭＡＣ、立証データ（ａｔｔＤａｔａとラベル付けされた）、およびデバイス証明書（ｄｅｖｉｃｅＣｅｒｔ）を含む。署名はＥＣＤＳＡ署名であり得、ノンス、時間、ＨＭＡＣ、および立証データを使用して計算され得る。署名は、デバイスの認証およびデバイスデータ（Ｐｕｂ）の検証に使用される。シーケンス１４００のように、立証データは、アプリケーションによって非対称暗号化コアに提供される追加データである。暗号化コアは、このデータを認証ポリシーサーバ１１２に送信する前に暗号化して署名する。この立証データは検証され、アクセストークンの一部としてパッケージ化される。そのようなデータの実施例は、プロビジョニングサーバ１１８による証明書発行の基盤として使用できるアプリケーションの公開キーである。

認証ポリシーサーバ１１２は、立証データとデバイス証明書を含む認証要求１６０３を受信し、認証要求１６０５としてＲｏＴアイデンティティサーバ１１４に立証データおよびデバイス証明書を有する認証要求１６０３を送信する。ＲｏＴ識別サーバ１１４は、ノンス、タイムスタンプ、ＨＭＡＣ、および立証データを含む認証応答１３０７で応答する。ＲｏＴ識別サーバ１１４は、デバイス証明書が信頼できる機関によって署名されていることを検証でき、その後、信頼できるデバイス証明書から公開キーを抽出できる。その後、デバイス証明書からの公開キーを使用して、認証応答（デジタル署名）を検証できる。概して、ＲｏＴアイデンティティサーバ１１４は証明書（対称キーまたは公開キーのデータベースと同様に）を使用してデバイスを認証できる。例えば、「製造証明書」および「アプリケーション証明書」がある。後者は、前者が提供する認証に基づいて発行できる。認証ポリシーサーバ１１２は、認証応答１３０７を受信する。認証応答１３０７が認証要求１３０５を検証すると仮定すると、認証ポリシーサーバ１１２は、アイデンティティトークン（ｉｄＴｏｋｅｎ）およびアクセストークン（ａｃｃｅｓｓＴｏｋｅｎ）１３０９をＩｏＴデバイス１１０に提供する。上記のように、アクセストークンは署名された立証データである場合がある。ｉｄＴｏｋｅｎには、ノンス、タイムスタンプ、およびＨＭＡＣが含まれる場合がある。ノンス、タイムスタンプ、およびＨＭＡＣはデジタル署名されている場合がある。ＩｏＴデバイス１１０は、アイデンティティトークンおよびアクセストークン１３０９を、アイデンティティトークンおよびアクセストークン１３１１としてプロビジョニングポリシーサーバ１１６に提出する。

図１１の実施形態と図９の実施形態との間の主な違いは、認証要求１６０３で送信される非対称コアおよびデバイス証明書によって計算された署名であることに留意されたい。

図１２は、一実施形態による、図１１のシーケンスの関連するコンポーネントのそれぞれで実行される様々な動作を示すフロー図である。ブロック１７０１でプロビジョニングポリシーサーバ１１６は、ノンスを生成し、タイムスタンプを記録し、ＰＳＫを使用してＨＭＡＣを作成し、初期応答（リダイレクト応答）を送信する。ブロック１７０３でＩｏＴデバイス１１０のアプリケーションは、ノンスおよびタイムスタンプを非対称コアのバッファに送信し、非対称コアはシーケンスを実行して署名結果を取得する。例えば、署名結果は、ナンス、タイムスタンプ、およびＨＭＡＣを使用して計算されるＥＣＤＳＡ署名である。アプリケーションは、ブロック１７０３で、認証ポリシーサーバ１１２を介してＲｏＴアイデンティティサーバ１１４に認証要求を作成して送信する。上記の認証要求には、デバイス証明書が含まれる。ブロック１７０５で、ＲｏＴ識別サーバ１１４は、ＨＭＡＣを検証し、デバイス証明書を検証し、認証要求の署名を検証する。ＲｏＴ識別サーバ１１４はまた、認証応答を作成し、署名し、認証ポリシーサーバ１１２に送り返す。ブロック１７０７で、認証ポリシーサーバ１１２は認証要求を検証する。検証時に、認証ポリシーサーバ１１２は、アイデンティティトークン（および任意選択のアクセストークン）を作成し、署名し、ＩｏＴデバイス１１０のアプリケーションに送信する。ＩｏＴデバイス１１０でのアプリケーションは、アイデンティティトークンをプロビジョニングポリシーサーバ１１６に送り返し、ブロック１７０９で、アイデンティティトークンの署名を検証し、それ自体のポリシーに対して時間をチェックする。プロビジョニングポリシーサーバ１１６は、プロビジョニング操作も実行する。

上記のフローでは、どのエンティティもステートを保持せず、要求または応答オブジェクトに完全にカプセル化されているため、セッション識別子（セッションＩＤ）の明示的な識別子は必要ないことに留意されたい。要求／応答オブジェクト自体は、ＵＲＬエンコードされた文字列またはＪＳＯＮオブジェクトで表される場合があることにも留意されたい。

上記の記載のように、ＴＬＳ ＰＫＩベースのプロビジョニングでは、コアはＴＬＳクライアントとして機能し、ＴＬＳセッション内のクライアント認証にデバイスの秘密キーおよび証明書を使用する。そのセッションが確立されると、図１３で使用されるセキュリティ境界およびキーで記載されているような別の証明書のプロビジョニングを含む、アプリケーション層プロトコルをその上で実行できる。

図１３は、一実施形態による対称コアのＴＬＳ ＰＫＩベースのプロビジョニングプロセス１８００のフロー図である。プロセス１８００では、一部のデバイスは、ルートキー（ｒｏｔＫｅｙ）１８１２が格納されているＩｏＴデバイス１１０のハードウェアセキュリティ境界１８１０、認証（ｃｅｒｔｉｆｉｃａｔｅ）局秘密キー（ＣＡｐｒｉｖ）１８２２が格納されるプロビジョニングサーバ１１８のハードウェアセキュリティ境界１８２０、ならびに、データベースラップキー（ｄｂＷｒａｐＫｅｙ）１８３２および派生ルートキー（ｄｒｏｔｋｅｙ）１８３４が格納されるＲｏＴアイデンティティサーバ１１４のハードウェアセキュリティ境界１８３０、を含むハードウェアセキュリティ境界を有する。ｄｂＷｒａｐＫｅｙは、デバイスキーのデータベースを暗号化するために使用されるキーである。例えば、バックエンドが対称キーと関連するデバイスＩＤのデータベースを使用する場合、保管時に暗号化する必要がある。このために、ｄｂＷｒａｐＫｅｙが使用される。いくつかの実施形態では、ＲｏＴアイデンティティサーバ１１４は、キーデータベース１８４２が格納されるハードウェアセキュリティ境界１８４０を含む。

記載を簡単にするために、プロセス１８００は、同様の参照番号で示されるように、図５の相互作用の同じシーケンス１０００を使用する。しかしながら、プロセス１８００のシーケンスでは、以下で記載するようにＴＬＳを使用する。例えば、プロビジョニングポリシーサーバ１１６および認証ポリシーサーバ１１２は、ＴＬＳキーペア１８５０を使用して相互認証されたセキュアなチャネル１０２３上で通信することができる。プロビジョニングポリシーサーバ１１６および認証ポリシーサーバ１１２は、事前共有キー（ＰＳＫ）１８５２を交換することができる。同様に、認証ポリシーサーバ１１２およびＲｏＴアイデンティティサーバ１１４は、ＴＬＳキーペア１８５０を使用して、相互認証されたセキュアなチャネル１０１７で通信できる。ＩｏＴデバイス１１０は、デバイスＴＬＳキーペア１８５４を使用して、一方向認証されたセキュアなチャネル１０１９を介して認証ポリシーサーバ１１２と、一方向認証されたセキュアなチャネル１０２１を介してプロビジョニングポリシーサーバ１１６と、またはその両方と通信することができる。

図１４は、一実施形態による非対称コアのためのＴＬＳ ＰＫＩベースのプロビジョニングプロセス１９００のフロー図である。プロセス１９００では、一部のデバイスは、デバイス秘密キー１９１２およびＩｏＴアプリケーション秘密キー１９１４が格納されるＩｏＴデバイス１１０のハードウェアセキュリティ境界１９１０、ならびに、認証（ｃｅｒｔｉｆｉｃａｔｅ）局秘密キー（ＣＡｐｒｉｖ）１９２２が格納されるプロビジョニングサーバ１１８のハードウェアセキュリティ境界１９２０、を含むハードウェアセキュリティ境界を有する。ＲｏＴ識別サーバ１１４は、ハードウェアセキュリティ境界内に格納される必要のない公開鍵データベース１９４２を格納できることに留意されたい。

記載を簡単にするために、プロセス１９００は、同様の参照番号で示されるように、図１１の相互作用の同じシーケンス１６００を使用する。しかしながら、プロセス１９００のシーケンスでは、以下で記載するようにＴＬＳを使用する。例えば、プロビジョニングポリシーサーバ１１６および認証ポリシーサーバ１１２は、ＴＬＳキーペア１９５０を使用して相互認証されたセキュアなチャネル１０２３上で通信することができる。プロビジョニングポリシーサーバ１１６および認証ポリシーサーバ１１２は、事前共有キー（ＰＳＫ）１９５２を交換することができる。同様に、認証ポリシーサーバ１１２およびＲｏＴアイデンティティサーバ１１４は、ＴＬＳキーペア１９５０を使用して、相互認証されたセキュアなチャネル１０１７で通信できる。ＩｏＴデバイス１１０は、デバイスＴＬＳキーペア１９５４を使用して、一方向認証されたセキュアなチャネル１０１９を介して認証ポリシーサーバ１１２と、一方向認証されたセキュアなチャネル１０２１を介してプロビジョニングポリシーサーバ１１６と、またはその両方と通信することができる。

上記に記載の認証、アイデンティティ、および立証サービスに加えて、必要に応じて、追加のセキュリティチェックがシステムによって実行できる。追加のセキュリティチェックの一実施例を図１５に示す。

図１５は、一実施形態によるライブセキュリティチェックプロセス２０００のフロー図である。記載を簡単にするために、ライブセキュリティチェックプロセス２０００は、同様の参照番号で示されるように、図５の相互作用の同じシーケンス１０００を使用する。ＩｏＴデバイス１１０がアイデンティティトークン１００９をアイデンティティトークン１０１１としてプロビジョニングポリシーサーバ１１６に送信すると、プロビジョニングポリシーサーバ１１６はブロック１０１３でアイデンティティトークン１００９を検証し、ＩｏＴデバイス１１０に追加のチャレンジ２０１３を発行できる。このチャレンジ２０１３は、ＩｏＴデバイス１１０の現在のステートに基づいて応答を生成する別の静的シーケンスである可能性がある。ＩｏＴデバイス１１０は、応答２０１５を計算し、それを検証のためにプロビジョニングポリシーサーバ１１６に送り返す。並行して、プロビジョニングポリシーサーバ１１６は、認証ポリシーサーバ１１２を介してＲｏＴアイデンティティサーバ１１４に要求２０１７（ｇｅｔＥｘｐｅｃｔｅｄＲｅｓｐｏｎｓｅ）を送信し、認証ポリシーサーバ１１２を介してＲｏＴアイデンティティサーバ１１４から期待される応答２０１９を受信することができる。プロビジョニングポリシーサーバ１１６は、期待される応答２０１９をＩｏＴデバイス１１０から受信した応答２０１５と比較して、それらが一致するかどうかを確認することができる。それらが一致する場合、プロビジョニングポリシーサーバ１１６は、データ２０２１をＩｏＴデバイス１１０に送信することができる。応答２０１５が期待される応答２０１９と一致しない場合、プロビジョニングポリシーサーバ１１６は、ＩｏＴデバイス１１０にエラー応答を送信することができる。あるいは、プロビジョニングポリシーサーバ１１６はエラー応答を送信しない。

このライブセキュリティチェックでは、ＲｏＴアイデンティティサーバ１１４がＩｏＴデバイス１１０のステートを保持する必要があることに留意されたい。例えば、ＲｏＴ識別サーバ１１４は、モジュールを実行した後に期待される応答をキャッシュしなければならないだろう。

別の実施形態では、証明書の登録をセキュアするのに役立つかもしれない暗号化コアへのデータ入力を立証することに加えて、スキームを修正して、暗号化コアとバックエンドサービスの間で共有できる対称キーを生成することができる。

図１６は、一実施形態による、ＩｏＴデバイスをセキュアなプロビジョニングする方法２１００のフロー図である。方法２１００は、ハードウェア（例えば、回路、専用ロジック、プログラマブルロジック、マイクロコードなど）、ソフトウェア、ファームウェア、またはそれらの組み合わせを備え得る処理ロジックによって実行され得る。方法２１００は、デバイスプロビジョニングサービスの１つ以上のサーバで実行され得る。図１６に戻って、方法２１００は、ブロック２１０２で処理ロジックがモノのインターネット（ＩｏＴ）デバイスからメッセージを受信し、ＩｏＴデバイスをセキュアにプロビジョニングすることから始まる。メッセージはプロファイル識別子を含む。処理ロジックは、プロファイル識別子を使用してプロビジョニングポリシー情報を取得し（ブロック２１０４）、ＩｏＴデバイスを認証および承認するための信頼のルート（ＲｏＴ）認証サービスを決定する（ブロック２０１６）。処理ロジックは、ＩｏＴデバイスをＲｏＴ認証サービスにリダイレクトしてＩｏＴデバイスを認証および承認するために、ＩｏＴデバイスにリダイレクト応答を送信する（ブロック２１０８）。リダイレクト応答には、ＩｏＴデバイスの認証に使用される暗号化されたポリシー識別子が含まれる場合がある。その後、処理ロジックは、ＲｏＴ認証サービスによって発行されたトークンを含むプロビジョニング要求を受信する（ブロック２１１０）。処理ロジックは、プロビジョニング要求およびトークンを検証する（ブロック２１１２）。プロビジョニング要求およびトークンがブロック２１１２で検証されると、処理ロジックはプロビジョニング情報をＩｏＴデバイスに送信し（ブロック２１１４）、方法２１００は終了する。プロビジョニング要求、トークン、またはその両方がブロック２１１２で検証されない場合、処理ロジックはエラーメッセージを送信する（またはしない）（ブロック２１１６）ため、方法２１００は終了する。

さらなる実施形態において、処理ロジックは、ブロック２１１２でプロビジョニング要求およびトークンが検証されると、ＩｏＴデバイスをＩｏＴアプリケーションサービスに登録する。場合によっては、トークン、デバイス、またはその両方を登録できる。ＩｏＴアプリケーションサービスはローカル登録を実行し、デバイスプロビジョニングサービスに確認応答（ＡＣＫ）を送り返すことができる。

さらなる実施形態では、処理ロジックは、セキュリティクレデンシャルをＲｏＴ認証サービスと交換する。処理ロジックは、ＲｏＴ認証サービスから認証方法のリストを取得（または受信）する。認証方法は、ＩｏＴプラットフォームプロバイダによって指定されるなど、ＩｏＴデバイスの認証に使用されるプロセスである。処理ロジックは、リストから認証方法を選択し、認証方法のポリシー識別子を割り当てる。処理ロジックは、ポリシー識別子および認証方法をＲｏＴ認証サービスに送信する。処理ロジックは、ＲｏＴ認証サービスおよびセッションキーを確立することもできる。一実施形態では、ポリシー識別子は、ＲｏＴ認証サービスによって発行されたトークンに関する１つ以上の要件を定義する。別の実施形態では、セキュリティクレデンシャルはＭＡＣを含む。

別の実施形態では、処理ロジックは、ＭＵＤファイルに記載されたＵＲＬを受信することによりメッセージを受信し、ＭＵＤファイルはプロファイル識別子を含む。さらなる実施形態では、処理ロジックは、プロビジョニングポリシー情報から、ＲｏＴ認証サービスによってＩｏＴデバイスを認証するために使用される認証方法を決定し、認証方法は識別ポリシー識別子を有する。処理ロジックは、リダイレクト応答のＵＲＬに識別ポリシー識別子をエンコードする。

別の実施形態において、処理ロジックは、プロビジョニング要求内のトークンが未知の形式を有することを決定し、トークンをＲｏＴ認証サービスに検証する要求を送信し、ＲｏＴ認証サービスから検証応答を受信する。別の実施形態では、処理ロジックは、プロビジョニング要求内のトークンがＲｏＴ属性を含むことを決定し、トークンからＲｏＴ属性を抽出する。処理ロジックは、ＲｏＴ認証サービスから追加のＲｏＴセキュリティ属性を取得する要求を送信し、追加のＲｏＴセキュリティ属性には、識別ポリシー識別子が含まれる。処理ロジックは、追加のＲｏＴセキュリティ属性を検証する。

別の実施形態では、処理ロジックは、ＩｏＴアプリケーションへのアクセスがＩｏＴデバイスに許可されるべきかどうかをチェックするために、ＩｏＴアプリケーションサービスからチェックアクセス要求を受信する。アクセス確認リクエストには、ＩｏＴデバイスのプロビジョニングされた情報が含まれる。処理ロジックは、プロビジョニングされた情報を使用してＩｏＴデバイスのアクセスを検証し、ＩｏＴアプリケーションサービスに応答を送信する。

上記で記載した様々な実施形態は、本明細書で記載したデバイスプロビジョニングサービスの１つ以上のサーバによって実行される動作に関するものであり得る。他の実施形態では、デバイスプロビジョニングサービス１０６のプロビジョニングポリシーサーバ１１６およびプロビジョニングサーバ１１８など、本明細書で記載されたデバイスの指定されたサーバによって他の方法が実行されてもよい。他の実施形態では、認証ポリシーサーバ１１２およびＲｏＴ識別サーバ１１４に関して上記で記載した動作を含む他の方法がＲｏＴ認証サービスによって実行されてもよい。同様に、本明細書で記載されたＩｏＴアプリケーションゲートウェイ１２０およびＩｏＴアプリケーションサーバ１２２を含む、ＩｏＴデバイス１１０、およびＩｏＴアプリケーションサービス１０８によって他の方法が実行されてもよい。

図１７は、本明細書に記載の方法のいずれかが一実施形態に従って実行され得るコンピュータシステム２２００の一実施形態の図である。コンピュータシステム２２００は、プロセッサ２２０２、メインメモリ２２０４、ストレージメモリ２２０６、チップセット２２０８、１つ以上の周辺機器２２１０、ネットワークインターフェースデバイス２２２２を含むことができ、リムーバブルストレージデバイスインターフェース２２０３は、リムーバブルストレージデバイス２２１５と接続するように構成可能である。プロセッサ２２０２は、本明細書で記載された方法論のいずれかに従って命令２２２６（またはソフトウェア）を実行するように動作可能である。命令２２２６は、メインメモリ２２０４またはリムーバブルストレージデバイス２２０５に格納され、プロセッサ２２０２によって実行される命令を含むことができ、本明細書で記載された認証、アイデンティティ、立証、およびライブセキュリティチェックサービスに関する様々な操作を実行するために使用できる。一実施形態では、コンピュータシステム２２００は、ＩｏＴデバイス１１０、認証ポリシーサーバ１１２、ＲｏＴアイデンティティサーバ１１４、プロビジョニングポリシーサーバ１１６ プロビジョニングサーバ１１８、ＩｏＴアプリケーションゲートウェイ１２０、ＩｏＴアプリケーションサーバ１２２、またはＩｏＴセキュア分析サービス１３０の任意のデバイスのような、図１のＩＤＭ１００のデバイスのいずれか１つ以上を表す。

コンピュータシステム２２００は、場合によっては、（例えば、ネットワークされた）ＬＡＮ、イントラネット、エクストラネット、またはインターネット内の他のマシンに接続されてもよい。コンピュータシステム２２００は、クラウド内のホスト、クラウドプロバイダーシステム、クラウドコントローラ、サーバ、クライアント、または他のマシンであり得る。コンピュータシステム２２００は、クライアントサーバネットワーク環境のサーバまたはクライアントマシンの容量で、またはピアツーピア（または分散）ネットワーク環境のピアマシンとして動作することができる。マシンは、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、コンソールデバイスまたはセットトップボックス（ＳＴＢ）、携帯情報端末（ＰＤＡ）、携帯電話機、ウエブアプライアンス、サーバ、ネットワークルータ、スイッチもしくはブリッジ、もしくはそのマシンが実行するアクションを指定する（一連のまたはそれ以外の）命令セットを実行する。さらに、単一のマシンのみが示されているが、「マシン」という用語は、本明細書で記載する方法論の１つ以上を実行する１つの命令セット（または複数のセット）を個別または共同で実行するマシン（例えば、コンピュータ）の集合体も含むものとする。

コンピュータシステム２２００は、バス２２３０を介して互いに通信するプロセッサ２２０２（例えば、ホストプロセッサまたは処理装置）、メインメモリ２２０４（例えば、読み取り専用メモリ（ＲＯＭ）、フラッシュメモリ、ダイナミックランダムアクセスメモリ（ＤＲＡＭ））、ストレージメモリ２２０６（例えば、フラッシュメモリ、スタティックランダムアクセスメモリ（ＳＲＡＭ）など）、およびセカンダリメモリ２２１８（例えば、ドライブユニットの形式のデータストレージデバイスであり、これには、固定または取り外し可能なコンピュータ可読ストレージメディアが含まれる場合がある）を含む。

プロセッサ２２０２は、マイクロプロセッサ、中央処理装置などの１つ以上の汎用処理デバイスを表す。より具体的には、プロセッサ２２０２は、複合命令セットコンピューティング（ＣＩＳＣ）マイクロプロセッサ、縮小命令セットコンピューティング（ＲＩＳＣ）マイクロプロセッサ、超長命令語（ＶＬＩＷ）マイクロプロセッサ、他の命令セットを実装するプロセッサ、または命令セットの組み合わせを実装するプロセッサであり得る 。プロセッサ２２０２は、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、ネットワークプロセッサなどの１つ以上の専用処理装置であってもよい。

一実施形態では、プロセッサ２２０２は第１の集積回路上に存在してもよく、メインメモリ２２０４は第２の集積回路上に存在してもよい。例えば、集積回路は、ホストコンピュータ（例えば、１つ以上の処理コア、Ｌ１キャッシュ、Ｌ２キャッシュなどを有するＣＰＵ）、ホストコントローラ、または他のタイプのプロセッサ２２０２を含み得る。第２の集積回路は、ホストデバイスに結合されたメモリデバイスを含むことができ、その主な機能はホストデバイスに依存するため、ホストデバイスのコアアーキテクチャの一部を形成せずに、ホストデバイスの機能を拡張するとみなすことができる。メモリデバイスは、ホストデバイスと通信可能であってもよい。例えば、メモリデバイスは、共通の集積回路基板上の単一のＩＣデバイスの任意の組み合わせを含む単一のＩＣまたはマルチＩＣモジュールであり得る。図１７の構成要素は、例えば、集積回路（「ＩＣ」）ダイ基板、マルチＩＣモジュール基板などの「共通キャリア基板」上に存在することができる。あるいは、メモリデバイスは、例えば、マザーボード、ドーターボード、または他のタイプの回路カードなどの１つ以上のプリント回路基板上に存在してもよい。他の実装形態では、メインメモリおよびプロセッサ２２０２は、同じまたは異なるキャリア基板上に常駐することができる。

コンピュータシステム２２００は、プロセッサ２２０２と共に動作するように設計され、プロセッサ２２０２と外部デバイスとの間の通信を制御する集積回路またはチップのグループを指すチップセット２２０８を含むことができる。例えば、チップセット２２０８は、プロセッサ２２０２をメインメモリ２２０４やグラフィックコントローラなどの非常に高速なデバイスにリンクし、処理デバイスをＵＳＢ、ＰＣＩ、またはＩＳＡバスなどの周辺機器２２１０低速の周辺バスにリンクするマザーボード上のＩＣのセットである場合がある。一実施形態では、リムーバブル記憶装置インターフェース２２０３は、チップセット２２０８に実装することができる。

コンピュータシステム２２００は、ネットワークインターフェースデバイス２２２２をさらに含むことができる。また、コンピュータシステム２２００は、グラフィックポートおよびグラフィックチップセットを介してコンピュータシステムに接続されたビデオディスプレイユニット（例えば、液晶ディスプレイ（ＬＣＤ））、英数字入力デバイス（例えば、キーボード）、カーソル制御デバイス（例えば、マウス）、信号生成デバイス（例えば、スピーカ）などの１つ以上の周辺機器２２１０を含み得る。集積回路デバイスの「プログラミング」には、例えば、制限なしに、ホスト命令に応じてデバイス内のレジスタまたはその他のストレージ回路に制御値をロードし、デバイスの動作面を制御すること、ワンタイムプログラミング操作（例えば、デバイスの製造中に構成回路内でヒューズを切断すること）により、デバイス構成を確立するか、またはデバイスの動作面を制御すること、および／または、デバイスの１つ以上の選択されたピンまたは他の接触構造を基準電圧線に接続して（ストラッピングとも呼ばれる）、デバイスの特定のデバイス構成または動作を確立すること、を含み得る。「例示的」という用語は、好みまたは要件ではなく、実施例を表すために使用される。

上記の記載では、多くの詳細が説明されている。しかしながら、本開示の利益を有する当業者には、これらの特定の詳細なしで本発明の実施形態を実施できることが明らかであろう。場合によっては、記載を不明瞭にしないために、よく知られた構造とデバイスは、むしろ詳細ではなく、ブロック図形式で示されている。

詳細な記載の一部は、コンピューターメモリ内のデータビットに対する操作のアルゴリズムおよび記号表現の観点から提示されている。これらのアルゴリズムの記載および表現は、データ処理分野の当業者が自分の仕事の内容を他の当業者に最も効果的に伝えるために使用する手段である。アルゴリズムは、ここで、そして概して、望ましい結果をもたらす一貫したステップのシーケンスであると考えられている。ステップは、物理量の物理的な操作を必要とするものである。通常、必ずしもではないが、これらの量は、格納、転送、結合、比較、その他の操作が可能な電気信号または磁気信号の形式を取る。主に一般的な使用上の理由から、これらの信号をビット、値、要素、記号、文字、用語、数字などと呼ぶと便利な場合がある。

しかしながら、これらの用語および類似の用語はすべて適切な物理量に関連付けられるものであり、これらの量に適用される便利なラベルにすぎないことに留意されたい。上記の議論から明らかであると特に明記しない限り、明細書、「暗号化」、「復号化」、「格納」、「提供」、「導出」、「取得」、「受信」、「認証」、「削除」、「実行」、「要求」、「通信」などの用語を使用する議論の全体を通して、コンピューティングシステムのレジスタおよびメモリ内の物理（電子など）量として表されるデータを、コンピューティングシステムメモリまたはレジスタ、またはその他のそのような情報の格納デバイス、送信デバイス、または表示デバイス内の物理量として同様に表される他のデータに操作および変換する、コンピューティングシステムまたは同様の電子コンピューティングデバイスのアクションおよびプロセスを指す。

本明細書では、「実施例」または「例示的な」という言葉は、じっし例、事例、または例証として役立つことを意味するために使用される。「実施例」または「例示的」として本明細書で記載される任意の態様または設計は、必ずしも他の態様または設計よりも好ましいまたは有利であると解釈されるべきではない。むしろ、「実施例」または「例示的な」という言葉の使用は、概念を具体的な方法で提示することを意図している。本開示で使用される「または」という用語は、排他的な「または」ではなく、包括的な「または」を意味することを意図している。すなわち、特に指定しない限り、または文脈から明らかでない限り、「ＸはＡまたはＢを含む」は、自然な包括的な順列のいずれかを意味することを意図している。すなわち、ＸはＡを含む、ＸはＢを含む、または、ＸはＡおよびＢの両方を含む、であれば、「ＸはＡまたはＢを含む」は、前述のいずれかの場合で満たされる。さらに、本開示および添付の特許請求の範囲で使用される冠詞「ａ」および「ａｎ」は、特に明記しない限り、または単数形を対象とする文脈から明確でない限り、「１つ以上」を意味すると解釈されるべきである。さらに、「実施形態」または「一実施形態」または「実装形態」または「一実装形態」という用語は、そのように記載しない限り、同じ実施形態または実装形態を意味するものではない。

本明細書で記載される実施形態は、本明細書の動作を実行するための装置にも関連し得る。この装置は、必要な目的のために特別に構築されてもよいし、コンピュータに保存されたコンピュータプログラムによって選択的に起動または再構成される汎用コンピュータを備えてもよい。そのようなコンピュータプログラムは、フロッピーディスク、光ディスク、ＣＤ−ＲＯＭおよび光磁気ディスク、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カードまたは光カード、フラッシュメモリ、または電子命令の格納に適したあらゆる種類のメディアを含む任意のタイプのディスクなどの、しかしながらこれらに限定されない、非一時的なコンピュータ可読記憶媒体に格納されてもよい。用語「コンピュータ可読記憶媒体」は、命令の１つ以上のセットを格納する単一の媒体または複数の媒体（例えば、集中型または分散型データベースおよび／または関連するキャッシュおよびサーバ）を含むと解釈されるべきである。「コンピュータ可読媒体」という用語は、マシンによる実行のための命令セットを格納、エンコード、または実行することができ、マシンに本実施形態の１つまたは複数の方法論のいずれかを実行させる任意の媒体も含むものとする。したがって、「コンピュータ可読記憶媒体」という用語は、固体メモリ、光学媒体、磁気媒体、マシンによる実行のための命令セットを格納できる任意の媒体、およびこれらに限定されないものと解釈されるものとし、これにより、マシンは、本実施形態の方法論のいずれか１つ以上を実行する。

本明細書で提示されるアルゴリズムおよび表示は、特定のコンピュータまたは他の装置に本質的に関連するものではない。本明細書の教示に従って、様々な汎用システムをプログラムと共に使用することができ、または必要な方法ステップを実行するためにより特化した装置を構築することが便利であることが判明する場合がある。これらの様々なシステムに必要な構造は、以下の記載から明らかになる。さらに、本実施形態は、特定のプログラミング言語を参照して記載されていない。本明細書に記載の実施形態の教示を実施するために、様々なプログラミング言語を使用できることが理解されよう。

上記の記載は、本発明のいくつかの実施形態の良好な理解を提供するために、特定のシステム、コンポーネント、方法などの実施例などの多数の特定の詳細を示している。しかしながら、本発明の少なくともいくつかの実施形態は、これらの特定の詳細なしで実施できることが当業者には明らかであろう。他の実施例では、本発明を不必要に不明瞭にすることを避けるために、周知のコンポーネントまたは方法は詳細に説明されないか、または単純なブロック図形式で提示される。したがって、上記の特定の詳細は単なる例示にすぎない。特定の実装形態は、これらの例示的な詳細とは異なる場合があり、それでも本発明の範囲内にあると考えられる。

上記の記載は例示的なものであり、限定的なものではないことを理解されたい。上記の記載を読んで理解すると、多くの他の実施形態が当業者に明らかになるであろう。したがって、本発明の範囲は、添付の特許請求の範囲を参照して、そのような特許請求の範囲が権利を有する均等物の全範囲とともに決定されるべきである。

本発明をその特定の実施形態を参照して記載してきたが、本発明のより広い精神および範囲から逸脱することなく、様々な修正および変更を加えることができることは明らかであろう。例えば、少なくとも実施可能な場合、実施形態のいずれかの特徴または態様を、他の実施形態と組み合わせて、または対応する特徴または態様の代わりに適用することができる。したがって、明細書および図面は、制限的な意味ではなく、例示的な意味でみなされるべきである。

Claims (26)

1. 分散信頼ネットワークを確立するためのシステムであって、
   デバイスの信頼のルート（ＲｏＴ）の直接の知識を有し、アプリケーションサービスに前記デバイスの認証サービスおよびセキュアなプロビジョニングサービスを提供する、ＲｏＴサービスを有し、それによって、前記アプリケーションサービスが前記デバイスのＲｏＴの直接の知識を有することなく前記デバイスとの信頼できる接続を確立することができ、前記ＲｏＴサービスは前記認証サービスを提供する認証ポリシーサーバおよびＲｏＴアイデンティティサーバを含み、前記認証ポリシーサーバのフロントエンドプロトコルはプロトコル固有であり、バックエンドプロトコルは前記フロントエンドプロトコルから独立している、システム。
2. 前記フロントエンドプロトコルはステートを保持し、前記バックエンドプロトコルはステートレスである、請求項１に記載のシステム。
3. 前記直接の知識は、前記デバイスのデバイス製造中にプロビジョニングされた少なくとも１つのキーに基づく、請求項１に記載のシステム。
4. 前記フロントエンドプロトコルは、前記デバイスに対するチップ製造業者のビジネス要件、通信プロトコル、および認証プロトコルを含む、請求項１に記載のシステム。
5. 前記デバイスをさらに備え、前記デバイスの前記ＲｏＴはハードウェアＲｏＴである、請求項１に記載のシステム。
6. 前記デバイスをさらに備え、前記デバイスの前記ＲｏＴはソフトウェアＲｏＴである、請求項１に記載のシステム。
7. 前記認証ポリシーサーバおよび前記ＲｏＴアイデンティティサーバは、トランスポート層セキュリティ（ＴＬＳ）およびハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）を使用して通信する、請求項１に記載のシステム。
8. 前記アプリケーションサービスをさらに備え、前記アプリケーションサービスは、前記デバイスにアプリケーションを提供する、請求項１に記載のシステム。
9. 前記アプリケーションサービスは、フロントエンドアプリケーションゲートウェイおよびバックエンドアプリケーションサーバを含む、請求項８に記載のシステム。
10. 前記フロントエンドアプリケーションゲートウェイおよび前記バックエンドアプリケーションサーバは、ハイパーテキスト転送プロトコルセキュア（ＨＴＴＰＳ）を使用して通信する、請求項９に記載のシステム。
11. 前記ＲｏＴサービスは、前記セキュアなプロビジョニングサービスを提供するためのフロントエンドプロビジョニングポリシーサーバおよびバックエンドプロビジョニングサーバをさらに含む、請求項１に記載のシステム。
12. デバイスプロビジョニングサービスで、モノのインターネット（ＩｏＴ）デバイスから、前記ＩｏＴデバイスをセキュアにプロビジョニングするためのメッセージであって、プロファイル識別子およびプロビジョニング要求を含む、メッセージを受信することと、
    前記プロファイル識別子を使用してプロビジョニングポリシー情報を取得することと、
    前記ＩｏＴデバイスを認証および承認するために、信頼のルート（ＲｏＴ）認証サービスを決定することと、
    前記デバイスプロビジョニングサービスによって、前記ＩｏＴデバイスを前記ＲｏＴ認証サービスにリダイレクトして前記ＩｏＴデバイスを認証および承認するために、前記ＩｏＴデバイスにリダイレクト応答を送信することであって、前記リダイレクト応答は、前記ＩｏＴデバイスの認証に使用される暗号化されたポリシー識別子を含む、送信することと、
    前記デバイスプロビジョニングサービスで、前記ＲｏＴ認証サービスによって発行されたトークンを含むプロビジョニング要求を受信することと、
    前記プロビジョニング要求および前記トークンを検証することと、
    前記プロビジョニング要求および前記トークンが検証されると、前記デバイスプロビジョニングサービスによってプロビジョニング情報を前記ＩｏＴデバイスに送信することと、を含む、方法。
13. 前記プロビジョニング要求および前記トークンが検証されたときに、前記デバイスプロビジョニングサービスによって、前記ＩｏＴデバイスをＩｏＴアプリケーションサービスに登録することと、をさらに含む、請求項１２に記載の方法。
14. 前記デバイスプロビジョニングサービスによって、前記ＲｏＴ認証サービスとセキュリティクレデンシャルを交換することと、
    前記ＲｏＴ認証サービスから認証方法のリストを取得することと、
    前記リストから認証方法を選択することと、
    前記認証方法にポリシー識別子を割り当てることと、
    前記ポリシー識別子および前記認証方法を前記ＲｏＴ認証サービスに送信することと、
    前記ＲｏＴ認証サービスとのセッションキーを確立することと、をさらに含む、請求項１２に記載の方法。
15. 前記ポリシー識別子は、前記ＲｏＴ認証サービスによって発行されたトークンに関する１つ以上の要件を定義する、請求項１４に記載の方法。
16. 前記セキュリティクレデンシャルがメッセージ認証コード（ＭＡＣ）を含む、請求項１４に記載の方法。
17. 前記メッセージを受信することは、製造業者使用記述（ＭＵＤ）ファイルに記述されたユニフォームリソースロケータ（ＵＲＬ）を受信することを含み、前記ＭＵＤファイルは前記プロファイル識別子を含む、請求項１２に記載の方法。
18. 前記プロビジョニングポリシー情報から、前記ＲｏＴ認証サービスによるＩｏＴデバイスの認証に使用される認証方法を決定することであって、前記認証方法は識別ポリシー識別子を有する、決定することと、
    前記リダイレクト応答のユニフォームリソースロケータ（ＵＲＬ）で前記識別ポリシー識別子をエンコードすることと、をさらに含む、請求項１２に記載の方法。
19. 前記プロビジョニング要求内の前記トークンの形式が不明であることを決定することと、
    前記ＲｏＴ認証サービスに前記トークンを検証する要求を送信することと、
    前記ＲｏＴ認証サービスから検証応答を受信することと、をさらに含む、請求項１２に記載の方法。
20. 前記プロビジョニング要求内の前記トークンにＲｏＴ属性が含まれていると決定することと、
    前記トークンから前記ＲｏＴ属性を抽出することと、
    前記ＲｏＴ認証サービスから追加のＲｏＴセキュリティ属性を取得する要求を送信することであって、前記追加のＲｏＴセキュリティ属性には、識別ポリシー識別子が含まれる、送信することと、
    前記追加のＲｏＴセキュリティ属性を検証することと、をさらに含む、請求項１２に記載の方法。
21. ＩｏＴアプリケーションへのアクセスをＩｏＴデバイスに許可すべきかどうかをチェックするために、前記ＩｏＴアプリケーションサービスからアクセスチェック要求を受信することであって、前記アクセスチェック要求は、前記ＩｏＴデバイスのプロビジョニングされた情報を含む、受信することと、
    前記プロビジョニングされた情報を使用して前記ＩｏＴデバイスのアクセスを検証することと、
    前記デバイスプロビジョニングサービスによって、前記ＩｏＴアプリケーションサービスへの応答を送信することと、をさらに含む、請求項１２に記載の方法。
22. デバイスプロビジョニングサービスから信頼のルート（ＲｏＴ）認証サービスで、トークンを発行するための要件を定義するプロビジョニングポリシー情報を受信することと、
    前記ＲｏＴ認証サービスで、モノのインターネット（ＩｏＴ）デバイスから前記ＩｏＴデバイスを認証および承認するためにリダイレクトメッセージを受信することであって、前記メッセージは、前記プロビジョニングポリシー情報およびプロビジョニング要求を識別するために使用されるポリシー識別子を含む、受信することと、
    前記プロビジョニングポリシー情報に従い、前記ＲｏＴ認証サービスによって前記ＩｏＴデバイスを認証および承認することと、
    前記ＩｏＴデバイスが認証および承認されたときにトークンを発行することと、
    前記発行されたトークンで前記ＩｏＴデバイスにリダイレクト応答を送信することであって、前記リダイレクト応答は、前記ＩｏＴデバイスをセキュアにプロビジョニングするための要求をセキュアにプロビジョニングするためのプロビジョニング要求に発行されたトークンを使用して、前記ＩｏＴデバイスを前記デバイスプロビジョニングサービスにリダイレクトする、送信することと、を含む、方法。
23. 前記ＲｏＴ認証サービスにより、前記デバイスプロビジョニングサービスとセキュリティクレデンシャルを交換することと、
    認証方法のリストを前記デバイスプロビジョニングサービスに提供することと、
    前記リストから１つの認証方法の選択を受信することと、
    前記デバイスプロビジョニングサービスから前記ポリシー識別子および前記認証方法の割り当てを受信することと、
    前記デバイスプロビジョニングサービスとのセッションキーを確立することと、をさらに含む、請求項２２に記載の方法。
24. 前記ポリシー識別子は、前記ＲｏＴ認証サービスによって発行されたトークンに関する１つ以上の要件を定義する、請求項２３に記載の方法。
25. 前記セキュリティクレデンシャルがメッセージ認証コード（ＭＡＣ）を含む、請求項２３に記載の方法。
26. 前記リダイレクトメッセージを受信することは、識別ポリシー識別子でエンコードされたユニフォームリソースロケータ（ＵＲＬ）を受信することを含む、請求項２２に記載の方法。
    

Images