JP2018529299A - 生体認証プロトコル標準のシステムおよび方法 - Google Patents

Abstract

ユーザコンピューティング装置とサーバコンピューティング装置との間にセキュアな通信が提供される。エンロールメントリクエストは、分散クライアントソフトウェアアプリケーションによって構成されるユーザコンピューティング装置から受信され、かつ処理される。エンロールメントリクエストは、ネットワークにおいてユーザコンピューティング装置をエンロールするために使用可能であり、ユーザに関連付けられた暗号化済み部分初期生体認証ベクトルを含む。暗号化済み部分第２生体認証ベクトルを含む、後に受信される認証リクエストが処理され、かつ、ユーザコンピューティング装置のユーザに関連付けられる。暗号化済み部分初期生体認証ベクトルと、暗号化済み部分第２生体認証ベクトルの比較が行われ、この比較を表す値が生成され、かつ、ユーザコンピューティング装置に送信される。この値が最小閾値を上回る場合、ユーザコンピューティング装置は認証される。

Description

本発明は、一般的に、セキュリティに関し、より詳細には、ユーザを識別するまたは認証するためのシステムおよび方法に関する。

あらゆる種類の情報は、データ通信ネットワーク上でアクセス可能な記憶装置などに、リモートに記憶されかつアクセスされ続けている。例えば、多くの人々および会社は、インターネットまたは他の通信ネットワーク上で、財務情報、健康および医療情報、商品およびサービス情報、購買情報、娯楽情報、マルチメディア情報を記憶しかつこれらにアクセスする。情報へのアクセスに加えて、ユーザは金銭の振替（例えば、購買、送金、または販売など）を行うことができる。典型的なシナリオでは、ユーザは情報へアクセスするために登録を行い、その後、ユーザ名およびパスワードを提示して、「ログイン」し、情報にアクセスする。データ／通信ネットワークに記憶されるかかる情報およびデータへ（から）のアクセスをセキュリティ保護することは、依然として最も重要な懸念事項である。

本願の１つまたは複数の実装形態では、ユーザコンピューティング装置とサーバコンピューティング装置との間にセキュアな通信が提供される。分散クライアントソフトウェアアプリケーションで構成されるユーザコンピューティング装置から受信されるエンロールメントリクエストが処理される。エンロールメントリクエストは、ネットワークにおいてユーザコンピューティング装置をエンロールするために使用可能であり、ユーザに関連付けられた、暗号化済み部分初期生体認証ベクトルを含む。暗号化済み部分第２生体認証ベクトルを含む、その後受信される認証リクエストが処理され、かつユーザコンピューティング装置のユーザに関連付けられる。暗号化済み部分初期生体認証ベクトルと暗号化済み部分第２生体認証ベクトルとの比較が行われ、この比較を表す値が生成され、かつ、ユーザコンピューティング装置に送信される。この値が最小閾値を上回る場合、ユーザコンピューティング装置は認証される。

１つまたは複数の実装形態では、ユーザコンピューティング装置とサーバコンピューティング装置との間にセキュアな通信が提供される。分散クライアントソフトウェアアプリケーションで構成されるユーザコンピューティング装置から受信されるエンロールメントリクエストが処理される。エンロールメントリクエストは、ネットワークにおいてユーザコンピューティング装置をエンロールするために使用可能であり、ユーザに関連付けられた第１の生体認証ベクトルの第１の部分を含む。第１の生体認証ベクトルの第１の部分は記憶され、第２の生体認証ベクトル、および第１の生体認証ベクトルの第２の部分を含む、後に受信される認証リクエストが処理される。第１の部分および第２の部分は結合され、かつ、第２の生体認証ベクトルと比較される。この比較を表す値が生成され、かつ、ユーザコンピューティング装置に送信される。この値が最小閾値を上回る場合、ユーザコンピューティング装置は認証される。

１つまたは複数の実装形態では、エンロールメントリクエストおよび認証リクエストに含まれる証明書が提供され、ここで、認証リクエストを処理することは、証明書が現行のものであり取り消されていないかを判断することを含む。

１つまたは複数の実装形態では、アクティブな監視を行い、かつ証明書のリプレイを含む証明書のスプーフィングを防止する侵入検出システムが提供される。

１つまたは複数の実装形態では、認証リクエストを処理することは、一方向暗号化に応じて暗号化済み空間において少なくとも１回の照合動作を行うことを含む。一方向暗号化はランダムな一方向のパッドを使用して行われ得る。

１つまたは複数の実装形態では、ロール収集が提供され、かつ、デジタルアセットへのアクセスのために１つまたは複数のルールによって定義され、サーバコンピューティング装置は、ロール収集に応じてユーザコンピューティング装置によってデジタルアセットへのアクセスを提供するまたは拒否する。任意アクセス制御および強制アクセス制御のうちの少なくとも１つに応じて、アクセスできるようにする。

１つまたは複数の実装形態では、サーバコンピューティング装置は、分散クライアントソフトウェアアプリケーションで構成されるユーザコンピューティング装置から受信される第２のエンロールメントリクエストを処理する。第２のエンロールメントリクエストは、ネットワークにおいてユーザコンピューティング装置の第２のユーザをエンロールするために使用可能であり、第２のエンロールメントリクエストは、ユーザコンピューティング装置のユーザに関連付けられた第２の暗号化済み部分初期生体認証ベクトル（「ＩＢＶ」）を含む。第２のエンロールメントリクエストを処理することは、サーバコンピューティング装置によってアクセス可能である、またはこの一部である非一時的なプロセッサ可読媒体に第２の暗号化済み部分ＩＢＶを記憶することを含む。

１つまたは複数の実装形態では、サーバコンピューティング装置はユーザのエンロールメントを取り消すことができる。

本発明の他の特徴および利点は、添付の図面に言及する、本発明の以下の説明から明らかとなるであろう。

本開示のさらなる態様は、添付の図面と併せると、後述されるこのさまざまな実施形態の詳細な説明を検討することでより容易に理解されるであろう。

本願の１つまたは複数の実装形態による複数の装置および構成要素を示すブロック図である。 ＢＯＰＳ実装形態の例に関連して、装置、およびこれらの間の情報フローを示す図である。 ＢＯＰＳ実装形態の例に関連して、装置、およびこれらの間の情報フローを示す図である。 ＢＯＰＳ実装形態の例に関連して、装置、およびこれらの間の情報フローを示す図である。 ＢＯＰＳ実装形態の例に関連して、装置、およびこれらの間の情報フローを示す図である。 ＢＯＰＳ実装形態の例に関連して、装置、およびこれらの間の情報フローを示す図である。 １つまたは複数の実装形態に従って、特にデータの機密性を強調したエンロールメントプロセスの例に関連付けられた装置およびステップを示す図である。 本願によるユーザインターフェースにおいて提供される管理コンソールの例を示す図である。 エンロールメントプロセスに関連して、データのアクセスおよびやりとりを含む概要を示す図である。 本願の１つまたは複数の実装形態によるセキュリティアーキテクチャの構成要素を示す図である。 本願の１つまたは複数の実装形態による、対応する代替のエンロールメントプロセスに関連付けられた装置およびステップを示す図である。 本願の１つまたは複数の実装形態による、対応する代替のエンロールメントプロセスに関連付けられた装置およびステップを示す図である。 本願に従って、Ｇｅｎｅｓｉｓプロセスの種々のレベルに関連付けられた可能な要件および例を示すブロック図である。 エンロールメントプロセスおよび認証プロセス中に初期生体認証ベクトルに関連付けられた情報フローの例を示す図である。 本願に関連して実装される視覚暗号法（ＶＣ）の例を示す図である。 ＢＯＰＳ実装形態の例に関連して、それぞれのビットを共有資源に暗号化する視覚暗号スキーム（ＶＣＳ）における２つの共有資源（２、２）の重ね合わせの例を示す図である。 本願によるロール階層のインスタンスを示す図である。 実装形態の例に従って、リプレイ防止に関連した装置および送信フローを示すブロック図である。 実装形態の例によるトークンに関連したステップを示す高レベルフロー図である。 多対多関係のＧｅｎｅｓｉｓプロセスに関連した装置および特徴の例を示す図である。 単一のクライアント装置においてエンロールメントプロセスの例を開始する複数のユーザを示す図である。 複数のユーザアカウントに関する情報を記憶するクライアント装置から認証セッションを開始するユーザの１つの例を示す図である。 ユーザのアカウントの取り消しに関連付けられたステップの例を示す図である。 クライント装置とＢＯＰＳサーバとの間のクライアント証明書の初期化、検証、および確認に関連付けられたステップを実証することを簡略的に示す図である。 サードパーティのサーバおよびＢＯＰＳサーバに関連したクライアント証明書登録の例を示す図である。 本願の実装形態の例による、ＱＲコード（登録商標）認証フローの例を示す図である。

本特許出願の１つまたは複数の実装形態に従って、本明細書では、概して、生体認証オープンプロトコル標準（「ＢＯＰＳ」）と称される、ユーザを認証するためのフレームワークをまとめてまたは少なくとも部分的に含む、新しい標準のセットが提供される。１つまたは複数のＢＯＰＳ実装形態は、識別アサーション、ロール収集、マルチレベルアクセス制御、保証、および監査のための１つまたは複数のモジュールを提供することができる。

図１は、ハードウェア配置構成１００の例を示し、かつ、１つまたは複数のＢＯＰＳ実装形態に関連したデータ通信を表示する。配置構成１００は、クライアント装置（例えば、スマートフォンまたはモバイル装置）１０４、サーバコンピューティング装置（本明細書では概して「ＢＯＰＳサーバ」と称される）１０２、サードパーティのサーバ１０６、および、本明細書に示されかつ説明される機能性をサポートしかつ有効にするために複数のコンピューティング装置１１２を含むことができる侵入検出システム（「ＩＤＳ」）などの複数のコンピューティング装置を構成する１つまたは複数のソフトウェアアプリケーションを含むことができる。さらに、ＢＯＰＳサーバ１０２は、稼働状況監視装置１０８および解析エンジン装置１１０と通信または接続できる。装置１０８および１１０は両方共、ＢＯＰＳサーバ１０２の一部として構成可能である、または個々の装置とすることができる。

下記は、本明細書において言及される略語および頭字語の非限定的なリストである：ａｄｍｉｎ＝管理部、ＡＯＰ＝アスペクト指向プログラミング、ＡＰＩ＝アプリケーションプログラミングインターフェース、ＡＷＳ＝アマゾンウェブサービス、ａｐｐ ａ＝クライアントアプリケーション、ＢＯＰＳ＝生体認証オープンプロトコル標準、ＣＰＵ＝中央処理装置、ＣＢＶ＝現行の生体認証識別子、ＣＳＲＦ＝クロスサイトリクエストフォージェリ、ＩＤ＝識別子、ＩＤＳ＝侵入検出システム、ＩＢＶ＝初期生体認証ベクトル、ＩＰ＝インターネットプロトコル、ＪＳＯＮ＝ＪａｖａＳｃｒｉｐｔ（登録商標） ｏｂｊｅｃｔ ｎｏｔａｔｉｏｎ、ＬＤＡＰ＝ライトウェイトディレクトリアクセスプロトコル、ＭＡＣ＝強制アクセス制御、ＭＣＡ＝モバイルクライアントアプリケーション、ＮＳＡ＝国家安全保障局（米国）、ＱＲコード（登録商標）＝Ｑｕｉｃｋ Ｒｅｓｐｏｎｓｅ ｃｏｄｅ、ＲＤＢＭＳ＝リレーショナルデータベース管理システム、ＲＥＳＴ＝ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ ｓｔａｔｅ ｔｒａｎｆｅｒ、ＳＳＬ＝セキュアソケット層、ＴＣＳＥＣ＝ｔｒｕｓｔｅｄ ｃｏｍｐｕｔｅｒ ｓｙｓｔｅｍ ｅｖａｌｕａｔｉｏｎ ｃｒｉｔｅｒｉａ、ＴＬＳ＝トランスポート層セキュリティ、ＵＲＬ＝ｕｎｉｆｏｒｍ ｒｅｓｏｕｒｃｅ ｉｄｅｎｔｉｆｉｅｒ、ＸＮＴＰ＝ｅｘｔｅｎｄｅｄ ｎｅｔｗｏｒｋ ｔｉｍｅ ｐｒｏｔｏｃｏｌ、ＸＯＲ＝「排他的論理和」二項演算、１：Ｍ＝一対多、４Ｆ＝４本指、専有生体認証技術、５タプル＝５タプルのデータパラメータ。

本願の利点は、１つまたは複数の対応するＢＯＰＳ実装形態が、機能性を提供する構成要素を含むことができ、これが企業の既存の構成要素と共に働くまたはこの代わりになることで、相対的に非常に短い期間で現行の動作環境と統合させるようにすることである。さらに、１つまたは複数の対応するＢＯＰＳ実装形態は、高感度でプライベートのリソースへのアクセスを判定するなどのために形態の保護を継続的に行う。製作システムのみならず開発時のシステムにも適切なセキュリティを加えるように「ポイントカット」機構の形態としての実装形態をサポートする１つまたは複数のアプリケーションプログラミングインターフェース（ＡＰＩ）に少なくとも部分的に応じて、受け入れた目標を満たすまたはこれを超えるようなサービスレベルのセキュリティが、ＢＯＰＳ実装形態において提供可能である。

１つまたは複数のＢＯＰＳ実装形態は、１つまたは複数のデータ通信ネットワークを介してクライアント装置１０４から、本明細書では概して初期生体認証ベクトル（「ＩＢＶ」）と称される生体認証ベクトルを受信でき、かつ、あるアルゴリズムに従ったベクトルを、識別に関連付けられた複数部に分割するＢＯＰＳサーバ１０２を含むことができる。個数に関係なく、無鍵式を含んでＩＢＶは暗号化でき、後の生体認証照合プロセスは、オプションとして、管理側パラメータによって示されるように、例えば、クライアント装置１０４またはサーバ１０２上で行うことができる。

