特許 5744915 信頼される連合アイデンティティ管理およびデータアクセス認可の方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5744915

(24)【登録日】2015年5月15日

(45)【発行日】2015年7月8日

(54)【発明の名称】信頼される連合アイデンティティ管理およびデータアクセス認可の方法および装置

(51)【国際特許分類】

   G06F 21/33 20130101AFI20150618BHJP

   G06F 21/41 20130101ALI20150618BHJP

   G06F 21/57 20130101ALI20150618BHJP

   G06F 21/44 20130101ALI20150618BHJP

【ＦＩ】

   G06F21/33

   G06F21/41

   G06F21/57

   G06F21/44

【請求項の数】8

【全頁数】38

(21)【出願番号】特願2012-550173(P2012-550173)

(86)(22)【出願日】2011年1月21日

(65)【公表番号】特表2013-518326(P2013-518326A)

(43)【公表日】2013年5月20日

(86)【国際出願番号】US2011022141

(87)【国際公開番号】WO2011091313

(87)【国際公開日】20110728

【審査請求日】2012年9月24日

(31)【優先権主張番号】61/297,446

(32)【優先日】2010年1月22日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】特許業務法人 谷・阿部特許事務所

(72)【発明者】

【氏名】インヒョク チャ

(72)【発明者】

【氏名】アンドレアス シュミット

(72)【発明者】

【氏名】アンドレアス レイチェル

(72)【発明者】

【氏名】ヨゲンドラ シー．シャー

【審査官】 金木 陽一

(56)【参考文献】

【文献】 米国特許出願公開第２００５／０１０５７３４（ＵＳ，Ａ１）

【文献】 磯崎 宏，ソフトウェアを保護するトラステッドコンピューティング，東芝レビュー，２００９年 ７月，Vol. 64, No. 7，pp. 32-35

【文献】 丸山 宏ほか，ソフトウェア完全性検証技術，情報処理，２００４年 ４月，Vol, 45, No. 4，pp. 354-359

【文献】 LEICHER, A., et al.，Implementation of a Trusted Ticket System，IFIP ADVANCES IN INFORMATION AND COMMUNICATION TECHNOLOGY，２００９年 ６月１１日，Vol. 297/2009，pp. 152-163

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ２１／３３

Ｇ０６Ｆ ２１／４１

Ｇ０６Ｆ ２１／４４

Ｇ０６Ｆ ２１／５７

(57)【特許請求の範囲】

【請求項1】

ユーザを有する無線デバイスにて実行される方法であって、
前記方法は、
前記無線デバイスによって、ネットワークアプリケーション機能から認証要求を受信することであって、前記認証要求は、前記ユーザに対応するＯｐｅｎＩＤアイデンティティを備える、ことと、
前記認証要求が前記ユーザによって受け入れられた時、前記無線デバイス上に存在する信頼されるチケットサーバによって、認証データおよびプラットフォーム妥当性検査データをストレージルートキーを使用して取り出すことであって、前記プラットフォーム妥当性検査データは、前記無線デバイスの信頼性の評価値および前記信頼されるチケットサーバの信頼性の評価値を含み、および前記認証データは、前記ユーザに対応するＯｐｅｎＩＤアイデンティティに関連付けられる、ことと、
前記ネットワークアプリケーション機能に、前記ユーザに対応する前記ＯｐｅｎＩＤアイデンティティに関連付けられる前記プラットフォーム妥当性検査データおよび前記認証データを送信することと、
前記信頼性の評価値が十分であること、および前記ＯｐｅｎＩＤアイデンティティが前記ユーザに対応することを前記ネットワークアプリケーション機能が検証したことを示す検証データを受信することと
を備える、方法。

【請求項2】

前記無線デバイスの信頼性の評価値はシステム状態を示し、および前記検証データは、前記システム状態が以前に生成された基準値と一致することをさらに示す、請求項１の方法。

【請求項3】

前記プラットフォーム妥当性検査データは、前記無線デバイスの信頼されるプラットフォームモジュールによって署名されている、請求項１の方法。

【請求項4】

前記プラットフォーム妥当性検査データは、ユーザ識別パラメータを含む、請求項１の方法。

【請求項5】

前記無線デバイスの信頼性の評価値は、ＡＩＫを用いて署名されているＳＭＬおよびＰＣＲ引用を含む、請求項１の方法。

【請求項6】

前記検証データを備えるチケットを受信することであって、前記チケットは、前記無線デバイスの再妥当性検査なしで後続の認可を実行するために再利用されることが可能である、ことをさらに備える、請求項１の方法。

【請求項7】

依拠当事者への接続を確立することと、
前記ネットワークアプリケーション機能へのブラウザリダイレクションを受信することと、
前記ネットワークアプリケーション機能に認証要求を送信することと
をさらに備える、請求項１の方法。

【請求項8】

前記検証データは、依拠当事者に認められたアクセスを示す、請求項１の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、信頼される連合アイデンティティ（Ｔｒｕｓｔｅｄ Ｆｅｄｅｒａｔｅｄ Ｉｄｅｎｔｉｔｙ）管理およびデータアクセス認可に関する。

【0002】

関連出願の相互参照
本願は、これによってその内容全体が参照によって本明細書に組み込まれている、２０１０年１月２２日に出願した米国特許仮出願第６１／２９７４４６号明細書に基づき、その優先権を主張するものである。

【背景技術】

【0003】

認証のためのＴｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ（ＴＣ）の基本的な使用は、たとえばハードウェアＴＰＭ（ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ ｍｏｄｕｌｅ）によって保護されたＴｒｕｓｔｅｄ Ｓｙｓｔｅｍ（ＴＳ）に認証のための証明書を提供することとすることができる。主なセキュリティ特徴として、これは、証明書を特定のＴＳに束縛することができる。無線ネットワーク内のこの認証の応用例は、ＥＡＰ−ＴＬＳ（ｅｘｔｅｎｓｉｂｌｅ ａｕｔｈｏｒｉｚａｔｉｏｎ ｐｒｏｃｅｄｕｒｅ−ｔｒａｎｓｐｏｒｔ ｌａｙｅｒ ｓｅｃｕｒｉｔｙ）を介するものとすることができる。ＴＳへのシングルサインオン（ＳＳＯ）の使用は、潜在的なセキュリティ問題を提示する可能性がある。

【発明の概要】

【0004】

本明細書で開示されるｔｒｕｓｔｅｄ ＯｐｅｎＩＤ（ＴＯｐｅｎＩＤ）の、ＯｐｅｎＩＤとの統合を提供できるシステム、方法、および手段を開示する。

【0005】

たとえばＵＥ（ユーザ機器）などの無線デバイスのユーザを、たとえばネットワークアプリケーション機能からの認証要求に応答して認証することができる。ＵＥ上の信頼されるチケットサーバ（ＴＴＳ：ｔｒｕｓｔｅｄ ｔｉｃｋｅｔ ｓｅｒｖｅｒ）は、プラットフォーム妥当性検査データ（ｐｌａｔｆｏｒｍ ｖａｌｉｄａｔｉｏｎ ｄａｔａ）を（たとえばＵＥ上のｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ ｍｏｄｕｌｅから）取り出すことができる。プラットフォーム妥当性検査データは、無線デバイスの信頼性の評価値を含むことができる。ＴＴＳは、ネットワークアプリケーション機能にプラットフォーム妥当性検査データを送信することができる。ＵＥは、ネットワークアプリケーション機能がプラットフォーム妥当性検査データおよびユーザを検証したことを示すプラットフォーム検証を受信することができる。ネットワークアプリケーション機能から受信されるプラットフォーム検証（ｐｌａｔｆｏｒｍ ｖｅｒｉｆｉｃａｔｉｏｎ）は、プラットフォーム妥当性検査データによって示されるシステム状態が以前に生成された基準値と一致することを示すことができる。

【0006】

ＵＥは、プラットフォーム検証を含むチケットを受信することができる。チケットは、無線デバイスの再妥当性検査なしで後続認可を実行するために再利用されることが可能とすることができる。チケットは、タイムスタンプ、寿命限度（ｌｉｆｅｔｉｍｅ ｌｉｍｉｔ）などを含むことができる。

【0007】

ＵＥは、ネットワークエンティティからチケット参照を受信することができる。チケット参照は、ネットワークアプリケーション機能からチケットを入手するのに使用されることが可能とすることができる。プラットフォーム検証は、無線デバイスの再妥当性検査（ｒｅｖａｌｉｄａｔｉｏｎ）なしで後続認可を実行するために再利用されることが可能とすることができる。

【図面の簡単な説明】

【0008】

【図1】例示的な認証およびアクセスシステムを示す図である。

【図1A】信頼されるケルベロスに関連する例示的なコールフローを示す図である。

【図2】ｔｒｕｓｔｅｄ Ｏｐｅｎ ＩＤに関連する例示的なコールフローを示す図である。

【図3A】信頼されるチケットサーバチャレンジ−レスポンスに関連する例示的なコールフローを示す図である。

【図3B】信頼されるチケットサーバチャレンジ−レスポンスに関連する例示的なコールフローを示す図である。

【図4】ｔｒｕｓｔｅｄ ＯｐｅｎＩＤに関連する例示的な方法を示す図である。

【図5】ＵＩＣＣおよびＷＴＲＵを束縛することに関連する例示的なコールフロー図を示す図である。

【図6】コンポーネントの間の例示的な関係を示す図である。

【図7】信頼エバリュエータとしてのＰＶＥの例を示す図である。

【図8】例示的なＴＶＴログオンを示す図である。

【図9】もう１つの例示的なＴＶＴログオンを示す図である。

【図10】もう１つの例示的なＴＶＴログオンを示す図である。

【図11】ＴＶＴログオンに関連する例示的なビジュアル指示を提供する図である。

【図12】ｔｒｕｓｔｅｄ ｃｏｍｐｕｔｉｎｇ概念に基づくプラットフォーム上のＴＶＴの例示的実施態様を提供する図である。

【図13】ＴＯｐｅｎＩＤと共のＢＯＮＤＩの例示的な使用を示す図である。

【図14】ＴＯｐｅｎＩＤと共のＢＯＮＤＩの使用の例示的なコールフロー図を示す図である。

【図15】例示的なＯｐｅｎＩＤプロトコルを示す図である。

【図16】例示的なＯＡｕｔｈプロトコルを示す図である。

【図17】例示的な組み合わされたＯｐｅｎＩＤ／ＯＡｕｔｈプロトコルを示す図である。

【図18】Ｇｏｏｇｌｅ（登録商標） ＯｐｅｎＩＤと共に例示的なＯｐｅｎＩＤプロトコルを示す図である。

【図19】Ｇｏｏｇｌｅ ＡＰＩを使用する例示的なＯＡｕｔｈプロトコルを示す図である。

【図20】例示的なＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）無線通信システム／アクセスネットワークを示す図である。

【図21】例示的なＬＴＥ無線通信システムを示す図である。

【発明を実施するための形態】

【0009】

より詳細な理解を、添付図面に関連して例として与えられる次の説明から得ることができる。

【0010】

図１〜２１は、開示されるシステム、方法、および手段を実施できる例示的実施形態に関連しうる。しかしながら、本発明を例示的実施形態に関連して説明する場合があるものの、本発明は、これに限定されず、本発明から逸脱せずに、他の実施形態を使用でき、または、本発明の同一の機能を実行するために、説明される実施形態に対して変更および追加が行われてもよいことを理解されたい。さらに、図面は、コールフローを示す場合があるが、これは、例示的であることが意図されている。他の実施形態を使用できることを理解されたい。さらに、フローの順序を、適当な場合に変更することができる。さらに、フローを、必要な場合に省略することができ、追加のフローを追加することができる。

【0011】

本明細書において後で言及される際、用語「ＷＴＲＵ（無線送受信ユニット）」は、ＵＥ（ユーザ機器）、移動局、固定のもしくは可動の加入者ユニット、ポケットベル、セルラ電話機、携帯情報端末（ＰＤＡ）、コンピュータ、または無線環境内で動作できる任意の他のタイプのデバイスを含むが、これに限定されない。本明細書で後で言及される際、用語「基地局」は、Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、または無線環境内で動作できる任意の他のタイプのインターフェースするデバイスを含むことができるが、これに限定されない。

