JP2013509805A - 一往復での鍵証明 - Google Patents

Abstract

認証機関（ＣＡ）と、証明書を要求するクライアントとの間における１回の往復で、鍵の証明を行い、トラステッド・プラットフォーム・モジュール（ＴＰＭ）が移行不可であることを明らかにすることができる。クライアントは、証明要求を作り、次いで、証明書要求に結び付けられたＴＰＭに証明識別鍵（ＡＩＫ）を作らせる。次いで、クライアントは、移行不可であることの証明として、新たな鍵に署名するようにＴＰＭに要求する。次いで、クライアントは証明書要求を、移行不可であることの証明と共に、ＣＡに送る。ＣＡは、証明書要求および移行不可であることの証明を調べる。しかしながら、ＣＡは、この証明が信頼されているＴＰＭによって行われたのか否か知らないので、鍵を証明するが、証明書の中に暗号化された署名を含ませる。この署名は、信頼されているＴＰＭの裏書き鍵を使用しなければ、解読することができない。
【選択図】図１

Description

従来技術

[0001] 暗号鍵の使用には、信頼が必要になる。ＡがＢの鍵でデーターを暗号化するとき、Ａは、Ｂだけがこのデーターを解読できると考えている。そして、ＡがＢの鍵で作られた署名を検証するとき、Ａは有効な署名の存在を期待するが、これはＢが実際に署名が計算されたデーターに署名したことを意味する。したがって、ＡがＢの鍵を用いるとき、Ｂの鍵が本当にＢに属することをどのようにしてＡが確信することができるのか、そしてＢの鍵が危険に晒されていないことをどのようにしてＡが確信することができるのか知りたいというのは、Ａにとって正当なことである。

[0002] 鍵における信頼は、一般に、証明書によって作られる。あるエンティティが鍵を作るとき、このエンティティはこの鍵を証明のために機関に出す。機関は、この鍵およびその所有者が証明に対する機関の標準を満たすか否か判断する。満たす場合、機関はこの鍵に対して証明書を発行する。この証明書は、機関によって署名された鍵を含む。機関とは、これらがサーブする共同体に知られているエンティティであり、共同体が他のエンティティの鍵を証明することを委託するエンティティである。認識されている機関が鍵を証明した場合、この機関に委託した共同体は、証明された鍵を信頼する。例えば、ブラウザーは定期的に機関の更新リストを受け取り、そしてブラウザーは、このリスト上にある機関によって発行された証明書を信頼する。組織（例えば、会社）は、その組織内にある装置によって認識されそして信頼されている認証機関を有することができる。

[0003] トラステッド・プラットフォーム・モジュール（ＴＰＭ）とは、装置に対して種々の形態のセキュリティーを提供するために用いることができる１つのハードウェア・ユニットである。ＴＰＭができることの１つは、鍵を基にハードウェア・セキュリティーを維持することによって、この鍵が悪用されることはないであろうという高い保証尺度を与えることである。場合によっては、認証機関は、特定のＴＰＭに結び付けられている鍵のみを証明しようとすることもある。何故なら、この結びつきが、その特定のＴＰＭを含む装置においてのみ、その鍵が使用されることを保証するからである。したがって、このような鍵を証明するために、認証機関は、鍵が特定の装置においてＴＰＭに実際に結び付けられており、他の装置に移ることができないことを検証しなければならない。通常、このような鍵を証明するプロセスでは、認証機関と、鍵を証明することを要求しているクライアントとの間には、数回の往復交換を伴う。クライアントが、このクライアントのＴＰＭによって安全確保されている新たな移行不可鍵(non-migratable key)を証明したいとき、このクライアントは、ＴＰＭがこの新しい鍵に対して証明識別鍵（ＡＩＫ：Attestation Identity Key)と呼ばれる鍵を作ることを要求する。次いで、クライアントは認証機関にＡＩＫを証明することを要求する。この認証機関は、ＡＩＫがクライアントの装置においてＴＰＭによって実際に生成されたことを検証した後に、これを行う。次いで、クライアントは、新たな鍵にＡＩＫで署名することをＴＰＭに要求する。ＴＰＭは、鍵が移行不可である場合にのみこれを行う。次いで、クライアントは、この新たな鍵およびＡＩＫ生成署名を認証機関に出す。認証機関はＴＰＭを信頼し、ＡＩＫがＴＰＭに属することを証明している。したがって、認証機関は、ＡＩＫで署名されているＴＰＭに基づいて、新たな鍵が移行不可であることを信頼するので、認証機関は新たな鍵に対して証明書を発行する。

[0004] しかしながら、このプロセスに伴う１つの問題は、クライアントと認証機関との間に複数回の往復が必要となることである。つまり、ＡＩＫを証明するために１往復、そしてクライアントが証明しようとしている新たな鍵を証明するために１往復が必要となる。

[0005] 移行不可鍵は、認証機関と、鍵を要求しているクライアントとの間における１回の往復において証明することができる。ＴＰＭを有する装置において、クライアントはＴＰＭに新たな移行不可鍵（例えば、ＲＳＡ鍵対）を作ることを要求する。すると、ＴＰＭは鍵を作り、新たな鍵の公開部分をクライアントに供給する。次いで、クライアントは、この新たな鍵に対する証明書要求を作り、証明書要求のタイジェストに結び付けられている証明識別鍵（ＡＩＫ）を作ることをＴＰＭに要求する。ＴＰＭは、ＡＩＫを作り、ＡＩＫの公開部分、ダイジェスト、ならびにＡＩＫの公開部分およびダイジェスト双方に引き継がれた署名を含む識別結合(identity binding)を返す。次いで、クライアントは、新たな鍵が移行不可であることの指示として、ＡＩＫを使用して新たな鍵の公開部分に署名するように、ＴＰＭに要求する。ＴＰＭは、新たな鍵の公開部分に署名し、新たな鍵と、この新たな鍵が移行不可であることのＴＰＭのステートメント、およびＡＩＫの秘密部分で作られた署名を含む鍵証明構造を返す。次いで、クライアントは認証機関に、証明書要求、識別結合、鍵証明構造、およびＴＰＭの裏書き鍵の公開鍵証明書を送る。（裏書き鍵とは、特定のＴＰＭを識別する、各ＴＰＭが有する鍵である）。

[0006] 認証機関がこれらの品目をクライアントから受け取ると、ＴＰＭ裏書き鍵の公開鍵証明書を調べて、その裏書き鍵と関連のあるＴＰＭが、認証機関が知っており信頼しているＴＰＭであることを検証する。次いで、認証機関は、証明書を調べて、クライアントが証明することを要求している新たな鍵を復元する。次いで、認証機関は、証明書結合における署名を検証し、証明書要求のダイジェストを計算し、計算したダイジェストを、識別結合に含まれているダイジェストと比較して、２つのダイジェストが一致することを確認する。ダイジェストが一致し、そして識別結合における署名が有効である場合、これらの事実は、識別結合において述べられているＡＩＫが、認証機関が受け取った証明書要求に対して特定的に作られたことを証明する。ダイジェストが一致し、識別結合における署名が正しく検証されたと仮定すると、認証機関は鍵証明構造を調べ、この構造における署名を検証する。鍵証明構造は、ＡＩＫの秘密部分を所持する当事者によって作られたステートメント(statement)を表し、この構造に含まれている新たな鍵は移行不可であることを示す。つまり、鍵証明構造が、証明書要求の中にあるのと同じ鍵をあげる場合、そして署名が検証された場合、認証機関は、ＡＩＫの秘密部分を所有する当事者が、この鍵は移行不可であると言ったことが分かる。

