JP5860815B2 - コンピューターポリシーを施行するためのシステムおよび方法 - Google Patents

Description

本発明は、コンピューターポリシーを施行するためのシステムおよび方法に関するものである。

企業セキュリティポリシー（ＳＰ）は企業セキュリティ統治の根幹にかかわる必要不可欠な部分である。このようなポリシーは、従業員が組織の最も重要な資産である情報を持って移動することが認められている場合、重大な危険にさらされることになる。このことは、非常に重要な問題であり、かつ十分満足のいく程度に対処することが非常に難しい問題でもある。

たとえば、企業ポリシーによって、会社のラップトップが盗まれた場合であっても、すなわち敵対者がラップトップに物理的にアクセスし、ラップトップを会社の境界（ポリシーがその中で通常施行されている境界）の外側に持ち出した場合であっても、会社のラップトップに格納されているいかなるデータをも保護することがいかなる会社のラップトップにも要求されうる。それと同様に、従業員が許可をもらって会社のラップトップを家に持ち帰る場合であって、会社のラップトップが会社の施設の外側にある場合であったとしても、企業ポリシーによって会社のラップトップが引き続き管理されるべきである。

既存のセキュリティポリシーでは、従業員が、オフィスとオフィスとの間を移動し、会社の境界の内側および外側でさまざま異なるコンピューティングデバイスを用いて作業するに際には暗号鍵を複製する必要がある。したがって、既存のセキュリティポリシーの運用は、通常複雑でありかつ多大な時間を必要とする。従業員が会社を辞めるような場合には、従業員の暗号鍵をすべて無効にすることが必要となる。鍵管理についてのこれらの問題は、流動的なかつ常に変動する従業員全員にセキュリティポリシーを強いようとする会社とって相当なコストとなる。

本発明の目的は、少なくともこれらの困難を軽減することにある。

本発明の第一の態様によれば、コンピューターポリシーを施行する方法が提供されており、かかる方法は、
（ａ）暗号鍵を用いて、クライアントデバイス上の機密性の高いデータへのユーザーのアクセスを管理するためのポリシーを定義することと、
（ｂ）ポリシーおよびそれに関連する暗号鍵をサーバーに格納することと、
（ｃ）ユーザーの識別情報を確認し、クライアントデバイスの機密性保持環境を通じてクライアントデバイスの識別情報および信頼性を暗号処理により認証することと、
（ｄ）ポリシーを満たして許可された場合、暗号鍵をサーバーからクライアントデバイスの機密性保持環境へと機密性を保持しながら送信することと、
（ｅ）ユーザーに暗号鍵を開示することなく、機密性の高いデータへのユーザーのアクセスを可能とすることとを含んでいる。

第二の態様によれば、コンピューターポリシーを施行するためのシステムが提供されており、かかるシステムは、
（ａ）クライアントデバイス上の機密性の高いデータおよびそれに関連する暗号鍵へのユーザーのアクセスを管理するためのポリシーが格納されているサーバーと、
（ｂ） ユーザーにより操作されるクライアントデバイスであって、ポリシーを満たして許可されたとき、ユーザーに鍵を開示することなく、クライアントデバイス上の暗号化された機密性の高いデータへのユーザーのアクセスを可能とする暗号鍵を保持する機密性保持環境を有している、クライアントデバイスと、
（ｃ）ユーザーの識別情報を確認し、クライアントデバイスの識別情報および信頼性を暗号処理により認証するための手段と、
（ｄ）ポリシーを満たして許可されたとき、暗号鍵をサーバーからクライアントデバイスの機密性保持環境へと機密性を保持しながら送信するための手段とを備えている。

本発明の他の態様によれば、暗号操作を実行するために遠隔サーバーに格納されている暗号鍵にアクセスする方法が提供されており、かかる方法は、ユーザーの識別情報を判別することと、クライアントデバイスの識別情報を暗号処理により認証することと、ユーザーの識別情報およびクライアントデバイスの識別情報が遠隔サーバーに格納されているアクセス条件を満たすか否かを判断することと、アクセス条件が満たされている場合、暗号鍵を遠隔サーバーからクライアントデバイスへと機密性を保持しながら送信することと、ユーザーに暗号鍵を開示することなく、暗号鍵を用いて暗号操作を実行することとを含んでいる。

このような方法は、暗号化された形態でクライアントデバイスに格納されているデータへのユーザーのアクセスを管理するために用いられてもよい。暗号操作には、データを解読することが含まれていてもよい。かかる方法は、ユーザーに暗号鍵を開示することなく、解読されたデータへのユーザーのアクセスを可能とすることをさらに含んでもよい。

この態様によれば、クライアントデバイスは、デバイスの識別情報を暗号処理により認証することを可能とし、遠隔サーバーから機密性を保持しながら送信される暗号鍵を受け取り、暗号鍵をユーザーに開示することなく、暗号鍵を用いて暗号操作を実行するように構成されている。

データはクライアントデバイスに暗号化された形態で格納されており、クライアントデバイスは、暗号鍵を用いてデータを解読し、解読されたデータへのユーザーのアクセスを可能とするように構成されていてもよい。

さらにこの態様によれば、暗号鍵およびアクセス条件が格納されているサーバーは、ユーザーの識別情報およびクライアントデバイスの識別情報がアクセス条件を満たしているか否かを判断し、アクセス条件が満たされている場合、暗号鍵をクライアントデバイスへ機密性を保持しながら送信するように構成されている。

アクセス条件は、暗号鍵に関連するものであってもよいし、および／または、クライアントデバイスに暗号化された形態で格納されているデータに関連するものであってもよい。

ユーザー識別情報についての概念に加えておよびユーザー識別情報についての概念とは別個に、複雑でもっと意味深いポリシーの定義および施行を可能とするためにマシン識別情報が用いられてもよい。このことにより、システム管理者が、個々のユーザーが何を行うことができるかおよび個々のマシンを用いてユーザーが何を行いうるかを指定することが可能となる。

好ましくは、クライアントデバイスはセキュア暗号プロセッサまたはハードウェアセキュリティモジュールを有していてもよい。このようにして、機密性保持環境を提供することができる（たとえば、トラスティッドプラットフォームモジュール）。好ましくは、このデバイスは、デバイスの識別情報が暗号処理によって認証されることを可能とするためにセキュア暗号プロセッサを用いるように構成されている。好ましくは、このデバイスは、デバイスに格納されているデータを解読するために暗号鍵を用いるというような暗号操作を実行するためにセキュア暗号プロセッサを用いるように構成されている。

