JP2010502109A - アプリケーションおよびインターネットベースのサービスに対する信頼されるシングル・サインオン・アクセスを提供するための方法および装置 - Google Patents

Abstract

ＴＣ（信頼されるコンピューティング）技術に基づくパスワード管理およびＳＳＯ（シングル・サインオン）アクセスのための方法および装置。この方法は、プロキシＳＳＯユニットとＷｅｂアクセス・アプリケーションとの両方と対話して、パスワードおよびＳＳＯ資格証明の生成、格納、および取り出しを行う、セキュアな信頼される機構をもたらす、ＴＣＧ（Trusted Computing Group）のＴＰＭ（信頼されるプラットフォームモジュール）を実装する。本発明の様々な実施形態は、ユーザーが、ユーザーのデバイス上に存在するセキュアなプロキシに１回だけサインオンした後、事前識別されたサイトグループに属する１つのサイトから別のサイトに、セキュアに、かつ透過的に飛ぶことを許す。

Description

本発明は、無線通信に関する。より具体的には、アプリケーションおよびインターネットベースのサービスに対する信頼されるＳＳＯ（Single Sign-On、シングル・サインオン）アクセス、および信頼されるＩＤ（識別）管理を提供するための方法および装置が、開示される。

ますます多くの無線通信デバイスに関して、サードパーティ・インターネット・コンテンツ・プロバイダーによって提供される独立したセキュアなＷｅｂサイトにログインするためのユーザーの認証プロセスを強化し、簡略化する必要性が、存在する。これらのＷｅｂサイトへのアクセスを得るのに、ユーザーは、サービスごとに一意のユーザーＩＤ、および一意のパスワードをセットアップすることを要求される。しかし、異なるパスワードポリシーの対象となる複数のユーザーＩＤ、および複数のパスワードを使用することは、面倒であり、セキュリティ侵害を被りやすい。したがって、無線通信デバイスユーザーに関するユーザー認証プロセスを簡略化しながら、パスワード管理のセキュリティレベルを強化するための方法が、大いに必要とされる。

サードパーティＷｅｂサービス・プロバイダーは、無線ネットワーク事業者を相手にした別個の契約を保持するため、アクセスネットワーク上のサードパーティ・サービスにユーザー認証プロセスを基づかせることは、それらのネットワークが、ＲＡＮ（Radio Access Network、無線アクセスネットワーク）などの無線ネットワークであれ、固定の、もしくは移動性の低い無線ネットワーク（例えば、ＩＥＥＥ ８０２．１６−タイプのネットワーク）であれ、固定の有線ネットワークであれ、実際的ではない。サービス・プロバイダーおよびユーザーは、しばしば、単一のＩＤを使用して、複数のＲＡＮ、複数の無線ネットワーク、または固定ネットワークを介してサービスにアクセスするため、ユーザーおよびサードパーティ・サービス・プロバイダーは、ネットワーク事業者が、ユーザー許可を与えることに対する制御を保つことができる、様々なネットワークにまたがってＳＳＯ運用を実装する可能性が高い。

１つのシナリオでは、無線ネットワーク事業者およびサードパーティＩＤサービス・プロバイダーは、一様なユーザーＩＤをユーザーに供給して、様々なタイプのネットワーク、事業者、およびサービス・プロバイダーにわたるシームレスなサービス継続性を円滑にすることが可能である。一様なユーザーＩＤは、異なるネットワークタイプおよびネットワークエンティティのサービス、ならびにサービス・プロバイダー境界にまたがる頻繁な、大量の変更からもたらされる過渡的な問題を解決する可能性がある。

パスワードまたは認証資格証明（authentication credential）のずさんな管理は、セキュリティに壊滅的な影響を与える可能性がある。攻撃者は、弱いパスワード、または盗んだパスワードを介してセンシティブなデータへのアクセスを得ることができる。また、ずさんなパスワード管理は、運用コストの増加につながる可能性もある。例えば、ヘルプデスク呼び出し件数（call volume）が、ユーザーの紛失した、または忘れてしまったパスワードを取り出す、または再設定する呼び出しを行うユーザーの数の増加とともに劇的に増加する可能性がある。

以下が、後段でより詳細に説明される、パスワード管理を向上させるための従来技術のソリューションである。すなわち、特定のパスワードポリシー、パスワードなしの認証、バイオメトリック因子、パスワード同期、資格証明マッピング、Ｅ−ＳＳＯ（エンタープライズ・シングル・サインオン）、Ｅ−ＳＳＯをパスワード同期と組み合わせること、Ｗｅｂ−ＳＳＯ（Ｗｅｂシングル・サインオン）、およびＳＡＭＬ（Security Assertion Mark−up Language）である。

ユーザーパスワードのセキュリティレベルを強化するため、組織は、特定のパスワードポリシーを実施することができる。一般的なパスワードポリシーは、ユーザーが、推測するのが難しいパスワードを設定する、またはパスワードを頻繁に変更することを要求することが可能である。また、パスワードポリシーは、ユーザーパスワード履歴を記録して、即時のパスワード再使用を防止する、またはロックアウトポリシーを実施して或る回数の試行の後にログインに失敗する人を誰であれロックアウトすることも可能である。良好なパスワードポリシーを実施することは、パスワードセキュリティを強化する可能性がある一方で、ユーザーが、憶えているのが容易で、管理しやすいパターン化されたパスワードを設定するのを助長する可能性もある。例えば、ユーザーが、パスワードポリシーの複雑度要件を満たすように、＠＃＄％９８７６などの、文字と数字の組み合わせを使用してパスワードを作成する可能性がある。しかし、ユーザーは、このパスワードを変更するようにシステムによって促されると、＠＃＄％８７６５または＠＃＄％７６５４など、古いパスワードの変種を使用して新たなパスワードを作成する可能性がある。パターン化されたパスワードの使用は、ユーザーのパスワード履歴の知識が旧パスワードの変種に対する侵入の試行の回数を大幅に絞るため、パスワードセキュリティレベルを弱める。複雑なパスワードは、憶えているのが困難であるため、厳密なパスワードポリシーは、ユーザーが、異なるサービスに関して同一のパスワードを使用することを生じさせる可能性がある。パスワードが、異なるサービスにまたがって共有されると、それらのサービスのいずれかにおいて漏洩した単一のパスワードが、その他のサービスのすべてにおけるパスワードの漏洩につながる。

パスワードなしの認証は、認証プロセスのセキュリティを向上させるのに使用される別の技術である。個人および組織が、スマートカードや認証トークンなどの、ユーザーＩＤおよびパスワードに依拠しない認証方法を採用している。スマートカードは、ユーザー認証目的でカード上に格納された複雑なパスワードをロック解除する組み込みパスワード、すなわち、ＰＩＮ（Personal Identification Number、個人識別番号）を使用する。このセットアップは、ユーザーがパスワードを入力する必要性を解消し、多因子認証、物理的なスマートカード、およびスマートカードの中に格納されたＰＩＮを使用して、ユーザーを認証する。しかし、スマートカードは、システムをセットアップすることの高い前払いの費用や、紛失したカード、盗まれたカード、またはそれ以外で侵害された（compromised）カードに関するヘルプデスクサポートを維持することの高い継続的費用などの欠点を有する。

また、バイオメトリック因子を使用して、ユーザーを認証することも普及してきている。一般的なバイオメトリック認証デバイスには、網膜スキャナ、指紋スキャナ、および手のひらスキャナが関わる。これらのデバイスは、ユーザーの物理的属性から導き出されたデータを用いてユーザーを認証する。これらのデバイスの欠点は、これらのデバイスを実装し、維持する費用がかさむことである。

パスワード同期（password synchronization）は、ユーザーが、複数のシステムにわたって単一のパスワードを使用することを許す技術である。パスワード同期において、パスワードは、パスワード再設定およびパスワード変更の両方に関して単一のセキュリティポリシーの対象となる。この技術において、パスワードの平文コピーが、１つのロケーションから抽出され、１つまたは複数の外部サービスロケーションに置かれる。これを達成するのに、展開プロジェクト（deployment project）の最初から、すべてのシステム上にすべてのユーザーに関するユーザープロファイルのコピーが、存在して、システムの寿命全体にわたって保持されなければならない。パスワード同期におけるパスワード変更は、一方向プッシュで、または双方向プッシュで行われることが可能である。一方向パスワードプッシュでは、中央システムにおけるパスワード変更がインターセプトされネットワーク内の他のロケーションにプッシュされる。双方向パスワードプッシュでは、パスワード変更は、任意のシステムにおいて行われることが可能であり、パスワードアーキテクチャ全体にわたって伝搬される。

一方向パスワードプッシュの主な問題は、パスワードを格納するシステムのセキュリティ測定内にある。同期されたパスワードがシステムにまたがって使用されるため、いずれのシステムにおけるセキュリティ侵害がすべてのシステムにおける破滅的なセキュリティ侵害をもたらす。双方向パスワード同期はより大きいユーザー・フレキシビリティを提供するが、パスワード変更の無限ループを生じさせることなどのさらなる問題を生じさせる可能性がある。システムは、そのシステムの残りの部分に新たなデータを伝搬させるようにプログラミングされるため、システムは、単一のパスワードに対する複数のパスワード変更を伝搬させるエンドレスのパスワード更新プロセスに陥る可能性がある。

したがって、パスワード同期は、ネットワーク内で複数のパスワードを憶えていて管理しなければならないことからユーザーを解放するものの、ユーザーが１つのパスワードを使用して複数のサービスにアクセスするのを許すことによって、パスワードセキュリティを弱めもする。

Ｅ−ＳＳＯと一般に呼ばれる資格証明マッピング（credential mapping）は、ユーザーに代行してユーザーＩＤおよびパスワードを格納し、取り出し、「タイプ入力」する技術である。Ｅ−ＳＳＯを実施するのに、Ｅ−ＳＳＯソフトウェアのコピーが、各ＷＴＲＵにインストールされなければならない。すべてのシステムおよびアプリケーションに関するユーザーＩＤおよびパスワードが、ローカルファイル、ネットワーク接続された（network-attached）データベース、またはユーザーディレクトリの中に格納される。初期セットアップの後で、ユーザーは、前に行っていたように、または新たなＥ−ＳＳＯソフトウェアインターフェースを介して、ユーザーのワークステーションにサインインすることができる。ユーザーが、ユーザーのワークステーションを使用してアプリケーションに接続することを要求する場合、Ｅ−ＳＳＯソフトウェアは、それらのアプリケーションのログインページのユーザーＩＤフィールドおよびパスワードフィールドに自動的にデータ投入（populate）する。

Ｅ−ＳＳＯシステムでは、ユーザーは、以下の場合、１つまたは２つのユーザー資格証明セット（例えば、ユーザーＩＤおよびパスワード）を使用して、ユーザーのワークステーションにサインインする。すなわち、（１）ユーザーが、Ｅ−ＳＳＯソフトウェアにログインするだけでよく、ユーザーのワークステーションにログインする必要がない場合、および（２）ユーザーが、両方にログインしなければならない場合である。

一部のＥ−ＳＳＯシステムは、ワークステーションにサインインし、スマートカード、認証トークン、またはバイオメトリックサンプルを含むユーザーの資格証明プロファイルにアクセスするために、パスワード以外の認証技術の使用をサポートする。さらに、一部のＥ−ＳＳＯ技術は、各ターゲット宛先に関して、パスワード管理を完全に制御するように構成される。このアプローチは、ユーザーが、いずれのターゲットシステムに関してもユーザーのパスワードを憶える必要性を解消する。Ｅ−ＳＳＯソフトウェアは、ユーザーに代行して、ユーザーのために自動的にサインインする。

Ｅ−ＳＳＯの下で、ユーザーは、ターゲットシステム上でパスワードを変更する必要もない。このソフトウェアが、パスワード変更要求を認識し、または予期し、それに相応して、ユーザーに代行してパスワードを変更する。資格証明マッピングパスワード管理フィーチャは、ターゲットシステムが、資格証明管理ソフトウェアだけを介してアクセスされる場合に、最もうまく機能する。

Ｅ−ＳＳＯシステムは、ユーザーパスワードを保護する機能を提供するが、システムは、セットアップするのに費用がかさみ、面倒であるという欠点を有する。Ｅ−ＳＳＯシステムを実装することは、各ユーザーに関してログインＩＤプロファイルを作成することだけでなく、各ユーザーおよび各ターゲットアプリケーションに関して現在のパスワードを格納することも要求する。Ｅ−ＳＳＯシステムをセットアップすることは、クライアントソフトウェアをインストールすること、ならびにユーザーＩＤおよびパスワードを格納するための資格証明データベースを展開することをさらに要求する。このデータベースは、専用ネットワークサービスを介して、または既存のディレクトリ（例えば、アクティブ・ディレクトリ、ＬＤＡＰ、ＮＤＳ）のスキームを拡張することによって、得られることが可能である。資格証明データベースは、このデータベース独自の、いくつかの要件を有する。このデータベースの目的を実行するのに、このデータベースは、このデータベースにおける障害により多数のユーザーがいずれのシステムにサインインすることを妨げられるので、高速であり、利用可能でなければならない。さらに、このデータベースはまた、このデータベースにおける侵害（compromise）が、すべてのシステムにおけるすべてのユーザー資格証明の侵害につながる可能性があるので、セキュリティで保護されていなければならない。

中央パスワード制御システムとして、Ｅ−ＳＳＯは、単一障害点（single point-of-failure）を生じさせる。ユーザーは、Ｅ−ＳＳＯシステムまたは資格証明データベースがダウンしている場合、いずれのシステムにもログインすることができない。さらに、Ｅ−ＳＳＯ技術は、複数のユーザーインターフェース（例えば、クライアント、Ｗｅｂ、電話機など）をサポートするアプリケーションを用いる認証プロセスをサポートしない。さらに、Ｅ−ＳＳＯは、Ｗｉｎｄｏｗｓ（登録商標）「スクリーン・スクレイピング（screen scraping）」技術に依拠するため、Ｅ−ＳＳＯシステムの展開および管理は、特に複数のタイプのワークステーションにまたがって、費用がかさむ可能性がある。したがって、Ｅ−ＳＳＯシステムは、セットアップし、登録するのが退屈で、時間がかかり、費用がかさむだけでなく、単一障害点を許しもする。

