JP7702404B2 - 悪意のあるプログラムコード注入に対する保護のためのシステム及び方法 - Google Patents

Description

本発明は、概して、データ処理システムの分野に関する。より具体的には、本発明は、ＪａｖａＳｃｒｉｐｔインジェクションなどの悪意のあるプログラムコードインジェクションから保護するためのシステム及び方法に関するものである。

図１は、生体認証デバイス１００を有する例示的なクライアント１２０を示している。正常動作時において、生体認証センサ１０２は、ユーザからの生の生体認証データを読み取り（例えば、ユーザの指紋を捕捉する、ユーザの音声を録音する、ユーザのスナップ写真を撮るなど）、特徴抽出モジュール１０３は、生の生体認証データの指定された特性を抽出する（例えば、指紋の特定領域、特定の顔特徴などに焦点を当てるなど）。照合部モジュール１０４は、抽出した特徴１３３を、クライアント１２０のセキュアストレージに格納された生体認証基準データ１１０と比較し、抽出した特徴と生体認証基準データ１１０との間の類似度に基づいてスコアを生成する。生体認証基準データ１１０は、一般的に、ユーザが、指紋、音声サンプル、画像、又は他の生体認証データをデバイス１００に登録する登録プロセスの結果である。次に、アプリケーション１０５は、スコアを使用して、認証が成功したかどうか（例えば、スコアが特定の指定閾値を上回っているか）を判定してもよい。

図１に示されるシステムは生体認証を指向しているが、様々な他の又は追加の認証技術が例示的なクライアント１２０上で採用されてもよい。例えば、クライアント側認証部は、ユーザによって入力されたＰＩＮ又は他の秘密コード（例えば、パスワード）に基づいてもよく、かつ／又はユーザの存在（例えば、ユーザが存在を検証するために押すボタン）に基づいて始動されてもよい。

システムは、生体認証センサを使用してネットワーク上でセキュアなユーザ認証を提供するために設計されている。かかるシステムでは、アプリケーションによって生成されたスコア及び／又は他の認証データは、リモートサーバによってユーザを認証するため、ネットワークを通じて送られてもよい。例えば、米国特許出願公開第２０１１／００８２８０１号（「‘８０１出願」）は、強力な認証（例えば、個人情報の盗難及びフィッシングに対する保護）を提供する、ネットワーク上でのユーザ登録及び認証のためのフレームワーク、セキュアトランザクション（例えば、「マルウェア・イン・ザ・ブラウザ」及びトランザクションについての「マン・イン・ザ・ミドル」攻撃に対する保護）、及び、クライアント認証トークン（例えば、指紋リーダー、顔認識デバイス、スマートカード、トラステッドプラットフォームモジュールなど）の登録／管理について記載している。

本特許出願の譲受人は、‘８０１出願に記載された認証フレームワークに対する様々な改善を開発している。これらの改善のうちいくつかは、１０１２年１２月２９日に本件の譲受人に譲渡され、参照として本明細書に組み込まれる以下の一群の米国特許出願（「同時係属出願」）に記載されている：第１３／７３０，７６１号、Ｑｕｅｒｙ Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｔｏ Ｄｅｔｅｒｍｉｎｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃａｐａｂｉｌｉｔｉｅｓ；第１３／７３０，７７６号、Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｅｆｆｉｃｉｅｎｔｌｙ Ｅｎｒｏｌｌｉｎｇ，Ｒｅｇｉｓｔｅｒｉｎｇ，ａｎｄ Ａｕｔｈｅｎｔｉｃａｔｉｎｇ Ｗｉｔｈ Ｍｕｌｔｉｐｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄｅｖｉｃｅｓ；第１３／７３０，７８０号、Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｐｒｏｃｅｓｓｉｎｇ Ｒａｎｄｏｍ Ｃｈａｌｌｅｎｇｅｓ Ｗｉｔｈｉｎ ａｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ；第１３／７３０，７９１号、Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｉｍｐｌｅｍｅｎｔｉｎｇ Ｐｒｉｖａｃｙ Ｃｌａｓｓｅｓ Ｗｉｔｈｉｎ ａｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ；第１３／７３０，７９５号、Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｉｍｐｌｅｍｅｎｔｉｎｇ Ｔｒａｎｓａｃｔｉｏｎ Ｓｉｇｎａｌｉｎｇ Ｗｉｔｈｉｎ ａｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｆｒａｍｅｗｏｒｋ。

簡潔に述べると、同時係属出願は、ユーザがクライアント装置上の生体認証デバイス（例えば、指紋センサ）などの認証装置（又は認証部）に登録する認証技術を記載している。ユーザが生体認証デバイスによって登録されるとき、生体認証参考データが（例えば、指をスワイプすること、写真をスナップすること、音声を録音することなどにより）捕捉される。ユーザは、その後、ネットワーク上で１つ以上のサーバ（例えば、同時係属中の出願で説明されているようにセキュアなトランザクションサービスが装備されたウェブサイト又は他の依拠当事者）に認証デバイスを登録して、その後、登録プロセス中に交換されるデータ（例えば、認証デバイスにプロビジョニングされる暗号鍵）を使用してそれらのサーバで認証することができる。認証されると、ユーザは、ウェブサイト又は他の依拠当事者と１つ以上のオンライントランザクションを実行することが許可される。同時係属出願に記載されたフレームワークでは、機密情報、例えば、ユーザを一意的に識別するために使用することができる指紋データ及び他のデータは、ユーザのプライバシーを保護するためにユーザの認証デバイスにローカルに保持されてもよい。

本発明のより良好な理解は、以下の図面と併せた以下の詳細な説明から得ることができる。

生体認証能力を有する例示のクライアントデバイスを示す図である。

セキュア認証システムアーキテクチャの２つの異なる実施形態を示す図である。 セキュア認証システムアーキテクチャの２つの異なる実施形態を示す図である。

鍵を認証デバイスに登録することができる方法を示すトランザクション図である。

セキュアディスプレイを使用するセキュアトランザクション確認の実施形態を示す図である。 セキュアディスプレイを使用するセキュアトランザクション確認の実施形態を示す図である。

関係が確立されていないデバイスとのトランザクションのための認証を行う本発明の一実施形態を示す図である。

トランザクションのための認証を行う２つの異なる実施形態を示すトランザクション図である。 トランザクションのための認証を行う２つの異なる実施形態を示すトランザクション図である。

本発明の一実施形態で用いられる追加のアーキテクチャ上の特徴を示す図である。

本発明の異なる実施形態で用いられるベアラートークンの異なる実施形態を示す図である。 本発明の異なる実施形態で用いられるベアラートークンの異なる実施形態を示す図である。

例示の「オフライン」及び「セミオフライン」認証シナリオを示す図である。

クライアント及び／又はサーバのための例示のシステムアーキテクチャを示す図である。

クライアント及び／又はサーバのための別の例示のシステムアーキテクチャを示す図である。

クライアントとサーバとの間の中間者（ＭＩＴＭ）配列を示す図である。

クライアントがウェブページを訪問したときの例示的な相互作用のセットを示す図である。

ウェブページ及びその後のＪａｖａＳｃｒｉｐｔリンクに関連するＭＩＴＭ捕捉通信を示す図である。

認証段階中にクライアントとサーバとの間に介在するＭＩＴＭを示す図である。

リソース記述子及びコード記述子を使用したクライアントサーバ認証の一実施形態を示す図である。

以下に説明するものは、高度な認証技術及び関連するアプリケーションを実行するための装置、方法及び機械可読媒体の実施形態である。説明を通して、説明の目的のために、多数の具体的な詳細が本発明の完全な理解を提供するために記載されている。しかしながら、本発明が、これらの具体的な詳細の一部がなくても実施され得ることは当業者にとって明らかであろう。他の例において、周知の構造及びデバイスは示されていないか、又は、本発明の基本原理を曖昧にすることを避けるためにブロック図の形態で示されている。

以下に考察する本発明の実施形態は、生体認証デバイス又はＰＩＮ入力などの認証能力を備えたクライアントデバイスを伴う。これらのデバイスは、本明細書において、「トークン」、「認証デバイス」、又は「認証部」と呼ばれることがある。特定の実施形態は、顔認識ハードウェア／ソフトウェア（例えば、ユーザの顔を認識してユーザの眼の動きを追跡するためのカメラ及び関連するソフトウェア）にフォーカスしており、いくつかの実施形態は、例えば、指紋センサ、音声認識ハードウェア／ソフトウェア（例えば、マイクロフォン及びユーザの音声を認識するための関連するソフトウェア）、及び、光学的認識機能（例えば、ユーザの網膜をスキャンするための光学スキャナ及び関連するソフトウェア）を含む追加の生体認証デバイスを利用することができる。認証能力はまた、トラステッドプラットフォームモジュール（trusted platform module、ＴＰＭ）及びスマートカードなどの非生体認証デバイスを含むことができる。

モバイル生体認証の実装において、生体認証デバイスは、依拠当事者からリモートにあってもよい。本明細書で用いるとき、「リモート」という用語は、生体認証デバイスが通信可能に結合されているコンピュータのセキュリティ境界の一部ではない（例えば、依拠当事者コンピュータと同じ物理的筐体内に埋め込まれていない）ことを意味する。一例として、生体認証デバイスは、ネットワーク（例えば、インターネット、無線ネットワークリンクなど）を介して又はＵＳＢポートなどの周辺入力を介して依拠当事者に結合することができる。これらの条件下では、そのデバイスが依拠当事者（例えば、認証及び完全性保護の許容レベルを提供するもの）によって認証され、及び／又はハッカーが生体認証デバイスを侵害したかを、依拠当事者が知る方法がないことがある。生体認証デバイスにおける信頼度は、デバイスの特定の実装形態に依存する。

しかしながら、以下に説明するように、ユーザを認証するために用いられる認証技術は、リモートサーバ及び／又は他のデータ処理デバイスとのネットワークを介した通信などの非位置的構成要素（non-location component）を含むことができる。更に、具体的な実施形態（ＡＴＭ及び小売店など）が本明細書において記載されるが、本発明の基本原理は、トランザクションがエンドユーザによってローカル又は遠隔で開始される、任意のシステムのコンテキスト内で実装されてもよいことに留意すべきである。

「依拠当事者」という用語は、本明細書では、ユーザトランザクションを実行しようとしているエンティティ（例えば、ユーザトランザクションを実行するウェブサイト又はオンラインサービス）だけでなく、本明細書に記載する基本認証技術を実行してもよいそのエンティティの代理として実装されるセキュアトランザクションサーバも指すのに使用される場合がある。遠隔認証能力を提供したセキュアトランザクションサーバは、所有され、及び／又は依拠当事者の制御下にあってもよく、あるいは事業構成の一部として依拠当事者に対してセキュアトランザクションサービスを提供する第三者の制御下にあってもよい。

「サーバ」という用語は、クライアントからネットワークを介してリクエストを受信し、応答として１つ以上の操作を実行し、クライアントに通常は操作の結果を含む応答を送信するハードウェアプラットフォーム上で（又は複数のハードウェアプラットフォームにわたって）実行されるソフトウェアを指すために本明細書において使用される。サーバは、クライアントに対してネットワーク「サービス」を提供する又は提供するのに役立つように、クライアントのリクエストに応答する。重要なことは、サーバが単一のコンピュータ（例えば、サーバソフトウェアを実行する単一のハードウェアデバイス）に限定されるものではなく、実際には、潜在的に複数の地理的位置にある複数のハードウェアプラットフォームにまたがってもよいということである。

本明細書に記載する本発明の実施形態は、セキュアトランザクションデバイスを通してトランザクションを開始するために、ユーザを認証する技術を含む。一例として、トランザクションは、払い戻し、振替、又は他のユーザ起動型動作であってもよく、トランザクションデバイスは、自動預金支払い機（automatic teller machine、ＡＴＭ）、売場専用（point-of-sale、ＰｏＳ）トランザクションデバイス、又はユーザの代理としてトランザクションを実行することができる他のデバイスであってもよい。トランザクションは、例えば、デバイスを装備した小売店若しくは他の小売場所における物品又はサービスの購入に対する支払いの完了、デバイスを介したファンドの払い戻し、デバイスに対するメンテナンスの実行、あるいはユーザ認証を要する他の任意のトランザクションを伴ってもよい。

本発明の一実施形態は、デバイスがオフライン（すなわち、バックエンド認証サーバに接続されていない）又はセミオフライン（すなわち、周期的にのみバックエンド認証サーバに接続される）の状況であっても、ユーザをローカルで認証する（すなわち、ユーザを検証する）ための技術を提供する。一実施形態では、ユーザのクライアントデバイスは、（例えば、依拠当事者の代理として動作する）バックエンド認証サーバによって生成される認証要求をキャッシュに入れる能力を備え、デバイスは、ユーザのクライアントデバイスからデバイスに送信された認証応答を検証するのに必要なデータを含む。

これらの実施形態の詳細を考察する前に、遠隔ユーザ認証技術の概要を提供する。これら及び他の遠隔ユーザ認証技術は、本出願の譲受人に譲渡されており、参照により本明細書に組み込まれる、同時係属出願に記載されている。
遠隔ユーザ認証技術