１つまたは複数のＢＯＰＳ実装形態は、パブリッククラウド（例えばアマゾンウェブサービス）またはプライベートクラウドなどにおけるさまざまなオンライン環境において実装されてよい。

本明細書に示されかつ説明される装置の組織的な構造および機能性によると、ユーザ認証は、承認の代わりに、かつ、サーバがクライアント情報を保持するのではなく、むしろ、クライント同士の認識を可能にするのに十分な量の情報を維持するように提供可能である。１つまたは複数のＢＯＰＳ実装形態に従ってセキュリティに配慮した構成要素は、識別アサーション、ロール収集、アクセス制御、監査、および保証を含むことができる。よって、１つまたは複数のＢＯＰＳ実装形態は、大部分は、終端間の生体認証ソリューションにおけるサーバ側の構成要素を考慮する。

識別アサーションに関連して、１つまたは複数のＢＯＰＳ実装形態は、リソースの継続的な保護を提供でき、判定のクラス分けおよび実行可能性、ならびに他の鍵特徴を保証することができる。１つまたは複数のＢＯＰＳ実装形態はさらに、人間の生体認証に直接頼らずに、指名されたユーザが主張している人物であることを確認する助けとなるように、識別アサーションを補佐することができる。本明細書に示されかつ説明される標準は、同指名されたユーザに関連付けられる任意の識別アサーション部または多数の異なるアサーション部を事実上組み込むことができる相互運用可能な標準について含む。（例えばクライアント装置１１２を介した）ＩＤＳのアプリケーションは、信用証明書のセットのスプーフィングを防止する助けとなるように、および／または、１回または複数回の悪意のある試みを行ったと判断された、または行うことを試みている主体または装置をブラックリストに載せるように、アクティブな監視のために提供できる。

さらに、ロール収集は、データの機密性、および、例えば、既知のシステムによって定義されるルールに基づくおよび／または該システムによって実施される特権アクセスに応じてサポートされる。例えば、アクセスの特定的なモードが許可されるかどうか判断するために、対応するロールに関連付けられる特定的な特権は、グループの分類と比較可能である。対象の構造はアクセス制御によって定義されることが可能であり、ロール収集は、システムレベルで、またはクライアント／サーバ呼び出しを通して行うことができる。例えば、ＢＯＰＳサーバ１０２は、一意のユーザを一意の装置１０４に関連付けるためにロール収集情報を記憶することができる。アクセス制御情報は、所与の主体（例えば、人、装置、またはサービス（例えば、ソフトウェアプログラム））が、アクセスする、および／または所与の対象を、読み取る、書き出す、実行する、または削除するなどのように働き出すことに対して承認されるかを判断するコンピューティング装置上で考えられる１つまたは複数のモジュールを実装することを含むことができる。

一般的に、アクセス制御は、任意とすることができ、また、または代替的には、より粒度の細かい可能性がある強制アクセス制御を含むことができる。任意アクセス制御は、例えば、指名されたユーザおよび指名された対象（例えば、ファイルおよびプログラム）に応じて、１つまたは複数の対象へのアクセスを制御することと見なす。判定機構は、例えば、ロールベースとすることができ、ユーザおよび管理部が、指名された個人によっておよび／または個人の定義されたグループによって対象の共有を規定および制御することができるようにする。任意アクセス制御機構は、１つまたは複数の実装形態において、対象が、対象の単体またはグループにわたるグループまたは個々のレベルで承認されないアクセスから保護されるように提供される。よって、任意アクセスに関連付けられた粒度は個人からグループに及ぶ可能性がある。

１つまたは複数のＢＯＰＳ実装形態は、対応する実装形態内の制御下で全ての主体および記憶対象（例えば、プロセス、ファイル、セグメント、装置）上で強制アクセス制御ポリシを実施することができる。これらの主体および対象には、感受性ラベルがアサインされ得、これは、階層的分類ラベルおよび非階層的カテゴリの結合とすることができる。ラベルは、強制アクセス制御決定のための基準として判定時に使用可能である。例えば、クライアント装置１０４上で実行するソフトウェアは、装置にラベルを維持させる、またはＢＯＰＳサーバ１０２にデータを維持させることで主体および対象のラベリングに強制的に順守させる。ＢＯＰＳサーバ１０２は、ＢＯＰＳ実装形態の構成要素として信頼される記憶装置を維持できる。本明細書で使用されるように、信頼される記憶装置は、概して、アクセス制御（ＤＡＣまたはＭＡＣ）によって、主体が正しい対象を受信するように保証し、かつ否認不可および機密性をさらに保証するようにセキュアなやり方でデータを記憶することに言及する。

下記では、１つまたは複数のＢＯＰＳ実装形態の例においてサポートされるアクセス制御ルールおよびオプションを識別する。主体は、主体のセキュリティレベルの階層的分類が対象のセキュリティレベルにおける階層的分類を上回るまたはこれに等しい場合のみ対象を読み取るためにアクセスできるようにすることが可能である。主体のセキュリティレベルにおける１つまたは複数の非階層的カテゴリは、対象のセキュリティレベルにおける非階層的カテゴリ全てを含むことができる。主体は、主体のセキュリティレベルにおける階層的分類が対象のセキュリティレベルにおける階層的分類を下回るまたはこれに等しく、かつ、主体のセキュリティレベルにおける非階層的カテゴリ全てが対象のセキュリティレベルにおける非階層的カテゴリに含まれる場合のみ、対象に書き込むおよび／またはこの対象を実行することができる。識別および認証データは、ユーザの識別情報を認証し、かつ、個々のユーザの代わりに作動するように作成可能であるＢＯＰＳ実装形態の外部の主体のセキュリティレベルおよび承認がそのユーザによる取り扱い許可および承認によって方向づけられるように保証するために、ＢＯＰＳサーバ装置１０２によって使用可能である。

本願は、本明細書では概して保証と称される、セキュリティモデルが稼働中であるかの監査および検証を行う１つまたは複数のモジュールに応じて含むアカウンタビリティを高めるように動作する。ＢＯＰＳ実装形態内のコンピューティング装置が危険にさらされるという思いもよらない事態が生じた場合、かかるモジュールは危険にさらされたシステムが検出されずに動作しないようにする。例えば、ＢＯＰＳ実装形態において、監査リクエストは、当技術分野では既知であるアスペクト指向プログラミングに応じて含む主体／対象レベルでまたはグループレベルでサポート可能である。これによって、呼び出しが監査証跡に安全に書き込まれる可能性が高まる。さらに、ＲＥＳＴｆｕｌウェブサービスおよびＪａｖａＳｃｒｉｐｔ（登録商標） ｏｂｊｅｃｔ ｎｏｔａｔｉｏｎ（ＪＳＯＮ）のインターフェースは、監査証跡を読み取るための機構を提供できる。アクションごとの主体、アクションごとの対象、またはアクションごとのグループで監査を行うことができる。例えば、ユーザのグループは特定的な名前（例えば、「会計」）によって指定でき、かつ、総勘定台帳への全ての書き込みを監査できる。さらに、個人、例えば、最高財務責任者には、損益計算書を読み取るための監査情報を与えることができる。

ＪＵｎｉｔテストのスイートにおける１つまたは複数は、１つまたは複数のＢＯＰＳ実装形態において、システム内の境界構成要素および条件をテストすることを含むことができる、境界条件をテストおよび監視するために使用可能である。１つまたは複数のＢＯＰＳ実装形態では、ＡＰＩに応じて少なくとも部分的にセキュリティ規定を満たすことができる。ＡＰＩの使用によって、リレーショナルデータベース管理システム、検索エンジン、または事実上任意の他のアーキテクチャといった基礎を成すシステムに準拠するようにＢＯＰＳ実装形態を識別するおよび／またはカスタマイズすることを必要としないようにする。対応するＢＯＰＳ実装形態によって提供される機能性は、製作時のシステムのみならず開発時のシステムにも適切なセキュリティを加えるように「ポイントカット」機構を与えることができる。さらに、通信インターフェースを提供するために、例えば、ＲＥＳＴ、ＪＳＯＮ、およびＳＳＬをサポートする１つまたは複数のＢＯＰＳ実装形態のアーキテクチャは、言語に依存しない。１つまたは複数の実装形態において、サーブレット仕様、オープンＳＳＬ、Ｊａｖａ（登録商標）、ＪＳＯＮ、ＲＥＳＴ、および永続的記憶装置に対してアーキテクチャがビルドされる。ツールはオープン標準に順守でき、図１などに示されるように装置の相互運用性を最大にすることができる。

１つまたは複数のＢＯＰＳ実装形態において、識別アサーション、ロール収集、マルチレベルアクセス制御、監査、および保証が提供される。これらは、少なくとも１つの特別に構成されたクライアント装置１０４（例えば、スマートフォンまたはモバイル装置）、ＢＯＰＳサーバ１０２、および装置１１２を含む侵入検出システム（ＩＤＳ）の結合に応じて実装可能である。１つまたは複数の実装形態では、クライアント装置１０４は、ＢＯＰＳサーバ１０２とのセキュアな最初の通信セッションを確立するために、アプリケーションを実行し、かつ、ワンタイムの二方向セキュアソケット層（「ＳＳＬ」）／トランスポート層セキュリティ（「ＴＬＳ」）鍵をロードする。ワンタイム鍵は、少なくとも機能的に、（本明細書では概して「Ｇｅｎｅｓｉｓ」と称される）識別フェーズ中に生成されるおよび／または提供される主体の二方向ＳＳＬ／ＴＬＳ鍵で置き換えられる。Ｇｅｎｅｓｉｓは、概して、生体認証のセットを所与の主体と融合させるプロセスにおける最初のまたは早期のステップを含む。本明細書では概してエンロールメントと称される別のフェーズは、ＢＯＰＳ実装形態においてユーザおよび／または装置を登録することに関連付けられたステップを含み、クライアント装置１０４の証明書を発行すること、クライアント証明書を保護すること、および、クライアントにおいて記憶された極秘データを保護することを含むことができる。

１つまたは複数のＢＯＰＳ実装形態において、データ暗号化、およびセキュアなクライアント／サーバ通信をハンドリングするインフラストラクチャが提供される。ＢＯＰＳインフラストラクチャは、Ｇｅｎｅｓｉｓおよびエンロールメントのプロセスを切り離すこと、および、これらのプロセスをさまざまなエンロールメント要素と共に調整することをサポートできる。これらの従属性は、ＢＯＰＳサーバ１０２のインフラストラクチャを識別でき、かつ、ＢＯＰＳ ＤＮＳ、ＢＯＰＳ ＴｒｕｓｔＳｔｏｒｅ、ＢＯＰＳ ＫｅｙＳｔｏｒｅ、およびＢＯＰＳ鍵ネゴシエーションプロトコルを含むことができる。証明書管理に関して、ＢＯＰＳサーバ１０２のホスト名に対するＤＮＳ入力は、一方向ＳＳＬに対する鍵記憶装置において鍵を有するように構成可能である。１つまたは複数のＢＯＰＳ構成におけるＴｒｕｓｔＳｔｏｒｅは、全ての対応する証明書に署名するための認証局を定義する二方向ＳＳＬ機構である。トランスポートレベルでは、ハンドシェイクを行うことによって、二方向証明書および信頼される記憶装置を通してＢＯＰＳ識別が行われ得る。キーストアはキーストアにおける鍵によってトランスポートレベルセキュリティをサポートし、キーストアにおける鍵は、ＳＳＬ／ＴＬＳでの暗号化のためにホストを識別するのに使用可能であるＶＥＲＩＳＩＧＮ、ＧＯＤＡＤＤＹ、または他の機関といった明確に定義されかつ認識される認証局を使用することができる。本明細書に述べられるように、１つまたは複数のＢＯＰＳ実装形態は、クライアント装置１０４が、二方向ＳＳＬ証明書をロック解除するパスワードをリクエストするワンタイムパスワード（ＯＴＰ）プロセスを使用する。これは、二方向ＳＳＬセッションの開始後に証明書をロック解除するように鍵を戻すためにＯＴＰを同期するクライアント装置１０４およびサーバ１０２によって行われ得る。

１つまたは複数の実装形態において、いくつかの鍵エンロールメント要素は、クライアント装置１０４がＢＯＰＳサーバ１０２にリクエストを送る時にクライアント証明書認証をサポートする。トークンは例えば、データ要素、例えば、「共通名」などに応じて、サーバ上のプロファイルを識別情報に連係させる識別子として構成できる。ＯＴＰプロセスは、二方向ＳＳＬ（ｘ．５０９）証明書をロック解除するパスワードをサーバからリクエストする１つまたは複数の機構を含む。パスワードは、サーバコンピューティング装置１０２とクライアントコンピューティング装置１０４との間で調整されるあらかじめ定義されたアルゴリズムによって使用ごとに変更可能であり、ＯＴＰに対して使用されるチャネルは、個々の証明書に対して使用されるチャネルと異なっているのが好ましい。例えば、プッシュ通知は、個々の証明書をロック解除するために使用されるパスワードを送ることができる。異なる証明書を使用して、個々の証明書をロック解除するためのパスワードを入手することができる。いずれにしても、証明書をロック解除する機構は、クライアント装置１０４上のそのパスワードの記憶を伴わない場合がある。

ある例では、アプリケーションは、Ｇｅｎｅｓｉｓおよびエンロールメントのためのデフォルトの（例えば、あらかじめロードされた）証明書を使用する。後の処理では、現行のＯＴＰでデフォルトの証明書を使用できる。その結果（例えば、ＨＴＴＰ応答）は証明書をロック解除するためのパスワードを含むことができる。ＯＴＰは、次いで、クライアントおよびサーバにおいてロールフォワードすることになる。１つまたは複数のＢＯＰＳ実装形態において、リプレイアタックを防止するために使用される５タプルは高エントロピー値である。この値は、エンロールメント時に生じる可能性があり、クライアント装置１０４とサーバ１０２との間の将来的な通信の一部となり得る。