Ｅ−ＳＳＯをパスワード同期と組み合わせることは、Ｅ−ＳＳＯシステムを単独で実施することの欠点のいくつかに対処することができる。例えば、パスワード同期技術がない場合、ユーザーは、代替のユーザーインターフェースを使用して、ユーザーのＥ−ＳＳＯパスワードを使用してアプリケーションにログインすることができない。ユーザーは、ユーザー自身のパスワードを必ずしも知らないため、Ｍｉｃｒｏｓｏｆｔ（登録商標） Ｏｕｔｌｏｏｋ（登録商標）などの所有（proprietary）クライアントを通常使用するユーザーは、Ｗｅｂポータルを介して電子メールアカウントにアクセスすることができない可能性がある。パスワード同期をＥ−ＳＳＯと組み合わせることによって、ユーザーは、Ｗｅｂポータルなどの代替のインターフェースを介して、ユーザーの一次Ｅ−ＳＳＯパスワードを使用して、他のアプリケーションにログインすることができる。さらに、Ｅ−ＳＳＯシステムを展開するより前にパスワード同期システムを展開することが、各ユーザーに関するユーザーＩＤプロファイルを獲得する際の時間および労力を低減する。

Ｅ−ＳＳＯシステムにおいて、ユーザー資格証明は、通常、一次Ｅ−ＳＳＯパスワードから導き出されたキーを使用して暗号化される。この構成の下で、一次Ｅ−ＳＳＯパスワーを紛失することは、すべてのシステムにユーザー資格証明が失われることをもたらす。失われたＥ−ＳＳＯパスワードが再設定された後でさえ、資格証明は紛失したパスワードから導き出されたキーを使用して暗号化されているため、この暗号化された資格証明は、アクセス可能でない。つまり、ユーザーのＥ−ＳＳＯ一次パスワードを再設定することによって、ユーザーの資格証明が取り出されることはなく、ユーザーは、Ｅ−ＳＳＯシステムに再登録しなければならない。

この問題に対処するのに、Ｅ−ＳＳＯシステムは、Ｅ−ＳＳＯパスワードが再設定された後、ユーザー資格証明を回復する「バックドア」を提供しなければならない。パスワード再設定システムが、このバックドアシステムと一体化しなければならない、またはパスワード再設定システム独自のバックドアを提供しなければならない。ユーザーの一次Ｅ−ＳＳＯパスワードを再設定した後、パスワード再設定システムは、安全なストレージからユーザーの以前のパスワードを回復し、ユーザーの古い資格証明を解読し、このパスワードおよびこの資格証明を新たなパスワードおよびキーを使用して再暗号化して、Ｅ−ＳＳＯクライアントソフトウェアが再びアクセス可能であるようにしなければならない。

パスワード再設定、パスワード同期、およびＥ−ＳＳＯシステムを統合することにより、以上の問題が解決され、組織が、迅速な展開、自動化されたサインオン、およびセルフサービス問題解決の利益を享受することが可能になる。しかし、技術のこの組み合わせは、パスワードおよびログイン資格証明をセキュリティで保護するという問題に対処しない。さらに、クライアントソフトウェアもしくはサーバーソフトウェア、またはデータベースにおける侵害により、ユーザープロファイルが侵害される。最後に、この組み合わせは、パスワード同期およびＥ−ＳＳＯに携わっているシステムの「健康」状態を検証する方法を提供することが、依然としてできない。この検証なしで、ユーザーがシステムによって一度認証されると、ユーザーは、システムが侵害されている場合でさえ、システムにアクセスすることができる。

Ｗｅｂ−ＳＳＯは、Ｗｅｂブラウザを介してアクセスされるアプリケーションおよびリソースで機能する。Ｗｅｂ−ＳＳＯでは、Ｗｅｂリソースに対するアクセスは、Ｗｅｂプロキシサーバーによって、またはターゲットとされるＷｅｂサーバー上のコンポーネントによってインターセプトされ、Ｗｅｂリソースにアクセスしようと試みる認証されていないユーザーは、認証プロンプトに向かわされ、サインオンに成功して初めて、元のサイトにリダイレクトされる。ユーザーの認証状態を追跡するのにクッキーが最もよく使用され、Ｗｅｂ−ＳＳＯインフラストラクチャは、クッキーからユーザー識別情報を抽出して、この情報をＷｅｂリソースに送る。

スクリーン・スクレイピングおよびフェデレーションが、Ｗｅｂ−ＳＳＯにおいて使用される２つの最も重要な従来技術の技術である。一般的なタイプのスクリーン・スクレイピングは、Ｗｅｂスクレイピングである。Ｗｅｂスクレイピングは、ＨＴＭＬスクレイピングまたはページスクレイピングとも呼ばれ、コンピュータプログラムであるＷｅｂスクレーパが、Ｗｅｂページからデータを抽出する技法である。Ｗｅｂスクレイピングは、Ｅ−ＳＳＯにおいて、またはＷｅｂ−ＳＳＯにおいて使用されることが可能である。

スクリーン・スクレイピング技術は、Ｗｅｂページが、テキスト形態の情報をしばしば含むテキストベースのマークアップ言語（例えば、ＨＴＭＬ）を使用して構築されるため、有用である。これに対して、プログラム間のデータ交換は、通常、人間が直ちに理解することができないマシンのために設計されたデータ構造を使用して達せられる。同様に、ユーザーに向けられたデータ出力は、しばしば、マシン解釈に適していない。したがって、最初に、ＨＴＭＬおよび他のマークアップマシン言語からマシンフレンドリなデータを抽出し、次にこの抽出されたマシンフレンドリなデータをプログラム間で交換することによって、プログラム間でデータの転送を実現するために、スクリーン・スクレイピングが必要とされる。

スクリーン・スクレイピングを実行する際、コンピュータテキスト表示からデータを読み取ることは、一般に、端末装置の補助ポートを介して端末装置のメモリを読み取ること、または端末装置の出力ポートを別のシステムの入力ポートに接続することによって行われる。これらの事例では、スクリーン・スクレイピングは、Ｗｅｂページのコンピュータ化された解析（parsing）と呼ばれることも可能である。

スクリーン・スクレイピングは、以下を行うのに、最もよく行われる。すなわち、（１）現在のハードウェアと互換性のある代替の機構を提供することができないレガシーシステムとインターフェースをとる、または（２）それほど高性能でないＡＰＩ（アプリケーション・プログラミング・インターフェース）を提供するサードパーティシステムとインターフェースをとる。２）の事例では、サードパーティシステムは、より大きいシステム負荷、広告収入が失われること、または情報コンテンツの支配が失われることなどの理由で、スクリーン・スクレイピングを不要であると考える可能性がある。

図１は、Ｗｅｂ−ＳＳＯをＷｅｂスクレイピングと一緒に使用する従来技術のＷＴＲＵにおける例示的な手続きを示す。この図では、ＷＴＲＵはプロキシソフトウェアを備えており、ＷＴＲＵ上のＷｅｂアクセス・アプリケーションは、ＳＳＯプロキシソフトウェアと協調的に対話して、プロキシがＷｅｂサービスへのＳＳＯのための手続きを確立し制御することを許可するものと仮定する。例えば、ブラウザが或るＵＲＬにアクセスする要求を受信すると、ブラウザは、このＵＲＬをＳＳＯプロキシソフトウェアに送信して、その特定のＷｅｂサイトにアクセスするのにＷｅｂ−ＳＳＯが使用されることが可能であるかどうかを検証する。

フェデレーションは、標準ベースのプロトコルを使用して１つのアプリケーションがユーザーのＩＤを第２のエンティティにアサート（assert、表明）することを可能にして、冗長な認証の必要性を解消する、Ｗｅｂ−ＳＳＯに関して使用される第２のインポート技術である。フェデレーションをサポートする規格標準には、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ、ＩＤ−ＦＦ、ＯＡＳＩＳ、ＳＡＭＬ、およびインターネット２のために開発されているＳｈｉｂｂｏｌｅｔｈが含まれる。Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅは、ＩＤ−ＦＦ（IDentity Federation Framework、ＩＤフェデレーションフレームワーク）およびＩＤ−ＷＳＦ（IDentity Web Service Framework、ＩＤ Ｗｅｂサービスフレームワーク）のための規格を開発した中央組織である。Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅは、連携ＩＤ管理（federated identity management）およびＷｅｂサービス通信プロトコルを規定する規格を含む包括的な業界コンソーシアム開発スイートのセットを提供する。これらのプロトコルは、企業内展開と企業間展開の両方のために設計される。ＯＡＳＩＳは、電子商取引のためのソリューションを開発する非営利組織である。現在、バージョン２．０であるＳＡＭＬは、ＳＳＯ認証を可能にするユーザーＩＤ情報を含むセキュリティアサーションのためのマークアップ言語である。Ｓｈｉｂｂｏｌｅｔｈは、連携ＩＤおよびＳＡＭＬに基づいて認証−許可インフラストラクチャのためのアーキテクチャおよびオープンソース実装を作成したインターネット２ミドルウェア・イニシアティブ（ＮＭＩ）プロジェクトである。

図２は、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ ＩＤ−ＦＦを使用するＷＴＲＵユーザーによるＷｅｂ−ＳＳＯのための手続きを示す。Ｗｅｂ−ＳＳＯのコンテキストにおいて、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅは、ユーザーが、或る単一のアカウントにログインし、ネットワークにおけるＩＤ管理エンティティによって管理される「信頼サークル」内のいくつかのサービス・プロバイダーからのサービスを要求することを可能にする。Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅの独特なフィーチャが、「フェデレーション」プロセスである。再認証を受けることなしにＳＰ（サービス・プロバイダー）にアクセスするために各ユーザーがどのような種類の権利を有するかを決定する代わりに、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅは、ユーザーが再認証なしにＳＰにアクセスすることを所望するかどうかを、ユーザーが決定することを許す。この権利を得るために、ユーザーはまず、ＳＰによって認識されるＩＤＰ（ＩＤプロバイダー）によって認証されなければならない。このことは、Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅを、ユーザーが通常個人データの管理を企業に委ねる、拡張された企業アプリケーションのコンテキストにおけるＩＤ管理のための実用的なフレームワークにする。

ＳＡＭＬは、セキュリティドメイン間で、つまり、ＩＤＰとＳＰの間で、認証データおよび許可データを交換するためにＯＡＳＩＳ組織によって作成されたＸＭＬ標準である。図３は、ＳＡＭＬコンポーネント間の関係を示す。ＳＡＭＬは、ネットワークエンティティ間で認証手続きおよびセキュリティアサーション情報（security assertion information）のシームレスで、確実な交換を円滑にすることによって、Ｗｅｂ−ＳＳＯ問題を解決しようと試みる。ＳＡＭＬ標準は、以下のコンポーネントを利用する。すなわち、（１）アサーションコンポーネント、（２）プロトコルコンポーネント、（３）結合コンポーネント（biding component）、および（４）プロファイルコンポーネントである。アサーションコンポーネントは、１つのエンティティが、ユーザー名、ステータス、電子メールアドレス、グループにおけるメンバシップなどの、別のエンティティの特性および属性をアサートすることを可能にする。プロトコルコンポーネントは、ＸＭＬスキーマにおいて符号化され、要求−応答関連プロトコルのリストを定義する。

結合コンポーネントは、ＳＡＭＬプロトコルメッセージが、ＳＯＡＰメッセージ内でどのようにトランスポートされるか、およびＳＯＡＰメッセージが、ＨＴＴＰを介して、どのようにトランスポートされるかを定義する。ＳＯＡＰメッセージは、Ｗ３Ｃ組織ＳＯＡＰバージョン１．２のエンベロープ規則および符号化規則に準拠して構築される、適格な（well-formed）ＸＭＬメッセージである。図４は、通常の結合ケースにおけるＳＡＭＬコンポーネント間の交換の例を示す。プロファイルコンポーネントは、ＳＡＭＬ規格の中核であり、つまり、プロファイルコンポーネントは、ＳＡＭＬ要求およびＳＡＭＬ応答が、どのようにトランスポートされるかを定義する。

Ｌｉｂｅｒｔｙ ＩＤ−ＦＦとＳＡＭＬはともに、パスワードセキュリティレベルを強化することに重要な役割を果たすものの、いずれも、ユーザーのデバイス内、またはＩＤＰ上およびＳＰ上でＷｅｂ−ＳＳＯに必要な、センシティブな情報をどのようにセキュリティで保護するかには対処しない。さらに、Ｌｉｂｅｒｔｙ ＩＤ−ＦＦとＳＡＭＬはともに、最終的には、ユーザー認証プロセスの制御をＩＤＰおよびＳＰに明け渡し、その結果、ユーザー個人情報の開示が要求されるため、ユーザープロファイルが、このプロセスにおいて侵害される可能性がある。

信頼されるコンピューティング技術が、概ねＴＣＧ（Trusted Computing Group）の技術的な傘下で、文献および製品において出現している。信頼されるコンピューティングは、暗号機能および保護されたストレージを提供する専用の、物理的に隔離されたハードウェアモジュールの物理的セキュリティに基づく。

ＴＣＧは、コンピューティングエンティティが、システムの完全性をアサートし、適切な信頼レベルが確立されると認証プロセスを検証し、他のデバイスを相手にした情報の交換、および処理についての評価および決定を、そのようなターゲットデバイスの明らかになった信頼レベルに基づいて実行する方法を提供する、様々な技術を開発している。

ＴＣＧは、ＴＰＭ（信頼されるプラットフォームモジュール）と呼ばれるコア・プラットフォーム・モジュールを規定する。図５は、ＴＰＭモジュールおよびＴＰＭモジュールのインターフェースの物理的保護を提供するＴＰＭの構成を示す。また、このモジュールは、揮発性メモリ空間および不揮発性メモリ空間に関する保護、ならびに暗号化およびデジタル署名を実行するための暗号機能を提供する。ＴＰＭは、ＰＣＲ（Platform Configuration Register、プラットフォーム構成レジスター）を使用して、ＨＡＳＨ拡張と、ＰＫＩ（Public Key Infrastructure、公開キー・インフラストラクチャ）に基づくユーザーデバイス固有のセキュアなＥＫ（Endorsement Key、保証キー）と、によって、プラットフォームおよびプラットフォームのソフトウェアコンポーネントの「状態」をキャプチャする。ＥＫは、決して外部に開示されないが、ＥＫのエイリアスであるＡＩＫ（Attestation Identity Key、立証ＩＤキー）を使用して、プラットフォームの完全性値が検証される。さらに、ＴＰＭは、ＡＩＫによって署名されたＰＣＲ値に関連してデータをメモリの中に「封印（seal）」して、その結果、ＴＭＰから、および封印されたメモリからの合致するＰＣＲ値によって検証され、測定される、プラットフォーム完全性またはソフトウェア完全性が検証された場合に限って、データにアクセスが行われる、またはデータが抽出されることが可能であるようにするプロセスを使用する。

図６は、外部エンティティ（チャレンジャ（challenger）またはベリファイア（verifier））が、ＴＰＭ、ＡＩＫ、およびＰＣＡ（Private Certification Authority、プライベート証明権限）を使用して、プラットフォーム立証(attestation)を求める要求をどのように行うことができるかを示す。そのような立証機構は、ＳＳＯ技術の信頼態様およびセキュリティ態様を改良するために役立つ可能性がある。

