JP2019537185A - デバイスの信頼されたプールを作成する方法 - Google Patents

Abstract

本発明は、サービスプロバイダ（ＡＤＭ）によって、セキュアサービスにおける暗号化動作を実行するように構成されたセキュリティデバイス（ＳＤｉ）の信頼されたプールを作成するための方法であって、サービスプロバイダ（ＡＤＭ）が、セキュアサービスを、第１のデバイス（ＳＤ１）をサービス内に割り振ることによってセットアップするステップと、第１のセキュリティデバイスのクロックを信用できる時間ソース（ＵＴＳ）に設定するステップ（Ｓ２）と、リソースオーナーのセキュリティアプリケーション（Ａｐｐ）とセキュアサービスのセキュリティデバイス（ＳＤ）部分との間の通信を保護するために使用される、少なくともサービスクロックインスタンス（ＳＣＩ）とサービス固有暗号鍵と証明書とを定義する内部セキュアサービスオブジェクト（ＳＳＯ）を作成し（Ｓ５）、前記セキュアサービスオブジェクト（ＳＳＯ）が、セキュリティデバイス（ＳＤ１）によって内部で維持され、任意のサービスプロバイダがそれを恣意的に変更するのを防ぐ、ステップと、追加のセキュリティデバイス（ＳＤｉ）が必要とされるとき、サービスプロバイダ（ＡＤＭ）が、ターゲットセキュリティデバイスのクロックを正確な時間値（ＵＴＳ）に設定し（Ｓ１０）、セキュアサービスオブジェクト（ＳＳＯ）において、プールの２つのデバイス間のドリフトを限定する最大デルタ時間（ＭＤＴ）と１日当たり最大日次補正（ＭＤＣ）値とを定義することによって、２つのセキュリティデバイスのクロック（Ｔｉ）が同期していることを保証することを通して、追加のセキュリティデバイス（ＳＤｉ）をサービスに追加するステップとを含む、方法に関する。

Description

本発明は、サービスプロバイダによって、セキュアサービスにおける暗号化動作を実行するように構成されたセキュリティデバイスの信頼されたプールを作成するための方法に関する。

本発明はまた、前記方法を実装するセキュリティデバイスに関する。

スケーラブルベースの認証方式（ｓｃａｌａｂｌｅ ｂａｓｅｄ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｓｃｈｅｍｅ）は、時間に大きく依存する。たとえば、ＯＡＵＴＨ２トークンは、識別されたアクターが特定の時間においてそれ自体を成功裏に認証したことを確認する。トークンは、次いで、有効期間をもつ許可（ａｕｔｈｏｒｉｚａｔｉｏｎ）データを運ぶ。したがって、このように、保護されるリソースは、ＯＡＵＴＨ２トークンの悪用を防ぐために信頼できるクロックを有することが重要である。リソースがクラウドプロバイダによって管理されるとき、リソースオーナーは、正しいクロックを維持するためにそのプロバイダに依存することを強制される。これは、顧客の保護されるリソースについてのセキュリティリスクを生じる。プロバイダまたはプロバイダのスタッフは、アクセストークンをキャプチャし、次いで、単にホストの時間を捏造することによって、保護されるリソースを悪用することができる。これは、保護されるリソースが、セキュリティデバイス、一般にＨＳＭ、によって保護された暗号鍵であるとき、特に重要な問題点である。

クラウドベースＨＳＭが高い保証を提供する１つのやり方は、プロバイダが鍵材料（ｋｅｙ ｍａｔｅｒｉａｌ）を悪用するのを防ぐことによるものである。ＨＳＭが、鍵がＨＳＭによってのみ使用され得ることを保証し、ＨＳＭの機能が、デバイス製造業者と、関連する証明プロセスとによって厳しく制御されるので、鍵オーナーは、ＨＳＭが関与するとき、それらの鍵が安全であると確信することができる。しかしながら、プロバイダが、ＨＳＭ支援（ＨＳＭ−ｂａｃｋｅｄ）サービスを提供することが実際的であるためには、ＨＳＭの大きいプールが、単一のリソースとして働くことが可能でなければならない。また、ＨＳＭのアクセス制御システムは、最も、クラウドのＩＡＭサービスにさらに統合されなければならない。これは、２つの関連する課題、すなわち、クラウドベースＨＳＭが、時間ベースの認証システムを使用するべきであることと、リソースオーナーが、プール中のどのデバイスがリソースオーナーのサービスを配信するのか確信できないこととを生じる。

したがって、システムの完全性を損なうことなしにクラウドベースＨＳＭを実現可能にするために、ＨＳＭは、時間の完全性が保証された時間ベースの認証方式をサポートしなければならない。さらに、リソースオーナーが、プール中の個々のデバイスに対する可視性および／またはデバイスがいつ追加または削除されるかに対する可視性を決して与えられないという事実は、厄介な問題をもたらす。

したがって、当技術分野において、さらなる代替のおよび有利なソリューションが望ましいであろう。

本発明は、一般にクラウド環境において、セキュリティデバイスのセキュアプールの使用に基づいてセキュアサービスを提供することを目的とする。

