JP5802337B2 - アウトオブバンドリモート認証 - Google Patents

Description

ユーザーの証明及び認証には、従来、オペレーティングシステム（ＯＳ）及び／又はソフトウェアを介した（即ち、インバンド通信を介した）ユーザー証明書の入力が必要とされている。例えば、サービスプロバイダ（ＳＰ）のクラウドに基づいた電子メールサービスにログインするためには、ユーザーは、ユーザー名及びパスワードをＯＳ及びブラウザを介して入力しなければならない。但し、このようなパスワードへの依存だけでは、安全な演算慣行を維持するには不十分であろう。

例えば、ＯＳ又はソフトウェアモジュールを伴うインバンド通信を介したパスワード情報の入力の際には、システムは、（例えば、キーロガーや中間者攻撃などの）セキュリティ上の脅威に晒された状態におかれる。ユーザーアクセス要求が実際に自然人に由来したものであることを検証するものと理論的に考えられているハードウェア又はソフトウェアのワンタイムパスワード（Ｏｎｅ Ｔｉｍｅ Ｐａｓｓｗｏｒｄ：ＯＴＰ）などの強力なパスワードも、パスワードが伝達される方式に伴うインバンド特性に起因し、問題を有している（即ち、このようなパスワードは、依然として、キーロガーやこれに類似したものの影響を受け易い）。更には、このようなパスワードが捕捉されない場合にも、これらの同一のパスワードは、脆弱であり、その理由は、トロイの木馬、ウイルス、及びワームが自然人を装うと共に複数のエンドポイントに跨って拡散する場合があるからである。大部分のパスワードに伴う更に別の問題点として、人間は、通常、自身が加入しているすべてのインターネットサービス用の、一意の、長い、又はその他の方式によって強力な、パスワードを思い出すことなどできない。この結果、思い出すことに伴う負担を低減するために、多くのユーザーは、同一のパスワードを複数のサイトにわたって再使用している。ユーザーがいくつかの異なるパスワードを使用している場合にも、それらのパスワードは、しばしば、短く、予測可能であり、又はその他の方式によって脆弱であり、且つ、上述の選択肢と同様に効果を有していない。

パスワードの強度を増大させるために、アイデンティティ管理サービスは、例えば、網膜スキャン、指紋スキャン、及びこれらに類似したものを含む多要素認証（Ｍｕｌｔｉ−Ｆａｃｔｏｒ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ：ＭＦＡ）を実装している。このような証明書は、一意であり、ユーザーが記憶する必要がなく、且つ、一般に、パスワードとして強力であると見なされている。但し、このような証明書の実際の現実世界における実装は、例えば、ユーザーが複数のサービスプロバイダとのやり取りを所望するなどのような現実的な環境において観察した際には、問題となる可能性がある。

具体的には、アイデンティティ管理サービスは、クライアント上ではなく、サーバー上において、対応するＭＦＡポリシーを試験することにより、ＭＦＡを実装している。従って、ユーザーの存在は、プラットフォームの外部において（例えば、クライアントサイドにおけるハードウェアトークンにより、且つ／又は、認証の細目をサーバーに転送することにより）立証されている。この理由は、プラットフォーム自体が証明能力を有していないからであるか、或いは、プラットフォーム自体が証明能力を有している場合には、高信頼性経路メカニズム（例えば、高信頼性プラットフォームモジュール（Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ：ＴＰＭ））が証明能力の外部に存在しているからであろう。

この結果、ユーザー認証の状態が（クライアント上にではなく）サーバーによって保持されているため、（異なるサーバー上の）異なるサービスプロバイダがユーザーの認証状態について知ることを所望した場合には、２つの選択肢が存在している。第１の選択肢としては、ユーザーは、例えば、再度、網膜スキャンを提出することにより、再認証しなければならないであろう。これは、特に、ＭＦＡ証明書を有するように（例えば、複数の網膜スキャンを取得するように）実装されている際には、ユーザーにとって負担となる可能性がある。第２の選択肢としては、２つのサーバーが、ユーザーのアイデンティティを統合すると共にユーザーの認証状態を追跡するためのバックエンドプロトコルを実装しなければならない。この方式は、ユーザーが直接的に制御することができないというプライバシー上の懸念を有しており、この結果、この場合にも、セキュリティが低下することになる。いずれの選択肢も最適なものではない。

本発明の実施形態の特徴及び利点については、添付の請求項、１つ又は複数の例示用の実施形態の詳細な説明、及び対応する図面から明らかとなろう。

本発明の一実施形態におけるシステムを含む。 本発明の一実施形態における方法を含む。 本発明の一実施形態における方法を含む。 本発明の実施形態と共に使用されるシステムを含む。

以下の説明においては、多数の具体的な詳細事項が記述されているが、本発明の実施形態は、これらの具体的な詳細事項を伴うことなしに実施してもよい。周知の回路、構造、及び技法については、以下の説明の理解を曖昧にすることを回避するべく、詳細に示されてはいない。「一実施形態」、「様々な実施形態」、及びこれらに類似したものは、このように記述された１つ又は複数の実施形態が特定の特徴、構造、又は特性を含んでもよいことを示しているが、すべての実施形態が、それらの特定の特徴、構造、又は特性を必ずしも含むものではない。いくつかの実施形態は、その他の実施形態について記述されている特徴のいくつか又はすべてを有してもよく、或いは、そのすべてを有していなくてもよい。「第１の」、「第２の」、「第３の」、及びこれらに類似したものは、共通の対象物を記述しており、且つ、類似の対象物の異なるものが参照されていることを示している。このような形容詞は、このように記述されている対象物が、時間的に、空間的に、ランキングにおいて、又は任意のその他の方式により、所与の順序を有していなければならないことを意味するものではない。「接続されている」は、要素が互いに直接的な物理的又は電気的接触状態にあることを示している場合があり、且つ、「結合されている」は、要素が互いに協働又は相互作用することを示している場合があるが、これらの要素は、直接的な物理的又は電気的接触状態にある場合もあり、或いは、そうでない場合もある。又、類似の又は同一の符号を使用して異なる図面において同一の又は類似の部分を表記している場合があるが、このような表記は、類似の又は同一の符号を含むすべての図面が単一の又は同一の実施形態を構成していることを意味するものではない。