【0012】

本明細書の開示は、例の認証およびアクセスシステムとしてＯｐｅｎＩＤプロトコルを使用することができ、他の認証およびアクセスシステムに適用可能である。説明において、さまざまな実施形態は、３ＧＰＰ（Ｔｈｉｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ）のコンテキストで説明されるが、さまざまな実施形態を、任意の無線通信技術で実施することができる。無線通信技術のいくつかの例のタイプは、ＷｉＭＡＸ（Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ）、８０２．ｘｘ、ＧＳＭ（Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ ｃｏｍｍｕｎｉｃａｔｉｏｎｓ）、符号分割多元接続（ＣＤＭＡ２０００）、ＵＭＴＳ（Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ）、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）、または任意の将来の技術を含むことができるが、これらに限定されない。

【0013】

図１に、クライアント／ユーザプラットフォーム１１０、アイデンティティプロバイダ１２０、プライバシ認証機関（ｐｒｉｖａｃｙ ｃｅｒｔｉｆｉｃａｔｉｏｎ ａｕｔｈｏｒｉｔｙ：ＰＣＡ）１３０、およびサービスプロバイダ１４０を含むがこれらに限定されない例示的な認証およびアクセスシステム１００を示す。クライアント／ユーザプラットフォーム１１０、アイデンティティプロバイダ１２０、およびサービスプロバイダ１４０は、無線通信システムおよび有線通信システムの任意の組合せを介してお互いと通信しているものとすることができる。クライアント／ユーザプラットフォーム１１０は、ＰＣＡ １３０と通信しているものとすることができ、ＰＣＡ １３０は、記憶媒体１６０との通信とすることができ、記憶媒体１６０は、たとえば証明書を格納することができる。

【0014】

クライアント／ユーザプラットフォーム１１０は、ＷＴＲＵ、基地局、コンピューティングプラットフォーム、または認証を必要とする可能性がある任意のデバイスとすることができる。クライアント／ユーザプラットフォーム１１０は、リモート構成証明（ａｔｔｅｓｔａｔｉｏｎ）と、クライアント／ユーザプラットフォーム１１０のデータに関するスケーリング能力および束縛能力とを提供するｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ ｍｏｄｕｌｅ（ＴＰＭ）１１５を含むことができるが、これに限定されない。ＴＰＭ １１５は、鍵、パスワード、ディジタル証明書を格納し、暗号鍵を生成できる、マイクロコントローラとすることができる。ＴＰＭ １１５を、マザーボードに固定するかシステムのチップセット内に統合することができ、ＴＰＭ １１５を、これらの機能を必要とする可能性がある任意のコンピューティングデバイス内で使用することができる。ＴＰＭ １１５は、たとえば外部ソフトウェア攻撃、物理的改竄、盗聴などからその情報を保護することができる。ＴＰＭ １１５またはクライアント／ユーザプラットフォーム１１０内のデータおよび秘密へのアクセスは、ブートシーケンス中にコンポーネントについてとられた測定値が、セキュア電子メール、セキュアウェブアクセス、およびデータのローカル保護などのアプリケーションおよび能力をよりセキュアにすることができる基準測定に対して期待されるものではない場合に、拒否され得る。ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ ｍｏｄｕｌｅが本明細書において議論されるが、たとえばｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｍｏｄｕｌｅなどの他の信頼センタ（ｔｒｕｓｔ ｃｅｎｔｅｒ）を使用することができる。

【0015】

ＴＰＭ １１５は、保証キー（ｅｎｄｏｒｓｅｍｅｎｔ ｋｅｙ：ＥＫ）、たとえば製造時にチップ上でランダムに作成され、変更できない２０４８ビットＲＳＡ（Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｅｌｍａｎ）公開鍵／秘密鍵対を使用することができる。秘密鍵をチップに制限することができ、公開鍵は、構成証明およびチップに送信される機密データの暗号化に使用される。ＥＫの公開部分を、構成証明のためのＥＫ証明書を介してＰＣＡ １３０によって一般に知られるものとすることができる。ＴＰＭ １１５が、たとえばアイデンティティプロバイダなどのベリファイヤに対してそれ自体を認証することを必要とする時には、ＴＰＭ １１５は、構成証明識別鍵（ａｔｔｅｓｔａｔｉｏｎ ｉｄｅｎｔｉｔｙ ｋｅｙ：ＡＩＫ）と呼ばれる第２のＲＳＡ鍵対を生成し、ＡＩＫ公開鍵をＰＣＡ １３０に送信し、対応するＥＫに対してこの公開鍵を認証することができる。ＰＣＡ １３０が、そのリスト内でこのＥＫを見つける場合には、ＰＣＡ １３０は、ＴＰＭ １１５のＡＩＫに対する証明書を発行することができる。その後、ＴＰＭ １１５は、この証明書をアイデンティティプロバイダ１２０に供給し、それ自体を認証することができる。

【0016】

ＡＩＫ（少なくともＡＩＫ内で実施されるアイデンティティ）は、本明細書で説明されるチケットの少なくとも１つの部分を表すことができる。チケット内でのＡＩＫの使用を、ＴＰＭ １１５によって制限することができる。ＣｅｒｔｉｆｙＫｅｙ動作と称する間接的手法を使用することができ、ここでは、署名する鍵が、ＴＰＭ １１５によって生成され、ＡＩＫを用いてこれに署名することによって証明される。この鍵を、証明された署名する鍵（ｃｅｒｔｉｆｉｅｄ ｓｉｇｎｉｎｇ ｋｅｙ：ＣＳＫ）と呼ぶことができる。ＣＳＫおよびＡＩＫは、ＡＩＫの妥当性をアテストするＰＣＡと一緒に、本明細書で説明されるチケットの一部を構成することができる。

【0017】

クライアント／ユーザプラットフォーム１１０は、サービスアクセス用の証明書すなわちチケットを生成する信頼されるチケットサーバ、ＴＴＳ １５０を含むことができる。本明細書でｔｒｕｓｔｅｄ ＯｐｅｎＩＤに関してチケットサーバに言及する際、そのような言及を、信頼されるチケットサーバへの言及とすることができる。ＴＴＳ １５０は、ユーザを認証することができる。ＴＴＳ １５０は、たとえばプラットフォーム構成証明のｔｒｕｓｔｅｄ ｃｏｍｐｕｔｉｎｇ法を使用して、アイデンティティプロバイダ１２０に対してクライアント／ユーザプラットフォーム１１０およびそれ自体を妥当性検査することができる。セキュリティ情報およびセキュリティ動作をＴＴＳ １５０内に集中することができるので、ＴＴＳ １５０は、ＡＩＫ証明書およびＣＳＫを正しく扱い、これらを他のプラットフォームに増殖させず、チケットおよび証明書を保護し、ユーザ認可によって証明書に対するセキュリティ動作を保護し、一般的なウェブブラウザに統合され、これによってアクセスされるセキュアオプションを提供し、プラットフォーム妥当性検査データを収集し、処理し、送信すると信頼される必要がある場合がある。

【0018】

ユーザは、ＴＰＭ １１５内で作成されたＡＩＫを証明するためにＰＣＡ １３０を選択する必要がある場合がある。ＰＣＡ １３０は、アイデンティティ関連情報を保持することができ、契約措置が、このアイデンティティ関連情報の非開示を保証するためにとられる必要がある場合がある。ＰＣＡ １３０でＡＩＫを証明した後に、ユーザは、主張されたアイデンティティをホスティングするためにアイデンティティプロバイダ１２０を選択することができる。主張されたアイデンティティを、ユーザによって選択されたＵＲＩ（ｕｎｉｖｅｒｓａｌ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ）によって表すことができる。そのような主張されたアイデンティティを登録するために、ユーザに、有効なＡＩＫ証明書をアイデンティティプロバイダ１２０に供給するように要求することができる。

【0019】

アイデンティティプロバイダ１２０に、最小限の量のアイデンティティ関連情報を提示することができる。ユーザは、ＰＣＡ １３０でホスティングされるどの情報をアイデンティティプロバイダ１２０に明らかにすることができるのかを判断することができる。当事者の間での調整を保証するために契約措置をとる必要がある場合があり、そうでなければ、悪意者のＰＣＡが、異なるユーザに属するアイデンティティを証明できる可能性がある。ＰＣＡ １３０は、ユーザの実際のアイデンティティをアイデンティティプロバイダ１２０に明らかにすることができないので、アイデンティティプロバイダ１２０は、異なる要求を単一のアイデンティティにリンクすることができない可能性がある。

【0020】

主張されたアイデンティティを実際のアイデンティティに解決する能力を、ＰＣＡ １３０に制限することができる。これは、（一意の）ＥＫ証明書をＡＩＫにマッピングする保護されたデータベースを維持することによって行うことができる。ＡＩＫ証明中に使用されるＥＫ証明書は、ＴＰＭ １１５の識別を、したがってクライアント／ユーザプラットフォーム１１０の識別を、可能にすることができる（たとえば、１人のユーザがプラットフォーム１１０への物理アクセスを有すると仮定すると、これがそのユーザに解決される）。

【0021】

サービスプロバイダ１４０は、サイトに関するアイデンティティプロバイダログインを可能にすることができる。たとえば、サービスプロバイダ１４０は、フロントページにＯｐｅｎＩＤログインロゴを有することができる。ユーザ／クライアントによって使用されるアイデンティティプロバイダ１２０に、サービスプロバイダ１４０の既知の受け入れられるアイデンティティプロバイダのリストに含まれることを要求することができる。

【0022】

連合アイデンティティ（ｆｅｄｅｒａｔｅｄ ｉｄｅｎｔｉｔｙ）方式またはシングルサインオン（ＳＳＯ）方式は、ユーザが単一の証明書を使用して複数のセキュアサイトにログインすることを可能にする、ユーザフレンドリな方法を提供することができる。連合アイデンティティ方式の実施態様の複数の形が可能である可能性があるが、本明細書の開示は、例としてＯｐｅｎＩＤを使用する信頼される概念（ｔｒｕｓｔｅｄ ｃｏｎｃｅｐｔｓ）の概要を提供する。他の方法、たとえば、ｔｒｕｓｔｅｄ ｃｏｍｐｕｔｉｎｇ技法を使用し、ユーザとデバイスとネットワークとの間で認証を束縛する、アプリケーションおよびインターネットベースのサービスへのシングルサインオン（ＳＳＯ）アクセスを適用することができる。

【0023】

ＯｐｅｎＩＤは、ユーザを認証するための異なる認証方法を可能にすることができる。ＯｐｅｎＩＤプロバイダでアイデンティティを主張するために、複数の方法を使用することができる。ある方法は、ユーザがパスワードを提供するログオンフォームの使用であってもよい。

【0024】

このログオンを、ＴＰＭベースのログオンプロセスに置換することができる。ユーザは、かれらの特定のプラットフォーム、たとえばＴＰＭに緊密に束縛されたアイデンティティを登録することができる。ユーザが、このアイデンティティを使用してログオンすると判断する場合には、ＯｐｅｎＩＤプロバイダは、正しい証明書を提供するために、そのユーザにチャレンジすることができる。この場合に、証明書は、ＴＰＭが生成したチケット、たとえば証明書チェーン（ｃｒｅｄｅｎｔｉａｌ ｃｈａｉｎ）を含むことができる。これは、ユーザが、ＯｐｅｎＩＤプロバイダでのパスワードの必要なしにログインすることを可能にすることができる。ユーザのコンピュータでのローカルパスワードを使用して、ローカル攻撃からアイデンティティを保護することができる。

【0025】

ログインを、特定のプラットフォームの完全性（ｉｎｔｅｇｒｉｔｙ）検証と組み合わせることができる。システム構成値に対するＴＰＭ署名されたステートメントを使用して、ＯｐｅｎＩＤプロバイダは、報告されたシステム状態を以前に生成された基準値と比較することができる。この手順は、信頼できるクライアントがログインし、アイデンティティを主張することを可能にすることができる。この組み合わされた認証および構成証明は、認証データを特定のプラットフォームおよび信頼できると考えることのできる事前定義のシステム状態に束縛することによって、微細な粒度のアクセス制御を可能にすることができる。これは、システムの強化されたセキュリティおよび安全性を要求する可能性があるＯｐｅｎＩＤの新しいユースケースの使用可能化を可能にすることができ、したがって、信頼できないシステムにつながる変更を可能にしないものとすることができる。議論される実施形態は、ＴＰＭに基づくが、たとえばモバイルツーモバイル（ＭＴＭ）環境または信頼される環境など、他の信頼されるシステムの変形形態も可能である可能性がある。