また、ＴＣＧは、ＴＰＭを含むコンピューティング・プラットフォームが使用するための詳細なＴＳＳ（TPM Software Stack、ＴＰＭソフトウェア・スタック）も規定している。各ＴＳＳモジュールは、特化された機能を提供するコンポーネントを含む。これらのコンポーネントの主要な設計目標は、ＴＰＭへの単一の同期された入口点を供給して、アプリケーションから適切なバイト順序および整列を有する構築コマンドストリームを隠すこと、およびＴＰＭリソースを管理することである。

図７は、ＴＰＭ層およびＴＳＳ層のアーキテクチャを示す。ＴＳＳモジュールは、以下の構成要素を含む。すなわち、（１）標準化されたＴＤＤＬ（TPM Device Driver Library、ＴＰＭデバイス・ドライバ・ライブラリ）とインターフェースをとるＴＤＤＬＩ（ＴＳＳデバイス・ドライバ・ライブラリ・インターフェース）、（２）ＴＰＭのＴＣＳコマンド（図示せず）とインターフェースをとるＴＣＳＩ（TSS Core Service Interface、ＴＳＳコア・サービス・インターフェース）、および（３）ＴＣＧのＴＳＰコマンド（図示せず）とインターフェースをとり、アプリケーションのすぐ下に位置するＴＳＰＩ（TGG Service Provider Interface、ＴＣＧサービス・プロバイダー・インターフェース）である。ＴＰＭ側で、ＴＤＤＬは、ＴＰＭと通信しているベンダ固有のＴＰＭデバイス・ドライバの上に位置する。

ＴＤＤＬＩは、ＴＳＳの様々な実装が、任意のＴＰＭと適切に通信し、ＴＰＭアプリケーションに関するＯＳ独立のインターフェースを提供し、ＴＰＭベンダが、ユーザー・モード・コンポーネントとしてソフトウェアＴＰＭシミュレータを提供できるようにすることを可能にする。ＴＤＤＬは、プラットフォーム上でユーザーモードとカーネルモードとの間の遷移を提供する。ＴＣＳ（ＴＣＧコア・サービス）が、一般的なプラットフォームサービスセットに対するインターフェースを提供する。ＴＣＳは、以下の４つのコアサービスを提供する。すなわち、（１）ＴＰＭに対するスレッド化された（threaded）アクセスを実施するコンテキスト管理、（２）プラットフォームに関連する資格証明およびキーを格納する資格証明−キー管理、（３）イベント・ログ・エントリを管理し、関連するＰＣＲにアクセスする測定イベント管理、および（４）ＴＰＭコマンドをシリアル化し、同期し、処理するためのパラメータ・ブロック生成である。

ＴＳＰ（TCG Service Provider、ＴＣＧサービス・プロバイダー）は、オブジェクト指向アーキテクチャに基づく、ＴＰＭに対するＣインターフェースである。ＴＳＰは、アプリケーションと同一のプロセス・アドレス・ロケーション内に存在する。許可は、この層において、この層に符号化されたユーザーインターフェースを使用することを介して、またはＴＣＳ層におけるコールバック機構を介して行われる。エンドユーザーに標準化された許可インターフェースを提供するために、認証サービスは、ローカルアプリケーションによってではなく、プラットフォームによって提供される。

ＴＰＳは、以下の２つのサービスを提供する。すなわち、（１）コンテキスト管理、および（２）暗号化である。コンテキストマネージャは、アプリケーションリソースおよびＴＳＰリソースの効率的な使用を可能にする動的ハンドルを提供する。各ハンドルは、互いに関係するＴＣＧ動作のセットに関するコンテキストを提供する。アプリケーション内の異なるスレッドは、同一のコンテキストを共有することも、別々のコンテキストを獲得することも可能である。

米国特許出願第１１／７４５６９７号明細書

ＴＰＭ保護された機能を完全に利用するのに、暗号機能をサポートすることが提供されなければならない。ＴＳＰは、ＴＰＭ規格によって要求される動作を実行するのに必要なサポート以外、このサポートを提供しない。特に、大量データ暗号化は、このインターフェースによって開示されない。ＴＰＭによって規定される暗号化機能の例には、メッセージダイジェスト化、および少量（１０２４バイト未満）のデータの暗号化が含まれる。

信頼されるコンピューティング技術に基づくパスワード管理およびＳＳＯアクセスのための方法および装置を開示する。この方法は、プロキシＳＳＯユニットおよびＷｅｂアクセス・アプリケーションの両方と対話して、パスワードおよびＳＳＯ資格証明の生成、格納、および取り出しを行うセキュアな信頼される機構をもたらす、ＴＣＧのＴＰＭを実施する。それらの様々な実施形態は、ユーザーが、ユーザーのデバイス上に存在するセキュアなプロキシに１回だけサインオンした後、事前識別されたサイトグループに属する１つのサイトから別のサイトに、セキュアに、透過的に飛ぶこと（hop）を許す。

ユーザーが、移動デバイスにサインオンした後、このデバイス上に存在するプロキシＳＳＯユニットが、登録されたグループに属するセキュアなサイトにアクセスしようと試みるアプリケーションをインターセプトし、ＴＰＭによって生成され、保護されて保持されているサイト毎のセキュアなパスワードを使用して、そのグループ内の個々のサイトにサインオンする。また、ハードウェアまたはソフトウェアで実装されることが可能なプロキシＳＳＯユニットは、ＴＰＭによってユニットの完全性に関して保護もされる。このことにより、ユーザーが別々に憶えている、または格納している必要がない、ＴＰＭによって生成されたランダム化されたパスワードを介して、様々なサイトに対してＳＳＯを使用するプロセスに関する高いレベルの信頼がもたらされる。

ＳＳＯフィーチャは、任意の数のセキュアなサイトに適用されることが可能であり、リストは、ユーザーが、インターネットを検索（ナビゲート）し、新たなＷｅｂサーバーにアクセスするにつれ、増大することが可能である。各Ｗｅｂサーバーには、セキュアなサインオン証明書が関連付けられており、この証明書は、或るＷｅｂサーバーへの初期登録からその後のログオンセッションおよび認証セッションまで、ＳＳＯ手続きの自律的動作を可能にするＴＣＧによって生成されたユーザー資格証明に関連付けられている。オプションとして、ユーザーは、ＳＳＯＷｅｂアクセスが可能にされるＷｅｂサイトのグループのプロキシソフトウェアによって、プロンプトが提供されることが可能である。ユーザーは、プロキシソフトウェアによって示されるＷｅｂサイトのグループ、またはサブセットへのＳＳＯ動作を許すかどうかを選択することができる。

さらなる実施形態は、Ｅ−ＳＳＯのＴＰＭ拡張、および連携ＩＤ管理を有するＷｅｂ−ＳＳＯに関する機構を含む。

本発明の、より詳細な理解は、例として与えられ、添付の図面と併せて理解されるべき、好ましい実施形態の以下の説明から得ることができる。

従来技術によるＷＴＲＵのためのＷｅｂ−ＳＳＯに関する例示的な流れ図である。 従来技術によるＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ ＩＤ−ＦＦを装備したＷＴＲＵのＷｅｂ−ＳＳＯプロセスに関する例示的な流れ図である。 ＳＡＭＬコンポーネント間の関係を示すブロック図である。 ＳＳＯにおけるＳＰによって開始されたポスト−ポスト結合（SP-initiated post-post binding）の例を示す図である。 汎用ＴＰＭを示すブロック図である。 ＴＰＭ ＡＩＫを使用する、外部パーティによるＡＩＫ資格証明検証のための例示的なプロセスを示す図である。 ＴＰＭ内、およびＴＳＳ内の様々な層を示すブロック図である。 無線通信システムを示す例示的なブロック図である。 ＴＰＭ／ＴＳＳを使用するセキュアな自動化されたサインオンの実施形態の例示的な流れ図である。 ＴＰＭ／ＴＳＳ、およびデバイスによって信頼されるミラー（device trusted mirror）を使用するセキュアな自動化されたサインオンの実施形態の別の例示的な流れ図である。 ＴＰＭを使用する、グループに関するパスワード（group-wise password）に基づく、ＴＰＭ／ＴＳＳを使用するＷｅｂアクセスのためのＳＳＯの実施形態の例示的な流れ図である。 Ｌｉｂｅｒｔｙ−Ａｌｌｉａｎｃｅ ＩＤ−ＦＦを使用する無線通信システムの例示的なブロック図である。 Ｌｉｂｅｒｔｙ−Ａｌｌｉａｎｃｅ ＩＤ−ＦＦを使用するＴＰＭ／ＴＳＳによって保護されたＷｅｂ−ＳＳＯの実施形態の例示的な流れ図である。

以降、言及される場合、「ＷＴＲＵ（無線送受信ユニット）」という用語には、ＵＥ（ユーザー機器）、移動局、固定加入者ユニットもしくは移動加入者ユニット、ポケットベル、セルラー電話機、ＰＤＡ（パーソナル・デジタル・アシスタント）、コンピュータ、または無線環境もしくは無線／有線複合環境において動作することができる他の任意のタイプのユーザーデバイスが含まれるが、以上には限定されない。以降、言及される場合、「基地局」という用語には、ノードＢ、サイトコントローラ、ＡＰ（アクセスポイント）、または無線環境において動作することができる他の任意のタイプのインターフェースデバイスが含まれるが、以上には限定されない。

図８は、少なくとも１つのＷＴＲＵ８０５と、ＲＡＮ（無線アクセスネットワーク）８０７とを含む無線通信システム８００の例示的なブロック図である。ＷＴＲＵ８０５は、ユーザー８０９と対話し、ＳＡＳＯ（Single Automatic Sign-On、シングル自動サインオン）プロキシユニット８１０、ＴＰＭ／ＴＳＳ ８１５、ＷＡＡ（Web Access Application、Ｗｅｂアクセス・アプリケーション）８２０を含む。ＴＰＭ／ＴＳＳ ８１５は、ＳＡＳＯプロキシユニット８１０およびＷＡＡ８２０の両方と対話して、パスワードおよびＳＳＯ資格証明の生成、格納、および取り出しを行うセキュアな信頼される機構を提供する。ＳＡＳＯプロキシユニット８１０は、ＴＰＭ／ＴＳＳ ８１５によってユニット８１０の完全性に関して保護され、様々なＷｅｂサイトに関してＳＳＯを使用しながら、高いレベルの信頼を可能にする。ＴＰＭ／ＴＳＳ ８１５は、ユーザーが、別々に憶えている必要がないランダム化されたパスワードを格納し、生成することによって、この高いレベルの信頼をもたらす。ＲＡＮ８０７は、通常、少なくとも１つのＷｅｂサイト８３０ａ〜ｃへのアクセスを含む。オプションとして、ＲＡＮ８０７は、ＤＴＭ（Device Trusted Mirror、デバイスによって信頼されるミラー）８３５を含むことも可能である。

ユーザー８０９が憶えていなければならないパスワードの数を最小限に抑えるため、機構が提供され、これにより、ユーザー８０９がまず、サイトまたはアプリケーションのリストを作成し、次に、ＳＡＳＯプロキシユニット８１０が、ユニット８１０自体のログ上と、ストレージキー結合を使用して、または内部ストレージを用いてＴＰＭ／ＴＳＳ ８１５によって後にセキュリティで保護されて保たれるログ上と、の両方に、情報を記録する。ＳＡＳＯプロキシユニット８１０は、協調的結合（cooperative binding）、またはＷｅｂスクレイピングなどのインターセプト技術を使用して、アプリケーションまたはＷｅｂサイト８３０へのアクセスを求めるユーザーの要求と、アプリケーションまたはＷｅｂサイト８３０からのログインおよび／またはパスワードタイプ入力を促すプロンプトとの両方をインターセプトする。

ユーザー８０９の資格証明（ルートＩＤとも呼ばれる）は、ＴＰＭ／ＴＳＳ ８１５自体の中に、またはＵＳＩＭなどの別のセキュアな記憶装置の中にセキュアに格納されることが可能である。さらに、キー階層が、このルートＩＤから作成されることが可能である。ルートＩＤは、デバイス内部にセキュアに保持され、セキュアなドメイン、または信頼されるドメインの外部に決して明かされない。

ユーザー８０９が、セキュアなＷｅｂサイト８３０に初めてサインオンすると、ＷＡＡ８２０が、ＳＡＳＯプロキシユニット８１０およびＴＰＭ／ＴＳＳ ８１５と対話して、高いエントロピー、一意なユーザーＩＤ、およびＷｅｂサイト８３０に関する証明書情報に関連する高エントロピーパスワードを作成する。以降、ユーザー８０９が、Ｗｅｂサイト８３０にアクセスすることを所望するといつでも、ユーザーの資格証明が、ＷＡＡ８２０、ＳＡＳＯプロキシユニット８１０、およびＴＰＭ／ＴＳＳ ８１５の間の対話を介して、通信リンクを介して送信される情報に自動的に入力される。

オプションとして、ユーザー８０９がＲＡＮ８０７にアクセスするといつでも、ＷＴＲＵ８０５が、ＳＡＳＯプロキシユニット８１０およびＴＰＭ／ＴＳＳ ８１５を同一の仕方で使用して、ＳＰ（サービス・プロバイダー）またはＩＤＰ（ＩＤプロバイダー）（図示せず）などのＲＡＮ８０７における妥当なネットワーク要素を相手に信頼関係を確立する。あるいは、ＲＡＮ８０７は、ＤＴＭ８３５などの、特別なシステムコンポーネント、または信頼されるサードパーティエンティティに対する関係を保持する。ひとたびＷＴＲＵ８０５が、ＲＡＮ８０７に対して確立された信頼関係、およびセキュアなリンクを得ると、ＤＴＭ８３５が、移動体の信頼サービスのためのプロキシ、およびセキュアな各Ｗｅｂサイトに関して作成されたパスワードに関するデータベースの役割をする。

ユーザー８０９は、ＷＴＲＵロック機構にアクセスする単一のログインＩＤおよびパスワードを使用することによって、ＷＴＲＵ８０５機能へのアクセスを得て、そのため、インターネットへのアクセスを得ることが可能である。ひとたびログインすると、他のすべてのサービスは、ＷＴＲＵ８０５によって透過的に扱われる。さらに、キーフォブ（key fob）、スマートカード、および／またはバイオメトリックを使用して、電話フィーチャにアクセスするセキュアな２つ、または３つの因子の認証が提供されることが可能である。オプションとして、認証資格証明は、認証のため、およびデバイスへのユーザーアクセスを可能にするように、ＲＡＮ８０７に送信されることが可能である。