ＢＯＰＳ実装形態におけるクライアント／サーバアプリケーションの相互作用は、３ステップのプロセスと考えることができ、少なくとも２つの可能な変型が最初の第１のステップの後に生じ得る。このような場合、ＢＯＰＳクライアント／サーバアプリケーションアーキテクチャは、３つの構成要素：クライント装置１０４上で実行するクライントアプリケーション、ＢＯＰＳサーバ１０２上で実行するアプリケーション、および（図面では「アプリサーバ」と称される）サーバ側アプリケーションを参照して、本明細書では説明される。図２〜図６に示される例では、サーバ側アプリケーションは、ＳＳＬ／ＴＬＳ接続がアプリケーションサーバで終点となる可能性があるため、必ずしも、ＢＯＰＳサーバ１０２を通して起動するわけではない。さらに、対応するＢＯＰＳ実装配置は、非暗号化コンテンツによるＢＯＰＳシステムを当てにするアプリケーションを必要としない。図２を参照すると、Ｇｅｎｅｓｉｓプロセス中に、クライント装置１０４はＢＯＰＳサーバ１０２への呼び出しを行い、かつ、ユーザおよびクライント側アプリケーションソフトウェアを認証する。その後、クライント装置１０４は、ＢＯＰＳサーバ１０２によって割り当てられた、かつ、特定的なアプリケーションのクライアント識別情報に固有の証明書を受信する。

次のステップ中（図３）、クライアント装置／アプリケーションはアプリケーションサーバを直接呼び出す。アプリケーションのクライアント部およびサーバ部の間のＳＳＬ／ＴＬＳ接続は、これらの箇所で始められかつ終わる。コンテンツのやりとりは、好ましくは、アプリケーションの外部でＢＯＰＳサーバ１０２にはまたはこのアプリケーションエンティティ内で信頼されない他のものには不可視である。クライアントセッション中（図４）、アプリケーションサーバ１０６は、ＢＯＰＳ１０２サーバを呼び出して識別詳細を入手し、かつ、証明書が以前に取り消されていないかを確認する。

（一部図５に示される）第２の変型では、（図２〜図３に示されるものを含む）Ｇｅｎｅｓｉｓステップは同じとすることができる。その後、ＢＯＰＳサーバ１０２は、アプリケーションサーバ１０６構成要素に連絡して、新しいクライアント１０４が登録され、かつ割り当てられたことを通知する。第２の変型のフローは、少なくとも２つのやり方：識別詳細が異なっている、および取り消しチェックがクライアントセッションにおいてもたらされる（図６）という点で、第１の変型のフローと異なっている。第３のステップでは、クライアント装置１０４がアプリケーションサーバ１０６を直接呼び出す時、アプリケーションサーバ１０６はＢＯＰＳサーバ１０２を呼び出して、証明書が以前に取り消されていないかを確認する。

ＢＯＰＳ実装形態の例に関連して本明細書に示されかつ説明される特徴は、本明細書に提供されるアクセス制御モジュールによってまたはこれに関連して使用可能である、または、既存のフレームワークの識別アサーション要素に追加可能である。よって、ＢＯＰＳ実装形態は、制作環境において最小のアクションを行うことによって信頼される処理を可能にし、それによって、アプリケーションソフトウェアの変更を必要としないようになることが多くなる。

図７Ａは、１つまたは複数のＢＯＰＳ実装形態に従って、エンロールメントプロセスおよび関連のデータの機密性の例に関連付けられた装置およびステップ７００を示す。本願において一方向ＳＳＬ／ＴＬＳに加えてビルドされる二方向ＳＳＬ／ＴＬＳは、クライアント装置１０４において始める通信を提供する。最初の（例えば、Ｇｅｎｅｓｉｓ）通信は、クライアント１０４の識別の起点を定義し、かつクライアント装置１０４が後の通信のためにセッション指向識別アサーションと併せて使用できるというＢＯＰＳ対応二方向証明書を渡す。１つまたは複数の実装形態では、クライアントアプリケーションは、後のＧｅｎｅｓｉｓ動作に対して可能であるあらかじめロードされた二方向ＳＳＬ／ＴＬＳ鍵を有することができる。

１つまたは複数の実装形態によると、ＢＯＰＳサーバ１０２は、クライアント装置１０４からの識別情報を二方向ＳＳＬ／ＴＬＳによる一方向ＳＳＬ／ＴＬＳ通信で受信する。一方向ＳＳＬ／ＴＬＳおよび二方向ＳＳＬ／ＴＬＳ両方を介して通信は行われる。１つまたは複数の実装形態では、サーバ１０２は、信頼される識別情報を入手し、かつ対応する識別情報の代わりに処理するためのロールを収集するためにデータ記憶装置を使用する。また、監査は、継続した検証および信頼されるアクセスの妥当性検査に対して適切なアーティファクトを最大化する。マルチレベルアクセス制御機構の簡略化および文書化に応じて、保証を行うことができる。１つまたは複数のＢＯＰＳ実装形態において、グラフィカルユーザインターフェースにおける管理コンソール（以降「アドミンコンソール」）は、提供された後、登録プロセスは完了し、これによって、ユーザ、グループ、およびロールの動的な修正が可能になり、このことは本明細書においてより詳細に説明される。アドミンコンソールの例は図７Ｂに示される。

図７Ａを参照すると、トークンリクエスト（ＲＥＳＴｆｕｌ）は、クライアント装置１０４から送信され（１）、ＢＯＰＳサーバ１０２から受信され、検証される（２）。ＢＯＰＳサーバ１０２のホスト名に対するＤＮＳエントリは、キーストアにおいて鍵を有するように構成でき（３）、リクエストはフォーマットされ（４Ａ）、ｍのトークン応答は二方向ＳＳＬ／ＴＬＳを介してクライアント装置１０４に送信される（４Ｂ）。その後、ｃのトークン（例えば、５タプルおよびＴｉｍｅＳｔａｍｐ）はクライアント装置１０４から送信され（５）、これは、リクエストにおいてｍのＴｉｍｅＳｔａｍｐに応じて含んで、検証される（６、７）。その後、欠けている５タプルは信頼される記憶装置に対して判断され（８）、リクエストはフォーマットされ（９）、ＳＨＡ５１２トークンはクライアント装置１０４に送信される（１０）。

続けて図７Ａを参照すると、ＳＨＡ５１２トークンを含む登録リクエストは、クライアント装置１０４から送信され（１１）、ＢＯＰＳサーバ１０２による妥当性検査のために受信され（１２）、クライント署名リクエストは、ワンタイムパスワードを算出しかつキーストアに対してトークン数をチェックすること（１４）、および外部の通知サービスへとクライアント証明書パスワードを外部にプッシュすること（１５）を含んで、証明書をロック解除するために処理される（１３）。加えて、１２における検証ステップは、解析に関連付けられたステップに分岐し、かつ、装置情報（１６）、プロファイル情報（１７）、および（本明細書に示されかつ説明されるような）生体認証（１８）を判断することを含む。

加えて、クライアント装置の証明書パスワードは、フォーマットされたリクエスト（２）およびＳＨＡ５１２トークン（２１）と共に再びクライアント装置１０４に送信される。その後、ＳＨＡ５１２トークンを含むカスタムセキュリティリクエストは、クライアント装置１０４から送信され（２２）、これはＢＯＰＳサーバ１０２によって検証される（２３）。リクエストはフォーマットされ（２４）、（ＳＨＡ５１２トークンを含む）カスタムセキュリティ応答はクライアント装置１０４に送信される（２５）。

１つまたは複数のＢＯＰＳ実装形態では、装置１１２を介することを含んで、アクティブな侵入検出システムが提供される。アクティブな侵入検出システムは、ブルートフォースアタック、サービスの妨害（例えば、分散したまたは単一のサービスの妨害）、または他のアタックに対して効果的である。二方向ＳＳＬ／ＴＬＳ証明書偽装の偽造を行う試み、セッションリプレイ、偽造したパケット、または、どうにかしてＢＯＰＳサーバ装置１０２を危険にさらそうとするさまざまな裏をかく技法を識別しかつ追跡するカスタムルールが定義されかつ施行可能である。

１つまたは複数のＢＯＰＳ実装形態において、視覚暗号法は、初期生体認証ベクトル（ＩＢＶ）を暗号化するために使用される。この技法によって、生体認証照合を行う特定の装置上でＸＯＲ演算を使用することなどによって、ＩＢＶの早い組み替えという利点がもたらされる。例えば、秘密共有スキームのために提供する、Ｍｏｎｉ ＮａｏｒおよびＡｄｉ Ｓｈａｍｉｒによって開発された技法が使用できる。動作の例では、ベクトルは、Ｎの共有資源に分けられ、初期ベクトルの組み替えはＮの共有部全てを必要とする。各装置は、ＢＯＰＳサーバ１０２およびモバイルクライアントアプリケーション１０４を含み、エンロールされたベクトルは２つの共有部に分けることができ、このうちの１つはＢＯＰＳサーバ１０２によってアクセス可能であるＢＯＰＳレポジトリに記憶され、もう１つはモバイルコンピューティング装置１０４に記憶される。

本願の１つまたは複数の実装形態では、データの機密性を徹底する暗号化および／または機構の他の形態は、利用可能である。例えば、楕円曲線暗号は視覚暗号法の代わりに（または場合によってこれに加えて）使用可能である。

ある例の生体認証アクション中、新しく取得されたベクトル、およびエンロールされたベクトルの両方の共有資源は、単一の場所（例えば、モバイルコンピューティング装置アプリケーション１０４またはＢＯＰＳサーバ１０２）において、または複数の場所において使用可能とすることができる。どんな場合でも、エンロールされたベクトル共有を使用して、初期ベクトルは、メモリにおいて組み替え可能であることで、これに対して生じる認証をサポートすることができる。図８は、エンロールメントプロセスに関連して、データのアクセスおよびやりとりを含む概要を示す。ＢＯＰＳサーバ１０２に関して、主体のアカウントおよび装置に応じて識別情報が提供される。主体のアカウントおよび装置は、所与の主体のプロファイル情報の一部である。プロファイル情報はクラスタ化されたデータ記憶装置に記憶される。照合させるために、ＩＢＶは、共有資源に取り入れられ、再構成され、解読される。照合アルゴリズムがユークリッドの照合が可能でない場合、プレーンテキストとしての照合が生じ、他の状況では、暗号化されたドメインでの照合が生じる。

代替的な実装形態では、準同形の暗号化が用いられ、これによって、計算が暗号文に対して行われるため、暗号化済みの結果を生成することが可能になる。照合動作は暗号化済み空間で可能であることで、プライバシおよびセキュリティを高めることができる。例えば、一方向暗号化を使用して暗号化済み空間において照合を行うことによって、高レベルのプライバシをもたらし、かつ、元のプレーンテキストのＩＢＶを得る能力を効果的に妨げることができる。

１つまたは複数の実装形態において、１つはクライアント、もう１つはサーバの２つの部分を有するようにするアルゴリズムによって一方向暗号化が行われる。照合において当技術分野で既知であるユークリッド距離（例えば、ハミング距離）を使用する場合、暗号化済み空間で照合を行う。代替的には、照合にハミング距離を使用しない場合、本明細書に説明されるように、プレーンテキスト空間において照合を行う。

１つまたは複数の実装形態において、ランダムなワンタイムパッド（ＲＯＴＰ）は、暗号化済み空間における照合を可能にする一方向暗号化を行うために使用される。代替的には、視覚暗号法は、プレーンテキストにおける照合の場合に可逆暗号のために使用される。例えば、ハミング距離を有さない場合、視覚暗号法はメモリにおいて照合を行うようにプレーンテキストに返すために使用される。好ましくは、暗号化および解読は、２つの暗号化アルゴリズム：１．ビットマスク、または２．マトリックス変換のうちの１つを使用する。理想的には、全ての照合アルゴリズムがハミング距離を有するようにし、従って、サーバはプレーンテキストのＩＢＶを有さない。

下記は、２つの二値ベクトル間のハミング距離を計算することに応じて行われる虹彩認識に関連したアルゴリズムの例である。このアルゴリズムの例では、生体認証の暗号化された二等分に対して、これらを以下のようにプレーンテキストに変換することなく直接照合を行うことができる（＾はビット単位のＸＯＲ演算を示す）。

サーバは、ベクトル＾ノイズをエンロールする、を記憶する。

電話は、ベクトル＾同じノイズを検証する、を送る。

サーバに対して比較が行われる：（ベクトル＾ノイズをエンロールする）＾（ベクトル＾同じノイズを検証する）。

ＸＯＲは、可換であり、かつ結合的であり、そのため、これは、（ベクトルをエンロールする＾ベクトルを検証する）＾（ノイズ＾同じノイズ）、に並び替え可能である。

ＸＯＲは自己逆元であり、従って、（ノイズ＾同じノイズ）＝Ｉであり、式中、ＩはＸＯＲの識別要素であり、これは０である。

従って、式は、（ベクトルをエンロールする＾ベクトルを検証する）＾Ｉ＝（ベクトルをエンロールする＾ベクトルを検証する）に簡略化する。

ＡとＢとの間のハミング距離はＡ＾Ｂの関数である。

従って、ノイズのあるベクトル間のハミング距離は、元のベクトル間のハミング距離と同一である。

エンロールメントに基づく実装形態の例では、下記が生じる。

ａ）．エンロールメントベクトル：

００１１００１１

ｂ）．ランダムシーケンス（ベクトルの前半）：サーバに対して記憶する。

０１０１０１０１

ｃ）．ベクトルの後半（算出済み）：電話に対して記憶する。