図２Ａ及び図２Ｂは、ユーザを遠隔で認証する、クライアント側及びサーバ側の構成要素を備えるシステムアーキテクチャの２つの実施形態を示している。図２Ａに示される実施形態は、ウェブサイトと通信するため、ブラウザプラグインベースのアーキテクチャを使用するが、図２Ｂに示される実施形態はブラウザを要しない。本明細書に記載する様々な認証技術及び関連アプリケーションは、これらのシステムアーキテクチャのいずれかに実装されてもよい。例えば、本明細書に記載するクライアントデバイス内の認証エンジンは、インターフェース２０２を含むセキュアトランザクションサービス２０１の一部として実装されてもよい。しかしながら、上述した実施形態は、図２Ａ～Ｂに示されるもの以外のハードウェア及びソフトウェアの論理構成を使用して実現されてもよいことに留意すべきである。

図２Ａを参照すると、図示される実施形態は、エンドユーザを登録し認証するための１つ以上の認証デバイス２１０～２１２を装備したクライアント２００を含む。上述したように、認証デバイス２１０～２１２は、指紋センサ、音声認識ハードウェア／ソフトウェア（例えば、ユーザの音声を認識するためのマイクロフォン及び関連ソフトウェア）、顔認識ハードウェア／ソフトウェア（例えば、ユーザの顔を認識するためのカメラ及び関連ソフトウェア）、及び光学認識能力（ユーザの網膜をスキャンするための光スキャナ及び関連ソフトウェア）などの生体認証デバイス、並びにトラステッドプラットフォームモジュール（ＴＰＭ）及びスマートカードなどの非生体認証デバイスを含んでもよい。ユーザは、セキュアトランザクションサービス２０１が（インターフェース２０２を介して）セキュアストレージ２２０に生体認証テンプレートデータとして格納することができる生体認証データを提供する（例えば、指紋認証デバイス上で指をスワイプする）ことによって、生体認証デバイスに登録することができる。

セキュアストレージ２２０は、認証デバイス２１０～２１２のセキュア周辺デバイスの外側に示されているが、一実施形態では、各認証デバイス２１０～２１２は独自の統合セキュアストレージを有してもよい。それに加えて、各認証デバイス２１０～２１２は、生体認証基準データレコードを暗号的に保護（例えば、ストレージ２２０をセキュアにするため、データレコードをラッピング）してもよい。

認証デバイス２１０～２１２は、セキュアトランザクションサービス２０１によって露出されたインターフェース２０２（例えば、アプリケーションプログラミングインターフェース、すなわちＡＰＩ（application programming interface））を通して、クライアントに通信可能に結合される。セキュアトランザクションサービス２０１は、ネットワーク上で１つ以上のセキュアトランザクションサーバ２３２～２３３と通信し、ウェブブラウザ２０４のコンテキスト内で実行されるセキュアトランザクションプラグイン２０５とインターフェース接続するためのセキュアアプリケーションである。図示されるように、インターフェース２０２はまた、デバイス識別コード（認証部証明ＩＤ（authenticator attestation ID、ＡＡＩＤ））、ユーザ識別コード、ユーザ登録データ（例えば、スキャンされた指紋又は他の生体認証データ）、及び本明細書に記載するセキュア認証技術を実行するのに使用される鍵など、認証デバイス２１０～２１２それぞれに関する情報を格納する、クライアント２００のセキュアストレージデバイス２２０に対するセキュアアクセスを提供してもよい。例えば、詳細に後述するように、固有の鍵が認証デバイスそれぞれに格納され、その後、インターネットなどのネットワーク上でサーバ２３０と通信するときに使用されてもよい。

後述するように、特定の種類のネットワークトランザクションは、ウェブサイト２３１又は他のサーバとのＨＴＴＰ又はＨＴＴＰＳトランザクションなどのセキュアトランザクションプラグイン２０５によってサポートされる。一実施形態では、セキュアトランザクションプラグインは、セキュアエンタープライズ又はウェブデスティネーション２３０の内部のウェブサーバ２３１（時として、単に「サーバ２３０」と呼ばれることがある）によってウェブページのＨＴＭＬコードの中に挿入された特定のＨＴＭＬタグに応答して開始される。そのようなタグを検出することに応答して、セキュアトランザクションプラグイン２０５は、処理のために、セキュアトランザクションサービス２０１に、トランザクションを転送することができる。更に、特定の種類のトランザクション（例えば、セキュア鍵交換などの）について、セキュアトランザクションサービス２０１は、内部設置トランザクションサーバ２３２（すなわち、ウェブサイトと同じ位置に配置された）又は外部設置トランザクションサーバ２３３との直接の通信チャネルを開くことができる。

セキュアトランザクションサーバ２３２～２３３は、ユーザデータ、認証デバイスデータ、鍵、及び後述するセキュア認証トランザクションをサポートするのに必要な他のセキュア情報を格納する、セキュアトランザクションデータベース２４０に結合される。しかしながら、本発明の基本原理は、図２Ａに示されるセキュアエンタープライズ又はウェブデスティネーション２３０内の論理的構成要素の分離を要しないことに留意すべきである。例えば、ウェブサイト２３１及びセキュアトランザクションサーバ２３２～２３３は、単一の物理的サーバ又は別個の物理的サーバ内に実装されてもよい。更に、ウェブサイト２３１及びトランザクションサーバ２３２～２３３は、後述する機能を行うために１つ以上のサーバ上で実行される統合されたソフトウェアモジュール内に実装されてもよい。

上述したように、本発明の基本原理は、図２Ａに示されるブラウザベースのアーキテクチャに限定されない。図２Ｂは、スタンドアロンアプリケーション２５４が、セキュアトランザクションサービス２０１によって提供される機能を利用してネットワーク上でユーザを認証する、代替の実装形態を示している。一実施形態では、アプリケーション２５４は、詳細に後述するユーザ／クライアント認証技術を実行するための、セキュアトランザクションサーバ２３２～２３３に依存する１つ以上のネットワークサービス２５１との通信セッションを確立するように設計される。

図２Ａ～２Ｂに示される実施形態のどちらにおいても、セキュアトランザクションサーバ２３２～２３３は、次にセキュアトランザクションサービス２０１に対してセキュアに送信され、セキュアストレージ２２０内の認証デバイスに格納される、鍵を生成してもよい。それに加えて、セキュアトランザクションサーバ２３２～２３３は、サーバ側のセキュアトランザクションデータベース２４０を管理する。

図２Ｃは、認証デバイスを登録するための一連のトランザクションを示している。上述したように、登録の間、鍵は認証デバイスとセキュアトランザクションサーバ２３２～２３３のうち１つとの間で共有される。鍵は、クライアント２００のセキュアストレージ２２０、及びセキュアトランザクションサーバ２３２～２３３によって使用されるセキュアトランザクションデータベース２２０内に格納される。一実施形態では、鍵は、セキュアトランザクションサーバ２３２～２３３のうち１つによって生成される対称鍵である。しかしながら、後述する別の実施形態では、非対称鍵が使用されてもよい。この実施形態では、公開鍵は、セキュアトランザクションサーバ２３２～２３３によって格納されてもよく、第２の関連する秘密鍵は、クライアントのセキュアストレージ２２０に格納されてもよい。更に、別の実施形態では、鍵は、（例えば、セキュアトランザクションサーバ２３２～２３３よりもむしろ認証デバイス又は認証デバイスインターフェースによって）クライアント２００上で生成されてもよい。本発明の基本原理は、任意の特定の種類の鍵又は鍵の生成方法に限定されるものではない。

動的対称鍵プロビジョニングプロトコル（ＤＳＫＰＰ）などのセキュア鍵プロビジョニングプロトコルは、セキュア通信チャネルを通じてクライアントと鍵を共有するのに使用されてもよい（例えば、コメント要請（ＲＦＣ）６０６３を参照）。しかしながら、本発明の基本原理は、いかなる特定の鍵プロビジョニングプロトコルにも限定されるものではない。

図２Ｃに示される具体的な詳細を参照すると、ユーザ登録又はユーザ検証が完了すると、サーバ２３０は、デバイス登録の間にクライアントによって提示されなければならないランダム生成チャレンジ（例えば、暗号化ナンス）を生成する。ランダムチャレンジは、限られた期間について有効であり得る。セキュアトランザクションプラグインは、ランダムチャレンジを検出し、それをセキュアトランザクションサービス２０１に転送する。それに応答して、セキュアトランザクションサービスは、サーバ２３０とのアウトオブバンドセッション（例えば、アウトオブバンドトランザクション）を開始し、鍵プロビジョニングプロトコルを使用してサーバ２３０と通信する。サーバ２３０は、ユーザ名を用いてユーザの位置を確認し、ランダムチャレンジを有効化し、デバイスの認証コードが送られた場合にその認証コード（例えば、ＡＡＩＤ）を有効化し、セキュアトランザクションデータベース２２０にユーザのための新たなエントリを作成する。また、鍵又は公開／秘密鍵の対を生成し、鍵をデータベース２２０に書き込み、鍵プロビジョニングプロトコルを使用して鍵をセキュアトランザクションサービス２０１に返送してもよい。完了すると、認証デバイス及びサーバ２３０は、対称鍵が使用された場合には同じ鍵を共有し、非対称鍵が使用された場合には異なる鍵を共有する。

図３Ａは、ブラウザベースの実装形態のためのセキュアトランザクションの確認を示している。ブラウザベースの実装形態が示されているが、同じ基本原理が、スタンドアロンアプリケーション又はモバイルデバイスアプリケーションを使用して実現されてもよい。

セキュアトランザクション確認は、特定の種類のトランザクション（例えば、金融トランザクション）に対するより強力なセキュリティを提供するように設計される。図示される実施形態では、ユーザは、トランザクションを委任する前に各トランザクションを確認する。図示される技術を使用して、ユーザは、自身が完遂したいものを正確に確認し、グラフィカルユーザインターフェース（ＧＵＩ）のウィンドウ３０１に表示されているものを自身が見ることを正確に完遂する。換言すれば、この実施形態は、ユーザが確認しなかったトランザクションを完遂するため、トランザクションテキストが「中間者」（ＭＩＴＭ）又は「マンインザブラウザ」（ＭＩＴＢ）によって修正されることがないことを保証する。

１つの実施形態では、セキュアトランザクションプラグイン２０５は、ブラウザコンテキスト内にウィンドウ３０１を表示して、トランザクションの詳細を示す。セキュアトランザクションサーバ２０１は、ウィンドウに示されるテキストが、誰かによって（例えば、表示されたテキストの上にハッシュ／署名を生成することによって）改竄されていないことを周期的に（例えば、ランダムな間隔で）検証する。異なる実施形態では、認証デバイスは、トラステッドユーザインターフェース（例えば、ＧｌｏｂａｌＰｌａｔｆｏｒｍのＴｒｕｓｔｅｄＵＩに適合するＡＰＩを提供する）を有する。

以下の例は、この実施形態の動作を強調する助けとなる。ユーザは、マーチャントサイトから購入する品目を選び、「チェックアウト」を選択する。マーチャントサイトは、本明細書に記載する発明の実施形態のうち１つ以上を実装するセキュアトランザクションサーバ２３２～２３３を有する、サービスプロバイダ（例えば、ＰａｙＰａｌ）にトランザクションを送る。マーチャントサイトは、ユーザを認証し、トランザクションを完了する。

セキュアトランザクションサーバ２３２～２３３は、トランザクション詳細（ＴＤ）を受信し、「セキュアトランザクション」要求をＨＴＭＬページに入れ、クライアント２００に送る。セキュアトランザクション要求は、トランザクション詳細及びランダムチャレンジを含む。セキュアトランザクションプラグイン２０５は、トランザクション確認メッセージの要求を検出し、全てのデータをセキュアトランザクションサービス２０１に転送する。ブラウザ又はプラグインを使用しない実施形態では、情報は、セキュアトランザクションサーバからクライアント２００上のセキュアトランザクションサービスに直接送られてもよい。

ブラウザベースの実装形態について、セキュアトランザクションプラグイン２０５は、（例えば、ブラウザコンテキスト内で）トランザクション詳細を有するウィンドウ３０１をユーザに対して表示し、トランザクションを確認する認証を提供するようにユーザに求める。ブラウザ又はプラグインを使用しない実施形態では、セキュアトランザクションサービス２０１、アプリケーション２５４（図２Ｂ）、又は認証デバイス２１０は、ウィンドウ３０１を表示してもよい。セキュアトランザクションサービス２０１は、タイマを起動し、ユーザに対して表示されているウィンドウ３０１の内容を検証する。検証期間はランダムに選ばれてもよい。セキュアトランザクションサービス２０１は、ユーザが有効なトランザクション詳細をウィンドウ３０１内で見ていること（例えば、詳細に対するハッシュを生成し、正確な内容のハッシュと比較することによって内容が正確であると検証すること）を保証する。内容が改竄されていることを検出した場合、確認トークン／署名が生成されることを防止する。

ユーザが（例えば、指紋センサ上で指をスワイプすることによって）有効な検証データを提供した後、認証デバイスは、ユーザを検証し、トランザクション詳細及びランダムチャレンジによって暗号化署名（「トークン」と称される場合がある）を生成する（すなわち、署名は、トランザクション詳細及びナンスにわたって計算される）。これにより、トランザクション詳細がサーバとクライアントとの間で修正されていないことを、セキュアトランザクションサーバ２３２～２３３が保証するのが可能になる。セキュアトランザクションサービス２０１は、生成された署名及びユーザ名をセキュアトランザクションプラグイン２０５に送り、プラグインは、署名をセキュアトランザクションサーバ２３２～２３３に転送する。セキュアトランザクションサーバ２３２～２３３は、ユーザ名によってユーザを識別し、署名を検証する。検証が成功すると、確認メッセージがクライアントに送られ、トランザクションが処理される。

