JP7025101B2 - 暗号オブジェクトを管理する方法、コンピュータ実装方法、システムおよびプログラム - Google Patents

Description

本発明は、一般に、コンピュータ化されたクライアントと対話するハードウェア・セキュリティ・モジュール（ＨＳＭ：ｈａｒｄｗａｒｅ ｓｅｃｕｒｉｔｙ ｍｏｄｕｌｅ）を含むシステムにおいて暗号オブジェクトを管理するためのコンピュータ実装方法、ならびに関連するコンピュータ化されたシステムの分野に関する。より詳細には、ＨＳＭの鍵管理システムにおけるエントロピーの枯渇を緩和する（すなわち、延期する、または防止さえする）ことを目的とする方法を対象とする。

鍵管理は暗号システムにおける暗号鍵の管理に関連し、これには鍵の生成、記憶、使用、破棄、および置換などの操作が含まれる。鍵管理には、特定の暗号プロトコル、鍵サーバ、および他の手順が必要となる。

一般に、鍵管理システム（ＫＭＳ：ｋｅｙ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）は、クライアント（デバイス、アプリケーション）用の暗号鍵を生成し、配布し、より一般的には管理するシステムである。ＫＭＳはセキュリティのいくつかの側面に対処し得、これらは、安全な鍵の生成から、安全な鍵の取り扱いおよびクライアントへの記憶までに及ぶ。ＫＭＳは典型的には鍵の生成、配布、および置換のためのバックエンド機能を含む。さらに、鍵の挿入、クライアント・デバイスでの鍵の記憶および管理のための特定のクライアント機能を統合し得る。

モノのインターネットおよびクラウド・コンピューティングの発展に伴い、コネクテッド・デバイスおよびアプリケーションのセキュリティにとって、鍵管理および鍵管理システムはますます重要になっている。

ハードウェア・セキュリティ・モジュール（ＨＳＭ）は、暗号操作（すなわち、暗号処理）および強力な認証を実行するための鍵を保護および管理する物理コンピューティング・デバイスである。そのようなモジュールは、典型的にはコンピュータ（たとえば、ネットワーク・サーバ）に直接取り付けられる物理デバイス（たとえば、プラグイン・カード）である。

ＨＳＭは典型的には、改ざんおよびバス・プロービングを防ぐための安全な暗号プロセッサ・チップを備える。一般に、ＨＳＭは、改ざんの証拠および改ざん耐性を提供する（たとえば、改ざん検出時に鍵を削除する）ように設計され得る。ＨＳＭシステムは、管理している鍵を安全にバックアップできる場合がある。ＨＳＭは典型的にはクラスタ化されて高い可用性を提供するので、最新のデータセンタ環境の高可用性要件に適合している。とりわけ、オンライン・バンキング・アプリケーションおよび公開鍵インフラストラクチャなどのインフラストラクチャの一部を形成し得る。

機能の中でもとりわけ、ＨＳＭは、典型的には物理的過程を利用して十分なランダム性のソース（エントロピーによって特徴付けられるもの）を生成する特定のハードウェアに依存し得る。使用可能なランダム性は、ランダムな鍵の生成に使用される。

そのようなＨＳＭでは、乱数生成（ＲＮＧ：ｒａｎｄｏｍ ｎｕｍｂｅｒ ｇｅｎｅｒａｔｉｏｎ）処理は、ＨＳＭのエントロピー・プールで使用可能なエントロピーの量によって制限される。エントロピー・プールが枯渇してしまった場合（たとえば、高負荷時）、ＲＮＧをそれ以上実行できなくなる。そのような場合、鍵および初期化ベクトル（ＩＶ：ｉｎｉｔｉａｌｉｚａｔｉｏｎ ｖｅｃｔｏｒ）をそれ以上生成できなくなり、それらの生成は、追加のエントロピーが使用可能になるまで遅延する。このように、高負荷時にはＫＭＳのパフォーマンスが損なわれ得る。

本発明の態様によれば、本発明は、鍵管理システムにおいて暗号オブジェクトを管理するためのコンピュータ実装方法として具現化される。このシステムは、１つまたは複数のハードウェア・セキュリティ・モジュール、すなわち、ＨＳＭのセットと、（実際にはクライアントと対話する）ユーザに代わってＨＳＭと対話するクライアントと、を含む。この方法は、セットの各ＨＳＭについて、各ＨＳＭのエントロピー・プールもしくは負荷またはその両方を監視することを含む。ＨＳＭのエントロピー・プールとは、暗号オブジェクトを生成するためにこのＨＳＭで使用可能なエントロピーを指す。ＨＳＭにおいて誘導される負荷は、暗号オブジェクトを取得するためにユーザがクライアントと対話することから生じる負荷である。監視されているエントロピー・プールもしくは負荷またはその両方に応じて、前記各ＨＳＭにおいて暗号オブジェクトが生成される。したがって、そのようなオブジェクトが生成される程度は、監視されているエントロピー・プールもしくは負荷またはその両方に依存する。

本手法により、ＨＳＭにおいてエントロピーがまだ使用可能である場合に、クライアントからの現在のニーズを超えて暗号オブジェクトを蓄積することが可能になる。その後、高負荷によってエントロピーが枯渇してしまった場合に、蓄積されたオブジェクトを使用して、依然として要求に十分にサービス提供することができる。したがって、本解決策により、安全な環境（ＨＳＭ）において、パフォーマンスを確保しながら（高負荷でも暗号材料がまだ配布される）、潜在的なエントロピーの枯渇の問題を緩和（防止できない場合は、延期など）することが可能になる。

各ＨＳＭにおいて誘導される負荷を監視することができる。実際に、エントロピーが主要なボトルネック・リソースであると仮定すると、現在の残存エントロピーの指標として、ＨＳＭにおける負荷を監視するだけで十分である。そのような場合、各ＨＳＭにおいて暗号オブジェクトが生成される程度は、監視されている負荷に依存する。たとえば、監視されている負荷が所与の負荷閾値を下回った場合、そのようなオブジェクトが生成される速度が増加する。

上述のように、本方法によれば、暗号オブジェクトは、将来の使用のために暗号オブジェクトの予備を蓄積するように、ＨＳＭにおいて生成することができる。さらに、生成されたオブジェクトの安全な環境を確保するために、生成されたオブジェクトの少なくとも一部（たとえば、ラップ解除された暗号鍵）をＨＳＭに記憶するように指示することができる。

生成されるオブジェクトはとりわけ、暗号鍵（対称鍵もしくは非対称鍵またはその両方を含む）と、初期化ベクトルと、を含み得る。クライアントの要求に応じて、続いてＨＳＭにおいて暗号操作を実行することができ、これにより初期化ベクトルが、データ暗号化などのための暗号プリミティブへの入力として、暗号鍵と共に使用される。

生成された暗号鍵および初期化ベクトルは、たとえば、少なくとも一時的にＨＳＭに記憶され得る。加えて、生成処理は、各ＨＳＭに存在するマスター鍵に基づいて、ＨＳＭにおいて生成された鍵をラップして、ラップされた鍵を取得するための鍵ラップ処理を含むことができる。次いで、ラップされた鍵を、後で（たとえば、クライアントの、またはその付近の）外部記憶媒体に記憶するために、（たとえば、クライアントに）供給することができる。

ここで、ＨＳＭの限られた記憶能力に対処するための適応的な管理が考えられる。すなわち、実施形態では、各ＨＳＭのメモリ容量が監視される。たとえば、暗号オブジェクトを生成する前などにこの容量を継続的にチェックすることができる。このようにして、生成されたオブジェクトを全て維持するか、外部に記憶するかを適切に判断することができる。

すなわち、メモリ容量が十分である場合、たとえば、所与の閾値よりも大きい場合、以前に供給されたラップされた鍵に対応する（ラップ解除された）鍵は、必ずしも削除される必要はない。