[0007] この時点で、認証機関は新たな鍵に対して証明書を作り、この証明書に署名する。しかし、この証明書にクリア(clear)署名を含ませる代わりに、認証機関は対称鍵を作り、この対称鍵で署名を暗号化する。次いで、認証機関は、証明書要求と共に受け取った公開裏書き鍵で対称鍵を暗号化し、この証明書を（対称鍵で暗号化された署名がある）を、ＴＰＭの公開裏書き鍵で暗号化された対称鍵と共にクライアントに送る。認証機関が、ＴＰＭ裏書き鍵に対する公開鍵証明書を受け取ると、その裏書き鍵と関連のある特定のＴＰＭを信頼することを決定する。クライアントが実行している装置にそのＴＰＭが存在する限り（異なる裏書き鍵がある他の何らかのＴＰＭではなくて）、クライアントは、最初にその裏書き鍵を使用して対称鍵を解読することをＴＰＭに要求し、次いでこの対称鍵を使用して署名を解読することによって、証明書における署名を解読することができる。クライアントが、暗号化された署名をクリア署名と置き換えると、証明書は使用可能になる。異なるＴＰＭがクライアントに存在する場合（例えば、認証機関によって信頼されていないＴＰＭ）、ＴＰＭは対称鍵を解読することができない。何故なら、対称鍵が暗号化された裏書き鍵を有していないからである。その場合、クライアントは署名を解読することができず、証明書は使用することができない。

[0008] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを簡略化した形態で紹介するために設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために使用されることを意図するのでもない。

図１は、認証機関が鍵を証明することをクライアントが要求するときに使用することができる種々のコンポーネントのブロック図である。 図２は、鍵を証明する要求を行い、それに作用することができるプロセス例を纏めた流れ図である。 図３は、鍵を証明する要求を行い、それに作用することができるプロセス例を纏めた流れ図である。 図４は、鍵を証明する要求を行い、それに作用することができるプロセス例を纏めた流れ図である。 図５は、鍵を証明する要求を行い、それに作用することができるプロセス例を纏めた流れ図である。 図６は、識別結合の一例のブロック図である。 図７は、鍵証明構造の一例のブロック図である。 図８は、証明書の一例および暗号化された署名のブロック図である。 図９は、本明細書において説明する主題の実施態様と共に使用することができるコンポーネント例のブロック図である。

[0015] 暗号鍵は、暗号化およびディジタル署名というような、コンピューター・セキュリティーにおいて種々の用途に用いられている。暗号化とは、解読鍵（暗号鍵と同一であってもよく、なくてもよい）を所有する当事者だけがメッセージを解読できるように、暗号鍵でメッセージを暗号化するプロセスである。ディジタル署名は、エンティティ（署名者）がデーター片について断定(assertion)を行うプロセスであり、署名は、この断定が鍵を所有するエンティティによって実際に行われたことの、暗号強度の保証(cryptographic-strength assurance)を与える。

[0016] 暗号化プロセスおよびディジタル署名プロセスは双方共、これらのプロセスに関与する当事者間において暗黙の信頼関係を必要とする。例えば、ＡがＢの鍵でデーターを暗号化するとき、Ａは、（ａ）ＡがＢのものであると信ずる鍵が実際にＢの鍵であること、および（ｂ）Ｂの鍵でデーターを暗号化し暗号化されたデーターを安全でないチャネルで送信しても、暗号化されたデーターが、Ａに容認できないような何らかのやり方で使用されることはないことを暗黙の内に信頼している。例えば、点（ａ）に関して、ＡはＢの鍵を信頼性のないソースから受け取っているかもしれないので、Ｂに属するとＡが信じている鍵が、実際には侵入者の鍵であるかもしれない。また、点（ｂ）に関して、鍵は本当にＢの鍵であるかもしれないが、Ｂは鍵のセキュリティーを危険に晒すような緩いセキュリティー手段を使用するかもしれず、これによって、Ｂの鍵で暗号化されているメッセージを解読することを、侵入者に許してしまう。同様に、Ｂによって署名されたと言われているメッセージをＡが受信したとき（例えば、「事実Ｆは真であり、Ｂが署名した」）、Ａがこのメッセージを信頼する場合、Ａは、メッセージが本当にＢによって署名されたことを暗黙に信頼している（即ち、どの鍵がＢのものであるかＡは本当に知っていること、そしてＢの鍵が危険に晒されていないこと）。加えて、Ａは、Ｂがあるレベルの確信度まで事実Ｆが本当に真であることを検証していなければ、Ｂがメッセージ「事実Ｆは真である」に署名しないことも信頼している。

[0017] 鍵が使用されるとき、鍵の信頼は、一般に、機関に鍵の信頼度(trustworthiness)を明らかにさせる(attest)ことによって確立される。この証明(attestation)は、証明書の形態で表され、これによって機関がこの鍵を信頼できることが分かった指示として、機関が鍵に署名する。勿論、機関の署名に対する信頼性(reliance)は、前述したのと同じ形態の信頼が必要となるが、認証機関は、一般に、信頼が確立されるべき関連共同体には周知であるか、または周知の機関に戻る短い信頼連鎖を伴う。このように、エンティティが署名または暗号化のために鍵を用いることを望む場合、このエンティティは、通例、この鍵をしかるべき認証機関に提示し、この機関に鍵に署名するように要求する。機関は、鍵が十分に信頼できると判断するためには、しかるべきとみなす手段であれば何でも採用する。例えば、機関は、どんな種類のセキュリティー手段を、要求元エンティティが鍵を保護するために使用するか判定することができる（例えば、エンティティがハードウェア保護またはソフトウェア保護のどちらを使用するのか）。機関は、要求側エンティティがどのポリシーを使用して、鍵で何に署名できるのか判断するのか問い合わせることができる。また、機関は、あるタイプのエンティティに対して鍵を証明しようとするだけであってもよい（例えば、機関は、会社または他の企業に対する認証機関であることもでき、その企業において装置によって用いられる鍵を証明しようとするだけでもよい）。機関が、鍵を証明できると判断したとき、その鍵および機関の署名を含む証明書を発行する。Ｘ．５０９証明書は、このような証明書の一例である。

[0018] 装置がその鍵の信頼度を保証するのに役立つことができる１つの方法は、その装置に結び付けられている信頼プラットフォーム・モジュール（ＴＰＭ）を採用することである。ＴＰＭは、そのホスト装置に対してある種の暗号機能を実行するチップである。ホスト装置はこれらの暗号機能を利用して、豊富なセキュリティー・サービスを一揃え提供することができる。例えば、ＴＰＭはデーターを特定の装置実行状態に隠蔽することができるので、その装置が既知の安全状態にあるときにのみ、データーをその装置に提供する。この技法は、多くの場合、ホストにおいて暗号鍵を保護するために用いられる。このような技法では、ホストはＴＰＭを用いて鍵を隠蔽し、隠蔽された鍵だけが装置のディスク・ドライブに格納される。ホストがこの鍵を使用したいとき、ホストはＴＰＭに鍵の隠蔽を解除するように要求する。これは、鍵が隠蔽された実行状態に装置があるときでなければ、ＴＰＭは実行できない。この実行状態（通例、プラットフォーム構成レジスター、即ち、「ＰＣＲ」の特定値によって表される）は、鍵の誤用に対して十分な保証を与える安全なものであることが既に検証されている。ＴＰＭが鍵に対してセキュリティーを提供する他の方法は、鍵対を生成し、この鍵対のうち公開部分のみをホストに供給して、この鍵対を必要とする全ての秘密鍵動作がＴＰＭの内部で行われるようにすることである。ＴＰＭは、このような鍵に関して種々の保証を与えることができる。例えば、ＴＰＭは、ＴＰＭを離れていない鍵は移行不可鍵であることを保証することができる（即ち、この鍵は、鍵を隠蔽した特定のＴＰＭを採用するもの以外では、いずれのプラットフォームにおいても用いることができない）。

[0019] 移行不可鍵はＴＰＭによって安全が確保されているので、この鍵は、侵入者によって悪用されそうにないこと、そしてホスト・プラットフォームにおいてマルウェアによって誤用されそうにないという意味で、非常に信頼できる。この信頼度を関連共同体の会員に確立するために、ホスト・プラットフォームはこの移行不可鍵を機関に提示し、機関がこの鍵を、信頼度の指示として、証明することを要求することができる。しかしながら、この証明を得るときに問題が発生する。具体的には、このような鍵に対して証明書を発行する前に、認証機関は、署名を求めて提示された鍵が実際にＴＰＭによって安全確保されていることを確認しなければならない。例えば、ホスト機関は、移行不可鍵を有することを請求することもできる。しかしながら、鍵が移行不可であることを証明する前では、認証機関は、単にホストがそう言うのではなく、鍵が移行不可であるとＴＰＭが言うことを主張する。