０１１００１１０

検証に基づく：

ｅ）．検証ベクトル：（エンロールと検証との間で変更された最後のビットのみを通知するが、これは照合が良好であるからである）。

００１１００１０

ベクトルの後半：電話に対して記憶する。

０１１００１１０

ｆ）．ベクトルの前半（ｅからｃまで）に対する近似を算出する。

０１０１０１００

照合に基づいて：

ｇ）．この「前半の検証」（ｆ）をサーバに送る。

ｈ）．サーバはここで以下を有する。

ベクトルの前半のエンロールメントｂ）：

０１０１０１０１

ベクトルの前半の検証ｆ）：

０１０１０１００

ｂとｆとの間で変更された全てのビットに１でフラグを立てる：

０００００００１

システムによって、最後のビットのみがエンロールと検証との間で変更され、これは良好な照合を表し、どのようにしてサーバがスクランブルをかけられたデータのみを取り扱ったのかを通知すること、および、実際のベクトルがサーバで既知ではなく、ベクトルの差異のみが算出できることが分かる。

代替的な実装形態では、テンプレートベクトル間のユークリッド距離を算出することによって、顔認識が行われ、この場合顔はベクトルから解析して模倣できない。２つの顔の画像が照合される時、例えば、ニューラルネットワークを使用して、それぞれの顔は最初に、１２８バイトのサイズの浮動ベクトルに変換される。この符号ベクトルの表現は任意であり、元の顔に戻すように解析して模倣できない。これらの顔を比較するために、２つのベクトルのユークリッド距離が算出される。同じ人からの２つの顔は同様のベクトルを有するべきであり、異なる人達の顔はユークリッド空間においてさらにばらばらであるべきである。検証ベクトルはモバイル装置に対して算出可能であり、記憶されたエンロールメントベクトルに照合させるため、リモートサーバに送信される。それ故に、元の生体認証（例えば、顔）は、ユーザの装置を離れることはなく、全ての照合はサーバに対して算出可能である。

さらに別の実装形態において、テンプレートベクトル間のユークリッド距離を算出することによって、指紋認識が行われ、ここで、指紋はベクトルから解析して模倣できない。同様に、上述されるように、ニューラルネットワークは指紋照合のために適用可能である。このような場合、指紋は装置においてベクトルに変換可能であり、このベクトルは送信されることになり、それによって、ネットワーク出力ベクトルから元の指紋画像を再構築するやり方が排除される。

１つまたは複数の実装形態では、装置上で暗号鍵がランダムに生成され、これは、ニューラルネットワークから出力されたベクトルを分かりにくくさせるために使用される。例えば、暗号化生体認証ベクトル＝暗号化マトリックス×プレーンテキスト生体認証ベクトル、である。このような場合、暗号化マトリックス変換は、ユークリッド距離が保全されるという特別な特性を有するため、マトリックスは厳密な変換であるはずである。このような場合、生体認証ベクトルは非暗号化フォーマットで装置を離れず、サーバは、２つの暗号化された生体認証を比較し、かつ、プレーンテキストを知ることなく、ユークリッド距離を算出する。ユーザが新しい装置からの検証を望む時、ユーザは、暗号化データを、ＱＲコード（登録商標）などによって新しい装置に転送することができる。これは、古い装置が利用可能であることを必要とする。古い装置が失われるまたは別の状況では利用不可能である場合、ユーザは、本明細書に示されかつ説明されるように、再エンロールする。

それ故に、生体認証ベクトルが分割され、かつ暗号化されて装置間で記憶されるのに応じて、向上したプライバシがもたらされる。ディスクまたはメモリどちらにもプレーンテキスト形式でサーバ上に存在する生体認証ベクトルは部分的にもない。さらに、各認証および認証の失敗に対する「仮説の」解析を行うことを希望するユーザは、ファセット、検索、および解析などをサポートする管理側インターフェースを介してこの解析を行うことができるため、本願は向上した解析をもたらす。

図９は、１つまたは複数のＢＯＰＳ実装形態によるセキュリティアーキテクチャ９００の例の構成要素を示す。図９に示されるように、ＢＯＰＳセキュリティクラスタ９０２は、仮想プライベートネットワーク（ＶＰＮ）上でＢＯＰＳインスタンスを起動するように構成可能である。認証局エンティティ、ＢＯＰＳ ＫｅｙＳｔｏｒｅ、およびＢＯＰＳ ＴｒｕｓｔＳｔｏｒｅのコア属性は、例えば、ＢＯＰＳインスタンス上に位置することができる。ＢＯＰＳインスタンスはまた、ＤＮＳ、ＯＰＳライブラリ、通知サービス鍵、ビジネスアダプタ、ＢＯＰＳ構成特性に関連付けられたおよび／またはこれらを表すデータを包含することができる。ロードバランサクラスタ９０４は、作業負荷を分散した、ＢＯＰＳサービスの信頼性および可用性を徹底する１つまたは複数の装置を含むことができる。構成されたＢＯＰＳロードバランサ９０４は、スループットを最大化し、応答時間を最小化し、ＢＯＰＳアーキテクチャ９００におけるいずれの単一のリソースの過負荷も回避するように動作可能である。

続けて図９を参照すると、永続クラスタ９０６は、１つまたは複数のデータベースセキュリティグループを含むことができ、かつ、ＢＯＰＳデータクラスタを自動スケーリングするように構成可能である。認証サービスは、大きいデータオブジェクトを取扱い、大きいデータセット、ＮｏＳＱＬなどのビッグデータ記憶装置をハンドリングし、データのデータ（「シャード」）の１つまたは複数の水平パーティションは、シャードから同時に読み取り、かつ結果をマージすることによって、性能を改善するために利用可能である。データベースセキュリティアーキテクチャ９００は、ＢＯＰＳアーキテクチャを実装し、かつ、単一の場所における極秘データの記憶の集中を防止する。また、ＩＤＳ装置１１２を含むことができる監視クラスタ９０８も図９に示されている。

図１０Ａおよび図１０Ｂは、１つまたは複数のＢＯＰＳ実装形態による、対応する代替のエンロールメントプロセス１０００および１０１０それぞれに関連付けられた装置およびステップを示す。図１０Ａおよび図１０Ｂに示される実装形態は、アカウントまたは装置に関連付けられた暗号化済み生体認証データを記憶する、生体認証データの変更全てについての情報を記憶する、認証サービスおよびこの対応する生体認証ライブラリ（例えば、顔、４Ｆ、虹彩）をロードしかつ使用する、および、新しいフロー（例えば、エンロールメントおよび認証）をサポートするためのＡＰＩ動作を提供する機構を提供する。

図１０Ａに示される実装形態において、モバイルコンピューティング装置１０４上で実行するソフトウェアアプリケーション（「ＭＣＡ」）は、認証フローの方法がクライント１０４側で行われるように構成される時、初期生体認証ベクトル（ＩＢＶ）の取得、エンロールメントプロセス中に暗号分割動作を行いかつこのプロセスをサーバ側のＣＰＵ負荷を低くするために分散すること、ＢＯＰＳサーバ１０２によってエンロールメントリクエスト（登録）を行うこと、および、暗号照合動作を行うことをもたらす。ＢＯＰＳサーバ１０２は、例えば、エンロールメントプロセス中にＢＯＰＳビッグデータ記憶装置１００２において、共有されたベクトルと共にユーザ識別データを保存するように構成可能である。さらに、ＢＯＰＳサーバ１０２は、認証フローを管理し、かつ認証サービス通信構成要素を統合することができる（１００４）。認証サービス（１００６）は、１つまたは複数の認証アルゴリズム、生体認証エンジンライブラリを動的にロードし、認証エンジンバージョン管理に対するサポートを提供して、ＢＯＰＳサーバ１０２と１つまたは複数の生体認証エンジンとの間の通信を正規化し、認証エンジンバージョン管理に対するサポートを提供し、および、ＢＯＰＳサーバ１０２と認証エンジンとの間の通信を正規化することができる。認証サービスは、認証を行う際に生体認証サービスをラップする。

本明細書に説明されるように、プラガブル認証サービスおよびこの対応する生体認証エンジンのための１つまたは複数の機構が提供される。それ故に、ＢＯＰＳ実装形態は（例えば、認証サービスおよび生体認証ライブラリの場所を介して）構成可能とすることができ、利用可能なサービスを自動的にロードしてシステムに登録することができる。

この結果、発音サービスのリストは、システムレベル、例えば、４Ｆ−エンジン、顔−エンジン、虹彩−エンジン、音声−エンジンで利用可能である。認証部のリストは、ＦＩＤＯ認証部またはＢＯＰＳ認証部を含む。

本願は、以下の特徴をサポートすることによって、生体認証統合認証サービスに対する改善をもたらす。ＢＯＰＳサーバ１０２によってアクセス可能であるアカウントまたは装置において暗号化された生体認証データを記憶するための、１つまたは複数の機構が提供可能である。さらに、生じる生体認証データ変更を表す情報を記憶するための機構が提供可能である。加えて、例えば、同一出願人による、米国特許出願第１４／２０１，４６２号明細書、米国特許出願第１４／２０１，４９９号明細書、米国特許出願第１４／９８８，８３３号明細書、および米国特許出願第１４／８１９，６３９号明細書に示されかつ説明されるような、顔、４本指、および虹彩の生体測定による認証に関連して含む、認証サービスにアクセスしかつこれを使用する「汎用」機構が提供可能である。

本願の１つまたは複数の実装形態において、モバイルコンピューティング装置１０４は、エンロールメントベクトルを取得し、かつ、エンロールメントプロセス中に暗号分割動作を行う。これによって、サーバ側でプロセスを分散しかつＣＰＵ負荷を低下させることによって計算機能性の改善がもたらされる。さらに、モバイル装置１０４は、ＢＯＰＳサーバ１０２に対するエンロールメントリクエスト（登録）を行い、かつ、認証フローからの「生体認証妥当性検査」ステップが携帯で行われるように構成される時、暗号照合動作を行うことができる。

本願の１つまたは複数の実装形態において、ＢＯＰＳサーバ１０２は、例えば、エンロールメントプロセス中にＡＰＡＣＨＥ ＳＯＬＲレポジトリにおいて、共有ベクトルの少なくとも一部分と共にユーザ識別情報を記憶する。さらに、ＢＯＰＳサーバ１０２は、認証情報およびプロセスフローを管理し、かつ、少なくとも１つの生体認証サービス通信構成要素を統合するように構成可能である。

本願によるアーキテクチャにおいて提供される他の構成要素は、１つまたは複数の認証サービスおよび１つまたは複数の生体認証エンジンを含むことができる。認証サービスは、１つまたは複数の認証サービスのバージョン管理をサポートするように構成される１つまたは複数のライブラリの動的なロードを行うように、ＢＯＰＳサーバ１０２と認証サービスとの間の通信を正規化するように、および、１つまたは複数のＢＯＰＳインスタンスが、自身でスケーリングすることができる別個のクラウドを離れるまたは該クラウドである場合のウェブ−アプリケーション機械といった、１つまたは複数の配置シナリオをもたらすように構成可能である。

１つまたは複数の実装形態において、生体認証エンジンは、インターフェースの主体である、管理されていない生体認証ライブラリを含むように構成され、ＢＯＰＳ実装されたシステムにプラグインされるそれぞれの対応するライブラリによって定義されかつ実装される。生体認証エンジンは、好ましくは、必要に応じてエンジンをロードする「ロード」方法、エンジンを無料リソース（例えば、メモリ、一時ファイル）にアンロードする「ＵｎｌｏａｄＬｏａｄ」方法、ステータス情報（例えば、ＩＮＩＴ＿ＦＡＩＬＥＤ、ＯＫ、ＥＲＲＯＲ、ＯＵＴ＿ＯＦ＿ＭＥＭＯＲＹ）を提供する「ＧｅｔＳｔａｔｕｓ」、エンロールメント中に取得したベクトルを暗号化する「分割」方法、例えば、初期ベクトルの共有部に基づいて、ベクトルを認証する「照合」方法、「アクティブ化／登録」方法、および、エンジンの記述をもたらす。記述は、例えば、生体認証タイプ識別子、名前および記述、エンジンバージョン、および生体認証フォーマットを含むことができる。この情報を使用して、本願に関連付けられる１つまたは複数のプロセスは、特定的な生体認証エンジンを自動的にロードしかつ登録することができる。

１つまたは複数の実装形態において、プラガブル認証サービスのための機構は、システムが、構成可能であり（認証サービス場所）、利用可能なライブラリを自動的にロードしかつシステムに登録できるようにサポートされる。認証サービスと呼ばれるそれぞれの生体認証ライブラリは、それ自体を記述するように、定数列（生体認証タイプ）、対応するバージョン、名前および記述といった情報を提供できる。さらに、ペア（生体認証タイプ、生体認証バージョン）などの情報は、一意の生体認証エンジンを識別することができる。

認証サービスおよびこの対応するレベルが低くなった生体認証エンジンの例は、列挙可能であり、例えば、同一出願人による、米国特許出願第１４／２０１，４６２号明細書、米国特許出願第１４／２０１，４９９号明細書、米国特許出願第１４／９８８，８３３号明細書、および米国特許出願第１４／８１９，６３９号明細書に示されかつ説明されるような、４Ｆ、顔、虹彩、および音声を含むシステムレベルで利用可能である。