しかしながら、専用のハードウェアによる機密性保持環境が絶対に必要というわけではなく、実施形態によっては、クライアントデバイスは、マイクロコントローラまたは中央処理装置（ＣＰＵ）上で実行されるソフトウェアを用いて機密性保持環境を構築するようにしてもよい。このような手段が、暗号操作を実行する、および／または、デバイスの識別情報を暗号処理により検証することを可能とするために用いられるようになっていてもよい。

好ましくは、クライアントデバイスは、暗号鍵を揮発性メモリー（例：ＲＡＭ）内に保持し、暗号操作を実行した後は、メモリーから暗号鍵を消去するように構成されている。

好ましくは、サーバーはクライアントデバイスの識別情報を認証するように構成されている。

ユーザーの識別情報は、クライアントデバイスおよび／または遠隔サーバーによって検証されるようになっていてもよい。

クライアントデバイスはサーバーの識別情報を認証するように構成されてもよい。

クライアントデバイス上の機密性の高いデータを保護するために用いられるすべての暗号鍵は、中央サーバーに格納されることが好ましく、クライアントマシンのローカルディスクには格納されないことが好ましい。このようにすることにより、ポータブルクライアントデバイスの盗難による衝撃が小さくなる。このようなデバイスに格納されている暗号化されたデータは、それがいかなるデータであっても、必要な解読鍵を入手することができないので、取り出すことはできない。

解読されるデータはいかなるタイプのデータであってもよい。たとえば、解読されるデータは、電子メールメッセージの全部または一部を含んでいてもよい。

暗号鍵はさまざまな目的のうちのいずれの目的のためにクライアントデバイスによって用いられてもよい。さまざまな目的には、たとえば、データを解読するため、データを暗号化するため、データに署名するため、または遠隔デバイスと安全なセッションを開始するためなどが含まれる。

アクセス条件はセキュリティポリシーを構成しうる。

コンピューターポリシーを施行する既存の方法に対して、好ましい実施形態では、
− 暗号鍵（データを保護するために用いられる）が、クライアントデバイスに長期間格納されない点で好ましく、
− システムがデバイスおよびユーザーの両方を遠隔から識別することができ、かつ遠隔デバイスの完全性を検証することができるので、システムは、クライアントデバイスによるクライアント鍵の利用を可能とするか否かを管理する（したがって、ポリシーを施行する）ことができる。

このことにより、遠隔デバイスにおいても、サーバーを中心としたポリシーの施行が可能となる。このポリシーは、いかなる分散型環境、たとえばクラウド分散型環境であっても、その全体にわたって施行されうる。

暗号鍵はユーザー固有のものであってもよい。

遠隔サーバーは、暗号鍵と共に、１つ以上の証明書を送信するようになっていてもよい。遠隔サーバーは、複数の暗号鍵をクライアントデバイスへ送信するようになっていてもよい。

実施形態によっては、ユーザー固有の秘密鍵を含んでいるユーザープロファイルのダウンロードを含むポリシー施行のために、トラスティッドコンピューティングが用いられている場合もある。

これは他の応用（たとえば、トラスティッドソフトウェアのダウンロード応用）と次の点で異なっている：
− ユーザープロファイルとは、ユーザーに固有のものであり、汎用のソフトウェアのことではない。
− ユーザープロファイルの特定の部分へのアクセスをポリシーに基づいて管理することにより、私有の秘密鍵へのアクセスをポリシーに基づいて柔軟に管理することができるようになる。たとえば、ポリシーにより、下級の鍵については、広範囲のクラスのプラットフォームへの公開が許されるものの、上級の鍵については、起こりうるソフトウェア状態の非常に特殊な組合せにある非常に特殊なプラットフォームにのみダウンロードが許されることとしうる。
− ユーザープロファイルをポリシーに基づいて管理することにより、暗号鍵へのアクセスが柔軟なものになるので、他にも多くの応用が考えられるようになる（暗号鍵自体をさらなるサービスおよび／または情報へのアクセスを管理するために用いることができる）。

適切な場合、１つの態様における選択的特徴は、それがいかなるものであっても他の態様の選択的特徴となりうる。

以下に、本発明のいくつかの好ましい実施形態を記載するが、これらは例示のみを意図したものである。
構成要素
ある好ましい実施形態は次のデバイスを備えている：
１．好ましくはウェブサービスを提供するサーバーコンピューティングデバイス。
２．トラスティッドコンピューティンググループ仕様に従うトラスティッドプラットフォームモジュール（ＴＰＭ）（または、同様のセキュリティサービスを提供する任意のデバイスまたはシステム）を装備しているユーザーエージェントクライアントデバイス。

各ユーザーエージェントのＴＰＭには、公開暗号鍵／私有暗号鍵のペアが搭載され、ユーザーエージェント（マシン）の固有の識別情報（ｉｄｅｎｔｉｔｙ）の基礎を提供するようになっている。設計方法および不正開封防止特性の付与により、ＴＰＭ私有鍵は、ＴＰＭの外側では入手することができなくなっており、クライアントデバイスの識別情報を窃取することが非常に困難なになっている。
クライアントサーバープロトコル
サーバーがユーザーエージェントの識別情報を検証し、かつ、ポリシーを施行するにあたってその識別情報を用いるために、次のプロトコルが適用される：
１．ユーザーエージェント／クライアントデバイスがサーバーを検証する。このことは、サーバーによって生成されたシグネチャを検証し、サーバーの公開鍵をチェックすることにより実現される（ユーザーエージェント内にプログラムされている）。
２．サーバーがＴＰＭを取り調べることによりユーザーエージェントを検証する。サーバーは、ＴＰＭに身分証明を求め、ＴＰＭに属する私有鍵を用いてシグネチャを演算するようＴＰＭに要求する。ＴＰＭの私有鍵が解読された形態でＴＰＭから出て行くことはないので、（たとえば、クライアントプラットフォーム上で起動している悪質なソフトウェアによって）盗まれるようなことはありえないことに留意されたい。

いったんユーザーエージェントの物理デバイスの識別情報が認証されると、たとえばパスワード、暗号鍵ペアおよび／または生体認証を含む適切なユーザー認証メカニズムを用いて、ユーザーの検証が実行される。このシステムは、デバイスとユーザーとを任意に組み合わせたものの識別を可能とする。すなわち、一人のユーザーが多数のデバイスを使用する場合もあれば、多数のユーザーが単一のデバイスにより用いられる場合もある。次いで、それに応じて、ポリシーが施行されるようになっていてもよい。
ユーザーエージェントの遠隔からの検証
ポリシーは、たとえば（機密性が保持されない）インターネットを通じたデータの漏洩を回避するため、企業ＶＰＮに接続するとき、管理されていないインターネット接続を動作不能とすることにより、システム機能を制限することができる。このようなポリシーを施行するようにユーザーエージェントをプログラムすることができる。