本発明は、その最も広い意味では、サービスプロバイダによって、セキュアサービスにおける暗号化動作を実行するように構成されたセキュリティデバイスの信頼されたプールを作成するための方法として定義され、本方法は、
サービスプロバイダが、第１のデバイスをサービス内に割り振ることによって、セキュアサービスをセットアップするステップと、第１のセキュリティデバイスのクロックを信用できる時間ソースに設定するステップと、リソースオーナーのセキュリティアプリケーションとセキュアサービスのセキュリティデバイス部分との間の通信を保護するために使用される、少なくともサービスクロックインスタンス値とサービス固有暗号鍵と証明書とを定義する内部セキュアサービスオブジェクトを作成し、前記セキュアサービスオブジェクトが、セキュリティデバイスによって内部で維持され、任意のサービスプロバイダがそれを恣意的に変更するのを防、ステップと、
追加のセキュリティデバイスが必要とされるとき、サービスプロバイダが、ターゲットセキュリティデバイスのクロックを正確な時間値に設定し、セキュアサービスオブジェクトにおいて、プールの２つのデバイス間のドリフトを限定する最大デルタ時間（ｍａｘ−ｄｅｌｔａ−ｔｉｍｅ）と１日当たり最大日次補正（ｍａｘ−ｄａｉｌｙ−ｃｏｒｒｅｃｔｉｏｎ ｐｅｒ ｄａｙ）値とを定義することによって、２つのセキュリティデバイスのクロックが同期していることを保証することを通して、追加のセキュリティデバイスをサービスに追加するステップとを含む。

本発明は、サービスプロバイダが、デバイスのプール全体におけるすべてのクロックの精度および完全性にわたる可視性をリソースオーナーに与えながら、クラウドベースセキュアサービスにおいてＨＳＭデバイスおよびそれらのクロックをサービスプロバイダ自体によって管理することを可能にする。ターゲットまたはターゲットにされるデバイスは、セキュアサービスに追加されるべきデバイスである。本発明は、実際に、サービスプロバイダが、デバイス上のクロックを自動様式で設定するが、同時に、それらがプール中のあらゆる他のデバイスと同期するように強制されることを可能にする。本発明は、リソースオーナーが、プール中にセキュリティデバイスを追加することによって新しいリソースを作成したときを含めて、いつでもプール中のすべてクロックの正しさを監査することを可能にする。本発明は、クロックが明確な許容差内で変更されない限り、リソース消費が勝手に進むことを可能にする。本発明は、許容される許容差外にクロックが変更されるかまたは再設定されるときはいつでも、リソースオーナーが、リソース使用を検出し、許容／拒否することを可能にする。本発明は、さらに、破局的な事象が生じた場合、たとえば、プロバイダのリソース世界におけるあらゆるデバイスが、それらのクロックを同時に破損されたとき、リソースオーナーのみが関与するように、人間相互作用の数を最小化する。本発明は、それが、サービスプロバイダがプールのセキュリティデバイスのクロックを管理することを可能にし、同時にそれが、設定された１日当たり最大日次補正を使用して、１日につき許容時間よりも多く恣意的にクロックが変更され得ないことの保証をリソースオーナーに与えるので、独特である。これは、サービスプロバイダが、時間を変更し、古いメッセージを恣意的に再生するのを防ぐ。最大デルタ時間と１日当たり最大日次補正値とを含んでいるセキュアサービスオブジェクトは、各セキュリティデバイスによって内部で維持される。本発明は、したがって、特定のセキュアサービスを実装するためのプールの各セキュリティデバイス中の最大デルタ時間と１日当たり最大日次補正値との存在に基づく。本発明では、クロックは、それらが既存の方法を使用して（ＮＴＰのようなものまたは任意のクロック維持方法を使用して）一般にそうするであろうやり方で、技術的に同期される。本発明は、サービスプロバイダが、サービスを作成する間、クロックをサービスプロバイダ自体で監視するが、セキュアサービスが実装されている任意のセキュリティデバイスによる最大変更が許可される、という事実から生じる。本発明は、リソースオーナーが、任意のセキュリティデバイスの真正性（ｇｅｎｕｉｎｅｎｅｓｓ）を、セキュアサービスを実装するデバイスの正しいプールに属することとして検査することを可能にする。一旦、サービスが作成されると、サービスプロバイダが、セキュリティデバイスに記憶されたセキュアサービスオブジェクトのうちのいずれの内容をも変更する手段を有せず、セキュアサービスオブジェクトが各セキュリティデバイスによって維持されるので、サービスプロバイダは、セキュリティデバイスの同期を変更するやり方を有しない。したがって、セキュアサービスが前もって実装されたセキュリティデバイスにおいて作成および維持された、セキュアサービスオブジェクト中の最大デルタ時間と１日当たり最大日次補正値との存在は、セキュアサービスを使用する任意のリソースオーナーが、セキュアサービスを正当に実装するセキュリティデバイスと関係があることを保証する。本質的特徴は、セキュアサービスを実装する任意のセキュリティデバイスに搭載されたセキュアサービスオブジェクトの存在であり、このセキュアサービスオブジェクトが、少なくとも最大デルタ時間と１日当たり最大日次補正値とを含むことである。

したがって、任意のサービスプロバイダが、セキュリティデバイスにセキュアサービスオブジェクトを作成させることができ、そのセキュアサービスオブジェクトは、次いでこのセキュリティデバイス中で完全に維持され、次いで、セキュアサービスを実装するために他のセキュリティデバイスに潜在的に移される。本発明において定義されたこのセキュアサービスオブジェクトは、さらに実行される同期に対する制御を保つために必要十分である。最大デルタ時間と１日当たり最大日次補正値との使用は、本発明の結果を可能にし、それは、セキュリティデバイスのうちの任意の１つのクロックのドリフトに対する制御である。

本発明では、プライベートサービス固有暗号鍵を有するセキュリティデバイスのみが要求を復号し、署名付き応答を発行することができるように、リソースオーナーのアプリケーションは一般に、最初に、サービス固有通信証明書を取得し、次いで、その要求のすべてを保護するためにその証明書を使用する。

歴史的に、ＨＳＭのようなセキュリティデバイスは、認証のためのセキュリティ関連要素として、時間を使用しない。同じく歴史的に、セキュリティ関連動作から、非セキュリティ関連物理および論理デバイス管理の大部分を分離するやり方がないので、ＨＳＭのすべての管理が、セキュリティオフィサー役割の制御下のままである。