本発明の一実施形態は、セキュアトランザクションサーバが、サーバによって許容される認証能力を示すサーバポリシーをクライアントに送信するクエリポリシーを実装する。次に、クライアントは、サーバポリシーを分析して、サーバポリシーがサポートし、かつ／又はユーザが使用したいという要望を示している、認証能力のサブセットを識別する。次に、クライアントは、提供されたポリシーに一致する認証トークンのサブセットを使用してユーザを登録及び／又は認証する。したがって、クライアントは、認証能力に関する網羅的な情報（例えば、その認証デバイスの全て）、又はクライアントを固有に識別するのに使用されるかもしれない他の情報を送信することを求められないので、クライアントのプライバシーに対する影響は少ない。

限定ではなく一例として、クライアントは、例を挙げると、指紋センサ、音声認識能力、顔認識能力、眼／光学的認識能力、ＰＩＮ検証など、多くのユーザ検証能力を含んでもよい。しかしながら、プライバシー上の理由から、ユーザは、その能力の全てに関する詳細を要求サーバに対して明かすことを望まないことがある。このため、本明細書に記載する技術を使用して、セキュアトランザクションサーバは、例えば、指紋、光学的、又はスマートカード認証をサポートすることを示すサーバポリシーを、クライアントに送信してもよい。次に、クライアントは、サーバポリシーを独自の認証能力に対して比較し、利用可能な認証オプションのうち１つ以上を選んでもよい。

本発明の一実施形態は、クライアントとのセッションを維持するのに、いかなるトランザクション状態もサーバ上で維持する必要がないように、セキュアトランザクションサーバにおいてトランザクション署名を用いる。特に、ウィンドウ３０１内に表示されるトランザクションテキストなどのトランザクション詳細は、サーバによって署名されたクライアントに送られてもよい。次に、サーバは、クライアントが受信した署名付きトランザクション応答が有効であることを、署名を検証することによって検証してもよい。サーバは、トランザクションの内容を持続的に格納する必要はなく、それにより、多数のクライアントのために相当量の格納スペースが消費され、サーバに対するサービス種類攻撃の拒否の可能性が開かれる。

本発明の一実施形態が、クライアント２００とのトランザクションを開始するウェブサイト又は他のネットワークサービス３１１を示す図３Ｂに示されている。例えば、ユーザは、ウェブサイト上で購入する品目を選択していてもよく、チェックアウトし支払う準備ができていてもよい。図示される例では、ウェブサイト又はサービス３１１は、（本明細書に記載するように）署名を生成して検証するための署名処理論理３１３と、（例えば、上述した認証技術を使用して）クライアント認証３１４を実行するための認証論理とを含むセキュアトランザクションサーバ３１２に、トランザクションをハンドオフする。

１つの実施形態では、セキュアトランザクションサーバ３１２からクライアント２００に送られる認証要求は、（上述したような）暗号化ナンスなどのランダムチャレンジと、トランザクション詳細（例えば、トランザクションを完了するために提示される特定のテキスト）と、（セキュアトランザクションサーバによってのみ知られている）秘密鍵を使用して、ランダムチャレンジ及びトランザクション詳細を通じて署名処理論理３１３によって生成される署名とを含む。

上述の情報がクライアントによって受信されると、ユーザは、トランザクションを完了するのにユーザ検証が求められているという指標を受信してもよい。これに応答して、ユーザは、例えば、指紋スキャナにわたって指をスワイプするか、画像をスナップするか、マイクロフォンに向かって発話するか、又は所与のトランザクションに対して許可された他の任意の種類の認証を行ってもよい。一実施形態では、ユーザが認証デバイス２１０によって成功裡に検証されると、クライアントは：（１）ランダムチャレンジ及びトランザクションテキスト（両方とも、サーバによってクライアントに以前提供されたもの）、（２）ユーザが成功裡に認証を完了したことを証明する認証データ、並びに（３）署名を、サーバに返送する。

次に、セキュアトランザクションサーバ３１２上の認証モジュール３１４は、ユーザが適正に認証されていることを確認してもよく、署名処理論理３１３は、秘密鍵を使用して、ランダムチャレンジ及びトランザクションテキストを通じて署名を再生成する。署名がクライアントによって送られたものと一致した場合、サーバは、トランザクションのテキストがウェブサイト又はサービス３１１から最初に受信したときのものと同じであると検証することができる。セキュアトランザクションサーバ３１２は、セキュアトランザクションデータベース１２０内にトランザクションのテキスト（又は他のトランザクションデータ）を持続的に格納するのに必要でないため、記憶及び処理リソースは格納される。
オフラインデバイス又は接続性が制限されたデバイスに対してクライアントを認証するためのシステム及び方法

上述したように、本発明の一実施形態は、ユーザデバイス及びデバイスがオフライン（すなわち、依拠当事者のバックエンド認証サーバに接続されていない）又はセミオフライン（すなわち、ユーザデバイスは依拠当事者に接続されていないが、デバイスは接続されている）の状況であっても、ユーザをローカルで認証する（すなわち、ユーザを検証する）ための技術を含む。図４は、認証デバイスに依拠当事者４５１が以前に登録されているクライアント４００が、トランザクションデバイス４５０とセキュアなチャネルを確立してトランザクションを完了する、１つのかかる構成を示している。限定ではなく一例として、トランザクションデバイスは、ＡＴＭ、小売場所における売場専用（ＰｏＳ）トランザクションデバイス、物のインターネット（ＩｏＴ）デバイス、又はクライアント４００とチャネルを確立し、ユーザがトランザクションを実行することを可能にすることができる、他の任意のデバイスであってもよい。チャネルは、限定ではなく一例として、近距離無線通信（near field communication、ＮＦＣ）及びＢｌｕｅｔｏｏｔｈ（例えば、Ｂｌｕｅｔｏｏｔｈ Ｃｏｒｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｖｅｒｓｉｏｎ ４．０に記載されているようなＢｌｕｅｔｏｏｔｈ Ｌｏｗ Ｅｎｅｒｇｙ（Bluetooth Low Energy、ＢＴＬＥ））を含む、任意の無線通信プロトコルを使用して実装されてもよい。当然ながら、本発明の基本原理は、いかなる特定の通信標準にも限定されない。

点線の矢印によって示されるように、クライアント４００と依拠当事者４５１との間の接続、及び／又はトランザクションデバイス４５０と依拠当事者４５１との間の接続は、散発的であるか又は存在しなくてもよい。支払いの分野における実世界の適用は、かかる「オフライン」使用例に依存している場合が多い。例えば、クライアント４００（例えば、スマートフォン）を用いるユーザは、トランザクションの時点で依拠当事者４５１への接続可能性を有しないことがあるが、トランザクションデバイス４５０を認証することによってトランザクション（例えば、支払い）を認証したいことがある。しかしながら、本発明のいくつかの実施形態では、クライアント４００及び／又はトランザクションデバイス４５０は、一部の情報を依拠当事者４５１と交換する（但し、本明細書に記載する認証又はトランザクション確認プロセスの間は必須ではない）。

従来、ユーザ検証は、デバイス（例えば、ＰｏＳトランザクションデバイス又はＡＴＭ）によって捕捉される個人識別番号（ＰＩＮ）などの秘密を使用して実現されてきた。次に、デバイスは、秘密を検証するために、依拠当事者に対するオンライン接続を作成するか、又はＰＩＮを検証するためにユーザの認証部（例えば、ＥＭＶ銀行カード）を求める。かかる実装形態はいくつかの不利な点を有する。利用可能なときがあるが常に利用可能ではない、オンライン接続を要することがある。また、長期間有効な秘密を信頼できない可能性があるデバイスにユーザが入力する必要があり、そのことによってショルダーサーフィン及び他の攻撃に晒される。それに加えて、本質的に、特定のユーザ検証方法（例えば、この場合はＰＩＮ）に縛られる。最後に、ＰＩＮなどの秘密をユーザが覚えておく必要があり、それがユーザにとって不便なことがある。

本明細書に記載する認証技術は、ユーザが自身のクライアントの認証能力に依存することができるので、ユーザ検証方法及びセキュリティの点で大幅な柔軟性を提供する。特に、一実施形態では、クライアントが依拠当事者に接続されている時間の間、ユーザのクライアント上のモバイルアプリケーションは、依拠当事者によって提供される認証要求をキャッシュに入れる。認証要求は、上述の認証要求と同じ（又は類似の）情報（例えば、認証部と関連付けられたナンス及び公開鍵）、並びに依拠当事者によって生成される認証要求（少なくともその一部）に対する署名、検証鍵、及び潜在的に、認証要求が有効であり続ける期間（又は逆に、認証要求の期限が切れた後の時間）を示すタイミングデータを含む追加情報を含んでもよい。一実施形態では、モバイルアプリケーションは、複数のかかる接続要求（例えば、各トランザクションデバイス又はトランザクションデバイスの種類に対して１つずつ）をキャッシュに入れてもよい。

一実施形態では、キャッシュに入れた認証要求は、次に、クライアント／モバイルアプリケーションが依拠当事者と接続できない状況で、トランザクションデバイスとのトランザクションに使用されてもよい。一実施形態では、モバイルアプリケーションは、ｓｅｒｖｅｒＤａｔａ及びトランザクションデバイスから受信した追加データを含む、キャッシュに入れた認証要求に基づいて、認証応答の作成を始動させる。認証応答は、次に、トランザクションデバイスに送信され、それが次に、（例えば、トランザクションデバイスが依拠当事者と接続されている時間の間に）依拠当事者からの検証鍵を使用して認証応答を検証する。特に、トランザクションデバイスは、依拠当事者によって提供される鍵を使用して、認証応答に含まれるｓｅｒｖｅｒＤａｔａに対する署名を検証してもよい。一実施形態では、署名は、秘密の依拠当事者検証鍵を使用して依拠当事者によって生成され、トランザクションデバイスは、対応する公開依拠当事者検証鍵（依拠当事者によってトランザクションデバイスに提供される）を使用して、署名を検証する。

トランザクションデバイスが、認証応答から抽出したｓｅｒｖｅｒＤａｔａを検証すると、認証要求から抽出した公開鍵（例えば、Ｕａｕｔｈ．ｐｕｂ）を使用して、（例えば、クライアントが依拠当事者を直接認証しているときの、上述の依拠当事者による検証と同じ又は類似の方法で）クライアント／モバイルアプリケーションによって生成された認証応答を検証してもよい。

後述する代替実施形態では、依拠当事者は、認証要求を（クライアントデバイス上のモバイルアプリケーションを通してではなく）直接トランザクションデバイスに提供する。この実施形態では、トランザクションデバイスは、クライアント上のモバイルアプリケーションからトランザクションを完了する要求を受信すると、依拠当事者からの認証要求を求めてもよい。認証要求を有すると、上述したように（例えば、署名を生成し、それを既存の署名と比較することによって）要求及び認証応答を有効化してもよい。

図５Ａは、クライアント４００が認証要求をキャッシュに入れる実施形態における、クライアント４００、トランザクションデバイス４５０、及び依拠当事者の間での相互作用を示すトランザクション図である。この実施形態は、トランザクションデバイス４５０が依拠当事者との既存の接続を有することを要しないので、場合によっては「完全オフライン」実施形態と称される。

５０１において、クライアントは、依拠当事者からのキャッシュ可能な認証要求を要求する。５０２において、依拠当事者は、キャッシュ可能な認証要求を生成し、５０３において、認証要求がクライアントに送られ、５０４において、クライアントは、認証要求をキャッシュに入れる。一実施形態では、認証要求は、認証に使用される認証部と関連付けられた公開鍵（Ｕａｕｔｈ．ｐｕｂ）と、公開鍵及びランダムナンスに対して依拠当事者検証鍵（ＲＰＶｅｒｉｆｙＫｅｙ）を使用して生成された署名とを含む。非対称鍵が使用される場合、依拠当事者によって署名を生成するのに使用されるＲＰＶｅｒｉｆｙＫｅｙは、（潜在的に、ユーザ認証要求を処理するはるか前に）依拠当事者がトランザクションデバイスに提供した、対応する公開ＲＰＶｅｒｉｆｙＫｅｙを有する秘密鍵である。

一実施形態では、認証要求はまた、認証要求が有効である時間長（例えば、ＭａｘＣａｃｈｅＴｉｍｅ）を示すタイミング情報を含む。この実施形態では、キャッシュ可能な認証要求に対する署名は、公開認証鍵、ナンス、及びＭａｘＣａｃｈｅＴｉｍｅの組み合わせに対して生成されてもよい（例えば、ＳｅｒｖｅｒＤａｔａ＝Ｕａｕｔｈ．ｐｕｂ｜ＭａｘＣａｃｈｅＴｉｍｅ｜ｓｅｒｖｅｒＮｏｎｃｅ｜Ｓｉｇｎ（ＲＰＶｅｒｉｆｙＫｅｙ，Ｕａｕｔｈ．ｐｕｂ｜ＭａｘＣａｃｈｅＴｉｍｅ｜ｓｅｒｖｅｒＮｏｎｃｅ））。一実施形態では、認証応答は、１つを超える認証鍵（例えば、ユーザを認証することができる各認証部に対して１つずつ）を含み、署名は、（例えば、ナンス及びＭａｘＣａｃｈｅＴｉｍｅと共に）これらの鍵全てに対して生成されてもよい。