このように、暗号操作を実行するクライアントの１つから要求を後で受信した場合（この要求には、以前に供給されたラップされた鍵またはその識別子が付属する）、ＨＳＭのうちの１つにおいて対応する鍵を見つけようとするだけで十分であり得る。次いで、要求された暗号操作は、見つかった鍵に基づいて、ＨＳＭのうちの前記１つにおいて実行することができる。

ここで、チェックされた監視されているメモリ容量が不十分である場合（たとえば、所与の閾値よりも小さい場合）、後で外部記憶媒体に記憶するために、ＨＳＭにおいて生成された暗号オブジェクトが供給され得、対応する暗号オブジェクトがこのＨＳＭから削除される。

供給されるオブジェクトは、典型的にはラップされた鍵を含み、それによって対応する暗号材料をＨＳＭから削除することができる。削除される材料はとりわけ、たとえば、ラップされた状態もしくはラップ解除された状態またはその両方の暗号鍵を含み得る。加えて、供給される暗号材料は初期化ベクトルも含むことができるので、そのような初期化ベクトルもＨＳＭから削除され得る。

これにより、ＨＳＭ上のメモリスペースを節約することが可能になる。それにもかかわらず、以下で説明する本発明の実施形態によれば、削除された材料は、必要に応じて復元することができる。

たとえば、クライアントは暗号操作を実行する要求を送信し得、要求はＨＳＭから以前に供給されたラップされた鍵を含む。次いで、そのような要求を受信した場合、ＨＳＭは、対応する鍵を復元するために、このＨＳＭに存在するマスター鍵に従って、受信したラップされた鍵をラップ解除することに進み得る。したがって、要求された暗号操作は、ＨＳＭにおいて、復元された鍵に基づいて実行することができる。

実際には、要求（ラップされた鍵が付属する）を受信した場合、まずＨＳＭの１つにおいて対応する鍵を見つけようとし、そのような鍵を見つけられなかった場合、効率上の理由から鍵のラップ解除に進み得る。

監視されているメモリ容量は、前記各ＨＳＭにおいて、前記各ＨＳＭのキャッシュ・メモリとして構成されるハードウェア・メモリ・デバイスの容量とすることができる。

実施形態では、暗号オブジェクトは、監視されているエントロピー・プールもしくは負荷またはその両方のパラメータ化された関数に従って、ＨＳＭにおいて生成される。この関数はさらに、関数の１つまたは複数のパラメータに関する受信した入力に従って更新され得る。

また、本方法は、対応する統計を取得するように、ＨＳＭにおいて生成済みの暗号オブジェクトを監視することを含むことができる。したがって、そのような統計を参照データ（たとえば、達成すべき目標）と比較することにより、続いて、そのような比較の結果に基づいて、ＨＳＭにおいて暗号オブジェクトを生成することが可能になる。

本明細書に記載の本発明の実施形態は、ＨＳＭにおける負荷の監視に少なくとも部分的に基づくことができる。しかしながら、変形例では、主に各ＨＳＭのエントロピー・プールを監視し得る。その場合、ＨＳＭにおいて暗号オブジェクトが生成される程度は、負荷ではなく、監視されているエントロピー・プールに依存する。また、監視されているエントロピー・プールが所与のエントロピー閾値を超えた場合に、そのようなオブジェクトが生成される速度が増加する。

ここで、デュアル方式が考えられる。たとえば、ＨＳＭにおいて誘導される負荷を主に監視し得るが、ＨＳＭにおける現在の負荷を現在のエントロピー値に適合させるように、並行して（たとえば、残存エントロピーの推定値に基づいて）各ＨＳＭのエントロピー・プールを監視し得る。すなわち、監視されているエントロピー・プールの現在の値に対してこのＨＳＭにおいて誘導される負荷を調整するために、ＨＳＭにおいて暗号オブジェクトが（可能なときに可能な限り）蓄積され得る。同じ方式を各ＨＳＭにおいて並行して実装することができる。このようにして、グローバルなＨＳＭの負荷をグローバルな現在のエントロピーに対して調整することができる。

全ての場合において、ＨＳＭのいずれかのエントロピー・プールの潜在的なエントロピーの枯渇を緩和するように暗号オブジェクトを生成するため本方法を使用し得る。

他の態様によれば、本発明は、暗号オブジェクトを管理するためのコンピュータ化されたシステム、たとえば鍵管理システムとして具現化される。システムは、１つまたは複数のＨＳＭのセットと、ユーザに代わってＨＳＭのセットと対話するように構成されるクライアントと、を含む。一方で、本方法と一貫して、システムは、エントロピー・プールもしくは前記各ＨＳＭにおいて誘導される負荷またはその両方を監視するように構成される。他方、システムは、監視されている値に応じて、各ＨＳＭにおいて暗号オブジェクトが生成されるようにする。その結果、そのようなオブジェクトが生成される程度は、監視されている値に依存する。

本発明の実施形態では、クライアントはクラウドに実装される。クライアントはとりわけ、コンテナ、仮想マシン、もしくはそれぞれのコンピュータ・デバイスまたはそれらの組み合わせとして実装され得る。

最後の態様によれば、本発明は、上述のような鍵管理システムにおいて暗号オブジェクトを管理するためのコンピュータ・プログラム製品として具現化される。コンピュータ・プログラム製品は、プログラム命令を具現化したコンピュータ可読記憶媒体を含む。プログラム命令は、１つまたは複数のプロセッサによって実行可能であって、セットの各ＨＳＭに対して、本方法によるステップを実行させるものである。

ここで、本発明を具現化するコンピュータ化されたシステム、方法、およびコンピュータ・プログラム製品を、非限定的な例として、添付図面を参照して説明する。

添付図面は、同様の参照番号が別々の図にわたって同一または機能的に同様の要素を指し、以下の詳細な説明と共に本明細書に組み込まれ、その一部を形成するものであり、さらに様々な実施形態を例示し、全てが本開示による様々な原理および利点を説明するのに役立つ。

実施形態による、暗号オブジェクトを管理するための方法の高レベルのステップを示すフローチャートである。 実施形態に含まれる、ユーザに代わってハードウェア・セキュリティ・モジュール（ＨＳＭ）と対話するクライアントからの要求を管理するための方法の高レベルのステップを示すフローチャートである。 実施形態における、クライアントがユーザに代わってＨＳＭと対話し、クライアントがクラウドで動作する鍵管理システムの選択されたコンポーネントおよびアクターを概略的に示す図である。 本発明の実施形態に含まれる、ＨＳＭのエントロピー・プールと、ユーザがＨＳＭのクライアントと対話すること、ならびにこのＨＳＭにおける暗号オブジェクトの予防的生成によって、このＨＳＭにおいて誘導される負荷との典型的な時間発展を比較したプロットである。 図１に示す生成処理への入力として与えられる様々なタイプの暗号オブジェクトの例示的な理想的な再分割を表す円グラフである。

添付図面は、実施形態に含まれるコンピュータ化されたシステムの簡略化された表現を示している。図中の同様または機能的に同様の要素には、特に明記しない限り、同じ参照番号が割り当てられている。

以下の説明は次のように構成されている。まず、一般的な実施形態および高レベルの変形例について説明する（セクション１）。次のセクションでは、より具体的な実施形態および技術的な実装の詳細について述べる（セクション２）。

１．一般的な実施形態および高レベルの変形例
図１、図３および図４を参照して、本発明の一態様を最初に説明し、これは鍵管理システム１において暗号オブジェクトを管理するためのコンピュータ実施方法に関するものである。

