暗号操作を実行するために遠隔サーバーに格納されている暗号鍵にアクセスする方法であって、ユーザーの識別情報を特定することと、クライアントデバイスの識別情報を暗号処理により認証することと、前記ユーザーの識別情報および前記クライアントデバイスの識別情報が前記遠隔サーバーに格納されているアクセス条件を満たすか否かを判断することと、前記アクセス条件が満たされている場合、前記暗号鍵を前記遠隔サーバーから前記クライアントデバイスへ機密性を保持しながら送信することと、前記ユーザーに前記暗号鍵を知らせることなく、該暗号鍵を用いて暗号操作を実行することとを含む、方法。前記方法が、前記クライアントデバイスに暗号化された形態で格納されているデータへのユーザーアクセスを管理するのに適し、前記暗号操作が前記データを解読することを含み、前記方法が、解読された前記データへの前記ユーザーのアクセスを可能とすることをさらに含む、請求項1に記載の方法。前記暗号操作が、データを暗号化することまたはデータに署名することを含む、請求項1または2に記載の方法。前記クライアントデバイスがセキュア暗号プロセッサを有している、請求項1乃至3のうちのいずれか一項に記載の方法。前記クライアントデバイスがトラスティッドプラットフォームモジュールを有している、請求項1乃至4のうちのいずれか一項に記載の方法。セキュア暗号プロセッサを用いて、前記クライアントデバイスの識別情報を暗号処理により認証するまたは前記暗号操作を実行することを可能とすることを含む、請求項1乃至5のうちのいずれか一項に記載の方法。前記クライアントデバイスが、マイクロコントローラまたは中央処理装置のソフトウェアを実行して、前記デバイスの前記識別情報を暗号処理により認証することを可能とすることまたは前記暗号操作を実行することを含む、請求項1乃至4のうちのいずれか一項に記載の方法。前記クライアントデバイスが、前記暗号鍵を揮発性メモリーに保持し、前記暗号操作を実行した後、前記暗号鍵を前記をメモリーから消去することを含む、請求項1乃至7のうちのいずれか一項に記載の方法。前記サーバーが前記クライアントデバイスの識別情報を認証することを含む、請求項1乃至8のうちのいずれか一項に記載の方法。前記サーバーが前記ユーザーの識別情報を検証することを含む、請求項1乃至9のうちのいずれか一項に記載の方法。前記クライアントデバイスが前記サーバーの識別情報を認証することを含む、請求項1乃至10のうちのいずれか一項に記載の方法。前記暗号鍵が前記ユーザーに固有のものである、請求項1乃至11のうちのいずれか一項に記載の方法。前記遠隔サーバーが前記暗号鍵と共に1つ以上の証明書を送信することを含む、請求項1乃至12のうちのいずれか一項に記載の方法。前記遠隔サーバーが前記クライアントデバイスに複数の暗号鍵を送信することを含む、請求項1乃至13のうちのいずれか一項に記載の方法。デバイスの識別情報を暗号処理により認証し、遠隔サーバーから機密性を保持しながら送信される暗号鍵を受け取り、前記暗号鍵をユーザーに開示することなく、前記暗号鍵を用いて暗号操作を行うように構成されてなる、クライアントデバイス。データが前記クライアントデバイスに暗号化された形態で格納されており、前記クライアントデバイスが、前記暗号鍵を用いて前記データを解読し、解読された前記データへのユーザーのアクセスを可能とするように構成されてなる、請求項15に記載のクライアントデバイス。前記暗号操作が、データを暗号化することまたはデータに署名することを含んでなる、請求項15または16に記載のクライアントデバイス。前記クライアントデバイスがセキュア暗号プロセッサを有してなる、請求項15乃至17のうちのいずれか一項に記載のクライアントデバイス。前記クライアントデバイスがトラスティッドプラットフォームモジュールを有してなる、請求項15乃至18のうちのいずれか一項に記載のクライアントデバイス。前記クライアントデバイスが、セキュア暗号プロセッサを用いて、前記クライアントデバイスの前記識別情報を暗号処理により認証するまたは前記暗号操作を実行することを可能とするように構成されてなる、請求項15乃至19のうちのいずれか一項に記載のクライアントデバイス。前記クライアントデバイスが、マイクロコントローラまたは中央処理装置のソフトウェアを実行して、前記デバイスの前記識別情報を暗号処理により認証することを可能とするまたは前記暗号操作を実行するように構成されてなる、請求項15乃至20のうちのいずれか一項に記載のクライアントデバイス。前記クライアントデバイスが、前記暗号鍵を揮発性メモリーに保持し、前記暗号操作を実行した後、前記メモリーから前記暗号鍵を消去するように構成されてなる、請求項15乃至21のうちのいずれか一項に記載のクライアントデバイス。前記サーバーの識別情報を認証するように構成されてなる、請求項15乃至22のうちのいずれか一項に記載のクライアントデバイス。暗号鍵およびアクセス条件が格納されているサーバーであって、前記サーバーが、ユーザーの識別情報およびクライアントデバイスの識別情報が前記アクセス条件を満たすか否かを判断し、前記アクセス条件が満たされている場合、前記クライアントデバイスへ前記暗号鍵を機密性を保持しながら送信するように構成されてなる、サーバー。前記アクセス条件が前記クライアントデバイスに暗号化された形態で格納されているデータに関連してなる、請求項24に記載のサーバー。前記サーバーが前記クライアントデバイスの識別情報を認証するように構成されてなる、請求項24または25に記載のサーバー。前記サーバーが前記ユーザーの識別情報を検証するように構成されてなる、請求項24乃至26のうちのいずれか一項に記載のサーバー。前記サーバーが、前記暗号鍵と共に、1つ以上の証明書を送信するように構成されてなる、請求項24乃至27のうちのいずれか一項に記載のサーバー。前記サーバーが前記クライアントデバイスへ複数の暗号鍵を送信するように構成されてなる、請求項24乃至28のうちのいずれか一項に記載のサーバー。コンピューターポリシーを施行する方法であって、a暗号鍵を用いて、クライアントデバイス上の機密性の高いデータへのユーザーのアクセスを管理するためにポリシーを定義することと、b前記ポリシーおよびそれに関連する前記暗号鍵をサーバーに格納することと、c前記ユーザーの識別情報を確認し、前記クライアントデバイスの機密性保持環境を通じて前記クライアントデバイスの識別情報および信頼性を暗号処理により認証することと、d前記ポリシーを満たして許可された場合、機密性を保持しながら前記暗号鍵を前記サーバーから前記クライアントデバイスの前記機密性保持環境へ送信することと、e前記ユーザーに前記暗号鍵を開示することなく、機密性の高いデータへの前記ユーザーのアクセスを可能とすることとを含む方法。使用時、前記暗号鍵が前記クライアントデバイスの保護メモリーに保持されている、請求項30に記載の方法。前記クライアントデバイスの前記ユーザーにとって、前記暗号鍵が、暗号化された形態でのみ視認可能である、請求項30に記載の方法。前記機密性保持環境がトラスティッドプラットフォームモジュールTPMであり、前記クライアントデバイスの識別情報および信頼性がTPM認証手法によって検証される、請求項30乃至32のうちのいずれか一項に記載の方法。前記暗号鍵が、TPMシールドストレージにより保護される第二の鍵を用いて暗号化される、請求項32に従属する請求項33に記載の方法。前記ユーザーまたは前記クライアントデバイスがポリシーを満たしていない場合、前記鍵は、前記保護メモリーから前記鍵を削除することにより無効とされる、請求項31に記載の方法。初期設定フェーズ有しており、該フェーズでは、前記サーバーおよび前記クライアントデバイスが非公開セッション鍵を作成して共有するように構成されている、請求項30に記載の方法。ダウンロードフェーズを有しており、該ダウンロードフェーズでは、前記ポリシーおよびそれに関連する暗号鍵が、前記サーバーから前記クライアントデバイスへとダウンロードされ、また、該ダウンロードフェーズが非公開セッション鍵により保護されている、請求項36に記載の方法。個々のユーザーに付随するポリシーおよび暗号鍵が、前もって作成され、前記サーバーにユーザープロファイルとして格納される、請求項30乃至37のうちのいずれか一項に記載の方法。前記ダウンロードフェーズ時、使用中の特定のクライアントデバイスに適用可能な前記プロファイルの部分のみがダウンロードされる、請求項37に従属する請求項38に記載の方法。コンピューターポリシーを施行するためのシステムであって、aクライアントデバイス上の機密性の高いデータおよびそれに関連する暗号鍵へのユーザーのアクセスを管理するためのポリシーが格納されているサーバーと、bユーザーにより操作されるクライアントデバイスであって、ポリシーを満たして許可された場合に、前記ユーザーに前記鍵を開示することなく、前記クライアントデバイス上の暗号化された機密性の高いデータへのユーザーのアクセスを可能とする前記暗号鍵を保持する機密性保持環境を有しているクライアントデバイスと、c前記ユーザーの識別情報を確認し、前記クライアントデバイスの識別情報および信頼性を暗号処理により認証するための手段と、d前記ポリシーを満たして許可された時、機密性を保持しながら、前記暗号鍵を前記サーバーから前記クライアントデバイスの前記機密性保持環境へと送信するための手段とを備えてなる、システム。前記機密性保持環境が、トラスティッドプラットフォームモジュールTPMである、請求項40に記載のシステム。既存のセキュリティポリシーでは、従業員が、オフィスとオフィスとの間を移動し、会社の境界の内側および外側でさまざま異なるコンピューティングデバイスを用いて作業するに際には暗号鍵を複製する必要がある。したがって、既存のセキュリティポリシーの運用は、通常複雑でありかつ多大な時間を必要とする。従業員が会社を辞めるような場合には、従業員の暗号鍵をすべて無効にすることが必要となる。鍵管理についてのこれらの問題は、流動的なかつ常に変動する従業員全員にセキュリティポリシーを強いようとする会社とって相当なコストとなる。本発明の目的は、少なくともこれらの困難を軽減することにある。本発明の第一の態様によれば、コンピューターポリシーを施行する方法が提供されており、かかる方法は、a暗号鍵を用いて、クライアントデバイス上の機密性の高いデータへのユーザーのアクセスを管理するためのポリシーを定義することと、bポリシーおよびそれに関連する暗号鍵をサーバーに格納することと、cユーザーの識別情報を確認し、クライアントデバイスの機密性保持環境を通じてクライアントデバイスの識別情報および信頼性を暗号処理により認証することと、dポリシーを満たして許可された場合、暗号鍵をサーバーからクライアントデバイスの機密性保持環境へと機密性を保持しながら送信することと、eユーザーに暗号鍵を開示することなく、機密性の高いデータへのユーザーのアクセスを可能とすることとを含んでいる。第二の態様によれば、コンピューターポリシーを施行するためのシステムが提供されており、かかるシステムは、aクライアントデバイス上の機密性の高いデータおよびそれに関連する暗号鍵へのユーザーのアクセスを管理するためのポリシーが格納されているサーバーと、bユーザーにより操作されるクライアントデバイスであって、ポリシーを満たして許可されたとき、ユーザーに鍵を開示することなく、クライアントデバイス上の暗号化された機密性の高いデータへのユーザーのアクセスを可能とする暗号鍵を保持する機密性保持環境を有している、クライアントデバイスと、cユーザーの識別情報を確認し、クライアントデバイスの識別情報および信頼性を暗号処理により認証するための手段と、dポリシーを満たして許可されたとき、暗号鍵をサーバーからクライアントデバイスの機密性保持環境へと機密性を保持しながら送信するための手段とを備えている。本発明の他の態様によれば、暗号操作を実行するために遠隔サーバーに格納されている暗号鍵にアクセスする方法が提供されており、かかる方法は、ユーザーの識別情報を判別することと、クライアントデバイスの識別情報を暗号処理により認証することと、ユーザーの識別情報およびクライアントデバイスの識別情報が遠隔サーバーに格納されているアクセス条件を満たすか否かを判断することと、アクセス条件が満たされている場合、暗号鍵を遠隔サーバーからクライアントデバイスへと機密性を保持しながら送信することと、ユーザーに暗号鍵を開示することなく、暗号鍵を用いて暗号操作を実行することとを含んでいる。このような方法は、暗号化された形態でクライアントデバイスに格納されているデータへのユーザーのアクセスを管理するために用いられてもよい。暗号操作には、データを解読することが含まれていてもよい。かかる方法は、ユーザーに暗号鍵を開示することなく、解読されたデータへのユーザーのアクセスを可能とすることをさらに含んでもよい。この態様によれば、クライアントデバイスは、デバイスの識別情報を暗号処理により認証することを可能とし、遠隔サーバーから機密性を保持しながら送信される暗号鍵を受け取り、暗号鍵をユーザーに開示することなく、暗号鍵を用いて暗号操作を実行するように構成されている。データはクライアントデバイスに暗号化された形態で格納されており、クライアントデバイスは、暗号鍵を用いてデータを解読し、解読されたデータへのユーザーのアクセスを可能とするように構成されていてもよい。さらにこの態様によれば、暗号鍵およびアクセス条件が格納されているサーバーは、ユーザーの識別情報およびクライアントデバイスの識別情報がアクセス条件を満たしているか否かを判断し、アクセス条件が満たされている場合、暗号鍵をクライアントデバイスへ機密性を保持しながら送信するように構成されている。アクセス条件は、暗号鍵に関連するものであってもよいし、および/または、クライアントデバイスに暗号化された形態で格納されているデータに関連するものであってもよい。ユーザー識別情報についての概念に加えておよびユーザー識別情報についての概念とは別個に、複雑でもっと意味深いポリシーの定義および施行を可能とするためにマシン識別情報が用いられてもよい。このことにより、システム管理者が、個々のユーザーが何を行うことができるかおよび個々のマシンを用いてユーザーが何を行いうるかを指定することが可能となる。好ましくは、クライアントデバイスはセキュア暗号プロセッサまたはハードウェアセキュリティモジュールを有していてもよい。このようにして、機密性保持環境を提供することができるたとえば、トラスティッドプラットフォームモジュール。好ましくは、このデバイスは、デバイスの識別情報が暗号処理によって認証されることを可能とするためにセキュア暗号プロセッサを用いるように構成されている。好ましくは、このデバイスは、デバイスに格納されているデータを解読するために暗号鍵を用いるというような暗号操作を実行するためにセキュア暗号プロセッサを用いるように構成されている。しかしながら、専用のハードウェアによる機密性保持環境が絶対に必要というわけではなく、実施形態によっては、クライアントデバイスは、マイクロコントローラまたは中央処理装置CPU上で実行されるソフトウェアを用いて機密性保持環境を構築するようにしてもよい。このような手段が、暗号操作を実行する、および/または、デバイスの識別情報を暗号処理により検証することを可能とするために用いられるようになっていてもよい。好ましくは、クライアントデバイスは、暗号鍵を揮発性メモリー例:RAM内に保持し、暗号操作を実行した後は、メモリーから暗号鍵を消去するように構成されている。好ましくは、サーバーはクライアントデバイスの識別情報を認証するように構成されている。ユーザーの識別情報は、クライアントデバイスおよび/または遠隔サーバーによって検証されるようになっていてもよい。クライアントデバイスはサーバーの識別情報を認証するように構成されてもよい。クライアントデバイス上の機密性の高いデータを保護するために用いられるすべての暗号鍵は、中央サーバーに格納されることが好ましく、クライアントマシンのローカルディスクには格納されないことが好ましい。このようにすることにより、ポータブルクライアントデバイスの盗難による衝撃が小さくなる。このようなデバイスに格納されている暗号化されたデータは、それがいかなるデータであっても、必要な解読鍵を入手することができないので、取り出すことはできない。解読されるデータはいかなるタイプのデータであってもよい。たとえば、解読されるデータは、電子メールメッセージの全部または一部を含んでいてもよい。暗号鍵はさまざまな目的のうちのいずれの目的のためにクライアントデバイスによって用いられてもよい。さまざまな目的には、たとえば、データを解読するため、データを暗号化するため、データに署名するため、または遠隔デバイスと安全なセッションを開始するためなどが含まれる。アクセス条件はセキュリティポリシーを構成しうる。コンピューターポリシーを施行する既存の方法に対して、好ましい実施形態では、-暗号鍵データを保護するために用いられるが、クライアントデバイスに長期間格納されない点で好ましく、-システムがデバイスおよびユーザーの両方を遠隔から識別することができ、かつ遠隔デバイスの完全性を検証することができるので、システムは、クライアントデバイスによるクライアント鍵の利用を可能とするか否かを管理するしたがって、ポリシーを施行することができる。このことにより、遠隔デバイスにおいても、サーバーを中心としたポリシーの施行が可能となる。このポリシーは、いかなる分散型環境、たとえばクラウド分散型環境であっても、その全体にわたって施行されうる。暗号鍵はユーザー固有のものであってもよい。遠隔サーバーは、暗号鍵と共に、1つ以上の証明書を送信するようになっていてもよい。遠隔サーバーは、複数の暗号鍵をクライアントデバイスへ送信するようになっていてもよい。実施形態によっては、ユーザー固有の秘密鍵を含んでいるユーザープロファイルのダウンロードを含むポリシー施行のために、トラスティッドコンピューティングが用いられている場合もある。これは他の応用たとえば、トラスティッドソフトウェアのダウンロード応用と次の点で異なっている:-ユーザープロファイルとは、ユーザーに固有のものであり、汎用のソフトウェアのことではない。-ユーザープロファイルの特定の部分へのアクセスをポリシーに基づいて管理することにより、私有の秘密鍵へのアクセスをポリシーに基づいて柔軟に管理することができるようになる。たとえば、ポリシーにより、下級の鍵については、広範囲のクラスのプラットフォームへの公開が許されるものの、上級の鍵については、起こりうるソフトウェア状態の非常に特殊な組合せにある非常に特殊なプラットフォームにのみダウンロードが許されることとしうる。-ユーザープロファイルをポリシーに基づいて管理することにより、暗号鍵へのアクセスが柔軟なものになるので、他にも多くの応用が考えられるようになる暗号鍵自体をさらなるサービスおよび/または情報へのアクセスを管理するために用いることができる。適切な場合、1つの態様における選択的特徴は、それがいかなるものであっても他の態様の選択的特徴となりうる。以下に、本発明のいくつかの好ましい実施形態を記載するが、これらは例示のみを意図したものである。構成要素ある好ましい実施形態は次のデバイスを備えている:1.好ましくはウェブサービスを提供するサーバーコンピューティングデバイス。2.トラスティッドコンピューティンググループ仕様に従うトラスティッドプラットフォームモジュールTPMまたは、同様のセキュリティサービスを提供する任意のデバイスまたはシステムを装備しているユーザーエージェントクライアントデバイス。各ユーザーエージェントのTPMには、公開暗号鍵/私有暗号鍵のペアが搭載され、ユーザーエージェントマシンの固有の識別情報identityの基礎を提供するようになっている。設計方法および不正開封防止特性の付与により、TPM私有鍵は、TPMの外側では入手することができなくなっており、クライアントデバイスの識別情報を窃取することが非常に困難なになっている。クライアントサーバープロトコルサーバーがユーザーエージェントの識別情報を検証し、かつ、ポリシーを施行するにあたってその識別情報を用いるために、次のプロトコルが適用される:1.ユーザーエージェント/クライアントデバイスがサーバーを検証する。このことは、サーバーによって生成されたシグネチャを検証し、サーバーの公開鍵をチェックすることにより実現されるユーザーエージェント内にプログラムされている。2.サーバーがTPMを取り調べることによりユーザーエージェントを検証する。サーバーは、TPMに身分証明を求め、TPMに属する私有鍵を用いてシグネチャを演算するようTPMに要求する。TPMの私有鍵が解読された形態でTPMから出て行くことはないので、たとえば、クライアントプラットフォーム上で起動している悪質なソフトウェアによって盗まれるようなことはありえないことに留意されたい。いったんユーザーエージェントの物理デバイスの識別情報が認証されると、たとえばパスワード、暗号鍵ペアおよび/または生体認証を含む適切なユーザー認証メカニズムを用いて、ユーザーの検証が実行される。このシステムは、デバイスとユーザーとを任意に組み合わせたものの識別を可能とする。すなわち、一人のユーザーが多数のデバイスを使用する場合もあれば、多数のユーザーが単一のデバイスにより用いられる場合もある。次いで、それに応じて、ポリシーが施行されるようになっていてもよい。ユーザーエージェントの遠隔からの検証ポリシーは、たとえば機密性が保持されないインターネットを通じたデータの漏洩を回避するため、企業VPNに接続するとき、管理されていないインターネット接続を動作不能とすることにより、システム機能を制限することができる。このようなポリシーを施行するようにユーザーエージェントをプログラムすることができる。しかしながら、サーバーによる鍵の管理とクライアントプラットフォームのTPMとの組み合わせを用いることにより、ここに記載するソリューションは、ポリシーが実際に施行されていることをサーバーに保証することもできる。悪質な改変されたユーザーエージェントが、実際にはポリシーを施行していないのに、ポリシーを施行しているとサーバーに対して報告すると仮定する。サーバーは、そのTPMを通じて、遠隔システムの完全性を検証することができるので、次の手続きを用いて、改変されたユーザーエージェントの存在を検出することができる。1.ブート時、TPMは、オペレーティングシステムの完全性を検証し、搭載されたソフトウェアの特性を示す測定結果を機密性を保持しながら記録する。2.ブート時になされたTPMの測定によって完全性が保証されたオペレーティングシステムは、ユーザーエージェントの完全性を検証する。この測定の結果もTPMの内部に格納される。3.サーバーが遠隔デバイスの識別情報を認証するとき、その完全性も確認する。すなわち、認証プロセスには、ステップ1およびステップ2に記載の完全性の測定結果をTPMからサーバーへ転送することが含まれている。この転送は、測定結果が通信相手のプラットフォームに埋め込まれている本物のTPMから確かに来ていることをサーバーが検証することができるように行われる。このことは、TPMにとって固有のものであることを検証することができる私有鍵を用いて、TPMが完全性の測定結果にデジタル方式で署名することによって実現される。このプロセスは認証として知られている。4.サーバーは、クライアントプラットフォームのための完全性の測定結果を処理し、これらが、施行されているセキュリティポリシーと一致する処理環境を示しているか否かを判定する。5.ポリシー要件が満たされている場合、サーバーは、デバイスに暗号鍵を、メッセージ3で送られている完全性の測定結果がまだ有効である場合にのみクライアントプラットフォームがそれらを解読することができるように転送する。このことには、たとえば、www.rsa.com/rsalabs/technotes/tpm/sealedstorage.pdfから入手可能な2007年6月21日にブライアンパルノBryanParnoにより提出された表題がトラスティッドプラットフォームモジュールTPMおよびシールドストレージである論文に記載のようなシールドストレージとして知られている機能が用いられる。このことにより、セキュリティポリシーがクライアントプラットフォームへとダウンロードされる一組の鍵に効果的に結び付けられる、すなわち、このことにより、ポリシー要件を満たしているクライアントプラットフォームにのみ鍵が利用可能となる。この手順により、遠隔状況下においてポリシーが施行されていることを担保するにあたってマシンを識別するという概念の重要性が示されている。サーバー中心の鍵の管理とTPMに基づく完全性の測定結果の使用とを組み合わせたもの認証およびシールドストレージを含むが本実施形態において固有のものであると考えられている。鍵に基づいたポリシーの施行ポリシーは、クライアントデバイス上に保持されている機密性の高いデータへのアクセスを制限することができるようになっており、実際、制限していることが多い。暗号化されたデータは、解読に必要な鍵が秘密になっていることを前提として、自由に開示されている。このように、データへのアクセスを制限する問題は、鍵の管理問題へと変換されうる。鍵へのユーザーのアクセスを拒否することによって、ユーザーは暗号化されたデータにアクセスすることができなくなる。このような方法でポリシー制御を行なうことにより、特に遠隔デバイスに対して相当な利点を提供することができる。遠隔デバイスが平文で暗号化しないでデータを保持して盗まれた場合、どのようなオペレーティングシステムがアクセス制限を実施していたとしてもまたはTPMが存在していたとしても、ハードディスクの内容を直接解析することによりデータを読むことができた。このことは、データが暗号化され、解読に必要な鍵がクライアントデバイスに格納されていれば不可能である。機密性の高いデータの取り扱いに関するポリシーを施行するために、次のメカニズムが用いられる。1.データは、サーバーで作成されかつサーバーに保持されている鍵を用いて暗号化される。2.施行されているポリシーによりデータへのユーザーのアクセスが許可されている場合、サーバーは、ユーザーエージェントのホストマシンおよびユーザーが認証された後でのみ、解読に必要な鍵をユーザーエージェントに開示する。エンドユーザーは、ユーザーエージェントから当該鍵を獲得することはない。というのも、当該鍵は、クライアントマシンのハードディスクに平文で格納されることがないからであり、また、たとえばデバッガーによるアクセスが不可能な保護メモリーにのみ格納されているからである。これらの特性は、たとえばTPM認証手法を用いてシステムの完全性がサーバーによって検証されているので施行されている。エンドユーザーが解読用の鍵を獲得することができないので、ユーザーエージェントのメモリーから鍵を削除するだけで、このような鍵を無効、すなわちデータへのアクセス権を無効とすることができる。3.オフラインでのデータのアクセスを許可するために、ユーザーエージェントは、暗号化された形態でデータ暗号化鍵をディスクにポリシーに従って格納しうる。データ用の鍵を暗号化するために用いられる鍵は、TPMのシールドストレージ機能を用いて保護されているので、許可無く回収することはTPMの不正開封防止特性のため非現実的なこととなる。クライアントシステムが適切な一組のソフトウェア有効なユーザーエージェントを含むを実行している場合にのみ、TPMは、シールドストレージ機能を用いて、鍵を暗号化するための鍵の解読を許可するようになっている。ポリシーおよび、鍵を管理するサーバー中心性と、ポリシーの施行を検証してオフラインでのデータの使用を許可するTPMのような機密保護環境とを新規に組み合わせることによって、遠隔デバイスについて、サーバーにより企業ポリシーをロバストに管理し、施行することが可能となる。プロファイルの転送以下では、ユーザープロファイルをサーバーからクライアントデバイスへ転送することについて詳細に説明する。前書き本明細書で用いられる用語プロファイルは、中央サーバーに格納される一組のユーザー固有のデータのことを意味する。このプロファイルには、暗号化用の鍵および個人に関するポリシー情報、たとえばどのアプリケーションを用いる権限が与えられているのか、どのような状況で鍵がクライアントへダウンロードされるべきであるのか等の如き情報が含まれている。プロファイルとの用語は大ざっぱに用いられている。使用されるクライアントのタイプおよび/またはダウンロード時の具体的なユーザー要件によって異なる項目が選択され、プロファイル情報の部分部分だけをクライアントマシンへダウンロードすることが適切な場合もある。プロファイル転送プロトコルの説明を3つのフェーズ、すなわち予備セットアップフェーズと2つのメインフェーズとに分割する。セットアップフェーズは関連するエンティティ毎に一回だけ実行されるが、他の2つのフェーズはユーザーがクライアントマシンを利用したいときはいつでも、すなわちセッション毎に実行される。メインフェーズフェーズIおよびフェーズIIは説明を単純化するためにここでは別々説明されるが、実際問題として、これらの実行は重なり合う場合もある。たとえば、フェーズIを実行しているメッセージがフェーズIIを実行しているメッセージのうちの一部と同時に送られる場合もある。すべてのユーザーおよびすべてのサーバーはプロトコルに携わる前にセットアップフェーズを実行しなければならない。このフェーズでは、すべての必要な長期的な鍵およびユーザープロファイルが作成される。いったん実行されると、セキュリティ問題が生じたまたはユーザーステータスが変更された場合でない限り、再びセットアップフェーズを実行することが必要になることは通常ない。フェーズIでは、クライアントプラットフォームおよびサーバーが非公開セッション鍵を共有することができ、その後、フェーズIIでは、両方が、非公開セッション鍵を用いてユーザープロファイルの転送を保護することができるようにすることが意図されている。フェーズIIでは、クライアントがサーバーにプロファイルを機密性を保持しながら要求するが、この要求については、フェーズIで作成したセッション鍵を用いて確認することができる。この要求には、たとえば、どのタイプの鍵が必要となるか示されていてもよい。次いで、サーバーは、ユーザーに送るためのプロファイルの適切な部分部分を選択し、必要な短期間用の鍵ペアおよび/または秘密鍵を作成し、必要な短期間用の公開鍵証明書を作成し、ユーザーのもとへ送られる資料を作る。次いで、このプロファイルデータのパッケージはフェーズIで作成されたセッション鍵を用いて暗号化されて完全性が保護され、そして、そのパッケージがクライアントへ送られる。クライアントは、プロファイルデータをサーバーから受け取ると、このプロファイルデータを検証し、解読し、情報を処理し、いつでも使えるようにする。セットアップフェーズこの予備フェーズの目的は、スキームにかかわるパーティーにプロトコルに参加するのに必要となるリソースを提供することにある。ここでの説明は、サーバーに対するセットアップ要件、ユーザーに対するセットアップ要件およびクライアントに対するセットアップ要件を対象にした3つの部分に分割される。サーバーのセットアップスキームを支えるサーバーを確立させるために、次のステップが実行される。1.必要なソフトウェアがインストールされる。2.ユーザープロファイルおよびユーザーパスワードを機密性を保持しながら格納することができるように準備が行なわれる。ユーザーのセットアップユーザーがスキームを用い始めるために、次のステップが実行される。1.ユーザーはサーバーとの関係を確立する。これは、たとえば、料金を支払う契約関係サーバーがユーザーに対してサービスを提供するであってもよいし、または、サーバーが雇用者によってまたは雇用者の代わりに運用される場合においてユーザーの職業雇用によりデフォルトで生じる関係であってもよい。2.ユーザーは、ユーザー公開鍵のための証明書を作成する責務を有する1つ以上の証明機関CAを選択する。もちろん、サーバーとユーザーとの間の関係に応じて、このことは、ユーザーのためにサーバーによって自動的に実行されるようになっていてもよい。3.ユーザーは、サーバーと共有の秘密パスワードを作成する。4.サーバーは、ユーザーのプロファイルを作成する。ユーザーは、どのタイプの鍵が必要かを指定するまたは、自動的に選択されている。次いで、サーバーは必要な秘密鍵および非対称鍵ペアを作成し、1つ以上のCAから、公開鍵用の証明書を取得する。ユーザープロファイルの一部として必要とされる長期的な鍵のみがシグネチャ用の鍵ペアとされうることに留意されたい。5.次いで、サーバーは、ユーザーパスワードまたは他のユーザー識別情報と共に、たとえば、秘密鍵、非対称鍵ペアおよびそれに伴う公開鍵証明書を含むプロファイルを機密性を保持しながら格納する。各鍵が、用いられるアルゴリズムのための識別子、意図する用途たとえば、暗号化、MACの生成、シグネチャの生成など、および有効期間を含む、それに伴うなんらかの情報を有していることに留意されたい。クライアントのセットアップユーザーがスキームの一部としてクライアントデバイスを用いるために次のステップが実行される。1.適切なソフトウェアがクライアントに搭載されるしかしながら、このことは、たとえば使用時にJava登録商標アプレットとしてソフトウェアをサーバーからダウンロードすることによって動的に実行されてもよい。2.クライアントマシンのTPMを初期化し、クライアントマシン上で用いられるタイプのTPMまたは他の機密性保持環境を備えているプラットフォームにサーバーが対処することができるようにする。フェーズIこのフェーズの主な目的は、クライアントマシンとサーバーとの間の短期的な非公開セッション鍵を作成することにある。次に、プロトコルのこのフェーズを実現することができる方法について説明する。信頼できるソフトウェアが実行されているプラットフォームだけにプロファイルが利用可能とすることを担保するために、受益者クライアントのプラットフォーム上のソフトウェア環境を検証するトラスティッドコンピューティング機能を用いることができることに留意されたい。このことは、信頼できるプラットフォームのみが短期的なセッション鍵にアクセスすることができるようになされるべきである。この鍵なしでは、サーバーからクライアントへ送られるプロファイルを解読することができないため、クライアントが利用することができない。すなわち、短期的なセッション鍵へのアクセスを通じて、ポリシー制御がなされている。次に、短期的な鍵を作成することが可能な手段について説明する。このプロセスがトラスティッドコンピューティングによって実現されるいくつかの方法については、後で説明する。簡単なアプローチ非常に簡単なアプローチは、両方のパーティーが共有秘密パスワードから鍵を簡単に導き出すことである。セッション毎に異なる鍵が使用されることを担保するために、2つのパーティーのうちの一方がまずたとえば128ビットからなる乱数rを生成し、それを他方のパーティーへ送る。次いで、サーバーおよびクライアントは、K=hp||rであるセッション鍵を作成する。ここで、hは暗号化ハッシュ関数たとえば、SHA-256、[5]であり、pはユーザーの秘密パスワードであり、||は、ビット列の連結を表している。非常に簡単であるものの、このようなアプローチは深刻な弱点を有している。攻撃者がrを傍受し、さらにセッション鍵Kを用いて暗号化されたなんらかのデータを傍受すれば、pが非常に小さな数の可能性選択肢からなるセットから取り出されたものである場合、次のオフラインでの辞書攻撃が可能となる。-攻撃者は一つずつあらゆる可能性のあるパスワードのセットを試み、以下のような簡単な方法で間違った推測を除いていく。たとえば、pがパスワードの候補値であると仮定する。攻撃者は、それに対応するセッション鍵の候補K=hp||rを傍受したrの値を用いて演算する。次いで、攻撃者は、Kを用いて、傍受した暗号文を解読してみて、その解読の結果が意味のある平文にならなければ、そのパスワードの候補を除外することができる。もっとはっきりいえば、このような攻撃を防ぐために得られる十分に大きなパスワードのセットを簡単に記憶するのは若干難しいことである。しかしながら、ユーザーが8つの文字からなるパスワードを選択したと仮定しても、各文字が符号か数字のいずれかである場合、考えられうるパスワードの数は、368、すなわち約2.8×1012しかない。このサイズのセットを試みるのは容易なことではないが実行不可能なことではない。したがって、たとえば以下に提案されている道筋に沿ったもっとロバストなアプローチを用いることが望ましい。SSLに基づくアプローチ他の比較的簡単なアプローチは、クライアントマシンとのセキュアソケットレイヤーSSLセッションをまず開始することをサーバーに要求することである。クライアントマシンは、セッションが適切なサーバーと開始されていることを検証する手段を有する必要がある。このことは、たとえば、クライアントにダウンロードされているソフトウェアがサーバーの公開鍵の信頼できるコピーを前もって装備していてもよい。いったんSSLセッションが実施されると、クライアントのソフトウェアは、ユーザーにそのユーザーのパスワードを入力するように促し、このパスワードは検証のためにSSLチャネルを経由してサーバーへ送られる。パスワードは、SSLによって実現されるような暗号化されたチャネルを通じて伝達されるので、傍受者による危険性から保護される。SSLチャネルは、プロファイルを転送するための安全な手段を提供するために、フェーズIIでも用いられうる。このようなアプローチには1つの大きな欠点がある。クライアントは、当該クライアントが正しいサーバーと通信していることを検証する手段を有していなければならず、そうでなければ、中間者攻撃が開始される場合もある。クライアントにより用いられるソフトウェアがサーバーの公開鍵を有している場合にはこの問題は回避されることになるが、このことは、クライアントマシン上で用いられるソフトウェアを、ユーザーが信頼関係を有しているサーバーの公開鍵を備えるように独自なものとしなければならないことを意味する。このように構成することが難しい場合が存在する。上述の問題は以下に記載の解決策によって回避される。標準ベースのアプローチオフラインでの辞書攻撃が行えないようにユーザー記憶可能パスワードを用いて非公開セッション鍵を作成することを可能とするように設計される定評あるプロトコルが数多くある。さらに、より積極的な攻撃をくじくようにプロトコルを設計することもできる認証の試みの失敗を数えて適切な対応策をとるためのなんらかの手段が設けられている限り。このような3つのプロトコルが、ISO/IEC11770-4[6]の第6節に記載されており、鍵承認メカニズム1、2、3と呼ばれている。これらのすべてメカニズムが機密性がある安全であると考えられており、これらのメカニズムのうちのいずれであっても本スキームにおいて用いるのに適している。次に、これらのメカニズムの相対的な利点および欠点について検討する。機密性保持特性ISO/IEC11770-4の3つのすべてのメカニズムはよく似た機密性保持を有している。ただ一つの大きな差現在の知識ではは、メカニズム1では、サーバーがパスワードを知っていることが必要となるが、他の2つのメカニズムでは、サーバーがパスワードのハッシュを格納することが必要となるだけである。この後者の特性はいくつかの小さな実用上の長所を有しうる。実現する上での問題点これらの選択肢の間には特性の点において次のような差がいくつか存在している。-メカニズム1SPEKEは3つのメッセージフローを用いて実行することができ、メカニズム2SRP6およびメカニズム3AMPは少なくとも4つのメッセージフローを必要とする。-メカニズム1およびメカニズム3は、標準的な離散的ログ設定discretelogsettingおよび楕円曲線設定ellipticcurvesettingの両方で実行することができる。-メカニズム2は、標準的な離散的ログ設定のみで実行することができる。-3つのすべてのメカニズムの計算コストはほぼ同じと考えられるが、差は詳細にチェックされていない。SPEKEを用いた実現上述の説明を明瞭にするために、ISO/IEC11770-4のメカニズム1が用いられる場合のフェーズIについて簡単に説明する。1.ユーザー名およびパスワードを提供する。ユーザーは、クライアントのソフトウェアを実行し、ユーザーの名前およびパスワードをそのソフトウェアに与える必要がある。このステージにおいて、ユーザーが追加情報、たとえば当該ユーザーがサーバーからダウンロードしたい鍵のタイプを提供することは適切なことであるこのような情報はフェーズIIで用いられうる。2.プロファイルを要求するフェーズI。クライアントのソフトウェアは、プロファイルをダウンロードするプロセスの開始を要求するためのメッセージをサーバーへ送る。3.セッション鍵を作成するフェーズI。ここで、サーバーおよびクライアントは、共有秘密鍵を作成するために、ISO/IEC11770-4[6]の第6.1節に記載のようなSPEKEプロトコル用いる。以下に、ステップ2およびステップ3がどのように実行されるかについてもう少し詳細に説明する。ISO/IEC11770-4[6]の第6.1節の記載を参照する。クライアントが11770-4のAに相当し、サーバーがBに相当すると仮定する。1.クライアントのソフトウェアは、ユーザーが入力したパスワードπを用いて、第6.1.3節に記載の鍵トークン構築ステップA1を実行する。2.クライアントのソフトウェアは、ユーザー名およびプロファイルのダウンロードを開始する要求とともに、wAをBに送る。3.クライアントからのメッセージの受け取ると、サーバーは、ユーザーパスワードπをユーザー名によってインデックスが付されたユーザープロファイルから回収recoverし、πを用いて第6.1.3節に記載の鍵トークン構築ステップB1を実行する。4.サーバーはwBをAに送る。5.サーバーは、ステップB2において受け取ったwAの値を用いて共有秘密鍵Kiを取得する。6.サーバーからのメッセージを受け取ると、クライアントは、ステップA2において受け取ったwBの値を用いて共有秘密鍵Kiをさらに取得する。フェーズIIがある程度の一方向の鍵の確認を行っているので、鍵確認ステップが省略されていることに留意されたい。上述のステップ2において、クライアントAが任意のセッション識別子を作成し、それをサーバーBへ送ることは有益でありうることに留意されたい。次いで、サーバーは、ステップ4で、セッション識別子をクライアントへ送り返すことにより、クライアントにおいて応答を要求と合致させることができるようにする。フェーズIIこのフェーズの主な目的は、ユーザープロファイルデータをサーバーからクライアントマシンへ機密性を保持しながらダウンロードすることにある。このことを実現することができる方法はいろいろある。ここでは、1つの選択肢について説明する。転送プロトコルは次の一般的な形態をとる。1.クライアント→サーバー:プロファイルの要求この要求メッセージにより、クライアントマシンによりどのタイプの鍵が必要とされているかが特定される。たとえば、ユーザーがシグネチャ操作しか実行する必要がないのであれば、ユーザーに提供されるプロファイル情報には、シグネチャ私有鍵および、それに対応する公開鍵の証明書が含まれている必要があるだけである。このメッセージはフェーズIのメッセージのうちの1つのメッセージと同時に送られてもよいということに留意されたい。しかしながら、このメッセージの完全性を保護し、そして、場合によってはこのメッセージを暗号化することが必要な場合もある。そのような場合、このメッセージは、クライアントマシンがセッション鍵のコピーを取得した後でのみ送ることができる。2.サーバー:プロファイルの作成いったんサーバーにより要求が受け取られるとそして検証されると、サーバーは、クライアントマシンへ送られるデータを作成するのに必要となるタスクを実行する。次いで、すべての必要な鍵および証明書がフォーマット済みプロファイルの中に入れられ、いつでもクライアントへダウンロードできる状態にされる。3.サーバー→クライアント:暗号化されたプロファイルいったん鍵と証明書とを含むプロファイルデータがサーバーにより構築されると、当該プロファイルデータをクライアントへ送ることができる。プロファイルデータは、送信に先立って、サーバーによりセッション鍵を用いて暗号化される必要がある。暗号化の方法は機密性および完全性の保護の両方を提供する必要があり、ISO/IEC19772[7]に記載の技術のうちの1つが強く推奨される。このメッセージは、必要なセッション鍵がサーバーより入手可能な限り、フェーズIのメッセージうちの1つのメッセージと同時に送ることができることに留意されたい。4.クライアント:プロファイルを受け取るプロセス最後に、クライアントは、暗号化されたプロファイルを受け取ると、非公開セッション鍵を用いて、それを検証し、解読することができる。上述のように、通常、プロファイルはユーザー毎に作成される。ユーザープロファイルには、さまざまな鍵および証明書が含まれている。次いで、セッションが開始される毎に、これらの鍵および証明書のうちの一部または全部がクライアントマシンへ送られうる。このアプローチは、必要なすべての鍵が前もって作成されているので、クライアントがプロファイルを要求したときにサーバーが新たに鍵や証明書を作成する必要がないという利点を有している。さらに、各公開鍵には、それに付随しかつ信頼できるCAにより署名された単一の証明書が存在する。しかしながら、このアプローチは、クライアントマシンがいつか危険にさらされるようなことがあった場合、ユーザーの長期的な私有鍵も危険にさらされることになるという欠点を有している。さらに、鍵の取り消しが可能であるものの、危険が検出された場合にのみ取り消しができるようになるのであって、必ずしも危険が検出されるとは限らない。最後に、クライアントホストにおける他のアプリケーションに鍵および/または証明書を提供するためにプロファイルの中身を出す必要がありうることに留意されたい。そのとき、私有鍵が本発明のシステムが直接に制御できる範囲の外側にある場合、これらの鍵がセッションの終わりに削除されていることを担保することが難しい場合もある。トラスティッドコンピューティングの使用クライアントデバイスが信頼できない可能性がある場合、機密性保持に関して大きな危険が伴うことになる。サーバーが、クライアントにプロファイルをダウンロードする前にはクライアントにおいて正しいソフトウェアが実行されていたことそしてクライアントのオペレーティングシステム環境には機密性が保持されていたことを検証することができる場合、プロファイルの機密性を著しく向上させることができる。このような機能はトラスティッドコンピューティングによって提供されているたとえば、[8]を参照。今日、この技術は、トラスティッドプラットフォームモジュールTPMとして知られている特定用途セキュリティチップという形態で、かなりの割合の新しいPCに用いられている。この技術により、1つのデバイスが、他のプラットフォーム上で稼働しているソフトウェアの特性を遠隔から検証し、特定のソフトウェア構成についての秘密へのアクセスを制限することが可能となる。これらの特性は、上述のオペレーショナルモデルに理想的に適しているように思われる。以下では、トラスティッドコンピューティング機能について記載する。トラスティッドコンピューティング機能を用いてプロファイル転送プロセスポリシーを管理することができる。上述のように、このことには、サーバーが遠隔のクライアントプラットフォームの状態に満足しているという条件で短期的なセッション鍵へアクセスすることが含まれる。関連する作業遠隔のプラットフォームがある状態であるトラスティッドコンピューティング機能を用いたテストによって示される場合にのみある事柄が生じることを許可するという一般的概念は定着した考えである。トラスティッドネットワークコネクトプロトコルTNCでは、クライアントPCをネットワークに受け入れるべきか否かを判断するためにトラスティッドコンピューティングが用いられている。サーバーは、ネットワークにクライアントを入れるべきかどうか決定する前に、クライアントにそのソフトウェア構成の証拠の提供を要求する。TNCはトラスティッドコンピューティンググループにより標準化されているhttp://www.trustedcomputinggroup.org/。そのオペレーションについての簡単な説明に関しては、たとえばレボックおよびハントRehbockandHunt[9]を参照されたい。この一般的な考えが、機密性の高いソフトウェアを信頼できる状態でかつ検証可能なプラットフォームへダウンロードすることのみによって当該ソフトウェアを保護する手法として提案されている。この考えは、ギャラリーGallery、トムリンソンTomlinson、デリカタDelicataおよびミッチェルMitchellにより報告されている[1]、[2]、[3]、[4]。簡単なアプローチ最も簡単なアプローチは、サーバーが、秘密鍵の承認プロセスの開始直前に、信頼できるプラットフォームにその現在のソフトウェア構成を証明することを要求することである。このことは、クライアントプラットフォームがTPMを有し、クライアント上のソフトウェアがこのTPMを用いてクライアントプラットフォームの現在状況を示す測定値をTPM内のPCRプラットフォーム構成レジスタ内に格納することができることを仮定している。次いで、認証プロセスは、以下の道筋に沿って進められる。1.サーバーは、確認したいPCRのシリアル番号の値とともに、ランダムなチャレンジrandomchallengeをクライアントに送る。2.クライアントは、情報をクライアントのTPMに渡し、TPMは、ランダムチャレンジおよび要求されたPCRの現在値をそれらのインデックスとともに有しているストリング文字列にデジタル署名する。3.次いで、このシグネチャは、サーバーに返送され、サーバーは、シグネチャを検証および、ランダムチャレンジのフレシュネスをチェックすることにより、これらのPCR値がクライアントプラットフォームの現在のソフトウェア状態の正確な記録であることを検証することができる。このシグネチャは、構成証明識別鍵、すなわち私的な値がTPMにのみ入手可能となるシグネチャ鍵を用いて演算される。それに対応する公開鍵シグネチャを検証するために用いられるの有効性は、サーバーがクライアントにより提供される公開鍵証明書をチェックすることによって検証することができる。次いで、サーバーは、これらのPCR値が、対象となるユーザープロファイルと関連するポリシーの命令文によって許容可能であると見なされるソフトウェア構成と一致することを検証することができる。ポリシーによりこの設定が許容可能であると見なされる場合にのみ、上述のように、サーバーは共有秘密鍵を作成するように進む。さらにロバストなアプローチ直前に説明されたアプローチの1つの問題は、クライアントのソフトウェアの状態が、測定が行われる時間と、すぐ後の共有秘密鍵が作成される時間との間で変わる可能性があることである。この問題は、認証のプロセスと共有秘密鍵の作成とを組み合わせることにより取り除くことができる。このことを実現する方法は文献に説明されている。たとえば、ギャラリーGallery、トムリンソンTomlinson、デリカタDelicataおよびミッチェルMitchell[1]、[2]、[3]、[4]を参照されたい。引用文献[1]イーギャラリーE.GalleryおよびエイトムリンソンA.Tomlinson、モバイルレシーバーへの条件付きアクセスアプリケーションの安全な配信Securedeliveryofconditionalaccessapplicationstomobilereceivers、シージェイミッチェルC.J.Mitchell編集、トラスティッドコンピューティング、IEEプレス、ページ195~237、2005年[2]イーギャラリーE.GalleryおよびエイトムリンソンA.Tomlinson、SDRデバイス上のダウンロード可能なソフトウェアの保護ProtectionofDownloadableSoftwareonSDRDevices、ソフトウェア無線技術会議SDR05、2005年11月[3]イーギャラリーE.Gallery、エイトムリンソンA.TomlinsonおよびアールデリカタR.Delicata、モバイルレシーバーへの安全なビデオブロードキャストへのトラスティッドコンピューティングの応用ApplicationofTrustedComputingtoSecureVideoBroadcaststoMobileeceivers、技術報告書RHUL-MA-2005-11、ロンドン大学、ロイヤルホロウェー、数学科、2005年6月。[4]イーエムギャラリーE.M.GalleryおよびシージェイミッチェルC.J.Mitchell、トラスティッドコンピューティング技術および高度保証SDRプラットフォーム設備おけるその利用TrustedcomputingtechnologiesandtheiruseintheprovisionofhighassuranceSDRplatform、2006年ソフトウェア無線技術会議会議録、フロリダ州オーランド、2006年11月[5]ISO/IEC10118-3:2003、情報技術-安全技術-ハッシュ関数:パート3:専用ハッシュ関数InformationTechnology-Securitytechniques-Hash-functions:Part3:Delicatedhash-functions、国際標準化機構、ジュネーブ、2003年。[6]ISO/IEC11770-4:2006、情報技術-安全技術-鍵管理:パート4:低い秘密性に基づいたメカニズムInformationtechnology-Securitytechniques-Keymanagement:Part4:Mechanismbasedonweaksecrets、国際標準化機構、ジュネーブ、2006年[7]ISO/IEC19772:2009、情報技術-安全技術-認証付暗号化方式Informationtechnology-Securitytechniques-Authenticatedencryption、国際標準化機構、ジュネーブ、2009年[8]シーミッチェルC.Mitchell編集、トラスティッドコンピューティング、IEEプレス、ロンドン、2005年[9]エスレボックS.RehbockおよびアールハントR.Hunt、信頼できるクライアント:TNCのウェブベース環境への拡張Tustworthyclinets:ExtendingTNCtoweb-basedenvironments、コンピューター通信、32、ページ1006~1013、2009年