(57)【要約】      （修正有）【課題】複数のローカリティの複数のキー・キャッシュ・マネージャが、セキュリティ・チップの暗号キー・ストレージ・リソースを共用する方法を提供すること。【解決手段】方法は、アプリケーション・キーをキー・ストレージにロードするステップと、キー・キャッシュ・マネージャによってアプリケーション・キーの復元データを保存するステップとを含む。アプリケーション・キーが他のキー・キャッシュ・マネージャによってキー・ストレージから払い出される場合には、キー・キャッシュ・マネージャはこの復元データを使用してアプリケーション・キーをキー・ストレージに再ロードすることができる。【選択図】図３
2005182787.tif 000002
【特許請求の範囲】
【請求項１】
複数のローカリティの複数のキー・キャッシュ・マネージャがセキュリティ・チップの暗号キー・ストレージ・リソースを共用する方法であって、
（ａ）アプリケーション・キーを前記キー・ストレージにロードするステップと、
（ｂ）キー・キャッシュ・マネージャによって前記アプリケーション・キーの復元データを保存するステップと
を含み、前記アプリケーション・キーが他のキー・キャッシュ・マネージャによって前記キー・ストレージから払い出される場合には、前記キー・キャッシュ・マネージャが前記復元データを使用して前記アプリケーション・キーを前記キー・ストレージに再ロードすることができる方法。
【請求項２】
前記ロードするステップ（ａ）が、
（ａ１）前記キー・ストレージが満杯であると決定するステップと、
（ａ２）現在ロードされているキーを前記キー・ストレージから払い出すステップと、
（ａ３）前記アプリケーション・キーを前記キー・ストレージにロードするステップと
を含む、請求項１に記載の方法。
【請求項３】
（ｃ）前記アプリケーション・キーが以前に前記キー・ストレージにロードされていたと決定するステップと、
（ｄ）前記アプリケーション・キーが現在前記キー・ストレージ中にロードされていないと決定するステップと、
（ｅ）現在ロードされているキーを払い出すステップと、
（ｆ）前記アプリケーション・キーの前記復元データを使用して、前記アプリケーション・キーを前記キー・ストレージに再ロードするステップと
をさらに含む、請求項１に記載の方法。
【請求項４】
（ｃ）第２のアプリケーション・キーを前記キー・ストレージにロードするステップと、
（ｄ）第２のキー・キャッシュ・マネージャによって前記第２のアプリケーション・キーの第２の復元データを保存するステップと
をさらに含み、前記第２のアプリケーション・キーが他のキー・キャッシュ・マネージャによって前記キー・ストレージから払い出される場合には、前記第２のキー・キャッシュ・マネージャが前記第２の復元データを使用して前記第２のアプリケーション・キーを前記キー・ストレージに再ロードすることができる、請求項１に記載の方法。
【請求項５】
前記ロードするステップ（ｃ）が、
（ｃ１）前記キー・ストレージが満杯であると決定するステップと、
（ｃ２）前記第２のキー・キャッシュ・マネージャによって、前記アプリケーション・キーを前記キー・ストレージから払い出すステップと、
（ｃ３）前記第２のアプリケーション・キーを前記キー・ストレージにロードするステップと
を含む、請求項４に記載の方法。
【請求項６】
（ｅ）前記第２のアプリケーション・キーが以前に前記キー・ストレージにロードされていたと決定するステップと、
（ｆ）前記第２のアプリケーション・キーが現在前記キー・ストレージにロードされていないと決定するステップと、
（ｇ）前記第２のキー・キャッシュ・マネージャによって前記アプリケーション・キーを払い出すステップと、
（ｈ）前記第２のアプリケーション・キーの前記第２の復元データを使用して、前記第２のアプリケーション・キーを前記キー・ストレージにロードするステップと
をさらに含む請求項４に記載の方法。
【請求項７】
複数のローカリティの複数のキー・キャッシュ・マネージャがセキュリティ・チップの暗号キー・ストレージ・リソースを共用するためのプログラム命令を有するコンピュータ可読の媒体であって、
（ａ）アプリケーション・キーを前記キー・ストレージにロードする命令と、
（ｂ）キー・キャッシュ・マネージャによって前記アプリケーション・キーの復元データを保存する命令と
を含み、前記アプリケーション・キーが他のキー・キャッシュ・マネージャによって前記キー・ストレージから払い出される場合には、前記キー・キャッシュ・マネージャが前記復元データを使用して前記アプリケーション・キーを前記キー・ストレージに再ロードすることができる媒体。
【請求項８】
前記ロードする命令（ａ）が、
（ａ１）前記キー・ストレージが満杯であると決定する命令と、
（ａ２）現在ロードされているキーを前記キー・ストレージから払い出す命令と、
（ａ３）前記アプリケーション・キーを前記キー・ストレージにロードする命令と
を含む、請求項７に記載の媒体。
【請求項９】
（ｃ）前記アプリケーション・キーが以前に前記キー・ストレージにロードされていたと決定する命令と、
（ｄ）前記アプリケーション・キーが現在前記キー・ストレージにロードされていないと決定する命令と、
（ｅ）現在ロードされているキーを払い出す命令と、
（ｆ）前記アプリケーション・キーの前記復元データを使用して、前記アプリケーション・キーを前記キー・ストレージに再ロードする命令と
をさらに含む、請求項７に記載の媒体。
【請求項１０】
（ｃ）第２のアプリケーション・キーを前記キー・ストレージにロードする命令と、
（ｄ）第２のキー・キャッシュ・マネージャによって前記第２のアプリケーション・キーの第２の復元データを保存する命令と
をさらに含み、前記第２のアプリケーション・キーが他のキー・キャッシュ・マネージャによって前記キー・ストレージから払い出される場合には、前記第２のキー・キャッシュ・マネージャが前記第２の復元データを使用して前記第２のアプリケーション・キーを前記キー・ストレージに再ロードすることができる、請求項７に記載の媒体。
【請求項１１】
前記ロードする命令（ｃ）が、
（ｃ１）前記キー・ストレージが満杯であると決定する命令と、
（ｃ２）前記第２のキー・キャッシュ・マネージャによって、前記アプリケーション・キーを前記キー・ストレージから払い出す命令と、
（ｃ３）前記第２のアプリケーション・キーを前記キー・ストレージにロードする命令と
を含む、請求項１０に記載の媒体。
【請求項１２】
（ｅ）前記第２のアプリケーション・キーが以前に前記キー・ストレージにロードされていたと決定する命令と、
（ｆ）前記第２のアプリケーション・キーが現在前記キー・ストレージにロードされていないと決定する命令と、
（ｇ）前記第２のキー・キャッシュ・マネージャによって前記アプリケーション・キーを払い出す命令と、
（ｈ）前記第２のアプリケーション・キーの前記第２の復元データを使用して、前記第２のアプリケーション・キーを前記キー・ストレージにロードする命令と
をさらに含む、請求項１０に記載の媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はハードウェア・セキュリティ・アーキテクチャに関し、より詳細にはＴＰＭ（trustedplatformmodule）セキュリティ・アーキテクチャに関する。
【背景技術】
【０００２】
図１は、従来のハードウェア・セキュリティ・アーキテクチャを示す。このアーキテクチャは、コンピュータ・システム中にセキュリティ・チップ１０１およびメモリ１０２を含む。メモリ１０２は、ローカリティ１（１０３）、ローカリティ３（１０４）など異なるローカリティに分けられる。様々なアプリケーション１０５〜１０８が各ローカリティから実行される。各ローカリティはまた、それ自体のキー・キャッシュ・マネージャ１１１〜１１２を有する。各キー・キャッシュ・マネージャ１１１〜１１２は、セキュリティ・チップ１０１のキー・ストレージ１１０にあるアプリケーション・セキュリティ・キーの暗号ストレージを管理する。例えば、キー・キャッシュ・マネージャ１１１はアプリケーション１０５のキーをセキュリティ・チップ１０１の公開鍵を使用して暗号化する。公開鍵は、公開／秘密鍵対、すなわちセキュリティ・チップ１０１のストレージ・ルート・キー（ＳＲＫ）１０９の一部である。次いで、暗号化されたアプリケーション・キーがセキュリティ・チップ１０１に送られる。セキュリティ・チップ１０１は、暗号化されたアプリケーション・キーをそれ自体の秘密鍵を使用して解読して、そのアプリケーション・キーをチップ１０１上に格納する。次に、アプリケーション１０５が後でキーの使用を要求したとき、キー・キャッシュ・マネージャ１１１は、セキュリティ・チップ１０１に格納されたアプリケーション・キーの使用を求める要求を処理することができる。
【０００３】
ただしこのアーキテクチャでは、キー・キャッシュ・マネージャ１１１〜１１２は、互いに相手を信頼せずに機能する。すなわち、どちらのキー・キャッシュ・マネージャ１１１〜１１２も、相手がキー・ストレージ１１０を同じ状態のままにしておくことを期待しない。従って、例えばキー・ストレージ１１０が満杯である場合には、キー・キャッシュ・マネージャ１１２は、現在ロードされているキーを払い出して、それ自体のローカリティ３（１０４）にあるアプリケーションのための別のキーを格納することができる。払い出されるキーがそのローカリティ内部のアプリケーションからのキーである場合には、キー・キャッシュ・マネージャ１１２はそのキーのストレージを追跡することができる。しかし、キー・キャッシュ・マネージャ１１２は、別のローカリティ、例えばローカリティ１（１０３）にあるアプリケーションのキーを払い出すこともできる。キー・キャッシュ・マネージャ１１１と１１２は互いに対話をすることがないので、キー・キャッシュ・マネージャ１１１は、それ自体のキーの１つがキー・キャッシュ・マネージャ１１２によって払い出されたことを知らない。その結果、キー・キャッシュ・マネージャ１１１がキー・ストレージ１１０に行き、そのキーにアクセスしたときに、誤ったキーが使用されることになる。これは、一貫性の問題を生じる。この問題を避ける１つの方法は、セキュリティ・チップ１０１へのアクセスを１つのローカリティ内のアプリケーションに制限することである。しかし、その方法では、他のローカリティ内のアプリケーションはセキュリティ・チップ１０１の機能を利用することができなくなる。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
従って、複数のキー・キャッシュ・マネージャがセキュリティ・チップの暗号キー・ストレージ・リソースを共用できる方法が求められている。この方法により、異なるローカリティのキー・キャッシュ・マネージャが、一貫性の問題なしにセキュリティ・チップにアクセスすることが可能になる必要がある。本発明はこのような要望に応えるものである。
【課題を解決するための手段】
【０００５】
複数のローカリティの複数のキー・キャッシュ・マネージャがセキュリティ・チップの暗号キー・ストレージ・リソースを共用する方法は、アプリケーション・キーをキー・ストレージにロードするステップと、そのアプリケーションの復元データをキー・キャッシュ・マネージャが保存するステップとを含む。復元データは、あるアプリケーション・キーが他のキー・キャッシュ・マネージャによってキー・ストレージから払い出された場合に、払い出されたアプリケーション・キーのキー・キャッシュ・マネージャがそのキーをキー・ストレージに再ロードするために使用することができる。この方法を用いると、複数のキー・キャッシュ・マネージャの各々が、各々のキーがセキュリティ・チップから移動されたことを認識し、かつそのキーを復元させることが可能になる。この方法により、各キー・キャッシュ・マネージャが、現在セキュリティ・チップ上にロードされている任意のキーを他のローカリティに影響を与えることなく払い出すまたは廃棄することも可能になる。
【発明を実施するための最良の形態】
【０００６】
本発明は、複数のキー・キャッシュ・マネージャが、セキュリティ・チップの暗号キー・ストレージ・リソースを共用するための方法を提供する。以下の説明は、当業者が本発明を理解し使用することが可能になるように示され、また特許出願およびその要件に即して行われる。当業者には、好ましい実施形態の様々な修正形態が容易に明らかになるはずであり、また本発明の一般的な原理は他の実施形態にも適用できるものである。従って本発明は、示された実施形態に制限されることは意図されておらず、本明細書に記載の原理および特徴に適合する最大限の範囲が許容されるべきであることが意図される。
【０００７】
本発明による方法を用いると、複数のキー・キャッシュ・マネージャの各々が、各々のキーがセキュリティ・チップから移動されたことを認識し、かつそのキーを復元させることが可能になる。この方法により、各キー・キャッシュ・マネージャが、現在セキュリティ・チップ上にロードされている任意のキーを他のローカリティに影響を与えることなく払い出すまたは廃棄することも可能になる。
【０００８】
本発明の特徴をより詳細に説明するために、以下の議論と併せて図２〜図５を参照されたい。
【０００９】
図２は、本発明によるハードウェア・セキュリティ・アーキテクチャを示す。このアーキテクチャは、以下で説明するように、本発明による方法を実施するためのコードを含むキー・キャッシュ・マネージャ２０１〜２０２を除けば、図１に示された従来のアーキテクチャと同一の要素を含む。
【００１０】
図３は、本発明による、複数のキー・キャッシュ・マネージャがセキュリティ・チップの暗号キー・ストレージ・リソースを共用する方法についての好ましい実施形態を示す流れ図である。キー・ストレージ１１０にキーをロードするために、キー・キャッシュ・マネージャ、例えばキー・キャッシュ・マネージャ２０１は先ず、ステップ３０１で、ロードするアプリケーション・キーが以前にキー・ストレージ１１０にロードされたことがあるかどうか判定する。ロードされたことがなければ、キー・キャッシュ・マネージャ２０１は、ステップ３０２で、キー・ストレージ１１０に空きがあるかどうか判定する。キー・ストレージ１１０に空きがある場合には、ステップ３０３で、キー・キャッシュ・マネージャ２０１がアプリケーション・キーをロードする。好ましい実施形態では、キー・キャッシュ・マネージャ２０１は、セキュリティ・チップの公開鍵を用いてアプリケーション・キーを暗号化する。セキュリティ・チップ１０１はそれ自体の秘密鍵を使用してアプリケーション・キーを解読し、そのアプリケーション・キーをキー・ストレージ１１０に格納する。アプリケーション・キーのロードに加え、キー・キャッシュ・マネージャ２０１は、ステップ３０４で、アプリケーション・キーの復元データの保存も行う。復元データは、実質的にアプリケーション・キーのコピーであり、知識データベースに格納される。復元データの使用法を以下に示す。
【００１１】
キー・ストレージ１１０に空きが無い場合には、キー・キャッシュ・マネージャ２０１は、ステップ３０５で、現在ロードされているキーを払い出す。次いでこのマネージャは、ステップ３０６で、払い出すことで生成された新たな空き領域にアプリケーション・キーをロードする。さらにキー・キャッシュ・マネージャ２０１は、ステップ３０７で、そのアプリケーション・キーの復元データを保存する。
【００１２】
アプリケーション・キーがキー・ストレージ１１０にロードされた後で、アプリケーションがキーの使用を要求したとき、キー・キャッシュ・マネージャ２０１は、ステップ３０８で、そのアプリケーション・キーが現在キー・ストレージ１１０にロードされているかどうか、すなわち他のキー・キャッシュ・マネージャによってそのキーが払い出されていないかどうか判定する。アプリケーション・キーが現在ロードされている場合には、ステップ３０９で、そのアプリケーション・キーを使用するアプリケーションの要求にサービスが提供される。ロードされていない場合には、キー・キャッシュ・マネージャ２０１は、ステップ３１０で、キー・ストレージ１１０に現在ロードされているキーの１つを払い出し、次いでステップ３１１で、そのアプリケーション・キーの復元データを使用して、アプリケーション・キーをキー・ストレージ１１０に再ロードする。
【００１３】
例えば、キー・ストレージ１１０が同時に３つのキーを保持するものと想定する。図４は、キー・ストレージ１１０に格納されたキーの例である。ローカリティ１（１０３）にあるアプリケーション１０５のための第１のアプリケーション・キー４０１がキー・ストレージ１１０に格納されると想定する。このキー４０１を格納する際に、キー・キャッシュ・マネージャ２０１は先ず、ステップ３０１で、第１のアプリケーション・キー４０１がキー・ストレージ１１０にロードされたことがあるかどうか判定する。ロードされたことがないので、次いでキー・キャッシュ・マネージャ２０１は、ステップ３０２で、キー・ストレージ１１０が満杯かどうか判定する。このキー・ストレージは満杯ではないので、次にキー・キャッシュ・マネージャ２０１は、ステップ３０３で、LoadKey関数を呼び出して第１のアプリケーション・キー４０１をキー・ストレージ１１０にロードする。第１のアプリケーション・キー４０１には、このキーのアプリケーションのローカリティを一意に識別するタグ「0x1000001」が付与される。この例では、タグの先頭近くの「１」によって、そのキーのソースであるローカリティ１（１０３）が一意に識別される。次に、キー・キャッシュ・マネージャ２０１は、直ちに関数SaveContextPersistを呼び出し、この関数は第１のアプリケーション・キー４０１の復元データを返す。復元データは、ステップ３０４で、キー・キャッシュ・マネージャ２０１によって格納される。
【００１４】
ローカリティ１（１０３）にあるアプリケーション１０７のための第２のアプリケーション・キー４０２もまたストレージ１１０に格納されると想定する。このキー４０２を格納する際に、キー・キャッシュ・マネージャ２０１は先ず、ステップ３０１で、第２のアプリケーション・キー４０２がキー・ストレージ１１０にロードされたことがあるかどうか判定する。ロードされたことがないので、次いでキー・キャッシュ・マネージャ２０１は、ステップ３０２で、キー・ストレージ１１０が満杯かどうか判定する。このストレージは満杯ではないので、次にキー・キャッシュ・マネージャ２０１は、ステップ３０３で、LoadKey関数を呼び出して第２のアプリケーション・キー４０２をキー・ストレージ１１０にロードする。第２のアプリケーション・キー４０２には、このキーのアプリケーションのローカリティを一意に識別するタグ「0x1000002」が付与される。この例では、タグの先頭近くの「１」によって、このキーのソースであるローカリティ１（１０３）が一意に識別される。次に、キー・キャッシュ・マネージャ２０１は、直ちに関数SaveContextPersistを呼び出し、この関数は第２のアプリケーション・キー４０２の復元データを返す。この復元データは、ステップ３０４で、キー・キャッシュ・マネージャ２０１によって格納される。
【００１５】
次に、ローカリティ３（１０４）にあるアプリケーションのための第３のアプリケーション・キー４０３がキー・ストレージ１１０に格納されると想定する。このキー４０３を格納する際に、キー・キャッシュ・マネージャ２０２は先ず、ステップ３０１で、第３のアプリケーション・キー４０３がキー・ストレージ１１０にロードされたことがあるかどうか判定する。ロードされたことがないので、次いでキー・キャッシュ・マネージャ２０２は、ステップ３０２で、キー・ストレージ１１０が満杯かどうか判定する。このストレージは満杯ではないので、次にキー・キャッシュ・マネージャ２０２は、ステップ３０３で、LoadKey関数を呼び出して第３のアプリケーション・キー４０３をキー・ストレージ１１０にロードする。第３のアプリケーション・キー４０３にはタグ「0x3000003」が付与され、この場合、タグの先頭近くの「３」によって、このキーのソースであるローカリティ３（１０４）が一意に識別される。キー・キャッシュ・マネージャ２０２はまた、関数SaveContextPersistを呼び出し、この関数は第３のアプリケーション・キー４０３の復元データを返す。この復元データは、ステップ３０４で、キー・キャッシュ・マネージャ２０２によって格納される。
【００１６】
次に、ローカリティ３（１０４）にあるアプリケーション１０８が、第４のアプリケーション・キー４０４をキー・ストレージ１１０にロードする必要があると想定する。キー・キャッシュ・マネージャ２０２は、ステップ３０１で、この第４のアプリケーション・キー４０４がキー・ストレージ１１０にロードされたことがないと決定する。このキー・キャッシュ・マネージャはまた、ステップ３０２で、キー・ストレージ１１０に空きがないことも決定する。次に、キー・キャッシュ・マネージャ２０２は、ステップ３０５で、現在ロードされているキー、例えば第１のアプリケーション・キー４０１を払い出す。次いで、キー・キャッシュ・マネージャ２０２は、ステップ３０６で、第４のアプリケーション・キー４０４をキー・ストレージ１１０にロードする。このキーには、タグ「0x3000001」が付与される。図５は、第１のアプリケーション・キー４０１が払い出され、第４のアプリケーション・キー４０４がロードされた後の、キー・ストレージ１１０に格納されたアプリケーション・キーの例を示す。SaveContextPersist関数も呼び出され、キー・キャッシュ・マネージャに第４のアプリケーション・キー４０４の復元データが返され、ステップ３０７で、そのデータが保存される。
【００１７】
次に、第１のアプリケーション・キー４０１のオーナが、キーの使用を必要としていると想定する。キー・キャッシュ・マネージャ２０１は、ステップ３０１で、第１のアプリケーション・キー４０１が既にキー・ストレージ１１０にロードされたことがあると決定する。次に、キー・キャッシュ・マネージャ２０１は、ステップ３０８で、第１のアプリケーション・キーが現在キー・ストレージ１１０にロードされているかどうか判定する。このマネージャは、キー・ストレージ１１０の第１のアプリケーション・キー４０１の位置に現在ロードされているキーのタグを検査することによってそれを決定する。現在ロードされているキーのタグが「0x3000001」なので、キー・キャッシュ・マネージャ２０１は、このキーがローカリティ１（１０３）のどのアプリケーションにも属していないことを認識する。次いでキー・キャッシュ・マネージャ２０１は、ステップ３１０で、現在ロードされている第４のアプリケーション・キー４０４をキー・ストレージ１１０から払い出し、ステップ３１１で、ステップ３０４で以前に保存した第１のアプリケーション・キーの復元データを使用して、第１のアプリケーション・キー４０１を再ロードする。次に、キー・ストレージ１１０に格納されたキーは、再び図４に示されたようになる。
【００１８】
この好ましい実施形態では、上記のように、キーのロードと復元データの保存とを別々のステップとして説明しているが、当業者なら、本発明の趣旨および範囲を逸脱することなく、キーのロードと復元データの保存を１つの関数呼出しで実施できることを理解されよう。
【００１９】
複数のキー・キャッシュ・マネージャが、セキュリティ・チップの暗号キー・ストレージ・リソースを共用する方法を開示してきた。この方法を用いると、複数のキー・キャッシュ・マネージャの各々が、各々のキーがセキュリティ・チップから移動されたことを認識し、かつそのキーを復元させることが可能になる。この方法により、各キー・キャッシュ・マネージャが、現在セキュリティ・チップ上にロードされている任意のキーを他のローカリティに影響を与えることなく払い出すまたは廃棄することも可能になる。
【００２０】
本発明を図示の実施形態に従って説明してきたが、添付の特許請求の範囲の趣旨および範囲を逸脱することなく、これらの実施形態のいくつもの変形形態が存在し得ることを当業者なら容易に理解されよう。したがって、添付の特許請求の範囲の趣旨および範囲を逸脱することなく、当業者によって多くの修正を加え得るものである。
【図面の簡単な説明】
【００２１】
【図１】従来のハードウェア・セキュリティ・アーキテクチャを示す図である。
【図２】本発明によるハードウェア・セキュリティ・アーキテクチャを示す図である。
【図３】本発明による、複数のキー・キャッシュ・マネージャがセキュリティ・チップの暗号キー・ストレージ・リソースを共用する方法についての好ましい実施形態を示す流れ図である。
【図４】本発明に従ってキー・ストレージに格納されるキーの例を示す図である。
【図５】本発明に従ってキー・ストレージに格納されるキーの例を示す図である。
【符号の説明】
【００２２】
１０１  セキュリティ・チップ
１０２  メモリ
１０３  ローカリティ１
１０４  ローカリティ３
１０５  アプリケーション
１０７  アプリケーション
１０９  ストレージ・ルート・キー（ＳＲＫ）
１１０  キー・ストレージ
１１１  キー・キャッシュ・マネージャ
１１２  キー・キャッシュ・マネージャ
２０１  キー・キャッシュ・マネージャ
２０２  キー・キャッシュ・マネージャ
４０１  アプリケーション・キー
４０２  アプリケーション・キー
４０３  アプリケーション・キー
４０４  アプリケーション・キー
【図１】
2005182787.tif 000003
【図２】
2005182787.tif 000004
【図３】
2005182787.tif 000005
【図４】
2005182787.tif 000006
【図５】
2005182787.tif 000007