上述したように、公開ＲＰＶｅｒｉｆｙＫｅｙを、トランザクションデバイス４５０、又は認証要求／応答のオフライン検証を実行するように意図された任意のデバイスが知る必要がある。トランザクションデバイスは、依拠当事者において登録された認証鍵に関する知識を何ら有しない（すなわち、ユーザデバイスとトランザクションデバイスとの間に確立された関係が存在しない）ので、この拡張が求められる。結果として、依拠当事者は、鍵が認証応答検証に使用されるセキュアな方法で、トランザクションデバイス（又は他のデバイス）と通信しなければならない。トランザクションデバイスは、ＭａｘＣａｃｈｅＴｉｍｅを検証して、（キャッシュに入れた認証要求をいつまで使用できるかに関する依拠当事者のポリシーに準拠するために）キャッシュに入れた認証要求がまだ有効であるかどうかを判定する。

５０５において、クライアントは、トランザクションデバイスに対するセキュアな接続を確立し、トランザクションを開始する。例えば、トランザクションデバイスがＰｏＳトランザクションデバイスである場合、トランザクションは、デビット又はクレジットトランザクションを伴うことがある。トランザクションデバイスがＡＴＭである場合、トランザクションは、現金払い戻し又はメンテナンス作業を伴うことがある。本発明の基本原理は、任意の特定の種類の鍵又は鍵の生成方法に限定されるものではない。加えて、５０５において、クライアントは、キャッシュに入れた認証要求をトランザクションデバイスに送信してもよい。

それに応答して、５０６において、トランザクションデバイスは、トランザクションを完了するため、デバイス識別情報（例えば、トランザクションデバイス識別コード）、ランダムチャレンジ（ナンス）、及び任意選択的に定義された構文のトランザクションテキストを送信してもよい。ランダムチャレンジ／ナンスは、次に、認証応答に対して暗号的に結合される。このメカニズムによって、ユーザ検証が新しいものであってキャッシュ／再使用されていないことを、デバイスが検証することが可能になる。

上述したもの（例えば、図３Ａ～Ｂ及び関連する文章を参照）などのトランザクション確認をサポートするために、トランザクションデバイスは、標準化された人間が読み取り可能なトランザクションの表現を作成することが求められることがある。「標準化」は、本明細書で使用するとき、依拠当事者（例えば、以下の動作５１１に示されるような最終検証のため）及び／又はトランザクションデバイスが解析することができる形式を意味する。トランザクション確認には、認証部をクライアント４００のセキュアなディスプレイ上に表示する必要があるので、人間が読み取り可能である必要がある。かかる符号化の一例はＸＭＬであることができ、その場合、ＸＳＬＴは可視化のために使用される。

５０７において、認証応答を生成するため、特定の認証部を使用してクライアントに対して認証を実行する（例えば、指紋センサを指スワイプする、ＰＩＮコードを入力する、マイクロフォンに向かって発話するなど）ようにユーザに指示する、認証ユーザインターフェースが表示される。ユーザが認証を提供すると、クライアントの認証エンジンは、ユーザの個人情報を検証し（例えば、ユーザから収集した認証データを、認証部のセキュアストレージに格納されたユーザ検証基準データと比較する）、認証デバイスと関連付けられた秘密鍵を使用して、ランダムチャレンジに対して署名（また潜在的に、トランザクションデバイスＩＤ及び／又はトランザクションテキスト）を暗号化及び／又は生成する。次に、認証応答は、５０８でトランザクションデバイスに送信される。

５０９において、トランザクションデバイスは、公開ＲＰＶｅｒｉｆｙＫｅｙを使用して、（５０５で受信した）ｓｅｒｖｅｒＤａｔａに対する署名の検証がまだ行われていなければ、検証を行う。ｓｅｒｖｅｒＤａｔａが検証されると、認証を行うのに使用される認証部と関連付けられた公開鍵（Ｕａｕｔｈ．ｐｕｂ）が分かる。この鍵を使用して、認証応答を検証する。例えば、公開認証鍵を使用して、ナンス及び他の任意の関連情報（例えば、トランザクションテキスト、トランザクションデバイスＩＤなど）に対して生成された署名を復号又は検証してもよい。トランザクション確認がトランザクションデバイスによって実行される場合、５０８において、トランザクションテキストに対して生成され認証応答に含まれた署名を有効化することによって、クライアントに表示されたトランザクションテキストを検証してもよい。暗号的にセキュアなｓｅｒｖｅｒＤａｔａ構造を有する代わりに、トランザクションデバイスはまた、依拠当事者に対するオンライン接続が利用可能な場合（セミオフラインの場合）、その接続を使用して、無署名のｓｅｒｖｅｒＤａｔａを検証することができる。

５１０において、認証が成功したかしなかったかに応じて、成功又は失敗の指標がクライアントに送られる。成功した場合、トランザクションデバイスは、トランザクション（例えば、購入を完了するための口座の借方記入／貸方記入、現金の自動支払い、会計作業の実行など）を許可する。成功しなかった場合、トランザクションを却下する、かつ／又は追加の認証を要求する。

依拠当事者に対する接続が存在する場合、５１１において、トランザクションデバイスは、依拠当事者に対する認証応答、及び／又はトランザクションテキスト（依拠当事者がトランザクションテキストの検証の責任を負うエンティティであると仮定）を送信してもよい。トランザクションの記録は依拠当事者において記録されてもよく、かつ／又は依拠当事者はトランザクションテキストを検証し、トランザクション（図示なし）を確認してもよい。

図５Ｂは、トランザクションデバイスが依拠当事者との接続を有し、そこからの認証要求を受信する実施形態における、クライアント４００、トランザクションデバイス４５０、及び依拠当事者の間での相互作用を示すトランザクション図である。この実施形態は、クライアントは依拠当事者に対する接続を有しないが、トランザクションデバイス４５０は有するので、場合によっては「セミオフライン」実施形態と称される。

５２１において、クライアントは、トランザクションを開始して、トランザクションデバイス（例えば、ＮＦＣ、Ｂｌｕｅｔｏｏｔｈなど）とのセキュアな接続を確立する。５２２において、トランザクションデバイスは、応答として依拠当事者に対する認証要求を求める。５２３において、依拠当事者は認証要求を生成し、５２４において、認証要求がトランザクションデバイスに送られる。図５Ａに示される実施形態のように、認証要求は、認証に使用されるクライアントの認証部と関連付けられた公開鍵（Ｕａｕｔｈ．ｐｕｂ）と、公開鍵及びランダムナンスに対して依拠当事者認証鍵（ＲＰＶｅｒｉｆｙＫｅｙ）を使用して生成される署名とを含んでもよい。非対称鍵が使用される場合、依拠当事者によって署名を生成するのに使用されるＲＰＶｅｒｉｆｙＫｅｙは、（潜在的に、ユーザ認証要求を処理するはるか前に）依拠当事者がトランザクションデバイスに提供する、対応する公開ＲＰＶｅｒｉｆｙＫｅｙを有する秘密鍵である。暗号的にセキュアなｓｅｒｖｅｒＤａｔａ構造を有する代わりに、トランザクションデバイスはまた、依拠当事者に対するオンライン接続が利用可能な場合（セミオフラインの場合）、その接続を使用して、無署名のｓｅｒｖｅｒＤａｔａを検証してもよい。

一実施形態では、ｓｅｒｖｅｒＤａｔａはまた、認証要求が有効である時間長（例えば、ＭａｘＣａｃｈｅＴｉｍｅ）を示すタイミング情報を含む。この実施形態では、ｓｅｒｖｅｒＤａｔａに対する署名は、公開認証鍵、ナンス、及びＭａｘＣａｃｈｅＴｉｍｅの組み合わせに対して生成されてもよい（例えば、ＳｅｒｖｅｒＤａｔａ＝Ｕａｕｔｈ．ｐｕｂ｜ＭａｘＣａｃｈｅＴｉｍｅ｜ｓｅｒｖｅｒＮｏｎｃｅ｜Ｓｉｇｎ（ＲＰＶｅｒｉｆｙＫｅｙ，Ｕａｕｔｈ．ｐｕｂ｜ＭａｘＣａｃｈｅＴｉｍｅ｜ｓｅｒｖｅｒＮｏｎｃｅ））。一実施形態では、認証応答は、１つ以上の認証鍵（例えば、各認証部に対して１つずつ）を含み、署名は、（例えば、ナンス及びＭａｘＣａｃｈｅＴｉｍｅと共に）これらの鍵全てに対して生成されてもよい。

一実施形態では、図５Ｂのトランザクション図の残りは、実質的に図５Ａに示されるように動作する。５２５において、トランザクションデバイスは、トランザクションを完了するため、識別情報（例えば、トランザクションデバイス識別コード）、ランダムチャレンジ（ナンス）、及び任意選択的に定義された構文のトランザクションテキストを送信してもよい。ランダムチャレンジ／ナンスは、次に、認証応答に対して暗号的に結合される。このメカニズムによって、ユーザ検証が新しいものであってキャッシュ／再使用されていないことを、デバイスが検証することが可能になる。

上述したもの（例えば、図３Ａ～Ｂ及び関連する文章を参照）などのトランザクション確認をサポートするために、トランザクションデバイスは、標準化された人間が読み取り可能なトランザクションの表現を作成することが求められることがある。「標準化」は、本明細書で使用するとき、依拠当事者（例えば、以下の動作５１１に示されるような最終検証のため）及び／又はトランザクションデバイスが解析することができる形式を意味する。トランザクション確認には、認証部をクライアント４００のセキュアなディスプレイ上に表示する必要があるので、人間が読み取り可能である必要がある。かかる符号化の一例はＸＭＬであることができ、その場合、ＸＳＬＴは可視化のために使用される。

５２６において、認証応答を生成するため、特定の認証部を使用してクライアントに対して認証を実行する（例えば、指紋センサを指スワイプする、ＰＩＮコードを入力する、マイクロフォンに向かって発話するなど）ようにユーザに指示する、認証ユーザインターフェースが表示される。ユーザが認証を提供すると、クライアントの認証エンジンは、ユーザの個人情報を検証し（例えば、ユーザから収集した認証データを、認証部のセキュアストレージに格納されたユーザ検証基準データと比較する）、認証デバイスと関連付けられた秘密鍵を使用して、ランダムチャレンジに対して署名（また潜在的に、トランザクションデバイスＩＤ及び／又はトランザクションテキスト）を暗号化及び／又は生成する。次に、認証応答は、５２７でトランザクションデバイスに送信される。

５２８において、トランザクションデバイスは、公開ＲＰＶｅｒｉｆｙＫｅｙを使用して、（５２４で受信した）ｓｅｒｖｅｒＤａｔａに対する署名の検証がまだ行われていなければ、検証を行う。ｓｅｒｖｅｒＤａｔａが検証されると、認証を行うのに使用される認証部と関連付けられた公開鍵（Ｕａｕｔｈ．ｐｕｂ）が分かる。この鍵を使用して、認証応答を検証する。例えば、公開認証鍵を使用して、ナンス及び他の任意の関連情報（例えば、トランザクションテキスト、トランザクションデバイスＩＤなど）に対して生成された署名を復号又は検証してもよい。トランザクション確認がトランザクションデバイスによって実行される場合、５２８において、トランザクションテキストに対して生成され認証応答に含まれた署名を有効化することによって、クライアントに表示されたトランザクションテキストを検証してもよい。暗号的にセキュアなｓｅｒｖｅｒＤａｔａ構造を有する代わりに、トランザクションデバイスはまた、依拠当事者に対するオンライン接続が利用可能な場合（セミオフラインの場合）、その接続を使用して、無署名のｓｅｒｖｅｒＤａｔａを検証することができる。

５２９において、認証が成功したかしなかったかに応じて、成功又は失敗の指標がクライアントに送られる。成功した場合、トランザクションデバイスは、トランザクション（例えば、購入を完了するための口座の借方記入／貸方記入、現金の自動支払い、会計作業の実行など）を許可する。成功しなかった場合、トランザクションを却下する、かつ／又は追加の認証を要求する。

５３０において、トランザクションデバイスは、依拠当事者に対する認証応答、及び／又はトランザクションテキスト（依拠当事者がトランザクションテキストの検証の責任を負うエンティティであると仮定）を送信してもよい。トランザクションの記録は依拠当事者において記録されてもよく、かつ／又は依拠当事者はトランザクションテキストを検証し、トランザクション（図示なし）を確認してもよい。

図６に示されるように、一実施形態では、モバイルアプリケーション６０１は、認証クライアント６０２（図２Ｂに示されるセキュアトランザクションサービス２０１及びインターフェース２０２であってもよい）と組み合わせて、本明細書に記載する動作を実行するため、クライアントで実行される。特に、モバイルアプリケーション６０１は、トランスポート層セキュリティ（ＴＬＳ）又は他のセキュア通信プロトコルを使用して、トランザクションデバイス４５０で実行されるウェブアプリケーション６１１に対してセキュアチャネルを開いてもよい。トランザクションデバイスのウェブサーバ６１２も、（例えば、上述したように、認証要求を取得するため、及び／又は依拠当事者４５１に更新を提供するため）依拠当事者４５１と通信するセキュアチャネルを開いてもよい。認証クライアント６０２は、例えば、（詳細に上述したような）キャッシュ可能な認証要求を取得するため、依拠当事者４５１と直接通信してもよい。