一実施形態においては、アウトオブバンド通信を介した高信頼性経路ハードウェアモジュールとサービスプロバイダの間において実行される単一のユーザー認証イベントにより、ユーザーが、それぞれのサービスプロバイダに固有の強力な証明書を使用して複数のサービスプロバイダに対してトランスペアレントにアクセスすることができるようにすることができる。認証イベントは、ユーザーの実際の物理的存在を示す多要素認証に基づいたものであってもよい。従って、例えば、ユーザーは、それぞれのサービスプロバイダに対するアクセスを得るために、異なる網膜スキャンを入力する必要がなくなるであろう。

図１は、本発明の一実施形態におけるシステム１００を含んでいる。一般に、プラットフォーム１０５は、モバイル演算装置、ラップトップ、ネットブック、タブレット、パーソナルコンピュータ、パーソナルデジタルアシスタント、携帯電話機、スマートフォン、携帯型メディアプレーヤー、及びこれらに類似したものを含んでもよい。プラットフォーム１０５は、中央処理装置（ＣＰＵ）１２５と、システムオンチップ（Ｓｙｓｔｅｍ−Ｏｎ−ａ−Ｃｈｉｐ：ＳＯＣ）１３０と、を含んでもよい。

ＳＯＣ１３０は、高信頼性経路（Ｔｒｕｓｔｅｄ Ｐａｔｈ：ＴＰ）メカニズム１３５を含んでもよく、或いは、これに結合されてもよい。一例として、且つ、限定を伴うことなく、ＴＰメカニズムは、Ｉｎｔｅｌ（登録商標） Ａｃｔｉｖｅ Ｍａｎａｇｅｍｅｎｔ Ｔｅｃｈｎｏｌｏｇｙ（Ｉｎｔｅｌ（登録商標） ＡＭＴ）を含んでもよく、或いは、これを実装してもよく、ＡＭＴによれば、装置の電源がオフである際にも、リモートで、装置に対して問合せを行い、装置をリストアし、且つ、装置を保護することができる。ＡＭＴは、ＯＳ１２６、アプリケーションソフトウェア１１０、及びＣＰＵ１２５とは独立的に（即ち、アウトオブバンド（ＯＯＢ）通信を介して）、プラットフォーム１０５に対するアクセスを許容する。更には、ＳＯＣ１３０は、通信リンクプラットフォーム１０５及びその外部環境が安全なものとなることを保証するためのセキュリティメカニズムを含む。一実施形態においては、ＴＰメカニズム１３０は、具体的には、一例として、且つ、限定を伴うことなしに、ＡＭＴファームウェアサービス及びアプリケーションを稼働させるＩｎｔｅｌ（登録商標） Ｍａｎａｇｅｍｅｎｔ Ｅｎｇｉｎｅ（ＭＥ）１３５を含んでもよい。ＭＥ１３５は、プラットフォーム１０５のその他の部分（例えば、メモリ）との間の通信との関連において結合されたネットワークを介してリモートエージェント（例えば、独立系ソフトウェアベンダ（Ｉｎｄｅｐｅｎｄｅｎｔ Ｓｏｆｔｗａｒｅ Ｖｅｎｄｏｒ：ＩＳＶ）、相手先ブランド製造者（Ｏｒｉｇｉｎａｌ Ｅｑｕｉｐｍｅｎｔ Ｍａｎｕｆａｃｔｕｒｅｒ：ＯＥＭ）、情報技術（Ｉｎｆｏｒｍａｔｉｏｎ Ｔｅｃｈｎｏｌｏｇｙ：ＩＴ）部門、ＳＰなど）から受け取ったポリシーを実施するためのマイクロコントローラによって実装されたシステムであってもよい。例えば、システムのスタートアップ（ブート）ポリシーをＯＥＭからＭＥ１３５にダウンロードしてもよい。そして、ＭＥ１３５が、例えば、高信頼性プラットフォームモジュール（ＴＰＭ）及びこれに類似したものの内部のローカルなユーザー設定証明書に照らしてポリシーを評価する。この後に、ＭＥ１３５は、ポリシーの条件が合致した状態にある場合に、プラットフォーム１０５のその他の部分（例えば、メモリ）に対するアクセスを提供してもよい。ＭＥ１３５に関する更なる詳細については、一例として、且つ、限定を伴うことなしに、米国特許第７，６０３，７０７０号及び第７，９３０，７２８号明細書、並びに、ｈｔｔｐ：／／ｄｏｗｎｌｏａｄ．ｉｎｔｅｌ．ｃｏｍ／ｅｍｂｅｄｄｅｄ／ｔｅｃｈｎｏｌｏｇｙ／３２５６４４．ｐｄｆにおいて、且つ、更に一般的には、ｗｗｗ．ｉｎｔｅｌ．ｃｏｍにおいて、提供されている「Ａｄｖａｎｃｅｄ Ｓｅｃｕｒｉｔｙ Ｄｅｓｉｇｎ Ａｓｐｅｃｔｓ ｏｆ ｉ５ ａｎｄ ｉ７ Ｐｒｏｃｅｓｓｏｒｓ （Ｉｎｔｅｌ（Ｒ） ＡＭＴ）： ＷＨＩＴＥ ＰＡＰＥＲ ２ｎｄ ｇｅｎｅｒａｔｉｏｎ Ｉｎｔｅｌ（Ｒ） Ｃｏｒｅ（ＴＭ） ｉ５ ａｎｄ ｉ７ Ｐｒｏｃｅｓｓｏｒｓ Ｉｎｔｅｌ（Ｒ） ｖＰｒｏ（ＴＭ） Ｔｅｃｈｎｏｌｏｇｙ Ｅｍｂｅｄｄｅｄ Ｃｏｍｐｕｔｉｎｇ」において入手可能である。先程示唆したように、ＴＰメカニズム１３５は、ホストＯＳ１２６のネットワークとは独立したＴＣＰ／ＩＰネットワークスタックを含むことにより、アウトオブバンド（Ｏｕｔ−Ｏｆ−Ｂａｎｄ：ＯＯＢ）ネットワーク接続を許容してもよい。

一実施形態においては、プラットフォーム１０５は、証明書保管部（Ｃｒｅｄｅｎｔｉａｌ Ｖａｕｌｔ：ＣＶ）１４０を含み、ＣＶ１４０は、ＴＰメカニズム１３５に更に含まれている。ＣＶ１４０は、一意の強力な多要素証明書を生成すると共に記憶する。