本発明は、クラウドプロバイダテナントなど、サードパーティ顧客がサービスを信頼することを可能にする様式で、ＩａａＳ／ＰａａＳパブリッククラウドプロバイダなど、信頼されていないサービスプロバイダによってデバイスの管理が扱われることを可能にする。本発明は、サードパーティ顧客が、セキュアサービスのセキュリティデバイス部分のうちの１つのクロック値について照会し、同じセキュアサービスのすべての他のセキュリティデバイス部分のクロック値が同期しているという保証を有するための方法を定義する。本発明はまた、消費者が、関与する必要はないが依然としてそれらのサービス／鍵の制御を保持する様式で、プロバイダが、デバイスの追加のコピーを代用して、たとえば、サービスを増大させること、故障したユニットを入れ替えることなどを可能にする。すなわち、消費者は、どのデバイスがそれらのサービスを配信しても、そのクロックが、それらのサービスを作成したのと同じデバイスと同期しているはずであることを確認することができる。

有利な特徴によれば、保護されるセキュアサービスオブジェクトは、セキュアサービスが作成されたときのサービス始動タイムスタンプを含む。

有利には、保護されるセキュアサービスオブジェクトは、ランダムに生成されたクロックインスタンス値を含む。

有利には、保護されるセキュアサービスオブジェクトは、ランダムに生成されたサービス固有暗号鍵と、対応する証明書とをも含む。

サービス固有暗号鍵を有するデバイスのみが、着信要求を復号し、アプリケーションにセキュア応答を発行することができるように、サービス固有暗号鍵および証明書が、リソースオーナーのアプリケーションとセキュリティデバイスとの間の通信を保護するために使用される。

それらの３つの値は、同期しているクロックを有する許可されたデバイスのみが同じ値を有するように、セキュリティデバイス間でセキュアに共有される。このようにして、顧客がクロックインスタンスを信頼するとき、顧客は、そのクロックインスタンスを共有するデバイスのプールを間接的に信頼する。それらの値は、サービスの状態を定義する。

特定の特徴によれば、本方法は、任意の時間において、セキュアサービスの消費者が、サービスのセキュリティデバイス部分の、現在のクロック設定を含むセキュアメッセージを要求するステップを含む。

この実施形態は、プール中のセキュリティデバイスの現在のクロック値の周期的および／または規則的検証を可能にする。

別の特定の特徴によれば、本方法は、任意の時間において、セキュアサービスの消費者が、サービスのセキュリティデバイス部分のクロックインスタンスを含むセキュアメッセージを要求するステップをさらに含む。

これは、プール中のセキュリティデバイスのクロックインスタンスの周期的または規則的検証を補強する。

次いで、リソースオーナーのアプリケーションは、サービスに属する任意のデバイスのクロックインスタンスを信頼し、ファームウェアは、２つのこと、すなわち、サービスのすべてのデバイスが、同じクロックおよびクロックインスタンスを有することと、デバイスが、デバイス上に構成されたクロックインスタンスとは異なるクロックインスタンスを有する要求を拒否することとを確かめる。

２つの最後の特徴を用いて、顧客、リソースオーナーは、有利には、デバイスのクロックの値を正確な外部時間ソースと比較することによって、セキュリティデバイスのクロックインスタンスを信頼することを決定することができる。クロックインスタンス値をさらに検査することによって、セキュリティは補強される。

特定の実装形態によれば、前記方法は、追加のセキュリティデバイスが必要とされるとき、ターゲットにされるセキュリティデバイスからの署名付き加入要求を、セキュアサービスのためにすでにアクティブ化されたセキュリティデバイスにおいて集め、セキュリティデバイスからの署名付き加入要求が、ターゲットにされるセキュリティデバイスのクロックのスナップショットを含む、ステップと、クロックのスナップショットが最大デルタ時間を遵守する場合のみ、ターゲットにされるセキュリティデバイスをセキュアサービスに割り振るステップとを含む。

この実装形態は、新しいセキュリティデバイスを挿入し、一方で、そのクロックとプール中のデバイスのクロックとの同期を保証することを可能にする。

有利には、ターゲットにされるセキュリティデバイスの割振りのステップは、セキュアサービスにすでに割り振られたセキュリティデバイスが、セキュアサービスオブジェクトを含む署名付き回答を、ターゲットにされるセキュリティデバイスに送るステップを含む。

セキュアサービスオブジェクトを送ることは、異なるセキュリティデバイスを同じオブジェクトにバインドすることを可能にする。このオブジェクトがデバイスによって知られていない場合、それはサービス要求を扱うことができないことになる。

さらなる特徴によれば、本方法は、セキュアサービスの暗号化動作が、サービスのセキュリティデバイス部分によって実行されることを要求されるとき、リソースオーナーの要求側セキュリティアプリケーションが、少なくとも、そのセキュアサービスのセキュリティデバイス部分の現在時間とサービスクロックインスタンスとを照会するステップと、セキュリティデバイスのクロックのスナップショットと、その対応するサービスクロックインスタンスとを含む、セキュリティデバイスからの回答を集めるステップと、取得された、セキュリティデバイスのクロックを、正確な時間ソースと比較するステップと、デバイスのクロックが正確な時間ソースに一致する場合、デバイスのクロックインスタンスを信頼するステップと、受信された信頼されたクロックインスタンスを、セキュアサービスに対しての後続の要求中に含めるステップと、デバイスのセキュアサービスオブジェクト上のクロックインスタンスと同じクロックインスタンスを有する要求のみをセキュリティデバイスに受諾させるステップとを含む。