【0026】

信頼されるケルベロス（ＴＫｅｒｂｅｒｏｓ：ｔｒｕｓｔｅｄ Ｋｅｒｂｅｒｏｓ）概念は、たとえば認証サーバ（ＡＳ：Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｅｒｖｅｒ）および／またはチケット付与サーバ（ＴＧＳ：Ｔｉｃｋｅｔ Ｇｒａｎｔｉｎｇ Ｓｅｒｖｅｒ）など、２つのサーバに頼ることができる。これらのサーバのそれぞれが、チケットを発行することができる。各チケットは、２つの部分を含むことができる。たとえば、一方の部分は、次のターゲットサーバのために暗号化され得、したがって、クライアントによって暗号化解除（ｄｅｃｒｙｐｔ）され得ない。この部分は、次の通信ステップによって使用できるセッション鍵を含むことができる。セッション鍵を、チケットの第２部分内においてクライアントのために暗号化することができる。クライアントが第２部分を暗号化解除できる場合には、クライアントは、次のチケットを要求するためにセッション鍵を入手することができる。

【0027】

ＴＫｅｒｂｅｒｏｓを、たとえば次のように複数のステージで実行することができる。たとえば、ＴＧＴ（ｔｉｃｋｅｔ ｇｒａｎｔｉｎｇ ｔｉｃｋｅｔ）をＡＳに要求し、かつ／またはＡＳから受信し、将来の使用のために格納することができる。セッション鍵を暗号化解除して、ＳＴ（ｓｅｒｖｉｃｅ ｔｉｃｋｅｔ）用の認証データを暗号化することができる。ＴＧＴを、暗号化されたオーセンティケータ（認証子）と一緒にＴＧＳに送信することができる。ＳＴを、ＴＧＳから受信することができる。セッション鍵を暗号化解除して、サービス要求用の認証データを暗号化することができる。ＳＴを、暗号化されたオーセンティケータと共にサービスプロバイダに送信することができる。

【0028】

ＴＫｅｒｂｅｒｏｓプロトコルは、ＴＣを使用することができる。その設計は、たとえば、ＴＰＭを介してチケットをユーザのチケットサーバ（ＴＳ）に密に束縛する手段を提供することによってセキュリティを高めるため、および／またはサービスにアクセスするユーザのプライバシを保護するため、などの目標を有しうる。

【0029】

ＡＳが、ＰＣＡの役割を実行することができ、かつ／またはＴＧＴが、ＡＩＫ証明書として働くことができる。チケット獲得プロセスは、プラットフォームが前もってチケットをキャッシングし、サービスアクセスのためにそれらのチケットを個々に取り扱うことを可能にするために、ＴＫｅｒｂｅｒｏｓに２つの部分を含めることができる。

【0030】

サーバ側のセキュリティに含まれて、ユーザのシステムの構成証明が存在する場合がある。ユーザが、サービスにアクセスするためにＳＴを獲得することを望む時には、システム準拠をリモートにアテストするために、ユーザに、ＴＧＳによってチャレンジすることができる。その結果、証明されたシステム内のクライアントは、サービスにアクセスできるものとすることができる。図１Ａに、信頼されるケルベロスに関連する例示的なコールフローを示す。ＴＧＴを、ＴＣＴｉｃｋｅｔによって増強することができ、このＴＣＴｉｃｋｅｔは、ＴＧＴの主張されるアイデンティティおよびサービス要求を有し、ＴＰＭによって署名され得る。

【0031】

図１Ａに示されているように、クライアント３０、ＡＳ ４０、ＴＧＳ ５０、およびサービスプロバイダ６０が、お互いの間の通信のために構成される。１０では、クライアント３０が、ＴＧＴを取り出すことができる。たとえば、クライアント３０は、ローカルキャッシュからロードし、かつ／またはＡＳ ４０からＴＧＴを得ることができる。クライアント３０は、ＡＳ ４０へのＴＧＴ要求１３を行うことができる。クライアントの実際のアイデンティティ情報は、ＡＳ ４０公開鍵を使用して暗号化され得るので、保護され得る。１５では、ＡＳ ４０が、ＴＧＴ応答をクライアント３０に返すことができる。ＡＳからのＴＧＴ応答を、ＴＰＭの公開ＥＫを使用して暗号化することができる。

【0032】

１７では、クライアント３０が、ＳＴを取り出すことができる。１７では、クライアント３０が、ユーザからアイデンティティ（ＡＩＫ）パスワードを得、ＴＰＭを使用してＴＣＴｉｃｋｉｔを作成し、かつ／またはシステム状態を引用することができる。１８では、クライアント３０が、ＳＴを取り出すためにＳＴ要求を使用することができる。クライアント３０がＴＧＳ ５０にＳＴを要求するのにＴＧＴを使用する時に、通信を、ＴＧＴからのセッション鍵によって暗号化することができる。ＴＧＳ ５０は、１９でＴＧＴをチェックし、２０でシステム状態完全性をチェックし、２１でＴＣＴをチェックし、かつ／または２２でクライアントＴＰＭのためにＳＴを暗号化することができる。セッション鍵を明らかにし、かつ／またはＴＧＳがクライアントによって供給されるデータを暗号化解除することを可能にするために、ＴＧＴを、ＴＧＳ ５０によって暗号化することができる。ＴＣＴｉｃｋｅｔからの証明された署名する鍵（ＣＳＫ）に束縛され、ＴＰＭによって保護される使い捨て鍵を用いてセッション鍵を暗号化することによって、応答をＴＰＭに暗号的に束縛することができる。

【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】

ＴＯｐｅｎＩＤは、プラットフォーム妥当性検査データおよび／または認証ステップでのＩｄＰによる完全性チェックを含むことができる。ＴＯｐｅｎＩＤでの認証を、特定のＴＰＭ（またはたとえば単一のプラットフォーム）に束縛することができる。というのは、ＯｐｅｎＩＤ識別子を、ＴＰＭ束縛されたＡＩＫを使用して登録することができるからである。ＴＰＭおよび／またはＡＩＫ証明プロセスのセキュリティプロパティは、識別子を別のプラットフォーム上で使用できないことを保証することができる。ＩｄＰによる完全性妥当性検査は、正しいプラットフォーム（または、指定される場合に、信頼されるチケットサーバを含む信頼されるサブシステム）が正しい構成で動作しつつあることを保証することができる。

【0058】

上の方法を、図２に示されたＴＯｐｅｎＩＤプロトコルフローに適用することができる。ＯｐｅｎＩＤアイデンティティプロバイダ（ＩｄＰ）および／またはユーザのシステムは、ＴＰＭおよびその完全性妥当性検査プロトコルを使用して認証ステップを実行する能力を含むことができる。これらの能力を、クライアントおよび／またはサーバ上のソフトウェアモジュールおよび／またはライブラリとして実施することができる。たとえば、これらの能力を、ＴＴｖｅｒｉｆｉｅｒ ２５８、チャレンジメッセージ２５２、チャレンジ回答メッセージ２５９、ＴＰＭ ２７０、ＰＣＡ ２７５、および／または記憶媒体２８０でなど、クライアント／ユーザプラットフォーム２１０および／またはＯｐｅｎＩＤプロバイダ２２０で実施することができる。ＯｐｅｎＩＤのオープン概念は、非常にさまざまな異なるＯｐｅｎＩＤ ＩｄＰ実施態様へとつながりうる。したがって、ＯｐｅｎＩＤ ＩｄＰは、それら自体の中で区別するための概念を展開することができる。ＯｐｅｎＩＤ ＩｄＰがそれら自体を区別するのに使用できる１つの機能を、たとえば、強化されたセキュリティ特徴のアサーションとすることができる。そのようなアサーションは、ユーザの（ＯｐｅｎＩＤ）アイデンティティがたとえばＨＷ束縛される場合など、そのアイデンティティが保護されることをユーザに保証することができる。ユーザに、そのようなＩｄＰが、ＲＰがそれらから受信される情報に頼ることを可能にすることができることを保証することができる。たとえば、銀行または他のセキュリティを要求するアプリケーションが、セキュリティを意識し証明されたＯｐｅｎＩＤ ＩｄＰのホワイトリストと共にＯｐｅｎＩＤを使用することを可能にすることである。

【0059】

ＴＯｐｅｎＩＤを実施する１つの方法は、プラットフォーム妥当性検査を実行するのに第２の非ＨＴＴＰベースのプロトコルを使用することができる。たとえば、第２のプロトコルを使用して、チャレンジメッセージを、ＯｐｅｎＩＤプロバイダ２２０からクライアント／ユーザプラットフォーム２１０に送信することができ、レスポンスを、ＯｐｅｎＩＤプロバイダ２２０に送り返すことができる。これを、ＯｐｅｎＩＤプロバイダ２２０の主認証プロセスに制御を返すことができるバックグラウンドプロセスを介して実行することができる。主認証プロセスは、図２に示されているようにクライアント／ユーザプラットフォーム２１０からＯｐｅｎＩＤプロバイダ２２０へのリダイレクトを用いて開始されている場合がある。その後、ＨＴＴＰリダイレクトを、図２に示されているように、ＯｐｅｎＩＤプロバイダ２２０からクライアント／ユーザプラットフォーム２１０へ実行することができる。

【0060】

サーバおよび／またはユーザのデバイスの能力に応じて、異なるプロトコルを使用してデータを転送することができる。

【0061】

サービスアクセス用の証明書すなわちチケットを作るエンティティを、クライアント内に組み込むことができる。これを、たとえば図２に示されたチケットサーバ２５０などのクライアント内の信頼される機能エンティティによるＴＫｅｒｂｅｒｏｓのセキュリティに関して妥協せずに、実行することができる。チケットサーバは、ＯｐｅｎＩＤプロバイダに対してクライアントおよびそれ自体を妥当性検査することができる。セキュリティ情報および動作を、チケットサーバコンポーネント内に集中することができるので、チケットサーバは、ＡＩＫ証明書および／またはＣＳＫを正しく処理すると信頼され得る。チケットサーバは、ＡＩＫ証明書および／もしくはＣＳＫを他のプラットフォームに増殖させず、チケットおよび証明書を保護し、ユーザ認可によってセキュリティ動作証明書を保護し、一般的なウェブブラウザに統合され、これによってアクセスされるセキュアオプションを提供し、プラットフォーム妥当性検査データを収集し、処理し、送信し、かつ／または反射攻撃を識別するためにナンスの妥当性に基づくアクセス制御を提供すると信頼されることができる。

【0062】

特定の証明書チェーンを、本明細書で説明されるように、チケットサーバおよびＰＣＡによって作成することができる。ＴＯｐｅｎＩＤでの証明書チェーンは、ＡＩＫ証明書−証明されたＣＳＫ−署名された要求とすることができる。

【0063】

ＴＫｅｒｂｅｒｏｓシステム内にＰＣＡを配置する実施態様は、次を含むことができる。ＯｐｅｎＩＤプロバイダ内にＰＣＡを含めることは、複雑さを減らすことができる。それを、ウェブフォームを介するＯｐｅｎＩＤプロバイダへの登録のシームレス置換とすることができる。ＴＯｐｅｎＩＤでは、ユーザは、１）そのＡＩＫ証明書をＴＯｐｅｎＩＤプロバイダによって受け入れることができる任意の外部ＰＣＡを選択し、かつ／または２）ＴＯｐｅｎＩＤプロバイダによって直接にまたは間接に提供されるＰＣＡ機能性を使用することができる。

【0064】