一実施形態では、認証クライアント６０２は、依拠当事者によって利用可能にされた各アプリケーションと関連付けられた固有のコードである「ＡｐｐＩＤ」を用いて、依拠当事者及び任意の認証済みモバイルアプリケーション６０１を識別してもよい。依拠当事者が複数のオンラインサービスを提供する幾つかの実施形態において、ユーザは、単一の依拠当事者との間で複数のＡｐｐＩＤを有し得る（依拠当事者によって提供される各サービスに対して１つずつ）。

一実施形態では、ＡｐｐＩＤによって識別されるいずれのアプリケーションも、依拠当事者と接続するための許容メカニズム及び／又はアプリケーションタイプを識別する、複数の「ファセット」を有してもよい。例えば、特定の依拠当事者は、ウェブサービスを介した、また異なるプラットフォーム専用のモバイルアプリケーション（例えば、アンドロイドアプリケーション、ｉＯＳアプリケーションなど）を介したアクセスを可能にしてもよい。これらはそれぞれ、依拠当事者によって図示されるような認証エンジンに提供されてもよい、異なる「ＦａｃｅｔＩＤ」を使用して識別されてもよい。

一実施形態では、呼出しモバイルアプリケーション６０１はそのＡｐｐＩＤを、認証クライアント６０２によって公表されたＡＰＩに渡す。各プラットフォーム上で、認証クライアント６０２は、呼出しアプリケーション６０１を識別し、そのＦａｃｅｔＩＤを判定する。次に、ＡｐｐＩＤを分解し、ＦａｃｅｔＩＤが、依拠当事者４５１によって提供されるＴｒｕｓｔｅｄＡｐｐｓリストに含まれるかどうかをチェックする。

一実施形態では、上述のキャッシュ可能な認証要求は、図７及び８に示されるようなベアラートークンを使用して実現されてもよい。本明細書に記載する本発明の実施形態では、トークン受領者（トランザクションデバイス４５０）は、トークン発行者（依拠当事者）に対する別の「オンライン」接続を要することなく、トークン、認証応答、及び認証応答に対するトークンの結合を検証可能である必要がある。

ベアラートークンの２つの分類を区別すべきである。

１． トークン発行とトークン検証との間は存在していなければならない、発行者（例えば、依拠当事者４５１）に対する異なるチャネルを使用して、受領者（例えば、トランザクションデバイス４５０）によってのみ検証可能なトークン。このトークンの分類は、本明細書では「無署名トークン」と称される。

２． 暗号的構造により、例えば、潜在的には特定のトークンが発行されるよりも大分前に、トークン発行者から受信したデータを使用して検証することができるデジタル署名を含むことにより、受領者によって検証可能なトークン。このトークンの分類は、本明細書では「署名トークン」と称される。

「署名付きトークン構造」という用語は、本明細書では、Ｕａｕｔｈ．ｐｕｂ鍵を含む署名付きトークン、及びトークンを含む署名付き構造の両方を指すのに使用される。
認証鍵に対する署名付きトークンの結合

図７に示されるように、一実施形態では、署名付きトークンを認証鍵に結合するために、トークン発行者（例えば、依拠当事者４５１）は：（ａ）認証公開鍵（Ｕａｕｔｈ．ｐｕｂ）７０２を署名（待ち）トークンの署名待ち部分７０１に追加し；（ｂ）その署名付きトークンを認証応答の署名待ち部分に含める。これを行うことによって、トークン受領者（例えば、トランザクションデバイス４５０）は、署名７０３（例えば、上述の公開ＲＰＶｅｒｉｆｙＫｅｙ）を有効化することによって、トークンを検証することができる。検証が成功した場合、上述したように、公開鍵（Ｕａｕｔｈ．ｐｕｂ）を抽出し、それを使用して認証応答を検証することができる。
認証鍵に対する無署名トークンの結合

図８に示されるように、無署名トークン８０２を認証鍵に結合するために、一実施形態では、トークン発行者（例えば、依拠当事者４５１）は、（少なくとも）元のトークン８０２と認証公開鍵（Ｕａｕｔｈ．ｐｕｂ）を含む署名待ちデータ８０１とを網羅する、署名付き構造を作成する。署名付き構造は、秘密署名鍵（例えば、上述のＲＰＶｅｒｉｆｙＫｅｙ対）に関連する公開鍵を使用して、署名８０３を有効化することによって、検証することができる。この公開署名鍵は、トークン受領者（例えば、トランザクションデバイス４５０）と共有する必要がある。共有は、署名鍵対を生成した後に、潜在的には第１の署名付き構造がよりも生成される大分前に行うことができる。

本明細書に記載する技術は、「完全オフライン」実装形態（すなわち、トランザクションの時点でトランザクションデバイス４５０が依拠当事者４５１に対する接続を有しない）、並びに「セミオフライン」実装形態（すなわち、トランザクションの時点でトランザクションデバイスは依拠当事者４５１に対する接続を有するが、クライアントは有しない）の両方をサポートする。

完全オフラインの場合であっても、トランザクションデバイス４５０は依然として、依拠当事者４５１に対してホストを介して時々接続されることが予想される。例えば、ホストは、トランザクションデバイス４５０に格納された全ての応答を、依拠当事者に送るために収集してもよく、また、取り消されたＵａｕｔｈ鍵（例えば、最後の接続以降は取り消されている公開認証鍵）のリストを更新（必要であれば）してもよい。

いくつかの実施形態は、純粋な（セッション）認証並びにトランザクション確認もサポートする。トランザクション確認の場合であっても、依拠当事者４５１は、トランザクションデバイス４５０がトランザクションテキストを認証応答と共に依拠当事者４５１に提出する場合、トランザクションを検証することができる。

本明細書に記載する技術に対して、いくつかの異なる使用事例／アプリケーションがある。例：

１． 支払い。ユーザは、自身の認証部（例えば、スマートフォン）に支払いサービス提供者（ＰＳＰ）を登録している。ユーザは、ＰＳＰによって認証された売場専用デバイス（ＰｏＳ）を使用して、あるマーチャントでの支払いを認証したいが、ＰｏＳは、（例えば、バスに配置された）ＰＳＰに対する信頼できる恒久的なオンライン接続を有しない。この例では、信頼できる恒久的な接続がないにも関わらずトランザクションを可能にするため、上述したように、ＰｏＳはトランザクションデバイス４５０として実装されてもよく、ＰＳＰは依拠当事者４５１として実装されてもよい。

２． 物のインターネット。企業は、（例えば、工場、ビルなどに）いくつかの埋め込みデバイスをインストールしている。かかるデバイスのメンテナンスは、契約当事者が雇用した技術者によって実行される。メンテナンスを実行するため、技術者は、その作業に対する自身の適格性を証明するために、デバイスに対して認証しなければならない。以下の仮定が（現実の構成条件に基づいて）行われる。
ａ． 技術者は、かかるデバイスそれぞれの登録を実行することはできない（デバイスが多すぎるため）。
ｂ． デバイスそれぞれにおいて適格技術者のリストを細心に保つためには、技術者の人数が多すぎ、かかる技術者のばらつきが大きすぎる。
ｃ． デバイスも技術者のコンピュータも、メンテナンスの時点で信頼できるネットワーク接続を有しない。

上述の技術を使用して、企業は、トラストアンカー（例えば、公開ＲＰＶｅｒｉｆｙＫｅｙ）を全てのデバイスに一度に（例えば、インストール時に）注入することができる。各技術者は、次に、契約当事者（例えば、技術者の雇用主であってもよい依拠当事者４５１を登録する。上述の技術を使用して、技術者は、各デバイスを認証することができる。

上述した本発明の実施形態は、認証能力を有するクライアントが依拠当事者を登録するいずれかのシステムで実現されてもよく、認証動作は、このクライアントと、（ａ）依拠当事者の代理を果たす、（ｂ）トランザクションの時点でオフラインである（すなわち、クライアントが登録している依拠当事者の元のサーバに対して信頼できるネットワーク接続を有していない）、デバイスとの間で実行される。かかる例では、クライアントは、キャッシュ可能な認証要求を元のサーバから受信し、それをキャッシュに入れる。要求されると、クライアントは認証応答を計算し、それをデバイスに送る。

別の実施形態では、クライアントは、暗号的にセキュアな方法で、チャネル結合データ（認証要求で受信される）を応答に追加する。これを行うことによって、依拠当事者の元のサーバは、要求が（何らかの中間者ではなく）合法的なクライアントによって受信されたことを検証することができる。

一実施形態では、依拠当事者は、許可されたＵａｕｔｈ．ｐｕｂ鍵を取得するために依拠当事者サーバにコンタクトする必要なしに、デバイスが認証又はトランザクション確認応答を検証することを可能にするＵａｕｔｈ．ｐｕｂ鍵など、追加の認証済みデータを応答に追加する。別の実施形態では、依拠当事者は、（サービス攻撃の拒否を防止するために）「キャッシュ可能な」認証要求を発行する前に、クライアントのユーザが成功する認証を実行することを要求する。一実施形態では、依拠当事者は、要求がキャッシュ可能であるか否かをクライアントが示すことを要求する。キャッシュ可能である場合、依拠当事者は、応答において追加の認証データを要求してもよい（例えば、上述のＭａｘＣａｃｈｅＴｉｍｅ）。

一実施形態では、トランザクションデバイス４５０などのデバイスは、依拠当事者に対する直接ネットワーク接続を有さず、別個のコンピュータ（本明細書では、「ホスト」と称されることがある）を使用して、依拠当事者に「同期」される。このホストは、全ての収集された認証応答をデバイスから取得し、それらを依拠当事者に転送する。それに加えて、ホストはまた、取り消されたＵａｕｔｈ鍵のリストをデバイスにコピーして、取り消された鍵の１つが認証応答で使用されていないことを保証してもよい。

一実施形態では、トランザクションデバイス４５０などのデバイスは、ランダム値（例えば、ナンス）をクライアントに送り、クライアントは、このランダム値を、署名前の認証応答に対する拡張として、暗号的に追加する。この署名付きランダム値は、デバイスに対する鮮度の証明として役立つ。

一実施形態では、クライアントの認証部は、署名前の認証応答に対する拡張として、現在時間Ｔａを追加する。デバイス／トランザクションデバイスは、その時間を現在時間Ｔｄと比較し、ＴａとＴｄとの差が許容可能である場合（例えば、差が２分未満（ａｂｓ（Ｔｄ－Ｔａ）＜２分）である場合）にのみ、応答を許容してもよい。

一実施形態では、依拠当事者は、認証済み（すなわち、署名付き）の有効期限をキャッシュ可能な要求に追加する。上述したように、デバイス／トランザクションデバイスは、有効期限前に受信された場合にのみ、応答を有効であるとして許容する。

一実施形態では、依拠当事者は、公開鍵、有効期限、最大トランザクション値（例えば、セキュリティアサーションマークアップランゲージ（ＳＡＭＬ）アサーション、ＯＡｕｔｈトークン、ＪＳＯＮウェブ署名（ＪＷＳ）オブジェクトなど）などの（但しそれらに限定されない）、キャッシュ可能な要求に対する追加情報を含む、認証済み（即ち、署名付き）のデータブロック（例えば、上述の「署名付きトークン構造」）を追加する。デバイス／トランザクションデバイスは、署名付きデータブロックを肯定的に検証でき、内容が許容可能である場合にのみ、応答を有効として許容してもよい。

一実施形態では、依拠当事者は、署名トークンのみをキャッシュ可能な認証要求に追加するが、トランザクションデバイスは、トランザクションの時点で依拠当事者に対するオンライン接続を有する。トランザクションデバイスは、トランザクションの時点で依拠当事者に対するオンライン接続を使用して、無署名トークンの信頼性を検証する。

図９は、本発明の一実施形態による、例示の「オフライン」及び「セミオフライン」認証シナリオを示す。この実施形態では、コンピュータデバイス９１０を有するユーザは、依拠当事者９３０に対する確立された関係を有し、依拠当事者を認証することができる。しかしながら、いくつかの状況では、ユーザは、依拠当事者９３０に対する確立された関係を有するが、ユーザのコンピュータデバイス９１０に対しては必ずしも有しないデバイス９７０を用いて、トランザクション（例えば、トランザクション確認の認証）を実行することを望む。この実施形態に関して、トランザクションは、接続９２０及び接続９２１が存在しないか、関連がある時点（例えば、ユーザのコンピュータデバイス９１０をデバイス９７０に対して認証する時点、又はユーザのコンピュータデバイス９１０とデバイス９７０との間のトランザクションの時点）で安定しない場合、「完全オフライン」と称される。この実施形態に関して、トランザクションは、ユーザのコンピュータデバイス９１０と依拠当事者９３０との間の接続９２０は安定しないが、デバイス９７０と依拠当事者９３０との間の接続９２１は安定している場合に、「セミオフライン」である。この実施形態では、ユーザのコンピュータデバイス９１０とデバイス９７０との間の接続９２２は、関連がある時点で安定している必要があることに留意されたい。認証部がユーザのコンピュータデバイス９１０に接続されることもまた、予想される。接続９２２は、ブルートゥース、ブルートゥースローエナジー（ＢＴＬＥ）、近距離無線通信（ＮＦＣ）、Ｗｉｆｉ、汎欧州デジタル移動電話方式（ＧＳＭ）、ユニバーサル移動体通信システム（ＵＴＭＳ）、ロングタームエボリューション（ＬＴＥ）（例えば、４Ｇ ＬＴＥ）、及びＴＣＰ／ＩＰを含むがそれらに限定されない、あらゆる種類の通信チャネル／プロトコルを使用して実現することができる。
例示的なデータ処理デバイス

