JP2016535476A - 暗号化鍵の管理、連携、および、配布のためのシステムと方法 - Google Patents

Abstract

例えば、ポリシーエンジンに接続されたデータベースにおいて複数のポリシーを定義し、記憶することと、ポリシーエンジンによって、セキュリティオブジェクトとセキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性を受け取ることと、を含む、セキュリティオブジェクトをオーケストレートするためのシステムと方法が記載される。加えて、ポリシーエンジンは、少なくとも１つのオブジェクト属性と少なくとも１つのオブジェクト属性に対応する複数のポリシーの少なくとも１つとに少なくとも部分的に基づいて、セキュリティオブジェクトの容認可能性を決定する。ポリシーエンジンに関連付けられた少なくとも１つの通信デバイスへのセキュリティオブジェクトは、セキュリティオブジェクトが容認可能と決定された場合に配布される。少なくとも１つの通信デバイスは、セキュリティオブジェクトに少なくとも部分的に基づいて通信を確立する。

Description

関連出願

[0001] 本願は、それらの全体が参照によってこの中に組み込まれる、２０１３年１０月７日に出願された仮出願第６１／８８７，６６２号と２０１４年３月１０日に出願された仮出願第６１／９５０，３６２号からの優先権を主張する。

[0002] 本発明の実施形態は、一般的に、通信システムで用いられるセキュリティオブジェクト（security objects）に関連し、より具体的には、セキュリティオブジェクトの生成（generation）、管理（management）、配布（distribution）、連携（federation）、および／または、オーケストレーション（orchestration）に関する。

[0003] セキュリティシステムにおいて、暗号化鍵は、暗号化処理の間に生データが暗号化されたデータにどのように変換され得るか、復号化処理の間に暗号化されたデータが生データにどのように変換され得るかを規定するパラメータまたはデータをいう。一般的に、暗号化鍵は、通信処理（communication transaction）において、ソースデバイス（例えば、送信側デバイス）とターゲットデバイス（例えば、受信側デバイス）の両方で利用可能にされる。暗号化鍵が普及している方法で用いられるとすると、セキュリティシステムに対する脅威への防御と応答のための暗号化鍵（並びに、他のセキュリティオブジェクト）の効果的な管理が、特に重要なこととなる。

[0004] 伝統的に、暗号化鍵の管理は、デバイスレベルで（例えば、通信処理に含まれるソースデバイスおよび／またはターゲットデバイスによって）、始められ、実行される。他方、通信管理は、伝統的に、より高いレベルで（例えば、ソースデバイスとターゲットデバイスのためのサーバによって）、集中的に管理される。最終結果は、暗号化管理が、通信管理と手続き的に非同期化されることであり得る。従って、現在の公開鍵インフラストラクチャ（public key infrastructure：ＰＫＩ）の事例において論証されているように、暗号化鍵のゆるんだ制御が結果として生じ得る。加えて、エンタープライズにおいて生成され、配布される対称鍵のゆるい制御も起こり得る。従って、最終結果は、通信管理または通信セキュリティにおける崩壊であり得る。同様な問題が、他のタイプの暗号化オブジェクトにも立ちはだかる。

[0005] 本開示は、限定はされないが、セキュリティオブジェクトの管理、配布、および、連携を含む、セキュリティオブジェクトオーケストレーション（security object orchestration）に関する実施形態を記載する。セキュリティオブジェクトは、限定はされないが、暗号化鍵、および、他のセキュリティオブジェクト（限定はされないが、ユーザ識別情報、証明書、生体識別データ、乱数発生データ、既知数の（determinate）乱数発生器データ、非既知数（non-determinate）の乱数発生器データ、ユーザ認証情報、ポリシーコンポーネント、オーガニゼーションセキュリティコンポーネントに関連付けられた他のコンポーネント、等）を含む。

[0006] セキュリティオブジェクトをオーケストレートするためのプロセスであって、該プロセスは、限定はされないが、ポリシーエンジンに接続されたデータベースにおいて複数のポリシーを定義し、記憶することと、ポリシーエンジンによって、セキュリティオブジェクトとセキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性とを受け取ることと、少なくとも１つのオブジェクト属性と少なくとも１つのオブジェクト属性に対応する複数のポリシーの少なくとも１つとに少なくとも部分的に基づいて、ポリシーエンジンでもって、セキュリティオブジェクトの容認可能性を決定することと、セキュリティオブジェクトが容認できると決定された場合、ポリシーエンジンに関連付けられた少なくとも１つの通信デバイスにセキュリティオブジェクトを配布することと、を含む。少なくとも１つの通信デバイスは、セキュリティオブジェクトに少なくとも部分的に基づいて、通信を確立する。

[0007] いくつかの実施形態において、セキュリティオブジェクトは暗号化鍵である。様々な実施形態において、少なくとも１つのオブジェクト属性は、セキュリティオブジェクト、セキュリティオブジェクトを生成する第１のデバイス、セキュリティオブジェクトを送る第２のデバイス、セキュリティオブジェクトを受け取る第３のデバイス、第１のデバイスに関連付けられた第１のユーザ、第２のデバイスに関連付けられた第２のユーザ、および、第３のデバイスに関連付けられた第３のユーザの内の少なくとも１つの特徴を備える。

[0008] いくつかの実施形態に従って、少なくとも１つのオブジェクト属性は、セキュリティオブジェクトサイズ、セキュリティオブジェクトが生成された時間、セキュリティオブジェクトが生成された地理位置、セキュリティオブジェクトの分類、鍵ソースに関連付けられた役割、ソースデバイスに関連付けられた役割、および、ターゲットデバイスに関連付けられた役割の内の少なくとも１つを備える。

[0009] いくつかの実施形態において、複数のポリシーは、セキュリティオブジェクトサイズが所定のサイズの範囲の中にある場合にセキュリティオブジェクトを容認することを備える。様々な実施形態において、複数のポリシーは、セキュリティオブジェクトが生成された時間が所定の時間間隔の中にある場合にセキュリティオブジェクトを容認することを備える。

[0010] いくつかの実施形態において、複数のポリシーは、セキュリティオブジェクトが生成された地理位置が所定のエリアの中にある場合にセキュリティオブジェクトを容認することを備える。いくつかの実施形態に実装されるように、複数のポリシーは、セキュリティオブジェクトの分類が所定のセキュリティオブジェクト分類グループと関連付けられている場合にセキュリティオブジェクトを容認することを備える。いくつかの実施形態において、複数のポリシーは、鍵ソース、ソースデバイス、または、ターゲットデバイスに関連付けられた役割が役割の所定のグループに関連付けられている場合にセキュリティオブジェクトを容認することを備える。

[0011] プロセスは、更に、鍵ソースに不認可（rejection）インジケータを送ることと、鍵ソースにセキュリティオブジェクトの不適当な点を知らせるヒントを送ることと、を含み、ここにおいて、セキュリティオブジェクトは鍵ソースから受け取られる。

[0012] いくつかの実施形態において、ポリシーエンジンによってセキュリティオブジェクトを受け取ることは、ポリシーエンジンによって、セキュリティオブジェクトを生成するための要求を受け取ることと、ポリシーエンジンによって、セキュリティオブジェクトを生成することと、を含む。

[0013] 様々な実施形態に従って実装されるように、セキュリティオブジェクトをオーケストレートするためのプロセスは、限定はされないが、第１の鍵オーケストレーションデバイスの第１のデータベースにおいて第１の複数のポリシーを定義し、記憶することを含む。第１のデータベースは、第１のエンタープライズと関連付けられる。プロセスは、更に、第１のエンタープライズと関連付けられた第１の鍵オーケストレーションデバイスを用いて受け取ることを含む。セキュリティオブジェクトとセキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性は、第２のエンタープライズに関連付けられた第２の鍵オーケストレーションデバイスからである。加えて、プロセスは、少なくとも１つのオブジェクト属性と少なくとも１つのオブジェクト属性に対応する第１の複数のポリシーの少なくとも１つとに少なくとも部分的に基づいて、第１の鍵オーケストレーションデバイスを用いて、セキュリティオブジェクトの容認可能性を決定することと、第１のエンタープライズに関連付けられた第１の通信デバイスにセキュリティオブジェクトを配布することと、を含み得る。

[0014] いくつかの実施形態において記載されるように、プロセスは、更に、第２の鍵オーケストレーションデバイスの第２のデータベースにおいて第２の複数のポリシーを定義し、記憶することを含む。少なくとも、第１の複数のポリシーの第１の部分と第２の複数のポリシーの第２の部分は同じである。

[0015] いくつかの実施形態において、プロセスは、更に、第１の鍵オーケストレーションデバイスから第２の鍵オーケストレーションデバイスに、セキュリティオブジェクトを送ることと、第２のエンタープライズに関連付けられた第２の通信デバイスにセキュリティオブジェクトを配布することと、を含み、ここにおいて、第１の通信デバイスと第２の通信デバイスはセキュリティオブジェクトに基づき通信を確立し得る。

[0016] 様々な実施形態において、プロセスは、更に、第１の鍵オーケストレーションデバイスから第２の鍵オーケストレーションデバイスに、セキュリティオブジェクトを送ることと、少なくとも１つのオブジェクト属性と少なくとも１つのオブジェクト属性に対応する第２の複数のポリシーの少なくとも１つとに少なくとも部分的に基づいて、第２の鍵オーケストレーションデバイスを用いて、セキュリティオブジェクトの容認可能性を決定することと、第２のエンタープライズに関連付けられた第２の通信デバイスにセキュリティオブジェクトを配布することと、を含む。第１の通信デバイスと第２の通信デバイスは、セキュリティオブジェクトに基づいて通信を確立し得る。

[0017] 様々な実施形態に実装されるように、セキュリティオブジェクトとセキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性とを第２の鍵オーケストレーションデバイスから受け取ることは、第２のオーケストレーションデバイスから第１の鍵オーケストレーションデバイスによって、セキュリティオブジェクトを生成するための要求を受け取ることと、要求に応答して、第１のエンタープライズに関連付けられた鍵ソースを用いて、セキュリティオブジェクトを生成することと、を含む。

[0018] いくつかの実施形態において、コンピュータ読出し可能な媒体はコンピュータ読出し可能な命令を備え、実行されたとき、プロセッサに、データベースにおいて複数のポリシーを定義させ、セキュリティオブジェクトとセキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性とを受け取らせ、少なくとも１つのオブジェクト属性と少なくとも１つのオブジェクト属性に対応する複数のポリシーの少なくとも１つとに少なくとも部分的に基づいて、セキュリティオブジェクトの容認性を決定させ、セキュリティオブジェクトが容認可能であると決定された場合に、プロセッサに関連付けられた少なくとも１つの通信デバイスにセキュリティオブジェクトを配布させる。少なくとも１つの通信デバイスは、セキュリティオブジェクトに少なくとも部分的に基づいて通信を確立する。いくつかの実施形態では、セキュリティオブジェクトは暗号化鍵である。

[0019] 様々な実施形態において、少なくとも１つのオブジェクト属性は、セキュリティオブジェクトサイズ、セキュリティオブジェクトが生成された時間、セキュリティオブジェクトが生成された地理位置、セキュリティオブジェクトの分類、鍵ソースに関連付けられた役割、ソースデバイスに関連付けられた役割、および、ターゲットデバイスに関連付けられた役割の内の少なくとも１つを備える。

[0020] いくつかの実施形態において実装されているように、複数のポリシーは、セキュリティオブジェクトサイズが所定のサイズの範囲にはいる場合、セキュリティオブジェクトが生成された時間が所定の時間間隔の中にある場合、セキュリティオブジェクトが生成された地理位置が所定のエリアの中にある場合、セキュリティオブジェクトの分類が所定のセキュリティオブジェクト分類グループに含まれる場合、および、鍵ソース、ソースデバイス、または、ターゲットデバイスに関連付けられた役割が役割の所定のグループに関連付けられている場合の内の少なくとも１つの場合にセキュリティオブジェクトを容認すること、を備える。

[0021] 図１は、様々な実施形態に従った、一般的な暗号化鍵オーケストレーションシステムの例を示す概略ブロック図である。 [0022] 図２は、様々な実施形態に従った、暗号化鍵オーケストレーションシステムの例を示す概略ブロック図である。 [0023] 図３は、様々な実施形態に実装された、暗号化鍵連携システムの例を示した概略ブロック図である。 [0024] 図４は、いくつかの実施形態に従った、鍵オーケストレーションサービスを消費する通信デバイスの例を示す概略ブロック図である。 [0025] 図５は、いくつかの実施形態に従った、要求を発行し、暗号化鍵を受け取るための要求認証プロセスの例を示すプロセスフロー図である。 [0026] 図６は、様々な実施形態に従った、様々な鍵オーケストレーションシステムに実装される通信デバイスレジストレーションプロセス（communication device registration process）の例を示すプロセスフロー図である。 [0027] 図７は、様々な実施形態に従った、鍵管理および配布プロセスの例を示すプロセスフロー図である。 [0028] 図８は、様々な実施形態に従った、鍵連携プロセスの例を示すプロセスフロー図である。 [0029] 図９は、様々な実施形態に従った、暗号化鍵管理および配布プロセスの例を示すプロセスフロー図である。

詳細な説明

[0030] 様々な実施形態の以下の記載において、これの一部を形成し、例示によって発明が実施され得る特定の実施形態が示される添付の図面への参照がなされる。他の実施形態が利用され得、構成の変更が本開示に開示された様々な実施形態の範囲から逸脱することなくなされ得ることが理解されるべきである。

[0031] この中に記載された実施形態は、概括的に、セキュリティオブジェクトオーケストレーション（security object orchestration）に関する。セキュリティオブジェクトオーケストレーションは、セキュリティオブジェクトの管理（management）、配布（distribution）、連携（federation）を含み得る。セキュリティオブジェクトは、暗号化鍵と他のセンシティブなオブジェクト（限定はされないが、ユーザ識別情報、証明書、生体識別データ、乱数発生データ、既知数の（determinate）乱数発生器データ、非既知数の（non-determinate）乱数発生器データ、ユーザ認証情報、ポリシーコンポーネント、オーガニゼーションセキュリティコンポーネント（organization security component）に関連付けられた他のコンポーネント、等）を含み得る。本開示において、暗号化鍵ベースのオーケストレーションが、セキュリティオブジェクトオーケストレーションのシステムと方法の例として、様々な実施形態の中で記載される。オーケストレーションシステムと方法は上述のものを含む他のセキュリティオブジェクトに対して同様に適用可能であることが理解されるべきである。