そのセキュリティアーキテクチャに起因して、ＴＯｐｅｎＩＤは、ＯｐｅｎＩＤベースのシステムに関する特定の脅威を軽減することができる。ＴＫｅｒｂｅｒｏｓでは、ＡＩＫ証明書が、クライアント上で可視であるのではなく、ＴＧＴで暗号化され、ＴＧＳによって暗号化解除可能である場合がある。ＡＩＫ証明書は、クライアントに既知とすることができ、たとえばプライバシを脅かすことができる隠された情報を有しないものとすることができる。ＯｐｅｎＩＤ実施態様は、ＯｐｅｎＩＤプロバイダログインフォームをユーザに提示することができる。ユーザは、自身の証明書を入力することができ、ＯｐｅｎＩＤプロバイダは、クッキーをクライアントに発行することができる。次に、このクッキーを、各後続のＯｐｅｎＩＤ対応サービスアクセスに使用することができる。これは、ＯｐｅｎＩＤプロトコルに対する複数の攻撃の可能性、たとえば、１）ＯｐｅｎＩＤプロバイダへのログインに使用されるユーザ証明書に対する直接攻撃（偽ＯｐｅｎＩＤプロバイダページを用いるフィッシングが、大量のユーザ証明書を露出させ、アイデンティティ窃盗を可能にする可能性がある）、または２）アイデンティティ窃盗につながる可能性がある、認証の後のクライアントのコンピュータからのクッキーの再利用、コピー、および／または窃盗を用いる攻撃につながる可能性がある。ｔｒｕｓｔｅｄ ＯｐｅｎＩＤの使用によって、攻撃を軽減することができる。ユーザパスワードを、ローカルとし、かつ／またはローカルの信頼されるチケットサーバに供給することができるので、証明書フィッシングを阻止することができる。偽名アイデンティティを、プラットフォームに束縛することができる。すなわち、偽名アイデンティティは、別のデバイスにコピーすることができない。

【0065】

クライアントのプラットフォーム上に格納されるクッキーがないものとすることができる。これは、たとえばコンピュータが複数の人によって共有される時など、ローカル再利用の脅威を防ぐことができる。一例では、ユーザＡが自身のＯｐｅｎＩＤアカウントにログインし、サインアウトするのを忘れる場合に、ユーザＢは、ユーザＡに成りすますために格納されたクッキーを使用することを試みることができる。そのような再利用は、ｔｒｕｓｔｅｄ ＯｐｅｎＩＤ認証をウェブブラウザにシームレスに統合することによって防ぐことができる。ユーザが、ｔｒｕｓｔｅｄ ＯｐｅｎＩＤを使用してサービスにアクセスすることを望む時に必ず、ＯｐｅｎＩＤプロバイダは、チケットサーバに関する新しいチャレンジを作成することができる。ユーザは、たとえば、チャレンジに答えるために必要になる可能性があるローカルＡＩＫパスワードをユーザに要求するプロンプトなど、自身の信頼されるチケットサーバアプリケーションからのプロンプトを見ることができる。チケットサーバは、このＡＩＫ認証秘密を格納してはならない。同一のプラットフォームにいる別のユーザＢがそのサービスにアクセスすることを望む場合に、チケットサーバは、やはり、ＯｐｅｎＩＤプロバイダによってチャレンジされ得、かつ／またはユーザＢは、ユーザＡのローカルＡＩＫパスワード（ユーザＢには未知）を提供しなければならないものとすることができる。これは、クライアントのプラットフォームに格納されないものとすることができる使い捨てクッキーの使用を必要とする可能性がある。

【0066】

発行されたクッキーを、ターゲットプラットフォームおよび／またはユーザがこれを暗号化解除し、認証トークンとして使用できる形で暗号化することができる。ＯｐｅｎＩＤプロバイダは、公開ＣＳＫを使用してクッキーを暗号化し、かつ／またはこれをクライアント側のチケットサーバに送信することができる。ＴＰＭを使用して、必要な時にクッキーを暗号化解除することができる。暗号化解除は、ユーザに、たとえば（ローカル）ＣＳＫ秘密を用いるなど、ＣＳＫ使用のために認証することを要求することができる。チケットサーバは、クッキーが暗号化されて格納され、必要な場合に暗号化解除されることを保証することができる。暗号化されたクッキーの格納および／または使用のもう１つの実施態様を、シールする動作が行われる時にクッキーをプラットフォームの完全性に束縛する形でクッキーを格納するためのコマンドＴＰＭ−Ｓｅａｌの使用とすることができる。以前にシールされたクッキー値が次に取り出される時に、プラットフォームの完全性が、シールする動作が行われた時の値と同一であることを検証することができる。この例では、プラットフォームの完全性がその以前の値と一致する時に、シールされたクッキー値を取り出すことができる。

【0067】

Ｔｒｕｓｔｅｄ ＯｐｅｎＩＤを、Ｔｒｕｓｔｅｄ Ｇｏｏｇｌｅ ＡＰＩに拡張することができる。ＯｐｅｎＩＤおよびＯＡｕｔｈを組み合わせることは、たとえばＯｐｅｎＩＤプロバイダでの伝統的な「ログイン」以外のさらなるユーザ対話が要求されないように、ＯｐｅｎＩＤ認証プロセスに頼ることができる。

【0068】

ユーザのＴＰＭにＯｐｅｎＩＤチャレンジに署名させる代わりに、ＴＰＭは、ウェブアプリケーションの要求を介してＯｐｅｎＩＤプロバイダによって提示される組み合わされたＯｐｅｎＩＤ／ＯＡｕｔｈチャレンジに署名することができる。ユーザ識別および認可ならびにデータへのアクセスの受入に、ＴＰＭによってセキュアに署名することができる。Ｔｒｕｓｔｅｄ ＯｐｅｎＩＤの文脈と同様に、ユーザに関するセキュリティを、１）ログインおよび認可をハードウェアＴＰＭにバインドすること、ならびに／または２）クライアント上で動作する悪意のあるソフトウェアによる機密データの窃盗を防ぐためにＯｐｅｎＩＤ／ＯＡｕｔｈプロバイダによるオプションのプラットフォーム完全性検証を含めることによって改善することができる。完全性検証は、ウェブアプリケーションに関するセキュリティのレベルを高めることができる。サービスへのアクセスを、証明された完全性検証された状態のクライアントに制限することができる。これは、セキュリティおよびプライバシアプリケーションに関する新しいウェブサービスの確立を可能にすることができる。このプロセスは、否認防止を提供することができ、たとえば、ＯＡｕｔｈアクセストークンに、ＴＰＭによって署名することができ、これは、一意に識別され得る。これは、ウェブアプリケーションのプロバイダによって実施され得る課金プロセスを容易にすることができる。署名は、ウェブアプリケーションプロバイダが、ユーザがサービスを要求し、サービスにアクセスしたことを証明することを可能にすることができる。

【0069】

ＴＰＭベースのユーザ認証は、プラットフォームアイデンティティがＯｐｅｎＩＤアイデンティティにリンクすることを可能にすることができる。ＯｐｅｎＩＤプロバイダに、所与のプラットフォームの登録されたアイデンティティのデータベースを保持するように要求することができる。ＯｐｅｎＩＤプロバイダは、所与のプラットフォーム証明書によって、正当なユーザを攻撃者から区別することができる。別のプラットフォームからのログインの試みが検出される時に、ＯｐｅｎＩＤプロバイダは、１）認証を拒否し、かつ／または２）アイデンティティの正当な所有者が次にログインする時に、その所有者に通知することができる。

【0070】

ＯｐｅｎＩＤ／ＧＢＡ認証方式とのＴＯｐｅｎＩＤの可能な統合を、ＮＡＦ／ＩｄＰに、プラットフォーム完全性値を検証するためのＴＯｐｅｎＩＤ ＩｄＰの能力を与えることとすることができる。ＮＡＦ／ＩｄＰからのＧＢＡ認可ヘッダは、ＴＯｐｅｎＩＤプロトコルからのチャレンジ（たとえば、ｉｄ、ｒｅｑ、ナンス）を直列化された形で含むことができる。受信時に、ＭＥ／ＵＥは、チャレンジを直列化解除し、これを、信頼されるチケットサーバおよび認可ダイジェストを計算するのに使用できるＧＢＡ鍵導出関数に多重化することができる。次に、両方の戻り値、たとえば、信頼されるチケットサーバからの署名された引用およびＭＬとＧＢＡプロセスからのダイジェスト値を、ＨＴＴＰ応答ヘッダ内でＮＡＦ／ＩｄＰに返すことができる。

【0071】

認証および信頼評価を組み合わせることができる。そのような組合せは、特定のＵＩＣＣ（たとえば、ＧＢＡクライアント）の使用を単一のプラットフォームに束縛することができる。ＮＡＦは、プラットフォームがある完全性証明された状態であり、プラットフォームを認証でき（たとえば、ＡＩＫによって）、ユーザを認証できる（たとえば、ＵＩＣＣ／ＧＢＡの所有によって）場合に、ＯｐｅｎＩＤ識別子を認可することができる。そのようなプロトコルは、単一ＵＩＣＣを有する単一の構成の単一のプラットフォームと共に、ユーザのＯｐｅｎＩＤ識別子を使用するために、ユーザをロックすることを可能にすることができる。

【0072】

図５および図６は、ＯｐｅｎＩＤ使用のためにＵＩＣＣ（たとえば、ユーザに関連する）およびＷＴＲＵを束縛することに関連する例示的な図である。図５に、例示的なコールフロー図を示す。図６に、コンポーネントの間の例示的な関係を示す。実施態様は、信頼されないＷＴＲＵ要素、たとえばブラウザとのセキュア通信を保証することができる。図５を参照すると、例示的なプロトコルステップは、次のうちの１つまたは複数を含むことができる １）ユーザが、ＲＰへの接続を確立することができ、２）ＲＰが、ＯＰ／ＮＡＦとの関連付けを開始することができ、３）ＲＰが、ＷＴＲＵのブラウザをＯＰ／ＮＡＦにリダイレクトすることができ、４）ＷＴＲＵとＯＰ／ＮＡＦとの間の通信が、認証の責任を負うことができるＴＴＳを介することができ（たとえば、ＴＴＳは、ＧＢＡチャレンジと一緒にＴＯｐｅｎＩＤチャレンジを受信することができる）、５）ＴＴＳが、ＵＩＣＣへのセキュアチャネルを確立することができ、６）ＴＴＳが、ＧＢＡチャレンジをＵＩＣＣに転送することができ、７）ＵＩＣＣが、ＯｐｅｎＩＤ／ＧＢＡプロトコルと同様にダイジェストを計算することができ、７ａ）ＵＩＣＣが、ＧＢＡレスポンスをＴＳＳに送信することができ（たとえば、ＯｐｅｎＩＤ／ＧＢＡダイジェストを用いて）、８）ＴＴＳが、ＴＯｐｅｎＩＤプロトコルのプラットフォーム妥当性検査データ／構成証明データを取り出すことができ、ここで、プラットフォーム妥当性検査データ／構成証明データは、ＷＴＲＵの信頼性の評価値（たとえば、ＡＩＫを用いて署名されたＳＭＬおよびＰＣＲ引用）を含むことができ、９）ＴＴＳが、ＵＩＣＣ ＧＢＡレスポンスおよびプラットフォーム妥当性検査データ／構成証明データを含む順序正しくまとめられたレスポンス内でＯＰ／ＮＡＦに応答することができ、１０）ＯＰ／ＮＡＦが、ＧＢＡレスポンスを検証し、プラットフォーム妥当性検査データ／構成証明データを用いて完全性を検証することができ（たとえば、ＳＭＬ ＰＣＲ引用が、ＯＰ／ＮＡＦによって以前に受信された以前に生成された基準値と一致することを検証する。これは、ＷＴＲＵの現在のシステム状態が以前の状態と一致することを示すことができる）、１１）ＯＰ／ＮＡＦが、ＷＴＲＵのブラウザを介してＲＰに肯定のアサーションを発行することができる（たとえば、ＲＰへのＭＥのブラウザのリダイレクト動作の一部として）。すなわち、ＮＡＦは、それがプラットフォーム妥当性検査データおよび／またはユーザを検証したことを示すプラットフォーム検証を送信することができる。プラットフォーム検証を、直接にまたは間接に通信することができる（たとえば、プラットフォーム検証は、依拠当事者（ＲＰ）へのアクセスを付与されるＷＴＲＵ／ユーザを含むことができる）。