しかしながら、サーバーによる鍵の管理とクライアントプラットフォームのＴＰＭとの組み合わせを用いることにより、ここに記載するソリューションは、ポリシーが実際に施行されていることをサーバーに保証することもできる。悪質な改変されたユーザーエージェントが、実際にはポリシーを施行していないのに、ポリシーを施行しているとサーバーに対して報告すると仮定する。サーバーは、そのＴＰＭを通じて、遠隔システムの完全性を検証することができるので、次の手続きを用いて、改変されたユーザーエージェントの存在を検出することができる。
１．ブート時、ＴＰＭは、オペレーティングシステムの完全性を検証し、搭載されたソフトウェアの特性を示す測定結果を機密性を保持しながら記録する。
２．ブート時になされたＴＰＭの測定によって完全性が保証されたオペレーティングシステムは、ユーザーエージェントの完全性を検証する。この測定の結果もＴＰＭの内部に格納される。
３．サーバーが遠隔デバイスの識別情報を認証するとき、その完全性も確認する。すなわち、認証プロセスには、ステップ１およびステップ２に記載の完全性の測定結果をＴＰＭからサーバーへ転送することが含まれている。この転送は、測定結果が通信相手のプラットフォームに埋め込まれている本物のＴＰＭから確かに来ていることをサーバーが検証することができるように行われる。このことは、ＴＰＭにとって固有のものであることを検証することができる私有鍵を用いて、ＴＰＭが完全性の測定結果にデジタル方式で署名することによって実現される。このプロセスは認証として知られている。
４．サーバーは、クライアントプラットフォームのための完全性の測定結果を処理し、これらが、施行されているセキュリティポリシーと一致する処理環境を示しているか否かを判定する。
５．ポリシー要件が満たされている場合、サーバーは、デバイスに暗号鍵を、メッセージ３で送られている完全性の測定結果がまだ有効である場合にのみクライアントプラットフォームがそれらを解読することができるように転送する。このことには、（たとえば、ｗｗｗ．ｒｓａ．ｃｏｍ／ｒｓａｌａｂｓ／ｔｅｃｈｎｏｔｅｓ／ｔｐｍ／ｓｅａｌｅｄｓｔｏｒａｇｅ．ｐｄｆから入手可能な２００７年６月２１日にブライアン・パルノ（Ｂｒｙａｎ Ｐａｒｎｏ）により提出された表題がトラスティッドプラットフォームモジュール（ＴＰＭ）およびシールドストレージである論文に記載のような）シールドストレージとして知られている機能が用いられる。このことにより、セキュリティポリシーがクライアントプラットフォームへとダウンロードされる一組の鍵に効果的に結び付けられる、すなわち、このことにより、ポリシー要件を満たしているクライアントプラットフォームにのみ鍵が利用可能となる。

この手順により、遠隔状況下においてポリシーが施行されていることを担保するにあたってマシンを識別するという概念の重要性が示されている。サーバー中心の鍵の管理とＴＰＭに基づく完全性の測定結果の使用とを組み合わせたもの（認証およびシールドストレージを含む）が本実施形態において固有のものであると考えられている。
鍵に基づいたポリシーの施行
ポリシーは、クライアントデバイス上に保持されている機密性の高いデータへのアクセスを制限することができるようになっており、実際、制限していることが多い。暗号化されたデータは、解読に必要な鍵が秘密になっていることを前提として、自由に開示されている。このように、データへのアクセスを制限する問題は、鍵の管理問題へと変換されうる。鍵へのユーザーのアクセスを拒否することによって、ユーザーは（暗号化された）データにアクセスすることができなくなる。

このような方法でポリシー制御を行なうことにより、特に遠隔デバイスに対して相当な利点を提供することができる。遠隔デバイスが平文で（暗号化しないで）データを保持して盗まれた場合、どのようなオペレーティングシステムがアクセス制限を実施していたとしてもまたはＴＰＭが存在していたとしても、ハードディスクの内容を直接解析することによりデータを読むことができた。このことは、データが暗号化され、解読に必要な鍵がクライアントデバイスに格納されていれば不可能である。

機密性の高いデータの取り扱いに関するポリシーを施行するために、次のメカニズムが用いられる。
１．データは、サーバーで作成されかつサーバーに保持されている鍵を用いて暗号化される。
２．施行されているポリシーによりデータへのユーザーのアクセスが許可されている場合、サーバーは、ユーザーエージェントのホストマシンおよびユーザーが認証された後でのみ、解読に必要な鍵をユーザーエージェントに開示する。エンドユーザーは、ユーザーエージェントから当該鍵を獲得することはない。というのも、当該鍵は、クライアントマシンのハードディスクに（平文で）格納されることがないからであり、また、たとえばデバッガーによるアクセスが不可能な保護メモリーにのみ格納されているからである。これらの特性は、たとえばＴＰＭ認証手法を用いてシステムの完全性がサーバーによって検証されているので施行されている。エンドユーザーが解読用の鍵を獲得することができないので、ユーザーエージェントのメモリーから鍵を削除するだけで、このような鍵を無効、すなわちデータへのアクセス権を無効とすることができる。
３．オフラインでのデータのアクセスを許可するために、ユーザーエージェントは、暗号化された形態でデータ暗号化鍵をディスクに（ポリシーに従って）格納しうる。データ用の鍵を暗号化するために用いられる鍵は、ＴＰＭのシールドストレージ機能を用いて保護されているので、許可無く回収することはＴＰＭの不正開封防止特性のため非現実的なこととなる。クライアントシステムが適切な一組のソフトウェア（有効なユーザーエージェントを含む）を実行している場合にのみ、ＴＰＭは、シールドストレージ機能を用いて、鍵を暗号化するための鍵の解読を許可するようになっている。

ポリシー（および、鍵）を管理するサーバー中心性と、ポリシーの施行を検証してオフラインでのデータの使用を許可するＴＰＭのような機密保護環境とを新規に組み合わせることによって、遠隔デバイスについて、サーバーにより企業ポリシーをロバストに管理し、施行することが可能となる。
プロファイルの転送
以下では、ユーザープロファイルをサーバーからクライアントデバイスへ転送することについて詳細に説明する。
前書き
本明細書で用いられる用語「プロファイル」は、中央サーバーに格納される一組のユーザー固有のデータのことを意味する。このプロファイルには、暗号化用の鍵および個人に関するポリシー情報、たとえばどのアプリケーションを用いる権限が与えられているのか、どのような状況で鍵がクライアントへダウンロードされるべきであるのか等の如き情報が含まれている。プロファイルとの用語は大ざっぱに用いられている。使用されるクライアントのタイプおよび／またはダウンロード時の具体的なユーザー要件によって異なる項目が選択され、プロファイル情報の部分部分だけをクライアントマシンへダウンロードすることが適切な場合もある。