[0020] 「この鍵は移行不可です」というようなステートメントは、一般に、信頼されているエンティティの署名状態によって作られる。ＴＰＭは、「裏書き鍵」（「ＥＫ」と呼ばれ、その公開部分および秘密部分は、それぞれ、「ＥＫ−公開」および「ＥＫ−秘密」と呼ぶことができる）と呼ばれる鍵対を有する。所与のＴＰＭの裏書き鍵は、そのＴＰＭを他のＴＰＭから区別する。ＴＰＭの公開ＥＫは、その特定のＴＰＭを信頼する認証機関に知られている。例えば、ある会社が、認証機関として機能するようにサーバーを動作させることができ、そのサーバーは、この会社が所有する全てのラップトップに対するＥＫを知ることができる。このように、ホスト・プラットフォームが鍵を作り、この鍵がＴＰＭによって隠蔽された場合、理論的には、ＴＰＭはＥＫを使用して、ＴＰＭがこの鍵が安全であることを信じる指示として、この鍵に署名することができる。認証機関は、それが知っており信頼しているＴＰＭの公開ＥＫを知っているので、認証機関は、署名を使用して、鍵が移行不可であることを信頼されているＴＰＭが既に明らかにしたことを検証することができ、認証機関は、それに基づいて鍵に証明書を発行することができる。しかしながら、実際には、ＴＰＭは、それが任意のデーターにＥＫで署名することを防止するポリシーを有する。このため、ＴＰＭは、通例、他の鍵を作るためにＥＫを使用し、ＴＰＭはこれらの鍵を使用してデーターに署名する。このような「他の鍵」の一例に、証明識別鍵（ＡＩＫ）があり、ＴＰＭはこれを使用して他の鍵に署名する。

[0021] 通例、ＡＩＫは、以下のようにして、鍵の証明書を得るために使用される。ホスト・プラットフォームにおけるソフトウェアが、ＴＰＭに新たな鍵対を作ることを要求し、このソフトウェアは公開部分を受け取る。次いで、このソフトウェアは、新たな鍵の公開部分に結び付けられているＡＩＫを作ることをＴＰＭに要求し、次いで、認証機関（「ＣＡ」）がＡＩＫの公開部分（即ち、「ＡＩＫ−公開」）に署名することを要求する。このプロセスの間、ＣＡは、この要求が実際にそれを信頼するＴＰＭから来たことを検証する。例えば、ＣＡは、ノンスを使用することによって、それ自体とＴＰＭとの間における通信チャネルのセキュリティーを検証することができる。一旦ＡＩＫに署名する要求が、ＣＡが信頼するＴＰＭから来たことをＣＡが納得したなら、ＣＡはＡＩＫ−公開に署名し、証明書をホスト・プラットフォームに戻す。次いで、ホスト・プラとフォームは新たな鍵を生成し、ＴＰＭがＡＩＫの秘密部分（「ＡＩＫ−秘密」）を使用して新たな鍵に署名することを要求する。ＡＩＫを使用して新たな鍵に署名することは、ＴＰＭが新たな鍵について作った何らかのステートメントを表すことができる。例えば、ＡＩＫで新たな鍵に署名することは、ＴＰＭが、新たな鍵が移行不可であることを断言したことを示すことができる。次いで、ホストはＣＡに新たな鍵、署名、およびＡＩＫのＣＡの証明書、およびＣＡが新たな鍵に署名することの要求を提示する。ＣＡはＡＩＫ−公開を使用して、新たな鍵における署名を検証し、ＡＩＫ−公開の証明書を使用して、ＡＩＫにおける信頼が既に確立されていることを検証する。次いで、ＣＡは新たな証明書を発行し、それをホストに戻す。

[0022] 以上の手順に発生する問題は、ＣＡに対して複数の往復を使用することである。即ち、ＡＩＫを証明するために１回、そしてＴＰＭがＡＩＫで署名した鍵を証明するためにもう１回である。

[0023] 本明細書において記載する主題は、ＴＰＭのホスト・プラットフォームが、１回の往復でＣＡがＴＰＭ保護鍵を証明することを要求することを可能にする。本明細書において記載する技法は、ＡＩＫを証明するために別の往復を１回使用することを回避する。代わりに、ホスト・プラットフォームにおけるクライアントが、新たな移行不可鍵を作るようにＴＰＭに要求し、ＣＡがＡＩＫを信頼することを最初に確立することなく、新たな鍵を証明することをＣＡに要求する。ＣＡは、鍵を証明することによって応答するが、ＣＡが信頼するＴＰＭを有するホスト次第の証明書を以後使用するようにする。この手順を実行するために、クライアントは、このクライアントが証明させたい新たな鍵を作るように、ＴＰＭに要求する。次いで、クライアントは、証明書要求、即ち、ＣＡに新たな鍵に証明させる要求を作る。実際にこの要求をＣＡに送る前に、クライアントは、証明書要求に結び付けられているＡＩＫを作ることを、ＴＰＭに要求する。ＴＰＭは、識別結合を作ることによって応答する。この識別結合は、ＡＩＫの公開部分、証明書要求のダイジェスト、および署名を含む。次いで、クライアントは、新たな鍵に署名することをＴＰＭに要求する。ＴＰＭは、鍵証明構造を作ることによって応答する。この鍵証明構造は、証明すべき鍵、鍵についてのステートメント（例えば、「この鍵は移行不可です」）、およびＡＩＫ−秘密で作られた署名を含む。次に、クライアントは、証明書要求、識別結合、鍵証明構造、およびＴＰＭのＥＫ−公開の証明書をＣＡに伝える。

[0024] 次に、ＣＡはＥＫ−公開の証明書を調べて、ＣＡが信頼するＴＰＭにそれが属することを確認する。次いで、ＣＡは証明書要求を簡約し、そのダイジェストを、識別結合に含まれているダイジェストと比較し、識別結合における署名を検証する。これらのダイジェストが一致し、署名が検証されたと仮定すると、これらの事実から、ＣＡが受け取った証明書要求に対してＡＩＫが作られたことが証明される。次に、ＣＡは、証明書要求から、証明すべき鍵を復元し、それを、鍵証明構造において特定された鍵と比較して、鍵証明書構造が、証明書要求において指定された鍵に関係することを確認する。次いで、ＣＡは鍵証明構造において行われたステートメントを調べて、鍵についてのステートメントが、ＣＡの証明書発行ポリシーと一致することを確認する（例えば、ＣＡのポリシーが移行不可鍵のみを証明することを要求する場合、ＣＡはステートメントが鍵の移行不可であることを明らかにする(attest)ことを検証する。次いで、ＣＡは、鍵証明構造における署名を検証して、その構造に含まれているステートメントが、ＡＩＫ−秘密の保持者によって行われたことを確認する。以上の検証の全てが適正であると仮定すると、ＣＡは、この時点で、ＡＩＫの保持者が新たな鍵が移行不可であることを断言しており、その鍵に対して証明書を要求していることが分かる。

[0025] ＣＡが知らないことは、ＡＩＫが、ＥＫ−公開と関連があり信頼されているＴＰＭと関連があるか否かということである。つまり、ＣＡは、クライアントに、条件付証明書を発行する。証明書は、ＥＫ−秘密（ＣＡから信頼されている）を保持するＴＰＭが、ＡＩＫがそのＴＰＭによって発行されたことを検証した場合のみに用いることができるという意味で、条件付きである。証明書を条件付きにするためには、証明書に明確に署名する代わりに、ＣＡが対称鍵を作り、この対称鍵で証明書のその署名を暗号化する。したがって、ＣＡは、暗号化された署名を含む証明書をクライアントに提供し、更にＥＫ−公開によって暗号化された対称鍵を提供する。証明書要求に使用されたＡＩＫが、ＥＫを保持し信頼されているＴＰＭによって実際に作られた場合、そのクライアントは、ＥＫ−秘密を使用して対称鍵を解読することをＴＰＭに要求することができる。次いで、この対称鍵は、証明書における署名を解読するために使用することができる。逆に、ＥＫ−公開によって特定された信頼されているＴＰＭを有していない装置においてＣＡがクライアントに証明書を提供する場合、クライアントは署名を解読することができず、証明書を使用することができない。このように、ＣＡは、信頼されているＴＰＭに、特定のＡＩＫの信頼度を検証するジョブを委任することによって、認証機関と、ＡＩＫを証明させるクライアントとの間における別の１回の往復を回避する。