[0032] この中で用いられるものとして、「鍵オーケストレーション（key orchestration）」とは、１つまたはそれより多くのエンタープライズにおける鍵管理（key management）、鍵連携（key federation）、鍵配布（key distribution）の行為の組み合わせのことを指し得る。例えば、記載された実施形態は、１つまたはそれより多くのエンタープライズにおいて暗号化を利用することと相互に関連がある暗号化鍵情報のオーケストレーションと関連付けられ得る。「エンタープライズ鍵管理（enterprise key management）」は、データを暗号化すること、ｅｍａｉｌに署名すること、ｗｅｂサービスを認証すること、および／または、他の可能性のある使用のために必要とされる非対称および対称鍵の複数の使用を管理すること、および／または、監督することを含み得る。これは、また、無線、セルラ、衛星、および、インターネットプロトコルベースの通信を含むための、通信システムのための暗号化管理を含む。「エンタープライズ鍵連携（enterprise key federation）」は、連合する組織（例えば、エンタープライズ）の間の確立された信用に基づき、複数の異なる鍵オーケストレーションプラットホーム（各々、異なる連合する組織に関連付けられる）への鍵情報の連携を調整することと、協議して取り決めることとを含み得る。「鍵配布（key distribution）」は、ローカルなエンタープライズ、および／または、異なるエンタープライズの中での暗号化オペレーションをサポートするために、鍵素材の集中化された配布（例えば、プッシュ（pushing）、または、フォワード（forwarding））を言い得る。特に、鍵配布は、適切な暗号化鍵を適切に関連付けられたデバイス（例えば、ソースデバイスまたはターゲットデバイスのいずれかであり得る通信デバイス）に割り当てること、または、別な方法で送ることに関係し得る。

[0033] 鍵オーケストレーションの実施形態（例えば、要求ハンドラ（request handler）と種々のサポートデータベースに接続された管理要求ハンドラ（management request handler）等の鍵オーケストレーションデバイス）は、集中型のユーザインターフェースを介して、暗号化鍵の管理、連携、および、配布の制御を提供する。そのような鍵オーケストレーションデバイスは、通信、インフラストラクチャ、および、アプリケーションに関連付けられた暗号化鍵を管理することの集中型のシステム、および／または、方法を提供し得る。そのような鍵オーケストレーションは、また、デバイスエンロールメント（device enrollment）を管理し、暗号化能力に関係したデバイス健全性をモニタし、鍵オーケストレーション行為についてのステータスをモニタし得る。そのような能力は、通信、アプリケーション、および、インフラストラクチャの管理に関連付けられた監査行為をサポートするために、頑強な処理報告を可能にし得る。

[0034] 鍵オーケストレーションは、通信システム以外の追加のシステムについて影響され得る。鍵オーケストレーションの他の実装例は、アプリケーション暗号化管理（application encryption management）、仮想化暗号化管理（virtualization encryption management）、記憶暗号化管理（storage encryption management）、および／または、ユーザ識別暗号化管理（user identity encryption management）を含む。端的に言えば、アプリケーション、通信、または、インフラストラクチャが、暗号化（または、セキュリティオブジェクトを用いる他のタイプのセキュリティメカニズム）と鍵（または、セキュリティオブジェクト）の使用を必要とする場合、記載されたような利点を与えるために、オーケストレーションが適用され得る。通信システムは、限定はされないが、無線通信、セルラ通信、転送制御プロトコル／インターネットプロトコル（transmission control protocol /internet protocol：ＴＣＰ／ＩＰ）ベースの通信、衛星通信機器、等を含み得る。アプリケーションシステムは、限定はされないが、ボイスオーバーインターネットプロトコル（voice-over-internet protocol：ＶＯＩＰ）アプリケーション、仮想化（virtualization）、識別と認証（identification and authentication）、メッセージング（messaging）、ローカルストレージ（local storage）を含み得る。インフラストラクチャシステムは、限定はされないが、ストレージソリューション、物理的安全保護インフラストラクチャ（physical security infrastructure）、および、医用機器を含む。

[0035] 特定の実施形態において、鍵オーケストレーションデバイスは、集中型の方法で、複数の形式の通信デバイスにわたる暗号化鍵ライフサイクル行為（encryption key lifecycle activities）を可能にし得る。鍵オーケストレーションデバイスは、既存のシステムとの相互運用性のための鍵管理についての業界標準を活用し得、例えば、鍵オーケストレーションの一部として適用された鍵管理のためのプロトコルを使用し得る。適用された鍵オーケストレーションと鍵管理だけとの間の区別は、通信システムのための暗号化鍵管理と鍵配布において説明され得る。既存の関係を切断する前に新たな暗号化関係をつくるための要求を与えられると、典型的な通信システムは、通信の新たなラインを確立するために管理ステップが行われる前に通信を切断するので、鍵更新コマンド（rekey commands）を利用することができない。しかし、鍵更新コマンドは、−ストレージ、アプリケーション、および、仮想化ソリューションを含むために−インフラストラクチャのために働き得、そこでは、サービスが、管理された性能の集中型の制御の損失なく再確立され得る。

[0036] 鍵オーケストレーションのシステムアーキテクチャは、例えば、鍵管理相互運用性プロトコル（key management interoperability protocol：ＫＭＩＰ）等のサポートされるシステムのための標準ベースのアプローチの使用を可能にするが、また、物理的安全保護インフラストラクチャ（physical security infrastructure）、仮想化アプリケーション、衛星通信システム、および、医用機器等の非標準システムのためのサポートインターフェースを開発するための性能を可能にするよう構成され得る。これは、サポートインターフェースから構造上分離したメッセージハンドリングによって達成され得る。純粋にＫＭＩＰの例を用いると、ストレージデバイスは、「鍵更新（rekey）」コマンドを受け取り得、通信機器は、「プット・アンド・ノーティファイ（put-and-notify）」コマンドを受け取り、セルラデバイスは、鍵管理および生成システムコンポーネント（key management and generation system components）にリレーされるように鍵オーケストレーションデバイスに「ゲット・メッセージ（get messages）」を送るためにセルラデバイスに知らせる、待ち行列に入れられた「ノーティファイ（notify）」コマンドを要求し得る。そのような態様を実装する例示のシステムが以下で検討される。

[0037] この中に記載された実施形態は、集中型のトップダウンのエンタープライズ暗号化鍵管理暗号化鍵（例えば、限定はされないが、対称鍵、非対称鍵、等）、並びに、セキュリティシステムで用いられる他のセキュリティオブジェクトを実装するために、鍵オーケストレーションデバイスを含み得る。暗号化のそのような集中型のトップダウン制御は、所与のエンタープライズのためであり得る。実施形態は、デバイスレジストレーション（device registration）、ユーザレジストレーション（user registration）、システムとユーザの初期化（system and user initialization）、鍵素材の実装（key material installation）、鍵確立（key establishment）、鍵レジストレーション（key registration）、オペレーショナルユース（operational use）、鍵保管（key storage）、鍵配布（key distribution）、鍵更新（key update）、鍵リカバリ（key recovery）、鍵レジストレーション解除（key de-registration）、鍵破壊（key destruction）、鍵取り消し（key revocation）、等の内の少なくとも１つを実装する暗号鍵ライフサイクル機能のために、エンタープライズ鍵管理通信システム、アプリケーション、および、インフラストラクチャ上に、協調的なＫＭＩＰを実装することを含み得る。

[0038] この中で参照されることとして、暗号化鍵に関連付けられた「鍵属性（key attribute）」（属性、暗号化属性、等）は、暗号化鍵に関連付けられた特徴、暗号化鍵の暗号法のまたはセキュリティの特徴、暗号化鍵の暗号法のアルゴリズム、暗号化鍵を生成し／送り／受け取るデバイス、デバイスのユーザ、等に関連付けられた特徴のことを言い得る。各暗号化鍵は、少なくとも１つの鍵属性と関連付けられ得る。暗号化鍵は、データ値で示される関連した鍵属性とともに送られ、および／または、受け取られ得る。

[0039] この中に参照されるものとして、「ポリシー（policy）」は、暗号化鍵を、その暗号化鍵に関連付けられた鍵属性に基づいて管理するルールであり得る。
特定の実施形態において、ポリシーは、特定の暗号化鍵が容認可能な暗号化鍵であるかどうかを規定し得る。そのような容認可能性は、暗号化鍵（例えば、暗号化鍵に関連付けられた鍵属性から示されるように）が十分に安全であり得るかどうかについて、安全保障と暗号法の考慮に基づき得る。言い換えると、特定の通信処理のために生成された暗号化鍵は、暗号化鍵がその通信処理のために許可されるべきか不認可されるべきかについて評価されるために、ポリシーによる検査のために提示され得る。

[0040] いくつかの実施形態は、モバイル通信デバイス（例えば、無線デバイス、等）のための鍵オーケストレーションのためのインターフェースを含み、または、衛星通信における遠隔測定やペイロードを含むために、無線／衛星通信システムのための鍵オーケストレーションのためのインターフェースを提供する。該実施形態の特定の実装例は、限定はされないが、現金自動支払機（ＡＴＭ）、銀行口座インターフェース、等の銀行アプリケーションのためのインターフェースを含み得る。銀行アプリケーションのためのインターフェースは、任意のモバイルまたは非モバイルデバイス上に実装され得る。実施形態は、仮想化を含むアプリケーションのために鍵オーケストレーションのためのインターフェースを提供し得、ルータ、交換機、仮想プライベートネットワーク（virtual private network：ＶＰＮ）設備、ファイアウォール、侵入検知システム（intrusion detection system：ＩＤＳ）、侵入防止システム（intrusion prevention system：ＩＰＳ）、トークナイザー（tokenizer）、等を含むために、ネットワークインフラストラクチャのための鍵オーケストレーションのためのインターフェースを提供する。

[0041] 例えば、集中型の暗号化管理が、プライベートおよび／またはパブリックな環境の両方において、対称暗号化鍵または非対称暗号化鍵のために提供され得る。いくつかの実施形態において、既存のネットワークインフラストラクチャ情報が、ネットワークインフラストラクチャの動作／非動作のステータス、または、暗号化鍵を容易に容認することができる機器（例えば、既存のハードウェア／ソフトウェアが暗号化鍵を容認するための機器上にインストールされ得る）に基づいてネットワークインフラストラクチャのための暗号化鍵を配布し、管理することに基づいて、暗号化鍵を配布するために費やされ得る。

[0042] 実施形態は、所与の暗号化管理動作のポイント（例えば、プッシュキーイベント（push-key event）において）で利用可能でない通信デバイスのための暗号化鍵処理情報を待ち行列に入れ得る。加えて、この中に記載された実施形態は、暗号化鍵ライフサイクル情報（サポートされるインフラストラクチャのため）と成功した暗号化鍵管理処理を一元的に表示し得る。加えて、または、代替的に、失敗メッセージおよび／または不成功の暗号化鍵管理処理の原因が表示され得る。

[0043] いくつかの実施形態において、定時ベースで新たな非対称鍵を獲得するために通信デバイスのためのサービスインターフェースが提供され得る。加えて、定時ベースで新たな対称鍵を獲得するために通信デバイスのためのサービスインターフェースが提供され得る。いくつかの実施形態において、ユーザ起動ベースで新たな非対称鍵を獲得するために通信デバイスのためのサービスインターフェースが提供され得る。様々な実施形態において、ユーザ起動ベースで新たな対称鍵を獲得するために通信デバイスのためのサービスインターフェースが提供され得る。また、２つまたはそれより多くの鍵管理とオーケストレーションデバイスとの間の確立された信頼ベースの鍵交換に基づく暗号化鍵の連携された配布が、記載されたように、提供され得る。

[0044] いくつかの実施形態において、連携された対称鍵配布のための構成に基づいてローカルなエンタープライズインフラストラクチャに連携された対称鍵を配布することが提供され得る。様々な実施形態において、連携された非対称鍵配布のための構成に基づいてローカルなエンタープライズインフラストラクチャに連携された非対称鍵を配布することが提供され得る。加えて、複数のデバイスと分割鍵配布（split key distribution）を用いることにより連携された信用モデルを実装することが、安全に通信することが必要である２つの信用されないエンティティの間の信用を確立するために提供され得る。

[0045] 鍵オーケストレーションデバイス（例えば、管理要求ハンドラ（management request handler）と関連するコンポーネントは、この中に記載された機能を実行するための、ビジネスロジックモジュール（business logic module）、認証および承認モジュール（authentication and authorization module）、ポリシー行使モジュール（policy enforcement module）、システム一貫性／検証モジュール（system consistency/validation module）、等を含むサブモジュールを含み得る。

[0046] 図１は、様々な実施形態に実装されている、一般的な暗号化鍵オーケストレーションシステム１００の例の概略図である。様々な実施形態において、鍵オーケストレーションデバイス１１０は、少なくとも１つのソースデバイス１５０ａと少なくとも１つのターゲットデバイス１５０ｂとに接続され得る。鍵オーケストレーションデバイス１１０は、この中に記載される動作を実行するためにハードウェアとソフトウェアとで構成される、少なくとも１つのデスクトップコンピュータ、メインフレームコンピュータ、ラップトップコンピュータ、パッドデバイス、スマートホンデバイス、等を備え得る。例えば、鍵オーケストレーションデバイス１１０は、この中で記載される動作を実行するために好適なソフトウェアでもって構成される、好適な処理能力、メモリ、ユーザインターフェース（例えば、表示と入力）能力、および、通信能力を有する計算システムを備え得る。従って、特定の実施形態は、多くのビジネスおよび組織の環境において既にしばしば存在しているプロセッサデバイスを用いて、この中に記載された好適なソフトウェアプロセスでもってそのようなデバイスを構成することによって実装され得る。従って、そのような実施形態は、最小限の追加のハードウェアコストでもって実装され得る。しかし、鍵オーケストレーションデバイス１１０の他の実施形態が、この中に記載された動作を実行するために特別に構成された専用のデバイスハードウェア／複数のデバイスでもって実装されるシステムとプロセスに関係し得る。