【0073】

ＴＴＳは、必ずしもＵＩＣＣとのセキュアチャネルを確立しなければならないのではない可能性がある。２つの独立のセッションすなわち、ＵＩＣＣとＯＰ／ＮＡＦとの間の１つのＧＢＡセッションならびにＴＴＳとＯＰ／ＮＡＦとの間の構成証明セッションを実行することが可能である場合がある。ＯＰ／ＮＡＦは、両方のプロトコルが成功する場合に肯定のアサーションを発行することができる。そのような並列セッションシナリオでは、構成証明結果をＧＢＡプロトコルの認証結果に束縛するために、ＯＰが少なくとも内部的に両方のセッションをリンクすることが必要である場合がある。

【0074】

妥当性タスク（ｖａｌｉｄａｔｉｏｎ ｔａｓｋｓ）は、実行にネットワークおよびデバイス上の大量のリソースを必要とする可能性がある。妥当性検査されるデバイスは、たとえば新しい妥当性検査手順を受ける必要なしに、後続の認証手順またはネットワークコンポーネントとの相互作用のために妥当性検査情報を再利用することができる。たとえば、ネットワークとの以前の妥当性検査セッションから生成されたものとすることができる妥当性検査情報を再利用することができる。信頼されるチケットサーバは、次のように妥当性検査チケット（または証明書）を提供することができる。ネットワークに対するデバイスの成功の妥当性検査に続いて、ＭＮＯのネットワークの内部のＯＰ／ＮＡＦエンティティは、チケットを発行することができ、このチケットは、要求があり次第他のネットワークへの再配送のためにデバイスに通信され得、またはネットワークエンティティがＯＰ／ＮＡＦエンティティからチケットを間接的に入手できるように参照され得る。ＯＰ／ＮＡＦエンティティは、チケットと共に情報を含めることができ、その結果、チケットは、チケット／デバイス信頼性の指示を含むようになる。たとえば、ＯＰ／ＮＡＦエンティティは、タイムスタンプ、発信タイムスタンプ（ｏｒｉｇｉｎａｔｉｏｎ ｔｉｍｅｓｔａｍｐ）、チケットの寿命限度、チケットの終了日付、使用パラメータ限度などを提供することができる。時間情報は、ネットワークコンポーネントが、デバイスの信頼できる状態および査定が実行された時を確かめることを可能にすることができる。チケットを受信するエンティティは、デバイスとのセキュアトランザクションを行うのに満足に情報を検討することができ、またはデバイスへの信頼に関する特定のアプリケーションの必要に応じて再妥当性検査を強制することができる。

【0075】

そのようなチケットを、プラットフォーム妥当性検査および管理に使用することができる。チケットを、完全性保護し、かつ／または機密性保護することができ、その結果、チケットは、ＯＰ／ＮＡＦエンティティおよびデバイスに束縛されるようになり、チケットは、データが束縛されるデバイスまたはＯＰ／ＮＡＦ以外のエンティティによって変更できなくなる。デバイス内の信頼される環境（ＴｒＥ：ｔｒｕｓｔｅｄ ｅｎｖｉｒｏｎｍｅｎｔ）は、チケットをセキュアに格納し、再妥当性検査を実行する必要なしにネットワークとの後続相互作用にそのチケットを使用することができる。チケットを、デバイスによって分配して、他のネットワークコンポーネントに妥当性検査状況データを提供することができる。デバイスは、チケットへの参照を循環させることができ、この参照から、他のネットワークエンティティは、妥当性検査情報を入手するためにＯＰ／ＮＡＦエンティティに相談することができる。

【0076】

組み合わされたＴＯｐｅｎＩＤ／ＧＢＡの場合について、信頼エバリュエータ（信頼評価器：ｔｒｕｓｔ ｅｖａｌｕａｔｏｒ）、たとえばＴＴＳから測定を受信し、この査定に基づいて妥当性検査またはプラットフォームの信頼性に関するステートメントを導出するためにメトリックを参照するため、これらの測定を比較可能でありうるエンティティの位置は変化しうる。

【0077】

図７に、ＴＯｐｅｎＩＤ／ＧＢＡの場合の信頼エバリュエータとしてのプラットフォーム妥当性検査エンティティ（ＰＶＥ：ｐｌａｔｆｏｒｍ ｖａｌｉｄａｔｉｏｎ ｅｎｔｉｔｙ）の例を示す。図７は、プラットフォーム妥当性検査エンティティ（ＰＶＥ ７０５）、ＢＳＦ ７１０、ＵＥ ７２０、ＯＰ／ＮＡＦ ７３０、およびＲＰ ７４０を含む。妥当性検査プロセスをＭＮＯのネットワークの内部のＯＰ／ＮＡＦエンティティ内に統合するのではなく、信頼査定に関する基準完全性メトリックスを既に所有している可能性がある既存のネットワークエンティティを再利用することが可能である場合がある。そのような例を、ＰＶＥ ７０５など、プラットフォーム妥当性検査エンティティと称する場合がある。ＰＶＥ ７０５は、基準メトリックスを備えることができ、受信した妥当性検査データを基準メトリックスと比較し、デバイスの信頼性に関するステートメントを発行することができる可能性がある。そのようなシナリオでは、ＯＰ／ＮＡＦ ７３０は、内部ネットワーク内の妥当性検査データをＰＶＥ ７０５に転送することができ、ＰＶＥ ７０５は、信頼妥当性検査を実行することができる。

【0078】

信頼評価を、信頼されるサードパーティ（ＴＴＰ：ｔｒｕｓｔｅｄ ｔｈｉｒｄ ｐａｒｔｙ）によって実施することができる。ＭＮＯ内部エンティティが、受信された妥当性検査データの妥当性検査を実行するのに使用不能である場合には、ＮＡＦ／ＯＰは、セキュアチャネルを介して外部の信頼されるサードパーティに妥当性検査データを転送することができる。次に、ＴＴＰは、検証および妥当性検査を実行し、プラットフォームの信頼性に関するステートメントをＮＡＦ／ＯＰに戻って発行することができる。

【0079】

ユーザのプラットフォームの成功の認証および検証の後に、サービスプロバイダ（ＳＰ）は、署名されたｊａｖａ（登録商標）アプレットをＷＴＲＵに送信することができ、このｊａｖａアプレットは、ＷＴＲＵの信頼される環境（ＴｒＥ）にインストールされ得る。ＴｒＥは、ｊａｖａアプレットを信頼される環境にインストールする前に、たとえばＩｄＰまたは信頼されるサードパーティ（ＴＴＰ）によって供給されたＳＰまたはＲＩＭ証明書からの署名および／または証明書を介して、アプレット完全性を検証し、セキュアＵＩに関するＳＰチャレンジに回答することができる。ＴｒＥは、セキュアＵＩを使用してアプレットをロードし、現在のアプリケーションがセキュア環境内で動作できることをユーザに示すことができる。この方式を、偽ＳＰから保護することができ、たとえば、ＳＰに、認証し、ＩｄＰに完全性を供給するように要求することができる。この方式を、たとえばＩｄＰがＴｒＥ完全性および機能性を検証することと、チェックが成功である場合にチケットを発行することとによって、偽ＴｒＥから保護することもできる。

【0080】

分離された／サンドボックス化されたウェブブラウザを実施することができる。通常のブラウザ解決策とは異なって、これは、たとえばオンラインバンキング、ウェブメール、ビデオストリーミング、その他などのウェブアプリケーションの発行者向けとすることができ、彼らのウェブアプリケーションの特定のマニフェストを定義することができる。このディジタル署名されたマニフェストは、ウェブアプリケーションが接続すべき許可されるウェブサイトのリストおよびウェブアプリケーションがその中で動作しなければならないブラウザを含むことができる。ｖｍイメージへのＵＲＬなどのこのブラウザの仮想化されたエンティティを、マニフェスト内で定義することができ、ウェブアプリケーションを他のウェブアプリケーションおよび／またはホストオペレーティングシステム（０ｓ）から分離するために実施することができる。各サンドボックス化されたウェブアプリケーションを、たとえば信頼状態を提示するためにグラフィカル境界を使用することによってレンダリングすることができる。この概念を、ＸＥＮ仮想化を使用して実施することができる。ＷＴＲＵは、ＴＴＳを使用するプラットフォーム構成証明と、その後のデバイス上のＴｒＥ（小さい信頼されるサンドボックス化されたＪａｖａアプレットを実行する環境）を使用するアプリケーション構成証明との両方を実行することができる。ＴＴＳおよびＴｒＥが、両方ともＷＴＲＵデバイス内のある共通の信頼されるハードウェアコンポーネントの上に構築され、その機能を使用することができることに留意されたい。

【0081】

セキュアユーザインターフェース（セキュアＵＩ）は、セキュリティを高めるためにＴＯｐｅｎＩＤおよびＯｐｅｎＩＤを要求され得る。基本的なＴＯｐｅｎＩＤプロトコルは、その高められたセキュリティを信頼されるチケットサーバから導出することができ、信頼されるチケットサーバは、デバイス完全性情報を収集することができる。デバイス完全性情報を、ＯｐｅｎＩＤ ＩｄＰによって評価することができる。デバイス上で動作するソフトウェアが、周知の信頼される状態である場合には、認証は成功しうる。認証を、ＴＰＭに格納されＰＣＡ証明されるＡＩＫに束縛することができる。ＡＩＫを使用して、構成証明に使用されるＰＣＲ引用に署名することができる。認証を、所与の状態の所与のプラットフォーム（たとえば、ＴＰＭを有するデバイス）を用いる実施態様に制限することができる。

【0082】

構成証明および完全性チェックを、ある種のコンポーネント、たとえば、ＴＯｐｅｎＩＤのセキュア動作に必要なコンポーネントに制限することができる。そのような手法では、デバイスを、信頼される／セキュア部分と信頼されない部分とに分離することができる。信頼されるチケットサーバは、信頼される世界の内部の、信頼され、完全性がチェックされたアプリケーションとして動作することができる。ドライバを含む、ハードウェアへのアクセスを、信頼される世界内のサービスインスタンスによって保護することができる。デバイスの能力へのアクセスを、必要なＡＰＩを信頼されない世界に提供できるこのサービスインスタンスを介して制限することができる。これらのＡＰＩは、デバイス能力へのアクセスを提供し、アクセス制限を実施することを可能にすることができるセキュリティポリシフレームワークを備えることができる。

【0083】

ＩｄＰによる完全性チェックおよび検証が、デバイスの一部に制限される場合には、ユーザは、信頼されるチケットサーバを用いるＯｐｅｎＩＤ ＩＤの使用を確認し、この入力が中間者攻撃（ｍａｎ ｉｎ ｔｈｅ ｍｉｄｄｌｅ ａｔｔａｃｋ）またはｍａｎ ｉｎ ｔｈｅ ｄｅｖｉｃｅ／ｍａｎ ｉｎ ｔｈｅ ｂｒｏｗｓｅｒ攻撃の形でインターセプトされまたは再生され得ないことを確認する必要がある場合がある。信頼される部分は、入力を保護し、ユーザがセキュアモードのデバイスを使用しつつある可能性があることをユーザに示すことができる信頼されるユーザインターフェース（ＵＩ）を提供することができる。例のインジケータを、デバイス（プロセッサ）が信頼されるモードで動作しつつある場合に光ることのできる発光ダイオード（ＬＥＤ）とすることができる。ＬＥＤを、信頼される要素またはセキュア要素によって制御することができる。ユーザがＯｐｅｎＩＤチケットの使用のために証明書を入力しなければならない時には必ず、セキュアＵＩは、デバイスがセキュアモードで動作しつつあることを示すことができる。ＬＥＤなどのデバイスは、セキュアハードウェアインターフェースを介して保護された外部プロセッサインターフェースに接続されたあるマッピング可能アドレス空間内にあるものとすることができ、ここで、アクセスを、セキュアな信頼される環境に制限することができる。

【0084】