そのようなシステムを図３に示す。これは、１つまたは複数のハードウェア・セキュリティ・モジュール１１～１３（以下、ＨＳＭ）のセットに加え、ユーザ５０に代わってＨＳＭ１１～１３と対話するクライアント３１～３３を含む。本方法は単一のＨＳＭを含むシステムに既に実装されている場合があるが、そのような方法は、以下で想定するように複数のＨＳＭを含む可能性が高い。実際には、ユーザ５０はクライアント３１～３３と対話し、これによりＨＳＭによって実行される様々な暗号処理操作（強力な認証、暗号化、復号など）が引き起こされて、暗号化／復号されたデータなどのデータがクライアントに供給される。

一般に、本明細書で提案する方法は、ＨＳＭのエントロピー・プールもしくはＨＳＭで誘導される負荷またはその両方の監視を中心に展開して、暗号オブジェクトを予防的に生成するようにして、ＨＳＭにおけるエントロピーの枯渇に関連する問題を回避する（または少なくとも延期する）。

そのような方法が図１のようにステップＳ１００にて開始すると仮定する。次に、各ＨＳＭ１１、１２、１３について、図１のループＳ１１０に示すように、エントロピー・プールもしくはこのＨＳＭで誘導される負荷またはその両方が継続的に監視される。「エントロピー・プール」とは、このＨＳＭが暗号オブジェクト（以下、ＣＯ）を生成するために使用可能なエントロピーを指し、「負荷」とは、ユーザ５０がこのＨＳＭからＣＯ５０を取得するためにクライアント３１～３３と対話することによって、このＨＳＭで誘導される負荷である。図３を参照されたい。これについては後で詳細に説明する。

次に、各ＨＳＭ１１、１２、１３において、監視されているエントロピー・プールもしくは負荷またはその両方に応じてＣＯをＳ１４０にて生成することができ、これは典型的には現在の負荷／エントロピー・レベルを継続的にチェックすることＳ１３０を含む。その結果、各ＨＳＭでそのようなオブジェクトがＳ１４０にて生成される程度は、このＨＳＭに対して監視されているエントロピー・プールもしくは負荷またはその両方に依存する。そのようなステップが、セットの各ＨＳＭに対して並行して実施される。

本明細書で前述したように、いくつかのＨＳＭが含まれ得（典型的には同じリージョンに対して３つ以上）、ＨＳＭは典型的には、より高い可用性を提供するためにクラスタ化されることが想定される。本発明の実施形態では、クライアントとＨＳＭとの間に１対１のマッピングが存在し得る。換言すれば、実装およびリソース管理を容易にするために、１つのクライアントが一度に１つのＨＳＭと対話する。変形例では、クライアントの高可用性を確保するために、異なる可用性ゾーンに分散した複数のクライアントを各ＨＳＭに割り当て得る。たとえば、（所与のデータセンタ内の）２つの物理マシンが２つの別々のラックに配置される場合、異なる可用性ゾーンは２つの別々のラックに対応し得る。ここで、（一方のラック上の）物理マシンが故障した場合、他方のラックに残っているホット・スペア（物理マシン）により、サービスを引き続き利用可能にすることができる。同じリージョン内に複数の可用性ゾーンが存在することができる。リージョンは、たとえば、特定のリージョン（エリア／市／国）内のデータセンタを指す場合がある。しかしながら、他のアーキテクチャおよび他のマッピングも考えられる。

クライアントは、１つまたは複数のマシンで動作するコンピュータ化されたリソースであり、たとえば、アプリケーションまたはコンテナ（複数の分離されたユーザ空間のインスタンスを可能にするもの）であり得る。そうでなければ、クライアントは、仮想マシン（ＶＭ：ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）または個別の物理デバイスであり得、またはこれらを含み得る。全ての場合において、クライアント３１～３３は、たとえば背景技術のセクションで述べたような大規模インフラストラクチャ向けのクラウド・サービスとして暗号処理操作を提供するために、（図３で想定するように）クラウド３０に実装することができる。特にクラウド実装において、生成されたＣＯを配布するために必要なメタデータを割り当てるなどのために、ユーザ５０とクライアントとの間に中間（たとえばソフトウェア）レイヤが含まれ得ることに留意されたい。しかしながらより一般的には、本発明は、たとえば、データ暗号化／復号（場合によってはストリーミングされるデータ）、認証、デジタル署名、もしくは任意の機密データ処理またはそれらの組み合わせを含む、任意の暗号アプリケーションに使用され得る。

たとえば、図３のシステム１はＮ個のＨＳＭを含み得、Ｎ個のクライアント３１～３３とそれぞれ対話する（Ｎ≧２であるが、Ｎははるかに大きい可能性が高い）。（図３の太い矢印のように）クライアント３１～３３とＨＳＭ１１～１３との間に１対１のマッピングを仮定すると、ＨＳＭ１１～１３のそれぞれに関して上記のステップが簡単に実行され得る。すなわち、監視されているリソースは、（ｉ）各ＨＳＭがＣＯを生成するための各ＨＳＭのエントロピー・プール、もしくは（ｉｉ）１人または複数人のユーザがＣＯを取得するために前記各ＨＳＭにマッピングされたクライアントと対話することによって各ＨＳＭで誘導される負荷、またはその両方に対応し得る。

本明細書で企図するＨＳＭ１１～１３は耐改ざんデバイスであり、安全性の高い暗号処理操作を実行できる安全な物理環境を提供する。ＨＳＭはハードウェアベースの乱数生成器を含む。ＨＳＭによって生成されたデータ、たとえば、生成された乱数から取得されたデータは、ある程度までクライアント３１～３３が使用できる（クライアントのみが使用でき、ユーザは使用できない）。より正確には、そのようなデータは、クライアントで動作する選択されたアプリケーションで使用可能にすることができ、それらのアプリケーションは典型的には、ＨＳＭによって生成されたデータにアクセスし、別の方法でＨＳＭと通信するために、適切に認証およびログインされる。それでもなお、ＨＳＭは比較的分離されたデバイスのままであり、限られた数のクライアントによって使用される。

エントロピーとは、暗号処理操作で使用するための、ＨＳＭ１１～１３で使用可能なランダム・データのランダム性の度合いを表す。ランダム性は、それ自体が知られているように、たとえばノイズ、電気信号の変動、または任意の外乱などの一部の物理的ソースに基づいて、専用のランダム性生成器から収集され得る。変形例では、ランダム生成器はまた、一部の外因性イベント、たとえば、クライアント要求のタイミングに関連付けられたビットもしくはそのような要求に含まれるデータまたはその両方に基づき得る。しかしながら、そのような変形例は、生成される数のランダム性の度合いに影響を与える体系的なパターンを含むことができることに留意されたい。

前述のように、本手法は予防的にＣＯを事前生成することに相当するので、ＨＳＭ１１～１３の負荷が低い／使用可能なエントロピーが大きい場合に、そのようなオブジェクトを蓄積することが可能になる。ＣＯの予備を蓄積することにより、後で適切に要求にサービス提供することが可能になり、これらがＨＳＭに高負荷時に押し寄せた場合でも可能である。ＣＯが蓄積されるということは、後で使用するために、現在のニーズを超えて事前に生成されることを意味する。これはまた、低負荷時に、典型的には、現在の要求を満たすために、事前生成されたＣＯの一部のみが配布されることを意味する。

その結果、後で使用するためにエントロピーを記憶する代わりに、ここでは使用可能なエントロピーを、使用可能になり次第すぐに使用することができる。このように、本手法はエントロピーの使い果たしに対処するだけでなく、ＣＯの事前生成に応じてパフォーマンスを改善することも可能になる。また、負荷を考慮することにより、本明細書に記載の実施形態は、ＨＳＭ１１～１３の現在の作業負荷に過度に影響を与えない。