図１０は、本発明のいくつかの実施形態において使用することができる例示的なクライアント及びサーバを図示するブロック図である。図１０は、コンピュータシステムの様々な構成要素を図示しているが、そのような詳細は本発明に適切でないため、構成要素を相互接続する任意の特定のアーキテクチャ又は方法を表すことを意図するものではないことを理解すべきである。より少ない構成要素又は複数の構成要素を有する他のコンピュータシステムもまた、本発明によって使用可能であることが理解されるであろう。

図１０に示されるように、データ処理システムの形態であるコンピュータシステム１０００は、処理システム１０２０に結合されているバス（複数可）１０５０と、電源１０２５と、メモリ１０３０と、不揮発性メモリ１０４０（例えば、ハードドライブ、フラッシュメモリ、相変化メモリ（ＰＣＭ）など）とを含む。バス（複数可）１０５０は、当該技術分野において周知であるように、様々なブリッジ、コントローラ及び／又はアダプタを介して互いに接続され得る。処理システム１０２０は、メモリ１０３０及び／又は不揮発性メモリ１０４０から命令（複数可）を取得することができ、上述したように動作を実行するための命令を実行することができる。バス１０５０は、上記構成要素を一体に相互接続し、また、任意選択的なドック１０６０、ディスプレイコントローラ及びディスプレイデバイス１０７０、入力／出力デバイス１０８０（例えば、ＮＩＣ（ネットワークインターフェースカード）、カーソル制御（例えば、マウス、タッチスクリーン、タッチパッドなど）、キーボードなど）及び任意選択的な無線送受信機（複数可）１０９０（例えば、Ｂｌｕｅｔｏｏｔｈ、ＷｉＦｉ、赤外線など）にそれらの構成要素を相互接続する。

図１１は、本発明のいくつかの実施形態において使用され得る例示的なデータ処理システムを図示するブロック図である。例えば、データ処理システム１９０は、ハンドヘルドコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、携帯電話、ポータブルゲームシステム、ポータブルメディアプレーヤ、タブレット、又は、携帯電話、メディアプレーヤ及び／又はゲームシステムを含むことができるハンドヘルドコンピューティングデバイスとすることができる。別の例として、データ処理システム１１００は、ネットワークコンピュータ又は別のデバイス内の埋め込み処理デバイスとすることができる。

本発明の１つの実施形態によれば、データ処理システム１１００の例示的なアーキテクチャは、上述した携帯デバイスのために使用することができる。データ処理システム１１００は、集積回路上の１つ以上のマイクロプロセッサ及び／又はシステムを含むことができる処理システム１１２０を含む。処理システム１１２０は、メモリ１１１０、（１つ以上のバッテリを含む）電源１１２５、オーディオ入力／出力１１４０、ディスプレイコントローラ及びディスプレイデバイス１１６０、任意選択的な入力／出力１１５０、入力デバイス（複数可）１１７０及び無線送受信機（複数可）１１３０に結合されている。図１１には図示されない追加の構成要素も、本発明の特定の実施形態におけるデータ処理システム１１００の一部であってもよく、本発明の特定の実施形態では、図１１に示されているのよりも少数の構成要素が使用されてもよいことが理解されるであろう。更に、図１１には示されていない１つ以上のバスは、当該技術分野において周知であるように様々な構成要素を相互接続するために使用することができることが理解されるであろう。

メモリ１１１０は、データ処理システム１１００による実行のためのデータ及び／又はプログラムを格納することができる。音声入力／出力１１４０は、例えば、音楽を再生するためのマイクロフォン及び／又はスピーカを含むことができ、並びに／又はスピーカ及びマイクロフォンを介して電話機能を提供することができる。ディスプレイコントローラ及びディスプレイデバイス１１６０は、グラフィカルユーザインターフェース（ＧＵＩ）を含むことができる。無線（例えば、ＲＦ）送受信機１１３０（例えば、ＷｉＦｉ送受信機、赤外線送受信機、Ｂｌｕｅｔｏｏｔｈ送受信機、無線携帯電話送受信機など）は、他のデータ処理システムと通信するために使用することができる。１つ以上の入力デバイス１１７０は、ユーザがシステムに入力を提供することを可能にする。これらの入力デバイスは、キーパッド、キーボード、タッチパネル、マルチタッチパネルなどとすることができる。任意選択的な他の入力／出力１１５０は、ドック用コネクタとすることができる。
プログラムコードインジェクションを防止するための装置及び方法

コンテンツセキュリティポリシー（ＣＳＰ）及びサブリソース完全性（ＳＲＩ）などの既存のウェブ完全性保護方法は、メインのハイパーテキストマークアップ言語（ＨＴＭＬ）ページによって参照される外部要素の完全性を保護することができる。しかしながら、それらはクライアントによってサポートされている場合にのみ作用し、メインＨＴＭＬページは、ローディング中に中間者（ＭＩＴＭ）攻撃を受けることはなかった。公開鍵のピン留め（Public Key Pinning）、証明書の透明性、及び更にトークンバインドなどの既存の保護技術は、そのような攻撃に対する完全な保護を提供しない。

ＦＩＤＯ／ウェブ認証応答を提出する場合、トークンバインドなどの技術が必要であり、これによりサーバは、結果として生じる認証セッションが、認証部に接続されたクライアントによって所有され、ＭＩＴＭ攻撃者などのなんらかの第三者が所有していないであろうことを検証することができる。

悪意のあるＪａｖａＳｃｒｉｐｔは、中間者攻撃の結果としてしばしば注入されるが、これは、ブラウザが特定のＵＲＬからリソースをフェッチしようとした場合に、代わりに悪意のあるサーバから修正されたリソースをフェッチする羽目になってしまうことである。図１２は、ＭＩＴＭ１２１１がクライアント／ブラウザ１２１０とサーバ１２１２との間の通信をインターセプトする例を示す。

ブラウザは、ドメインネームサービス（ＤＮＳ）を使用して、サーバ名をＩＰアドレスに分解し、トランスポート層セキュリティ（ＴＬＳ）を使用してサーバを認証し、クライアントとサーバとの間で交換されたトラフィックを暗号化する。サーバは、クライアントから信頼されているＴＬＳ認証局（ＣＡ）から発行されたＴＬＳサーバ証明書を使用して認証される。残念ながら、ＴＬＳ ＣＡは、証明書を攻撃者に悪意を持って発行し、時には攻撃者が依拠当事者のＴＬＳ証明書私有鍵を取得することができる場合がある。例えば、図１２のようにＭＩＴＭ１２１１は、ｓｅｒｖｅｒ．ｃｏｍに対して悪意を持って発行された証明書、又はｓｅｒｖｅｒ．ｃｏｍから盗まれた証明書と秘密鍵とを使用する可能性がある。

公開鍵のピン留めは、悪意を持って発行されたＴＬＳサーバ証明書から保護するように設計されているが、いくつかの欠点があり、大規模に採用されるまでには至っていない。これらの欠点を解決するために、証明書の透明性が提案されているが、まだ広くサポートされておらず、いくつかの弱点を有する。

公開鍵のピン留め（ＰＫＰ）と証明書の透明性（ＣＴ）とは対照的に、トークンバインドアプローチは、サーバが、クライアントが正しいエンティティに通信しているか否かを学習することを可能にする。ＰＫＰ及びＣＴの場合、サーバは、そのアプローチのためのサポートを実装するクライアントを信頼する必要がある。残念ながら、トークンバインドのみだけでは、ＭＩＴＭ保護を効果的に提供するのに十分ではない。例えば、典型的なウェブページには、潜在的に複数のソースから（例えば、ＧｏｏｇｌｅのＩＭＡ ＳＤＫ、Ｇｏｏｇｌｅ Ａｎａｌｙｔｉｃｓなど）のＪａｖａＳｃｒｉｐｔコードが含まれ、トークンバインドデータは、認証応答を受信するときにのみチェックされる。サインインページへのアクセスは、ユーザ認証なしで常に可能である。

ＦＩＤＯ及びウェブ認証は、ウェブ環境（及び他の環境）でユーザを認証するための簡単かつ安全な方法を提供する。ウェブ認証仕様は、中間者（ＭＩＴＭ）攻撃者によるセキュリティ／セッショントークンのエクスポートと再生に対するロバストな保護を追加するために、トークンバインディング（ＲＦＣ８４７１）のサポートを含む。

図１３は、典型的なウェブサイトロードプロセスのシーケンスを示す図である。クライアントは、サーバ１３１１へのリンクを選択すると、メインＨＴＭＬファイルをロードする。その後、メインＪａｖａＳｃｒｉｐｔファイルがロードされる。次いで、クライアントは、認証応答を送信し、サーバは保護された（例えば、認証に成功した場合にのみアクセス可能なデータ）コンテンツを返す。

実際には、典型的なウェブページは、クライアント１３１０によってロードされる２つ以上の要素から構成される。ウェブ認証アサーションに含まれるトークンバインドデータは１つだけで、認証応答を送信するときに接続に関連するものである。

図１４に示すように、これは、メインＨＴＭＬファイルをロードするとき、又はメインＪＳファイルをロードするときに（両方とも未認証クライアントが利用可能である）ＭＩＴＭ１４１２攻撃が、Ｗｅｂ認証応答でトークンバインドデータを検証するときにサーバ１３１１によって検出されないことを意味する。結果として、攻撃者は、悪意のあるＪａｖａＳｃｒｉｐｔコードを注入することができ、及び／又は潜在的な完全性保護ポリシーを改竄することができる。

改竄された外部オブジェクトをロードするリスクが、ウェブアプリケーションセキュリティコミュニティによって識別され、これらのタイプの攻撃に対して、主に２つのアプローチが開発されている。

アプローチの１つに、サブリソースの完全性（ＳＲＩ）があり、「完全性」属性を使用してＨＴＭＬコード内の外部リソースに対する予想されるハッシュ値の仕様を可能にする。メインウェブページが改竄されることなくロードされたという仮定の下で、ＳＲＩは、このウェブページが必要とするサブリソースが改竄されてロードされた場合、ブラウザがそれを拒否し、サーバに通知する可能性を持たせている。目下、多くのブラウザがＳＲＩをサポートしている。残念ながら、クライアント１３１０が、実装されたＳＲＩのサポートについてサーバ１３１１に通知する安全な方法はなく、また、クライアント１３１０が、メインＨＴＭＬページをロードする際に、受け取ったＳＲＩ「完全性」属性についてサーバ１３１１に通知する方法も存在しない。その理由は、悪意のあるＪａｖａＳｃｒｉｐｔが常に同じ通知呼出しをトリガできるからである。結果として、ＭＩＴＭ攻撃者１４１２は、メインＨＴＭＬページをロードするときにＳＲＩ「完全性」属性を修正することができる。

別のアプローチは、ＨＴＴＰヘッダで指定され、依拠当事者がＪａｖａｓｃｒｉｐｔコードなどの外部オブジェクトのトラステッドソースのリストを指定することを可能にする、コンテンツセキュリティポリシー（ＣＳＰ）である。また、そのようなコードのハッシュ値も指定することができる。残念ながら、ポリシー自体に対するＭＩＴＭ攻撃から保護する方法は提供されていない。メインＨＴＭＬファイルのローディングがすでにＭＩＴＭ攻撃の対象となっている場合、コンテンツセキュリティポリシーが悪意を持って弱体化される可能性がある。ＣＳＰの付加的な弱点も明らかにされている。

ＣＳＰ、ＳＲＩ、及び同様のアプローチの一般的に不利な点は、サーバ１３１１が、（１）クライアント１３１０が実際にこれらの概念をサポートし、コンテンツを検証したかどうか、（２）フェッチングされたメインウェブページ（ＭＩＴＭ１４１２を介して潜在的にフェッチされた）が正しい完全性保護ポリシーを含んでいたかどうかを学習することができないことである。

クライアントが完全なＣＳＰ及びＳＲＩサポートを有するメインＨＴＭＬページをロードした場合であっても、ロバストなＭＩＴＭ保護を提供するために、トークンバインドサポートが依然としてウェブ認証で必要とされていることに留意されたい。図１５を参照すると、ＭＩＴＭ１５１２がクライアント１３１０からの認証応答の伝送を標的とする場合、ＭＩＴＭ１５１２はその後、認証されたセッションを所有するであろう。そのような攻撃は、修正されたＨＴＭＬコード、修正されたＣＳＰ若しくはＳＲＩポリシー、又は修正されたＪＳコードに依存することにはならない。ＤＮＳポイズニング及び盗まれたＴＬＳサーバ証明書の秘密鍵へのアクセス（証明書の透明性サポートがある場合）又はサーバのドメインに対してＭＩＴＭ１４１２に悪意を持って発行されたＴＬＳサーバ証明書へのアクセス（証明書の透明性サポートがない場合）で十分である。残念ながら、ウェブブラウザにおけるトークンバインドサポートはまれである。その結果、ウェブアプリケーションでＡＡＬ３（ＮＩＳＴ８００－６３）のような認証保証レベルに達することは、現状、現実的ではない。