プロファイル転送プロトコルの説明を３つのフェーズ、すなわち予備（セットアップ）フェーズと２つのメインフェーズとに分割する。セットアップフェーズは関連するエンティティ毎に一回だけ実行されるが、他の２つのフェーズはユーザーがクライアントマシンを利用したいときはいつでも、すなわちセッション毎に実行される。メインフェーズ（フェーズＩおよびフェーズＩＩ）は説明を単純化するためにここでは別々説明されるが、実際問題として、これらの実行は重なり合う場合もある。たとえば、フェーズＩを実行しているメッセージがフェーズＩＩを実行しているメッセージのうちの一部と同時に送られる場合もある。

すべてのユーザーおよびすべてのサーバーはプロトコルに携わる前にセットアップフェーズを実行しなければならない。このフェーズでは、すべての必要な長期的な鍵およびユーザープロファイルが作成される。いったん実行されると、セキュリティ問題が生じたまたはユーザーステータスが変更された場合でない限り、再びセットアップフェーズを実行することが必要になることは通常ない。

フェーズＩでは、クライアントプラットフォームおよびサーバーが非公開セッション鍵を共有することができ、その後、フェーズＩＩでは、両方が、非公開セッション鍵を用いてユーザープロファイルの転送を保護することができるようにすることが意図されている。

フェーズＩＩでは、クライアントがサーバーにプロファイルを（機密性を保持しながら）要求するが、この要求については、フェーズＩで作成したセッション鍵を用いて確認することができる。この要求には、たとえば、どのタイプの鍵が必要となるか示されていてもよい。次いで、サーバーは、ユーザーに送るためのプロファイルの適切な部分部分を選択し、必要な短期間用の鍵ペアおよび／または秘密鍵を作成し、必要な短期間用の公開鍵証明書を作成し、ユーザーのもとへ送られる資料を作る。次いで、このプロファイルデータのパッケージはフェーズＩで作成されたセッション鍵を用いて暗号化されて完全性が保護され、そして、そのパッケージがクライアントへ送られる。クライアントは、プロファイルデータをサーバーから受け取ると、このプロファイルデータを検証し、解読し、情報を処理し、いつでも使えるようにする。
セットアップフェーズ
この予備フェーズの目的は、スキームにかかわるパーティーにプロトコルに参加するのに必要となるリソースを提供することにある。ここでの説明は、サーバーに対するセットアップ要件、ユーザーに対するセットアップ要件およびクライアントに対するセットアップ要件を対象にした３つの部分に分割される。
サーバーのセットアップ
スキームを支えるサーバーを確立させるために、次のステップが実行される。
１．必要なソフトウェアがインストールされる。
２．ユーザープロファイルおよびユーザーパスワードを機密性を保持しながら格納することができるように準備が行なわれる。
ユーザーのセットアップ
ユーザーがスキームを用い始めるために、次のステップが実行される。
１．ユーザーはサーバーとの関係を確立する。これは、たとえば、料金を支払う契約関係（サーバーがユーザーに対してサービスを提供する）であってもよいし、または、サーバーが雇用者によってまたは雇用者の代わりに運用される場合においてユーザーの職業（雇用）により「デフォルト」で生じる関係であってもよい。
２．ユーザーは、ユーザー公開鍵のための証明書を作成する責務を有する１つ以上の証明機関（ＣＡ）を選択する。もちろん、サーバーとユーザーとの間の関係に応じて、このことは、ユーザーのためにサーバーによって自動的に実行されるようになっていてもよい。
３．ユーザーは、サーバーと共有の秘密パスワードを作成する。
４．サーバーは、ユーザーのプロファイルを作成する。ユーザーは、どのタイプの鍵が必要かを指定する（または、自動的に選択されている）。次いで、サーバーは必要な秘密鍵および非対称鍵ペアを作成し、１つ以上のＣＡから、公開鍵用の証明書を取得する。（ユーザープロファイルの一部として必要とされる長期的な鍵のみがシグネチャ用の鍵ペアとされうることに留意されたい。）
５．次いで、サーバーは、ユーザーパスワードまたは他のユーザー識別情報と共に、（たとえば、秘密鍵、非対称鍵ペアおよびそれに伴う公開鍵証明書を含む）プロファイルを機密性を保持しながら格納する。各鍵が、用いられるアルゴリズムのための識別子、意図する用途（たとえば、暗号化、ＭＡＣの生成、シグネチャの生成など）、および有効期間を含む、それに伴うなんらかの情報を有していることに留意されたい。
クライアントのセットアップ
ユーザーがスキームの一部としてクライアントデバイスを用いるために次のステップが実行される。
１．適切なソフトウェアがクライアントに搭載される（しかしながら、このことは、たとえば使用時にＪａｖａ（登録商標）アプレットとしてソフトウェアをサーバーからダウンロードすることによって動的に実行されてもよい）。
２．クライアントマシンのＴＰＭを初期化し、クライアントマシン上で用いられるタイプのＴＰＭまたは他の機密性保持環境を備えているプラットフォームにサーバーが対処することができるようにする。
フェーズＩ
このフェーズの主な目的は、クライアントマシンとサーバーとの間の短期的な非公開セッション鍵を作成することにある。次に、プロトコルのこのフェーズを実現することができる方法について説明する。

信頼できるソフトウェアが実行されているプラットフォームだけにプロファイルが利用可能とすることを担保するために、受益者（クライアント）のプラットフォーム上のソフトウェア環境を検証するトラスティッドコンピューティング機能を用いることができることに留意されたい。このことは、信頼できるプラットフォームのみが短期的なセッション鍵にアクセスすることができるようになされるべきである。この鍵なしでは、サーバーからクライアントへ送られるプロファイルを解読することができないため、クライアントが利用することができない。すなわち、短期的なセッション鍵へのアクセスを通じて、ポリシー制御がなされている。

次に、短期的な鍵を作成することが可能な手段について説明する。このプロセスがトラスティッドコンピューティングによって実現されるいくつかの方法については、後で説明する。
簡単なアプローチ
非常に簡単なアプローチは、両方のパーティーが共有秘密パスワードから鍵を簡単に導き出すことである。セッション毎に異なる鍵が使用されることを担保するために、２つのパーティーのうちの一方がまずたとえば１２８ビットからなる乱数ｒを生成し、それを他方のパーティーへ送る。次いで、サーバーおよびクライアントは、Ｋ＝ｈ（ｐ｜｜ｒ）であるセッション鍵を作成する。ここで、ｈは暗号化ハッシュ関数（たとえば、ＳＨＡ−２５６、［５］）であり、ｐはユーザーの秘密パスワードであり、｜｜は、ビット列の連結を表している。