本方法は、鍵管理システムにおけるエントロピーの枯渇を緩和する（すなわち延期する、または防止さえする）ことを目的とする。さもなければ、エントロピーの枯渇は、負荷が所与の閾値Ｔを超えた時点で発生する可能性があり得る。図４を参照されたい。詳細には、ＨＳＭによって使用される乱数生成処理は、各ＨＳＭのエントロピー・プールにおいて使用可能なエントロピーの量によって制限され、これは生成処理の現在の負荷および現在の供給速度に依存する。エントロピー・プールが枯渇した場合、乱数生成（以下、ＲＮＧ）を実行することができない。したがって、鍵および初期化ベクトル（ＩＶ：ｉｎｉｔｉａｌｉｚａｔｉｏｎ ｖｅｃｔｏｒ）をそれ以上生成できなくなり、追加のエントロピーが使用可能になるまでそれらの生成が遅延する。

このように、高負荷時にはパフォーマンスおよびセキュリティが損なわれ得るが、本発明の利点により、ＨＳＭを修正する必要なく、エントロピーの枯渇を緩和することが可能になる。すなわち、既存のＨＳＭに依存することができ、これらは必ずしも修正される必要はない。

ＲＮＧは、仮想化環境で動作するアプリケーションなど、多くのセキュリティ・アプリケーションにとっての課題である。その点で、本手法の実施形態は、本発明の実施形態のように、クライアント３１～３３とＨＳＭとの間の１対１のマッピングに応じて容易に拡張可能である。使用可能なエントロピーをすぐに使用することに加えて、生成されたオブジェクトをＨＳＭに記憶できる程度まで、ＣＯの事前生成を安全に管理することができる。本明細書に記載の実施形態のように、最も重要なデータをＨＳＭで維持することができ、あまり重要でないデータの記憶は、クライアント側などに外部化することができる。

したがって、本発明の実施形態は、パフォーマンスとセキュリティとを両立し、さらに、ＨＳＭを修正する必要なく、容易に拡張することができる。これにより、全体として、クライアント３１～３３をクラウドに実装することが完全に適切になる。したがって、実施形態のように、本方法はクラウドベースのサービスとして有利に提供することができる。

変形例の中でもとりわけ、以下に説明するように、３つのクラスの実施形態が考えられる。

第１の手法は、たとえば、乱数、暗号鍵、またはＨＳＭにおける他の任意の暗号関連オブジェクトに関する要求による負荷を監視することＳ１１０のみからなる。この手法はエントロピーに依存せず、エントロピー・プール（たとえば、乱数供給源）は監視されない。

第２の手法は、エントロピー・プールのみを監視するもの（すなわち、乱数供給源の補充）である。この第２の手法は負荷に依存しない。負荷自体は監視されないが、典型的には常に中／高であると想定され得る。それでもやはり、エントロピーは典型的には、（たとえば、任意の適切な統計モデル、機械学習モデル、または分析関数を介して）現在の負荷に基づいて推定される必要があり得るので、エントロピーを監視することは、最終的には、負荷も監視し、これからエントロピーを予想することに相当し得る。

第３の手法は、たとえば、高および低閾値の方法を使用して、ＨＳＭのエントロピー・プールと負荷との両方を監視するものである。このようにして、たとえば、オンライン負荷（需要）とエントロピー・プール（供給）とを一致させるために二重制約最適化方式を実装できる、完全にバランスの取れた管理システムを考えることができる。換言すれば、要求にサービス提供するために事前に生成されたオブジェクトを提供して、エントロピーの補充を可能にすることによって、オンライン負荷を効果的に下げることができる。このように、負荷を現在測定されている（というよりは推定されている）エントロピー値に調整することにより、ＨＳＭを（ほぼ）定常状態に維持するように、負荷をエントロピー・プールに一致させることができる。

理想的には、監視されているエントロピー・プールに比例して、もしくは監視されている負荷に反比例して、またはその両方で、ＨＳＭにおいてＣＯがＳ１４０にて生成される。しかしながら、ＣＯが生成されるペースの関係は、実際には多少粗くてもよい。たとえば、エントロピーが所与のそれぞれの閾値を超える場合、もしくは負荷が所与のそれぞれの閾値を下回る場合、またはその両方の場合に、一定の生成速度が適用され得る。図４を参照されたい。

図４の例では、暗号オブジェクトは２値処理に従ってＳ１４０にて生成され、すなわち、それらが（エントロピー／負荷レベルに応じて）生成されるか否かであり、監視されている値との正味の比例関係（または逆の関係の比例）を必ずしも必要としない。しかしながら、一般に、負荷が所与のそれぞれの閾値を下回る場合に、現在の負荷がこの閾値を超える場合よりも多くのオブジェクトがＳ１４０にて生成される。同様に、エントロピーが所与のそれぞれの閾値を超える場合に、エントロピーがその閾値を下回る場合よりも多くのオブジェクトを生成することができる。最後に、図４の例では、簡単にする目的で、図示したエントロピーと負荷との両方に対して閾値Ｔが同一になるように選ばれていることに留意されたい（そうでなければグラフは負荷とエントロピーとに対して自由な単位を仮定する）。しかしながら、実際には、単位は異なる可能性があるので、そのような閾値が同一である理由はない。

本明細書に記載の本発明の実施形態は、エントロピーではなく、各ＨＳＭ１１、１２、１３で誘導される負荷を監視することＳ１１０に主に基づいている。換言すれば、各ＨＳＭ１１、１２、１３でそのようなオブジェクトがＳ１４０にて生成される程度は、監視されている負荷に依存する。実際には、監視されている負荷が所与の負荷閾値を下回った場合、そのようなオブジェクトがＳ１４０にて生成される速度が増加する。図４で想定しているように、エントロピーが重要なボトルネック・リソースであるとすれば、所与のＨＳＭの現在のエントロピー・プールおよび負荷は、典型的には時間の経過と共におおよそ逆に変化する。したがって、実際には負荷を監視すれば通常は十分であり、エントロピー・プールを明示的に監視する必要はない。それでもなお、ＣＯを実際に生成するために必要な計算リソースなど、追加的な要因がＨＳＭの負荷にさらに影響し得る。そのため、エントロピー・プールおよび負荷は、実際には時間の経過と共に完全な反比例で変化しない場合がある。

それにもかかわらず、本発明の実施形態では、本方法は負荷非依存ではない。換言すれば、負荷は明示的に監視され、監視されている負荷値はＣＯが生成される程度に影響する。当業者が知っているように、ネットワークのノードでリアルタイムの負荷を監視できるようにするいくつかの方法が知られている。

ＨＳＭの負荷はとりわけ、クライアント３１～３３から測定され得（ＨＳＭの既知の特性を考慮すると、１対１のマッピングでは特に簡単である）、またはＨＳＭ自体で測定され得（対応する機能が搭載されている場合）、さらにはゲートウェイもしくはネットワークの任意の適切なノードにおいて、このノードにはクライアントによって行われた要求が継続的に通知されると仮定して、測定され得る。ＣＯ生成処理Ｓ１４０は最終的にＨＳＭで行われるが、ネットワークのノード（たとえば、トラフィック・コントローラ）から制御され得る。変形例では、この処理はいくつかのノードにわたって非局在化（ｄｅｌｏｃａｌｉｚｅ）される。ネットワーク・トラフィック管理ソリューションのような、様々な中間構成が考えられる。

実施形態では、生成されたＣＯの少なくとも一部を、ＣＯ生成が行われたＨＳＭ１１、１２、１３にＳ１４３にて記憶して、生成されたオブジェクトを保護するようにさらに指示される。それでもやはり、最も重要なデータ（たとえば、マスター鍵、ラップ解除された形式の暗号鍵）だけはＨＳＭ内で厳重に維持される必要があるが、後で詳細に説明するように、あまり重要でないデータの記憶を外部化して、ＨＳＭのメモリスペースを節約することができる。