[0047] 一般的に、ソースデバイス１５０ａは、暗号化（そして、従って、暗号化鍵）が必要とされ得るか、または、好まれ得る、データを送信する（または、通信を開始する）通信デバイスであり得る。ターゲットデバイス１５０ｂは、暗号化されている（例えば、暗号化鍵でもって）データを受信するための通信デバイスであり得る。様々な実施形態に従って、ソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂは、ＡＴＭであり得る。ソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂは、また、銀行口座情報を記憶し、銀行業務機能を実行するための任意のサーバまたはデバイスであり得る。特定の実施形態において、ソースデバイス１５０ａとターゲットデバイス１５０ｂの各々は、好適な処理および暗号化能力を持つモバイルスマートホン（限定はされないが、ｉＰｈｏｎｅ（登録商標）、Ａｎｄｒｏｉｄ（商標）ホン、等）、または、他の無線モバイル通信デバイスを含み得る。典型的な現代のモバイル通信デバイスは、電話通信電子回路、並びに、いくつかのプロセッサ電子回路、１つまたはそれより多くのディスプレイデバイスとキーパッド、および／または、他のユーザ入力デバイスを含む。更なる実施形態において、ソースデバイス１５０ａとターゲットデバイス１５０ｂの各々は、限定はされないが、電子スマートパッドデバイス（限定はされないが、ｉＰａｄ（登録商標）等）、ポータブルコンピュータ、等の好適な形式のモバイルホン、および／または、他の形式のポータブル電子通信デバイスを備え得る。暗号化鍵は、ソースデバイス１５０ａまたはターゲットデバイス１５０ｂのいずれか、および／または、その両方から発せられる。言い換えれば、ソースデバイス１５０ａまたはターゲットデバイス１５０ｂのいずれかが鍵ソース１７０であり得る。ソースデバイス１５０ａとターゲットデバイス１５０ｂは、同じエンタープライズまたは別個のエンタープライズに関連付けられ得る。他の実施形態では、ソースデバイス１５０ａとターゲットデバイス１５０ｂの一方または両方は、有線または無線デバイスと通信するのに好適な有線デバイスであってよい。

[0048] いくつかの実施形態において、鍵オーケストレーションデバイス１１０は、ソースデバイス１５０ａとターゲットデバイス１５０ｂに関連付けられたエンタープライズの一部であり得る。エンタープライズは、少なくとも１つのソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂに支配を有する組織またはセキュリティユニットであり得る。異なるエンタープライズに関連付けられたソースデバイス１５０ａとターゲットデバイス１５０ｂとの間の通信について、ソースデバイス１５０ａは第１のエンタープライズに関連付けられ得、ターゲットデバイス１５０ｂは第２の異なるエンタープライズに関連付けられ得る。エンタープライズは、企業、企業の中のサブグループ、自律的で独立なエンティティ、通信グループ、セキュリティプロバイダー、様々なエンティティ、組織、等であってよい。各鍵オーケストレーションデバイス１１０は、ソースデバイス１５０ａとターゲットデバイス１５０ｂ等の複数のデバイスのための鍵オーケストレーション行為を実行し得、鍵オーケストレーションのための階層型モデルを確立する。

[0049] 他の実施形態において、鍵オーケストレーションデバイス１１０は、ソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂに関連付けられたエンタープライズに接続された第三者サーバであり得る。従って、様々な実施形態が、エンタープライズの既存の通信システムとプロトコルを用いた暗号化鍵オーケストレーションの集中化に影響し得る。言い換えると、鍵オーケストレーションデバイス１１０は、通信、アプリケーション、および、インフラストラクチャのための既存の暗号化技術と協調するように実装され得る。鍵オーケストレーション（例えば、第三者またはその他による）は、鍵情報（例えば、暗号化鍵と関連する鍵属性１６０）のソースとターゲットの両方と相互作用し得る。従って、ソースデバイス１５０ａとターゲットデバイス１５０ｂが鍵情報を要求し得る要求モデル（request model）を維持するが、鍵オーケストレーションのトップダウン制御が達成され得る。

[0050] いくつかの実施形態において、鍵ソース１７０が鍵オーケストレーションデバイス１１０に接続され得る。鍵ソース１７０は、暗号化鍵（または、他の形式のセキュリティオブジェクト）が生成され得る任意のソースであってよい。いくつかの実施形態において、鍵ソース１７０は、鍵オーケストレーションデバイス１１０の部分（例えば、鍵オーケストレーションデバイス１１０の中の、または、鍵オーケストレーションデバイス１１０に接続されたモジュールまたはデータベース）であってよい。他の実施形態において、鍵ソース１７０は、鍵オーケストレーションデバイス１１０の外部のソースであってよい。鍵ソース１７０は、ソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂの１つまたはそれより多くは、それらの間の通信のための暗号化鍵を生成することができ得るソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂを含み得る。代替として、または、加えて、鍵ソース１７０は、ソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂと同じエンタープライズの内部または外部の鍵生成デバイス（ソースデバイス１５０ａおよびターゲットデバイス１５０ｂ以外）であってよい。これらの場合では、鍵ソース１７０は、鍵オーケストレーションデバイス１１０とは別々に実装された、既存の専用化された鍵生成デバイス（例えば、図２の鍵生成および管理デバイス２３０）であり得る。鍵ソース１７０の他の例は、図２の管理ユーザインターフェース２２０（例えば、暗号化鍵は、管理ユーザインターフェース２２０を介して、マニュアルで生成され得る）、図２の鍵連携インターフェース２６０（例えば、暗号化鍵は異なるエンタープライズから生成される）、生成された暗号化鍵を記憶する様々なデータベース、等を含み得る。

[0051] 様々な実施形態において、要求１７５が鍵オーケストレーションデバイス１１０に送られ得る。要求１７５は、暗号化鍵を生成するための要求であり得る。例えば、鍵オーケストレーションデバイス１１０自身が、要求１７５に応答して暗号化鍵を生成し得る（または、鍵オーケストレーションデバイス１１０に接続されたデータベースから取り出す）。他の例において、鍵オーケストレーションデバイス１１０は、同じまたは異なるエンタープライズの中の他のデバイス（例えば、鍵ソース１７０）からの暗号化鍵を要求し得る。

[0052] 要求１７５は、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、鍵オーケストレーションデバイス自身１１０、同じエンタープライズの中の第三者デバイス（例えば、管理ユーザインターフェース２２０、鍵管理インターフェース２４０、等）、異なるエンタープライズにおける第三者デバイス（例えば、図２の鍵連携インターフェースから）、等から発せられ得る。鍵オーケストレーションデバイス１１０の実施形態は、従って、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、要求デバイス（要求１７５を発行する）、鍵ソース１７０、等の間の仲介デバイスとして機能し得る。従って、鍵管理、配布、および、連携は、同じまたは異なるエンタープライズにおける様々なデバイスのために、効果的に管理され得る。

[0053] 一般的な暗号化鍵オーケストレーションシステム１００の中の様々なコンポーネント（例えば、鍵オーケストレーションデバイス１１０、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、鍵オーケストレーションデバイス自身１１０、要求１７５を発行するデバイス、鍵ソース１７０、等）は、任意の好適な有線または無線ネットワークを介して接続され得る。ネットワークは、安全が保たれているか、または、安全が保たれていなくてもよい。例えば、ネットワークは、限定はされないが、インターネット等の広域通信ネットワーク、または、１つまたはそれより多くのイントラネット、ローカルエリアネットワーク（local area network：ＬＡＮ）、イーサネット（登録商標）ネットワーク、メトロポリタンエリアネットワーク（metropolitan area network：ＭＡＮ）、ワイドエリアネットワーク（wide area network：ＷＡＮ）、それらの組み合わせ、等であってよい。特定の実施形態では、ネットワークは、限定はされないが、権限のない人またはエンティティによるネットワーク通信へのアクセスを禁じる、ファイアウォール、暗号化、または、他のソフトウェアまたはハードウェア構成、等の好適なセキュリティ態様をもって構成された１つまたはそれより多くの安全なネットワークを提示し得る。

[0054] いくつかの実施形態において、鍵属性１６０は、概括的に、暗号化鍵自身に関連付けられた特徴、暗号化鍵に関連付けられたデバイスの特徴、等を言い得る。言い換えると、鍵属性１６０は、暗号化鍵が生成されている、または、生成されようとしている時、場所、方法、何のためにか、何のデバイスをもってかを指し得る。鍵属性１６０の例は、限定はされないが、暗号化鍵サイズ、暗号化鍵の分類、暗号化鍵が生成された、または、生成されようとしている（例えば、鍵ソース１７０によって）時間、暗号化鍵が生成された、または、生成されようとしている（例えば、鍵ソース１７０によって）場所、鍵ソース１７０に関連付けられた役割、ソースデバイス１５０ａに関連付けられた役割、ターゲットデバイス１５０ｂに関連付けられた役割、鍵生成／記憶デバイスに関連付けられた役割、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、鍵生成／記憶デバイス、ソース１７０のユーザに関連付けられた役割、それらの組み合わせ、等を含み得る。

[0055] いくつかの実施形態では、鍵属性１６０は鍵サイズを含み得る。典型的に、鍵サイズが大きくなればなるほど（即ち、暗号化鍵が長くなればなるほど）、より大きなセキュリティが通信のために与えられ得る。また、鍵属性１６０は暗号化鍵の分類を含み得る。
様々な実施形態において、暗号化鍵の分類は、例えば、暗号化鍵が何のために使用され得るかといった、その利用性を指し得る。利用性の例は、（例えば、通信システムについて）、暗号化鍵がグローバルホッピング鍵（global hopping key）であるかどうか、暗号化鍵が秘密鍵であるかどうか、暗号化鍵が対称か非対称か、それらの組み合わせ、等を含み得る。

[0056] いくつかの実施形態において、鍵属性１６０は、暗号化鍵が生成された、または、生成されようとしている時間および／または場所を含む。記載されるように、暗号化鍵が生成され得る時間および／または場所は、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、および／または、任意の他の鍵ソースの観点から規定され得る。例えば、暗号化鍵が生成される（および／または、送られる、受信される）場合、暗号化鍵を生成する（および／または、送る、受信する）デバイス（例えば、鍵ソース１７０）の対応する時間が決定され得る。暗号化鍵は、時間を示すタイムスタンプとともに送信され／記憶され得る。同様に、暗号化鍵が生成され（および／または、送られ、受信される）場合、暗号化鍵を生成する（および／または、送る、受信する）デバイス（例えば、鍵ソース１７０）の対応する地理位置が決定され得る。暗号化鍵は、地理位置とともに送信され／記憶され得る。

[0057] 様々な実施形態において、鍵属性１６０は、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、鍵ソース１７０、他の鍵生成.／記憶デバイス、並びに、それらのユーザに関連付けられた役割を含み得る。特に、役割は、デバイス／ユーザが割り当てられたグループ／分類（例えば、デバイスの予め定められた任務、時間、地理位置、デバイスが暗号化鍵を生成しているか否か、デバイスが暗号化鍵を送っているか否か、デバイスが暗号化鍵を受け取っているか否か、等に基づく）、セキュリティクリアランスのレベル、デバイス／ユーザのタイプ、それらの組み合わせ、等のことを言い得る。特定の例では、各デバイス／ユーザは、少なくともセキュリティグループ（例えば、サーバに割り当てられた）に関連付けられ得る。各セキュリティグループの中で、サブグループは、デバイス／ユーザを更に下位分割するために存在し得る。グループ／サブグループは、任意の好適な人員によって予め定められ得る。他の、または、更なる実施形態において、グループ／サブグループは、暗号化鍵が生成されるときに決定され得る（例えば、地理位置、一日の時間、等のようなデバイスの現在の特性に基づいて）。

[0058] １つまたはそれより多くの鍵属性１６０が所与の暗号化鍵に関連付けられ得ることは、当技術において通常の技量をもつ人によって了解されるべきである。実際、様々な実施形態において実装されるように、暗号化鍵は、複数の鍵属性１６０と関連付けられ得る。暗号化鍵は、関連付けられた鍵属性１６０とともに、デバイス（例えば、鍵オーケストレーションデバイス１１０）に送信され得る。暗号化鍵と暗号化鍵に関連付けられた鍵属性１６０は、鍵属性１６０に関連した少なくとも１つのポリシーに従って検査され得る。そのようなプロセスは、関連するポリシーに対して鍵属性１６０を「投げかける（shooting）」、または、鍵属性１６０をポリシーによる「検査（inspection）」のために「提示する（presenting）」と言われ得る。

[0059] 暗号化鍵は、一般的に、一組のポリシー１１５によって管理され得る、
様々な実施形態において実装されるように、ポリシーは、鍵属性１６０のための判定基準を決定する少なくとも１つの規定されたルールのことを言い得る。いくつかの実施形態において、ポリシーエンジン（例えば、鍵オーケストレーションデバイス１１０、および／または、この中に記載された他のデバイスにはめ込まれたような）は、入力として、暗号化鍵と暗号化鍵に関連付けられた鍵属性を受け取り得る。ポリシーエンジンンは、暗号化鍵が鍵属性１６０に基づいて許可可能であり得るかどうかについての応答を出力し得る。特定の実施形態において、ポリシーエンジンは、２値の応答（例えば、容認されたか不認可されたか）を出力し得る。

[0060] 暗号化鍵と関連する鍵属性１６０は、通信処理あたり１回またはそれより多く、検査のために提示され得る。いくつかの実施形態において、暗号化鍵と関連する鍵属性１６０は、通信処理あたり１回（例えば、通信処理が起こる前だが、暗号化鍵が生成された後の開始段階で）、ポリシー１１５による検査のために提示されるよう求められるのみであってもよい。他の、または、更なる実施形態において、暗号化鍵と関連する鍵属性１６０は、定期的に、および／または、所与の通信処理のために暗号化鍵が変更される度ごとに、ポリシー１１５による検査のために提示されるよう求められ得る。ある場合には、いくつかの暗号化鍵が、所与の通信処理のために、ポリシー１１５による検査のために提示され得る。

[0061] ポリシーエンジンは、受信された鍵属性１６０を特定し得る。ポリシーエンジンは、関連するポリシー１１５を、ローカルまたは遠隔の記憶データベースから読み出し得る。他の実施形態において、ポリシーエンジンが予め定められたポリシー１１５の組に基づいて容認可能性を決定するように、ポリシーエンジンは、暗号化鍵に関連付けられた特定の鍵属性１６０（または、時には、全ての鍵属性１６０）を検査し得る。例えば、ポリシーエンジンは、関連するポリシー１１５に基づいて、暗号化鍵が生成され得る通信処理のために容認されるべきかどうかを決定し得る。

[0062] １つの限定ではない例において、ポリシー１１５は、暗号化鍵のサイズが所定の範囲の中になければならない（例えば、暗号化鍵のサイズが、１２６ビット、１９２ビット、２５６ビット、等を超す、および／または、下回らなければならない）ことを要求する。ある場合には、ポリシー１１５は、暗号化鍵のサイズが特定のサイズ（例えば、２６５ビット、等）でなければならないことを要求する。