ＴＰＭ／ＴＳＳ ８１５は、物理的に保護された境界を提供することによって、ＴＰＭ／ＴＳＳ ８１５が暗号によって保護し、格納するパスワードを含むデータに関して本来的なセキュリティを提供する。しかし、データ保護の強度は、そのようなデータを保護するのに使用されるパスワードまたは暗号キーの場合、データ自体の強度および新しさにも或る程度依存する。強固に保護されたデータでさえ、暗号化されたデータの十分なサンプル、十分な計算能力、および攻撃者の意のままになる計算時間が与えられると、破られる可能性がある。したがって、キーを更新し、必要な場合、新たなキーでデータを再暗号化することが、暗号化されたＩＤおよび認証データを解読しようとする盗聴者の試みに対するさらなるセキュリティ障壁をもたらすことが可能である。ユニバーサル認証のために使用されるキーおよびパスワードは、ＴＰＭ／ＴＳＳ ８１５によって頻繁に更新されなければならない。そのような更新は、データ更新および／またはキー更新と関係する必要な手続きを開始し、確認し、実行するプロトコルを要求する。

代替の実施形態では、ＷＴＲＵ８０５は、ＷＴＲＵ８０５の内部に、ＵＳＩＭ（Universal Subscriber Identity Module、汎用加入者ＩＤモジュール）（図示せず）を有する。ＵＳＩＭは、隔離され、保護されたエンティティとして、ソフトウェアに関する第２のセキュアな実行環境を提供するとともに、パスワードなどのデータに関するセキュアな格納場所を提供する。したがって、ＳＡＳＯプロキシユニット８１０は、ＵＳＩＭ内に存在することが可能である。また、ＷＡＡ８２０もＵＳＩＭ内に存在することが可能である。

ＷＴＲＵ８０５の別の代替の実施形態では、ＵＳＩＭは、唯一の「セキュアな」実行環境として、ＴＰＭ／ＴＳＳ ８１５に取って代わることが可能である。この場合、ＷＴＲＵ８１５は、ＴＰＭ／ＴＳＳ ８１５によって通常提供されるプラットフォームおよび／またはアプリケーションの完全性の測定、検証、および立証を実行する機能を有さない可能性がある。しかし、ＵＳＩＭは、隔離され、保護され、セキュアな実行環境であるので、ＳＡＳＯプロキシユニット８１０のセキュアな実行、および、場合により、ＷＡＡ８２０のセキュアな実行さえ可能にする。また、ＵＳＩＭは、高エントロピーのサイト固有のパスワードを生成し、格納するように、さらに、ＳＳＯパスワードおよびＳＳＯ資格証明を格納するようにも構成されることも可能である。

ＷＴＲＵ８０５のさらに別の代替の実施形態では、２００７年５月８日に出願され、本明細書に完全に記載されているかのように参照により本明細書に組み込まれている特許文献１において開示される、「拡張された」ＵＳＩＭが、ＷＴＲＵ８０５内部に存在し、ＳＡＳＯプロキシ８１０、ＷＡＡ８２０、およびＴＰＭ／ＴＳＳ ８１５に関するセキュアな実行環境を提供する。

図９は、代替の実施形態による図８のシステム８００のコンポーネント間のシグナリングを示す。具体的には、図９は、ＴＰＭ／ＴＳＳ ８１５を使用するＷｅｂアクセスのためのＳＡＳＯに関する例示的な手続きを示す。

この手続きは、ユーザー８０９が、ステップ１００５で、セキュアな１つの因子の認証、または、好ましくは、２つもしくは３つの因子の認証を介して、ＷＴＲＵ８０５へのアクセスを得ると、開始される。これらの認証因子は、ＳＡＳＯプロキシユニット８１０が、ＴＰＭ／ＴＳＳ ８１５内部に保持されるセキュアな情報にアクセスすることを許す機構である。バイオメトリックの第２の因子もしくは第３の因子の認証が使用される場合、ＳＡＳＯプロキシユニット８１０は、ステップ９１０で、認証のためのバイオメトリック認証データを取り出す要求をＴＰＭ／ＴＳＳ ８１５に送信する。ＴＰＭ８１０は、ステップ９１５で、このバイオメトリック認証データをＳＡＳＯプロキシユニット８１０に供給する。次に、ユーザー８０９が、ステップ９２０で、セキュアなＷｅｂサイトに登録する要求をＷＡＡ８２０に送信する。

ＷＡＡ８２０が、ステップ９２５で、ＷｅｂサイトＡ８３０ａに、ＷｅｂサイトＡ８３０ａにアクセスしたいというユーザー８０９の要望を伝える。ＷＡＡ８２０は、ステップ９３０で、ＷｅｂサイトＡ８３０ａのログイン・プロンプトを受信して、表示する、または別の仕方で示す。ＳＡＳＯプロキシユニット８１０が、ステップ９３５で、Ｗｅｂスクレイピングによって、またはＡＰＩもしくは他の解析技術を介する協調によって、ＷＡＡ８２０からＷｅｂサイトＡ８３０ａの認証プロンプトをインターセプトする。ＳＡＳＯプロキシユニット８１０が、ステップ９４０で、ユーザーＩＤ情報（この情報は、多因子認証からのデバイスログイン情報であることも可能である）をＴＰＭ／ＴＳＳ ８１５に送る。Ｗｅｂサイト固有のセキュアなパスワードが、ステップ９４５で、ＴＰＭ／ＴＳＳ ８１５によって生成されて、セキュアに格納される（ＴＰＭ ＮＶメモリの中に直接に、または通常のメモリの中に。ただし、ＴＰＭによって保護された結合ストレージキーによって暗号化されて。）。次に、ＳＡＳＯプロキシユニット８１０が、ステップ９５０で、ＷＡＡ８２０をインターセプトし、スクレイピング、またはＡＰＩもしくは他の解析技術の使用などの方法によって、ＷｅｂサイトＡ８３０ａに関するＷＡＡ８２０パスワード・プロンプト時に、Ｗｅｂサイト固有のセキュアなパスワードを記入する。ＷＡＡ８２０が、ステップ９５５で、このＷｅｂサイト固有のパスワードをＷｅｂサイトＡ８３０ａに伝える。ＷｅｂサイトＡ８３０ａが、ステップ９６０で、このＷｅｂサイト固有のパスワードを登録し、ＷＡＡ８２０にアクセス許可を送信する。登録が確立されると、ＵＲＬ、デジタル証明書、ユーザーＩＤ、およびパスワードなどのＷｅｂサイト情報が、ＴＰＭ／ＴＳＳ ８１５の中のデータベースレコード、およびＴＰＭ／ＴＳＳ ８１５結合ストレージキーによって保護されたデータブラブとして一緒にセキュアに格納される。このＷｅｂサイト固有のパスワードは、それぞれのサイトへの後のログインのために、ＳＡＳＯプロキシユニット８１０によって再使用されることが可能である。ＷｅｂサイトＡ８３０ａが、ＷＡＡ８２０にアクセスを許可した後、ＷＡＡが、ステップ９６５で、登録ＯＫ−アクセス許可メッセージをＳＡＳＯプロキシユニット８１０に送信する。ステップ９７０で、通常のＷｅｂベースの通信が、後に続くことが可能である。

図９のステップ９０５ないし９６５は、或るＷｅｂサイトにおける、ＷＴＲＵ８０５によって管理される、ユーザーのサイト固有のパスワードの初期登録に関して示されることに留意されたい。そのような初期登録の後、ユーザー８０９は、ＷＡＡ８２０を使用して、ＷｅｂサイトＡ８３０ａへのアクセスを要求することができる（ステップ９２０の場合と同様に）。次に、ＳＡＳＯプロキシユニット８１０が、ＷＡＡ８２０からのログイン・プロンプトをインターセプトして（ステップ９３５の場合と同様に）、ＴＰＭ／ＴＳＳ ８１５において格納されたサイト固有のパスワードを獲得し（ステップ９４５の場合と同様に）、スクレイピング、ＡＰＩ、または解析によって、ＷＡＡ８２０上でＷｅｂサイトＡ８３０ａに固有のログイン情報を記入する（ステップ９５０の場合と同様に）。次に、ＷＡＡ８２０が、サイト固有のログイン情報をＷｅｂサイトＡ８３０ａに送信し（ステップ９５５の場合と同様に）、ＷｅｂサイトＡ８３０ａが、供給されたこのサイト固有のログイン情報を検証した後、要求されたサービスに関するアクセスをＷＡＡ８２０に許可し（ステップ９６０の場合と同様に）、ＳＡＳＯプロキシユニット８１０が、ＷＡＡ８２０からこのアクセス許可メッセージを取得し、次に、サービスが許可されたことをユーザー８０９に知らせることができる。通常のＷｅｂベースの通信が、その後に続くことが可能である（ステップ９７０の場合と同様に）。

同様の手続きセットが、ＴＰＭ８２０内にパスワードが保持されている、既に確立されたＷｅｂサイトにアクセスする際に実行される。例えば、９０５ないし９７０におけるステップが、ステップ９７５で、ＳＡＳＯプロキシユニット８１０によって、他のサイト、例えば、ＷｅｂサイトＢ８３０ｂなどの異なるＷｅｂサイトに対して繰り返されることが可能である。ＴＰＭ／ＴＳＳ ８１５によって可能にされる符号完全性検証手続き（code integrity verification procedure）を使用して、ＳＡＳＯプロキシユニット８１０および他のソフトウェアコンポーネントの完全性が保護されて、セキュアなトランザクションが行われることが確実にされる。例えば、パスワード更新手続きを管理するポリシーまたはプロファイルが確立された場合、ＴＰＭ／ＴＳＳ ８１５は、ポリシー情報およびプロファイル情報を、ＴＰＭ結合ストレージキーによって保護されるメモリの中に格納することによって保護することも行う。ユーザー８０９が、非Ｗｅｂのサードパーティ・サービスまたはセキュアなサーバーにアクセスしようと試みた場合、ＤＴＭ８３５によって管理されることが可能な信頼ミラーリング手続きを使用することによって、前述した手続きと非常に似通った手続きが、使用される。

図１０は、別の実施形態による図８に示されるコンポーネント間のシグナリングを示す。具体的には、図１０は、ＷＴＲＵ８０５におけるユーザー認証情報の登録のために、次いで、ＤＴＭ８３５におけるユーザー認証情報の登録のために、ＴＰＭ／ＴＳＳ ８１５およびＤＴＭ８３５を使用するＷｅｂアクセスのためのＳＡＳＯに関する例示的な手続き１０００を示す。通常、ＲＡＮ８０７内に存在するが、ＲＡＮの外部に配置されることも可能なＤＴＭ８３５が、ＷＴＲＵ８０５の信頼できるサービスを「ミラーリング」するサービスを提供し、このことを、そのような情報の外部の要求者に立証することができる。例えば、ＤＴＭ８３５は、図９におけるＴＰＭ／ＴＳＳ ８１５に関して説明されるＩＤ情報を管理するタスクを引き受けることが可能である。

ユーザー８０９が、ステップ１００５で、ユーザーの認証情報をＳＡＳＯプロキシユニット８１０に登録することによって手続き１０００を開始する。そのような登録は、セキュアな１因子、または好ましくは２因子の認証を使用することによって行われることが可能である。さらに、第３の因子は、ＴＰＭ／ＴＳＳ ８１５によってセキュアに保持されるバイオメトリック情報を介することが可能である。また、ステップ１００５でまたは別個のステップで、ユーザー８０９が、オプションとして、所望されるサービスのリストを提供することも可能である。

次に、ＳＡＳＯプロキシユニット８１０が、ステップ１０１０で、認証データおよび所望されるサービスのリストをＴＰＭ／ＴＳＳ ８１５に送信する。ＴＰＭ／ＴＳＳ ８１５は、ステップ１０１５で、認証データおよび所望されるサービスのリストを、ＳＡＳＯプロキシユニット８１０およびＷＡＡ８２０の完全性に封印する。ＳＡＳＯプロキシユニット８１０は、ステップ１０２０で、ＷＴＲＵ８０５に関する完全性情報（または、同等なこととして、立証情報）を、認証データ、ならびにアプリケーションおよび所望されるサービスのリストと一緒に、ＤＴＭ８３５に送信する。

ＤＴＭ８３５は、ステップ１０２５で、ユーザーの認証資格証明をＷｅｂサイトＡ８３０ａに登録する。このプロセス中、ＤＴＭ８３５とＷｅｂサイトＡ８３０ａは、ユーザー８０９およびＷＴＲＵ８０５のために、ＷｅｂサイトＡ８３０ａからサービスを獲得するのに特に使用されるパスワードを相互に確立する。ＤＴＭ８３５は、ステップ１０３０で、ＷｅｂサイトＡ８３０ａに対する登録が完了したことを示すメッセージを、ＳＡＳＯプロキシユニット８１０に送信する。ステップ１０３５で、ＳＡＳＯプロキシユニット８１０が、登録が完了したことをユーザー８０９に示す。

登録が完了した後、ユーザーは、信頼されるＤＴＭユニット８３５を使用して仲介されるＳＡＳＯプロセス（ステップ１０４０〜１０９５）においてＷｅｂサイトＡ８３０ａにアクセスすることができる。ステップ１０４０で、ユーザー８０９は、ユーザー８０９がＷｅｂサイトＡ８３０ａにアクセスするつもりであることをＳＡＳＯプロキシユニット８１０に（または、ＳＡＳＯプロキシユニット８３０ａが、スクレイピングまたは類似する技術によってこのメッセージを解釈することができるＷＡＡ８２０に）示す。ＳＡＳＯプロキシユニット８１０は、ステップ１０４５で、ユーザーが、ＷｅｂサイトＡにアクセスするつもりであることをＷＡＡ８２０に示す。あるいは、ユーザーが、ＷｅｂサイトＡ８３０ａにアクセスするユーザーの意図をＷＡＡ８２０に直接に示し、ＳＡＳＯプロキシユニット８１０が、スクレイピングを使用して、同一の情報を獲得する場合、ステップ１０４５は、要求されない。

次に、ＷＡＡ８２０が、ステップ１０５０で、ＷｅｂサイトＡ８３０ａにアクセスする要求をＤＴＭ８３５に送信する。次に、ＤＴＭ８３５が、ステップ１０５５で、アクセスを求める要求をＷｅｂサイトＡ８３０ａに転送する。ＷｅｂサイトＡ８３０ａは、ステップ１０６０で、サービス固有のパスワードを求める要求をＤＴＭユニット８３５に送信する。ＤＴＭユニット８３５は、ステップ１０６５で、Ｗｅｂサイト固有のパスワードをＷｅｂサイトＡ８３０ａに送信する。ＷｅｂサイトＡ８３０ａが、ステップ１０７０で、サービスアクセス許可メッセージをＤＴＭユニット８３５に送信する。ＤＴＭユニット８３５が、ステップ１０７５で、サービスアクセス許可メッセージをＷＡＡ８２０に送信する。ＷＡＡ８２０が、ステップ１０８０で、ＷｅｂサイトＡ８３０ａに関するアクセスが許可されたことをユーザー８０９に示す。ユーザーは、ステップ１０８５で、ＷＡＡ８２０を使用して、ＷｅｂサイトＡ８３０ａからサービスを受信することを始めることができる。