図２との関連において、図１について更に説明する。図２は、本発明の一実施形態における方法を含んでいる。方法２００は、プラットフォーム１０５との間の安全な通信を可能にするべく、単一のユーザー認証イベントを使用し、ユーザーがＳＰに固有の証明書（例えば、それぞれのＳＰ用の一意の強力な証明書）を使用して複数のＳＰに対してアクセスできるようにする。図２は、図１のシステム１００との関連において説明するが、方法の実施形態は、このようなシステムを有する実装形態に限定されるものではない。

ブロック２０５において、ユーザーをＯＯＢ通信を介して（例えば、ＯＯＢチャネル１５５を介して）ホスト１０５に対して認証することにより、ユーザー認証状態を判定している。ＳＯＣ１３０のＯＯＢの能力と、この結果として得られるＯＳ１２６のブーティングからの独立性を考慮することにより、ブロック２０５のユーザー認証は、システムスタートアップの前に（即ち、ブートの前に、又はＯＳ１２６が完全にブートされる前に）、且つ／又は、システムスタートアップの後に（即ち、ブートの後に、又はＯＳ１２６が完全にブートされた後に）、実行してもよい。更には、ＯＯＢの通信能力を考慮した場合に、認証は、部分的に、ソフトウェアアプリケーション１１０及びＯＳ１２６とは独立したＯＯＢ通信を可能にするグラフィカルオーバーレイであるスプライト１１５（例えば、保護されたオーディオ／ビジュアル経路（Ｐｒｏｔｅｃｔｅｄ Ａｕｄｉｏ／Ｖｉｓｕａｌ Ｐａｔｈ：ＰＡＶＰ）スプライト）を介したユーザーからの情報の入力に基づいたものであってもよい。認証情報は、ユニット１２０（指紋スキャナ、網膜スキャナ、音声認識、及びこれらに類似したもの）を介して入力された強力な多要素証明書を含んでもよい。このような情報は、スプライト１１５を介して入力された情報との関連において、又はこれとは独立的に、含まれてもよい。実施形態は、任意の特定の形態の証明書又は証明書の組合せの使用に限定されるものではない。

スプライト１１５に関連し、一実施形態においては、ホスト１２６又は複数ＳＰのうちの１つは、ユーザー経験がＯＳのユーザーインターフェイスのルックアンドフィールと一貫性を有するように、ＰＡＶＰスプライトのビットマップを供給してもよい。このビットマップは、更に後述されるＯＯＢセキュアチャネル１６５又はＯＯＢセキュアチャネル１７０を介して送信してもよい。

更に具体的には、ＯＯＢ通信に関連し、ユーザーは、ヒューマンインターフェイス装置（例えば、指紋スキャナや高信頼性キーボード）とＣＶ１４０の間に安全なチャネルを確立する「高信頼性経路」メカニズム（例えば、ＭＥ）を使用して認証される。ＣＶ１４０のロジックは、ホストＣＰＵ、メモリ、及び入出力（Ｉ／Ｏ）装置から物理的に隔離されたチップセット１３０内のマイクロコントローラ上において稼働している。従って、チップセット１３０に対する通信は、ＯＳ１２６又はソフトウェア１１０を「経由」する必要はない。その代わりに、通信は、「アウトオブバンド」であってもよく、且つ、ＯＳ１２６及びソフトウェア１１０をバイパスしてチップセット１３０に対して直接的に通信してもよい。

ユーザー認証装置をＣＶ１４０に対して（少なくとも一時的に）割り当てることにより、高信頼性経路ユーザー認証を実行してもよい。例えば、ＰＡＶＰは、ホスト１０５とチップセット１３０の間においてパーティション化されるリソースである。ＣＶ１４０は、ＰＡＶＰを使用しているホスト１０５と衝突しないように、チップセットＰＡＶＰリソースを使用する。それぞれの認証装置（例えば、指紋スキャナ）は、リソースをパーティション化して１つのパーティションをチップセットに対して排他的に割り当てなければならない場合もあり、或いは、チップセットが装置をホストから「窃盗」すると共に装置を「返却」できるようにする共有方式を案出してもよい。多くのヒューマンインターフェイス装置は、この観点において状態を有しておらず、従って、窃盗及び返却は、結果的にプログラムエラーをもたらさない。

図２を再度参照すれば、ブロック２１０において、システム１００は、（ブロック２０５において判定された）ユーザー認証状態をホスト１０５上においてローカルに維持しており、この意義については、更に後述する。

ブロック２１５において、システム１００は、ユーザーに対してトランスペアレントに、ユーザーをＳＰ１４５に対して認証するための証明書と、ユーザーをＳＰ１５０に対して認証するための、ＳＰ１４５用の証明書とは等しくない、別の証明書と、を決定（例えば、生成又は選択）している。ＳＰ１４５は、金融クラウドサービスを含んでもよく、且つ、ＳＰ１５０は、電子メールクラウドサービスを含んでもよい。ＳＰ１４５は、ＳＰ１５０をホスティングする別のサーバーとは別個のサーバー上においてホスティングされていてもよい。一実施形態においては、ＣＶ１４０を使用してブロック２１０の証明書を生成している。ＣＶ１４０は、一意の強力な多要素証明書を生成すると共に記憶する。ＴＰモジュール１３５（例えば、ＭＥ）がＣＶ１４０を実装しており、これは、ＭＥファームウェア及びハードウェアによって保護された１つ又は複数のＪａｖａ（登録商標）アプレット及び暗号化キーを有するＪａｖａ（登録商標）仮想マシン（Ｊａｖａ（登録商標） Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ：ＪＶＭ）と、既定の保管部認証ポリシー（更に後述する）と、から構成してもよい。

ブロック２２０において、（例えば、ランダム数生成器を介して）生成された又はブロック２１５において選択された証明書に基づいて、システム１００は、（ユーザーに対して）トランスペアレントに、ＯＯＢ通信を介して（例えば、ＯＯＢ通信チャネル１６５を介して）、ユーザーをＳＰ１４５に対して認証している。又、ブロック２２０においては、ブロック２１５において決定された証明書に基づいて、システム１００は、別のＯＯＢ通信を介して（例えば、ＯＯＢ通信チャネル１７０を介して）、（ユーザーに対して）トランスペアレントに、ユーザーをＳＰ１５０に対して認証している。