この特徴は、サービスのために実行されるべき任意の機密性の高い動作が、その動作を実行することができるセキュリティデバイスのクロック同期性の前もっての検査に、サブミットされ得ることを保証する。この特徴はまた、リソースオーナーに、適切なクロック設定をもつデバイスのみがセキュアサービスを実行することを許可されるという保証を与える。アプリケーションは、要求をサービスの任意のセキュリティデバイス部分に送り、アプリケーションによって送られたサービスクロックインスタンスが正しい場合のみ、サービス要求を処理するためにセキュリティデバイスに依存する。この特徴を用いて、セキュアサービスに対しての要求は、信頼されたセキュリティデバイスから前もって受信されたサービスクロックインスタンス値を含み、サービスは、このサービスクロックインスタンスが、サービス要求時にこのセキュリティデバイスに記憶されたサービスクロックインスタンスに対応する場合のみ、セキュリティデバイスにおいて実行される。本発明によれば、アプリケーションは、固有のセキュリティデバイスをターゲットにする必要がない。実際、この状況は、リソースオーナーのアプリケーションが、セキュアサービスのどのセキュリティデバイスが要求を扱うことになるか知ることができないので、本発明の根源である。実際、サービスプロバイダのみが、セキュリティデバイスを制御する。

有利な特徴によれば、ポリシーがセキュアサービスオブジェクト中にさらに含まれ、それらのポリシーは、サービスプロバイダからの許可を必要とすることなしに、および／または非アクティブ化され、サービス要求を扱うことができなくなる前に、セキュリティデバイスのクロックがどのくらい変更され得るかを、さらに制御する。

この特徴は、無許可のアプリケーションが、最終顧客に影響を及ぼすであろうそれらのセキュリティデバイスのクロックに対する変更を実行することから、サービスプロバイダを保護する。ポリシーは、実際、デバイスが非アクティブ化される前にデバイスのクロックがどのくらい変更され得るかを制御する。この重要な特徴がなければ、サービスプロバイダは、セキュリティデバイスがプールに加入した後に、セキュリティデバイスのクロックを変更することができるであろう。したがって、ポリシーは、有利には、サービスプロバイダの関与なしにクロックがどのくらい変更され得るかを制御し、同じく、最大日次補正値との関係において、サービスプロバイダが、デバイスを非アクティブ化することなしにクロックをどのくらい更新することができるかを制御する。しきい値は、最大回数または最大オフセットである。

本発明はまた、セキュアサービスにおける暗号化動作を実行するように構成されたセキュリティデバイスのプールに属するように構成されたセキュリティデバイスに関し、
前記セキュリティデバイスが、リソースオーナーおよびそのセキュリティアプリケーションがプールの完全性を検査することを可能にするため、および、セキュアサービスプロバイダがセキュリティデバイスのプールを管理することを可能にするために、時間ベースの認証方式をサポートするファームウェアを有し、
前記ファームウェアは、ターゲットセキュリティデバイスのクロックを正確な時間値に設定することと、プールの２つのデバイス間のドリフトを限定する、最大デルタ時間と１日当たり最大日次補正値とを定義することとを行い、前記ファームウェアが、さらに、任意のセキュリティデバイスからの、このセキュリティデバイスのクロックのスナップショットを含む署名付き加入要求を受信し、処理することと、最大デルタ時間と１日当たり最大日次補正値とを使用して、このセキュリティデバイスのクロックのスナップショットをそれ自体の時間値と比較することとができる。

そのようなセキュリティデバイスは、本発明によるセキュアサービスを形成するための基本エンティティである。

本発明はまた、本発明によるセキュリティデバイスの信頼されたプールに関し、前記信頼されたプールがセキュアサービスを実装し、信頼されたプールの前記セキュリティデバイスが同じセキュアサービスオブジェクトを共有し、プール中に割り振られた第１のデバイスが、セキュアサービスオブジェクトを作成する責任を負い、プールに加入する他のセキュリティデバイスが、セキュリティデバイス間のセキュアプロトコルの加入要求を使用して、セキュアサービスオブジェクトのコピーを受信し、前記セキュアサービスオブジェクトが、リソースオーナーのセキュリティアプリケーションとサービスの任意のセキュリティデバイス部分との間の通信を保護するために使用される、少なくともサービスクロックインスタンスとサービス固有暗号鍵と証明書とを含んでいる。

本発明では、プライベートサービス固有暗号鍵を有するセキュリティデバイスのみが要求を復号し、署名付き応答を発行することができるように、リソースオーナーのアプリケーションは一般に、最初に、サービス固有通信証明書を取得し、次いで、その要求のすべてを保護するためにその証明書を使用する。

上記および関連する目的を達成するために、１つまたは複数の実施形態は、以下で十分に説明し、特に特許請求の範囲で指摘する特徴を備える。

以下の説明および添付の図面は、いくつかの例示的な態様を詳細に記載し、実施形態の原理が採用され得る様々なやり方のうちのほんのいくつかを示す。図面とともに考慮されるとき、以下の発明を実施するための形態から、他の利点および新規の特徴が明らかになり、開示される実施形態は、すべてのそのような態様およびそれらの均等物を含むことが意図される。

本発明のコンテキストを概略的に表す図である。 本発明の方法による、セキュアサービスの作成の時系列図である。 セキュアサービスについての新しいセキュリティデバイスの登録の時系列図である。 セキュアサービスの各セキュリティデバイス内のクロックの維持の時系列図である。 リソースオーナーの消費の時系列図である。 本発明のセキュリティデバイスを概略的に示す図である。

本発明のより完全な理解のために、次に、本発明は添付の図面を参照しながら詳細に説明される。発明を実施するための形態は、本発明の好ましい実施形態として考えられるものを示し、説明する。形態または詳細における様々な修正および変更が、本発明の趣旨から逸脱することなく容易に行われ得ることをもちろん理解されたい。したがって、本発明が、本明細書で図示および説明される厳密な形態および詳細に限定されず、本明細書で開示され、以下の特許請求の範囲で請求される本発明の全体よりも狭いものにも限定されないことが意図される。同じ要素が、異なる図面において同じ参照符号を用いて指定されている。明快のために、本発明の理解に有用である要素およびステップのみが、図面に示され、説明される。