ＤＴＭ８３５が、ステップ１０８８、１０９０、および１０９３で、ＷＴＲＵ８０５およびＷＡＡ８２０の完全性の立証、ならびにユーザー立証データの完全性およびサービス固有のデータ（アプリケーションおよび所望されるサービスのリストなど）を検証する情報を要求し、受信することができる。そのようなリモート立証手続きは、ＷＴＲＵ８０５上のＴＰＭ／ＴＳＳ ８１５リモート立証能力を使用して行われることが可能である。また、ステップ１０８８、１０９０、および１０９３の手続きは、例えば、ＷＴＲＵ８０５が起動された時点で、実行されることも可能である。また、これらのステップは、ステップ１０５０の一環として、ＤＴＭ８３５からＷｅｂサイトへのサービス要求メッセージに組み込まれることも可能である。１０４０〜１０８５と同様のステップが、ＷｅｂサイトＢ８３０ｂなどの別のＷｅｂサイトまたは登録されたリスト上の他の任意のＷｅｂサイトに関して繰り返されることが可能である。

図１０のいくつかの代替の実施形態では、ＷＴＲＵ８０５は、ＴＰＭ／ＴＳＳ ８１５を欠いている可能性がある。そのような場合、ＤＴＭ８３５がそれでも使用されることが可能である。図１０を再び参照すると、ＷＴＲＵが、ＴＰＭ／ＴＳＳ ８１５を欠いている場合、ＳＡＳＯプロキシユニット８１０が、ユーザー認証データおよびデバイス認証データ、所望されるサービスのリストをＤＴＭユニット８３５に直接に登録する。この情報を受信した後、ＤＴＭ８３５は、高エントロピーのサイト（またはサービス）固有のパスワードを生成して、保持する（図１０におけるステップ１１２５の場合と同様に）。初期登録の後、ユーザー８０９が、ＷｅｂサイトＡ８３０ａにアクセスするつもりである場合、ＳＡＳＯプロキシユニット８１０が、ＤＴＭ８３５にアクセスするようＷＡＡ８２０を促す（図１０のステップ１１４５および１１５０と同様に）。ＤＴＭ８３５が、ＷｅｂサイトＡ８３０ａへのアクセスを要求する（ステップ１１５５と同様に）。ＷｅｂサイトＡ８３０ａは、サービス固有のパスワードを求める要求をＤＴＭ８３５に送信する（ステップ１１６０と同様に）。ＤＴＭ８３５が、このＷｅｂサイト固有のパスワードをＷｅｂサイトＡ８３０ａに送信する（ステップ１１６５と同様に）。ＷｅｂサイトＡ８３０ａが、サービスアクセス許可メッセージをＤＴＭ８３５に送信する（ステップ１１７０と同様に）。ＤＴＭ８３５が、アクセス許可メッセージをＷＡＡ８２０に送信する（ステップ１１７５と同様に）。ＷＡＡ８２０が、ＷｅｂサイトＡ８３０ａに関するアクセスが許可されたことをユーザー８０９に示す（ステップ１１８０と同様に）。ユーザーは、ＷＡＡ８２０を使用して、ＷｅｂサイトＡ８３０ａからサービスを受信することを始めることができる（ステップ１１８５と同様に）。

図１１は、別の実施形態による図８のシステム８００のコンポーネント間のシグナリングを示す。具体的には、図１１は、従来技術の方法よりセキュアにＴＰＭ／ＴＳＳ ８１５を使用するＷｅｂアクセスのためのＳＳＯに関する別の例示的な手続き１１００を示す。

この方法では、ユーザー８０９は、ＳＡＳＯプロキシユニット８１０によってそれぞれへのアクセスが制御され、ユーザー８０９によって供給される共通のグループ固有のログイン／パスワードを有する、サイトのグループを構成する。そのような手続きを使用することによって、ユーザー８０９は、グループ固有のパスワードを使用して、特定のＷｅｂサイトグループへのアクセスを制御して、その結果、或る特定のＷｅｂサイトグループだけにアクセスするユーザー８０９の意図に従って、ＳＡＳＯプロキシユニットのアクセス権さえ構成することができる。例えば、ユーザー８０９が、金融Ｗｅｂサイトグループに関する共通のパスワードだけを供給するが、個人的Ｗｅｂサイトグループに関する別の異なるパスワードを供給しない場合、ＳＡＳＯプロキシユニット８１０は、金融Ｗｅｂサイトグループに属するサイトに関するＳＳＯ動作を管理することだけしか許可されない。図１１に示されるとおり、この実施形態は、例として、以下の好ましいシグナリングステップを含む。シーケンスおよび／またはコンテンツの他の変種も可能であり、やはり、この実施形態の範囲に含まれる。

ユーザー８０９が、ステップ１１０５で、場合により、ＳＡＳＯプロキシユニット８１０によって促された後、Ｗｅｂサイトグループの確立を求める要求をＳＡＳＯプロキシユニット８１０に送信することによって、手続き１１００を開始する。この要求は、ＷｅｂサイトＡ８３０ａおよびＷｅｂサイトＢ８３０ｂ、ならびに、そのＷｅｂサイトグループに関してユーザーが作成したＳＳＯパスワードおよびそのグループに属するＷｅｂサイトのＵＲＬも含むことが可能である。このステップは、ユーザー８０９が、ＷｅｂサイトＡ８３０ａだけしか有さず、その後、他のＷｅｂサイトを追加または削除することによってグループを開始する、漸進的な仕方で行われることも可能である。そのようなＷｅｂサイトリスト更新が、いずれかの時点で実行されると、ＳＡＳＯプロキシユニット８１０は、ＴＰＭ／ＴＳＳ ８１５によって保持される或るデータ（さらに、データの一部はＳＡＳＯプロキシユニット８１０によっても保持される）を追加するため、削除するため、または結合解除する（un-binding）ため、および再結合するための手続きを要求する必要がある。

次に、ステップ１１１０で、ＳＡＳＯプロキシユニット８１０は、それらのＷｅｂサイトＵＲＬ、および各Ｗｅｂサイトに関する単一のＳＳＯパスワードをＷｅｂサイトグループの中に登録する。次に、ＳＡＳＯプロキシユニット８１０は、ステップ１１１５で、ＳＳＯパスワード、そのグループに属するすべてのＷｅｂサイトに関するＵＲＬおよびＷｅｂサイト資格証明、ＷＡＡ８２０およびＳＳＯプロキシユニット８１０のアドレスハンドル、さらにまた、ＴＰＭ／ＴＳＳ ８１５に対する、データ結合、およびＷｅｂサイト固有のパスワード生成を求める要求をＴＰＭ／ＴＳＳ ８１５に送信する。Ｗｅｂサイトのリストの中の各ＵＲＬに関して、ＴＰＭ／ＴＳＳ ８１５が、ステップ１１２０で、ＴＰＭ ＲＮＧ（Random Number Generator、乱数発生器）を使用して、暗号的に強いパスワードを生成する。ステップ１１２５で、ＴＰＭ／ＴＳＳ ８１５が、Ｗｅｂサイト固有のＵＲＬ、資格証明（サイト証明書を含む）、ＳＳＯパスワード、ならびにＴＰＭ／ＴＳＳ ８１５が生成したサイト固有のパスワードを、ＴＰＭストレージキーを使用して暗号化されたデータブラブ（data blob）の中で結合する。そのようなキーは、ＴＰＭを収容するプラットフォーム（例えば、ＷＴＲＵまたはコンピュータ）に「結合」される。ステップ１１０５で、ユーザー８０９が、関連する情報（ＵＲＬ、資格証明など）を有するＷｅｂサイトのグループのリストの更新（追加、削除、または変更）を示している場合、影響を受けるＷｅｂサイトに関するＷｅｂサイト固有のレコードを追加する、または削除する、ＳＡＳＯプロキシユニット８１０およびＴＰＭ／ＴＳＳ ８１５からの指示が、存在するはずである。

次に、ユーザー８０９が、ステップ１１３０で、ＷｅｂサイトＡ８３０ａに関するＵＲＬをＷＡＡ８２０に供給する。ＳＡＳＯプロキシユニット８１０が、ステップ１１３５で、Ｗｅｂスクレイピングによって、またはＡＰＩもしくは他の解析技術を介する協調によって、ＷｅｂサイトＡ８３０ａからのパスワード・プロンプトをインターセプトする。次に、ＳＡＳＯプロキシユニット８１０は、ステップ１１４０で、ＷｅｂサイトＡ８３０ａが、登録されたＷｅｂサイトグループのメンバであるかどうかを検証し、判定が肯定的である場合、そのようなグループを識別する。ＳＡＳＯプロキシユニット８１０は、ステップ１１４５で、ＷｅｂサイトＡ８３０ａが属するＷｅｂサイトグループに関するＳＳＯパスワードを供給するよう、人間のユーザー８０９に要求する。人間のユーザー８０９が、ステップ１１５０で、ＷｅｂサイトＡ８３０に関するＳＳＯパスワードおよびＷｅｂサイトＵＲＬを供給する（例えば、ＵＳＩＭ、バイオメトリック、またはタイプ入力によって）。代替として、ステップ１１４５および１１５０は、透過的にされて、ＳＡＳＯプロキシユニット８１０によって自動的に供給されてもよい。

次に、ＳＡＳＯプロキシユニット８１０が、ステップ１１５５で、ユーザー８０９が供給したＳＳＯパスワードを検査する。ＳＡＳＯプロキシユニット８１０は、ステップ１１６０で、ＷｅｂサイトＡ８３０ａに関するパスワードを結合解除し、取り出す要求をＴＰＭ／ＴＳＳ ８１５に送信する。この要求において、ＳＡＳＯプロキシユニット８１０は、ＷｅｂサイトＡ８３０ａに関するＳＳＯパスワードおよびサイトＵＲＬを含む。ＴＰＭ／ＴＳＳ ８１５が、ステップ１１６５で、以前に格納されたデータブラブからＷｅｂサイトＡ８３０ａに関するサイト固有のパスワードおよびサイト固有の資格証明を結合解除するデータハンドルとして、ＷｅｂサイトＡ８３０ａに関するＳＳＯパスワードおよびＵＲＬを使用する。以前に格納されたＷｅｂサイト固有のパスワード、ＵＲＬリスト、およびＷｅｂサイト固有の資格証明を結合解除し、取り出した後、ＴＰＭ／ＴＳＳ ８１５は、ＴＰＭ／ＴＳＳ ８１５がＳＡＳＯプロキシユニット８１０から受信したＳＳＯパスワードおよびＷｅｂサイトＵＲＬを、結合ストレージから回復したばかりのデータの値に照らして検証する。検証が、前述のステップ１１６５で達せられると、ＴＰＭ／ＴＳＳ ８１５は、ステップ１１７０で、ＷｅｂサイトＡ８３０ａに関するＷｅｂサイト固有のパスワード、およびＷｅｂサイト固有の資格証明をＳＡＳＯプロキシユニット８１０に供給する。

次に、ＳＡＳＯプロキシユニット８１０が、ステップ１１７３で、Ｗｅｂスクレイピング、ＡＰＩ、または他の解析技術などの技術を使用して、ＷＡＡ８２０上でＷｅｂサイトＡ８３０ａに関するパスワードフィールドおよび資格証明フィールドにデータ投入する。次に、ＷＡＡ８２０が、ステップ１１７５で、記入され、Ｗｅｂサイト固有のパスワード、およびＷｅｂサイト固有の資格証明をＷｅｂサイトＡ８３０ａに送信する。次に、このパスワードおよび資格証明が、ステップ１１８０で、ＷｅｂサイトＡ８３０ａにおいて登録される。ステップ１１８５で、Ｗｅｂサイト登録の成功が、ＷＡＡ８２０に示される。ステップ１１９０で、Ｗｅｂサイト登録の成功が、ＳＡＳＯプロキシユニット８１０に示され、ユニット８１０のデータベースの中に記録される。また、ステップ１１９０においても、Ｗｅｂサイト登録の成功が、ＴＰＭキーによって保護されたセキュアなメモリの中に、ＳＭＬ（Stored Measurement Log、格納された測定ログ）として記録される。ステップ１１９５で、ＴＰＭ／ＴＳＳ ８１５によって保持されるサイト固有のパスワード、およびサイト固有の資格証明を含む、信頼されるＳＳＯの確立が、完了する。

Ｗｅｂサイト登録が確立された後、ユーザー８０９が、ＷｅｂサイトＡ８３０ａにアクセスすることを、後でこのＷｅｂサイトのサービスを使用するサインオンのために所望する場合、１１３０〜１１８５と実質的に同一のステップが行われ、ただし、この場合、最終結果は、初期サイト登録ではなく、ＷｅｂサイトＡ８３０ａへのＳＳＯサインオンである。また、ユーザー８０９が、ＷｅｂサイトＡ８３０ａにではなく、ＷｅｂサイトＢ８３０ｂに登録するつもりである場合、ＷｅｂサイトＡ８３０ａに関して前に使用されたのと同一のステップが、ＷｅｂサイトＢ８３０ｂのＳＳＯ登録またはＳＳＯ認証のために使用されることが可能である。しかし、ＷｅｂサイトＢ８３０ｂのＵＲＬ、資格証明、サイト固有のパスワード、およびトークンなどの、ＷｅｂサイトＢ８３０ｂに関するＷｅｂサイト固有の情報が、ＷｅｂサイトＡ８３０ａに関するそのような情報の代わりに使用される。

代替の実施形態において、グループに関するアクセス制御（group-wise access control）が、ユーザー８０９による明示的な構成なしに実行されることが可能である。代わりに、ＳＡＳＯプロキシユニット８１０が、様々なタイプのＷｅｂサイトグループへのアクセスを支配するポリシーデータまたはプロファイルデータ（このデータ自体、ＴＰＭによって保護される）を供給されることが可能である。この実施形態では、グループに関するアクセス制御が、インストール時にＳＡＳＯプロキシユニット８１０によって構成される。さらに、ポリシー更新も、インストール時の後に可能であり得る。

