JP2008500776A - 直接証明署名の否定を提供する装置及び方法 - Google Patents

Abstract

幾つかの形態のおける、直接証明署名の否定を提供する方法及び装置を示す。１つの形態では、トラステッド・ハードウェア・デバイスは、トラステッド・ハードウェア・デバイスの固有のデバイス認証情報又は暗号情報を露呈することなく、トラステッド・ハードウェア・デバイスが暗号情報を所有していることを検証者に確証させる。検証者がハードウェアデバイスは暗号情報を所有していると確証するとただちに、検証者は少なくとも１つの信用できない直接証明署名を有するトラステッド・ハードウェア・デバイスに署名拒否リクエストを発行しても良い。それに応じて、トラステッド・ハードウェア・デバイスによって所有されている暗号鍵がその少なくとも１つの疑わしい直接証明署名を生成することに用いられなかったことを検証者に知らせることによって、トラステッド・ハードウェア・デバイスは疑わしい直接証明署名の否定を発行しても良い。他の形態も記載され、請求される。

Description

本発明における１つ以上の実施形態は、概して暗号分野に関する。より具体的には、本発明における１つ以上の実施形態は、直接証明署名の否定を提供する方法及び装置に関する。

今日の多くの通信システムでは、やり取りされる情報における信頼性及びセキュリティに多大な懸念が集まっている。この懸念に対応して、トラステッド・コンピューティング・プラットフォーム・アライアンス（ＴＣＰＡ）はプラットフォームに対するセキュリティ・ソリューションを発展している。２００２年２月２２日頃に公開された「Ｍａｉｎ ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ １．１ｂ」との題を持つＴＣＰＡ仕様書に基づくと、各パーソナルコンピュータ（ＰＣ）は信頼できるハードウェアデバイス、ここではトラステッド・プラットフォーム・モジュール（ＴＰＭ）と表すが、を実装する。各ＴＰＭは、固有のエンドースメント鍵ペア（ＥＫ）を含む。エンドースメント鍵ペアは公開ＥＫ鍵（ＰＵＢＥＫ）及び秘密ＥＫ鍵（ＰＲＩＶＥＫ）を主要要素とする。ＴＰＭは概して、製造者によって署名されたＰＵＢＥＫに対する証明書を有する。

動作中、外部の第３者（以後「検証者」と示す）はＴＰＭの認証を要求しても良い。これは二つの相反するセキュリティ懸念を生み出す。第１に、要求された認証情報が正当なＴＰＭから本当にきたことを検証者は確証する必要がある。第２に、ＴＰＭを有するＰＣの所有者はできる限り秘密性を保持したい。特に、ＰＣの所有者は、認証情報が同一のＴＰＭから来ていることを検証者に特定させることなく、異なる検証者に認証情報を提供できることを望む。

これらのセキュリティ懸念に対して提案されている１つのソリューションは、信頼できるサードパーティ（ＴＴＰ）を設立することである。例えば、ＴＰＭは証明識別鍵ペア（ＡＩＫ）、即ち公開ＡＩＫ鍵及び秘密ＡＩＫ鍵を生成しても良い。公開ＡＩＫ鍵はＰＲＩＶＥＫを用いて署名された証明書リクエストに置かれても良く、その後にＴＴＰに送られても良い。ＰＵＢＥＫに対する証明書もまたＴＴＰに送られても良い。証明書が受信されるとすぐ、ＴＴＰは署名された証明書リクエストが有効であることを調べても良い。証明書リクエストが有効であった場合、ＴＴＰは証明書をＴＰＭに対して発行しても良い。

証明書が発行されると、ＴＰＭが検証者からリクエストを受信したときに、ＴＰＭは公開ＡＩＫ、及びＴＴＰによって発行された証明書を用いても良い。ＡＩＫ及び証明書は、ＥＫと無関係でも良く、検証者はＴＰＭ又はＴＰＭを実装したＰＣの身元に関する情報を得られない。実際のところ、上記の認証手法はＴＴＰを設立する必要があることから問題を含む。ＴＴＰとして機能する多様な団体を特定すること、及び設立することは多大な障害となる。

別の提案されたソリューションが、本願の譲受人に所有された同時係属出願（ＵＳ出願番号：１０／３０６，３３６、出願日：２００２年１１月２７日）に開示されている。その提案されたソリューションでは直接証明方法を用いている。そこでは、ＴＰＭの身元を露呈することなく、そして信用できるサードパーティを必要とせずに、ＴＰＭはＡＩＫが正当なＴＰＭによって生成されたことを直接証明することができる。本ソリューションでは、各ＴＰＭは固有の秘密鍵を所有する。残念ながら、相手側はＴＰＭにアクセスして、洗練された手法を用いて、ＴＰＭから固有の秘密鍵を抽出することもできる。

直接証明方法においては、ＴＰＭから削除された鍵を無効にできる方法がある。直接証明プルトコルにおいては、ＴＰＭはベースｈを取得して、ｋ＝ｈ^ｆｍｏｄｎを算出及び露呈する。ここで、ｎは公開鍵の一部であり、ｆはＴＰＭに所有される固有の鍵の一部である。よって、検証者がＴＰＭから削除された値ｆ０を受信した場合、検証者はｋ０＝ｈ^ｆ０ｍｏｄｎを算出してｋ＝ｋ０を満たすかどうかを調べることにより、その直接証明がこの値ｆ０を用いて生成されたかどうかを調べることができる。ｋ＝ｋ０の場合、直接証明はｆ０を用いて生成されており、ｋ＝ｋ０でない場合は、直接証明は他の秘密鍵を用いて生成されている。

この方法の１つの制限として、検証者がｆ０の値を取得する必要があることが挙げられる。相手側はＴＰＭから秘密の固有の値を取得してこれを用いることも考えられる。そこでは、検証者はｆ０の値は取得できないが、あるｋ０を生成する値ｆ０がＴＰＭから削除されたことは知ることとなる。ＵＳ出願番号：１０／３０６，３３６は、この問題を解決する方法を提示している。この方法では、検証者は、ＴＰＭが検証者とやり取りする時に用いる目的で、ベースｈの値を各ＴＰＭに対して提供する必要がある。これにより、検証者は検証者とやり取りした全てのものを関連付けることができる。

本発明の多様な形態を例として図示するが、この形態に限定されるわけではない。

１つの形態に基づいて動作するＴＰＭ（トラステッド・プラットフォーム・モジュール）を実装したプラットフォームを主要要素とするシステムである。

図１のＴＰＭを備えたプラットフォームの第１の形態である。

図１のＴＰＭを備えたプラットフォームの第２の形態である。

図２のＴＰＭを実装したコンピュータの１つの実施形態である。

１つの形態である、製造工程でのＴＰＭのセットアップの手順を示すフロー図である。

１つの形態である、製造された各プラットフォームのセットアップの手順を示すフロー図である。

１つの形態である、トラステッド・ハードウェア・デバイス内に格納された暗号鍵が露呈しないことを確証する方法を示すフロー図である。

１つの形態である、二つの離散対数が同一であることを示すゼロ知識証明を実現する方法を示すフロー図である。

１つの形態である、二つの離散対数が同一であるとの証明を検証する工程を概念的に示すフロー図である。

１つの形態である、トラステッド・ハードウェア・デバイス内に格納された暗号鍵が信用できることを検証者に確証させる方法を示すフロー図である。

直接証明署名の否定を提供する方法及び装置を以下に示す。１つの形態では、トラステッド・ハードウェア・デバイスは、固有のトラステッド・ハードウェア・デバイスのデバイス認証情報又は暗号情報を露呈することなく、暗号情報の所有を検証者に確証させる。これは、信頼できるサードパーティ（ＴＴＰ）を使わないで達成できる。正しくは、これは、ＴＰＭによる計算が暗号鍵を指数として用いる累乗法を伴う「直接証明」手法によって達成できる。１つの形態では、トラステッド・ハードウェア・デバイスは直接証明で用いられるデジタル書名（「直接証明署名」）が、信用できる暗号鍵に基づいていることを検証者に証明する。