高いセキュリティを必要とするエンティティにとっての更なる課題は、それらが通常、コンピューティング環境を可能な限り制御できなくてはならないことである。これはまた、（破損していない）クライアント１３１０がセキュリティ対策を実施するかどうかを認識する必要があり、それらは通常、全ての依拠当事者に契約関係を要求することを意味する。許容可能なＴＬＳ認証局のリストを定義する各ＴＬＳ認証局又はブラウザベンダと二国間契約を締結することは、むしろ非現実的であると思われる。

図１６を参照すると、これらの制限に対処するために、サーバ１６１１の１つの実施形態は、クライアント１６１０で実行される動的にロードされたコードのセキュリティ特性を評価するためのクライアント評価器１６５０を含む。一実施形態は、上記の制限に対処するために以下の対策を実施する。まず、クライアント評価器１６５０は、クライアント１６１０がサポートする完全性保護手段を判定する。加えて、ウェブページ評価器１６５２は、ウェブページによって課された完全性保護方ポリシー（例えば、ＣＳＰ又はＳＲＩ）を判定し、また、ウェブページが改竄されたかどうかを判定するために、ウェブページを評価する。加えて、ウェブページ評価器は、ウェブページに関連する全ての外部オブジェクトのハッシュ値へのアクセスを提供され、及び／又は判定することができ、これは、ＣＳＰ及びＳＲＩサポートがない場合に関連するものである。

一実施形態は、認証応答が認証部１６３０を含むクライアント１６１０から直接受信されたのか、それともなんらかのＭＩＴＭを介して間接的に受信されたのかをサーバ１６１１が検証することを可能にするトークンバインドサポートを実施する。ここで、クライアント１６１０及びサーバ１６１１の詳細を、本発明の実施形態に従って提供する。
Ｉ． クライアント１６１０

クライアント１６１０の認証エンジン１６１３の一実施形態は、ウェブ認証データ（ＷＡＤ）ディクショナリ１６２０（例えば、既存のウェブ認証仕様内のＣｏｌｌｅｃｔｅｄＣｌｉｅｎｔＤａｔａディクショナリ）又はサポート付き完全性保護機能１６２０Ａのリスト及び関連付けられたバージョン番号（例えば、ＣＳＰ、ＳＲＩ、証明書の透明性、トークンバインドなど）を含むトークンバインド拡張部への拡張を含む。加えて、ＷＡＤディクショナリ１６２０の一実施形態は、ウェブページのローディングと関連付けられたリソース記述子１６２０Ｂのリストを含み、この場合、各リソース記述子は、以下の要素のうちの１つ以上を含む。
ａ． 対応するリソースの処理順序に関連するシーケンス番号。例えば、主ＨＴＭＬページは、シーケンス番号１を有することができ、最初に処理される外部リソースは、シーケンス番号２を有することになる。
ｂ． リソースがロードされたＵＲＬ（例えば、ｈｔｔｐｓ：／／ｗｗｗ．ｒｐ．ｃｏｍ／ｉｎｄｅｘ．ｈｔｍｌ”、ｈｔｔｐｓ：／／ｐａｎｏｐｔｉｃｕｍ．ｃｏｍ／ｔｒａｃｋｅｒ．ｊｓ”など）。
ｃ． （例えば、ＣＳＰポリシーの）ＨＴＴＰヘッダに含まれる潜在的な完全性ポリシー命令のハッシュ値。
ｄ． リソースに関連付けられた要素のタイプ（例えば、Ｊａｖａｓｃｒｉｐｔ、ＨＴＭＬ、画像、ウェブアセンブリなど）。
ｅ． 最初のバイトから最後のバイトまでを含む、クライアントによって計算された要素／ファイル全体の実際のハッシュ。
ｆ． 要素の予想されるハッシュ（例えば、ＳＲＩ「完全性」属性を使用して指定されたもの）。
ｇ． コード記述子１６２０Ｃのリストは、また各リソース記述子１６２０Ｂに対して、潜在的に、このオブジェクト内のＪａｖａＳｃｒｉｐｔ／ＷｅｂＡｓｓｅｍｂｌｙコードフラグメントごとに１つのエントリを含み、それぞれが以下の要素のうちの１つ以上を含むことができる。
１． クライアントが計算した要素の実際のハッシュ（例：＜ｓｃｒｉｐｔ＞タグと＜／ｓｃｒｉｐｔ＞タグとの間の実際のコードのハッシュ、又は属性に割り当てられた場合はコード全体の文字列）。
２． タグは各コードフラグメントに関連付けられる。（例えば、ｓｃｒｉｐｔタグにコードが含まれる場合は「ｓｃｒｉｐｔ」、「ｂｏｄｙ」、「ｆｒａｍｅ」、「ｉｍｇ」、「ｉｎｐｕｔ」などの、このようなタグの属性にはそのコードが含まれる）。
３． タグが指定された場合のタグに関連する「ＩＤ」。
４． そのような属性（例えば、「オンロード」属性、「オンクリック」属性など）でコードが指定された場合、関連する属性。

一実施形態では、そのウェブページのコンテキストにロードされる全てのコードは、認証エンジン１６１３及びサーバ側認証エンジン１６５０による評価のために含まれる。例えば、「ｇｅｔ」／「ｃｒｅａｔｅ」呼び出しの時点で処理された（必ずしも実行されたわけではないが）全てのＨＴＭＬ要素及びコードフラグメントが含まれ得る。時には、ユーザが要素をクリックするときなど、コードが動的にロードされることもある。一実施態様では、そのようなコードフラグメントは、「ｇｅｔ」／「ｃｒｅａｔｅ」呼び出しの時点でロードされた場合にのみ含まれる。

場合によっては、既存のＪａｖａＳｃｒｉｐｔコードは、新しいＪａｖａＳｃｒｉｐｔコード要素を動的に追加し、これらの動的に追加された要素もまた、コード記述子１６２０Ｃのリスト内のエントリとして含まれる。クライアント側で動的に生成されたコードに対するこれらのコード記述子は、空のＵＲＬを有する専用リソース記述子に（そのリソースが動的に生成され、リモートソースから直接ロードされなかったため）関連する。
ＩＩ． サーバ１６１１

図１６に示すように、サーバ１６１１上の認証エンジン１６５０は、完全性保護能力１６２０Ａ、リソース記述子１６２０Ｂ、及び／又はコード記述子１６２０Ｃを含む拡張ＷＡＤディクショナリ１６２０の任意の部分を使用してクライアントを認証することができる。完全性保護能力１６２０Ａは、認証エンジン１６５０のクライアントエンジン評価器構成要素１６５１によって評価され得、リソース記述子１６２０Ｂ及びコード記述子１６２０Ｃは、ウェブページ評価器構成要素１６５２によって評価され得る。例えば、一実施形態では、ウェブページ評価器１６５２は、予想されるリソース記述子１６５２Ｂ及び予想されるコード記述子１６５２Ｃに関連するデータのセットを維持する。次いで、サーバ１６１１上の認証エンジン１６５０は、クライアント１６１０から受信した認証データ（例えば、リソース記述子１６２０Ｂ及び／又はコード記述子１６２０Ｃに基づく、署名、ハッシュ値など）を、予想されるリソース記述子１６５２Ｂ及びコード記述子１６５２Ｃに関連付けられたそれ自体のデータと比較することができる。この追加のセキュリティ層に関心がある依拠当事者は、ロードされた（ＪａｖａＳｃｒｉｐｔ）コードの正確さを検証するために異なるアプローチを実装し得る。

サーバ１６１１上の認証エンジン１６５０が「厳密な」アプローチを実装する場合、全てのリソース記述子１６２０Ｂ及びコード記述子１６２０Ｃの予想されるエントリは判定及び比較され得る。Ｊａｖａｓｃｒｉｐｔコードは、所与のハッシュ値を有する十分に定義された数の外部ファイルに制限され得る。このアプローチは、高いセキュリティ要件を有するエンティティによって、及びストレートフォワード法で仕様を実装するサーバによって実装され得る。

機械学習アプローチは、認証エンジン１６５０の一実施形態で使用される。例えば、機械学習ベースの認証エンジン１６５０は、完全性保護測定値１６２０Ａのサポートをチェックし、それらの測定値に関連付けられた完全性保護ポリシー命令の完全性をチェックし、及び／又はコード記述子１６２０Ｃのリストにおけるファイル名及び関連するハッシュ値のペアが初めて又は非常にまれに出現する（例えば、これはスピアフィッシング攻撃を示し得る）かをチェックし得る。これらの状況は、現状のアンチウイルススキャナによるウイルスパターンの分析と同様の様式で処理される可能性がある。つまり、トランザクションは「高リスク」としてフラグを立てられ、認証エンジンが追加の保護措置を実施するトリガとなる。

上記の１つの利点は、このアプローチが、そのようなレベルのセキュリティに関心がない依拠当事者を罰したり／傷つけたりしないことである。これらの依拠当事者は、単に追加のデータ要素を無視するであろう。これらの実施形態はまた、他のＵＲＬから第三者のＪａｖａｓｃｒｉｐｔコードをロードするような現状のウェブ慣行とも互換性がある。これらの第三者は、コード署名を追加したり、又はそれらのコードを変更したりする必要がない。高いセキュリティレベルを必要とする依拠当事者は、上記の実施形態を使用し、このような保護レベルを必要とするアプリケーション／ウェブページに限定して厳密なチェックを実施することができる。

機械学習ベースのアプローチに関心がある依拠当事者は、そのようなエコシステムのパートナーに追加のセキュリティレベルの実装を予想することなく、依然として既存の第三者のＪａｖａｓｃｒｉｐｔモジュールを利用することができる。そのようなモジュールの予想されるハッシュ値は、ファイルに直接含まれる必要はない（したがって、動的生成を必要とする）。代わりに、検証は、認証応答を検証するときに、ＦＩＤＯサーバによって行われ得る。

このアプローチはまた、（潜在的に動的に生成された）ＨＴＭＬオブジェクトの全体を検証する必要がないため、動的に生成されたＨＴＭＬと互換性がある。未修正のＪａｖａｓｃｒｉｐｔが実行される場合、結果として得られた文書オブジェクトモデル（ＤＯＭ）ツリーのセキュリティ関連部分は、Ｊａｖａｓｃｒｉｐｔによって動的に検証することができる。

上記のアプローチはまた、クライアント１６１０の認証部１６１３の暗号化署名機能を活用する。これは、（クライアント自体は、サーバに提供するために返された任意の情報を認証するために使用され得る暗号秘密を有しないので）クライアント１６１０によってどのようなウェブページがロードされレンダリングされたかという証明をサーバ１６１１に提供する方法である。

このアプローチは、プライバシーにも配慮している。追加のデータ要素は、ユーザの個人情報又は個人識別情報を含まない。ロードされたウェブページの内容に関連するデータのみを含む。ユーザ認証を必要としないそれらのウェブページには追加のデータ要素が表示されず、ユーザ認証を必要とするそれらのウェブページは、ロードされたウェブページの完全性を検証するための追加のデータ要素を使用することができる。

本発明の一実施形態は、サインインＵＲＬのセットが与えられたウェブページを定期的に分析し、予想されるコードフラグメントとそのハッシュ値のリストを作成し、提案された完全性保護ポリシー（ＣＳＰ）を作成するツールを含む。

一実施態様では、既知の正常なＪａｖａＳｃｒｉｐｔＵＲＬ及びハッシュ値のリポジトリは、最初にリポジトリ内で提供される。インターネット上に現れるコードフラグメント及び値は、「既知の正常な」状態を維持するためにこのリポジトリと同期され得る。一実施形態は、定期的に分析されるウェブページに基づいて、文書オブジェクトモデルのセキュリティ関連部分を検証するＪａｖａｓｃｒｉｐｔコードを含む。

一実施形態では、ＪａｖａＳｃｒｉｐｔのＳｅｃｕｒｅＬｏａｄ関数は、ソフトウェア開発キット（ＳＤＫ）の形態で提供される。このＳｅｃｕｒｅＬｏａｄ関数は、パラメータとして提供される予想ハッシュ値に対してロードされたオブジェクトを検証する。このような関数は、Ｊａｖａｓｃｒｉｐｔ関数を使用して外部リソース（例えば、画像、テキスト、ＪＳ、．．．）を動的にロードするためのセキュアアプローチを簡素化する。

本発明のこれらの実施形態はまた、クライアントデバイスが安全であると想定され、認証を直接サポートしない他の領域に拡張され得る。クライアントデバイスはまた、暗号化アサーションを生成できるモジュール／デバイス（ＦＩＤＯ認証部又はＴＰＭなど）にアクセスし、潜在的に感染／修正される可能性がある様々なソースからロードされた任意のコードの実行を可能にすると仮定される。一例は、カスタムコードの実行をサポートするＩｏＴデバイスである。

本発明の一実施形態は、ウェブサーバ又は他の外部エンティティからコンテンツ及びプログラムコードをロードする、ウェブブラウザ又は他のソフトウェアを有するクライアントを含む。クライアント／ブラウザは、暗号計算において１つ以上のリソース記述子１６２０Ｂ及び／又はコード記述子１６２０Ｃオブジェクトを含む暗号化アサーション（例えば、ＦＩＤＯ認証部）に署名することができるトラステッドエンティティとインターフェース接続する。例えば、一実施形態は、署名対象オブジェクト内のそのようなリソース記述子（複数可）／コード記述子（複数可）の暗号化ハッシュ値を含む。