非常に簡単であるものの、このようなアプローチは深刻な弱点を有している。攻撃者がｒを傍受し、さらにセッション鍵Ｋを用いて暗号化されたなんらかのデータを傍受すれば、ｐが非常に小さな数の可能性（選択肢）からなるセットから取り出されたものである場合、次のオフラインでの辞書攻撃が可能となる。
−攻撃者は一つずつあらゆる可能性のあるパスワードのセットを試み、以下のような簡単な方法で間違った「推測」を除いていく。たとえば、ｐ^*がパスワードの候補値であると仮定する。攻撃者は、それに対応するセッション鍵の候補Ｋ^*＝ｈ（ｐ^*｜｜ｒ）を傍受したｒの値を用いて演算する。次いで、攻撃者は、Ｋ^*を用いて、傍受した暗号文を解読してみて、その解読の結果が意味のある平文にならなければ、そのパスワードの候補を除外することができる。

もっとはっきりいえば、このような攻撃を防ぐために得られる十分に大きなパスワードのセットを簡単に記憶するのは若干難しいことである。しかしながら、ユーザーが８つの文字からなるパスワードを選択したと仮定しても、各文字が符号か数字のいずれかである場合、考えられうるパスワードの数は、３６⁸、すなわち約２．８×１０¹²しかない。このサイズのセットを試みるのは（容易なことではないが）実行不可能なことではない。

したがって、たとえば以下に提案されている道筋に沿ったもっとロバストなアプローチを用いることが望ましい。
ＳＳＬに基づくアプローチ
他の比較的簡単なアプローチは、クライアントマシンとのセキュアソケットレイヤー（ＳＳＬ）セッションをまず開始することをサーバーに要求することである。クライアントマシンは、セッションが適切なサーバーと開始されていることを検証する手段を有する必要がある。このことは、たとえば、クライアントにダウンロードされているソフトウェアがサーバーの公開鍵の信頼できるコピーを前もって装備していてもよい。

いったんＳＳＬセッションが実施されると、クライアントのソフトウェアは、ユーザーにそのユーザーのパスワードを入力するように促し、このパスワードは検証のために（ＳＳＬチャネルを経由して）サーバーへ送られる。パスワードは、（ＳＳＬによって実現されるような）暗号化されたチャネルを通じて伝達されるので、傍受者による危険性から保護される。

ＳＳＬチャネルは、プロファイルを転送するための安全な手段を提供するために、フェーズＩＩでも用いられうる。

このようなアプローチには１つの大きな欠点がある。クライアントは、当該クライアントが正しいサーバーと通信していることを検証する手段を有していなければならず、そうでなければ、中間者攻撃が開始される場合もある。クライアントにより用いられるソフトウェアがサーバーの公開鍵を有している場合にはこの問題は回避されることになるが、このことは、クライアントマシン上で用いられるソフトウェアを、ユーザーが信頼関係を有しているサーバーの公開鍵を備えるように独自なものとしなければならないことを意味する。

このように構成することが難しい場合が存在する。上述の問題は以下に記載の解決策によって回避される。
標準ベースのアプローチ
オフラインでの辞書攻撃が行えないようにユーザー記憶可能パスワードを用いて非公開セッション鍵を作成することを可能とするように設計される定評あるプロトコルが数多くある。さらに、より積極的な攻撃をくじくようにプロトコルを設計することもできる（認証の試みの失敗を数えて適切な対応策をとるためのなんらかの手段が設けられている限り）。

このような３つのプロトコルが、ＩＳＯ／ＩＥＣ １１７７０−４［６］の第６節に記載されており、鍵承認メカニズム１、２、３と呼ばれている。これらのすべてメカニズムが機密性がある（安全である）と考えられており、これらのメカニズムのうちのいずれであっても本スキームにおいて用いるのに適している。次に、これらのメカニズムの相対的な利点および欠点について検討する。
機密性保持特性
ＩＳＯ／ＩＥＣ １１７７０−４の３つのすべてのメカニズムはよく似た機密性保持を有している。ただ一つの大きな差（現在の知識では）は、メカニズム１では、サーバーがパスワードを知っていることが必要となるが、他の２つのメカニズムでは、サーバーがパスワードのハッシュを格納することが必要となるだけである。この後者の特性はいくつかの（小さな）実用上の長所を有しうる。
実現する上での問題点
これらの選択肢の間には特性の点において次のような差がいくつか存在している。
−メカニズム１（ＳＰＥＫＥ）は３つのメッセージフローを用いて実行することができ、
メカニズム２（ＳＲＰ６）およびメカニズム３（ＡＭＰ）は少なくとも４つのメッセージフローを必要とする。
−メカニズム１およびメカニズム３は、「標準的な」離散的ログ設定（ｄｉｓｃｒｅｔｅ ｌｏｇ ｓｅｔｔｉｎｇ）および楕円曲線設定（ｅｌｌｉｐｔｉｃ ｃｕｒｖｅ ｓｅｔｔｉｎｇ）の両方で実行することができる。
−メカニズム２は、「標準的な」離散的ログ設定のみで実行することができる。
−３つのすべてのメカニズムの計算コストはほぼ同じと考えられるが、差は詳細にチェックされていない。
ＳＰＥＫＥを用いた実現
上述の説明を明瞭にするために、ＩＳＯ／ＩＥＣ １１７７０−４のメカニズム１が用いられる場合のフェーズＩについて簡単に説明する。
１．ユーザー名およびパスワードを提供する。ユーザーは、クライアントのソフトウェアを実行し、ユーザーの名前およびパスワードをそのソフトウェアに与える必要がある。このステージにおいて、ユーザーが追加情報、たとえば当該ユーザーがサーバーからダウンロードしたい鍵のタイプを提供することは適切なことである（このような情報はフェーズＩＩで用いられうる）。
２．プロファイルを要求する（フェーズＩ）。クライアントのソフトウェアは、プロファイルをダウンロードするプロセスの開始を要求するためのメッセージをサーバーへ送る。
３．セッション鍵を作成する（フェーズＩ）。ここで、サーバーおよびクライアントは、共有秘密鍵を作成するために、ＩＳＯ／ＩＥＣ １１７７０−４［６］の第６．１節に記載のようなＳＰＥＫＥプロトコル用いる。