本明細書に述べられるように、１つまたは複数のＢＯＰＳ実装形態において、Ｇｅｎｅｓｉｓおよびエンロールメントプロセスは効果的に切り離され、これによって、生体認証ベクトル、証明書、または、その他の状況では自動化処理に必要とされる他の機密情報にＢＯＰＳサーバ１０２が直接アクセスする必要なく、主体の識別情報を判断することが可能になる。それ故に、ＢＯＰＳソリューションは、「オープンである」と解釈でき、事実上、Ｇｅｎｅｓｉｓおよびエンロールメントにおけるいずれのカスタマイズも可能にすることができる。例えば、Ｇｅｎｅｓｉｓは、アクティブなディレクトリ、電子メールまたはテキストメッセージの妥当性検査、または、識別情報を物理的に検証するための組織のオフィサにアクセスするためにユーザ名およびパスワードを使用することを含むことができる。例えば、バッチで生じる場合があるユーザアカウントの予備登録は、ビジネス要件に基づくことができる。さらに、Ｇｅｎｅｓｉｓプロセスは、リスク管理に対する完全な従属関係を形成でき、さらに、下流処理を判断することができる。例としてのＧｅｎｅｓｉｓの後処理の間、ユーザは、対応してエンロールされた装置に対して発行される一意のクライアント証明書を含むことができる、自身の生体認証をエンロールする。さらに、ワンタイムパスワード（例えば、「シード」）は、クライアント装置１０４とサーバ装置１０２との間で確立可能であり、さらなるシード値はリプレイアタック防止のために使用可能である。

本明細書において、単一ユーザが多くの装置を有する場合がある、および／または、単一装置が多くのユーザを有する場合がある（すなわち、単一装置が多くの生体認証を有する場合がある）ことは認識されたい。よって、多対多関係の形態は、Ｇｅｎｅｓｉｓおよびエンロールメントプロセスを分離することに応じて生じる可能性がある。それ故に、Ｇｅｎｅｓｉｓによって識別された主体は、多くの生体認証によって何度もエンロールする可能性がある。１つまたは複数のＢＯＰＳ実装形態において、エンロールメントプロセスは、二方向セキュアソケット層／トランスポート層セキュリティ（ＳＳＬ／ＴＬＳ）証明書を使用し、これはサーバ側で生成可能である。かかる生成は、Ｇｅｎｅｓｉｓプロセス後に行うことができるため、明確に定義された主体に対して証明書が適正であることが保証される。

また、１つまたは複数のＢＯＰＳ実装形態は、さまざまなレベルのプロビジョニングを有することができ、これによって、種々のセキュリティレベルに対する柔軟性がもたらされる。例えば、高いレベルのＧｅｎｅｓｉｓは、ユーザが、オフィサなど、物理的に誰かの正面で妥当性検査を行うことを含む。低いレベルは、代替策では、ユーザによって受信される電子メールの妥当性検査と併せてユーザ名およびパスワードだけを定義することを含むことができる。さまざまなレベルのＧｅｎｅｓｉｓおよび検証プロセスは、１つまたは複数の対応する組織に一意であるまたは固有であるとすることができる１つまたは複数のビジネス上の決定に応じて、実装可能である。さらに、後の処理は、対応するＧｅｎｅｓｉｓレベルに基づいて変更可能である。例えば、システムは、高いレベルのＧｅｎｅｓｉｓに関連した１０００，０００ドルの振替を可能にするだけでなく、より低いレベルのＧｅｎｅｓｉｓに関連した１００ドルの振替も可能にする。

図１１は、本願に従って、種々のレベルのＧｅｎｅｓｉｓに関連付けられた可能な要件および例１１００を示すブロック図である。検証プロセスにおいてさらなる要件が必要とされるため、各セキュリティレベルはそれに対応して上昇する可能性がある。図１１のレベルの例では、第１のレベルおよび第２のレベルは組織的な考察に基づいてスワップ可能である。例えば、目標がビジネスビジタに対するＷｉ−Ｆｉアクセスを検証しかつ与えることである場合、検証は、モバイル装置を介して送ることが可能であり、本明細書では低い検証レベルであると考えられる。

エンロールメントフェーズ中、例えば、モバイルコンピューティング装置１０４上で実行しているモバイルアプリケーションは、対応するビルトイン機能に基づいて生体認証をエンロールする。例えば、特定的な統合でビルドされ、デフォルトの生体認証を必要としているモバイルアプリケーションは、アプリケーションにおいてこのような具体的にハードコードされたモジュールを有することができる。

１つまたは複数のＢＯＰＳ実装形態は、生体認証トランザクションの速度に対処し、かつ、モバイル装置上の仮想化の脅威の問題を解決する。かかる脅威の例は、侵入者がモバイル装置のコピーされた仮想画像上のコードを逆コンパイルし、このソースコードを使用して電話認証を停止し、認証しかつ許可を与えるサーバを制御しようとすることである。

これらのリスクを軽減するために、ＢＯＰＳ実装形態におけるプロセスでは、暗号鍵なしで初期生体認証値（ＩＢＶ）を暗号化し、その後、ＩＢＶの半分はクライアント装置１０４に記憶され、もう半分はサーバ１０２に記憶される、または別の状況では該サーバによってアクセス可能である。生体認証照合はサーバ１０２上で行うことができる。図１２は、エンロールメントプロセスおよび認証プロセス中に初期生体認証ベクトル（「ＩＢＶ」）に関連付けられた情報フローの例１２００を示す。図１２に示されるフローの例では、エンロールメント中、ＩＢＶはキャプチャされかつ分割され、ＩＢＶの一部分（例えば、半分）はクライアント装置１０４に記憶される。ＩＢＶの一部分（例えば、半分または１／２）はエンロールメントリクエストにおいてＢＯＰＳサーバ１０２に送信され、この部分は、例えば、ＢＯＰＳサーバ１０２によってアクセス可能なデータ記憶装置に記憶される。その後、ＢＯＰＳサーバ１０２によってエンロールメントの確認が送信される。

続けて図１２を参照すると、現行の生体認証ベクトル（「ＣＢＶ」）は後続の生体認証プロセス中にキャプチャされ、かつ、残りの部分（２／２）を含んで認証（「Ａｕｔｈ」）リクエストに関連してＢＯＰＳサーバ１０２に送られる。ＢＯＰＳサーバ１０２は、認証リクエストにおける受信されたＩＢＶの一部分を結合し、かつこれをＩＢＶの記憶された一部分に結合して解読するように構成される。受信されたＣＢＶは、ＩＢＶ全体のプレーンテキストと比較され、比較中の判断に応じて、クライアントコンピューティング装置１０４に数（例えば、浮動小数点数）が返される。照合するものがある場合、ユーザは、認証されたとして登録可能である。さらに、認証プロセスの結果は、クライアントコンピューティング装置１０４上に表示可能である。

よって、図１２に示されるステップに示され、かつ本明細書に説明されるように、本願によるＢＯＰＳ実装形態は、生体認証トランザクションの速度に対処し、かつクライアント装置上の仮想化の脅威に関連付けられた問題を解決する。このような脅威は、例えば、侵入者が、例えば、モバイル装置のコピーされた仮想画像に対してソフトウェアを逆コンパイルし、このソースコードを使用して電話認証を停止し、認証しかつ許可を与えるサーバを制御しようとした後に生じる可能性がある。

これらのリスクを軽減するために、ＢＯＰＳ実装形態に関連付けられた特徴は、暗号鍵なしでＩＢＶを暗号化し、クライアント装置上のＩＢＶの一部分（例えば、半分）、およびサーバ、またはサーバによってアクセス可能な装置上の一部分（例えば、もう半分）を記憶するように動作可能である。サーバ上で生体認証照合を行うことができる。このように、盗まれた装置は認証を無視することができないが、これは少なくとも部分的に、危険にさらされた装置またはサーバが攻撃者に対して有用となる情報を与えないからである。

１つまたは複数の実装形態によると、下記は、１つまたは複数のＢＯＰＳ実装形態における生体測定による認証に対する処理協約を確立するために提供する。生体認証ベクトルは、少なくとも、クライアントとサーバとの間で分割され、認証へのアプローチは不可知論的な生体認証である。例えば、顔認識に関連して、初期生体認証ベクトルのサイズは、およそ２０ＫＢとすることができ、これは、ＨＴＴＰリクエストおよびＨＴＴＰ応答の上／下によって最小になる可能性があるため、受け入れられる。顔認識に関連するＩＢＶの分割アルゴリズムは、次のように、ゼロビットが白であり、１ビットが黒である可能性がある。それ故に、ＢＯＰＳ実装形態は、視覚暗号法（ＶＣ）に対応することができる。本明細書に述べられるように、本願は、事実上任意の生体認証で使用可能であり、ＩＢＶを取り入れかつＶＣで暗号化する機構を提供する。ＶＣでは、照合はプレーンテキストで生じる。代替的には、ランダムに、照合は、暗号化ドメインで生じる。

具体的に図１２を参照して、クライアントコンピューティング装置１０４を動作させるユーザは、生体認証エンロールメントを進め（１）、初期生体認証ベクトル（ＩＢＶ）をキャプチャする（２）。ステップ（３）では、ＩＢＶは暗号化されかつ分割され、ＩＢＶの２／２はローカルにクライントコンピューティング装置１０４にまたは該装置によって記憶され（４）、エンロールメントリクエストはＩＢＶの１／２を含んで送られ、（二方向ＳＳＬ／ＴＬＳ）を介して）トランスポート層を介してＢＯＰＳサーバ１０２に送信される（５）。ＩＢＶの１／２は、ＢＯＰＳビッグデータなどにおいて、ＢＯＰＳサーバ１０２によって記憶され（６）、エンロールメントの確認はＢＯＰＳサーバ１０２からクライアントコンピューティング装置１０４に戻って送信される（７）。

続けて図１２を参照すると、エンロールメントの後に、クライアントコンピューティング装置１０４において生体測定による認証が行われ（８）、現行の生体認証ベクトルはキャプチャされる（９）。その後、認証リクエストは、トランスポート層を介して送られ（１０）、ＢＯＰＳサーバ１０２によって受信され、ＩＢＶの２／２と結合され、解読のために使用される（１１）。その後、ＣＢＶはＩＢＶのプレーテンテキストと比較され（１２）、浮動小数点数はクライアント１０４に戻るように送信され（１４）、結果が表示される（１５）。

ここで図１３に移ると、本願に関連して実装される視覚暗号法（ＶＣ）の例１３００が示される。ＶＣは、暗号化による良好な相乗効果、ＩＢＶの分割、および、鍵管理の必要がないＩＢＶの再構築をもたらす。図１３に示される視覚暗号法の例では、黒は１に等しい可能性があり、白は０に等しい可能性がある。例では、ＩＢＶは００１００１１０に等しい。ＸＯＲ再構築はソリューションがブーリアンであるため使用可能である。元の生体認証ベクトル暗号化プロセスは資格暗号法を使用して行われ、この結果は、シートに記される２つのベクトルとなる可能性があり、白のノイズのみを包含する。モバイル記憶域（例えば、クライアント装置１０４）は該シートのうちの１つを包含し、サーバ装置１０２はもう１つを包含するまたはこれにアクセスする。検証プロセスは簡易なブール演算を使用して２つのシートを結合し、この結果、元の生体認証ベクトルは完全に再構築される。

ＸＯＲ演算に関連したＩＢＶの再構築の例は、以下の表１に示される。

表１を参照すると、ＢＯＰＳ実装形態の例に関連して、元の生体認証ベクトル暗号化プロセスは視覚暗号法を使用して行うことができ、この暗号化の結果は、白のノイズのみを包含するシートに記される２つのベクトルとなる。本明細書に述べられるように、クライアント装置１０４に関連付けられた記憶域はシートのうちの１つを含み、サーバ装置１０２に関連付けられた記憶域はのもう１つを包含する。検証プロセスは簡易なブール演算を使用して２つのシートを結合し、この結果、元の生体認証ベクトルは完全に再構築される。

図１４は、ＢＯＰＳ実装形態の例に関連して、それぞれのビットが共有資源に暗号化する視覚暗号スキーム（ＶＣＳ）における２つの共有資源（２、２）の重ね合わせの例を示す図である。図１４に示される例では、ゼロおよび１ビットの共有資源の選定はランダムなプロセスである。ゼロまた１ビットを符号化する時、表から１の共有資源に対する値、および表におけるもう１つの共有資源に対する隣接値が得られる。プロセスの終わりに、共有資源のどちらも、元のビットについて何の手がかりも与えない。（ＯＲまたはＸＯＲを使用して）２つの共有資源を重ね合わせることによって、元のビットの値を判断する。

続けて図１４に示される例を参照すると、２つの共有資源（２、２）の重ね合わせは視覚暗号スキーム（ＶＣＳ）で示され、この場合、それぞれのビットを共有資源に暗号化する。ゼロおよび１ビットに対する共有資源の選定はランダムなプロセスにおいて実装可能であることは留意されたい。ゼロまたは１ビットを符号化する時、表（例えば、表１）から１の共有資源に対する値、および、表におけるもう１つの共有資源に対する隣接値が得られる。プロセスの終わりに、共有資源のどちらも、元のビットについて何の手がかりも与えない。その後、例えば、ＯＲまたはＸＯＲを使用して、２つの共有資源を重ね合わせることによって、元のビットの値を判断する。これは、（２、２）ＶＣＳに対する例である。ＶＣＳは、ランダムなプロセスの確率を変更することによって、２つ以上の共有資源に拡張できる。ランダムなプロセスの確率を０．５から０．２５に変更することによって、共有資源は０．５の例に存在する２つのビットの代わりに４つのビットを有することになる。さらに、ランダムなプロセスの確率を０．１２５に変更することによって、それぞれの入力ビットに対して８ビットの暗号化が生じる。

照合を検出することに関して、ＢＯＰＳ実装形態の例における１つまたは複数のモジュールは複数の初期生体認証ベクトルを利用する。そして、それぞれの生体認証に対して１つをＳＳＬ／ＴＬＳを介して通信する２つのＲＥＳＴｆｕｌウェブサービス呼び出しがある。１つの呼び出しは、認証セッションにおける現行の生体認証に加えて、ＩＢＶの二等分を含むことができ、照合の強度を表す浮動小数点値を返す。もう１つの呼び出しは、１度に１つのＩＢＶ（半分）を、および現行の生体認証をもたらすことができ、照合の強度を表す浮動小数点値を返すことができる。第２の呼び出しについて、数回の連続した呼び出し、例えば、照合を判断するために１回に１つのＩＢＶがある可能性がある。