加えて、一実施形態は、暗号化アサーションを検証し、暗号化アサーションが予想されるリソース記述子として指定されたそれらのリソース記述子１６２０Ｂ及び／又はコード記述子１６２０Ｃのみを含むことを検証する、ＦＩＤＯサーバなどのサーバ側構成要素を含む。認証エンジンは、悪意のあるリソース記述子及び／又はコード記述子が見つかった可能性を示すリスクスコアを返し得る。

一実施形態は、認証エンジン１６５０（例えば、ＦＩＤＯサーバ）などのサーバ側ソフトウェア構成要素が、暗号化アサーションを検証し、暗号化アサーションが、サーバが以前にトラステッドロケーションからすでに複数回見たことがあるリソース記述子（複数可）／コード記述子（複数可）のみを含むことを検証すること（例えば、機械学習を使用して「複数回」とは何か、「トラステッドロケーション」とは何かを判定すること）を含む。ソフトウェア構成要素は、悪意のあるリソース記述子／コード記述子が見つかった可能性を示すリスクスコアを返し得る。

本発明の一実施形態は、ＭＩＴＭ攻撃（例えば、サインインに使用されるもの）から保護された内部チャネルを介して関連するウェブページをロードし、どのようなリソース及びコードフラグメントが通常使用されるかを学習するソフトウェアツールを含む。このソフトウェアツールは、サーバ側認証エンジンが使用できるＷｅｂサイトについて、予想リソース記述子／予想コード記述子に加えて関連するソースコードを明確にしたデータベースを自動的に供給する。

ＪａｖａＳｃｒｉｐｔ関数は、ＤＯＭツリーのセキュリティ関連部分が攻撃者によって修正されていないことを検証する（例えば、「今すぐ購入（Buy Now）」ボタンが依然として存在し、所与のＩＤを持つ唯一の要素であるかどうか、トランザクションの内容を示す要素がＤＯＭツリーに存在し、ユーザから見えるかどうか、動的に生成されたＪａｖａｓｃｒｉｐｔコードが特定のパターンに従っているか、など）ために、クライアントによって実行されるウェブサイトに含まれ得る。上記の技術のいずれも、Ｊａｖａｓｃｒｉｐｔコードを検証するために使用され得る。

一実施形態では、フィードバック関数がサーバ側認証エンジンで実装されており、これは、悪意のあるリソース記述子／コード記述子のリストを維持する中央サーバに対して、ウェブ上で悪意のあるものとして見つかったＪａｖａｓｃｒｉｐｔコードのリソース記述子／コード記述子を更新する。

一実施態様では、（例えば、上述のように収集された）悪意のあるリソース記述子／コード記述子のリストを分析して、同様の（すなわち、全く同じではない）コードフラグメント（例えば、レンダリングされた内部変数の一部、内部順序又は構造のわずかな修正など）を識別するのに役立ち得る「パターン」を作成するソフトウェアツールを含む。ソフトウェアツールは、リソース記述子／コード記述子のリストを分析し、それらのリソース記述子／コード記述子に所与のＵＲＬから関連するソースコードをロードし、そのようなコードが１つ以上のパターンに一致するかどうかを検証することができる。

一実施形態はまた、画像、テキスト、又はコード（例えば、Ｊａｖａｓｃｒｉｐｔ、ＷｅｂＡｓｓｅｍｂｌｙ、．．．など）のような外部リソースを安全にロードすることを可能にするソフトウェアＳＤＫを含む。このＳＤＫは、ＵＲＬ及びそのリソースの予想されるハッシュ値を受信する。代替的に又は加えて、ＳＤＫは、ロードされる外部リソースのコード署名を検証するために、ＵＲＬ及びトラストアンカー（例えば、署名証明書、ＣＡ証明書のコード、又はルート証明書）を受信する。

上述したように、本発明の実施形態は、様々な工程を含んでもよい。工程は、汎用又は特殊目的のプロセッサに特定の工程を実行させる機械実行可能な命令で具現化され得る。代替的に、これらの工程は、工程を実行するためのハードワイヤードロジックを含む特定のハードウェア構成要素によって、又はプログラミングされたコンピュータ構成要素及びカスタムハードウェア構成要素の任意の組み合わせによって、実行することができる。

本発明の要素はまた、機械実行可能なプログラムコードを記憶する機械可読媒体として提供することができる。機械可読媒体としては、フロッピーディスク、光ディスク、ＣＤ－ＲＯＭ及び光磁気ディスク、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気若しくは光カード、又は、電子プログラムコードを記憶するのに適した他の種類の媒体／機械可読媒体を挙げることができるが、これらに限定されるものではない。

上記の説明全体を通じて、説明の目的のために、多数の具体的な詳細が本発明の完全な理解を提供するために記載された。しかしながら、本発明は、これらの具体的な詳細の一部がなくても実施され得ることは、当業者にとって明らかであろう。例えば、本明細書に記載された機能モジュール及び方法は、ソフトウェア、ハードウェア又はそれらの任意の組み合わせとして実装されてもよいことは、当業者にとって容易に明らかであろう。更に、本発明のいくつかの実施形態は、モバイルコンピューティング環境のコンテキストで本明細書において記載されているが、本発明の基本原理は、モバイルコンピューティングの実装形態に限定されるものではない。実質的に任意の種類のクライアント又はピアデータ処理デバイスは、例えば、デスクトップ又はワークステーションコンピュータを含むいくつかの実施形態で使用することができる。したがって、本発明の範囲及び趣旨は、以下の特許請求の範囲の観点から判断されるべきである。

上述したように、本発明の実施形態は、様々な工程を含んでもよい。工程は、汎用又は特殊目的のプロセッサに特定の工程を実行させる機械実行可能な命令で具現化され得る。代替的に、これらの工程は、工程を実行するためのハードワイヤードロジックを含む特定のハードウェア構成要素によって、又はプログラミングされたコンピュータ構成要素及びカスタムハードウェア構成要素の任意の組み合わせによって、実行することができる。

Claims (15)

1. 装置であって、
   ユーザ入力に応答して、インターネット上のウェブページにアクセスするためにアプリケーションを実行するプロセッサであって、前記ウェブページが、１つ以上のリソース記述子及び／又は前記１つ以上のリソース記述子と関連付けられたコード記述子を有する、プロセッサと、
   トラステッドエンティティに接続することによって、前記１つ以上のリソース記述子及び／又はコード記述子に少なくとも部分的に基づいて、前記ウェブページを検証する認証エンジンと、を備え、
   前記トラステッドエンティティが、前記トラステッドエンティティの第１の鍵を使用して、暗号化アサーションに署名を生成するように構成され、前記暗号化アサーションは、前記ウェブページに基づいて前記認証エンジンにより生成され、前記暗号化アサーションは、前記１つ以上のリソース記述子と関連付けられた１つ以上のリソース記述子オブジェクト及び／又は前記１つ以上のコード記述子に関連付けられた１つ以上のコード記述子オブジェクトを含み、
   前記第１の鍵に対応する前記トラステッドエンティティの第２の鍵を使用し、前記暗号化アサーション内のデータを前記ウェブページの１つ以上の予想リソース記述子及び／又は１つ以上の予想コード記述子と関連付けられたデータと比較し、前記署名を検証することによって、少なくとも部分的に前記ウェブページが検証され、
   前記暗号化アサーションが、判定されたトラステッドロケーションのセットから、判定された以前の回数、以前に観察されたリソース記述子及び／又はコード記述子のみを含むことを検証する機械学習を用いることで前記ウェブページは検証され、前記機械学習が、前記判定された以前の回数と前記トラステッドロケーションのセットとを継続的に更新するために実行されるべきものである、装置。
2. 前記署名が、前記１つ以上のリソース記述子及び／又はコード記述子の暗号化ハッシュ値を含む、請求項１に記載の装置。
3. サーバ側認証エンジンは、前記暗号化アサーションが予想リソース記述子及び／又はコード記述子として指定された１つ以上のリソース記述子及び／又はコード記述子のみを含むことの検証を含む、前記暗号化アサーションの検証を行う、請求項１に記載の装置。
4. 前記サーバ側認証エンジンは、悪意のあるリソース記述子及び／又はコード記述子が識別された可能性を示すリスクスコアを応答として生成する、請求項３に記載の装置。
5. 前記プロセッサが、前記ウェブページに含まれる関数を含むプログラムコードを実行して、文書オブジェクトモデル（ＤＯＭ）ツリーの１つ以上のセキュリティ関連部分が修正されていないことを検証し、前記プログラムコードが、前記署名を使用して検証される、請求項１に記載の装置。
6. サーバ装置であって、
   ウェブページを受信したクライアントから認証要求を受信するためのインターフェースと、
   前記認証要求は、第１の鍵を使用している暗号化アサーションを超えて生成された署名と、前記ウェブページの１つ以上のリソース記述子と関連付けられた１以上のリソース記述子オブジェクト及び／又は前記ウェブページの１つ以上のコード記述子と関連付けられた１つ以上のコード記述子オブジェクトを含んでいる前記暗号化アサーションを含み、
   前記ウェブページと関連付けられた１つ以上の予想リソース記述子及び／又は１つ以上の予想コード記述子を蓄積するストレージデバイスと、
   前記第１の鍵に対応する第２の鍵を使用し、前記暗号化アサーションにおけるデータを、前記ウェブページ及び関連付けられた前記１つ以上の予想リソース記述子及び／又は１つ以上の予想コード記述子に関連付けられたデータと比較し、前記署名を検証することで、少なくとも部分的に前記ウェブページを検証する認証エンジンと、を含み、
   前記暗号化アサーションが、判定されたトラステッドロケーションのセットから、判定された以前の回数、以前に観察されたリソース記述子及び／又はコード記述子のみを含むことを検証する機械学習を用いることで前記ウェブページは検証され、前記機械学習が、前記判定された以前の回数と前記トラステッドロケーションのセットとを継続的に更新するために実行されるべきものである、サーバ装置。
7. 前記署名が、前記１つ以上のリソース記述子及び／又はコード記述子の暗号化ハッシュ値を含む、請求項６に記載のサーバ装置。
8. 前記認証エンジンは、前記暗号化アサーションが予想リソース記述子及び／又はコード記述子として指定された１つ以上のリソース記述子及び／又はコード記述子のみを含むことの検証を含む、前記暗号化アサーションの検証を行うように構成されている、請求項６に記載のサーバ装置。
9. 前記認証エンジンは、悪意のあるリソース記述子及び／又はコード記述子が識別された可能性を示すリスクスコアを応答として生成する、請求項８に記載のサーバ装置。
10. 前記クライアントが、前記ウェブページに含まれる関数を含むプログラムコードを実行して、文書オブジェクトモデル（ＤＯＭ）ツリーの１つ以上のセキュリティ関連部分が修正されていないことを検証するプロセッサを備え、前記プログラムコードが、前記署名を使用して検証される、請求項６に記載のサーバ装置。
11. 方法であって、
    ウェブページを受信したクライアントから認証要求を受信することと、
    第１の鍵を使用して暗号化アサーションに上に生成された署名を識別することであって、前記暗号化アサーションは、前記ウェブページに基づいて前記クライアントにより生成され、前記暗号化アサーションは、前記ウェブページの１つ以上のリソース記述子と関連付けられた１つ以上のリソース記述子オブジェクト及び／又は前記ウェブページの前記１つ以上のコード記述子と関連付けられた１つ以上のコード記述子オブジェクトを含むことと、
    少なくとも部分的に前記ウェブページに関連付けられた１つ以上の予想リソース記述子及び／又は１つ以上の予想コード記述子を識別し、蓄積することと、
    前記第１の鍵に対応する第２の鍵を使用し、前記暗号化アサーション内のデータを、前記ウェブページと関連付けられた１つ以上の予想リソース記述子及び／又は１つ以上の予想コード記述子と関連付けられたデータと比較して、前記署名を検証することにより前記ウェブページを検証することと、を含み、
    前記暗号化アサーションが、判定されたトラステッドロケーションのセットから、判定された以前の回数、以前に観察されたリソース記述子及び／又はコード記述子のみを含むことを検証する機械学習を用いることで前記ウェブページは検証され、前記機械学習が、前記判定された以前の回数と前記トラステッドロケーションのセットとを継続的に更新するために実行されるべきものである、方法。
12. 前記署名が、前記１つ以上のリソース記述子及び／又はコード記述子の暗号化ハッシュ値を含む、請求項１１に記載の方法。
13. さらに、前記暗号化アサーションが予想リソース記述子及び／又はコード記述子として指定された１つ以上のリソース記述子及び／又はコード記述子のみを含むことの検証することを含む、請求項１１に記載の方法。
14. さらに、悪意のあるリソース記述子及び／又はコード記述子が識別された可能性を示すリスクスコアを生成することを含む、請求項１３に記載の方法。
15. 前記クライアントが、前記ウェブページに含まれる関数を含むプログラムコードを実行して、文書オブジェクトモデル（ＤＯＭ）ツリーの１つ以上のセキュリティ関連部分が修正されていないことを検証するプロセッサを備え、前記プログラムコードが、前記署名を使用して検証される、請求項１１に記載の方法。