(57)【要約】【課題】クライアント側の入力装置から商業者のサーバへセキュリティを提供する信頼された取引のアーキテクチャを提供する。【解決手段】ＡｃｔｉｖｅＸコントロールまたはその同等物を介して、クライアント側コンピュータにセキュアカスタムブラウザプロセスをインストールする。次に、このセキュアブラウザプロセスを検査して、そのアプリケーション記憶領域に外部コードが存在しないことと、後にロードされたダイナミックリンクライブラリ（ＤＬＬ）もしくはその同等物が改ざんまたは変更されていないことと、アプリケーションプログラミングインタフェースが上書きまたはリダイレクトされていないことと、入力装置のドライバがデジタル署名によってフックされていないこととを確認する。【選択図】図１４
2010517170.tif 000002
【特許請求の範囲】
【請求項１】
ブラウザのアプリケーション内においてセキュアなブラウザプロセスを提供するセキュアなシステムローダと、
前記セキュアなシステムローダ内で実行されて、前記セキュアなブラウザプロセスに対するセキュリティ確認を提供するシステムインスペクタと、
前記セキュアなブラウザプロセスによってユーザ入力装置から宛先サーバへの信頼された通信を提供する、少なくとも１つのセキュアな入力チャネルとを備えた、信頼された取引の提供システム。
【請求項２】
請求項１において、前記セキュアなシステムローダが、前記ブラウザのアプリケーションにダイナミックリンクライブラリをインストールする、信頼された取引の提供システム。
【請求項３】
請求項２において、前記ダイナミックリンクライブラリがブラウザヘルパーオブジェクトである、信頼された取引の提供システム。
【請求項４】
請求項２において、前記システムインスペクタは、前記セキュアなブラウザプロセスにロードされた前記ダイナミックリンクライブラリが変更されているかを判別する、信頼された取引の提供システム。
【請求項５】
請求項１において、前記システムインスペクタは、いずれかのカーネルアプリケーションプログラミングインタフェースが変更されているかを判別する、信頼された取引の提供システム。
【請求項６】
請求項１において、前記セキュアなブラウザプロセスは、通信が標準オペレーティングシステムの構成要素にさらされる前に、この通信を暗号化する、信頼された取引の提供システム。
【請求項７】
請求項１において、前記少なくとも１つのセキュアなチャネルが、前記ユーザ入力装置と前記セキュアなブラウザプロセスとの間の第１のセキュアなチャネルと、前記セキュアなブラウザプロセスと前記宛先サーバとの間の第２のセキュアなチャネルとを有する、信頼された取引の提供システム。
【請求項８】
請求項１において、前記ユーザ入力装置がキーボードである、信頼された取引の提供システム。
【請求項９】
ブラウザのアプリケーション内においてセキュアなブラウザプロセスをインスタンス化する工程と、
前記セキュアなブラウザプロセスに対するセキュリティ確認を提供するように、前記セキュアなブラウザプロセスの構成要素を検査する工程と、
前記セキュアなブラウザプロセスによってユーザ入力装置から宛先サーバへの少なくとも１つのセキュアなチャネルを生成する工程とを備えた、信頼された取引の提供方法。
【請求項１０】
請求項９において、前記セキュアなブラウザプロセスをインスタンス化する工程が、前記ブラウザアプリケーション内にダイナミックリンクライブラリをインストールする工程を有する、信頼された取引の提供方法。
【請求項１１】
請求項１０において、前記ダイナミックリンクライブラリがブラウザヘルパーオブジェクトである、信頼された取引の提供方法。
【請求項１２】
請求項１０において、前記セキュアなブラウザプロセスの構成要素を検査する工程が、前記セキュアなブラウザプロセスにロードされた前記ダイナミックリンクライブラリが変更されているかを判別する工程を有する、信頼された取引の提供方法。
【請求項１３】
請求項９において、前記セキュアなブラウザプロセスの構成要素を検査する工程が、いずれかのカーネルアプリケーションプログラミングインタフェースが変更されているかを判別する工程を有する、信頼された取引の提供方法。
【請求項１４】
請求項９において、さらに、通信が標準オペレーティングシステムの構成要素にさらされる前に、この通信を暗号化する工程を備えた、信頼された取引の提供方法。
【請求項１５】
請求項９において、前記少なくとも１つのセキュアなチャネルを生成する工程が、前記ユーザ入力装置と前記セキュアなブラウザプロセスとの間に第１のセキュアなチャネルを生成する工程と、前記セキュアなブラウザプロセスと前記宛先サーバとの間に第２のセキュアなチャネルを生成する工程とを有する、信頼された取引の提供方法。
【請求項１６】
請求項９において、前記ユーザ入力装置がキーボードである、信頼された取引の提供方法。
【請求項１７】
信頼された取引を提供するために、内部に埋め込まれたコンピュータ読取り可能なプログラムコードを有するコンピュータ読取り可能媒体であって、
前記コンピュータ読取り可能媒体のプログラムコードは命令を含み、この命令が１つ以上のプロセッサによって実行されると、前記プロセッサは、個別または複数で共同して、
ブラウザのアプリケーション内においてセキュアなブラウザプロセスをインスタンス化し、
前記セキュアなブラウザプロセスに対するセキュリティ確認を提供するように、前記セキュアなブラウザプロセスの構成要素を検査し、
前記セキュアなブラウザプロセスによってユーザ入力装置から宛先サーバへの少なくとも１つのセキュアなチャネルを生成する、コンピュータ読取り可能媒体。
【請求項１８】
請求項１７において、前記セキュアなブラウザプロセスをインスタンス化する命令が、前記ブラウザアプリケーション内にダイナミックリンクライブラリをインストールする、コンピュータ読取り可能媒体。
【請求項１９】
請求項１８において、前記セキュアなブラウザプロセスの構成要素を検査する命令が、前記セキュアなブラウザプロセスにロードされた前記ダイナミックリンクライブラリが変更されているかを判別する、コンピュータ読取り可能媒体。
【請求項２０】
請求項１７において、さらに、通信が標準オペレーティングシステムの構成要素にさらされる前に、この通信を暗号化する命令を備えた、コンピュータ読取り可能媒体。
【請求項２１】
請求項１７において、前記少なくとも１つのセキュアなチャネルを生成する命令が、前記ユーザ入力装置と前記セキュアなブラウザプロセスとの間に第１のセキュアなチャネルを生成する命令と、前記セキュアなブラウザプロセスと前記宛先サーバとの間に第２のセキュアなチャネルを生成する命令とを有する、コンピュータ読取り可能媒体。
【発明の詳細な説明】
【関連出願】
【０００１】
本願は、2007年1月26日付で出願された米国特許仮出願第60/897,729号の優先権を主張する。上記出願の全教示は、参照により本明細書に引用したものとする。
【技術分野】
【０００２】
本発明は、エンドユーザ（クライアント側）が不正侵入されている（攻撃されている、感染されている）との仮定の下に、エンドユーザとウェブサイト（例えば、商業者によって運営されているウェブサイト）の間の信頼された相互作用を実現する。
【背景技術】
【０００３】
インターネットは、商業者と顧客との間の取引実行のために、これまでにない利便性を提供している。しかし、このような取引の安全性は、依然として極めて深刻な問題である。キーロギングする（キーボードのタイピング履歴を記録する）「トロイの木馬」というソフトウェアは、犯罪者が好んで使う武器の１つであり続けている。ＭｃＡｆｅｅ（登録商標）によると、キーロギングするマルウェア（悪意のソフトウェア）のインストール数は、2004年から2006年の間に２５０％増加し、フィッシング攻撃の数は同じ期間に１００倍増加したと推定される。
【０００４】
近年、オンラインによる株式取引会社は、高度に組織化された犯罪グループによって特にひどい痛手を受け、数千万ドルの赤字を計上している。このような犯罪手口の１つでは、泥棒は、単に、キーロガーを用いて見込みのある標的の銀行口座証明書を盗むのではなく、ハイジャックした口座や不正に作成したダミー口座を用いて、オンライン証券口座を標的としている。犯罪者は、数ヶ月間にわたる一連の取引において、少数しか売買されていない証券を購入する。これらの取引は人為的に株価をつり上げて、詐欺が発見される前に、泥棒は利潤を上乗せして株を売却する。この「株価操作」の犯罪手口は、例えば、Ｅ−Ｔｒａｄｅ（登録商標）などの名の通ったインターネット証券会社の顧客を標的としてきた。
【０００５】
今まで証券会社は、日常的にユーザの損失を証券会社自体の資金で埋め合わせてきており、格別な安全対策を組み込む方法を捜し求めている。これらの安全対策は、主として、証券会社が不審な取引をより迅速に見抜くことを可能にする詐欺防止技術を利用することについてあれこれ思案している。別のアプローチでは、証券会社は顧客にハードウェアキーつまり「ドングル」を提供することによって、変更のないログイン証明書によって引き起こされるセキュリティリスクを取り除くことを期待して、いわゆる「二因子（二要素）」認証を行っている。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
必要とされるのは、クライアント側がトロイの木馬やキーロガーなどのマルウェア（悪意のあるソフトウェア）によって侵入つまり攻撃されていると間違いなく推定される場合に、エンドユーザ（クライアント側コンピュータ）と商業者のウェブサイトとの間で信頼された取引を実現する方法である。
【課題を解決するための手段】
【０００７】
本発明は、多数の技術の発展を統合することによって、クライアント側のユーザのキーボード（または他の入力装置）から商業者のサーバへセキュリティを提供する。
【０００８】
信頼された取引を提供するために、キーボードからアプリケーションへのデータフローは、エンド・ツー・エンドで保護されている。ユーザ入力を取得する際に、標準オペレーティングシステム（標準仕様のオペレーティングシステム）手段を用いることを避ける手段が講じられる。このためには、証券泥棒には周知である通常のオペレーティングシステムのアプリケーションプログラミングインタフェース（ＡＰＩ）のような任意の標準オペレーティングシステム機構を通過せずに、キーボード（または他の入力装置）のハードウェアにアクセスすることが必要とされる。一実施形態においては、これは、エンドユーザのマシンにインストールされているキーボードミニポートまたはキーボードクラスドライバに直接接続しているカスタムキーボードドライバ（特別キーボードドライバ）または低レベルのキーボード監視ドライバを用いて達成される。別のアプローチとして、これに限定されるわけではないが、他の永続的にセキュアなコードインジェクション（コード挿入）手法、例えば、Ｖｅｒｄａｓｙｓ（登録商標）社（本発明の譲受人）が販売するＤｉｇｉｔａｌ  Ｇｕａｒｄｉａｎ（登録商標）が挙げられる。
【０００９】
キーボードからアプリケーションへのデータフローをセキュリティ保護することに加えて、セキュアな（セキュリティ保護された、例えば暗号化された）ウェブブラウザ環境が提供される。これは、ＡｃｔｉｖｅＸコントロールまたはその同等物を経由して、ローカルマシンにセキュアなカスタムブラウザのプロセスをインストールすることによって実現されてもよい。そして、このセキュアなブラウザプロセス（ＳＢＰ）は、セキュアなブラウザプロセスのアプリケーション記憶領域に外部コードが存在しないことを保証するために試験（検査）される。これを確認するために、ＳＢＰは、後でロードされた任意のダイナミックリンクライブラリ（ＤＬＬ）もしくはその同等物が改ざんまたは変更されているかを検査する。同様に、ＳＢＰは、任意のカーネルＡＰＩが上書きまたはリダイレクト（redirect）されているかを判別してもよい。セキュアなキーボードドライバも検査されて、デジタル署名を用いた任意の方法によって、暗号ハッシュ（例えば、ＭＤ５、ＳＨＡ１など）などで、そのロードされた画像がフック（入力を横取りして独自処理を行うこと）されていないことを保証してもよい。この方法により、システムは、システム自体のセキュアキーボードドライバから入力を受け取ることを保証してもよい。環境が確認されると、外部ＡＰＩがブロックされ、ブラウザのプラグインはロードされていない状態で、ＳＢＰはセキュアなブラウザオブジェクトをインスタンス化する。
【００１０】
次に、ＳＢＰは、データをアプリケーションに入力するために用いられる入力装置に対するセキュアなチャネル（プロキシ）を生成し、商業者の宛先サーバに対するセキュアなチャネル（プロキシ）を生成して、ローカルマシン上であってもデータを傍受できないことを保証する。
【００１１】
このようにして、確認されたシステムローダ、システムインスペクタ、セキュアな入力チャネル、セキュアな通信チャネル、セキュアな認証システム、およびセキュアなブラウザ環境を用いることによって、完全なレイヤソリューション（階層構造によるソリューション）が提供される。
【００１２】
上述の内容は、添付図面に示す本発明の例示的な実施形態に関する以下のより詳細な説明から明らかとなろう。図面では、同様の参照符合は異なる図面であっても同一部品を指す。これらの図面は必ずしも縮尺通りではなく、代わり、本発明の実施形態を示すことに重点が置かれている。
【図面の簡単な説明】
【００１３】
【図１】インターネットブラウザへの顧客ＤＬＬ（ダイナミックリンクライブラリ）の挿入を示すブロック図である。
【図２】挿入されたＤＬＬからサーバへの情報の送信を示すブロック図である。
【図３】キーボード、マウスなどの入力装置からアプリケーションへの正常なデータフローを示すフローチャートである。
【図４】キーボード、マウスなどの入力装置から、セキュア入力チャネルを経由したセキュアブラウザプロセスへのデータフローを示すブロック図である。
【図５】商業者のウェブページを示す高レベル図である。
【図６】セキュアブラウザホスト（ＳＢＨ）ＡｃｔｉｖｅＸコントロールを参照する埋め込みオブジェクトを含む、ウェブページを示す高レベル図である。
【図７】セキュアブラウザプロセス（ＳＢＰ）の初期化を示す高レベル図である。
【図８】セキュリティ確認を提供するためのセキュアブラウザプロセス（ＳＢＰ）の検査を示す高レベル図である。
【図９】埋め込みブラウザオブジェクトの初期化を示す高レベル図である。
【図１０】入力装置に対するセキュア入力チャネルの生成を示す高レベル図である。
【図１１】宛先サーバに対するセキュア通信チャネルの生成を示す高レベル図である。
【図１２】標準的通信アーキテクチャにおける通信のフローを示すフローチャートである。
【図１３】標準的オペレーティングシステムの構成要素を通過する前の通信の暗号化を示すフローチャートである。
【図１４】信頼された取引のアーキテクチャを示す高レベル図である。
【発明を実施するための形態】
【００１４】
本発明の例示的な実施形態を以下に説明する。
【００１５】
最新のトロイの木馬およびスパイウェアの検出ソフトウェアにはいくつかの難点があり、この検出ソフトウェアは、悪意のあるソフトウェアを抑制するために本来は開発されたものである。これらの技術は、典型的には、すでに知られているファイル署名を探し出し、その後そのような脅威を可能な限り排除する。これらの技術はまた、顧客のコンピュータから送出されるデータトラフィックを監視するが、個人データが暗号化されている場合、この個人データを検出することができない。これらのプロセスはまた、新しい脅威が発見されると更新されなければならず、予防的セキュリティまたは他の防御機構に基づいて構築されているわけではない。これらプロセスはまた、単独では、ブラウザクライアントとサーバとの間のデータストリームを保護することができない。それは、連係および対応の構成要素がサーバに存在しないためである。
【００１６】
現在のブラウザアーキテクチャはまた、固有のセキュリティ問題を呈する。これらブラウザアーキテクチャは、当初はグラフィカルなウェブページを表示するために設計されたが、後には拡張機能をサポートして、ベンダーがブラウザアーキテクチャ内でカスタムアプリケーションを記述できるようになっている。つまり、ベンダーは、ブラウザアーキテクチャ内に独自のアプリケーションを作成できる。さらに後に、Ｗｅｂベースアプリケーション（ウェブ基盤のアプリケーション）のような相互作用を可能にするスクリプト言語を許可するように、このようなカスタムアプリケーションは拡張された。これらは、最初からセキュア方式に設計されているわけではなく、時間とともに次第に進化した。例えば、ＨＴＴＰＳ（Hyper-Text Transfer Protocol Secure）のようなプロトコルが、ネットワーク配線の「スヌーピング」または「盗聴」からエンドユーザを保護するといった、いくつかのセキュリティの側面を提供するように設計された。他のセキュリティ機能拡張は、悪質なウェブサイトからエンドユーザを保護すること、およびコードを記述（スクリプト）することに焦点を合わせているが、侵入されたエンドユーザのマシン（コンピュータ）からＷｅｂアプリケーションを保護することを目的としていない。
【００１７】
図１は、本発明の１つの例示的な実施形態を示したブロック図１００であり、トロイの木馬の簡単な検出方法を改良したものである。この例示的な実施形態は、インターネットブラウザ１０５（例えば、マイクロソフト（登録商標）社のインターネットエクスプローラ（登録商標））の立上げを検出し、カスタムＤＬＬ（ダイナミックリンクライブラリ）１１５を直接ブラウザプロセス１０５に挿入する。これは、ブラウザヘルパーオブジェクト（Browser Helper Object（ＢＨＯ））として、またはインターネットブラウザ１０５へのプラグインとして設計されたＢＨＯ以外のＤＬＬモジュールとしてインスタンス化される。
【００１８】
しかし、このようなＢＨＯはインターネットブラウザのイベントモデルに無制限にアクセスするため、ＢＨＯ単独では完全なセキュリティを提供することができない。そのために、マルウェア形態もまたＢＨＯとして生成されている。例えば、悪名高い"download.jact"は、インストールされたＢＨＯの弱点をついて攻撃する。具体的には、攻撃されたＢＨＯは、金融機関へのセキュアＨＴＴＰ接続を検出するとアクティブな状態となり、ユーザのキーストロークを記録し（パスワードを捕獲する目的で）、その後、その情報を犯罪者が運営するウェブサイトに送信する。ＢＨＯに関連するこれらの問題に対応して、インターネットブラウザのプロバイダは後に、アドオンマネージャ（例えば、Ｗｉｎｄｏｗｓ（登録商標）  ＸＰについてのマイクロソフト（登録商標）社によるＳｅｒｖｉｃｅ  Ｐａｃｋ  IIのリリースにより）を追加した。この追加によって、ユーザは、インストールされたＢＨＯ、ブラウザ拡張機能、およびＡｃｔｉｖｅＸコントロールを有効または無効にすることができるようになった。
【００１９】
例示的なこの実施形態によれば、ルートキット１１０または他のプロセス（例えば、Ｖｅｒｄａｓｙｓ（登録商標）社（本特許出願の譲受人）から入手可能なＤｉｇｉｔａｌ  Ｇｕａｒｄｉａｎ（登録商標））を用いてＤＬＬ１１５をインストールすることにより、ブラウザ１０５に出入りするトラフィックのフローを検査することができる。ルートキット１１０は、図２の例示的な実施形態２００に示されるような中央サーバ２００を用いて、インテリジェントエージェントプロセスを展開および監視してもよい。このエージェントプロセスは、ＨＴＴＰ接続を介して、ユーザ名およびパスワードのような情報をサーバ２２０に送り返してもよい。なお、エージェントプロセスが情報をサーバ２２０に送信する前に情報を暗号化するため、この情報は他のプロセスには見えないかもしれない。インテリジェントエージェントプロセスが用いられて、ユーザのデータ取引をログ記録し、予め定義された役割を適用することにより、エンドユーザのデータトラフィックの検出だけでなく、データが適正に使用されることを保証する。このようなプロセスはまた、Ｖｅｒｄａｓｙｓ，Ｉｎｃ．（本発明の譲受人）に譲渡された、発明の名称が「アプリケーション計測および監視（“Application Instrumentation and Monitoring”）」である、2004年11月22日付で出願された米国特許出願第10/995,020号（米国特許出願公開第2006−0123101号として公開されている）に詳細に説明されている。上記出願の全内容は参照により本明細書に引用したものとする。
【００２０】
図３は、標準通信アーキテクチャの通常の入力フローを示すフローチャート３００である。この標準アーキテクチャでは、標準アーキテクチャのデータフロー内のいくつかの異なる場所（例えば、カーネル３１５、アプリケーションメッセージキュー３２０またはアプリケーション層３２５）において、ユーザ入力（例えば、キーボード、マウスなどの入力装置３０５、３１０）が検査され、場合によっては拒絶される。このため、標準アーキテクチャでは、受信された入力メッセージが実際にユーザのキーボードなどの入力装置３０５、３１０において生じたものであって、システムが侵入されたことによるものではない、ということを判別することができない。
【００２１】
図４は、本発明の１つの例示的な実施形態による、キーボード、マウスなどの入力装置３０５、３１０から、セキュア入力チャネル４３０、４３５を介する、セキュアブラウザプロセス４４０へのデータフローを示すブロック図４００である。この例示的な実施形態では、キーボードドライバスタックと相互作用する、顧客のセキュアカーネルドライバを提供することによって、標準アーキテクチャの問題点を克服している。このドライバはポイント３１５、３２０、３２５を回避するような方法でロードされており、これらポイント３１５、３２０、３２５を回避しなければ、ユーザ入力が侵入つまり攻撃される可能性がある。この回避は、通常のオペレーティングシステムのキーボードおよびマウスのメッセージングプロセス（例えば、標準オペレーティングシステムのアプリケーションプログラミングインタフェース（ＡＰＩ））を「短絡」し（かわし）、その代わりにユーザ入力装置３０５、３１０とセキュアブラウザプロセス４４０の間にセキュアチャネル４３０、４３５を設けることによって、最良の形態で達成できる。セキュアキーボードドライバおよびセキュアブラウザプロセスからの入力ストリームは暗号化されてもよく、そのため、ユーザマシンがマルウェアによって侵入されている場合であっても、キーボードトラフィックは解読されない。一般に、この発想は、標準オペレーティングシステムの構成要素を回避し、その代わりにカスタムセキュア入力ドライバ（特別なセキュア入力ドライバ）をインスタンス化することであり、この入力ドライバのアーキテクチャは部外者に知られたり制御されたりする可能性が極めて低い。
【００２２】
図５は、商業者のウェブページを示す高レベル図５００であり、図６は、セキュアブラウザホスト（ＳＢＨ）ＡｃｔｉｖｅＸコントロール６１０を参照する単一の埋め込みオブジェクトを含む、ウェブページ５０５を示す高レベル図６００である。図５に示すように、商業者のクライアントが商業者のウェブページ５０５でログインリンク５１０を選択すると、プロセスが開始する。以後、図６に示すように、プロセスは、セキュアブラウザホスト（ＳＢＨ）ＡｃｔｉｖｅＸコントロール６１０を参照する単一の埋め込みオブジェクトを含むホストからウェブページ５０５を戻す。
【００２３】
図７は、セキュアブラウザプロセス（ＳＢＰ）７１５の初期化を示す高レベル図７００である。ウェブページ５０５が戻ると、ＡｃｔｉｖｅＸコントロール６１０がブラウザ内で初期化され、その後に元のブラウザアプリケーションのコンテキスト内でセキュアブラウザプロセス（ＳＢＰ）７１５を開始する。次に、このＳＢＰ７１５が試験され、「システムインスペクタ（system inspector）」を用いてそのアプリケーション記憶領域に外部コードが全く存在しないことを保証する。このインスペクタに関しては、図８と併せて説明する。
【００２４】
図８は、ＳＢＰ７１５を検査してセキュリティ確認を提供することを示す高レベル図８００である。ＳＢＰ７１５を開始すると、ＳＢＰ７１５は「システムインスペクタ」機能８２０を実行してセキュリティ確認を提供する。このシステムインスペクタ機能８２０は、そのプロセス内にロードされている全てのＤＬＬを確認して、ＤＬＬが改ざんまたは変更されていないことを保証する。１つの代替の実施形態においては、セキュアキーボードドライバも確認されて、そのロードされた画像が何らかの方法、例えばデジタル署名（暗号ハッシュ、例えば、ＭＤ５、ＳＨＡ１など）を用いてフック（入力を横取りして独自処理を行うこと）されていないことを保証する。このようにして、ＳＢＰ７１５がそれ自体のセキュアキーボードドライバからの入力のみを受信することが保証される。ＳＢＰ７１５はまた、使用中の全てのカーネルＡＰＩが、システムインスペクタ機能８２０の一部として上書きまたはリダイレクトされていないことを確認してもよい。ＤＬＬが侵入されているか、またはカーネルＡＰＩもしくはカーネルドライバが上書きまたは変更されている場合、その後プロセスは終了するか、または例外を投入する。
【００２５】
図９は、埋め込みブラウザオブジェクト９２５をインスタンス化して、外部ＡＰＩおよびプラグインを阻止することを示す高レベル図９００である。環境がクリーンであることを確認すると、ＳＢＰ７１５はこのような埋め込みブラウザオブジェクト９２５をインスタンス化し、全ての外部ＡＰＩは阻止され、ブラウザのプラグインのロードが許可されない。
【００２６】
図１０は、入力装置に対してセキュア入力チャネル１０３０を生成することを示した高レベル図１０００である。環境がクリーンであることを確認すると、ＳＢＰ７１５は、データをアプリケーションに入力するプロセスで用いられるエンドユーザの入力装置（例えば、キーボードまたはマウス）に対してセキュアチャネル１０３０（プロキシ）をオープンにする。
【００２７】
図１１は、商業者の宛先サーバに対してセキュア通信チャネル１１３５を生成することを示す、高レベル図１１００である。環境がクリーンであることを確認すると、ＳＢＰ７１５はまた、宛先サーバに対してセキュアチャネル１１３５（プロキシ）を生成する。このアーキテクチャによって、キーボードと宛先サーバとの間の接続がセキュリティ保護されるため、ローカルマシン上であっても、データは傍受（インターセプト）および侵入されないことを保証する。
【００２８】
図１２は、標準通信アーキテクチャにおける通信のフローを示すフローチャート１２００である。標準的なフローにおいて、ブラウザアプリケーション１２０５から生じた通信（例えば、伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）トラフィック）は、セキュアソケット層（ＳＳＬ）１２２０に到達するまで完全にクリアであり、セキュアソケットを介して送信される前にこのＳＳＬ１２２０においてその通信が暗号化される。標準アーキテクチャにおいては、ソケット層１２２０に到達するまで通信は暗号化されないため、オペレーティングシステムの中間構成要素（例えば、プロトコルフィルタ１２１０またはＡＰＩ１２１５）内においてブラウザプロセス１２０５とソケットレイヤー１２２０との間で、通信が傍受される可能性がある。
【００２９】
図１３は、本発明の１つの例示的な実施形態による、標準オペレーティングシステムの構成要素を通過する前に通信を暗号化するフローチャート１３００を示す。この例示的な実施形態では、任意の別の標準オペレーティングシステム構成要素１３１５（例えば、フィルタまたはＡＰＩ）を介して送信される前に、ブラウザプロセス１３０５から生じた通信を暗号化すること（１３１０）によって、標準通信アーキテクチャに関する問題が克服される。もし、暗号化されなければ、通信はクリアに見えてしまう。このようにして、さらなるセキュリティ上のリスクと起こり得る傍受ポイントとが最小限になる。
【００３０】
図１４は、結果として得られる信頼された取引のアーキテクチャを示す高レベル図１４００である。最下位層には、セキュアシステムローダ１４０５が設けられている。図８に関して説明したように、システムローダ１４０５のコンテキストにおいて、システムインスペクタ１４１０が確認を実行する。確認が確立されると、セキュア通信チャネル１４１５、セキュア入力チャネル１４２０およびセキュア認証システム１４２５によって、セキュアブラウザ環境１４３０のコンテキスト内で、「指先」によるユーザキーボード入力（ユーザによる実際のキーボード入力）から宛先サーバ１４３５までの信頼された通信が提供される。
【００３１】
本発明を例示的な実施形態を参照して詳細に示し、説明してきたが、添付の特許請求の範囲に包含される本発明の範囲から逸脱することなく、形態および細部において様々な変更がなされてもよいことが、当業者には理解されるであろう。
【符号の説明】
【００３２】
１４０５  セキュアシステムローダ
１４１０  システムインスペクタ
１４２０  セキュア入力チャネル
【図１】
2010517170.tif 000003
【図２】
2010517170.tif 000004
【図３】
2010517170.tif 000005
【図４】
2010517170.tif 000006
【図５】
2010517170.tif 000007
【図６】
2010517170.tif 000008
【図７】
2010517170.tif 000009
【図８】
2010517170.tif 000010
【図９】
2010517170.tif 000011
【図１０】
2010517170.tif 000012
【図１１】
2010517170.tif 000013
【図１２】
2010517170.tif 000014
【図１３】
2010517170.tif 000015
【図１４】
2010517170.tif 000016
【国際調査報告】
2010517170.tif 000017