図１は、本発明のコンテキストを示す。セキュアサービスは、サービスプロバイダのサービス管理者ＡＤＭによってユーザに提案されることが意図される。このサービスが実装されるために、サービスプロバイダ構内にいる人間である、管理者ＡＤＭは、セキュリティデバイスＳＤをセキュアに動作させる必要がある。本発明は、正確だが非セキュアな時間ソースＵＴＳを使用する。

図２は、本発明によって、サービスがどのように作成されるかを示す。最初に、ステップＳ１において、セキュアサービスの管理者ＡＤＭが、セキュアサービスの形成を開始するためにセキュリティデバイスＳＤ１に接触する。それは、ステップＳ２において、セキュリティデバイスＳＤ１が、信用できる時間ソースＵＴＳによって提供された時間Ｔを使用してそのクロックを設定することを必要とする。

サービスプロバイダＡＤＭは、したがって、ステップＳ３において、そのクロックが信用できる時間ソースＵＴＳに設定されると、サービスポリシーＰをプッシュすることにより第１のデバイスＳＤ１をセキュアサービス内に割り振ることによって、セキュアサービスをセットアップする。次いで、ステップＳ４において、サービスはアクティブ化される。

これは、ステップＳ５におけるセキュアサービスオブジェクトＳＳＯの作成につながる。内部セキュアサービスオブジェクトＳＳＯは、サービスの状態と、有利には、ポリシーとを定義する。これは、サービスプロバイダが、このセキュリティデバイスＳＤ１上のセキュアサービスの作成を生じる。サービスの状態は、有利には、セキュアサービスオブジェクトＳＳＯ中のデータ中の、サービスが作成されたときのタイムスタンプと、ランダムに生成されたクロックインスタンス値とサービス固有暗号鍵と証明書とを含む。セキュアサービスオブジェクトＳＳＯポリシーは、最大デルタ時間値ＭＤＴと最大日次補正値ＭＤＣとを含む。セキュアサービスオブジェクトＳＳＯは、任意のエンティティ、人間またはアプリケーションが恣意的に変更するのを防ぐ様式で、セキュリティデバイスＳＤ１によって内部で維持される。

図３は、セキュリティデバイスＳＤ２をセキュアサービスに追加するプロセスを概略的に示す。サービスプロバイダ管理者ＡＤＭは、２つのデバイスのクロックが同期していることを保証するプロセスを通して、追加のセキュリティデバイスＳＤ２をサービスに追加する。この目的で、サービスプロバイダＡＤＭは、サービスポリシーにおいて、最大デルタ時間ＭＤＴと２つのデバイス間のドリフトを限定する１日当たり最大日次補正ＭＤＣ値とを、前もって定義する。

次いで、図３に示されるように、最初のステップＳ１０において、追加されるべきセキュリティデバイスＳＤ２が、そのクロックを正確な信頼されていない時間値ＵＴＳに設定する。次いで、ステップＳ１１において、セキュリティデバイスＳＤ２は、そのクロックＴ２のスナップショットを、プロバイダＡＤＭによってセキュアサービスに前もって挿入された別のセキュリティデバイスＳＤ１に、署名付き加入要求（ＲＥＱｊ（Ｔ２））Ｋ２中で送る。

並行して、ステップＳ１２において、セキュアサービス内に追加されるべきセキュリティデバイスＳＤ２が、時間ベースカウンタｔを開始する。

加入要求（ＲＥＱｊ（Ｔ２））Ｋ２は、限定された経過時間内にセキュリティデバイスＳＤ１において配信されることになる。ステップＳ１３において、追加されるべきセキュリティデバイスＳＤ２の時間Ｔ２が、最大デルタ時間ＭＤＴよりも大きい量だけ、前もって挿入されたセキュリティデバイスＳＤ１のクロックと異なることが検出された場合、セキュリティデバイスＳＤＡ１は、要求を拒否し、要求側セキュリティデバイスに通知するための信号Ａｂが、セキュリティデバイスＳＤ２に送られる。

時間Ｔ２が、セキュリティデバイスＳＤ１のクロックと比較して最大デルタ時間ＭＤＴ内にある場合、セキュリティデバイスＳＤ１は、セキュアサービスオブジェクトＳＳＯとその現在時間Ｔ１とを含む署名付き応答ＡＮＳｊ（ＳＳＯ，Ｔ１）Ｋ１を作成する。この回答は、ステップＳ１４において、セキュリティデバイスＳＤ２に送られる。

次いで、ステップＳ１５において、追加されるべきセキュリティデバイスＳＤ２は、応答シグネチャと、その時間ベースカウンタｔが、管理者ＡＤＭによって前もって定義された最大デルタ時間ＭＤＴを超えないこととを検証する。

最大デルタ時間ＭＤＴを超える場合、したがって、最大時間が満了した場合、加入要求は中止される（Ａｂ）。超えない場合、ステップＳ１６において、セキュリティデバイスＳＤ２は、誤差を最小限に抑えるために、その時間Ｔ２を、ソースデバイスのクロックＴ１にその時間ベースカウンタｔの１／２を加えたものに調節し、セキュリティデバイスＳＤ２は、受信されたセキュアサービスオブジェクトＳＳＯを記憶する（ＳＴ（ＳＳＯ））。

ここで、最大デルタ時間ＭＤＴは、プロバイダが、サイクルするデバイスを、大きいレートで時間的にそれらを前方にまたは後方にスライドさせようとして、シーケンシングするのを防ぐために、十分に小さくなければならないことに留意されたい。