従って、ブロック２０５、ブロック２１０、ブロック２１５、及びブロック２２０により、方法２００は、単一のユーザー認証イベント（ブロック２０５）を使用し、ユーザーがＳＰ１４５及びＳＰ１５０の両方に固有の証明書を使用して複数のＳＰ（ＳＰ１４５及びＳＰ１５０）に対してアクセスすることをトランスペアレントに可能にしている。更には、ブロック２０５がユーザーの実際の物理的存在を示す認証（例えば、網膜スキャン）に基づいたものであってもよいことを考慮すれば、プラットフォーム１０５は、ブロック２０５における単一の網膜スキャンに依存することにより、但し、ＳＰ１４５及びＳＰ１５０用の更なる独立的なスキャンに対する必要性を伴うことなしに、ユーザーの物理的存在の証拠をＳＰ１４５及びＳＰ１５０に供給してもよい。

一実施形態は、ブロック２２５を含む。ブロック２２５において、システム１００は、ユーザーに対してトランスペアレントに、且つ、補完的なＯＯＢ通信を介して、ユーザーをＳＰ１４５に対して再認証している。例えば、プラットフォーム１０５とＳＰ１４５の間の安全なセッションが最終的にタイムアウトした場合に、ユーザーが、再度、例えば、多要素証明書を再入力する必要性を伴うことなしに、（部分的に、ブロック２０５において実行された初期認証に基づいて）、再認証を実行してもよい。この再認証は、相対的に容易に処理されることになり、その理由は、ブロック２１０において、ユーザー認証状態が、プラットフォーム１０５上においてローカルに保存されている（例えば、ＴＰモジュール１３５内に含まれている）からである。

又、ユーザー認証状態がプラットフォーム１０５上においてローカルに保存されていることに部分的に起因し、ブロック２３０において、ユーザーは、トランスペアレントに（即ち、更なる多要素証明書の入力をユーザーに対して再度求めることなしに）第３ＳＰ（図１には図示されてはいない）に対してアクセスすることができる。従って、第３ＳＰがＳＰ１４５又はＳＰ１５０と統合されていない場合にも、統合の欠如が克服されるように、ユーザー認証は、プラットフォーム１０５にとってローカルなものになっている。

ブロック２３５において、プラットフォーム１０５は、例えば、個々のチャネル１７５、１８０などのインバンド通信を介して、ＳＰ１４５及びＳＰ１５０と安全に通信してもよい。このようなチャネルは、例えば、インターネットを含む。方法２００における先行するブロックに基づいて、いまや、真の人物が本当の認証プラットフォームの背後に着座しているという信頼性を伴って、インターネットリソースに対するユーザーアクセスの認可を実行することができる。

図３は、本発明の一実施形態における方法３００を含んでいる。方法は、ブロック３０２において始まっており、且つ、ブロック３０４におけるシステムリセットによって後続されている。ブロック３０６において、ＢＩＯＳが、ＴＰ装置１３５内のＭＥなどのハードウェアセキュリティモジュール（ＣＶ１４０を含んでいてもよく、或いは、これに結合されていてもよい）を初期化している。ブロック３０８において、ＢＩＯＳが、ブート前認証（Ｐｒｅ−Ｂｏｏｔ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ：ＰＢＡ）を起動している。ブロック３１２において、ＰＢＡが、ＣＶ１４０内に保存されている既定のＭＦＡポリシーを選択している。ブロック３１４及びブロック３１６において、ユーザーが、ブロック３１２のポリシーによって決定されるいくつかの要素に従って認証している（即ち、プロセスは、すべての必要とされる要素の試験が完了する時点まで、網膜スキャン、指紋スキャンなどの実行を反復する）。認証は、ＭＥ１３５及びＡＭＴ手順などの高信頼性経路技術を使用して進めてもよい。ブロック３１８は、ユーザーが、ブロック３１４において実行された試験に基づいて認証されているかどうかを判定している。

ブロック３２０において、ＣＶ１４０がユーザーの状態を更新している。上述のように、このような情報をローカルに保存することにより、ばらばらのサーバー上においてホスティングされているＳＰを互いに統合する必要性が軽減される。

ブロック３２２において、ＰＢＡがＰＢＡに対するユーザー証明書を放出している。更に具体的には、ＣＶ１４０は、ハードディスクドライブ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ：ＨＤＤ）をアンロックし、ロックされているＵＳＢ装置にアクセスし、且つ、これに類似した動作を行うためにＢＩＯＳによって再生される「証明書」（例えば、パスワード）を維持（保存）している。アクセス対象であるそれぞれのリソース（例えば、ＨＤＤやＵＳＢ装置）についてパスワードを入力するようにユーザーに要求するのではなく、ＣＶ１４０は、必要とされるすべてのパスワードを保存し、且つ、ユーザーを一度だけ認証する。これは、パスワードに基づいたものとすることが可能であり、この場合には、ユーザーが供給するパスワードは、実際のＨＤＤ及びＵＳＢ装置のアンロック動作を実行するために保管部１４０がＢＩＯＳに「放出」するパスワードとは異なっている。

ブロック３２４において、ＰＢＡは、実行をホストＯＳ又はＶＭＭに渡している。ブロック３２６において、ホストプラットフォーム１０５が、ＣＶ１４０を試験し、ホストに対する認証をユーザー状態が反映しているかどうかを判定している。判定結果が否定的である場合には、ホストは、認証についてユーザーに要求してもよく（ブロック３３０）、或いは、最終的にエラーを返すと共に／又は認証を中止してもよい。判定結果が肯定的である場合には、ユーザー証明書がホストに対して放出される（ブロック３３２）。更に詳しくは、ホストＯＳ１２６は、ログイン動作を実行し、且つ、ＣＶ１４０内に保存されているアプリケーション（例えば、電子メール、ファイルパスワード、及びこれらに類似したもの）を有してもよい。ホストアプリケーションは、（アプリケーション開発者によって垂直統合されたファイル内にではなく）ＣＶ１４０内にパスワードを保存するように記述することができる。ブロック３２６は、ユーザーが以前に認証しているかどうかを判定するための試験を含んでいる（例えば、ＢＩＯＳは、ブロック３２２との関連において説明したように、ＨＤＤをアンロックするためにユーザー認証を起動した状態にあってもよい）。判定結果が肯定的である場合には、ＯＳログインの際に、再度、ユーザーに対して要求されることはない。その代わりに、（再度）ユーザーの手を煩わすことなしに、保管部内のパスワードが返される。

ブロック３３４において、ホストが、ＯＯＢ通信チャネルを介してＳＰに対する接続を確立してもよい。従って、いくつかの従来の方法とは対照的に、ＳＰがソフトウェア１１０への安全な通信認証チャネルを確立することはなく、その代わりに、ＳＰは、ＴＰモジュール１３５との間にＯＯＢ通信チャネルを確立する。一実施形態においては、ＴＰモジュール１３５は、第三者リソース（例えば、ＶｅｒｉＳｉｇｎ）を使用してＳＰからの認可証を認証してもよく、且つ、ＳＰとの間の更なる通信は、この認証に基づいたものであってもよい。