１つの形態では、検証者は、トラステッド・ハードウェア・デバイスによって保持された暗号鍵が、信用できない疑わしい直接証明署名（疑わしい直接証明署名）の形成に用いられなかったことを証明する目的で、トラステッド・ハードウェア・デバイスに署名拒否リクエストを発行してもよい。１つの形態においては、ＴＰＭからの情報（例えば、暗号鍵、デジタル署名、デジタル証明書等）が信用できることを、検証者に証明する目的で構築されるＴＰＭの機能は、ファームウェアで実現しても良い。また、そのような機能を専用のハードウェア又はソフトウェアによって実現しても良い。ファームウェア又はソフトウェアを形成する命令又はコードは機械可読メディアに格納される。

ここでは、「機械可読メディア」とはフロッピー（登録商標）ディスク、ハードディスク、光学ディスク（例えば、ＣＤ−ＲＯＭ、ＤＶＤ 、ミニＤＶＤ等）、磁気光学ディスク、読み出し専用メモリ（ＲＯＭ）又はランダムアクセスメモリ（ＲＡＭ）、あらゆるタイプのプログラム可能読み出し専用メモリ（例えば、プロフラム可能読み出し専用メモリ「ＰＲＯＭ」、消去・プログラム可能読み出し専用メモリ「ＥＰＲＯＭ」、電気的消去・プログラム可能読み出し専用メモリ「ＥＥＰＲＯＭ」、又はフラッシュメモリ）、磁気カード又は光学カード等を表すが、それらに限定されない。ソフトウェアは、ダウンロードされる信号の一部として、又は通信リンクを伝播中に一時的に信号及び／又は通信リンクに格納されるので、信号そのもの及び／又は通信リンクも機械可読メディアとみなすことができる。

以下の記載において、特定の専門用語が、本発明の１つ以上の形態において特定の要素を表す目的で用いられる。例えば、「プラットフォーム」は情報を送受信する目的のあらゆるタイプの通信デバイスと定義できる。多様なプラットフォームの例として、コンピュータ、パーソナルデジタルアシスタント、携帯電話、セットトップボックス、ファクシミリ、プリンタ、モデム又はルータ等があるが、それらに限定されない。「通信リンク」は概して、プラットフォームに適合する１つ以上の情報運搬メディアと定義できる。多様な通信リンクの例として、電線、光ファイバ、ケーブル、バストレース、又は無線技術があるが、それらに限定されない。

「検証者」は他の構成要素から信頼性又は権限の検証をリクエストする要素（個人、プラットフォーム、システム、ソフトウェア及び／又はデバイス）を表す。通常、この事はリクエストされた情報を開示又は提供する前に行われる。「証明者」は権限、正当性、及び／又は身元の証明の提供をリクエストされる構成要素を表す。「デバイス製造者」は、「認証製造者」とも表されるが、プラットフォーム又はデバイス（トラステッド・プラットフォーム・モジュール等）を製造又は構成する事業体である。

ここで用いられる、証明者がある暗号情報（署名鍵、秘密鍵等）を保有又は知っていることを、検証者に「証明」又は「確証」するとは、検証者に対して開示された情報及び証明から判断して、証明者が暗号情報を所有している可能性が非常に高いこと意味する。検証者に暗号情報を「露呈」又は「開示」することなく、検証者に上記のことを証明することは、検証者に開示された情報に基づいて、検証者が暗号情報を計算的に割り出すことができないことを意味する。そのような証明をここでは、直接証明と述べる。用語「直接証明」とは、当分野で公知であるゼロ知識証明を表す。

ここで述べられる多様な形態の記載及び図を通して、係数、変数、及び他のシンボル（「ｈ」等）は同じラベル又は名前によって表される。それゆえ、異なる方程式又は機能的記載に加え、１つの方程式の異なる部分において使われる特定のシンボルは、同一のシンボルを表している。
Ｉ．一般的なアーキテクチャ

図１に、１つの形態における、トラステッド・ハードウェア・デバイス（「トラステッド・プラットフォーム・モジュール」又は「ＴＰＭ」と表す）を実装したプラットフォームを主要要素とするシステム１００を示す。第１のプラットフォーム１０２（検証者）は第２のプラットフォーム２００（証明者）に認証リクエスト１０６を転送する。リクエスト１０６に応じて、第２のプラットフォーム２００は認証情報１０８を提供する。１つの形態では、ネットワーク１２０はローカル又は広域エリアネットワーク、及び／又は企業のイントラネット、インターネット又は他のネットワーク等のネットワークインフラの一部を形成する。

さらに、セキュリティを高める目的で、第１のプラットフォーム１０２は、証明者側プラットフォーム２００が選ばれたデバイス製造者又は選ばれたデバイス製造者団体（以下デバイス製造者１１０と示す）によって製造された事を検証しても良い。１つの形態では、第１のプラットフォーム１０２は、第２のプラットフォーム２００がデバイス製造者１１０によって作られた暗号情報（秘密署名鍵等）を所有していることを厳密に調べても良い。第２のプラットフォーム２００は認証情報を提供することによってその検証に応答しても良い。その応答では、第２のプラットフォーム２００がデバイス製造者１１０によって作られた暗号情報を所有することを、暗号情報又は固有のデバイス／プラットフォーム認証情報を露呈することなく、第１のプラットフォーム１０２に確証させることができる。

図２は、プラットフォーム２２０が信用できる暗号情報を所有している事を、その暗号情報又は固有のデバイス認証情報を開示することなく、検証者に確証させる目的で、ＴＰＭ２２０を備えるプラットフォーム２００を表すブロック図である。典型的には、コンピュータシステム２００は、プロセッサ（ＣＰＵ）２０２及びチップセット２１０の間で情報を通信する目的で、プロセッサシステムバス｛フロントサイドバス（ＦＳＢ）｝２０４を備える。ここに記載したとおり、用語「チップセット」は所望のシステム機能を実行する目的でＣＰＵ２０２に結合される多様なデバイスを集合的に表すために用いている。

典型的には、グラフィックブロック２１８、ハードドライブデバイス（ＨＤＤ）２１４及びメインメモリ２１２がチップセット２１０に結合されても良い。１つの形態では、チップセット２１０は、Ｉ／Ｏデバイス２１６（２１６−１〜２１６−Ｎ）と通信する目的で、メモリコントローラ及び／又は入力／出力（Ｉ／Ｏ）コントローラを備えてもよい。他の形態として、チップセット２１０はグラッフィクブロック２１８を取り込んで、グラフィックメモリコントローラハブ（ＧＭＣＨ）として稼動しても良い。１つの形態では、メインメモリ２１２は、ランダムアクセスメモリ（ＲＡＭ）、ダイナミックＲＡＭ（ＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、シンクロナスＤＲＡＭ（ＳＤＲＡＭ）、ダブルデータレート（ＤＤＲ）ＳＤＲＡＭ（ＤＤＲ−ＳＤＲＡＭ）、ランバスＤＲＡＭ（ＲＤＲＡＭ）、又はデータの高速のバッファリングをサポートするデバイスを含んでも良いが、それらに限定されない。

図３に、１つの形態である、第２のプラットフォーム２００のトラステッド・プラットフォーム・モジュール（ＴＰＭ）２２０を示す。ＴＰＭ２２０はデバイス製造者１１０によって製造された暗号デバイスである。１つの形態では、ＴＰＭ２２０はパッケージ内にカプセル化された小容量のオンチップメモリを有するプロセッサユニット２２２を備える。１つの形態では、カプセル化されたメモリは認証製造者から受け取った暗号鍵２３０を格納しても良い。ＴＰＭ２２０は、認証情報が正当なＴＰＭから転送されたことを判定できるよう第１プラットフォーム１０２に認証情報を提供しても良い。用いられる認証情報は、ＴＰＭ又は第２のプラットフォームの身元、ここでは「固有のデバイス認証情報」と表すが、を認証することを可能にする固有でないデータである。