図１２は、代替の実施形態に従って構成された無線通信システム１２００の例示的なブロック図である。システム１２００は、少なくとも１つのＷＴＲＵ１２１５と、ＲＡＮ（無線アクセスネットワーク）１２０３とを含むＬｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ準拠の無線通信システムである。ＷＴＲＵは、ユーザー１２０５と対話するように構成され、Ｗｅｂ−ＳＳＯユニット１２１２、プラットフォーム処理ユニット１２１０、ＴＰＭ／ＴＳＳ １２１７を含む。プラットフォーム処理ユニット１２１０は、ソフトウェアＳＷとして、またはハードウェアとして実施されることが可能である。ＲＡＮ１２０３は、ＩＤプロバイダー１２２０およびサービス・プロバイダー１２２５を含む。代替として、ＩＤプロバイダー１２２０は、公共のインターネット上などの、ＲＡＮ１２０３の外部に配置されてもよい。

図１３は、別の実施形態による図１２のシステム１２００のコンポーネント間のシグナリングを示す。具体的には、図１３で、ＩＤ−ＦＦ／ＳＡＭＬベースのＷｅｂＳＳＯ技術が、ＴＰＭ／ＴＳＳ １２１７によって提供される完全性検査機構とも組み合わされる。シーケンスおよび／またはコンテンツの他の変種も可能であり、やはり、この実施形態の範囲に含まれる。ユーザー１２０５が、ステップ１３０３で、Ｗｅｂ−ＳＳＯユニット１２１２を実行する意図を示すこと（例えば、ユニット１２１２をクリックすることによって、または、デフォルトで、システム起動によってなど）によって手続き１３００を開始する。プラットフォーム処理ユニット１２１０が、ステップ１３０８で、Ｗｅｂ−ＳＳＯユニット１２１２の符号完全性検査を実行するようＴＰＭ／ＴＳＳ １２１７に要求する。ＴＰＭ１２１７が、ステップ１３１２で、符号完全性検査を実行し、その結果をプラットフォーム処理ユニット１２１０に伝送する。

ステップ１３１２における検査が肯定的である場合、ステップ１３１６で、ログイン情報または認証情報が、プラットフォーム処理ユニット１２１０に供給され、Ｗｅｂ−ＳＳＯユニット１２１２に送られる。Ｗｅｂ−ＳＳＯユニット１２１２が、ステップ１３２０で、ＴＰＭキーを使用して以前に格納されているログイン資格証明を取り出すようＴＰＭ１２１７に要求する。ＴＰＭ１２１７が、ステップ１３２４で、ログイン資格証明データを取り出し、Ｗｅｂ−ＳＳＯソフトウェア１２１２に送る。Ｗｅｂ−ＳＳＯユニット１２１２が、ステップ１３２８で、取り出されたログイン資格証明データを使用して、ＩＤＰ１２２０にログインする。ＩＤＰ１２２０が、ステップ１３３２で、Ｗｅｂ−ＳＳＯユニット１２１２にイントロダクション・クッキーを送信する。

次に、Ｗｅｂ−ＳＳＯユニット１２１２が、ステップ１３３６で、ＳＰ１２２５に対して認証を行う。ステップ１３４０で、ＳＰ１２２５が、Ｗｅｂ−ＳＳＯユニット１２１２に、（１）Ｗｅｂ−ＳＳＯユニット１２１２が、ＩＤＰ１２２０からのクッキーを有するかどうか、（２）Ｗｅｂ−ＳＳＯユニット１２１２が、ＩＤＰ１２２０によってサポートされる、ユニット１２１２の連携ＩＤを使用する意図があるかどうか、および（３）Ｗｅｂ−ＳＳＯユニット１２１２が、公開キーがＳＰにおいて既に格納されている、またはＰＣＡによって獲得されることが可能である、プラットフォーム結合（platform-bound）ＴＰＭ秘密キーによって署名されたユニット１２１２のプラットフォームセキュリティ状態のステータスを表明する証明書を供給することができるかどうかを尋ねる。オプションとして、ＰＣＡは、ＩＰＤ１２２０であることが可能である。

次に、Ｗｅｂ ＳＳＯユニット１２１２が、ステップ１３４４で、ＴＰＭ／ＴＳＳ １２１７にプラットフォーム信頼状態を送信する。ＴＰＭ／ＴＳＳ １２１７が、ステップ１３４８で、プラットフォームの信頼状態を立証するＴＰＭによって保持される秘密署名キーによって署名された証明書を作成して、Ｗｅｂ−ＳＳＯソフトウェア１２１２に送る。Ｗｅｂ−ＳＳＯユニット１２１２は、ステップ１３５２で、ＳＰ１２２５に、（１）「はい」、ユニット１２１２が、ＩＤＰ１２２０からのクッキーを有すること、（２）「はい」、ユニット１２１２が、ＩＤＰ１２２０によって維持されるユニット１２１２の連携アカウントを使用することを意図すること、および（３）ＳＰ１２２５にプラットフォームセキュリティステータス証明書を送信することを示す。ＳＰ１２２５が、ステップ１３５６で、ＰＣＡからの助けを借りて、Ｗｅｂ−ＳＳＯユニット１２１２によって送信された信頼証明書を評価する。次に、ＳＰ１２１２は、ステップ１３５８で、今回は、連携認証要求を使用して、リダイレクトし再び認証を行うようＷｅｂ−ＳＳＯユニット１２１２に要求する。

次に、Ｗｅｂ−ＳＳＯユニット１２１２は、ステップ１３６２で、ＩＤＰ１２２０に連携認証要求（federated authentication request）を送信する。ＩＤＰ１２２０が、ステップ１３６４で、連携ＮａｍｅＩＤ、および関連する認証ステートメントを生成する。ＩＤＰ１２２０は、ステップ１３６８で、ＳＰ１２２５にリダイレクトするようＷｅｂ−ＳＳＯユニット１２１２に要求する。Ｗｅｂ−ＳＳＯユニット１２１２が、ステップ１３７２で、ＴＰＭ／ＴＳＳ １２１７によって保護されたキーを用いて格納されている連携＜Ａｓｓｅｒｔｉｏｎ＞の連携アーチファクト（artifact）を取り出すようＴＰＭ／ＴＳＳ １２１７に要求する。ＴＰＭ／ＴＳＳ １２１７が、ステップ１３７２で、アーチファクトデータを取り出して、このデータをＷｅｂ−ＳＳＯユニット１２１２に送る。Ｗｅｂ−ＳＳＯユニット１２１２が、ステップ１３８０で、ＩＤＰ１２２０によって保持されている、取り出された連携＜Ａｓｓｅｒｔｉｏｎ＞アーチファクトをＳＰ１２２５に送信する。

次に、ＳＰ１２２５が、ステップ１３８４で、ＳＯＡＰプロトコルを使用して、人間のユーザー１２０５に関する＜Ａｓｓｅｒｔｉｏｎ＞を検証するＩＤＰ１２２０に対する検証プロセスを開始する。ＩＤＰ１２２０が、ステップ１３８８で、ＳＯＡＰプロセスを使用する検証プロセスを返す（reciprocate）。ＳＰ１２２５が、ステップ１３９２で、人間のユーザー１２０５に関する＜Ａｓｓｅｒｔｉｏｎ＞および連携アカウントを評価する。最後に、ＳＰ１２２５は、ステップ１３９６で、許可されたサービス開始をＷｅｂ−ＳＳＯユニット１２１２に示し、指示が人間のユーザー１２０５に与えられる（例えば、表示などによって）。

図１３の代替の実施形態では、デバイスの信頼状態が、ＩＤＰ１２２０によって１回、評価され、後に、この信頼状態の使用のために、必要に応じて、各ＳＰ１２２５に通信されることが可能である。そのような情報の伝送は、クッキー、あるいはＳＡＭＬ手続きまたはＳＯＡＰ手続きなどの連携スキーム内の他の既存の、もしくは変形されたメッセージ／プロトコルなどの手段によって行われることが可能である。

フィーチャおよび要素が、特定の組み合わせで開示される実施形態において説明されるものの、各フィーチャ、または各要素は、好ましい実施形態の他のフィーチャ、および他の要素なしに単独で使用されることも、開示される他のフィーチャ、および他の要素を伴って、または伴わずに、様々な組み合わせで使用されることも可能である。本発明において提供される方法または流れ図は、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読媒体として実体化されたコンピュータプログラム、ソフトウェア、またはファームウェアとして実施されることが可能である。コンピュータ可読記憶媒体の例には、ＲＯＭ（読取り専用メモリ）、ＲＡＭ（ランダムアクセスメモリ）、レジスター、キャッシュメモリ、半導体メモリデバイス、内部ハードディスクやリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクやＤＶＤ（デジタルバーサタイルディスク）などの光媒体が含まれる。

適切なプロセッサには、例として、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、ＤＳＰ（デジタルシグナルプロセッサ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、ＡＳＩＣ（特定用途向け集積回路）、ＦＰＧＡ（フィールドプログラマブルゲートアレイ）回路、他の任意のタイプのＩＣ（集積回路）、および／または状態マシンが含まれる。

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