[0026] これより図面に移ると、図１は、認証機関が新たな鍵を証明することをクライアントが要求するときに使用することができる種々のコンポーネント、およびこれらのコンポーネント間における相互作用例を示す。図面において、そして以下に続く説明において、クライアントが証明することを要求する鍵を「新たな鍵」と呼ぶ。一例では、この鍵は、クライアントがデーターに署名するプロセスの一部として使用するRivest-Shamir-Adelman（ＲＳＡ）鍵の公開部分である。つまり、典型的なシナリオでは、クライアントは新たなＲＳＡ署名鍵を作り、署名鍵を他のエンティティが信頼できるように、この鍵をＣＡによって証明させることを求めている。しかしながら、本明細書において記載する技法は、署名鍵、またはＲＳＡ鍵の証明に限定されるのではない。一般に、本明細書における技法は、クライアントが鍵を作り、それをＣＡによって証明させることを求めているときであればいつでも適用できる。つまり、クライアントが証明させようとしている鍵を、ここでは、「新たな鍵」と呼ぶ。本明細書において記載する技法は、種々の鍵の使用を伴い、これらの鍵は、しかるべき呼称および／または修飾によって、本文および図面において区別することにする。

[0027] 装置１０２は、パーソナル・コンピューター、ハンドヘルド・コンピューター、セット・トップ・ボックス等のように、何らかの計算能力を提供する装置である。装置１０２には、ＴＰＭ１０４が装備されている。ＴＰＭ１０４は、ＴＰＭ１０４が配置されている装置１０２に、種々のセキュリティー・サービスを提供するコンポーネントである。ＴＰＭ１０４は、裏書き鍵（ＥＫ）１０６を有する。裏書き鍵１０６は、非対称鍵対であり、それぞれ、公開部分１０８および秘密部分１１０を有する（ここでは、「ＥＫ−公開」および「ＥＫ−秘密」と呼ぶ）。各ＴＰＭ１０４は、他のＴＰＭによって共有されない、それ自体のＥＫを有する。ＥＫ１０６の一態様では、ＥＫ−秘密はＴＰＭ１０４の外部には露出されない。ＴＰＭ１０４はインターフェースを露出し、装置１０２がこのインターフェースを使用して、ＴＰＭ１０４がＥＫ−秘密によってデーター片を解読することを要求することができ、ＴＰＭ１０４は、ＥＫ−秘密の実際の値を露出することなく、装置１０２のためにデーターを解読できるようになっている。また、ＴＰＭ１０４は、種々の他のセキュリティー機能も提供する。例えば、ＴＰＭ１０４は、装置の現在の実行状態の測定値を記録する１組のレジスター（プラットフォーム構成レジスター、またはＰＣＲと呼ぶ）を維持し、ＴＰＭ１０４は、装置１０２がデーター片を特定の装置状態に隠蔽することを可能にする。このように、装置１０２は、ＴＰＭ１０４のみが隠蔽解除することができる隠蔽データー片を保持することができ、ＴＰＭ１０４は、装置１０２が現在既知の「安全」状態になければ、データーの隠蔽解除を拒否することによって、このデーターを保護することができる。ＴＰＭ１０４によって提供される他の特徴は、ＴＰＭ１０４内部にある少量のメモリーであり、鍵を格納するために使用することができる。このように、ＴＰＭ１０４は、鍵対を生成することができ、そして秘密部分は装置１０２の安全でない部分には露出されないように、その鍵の秘密部分をそれ自体のメモリーに保持することができる（即ち、ＴＰＭ１０４の外部にある装置１０２の部分）。この意味において、鍵対の中の秘密鍵がＴＰＭ１０４内部に保持されている場合、移行不可鍵となる。特定の装置のＴＰＭの外部には露出されないので、他の装置に移行させることはできない。

[0028] クライアント１１２は、ある目的（例えば、署名または暗号化）のために新たな鍵を作ることを望むソフトウェア・コンポーネントである。クライアント１１２は、アプリケーション、オペレーティング・システムのコンポーネント、または装置１０２において実行する任意の他のタイプのソフトウェア・コンポーネントとすることができる。クライアント１１２が新たな鍵を作ることを決定したとき、クライアント１１２は、ＴＰＭ１０４が鍵を作ることの要求１１４を発行する。ＴＰＭ１０４は、要求された鍵を作り、鍵ハンドル１１６を戻す。この鍵ハンドル１１６によって、鍵を特定することができる。通例、要求１１４はＲＳＡ鍵対のような、非対称鍵対を作ることの要求であり、この場合、鍵ハンドル１１６は、新たな鍵の公開部分を含む（秘密部分はＴＰＭ１０４の内部だけに保持されている）。この例では、ＲＳＡ鍵対の公開部分が、クライアントが証明させようとしている「新たな鍵」となる。（通例、データーに署名するために使用されるのは秘密鍵であり、公開鍵は、署名を検証するために、他の当事者によって使用される。データーは、ある者が後に署名を検証することを予期して署名されるので、本明細書に限って言えば、公開鍵は署名データーの「プロセスの一部」であると見なすことができる。）
[0029] 新たな鍵を証明させるために、クライアント１１２は証明書要求１１８を作る。証明書要求１１８は、認証機関が鍵を証明することを要求する、正式なデーター構造である。クライアント１１２は、この時点では、証明書要求１１８を認証機関には送らない。そうする前に、クライアント１１２は、ＴＰＭによって作られた種々のデーター片を、証明書要求と共に送るための手配をする。これらの種々のデーター片について、以下に説明する。

[0030] 最初に、クライアント１１２は、ＴＰＭ１０４に、証明識別鍵（ＡＩＫ）を求める要求１１９を発行する。ＴＰＭ１０４は、任意のデーター片に結び付けられたＡＩＫを作る関数を露出する。例えば、ＴＰＭ１０４は、「CreateAIK (blob)」のような関数を露出することができる。これは、暗号的に「blob」に結び付けられるようにAIKを戻す（「blob」は任意のデーター片である）。具体的には、クライアント１１２が要求「CreateAIK (blob)」を発行したとき、ＴＰＭ１０４は以下の形態のデーター片を戻す。

（表記について、垂直線の記号「｜」は、連結を指す。加えて、この説明にわたって、「ｓｉｇ＜鍵対＞−秘密（＜データー＞）」という表記は、＜鍵対＞の秘密部分を使用することによって、＜データー＞に対して作られる署名を指す。）クライアント１１２がＡＩＫをＴＰＭ１０４に要求するとき、ＡＩＫを結び付けることをクライアントが要求する「ｂｌｏｂ」は証明書要求１１８のダイジェストとなる。ＡＩＫ−作成機能によって戻されたデーターを、識別結合１２０と呼び、識別結合１２０の一例を図６に示す。具体的には、識別結合１２０は、ＡＩＫ−公開６０２、証明書要求のダイジェスト６０４、ならびにＡＩＫ−公開６０２およびダイジェスト６０４に受け渡される署名６０６を含み、署名６０６は、ＡＩＫ−秘密を使用して作られる。つまり、クライアント１１２がＴＰＭ１０４から受け取る識別結合１２０は、以下のようになる。

識別結合が行うことは、ＡＩＫを特定の証明書要求に結び付けることである（その要求のダイジェストを介して）。実際、署名は、ＡＩＫ−秘密の保持者（ＴＰＭ１０４）が、「ダイジェスト」はＡＩＫを作った目的であるデーターであることを断言したことを意味する。識別結合１２０を有する当事者は誰でも、署名を検証するためにＡＩＫ−公開を使用することができる。