１つの形態では、１つ以上の鍵、ハッシュ値、署名又は証明書等の暗号情報を格納する目的で、ＴＭＰ２２０は更に不揮発性メモリ２２４（フラッシュメモリ等）を備えても良い。１つの形態では、暗号情報は認証製造者から受け取った暗号鍵である。以下に示すとおり、「Ｘ」のハッシュ値を「Ｈａｓｈ（Ｘ）」と表しても良い。当然、そのような情報は、フラッシュメモリ２２４の代わりに、プラットフォーム２００の外部メモリ２８０内に格納されても良い。暗号情報は、特にＴＰＭ２２０の外部に格納される場合には暗号化されても良い。

１つの形態では、検証側プラットフォームからの認証リクエストに応答する目的で、ＴＰＭ２２０は認証ロジック２４０を含んでもよい。１つの形態では、認証ロジック２４０は、ＴＰＭ２２０が認証デバイス製造者によって作られた暗号情報を格納している事を、その暗号情報又は固有のデバイス／プラットフォーム認証情報を露呈することなく、検証側プラットフォームに確証又は保証しても良い。その結果、認証ロジック２４０は証明者側プラットフォームの身元を保護する一方で、リクエストのあった認証を実行する。認証ロジック２４０は更に図４で示される。

図のとおり、直接証明ロジック２５０は、証明者側プラットフォームが認証製造者からの暗号情報を所有していることを、暗号情報を露呈せずに検証者に確証させる目的で、以下に詳細を示す直接証明を実行する。鍵ロジック２７０は固有の秘密のペア（ｃ，Ｆ）を受け取る目的でＴＰＭ２２０におけるプラットフォームのセットアップを実行する。ここで、Ｆ＝ｃ^ｅｍｏｄｎであり、Ｆは秘密署名鍵を、ｅ及びｎはＴＰＭ２２０の認証製造者の公開鍵を意味する。

以下に詳細に示すとおり、署名拒否ロジック２６０は、直接証明ロジック２５０で実行される直接証明処理の間に、デバイスが所有している秘密署名鍵が疑わしい署名（疑わしい直接署名証明）を生成しないことを検証側プラットフォームに確証又は証明する目的で更なる機能を提供する。上記に示した形態よりも少ない装備又は優れた装備のコンピュータが特定の実施に対しては望ましい。従って、プラットフォーム２００の構成は価格的制約、性能要求、技術的進歩、及び／又はその他の状況等の多くの要素に応じて、実施形態ごとに異なる。
ＩＩ．プラットフォームのセットアップ

１つ以上のタイプのプラットフォーム又はデバイスを含ませる目的で、「プラットフォーム・ファミリ」がデバイス製造者によって定義されても良い。例えば、あるプラットフォーム・ファミリは、同一のセキュリティ関連情報を備える全てのプラットフォーム（会員）の集合体であっても良い。このセキュリティ関連情報は、ＴＣＰＡモデルのＥＫ又はＡＩＫ証明書に含まれる幾つかの情報を含んでも良い。セキュリティ関連情報はまた、特定のプラットフォーム又はデバイスの製造番号及びモデル番号を含んでも良い。それぞれのプラットフォーム・ファミリに対して、デバイス製造者は、デバイス製造者がそのプラットフォーム・ファミリに対して用いる暗号パラメータを生成する。デバイス製造者は、デバイス（プラットフォーム２００又はＴＰＭ２２０）に対して機密を署名する目的で用いられる署名鍵を図５及び６で示す方法で生成する。

図５は、１つの形態である、プラットフォーム・ファミリ証明書（ＰＦＣ）を形成する方法４００を示すフローチャートである。１つの形態では、デバイス製造者は公開モジュールｎ、公開指数ｅ及び秘密指数ｄを備えるＲＳＡ公開／秘密鍵ペアを生成する目的で、公開鍵暗号機能（Ｒｉｖｅｓｔ，Ｓｈａｍｉｒ，Ａｄｅｌｍａｎ（ＲＳＡ）機能）を活用する（ブロック４０２）。公開鍵は値ｅ及びｎに基づいている。一方で、秘密鍵は値ｄ及びｎに基づいている。これは、Ｂｒｕｃｅ Ｓｃｈｎｅｉｅｒ，Ｊｏｈｎ Ｗｉｌｌｙ 及び ＳｏｎｓによるＡｐｐｌｉｅｄ Ｃｒｙｐｔｏｇｒａｐｈｙ（ＩＳＢＮ：０４７１１１７０９９；Ｓｅｃｏｎｄ Ｅｄｉｔｉｏｎ（１９９６））等に記載されている周知の方法を用いる事で生成される。１つの形態では、ｎを計算的に因数分解できないようモジュールｎを十分大きくするべきである。

デバイス製造者はパラメータＺを特定する（ブロック４０４）。パラメータＺは零（０）とｎの間の整数である。デバイス製造者は、セキュリティパラメータＷを特定する（ブロック４０６）。セキュリティパラメータＷは零（０）とｎの間の整数である。しかしながら、あまりにも小さすぎたり又は大きすぎたりするＷを選択することはセキュリティ障害の要因となる。本発明の１つの形態では、Ｗの値としておおよそ２^１６０前後が選択される。Ｗとしては２^８０とｎの平方根との間の値を選択することが望ましい。本発明の１つの形態では、デバイス製造者はＰ＝ｕ＊ｎ＋１を満たす素数Ｐを算出する（ブロック４０８）。Ｐが素数である限り、ｕはどの値でも良い。しかしながら、一定のセキュリティレベルを保持するためには、離散対数「ｍｏｄＰ」の算出が計算的に実現不可能となるようＰの値は十分大きくするべきである。

１つの形態として、デバイス製造者の直接証明公開鍵は暗号パラメータｅ，ｎ，ｕ，Ｐ，Ｚ及びＷから構築される。これらのパラメータはデバイスによって生成される直接証明署名を検証する目的で検証者によって使用される。デバイス製造者は、暗号パラメータｅ，ｎ，ｕ，Ｐ，Ｚ，Ｗ、プラットフォーム・ファミリのセキュリティ関連情報、及びデバイス製造者名を含むプラットフォーム・ファミリ証明書を生成する（ブロック４１０）。１つの形態として、パラメータｕ及びＰの両方を含まない場合もある。なぜなら、ｎ及びこれらの一方の値が与えられれば、他の一方はＰ＝ｕ＊ｎ＋１を用いて算出できるからである。１つの形態として、デバイス製造者は、幾つかの異なるプラットフォーム・ファミリに対して同一の暗号パラメータｅ，ｎ，ｕ，Ｐ及びＷを用いて、異なるプラットフォームごとにＺの値だけを変化させる。この場合、Ｚの値は少なくとも、又はおおよそ４Ｗずつ異なるよう選択されても良い。この選択される差は任意に選択できる。

プラットフォーム・ファミリ証明書が生成されるとただちに、デバイス製造者はプラットフォーム・ファミリ証明書を特定のプラットフォーム・ファミリに属するプラットフォーム又はデバイスに提供する（ブロック４１２）。証明者（例えば、図１に示す第２のプラットフォーム２００）から検証者への、プラットフォーム・ファミリ証明書に付随する暗号パラメータの配布は多数の方法で実現できる。しかしながら、これらの暗号パラメータは、検証者にプラットフォーム・ファミリ証明書がデバイス製造者によって生成されたことを確証させる方法で検証者に配布されるべきである。

例えば、一般的な方法として、検証者にそのパラメータを直接配布する方法がある。他の一般的な方法では、認証オーソリティ、１つの例としてはデバイス製造者であるが、によって署名されたプラットフォーム・ファミリ証明書を配布する方法がある。この後者の場合では、認証オーソリティの公開鍵は検証者に配布されるべきである。署名されたプラットフォーム・ファミリ証明書はそのプラットフォーム・ファミリ（証明者側プラットフォーム）のそれぞれのプラットフォーム会員に与えることができる。その結果、証明者側プラットフォームは署名されたプラットフォーム・ファミリ証明書を検証者に提供することができる。