（実施形態）
１．ＴＰＭ（信頼されるプラットフォームモジュール）を有するＷＴＲＵ（無線送受信ユニット）によるＷｅｂサイトアクセスのためのセキュアなＳＳＯ（シングル・サインオン）を提供するための方法であって、
ＷＴＲＵにおいて、ターゲットＷｅｂサイトのグループを決定するステップと、
ターゲットＷｅｂサイトのグループから選択された１つのＷｅｂサイトにセキュアにサインオンするステップと、
ＷＴＲＵのＴＰＭにおいて生成され、格納されたセキュアなパスワードを使用して、Ｗｅｂサイトのグループから選択された他のＷｅｂサイトにサインオンするステップとを含む方法。
２．ＴＰＭが、いつターゲットＷｅｂサイトのグループへのアクセスが要求されるかを判定するＳＳＯプロキシユニットを含む実施形態１の方法。
３．ＳＳＯプロキシユニットが、ＴＰＭによってセキュリティ保護される実施形態２の方法。
４．ＴＰＭが、ターゲットＷｅｂサイトのグループから選択されたＷｅｂサイトにアクセスするためのランダムなパスワードを生成する、先行する実施形態のいずれかによる方法。
５．ＴＰＭが、ターゲットＷｅｂサイトのグループから選択されたＷｅｂサイトにアクセスするために生成されたランダムなパスワードを格納する実施形態４の方法。
６．決定するステップは、
ＷＴＲＵのユーザーが、ターゲットＷｅｂサイトのグループを選択することをさらに含む、先行する実施形態のいずれかによる方法。
７．ＳＳＯプロキシユニットは、パスワード情報をセキュアに記録する、先行する実施形態のいずれかによる方法。
８．記録されたパスワード情報が、キー結合技術を使用して格納される実施形態７の方法。
９．記録されたパスワード情報が、ＴＰＭの内部に格納される実施形態７または８による方法。
１０．ＷＴＲＵが、ＴＰＭの中に格納された一意のＩＤを含む、先行する実施形態のいずれかによる方法。
１１．ＷＴＲＵが、ＵＳＩＭ（汎用加入者ＩＤモジュール）の中に格納された一意なＩＤを含む、先行する実施形態のいずれかによる方法。
１２．一意なＩＤに基づいて暗号化キー階層を作成することをさらに含む実施形態１０〜１１のいずれかによる方法。
１３．Ｗｅｂサイトのグループから選択されたＷｅｂサイトにセキュアにサインオンするステップが、
Ｗｅｂサイトの証明書情報に関連する一意なユーザーＩＤおよびパスワードを作成することをさらに含む、先行する実施形態のいずれかによる方法。
１４．Ｗｅｂサイトのグループから選択された他のＷｅｂサイトにサインオンするステップは、
ユーザー資格証明をＷｅｂサイトに自動的に伝送するステップをさらに含む、先行する実施形態のいずれかによる方法。
１５．ユーザー資格証明が、データと一緒に伝送される実施形態１４の方法。
１６．ユーザーのバイオメトリック情報を感知するステップをさらに含む、先行する実施形態のいずれかによる方法。
１７．感知されたバイオメトリック情報が、セキュリティ目的で使用される実施形態１６の方法。
１８．ユーザーが、ＷｅｂサイトＡおよびＷｅｂサイトＢを含むＷｅｂサイトグループへの登録を要求することをさらに含む、先行する実施形態のいずれかによる方法。
１９．登録が、ＷｅｂサイトＡおよびＷｅｂサイトＢを含むＷｅｂサイトグループに関するＳＳＯパスワード、およびこのグループに属するＷｅｂサイトのＵＲＬをさらに含む実施形態１８の方法。
２０．登録が、漸進的に実行される実施形態１８〜１９のいずれかによる方法。
２１．ＳＳＯプロキシユニットが、Ｗｅｂサイトグループに関するＷｅｂサイトＵＲＬおよびシングルＳＳＯパスワードを登録することをさらに含む実施形態１８〜２０のいずれかによる方法。
２２．ＳＳＯプロキシユニットが、ＴＰＭおよびＴＰＭソフトウェア・スタック（ＴＳＳ）（ＴＰＭ／ＴＳＳ）に、Ｗｅｂサイトグループに属するすべてのＷｅｂサイトに関するＳＳＯパスワード、ＵＲＬ、およびＷｅｂサイト資格証明、ＷＡＡ（Ｗｅｂアクセス・アプリケーション）およびプロキシのアドレスハンドルを送信するステップと、
ＳＳＯプロキシが、データ結合、およびＷｅｂサイト固有のパスワード生成をＴＰＭ／ＴＳＳに要求するステップとをさらに含む実施形態２１の方法。
２３．ＴＰＭ／ＴＳＳが、プロキシおよびＷＡＡの符号完全性を所定の基準に照らして検証するステップをさらに含む実施形態２２の方法。
２４．ＴＰＭ／ＴＳＳが、Ｗｅｂサイトグループの各ＵＲＬに関して、ＴＰＭ乱数発生器を使用して、暗号的に強いパスワードを生成するステップをさらに含む実施形態２３の方法。
２５．ＴＰＭが、生成されて次いでＴＰＭ／ＴＳＳによって保護されたストレージキーを使用して、Ｗｅｂ固有のＵＲＬ、資格証明、ＳＳＯパスワードハッシュ、および生成されたＷｅｂサイト固有のパスワードを、結合された符号完全性値に封印するステップをさらに含む実施形態２４の方法。
２６．ＴＰＭが、生成されて次いでＴＰＭ／ＴＳＳによって保護されたストレージキーを使用して、Ｗｅｂ固有のＵＲＬ、資格証明、ＳＳＯパスワードハッシュ、および生成されたＷｅｂサイト固有のパスワードを、結合された符号完全性値に結合するステップをさらに含む実施形態２４の方法。
２７．ＴＰＭ／ＴＳＳが、Ｗｅｂサイトグループの各Ｗｅｂサイトに対応するさらなるアクションおよび要求の指示のために、ＴＰＭとＳＳＯプロキシユニットとの間でトークンとして使用するために、暗号的に強い乱数を生成するステップをさらに含む実施形態２５〜２６のいずれかによる方法。
２８．ＴＰＭ／ＴＳＳが、これらのトークンを、Ｗｅｂサイトグループの中のＷｅｂサイトのそれぞれに関するデータハンドルとして使用するステップをさらに含む実施形態２７の方法。
２９．ＴＰＭ／ＴＳＳが、ＳＳＯパスワードをハッシングして、このパスワード、およびこのハッシュをセキュアに格納するステップをさらに含む実施形態２８の方法。
３０．ＴＰＭ／ＴＳＳが、すべてのトークンをＳＳＯプロキシユニットに送信するステップと、
ＴＰＭ／ＴＳＳが、トークンとＷｅｂサイトＵＲＬの間のマッピングを示すマッピングデータを送信するステップをさらに含む実施形態２９の方法。
３１．ＷＴＲＵのユーザーが、ＵＲＬを選択するステップをさらに含む実施形態３０の方法。
３２．プロキシが、ＷｅｂサイトＡからのパスワード・プロンプトをインターセプトするステップをさらに含む実施形態３１の方法。
３３．ＳＳＯプロキシユニットが、ＷｅｂサイトＡからのパスワードをインターセプトするために、Ｗｅｂスクレイピング、またはＡＰＩ（アプリケーション・プログラミング・インターフェース）との協調を使用する実施形態３２の方法。
３４．ＳＳＯプロキシユニットが、ＷｅｂサイトＡが、Ｗｅｂサイトグループのメンバであるかどうかを検証するステップをさらに含む実施形態３２〜３３のいずれかによる方法。
３５．プロキシが、ＷｅｂサイトＡを含むＷｅｂサイトグループに関するＳＳＯパスワードを供給するようＷＴＲＵのユーザーに要求するステップをさらに含む実施形態３４の方法。
３６．ＷＴＲＵのユーザーが、ＳＳＯパスワードを供給するステップをさらに含む実施形態３５の方法。
３７．プロキシが、ＷＴＲＵのユーザーによって供給されたＳＳＯパスワードを検証するステップをさらに含む実施形態３６の方法。
３８．プロキシが、ＷｅｂサイトＡに関するパスワードを封印解除する要求をＴＰＭ／ＴＳＳに送信するステップをさらに含む実施形態３７の方法。
３９．ＷｅｂサイトＡに関するパスワードを封印解除する要求が、ＳＳＯプロキシユニットがデータベースの中に格納する、ＷｅｂサイトＡに関するＳＳＯパスワードおよび任意のＷｅｂサイト固有の資格証明を含む実施形態３８の方法。
４０．ＷｅｂサイトＡに関するパスワードを封印解除する要求が、ＳＳＯプロキシユニットおよびＷＡＡに関する符号ハンドルを含む実施形態３８または３９のいずれかによる方法。
４１．ＴＰＭ／ＴＳＳが、ＷｅｂサイトＡに属するトークンを検証するステップと、
ＷｅｂサイトＡに関するＷｅｂサイト固有のパスワード、およびＷｅｂサイト固有の資格証明を封印解除するステップをさらに含む実施形態３９〜４０のいずれかによる方法。
４２．ＴＰＭ／ＴＳＳが、ＷｅｂサイトＡに関するＷｅｂサイト固有のパスワードおよび資格証明をＳＳＯプロキシユニットに供給するステップをさらに含む実施形態４１の方法。
４３．ＳＳＯプロキシユニットが、ＷＡＡ上でＷｅｂサイトＡに関するパスワードフィールドおよび資格証明フィールドにデータ投入するステップをさらに含む実施形態４２の方法。
４４．Ｗｅｂサイト固有のパスワード、およびＷｅｂサイト固有の資格証明をＷｅｂサイトＡに送信するステップと、
ＷｅｂサイトＡにおける登録の成功を確認するステップをさらに含む実施形態４３の方法。
４５．Ｗｅｂサイト登録の成功をＳＳＯプロキシユニットに示すステップと、
登録の成功をＳＳＯプロキシユニットデータベースの中に記録するステップとをさらに含む実施形態４４の方法。
４６．ＷＴＲＵのＩＤおよび認証と関係するデータは、ＷＴＲＵのＴＰＭによって暗号的に保護される、先行する実施形態のいずれかによる方法。
４７．新たな暗号化キーを使用して、格納され暗号化されたデータを定期的に更新するステップをさらに含む、先行する実施形態のいずれかによる方法。
４８．ＴＰＭ（信頼されるプラットフォームモジュール）を使用するデバイス上でアプリケーションまたはインターネットベースのサービスにアクセスするための、ユーザーによるＳＡＳＯ（セキュアな自動化されたサインオン）のための方法であって、ユーザーが、シングルログインＩＤおよびパスワードによって、アプリケーションまたはインターネットベースのサービスにアクセスするステップを含む方法。
４９．ＴＰＭが、ＴＳＳ（ＴＰＭソフトウェア・スタック）を含む実施形態４８の方法。
５０．ユーザーが、デバイスに対して認証を行い、セキュアな１因子認証を介してデバイスへのアクセスを得るステップをさらに含む実施形態４８〜４９のいずれかにおけるとおりの方法。
５１．ユーザーが、デバイスに対して認証を行い、セキュアな２因子認証を介してデバイスへのアクセスを得るステップをさらに含み、第２の因子は、ＴＰＭによってセキュアに保持されるバイオメトリックを介する実施形態４８〜４９のいずれかにおけるとおりの方法。
５２．ＳＡＳＯプロキシユニットが、ＴＰＭ内に保持されるセキュアな情報にアクセスする実施形態４８〜５１のいずれかによる方法。
５３．バイオメトリックの第２の因子の認証が使用され、ＳＡＳＯプロキシユニットが、認証のためにそれを取り出す要求をＴＰＭに送信する実施形態５１または５２におけるとおりの方法。
５４．ＴＰＭが、このバイオメトリック認証データをＳＡＳＯプロキシユニットに供給するステップをさらに含む実施形態５３の方法。
５５．ユーザーが、ＷＡＡを使用して、セキュアなＷｅｂサイトに登録しようと試みるステップをさらに含む実施形態４８〜５４のいずれかにおけるとおりの方法。
５６．このアプリケーションが、ＷＡＡ（ウェブ−ＷＡＡ）である実施形態５５の方法。
５７．ＷＡＡが、第１のインターネットベースのサービスＷｅｂサイトに、ユーザーが、このＷｅｂサイトにアクセスすることを所望するという指示を送信する実施形態５５または５６におけるとおりの方法。
５８．ＷＡＡが、第１のインターネットベースのサービスＷｅｂサイトのログイン・プロンプトを受信して、示すステップをさらに含む実施形態５７の方法。
５９．ＳＳＯプロキシユニットが、ＷＡＡからの第１のＷｅｂサイトの認証プロンプトをインターセプトするステップをさらに含む実施形態４８〜５８のいずれかにおけるとおりの方法。
６０．インターセプトするステップが、Ｗｅｂスクレイピングによって、または解析技術を介する協調によって達せられる実施形態５９の方法。
６１．ＳＡＳＯプロキシユニットが、ＴＰＭにユーザーＩＤ情報を送るステップをさらに含む実施形態４８〜６０のいずれかにおけるとおりの方法。
６２．ユーザーＩＤ情報が、２因子認証からのデバイスログイン情報を含む実施形態６１の方法。
６３．Ｗｅｂサイト固有のセキュアなパスワードが、ＴＰＭによって生成され、セキュアに格納されるステップをさらに含む実施形態４８〜６２のいずれかにおけるとおりの方法。
６４．パスワードが、ＴＰＭ ＮＶメモリの中に直接にセキュアに格納される、またはＴＰＭによって保護された結合ストレージキーによって通常のメモリの中に暗号化される実施形態６３の方法。
６５．ＳＡＳＯプロキシユニットが、ＷＡＡパスワード・プロンプトにＷｅｂサイト固有のセキュアなパスワードに情報を記入し、この情報が、第１のＷｅｂサイトにＷｅｂサイト固有である実施形態５９〜６４のいずれかにおけるとおりの方法。
６６．ＷＡＡが、このＷｅｂサイト固有のパスワードを第１のＷｅｂサイトに伝送するステップと、第１のＷｅｂサイトが、このＷｅｂサイト固有のパスワードを登録して、アクセス許可をＷＡＡに送信するステップをさらに含む実施形態６５の方法。
６７．登録が確立されている、実施形態４８〜６６のいずれかにおけるとおりの方法であって、Ｗｅｂサイト固有の情報を、ＴＰＭ結合ストレージキーによって保護されたＴＰＭデータブラブの中のデータベースレコードとして、一緒にセキュアに格納するステップをさらに含む方法。
６８．Ｗｅｂサイト固有の情報が、ＵＲＬ、デジタル証明書、ユーザーＩＤ、およびパスワードの少なくとも１つを含む実施形態６７の方法。
６９．Ｗｅｂサイト固有のパスワードが、それぞれのＷｅｂサイトへの後のログインのためにＳＡＳＯプロキシユニットによって再使用される実施形態６６〜６８のいずれかにおけるとおりの方法。
７０．第１のＷｅｂサイトが、ＷＡＡにアクセスを許可する実施形態４８〜６９のいずれかにおけるとおりの方法であって、通常のＷｅｂベースの通信をさらに含む方法。
７１．ＴＰＭ内にパスワードが保持される、既に確立されたＷｅｂサイトにアクセスするステップをさらに含む実施形態４８〜７０のいずれかにおけるとおりの方法。
７２．さらなるＷｅｂサイトにアクセスするためにＳＡＳＯプロキシユニットを使用するステップをさらに含む実施形態４８〜７１のいずれかにおけるとおりの方法。
７３．ＴＰＭによって可能にされる符号完全性検証手続きを使用してＳＡＳＯプロキシユニットの完全性が保護されて、セキュアなトランザクションが行われることが確実にされる実施形態４８〜７２のいずれかにおけるとおりの方法。
７４．パスワード更新手続きを管理するポリシーまたはプロファイルを確立するステップをさらに含み、ＴＰＭが、このポリシー情報およびプロファイル情報を、ＴＰＭ結合ストレージキーによって保護されるデータブラブの中に、これらの情報を格納することによって保護する実施形態４８〜７３のいずれかにおけるとおりの方法。
７５．セキュアな時間ファシリティ（time facilities）を使用して、執行されるべきセキュアなパスワード更新ポリシーを与えるステップをさらに含む実施形態４８〜７４のいずれかにおけるとおりの方法。
７６．ＴＰＭ内の単一の認証パスワードの下で保持される、いくつかのＷｅｂサイトを一緒にプールするステップをさらに含む実施形態４８〜７５のいずれかにおけるとおりの方法。
７７．ＴＰＭが、認証のために使用されるキーおよびパスワードの頻繁な更新を実行するステップをさらに含む実施形態４８〜７６のいずれかにおけるとおりの方法。
７８．ＴＰＭが、前回のパスワード更新が行われた時刻、およびパスワード更新手続きをトリガするようにユーザーによってまたはインターネットベースのサービスによって供給される更新時間間隔を常に把握しておくセキュアなタイマモジュールを含む実施形態７７の方法。
７９．ＳＡＳＯプロキシユニットと、ＴＰＭ（信頼されるプラットフォームモジュール）とを有するデバイス上でアプリケーションまたはインターネットベースのサービスにアクセスするための、ユーザーによるＳＡＳＯ（シングル自動サインオン）のための方法であって、
ユーザーが、アプリケーションまたはインターネットベースのサービスのグループを構成し、各アプリケーション、または各インターネットベースのサービスへのアクセスが、グループ固有のパスワードによって制御されるステップを含む方法。
８０．ＳＡＳＯプロキシユニットが、第１のインターネットＷｅｂサイトと、第２のインターネットＷｅｂサイトとを含むＷｅｂサイトグループの確立または登録を求める要求を受信するステップと、
このＷｅｂサイトグループに関するＳＳＯパスワード、およびこのＷｅｂサイトグループに属するインターネットＷｅｂサイトのＵＲＬを生成するステップをさらに含む実施形態７９の方法。
８１．ユーザーが、第１のインターネットＷｅｂサイトだけしか有さず、その後、他のＷｅｂサイトを追加すること、または削除することによって、このグループを漸進的に開始する実施形態８０の方法。
８２．Ｗｅｂサイトグループの更新を実行すること、およびＳＡＳＯプロキシユニットが、ＴＰＭによって保持されるデータの追加、削除、または結合解除および再結合さえも行うための手続きを要求するステップをさらに含む請求項７９〜８１のいずれかにおけるとおりの方法。
８３．ＳＡＳＯプロキシユニットが、このＷｅｂサイトグループに関するＷｅｂサイトＵＲＬおよびシングルＳＳＯパスワードを登録するステップをさらに含む実施形態７９〜８２のいずれかにおけるとおりの方法。
８４．ＴＰＭが、ＴＳＳ（ＴＰＭソフトウェア・スタック）を含む実施形態７９〜８３のいずれかにおけるとおりの方法。
８５．ＳＡＳＯプロキシユニットが、このグループに属するすべてのＷｅｂサイトに関するＳＳＯパスワード、ＵＲＬ、およびＷｅｂサイト資格証明、インターネットＷＡＡソフトウェアおよびＳＳＯプロキシユニット自体のアドレスハンドルをＴＰＭに送信するステップと、データ結合およびＷｅｂサイト固有のパスワード生成を求める要求をＴＰＭに送信するステップをさらに含む実施形態８０〜８４のいずれかにおけるとおりの方法。
８６．リストの中の各ＵＲＬに関して、ＴＰＭが、ＴＰＭ ＲＮＧ（乱数発生器）を使用して、暗号的に強いパスワードを生成する実施形態８５におけるとおりの方法。
８７．ＴＰＭが、ＴＰＭストレージキーを用いて暗号化されたデータブラブの中で、Ｗｅｂサイト固有のＵＲＬ、任意の資格証明、ＳＳＯパスワード、およびＴＰＭが生成したＷｅｂサイト固有のパスワードを結合するステップをさらに含む実施形態８６におけるとおりの方法。
８８．このキーが、ＴＰＭを収容するプラットフォームに結合される実施形態８７におけるとおりの方法。
８９．ユーザーが、関連する情報を有するＷｅｂサイトグループの更新を指示している、実施形態８０〜８８のいずれかにおけるとおりの方法であって、影響を受けるＷｅｂサイトに関するＷｅｂサイト固有のレコードを追加または削除するＳＡＳＯプロキシユニットおよびＴＰＭからの指示をさらに含む方法。
９０．ユーザーが、ＷＡＡに対する第１のインターネットＷｅｂサイトに関するＵＲＬをデバイスに入力することをさらに含む実施形態７９〜８９のいずれかにおけるとおりの方法。
９１．ＳＡＳＯプロキシユニットが、第１のインターネットＷｅｂサイトからのパスワード・プロンプトをインターセプトするステップをさらに含む実施形態９０の方法。
９２．インターセプトするステップが、Ｗｅｂスクレイピングによる、またはＡＰＩもしくは他の解析技術を介する協調による実施形態９１の方法。
９３．ＳＡＳＯプロキシユニットが、第１のインターネットＷｅｂサイトが、登録されたＷｅｂサイトグループのメンバであるかどうかを検証し、肯定的である場合、そのようなグループを識別することをさらに含む実施形態９１または９２におけるとおりの方法。
９４．ＳＡＳＯプロキシユニットが、第１のインターネットＷｅｂサイトが属するＷｅｂサイトグループに関するＳＳＯパスワードを供給するよう、ユーザーに要求するステップをさらに含む実施形態９１〜９３のいずれかにおけるとおりの方法。
９５．ユーザーが、第１のインターネットＷｅｂサイトに関するＳＳＯパスワードおよびＷｅｂサイトＵＲＬを入力または供給するステップをさらに含む実施形態９１〜９４のいずれかにおけるとおりの方法。
９６．供給するステップは、バイオメトリックによる実施形態９６の方法。
９７．ＳＡＳＯプロキシユニットが、ユーザーが供給したＳＳＯパスワードを検査する実施形態９４〜９７のいずれかにおけるとおりの方法。
９８．ＳＳＯプロキシユニットが、ＷｅｂサイトＵＲＬ、ＳＳＯプロキシユニットの証明書、およびパスワードを求めるプロンプトのおかげで、ＳＳＯパスワードを自動的に供給するステップをさらに含む実施形態９１〜９３のいずれかにおけるとおりの方法。
９９．ＳＳＯプロキシユニットが、第１のインターネットＷｅｂサイトに関するＳＳＯパスワードおよびＷｅｂサイトＵＲＬを含む第１のインターネットＷｅｂサイトに関するパスワードを結合解除し、取り出す要求をＴＰＭに送信するステップをさらに含む実施形態７９〜９８のいずれかにおけるとおりの方法。
１００．ＴＰＭが、以前に格納されたデータブラブから第１のインターネットＷｅｂサイトに関するＷｅｂサイト固有のパスワードおよび資格証明を結合解除するデータハンドルとして、第１のインターネットＷｅｂサイトに関するＳＳＯパスワードおよびＵＲＬを使用するステップと、ＴＰＭが、ＳＡＳＯプロキシユニットから受信したＳＳＯパスワードおよびＷｅｂサイトＵＲＬを、結合ストレージから回復したデータの値に照らして検証するステップをさらに含む実施形態９９の方法。
１０１．ＳＳＯパスワードの検証が達せられた場合、ＴＰＭが、第１のインターネットＷｅｂサイトに関するＷｅｂサイト固有のパスワードおよび資格証明をＳＳＯプロキシユニットに供給する実施形態１００におけるとおりの方法。
１０２．ＳＳＯプロキシユニットが、Ｗｅｂスクレイピング、ＡＰＩ、または他の解析技術を使用して、第１のインターネットＷｅｂサイトに関するパスワードフィールドおよび資格証明フィールドにデータ投入するステップをさらに含む実施形態７９〜１０１のいずれかにおけるとおりの方法。
１０３．インターネットＷＡＡに記入して、第１のインターネットＷｅｂサイトにＷｅｂサイト固有のパスワードおよび資格証明を送信するステップと、このパスワードおよび資格証明を第１のインターネットＷｅｂサイトにおいて登録するステップとをさらに含む実施形態１０２の方法。
１０４．登録の成功をインターネットＷＡＡに示すステップと、この登録をＳＡＳＯプロキシユニットに示して、この登録をＳＡＳＯプロキシユニットのデータベースの中に記録するステップをさらに含む実施形態１０３の方法。
１０５．この登録を、ＴＰＭキーによって保護されるセキュアなメモリの中にＳＭＬ（格納された測定ログ）として記録するステップをさらに含む実施形態１０４の方法。
１０６．ユーザーが、第１のインターネットＷｅｂサイトにアクセスすることを、後の時点でサインオンしてそのＷｅｂサイトのサービスを使用するために求める、実施形態７９〜１０５のいずれかにおけるとおりの方法であって、ユーザーが、ＳＡＳＯによってアクセスを得るステップをさらに含む方法。
１０７．ユーザーが、第１のインターネットＷｅｂサイトではなく、第２のインターネットＷｅｂサイトに登録する、または後にアクセスすることを求める、実施形態７９〜１０６のいずれかにおけるとおりの方法であって、ＵＲＬ、資格証明、Ｗｅｂサイト固有のパスワード、およびトークンの１つまたは複数を含む、第２のインターネットＷｅｂサイトに関するＷｅｂサイト固有の情報を使用して、第２のインターネットＷｅｂサイトのＳＡＳＯ登録またはＳＡＳＯ認証を実行するステップをさらに含む方法。
１０８．機能するＴＰＭが、ユーザーのプラットフォームに結合される、任意の先行する実施形態におけるとおりの方法であって、ユーザーまたはユーザーのデバイスのＩＤおよび認証と関係するデータを、ユーザーのデバイスまたはプラットフォームの中に存在するＴＰＭによってデータの機密性、完全性、および真正性に関して暗号によって保護するステップをさらに含む方法。
１０９．ＴＰＭが、物理的に保護された境界を提供することによって、暗号によって保護し、格納するデータに関する本来的なセキュリティを提供する、実施形態１０８におけるとおりの方法。
１１０．アプリケーション・セキュリティ・コンポーネントおよびＩＰスタック・セキュリティ・コンポーネントに、高エントロピーのパスワードを含むセキュアな資格証明が与えられるように、ＴＰＭ機能を含むようにＵＳＩＭ機能を拡張するステップをさらに含む実施形態１０８〜１０９のいずれかにおけるとおりの方法。
１１１．アプリケーション・セキュリティ・コンポーネントが、ＤＲＭサービスコンポーネントと、ＰＧＰサービスコンポーネントとを含む、実施形態１１０におけるとおりの方法。
１１２．ＩＰスタック・セキュリティ・コンポーネントが、ＩＰＳｅｃまたはＴＬＳ、あるいはＩＰＳｅｃとＴＬＳの両方を含む実施形態１１０または１１１におけるとおりの方法。
１１３．ＵＳＩＭ内に組み込まれたＴＰＭ内でリフレッシュされるパスワードおよび／または暗号化キーのポリシーベースの自動更新をさらに含む実施形態１０８〜１１０のいずれかにおけるとおりの方法。
１１４．ＴＬＳおよびアプリケーションセキュリティのために要求される認証アルゴリズムを含むようにＵＳＩＭ機能を拡張することをさらに含む実施形態１０８〜１１０のいずれかにおけるとおりの方法。

