JP2004513585A5 - - Google Patents
Download PDFInfo
- Publication number
- JP2004513585A5 JP2004513585A5 JP2002541482A JP2002541482A JP2004513585A5 JP 2004513585 A5 JP2004513585 A5 JP 2004513585A5 JP 2002541482 A JP2002541482 A JP 2002541482A JP 2002541482 A JP2002541482 A JP 2002541482A JP 2004513585 A5 JP2004513585 A5 JP 2004513585A5
- Authority
- JP
- Japan
- Prior art keywords
- data
- server
- sac
- trusted
- key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 description 24
- 238000004891 communication Methods 0.000 description 23
- 230000000875 corresponding Effects 0.000 description 10
- 238000004364 calculation method Methods 0.000 description 8
- 238000010586 diagram Methods 0.000 description 8
- 230000001010 compromised Effects 0.000 description 5
- 238000009826 distribution Methods 0.000 description 5
- 238000009434 installation Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 230000001276 controlling effect Effects 0.000 description 4
- 235000009508 confectionery Nutrition 0.000 description 3
- 230000002708 enhancing Effects 0.000 description 3
- 230000006399 behavior Effects 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000006011 modification reaction Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000003860 storage Methods 0.000 description 2
- 230000001629 suppression Effects 0.000 description 2
- 238000010367 cloning Methods 0.000 description 1
- 230000000295 complement Effects 0.000 description 1
- 230000001808 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 238000007620 mathematical function Methods 0.000 description 1
- 230000000116 mitigating Effects 0.000 description 1
- 230000003068 static Effects 0.000 description 1
Images
Description
【書類名】明細書
【発明の名称】クライアントとサーバー間の信頼を管理するシステムおよび方法
【特許請求の範囲】
【請求項１】（１）クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、（２）少なくとも１つのリモートサーバーとの間のセキュア（安全な）関係を基本とするトランザクションに対して信頼を高める方法であって、
（ａ）少なくとも１つの公開鍵データを受け入れるように構成された信頼されるサーバー（ｔｒｕｓｔｅｄ ｓｅｒｖｅｒ）を使用するステップであって、前記公開鍵データがそれぞれ、前記プラットフォーム用の公開鍵／秘密鍵の対の一部として、前記クライアント・プラットフォームと特に関連づけられ、また、前記公開鍵／秘密鍵の対がそれぞれ、（ｉ）クライアント・プラットフォームか、（ｉｉ）前記信頼されるサーバーのうちの少なくとも１つを用いて、生成される場合があるステップと、
（ｂ）追加的な承認データを前記公開鍵データと関連づけて、前記公開鍵データを、前記公開鍵データを受け入れた前記信頼されるサーバーにより承認されたものとして特定するステップと、
（ｃ）前記公開鍵データを信頼できるものとして承認するために、前記信頼されるサーバーからの信頼できる追加的な承認データを見分けるように構成されている前記リモートサーバーが、前記公開鍵データと前記関連づけられる追加的な承認データを利用できるようにするステップと、
（ｄ）リモートサーバー固有のデータを、前記承認された公開鍵データと関連づけるステップであって、前記関連づけられるリモートサーバー固有のデータが、前記公開鍵データと関連づけられたクライアント・プラットフォーム秘密鍵といっしょに使用され、また、前記信頼されるサーバーとのクライアント・プラットフォームのやり取りを通じて、前記信頼されるサーバーが、前記リモートサーバーからのサーバー固有のデータとともに、前記クライアント・プラットフォーム秘密鍵を、少なくとも１回、利用することに気づいて、前記公開鍵データを前記リモートサーバーと関連づけることを受け入れるか、または拒絶し、かつ、保証を与えるか、または拒否する機会を、前記信頼されるサーバーに与えるステップ、
を含むことを特徴とする方法。
【請求項２】（１）クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、（２）リモートサーバーとの間のトランザクションに対して信頼を高める、少なくとも１つの信頼されるサーバーを使用する方法であって、
（ａ）少なくとも１つの秘密データを含むデータを、前記リモートサーバーから、信頼されるサーバーに転送するステップであって、前記転送が、データ転送セキュリティ対策とともに行われるステップと、
（ｂ）前記転送されるデータの一部の関数を、前記信頼されるサーバーから前記クライアント・プラットフォームに提供するステップであって、前記データの一部には、前記少なくとも１つの秘密データの少なくとも一部が含まれ、また、前記転送する信頼されるサーバーが、信頼できると見なされるクライアント・プラットフォームと関連づけられるものとして、前記信頼されるサーバーにより識別できる少なくとも１つの鍵で暗号化された前記関数の１つの値を、前記クライアント・プラットフォームに提供し、前記クライアント・プラットフォームが、前記暗号化された関数値を復号化する機能を果たすステップ、および
（ｃ）前記関数の前記値を、前記リモートサーバーと前記クライアント・プラットフォームとの間で安全に共有できるようにするステップ、
を含むことを特徴とする方法。
【請求項３】前記信頼されるサーバーから前記クライアント・プラットフォームに提供される前記関数の前記値は、前記信頼されるサーバーに知られている前記クライアント・プラットフォームの属性によって決まることを特徴とする請求項２記載の方法。
【請求項４】コンピュータ・オブジェクト・データをクライアント・コンピュータ・マイクロプロセッサ・プラットフォームに、信頼されるように受け渡す方法であって（その場合、前記受け渡されるオブジェクト・データが一関数であるソースデータはリモートサーバーが提供する）、
（ａ）前記リモートサーバーに知られている、前記オブジェクト・データと区別できる秘密データを特定するステップであって、前記秘密データを、信頼されるサーバーに提供して、一意のタグを用いて特定するステップと、
（ｂ）前記一意のタグと関連させて、ソースデータを前記信頼されるサーバーに提出させるステップと、
（ｃ）前記提出されたソースデータから得られた前記コンピュータ・オブジェクト・データを、クライアント・プラットフォームでの利用のために提供するステップであって、前記オブジェクト・データを、前記信頼されるサーバーにより計算された署名と関連づけ、また前記署名が、前記オブジェクト・データの関数ｆ１であるようなステップ、
を含むことを特徴とする方法。
【請求項５】（ｉｉ）前記署名が、前記オブジェクト・データの関数ｆ２をさらに含むことと、前記オブジェクト・データの知識が与えられた前記オブジェクト・データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項４記載の方法。
【請求項６】（ｉｉ）前記署名が、データの関数ｆ２をさらに含むことと、前記信頼されるサーバーが関数値を利用できることと、データの関数ｆ３を前記リモートサーバーに提供することと、データの関数ｆ３の知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項４記載の方法。
【請求項７】前記データは、前記信頼されるサーバーにより、少なくとも一部ランダムに生成されることを特徴とする請求項６記載の方法。
【請求項８】前記データの知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項６記載の方法。
【請求項９】前記データの知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ３の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項６記載の方法。
【請求項１０】リモートサーバーと関連づけられたソースデータから得、かつクライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントで利用できるコンピュータ・オブジェクト・データを制御する方法であって、
（ａ）一意のタグと関連づけられた第１のデータを特定するステップ（前記第１のデータと、その関連タグは、前記リモートサーバーに知られている）と、
（ｂ）前記第１のデータおよびタグと、前記第２のデータを反映させる情報を格納するように構成される信頼されるサーバーから提供されている前記第２のデータを、前記第１のデータおよびタグと関連づけるステップと、
（ｃ）コンピュータ・オブジェクト・データを、得られたデータの一関数として計算された値に結び付けるステップであって、前記得られたデータが、（Ａ）前記第１のデータを表わすデータと、（Ｂ）前記第２のデータを表わすデータのうち、少なくとも１つを含み、また、前記結び付けが、前記信頼されるサーバーにより実施されるステップと、
（ｄ）前記リモートサーバーでは、（ｉ）前記リモードサーバーの追加的データを、（ｉｉ）（Ｃ）前記第１のデータを表わすデータと（Ｄ）前記第２のデータを表わすデータのうち少なくとも１つと、また、（ｉｉｉ）前記関連タグと関連づけて、追加的なデータ・バンドルを形成するステップと、
（ｅ）前記追加的なデータ・バンドルを、前記信頼されるサーバーに提出し、また、前記データ・バンドルが、前記信頼されるサーバーで格納される前記第１のデータおよびタグと前記第２のデータに関して、前記格納された情報と合致するものとして検証される場合には、前記得られたデータを、前記データ・バンドルの関数と関連づけて、クライアント・プラットフォームに受け渡すステップ、
を含むことを特徴とする方法。
【請求項１１】前記第１のデータは秘密データを含むことを特徴とする請求項１０記載の方法。
【請求項１２】前記得られたデータは暗号鍵を含むことを特徴とする請求項１０記載の方法。
【請求項１３】前記第１のデータは秘密データを含み、かつ、前記得られたデータは暗号鍵を含むことを特徴とする請求項１０記載の方法。
【請求項１４】リモートサーバーと関連づけられたソースデータから得、かつクライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントで利用できるコンピュータ・オブジェクト・データを制御する方法であって、
（ａ）一意のタグと関連づけられた第１のデータを特定するステップ（前記第１のデータと、その関連タグは、前記リモートサーバーに知られている）と、
（ｂ）コンピュータ・オブジェクト・データを、得られたデータの一関数として計算された値に結び付けるステップであって、前記得られたデータが、前記第１のデータを表わすデータを含み、前記結び付けが、前記信頼されるサーバーにより実施され、また、前記信頼されるサーバーが、前記第１のデータおよびタグを反映させる情報を格納するように構成されているステップと、
（ｃ）前記リモートサーバーでは、（ｉ）前記第１のデータを表わすデータを含む前記リモードサーバーの追加的データを、（ｉｉ）前記関連タグと関連づけて、追加的なデータ・バンドルを形成するステップと、
（ｄ）前記追加的なデータ・バンドルを、前記信頼されるサーバーに提出し、また、前記データ・バンドルが、前記信頼されるサーバーで格納される前記第１のデータおよびタグに関して、前記格納された情報と合致するものとして検証される場合には、前記得られたデータを、前記データ・バンドルの関数と関連づけて、クライアント・プラットフォームに受け渡すステップ、
を含むことを特徴とする方法。
【請求項１５】前記第１のデータは秘密データを含むことを特徴とする請求項１４記載の方法。
【請求項１６】前記得られたデータは暗号鍵を含むことを特徴とする請求項１４記載の方法。
【請求項１７】前記第１のデータは秘密データを含み、かつ、前記得られたデータは暗号鍵を含むことを特徴とする請求項１４記載の方法。
【請求項１８】安全な関係を基本とするトランザクションに対して信頼を高めるシステムであって、
ａ）少なくとも１つのリモートサーバーと、
ｂ）前記少なくとも１つのリモードサーバーと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合された少なくとも１つの公開鍵データを受け入れるように構成されたトラスト・サーバーと、
ｄ）前記トラスト・サーバーと動作可能に結合されたクライアント・コンピュータ・マイクロプロセッサ・プラットフォームであって、
ｉ）それぞれ（ｉ）前記クライアント・プラットフォームまたは（ｉｉ）前記信頼されるサーバーの少なくとも１つを用いて生成される場合のある、前記プラットフォーム用の公開鍵／秘密鍵の対の一部として、それぞれが、前記クライアント・プラットフォームと、とりわけ関連づけられた少なくとも１つの公開鍵データを受け入れるように構成された前記信頼されるサーバーを使用する、
ｉｉ）追加的な承認データを前記公開鍵データと関連づけて、前記公開鍵データを受け入れる前記信頼されるサーバーによって承認されたものとして、前記公開鍵データを特定する、
ｉｉｉ）前記公開鍵データを信頼できるものとして承認するために、前記信頼されるサーバーからの信頼できる追加的な承認データを見分けるように構成されているリモートサーバーに、前記公開鍵データと前記関連づけられた追加的な承認データを提供する、
ｉｖ）前記公開鍵データと関連づけられた前記クライアント・プラットフォーム秘密鍵とともに用いられるリモートサーバー固有のデータを、前記承認された公開鍵データと関連づけ、そこでは、前記信頼されるサーバーとのクライアント・プラットフォームのやり取りを通じて、前記信頼されるサーバーが、前記リモートサーバーからのサーバー固有のデータとともに、前記クライアント・プラットフォーム秘密鍵を、少なくとも１回、利用することに気づいて、前記公開鍵データを、前記リモートサーバーと関連づけることを受け入れるか、または拒絶し、かつ、保証を与えるか、または拒否する機会を、前記信頼されるサーバーに与える、
ように動作できるプログラムが供給されるクライアント・コンピュータ・マイクロプロセッサ・プラットフォーム、
を備えることを特徴とするシステム。
【請求項１９】安全な関係を基本とするトランザクションに対して信頼を高めるシステムであって、
ａ）少なくとも１つのリモートサーバーと、
ｂ）前記少なくとも１つのリモードサーバーと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合されたクライアント・コンピュータ・マイクロプロセッサ・プラットフォームと、
ｄ）前記データ通信リンクと動作可能に結合された信頼されるサーバーであって、
ｉ）少なくとも１つの秘密データを含むデータを、前記リモートサーバーから前記信頼されるサーバーに転送し、かつ、このような転送を、データ転送セキュリティ対策とともに行う、
ｉｉ）前記転送されるデータの一部の関数を、前記信頼されるサーバーから前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに提供し、前記データの一部には、前記少なくとも１つの秘密データの少なくとも一部が含まれ、また、前記転送する信頼されるサーバーが、信頼できると見なされる前記クライアント・プラットフォームと関連づけられるものとして、前記信頼されるサーバーにより識別できる少なくとも１つの鍵で暗号化された前記関数の１つの値を、前記クライアント・プラットフォームに提供し、前記クライアント・プラットフォームが、前記暗号化された関数値を復号化する機能を果たす、
ｉｉｉ）前記関数の前記値を、前記リモートサーバーと前記クライアント・プラットフォームとの間で安全に共有できるようにする、
ように動作できるプログラムが供給される信頼されるサーバー、
を備えることを特徴とするシステム。
【請求項２０】前記信頼されるサーバーから前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに提供される前記関数の前記値は、前記信頼されるサーバーに知られている前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームの属性によって決まることを特徴とする請求項１９記載のシステム。
【請求項２１】コンピュータ・オブジェクト・データを、信頼されるように受け渡すシステムであって、
ａ）少なくとも１つのリモートサーバーと、
ｂ）前記少なくとも１つのリモードサーバーと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合されたクライアント・コンピュータ・マイクロプロセッサ・プラットフォームと、
ｄ）前記データ通信リンクと動作可能に結合された信頼されるサーバーであって、
ｉ）前記リモートサーバーに知られている、前記オブジェクト・データと区別できる秘密データを特定し、前記秘密データを、信頼されるサーバーに提供して、一意のタグを用いて特定する、
ｉｉ）前記一意のタグと関連させて、ソースデータを前記信頼されるサーバーに提出させる、
ｉｉｉ）前記提出されたソースデータから得られた前記コンピュータ・オブジェクト・データを、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームでの利用のために提供し、前記オブジェクト・データを、前記信頼されるサーバーにより計算された署名（前記オブジェクト・データの関数ｆ１である）と関連づける、
ように、同時に動作できるプログラムが前記信頼されるサーバーと前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに供給されるような信頼されるサーバー、
を備えることを特徴とするシステム。
【請求項２２】前記署名が、前記オブジェクト・データの関数ｆ２をさらに含むことと、前記オブジェクト・データの知識が与えられた前記オブジェクト・データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項２１記載のシステム。
【請求項２３】前記署名が、データの関数ｆ２をさらに含むことと、前記信頼されるサーバーが関数値を利用できることと、データの関数ｆ３を前記リモートサーバーに提供することと、前記データの関数ｆ３の知識と前記オブジェクト・データの知識が与えられたデータの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項２１記載のシステム。
【請求項２４】前記データは、前記信頼されるサーバーにより、少なくとも一部ランダムに生成されることを特徴とする請求項２３記載のシステム。
【請求項２５】前記データの知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項２３記載のシステム。
【請求項２６】前記データの知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ３の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項２３記載のシステム。
【請求項２７】リモートサーバーと関連づけられたソースデータから得るコンピュータ・オブジェクト・データを制御するシステムであって、
ａ）複数のクライアント・コンピュータ・マイクロプロセッサ・プラットフォームと、
ｂ）前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合された信頼されるサーバーであって、
ｉ）一意のタグと関連づけられた第１のデータを特定する（前記第１のデータと、その関連タグは、前記リモートサーバーに知られている）、
ｉｉ）前記第１のデータおよびタグと、前記第２のデータを反映させる情報を格納するように構成される前記信頼されるサーバーから提供されている前記第２のデータを、前記第１のデータおよびタグと関連づける、
ｉｉｉ）コンピュータ・オブジェクト・データを、得られたデータの一関数として計算された値に結び付け、そこでは、前記得られたデータが、（Ａ）前記第１のデータを表わすデータと、（Ｂ）前記第２のデータを表わすデータのうち、少なくとも１つを含み、また、前記結び付けを、前記信頼されるサーバーで実施する、
ｉｖ）前記リモートサーバーでは、（ｉ）前記リモードサーバーの追加的データを、（ｉｉ）（Ｃ）前記第１のデータを表わすデータと（Ｄ）前記第２のデータを表わすデータのうち少なくとも１つと、また、（ｉｉｉ）前記関連タグと関連づけて、追加的なデータ・バンドルを形成する、
ｉ）前記追加的なデータ・バンドルを、前記信頼されるサーバーに提出し、また、前記データ・バンドルが、前記信頼されるサーバーで格納される前記第１のデータおよびタグと前記第２のデータに関して、前記格納された情報と合致するものとして検証される場合には、前記得られたデータを、前記データ・バンドルの関数と関連づけて、前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに受け渡す、
ように動作できるプログラムが前記信頼されるサーバーと前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに供給されるような信頼されるサーバー、
を備えることを特徴とするシステム。
【請求項２８】前記第１のデータは秘密データを含むことを特徴とする請求項２７記載のシステム。
【請求項２９】前記得られたデータは暗号鍵を含むことを特徴とする請求項２７記載のシステム。
【請求項３０】前記第１のデータは秘密データを含み、かつ、前記得られたデータは暗号鍵を含むことを特徴とする請求項２７記載の方法。
【請求項３１】リモートサーバーと関連づけられたソースデータから得るコンピュータ・オブジェクト・データを制御するシステムであって、
ａ）複数のクライアント・コンピュータ・マイクロプロセッサ・プラットフォームと、
ｂ）前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合された信頼されるサーバーであって、
ｉ）一意のタグと関連づけられた第１のデータを特定する（前記第１のデータと、その関連タグは、前記リモートサーバーに知られている）、
ｉｉ）コンピュータ・オブジェクト・データを、得られたデータの一関数として計算された値に結び付け、そこでは、前記得られたデータが、前記第１のデータを表わすデータを含み、また、前記第１のデータおよびタグを反映させる情報を格納するように構成されている前記信頼されるサーバーで、前記結び付けを実施する、
ｉｉｉ）前記リモートサーバーでは、（ｉ）前記第１のデータを表わすデータを含む前記リモードサーバーの追加的データを、（ｉｉ）前記第関連タグと関連づけて、追加的なデータ・バンドルを形成する、
ｉｖ）前記追加的なデータ・バンドルを、前記信頼されるサーバーに提出し、また、前記データ・バンドルが、前記信頼されるサーバーで格納される前記第１のデータおよびタグに関して、前記格納された情報と合致するものとして検証される場合には、前記得られたデータを、前記データ・バンドルの関数と関連づけて、前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに受け渡す、
ように動作できるプログラムが前記信頼されるサーバーと前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに供給されるような信頼されるサーバー、
を備えることを特徴とするシステム。
【請求項３２】前記第１のデータは秘密データを含むことを特徴とする請求項３１記載のシステム。
【請求項３３】前記得られたデータは暗号鍵を含むことを特徴とする請求項３１記載のシステム。
【請求項３４】前記第１のデータは秘密データを含み、かつ、前記得られたデータは暗号鍵を含むことを特徴とする請求項３１記載のシステム。
【発明の詳細な説明】
【０００１】
（背景技術）
近年、貴重なコンテンツを含め、デジタル・コンテンツが知的財産を含むために、あるいは、機密にかかわる個人情報または金融情報を含むために、そのようなデジタル・コンテンツの保護は、コンシューマー側にあるハードウェアの利用をともなう必要があることが認識されてきた。このようなハードウェアは、エンドユーザの保護において重要な役割を果たせることも認識されており、その場合、このようなハードウェアは、さらに安全なアクセス認証を達成するために、スマートカード、および他のパーソナル・トークンの形式で展開されている。プロバイダに関しては、ソフトウェアのコピー保護という厳しく制限された目的の範囲内で、何らかの成功を収めたコンシューマー側にある単純なハードウェアの一例として、ドングルを指す場合がある。
【０００２】
しかしながら、このコンシューマー側にあるハードウェアは、インターネットによる効率的運用にはまったく影響を与えず、その場合、ネットワークしたデジタル媒体の領域では、そのような効率的運用の欠如が特に深刻である。革新的な流通経路としてインターネットを利用する際に、その機会を認識しているものもある。しかしながら、その課題は、そのような専用装置の設計、製造、大量販売の費用、並びに、消費者や様々な業界（例えば、消費者向け電子機器、コンテンツ配信、バンキング・サービス、インターネット・サービス）への前記装置の魅力であった。
【０００３】
このようなコンシューマー側にあるセキュリティ装置の費用を減らし、かつ、そのような装置の魅力を高める１つの可能性は、２つ以上のプロバイダへのアクセスをオープンにすることによる場合もあることが開示されている。実際、上記のハードウェアが、あらかじめプログラムされ、かつ狭い範囲で定められるやり方で、複数のプロバイダのために働くのではなく、代りに、そのコアに、オープン・プログラマビリティ（ｏｐｅｎ ｐｒｏｇｒａｍｍａｂｉｌｉｔｙ）を取り入れることで、非常に柔軟に遂行できる場合には、広範囲に及ぶコンシューマーの展開を妨げる障害物がかなり減らされることがある。普通なら、定められた目的の製品を実現するために必要であるはずの、まったく異なる企業実体間の困難な緊密結合を、オープン・ハードウェアがゆるめることができる。ライバルの同業者の調停の成功が動機となって、プロバイダとは無関係のメーカが、セキュリティ装置の広範囲にわたる促進を専門とすることが望ましいものとなる。
【０００４】
しかしながら、大部分または全部の従来技術の複数用途、プロバイダ独立型のセキュリティ・ハードウェアは、特にコンシューマーのプライバシやコプロセッサのフォールト・トレランスに対して、他のシステム設計の課題を導入する点で、共通の欠点を免れないものと考えられる。前述のセキュリティ・ハードウェアのアノニマス（匿名）サービスは、アクセストークン式システムを利用するが、ただし、複数用途の信頼される実行環境でのアノニミティ（匿名性）が、まさしく、今なお公開研究テーマとなっている。扱われたことのない重要な問題は、プロバイダの間で、特定のシステムの基盤情報を共有して、各コンシューマーの包括的なプロファイルを形成する場合があるという事実である。コンシューマーがトランザクションを望むあらゆるプロバイダには、コンシューマーのセキュリティ・モジュールの保証公開鍵を配布する。次に、悪辣きわまる小集団のプロバイダの間で、この保証公開鍵を共有して、コンシューマーの購入習慣の暴露的なプロファイルを作成する場合がある。このシステム設計のプライバシ保護の特徴は、必要であっても、その基礎をなす通信トランスポートがアノニミティの特徴をサポートしなければ、厳密なプライバシ要件を満たすのに充分であるとは言えないことに留意されたい。
【０００５】
さらに大きな注目に値するもう１つの問題は、充分な資源を有する敵対者により、エンドユーザのコプロセッサが危険にさらされる場合があるという事実である。上記のあらゆる目標をサポートする信頼基盤は、このようなシナリオにおいては、フォールト・トレランスの特色をなすであろう。単純な一例は、危険にさらされたコプロセッサの任意の数のクローンが、このシステムに侵入しないようにすることである。しかしながら、上に述べられる共同使用、高プライバシのシステムの関係により、構築の抑制（ａｒｃｈｉｔｅｃｔｉｎｇ ｃｏｎｔａｉｎｍｅｎｔ）や損害制限能力の問題がさらに難しくなる。
【０００６】
よって、プライバシの保護とコプロセッサのフォールト・トレランスを向上させる複数用途、プロバイダ独立型のセキュリティ・ハードウェアが今なお必要となっている。従来技術は、これらの要求を満たすとは考えられない。
【０００７】
（発明の開示）
本発明の目的は、クライアントと、少なくとも１つのリモートサーバーとの間のセキュア（安全な）関係を基本とするトランザクションに対して、信頼を高めることである。
【０００８】
本発明の他の目的は、複数のクライアントにより用いられるコンピュータ・オブジェクト・データの制御を行うことである。
【０００９】
本発明のさらに他の目的は、コプロセッサのフォールト・トレランスを高めることである。
【００１０】
以下に記述されるさらなる開示内容を参照すると明らかになる上記および他の目的を満たすために、本発明は、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、リモートサーバーとの間のトランザクションに対して信頼を高める方法、および、リモートサーバーと関連づけられたソースデータから得られたコンピュータ・オブジェクト・データであって、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントが利用できるオブジェクト・データの制御を行う方法を提供する。
【００１１】
本発明は、少なくとも１つの公開鍵データを受け入れるように構成された信頼されるサーバーを用いることで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、少なくとも１つのリモートサーバーとの間のトランザクションに対する信頼を高め、その場合、それぞれの公開鍵データは、このプラットフォーム用の公開鍵／秘密鍵の対の一部として、クライアント・プラットフォームと特に関連づけられる。このような公開鍵／秘密鍵の対は、このクライアント・プラットフォームと、この信頼されるサーバーのうちの少なくとも１つを用いて生成される場合がある。
【００１２】
追加的な承認データも、この公開鍵データと関連づけて、この公開鍵データを、それを受け入れる信頼されるサーバーにより承認されたものとして特定する。次に、信頼できる追加的な承認データを見分けるように構成されているリモートサーバーに、この公開鍵データと、その関連づけられた追加的な承認データを提供する。リモートサーバー固有のデータも、この承認された公開鍵データと関連づけ、また、その関連づけられたリモートサーバー固有のデータが、この公開鍵データと関連づけられたクライアント・プラットフォーム秘密鍵といっしょに使用される。その信頼されるサーバーとのクライアント・プラットフォームのやり取りを通じて、この信頼されるサーバーが、リモートサーバーからのサーバー固有のデータとともに、クライアント・プラットフォーム秘密鍵を、少なくとも１回、利用することに気づいて、この公開鍵データを、このリモートサーバーと関連づけることを受け入れるか、または拒絶し、かつ、保証を与えるか、または拒否する機会を、その信頼されるサーバーに与える。
【００１３】
本発明は、少なくとも１つの信頼されるサーバーを使用して、データを、リモートサーバーから、その信頼されるサーバーに転送することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、そのリモートサーバーとの間のトランザクションに対して信頼を高める。この転送されるデータは、少なくとも１つの秘密データを含む。このような転送は、データ転送セキュリティ対策とともに行われる。この転送されるデータの一部の関数は、その信頼されるサーバーからクライアント・プラットフォームに提供される。その場合、この転送されるデータの一部には、秘密データの少なくとも一部が含まれる。この信頼されるサーバーは、信頼できると見なされるクライアント・プラットフォームと関連づけられるものとして、この信頼されるサーバーにより識別できる少なくとも１つの鍵で暗号化されたその関数の１つの値を、クライアント・プラットフォームに提供する。このクライアント・プラットフォームは、この暗号化された関数値を復号化する機能を果たし、従って、この関数値は、リモートサーバーとクライアント・プラットフォームとの間で安全に共有される場合がある。
【００１４】
本発明はまた、コンピュータ・オブジェクト・データをクライアント・コンピュータ・マイクロプロセッサ・プラットフォームに、信頼されるように受け渡すことができるようにし、その場合、リモートサーバーは、受け渡されるオブジェクト・データが一関数（例えば、代数関数などの数学関数、ハッシュ、変換、恒等関数、または、オブジェクト・データをその引数として有する別の関数）であるソースデータを提供する。このような受渡しは、リモートサーバーに知られている秘密データを特定することで、達成される。この秘密データは、信頼されるサーバーに提供されて、一意のタグを用いて特定される。コンピュータ・オブジェクト・データは、その提出されたソースデータから得られ、その場合、このオブジェクト・データは、その信頼されるサーバーにより計算された署名と関連づけられ、またこの署名は、そのオブジェクト・データの一関数である。次に、このコンピュータ・オブジェクト・データは、クライアント・プラットフォームでの利用のために提供される。
【００１５】
本発明は、リモートサーバーと関連づけられたソースデータから得られるコンピュータ・オブジェクト・データを制御し、その場合、このオブジェクト・データは、一意のタグと関連づけられた第１のデータを特定することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントで利用できる。第１のデータと、その関連タグは、リモートサーバーに知られている。次に、第２のデータが、第１のデータおよびタグと関連づけられ、その場合、第２のデータは、第１のデータおよびタグと、第２のデータを反映させる情報を格納するように構成されている信頼されるサーバーから、提供される。次に、コンピュータ・オブジェクト・データは、得られたデータの一関数として計算された値に結び付けられ、そこでは、この得られたデータは、第１のデータを表わすデータと第２のデータを表わすデータのうち、少なくとも１つを含む。このような結び付けは、その信頼されるサーバーにより実施される。追加的なデータ・バンドルはまた、リモートサーバーでは、リモードサーバーの追加的データを、ｉ）第１のデータを表わすデータと第２のデータを表わすデータのうち、少なくとも１つ；ｉｉ）その関連タグと関連づけることにより、形成される。この追加的なデータ・バンドルは、検証のために、信頼されるサーバーに提出される。このデータ・バンドルが、その信頼されるサーバーで格納される第１のデータおよびタグと第２のデータに関して、その格納された情報と合致するものとして検証される場合には、得られたデータは、そのデータ・バンドルの関数と関連づけられて、クライアント・プラットフォームに受け渡す。
【００１６】
本発明の一実施形態では、第１のデータは、秘密データを含むことができるか、もしくは、秘密データである。さらに、この得られたデータは、暗号鍵を含むか、あるいは、暗号鍵であることもある。
【００１７】
この開示内容に織り込まれ、かつこの開示内容の一部を構成している添付図面は、本発明の好ましい実施形態を図解するものであって、本発明の原理を説明するのに役立つ。
【００１８】
（発明を実施するための最良の形態）
クライアント側のコンピュータ（例えば、様々なサーバーにリンクさせるインターネットなどの分散形データネットワークにアクセスするビジネスユーザまたは個人ユーザのパーソナルコンピュータ）などの常用されるコンピュータは、一般にコプロセッサを含んでいる。コプロセッサという用語の使用は、本明細書中では、コンシューマー／クライアントのレベルで使用されるコプロセッサを指すことに限定される。そのコプロセッサに対応するサーバークラスのデバイスは、ハードウェア・セキュリティ・モジュール（ＨＳＭ）という用語で示される。セキュア・コプロセッサは、Ｓ．Ｗ．Ｓｍｉｔｈ氏、Ｂ．Ｒ．Ｐａｌｍｅｒ氏、Ｓ．Ｈ．Ｗｅｉｎｇａｒｔ氏の「Ｕｓｉｎｇ ａ Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ， Ｐｒｏｇｒａｍｍａｂｌｅ Ｓｅｃｕｒｅ Ｃｏｐｒｏｃｅｓｓｏｒ（高性能なプログラマブル・セキュア・コプロセッサを利用して）」（第２回国際金融暗号化会議の会議報告書、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ ＬＮＣＳにより１９９８年発行）の中で開示されるように、いくつかのタイプに分類される場合がある。このセキュア・オープンシステムをサポートするものと考えられるコプロセッサは、これらの種類のいくつかと重複する。このようなコプロセッサを、ＨＳＭ、すなわちハイエンドのセキュア・コプロセッサのものと同じ領域内に置くようなオープン・プログラミング環境が好ましいことは明らかである。その一方、このコプロセッサは、多分、資源制約形のコンシューマー機器内で働く必要があるであろう。このような埋め込みフットプリントを有するコプロセッサは、暗号アクセラレータの種類に、より良く適合するように思われる。
【００１９】
次に、図１に関して、本発明の模範的なアプリケーションとトラスト・フレームワークを述べる。
【００２０】
このモデルにおいて、プロバイダが配信する代表的なサービスまたはアプリケーションには、次の３つのエンティティが含まれる。すなわち、「リモートサーバー」とも呼ばれる「アプリケーション・サーバー（ＡＳ）」１２０、コンシューマー側にある従来の保護されてないホスト装置１３０、および、コプロセッサの信頼される実行環境１１０である。このクライアント側の信頼される実行環境内で実行するソフトウェア・アプリケーション・コンポーネントは、セキュア・アプリケーション・コンポーネント（ＳＡＣ）１４０と呼ばれる。クライアント側の計算設備の全体は、「クライアント・コンピュータ・マイクロプロセッサ・プラットフォーム」または「クライアント・プラットフォーム」と呼ばれる。「コンピュータ・オブジェクト・データ」は、ＳＡＣ実行可能プログラムを含む場合がある。また「ソース・データ」は、ＳＡＣまたはＳＡＣ実行可能プログラムのソース（コード）を含む場合がある。
【００２１】
「信頼されるサーバー（ｔｒｕｓｔｅｄ ｓｅｒｖｅｒ）」とも呼ばれる「トラスト・サーバー（ｔｒｕｓｔ ｓｅｒｖｅｒ）」１５０は、プライバシか、抑制の目的のいずれかの緩和に対応する２つの退廃した事例を調査することが動機となって、もたらされた。
【００２２】
抑制（ｃｏｎｔａｉｎｍｅｎｔ）が必要でない場合には、コプロセッサが、いくつかのアノニマス・アクセス方式の任意のものと結合された形式的には見分けのつかないコプロセッサであることを請け負うだけで、充分にプライバシを保証できる。この結果は、その信頼される実行環境のフィーチャ・セットの影響を受けないことに留意されたい。コードは、機密に、かつ起点の認証と完全性チェックの双方を用いて、いかなる特定コプロセッサにも移送することができる。この要件は、実際、暗号鍵材料を、それらのコプロセッサにプレロードする必要がある場合に、それらのコプロセッサがすべて、同一データを得ることにすぎない。
【００２３】
逆に、抑制だけが求められる場合には、各コプロセッサ用の一意の保証公開鍵を利用して、プロバイダが課金を追跡し、見つけられるほど危険にさらされたハードウェアに対する信頼を撤回できるようにする場合がある。
【００２４】
抑制とプライバシの双方が要求されるときには、コンシューマーとプロバイダとの信頼関係の授与と撤回の仲介をするために、信頼される仲介物が必要である。よって、「トラスト・サーバー」１５０は、このような仲介物として使用される。コプロセッサ１７０を用いて、コンシューマーまたはクライアントのプライバシを最大限保護するために、コプロセッサ１７０とＳＡＣ１４０のインスタンスとの関連づけを知っているものが、「トラスト・サーバー」１５０に限定されなければならない。
【００２５】
前述の考察から、コプロセッサの個別化の必要性が明白である。ＳＡＣ１４０の個別化の要件は、プロバイダが、コプロセッサ１７０を横切って、その個々のインスタンスの経過を追う必要があることから、生まれたものである。ＳＡＣ１４０を個別化する２つの方法、すなわち、プロバイダの「アプリケーション・サーバー」１２０によるＳＡＣ個別化と、「トラスト・サーバー」１５０によるＳＡＣ個別化が使用される場合がある。
【００２６】
ＳＡＣ１４０のアンインストールと再インストールから成る１サイクル後に、ＳＡＣ１４０が、新しい個別化データを備えるべきかどうかという問題がある。一方では、同一データを発行することで、プロバイダは、怪しげな行動をしているＳＡＣ１４０のインスタンスを一方的に撤回して、おそらく、そのインスタンスがランするコプロセッサ１７０が危険にさらされていることを示すこともある。他方では、公正なコンシューマーが、プライバシのために要望するのであれば、これらのコンシューマーに、個別化のつながりを断ち切らせるべきである。それゆえ、インストールごとの新しい個別化は、初めてのものであろうと、繰返しのものであろうと、求められる。このことは、ＳＡＣ１４０に対して責任のあるプロバイダ１７０が、特定のコプロセッサ１７０上のＳＡＣ１４０を撤回するプロセスを変更する。プロバイダが、その要求を提出する「トラスト・サーバー」１５０は、この撤回プロセスを仲裁しなければならない。コンシューマーのプライバシを保護し、かつプロバイダのニーズを満たすという２つの相補的な責任は、「トラスト・サーバー」１５０にある。
【００２７】
下記の表は、本明細書に用いられている技術的表記法を要約している。
【００２８】
【表１】
「トラスト・サーバー」１５０内のハードウェア・セキュリティ・モジュール（ＨＳＭ）１６０は、そのマスタ・ホストのスレーブの働きをするものと考えられるが、ただし、それ自体の保護されるコードを実行し、また、その秘密鍵、および、「トラスト・サーバー」のデータベースから検索されたデータのローカル認証用の秘密値のような静的数値を安全に保存することができる。ＨＳＭ１６０は、動的な状態メモリを持つとは考えられないが、ただし、このようなメモリが利用できる程度に、このメモリを使えば、首尾よく危険にさらされた装置の大規模なクローン化をともなう抑制攻撃から、「トラスト・サーバー」１５０を守るのに役立てることができる。このようなメモリに左右されることなく、処理および通信のどの面を保護することができるのか調査する利点がいくつかある。動的に変化するＨＳＭ１６０の効果的なバックアップ、およびハードウェア障害に適切な反応と妨害の決定は、解決すべき難問であることもある。ここでの「トラスト・サーバー」１５０は、モノリシックのホスト／ＨＳＭの組合せであるが、機能により、この「トラスト・サーバー」を、別々のコンポーネントに分けることができる。一例として、ＳＡＣパブリッシングと一括個別化を処理するために、「アプリケーション・サーバー」１２０と対話する単一のサーバーがあることもある。このようなサーバーは、「アプリケーション・サーバー」１２０と、それぞれがクライアント側のコプロセッサ・ユーザの異なる母集団に係わる複数のデバイス・サーバーとのインターフェースの働きをすることもある。うわべは、プロトコル設計をわずかに変更したものが、全体のシステムのセキュリティ・プロファイルに大きな影響を与えかねないことを示す例が与えられる。サブシステムが、さらに重要な資源にすでにアクセスしている他のサブシステムから遠く隔てて実行される場合には、このサブシステムを、削減されたハードウェア費用と保守の要件のもとに保護することが特に重要であることもある。
【００２９】
コプロセッサ１７０と「トラスト・サーバー」１５０間を通過するいかなるデータも、認証と暗号化によって保護されなければならない。関係のあるコプロセッサ１７０のＩＤの証拠を隠すように、注意も払わなければならない。例えば、サイファテキストの上に添付署名のあるサイファテキストの公知構造は、この要件に違反することになる。なぜならば、コプロセッサ公開鍵の網羅的なリストを備えて、署名の検証を試みることもあるからである。本発明は、「Ｓｅｃｕｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（安全な通信）」の見出しのもとに、ＨＳＭ１６０向けにコプロセッサ１７０により暗号化されたいかなるデータも、「トラスト・サーバー」１５０のインサイダでは復号化できないように；ＨＳＭ１６０により、コプロセッサ１７０向けに暗号化されたいかなるデータも、「トラスト・サーバー」のインサイダでは復号化できないように；現時点で「トラスト・サーバー」１５０に保持されているデータにアクセスせずには、ＨＳＭ１６０から来たものとして、メッセージを、コプロセッサ１７０にうまくスプーフィングすることができないように；現時点で「トラスト・サーバー」１５０に保持されているデータにアクセスせずには、コプロセッサ１７０から来たものとして、メッセージを、ＨＳＭ１６０にうまくスプーフィングすることができないように、とりわけ求めている。「トラスト・サーバー」１５０のインサイダは、データがコプロセッサ１７０から来たかのように、そのデータをＨＳＭ１６０にうまくスプーフィングすることができないとは考えられない。同様に、「トラスト・サーバー」１５０のインサイダは、データがＨＳＭ１６０から来たかのように、そのデータをコプロセッサ１７０にうまくスプーフィングすることができないとは考えられない。
【００３０】
本発明は、少なくとも１つの公開鍵データを受け入れるように構成された信頼されるサーバー１５０を使用することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、少なくとも１つのリモートサーバーとの間のトランザクションに対して信頼を高める。その場合、各公開鍵データは、クライアント・プラットフォーム用の公開鍵／秘密鍵の対の一部として、このクライアント・プラットフォームと特に関連づけられる。この公開鍵／秘密鍵の対は、このクライアント・プラットフォームと、この信頼されるサーバー１５０のうち少なくとも１つを用いて、生成される場合がある。追加的な承認データも、この公開鍵データと関連づけて、この公開鍵データを、それを受け入れる信頼されるサーバー１５０により承認されたものとして特定する。次に、この公開鍵データと、その関連づけられた追加的な承認データをリモートサーバーに提供する。その場合、このリモートサーバーは、信頼できる追加的な承認データを見分けるように構成されている。
【００３１】
リモートサーバー固有のデータも、この承認された公開鍵データと関連づけ、また、その関連づけられたリモートサーバー固有のデータが、この公開鍵データと関連づけられたクライアント・プラットフォーム秘密鍵といっしょに使用される。その信頼されるサーバーとのクライアント・プラットフォームのやり取りを通じて、この信頼されるサーバーが、リモートサーバーからのサーバー固有のデータとともに、クライアント・プラットフォーム秘密鍵を、少なくとも１回、利用することに気づいて、この公開鍵データを、このリモートサーバーと関連づけることを受け入れるか、または拒絶し、かつ、保証を与えるか、または拒否する機会を、その信頼されるサーバーに与える。
【００３２】
前述の通り、ＳＡＣ１４０の個別化の要件は、プロバイダが、コプロセッサ１７０を横切って、その個々のインスタンスの経過を追う必要があることから、生まれたものである。ＳＡＣ１４０を個別化する２つの方法、すなわち、「アプリケーション・サーバー」１２０による方法と、「トラスト・サーバー」１５０による方法があることにも留意された。図２および図３を参照すると、「アプリケーション・サーバー」１２０によるＳＡＣ個別化の方法が示されている。
【００３３】
図２を参照すると、「アプリケーション・サーバー」（ＡＳ）１２０によるセキュア・アプリケーション・コンポーネント（ＳＡＣ）の暗号化プロセスを示すブロック図が与えられている。公開配布の前に、「アプリケーション・サーバー」（ＡＳ）１２０は、新規の識別子ＳＡＣ．ＩＤを、それぞれのＳＡＣ１４０に割り当てる。次に、ＳＡＣ１４０の暗号化に用いられる対称鍵ＳＡＣ．ｋｅｙを生成する。次に、対称的に暗号化されたＳＡＣは、配布のために公に利用できるようにする。
【００３４】
図３を参照すると、コプロセッサ１７０によるクーポン収集と、「アプリケーション・サーバー」１２０でのクーポンの引換えのプロセスを示すブロック図が示されている。アノニマス証明書すなわち「クーポン」に対応する秘密鍵（ｐｒｉｖＫｅｙ）は、成功するようには改ざんされなかったコプロセッサ１７０から漏洩しないコプロセッサ・レベルの秘密であるようになっている。その結果、「アプリケーション・サーバー」１２０は、疑わしいコプロセッサ１７０が、サービスまたはコンテンツを成功するように獲得する条件として、それらの正当性を証明するのに用いる手法を柔軟に決定できるようにするのではなく、コプロセッサ１７０との規定された対話を、それらの通信コードに織り込まなければならない。
【００３５】
悪辣きわまるアプリケーション・プロバイダは、普通なら、その「アプリケーション・サーバー」を構成し、Ｒａｂｉｎ復号化（すなわち、モジュラ平方根の計算）が、その係数（ｍｏｄｕｌｕｓ）の因数分解（ｆａｃｔｏｒｉｎｇ）と等価であることに基くもの、あるいは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ関連のプロトコルに対する小サブグループの攻撃に基くもののように、オラクル（ｏｒａｃｌｅ）を利用しようとするはずである。このようなプロトコルの欠陥が検出されなくなるとすると、このような秘密鍵の遠隔収集が、潜在的に、広範囲に利用されることになろう。
【００３６】
（図３のステップ１１において）ＡＳ署名が適正に検証され、また、当初、「アプリケーション・サーバー」１２０が使用して、公開配布（図２のステップ３において）の前に、ＳＡＣ１４０を暗号化した鍵（ＳＡＣ．ｋｅｙ）が、その復号化されたメッセージからもたらされる場合を除き、ＳＡＣ１４０は、適合するコプロセッサ１７０にインストールできなくなることに留意されたい。ＡＳ．ＩＤは、コプロセッサ１７０により、「アプリケーション・サーバー」の公開鍵証明書から得られる。ＡＳ１２０が、「トラスト・サーバー」１５０でのクーポンの引換えの代りにコプロセッサ１７０が得る受領書に対して、有効性試験を無視することに決めたとしても、ＡＳ．ＩＤは、ＴＳ（「トラスト・サーバー」）１５０により書き留められており、したがって、（潜在的に課金の目的だけでなく）追跡の目的でも、この情報を記録することができる。このような受領書の証拠を、「アプリケーション・サーバー」１２０に提供しても、うまく改ざんされたコプロセッサ１７０に対応するクーポンが、「何回も使われる」ことになろう。適合するコプロセッサ１７０は、時間（または、他の計量）の或る指定限度値を超えた後で、ホームを呼び出さなかった場合に、重要な機能を失うようにプログラムされていることで、「トラスト・サーバー」１５０に縛られるが、うまく改ざんされたコプロセッサ１７０は、そのようなレポートバック（折返し報告）を避ける場合がある。これらのコプロセッサが、新規の鍵材料を得るために、折返し報告する必要がある場合には、例えば、これらのコプロセッサは、過去の活動ログについて、うまく嘘を言うことができる場合もある。「トラスト・サーバー」１５０が発行する受領書中の「ｂｌｏｂ」に依存すれば、改ざんされた装置でも、使用可能な受領書を蓄積することができなくなることに留意されたい。
【００３７】
ＨＳＭ１６０で実施される処理の最小単位（ａｔｏｍｉｃｉｔｙ）とともに、コプロセッサ１７０と「トラスト・サーバー」１５０との間の「安全な通信」の想定から、改ざんされた装置の内通なしに働く「トラスト・サーバー」１５０のインサイダは、それが、対応する秘密鍵を知っているクーポンを得ることができなくなる。この好ましい実施形態のこれらの２つの面は、公開鍵データが、「安全な通信」のもとに、信頼されるサーバー１５０により、クライアント・プラットフォームから受け取られる場合に、その信頼されるサーバー１５０が、その公開鍵データを受け入れるように構成されることが何を意味するか説明するのに役立つ。
【００３８】
この方法は、適合するコプロセッサ１７０と「アプリケーション・サーバー」１２０との間で共有される（ＳＡＣレベル）「ｂｌｏｂ」（すなわち、ＳＡＣ個別化データ）が、コプロセッサ１７０と「アプリケーション・サーバー」１２０との間のＳＡＣレベルの通信に、どのように使用されるべきか故意に指定しない。
【００３９】
このデータの潜在的な「乱用」は、任意の独立して管理されたＳＡＣ１４０のセキュリティには影響を及ぼさない。
【００４０】
コンシューマーのプライバシの視点から、改ざんされたコプロセッサ１７０は、保証ＡＳ公開鍵に対応するＡＳ秘密鍵を知っている「アプリケーション・サーバー」１２０とやり取りをしているというユーザの確信を揺るがすことはできない。例えば、「アプリケーション・サーバー」１２０による署名入り暗号化ステップが、データへの別の署名および暗号化＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞と取り替えられる場合には、以下の攻撃が開始されることもある。
【００４１】
改ざんされたコプロセッサ１７０は、トランザクションを完了させることなく（これらのクーポンが、ＴＳ１５０にて引換えが行われるものとしてマークされないようにするため）、クーポンを収集し、それらのクーポンを使用することもある。改ざんされたコプロセッサ１７０は、対応するＥｎｃ（＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞）と、その関連ｐｒｉｖＫｅｙの知識に基いて、おそらく、それぞれの＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞の知識を得ることができよう。Ｓｉｇｎ（＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞，ＡＳ．ｐｒｉｖＫｅｙ）は、コプロセッサ関連の入力には依存しないから、その改ざんされたコプロセッサ１７０は、ターゲットのｐｕｂＫｅｙ値のもとに暗号化された＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞を再利用できることになる。敵対者は、プレーンテキストの実行可能プログラムにアクセスするであろうが、しかしながら、敵対者は、例えば、ＳＡＣ１４０のターゲット・コプロセッサのインスタンスによりランダムに生成されたデータ上の署名を予想するＳＡＣ１４０内のコードによって、裏をかかれることもある。敵対者が、これらのクーポンを「アプリケーション・サーバー」１２０に使用することを中止しかった場合には、ターゲット・コプロセッサ１７０は、潜在的に機密のいかなる情報も、敵対者に無意識に伝達しようとしなくなるであろう。これは、「トラスト・サーバー」１５０において、そのクーポンの再利用が検出されることになるからである。いかなる場合にも、このタイプの攻撃は、実際のプロトコル設計において妨げられる。なぜなら、この署名は、ｐｕｂＫｅｙの使用を通じて、コプロセッサ１７０に基いて様々であるような暗号を使っているからである。
【００４２】
情報の信頼性が、匿名扱いにするサーバーまたは他の信頼されるサーバー１５０、あるいは、代表して行動するものによって保証される場合には、プライバシの視点から、クライアント・プラットフォームのユーザは、証明書のステータスに関して、そのような情報をリモートサーバーに開示することを特定のトランザクションが正当とするかどうかの判定に関与べきである。このような保証手順は、（コンピュータで）偽造できないように設計できるから、そのような保証は、クライアント・プラットフォーム・ユーザにより、その信頼されるサーバー１５０に要請でき、また、その信頼されるサーバー１５０からの応答を、クライアント・プラットフォーム・ユーザも、リモートサーバーに受け渡すことができる。このリモートサーバーが、或る自己指定した時点（時間の関数、集計されたサービスへのアクセス、あるいは、他の計量（１つまたは複数）である場合もある）により、充分な保証指示を受け取らない場合には、リモートサーバーは、特定のクライアント・プラットフォーム・ユーザとの関係を断つことに決めることがある。このリモートサーバーは、信頼されるサーバーによってもたらされる保証に反映されるものと思っている適切な情報を、公開鍵データと関連づけたリモートサーバー固有のデータに含めることで、リモートサーバーが受ける任意の保証が新しいかどうか判定できる。この手順は、証明書の信頼性の保証だけでなく、公開鍵データに対応する秘密鍵を有するという証拠を示す追加的な利点（このように構成される場合）も持っている。したがって、信頼されるサーバー１５０は、秘密鍵の少なくとも１回の利用に気づく（「安全な通信」のもとに）。好ましい実施形態では、サーバー固有のデータ（すなわち、ｂｌｏｂ、ｂｌｏｂＴａｇ、ＳＡＣ．ｋｅｙ）は、復号化する秘密鍵を用いて、クライアント・プラットフォームにより復元される（図３のステップ１１において）。その場合、この復元されたデータの或る関数（すなわち、Ｈ（ｂｌｏｂ））が、リモートサーバーのＩＤ（ＳＡＣ．ＩＤとともに、ＡＳ．ＩＤ）を付けて、その信頼されるサーバー１５０に送られる。リモートサーバーではなく、クライアント・プラットフォーム・ユーザに、保証の要求を処理させることで、これは、課金モデルにおいて汎用性を高めることを可能にする。証明書の使用料をリモートサーバーに請求する場合には、普通なら、その信頼されるサーバーに、その証明書の使用を知らせないでおくために、保証の要求から身を引くはずである。いかなる時点においても、クライアント・プラットフォームの関係を、ただ１つの信頼されるサーバーに限定することで、これは、さらに有意義に、証明書の使用を追跡できるようにしている。満了日を証明書に織り込むことが知られているが、これは、証明書が、どの程度まで信頼されてきたか、また、この証明書が、信頼できると考えられるべきかどうかは、示していない。証明書撤回リスト（ＣＲＬ）を利用しても、リモートサーバーの潜在的な問題は、満足のいくようには処理されていない。最新バージョンの保証された受渡しやスケーラビリティのように、ＣＲＬと関連づけられた通常の問題に加えて、クライアント・プラットフォームのユーザ・プライバシを織り込むことも、ＣＲＬの効力を徐々に弱める場合がある。
【００４３】
本発明は、以下のように、異なる撤回手法を考慮に入れている。すなわち、証明書ＩＤのリストを指定するリモートサーバーの事前要請を受けて、特定のクライアント・プラットフォームが、疑わしい証明書ＩＤの１つと関連づけられているものとして、その信頼されるサーバーでマークされる場合には、該当するリモートサーバーに対して、リモートサーバー固有のデータと関連づけられた保証用の将来のクライアント・プラットフォーム・ユーザの要求が否定されることがある。リモートサーバーで起こされたこれらの要求が、適正に認証される場合には、リモートサーバーは、他のリモートサーバーに対する保証プロセスには影響を及ぼさない。この技法は、クライアント・プラットフォーム・ユーザの側において、うわべは詐欺的な活動を見つけるために、リモートサーバーが、信頼されるサーバー１５０よりも優れた立場にあることがあるような電子商取引のインスタンスが存在するという事実に基いていることに留意されたい。なぜなら、この信頼されるサーバー１５０は、コンテンツまたはサービスにアクセスするのに、ロギングや課金などの実際の電子商取引のトランザクションに立ち会わないからである。さらに、このようなトランザクションは、それらの信頼されるサーバーから隠される場合がある。なぜなら、これらのトランザクションは、本発明により可能となるように、クライアント・プラットフォームとリモートサーバーとの間で共有される秘密データに基いて保護される場合があるからである。リモートサーバーは、ユーザ・プライバシが実施される場合に、２つの証明書ＩＤが、同一のクライアント・プラットフォームに一致するかどうか、それ自体では、認識できない。信頼されるサーバー１５０とは違って、リモートサーバーは、そのリモートサーバーの制御下にあるクライアント・プラットフォームでランしているアプリケーションの挙動に影響を及ぼすことがあっても、クライアント・プラットフォームの挙動に直接に影響を及ぼすことができない場合もある。
【００４４】
ＳＡＣ１４０を個別化する別の方法は、「トラスト・サーバー」１５０によるものである。図４〜図７を参照すると、「アプリケーション・サーバー」１２０によるＳＡＣ個別化の方法が示されている。
【００４５】
この方法では、重要な抑制目標が達成される。すなわち、「トラスト・サーバー」のインサイダと、うまく改ざんされたコプロセッサとの組合せからでも、「追加的な」事前格納されたＳＡＣ個別化データの知識は安全である。さらに正確に言えば、危険にさらされる唯一のＳＡＣ個別化データは、危険にされされている（あるいは、危険にされされるであろう）コプロセッサ１７０、または、それらのコプロセッサのクローンに供されるものである。この方法では、ＳＡＣ個別化データは、一括して「トラスト・サーバー」１５０に受け渡されて、ＳＡＣのインストールおよび個別化の間、コプロセッサ１７０に分け与える目的で蓄積される。この手順は、一度に一つのキャンディ・タブレットを分け与える（それぞれ、一回出されて、消費される）前に、ＰＥＺ（登録商標）キャンディ自動販売機にキャンディを満たすことに、いくらか類似している。コプロセッサ１７０に分け与えられるそれぞれの個別化データのパケットは、「トラスト・サーバー」１５０による追跡目的で、また、「アプリケーション・サーバー」１２０がやり取りする任意の特定のコプロセッサ１７０により、どのｂｌｏｂ値が意図的に保持されているか「アプリケーション・サーバー」１２０に特定させるために、使用できるｂｌｏｂＴａｇだけでなく、データのｂｌｏｂも含む場合がある。コプロセッサの安全な環境内で、ＳＡＣ１４０でアクセスされる適切なｂｌｏｂ値を知ることを条件として、コンテンツまたはサービスを、クライアント・プラットフォームにうまく受け渡す場合がある。所与のＳＡＣ．ｎｕｍｂｅｒに対応するＳＡＣ１４０のすべてのバージョンまたはアップグレードは、一括個別化データの同一（補充可能な）プールを取り除くように設計されているから、「アプリケーション・サーバー」１２０からの一括受渡しの間、「トラスト・サーバー」１５０による処理と格納の間、および、コプロセッサ１７０にパーミッションが付与されているＳＡＣインスタンスの個別化の間、このデータを攻撃から保護するだけでは充分でない（ただし、必要である）。所望のセキュリティ・レベルを達成するために、ＳＡＣパブリッシング・プロセスも保護しなければならない。この当面の目標に対応する問題は、ＳＡＣ１４０のパブリッシングを要求する「アプリケーション・サーバー」１２０（すなわち、プロバイダ）の信頼性を保証するものではなく、もっと適切に言えば、ＳＡＣシリーズが初期設定されると、正当な「アプリケーション・サーバー」１２０が、手におえぬＳＡＣをパブリッシングさせる能力があろうと、なかろうと、侵入者を拒絶する戦略が所定の場所に置かれていることを保証するものである。手におえぬＳＡＣは、ターゲットの「アプリケーション・サーバー」の個別化データを乱用するか、あるいは、そのデータを暴露することで、そのデータを悪用することもある。
【００４６】
さきに取り上げられた第１の方法は、「トラスト・サーバー」１５０の外部で、ＳＡＣのパブリッシングと署名の双方を扱ったことを想起しよう。ＳＡＣシリーズの一括個別化とＳＡＣパーミッション付与は、現行方法の場合のように扱われるが、ただし、「アプリケーション・サーバー」１２０（ＡＳ）は、それ自体のＳＡＣ１４０の署名と、それ自体のパブリッシングを行うと仮定しよう。その場合、ＡＳ１２０は、ＳＡＣ．ｋｅｙのそれ自体の値を生成し、かつ、ＳＡＣシリーズの初期設定のために、ＳＡＣ．ｎｕｍｂｅｒ、Ｅｎｃ（＜ＡＳ．ｔｒａｃｋ，ＳＡＣ．ｋｅｙ，ＳＡＣ．ｎｕｍｂｅｒ＞，ＴＳ．ｐｕｂＫｅｙ）を、「トラスト・サーバー」１５０に送ることになる。次に、単一のコプロセッサ１７０が危険にさらされると、敵対者は、ＳＡＣ．ｎｕｍｂｅｒの、ターゲットＡＳと同一値と、ＳＡＣ．ｋｅｙの同一（危険にされされた）値を用いて、手におえぬＳＡＣをパブリッシングすることができる。敵対者は、ＳＡＣシリーズの初期設定ベクトルを提出する必要がないから、この攻撃は、ＴＳインサイダの共謀を必要としないであろう。敵対者の目標は、それ自体の一括個別化データを提出することではなく、ターゲットをハイジャックすることである。
【００４７】
次に、記録されたプロトコルがすべて使用されるが、ただし、ＡＳが、ＴＳ ＨＳＭ１６０によりランダムに生成されるのではなく、ＡＳに、ＳＡＣ．ｋｅｙのそれ自体の値を選ばせることを考えてみよう。次に、ＳＡＣ．ｋｅｙのターゲットの値をもたらすコプロセッサ１７０の攻撃が、ＴＳインサイダの攻撃と組み合わされることもあり、そこでは、敵対者は、ＳＡＣ．ｎｕｍｂｅｒの同一値の強制やり直しを用いて、ＳＡＣ．ｋｅｙの、そのターゲットが選んだものと同じ値を選ぶ。敵対者は、ＳＡＣ．ｎｕｍｂｅｒのこの値を用いて、標準のＳＡＣシリーズの初期設定ステップを実施し、それにより、敵対者は、そのターゲットの個別化データをうまくインストールでき、かつその個別化データにアクセスできる手におえぬＳＡＣをパブリッシングさせることができる。これは、敵対者が、ＳＡＣ．ｎｕｍｂｅｒおよびＳＡＣ．ｋｅｙの同一値を共有するからである。それゆえに、ＡＳ１２０に、ＳＡＣ．ｋｅｙのそれ自体の値を選択させれば、インサイダが、選択された値の暗号に代えることができないように、ＳＡＣ．ａｓｓｉｇｎにＴＳ．ｌｏｃａｌを含めることで（図４に指定される通り）提供された保護がうまく避けられる。
【００４８】
実際の現行方法が、コププロセッサの危険のさらしと、ＴＳのインサイダというニ方面からの攻撃に対して、その抵抗を達成するために、このプロトコル設計の重要な面は、ＡＳ．ｋｅｙが、一般に、コプロセッサ１７０には絶対に提供されず、したがって、このようなやり方で、危険にはさらされないことである。ターゲットのＡＳ．ｋｅｙを知らずには、敵対者は、「最後に」パブリッシングするのに必要な不足引数（ｍｉｓｓｉｎｇ ａｒｇｕｍｅｎｔ）を提供できない（すなわち、検証可能な署名を提供できない）。その署名と、コプロセッサ１７０へのＳＡＣ個別化データの提示との間に、だますことのできない（ｕｎｓｐｏｏｆａｂｌｅ）結び付けがあることも重要である。デジタル署名は、その署名の引数を結び付ける手段を与えることは、従来技術において知られており、その場合、この署名を付けるメッセージは、そのような引数をいくつか含むと解釈できる。したがって、帰納的に推論すると、データを、既存の署名に結び付ける１つの方法は、その署名の追加的な引数として、そのデータの関数を入力することである。
【００４９】
本発明は、少なくとも１つの信頼されるサーバーを利用して、データを、リモートサーバーから、その信頼されるサーバーに転送することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、そのリモートサーバーとの間のトランザクションに対して信頼を高める。この転送されるデータは、少なくとも１つの秘密データを含む。このような転送は、データ転送セキュリティ対策とともに行われる。この転送されるデータの一部の関数は、その信頼されるサーバーからクライアント・プラットフォームに提供される。その場合、この転送されるデータの一部には、秘密データの少なくとも一部が含まれる。この信頼されるサーバーは、信頼できると見なされるクライアント・プラットフォームと関連づけられるものとして、この信頼されるサーバーにより識別できる少なくとも１つの鍵で暗号化されたその関数の１つの値を、クライアント・プラットフォームに提供する。そのクライアント・プラットフォームは、この暗号化された関数値を復号化する機能を果たし、従って、この関数値は、リモートサーバーとクライアント・プラットフォームとの間で安全に共有される場合がある。
【００５０】
図６のステップ４のメッセージに示されるように、ＡＳ．ｔｒａｃｋを一括個別化データ移動と関連づけることは、ＳＡＣ．ｋｅｙのどの暗号鍵の値を、ＳＡＣ個別化の値（ｂｌｏｂＴａｇ，ｂｌｏｂ）（それぞれ、図７のステップ５のメッセージで、コプロセッサ１７０に受け渡される）に付加すべきか明瞭に示すのに役立つ。当初、図４のステップ９で計算されるように、所与のＳＡＣシリーズの初期設定の間に、ＳＡＣ．ａｓｓｉｇｎへのＴＳ ＨＳＭ１６０によるアクセスに基いて、図６のステップ５、ステップ６、ステップ７において、一括個別化の一部として、ＳＡＣ個別化の値に、ＳＡＣ．ｋｅｙの値を対応づける。ＡＳ．ｔｒａｃｋの秘密を維持することにより、敵対者は、ＳＡＣシリーズの初期設定の間、敵対者が知っているＡＳ．ｋｅｙの値とともに、再利用されるＳＡＣ．ｎｕｍｂｅｒとして、この値を再提出するために、この値の知識を用いないようにしていることに留意されたい。このような策略がもし成功する場合には、この策略により、敵対者は、ＳＡＣ個別化データを、ＳＡＣの手におえぬものにコース変更することができよう。手におえぬＳＡＣで用いられるデータを、このようにコース変更させないようにする目的では、一括個別化の間に、ＡＳ．ｔｒａｃｋの秘密値（例えば、Ｈ（ＡＳ．ｔｒａｃｋ））を明瞭に表わす（ただし、その秘密値を漏らさない）秘密でない値を使用するだけで、実際に充分であろう。これは、ＳＡＣシリーズの初期設定の間、ＡＳ．ｋｅｙの公知の値とともに、ＡＳ．ｔｒａｃｋを提出するために、ＡＳ．ｔｒａｃｋの値を知ることが必要であるからである。
【００５１】
安全にコプロセッサ１７０に配布するために、個別化データを、適正なＳＡＣ．ｋｅｙに確実にリンクする方法を、このようにして設計した後で、また、ＡＳ．ｋｅｙのターゲットの秘密値のもとに、手におえぬＳＡＣを、利用可能にうまくパブリッシングすることを阻止する方法を設計した後では、これから、ＳＡＣパブリッシングの間に、「トラスト・サーバー」１５０が生成する署名に、ＳＡＣ．ｋｅｙを確実に結び付ける手段を提供しなければならない。このような目的では、ＳＡＣ．ｎｕｍｂｅｒまたはＳＡＣ．ＩＤを用いることだけでは充分でない。これは、充分な状態メモリを持たないＴＳ ＨＳＭ１６０が、これらの値の詐欺的な再利用を追跡できない場合があり、かつ、これらの値が、毎回ランダムに生成されるようになってないからである。現行設計に取り入れられた手法は、この署名の引数として、Ｈ（ＳＡＣ．ｋｅｙ）を入力することである。コプロセッサ１７０の安全な実行環境内で、ＳＡＣ．ｋｅｙのこの値を使用して、この署名検証プロセスへの入力として、ＳＡＣ１４０のサイファテキスト形式を復号化する。この設計は、この署名内に、ＳＡＣ１４０のプレーンテキスト（すなわち、ＳＡＣ．ｋｅｙ独立型）のものを使用して、「アプリケーション・サーバー」１２０により、この署名のコプロセッサ独立型の検証を可能にして、「アプリケーション・サーバー」１２０が、ＡＳ．ｋｅｙの知識に基いて、署名検証の間に計算する署名の不足引数を公に利用できるようにすべきかどうか判定を行う。Ｈ（ＳＡＣ．ｋｅｙ）の明示的な（ただし、秘密ではない）使用から、このような結び付けを行うのに必要な連係が提供される。
【００５２】
ＳＡＣパブリッシングの間に、署名を生成する原子的な（ａｔｏｍｉｃ）処理により、特に、インサイダは、その署名の暗号化されない引数Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞）の計算に用いられる異なる（手におえぬ）ＳＡＣと並置された、ＳｙｍＥｎｃ（Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞），ＡＳ．ｋｅｙ）が知られている、以前にパブリッシングされた（正当な）ＳＡＣ１４０に代えることができない。
【００５３】
（ＳＡＣ．ｋｅｙベースの技法とは違って）機密性のためにＳＡＣ暗号化の影響を受けない、ＳＡＣ個別化データの処理を保護する代替手段は、以下のように進むこともある：図５（ＳＡＣパブリッシング）のステップ１２の間に送られるメッセージ中の署名の引数として現れるＨ（ＳＡＣ．ｋｅｙ）を、Ｈ（ＡＳ．ｔｒａｃｋ）に代える。Ｈ（ＡＳ．ｔｒａｃｋ）は、その署名とともに、「アプリケーション・サーバー」１２０に送られる必要はない。これは、ＳＡＣ．ｋｅｙ（図４のステップ８において、「トラスト・サーバー」により生成される）と違って、ＡＳ．ｔｒａｃｋの適切な値が、図４（ＳＡＣシリーズの初期設定）のステップ５においてＡＳ．ｔｒａｃｋを生成した「アプリケーション・サーバー」１２０により知られると想定されるからである。未使用の形式のＳＡＣ．ｋｅｙは、コプロセッサで使用するために、図７（ＳＡＣパーミッション付与）のステップ５において、クライアント・プラットフォームに送られるが、コプロセッサが危険にさらされると、ＡＳ．ｔｒａｃｋの値が得られなくなるであろうから、ＡＳ．ｔｒａｃｋ自体ではなく、Ｈ（ＡＳ．ｔｒａｃｋ）などのＡＳ．ｔｒａｃｋを示す秘密でない値を、ステップ５に類似するステップの間、コプロセッサ１７０に伝達することが重要である。ＳＡＣ．ｋｅｙは、ＳｙｍＥｎｃ（ＳＡＣ．ｅｘｅ，ＳＡＣ．ｋｅｙ）を復号化するためにＳＡＣ．ｋｅｙの値を必要とするコプロセッサ１７０に、Ｈ（ＡＳ．ｔｒａｃｋ）とともに送られる場合があることに留意されたい。なぜなら、これは、ＳＡＣ実行可能プログラムを受け取る形式であるからである。
【００５４】
ＳＡＣパーミッション付与の間、アップグレードのコプロセッサ１７０によるインストールと、ＳＡＣ１４０の新規インストール（これは、ＳＡＣ．ｎｕｍｂｅｒに対応するような、現時点でインストールされたＳＡＣ１４０がまったくないことを特徴としている）は、新規個別化データの吸収を拒否することに留意されたい。この属性により、そのシステムは、なんらかの方法で個別化データに結び付けられたか、あるいは個別化データにより保護されたデジタル権データが、アップグレードを横切って維持できる点で、ＤＲＭ（デジタル権管理）フレンドリとなる。
【００５５】
この方法は、レガシー・プロバイダ基盤の問題を扱い、それにより、「アプリケーション・サーバー」１２０は、すでに存在するクライアント側の装置のユーザとともに、複数用途のコプロセッサのユーザとやり取りすることができる。第１の方法において必要であったように、「アプリケーション・サーバー」１２０とコプロセッサ１７０との間で共有される秘密に切り替えるのに、予備段階はまったく必要でない。さらに、「アプリケーション・サーバー」１２０が、一度もコプロセッサ１７０とやり取りしなくても、所与のＳＡＣ１４０または互いに信頼されるＳＡＣのインスタンスは、ＳＡＣレベルの暗号化および／または認証を用いて、「ピア・ツー・ピア」通信を行うことができる。これは、ｂｌｏｂ内の秘密鍵に対応する公開鍵を備えた証明書をｂｌｏｂＴａｇに含ませることで、達成できる。
【００５６】
ここでは、さらに調査はされないが、潜在的な混成手法があり、この手法は、（第１の方法の場合のように）、「トラスト・サーバー」１５０と「アプリケーション・サーバー」１２０との間で、ＳＡＣ個別化データ値を調整する必要はないが、ただし、（第２の方法の場合のように）、ＳＡＣパブリッシングと、「トラスト・サーバー」１５０を通じてのＳＡＣのインストールを扱う。
【００５７】
「トラスト・サーバー」１５０が、実行可能プログラム／ソースコードの起点の認証を実施するという範囲で、コンシューマーのプライバシは、「トラスト・サーバー」１５０の外部の詐欺師が、ターゲットされた「アプリケーション・サーバー」のＩＤのもとに、ＳＡＣ１４０をパブリッシングさせるような攻撃から保護される。オプションのＳＡＣパブリッシング許可手順に従う場合には、適合性についてソースコード自体の検査だけでなく、ＳＡＳソースコードの起点をサポートするバンド外の記録の追加的な再調査もあることがある。ＳＡＣパブリッシング許可プロセスの必要がない場合には、この起点の認証を、直接に、ＨＳＭ１６０に持ち込むことができる。もちろん、ＨＳＭ１６０が、デジタル署名入りコードを、保証署名鍵と対照して検証しても、認証局（ＣＡ）を利用して、証明書の発行前にＩＤを認証する登録プロセスも、潜在的に攻撃を受ける。
【００５８】
気づかれないように、「トラスト・サーバー」１５０の内部のＳＡＣ個別化データを、公知の値に代えることは、潜在的には、プロバイダの抑制目標に対する攻撃ではなく、コンシューマーのプライバシに対する攻撃である。危険にさらされたコプロセッサと「トラスト・サーバー」のインサイダの攻撃との共謀の結果、ＳＡＣパーミッション付与の間に、ターゲット・コプロセッサ１７０への＜ｂｌｏｂＴａｇ，ｂｌｏｂ＞の値の分け与えを不正に繰り返すことで、このような取替えが発生しかねない。この場合、これらの値は、危険にさらされたコプロセッサから得られた値と一致する。コプロセッサ１７０と「トラスト・サーバー」１５０との間の「安全な通信」での仮定のために、また、暗号化された一括個別化データの入力が、ＳＡＣシリーズを初期設定したエンティティによる許可（ＡＳ．ｔｒａｃｋの安定した入力を介して）を必要とするために、ＴＳのインサイダの攻撃、あるいはコプロセッサが危険にさらされることだけでは、このような攻撃は可能とはならない。
【００５９】
このプロセスの好ましい実施形態は、図６と図７に示されている。データのどの部分が、クライアント・プラットフォームの属性のどの集まりを含むと見なされるかに関して、移動を、リモートサーバーと、信頼されるサーバー１５０との間の調整と関連づけられる場合があり、したがって、これらの関数値が、適宜に、クライアント・プラットフォームに提供される場合がある。
【００６０】
好ましい実施形態は、信頼されるように、コンピュータ・オブジェクト・データを、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに受け渡すことができるようにし、その場合、リモートサーバーは、その受け渡されたオブジェクト・データが関数であるソースデータを供給する。このような受渡しは、リモートサーバーに知られている秘密のデータを特定することで、達成される。この秘密のデータは、信頼されるサーバーに提供されて、一意のタグを用いて特定される。このコンピュータ・オブジェクト・データは、その提出されたソースデータから得られる。その場合、このオブジェクト・データは、その信頼されるサーバーによって計算された署名と関連づけられ、また、その署名は、そのオブジェクト・データの関数である。次に、このコンピュータ・オブジェクト・データは、クライアント・プラットフォームで使用するために提供される。
【００６１】
好ましい実施形態では、この秘密のデータは、ＡＳ．ｋｅｙをさす。ＡＳ．ｋｅｙは、図４に示されるように、ＳＡＣシリーズの初期設定の間、信頼されるサーバーに提供されて、一意のタグＳＡＣ．ｎｕｍｂｅｒを用いて特定される。ＳＡＣのソースコードまたはＳＡＣ実行可能プログラムを含むソースデータは、ＳＡＣ．ｖｅｒｓｉｏｎだけでなく、ＳＡＣ．ｎｕｍｂｅｒも指定したＳＡＣ．ＩＤと関連させて、信頼されるサーバー１５０に提出される。図５（ＳＡＣパブリッシング）は、このようなデータの転送を示している。クライアント・プラットフォームでの使用のために提供される情報は、ＳＡＣ実行可能プログラムＳＡＣ．ｅｘｅの形式でコンピュータ・オブジェクト・データを含み、また、このようなコンピュータ・オブジェクト・データは、暗号化形式ＳｙｍＥｎｃ（ＳＡＣ．ｅｘｅ，ＳＡＣ．ｋｅｙ）で公に利用できるようになっている。この関連署名、すなわち、Ｓｉｇｎ（＜ＡＳ．ＩＤ，Ｈ（ＳＡＣ．ｋｅｙ），ＳｙｍＥｎｃ（Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞），ＡＳ．ｋｅｙ），Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞）＞，ＴＳ．ｐｒｉｖＫｅｙ）は、署名引数Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞）を介して、このオブジェクト・データの関数ｆ１である。一実施形態では、このオブジェクト・データの関数ｆ２は、ＳｙｍＥｎｃ（Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞），ＡＳ．ｋｅｙ）をさす。別法として、ｆ２（ｄａｔａ）＝ＳｙｍＥｎｃ（ｄａｔａ）とｆ３（ｄａｔａ）＝ｄａｔａが使用される場合がある。他の実施形態では、ｆ２（ｄａｔａ）＝ｄａｔａと、ｆ３（ｄａｔａ）＝ＳｙｍＥｎｃ（ｄａｔａ）が使用される場合がある。
【００６２】
本発明は、リモートサーバーと関連づけられたソースデータから得られるコンピュータ・オブジェクト・データを制御し、その場合、このオブジェクト・データは、一意のタグと関連づけられた第１のデータを特定することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントで利用できる。第１のデータと、その関連タグは、リモートサーバーに知られている。次に、第２のデータが、第１のデータおよびタグと関連づけられ、その場合、第２のデータは、第１のデータおよびタグと、第２のデータを反映させる情報を格納するように構成されている信頼されるサーバーから、提供される。次に、コンピュータ・オブジェクト・データは、得られたデータの一関数として計算された値に結び付けられ、そこでは、この得られたデータは、第１のデータを表わすデータと第２のデータを表わすデータのうち、少なくとも１つを含む。このような結び付けは、その信頼されるサーバーにより実施される。追加的なデータ・バンドルはまた、リモートサーバーでは、リモートサーバーの追加的データを、ｉ）第１のデータを表わすデータと第２のデータを表わすデータのうち、少なくとも１つ；ｉｉ）その関連タグと関連づけることにより、形成される。この追加的なデータ・バンドルは、検証のために、信頼されるサーバーに提出される。このデータ・バンドルが、その信頼されるサーバーで格納される第１のデータおよびタグと第２のデータに関して、その格納された情報と合致するものとして検証される場合には、得られたデータは、そのデータ・バンドルの関数と関連づけられて、クライアント・プラットフォームに受け渡す。
【００６３】
好ましい実施形態では、第１のデータは、ＡＳ．ｔｒａｃｋを含み、また一意のタグは、ＳＡＣ．ｎｕｍｂｅｒを含む。第２のデータは、ＳＡＣ．ｋｅｙを含む。ＳＡＣ．ｎｕｍｂｅｒ、ＡＳ．ｔｒａｃｋ、ＳＡＣ．ｋｅｙを含む情報は、ＳＡＣ．ａｓｓｉｇｎとして、信頼されるサーバーにて格納される（図４）。この得られたデータはＳＡＣ．ｋｅｙを含み、その関数はＨ（・）であり、また、この結び付けは、デジタル署名により行われて、図５のステップ１１の署名が得られる。追加的なデータ・バンドルは、図６のステップ４に示されている。ＳＡＣ．ｎｕｍｂｅｒでインデックスされるＳＡＣ．ａｓｓｉｇｎに対して、その提出されたデータ・バンドルが一致しているかの検証が、図６のステップ５で行われる。ＳＡＣ．ｋｅｙを、データ・バンドルの関数と関連づけて、（後で）クライアント・プラットフォームに受け渡す作業が、図６のステップ６とステップ７に示されている。
【００６４】
本発明の一実施形態では、第１のデータは秘密データを含む。さらに、この得られたデータは、暗号鍵も含む。
【００６５】
本発明の他の実施形態では、第１のデータはＡＳ．ｔｒａｃｋを含み、また一意のタグはＳＡＣ．ｎｕｍｂｅｒを含む。ＳＡＣ．ｎｕｍｂｅｒとＡＳ．ｔｒａｃｋを含む情報は、図４のＳＡＣ．ａｓｓｉｇｎの格納と同様に、信頼されるサーバーに格納される。この得られたデータはＨ（ＡＳ．ｔｒａｃｋ）を含み、その関数は恒等関数であると考えられる場合があり、また、その結び付けは、デジタル署名により行われる。このデータ・バンドルの関数は、Ｈ（ＡＳ．ｔｒａｃｋ）と関連づけられる。
【００６６】
このシステムに参加するコンシューマーのプライバシの権益を保護しながら、コンテンツ・プロバイダやサービス・プロバイダの業務への損害の抑制を達成するという同一目標に合わされた２つの異なるアーキテクチャが導入されている。これらの相反する要件は、プログラマブル・セキュリティ・コプロセッサをコンシューマー端末とトラスト・サーバーに導入して、その端末とサーバーが、これらの装置に直接にアクセスし、そこで、ユーザのプライバシをなお維持しながら、プロバイダのアプリケーションのパーミッションを、それらの装置に付与することができることから、最適な調停が得られる。
【００６７】
ユーザは、それ以外の人が少しずつ収集できるが、しばしば該当するコンシューマーには相応の利益がもたらさないような貴重な情報の量を制限するために、インターネット上で行われる活動に対して、それらのユーザの人物（ｐｅｒｓｏｎａ）を変更する正当な権利を有する。個々のプロバイダが、それらのプロバイダに知られているカスタマとの関係を扱えることがあるのと類似するやり方で、トラスト・サーバーは、このようなサービスの適合しない使用の疑いがかけられているユーザに、さらなるサービスのパーミッションを付与することを拒絶できる。入念なプロトコル設計と、カスタマとサーバー端末の双方におけるハードウェア・セキュリティ資源のきちんと調整された使用により、インサイダの攻撃に対しても、コンシューマーの詐欺行為に対しても、かなりの防衛度が達成できる。２つの方法のうちの第１の方法は、このプロセスとのトラスト・サーバーのかかわりあいを最小限利用する傾向がある強力なＰＫＩ（公開鍵基盤）の特質をその特徴としている。第２の手法は、レガシー基盤を扱うことができるが、ただし、この手法は、ピア・ツー・ピアＰＫＩも、コプロセッサとアプリケーション・サーバー共有の秘密を基本とする暗号もサポートできる鍵材料を用いて、コプロセッサを個別化できるような混成手法にも当てはまる。
【００６８】
以上の説明は、本発明の模範的な実施形態を参照して、本発明の原理を単に例示しているにすぎない。これらの記述される実施形態の様々な変更例や変形例は、本明細書中の教えから見て、当業者には明らかとなろう。したがって、当業者であれば、本明細書中に明示的に図示され、記述されてなくても、本発明の原理を実施し、ゆえに、本発明の精神および範囲内にある多数の技法を案出できるものと理解されよう。
【図面の簡単な説明】
【図１】
本発明と、本発明のトラスト・フレームワークの概略を示す例解図
【図２】
アプリケーション・サーバー（ＡＳ）によるセキュア・アプリケーション・コンポーネント（ＳＡＣ）の暗号化プロセスを示すブロック図
【図３】
クライアント・プラットフォーム上のコンプロセッサ（Ｃｐ）によるＳＡＣ個別化プロセスのクーポン収集およびクーポン償還を示すブロック図
【図４】
アプリケーション・サーバーおよびトラスト・サーバー（ＴＳ）によるＳＡＣ個別化プロセスにおいて、ＳＡＣシリーズの初期設定を示すブロック図
【図５】
アプリケーション・サーバーおよびトラスト・サーバーによるＳＡＣ個別化プロセスにおいて、ＳＡＣ公表プロセスを示すブロック図
【図６】
アプリケーション・サーバーおよびトラスト・サーバーによるＳＡＣシリーズのバルク個別化を示すブロック図
【図７】
コプロセッサ内へのＳＡＣパーミッションの付与を示すブロック図
【発明の名称】クライアントとサーバー間の信頼を管理するシステムおよび方法
【特許請求の範囲】
【請求項１】（１）クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、（２）少なくとも１つのリモートサーバーとの間のセキュア（安全な）関係を基本とするトランザクションに対して信頼を高める方法であって、
（ａ）少なくとも１つの公開鍵データを受け入れるように構成された信頼されるサーバー（ｔｒｕｓｔｅｄ ｓｅｒｖｅｒ）を使用するステップであって、前記公開鍵データがそれぞれ、前記プラットフォーム用の公開鍵／秘密鍵の対の一部として、前記クライアント・プラットフォームと特に関連づけられ、また、前記公開鍵／秘密鍵の対がそれぞれ、（ｉ）クライアント・プラットフォームか、（ｉｉ）前記信頼されるサーバーのうちの少なくとも１つを用いて、生成される場合があるステップと、
（ｂ）追加的な承認データを前記公開鍵データと関連づけて、前記公開鍵データを、前記公開鍵データを受け入れた前記信頼されるサーバーにより承認されたものとして特定するステップと、
（ｃ）前記公開鍵データを信頼できるものとして承認するために、前記信頼されるサーバーからの信頼できる追加的な承認データを見分けるように構成されている前記リモートサーバーが、前記公開鍵データと前記関連づけられる追加的な承認データを利用できるようにするステップと、
（ｄ）リモートサーバー固有のデータを、前記承認された公開鍵データと関連づけるステップであって、前記関連づけられるリモートサーバー固有のデータが、前記公開鍵データと関連づけられたクライアント・プラットフォーム秘密鍵といっしょに使用され、また、前記信頼されるサーバーとのクライアント・プラットフォームのやり取りを通じて、前記信頼されるサーバーが、前記リモートサーバーからのサーバー固有のデータとともに、前記クライアント・プラットフォーム秘密鍵を、少なくとも１回、利用することに気づいて、前記公開鍵データを前記リモートサーバーと関連づけることを受け入れるか、または拒絶し、かつ、保証を与えるか、または拒否する機会を、前記信頼されるサーバーに与えるステップ、
を含むことを特徴とする方法。
【請求項２】（１）クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、（２）リモートサーバーとの間のトランザクションに対して信頼を高める、少なくとも１つの信頼されるサーバーを使用する方法であって、
（ａ）少なくとも１つの秘密データを含むデータを、前記リモートサーバーから、信頼されるサーバーに転送するステップであって、前記転送が、データ転送セキュリティ対策とともに行われるステップと、
（ｂ）前記転送されるデータの一部の関数を、前記信頼されるサーバーから前記クライアント・プラットフォームに提供するステップであって、前記データの一部には、前記少なくとも１つの秘密データの少なくとも一部が含まれ、また、前記転送する信頼されるサーバーが、信頼できると見なされるクライアント・プラットフォームと関連づけられるものとして、前記信頼されるサーバーにより識別できる少なくとも１つの鍵で暗号化された前記関数の１つの値を、前記クライアント・プラットフォームに提供し、前記クライアント・プラットフォームが、前記暗号化された関数値を復号化する機能を果たすステップ、および
（ｃ）前記関数の前記値を、前記リモートサーバーと前記クライアント・プラットフォームとの間で安全に共有できるようにするステップ、
を含むことを特徴とする方法。
【請求項３】前記信頼されるサーバーから前記クライアント・プラットフォームに提供される前記関数の前記値は、前記信頼されるサーバーに知られている前記クライアント・プラットフォームの属性によって決まることを特徴とする請求項２記載の方法。
【請求項４】コンピュータ・オブジェクト・データをクライアント・コンピュータ・マイクロプロセッサ・プラットフォームに、信頼されるように受け渡す方法であって（その場合、前記受け渡されるオブジェクト・データが一関数であるソースデータはリモートサーバーが提供する）、
（ａ）前記リモートサーバーに知られている、前記オブジェクト・データと区別できる秘密データを特定するステップであって、前記秘密データを、信頼されるサーバーに提供して、一意のタグを用いて特定するステップと、
（ｂ）前記一意のタグと関連させて、ソースデータを前記信頼されるサーバーに提出させるステップと、
（ｃ）前記提出されたソースデータから得られた前記コンピュータ・オブジェクト・データを、クライアント・プラットフォームでの利用のために提供するステップであって、前記オブジェクト・データを、前記信頼されるサーバーにより計算された署名と関連づけ、また前記署名が、前記オブジェクト・データの関数ｆ１であるようなステップ、
を含むことを特徴とする方法。
【請求項５】（ｉｉ）前記署名が、前記オブジェクト・データの関数ｆ２をさらに含むことと、前記オブジェクト・データの知識が与えられた前記オブジェクト・データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項４記載の方法。
【請求項６】（ｉｉ）前記署名が、データの関数ｆ２をさらに含むことと、前記信頼されるサーバーが関数値を利用できることと、データの関数ｆ３を前記リモートサーバーに提供することと、データの関数ｆ３の知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項４記載の方法。
【請求項７】前記データは、前記信頼されるサーバーにより、少なくとも一部ランダムに生成されることを特徴とする請求項６記載の方法。
【請求項８】前記データの知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項６記載の方法。
【請求項９】前記データの知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ３の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項６記載の方法。
【請求項１０】リモートサーバーと関連づけられたソースデータから得、かつクライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントで利用できるコンピュータ・オブジェクト・データを制御する方法であって、
（ａ）一意のタグと関連づけられた第１のデータを特定するステップ（前記第１のデータと、その関連タグは、前記リモートサーバーに知られている）と、
（ｂ）前記第１のデータおよびタグと、前記第２のデータを反映させる情報を格納するように構成される信頼されるサーバーから提供されている前記第２のデータを、前記第１のデータおよびタグと関連づけるステップと、
（ｃ）コンピュータ・オブジェクト・データを、得られたデータの一関数として計算された値に結び付けるステップであって、前記得られたデータが、（Ａ）前記第１のデータを表わすデータと、（Ｂ）前記第２のデータを表わすデータのうち、少なくとも１つを含み、また、前記結び付けが、前記信頼されるサーバーにより実施されるステップと、
（ｄ）前記リモートサーバーでは、（ｉ）前記リモードサーバーの追加的データを、（ｉｉ）（Ｃ）前記第１のデータを表わすデータと（Ｄ）前記第２のデータを表わすデータのうち少なくとも１つと、また、（ｉｉｉ）前記関連タグと関連づけて、追加的なデータ・バンドルを形成するステップと、
（ｅ）前記追加的なデータ・バンドルを、前記信頼されるサーバーに提出し、また、前記データ・バンドルが、前記信頼されるサーバーで格納される前記第１のデータおよびタグと前記第２のデータに関して、前記格納された情報と合致するものとして検証される場合には、前記得られたデータを、前記データ・バンドルの関数と関連づけて、クライアント・プラットフォームに受け渡すステップ、
を含むことを特徴とする方法。
【請求項１１】前記第１のデータは秘密データを含むことを特徴とする請求項１０記載の方法。
【請求項１２】前記得られたデータは暗号鍵を含むことを特徴とする請求項１０記載の方法。
【請求項１３】前記第１のデータは秘密データを含み、かつ、前記得られたデータは暗号鍵を含むことを特徴とする請求項１０記載の方法。
【請求項１４】リモートサーバーと関連づけられたソースデータから得、かつクライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントで利用できるコンピュータ・オブジェクト・データを制御する方法であって、
（ａ）一意のタグと関連づけられた第１のデータを特定するステップ（前記第１のデータと、その関連タグは、前記リモートサーバーに知られている）と、
（ｂ）コンピュータ・オブジェクト・データを、得られたデータの一関数として計算された値に結び付けるステップであって、前記得られたデータが、前記第１のデータを表わすデータを含み、前記結び付けが、前記信頼されるサーバーにより実施され、また、前記信頼されるサーバーが、前記第１のデータおよびタグを反映させる情報を格納するように構成されているステップと、
（ｃ）前記リモートサーバーでは、（ｉ）前記第１のデータを表わすデータを含む前記リモードサーバーの追加的データを、（ｉｉ）前記関連タグと関連づけて、追加的なデータ・バンドルを形成するステップと、
（ｄ）前記追加的なデータ・バンドルを、前記信頼されるサーバーに提出し、また、前記データ・バンドルが、前記信頼されるサーバーで格納される前記第１のデータおよびタグに関して、前記格納された情報と合致するものとして検証される場合には、前記得られたデータを、前記データ・バンドルの関数と関連づけて、クライアント・プラットフォームに受け渡すステップ、
を含むことを特徴とする方法。
【請求項１５】前記第１のデータは秘密データを含むことを特徴とする請求項１４記載の方法。
【請求項１６】前記得られたデータは暗号鍵を含むことを特徴とする請求項１４記載の方法。
【請求項１７】前記第１のデータは秘密データを含み、かつ、前記得られたデータは暗号鍵を含むことを特徴とする請求項１４記載の方法。
【請求項１８】安全な関係を基本とするトランザクションに対して信頼を高めるシステムであって、
ａ）少なくとも１つのリモートサーバーと、
ｂ）前記少なくとも１つのリモードサーバーと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合された少なくとも１つの公開鍵データを受け入れるように構成されたトラスト・サーバーと、
ｄ）前記トラスト・サーバーと動作可能に結合されたクライアント・コンピュータ・マイクロプロセッサ・プラットフォームであって、
ｉ）それぞれ（ｉ）前記クライアント・プラットフォームまたは（ｉｉ）前記信頼されるサーバーの少なくとも１つを用いて生成される場合のある、前記プラットフォーム用の公開鍵／秘密鍵の対の一部として、それぞれが、前記クライアント・プラットフォームと、とりわけ関連づけられた少なくとも１つの公開鍵データを受け入れるように構成された前記信頼されるサーバーを使用する、
ｉｉ）追加的な承認データを前記公開鍵データと関連づけて、前記公開鍵データを受け入れる前記信頼されるサーバーによって承認されたものとして、前記公開鍵データを特定する、
ｉｉｉ）前記公開鍵データを信頼できるものとして承認するために、前記信頼されるサーバーからの信頼できる追加的な承認データを見分けるように構成されているリモートサーバーに、前記公開鍵データと前記関連づけられた追加的な承認データを提供する、
ｉｖ）前記公開鍵データと関連づけられた前記クライアント・プラットフォーム秘密鍵とともに用いられるリモートサーバー固有のデータを、前記承認された公開鍵データと関連づけ、そこでは、前記信頼されるサーバーとのクライアント・プラットフォームのやり取りを通じて、前記信頼されるサーバーが、前記リモートサーバーからのサーバー固有のデータとともに、前記クライアント・プラットフォーム秘密鍵を、少なくとも１回、利用することに気づいて、前記公開鍵データを、前記リモートサーバーと関連づけることを受け入れるか、または拒絶し、かつ、保証を与えるか、または拒否する機会を、前記信頼されるサーバーに与える、
ように動作できるプログラムが供給されるクライアント・コンピュータ・マイクロプロセッサ・プラットフォーム、
を備えることを特徴とするシステム。
【請求項１９】安全な関係を基本とするトランザクションに対して信頼を高めるシステムであって、
ａ）少なくとも１つのリモートサーバーと、
ｂ）前記少なくとも１つのリモードサーバーと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合されたクライアント・コンピュータ・マイクロプロセッサ・プラットフォームと、
ｄ）前記データ通信リンクと動作可能に結合された信頼されるサーバーであって、
ｉ）少なくとも１つの秘密データを含むデータを、前記リモートサーバーから前記信頼されるサーバーに転送し、かつ、このような転送を、データ転送セキュリティ対策とともに行う、
ｉｉ）前記転送されるデータの一部の関数を、前記信頼されるサーバーから前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに提供し、前記データの一部には、前記少なくとも１つの秘密データの少なくとも一部が含まれ、また、前記転送する信頼されるサーバーが、信頼できると見なされる前記クライアント・プラットフォームと関連づけられるものとして、前記信頼されるサーバーにより識別できる少なくとも１つの鍵で暗号化された前記関数の１つの値を、前記クライアント・プラットフォームに提供し、前記クライアント・プラットフォームが、前記暗号化された関数値を復号化する機能を果たす、
ｉｉｉ）前記関数の前記値を、前記リモートサーバーと前記クライアント・プラットフォームとの間で安全に共有できるようにする、
ように動作できるプログラムが供給される信頼されるサーバー、
を備えることを特徴とするシステム。
【請求項２０】前記信頼されるサーバーから前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに提供される前記関数の前記値は、前記信頼されるサーバーに知られている前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームの属性によって決まることを特徴とする請求項１９記載のシステム。
【請求項２１】コンピュータ・オブジェクト・データを、信頼されるように受け渡すシステムであって、
ａ）少なくとも１つのリモートサーバーと、
ｂ）前記少なくとも１つのリモードサーバーと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合されたクライアント・コンピュータ・マイクロプロセッサ・プラットフォームと、
ｄ）前記データ通信リンクと動作可能に結合された信頼されるサーバーであって、
ｉ）前記リモートサーバーに知られている、前記オブジェクト・データと区別できる秘密データを特定し、前記秘密データを、信頼されるサーバーに提供して、一意のタグを用いて特定する、
ｉｉ）前記一意のタグと関連させて、ソースデータを前記信頼されるサーバーに提出させる、
ｉｉｉ）前記提出されたソースデータから得られた前記コンピュータ・オブジェクト・データを、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームでの利用のために提供し、前記オブジェクト・データを、前記信頼されるサーバーにより計算された署名（前記オブジェクト・データの関数ｆ１である）と関連づける、
ように、同時に動作できるプログラムが前記信頼されるサーバーと前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに供給されるような信頼されるサーバー、
を備えることを特徴とするシステム。
【請求項２２】前記署名が、前記オブジェクト・データの関数ｆ２をさらに含むことと、前記オブジェクト・データの知識が与えられた前記オブジェクト・データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項２１記載のシステム。
【請求項２３】前記署名が、データの関数ｆ２をさらに含むことと、前記信頼されるサーバーが関数値を利用できることと、データの関数ｆ３を前記リモートサーバーに提供することと、前記データの関数ｆ３の知識と前記オブジェクト・データの知識が与えられたデータの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項２１記載のシステム。
【請求項２４】前記データは、前記信頼されるサーバーにより、少なくとも一部ランダムに生成されることを特徴とする請求項２３記載のシステム。
【請求項２５】前記データの知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ２の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項２３記載のシステム。
【請求項２６】前記データの知識と前記オブジェクト・データの知識が与えられた前記データの前記関数ｆ３の計算が、前記秘密データの正確な知識を必要とすることを特徴とする請求項２３記載のシステム。
【請求項２７】リモートサーバーと関連づけられたソースデータから得るコンピュータ・オブジェクト・データを制御するシステムであって、
ａ）複数のクライアント・コンピュータ・マイクロプロセッサ・プラットフォームと、
ｂ）前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合された信頼されるサーバーであって、
ｉ）一意のタグと関連づけられた第１のデータを特定する（前記第１のデータと、その関連タグは、前記リモートサーバーに知られている）、
ｉｉ）前記第１のデータおよびタグと、前記第２のデータを反映させる情報を格納するように構成される前記信頼されるサーバーから提供されている前記第２のデータを、前記第１のデータおよびタグと関連づける、
ｉｉｉ）コンピュータ・オブジェクト・データを、得られたデータの一関数として計算された値に結び付け、そこでは、前記得られたデータが、（Ａ）前記第１のデータを表わすデータと、（Ｂ）前記第２のデータを表わすデータのうち、少なくとも１つを含み、また、前記結び付けを、前記信頼されるサーバーで実施する、
ｉｖ）前記リモートサーバーでは、（ｉ）前記リモードサーバーの追加的データを、（ｉｉ）（Ｃ）前記第１のデータを表わすデータと（Ｄ）前記第２のデータを表わすデータのうち少なくとも１つと、また、（ｉｉｉ）前記関連タグと関連づけて、追加的なデータ・バンドルを形成する、
ｉ）前記追加的なデータ・バンドルを、前記信頼されるサーバーに提出し、また、前記データ・バンドルが、前記信頼されるサーバーで格納される前記第１のデータおよびタグと前記第２のデータに関して、前記格納された情報と合致するものとして検証される場合には、前記得られたデータを、前記データ・バンドルの関数と関連づけて、前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに受け渡す、
ように動作できるプログラムが前記信頼されるサーバーと前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに供給されるような信頼されるサーバー、
を備えることを特徴とするシステム。
【請求項２８】前記第１のデータは秘密データを含むことを特徴とする請求項２７記載のシステム。
【請求項２９】前記得られたデータは暗号鍵を含むことを特徴とする請求項２７記載のシステム。
【請求項３０】前記第１のデータは秘密データを含み、かつ、前記得られたデータは暗号鍵を含むことを特徴とする請求項２７記載の方法。
【請求項３１】リモートサーバーと関連づけられたソースデータから得るコンピュータ・オブジェクト・データを制御するシステムであって、
ａ）複数のクライアント・コンピュータ・マイクロプロセッサ・プラットフォームと、
ｂ）前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームと動作可能に結合されたデータ通信リンクと、
ｃ）前記データ通信リンクと動作可能に結合された信頼されるサーバーであって、
ｉ）一意のタグと関連づけられた第１のデータを特定する（前記第１のデータと、その関連タグは、前記リモートサーバーに知られている）、
ｉｉ）コンピュータ・オブジェクト・データを、得られたデータの一関数として計算された値に結び付け、そこでは、前記得られたデータが、前記第１のデータを表わすデータを含み、また、前記第１のデータおよびタグを反映させる情報を格納するように構成されている前記信頼されるサーバーで、前記結び付けを実施する、
ｉｉｉ）前記リモートサーバーでは、（ｉ）前記第１のデータを表わすデータを含む前記リモードサーバーの追加的データを、（ｉｉ）前記第関連タグと関連づけて、追加的なデータ・バンドルを形成する、
ｉｖ）前記追加的なデータ・バンドルを、前記信頼されるサーバーに提出し、また、前記データ・バンドルが、前記信頼されるサーバーで格納される前記第１のデータおよびタグに関して、前記格納された情報と合致するものとして検証される場合には、前記得られたデータを、前記データ・バンドルの関数と関連づけて、前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに受け渡す、
ように動作できるプログラムが前記信頼されるサーバーと前記クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに供給されるような信頼されるサーバー、
を備えることを特徴とするシステム。
【請求項３２】前記第１のデータは秘密データを含むことを特徴とする請求項３１記載のシステム。
【請求項３３】前記得られたデータは暗号鍵を含むことを特徴とする請求項３１記載のシステム。
【請求項３４】前記第１のデータは秘密データを含み、かつ、前記得られたデータは暗号鍵を含むことを特徴とする請求項３１記載のシステム。
【発明の詳細な説明】
【０００１】
（背景技術）
近年、貴重なコンテンツを含め、デジタル・コンテンツが知的財産を含むために、あるいは、機密にかかわる個人情報または金融情報を含むために、そのようなデジタル・コンテンツの保護は、コンシューマー側にあるハードウェアの利用をともなう必要があることが認識されてきた。このようなハードウェアは、エンドユーザの保護において重要な役割を果たせることも認識されており、その場合、このようなハードウェアは、さらに安全なアクセス認証を達成するために、スマートカード、および他のパーソナル・トークンの形式で展開されている。プロバイダに関しては、ソフトウェアのコピー保護という厳しく制限された目的の範囲内で、何らかの成功を収めたコンシューマー側にある単純なハードウェアの一例として、ドングルを指す場合がある。
【０００２】
しかしながら、このコンシューマー側にあるハードウェアは、インターネットによる効率的運用にはまったく影響を与えず、その場合、ネットワークしたデジタル媒体の領域では、そのような効率的運用の欠如が特に深刻である。革新的な流通経路としてインターネットを利用する際に、その機会を認識しているものもある。しかしながら、その課題は、そのような専用装置の設計、製造、大量販売の費用、並びに、消費者や様々な業界（例えば、消費者向け電子機器、コンテンツ配信、バンキング・サービス、インターネット・サービス）への前記装置の魅力であった。
【０００３】
このようなコンシューマー側にあるセキュリティ装置の費用を減らし、かつ、そのような装置の魅力を高める１つの可能性は、２つ以上のプロバイダへのアクセスをオープンにすることによる場合もあることが開示されている。実際、上記のハードウェアが、あらかじめプログラムされ、かつ狭い範囲で定められるやり方で、複数のプロバイダのために働くのではなく、代りに、そのコアに、オープン・プログラマビリティ（ｏｐｅｎ ｐｒｏｇｒａｍｍａｂｉｌｉｔｙ）を取り入れることで、非常に柔軟に遂行できる場合には、広範囲に及ぶコンシューマーの展開を妨げる障害物がかなり減らされることがある。普通なら、定められた目的の製品を実現するために必要であるはずの、まったく異なる企業実体間の困難な緊密結合を、オープン・ハードウェアがゆるめることができる。ライバルの同業者の調停の成功が動機となって、プロバイダとは無関係のメーカが、セキュリティ装置の広範囲にわたる促進を専門とすることが望ましいものとなる。
【０００４】
しかしながら、大部分または全部の従来技術の複数用途、プロバイダ独立型のセキュリティ・ハードウェアは、特にコンシューマーのプライバシやコプロセッサのフォールト・トレランスに対して、他のシステム設計の課題を導入する点で、共通の欠点を免れないものと考えられる。前述のセキュリティ・ハードウェアのアノニマス（匿名）サービスは、アクセストークン式システムを利用するが、ただし、複数用途の信頼される実行環境でのアノニミティ（匿名性）が、まさしく、今なお公開研究テーマとなっている。扱われたことのない重要な問題は、プロバイダの間で、特定のシステムの基盤情報を共有して、各コンシューマーの包括的なプロファイルを形成する場合があるという事実である。コンシューマーがトランザクションを望むあらゆるプロバイダには、コンシューマーのセキュリティ・モジュールの保証公開鍵を配布する。次に、悪辣きわまる小集団のプロバイダの間で、この保証公開鍵を共有して、コンシューマーの購入習慣の暴露的なプロファイルを作成する場合がある。このシステム設計のプライバシ保護の特徴は、必要であっても、その基礎をなす通信トランスポートがアノニミティの特徴をサポートしなければ、厳密なプライバシ要件を満たすのに充分であるとは言えないことに留意されたい。
【０００５】
さらに大きな注目に値するもう１つの問題は、充分な資源を有する敵対者により、エンドユーザのコプロセッサが危険にさらされる場合があるという事実である。上記のあらゆる目標をサポートする信頼基盤は、このようなシナリオにおいては、フォールト・トレランスの特色をなすであろう。単純な一例は、危険にさらされたコプロセッサの任意の数のクローンが、このシステムに侵入しないようにすることである。しかしながら、上に述べられる共同使用、高プライバシのシステムの関係により、構築の抑制（ａｒｃｈｉｔｅｃｔｉｎｇ ｃｏｎｔａｉｎｍｅｎｔ）や損害制限能力の問題がさらに難しくなる。
【０００６】
よって、プライバシの保護とコプロセッサのフォールト・トレランスを向上させる複数用途、プロバイダ独立型のセキュリティ・ハードウェアが今なお必要となっている。従来技術は、これらの要求を満たすとは考えられない。
【０００７】
（発明の開示）
本発明の目的は、クライアントと、少なくとも１つのリモートサーバーとの間のセキュア（安全な）関係を基本とするトランザクションに対して、信頼を高めることである。
【０００８】
本発明の他の目的は、複数のクライアントにより用いられるコンピュータ・オブジェクト・データの制御を行うことである。
【０００９】
本発明のさらに他の目的は、コプロセッサのフォールト・トレランスを高めることである。
【００１０】
以下に記述されるさらなる開示内容を参照すると明らかになる上記および他の目的を満たすために、本発明は、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、リモートサーバーとの間のトランザクションに対して信頼を高める方法、および、リモートサーバーと関連づけられたソースデータから得られたコンピュータ・オブジェクト・データであって、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントが利用できるオブジェクト・データの制御を行う方法を提供する。
【００１１】
本発明は、少なくとも１つの公開鍵データを受け入れるように構成された信頼されるサーバーを用いることで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、少なくとも１つのリモートサーバーとの間のトランザクションに対する信頼を高め、その場合、それぞれの公開鍵データは、このプラットフォーム用の公開鍵／秘密鍵の対の一部として、クライアント・プラットフォームと特に関連づけられる。このような公開鍵／秘密鍵の対は、このクライアント・プラットフォームと、この信頼されるサーバーのうちの少なくとも１つを用いて生成される場合がある。
【００１２】
追加的な承認データも、この公開鍵データと関連づけて、この公開鍵データを、それを受け入れる信頼されるサーバーにより承認されたものとして特定する。次に、信頼できる追加的な承認データを見分けるように構成されているリモートサーバーに、この公開鍵データと、その関連づけられた追加的な承認データを提供する。リモートサーバー固有のデータも、この承認された公開鍵データと関連づけ、また、その関連づけられたリモートサーバー固有のデータが、この公開鍵データと関連づけられたクライアント・プラットフォーム秘密鍵といっしょに使用される。その信頼されるサーバーとのクライアント・プラットフォームのやり取りを通じて、この信頼されるサーバーが、リモートサーバーからのサーバー固有のデータとともに、クライアント・プラットフォーム秘密鍵を、少なくとも１回、利用することに気づいて、この公開鍵データを、このリモートサーバーと関連づけることを受け入れるか、または拒絶し、かつ、保証を与えるか、または拒否する機会を、その信頼されるサーバーに与える。
【００１３】
本発明は、少なくとも１つの信頼されるサーバーを使用して、データを、リモートサーバーから、その信頼されるサーバーに転送することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、そのリモートサーバーとの間のトランザクションに対して信頼を高める。この転送されるデータは、少なくとも１つの秘密データを含む。このような転送は、データ転送セキュリティ対策とともに行われる。この転送されるデータの一部の関数は、その信頼されるサーバーからクライアント・プラットフォームに提供される。その場合、この転送されるデータの一部には、秘密データの少なくとも一部が含まれる。この信頼されるサーバーは、信頼できると見なされるクライアント・プラットフォームと関連づけられるものとして、この信頼されるサーバーにより識別できる少なくとも１つの鍵で暗号化されたその関数の１つの値を、クライアント・プラットフォームに提供する。このクライアント・プラットフォームは、この暗号化された関数値を復号化する機能を果たし、従って、この関数値は、リモートサーバーとクライアント・プラットフォームとの間で安全に共有される場合がある。
【００１４】
本発明はまた、コンピュータ・オブジェクト・データをクライアント・コンピュータ・マイクロプロセッサ・プラットフォームに、信頼されるように受け渡すことができるようにし、その場合、リモートサーバーは、受け渡されるオブジェクト・データが一関数（例えば、代数関数などの数学関数、ハッシュ、変換、恒等関数、または、オブジェクト・データをその引数として有する別の関数）であるソースデータを提供する。このような受渡しは、リモートサーバーに知られている秘密データを特定することで、達成される。この秘密データは、信頼されるサーバーに提供されて、一意のタグを用いて特定される。コンピュータ・オブジェクト・データは、その提出されたソースデータから得られ、その場合、このオブジェクト・データは、その信頼されるサーバーにより計算された署名と関連づけられ、またこの署名は、そのオブジェクト・データの一関数である。次に、このコンピュータ・オブジェクト・データは、クライアント・プラットフォームでの利用のために提供される。
【００１５】
本発明は、リモートサーバーと関連づけられたソースデータから得られるコンピュータ・オブジェクト・データを制御し、その場合、このオブジェクト・データは、一意のタグと関連づけられた第１のデータを特定することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントで利用できる。第１のデータと、その関連タグは、リモートサーバーに知られている。次に、第２のデータが、第１のデータおよびタグと関連づけられ、その場合、第２のデータは、第１のデータおよびタグと、第２のデータを反映させる情報を格納するように構成されている信頼されるサーバーから、提供される。次に、コンピュータ・オブジェクト・データは、得られたデータの一関数として計算された値に結び付けられ、そこでは、この得られたデータは、第１のデータを表わすデータと第２のデータを表わすデータのうち、少なくとも１つを含む。このような結び付けは、その信頼されるサーバーにより実施される。追加的なデータ・バンドルはまた、リモートサーバーでは、リモードサーバーの追加的データを、ｉ）第１のデータを表わすデータと第２のデータを表わすデータのうち、少なくとも１つ；ｉｉ）その関連タグと関連づけることにより、形成される。この追加的なデータ・バンドルは、検証のために、信頼されるサーバーに提出される。このデータ・バンドルが、その信頼されるサーバーで格納される第１のデータおよびタグと第２のデータに関して、その格納された情報と合致するものとして検証される場合には、得られたデータは、そのデータ・バンドルの関数と関連づけられて、クライアント・プラットフォームに受け渡す。
【００１６】
本発明の一実施形態では、第１のデータは、秘密データを含むことができるか、もしくは、秘密データである。さらに、この得られたデータは、暗号鍵を含むか、あるいは、暗号鍵であることもある。
【００１７】
この開示内容に織り込まれ、かつこの開示内容の一部を構成している添付図面は、本発明の好ましい実施形態を図解するものであって、本発明の原理を説明するのに役立つ。
【００１８】
（発明を実施するための最良の形態）
クライアント側のコンピュータ（例えば、様々なサーバーにリンクさせるインターネットなどの分散形データネットワークにアクセスするビジネスユーザまたは個人ユーザのパーソナルコンピュータ）などの常用されるコンピュータは、一般にコプロセッサを含んでいる。コプロセッサという用語の使用は、本明細書中では、コンシューマー／クライアントのレベルで使用されるコプロセッサを指すことに限定される。そのコプロセッサに対応するサーバークラスのデバイスは、ハードウェア・セキュリティ・モジュール（ＨＳＭ）という用語で示される。セキュア・コプロセッサは、Ｓ．Ｗ．Ｓｍｉｔｈ氏、Ｂ．Ｒ．Ｐａｌｍｅｒ氏、Ｓ．Ｈ．Ｗｅｉｎｇａｒｔ氏の「Ｕｓｉｎｇ ａ Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ， Ｐｒｏｇｒａｍｍａｂｌｅ Ｓｅｃｕｒｅ Ｃｏｐｒｏｃｅｓｓｏｒ（高性能なプログラマブル・セキュア・コプロセッサを利用して）」（第２回国際金融暗号化会議の会議報告書、Ｓｐｒｉｎｇｅｒ−Ｖｅｒｌａｇ ＬＮＣＳにより１９９８年発行）の中で開示されるように、いくつかのタイプに分類される場合がある。このセキュア・オープンシステムをサポートするものと考えられるコプロセッサは、これらの種類のいくつかと重複する。このようなコプロセッサを、ＨＳＭ、すなわちハイエンドのセキュア・コプロセッサのものと同じ領域内に置くようなオープン・プログラミング環境が好ましいことは明らかである。その一方、このコプロセッサは、多分、資源制約形のコンシューマー機器内で働く必要があるであろう。このような埋め込みフットプリントを有するコプロセッサは、暗号アクセラレータの種類に、より良く適合するように思われる。
【００１９】
次に、図１に関して、本発明の模範的なアプリケーションとトラスト・フレームワークを述べる。
【００２０】
このモデルにおいて、プロバイダが配信する代表的なサービスまたはアプリケーションには、次の３つのエンティティが含まれる。すなわち、「リモートサーバー」とも呼ばれる「アプリケーション・サーバー（ＡＳ）」１２０、コンシューマー側にある従来の保護されてないホスト装置１３０、および、コプロセッサの信頼される実行環境１１０である。このクライアント側の信頼される実行環境内で実行するソフトウェア・アプリケーション・コンポーネントは、セキュア・アプリケーション・コンポーネント（ＳＡＣ）１４０と呼ばれる。クライアント側の計算設備の全体は、「クライアント・コンピュータ・マイクロプロセッサ・プラットフォーム」または「クライアント・プラットフォーム」と呼ばれる。「コンピュータ・オブジェクト・データ」は、ＳＡＣ実行可能プログラムを含む場合がある。また「ソース・データ」は、ＳＡＣまたはＳＡＣ実行可能プログラムのソース（コード）を含む場合がある。
【００２１】
「信頼されるサーバー（ｔｒｕｓｔｅｄ ｓｅｒｖｅｒ）」とも呼ばれる「トラスト・サーバー（ｔｒｕｓｔ ｓｅｒｖｅｒ）」１５０は、プライバシか、抑制の目的のいずれかの緩和に対応する２つの退廃した事例を調査することが動機となって、もたらされた。
【００２２】
抑制（ｃｏｎｔａｉｎｍｅｎｔ）が必要でない場合には、コプロセッサが、いくつかのアノニマス・アクセス方式の任意のものと結合された形式的には見分けのつかないコプロセッサであることを請け負うだけで、充分にプライバシを保証できる。この結果は、その信頼される実行環境のフィーチャ・セットの影響を受けないことに留意されたい。コードは、機密に、かつ起点の認証と完全性チェックの双方を用いて、いかなる特定コプロセッサにも移送することができる。この要件は、実際、暗号鍵材料を、それらのコプロセッサにプレロードする必要がある場合に、それらのコプロセッサがすべて、同一データを得ることにすぎない。
【００２３】
逆に、抑制だけが求められる場合には、各コプロセッサ用の一意の保証公開鍵を利用して、プロバイダが課金を追跡し、見つけられるほど危険にさらされたハードウェアに対する信頼を撤回できるようにする場合がある。
【００２４】
抑制とプライバシの双方が要求されるときには、コンシューマーとプロバイダとの信頼関係の授与と撤回の仲介をするために、信頼される仲介物が必要である。よって、「トラスト・サーバー」１５０は、このような仲介物として使用される。コプロセッサ１７０を用いて、コンシューマーまたはクライアントのプライバシを最大限保護するために、コプロセッサ１７０とＳＡＣ１４０のインスタンスとの関連づけを知っているものが、「トラスト・サーバー」１５０に限定されなければならない。
【００２５】
前述の考察から、コプロセッサの個別化の必要性が明白である。ＳＡＣ１４０の個別化の要件は、プロバイダが、コプロセッサ１７０を横切って、その個々のインスタンスの経過を追う必要があることから、生まれたものである。ＳＡＣ１４０を個別化する２つの方法、すなわち、プロバイダの「アプリケーション・サーバー」１２０によるＳＡＣ個別化と、「トラスト・サーバー」１５０によるＳＡＣ個別化が使用される場合がある。
【００２６】
ＳＡＣ１４０のアンインストールと再インストールから成る１サイクル後に、ＳＡＣ１４０が、新しい個別化データを備えるべきかどうかという問題がある。一方では、同一データを発行することで、プロバイダは、怪しげな行動をしているＳＡＣ１４０のインスタンスを一方的に撤回して、おそらく、そのインスタンスがランするコプロセッサ１７０が危険にさらされていることを示すこともある。他方では、公正なコンシューマーが、プライバシのために要望するのであれば、これらのコンシューマーに、個別化のつながりを断ち切らせるべきである。それゆえ、インストールごとの新しい個別化は、初めてのものであろうと、繰返しのものであろうと、求められる。このことは、ＳＡＣ１４０に対して責任のあるプロバイダ１７０が、特定のコプロセッサ１７０上のＳＡＣ１４０を撤回するプロセスを変更する。プロバイダが、その要求を提出する「トラスト・サーバー」１５０は、この撤回プロセスを仲裁しなければならない。コンシューマーのプライバシを保護し、かつプロバイダのニーズを満たすという２つの相補的な責任は、「トラスト・サーバー」１５０にある。
【００２７】
下記の表は、本明細書に用いられている技術的表記法を要約している。
【００２８】
【表１】
【００２９】
コプロセッサ１７０と「トラスト・サーバー」１５０間を通過するいかなるデータも、認証と暗号化によって保護されなければならない。関係のあるコプロセッサ１７０のＩＤの証拠を隠すように、注意も払わなければならない。例えば、サイファテキストの上に添付署名のあるサイファテキストの公知構造は、この要件に違反することになる。なぜならば、コプロセッサ公開鍵の網羅的なリストを備えて、署名の検証を試みることもあるからである。本発明は、「Ｓｅｃｕｒｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（安全な通信）」の見出しのもとに、ＨＳＭ１６０向けにコプロセッサ１７０により暗号化されたいかなるデータも、「トラスト・サーバー」１５０のインサイダでは復号化できないように；ＨＳＭ１６０により、コプロセッサ１７０向けに暗号化されたいかなるデータも、「トラスト・サーバー」のインサイダでは復号化できないように；現時点で「トラスト・サーバー」１５０に保持されているデータにアクセスせずには、ＨＳＭ１６０から来たものとして、メッセージを、コプロセッサ１７０にうまくスプーフィングすることができないように；現時点で「トラスト・サーバー」１５０に保持されているデータにアクセスせずには、コプロセッサ１７０から来たものとして、メッセージを、ＨＳＭ１６０にうまくスプーフィングすることができないように、とりわけ求めている。「トラスト・サーバー」１５０のインサイダは、データがコプロセッサ１７０から来たかのように、そのデータをＨＳＭ１６０にうまくスプーフィングすることができないとは考えられない。同様に、「トラスト・サーバー」１５０のインサイダは、データがＨＳＭ１６０から来たかのように、そのデータをコプロセッサ１７０にうまくスプーフィングすることができないとは考えられない。
【００３０】
本発明は、少なくとも１つの公開鍵データを受け入れるように構成された信頼されるサーバー１５０を使用することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、少なくとも１つのリモートサーバーとの間のトランザクションに対して信頼を高める。その場合、各公開鍵データは、クライアント・プラットフォーム用の公開鍵／秘密鍵の対の一部として、このクライアント・プラットフォームと特に関連づけられる。この公開鍵／秘密鍵の対は、このクライアント・プラットフォームと、この信頼されるサーバー１５０のうち少なくとも１つを用いて、生成される場合がある。追加的な承認データも、この公開鍵データと関連づけて、この公開鍵データを、それを受け入れる信頼されるサーバー１５０により承認されたものとして特定する。次に、この公開鍵データと、その関連づけられた追加的な承認データをリモートサーバーに提供する。その場合、このリモートサーバーは、信頼できる追加的な承認データを見分けるように構成されている。
【００３１】
リモートサーバー固有のデータも、この承認された公開鍵データと関連づけ、また、その関連づけられたリモートサーバー固有のデータが、この公開鍵データと関連づけられたクライアント・プラットフォーム秘密鍵といっしょに使用される。その信頼されるサーバーとのクライアント・プラットフォームのやり取りを通じて、この信頼されるサーバーが、リモートサーバーからのサーバー固有のデータとともに、クライアント・プラットフォーム秘密鍵を、少なくとも１回、利用することに気づいて、この公開鍵データを、このリモートサーバーと関連づけることを受け入れるか、または拒絶し、かつ、保証を与えるか、または拒否する機会を、その信頼されるサーバーに与える。
【００３２】
前述の通り、ＳＡＣ１４０の個別化の要件は、プロバイダが、コプロセッサ１７０を横切って、その個々のインスタンスの経過を追う必要があることから、生まれたものである。ＳＡＣ１４０を個別化する２つの方法、すなわち、「アプリケーション・サーバー」１２０による方法と、「トラスト・サーバー」１５０による方法があることにも留意された。図２および図３を参照すると、「アプリケーション・サーバー」１２０によるＳＡＣ個別化の方法が示されている。
【００３３】
図２を参照すると、「アプリケーション・サーバー」（ＡＳ）１２０によるセキュア・アプリケーション・コンポーネント（ＳＡＣ）の暗号化プロセスを示すブロック図が与えられている。公開配布の前に、「アプリケーション・サーバー」（ＡＳ）１２０は、新規の識別子ＳＡＣ．ＩＤを、それぞれのＳＡＣ１４０に割り当てる。次に、ＳＡＣ１４０の暗号化に用いられる対称鍵ＳＡＣ．ｋｅｙを生成する。次に、対称的に暗号化されたＳＡＣは、配布のために公に利用できるようにする。
【００３４】
図３を参照すると、コプロセッサ１７０によるクーポン収集と、「アプリケーション・サーバー」１２０でのクーポンの引換えのプロセスを示すブロック図が示されている。アノニマス証明書すなわち「クーポン」に対応する秘密鍵（ｐｒｉｖＫｅｙ）は、成功するようには改ざんされなかったコプロセッサ１７０から漏洩しないコプロセッサ・レベルの秘密であるようになっている。その結果、「アプリケーション・サーバー」１２０は、疑わしいコプロセッサ１７０が、サービスまたはコンテンツを成功するように獲得する条件として、それらの正当性を証明するのに用いる手法を柔軟に決定できるようにするのではなく、コプロセッサ１７０との規定された対話を、それらの通信コードに織り込まなければならない。
【００３５】
悪辣きわまるアプリケーション・プロバイダは、普通なら、その「アプリケーション・サーバー」を構成し、Ｒａｂｉｎ復号化（すなわち、モジュラ平方根の計算）が、その係数（ｍｏｄｕｌｕｓ）の因数分解（ｆａｃｔｏｒｉｎｇ）と等価であることに基くもの、あるいは、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ関連のプロトコルに対する小サブグループの攻撃に基くもののように、オラクル（ｏｒａｃｌｅ）を利用しようとするはずである。このようなプロトコルの欠陥が検出されなくなるとすると、このような秘密鍵の遠隔収集が、潜在的に、広範囲に利用されることになろう。
【００３６】
（図３のステップ１１において）ＡＳ署名が適正に検証され、また、当初、「アプリケーション・サーバー」１２０が使用して、公開配布（図２のステップ３において）の前に、ＳＡＣ１４０を暗号化した鍵（ＳＡＣ．ｋｅｙ）が、その復号化されたメッセージからもたらされる場合を除き、ＳＡＣ１４０は、適合するコプロセッサ１７０にインストールできなくなることに留意されたい。ＡＳ．ＩＤは、コプロセッサ１７０により、「アプリケーション・サーバー」の公開鍵証明書から得られる。ＡＳ１２０が、「トラスト・サーバー」１５０でのクーポンの引換えの代りにコプロセッサ１７０が得る受領書に対して、有効性試験を無視することに決めたとしても、ＡＳ．ＩＤは、ＴＳ（「トラスト・サーバー」）１５０により書き留められており、したがって、（潜在的に課金の目的だけでなく）追跡の目的でも、この情報を記録することができる。このような受領書の証拠を、「アプリケーション・サーバー」１２０に提供しても、うまく改ざんされたコプロセッサ１７０に対応するクーポンが、「何回も使われる」ことになろう。適合するコプロセッサ１７０は、時間（または、他の計量）の或る指定限度値を超えた後で、ホームを呼び出さなかった場合に、重要な機能を失うようにプログラムされていることで、「トラスト・サーバー」１５０に縛られるが、うまく改ざんされたコプロセッサ１７０は、そのようなレポートバック（折返し報告）を避ける場合がある。これらのコプロセッサが、新規の鍵材料を得るために、折返し報告する必要がある場合には、例えば、これらのコプロセッサは、過去の活動ログについて、うまく嘘を言うことができる場合もある。「トラスト・サーバー」１５０が発行する受領書中の「ｂｌｏｂ」に依存すれば、改ざんされた装置でも、使用可能な受領書を蓄積することができなくなることに留意されたい。
【００３７】
ＨＳＭ１６０で実施される処理の最小単位（ａｔｏｍｉｃｉｔｙ）とともに、コプロセッサ１７０と「トラスト・サーバー」１５０との間の「安全な通信」の想定から、改ざんされた装置の内通なしに働く「トラスト・サーバー」１５０のインサイダは、それが、対応する秘密鍵を知っているクーポンを得ることができなくなる。この好ましい実施形態のこれらの２つの面は、公開鍵データが、「安全な通信」のもとに、信頼されるサーバー１５０により、クライアント・プラットフォームから受け取られる場合に、その信頼されるサーバー１５０が、その公開鍵データを受け入れるように構成されることが何を意味するか説明するのに役立つ。
【００３８】
この方法は、適合するコプロセッサ１７０と「アプリケーション・サーバー」１２０との間で共有される（ＳＡＣレベル）「ｂｌｏｂ」（すなわち、ＳＡＣ個別化データ）が、コプロセッサ１７０と「アプリケーション・サーバー」１２０との間のＳＡＣレベルの通信に、どのように使用されるべきか故意に指定しない。
【００３９】
このデータの潜在的な「乱用」は、任意の独立して管理されたＳＡＣ１４０のセキュリティには影響を及ぼさない。
【００４０】
コンシューマーのプライバシの視点から、改ざんされたコプロセッサ１７０は、保証ＡＳ公開鍵に対応するＡＳ秘密鍵を知っている「アプリケーション・サーバー」１２０とやり取りをしているというユーザの確信を揺るがすことはできない。例えば、「アプリケーション・サーバー」１２０による署名入り暗号化ステップが、データへの別の署名および暗号化＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞と取り替えられる場合には、以下の攻撃が開始されることもある。
【００４１】
改ざんされたコプロセッサ１７０は、トランザクションを完了させることなく（これらのクーポンが、ＴＳ１５０にて引換えが行われるものとしてマークされないようにするため）、クーポンを収集し、それらのクーポンを使用することもある。改ざんされたコプロセッサ１７０は、対応するＥｎｃ（＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞）と、その関連ｐｒｉｖＫｅｙの知識に基いて、おそらく、それぞれの＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞の知識を得ることができよう。Ｓｉｇｎ（＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞，ＡＳ．ｐｒｉｖＫｅｙ）は、コプロセッサ関連の入力には依存しないから、その改ざんされたコプロセッサ１７０は、ターゲットのｐｕｂＫｅｙ値のもとに暗号化された＜ｂｌｏｂ，ｂｌｏｂＴａｇ，ＳＡＣ．ｋｅｙ＞を再利用できることになる。敵対者は、プレーンテキストの実行可能プログラムにアクセスするであろうが、しかしながら、敵対者は、例えば、ＳＡＣ１４０のターゲット・コプロセッサのインスタンスによりランダムに生成されたデータ上の署名を予想するＳＡＣ１４０内のコードによって、裏をかかれることもある。敵対者が、これらのクーポンを「アプリケーション・サーバー」１２０に使用することを中止しかった場合には、ターゲット・コプロセッサ１７０は、潜在的に機密のいかなる情報も、敵対者に無意識に伝達しようとしなくなるであろう。これは、「トラスト・サーバー」１５０において、そのクーポンの再利用が検出されることになるからである。いかなる場合にも、このタイプの攻撃は、実際のプロトコル設計において妨げられる。なぜなら、この署名は、ｐｕｂＫｅｙの使用を通じて、コプロセッサ１７０に基いて様々であるような暗号を使っているからである。
【００４２】
情報の信頼性が、匿名扱いにするサーバーまたは他の信頼されるサーバー１５０、あるいは、代表して行動するものによって保証される場合には、プライバシの視点から、クライアント・プラットフォームのユーザは、証明書のステータスに関して、そのような情報をリモートサーバーに開示することを特定のトランザクションが正当とするかどうかの判定に関与べきである。このような保証手順は、（コンピュータで）偽造できないように設計できるから、そのような保証は、クライアント・プラットフォーム・ユーザにより、その信頼されるサーバー１５０に要請でき、また、その信頼されるサーバー１５０からの応答を、クライアント・プラットフォーム・ユーザも、リモートサーバーに受け渡すことができる。このリモートサーバーが、或る自己指定した時点（時間の関数、集計されたサービスへのアクセス、あるいは、他の計量（１つまたは複数）である場合もある）により、充分な保証指示を受け取らない場合には、リモートサーバーは、特定のクライアント・プラットフォーム・ユーザとの関係を断つことに決めることがある。このリモートサーバーは、信頼されるサーバーによってもたらされる保証に反映されるものと思っている適切な情報を、公開鍵データと関連づけたリモートサーバー固有のデータに含めることで、リモートサーバーが受ける任意の保証が新しいかどうか判定できる。この手順は、証明書の信頼性の保証だけでなく、公開鍵データに対応する秘密鍵を有するという証拠を示す追加的な利点（このように構成される場合）も持っている。したがって、信頼されるサーバー１５０は、秘密鍵の少なくとも１回の利用に気づく（「安全な通信」のもとに）。好ましい実施形態では、サーバー固有のデータ（すなわち、ｂｌｏｂ、ｂｌｏｂＴａｇ、ＳＡＣ．ｋｅｙ）は、復号化する秘密鍵を用いて、クライアント・プラットフォームにより復元される（図３のステップ１１において）。その場合、この復元されたデータの或る関数（すなわち、Ｈ（ｂｌｏｂ））が、リモートサーバーのＩＤ（ＳＡＣ．ＩＤとともに、ＡＳ．ＩＤ）を付けて、その信頼されるサーバー１５０に送られる。リモートサーバーではなく、クライアント・プラットフォーム・ユーザに、保証の要求を処理させることで、これは、課金モデルにおいて汎用性を高めることを可能にする。証明書の使用料をリモートサーバーに請求する場合には、普通なら、その信頼されるサーバーに、その証明書の使用を知らせないでおくために、保証の要求から身を引くはずである。いかなる時点においても、クライアント・プラットフォームの関係を、ただ１つの信頼されるサーバーに限定することで、これは、さらに有意義に、証明書の使用を追跡できるようにしている。満了日を証明書に織り込むことが知られているが、これは、証明書が、どの程度まで信頼されてきたか、また、この証明書が、信頼できると考えられるべきかどうかは、示していない。証明書撤回リスト（ＣＲＬ）を利用しても、リモートサーバーの潜在的な問題は、満足のいくようには処理されていない。最新バージョンの保証された受渡しやスケーラビリティのように、ＣＲＬと関連づけられた通常の問題に加えて、クライアント・プラットフォームのユーザ・プライバシを織り込むことも、ＣＲＬの効力を徐々に弱める場合がある。
【００４３】
本発明は、以下のように、異なる撤回手法を考慮に入れている。すなわち、証明書ＩＤのリストを指定するリモートサーバーの事前要請を受けて、特定のクライアント・プラットフォームが、疑わしい証明書ＩＤの１つと関連づけられているものとして、その信頼されるサーバーでマークされる場合には、該当するリモートサーバーに対して、リモートサーバー固有のデータと関連づけられた保証用の将来のクライアント・プラットフォーム・ユーザの要求が否定されることがある。リモートサーバーで起こされたこれらの要求が、適正に認証される場合には、リモートサーバーは、他のリモートサーバーに対する保証プロセスには影響を及ぼさない。この技法は、クライアント・プラットフォーム・ユーザの側において、うわべは詐欺的な活動を見つけるために、リモートサーバーが、信頼されるサーバー１５０よりも優れた立場にあることがあるような電子商取引のインスタンスが存在するという事実に基いていることに留意されたい。なぜなら、この信頼されるサーバー１５０は、コンテンツまたはサービスにアクセスするのに、ロギングや課金などの実際の電子商取引のトランザクションに立ち会わないからである。さらに、このようなトランザクションは、それらの信頼されるサーバーから隠される場合がある。なぜなら、これらのトランザクションは、本発明により可能となるように、クライアント・プラットフォームとリモートサーバーとの間で共有される秘密データに基いて保護される場合があるからである。リモートサーバーは、ユーザ・プライバシが実施される場合に、２つの証明書ＩＤが、同一のクライアント・プラットフォームに一致するかどうか、それ自体では、認識できない。信頼されるサーバー１５０とは違って、リモートサーバーは、そのリモートサーバーの制御下にあるクライアント・プラットフォームでランしているアプリケーションの挙動に影響を及ぼすことがあっても、クライアント・プラットフォームの挙動に直接に影響を及ぼすことができない場合もある。
【００４４】
ＳＡＣ１４０を個別化する別の方法は、「トラスト・サーバー」１５０によるものである。図４〜図７を参照すると、「アプリケーション・サーバー」１２０によるＳＡＣ個別化の方法が示されている。
【００４５】
この方法では、重要な抑制目標が達成される。すなわち、「トラスト・サーバー」のインサイダと、うまく改ざんされたコプロセッサとの組合せからでも、「追加的な」事前格納されたＳＡＣ個別化データの知識は安全である。さらに正確に言えば、危険にさらされる唯一のＳＡＣ個別化データは、危険にされされている（あるいは、危険にされされるであろう）コプロセッサ１７０、または、それらのコプロセッサのクローンに供されるものである。この方法では、ＳＡＣ個別化データは、一括して「トラスト・サーバー」１５０に受け渡されて、ＳＡＣのインストールおよび個別化の間、コプロセッサ１７０に分け与える目的で蓄積される。この手順は、一度に一つのキャンディ・タブレットを分け与える（それぞれ、一回出されて、消費される）前に、ＰＥＺ（登録商標）キャンディ自動販売機にキャンディを満たすことに、いくらか類似している。コプロセッサ１７０に分け与えられるそれぞれの個別化データのパケットは、「トラスト・サーバー」１５０による追跡目的で、また、「アプリケーション・サーバー」１２０がやり取りする任意の特定のコプロセッサ１７０により、どのｂｌｏｂ値が意図的に保持されているか「アプリケーション・サーバー」１２０に特定させるために、使用できるｂｌｏｂＴａｇだけでなく、データのｂｌｏｂも含む場合がある。コプロセッサの安全な環境内で、ＳＡＣ１４０でアクセスされる適切なｂｌｏｂ値を知ることを条件として、コンテンツまたはサービスを、クライアント・プラットフォームにうまく受け渡す場合がある。所与のＳＡＣ．ｎｕｍｂｅｒに対応するＳＡＣ１４０のすべてのバージョンまたはアップグレードは、一括個別化データの同一（補充可能な）プールを取り除くように設計されているから、「アプリケーション・サーバー」１２０からの一括受渡しの間、「トラスト・サーバー」１５０による処理と格納の間、および、コプロセッサ１７０にパーミッションが付与されているＳＡＣインスタンスの個別化の間、このデータを攻撃から保護するだけでは充分でない（ただし、必要である）。所望のセキュリティ・レベルを達成するために、ＳＡＣパブリッシング・プロセスも保護しなければならない。この当面の目標に対応する問題は、ＳＡＣ１４０のパブリッシングを要求する「アプリケーション・サーバー」１２０（すなわち、プロバイダ）の信頼性を保証するものではなく、もっと適切に言えば、ＳＡＣシリーズが初期設定されると、正当な「アプリケーション・サーバー」１２０が、手におえぬＳＡＣをパブリッシングさせる能力があろうと、なかろうと、侵入者を拒絶する戦略が所定の場所に置かれていることを保証するものである。手におえぬＳＡＣは、ターゲットの「アプリケーション・サーバー」の個別化データを乱用するか、あるいは、そのデータを暴露することで、そのデータを悪用することもある。
【００４６】
さきに取り上げられた第１の方法は、「トラスト・サーバー」１５０の外部で、ＳＡＣのパブリッシングと署名の双方を扱ったことを想起しよう。ＳＡＣシリーズの一括個別化とＳＡＣパーミッション付与は、現行方法の場合のように扱われるが、ただし、「アプリケーション・サーバー」１２０（ＡＳ）は、それ自体のＳＡＣ１４０の署名と、それ自体のパブリッシングを行うと仮定しよう。その場合、ＡＳ１２０は、ＳＡＣ．ｋｅｙのそれ自体の値を生成し、かつ、ＳＡＣシリーズの初期設定のために、ＳＡＣ．ｎｕｍｂｅｒ、Ｅｎｃ（＜ＡＳ．ｔｒａｃｋ，ＳＡＣ．ｋｅｙ，ＳＡＣ．ｎｕｍｂｅｒ＞，ＴＳ．ｐｕｂＫｅｙ）を、「トラスト・サーバー」１５０に送ることになる。次に、単一のコプロセッサ１７０が危険にさらされると、敵対者は、ＳＡＣ．ｎｕｍｂｅｒの、ターゲットＡＳと同一値と、ＳＡＣ．ｋｅｙの同一（危険にされされた）値を用いて、手におえぬＳＡＣをパブリッシングすることができる。敵対者は、ＳＡＣシリーズの初期設定ベクトルを提出する必要がないから、この攻撃は、ＴＳインサイダの共謀を必要としないであろう。敵対者の目標は、それ自体の一括個別化データを提出することではなく、ターゲットをハイジャックすることである。
【００４７】
次に、記録されたプロトコルがすべて使用されるが、ただし、ＡＳが、ＴＳ ＨＳＭ１６０によりランダムに生成されるのではなく、ＡＳに、ＳＡＣ．ｋｅｙのそれ自体の値を選ばせることを考えてみよう。次に、ＳＡＣ．ｋｅｙのターゲットの値をもたらすコプロセッサ１７０の攻撃が、ＴＳインサイダの攻撃と組み合わされることもあり、そこでは、敵対者は、ＳＡＣ．ｎｕｍｂｅｒの同一値の強制やり直しを用いて、ＳＡＣ．ｋｅｙの、そのターゲットが選んだものと同じ値を選ぶ。敵対者は、ＳＡＣ．ｎｕｍｂｅｒのこの値を用いて、標準のＳＡＣシリーズの初期設定ステップを実施し、それにより、敵対者は、そのターゲットの個別化データをうまくインストールでき、かつその個別化データにアクセスできる手におえぬＳＡＣをパブリッシングさせることができる。これは、敵対者が、ＳＡＣ．ｎｕｍｂｅｒおよびＳＡＣ．ｋｅｙの同一値を共有するからである。それゆえに、ＡＳ１２０に、ＳＡＣ．ｋｅｙのそれ自体の値を選択させれば、インサイダが、選択された値の暗号に代えることができないように、ＳＡＣ．ａｓｓｉｇｎにＴＳ．ｌｏｃａｌを含めることで（図４に指定される通り）提供された保護がうまく避けられる。
【００４８】
実際の現行方法が、コププロセッサの危険のさらしと、ＴＳのインサイダというニ方面からの攻撃に対して、その抵抗を達成するために、このプロトコル設計の重要な面は、ＡＳ．ｋｅｙが、一般に、コプロセッサ１７０には絶対に提供されず、したがって、このようなやり方で、危険にはさらされないことである。ターゲットのＡＳ．ｋｅｙを知らずには、敵対者は、「最後に」パブリッシングするのに必要な不足引数（ｍｉｓｓｉｎｇ ａｒｇｕｍｅｎｔ）を提供できない（すなわち、検証可能な署名を提供できない）。その署名と、コプロセッサ１７０へのＳＡＣ個別化データの提示との間に、だますことのできない（ｕｎｓｐｏｏｆａｂｌｅ）結び付けがあることも重要である。デジタル署名は、その署名の引数を結び付ける手段を与えることは、従来技術において知られており、その場合、この署名を付けるメッセージは、そのような引数をいくつか含むと解釈できる。したがって、帰納的に推論すると、データを、既存の署名に結び付ける１つの方法は、その署名の追加的な引数として、そのデータの関数を入力することである。
【００４９】
本発明は、少なくとも１つの信頼されるサーバーを利用して、データを、リモートサーバーから、その信頼されるサーバーに転送することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いるクライアントと、そのリモートサーバーとの間のトランザクションに対して信頼を高める。この転送されるデータは、少なくとも１つの秘密データを含む。このような転送は、データ転送セキュリティ対策とともに行われる。この転送されるデータの一部の関数は、その信頼されるサーバーからクライアント・プラットフォームに提供される。その場合、この転送されるデータの一部には、秘密データの少なくとも一部が含まれる。この信頼されるサーバーは、信頼できると見なされるクライアント・プラットフォームと関連づけられるものとして、この信頼されるサーバーにより識別できる少なくとも１つの鍵で暗号化されたその関数の１つの値を、クライアント・プラットフォームに提供する。そのクライアント・プラットフォームは、この暗号化された関数値を復号化する機能を果たし、従って、この関数値は、リモートサーバーとクライアント・プラットフォームとの間で安全に共有される場合がある。
【００５０】
図６のステップ４のメッセージに示されるように、ＡＳ．ｔｒａｃｋを一括個別化データ移動と関連づけることは、ＳＡＣ．ｋｅｙのどの暗号鍵の値を、ＳＡＣ個別化の値（ｂｌｏｂＴａｇ，ｂｌｏｂ）（それぞれ、図７のステップ５のメッセージで、コプロセッサ１７０に受け渡される）に付加すべきか明瞭に示すのに役立つ。当初、図４のステップ９で計算されるように、所与のＳＡＣシリーズの初期設定の間に、ＳＡＣ．ａｓｓｉｇｎへのＴＳ ＨＳＭ１６０によるアクセスに基いて、図６のステップ５、ステップ６、ステップ７において、一括個別化の一部として、ＳＡＣ個別化の値に、ＳＡＣ．ｋｅｙの値を対応づける。ＡＳ．ｔｒａｃｋの秘密を維持することにより、敵対者は、ＳＡＣシリーズの初期設定の間、敵対者が知っているＡＳ．ｋｅｙの値とともに、再利用されるＳＡＣ．ｎｕｍｂｅｒとして、この値を再提出するために、この値の知識を用いないようにしていることに留意されたい。このような策略がもし成功する場合には、この策略により、敵対者は、ＳＡＣ個別化データを、ＳＡＣの手におえぬものにコース変更することができよう。手におえぬＳＡＣで用いられるデータを、このようにコース変更させないようにする目的では、一括個別化の間に、ＡＳ．ｔｒａｃｋの秘密値（例えば、Ｈ（ＡＳ．ｔｒａｃｋ））を明瞭に表わす（ただし、その秘密値を漏らさない）秘密でない値を使用するだけで、実際に充分であろう。これは、ＳＡＣシリーズの初期設定の間、ＡＳ．ｋｅｙの公知の値とともに、ＡＳ．ｔｒａｃｋを提出するために、ＡＳ．ｔｒａｃｋの値を知ることが必要であるからである。
【００５１】
安全にコプロセッサ１７０に配布するために、個別化データを、適正なＳＡＣ．ｋｅｙに確実にリンクする方法を、このようにして設計した後で、また、ＡＳ．ｋｅｙのターゲットの秘密値のもとに、手におえぬＳＡＣを、利用可能にうまくパブリッシングすることを阻止する方法を設計した後では、これから、ＳＡＣパブリッシングの間に、「トラスト・サーバー」１５０が生成する署名に、ＳＡＣ．ｋｅｙを確実に結び付ける手段を提供しなければならない。このような目的では、ＳＡＣ．ｎｕｍｂｅｒまたはＳＡＣ．ＩＤを用いることだけでは充分でない。これは、充分な状態メモリを持たないＴＳ ＨＳＭ１６０が、これらの値の詐欺的な再利用を追跡できない場合があり、かつ、これらの値が、毎回ランダムに生成されるようになってないからである。現行設計に取り入れられた手法は、この署名の引数として、Ｈ（ＳＡＣ．ｋｅｙ）を入力することである。コプロセッサ１７０の安全な実行環境内で、ＳＡＣ．ｋｅｙのこの値を使用して、この署名検証プロセスへの入力として、ＳＡＣ１４０のサイファテキスト形式を復号化する。この設計は、この署名内に、ＳＡＣ１４０のプレーンテキスト（すなわち、ＳＡＣ．ｋｅｙ独立型）のものを使用して、「アプリケーション・サーバー」１２０により、この署名のコプロセッサ独立型の検証を可能にして、「アプリケーション・サーバー」１２０が、ＡＳ．ｋｅｙの知識に基いて、署名検証の間に計算する署名の不足引数を公に利用できるようにすべきかどうか判定を行う。Ｈ（ＳＡＣ．ｋｅｙ）の明示的な（ただし、秘密ではない）使用から、このような結び付けを行うのに必要な連係が提供される。
【００５２】
ＳＡＣパブリッシングの間に、署名を生成する原子的な（ａｔｏｍｉｃ）処理により、特に、インサイダは、その署名の暗号化されない引数Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞）の計算に用いられる異なる（手におえぬ）ＳＡＣと並置された、ＳｙｍＥｎｃ（Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞），ＡＳ．ｋｅｙ）が知られている、以前にパブリッシングされた（正当な）ＳＡＣ１４０に代えることができない。
【００５３】
（ＳＡＣ．ｋｅｙベースの技法とは違って）機密性のためにＳＡＣ暗号化の影響を受けない、ＳＡＣ個別化データの処理を保護する代替手段は、以下のように進むこともある：図５（ＳＡＣパブリッシング）のステップ１２の間に送られるメッセージ中の署名の引数として現れるＨ（ＳＡＣ．ｋｅｙ）を、Ｈ（ＡＳ．ｔｒａｃｋ）に代える。Ｈ（ＡＳ．ｔｒａｃｋ）は、その署名とともに、「アプリケーション・サーバー」１２０に送られる必要はない。これは、ＳＡＣ．ｋｅｙ（図４のステップ８において、「トラスト・サーバー」により生成される）と違って、ＡＳ．ｔｒａｃｋの適切な値が、図４（ＳＡＣシリーズの初期設定）のステップ５においてＡＳ．ｔｒａｃｋを生成した「アプリケーション・サーバー」１２０により知られると想定されるからである。未使用の形式のＳＡＣ．ｋｅｙは、コプロセッサで使用するために、図７（ＳＡＣパーミッション付与）のステップ５において、クライアント・プラットフォームに送られるが、コプロセッサが危険にさらされると、ＡＳ．ｔｒａｃｋの値が得られなくなるであろうから、ＡＳ．ｔｒａｃｋ自体ではなく、Ｈ（ＡＳ．ｔｒａｃｋ）などのＡＳ．ｔｒａｃｋを示す秘密でない値を、ステップ５に類似するステップの間、コプロセッサ１７０に伝達することが重要である。ＳＡＣ．ｋｅｙは、ＳｙｍＥｎｃ（ＳＡＣ．ｅｘｅ，ＳＡＣ．ｋｅｙ）を復号化するためにＳＡＣ．ｋｅｙの値を必要とするコプロセッサ１７０に、Ｈ（ＡＳ．ｔｒａｃｋ）とともに送られる場合があることに留意されたい。なぜなら、これは、ＳＡＣ実行可能プログラムを受け取る形式であるからである。
【００５４】
ＳＡＣパーミッション付与の間、アップグレードのコプロセッサ１７０によるインストールと、ＳＡＣ１４０の新規インストール（これは、ＳＡＣ．ｎｕｍｂｅｒに対応するような、現時点でインストールされたＳＡＣ１４０がまったくないことを特徴としている）は、新規個別化データの吸収を拒否することに留意されたい。この属性により、そのシステムは、なんらかの方法で個別化データに結び付けられたか、あるいは個別化データにより保護されたデジタル権データが、アップグレードを横切って維持できる点で、ＤＲＭ（デジタル権管理）フレンドリとなる。
【００５５】
この方法は、レガシー・プロバイダ基盤の問題を扱い、それにより、「アプリケーション・サーバー」１２０は、すでに存在するクライアント側の装置のユーザとともに、複数用途のコプロセッサのユーザとやり取りすることができる。第１の方法において必要であったように、「アプリケーション・サーバー」１２０とコプロセッサ１７０との間で共有される秘密に切り替えるのに、予備段階はまったく必要でない。さらに、「アプリケーション・サーバー」１２０が、一度もコプロセッサ１７０とやり取りしなくても、所与のＳＡＣ１４０または互いに信頼されるＳＡＣのインスタンスは、ＳＡＣレベルの暗号化および／または認証を用いて、「ピア・ツー・ピア」通信を行うことができる。これは、ｂｌｏｂ内の秘密鍵に対応する公開鍵を備えた証明書をｂｌｏｂＴａｇに含ませることで、達成できる。
【００５６】
ここでは、さらに調査はされないが、潜在的な混成手法があり、この手法は、（第１の方法の場合のように）、「トラスト・サーバー」１５０と「アプリケーション・サーバー」１２０との間で、ＳＡＣ個別化データ値を調整する必要はないが、ただし、（第２の方法の場合のように）、ＳＡＣパブリッシングと、「トラスト・サーバー」１５０を通じてのＳＡＣのインストールを扱う。
【００５７】
「トラスト・サーバー」１５０が、実行可能プログラム／ソースコードの起点の認証を実施するという範囲で、コンシューマーのプライバシは、「トラスト・サーバー」１５０の外部の詐欺師が、ターゲットされた「アプリケーション・サーバー」のＩＤのもとに、ＳＡＣ１４０をパブリッシングさせるような攻撃から保護される。オプションのＳＡＣパブリッシング許可手順に従う場合には、適合性についてソースコード自体の検査だけでなく、ＳＡＳソースコードの起点をサポートするバンド外の記録の追加的な再調査もあることがある。ＳＡＣパブリッシング許可プロセスの必要がない場合には、この起点の認証を、直接に、ＨＳＭ１６０に持ち込むことができる。もちろん、ＨＳＭ１６０が、デジタル署名入りコードを、保証署名鍵と対照して検証しても、認証局（ＣＡ）を利用して、証明書の発行前にＩＤを認証する登録プロセスも、潜在的に攻撃を受ける。
【００５８】
気づかれないように、「トラスト・サーバー」１５０の内部のＳＡＣ個別化データを、公知の値に代えることは、潜在的には、プロバイダの抑制目標に対する攻撃ではなく、コンシューマーのプライバシに対する攻撃である。危険にさらされたコプロセッサと「トラスト・サーバー」のインサイダの攻撃との共謀の結果、ＳＡＣパーミッション付与の間に、ターゲット・コプロセッサ１７０への＜ｂｌｏｂＴａｇ，ｂｌｏｂ＞の値の分け与えを不正に繰り返すことで、このような取替えが発生しかねない。この場合、これらの値は、危険にさらされたコプロセッサから得られた値と一致する。コプロセッサ１７０と「トラスト・サーバー」１５０との間の「安全な通信」での仮定のために、また、暗号化された一括個別化データの入力が、ＳＡＣシリーズを初期設定したエンティティによる許可（ＡＳ．ｔｒａｃｋの安定した入力を介して）を必要とするために、ＴＳのインサイダの攻撃、あるいはコプロセッサが危険にさらされることだけでは、このような攻撃は可能とはならない。
【００５９】
このプロセスの好ましい実施形態は、図６と図７に示されている。データのどの部分が、クライアント・プラットフォームの属性のどの集まりを含むと見なされるかに関して、移動を、リモートサーバーと、信頼されるサーバー１５０との間の調整と関連づけられる場合があり、したがって、これらの関数値が、適宜に、クライアント・プラットフォームに提供される場合がある。
【００６０】
好ましい実施形態は、信頼されるように、コンピュータ・オブジェクト・データを、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームに受け渡すことができるようにし、その場合、リモートサーバーは、その受け渡されたオブジェクト・データが関数であるソースデータを供給する。このような受渡しは、リモートサーバーに知られている秘密のデータを特定することで、達成される。この秘密のデータは、信頼されるサーバーに提供されて、一意のタグを用いて特定される。このコンピュータ・オブジェクト・データは、その提出されたソースデータから得られる。その場合、このオブジェクト・データは、その信頼されるサーバーによって計算された署名と関連づけられ、また、その署名は、そのオブジェクト・データの関数である。次に、このコンピュータ・オブジェクト・データは、クライアント・プラットフォームで使用するために提供される。
【００６１】
好ましい実施形態では、この秘密のデータは、ＡＳ．ｋｅｙをさす。ＡＳ．ｋｅｙは、図４に示されるように、ＳＡＣシリーズの初期設定の間、信頼されるサーバーに提供されて、一意のタグＳＡＣ．ｎｕｍｂｅｒを用いて特定される。ＳＡＣのソースコードまたはＳＡＣ実行可能プログラムを含むソースデータは、ＳＡＣ．ｖｅｒｓｉｏｎだけでなく、ＳＡＣ．ｎｕｍｂｅｒも指定したＳＡＣ．ＩＤと関連させて、信頼されるサーバー１５０に提出される。図５（ＳＡＣパブリッシング）は、このようなデータの転送を示している。クライアント・プラットフォームでの使用のために提供される情報は、ＳＡＣ実行可能プログラムＳＡＣ．ｅｘｅの形式でコンピュータ・オブジェクト・データを含み、また、このようなコンピュータ・オブジェクト・データは、暗号化形式ＳｙｍＥｎｃ（ＳＡＣ．ｅｘｅ，ＳＡＣ．ｋｅｙ）で公に利用できるようになっている。この関連署名、すなわち、Ｓｉｇｎ（＜ＡＳ．ＩＤ，Ｈ（ＳＡＣ．ｋｅｙ），ＳｙｍＥｎｃ（Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞），ＡＳ．ｋｅｙ），Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞）＞，ＴＳ．ｐｒｉｖＫｅｙ）は、署名引数Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞）を介して、このオブジェクト・データの関数ｆ１である。一実施形態では、このオブジェクト・データの関数ｆ２は、ＳｙｍＥｎｃ（Ｈ（＜ＳＡＣ．ＩＤ，ＳＡＣ．ｅｘｅ＞），ＡＳ．ｋｅｙ）をさす。別法として、ｆ２（ｄａｔａ）＝ＳｙｍＥｎｃ（ｄａｔａ）とｆ３（ｄａｔａ）＝ｄａｔａが使用される場合がある。他の実施形態では、ｆ２（ｄａｔａ）＝ｄａｔａと、ｆ３（ｄａｔａ）＝ＳｙｍＥｎｃ（ｄａｔａ）が使用される場合がある。
【００６２】
本発明は、リモートサーバーと関連づけられたソースデータから得られるコンピュータ・オブジェクト・データを制御し、その場合、このオブジェクト・データは、一意のタグと関連づけられた第１のデータを特定することで、クライアント・コンピュータ・マイクロプロセッサ・プラットフォームを用いる複数のクライアントで利用できる。第１のデータと、その関連タグは、リモートサーバーに知られている。次に、第２のデータが、第１のデータおよびタグと関連づけられ、その場合、第２のデータは、第１のデータおよびタグと、第２のデータを反映させる情報を格納するように構成されている信頼されるサーバーから、提供される。次に、コンピュータ・オブジェクト・データは、得られたデータの一関数として計算された値に結び付けられ、そこでは、この得られたデータは、第１のデータを表わすデータと第２のデータを表わすデータのうち、少なくとも１つを含む。このような結び付けは、その信頼されるサーバーにより実施される。追加的なデータ・バンドルはまた、リモートサーバーでは、リモートサーバーの追加的データを、ｉ）第１のデータを表わすデータと第２のデータを表わすデータのうち、少なくとも１つ；ｉｉ）その関連タグと関連づけることにより、形成される。この追加的なデータ・バンドルは、検証のために、信頼されるサーバーに提出される。このデータ・バンドルが、その信頼されるサーバーで格納される第１のデータおよびタグと第２のデータに関して、その格納された情報と合致するものとして検証される場合には、得られたデータは、そのデータ・バンドルの関数と関連づけられて、クライアント・プラットフォームに受け渡す。
【００６３】
好ましい実施形態では、第１のデータは、ＡＳ．ｔｒａｃｋを含み、また一意のタグは、ＳＡＣ．ｎｕｍｂｅｒを含む。第２のデータは、ＳＡＣ．ｋｅｙを含む。ＳＡＣ．ｎｕｍｂｅｒ、ＡＳ．ｔｒａｃｋ、ＳＡＣ．ｋｅｙを含む情報は、ＳＡＣ．ａｓｓｉｇｎとして、信頼されるサーバーにて格納される（図４）。この得られたデータはＳＡＣ．ｋｅｙを含み、その関数はＨ（・）であり、また、この結び付けは、デジタル署名により行われて、図５のステップ１１の署名が得られる。追加的なデータ・バンドルは、図６のステップ４に示されている。ＳＡＣ．ｎｕｍｂｅｒでインデックスされるＳＡＣ．ａｓｓｉｇｎに対して、その提出されたデータ・バンドルが一致しているかの検証が、図６のステップ５で行われる。ＳＡＣ．ｋｅｙを、データ・バンドルの関数と関連づけて、（後で）クライアント・プラットフォームに受け渡す作業が、図６のステップ６とステップ７に示されている。
【００６４】
本発明の一実施形態では、第１のデータは秘密データを含む。さらに、この得られたデータは、暗号鍵も含む。
【００６５】
本発明の他の実施形態では、第１のデータはＡＳ．ｔｒａｃｋを含み、また一意のタグはＳＡＣ．ｎｕｍｂｅｒを含む。ＳＡＣ．ｎｕｍｂｅｒとＡＳ．ｔｒａｃｋを含む情報は、図４のＳＡＣ．ａｓｓｉｇｎの格納と同様に、信頼されるサーバーに格納される。この得られたデータはＨ（ＡＳ．ｔｒａｃｋ）を含み、その関数は恒等関数であると考えられる場合があり、また、その結び付けは、デジタル署名により行われる。このデータ・バンドルの関数は、Ｈ（ＡＳ．ｔｒａｃｋ）と関連づけられる。
【００６６】
このシステムに参加するコンシューマーのプライバシの権益を保護しながら、コンテンツ・プロバイダやサービス・プロバイダの業務への損害の抑制を達成するという同一目標に合わされた２つの異なるアーキテクチャが導入されている。これらの相反する要件は、プログラマブル・セキュリティ・コプロセッサをコンシューマー端末とトラスト・サーバーに導入して、その端末とサーバーが、これらの装置に直接にアクセスし、そこで、ユーザのプライバシをなお維持しながら、プロバイダのアプリケーションのパーミッションを、それらの装置に付与することができることから、最適な調停が得られる。
【００６７】
ユーザは、それ以外の人が少しずつ収集できるが、しばしば該当するコンシューマーには相応の利益がもたらさないような貴重な情報の量を制限するために、インターネット上で行われる活動に対して、それらのユーザの人物（ｐｅｒｓｏｎａ）を変更する正当な権利を有する。個々のプロバイダが、それらのプロバイダに知られているカスタマとの関係を扱えることがあるのと類似するやり方で、トラスト・サーバーは、このようなサービスの適合しない使用の疑いがかけられているユーザに、さらなるサービスのパーミッションを付与することを拒絶できる。入念なプロトコル設計と、カスタマとサーバー端末の双方におけるハードウェア・セキュリティ資源のきちんと調整された使用により、インサイダの攻撃に対しても、コンシューマーの詐欺行為に対しても、かなりの防衛度が達成できる。２つの方法のうちの第１の方法は、このプロセスとのトラスト・サーバーのかかわりあいを最小限利用する傾向がある強力なＰＫＩ（公開鍵基盤）の特質をその特徴としている。第２の手法は、レガシー基盤を扱うことができるが、ただし、この手法は、ピア・ツー・ピアＰＫＩも、コプロセッサとアプリケーション・サーバー共有の秘密を基本とする暗号もサポートできる鍵材料を用いて、コプロセッサを個別化できるような混成手法にも当てはまる。
【００６８】
以上の説明は、本発明の模範的な実施形態を参照して、本発明の原理を単に例示しているにすぎない。これらの記述される実施形態の様々な変更例や変形例は、本明細書中の教えから見て、当業者には明らかとなろう。したがって、当業者であれば、本明細書中に明示的に図示され、記述されてなくても、本発明の原理を実施し、ゆえに、本発明の精神および範囲内にある多数の技法を案出できるものと理解されよう。
【図面の簡単な説明】
【図１】
本発明と、本発明のトラスト・フレームワークの概略を示す例解図
【図２】
アプリケーション・サーバー（ＡＳ）によるセキュア・アプリケーション・コンポーネント（ＳＡＣ）の暗号化プロセスを示すブロック図
【図３】
クライアント・プラットフォーム上のコンプロセッサ（Ｃｐ）によるＳＡＣ個別化プロセスのクーポン収集およびクーポン償還を示すブロック図
【図４】
アプリケーション・サーバーおよびトラスト・サーバー（ＴＳ）によるＳＡＣ個別化プロセスにおいて、ＳＡＣシリーズの初期設定を示すブロック図
【図５】
アプリケーション・サーバーおよびトラスト・サーバーによるＳＡＣ個別化プロセスにおいて、ＳＡＣ公表プロセスを示すブロック図
【図６】
アプリケーション・サーバーおよびトラスト・サーバーによるＳＡＣシリーズのバルク個別化を示すブロック図
【図７】
コプロセッサ内へのＳＡＣパーミッションの付与を示すブロック図
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US24208300P | 2000-10-20 | 2000-10-20 | |
| US24684300P | 2000-11-08 | 2000-11-08 | |
| PCT/US2001/046238 WO2002039222A2 (en) | 2000-10-20 | 2001-10-19 | System and method for managing trust between clients and servers |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004513585A JP2004513585A (ja) | 2004-04-30 |
| JP2004513585A5 true JP2004513585A5 (ja) | 2005-01-20 |
Family
ID=26934812
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002541482A Pending JP2004513585A (ja) | 2000-10-20 | 2001-10-19 | クライアントとサーバー間の信頼を管理するシステムおよび方法 |
| JP2002544911A Pending JP2004515117A (ja) | 2000-10-20 | 2001-10-19 | 暗号化データセキュリティシステムおよび方法 |
Family Applications After (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002544911A Pending JP2004515117A (ja) | 2000-10-20 | 2001-10-19 | 暗号化データセキュリティシステムおよび方法 |
Country Status (7)
| Country | Link |
|---|---|
| US (2) | US20020107804A1 (ja) |
| EP (2) | EP1327321A4 (ja) |
| JP (2) | JP2004513585A (ja) |
| CN (2) | CN1439136A (ja) |
| AU (2) | AU2002220182A1 (ja) |
| BR (2) | BR0107346A (ja) |
| WO (2) | WO2002039222A2 (ja) |
Families Citing this family (63)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8706630B2 (en) * | 1999-08-19 | 2014-04-22 | E2Interactive, Inc. | System and method for securely authorizing and distributing stored-value card data |
| US7698565B1 (en) | 2000-03-30 | 2010-04-13 | Digitalpersona, Inc. | Crypto-proxy server and method of using the same |
| US7409543B1 (en) * | 2000-03-30 | 2008-08-05 | Digitalpersona, Inc. | Method and apparatus for using a third party authentication server |
| US7644188B2 (en) * | 2002-02-25 | 2010-01-05 | Intel Corporation | Distributing tasks in data communications |
| US7516491B1 (en) * | 2002-10-17 | 2009-04-07 | Roger Schlafly | License tracking system |
| EP1559256B1 (en) * | 2002-11-06 | 2006-08-09 | International Business Machines Corporation | Providing a user device with a set of access codes |
| US20040122772A1 (en) * | 2002-12-18 | 2004-06-24 | International Business Machines Corporation | Method, system and program product for protecting privacy |
| ITTO20030079A1 (it) * | 2003-02-06 | 2004-08-07 | Infm Istituto Naz Per La Fisi Ca Della Mater | Procedimento e sistema per l'identificazione di un soggetto |
| CN1806217A (zh) * | 2003-06-19 | 2006-07-19 | 皇家飞利浦电子股份有限公司 | 用于验证口令的方法和设备 |
| TWI350686B (en) * | 2003-07-14 | 2011-10-11 | Nagravision Sa | Method for securing an electronic certificate |
| US7400639B2 (en) * | 2003-08-07 | 2008-07-15 | Intel Corporation | Method, system, and article of manufacture for utilizing host memory from an offload adapter |
| US8190893B2 (en) * | 2003-10-27 | 2012-05-29 | Jp Morgan Chase Bank | Portable security transaction protocol |
| US7827603B1 (en) * | 2004-02-13 | 2010-11-02 | Citicorp Development Center, Inc. | System and method for secure message reply |
| US7548620B2 (en) * | 2004-02-23 | 2009-06-16 | Verisign, Inc. | Token provisioning |
| AU2004201058B1 (en) * | 2004-03-15 | 2004-09-09 | Lockstep Consulting Pty Ltd | Means and method of issuing Anonymous Public Key Certificates for indexing electronic record systems |
| US8250650B2 (en) * | 2004-09-09 | 2012-08-21 | International Business Machines Corporation | Front-end protocol for server protection |
| JP4938673B2 (ja) * | 2004-10-15 | 2012-05-23 | ベリサイン・インコーポレイテッド | ワンタイムパスワード |
| US7840993B2 (en) * | 2005-05-04 | 2010-11-23 | Tricipher, Inc. | Protecting one-time-passwords against man-in-the-middle attacks |
| US20070005602A1 (en) * | 2005-06-29 | 2007-01-04 | Nokia Corporation | Method, electronic device and computer program product for identifying entities based upon innate knowledge |
| US20070016767A1 (en) * | 2005-07-05 | 2007-01-18 | Netdevices, Inc. | Switching Devices Avoiding Degradation of Forwarding Throughput Performance When Downloading Signature Data Related to Security Applications |
| US8181232B2 (en) * | 2005-07-29 | 2012-05-15 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
| JP4436294B2 (ja) * | 2005-08-26 | 2010-03-24 | 株式会社トリニティーセキュリティーシステムズ | 認証処理方法、認証処理プログラム、記録媒体および認証処理装置 |
| WO2007035327A2 (en) * | 2005-09-20 | 2007-03-29 | Matsushita Electric Industrial Co., Ltd. | System and method for component trust model in peer-to-peer service composition |
| US9002750B1 (en) | 2005-12-09 | 2015-04-07 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
| US7904946B1 (en) | 2005-12-09 | 2011-03-08 | Citicorp Development Center, Inc. | Methods and systems for secure user authentication |
| US9768963B2 (en) | 2005-12-09 | 2017-09-19 | Citicorp Credit Services, Inc. (Usa) | Methods and systems for secure user authentication |
| US9258124B2 (en) | 2006-04-21 | 2016-02-09 | Symantec Corporation | Time and event based one time password |
| US20080005034A1 (en) * | 2006-06-09 | 2008-01-03 | General Instrument Corporation | Method and Apparatus for Efficient Use of Trusted Third Parties for Additional Content-Sharing Security |
| ATE523020T1 (de) * | 2006-08-31 | 2011-09-15 | Encap As | Verfahren zur synchronisierung zwischen server und mobiler vorrichtung |
| US8285989B2 (en) * | 2006-12-18 | 2012-10-09 | Apple Inc. | Establishing a secured communication session |
| TWI339976B (en) * | 2007-03-16 | 2011-04-01 | David Chiu | Business protection method in internet |
| US7930554B2 (en) * | 2007-05-31 | 2011-04-19 | Vasco Data Security,Inc. | Remote authentication and transaction signatures |
| US8667285B2 (en) | 2007-05-31 | 2014-03-04 | Vasco Data Security, Inc. | Remote authentication and transaction signatures |
| KR100954223B1 (ko) * | 2007-11-22 | 2010-04-21 | 한국전자통신연구원 | Ｒｔｃ를 이용하는 암호시스템간 보안 통신 방법 및 장치 |
| US8935528B2 (en) * | 2008-06-26 | 2015-01-13 | Microsoft Corporation | Techniques for ensuring authentication and integrity of communications |
| US20100057910A1 (en) * | 2008-09-02 | 2010-03-04 | International Business Machines Corporation | Concept for trusting client-side storage and distribution of asynchronous includes in an application server environment |
| US8411867B2 (en) * | 2009-04-06 | 2013-04-02 | Broadcom Corporation | Scalable and secure key management for cryptographic data processing |
| US8904519B2 (en) * | 2009-06-18 | 2014-12-02 | Verisign, Inc. | Shared registration system multi-factor authentication |
| US10102352B2 (en) * | 2009-08-10 | 2018-10-16 | Arm Limited | Content usage monitor |
| US20110191581A1 (en) * | 2009-08-27 | 2011-08-04 | Telcordia Technologies, Inc. | Method and system for use in managing vehicle digital certificates |
| JP5597053B2 (ja) * | 2010-07-28 | 2014-10-01 | Ｋｄｄｉ株式会社 | 認証システム、認証方法およびプログラム |
| WO2012039714A1 (en) * | 2010-09-23 | 2012-03-29 | Hewlett-Packard Development Company, L.P. | Methods, apparatus and systems for monitoring locations of data within a network service |
| US8621282B1 (en) * | 2011-05-19 | 2013-12-31 | Google Inc. | Crash data handling |
| EP2742473B1 (en) * | 2011-08-08 | 2022-07-13 | Bloomberg Finance L.P. | System and method for electronic distribution of software and data |
| US8990913B2 (en) * | 2012-04-17 | 2015-03-24 | At&T Mobility Ii Llc | Peer applications trust center |
| US9420008B1 (en) * | 2012-05-10 | 2016-08-16 | Bae Systems Information And Electronic Systems Integration Inc. | Method for repurposing of communications cryptographic capabilities |
| US8935523B1 (en) * | 2012-07-18 | 2015-01-13 | Dj Inventions, Llc | Cryptographic protected communication system with multiplexed cryptographic cryptopipe modules |
| US8924727B2 (en) * | 2012-10-12 | 2014-12-30 | Intel Corporation | Technologies labeling diverse content |
| US9288049B1 (en) * | 2013-06-28 | 2016-03-15 | Emc Corporation | Cryptographically linking data and authentication identifiers without explicit storage of linkage |
| GB2524497A (en) * | 2014-03-24 | 2015-09-30 | Vodafone Ip Licensing Ltd | User equipment proximity requests |
| US9660983B2 (en) * | 2014-10-24 | 2017-05-23 | Ca, Inc. | Counter sets for copies of one time password tokens |
| CN104615947B (zh) * | 2015-02-02 | 2017-10-03 | 中国科学院软件研究所 | 一种可信的数据库完整性保护方法及系统 |
| US9948620B2 (en) * | 2015-12-15 | 2018-04-17 | International Business Machines Corporation | Management of encryption within processing elements |
| FR3051064B1 (fr) * | 2016-05-09 | 2018-05-25 | Idemia France | Procede de securisation d'un dispositif electronique, et dispositif electronique correspondant |
| US20180198620A1 (en) * | 2017-01-11 | 2018-07-12 | Raptor Engineering, LLC | Systems and methods for assuring data on leased computing resources |
| US11057366B2 (en) | 2018-08-21 | 2021-07-06 | HYPR Corp. | Federated identity management with decentralized computing platforms |
| US11178148B2 (en) | 2018-08-21 | 2021-11-16 | HYPR Corp. | Out-of-band authentication to access web-service with indication of physical access to client device |
| US10764752B1 (en) * | 2018-08-21 | 2020-09-01 | HYPR Corp. | Secure mobile initiated authentication |
| US10939295B1 (en) * | 2018-08-21 | 2021-03-02 | HYPR Corp. | Secure mobile initiated authentications to web-services |
| US11017090B2 (en) | 2018-12-17 | 2021-05-25 | Hewlett Packard Enterprise Development Lp | Verification of a state of a platform |
| CZ2019355A3 (cs) * | 2019-06-07 | 2020-08-19 | Martin Hruška | Způsob ochrany duševního vlastnictví jako záznam souborů dat o chráněném díle a jeho původcích elektronickou formou |
| US11360784B2 (en) * | 2019-09-10 | 2022-06-14 | Hewlett Packard Enterprise Development Lp | Integrity manifest certificate |
| US11671265B2 (en) | 2019-10-25 | 2023-06-06 | John A. Nix | Secure configuration of a secondary platform bundle within a primary platform |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5367572A (en) * | 1984-11-30 | 1994-11-22 | Weiss Kenneth P | Method and apparatus for personal identification |
| US5241599A (en) * | 1991-10-02 | 1993-08-31 | At&T Bell Laboratories | Cryptographic protocol for secure communications |
| JP3053527B2 (ja) * | 1993-07-30 | 2000-06-19 | インターナショナル・ビジネス・マシーンズ・コーポレイション | パスワードを有効化する方法及び装置、パスワードを生成し且つ予備的に有効化する方法及び装置、認証コードを使用して資源のアクセスを制御する方法及び装置 |
| US5604803A (en) * | 1994-06-03 | 1997-02-18 | Sun Microsystems, Inc. | Method and apparatus for secure remote authentication in a public network |
| US5671283A (en) * | 1995-06-08 | 1997-09-23 | Wave Systems Corp. | Secure communication system with cross linked cryptographic codes |
| US5790677A (en) * | 1995-06-29 | 1998-08-04 | Microsoft Corporation | System and method for secure electronic commerce transactions |
| JP3982848B2 (ja) * | 1995-10-19 | 2007-09-26 | 富士通株式会社 | セキュリティレベル制御装置及びネットワーク通信システム |
| US5706347A (en) * | 1995-11-03 | 1998-01-06 | International Business Machines Corporation | Method and system for authenticating a computer network node |
| FR2741465B1 (fr) * | 1995-11-20 | 1997-12-19 | Bull Sa | Procede d'authentification d'un utilisateur travaillant dans un environnement distribue en mode client/serveur |
| US6085320A (en) * | 1996-05-15 | 2000-07-04 | Rsa Security Inc. | Client/server protocol for proving authenticity |
| KR100213188B1 (ko) * | 1996-10-05 | 1999-08-02 | 윤종용 | 사용자 인증 장치 및 방법 |
| US5903721A (en) * | 1997-03-13 | 1999-05-11 | cha|Technologies Services, Inc. | Method and system for secure online transaction processing |
| JP3595109B2 (ja) * | 1997-05-28 | 2004-12-02 | 日本ユニシス株式会社 | 認証装置、端末装置、および、それら装置における認証方法、並びに、記憶媒体 |
| JP3657745B2 (ja) * | 1997-07-23 | 2005-06-08 | 横河電機株式会社 | ユーザ認証方法及びユーザ認証システム |
| US6011849A (en) * | 1997-08-28 | 2000-01-04 | Syndata Technologies, Inc. | Encryption-based selection system for steganography |
| JP2000019960A (ja) * | 1998-06-29 | 2000-01-21 | Hitachi Ltd | 遠隔操作方法 |
| KR20010031840A (ko) * | 1998-09-04 | 2001-04-16 | 브레너 해리 | 익명성 쇼핑 및 익명성 밴더 운송자를 갖는 전자 상거래 |
| EP1238506A1 (en) * | 1999-01-29 | 2002-09-11 | Allen Claxton | Reliance manager for electronic transaction system |
| US6421768B1 (en) * | 1999-05-04 | 2002-07-16 | First Data Corporation | Method and system for authentication and single sign on using cryptographically assured cookies in a distributed computer environment |
| US6728884B1 (en) * | 1999-10-01 | 2004-04-27 | Entrust, Inc. | Integrating heterogeneous authentication and authorization mechanisms into an application access control system |
-
2001
- 2001-10-19 AU AU2002220182A patent/AU2002220182A1/en not_active Abandoned
- 2001-10-19 EP EP01987265A patent/EP1327321A4/en not_active Withdrawn
- 2001-10-19 WO PCT/US2001/046238 patent/WO2002039222A2/en not_active Application Discontinuation
- 2001-10-19 US US10/015,201 patent/US20020107804A1/en not_active Abandoned
- 2001-10-19 CN CN01805298A patent/CN1439136A/zh active Pending
- 2001-10-19 CN CNA018175740A patent/CN1470112A/zh active Pending
- 2001-10-19 JP JP2002541482A patent/JP2004513585A/ja active Pending
- 2001-10-19 US US10/010,995 patent/US20020087860A1/en not_active Abandoned
- 2001-10-19 BR BR0107346A patent/BR0107346A/pt not_active Application Discontinuation
- 2001-10-19 JP JP2002544911A patent/JP2004515117A/ja active Pending
- 2001-10-19 EP EP01993857A patent/EP1328891A4/en not_active Withdrawn
- 2001-10-19 WO PCT/US2001/046290 patent/WO2002043309A2/en not_active Application Discontinuation
- 2001-10-19 BR BR0114768A patent/BR0114768A/pt not_active Application Discontinuation
- 2001-10-19 AU AU2002239500A patent/AU2002239500A1/en not_active Abandoned
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2004513585A5 (ja) | ||
| US20020107804A1 (en) | System and method for managing trust between clients and servers | |
| Claessens et al. | (How) can mobile agents do secure electronic transactions on untrusted hosts? A survey of the security issues and the current solutions | |
| EP1942430B1 (en) | Token Passing Technique for Media Playback Devices | |
| US8843415B2 (en) | Secure software service systems and methods | |
| USRE38070E1 (en) | Cryptography system and method for providing cryptographic services for a computer application | |
| JP5680115B2 (ja) | データ・セキュリティ装置のためのトランザクション監査 | |
| CN105095696B (zh) | 对应用程序进行安全认证的方法、系统及设备 | |
| KR100912276B1 (ko) | 하드웨어 식별에 기초한 디지털권 관리 방법을 이용한 전자소프트웨어 배포 방법 및 시스템 | |
| EP0881559B1 (en) | Computer system for protecting software and a method for protecting software | |
| KR100362219B1 (ko) | 변조방지 프로세서를 이용하여 프로그램을 분배하기 위한방법 및 시스템 | |
| US7526649B2 (en) | Session key exchange | |
| US20040088541A1 (en) | Digital-rights management system | |
| US8312518B1 (en) | Island of trust in a service-oriented environment | |
| JP2008501176A (ja) | プライバシーを保護する情報配布システム | |
| JP2004537095A (ja) | 情報セキュリティシステム | |
| EP1277300A1 (en) | System and method for controlling and enforcing access rights to encrypted media | |
| JP2007511810A (ja) | 乱数関数を利用した実行証明 | |
| KR100873314B1 (ko) | 안전한 콘텐트 배포를 위한 방법 및 장치 | |
| US7770001B2 (en) | Process and method to distribute software product keys electronically to manufacturing entities | |
| Mana et al. | An efficient software protection scheme | |
| AU2009295193A1 (en) | Method and system for user authentication | |
| Pearson | Trusted computing: Strengths, weaknesses and further opportunities for enhancing privacy | |
| JP4510392B2 (ja) | 個人情報認証を行うサービス提供システム | |
| JP2004032220A (ja) | 電子チケットを用いたアクセス権管理装置 |