その点で、Ｓ１４０にて生成されたＣＯは、典型的には、対称鍵もしくは非対称鍵またはその両方を含み得る暗号鍵に加え、初期化ベクトル（ＩＶ）を含む。ＩＶはデータ暗号化用の秘密鍵と共に、暗号プリミティブへの入力として使用される。すなわち、そのようなベクトルは、同じクリア・データを暗号化した結果が、異なるベクトルが使用される度に異なるように、暗号化アルゴリズムへの追加のランダム入力として使用される。しかしながら、ＩＶは暗号鍵よりも重要でなく、公開することができるので、場合によってはＨＳＭの外部に、たとえばクライアント３１～３３に、またはそれらの近く４１～４３に記憶することができる。

図１に見られるように、生成された暗号鍵およびＩＶを、それらがＳ１４１にて生成されたＨＳＭ１１、１２、１３に、少なくとも一時的にＳ１４３にて記憶するように指示することができる。その目的で、ＨＳＭ１１～１３にはハードウェア・メモリが搭載され、これはＨＳＭ用のキャッシュ・メモリとして構成することができる。ハードウェア・キャッシュは、ＨＳＭによって、そこに記憶されたデータにアクセスするための（時間またはエネルギーの観点での）平均コストを削減するために使用される。

前述のように、生成されたオブジェクトの一部は、それにもかかわらず、後で外部記憶媒体４１～４３に記憶されるように、各ＨＳＭ１１、１２、１３によってクライアントなどにＳ１５０にて供給される。図３で想定しているように、外部記憶媒体４１～４３は、たとえば、クライアント３１～３３に取り付けられるか、またはこれらと密接なデータ通信を行い、すなわち、クライアント空間にあり（ユーザ空間にはない）、ここにデータをまだ比較的安全に記憶することができる。このようにして、供給された材料（または関連する材料）の少なくとも一部を、後でステップＳ１７０にて削除することができる。

そのようなオブジェクトをＨＳＭ１１～１３に記憶および維持するか否かは、以下で説明する実施形態のように、実際には選択されたストレージ戦略に依存し、これはＨＳＭのメモリ容量の監視をさらに含み得る。具体的には、生成された暗号鍵およびＩＶは、後述のように、ＨＳＭのメモリ容量に応じて、まずＨＳＭに記憶され、後で削除され得る。

実施形態では、生成ステップＳ１４０全体は、以前にＳ１４１にて生成された鍵のうちの１つまたは複数を、ローカルに、すなわち各ＨＳＭ１１、１２、１３でＳ１４５にてラップすることをさらに含む。これは、それ自体が知られているように、各ＨＳＭ１１、１２、１３にあるマスター鍵に基づいて実行される。それに応じて、１つまたは複数のラップされた鍵がそれぞれＳ１４５にて取得される。

ステップＳ１４５にて取得されたラップされた鍵の記憶は、外部記憶媒体４１～４３に（関係する各ＨＳＭによって）Ｓ１５０にて外部化することができる。典型的には、ステップＳ１４５およびＳ１５０は単一のステップとして、ラップ処理の一部として実装され、これにより、鍵をラップすると、（図１が示唆し得るものに反して）ラップされた鍵はすぐに供給される。しかしながら、変形例では、ラップされた鍵は、たとえば現在のネットワーク・トラフィック状況に適応するために、要求元のユーザ／クライアントに供給される前にＨＳＭのキャッシュに一時的に保持され得る。全ての場合において、クライアント３１～３３は、ラップされた鍵を複製するか、またはその識別子を維持することができる。それでもなお、たとえばＨＳＭに記憶された鍵ハンドルへのローカル・マッピングを使用して、対応する（ラップ解除された）鍵を後で必要に応じて識別することができる。なお、「ラップ解除された」という用語は、ここではラップ解除された形式またはラップされていない形式の鍵を表すために使用していることに留意されたい。

図１に示すように、ＨＳＭ１１～１３に記憶されている暗号材料を削除するか否かは、ＨＳＭのメモリ容量に基づくことができる。その目的で、ＨＳＭのメモリ容量がＳ１２０にて監視される。このようにして、たとえば、新たなＣＯ生成ステップＳ１４０の前に、所与のＨＳＭのメモリ容量を継続的に１２０、１６０にてチェックすることができる。そこで、仮にＳ１６０にてメモリ容量が十分であった（たとえば、所与の容量閾値よりも大きい）場合、このＨＳＭから暗号材料を削除する必要はなく、処理はステップＳ１００に戻る。新たなサイクルが開始し、それによって現在の負荷／エントロピー・レベルがＳ１３０にてチェックされ、負荷／エントロピーが許せば、このＨＳＭはＣＯ生成１４０の新たなサイクルに進んで、さらなるクライアント要求にサービス提供するなどし得る。

しかしながら、仮にＳ１６０にてこのＨＳＭのメモリ容量が不十分であった（たとえば、所与の容量閾値よりも小さい）場合、以前にＳ１５０にて供給されたＣＯに対応する材料をＳ１７０にて削除して、このＨＳＭのスペースを節約することができる。

前述のように、Ｓ１５０にて供給されたＣＯは、以前にＳ１４５にて取得されたラップされた鍵を含むことができる。したがって、ラップされた鍵は、それらが取得されたＨＳＭから削除することができる（ラップされた鍵は、典型的にはローカルに、ラップ処理Ｓ１４５～Ｓ１５０の一部として削除されることに留意されたい）。加えて、ステップＳ１５０にて供給されたラップされた鍵に対応する暗号鍵（ラップ解除された形式）もステップＳ１７０にて削除することができる。

また、ステップＳ１５０にて供給されたＣＯは、ＨＳＭ１１、１２、１３で以前にＳ１４１にて生成されたＩＶをさらに含み得る。したがって、ステップＳ１７０であろうと、それ以前（たとえば、Ｓ１５０にてラップされた鍵を供給したとき）であろうと、Ｓ１５０にて供給されたＩＶもこのＨＳＭから削除され得る。

全ての場合において、上記のシナリオでは、ラップ解除された形式の鍵がＨＳＭ１１～１３で維持されるかまたはＳ１７０にて削除されることを常に想定している。そのような鍵は、セキュリティ上の理由で、ＨＳＭから離れることを意図していない。したがって、最終的に削除されるＣＯのセットは、外部記憶媒体４１～４３にＳ１５０にて供給されるオブジェクトのセットとは異なる可能性があり、ただし、いくらかの重複および対応関係が存在する。たとえば、鍵（ラップされた形式のみ）をクライアント・デバイスにＳ１５０にて供給して、その上に記憶することができるので、対応する鍵（ラップされた形式とラップ解除された形式との両方）をＨＳＭから削除することができる。そのような削除は不利にはならず、その理由は、図２を参照して後述するように、後続の要求にはラップされた鍵が付属し得、付属するラップされた鍵をＨＳＭにおいて、そこにあるマスター鍵に従ってラップ解除することができるためである。

ステップＳ１５０～Ｓ１７０の方式により、ＨＳＭのキャッシュの飽和に関連する潜在的な問題を緩和することが可能になる。反対に、従来の解決策では、高負荷はエントロピーの枯渇につながり得るだけでなく、加えて、ＨＳＭのキャッシュの飽和がもたらされ得る。ここでは、機密性の低いデータ（ラップされた鍵およびＩＶなど）の記憶を外部化することにより、外部化された材料に対応する暗号材料をＨＳＭ１１～１３から削除することが可能になる。しかしながら、そのような削除は、図２を参照して以下で説明するように、要求にサービス提供するパフォーマンスに影響を与えないように、ＨＳＭのメモリ容量が飽和した場合にのみ含まれる。