[0031] 図１に戻って、クライアント１１２は次にＴＰＭ１０４に、新たな鍵にＡＩＫで署名させる要求１２２を発行する。ＴＰＭ１０４がＡＩＫで鍵に署名すると、ＴＰＭ１０４は、鍵に適用するセキュリティー機構(security feature)を示す構造を戻す。例えば、前述のように、クライアント１１２がＣＡによって証明させようとしている新たな鍵は、ＴＰＭによって作られた。この新たな鍵が鍵対である例では、ＴＰＭ１０４は秘密部分をＴＰＭ１０４の内部に保持し、秘密部分をＴＰＭ１０４の外部には暴露しない。この意味では、新たな鍵は移行不可である。何故なら、その秘密部分は、ＴＰＭ１０４を含む特定の装置（即ち、装置１０２）以外ではいずれの装置でも使用できないからである。したがって、ＴＰＭ１０４がＡＩＫで鍵に署名すると、実際に以下の情報を含む構造を戻す。

ここで、「ステートメント」は、新たな鍵についてのステートメントである。例えば、ステートメントは、実際には、「署名されようとしている鍵は移行不可鍵です」と言うことができる。（英語の文章で表現されるステートメントの例は、単に例示のために過ぎない。通例、ステートメントは、コードを使用して作ることができる。または、ＴＰＭが、鍵が特定のセキュリティー標準に一致しなければ鍵に署名することを拒否するという既知のポリシーを有する場合、ステートメントは、ＴＰＭが鍵に署名したという事実に内在することもできる。加えて、「移行不可であること」は、鍵の特徴の一例であり、この例は、本明細書における記載全体において使用されることを注記しておく。つまり、本説明では、頻繁に、移行不可という特徴を有するものとして鍵に言及し、または鍵が移行不可であるというステートメントに署名するために使用されるＡＩＫに言及し、または鍵が移行不可であるというポリシーを満たすことをチェックするＣＡに言及する。しかしながら、移行不可であることは、このような特徴の一例に過ぎない。一般に、鍵は任意の特徴を有することができ、鍵証明構造に含まれるステートメントは、任意のこのような特徴を明らかにすることができ、ＣＡは任意の１組の０個以上の特徴を有することを鍵に要求するポリシーを強制することができる。このように、本明細書における記載は、移行不可鍵に言及するが、鍵証明構造は単に鍵の一部の特徴を明らかにするに過ぎず、その特徴が何であるかには関係なく、そして、以下で論ずるように、ＣＡは鍵証明構造を使用して、ＡＩＫ−秘密が、ＣＡのポリシーが要求する任意の特徴を明らかにするために用いられていたか否か判断することができる。）
[0032] したがって、ＴＰＭ１０４が鍵に署名すると、鍵証明構造１２４を生成する。鍵証明構造１２４の一例を図７に示す。鍵証明構造例１２４は、ステートメント７０２（図示のように明示的に表現することができ、または暗示的に表現することもできる）を含む。また、鍵証明構造１２４は、証明すべき新たな鍵７０４、および署名７０６も含む。署名７０６は、ＡＩＫ−秘密を使用して作られ、ステートメントおよび新たな鍵について計算されている。鍵証明構造１２４は、いかなるエンティティが制御しても、ＡＩＫ−秘密は、新たな鍵７０４が移行不可鍵であると言うこと（または、ＡＩＫ−秘密の保持者が明らかにしている任意の特徴を有する）を証明する(prove)。ＡＩＫ−公開を所有する任意のエンティティ（即ち、前述した識別結合を受け取った任意のエンティティ）は、署名を使用して、新たな鍵７０４およびステートメント７０２が、ＡＩＫ−秘密を所有するエンティティによって署名されたことを証明することができる。

[0033] 図１に戻って、認証機関（ＣＡ）１２６は、クライアント１１２が新たな鍵を証明することを要求することを望むエンティティである。クライアント１１２は、既に証明書をＣＡ１２６に要求する用意ができている。ＣＡ１２６が新たな鍵を証明することを要求するために、クライアント１１２は、ＣＡ１２６に、証明書要求１１８、識別結合１２９、鍵証明構造１２４、およびＥＫ１０６の証明書１２８（即ち、ＥＫ−公開を含む、ＴＰＭ１０４の裏書き鍵の公開鍵証明書）を送る。これらの品目は、ＣＡ１２６によって受け取られる。

[0034] 一例では、ＣＡ１２６は、要求に応えて証明書を発行するサーバーである。例えば、ＣＡ１２６は会社（または他の企業）内部にあるサーバーとすることができ、企業内の新たな装置の鍵を証明することによって、これらを登録する。ＣＡ１２６は、発行コンポーネント１３０を含む。発行コンポーネント１３０は、どの鍵を証明するかについて判断を下す。ＣＡ１２６は、信頼されているＴＰＭのリスト１３２（例えば、ＣＡ１２６が信頼するＴＰＭのＥＫ−公開のリスト）を含むことができる。また、ＣＡ１２６は、証明書要求が付与されるまたは拒否されるべき規則を含むポリシー１３４を有することもできる。例えば、ＣＡ１２６は、移行不可鍵のみを証明するポリシーを有することができ、または他の何らかのポリシーを有することもできる。加えて、ＣＡ１２６は署名検証部１３６を有することもできる。署名検証部１３６は、ＣＡが受け取った種々のデーター片における暗号署名を検証することをＣＡに可能にする。これらのコンポーネントは、発行コンポーネント１３０によって使用することができる。例えば、発行コンポーネントは、署名検証部１３６を使用して、識別結合および鍵証明構造における署名を検証することができる。また、発行コンポーネント１３０は、信頼されているＴＰＭのリスト１３２を使用して、どのＴＰＭの鍵であれば証明しても構わないか判断することができる。加えて、発行コンポーネント１３０は、ポリシー１３４を使用して、証明書要求が信頼されているＴＰＭから来ている場合であっても、特定の鍵を証明するか否か判断することができる。（例えば、発行コンポーネントはＴＰＭ１０４を信頼することができるが、鍵が移行不可であるとＴＰＭ１０４が言わない場合、ＴＰＭ１０４の鍵を証明しようとしない場合もある。）
[0035] ＣＡ１２６が前述の品目をクライアント１１２から受け取ると、以下のことを行う。最初に、ＣＡ１２６は証明書１２８（ＴＰＭ１０４の裏書き鍵の公開部分を含む）を調べて、ＣＡ１２６が、クライアント１１２が実行している装置におけるＴＰＭを知っておりそれを信頼するか否か判断する。例えば、ＴＰＭ１０４がＣＡ１２６に知られていない場合（証明書１２８をリスト１３２と比較することによって判断することができる）、ＣＡ１２６は、ＴＰＭ１０４がインストールされている装置において鍵を証明しなくない場合もある。つまり、証明書１２８が、証明が求められている鍵が知らないＴＰＭに結び付けられていることを示す場合、ＣＡ１２６は証明書要求を拒否することができる。

[0036] ＣＡ１２６が、公開裏書き鍵が証明書１２８に現れているＴＰＭを知っており、信頼していると仮定すると、ＣＡ１２６は次に証明書要求１１８を調べて、クライアント１１２が証明することを要求している新たな鍵を復元する（その鍵は証明書要求に含まれているからである）。

[0037] 次に、ＣＡ１２６は識別結合１２０を調べて、証明書要求のダイジェストを発見する。次いで、ＣＡ１２６は、証明書要求のダイジェストを計算し（識別結合１２０においてダイジェストを作るのに用いたのと同じダイジェスト・アルゴリズムを使用して）、識別結合に含まれているダイジェストが、ＣＡ１２６が計算したダイジェストと一致することを検証する。これらのダイジェストが一致した場合、ＣＡ１２６はＡＩＫ−公開を識別結合１２０から読み出し、ＡＩＫ−公開を用いて、識別結合１２０における署名を検証する。ＡＩＫは、その作成時に、特定のデーター片に結び付けられることが思い出されよう。署名の検証によって、この特定のＡＩＫが作られたデーター片が、証明書要求１１８のダイジェストであることが証明される。ダイジェスト・プロセスが安全である範囲で、ＡＩＫがそのダイジェストに対して作られたという事実は、ＡＩＫが証明書要求１１８に対して作られたことを証明する。尚、検証プロセスが失敗した場合（即ち、ＡＩＫが、現在作られているもの以外の何らかの証明書要求に対して作られた場合）、この事実は、証明書要求が何らかのタイプの反射攻撃の一部として作られていたことを示唆し、ＣＡ１２６はこの要求を拒否できることを注記しておく。