グラフィックスデバイスの保護されたフレームバッファの諸部分を使用することができる。他のドライバは、デバイスメモリのこの部分に書き込みまたはこれから読み取ることを許可されないものとすることができる。次に、セキュア／信頼されるドライバは、悪意のあるソフトウェアによる「セキュアアイコン」の表示を防ぐためにディスプレイフレームバッファに直接に書き込むことによってデバイスのディスプレイ上にグラフィカル情報を表示することによって、セキュアＵＩの使用を示すためにこのフレームバッファメモリを使用することができる。

【0085】

ＯｐｅｎＩＤ認証用のＵＩとして働くことができるブラウザを、完全性チェック検査し、信頼される世界に統合することができる。ブラウザが、信頼される部分に含まれない場合には、ユーザに、ユーザＯｐｅｎＩＤログインが使用されるたびに、セキュアＵＩを介して同意を提供するように要求することができる。ユーザが、ＯｐｅｎＩＤ識別子を使用してサイトにログインすることを望む場合には、ブラウザは、信頼されるチケットサーバにチャレンジを転送することができる。信頼されるチケットサーバは、ＵＩをセキュアＵＩに切り替え、ユーザに同意インターフェースを提示することができ、同意インターフェースは、認証を終了するためにセキュアＵＩと対話するようにユーザに要求することができる。信頼されるチケットサーバは、レスポンスを生成し、これをＯｐｅｎＩＤ ＩｄＰに転送し、潜在的に危険にさらされるブラウザをバイパスすることができる。ＴｒｕｓｔｅｄＯｐｅｎＩＤプロセスでは、ＷＴＲＵのブラウザおよびユーザインターフェースを保護することができる。

【0086】

信頼されるビジュアルトークン（ＴＶＴ：Ｔｒｕｓｔｅｄ Ｖｉｓｕａｌ Ｔｏｋｅｎ）を使用することができる。信頼されるビジュアルトークンは、次の技術的特徴のうちの１つまたは複数の組合せを含むことができる。

【0087】

ビジュアル構成証明は、ユーザのプラットフォーム（ユーザが対話するデバイス）が信頼できる状態であることをアテストする、あるビジュアル情報のユーザへの表示を含むことができる。そのようなビジュアル情報は、暗号化された形でプラットフォーム上に存在する、たとえばユーザに既知であるが他者に既知ではない、秘密のイメージを含むことができ、ここで、暗号化解除は、プラットフォームが事前に定義された状態である場合に許可されるものとすることができる。これを、シーリングと称する場合がある。

【0088】

ビジュアル構成証明を、追加のビジュアライゼーション法によって増強することができる。たとえば、特定の取引が行われることのデータ（たとえば、ユーザ認証、支払データなど）を、ビジュアライゼーションに含めることができる。これは、キャプチャアンドリプレイ（ｃａｐｔｕｒｅ−ａｎｄ−ｒｅｐｌａｙ）攻撃をよりむずかしくすることができる。

【0089】

特権インジケータ（Ｐｒｉｖｉｌｅｇｅｄ Ｉｎｄｉｃａｔｏｒ：ＰＩ）は、プラットフォームの内部のエンドポイントが信頼される環境またはセキュア要素、たとえば、所望の取引において信頼できる可能性がある、ある実行スペースである、プラットフォームのセキュア入力パス（たとえば、鍵）とすることができる。

【0090】

ユーザは、自身の支配下のチャレンジ−レスポンス機構によってプラットフォームのビジュアル構成証明を制御することができる。ユーザは、取引（たとえば、認証、オンライン支払など）プロセス中のある点で、自身のプラットフォームにチャレンジを提示することができ、このチャレンジに対して、プラットフォームは、ビジュアル構成証明を応答することができる。これを、特権インジケータを使用して実施することができる。

【0091】

特権インジケータチャレンジを、取引中に手続的に使用し、これを迂回できないように取引と組み合わせることができる。

【0092】

上の特徴を、信頼されるビジュアルトークン（ＴＶＴ）としてのオンライン取引での使用のためにプラットフォーム内で組み合わせることができる。ＴＶＴは、たとえばソフトウェア信頼される環境内またはハードウェアセキュア実行環境（スマートカードなど）内で実現される、ＰＩを介して提示されるユーザチャレンジに対してビジュアル構成証明を用いて事前に定義された形で応答できる、ユーザのプラットフォーム上の信頼できるエンティティとすることができる。ＴＶＴは、次の特徴のうちの１つまたは複数を有することができる。

【0093】

ＴＶＴの信頼できる状態をユーザに提供するＴＶＴビジュアル構成証明を、プラットフォームの主または別の、専用ディスプレイ上でユーザに表示することができる。

【0094】

ＴＶＴは、ビジュアル構成証明のためにハードウェア保護された（たとえば、スマートカード、ＴＰＭシールされたなど）秘密を使用することができる。

【0095】

ＴＶＴは、バイオメトリック入力など、ユーザを認証する方法へのアクセスを有することができる。

【0096】

ＴＶＴの信頼できる状態を、リモート当事者によって、たとえばリモート構成証明を使用することによって、妥当性検査することができる。

【0097】

ＴＶＴは、プラットフォームの他のコンポーネント、たとえばブラウザまたはオンラインバンキングアプリケーションを妥当性検査し、これらのコンポーネントの信頼性に関する情報をビジュアル構成証明に組み込むことができる。

【0098】

ＴＶＴは、特定の取引に固有のデータへのアクセスを有することができ、意味のある一意の形でそのようなデータをビジュアル構成証明に組み込むことができるものとすることができる。

【0099】

ビジュアル構成証明にＴＶＴによって表示されるものの基本的なモーダリティは、特定のユースケースで必要に応じて組み合わせることができる、次のうちの１つまたは複数を含むことができる。

【0100】

ＴＶＴは、ユーザに関連する情報、たとえば、ユーザが記録した秘密、個人情報などを表示することができる。ＴＶＴは、時間依存とすることができるＴＶＴ固有の秘密を表示することができる。ＴＶＴは、取引固有データ、たとえば取引番号、取引量、通貨タイプなどを表示することができる。ＴＶＴは、ユーザ通知を表示することができ、たとえば、ユーザに、たとえば特権インジケータを押したままにしながら指紋リーダーを使用することによって、取引を認可するように促すことができる。

【0101】

取引でのＴＶＴの基本的な使用は、ローカルにまたはリモート当事者へのいずれかの、ユーザ認証の使用である。このプロセスは、「ログオン」と称する場合があるが、次の特徴のうちの１つまたは複数を含むことができる。

【0102】

ユーザが、プラットフォームまたはリモートサービスにログオンすることを望む時には、ユーザは、ウェブ上のサービスのログオンページへのログオンアプリケーションまたはブラウザを開くことができる。ユーザは、ＰＩを押し、ログオンに関するビジュアル構成証明を入手することができる。図８に、一例を提供する。

【0103】

この形のビジュアライゼーションを、ＴＶＴの状態に対してアテストする秘密イメージを含めることによって増強することができる。図９に例を示す。

【0104】

ＴＶＴビジュアル構成証明のさらなるセキュリティ強化を、追加情報、たとえばランダムに現れる、削除がむずかしい、新鮮な、機械依存の、人間可読情報を含めることによって達成することができる。図１０に例を示す。

【0105】

ユーザログオンに関するＴＶＴのアクティビティを、リモート当事者、たとえばユーザ認証を要求するウェブサービスによってトリガすることができる。リモートサービスは、それがユーザ認証を必要とすることをプラットフォーム上のＴＶＴにシグナリングすることができ（たとえば、相互に認証されたチャネルを介して）、このシグナリングの際に、ＴＶＴは、包括的ログオン通知を表示する。たとえば、ユーザは、ＰＩを押すことができ、ＴＶＴは、それ自体のビジュアル構成証明を実行する。ユーザは、本明細書で説明される直接ログオン変形形態と同様に、たとえばバイオメトリック入力を使用して、ローカルに認証することができる。図１１に、例示的なビジュアル指示を提供する。

【0106】

図１２ならびに以下の説明は、ｔｒｕｓｔｅｄ ｃｏｍｐｕｔｉｎｇ概念に基づくプラットフォーム上のＴＶＴの例示的実施態様を提供する。以下は、例としてＭｉｃｒｏｓｏｆｔ（登録商標） Ｗｉｎｄｏｗｓ（登録商標）ネットワークドメインを含む場合があるが、そのような実施態様に限定されない。

【0107】

次の頭字語が、図１２および以下の議論で使用される可能性がある。
ＴＣＢ 信頼されるコンピューティングベース
ＢＩＯ バイオメトリック認証機能
ＲｏＴ 信頼のルート
ＭＯＤ ＬＳＡＳＳ 変更されたＬｏｃａｌ Ｓｅｃｕｒｉｔｙ Ａｕｔｈｏｒｉｔｙ Ｓｕｂｓｙｓｔｅｍ ローカルユーザログオンおよびネットワークユーザログオンの責任を負うＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓコンポーネント
ＲＥＱ 「要求」
ＤＥＣ ＥＮＣの暗号化解除鍵
ＥＮＣ ＴＶＴ秘密データを暗号化する鍵

【0108】

システムスタートアップ時のセキュアブートプロセスまたは認証されるブートプロセスでは、プラットフォームのＲｏｔは、ＴＶＴアプリケーションの状態を測定し、かつ／またはたとえばプラットフォームのＰＣＲ（プラットフォーム構成レジスタ）（１ｂ）内に格納する（１ａ）ことができる。ＴＶＴアプリケーションを、ランタイムのＴＶＴの保護を含む信頼される環境に含めることができる。測定機能ならびにＲｏＴは、プラットフォームのＴＣＢ内、たとえば、システム動作中に無条件で安全と考えられるコンポーネントのセット内に含まれる。

【0109】

ユーザが、このプラットフォームを使用してネットワークドメインにログオンすることを望む時に、ドメインコントローラは、プラットフォームにユーザ証明書を要求する（２）ことができる。ＴＶＴアクティブ化は、この時点で発生することができ、リモートに要求されたＴＶＴユーザログオンが、本明細書で説明されるように開始され得る。ユーザに、ＰＩを使用するように通知することができ、たとえば、（３）での使用を参照されたい。ＰＩ信号は、ＴＣＢ内に含まれるあるＰＩ機能性に送信される。

【0110】

ＰＩ機能性は、ＴＶＴマスタ暗号化解除鍵Ｄｅｃをシール解除し（４）、ＴＶＴの状態を引用して、プラットフォームＲｏＴにＤｅｃのシール解除要求を発行することができる。ＲｏＴｓは、状態をチェックし、たとえば状態が正しい場合に、Ｄｅｃを暗号化解除する（５）ことができる（シール解除）。

【0111】

Ｄｅｃ鍵は、鍵下位層のうちでＴＣＢの内部での使用に制限された部分である鍵、たとえばＴＰＭ鍵階層の鍵を指すことができる。Ｄｅｃを使用して、対応する暗号化鍵Ｅｎｃを用いて暗号化されたＴＶＴビジュアル構成証明シードを暗号化解除することができる。

【0112】

ＰＩ機能性は、ユーザに対してビジュアルにアテストするようにＴＶＴアプリケーションに指令する（６）ことができる。ＴＶＴアプリケーションは、ＴＶＴシードの暗号化解除を要求する（７）ことができ、この暗号化解除は、Ｄｅｃを使用して実行され（８）得、ＴＶＴシードは、ＴＶＴアプリケーションに提供され（９）得る。これらを使用して、ＴＶＴアプリケーションは、たとえばバイオメトリック入力ＢＩＯを使用する、ローカルユーザ認証の要求を含む、ビジュアル構成証明を実行する（１０）ことができる。

【0113】

ユーザは、ＢＩＯに認証する（１１）ことができ、ＢＩＯ機能性は、認証成功をＴＶＴにシグナリングする（１２）ことができる。

【0114】

ＴＶＴは、そのユーザアカウントデータストレージにユーザ証明書、たとえばネットワークログオンに使用されるユーザ名およびパスワードを要求する（１３）ことができる。そのデータを、暗号化解除し、ＴＶＴに送信することができ、ＴＶＴは、これをログオンアプリケーションＬＳＡＳＳに提供する（１４）ことができ、ログオンアプリケーションＬＳＡＳＳは、これをネットワークドメインコントローラに転送することができる。

【0115】