図６は、１つの形態における、製造された証明者側プラットフォームに対して、例えば、図４で示した鍵ロジック２７０によって行われるセットアップの方法５００を示したフローチャートである。証明者側のプラットフォームのＴＰＭは０＜Ｆ−Ｚ＜Ｗを満たす任意の値Ｆを選択する（ブロック５０２）。ＴＰＭは署名のため認証製造者にこの任意の値Ｆを送る前に値Ｆをブラインド化しても良い（ブロック５０４）。このブラインド化処理は、任意の値Ｆの正確な内容を認証製造者に分かりにくくする目的で実行される。１つの形態では、ＴＰＭは任意の値Ｂを選択する。ここでは、１＜Ｂ＜ｎ−１であり（ブロック５０６）、Ａ＝Ｂ^ｅｍｏｄｎと計算される（ブロック５０８）。それから、ＴＰＭはＦ’＝Ｆ＊Ａｍｏｄｎを算出する（ブロック５１０）。ＴＰＭがＦをブラインド化しない場合、ＴＰＭはＦ’＝Ｆ及びＡ＝１となる（ブロック５１２）。

これらの計算の後で、ＴＰＭは認証製造者にＦ’を送る（ブロック５１２）。認証製造者はｃ’＝Ｆ’^ｄｍｏｄｎを算出し（ブロック５１６）、証明者にｃ’を提供する（ブロック５１８）。証明者側のＴＰＭはｃ＝ｃ’＊Ｂ^−１ｍｏｄｎを算出する（ブロック５２０）。これはｃ＝Ｆ^ｄｍｏｄｎであることを暗に示していることに留意してほしい。ｃ及びＦの値はその後、証明者側のＴＰＭ又は外部の記憶メモリに格納される（ブロック５２２）。ここに記したとおり、ＦをＴＰＭの署名鍵と称しても良く、秘密ペアｃ，Ｆを暗号情報、又は「会員鍵」と称しても良い。ここに記したとおり、Ｆを「スードニム指数」と称しても良い。

ハードウェアデバイスが認証製造者からの暗号情報を所有していることを検証者に確証させる目的で、直接証明を実行するためのＴＰＭの動作は、同時係属出願（ＵＳ出願番号１０／６７５，１６５出願日２００３年９月３０日）に開示されている。直接証明法では、直接証明に用いられる証明者の署名（直接証明署名）は、プラットフォーム製造者（発行者）が場合、公開鍵を用いる事で有効となる。それゆえ、全ての会員は同一の公開鍵を用いて有効となった署名を所有する事ができる。そして、会員によって生成された直接証明署名は、どの会員がその直接証明署名を生成したかを特定しないことを保証できる。

ＴＰＭが固有の秘密ペアを所有していることを検証者に証明する目的で、ランダムベースオプションに準じたベースとして用いる値Ｂを獲得しても良い。例えば、ＴＰＭはｋ＝Ｂ^ＦｍｏｄＮを算出して、署名リクエストの応答として検証者にＢ及びｋを提供しても良い。したがって、ここに記したとおり、値ｋは直接証明署名における「スードニム」とみなされ、Ｂは直接証明署名における「ベース」とみなされる。ＴＰＭはそれから、ＴＰＭがＦ＝ｃ^ｅｍｏｄｎ及びｋ＝Ｂ^ＦｍｏｄＰを満たすようなＦ，ｃを所有していることの証明である直接証明署名を、Ｆ及びｃについての付加情報を露呈することなく実行する。直接証明署名を実行する方法は本出願の譲受人に所有される同時継続出願（ＵＳ出願番号１０／３０６，３３６）によって開示されている。検証者がランダムベースオプションに準じて同一のＴＰＭから証明を受け取ったことを分からせないように、ＴＰＭは新しい直接証明署名を生成するたびに異なる値Ｂを用いても良い。

図４に戻って、１つに形態では、会員鍵の取り消しを処理する目的で、ＴＰＭ２２０は署名拒否ロジック２６０を含んでも良い。会員鍵はハードウェアに保持されるが、その鍵は削除可能である。この場合、検証者は削除された鍵を無効にし、無効にされた（未知の疑わしい）鍵に伴って生成された直接証明署名の受け入れを拒否する。署名プロセスの一環として、ｋ＝Ｂ^ＦｍｏｄＰを算出する目的で、会員はランダムベースＢ、認証会員の公開鍵（ｅ，ｎ）を選択する。Ｂ及びｋの値は署名の一部として露呈される。ランダムベースが用いられ、それから二つの異なる署名が与えられた場合、その二つの署名が同一のスードニム指数Ｆを伴って生成されたのか、又は異なるスードニム指数Ｆ’を伴って生成されたかのかを計算的に特定することは不可能である。

しかしながら、相手側が秘密スードニム指数Ｆ’を幾つかのハードウェアデバイスから削除した場合で（例えばＦ１，Ｆ２，Ｆ３）、検証者がこれらのスードニム指数を所有している場合、検証者は与えられた署名がこれらのスードニム指数の１つを用いて生成されたかどうかをＫ＝Ｂ^Ｆ１ｍｏｄＰ、Ｋ＝Ｂ^Ｆ２ｍｏｄＰ又はＫ＝Ｂ^Ｆ３ｍｏｄＰであるかを調べることにより判別することができる。これは検証者がハードウェアデバイスから削除された秘密のＦ’を所有している場合に有効である。しかし、会員鍵がハードウェアデバイスから削除されたことを検証者が疑ってはいるが、検証者が会員鍵、特に指数Ｆを所有していない場合には有効でない。

検証者に信用できない会員鍵を無効にさせる目的で、直接証明方法は名前ベースオプションを支持する。１つの形態として、名前ベースオプションに応じて、検証者はベースＢを提供する。ここでは１つの形態として、Ｂは検証者の名前から導かれる。会員は任意のＢを選択する代わりに直接証明署名においてこのようなベースＢを用いても良い。検証者が同一のベースを用いている限り、検証者は検証者に送られた二つの署名が同一のスードニム指数Ｆを伴うかどうかを、二つの署名は同一のスードニムＢ^ＦｍｏｄＰを生成するので判断することができる。

したがって、名前ベースオプションを用いている検証者が直接証明署名を受け取った場合で、署名を生成する目的で用いられた会員鍵が疑わしい場合、検証者は、同一の名前ベースを用いている限りこの会員鍵による更なる署名を拒絶できる。しかしながら、検証者に対してこの名前ベースオプションを有効に用いる唯一の方法は、長い間同一の名前ベースオプションを使うことである。これは、検証者の名前ベースを伴う会員によって実行されるやり取りの全てと検証者がリンクされるので秘密性の観点からは理想的ではない。

図７は、１つの形態における、ＴＰＭ内に格納された暗号鍵が信用できることを検証する目的で、検証者側プラットフォームによって実行される方法５００を示すフローチャートである。典型的には、ブロック５１０の工程において、検証者側プラットフォームは
未知の疑わしい鍵によって生成された疑わしい直接証明署名であることを特定する。検証者側プラットフォームが未知の疑わしい鍵によって生成された疑わしい直接証明署名に気づいたと想定しよう。Ｂ_０をベース、Ｋ_０を疑わしい直接証明署名の１つの中から受け取ったスードニムとする。１つの形態として、検証者側プラットフォームは疑わしい直接証明署名それぞれに対して以下の処理を繰り返す。

記載した形態では、検証者側プラットフォームはＫ_０＝Ｂ_０ ^Ｆ０ｍｏｄＰを算出する目的で用いられる疑わしい鍵Ｆ_０のコピーを所有しない。したがって、ブロック５２０の工程において、検証者側プラットフォームは、未知の疑わしい鍵Ｆ_０を伴って生成された、疑わしい直接証明署名内のベースＢ_０及びスードニムＫ_０を転送する。その応答として、検証者側プラットフォームは、Ｂ_０及びＫ_０を用いて算出された１つ以上の値を証明者側プラットフォームから受信する。