ブロック３３６において、ＳＰは、ユーザーの認証をプラットフォーム１０５に対して要求してもよい。ブロック３３８においては、証明が必要とされているかどうかについての判定が実施されている。この判定結果が否定的である場合には、プロセスは、ブロック３４６に進む。判定結果が肯定的である場合には、ブロック３４０において、ホスト１０５がＳＰ参照をＣＶ１４０に転送する。ブロック３４２において、ＣＶ１４０が、ＳＰとの間に安全なＯＯＢセッション（例えば、Ｓｉｇｍａ又はトランスポート層セキュリティ（Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ：ＴＬＳ）プロトコル）を確立している。

ブロック３４４において、Ｓｉｇｍａセッションが、セキュアＩＤを使用し、ＣＶ１４０の信憑性を証明してもよい。このようなＩＤは、一例として、且つ、限定を伴うことなしに、装置所有者のプライバシーを保持しつつ、ハードウェア装置のリモート認証を可能にする暗号化方式であるＥＰＩＤ（Ｅｎｈａｎｃｅｄ Ｐｒｉｖａｃｙ ＩＤ）を含んでもよい。このような状況においては、ＥＰＩＤ方式における１つのパブリックキーは、複数のプライベートキーに対応している。一実施形態においては、ＥＰＩＤは、ＴＰモジュール１３５に永久的に埋め込まれた証明書であってもよい。この結果、ＥＰＩＤは、ＳＰがユーザーの認証状態について別のＳＰと協働することを許容することなしに、ＳＰがプラットフォーム１０５の認可状態を信頼できるようにするプライバシーの影響を受け易いプラットフォーム識別子である。ＥＰＩＤに関する更なる情報については、少なくとも、Ｉｎｔｅｌ Ｔｅｃｈｎｏｌｏｇｙ Ｊｏｕｒｎａｌの２００９年の第１３巻第２号に公開されている「Ｅｎｈａｎｃｅｄ Ｐｒｉｖａｃｙ ＩＤ： Ａ Ｒｅｍｏｔｅ Ａｎｏｎｙｍｏｕｓ Ａｔｔｅｓｔａｔｉｏｎ Ｓｃｈｅｍｅ ｆｏｒ Ｈａｒｄｗａｒｅ Ｄｅｖｉｃｅｓ」に見出すことができる。実施形態は、必ずしも、ＥＰＩＤ又は任意のその他の１パブリックキー／多数プライベートキー方式を必要とするものではない。

ステップ３４０、ステップ３４２、ステップ３４４を更に詳細に観察すれば、パスワードをリモートパーティ（例えば、サービスプロバイダ）に「放出」する際には、ＳＰは、パスワードがホストＯＳ内において攻撃に晒された場合に、パスワードがハードウェア内において保護されるかどうかに関する知識を有していない。証明は、ＭＥが、実際に、パスワードを保護しているハードウェアであることをＭＥがリモートパーティに対して証明できるようにするメカニズムである。ブロック３４０は、トランスポートセッションハンドルを保管部１４０に送っており、トランスポートセッションハンドルは、保管部１４０が保管部１４０とＳＰの間にＳｉｇｍａセッション（又は、その他の保護されたセッション）をオープンできるようにする。Ｓｉｇｍａセッションは、符号付きＤｉｆｆｉｅ−Ｈｅｌｌｍａｎキー交換プロトコルを含んでもよく、この場合に、署名は、ＥＰＩＤを使用して実行される。Ｓｉｇｍａの１つの特性は、証明情報を含んでいるという点にある。一実施形態における証明は、保管部環境と、保管部内に収容されている１つ又は複数のパスワードと、のためのものであってもよい。証明においては、パスワードのハッシュを供給してもよく、これにより、ＳＰは、ハッシュを、アプリケーションに対して後で放出される実際のパスワードと比較することができる（例えば、ブロック３５８を参照されたい）。

方法３００を再度参照すれば、ブロック３４４において、ＣＶ１４０のハードウェア証明をＥＰＩＤを使用して実現している。これは、ユーザーに対するＴＰ認証メカニズム（例えば、ＰＡＶＰ）を実装するユニット１３５（例えば、ＭＥ）に少なくとも部分的に基づいている。又、これは、サービスプロバイダに対する安全なチャネルをも実装し、且つ、ユーザー証明書（例えば、パスワード）を管理するための安全な実行環境をも実装する。この結果、ＳＰは、ユーザーの証明及び認証を定量化するためのポリシーを実施するべく、ＴＰ１３５を必要とする可能性がある。例えば、ＳＰは、有効なプラットフォームがＳＰのバックエンドサービスと通信していることを保証するべく、ＴＰモジュール１３５からのＯＴＰと結合されたＣＰＵ１２５からのＥＰＩＤを必要とする可能性がある。この結果、ＳＰは、ＣＶ１４０をアンロックするために有効なＰＩＮをエンドユーザーが入力することを必要とする可能性がある。一実施形態においては、チャネル１９０、１９５を介して更なる機械１８５（例えば、サーバー）により、ＥＰＩＤを検証してもよい。

ブロック３４６において、ＳＰは、ユーザーの認証状態についてＣＶ１４０を試験している。ブロック３４８において、ユーザーが認証されていない場合には、プロセスは、エラーを返してもよい。但し、ユーザーが認証されている場合には、ブロック３５０において、ＳＰが優位な（即ち、ＣＶ１４０内に保存されている既定のＭＦＡポリシー内のもの以外の要素及び／又はそれらほどには厳格ではない要素を必要とする）ＭＦＡポリシーを有しているかどうかを判定している。判定結果が肯定的である場合には、方法は、ブロック３５６に進む。さもなければ、ブロック３５２において、ＣＶ１４０は、高信頼性経路を介して、認証するようにユーザーに対して要求する。このような情報の入力は、ＴＰモジュール１３５がＣＰＵ１２５上において稼働しているソフトウェア１１０の外部においてデータをユーザーに対して安全に提示することができるように、ＴＰモジュール１３５のグラフィックオーバーレイ機能（例えば、スプライト１１５）を介して入力してもよい（プロセスは、すべての要素が吟味される時点まで、ブロック３５４を介して反復してもよい。すべての要素が吟味されたら、ブロック３５０は、ブロック３５６に進んでもよい）。従って、ＴＰモジュール１３５は、キーボード及び／又はマウスのクリックを安全に収集することができる。エンドユーザーがＣＶ１４０をアンロックしたら、ＴＰモジュール１３５は、強力な一意の且つ長いパスワードを使用してＳＰに対して再認証することができる。要素認証は、必要に応じて、優位なポリシーに従って反復してもよい。