全ての場合において、マスター鍵はＨＳＭにおいて維持される必要がある。マスター鍵およびラップ解除された鍵は、ＨＳＭから離れることを意図しておらず、上述の実施形態のように、ラップ解除された鍵をＨＳＭからＳ１７０にて削除できることを想起されたい。

ここで図２をより詳細に参照して、システムによるクライアント要求の処理に関する実施形態を説明する。前述のように、将来の使用Ｓ２００のためにＣＯの予備を蓄積するために、各ＨＳＭ１１、１２、１３においてＣＯをＳ１４０にて生成することができる。具体的には、クライアント３１～３３の１つの要求Ｓ２００を受信すると、ＨＳＭ１１、１２、１３は受信した要求に従って、暗号操作をＳ２１０～Ｓ２４５にて実行し得る。この際、たとえばデータ暗号化のために、ＨＳＭで実装された暗号プリミティブへの入力として、１つまたは複数のＩＶが１つまたは複数の暗号鍵と共に使用され得る。

しかしながら、この時点で、選択されたストレージ戦略次第で、ラップ解除された鍵がＨＳＭにある場合と、ない場合とがある。また、図１を参照して説明したような実施形態では、暗号オブジェクトの一部はＨＳＭで維持されるが（メモリ容量が十分な場合）、他の一部のオブジェクトは欠落している。欠落しているオブジェクトは、メモリ容量が不十分であったときに作成されたオブジェクトに対応し、したがってそれらの記憶は外部化されており、対応する暗号材料はその後削除されている。したがって、場合によっては、クライアント要求に基づいて最初に適切な鍵をＨＳＭで見つける必要があり得、またはこの鍵が、以下で説明するように、要求と共に提供されるラップされた鍵に基づいて、最初にラップ解除される必要があり得る。

図２に見られるように、ステップＳ２００にて、暗号操作を実行する要求が、クライアント３１～３３のうちの１つからＨＳＭに受信され得る。この要求にはラップされた鍵が付属し、これは以前にクライアントにＳ１５０にて供給されたものである。要求に基づいて、ＨＳＭコントローラ（図示せず）は、ＨＳＭ１１、１２、１３のうちの１つにおいて、要求に付属するラップされた鍵に対応する鍵をＳ２１０、Ｓ２２０にて最初に見つけようとし得る。Ｓ２２０にて一致が見つかったと仮定すると、要求された暗号操作を、見つかった鍵を保護しているＨＳＭにおいて、その鍵に基づいてＳ２４０にて実行することができる。

いくつかの変形例が考えられる。たとえば、要求には、ラップされた鍵自体ではなく、ラップされた鍵の識別子が付属し得る。その場合、要求と共に受信した識別子に対応する鍵をＳ２１０、Ｓ２２０にて見つけようとする。その点で、ステップＳ２００～Ｓ２２０は、それ自体が知られているように、ハッシュおよび鍵ハンドルに基づいて実行され得る。たとえば、ステップＳ２１０にて、最初に、ラップされた鍵のハッシュ（すなわち、このハッシュはステップＳ２００で受信した識別子である）を、ＨＳＭに記憶された鍵ハンドルへのローカル・マッピングと比較し得る。Ｓ２２０にて一致が見つかると、対応する鍵ハンドルを使用して、対応する（ラップ解除された）鍵にアクセスする。

しかしながら、ステップＳ２２０にて一致が見つからなかった場合、ラップされた鍵が、その鍵をラップ解除するのに必要である。その目的で、ステップＳ２００にて要求と共に提供されたラップされた鍵があれば、それを使用し得る。ラップされた鍵自体の代わりにラップされた鍵の識別子が提供された場合、ラップされた鍵を取得するには、要求元のクライアントとの追加の通信（図示せず）が必要になる。そのような状況に対処するために、適切なプロトコルが実装され得る。ラップされた鍵を受信すると（それによって要求はここで完了する）、ＨＳＭは、そこに存在するマスター鍵に従って、受信したラップされた鍵をＳ２３０にてラップ解除することに進む。これにより、対応する（ラップ解除された）鍵が復元される。要求された暗号操作は、復元された鍵に基づいて、ステップＳ２４５にて最終的に実行される。

必要に応じて、ＨＳＭが要求された操作を適切に実行するために、要求内でラップされた鍵データと共にＩＶが提供される。

図１および図２に具体的に示した実施形態によって、パフォーマンスおよびセキュリティを維持しながら、ＨＳＭにおけるエントロピーの枯渇の問題と、潜在的なキャッシュの飽和との両方に対処することが可能になる。低負荷／高エントロピー時には、将来の要求を考慮してＣＯが蓄積される。しかしながら、ＨＳＭの残存メモリ容量が少ない場合、暗号材料の一部はＨＳＭに維持されない。それでもなお、図２の方式により、ＨＳＭで維持される（ＨＳＭから離れない）より重要な暗号オブジェクト（たとえば、マスター鍵）に基づいて、削除された材料（たとえば、ラップ解除された鍵）を安全に復元することが可能になる。

再び図１を参照して、ステップＳ１４０にて暗号材料が生成される仕方に関連する追加の実施形態をここで説明する。たとえば、各ＨＳＭ１１、１２、１３において、監視されているエントロピー・プールもしくは負荷またはその両方のパラメータ化された関数に従って、ＣＯがＳ１４０にて生成され得る。この関数は、自動的な方法に基づいて、たとえばユーザから（ただし、クライアントを介して）または何らかのコントローラからＨＳＭにおいて受信した入力に従って、Ｓ１４９にて更新され得るパラメータを含み得る。全ての場合において、ステップＳ１４８にて受信した入力（関数のパラメータに関するもの）を使用して、この関数をＳ１４９にて更新する。この関数は、生成プロファイル（単数または複数）を定義する。ＣＯのタイプによって、生成プロファイルは異なり得る。したがって、関数はとりわけ、生成されるＣＯの理想的な速度と、現在の負荷／エントロピー・レベルとの関係（すなわち比率）を定義し得る。

この関数は、たとえば、分析的（かつ、場合によってはパラメトリック）であるか、または数値的であり得る（たとえば、単なるテーブルであり得る）。この関数は、たとえば、いくつかの関数（たとえば、Ｓ１４０にて生成されるＣＯのタイプごとに１つ）に分解するためにパラメトリックであり得る。

加えて、ＨＳＭにおいて予防的に到達すべき目標を設定するため参照データに依存することができる。たとえば、対応する統計をＳ１４６にて取得するように、生成されたＣＯを各ＨＳＭ１１、１２、１３において監視し得る。次いで、そのような統計を参照データとＳ１４７にて比較することができる。したがって、その後Ｓ１４０にて生成されるＣＯは、ステップＳ１４７にて実行された比較の結果に、Ｓ１４９にて基づくことができる。たとえば、ＣＯの生成プロファイルを決定するために使用される生成関数は、比較結果に基づいて、参照データからの指示に沿ってＣＯを生成するようにステップＳ１４９にて更新され得る。

そのような参照データは、たとえば、アプリケーション固有の目標であり得る。そのようなデータは、図５の円グラフに示すように、異なるタイプのＣＯ（たとえば、対称鍵、非対称鍵、ＩＶなど）の間の比率をさらに指定し得る。

次に、他の態様によれば、本発明は、ＣＯを管理するためのコンピュータ化されたシステム１、たとえば、鍵管理システム（ＫＭＳ）、またはＫＭＳのサブシステムとして具現化することができる。そのようなシステムの主な態様は、本方法を参照して既に前述している。そのため、そのようなシステムを、以下でごく簡潔に説明する。ＣＯ管理システム１は、１つまたは複数のＨＳＭ１１～１３を含み（およびいくつかのＨＳＭを含むことができる）、ならびに前述のように、ユーザ５０に代わってＨＳＭ１１～１３のセットと対話するように構成されるクライアント３１～３３を含む。