以下に、ステップ２およびステップ３がどのように実行されるかについてもう少し詳細に説明する。ＩＳＯ／ＩＥＣ １１７７０−４［６］の第６．１節の記載を参照する。クライアントが１１７７０−４のＡに相当し、サーバーがＢに相当すると仮定する。
１．クライアントのソフトウェアは、ユーザーが入力したパスワードπを用いて、第６．１．３節に記載の鍵トークン構築ステップ（Ａ１）を実行する。
２．クライアントのソフトウェアは、ユーザー名およびプロファイルのダウンロードを開始する要求とともに、ｗ_AをＢに送る。
３．クライアントからのメッセージの受け取ると、サーバーは、ユーザーパスワードπを（ユーザー名によってインデックスが付された）ユーザープロファイルから回収（ｒｅｃｏｖｅｒ）し、πを用いて第６．１．３節に記載の鍵トークン構築ステップ（Ｂ１）を実行する。
４．サーバーはｗ_BをＡに送る。
５．サーバーは、ステップＢ２において受け取ったｗ_Aの値を用いて共有秘密鍵Ｋ_iを取得する。
６．サーバーからのメッセージを受け取ると、クライアントは、ステップＡ２において受け取ったｗ_Bの値を用いて共有秘密鍵Ｋ_iをさらに取得する。

フェーズＩＩがある程度の（一方向の）鍵の確認を行っているので、鍵確認ステップが省略されていることに留意されたい。上述のステップ２において、クライアント（Ａ）が任意のセッション識別子を作成し、それをサーバー（Ｂ）へ送ることは有益でありうることに留意されたい。次いで、サーバーは、ステップ４で、セッション識別子をクライアントへ送り返すことにより、クライアントにおいて応答を要求と合致させることができるようにする。
フェーズＩＩ
このフェーズの主な目的は、ユーザープロファイルデータをサーバーからクライアントマシンへ機密性を保持しながらダウンロードすることにある。

このことを実現することができる方法はいろいろある。ここでは、１つの選択肢について説明する。

転送プロトコルは次の一般的な形態をとる。
１．クライアント→サーバー：プロファイルの要求
この要求メッセージにより、クライアントマシンによりどのタイプの鍵が必要とされているかが特定される。たとえば、ユーザーがシグネチャ操作しか実行する必要がないのであれば、ユーザーに提供されるプロファイル情報には、シグネチャ私有鍵（および、それに対応する公開鍵の証明書）が含まれている必要があるだけである。

このメッセージはフェーズＩのメッセージのうちの１つのメッセージと同時に送られてもよいということに留意されたい。しかしながら、このメッセージの完全性を保護し、そして、場合によってはこのメッセージを暗号化することが必要な場合もある。そのような場合、このメッセージは、クライアントマシンがセッション鍵のコピーを取得した後でのみ送ることができる。
２．サーバー：プロファイルの作成
いったんサーバーにより要求が受け取られると（そして検証されると）、サーバーは、クライアントマシンへ送られるデータを作成するのに必要となるタスクを実行する。

次いで、すべての必要な鍵および証明書がフォーマット済みプロファイルの中に入れられ、いつでもクライアントへダウンロードできる状態にされる。
３．サーバー→クライアント：暗号化されたプロファイル
いったん鍵と証明書とを含むプロファイルデータがサーバーにより構築されると、当該プロファイルデータをクライアントへ送ることができる。プロファイルデータは、送信に先立って、サーバーによりセッション鍵を用いて暗号化される必要がある。暗号化の方法は機密性および完全性の保護の両方を提供する必要があり、ＩＳＯ／ＩＥＣ １９７７２［７］に記載の技術のうちの１つが強く推奨される。

このメッセージは、必要なセッション鍵がサーバーより入手可能な限り、フェーズＩのメッセージうちの１つのメッセージと同時に送ることができることに留意されたい。
４．クライアント：プロファイルを受け取るプロセス
最後に、クライアントは、暗号化されたプロファイルを受け取ると、非公開セッション鍵を用いて、それを検証し、解読することができる。

上述のように、通常、プロファイルはユーザー毎に作成される。ユーザープロファイルには、さまざまな鍵および証明書が含まれている。次いで、セッションが開始される毎に、これらの鍵および証明書のうちの一部または全部がクライアントマシンへ送られうる。

このアプローチは、必要なすべての鍵が前もって作成されているので、クライアントがプロファイルを要求したときにサーバーが新たに鍵や証明書を作成する必要がないという利点を有している。さらに、各公開鍵には、それに付随しかつ信頼できるＣＡにより署名された単一の証明書が存在する。

しかしながら、このアプローチは、クライアントマシンがいつか危険にさらされるようなことがあった場合、ユーザーの長期的な私有鍵も危険にさらされることになるという欠点を有している。さらに、鍵の取り消しが可能であるものの、危険が検出された場合にのみ取り消しができるようになるのであって、必ずしも危険が検出されるとは限らない。

最後に、クライアントホストにおける他のアプリケーションに鍵および／または証明書を提供するためにプロファイルの中身を「出す」必要がありうることに留意されたい。そのとき、私有鍵が本発明のシステムが直接に制御できる範囲の外側にある場合、これらの鍵がセッションの終わりに削除されていることを担保することが難しい場合もある。
トラスティッドコンピューティングの使用
クライアントデバイスが信頼できない可能性がある場合、機密性保持に関して大きな危険が伴うことになる。サーバーが、クライアントにプロファイルをダウンロードする前にはクライアントにおいて正しいソフトウェアが実行されていたこと（そしてクライアントのオペレーティングシステム環境には機密性が保持されていたこと）を検証することができる場合、プロファイルの機密性を著しく向上させることができる。

このような機能はトラスティッドコンピューティングによって提供されている（たとえば、［８］を参照）。今日、この技術は、トラスティッドプラットフォームモジュール（ＴＰＭ）として知られている特定用途セキュリティチップという形態で、かなりの割合の新しいＰＣに用いられている。この技術により、１つのデバイスが、他のプラットフォーム上で稼働しているソフトウェアの特性を遠隔から検証し、特定のソフトウェア構成についての秘密へのアクセスを制限することが可能となる。これらの特性は、上述のオペレーショナルモデルに理想的に適しているように思われる。

以下では、トラスティッドコンピューティング機能について記載する。トラスティッドコンピューティング機能を用いてプロファイル転送プロセスポリシーを管理することができる。上述のように、このことには、サーバーが遠隔のクライアントプラットフォームの状態に満足しているという条件で短期的なセッション鍵へアクセスすることが含まれる。
関連する作業
遠隔のプラットフォームがある状態である（トラスティッドコンピューティング機能を用いたテストによって示される）場合にのみある事柄が生じることを許可するという一般的概念は定着した考えである。トラスティッドネットワークコネクトプロトコル（ＴＮＣ）では、クライアントＰＣをネットワークに受け入れるべきか否かを判断するためにトラスティッドコンピューティングが用いられている。サーバーは、ネットワークにクライアントを入れるべきかどうか決定する前に、クライアントにそのソフトウェア構成の証拠の提供を要求する。ＴＮＣはトラスティッドコンピューティンググループにより標準化されている（ｈｔｔｐ：／／ｗｗｗ．ｔｒｕｓｔｅｄｃｏｍｐｕｔｉｎｇｇｒｏｕｐ．ｏｒｇ／）。そのオペレーションについての簡単な説明に関しては、たとえばレボックおよびハント（Ｒｅｈｂｏｃｋ ａｎｄ Ｈｕｎｔ）［９］を参照されたい。

