(57)【要約】  テナントからサービスプロバイダーへデータを転送する方法は、サービスプロバイダーシステム内の安全デバイスによって生成されたパブリックキーのキーペアによりデータを暗号化する工程を有する。データは転送中にサービスプロバイダーによってアクセス不能である。データは、格納されるとデータの特定の使用を許可するために有効サーティフィケートが与えられなければならないことを特定する、対応するアクセスコントロールリストとともに生成される。したがってテナントは、たとえそれがテナントシステムの外部に転送されたとしてもデータの使用のコントロールを維持することができる。サービスプロバイダーシステム内に安全に格納されたデータの使用をコントロールする方法は、データの使用をリクエストするパーティーに対して、満了時間を有する使用サーティフィケートを発行する工程を有する。使用サーティフィケートは、格納されたデータの使用が許可される前に認証されなければならない。これにより、テナントは、制限された時間間隔の間に、格納されたデータの使用を許可することができる。
2019509667.tif 000002
【特許請求の範囲】
【請求項１】
テナントシステム内の第１セキュリティコンテキストと、サービスプロバイダーシステム内の第２セキュリティコンテキストとの間でデータ転送する方法であって、当該方法は、
第１セキュリティコンテキスト内のデータに対応するアクセスコントロールリストを生成する工程であって、前記アクセスコントロールリストは、有効使用クレデンシャルが前記データの使用の第１のタイプを許可するために与えられなければならないことを特定する、ところの工程と、
第１暗号キーペアおよび第１暗号サーティフィケートを前記第２セキュリティコンテキスト内で生成する工程であって、前記第１暗号キーペアは、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを有し、前記第１暗号サーティフィケートは前記第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報を含むところの工程と、
前記第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび前記第１暗号サーティフィケートを前記第１セキュリティコンテキストに送信する工程と、
前記第１セキュリティコンテキスト内で前記第１暗号サーティフィケートを認証する工程と、
前記第１暗号サーティフィケートが有効であれば、前記第１セキュリティコンテキスト内で、前記第１パブリックキーＫＢＬＯＢ  ｐｕｂによって前記データおよび前記対応するアクセスコントロールリストを暗号化する工程と、
前記暗号化したデータおよび対応するアクセスコントロールリスト、および、前記データの起源を認証可能な情報を、前記第２セキュリティコンテキストへ送信する工程と
を備える方法。
【請求項２】
前記データは、暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１セキュリティコンテキスト内で前記暗号キーＫｔｅｎａｎｔを生成する工程をさらに備える、請求項２に記載の方法。
【請求項４】
前記第２セキュリティコンテキストにおいて、前記暗号キーＫｔｅｎａｎｔの起源を認証する工程と、
前記暗号化した暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストを、前記第１プライベートキーＫＢＬＯＢ  ｐｒｉｖによって、前記第２セキュリティコンテキストにおいて解読する工程と
をさらに備える請求項３に記載の方法。
【請求項５】
前記第２セキュリティコンテキストにおいて、他の暗号キーによって前記暗号キーＫｔｅｎａｎｔを再暗号化する工程であって、前記他の暗号キーは前記第２セキュリティコンテキストを離れることができない、ところの工程と、
前記再暗号化された暗号キーＫｔｅｎａｎｔ、対応するアクセスコントロールリスト、および、暗号キーＫｔｅｎａｎｔの起源を認証可能な情報を格納する工程と
をさらに備える請求項４に記載の方法。
【請求項６】
前記使用の第１のタイプは、ひとつ以上の暗号オペレーションである、ことを特徴とする請求項２から５のいずれか一項に記載の方法。
【請求項７】
前記第２セキュリティコンテキストが信用される製造業者によって製造されたものであること、前記第２セキュリティコンテキストのコンフィギュレーションが前記テナントのセキュリティ要求に一致すること、および、前記第２セキュリティコンテキストがＡＣＬ内に含まれるポリシーを行使するように構成されていることを、前記第１セキュリティコンテキストにおいて認証する工程をさらに備える請求項２から６のいずれか一項に記載の方法。
【請求項８】
前記第２セキュリティコンテキストが第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖを格納する請求項２から７のいずれか一項に記載の方法であって、当該方法は、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別サーティフィケートを、前記第２セキュリティコンテキストから前記第１セキュリティコンテキストへ送信する工程であって、前記第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖは、暗号キーペアであり、前記第２識別サーティフィケートはＫ２ＩＤ  ｐｕｂを同定する情報を有し、かつ、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされる、ところの工程をさらに備える方法。
【請求項９】
前記第２セキュリティコンテキストのカレントのコンフィギュレーションに関連する情報を生成する工程と、
前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖにより、前記情報を暗号化サインする工程と、
サイン済みの情報を前記第２セキュリティコンテキストから前記第１セキュリティコンテキストへ送信する工程と
をさらに備える請求項８に記載の方法。
【請求項１０】
前記第１暗号サーティフィケートは、前記第２セキュリティコンテキストのカレントのコンフィギュレーションに関連する情報を有し、かつ、前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによってサインされる、ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１セキュリティコンテキストが第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖを格納するところの請求項８から１０のいずれか一項に記載の方法であって、当該方法は、
第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを前記第１セキュリティコンテキストから前記第２セキュリティコンテキストへ送信する工程であって、前記第１識別プライベートキーＫ１ＩＤ  ｐｕｂおよび前記第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖは暗号キーペアであり、前記第１識別サーティフィケートは、Ｋ１ＩＤ  ｐｕｂを同定する情報を有し、かつ、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされる、ところの工程をさらに備える方法。
【請求項１２】
第２暗号キーペアおよび第２暗号サーティフィケートを前記第１セキュリティコンテキスト内で生成する工程であって、前記第２暗号キーペアは第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂ、および、第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖを有し、前記第２暗号サーティフィケートは前記第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を同定可能な情報を有する、ところの工程と、
前記第２暗号サーティフィケートを前記第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖによって暗号化サインする工程と、
前記第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびサイン済み前記第２暗号サーティフィケートを前記第２セキュリティコンテキストへ送信する工程と、
前記第２暗号サーティフィケートを、前記第１識別プライベートキーＫ１ＩＤ  ｐｕｂを使って検証する工程と
をさらに備える請求項１１に記載の方法。
【請求項１３】
前記アクセスコントロールリストは、前記使用クレデンシャルが、前記暗号キーＫｔｅｎａｎｔの前記第１のタイプの使用を許可するために、前記第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされる使用サーティフィケートであることを特定する、ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記暗号キーＫｔｅｎａｎｔの起源を認証可能な前記情報は、暗号化された暗号キーＫｔｅｎａｎｔ、およびＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされた対応するアクセスコントロールリストを有する、ことを特徴とする請求項１２または１３に記載の方法。
【請求項１５】
前記暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、暗号キーＫｔｅｎａｎｔの起源を認証可能な情報を前記第２セキュリティコンテキストへ送信する工程は、
暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストをＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによって暗号化サインする工程と、
前記暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、前記暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、および、Ｋｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュを、前記第２セキュリティコンテキストへ送信する工程と
を有する、ことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記アクセスコントロールリストは、前記使用クレデンシャルが、前記使用クレデンシャルの満期を決定可能な情報を有しなければならず、かつ、有効であるために満了前でなければならないことを特定する、ことを特徴とする請求項２から１５のいずれか一項に記載の方法。
【請求項１７】
前記アクセスコントロールリストは、前記暗号キーＫｔｅｎａｎｔが、前記第２セキュリティコンテキストを離れることができないキーによって第２セキュリティコンテキストの外部に格納用にのみ暗号化されることを特定する、ことを特徴とする請求項２から１６のいずれか一項に記載の方法。
【請求項１８】
前記第１暗号サーティフィケートは、ＫＢＬＯＢ  ｐｒｉｖが一時的なものであること、ＫＢＬＯＢ  ｐｒｉｖが前記第２セキュリティコンテキストを離れることができないことを認証する、ことを特徴とする請求項２から１７のいずれか一項に記載の方法。
【請求項１９】
請求項１から１８のいずれか一項に記載の方法を、コンピュータに実行させるように構成された、コンピュータ読み取り可能コードを有するキャリア媒体。
【請求項２０】
第１セキュリティコンテキストを有する暗号デバイスであって、前記第１セキュリティコンテキストは、
第１パブリックキーＫＢＬＯＢ  ｐｕｂ、および、前記第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な第１暗号サーティフィケートを、第２セキュリティコンテキストから受信するように構成された第１トランシーバと、
暗号オペレーションを実行するように構成された第１プロセッサであって、前記第１プロセッサは、
転送されるべきデータに対応するアクセスコントロールリストを生成し、ここで前記アクセスコントロールリストは、有効使用クレデンシャルが前記データの使用の第１のタイプを許可するために与えられなければならなず、
前記第１パブリックキーＫＢＬＯＢ  ｐｕｂが前記第２セキュリティコンテキストを起源とすることを認証し、
前記データおよび前記対応するアクセスコントロールリストを前記第１パブリックキーＫＢＬＯＢ  ｐｕｂによって暗号化する
ように構成されており、
前記第１トランシーバは、前記暗号化されたデータおよび対応するアクセスコントロールリスト、および、前記データの起源を認証可能な情報を前記第２セキュリティコンテキストへ送信するように構成されている、ことを特徴とするデバイス。
【請求項２１】
前記データは、暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項２０に記載のデバイス。
【請求項２２】
第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖを格納する第１デバイスメモリをさらに備え、前記第１トランシーバはさらに、
第１識別プライベートキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを前記第２セキュリティコンテキストへ送信し、ここで、前記第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび前記第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖは暗号キーペアであり、前記第１識別サーティフィケートは、Ｋ１ＩＤ  ｐｕｂを同定する情報を有し、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされ、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別サーティフィケートを前記第２セキュリティコンテキストから受信し、前記第２識別サーティフィケートは、Ｋ２ＩＤ  ｐｕｂを同定する情報を有し、かつ、前記製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされる
ように構成されており、
前記第１プロセッサは、前記製造業者パブリックキーＫｍａｎ  ｐｒｉｖを使って前記第２識別サーティフィケートを検証するようにさらに構成されている、ことを特徴とする請求項２１に記載のデバイス。
【請求項２３】
前記第１トランシーバはさらに、
前記第２セキュリティコンテキストのカレントコンフィギュレーションに関連する情報を受信するように構成され、前記情報は第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによって暗号化サインされ、前記第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖは暗号キーペアであり、
前記第１プロセッサは、
前記第２識別パブリックキーＫ２ＩＤ  ｐｕｂを使って前記サインを検証し、
前記第２セキュリティコンテキストの前記コンフィギュレーションが前記テナントの安全要求に一致すること、および、前記第２セキュリティコンテキストが前記ＡＣＬ内の含まれる前記ポリシーを行使するように構成されていることを認証する
ようにさらに構成されている、ことを特徴とする請求項２２に記載のデバイス。
【請求項２４】
前記第１プロセッサは、さらに
第２暗号キーペアおよび第２暗号サーティフィケートを前記第１セキュリティコンテキスト内で生成するように構成され、前記第２暗号キーペアは、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよび第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖを有し、前記第２暗号サーティフィケートは、前記第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を同定可能な情報を有し、
前記第２暗号サーティフィケートを前記第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖによって暗号化サインするよう構成され、
前記第１トランシーバは、前記第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよび前記サインされた第２暗号サーティフィケートを前記第２セキュリティコンテキストへ送信するようにさらに構成されている、ことを特徴とする請求項２３に記載のデバイス。
【請求項２５】
第１セキュリティコンテキストを有するデバイスと協働する、第２セキュリティコンテキストを有する暗号デバイスであって、前記暗号デバイスは、
暗号オペレーションを実行するように構成されたプロセッサであって、前記プロセッサは、第１暗号キーペアおよび第１暗号サーティフィケートを生成するように構成され、前記第１暗号キーペアは、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを有し、前記第１暗号サーティフィケートは、前記第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報を有する、ところのプロセッサと、
トランシーバであって、前記第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび前記第１暗号サーティフィケートを第１セキュリティコンテキストに送信し、かつ
暗号化されたデータおよび対応するアクセスコントロールリスト、および、前記データの起源を認証可能な情報を前記第１セキュリティコンテキストから受信するように構成されているトランシーバと、
を備え、
前記プロセッサはさらに、
前記データの起源を認証し、かつ、前記第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを使って、前記暗号化されたデータおよび対応するアクセスコントロールリストを解読するように構成されている、ことを特徴とするデバイス。
【請求項２６】
前記データは、暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項２５に記載のデバイス。
【請求項２７】
前記プロセッサはさらに、前記暗号キーＫｔｅｎａｎｔを他の暗号キーによって再暗号化するように構成され、前記他の暗号キーは前記第２セキュリティコンテキストを離れることができない、ことを特徴とする請求項２６に記載のデバイス。
【請求項２８】
第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖを格納するデバイスメモリをさらに備え、
前記トランシーバはさらに、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別サーティフィケートを前記第１セキュリティコンテキストへ送信するように構成され、前記第２識別パブリックキーＫ２ＩＤ  ｐｕｂはおよび前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖは暗号キーペアであり、前記第２識別サーティフィケートは、Ｋ２ＩＤ  ｐｕｂを同定する情報を有し、かつ、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされ、
第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを前記第１セキュリティコンテキストから受信するように構成され、前記第１識別サーティフィケートはＫ１ＩＤ  ｐｕｂを同定する情報を有し、かつ、前記製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号サインされ、
前記プロセッサはさらに、前記製造業者パブリックキーＫｍａｎ  ｐｕｂを使って前記第１識別サーティフィケートを検証するように構成されている、ことを特徴とする請求項２７に記載のデバイス。
【請求項２９】
前記プロセッサはさらに、
前記第２セキュリティコンテキストの前記カレントコンフィギュレーションに関連する情報を生成し、かつ、前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによって前記情報を暗号化サインするように構成され、
前記トランシーバはさらに、前記情報およびサインを前記第１セキュリティコンテキストへ送信するように構成されている、ことを特徴とする請求項２８に記載のデバイス。
【請求項３０】
前記プロセッサはさらに、前記第２セキュリティコンテキストの前記カレントコンフィギュレーションに関連する情報を有する前記第１暗号サーティフィケートを生成し、かつ、前記第１暗号サーティフィケートを前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによってサインするように構成されている、ことを特徴とする請求項２９に記載のデバイス。
【請求項３１】
前記トランシーバはさらに、
第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびサインされた第２暗号サーティフィケートを前記第２セキュリティコンテキストから受信するように構成され、前記第２暗号サーティフィケートは、前記第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証可能な情報を有し、
前記プロセッサはさらに、前記第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証するように構成されている、ことを特徴とする請求項２８から３０のいずれか一項に記載のデバイス。
【請求項３２】
サービスプロバイダー内の信用された第２セキュリティコンテキストにはアクセス可能であるが、残りのサービスプロバイダーシステムからは安全であるような方法でサービスプロバイダー内に格納されたデータの使用をコントロールする方法であり、アクセスコントロールリストは、格納されたデータの使用の第１のタイプ許可するために、有効使用クレデンシャルが前記データにより与えられなければならないことを特定する方法であって、
使用クレデンシャルを第１セキュリティコンテキスト内で生成する工程であって、前記使用クレデンシャルは、
前記使用クレデンシャルに対応するデータを同定可能である情報、および
前記使用クレデンシャルの満期を判定する情報を有する、ところの工程と、
前記使用クレデンシャル、および前記使用クレデンシャルの起源を認証可能な情報を発行する工程と、
前記アクセスコントロールリストに関して前記使用クレデンシャルを認証し、かつ、前記使用クレデンシャルが前記第２セキュリティコンテキストにおいて満了しなかったことを認証する工程と、前記データの使用の前記第１のタイプを、前記第２セキュリティコンテキスト内で、前記使用クレデンシャルが有効でありかつ満了していないことを条件に許可する工程と
を備える方法。
【請求項３３】
前記データは、暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項３２に記載の方法。
【請求項３４】
前記使用の第１のタイプは、ひとつ以上の暗号オペレーションである、ことを特徴とする請求項３３に記載の方法。
【請求項３５】
前記使用クレデンシャル、および前記使用クレデンシャルの起源を認証可能な情報は、前記サービスプロバイダーに発行され、当該方法は、
前記使用クレデンシャル、および、前記使用クレデンシャルの起源を認証可能な情報、および、前記キーＫｔｅｎａｎｔによって、使用の第１のタイプであるオペレーションを実行するリクエストを前記第２セキュリティコンテキストに与える工程と、
前記使用クレデンシャルが有効でありかつ満了していないことを条件に、前記第２セキュリティコンテキストにおいて前記オペレーションを実行する工程と
をさらに備える請求項３４に記載の方法。
【請求項３６】
前記使用クレデンシャルは使用サーティフィケートである、請求項３３から３５のいずれか一項に記載の方法であって、当該方法は、
前記使用サーティフィケートを前記第１セキュリティコンテキスト内で、プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによって暗号化サインする工程であって、前記使用サーティフィケートの起源を認証可能な情報はサインであり、前記対応するパブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂはインテグリティ保護され、前記第２セキュリティコンテキストにアクセス可能である、ところの工程と、
前記パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂを使って前記第２セキュリティコンテキストにおいて前記使用サーティフィケートを検証する工程と
をさらに備える方法。
【請求項３７】
前記使用クレデンシャルの満期を判定可能な情報は、満了時間、および基準時間ソースを同定する情報を有する、ことを特徴とする請求項３３から３６のいずれか一項に記載の方法。
【請求項３８】
前記使用サーティフィケートに対応する前記暗号キーＫｔｅｎａｎｔを同定可能な情報はＫｔｅｎａｎｔのハッシュである、ことを特徴とする請求項３３から３７のいずれか一項に記載の方法。
【請求項３９】
請求項３２から３８のいずれか一項に記載の方法をコンピュータに実行させるように構成されたコンピュータ読み取り可能なコードを有するキャリア媒体。
【請求項４０】
暗号化データと、
前記データに対応するアクセスコントロールリストであって、前記アクセスコントロールリストは、前記データの使用の第１のタイプを許可するために、有効使用クレデンシャルが与えられなければならないことを特定し、かつ、前記使用クレデンシャルが前記使用クレデンシャルの満期を判定可能な情報を有しなければならず、かつ、前記データの使用の第１のタイプを許可するために満了前でなければならないことを特定する、ところのアクセスコントロールリストと、
前記データの起源を同定可能な情報と
を格納するデバイスメモリを備えるデバイス。
【請求項４１】
前記デバイスは、第１セキュリティコンテキストを有するデバイスと協働する、第２セキュリティコンテキストを有する暗号デバイスであり、前記データは暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項４０に記載のデバイス。
【請求項４２】
前記アクセスコントロールリストは、前記使用クレデンシャルが、前記暗号キーＫｔｅｎａｎｔの使用を許可するために、プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされなければならない使用サーティフィケートであることを特定する、ことを特徴とする請求項４１に記載のデバイス。
【請求項４３】
前記アクセスコントロールリストは、前記使用クレデンシャルに対応する暗号キーＫｔｅｎａｎｔを認証可能な情報を有しなければならないことを特定する、ことを特徴とする請求項４１または４２に記載のデバイス。
【請求項４４】
前記暗号化された暗号キーＫｔｅｎａｎｔは、前記第２セキュリティコンテキストを離れることができないキーによって暗号化される、ことを特徴とする請求項４１から４３のいずれか一項に記載のデバイス。
【請求項４５】
プロセッサをさらに備え、前記プロセッサは、
前記アクセスコントロールリストに関する受信した使用サーティフィケートを認証し、かつ、前記使用クレデンシャルが満了前であることを認証し、
前記使用クレデンシャルが有効であり、かつ、満了前であることを条件に、前記第２セキュリティコンテキスト内で、前記暗号キーＫｔｅｎａｎｔの使用の前記第１のタイプを許可する
ように構成されている、ことを特徴とする請求項４１から４４のいずれか一項に記載のデバイス。
【請求項４６】
第１セキュリティコンテキストを備え、前記第１セキュリティコンテキストは、
第１プロセッサを有し、前記第１プロセッサは使用クレデンシャルを生成するように構成され、前記使用クレデンシャルは、
前記使用クレデンシャルに対応するデータを同定可能な情報、および、前記使用クレデンシャルの満期を判定可能な情報を有し、
第１トランシーバを有し、前記第１トランシーバは使用クレデンシャルおよび前記使用クレデンシャルの起源を認証可能な情報を送信するように構成されている、
ことを特徴とする暗号デバイス。
【請求項４７】
前記データは暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項４６に記載のデバイス。
【請求項４８】
前記第１セキュリティコンテキストは、
プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖを格納する第１デバイスメモリをさらに有し、
前記使用クレデンシャルは使用サーティフィケートであり、前記第１プロセッサは、前記使用サーティフィケートをプライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによって暗号化サインするように構成されている、ことを特徴とする請求項４７に記載のデバイス。
【請求項４９】
前記使用クレデンシャルの満期を判定可能な情報は、満了時間、および、基準時間ソースを同定する情報を有する、ことを特徴とする請求項４７または４８に記載のデバイス。
【請求項５０】
前記使用クレデンシャルに対応する前記暗号キーＫｔｅｎａｎｔを同定可能な情報はＫｔｅｎａｎｔのハッシュである、ことを特徴とする請求項４７から４９のいずれか一項に記載のデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
本願発明は、データ転送方法、データ使用のコントロール方法、および暗号デバイスに関する。
【背景技術】
【０００２】
インターネットは、サービスプロバイダーによって提供されるコンピュータ実行サービスを使う多くの組織を生じさせた。それらは、以前はそれ自身をホストすることを要求されたものであった。サービスプロバイダーは、そのコンピュータ実行サービスを、多くの組織（テナント）に提供することができる。この一例は、サービスプロバイダーのＣＳＰｓであり、それは、サービス型ソフトウエア（ＳａａＳ）またはストレージオンデマンドのような製品を提供している。サービスプロバイダーが提供するコンピュータ実行サービスの使用により、テナントは、このようなサービス自身をホストする管理コストを削減することができる。
【０００３】
複数テナント型のコンピュータ実行サービスを提供するよう努力してきたサービスプロバイダーの領域は、暗号インフラストラクチャーセクター内にあり、特に、ハードウエアセキュリティモジュール、ＨＳＭｓ内にある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
サービスプロバイダーによりホストされた従来のＨＭＳは、シングルテナンシーソリューションを使用する。すなわち、テナントに代わって、データの安全暗号化処理および暗号キーの保管が可能となる。サービスプロバイダーは、ＩＰアドレスのような暗号アプライアンスの環境設定を管理し、一方、テナントは従来の方法で暗号インフラストラクチャーを遠隔的に管理する。したがって、サービスプロバイダーは、テナントごとにアプライアンスを提供しなければならず、テナントは以前と同様に暗号アプライアンスのメンテナンスおよび管理をしなければならない。このようなシステムは非効率的であり、暗号リソースの利用低下を招く。
【０００５】
また、このようなシステムは脆弱である。サービスプロバイダーは、王国への鍵（keysto  the  kingdom）すなわち、ＨＳＭ内に格納された原料キーをエキスポートする能力をしばしば有する。サービスプロバイダーに与えられた許可は、ホストされたテナントキーのセキュリティを弱くする。これは、テナント、サービスプロバイダーの両方に対して、多くの問題を生じさせる。例えば、サービスプロバイダーによるテナントの暗号キーの可能な悪用、テナントではなくサービスプロバイダーに対する裁判管轄を有するセキュリティエージェンシーに対するテナントキーの露出、他のテナントによるテナントキーの使用などである。
【課題を解決するための手段】
【０００６】
本願発明の第１の態様において、テナントシステムの第１のセキュリティコンテキストと、サービスプロバイダーシステムの第２のセキュリティコンテキストとの間でのデータ転送の方法が与えられる。当該方法は、
第１のセキュリティコンテキスト内のデータに対応するアクセスコントロールリストを生成する工程であって、当該アクセルコントロールリストは、有効な使用クレデンシャルは、第１のタイプのデータの使用を許可するために与えられなければならないところの工程と、
第２のセキュリティコンテキスト内に、第１の暗号キーペアおよび第１暗号サーティフィケートを生成する工程であって、第１暗号キーペアは、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを有し、第１暗号サーティフィケートは、第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報を有する、ところの工程と、
第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１の暗号サーティフィケートを第１セキュリティコンテキストに送信する工程と、
第１セキュリティコンテキスト内の第１暗号サーティフィケートを認証する工程と、
第１暗号サーティフィケートが有効であれば、第１セキュリティコンテキスト内の第１パブリックキーＫＢＬＯＢ  ｐｕｂにより、データおよび対応するアクセスコントロールリストを暗号化する工程と、
暗号化されたデータおよび対応するアクセスコントロールリスト、および、データの起源を認証する情報を、第２セキュリティコンテキストへ送信する工程と
を有する。
【０００７】
実施形態において、使用クレデンシャルは、使用サーティフィケートである。
【０００８】
実施形態において、データは、暗号キーＫｔｅｎａｎｔを有する。方法はさらに、第１のセキュリティコンテキスト内で暗号キーＫｔｅｎａｎｔを生成する工程を有する。使用の第１のタイプは、ひとつ以上の暗号オペレーションであってよい。
【０００９】
実施形態において、方法は、さらに、暗号データを送る前に第２セキュリティコンテキストが信用されることを、テナントシステムにおいて確立する工程を有する。
【００１０】
信用の確立は、第２のセキュリティコンテキストが信用された製造業者により製造されたこと、第２のセキュリティコンテキストのコンフィギュレーションがテナントのセキュリティ要求に一致すること、および、第２のセキュリティコンテキストがＡＣＬ内に含まれるポリシーを行使するように構成されていることを第１セキュリティコンテキストにおいて認証することを含む。
【００１１】
実施形態において、暗号化データを第２のセキュリティコンテキストに送る直前に、第２のセキュリティコンテキストのコンフィギュレーションが第２セキュリティ要求に一致していることが認証される。
【００１２】
信用を確立する工程は、第２のセキュリティコンテキストの状態が製造業のセキュリティ要求に一致していることを認証する工程、例えば、サービスプロバイダーによる攻撃に対してソフトウエアおよびハードウエアが鈍感であることを認証する工程を有する。
【００１３】
製造業者プライベートキーは、第２セキュリティコンテキストが信用された製造業者によって製造されたことを認証するのに使用され、かつ、第２セキュリティコンテキストの第２識別パブリックキーを認証するのに使用される。
【００１４】
実施形態において、第２セキュリティコンテキストは、第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖを格納する。当該方法はさらに、第２セキュリティ識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別サーティフィケートを第２セキュリティコンテキストから第１セキュリティコンテキストへ送る工程であって、第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖが暗号キーペアであり、第２識別サーティフィケートは、Ｋ２ＩＤ  ｐｕｂを同定する情報を有し、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされている。
【００１５】
実施形態において、第２識別サーティフィケートは、第２セキュリティコンテキストの状態を認証可能な情報をさらに有する。
【００１６】
実施形態において、当該方法はさらに、基準時間ソースが信用されることをテナントシステムにおいて確立する工程を有する。実施形態において、当該方法はさらに、基準時間が信用されることをサービスプロバイダーシステムにおいて確立する工程を有する。基準時間が使用されることを確立する工程は、基準時間が信用された製造業者によって製造されたものであること、および、基準時間ソースのコンフィギュレーションがセキュリティ要求に一致することを認証する工程を含む。
【００１７】
実施形態において、当該方法はさらに、
第２セキュリティコンテキストのカレントのコンフィギュレーションに関連する情報を生成する工程と、
第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖにより情報を暗号化サインする工程と、
サイン済みの情報を、第２セキュリティコンテキストから第１セキュリティコンテキストへ送信する工程とを有する。
【００１８】
実施形態において、第１暗号サーティフィケートは、第２セキュリティコンテキストのカレントの構成に関連する情報を有し、第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによってサインされる。
【００１９】
実施形態において、当該方法はさらに
第２暗号キーペアおよび第２暗号サーティフィケートを第１セキュリティコンテキスト内で生成する工程であって、第２暗号キーペアは、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂ、第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｉｖを有し、第２暗号サーティフィケートは第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証可能な情報を有するところの工程と、
第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよび第２暗号サーティフィケートを第２セキュリティコンテキストへ送信する工程とを有する。
【００２０】
実施形態において、第１セキュリティコンテキストは、第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖを格納し、当該方法はさらに、第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを第１セキュリティコンテキストから第２セキュリティコンテキストに送信する工程であって、第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖは暗号キーペアであり、第１識別サーティフィケートは、Ｋ１ＩＤ  ｐｕｂを識別する情報を有し、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされるところの工程とを有する。
【００２１】
実施形態において、第２暗号サーティフィケートは、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を識別可能な情報を有し、当該方法はさらに、
第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖにより第２暗号サーティフィケートを暗号化サインする工程と、
第２セキュリティコンテキストにおいて、第１識別パブリックキーＫ１ＩＤ  ｐｕｂを使って第２暗号サーティフィケートを認証する工程とを有する。
【００２２】
暗号キーＫｔｅｎａｎｔの起源を認証可能な情報は、暗号化された暗号キーＫｔｅｎａｎｔおよびＫｔｅｎａｎｔ−ｓｉｇｎｐｉｖによってサインされた対応するアクセスコントロールリストを有する。
【００２３】
暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、および暗号キーＫｔｅｎａｎｔの起源を認証可能な情報を第２セキュリティコンテキストに送信する工程は、
暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストをＫｔｅｎａｎｔ−ｓｉｇｎｐｉｖによって暗号化サインする工程と、
暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、暗号化された暗号キーＫｔｅｎａｎｔのサインおよび対応するアクセスコントロールリストおよびＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュを第２セキュリティコンテキストに送信する工程とを有する。
【００２４】
実施形態において、第１暗号サーティフィケートは、ＫＢＬＯＢ  ｐｒｉｖが一時的なものであり、ＫＢＬＯＢ  ｐｒｉｖは第２セキュリティコンテキストを離れることができないことを認証する。実施形態において、第１暗号サーティフィケートは、非対称キーペアが第２セキュリティコンテキスト内で生成されたことを認証する。第１プライベートキーＫＢＬＯＢ  ｐｒｉｖは、第２セキュリティコンテキスト内に格納される。
【００２５】
実施形態において、第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報は、第１パブリックキーＫＢＬＯＢ  ｐｕｂのサインされたハッシュである。第１暗号サーティフィケートは、第１パブリックキーＫＢＬＯＢ  ｐｕｂのハッシュを油脂、第２セキュリティコンテキストの識別キーのプライベートハーフＫ２ＩＤ  ｐｒｉｖによってサインされる。第１暗号サーティフィケートＣＢＬＯＢを認証する工程は、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂを使ってサインを認証する工程を有する。
【００２６】
実施形態において、第２セキュリティコンテキストは、残りのサービスプロバイダーシステムから安全である。
【００２７】
実施形態において、アクセスコントロール（ＡＣＬ）リストは、使用クレデンシャルが、当該使用クレデンシャルの起源を認証可能な情報を有しなければならないことを特定する。アクセスコントロールリストは、暗号キーＫｔｅｎｅｎｔの使用の第１のタイプを許可するべく、使用クレデンシャルが第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされなければならない使用サーティフィケートであることを特定する。
【００２８】
ＡＣＬは、使用サーティフィケートが、使用クレデンシャルの満期を決定可能な情報を有しなければならないこと、および、認証されるために満了前であることを特定する。
【００２９】
ＡＣＬは、テナント暗号キーＫｔｅｎａｎｔがサードパーティーによる改ざんに対抗できる不揮発性メモリ内にのみ格納されることを特定する。
【００３０】
実施形態において、ＡＣＬは、テナント暗号キーＫｔｅｎａｎｔが第２セキュリティコンテキスト内部にのみ格納されることを特定する。代替的実施形態において、ＡＣＬはテナント暗号キーＫｔｅｎａｎｔが、第２セキュリティコンテキストから離れることができないキーによって格納用に暗号化される状態でのみ格納されることの制限を含む。
【００３１】
実施形態において、当該方法はさらに、
第２セキュリティコンテキストにおいて、暗号キーＫｔｅｎａｎｔの期限を認証する工程と、
暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストを、第１プライベートキーＫＢＬＯＢ  ｐｒｉｖによって第２セキュリティコンテキストにおいて解読する工程とを有する。
【００３２】
実施形態において、当該方法はさらに、
第２セキュリティコンテキストにおいて、他の暗号キーにより、暗号キーＫｔｅｎａｎｔを再暗号化する工程であって、他の暗号キーは、第２セキュリティコンテキストを離れることができないところの工程と、
再暗号化された暗号キーＫｔｅｎａｎｔ、対応するアクセスコントロールリストおよび、暗号キーＫｔｅｎａｎｔの期限を認証可能な情報を格納する工程とを有する。
【００３３】
本願発明の他の態様において、上記したいずれかの方法をコンピュータに実行させることが可能なように構成されたコンピュータ読み取り可能コードを有するキャリア媒体が与えられる。
【００３４】
本願発明の他の態様において、データの使用をコントロールする方法が与えられ、当該データは、サービスプロバイダーシステム内の信用されたセキュリティコンテキストにアクセス可能であるが、残りのサービスプロバイダーからは安全である方法で、サービスプロバイダーシステム内に格納されており、データの使用の第１のタイプを許可するために、有効な使用クレデンシャルが与えられなければならないことを特定するアクセスコントロールリストがデータとともに格納されており、当該方法は、
第１セキュリティコンテキスト内で使用クレデンシャルを生成する工程であって、使用クレデンシャルは、
使用クレデンシャルに対応するデータが識別可能である情報と、
使用クレデンシャルの満期を決定可能である情報と
を有し、
使用クレデンシャルおよび当該使用クレデンシャルの起源が認証可能な情報を発行する工程と、
アクセスコントロールリストに関して使用クレデンシャルを認証し、かつ、当該使用クレデンシャルが第２セキュリティコンテキストにおいて満了しなかったことを認証する工程と、
使用クレデンシャルが有効でありかつ満了前である条件のもとで、第２のセキュリティコンテキスト内で、データの使用の第１のタイプを許可する工程と
を有する。
【００３５】
実施形態において、使用クレデンシャルは、使用サーティフィケートである。
【００３６】
実施形態において、データは、暗号キーＫｔｅｎａｎｔを有する。使用の第１のタイプは、ひとつ以上の暗号オペレーションである。
【００３７】
実施形態において、使用クレデンシャルの満期を決定可能な情報は
満了時間、および
基準時間ソースを同定する情報を有する。
【００３８】
実施形態において、当該方法はさらに、基準時間ソースが信用されたことをテナントシステムにおいて確立する工程を有する。実施形態において、当該方法はさらに、サービスプロバイダーシステムにおいて、基準時間ソースが信用されたことを確立する工程を有する。基準時間ソースが信用されたことを確立する工程は、基準時間ソースが信用された製造業者によって製造されたこと、および、基準時間ソースの状態およびコンフィギュレーションがセキュリティ要求に一致することを認証する工程を有する。
【００３９】
実施形態において、当該方法はさらに、第１セキュリティコンテキストへ、識別暗号キーペアの起源を認証する情報とともに時間ソースの識別暗号キーのパブリックハーフを与える工程を有する。
【００４０】
実施形態において、当該方法はさらに、第２セキュリティコンテキストへ、識別暗号キーペアの起源を認証する情報とともに、時間ソースの識別暗号キーペアのパブリックハーフを与える工程を有する。
【００４１】
実施形態において、第１セキュリティコンテキスト内で使用クレデンシャルを生成する工程は、
基準時間ソースを選択する工程と、
基準時間ソースからカレントのタイムスタンプを要求する工程と、
タイムスタンプに基づいて、満了時間を計算する工程とを有する。
【００４２】
実施形態において、当該方法は、
カレントのタイムスタンプを有するメッセージを、メッセージの起源を認証可能な情報とともにソースからテナントシステムへ送信する工程と、
メッセージの起源を認証する工程とを有する。
【００４３】
メッセージはさらに、基準時間ソースのカレント構成に関連する情報を有する。
【００４４】
メッセージの起源を認証する情報は、時間ソースの識別暗号キーペアのプライベートハーフによってサインされた、サイン済みメッセージであってよい。
【００４５】
実施形態において、スタート時間に関連する情報は、使用クレデンシャル内に含まれる。
【００４６】
使用クレデンシャルに対応するデータを同定可能な情報は、Ｋｔｅｎａｎｔのハッシュであってよい。
【００４７】
実施形態において、使用クレデンシャルは、使用サーティフィケートであり、当該方法はさらに、
第１セキュリティコンテキスト内で、使用サーティフィケートをプライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによって暗号化サインする工程であって、使用サーティフィケートの起源を認証可能な情報はサインであり、対応するパブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂは、インテグリティプロテクトであり、第２セキュリティコンテキストにアクセス可能である、ところの工程と、
第２セキュリティコンテキストにおいてパブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂを使って使用サーティフィケートを認証する工程とを有する。
【００４８】
実施形態において、当該方法はさらに、
使用クレデンシャル、該使用クレデンシャルの起源を認証可能である情報、および、使用の第１のタイプであるオペレーションをキーＫｔｅｎａｎｔによって実行するためのリクエストを第２セキュリティコンテキストに与える工程と、
使用クレデンシャルが有効でありかつ満了前である条件の下で、第２セキュリティコンテキストにおいてオペレーションを実行する工程とを有する。
【００４９】
実施形態において、使用クレデンシャルが第２セキュリティコンテキストにおいて満了前であることを認証する工程は、
基準時間ソースからカレントのタイムスタンプをリクエストする工程と、
基準時間ソースから第２セキュリティコンテキストへ、カレントのタイムスタンプを有するメッセージを、メッセージの起源を認証可能な情報とともに送信する工程と、
メッセージの起源を認証する工程とを有する。
【００５０】
メッセージの起源を認証する情報は、時間ソースの識別暗号キーペアのプライベートハーフによってサインされた、サイン済みメッセージであってよい。
【００５１】
使用クレデンシャルが第２セキュリティコンテキストにおいて満了前であることを認証する工程はさらに、
満了時間とタイムスタンプとを比較する工程を有する。
【００５２】
本願発明の他の態様において、上記したいずれかの方法をコンピュータに実行させるように構成されたコンピュータ読み取り可能なコードを有するキャリア媒体が与えられる。
【００５３】
本願発明の他の態様において、第１セキュリティコンテキストを有する暗号デバイスが与えられ、第１セキュリティコンテキストは、
第１パブリックキーＫＢＬＯＢ  ｐｕｂ、および第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報を有する暗号サーティフィケートを、第２セキュリティコンテキストから受信するように構成された第１トランシーバと、
暗号オペレーションを実行するように構成された第１プロセッサであって、該第１プロセッサであって、
転送されるべきデータに対応するアクセスコントロールリストを生成し、ここで、アクセスコントロールリストは、有効使用クレデンシャルがデータの使用の第１のタイプを許可するために与えられなければならないことを特定し、
第２セキュリティコンテキストから生成された第１暗号キーペアを認証し、
第１パブリックキーＫＢＬＯＢ  ｐｕｂによって、データおよび対応するアクセスコントロールリストを暗号化するように構成されたプロセッサと
を有し、
第１トランシーバは、暗号化されたデータおよび対応するアクセスコントロールリスト、および、データの起源を認証可能な情報を第２セキュリティコンテキストに送信するように構成されている。
【００５４】
実施形態において、使用クレデンシャルは、使用サーティフィケートである。
【００５５】
実施形態において、データは、暗号キーＫｔｅｎａｎｔを有する。
【００５６】
実施形態において、デバイスはさらに、
第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖを格納する第１デバイスメモリを有し、
第１トランシーバはさらに、
第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを第２セキュリティコンテキストに送信するように構成され、ここで、第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖは暗号キーペアであり、第１識別サーティフィケートはＫ１ＩＤ  ｐｕｂを同定する情報を有し、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされ、かつ、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂ、および第２識別サーティフィケートを第２セキュリティコンテキストから受信するように構成され、第２識別サーティフィケートは、Ｋ２ＩＤ  ｐｕｂを同定する情報を有し、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされており、
第１プロセッサはさらに、製造業者パブリックキーＫｍａｎ  ｐｕｂを使って第２識別サーティフィケートを認証するように構成されている。
【００５７】
実施形態において、第１トランシーバはさらに、
第２セキュリティコンテキストのカレントのコンフィギュレーションに関する情報を受信するように構成され、ここで、情報は第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによって暗号化サインされ、第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別プライベートキーは、暗号キーペアであり、第１プロセッサはさらに、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂを使ってサインを検証し、
第２セキュリティコンテキストのコンフィギュレーションがテナントのセキュリティ要求に一致すること、および、第２セキュリティコンテキストがＡＣＬ内に含まれるポリシーを行使するように構成されていることを認証するように構成されている。
【００５８】
実施形態において、第１プロセッサはさらに、
第２暗号キーペアおよび第２暗号サーティフィケートを第１セキュリティコンテキスト内に生成するように構成され、第２暗号キーペアは第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂ、第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖを有し、第２暗号サーティフィケートは、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を同定可能な情報を有し、かつ、
第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖによって、第２暗号サーティフィケートを暗号化サインするように構成され、
第１トランシーバはさらに、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびサイン済み第２暗号サーティフィケートを第２セキュリティコンテキストへ送信するように構成されている。
【００５９】
本願発明の他の態様において、第１セキュリティコンテキストを有する暗号デバイスが提供され、当該デバイスは、
使用クレデンシャルを生成するように構成された第１プロセッサであって、当該使用クレデンシャルは、使用クレデンシャルに対応するデータを同定可能な情報と、
使用クレデンシャルの満期を決定可能な情報を有する、ところの第１プロセッサと、
使用クレデンシャル、および使用クレデンシャルの起源を認証可能な情報を第２セキュリティコンテキストに送信するように構成された第１トランシーバとを有する。
【００６０】
実施形態において、使用クレデンシャルは使用クレデンシャルである。
【００６１】
実施形態において、データは暗号キーＫｔｅｎａｎｔを有する。
【００６２】
実施形態において、第１セキュリティコンテキストはさらに、
プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖを格納する第１デバイスメモリを有し、第１プロセッサは、使用クレデンシャルをプライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによって暗号化サインするように構成されている。
【００６３】
実施形態において、使用クレデンシャルは、使用サーティフィケートである。
【００６４】
実施形態において、使用クレデンシャルの満期を決定可能な情報は、
満了時間と、
基準時間ソースを識別する情報とを有する。
【００６５】
実施形態において、使用クレデンシャルに対応する暗号キーＫｔｅｎａｎｔが同定可能な情報は、Ｋｔｅｎａｎｔのハッシュである。
【００６６】
本願発明の他の態様において、第１セキュリティコンテキストを有するデバイスと協働する、第２セキュリティコンテキストを有する暗号デバイスが提供され、当該暗号デバイスは、
暗号オペレーションを実行するように構成されたプロセッサであって、当該プロセッサは、
第１暗号キーペアおよび第１暗号サーティフィケートを生成するように構成され、第１暗号キーペアは、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを有し、第１暗号サーティフィケートは第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報を有し、
第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１暗号サーティフィケートを第１セキュリティコンテキストに送信し、
暗号化データおよび対応するアクセスコントロールリスト、および、データの起源を認証可能な情報を、第１セキュリティコンテキストから受信するように構成されたトランシーバと、
を有し、プロセッサはさらに
データの起源を認証し、
暗号化データおよび対応するアクセスコントロールリストを、第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを使って解読するように構成される。
【００６７】
実施形態において、使用クレデンシャルは使用サーティフィケートである。
【００６８】
実施形態において、データは、暗号キーＫｔｅｎａｎｔである。
【００６９】
実施形態において、プロセッサはさらに、
他の暗号キーによって暗号キーＫｔｅｎａｎｔを再暗号化するように構成され、当該他の暗号キーは、第２セキュリティコンテキストを離れることができない。
【００７０】
実施形態において、当該デバイスはさらに、第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖを格納するデバイスメモリを有し、トランシーバはさらに、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別サーティフィケートを第１セキュリティコンテキストに送信するように構成され、第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖは暗号キーペアであり、第２識別サーティフィケートはＫ２ＩＤ  ｐｕｂを同定するための情報を有し、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされており、
第１識別プライベートキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを第１セキュリティコンテキストから受信するよう構成され、第１識別サーティフィケートはＫ１ＩＤ  ｐｕｂを同定する情報を有し、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされ、
プロセッサはさらに、
製造業者パブリックキーＫｍａｎ  ｐｕｂを使って第１識別サーティフィケートを検証する。
【００７１】
実施形態において、プロセッサはさらに、
第２セキュリティコンテキストのカレント構成に関連する情報を生成し、
第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによって情報を暗号化サインするように構成され、
トランシーバはさらに、
情報およびサインを第１セキュリティコンテキストに送信するように構成されている。
【００７２】
実施形態において、プロセッサは、
第２セキュリティコンテキストのカレント構成に関連する情報を有する第１暗号サーティフィケートを生成し、第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによって第１暗号サーティフィケートをサインするように構成される。
【００７３】
実施形態において、トランシーバはさらに
第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびサイン済み第２暗号サーティフィケートを第１セキュリティコンテキストから受信するように構成され、第２暗号サーティフィケートは第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証可能な情報を有し、
プロセッサはさらに、
第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証するように構成されている。
【００７４】
本願発明の他の態様において、デバイスが与えられ、当該デバイスは、メモリを有し、当該メモリは、
暗号データ、および
データに対応するアクセスコントロールリストであって、アクセスコントロールリストは、データの使用の第１のタイプを許可するために有効使用クレデンシャルが与えられなければならないことを特定し、かつ、使用クレデンシャルが、使用クレデンシャルの満期が決定可能な情報を有しなければならず、かつ、データの使用の第１の第プライベートキーを許可するために満了前であることを特定する、アクセスコントロールリストと、
データの起源が同定可能である情報を格納する。
【００７５】
実施形態において、使用クレデンシャルは、使用サーティフィケートである。
【００７６】
実施形態において、デバイスは、第１セキュリティコンテキストを有するデバイスと協働する、第２セキュリティコンテキストを有する暗号デバイスである。
【００７７】
実施形態において、データは、暗号キーＫｔｅｎａｎｔを有する。
【００７８】
アクセスコントロールリストは、使用クレデンシャルが、暗号キーＫｔｅｎａｎｔの使用を許可するために、プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされるべき使用サーティフィケートであることを特定する。
【００７９】
アクセスコントロールリストは、使用クレデンシャルが、使用クレデンシャルに対応する暗号キーＫｔｅｎａｎｔが同定可能な情報を有しなければならないことを特定する。
【００８０】
実施形態において、暗号化された暗号キーＫｔｅｎａｎｔは、第２セキュリティコンテキストを離れることができないキーによって暗号化される。
【００８１】
実施形態において、デバイスはさらに、
アクセスコントロールリストに関して受信した使用クレデンシャルを認証し、かつ、使用クレデンシャルが満了前であることを認証するように構成され、かつ
使用クレデンシャルが有効でありかつ満了前であるという条件のもとで、第２セキュリティコンテキスト内で暗号キーＫｔｅｎａｎｔの使用の第１のタイプを許可するように構成されたプロセッサを有する。
【００８２】
実施形態において、テナントからサービスプロバイダーへデータを転送する方法が与えられ、当該方法は、サービスプロバイダーシステム内でセキュアデバイスにより生成されたキーペアのパブリックキーによってデータを暗号化する工程を有する。したがってデータは、転送中にサービスプロバイダーによってアクセス不能である。
【００８３】
対応するアクセスコントロールリストとともにデータが生成され、それは、一度格納されたデータの特定の使用を許可するために、認証サーティフィケートが与えられなければならないことを特定する。したがってテナントは、テナントシステムの外部にデータが転送されたとしても、データの使用のコントロールを維持することができる。
【００８４】
実施形態において、サービスプロバイダーシステム内に安全に格納されたデータの使用をコントロールする方法が与えられ、当該方法は、データの使用をリクエストするパーティーに対して満了時間を有する使用クレデンシャルを発行する工程を有する。使用クレデンシャルは、格納されたデータの使用が許可される前に、認証されなければならない。これにより、テナントは、制限時間の間に、格納されたデータの使用を許可することができる。
【００８５】
実施形態において、用語のセキュリティコンテキストは、ひとつ以上のセキュリティアプライアンス（例えば、ＨＳＭｓ）または、セキュリティアプライアンスのパーティションを指し、それは少なくともひとつのプライベートキーを共有し、暗号機能のセットを保護しかつ実行するように構成されている。
【００８６】
本明細書において、用語の暗号キーは、暗号オペレーションで使用するための暗号材料のブロックを指す。キーに対応するアクセスコントロールリストは、オペレーションを記述するパーミッションのセットに関連する情報を有し、キー材料は、例えば、暗号、解読、またはストレージのために使用され、かつ、パーミッションをイネーブルにするために与えられるべき任意のクレデンシャルである。またキーに関連するのは、キーのタイプを同定するデータを有するキータイプに関連する情報、例えば、２５６ビットの長さのキーを有するAdvanced  Encryption  Standard  (AES)アルゴリズム、または、２０４８ビットの長さのキーを有するＲＳＡアルゴリズムのような使用可能なアルゴリズムを同定する情報を含む。
【００８７】
本明細書において、用語の“検証”は、暗号サインのチェック方法を言及するのに使用される。用語の“認証”は、データが予想どおりであることをチェックする方法、または、サインが正しいことおよびデータが予想通りであることの両方をチェックする方法を言及するのに使用される。
【００８８】
本明細書において、用語のアクセスコントロールリストは、オブジェクトに添付されたひとつ以上のパーミションを指す。パーミションは、オブジェクトに対してどのオペレーションが許可されたか、および、許可されるべきオペレーションに要求される条件および／またはクレデンシャルを特定する。本明細書に記載された方法において、パブリックキーは第１セキュリティコンテキストまたは第２セキュリティコンテキスト内に格納されてよく、または、パブリックキーが、例えば第１セキュリティコンテキストまたは第２セキュリティコンテキストの識別キーによってサインされ、保護されたインテグリティであれば、第１のセキュリティコンテキストまたは第２のセキュリティコンテキストの外部の不信用媒体上に格納されてよい。これは、パブリックキーが改ざんされれば、それが検出されることを意味する。
【００８９】
本明細書に記載された方法において、第１セキュリティコンテキストおよび第２セキュリティコンテキストの間で送信される情報は、暗号サーティフィケートの使用によって認証されてよい。例えば、情報は、送り手に帰属するプライベートサインキー、および、レシーバへ情報と一緒に送られるサインによってサインされてよい。
【００９０】
本明細書に記載された方法は、コンピュータにより実行可能な方法であってよい。
【００９１】
実施形態に従ういくつかの方法は、ソフトウエアによって実行されるために、いくつかの実施形態は、任意の適当なキャリア媒体上で汎用コンピュータに与えられるコンピュータコードを包含する。キャリア媒体は、フロッピーディスク、ＣＤ−ＲＯＭ、磁気デバイスまたはプログラム可能なメモリデバイスのような非一過性記憶媒体、または、電気的、光学的またはマイクロ波信号などの任意の信号のような一過性媒体を有する。
【００９２】
非限定的な実施形態に従うデバイスおよび方法は、添付する図面を参照して詳細に説明される。
【図面の簡単な説明】
【００９３】
【図１Ａ】図１Ａは、本願発明の実施形態に従う暗号デバイスを有するテナントシステムと、本願発明の実施形態に従う暗号デバイスを有するサービスプロバイダーを備えるネットワークの略示図である。
【図１Ｂ】図１Ｂは、本願発明の実施形態に従う第１セキュリティコンテキストおよび本願発明の実施形態に従う第２セキュリティコンテキストの略示図である。
【図２Ａ】図２Ａは、本願発明の実施形態に従う暗号キー転送方法の一部である、第１セキュリティコンテキストと第２セキュリティコンテキストとの間に信用を確立する方法を示すフローチャートである。
【図２Ｂ】図２Ｂは、本願発明の実施形態に従う暗号キー転送方法の一部である、第１セキュリティコンテキストにおいて第２セキュリティコンテキストのコンフィギュレーションを認証する方法を示すフローチャートである。
【図３】図３は、信用が確立された後で、各セキュリティコンテキスト内に関連するキーが生成された後の、本願発明の実施形態に従う第１セキュリティコンテキスト、および、本願発明の実施形態に従う第２セキュリティコンテキストの略示図である。
【図４Ａ】図４Ａは、本願発明の実施形態に従う暗号キー転送方法の一部である、第１セキュリティコンテキストから第２セキュリティコンテキストへサインキーＫｔｅｎａｎｔ−ｓｉｇｎを転送する方法を示すフローチャートである。
【図４Ｂ】図４Ｂは、本願発明の実施形態に従う暗号キー転送方法の一部である、テナント登録方法を示す図である。
【図５】図５は、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂがデータ転送処理中に交換された後の、本願発明の実施形態に従う、第１セキュリティコンテキストおよび本願発明の実施形態に従う第２セキュリティコンテキストの略示図である。
【図６Ａ】図６Ａは、本願発明の実施形態に従う第１セキュリティコンテキストから第２セキュリティコンテキストへのデータ転送方法を示すフローチャートである。
【図６Ｂ】図６Ｂは、本願発明の実施形態に従う、第１セキュリティコンテキストから第２セキュリティコンテキストへのデータ転送方法のさらなるステップを示すフローチャートである。
【図７Ａ】図７Ａは、本願発明の実施形態に従う暗号キー転送方法の一部である、キー登録方法を示す図である。
【図７Ｂ】図７Ｂは、本願発明の実施形態に従う暗号キー転送方法のフローチャートである。
【図８Ａ】図８Ａは、転送キーＫｔｅｎａｎｔが第２セキュリティコンテキストにインポートされた後の、本願発明の実施形態に従う第１セキュリティコンテキスト、および本願発明の実施形態に従う第２セキュリティコンテキストの略示図である。
【図８Ｂ】図８Ｂは、サービスプロバイダー、テナントまたは別のサードパーティーによってホストされる時間ソースの略示図である。
【図９】図９は、第２セキュリティコンテキストを有する時間ソースを登録する方法を示すフローチャートである。
【図１０】図１０は、第１セキュリティコンテキストにより時間ソースを登録する方法を示すフローチャートである。
【図１１】図１１は、本願発明の実施形態に従うデータの使用をコントロールする方法を示すフローチャートである。
【図１２】図１２は、本願発明の実施形態に従う暗号キーＫｔｅｎａｎｔの使用をコントロールする方法の一部である、第１セキュリティコンテキストにおいて、使用サーティフィケートを生成する方法を示すフローチャートである。
【図１３】図１３は、本願発明の実施形態に従う暗号キーＫｔｅｎａｎｔの使用をコントロールする方法を示す図である。
【図１４】図１４は、本願発明の実施形態に従う暗号キーＫｔｅｎａｎｔの使用をコントロールする方法のフローチャートである。
【発明を実施するための形態】
【００９４】
図１Ａは、本願発明の実施形態に従う暗号デバイスを有するテナントシステム１、および本願発明の他の実施形態に従う暗号デバイスを有するサービスプロバイダーシステム３の略示図である。
【００９５】
サービスプロバイダーは、例えばクラウドサービスプロバイダーであってよい。サービスプロバイダーは、ひとつ以上のテナントに対して、暗号キーのようなデータのストレージおよびデータの安全な暗号処理を提供する。例えば、テナントは、支払い、セキュリティおよびレギュレーションなどのアプリケーションに対して、サービスプロバイダーシステム３の暗号インフラストラクチャーを使用する。サービスプロバイダーシステム３は、それらのひとつ以上のアプリケーションを実行するように構成されたサービスプロバイダーアプリケーションサーバーを有する。
【００９６】
これらのサービスを使用するために、テナントシステム１は、サービスプロバイダーシステム３に対して暗号キーＫｔｅｎａｎｔを提供する。暗号キーＫｔｅｎａｎｔはそれらのアプリケーションで使用するために、サービスプロバイダーシステム３において安全に格納される。
【００９７】
テナントシステム１は第１セキュリティコンテキスト５を有し、サービスプロバイダーシステム３は第２セキュリティコンテキスト７を有する。セキュリティコンテキストは、例えば、ハードウエアセキュリティモジュール、ＨＳＭなどの単一のセキュリティデバイスであってよい。代替的に、それは、２つ以上のセキュリティデバイス、またはセキュリティデバイスのパーティションであってもよい。ここで使用する用語のセキュリティコンテキストは、単一のセキュリティコンテキストを形成するデバイス、複数デバイス、またはデバイスのパーティションを指す。それは、少なくともひとつのプライベートキーを共有し、かつ、暗号機能のセットを保護しかつ実行するように構成されている。第１セキュリティコンテキスト５は、残りのテナントシステムから保護される。第２セキュリティコンテキスト７は残りのサービスプロバイダーシステムから保護される。
【００９８】
テナント暗号キーＫｔｅｎａｎｔは、サービスプロバイダーシステム３において第２のセキュリティコンテキスト７に与えられる。テナント暗号キーＫｔｅｎａｎｔはその後、第２セキュリティコンテキスト７内に格納されるか、または、サービスプロバイダーシステム３のどこか他の場所に格納される前に第２セキュリティコンテキストを離れることができないキーによって暗号化される。
【００９９】
暗号キーＫｔｅｎａｎｔを第２セキュリティコンテキスト７に提供する前に、テナントは、第２セキュリティコンテキスト７によって与えられた生成サーティフィケートから第２セキュリティコンテキスト７を確認および認証する。生成サーティフィケートは、例えば第２セキュリティコンテキスト７の一部であるデバイスまたは複数デバイスの製造の時に生成されたものであってよい。テナントは製造業者を信用するがサーティフィケートを信用しない。生成サーティフィケートは、第２セキュリティコンテキスト７が信用された製造業者によって製造されたことを確認し、そうして信用される。また、第２セキュリティコンテキスト７のパラメータおよび状態は、例えば、生成サーティフィケート内、および、他のコンフィギュレーションサーティフィケート内に含まれる情報から認証される。
【０１００】
生成サーティフィケートは、アプライアンスの全寿命の間に有効である静的情報を有する。コンフィギュレーションサーティフィケートは、デバイスのカレントのコンフィギュレーションに関する情報を有する。コンフィギュレーション情報は、コンフィギュレーションサーティフィケートの生成の時間においてのみ有効であり、後の格納時において変化する。
【０１０１】
したがって第１セキュリティコンテキスト５は、キー転送オペレーションが始まる前に、第２セキュリティコンテキストによって信用を確立する。
【０１０２】
テナント暗号キーＫｔｅｎａｎｔは、第２セキュリティコンテキスト７へ転送される前に、第２セキュリティコンテキスト７において生成された非対称キーペアのパブリックハーフによって暗号化される。第１暗号サーティフィケートは、第２セキュリティコンテキスト７において生成された非線形キーペアとともに発行される。実施形態において、第１セキュリティサーティフィケートは、非線形キーペアが第２セキュリティコンテキスト７内で生成されたこと、非線形キーペアのプライベートハーフが一時的なものであること、および、非線形キーペアのプライベートハーフが第２セキュリティコンテキスト７を離れることができないことを認証する。これにより、テナント暗号キーＫｔｅｎａｎｔは、攻撃から保護され、サービスプロバイダー自身、すなわち、例えばアプリケーションサーバーのような第２セキュリティコンテキスト７の外部にある残りのサービスプロバイダーシステム３から保護されるような方法で、サービスプロバイダーシステム３に転送されることができる。
【０１０３】
実施形態において、テナント暗号キーＫｔｅｎａｎｔは、その後第２セキュリティコンテキスト７内に格納される。代替的に、テナント暗号キーＫｔｅｎａｎｔは、例えばアプリケーションサーバー内のようなサービスプロバイダーシステムの他のどこかに格納され、第２セキュリティコンテキスト７を離れることができないキーによって暗号化される。
【０１０４】
テナント暗号キーＫｔｅｎａｎｔに対応するアクセスコントロールリスト（ＡＣＬ）がまた、第１セキュリティコンテキスト５内でテナント暗号キーＫｔｅｎａｎｔによって生成される。ＡＣＬはまた、テナント暗号キーＫｔｅｎａｎｔとともに第２セキュリティコンテキスト７に転送される。ＡＣＬは、テナント暗号キーＫｔｅｎａｎｔとともに格納される。第１セキュリティコンテキスト５は、第２セキュリティコンテキスト７により信用を確立し、それにより、第２セキュリティコンテキスト７がＡＣＬ内に含まれるポリシーを行使することを知る。したがってＡＣＬにより、テナントは、キーが第２セキュリティコンテキスト７に一旦転送されたとしても、キーに対するコントロールを維持することができる。
【０１０５】
実施形態において、ＡＣＬは、テナント暗号キーＫｔｅｎａｎｔが第２セキュリティコンテキスト７内にのみ格納されることを特定する。代替的実施形態において、ＡＣＬは、第２セキュリティコンテキスト７を離れることができないキーによって格納のために暗号化される条件のもとでのみ、テナント暗号キーＫｔｅｎａｎｔが格納されることの制限を含む。これは、テナント暗号キーＫｔｅｎａｎｔがサードパーティーおよびサービスプロバイダーにアクセス不能であることを保証する。
【０１０６】
ＡＣＬは、テナント暗号キーＫｔｅｎａｎｔが、サードパーティーによる改ざんに対抗できる不揮発性メモリ内にのみ格納されることを特定する。
【０１０７】
また、ＡＣＬは、認証が、例えば使用サーティフィケートのようなクレデンシャルを使用すること、および、テナント暗号キーＫｔｅｎａｎｔの使用のひとつ以上のタイプを許可するために与えられなければならないことを特定する。例えば、ＡＣＬは、テナントキーＫｔｅｎａｎｔを使ってある暗号オペレーションのパフォーマンスを許可するためにテナントによって所有される非対称キーのプライベートハーフによってサインされたサーティフィケートのプレゼンテーションを要求してよい。これは、テナントによって許可されなければ、キーを使ったオペレーションの特定のタイプが使用できないことを保証する。
【０１０８】
テナント暗号キーＫｔｅｎａｎｔはサービスプロバイダーシステム内に格納されるが、サービスプロバイダー、すなわち、第２セキュリティコンテキスト７の外部にある残りのサービスプロバイダーシステム３は、キーにアクセス不能であり、キーはテナントからの許可無しで使用不可能である。これにより、テナント暗号キーＫｔｅｎａｎｔを悪意あるサービスプロバイダーから保護する。また、それは、サービスプロバイダーに対して裁判管轄を有するがテナントに対して有しないセキュリティエージェンシーからテナント暗号キーＫｔｅｎａｎｔを保護する。
【０１０９】
またそれにより、複数のテナントが、サービスプロバイダー内の同じ暗号インフラストラクチャーを使用することができる。複数のテナントは、各テナント暗号キーＫｔｅｎａｎｔが他のテナントにアクセス不能なように、同じ暗号デバイス内にキーを格納することができ、対応するテナントからの許可無しで使用することができない。
【０１１０】
アクセスコントロールリストは、使用クレデンシャルが、使用クレデンシャルの満期を決定可能な情報を有し、かつ、暗号キーＫｔｅｎａｎｔの使用を許可するために満了前であることを特定する。したがってテナントは、使用クレデンシャル内でキーの満了時間を特定することができ、その後は他の許可が与えられるまでキーが使用されない。
【０１１１】
満了時間は、第１セキュリティコンテキストおよび第２セキュリティコンテキスト７の両方によって信用される基準時間ソース２を参照して計算される。基準時間ソース２は、サービスプロバイダー、テナント、または、別のサードパーティーによりホストされてよい。図１Ａは、基準時間ソース２がサードパーティーによりホストされるところの実施形態の略示図である。
【０１１２】
上記説明は、テナント暗号キーの転送および格納に関連するものであるが、任意の形式のデータが同じ方法で転送および格納可能である。テナントからサービスプロバイダーへのデータ転送の方法は、サービスプロバイダーシステム内でセキュアデバイスによって生成されたパブリックキーのキーペアによってデータを暗号化する工程を有する。したがって、データは転送中にサービスプロバイダーによってアクセス不能である。データの信頼性およびインテグリティを保証するために、暗号データは、転送前に暗号化サインされる。
【０１１３】
データは、対応するアクセスコントロールリストとともに生成され、それは、一度格納されたデータの特定の使用を許可するために有効なサーティフィケートが与えられなければならないことを特定する。したがってテナントは、テナントシステムの外部に転送されたとしてもデータの使用のコントロールを維持することができる。
【０１１４】
サービスプロバイダーシステム内に安全に格納されたデータの使用をコントロールする方法は、データの使用をリクエストするパーティーに対して、満了時間を有する使用クレデンシャルを発行する工程を有する。使用クレデンシャルは、格納済みデータの使用が許可される前に認証されなければならない。これにより、テナントは、制限された時間間隔の間に格納されたデータの使用を許可することが可能となる。
【０１１５】
図１Ｂは、本願発明の実施形態に従う第１セキュリティコンテキスト５および本願発明の他の実施形態に従う第２セキュリティコンテキスト７の略示図である。
【０１１６】
第１セキュリティコンテキスト５は、例えば、ハードウエアセキュリティモジュール、ＨＳＭのような単一のセキュリティアプライアンスであってよい。代替的に、第１セキュリティコンテキスト５は、２つ以上のセキュリティアプライアンス、または、セキュリティアプライアンスのパーティションであってもよい。第１セキュリティコンテキスト５は例えば、低電力、低性能、低コストのＨＳＭである。
【０１１７】
第２セキュリティコンテキスト７は、例えば、ハードウエアセキュリティモジュールなどの単一のセキュリティアプライアンスであってよい。代替的に、第２セキュリティコンテキスト７は、２つ以上のセキュリティアプライアンス、または、セキュリティアプライアンスのパーティションであってよい。第２セキュリティコンテキスト７は、高性能ＨＳＭのクラスタを有してよい。
【０１１８】
したがって第１セキュリティコンテキスト５および第２セキュリティコンテキスト７の各々は、ひとつ以上の改ざん対抗暗号アプライアンスまたは改ざん対抗暗号アプライアンスのパーティションであってよい。
【０１１９】
第１セキュリティコンテキスト５は、第１デバイスメモリ９を有する。第１デバイスメモリ９は、キー、キーペアおよびサーティフィケートのような暗号情報を格納するように構成されている。第１デバイスメモリ９は、例えばフラッシュ、光学ディスクまたは磁気ハードドライブなどの任意の形式の不揮発性メモリデバイスを含む。第１セキュリティコンテキスト５はまた、揮発性メモリを有する。
【０１２０】
第１デバイスメモリ９は、例えば、下層の物理的ハードウエアを破壊することなく除去不可能であり、それにより使用不能となるデバイス全体をカバーする薄膜などの物理的セキュリティを含むことにより、物理的に安全であり、かつ、サードパーティーによる改ざんに対抗することができる。
【０１２１】
ユニークな非対称識別キーＫ１ＩＤが、対応するサイン済みの生成サーティフィケート｛Ｃ１ＩＤ｝Ｋｍａｎ  ｐｒｉｖとともに、第１デバイスメモリ９内に格納される。生成サーティフィケートＣ１ＩＤは、例えばキーのパブリックパラメータを記述し、生成サーティフィケートＣ１ＩＤはキーのタイプおよびその長さに関連する情報を含む。生成サーティフィケートＣ１ＩＤは、識別キーＫ１ＩＤが第１セキュリティコンテキスト５内で生成されたことを証明する情報を有する。例えば、生成サーティフィケートＣ１ＩＤは、Ｋ１ＩＤのパブリックハーフのハッシュを有し、製造業者の非線形キーＫｍａｎ  ｐｒｉｖのプライベートハーフによってサインされる。
【０１２２】
生成サーティフィケートＣ１ＩＤはまた、状態情報、例えば、デバイスのユニークな識別に関連する情報、製造業者を同定する情報、使用されるハードウエアバージョン、使用されるソフトウエアのタイプ、ユニットのシリアル番号、およびモデルのサポート特徴／機能を含んでよい。生成サーティフィケートＣ１ＩＤは、第１セキュリティコンテキスト５および第２セキュリティコンテキスト７の両方によって信用される製造業者によりサインされる。生成サーティフィケートは、製造業者非対称キーＫｍａｎ  ｐｒｉｖのプライベートハーフによって暗号化サインされる。製造業者は、第１セキュリティコンテキストを形成するセキュリティアプライアンス、および第２セキュリティコンテキストを形成するセキュリティアプライアンスを製造したサードパーティーであってもよい。信用された製造業者キーのパブリックハーフＫｍａｎ  ｐｕｂもまた第１デバイスメモリ９内に格納されるか、またはインテグリティ保護される方法で第１セキュリティコンテキスト５の外部に格納されてよい。
【０１２３】
第２セキュリティコンテキスト７は、第２デバイスメモリ１１を有する。第２デバイスメモリ１１は、キー、キーペアおよびサーティフィケートのような暗号情報を格納するように構成されている。第２デバイスメモリ１１は、フラッシュ、光学ディスクまたは磁気ハードドライブなどの任意の形式の不揮発性デバイスメモリを含む。第２セキュリティコンテキスト５はまた揮発性メモリを含む。
【０１２４】
デバイスメモリは、例えば、下層の物理的ハードウエアを破壊することなく除去不可能であり、それにより使用不能となるデバイス全体をカバーする薄膜などの物理的セキュリティを含むことにより、物理的に安全であり、かつ、サードパーティーによる改ざんに対抗することができる。
【０１２５】
ユニークな非対称識別キーＫ２ＩＤは、対応するサイン済みの生成サーティフィケート｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖとともに、第２デバイスメモリ内に格納される。Ｋ２ＩＤは、データの起源および信頼性を証明するために使用されるサインキーである。生成サーティフィケートＣ２ＩＤは、例えばキーのパブリックパラメータを記述し、生成サーティフィケートＣ２ＩＤはキーのタイプおよび長さに関連する情報を含んでよい。生成サーティフィケートＣ２ＩＤは、識別キーＫ２ＩＤが第２セキュリティコンテキスト７内に生成されたことを証明する情報を有する。例えば、生成サーティフィケートＣ２ＩＤはＫ２ＩＤのパブリックハーフのハッシュを含み、製造業者非対称キーＫｍａｎ  ｐｒｉｖのプライベートハーフによってサインされてよい。
【０１２６】
生成サーティフィケートＣ２ＩＤは、状態情報、例えば、デバイスのユニークな識別に関連する情報、製造業者を同定する情報、ハードウエアバージョン、使用されるソフトウエアのタイプ、ユニットのシリアル番号、および、モデルのサポート特徴／機能を有する。生成サーティフィケートＣ２ＩＤは、信用された製造業者によってサインされる。生成サーティフィケート製造業者非対称キーのプライベートハーフＫｍａｎ  ｐｒｉｖによって暗号化サインされる。信用された製造業者キーのパブリックハーフＫｍａｎ  ｐｕｂもまた第２デバイスメモリ１１内に格納されるか、または、インテグリティ保護される方法で第２セキュリティコンテキスト７の外部に格納されてよい。
【０１２７】
第１セキュリティコンテキスト５および第２セキュリティコンテキスト７の両方において、暗号キーは安全な、改ざん防止フォーマットで、デバイスメモリ内に格納される。
【０１２８】
第１セキュリティコンテキスト５および第２セキュリティコンテキスト７は、暗号サーティフィケート、製造時に生成されるサイン済み生成サーティフィケート｛Ｃ１ＩＤ｝Ｋｍａｎ  ｐｒｉｖおよび｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖを使って検証可能に同定される。したがって、各々は偽造不可能なことを意味する方法でそれらのアイデンティティを安全に格納することができる。第１セキュリティコンテキスト５および第２セキュリティコンテキスト７を識別することは、確認されるべき各セキュリティコンテキスト内のデバイスまたは複数のデバイスの起源を与える。各デバイスは、例えばその製造時に工場内で生成されたユニークな非対称識別キーＫＩＤを含む。各コンポーネントはまたは、製造業者にのみ知られた非対称キーを使ってサインされたＫＩＤ用のキー生成サーティフィケートを含む。製造業者キーのパブリックハーフは本物のアプライアンスであることを証明する信用のルートとして使用される。
【０１２９】
また、第１セキュリティコンテキストおよび第２セキュリティコントラストのパラメータおよび状態は、生成サーティフィケート内に含まれる情報から、さらなるコンフィギュレーション、サーティフィケートの交換を通じて、拒否不能な方法で認証される。
【０１３０】
実施形態において、第１セキュリティコンテキスト５および第２セキュリティコンテキスト７は、テナントおよびサービスプロバイダーによって設定されたデバイスのカレントのコンフィギュレーションに関する情報を含む、コンフィギュレーションサーティフィケートＣ１ＶおよびＣ２Ｖをそれぞれ生成するように構成される。コンフィギュレーション情報は、デバイスがテナントおよびサービスプロバイダーに分配されて構成される前に、製造時において生成されるので、生成サービスプロバイダー内には含まれ得ない。
【０１３１】
したがって、生成サーティフィケートが交換され、２つのセキュリティコンテキスト間で信用が形成されたら、ダイナミックなコンフィギュレーションに関連する他の情報がさらにサインされたサーティフィケートデータ転送を通じて交換される。コンフィギュレーションサーティフィケートＣ１ＶおよびＣ２Ｖはそれぞれ、対応するセキュリティコンテキストのユニークな非対称識別キーのプライベートハーフによってサインされる。コンフィギュレーションサーティフィケートは、現在ＫＩＤｐｒｉｖが他のセキュリティコンテキストによって信用されているとして、信頼性を検証するためにＫＩＤｐｒｉｖによってサインされる。コンフィギュレーションサーティフィケート内に含まれるデータは、セキュリティ設定、ソフトウエアのバージョン、どの信用された時間ソースが使用されているか、または、ＨＳＭが改ざんの試みが為されたと考えるか否かなどの管理者展開オプションに関連する。
【０１３２】
サービスの起源および状態は、他のサービスがそれらに信用を置くことができる十分な情報を定義する。
【０１３３】
第２のセキュリティコンテキストは、第２セキュリティコンテキストに与えられたＡＣＬ内で特定されたルールを行使するよう信用され、かつ、その状態サーティフィケートを正確にアップデートするよう信用される。実施形態において、第２セキュリティコンテキストがＡＣＬ内に含まれる特定レベルにルールを行使することができない場合には、それはオペレーションを実行せず、自分自身またはキーがルールをサポートするように作成されたことを公言しない。
【０１３４】
第１および第２セキュリティコンテキストの識別キーは、製造時にインストールされ、これらのキーのハッシュが製造業者キーＫｍａｎ  ｐｒｉｖによってサインされ、かつ、識別キーとともに格納され、よってその起源を証明する。
【０１３５】
信用されたソースからのサービスを暗号的に識別できることにより、テナントは、すべてのデータが保護され、かつ、ホスティングサービスプロバイダーを含む任意のサードパーティーによって回復不能であることの高い保証によって、通信チャネルを通じて、その暗号キーをホストサービスと交換することができる。生成サーティフィケートから、第２セキュリティコンテキスト７内のサービスプロバイダーのアプライアンスが信用されたことを確認することにより、および、コンフィギュレーションサーティフィケートから、そのコンフィギュレーションがテナントのセキュリティポリシーに一致することを確認することにより、テナントはキーが特定された方法で格納されていることを知ってそのキーを転送することができる。キーとともに送られたＡＣＬは、キーがどのように格納されかつ使用されるかを特定するポリシーを含む。第２セキュリティコンテキスト７はその後、当ポリシーを行使する。テナントは、第２セキュリティコンテキスト７に対して信用を確立したとして第２セキュリティコンテキスト７がポリシーを行使することを信用することができる。信用の確立により安全な転送が可能となり、ＡＣＬにより第２セキュリティコンテキスト７はキーを所有しているときにポリシーを適用することができる。
【０１３６】
第１セキュリティコンテキスト５はさらにトランシーバ１３を有する。トランシーバ１３はデータパケットを送信および受信するように構成されている。データパケットは、例えば、第１セキュリティコンテキスト５および第２セキュリティコンテキスト７との間のインターネット接続または直接的な有線接続を介して、第１トランシーバ１３において送受信される。この通信リンクは信用されないが、以下で図６Ａに関連して説明するキー転送プロトコルは攻撃からキーの保護を与える。
【０１３７】
第１セキュリティコンテキスト５はさらに、第１プロセッサ１７を有する。第１プロセッサ１７は、暗号キーおよび非対称暗号キーペアの生成、暗号キーおよび非対称暗号キーペアに対応するサーティフィケートの生成、暗号キーに対応するアクセスコントロールリストの生成、暗号キーに対応する使用サーティフィケートの生成、第１デバイスメモリ９内に格納された暗号キーによるオブジェクトの暗号化、第１デバイスメモリ９内に格納された暗号キーによる暗号オブジェクトの解読、第１デバイスメモリ９内に格納された暗号キーによるオブジェクトの暗号化サイン、第１デバイスメモリ９内に格納された情報に基づく暗号サインの検証およびオブジェクトの認証などの暗号オペレーションを実行するように構成されている。第１プロセッサ１７は物理的に安全である。
【０１３８】
実施形態において、第１セキュリティコンテキスト５は非暗号オペレーションを実行するためのメインプロセッサを有し、第１プロセッサ１７はコプロセッサである。すなわち、メインプロセッサとは別のコンポーネントが暗号オペレーションのみを実行するように構成されている。代替的に、第１プロセッサ１７はメインプロセッサであってもよい。
【０１３９】
暗号キーおよび非対称暗号キーペアの生成は、乱数の生成を含む。第１セキュリティコンテキスト５はさらに、乱数生成で使用するために、ランダムエントロピーソースを有する。
【０１４０】
第２セキュリティコンテキスト７はさらにトランシーバ１５を有する。第２トランシーバ１５はデータパケットを送信および受信するように構成されている。データパケットは、例えば、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間のワイヤレスインターネット接続または直接的な有線接続を介して、第２トランシーバ１５において送受信される。
【０１４１】
第２セキュリティコンテキスト７はさらに第２プロセッサ１９を有する。第２プロセッサ１９は、暗号キーおよび非線形暗号キーペアの生成、暗号キーまたは非線形暗号キーペアに対応するサーティフィケートの生成、暗号キーに対応するアクセスコントロールリストの生成、暗号キーに対応する使用サーティフィケートの生成、第２デバイスメモリ１１に格納された暗号キーによるオブジェクトの暗号化、第２デバイスメモリ１１内に格納された暗号キーによる暗号化オブジェクトの解読、第２デバイスメモリ１１内に格納された暗号キーによるオブジェクトの暗号化サイン、第２デバイスメモリ１１内に格納された情報に基づく暗号サインの検証およびオブジェクトの認証などの暗号オペレーションを実行するように構成されている。第２プロセッサ１９は物理的に安全である。
【０１４２】
実施形態において、第１セキュリティコンテキスト５は非暗号オペレーションを実行するメインプロセッサを有し、第１プロセッサ１７はコプロセッサである。すなわち、メインプロセッサとは別のコンポーネントが暗号オペレーションのみを実行するように構成されている。代替的に、第１プロセッサ１７はメインプロセッサであってもよい。
【０１４３】
暗号キーおよび非線形暗号キーペアの生成は、乱数の生成を含む。第２セキュリティコンテキスト７はさらに、乱数生成に使用するためのランダムエントロピーソースを有する。
【０１４４】
第１セキュリティコンテキスト５または第２セキュリティコンテキスト７の一部として使用可能なＨＳＭデバイスは、デバイスメモリ、プロセッサ、トランシーバおよび上記したランダムエントロピーソースを有する。ＨＳＭは、物理的および非物理的に安全な性質を有する。非物理的に安全な性質は、暗号の使用を含む。すなわち、格納データの暗号化を実行するように構成されたソフトウエアまたは物理的コンポーネントがデバイス内に含まれる。物理的性質は、物理的アクセスによってトリガーされる改ざんスイッチ、およびデバイスの物理的境界を包囲する改ざん防止薄膜を有する。
【０１４５】
本明細書において議論する暗号非対称キーペアは、サインおよび検証をサポートする任意の非対称キーペアタイプであってよい。例えば、製造者キーペアＫｍａｎ、第１識別キーＫ１ＩＤ、第２識別キーペアＫ２ＩＤ、時間ソース識別キーペアＫＴＳＩＤ、およびサインキーペアＫｔｅｎａｎｔ−ｓｉｇｎの各々は、例えば、ＲＳＡ、ＤＳＡ、またはＥＣＤＳＡキーペアのいずれかであってよい。ここで、ＲＳＡまたはＤＳＡは、サインおよび認証用のアルゴリズムである。
【０１４６】
例えば、ＲＳＡキーペアを生成するために、生成オペレーションが、データをサインするためにＲＳＡアルゴリズムによって使用可能なアウトプットキーペアを生成するべく、第１プロセッサ１７、第２プロセッサ１９、または第３プロセッサ４１によって実行されてよい。
【０１４７】
ランダムエントロピーソースは、乱数を生成するのに使用されてよく、それは順に、暗号キーおよび暗号キーペアを生成するべく、第１プロセッサ１７、第２プロセッサ１９、または第３プロセッサ４１によって使用される。
【０１４８】
本明細書における暗号非線形キーペアは、暗号化および解読をサポートする任意の非対称暗号キーペアであってよい。例えば、第１暗号キーペアＫＢＬＯＢは、ＲＳＡキーペアまたは統合暗号化スキーム（ＩＥＳ）アルゴリズムで使用可能なキーペアであってよい。
【０１４９】
以下で説明される第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の暗号サーティフィケートおよび暗号キーの転送は、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の安全な認証されたチャネルを通じて生じ、それは、サービスプロバイダーによって与えられかつ制御される。サービスプロバイダーによって提供される安全チャネルは、ロードバランサまたはファイアウォールアプライアンスを使って与えられる。このインフラストラクチャーの使用は、サービス拒否のような攻撃を緩和する。
【０１５０】
チャネルはサードパーティーからは安全であるが、サービスプロバイダーによる攻撃に対してオープンである。したがって、高価値の暗号キーの転送に対してテナントによって信用されない。したがって、セキュリティは、Ｋｔｅｎａｎｔの暗号化および後続のチャネルを通じて送られる暗号化データのサインによってテナントにより行使される。
【０１５１】
図２Ａは、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間で信用を確立する方法を示すフローチャートである。信用を確立する方法は、本願発明の実施形態に従う暗号キー転送方法の一部である。信用を確立する方法は、例えば暗号キーＫｔｅｎａｎｔが生成される前に実行されてよく、または、暗号キーが生成された後であって、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間で暗号キーを交換する前に実行されてもよい。
【０１５２】
ステップＳ２１０において、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂおよび生成サーティフィケート｛Ｃ１ＩＤ｝Ｋｍａｎ  ｐｒｉｖが、第１セキュリティコンテキスト５から第２セキュリティコンテキスト７へ送信される。第１安全コンテキスト５内のトランシーバ１３は、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂおよび生成サーティフィケート｛Ｃ１ＩＤ｝Ｋｍａｎ  ｐｒｉｖを、第２セキュリティコンテキスト内の第２トランシーバ１５に送信するように構成されている。第１セキュリティコンテキスト５内のデバイスの状態に関連する情報は、同じメッセージ内で送信されてよい。デバイスの状態に関連する情報は、この場合生成サーティフィケート内にも含まれ、メッセージ内に含まれる状態情報を認証するべくレシーバによって使用される。
【０１５３】
生成サーティフィケートは変更不能であり、したがって、製造時に入手可能な情報のみを含む。例えば、ＩＰアドレスまたは改ざん状態などのデバイスのカレントコンフィギュレーションに関連する情報は、コンフィギュレーションサーティフィケート内に含まれてよい。コンフィギュレーション情報は、生成サーティフィケートと同時に送信されるか、または、生成サーティフィケートの後に送信されてよい。しかし、生成サーティフィケートは製造時に生成されかつサインされるが、一方でコンフィギュレーションサーティフィケートはキー転送時に生成されかつＫ１ＩＤ−ｐｒｉｖによってサインされる。コンフィギュレーションサーティフィケートは、生成サーティフィケートが検証された後にのみ検証可能である。
【０１５４】
ステップＳ２０２において、生成サーティフィケート｛Ｃ１ＩＤ｝Ｋｍａｎ  ｐｒｉｖのサインは、第２セキュリティコンテキスト７において検証される。第２セキュリティコンテキスト７内の第２プロセッサ１９は、生成サーティフィケート｛Ｃ１ＩＤ｝Ｋｍａｎ  ｐｒｉｖのサインを検証するように構成されている。生成サーティフィケートは、デバイスメモリ１１内に格納されている信用された製造業者キーのパブリックハーフＫｍａｎ  ｐｕｂを使って検証される。第２プロセッサ１９は、与えられたサイン済みメッセージ｛Ｃ１ＩＤ｝Ｋｍａｎ  ｐｒｉｖおよびパブリックキーＫｍａｎ  ｐｕｂがメッセージの信頼性要求を受け入れるかまたは拒否するサイン検証アルゴリズムを実行するように構成されている。
【０１５５】
第２セキュリティコンテキストの認証キーのパブリックハーフＫ１ＩＤ  ｐｕｂの信頼性は、第２セキュリティコンテキスト７において認証される。第２セキュリティコンテキスト７内の第２プロセッサ１９は、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂを認証するように構成されている。生成サーティフィケートＣ１ＩＤが第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂのハッシュを有する実施形態において、信頼性は、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂのハッシュを計算し、かつ、それが生成サーティフィケートＣ１ＩＤ内に含まれるものと一致することを認証することにより認証される。
【０１５６】
実施形態において、生成サーティフィケートＣ１ＩＤは、Ｋ１ＩＤのパブリックハーフのハッシュを有し、製造業者非対称キーのプライベートハーフＫｍａｎ  ｐｒｉｖによってサインされる。ステップＳ２０２は、Ｋ１ＩＤ  ｐｕｂのハッシュである場合に、メッセージ内で送信された受信データのハッシュを計算する工程と、暗号オペレーションである受信サインを製造業者キーのパブリックハーフとともに検証アルゴリズムに入力し、出力を検証する工程と、計算されたハッシュと検証アルゴリズムの出力に含まれたものとが同一であるか否かを判定するために両者を比較する工程とを有する。
【０１５７】
ステップＳ２０３において、状態情報がメッセージ内に含まれていれば、第２セキュリティコンテキスト７は、デバイスの状態が要求に一致していることを認証する。代替的に、状態情報が生成サーティフィケート内に含まれていなければ、第２セキュリティコンテキスト７は第１セキュリティコンテキスト５の状態を認証しない。第２セキュリティコンテキスト７は、第１セキュリティコンテキスト５へいかなるセキュリティ情報も転送しないので、第１セキュリティコンテキスト５の状態情報は認証される必要がない。
【０１５８】
サインが検証されかつ状態情報が認証されれば、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂは第２セキュリティコンテキスト７の第２デバイスメモリ１１内に格納される。代替的に、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂは第２セキュリティコンテキスト７によってインテグリティ保護され、第２セキュリティコンテキスト７の外部の不信用ストレージ内に格納される。第２セキュリティコンテキスト７は第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂをサインし、かつ、格納用にＫ２ＩＤ  ｐｒｉｖを使って、これが信用されたソースからのパブリックキーであることを示すデータをサインしてよい。代替的に、他の秘密キーを使ってそれを暗号化してもよい。この場合、キーの信用は維持されたまま、しばしば第２セキュリティコンテキスト７内のデバイスメモリよりも大きな容量を有する不信用デバイスメモリを使用できる。
【０１５９】
サインが検証されないか、または、状態情報が認証されなければ、エラーが第１セキュリティコンテキストにリターンされ、例えば“AccessDenied”を記述するメッセージが送られる。この点で、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の通信が終了する。
【０１６０】
ステップＳ２０４において、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂおよび生成サーティフィケート｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖが第２セキュリティコンテキスト７から第１セキュリティコンテキスト５へ送信される。第２セキュリティコンテキスト７内の第２トランシーバ１５は、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂおよび生成サーティフィケート｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖを、第１セキュリティコンテキスト５内の第１トランシーバ１３へ送信するように構成されている。第２セキュリティコンテキスト７内のデバイスの状態に関連する情報は、同じメッセージ内で送られてよい。デバイスの状態に関連する情報は、この場合、状態情報を認証するために生成サーティフィケート内にも含まれる。再び、生成サーティフィケートは変更不能であり、製造時に入手可能な情報のみを含む。例えば、ＩＰアドレスまたは改ざん状態などのデバイスのカレントのコンフィギュレーションに関連する情報は、コンフィギュレーションサーティフィケート内に含まれてよい。コンフィギュレーション情報は、生成サーティフィケートと同時に送信されるか、例えばステップＳ６０４において第１暗号サーティフィケートＣＢＬＯＢの一部として生成サーティフィケートの後に送信される。しかし、生成サーティフィケートは、製造時に生成されかつサインされており、一方、コンフィギュレーションサーティフィケートは、キー転送実施形態に生成され、Ｋ２ＩＤ−ｐｒｉｖによってサインされる。コンフィギュレーションサーティフィケートは、生成サーティフィケートが検証された後にのみ検証可能である。
【０１６１】
ステップＳ２０５において、生成サーティフィケート｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖのサインは第１セキュリティコンテキスト５において検証される。第１セキュリティコンテキスト５内の第１プロセッサ１７は、生成サーティフィケート｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖを検証するように構成されている。サインは、デバイスメモリ９内に格納された信用された製造業者キーのパブリックハーフＫｍａｎ  ｐｕｂを使って検証される。第１プロセッサ１７は、所与のサイン済みメッセージ｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖおよびパブリックキーＫｍａｎ  ｐｒｉｖが信頼性に対するメッセージの要求を受け入れるか拒否する、サイン検証アルゴリズムを実行するように構成されている。これにより、第１セキュリティコンテキスト５は、サインを検証することにより、第２コンテキスト７内の製造業者デバイスを認証することができる。
【０１６２】
第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂの信頼性は、第１セキュリティコンテキスト５において認証される。第１セキュリティコンテキスト５内の第１プロセッサ１７は、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂを認証するように構成されている。実施形態において、生成サーティフィケートＣ２ＩＤは第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂのハッシュを有し、信頼性は、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂのハッシュを計算し、かつ、それが生成サーティフィケートＣ２ＩＤ内に含まれるものと一致することを認証することによって認証される。
【０１６３】
ステップＳ２０６において、状態情報がメッセージ内に含まれれば、第１セキュリティコンテキスト５は、デバイスの状態が要求と一致することを認証する。
【０１６４】
サインが検証され、かつ、状態情報が認証されれば、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂは第１セキュリティコンテキスト５の第１デバイスメモリ９内に格納される。代替的に、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂは、第１セキュリティコンテキスト５によってインテグリティ保護され、かつ、第１セキュリティコンテキスト５の外部の不信用ストレージ内に格納される。第１セキュリティコンテキスト５は、格納用のＫ１ＩＤ  ｐｒｉｖを使って、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂ、および、これが信用済みソースからのパブリックキーであることを示すデータをサインしてよい。代替的に、他の秘密キーを使ってそれを暗号化してもよい。この場合、キーの信頼を維持したまま、しばしば第１セキュリティデバイス５内のデバイスメモリより大きな容量を有する不信用デバイスメモリが使用可能である。
【０１６５】
サインが有効ではないか、または、状態情報が認証されなければ、第２セキュリティコンテキスト７へエラーがリターンされ、例えば、“AccessDenied”を記述するメッセージが送られる。この時点で、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の通信が終了する。
【０１６６】
図２Ａは、第１セキュリティコンテキスト５において第２セキュリティコンテキスト７のコンフィギュレーションを認証する方法を示すフローチャートであり、それは、本願発明の実施形態に従う暗号キー転送方法の一部である。この方法において、第２セキュリティコンテキスト７のコンフィギュレーションが認証可能である。実施形態において、同様の方法が、第２セキュリティコンテキスト７において、第１セキュリティコンテキスト５の構成を認証するために使用される。代替的に、第２セキュリティコンテキスト７は、第１セキュリティコンテキスト５のコンフィギュレーションを認証しない。第２セキュリティコンテキストは、第１セキュリティコンテキストへいかなる安全情報も転送しない。したがって、第１セキュリティコンテキスト５のコンフィギュレーションは認証される必要がない。
【０１６７】
ステップＳ２１１において、コンフィギュレーション情報が第２セキュリティコンテキスト７によって生成される。コンフィギュレーション情報は、管理者によって適用される特定のコンフィギュレーションに関連する情報を含んでよい。これは、サポートされる暗号オペレーション、使用される暗号キー、および／または、ユニットのソフトウエアのバージョンなどに関する情報を含む。コンフィギュレーション情報は、第２セキュリティコンテキスト７内に無い場合に、テナントキーを暗号化するのに第１セキュリティコンテキスト５がＡＥＳアルゴリズムを使用するように構成されたことを示す情報を有してよい。コンフィギュレーション情報はさらに、信用された時間ソースが使用されるか、または、第２セキュリティコンテキスト７がデバイスによる改ざんの試みが為されたと考えるか否かなどのセキュリティ設定の管理者展開オプションに関連する情報を有してよい。
【０１６８】
ステップＳ２１２において、コンフィギュレーション情報は、第２セキュリティコンテキストの識別キーのプライベートハーフＫ２ＩＤ  ｐｒｉｖによってサインされ、コンフィギュレーションサーティフィケートＣ２Ｖを生成する。第２セキュリティコンテキストの識別キーのプライベートハーフＫ２ＩＤ  ｐｒｉｖは第２セキュリティコンテキスト７内に格納され、管理者によってアクセス不能である。コンフィギュレーションサーティフィケートＣ２Ｖを、第２セキュリティコンテキストの識別キーのプライベートハーフによってサインすることは、コンフィギュレーション情報が破壊不能であることを意味する。
【０１６９】
ステップＳ２１３において、コンフィギュレーション情報およびコンフィギュレーションサーティフィケートＣ２Ｖは、第２セキュリティコンテキスト７から第１セキュリティコンテキスト５へ送信される。これは、例えば、ステップＳ２０４において、Ｋ２ＩＤおよび｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖと同時に送信可能である。代替的に、コンフィギュレーション情報は、図６Ａを参照して説明される第１暗号サーティフィケート内に含まれてよく、第１暗号サーティフィケートＣＢＬＯＢと同時に送信されたコンフィギュレーション情報であってもよい。第２セキュリティコンテキスト７内の第２トランシーバ１５は、コンフィギュレーション情報およびコンフィギュレーションサーティフィケートＣ２Ｖを第１セキュリティコンテキスト５内の第１トランシーバ１３へ送信するように構成されている。
【０１７０】
ステップＳ２１４において、サイン済みのコンフィギュレーションサーティフィケートＣ２Ｖは、第１セキュリティコンテキスト５において検証される。第１セキュリティコンテキスト５内の第１プロセッサ１７は、サイン済みのコンフィギュレーションサーティフィケートＣ２Ｖを検証するように構成されている。サイン済みのコンフィギュレーションサーティフィケートＣ２Ｖは、受信されかつステップＳ２０４からＳ２０６で処理された後に、デバイスメモリ９内に格納された第２識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂを使って検証される。第１プロセッサ１７は、所与のサイン済みコンフィギュレーションサーティフィケートＣ２ＶおよびパブリックキーＫ２ＩＤ  ｐｕｂが、信頼性に対するメッセージの要求を受け入れるか拒否するサイン検証アルゴリズムを実行するように構成されている。これにより、第１セキュリティコンテキスト５は、コンフィギュレーション情報が既知のアプライアンスによって生成されたことを証明することができる。
【０１７１】
ステップＳ２１５において、第１セキュリティコンテキストは、コンフィギュレーション情報が要求に一致することを認証する。
【０１７２】
実施形態において、コンフィギュレーション情報は、Ｋｔｅｎａｎｔが第２セキュリティコンテキスト７に転送される直前に、リクエストされかつチェックされる。これは、最新のコンフィギュレーション情報が認証されることを保証する。
【０１７３】
実施形態において、コンフィギュレーション情報およびコンフィギュレーションサーティフィケートもまた、同様の方法で第１セキュリティコンテキスト５によって生成されかつ送信される。コンフィギュレーション情報は、管理者によって適用される特定コンフィギュレーションに関連する情報を有してよい。コンフィギュレーション情報は第１セキュリティコンテキスト５の識別キーのプライベートハーフによってサインされ、かつ、第２セキュリティコンテキスト７に送信される。それは、第１セキュリティコンテキスト５のコンフィギュレーションがその要求に一致することを認証する。
【０１７４】
上述した方法において、テナントは自身をサービスプロバイダーによって登録する。登録は、安全でない媒体を通じた２つのパーティーの相互認証の形式で進められる。第１セキュリティコンテキスト５および第２セキュリティコンテキスト７の相互認証は、ユニークな非対称識別キーを使って実行される。識別キーのパブリックハーフは、それらの一致する生成サーティフィケートとともに交換される。各セキュリティコンテキストは、サーティフィケートが識別キーのパブリックハーフのハッシュを含むこと、および、サーティフィケートが信用された製造業者によって純粋に製造されたことをチェックすることにより、それ以外の生成サーティフィケートを認証する。識別キーの生成サーティフィケートは、ワラントと言及される。確立された信用の共有ルートを使って、第１セキュリティコンテキスト５および第２セキュリティコンテキスト７は、認証可能な信用できるパートナーと安全で認証されたネットワーク通信を確立する。第１セキュリティコンテキスト５および第２セキュリティコンテキスト７は、それ以外が信用された製造業者によって確立されたことを、それぞれ暗号的に認証する。
【０１７５】
第１セキュリティコンテキストにおいてＫｍａｎ  ｐｕｂを使ってサイン済み生成サーティフィケート｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖを検証するステップＳ２０５は、第２セキュリティコンテキスト７が既知の信用できる起源であることを検証する。
【０１７６】
図３は、信用が確立された後であって、かつ、関連キーが各セキュリティコンテキストで生成された後のテナントシステム１およびサービスプロバイダーシステム３である。
【０１７７】
第１セキュリティコンテキスト５内の第１デバイスメモリ９もまた、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂを格納する。代替的に、このキーは、インテグリティ保護される方法で、第１セキュリティコンテキスト５の外部に格納されてよい。第１デバイスメモリ９はまた、以下で説明するステップＳ６０１で生成されるテナントキーＫｔｅｎａｎｔ、および、以下で説明するステップＳ４０１で生成される第２キーペアＫｔｅｎａｎｔ−ｓｉｇｎを格納する。
【０１７８】
第２セキュリティコンテキスト７内の第２デバイスメモリ１１はまた、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂを格納する。代替的に、このキーは、インテグリティ保護される方法で、第１セキュリティコンテキスト５の外部に格納されてもよい。第２デバイスメモリ１はまた、以下で説明するステップＳ６０２で生成される第１暗号キーペアおよび第１暗号サーティフィケートを格納する。
【０１７９】
図４Ａは、第１セキュリティコンテキスト５から第２セキュリティコンテキスト７へ、サインキーＫｔｅｎａｎｔ−ｓｉｇｎを転送する方法を示すフローチャートであり、それは、本願発明の実施形態に従う暗号キー転送方法の一部である。実施形態において、サインキーＫｔｅｎａｎｔ−ｓｉｇｎを転送する方法は、暗号キーＫｔｅｎａｎｔが第２セキュリティコンテキスト７へ送信される前に実行される。サインキーＫｔｅｎａｎｔ−ｓｉｇｎを送信する方法は、暗号キーＫｔｅｎａｎｔが生成された後に実行されてもよい。
【０１８０】
ステップＳ４０１において、非対称暗号キーペアＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖ、および、対応するサーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎが第１セキュリティコンテキスト５内で生成される。非対称暗号キーペアＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖは、第２パブリックキーおよび第２プライベートキーと呼ばれ、対応するサーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎは第２暗号サーティフィケートと呼ばれる。第１セキュリティコンテキスト５内の第１プロセッサ１７は、非対称暗号キーペアＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖ、および対応するサーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎを生成するように構成されている。第２暗号サーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎは、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂのサイン済みハッシュを有してよい。
【０１８１】
ステップＳ４０２において、第２暗号サーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎは、第１セキュリティコンテキストの識別キーのプライベートハーフＫ１ＩＤ  ｐｒｉｖによって暗号化サインされる。第１プロセッサ１７は、第１セキュリティコンテキストの識別キーのプライベートハーフＫ１ＩＤ  ｐｒｉｖにより第２暗号サーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎを暗号化サインするように構成されている。
【０１８２】
したがって、第２暗号サーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎは、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証可能な情報を有する。第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証可能な情報は、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂのサイン済みハッシュを有する。第２暗号サーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎは、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュを有し、かつ、第１セキュリティコンテキストの識別キーのプライベートハーフＫ１ＩＤ  ｐｒｉｖによってサインされ、それにより、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源が認証可能となる。
【０１８３】
ステップＳ４０３において、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよび第２暗号サーティフィケート｛Ｃｔｅｎａｎｔ−ｓｉｇｎ｝Ｋ１ＩＤ  ｐｒｉｖは第２セキュリティコンテント７に送信される。第１トランシーバ１３は、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよび第２暗号サーティフィケート｛Ｃｔｅｎａｎｔ−ｓｉｇｎ｝Ｋ１ＩＤ  ｐｒｉｖを第２セキュリティコンテキスト７へ送信するように構成されている。
【０１８４】
ステップＳ４０４において、第２暗号サーティフィケート｛Ｃｔｅｎａｎｔ−ｓｉｇｎ｝Ｋ１ＩＤ  ｐｒｉｖは、第２セキュリティコンテキスト７において検証される。第２セキュリティコンテキスト７内の第２プロセッサ１９は、第２サーティフィケート｛Ｃｔｅｎａｎｔ−ｓｉｇｎ｝Ｋ１ＩＤ  ｐｒｉｖを検証するように構成されている。第２サーティフィケートは、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂを使って検証される。第２プロセッサ１９は、所与のサイン済みメッセージ｛Ｃｔｅｎａｎｔ−ｓｉｇｎ｝Ｋ１ＩＤ  ｐｒｉｖおよびパブリックキーＫ１ＩＤ  ｐｕｂが、信頼性に対するメッセージの要求を受け入れるかまたは拒否するサイン検証アルゴリズムを実行するように構成されている。
【０１８５】
第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの信頼性は、その後、第２セキュリティコンテキスト７において認証される。第２セキュリティコンテキスト７内の第２プロセッサ１９は、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂを認証するように構成されている。第２暗号サーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎが第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュを有するところの実施形態において、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの信頼性は、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュを計算し、それが第２暗号サーティフィケートＣｔｅｎａｎｔ−ｓｉｇｎ内に含まれるものと一致することを認証することにより、認証される。
【０１８６】
サインが検証され、かつ、第２パブリックキーが認証されれば、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂは第２セキュリティコンテキスト７の第２デバイスメモリ１１内に格納される。代替的に、それは第２セキュリティコンテキスト７によってインテグリティ保護され、第２セキュリティコンテキスト７の外側の不信用ストレージ内に格納されてよい。
【０１８７】
サインが検証されず、または、第２パブリックキーが認証されなければ、第１セキュリティコンテキスト５へエラーがリターンされる。例えば、“AccessDenied”を記述するメッセージが送信される。この時点で、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の通信が終了する。
【０１８８】
上記した方法において、信用の確立に成功すると、第１セキュリティコンテキスト５は、非対称キーＫｔｅｎａｎｔ−ｓｉｇｎを生成し、Ｋ１ＩＤのプライベートハーフによってサインされたサーティフィケートを含むパブリックハーフを第２セキュリティコンテキスト７に送信する。第２セキュリティコンテキスト７は、サーティフィケートを認証し、かつ、Ｋｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフを、後の使用のために安全かつ改ざん防止フォーマットで、第２デバイスメモリ１１または他に格納する。したがって、第１テナントシステム内の第１セキュリティコンテキスト５は、非対称キーＫｔｅｎａｎｔ−ｓｉｇｎを生成し、かつ、格納および後の使用のために、第２セキュリティコンテキストへパブリックハーフを送信する。
【０１８９】
図４Ｂは、テナント登録の方法の略示図である。それは、本願発明の実施形態に従う暗号キー転送方法の一部である。当該方法は、ステップＳ６０１に関連して以下で説明するように、テナント暗号キーＫｔｅｎａｎｔを生成する工程と、図２Ａに関連して上述したように信用を確立する工程と、図４Ａに関連して上述したように第２パブリックキーを生成しかつ交換する工程とを有する。
【０１９０】
図中の垂直方向の各ボックスは、包含されるエンティティーを表し、下方向に時間経過する、第１セキュリティコンテキスト５、第２セキュリティコンテキスト７および時間ソース３を示す。矢印が始まり、ループして終端するブロックは、特定のプロセスの時間間隔を示す。例えば、第２セキュリティコンテキスト７は、第１セキュリティコンテキストの識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂおよび対応する生成サーティフィケートを受信する。これは、第２セキュリティコンテキスト７において処理を開始させる。処理の次のステップは、サーティフィケートを認証し、その後第１セキュリティコンテキスト５に応答を送信することである。応答は、サーティフィケートが認証されなければエラーメッセージ、または、サーティフィケートが認証されればそれ自身のパブリック識別キーおよびサーティフィケートを含むメッセージである。これで特定のプロセスは終了する。
【０１９１】
ループは、例えば、他のエンティティーとの相互作用を必要としない認証のような処理に対して、内部で生じる作用を示す。エンティティー間をまたぐ線は、エンティティー間の通信を示す。
【０１９２】
暗号キーＫｔｅｎａｎｔは、第１セキュリティコンテキスト５内で生成される。第２暗号キーＫｔｅｎａｎｔ−ｓｉｇｎは、その後第１セキュリティコンテキスト５内で生成される。識別キーのパブリックハーフＫ１ＩＤ  ｐｕｂのおよびサインされたサーティフィケート｛Ｃ１ＩＤ｝はその後、第１セキュリティコンテキスト５から第２セキュリティコンテキスト７へ送信され、第２セキュリティコンテキスト７において認証される。識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂおよびサイン済みサーティフィケート｛Ｃ２ＩＤ｝Ｋｍａｎ  ｐｒｉｖはその後、第２セキュリティコンテキスト７から第１セキュリティコンテキスト５へ送信され、第１セキュリティコンテキスト５において認証される。第２暗号キーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびサイン済みサーティフィケート｛Ｃｔｅｎａｎｔ−ｓｉｇｎ｝Ｋ１ＩＤ  ｐｒｉｖは、第２セキュリティコンテキスト７に送られ、そこでそれらが認証されかつ格納される。
【０１９３】
図５は、図６Ａに関連して以下で説明するデータ転送処理中に、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂが交換された後のテナントシステム１およびサービスプロバイダーシステム３の略示図である。
【０１９４】
実施形態において、ＫｂｌｏｂおよびＣｂｌｏｂは一時的であり、Ｋｔｅｎａｎｔが転送されるとすぐに第２セキュリティコンテキスト７から削除される。
【０１９５】
第２セキュリティコンテキスト７内の第２デバイスメモリ１１はまた、第２キーのパブリックハーフＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂを格納する。代替的に、このキーはインテグリティ保護される方法で第１セキュリティコンテキスト５の外部に格納されてもよい。
【０１９６】
図６Ａは、本願発明の実施形態に従う、第１セキュリティコンテキスト５から第２セキュリティコンテキスト７へデータを転送する方法を示すフローチャートである。図６Ａに示す実施形態において、データは、暗号キーＫｔｅｎａｎｔである。
【０１９７】
テナントシステムがサービスプロバイダーシステムとともにそれ自身を登録すると、第１セキュリティコンテキスト５が、安全で、認証された接続を介して、第２セキュリティコンテキスト７と接続し、キー転送、または、インポート、処理を開始する。
【０１９８】
ステップＳ６０１において、暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、ＡＣＬが第１セキュリティコンテキスト５内で生成される。第１セキュリティコンテキスト５内の第１プロセッサ１７は、暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストを生成するように構成されている。
【０１９９】
第１セキュリティコンテキスト５はキーＫｔｅｎａｎｔを生成し、それは、サービスプロバイダーに貸し出している。Ｋｔｅｎａｎｔは、第１セキュリティコンテキスト５内の安全なアプライアンス内においてアクセスコントロールリスト（ＡＣＬ）とともに生成される。
【０２００】
ＡＣＬは、使用サーティフィケートなどの有効使用クレデンシャルがキーの使用の第１のタイプを許可するために与えられなければならないことを特定する。使用の第１のタイプは、例えば、暗号オペレーションであってよい。ＡＣＬは、キーがどのように使用されるか、使用上のあらゆる制限、および、イネーブルにされるべき各オペレーションに対してどのようなクレデンシャルが供給されなければならないかなどを記述する。
【０２０１】
代替的実施形態において、暗号キーＫｔｅｎａｎｔは、第１セキュリティコンテキスト５内で生成されず、第１セキュリティコンテキスト５の外部で生成され、その後、第１セキュリティコンテキスト５に与えられる。
【０２０２】
代替的実施形態において、暗号キーＫｔｅｎａｎｔの代わりに、第１セキュリティコンテキスト５において他の種類のデータが生成されるか、または、それが第１セキュリティコンテキストに与えられる。データに対応するアクセスコントロールリストがその後生成され、それは、データの使用の第１のタイプを許可するために、有効使用クレデンシャルが与えられなければならないことを特定する。使用の第１のタイプは、例えばデータファイルのコンテンツの読込である。
【０２０３】
以下の説明において、方法および装置は、テナントキーの転送およびリースに関連して説明されるが、他の種類のデータがテナントキーと代替されて、同じ方法で転送およびリースされてもよい。
【０２０４】
ＡＣＬはひとつ以上のパーミションまたはポリシーを有する。各パーミションはキーの特定の使用を管理する。例えば、第１パーミションは、キーがどのように格納されるかを管理し、第２パーミションはキーが暗号化のためにどのように使用されるかを管理し、第２パーミションはキーが解読のためにどのように使用される、という具合である。
【０２０５】
ＡＣＬはまた、特定パーミションに関連するクレデンシャルを有する。クレデンシャルは、特定のパーミションを許可するために何が与えられるべきかを特定する。いくつかのパーミションは、例えば、格納パーミションなどの関連クレデンシャルを有していなくてもよい。
【０２０６】
図２Ａおよび図２Ｂに関連して説明したように、テナントは、キーが転送される前に、第２セキュリティコンテキスト７がＡＣＬ内の要求を忠実に守ることを認証している。テナントは、第２セキュリティコンテキスト７が信用された製造業者によって製造されたことを認証する。テナントは、第２セキュリティコンテキスト７のカレントコンフィギュレーションがテナントのセキュリティ要求に一致することも認証してよい。第２セキュリティコンテキスト７が信用され、かつ、テナント要求に一致することを認証することにより、テナントは、第２セキュリティコンテキスト７がＡＣＬ内に含まれるポリシー／パーミションを行使することを確認できる。
【０２０７】
アクセスコントロールリストは、例えば、使用サーティフィケートなどの有効使用クレデンシャルが、暗号キーＫｔｅｎａｎｔのある使用を許可するために与えられなければならないことを特定する。したがって、ＫｔｅｎａｎｔＡＣＬは、キーが例えば暗号化に使用されるたびに、与えられるべき有効サーティフィケートを要求してよい。この使用に関連するパーミションは、例えば使用サーティフィケートなどの関連クレデンシャルを有する。
【０２０８】
テナントは、例えば暗号化のためのキーの使用を管理するパーミション内で、有効使用サーティフィケートが要求されることを特定してよい。したがって、暗号化用に暗号キーＫｔｅｎａｎｔを使用するために、有効使用サーティフィケートがパーミションをアクティブにするべく与えられる必要がある。
【０２０９】
パーミションは、パーミションに対応する使用を許可するために、使用サーティフィケートが、使用サーティフィケートに対応する暗号キーＫｔｅｎａｎｔが識別可能である情報を有しなければならないことを特定してよい。ＡＣＬは、Ｋｔｅｎａｎｔのハッシュを有してよい。
【０２１０】
ＡＣＬは、第２セキュリティコンテキスト７へのリファレンスを有する。第２セキュリティコンテキスト７へのリファレンスは、識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂのハッシュを有してよい。
【０２１１】
実施形態において、パーミションは、パーミションに関連する使用を許可するために、テナントによって所有される非線形キーのプライベートハーフＫｔｅｎａｎｔ−ｓｉｇｎによってサインされたサーティフィケートのプレゼンテーションを要求する。パーミションは、暗号キーＫｔｅｎａｎｔの使用を許可するために、使用サーティフィケートが、第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされなければならないことを特定する。
【０２１２】
実施形態において、パーミションは、使用サーティフィケートの満期を判定可能な情報を有しなければならず、かつ、パーミションに関連する暗号キーＫｔｅｎａｎｔの使用を許可するために、満了前であることを特定する。したがってテナントは、使用サーティフィケートにおいて、そのキーの満了期間を特定することができ、その後、キーは他の許可が与えられるまで使用されない。これにより、キーが使用される時間にわたって保証された状態で、テナントとサービスプロバイダーとの間の暗号マテリアルの転送が可能となる。これは、キーの使用がテナントによって特定された設定時間中のみキーが使用できることを保証する。
【０２１３】
実施形態において、ＡＣＬは、使用サーティフィケートの有効時間間隔の開始時刻を決定可能な情報を有しなければならず、かつ、開始時刻は、パーミションに関連する暗号キーＫｔｅｎａｎｔの使用を許可するために経過していなければならない。したがって、テナントはキーの有効時間間隔を特定することができ、それ以外でキーは、さらに許可が与えられるまで使用されない。これは、キーの使用が、テナントによって特定される設定時間インターバルの間でのみ可能であることを保証する。
【０２１４】
暗号キーＫｔｅｎａｎｔの格納を管理するパーミションに対して、サーティフィケートクレデンシャルは与えられない。これは、ストレージを管理するパーミションが常にアクティブであること、または、例えばキーが不揮発性媒体内に格納されるまでの間だけアクティブであることを意味する。これにより、第２セキュリティコンテキスト７は、サーティフィケート無しでキーを格納することができる。ストレージを管理するパーミションが、キーが不揮発性媒体内に格納されるまでの間だけアクティブである場合に、パーミションは一時的パーミションであり、格納後に非アクティブになる。すなわち、それはＡＣＬからはがされる。
【０２１５】
パーミションは、暗号キーＫｔｅｎａｎｔが、第２セキュリティコンテキスト７を離れることができないキーによって、格納用に暗号されたときにのみ、第２セキュリティコンテキスト７の外部に格納可能であることを特定してよい。パーミションは、Ｋｔｅｎａｎｔが、第２セキュリティコンテキスト７を離れることができないキーによってのみ暗号化され、管理者、すなわち、サービスプロバイダーによってコントロール不能であることを特定する。パーミションはまた、例えばテナントキーＫｔｅｎａｎｔを暗号化するのに使用可能なキーのタイプおよびメカニズムを有し、テナントキーＫｔｅｎａｎｔは２５６ビットのＡＥＳキーを有するＡＳＥ−ＧＣＭを使ってのみ暗号化可能である。パーミションは、暗号キーＫｔｅｎａｎｔが第２セキュリティコンテキスト７内部にも格納可能であることを特定してよい。
【０２１６】
実施形態において、パーミションは、暗号キーＫｔｅｎａｎｔおよびＡＣＬは、認証済み暗号アルゴリズムによって暗号化されるべきであることを特定する。
【０２１７】
実施形態において、パーミションは、暗号キーＫｔｅｎａｎｔの起源を同定可能な情報が、暗号化された暗号キーＫｔｅｎａｎｔおよびアクセスコントロールリストと同じデータ構造で格納され、かつ、信頼保護されていることを特定する。
【０２１８】
代替的に、パーミションは、暗号キーＫｔｅｎａｎｔが第２セキュリティコンテキスト７内部にのみ格納可能であることを特定してよい。
【０２１９】
ＫｔｅｎａｎｔＡＣＬは、テナントキーが第２セキュリティコンテキスト７内部にのみ格納可能であること、および／または、サービスプロバイダーによって取得不能なキーによって第２セキュリティコンテキスト７の外部のストレージに対して暗号化されれば、第２セキュリティコンテキスト７の外部に可能可能であることを特定するパーミションを含む。第２セキュリティコンテキスト７がＡＣＬ内で特定されたポリシーを行使する限り、テナントキーＫｔｅｎａｎｔはホストサービスプロバイダー３に晒されることはない。
【０２２０】
テナントは、第２セキュリティコンテキスト７の製造業者が信頼された製造業者であることを認証する情報を受信したので、第２セキュリティコンテキスト７はポリシーを行使することを保証した。第２セキュリティコンテキストの製造業者を同定する情報は、生成サーティフィケート内で送信される。例えば、生成サーティフィケートは、製造業者プライベートキーによってサインされる。また、テナントは、第２セキュリティコンテキスト７の製品、ソフトウエアおよびハードウエアを認証する情報を受信している。この情報は生成サーティフィケート内で送信される。製造業者は信用された製造業者として同定されているので、テナントは、第２セキュリティコンテキスト７が製造業者によって与えられる情報と一致することを信用する。例えば、生成サーティフィケートが、ソフトウエアおよびハードウエアがサービスプロバイダーによる攻撃に鈍感であることを特定する情報を含む場合、テナントは、当該情報が信用済みの製造業者によって与えられたものであること信用する。テナントは、サービスプロバイダーが、製造業者からのあるギャランティを有する第２セキュリティコンテキスト７を使っていることを、生成サーティフィケートから認証することができる。製造業者は、ＡＣＬが第２セキュリティコンテキスト７によって行使されることを保証する情報を生成サーティフィケート内に与えることができる。テナントは、製造業者を信用しているので、このギャランティもまた信用される。したがって、テナントに、ＡＣＬが行使されることを許可するギャランティ情報は、製造業者から生じる。また、コンフィギュレーションサーティフィケート内で送信されるコンフィギュレーション情報は、テナントに、誰かが第２セキュリティコンテキスト７に物理的またはハッキングすることにより改ざんを試みたか否かを知らせる。テナントが、第２セキュリティコンテキスト７が改ざんされていなかったことを確認すると、製造業者からのギャランティはまだ適用可能である。
【０２２１】
サービスプロバイダー、またはサービスプロバイダーに対して裁判管轄を有するセキュリティエージェンシーに対して暗号材料が晒されていない状態で、ＡＣＬは、テナントとサービスプロバイダーとの間での暗号マテリアルの転送を可能にする。例えば、ＵＫに存在するテナントは、ＵＫに本社がある会社に対して裁判管轄を有しないアメリカのセキュリティエージェンシーにキーが渡される危険があるので、アメリカのサービスプロバイダーによってアクセス可能な暗号キーを使用したくない。
【０２２２】
また、それにより、サービスプロバイダーは、テナントごとに専用のアプライアンスを維持する必要がなく、単一のインフラストラクチャー内で複数のテナントからのキーをサポートすることができる。テナントは、テナントのキーを抽出することができたサードパーティーがその後キーを使用するので、サードパーティーがアクセス可能なキーを使用したくない。暗号キーＫｔｅｎａｎｔが第２セキュリティコンテキスト７内にのみ格納されること、および／または、第２セキュリティコンテキスト７を離れることができないキーによってストレージに対して暗号化されれば第２セキュリティコンテキスト７の外部に格納可能であることを特定するパーミションを有するアクセスコントロールリストを与えることにより、キー材料が他のテナントに決して晒されないことを保証しつつ、複数のテナントは、同じ暗号インフラストラクチャーを使用することができる。サービスプロバイダーおよびテナントは、効率を向上させる安全な方法で、暗号インフラストラクチャーを共有することができる。
【０２２３】
ＡＣＬ内に含まれるパーミションおよび複数のパーミションは、Ｋｔｅｎａｎｔがどのように格納されかつ設定されるかを制限し、その結果、Ｋｔｅｎａｎｔは、サービスプロバイダーを含むだれからもアクセス不能となる。キーの使用の第１タイプに対応するパーミションが、テナントにのみ知られたプライベートキーによってサインされたサーティフィケートクレデンシャルによりアクティブ化されるので、第２セキュリティコンテキスト７は、許可サーティフィケートがキーによって与えられる時間まで、キーの使用の第１のタイプを許可しない。これは、キー材料の使用の第１のタイプが、サービスプロバイダーを含む任意のサードパーティーによってアクセス不能であることを意味する。したがって、テナントは暗号キーがサービスプロバイダーまたは任意のサードパーティーに対して晒されないことの保証を維持することができる。テナントは、アクセスコントロールリストを通じて第２セキュリティコンテキスト内にインポートされれば、そのキーの使用をコントロールすることができる。
【０２２４】
アクセスコントロールリストは、テナントキーＫｔｅｎａｎｔの特定の使用を許可するために、使用サーティフィケート内で特定の情報が与えられなければならないことを特定する。このようにして、テナントは、キーがサービスプロバイダーによってどのように使用されるかを制限することができる。例えば、ＡＣＬは、あるプライベートキーによってサインされたサーティフィケートが与えられたとき、テナントキーがデータを暗号化するのに使用可能であることを特定するパーミションを含む。したがって、パーミションに関連するクレデンシャルは、あるプライベートキーによってサインされたサーティフィケートである。それはまた、異なるプライベートキーによってサインされたサーティフィケートによって与えられたとき解読が利用可能であることを特定するパーミションを含む。各パーミションは、例えば、異なるプライベートキーによってサインされるサーティフィケートなどの異なるクレデンシャルを要求してよい。
【０２２５】
さらに、サーティフィケート内に含まれる情報は、タイムスタンプが共有された信用クロックへのリファレンスおよび／またはサーティフィケートが使用されるアプライアンスのアイデンティティ（例えばＫＩＤ  ｐｕｂのハッシュ）を含むところの、サーティフィケートが発行された時間を含むことをパーミションが特定してよい。アイデンティティを含むことは、コンテキスト内のどのアプライアンスが使用可能であるかを制限する。
【０２２６】
第２セキュリティコンテキストおよびテナントキーＫｔｅｎａｎｔに対応するＡＣＬの付与により確立された信用により、テナントは、サービスプロバイダーが、ＡＣＬ内に与えられたルールのセットを遵守することを暗号的に認証することができる。それは、キーが転送された後に、暗号材料の非開示および使用を保証する。それにより、テナントは、複数のテナントをサポートしつつ、制限された方法での使用に対して、サービスプロバイダーに暗号キーを安全かつ検証可能にリースすることができる。
【０２２７】
ＡＣＬは、サービスプロバイダーがテナントのキー材料へアクセス不能であること、テナントがそのキーはそのコントロール状態の下でのみ使用可能であることの保証を有し、複数のテナントが安全な方法で同じ暗号インフラストラクチャーを共有することができることを保証するポリシーを有する。それが、使用可能な時間間隔を制限しつつ、キーＫｔｅｎｅｎｔのリースを可能にする。それにより、テナントは、サービスプロバイダーによってホストされるとき、そのキーの使用を正確にコントロールすることができる。
【０２２８】
Ｋｔｅｎａｎｔが生成された後、テナントは、サービスプロバイダーとともにキー貸与プロトコルを開始する。例えば、第１セキュリティコンテキスト５は、ステップＳ６０２を開始する第２セキュリティコンテキスト７に対してメッセージを送信する。メッセージはリクエストＫＢＬＯＢ  ｐｕｂをリクエストしてよい。
【０２２９】
ステップＳ６０２において、暗号スキーム内で使用するのに適した第１暗号キーペアおよび第１暗号サーティフィケートＣＢＬＯＢが第２セキュリティコンテキスト７内で生成され、第１暗号キーペアは、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを有する。実施形態において、第１暗号サーティフィケートは、第１パブリックキーＫＢＬＯＢ  ｐｕｂのハッシュを有する。
【０２３０】
実施形態において、新しい第１暗号キーペアＫＢＬＯＢおよび第１暗号サーティフィケートＣＢＬＯＢは、各データ転送用に生成される。換言すれば、第１暗号キーペアＫＢＬＯＢおよび第１暗号サーティフィケートＣＢＬＯＢの各々は、一回の使用に対してのみ有効である。
【０２３１】
実施形態において、第１暗号サーティフィケートＣＢＬＯＢおよびコンフィギュレーションサーティフィケートは、単一のサーティフィケートである。換言すれば、図２Ｂの方法に代わって、第２セキュリティコンテキストのカレントコンフィギュレーションに関連する情報をさらに有する第１暗号サーティフィケートが生成される。第２セキュリティコンテキストのカレントコンフィギュレーションに関連する情報は、図２Ｂに関連して説明されたようなものであってよい。
【０２３２】
ステップＳ６０３において、第１暗号サーティフィケートＣＢＬＯＢは第２セキュリティコンテキストの識別キーのプライベートハーフＫ２ＩＤ  ｐｒｉｖによって暗号化サインされる。第２プロセッサ１９は、第２セキュリティコンテキストの識別キーのプライベートハーフＫ２ＩＤ  ｐｒｉｖによって第１暗号サーティフィケートＣＢＬＯＢを暗号サインするように構成されている。
【０２３３】
実施形態において、第１暗号サーティフィケートＣＢＬＯＢは、ＫＢＬＯＢ  ｐｕｂが第２セキュリティコンテキスト７内で生成されたことを認証する。第１暗号サーティフィケートは、暗号キーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報を有する。実施形態において、暗号キーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報は、第１パブリックキーＫＢＬＯＢ  ｐｕｂのサイン済みハッシュである。換言すれば、第１暗号サーティフィケートＣＢＬＯＢは第１パブリックキーＫＢＬＯＢ  ｐｕｂのハッシュを有し、かつ、第２セキュリティコンテキストの識別キーのプライベートハーフＫ２ＩＤ  ｐｒｉｖによってサインされる。それにより、第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源が認証可能になる。
【０２３４】
第１暗号サーティフィケートは、サービスプロバイダーがサーティフィケートを生成したことを証明するために、Ｋ２ＩＤ  ｐｒｉｖによってサインされる。ハッシュを含むことで、データ、すなわち、第１パブリックキーＫＢＬＯＢ  ｐｕｂが転送中に改ざんされなかったことも認証する。
【０２３５】
実施形態において、第１暗号サーティフィケートは、ＫＢＬＯＢ  ｐｒｉｖが一時的なものであること、および、ＫＢＬＯＢ  ｐｒｉｖは第２セキュリティコンテキストを離れることができないことを認証する情報を有する。ＫＢＬＯＢ  ｐｒｉｖが一時的なものであること、および、ＫＢＬＯＢ  ｐｒｉｖが第２セキュリティコンテキストを離れることができないことを認証する情報は、第１暗号キーペアＫＢＬＯＢによって第１セキュリティコンテキスト５に送信される。第１暗号サーティフィケートは、この情報を有し、サインされ、したがって、メッセージ内に含まれる情報を認証する。
【０２３６】
ステップＳ６０４において、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよびサイン済みの第１暗号サーティフィケート｛ＣＢＬＯＢ｝Ｋ２ＩＤ  ｐｒｉｖが第１セキュリティコンテキスト５に送信される。ＫＢＬＯＢに関連する情報、例えば、ＫＢＬＯＢが一時的なものであること、および、ＫＢＬＯＢ  ｐｒｉｖが第２セキュリティコンテキストを離れることができないことを示す情報はまた、第１暗号キーペアＫＢＬＯＢとともに第１セキュリティコンテキスト５に送信され、第１サーティフィケート内に含まれる。第２トランシーバ１５は、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよびサイン済み第１暗号サーティフィケート｛ＣＢＬＯＢ｝Ｋ２ＩＤ  ｐｒｉｖを第１セキュリティコンテキスト５に送信するように構成されている。コンフィギュレーション情報および／またはキーに関する情報は、同じメッセージ内で第１セキュリティコンテキスト５に送信されてよい。
【０２３７】
ステップＳ６０２からＳ６０４において、開始メッセージに応答して、第２セキュリティコンテキスト７は、非対称キーＫＢＬＯＢを生成し、そのパブリックハーフおよび第２セキュリティコンテキストの識別キーのプライベートハーフＫ２ＩＤ  ｐｒｉｖによってサインされたサーティフィケートを第２セキュリティコンテキスト５に送る。ＫＢＬＯＢは一時的な非対称キーであり、付帯するキーサーティフィケートＣＢＬＯＢととに第２セキュリティコンテキスト７内で生成される。ＣＢＬＯＢにより、テナントは、キーが第２セキュリティコンテキスト７内のアプライアンスによって生成されたこと、Ｋｂｌｏｂのプライベートハーフが一時的なものであること、および、第２セキュリティコンテキスト７を離れることができないことを認証することができる。サービスプロバイダーは、ＫＢＬＯＢのパブリックハーフおよびＣＢＬＯＢを第１セキュリティコンテキスト５に送信する。
【０２３８】
ステップＳ６０５において、サイン済みの第１暗号サーティフィケート｛ＣＢＬＯＢ｝Ｋ２ＩＤ  ｐｒｉｖが第１セキュリティコンテキスト５において検証される。第１セキュリティコンテキスト５内の第１プロセッサ１７は、サイン済みの第１暗号サーティフィケート｛ＣＢＬＯＢ｝Ｋ２ＩＤ  ｐｒｉｖを検証するように構成されている。サイン済みの第１暗号サーティフィケート｛ＣＢＬＯＢ｝Ｋ２ＩＤ  ｐｒｉｖは、第２セキュリティコンテキストの識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂを使って検証される。第１プロセッサ１７は、所与のサイン済みメッセージ｛ＣＢＬＯＢ｝Ｋ２ＩＤ  ｐｒｉｖおよびパブリックキーＫ２ＩＤ  ｐｕｂがメッセージの信頼性の要求を受け入れるかまたは拒否する、サイン検証アルゴリズムを実行するように構成される。
【０２３９】
第１パブリックキーＫＢＬＯＢ  ｐｕｂの信頼性は、その後、第１暗号サーティフィケートＣＢＬＯＢからの第１セキュリティコンテキスト５において認証される。第１セキュリティコンテキスト５内の第１プロセッサ１７は、第１パブリックキーＫＢＬＯＢ  ｐｕｂを検証するように構成される。実施形態において、ＫＢＬＯＢ  ｐｕｂのハッシュ計算することにより、第１パブリックキーＫＢＬＯＢ  ｐｕｂの信頼性は認証され、それが、第１暗号サーティフィケートＣＢＬＯＢ内に含まれるものと一致することを認証する。第１パブリックキーＫＢＬＯＢ  ｐｕｂとともに送られた他の情報、例えば、カレントコンフィギュレーション情報および第１パブリックキーＫＢＬＯＢ  ｐｕｂに関連する情報もまたサーティフィケートから認証される。
【０２４０】
サインが検証されると、第１パブリックキーＫＢＬＯＢ  ｐｕｂが第１セキュリティコンテキスト５の第１デバイスメモリ９に格納される。代替的に、それは、第１セキュリティコンテキスト５によってインテグリティ保護可能であり、第１セキュリティコンテキスト５の外部の不信用ストレージ内に格納される。
【０２４１】
サインが検証されないか、または、キーが認証されなければ、第２セキュリティコンテキスト７にエラーがリターンされ、例えば、“AccessDenied”を記述するメッセージが送信される。この時点で、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の通信が終了する。
【０２４２】
第１暗号サーティフィケートＣＢＬＯＢが生成されるところの実施形態において、さらに第２セキュリティコンテキストにカレントコンフィギュレーションに関連する情報が含まれ、第２セキュリティコンテキストのカレントコンフィギュレーションに関連する情報はまたは図２Ｂに関連して説明したように、ステップＳ６０５において認証される。メッセージ内に含まれる任意のキー情報もまた認証される。
【０２４３】
ステップＳ６０５において、ソースを認証しかつそれがよく形成されており、かつ、テナントによって予想されるセキュリティポリシーと一致することを確認しながら、第１セキュリティコンテキストは、ＫＢＬＯＢのパラメータを認証するためにサーティフィケートを使用する。テナントのセキュリティポリシーは、キーの長さ、キーのタイプ、および／または、キーのパーミション−クレデンシャルペアを含むか、または、要求することができる。キーパーミションは、キーが使用されるオペレーションを記述するのに使用される。例えば、パーミションはキーが他のキーを暗号化するのに使用可能であること、または、それがデータを暗号化サインするのに使用されることを特定してよい。パーミションはそれが使用される前に一致するクレデンシャルによりアクティブ化されなければならない。このシステム内のクレデンシャルは、検証可能な暗号サーティフィケートの形式を取る。第１セキュリティコンテキスト５のＣＢＬＯＢは、ＫＢＬＯＢのプライベートハーフが一時的なものであること、第２セキュリティコンテキスト７が信用されたソースによって製造されたこと、および、第２セキュリティコンテキスト７の状態がキーを貸与するのに適切であることを認証する。
【０２４４】
ステップＳ６０６は、暗号キーＫｔｅｎａｎｔおよび対応するアクセス制御リストを第１セキュリティコンテキスト５内で第１パブリックキーＫＢＬＯＢ  ｐｕｂによって暗号化する工程を有する。第１プロセッサ１７は、暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストを第１パブリックキーＫＢＬＯＢ  ｐｕｂによって暗号化するように構成されている。
【０２４５】
第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間に通信チャネルが与えられ、かつ、サービスプロバイダーによってコントロールされる場合、それはサービスプロバイダーによる攻撃に対してオープンであるため、Ｋｔｅｎａｎｔのような高価値暗号キーの転送に対してテナントは信用しない。したがって、Ｋｔｅｎａｎｔのセキュリティは、第１パブリックキーＫＢＬＯＢ  ｐｕｂによるＫｔｅｎａｎｔの暗号化によりテナントによって行使される。第１サーティフィケートＣＢＬＯＢにより、テナントは、Ｋｂｌｏｂのプラべートランザクションハーフが第２セキュリティコンテキスト７を離れることができないことを認証することができる。したがって、第１パブリックキーＫＢＬＯＢ  ｐｕｂによりＫｔｅｎａｎｔの暗号化により、テナントは、サービスプロバイダーが通信チャネルを攻撃しても、Ｋｔｅｎａｎｔはサービスプロバイダーから安全であることを保証することができる。
【０２４６】
こうしてテナントの暗号化は、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の信用に根ざした安全チャネルを提供する。これにより、第１セキュリティコンテキスト５および第２セキュリティコンテキスト７によって信用されないより高レベルの安全認証チャネルが、テナントおよびサービスプロバイダーサイト間で使用可能となる。このより高いレイヤーの安全チャネルは、ロードバランサまたはファイアウォールアプライアンスを使ってサービスプロバイダーによって提供されてもよい。テナントキーの暗号化により、外部セキュリティサービスを信用する必要性なしにコンテキストのセキュリティを与えつつ、サービスプロバイダーは、サービスの停止のような攻撃を緩和するのにこのインフラストラクチャーを使用しつづけることができる。
【０２４７】
ＫＢＬＯＢ  ｐｕｂは、Ｋｔｅｎａｎｔの暗号化の後にテナントによって破棄される。
【０２４８】
実施形態において、暗号キーＫｔｅｎａｎｔの起源を承認可能な情報は、サイン済みの暗号化されたテナントキーおよびアクセスコントロールリスト｛｛Ｋｔｅｎｔｎａｔ、ＡＣＬ｝ＫＢＬＯＢ  ｐｕｂ｝Ｋｔｅｎａｎｔ−ｓｉｇｎ  ｐｒｉｖである。
【０２４９】
ステップＳ６０７において、ステップＳ６０６からの出力ｂｌｏｂは、Ｋｔｅｎａｎｔ−ｓｉｇｎのプライベートハーフを使って暗号化サインされる。第１プロセッサ１７は、Ｋｔｅｎａｎｔ−ｓｉｇｎのプライベートハーフによりステップＳ６０６からの出力ｂｌｏｂを暗号化サインするように構成されている。
【０２５０】
ステップＳ６０８において、暗号化された暗号キーおよび対応するアクセスコントロールリスト｛Ｋｔｅｎａｎｔ，ＡＣＬ｝、および暗号キーＫｔｅｎａｎｔの起源を認証可能な情報が第２セキュリティコンテキスト７に送信される。実施形態において、メッセージの起源を認証可能な情報もまた送信され、それは、例えば、Ｋｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフのハッシュであってよい。
【０２５１】
実施形態において、メッセージの起源を認証可能な情報は、Ｋｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュ、暗号化ｂｌｏｂ、サインキーのハッシュ、およびサインを含み、第２セキュリティコンテキスト７に送信される。サインは、暗号キーＫｔｅｎａｎｔの起源を認証可能な情報である。第１トランシーバ１３は、暗号化ｂｌｏｂ、ステップＳ６０７からのサイン済み出力ｂｌｏｂ、およびＫｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフのハッシュを第２セキュリティコンテキスト７へ送信するように構成されている。
【０２５２】
許容キーＫＢＬＯＢ  ｐｕｂが与えられると、それは、テナントが十分な暗号の長さとして定義したキーＫＢＬＯＢ  ｐｕｂであり、登録されるべきキーＫｔｅｎａｎｔが第１のセキュリティコンテキスト５においてＫｂｌｏｂのパブリックハーフによって暗号化される。上述したように、Ｋｔｅｎａｎｔは、パーミション−クレデンシャルペア、すなわち、キー材料が使用可能な許容オペレーションを特定し、かつ、Ｋｔｅｎａｎｔ−ｓｉｇｎのプライベートハーフによってサインされなければならないサーティフィケートによってアクティブ化されるＡＣＬを有する。暗号化ｂｌｏｂはＫｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフを使ってサインされ、暗号化ｂｌｏｂ、サインおよびＫｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフのハッシュは、第２セキュリティコンテキスト７に送信される。
【０２５３】
サービスプロバイダー内の第２セキュリティコンテキストへの暗号キーＫｔｅｎａｎｔの転送は、暗号キーＫｔｅｎａｎｔを暗号化するのに使用されるキーはプレインテキストで回復不能であるので、サービスプロバイダーおよび他の攻撃者から安全である。Ｋｂｌｏｂ  ｐｒｉｖは第１セキュリティコンテキスト５から第２セキュリティコンテキスト７へ送信されるデータをうまく解読するのに要求される。Ｋｂｌｏｂ  ｐｒｉｖは一時的なものであり、サービスプロバイダーまたはサードパーティーによってアクセス不能かつ変更不能である。
【０２５４】
図６Ｂは、本願発明の実施形態に従う、第１セキュリティコンテキスト５から第２セキュリティコンテキスト７へ暗号キーＫｔｅｎａｎｔを転送する方法のさらなるステップを示すフローチャートである。
【０２５５】
ステップＳ６０９において、暗号キーＫｔｅｎａｎｔの起源は、第２セキュリティコンテキスト７において認証される。実施形態において、これは、第１セキュリティコンテキスト５から送信されたメッセージ内に含まれたサインをまず検証することにより認証される。
【０２５６】
実施形態において、Ｋｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフのハッシュは、メッセージの起源を同定するのに使用され、よってサインを検証するのに要求される正しいサインキーを同定する。
【０２５７】
その後、サインはＫｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフを使って検証される。第２セキュリティコンテキスト７内の第２プロセッサは、サインを検証するように構成されている。サインはＫｔｅｎａｎｔのパブリックハーフを使って検証される。第２プロセッサは、所与のサインおよびパブリックキーＫｔｅｎａｎｔ−ｓｉｇｎがメッセージの信頼性の要求を受け入れるかまたは拒否するサイン検証アルゴリズムを実行するように構成されている。
【０２５８】
その後、サインのコンテンツが暗号化ｂｌｏｂと一致することが認証される。これは、暗号化ｂｌｏｂの起源の認証を可能にする。
【０２５９】
検証されかつ認証されると、方法はステップＳ６１０に進む。検証または認証されなければ、第１セキュリティコンテキスト５にエラーがリターンされる。例えば、“AccessDenied”を記述するメッセージが送られる。この時点で、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の通信は終了する。
【０２６０】
ステップＳ６１０は、暗号化した暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストを、第２セキュリティコンテキスト７において第１プライベートキーＫＢＬＯＢ  ｐｒｉｖにより解読する工程を有する。第２プロセッサ１９は、暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストを解読するように構成されている。第２プロセッサ１９は、所与の暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、および第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを解読するアルゴリズムを実行するように構成されている。
【０２６１】
ステップＳ６１１は、暗号キーＫｔｅｎａｎｔおよびＡＣＬを、第２セキュリティコンテキスト７において第３暗号キーによって再暗号化する工程を有する。この工程は、暗号キーＫｔｅｎａｎｔおよびＡＣＬが第２セキュリティコンテキスト７の外部に格納されるように実行される。代替的実施形態において、この工程は、省略され、暗号キーＫｔｅｎａｎｔおよびＡＣＬ、および暗号キーＫｔｅｎａｎｔの起源を同定する情報は、第２セキュリティコンテキスト７内で解読され格納される。
【０２６２】
ＡＣＬは、キーのどのタイプのパラメータがＫｔｅｎａｎｔを暗号化するのに使用可能であるかおよび、どの暗号化メカニズムが使用可能であるかを特定する。
【０２６３】
ＡＣＬは、パーミッション、すなわち、Ｋｔｅｎａｎｔが、第２セキュリティコンテキスト７を離れることができないキーによってのみ暗号化され、かつ、管理者すなわちサービスプロバイダーによりコントロール不能であることを記述するポリシーを有する。パーミションはまた、テナントキーＫｔｅｎａｎｔを暗号化するのに使用可能であるキーのタイプおよびメカニズムを含む。例えば、テナントキーＫｔｅｎａｎｔは、２５６ビットのＡＥＳキーを有するＡＥＳ−ＧＣＭ（Ｇａｌｏｉｓ／Ｃｏｕｎｔｅｒ  ｍｏｄｅ）暗号を使ってのみ暗号化される。
【０２６４】
暗号化メカニズムは、信頼性、インテグリティおよび秘密性またはそれらの特定のサブセットを保証するニーズを特定する。
【０２６５】
第２セキュリティコンテキスト７は、ＡＣＬポリシー要求に一致する既存のキーを再利用するか、または、新しいキーを作成する。
【０２６６】
暗号キーＫｔｅｎａｎｔおよびＡＣＬは、特定されたメカニズムおよび、特定された要求に一致する第３の暗号キーを使って第２セキュリティコンテキスト７内で暗号化される。第２プロセッサは、第３暗号キーにより暗号キーＫｔｅｎａｎｔを暗号化するように構成されている。実施形態において、暗号キーＫｔｅｎａｎｔは第２セキュリティコンテキスト７を離れることができないキーによって格納用に暗号化される。
【０２６７】
暗号キーＫｔｅｎａｎｔおよびＡＣＬは、認証された暗号アルゴリズムを使って暗号化されてよい。
【０２６８】
実施形態において、暗号キーＫｔｅｎａｎｔおよびＡＣＬは認証された暗号アルゴリズム、例えばＡＥＳ−ＧＣＭで暗号化されるように入力され、一方、暗号キーＫｔｅｎａｎｔの起源を同定可能な情報は認証されたデータパラメータとして入力される。実施形態において、暗号キーＫｔｅｎａｎｔの起源を同定可能な情報はＫｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフである。実施形態において、Ｋｔｅｎａｎｔのハッシュがまた暗号キーＫｔｅｎａｎｔとともに格納され、例えば、Ｋｔｅｎａｎｔのハッシュは、暗号化されたデータが格納されたファイルの名前であってよい。
【０２６９】
再暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、および暗号キーＫｔｅｎａｎｔの起源を同定可能な認証情報が、第２セキュリティコンテキスト７の外部のデバイスメモリへ転送される。
【０２７０】
暗号キーＫｔｅｎａｎｔの起源を同定可能な情報は、暗号化された暗号キーＫｔｅｎａｎｔおよびアクセスコントロールリストと同じデータ構造で格納されるが、必ずしも暗号化されなくてよい。しかし、暗号キーＫｔｅｎａｎｔの起源を同定可能な情報は、信頼性保護されており、その結果それは通知なしで変更不能である。
【０２７１】
上述したステップにおいて、受信すると、第２セキュリティコンテキスト７がＫｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフを使ってペイロードサインを検証する。受信したペイロード内に含まれたハッシュは、テナントのサインキーのパブリックハーフを同定するのに使用される。受信したペイロードサインは、同定されたサインキーを使って検証される。ペイロードの検証が成功すると、ＫｔｅｎａｎｔＡＣＬにより行使され、後の使用のために第２セキュリティコンテキスト７の外部でＫｔｅｎａｎｔ−ｓｉｇｎのパブリックハーフとともに格納される際に、ＫｔｅｎａｎｔはＫｂｌｏｂのプライベートハーフを使って解読され、回復不能キーの下で再暗号化される。代替的に、キーＫｔｅｎａｎｔは第２セキュリティコンテキスト７内の保護された不揮発性メモリ内に解読されて格納される。両方の場合において、解読キーは、安全で、改ざん防止された方法で格納される。
【０２７２】
Ｋｔｅｎａｎｔが格納される方法がそのパーミションまたはポリシーによって記述される。特に、生成時において、許可されたパーミッションは、Ｋｔｅｎａｎｔがどのように格納されるかを制限し、第２セキュリティコンテキスト７以外のサービスプロバイダーを含むだれかによってＫｔｅｎａｎｔがアクセス不可能であるように設定される。
【０２７３】
複数のテナントが単一のサービスプロバイダーとともにキーを格納する実施形態において、テナントキーの各々は、同じキーによって格納用に暗号化される。代替的に、各テナントキーは、例えば各テナントに対応するＡＣＬ間で異なる格納パーミションが存在する場合には、異なるキーによって暗号化されてもよい。
【０２７４】
図７Ａは、本願発明の実施形態に従う暗号キー転送方法の一部である、キー登録方法の略示図である。当該方法は、図６Ａおよび図６Ｂに関連して上述したステップＳ６０２からＳ６１１を有する。
【０２７５】
キー登録メッセージは、第１セキュリティコンテキスト５から第２セキュリティコンテキスト７へ送信される。このメッセージに応答して、第１暗号キーペアＫＢＬＯＢが第２セキュリティコンテキスト７で生成される。第２セキュリティコンテキスト７は、第１暗号キーペアＫＢＬＯＢのパブリックハーフおひょびサイン済みの暗号サービスプロバイダー｛ＣＢＬＯＢ｝Ｋ２ＩＤ  ｐｒｉｖを第１セキュリティコンテキスト５に送信し、そこでそれらは認証される。暗号キーＫｔｅｎａｎｔは、第１セキュリティコンテキスト５においてＫＢＬＯＢ  ｐｕｂによって暗号化される。暗号化されたキー｛Ｋｔｅｎａｎｔ｝ＫＢＬＯＢ  ｐｕｂおよびハッシュ｛Ｋｔｅｎａｎｔ−ｓｉｇｎ  ｐｕｂ｝は、第１セキュリティコンテキスト５においてＫｔｅｎａｎｔ−ｓｉｇｎ  ｐｉｖによってサインされる。サイン済みメッセージは、第２セキュリティコンテキスト７に送信され、そこで認証される、暗号化されたキー｛Ｋｔｅｎａｎｔ｝ＫＢＬＯＢ  ｐｕｂは、管理者から安全である回復不能キーによって第２セキュリティコンテキスト７内で解読されかつ再暗号化される。暗号化されたテナントキーは、その後、第２セキュリティコンテキスト７の外部に格納される。
【０２７６】
図７Ｂは、本願発明の実施形態に従う暗号キー送信方法のフローチャートである。
【０２７７】
テナントは、第１セキュリティコンテキスト５内で、テナントキーのＡＣＬを設定する。その後、第１セキュリティコンテキスト５は、第２セキュリティコンテキスト７から第１パブリックキーＫＢＬＯＢ  ｐｕｂをリクエストする。第１セキュリティコンテキスト５は、例えば第２セキュリティコンテキスト７へリクエストメッセージを送信する。第１セキュリティコンテキスト５はその後、受信した第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１暗号サーティフィケートＣＢＬＯＢを認証する。これは、上述したステップＳ６０５に対応する。第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１暗号サーティフィケートＣＢＬＯＢが認証されなければ、エラーがリターンされる。それらが認証されれば、第１セキュリティコンテキスト５は、第１パブリックキーＫＢＬＯＢ  ｐｕｂによってテナントキーおよび関連するＡＣＬを暗号化する。これは、上述したステップＳ６０６に対応する。第１セキュリティコンテキスト５はその後、暗号化キーおよび関連ＡＣＬ、およびＫｔｅｎａｎｔ−ｓｉｇｎ  ｐｕｂのハッシュをＫｔｅｎａｎｔ−ｓｉｇｎ  ｐｒｉｖによってサインする。これは、上述したステップＳ６０７に対応する。その後、第１セキュリティコンテキスト５は、暗号化ｂｌｏｂ、Ｋｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュ、およびサインを第２セキュリティコンテキスト７と交換する。これは、上述したステップＳ６０８に対応する。
【０２７８】
図８Ａは、テナントキーＫｔｅｎａｎｔが第２セキュリティコンテキスト７にインポートされた後のテナントシステム１およびサービスプロバイダーシステム３の略示図である。実施形態において、ＫｂｌｏｂおよびＣｂｌｏｂは一時的なものであり、Ｋｔｅｎａｎｔが送信されたら、第２セキュリティコンテキスト７および第１セキュリティコンテキスト５から削除される。
【０２７９】
第１セキュリティコンテキスト５内の第１デバイスメモリ９はまた、第１パブリックキーＫＢＬＯＢ  ｐｕｂを格納する。代替的に、このキーは、インテグリティ保護された方法で、第１セキュリティコンテキスト５の外部に格納されてもよい。第２セキュリティコンテキスト内の第２デバイスメモリ１１はまた、テナントキーＫｔｅｎａｎｔおよび対応するＡＣＬを格納する。代替的に、テナントキーＫｔｅｎａｎｔおよびＡＣＬは第２セキュリティコンテキスト７の外部に格納され、第２セキュリティコンテキスト７を離れることができない第３暗号キーによって暗号化されてよい。
【０２８０】
図８Ｂは、改ざん防止の安全基準時間ソース２の略示図であり、それは、サービスプロバイダー、テナント、または、別のサードパーティーによってホストされてよい。サービスプロバイダーによってホストされれば、基準時間ソースは、第２セキュリティコンテキスト７の一部であるか、異なるセキュリティコンテキストであってよい。
【０２８１】
時間ソース２は、第２デバイスメモリ３５を有する。第３デバイスメモリ３５は、複数キー、キーペアおよびサーティフィケートのような暗号情報を格納するように構成されている。第３デバイスメモリ３５は、例えばフラッシュ、光学ディスクまたは磁気ハードドライブなどの任意の形式の不揮発性デバイスメモリを有する。時間ソース２はまた揮発性メモリを有する。
【０２８２】
第３デバイスメモリ３５は、対応するサイン済みのオペレーションサーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖとともにユニークな非対称識別キーＫＴＳＩＤを格納する。ＫＴＳＩＤはデータの起源および安全性を証明するのに使用されるサインである。生成サーティフィケートＣＴＳＩＤは、例えば、キーのタイプ、キーの長さなどのキーのパブリックパラメータを記述してよい。生成サーティフィケートＣＴＳＩＤは、識別キーＫＴＳＩＤが時間ソース２内で生成されたことを認証する情報を有する。例えば、姿勢サーティフィケートＣＴＳＩＤは、ＫＴＳＩＤのパブリックハーフのサイン済みハッシュを有してよい。生成サーティフィケートＣＴＳＩＤはまた、例えば、デバイスのユニークは識別子に関連する情報、製造業者を同定する情報、デバイスバージョン、ハードウエアバージョン、ソフトウエアのタイプ、モデルのサポート特徴などの状態情報を有する。生成サーティフィケートＣＴＳＩＤは、第１セキュリティコンテキスト５および第２セキュリティコンテキスト７の両方によって信用された製造業者によってサインされる。生成サーティフィケートは、製造業者非対称キーのプライベートハーフＫｍａｎ  ｐｒｉｖによって暗号化サインされる。製造業者は、第１セキュリティコンテキストを形成するセキュリティアプライアンス、第２セキュリティコンテキストおよび時間ソース２を形成する第２セキュリティアプライアンスを製造したサードパーティーであってよい。
【０２８３】
時間ソース２はさらに、第３トランシーバ３９を有する。第３トランシーバ３９は、データパケットを送受信するように構成されている。データパケットは、例えば無線インターネット接続を介して、トランシーバ３９において送受信される。
【０２８４】
時間ソース２はさらに第３プロセッサ４１を有する。第３プロセッサ４１は、暗号キーおよび非対称暗号キーペアの生成、暗号キーまたは非対称暗号キーペアに対応するサーティフィケートの生成、暗号キーに対応するアクセスコントロールリストの生成、暗号キーに対応する使用サーティフィケートの生成、第３デバイスメモリ３５内に格納される暗号キーによるオブジェクトの暗号化、第３デバイスメモリ３５内に格納された暗号キーによる暗号化オブジェクトの解読、第３デバイスメモリ３５内に格納された暗号キーによるオブジェクトの暗号化サイン、第３デバイスメモリ３５内に格納された情報に基づくオブジェクトのサイン検証および認証などの、暗号オペレーション実行するように構成されている。
【０２８５】
時間ソース２はさらに、クロック３７を有する。クロック３７は、単調クロック、すなわち、時間を通じて単調に増加するカウンタであってよい。クロックは、高度に正確な日時を表す。実施形態において、クロックは、１秒またはそれ以上に正確である。例えば、クロックは、４０ナノ秒のオーダーで正確であるＧＰＳ信号に基づいてよい。
【０２８６】
時間ソース２は、デバイス全体をカバーし、下層の物理的ハードウエアを破壊する、したがって使用不能にすることなく除去不可能である薄膜のような物理的セキュリティを含むことにより改ざん防止されてよい。
【０２８７】
図８Ａおよび図８Ｂに示す３つのサービスは、１）テナントによって所有されかつ操作される、例えば安全アプライアンスのような第１セキュリティコンテキスト５、２）サービスプロバイダーによって所有されかつ操作される、例えば一つ以上の安全アプライアンスなどの第２セキュリティコンテキスト７、および３）サービスプロバイダー、外部のサードパーティー、またはテナントによって所有され、既知の安全プロパーティーのセットを有する信用されたサードパーティーによって構築されたこを検証でき、かつ、同じルールを遵守する協働サービスのセットである、信用された時間ソース２を有する。テナントは、協働サービスを構築するが、これらのサービスのいくつかをホストしているサービスプロバイダーを信用していないことが仮定されている。セキュリティコンテキストは、リクエストが負荷分散された交差クラスタを形成し、かつ、暗号プリミティブのセットを共有するひとつ以上の安全アプライアンスであってよい。
【０２８８】
第１セキュリティコンテキスト５、第２セキュリティコンテキスト７および基準時間ソース２の各々は、暗号サーティフィケートを使って検証可能に同定され、それは、例えば製造時に生成されてよい。各々は、制限されないことを意味する方法でアイデンティティを安全に格納することができる。第１セキュリティコンテキスト５、第２セキュリティコンテキスト７または基準時間ソース２の同定は、起源の保証を与える。
【０２８９】
また、第１セキュリティコンテキスト５、第２セキュリティコンテキスト７および基準時間ソース２の各々の構成および状態は、拒絶可能な方法で認証可能である。ソースの起源および状態は、他のサービスが信用を置くことができる十分な情報を画定する。
【０２９０】
各コンポーネントは、例えば製造時に、工場で生成されたＫＩＤを含む。各コンポーネントはまた製造業者によってのみ知られた非対称キーを使ってサインされたＫＩＤに対するキーサーティフィケートを含む。製造業者キーのパブリックハーフは、純正アプライアンスを認証する信用のルートとして使用され得る。
【０２９１】
以下で説明される、基準時間ソース２と第２セキュリティコンテキストとの間での暗号サーティフィケートおよび暗号キーの転送は、サービスプロバイダーによって与えられかつコントロールされる、基準時間ソース２と第２セキュリティコンテキスト７との間の安全な認証済みチャネルを通じて生じる。チャネルはサードパーティーから安全であるが、サービスプロバイダーによる攻撃にはオープンであり、したがって信用されない。
【０２９２】
図９に関連して以下で説明されるパブリックキーおよびサーティフィケートの交換により、第２セキュリティコンテキスト７と時間ソース２との間で信用された関係が確立可能になる。
【０２９３】
図９は、第２セキュリティコンテキスト７とともに時間ソース２を登録する方法を示すフローチャートである。これは、本願発明の実施形態に従う暗号キー転送方法の任意の時点で、または、本願発明の実施形態に従う暗号キーの使用をコントロールする方法の一部として実行可能である。例えば、時間ソース２を登録する方法は、第２セキュリティコンテキスト７の管理者が第２セキュリティコンテキスト７内のアプライアンスを設定するとき、すなわち、認証が実行されるときに実行されてよい。これは、まれな処理であり、一度だけ実行が必要なものである。時間ソース２の登録後に、第２セキュリティコンテキスト７はその後、潜在的なテナントへ、信用された時間ソースに関連する情報をブロードキャストする。したがって、テナントは最初に、どの時間ソースがサービスプロバイダーをサポートするかを知り、図１０に関連して以下で説明するように、時間ソースの信頼性、状態およびコンフィギュレーションを認証することにより、キーの登録が始まる前に、これらの時間ソースが受け入れ可能か否かについて決定することができる。
【０２９４】
基準時間ソース２が第２セキュリティコンテキスト７の一部であれば、第２セキュリティコンテキスト７とともに時間ソース２を登録する必要はなく、これらのステップは実行されない。
【０２９５】
基準時間ソース２は、図８に関連して上述したように、デバイスメモリ３５およびクロック３７を有する。
【０２９６】
ステップＳ９０１において、時間ソースの識別キーのパブリックハーフＫＴＤＩＤ  ｐｕｂおよび生成サーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖが、第２セキュリティコンテキスト７からの質問メッセージに応答して、基準時間ソース２から第２セキュリティコンテキスト７へ送信される。基準時間ソース２内のトランシーバ３９は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂおよび生成サーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖを第２セキュリティコンテキスト７内の第２トランシーバ１５に送信するように構成されている。時間ソースデバイス２に関連する情報は、同じメッセージ内で送信されてよい。この場合、デバイスの状態に関連する情報は、状態情報の認証を許可するために、生成サーティフィケート内にも含まれる。
【０２９７】
ステップＳ９０２において、生成サーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖは第２セキュリティコンテキスト７において検証される。第２セキュリティコンテキスト７内の第２プロセッサ１９は、生成サーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖを検証するように構成されている。生成サーティフィケートは、信用された製造業者キーのパブリックハーフＫｍａｎ  ｐｕｂを使って検証される。第２プロセッサ１９は、所与のサイン済みメッセージ｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖおよびパブリックキーＫｍａｎ  ｐｕｂがメッセージの信頼性の要求を受け入れるかまたは拒絶するサイン検証アルゴリズムを実行するように構成されている。
【０２９８】
その後、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂの信頼性が、第２セキュリティコンテキスト７において認証される。第２セキュリティコンテキスト７内の第２プロセッサ１９は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂを認証するように構成されている。生成サーティフィケートＣＴＤＩＤが時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂのハッシュを有するところの実施形態において、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂの信頼性は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂのハッシュを計算し、それが生成サーティフィケートＣＴＳＩＤ内に含まれるものと一致することを認証することにより、認証される。
【０２９９】
ステップＳ９０３において、第２セキュリティコンテキスト７はまた、メッセージ内に含まれる任意の状態情報が要求と一致することを認証する。
【０３００】
サインが認証され、かつ、状態情報が認証されれば、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂは、第２セキュリティコンテキスト７の第２デバイスメモリ１１内に格納される。代替的に、それは、第２セキュリティコンテキスト７によってインテグリティ保護され、かつ、第２セキュリティコンテキスト７の外部の不信用ストレージ内に格納される。
【０３０１】
サインが認証されないか、または、キーまたは状態情報が認証されなければ、エラー、が時間ソース２にリターンされ、例えば、“AccessDenied”を記述するメッセージが送信される。この時点で、第２時間ソースと第２セキュリティコンテキスト７との間の通信は終了する。
【０３０２】
上述したステップにおいて、第２セキュリティコンテキスト７は、基準時間ソース２により信用を確立する。したがって、第２セキュリティコンテキスト７は、サーティフィケートチェーンを通じて、起源、状態および信頼性を認証することにより、時間ソース２により信用を確立する。
【０３０３】
信用が確立されると、第２セキュリティコンテキスト７はステップＳ９０４において時間ソース２からコンフィギュレーション情報をリクエストする。第２セキュリティコンテキスト７内のトランシーバ１５は、時間ソース２に情報をリクエストするメッセージを送信する。
【０３０４】
ステップＳ９０５において、リクエストに応答して、時間ソース２は、クロックおよびセキュリティ設定に関する正確な情報を含む、時間ソース２のコンフィギュレーションに関連する情報を含むコンフィギュレーション情報、セットアップされた暗号プリミティブ、時間ソースが実行中のソフトウエアのバージョン、および、検出された任意の例外を含む、時間ソース２の状態を生成する。時間ソース２内の第３プロセッサ４１は、このメッセージを生成するように構成されている。
【０３０５】
ステップＳ９０６において、応答メッセージは、時間ソースの識別キーのプライベートハーフＫＴＳＩＤ  ｐｒｉｖによってサインされる。時間ソース２内の第３プロセッサ４１は、時間ソースの識別キーのプライベートハーフＫＴＳＩＤ  ｐｒｉｖによって、メッセージを暗号化サインするように構成されている。
【０３０６】
ステップＳ９０７において、サインおよび構成情報が第２セキュリティコンテキスト７に送信される。時間ソース２内のトランシーバ３９は、第２セキュリティコンテキスト７へサイン済みのメッセージを送信するように構成されている。
【０３０７】
ステップＳ９０８において、第２セキュリティコンテキスト７は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂを使って応答サインを検証する。第２セキュリティコンテキスト５内の第２プロセッサ１９は、サインを検証するように構成されている。サインは、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂを使って検証される。第２プロセッサ１９は、所与のサイン済みメッセージおよびパブリックキーＫＴＳＩＤ  ｐｕｂがメッセージの信頼性の主張を受け入れるかまたは拒絶するサイン検証アルゴリズムを実行するように構成されている。
【０３０８】
ステップＳ９０９において、時間ソースコンフィギュレーションが許容トレランス内にあるか否かに関するチェックが実行される。コンフィギュレーション情報は、それがサービスプロバイダーの要求に一致することを認証するようにチェックされる。
【０３０９】
コンフィギュレーション情報は、タイムスタンプが第２セキュリティコンテキスト７によって要求されているか否かを、コンフィギュレーション情報を再度リクエストすることにより、再チェック可能である。
【０３１０】
システム内のずべてのアプライアンスの状態およびコンフィギュレーション、すなわち、第１セキュリティコンテキスト５、第２セキュリティコンテキスト７、および、基準時間ソース２は、アプライアンス内に与えられた状態エントリーから得られる。初期化の後、各アプライアンスは、このフィールドを更新し、クライアントが新しいアプライアンス設定を暗号化検証できるように新しいコンフィギュレーションメッセージを生成する。
【０３１１】
サインの検証が成功し、かつ、時間ソース２のコンフィギュレーションがトレランスの範囲にあれば、方法はステップＳ９１０に進む。そうでなければ、エラーが時間ソース２にリターンされ、例えば“AccessDenied”を記述するサインが送られる。この時点で、時間ソース２と第２セキュリティコンテキスト７との間の通信は終了する。
【０３１２】
ステップＳ９１０において、時間ソース２を同定する情報、および、時間ソース２が第２セキュリティコンテキスト７によって信用されたことを示す情報を有するメッセージが第１セキュリティコンテキスト５に送信される。時間ソース２を同定する情報は、例えば時間ソース２の識別キーのパブリックハーフのハッシュ、または、時間ソース２のＩＰアドレスなどのユニークな識別番号を有する。第２セキュリティコンテキスト７内のトランシーバ１５は、時間ソース２を同定する情報、および、時間ソースが信用されていることを示す情報を第１セキュリティコンテキスト５に送信するように構成されている。時間ソース２を同定する情報および時間ソース２が信用されていることを示す情報は、第２セキュリティコンテキスト７のデバイスメモリ１１に、または、インテグリティ保護される方法で第２セキュリティコンテキスト７の外部に格納される。
【０３１３】
実施形態において、第２セキュリティコンテキスト７は、時間ソース２を信用済み時間ソースのリストへ追加する。基準時間ソースのユニークな識別子は、リストに追加されてよい。信用済み時間ソースのリストは、その後、第２セキュリティコンテキストによってブロードキャストされる。第１セキュリティコンテキスト５は、第２セキュリティコンテキスト７から信用済み時間ソースのリストを受信する。
【０３１４】
ひとつ以上の信用済み時間ソースを同定する情報が受信されると、第１セキュリティコンテキストは問いあわせをし、第２セキュリティコンテキスト７と同じ方法で、時間ソースの信頼性、状態およびコンフィギュレーションを認証する。図１０は、このプロセスを示すフローチャートである。これは、本願発明の実施形態に従うキー転送方法の一部として、任意のポイントで、または、本願発明の実施形態に従う暗号キーの使用をコントロールする方法の一部として実行可能である。
【０３１５】
代替的に、基準時間ソース２が第１セキュリティコンテキスト５の一部であれば、以下のステップが実行されない。
【０３１６】
また、基準時間ソース２が第１セキュリティコンテキスト５によって最初に同定される場合、以下のステップが実行され、その後時間ソース２に関連する情報が第２セキュリティコンテキスト７に送信され、その後、それが時間ソースを認証する。
【０３１７】
以下で説明するように、基準時間ソース２と第１セキュリティコンテキスト５との間での暗号サーティフィケートおよび暗号キーの転送は、基準時間ソース２と第１セキュリティコンテキスト５との間の安全で、認証されたチャネルを通じて生じる。時間ソースがサービスプロバイダーによって与えられる場合、チャネルはサービスプロバイダーまたはプロキシによって与えられかつコントロールされる。時間ソースがサードパーティー時間サービスプロバイダーによって与えられる場合、チャネルはテナントと時間サービスプロバイダーとの間に直接与えられてよい。このチャネルは、時間サービスプロバイダーまたはプロキシによって与えられてよい。チャネルはサードパーティーから安全であるが、時間サービスプロバイダーによる攻撃に対してオープンである点に注意すべきである。以下で説明される基準時間ソース２と第２セキュリティコンテキスト７との間の暗号サーティフィケートおよび暗号キーの転送は、基準時間ソース２および第２セキュリティコンテキスト７との間の安全で認証されたチャネルを通じて生じる。
【０３１８】
図１０に関連して以下で説明されるパブリックキーとサーティフィケートの交換により、第１セキュリティコンテキスト５と時間ソース２との間に信頼された関係が確立可能である。
【０３１９】
ステップＳ１００１において、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂ、生成サーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖ、およびコンフィギュレーションサーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖが、第１セキュリティコンテキスト５からの問いあわせメッセージに応答して、基準時間ソース２から第１セキュリティコンテキスト５へ送信される。基準時間ソース２内のトランシーバ３９は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂおよび生成サーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖを、第１セキュリティコンテキスト５内の第１トランシーバ１３へ送信するように構成されている。時間ソースデバイスの状態に関連する情報は、同じメッセージ内で送信されてよい。デバイスの状態に関連する情報はまた、状態情報を認証するために、この場合生成サーティフィケート内に含まれる。
【０３２０】
ステップＳ１００２において、生成サーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖは、第１セキュリティコンテキスト５において検証される。第１セキュリティコンテキスト５内の第１プロセッサ１７は、生成サーティフィケート｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖを検証するように構成されている。生成サーティフィケートは、信用された製造業者キーのパブリックハーフＫｍａｎ  ｐｕｂを使って検証される。第１プロセッサ１７は、所与のサイン済みメッセージ｛ＣＴＳＩＤ｝Ｋｍａｎ  ｐｒｉｖおよびパブリックキーＫｍａｎ  ｐｕｂがメッセージの安全性の主張を受け入れるかまたは拒絶するサイン認証アルゴリズムを実行するよう構成されている。
【０３２１】
時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂの信頼性は、その後、第１セキュリティコンテキスト５において認証される。第１セキュリティコンテキスト５内の第１プロセッサ１７は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂを認証するように構成されている。生成サーティフィケートＣＴＳＩＤが時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂのハッシュを有するところの実施形態において、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂの信頼性は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂのハッシュを計算し、それが晴雨性サーティフィケートＣＴＳＩＤ内に含まれるものと一致することを認証することにより認証される。
【０３２２】
ステップＳ１００３において、第１セキュリティコンテキスト５はまた、メッセージ内に含まれる任意の状態情報から、デバイスの状態が要求に一致することを認証する。
【０３２３】
サインが検証され、かつ、キーおよび状態情報が検証されれば、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂは、第１セキュリティコンテキスト５内の第１デバイスメモリ９内に格納される。代替的に、それは、第１セキュリティコンテキスト５によってインテグリティ保護され、第１セキュリティコンテキスト５の外部の不信用ストレージ内に格納される。
【０３２４】
サインが検証されず、または、キーまたは状態情報が認証されなければ、エラーが時間ソース２にリターンされ、例えば、“AccessDenied”を記述するメッセージが送信される。この時点で、時間ソース２と第１セキュリティコンテキスト５との間の通信が終了する。
【０３２５】
上述したステップにおいて、第１セキュリティコンテキスト５は、基準時間ソース２によって、信用を確立する。したがって第１セキュリティコンテキスト５は、時間ソースへ安全な接続を作成し、かつ、その起源および信頼性をサーティフィケートチェーンを通じて認証することにより時間ソース２によって信用を確立する。
【０３２６】
信用が確立されると、第１セキュリティコンテキスト５は、ステップＳ１００４において時間ソース２からコンフィギュレーションおよび状態情報をリクエストする。第１セキュリティコンテキスト５内のトランシーバは、時間ソース２へ情報をリクエストするメッセージを送信する。
【０３２７】
ステップＳ１００５において、リクエストに応答して、時間ソース２は、クロックおよびセキュリティ設定に関する正確な情報を含む、時間ソース２のコンフィギュレーションを含むメッセージ、セットアップされた暗号プリミティブ、時間ソースが実行中のソフトウエアのバージョン、および、検出された任意の例外を含む時間ソースの状態を生成する。時間ソース内の第３プロセッサ４１は、コンフィギュレーション情報を生成するように構成されている。
【０３２８】
メッセージは、第２セキュリティコンテキスト７に送信されたメッセージを同じであってよい。代替的に、異なる情報を含むメッセージが、図２Ｂに関連して説明したものと類似の方法で生成されかつ送信されてもよい。メッセージは、基準時間ソースに適用される特定のコンフィギュレーションに関連する情報を有してよい。
【０３２９】
ステップＳ１００６において、応答メッセージが、時間ソースの識別キーのプライベートハーフＫＴＳＩＤ  ｐｒｉｖによってサインされる。時間ソース内の第３プロセッサ４１は、時間ソースの識別キーのプライベートハーフＫＴＳＩＤ  ｐｒｉｖによってメッセージを暗号化サインするように構成されている。
【０３３０】
ステップＳ１００７において、メッセージおよびサインは、第１セキュリティコンテキスト５に送信される。時間ソース２内のトランシーバ３９は、サイン済みのメッセージを第１セキュリティコンテキスト５に送信するように構成されている。
【０３３１】
ステップＳ１００８において、第１セキュリティコンテキスト５は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂを使って応答サインを検証する。第１セキュリティコンテキスト５内の第１プロセッサ１７は、サインを検証するように構成されている。サインは、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂを使って検証される。第１プロセッサ１７は、所与のサイン済みメッセージおよびパブリックキーＫＴＳＩＤ  ｐｕｂがメッセージの安全性の主張を受け入れるかまたは拒絶するサイン検証アルゴリズムを実行するように構成されている。
【０３３２】
ステップＳ１００９において、時間ソース構成および時間ソース状態が許容されるトレランス内にあるか否かに関するチェックが実行される。情報は、それがテナントの要求に一致することを認証するためにチェックされる。実施形態において、コンフィギュレーション情報は、第２セキュリティコンテキスト７へＫｔｅｎａｎｔを転送する直前にリクエストされかつチェックされる。これは、最新のコンフィギュレーション情報が認証されることを保証する。
【０３３３】
サインの認証が成功し、かつ、時間ソース２のコンフィギュレーションおよび状態がトレランス内にあれば、時間ソース２を同定する情報および時間ソースが信用されることを示す情報が、第１セキュリティコンテキスト５のデバイスメモリ９内に格納されるか、または、インテグリティ保護される方法で第１セキュリティコンテキスト５の外部に格納される。そうでなければ、エラーが時間ソース２にリターンされ、例えば“AccessDenied”を記述するメッセージが送信される。この時点で、時間ソース２と第１セキュリティコンテキスト５との間の通信は終了する。
【０３３４】
コンフィギュレーション情報は、タイムスタンプが第２セキュリティコンテキスト７によって要求されたタイムスタンプであるか否かを、コンフィギュレーション情報を再度要求することにより、再チェックされる。
【０３３５】
図１１は、本願発明の実施形態に従う暗号キーＫｔｅｎａｎｔの使用を制御する方法を示すフローチャートである。暗号キーＫｔｅｎａｎｔは、例えば使用サーティフィケートのような使用クレデンシャルが、暗号キーＫｔｅｎａｎｔの使用の第１のタイプを許可するために与えられなければならないことを特定するアクセスコントロールリストとともにサービスプロバイダー内に安全に格納される。
【０３３６】
代替的実施形態において、暗号キーＫｔｅｎａｎｔの代わりに、他の種類のデータがサービスプロバイダーシステム内に安全に格納され、このデータの使用がコントロールされる。アクセスコントロールリストは、データの第１のタイプの使用を許可するために有効使用サーティフィケートが与えられなければならないことを特定するデータと一緒に格納される。以下において、方法および装置はテナントキーの使用を参照して説明されるが、他の種類のデータがテナントキーと置換されてよく、同じ方法で使用可能である。
【０３３７】
インポートされたキーの使用を可能にするプロセスは、キー承認と呼ばれる。
【０３３８】
テナントが、サービスプロバイダーの暗号インフラストラクチャー内でそのキーを使用可能にしたいポイントにおいて、テナントは使用サーティフィケートを生成する。
【０３３９】
ステップＳ１１０１は、第１セキュリティコンテキスト５内で使用クレデンシャルを生成する工程を有する。実施形態において、使用クレデンシャルは、使用サーティフィケートである。第１セキュリティコンテキスト５内のプロセッサ１７は、使用サーティフィケートを生成するように構成される。使用サーティフィケートは、使用サービスプロバイダーに対応する暗号キーＫｔｅｎａｎｔを同定可能な情報、および、使用サーティフィケートの満期を決定可能な情報を有する。
【０３４０】
実施形態において、使用サーティフィケートに対応する暗号キーＫｔｅｎａｎｔを同定可能な情報は、Ｋｔｅｎａｎｔのハッシュを有する。
【０３４１】
実施形態において、使用サーティフィケートの満期を決定可能な情報は、満了時間および基準時間ソースを同定する情報を有する。満了時間は、第１セキュリティコンテキスト５および第２セキュリティコンテキスト７の両方によって信用される基準時間ソース２を参照して計算される。基準時間ソース内の信用は、基準時間ソースに独立に接続され、時間ソースが信用されること、および、時間ソースがサービスプロバイダーのモジュール状態パラメータを通じて改ざん防止されることを認証して、第１セキュリティコンテキスト５および第２セキュリティコンテキスト７によって確認される。これは、図９および図１０に関連して上述されており、キー転送の方法の前、または、例えばキー転送の後であってかつ使用サーティフィケートの生成前に実行されてよい。
【０３４２】
使用サーティフィケートは、安全な時間ソース２を参照する有効時間間隔に関連する情報を有する。
【０３４３】
したがって、キー承認は、クレデンシャルサーティフィケートを生成するテナントにより始まるか、または、“キーの使用”が、Ｋｔｅｎａｎｔのパーミション内で定義されたＡＣＬと一致することを認証する。換言すれば、使用サーティフィケートは、Ｋｔｅｎａｎｔに対応するアクセスコントロールリスト内で定義された要求を履行する。
【０３４４】
実施形態において、クレデンシャルサーティフィケート、または、使用サーティフィケートは、Ｋｔｅｎａｎｔ−ｓｉｇｎのプライベートハーフによってサインされる。
【０３４５】
図１２は、第１セキュリティコンテキスト５において使用サーティフィケートを生成する方法を示す。それは、本願発明の実施形態に従う暗号キーＫｔｅｎａｎｔの使用をコントロールする方法の一部である。
【０３４６】
ステップＳ１２０１において、基準時間ソース２が第１セキュリティコンテキスト５により選択される。ひとつ以上の時間ソースを同定する情報、および時間ソースが信用されることを示す情報は、第１セキュリティコンテキスト５のデバイスメモリ９内に格納されるか、または、インテグリティ保護される方法で、第１セキュリティコンテキストの外部に格納される。時間ソースのひとつは、第１セキュリティコンテキスト５によって選択される。
【０３４７】
時間ソース２は、第２セキュリティコンテキスト７によってブロードキャストされる信用済み時間ソースのリストから選択されてよく、それに対して第１セキュリティコンテキストが信用を確立する。したがって、第２セキュリティコンテキスト７および第１セキュリティコンテキスト５の両方は、リスト上のひとつ以上の時間ソースによって信用を確立する。これらの時間ソースの各々は、必要な構成および状態を有する有効時間ソースである。第１セキュリティコンテキストは、ひとつ以上の有効時間ソースのリストから、時間ソース２を選択する。
【０３４８】
ステップＳ１２０２において、第１セキュリティコンテキスト５は、選択した時間ソース２からカレントのタイムスタンプをリクエストする。第１セキュリティコンテキスト５内の第１トランシーバ１３は、時間ソース２へリクエストメッセージを送信する。
【０３４９】
ステップＳ１２０３において、時間ソース２は、タイムスタンプを含むメッセージを送信する。メッセージは、時間ソースを同定する情報、および、時間ソースクロックから決定される、メッセージ生成のカレント時刻を有する。時間ソースを同定する情報は、生成時間ソースの識別キーのパブリックＫＲＳＩＤ  ｐｕｂのハッシュを有してよい。
【０３５０】
メッセージはさらに、例えば時間ソースが改ざんされたことの指示に関連するカレントコンフィギュレーション情報を有する。その後、この情報は、使用サーティフィケート内でタイムスタンプを使用する前に、時間ソースが許容状態であるか否かをチェックするために、クライアントによって使用される。
【０３５１】
ステップＳ１２０４において、メッセージは、時間ソースの識別キーのプライベートハーフＫＴＤＩＤ  ｐｒｉｖによってサインされる。時間ソース内の第３プロセッサ４１は、時間ソースの識別キーのプライベートハーフＫＴＤＩＤ  ｐｒｉｖによってメッセージを暗号化サインするように構成される。
【０３５２】
ステップＳ１２０５において、メッセージおよびサインは、第１セキュリティコンテキスト５に送信される。時間ソース２内のトランシーバ３９は、サイン済みのメッセージを第１セキュリティコンテキスト５へ送信するように構成されている。
【０３５３】
ステップＳ１２０６において、第１セキュリティコンテキスト５は、時間ソースの識別キーのパブリックハーフＫＴＤＩＤ  ｐｕｂを使って応答サインを検証する。第１セキュリティコンテキスト５内の第１プロセッサ１７は、サインを検証するよう構成されている。サインは、時間ソースの識別キーのパブリックハーフＫＴＤＩＤ  ｐｕｂを使って検証される。第１プロセッサ１７は、所与のサイン済みメッセージおよびパブリックキーＫＴＤＩＤ  ｐｕｂが、メッセージの安全性の主張を受け入れるか拒否するサイン検証アルゴリズムを実行するように構成されている。サインの検証が成功すれば、方法はステップＳ１２０７に進む。成功しなければ、エラーが時間ソース２にリターンされ、例えば、“AccessDenied”を記述するメッセージが送信される。この時点で、時間ソース２と第２セキュリティコンテキスト７との間での通信は終了する。
【０３５４】
コンフィギュレーション情報がメッセージ内に含まれれば、第１セキュリティコンテキスト５は、コンフィギュレーションが許容されることを認証する。カレントコンフィギュレーション情報がテナントにとって許容できない場合、その後使用サーティフィケートの生成が停止される。
【０３５５】
ステップＳ１２０７において、テナントは、上述したタイムスタンプに基づいて、キーＫｔｅｎａｎｔに対する完了時間を計算する。満了時間は、タイムスタンプに、テナントがサーティフィケートがアクティブであることを望む時間間隔を足した時間、例えば、タイムスタンプと一日以上の日数の和として計算される。
【０３５６】
満了時間が通信遅延に比べて短い場合、通信遅延は例えば満了時間に因数分解される。この場合、満了時間は、タイムスタンプの時間、基準時間ソース２から第１セキュリティコンテキスト５までの通信遅延、第１セキュリティコンテキスト５から第２セキュリティコンテキスト７までの通信遅延、テナントがサーティフィケートがアクティブとなることを望む時間間隔の合計である。
【０３５７】
テナントがサーティフィケートがアクティブであることを望む時間間隔は、アプリケーションに応じて、例えば、数秒または数日であってよい。
【０３５８】
“開始時間”は、使用サーティフィケート内に含まれてよく、その結果、使用サーティフィケートは、サーティフィケートが有効である有効時間間隔を定義する。これにより、テナントは、使用に先立って、ひとつ以上のサービスプロバイダーを予め生成することができる。
【０３５９】
ステップＳ１２０８において、満了時間、時間ソース参照、Ｋｔｅｎａｎｔ参照および第２セキュリティコンテキスト７参照が、使用サーティフィケートに含まれる。
【０３６０】
時間ソースまたは第２セキュリティコンテキスト７のようなシステムコンポーネント参照は、サーティフィケートを使用しているものに付随するユニークなＩＤであってよく、または、その識別キーＫＩＤのパブリックハーフのハッシュであってよい。
【０３６１】
第１セキュリティコンテキスト５内のプロセッサ１７は、ステップＳ１２０７で計算された満了時間、時間ソース参照、Ｋｔｅｎａｎｔ参照、および第２セキュリティコンテキスト７参照を含む使用サーティフィケートを生成するように構成されている。
【０３６２】
実施形態において、Ｋｔａｎａｎｔ参照は、Ｋｔｅｎａｎｔのハッシュである。実施形態において、時間ソース２参照は、その識別キーＫＴＳＩＤ−ｐｕｂのパブリックハーフのハッシュである。実施形態において、第２セキュリティコンテキスト７参照は、その識別キーのパブリックハーフＫ２ＩＤ−ｐｕｂのハッシュである。
【０３６３】
図１１に戻って、使用サーティフィケートが生成されると、それは使用サーティフィケートの起源を同定可能な情報とともに発行される。実施形態において、使用サーティフィケートの起源を同定可能な情報はＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュである。
【０３６４】
ステップＳ１１０２において、使用サーティフィケートは、サインキーのプライベートハーフＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされる。第１セキュリティコンテキスト５内の第１プロセッサ１７は、サインキーのプライベートハーフＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサーティフィケートを暗号化サインするように構成されている。
【０３６５】
ステップＳ１１０３において、使用サーティフィケートは、使用サーティフィケートの起源を認証可能な情報とともに、サービスプロバイダーのアプリケーションサーバーへ送信される。使用サーティフィケートの起源を認証可能な情報はサイン、すなわち、サイン済みの使用サーティフィケートである。
【０３６６】
第１トランシーバ１３は、使用サーティフィケートをアプリケーションサーバーに送信するように構成されている。テナントキーを使用するこを望む他のエンティティーに、使用サーティフィケートが送信されてよい。これらのエンティティーは、第２セキュリティコンテキスト７と直接通信するか、または、アプリケーションサーバーを介して通信してよい。
【０３６７】
使用サーティフィケートの起源を同定可能な情報はまた、使用サーティフィケートとともに送信されてよい。使用サーティフィケートの起源を同定可能な情報は、Ｋｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュであってよい。使用サーティフィケートの起源を同定可能な情報は、サインを検証するのにどのサインキーを使用するべきかを同定するために含まれる。
【０３６８】
したがって、第１セキュリティコンテキスト５は、サービスプロバイダーへ、使用サーティフィケート、サイン、およびＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュを送信する。その後、サービスプロバイダーによるキーの各使用は、第２セキュリティコンテキスト７に対するこの情報のプレゼンテーションを伴う。
【０３６９】
ステップＳ１１０４において、使用サーティフィケート、サイン、および、Ｋｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュである使用サーティフィケートの起源を同定可能な情報は、アプリケーションサーバーにより、第２セキュリティコンテキスト７へ与えられる。使用サーティフィケートは、アプリケーションサーバーがＫｔｅｎａｎｔの使用を望むたびに与えられる。アプリケーションサーバーは、使用サーティフィケートとともに、要求されるテナントキーの使用を特定するリクエストメッセージを送信する。例えば、アプリケーションサーバーは、データファイル、第２セキュリティコンテキスト７がテナントキーによってデータファイルを暗号化することのリクエスト、使用サーティフィケート、および、Ｋｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュである、使用サーティフィケートの起源を同定可能な情報を有するメッセージを、第２セキュリティコンテキスト７へ送る。
【０３７０】
第２セキュリティコンテキスト７は、例えば、異なるテナントに関連する多くのパブリックキーに対してアクセスを有してよい。キーは、第２セキュリティコンテキスト７に格納されるか、または、認証済みの方法で第２セキュリティコンテキスト７の外部に可能される。第２セキュリティコンテキスト７は、Ｋｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュである使用サーティフィケートの起源を同定可能な情報に基づいて、正しいサイン検証キーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂを識別する。その後、サイン済みサーティフィケートは、第２セキュリティコンテキスト７において検証される。第２セキュリティコンテキスト７内の第２プロセッサ１９は、サインを検証するように構成されている。サインは、サインキーのパブリックハーフＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂを使って検証される。第２のプロセッサ１９は、所与のサイン済み使用サーティフィケートおよびパブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂがメッセージの安全性の主張を受け入れるか拒否するサイン検証アルゴリズムを実行するように構成されている。サインの検証が成功すれば、方法はステップＳ１１０５に進む。成功しなければ、エラーが第１セキュリティコンテキスト５にリターンされる。例えば“AccessDenied”を記述するメッセージが送信される。この時点で、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の通信が終了する。
【０３７１】
ステップＳ１１０５において、第２セキュリティコンテキスト７は、第２デバイスメモリ１１内に格納されたアクセスコントロールリストに関する使用サーティフィケートを認証する。このステップの一部として、使用サーティフィケートが満了していないことが認証される。使用サーティフィケートは要求されたオペレーションを許可したこと、換言すれば、使用サーティフィケートが要求されるオペレーションまたは使用に対応するパーミションに関連するクレデンシャルと一致することが認証される。第２プロセッサ１９は、使用サーティフィケートを認証するように構成される。例えば、サーティフィケートによって示される改ざんのためにサーティフィケートが無効であるか、期限満了であるか、または、ＡＣＬが要求されたオペレーションを許可しなければ、第２セキュリティコンテキスト７はエラーメッセージをアプリケーションサーバーにリターンする。
【０３７２】
第２セキュリティコンテキスト７は、使用サーティフィケート内のＫｔｅｎａｎｔ参照から、使用サーティフィケートに対応する安全に格納されたテナントキーを同定する。
【０３７３】
第２セキュリティコンテキストは、安全に格納されたテナントキーおよびＡＣＬをロードする。テナントキーのロードにより、第２セキュリティコンテント７内のプロセッサが利用可能となる。すなわち、すでに存在していなければ、デバイスメモリ９へテナントキーおよびＡＣＬを送信する。これは、第２セキュリティコンテキスト７の外部の不揮発性メモリデバイスからテナントキーおよびＡＣＬをロードすること、キーを暗号化すること、および、それを第２プロセッサで使用可能にすることを含む。
【０３７４】
この時点で、第２セキュリティコンテキスト７は使用サーティフィケート、および、基準時間ソースに関して満了時間に達していないことを認証する。第２セキュリティコンテキスト７は、与えられたすべてのフィールドが予想通りであることを認証することにより、マッチングパーミッションを可能するべく使用サーティフィケートを使用する。
【０３７５】
第２プロセッサ１９は、Ｋｔｅｎａｎｔ参照および第２セキュリティコンテキスト７参照が、キーＫｔｅｎａｎｔに対応するＡＣＬ内のもの、および、第２デバイスメモリ１１内の格納されているものと一致することを確認するように構成されている。実施形態において、Ｋｔｅｎａｎｔ参照は、Ｋｔｅｎａｎｔのハッシュである。実施形態において、第２セキュリティコンテキスト７参照は、識別キーのパブリックハーフＫ２ＩＤ  ｐｕｂのハッシュである。
【０３７６】
Ｋｔｅｎａｎｔ参照および第２セキュリティコンテキスト７参照がＡＣＬ内のものと一致すれば、有効期間が満了したか否かが確認される。もし一致しなければ、エラーがアプリケーションサーバーにリターンされる。例えば、“CertificateExpired”を記述するメッセージが送信される。
【０３７７】
第２プロセッサ１９はまた、参照された時間ソース２に関して有効時間間隔が満了していないことを確認するように構成されている。実施形態において、第２セキュリティコンテキスト７は、使用サーティフィケート内の参照に対応する時間ソース２からカレントタイムスタンプを要求する。第２セキュリティコンテキスト７内の第２トランシーバ１５は、時間ソース２へリクエストメッセージを送信するように構成されている。リクエストメッセージに応答して、時間ソース２は、カレントタイムスタンプを含むメッセージを生成する。メッセージは、時間ソースの識別キーのプライベートハーフＫＴＳＩＤ  ｐｒｉｖによりサインされる。時間ソース内の第３プロセッサ４１は、時間ソースの識別キーのプライベートハーフＫＴＳＩＤ  ｐｒｉｖにより、メッセージを暗号サインするように構成されている。その後、サイン済みメッセージは第２セキュリティコンテキスト７へ送信される。時間ソース２内のトランシーバ３９は、第２セキュリティコンテキスト７へサイン済みメッセージを送信するように構成されている。メッセージはまた、時間ソースのカレントのコンフィギュレーション情報を有する。
【０３７８】
その後、第２セキュリティコンテキスト７は、時間ソースの識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂを使って、応答サインを検証する。第２セキュリティコンテキスト７内の第２プロセッサ１９は、サインを検証するように構成されている。サインは、時間曽於―すなわち、の識別キーのパブリックハーフＫＴＳＩＤ  ｐｕｂを使って検証される。第２プロセッサ１９は、所与のサイン済みメッセージおよびパブリックキーＫＴＳＩＤ  ｐｕｂがメッセージの安全性の主張を受け入れるかまたは拒否するサイン検証アルゴリズムゴリを実行するように構成されている。
【０３７９】
サインの認証が成功すれば、使用サーティフィケートが満了したか否かを判定するべく、カレントタイムスタンプは使用サーティフィケートに含まれる満了時間と比較される。もし成功しなければ、エラーがアプリケーションサーバーにリターンされ、例えば“AccessDenied”を記述するメッセージが送信される。この時点で、第１セキュリティコンテキスト５と第２セキュリティコンテキスト７との間の通信が終了する。
【０３８０】
もし時間ソース２から受信したカレントタイムスタンプが使用サーティフィケート内に含まれる満了時間の前であれば、方法はステップＳ１１０６へ進む。そうでなければ、エラーがアプリケーションサーバーにリターンされる。例えば、“CerfufucateExpired”を記述するメッセージが送信される。その後、アプリケーションサーバーは、新しいサーティフィケートを与えるか、または、オペレーションを単純に終了することを、第１セキュリティコンテキスト５にリクエストする。
【０３８１】
ステップＳ１１０６において、第２セキュリティコンテキスト７は、使用サーティフィケートが有効であり、かつ、満了していないことの条件のもとで、暗号キーＫｔｅｎａｎｔの使用を許可する。サーティフィケートが有効であり、かつ、満了時間にまだ達していなければ、暗号オペレーションの進行が許可される。第２セキュリティコンテキスト７は、有効時間間隔でタレントキーを使用することができる。第２セキュリティコンテキスト７は、要求された使用に対応するＡＣＬ内で必要なパーミションをアクティブにし、リクエストを許可するアクティブなパーミション用にＡＣＬをチェックする。その後、第２セキュリティコンテキスト７は、リクエストされたオペレーションを実行し、アプリケーションサーバーに結果をリターンする。例えば、アプリケーションサーバーが、データファイル、および、第２セキュリティコンテキスト７がテナントキーによってデータファイルを暗号化することのリクエストを有するメッセージを送信した場合、第２セキュリティコンテキスト７はテナントキーによってデータファイルを暗号化し、かつ、暗号化したデータファイルをアプリケーションサーバーにリターンする。
【０３８２】
期限満了の時点またはその前に、テナントは、キーの満了時間を延長するべく新しいサーティフィケートを生成する。新しいサーティフィケートの生成が失敗すると、サービスプロバイダーによりキーは使用不能となる。実施形態において、第２セキュリティコンテキスト７は、使用サーティフィケートの満了前または満了時点で、第１セキュリティコンテキスト５に通知する。その後、新しい使用サーティフィケートが後の満了時間とともに第１セキュリティコンテキストにおいて生成される。代替的に、第２セキュリティコンテキスト７は、使用サーティフィケートの満了前または満了時点で、アプリケーションサーバーに通知する。その後、アプリケーションサーバーは第１セキュリティコンテキスト５から新しい使用サーティフィケートをリクエストする。代替的に、使用サーティフィケートは、アプリケーションサーバーによって読み出され、それは、満了前または満了時点で、第１セキュリティコンテキスト５から新しい使用サーティフィケートをリクエストする。代替的に、テナントまたはサービスプロバイダーによって所有される他のコンポーネントは、サーティフィケートをモニターし、満了に近いかまたは満了したサーティフィケートのリクエストをレイズする。
【０３８３】
したがって、テナントシステム１は、安全な方法で、サービスプロバイダーシステム３に対して暗号キーＫｔｅｎａｎｔを効果的に貸与する。サービスプロバイダーによるキーの使用は、使用サーティフィケート内でテナントの所有者によって設定されるように、信用された時間ソースを参照する満了時間によって暗号的に制限される。ＡＣＬは、暗号キーＫｔｅｎａｎｔの使用が、未満了の使用サーティフィケートが与えられるときにのみ許可されることを特定する。また、テナントは、サービスプロバイダーによってどのようなキーが使用されるかを制限することができる。
【０３８４】
図１３は、本願発明の実施形態に従う暗号キーＫｔｅｎａｎｔの使用をコントロールする方法の略示図である。
【０３８５】
この方法は、テナントキーが第２セキュリティコンテキスト７において使用されており、かつ、満了時間に達した場合に対応する。第２セキュリティコンテキスト７またはアプリケーションサーバーは、基準時間ソース２から得られたカレント時間を使用サーティフィケート内の満了時間と周期的に比較し、この情報からサーティフィケートが満了したか否かを判定する。代替的に、第２セキュリティコンテキスト７が、満了したサーティフィケートを使用するリクエストが作成されたときにのみ、サーティフィケートが満了したことを判定してもよい。第２セキュリティコンテキスト７は、第１セキュリティコンテキスト５、アプリケーションサーバーまたは他のデバイスに、キーがタイムアウトしたことを通知してもよい。
【０３８６】
第１セキュリティコンテキスト５は、上述したステップＳ１２０２に関連して上述したようなカレントタイムスタンプを要求して、通知に応答して時間ソース２へリクエストメッセージを送信するように構成される。
【０３８７】
時間ソース２は、ステップＳ１２０３からＳ１２０５に関連して上述したように、時間情報を有するメッセージを生成しかつ送信するように構成される。
【０３８８】
メッセージは、ステップＳ１２０６に関連して上述したように第１セキュリティコンテキスト５において検証され、ステップＳ１２０７からＳ１２０８に関連して上述したように使用サーティフィケートが生成され、かつ、ステップＳ１１０２に関連して上述したようにサインされる。使用サーティフィケートはステップＳ１１０３に関連して上述したようにサービスプロバイダーに送信され、ステップＳ１１０４に関連して上述したように、第２セキュリティコンテキスト７へ送信され、かつ、第２セキュリティコンテキスト７において検証される。使用サーティフィケートに対応する格納されたテナントキーがロードされ、ステップＳ１１０１に関連して上述したように、時間ソース２からカレントのタイムスタンプが得られかつ認証される。テナントキーのロードにより、プロセッサにより利用可能となる。すなわち、すでに存在していなければ、デバイスメモリ９へ送信される。これは、第２セキュリティコンテキスト７の外部の不揮発性メモリデバイスからタレントキーをロードすること、キーを解読すること、および、プロセッサにそれを使用可能にすることを含む。その後、キーは、ステップＳ１１０６に関連して上述しようにアクティブ化される。
【０３８９】
図１４は、本願発明の実施形態に従う、暗号キーＫｔｅｎａｎｔの使用をコントロールする方法の略示図である。
【０３９０】
最初のステップにおいて、第１セキュリティコンテキスト５は、時間ソース、状態、および、時間の生成サーティフィケートを時間ソース２から得る。その後、生成サーティフィケートおよびタイムスタンプサインは、第１セキュリティコンテキスト５において検証される。これは、ステップＳ１２０１からＳ１２０６に関連して上述した。
【０３９１】
生成サーティフィケートおよびタイムスタンプサインが認証されれば、その後方法は、次のステップ“承認サーティフィケートの生成”に進む。認証されなければ、エラーがリターンされる。
【０３９２】
使用サーティフィケートは、ステップＳ１２０７およびＳ１２０８に関連して上述したように生成される。その後、使用サーティフィケートは、ステップＳ１１０３に関連して上述したように第２セキュリティコンテキスト７へ送信される。
【０３９３】
上述したステップは、すべてのキー材料がテナントと第２セキュリティコンテキスト７との間で暗号化されるので、サードパーティーおよび悪意のサービスプロバイダーによる攻撃に対して安全であるシステムを画定し、テナントキー材料は安全で、改ざん不可能なフォーマットで格納され、テナントキーは暗号的に行使される方法でテナントによって承認されたときにのみ信用され、コンポーネントスプーフィングは、識別キーＫＩＤ、およびテナントおよびサービスプロバイダーの両方によって信用される製造業者によってサインされた生成サーティフィケートの存在により防止される。
【０３９４】
上述したキー転送方法およびキーの使用をコントロールする方法は、テナントが、既知の起源の共有暗号インフラストラクチャーをホストしているサービスプロバイダーへ、暗号キーを安全に貸与することができることを意味する。テナントキーの使用は、暗号化保護された方法でテナントのコントロールの下にある。
【０３９５】
キー転送方法の一部として、テナントは、自己ホストの安全なアライアンスである第１セキュリティコンテキスト内部でキーを生成する。
【０３９６】
テナントのソースアライアンスである第１セキュリティコンテキスト５は、インフラストラクチャーが信用された製造業者を使って製造され、テナントに受け入れられる方法で構成され、かつ、キーを貸与するのに適していることを認証することにより、選択されたサービスプロバイダーである第２セキュリティコンテキスト７によってホストされる暗号インフラストラクチャーが、テナントによって受け入れられるルールのセットを遵守することを認証する。図２Ａに関連して上述したステップＳ２０５は、インフラストラクチャーが信用された製造業者を使って製造されることの認証を許可する。生成サーティフィケートＣ２ＩＤのサインが検証されれば、その後、第２セキュリティコンテキストが信用された製造業者により製造されたことが認証される。図２Ｂに関連して上述したステップＳ２１５は、テナントに受け入れられかつキーの貸与に適した方法で、インフラストラクチャーが構成されていることの認証を許可する。
【０３９７】
さらに、テナントおよびサービスプロバイダーの暗号インフラストラクチャーは、テナントによって設定されたキー満了時間を行使するよう、信用された時間ソース２を使用し、それは、サードパーティーによってホストされてもよい。
【０３９８】
上述したデバイスおよび方法により、複数のテナントの、ホストされた暗号ソリューションが、ＣＳＰによって与えられることができる。システムは、サードパーティーおよびＣＳＰ自身の両方による攻撃に対して安全であるように設計される。テナントはキーのコントロール内に残って使用の許可を与え、それは、ＣＳＰホストされたシステム内部での使用のために暗号化行使される。これは、ＨＳＭの複数テナントおよびサービスプロバイダーの暗号インフラストラクチャーへ転送されたキーに対する保証の両方を許可する。筆以上のテナントは、単一の暗号アプライアンスを使用できるが、テナントキーのセキュリティは、サードパーディーおよびサービスプロバイダーの両方から保護される。
【０３９９】
上述したデバイスおよび方法により、テナントは、ＣＳＰセキュリティコンテキスト内部のキーの使用に対するコントロールを維持したまま、サービスプロバイダーおよびサードパーティーにアクセス不可能な方法でサービスプロバイダーのインフラストラクチャー内部で使用される暗号キーを検証可能に貸与することができる。これにより、悪意または面倒な管理者の攻撃に対抗しつつ、設定時間間隔の間にサービスプロバイダーＨＳＭ内部で使用するためにテナントキーの使用を制限する能力とともに、テナントおよびサービスプロバイダー間での暗号キーの安全な貸与が可能になる。これは、暗号化行使する方法で、ＣＳＰへキーの貸与を許可する。これにより、サービスプロバイダーは、悪意のＣＳＰに対してロバストであるとともに、サードパーティーの攻撃に対してロバストである複数テナントのサービスをホストすることができる。テナントキーの使用がテナントによりコントロールされることを暗号的に行使することは、キーの使用がテナントによって完全にコントロールされることを保証し、攻撃に対してサービスを安全にし、かつ、他とインフラストラクチャーの共有を可能にする。
【０４００】
上述したデバイスおよび方法により、ＣＳＰは、支払い、セキュリティおよびレギュレーションなどのアプライアンスに対する暗号インフラストラクチャーのテナントの使用を与えることができる。
【０４０１】
第２セキュリティコンテキスト７は、サービスプロバイダーシステムの一部であり、例えばＣＳＰなどのサービスプロバイダーは、顧客を代表して、ハードウエアセキュリティモジュールＨＳＭを介して暗号サービスをホストすることができる。
【０４０２】
ある実施形態が説明されてきたが、これらの実施形態は、例示に過ぎず、本願発明の範囲を限定することを意図しない。ここで説明した新規な方法および装置は他の様々な形式で実施可能である。また、ここで説明した方法および装置の形式のさまざまな省略、置換および変更が本願発明の思想から離れることなく可能である。添付する特許請求の範囲およびその均等範囲が、その形式の修正を本願発明の思想および態様の範囲内であるとしてカバーする。 
【図１Ａ】
2019509667.tif 000003
【図１Ｂ】
2019509667.tif 000004
【図２Ａ】
2019509667.tif 000005
【図２Ｂ】
2019509667.tif 000006
【図３】
2019509667.tif 000007
【図４Ａ】
2019509667.tif 000008
【図４Ｂ】
2019509667.tif 000009
【図５】
2019509667.tif 000010
【図６Ａ】
2019509667.tif 000011
【図６Ｂ】
2019509667.tif 000012
【図７Ａ】
2019509667.tif 000013
【図７Ｂ】
2019509667.tif 000014
【図８Ａ】
2019509667.tif 000015
【図８Ｂ】
2019509667.tif 000016
【図９】
2019509667.tif 000017
【図１０】
2019509667.tif 000018
【図１１】
2019509667.tif 000019
【図１２】
2019509667.tif 000020
【図１３】
2019509667.tif 000021
【図１４】
2019509667.tif 000022
【手続補正書】
【提出日】平成30年10月3日(2018.10.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
テナントシステム内の第１セキュリティコンテキストと、サービスプロバイダーシステム内の第２セキュリティコンテキストとの間でデータ転送する方法であって、当該方法は、
第１セキュリティコンテキスト内のデータに対応するアクセスコントロールリストを生成する工程であって、前記アクセスコントロールリストは、有効使用クレデンシャルが前記データの使用の第１のタイプを許可するために与えられなければならないことを特定する、ところの工程と、
第１暗号キーペアおよび第１暗号サーティフィケートを前記第２セキュリティコンテキスト内で生成する工程であって、前記第１暗号キーペアは、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを有し、前記第１暗号サーティフィケートは前記第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報を含むところの工程と、
前記第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび前記第１暗号サーティフィケートを前記第１セキュリティコンテキストに送信する工程と、
前記第１セキュリティコンテキスト内で前記第１暗号サーティフィケートを認証する工程と、
前記第１暗号サーティフィケートが有効であれば、前記第１セキュリティコンテキスト内で、前記第１パブリックキーＫＢＬＯＢ  ｐｕｂによって前記データおよび前記対応するアクセスコントロールリストを暗号化する工程と、
前記暗号化したデータおよび対応するアクセスコントロールリスト、および、前記データの起源を認証可能な情報を、前記第２セキュリティコンテキストへ送信する工程と
を備える方法。
【請求項２】
前記データは、暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１セキュリティコンテキスト内で前記暗号キーＫｔｅｎａｎｔを生成する工程をさらに備える、請求項２に記載の方法。
【請求項４】
前記第２セキュリティコンテキストにおいて、前記暗号キーＫｔｅｎａｎｔの起源を認証する工程と、
前記暗号化した暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストを、前記第１プライベートキーＫＢＬＯＢ  ｐｒｉｖによって、前記第２セキュリティコンテキストにおいて解読する工程と
をさらに備える請求項３に記載の方法。
【請求項５】
前記第２セキュリティコンテキストにおいて、他の暗号キーによって前記暗号キーＫｔｅｎａｎｔを再暗号化する工程であって、前記他の暗号キーは前記第２セキュリティコンテキストを離れることができない、ところの工程と、
前記再暗号化された暗号キーＫｔｅｎａｎｔ、対応するアクセスコントロールリスト、および、暗号キーＫｔｅｎａｎｔの起源を認証可能な情報を格納する工程と
をさらに備える請求項４に記載の方法。
【請求項６】
前記使用の第１のタイプは、ひとつ以上の暗号オペレーションである、ことを特徴とする請求項２から５のいずれか一項に記載の方法。
【請求項７】
前記第２セキュリティコンテキストが信用される製造業者によって製造されたものであること、前記第２セキュリティコンテキストのコンフィギュレーションが前記テナントのセキュリティ要求に一致すること、および、前記第２セキュリティコンテキストがＡＣＬ内に含まれるポリシーを行使するように構成されていることを、前記第１セキュリティコンテキストにおいて認証する工程をさらに備える請求項２から６のいずれか一項に記載の方法。
【請求項８】
前記第２セキュリティコンテキストが第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖを格納する請求項２から７のいずれか一項に記載の方法であって、当該方法は、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別サーティフィケートを、前記第２セキュリティコンテキストから前記第１セキュリティコンテキストへ送信する工程であって、前記第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖは、暗号キーペアであり、前記第２識別サーティフィケートはＫ２ＩＤ  ｐｕｂを同定する情報を有し、かつ、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされる、ところの工程をさらに備える方法。
【請求項９】
前記第２セキュリティコンテキストのカレントのコンフィギュレーションに関連する情報を生成する工程と、
前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖにより、前記情報を暗号化サインする工程と、
サイン済みの情報を前記第２セキュリティコンテキストから前記第１セキュリティコンテキストへ送信する工程と
をさらに備える請求項８に記載の方法。
【請求項１０】
前記第１暗号サーティフィケートは、前記第２セキュリティコンテキストのカレントのコンフィギュレーションに関連する情報を有し、かつ、前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによってサインされる、ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記第１セキュリティコンテキストが第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖを格納するところの請求項８から１０のいずれか一項に記載の方法であって、当該方法は、
第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを前記第１セキュリティコンテキストから前記第２セキュリティコンテキストへ送信する工程であって、前記第１識別プライベートキーＫ１ＩＤ  ｐｕｂおよび前記第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖは暗号キーペアであり、前記第１識別サーティフィケートは、Ｋ１ＩＤ  ｐｕｂを同定する情報を有し、かつ、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされる、ところの工程をさらに備える方法。
【請求項１２】
第２暗号キーペアおよび第２暗号サーティフィケートを前記第１セキュリティコンテキスト内で生成する工程であって、前記第２暗号キーペアは第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂ、および、第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖを有し、前記第２暗号サーティフィケートは前記第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を同定可能な情報を有する、ところの工程と、
前記第２暗号サーティフィケートを前記第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖによって暗号化サインする工程と、
前記第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびサイン済み前記第２暗号サーティフィケートを前記第２セキュリティコンテキストへ送信する工程と、
前記第２暗号サーティフィケートを、前記第１識別プライベートキーＫ１ＩＤ  ｐｕｂを使って検証する工程と
をさらに備える請求項１１に記載の方法。
【請求項１３】
前記アクセスコントロールリストは、前記使用クレデンシャルが、前記暗号キーＫｔｅｎａｎｔの前記第１のタイプの使用を許可するために、前記第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされる使用サーティフィケートであることを特定する、ことを特徴とする請求項１２に記載の方法。
【請求項１４】
前記暗号キーＫｔｅｎａｎｔの起源を認証可能な前記情報は、暗号化された暗号キーＫｔｅｎａｎｔ、およびＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによってサインされた対応するアクセスコントロールリストを有する、ことを特徴とする請求項１２または１３に記載の方法。
【請求項１５】
前記暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、暗号キーＫｔｅｎａｎｔの起源を認証可能な情報を前記第２セキュリティコンテキストへ送信する工程は、
暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリストをＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによって暗号化サインする工程と、
前記暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、前記暗号化された暗号キーＫｔｅｎａｎｔおよび対応するアクセスコントロールリスト、および、Ｋｔｅｎａｎｔ−ｓｉｇｎｐｕｂのハッシュを、前記第２セキュリティコンテキストへ送信する工程と
を有する、ことを特徴とする請求項１４に記載の方法。
【請求項１６】
前記アクセスコントロールリストは、前記使用クレデンシャルが、前記使用クレデンシャルの満期を決定可能な情報を有しなければならず、かつ、有効であるために満了前でなければならないことを特定する、ことを特徴とする請求項２から１５のいずれか一項に記載の方法。
【請求項１７】
前記アクセスコントロールリストは、前記暗号キーＫｔｅｎａｎｔが、前記第２セキュリティコンテキストを離れることができないキーによって第２セキュリティコンテキストの外部に格納用にのみ暗号化されることを特定する、ことを特徴とする請求項２から１６のいずれか一項に記載の方法。
【請求項１８】
前記第１暗号サーティフィケートは、ＫＢＬＯＢ  ｐｒｉｖが一時的なものであること、ＫＢＬＯＢ  ｐｒｉｖが前記第２セキュリティコンテキストを離れることができないことを認証する、ことを特徴とする請求項２から１７のいずれか一項に記載の方法。
【請求項１９】
請求項１から１８のいずれか一項に記載の方法を、コンピュータに実行させるように構成された、コンピュータ読み取り可能コードを有するキャリア媒体。
【請求項２０】
第１セキュリティコンテキストを有する暗号デバイスであって、前記第１セキュリティコンテキストは、
第１パブリックキーＫＢＬＯＢ  ｐｕｂ、および、前記第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な第１暗号サーティフィケートを、第２セキュリティコンテキストから受信するように構成された第１トランシーバと、
暗号オペレーションを実行するように構成された第１プロセッサであって、前記第１プロセッサは、
転送されるべきデータに対応するアクセスコントロールリストを生成し、ここで前記アクセスコントロールリストは、有効使用クレデンシャルが前記データの使用の第１のタイプを許可するために与えられなければならず、
前記第１パブリックキーＫＢＬＯＢ  ｐｕｂが前記第２セキュリティコンテキストを起源とすることを認証し、
前記データおよび前記対応するアクセスコントロールリストを前記第１パブリックキーＫＢＬＯＢ  ｐｕｂによって暗号化する
ように構成されており、
前記第１トランシーバは、前記暗号化されたデータおよび対応するアクセスコントロールリスト、および、前記データの起源を認証可能な情報を前記第２セキュリティコンテキストへ送信するように構成されている、ことを特徴とするデバイス。
【請求項２１】
前記データは、暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項２０に記載のデバイス。
【請求項２２】
第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖを格納する第１デバイスメモリをさらに備え、前記第１トランシーバはさらに、
第１識別プライベートキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを前記第２セキュリティコンテキストへ送信し、ここで、前記第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび前記第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖは暗号キーペアであり、前記第１識別サーティフィケートは、Ｋ１ＩＤ  ｐｕｂを同定する情報を有し、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされ、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別サーティフィケートを前記第２セキュリティコンテキストから受信し、前記第２識別サーティフィケートは、Ｋ２ＩＤ  ｐｕｂを同定する情報を有し、かつ、前記製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされる
ように構成されており、
前記第１プロセッサは、前記製造業者パブリックキーＫｍａｎ  ｐｒｉｖを使って前記第２識別サーティフィケートを検証するようにさらに構成されている、ことを特徴とする請求項２１に記載のデバイス。
【請求項２３】
前記第１トランシーバはさらに、
前記第２セキュリティコンテキストのカレントコンフィギュレーションに関連する情報を受信するように構成され、前記情報は第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによって暗号化サインされ、前記第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖは暗号キーペアであり、
前記第１プロセッサは、
前記第２識別パブリックキーＫ２ＩＤ  ｐｕｂを使って前記サインを検証し、
前記第２セキュリティコンテキストの前記コンフィギュレーションが前記テナントの安全要求に一致すること、および、前記第２セキュリティコンテキストが前記ＡＣＬ内の含まれる前記ポリシーを行使するように構成されていることを認証する
ようにさらに構成されている、ことを特徴とする請求項２２に記載のデバイス。
【請求項２４】
前記第１プロセッサは、さらに
第２暗号キーペアおよび第２暗号サーティフィケートを前記第１セキュリティコンテキスト内で生成するように構成され、前記第２暗号キーペアは、第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよび第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖを有し、前記第２暗号サーティフィケートは、前記第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を同定可能な情報を有し、
前記第２暗号サーティフィケートを前記第１識別プライベートキーＫ１ＩＤ  ｐｒｉｖによって暗号化サインするよう構成され、
前記第１トランシーバは、前記第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよび前記サインされた第２暗号サーティフィケートを前記第２セキュリティコンテキストへ送信するようにさらに構成されている、ことを特徴とする請求項２３に記載のデバイス。
【請求項２５】
第１セキュリティコンテキストを有するデバイスと協働する、第２セキュリティコンテキストを有する暗号デバイスであって、前記暗号デバイスは、
暗号オペレーションを実行するように構成されたプロセッサであって、前記プロセッサは、第１暗号キーペアおよび第１暗号サーティフィケートを生成するように構成され、前記第１暗号キーペアは、第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを有し、前記第１暗号サーティフィケートは、前記第１パブリックキーＫＢＬＯＢ  ｐｕｂの起源を認証可能な情報を有する、ところのプロセッサと、
トランシーバであって、前記第１パブリックキーＫＢＬＯＢ  ｐｕｂおよび前記第１暗号サーティフィケートを第１セキュリティコンテキストに送信し、かつ
暗号化されたデータおよび対応するアクセスコントロールリスト、および、前記データの起源を認証可能な情報を前記第１セキュリティコンテキストから受信するように構成されているトランシーバと、
を備え、
前記プロセッサはさらに、
前記データの起源を認証し、かつ、前記第１プライベートキーＫＢＬＯＢ  ｐｒｉｖを使って、前記暗号化されたデータおよび対応するアクセスコントロールリストを解読するように構成されている、ことを特徴とするデバイス。
【請求項２６】
前記データは、暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項２５に記載のデバイス。
【請求項２７】
前記プロセッサはさらに、前記暗号キーＫｔｅｎａｎｔを他の暗号キーによって再暗号化するように構成され、前記他の暗号キーは前記第２セキュリティコンテキストを離れることができない、ことを特徴とする請求項２６に記載のデバイス。
【請求項２８】
第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖを格納するデバイスメモリをさらに備え、
前記トランシーバはさらに、
第２識別パブリックキーＫ２ＩＤ  ｐｕｂおよび第２識別サーティフィケートを前記第１セキュリティコンテキストへ送信するように構成され、前記第２識別パブリックキーＫ２ＩＤ  ｐｕｂはおよび前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖは暗号キーペアであり、前記第２識別サーティフィケートは、Ｋ２ＩＤ  ｐｕｂを同定する情報を有し、かつ、製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号化サインされ、
第１識別パブリックキーＫ１ＩＤ  ｐｕｂおよび第１識別サーティフィケートを前記第１セキュリティコンテキストから受信するように構成され、前記第１識別サーティフィケートはＫ１ＩＤ  ｐｕｂを同定する情報を有し、かつ、前記製造業者プライベートキーＫｍａｎ  ｐｒｉｖによって暗号サインされ、
前記プロセッサはさらに、前記製造業者パブリックキーＫｍａｎ  ｐｕｂを使って前記第１識別サーティフィケートを検証するように構成されている、ことを特徴とする請求項２７に記載のデバイス。
【請求項２９】
前記プロセッサはさらに、
前記第２セキュリティコンテキストの前記カレントコンフィギュレーションに関連する情報を生成し、かつ、前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによって前記情報を暗号化サインするように構成され、
前記トランシーバはさらに、前記情報およびサインを前記第１セキュリティコンテキストへ送信するように構成されている、ことを特徴とする請求項２８に記載のデバイス。
【請求項３０】
前記プロセッサはさらに、前記第２セキュリティコンテキストの前記カレントコンフィギュレーションに関連する情報を有する前記第１暗号サーティフィケートを生成し、かつ、前記第１暗号サーティフィケートを前記第２識別プライベートキーＫ２ＩＤ  ｐｒｉｖによってサインするように構成されている、ことを特徴とする請求項２９に記載のデバイス。
【請求項３１】
前記トランシーバはさらに、
第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂおよびサインされた第２暗号サーティフィケートを前記第２セキュリティコンテキストから受信するように構成され、前記第２暗号サーティフィケートは、前記第２パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証可能な情報を有し、
前記プロセッサはさらに、前記第２プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂの起源を認証するように構成されている、ことを特徴とする請求項２８から３０のいずれか一項に記載のデバイス。
【請求項３２】
サービスプロバイダー内の信用された第２セキュリティコンテキストにはアクセス可能であるが、残りのサービスプロバイダーシステムからは安全であるような方法でサービスプロバイダー内に格納されたデータの使用をコントロールする方法であり、アクセスコントロールリストは、格納されたデータの使用の第１のタイプ許可するために、有効使用クレデンシャルが前記データにより与えられなければならないことを特定する方法であって、
使用クレデンシャルを第１セキュリティコンテキスト内で生成する工程であって、前記使用クレデンシャルは、
前記使用クレデンシャルに対応するデータを同定可能である情報、および
前記使用クレデンシャルの満期を判定する情報を有する、ところの工程と、
前記使用クレデンシャル、および前記使用クレデンシャルの起源を認証可能な情報を発行する工程と、
前記アクセスコントロールリストに関して前記使用クレデンシャルを認証し、かつ、前記使用クレデンシャルが前記第２セキュリティコンテキストにおいて満了しなかったことを認証する工程と、前記データの使用の前記第１のタイプを、前記第２セキュリティコンテキスト内で、前記使用クレデンシャルが有効でありかつ満了していないことを条件に許可する工程と
を備える方法。
【請求項３３】
前記データは、暗号キーＫｔｅｎａｎｔを有する、ことを特徴とする請求項３２に記載の方法。
【請求項３４】
前記使用の第１のタイプは、ひとつ以上の暗号オペレーションである、ことを特徴とする請求項３３に記載の方法。
【請求項３５】
前記使用クレデンシャル、および前記使用クレデンシャルの起源を認証可能な情報は、前記サービスプロバイダーに発行され、当該方法は、
前記使用クレデンシャル、および、前記使用クレデンシャルの起源を認証可能な情報、および、前記キーＫｔｅｎａｎｔによって、使用の第１のタイプであるオペレーションを実行するリクエストを前記第２セキュリティコンテキストに与える工程と、
前記使用クレデンシャルが有効でありかつ満了していないことを条件に、前記第２セキュリティコンテキストにおいて前記オペレーションを実行する工程と
をさらに備える請求項３４に記載の方法。
【請求項３６】
前記使用クレデンシャルは使用サーティフィケートである、請求項３３から３５のいずれか一項に記載の方法であって、当該方法は、
前記使用サーティフィケートを前記第１セキュリティコンテキスト内で、プライベートキーＫｔｅｎａｎｔ−ｓｉｇｎｐｒｉｖによって暗号化サインする工程であって、前記使用サーティフィケートの起源を認証可能な情報はサインであり、前記対応するパブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂはインテグリティ保護され、前記第２セキュリティコンテキストにアクセス可能である、ところの工程と、
前記パブリックキーＫｔｅｎａｎｔ−ｓｉｇｎｐｕｂを使って前記第２セキュリティコンテキストにおいて前記使用サーティフィケートを検証する工程と
をさらに備える方法。
【請求項３７】
前記使用クレデンシャルの満期を判定可能な情報は、満了時間、および基準時間ソースを同定する情報を有する、ことを特徴とする請求項３３から３６のいずれか一項に記載の方法。
【請求項３８】
前記使用サーティフィケートに対応する前記暗号キーＫｔｅｎａｎｔを同定可能な情報はＫｔｅｎａｎｔのハッシュである、ことを特徴とする請求項３３から３７のいずれか一項に記載の方法。
【請求項３９】
請求項３２から３８のいずれか一項に記載の方法をコンピュータに実行させるように構成されたコンピュータ読み取り可能なコードを有するキャリア媒体。
【国際調査報告】
2019509667.tif 000023
2019509667.tif 000024
2019509667.tif 000025
2019509667.tif 000026
2019509667.tif 000027
2019509667.tif 000028