１つの形態として、証明者側プラットフォーム内に格納された暗号鍵の検証はブロック５４０〜５６０の工程で示すとおり行われる。証明者側プラットフォームは、任意の値Ｒを生成する。１つの形態として、任意の値Ｒは、０〜Ｗ等のある特定の間の中で選定される。ブロック５４０の工程で、検証者側プラットフォームは値Ｓ、Ｔ及び
Ｓ＝Ｂ_０ ^ＲｍｏｄＰ及びＴ＝Ｋ_０ ^ＲｍｏｄＰ （１）
を満たすＲが存在する証明を証明者側プラットフォームから受信する。

１つの形態では、Ｒの存在を示す受信した証明はゼロ知識証明の形式でも良い。二つのペア（Ｓ，Ｂ_０）及び（Ｔ，Ｋ_０）を提供するそのようなゼロ知識証明の１つの形態は、図８に示したものと同一の離散対数を有する。ブロック５５０の工程において、検証者側プラットフォームは
Ｕ＝Ｓ^ＦｍｏｄＰ及びＫ＝Ｂ^ＦｍｏｄＰ （２）
を満たすＦが存在する証明を受信する。

繰り返しになるが、値Ｆが存在する証明はゼロ知識証明を用いることで行っても良い。２つのペア（Ｕ，Ｓ）及び（Ｋ，Ｂ）を提供するそのようなゼロ知識証明の１つの形態は、図８に示したものと同一の離散対数を備える。

したがって、検証者側プラットフォームが値Ｒ及びＦの存在を確証するとただちに、検証者側プラットフォームはＵ及びＴの値を調べる。Ｕ＝ＴｍｏｄＰの場合、検証者は証明者側のプラットフォーム鍵Ｆが未知の疑わしい鍵Ｆ_０に等しいことを知る。
Ｕ≠ＴｍｏｄＰ （３）
の場合、検証者は証明者側プラットフォーム鍵Ｆが未知の疑わしい鍵Ｆ_０に等しくないことを知る。これは、Ｂ_０ ^ＲＦ＝Ｓ^Ｆ＝ＵｍｏｄＰ及びＢ_０ ^ＲＦ０＝Ｋ_０ ^Ｒ＝ＴｍｏｄＰであることから容易に分かる。よって、Ｆ＝Ｆ_０ｍｏｄｎである場合だけＵ＝ＴｍｏｄＰとなる。

Ｕ≠ＴｍｏｄＰである場合、証明者側のプラットフォーム鍵Ｆは未知の疑わしい鍵Ｆ_０に等しくない。よって、ブロック５７０の工程において、検証者は証明者側署名鍵Ｆが疑わしい直接証明署名を生成することに用いられたことの否定、ここでは「直接証明署名否定の提供」と表すが、を受信する。そうではなく、Ｕ＝ＴｍｏｄＰの場合、検証者側プラットフォームは証明者側プラットフォームが本当に、直接証明署名において信用できない鍵Ｆ_０を用いたことの確証を受信する。

１つの形態では、証明者側プラットフォームは、標準的なゼロ知識証明を用いることによって、証明者側の署名鍵Ｆが疑わしい直接証明署名を形成することに用いられたことを否定する。ここに記したとおり、同一の離散対数を有する二つのペアを提供する標準のゼロ知識証明は以下のとおり行われる。具体的には、整数の組ｋ_１，ｈ_１，ｋ_２，ｈ_２及びモジュールＰが与えられると、ゼロ知識証明はｆについての情報を露呈することなくｋ_１＝ｈ_１ ^ｆｍｏｄｋ_２及びｈ_２ ^ｆ＝Ｗ^ｅｍｏｄＰを満たすｅが存在することを証明できる。

二つの離散対数が同一であることを示すゼロ知識証明の１つの形態は、本願の譲受人によって所有される同時係属出願（ＵＳ出願番号：１０／３０６，３３６）に開示されている。図８はこのゼロ知識証明を表すフロー図６００である。ｆはＺとＺ＋Ｗの間にあるとする（上記の式１の場合、Ｚは０でも良い）。Ｂ＝Ｗ＊２^{Ｓｐ＋ＨＡＳＨ＿Ｌｅｎｇｔｈ}である。ここで、Ｓｐはセキュリティパラメータであり、ＨＡＳＨ＿ｌｅｎｇｔｈはハッシュ関数ＨＡＳＨの出力ビット長である。１つの形態では、Ｓｐとして、以下のとおり算出されたｓの値によってｆについての有用な情報が露呈しないほど十分大きな値、例えばＳｐ＝６０、が選定される。

ブロック６１０の工程において、ＴＰＭは〔０，Ｂ〕の間でｔの値を任意に選定する。Ｐブロック６２０の工程において、ＴＰＭはｊ_１＝ｈ_１ ^ｔｍｏｄＰ及びｊ_２＝ｈ_２ ^ｔｍｏｄＰ算出しても良い。その後ブロック６３０の工程において、ＴＰＭはｒ＝ＨＡＳＨ（ｈ_１，ｋ_１，ｈ_２，ｋ_２，ｊ_１，ｊ_２）を算出しても良い。ブロック６４０の工程において、ＴＰＭはｓ＝Ｚ＋ｔ−ｆ＊ｒを算出しても良い。最後に、ブロック６５０の工程において、ＴＰＭはｓ，ｈ_１，ｋ_１，ｈ_２，ｋ_２，ｊ_１及びｊ_２を検証者に送っても良い。１つの形態において、検証者はその後、証明を検証しても良い。

図９は、１つの形態において、二つの離散対数が同一であることの証明の検証を概念的に示すフロー図７００である。ブロック７１０の工程において、チャレンジャはｒ＝ＨＡＳＨ（ｈ_１，ｋ_１，ｈ_２，ｋ_２，ｊ_１，ｊ_２）を算出しても良い。その後ブロック７２０の工程において、チャレンジャは、ｊ_１＊ｈ_１ ^Ｚ＝ｋ_１ ^ｒ＊ｈ_１ ^ｓｍｏｄＰ及びｊ_２＊ｈ_２ ^Ｚ＝ｋ_２ ^ｒ＊ｈ_２ ^ｓｍｏｄＰであることを調べても良い。ブロック７２０の検査をパスした場合、チャレンジャはブロック７３０の工程において証明を受理しても良い。

図１０は、鍵検証リクエストの受信に応じて、証明者側プラットフォームによって実行される方法６００を示すフロー図である。ここに記すとおり、検証者側プラットフォームはハードウェアデバイス内に格納された暗号鍵の存在を確証するとすぐに、格納された暗号鍵が信用できることを検証しても良い。１つの形態では、そのような機能は、図２及び３で示したＴＰＭ２２０における認証ロジック２４０内の鍵検証ロジック２６０によって提供される。典型的には、ブロック８１０の工程において、証明者側プラットフォームは署名拒否リクエストが受信さえたかどうかを特定しても良い。署名拒否リクエストを受信するとただちに、ブロック６２０〜６７０の工程に示した機能が実行される。

ブロック８２０の工程において、検証側プラットフォームは未知の疑わしい鍵Ｆ_０を伴う証明において受信した疑わしい署名（疑わしい直接証明署名）が有するベースＢ_０及びスードニムＫ_０を受信する。ブロック８３０の工程において、証明者側プラットフォームは算出した値Ｓ＝Ｂ_Ｏ ^ＲｍｏｄＰ、Ｔ＝Ｋ_Ｏ ^ＲｍｏｄＰ、Ｕ＝Ｂ_Ｏ ^ＲＦｍｏｄＰ及びＫ＝Ｂ^ＦｍｏｄＰを検証者に転送する。ブロック８４０の工程において、証明者はＳ＝Ｂ_Ｏ ^ＲｍｏｄＰａｎｄＴ＝Ｋ_Ｏ ^ＲｍｏｄＰを満たす値Ｒが存在する証明を検証者側プラットフォームに送る。ブロック８５０の工程において、証明者側プラットフォームはＵ＝Ｓ^ＦｍｏｄＰ及びＫ＝Ｂ^ＦｍｏｄＰを満たすＦが存在することを検証者側プラットフォームに確証させる目的で、検証者側プラットフォームに直接証明を転送する。