図４は、本発明により、クロックがどのように維持されるかを概略的に示す。実際、一旦、セキュリティデバイスＳＤｉが、同期しているクロックを伴ってセキュアサービスにおいて動作していると、セキュリティデバイスのファームウェアは、ローカルサービスがそのクロックＴｉを周期的に、ただし最大日次補正値内でのみ、調節することを可能にする。この値は、クロックＴｉが、極めて長い期間、たとえば１０年にわたって、実時間から数分よりも多くスライドするのを防ぐために設定される。

クロック維持プロセスは、第１のステップＳ２０で開始し、セキュリティデバイスＳＤｉがタイマーｔを開始する。このタイマーｔは、異常な時間ドリフトが発生しないことを検査するために使用される。次いで、ステップＳ２１において、セキュリティデバイスＳＤｉは、そのクロックＴｉを正確な信頼されていない時間ＴソースＵＴＳに更新する（ＵｐＤ）。次いで、デバイスのファームウェアは、ステップＳ２２において、その日の累積デルタが、ポリシーにおいて定義された最大日次補正ＭＤＣを超えるかどうかを検査する。最大日次補正ＭＤＣを超える場合、セキュリティデバイスは、セキュアサービスに対して非アクティブ化される（ＤｅＡｃｔ）。他の場合、ステップＳ２３において、ファームウェアは、セキュリティデバイスＳＤｉのクロックＴｉを調節し（ＡＤＪ）、累積日次デルタＤを更新する（ＵｐＤ）。

図５は、リソースオーナー、一般にセキュリティアプリケーションが、デバイスのプールからのサービスを消費するためのメッセージ交換を概略的に示す。

セキュアサービスを使用する前に、リソースオーナーのセキュリティアプリケーションＡｐｐが、サービス固有通信証明書を取得し、さらに、サービスに送られるすべての要求を保護するためにこれらの証明書を使用する。

また、セキュアサービスを使用する前に、リソースオーナーのセキュリティアプリケーションＡｐｐが、サービスのセキュリティデバイスＳＤａ部分のサービスクロックおよびポリシー構成を要求する。

実際、本発明では、任意の時間において、リソースオーナーＡｐｐが、セキュリティデバイスの現在のクロック設定Ｔａと、有利にはポリシーＰａと、有利にはサービスクロックインスタンスＳＣＩａとを含む、セキュアメッセージ（Ｔａ，Ｐａ，ＳＣＩａ）Ｋａを要求することによって、サービスのクロックを確認することができる。それはまた、正確な信頼されていない時間ソースＵＴＳから現在時間を要求する。リソースオーナーは、サービス始動タイムスタンプおよびサービスクロックインスタンス値をさらに記憶する。

これらの値は、リソースオーナーＡｐｐに、サービスのクロックが実世界に対して正確であることを検証させることができる。また、それは、リソースオーナーＡｐｐに、サービスの経過期間（ａｇｅ）とセキュリティポリシーにおいて定義された許容差とが与えられれば、デバイスのプール全体にわたる最大偏差を計算させることができる。サービスによって取得されたクロック値が正確であり、ポリシーがリソースオーナーＡｐｐにとって許容できる場合、リソースオーナーＡｐｐは、サービスが信頼されると決定し、取得されたサービスクロックインスタンスを、サービスに送られるすべての後続の要求中に含める。

セキュリティデバイスＳＤａから受信されるメッセージは、デバイス製造業者の鍵によって署名される。

消費プロセスは、ステップＳ３０において、セキュリティアプリケーションＡｐｐが、クロックＴａとポリシーＰａとサービスクロックインスタンスＳＣＩａとに対しての要求ＲＥＱ（Ｔａ，Ｐａ，ＳＣＩａ）を任意のアクティブセキュリティデバイスＳＤａに送るための第１のステップを含む。一方、それは、ステップＳ３１において、正確な信頼されていない時間ソースＵＴＳから時間Ｔを得る。次いで、ステップＳ３２における、アクティブデバイスＳＤａのクロックＴａを含む、アクティブセキュリティデバイスの署名付き回答（Ｔａ，Ｐａ，ＳＣＩａ）Ｋａの受信後に、セキュリティアプリケーションＡｐｐは、ステップＳ３３において、アクティブセキュリティデバイスＳＤａから受信されたクロックＴａと比較して、クロック値Ｔを検査する。時間Ｔが、許容できる許容差内でセキュリティデバイスＳＤａの時間Ｔａに一致しない場合、サービス要求は中止される（Ａｂ）。そうではなく、時間ＴがアクティブデバイスのクロックＴａに対応する場合、ステップＳ３４において、サービスクロックインスタンス値ＳＣＩａは、信頼されるものとして保存される（ＳＴ（ＳＣＩ））。

次いで、ステップＳ３５において、セキュリティアプリケーションＡｐｐが、トランザクションＴＲＡＮＳをサービスにサブミットするとき、このサブミッションは、セキュアサービスのためにアクティブにされるセキュリティデバイスＳＤａに達する。サブミッションは、前もって記憶されたサービスクロックインスタンス値ＳＣＩをセキュアに含む。セキュリティデバイスＳＤａは、ステップＳ３６において、それ自体のクロックインスタンス値ＤＣＩと比較して、サービスクロックインスタンス値ＳＣＩを検査する。セキュリティデバイスＳＤａは、供給されたサービスクロックインスタンスＳＣＩが、アクティブデバイスがそのセキュアサービスオブジェクトＳＳＯ中に有するサービスクロックインスタンスＳＣＩａに一致する場合のみ、サービスを実行する。この一致は、ステップＳ３６において検査される。それが当てはまらない場合、手動許可に対しての要求ＲＥＱ（ＭＡ）が、リソースオーナーセキュリティアプリケーションＡｐｐに返される。これは、破局的な災害の場合、サービスを復元することを可能にする。実際、たとえそれが発生したとしても、リソースオーナーは、異なるサービスクロックインスタンス値ＳＣＩをもつセキュリティデバイスによるサービス上でのリソースオーナーのリソースの使用を、手動で許可することができる。この許可は、リソースを新しいサービスクロックインスタンス値ＳＣＩにバインドすることになる。