ＴＶＴによって使用される秘密は、２つのクラスを含むことができる。

【0116】

ＴＶＴシードは、ユーザにビジュアライズし、リモートエンティティとセキュアに通信するのにＴＶＴが使用する秘密を含むことができ、この秘密は、ビジュアライゼーション用のシード、ＴＶＴの個々の秘密（たとえば、プラットフォームに固有）、他のエンティティとのセキュア通信用のＴＶＴ証明書、ユーザ定義のパラメータ、アプリケーションごとの秘密、ユーザが記録した秘密などのうちの１つまたは複数を含むことができる。ユーザアカウントデータは、パスワード金庫（ｐａｓｓｗｏｒｄ ｖａｕｌｔ）に似たものとすることができるＴＶＴの機能を表すことができる。ユーザアカウントデータは、バイオメトリックユーザ基準データ、ドメイン、リモートサービス、およびユーザ名のリストおよび関連付け、ユーザ証明書、たとえばパスワードまたはパスワードのハッシュ値、リモートサービスまたはドメインコントローラの認証用の証明書などのうちの１つまたは複数を含むが、これらに限定されない。

【0117】

相互認証を、ＲＰとＴＴＳとの間で行うことができる。ＯｐｅｎＩＤプロトコルを、ＲＰ−ユーザインターフェースをどのようにして保護できるのかおよびユーザを悪意のあるＲＰからどのようにして保護できるのかを含むように定義することができる。悪意のあるＲＰは、ユーザがＲＰでログインフィールドに自身のアイデンティティ（たとえば、ＯｐｅｎＩＤ識別子）を入力する時に、ＯｐｅｎＩＤプロトコルに対する脅威を押し付ける可能性がある。ユーザは、基礎になるプロセスが何を行いつつあるのかを理解しない場合があるが、ユーザを、ユーザが訪れるサイトについてユーザのアイデンティティをＯｐｅｎＩＤを使用して管理できるＩｄＰページにリダイレクトすることができる。ＩｄＰでは、ユーザは、自身の証明書（たとえば、パスワード）を入力することができ、リダイレクトされ得る。しかし、ユーザが、やはりＯｐｅｎＩＤ対応である別のページを訪れる時に、ＩｄＰは、パスワードをもう一度要求しないものとすることができ、その代わりに格納されたクッキーを使用することができる。悪意のあるサイトのＲＰは、ユーザ証明書（パスワード）を盗むことを目指す偽サイトである可能性がある、説得力のある外見のＩｄＰへユーザをリダイレクトできる可能性がある。次に、偽ＩｄＰは、実際のＩｄＰを用いてユーザをＯｐｅｎＩＤにログインさせることができ、ユーザは、異常を経験しない可能性がある。攻撃の影響は、ＩｄＰが、ユーザがＯｐｅｎＩＤを使用してログインしたサイトのＳＳＯポイントとして働くことができ、したがって、攻撃者がユーザから多数のアカウントを盗むことができるという事実によって増やされる可能性がある。単一の悪意のあるＲＰウェブサイトを使用して、パスワードを収集する偽ＩｄＰページを訪問するようにユーザをだますことができる。

【0118】

ＲＰ認証を、ＴＴＳを使用して行うことができる。パスワードフィッシング攻撃を、次のうちの１つまたは複数を使用することによって軽減することができる。

【0119】

Ｍｉｃｒｏｓｏｆｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｃａｒｄｓを、たとえば盗まれる可能性があるパスワードをユーザが入力しなくてもよくなるように、証明書として使用することができる。Ｉｎｆｏｒｍａｔｉｏｎ Ｃａｒｄｓは、ユーザに、スクリーン上でそこから選択すべき複数の「カード」を示すことができるＭｉｃｒｏｓｏｆｔ社の技術である。ユーザは、サービスに認証するためにカードを選択することができる。Ｉｎｆｏｒｍａｔｉｏｎ Ｃａｒｄｓは、アイデンティティに関する所有の証明を提供するために、暗号証明を使用することができる。これらの証明を、再利用可能ではないものとすることができ、再生することができず、したがって、パスワードハーベスティングサイト（ｐａｓｓｗｏｒｄ ｈａｒｖｅｓｔｉｎｇ ｓｉｔｅ）による取込は、ＯｐｅｎＩＤアイデンティティへのアクセスをもたらすことができない。

【0120】

各ＲＰを、ユーザの側で認証することができる。そのような認証を、ユーザがＯｐｅｎＩＤに期待しているＳＳＯ経験に干渉しないセキュアな形で実行することができる。ＴＯｐｅｎＩＤでは、ＴＴＳを、ＲＰからの所与の証明書を検証するエンティティとすることができる。ＲＰへのＨＴＴＰＳ接続を使用する時に、ＴＴＳは、ブラウザのプロキシとして働き、ブラウザからＯｐｅｎＩＤ対応サイトへの呼出しをインターセプトすることができる。そのようなインターセプト機構は、ＨＴＴＰ ＧＥＴ要求の後にＲＰからブラウザに送信されるページ内のログインフォームを認識することができる。その後、ＴＴＳは、ドメイン証明書を要求し、その妥当性をチェックすることができる。証明書が有効である場合には、ユーザは、少なくとも、自身が訪れるサイトが暗号化された接続を使用することを保証され得る。ａｓｓｅｒｔｅｄ ｉｄｅｎｔｉｔｙなどのＳＳＬ（セキュアソケットレイヤ）証明書の追加の特徴を、確立し、ＴＴＳによってチェックすることができる。ａｓｓｅｒｔｅｄ ｉｄｅｎｔｉｔｙは、ＴＴＰが周知のページのデータベースまたは既知のフィッシングサイト、マルウェアサイトなどのブラックリストを維持することとすることができ、そのようなサイトによって使用されることが既知のすべての証明書の取消リストをＴＴＳに提供する。

【0121】

ＴＴＳは、モジュラ手法で拡張できる能力を有することができる。たとえば、Ｇｏｏｇｌｅ Ｐａｇｅｒａｎｋ（登録商標）、Ｗｅｂ Ｏｆ Ｔｒｕｓｔスコアを評価するモジュール、評判システムを考慮に入れる別のモジュールなどがあるものとすることができる。これらのモジュールは、ＴＴＳにスコアを提供することができ、ＴＴＳは、たとえばユーザ定義の重み付けポリシの使用によって、モジュール入力の要約されたスコアを計算し、サイトの査定をユーザに提示することができるものとすることができる。そのような特徴は、たとえば、不一致または発行するＣＡへの信頼関係の欠如の場合にユーザが証明書をチェックするように求められるＦｉｒｅｆｏｘ（登録商標）またはＩｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（登録商標）での既存の質問を超える可能性がある。これらのモジュールを、ＳＳＬ証明書が使用可能ではない可能性がある、ＲＰへの非ＨＴＴＰＳ接続に使用することもできる。一般に、モジュールは、セキュア環境内、たとえば、ＴＴＳによって使用されるものと同一のセキュア環境内で動作することができ、ＴＴＳとセキュアに通信できるものとすることができる。

【0122】

既存ページのハッシュ値の小さい基準データベースを維持することが可能である場合がある。記録プロセスは、新しいページについて定義されなければならない可能性があるが、基準メトリックのセットがウェブページ／サーバについて存在すると仮定して、ＴＴＳは、これらの基準メトリックを利用して、訪問されるＲＰの完全性および真正性を検証することができる。ＴＴＳプロトコルおよびＯｐｅｎＩＤ ＩｄＰプロトコルに似たリモート構成証明プロトコルに従って、ＲＰは、ＴＴＳに対してその完全性をアテストすることができ、ＴＴＳは、その後、成功の構成証明の場合にさらに進行することを許可することができる。

【0123】

ＴＴＳとＲＰとの間の例示的な相互認証は、次のうちの１つまたは複数を含むことができる。相互認証は、ＲＰウェブサイトおよびサーバのアイデンティティおよび信頼性のチェック以上のことをすることができる。このプロセスは、ＲＰによる、デバイス上で動作するＴＴＳの完全性および真正性のチェックを含むことができる。これは、ＴＯｐｅｎＩＤの会社または政府の記録に有用である可能性があり、ここで、ＲＰは、ユーザが実際に認証機構としてＴＯｐｅｎＩＤを使用していることを保証され得る。ＲＰは、あるタイプの認証機構、たとえばＴＯｐｅｎＩＤが、ＩｄＰとユーザＴＴＳとの間で使用されることを保証されることを望む可能性がある。しかし、ＲＰは、それでも、ＩｄＰが実際にＴＴＳを使用することを信頼しなければならない可能性がある。そうでない場合に、ユーザは、自身のＯｐｅｎＩＤ ＩｄＰに対して別の機構を使用して認証しながら、ＴＯｐｅｎＩＤを使用すると主張することができる。

【0124】

そのような認証は、プロトコルに対する複数の変更を含むことができる。ＲＰは、（たとえば、ユーザのデバイス上のＴＴＳの真正性およびおそらくは完全性を検証した後に）ＴＴＳにある種のナンスを送信することができる。このナンスは、一意であり、この特定のクライアントＴＴＳからのこの要求の識別子として働くことができる。ＴＴＳは、このナンスを、ログイン要求に関連付けられて、保護されたストレージにセキュアに格納することができる。ＲＰがユーザをＩｄＰにリダイレクトした後に、ＩｄＰは、ＴＯｐｅｎＩＤと同様に認証プロトコルを実行することができる。ＴＴＳは、以前に認証されたＯＰにナンスを解放することができる（たとえば、解放を、ＴＯｐｅｎＩＤプロトコルでの使用に制限することができる）。ＩｄＰからＲＰに来るアサーションは、ナンスを含む必要がある可能性があり、このナンスは、ＴＯｐｅｎＩＤが実際に認証に使用されたことをＲＰに保証することができる。

【0125】

このシナリオで使用される用語ナンスは、ＴＯｐｅｎＩＤ認証がＩｄＰと共に使用され得ることを検証するためにＲＰによってＴＴＳに渡されるトークンを記述するのに使用され得る。

【0126】

ナンスのセキュリティプロパティを定義するために、異なる攻撃タイプを検討することができる。ユーザは、非ＴＯｐｅｎＩＤ認証を実行し終えた後に、通信にナンスを注入することを試みることができる。これは、ユーザが、不可能ではないとしても困難であると仮定され得る、ＩｄＰとＲＰとの間の通信にインターセプトすることを要求する可能性がある。ユーザは、ＴＴＳまたはＲＰとのＴＴＳからの初期通信からナンスを抽出することもできる。これは、ナンスがセキュアストレージに格納され、ＴＴＳが危険にさらされていない場合には、困難である可能性がある。危険にさらされたＴＴＳが、ＲＰからそのようなナンスを受信しない可能性があると仮定することができる。というのは、ＲＰが、まず、ＴＴＳ完全性を検証し、その後にナンスを送信することができるからである。そのようなセキュリティを意識するＲＰは、ユーザのデバイス上で動作するＴＴＳインスタンスの完全性メトリックを備えることができる。ＲＰからナンスを受信しつつあるＴＴＳインスタンスが保護される場合には、これらのＴＴＳが悪意のあるユーザからナンスをセキュアに保護すると仮定することができる。

【0127】

もう１つの攻撃モデルは、悪意のあるＩｄＰを含むことができ、この悪意のあるＩｄＰは、認証機構をだますことを試みることができ、したがって、ＴＴＳからナンスを取り出すことができる。そのようなシナリオでは、ＴＴＳがナンスを効率的に保護すると仮定することができる。より複雑な攻撃モデルは、共謀するＩｄＰおよびユーザを含むことができる。ユーザが、ナンスを獲得できる場合には、そのユーザは、ＴＯｐｅｎＩＤ認証を実行せずにそのナンスをＩｄＰに転送することができる。次に、ＩｄＰは、ユーザがＴＯｐｅｎＩＤを使用して認証したと主張しながら、ＲＰヘのメッセージでそのナンスを使用することができる。

【0128】