上記のとおり、１つの形態では、証明は図８で示したゼロ知識証明に準じて実行される。同様に、上記のとおり、ブロック８６０において式（３）を満たす場合、証明者鍵Ｆは未知の疑わしい鍵Ｆ_０と等しくなく、ブロック８７０の工程が実行される。ブロック８７０の工程において、証明者はその疑わしい直接証明署名が証明者側プラットフォームの署名鍵Ｆを伴って生成されたことを否定する。そうではなく、式（３）を満たさない場合は、証明者鍵Ｆは未知の疑わしい鍵Ｆ_０に等しい。その結果、証明者側プラットフォームは疑わしい直接証明署名の否定の立証に達しない。よって証明者側プラットフォームが信用できない鍵を用いている理由で、検証者側プラットフォームは証明者側プラットフォームの認証を行わない。

その結果、１つの形態では、上記の名前ベースオプションに対するセキュリティ能力が高まる。しかしながら、１つの形態では、検証側プラットフォームは過去に受信した全ての署名を証明者側プラットフォームに送ることを禁じられる。すなわち、証明者側プラットフォームに過去に受信した全ての署名を送ることによって、過去に署名を送った証明者側プラットフォームはそれぞれの署名を特定することを要求される。その結果、検証者側プラットフォームは証明者側プラットフォームから受信した過去の全ての署名を関連付けることができる。１つの形態として、幾つかの方法が、ここに記した１つ以上の形態で示した無効機能の乱用を防ぐ目的で行われる。

１つの形態として、証明者側プラットフォームは、検証者が拒否できる署名の数の制限を行う機能を内蔵しても良い。これは、削除された鍵を所有している信用できないデバイスの割合はごく僅かなので合理的な方法である。しかしながら、制限された数以上が信用できなくなった場合、１つの形態では、デバイスは鍵を変更（リキー）されても良い。デバイスは、自分が信用できないデバイスでないことを証明した後に初めてリキーされても良い。他の方法では、無効オーソリティの１つ以上の公開鍵（公開鍵のハッシュ）をデバイスが備えても良い。従って、これらの無効オーソリティの１つによって拒否リクエストが容認された場合に、検証者側プラットフォームは署名拒否を与えても良い。この容認は無効オーソリティサイン署名拒否リクエスト、具体的には署名ペア（Ｂ_０，Ｋ_０）を所有することで示される。

他の方法として、検証者が署名を要求したとき、検証者は無効識別子を与える。１つの形態として、会員が無効識別子を与えられたとき、証明者側プラットフォームは同一の無効識別子含む、署名拒否リクエストを制限しても良い。無効識別子はＢの値の下位ビット、例えば下位４０ビットによって示されても良い。検証者はこれらのＢの下位ビットを示しても良い。証明者はこれらのＢの下位ビットを用いても良く、Ｂの残りのビットを任意に選定しても良い。証明者は、その後署名否定を提供しても良い。そこではＢ_０はこれらの下位ビットと一致している。このような方法で、検証者側プラットフォームはグループに分けられ、そこでは、二つの検証者が同一の無効識別子を用いている場合、二つの検証者は同一のグループに置かれる。グループ内では、ある検証者は他の検証者に会員鍵を拒絶することを通知しても良い。しかし、そのグループの外側の検証者に会員鍵を拒絶することを通知することはできない。１つの形態として、この方法において、発行される署名拒否リクエストの数を制限しても良い。

過去の出願は、直接証明において、非双方向性である方法も開示している。更に、直接方法を行う目的で発見された他の方法も存在する。これらの１つは、Ｂｒｉｃｋｅｌｌ、Ｂｏｎｅｈ、Ｃｈｅｎ及びＳｈａｃｈａｍによって発表されたセット署名（ｓｅｔ ｓｉｇｎａｔｕｒｅｓ）と呼ばれる方法である。又、他の１つは、Ｂｒｉｃｋｅｌｌ、Ｃａｍｅｎｉｓｃｈ及びＣｈｅｎによって発表された直接匿名証明（Ｄｉｒｅｃｔ Ａｎｏｎｙｍｏｕｓ Ａｔｔｅｓｔａｔｉｏｎ）と呼ばれる方法である。これらの方法は、署名又は双方向証明の生成の過程で、整数Ｑを伴う整数モジュールＱなどの有限郡におけるスードニムｋ＝Ｂ^ｆを会員が生成するランダムベースオプションを有する特性を持つ。従って、本発明の署名否定を提供する方法は、これらの署名又は双方向性方法にも適用できる。

幾つかの実施形態及びベストモードを開示してきたが、以下の請求項で述べられた発明の形態の範囲を逸脱しない範囲において、これら開示された実施形態に対して変更及び改良を行っても良い。

Claims (40)

1. ハードウェアデバイスが暗号情報を所有していることを、暗号情報又は前記ハードウェアデバイスの固有のデバイス認証情報を露呈することなく、検証者に確証させる工程と、
   前記暗号情報が信用できることを、前記検証者に確証させる工程とを含む方法。
2. 前記ハードウェアデバイスが前記暗号情報を所有していることを、前記検証者に確証させる前記工程は、
   暗号鍵が前記ハードウェアデバイス内に格納されていることを証明する目的で、前記ハードウェアデバイスによって直接認証を行う工程を含み、
   直接認証は複数の累乗法を含み、前記累乗法の少なくとも１つは、暗号鍵を露呈することなく、前記ハードウェアデバイスの前記暗号鍵を指数として用いる事によって実行される請求項１に記載の方法。
3. 前記ハードウェアデバイスが前記暗号情報を所有していることを、前記検証者に確証させる前記工程は、
   スードニムＫを算出する目的で、前記暗号情報を用いる工程と、
   前記スードニムＫを前記検証者に提供する工程とを含む請求項１に記載の方法。
4. 前記暗号情報が信用できることを前記検証者に確証させる工程は、
   疑わしい署名が有するベース値Ｂ_０及びスードニム値Ｋ_０を含む署名拒否リクエストを前記検証者から受信する工程と、
   前記スードニムＫを生成する目的で用いられた、ハードウェアデバイスに格納された暗号鍵が、前記疑わしい署名を形成する目的で用いられた、未知の疑わしい鍵Ｆ_０と一致しないことを前記検証者に確証させる工程とを含む請求項３に記載の方法。
5. 前記暗号情報が信用できることを前記検証者に確証させる工程は、
   任意の指数値Ｒを選定する工程と、
   前記検証者から受信した疑わしいベース値Ｂ_０及び疑わしいスードニム値Ｋ_０、前記ハードウェアデバイスのモジュール値Ｐ、及び前記任意の指数値Ｒに応じて算出された１つ以上の値を前記検証者に転送する工程と、
   前記ハードウェアデバイス内に格納された暗号鍵Ｆが疑わしい直接証明署名を生成することに用いられたことを否定する目的で、前記ハードウェアデバイスによって証明を行う工程とを含み、
   前記証明は複数の累乗法を含み、前記累乗法のそれぞれは、暗号鍵Ｆ、前記任意の指数値Ｒ、及び他の任意の指数値を露呈することなく、前記暗号鍵Ｆ、前記任意の指数値Ｒ、及び前記他の任意の指数値の中の１つを指数として用いることで実行される請求項１に記載の方法。
6. 前記証明を行う工程は、
   Ｓ＝Ｂ_０ ^ＲｍｏｄＰ及びＴ＝Ｋ_０ ^ＲｍｏｄＰを満たす値Ｒが存在することを、Ｒに関する有用な情報を露呈することなく、前記検証者に確証させる工程と、
   Ｕ＝Ｓ^ＦｍｏｄＰ及びＫ＝Ｂ^ＦｍｏｄＰを満たす値Ｆが存在することを、Ｆに関する有用な情報を露呈することなく、前記検証者に確証させる工程とを含む請求項５に記載の方法。