ブロック３５６において、ＣＶ１４０がユーザー状態を更新している。ブロック３５８において、（ＳＰ用の）ユーザーの証明書をＳＰに対して放出している。この結果、ウェブサーバーとの間の接続をオープンしているアプリケーション（例えば、ブラウザ）は、ウェブサーバーにパスワードを供給することができる。ユーザーが以前に（例えば、ブロック３１８におけるＢＩＯＳにおいて、或いは、ブロック３２８におけるＯＳログインの際に）認証している場合には、認証するようにユーザーに対して再度要求しなくてもよい。むしろ、まず、ブロック３４８及び３５０において、状態がチェックされる。状態が許容している場合には、ウェブへのログインという課題を完了させるために、ウェブサービスに固有のパスワードが「放出」されると共にブラウザに対して再生される。

ブロック３６０において、フローは、呼出し元のエンティティ（例えば、ブラウザ）に継続し、且つ、方法は終了する。

従って、様々な実施形態は、ユーザーがブート前とブート後の間の遷移の際に自動的に再認証する必要がないように、ブート前及びブート後の環境において利用可能な証明書を伴う多要素認証の使用可能性を提供している。この結果、例えば、反復的に複数の認証要素及び強力なパスワードを入力すると共に／又は維持することに関連するユーザーの疲労／フラストレーションの低減に起因し、ユーザー経験が改善される。

又、上述のように、チップセット／ＳＯＣ及び「アンコア」ハードウェア内において実装された高信頼性経路メカニズム（例えば、ＡＬＵ、ＦＰＵ、Ｌ１及びＬ２キャッシュなどのコア内には存在しないマイクロプロセッサの機能）に基づいて、エンドユーザー認証イベントの保護が促進されている。ユーザー認証イベント及び証明書との関連付けは、継続的に保護されており、これにより、ユーザーが認証されていない際にも有効な証明書を再生する中間ブラウザ攻撃（ｂｒｏｗｓｅｒ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ ａｔｔａｃｋ）の脅威が低減される。

又、高信頼性経路メカニズムに関連し、いくつかの実施形態においては、ＭＥ内において統合された証明書保管部及びＥＰＩＤを使用して認証状態の証明を実現しており、これにより、アイデンティティの盗難（例えば、正当なユーザーを装うクライアントサイドのマルウェア）のリスクを低減している。又、証明書が、ホストメモリ又はマルウェア含むＣＰＵ上において実行されるソフトウェアに晒されないことから、ＭＥ内における証明書の保存の強化も存在している。

又、自動化及び強力なパスワードの使用は、ユーザーに対してトランスペアレントである。実施形態は、いくつかの実施形態においては再使用不能な強力なパスワードを生成しており、これにより、リモートＳＰによるインサイダ攻撃のリスクを低減している。

実施形態は、多くの異なるシステムタイプにおいて実装してもよい。次に図４を参照すれば、本発明の一実施形態によるシステムのブロックダイアグラムが示されている。マルチプロセッサシステム５００は、ポイントツーポイント相互接続システムであり、且つ、ポイントツーポイント相互接続５５０を介して結合された第１プロセッサ５７０と第２プロセッサ５８０を含む。プロセッサ５７０及び５８０のそれぞれは、図１との関連において更に記述されているように、マルチコアプロセッサであってもよく、且つ、プロセッサ１２５内に含まれてもよい。「プロセッサ」という用語は、レジスタ及び／又はメモリからの電子データを処理してその電子データをレジスタ及び／又はメモリ内に保存してもよいその他の電子データに変換する任意の装置又は装置の部分を意味してもよい。第１プロセッサ５７０は、メモリコントローラハブ（Ｍｅｍｏｒｙ Ｃｏｎｔｒｏｌｌｅｒ Ｈｕｂ：ＭＣＨ）及びポイントツーポイント（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ：Ｐ−Ｐ）インターフェイスを含んでもよい。同様に、第２プロセッサ５８０も、ＭＣＨ及びＰ−Ｐインターフェイスを含んでもよい。ＭＣＨは、プロセッサを個々のメモリに、即ち、メモリ５３２及びメモリ５３４に、結合しており、これらのメモリは、個々のプロセッサにローカルに装着されたメインメモリ（例えば、ダイナミックランダムアクセスメモリ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ：ＤＲＡＭ））の一部分であってもよい。第１プロセッサ５７０及び第２プロセッサ５８０は、それぞれ、Ｐ−Ｐ相互接続を介してチップセット５９０に結合されてもよい。チップセット５９０は、図１との関連において更に記述されているように、Ｐ−Ｐインターフェイスを含んでもよく、且つ、ＳＯＣ１３０、ＭＥ又は「セキュリティエンジン」１３５、ＣＶ１４０という要素を含んでもよい。セキュリティエンジンは、ＭＥのサブタスクであるか、ＭＥの安全実行モードであるか、又はチップセット内の個別のマイクロコントローラであってもよいであろう。チップセット５９０は、ホストＯＳ１２６には「立ち入り禁止」であると共に入出力（Ｉ／Ｏ）装置によってＤＭＡアクセスから隔離されたスタティックＲＡＭ及びフラッシュメモリを含んでもよい。更には、チップセット５９０は、インターフェイスを介して第１バス５１６に結合されてもよい。第１バス５１６を第２バス５２０に結合するバスブリッジ５１８と共に、様々な入出力装置５１４を第１バス５１６に結合してもよい。例えば、キーボード／マウス５２２、通信装置５２６、並びに、一実施形態においては、コード５３０を含んでもよいディスクドライブ又はその他のマスストレージ装置などのデータストレージユニット５２８を含む様々な装置を第２バス５２０に結合してもよい。更には、オーディオ入出力５２４を第２バス５２０に結合してもよい。