[0038] 次に、ＣＡ１２６は、鍵証明構造を調べて、ＡＩＫ−秘密の保持者が、セキュリティー要求に含まれる新たな鍵についてどんなステートメントを作っているのか判定する。ＣＡ１２６は、ＡＩＫ−公開を使用して、鍵証明構造における署名を検証する。署名が検証できない場合、ＣＡ１２６は、ＡＩＫ−秘密の保持者がＣＡ１２６について任意の特定のステートメントを作ったと結論付けることができず、したがってＣＡ１２６は証明書要求を拒否する。署名が検証できたと仮定すると、ＣＡ１２６は、新たな鍵の特性がＣＡ１２６のポリシー１３４と矛盾しないか否か判断する。例えば、ＣＡ１２６が移行不可鍵のみを証明するポリシーを有する場合、鍵証明構造は、ＡＩＫ−秘密の保持者が鍵は移行不可であると言うことを示すことを主張することができる。

[0039] この時点まで、プロセスの説明は、どのエンティティがその鍵を保持するか特定することなく、「ＡＩＫ−秘密の保持者」に言及した。実際には、ＡＩＫ−秘密はＴＰＭ１０４によって保持される。何故なら、ＡＩＫを作ったのはＴＰＭ１０４であるからである。しかしながら、この事実はＣＡ１２６には知られていない。ＣＡ１２６は、ＴＰＭ１０４の裏書き鍵の公開部分を知っているが、ＣＡ１２６は、特定のＴＰＭと特定のＡＩＫとの間の関係を、単に裏書き鍵から推論することはできない。言い換えると、本プロセスのこの時点において、ＣＡ１２６は、何らかのエンティティが、ＣＡ１２６が受け取った特定の証明書要求に対してＡＩＫを作成したことを知っており、そしてそのエンティティが何であれ、証明すべき鍵について、ＣＡ１２６の発行ポリシーを満足するというステートメントを作ったことを知っている。しかし、ＣＡ１２６は、そのエンティティが誰なのかは知らない。前述のように、ＣＡ１２６はＴＰＭ１０４の公開裏書き鍵を調べており、そしてＴＰＭ１０４が信頼できると判断しているので、ＡＩＫ−秘密を制御するエンティティがＴＰＭ１０４である場合、ＣＡ１２６は証明書要求を付与しても構わない。しかし、ＣＡ１２６は、ＡＩＫ−秘密がＴＰＭ１０４によって制御されているのか、または何らかの他のエンティティによって制御されているのか知らない。以下で説明するが、ＣＡ１２６は、ＡＩＫ−秘密を制御するエンティティが実際にＴＰＭ１０４である場合にのみ用いることができる形態で、条件付き証明書を発行することができる。具体的には、この証明書の形態は、ＴＰＭ１０４が何らかの動作を実行した後でなければ、証明書を使用できないようになっている。特に、証明書における署名は、ＴＰＭによって実行されるプロセスの結果としてのみ解読できるように暗号化することができる（例えば、ＴＰＭによる署名の解読、後に署名を解読するために使用される鍵のＴＰＭによる解読）。

[0040] 特定のＴＰＭの存在について条件付きの証明書を発行するために、ＣＡ１２６は、要求に応じて、新たな鍵に対して証明書（例えば、Ｘ．５０９証明書）を作る。証明書は、証明すべき鍵と、鍵を証明する認証機関の署名とを含む。通常、署名は証明書においてクリアである（即ち、暗号化されていない）。しかしながら、ＣＡ１２６が証明書を作るとき、対称鍵を作り、この対称鍵を使用して署名を暗号化する。暗号化された署名は、クリア署名に代わって、証明書の中に置かれる。次いで、ＣＡ１２６は、ＴＰＭ１０４の公開裏書き鍵で（即ち、ＣＡ１２６が証明書１２８において受け取ったＥＫ−公開）、対称鍵を暗号化する。ＥＫ−秘密の保持者（即ち、ＴＰＭ１０４）のみが、ＥＫ−公開で暗号化された情報を解読することができるので、ＴＰＭ１０４のみが対称鍵を復元することができる。したがって、ＣＡ１２６は、クライアント１１２に、（ａ）暗号化された署名がある証明書１３８、および（ｂ）暗号化された対称鍵１４０（ＥＫ−公開によって暗号化された）を送る。クライアント１１２が暗号化された対称鍵を受け取ると、それをＥＫ−公開で解読することをＴＰＭ１０４に要求することができ、これによってクライアント１１２が対称鍵で署名を解読することが可能になる。次いで、クライアント１１２は、証明書１３８における暗号化された署名を、クリア署名と置き換えることができる。証明書１３８を図８に示す。証明書１３８は、新たな鍵７０４を、暗号化された署名８０２と共に含む。この署名８０２は、対称鍵によって暗号化されたｓｉｇ−ＣＡ−秘密（新たな鍵）である。（「ＣＡ−秘密」はＣＡ１２６の秘密鍵である。）
[0041] 尚、ＣＡ１２６が証明している鍵が、ＣＡ１２６によって強制される、該当する標準（例えば、移行不可であること）を満たすことを、ＴＰＭ１０４が明らかにした場合、ＣＡ１２６は使用可能な証明書を発行することのみを望むことを注記しておく。ＣＡ１２６がこれを真であると認めるのは、ＴＰＭ１０４が実際にＡＩＫを生成したエンティティである場合だけである。理論的には、ＡＩＫは、ＴＰＭ１０４以外の何らかのエンティティによって生成された可能性もある。その場合でも、ＣＡ１２６は、ＴＰＭ１０４が解読することができる、暗号化された署名のある証明書１３８を発行する（何故なら、ＴＰＭ１０４の秘密裏書き鍵で復元できる対称鍵で、署名が暗号化されているからである）。しかしながら、ＣＡ１２６が、暗号化された署名がある証明書を、ＴＰＭ１０４に送るとき、ＣＡ１２６はＴＰＭ１０４を拠り所として、証明書１３８によって証明された新たな鍵が実際にＴＰＭ１０４がＡＩＫで署名したものでない場合には、クリア署名の証明書を作らない。実際に、ＣＡ１２６はこの判定をＴＰＭ１０４に委任する。ＣＡ１２６がこれをすることができるのは、ＴＰＭ１０４が、ＣＡ１２６が信頼するＴＰＭであることを既に確定しているからである。つまり、ＴＰＭ１０４が暗号化された署名がある証明書１３８を受け取った後、ＴＰＭ１０４は、証明書１３８によって証明された新たな鍵が、ＴＰＭ１０４がＡＩＫで署名した鍵であるか否か判断する。そうである場合、ＴＰＭ１０４は署名を解読し、暗号化された署名をクリア署名と置き換える。そうでない場合、ＴＰＭ１０４は署名を解読せず、これによって証明書を使用不可能にする。当事者が信頼するしかるべき機関によって証明書が署名されたことをその当事者が検証できないかぎり、当事者は鍵証明書を信頼しない。証明書における署名を解読することができない場合、この証明書は事実上使用不可のままとなる。何故なら、いずれの当事者とも信頼を確立するために使用することができないからである。

[0042] 図２から図５は、フロー・チャートの形式で、鍵を証明する要求を行い、それに作用することができるプロセス例を示す。図２から図５の説明に移る前に、これらの図に含まれる流れ図について、一例として、図１に示したコンポーネントを参照して説明するが、このプロセスは、任意のシステムにおいて実行することができ、図１に示すシナリオに限定されるのではないことを注記しておく。加えて、図２から図５における各流れ図は、ブロックを繋ぐ線によって示されるように、プロセスの段階が特定の順序で行われる例を示すが、これらの図において示す種々の段階は、任意の順序で、あるいは任意のコンビネーションまたはサブコンビネーションで行うことができる。