[0063] ポリシー１１５は、鍵属性１６０の地理位置が所定の位置に関連付けられる（または、関連付けられない）、および／または、所定のエリアの中にある（または、中にない）ことを要求し得る。例えば、暗号化鍵の地理位置属性（例えば、暗号化鍵の生成、送る、および／または、受け取る地理位置によって規定される）が「危険（danger）」ゾーンに関連付けられる場合、ポリシーエンジンは暗号化鍵を不認可とし得る。これは、暗号化鍵が危険ゾーンにおいて危うくされる高い公算があるからである。他方、暗号化鍵の地理位置属性が「安全な（safe）」ゾーンに関連付けられている場合、暗号化鍵は通信処理について許可され得る。これは、最大でも、危うくされるセキュリティ鍵の低い公算があり得るからである。更なる実施形態において、「中立（neutral）」ゾーンは安全なゾーンであってよく、または、代替的に、危うくされたセキュリティ鍵の中程度の公算に関連付けられたゾーンであってよい。

[0064] 他の限定ではない例において、ポリシー１１５は、鍵属性１６０の時間属性が所定の時間期間内にある（または、期間内にない）ことを要求する。ポリシー１１５は、暗号化鍵の生成、送り、および／または、受け取りに関連付けられた時間属性（例えば、タイムスタンプ）が所定の時間期間外（例えば、午前３時、暗号化鍵の容認可能な生成、送信、および／または、受信の時刻が午前９時から午後５時の間である場合）であるとの根拠で、暗号化鍵を不認可とし得る。

[0065] 様々な実施形態において、ポリシー１１５は、鍵属性１６０の役割属性が所定の容認されたグループ内の暗号化鍵生成／送り／受け取りデバイス（および、該デバイスの関連したユーザ）に関連付けられている場合、暗号化鍵を許可し得る。いくつかの例では、エンタープライズ内の第１のセキュリティグループに関連付けられたソースデバイス１５０ａ（ターゲットデバイス１５０ｂ、または、他のソースデバイス１７０）が暗号化鍵を生成し、ポリシー１１５による検査のために暗号化鍵を提出し得る。ポリシーエンジンが、ソースデバイス１５０ａ（ターゲットデバイス１５０ｂ、または、他のソースデバイス１７０）が容認されたグループの一部である（例えば、第１のセキュリティグループが容認されたグループにはいる）場合、暗号化鍵は、暗号化が生成される通信処理のために許可され得る。

[0066] 複数のポリシー１１５が、包括的な暗号化鍵管理スキームのために提携して動作し得ることが、当技術分野において通常の技量を有する者によって理解されるべきである。
これは、各々が少なくとも１つの異なる鍵属性１６０を規制し得る複数のポリシー１１５が、ポリシーエンジンに提示される暗号化鍵を規制するための一組のポリシー１１５に集められ得ることを意味する。

[0067] 他の例において、他の鍵ソース１７０（例えば、ソースデバイス１５０ａやターゲットデバイス１５０ｂ以外）が、ソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂ間の通信処理のために、ソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂに配布（または、プッシュ）されるべく、暗号化鍵を生成し得る。ポリシーエンジン（例えば、鍵オーケストレーションデバイス１１０）は、暗号化鍵が許可可能かどうかを決定するために、鍵属性１６０を検査し得る。暗号化鍵が許可可能であると決定されることに応答して、鍵オーケストレーションデバイスは、通信処理のために、ソースデバイス１５０ａおよび／またはターゲットデバイス１５０ｂに暗号化鍵を配布することを決定する。

[0068] 様々な実施形態において、ポリシーエンジンが暗号化鍵を不認可とする場合、ポリシーエンジンは、鍵ソース１７０に、不認可インジケータ（例えば、「不認可（denied）」メッセージを送信し得る。鍵生成デバイスは、検査の第２ラウンドのために、ポリシーエンジンに（第２の暗号化鍵に関連付けられた鍵属性１６０と共に）提示されるべき第２の暗号化鍵を再設計し得る。他の実施形態において、ポリシーエンジンが暗号化鍵を不認可とした場合、ポリシーエンジンは、どの鍵属性が不認可を引き起こしたか、および／または、どうあるべきかについての失敗の原因（例えば、ヒント）と共に、鍵ソースに、「不認可（denied）」メッセージを送信し得る。

[0069] 例えば、午前４時４９分の時間属性、「安全なゾーン（safe zone）」の地理位置属性、および、「セキュリティグループＡ（security group A）」の役割属性を含む鍵属性１６０をもった暗号化鍵が、一組のポリシー１１５に提示され得る。ポリシーエンジンは、暗号鍵が午前５時から午後９時の間で、「安全なゾーン（safe zone）」または「中立なゾーン（neutral zone）」のいずれかにおいて、セキュリティグループＡ−Ｃのために生成された場合、暗号化鍵を許可し得る。該暗号化鍵は、午前５時から午後９時の間に生成されていないとして不認可とされ得る。ポリシーエンジンは、時間属性のヒント（例えば、１１分で、午前５時の後に暗号化鍵を生成すべきこと）と共に、「不認可（denied）」メッセージを送信し得る。

[0070] 従って、鍵オーケストレーションデバイス１１０は、暗号化鍵を管理し、暗号化鍵を配布するために構成され得る。言い換えれば、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、他の鍵ソース１７０、等自身が、鍵オーケストレーションデバイス１１０について記載された方法での暗号化の配布や管理の能力に欠けるので、鍵オーケストレーションデバイス１１０は、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、他の鍵ソース１７０、等の間の仲介者としての役割を持ち得る。鍵オーケストレーションデバイス１１０は、この中に記載されたような特徴毎に複数のモジュールを含み得る（または、遠隔のモジュールに接続され得る）。
加えて、一般的な暗号鍵オーケストレーションシステム１００は、この中に記載されたような暗号化鍵連携スキームを構成するために、少なくとも１つの他の類似の一般的な暗号化鍵オーケストレーションシステム１００と接続され得る。

[0071] 図２は、様々な実施形態に従った、暗号化鍵オーケストレーションシステムの例を示す概略図である。いくつかの実施形態において、暗号化鍵オーケストレーションシステム２００は、一般的な暗号化鍵オーケストレーションシステム１００の詳述された実装例を示す。構成上の観点から、暗号化鍵オーケストレーションシステム２００について示されたような実施形態は、メッセージハンドリングと、鍵生成技術、他の鍵オーケストレーションデバイス、サポートされる通信システム、アプリケーション、および、インフラストラクチャとの相互運用性とを中心とし得る。

[0072] 鍵オーケストレーションデバイス１１０は、少なくとも、管理要求ハンドラ（management request handler）２０５、要求ハンドラ（request handler）２１０、並びに、関連付けられたデータベース（例えば、ローカル鍵データベース（local key database）２７０、処理データベース（transactions database）２７５、ポリシーデータベース（policy database）２８０、ローカルユーザレポジトリ（local user repository）２８５、構成データベース（configuration database）２９０、デバイスインベントリデータベース（device inventory database）２９５）を含み得る。

[0073] 様々な実施形態において、管理要求ハンドラ２０５は、ポリシーベースの暗号化鍵管理、配布、および、連携のために実装され得るポリシーエンジンを含み得る（または、である）。管理要求ハンドラ２０５は、記載された様々なコンポーネントの間の仲介層であり得るので、ポリシーベースの暗号化鍵管理、配布、および、連携の素早い統合が、システムレベルのメッセージハンドリングへの変更の必要なく、既存のシステムに加えられ得る。管理要求ハンドラ２０５は、所与のエンタープライズに関連付けられた様々な通信デバイス（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．デバイスＮ ２５０ｎ、等）のためのトップダウン管理を提供し得る。様々な実施形態において、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．、デバイスＮ ２５０ｎの各々は、暗号化鍵が生成される特定の通信処理に応じてソースデバイス１５０ａ、または、ターゲットデバイス１５０ｂであり得る。

[0074] 管理要求ハンドラ２０５と要求ハンドラ２１０は、エージェント・インターフェース関係（agent-interface relationship）にある。即ち、要求ハンドラ２１０は、管理要求ハンドラ２０５とエンタープライズに関連付けられた様々な通信デバイス（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．デバイスＮ ２５０ｎ、等）との間のインターフェースとしての役割を持ち得る。管理要求ハンドラ２０５と要求ハンドラ２１０との間の通信は、サポート機構（support structure）２１５によって容易にされ得る。サポート機構２１５は、管理要求ハンドラ２０５と要求ハンドラ２１０との間のインターフェースのために、好適な通信プロトコル、管理アプリケーション、インフラストラクチャ、通信アプリケーションプログラムインターフェース（ＡＰＩ）、構成（configurations）、変換（translations）、等を提供し得る。

[0075] 要求ハンドラ２１０は、様々な通信デバイスから、鍵生成要求１７５および／または暗号化鍵を受け、サポート機構２１５からの支援でもって、それらを管理要求ハンドラ２０５に関連付ける。要求ハンドラ２１０は、また、管理要求ハンドラ２０５の応答（いくつかの実施形態ではヒントを含む）および／または暗号化鍵を、サポート機構２１５からの支援でもって、様々な通信デバイスに関連付け得る。

[0076] 様々な実施形態において、管理要求ハンドラ２０５は、暗号化鍵を生成するために要求１７５を受け得る。様々なコンポーネントは、要求１７５を、管理要求ハンドラ２０５に送ることができる。いくつかの実施形態では、管理要求ハンドラ２０５は、エンタープライズに関連付けられた様々な通信デバイス（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．デバイスＮ ２５０ｎ、等）から要求１７５を受け得る。要求１７５は、記載されたように、デバイスと管理要求ハンドラとの間のインターフェースとしての役割を持ち得る要求ハンドラ２１０によって関連付けられ得る。鍵連携インターフェース（key federation interface）２６０、管理ユーザインターフェース（management user interface）２２０、および、鍵管理インターフェース（key management interface）２４０は、また、要求１７５を管理要求ハンドラに送り得る。

[0077] 非要求駆動型（non-request-driven）の実施形態において、管理要求ハンドラ２０５は、少なくとも１つの鍵ソースから暗号化鍵を受け得る。鍵ソース１７０は、エンタープライズの中に実装された好適な既存の鍵生成装置であってよい、鍵生成および管理デバイス２３０であり得る。言い換えると、鍵生成および管理デバイス２３０は、エンタープライズの通信システムの内部または外部の既存のスキームを示し得る。例えば、鍵生成および管理デバイス２３０は、安全なネット機器に関連付けられた任意の好適なネーティブプロトコル（native protocol）であってよい。

[0078] 鍵管理インターフェース２４０の実施形態は、鍵生成および鍵管理能力の内的統合、並びに、既存のソリューションとの外的インターフェースを示し得る。これは、鍵管理インターフェース２４０が、鍵生成および管理デバイス２３０（暗号化鍵を生成し得る）と管理要求ハンドラ２０５（ポリシー１１５に基づいて暗号化鍵の鍵属性１６０を検査する）との間で釣り合いをとられ得るからである。例えば、鍵管理インターフェース２４０は、鍵オーケストレーションデバイス１１０との標準の暗号化管理メッセージング言語を維持する翻訳インターフェース（translation interface）であり得る。これは、既存のソリューション（例えば、鍵生成および管理デバイス２３０）と鍵オーケストレーションプラットホーム（例えば、管理要求ハンドラ２０５）との間のエンタープライズ相互運用性を可能にし得る。従って、ポリシーベースの暗号化鍵オーケストレーションシステムと方法は、様々な形式のセキュリティオブジェクト（例えば、暗号化鍵）生成プロトコルとともに実装され得る。

[0079] 加えて、または、代替的に、要求駆動型（request-driven）の実施形態において、管理ユーザインターフェース２２０は、要求１７５を管理要求ハンドラ２１０に送り得る。管理ユーザインターフェース２２０は、相互運用性を保証するために、この中に記載された他のコンポーネントと同じＡＰＩを利用し得る。管理ユーザインターフェース２２０は、指定された管理ユーザに対して、データを受け、表示するために、好適なユーザ入力および表示デバイスを含み得る。特定の実施形態では、管理ユーザインターフェース２２０は、スマートホンまたはタブレット等のモバイルデバイスを含み得る。管理ユーザインターフェース２２０は、また、有線のデバイスを含んでもよい。

[0080] いくつかの実施形態において、鍵連携インターフェース２６０は、管理要求ハンドラ２０５に要求１７５を送り得る。鍵連携インターフェース２６０は、異なるエンタープライズ（記載された、同じまたは類似の鍵オーケストレーションシステムと方法を利用し得る）と関連付けられた第２の鍵連携インターフェース（限定はされないが、鍵連携インターフェース２６０、等）と通信している。様々な通信デバイス（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．、デバイスＮ ２５０ｎ、等）の１つが、異なるエンタープライズからの他のデバイスとの通信を望む場合（または、その逆）、要求１７５は、（第２のエンタープライズの鍵連携インターフェース２６０から）現在のエンタープライズの鍵連携インターフェース２６０に送られ得る。いくつかの実施形態において、鍵連携インターフェース２６０が、信用されるエンタープライズ間の関係を特定している場合、要求１７５は、管理要求ハンドラ２０５に直接送られ得る。

[0081] いくつかの実施形態において、要求１７５の代わりに、または、追加して、暗号化鍵、並びに、「許可（allowed）」および「不認可（denied）」メッセージが、鍵連携インターフェース２６０（現在のエンタープライズと第２のエンタープライズの）の間で送られ、受け取られ得る。暗号化鍵とその関連付けられた属性１６０は、管理要求ハンドラ２０５により（ポリシー検査のため）、および／または、要求ハンドラ２１０により（配布のため）アクセス可能であり得るローカル鍵データベース２７０に記憶され得る。

[0082] 要求１７５は、暗号化鍵を生成することに関連する更なる命令とともに送られ得る。更なる命令は、限定はされないが、暗号化鍵のソース、暗号化鍵それら自身、暗号化鍵に関連付けられた鍵属性１６０、等を含む。

[0083] 様々な実施形態において、要求１７５を受け取ることに応答して、管理要求ハンドラ２０５は、暗号化鍵を生成し得る、または、生成することを容易にし得る。例えば、暗号化鍵が何処で生成されるべきか（例えば、鍵ソース１７０）について要求１７５が言及していない場合、管理要求ハンドラ２０５自身が暗号化鍵を生成し得る。管理要求ハンドラ２０５は、ポリシーデータベース２８０に記憶された一組のポリシー１１５に基づいて、暗号化鍵を生成し得る。言い換えれば、管理要求ハンドラ２０５は、ポリシーデータベース２８０に定められた任意のポリシー１１５に違反していないであろう鍵属性１６０をもった暗号化鍵を生成し得る。