この一般的な考えが、機密性の高いソフトウェアを信頼できる状態でかつ検証可能なプラットフォームへダウンロードすることのみによって当該ソフトウェアを保護する手法として提案されている。この考えは、ギャラリー（Ｇａｌｌｅｒｙ）、トムリンソン（Ｔｏｍｌｉｎｓｏｎ）、デリカタ（Ｄｅｌｉｃａｔａ）およびミッチェル（Ｍｉｔｃｈｅｌｌ）により報告されている［１］、［２］、［３］、［４］。
簡単なアプローチ
最も簡単なアプローチは、サーバーが、秘密鍵の承認プロセスの開始直前に、信頼できるプラットフォームにその現在のソフトウェア構成を証明することを要求することである。このことは、クライアントプラットフォームがＴＰＭを有し、クライアント上のソフトウェアがこのＴＰＭを用いてクライアントプラットフォームの現在状況を示す測定値をＴＰＭ内のＰＣＲ（プラットフォーム構成レジスタ）内に格納することができることを仮定している。次いで、認証プロセスは、以下の道筋に沿って進められる。

１．サーバーは、確認したいＰＣＲのシリアル番号の値とともに、ランダムなチャレンジ（ｒａｎｄｏｍ ｃｈａｌｌｅｎｇｅ）をクライアントに送る。
２．クライアントは、情報をクライアントのＴＰＭに渡し、ＴＰＭは、ランダムチャレンジおよび要求されたＰＣＲの現在値を（それらのインデックスとともに）有しているストリング（文字列）にデジタル署名する。
３．次いで、このシグネチャは、サーバーに返送され、サーバーは、シグネチャを検証（および、ランダムチャレンジのフレシュネスをチェック）することにより、これらのＰＣＲ値がクライアントプラットフォームの現在のソフトウェア状態の正確な記録であることを検証することができる。

このシグネチャは、構成証明識別鍵、すなわち私的な値がＴＰＭにのみ入手可能となるシグネチャ鍵を用いて演算される。それに対応する公開鍵（シグネチャを検証するために用いられる）の有効性は、サーバーがクライアントにより提供される公開鍵証明書をチェックすることによって検証することができる。

次いで、サーバーは、これらのＰＣＲ値が、対象となるユーザープロファイルと関連するポリシーの命令文によって許容可能であると見なされるソフトウェア構成と一致することを検証することができる。ポリシーによりこの設定が許容可能であると見なされる場合にのみ、上述のように、サーバーは共有秘密鍵を作成するように進む。
さらにロバストなアプローチ
直前に説明されたアプローチの１つの問題は、クライアントのソフトウェアの状態が、測定が行われる時間と、（すぐ後の）共有秘密鍵が作成される時間との間で変わる可能性があることである。この問題は、認証のプロセスと共有秘密鍵の作成とを組み合わせることにより取り除くことができる。このことを実現する方法は文献に説明されている。たとえば、ギャラリー（Ｇａｌｌｅｒｙ）、トムリンソン（Ｔｏｍｌｉｎｓｏｎ）、デリカタ（Ｄｅｌｉｃａｔａ）およびミッチェル（Ｍｉｔｃｈｅｌｌ）［１］、［２］、［３］、［４］を参照されたい。
引用文献
［１］イー・ギャラリー（Ｅ．Ｇａｌｌｅｒｙ）およびエイ・トムリンソン（Ａ．Ｔｏｍｌｉｎｓｏｎ）、「モバイルレシーバーへの条件付きアクセスアプリケーションの安全な配信（Ｓｅｃｕｒｅ ｄｅｌｉｖｅｒｙ ｏｆ ｃｏｎｄｉｔｉｏｎａｌ ａｃｃｅｓｓ ａｐｐｌｉｃａｔｉｏｎｓ ｔｏ ｍｏｂｉｌｅ ｒｅｃｅｉｖｅｒｓ）」、シー・ジェイ・ミッチェル（Ｃ．Ｊ．Ｍｉｔｃｈｅｌｌ）（編集））、トラスティッドコンピューティング、ＩＥＥプレス、ページ１９５〜２３７、２００５年
［２］イー・ギャラリー（Ｅ．Ｇａｌｌｅｒｙ）およびエイ・トムリンソン（Ａ．Ｔｏｍｌｉｎｓｏｎ）、「ＳＤＲデバイス上のダウンロード可能なソフトウェアの保護（Ｐｒｏｔｅｃｔｉｏｎ ｏｆ Ｄｏｗｎｌｏａｄａｂｌｅ Ｓｏｆｔｗａｒｅ ｏｎ ＳＤＲ Ｄｅｖｉｃｅｓ）」、ソフトウェア無線技術会議ＳＤＲ ０５、２００５年１１月
［３］イー・ギャラリー（Ｅ．Ｇａｌｌｅｒｙ）、エイ・トムリンソン（Ａ．Ｔｏｍｌｉｎｓｏｎ）およびアール・デリカタ（Ｒ．Ｄｅｌｉｃａｔａ）、「モバイルレシーバーへの安全なビデオブロードキャストへのトラスティッドコンピューティングの応用（Ａｐｐｌｉｃａｔｉｏｎ ｏｆ Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ ｔｏ Ｓｅｃｕｒｅ Ｖｉｄｅｏ Ｂｒｏａｄｃａｓｔｓ ｔｏ Ｍｏｂｉｌｅ ｅｃｅｉｖｅｒｓ）」、技術報告書ＲＨＵＬ−ＭＡ−２００５−１１、ロンドン大学、ロイヤル・ホロウェー、数学科、２００５年６月。
［４］イー・エム・ギャラリー（Ｅ．Ｍ．Ｇａｌｌｅｒｙ）およびシー・ジェイ・ミッチェル（Ｃ．Ｊ．Ｍｉｔｃｈｅｌｌ）、「トラスティッドコンピューティング技術および高度保証ＳＤＲプラットフォーム設備おけるその利用（Ｔｒｕｓｔｅｄ ｃｏｍｐｕｔｉｎｇ ｔｅｃｈｎｏｌｏｇｉｅｓ ａｎｄ ｔｈｅｉｒ ｕｓｅ ｉｎ ｔｈｅ ｐｒｏｖｉｓｉｏｎ ｏｆ ｈｉｇｈ ａｓｓｕｒａｎｃｅ ＳＤＲ ｐｌａｔｆｏｒｍ）」、２００６年ソフトウェア無線技術会議会議録、フロリダ州オーランド、２００６年１１月
［５］ＩＳＯ／ＩＥＣ １０１１８−３：２００３、「情報技術−安全技術−ハッシュ関数：パート３：専用ハッシュ関数（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ−Ｓｅｃｕｒｉｔｙ ｔｅｃｈｎｉｑｕｅｓ−Ｈａｓｈ−ｆｕｎｃｔｉｏｎｓ：Ｐａｒｔ３：Ｄｅｌｉｃａｔｅｄ ｈａｓｈ−ｆｕｎｃｔｉｏｎｓ）」、国際標準化機構、ジュネーブ、２００３年。
［６］ＩＳＯ／ＩＥＣ １１７７０−４：２００６、「情報技術−安全技術−鍵管理：パート４：低い秘密性に基づいたメカニズム（Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｓｅｃｕｒｉｔｙ ｔｅｃｈｎｉｑｕｅｓ−Ｋｅｙ ｍａｎａｇｅｍｅｎｔ：Ｐａｒｔ４：Ｍｅｃｈａｎｉｓｍ ｂａｓｅｄ ｏｎ ｗｅａｋ ｓｅｃｒｅｔｓ）」、国際標準化機構、ジュネーブ、２００６年
［７］ＩＳＯ／ＩＥＣ １９７７２：２００９、「情報技術−安全技術−認証付暗号化方式（Ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ−Ｓｅｃｕｒｉｔｙ ｔｅｃｈｎｉｑｕｅｓ−Ａｕｔｈｅｎｔｉｃａｔｅｄ ｅｎｃｒｙｐｔｉｏｎ）」、国際標準化機構、ジュネーブ、２００９年
［８］シー・ミッチェル（Ｃ．Ｍｉｔｃｈｅｌｌ）（編集）、「トラスティッドコンピューティング」、ＩＥＥプレス、ロンドン、２００５年
［９］エス・レボック（Ｓ．Ｒｅｈｂｏｃｋ）およびアール・ハント（Ｒ．Ｈｕｎｔ）、「信頼できるクライアント：ＴＮＣのウェブベース環境への拡張（Ｔｕｓｔｗｏｒｔｈｙ ｃｌｉｎｅｔｓ：Ｅｘｔｅｎｄｉｎｇ ＴＮＣ ｔｏ ｗｅｂ−ｂａｓｅｄ ｅｎｖｉｒｏｎｍｅｎｔｓ）」、コンピューター通信、３２、ページ１００６〜１０１３、２００９年