検討される攻撃モデルでは、ＴＴＳがＲＰによって完全性チェックされる場合にＴＴＳがナンスを受信でき、そのようなＴＴＳがナンスを十分に保護でき、そのナンスをＴＯｐｅｎＩＤ認証プロトコルに公開することに制限され得るという事実に、セキュリティが頼ることができることがわかる。ナンスをサービスアクセスごとに一意とすることができるので、悪意のあるＩｄＰは、これをＲＰに再生することができない。

【0129】

このプロトコルは、構成証明機構を含むことができる。ＯｐｅｎＩＤプロバイダは、システム状態に関する情報を提供するためにユーザにチャレンジすることができる。システムが信頼できる状態である場合には、アクセスを付与することができる。これは、サービスへのアクセスを「信頼できる」システムに制限することができるので、ウェブアプリケーションに関するセキュリティを活用することができる。

【0130】

着信ＯｐｅｎＩＤ認証要求をリスンし、これらをＴＰＭに転送するユーザ側のサービスアプリケーションを有するのではなく、シームレスブラウザ統合を提供することができる。これを、この機能性を引き受けるブラウザ拡張を使用することによって達成することができる。ＯｐｅｎＩＤプロバイダは、サインインページのＨＴＭＬコードの内部でチャレンジを発行することができる。ブラウザ拡張は、この情報を読み取り、必要なデータをＴＰＭに転送することができる。ＴＰＭは、署名されたチケットを作成し、これをブラウザ拡張に返すことができる。次に、拡張は、署名されたチケットを含む正しいＨＴＴＰＳ応答をＯｐｅｎＩＤプロバイダに発行することができる。

【0131】

デバイスがＵＩＣＣを有する場合に、ブラウザを、デバイス内のＵＩＣＣ上で実施することができる。ＵＩＣＣ上でのブラウザの実施は、デバイスに、ブラウザがそこから動作するための固有のセキュア環境を与えることができる。ＵＩＣＣ内のブラウザとデバイスの残り（ＴＰＭを含む）との間のインターフェースを、ＧＢＡベースのセキュアチャネルを使用して保護することもできる。

【0132】

ＯＭＴＰ ＢＯＮＤＩフレームワークは、ウィジェットまたはウェブアプリケーションがＨＴＭＬページ内のｊａｖａ ｓｃｒｉｐｔを介してデバイス能力にアクセスすることを可能にすることができるＡＰＩのスイートである。ＢＯＮＤＩを、さらなるデバイス能力へのアクセスを可能にするための追加ＡＰＩよって拡張可能とすることができる。特定の基礎になるデバイス能力へのアクセスを試みるＪａｖａ Ｓｃｒｉｐｔ ＡＰＩと独立にこれらの能力へのアクセスを実施できるように、ＢＯＮＤＩセキュリティフレームワークを、デバイス能力アクセス制御機構を提供するように制限することができる。ＢＯＮＤＩは、デバイス能力をシールドすることができない。ＢＯＮＤＩは、デバイスのリソースおよび能力への排他的なアクセスプロバイダになることができない。ＢＯＮＤＩに加えて他のフレームワークまたは機能が存在する場合には、ＢＯＮＤＩフレームワークの外部のこれらの非ＢＯＮＤＩ独自Ｊａｖａ Ｓｃｒｉｐｔ ＡＰＩまたはプラグインは、制御されまたは管理されることができず、これらは、ＢＯＮＤＩセキュリティフレームワークをむしばむ可能性がある。

【0133】

図１３は、ＴＯｐｅｎＩＤと共のＢＯＮＤＩの例示的な使用の図である。１では、ユーザが、ＲＰを訪問し、ＩＤに関するＸＲＩを送信することができる。２では、関連付けを、ＲＰとＯＰとの間で作成することができる。３では、ＯＰが、ＨＴＴＰ（Ｓ）認証ページを提示することができる。３ｂでは、信頼されるチケットサーバが、構成証明のために署名されたＳＭＬ ＰＣＲを提供することができる。４では、ＯＰが、ＳＭＬ ＰＣＲを妥当性検査することができる。５では、ＯＰが、ユーザがログインした状態でＲＰのＵＲＬにリダイレクトすることができる。

【0134】

たとえばポリシの管理および実施をセキュアに格納でき、デバイス能力へのアクセスプロバイダがＢＯＮＤＩフレームワークに制限されるように、ＢＯＮＤＩが、信頼される実行環境の上で実行される場合には、デバイス能力にセキュアにアクセスするウェブアプリケーションを作成することが可能である可能性がある。そのような機能は、ウェブページからデバイス内の保護された機能への間接アクセスを含むことができる。信頼されるＢＯＮＤＩの実行と、ウェブページがデバイス上で動作する信頼されるチケットサーバサービスにアクセスすることを可能にする特殊なＡＰＩの追加とが、ブラウザへのＴＯｐｅｎＩＤのシームレスな統合の新しい形を開くことができる。

【0135】

図１４に、ＴＯｐｅｎＩＤと共のＢＯＮＤＩの使用の例示的なコールフロー図を示す。ＯｐｅｎＩＤ ＯＰは、ＴＯｐｅｎＩＤ対応アカウント用の認証ページ内にＢＯＮＤＩ ｊａｖａ ｓｃｒｉｐｔコマンドを含めることができる。ページの内部のこのｊａｖａ ｓｃｒｉｐｔは、クライアントのブラウザによって実行され得、まず、ＢＯＮＤＩのライブラリおよびＡＰＩをロードすることができる。ｊａｖａ ｓｃｒｉｐｔは、ＨＴＭＬページから信頼されるチケットサーバを照会することができる。照会は、ＯｐｅｎＩＤ ＯＰからのＩＤ、ＲＥＱ、およびナンスを含むことができる。ＢＯＮＤＩ ＡＰＩを介して、照会を、デバイス上のチケットサーバに転送することができる。ＢＯＮＤＩセキュリティポリシを使用して、信頼されるチケットサーバへのアクセスを、たとえば単一のＯｐｅｎＩＤ ＯＰに制限することができる。要求を、許可のためまたは信頼されるチケットサーバへのアクセスの試みのたびにユーザ同意を要求するために、ユーザに対して行うことができる。信頼されるチケットサーバは、署名されたＰＣＲ引用Ｑおよび測定ログＭＬを取り出し、ＨＴＴＰ ＰＯＳＴメッセージを使用してこれらの値をＯｐｅｎＩＤ ＯＰに転送することができる。次に、ＯＰは、受信されたデータを評価し、基本的なＴＯｐｅｎＩＤの場合と同様にプロトコルに進むことができる。そのような統合の利益は、より少ないユーザ対話が要求される可能性があり、ＯＰが、チケット、たとえば引用およびＭＬのトランスポートのために第２通信チャネルを開始する必要なしに、ＨＴＴＰプロトコルを介して信頼されるチケットサーバと直接に通信できることとすることができる。

【0136】

図１５は、例示的なＯｐｅｎＩＤプロトコルの図である。

【0137】

図１６は、例示的なＯＡｕｔｈプロトコルの図である。

【0138】

図１７は、例示的な組み合わされたＯｐｅｎＩＤ／ＯＡｕｔｈプロトコルの図である。

【0139】

図１８は、Ｇｏｏｇｌｅ ＯｐｅｎＩＤと共の例示的なＯｐｅｎＩＤプロトコルの図である。

【0140】

図１９は、Ｇｏｏｇｌｅ ＡＰＩを使用する例示的なＯＡｕｔｈプロトコルの図である。

【0141】

本明細書で開示されるように、ユーザクライアント／プラットフォームを、たとえば無線通信システム内で使用できるＷＴＲＵまたは基地局とすることができる。他の無線通信システムにも適用可能ではあるが、一例では、図２０に、Ｅ−ＵＴＲＡＮ（Ｅｖｏｌｖｅｄ−Ｕｎｉｖｅｒｓａｌ Ｔｅｒｒｅｓｔｒｉａｌ Ｒａｄｉｏ Ａｃｃｅｓｓ Ｎｅｔｗｏｒｋ）４０５を含む例示的なＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）無線通信システム／アクセスネットワーク４００を示す。Ｅ−ＵＴＲＡＮ ４０５は、複数のｅＮＢ（ｅｖｏｌｖｅｄ Ｎｏｄｅ−Ｂ）４２０を含む。ＷＴＲＵ ４１０は、ｅＮＢ ４２０と通信している。ｅＮＢ ４２０は、Ｘ２インターフェースを使用してお互いとインターフェースする。ｅＮＢ ４２０のそれぞれは、Ｓ１インターフェースを介してＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）４３０とインターフェースする。単一のＷＴＲＵ ４１０および３つのｅＮＢ ４２０が図２０に図示されているが、無線デバイスおよび有線デバイスの任意の組合せを無線通信システムアクセスネットワーク４００内に含めることができることは明白である。

【0142】

図２１は、ＷＴＲＵ ４１０、ｅＮＢ ４２０、およびＭＭＥ／Ｓ−ＧＷ ４３０を含むＬＴＥ無線通信システムを５００の例示的なブロック図である。図２１に示されているように、ＷＴＲＵ ４１０、ｅＮＢ ４２０、およびＭＭＥ／Ｓ−ＧＷ ４３０は、リンケージを使用するブラインド復号（ＢＤ）複雑さ低減の方法を実行するように構成される。

【0143】

通常のＷＴＲＵ内で見つけることのできるコンポーネントに加えて、ＷＴＲＵ ４１０は、オプションのリンクされたメモリ５２２を有するプロセッサ５１６、少なくとも１つのトランシーバ５１４、オプションのバッテリ５２０、およびアンテナ５１８を含む。プロセッサ５１６を、本明細書で開示される方法を実行するように構成することができる。トランシーバ５１４は、無線通信の送信および受信を容易にするためにプロセッサ５１６およびアンテナ５１８と通信している。バッテリ５２０がＷＴＲＵ ４１０内で使用される場合には、バッテリ５２０は、トランシーバ５１４およびプロセッサ５１６に電力を供給する。

【0144】

通常のｅＮＢ内で見つけることのできるコンポーネントに加えて、ｅＮＢ ４２０は、オプションのリンクされたメモリ５１５を有するプロセッサ５１７、トランシーバ５１９、およびアンテナ５２１を含む。プロセッサ５１７を、本明細書で開示される方法を実行するように構成することができる。トランシーバ５１９は、無線通信の送信および受信を容易にするためにプロセッサ５１７およびアンテナ５２１と通信している。ｅＮＢ ４２０は、オプションのリンクされたメモリ５３４を有するプロセッサ５３３を含むＭＭＥ（Ｍｏｂｉｌｉｔｙ Ｍａｎａｇｅｍｅｎｔ Ｅｎｔｉｔｙ）／Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ Ｇａｔｅｗａｙ）４３０に接続される。

【0145】

特徴および要素が、上で特定の組合せで説明されるが、各特徴または要素を、単独でまたは他の特徴および要素との任意の組合せで使用することができることを、当業者は了解するであろう。さらに、本明細書で説明される方法を、コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読媒体の例は、電子信号（有線または無線の接続を介して伝送される）およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびディジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、これらに限定されない。ソフトウェアに関連するプロセッサを使用して、ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、または任意のホストコンピュータ内で使用されるラジオ周波数トランシーバを実施することができる。

【0146】

適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つもしくは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意の他のタイプの集積回路（ＩＣ）、および／または状態機械を含む。

【0147】

ソフトウェアに関連するプロセッサを使用して、ＷＴＲＵ（無線送受信ユニット）、ＵＥ（ユーザ機器）、端末、基地局、無線ネットワーク制御装置（ＲＮＣ）、または任意のホストコンピュータ内で使用されるラジオ周波数トランシーバを実施することができる。ＷＴＲＵを、カメラ、ビデオカメラモジュール、ビデオ電話、スピーカホン、振動デバイス、スピーカ、マイクロホン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、液晶ディスプレイ（ＬＣＤ）表示ユニット、有機発光ダイオード（ＯＬＥＤ）表示ユニット、ディジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザ、および／または任意の無線ローカルエリアネットワーク（ＷＬＡＮ）モジュールもしくはＵＷＢ（ウルトラワイドバンド）モジュールなど、ハードウェアおよび／またはソフトウェアで実施されるモジュールに関連して使用することができる。

【図1】

【図1A】

【図2】

【図3A】

【図3B】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】