ランダムファンクションを利用した秘密の共有
フィジカルランダムファンクション（ＰＵＦ）は、評価することは容易であるが、特徴付けすることが困難であるファンクションである。被制御フィジカルランダムファンクション（ＣＰＵＦ）は、分離不可な方法によりＰＵＦに物理的に関連付けされたセキュリティアルゴリズムによって制御されるセキュアプログラムを介してのみアクセス可能である。ＣＰＵＦは、証明書が生成され、特定の計算が特定のプロセッサ上で実行されたことを証明する場合、証明された実行を可能にする。特に、ＣＰＵＦを有する集積回路が、チャレンジ・レスポンスペア（ＣＲＰ）を利用して認証可能である。本発明は、ＣＰＵＦ上で実行される各セキュリティプログラムの間に共有される秘密を生成する機構を提供する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、第１セキュリティプログラムと少なくとも第２セキュリティプログラムとの間で共有される秘密を生成する方法と、当該方法を実現するよう構成されるシステムと、当該方法を実現するためのコンピュータプログラムプロダクトと、当該方法を実現するためのコンピュータ実行可能命令と、当該方法により生成される結果を搬送する信号とに関する。
【背景技術】
【０００２】
電子取引などのプリケーションでは、計算（又はプログラム）がユーザ又は第三者によって特定のプロセッサ上で実際に実行されたことを検証することが要求されるかもしれない。Ｂｌａｉｓｅ Ｇａｓｓｅｎｄ、Ｄｗａｉｎｅ Ｃｌａｒｋｅ、Ｍａｒｔｅｎ ｖａｎ Ｄｉｊｋ及びＳｒｉｎｉｖａｓ Ｄｅｖａｄａｓによる“Ｃｏｎｔｒｏｌｌｅｄ Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ｆｕｎｃｔｉｏｎｓ”（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １８ｔｈ Ａｎｎｕａｌ Ｃｏｍｐｕｔｅｒ Ｓｅｃｕｒｉｔｙ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｎｆｅｒｅｎｃｅ，Ｄｅｃｅｍｂｅｒ，２００２）（以降において「従来技術文献」と呼ぶ）において、ＰＵＦに結合されたチャレンジ・レスポンスペアを生成及び検証するためのフレームワークが規定されている。フィジカル・ランダム・ファンクション（ＰＵＦ）は、複雑な物理システムを用いて評価されるランダムファンクションである。ＰＵＦという略語の使用は（ＰＲＦの代わりに）、発音するのがより容易であるという効果を有し、擬似ランダムファンクション（Ｐｓｅｕｄｏ−Ｒａｎｄｏｍ Ｆｕｎｃｔｉｏｎ）との混同を回避する。ＰＵＦは様々な方法により実現可能である。ＰＵＦの実現形態のいくつかは、各生成サンプル（各半導体チップなど）が異なるファンクションを実現するように生成することが容易である。これは、ＰＵＦを認証識別アプリケーションに利用することを可能にする。
【０００３】
ＰＵＦは、チャレンジをレスポンスに変換し、物理装置により実現され、以下の２つの性質を有するファンクションである。すなわち、（１）ＰＵＦは評価が容易である。すなわち、物理装置は、短い時間でファンクションを容易に評価することができる。（２）ＰＵＦは特性化が困難である。すなわち、ポリノミアル（ｐｏｌｙｎｏｍｉａｌ）数のもっともらしい（ｐｌａｕｓｉｂｌｅ）物理的測定から（特に、選ばれたチャレンジ・レスポンスペアの決定）、もはやセキュリティ装置を有さず（アクセスできず）、ポリノミアル量のリソース（時間、物質など）しか利用できない攻撃者は、ランダムに選択されたチャレンジに対するレスポンスに関してわずかな情報しか抽出することができない。上記定義では、「短い」及び「多項式の」という用語は、セキュリティパラメータである装置のサイズに相対するものである。特に、「短い」という用語は、リニア又は低い程度のポリノミアルを意味する。「もっともらしい」という用語は、最新の測定技術に相対するものであり、改良された方法が創出されるに従い変化する可能性がある。
【０００４】
ＰＵＦの具体例として、シリコンＰＵＦ（Ｂｌａｉｓｅ Ｇａｓｓｅｎｄ、Ｄｗａｉｎｅ Ｃｌａｒｋｅ、Ｍａｒｔｅｎ ｖａｎ Ｄｉｊｋ及びＳｒｉｎｉｖａｓ Ｄｅｖａｄａｓによる“Ｓｉｌｉｃｏｎ Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ｆｕｎｃｔｉｏｎｓ”（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ９ｔｈ ＡＣＭ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｅｃｕｒｉｔｙ，Ｎｏｖｅｍｂｅｒ，２００２）、オプティカルＰＵＦ（マサチューセッツ工科大のＰ．Ｓ．Ｒａｖｉｋａｎｔｈによる“Ｐｈｙｓｉｃａｌ Ｏｎｅ−Ｗａｙ Ｆｕｎｃｔｉｏｎｓ（２００１）、デジタルＰＵＦなどがあげられる。シリコンＰＵＦは、製造工程に帰因するチップ間のばらつきを利用する、オプティカルＰＵＦは、コヒーレント光（レーザ）ビームにより放射される光構成によって生成されるスペックルパターンの予測不能性を利用する。デジタルＰＵＦは、改ざん耐性環境が、暗号化及び認証用に利用される秘密鍵をプロテクトする従来シナリオを表す。
【０００５】
ＰＵＦは、それがセキュリティ装置内で分離不可な方法により（すなわち、当該アルゴリズムを回避しようとする何れの試みも、ＰＵＦの破壊を導く）ＰＵＦに物理的にリンクしたセキュリティアルゴリズムを介してのみアクセス可能である場合、被制御であると定義される（被制御ＰＵＦ又はＣＰＵＦ）。特に、当該セキュリティアルゴリズムは、ＰＵＦに提供されるチャンレンジを制限し、外部の世界に与えられるレスポンスに関する情報を制限することができる。制御は、ＰＵＦがシンプルな認証識別アプリケーションに勝ることを可能にする基本的アイデアである。
【０００６】
ＣＰＵＦの具体例については、従来技術文献に記載されている。セキュリティプログラムは、ＰＵＦがセキュリティプログラムから２つのプリミティブファンクションＧｅｔＳｅｃｒｅｔ（．）及びＧｅｔＲｅｓｐｏｎｓｅ（．）を介してのみアクセス可能となるように、セキュリティアルゴリズムの制御の下で利用され、ＰＵＦとリンクされる。ＧｅｔＳｅｃｒｅｔ（．）は、プリミティブファンクションが実行されるセキュリティプログラムの表現にＰＵＦへの入力が依存することを保証する。この依存性のため、ＰＵＦへの入出力は、これらのプリミティブファンクションが異なるセキュリティプログラム内から実行される場合には、異なるものとなるであろう。さらに、これらのプリミティブファンクションは、新たなチャレンジ・レスポンスペアの生成が、従来技術文献に記載されるように、規制され、セキュアとすることが可能であることを保証する。
【０００７】
しかしながら、上記プリミティブファンクションの出力はセキュリティプログラムの表現に依存するとき、それらは同一のＰＵＦ上で実行される異なるセキュリティプログラムの間で共有される秘密を生成するのに利用可能でない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の課題は、異なるセキュリティアルゴリズムの間で共有される秘密を生成することを可能にする方法を提供することである。
【課題を解決するための手段】
【０００９】
上記課題は、第１セキュリティプログラムと少なくとも第２セキュリティプログラムとの間で共有される秘密を生成する方法であって、被制御インタフェースを介しセキュリティプログラムのみからアクセス可能なランダムファンクションを有するセキュリティ装置上で、前記第１セキュリティプログラムの制御の下でプログラム命令を実行するステップを有し、前記被制御インタフェースは、プリミティブファンクションを呼び出す前記第１セキュリティプログラムの表現の少なくとも一部と、前記セキュリティ装置上で前記第２セキュリティプログラムを実行すると、前記プリミティブファンクションを呼び出す前記第２セキュリティプログラムの表現の少なくとも一部とに依存する出力を返す前記ランダムファンクションにアクセスする少なくとも１つのプリミティブファンクションを有し、前記ステップは、前記共有される秘密を生成するため前記少なくとも１つのプリミティブファンクションを呼び出すサブステップを有する方法により実現される。これにより、共有される秘密は、各セキュリティプログラムが入力としてのプリミティブファンクションが呼び出されるセキュリティプログラムの表現と、秘密が共有されるべきその他のセキュリティプログラムの表現との両方と共にプリミティブファンクションを呼び出すことによって、２以上のセキュリティプログラムの間で確立することが可能である。これらセキュリティプログラムのそれぞれがプリミティブファンクションへの入力として、関係するセキュリティプログラムの表現を利用するため、同一の秘密が各セキュリティプログラムにより生成される。
【００１０】
出力をセキュリティプログラムの表現に依存させることによって、セキュリティ装置上で実行される他の何れかのセキュリティプログラムが、被制御インタフェースを介し同一の入力に対して異なる結果を取得することが、（ほとんど）保証される。共有されるキーを取得するようハッカーによって設計される他の何れかのセキュリティプログラムが、被制御インタフェースを介し役に立たない結果のみを取得する（表現方法に依存して高い確率により）。なぜなら、これらの結果は、ハッカーによって使用される他のセキュリティプログラムともとのセキュリティプログラムに対して異なるセキュリティプログラム表現に依存するためである。他の何れのセキュリティプログラムも、秘密キーを再生成し、ランダムファンクションによって提供されるセキュリティを危うくする方法によってはランダムファンクションにアクセスすることはできない。
【００１１】
セキュリティプログラムの表現は、ハッシュ、他のシグネチャ又は他の一部とすることが可能である。通常、セキュリティプログラムの表現は、完全なセキュリティプログラムをカバーするが、特別なケースでは（例えば、セキュリティプログラムがランダムファンクションに関係ない大きな部分を含む場合など）、プリミティブファンクションの入出力の呼び出し及び処理を扱うセキュリティプログラムのこれらの部分に表現を限定することが効果的であるかもしれない。
【００１２】
セキュリティプログラムは、典型的には、セキュリティ装置のユーザにより提供される。代わりとして、セキュリティプログラムはまた、セキュリティ装置内の別のプログラムライブラリによって提供することが可能である。
【００１３】
以降の利用のため特定のセキュリティプログラムの迅速な抽出を可能にするため、プログラムは、任意的に以降の実行が許可されている許可に関する情報と共に、セキュリティプログラムの以降の実行のため、格納又はハッシュコードとすることが可能である。
【００１４】
本発明のより特定の実現形態が、請求項２に記載されている。プログラム表現はすべて、明示的にはプログラムＰｒｏｇ１．．ＰｒｏｇＮについて、又は暗黙的にはプリミティブファンクションが呼び出されるプログラムＰｒｏｇｒａｍについて、ランダムファンクションへの入力として使用される。これを実現するため、プリミティブファンクションは、プリミティブファンクションを呼び出すセキュリティプログラムとその他のセキュリティプログラムの表現が区別されないようにしなければならない。異なるセキュリティプログラムが同一の共有された秘密を生成することを保証するため、辞書式順序付けが適用される。
【００１５】
本発明のより特定の実現形態が、請求項３に記載されている。好ましくは（ほとんど）コリジョンフリーであるランダムハッシュファンクションｈ（．）が利用されるとき、これらのプリミティブファンクションは、セキュリティプログラムの間で共有されるキーとして使用されるキーを確実に生成するのに効果的に利用可能である。請求項１に記載されるように、Ｐｒｏｇｒａｍ及びＰｒｏｇ１．．ＰｒｏｇＮは、セキュリティプログラムの関連する部分のみを表現することが理解されるべきである（セキュリティの観点から）。
【００１６】
本発明の一変形が、請求項４に記載される。請求項２のような辞書式順序付けを計算する必要の代わりに、プログラム表現がプリミティブファンクションへの入力として利用される前に、各セキュリティプログラムに同じ順序により容易に再順序付け可能となるように、当該変形はセキュリティプログラムが番号付けされることに依拠する。
【００１７】
本発明の一変形が、請求項５に記載される。２００４年５月６日に出願された特許出願ＵＳ２００４／０１４４０４（代理人整理番号ＰＨＮＬ０３０６０５）は、セキュリティプログラムが第１モードにより実行することによって生成され、同一のセキュリティプログラムが第２モードにより実行されることによって検証可能な実行のプルーフを記載している。当該手段の問題点は、双方のモードを含む完全なセキュリティプログラムが、プリミティブファンクションにおける利用及び実行のため、セキュリティプログラムにおいて利用可能とされる必要があるということである。本発明による方法は、第１モード部分又は第２モード部分のみが独立したセキュリティプログラムとして必要とされ、各セキュリティプログラムが共有される秘密を依然として生成することが可能であるとき、依然としてセキュリティが利用可能であるという効果を有している。
【００１８】
本発明の一変形が、請求項６に記載されている。２００４年５月６日に出願された特許出願ＵＳ２００４／０１４４０４（代理人整理番号ＰＨＮＬ０３０６０５）は、セキュリティプログラムの以降の継続のために考えられるセキュリティプログラムによるセキュア状態情報のコンセプトをさらに記載する。このコンセプトは、複数のセキュリティプログラムがセキュリティ装置上で実行することを効果的に可能にする２以上のセキュリティプログラムをスケジューリングするのに利用可能である。これらの各セキュリティプログラムは、本発明による方法により取得される共有される秘密キーを利用してセキュアに通信可能である。
【００１９】
本発明の効果的な実現形態が、請求項７に記載されている。従来技術文献では、認証された実行は、特定のプロセッサチップのユーザに、特定の計算が当該プロセッサチップ上で実行され、当該計算が実行され、与えられた計算出力を生成したことを証明する証明書（電子証明書と呼ばれる）を計算出力と共に生成するプロセスとして定義される。セキュリティ装置のユーザに、セキュリティプログラムが実際に同一のセキュリティ装置上で実行されることを証明するため、セキュリティプログラムは、好ましくは、従来技術文献に記載されるような認証された実行を実現する第２セキュリティプログラムの一部として実行される。
【００２０】
本発明のより特定の実現形態が、請求項８に記載される。当該実現形態では、プリミティブファンクションにおいて利用されるランダムファンクションを実現するため、ＰＵＦが利用される。
【００２１】
本発明のより特定の実現形態が、請求項９に記載されている。本実現形態における生成された共有秘密キーはまた、入力変数の少なくとも一部に依存する。これは、共有される秘密の生成について使用するため、（アプリケーション）プログラム入力がセキュリティプログラムにハードコード化される必要がないという効果を有する。一部の入力は関係がないかもしれないため、セキュリティ装置と当該セキュリティ装置のユーザとの間で秘密が維持される場合（従って、第三者に通信されない場合）、又は異なるプログラムの実行の間で異なるものとすることが許容される場合、必ずしもすべての入力が考慮される必要はない。
【００２２】
本発明によるシステムが、請求項１０に記載されるように特徴付けされる。
【００２３】
本発明によるコンピュータ可読媒体などのコンピュータプログラムプロダクトが、請求項１１に記載されるように特徴付けされる。
【００２４】
本発明による信号が、請求項１２に記載されるように特徴付けされる。
【００２５】
本発明の上記及び他の特徴が、概略図を参照して実施例を通じてさらに説明される。
【発明を実施するための最良の形態】
【００２６】
図面を通じて、同一の参照番号は同様又は対応する特徴を示す。図面に示される特徴の一部は、典型的にはソフトウェアにより実現され、ソフトウェアモジュールやオブジェクトなどのソフトウェアエンティティを表す。
【００２７】
図１は、従来技術によるＰＵＦ１０４を有するセキュリティ装置１０３を利用するアプリケーションのための基本的モデルを示す。システム１００により実現されるモデルは、以下を有する。
・セキュリティ装置１０３の制御における又は制御下のチップ１０５の計算能力を利用することを所望するユーザ１０３
・当該ユーザ及びチップは、おそらく信頼されない公衆通信チャネル１０２により互いに接続されている。ユーザは、人間とすることが可能であるだけでなく、異なるソフトウェア、ハードウェア又は他の装置とすることが可能である。
【００２８】
セキュリティ装置１０３は、プロセッサ１１１とメモリ１１２とを有し、コンピュータプログラムプロダクト１１３からのコンピュータ実行可能命令を実行するよう構成される処理装置１１０により実現可能である。
【００２９】
従来技術文献は、各特定のＰＵＦに対して一意的なチャレンジ及びレスポンスの処理を記載している。チャレンジが与えられると、ＰＵＦは対応するレスポンスを計算することができる。ユーザは、ＰＵＦにより当初生成されたＣＲＰ（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ Ｐａｉｒ）の自己のプライベート（認証された）リストを所有する。このリストは、当該ユーザのみが（おそらくＰＵＦに加えて）リストの各チャレンジに対するレスポンスを知っているという理由のため、プライベートなものである。ユーザのチャレンジはパブリックなものとすることが可能である。ユーザはセキュリティ装置によりいくつかのＣＲＰを確定していると仮定される。
【００３０】
（限定数の）チャレンジに対するレスポンスは、ユーザにのみ知られている。さらに、セキュリティ装置は、特定のチャレンジに対するレスポンスを（再）計算するかもしれない。他者が特定のチャレンジに対してレスポンスを復元することを回避するため、ＣＲＰを管理するセキュアな方法が必要とされる。従来技術文献は、これを実現するための被制御ＰＵＦのコンセプトを提案している。ＰＵＦは、それがセキュリティ装置内で分離不可な方法により（すなわち、当該アルゴリズムを回避しようとする何れの試みも、ＰＵＦの破壊を導く）ＰＵＦに物理的にリンクしたセキュリティアルゴリズムを介してのみアクセス可能である場合、被制御であると定義される（被制御ＰＵＦ又はＣＰＵＦ）。特に、当該セキュリティアルゴリズムは、ＰＵＦに提供されるチャンレンジを制限し、外部の世界に与えられるレスポンスに関する情報を制限することができる。制御は、ＰＵＦがシンプルな認証識別アプリケーションに勝ることを可能にする基本的アイデアである。ＰＵＦ及び被制御ＰＵＦは、スマートカード識別、認証実行及びソフトウェアライセンシングを実現するため説明及び知られている。
【００３１】
マン・イン・ザ・ミドル（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ）攻撃者を回避するため、ユーザはＣＲＰ管理プロトコル期間中には特定のチャレンジに対するレスポンスを求めることが禁止されている。これは、これらのプロトコルによりセキュリティ装置がユーザにレスポンスを送信するときに、ＣＲＰ管理プロトコルにおいて懸念されることである。これは、セキュリティ装置がチャレンジ対するレスポンスを直接的には提供しないように、ＰＵＦへのアクセスを制限することにより保証される。ＣＲＰ管理は、従来技術文献に記載されるように行われる。アプリケーションプロトコルでは、レスポンスは、メッセージ認証コード（ＭＡＣ）を生成するためなど、さらなる処理のために内部的にのみ使用され、ユーザに送信されることはない。ＣＰＵＦは、プライベートな方法により（当該プログラムが行っていることを誰も見ることができず、あるいは操作されている少なくともキー材料が隠されたままにされる）、また信頼できる方法により（検出されることなく、プログラムが行っていることを誰も変更することができない）、ある形式のプログラム（以降において、セキュリティプログラム）を実行することができる。
【００３２】
ＣＰＵＦの制御は、ＰＵＦがセキュリティプログラムを介してのみ、より具体的には２つのプリミティブファンクションＧｅｔＲｅｓｐｏｎｓｅ（．）及びＧｅｔＳｅｃｒｅｔ（．）を利用することによってのみアクセス可能となるように構成される。従来技術文献において使用されるプリミティブファンクションのセットは、
・ＧｅｔＲｅｓｐｏｎｓｅ（ＰＣ）＝ｆ（ｈ（ｈ（ＳＰｒｏｇｒａｍ），ＰＣ））
・ＧｅｔＳｅｃｒｅｔ（Ｃｈａｌｌｅｎｇｅ）＝ｈ（ｈ（ＳＰｒｏｇｒａｍ），ｆ（Ｃｈａｌｌｅｎｇｅ））
として定義される。ここで、ｆはＰＵＦであり、ｈは公開利用可能なランダムハッシュファンクション（又は、実際的にはある擬似ランダムファンクション）である。これらのプリミティブファンクションにおいて、ＳＰｒｏｇｒａｍは、信頼できる方法により実行されているセキュリティプログラムのコードである。当該装置のユーザが、このようなセキュリティプログラムを配信する。ｈ（ＳＰｒｏｇｒａｍ）は、ハードコード化された値（一部のケースでは、チャレンジなど）を含むプログラムに含まれるすべてを含む。セキュリティ装置は、ｈ（ＳＰｒｏｇｒａｍ）を計算し、以降においてＧｅｔＲｅｓｐｏｎｓｅ（．）とＧｅｔＳｅｃｒｅｔ（．）が呼び出されると、この値を利用する。ｈ（ＳＰｒｏｇｒａｍ）の計算は、セキュリティプログラムの開始前又はプリミティブファンクションの最初のインスタンス化（直）前に実行することができる。従来技術文献に示されるように、これら２つのプリミティブファンクションは、ＧｅｔＲｅｓｐｏｎｓｅ（．）がＣＲＰの生成に原則的に利用され、ＧｅｔＳｅｃｒｅｔ（．）がＣＲＰから共有される秘密を生成することを所望するアプリケーションにより利用されるセキュアなＣＲＰ管理を実現するのに十分である。
【００３３】
以降において、以下の記号が使用される。
・Ｅ（ｍ，ｋ）は、キーｋによりメッセージｍの暗号化である。
・Ｄ（ｍ，ｋ）は、キーｋによるメッセージｍの解読である。
・Ｍ（ｍ，ｋ）は、キーｋによりメッセージｍをＭＡＣする。
・Ｅ＆Ｍ（ｍ，ｋ）は、キーｋによりメッセージｍを暗号化及びＭＡＣする。
・Ｄ＆Ｍ（ｍ，ｋ）は、ＭＡＣが一致する場合、キーｋによりメッセージｍを解読する。ＭＡＣが一致しない場合、ＭＡＣが一致せず、解読を実行しない旨のメッセージを出力する。
【００３４】
図２に示されるような本発明の第１実施例は、共有される秘密を生成するセキュリティプログラムを実行する例を示す。セキュリティプログラム２３１は、セキュリティプログラム２３１は、共有キーが生成されるその他のセキュリティプログラムのハッシュコード表現（本例では、ｈ＿ＳＰｒｏｇＢ＝ｈ（ＳＰｒｏｇＢ）である）を有するセキュリティプログラムのための入力２３２と共に、実行のためＰＵＦ２０３を有するセキュリティ装置２０２を有するシステム２０１に通信２２１により送信される。その後、セキュリティプログラムＳＰｒｏｇＡは、
・ＧｅｔＲｅｓｐｏｎｓｅＳＫ（ＰＣ）＝ｆ（ｈ（ＰＨＲ，ＰＣ））
・ＧｅｔＳｅｃｒｅｔＳＫ（Ｃｈａｌｌｅｎｇｅ）＝ｈ（ＰＨＲ，ｆ（Ｃｈａｌｌｅｎｇｅ））
として定義される本発明によるプリミティブファンクションを利用して、セキュリティ装置に関する共有秘密を生成する。ただし、
・ＰＨＲ＝Ｏｒｄｅｒｉｎｇ（ｈ（ＳＰｒｏｇｒａｍ），Ｖａｌ，Ｒｕｌｅ）
である。
【００３５】
Ｏｒｄｅｒｉｎｇファンクションは、Ｒｕｌｅの値に従って入力パラメータの再順序付けを規定する。Ｒｕｌｅの値は、ＰＨＲとプリミティブファンクションの出力が、共有秘密を生成することを所望する異なるセキュリティプログラムにおいて同一であることを保証するのに利用可能である。生成される共有秘密は、その後は秘密キーとして利用可能である。Ｏｒｄｅｒｉｎｇファンクションは、セキュリティプログラムの表現値の辞書式順序付けとすることも可能であり、あるいはＲｕｌｅの値は上記表現値が連結される順序を決定するものであってもよい。
【００３６】
【表１】
プログラムＳＰｒｏｇＡにおいては、ｈ（Ｏｒｄｅｒｉｎｇ（ｈ（ＰｒｏｇＡ），Ｖａｌ，Ｒｕｌｅ））＝ｈ（Ｏｒｄｅｒｉｎｇ（ｈ（ＰｒｏｇＡ），ｈ（ＰｒｏｇＢ），０））＝ｈ（ｈ（ＰｒｏｇＡ），ｈ（ＰｒｏｇＢ））となる。プログラムＳＰｒｏｇＢにおいては、ｈ（Ｏｒｄｅｒｉｎｇ（ｈ（ＰｒｏｇＢ），Ｖａｌ，Ｒｕｌｅ））＝ｈ（Ｏｒｄｅｒｉｎｇ（ｈ（ＰｒｏｇＢ），ｈ（ＰｒｏｇＡ），１））＝ｈ（ｈ（ＰｒｏｇＡ），ｈ（ＰｒｏｇＢ））となる。従って、双方のプログラムは、同一の入力をプリミティブファンクションＧｅｔＲｅｓｐｏｎｓｅＳＫに適用する。
【００３７】
本発明の第２実施例は、実行のプルーフ（ｐｒｏｏｆ）の生成及び検証のため、別々のセキュリティプログラムを有するための共有秘密の利用を示す。２００４年５月６日に出願された特許出願ＵＳ２００４／０１４４０４（代理人整理番号ＰＨＮＬ０３０６０５）は、第１モードが実行のプルーフを生成し、第２モードが実行のプルーフを検証するマルチモードセキュリティプログラムを利用した実行のプルーフの生成及び検証を記載している。本発明によると、別々のセキュリティプログラムを利用して実行のプルーフを生成し、それを検証することが可能であり、これにより、プログラムダウンロード及び初期化のオーバヘッドを軽減することが可能となる。それはまた、セキュリティプログラムの表現計算の計算負荷を軽減するかもしれない。
【００３８】
実行のプルーフをサポートするため、認証された実行の解を実行のプルーフを生成するための付加的なプログラムレイヤにより拡張することが効果的である。
【００３９】
本実施例が利用可能な第１の例として、図３に示されるように、アリスが配信者３１０であり、ボブがセキュリティ装置３０１を有するＳＴＢ（セットトップボックス）３００の所有者となるＳＴＢアプリケーションを考える。プログラムＡ３２０において、ボブはあるサービスを購入する。アリスは、取引詳細３３２と、電子証明書３３３（当該電子証明書は、取引詳細と電子プルーフの両方の真正性を証明する）と、電子プルーフ３３４とを受信する。アリスは、ステップ３４０において、電子証明書が一致するかチェックする。そうである場合、アリスは、電子プルーフがボブのＳＴＢにより生成されたものであることを知り、プログラムＢにおいて取引を継続する。電子プルーフは、仲介者が取引詳細を復元可能であるため、ボブがサービスを購入したという確認として利用可能である。プログラムＢ３２１において、ボブは、ボブが要求したサービスに属するコンテンツ３３５を受信する。当該コンテンツは、ＣＲＰを利用することによって暗号化されてもよい。アリスは、プログラムＢにおいてボブのアクションの第２の電子プルーフ３３６を受信する。第１の例では、それは、ボブにプログラムＢにおいて当該コンテンツを送るアリスの約束のプルーフを受信していないようにみえる。しかしながら、アリスだけでなくボブもまた、第１の電子プルーフを利用することが可能である。ボブのＳＴＢがプログラムＡにおいて符号化されたプロトコルを良好に実行したことを何れかの第三者がチェック可能であり、それ自体プログラムＢにおいてボブにコンテンツを送信するアリスの約束となる。例えば、ボブは、電子プルーフを利用して、ボブがあるサービスを購入したことを第三者（及び特にアリス）に確信させることが可能であり、それが、ボブをディスカウントやアップグレードの対象とすることを可能にするかもしれない。
【００４０】
第２の例として、アリスが入力の一部としてタイムスタンプを有するプログラムをボブのセキュリティ装置上で実行することを所望していると仮定する。この実行結果は、当該タイムスタンプが正確な実行時間を表すというボブとの合意によるタイムスタンプのコピーを含むかもしれない。例えば、プログラムは、それがボブに同意するか尋ね、ボブが同意しない場合には中断するよう設計される。正しい電子プルーフが与えられると、仲介者は当該結果を抽出する。このため、ボブは、タイムスタンプをチェックし、ボブ及び／又はアリスの主張が依然として有効であるか否か検証することができる。
【００４１】
第３の例として、異なるモードによるプログラムＰｒｏｇｒａｍ’を仮定する。それのモードに応じて、Ｐｒｏｇｒａｍ’はプロセッサＰ上で（Ｒｅｓｕｌｔ，ＥＰｒｏｏｆ）＝Ｐｒｏｇｒａｍ（Ｉｎｐｕｔ）を計算するか（ただし、ＥＰｒｏｏｆは、Ｐに対する入力ＩｎｐｕｔによるプログラムＰｒｏｇｒａｍの電子プルーフである。）、又はＰｒｏｇｒａｍ’が、ＥＰｒｏｏｆが有効な電子プルーフであるかチェックする仲介者の役割を果たし、そうである場合には、Ｒｅｓｕｌｔを再構成する。仲介者の役割では、ＥＰｒｏｏｆはＰｒｏｇｒａｍ’における次のモードへのチケットとして利用されてもよい。この技術は、限定的なアクセスを実現する。
【００４２】
図４は、各種プログラムレイヤを示す。それぞれ実行のプルーフ、ＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ４０３及びＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ４５３を生成検証する本発明によるプログラムはそれぞれ、ユーザと第三者の双方がセキュリティ装置上で実行が行われたことを確信するため、ＰＵＦ４０１を備えるセキュリティ装置４００において各自の認証された実行プログラムＣＰｒｏｇｒａｍ１（４０２及び４５４）のＸＰｒｏｇｒａｍ部分として実行される。
【００４３】
ＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎは、アリスが興味を有する結果だけでなく、電子プルーフも計算する（ＡＰｒｏｇｒａｍ４０６において）。アリスは、認証された実行を利用して（ＣＰｒｏｇｒａｍのＸＰｒｏｇｒａｍ部分としてＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎを実行することによって）、当該プログラムがボブのセキュリティ装置上で正確に実行されたことを確信する。仲介者は、ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎを実行し、さらに認証された実行を利用することによって、電子プルーフをチェックすることができる。そのキーとなるアイデアは、ＧｅｔＲｅｓｐｏｎｓｅ（．）プリミティブが、双方のセキュリティ装置のハッシュに依存するということである。この結果、（ＧｅｔＲｅｓｐｏｎｓｅ（．）プリミティブを介し取得されたキーにより）実行のプルーフを生成するためセキュリティプログラムによって生成された電子プルーフは、実行のプルーフの検証のためセキュリティプログラムにより解読することが可能である。
【００４４】
セキュリティは、第１にＧｅｔＲｅｓｐｏｎｓｅ（．）プリミティブをブレークする困難性によって、すなわち、ハッシュをブレークし、ＧｅｔＲｅｓｐｏｎｓｅ（．）が定義されるＰＵＦをブレークする困難性によって、そして第２に暗号化及びＭＡＣ Ｅ＆Ｍ（．）プリミティブをブレークする困難性によって決定される。
【００４５】
これらのプログラムの変形が可能である。一部のプログラムは、入力の一部をハードコード化するかもしれず、これはフレキシビリティを低下させるが、よりロウバストになる。プルーフ結果に存在する出力量もまた異なる。これらのアルゴリズムの任意の変形が実現可能である。
【００４６】
第１の変形では、アリスは、ＡＰｒｏｇｒａｍ（Ｉｎｐｕｔ）を実行し、実行プルーフを受け取ることを所望し、これにより、ＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ（Ｉｎｐｕｔｓ）（４３１）を実行する。ただし、ｈ（ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ）に等しいＶａｌ４３２とランダム文字列であるＰＣ４３３によるＩｎｐｕｔｓ＝（ｈ（ＥＰｒｏｇｒａｍ＿ｖｅｒｆｉｃａｔｉｏｎ），ＡＰｒｏｇｒａｍ，Ｉｎｐｕｔ，ＰＣ）（４３５：ＡＰｒｏｇｒａｍ，４３４：Ｉｎｐｕｔによる）であり、ＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎは以下に定義されるようなものである。ＰＣは、秘密キーＫＥを生成するため、ランダムファンクションに対するチャレンジを計算するため、ＧｅｔＲｅｓｐｏｎｓｅ（．）により“プレ・チャレンジ（ｐｒｅ−ｃｈａｌｌｅｎｇｅ）として利用される。アリスは、認証された実行の技術を利用して、前述されたようなＣＰｒｏｇｒａｍ４３０を利用したボブのセキュリティ装置上でＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ（Ｉｎｐｕｔｓ）を実行する。アリスは、セキュリティ装置から取得したすべての出力の真正性を検証するため、電子証明書をチェックする。生成された電子証明書は、Ｐｒｏｇｒａｍ（Ｉｎｐｕｔ）により生成された結果４３８の証明書だけでなく、生成された電子プルーフ４３６の証明書となる。
【００４７】
【表２】
実行のプルーフは、ボブのセキュリティ装置によりプロトコルを実行する何れかの仲介者により検証可能であり、当該検証は３つのステップを有している。ステップ１では、仲介者はステップ４５０においてアリス又はボブから実行のプルーフであるＥＰｒｏｏｆを受け取る。仲介者はＩｎｐｕｔｓ＝（ｈ（Ｅｐｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ），ＥＰｒｏｏｆ）（ＥＰｒｏｏｆ：４４４）を構成する。ここで、Ｖａｌ４４２は、共有される秘密キーを生成するのに必要とされるセキュリティプログラム表現である。仲介者はまた、おそらくアリス又はボブからＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ及びＣＰｒｏｇｒａｍ（おそらく以前に実行されたようなものであって、本例では、ステップ４５１及び４５２において仲介者に通信される）。仲介者はＰＣを必要としないことに留意されたい。
【００４８】
ステップ２では、仲介者は、ＣＰｒｏｇｒａｍ４４０による認証された実行の技術を利用して、ボブのセキュリティ装置上でＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ（Ｉｎｐｕｔｓ）（ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ：４４１）を実行する。仲介者は、セキュリティ装置から取得したＲｅｓｕｌｔｓの真正性を検証するため、電子証明書４４７をチェックする。電子証明書がＲｅｓｕｌｔｓに一致する場合、仲介者は、ボブのセキュリティ装置が何れかの者の干渉なしにボブのＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ（Ｉｎｐｕｔｓ）を実行し、何れの者にもそれの入力又は出力が改ざんされていないことを知ることとなる。特に、何れの者も入力ＥＰｒｏｏｆを変更していなかった。すなわち、ボブのセキュリティ装置は、ＥＰｒｏｏｆを用いてＥＰｒｏｏｆ＿ｖｅｒｉｆｉｃａｔｉｏｎ（Ｉｎｐｕｔｓ）を実行した。Ｒｅｓｕｌｔ４４５は、Ｏｕｔｐｕｔにおいて完全に若しくは部分的に供給可能であり、又は全く供給することが可能でない。それはまた、Ｒｅｓｕｌｔから求められる情報と置換することができる。これは、アプリケーションと仲介者に依存するかもしれない。この決定は、その後プログラムにより実現される。例えば、プライバシーの理由のため、ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎは、結果のサマリのみを仲介者に送信することも可能である。
【００４９】
ステップ３では、仲介者は、ＣｈｅｃｋＢｉｔ４４６が真であるか、すなわち、ＥＭＲｅｓｕｌｔのＭＡＣが一致するか検証する。そうである場合、仲介者は、ボブのセキュリティ装置上のＡＰｒｏｇｒａｍ（Ｉｎｐｕｔ）がＥＰｒｏｏｆ及びＲｅｓｕｌｔを計算したと判断する。そうでない場合、仲介者は、ボブのセキュリティ装置がＥＰｒｏｏｆを計算していないと判断する。ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎは、ＭＡＣが一致しないことを出力するか（Ｄ＆Ｍ（．）及びＣｈｅｃｈＢｉｔの定義を参照されたい）、又はＭＡＣが解読された結果と一致することを出力する。（偽の）結果であるＦＲｅｓｕｌｔに対して偽の電子プルーフであるＦＥＰｒｏｏｆ＝（ＦＰＣ，ＦＥＭＲｅｓｕｌｔ）を生成することは、いわゆる困難な問題である。
【００５０】
第３の実施例では、２００４年５月６日に出願された特許出願ＵＳ２００４／０１４４０４（代理人整理番号ＰＨＮＬ０３０６０５）に記載されるように、セキュアメモリとセキュアプリグラムの実行状態の利用が、同一のセキュリティ装置上で交互に実行されるセキュリティ装置間のセキュアな通信を行うため、共有された秘密の生成と組み合わせることができる。
【００５１】
図５は、本実施例のアーキテクチャを示す。プログラム実行状態５０２とメモリコンテンツ５０２とは、セキュリティプログラム５０５の部分的実行の間に格納される。セキュリティ装置５００上で実行されるセキュリティプログラム５０１は、割り込みの場合、又は異なるセキュリティプログラムが実行される必要がある場合、それのプログラム状態５０５をセキュアに格納することが可能である。割り込みが行われると、プログラム状態が暗号化される（ステップ５０３）。セキュリティ装置は、外部にそれの状態を開示することなく以降においてそれの実行を継続するかもしれない。継続されると、プログラム状態が検証及び解読され（ステップ５０４）、復元される。メモリコンテンツの一部は共有秘密キーを用いて暗号化され、メモリの他の部分はプライベート共有秘密キーを用いて暗号化されてもよく、これにより、セキュアなプログラム間の通信とセキュリティプログラムの間のセキュアな分離の両方を実現することができる。
【００５２】
本発明の第４実施例は、認証された実行のレイヤを追加する。認証された実行のコンセプトは、従来技術文献において記載されている。セキュリティ装置のユーザにセキュリティプログラムがセキュリティ装置上で実際に及びセキュアに実行されることを保証するため、共有秘密を生成するセキュリティプログラムは、認証された実行を実現する他のセキュリティプログラムの制御の下で実行される。この技術は、具体的実現形態により示される。認証された実行は、いわゆる電子証明書を用いて提供される。セキュリティ装置上の入力ＩｎｐｕｔによるプログラムＸＰｒｏｇｒａｍの電子証明書は、ＸＰｒｏｇｒａｍの出力される結果がセキュリティ装置上でＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）により生成されたか、セキュリティ装置のユーザがかなりの確率により効率的にチェックすることができるように、セキュリティ装置上でＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）により効率的に生成される文字列として規定される。セキュリティ装置上でのＸＰｒｏｇｒａｍの実行をリクエストするユーザは、セキュリティ装置の所有者に頼る代わりに、自らがセキュリティ装置を生成したということを保証することができるセキュリティ装置のメーカーの信頼性に頼ることができる。
【００５３】
図６は、計算がセキュリティ装置上で直接実行される認証された実行を示す。ユーザであるアリスは、ボブのコンピュータ６０１上で計算量の大きなプログラムＰｒｏｇｒａｍ（Ｉｎｐｕｔ）を実行することを所望している。ボブのコンピュータは、ＰＵＦ６０３を有するセキュリティ装置６０２を有する。アリスは、セキュリティ装置によるＣＲＰ６１１のリストをすでに確立していると仮定する。（Ｃｈａｌｌｅｎｇｅ，Ｒｅｓｐｏｎｓｅ）をボブのＰＵＦに対するアリスのＣＲＰの１つであるとする。第１の実現形態の変形では、アリスは、（Ｃｈａｌｌｅｎｇｅ，Ｅ＆Ｍ（（ＸＰｒｏｇｒａｍ，Ｉｎｐｕｔ），ｈ（ｈ（ＣＰｒｏｇｒａｍ），Ｒｅｓｐｏｎｓｅ）））に等しい入力Ｉｎｐｕｔｓ６３２による以下のプログラムＣＰｒｏｇｒａｍ１（６３１）をセキュリティ装置６０２に送信する（通信６２１により）。
【００５４】
【表３】
Ｒｅｓｕｌｔ＝ＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）によって、ＲｅｓｕｌｔはＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）の出力の一部であると理解される。電子プルーフが必要とされないさらなる出力があるかもしれない。Ｏｕｔｐｕｔ（．．．）は、通信６２２に示されるように、ＣＰＵＦからの結果６３３を送信するのに利用される。セキュリティ装置から送信されるものは、潜在的には全世界に明白にされる（メーカーがセキュリティ装置を物理的に所持するブートストラッピング中を除いて）。プログラムのセキュアな設計は、Ｒｅｓｕｌｔに暗号化形式により配置される結果を生成する。暗号化は、従来の暗号化又はＳｅｃｒｅｔを用いることによって実行可能である。後者のケースでは、ＳｅｃｒｅｔはＩｎｐｕｔに含まれる。
【００５５】
アリスのＣＲＰはプライベートであるため、他の何れの者もＳｅｃｒｅｔと、ＳｅｃｒｅｔによるＭＡＣを生成することはできない。ＭＡＣは、プログラムの２つのスポットにおいて利用される。第１ＭＡＣは、プログラムによりチェックされ、Ｉｎｐｕｔｓの真正性を保証する。第２ＭＡＣは、アリスによりチェックされ、セキュリティ装置から取得したメッセージの真正性を保証する。アリスを除いて、セキュリティ装置のみが、プログラムＣＰｒｏｇｒａｍを実行することによりＳｅｃｒｅｔが与えられたチャレンジを生成することができる。このことは、ＲｅｓｕｌｔとＣｅｒｔｉｆｉｃａｔｅがセキュリティ装置上でＣＰｒｏｇｒａｍにより生成されたことを意味する。すなわち、ＣＰｒｏｇｒａｍは入力としてＩｎｐｕｔｓにより認証された実行を実行したこととなる。これは、Ｃｅｒｔｉｆｉｃａｔｅが電子証明書であることを証明する。
【００５６】
従って、電子証明書は共有される秘密を生成するセキュリティプログラムのセキュアなリモート計算に利用可能である。Ｃｅｒｔｉｆｉｃａｔｅが一致する場合、このことは、ＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）がセキュリティ装置上で（ＣＰｒｏｇｒａｍ（Ｉｎｐｕｔｓ）により）実行されたことをアリスに証明するものである。
【００５７】
セキュリティ装置の所有者（ボブ）とセキュリティ装置のユーザ（アリス）とは、１つの同一のものであってもよいということに留意されたい。例えば、ボブは、自分がＰｒｏｇｒａｍ（Ｉｎｐｕｔ）によりＲｅｓｕｌｔを計算したことを自らの電子プルーフにより他人に証明する。最終的に、本発明の効果は、アリスも仲介者もＰＵＦを備えたセキュリティ装置を必要としないということである。
【００５８】
本発明は、それがデジタルだけでなく、フィジカル又はオプティカルであるすべてのＰＵＦに適用可能であるという意味において一般的に適用可能である。構成の詳細は、フィジカルＰＵＦについて与えられているが、デジタル又はオプティカルＰＵＦに振り替えることができる。
【００５９】
他のものも可能である。上記記載において、「有する」という用語は他の要素又はステップを排除するものでなく、「ある」という用語は複数を排除するものでなく、単一のプロセッサ又は他のユニットもまた、請求項に記載されるいくつかの手段の機能を実現するかもしれない。
【図面の簡単な説明】
【００６０】
【図１】図１は、ＰＵＦを利用したアプリケーションに対する基本的モデルを示す。
【図２】図２は、共有される秘密の生成を示す。
【図３】図３は、共有される秘密を生成するための一例となる利用シナリオを示す。
【図４】図４は、認証された実行の下で共有秘密を生成するための各プログラムレイヤの概略を示す。
【図５】図５は、割り込みされた処理を示す。
【図６】図６は、認証された実行を示す。
【技術分野】
【０００１】
本発明は、第１セキュリティプログラムと少なくとも第２セキュリティプログラムとの間で共有される秘密を生成する方法と、当該方法を実現するよう構成されるシステムと、当該方法を実現するためのコンピュータプログラムプロダクトと、当該方法を実現するためのコンピュータ実行可能命令と、当該方法により生成される結果を搬送する信号とに関する。
【背景技術】
【０００２】
電子取引などのプリケーションでは、計算（又はプログラム）がユーザ又は第三者によって特定のプロセッサ上で実際に実行されたことを検証することが要求されるかもしれない。Ｂｌａｉｓｅ Ｇａｓｓｅｎｄ、Ｄｗａｉｎｅ Ｃｌａｒｋｅ、Ｍａｒｔｅｎ ｖａｎ Ｄｉｊｋ及びＳｒｉｎｉｖａｓ Ｄｅｖａｄａｓによる“Ｃｏｎｔｒｏｌｌｅｄ Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ｆｕｎｃｔｉｏｎｓ”（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １８ｔｈ Ａｎｎｕａｌ Ｃｏｍｐｕｔｅｒ Ｓｅｃｕｒｉｔｙ Ａｐｐｌｉｃａｔｉｏｎｓ Ｃｏｎｆｅｒｅｎｃｅ，Ｄｅｃｅｍｂｅｒ，２００２）（以降において「従来技術文献」と呼ぶ）において、ＰＵＦに結合されたチャレンジ・レスポンスペアを生成及び検証するためのフレームワークが規定されている。フィジカル・ランダム・ファンクション（ＰＵＦ）は、複雑な物理システムを用いて評価されるランダムファンクションである。ＰＵＦという略語の使用は（ＰＲＦの代わりに）、発音するのがより容易であるという効果を有し、擬似ランダムファンクション（Ｐｓｅｕｄｏ−Ｒａｎｄｏｍ Ｆｕｎｃｔｉｏｎ）との混同を回避する。ＰＵＦは様々な方法により実現可能である。ＰＵＦの実現形態のいくつかは、各生成サンプル（各半導体チップなど）が異なるファンクションを実現するように生成することが容易である。これは、ＰＵＦを認証識別アプリケーションに利用することを可能にする。
【０００３】
ＰＵＦは、チャレンジをレスポンスに変換し、物理装置により実現され、以下の２つの性質を有するファンクションである。すなわち、（１）ＰＵＦは評価が容易である。すなわち、物理装置は、短い時間でファンクションを容易に評価することができる。（２）ＰＵＦは特性化が困難である。すなわち、ポリノミアル（ｐｏｌｙｎｏｍｉａｌ）数のもっともらしい（ｐｌａｕｓｉｂｌｅ）物理的測定から（特に、選ばれたチャレンジ・レスポンスペアの決定）、もはやセキュリティ装置を有さず（アクセスできず）、ポリノミアル量のリソース（時間、物質など）しか利用できない攻撃者は、ランダムに選択されたチャレンジに対するレスポンスに関してわずかな情報しか抽出することができない。上記定義では、「短い」及び「多項式の」という用語は、セキュリティパラメータである装置のサイズに相対するものである。特に、「短い」という用語は、リニア又は低い程度のポリノミアルを意味する。「もっともらしい」という用語は、最新の測定技術に相対するものであり、改良された方法が創出されるに従い変化する可能性がある。
【０００４】
ＰＵＦの具体例として、シリコンＰＵＦ（Ｂｌａｉｓｅ Ｇａｓｓｅｎｄ、Ｄｗａｉｎｅ Ｃｌａｒｋｅ、Ｍａｒｔｅｎ ｖａｎ Ｄｉｊｋ及びＳｒｉｎｉｖａｓ Ｄｅｖａｄａｓによる“Ｓｉｌｉｃｏｎ Ｐｈｙｓｉｃａｌ Ｒａｎｄｏｍ Ｆｕｎｃｔｉｏｎｓ”（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ ９ｔｈ ＡＣＭ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｃｏｍｐｕｔｅｒ ａｎｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｅｃｕｒｉｔｙ，Ｎｏｖｅｍｂｅｒ，２００２）、オプティカルＰＵＦ（マサチューセッツ工科大のＰ．Ｓ．Ｒａｖｉｋａｎｔｈによる“Ｐｈｙｓｉｃａｌ Ｏｎｅ−Ｗａｙ Ｆｕｎｃｔｉｏｎｓ（２００１）、デジタルＰＵＦなどがあげられる。シリコンＰＵＦは、製造工程に帰因するチップ間のばらつきを利用する、オプティカルＰＵＦは、コヒーレント光（レーザ）ビームにより放射される光構成によって生成されるスペックルパターンの予測不能性を利用する。デジタルＰＵＦは、改ざん耐性環境が、暗号化及び認証用に利用される秘密鍵をプロテクトする従来シナリオを表す。
【０００５】
ＰＵＦは、それがセキュリティ装置内で分離不可な方法により（すなわち、当該アルゴリズムを回避しようとする何れの試みも、ＰＵＦの破壊を導く）ＰＵＦに物理的にリンクしたセキュリティアルゴリズムを介してのみアクセス可能である場合、被制御であると定義される（被制御ＰＵＦ又はＣＰＵＦ）。特に、当該セキュリティアルゴリズムは、ＰＵＦに提供されるチャンレンジを制限し、外部の世界に与えられるレスポンスに関する情報を制限することができる。制御は、ＰＵＦがシンプルな認証識別アプリケーションに勝ることを可能にする基本的アイデアである。
【０００６】
ＣＰＵＦの具体例については、従来技術文献に記載されている。セキュリティプログラムは、ＰＵＦがセキュリティプログラムから２つのプリミティブファンクションＧｅｔＳｅｃｒｅｔ（．）及びＧｅｔＲｅｓｐｏｎｓｅ（．）を介してのみアクセス可能となるように、セキュリティアルゴリズムの制御の下で利用され、ＰＵＦとリンクされる。ＧｅｔＳｅｃｒｅｔ（．）は、プリミティブファンクションが実行されるセキュリティプログラムの表現にＰＵＦへの入力が依存することを保証する。この依存性のため、ＰＵＦへの入出力は、これらのプリミティブファンクションが異なるセキュリティプログラム内から実行される場合には、異なるものとなるであろう。さらに、これらのプリミティブファンクションは、新たなチャレンジ・レスポンスペアの生成が、従来技術文献に記載されるように、規制され、セキュアとすることが可能であることを保証する。
【０００７】
しかしながら、上記プリミティブファンクションの出力はセキュリティプログラムの表現に依存するとき、それらは同一のＰＵＦ上で実行される異なるセキュリティプログラムの間で共有される秘密を生成するのに利用可能でない。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明の課題は、異なるセキュリティアルゴリズムの間で共有される秘密を生成することを可能にする方法を提供することである。
【課題を解決するための手段】
【０００９】
上記課題は、第１セキュリティプログラムと少なくとも第２セキュリティプログラムとの間で共有される秘密を生成する方法であって、被制御インタフェースを介しセキュリティプログラムのみからアクセス可能なランダムファンクションを有するセキュリティ装置上で、前記第１セキュリティプログラムの制御の下でプログラム命令を実行するステップを有し、前記被制御インタフェースは、プリミティブファンクションを呼び出す前記第１セキュリティプログラムの表現の少なくとも一部と、前記セキュリティ装置上で前記第２セキュリティプログラムを実行すると、前記プリミティブファンクションを呼び出す前記第２セキュリティプログラムの表現の少なくとも一部とに依存する出力を返す前記ランダムファンクションにアクセスする少なくとも１つのプリミティブファンクションを有し、前記ステップは、前記共有される秘密を生成するため前記少なくとも１つのプリミティブファンクションを呼び出すサブステップを有する方法により実現される。これにより、共有される秘密は、各セキュリティプログラムが入力としてのプリミティブファンクションが呼び出されるセキュリティプログラムの表現と、秘密が共有されるべきその他のセキュリティプログラムの表現との両方と共にプリミティブファンクションを呼び出すことによって、２以上のセキュリティプログラムの間で確立することが可能である。これらセキュリティプログラムのそれぞれがプリミティブファンクションへの入力として、関係するセキュリティプログラムの表現を利用するため、同一の秘密が各セキュリティプログラムにより生成される。
【００１０】
出力をセキュリティプログラムの表現に依存させることによって、セキュリティ装置上で実行される他の何れかのセキュリティプログラムが、被制御インタフェースを介し同一の入力に対して異なる結果を取得することが、（ほとんど）保証される。共有されるキーを取得するようハッカーによって設計される他の何れかのセキュリティプログラムが、被制御インタフェースを介し役に立たない結果のみを取得する（表現方法に依存して高い確率により）。なぜなら、これらの結果は、ハッカーによって使用される他のセキュリティプログラムともとのセキュリティプログラムに対して異なるセキュリティプログラム表現に依存するためである。他の何れのセキュリティプログラムも、秘密キーを再生成し、ランダムファンクションによって提供されるセキュリティを危うくする方法によってはランダムファンクションにアクセスすることはできない。
【００１１】
セキュリティプログラムの表現は、ハッシュ、他のシグネチャ又は他の一部とすることが可能である。通常、セキュリティプログラムの表現は、完全なセキュリティプログラムをカバーするが、特別なケースでは（例えば、セキュリティプログラムがランダムファンクションに関係ない大きな部分を含む場合など）、プリミティブファンクションの入出力の呼び出し及び処理を扱うセキュリティプログラムのこれらの部分に表現を限定することが効果的であるかもしれない。
【００１２】
セキュリティプログラムは、典型的には、セキュリティ装置のユーザにより提供される。代わりとして、セキュリティプログラムはまた、セキュリティ装置内の別のプログラムライブラリによって提供することが可能である。
【００１３】
以降の利用のため特定のセキュリティプログラムの迅速な抽出を可能にするため、プログラムは、任意的に以降の実行が許可されている許可に関する情報と共に、セキュリティプログラムの以降の実行のため、格納又はハッシュコードとすることが可能である。
【００１４】
本発明のより特定の実現形態が、請求項２に記載されている。プログラム表現はすべて、明示的にはプログラムＰｒｏｇ１．．ＰｒｏｇＮについて、又は暗黙的にはプリミティブファンクションが呼び出されるプログラムＰｒｏｇｒａｍについて、ランダムファンクションへの入力として使用される。これを実現するため、プリミティブファンクションは、プリミティブファンクションを呼び出すセキュリティプログラムとその他のセキュリティプログラムの表現が区別されないようにしなければならない。異なるセキュリティプログラムが同一の共有された秘密を生成することを保証するため、辞書式順序付けが適用される。
【００１５】
本発明のより特定の実現形態が、請求項３に記載されている。好ましくは（ほとんど）コリジョンフリーであるランダムハッシュファンクションｈ（．）が利用されるとき、これらのプリミティブファンクションは、セキュリティプログラムの間で共有されるキーとして使用されるキーを確実に生成するのに効果的に利用可能である。請求項１に記載されるように、Ｐｒｏｇｒａｍ及びＰｒｏｇ１．．ＰｒｏｇＮは、セキュリティプログラムの関連する部分のみを表現することが理解されるべきである（セキュリティの観点から）。
【００１６】
本発明の一変形が、請求項４に記載される。請求項２のような辞書式順序付けを計算する必要の代わりに、プログラム表現がプリミティブファンクションへの入力として利用される前に、各セキュリティプログラムに同じ順序により容易に再順序付け可能となるように、当該変形はセキュリティプログラムが番号付けされることに依拠する。
【００１７】
本発明の一変形が、請求項５に記載される。２００４年５月６日に出願された特許出願ＵＳ２００４／０１４４０４（代理人整理番号ＰＨＮＬ０３０６０５）は、セキュリティプログラムが第１モードにより実行することによって生成され、同一のセキュリティプログラムが第２モードにより実行されることによって検証可能な実行のプルーフを記載している。当該手段の問題点は、双方のモードを含む完全なセキュリティプログラムが、プリミティブファンクションにおける利用及び実行のため、セキュリティプログラムにおいて利用可能とされる必要があるということである。本発明による方法は、第１モード部分又は第２モード部分のみが独立したセキュリティプログラムとして必要とされ、各セキュリティプログラムが共有される秘密を依然として生成することが可能であるとき、依然としてセキュリティが利用可能であるという効果を有している。
【００１８】
本発明の一変形が、請求項６に記載されている。２００４年５月６日に出願された特許出願ＵＳ２００４／０１４４０４（代理人整理番号ＰＨＮＬ０３０６０５）は、セキュリティプログラムの以降の継続のために考えられるセキュリティプログラムによるセキュア状態情報のコンセプトをさらに記載する。このコンセプトは、複数のセキュリティプログラムがセキュリティ装置上で実行することを効果的に可能にする２以上のセキュリティプログラムをスケジューリングするのに利用可能である。これらの各セキュリティプログラムは、本発明による方法により取得される共有される秘密キーを利用してセキュアに通信可能である。
【００１９】
本発明の効果的な実現形態が、請求項７に記載されている。従来技術文献では、認証された実行は、特定のプロセッサチップのユーザに、特定の計算が当該プロセッサチップ上で実行され、当該計算が実行され、与えられた計算出力を生成したことを証明する証明書（電子証明書と呼ばれる）を計算出力と共に生成するプロセスとして定義される。セキュリティ装置のユーザに、セキュリティプログラムが実際に同一のセキュリティ装置上で実行されることを証明するため、セキュリティプログラムは、好ましくは、従来技術文献に記載されるような認証された実行を実現する第２セキュリティプログラムの一部として実行される。
【００２０】
本発明のより特定の実現形態が、請求項８に記載される。当該実現形態では、プリミティブファンクションにおいて利用されるランダムファンクションを実現するため、ＰＵＦが利用される。
【００２１】
本発明のより特定の実現形態が、請求項９に記載されている。本実現形態における生成された共有秘密キーはまた、入力変数の少なくとも一部に依存する。これは、共有される秘密の生成について使用するため、（アプリケーション）プログラム入力がセキュリティプログラムにハードコード化される必要がないという効果を有する。一部の入力は関係がないかもしれないため、セキュリティ装置と当該セキュリティ装置のユーザとの間で秘密が維持される場合（従って、第三者に通信されない場合）、又は異なるプログラムの実行の間で異なるものとすることが許容される場合、必ずしもすべての入力が考慮される必要はない。
【００２２】
本発明によるシステムが、請求項１０に記載されるように特徴付けされる。
【００２３】
本発明によるコンピュータ可読媒体などのコンピュータプログラムプロダクトが、請求項１１に記載されるように特徴付けされる。
【００２４】
本発明による信号が、請求項１２に記載されるように特徴付けされる。
【００２５】
本発明の上記及び他の特徴が、概略図を参照して実施例を通じてさらに説明される。
【発明を実施するための最良の形態】
【００２６】
図面を通じて、同一の参照番号は同様又は対応する特徴を示す。図面に示される特徴の一部は、典型的にはソフトウェアにより実現され、ソフトウェアモジュールやオブジェクトなどのソフトウェアエンティティを表す。
【００２７】
図１は、従来技術によるＰＵＦ１０４を有するセキュリティ装置１０３を利用するアプリケーションのための基本的モデルを示す。システム１００により実現されるモデルは、以下を有する。
・セキュリティ装置１０３の制御における又は制御下のチップ１０５の計算能力を利用することを所望するユーザ１０３
・当該ユーザ及びチップは、おそらく信頼されない公衆通信チャネル１０２により互いに接続されている。ユーザは、人間とすることが可能であるだけでなく、異なるソフトウェア、ハードウェア又は他の装置とすることが可能である。
【００２８】
セキュリティ装置１０３は、プロセッサ１１１とメモリ１１２とを有し、コンピュータプログラムプロダクト１１３からのコンピュータ実行可能命令を実行するよう構成される処理装置１１０により実現可能である。
【００２９】
従来技術文献は、各特定のＰＵＦに対して一意的なチャレンジ及びレスポンスの処理を記載している。チャレンジが与えられると、ＰＵＦは対応するレスポンスを計算することができる。ユーザは、ＰＵＦにより当初生成されたＣＲＰ（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ Ｐａｉｒ）の自己のプライベート（認証された）リストを所有する。このリストは、当該ユーザのみが（おそらくＰＵＦに加えて）リストの各チャレンジに対するレスポンスを知っているという理由のため、プライベートなものである。ユーザのチャレンジはパブリックなものとすることが可能である。ユーザはセキュリティ装置によりいくつかのＣＲＰを確定していると仮定される。
【００３０】
（限定数の）チャレンジに対するレスポンスは、ユーザにのみ知られている。さらに、セキュリティ装置は、特定のチャレンジに対するレスポンスを（再）計算するかもしれない。他者が特定のチャレンジに対してレスポンスを復元することを回避するため、ＣＲＰを管理するセキュアな方法が必要とされる。従来技術文献は、これを実現するための被制御ＰＵＦのコンセプトを提案している。ＰＵＦは、それがセキュリティ装置内で分離不可な方法により（すなわち、当該アルゴリズムを回避しようとする何れの試みも、ＰＵＦの破壊を導く）ＰＵＦに物理的にリンクしたセキュリティアルゴリズムを介してのみアクセス可能である場合、被制御であると定義される（被制御ＰＵＦ又はＣＰＵＦ）。特に、当該セキュリティアルゴリズムは、ＰＵＦに提供されるチャンレンジを制限し、外部の世界に与えられるレスポンスに関する情報を制限することができる。制御は、ＰＵＦがシンプルな認証識別アプリケーションに勝ることを可能にする基本的アイデアである。ＰＵＦ及び被制御ＰＵＦは、スマートカード識別、認証実行及びソフトウェアライセンシングを実現するため説明及び知られている。
【００３１】
マン・イン・ザ・ミドル（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ）攻撃者を回避するため、ユーザはＣＲＰ管理プロトコル期間中には特定のチャレンジに対するレスポンスを求めることが禁止されている。これは、これらのプロトコルによりセキュリティ装置がユーザにレスポンスを送信するときに、ＣＲＰ管理プロトコルにおいて懸念されることである。これは、セキュリティ装置がチャレンジ対するレスポンスを直接的には提供しないように、ＰＵＦへのアクセスを制限することにより保証される。ＣＲＰ管理は、従来技術文献に記載されるように行われる。アプリケーションプロトコルでは、レスポンスは、メッセージ認証コード（ＭＡＣ）を生成するためなど、さらなる処理のために内部的にのみ使用され、ユーザに送信されることはない。ＣＰＵＦは、プライベートな方法により（当該プログラムが行っていることを誰も見ることができず、あるいは操作されている少なくともキー材料が隠されたままにされる）、また信頼できる方法により（検出されることなく、プログラムが行っていることを誰も変更することができない）、ある形式のプログラム（以降において、セキュリティプログラム）を実行することができる。
【００３２】
ＣＰＵＦの制御は、ＰＵＦがセキュリティプログラムを介してのみ、より具体的には２つのプリミティブファンクションＧｅｔＲｅｓｐｏｎｓｅ（．）及びＧｅｔＳｅｃｒｅｔ（．）を利用することによってのみアクセス可能となるように構成される。従来技術文献において使用されるプリミティブファンクションのセットは、
・ＧｅｔＲｅｓｐｏｎｓｅ（ＰＣ）＝ｆ（ｈ（ｈ（ＳＰｒｏｇｒａｍ），ＰＣ））
・ＧｅｔＳｅｃｒｅｔ（Ｃｈａｌｌｅｎｇｅ）＝ｈ（ｈ（ＳＰｒｏｇｒａｍ），ｆ（Ｃｈａｌｌｅｎｇｅ））
として定義される。ここで、ｆはＰＵＦであり、ｈは公開利用可能なランダムハッシュファンクション（又は、実際的にはある擬似ランダムファンクション）である。これらのプリミティブファンクションにおいて、ＳＰｒｏｇｒａｍは、信頼できる方法により実行されているセキュリティプログラムのコードである。当該装置のユーザが、このようなセキュリティプログラムを配信する。ｈ（ＳＰｒｏｇｒａｍ）は、ハードコード化された値（一部のケースでは、チャレンジなど）を含むプログラムに含まれるすべてを含む。セキュリティ装置は、ｈ（ＳＰｒｏｇｒａｍ）を計算し、以降においてＧｅｔＲｅｓｐｏｎｓｅ（．）とＧｅｔＳｅｃｒｅｔ（．）が呼び出されると、この値を利用する。ｈ（ＳＰｒｏｇｒａｍ）の計算は、セキュリティプログラムの開始前又はプリミティブファンクションの最初のインスタンス化（直）前に実行することができる。従来技術文献に示されるように、これら２つのプリミティブファンクションは、ＧｅｔＲｅｓｐｏｎｓｅ（．）がＣＲＰの生成に原則的に利用され、ＧｅｔＳｅｃｒｅｔ（．）がＣＲＰから共有される秘密を生成することを所望するアプリケーションにより利用されるセキュアなＣＲＰ管理を実現するのに十分である。
【００３３】
以降において、以下の記号が使用される。
・Ｅ（ｍ，ｋ）は、キーｋによりメッセージｍの暗号化である。
・Ｄ（ｍ，ｋ）は、キーｋによるメッセージｍの解読である。
・Ｍ（ｍ，ｋ）は、キーｋによりメッセージｍをＭＡＣする。
・Ｅ＆Ｍ（ｍ，ｋ）は、キーｋによりメッセージｍを暗号化及びＭＡＣする。
・Ｄ＆Ｍ（ｍ，ｋ）は、ＭＡＣが一致する場合、キーｋによりメッセージｍを解読する。ＭＡＣが一致しない場合、ＭＡＣが一致せず、解読を実行しない旨のメッセージを出力する。
【００３４】
図２に示されるような本発明の第１実施例は、共有される秘密を生成するセキュリティプログラムを実行する例を示す。セキュリティプログラム２３１は、セキュリティプログラム２３１は、共有キーが生成されるその他のセキュリティプログラムのハッシュコード表現（本例では、ｈ＿ＳＰｒｏｇＢ＝ｈ（ＳＰｒｏｇＢ）である）を有するセキュリティプログラムのための入力２３２と共に、実行のためＰＵＦ２０３を有するセキュリティ装置２０２を有するシステム２０１に通信２２１により送信される。その後、セキュリティプログラムＳＰｒｏｇＡは、
・ＧｅｔＲｅｓｐｏｎｓｅＳＫ（ＰＣ）＝ｆ（ｈ（ＰＨＲ，ＰＣ））
・ＧｅｔＳｅｃｒｅｔＳＫ（Ｃｈａｌｌｅｎｇｅ）＝ｈ（ＰＨＲ，ｆ（Ｃｈａｌｌｅｎｇｅ））
として定義される本発明によるプリミティブファンクションを利用して、セキュリティ装置に関する共有秘密を生成する。ただし、
・ＰＨＲ＝Ｏｒｄｅｒｉｎｇ（ｈ（ＳＰｒｏｇｒａｍ），Ｖａｌ，Ｒｕｌｅ）
である。
【００３５】
Ｏｒｄｅｒｉｎｇファンクションは、Ｒｕｌｅの値に従って入力パラメータの再順序付けを規定する。Ｒｕｌｅの値は、ＰＨＲとプリミティブファンクションの出力が、共有秘密を生成することを所望する異なるセキュリティプログラムにおいて同一であることを保証するのに利用可能である。生成される共有秘密は、その後は秘密キーとして利用可能である。Ｏｒｄｅｒｉｎｇファンクションは、セキュリティプログラムの表現値の辞書式順序付けとすることも可能であり、あるいはＲｕｌｅの値は上記表現値が連結される順序を決定するものであってもよい。
【００３６】
【表１】
プログラムＳＰｒｏｇＡにおいては、ｈ（Ｏｒｄｅｒｉｎｇ（ｈ（ＰｒｏｇＡ），Ｖａｌ，Ｒｕｌｅ））＝ｈ（Ｏｒｄｅｒｉｎｇ（ｈ（ＰｒｏｇＡ），ｈ（ＰｒｏｇＢ），０））＝ｈ（ｈ（ＰｒｏｇＡ），ｈ（ＰｒｏｇＢ））となる。プログラムＳＰｒｏｇＢにおいては、ｈ（Ｏｒｄｅｒｉｎｇ（ｈ（ＰｒｏｇＢ），Ｖａｌ，Ｒｕｌｅ））＝ｈ（Ｏｒｄｅｒｉｎｇ（ｈ（ＰｒｏｇＢ），ｈ（ＰｒｏｇＡ），１））＝ｈ（ｈ（ＰｒｏｇＡ），ｈ（ＰｒｏｇＢ））となる。従って、双方のプログラムは、同一の入力をプリミティブファンクションＧｅｔＲｅｓｐｏｎｓｅＳＫに適用する。
【００３７】
本発明の第２実施例は、実行のプルーフ（ｐｒｏｏｆ）の生成及び検証のため、別々のセキュリティプログラムを有するための共有秘密の利用を示す。２００４年５月６日に出願された特許出願ＵＳ２００４／０１４４０４（代理人整理番号ＰＨＮＬ０３０６０５）は、第１モードが実行のプルーフを生成し、第２モードが実行のプルーフを検証するマルチモードセキュリティプログラムを利用した実行のプルーフの生成及び検証を記載している。本発明によると、別々のセキュリティプログラムを利用して実行のプルーフを生成し、それを検証することが可能であり、これにより、プログラムダウンロード及び初期化のオーバヘッドを軽減することが可能となる。それはまた、セキュリティプログラムの表現計算の計算負荷を軽減するかもしれない。
【００３８】
実行のプルーフをサポートするため、認証された実行の解を実行のプルーフを生成するための付加的なプログラムレイヤにより拡張することが効果的である。
【００３９】
本実施例が利用可能な第１の例として、図３に示されるように、アリスが配信者３１０であり、ボブがセキュリティ装置３０１を有するＳＴＢ（セットトップボックス）３００の所有者となるＳＴＢアプリケーションを考える。プログラムＡ３２０において、ボブはあるサービスを購入する。アリスは、取引詳細３３２と、電子証明書３３３（当該電子証明書は、取引詳細と電子プルーフの両方の真正性を証明する）と、電子プルーフ３３４とを受信する。アリスは、ステップ３４０において、電子証明書が一致するかチェックする。そうである場合、アリスは、電子プルーフがボブのＳＴＢにより生成されたものであることを知り、プログラムＢにおいて取引を継続する。電子プルーフは、仲介者が取引詳細を復元可能であるため、ボブがサービスを購入したという確認として利用可能である。プログラムＢ３２１において、ボブは、ボブが要求したサービスに属するコンテンツ３３５を受信する。当該コンテンツは、ＣＲＰを利用することによって暗号化されてもよい。アリスは、プログラムＢにおいてボブのアクションの第２の電子プルーフ３３６を受信する。第１の例では、それは、ボブにプログラムＢにおいて当該コンテンツを送るアリスの約束のプルーフを受信していないようにみえる。しかしながら、アリスだけでなくボブもまた、第１の電子プルーフを利用することが可能である。ボブのＳＴＢがプログラムＡにおいて符号化されたプロトコルを良好に実行したことを何れかの第三者がチェック可能であり、それ自体プログラムＢにおいてボブにコンテンツを送信するアリスの約束となる。例えば、ボブは、電子プルーフを利用して、ボブがあるサービスを購入したことを第三者（及び特にアリス）に確信させることが可能であり、それが、ボブをディスカウントやアップグレードの対象とすることを可能にするかもしれない。
【００４０】
第２の例として、アリスが入力の一部としてタイムスタンプを有するプログラムをボブのセキュリティ装置上で実行することを所望していると仮定する。この実行結果は、当該タイムスタンプが正確な実行時間を表すというボブとの合意によるタイムスタンプのコピーを含むかもしれない。例えば、プログラムは、それがボブに同意するか尋ね、ボブが同意しない場合には中断するよう設計される。正しい電子プルーフが与えられると、仲介者は当該結果を抽出する。このため、ボブは、タイムスタンプをチェックし、ボブ及び／又はアリスの主張が依然として有効であるか否か検証することができる。
【００４１】
第３の例として、異なるモードによるプログラムＰｒｏｇｒａｍ’を仮定する。それのモードに応じて、Ｐｒｏｇｒａｍ’はプロセッサＰ上で（Ｒｅｓｕｌｔ，ＥＰｒｏｏｆ）＝Ｐｒｏｇｒａｍ（Ｉｎｐｕｔ）を計算するか（ただし、ＥＰｒｏｏｆは、Ｐに対する入力ＩｎｐｕｔによるプログラムＰｒｏｇｒａｍの電子プルーフである。）、又はＰｒｏｇｒａｍ’が、ＥＰｒｏｏｆが有効な電子プルーフであるかチェックする仲介者の役割を果たし、そうである場合には、Ｒｅｓｕｌｔを再構成する。仲介者の役割では、ＥＰｒｏｏｆはＰｒｏｇｒａｍ’における次のモードへのチケットとして利用されてもよい。この技術は、限定的なアクセスを実現する。
【００４２】
図４は、各種プログラムレイヤを示す。それぞれ実行のプルーフ、ＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ４０３及びＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ４５３を生成検証する本発明によるプログラムはそれぞれ、ユーザと第三者の双方がセキュリティ装置上で実行が行われたことを確信するため、ＰＵＦ４０１を備えるセキュリティ装置４００において各自の認証された実行プログラムＣＰｒｏｇｒａｍ１（４０２及び４５４）のＸＰｒｏｇｒａｍ部分として実行される。
【００４３】
ＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎは、アリスが興味を有する結果だけでなく、電子プルーフも計算する（ＡＰｒｏｇｒａｍ４０６において）。アリスは、認証された実行を利用して（ＣＰｒｏｇｒａｍのＸＰｒｏｇｒａｍ部分としてＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎを実行することによって）、当該プログラムがボブのセキュリティ装置上で正確に実行されたことを確信する。仲介者は、ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎを実行し、さらに認証された実行を利用することによって、電子プルーフをチェックすることができる。そのキーとなるアイデアは、ＧｅｔＲｅｓｐｏｎｓｅ（．）プリミティブが、双方のセキュリティ装置のハッシュに依存するということである。この結果、（ＧｅｔＲｅｓｐｏｎｓｅ（．）プリミティブを介し取得されたキーにより）実行のプルーフを生成するためセキュリティプログラムによって生成された電子プルーフは、実行のプルーフの検証のためセキュリティプログラムにより解読することが可能である。
【００４４】
セキュリティは、第１にＧｅｔＲｅｓｐｏｎｓｅ（．）プリミティブをブレークする困難性によって、すなわち、ハッシュをブレークし、ＧｅｔＲｅｓｐｏｎｓｅ（．）が定義されるＰＵＦをブレークする困難性によって、そして第２に暗号化及びＭＡＣ Ｅ＆Ｍ（．）プリミティブをブレークする困難性によって決定される。
【００４５】
これらのプログラムの変形が可能である。一部のプログラムは、入力の一部をハードコード化するかもしれず、これはフレキシビリティを低下させるが、よりロウバストになる。プルーフ結果に存在する出力量もまた異なる。これらのアルゴリズムの任意の変形が実現可能である。
【００４６】
第１の変形では、アリスは、ＡＰｒｏｇｒａｍ（Ｉｎｐｕｔ）を実行し、実行プルーフを受け取ることを所望し、これにより、ＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ（Ｉｎｐｕｔｓ）（４３１）を実行する。ただし、ｈ（ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ）に等しいＶａｌ４３２とランダム文字列であるＰＣ４３３によるＩｎｐｕｔｓ＝（ｈ（ＥＰｒｏｇｒａｍ＿ｖｅｒｆｉｃａｔｉｏｎ），ＡＰｒｏｇｒａｍ，Ｉｎｐｕｔ，ＰＣ）（４３５：ＡＰｒｏｇｒａｍ，４３４：Ｉｎｐｕｔによる）であり、ＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎは以下に定義されるようなものである。ＰＣは、秘密キーＫＥを生成するため、ランダムファンクションに対するチャレンジを計算するため、ＧｅｔＲｅｓｐｏｎｓｅ（．）により“プレ・チャレンジ（ｐｒｅ−ｃｈａｌｌｅｎｇｅ）として利用される。アリスは、認証された実行の技術を利用して、前述されたようなＣＰｒｏｇｒａｍ４３０を利用したボブのセキュリティ装置上でＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ（Ｉｎｐｕｔｓ）を実行する。アリスは、セキュリティ装置から取得したすべての出力の真正性を検証するため、電子証明書をチェックする。生成された電子証明書は、Ｐｒｏｇｒａｍ（Ｉｎｐｕｔ）により生成された結果４３８の証明書だけでなく、生成された電子プルーフ４３６の証明書となる。
【００４７】
【表２】
実行のプルーフは、ボブのセキュリティ装置によりプロトコルを実行する何れかの仲介者により検証可能であり、当該検証は３つのステップを有している。ステップ１では、仲介者はステップ４５０においてアリス又はボブから実行のプルーフであるＥＰｒｏｏｆを受け取る。仲介者はＩｎｐｕｔｓ＝（ｈ（Ｅｐｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ），ＥＰｒｏｏｆ）（ＥＰｒｏｏｆ：４４４）を構成する。ここで、Ｖａｌ４４２は、共有される秘密キーを生成するのに必要とされるセキュリティプログラム表現である。仲介者はまた、おそらくアリス又はボブからＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ及びＣＰｒｏｇｒａｍ（おそらく以前に実行されたようなものであって、本例では、ステップ４５１及び４５２において仲介者に通信される）。仲介者はＰＣを必要としないことに留意されたい。
【００４８】
ステップ２では、仲介者は、ＣＰｒｏｇｒａｍ４４０による認証された実行の技術を利用して、ボブのセキュリティ装置上でＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ（Ｉｎｐｕｔｓ）（ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎ：４４１）を実行する。仲介者は、セキュリティ装置から取得したＲｅｓｕｌｔｓの真正性を検証するため、電子証明書４４７をチェックする。電子証明書がＲｅｓｕｌｔｓに一致する場合、仲介者は、ボブのセキュリティ装置が何れかの者の干渉なしにボブのＥＰｒｏｇｒａｍ＿ｇｅｎｅｒａｔｉｏｎ（Ｉｎｐｕｔｓ）を実行し、何れの者にもそれの入力又は出力が改ざんされていないことを知ることとなる。特に、何れの者も入力ＥＰｒｏｏｆを変更していなかった。すなわち、ボブのセキュリティ装置は、ＥＰｒｏｏｆを用いてＥＰｒｏｏｆ＿ｖｅｒｉｆｉｃａｔｉｏｎ（Ｉｎｐｕｔｓ）を実行した。Ｒｅｓｕｌｔ４４５は、Ｏｕｔｐｕｔにおいて完全に若しくは部分的に供給可能であり、又は全く供給することが可能でない。それはまた、Ｒｅｓｕｌｔから求められる情報と置換することができる。これは、アプリケーションと仲介者に依存するかもしれない。この決定は、その後プログラムにより実現される。例えば、プライバシーの理由のため、ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎは、結果のサマリのみを仲介者に送信することも可能である。
【００４９】
ステップ３では、仲介者は、ＣｈｅｃｋＢｉｔ４４６が真であるか、すなわち、ＥＭＲｅｓｕｌｔのＭＡＣが一致するか検証する。そうである場合、仲介者は、ボブのセキュリティ装置上のＡＰｒｏｇｒａｍ（Ｉｎｐｕｔ）がＥＰｒｏｏｆ及びＲｅｓｕｌｔを計算したと判断する。そうでない場合、仲介者は、ボブのセキュリティ装置がＥＰｒｏｏｆを計算していないと判断する。ＥＰｒｏｇｒａｍ＿ｖｅｒｉｆｉｃａｔｉｏｎは、ＭＡＣが一致しないことを出力するか（Ｄ＆Ｍ（．）及びＣｈｅｃｈＢｉｔの定義を参照されたい）、又はＭＡＣが解読された結果と一致することを出力する。（偽の）結果であるＦＲｅｓｕｌｔに対して偽の電子プルーフであるＦＥＰｒｏｏｆ＝（ＦＰＣ，ＦＥＭＲｅｓｕｌｔ）を生成することは、いわゆる困難な問題である。
【００５０】
第３の実施例では、２００４年５月６日に出願された特許出願ＵＳ２００４／０１４４０４（代理人整理番号ＰＨＮＬ０３０６０５）に記載されるように、セキュアメモリとセキュアプリグラムの実行状態の利用が、同一のセキュリティ装置上で交互に実行されるセキュリティ装置間のセキュアな通信を行うため、共有された秘密の生成と組み合わせることができる。
【００５１】
図５は、本実施例のアーキテクチャを示す。プログラム実行状態５０２とメモリコンテンツ５０２とは、セキュリティプログラム５０５の部分的実行の間に格納される。セキュリティ装置５００上で実行されるセキュリティプログラム５０１は、割り込みの場合、又は異なるセキュリティプログラムが実行される必要がある場合、それのプログラム状態５０５をセキュアに格納することが可能である。割り込みが行われると、プログラム状態が暗号化される（ステップ５０３）。セキュリティ装置は、外部にそれの状態を開示することなく以降においてそれの実行を継続するかもしれない。継続されると、プログラム状態が検証及び解読され（ステップ５０４）、復元される。メモリコンテンツの一部は共有秘密キーを用いて暗号化され、メモリの他の部分はプライベート共有秘密キーを用いて暗号化されてもよく、これにより、セキュアなプログラム間の通信とセキュリティプログラムの間のセキュアな分離の両方を実現することができる。
【００５２】
本発明の第４実施例は、認証された実行のレイヤを追加する。認証された実行のコンセプトは、従来技術文献において記載されている。セキュリティ装置のユーザにセキュリティプログラムがセキュリティ装置上で実際に及びセキュアに実行されることを保証するため、共有秘密を生成するセキュリティプログラムは、認証された実行を実現する他のセキュリティプログラムの制御の下で実行される。この技術は、具体的実現形態により示される。認証された実行は、いわゆる電子証明書を用いて提供される。セキュリティ装置上の入力ＩｎｐｕｔによるプログラムＸＰｒｏｇｒａｍの電子証明書は、ＸＰｒｏｇｒａｍの出力される結果がセキュリティ装置上でＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）により生成されたか、セキュリティ装置のユーザがかなりの確率により効率的にチェックすることができるように、セキュリティ装置上でＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）により効率的に生成される文字列として規定される。セキュリティ装置上でのＸＰｒｏｇｒａｍの実行をリクエストするユーザは、セキュリティ装置の所有者に頼る代わりに、自らがセキュリティ装置を生成したということを保証することができるセキュリティ装置のメーカーの信頼性に頼ることができる。
【００５３】
図６は、計算がセキュリティ装置上で直接実行される認証された実行を示す。ユーザであるアリスは、ボブのコンピュータ６０１上で計算量の大きなプログラムＰｒｏｇｒａｍ（Ｉｎｐｕｔ）を実行することを所望している。ボブのコンピュータは、ＰＵＦ６０３を有するセキュリティ装置６０２を有する。アリスは、セキュリティ装置によるＣＲＰ６１１のリストをすでに確立していると仮定する。（Ｃｈａｌｌｅｎｇｅ，Ｒｅｓｐｏｎｓｅ）をボブのＰＵＦに対するアリスのＣＲＰの１つであるとする。第１の実現形態の変形では、アリスは、（Ｃｈａｌｌｅｎｇｅ，Ｅ＆Ｍ（（ＸＰｒｏｇｒａｍ，Ｉｎｐｕｔ），ｈ（ｈ（ＣＰｒｏｇｒａｍ），Ｒｅｓｐｏｎｓｅ）））に等しい入力Ｉｎｐｕｔｓ６３２による以下のプログラムＣＰｒｏｇｒａｍ１（６３１）をセキュリティ装置６０２に送信する（通信６２１により）。
【００５４】
【表３】
Ｒｅｓｕｌｔ＝ＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）によって、ＲｅｓｕｌｔはＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）の出力の一部であると理解される。電子プルーフが必要とされないさらなる出力があるかもしれない。Ｏｕｔｐｕｔ（．．．）は、通信６２２に示されるように、ＣＰＵＦからの結果６３３を送信するのに利用される。セキュリティ装置から送信されるものは、潜在的には全世界に明白にされる（メーカーがセキュリティ装置を物理的に所持するブートストラッピング中を除いて）。プログラムのセキュアな設計は、Ｒｅｓｕｌｔに暗号化形式により配置される結果を生成する。暗号化は、従来の暗号化又はＳｅｃｒｅｔを用いることによって実行可能である。後者のケースでは、ＳｅｃｒｅｔはＩｎｐｕｔに含まれる。
【００５５】
アリスのＣＲＰはプライベートであるため、他の何れの者もＳｅｃｒｅｔと、ＳｅｃｒｅｔによるＭＡＣを生成することはできない。ＭＡＣは、プログラムの２つのスポットにおいて利用される。第１ＭＡＣは、プログラムによりチェックされ、Ｉｎｐｕｔｓの真正性を保証する。第２ＭＡＣは、アリスによりチェックされ、セキュリティ装置から取得したメッセージの真正性を保証する。アリスを除いて、セキュリティ装置のみが、プログラムＣＰｒｏｇｒａｍを実行することによりＳｅｃｒｅｔが与えられたチャレンジを生成することができる。このことは、ＲｅｓｕｌｔとＣｅｒｔｉｆｉｃａｔｅがセキュリティ装置上でＣＰｒｏｇｒａｍにより生成されたことを意味する。すなわち、ＣＰｒｏｇｒａｍは入力としてＩｎｐｕｔｓにより認証された実行を実行したこととなる。これは、Ｃｅｒｔｉｆｉｃａｔｅが電子証明書であることを証明する。
【００５６】
従って、電子証明書は共有される秘密を生成するセキュリティプログラムのセキュアなリモート計算に利用可能である。Ｃｅｒｔｉｆｉｃａｔｅが一致する場合、このことは、ＸＰｒｏｇｒａｍ（Ｉｎｐｕｔ）がセキュリティ装置上で（ＣＰｒｏｇｒａｍ（Ｉｎｐｕｔｓ）により）実行されたことをアリスに証明するものである。
【００５７】
セキュリティ装置の所有者（ボブ）とセキュリティ装置のユーザ（アリス）とは、１つの同一のものであってもよいということに留意されたい。例えば、ボブは、自分がＰｒｏｇｒａｍ（Ｉｎｐｕｔ）によりＲｅｓｕｌｔを計算したことを自らの電子プルーフにより他人に証明する。最終的に、本発明の効果は、アリスも仲介者もＰＵＦを備えたセキュリティ装置を必要としないということである。
【００５８】
本発明は、それがデジタルだけでなく、フィジカル又はオプティカルであるすべてのＰＵＦに適用可能であるという意味において一般的に適用可能である。構成の詳細は、フィジカルＰＵＦについて与えられているが、デジタル又はオプティカルＰＵＦに振り替えることができる。
【００５９】
他のものも可能である。上記記載において、「有する」という用語は他の要素又はステップを排除するものでなく、「ある」という用語は複数を排除するものでなく、単一のプロセッサ又は他のユニットもまた、請求項に記載されるいくつかの手段の機能を実現するかもしれない。
【図面の簡単な説明】
【００６０】
【図１】図１は、ＰＵＦを利用したアプリケーションに対する基本的モデルを示す。
【図２】図２は、共有される秘密の生成を示す。
【図３】図３は、共有される秘密を生成するための一例となる利用シナリオを示す。
【図４】図４は、認証された実行の下で共有秘密を生成するための各プログラムレイヤの概略を示す。
【図５】図５は、割り込みされた処理を示す。
【図６】図６は、認証された実行を示す。
【特許請求の範囲】
【請求項１】
第１セキュリティプログラムと少なくとも第２セキュリティプログラムとの間で共有される秘密を生成する方法であって、
被制御インタフェースを介しセキュリティプログラムのみからアクセス可能なランダムファンクションを有するセキュリティ装置上で、前記第１セキュリティプログラムの制御の下でプログラム命令を実行するステップを有し、
前記被制御インタフェースは、プリミティブファンクションを呼び出す前記第１セキュリティプログラムの表現の少なくとも一部と、前記セキュリティ装置上で前記第２セキュリティプログラムを実行すると、前記プリミティブファンクションを呼び出す前記第２セキュリティプログラムの表現の少なくとも一部とに依存する出力を返す前記ランダムファンクションにアクセスする少なくとも１つのプリミティブファンクションを有し、
前記ステップは、前記共有される秘密を生成するため前記少なくとも１つのプリミティブファンクションを呼び出すサブステップを有する方法。
【請求項２】
前記第１セキュリティプログラムの表現と前記第２セキュリティプログラムの表現とは、前記プリミティブファンクションの入力として使用されると、辞書式に順序付けされる、請求項１記載の方法。
【請求項３】
前記ランダムファンクションは、プリミティブファンクションを介しアクセス可能であり、ＧｅｔＲｅｓｐｏｎｓｅ（．．）＝ｆ（ｈ（ｏ（ｈ（Ｐｒｏｇｒａｍ），ｈｐｒｏｇ１，．．．，ｈｐｒｏｇＮ），ＰＣ）に実質的に等しい（ただし、Ｐｒｏｇｒａｍは前記プリミティブファンクションを呼び出すセキュリティプログラムであり、ｈｐｒｏｇ１〜ｈｐｒｏｇＮはｈ（Ｐｒｏｇｒａｍ１）〜ｈ（ＰｒｏｇｒａｍＮ）に等しく、Ｐｒｏｇｒａｍ１〜ＰｒｏｇｒａｍＮは前記キーが共有されるべきセキュリティプログラムであり、ｆ（．）は前記ランダムファンクションであり、ｈ（．）は実質的に公開利用可能なランダムハッシュファンクションであり、ｏ（．．）は当該引数の辞書式順序付けを実行する）、請求項２記載の方法。
【請求項４】
前記ランダムファンクションは、プリミティブファンクションＧｅｔＲｅｓｐｏｎｓｅ（．．）＝ｆ（ｈ（ｏ（ｈ（Ｐｒｏｇｒａｍ），ｈｐｒｏｇ１，．．．，ｈｐｒｏｇＮ，Ｒ），ＰＣ）を介しアクセス可能である（ただし、Ｐｒｏｇｒａｍは前記プリミティブファンクションを呼び出すセキュリティプログラムであり、ｈｐｒｏｇ１〜ｈｐｒｏｇＮはｈ（Ｐｒｏｇｒａｍ１）〜ｈ（ＰｒｏｇｒａｍＮ）に等しく、Ｐｒｏｇｒａｍ１〜ＰｒｏｇｒａｍＮは前記キーが共有されるべきセキュリティプログラムであり、ｆ（．）は前記ランダムファンクションであり、ｈ（．）は実質的に公開利用可能なランダムハッシュファンクションであり、ｏ（．．）は引数をｈｐｒｏｇ１，．．．，ｈｐｒｏｇＲ，ｈ（Ｐｒｏｇｒａｍ），ｈｐｒｏｇＲ＋１，．．．，ｈｐｒｏｇＮの順序で出力する当該引数の再順序付けを実行する）、請求項１記載の方法。
【請求項５】
前記共有される秘密は、実行のプルーフを生成するため第１セキュリティプログラムにおいて利用され、
前記共有される秘密は、前記実行のプルーフを検証するため第２セキュリティプログラムにおいて利用される、請求項１記載の方法。
【請求項６】
前記共有される秘密は、同一のセキュリティ装置上で実行される各セキュリティプログラムの間で通信するため利用される、請求項１記載の方法。
【請求項７】
前記セキュリティプログラムは、該セキュリティプログラムが前記セキュリティ装置によって実行されることを前記セキュリティ装置のユーザに証明する認証された実行を提供する第２セキュリティプログラムの一部として実行される、請求項１記載の方法。
【請求項８】
前記ランダムファンクションは複雑物理系を有する、請求項１記載の方法。
【請求項９】
前記共有される秘密の計算は、前記ランダムファンクションへの入力として前記セキュリティプログラムの一部を利用する、請求項１記載の方法。
【請求項１０】
コンピュータ可読命令を実行するためのプロセッサとメモリとを有する処理装置とランダムファンクションとを有するシステムであって、
前記命令は、請求項１記載の方法を当該システムに実行させるよう構成されるシステム。
【請求項１１】
コンピュータに請求項１記載の方法を実現させるためのコンピュータにより実行可能な命令を有するコンピュータプログラム。
【請求項１２】
請求項１記載の方法によって生成される共有される秘密を搬送する信号。
【請求項１】
第１セキュリティプログラムと少なくとも第２セキュリティプログラムとの間で共有される秘密を生成する方法であって、
被制御インタフェースを介しセキュリティプログラムのみからアクセス可能なランダムファンクションを有するセキュリティ装置上で、前記第１セキュリティプログラムの制御の下でプログラム命令を実行するステップを有し、
前記被制御インタフェースは、プリミティブファンクションを呼び出す前記第１セキュリティプログラムの表現の少なくとも一部と、前記セキュリティ装置上で前記第２セキュリティプログラムを実行すると、前記プリミティブファンクションを呼び出す前記第２セキュリティプログラムの表現の少なくとも一部とに依存する出力を返す前記ランダムファンクションにアクセスする少なくとも１つのプリミティブファンクションを有し、
前記ステップは、前記共有される秘密を生成するため前記少なくとも１つのプリミティブファンクションを呼び出すサブステップを有する方法。
【請求項２】
前記第１セキュリティプログラムの表現と前記第２セキュリティプログラムの表現とは、前記プリミティブファンクションの入力として使用されると、辞書式に順序付けされる、請求項１記載の方法。
【請求項３】
前記ランダムファンクションは、プリミティブファンクションを介しアクセス可能であり、ＧｅｔＲｅｓｐｏｎｓｅ（．．）＝ｆ（ｈ（ｏ（ｈ（Ｐｒｏｇｒａｍ），ｈｐｒｏｇ１，．．．，ｈｐｒｏｇＮ），ＰＣ）に実質的に等しい（ただし、Ｐｒｏｇｒａｍは前記プリミティブファンクションを呼び出すセキュリティプログラムであり、ｈｐｒｏｇ１〜ｈｐｒｏｇＮはｈ（Ｐｒｏｇｒａｍ１）〜ｈ（ＰｒｏｇｒａｍＮ）に等しく、Ｐｒｏｇｒａｍ１〜ＰｒｏｇｒａｍＮは前記キーが共有されるべきセキュリティプログラムであり、ｆ（．）は前記ランダムファンクションであり、ｈ（．）は実質的に公開利用可能なランダムハッシュファンクションであり、ｏ（．．）は当該引数の辞書式順序付けを実行する）、請求項２記載の方法。
【請求項４】
前記ランダムファンクションは、プリミティブファンクションＧｅｔＲｅｓｐｏｎｓｅ（．．）＝ｆ（ｈ（ｏ（ｈ（Ｐｒｏｇｒａｍ），ｈｐｒｏｇ１，．．．，ｈｐｒｏｇＮ，Ｒ），ＰＣ）を介しアクセス可能である（ただし、Ｐｒｏｇｒａｍは前記プリミティブファンクションを呼び出すセキュリティプログラムであり、ｈｐｒｏｇ１〜ｈｐｒｏｇＮはｈ（Ｐｒｏｇｒａｍ１）〜ｈ（ＰｒｏｇｒａｍＮ）に等しく、Ｐｒｏｇｒａｍ１〜ＰｒｏｇｒａｍＮは前記キーが共有されるべきセキュリティプログラムであり、ｆ（．）は前記ランダムファンクションであり、ｈ（．）は実質的に公開利用可能なランダムハッシュファンクションであり、ｏ（．．）は引数をｈｐｒｏｇ１，．．．，ｈｐｒｏｇＲ，ｈ（Ｐｒｏｇｒａｍ），ｈｐｒｏｇＲ＋１，．．．，ｈｐｒｏｇＮの順序で出力する当該引数の再順序付けを実行する）、請求項１記載の方法。
【請求項５】
前記共有される秘密は、実行のプルーフを生成するため第１セキュリティプログラムにおいて利用され、
前記共有される秘密は、前記実行のプルーフを検証するため第２セキュリティプログラムにおいて利用される、請求項１記載の方法。
【請求項６】
前記共有される秘密は、同一のセキュリティ装置上で実行される各セキュリティプログラムの間で通信するため利用される、請求項１記載の方法。
【請求項７】
前記セキュリティプログラムは、該セキュリティプログラムが前記セキュリティ装置によって実行されることを前記セキュリティ装置のユーザに証明する認証された実行を提供する第２セキュリティプログラムの一部として実行される、請求項１記載の方法。
【請求項８】
前記ランダムファンクションは複雑物理系を有する、請求項１記載の方法。
【請求項９】
前記共有される秘密の計算は、前記ランダムファンクションへの入力として前記セキュリティプログラムの一部を利用する、請求項１記載の方法。
【請求項１０】
コンピュータ可読命令を実行するためのプロセッサとメモリとを有する処理装置とランダムファンクションとを有するシステムであって、
前記命令は、請求項１記載の方法を当該システムに実行させるよう構成されるシステム。
【請求項１１】
コンピュータに請求項１記載の方法を実現させるためのコンピュータにより実行可能な命令を有するコンピュータプログラム。
【請求項１２】
請求項１記載の方法によって生成される共有される秘密を搬送する信号。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００８−５１４０９７（Ｐ２００８−５１４０９７Ａ）
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願番号】特願２００７−５３１９３９（Ｐ２００７−５３１９３９）
【出願日】平成１７年９月１６日（２００５．９．１６）
【国際出願番号】ＰＣＴ／ＩＢ２００５／０５３０４７
【国際公開番号】ＷＯ２００６／０３３０６５
【国際公開日】平成１８年３月３０日（２００６．３．３０）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
【公表日】平成２０年５月１日（２００８．５．１）
【国際特許分類】
【出願日】平成１７年９月１６日（２００５．９．１６）
【国際出願番号】ＰＣＴ／ＩＢ２００５／０５３０４７
【国際公開番号】ＷＯ２００６／０３３０６５
【国際公開日】平成１８年３月３０日（２００６．３．３０）
【出願人】（５９００００２４８）コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ (12,071)
【Ｆターム（参考）】
[ Back to top ]