ＢＯＰＳ実装形態に関連した照合協約に従ったサイズ変更算出は、次のように、顔ベクトル当たり２０ｋｂ、毎秒５フレームで、１０秒＝５０ベクトル、５０×２０ｋｂ＝１０００ｋｂとなり得る。

上で識別された実装形態に関連した照合ロジスティックの例は以下のように説明される。照合のために１，０００ＫＢがサーバに送られる。照合がない場合、次の１００ＫＢが送られ、浮動小数点値が判断されるまで以下同様に続く。１つまたは複数のＢＯＰＳ実装形態において、最小閾値が定義され、浮動小数点値は少なくとも最小閾値内にある。照合アルゴリズムの例によると、現行のフレームは、２００ミリ秒に加えて、サーバに対する上／下の時間の１２５ミリ秒を必要とする。よって、照合に加えて、フレーム送信はトランザクション速度を１フレーム当たり３２５ミリ秒にする。照合の上限が１００ミリ秒である時、フレーム送信はおおむね４２５ミリ秒で行われる。失敗が生じた時、フレームのバッチ（例えば、１回に５）は送信可能であり、再び照合を試みることができる。好ましくは、１秒間未満で照合が行われるが、ある特定の好適とは言えないケースでは、数秒間など、照合により長くかかる可能性がある。

本明細書に示されかつ説明されるように、本願の、柔軟性がある認証部および生体認証の不可知論的性質は、認証に使用可能であり、かつデフォルトの生体認証として定義され得る対応する認証部および生体認証を、組織が定義することを可能にする。下流のトランザクションの一部としての生体認証の仕様はないが、デフォルトの生体認証は、組織的レベル、グループユーザレベル、またはトランザクションレベルなどにおいて、１つまたは複数のユーザインターフェースを介して規定可能である。

１つまたは複数の実装形態では、管理コンソールは、グラフィカルユーザインターフェースで構成可能であり、かつ、各承認済みユーザにはアクセス可能とすることができる。管理コンソールは、選択される時、デフォルトの生体認証タイプに対して構成されることになるグラフィカルコントロールを含むことができる。例えば、ＡＣＭＥ Ｐｌｕｍｂｉｎｇの組織は、ある特定のアクセスについて、ＡＣＭＥの被雇用者全てに対してデフォルトの生体認証に顔が使用されるものとすると規定している。さらに、ＡＣＭＥ Ｐｌｕｍｂｉｎｇは、他の状況では、全ての顧客に対して生体認証に４本指が使用されるものとすると規定しており、またさらに、さらなる他の状況では、１０，０００ドルを上回る全ての被雇用者のトランザクションに対して４本指および顔が両方共使用されるものとすると規定している。これらのオプションは、ＡＣＭＥ Ｐｌｕｍｂｉｎｇ管理部が定義するための管理コンソールに提示される。よって、本願は、１つまたは複数の生体認証の柔軟性のある動的な応用を提供する。

認証に関して、生体認証のための複数の情報源は、例えば、条件エンジン、メンバプロファイル、およびメンバ定義などの特定的な組織セットアップにおいて使用可能である。条件エンジンはシステムにおいて定義される動的ルールに基づくことができる。例として、１Ｋドルを超えるいずれのトランザクションも、生体認証検証の少なくとも２つの形態を必要とする。メンバプロファイルは、ユーザロール、および対応する特権を定義する。例として、メンバプロファイル「情報セキュリティ−−第１の応答部」は、コミットトランザクションがある度になど、１０分毎、または他の条件での認証を必要とする場合がある。メンバ定義は、組織／統合レベルにおけるデフォルトの認証を定義することができる。例えば、システムにおいて利用可能な４つのタイプの生体認証−４Ｆ、顔、虹彩−があり、かつ、特定的なＢＯＰＳ／企業実装形態について、デフォルトの生体認証が「顔」である場合、顔認証はデフォルトとして利用可能であり、例えば、グラフィカルユーザインターフェースによって提供され、かつ本明細書では概してＢＯＰＳアドミンダッシュボードと称されるダッシュボードなどにおいて提供可能である。また、上述されるような各条件は優先順位を指示することができる。例えば、メンバ定義は、最低優先順位と見なすことができ、条件エンジンは、最高優先順位と見なすことができる。最高優先順位は、認証方法となる。

下記は、本願に従って、エンロールメントプロセスに関連付けられたステップの例を表す。モバイルクライアントアプリケーションで構成されるモバイルコンピューティング装置１０４は、生誕認証ベクトルを取得し、暗号化を行った後、ＡＰＩ呼び出し登録を行う。特に、生体認証を取得後、ＢＯＰＳサーバ１０２への登録呼び出しは、ＩＢＶの半分を含み、これはサーバ１０２によるアクセスのために記憶される。登録プロセスは、組織内でＢＯＰＳ実装形態を開始するために使用可能である。本明細書に示される説明および図の多くは、クラスタとして出現するＢＯＰＳ実装形態を表すが、ＢＯＰＳはビジネス構成要素として構成可能であると考えられる。ＢＯＰＳ管理部（「ＢＯＰＳアドミン」）が環境をセットアップする前に、組織はＢＯＰＳサーバ１０２から対応するＡＰＩ鍵について登録する。個々の開発者も、さまざまな実装形態において、ＡＰＩ鍵を適用する。

エンロールメントプロセス終了後に、元のサイト管理部（「元のサイトアドミン」）は追加のサイト管理部（「サイトアドミン」）を作成できる。さまざまなサイトアドミンに関連付けられることを含む、エンロールメント情報は、組織に関連付けられた対応するＡＰＩ鍵に関連付け可能である。１つまたは複数の実装形態では、ＡＰＩ登録は、エンロールされた元のサイトアドミン、および発行されたＡＰＩ鍵の２つのドメインに関連する可能性があり、これらは、エンロールメント情報、組織、および使用ケースに基づくことができる。アプリケーション開始の了承後、登録プロセスは終了する。その後、ＢＯＰＳアドミンは組織のための元のサイトアドミンを作成し、元のサイトアドミンはサイトアドミンを作成してよい（例えば、図１５に示されるロール階層図を参照）。

ＢＯＰＳサービスを用いる開発プロセスの前に、開発者は例えば、ＢＯＰＳアドミンコンソールにおけるオプションを使用して登録するのが好ましい。アプリケーション名を提供し、かつ開発者を識別するための質疑指向型識別機構を使用することによって、新しいアカウントは確立でき、かつＡＰＩ鍵は作成でき、これは、アプリケーション名で識別され、かつアプリケーションに関連付けられることになる。

１つまたは複数のＢＯＰＳ実装形態において、クライアント装置１０４上で動作するアプリケーションと、ＢＯＰＳサーバ１０２との間の通信は、二方向ＳＳＬ／ＴＬＳに加えて確立される。Ｇｅｎｅｓｉｓプロセスはかかる接続を確立し、かつ、ユーザが自身をＢＯＰＳサーバ１０２に対してどのように識別するかを規定することで、サーバ１０２が二方向ＳＳＬ／ＴＬＳ通信をセットアップするためのプライベート鍵を生成できるようにする。秘密の質問を提供することは、ユーザが自身を識別するための１つの機構であり、これは公理的アプローチであり、その対応するパーティ（例えば、ベンダ）は、「Ｇｅｎｅｓｉｓ」フェーズ中に個人を一意に説明する質問のセットを提供できる。

ユーザコンピューティング装置１０４上で動作するクライアントアプリケーションは、エンドユーザの装置１０４を識別する一意の識別子（ＩＤ）を提供するために応答可能である。アプリケーションは、ユーザとユーザの装置１０４との間の連係についてＢＯＰＳサーバ１０２に通知するために装置１０４および関連のＡＰＩを使用できる。５タプルは装置１０４を識別するために使用できるかかる機構の１つである。

１つまたは複数のＢＯＰＳ実装形態において、システムがアタックおよびアタックベクトルを打ち負かすために使用可能である対応するＲＥＳＴｆｕｌ呼び出しおよび／またはビヘイビアが規定される。さらに、既知のおよび未知のアタックからリアルタイムでデータを保護するためのリクエストのフォーマットが規定され、（例えば、装置１１２を介して）ＩＤＳにおいて提示できる。例えば、リプレイの軽減は、アクセスの妥当性検査を行うために暗号ワンタイムトークンで使用可能である。このような場合、ＩＤＳは、クライアント１０４およびサーバ１０２が互いに気づいているかを検証する３ティアであるため、サーバ１０２がアプリケーション層で完全に保護されるように徹底する。

図１６は、リプレイ防止に関連した装置および送信フローを示すブロック図１６００である。図１６に示されるように、暗号ワンタイムトークンによって、アクセスの妥当性検査を行い、かつリプレイ、分散サービス妨害（ＤＤｏＳ）および他のアタックを含む、国際標準化機構（ＩＳＯ）層７サイバーアタックからアプリケーション層におけるサーバ１０２を保護する。トークンおよびＩＤＳの結合は、リプレイ、分散サービス妨害（ＤＤｏＳ）および同様のアタックを含む、国際標準化機構（ＩＳＯ）層７サイバーアタックを検出するのに有用である。トークンは１回の使用に有効であり、通常、クライアント１０４からサーバ１０２に渡された後、ＲＥＳＴｆｕｌ呼び出しを使用してＢＯＰＳに返される。

１つまたは複数のＢＯＰＳ実装形態における前提は、ＤＤｏＳ検出のために全トークンが特異的でなければならず、クライアントとサーバとの間で利用される少なくとも１つのアルゴリズムは、時間が変化する場合があり、値がクライアント間のみならずアクセス間で異なっていなければならないことを考慮に入れることである。図１７は、ＢＯＰＳ実装形態の例による、トークンのアルゴリズムに関連付けられたステップ１７００を示す高レベルフロー図である。ステップ１７０２では、Ｇｅｎｅｓｉｓステップ中、ウェブ、モバイル、または組み込み装置（クライアント装置１０４）は、トークンをリクエストするためのＲＥＳＴｆｕｌ呼び出しを発行する。トークンは次いで、受信され、かつ、クライアント１０４からサーバ１０２への暗号化メッセージに埋め込まれる（１７０４）。サーバ１０２は、トークンを受信し、かつそのトークンをＩＤＳに渡すことによってメッセージの妥当性検査を行い（１７０６）、次いで、トークンが有効であるかを検証し、かつ、作成時間と現時間との間の差異が、規定された６０秒間内にあるように徹底する（１７０８）。

図１８は、多対多関係のＧｅｎｅｓｉｓ／エンロールメントおよびユーザ／装置の製品を示す。モバイルクライアント１０４上で、それぞれのアカウントと連係される識別要素が示される。図１８のサーバ側で、ＢＯＰＳサーバ１０２は、識別属性、アカウント、およびそれぞれの識別情報と関係のある装置に関連して示される。データ暗号化を行いかつ高レベルの保証によってクライアント／サーバ通信をセキュリティ保護するために、識別情報はセキュア要素に関連するものであり、これによって、ユーザアカウント（例として、図１８に示されるＡｌｉｃｅのアカウントまたはＢｏｂのアカウント）は、該ユーザの対応する識別情報に応じて適正に認証される。

Ｇｅｎｅｓｉｓステップを開始するために、クライアント装置１０４は、以下の表２に示される各値のいずれかまたは全てを規定することによって５タプルを確立するように選定することができる。ＩＤＳは、クライアントによって設定されない５つの値のいずれかを判断でき、かつ、トークンをＲＥＳＴｆｕｌフォーマットでクライアントに返すことができる。クライアント１０４およびサーバ１０２は、同じ５タプルを共有し、そして、これを使用して、タイムスタンプを計算し、この結果、ＩＤＳまたはＢＯＰＳサーバ１０２によってＳＨＡ５１２が符号化されかつ比較される。計算されたタイムスタンプは５タプルに基づく時間へと後方に移動し、それぞれの呼び出しに対して一意である。

それ故に、１つまたは複数の実装形態において、トークンにおける値全てが比較のためにＳＨＡ５１２合計に変換されるため、トークンはタイムスタンプ自体を包含しない。これによって、値を分ごとの値の間隔で変更して見境のないリプレイを防止することができる。また、トークンの分範囲は、十分に大きいエントロピー（４８，７７１，０７２）を可能にするために３（６０にならない）になるように構成可能であるため、試しのおよびエラーアタックを防止することができる。

さらに、セマンティックエンジンは、セキュリティ管理部が、任意の国際標準の範囲外にある場合があるアタック検出および防止のための追加のカスタムパラメータを作成し、かつ、ありとあらゆるアタックに対してさらなるチェックおよび均衡を提供できるように、構成可能である。

１つまたは複数の実装形態では、リプレイ検出は５タプルから機能させていく。上の表１に表されるような値は、サーバ１０２に提供可能である。代替的には、サーバ１０２は、値をランダムに選択できる。リプレイに従って、受け入れ可能な値の範囲およびエントロピーは最初に判断される。Ｇｅｎｅｓｉｓステップ中に規定される５タプルの値がない場合、アルゴリズムは下記の値を使用することができる。

実装形態の例によると、後方に回転するアルゴリズムが実行される。対応する月が現在の月に満たないまたはこれに等しい場合、年は等しくてよい。代替的には、月が現在の月を超える場合、年は戻るように回転しなければならない。これら２つのケースはアルゴリズムを示す。

例１の現在の月が８（８月）であり、かつ月のＧｅｎｅｓｉｓの値が１１であり、１１＞８であるため、年を５の間隔で遡って調べると、年は２０１１になる。残りの値は、実際の日の値を下回るＧｅｎｅｓｉｓの倍数である。