[0043] ２０２において、クライアントが、ＴＰＭが新たな鍵を生成することを要求する。先に注記したように、新たな鍵は、例えば、ＲＳＡ鍵対であり、暗号化または署名のような任意の暗号機能に使用することができる。ＲＳＡ鍵対を生成する例では、流れ図において言及される「新たな鍵」（即ち、証明すべき鍵）は、鍵対の公開部分である。

[0044] ２０４において、新たな鍵に対する証明書要求が作られる。この要求のダイジェストが作られ（２０６において）、次いで、クライアントは、ＴＰＭが、ダイジェストに結び付けられたＡＩＫを作ることを要求する（２０８において）。次いで、ＴＰＭはＡＩＫを作り（２１０において）、識別結合を戻す。先に注記したように、識別証明は、ＡＩＫ−公開、ダイジェスト、ならびにＡＩＫ−公開およびダイジェストに引き渡される署名（署名はＡＩＫ−秘密によって作られる）を含む。

[0045] ２１２において、クライアントは、ＴＰＭが新たな鍵にＡＩＫで署名することを要求する。次いで、ＴＰＭは鍵証明構造を戻す（２１４において）。鍵証明構造は、新たな鍵についての（明示的または暗示的な）ステートメント（例えば、「この鍵は移行不可です」）、新たな鍵自体、ならびにステートメントおよび新たな鍵（ＡＩＫ−秘密によって作られた署名を有する）に引き継がれる署名を含む。２１６において、クライアントはＣＡに、（ａ）証明書要求、（ｂ）識別結合、（ｃ）鍵証明構造、および（ｄ）ＴＰＭの裏書き鍵の公開鍵証明書（ＥＫ−公開）を送る。２１８において、これらの品目はＣＡによって受け取られる。

[0046] ２２０において、ＣＡはＥＫ−公開を既知のＴＰＭのリストと突き合わせてチェックし、ＥＫ−公開に基づいて、ＥＫ−公開と関連のあるＴＰＭがＣＡには知られていない、または信頼できないＴＰＭからであることが分かったと ＣＡが判断した場合（２２２において判断する）、ＣＡはこのプロセスを中断し（２２４において）、証明書を発行しない。ＥＫ−公開が既知の信頼できるＴＰＭからである場合、本プロセスは２２６に進み、ＣＡは証明書要求を読んで、証明することを要求されている新たな鍵を得る。

[0047] 次に、ＣＡは、識別結合における署名を検証し、結合からダイジェストを復元し、更に証明書要求からダイジェスト自体を計算する。識別結合が証明書要求と一致しない場合（即ち、証明書要求に含まれるダイジェストが、ＣＡが証明書要求から計算したダイジェストと同じでないと２２８において判断された場合）、本プロセスは中断し、ＣＡは証明書を発行しない（２３０において）。それ以外の場合、本プロセスは２３２に進む。

[0048] ２３２において、ＣＡは、鍵証明構造が、新たな鍵が該当するポリシーを満たす（例えば、移行不可であることのポリシー）ことを明らかにするか否か判断する。ＣＡは、例えば、鍵構造証明における署名を検証し、次いでこの構造が鍵について作ったステートメントを調べることによって、この判断を下すことができる。署名が検証できない場合、またはステートメントが、鍵を証明するＣＡのポリシーを鍵が満たしていないことを示す場合、本プロセスは中断し、ＣＡは証明書を発行しない（２３４において）。そうでない場合、本プロセスは２３６に進み、ＣＡは証明書の発行に進む。

[0049] ２３６において、ＣＡは、証明書における署名を暗号化するために使用される対称鍵を作る。２３８において、ＣＡは新たな鍵に対して証明書を作る。２４０において、ＣＡは証明書に対して署名を作る。２４２において、ＣＡは署名を対称鍵で暗号化し、暗号化された署名を（クリア署名の代わりに）証明書に含ませる。２４４において、ＣＡは対称鍵をＥＫ−公開（証明書を発行しようとしている装置におけるＴＰＭの裏書き鍵の公開部分）で暗号化する。２４６において、ＣＡは、証明書を要求したクライアントに、鍵の証明書（暗号化された署名を有する）、およびＥＫ−公開によって暗号化された対称鍵を送る。２４８において、これらの品目はクライアントによって受け取られる。

[0050] ２５０において、クライアントは、対称鍵をＥＫ−秘密で解読することをＴＰＭに要求する。証明書に含まれている鍵が、ＴＰＭが証明書要求に用いられたＡＩＫで署名されたものと同じであると仮定すると、ＴＰＭは対称鍵を解読し（２５２において）、それをクライアントに戻す。すると、クライアントはこの対称鍵を使用して、署名を解読し、証明書における暗号化された署名をクリア署名と置き換える（２５６において）。この時点で、クライアントは新たな鍵に対して使用可能な証明書を所有することになる（２５８において）。

[0051] 図９は、本明細書において記載した主題の態様を配備することができる環境の一例を示す。
[0052] コンピューター９００は、１つ以上のプロセッサー９０２と、１つ以上のデーター記憶コンポーネント９０４とを含む。プロセッサー（１つまたは複数）９０２は、通例、パーソナル・デスクトップまたはラップトップ・コンピューター、サーバー、ハンドヘルド・コンピューター、または他のタイプの計算機において見られるようなマイクロプロセッサである。データー記憶コンポーネント（１つまたは複数）９０４は、短期間または長期間データーを格納することができるコンポーネントである。データー記憶コンポーネント（１つまたは複数）９０４の例には、ハード・ディスク、リムーバブル・ディスク（光ディスクおよび磁気ディスクを含む）、揮発性および不揮発性ランダム・アクセス・メモリー（ＲＡＭ）、リード・オンリー・メモリー（ＲＯＭ）、フラッシュ・メモリー、磁気テープなどが含まれる。データー記憶コンポーネント（１つまたは複数）は、コンピューター読み取り可能記憶媒体の例である。コンピューター９００は、ディスプレイ９１２を含むこと、またはこれと関連付けられることができる。ディスプレイ９１２は、陰極線管（ＣＲＴ）モニター、液晶表示（ＬＣＤ）モニター、または任意の他のタイプのモニターとすることができる。

[0053] ソフトウェアは、データー記憶コンポーネント（１つまたは複数）９０４に格納することができ、１つ以上のプロセッサー（１つまたは複数）９０２において実行することができる。このようなソフトウェアの例に、鍵証明ソフトウェア９０６がある。このソフトウェア９０６は、図１から図８に関して先に説明した機能の一部または全部を実現することができるが、他のタイプのソフトウェアも使用することができる。ソフトウェア９０６は、例えば、１つ以上のコンポーネントを介して実装することができる。これらのコンポーネントは、分散型システムにおけるコンポーネント、別々のファイル、別々の機能、別々のオブジェクト、別々のコード・ライン等とすることができる。ハード・ディスクにプログラムが格納されており、ＲＡＭにロードしてコンピューターのプロセッサー（１つまたは複数）においてこのプログラムを実行するパーソナル・コンピューターが、図９に示すシナリオを代表するが、本明細書において記載した主題は、この例に限定されるのではない。

[0054] 本明細書において記載した主題は、データー記憶コンポーネント（１つ以上）９０４の１つ以上に格納されプロセッサー（１つ以上）９０２の１つ以上において実行するソフトウェアとして実現することができる。他の例として、本主題は、１つ以上のコンピューター読み取り可能記憶媒体に格納されている命令として実現することができる。（光ディスクまたは磁気ディスクのような有形媒体が、記憶媒体の例である）。このような命令は、コンピューターまたは他の装置によって実行されると、このコンピューターまたは他の装置に、方法の１つ以上の動作を実行させることができる。これらの動作を実行する命令は、１つの媒体に格納することができ、複数の媒体に跨がって拡散させることができるので、これらの命令の全てが偶然同じ媒体上にあるか否かには関係なく、命令は集合的に１つ以上のコンピューター読み取り可能記憶媒体に存在してもよい。