クライアントとＨＳＭとの間には１対１のマッピングが存在することができる。換言すれば、実装およびリソース管理を容易にするために、１つのクライアントが一度に１つのＨＳＭと対話する。しかしながら、他のアーキテクチャも考えられる。

全ての場合において、システムは、動作中の、各ＨＳＭ１１、１２、１３のエントロピー・プールもしくは各ＨＳＭにおいて誘導される負荷またはその両方を監視するように構成される。加えて、図１を参照して前述したように、システム１は、各ＨＳＭが監視されているエントロピー・プールもしくは負荷またはその両方に応じてＣＯをＳ１４０にて生成するようにする。その結果、そのようなオブジェクトがＳ１４０にて生成される程度は、動作中の、監視されているエントロピー・プールもしくは負荷またはその両方に依存する。そのようなシステム１により、低負荷／高エントロピー時にＣＯを蓄積することが可能になる。

実施形態では、システム１は、図１および図２を参照して前述したように、ＨＳＭのキャッシュの飽和を防止するように要求を処理するようさらに構成され得る。その目的で、各ＨＳＭのメモリ容量が監視される必要がある。セキュリティ上の理由で、そのようなメモリは、各ＨＳＭのキャッシュ・メモリとして構成されるハードウェア・メモリとすることができる。

実施形態では、クライアント３１～３３はクラウド３０に実装される。クライアントはとりわけ、アプリケーション、コンテナとして実装され、仮想マシンもしくはそれぞれのコンピュータ・デバイスまたはその両方であるか、またはそれらを含み得る。クライアント３１～３３は、たとえば、図３で想定しているように、異なるデバイスに実装されたコンテナで構成され得る。

クラウドは、リソースの所有者が、たとえば一定期間、それらのリソースの一部または全てをユーザに動的に割り当て得るように編成されたコンピュータ・リソースのセットである。クライアント３１～３３が実装されるクラウドは、プライベート・クラウド、すなわち、ユーザおよび所有者が同じ組織に属するクラウドであり得る。変形例では、このクラウドは外部クラウド、たとえばパブリック・クラウドであり、ユーザと所有者とが異なる組織に属する。たとえばセキュリティまたは信頼性などの理由で、所有者またはユーザが、自身の計算をサード・パーティのインフラストラクチャで実行させたくない場合に、プライベート・クラウドを使用することができる。

次に、最後の態様によれば、本発明は、ＫＭＳにおいてＣＯを管理するためのコンピュータ・プログラム製品として具現化することができる。このコンピュータ・プログラム製品は、プログラム命令を具現化したコンピュータ可読記憶媒体を含み、プログラム命令は、１つまたは複数のプロセッサによって、後者に本方法によるステップを取らせるために実行可能である。本コンピュータ・プログラムの態様については、セクション２．２で詳細に説明する。

このプログラムは、たとえば、クライアントおよびＨＳＭにおいて（非局在化された方法で）、または特定のノード（たとえば、ＨＳＭ）において動作し得る。加えて、このプログラムは、場合により、ＨＳＭまたはクライアントとＨＳＭとの両方と対話することを許可されたコントローラを含み得る。当業者には当然のことながら、多くの可能なアーキテクチャが考えられる。

上記の実施形態は、添付図面を参照して簡潔に説明しており、いくつかの変形例を含み得る。上記の特徴のいくつかの組み合わせが考えられる。

２．特定の実施形態 － 技術的な実装の詳細
２．１ クラウド実装
本開示はクラウド・コンピューティングを含む実施形態に言及するが、本明細書において述べた教示の実装はクラウド・コンピューティング環境に限定されないことを理解されたい。むしろ、本発明の実施形態は、現在知られているまたは今後開発される他の任意のタイプのコンピューティング環境と組み合わせて実装することが可能である。クラウド・コンピューティングは、最小限の管理労力またはサービスのプロバイダとの対話によって迅速に供給およびリリースすることが可能な、設定可能なコンピューティング・リソース（たとえば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、ストレージ、アプリケーション、仮想マシン、およびサービス）の共有プールへの便利なオンデマンド・ネットワーク・アクセスを可能にするためのサービス提供のモデルである。このクラウド・モデルは、少なくとも５つの特性と、少なくとも３つのサービス・モデルと、少なくとも４つの展開モデルと、を含み得る。

特徴は以下の通りである。
オンデマンド・セルフサービス：クラウド・コンシューマは、サービスのプロバイダとの人的な対話を必要とせずに、必要に応じて自動的に、サーバ時間およびネットワーク・ストレージなどのコンピューティング能力を一方的に供給することができる。

ブロード・ネットワーク・アクセス：能力はネットワークを介して使用することができ、異種のシンまたはシック・クライアント・プラットフォーム（たとえば、携帯電話、ラップトップ、およびＰＤＡ）による使用を促進する標準的なメカニズムを介してアクセスされる。

リソース・プーリング：プロバイダのコンピューティング・リソースをプールして、様々な物理リソースおよび仮想リソースが需要に応じて動的に割り当ておよび再割り当てされるマルチ・テナント・モデルを使用して複数のコンシューマにサービス提供する。一般にコンシューマは、提供されるリソースの正確な位置に対して何もできず、知っているわけでもないが、より高い抽象化レベル（たとえば、国、州、またはデータセンタなど）における位置を特定できる場合があるという点で位置非依存の感覚がある。

迅速な弾力性：能力を迅速かつ弾力的に、場合によっては自動的に供給して素早くスケール・アウトし、迅速に解放して素早くスケール・インすることができる。コンシューマにとって、供給可能な能力は無制限であるように見えることが多く、任意の時間に任意の数量で購入することができる。

測定されるサービス：クラウドシステムは、サービスのタイプ（たとえば、ストレージ、処理、帯域幅、およびアクティブ・ユーザ・アカウント）に適したある抽象化レベルでの計量機能を活用して、リソースの使用を自動的に制御し最適化する。リソース使用量を監視、管理、および報告して、利用されるサービスのプロバイダおよびコンシューマの両方に透明性を提供することができる。

サービス・モデルは以下の通りである。
ソフトウェア・アズ・ア・サービス（ＳａａＳ：Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、クラウド・インフラストラクチャ上で動作するプロバイダのアプリケーションを使用することである。アプリケーションは、ウェブ・ブラウザ（たとえば、ウェブ・ベースの電子メール）などのシン・クライアント・インターフェースを介して様々なクライアント・デバイスからアクセス可能である。コンシューマは、限定されたユーザ固有のアプリケーション構成設定を可能性のある例外として、ネットワーク、サーバ、オペレーティング・システム、ストレージ、さらには個々のアプリケーション能力を含む、基盤となるクラウド・インフラストラクチャを管理も制御もしない。

プラットフォーム・アズ・ア・サービス（ＰａａＳ：Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、プロバイダによってサポートされるプログラミング言語およびツールを使用して作成された、コンシューマが作成または取得したアプリケーションをクラウド・インフラストラクチャ上に展開することである。コンシューマは、ネットワーク、サーバ、オペレーティング・システム、またはストレージを含む、基盤となるクラウド・インフラストラクチャを管理も制御もしないが、展開されたアプリケーションおよび場合によってはアプリケーション・ホスティング環境構成を制御する。

インフラストラクチャ・アズ・ア・サービス（ＩａａＳ：Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）：コンシューマに提供される能力は、オペレーティング・システムおよびアプリケーションを含み得る任意のソフトウェアをコンシューマが展開し動作させることが可能な、処理、ストレージ、ネットワーク、および他の基本的なコンピューティング・リソースを供給することである。コンシューマは、基盤となるクラウド・インフラストラクチャを管理も制御もしないが、オペレーティング・システム、ストレージ、展開されたアプリケーションを制御し、場合によっては選択したネットワーキング・コンポーネント（たとえば、ホスト・ファイアウォール）を限定的に制御する。