同じ現在の日および時間を使用する第２の例に関連して、現在の月は８（８月）であり、月のＧｅｎｅｓｉｓの値は４であり、４≦８である。年は、５の間隔で２０１５に相当するまで詳しく調べられる。よって、年は２０１５になり、残りの値は、実際の日の値を下回るＧｅｎｅｓｉｓの倍数である。

１つまたは複数のＢＯＰＳ実装形態において、さまざまなレベルのデータプライバシが提供可能であり、それぞれ、暗号化された生体認証情報を含むことで、誰かが生体認証情報を再設定するおよび／または危険にさらすことを妨げるようにすることができる。１つのプライバシレベルは、非生体認証データ全てがプレーンテキストで記憶される（パッシブにされる）と定義することができる。これによって、使用パターンおよび認証記録の報告および解析が簡略化され、またこれには、否認不可、場所、日付、およびファセット検索などの他の因子が含まれ得る。例えば、２０１６年６月にＣｌｅｖｅｌａｎｄで認証の試みが多数失敗に終わり、個人および装置に関連する情報が提供可能であることが比較的容易に理解できる。この第１のプライバシレベルは、プレーンテキストのパッシベーション処理されたデータに基づいて動作する洗練されたツールに応じて実現可能である。別のより高いレベルのプライバシは、全ての非生体認証データが暗号化されたフォーマットに記憶されるが、クライアントごとの別個の解読鍵を必要としないと定義することができる。よって、クライアント装置１０４は、同じ解読鍵を使用するように構成可能であり、このことは、侵入者がアクセスすることができない、または、解読鍵にアクセスできない可能性が最も高い点で、先に説明した第１のレベルのプライバシより安全と考えられる。なおより高いレベルのプライバシは、全ての非生体認証データが暗号化されたフォーマットで記憶され、かつ解読鍵がそれぞれの識別情報ごとに一意であることを必要とする可能性がある。これによって、それぞれのユーザのデータが生体認証に関連付けられた鍵で暗号化されるため、プライバシおよび分離が高められる。高いレベルのプライバシでは、例えば、個人的に識別可能な情報（「ＰＩＩ」）を含むユーザデータが、ことによるとメモリ内で照合を行う時を除いて、常にクライアント装置１０４上で暗号化されると想定される。１つまたは複数のＢＯＰＳ実装形態では、ユーザは、トランザクションを承認するように認証を行い、かつ、ユーザデータを解読する（例えば、信用証明書またはファイルなどにログインする）ために認証を行う。また、保存データ（例えば、パッシブデータ）は、サーバコンピューティング装置１０２上でおよびクライアント装置１０４上で常に暗号化される。プレーンテキストデータは、照合プロセスが行われている時のメモリだけに存在するのが好ましい。

１つまたは複数のＢＯＰＳ実装形態において、Ｇｅｎｅｓｉｓフローに対する事実上任意のカスタマイズを可能にするためにオープンプラットフォームが提供される。Ｇｅｎｅｓｉｓのいくつかの例は、アクティブディレクトリにアクセスするためのユーザ名およびパスワード、電子メールまたはテキストメッセージの妥当性検査、または個人の識別を含むことができ、これらは、運転免許証、出生証明書、パスポート、社会保障番号、または他の適した信用証明書などに応じて、物理的に検証可能である。

ユーザアカウントの事前登録は、ビジネスルールを実装するバッチプロセスにおいて行うことができ、組織のポリシおよび手続きは、これらのビジネスルールの一因となる可能性がある。ビジネスルールは、アクセス管理プラットフォームと統合可能であり、このプラットフォームは、特権のレベル、およびロールの管理側におけるいくつかの特定の必要性に適合させるようにする他の属性を判断するグループまたはディレクトリにユーザを編成する。これによって、ＢＯＰＳサーバ１０２によってアクセスされるメンバ定義の入力として適用可能である、メンバプロファイル（例えば、ユーザプロファイル、アドミンプロファイル、管理者プロファイル、およびスーパーアドミンプロファイル）の定式化を、開発者が構築できるようにする柔軟性がもたらされる。本願によるＧｅｎｅｓｉｓプロセスは、リスク管理に対する完全な従属性を形成でき、それ故に、下流処理を判断できる。

図１９Ａは、単一のクライアント装置１０４においてエンロールメントを開始する複数のユーザに関連付けられた装置およびステップ１９００を示す。ユーザと装置１０４との関係は「多対多」（Ｍ：Ｍ）とすることができる。第１のエンロールメントステップが追加可能である（Ａ１ 生体認証エンロールメントを開始する、Ａ２ エンロールメントをリクエストする（ｘ、５０９）、Ａ３ エンロールメント要件を返す、Ａ４ アカウント登録をリクエストする（ｄｅｖ ＩＤ、ｕｓｅｒ ＩＤ＋１／２ ＩＢＶ）、Ａ５ 登録を返す）。これらのステップは、第２のユーザに対して繰り返され得る（Ｂ１〜Ｂ５）。多対多関係は、Ｇｅｎｅｓｉｓおよびエンロールメントの分離に応じて生じ得る。また、Ｇｅｎｅｓｉｓによる識別された主体は、多くの生体認証で何度もエンロールすることができる。クライアント／サーバ通信を開始するために、ユーザは、クライアント装置上で自身の生体認証をキャプチャし、これによって、クライアント装置に対して発行された一意のクライアント証明書のエンロールメントプロセスが実行に移される。エンロールメントのセキュリティ部が済むと、ユーザの生体認証情報の登録は実施され、これによってエンロールメントプロセスは終了する。ユーザは多くの装置（クライアント）を有してよく、装置（クライアント）は多くのユーザを有してよい。装置（クライアント）は多くの生体認証をサポートすることができる。

図１９Ｂは、複数のユーザアカウントに関する情報を記憶するクライアント装置１０４から認証セッションを開始するユーザの１つの例、Ａｌｉｃｅに関連した装置およびステップ１９１０を示す。図１９Ｂに示される例では、Ａｌｉｃｅは認証セッションを始め（１）、クライアント装置１０４上で動作するアプリケーションは生体測定による認証をリクエストする（２）。生体測定による認証の完了（３）後、クライアント装置１０４上で動作するアプリケーションは、装置１０４が、ＴＬＳを介してＡｌｉｃｅの識別属性を送るように構成する（４）。その後、ＢＯＰＳサーバ１０２は全てのエンロールメント要素の保全性を考慮して認証リクエストを処理し、結果を返す（５）。

図１９Ｂに示される例を参照すると、Ａｌｉｃｅが誤ってＢｏｂのアカウントを使用して認証セッションを開始する場合には、クライアント装置１０４はいずれのリクエストもサーバに返さないが、これは、ＣＢＶが、エンロールメント中に作成されたＩＢＶと異なることになるからであり、認証は成功しないことになる。

図１９Ｃは、ユーザのアカウントの取り消しに関連付けられた装置およびステップ１９２０の例を示す。図１９Ｃに示される例では、３人のユーザ（Ｅｖｅ、Ｂｏｂ、およびＡｌｉｃｅ）に関連付けられた情報が示される。１つまたは複数の取り消しルールは、管理側のグラフィカルユーザインターフェースによって構成されるアドミンコンソールなどによって、ユーザごとに定義可能である。（同様に生体測定による認証が可能である）管理部に関連付けられたロールは、ルールを実装することを担うこととすることができる。図１９Ｃに示される例では、Ａｌｉｃｅのアカウントはアクティブな証明書を有し、Ｂｏｂのアカウントはトランスポートセキュリティレベルでブロックされる期限切れの証明書を有し、ＥｖｅのアカウントはＢＯＰＳアドミンによって取り消されている。より詳細には、Ｅｖｅの証明書がＢＯＰＳサーバ１０２を介して取り消されており（１）、認証リクエストはＥｖｅのアカウントに関連付けられたクライアント装置１０４から受信される（２）。ＢＯＰＳサーバ１０２は、Ｅｖｅのアクセスがブロックされることを表すメッセーまたは他の適したコンテンツを返す（３）。Ｂｏｂの証明書に関して、９０日の期間が定義され、この期間後、Ｂｏｂの証明書は期限切れになる（「ＴＴＬ」）（４）。その後、認証リクエストはＢｏｂのアカウントに関連付けられたクライアント装置１０４から受信され（５）、Ｅｖｅのケースと同様に、Ｂｏｂのアクセスがブロックされることを表すメッセージまたは他の適したコンテンツがＢＯＰＳサーバ１０２によってクライアント装置１０４に送信される（６）。Ａｌｉｃｅのアカウントに関して、追加の９０日の期間の延長期間が設けられ（７）、認証リクエストはＡｌｉｃｅのアカウントに関連付けられたクライアント装置１０４から受信される（８）。ＢＯＰＳサーバ１０２は、Ａｌｉｃｅが認証されることを、本明細書に示されかつ説明されるような認証結果を表すメッセージまたは他の適したコンテンツを返す（９）。

本明細書に示されかつ説明されるモジュールに関連して解決される問題のうちの１つは、リプレイアタックの防止である。１つまたは複数の実装形態において、ＤＤｏＳ検出について、典型的には、サーバ上のプロファイルを共通名（ＣＮ）フィールドにおける識別情報に連係する識別子であるあらゆるトークンは特異的である。クライアント１０４とサーバ１０２との間のアルゴリズムは、時間が変化し得ること、および、値がクライアント１０４間のみならずアクセス間で異なっていなければならないことを考慮に入れる。

１つまたは複数の実装形態において、証明書の分散は以下のように働く。Ｘ．５０９証明書はクライアント装置１０４にインストールされるアプリケーションソフトウェアに応じることを含んで、クライアント装置１０４にあらかじめロードされる。Ｇｅｎｅｓｉｓプロセスの前に、クライアント１０４は、（本明細書に示されかつ説明されるように）タプルのいずれかまたは全てを規定することによって、５タプルの値を確立する。エンロールメントプロセス中、クライアント１０４はＢＯＰＳサーバ１０２からトークンをリクエストするためにＲＥＳＴｆｕｌ呼び出しを発行する。トークンは、受信される時、サーバに対するクライアントの暗号化メッセージに埋め込まれる。サーバは、トークンを受信し、かつ、作成時間と現時間との間の差異が、規定された６０秒間以内にあるように徹底することによってメッセージの妥当性検査を行う。サーバ１０２は、５タプルの値のどれが無くなっているかを判断し、かつ、トークンをＲＥＳＴｆｕｌフォーマットでクライアントに返す。クライアント１０４およびサーバ１０２は、同じ５タプルの値を共有し、そして、この値を使用して、タイムスタンプを計算し、この結果、例えば解析に応じて、ＳＨＡ５１２がＩＤＳによって符号化されかつ比較される。例えば、本明細書に説明されるように、計算されたタイムスタンプは５タプルに基づく時間へと後方に移動し、それぞれの呼び出しに対して一意である。

本願は、クライアント証明書の時間の長さを有効のままであるように（有効時間またはＴＴＬ）構成できる。認証されたユーザの取り消された証明書は、新しい証明書と暗黙的に置き換え可能である。よって、ＴＴＬは、ユーザ認証をサポートするためにＩＢＶおよびＣＢＶと併せて働く「ベルトおよびサスペンダー」式のアプローチである。トークンの取り消しは、ユーザロールに対して条件付きとすることもでき、特定の要件を行う他の因子は承認に必要である。例えば、条件ｙおよび／またはｚが満たされない場合など、財務トランザクションに対する認証の試みが１回またはｘ回失敗した後に、証明書はブロックされ得る。

図２０Ａは、クライント装置１０４とＢＯＰＳサーバ１０２との間のクライアント証明書の初期化、検証、および確認に関連付けられたステップ２０００を実証することを簡略的に示す図である。クライアント署名リクエスト（「ＣＳＲ」）の処理に関連付けられたステップは、公開−プライベート鍵ペアをクライアント装置１０４において生成し、公開鍵、およびＢＯＰＳサーバ１０２に送信される主体名を署名すること（本明細書では概して「所有証明」を行うことと称される）を含むことができる。本明細書に述べられるように、クライアントは二方向ＳＳＬを使用して登録アカウントリクエストを送る。証明書の主体名をチェックし、ＢＯＰＳ認証局（ＣＡ）のプライベート鍵によってクライアントリクエストに署名し、およびＯＴＰ機構によってクライアント証明書のパスワードを生成した後、ＢＯＰＳサーバ１０２はクライアント証明書パスワードをクライアント装置１０４に返す。登録されたクライアントは、証明書の署名をチェックし、かつ．ｐ１２コンテナを作成して、パスワードではなく、クライアントプライベート鍵および署名済み証明書を記憶する。ＯＴＰ機構がそれぞれのクライアントリクエストに対して１回使用のパスワードを生成するため、パスワードはクライアント装置に一度も記憶されないのが好ましい。

図２０Ｂは、サードパーティのサーバおよびＢＯＰＳ統合におけるクライアント証明書プロセス２０１０の例を示す。例えば、図２０Ａに示されるようなＣＳＲプロセスは、広く実証され、ユーザエンロールメントで始められる。図２０Ｂに示される例では、「ユーザアカウントを登録する」は、Ｇｅｎｅｓｉｓおよびエンロールメントに関連付けられたステップを説明するために使用され、クライアント証明書は識別属性を表し、アカウントは識別構成要素を表す。