[0084] 暗号化鍵が何処で生成されるべきか（例えば、鍵ソース１７０）について要求１７５が言及していない場合、または、暗号化鍵を生成するために特定の鍵ソース１７０を特定している場合、管理要求ハンドラ２０５は、好適な鍵ソース１７０から暗号化鍵を受ける、または、さもなければ要求し得る。管理要求ハンドラ２０５は、管理ユーザインターフェース２２０、鍵連携インターフェース２６０、通信デバイス（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．、デバイスＮ ２５０ｎ、ソースデバイス１５０ａ、および、ターゲットデバイス１５０ｂ）、鍵管理インターフェース２４０、等から、暗号化鍵を要求し得る。

[0085] 管理要求ハンドラ２０５は、暗号化鍵を記憶する指定されたデータベース（例えば、ローカル鍵データベース２７０）から暗号化鍵を受け得る。ローカル鍵データベース２７０は、他の鍵ソース１７０（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．、デバイスＮ ２５０ｎ、ソースデバイス１５０ａ、および、ターゲットデバイス１５０ｂ、鍵生成および管理デバイス２３０、鍵連携インターフェース２６０、等）に接続され得、他の鍵ソース１７０のためにキャッシュされた暗号化鍵を記憶する。管理要求ハンドラ２０５は、鍵ソース１７０から暗号化鍵を要求する代わりに、ローカル鍵データベースから暗号化鍵を引き出し得る。これは、暗号鍵を引き出すこと／生成することのための処理時間が改善され得、ローカル鍵データベースが管理要求ハンドラ２０５にローカルであれば（例えば、同じネットワークノードに属する）、暗号化鍵を得るために、管理要求ハンドラ２０５の能力を妨げないであろう。管理要求ハンドラ２０５がローカル鍵データベース２７０から暗号化鍵を引き出しているので、暗号化鍵が引き出されるかどうか、鍵ソース１７０によって変更されているかどうかを保証するために、検証要求が鍵ソース１７０に送られ得る。確認、または、更新された暗号化鍵は、応答して、ローカル鍵データベース２７０に送られ得、従って、管理要求ハンドラ２０５が暗号化鍵を受け取り得る。

[0086] いくつかの実施形態において、管理要求ハンドラ２０５は、記載された任意の方法で（要求されたか、されないにかかわらず）暗号化鍵を受けると、ローカル鍵データベース２７０において、鍵ソース識別子と関連する鍵属性１６０と共に、暗号化鍵をキャッシュし得る。暗号化鍵、鍵ソース識別子、および鍵属性１６０は、通信が失われた場合、または、暗号化鍵の暗号化鍵ソースが信ずべきではない場合、記憶され得る。他方では、いくつかの実施形態において、暗号化鍵は鍵属性１６０と共には送られない。そのような実施形態では、管理要求ハンドラ２０５は、限定はされないが、ローカルユーザレポジトリ２８５、デバイスインベントリデータベース２９５、等のような様々なソースから鍵属性１６０を決定し得る。

[0087] そして、管理要求ハンドラ２０５は、ポリシーデータベース２８０に記憶された一組のポリシー１１５に基づいて、受け取られた暗号化鍵に関連付けられた鍵属性１６０を検査し得る。管理要求ハンドラ２０５は、ポリシーデータベース２８０から、全てのポリシー１１５、または、関連のあるポリシー（例えば、いくつか、または、全ての鍵属性１６０に基づいて）を引き出す。いくつかの実施形態において、管理要求ハンドラ２０５自身によって、または、管理要求ハンドラ２０５の指示で生成された暗号化鍵は、それらがポリシー１１５に基づいて生成された場合、ポリシー１１５による検査から免じられ得る。他の実施形態において、管理要求ハンドラ２０５によって、または、管理要求ハンドラ２０５において生成された全ての暗号化鍵は、ポリシー１１５によって検査され得る。記載された方法で、ポリシー１１５に基づいて許可可能な暗号化鍵は許可され得、一方、許可され得ない暗号化鍵は不認可され得る。管理要求ハンドラ２０５は、ポリシーデータベース２８０に記憶されたポリシーを更新または追加するように構成され得る（例えば、管理ユーザインターフェース２２０によって指示される）。

[0088] ローカルユーザレポジトリ２８５は、エンタープライズの中の通信デバイス（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．、デバイスＮ ２５０ｎ、等）のローカルユーザに関連した情報を記憶するデータベースであり得る。様々な実施形態において、ローカルユーザレポジトリ２８５は、鍵属性１６０を構成するユーザの特徴／情報を記憶し得る。特徴は、限定はされないが、特権（privileges）、セキュリティグループ、割り当てられた役割、それらの組み合わせ、等を含む。セキュリティグループは、階層ツリーで記憶され得る。管理要求ハンドラ２０５は、そのような特徴について、ローカルユーザレポジトリ２８５をアクセスし得、そのような特徴に対応してそのデバイスによって要求され、送られ、または、受け取られた暗号化鍵に関連付けられた鍵属性１６０として、それらを利用する。管理要求ハンドラ２０５は、ローカルユーザレポジトリ２８５に記憶された情報を追加し、または、変更し得る。ローカルユーザレポジトリ２８５に記憶された情報のコピーは、ローカル鍵データベース２７０に記憶されるべき鍵属性１６０として、ローカル鍵データベース２７０に送られ得る。

[0089] いくつかの実施形態において、処理データベース２７５は、様々な通信処理、または、潜在的な通信処理を記憶し得る。いくつかの実施形態において、処理データベース２７５は、１つまたはそれより多くのデバイスへの暗号化鍵送信インスタンス（encryption key transmission instances）（即ち、暗号化鍵が配布されるべきインスタンス）を記憶し得る。例えば、特定の暗号化鍵が、何らかの理由で転送されることができない／転送される（例えば、通信デバイスにプッシュされる）べきではない場合、転送処理（例えば、ジョブ）は、後刻に暗号化鍵を転送するために、処理データベース２７５の中にキューされる、または、さもなければ記憶され得る。処理データベース２７５は、また、後で要求ハンドラ２１０によって読まれる各特定の暗号化鍵送信インスタンスのステータスを記憶し得る。例えば、要求ハンドラ２１０は、後刻、全ての「未送（unsent）」の暗号化送信インスタンスのための対応する通信デバイスに全てまたはいくつかの暗号化鍵を送るよう試み得る。処理データベース２７５は、暗号化鍵がそのために生成される各通信デバイスに転送されるべき鍵のアクセスを得るために、ローカル鍵データベース２７０に接続され得る。

[0090] 更なる実施形態において、処理データベース２７５は、要求ハンドラ２１０に接続され得、通信処理（そのために、暗号化鍵は要求され、送られ、または、受け取られ得る）、および／または、関連する鍵属性１６０を記憶し得る。例えば、要求ハンドラ２１０は、処理データベース２７５にそのような情報を送り得る。処理データベース２７５は、ローカル鍵データベース２７０に接続され得る。通信処理（関連付けられた細部として）は、ローカル鍵データベース２７０に記憶された暗号化鍵に関連付けられ得る。管理要求ハンドラ２０５は、暗号化鍵と関連する鍵属性２６０について、ローカル鍵データベース２７０のみをアクセスする必要があり得る。

[0091] 構成データベース２９０は、鍵暗号化・鍵オーケストレーションシステム２００のためのサポート命令を記憶し得る。いくつかの実施形態において、構成データベース２９０は、内部ネットワーク（internal network）、クライアントの構成（configuration of clients）、アプリケーションの構成（configuration of applications）、ＩＰアドレス割り当て（IP address allocations）、様々なコンポーネント構成（various component configurations）、デバイス特権（device privileges）、デバイス通信経路（device communication pathways）、資格証明書（credentials）、等を記憶する。構成データベース２９０は、動作のために構成データベース２９０の中に記憶された命令を要求し得る管理要求ハンドラ２０５に接続され得る。管理要求ハンドラ２０５は、また、構成データベース２９０に記憶された情報を追加し、または、変更し得る。

[0092] いくつかの実施形態において、デバイスインベントリデータベース２９５は、所与のエンタープライズに関連付けられた通信デバイスに関連する情報を記憶し得る。例えば、記憶された情報は、限定はされないが、セキュリティグループ、セキュリティレベル、地理位置、識別番号、内部分類、デバイス仕様、暗号化が生成されたタイムスタンプ、これらの組み合わせ、等を含み得る。要求ハンドラ２１０は、その中にそのようなデータを記憶するために、デバイスインベントリデータベース２９５に接続され得る。管理要求ハンドラ２０５は、そのようなデバイス情報にアクセスするために、デバイスインベントリデータベース２９５に接続され得る。デバイスインベントリデータベース２９５は、特定のキャッシュされた鍵を、鍵属性１６０として対応するデバイス情報に関連付けるためにある。デバイスインベントリデータベース２９５に記憶された情報のコピーは、鍵属性１６０としてローカル鍵データベース２７０に送られ得る。

[0093] 鍵連携インターフェース２６０は、１つの鍵オーケストレーションデバイス１１０が、確立された信用関係に基づいて、暗号化鍵情報を１つまたはそれより多くの他の鍵オーケストレーションデバイス１１０と連携することを可能にし得る。各エンタープライズは、鍵オーケストレーションデバイス１１０を含み得る。それとして、鍵連携インターフェース２６０は、少なくとも１つの他のエンタープライズの通信システムとの信用関係を維持し得る。それは、言い換えれば、信用を拡張するためのゲートウェイである。

[0094] 図３は、様々な実施形態において実装されるような暗号化鍵連携システム３００の例を示す。鍵連携システム３００は、図１−２について記載されたような鍵オーケストレーションデバイス１１０を実装し得る。鍵連携システム３００は、エキストラエンタープライズ（extra-enterprise）通信関係および鍵オーケストレーションデバイス１１０によって可能とされた鍵連携（例えば、管理要求ハンドラ２０５と関連するコンポーネント）に基づき得る。

[0095] １つのエンタープライズ（例えば、エンタープライズＡ ３９０ａ）の中のコンポーネントによって生成された暗号化鍵（例えば、非対称暗号化鍵、対称暗号化鍵、等）は、他のエンタープライズ（例えば、エンタープライズＢ ３９０ｂ）の異なる鍵オーケストレーションデバイス（例えば、鍵オーケストレーションデバイス１１０、管理要求ハンドラ２０５、その関連するコンポーネント、等）に、それぞれの（または、両方の）エンタープライズのポリシー１１５による検査に準じて配布され得る。これは、連携された信用モデルに基づいた外部のエンティティ（例えば、エンタープライズ）との安全な通信またはデータ交換を可能にする。これは、また、通信のための対称鍵暗号化を可能にするために、外部の通信をサポートすることにおける並列通信管理への暗号化管理を可能にすることができる。従って、非対称暗号化の利用が、対称暗号化と比較した処理の観点から効果であり得ることを考え合わせれば、通信プラットホームの性能が改善され得る。

[0096] 鍵連携システム３００において、各エンタープライズ（例えば、エンタープライズＡ ３９０ａ、または、エンタープライズＢ ３９０ｂ）は、鍵オーケストレーションデバイスＡ ３１０ａと鍵オーケストレーションデバイスＢ ３１０ｂのそれぞれ１つに関連付けられ得る。鍵オーケストレーションデバイスＡ ３１０ａと鍵オーケストレーションデバイスＢ ３１０ｂの各々が、鍵オーケストレーションデバイス１１０であってよい。鍵オーケストレーションデバイスＡ ３１０ａと鍵オーケストレーションデバイスＢ ３１０ｂは、好適なネットワークを介してお互いに通信している。特に、鍵オーケストレーションデバイスＡ ３１０ａと鍵オーケストレーションデバイスＢ ３１０ｂの各々の鍵連携インターフェース（例えば、鍵連携インターフェース２６０）は、お互いに通信している。

[0097] 様々な実施形態において、鍵管理サーバＡ ３３０ａと鍵管理サーバＢ ３３０ｂは、限定はされないが、鍵生成および管理デバイス２３０と鍵管理インターフェース２４０等のデバイスであり得る。鍵管理サーバＡ ３３０ａと鍵管理サーバＢ ３３０ｂの各々は、記載された方法で、それらのそれぞれのエンタープライズの中のそれらのそれぞれの鍵連携インターフェース２０６に接続され得る。

[0098] デバイスＡ ３５０ａとデバイスＢ ３５０ｂは、それらの間の通信のための暗号化鍵を得ようと試み得る。デバイスＡ ３５０ａとデバイスＢ ３５０ｂの各々は、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．．デバイスＮ ２５０ｎ、それらの組み合わせ、等であってよい。