展開モデルは以下の通りである。
プライベート・クラウド：クラウド・インフラストラクチャは組織専用に運用される。これは組織または第三者によって管理され得、構内または構外に存在し得る。

コミュニティ・クラウド：クラウド・インフラストラクチャはいくつかの組織によって共有され、共通の利害関係（たとえば、ミッション、セキュリティ要件、ポリシー、およびコンプライアンスの考慮事項など）を有する特定のコミュニティをサポートする。これは組織または第三者によって管理され得、構内または構外に存在し得る。

パブリック・クラウド：クラウド・インフラストラクチャは、一般大衆または大規模な業界団体に対して利用可能にされ、クラウド・サービスを販売する組織によって所有される。

ハイブリッド・クラウド：クラウド・インフラストラクチャは、固有のエンティティのままであるが、データおよびアプリケーションの移植性を可能にする標準化技術または独自技術（たとえば、クラウド間の負荷分散のためのクラウド・バースティング）によって結合された２つ以上のクラウド（プライベート、コミュニティ、またはパブリック）を合成したものである。

クラウド・コンピューティング環境は、ステートレス性、低結合性、モジュール性、および意味論的相互運用性に重点を置いたサービス指向型である。クラウド・コンピューティングの中核にあるのは、相互接続されたノードのネットワークを含むインフラストラクチャである。

２．２ システム、方法、およびコンピュータ・プログラム製品
本発明は、任意の可能な技術的詳細レベルの統合での、システム、方法、もしくはコンピュータ・プログラム製品またはそれらの組み合わせであり得る。コンピュータ・プログラム製品は、本発明の態様をプロセッサに実行させるためのコンピュータ可読プログラム命令をその上に有するコンピュータ可読記憶媒体（単数または複数）を含み得る。

コンピュータ可読記憶媒体は、命令実行デバイスによる使用のために命令を保持し記憶することができる有形デバイスとすることができる。コンピュータ可読記憶媒体は、たとえば、限定はしないが、電子記憶デバイス、磁気記憶デバイス、光学記憶デバイス、電磁記憶デバイス、半導体記憶デバイス、またはそれらの任意の適切な組み合わせであり得る。コンピュータ可読記憶媒体のより具体的な例の非網羅的リストは、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：ｓｔａｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：ｐｏｒｔａｂｌｅ ｃｏｍｐａｃｔ ｄｉｓｃ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、メモリー・スティック（登録商標）、フレキシブル・ディスク、命令が記録されたパンチ・カードまたは溝の隆起構造などの機械的に符号化されたデバイス、およびそれらの任意の適切な組み合わせを含む。コンピュータ可読記憶媒体は、本明細書で使用する場合、たとえば、電波もしくは他の自由に伝播する電磁波、導波管もしくは他の伝送媒体を伝播する電磁波（たとえば、光ファイバ・ケーブルを通過する光パルス）、または導線を介して伝送される電気信号などの一過性の信号自体であると解釈されるべきではない。

本明細書に記載のコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスに、あるいはインターネット、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、もしくはワイヤレス・ネットワーク、またはそれらの組み合わせなどのネットワークを介して外部コンピュータまたは外部記憶デバイスにダウンロードすることができる。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、もしくはエッジ・サーバ、またはそれらの組み合わせを含み得る。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インタフェースは、ネットワークからコンピュータ可読プログラム命令を受信し、コンピュータ可読プログラム命令を転送して、それぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体に記憶できるようにする。

本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ－ｓｅｔ－ａｒｃｈｉｔｅｃｔｕｒｅ）命令、機械命令、機械依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路用の構成データ、あるいはＳｍａｌｌｔａｌｋ（登録商標）、Ｃ＋＋、もしくは同様のもののオブジェクト指向プログラミング言語と、Ｃプログラミング言語または類似のプログラミング言語などの手続き型プログラミング言語とを含む、１つまたは複数のプログラミング言語の任意の組み合わせで書かれたソース・コードまたはオブジェクト・コードであり得る。コンピュータ可読プログラム命令は、完全にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、独立型ソフトウェア・パッケージとして、部分的にユーザのコンピュータ上かつ部分的にリモート・コンピュータ上で、または完全にリモート・コンピュータもしくはサーバ上で実行され得る。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）またはワイド・エリア・ネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザのコンピュータに接続され得、または（たとえば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータへの接続がなされ得る。一部の実施形態では、たとえば、プログラマブル論理回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ａｒｒａｙ）を含む電子回路は、本発明の態様を実行するために、電子回路を個人向けにするためのコンピュータ可読プログラム命令の状態情報を利用することによって、コンピュータ可読プログラム命令を実行し得る。

本発明の態様は、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して本明細書で説明している。フローチャート図もしくはブロック図またはその両方の各ブロック、ならびにフローチャート図もしくはブロック図またはその両方におけるブロックの組み合わせが、コンピュータ可読プログラム命令によって実装できることは理解されよう。

これらのコンピュータ可読プログラム命令を汎用コンピュータ、専用コンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供して、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行された命令が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックにおいて指定された機能／動作を実施するための手段を生成するようなマシンを生成し得る。また、これらのコンピュータ可読プログラム命令は、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックにおいて指定された機能／動作の態様を実装する命令を含む製造品を含むような特定の仕方で機能するように、コンピュータ、プログラム可能データ処理装置、もしくは他のデバイスまたはそれらの組み合わせに指示することができるコンピュータ可読記憶媒体に記憶され得る。

また、コンピュータ可読プログラム命令をコンピュータ、他のプログラム可能データ処理装置、または他のデバイスにロードして、コンピュータ、他のプログラム可能装置、または他のデバイス上で一連の動作ステップを実行させることによって、コンピュータ、他のプログラム可能装置、または他のデバイス上で実行された命令が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックにおいて指定された機能／動作を実装するようなコンピュータ実施処理を生成し得る。

図中のフローチャートおよびブロック図は、本発明の様々な実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実装形態のアーキテクチャ、機能性、および動作を示している。これに関して、フローチャートまたはブロック図の各ブロックは、指定された論理的機能（群）を実装するための１つまたは複数の実行可能命令を含むモジュール、セグメント、または命令の一部を表し得る。一部の代替的実装形態では、ブロックに示した機能は、図に示した順序以外で実施され得る。たとえば、関与する機能性に応じて、連続して示した２つのブロックは、実際には実質的に同時に実行され得、またはそれらのブロックは、場合によっては逆の順序で実行され得る。ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方におけるブロックの組み合わせは、指定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令との組み合わせを実行する専用ハードウェアベースのシステムによって実装できることにも留意されたい。

本発明は、限られた数の実施形態、変形例、および添付図面を参照して説明しているが、当業者には、本発明の範囲から逸脱することなく様々な変更が行われ得、均等物に置換され得ることが理解されよう。具体的には、本発明の範囲から逸脱することなく、所与の実施形態、変形例において述べた、または図示した（デバイス様または方法様の）特徴は、他の実施形態、変形例、または図面の他の特徴と組み合わせられるか、またはこれに置き換わり得る。したがって、添付の特許請求の範囲内に留まる上記の実施形態または変形例のいずれかに関して説明した特徴の様々な組み合わせが考えられる。加えて、本発明の範囲から逸脱することなく、特定の状況または材料を本発明の教示に適合させるために、多くの小さな修正が加えられ得る。そのため、本発明は開示した特定の実施形態に限定されず、本発明は添付の特許請求の範囲内に入る全ての実施形態を含むものとする。加えて、上記で明示的に触れた以外の多くの変形例が考えられる。

Claims (25)

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. 請求項２４に記載の前記コンピュータ・プログラムを、記録したコンピュータ可読記憶媒体。

Images