図２０Ｂに示される実装形態の例では、ユーザがエンロールメントプロセスを開始し、かつ自身の生体認証情報をアカウント登録リクエストによってＢＯＰＳサーバ１０２に送った後、鍵ペア／ＣＳＲ生成はクライアント１０４においてトリガされる。登録プロファイルリクエストが受信されると、ＢＯＰＳサーバ１０２はこのリクエストをさらに、プロファイル妥当性検査を表す図２０Ｂに示されるように、（サードパーティの企業によって用いられるアクセス管理ソリューション／プラットフォームとすることができる）アクセス管理アダプタに、その後さらに、アカウントログイン検証および妥当性検査のためにサードパーティのサーバに送る。サードパーティのサーバは、ログインデータの妥当性検査後認証トークンを提供し、その後、妥当性検査の結果をアクセス管理アダプタに送り返し、これによって、認証結果および認証トークンが再びＢＯＰＳサーバ１０２に回されて、アカウント／プロファイル登録を終了する。ＢＯＰＳサーバ１０２は、認証トークンを暗号化し、生体認証データを記憶し、ＢＯＰＳ ＣＡによってＣＳＲに署名し、暗号化された認証トークンをクライアントアプリケーションに送る。これは、生体測定による認証に応じてより高度の検証を行うために、既にレポジトリに何十億ものアカウントを蓄積している企業（例えば、銀行）と統合した実装の例を表す。

１つまたは複数の実装形態において、ｑｕｉｃｋ ｒｅｓｐｏｎｓｅ ｃｏｄｅ（ＱＲコード（登録商標））は、本明細書に示されかつ説明される１つまたは複数のモジュールの実行をトリガするために使用可能である。例えば、ビジネスパートナー（例えば、銀行）のログインページは、対応するセッション時機識別子を包含するＱＲコード（登録商標）画像を表示するように構成可能である。クライアントコンピューティング装置１０４上で実行するＭＣＡは、ＱＲコード（登録商標）をスキャンし、該コードがセッションにアタッチされるように、セッションを信号に登録し、本明細書における教示によるユーザの生体認証で認証するための、１つまたは複数のモジュール（例えば、認証ウィザード）を実行することができる。図２１は、ＱＲコード（登録商標）認証フロー２１００の例を示し、ここで、サードパーティのサーバは、ＢＯＰＳサーバ１０２によるセッション時機を登録し、それに応じて、新しい認証セッションに使用可能な情報はＢＯＰＳサーバ１０２によってサードパーティのサーバに提供可能であり、この情報はＱＲコード（登録商標）の範囲内で提供（例えば表示）可能である。サードパーティのサーバは、セッションステータス情報に対する１つまたは複数のリクエストを送信することができる。図２１における（「アクタ」と指定される）ユーザは、ＱＲコード（登録商標）をスキャンし、かつ、ＢＯＰＳサーバ１０２によるセッションを登録し、これは、外部のサードパーティのサーバに通知可能である。本明細書に示されかつ説明されるような生体測定による認証が行われると、ユーザセッションは、サードパーティのサーバとによるのを含めて確立可能である。

上述される主題は、例示としてのみ提供され、限定するものと解釈されるべきではない。例示されかつ説明される実施形態および応用の例に従うことなく、かつ、以下の特許請求の範囲のそれぞれおよびいずれかにおいて示されるように、本発明の真の趣旨および範囲から逸脱することなく、本明細書に説明した主題に対してさまざまな修正および変更をなすことが可能である。

１０２ ＢＯＰＳサーバ
１０４ クライアント装置
１０６ サードパーティのサーバ
１０８ 稼働状況監視装置
１１０ 解析エンジン
１１２ クライアント装置
９０２ ＢＯＰＳクラスタ
９０４ ロードバランサクラスタ
９０６ 永続クラスタ
９０８ 監視クラスタ

Claims (20)

1. ユーザコンピューティング装置とサーバコンピューティング装置との間にセキュアな通信を提供するための方法であって、
   前記サーバコンピューティング装置によって、分散クライアントソフトウェアアプリケーションで構成されるユーザコンピューティング装置から受信されるエンロールメントリクエストを処理することであって、前記エンロールメントリクエストは、ネットワークにおいて前記ユーザコンピューティング装置をエンロールするために使用可能であり、前記リクエストは、前記ユーザコンピューティング装置のユーザに関連付けられた暗号化済み部分初期生体認証ベクトル（「ＩＢＶ」）を含み、前記エンロールメントリクエストを前記処理することは、前記サーバコンピューティング装置によってアクセス可能である、または該サーバコンピューティング装置の一部である非一時的なプロセッサ可読媒体に前記暗号化済み部分ＩＢＶを記憶することを含む、処理することと、
   前記ユーザコンピューティング装置から後に受信され、暗号化済み部分第２生体認証ベクトルを含み、かつ前記ユーザコンピューティング装置のユーザに関連付けられる認証リクエストを前記サーバコンピューティング装置によって処理することであって、前記認証リクエストを前記処理することは、
   アルゴリズムに応じて、前記暗号化済み部分初期生体認証ベクトルと前記暗号化済み部分第２生体認証ベクトルとの比較を行うこと、および
   前記比較を表す値を生成することを含む、処理することと、
   前記比較を表す前記値を、前記サーバコンピューティング装置によって前記ユーザコンピューティング装置に送信することであって、前記ユーザコンピューティング装置は前記値が最小閾値を上回る場合認証され、前記ユーザコンピューティング装置は前記値が最小閾値を下回る場合認証されない、送信することとを含む、方法。
2. 前記エンロールメントリクエストおよび前記認証リクエストに含まれる証明書を、前記サーバコンピューティング装置によって前記ユーザコンピューティング装置に提供することであって、前記認証リクエストを前記処理することは、証明書が現行のものであり取り消されていないかを判断することを含む、提供することをさらに含む、請求項１に記載の方法。
3. アクティブな監視を行い、かつ前記証明書のスプーフィングを防止する侵入検出システムを利用することをさらに含む、請求項２に記載の方法。
4. 防止される前記スプーフィングは前記証明書のリプレイを含む、請求項３に記載の方法。
5. 前記認証リクエストを処理することは、一方向暗号化に応じて暗号化済み空間において少なくとも１回の照合動作を行うことをさらに含む、請求項１に記載の方法。
6. 前記一方向暗号化はランダムなワンタイムパッドを使用して行われる、請求項５に記載の方法。
7. デジタルアセットへのアクセスのために１つまたは複数のルールによって定義されるロール収集を前記サーバコンピューティング装置によって提供することと、
   前記サーバコンピューティング装置によって、前記ロール収集に応じて前記ユーザコンピューティング装置によって前記デジタルアセットへのアクセスを提供するまたは拒否することとをさらに含む、請求項１に記載の方法。
8. 前記アクセスは、任意アクセス制御および強制アクセス制御のうちの少なくとも１つに応じて提供される、請求項７に記載の方法。
9. 前記サーバコンピューティング装置によって、分散クライアントソフトウェアアプリケーションで構成される前記ユーザコンピューティング装置から受信される第２のエンロールメントリクエストを処理することであって、前記第２のエンロールメントリクエストは、前記ネットワークにおいて前記ユーザコンピューティング装置の第２のユーザをエンロールするために使用可能であり、前記第２のエンロールメントリクエストは、前記ユーザコンピューティング装置のユーザに関連付けられた第２の暗号化済み部分初期生体認証ベクトル（「ＩＢＶ」）を含み、前記第２のエンロールメントリクエストを前記処理することは、前記サーバコンピューティング装置によってアクセス可能である、または該サーバコンピューティング装置の一部である非一時的なプロセッサ可読媒体に前記第２の暗号化済み部分ＩＢＶを記憶することを含む、処理することをさらに含む、請求項１に記載の方法。
10. 前記サーバコンピューティング装置によって、前記ユーザコンピューティング装置に関連付けられた前記第１のユーザの前記エンロールメントを取り消すことをさらに含む、請求項９に記載の方法。
11. ユーザコンピューティング装置と信頼されるサーバとの間にセキュアな通信を提供するためのシステムであって、
    １つまたは複数の非一時的なプロセッサ可読媒体に動作可能に連結される少なくとも１つのプロセッサを備え、
    前記１つまたは複数の非一時的なプロセッサ可読媒体は、前記少なくとも１つのプロセッサが、
    分散クライアントソフトウェアアプリケーションで構成されるユーザコンピューティング装置から受信されるエンロールメントリクエストを処理することであって、前記エンロールメントリクエストは、ネットワークにおいて前記ユーザコンピューティング装置をエンロールするために使用可能であり、前記リクエストは、前記ユーザコンピューティング装置のユーザに関連付けられた暗号化済み部分初期生体認証ベクトル（「ＩＢＶ」）を含み、前記エンロールメントリクエストを前記処理することは、前記サーバコンピューティング装置によってアクセス可能である、または該サーバコンピューティング装置の一部である非一時的なプロセッサ可読媒体に前記暗号化済み部分ＩＢＶを記憶することを含む、処理することと、
    前記ユーザコンピューティング装置から後に受信され、暗号化済み部分第２生体認証ベクトルを含み、かつ前記ユーザコンピューティング装置のユーザに関連付けられる認証リクエストを処理することであって、前記認証リクエストを前記処理することは、
    アルゴリズムに応じて、前記暗号化済み部分初期生体認証ベクトルと前記暗号化済み部分第２生体認証ベクトルとの比較を行うこと、および
    前記比較を表す値を生成することを含む、処理することと、
    前記比較を表す前記値を前記ユーザコンピューティング装置に送信することであって、前記ユーザコンピューティング装置は前記値が最小閾値を上回る場合認証され、前記ユーザコンピューティング装置は前記値が最小閾値を下回る場合認証されない、送信することとを可能にするための命令を含む、システム。
12. 前記１つまたは複数の非一時的なプロセッサ可読媒体は、前記少なくとも１つのプロセッサが、前記エンロールメントリクエストおよび前記認証リクエストに含まれる証明書を、前記ユーザコンピューティング装置に提供することであって、前記認証リクエストを前記処理することは、前記証明書が現行のものであり取り消されていないかを判断することを含む、提供することを可能にするための命令をさらに含む、請求項１１に記載のシステム。
13. 前記１つまたは複数の非一時的なプロセッサ可読媒体は、前記少なくとも１つのプロセッサが、アクティブな監視を行い、かつ前記証明書の代替のもののスプーフィングを防止する侵入検出システムを利用することを可能にするための命令をさらに含む、請求項１１に記載のシステム。
14. 防止される前記スプーフィングは前記証明書の代替のもののリプレイを含む、請求項１３に記載のシステム。
15. 前記認証リクエストを処理することは、一方向暗号化に応じて暗号化済み空間において少なくとも１回の照合動作を行うことをさらに含む、請求項１１に記載のシステム。
16. 前記一方向暗号化はランダムなワンタイムパッドを使用して行われる、請求項１５に記載のシステム。
17. 前記１つまたは複数の非一時的なプロセッサ可読媒体は、前記少なくとも１つのプロセッサが、
    デジタルアセットへのアクセスのために１つまたは複数のルールによって定義されるロール収集を提供することと、
    前記ロール収集に応じて前記ユーザコンピューティング装置によって前記デジタルアセットへのアクセスを提供するまたは拒否することとを可能にする命令をさらに含む、請求項１１に記載のシステム。
18. 前記アクセスは、任意アクセス制御および強制アクセス制御のうちの少なくとも１つに応じて提供される、請求項１７に記載のシステム。
19. 前記１つまたは複数の非一時的なプロセッサ可読媒体は、前記少なくとも１つのプロセッサが、分散クライアントソフトウェアアプリケーションで構成される前記ユーザコンピューティング装置から受信される第２のエンロールメントリクエストを処理することであって、前記第２のエンロールメントリクエストは、前記ネットワークにおいて前記ユーザコンピューティング装置の第２のユーザをエンロールするために使用可能であり、前記第２のエンロールメントリクエストは、前記ユーザコンピューティング装置のユーザに関連付けられた第２の暗号化済み部分初期生体認証ベクトル（「ＩＢＶ」）を含み、前記第２のエンロールメントリクエストを前記処理することは、前記サーバコンピューティング装置によってアクセス可能である、または該サーバコンピューティング装置の一部である非一時的なプロセッサ可読媒体に前記第２の暗号化済み部分ＩＢＶを記憶することを含む、処理することを可能にするための命令をさらに含む、請求項１１に記載のシステム。
20. ユーザコンピューティング装置とサーバコンピューティング装置との間にセキュアな通信を提供するための方法であって、
    前記サーバコンピューティング装置によって、分散クライアントソフトウェアアプリケーションで構成されるユーザコンピューティング装置から受信されるエンロールメントリクエストを処理することであって、前記エンロールメントリクエストは、ネットワークにおいて前記ユーザコンピューティング装置をエンロールするために使用可能であり、前記リクエストは、前記ユーザコンピューティング装置のユーザに関連付けられた第１の生体認証ベクトルの第１の部分を含み、前記エンロールメントリクエストを前記処理することは、前記サーバコンピューティング装置によってアクセス可能である、または該サーバコンピューティング装置の一部である非一時的なプロセッサ可読媒体に前記第１の生体認証ベクトルの前記第１の部分を記憶することを含む、処理することと、
    前記ユーザコンピューティング装置から後に受信され、前記第１の生体認証ベクトルの後にキャプチャされる第２の生体認証ベクトルを含み、かつ前記ユーザコンピューティング装置のユーザに関連付けられる認証リクエストを前記サーバコンピューティング装置によって処理することであって、前記認証リクエストは前記第１の生体認証ベクトルの第２の部分をさらに含み、前記認証リクエストを前記処理することは、
    前記第１の生体認証ベクトルの少なくとも前記第１の部分および前記第２の部分を結合すること、
    アルゴリズムに応じて、結合された前記第１の部分および前記第２の部分と前記第２の生体認証ベクトルとの比較を行うこと、および
    前記比較を表す値を生成することを含む、処理することと、
    前記比較を表す前記値を前記サーバコンピューティング装置によって前記ユーザコンピューティング装置に送信することであって、前記ユーザコンピューティング装置は、前記値が最小閾値を上回る場合認証され、前記ユーザコンピューティング装置は前記値が最小閾値を下回る場合認証されない、送信することとを含む、方法。