[0099] 暗号化鍵は、記載された方法で、任意の好適な鍵ソース１７０から、１つのエンタープライズ(例えば、エンタープライズＡ ３９０ａ）の中で生成され得る。暗号化鍵は、エンタープライズＡ ３９０ａによって（例えば、エンタープライズＡ ３９０ａにおける鍵ソース１７０によって）、エンタープライズＢ ３９０ｂから、または、エンタープライズＡの中での要求１７０でもって、または、要求１７０無くして、生成され得る。同様に、暗号化鍵は、同様な方法で、エンタープライズＢ ３９０ｂによって生成されてもよい。暗号化鍵とその関連する鍵属性１６０は、記載された方法での検査のために、エンタープライズＡ ３９０ａのポリシーエンジン（例えば、管理要求ハンドラ２０５とその関連するコンポーネントを含み得る鍵オーケストレーションデバイスＡ ３１０ａ）に提供され得る。エンタープライズＡ ３９０ａのポリシーエンジンが、暗号化鍵が暗号化鍵属性１６０に基づいて容認されると決定することに応答して、エンタープライズＡ ３９０ａの鍵オーケストレーションデバイス３１０ａ（例えば、鍵連携インターフェース２６０）は、暗号化鍵、並びに、その関連する鍵属性１６０を、エンタープライズＢ ３９０ｂの鍵オーケストレーションデバイスＢ ３１０ｂ（例えば、鍵連携インターフェース２６９）に関連付け得る。

[0100] 暗号化鍵とその関連する鍵属性１６０を受け取ると、暗号化鍵とその関連する鍵属性１６０は、記載された方法での検査のために、エンタープライズＢ ３９０ｂのポリシーエンジン（例えば、管理要求ハンドラ２０５とその関連するコンポーネントをまた含み得る鍵オーケストレーションデバイスＢ ３１０ｂ）に提供され得る。鍵オーケストレーションデバイスＢ ３１０ｂが、暗号化鍵はエンタープライズＢ ３９０ｂにとって不認可とされたポリシー１１５と一致すると決定する場合、暗号化鍵は、デバイスＡ ３５０ａとデバイスＢ ３５０ｂの両方に転送され得る。言い換えると、暗号化鍵（鍵属性１６０によって定義されたとして）は、エンタープライズＡ ３９０ａ、並びに、エンタープライズＢ ３９０ｂの両方の組のポリシー１１５と一致した場合のみ許可され得る。エンタープライズＡ ３９０ａの一組のポリシー１１５の少なくともいくつかは、エンタープライズＢ ３９０ｂの一組のポリシー１１５の少なくともいくつかと異なってもよい。暗号化鍵が鍵オーケストレーションデバイスＡ ３１０ａまたは鍵オーケストレーションデバイスＢ ３１０ｂのいずれかによって許可可能でないと認定されたとすると、暗号化鍵は、記載された方法で、「不認可（denied）」メッセージ、および／または、ヒントと共に、鍵ソース１７０に戻される。

[0101] 他の実施形態において、１つのエンタープライズ（例えば、エンタープライズＡ ３９０ａまたはエンタープライズＢ ３９０ｂのいずれか）のみに関連付けられたポリシー１１５による容認は、暗号化鍵が許可されるのに十分であり得る。そのような場合には、信用は、ポリシー１１５のいくつか、時には全てに拡張される。加えて、各エンタープライズは、連携されたインスタンスのために一組のポリシーを含み得る（例えば、各エンタープライズは、エンタープライズの通信デバイス間の通信が起ころうとするときに用いられる一組のポリシー１１５について他方に同意している）。従って、各エンタープライズは、連携されたスキームのために、同じ組の連携された（共通で相互的な）ポリシーを記憶する（例えば、各々それぞれのポリシーデータベース２８０に）。連携されたポリシーは、エンタープライズＡ ３９０ａとエンタープライズＢ ３９０ｂの両方のために同じであってよい。従って、１つのエンタープライズに関連付けられた１つの鍵オーケストレーションデバイスによる許可は、暗号化鍵が両方のエンタープライズの間の通信のための利用のために転送されるのに十分であり得る。

[0102] 様々な実施形態において、エンタープライズ連携ポリシーは、各ポリシーデータベース２８０の中に記憶され得る。エンタープライズ連携ポリシーは、暗号化鍵が連携され得る方法を特定し得る。例えば、エンタープライズ連携ポリシーは、連携されたポリシー、どの鍵オーケストレーションデバイスが鍵属性１６０を検査し得るか、どのエンタープライズが暗号化鍵のための要求１７５を発行し得るか、どのエンタープライズが暗号化鍵を生成し得るか、それらの組み合わせ、等を特定し得る。エンタープライズ連携ポリシーは、ポリシー定義における自由度を可能にする。例えば、エンタープライズ連携ポリシーは、エンタープライズの各々が、連携されたポリシーに加えてそれ自身のポリシー１１５を含み得ることを特定し得、そこでは、各エンタープライズのポリシー１１５の少なくとも一部が異なり得る。

[0103] いくつかの実施形態において、各それぞれのエンタープライズの通信プラットホームＡ ３２０ａと通信プラットホームＢ ３２０ｂは、任意の好適なネットワークを介して、お互いに通信している。通信プラットホーム間のそのような通信は、暗号化された通信であり得、そこでは、また、そのような通信に対応する暗号化鍵が、デバイス（例えば、デバイスＡ ３５０ａ、デバイスＢ ３５０ｂ、等）について記載されたのと同様に、ポリシー１１５による検査のために提示され得る。各通信プラットホームは、鍵オーケストレーションシステムに関連した構成（configurations）が交換され得るように、それぞれのデバイスと通信している。

[0104] 図４は、いくつかの実施形態に従った、エンタープライズの一部としての鍵オーケストレーションサービスを消費する通信デバイス４００の例を示す。図１−４を参照して、通信デバイス４００は、限定はされないが、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．、デバイスＮ ２５０Ｎ、デバイスＡ ３５０ａ、デバイスＢ ３５０ｂ、それらの組み合わせ、等のデバイスであってよい。いくつかの実施形態において、通信デバイス４００は、限定はされないが、通信デバイス上のＥｍａｉｌアプリケーション４１０ａ、ボイスオーバーインターネットプロトコル（voice-over-internet protocol：ＶＯＩＰ）アプリケーション４１０ｂ、ストレージ暗号化（storage encryption）４１０ｃ、および／または、他の暗号化アプリケーション４１０ｄ、等のアプリケーションに関連付けられた暗号化鍵（または、鍵更新）を受けるために、鍵オーケストレーションを活用する。

[0105] 通信デバイス４００は、鍵オーケストレーションサービスを受けるために、鍵オーケストレーションプラットホームにレジスタされる（registered）。通信デバイス４００は、鍵オーケストレーションデバイス１１０から暗号化鍵配布および暗号化鍵管理メッセージ（例えば、「許可（allowed）」メッセージ、「不認可（denied）」メッセージ、ヒント、等）をもちいて受けるよう構成されたアプリケーションインターフェース４２０を与え得る。アプリケーションインターフェース４２０は、Ｅｍａｉｌアプリケーション４１０ａ、ボイスオーバーインターネットプロトコル（voice-over-internet protocol：ＶＯＩＰ）アプリケーション４１０ｂ、ストレージ暗号化（storage encryption）、および／または、他の暗号化アプリケーション４１０ｄの各々に接続され得、容認された暗号化鍵をそれらに転送する。

[0106] この通信デバイス４００は、また、鍵オーケストレーションデバイス１１０からＫＭＩＰ形式のコマンドを受けるために、ＫＭＩＰプロキシ（KMIP proxy）によってＫＭＩＰを利用し得る。ＫＭＩＰプロキシ４３０は、それらの中に記憶された暗号化鍵を管理するための鍵ストア４４０に接続され得る。ＫＭＩＰプロキシ４３０は、また、デバイスエンド暗号ユニット（device-end cryptographic unit）４５０に接続され得る。デバイスエンド暗号ユニット４５０は、暗号化鍵を生成するよう構成され得る。「不認可（denied）」メッセージに応答して、デバイスエンド暗号ユニット４５０は、検査のためにポリシーエンジンに提示するべき異なる暗号化鍵を生成し得る。ヒントが与えられるがゆえに、デバイスエンド暗号ユニット４５０は、ヒントに基づいて異なる暗号化鍵を生成し得る。デバイスエンド暗号ユニット４５０は、鍵ストア４４０にその暗号化鍵をキャッシュする。デバイスエンド暗号ユニット４５０は、アプリケーションインターフェース４２０に接続され得る。アプリケーションインターフェース４２０は、生成された暗号化鍵を、鍵属性１６０と共にポリシーエンジンに送り、例えば、応答が否定的な場合、デバイスエンド暗号ユニット４５０にポリシーエンジンの応答を転送し得る。

[0107] 従って、動作レベル（operation-level）のポリシー検査が達成され得る。通信デバイス４００が暗号化鍵についてポリシーエンジンと相互作用でき得るとすると、管理することとして動作する第三者デバイス（例えば、鍵オーケストレーションデバイス１１０に属するポリシーエンジン）による暗号化鍵の要求にサービスする（または、暗号化鍵を検査する）ための能力が達成され得る。暗号化鍵の要求１７５、または、暗号化鍵は、各通信処理にサービスされ得る。

[0108] 図５は、いくつかの実施形態に従った、様々な暗号化鍵オーケストレーションシステムにおいて暗号化鍵の要求１７５を発行する要求認証プロセス５００の例を示す。要求認証プロセス５００は、鍵オーケストレーションデバイス１１０（例えば、管理要求ハンドラ２０５、鍵オーケストレーションデバイスＡ ３１０ａ、鍵オーケストレーションデバイスＢ ３１０ｂ、等）自身が暗号化鍵を生成する場合に、鍵オーケストレーションデバイスの内部にあり得る。他の実施形態では、要求認証プロセス５００は、既存の鍵管理および鍵生成インフラストラクチャ（例えば、鍵生成および管理デバイス２３０、鍵管理サーバＡ ３３０ａ、鍵管理サーバＢ ３３０ｂ、等）との統合をサポートするために、鍵オーケストレーションデバイスの外部にあり得る。

[0109] 第１に、ブロックＢ５１０において、鍵オーケストレーションデバイス１１０は、認証情報を鍵ソース１７０に提供する。記載されるように、そのような鍵ソース１７０は、鍵オーケストレーションデバイス１１０自身、鍵生成および管理デバイス２３０、管理ユーザインターフェース２２０、鍵連携インターフェース２６０、通信デバイス（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．、デバイスＮ ２５０ｎ、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、デバイスＡ ３５０ａ、デバイスＢ ３５０ｂ、通信デバイス４００、それらの組み合わせ、等）、および／または、他の外部の鍵ソースであってよい。認証情報は、ユーザ名／パスコード要求、セキュリティハンドシェイクアルゴリズム（security handshake algorithms）、バイオメトリック要求（biometric request）、それらの組み合わせ、等の任意の好適な認証方法であってよい。

[0110] 次に、ブロックＢ５２０において、鍵オーケストレーションデバイス１１０が、鍵ソース１７０から認証応答を受け取り得る。鍵オーケストレーションデバイス１１０は、応答を認証し、鍵ソース１７０と鍵オーケストレーションデバイス１１０との間の信用関係を確立し得る。次に、ブロックＢ５３０において、鍵オーケストレーションデバイス１１０、管理ユーザインターフェース２２０、鍵生成および管理デバイス２３０、通信デバイス、および、他のＡＰＩ呼び出し（API calls）は、鍵管理／生成要求（例えば、要求１７５）を鍵ソース１７０に発行し得る。いくつかの実施形態において、鍵オーケストレーションデバイス１１０は、要求１７５を、信用された第三者（例えば、通信デバイス、管理ユーザインターフェース２２０、鍵連携インターフェース２６０、および／または、他の第三者デバイス）から鍵ソース１７０に転送する。いくつかの実施形態において、要求１７５は、鍵ソース１７０に直接送られ得る。鍵オーケストレーションデバイス１１０は、要求１７５が鍵ソースを特定していない場合、自身で暗号化鍵を生成するか、他の鍵ソース１７０に要求を転送するかどうかを決定するよう構成され得る。次に、ブロックＢ５４０において、鍵オーケストレーションデバイス１１０は、鍵ソース１７０から応答（例えば、要求されたような暗号化鍵）を受け得る。

[0111] 続いて、鍵オーケストレーションデバイス１１０によって得られた暗号化鍵は、記載された方法で、鍵属性１６０とポリシー１１５とに基づいて評価され得る。許可された場合、暗号化鍵は、対応する通信処理に関連付けられた通信デバイスに配布され得る。不認可された場合、鍵オーケストレーションデバイス１１０は、「不認可（denied）」メッセージ（および、ある場合には、ヒント）を送信し、新たな暗号化鍵のために待機し得る。

[0112] いくつかの実施形態において、複数の要求が複数の鍵ソースに送られ得、各要求は、単一の通信処理に対応し得る。それに応答して、複数の応答（例えば、暗号化鍵）が鍵ソース１７０から受け取られ得る。他の実施形態では、複数の要求が複数の鍵ソース１７０に送られ得、そこでは、２つまたはそれより多くの要求が同じ通信処理に対応し得る。鍵オーケストレーションデバイス１１０は、鍵ソース１７０から２つまたはそれより多くの暗号化鍵を受け取り得る。鍵オーケストレーションデバイス１１０は、ポリシー１１５に基づいて、通信処理のために、２つまたはそれより多くの暗号化鍵の１つ（例えば、２つまたはそれより多くの暗号化鍵から最も安全なもの）を決定し得る。

[0113] 従って、鍵オーケストレーションデバイス１１０による大規模な配布が、暗号化鍵のための少なくとも１つのソースと複数の受け取り手の通信デバイスを含むシステムにおいて可能となる。

[0114] 図６は、様々な実施形態に従った、様々な鍵オーケストレーションシステムに実装される通信デバイス登録プロセス６００の例を示すプロセスフロー図である。ブロックＢ６１０、Ｂ６２０、Ｂ６３０は、同時か、または、その順番で続けて実行され得る。最初に、ブロック６１０において、通信デバイスが発見され得る（例えば、要求ハンドラ２１０によって）。要求ハンドラ２１０は、通信デバイスがエンタープライズ（例えば、エンタープライズに関連付けられたネットワーク）の中に存在することを自動的に検出し得る。

[0115] ブロックＢ６２０において、通信デバイスがレジスタ（register）され得る（例えば、要求ハンドラ２１０によって）。いくつかの実施形態において、鍵オーケストレーションシステムに関連した構成情報が、通信デバイスに送信され得る。通信デバイスのデバイス情報は、ローカルユーザレポジトリ２８５、デバイスインベントリデータベース２９５、等に送られ得る。ブロックＢ６３０において、通信デバイスがエンロール（enroll）される（例えば、要求ハンドラ２１０によって）。例えば、通信デバイスは、サーバ認証要求を要求ハンドラ２１０に送り、ポジティブな承認応答を受け得る。

[0116] 次に、ブロックＢ６４０において、通信デバイスが容認され得る（例えば、要求ハンドラ２１０によって）。例えば、要求ハンドラ２１０、および／または、管理要求ハンドラ２０５は、通信デバイスが適当なグループ分類されているかどうか、鍵オーケストレーションデバイス１１０が通信デバイスをオーケストレートすることができるかどうか、それらの組み合わせ、等を決定するために、デバイス情報に基づいて既存のポリシー１１５をチェックし得る。

[0117] 次に、ブロックＢ６５０において、要求ハンドラ２１０は、デバイス認証情報を通信デバイスに提供し得る。認証情報は、鍵オーケストレーションデバイス１１０をアクセスするために、構成（configurations）（例えば、資格証明書（credentials）、パスコード（passcodes）、等）を含み得る。次に、ブロック６６０において、要求ハンドラ２１０、および／または、管理要求ハンドラ２０５は、通信デバイスのためのオーケストレーションルールを定義し得る。ブロックＢ６６０に続いてブロックＢ６７０において、通信デバイスの対応する識別子が、オーケストレーションレジストレーションに加えられている。続いて、通信デバイスは、記載された方法で、暗号化鍵を要求し、暗号化鍵を生成し、承認された暗号化鍵を受け取る、等をし得る。そのようなプロセスは、鍵オーケストレーションデバイス１１０によって提供されるサービスを利用する通信デバイスが鍵オーケストレーションデバイス１１０の動作標準に合致することを保証する。

[0118] 図７は、様々な実施形態に従った、鍵管理および配布プロセス７００の例を示す。
図１−７を参照して、鍵管理および配布プロセス７００は、鍵オーケストレーションデバイス１１０でもってレジスタされ、発見され、および／または、エンロールされた通信デバイスに対して実装され得る。

[0119] まず、ブロックＢ７１０において、管理要求ハンドラ２０５は、鍵管理コマンド（key management command）を定義する。鍵管理コマンドは、鍵管理イベント（例えば、「ジョブ（job）」）のために特化されたコマンドであってよい。鍵管理イベントは、ポリシー１１５に基づいて暗号化鍵を生成し、通信デバイスの少なくとも１つ（例えば、セルラデバイス２５０ａ、ネットワークデバイス２５０ｂ、．．．、デバイスＮ ２５０ｎ、ソースデバイス１５０ａ、ターゲットデバイス１５０ｂ、デバイスＡ ３５０ａ、デバイスＢ ３５０ｂ、通信デバイス４００、それらの組み合わせ、等）に暗号化鍵を配布（例えば、プッシュ）するために、一組のアルゴリズムを動作開始させるイベントであり得る。

[0120] いくつかの実施形態において、鍵管理イベントは時間に基づき得る。例えば、管理要求ハンドラ２０５は、エンタープライズ（または、他のエンタープライズ）に関連付けられた通信デバイスの少なくともいくつか（時には全て）のために、定期的（例えば、毎日、毎週、毎月、等）に暗号鍵を変更する（rekey）ように構成され得る。様々な実施形態において、鍵管理イベントは、ＡＰＩ呼び出しを介して自動的に生じ得る。ＡＰＩ呼び出しは、同じまたは異なるエンタープライズの中の鍵オーケストレーションデバイス１１０の内部の、および／または、外部の任意のコンポーネントから発行され得る。

[0121] 鍵管理イベントは、また、ユーザ定義されてもよい。例えば、管理ユーザインターフェース２２０は、少なくとも１つの通信デバイスのために直ちに暗号化鍵を生成するために、指定されたユーザからユーザ入力を受け取り得る。該例では、そのようなユーザ定義鍵管理イベントは、サイバーアタック（cyber-attacks）、セキュリティ違反、ポリシー１１５への変更、等を含む突然のイベントに応答して開始され得る。管理ユーザインターフェース２２０は、また、これらの鍵管理イベントに応答して、ポリシーデータベース２８０の中に記憶されたポリシー１１５を変更し得る。生成された、新たな暗号化鍵は、変更されたポリシー１１５の組に従わなければならない。

[0122] 鍵管理コマンドは、同じまたは異なるエンタープライズの中のいくつか、または、全ての通信デバイスに暗号化鍵を提供すること、同じまたは異なるエンタープライズの中のいくつか、または、全ての通信デバイスに、同じまたは異なる暗号化鍵を再送すること、それらの組み合わせ、等を含み得る。様々な実施形態において、管理要求ハンドラ２０５は、複数の鍵管理コマンドについて定義し得、それらの各々は、エンタープライズに関連付けられた通信処理、および／または、通信デバイスに対応し得る。更なる実施形態において、管理要求ハンドラ２０５は、連携モデルによって許される場合、異なるエンタープライズに関連付けられた通信デバイスのための鍵管理コマンドを定義し得る。管理コマンド（例えば、暗号化鍵）は、各エンタープライズに関連付けられた鍵連携インターフェース２６０を介して送られ得る。

[0123] 次に、ブロックＢ７２０において、管理要求ハンドラ２０５は、鍵管理コマンドキュー（key management command queue）を構築し得る。鍵管理イベントに応答して生成されたジョブは複数の鍵管理コマンドを含み得、それらの各々は、通信デバイス、および／または、通信処理に対応し得る。従って、鍵管理コマンドが、新しい暗号化鍵を生成しており、２つまたはそれより多くの通信デバイスに配布している場合、鍵管理コマンドの量があるとして、鍵管理コマンドは、実行のために待ち行列に入れられる（queue）（例えば、処理データベース２７５の中に記憶される）。故に、複合コマンド（composite command）は、複数の暗号化鍵を受け取る通信デバイスに暗号化鍵を発行するために、複数の鍵ソースのための複数の鍵管理コマンドに対応し得る。複合コマンドは、複数の鍵管理コマンドに関連付けられ得、配布を待って、処理データベース２７５の中に全体として記憶され得る。従って、サーバ（例えば、管理要求ハンドラ２０５）が、鍵管理コマンドの全てが実行され／配布される前に切断される場合でさえ、プロセスは、サーバが起動されるとすぐに復帰され得る。

[0124] 動作していない通信デバイス（例えば、切断されている、および／または、ネットワークから切り離されている通信デバイス）に関連付けられた鍵管理コマンドは、ブロックＢ７３０において、管理要求ハンドラ２０５によって、将来の配布（例えば、動作していない通信デバイスのスイッチが入れられたとき）のために処理データベース２７５に記憶され得る。他方、動作しているデバイス（例えば、起動されている、および／または、ネットワーク上にある通信デバイス）のために、鍵管理コマンドが、ブロックＢ７４０において、管理要求ハンドラ２０５によって実行され得る。

[0125] 例えば、管理要求ハンドラ２０５は、ブロックＢ７５０において、鍵管理コマンドに基づいて、鍵ソース１７０からの暗号化鍵を要求し得る。例えば、鍵管理コマンドは、通信デバイスに暗号化鍵を発行するために、１つまたはそれより多くの鍵ソース１７０を特定し得る。従って、いくつかの通信デバイスは、第１の鍵ソースから暗号化鍵を受け取り得、他方、他の通信デバイスは、第２の異なる鍵ソースから暗号化鍵を受け取り得る。次に、ブロックＢ７６０において、管理要求ハンドラ２０５は、通信デバイスに暗号化鍵を配布し得る。いくつかの実施形態において、管理要求ハンドラ２０５は、記載された方法で、鍵属性１６０と一組のポリシー１１５とに基づいて、暗号化鍵検査を実行する。承認されたならば、管理要求ハンドラ２０５は、要求ハンドラ２１０を介して、暗号化鍵を対応する通信デバイスに転送し得る。

[0126] 次に、ブロックＢ７７０において、管理要求ハンドラ２０５は、通信デバイスから、配布への応答を受け得る。例えば、管理要求ハンドラ２０５は、ブロックＢ７８０において、通信デバイスの応答に基づいて、該配布が成功したかどうかを決定し得る。管理要求ハンドラ２０５が、所与の通信デバイス（例えば、その通信デバイスは、それに配布された暗号化鍵を受け取っている）について配布が成功したと決定するのに対して、ブロックＢ７９５において、ポジティブフィードバックが管理要求ハンドラ２０５に与えられ得る。

[0127] 他方、管理要求ハンドラ２０５が、所与の通信デバイスについて配布が不成功であった（例えば、その通信デバイスが、それに配布された暗号化鍵を受け取れなかった）と決定するのに対して、ブロックＢ７９０において、その通信デバイスのネガティブ応答が管理要求ハンドラ２０５に与えられ得る。そして、管理要求ハンドラ２０５は、ブロックＢ７９８において、前から存在するアルゴリズム、または、ユーザ入力に基づいて、その通信デバイスのために、後の時間において再び鍵管理コマンドを実施しようと試みるかどうか決定し得る。

[0128] 鍵管理コマンドの実行（例えば、暗号の配布）が再び試みられるべきではないと、管理要求ハンドラ２０５が決定する場合（Ｎ７９８：いいえ）、プロセスは終了する。他方、成功裡に配布されなかった鍵管理コマンドが再び試みられるべきであると、管理要求ハンドラ２０５が決定する（Ｂ７９８：はい）ことに対して、鍵管理コマンドは、ブロックＢ７３０において、将来の配布のために記憶され得る（例えば、処理データベース２７５において）。

[0129] いくつかの実施形態において、鍵管理コマンドの配布が不成功であり得る場合、管理要求ハンドラ２０５は、不成功であった鍵管理コマンドの配布をリトライすると決定し得る（Ｂ７８０：リトライ）。例えば、管理要求ハンドラ２０５は、再び、ブロックＢ７４０において、動作しているデバイスのための鍵管理コマンドを実行し得る。

[0130] 図８は、様々な実施形態に従った、暗号化鍵連携プロセス８００の例を示すプロセスフロー図である。図１−８を参照して、鍵オーケストレーションデバイス１１０（例えば、同じローカルエンタープライズにおいて、および、他の（foreign）エンタープライズにおいて、の両方）は、１つのエンタープライズから他のエンタープライズに暗号化鍵を連携する（federating）ために、鍵オーケストレーションデバイス１１０または各エンタープライズに対して実装されたポリシー１１５に基づいて、暗号化鍵を相互に認証し、配布し得る。加えて、暗号化鍵連携プロセス８００は、また、他の鍵オーケストレーションデバイスの連携ポリシーの結果として、他の鍵オーケストレーションデバイスからの暗号化鍵の受け取りを含む。

[0131] まず、ブロックＢ８１０において、ローカル鍵オーケストレーションデバイス（例えば、鍵オーケストレーションデバイスＡ ３１０ａ）は、他の鍵オーケストレーションデバイス（例えば、鍵オーケストレーションデバイスＢ ３１０ｂ）に認証情報を与え得る。認証情報は、連携のための任意の好適な認証プロンプト、および／または、要求であってよい。次に、ブロックＢ８２０において、ローカル鍵オーケストレーションデバイスは、連携モデルを開始することに同意している他の鍵オーケストレーションから認証応答を受け得る。ブロックＢ８１０とＢ８２０は、典型的なセキュリティ証明書ハンドシェイク（security credential handshakes）を表し、そこでは、連携信用（federation trust）が２つのエンタープライズ間で確立されている。

[0132] 次に、ブロックＢ８３０において、ローカル鍵オーケストレーションデバイスは、他の鍵オーケストレーションデバイスに信用ポリシー情報（trust policy information）を与え得る。ブロックＢ８４０において、ローカル鍵オーケストレーションデバイスは、他の鍵オーケストレーションデバイスから信用ポリシー情報を受け取り得る。信用ポリシー情報は、構成（configurations）、設定（settings）、信用の範囲（extent of trust）、お互いに同意したポリシー、それらの組み合わせ、等を含んでよい。

[0133] ブロックＢ８５０において、ローカル鍵オーケストレーションデバイスと他の鍵オーケストレーションデバイスは、記載された方法で、鍵情報（例えば、暗号化鍵、関連する鍵属性１６０、それらの組み合わせ、等）を管理し、配布し得る。

[0134] 特定の実施形態において、他の鍵オーケストレーションデバイスに関連付けられた通信デバイスとローカル鍵オーケストレーションデバイスに関連付けられた通信デバイスとの間の通信処理のための暗号化鍵を生成するために、他の鍵オーケストレーションデバイスは、ローカル鍵オーケストレーションデバイスに要求１７５を送る。暗号化鍵は、ローカル鍵オーケストレーションデバイスによって生成され、ローカルポリシーエンジンによって検査される。暗号化鍵は、いくつかの実施形態において、他のポリシーエンジンによる検査のために他の鍵オーケストレーションデバイスに送られ得るが、他ではそうでない。

[0135] いくつかの実施形態において、要求１７５の代わりに、他の鍵オーケストレーションデバイスは、生成された暗号化鍵（特定された信用ポリシー情報に応じて、他の鍵オーケストレーションデバイスのポリシーエンジンによって検査されている、または、検査されていない）を送り得る。ローカル鍵オーケストレーションデバイスは、エンタープライズ間で特定された信用ポリシー情報に基づいて、ポリシー１１５によって暗号化鍵とその関連する鍵属性１６０を検査してもよく、または、検査しなくてもよい。

[0136] 図９は、様々な実施形態に従った、暗号化鍵管理および配布プロセス９００の例を示すプロセスフロー図である。様々な実施形態において、暗号化鍵管理および配布プロセス９００は、鍵管理（key management）、鍵配布（key distribution）、および、鍵連携（key federation）を含む、鍵オーケストレーションの要素を組み込み得る。

[0137] まず、ブロックＢ９１０において、一組のポリシー１１５が定義され得、そこでは、各ポリシー１１５が１つまたはそれより多くの鍵属性１６０に関連し得る。ポリシー１１５は、計画された人員によって定義され、将来の検索および更新のために、ポリシーデータベース２８０に記憶され得る。次に、ブロックＢ９２０において、管理要求ハンドラ２０５が、記載された方法で、暗号化鍵と、鍵ソース１７０からの暗号化鍵に関連付けられた少なくとも１つの鍵属性とを受け取り得る。

[0138] 次に、ブロックＢ９３０において、管理要求ハンドラ２０５は、少なくとも１つの鍵属性と、少なくとも１つの鍵属性の１つに関連するポリシー１１５の組とに少なくとも部分的に基づいて、受け取られた暗号化鍵の容認可能性を決定し得る。例えば、管理要求ハンドラ２０５が、鍵属性１６０に対応する値をチェックし得、値が、記載された方法で、ポリシー１１５によって定義されたような容認される範囲の中にあるかどうかを決定する。

[0139] 次に、ブロックＢ９４０において、管理要求ハンドラ２０５は、暗号化鍵が容認可能かどうか決定し得る。暗号化鍵が容認可能である（Ｂ９４０：はい）ことに対して、管理要求ハンドラ２０５は、ブロックＢ９５０において、それらの間で通信処理のための鍵を要求している通信デバイスに、暗号化鍵を配布し得る。他方、暗号化鍵が容認不可である（Ｂ９４０：いいえ）ことに対して、管理要求ハンドラ２０５は、ブロックＢ９６０において、鍵ソース１７０に、「不認可（denied）」メッセージを送り得る。オプションとして、管理要求ハンドラ２０５は、ブロックＢ９７０において、鍵生成を容易にするために、鍵ソースにヒントを送り得る。そして、管理要求ハンドラ２０５は、ブロックＢ９２０において、第２の暗号化鍵（および、関連する鍵属性１６０）を受け取るまで待機し得る。

[0140] この中に記載された鍵オーケストレーションシステム（例えば、鍵オーケストレーションデバイス１１０、管理要求ハンドラ２０５、鍵オーケストレーションデバイスＡ ３１０ａ、鍵オーケストレーションデバイスＢ ３１０ｂ、等）は、プロセッサとメモリデバイスとを有する任意の好適なコンピューティングデバイス上に実装され得る。プロセッサは、汎用プロセッサ（例えば、マイクロプロセッサ）等の任意の好適なデータプロセッシングデバイスを含み得るが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、または、ステートマシンであってもよい。プロセッサは、また、例えば、ＤＳＰとマイクロプロセッサとの組み合わせ、複数のマイクロプロセッサ、ＤＳＰコアと併せた少なくとも１つのマイクロプロセッサ、または、任意の他のそのような構成、等のコンピューティングデバイスの組み合わせとして実装され得る。メモリは、プロセッサに機能的に接続され得、この中に記載された動作と機能を実行するためにプロセッサを制御し、プロセッサによる使用のためのソフトウェアとデータを記憶するための好適なデバイスを含み得、限定はされないが、ランダムアクセスメモリ（random access memory：ＲＡＭ）、リードオンリーメモリ（read only memory：ＲＯＭ）、フロッピー（登録商標）ディスク、ハードディスク、メモリデバイスに接続されたドングルまたは他のＲＳＢ、等を含む。

[0141] 鍵オーケストレーションデバイス１１０、管理要求ハンドラ２０５、鍵オーケストレーションデバイスＡ ３１０ａ、および／または、鍵オーケストレーションデバイスＢ ３１０ｂは、限定はされないが、Ｌｉｎｕｘ（登録商標） ＯＳ、Ｗｉｎｄｏｗｓ（登録商標）、Ｍａｃ ＯＳ、等の好適なオペレーティングシステム上に実装され得る。加えて、鍵オーケストレーションデバイス１１０、管理要求ハンドラ２０５、鍵オーケストレーションデバイスＡ ３１０ａ、および／または、鍵オーケストレーションデバイスＢ ３１０ｂは、組込みシステム（embedded systems）等のスモールフォームファクタ（small form factors）上に実装され得る。

[0142] 図１−９に関して記載された実施形態は、暗号化鍵に関係する。他の実施形態において、管理、配布、および、連携を含む鍵オーケストレーションデバイス１１０に向けられたシステムと方法は、限定はされないが、ユーザ識別情報、証明書、生体識別データ、乱数発生器データ、既知数の（determinate）乱数発生器データ、非既知数（non-determinate）の乱数発生器データ、ユーザ認証情報、ポリシーコンポーネント、オーガニゼーションセキュリティコンポーネントに関連付けられた他のコンポーネント、等の他のデリケートなオブジェクトのために同様に実装され得ることが、当技術分野において通常の技量を有する者によって理解されるべきである。

[0143] 図１−９に関して上述された様々な実施形態は、様々なプロセスまたはタスクの実行を含む。様々な実施形態において、そのようなプロセスまたはタスクは、コンピュータ読出し可能な記憶媒体から読み出されたコンピュータコードの実行を通して実行され得る。例えば、様々な実施形態において、１つまたはそれより多くのコンピュータ読出し可能な記憶媒体が、プロセッサによって実行されたとき、プロセッサに、上記の実施形態においてプロセッサについて記載されたプロセスやタスクを実行させる１つまたはそれより多くのコンピュータプログラムを記憶する。また、様々な実施形態において、１つまたはそれより多くのコンピュータ読出し可能な記憶媒体は、デバイスによって実行されたとき、コンピュータに、上記実施形態において述べられたデバイスに関して記載されたようなプロセスまたはタスクを実行させる１つまたはそれより多くのコンピュータプログラムを記憶する。様々な実施形態において、１つまたはそれより多くのコンピュータ読出し可能な記憶媒体は、データベースによって実行されたとき、データベースに、上記実施形態においてデータベースに関して記載されたようなプロセスまたはタスクを実行させる１つまたはそれより多くのコンピュータプログラムを記憶する。

[0144] 従って、その上に記憶されたコンピュータまたは機械による実行が可能な命令またはデータ構造を担うまたは有するためのコンピュータ読出し可能な、または、機械読み出し可能な媒体を備えるプログラム製品を含む。そのようなコンピュータ読出し可能な記憶媒体は、例えば、汎用の、または、専用のコンピュータ、または、プロセッサを有した他の機械によってアクセスされることのできる、任意の利用可能な媒体であり得る。例として、そのようなコンピュータ読出し可能な記憶媒体は、半導体メモリ、フラッシュメモリ、ハードディスク、コンパクトディスク（compact disk：ＣＤ）またはデジタルバーサタイルディスク（digital versatile disk：ＤＶＤ）等の光ディスク、磁気記憶、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）、等を備え得る。それらのタイプのメモリの組み合わせは、また、コンピュータ読出し可能な記憶媒体の範囲の中に含まれる。コンピュータ実行可能なプログラムコードは、例えば、コンピュータまたはプロセッシングマシンに、ある機能、計算、アクション、等を行わせる命令およびデータを備え得る。

[0145] この中に開示された実施形態は、限定としてではなく、例示として、全ての観点で考慮されるべきである。本開示は、決して、上述の実施形態に限定されることはない。様々な修正や変更が、その開示の意図や範囲から逸脱しないで、実施形態に対してなされ得る。特許請求の範囲の意味や均等の範囲の中にはいる様々な修正や変更は、本開示の範囲の中に入ることを意図される。

Claims (20)

1. セキュリティオブジェクトをオーケストレートするためのプロセスであって、
   ポリシーエンジンに接続されたデータベースにおいて、複数のポリシーを定義し、記憶することと、
   前記ポリシーエンジンによって、前記セキュリティオブジェクトと前記セキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性を受け取ることと、
   前記少なくとも１つのオブジェクト属性と前記少なくとも１つのオブジェクト属性に対応する前記複数のポリシーの少なくとも１つとに少なくとも部分的に基づいて、前記ポリシーエンジンでもって、前記セキュリティオブジェクトの容認可能性を決定することと、
   前記セキュリティオブジェクトが容認可能であると決定された場合、前記ポリシーエンジンに関連付けられた少なくとも１つの通信デバイスに前記セキュリティオブジェクトを配布することと、ここにおいて、前記少なくとも１つの通信デバイスは、前記セキュリティオブジェクトに少なくとも部分的に基づいて通信を確立する、
   を備えるプロセス。
2. 前記セキュリティオブジェクトは暗号化鍵である、請求項１に記載のプロセス。
3. 前記少なくとも１つのオブジェクト属性は、前記セキュリティオブジェクト、前記セキュリティオブジェクトを生成する第１のデバイス、前記セキュリティオブジェクトを送る第２のデバイス、前記セキュリティオブジェクトを受け取る第３のデバイス、前記第１のデバイスに関連付けられた第１のユーザ、前記第２のデバイスに関連付けられた第２のユーザ、および、前記第３のデバイスに関連付けられた第３のユーザの内の少なくとも１つの特徴を備える、請求項１に記載のプロセス。
4. 前記少なくとも１つのオブジェクト属性は、セキュリティオブジェクトサイズ、前記セキュリティオブジェクトが生成された時間、前記セキュリティオブジェクトが生成された地理位置、前記セキュリティオブジェクトの分類、鍵ソースに関連付けられた役割、ソースデバイスに関連づけられた役割、および、ターゲットデバイスに関連付けられた役割の内の少なくとも１つを備える、請求項１に記載のプロセス。
5. 前記複数のポリシーは、前記セキュリティオブジェクトサイズが所定のサイズ範囲の中にある場合に前記セキュリティオブジェクトを容認することを備える、請求項４に記載のプロセス。
6. 前記複数のポリシーは、前記セキュリティオブジェクトが生成された前記時間が所定の時間間隔の中にある場合に前記セキュリティオブジェクトを容認することを備える、請求項４に記載のプロセス。
7. 前記複数のポリシーは、前記セキュリティオブジェクトが生成された前記地理位置が所定のエリアの中にある場合に前記セキュリティオブジェクトを容認することを備える、請求項４に記載のプロセス。
8. 前記複数のポリシーは、前記セキュリティオブジェクトの前記分類が所定のセキュリティオブジェクト分類グループと関連付けられている場合に前記セキュリティオブジェクトを容認することを備える、請求項４に記載のプロセス。
9. 前記複数のポリシーは、前記鍵ソース、前記ソースデバイス、または、前記ターゲットデバイスに関連付けられた前記役割が役割の所定のグループに関連付けられている場合に前記セキュリティオブジェクトを容認することを備える、請求項４に記載のプロセス。
10. 鍵ソースに不認可インジケータを送ることと、
    前記鍵ソースに前記セキュリティオブジェクトの不適当な点を知らせるヒントを送信することと、ここにおいて、前記セキュリティオブジェクトは、前記鍵ソースから受信される、
    を更に備える、請求項１に記載のプロセス。
11. 前記ポリシーエンジンによって、前記セキュリティオブジェクトを受け取ることは、
    前記ポリシーエンジンによって、前記セキュリティオブジェクトを生成するための要求を受け取ることと、
    前記ポリシーエンジンによって、セキュリティオブジェクトを生成することと、
    を備える、請求項１に記載のプロセス。
12. セキュリティオブジェクトをオーケストレートするためのプロセスであって、
    第１の鍵オーケストレーションデバイスの第１のデータベースにおいて第１の複数のポリシーを定義し、記憶することと、前記第１のデータベースは、第１のエンタープライズに関連付けられる、
    前記第１のエンタープライズに関連付けられた前記第１の鍵オーケストレーションデバイスでもって、第２のエンタープライズに関連付けられた第２の鍵オーケストレーションデバイスから、前記セキュリティオブジェクトと前記セキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性とを受け取ることと、
    前記第１の鍵オーケストレーションデバイスでもって、前記少なくとも１つのオブジェクト属性と前記少なくとも１つのオブジェクト属性に対応する前記第１の複数のポリシーの内の少なくとも１つとに少なくとも部分的に基づいて、前記セキュリティオブジェクトの容認性を決定することと、
    前記第１のエンタープライズに関連付けられた第１の通信デバイスに前記セキュリティオブジェクトを配布することと、
    を備えるプロセス。
13. 前記第２の鍵オーケストレーションデバイスの第２のデータベースにおいて第２の複数のポリシーを定義し、記憶することを更に備え、
    少なくとも、前記第１の複数のポリシーの第１の部分と前記第２の複数のポリシーの第２の部分は同じである、
    請求項１２に記載のプロセス。
14. 前記第１の鍵オーケストレーションデバイスから前記第２の鍵オーケストレーションデバイスに、前記セキュリティオブジェクトを送ることと、
    前記第２のエンタープライズに関連付けられた第２の通信デバイスに、前記セキュリティオブジェクトを配布することと、ここにおいて、前記第１の通信デバイスと前記第２の通信デバイスは、前記セキュリティオブジェクトに基づいて通信を確立する、
    を更に備えた、請求項１２に記載のプロセス。
15. 前記第１の鍵オーケストレーションデバイスから前記第２の鍵オーケストレーションデバイスに、前記セキュリティオブジェクトを送ることと、
    前記第２の鍵オーケストレーションデバイスでもって、前記少なくとも１つのオブジェクト属性と前記少なくとも１つのオブジェクト属性に対応する前記第２の複数のポリシーの内の少なくとも１つとに少なくとも部分的に基づいて、前記セキュリティオブジェクトの容認性を決定することと、
    前記第２のエンタープライズに関連付けられた第２の通信デバイスに前記セキュリティオブジェクトを配布することと、ここにおいて、前記第１の通信デバイスと前記第２の通信デバイスは、前記セキュリティオブジェクトに基づいて通信を確立する、
    を更に備える、請求項１３に記載のプロセス。
16. 第２の鍵オーケストレーションデバイスから、前記セキュリティオブジェクトと前記セキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性を受け取ることは、
    前記第２の鍵オーケストレーションデバイスから前記第１の鍵オーケストレーションデバイスによって、前記セキュリティオブジェクトを生成するための要求を受け取ることと、
    前記第１のエンタープライズに関連付けられた鍵ソースでもって、前記要求に応答して前記セキュリティオブジェクトを生成することと、
    を備える、請求項１２に記載のプロセス。
17. 実行されたとき、プロセッサに、
    データベースの中に複数のポリシーを定義させる、
    セキュリティオブジェクトと前記セキュリティオブジェクトに関連付けられた少なくとも１つのオブジェクト属性を受け取らせる、
    前記少なくとも１つのオブジェクト属性と前記少なくとも１つのオブジェクト属性に対応する前記複数のポリシーの内の少なくとも１つとに少なくとも部分的に基づいて、前記セキュリティオブジェクトの容認性を決定させる、
    前記セキュリティオブジェクトが容認可能と決定された場合に、前記プロセッサに関連付けられた少なくとも１つの通信デバイスに前記セキュリティオブジェクトを配布させる、ここにおいて、前記少なくとも１つの通信デバイスは、前記セキュリティオブジェクトに少なくとも部分的に基づいて通信を確立する、
    コンピュータ読出し可能命令を備えるコンピュータ読出し可能な媒体。
18. 前記セキュリティオブジェクトは暗号化鍵である、請求項１７に記載のコンピュータ読出し可能な媒体。
19. 前記少なくとも１つのオブジェクト属性は、セキュリティオブジェクトサイズ、セキュリティオブジェクトが生成された時間、セキュリティオブジェクトが生成された地理位置、セキュリティオブジェクトの分類、鍵ソースに関連付けられた役割、ソースデバイスに関連付けられた役割、および、ターゲットデバイスに関連付けられた役割の内の少なくとも１つを備える、請求項１７に記載のコンピュータ読出し可能な媒体。
20. 前記複数のポリシーは、前記セキュリティオブジェクトサイズが所定のサイズ範囲にある場合、前記セキュリティオブジェクトが生成された前記時間が所定の時間間隔の中にある場合、前記セキュリティオブジェクトが生成された前記地理位置が所定のエリアの中にある場合、前記セキュリティオブジェクトの前記分類が所定のセキュリティオブジェクト分類グループの中に含まれている場合、前記鍵ソース、前記ソースデバイス、または、前記ターゲットデバイスに関連付けられた前記役割が役割の所定のグループに関連付けられている場合の少なくとも１つの場合に前記セキュリティオブジェクトを容認することを備える、請求項１９に記載のコンピュータ読出し可能な媒体。

Images