[0055] 加えて、本明細書に記載した任意の動作（図に示されているかまたはいないかには関係なく）は、方法の一部としてプロセッサー（例えば、プロセッサー９０２の１つ以上）によって実行することができる。本明細書において動作Ａ、Ｂ、およびＣが記載されている場合、動作Ａ、Ｂ、およびＣの動作を含む方法を実行することができる。更に、本明細書においてＡ、Ｂ、Ｃの動作が記載されている場合、プロセッサーを使用してＡ、Ｂ、およびＣの動作を実行するステップを含む方法を実行することができる。

[0056] 環境の一例では、コンピューター９００は、ネットワーク９０８を介して１つ以上の他のデバイスに通信可能に接続することができる。コンピューター９１０は、コンピューター９００と構造が同様でもよく、コンピューター９００に接続することができるデバイスの一例であるが、他のタイプのデバイスもそのように接続することができる。

[0057] 以上、構造的特徴および／または方法論的動作に特定の文言で本主題について説明したが、添付されている特許請求の範囲において定められる主題は、前述した特定の特徴や動作には必ずしも限定されないことは言うまでもない。逆に、先に説明した特定の特徴および動作は、特許請求の範囲を実施する形態例として開示したまでである。

Claims (15)

1. 第１鍵（７０４）の証明書（１３８）を要求する方法であって、
   前記第１鍵（７０４）を証明させる証明書要求（１１８）を作るステップ（２０４）と、
   トラステッド・プラットフォーム・モジュール（１０４）から、前記証明書要求（１１８）に結び付けられた証明識別鍵を要求するステップ（２０８）と、
   前記トラステッド・プラットフォーム・モジュール（１０４）から、前記証明識別鍵を前記証明書要求（１１８）に結び付ける識別結合（１２０）を受け取るステップ（２１０）と、
   前記トラステッド・プラットフォーム・モジュール（１０４）が前記第１鍵（７０４）に前記証明識別鍵で署名することを要求するステップ（２１４）と、
   前記トラステッド・プラットフォーム・モジュール（１０４）から、前記第１鍵（７０４）を含み、前記証明識別鍵によって署名された鍵証明構造（１２４）を受け取るステップ（２１６）と、
   認証機関（１２６）に、前記証明書要求（１１８）、前記識別結合（１２０）、前記鍵証明構造（１２４）、および前記トラステッド・プラットフォーム・モジュール（１０４）の公開裏書き鍵（１０８）の第１証明書（１２８）を含む情報を送るステップ（２１８）と、
   前記認証機関（１２６）から、前記第１鍵（７０４）の第２証明書（１３８）を受け取るステップ（２４８）であって、前記第２証明書（１３８）が、前記トラステッド・プラットフォーム・モジュール（１０４）によって動作が行われた後でのみ使用可能となる形態となっている、ステップと、
   を含む、方法。
2. 請求項１記載の方法であって、更に、
   前記証明書要求のダイジェストを計算するステップを含み、
   前記証明識別鍵が、前記証明識別鍵を前記ダイジェストに結び付けることによって、前記証明書要求に結び付けられる、方法。
3. 請求項１記載の方法において、前記第１証明書が、前記認証機関の署名を含み、前記署名が、前記トラステッド・プラットフォーム・モジュールの秘密裏書き鍵を使用するプロセスのみによって解読可能であり、前記動作が、前記トラステッド・プラットフォーム・モジュールの秘密裏書き鍵の使用を含む、方法。
4. 請求項３記載の方法であって、更に、
   前記認証機関から、前記トラステッド・プラットフォーム・モジュールの公開裏書き鍵によって暗号化された対称鍵を受け取るステップを含み、
   前記第２証明書が、前記対称鍵によって暗号化された形態で前記署名を含み、前記トラステッド・プラットフォーム・モジュールの秘密裏書き鍵を使用する前記プロセスが、
   前記対称鍵を解読するために、前記トラステッド・プラットフォーム・モジュールの秘密裏書き鍵を使用するステップと、
   前記署名を解読するために、前記対称鍵を使用するステップと、
   を含む、方法。
5. 請求項１記載の方法において、前記第２証明書が、暗号化された形態で受け取られる署名を含み、前記動作が、更に、
   前記暗号化された形態の前記署名を、クリア形態の署名と置き換えるステップを含む、方法。
6. 請求項１記載の方法において、前記第１鍵が移行不可であり、前記鍵証明構造が、前記第１鍵が移行不可であるステートメントを含む、方法。
7. 請求項１記載の方法において、前記第１鍵が、前記トラステッド・プラットフォーム・モジュールが配置された装置においてデーターに署名するプロセスの一部として使用される、方法。
8. 請求項１から７のいずれか１項記載の方法を実行するためのコンピューター実行可能命令を有するコンピューター読み取り可能媒体。
9. 第１鍵を証明する要求に対して動作する方法であって、
   第１鍵（７０４）を証明する証明書要求（１１８）と、
   クライアント（１１２）が実行する装置（１０２）においてトラステッド・プラットフォーム・モジュール（１０４）によって作られた証明識別鍵の識別結合（１２０）と、
   前記第１鍵（７０４）の機構を明らかにするために前記証明識別鍵を使用する鍵証明構造（１２４）と、
   前記トラステッド・プラットフォーム・モジュール（１０４）の公開裏書き鍵（１０８）の第１証明書（１２８）と、
   を含む情報を前記クライアント（１１２）から受け取るステップ（２１８）と、
   前記公開裏書き鍵（１０８）に基づいて、前記トラステッド・プラットフォーム・モジュール（１０４）が、前記動作を実行する認証機関（１２６）によって信頼されていることを検証するステップ（２２２）と、
   前記識別結合（１２０）が前記証明識別鍵を前記証明書要求（１１８）に結び付けていることを検証するステップ（２２８）と、
   前記鍵証明構造（１２４）が、前記証明識別鍵の秘密部分の保持者による、前記第１鍵（７０４）が前記構造を有することのステートメント（７０２）を表すことを検証するステップ（２３２）と、
   前記クライアント（１１２）に、前記第１鍵（７０４）の第２証明書（１３８）を送るステップ（２４６）であって、前記第２証明書（７０４）の使用が、前記トラステッド・プラットフォーム・モジュール（１０４）の存在という条件が付いた、ステップと、
   を含む、方法。
10. 請求項９記載の方法において、前記第２証明書の使用が、前記トラステッド・プラットフォーム・モジュールの秘密裏書き鍵の使用後にのみ前記証明書を使用可能にすることによって、前記トラステッド・プラットフォーム・モジュールの存在という条件が付いたものとする、方法。
11. 請求項９記載の方法において、前記第２証明書が、前記認証機関の署名を含み、当該署名が、前記トラステッド・プラットフォーム・モジュールの秘密裏書き鍵の使用によってのみ解読可能な形態となっている、方法。
12. 請求項９記載の方法において、前記第２証明書が、前記認証機関の署名を含み、前記署名が対称鍵で暗号化され、前記方法が、更に、
    前記トラステッド・プラットフォーム・モジュールの公開裏書き鍵によって暗号化された前記対称鍵を、前記クライアントに送るステップを含む、方法。
13. 請求項９記載の方法において、前記機構が、前記第１鍵が移行不可であることを含み、前記鍵証明構造が、前記第１鍵が移行不可であることの明示的または暗示的ステートメントを含む、方法。
14. 請求項９記載の方法において、前記識別結合が、前記証明書要求の第１ダイジェストを含ませることによって、前記証明識別鍵を前記証明書要求に結び付け、前記方法が、更に、
    前記証明書要求の第２ダイジェストを計算するステップと、
    前記第２ダイジェストが前記第１ダイジェストと一致することを検証するステップと、
    を含む、方法。
15. 請求項９から１４のいずれかに記載の方法を実行するためのコンピューター実行可能命令を有するコンピューター読み取り可能媒体。

Images