クロックインスタンスが一致する場合、ステップＳ３７において、トランザクションＴＲＡＮＳは、リソースオーナーのリソースを使用してアクティブセキュリティデバイスＳＤａによって実行される。次いで、トランザクションの結果ＲＥＳが、ステップＳ３８において、リソースオーナーセキュリティアプリケーションＡｐｐに返される。

図６は、本発明のセキュリティデバイスＳＤを概略的に示す。このデバイスは、実際、図６上のクラウドによって概略的に表されている信頼されたプールＴｒＰの一部である。この信頼されたプールＴｒＰは、図６上で図示および詳述されるセキュリティデバイスを含む。

このセキュリティデバイスＳＤは、少なくとも１つのセキュアサービスによって使用されるために暗号化動作を実行することが可能な暗号モジュールＣＭと、任意の関連する値を記憶するためのメモリＭＥＭとを含む。セキュリティデバイスＳＤは、時間ベースの認証方式をサポートするファームウェアＦＷをも含み、セキュアサービスプロバイダが、デバイスの信頼されたプールＴｒＰを管理することを可能にし、リソースオーナーが、デバイスのプールＴｒＰのクロックの完全性を検査すること可能にする。セキュリティデバイスは、クロックＣＬＫをさらに含む。前記ファームウェアＦＷは、セキュリティデバイスのクロックＣＬＫを正確な時間値に設定し、プールＴｒＰの２つのデバイス間のドリフトを限定する最大デルタ時間値と１日当たり最大日次補正値とを定義する。２つの最新の値が、メモリＭＥＭに記憶される。ファームウェアＦＷは、さらに、信頼されたプールＴｒＰ中の任意の他のセキュリティデバイスから、このセキュリティデバイスのクロックのスナップショットを含む署名付き加入要求を受信および処理し、最大デルタ時間と１日当たり最大日次補正値とを使用して、このセキュリティデバイスのクロックのスナップショットをそれ自体の時間値と比較することが可能である。

上記の発明を実施するための形態において、例として、本発明が実施され得る特定の実施形態を示す添付の図面に対して参照が行われる。これらの実施形態は、当業者が本発明を実施することを可能にするために十分詳細に説明される。したがって、上記の発明を実施するための形態は、限定的な意味でとられるべきでなく、本発明の範囲は、添付の特許請求の範囲によってのみ定義され、特許請求の範囲と題された均等物の全範囲とともに、適切に解釈される。

Claims (13)

1. サービスプロバイダ（ＡＤＭ）によって、セキュアサービスにおける暗号化動作を実行するように構成されたセキュリティデバイス（ＳＤｉ）の信頼されたプールを作成するための方法であって、
   サービスプロバイダ（ＡＤＭ）が、第１のデバイス（ＳＤ１）をサービス内に割り振ることによって、セキュアサービスをセットアップするステップと、第１のセキュリティデバイスのクロックを信用できる時間ソース（ＵＴＳ）に設定するステップ（Ｓ２）と、リソースオーナーのセキュリティアプリケーション（Ａｐｐ）とセキュアサービスのセキュリティデバイス（ＳＤ）部分との間の通信を保護するために使用される、少なくともサービスクロックインスタンス（ＳＣＩ）とサービス固有暗号鍵と証明書とを定義する内部セキュアサービスオブジェクト（ＳＳＯ）を作成し（Ｓ５）、前記セキュアサービスオブジェクト（ＳＳＯ）が、セキュリティデバイス（ＳＤ１）によって内部で維持され、任意のサービスプロバイダがそれを恣意的に変更するのを防ぐ、ステップと、
   追加のセキュリティデバイス（ＳＤｉ）が必要とされるとき、サービスプロバイダ（ＡＤＭ）が、ターゲットセキュリティデバイスのクロックを正確な時間値（ＵＴＳ）に設定し（Ｓ１０）、セキュアサービスオブジェクト（ＳＳＯ）において、プールの２つのデバイス間のドリフトを限定する最大デルタ時間（ＭＤＴ）と１日当たり最大日次補正（ＭＤＣ）値とを定義することによって、２つのセキュリティデバイスのクロック（Ｔｉ）が同期していることを保証することを通して、追加のセキュリティデバイス（ＳＤｉ）をサービスに追加するステップと
   を含む、方法。