実施形態は、コードとして実装してもよく、且つ、命令を実行するようにシステムをプログラムするために使用可能な命令をその上部に保存された状態において有する一時的ではない保存媒体上に保存してもよい。保存媒体は、限定を伴うことなしに、フロッピー（登録商標）ディスク、光ディスク、半導体ドライブ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ：ＳＳＤ）、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−ＲＷ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅｗｒｉｔａｂｌｅ）、及び磁気光ディスクを含む任意のタイプのディスク、ＲＯＭ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）などのＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）、フラッシュメモリ、ＥＥＰＲＯＭ（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ）などの半導体装置、磁気又は光カード、或いは、電子的命令を保存するのに適した任意のその他のタイプの媒体を含んでもよい。本発明の実施形態は、本明細書においては、命令、機能、手順、データ構造、アプリケーションプログラム、構成設定、コード、及びこれらに類似したものなどのデータを参照して記述されている場合がある。データが機械によってアクセスされる際に、機械は、本明細書に更に詳細に記述されているように、タスクを実行し、抽象的なデータタイプを定義し、低レベルのハードウェアコンテキストを確立し、且つ／又は、その他の動作を実行することにより、応答してもよい。データは、揮発性及び／又は不揮発性のデータストレージに保存してもよい。「コード」又は「プログラム」という用語は、アプリケーション、ドライバ、プロセス、ルーチン、方法、モジュール、及びサブプログラムを含む広範囲のコンポーネント及び構造体をカバーしており、且つ、処理システムによって実行された際に望ましい１つ又は複数の動作を実行する命令の任意の集合体を意味してもよい。更には、代替実施形態は、開示されている動作のうちの一部を使用するプロセス、更なる動作を使用するプロセス、同一の動作を異なる順序において使用するプロセス、本明細書に開示されている個々の動作が組み合わせられるか、サブ分割されるか、或いは、その他の方法で変更されたプロセスを含んでもよい。コンポーネント又はモジュールは、必要に応じて組み合わせてもよく、或いは、分離してもよく、且つ、装置の１つ又は複数の部分内に位置決めしてもよい。

本発明は、限られた数の実施形態を参照して記述されているが、当業者であれば、これらの実施形態から多数の変更及び変形について理解することになろう。添付の請求項は、本発明の真の精神及び範囲に含まれるそれらのすべての変更及び変形を含むものと解釈されたい。
［項目１］
命令を含む一時的ではない機械アクセス可能保存媒体を有する物品であって、
上記命令は、実行された際に、システムが、
ホストに対してユーザーを認証してユーザー認証状態を判定し、
上記ユーザー認証状態及び第１アウトオブバンド（ＯＯＢ）通信を介して第１サービスプロバイダに対して上記ユーザーをトランスペアレントに認証し、且つ、
上記ユーザー認証状態及び第２ＯＯＢ通信を介して第２サービスプロバイダに対して上記ユーザーをトランスペアレントに認証する、
ことを可能にする、物品。
［項目２］
上記ホストに対して上記ユーザーを認証するステップは、証明書保管部に対して上記ユーザーを認証するステップを含む項目１に記載の物品。
［項目３］
上記システムが、上記ユーザーに対してトランスペアレントに、（ａ）上記第１サービスプロバイダに対して上記ユーザーを認証するための第１証明書と、（ｂ）上記第２サービスプロバイダに対して上記ユーザーを認証するための、上記第１証明書とは等しくない、第２証明書と、を決定することを可能にする命令を含む項目１に記載の物品。
［項目４］
上記システムが、上記第１及び第２ＯＯＢ通信のそれぞれを介して上記第１及び第２サービスプロバイダに対して上記ユーザーを認証した後に、インバンド通信を介して上記第１及び第２サービスプロバイダと通信することを可能にする命令を含む項目１に記載の物品。
［項目５］
上記システムが、上記ユーザーに対してトランスペアレントに、且つ、別のＯＯＢ通信を介して、上記第１サービスプロバイダに対して上記ユーザーを再認証することを可能にする命令を含む項目１に記載の物品。
［項目６］
上記システムが、別のＯＯＢ通信を介して伝達されたスプライトを介して上記ホストに対して上記ユーザーを認証することを可能にする命令を含む項目１に記載の物品。
［項目７］
上記システムが、上記ホスト上においてローカルに上記ユーザー認証状態を維持することを可能にする命令を含む項目１に記載の物品。
［項目８］
上記第１サービスプロバイダは、第１サーバーによってホスティングされ、上記第２サービスプロバイダは、第２サーバーによってホスティングされ、且つ、上記第１サーバーは、上記第２サーバーと統合されていない項目１に記載の物品。
［項目９］
上記システムが、上記ホストが完全にブートされる前に、上記ホストに対して上記ユーザーを認証することを可能にする命令を含む項目１に記載の物品。
［項目１０］
上記システムが、上記ホストに永久的に埋め込まれた証明書に基づいて、上記第１及び第２サービスプロバイダの両方に対して上記ユーザーを認証することを可能にする命令を含む項目１に記載の物品。
［項目１１］
上記システムが、ハードウェアセキュリティモジュール（ＨＳＷ）に対する更なるＯＯＢ通信を介して、上記ホストに対して上記ユーザーを認証することを可能にする命令を含む項目１に記載の物品。
［項目１２］
ホストに対してユーザーを認証してユーザー認証状態を判定するステップと、
上記ユーザー認証状態及び第１アウトオブバンド（ＯＯＢ）通信を介して第１サービスプロバイダに対して上記ユーザーをトランスペアレントに認証するステップと、
上記ユーザー認証状態及び第２ＯＯＢ通信を介して第２サービスプロバイダに対して上記ユーザーをトランスペアレントに認証するステップと、
を有する方法。
［項目１３］
上記ホストに対して上記ユーザーを認証するステップは、証明書保管部に対して上記ユーザーを認証するステップを含む項目１２に記載の方法。
［項目１４］
上記ホスト上においてローカルに上記ユーザー認証状態を維持するステップを含む項目１２に記載の方法。
［項目１５］
上記第１サービスプロバイダは、第１サーバーによってホスティングされ、上記第２サービスプロバイダは、第２サーバーによってホスティングされ、且つ、第１サーバーは、上記第２サーバーと統合されていない項目１２に記載の方法。
［項目１６］
上記ホストが完全にブートされる前に、上記ホストに対して上記ユーザーを認証するステップを含む項目１５に記載の方法。
［項目１７］
システムであって、
メモリと、
（ａ）ユーザー認証状態を判定するためにホストに対してユーザーを認証し、（ｂ）上記ユーザー認証状態及び第１アウトオブバンド（ＯＯＢ）通信を介して第１サービスプロバイダに対して上記ユーザーをトランスペアレントに認証し、且つ、（ｃ）上記ユーザー認証状態及び第２ＯＯＢ通信を介して第２サービスプロバイダに対して上記ユーザーをトランスペアレントに認証するべく、上記メモリに結合されたプロセッサと、
を有するシステム。
［項目１８］
上記ホストに対して上記ユーザーを認証するステップは、証明書保管部に対して上記ユーザーを認証するステップを含む項目１７に記載のシステム。
［項目１９］
上記ユーザー認証状態は、上記ホスト上においてローカルに且つ上記メモリ内において維持される項目１７に記載のシステム。
［項目２０］
上記プロセッサは、上記ホストが完全にブートされる前に、上記ホストに対して上記ユーザーを認証する項目１７に記載のシステム。