Claims (15)

1. クライアントデバイスにより、暗号を用いた署名操作を実行するために遠隔サーバーに格納されている、ユーザーに固有の暗号鍵にアクセスする方法であって、
   ユーザーの識別情報を特定することと、
   前記リモートサーバにより、前記クライアントデバイスの識別情報を認証することであって、前記リモートサーバにより認証されることを可能とするために前記クライアントデバイスのセキュア暗号プロセッサを用いて暗号処理により認証することと、
   前記ユーザーの識別情報および前記クライアントデバイスの識別情報が前記遠隔サーバーに格納されているアクセス条件を満たすか否かを判断することと、
   前記アクセス条件が満たされている場合、前記ユーザーに固有の暗号鍵を前記遠隔サーバーから前記クライアントデバイスへ機密性を保持しながら送信することと、
   前記クライアントデバイスにより、前記ユーザーに前記暗号鍵を知らせることなく、該暗号鍵を用いて前記セキュア暗号プロセッサによりデータに署名することと
   を含む、方法。
2. 前記セキュア暗号プロセッサがトラスティッドプラットフォームモジュールを有している、請求項１に記載の方法。
3. 前記クライアントデバイスが、前記暗号鍵を揮発性メモリーに保持し、前記暗号を用いた署名操作を実行した後、前記暗号鍵を前記メモリーから消去することを含む、請求項１または２に記載の方法。
4. 前記サーバーが前記クライアントデバイスの識別情報を認証することを含む、請求項１乃至３のうちのいずれか一項に記載の方法。
5. 前記サーバーが前記ユーザーの識別情報を検証することを含む、請求項１乃至４のうちのいずれか一項に記載の方法。
6. 前記クライアントデバイスが前記サーバーの識別情報を認証することを含む、請求項１乃至５のうちのいずれか一項に記載の方法。
7. 前記遠隔サーバーが前記暗号鍵と共に１つ以上の証明書を送信することを含む、請求項１乃至６のうちのいずれか一項に記載の方法。
8. セキュア暗号プロセッサを備えるクライアントデバイスであって、
   前記リモートサーバにより、前記セキュア暗号プロセッサを用いて前記クライアントデバイスの識別情報を暗号処理により認証し、
   遠隔サーバーから機密性を保持しながら送信されるユーザーに固有の暗号鍵を受け取り、
   前記暗号鍵をユーザーに開示することなく、前記暗号鍵を用いて前記セキュア暗号プロセッサによりデータに署名するように構成されてなる、クライアントデバイス。
9. 前記クライアントデバイスがトラスティッドプラットフォームモジュールを有してなる、請求項８に記載のクライアントデバイス。
10. 前記クライアントデバイスが、前記暗号鍵を揮発性メモリーに保持し、前記データに署名する前記暗号操作を実行した後、前記メモリーから前記暗号鍵を消去するように構成されてなる、請求項８または９に記載のクライアントデバイス。
11. 前記サーバーの識別情報を認証するように構成されてなる、請求項８乃至１０のうちのいずれか一項に記載のクライアントデバイス。
12. （ｉ）暗号を用いた署名操作を実行するための、ユーザーに固有の暗号鍵、および、（ｉｉ）アクセス条件、が格納されているサーバーであって、
    前記サーバーが、
    ユーザーの識別情報およびクライアントデバイスの識別情報が前記アクセス条件を満たすか否かを判断し、
    前記アクセス条件が満たされている場合、前記クライアントデバイスへ前記暗号鍵を機密性を保持しながら送信するように構成されてなる、サーバー。
13. 前記サーバーが前記クライアントデバイスの識別情報を認証するように構成されてなる、請求項１２に記載のサーバー。
14. 前記サーバーが前記ユーザーの識別情報を検証するように構成されてなる、請求項１２または１３に記載のサーバー。
15. 前記サーバーが、前記暗号鍵と共に、１つ以上の証明書を送信するように構成されてなる、請求項１２乃至１４のうちのいずれか一項に記載のサーバー。