2. 保護されるセキュアサービスオブジェクト（ＳＳＯ）が、セキュアサービスが作成されたときのサービス始動タイムスタンプを含む、請求項１に記載の方法。
3. 保護されるセキュアサービスオブジェクトが、ランダムに生成されたクロックインスタンス値を含む、請求項１に記載の方法。
4. 保護されるセキュアサービスオブジェクトが、ランダムに生成されたサービス固有暗号鍵と、対応する証明書とをも含む、請求項１に記載の方法。
5. 任意の時間において、セキュアサービスの消費者が、サービスのセキュリティデバイス部分の、現在のクロック設定を含むセキュアメッセージを要求するステップをさらに含む、請求項１に記載の方法。
6. 任意の時間において、セキュアサービスの消費者が、サービスのセキュリティデバイス部分のクロックインスタンスを含むセキュアメッセージを要求するステップをさらに含む、請求項１に記載の方法。
7. 前記方法が、追加のセキュリティデバイス（ＳＤ２）が必要とされるとき、ターゲットにされるセキュリティデバイス（ＳＤ２）からの署名付き加入要求を、セキュアサービスのためにすでにアクティブ化されたセキュリティデバイス（ＳＤ１）において集め（Ｓ１１）、セキュリティデバイスからの署名付き加入要求が、ターゲットにされるセキュリティデバイスのクロック（Ｔ２）のスナップショットを含む、ステップと、クロックのスナップショット（Ｔ２）が最大デルタ時間（ＭＤＴ）を遵守する場合のみ、ターゲットにされるセキュリティデバイス（ＳＤ２）をセキュアサービスに割り振るステップとを含む、請求項１から６のいずれか一項に記載の方法。
8. ターゲットにされるセキュリティデバイス（ＳＤ２）の割振りのステップが、セキュアサービスにすでに割り振られたセキュリティデバイスが、セキュアサービスオブジェクト（ＳＳＯ）を含む署名付き回答を、ターゲットにされるセキュリティデバイスに送るステップ（Ｓ１４）を含む、請求項７に記載の方法。
9. 前記方法が、セキュアサービスの暗号化動作が、サービスのセキュリティデバイス部分（ＳＤａ）によって実行されることを要求されるとき、リソースオーナーの要求側セキュリティアプリケーション（Ａｐｐ）が、少なくとも、そのセキュアサービスのセキュリティデバイス部分の、現在時間（Ｔａ）とサービスクロックインスタンス（ＳＣＩａ）とを照会するステップ（Ｓ３０）と、セキュリティデバイスのクロック（Ｔａ）のスナップショットと、サービスクロックインスタンス（ＳＣＩａ）とを含む、セキュリティデバイス（ＳＤａ）からの回答を集めるステップ（Ｓ３２）と、取得された、ターゲットにされるセキュリティデバイスのクロック（Ｔａ）を、正確な時間ソース（Ｔ）と比較するステップと、デバイスのクロック（Ｔａ）が正確な時間ソース（Ｔ）に一致する場合、デバイスのサービスクロックインスタンス値（ＳＣＩａ）を信頼するステップと、受信された信頼されたサービスクロックインスタンス値（ＳＣＩ）を、セキュアサービスに対しての後続の要求中に含めるステップと、セキュリティデバイスのセキュアサービスオブジェクト上のクロックインスタンスと同じクロックインスタンスを有する要求のみを、セキュリティデバイスに受諾させるステップとをさらに含む、請求項１から８のいずれか一項に記載の方法。
10. ポリシー（Ｐ）がセキュアサービスオブジェクト中にさらに含まれ、それらのポリシーが、さらに、サービスプロバイダ（ＡＤＭ）からの許可を必要とすることなしに、および／または非アクティブ化され、サービス要求を扱うことができなくなる前に、セキュリティデバイスのクロックがどのくらい変更され得るかを制御する、請求項１から９のいずれか一項に記載の方法。
11. セキュアサービスのための暗号化動作を実行するように構成されたセキュリティデバイスの信頼されたプール（ＴｒＰ）に属するように構成されたセキュリティデバイス（ＳＤ）であって、
    前記セキュリティデバイス（ＳＤ）は、リソースオーナーおよびそのセキュリティアプリケーション（Ａｐｐ）が、プール（ＴｒＰ）の完全性を検査することを可能にするため、および、セキュアサービスプロバイダがセキュリティデバイスのプール（ＴｒＰ）を管理することを可能にするために、時間ベースの認証方式をサポートするファームウェア（ＦＷ）を有し、
    前記ファームウェア（ＦＷ）が、リソースオーナーのセキュリティアプリケーション（Ａｐｐ）とセキュアサービスのセキュリティデバイス（ＳＤ）部分との間の通信を保護するために使用される、少なくともサービスクロックインスタンス値とサービス固有暗号鍵と証明書とを定義し、少なくとも内部セキュアサービスオブジェクト（ＳＳＯ）を記憶し、セキュリティデバイスのクロック（ＣＬＫ）を正確な時間値に設定し、および、プール（ＴｒＰ）の２つのセキュリティデバイス間のドリフトを限定する、最大デルタ時間値と１日当たり最大日次補正値とを定義し、
    前記ファームウェア（ＦＷ）が、さらに、任意のセキュリティデバイス（ＳＤ）からの、このセキュリティデバイスのクロックのスナップショットを含む署名付き加入要求を受信し、処理することと、最大デルタ時間と１日当たり最大日次補正値とを使用して、このセキュリティデバイスのクロックのスナップショットをそれ自体の時間値と比較することと、両方の時間値が合った場合、加入要求に同意することができる、
    セキュリティデバイス（ＳＤ）。
12. 前記ファームウェア（ＦＷ）が、一旦、加入要求が同意されると、セキュアサービスオブジェクト（ＳＳＯ）をターゲットにされるセキュリティデバイス（ＳＤｉ）に送るように構成された、請求項１１に記載のセキュリティデバイス（ＳＤ）。
13. 請求項１１および１２のいずれか一項に記載のセキュリティデバイス（ＳＤ）の信頼されたプール（ＴｒＰ）であって、前記信頼されたプール（ＴｒＰ）がセキュアサービスを実装し、信頼されたプール（ＴｒＰ）の前記セキュリティデバイス（ＳＤ）が同じセキュアサービスオブジェクト（ＳＳＯ）を共有し、信頼されたプール（ＴｒＰ）中に割り振られた第１のデバイス（ＳＤ１）が、セキュアサービスオブジェクト（ＳＳＯ）を作成する責任を負い、信頼されたプール（ＴｒＰ）に加入する他のセキュリティデバイス（ＳＤｉ）が、セキュリティデバイス（ＳＤｉ）間のセキュアプロトコルの加入要求を使用して、セキュアサービスオブジェクト（ＳＳＯ）のコピーを受信し、前記セキュアサービスオブジェクト（ＳＳＯ）が、リソースオーナーのセキュリティアプリケーション（Ａｐｐ）とセキュアサービスの任意のセキュリティデバイス（ＳＤｉ）部分との間の通信を保護するために使用される、少なくともサービスクロックインスタンス（ＳＣＩ）とサービス固有暗号鍵と証明書とを含んでいる、信頼されたプール（ＴｒＰ）。

Images