１００ システム
１０５ プラットフォーム
１１０ アプリケーションソフトウェア
１１５ スプライト
１２０ ユニット
１２５ 中央処理装置（ＣＰＵ）
１３０ システムオンチップ（Ｓｙｓｔｅｍ−Ｏｎ−ａ−Ｃｈｉｐ：ＳＯＣ）
１４５ ＳＰ
１５０ ＳＰ
１５５ ＯＯＢチャネル
１６５ ＯＯＢセキュアチャネル
１７０ ＯＯＢセキュアチャネル
１７５ チャネル
１８０ チャネル
１８５ 機械
１９０ チャネル
１９５ チャネル

Claims (20)

1. 少なくとも１つのプロセッサによって実行される認証方法であって、
   ホストに対してユーザーを認証してユーザー認証状態を判定するステップと、
   前記ユーザー認証状態及び第１アウトオブバンド（ＯＯＢ）通信を介して第１サービスプロバイダに対して前記ユーザーをトランスペアレントに認証するステップと、
   前記ユーザー認証状態及び第２ＯＯＢ通信を介して第２サービスプロバイダに対して前記ユーザーをトランスペアレントに認証するステップと、
   を有する方法。
2. 前記ホストに対して前記ユーザーを認証するステップは、証明書保管部に対して前記ユーザーを認証するステップを含む請求項１に記載の方法。
3. 前記ユーザーに対してトランスペアレントに、（ａ）前記第１サービスプロバイダに対して前記ユーザーを認証するための第１証明書と、（ｂ）前記第２サービスプロバイダに対して前記ユーザーを認証するための、前記第１証明書とは等しくない、第２証明書と、を決定するステップを有する請求項１または請求項２に記載の方法。
4. 前記第１及び第２ＯＯＢ通信のそれぞれを介して前記第１及び第２サービスプロバイダに対して前記ユーザーを認証した後に、インバンド通信を介して前記第１及び第２サービスプロバイダと通信するステップを有する請求項１から請求項３のいずれか１つに記載の方法。
5. 前記ユーザーに対してトランスペアレントに、且つ、別のＯＯＢ通信を介して、前記第１サービスプロバイダに対して前記ユーザーを再認証するステップを有する請求項１から請求項４のいずれか１つに記載の方法。
6. 別のＯＯＢ通信を介して伝達されたスプライトを介して前記ホストに対して前記ユーザーを認証するステップを有する請求項１から請求項５のいずれか１つに記載の方法。
7. 前記ホスト上においてローカルに前記ユーザー認証状態を維持するステップを有する請求項１から請求項６のいずれか１つに記載の方法。
8. 前記第１サービスプロバイダは、第１サーバーによってホスティングされ、前記第２サービスプロバイダは、第２サーバーによってホスティングされ、且つ、前記第１サーバーは、前記第２サーバーと統合されてはいない請求項１から請求項７のいずれか１つに記載の方法。
9. 前記ホストが完全にブートされる前に、前記ホストに対して前記ユーザーを認証するステップを有する請求項１から請求項８のいずれか１つに記載の方法。
10. 前記ホストに永久的に埋め込まれた証明書に基づいて、前記第１及び第２サービスプロバイダの両方に対して前記ユーザーを認証するステップを有する請求項１から請求項９のいずれか１つに記載の方法。
11. ハードウェアセキュリティモジュール（ＨＳＷ）に対する更なるＯＯＢ通信を介して、前記ホストに対して前記ユーザーを認証するステップを有する請求項１から請求項１０のいずれか１つに記載の方法。
12. コンピュータ請求項１から請求項１１のいずれか１つに記載の方法を実行させるためのプログラム。
13. 認証のための処理システムであって、
    ホストに対してユーザーを認証してユーザー認証状態を判定する手段と、
    前記ユーザー認証状態及び第１アウトオブバンド（ＯＯＢ）通信を介して第１サービスプロバイダに対して前記ユーザーをトランスペアレントに認証する手段と、
    前記ユーザー認証状態及び第２ＯＯＢ通信を介して第２サービスプロバイダに対して前記ユーザーをトランスペアレントに認証する手段と
    を備えるシステム。
14. 前記ホストに対して前記ユーザーを認証する前記手段は、証明書保管部に対して前記ユーザーを認証する手段を備える請求項１３に記載のシステム。
15. 前記ユーザーに対してトランスペアレントに、（ａ）前記第１サービスプロバイダに対して前記ユーザーを認証するための第１証明書と、（ｂ）前記第２サービスプロバイダに対して前記ユーザーを認証するための、前記第１証明書とは等しくない、第２証明書と、を決定する手段を備える請求項１３または請求項１４に記載のシステム。
16. 前記第１及び第２ＯＯＢ通信のそれぞれを介して前記第１及び第２サービスプロバイダに対して前記ユーザーを認証した後に、インバンド通信を介して前記第１及び第２サービスプロバイダと通信する手段を備える請求項１３から請求項１５のいずれか１つに記載のシステム。
17. 前記ユーザーに対してトランスペアレントに、且つ、別のＯＯＢ通信を介して、前記第１サービスプロバイダに対して前記ユーザーを再認証する手段を備える請求項１３から請求項１６のいずれか１つに記載のシステム。
18. 別のＯＯＢ通信を介して伝達されたスプライトを介して前記ホストに対して前記ユーザーを認証する手段を備える請求項１３から請求項１７のいずれか１つに記載のシステム。
19. 前記ホスト上においてローカルに前記ユーザー認証状態を維持する手段を備える請求項１３から請求項１８のいずれか１つに記載のシステム。
20. 前記ホストが完全にブートされる前に、前記ホストに対して前記ユーザーを認証する手段を備える請求項１３から請求項１９のいずれか１つに記載のシステム。

Images