7. 前記検証者は、Ｕ(ＴｍｏｄＰである場合に、前記ハードウェアデバイス内に格納された前記暗号鍵Ｆが前記疑わしい直接証明署名を生成することに用いられなかったと確証する請求項５に記載の方法。
8. 前記暗号情報が信用できることを前記検証者に確証させる工程は、疑わしい署名が有する疑わしいベース値Ｂ_０及び疑わしいスードニム値Ｋ_０を含む署名拒否リクエストを前記検証者から受信する工程と、
   前記疑わしい署名と関連する無効識別子を疑わしい無効識別子として受信する工程と、
   前記疑わしい無効識別子が前記検証者からの署名リクエストに伴って受信した無効識別子と一致する場合に、前記ハードウェアデバイス内に格納された暗号鍵Ｆが、前記未知の疑わしい鍵Ｆ_０と一致していることを否定する目的で、前記ハードウェアデバイスによって直接証明を実行する工程とを含む請求項１に記載の方法。
9. 前記暗号情報が信用できることを前記検証者に確証させる工程は、
   （ａ）少なくとも１つの疑わしい直接証明署名を含む、署名拒否リクエストを前記検証者から受信する工程と、
   （ｂ）前記ハードウェアデバイス内に格納された１つ以上の無効オーソリティが有する１つ以上の公開鍵に従って、前記署名拒否リクエストが所定の無効オーソリティによって承認されたかどうかを判定する工程と、
   （ｃ）前記リクエストが所定の無効オーソリティによって署名された場合、
   前記ハードウェアデバイス内に格納された暗号鍵が、前記疑わしい直接証明署名を形成すべく、前記検証者による直接証明において用いられたことを否定する目的で、直接証明を実行する工程とを含む請求項１に記載の方法。
10. 複数の疑わしい直接証明署名に対して、（ａ）〜（ｃ）の工程を繰り返す工程と、
    複数の疑わしい直接証明署名が、疑わしい直接証明署名制限値を超えた場合に、
    前記検証者が前記疑わしい直接証明署名制限値を超えたことを前記検証者に通知する
    工程とを更に含む請求項８に記載の方法。
11. ハードウェアデバイスの固有のデバイス識別情報を露呈することなく、前記ハード
    ウェアデバイスが暗号情報を所有していることを検証する工程と、
    前記ハードウェアデバイスの暗号鍵が、検証者に所有された少なくとも１つの疑わし
    い署名を生成する目的で用いられなかったことを検証する工程とを含み、
    前記ハードウェアデバイスの固有のデバイス識別情報は特定できず、前記疑わしい署名を生成することに用いられた疑わしい鍵は、前記検証者にとって未知である方法。
12. 前記ハードウェアデバイスは暗号情報を所有していることを検証する前に、
    前記検証者の信用できない内容物を検出する工程と、
    前記信用できない内容物を受信する目的で用いられる疑わしい直接証明署名が有するベースＢ_０及びスードニムＫ_０を特定する工程と、
    前記ベースＢ_０及びスードニムＫ_０を未知の疑わしい鍵Ｆ_０を伴って生成された疑わしい直接証明署名として保存する工程とを含む請求項１１に記載の方法。
13. 前記ハードウェアデバイスが暗号情報を所有していることを検証する工程は、
    暗号鍵が前記ハードウェアデバイス内に格納されていることを検証する目的で、前記ハードウェアから証明を受信する工程を含み、
    前記証明は複数の累乗法を含み、前記累乗法の少なくとも１つは、前記暗号鍵を露呈することなく、前記暗号鍵を指数として用いることで実行される請求項１１に記載の方法。
14. 前記ハードウェアデバイスが暗号情報を所有していることを検証する工程は、
    前記ハードウェアデバイスによって、前記暗号鍵を用いて、スードニムＫを算出する工程と、
    前記ハードウェアデバイスから前記スードニムＫを受信する工程とを含む請求項１１に記載の方法。
15. 前記暗号鍵が前記疑わしい署名を生成する目的で用いられていないことを検証する工程は、
    未知の疑わしい鍵Ｆ_０、ベースＢ_０及びスードニムＫ_０を伴って生成され、関連付けられた無効識別子を有する疑わしい直接証明署名のベースＢ_０及びスードニムＫ_０を含む署名拒否リクエストを前記ハードウェアデバイスに提供する工程と、
    デジタル署名リクエスト中に、前記ハードウェアデバイスに提供された無効識別子が
    前記疑わしい直接証明署名に関連付けられた無効識別子に一致している場合に、
    前記スードニムＫを構成することに用いられた前記ハードウェアデバイスの暗号鍵Ｆが、前記疑わしく信用できない鍵Ｆ_０と一致しないことを前記検証者に確証させる目的で、前記ハードウェアデバイスから直接証明を受信する工程とを含む請求項１４に記載の方法。
16. 前記暗号鍵が前記疑わしい署名を生成する目的で用いられていないことを検証する工程は、
    （ａ）未知の疑わしい鍵Ｆ_０を伴って形成される疑わしい署名が有するベースＢ_０及びスードニムＫ_０を含む署名拒否リクエストを前記ハードウェアデバイスに提供する工程と
    （ｂ）前記ハードウェアデバイスの暗号鍵Ｆの識別を行わずに、前記ハードウェアデバイスの前記暗号鍵Ｆが前記疑わしく信用できない鍵Ｆ_０と一致しないことを検証する工程とを含む請求項１１に記載の方法。
17. 前記証明を行う工程は、
    Ｓ＝Ｂ_０ ^ＲｍｏｄＰ及びＴ＝Ｋ_０ ^ＲｍｏｄＰを満たす値Ｒが存在するとの証明を、Ｒに関する有用な情報を特定せずに、前記ハードウェアデバイスから受信する工程と、
    Ｕ＝Ｓ^ＦｍｏｄＰ及びＫ＝Ｂ^ＦｍｏｄＰを満たす値Ｆが存在するとの証明を、Ｆに関する有用な情報を特定せずに、前記ハードウェアデバイスから受信する工程と、
    Ｕ(ＴｍｏｄＰである場合に、前記ハードウェアデバイスの前記暗号鍵Ｆが信用できると特定する工程とを更に含む請求項１６に記載の方法。
18. Ｕ＝ＴｍｏｄＰである場合に、前記ハードウェアデバイスの前記暗号鍵Ｆが信用できないと特定する工程を更に含む請求項１７に記載の方法。
19. 所定の数の疑わしい直接証明署名に対して、（ａ）及び（ｂ）の工程を繰り返す工程と、
    前記所定の数が疑わしい直接証明署名制限値を超えた場合に、前記ハードウェアデバイスの認証製造者によって規定されたプラットフォーム・ファミリの会員であるハードウェアデバイスをリキーする工程とを更に含む請求項１６に記載の方法。
20. 前記ハードウェアデバイスが暗号情報を所有していることを検証する工程は、
    前記ハードウェアデバイスの検証者無効識別子を含んだ署名リクエストを前記ハードウェアデバイスに転送する工程と、
    前記無効識別子を含んだ前記ハードウェアデバイスのデジタル署名を受信する工程と、
    前記ハードウェアデバイスの製造者の公開鍵に従って、前記ハードウェアデバイスの前記デジタル署名を認証する工程とを含む請求項１１に記載の方法。
21. 認証製造者からの暗号情報を格納するフラッシュメモリと、
    前記暗号情報又は前記ハードウェアデバイスの固有のデバイス認証情報を露呈することなく、ハードウェアデバイスが認証製造者からの前記暗号情報を所有していること及び前記暗号情報が信用できることを、検証者に確証させるトラステッド・プラットフォーム・モジュールとを含む装置。
22. 前記トラステッド・プラットフォーム・モジュールは、複数の累乗法を含む直接証明に基づいて、暗号鍵が前記ハードウェアデバイス内に格納されていることを証明する認証ロジックを含み、少なくとも１つの累乗法は、前記暗号鍵を露呈することなく、前記暗号鍵を指数として用いて実行される請求項２１に記載の装置。
23. 前記トラステッド・プラットフォーム・モジュールは、
    前記検証者からの疑わしい署名のベース値Ｂ_０及びスードニム値Ｋ_０を含む署名拒否リクエストを受信し、前記ハードウェアデバイス内に格納され、スードニムＫを生成することに用いられる暗号鍵が、前記疑わしい署名を形成する未知の疑わしい鍵Ｆ_０に一致しないことを前記検証者に確証させる署名拒否ロジックを含む請求項２１に記載の装置。
24. 前記トラステッド・プラットフォーム・モジュールは、
    前記装置の認証製造者から固有の秘密ピア（ｃ，Ｆ）を受信する鍵ロジックを含み、
    Ｆはｃ^ｅｍｏｄＰを生成する前記ハードウェアデバイスの署名鍵であり、前記ペア（ｅ，Ｐ）は前記認証製造者の公開鍵である請求項２１に記載の装置。
25. 前記トラステッド・プラットフォーム・モジュールは前記固有の秘密ペア（ｃ，Ｆ）を格納するフラッシュメモリを含む請求項２４に記載の装置。
26. ネットワークに結合する検証者側プラットフォームと、
    前記ネットワークに結合する証明者側プラットフォームとを含むシステムであり、
    バスと、
    前記バスに結合するプロセッサと、
    前記バスに結合するトラステッド・プラットフォーム・モジュールを含むチップセットとを含み、
    前記ネットワーク上から受信されるチャレンジに応じて、前記トラステッド・プラットフォーム・モジュールは、
    暗号情報又はハードウェアデバイスの認証デバイス情報を露呈せずに、前記ハードウェアデバイスが前記暗号情報を所有していること、及び前記暗号情報が信用できることを検証者に確証させるシステム。
27. 前記チップセットはグラフィックコントローラを含む請求項２６に記載のシステム。
28. 前記ネットワークは広域エリアネットワークを含む請求項２６に記載のシステム。
29. 前記トラステッド・プラットフォーム・モジュールは、
    前記検証者からの疑わしい署名のベース値Ｂ_０及びスードニム値Ｋ_０を含む署名拒否リクエストを受信し、前記ハードウェアデバイス内に格納され、スードニムＫを生成することに用いられる暗号鍵が、前記疑わしい署名を形成する未知の疑わしい鍵Ｆ_０に一致しないことを前記検証者に確証させる署名拒否ロジックを含む請求項２６に記載のシステム。
30. 前記トラステッド・プラットフォーム・モジュールは、
    前記装置の認証製造者から固有の秘密ペア（ｃ，Ｆ）を受信する鍵ロジックと
    前記固有の秘密ペア（ｃ，Ｆ）を格納するフラッシュメモリとを含み、
    Ｆはｃ^ｅｍｏｄＰを生成する前記ハードウェアデバイスの署名鍵であり、前記ペア（ｅ，Ｐ）は前記認証製造者の公開鍵である請求項２６に記載の装置。
31. 方法を実行するシステムをプログラムすることに用いられる命令を格納する機械可読メディアを含む製造物品であり、前記方法は、
    暗号情報又はハードウェアデバイスの固有のデバイス認証情報を露呈することなく、前記ハードウェアデバイスが前記暗号情報を所有していることを検証者に確証させる工程と、前記暗号情報が信用できることを前記検証者に確証させる工程とを含む製造物品。
32. ハードウェアデバイスが暗号情報を所有していることを検証者に確証させる工程は、
    スードニムＫを算出する目的で、前記暗号情報を用いる工程と、
    前記検証者に前記スードニムＫを提供する工程とを含む請求項３１に記載の製造物品。
33. 前記暗号鍵が、前記未知の信用できない鍵Ｆ_０と一致しないことを前記検証者に確証させる工程は、
    任意の指数値Ｒを選択する工程と、
    前記ハードウェアデバイスのモジュール値Ｐ、前記任意の指数値Ｒ、前記検証者から受信した前記疑わしいベースＢ_０及び前記疑わしいスードニム値Ｋ_０に従って、前記検証者に１つ以上の算出した値を転送する工程と、
    前記ハードウェアデバイス内に格納された暗号鍵Ｆが、疑わしい直接証明署名を生成することに用いられたことを否定するための証明を前記ハードウェアデバイスによって実行する工程とを含み、
    前記証明は、複数の累乗法を含み、それぞれの累乗法は、前記暗号鍵、前記任意の数値Ｒ及び他の指数値を露呈することなく、前記暗号鍵Ｆ、前記任意の指数値Ｒ及び他の指
    数値の１つを指数値として用いて実行される請求項３１に記載の製造物品。
34. 前記証明を実行する工程は、
    Ｓ＝Ｂ_０ ^ＲｍｏｄＰ及びＴ＝Ｋ_０ ^ＲｍｏｄＰを満たす値Ｒが存在することを、Ｒに関する有用な情報を露呈せずに、前記検証者に確証させる工程と、
    Ｕ＝Ｓ^ＦｍｏｄＰ及びＫ＝Ｂ^ＦｍｏｄＰを満たす値Ｆが存在することを、Ｆに関する有用な情報を露呈せずに、前記検証者に確証させる工程とを含む請求項３３に記載の製造物品。
35. Ｕ≠ＴｍｏｄＰである場合に、前記ハードウェアデバイス内に格納された前記暗号鍵Ｆが前記疑わしい直接証明署名を生成することに用いられなかったことを前記検証者に確証させる請求項３４に記載の製造物品。
36. 方法を実行するシステムをプログラムすることに用いられる命令を格納する機械可読メディアを含む製造物品であり、前記方法は、
    前記ハードウェアデバイスの固有のデバイス認証情報を露呈することなく、ハードウェアデバイスが暗号情報を所有していることを検証する工程と、
    前記ハードウェアデバイスの暗号鍵が、検証者によって所有され、少なくとも１つの疑わしい署名を生成することに用いられなかったことを検証する工程とを含み、
    前記疑わしい署名を生成することに用いられた疑わしい鍵は前記検証者に未知である製造物品。
37. 前記ハードウェアデバイスが暗号情報を所有していることを検証する工程は、
    暗号鍵が前記ハードウェアデバイス内に格納されていることを検証する証明を前記ハードウェアデバイスから受信する工程を含み、
    前記証明は複数の累乗法を含み、前記累乗法の少なくとも１つは、前記暗号鍵を露呈することなく、前記暗号鍵を指数として用いることによって実行される請求項３６に記載の製造物品。
38. 前記暗号鍵が前記疑わしい署名を生成することに用いられたことを検証する工程は、
    （ａ）前記ハードウェアデバイスに、未知の疑わしい鍵Ｆ_０によって形成された疑わしい直接証明署名のベース値Ｂ_０及びスードニム値Ｋ_０を含む署名拒否リクエストを提供する工程と、
    （ｂ）前記ハードウェアデバイスの暗号鍵Ｆが前記疑わしい信用できない鍵Ｆ_０に一致しない事を、前記ハードウェアデバイスの前記暗号鍵Ｆの認証を行わずに、検証する請求項３６に記載の製造物品。
39. 前記検証する工程は、
    Ｓ＝Ｂ_０ ^ＲｍｏｄＰ及びＴ＝Ｋ_０ ^ＲｍｏｄＰを満たす値Ｒが存在するとの直接証明を、Ｒに関する有用な情報の認証を行わずに、前記ハードウェアデバイスから受信する工程と、
    Ｕ＝Ｓ^ＦｍｏｄＰ及びＫ＝Ｂ^ＦｍｏｄＰを満たす値Ｆが存在するとの直接証明を、
    Ｆに関する有用な情報の認証を行わずに、前記ハードウェアデバイスから受信する工程と、
    Ｕ≠ＴｍｏｄＰである場合に、前記ハードウェアデバイスの前記暗号鍵を信用できるものとして認証する工程とを含む請求項３８に記載の製造物品。
40. Ｕ＝ＴｍｏｄＰである場合に、前記ハードウェアデバイスの前記暗号鍵Ｆが信用できないと特定する工程を更に含む請求項３９に記載の製造物品。

Images