Claims (32)

1. ＳＳＯ（シングル・サインオン）技術を使用してセキュアなパスワード管理を実行するためのＷＴＲＵ（無線送受信ユニット）であって、
   ユーザーからユーザー認証データを受信し、かつ少なくとも１つのＷｅｂサイトに関するユーザー固有のログイン情報を求める要求を取得するＳＳＯプロキシユニットと、
   少なくとも１つのＷｅｂサイトに関するユーザー固有のログイン情報およびユーザー認証データを格納し、かつ、前記受信したユーザー認証データを前記格納されたユーザー認証データと比較して、前記比較が肯定的である場合、前記格納されたユーザー固有のログイン情報を転送するＴＰＭ（信頼されるプラットフォームモジュール）と、
   前記転送されたユーザー固有のログイン情報を自動的に受信し、前記少なくとも１つのＷｅｂサイトへのアクセスを求めるユーザー要求を受信すると、前記転送されたユーザー固有のログイン情報を前記少なくとも１つのＷＥＢサイトに伝送するＷＡＡ（Ｗｅｂアクセス・アプリケーション）と
   を含むことを特徴とするＷＴＲＵ。
2. 前記ＳＳＯプロキシユニットは、前記ＴＰＭの中の前記パスワードにアクセスするためにユーザー認証データを要求することを特徴とする請求項１に記載のＷＴＲＵ。
3. 前記ユーザー認証データは、少なくとも２つの因子に基づくことを特徴とする請求項２に記載のＷＴＲＵ。
4. 前記少なくとも２つの因子の１つは、バイオメトリック情報であることを特徴とする請求項３に記載のＷＴＲＵ。
5. 前記少なくとも２つの因子の１つは、パスワードであることを特徴とする請求項３に記載のＷＴＲＵ。
6. ひとたびユーザー認証データが供給されることに成功すると、事前識別されたＷｅｂサイトグループの中のすべてのＷｅｂサイトへのアクセスが、自動的に許可されることを特徴とする請求項１に記載のＷＴＲＵ。
7. ユーザー固有のログイン情報は、少なくともＵＲＬおよびＷｅｂサイト固有のパスワードを含むことを特徴とする請求項１に記載のＷＴＲＵ。
8. ＴＰＭは、Ｗｅｂサイト固有のパスワードを生成して、保持することを特徴とする請求項７に記載のＷＴＲＵ。
9. 前記Ｗｅｂサイト固有のパスワードは、前記ＴＰＭの中だけに格納されるランダム化されたパスワードであることを特徴とする請求項８に記載のＷＴＲＵ。
10. 前記比較が肯定的である場合、さらなるＷｅｂサイトがアクセスされることが可能であることを特徴とする請求項１に記載のＷＴＲＵ。
11. 前記ＳＳＯプロキシユニットは、前記少なくとも１つのＷｅｂサイトからセキュアなサインオン証明書を受信し、該証明書を使用して前記少なくとも１つのＷｅｂサイトを認証することを特徴とする請求項１に記載のＷＴＲＵ。
12. 前記ＳＳＯプロキシユニットは、Ｗｅｂサイトグループに関してＳＳＯ動作を使用すべきかどうかを前記ユーザーにプロンプト指示することを特徴とする請求項１に記載のＷＴＲＵ。
13. 前記プロンプト指示は、前記Ｗｅｂサイトグループのサブグループに関してだけＳＳＯ動作を使用するオプションを含むことを特徴とする請求項１２に記載のＷＴＲＵ。
14. Ｌｉｂｅｒｔｙ Ａｌｌｉａｎｃｅ ＩＤ−ＦＦ（ＩＤフェデレーションフレームワーク）を使用してＳＳＯサービスを実行するように構成されることを特徴とする請求項１３に記載のＷＴＲＵ。
15. ＤＴＭ（デバイスによって信頼されるミラー）を認証して、前記ＤＴＭとの信頼される関係および無線アクセスネットワークに対するセキュアなリンクを確立するように構成されることを特徴とする請求項１に記載のＷＴＲＵ。
16. 前記ＤＴＭは、前記ユーザーデバイスの信頼性を「ミラーリング」するサービスを提供し、信頼性情報を、そのような情報の外部の要求者に提供するように構成されることを特徴とする請求項１に記載のＷＴＲＵ。
17. ＴＰＭ（信頼されるプラットフォームモジュール）を有するＷＴＲＵ（無線送受信ユニット）によってアクセスされるＷｅｂサイトグループの少なくとも１つのＷｅｂサイトに関してセキュアなＳＳＯ（シングル・サインオン）を提供するための方法であって、
    前記ＷＴＲＵにおいてＷｅｂサイトグループを決定するステップと、
    少なくとも１つの認証因子を使用してユーザーを認証するステップと、
    ひとたび前記ユーザーが前記ＴＰＭの中に格納されるログイン情報を使用して認証されると、前記Ｗｅｂサイトグループから選択された１つのＷｅｂサイトにセキュアにサインオンするステップと
    を含むことを特徴とする方法。
18. 前記ＷＴＲＵは、前記事前定義されたＷｅｂサイトグループへのアクセスがいつ要求されたかを判定するためのＳＳＯプロキシユニットを含むことを特徴とする請求項１７に記載の方法。
19. 前記ＳＳＯプロキシユニットは、前記ＴＰＭによってセキュリティ保護されることを特徴とする請求項１８に記載の方法。
20. 前記ＴＰＭは、前記Ｗｅｂサイトグループから選択されたＷｅｂサイトにアクセスするためのランダムなサイト毎のパスワードを生成することを特徴とする請求項１７に記載の方法。
21. 前記ＴＰＭは、前記Ｗｅｂサイトグループから選択されたＷｅｂサイトにアクセスするために生成されたランダムなパスワードを格納することを特徴とする請求項１７に記載の方法。
22. 決定するステップは、ＷＴＲＵが、ユーザーからＷｅｂサイトグループを受信するステップをさらに含むことを特徴とする請求項１７から２１のいずれかに記載の方法。
23. 前記ＳＳＯプロキシユニットは、パスワード情報をセキュアに記録し、該情報を前記ＴＰＭの中に格納することを特徴とする請求項１７に記載の方法。
24. 前記記録されたパスワード情報は、キー結合技術を使用して前記ＴＰＭの中に格納されることを特徴とする請求項２３に記載の方法。
25. 前記ＷＴＲＵは、前記ＴＰＭの中に格納された一意なＩＤを含むことを特徴とする請求項１７に記載の方法。
26. 前記ＷＴＲＵは、ＵＳＩＭ（汎用加入者ＩＤモジュール）の中に格納された一意なＩＤを含むことを特徴とする請求項１７に記載の方法。
27. キー結合技術を使用することは、前記一意なＩＤに基づいて暗号化キー階層を使用することを含むことを特徴とする請求項２４に記載の方法。
28. 前記事前定義されたＷｅｂサイトグループから選択されたサイトにセキュアにサインオンするステップは、
    Ｗｅｂサイトの証明書情報に関連する一意なユーザーＩＤおよびパスワードを作成するステップをさらに含むことを特徴とする請求項１７に記載の方法。
29. 前記サイトグループから選択された他のサイトに前記サインオンするステップは、前記他のＷｅｂサイトにユーザー資格証明を自動的に伝送するステップをさらに含むことを特徴とする請求項１７に記載の方法。
30. 前記ユーザー資格証明は、データと一緒に伝送されることを特徴とする請求項２９に記載の方法。
31. ユーザーのバイオメトリック情報を感知するステップをさらに含むことを特徴とする請求項１７に記載の方法。
32. 前記感知されたバイオメトリック情報は、認証目的で使用されることを特徴とする請求項３１に記載の方法。

Images