特表 2015-519776 マルチパーティシステムにおける安全な認証

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】特表2015-519776(P2015-519776A)

(43)【公表日】2015年7月9日

(54)【発明の名称】マルチパーティシステムにおける安全な認証

(51)【国際特許分類】

   H04L 9/32 20060101AFI20150612BHJP

   G06F 21/31 20130101ALI20150612BHJP

   G09C 1/00 20060101ALI20150612BHJP

【ＦＩ】

   H04L9/00 675B

   G06F21/31

   H04L9/00 675D

   G09C1/00 660E

【審査請求】有

【予備審査請求】未請求

【全頁数】36

(21)【出願番号】特願2015-503559(P2015-503559)

(86)(22)【出願日】2013年3月28日

(85)【翻訳文提出日】2014年11月29日

(86)【国際出願番号】US2013034227

(87)【国際公開番号】WO2013151852

(87)【国際公開日】20131010

(31)【優先権主張番号】61/618,813

(32)【優先日】2012年4月1日

(33)【優先権主張国】US

(31)【優先権主張番号】61/645,252

(32)【優先日】2012年5月10日

(33)【優先権主張国】US

(81)【指定国】 AP(BW,GH,GM,KE,LR,LS,MW,MZ,NA,RW,SD,SL,SZ,TZ,UG,ZM,ZW),EA(AM,AZ,BY,KG,KZ,RU,TJ,TM),EP(AL,AT,BE,BG,CH,CY,CZ,DE,DK,EE,ES,FI,FR,GB,GR,HR,HU,IE,IS,IT,LT,LU,LV,MC,MK,MT,NL,NO,PL,PT,RO,RS,SE,SI,SK,SM,TR),OA(BF,BJ,CF,CG,CI,CM,GA,GN,GQ,GW,ML,MR,NE,SN,TD,TG),AE,AG,AL,AM,AO,AT,AU,AZ,BA,BB,BG,BH,BN,BR,BW,BY,BZ,CA,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DM,DO,DZ,EC,EE,EG,ES,FI,GB,GD,GE,GH,GM,GT,HN,HR,HU,ID,IL,IN,IS,JP,KE,KG,KM,KN,KP,KR,KZ,LA,LC,LK,LR,LS,LT,LU,LY,MA,MD,ME,MG,MK,MN,MW,MX,MY,MZ,NA,NG,NI,NO,NZ,OM,PA,PE,PG,PH,PL,PT,QA,RO,RS,RU,RW,SC,SD,SE,SG,SK,SL,SM,ST,SV,SY,TH,TJ,TM,TN,TR,TT,TZ,UA,UG,US,UZ,VC

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＱＲコード

２．アンドロイド

３．ＷＩＮＤＯＷＳ

４．ブルートゥース

(71)【出願人】

【識別番号】512193230

【氏名又は名称】オーセンティファイ・インク

【氏名又は名称原語表記】ＡＵＴＨＥＮＴＩＦＹ ＩＮＣ．

(74)【代理人】

【識別番号】100126675

【弁理士】

【氏名又は名称】福本 将彦

(72)【発明者】

【氏名】マイケル・ニューマン

(72)【発明者】

【氏名】ダイアナ・ニューマン

【テーマコード（参考）】

5J104

【Ｆターム（参考）】

5J104AA07

5J104AA12

5J104AA16

5J104EA08

5J104EA26

5J104JA21

5J104KA01

5J104KA05

5J104MA01

5J104NA02

5J104NA37

5J104NA38

5J104PA07

(57)【要約】

ネットワークユーザは、他のネットワークエンティティに対し、第１のプログラムを用いてユーザが入力した検証情報を受信しかつユーザ認証情報を格納することにより認証される。第２のプログラムは、他のエンティティからランダム数等の情報を受信する。第１のプログラムは、情報を第１のプログラムへ転送する入力を受信し、情報を認証サーバへ送信し、かつ認証サーバから他のエンティティの識別子、他の情報および認証ポリシ要件を受信する。第１のプログラムは、次に、認証サーバへ受信した認証ポリシ要件に一致する入力された検証情報を送信し、かつこれに応答して、ユーザ認証情報要求を受信する。第１のプログラムは、転送された情報および受信した他の情報を含むメッセージに、格納されたユーザ認証情報で署名し、かつこの署名入りメッセージを、ユーザを認証するために認証サーバへ送信する。
【選択図】図３

【特許請求の範囲】

【請求項1】

ネットワークユーザを他のネットワークエンティティに対して認証する方法であって、
第１のユーザ操作デバイス上で、
ユーザが入力した検証情報を受信し、
前記第１のユーザ操作デバイス上にユーザ認証情報を格納するために、第１のプログラムを実行することと、
第２のユーザ操作デバイス上で、
前記ネットワークを介して他のネットワークエンティティから情報を受信するために、第２のプログラムを実行することと、
さらに、
前記他のネットワークエンティティから前記第２のプログラムが受信した前記情報を、前記第１のプログラムへ転送する入力を受信し、
前記転送された情報の、前記ネットワークを介しての認証サーバへの送信を指令し、
前記ネットワークを介して前記認証サーバから、前記他のネットワークエンティティの識別子と、他の情報と、前記他のネットワークエンティティの認証ポリシ要件とを受信し、
前記受信した他のネットワークエンティティの認証ポリシ要件に一致する前記入力された検証情報の、前記ネットワークを介しての認証サーバへの送信を指令し、
前記検証情報の送信を指令した後、前記ネットワークを介して前記認証サーバから、ユーザ認証情報要求を受信し、
前記転送された情報および前記受信された他の情報を含むメッセージに、前記格納されたユーザ認証情報で署名し、かつ、
前記ユーザを認証するために、前記署名入りメッセージの、前記ネットワークを介しての前記認証サーバへの送信を指令するために、前記第１のプログラムを実行することと、
さらに、
前記ネットワークを介して前記認証サーバおよび前記他のネットワークエンティティのうちの少なくとも一方から、前記ユーザが首尾良く認証されているという指示を受信するために、前記第２のプログラムを実行すること、を含む方法。

【請求項2】

前記第１のユーザ操作デバイスおよび前記第２のユーザ操作デバイスは同じデバイスであり、
前記情報は、セッション識別子として機能するランダム数であり、かつ、
前記他の情報は、他のランダム数である、請求項１に記載の方法。

【請求項3】

前記ユーザの秘密／公開鍵ペアを生成するために、前記第１のプログラムをさらに実行することを、さらに含み、前記格納されるユーザ認証情報は、前記生成されるユーザの秘密／公開鍵ペアのうちの前記秘密鍵であり、かつ、
前記生成されたユーザの秘密／公開鍵ペアのうちの前記公開鍵の、前記ネットワークを介しての前記認証サーバへの送信を指令するために、前記第１のプログラムをさらに実行すること、をさらに含む、請求項１に記載の方法。

【請求項4】

前記第１のプログラムを、さらに、
ユーザの秘密データを生成し、
前記生成された秘密データを、第１の部分および第２の部分を含む複数の部分に分割し、
前記ユーザ認証情報を前記生成された秘密データで暗号化するために実行することを、さらに含み、前記格納される認証情報は、前記暗号化された認証情報であり、かつ、
前記第１のプログラムを、さらに、
前記秘密データの第２の部分の、前記ネットワークを介しての前記認証サーバへの送信を指令し、
前記検証情報の送信を指令した後、前記ネットワークを介して前記認証サーバから、前記秘密データの第２の部分の受信をもし、
前記格納された秘密データの第１の部分と、前記受信された秘密データの第２の部分とを結合し、かつ、
前記格納された暗号化認証情報を前記結合された秘密データ部分で復号するために実行すること、をさらに含み、前記メッセージは、前記復号されたユーザ認証情報で署名される、請求項１に記載の方法。

【請求項5】

前記第１のプログラムを、さらに、
ユーザが入力したユーザ認証ポリシ要件を受信し、
前記受信されたユーザ認証ポリシ要件の前記認証サーバへの送信を指令し、
前記認証サーバから、前記他のネットワークエンティティの前記認証ポリシ要件と共に、前記ユーザ認証ポリシ要件と前記他のネットワークエンティティの認証ポリシ要件との任意の相違点に基づいて任意の追加的な認証ポリシ要件も受信し、かつ、
受信された任意の追加的な認証ポリシ要件に一致する前記受信した検証情報の、前記ネットワークを介しての前記認証サーバへの送信も指令するために実行すること、をさらに含む、請求項１に記載の方法。

【請求項6】

前記情報は、第１の情報であり、かつ前記他の情報は、第１の他の情報であり、かつ前記認証サーバに前記第１のユーザ操作デバイスがもはや使用されていない、または紛失されている、もしくは盗まれていること、もしくは前記ユーザ認証情報が危険に曝されていることが通知された後に、
前記第２のプログラムを、さらに、
前記ネットワークを介して前記他のネットワークエンティティから第２の情報を受信するために実行することと、
前記第１または第３のユーザ操作デバイス上で、前記第１のプログラムを、
前記他のネットワークエンティティから、前記第２のプログラムが受信した前記第２の情報を前記第１のプログラムへ転送する入力を受信し、
前記転送された第２の情報の、前記ネットワークを介しての前記認証サーバへの送信を指令し、
前記ネットワークを介して前記認証サーバから、前記他のネットワークエンティティの識別子と、第２の他の情報と、前記他のネットワークエンティティの認証ポリシ要件とを受信し、
前記受信した他のネットワークエンティティの認証ポリシ要件に一致する前記入力された検証情報の、前記ネットワークを介しての前記認証サーバへの送信を指令し、かつ、
前記ネットワークを介して前記認証サーバから、前記送信された検証情報に応答して、前記ユーザを検証したが、前記ユーザ認証情報が無効にされていることから認証はできない、という通知を受信するために実行すること、をさらに含む、請求項１に記載の方法。

【請求項7】

前記第２のプログラムを、前記ネットワークを介して前記認証サーバからリダイレクト命令を受信するために、さらに実行することを、さらに含み、前記リダイレクト命令は、
前記ユーザを、前記ネットワーク上の前記他のネットワークエンティティの再登録ウェブサイトへリダイレクトするものである、請求項６に記載の方法。

【請求項8】

前記第１のプログラムを、さらに、
前記ネットワークを介して前記認証サーバから交換認証情報要求を受信し、かつ、
前記受信された交換認証情報要求に応答して、交換認証情報を生成し、前記生成された交換認証情報を格納し、かつ前記生成された交換認証情報の、前記ネットワークを介する前記認証サーバへの送信を指令するために実行することをさらに含む、請求項６に記載の方法。

【請求項9】

前記生成された交換認証情報の、前記認証サーバへの送信を指令した後、前記第１のプログラムを、さらに、
前記ユーザを認証するために、前記交換認証情報で署名された、前記第２の情報および前記第２の他の情報を含む他のメッセージの、前記ネットワークを介する前記認証サーバへの送信を指令するために実行することをさらに含む、請求項６に記載の方法。

【請求項10】

前記第２のプログラムを、さらに、
前記受信した情報の、ディスプレイ画面上への提示を指令するために実行することをさらに含み、
前記受信した情報は、光学コードの形式であり、かつ、
前記受信した情報を前記第１のプログラムへ転送する入力は、前記提示された光学コードのデジタル写真である、請求項１に記載の方法。

【請求項11】

前記第２のプログラムを、さらに、
前記受信された情報の印刷を指令するために実行することをさらに含み、
前記受信された情報を前記第１のプログラムへ転送する入力は、前記印刷された光学コードのデジタル写真である、請求項１に記載の方法。

【請求項12】

ネットワークユーザを他のネットワークエンティティに対して認証するための製品であって、
非一時的記憶媒体と、
前記記憶媒体に格納された論理とを備え、前記格納された論理は、プロセッサにより読取り可能であるように構成され、よって、前記プロセッサを、
ユーザが入力した検証情報を受信し、
ユーザ認証情報を格納し、
前記ユーザにより他のネットワークエンティティから取得された情報の入力を受信し、
前記入力された情報の、ネットワークを介しての認証サーバへの送信を指令し、
前記情報の送信を指令した後に、前記ネットワークを介して前記認証サーバから、前記他のネットワークエンティティの識別子と、他の情報と、前記他のネットワークエンティティの認証ポリシ要件とを受信し、
前記受信された他のネットワークエンティティの認証ポリシ要件に一致する前記入力された検証情報の、前記ネットワークを介しての前記認証サーバへの送信を指令し、
前記検証情報の送信を指令した後に、前記ネットワークを介して前記認証サーバからユーザ認証情報要求を受信し、
前記他のネットワークエンティティから取得された、転送された情報、および前記認証サーバから受信された前記他の情報を含むメッセージを、前記格納されたユーザ認証情報で署名し、かつ、
前記ユーザを認証するために、前記署名されたメッセージの、前記ネットワークを介しての前記認証サーバへの送信を指令するように動作させる、製品。

【請求項13】

前記格納された論理は、さらに、前記プロセッサを、
前記ユーザの秘密／公開鍵ペアを生成するように動作させるべく構成され、前記格納されたユーザ認証情報は、前記生成されたユーザ秘密／公開鍵ペアのうちの前記秘密鍵であり、
前記格納された論理は、さらに、前記プロセッサを、
前記生成されたユーザ秘密／公開鍵ペアのうちの前記公開鍵の、前記ネットワークを介しての前記認証サーバへの送信を指令するように動作させるべく構成される、請求項１２に記載の製品。

【請求項14】

前記格納された論理は、さらに、前記プロセッサを、
ユーザの秘密データを生成し、
前記生成された秘密データを、第１の部分および第２の部分を含む複数の部分に分割し、
前記ユーザ認証情報を前記秘密データで暗号化するように動作させるべく構成され、前記格納された認証情報は、前記暗号化された認証情報であり、かつ、
前記格納された論理は、さらに、前記プロセッサを、
前記秘密データの第２の部分の、前記ネットワークを介しての前記認証サーバへの送信を指令し、
前記検証情報の送信を指令した後、前記ネットワークを介して前記認証サーバから、前記秘密データの第２の部分の受信をもし、
前記秘密データの第１の部分と、前記受信した秘密データの第２の部分とを結合し、かつ、
前記格納された暗号化認証情報を前記結合された秘密データ部分で復号するように動作させるべく構成され、前記署名入りメッセージは、前記復号されたユーザ認証情報で署名される、請求項１２に記載の製品。

【請求項15】

前記格納された論理は、さらに、前記プロセッサを、
ユーザが入力したユーザ認証ポリシ要件を受信し、
前記受信されたユーザ認証ポリシ要件の送信を、前記ネットワークを介して前記認証サーバへ指令し、
前記ネットワークを介して前記認証サーバから、前記他のネットワークエンティティの前記認証ポリシ要件と共に、前記ユーザ認証ポリシ要件と前記他のネットワークエンティティの認証ポリシ要件との任意の相違点に基づいて任意の追加的な認証ポリシ要件を受信し、かつ、
受信された任意の追加的な認証ポリシに一致する前記入力された検証情報の、前記ネットワークを介しての前記認証サーバへの送信も指令するように動作させるべく構成される、請求項１２に記載の製品。

【請求項16】

前記情報は、第１の情報であり、かつ前記他の情報は、第１の他の情報であり、かつ前記認証サーバに前記ユーザ認証情報が危険に曝されていることが通知された後に、前記格納された論理は、さらに、前記プロセッサを、
前記ユーザにより前記他のネットワークエンティティから取得された、入力された第２の情報を受信し、
前記入力された第２の情報の、前記ネットワークを介しての前記認証サーバへの送信を指令し、
前記第２の情報の送信を指令した後、前記ネットワークを介して前記認証サーバから、前記他のネットワークエンティティの識別子と、第２の他の情報と、前記他のネットワークエンティティの認証ポリシ要件とを受信し、
前記受信された他のネットワークエンティティの認証ポリシ要件に一致する入力された検証情報の、前記ネットワークを介しての前記認証サーバへの送信を指令し、かつ、
前記検証情報の送信を指令した後、前記ネットワークを介して前記認証サーバから、前記ユーザを検証したが、前記ユーザ認証情報が無効にされていることから認証はできない、という通知を受信するように動作させるべく構成される、請求項１２に記載の製品。

【請求項17】

前記格納された論理は、さらに、前記プロセッサを、
前記ネットワークを介して前記認証サーバから交換認証情報要求を受信し、
前記受信された交換認証情報要求に応答して、交換認証情報を生成し、前記生成された交換認証情報を格納し、かつ前記生成された交換認証情報の、前記ネットワークを介しての前記認証サーバへの送信を指令し、かつ、
前記ユーザを認証するために、前記交換認証情報で署名された、前記入力された前記他のネットワークエンティティからの第２の情報および前記認証サーバからの前記第２の他の情報を含む他のメッセージの、前記ネットワークを介しての前記認証サーバへの送信を指令するように動作させるべく構成される、請求項１６に記載の製品。

【請求項18】

ネットワークユーザを他のネットワークエンティティによって登録するようにユーザネットワークデバイスを動作させる方法であって、
ユーザが入力した一組のユーザ識別と、ユーザが入力した登録データと、前記受信された一組の識別における識別毎に関連づけられるべき入力された特定の登録データのユーザ選択とを受信することと、
個々の識別を、その識別に関連づけられるとして選択される前記特定の登録データに関連づけて格納することと、
ある登録要求に応答して、前記ユーザにより他のネットワークエンティティから取得される情報の入力を受信することと、
前記入力された情報を、ネットワークを介して前記認証サーバへ送信することと、
前記ネットワークを介して前記認証サーバから、前記他のネットワークエンティティの識別子と、前記他のネットワークエンティティの登録データ要件とを受信することと、
前記格納されたユーザ識別のうちの１つを選択するユーザ入力を受信することと、
前記選択されて入力された識別の受信に応答して、前記選択されたユーザ識別に関連づけて格納された前記特定の登録データを自動的に検索することと、
前記ユーザを前記他のネットワークエンティティで登録するために、前記検索された登録データを、前記ネットワークを介して前記認証サーバへ送信すること、を含む方法。

【請求項19】

請求項１８に記載の方法であって、
前記ネットワークを介して前記認証サーバへ、前記他のネットワークエンティティが用いるための新しい認証情報を、証書を生成するために、前記認証サーバがこの送信される新しい認証情報に前記認証サーバの秘密／公開鍵ペアのうちの秘密鍵で署名するという要求と共に送信すること、をさらに含み、前記認証サーバの秘密／公開鍵ペアのうちの前記公開鍵は、前記他のネットワークエンティティに知られており、
前記方法は、
前記ネットワークを介して前記認証サーバから前記証書を受信すること、をさらに含む方法。

【請求項20】

ユーザにネットワークを介して他のネットワークエンティティとのトランザクションを通知するようにユーザネットワークデバイスを動作させる方法であって、
前記ネットワークを介して認証サーバから、トランザクション識別子と、トランザクション承認および認証要件と、前記トランザクションに関するメッセージを受信することを含み、前記メッセージは、（ｉ）前記ユーザの秘密／公開鍵ペアのうちの公開鍵で暗号化され、前記ユーザの秘密／公開鍵ペアのうちの秘密鍵は、前記ユーザにのみ知られ、かつ前記メッセージはさらに（ｉｉ）前記他のネットワークエンティティの秘密／公開鍵ペアのうちの秘密鍵によって署名され、かつ前記他のネットワークエンティティの秘密／公開鍵ペアのうちの公開鍵は、前記ユーザに知られており、
前記方法は、さらに、
前記暗号化された署名入りメッセージへ、前記他のネットワークエンティティの秘密／公開鍵ペアのうちの前記公開鍵および前記ユーザの秘密／公開鍵ペアのうちの前記秘密鍵を適用することによって、前記メッセージを検証しかつ復号することと、
前記検証され復号されたメッセージの前記ユーザへの提示を指令することと、
前記受信されたトランザクション承認および認証要件に基づいて、トランザクション承認もしくは認証情報、またはこれらの双方を表すユーザ入力を受信することと、
前記ネットワークを介して前記認証サーバへ、前記受信されたユーザ入力に基づいて、トランザクション承認および認証情報のうちの少なくとも一方を送信すること、を含む方法。

【発明の詳細な説明】

【関連出願の相互参照】

【0001】

本出願は、２０１２年４月１日に提出された仮出願第６１／６１８，８１３号、および２０１２年５月１０日に提出された仮出願第６１／６４５，２５２号に対する優先権を主張するものであり、本参照により双方の内容は全て開示に含まれる。

【技術分野】

【0002】

本発明は、認証に関する。より具体的には、本発明は、マルチパーティシステムにおけるマルチレベル認証を安全にしかつ単純化することに関する。

【背景技術】

【0003】

現時点で、インターネット認証は、パスワードに基づく認証を行っているが、パスワードおよびパスワードシステムは、不確かで、解明、想像が容易であり、かつ覆されやすい。パスワードの安全は、１）ユーザが自らのパスワードを記憶していること、および２）攻撃者がパスワードへアクセスしないこと、に依存している。インターネット上では、より安全なパスワードは記憶しにくいという理由で、「１２３４５」のようなありふれたパスワードがかなりの比率のユーザによって使用されている。他に、システムの安全性を高めるために試行されている解決手段には、ワンタイムパスワード（ＯＴＰ）が含まれるが、これは、帯域外方法（典型的には、トークン発生器が発送される前に、ユーザがコードを打ち込む、またはセットアッププロセスが実行される）を用いて、時間ベースである一回限りのトークンを生成する。最近まで、ＯＴＰは、ハードウェアトークンによって生成されていて、ユーザへ供給するには高価であった。最近の改善によって、ＯＴＰは、モバイルデバイス上で、ユーザが幾つかのシード数を記入することにより初期化されるソフトウェアアプリケーションとして配信されることが可能になっている。ＯＴＰは、推測可能なパスワードおよびブルート・フォース・アタックに対する防護を提供しているが、それでもなお、ウィンドウ内での再使用および盗用といった幾つかの攻撃を受けやすい（シードマテリアルが盗まれれば、誰でもＯＴＰを生成することができる）。他の、より強力な安全オプションは、「秘密」データ（即ち、秘密鍵）がユーザ制御を絶対に外れないことから恩恵が多大である公開／秘密鍵に依存する公開鍵インフラ（ＰＫＩ）であるが、ＰＫＩシステムは、典型的には、極めて複雑であって実施が困難であり、よって、巨大組織でしか使用されず、かつ鍵の無効化、各ユーザの設定、および期限切れ他になった場合の鍵の管理、といった多くのオーバーヘッド問題を引き起こす。

【0004】

認証の安全性を高めることに加えて、より優れた認証システムは、ユーザにとって容易なものであるべきである。追加の安全質問の使用、より長いパスワードの作成、他による、ＯＴＰ、ＰＫＩのようなありふれた安全強化は、ユーザ側をより複雑にする。ユーザは、詐欺行為を防止するための自身の認証データの管理も任されながらもシステムを単純に使用することができ、かつユーザ自身の選好に基づいて異なる認証強度を選択することができることが理想的である。スマートフォンおよび他のユーザデバイスの性能は拡大し、今では、セッション／認証データをチャネル間で、例えばブラウザとスマートフォンとの間で転送することが可能である。これにより、安全な認証をより強化することができるようになる。

【発明の概要】

【0005】

本発明の態様によれば、あるネットワークユーザを、例えば銀行または商業者であるネットワーク・サービス・プロバイダ等の他のネットワークエンティティに対して、または他のネットワークユーザに対して認証する方法は、第１のユーザが操作するデバイス上で、例えばパスワード、ユーザの他の知識ベースデータ、トークンおよび／またはユーザの生体データを含むユーザが入力する検証情報を受信するために第１のプログラムを実行することを含む。例えば、検証情報は、ユーザにより、第１のユーザ操作デバイスの一部であるタッチパッドまたはキーボードおよび／またはカメラまたはマイク等のセンサを用いて入力されてもよい。第１のプログラムは、入力された検証情報を第１のユーザ操作デバイス上に、他のパスワード、トークン、生体データまたはユーザの秘密／公開鍵ペアの例えば秘密鍵である暗号鍵等のユーザ認証情報と共に格納してもよい。第１のプログラムは、さらに、受信された検証データおよび場合によりユーザ認証情報の、ネットワークを介しての認証サーバへの送信を、指令するために実行される。

【0006】

第２のプログラムは、第２のユーザ操作デバイス上で、好ましくはセッション識別子として機能する情報、最も典型的には、かつ後述の説明を目的としてランダム数を、ネットワークを介して他のネットワークエンティティから受信するために実行される。

【0007】

第１のユーザ操作デバイスが、例えばスマートフォン、タブレットコンピュータ、またはインターネット等の適用可能なネットワーク上で通信できる他のスマートモバイル通信デバイスであることも可能であり、かつ第１のプログラムが、このようなスマート・モバイル・デバイス上で実行可能なアプリケーション、または他のプログラムに内蔵されるライブラリであることも可能である点は認識されるべきである。あるいは、第１のユーザ操作デバイスは、パーソナルコンピュータ、ラップトップ、または適用可能なネットワーク上で通信できる他のモバイル性の低い処理デバイスであることも可能であり、かつ第１のプログラムは、このような処理デバイス上で実行可能なアプリケーション、例えばブラウザのポップアップまたは別の認証アプリケーション、であることも可能である。同様に、第２のユーザ操作デバイスも、スマート・モバイル・デバイスまたはモバイル性の低い処理デバイスであることも可能であり、かつ第２のプログラムがアプリケーション、例えばＳａｆａｒｉ（商標）等のブラウザアプリケーションまたはＦｉｒｅｆｏｘ（商標）等のブラウザアプリケーション、であることも可能である。このように、第１のユーザ操作デバイスおよび第２のユーザ操作デバイスは、異なるデバイス、例えばスマートフォンおよびパーソナルコンピュータ、であっても、同じデバイス、例えばラップトップコンピュータ、であってもよい。

【0008】

第１のプログラムは、さらに、第２のプログラムが受信したランダム数を第１のプログラムへ転送する入力を受信するように、かつ転送されたランダム数の、ネットワークを介する認証サーバへの送信を指令するように実行される。代替実施形態において、ランダム数およびログイン開始要求は、認証サーバから直に着信してもよく、ランダム数が第２のプログラムと第１のプログラムとの間で転送される必要性が回避される。これに応答して、ネットワークを介して認証サーバから、他のネットワークエンティティの識別子、他の情報、および他のネットワークエンティティの認証ポリシ要件が受信される。

【0009】

受信されるランダム数の第１のプログラムへの転送に関して、実施態様によっては、第２のプログラムは、さらに、第２のユーザ操作デバイスへ通信可能に接続されるディスプレイ画面上への受信したランダム数の提示を指令するように実行されることが好ましい場合がある。このような場合、受信されるランダム数は、光学コード、例えばＱＲコード、の形式であることも可能であり、かつ受信される第１のランダム数を第１のプログラムへ転送する入力は、第１のユーザ操作デバイスに含まれるカメラから受信されることも可能である。例えば、受信されるランダム数を第１のプログラムへ転送する入力は、提示される光学コードのデジタル写真である場合もある。他の実施態様では、第２のプログラムは、さらに、受信されるランダム数の、第２のユーザ操作デバイスへ通信可能に接続されるプリンタ上での印刷を指令するように実行されることが好ましい場合がある。このような場合、受信される第１のランダム数を第１のプログラムへ転送する入力は、例えば、印刷された光学コードのデジタル写真である可能性もある。さらに他の実施態様では、ランダム数は、他の技術を用いて、例えばオーディオコードまたは近距離無線通信によって、転送されることも可能である。

【0010】

他のネットワークエンティティの認証ポリシ要件を受信した後、第１のプログラムは、受信したポリシ要件に一致する入力検証情報の、ネットワークを介する認証サーバへの送信を指令する。即ち、第１のプログラムは、他のネットワークエンティティの認証ポリシ要件の下で必要な検証情報を決定し、この検証情報を記憶装置から検索しかつ／またはこの情報をユーザからの入力を介して受信し、かつこの情報の認証サーバへの送信を指令する。

【0011】

認証サーバが、送信された検証情報に基づいてユーザを検証することができれば、ネットワークを介して認証サーバからユーザ認証情報要求が受信される。第１のプログラムは、転送されたランダム数および受信した他の情報を含むメッセージに、格納されているユーザ認証情報を用いて署名し、かつ、ユーザを認証する目的で、この署名入りメッセージの、ネットワークを介する認証サーバへの送信を指令する。

【0012】

認証サーバが、ユーザから受信する検証情報に基づいて、このユーザがまさしく、ユーザが言うところのユーザ自身であることを検証する点は理解されるべきである。したがって、この検証は、認証の一形式であり、かつ例えば、認証はユーザ認証情報に基づいてユーザがさらに認証されるまで完全には終わらない場合があるという理由で、初回認証として特徴づけられることも可能性である。

【0013】

また、認証情報がユーザの秘密／公開鍵ペアのうちの一方の鍵であれば、第１のプログラムは、好ましくは、典型的には初期設定の間にユーザの秘密／公開鍵ペアを生成するようにさらに実行されることも認識されるであろう。このような場合、格納されるユーザ認証情報は、生成されるユーザの秘密／公開鍵ペアのうちの秘密鍵であり、かつ場合により認証サーバへ送信されるように指令される認証情報は、この鍵ペアのうちの公開鍵である。したがって、認証サーバは、送信されたユーザの公開鍵を送信された署名入りメッセージへ適用してランダム数および他の情報を回復することにより、認証を完了することができる。

【0014】

認証情報がユーザ鍵または他の何らかの認証情報であるか否かに関わらず、署名入りメッセージの送信が指令された後、第２のプログラムは、さらに、ネットワークを介して認証サーバまたは他のネットワークエンティティもしくは双方から、ユーザが他のネットワークエンティティに対して首尾良く認証されたという指示を受信するように実行される。

【0015】

また、ユーザは、複数の他のネットワークエンティティに対する認証に使用される単一の認証情報を有しても、複数の他のネットワークエンティティの各々に対する認証用に異なる認証情報を有してもよい点も理解されるべきである。異なる認証情報が使用されれば、第１のプログラムは、さらに、複数の認証情報、潜在的には各プロバイダにおけるアカウント毎に１つの認証情報を格納し、かつ特有のアカウントまたはプロバイダサービスへのアクセス時に適正な認証情報を用いるように実行される。即ち、異なる認証情報が使用されれば、第１のプログラムは、さらに、他のユーザ認証情報を第１のユーザ操作デバイス上へ格納し、かつ場合により、他の認証情報の、ネットワークを介する認証サーバへの送信を指令するように実行される。

【0016】

第２のプログラムは、さらに、ネットワークを介して、以下、本セクションにおいて第２の他のネットワークエンティティと称する異なる他のネットワークエンティティから、以下、本セクションにおいて第２のランダム数と称する他のランダム数を受信するように実行され、かつ第１のプログラムは、さらに、この第２のランダム数を第１のプログラムへ転送する入力を受信するように実行される。

【0017】

また、第１のプログラムは、転送される第２のランダム数の、ネットワークを介する認証サーバへの送信を指令する。これに応答して、第１のプログラムは、ネットワークを介して認証サーバから、第２の他のネットワークエンティティの識別子と、以下、本セクションにおいて第２の他の情報と称するさらに他の情報と、第２の他のネットワークエンティティの認証ポリシ要件とを受信する。

【0018】

第１のプログラムは、受信した第２の他のネットワークエンティティの認証ポリシ要件に一致する格納された、かつ／または新たに入力された検証情報の、ネットワークを介する認証サーバへの送信を指令する。認証サーバが、送信された検証情報に基づいてユーザを検証することができれば、第１のプログラムは、ネットワークを介して認証サーバから、ユーザ認証情報要求を受信する。

【0019】

第１のプログラムは、第２の他のネットワークエンティティから受信される第２のランダム数および認証サーバから受信される第２の他の情報を含む他のメッセージに、格納された他の認証情報を用いて署名し、かつ署名された他のメッセージの、ネットワークを介する認証サーバへの送信を指令する。第２のプログラムは、さらに、ネットワークを介して認証サーバまたは第２の他のネットワークエンティティの何れか、もしくは双方から、ユーザが第２の他のネットワークエンティティに対して首尾良く認証されたという指示を受信するように実行される。

【0020】

本発明の他の好適な態様によれば、第１のプログラムは、さらに、拡張パスワードまたはパスワードのハッシュ等のユーザ秘密データを生成し、かつ生成された秘密データを、少なくとも第１の部分と第２の部分とを含む複数の部分に分割するように実行されることが可能である。このような場合、第１のプログラムは、ユーザ認証情報を秘密データ、即ち第１および第２の部分の双方を含む完全な秘密データで暗号化も行い、よって上述の格納されるユーザ認証情報は、暗号化された認証情報になる。第１のプログラムは、さらに、秘密データの第２の部分の、ネットワークを介する認証サーバへの送信を指令する。後のアクセスの間、認証サーバは、送信された検証情報に基づいてユーザを検証することができれば、先に認証サーバへ送信された秘密データの第２の部分を第１のプログラムへ送信し返す。したがって、第１のプログラムは、典型的には認証情報要求と共に、秘密データの第２の部分もネットワークを介して認証サーバから受信する。第１のプログラムは、次に、秘密データの第１の部分と受信される秘密データの第２の部分とを結合し、かつ結合された秘密データ部分を用いて、即ち完全な秘密データを用いて、格納されている暗号化された認証情報を復号化する。したがって、このような分割された秘密が利用されれば、上述の署名入りメッセージは、復号されたユーザ認証情報で署名されることになる。

【0021】

効果的には、第１のプログラムは、さらに、ユーザが入力したユーザ認証ポリシ要件を受信し、場合により、このような要件を第１のユーザ操作デバイス上に格納しかつこれらの要件を認証サーバへ送信するように実行される。このような場合、他のネットワークエンティティの認証ポリシ要件を受信した後、認証サーバは、ユーザ認証ポリシ要件と他のネットワークエンティティの認証ポリシ要件との間の任意の相違点に基づいて、任意の追加的な認証ポリシ要件を決定する。認証サーバは、決定した追加の認証ポリシ要件を他のエンティティの認証ポリシ要件と共に第１のプログラムへ送信する。したがって、このような場合、第１のプログラムは、他のネットワークエンティティの認証ポリシ要件と、任意の決定された追加の認証ポリシ要件とを受信する。また、第１のプログラムは、受信される追加の認証ポリシ要件に一致するユーザが入力した、かつ／または格納されている検証情報、ならびに他のネットワークエンティティの認証ポリシ要件に一致するそれの、ネットワークを介する認証サーバへの送信も指令する。即ち、第１のプログラムは、他のネットワークエンティティおよびユーザ認証ポリシ要件の双方を満たすために必要なユーザ検証情報の、ネットワークを介する認証サーバへの送信を指令する。

【0022】

本発明の他の好適な態様によれば、認証サーバは、第１のユーザ操作デバイスがもはや使用されていない、または紛失されている、もしくは盗まれた、という通知、または別段でユーザ認証情報が危険に曝されている、という通知を受信してもよい。そうであれば、第２のプログラムは、さらに、ネットワークを介して他のネットワークエンティティから、以後、本セクションにおいて第３のランダム数と称する他のランダム数を受信するように実行されることが可能である。即ち、この第３のランダム数は、同じネットワークエンティティから、先に初めに述べた受信されるランダム数として受信される。

【0023】

この時点で新しいスマートフォン等の第３のユーザ操作デバイスで実行され得る第１のプログラムは、第２のプログラムが受信したこの第３のランダム数を第１のプログラムへ転送する入力を受信し、かつ転送された第３のランダム数の、ネットワークを介する認証サーバへの送信を指令する。

【0024】

これに応答して、第１のプログラムは、ネットワークを介して認証サーバから、他のネットワークエンティティの識別子と、以下、本セクションにおいて第３の他の情報と称するさらに他の情報と、この同じ他のネットワークエンティティの認証ポリシ要件とを受信する。第１のプログラムは、受信した他のネットワークエンティティの認証ポリシ要件に一致する検証情報の、ネットワークを介する認証サーバへの送信を指令する。認証サーバが、送信された検証情報に基づいてユーザを検証することができれば、第１のプログラムは、ネットワークを介して認証サーバから、ユーザを検証したが、ユーザ認証情報が無効にされていることから認証はできない、という通知を受信する。

【0025】

効果的には、第２のプログラムは、さらに、ネットワークを介して認証サーバから、ユーザをネットワーク上の他のネットワークエンティティの再登録ウェブサイトへリダイレクトするリダイレクト命令を受信するように実行されることが可能である。

【0026】

それに代えて、または追加的に、第１のプログラムは、さらに、ネットワークを介して認証サーバから、交換認証情報要求を受信するように実行されることが可能である。これに応答して、第１のプログラムは、交換認証情報を生成し、生成した交換認証情報をその時点でユーザに操作されているデバイス上に格納し、かつ場合により、生成した交換認証情報の、ネットワークを介する認証サーバへの送信を指令する。交換認証情報が認証サーバへ送信されれば、認証サーバも次に、交換認証情報および交換認証情報の有効性証書を、他のネットワークエンティティによるユーザの登録において用いるために、ネットワークを介して他のネットワークエンティティへ送ることができる。

【0027】

効果的には、生成した交換認証情報の認証サーバへの送信を指令した後、第１のプログラムは、さらに、ユーザを認証するために、その時点で操作されているデバイス上で、交換認証情報で署名された、第３のランダム数および第３の他の情報を含む他のメッセージの、ネットワークを介する認証サーバへの送信を指令するように実行されることが可能である。

【0028】

他のネットワークエンティティによってユーザを登録するために、第１のプログラムは、スマートフォン、タブレットコンピュータまたは他のスマートモバイル通信デバイス等の第１のユーザ操作デバイス上で、ユーザデバイスに一組のユーザ識別子および登録データ（例えば、名前、誕生日、他）を受信させ、かつ受信された一組のユーザ識別子を各識別子が個々の一組の登録データに関連づけられるように格納すべく実行されることが可能である。第２のプログラムは、登録要求の他のネットワークエンティティへの送信を指令する。これに応答して、第２のプログラムは、ネットワークを介して他のエンティティからランダム数を受信する。第１のプログラムは、第１のユーザデバイスに、第２のプログラムが受信したランダム数を第１のプログラムへ転送する入力を受信させ、かつ転送されるランダム数を、ネットワークを介して認証サーバへ送信させるように実行される。これに応答して、第１のユーザデバイスは、ネットワークを介して認証サーバから、他のネットワークエンティティの識別子および他のネットワークエンティティの登録データ要件を受信する。

【0029】

場合により、登録の間、第１のユーザデバイスは、格納された一組のユーザ識別子のうちの１つを選択するユーザ入力を受信する。選択の受信に応答して第１のプログラムは、第１のユーザデバイスに、選択されたユーザ識別子に関連づけられる格納された登録データを自動的に検索させ、かつ検索された登録データから、受信された登録データ要件に一致するデータを選択させる。ユーザは、選択されたデータを編集する選択肢が与えられてもよい。第１のユーザデバイスは、次に、選択され、場合により編集されたデータを認証サーバへ送信する。

【0030】

また、第１のプログラムは、第１のユーザデバイスに、要求された検証情報を認証サーバへ、他のネットワークエンティティが使用するための新しい認証情報と共に送信させる。認証情報は、第１のユーザデバイスにより、技術上十分に理解されている様々な方法で確立されてもよい。例えば、第１のプログラムは、認証情報を生成してもよい。認証情報が公開／秘密鍵ペアであるような場合、第１のユーザデバイスは、公開／秘密鍵を生成または受信し、かつ公開鍵を認証サーバへ、認証サーバが公開鍵に署名して証書を生成するという要求と共に送信する。認証サーバは、次に、第１のユーザデバイスへ証書を送信し返す。したがって、本発明によれば、認証サーバが認証サーバおよび証書権限保有機関の双方として機能することができ、かつ第１のユーザデバイスがユーザ証書およびユーザ認証の双方を同一のエンティティ、即ち認証サーバから取得することは認識されるべきである。

【0031】

本発明のさらに他の態様によれば、第１のプログラムは、第１のユーザデバイスに、ユーザと、ユーザがそれによって既に登録されている、または他に既存の関係性を有する例えば商業者または銀行等のサービスプロバイダである他のネットワークエンティティとの間のトランザクションをユーザに通知させるように実行される。そうするために、第１のユーザデバイスは、ネットワークを介して認証サーバから、トランザクション識別子、トランザクション承認および認証要件、およびトランザクションに関する例えばトランザクションの詳細を含む可能性もあるメッセージを受信する。メッセージは、ユーザの認証情報を用いて暗号化される。認証情報がユーザの秘密／公開鍵ペアのうちの公開鍵であれば、ユーザの秘密／公開鍵ペアのうちの秘密鍵は、該当するユーザにのみ知られている。メッセージは、他のネットワークエンティティの秘密／公開鍵ペアのうちの秘密鍵によっても署名される。他のネットワークエンティティの秘密／公開鍵ペアのうちの公開鍵は、第１のプログラムに知られ、故にユーザに知られている。

【0032】

これに応答して、第１のプログラムは、さらに、第１のユーザデバイスに、他のネットワークエンティティの公開鍵およびユーザの秘密鍵を受信された署名入りの暗号メッセージへ適用することによってメッセージを検証させかつ復号化させる。第１のプログラムは、次に、第１のユーザデバイスに、検証された復号メッセージをユーザに提示する、例えば表示するように指令し、必要に応じて検証情報等の認証情報を入手する。即ち、第１のユーザデバイスは、要求される、しかも第１のユーザデバイス上では入手できない、例えば先に格納されていない任意の認証情報のユーザ入力を受信する。第１のユーザデバイスは、次に、トランザクション承認を表すユーザ入力を受信する。第１のユーザデバイスは、次に、ユーザを認証しかつ／またはトランザクションを承認するために、要求される内容に依存して、入力されたトランザクション承認、または入力された検証情報および／または認証情報等の他の認証情報、またはこれらの双方を、ネットワークを介して認証サーバへ送信する。

【0033】

当業者には、以後の詳細な説明を含む本開示から、ならびに本発明の実施によって、本発明のさらなる目的、優利な点および新規特徴が明らかとなるであろう。以下、本発明の説明を、特定の実施形態を参照して行うが、本発明がこれらの実施形態に限定されないことは理解されるべきである。本明細書に記載される教示内容へアクセスする一般的な当業者には、追加的な実施、変更および具現化、ならびに他の利用分野が認識されるであろうが、これらは、本明細書において開示されかつ請求の範囲に記載された本発明の範囲に含まれ、かつ本発明は、これらに関して重要な効用を有する。

【図面の簡単な説明】

【0034】

これらの図面は各々、描写しているシステムの実施形態例を表している。

【図1】図１は、主要なアーキテクチャ構成部品を例示する。

【図2】図２は、ログイン画面の一例を例示する。

【図3】図３は、ユーザ（ブラウザおよび携帯電話の双方）と、認証サーバと、ネットワークプロバイダとの間の通信を例示する。

【図4】図４は、モバイル・ユーザ・デバイス上の主要サブシステムを例示する。

【図5】図５は、認証サーバ上の主要サブシステムを例示する。

【図6】図６は、分割鍵システムおよびハイレベル・データ・フローを例示する。

【図7】図７は、ユーザと、認証サーバと、プロバイダとの間の相互作用の例を例示する。

【図8】図８は、システム内の様々なデータのためのデータ制御エリアを例示する。

【図9】図９は、ユーザ（ブラウザおよび携帯電話の双方）と、認証サーバと、ネットワークプロバイダとの間の通信を例示する。

【図10】図１０は、紙ベースの登録プロセスの例を例示する。

【図11】図１１は、通知システムの通信フローの例を例示する。

【発明を実施するための形態】

【0035】

概観
第１の認証フレームワーク
本発明の態様によれば、ネットワーク接続を有するユーザのモバイルデバイス、例えばスマートフォン４００またはタブレットと、様々な暗号および認証オペレーション１０１を実行することができるソフトウェアアプリケーションとを含む認証フレームワーク、図１参照、が提供される。また、ウェブサイトまたは端末サーバのようなネットワークサービス１０３も含まれる。アクセスソフトウェアは、ウェブブラウザ１０２のようなネットワークサービスに繋がるために使用され、よってモバイルデバイス上に、またはデスクトップまたはラップトップのような二次デバイス上に存在してもよい。アクセスソフトウェアは、ユーザにより提供される認証情報が、現在のネットワークサービスに関するものであることを検証するための情報を含む安全データを、ユーザのモバイルデバイスへ確実に送信できる信用のある構成部品を有してもよい。アクセスソフトウェアの信用のある構成部品は、ブラウザプラグインであってもよい。信用のある構成部品により提供される安全情報には、ネットワークサーバのアドレスまたはＵＲＬ（ウェブサービスの場合）がさらに含まれてもよい。認証サーバ１００は、ネットワークへ取り付けられ、よってネットワークサービス、アクセスソフトウェアおよびモバイルデバイスによる到達が可能である。

【0036】

アクセスソフトウェアとモバイルデバイスのソフトウェアとの間の、走査されるＱＲコードまたは近距離無線通信システムのような第１の転送接続部１０６は、認証セッション識別子（ＩＤ）を転送するために使用され、かつセッションを起動するための追加情報を含んでもよい。第１の転送接続部は、同じネットワークサービスへ接続しているアクセスソフトウェアとモバイル・ソフトウェア・アプリケーションとの間の検証を可能にするより完全な通信チャネル（例えば、ブルートゥース、近距離無線、ＵＳＢ接続、他）によって増強されてもよい。第１の転送接続部上で受信されるセッションＩＤは、ＱＲコードの光学ディスプレイを介して転送されてもよい。その場合、セッションＩＤの評価は、ＱＲコードをカメラで読み取ることと、ＱＲコードを復号することを含んでもよい。

【0037】

モバイル・デバイス・ソフトウェアと認証サーバとの間の第２の転送接続部１０７は、セッションの活性に関する安全チェックの転送を実行し、かつユーザの認証情報およびネットワークサービスをチェックする。認証サーバは、詐欺行為および異常検出システム５０４を含んでもよい。ユーザの認証情報は、公開／秘密鍵システムを用いる非対称公開鍵暗号化に基づくものであってもよく、ユーザの認証情報は、アクセスされるネットワークサービスに固有のものであってもよい。

【0038】

認証の間に公開／秘密鍵システムが使用される場合、これは、認証サーバとネットワークサービスとの間の認証、および認証サーバとユーザ・モバイル・ソフトウェアとの間の認証を可能にする通信鍵／証書セットを含んでもよい。また、これは、ユーザとネットワークサービスとの間の認証を可能にするユーザ検証鍵／証書セットも含んでもよい。また、ユーザ検証鍵セットは、ユーザ間の検証鍵、および複数のサービスを通じて用いるための単一の鍵／証書、またはユーザ−サービスペア毎の固有の鍵、も含んでもよい。

【0039】

さらに、認証サーバは、認証データを検証しかつ期限切れ、紛失その他無効の証書に対処するプロセスを決定するために使用されることも可能である。また、認証サーバは、詐欺行為検出および監査を実行してもよい。最後に、認証サーバにより、１つまたは複数の証書署名権限保有機関が包含され、かつ証書を承認するために使用されることも可能である。好ましくは、証書署名権限保有機関は３つ、即ち、ネットワークサービスの認証情報のためと、ネットワークサービスに対するユーザの認証情報のためと、認証サーバに対するユーザの認証情報のため、の３つが使用される。紛失した認証情報に対処するプロセスには、紛失した認証情報を無効化することが含まれてもよい。

【0040】

安全チェックは、さらに、生体データ、トークンベースの認証データまたは知識ベースの追加的ファクタ等の追加の認証ファクタを含んでもよい。生体データがこれらのファクタのうちの１つであれば、これは、デバイス上のカメラを用いる手認識、ユーザ・モバイル・デバイスへ取り付けられたデバイスから収集される生体データ、ＵＳＢ指紋スキャナを用いる指紋認識を含むことも可能である。使用される追加的な認証ファクタは、パスワードおよび／または個人識別番号（ＰＩＮ）等の知識ベースの質問、または事前登録の電話番号のような検査可能な特性を含むことも可能である。使用される追加的な認証ファクタは、取り付けられたカードリーダで読み取られるスマートカード、近距離無線を介してアクセスされる安全なデータトークン、および／またはモバイルデバイスのＳＩＭカードから読み取られるデータ等の、モバイルデバイス上のトークン、またはモバイルデバイスへ取り付けられたトークンの何れかを含むことも可能である。

【0041】

アクセスソフトウェアへの第３の転送接続部は、ユーザ認証が完了した時点をアクセスソフトウェアが認識できるようにし、よってアクセスソフトウェアと、認証サービス１０５またはネットワークサービス１０８の何れかとの間に存在してもよい。アクセスソフトウェアは、認証が完了すると、ログイン状態へ自動的に移動してもよい。
第２の認証フレームワーク

【0042】

この認証フレームワークは、ネットワークを通じた様々なサービスと、これらのサービスのユーザとを含み、これらは、ユーザによる通信を可能にする様々な認証情報を有する。ユーザは、人ではなく、自動化されたプロセスである可能性もある。また、どのユーザサービス認証情報が有効であるか、紛失しているか、または期限切れであるかを示す、かつログインが許可されるかどうかの決定に使用可能な認証データも含まれる。関係者間の通信用に提供されるシステムは、伝統的なネットワークプロトコル、プロキシまたはリバースプロキシを含んでもよい。

【0043】

また、１つまたは複数の階層的認証サーバも提供され、この階層的認証サーバの最上層は、個々の認証要求を、認証されるサービスに基づいて下位のレベルまたは層へリダイレクトすることができる。各認証サーバは、認証データを用いて、ユーザ認証情報がまだ有効かどうかに関する決定を下すことができる。階層的認証サーバは、認証要求を１つのサーバまたはサーバクラスタが処理する単一レベルのサーバであってもよい。下位層のサーバは、所望されれば、ファイアウォールまたは周辺ネットワークゲートウェイの背後に存在し、かつローカルまたは組織内ネットワーク上のサービスを扱うことも可能である。ログインは、例えば、認証情報が紛失としてマーキングされていて、もはや有効でない、という理由で拒絶されてもよい。
第３の認証フレームワーク

【0044】

この認証フレームワークは、ウェブサイトまたは端末サーバのように、ネットワークへ接続される認証サーバと、到達可能なネットワークサービスとを含む。また、認証サーバ上にはユーザ認証情報セットも含まれ、その幾つかは、例えばユーザ認証情報が存在するデバイスは紛失している、という理由で無効とマーキングされてもよい。

【0045】

アクセスソフトウェアは、ネットワークサービスへ到達するために使用される。ネットワークサーバと認証サーバとの間の通信システムは、ネットワークサービスに、ユーザは有効であるが、個々の認証情報は無効であるか、存在しないことを告げる。通信システムは、認証サーバから返されるＡＰＩオブジェクト内のメソッドクエリであっても、認証情報の有効性を返すカスタムプロトコルであってもよい。

【0046】

追加的検証のためにアクセスソフトウェアを登録またはアラートページへリダイレクトする際には、簡易方法が実施される。簡易リダイレクト方法は、登録ページへのウェブ・リダイレクト・メッセージであっても、登録を目的としてカスタムアプリケーションを開始するためのアンドロイドのようなアプリケーション間通信であってもよい。ユーザは、サイト上で登録する、またはサイト上で登録し直す必要があるという理由でリダイレクトされてもよく、この場合、ユーザの登録情報は、ユーザにより承認された予め設定されている識別情報で記載されることも可能である。図８を参照されたい。ユーザ識別情報は、ユーザ・モバイル・デバイス８０６上、または認証サーバ上に格納されてもよい。識別情報は、ユーザが複数の識別（業務用、個人用、他）を有してこれらから選択できるようにする識別セットに予めグルーピングされてもよい。
データ機密保護システム

【0047】

また、暗号化および復号化のための対称鍵を用いる暗号データ格納ロケーション（キーストアまたはデータストア）を含む、モバイルデバイス上のデータを保護するためのシステムも提供される。図６を参照されたい。ユーザが入力した秘密データは、６０１で複数の部分に分割され、ユーザが入力した秘密データの一部は、６０５で対称復号鍵の第１の部分を入手するために局所的に使用される。ユーザが入力する秘密データは、パスワードまたはパスフレーズ、生体テンプレートまたはマッチ、またはユーザが描く画像であってもよい。ネットワーク到達可能サーバは、６０４において、ユーザが入力した秘密データの第２の部分を用いて、復号のための対称鍵の第２の部分を検索する。例えば、パスワードの半分を用いて復号鍵の半分を含むデータのローカルブロックを復号すること等によって、パスワードのこの半分をシステム・レベル・データと結合して復号鍵の半分を入手してもよい。例えばログイン試行の失敗数を限定し得るネットワークサーバ上の詐欺行為検出ポリシ６０３は、復号鍵の第２の部分に対する不審な要求に警告を出し、またはこれに応答する。
認証サーバ

【0048】

図７を参照すると、各ユーザについて、どのサービスに対して認証情報を有するか、アクセスするにはどのタイプの認証が必要か、および認証情報が有効かどうか、を明記するデータセットを含む認証サーバ７１３も提供される。サービス毎に、認証サーバ７１１を用いて最低限の安全ポリシが指定される。ポリシ管理ソフトウェア７００は、ユーザが、（ｉ）サービスの最低限の仕様に適合する限り、特定のサービスまたはサービスセットへのアクセスに必要な認証のタイプを修正し、（ｉｉ）その認証情報を削除し、または（ｉｖ）その他、そのユーザデータと相互作用すること、を目的として、その固有のレコードを更新できるようにする。ポリシ管理ソフトウェアは、ユーザのモバイルデバイス上またはユーザがアクセスするウェブサイト上に存在してもよい。修正は、新しい認証ファクタの追加（例えば、ログインにはＰＩＮだけでなく顔も必要であることを明示する）、またはファクタのより正確または限定的なものへの変更（例えば、手認識ではなく顔認識を用いる）を含む可能性もある。
第４の認証フレームワーク

【0049】

本発明の態様によれば、認証フレームワークは、ネットワーク接続と様々な暗号および認証オペレーションを実行することができるソフトウェアアプリケーションとを含む、ユーザのモバイルデバイスを含む。また、ウェブサイトまたは端末サーバのようなネットワークサービスも含まれる。アクセスソフトウェアは、ウェブブラウザのようなネットワークサービスに繋がるために使用され、よってモバイルデバイス上に、またはデスクトップまたはラップトップのような二次デバイス上に存在してもよい。認証サーバは、ネットワークへ接続され、よってネットワークサービス、アクセスソフトウェアおよびモバイルデバイスによって到達可能である。所望されれば、認証サーバは、詐欺行為および異常検出システムを含むことが可能である。図９を参照されたい。識別子９０２は、ブラウザへ供給されて、モバイルデバイスのソフトウェアアプリケーションを一意に識別する。識別子は、電話番号またはユーザ名のようなユーザ毎の固有値であることも可能である。

【0050】

モバイルデバイスのソフトウェアアプリケーションと認証サーバとの間の第１の接続部は、セッションの活性の安全チェックと、ユーザおよびネットワークサービスの認証情報の転送とを実行する。ユーザの認証情報は、公開／秘密鍵システムを用いる非対称公開鍵暗号化に基づいてもよく、認証情報は、アクセスされているネットワークサービスに固有のものである可能性もある。安全チェックは、さらに、生体データ、トークンベースの認証データまたは追加的な知識ベースのファクタを含む、追加的な認証ファクタを含んでもよい。生体データは、ユーザのモバイルデバイスへ取り付けられるデバイスから収集されることも可能である。

【0051】

アクセスソフトウェアへの第２の接続部は、認証が完了した時点をアクセスソフトウェアが認識できるようにする。第２の通信チャネルは、アクセスソフトウェアと認証サービスとの間であっても、アクセスソフトウェアとネットワークサービスとの間であってもよい。
第５の認証フレームワーク

【0052】

この認証フレームワークは、ネットワーク接続と、様々な暗号および認証オペレーションを実行できるソフトウェアアプリケーションとを有する、ユーザのモバイルデバイスを含む。また、ウェブサイトまたは端末サーバのように、ネットワークサービスも含まれる。アクセスソフトウェアは、ウェブブラウザのようなネットワークサービスへ繋がるために使用され、よってモバイルデバイス上に、またはデスクトップまたはラップトップのような二次デバイス上に存在してもよい。認証サーバは、ネットワークへ接続され、よってネットワークサービス、アクセスソフトウェアおよびモバイルデバイスによって到達可能である。ブラウザセッションをモバイルデバイスのソフトウェアアプリケーションへ一意に結ぶための手段が提供される。これらの手段は、ブラウザから、ＱＲコードの光学ディスプレイを介する等、光学コードを介してソフトウェアアプリケーションへ伝達されてもよい。この伝達の処理は、ＱＲコードをカメラで読み取ること、およびＱＲコードを復号することを含むことも可能である。

【0053】

モバイルデバイスのソフトウェアアプリケーションと認証サーバとの間の第１の接続部は、安全チェック、ユーザの認証情報およびネットワークサービスの転送を実行し、かつ安全なメッセージングチャネルを提供する。安全なメッセージングチャネルは、（ｉ）ネットワークサービスからモバイルデバイスのソフトウェアアプリケーションへの一方向通信手段、または（ｉｉ）ネットワークサービスがモバイルデバイスのソフトウェアアプリケーションからの追加情報を問い合わせるための双方向通信手段であってもよい。安全なメッセージングチャネルは、暗号化されたメッセージデータ、承認要求またはポリシ情報のうちの１つまたはそれ以上を送信する能力を含む規定されたメッセージングプロトコルを有してもよい。

【0054】

アクセスソフトウェアへの第２の接続部は、認証が完了した時点をアクセスソフトウェアが認識できるようにする。
認証登録システム

【0055】

認証登録システムは、ネットワーク接続部と様々な暗号および認証オペレーションを実行できるソフトウェアアプリケーションとを有する、ユーザのモバイルデバイスを含む。図１０を参照されたい。また、登録セッションを一意に識別するためのコード１００８を含む、ネットワークサービス関連の個々のアカウントに関する印刷文書１０００も含まれる。認証サーバは、ネットワークへ接続され、よってモバイルデバイスのソフトウェアアプリケーションおよびネットワークサービスによって到達可能である。モバイルデバイスのソフトウェアアプリケーションに対して、登録セッションを一意に識別するための手段が含まれる。これらの手段は、印刷文書からソフトウェアアプリケーションへ、ＱＲコードを含む光学コードを介して伝達されてもよく、伝達の処理は、ＱＲコードをカメラで読み取ることと、ＱＲコードを復号することを含んでもよい。

【0056】

モバイルデバイスのソフトウェアアプリケーションと認証サーバとの間の第１の接続部は、安全チェックおよびユーザの認証の転送を実行する。ネットワークサービスへの第２の接続部は、登録が完了した時点をネットワークサービスが認識できるようにする。
（実施の形態）
マルチパーティ認証システム

【0057】

マルチパーティ認証システムは、ネットワーク・サービス・プロバイダ１０３に対してユーザを検証するために、本質的に信用できない認証プロバイダ１００を用いる。システムは、様々なユーザ認証情報（例えば、公開／秘密鍵および証書）を保護しかつ保持する、モバイルタブレットまたはスマートフォン４００のような信用のあるユーザデバイスを包含し、かつ、生体ベース、知識ベース（即ち、パスワード）およびトークンベースを含む、可変数および可変タイプの認証情報を収集することができる。認証サービス１００は、ＷＡＮに渡るリアルタイムのスケーラブル認証を可能にするユーザ駆動の設定および制御を提供し、かつ紛失鍵の回復および簡易登録または再登録を可能にする。

【0058】

次に、図に例示されている実施形態の説明を詳細に参照する。実施形態の説明は、図面および関連の説明を参照して行うが、発明の範囲を本明細書に開示される実施形態に限定する意図はない。逆に、参照の意図は、全ての代替案、変更および等価物を包含することにある。一般的な当業者には、本明細書に開示される実施形態に範囲を限定することなく、追加のデバイスを含む他の実施形態、または例示されたデバイスのコンビネーションが追加または組み合わせられ得ることが認識されるであろう。

【0059】

本発明は、マルチパーティシステム（ユーザ、認証サービスプロバイダ１００およびネットワーク・サービス・プロバイダ１０３）を基礎とし、かつ下記の主要なアーキテクチャ構成部品を含む（図１から図５までのアーキテクチャ構成部品参照）：
・ネットワーク接続部４０２と、データ入力システム４０１と、様々な認証機能を実行できるようにするソフトウェア認証アプリケーションまたはａｐｐ（Ｑａｐｐ）１０１とを含むユーザ・モバイル・デバイス４００。Ｑａｐｐ１０１は、認証通信４０９を管理し、付加的な認証データ４０３および４０４を収集し、かつユーザ認証情報およびデータ４０５〜４０８を格納する。ユーザ・モバイル・デバイスは、スマートフォン、タブレットコンピュータ、ラップトップ、他を含む、任意のパーソナルデバイスであることが可能である。一実施形態は、セルラベースのネットワーキングおよびＷｉＦｉネットワーキングの双方を含むスマートフォンの使用である。モバイル・ユーザ・デバイスの第２の実施形態は、特殊化された認証デバイスである場合もある。理想的には、ユーザ・モバイル・デバイスには、生体データ４０４または追加的なトークンデータ４０３を収集するために使用されることが可能な（カメラ、マイク、他のような）追加センサ４０４も含まれる。
・ユーザがアクセスするためのログインを要求されているという情報を有する、ネットワーク・サービス・プロバイダ１０３（プロバイダ）。認証中のプロバイダの主たる役割は、ユーザを正しいプロバイダアカウントへマップすることである。場合により、プロバイダは、認証情報を再検査しかつ他の安全チェックを実行することができる。ある実施形態は、ユーザがそのアカウントに関する情報を得るためにログインできるようにする、ｅバンキング・ウェブサイトのようなウェブサイト１０３である。第２の実施形態は、（Ｗｉｎｄｏｗｓログイン画面のような）ネットワーク対応デスクトップログインである場合もある。
・ユーザのネットワークサービス・アクセス・ソフトウェア。これは、ユーザが通信チャネル１０８を介してログインするために相互作用するソフトウェアである。ウェブサイトの場合、アクセスソフトウェアは、ウェブブラウザ１０２であり、他のタイプのネットワークサービスは、特殊化されたアクセスポータルを有する場合もある。理想的には、これは、アクセスソフトウェアとモバイルデバイス上の認証アプリケーションとの間でデータセットを転送する能力を有するものと思われる。図２を参照されたい。ある実施形態は、２次元的バーコードシステムである視覚的ＱＲコード２００を示すことであり、他のオプションには、オーディオコード、近距離無線通信、他が含まれる。以後の説明では、第１のチャネル１０６（即ち、アクセスソフトウェア（即ち、ブラウザ）と認証アプリケーションとの間）における情報転送にＱＲコードの使用を想定している。少なくとも幾つかの実施において、ネットワークサービスは、一意のユーザＩＤを収集する能力を有するべきである。図９を参照されたい。実施の例は、ｉ）９０２において、ユーザがウェブサイト上のフィールドへデータを直接入力すること、ｉｉ）ＩＤがクッキーまたは他のブラウザ記憶ロケーションに格納されること、またはｉｉｉ）ユーザのモバイルデバイス（接続されたＵＳＢ、近距離場、他）との通信手段、を含む場合もあり、この場合、ユーザのモバイルデバイスは一意のユーザＩＤを提供する。
・様々なサービスを提供する認証サーバ１００（Ｑサーバ）。Ｑサーバは、５０１および５０５を含めて、ユーザおよびプロバイダの様々な認証情報が正しく設定されかつ使用されることを保証する中間ＰＫＩ管理ポータルとして行動し、生体ベースおよびトークンベースのオプションを含む追加的な認証形式５０２を処理し、紛失した電話の報告、またはポリシ調停システム５０３を介する認証のアップグレードを含めて、ユーザが自身の認証を管理することを可能にし、場合により、ユーザ識別を管理し、かつ認証要求および使用される認証データに関する詐欺行為検出５０４を行う。ある実施形態では、認証サーバは、ネットワーク接続デバイスが通信チャネル１０４、１０５および１０７を介して接続することを可能にしかつ５０６により管理される、様々な情報を要求または送信する単一のインターネット到達可能ホスト５００またはサーバクラスタである。第２の実施形態において、認証サーバは、認証に関する決定がサーバ間に流れることを可能にするサーバの階層より成ってもよい。この実施形態では、下位レベルのサーバは、認証サービスを、ファイアウォールまたは他のネットワークおよび安全境界背後の組織または企業ネットワークへ提供してもよい。ある実施形態では、Ｑサーバは、認証データを紛失する安全リスクを制限するために、プロバイダから分離したサーバ上に収容される。

【0060】

各関係者の役割は、システム全体に信用を広げることから、一関係者が危険に曝されても、システム全体に対する危険は限定されることが可能である。図７を参照されたい。例えば、本発明の１つの強みは、ユーザがそのモバイルデバイスを失っても、７０５において認証情報を容易に取り消すことができることにあり、認証情報は、アクセスに際してユーザに（パスワードのような）監査可能な秘密データを入力するように要求する場合もあって、安全なサイトは、アクセスに際して生体データを要求する。さらに、これらの制御は何れも、プロバイダの介入または変更を必要としない。安全上の他の利点は、フィッシング攻撃の間、ユーザ認証データが絶対にプロバイダ（またはプロバイダを装った者）へ転送されず、よって認証情報の盗難は不可能であることにある。最後に、Ｑサーバが危険に曝されても、Ｑサーバはユーザの個人的な認証情報へのアクセスを持たないことから、Ｑサーバからの全データを有する攻撃者であっても、ユーザになることはできず、またはプロバイダへの追加アクセスを得ることはできない。さらに、認証サーバは認証ゲートウェイとして行動することから、システム内部の多くのイベントは、完全に透明的に、またはユーザシーンの背後で発生することが可能である。例えば、モバイルデバイス紛失後のプロバイダへの再登録は、ユーザ側で何ら相互作用を追加することなく発生することが可能である。また、認証サーバシステムの一実施形態が事実上認証サーバセットより成ることも可能であり、そのうちの幾つかは、ファイアウォールまたは他の周辺デバイス背後の組織ネットワーク上に存在し、かつ認証要求は、特定のどの認証サーバが責任を負うべきかをアクセスされているネットワーク・サービス・プロバイダに基づいて決定すべくサーバ間で調整される。

【0061】

図７は、可能なユーザ制御エリアおよび管理エリア７１４および７１５のうちの幾つかを描いている。第１のセクション７１６は、７１０上でサーバへ伝達される特定のプロバイダへアクセスするためにどの程度の認証が所望されるかに関するユーザポリシ７００が、ユーザがプロバイダのサイトへアクセスするための究極の要件７０２を作成すべく、７１１上で伝達されるプロバイダ自身のポリシ７０１を用いて分析される、認証サーバ７１３で行われるポリシ調停を例示している。次の３つのセクション７１７、７１８および７１９は各々、ユーザが７０３でそのパスワードの変更を希望し、７０５でその認証情報を失い、または７０７で認証情報が期限切れになっても、７０９に示すように、プロバイダを関係させる必要のあるアクティビティではないことを示している。通信は、認証サーバ７１３とユーザ制御エリア７１４との間で、７０３から７０８までを介して発生する。

【0062】

図８は、１つまたは複数のプロバイダ８０１および識別８０６の複数のセットに渡って複数のアカウントを維持するユーザａｐｐ８００の能力を示す。アカウント情報は、ユーザ認証要件も含む。ユーザ識別８０６は、複数のデータレコードを含んでもよい。認証サーバ７１３は、次に、ポリシ管理の項目において論じたように、８１３において、ユーザが設定したアカウント毎に、ユーザとプロバイダとの間の認証要件を調停する。認証サーバ７１３は、また、複数のユーザエリアと複数のプロバイダエリア８１１および８１２との間の通信を促進する。例えば、第１のユーザ／プロバイダペアの場合、情報は、ユーザエリア７１４からチャネル８０７を介してチャネル８０９上を第１のプロバイダエリア８１１へ流れる。第２のユーザ／プロバイダペアは、類似するチャネル８０８および８１０のセット上へ異なるデータを送信する。プロバイダは各々、認証設定オプション８０３および８０５を含む固有のアカウントデータ８０２および８０４のセットを保持する。

【0063】

アーキテクチャに加えて、異なる関係者間で発生する通信セットが存在する。システムとの一般的な相互作用の１つは、ユーザがウェブサイトにログインする時点である。下記は、ログインの一実施形態の高レベルビューである。
１．ユーザは、本発明のログインシステムを実装するウェブサイトへ進む。図２は、ログインがどのようなものに見えるかを示すスクリーンショットである。通常のアカウントログインの選択に加えて、Ｑコードを有するＱＲコード２００が表示されている。Ｑコードは、ヘッダブロック（後述する）と、コードが有効である限り全ユーザに渡って一意であることが保証されかつ認証セッションの簡易識別子として作用するセッションＩｄ（Ｑｓｉｄ）とを含む。
２．次に、図３を参照すると、ユーザは、そのスマートフォン側でＱａｐｐを起動してＱコード３０２をスキャンする。これにより、認証サーバ（Ｑサーバ）１００との通信３０３が開始され、３０４で提供されるユーザおよびプロバイダのポリシに依存して、ユーザは、ｐｉｎ、トークンデータおよび／または生体データを含み得る追加的な認証情報３０５を入力する。より高位の安全サイト、例えばＰＣバンキングを目的とする場合、ユーザは、下記を経る場合もある。図３は、ログイン例を示す。
ｉ．「プロバイダＸへのログインを希望しますか」というメッセージが現れる。これにより、ユーザは、ユーザが試行しているログイン先と、１０２における接続先のロケーションとが同じである点を検証することができる。
ｉｉ．ユーザは、ログインを承認し、次にその秘密データを入力するが、サイト１０３が３ファクタ認証を要求すれば、ユーザは、何らかの形式の生体データ（顔写真、手の画像または音声サンプル等）を提出しなければならない場合もある。
ｉｉｉ．次に３０６において、セッション情報、セッション検証、承認および生体データがＱサーバ１００へ提出されて検証される。シーン背後の３０７で認証を承認すれば、Ｑサーバは、プロバイダへ通知し（よってサイトは、ユーザのチャレンジ／応答の独立した検証を実行することができる）、かつユーザブラウザは、自動的にリフレッシュされかつログインされる。
３．これで、ユーザはログインされ、３０２におけるＱＲコードのスキャンを除けば、情報を入力する必要はなく、あるいは、ウェブサイト上のリンクをクリックする必要もない。これにより、事実上透明で、完全に自動化された、しかも安全な認証システムとなる。

【0064】

下記は、ログインの他の実施形態を示す高レベルビューである。図９を参照されたい。
１．９０１において、ユーザは、本発明のログインシステムを実装するウェブサイトへ進む。従来のユーザ名およびパスワードフィールドの代わりに、ウェブサイトは、９０２においてユーザがその一意のユーザＩＤを入力するための単一フィールドを有する。一意のＩＤは、ユーザ名のように割り当てられることも可能であり、または電話番号のようなものであることも可能である。ユーザは次に、提出をクリックし、かつウェブサイトは、Ｑサーバからの連携で一意のセッションｉｄ（Ｑｓｉｄ）９００を割り当てて認証を開始する。第２の実施形態では、一意のＩＤは、クッキーに保存される、またはアクセス中にモバイルデバイスから検索される場合もある。また、ブラウザからＱｓｉｄまたはセッション固有の他の識別子を送信することにより、ブラウザとモバイルデバイスとを結びつけることも可能である。送信は、ユーザに表示されかつモバイルデバイスを介してスキャンされるＱＲコードの形式であることも可能である。
２．プロバイダは、９０３において、認証サーバへ一意のユーザＩＤおよびＱｓｉｄを伝達する。
３．認証サーバは、９０４において、一意のユーザＩＤに基づいてユーザのモバイルデバイスに接触する。認証サーバ（Ｑサーバ）によるこの伝達は、認証要件９０５を含む。ユーザおよびプロバイダのポリシに依存して、ユーザは、ｐｉｎ、トークンデータおよび／または生体データ９０６を含み得る追加的な認証情報を入力する。上述の図３の場合と同様に、ログイン例を示す図９も、ログインを終わらせる完成ステップ９０７および９０８を示している。
４．これで、ユーザはログインされ、その一意のユーザＩＤを提供することを除けば、情報を入力する必要はなく、あるいは、ウェブサイト上のリンクをクリックする必要もない。これにより、事実上透明で、完全に自動化された、しかも安全な認証システムとなる。
固有の安全およびアーキテクチャ問題

【0065】

Ｑコードは、下記の情報、即ちそれが本発明の認証トークンであることを明示するヘッダタグ、および推測を事実上不可能にし、環境内での一意性を保証するに足る長さの、かつＱｓｉｄの再使用の発生を低頻度にするに足る長さのＱｓｉｄ、を含む。ある実施形態では、Ｑｓｉｄは、少なくとも１２８ビット長さのランダム数である。場合により、Ｑコードは、要求されるログイン／登録のタイプまたは代替認証サーバのようなセッション固有情報を含んでもよい。

【0066】

Ｑｓｉｄに加えて、プロバイダからＱサーバを介してＱａｐｐへ送られる他の情報である活性ＩＤ（Ｑ活性）も存在する。ある実施形態では、Ｑ活性は、プロバイダにより発生されるランダム数である。Ｑ活性は、１）攻撃者はＱｓｉｄおよびＱ活性数字の双方を知る必要があることから、Ｑｓｉｄの再使用をより困難にする、および２）プロバイダがＱ活性を選べることから、Ｑサーバによる攻撃のリプレイを不可能にする、という２つの主要な安全機能を提供する。ある実施形態において、プロバイダがＱ活性ランダム数の生成を希望するか、Ｑサーバを信頼するかは、設定上のオプションである。

【0067】

第２の実施形態では、ユーザのアクセスソフトウェア（即ち、ウェブサービスのためのブラウザ）も、プラグイン技術、またはユーザがＱｓｉｄを登録したプロバイダ（即ち、ウェブサイト）に属することを検証するための他の技術を有する。このプラグインは、Ｑａｐｐとユーザのブラウザとの間で情報を安全に交換するために使用されることも可能である。これには、ＵＲＬ、セッション鍵または通信に署名しかつ／または通信を保護するための他の情報の検証が含まれる場合もある。ユーザが（スパムリンク、ＵＲＬのミスタイプ、他から）間違ったサイトへ行ってしまい、しかもプロバイダのウェブサイトにいるものと確信しているが、実は攻撃者が実行するサイトにいるという中間者攻撃の場合、ユーザにその間違いを警告する唯一の確実な方法は、ブラウザにおいて、Ｑサーバに関わるユーザの意向を検証することである。これは、ブラウザのプラグイン、またはデスクトップ上のスタンドアロンプログラムとして実行されることが可能である。

【0068】

異なる実施形態では、スマートフォンに格納されるユーザ認証情報のうちの幾つか、または全てが、プロバイダまたは潜在的に他のユーザとの通信に使用される秘密鍵および証書を含む暗号鍵ストアに格納される。ユーザ認証情報は、公開／秘密鍵ペア、パスワード、生体テンプレート、ワンタイムパスワード・シード、他を含む、ユーザを検証するための任意の情報またはトークンを含むことも可能である。

【0069】

鍵ストアの復号に当たって、ある実施形態は、６０１および６０６において、鍵ストアが失われてもブルートフォースが復号鍵を推測することを防止するために、かつＱサーバが鍵ストアへのアクセスを有することを防止するために、一意の分割鍵システムを用いる。図６を参照されたい。本発明は、下記の分割鍵システム、即ち、ユーザが入力する秘密データが複数の部分に分割され、２つの部分、ＡおよびＢを用いることが一実施形態である、分割鍵システムを含む。秘密データは、パスワード、ｐｉｎ、生体テンプレート、ユーザが描く画像、他を含む任意タイプのユーザデータであることが可能である。パスワードの部分Ａは、６０５において、復号鍵の部分Ａを生成するために局所的に使用される。様々な実施形態において、部分Ａは、ローカルシステム上で他のブロックを復号するために使用される場合もあれば、スマートカードの一意の製造番号のようなシステム情報と組み合わされる場合もあり、あるいは部分Ａをより長くするために、または復号するにはより分かりにくいものにするためにハッシュされる、または別段で修正される場合もある。部分Ａは絶対に電話から離れないことから、ユーザは、復号鍵に対する制御を保全する。秘密データの部分Ｂは、６０２において、暗号化されかつ認証されたチャネル上で（ユーザの通信鍵を用いて）Ｑサーバへ送信され、Ｑサーバは、６０４において、復号鍵の部分Ｂを送り返す。異なる実施形態において、鍵の部分Ｂは、データベースから検索され、秘密データの部分Ｂからハッシュとして生成され、または他のユーザ／ハードウェア固有情報と結合される場合もある。Ｑサーバは、部分Ｂの使用を監視できることから、６０３において、設定回数の試行失敗後にアカウントをロックし、ユーザに警告し、または不審な挙動に別段の応答をすることが可能である。

【0070】

ある実施形態では、ユーザ認証情報は、公開／秘密鍵および証書システム（ＰＫＩ）に基づく。このシステムの利点は、ユーザの認証情報である秘密鍵が絶対にスマートフォンを離れず、よって登録において証書の署名かつシステムへの検証を行えることにある。これらの証書は、個々に配りかつ制御することができ、ユーザは、プロバイダ毎に別々の認証情報で認証を行うことができる。さらに、他の認証情報ペア、例えばユーザ対ユーザの認証情報も、別々に生成されかつ保持されることが可能である。ある実施形態は、異なる３タイプの証書を使用するが、これらは、異なる３つの署名権限保有機関、即ち１）プロバイダの証書権限保有機関（ＣＡ）−プロバイダとＱサーバとの間の通信に用いるためのプロバイダ証書に署名する、２）ユーザのＣＡ−プロバイダに関連するその認証情報の検証に用いるためにユーザにより生成されるユーザ通信証書およびユーザ対プロバイダ証書に署名する、および３）ＱサーバのＣＡ−ユーザおよびプロバイダに対し、ユーザおよびプロバイダが正規のＱサーバと対話していることを検証するために、Ｑサーバ上で使用される証書に署名する、によって署名される。第２の実施形態では、ユーザは、単一のユーザ対全プロバイダ証書を有する場合もあり、かつ署名権限保有機関は、単一のＣＡまたは階層的ＣＡ構成に統合される可能性もある。

【0071】

本発明において、ユーザは、生体データを含む複数形式の認証データを用いることが可能である。認証システムにおける現行の最新技術は、何らかの形式の知識、生体およびトークンファクタを組み合わせるが、これらのファクタのうちの１つのみを設定することは、本発明なしでは複雑になる。スマートフォンおよび他のタイプのモバイルデバイスは、複数のセンサおよび他のデータ入力方法を有することから、下記のような全ての従来的認証タイプからデータを収集することが可能である。
・人を示すもの：正面のカメラで撮った顔認識、後向きカメラで撮った手認識、マイクで撮った話者認識、他のような生体的オプションを含む。電話によっては、指紋リーダのような特殊化された入力を内蔵したものがあり、かつスマートフォンには、追加のケイパビリティを許容するデバイスを取り付け可能であることが多い。
・知っているもの：パスワード、安全質問、話者認識の間に話される語句、画面に描かれる画像、電話の震動パターン、他を含む。
・所有するもの：最も自明なものは、電話またはモバイルデバイス自体である。しかしながら、このカテゴリには、例えば電話に関連づけられるトークン、取り付けられるｕｓｂデバイス、近距離無線オプションを介して発見されるトークン、カードリーダで読み取られるカードデータ、デバイスのＳＩＭカードからのデータ、安全なコプロセッサまたはデータロックボックス内のデバイス自体に格納される安全なデータ、他も包含されることが可能である。

【0072】

本発明は、プロバイダおよびユーザが、必要とされる場合に個別ベースで柔軟性および追加的安全性を与える１つまたは複数タイプの認証を用いることができるようにする。Ｑサーバは、様々な生体的またはトークンオプションの登録、生体テンプレート等の安全なデータの格納、異なる形式の認証を標的とする詐欺行為検出、およびログイン認証と登録されたデータとの比較を含む、追加的ファクタの安全管理を実行する。Ｑａｐｐは、認証データの収集を管理し、かつＱサーバへの提出前に、データに関して一連の前処理ステップを実行してもよい。前処理の目的は、主として、画像がぼけている、受信されない、他である場合にユーザへ迅速にフィードバックを与える提出の質を保証することにあるが、前処理は、送信されるデータサイズを制限しかつ提出データを潜在的に整理する（ヘッドを画像中心に合わせる、他）ためにも使用される。また、Ｑａｐｐは、Ｑサーバ上で実行される主たる詐欺行為検出に加えて実行される一連の詐欺行為検出機能も有する場合がある。Ｑサーバは、追加的な認証ファクタを保持するものの、鍵ストア４０６へのアクセスを持たないことから、ユーザであると偽ることはできない。この信用分離は、ユーザによる自身の認証に対する制御を危うくすることなく、集中化された制御および管理を可能にする。このアーキテクチャの他の利点は、プロバイダが一切変更を行う必要なしに、新たな形式の認証をユーザへ展開できることにある。

【0073】

本発明のアーキテクチャは、プロバイダが新規ユーザの追加を希望する際の簡易的な設定も可能にする。プロバイダは、認証データを事前に設定する必要がなく、例えば、一時的なパスワードを割り当てる必要がない。これにより、プロバイダに、サポートを希望する認証ポリシのタイプにおいてより大きい柔軟性を持たせることができる。例えば、プロバイダは、２ファクタを要求すべく認証のアップグレードを希望すれば、単にサーバ側のグローバルなポリシを変更し、かつユーザは、２ファクタによる認証の要求され始める。プロバイダは、全て認証サーバにより処理される新規ファクタの登録データを収集しようとして各ユーザへと戻る必要がない。単純化された識別および登録と組み合わされた場合、プロバイダは、そのシステム上に如何なるアカウントも事前設定する必要がない。

【0074】

ある実施形態では、従来のユーザを、ネットワークに渡る様々なサービスに対して認証される必要があるバッチシステムのような自動プロセスで置換することが可能であると思われる。システムは動作するものの、生体認証または知識ベースの認証ファクタと同等の所定のオプション構成部品が可能とはならない。

【0075】

また、本発明は、プロバイダとユーザとの間の、認証サーバおよびユーザ・モバイル・デバイス上のＱａｐｐを通じた安全なチャネルを介する安全な形式の通信も可能にする。この安全な通信チャネルは、プロバイダが極めて重要な通知を、「購入が完了しました」または「送金が完了しました」といった情報を偽装または修正され得ない方式で送信できるようにする、信頼された方式で送信することを可能にする。データの暗号鍵は、関係者間で先に交換している公開証書または先に共有しているセッション鍵を含む任意の規格に基づくことも可能である。このタイプの通信は、ネットワーク上の任意の２ユーザ間の事前に確立されたユーザ対ユーザ認証情報を用いる安全な通信も可能にすると思われる。

【0076】

「購入が完了しました」のような一方向要求は、ユーザからの応答を要求しないが、「Ｘの購入希望を確定しますか」のような双方向要求は、プロバイダがユーザからの応答を待てるようにする。したがって、ユーザは、取引を、その最終承認より前に安全な通信チャネルを介して検証することができる。検査プロセスは、ユーザがその時点でプロバイダにログインしていない場合でも発生する可能性があり、かつユーザが取引の「承認」を、追加的な認証データの提供と同時的に行うようにすることも可能である。
ログインプロセスの詳細な実施の例−図３参照

【0077】

・ユーザは、３０１において、デスクトップまたはモバイルブラウザを介してウェブサイトへ進む。
・ウェブサイト１０３（プロバイダ）は、チャネル１０４上で認証サーバ１００からセッションＩＤ（Ｑｓｉｄ）３００を入手し、かつ局所的にセッション固有ランダム数（Ｑ活性）３００を生成する。プロバイダは、パフォーマンスを理由として、ＱサーバからＱｓｉｄセットを事前キャッシュすることも可能性である。Ｑ活性は、認証サーバ上で生成されることも可能である（安全リスクは幾分か高まる）。Ｑ活性コードがプロバイダにより生成されれば、プロバイダは、Ｑｓｉｄの付与に伴ってＱ活性コードを認証サーバへ送信する。
・プロバイダは、表示されるＱコードに組み込まれたＱｓｉｄをユーザに示す。Ｑコードは、サーバにより生成されかつブラウザに画像として示されるか送信され、かつブラウザ側のジャバスクリプトにより生成される画像として表示される。Ｑｓｉｄは、第三者がＱｓｉｄを盗用していれば、競合状態を防止するために、ＳＳＬまたは他のトランスポート暗号化を用いて暗号化されるべきである。少なくとも幾つかの実施態様では、ユーザは、その一意のユーザＩＤをプロバイダへブラウザを介して入力あるいは提供し、ログインプロセスを開始する。プロバイダは、次に、一意のユーザＩＤ、ＱｓｉｄおよびＱ活性を暗号化チャネル上で認証サーバへ送信する。
・バックグラウンドにおいて、ユーザのブラウザは、暗号化チャネル１０５上で認証サーバをＱｓｉｄで絶えずポーリングし、認証が完了した時点を識別する。
・ユーザは、３０２において、Ｑコードをその認証アプリケーション（Ｑａｐｐ）を用いてスキャンする。ユーザは（Ｑａｐｐポリシに基づいて）、認証アプリケーションの開始前にその秘密データを入力する必要がある場合もあれば、ない場合もある。Ｑａｐｐは、Ｑコードを復号し、それが適正なコードであることを確信し、次にＱｓｉｄを抽出する。
・Ｑａｐｐは、クライアント−認証ＳＳＬ上で認証サーバへ接続し（よってＱサーバは、Ｑａｐｐユーザを検査することができる）、認証サーバの証書を検査し、次に、ステップ３０３においてＱｓｉｄを送信する。
・認証サーバは、Ｑａｐｐへセッションデータ３０４を送り返す（あるいは、直前に記載した２ステップが実行されなければ、認証サーバは、一意のユーザＩＤに基づいてユーザのモバイルデバイスへ接続し、Ｑａｐｐは、双方向の認証ＳＳＬ接続部上でセッションデータによりログイン要求を送信する）。セッションデータには、下記が含まれる。
・Ｑ活性数字、およびセッションのタイプ（ログインまたは登録）。
・ユーザが接続しようとしているプロバイダの識別名、ロゴおよび読取り可能な名前。任意選択の実施形態は、プロバイダの鍵で署名されたプロバイダの証書およびＱ活性を送信し、プロバイダの検証を可能にするが、より高いＣＰＵオーバーヘッドを要する。
・要求されるプロバイダの認証ポリシ（なし、パスワード、生体データ、他）。
・Ｑａｐｐは、プロバイダの認証ポリシと組み合わせてユーザの許可４０８および４０５をチェックし（常時的通知を希望するか、常時そのパスワードをタイピングするか、他）、次に、ユーザに適切な情報３０５について尋ねる。例えば、ユーザは、３ファクタ認証用にパスワードおよび生体データを入力する必要があるものとする。
・ユーザは、その秘密データをＱａｐｐへ入力する。
・Ｑａｐｐは、秘密データのネットワーク成分を認証サーバへ、暗号化されかつ検証されたチャネル上で送信する。
・認証サーバは、秘密データのネットワーク成分を検証し、ブルートフォースによる推測および他のタイプの攻撃を防止するために詐欺行為検出を実行し、次に、復号鍵の半分Ｂを送り返してユーザ電話側の鍵ストアをアンロックする。
・Ｑａｐｐは、分割鍵の半分Ｂを受信し、これを秘密データの半分Ａおよび安全に関連のない電話からの潜在的に他の情報（例えば、デバイスの一意のＩＤ、他）と組み合わせ、かつ組み合わされた鍵を用いてアプリケーション内の安全な鍵ストアをアンロックする。鍵ストアは、ユーザが通信するプロバイダ毎の秘密鍵を収容する。
・Ｑａｐｐは、次に、要求される任意の追加的な生体データ（例えば、手の画像）についてユーザにプロンプトする。
・Ｑａｐｐは、次に、３０６において、下記を含む認証のフルパケットをＱサーバへ送り返す。
・Ｑｓｉｄ−セッションＩＤ。
・ユーザｉｄ、Ｑｉｄは、通信証書に内蔵されていて、Ｑサーバによりクライアント認証ＳＳＬ接続に基づいて入手可能である。異なる実施形態では、Ｑｉｄは、ユーザ／プロバイダペア毎に一意であることが可能性であり、Ｑａｐｐのインストール毎に一意であることも可能である。
・特有のプロバイダに関する、ユーザ証書により署名されたＱｓｉｄおよびＱ活性。
・生の生体データ（例えば、顔または手のｊｐｇ画像）。
・認証サーバは、次に、下記のチェックを含むユーザパッケージの検証を行う。
・ユーザの通信証書は、有効である。証書が取り消されておらず（ユーザが電話を紛失した場合に発生し得る）、通用し（証書は期限切れとなり、リフレッシュする必要がある）かつ実際に存在する（新規ユーザまたは攻撃者が有効な証書を有することはない）点を確認する。
・Ｑｓｉｄは、有効である。これには、攻撃（攻撃者によるＱｓｉｄ再使用の試行等）またはブルートフォース・スキャン（攻撃者によるランダムＱｓｉｄの送信等）のチェックが含まれてもよく、かつこれが期限切れになっていない、サイトへのマッピングは有効である、他を確認するチェックも含まれる。
・ユーザは、プロバイダがＱｓｉｄでマッピングされたアカウントを有する。マッピングは、ＱｉｄからＱｓｉｄに登録されたプロバイダまで存在する。ユーザがアカウントを保有していなければ、認証サーバは、「このサイトには登録されていません」というメッセージをユーザへ送り返す。このタイプのチェックは、フィッシング攻撃を無効にするために使用される方法の１つである。
・生体データは、先にユーザによって登録されたデータに照らして検査される。生体データでは、様々な詐欺行為検出ステップが実行される場合もあれば、実行されない場合もある。
・署名入りのＱｓｉｄおよびＱ活性は、有効であり、かつ正しい証書により署名されている。
・認証サーバ（ユーザのオリジナルブラウザによってポーリングされている）は、ユーザのブラウザへ有効なログイン信号を送り返す。
・ブラウザは、プロバイダの受信された認証承認ロケーションへ接続する。
・プロバイダは、次に、認証サーバへ（暗号化されかつ検証されたチャネル上で）接続し、承認３０７の確定について尋ねる。認証サーバは、プロバイダへ下記のデータ、即ちＱｉｄ、署名入りのＱｓｉｄおよびＱ活性を含むユーザ証書、Ｑサーバへ送られた認証の有効性（例えば、ユーザはｐｉｎおよび顔で首尾良く認証されている）、を含むメッセージ「有効なログインを受信しました」を送り返す（この好適な方法は、具体的には、生体データまたは他の認証データをプロバイダへ送信しないことに留意されたい）。
・場合により、プロバイダは、次に、ローカルポリシに基づいて署名を承認または再検査することができ、かつ証書に関して、ログイン証書を登録証書に照らし合わせることを含む追加的な安全チェックを実行することができる。承認されると、ユーザは、ウェブサイトへログインされる。
登録プロセスの詳細な実施の例

【0078】

１）Ｑサーバに対するユーザ登録
ユーザは、Ｑａｐｐをそのスマートフォンにダウンロードする。Ｑａｐｐが最初に開始される際に、ユーザは、新しいアカウントを生成することができ、または下記のようにシステムに登録することができる。
１．ユーザは、名前、電話番号、ｅメール、他を含み得る様々な登録情報を入力する。
２．場合により、ユーザは、顔画像、音声プリント、パスワード、他のような生体登録データを入力する。
３．ユーザは、「提出」をクリックし、Ｑａｐｐは、ＱサーバへユーザＩＤ（Ｑｉｄ）要求を送信する。要求は、ユーザがまだ登録されていないことを検査し、かつ場合により帯域外検証を実行する（ユーザへｅメールを送信する等）ために、例えばｅメールアドレスである登録データの様々な部分を含んでもよい。
４．Ｑａｐｐは、Ｑサーバから一意のユーザｉｄ（Ｑｉｄ）およびＱサーバの公開証書の返送を受信する。Ｑａｐｐは、一意の公開／秘密鍵ペア、ユーザの通信証書（Ｑｉｄを含む）および証書署名要求を生成する。
５．Ｑａｐｐは、次に、Ｑサーバへ、証書署名要求、登録データおよび任意の生体データを含む登録データを送信する。
６．認証サービスが提出を承認するものと想定して、認証サービスは、ユーザの通信鍵の署名入り証書を送り返し、かつユーザデータをシステムに登録する。この情報は、次に、Ｑａｐｐ内に保存される。

【0079】

２ａ）プロバイダへのユーザ登録
ユーザが、プロバイダサービスへ接続し、かつ登録することを選択すると、ユーザに、ユーザが供給する必要のある任意の情報を含むプロバイダの既存の登録ページ、およびＱコードが提示される。
・登録プロセスの第１の部分は、ログインプロセスと同じである。これは、Ｑａｐｐがセッションデータの返送を受信し、かつそのセッションデータが登録セッションであるという識別子を含むと分岐する。
・Ｑａｐｐは、ユーザに、「プロバイダＸが登録を要求しています」という登録を承認するためのメッセージを示す。ユーザが承認すれば、Ｑａｐｐは、ユーザに、必要な任意の追加的認証（例えば、顔認識、他）を入力するように要求する。
・Ｑａｐｐは、ユーザとプロバイダとの間で用いるための公開／秘密鍵ペアを生成する。
・Ｑａｐｐは、証書署名要求を送る。
・認証サーバは、適宜、パラメータおよび生体データを検証し、かつ証書署名要求に署名する。
・認証サーバは、次に、Ｑａｐｐへ、プロバイダに関する公開証書（オプション）およびユーザに関する署名入り証書を送り返す。認証サーバは、次に、証書を（ユーザ、プロバイダ）ペアに関連づける。
・オリジナルのブラウザページ上のＱコード画像または他の視覚的表示は、奏効した登録を示して更新される。これでユーザは、その登録をプロバイダへ提出することができる。
・プロバイダは、セッションＩＤに基づいてセッションを検証し、首尾良く検証されれば、ユーザの公開証書およびユーザＩＤ（Ｑｉｄ）を保存する。セッションＩＤが有効でなければ、これは単に認証サーバを用いることなくプロバイダサイト上で登録されたユーザである可能性もあり、よってこのセッションＩＤが使用されたことはない。

【0080】

２ｂ）第２の登録実施の形態−識別の追加
プロバイダサイトにおけるユーザ登録をユーザ側でより容易にするための一方法は、ユーザが再入力しなければならない情報量を簡約することである。図８を参照されたい。本発明は、８０６において、ユーザが１つまたは複数の「識別」、例えば業務上および個人的な識別、を生成できるようにする。各識別は、識別に関連づけられるデータセット、例えば名前、ｅメールアドレス、郵便宛先、他を有する。よって、ユーザは、登録の間、ある識別からの情報を用いてプロバイダの登録情報に記入するオプションを有する。この単純化された登録オプションは、ユーザがログインＱコードをスキャンし、またはその一意のユーザＩＤをプロバイダの書式に入力し、かつユーザにアカウントがないことをＱサーバが認識した場合に、もたらされてもよい。ある実施形態では、識別情報は、Ｑサーバ上に格納されることが可能であり、かつ第２の実施形態では、識別が専らモバイル・ユーザ・デバイス上に格納されることが可能である。さらに、識別情報の管理は、情報の記憶装置に対して局所的に実行されることが可能であり、または、サーバ、認証サーバ、ユーザのデスクトップコンピュータ、他を含む他のサーバまたはデバイス上でリモート合意によって実行されることも可能である。
・登録プロセスの第１の部分は、ログインプロセスと同じである。これは、Ｑａｐｐがセッションデータの返送を受信し、かつそのセッションデータが登録セッションであるという識別子を含むと分岐する。
・Ｑａｐｐは、ユーザに、「プロバイダＸへのログインを保有していません。登録を希望しますか？」という登録を承認するためのメッセージを示す。プロバイダにより要求される登録情報のタイプ（名前、誕生日、他）は、特性セットとしてＱサーバによりＱａｐｐへ送信される。Ｑａｐｐは、次に、「プロバイダＸを登録するために、次の情報、即ち名前、ｅメール、他を希望します」といったメッセージをユーザに示す。ユーザは、次に、その識別セットから、プロバイダに使用したいものを選択することができ、必要なフィールドが、予め設定された識別データを用いて記入される。場合により、ユーザには、データを提出前に編集する選択肢が与えられてもよい。ユーザは、提出されるデータに対する完全な制御を保全し、しかも、クリックしてプロセスを登録することができる−潜在的に、如何なる新規データもタイピングする必要はない。
・次に、登録プロセスは、正常に進行する。

【0081】

３）Ｑサーバへのプロバイダ登録
これは、ユーザ登録より遙かに低頻度での発生が予期され、よって、署名鍵およびプロセスは、よりマニュアルであることが可能性である。これは、本質的に上述のステップと同じステップを辿るが、プロバイダが（提供されるスクリプトを用いて）その鍵を生成し、かつ返されるデータをそのプロバイダ設定の一部として保存する点が異なる。プロバイダは、認証ＣＡおよびユーザＣＡ証書の返送を受信する。
紛失電話プロセスの詳細な実施の例

【0082】

図７を参照されたい。ユーザ証書は、提案するシステムを用いてログイン前に検証されていることから、７０５においてユーザが電話の紛失を報告すると、全ての証書は、即座に無効化されることが可能である。これは、詐欺行為が検出された場合、またはユーザが、自分の電話が危険に曝されているかもしれないと考える場合にも使用されることが可能である。ユーザ支援を促進するためには、鍵が無効にされるだけでなく、Ｑサーバのサービスを用いてその旧プロバイダにより再登録を単純化しかつ管理することが可能である（実際に、Ｑサーバを信頼していれば、ユーザを再検証するためにプロバイダが何かする必要はない）。異なる実施形態では、認証情報を無効にする方法は、鍵の取消し、削除またはデータの無効化を含む。

【0083】

ユーザは、その電話の紛失を、Ｑサーバのウェブサイトを呼び出す、またはこれにログインすることによって報告する。ユーザは、秘密データの半分Ｂを用いることができ、または、新しい電話を有していれば、生体オプションを用いてログインすることができる。
・認証サービスが無効になる（または、全てのユーザ鍵を無効とマーキングする）。
・ユーザが無効化された鍵を用いてログインしようとすれば、ログインは拒絶される。
再検証

【0084】

・ユーザは、そのアカウントの再セットアップへ進むと、Ｑａｐｐ上で「既存のアカウントへログイン」を選択し、かつｅメールアドレス、生体データおよび秘密データのネットワーク部分を含む、ログインのための詳細を記入する。適切な情報が、認証サーバ上へ送信され、生体情報および他のログイン情報が正しいことを確かめるために検証される。
・認証が有効であれば、認証サーバは、ユーザの旧ユーザＩＤ（Ｑｉｄ）を送り返す。正常な登録は、Ｑａｐｐによる鍵ペア、証書、他の生成を続ける。
・次に、ユーザが、以前その認証情報を有していたサイトへログインしようとする場合、ユーザは、通常のログインプロセスに従うが、認証サーバは、そのユーザに関する現行の認証情報が発見されず、ユーザが既に認証情報を取り消していることを確認し、かつ新しい認証情報を生成するようにＱａｐｐに接触する点が異なる。認証情報が生成されると、ユーザのオリジナルブラウザが接触され、ユーザが再登録を行っていることが告げられる。ブラウザの戻りコードを用いてブラウザへ通知することにより、ユーザに対するリダイレクトを自動的に発生させることができる。ユーザに完全に透明な再登録オプションを与える能力は、認証フレームワーク、およびブラウザとプロバイダとの間の専用通信によって有効化される。これは、プロバイダにユーザを再登録ページへリダイレクトする機会を与え、再登録ページにおいて、プロバイダはユーザを再検査するために追加質問（例えば、好きなペットの名前、他）をすることができる。プロバイダは、このステップをスキップして、単に新しい認証情報を受け入れることもできる。認証情報が受け入れられると、ユーザは、ログインする。認証サーバも、この新しい認証情報を「受け入れる」ように、プロバイダにより接触される。
ポリシ設定の詳細な実施の例

【0085】

プロバイダおよびユーザが選択できるポリシのオプションおよび設定は、幾つか存在する。その各々が、ログインまたはログインプロセスを検証するために行われるステップに僅かに影響する。例えば、プロバイダは、ユーザの鍵は暗号鍵ストアに格納されるべきであり、または、ユーザのログインに際して２ファクタを用いる必要がある点を明示することができる。ユーザは、鍵が暗号化されて格納されるべきかどうかを指定することもできる。Ｑａｐｐは、ユーザおよびプロバイダ仕様の双方を満たす最小限の設定を選択する。これは、ユーザ関連オプションの各々が、安全性に対する「アップグレード」として作用することを意味する。ポリシ管理は、ＱａｐｐまたはＱサーバを用いてユーザポリシを変更できる例について配分することができる。一方で、Ｑサーバまたはプロバイダは、プロバイダポリシを変更するためにアクセスを有する場合もある。ある実施形態では、プロバイダのみが、プロバイダポリシを更新することができる。ある実施形態では、Ｑａｐｐのみが、ユーザポリシを変更することができる。他の実施形態では、ユーザは、Ｑサーバ上でウェブサイトのようなインタフェースからそのポリシを変更することも可能性である。本発明では、ユーザは、多数の個別レコードの保全を担当する管理者またはスーパーユーザを有するのではなく、その個々のポリシ情報およびレコードに対する制御を与えられる。
ユーザポリシ

【0086】

・全ての鍵を暗号化する。この場合、システム上でＱａｐｐが開始される度に、ユーザはその秘密データを入力する必要がある。
・設定された期間に亘って、認証が有効のままである（即ち、メモリに格納されている）ことを可能にする。これにより、ユーザは、その秘密データを入力する、またはその画像を撮る回数を、限定することができるようになる。可能な設定として、画面を保存する度、またはおそらくは１時間おき、が含まれる。固有の生体データまたは特殊トークンは、有効であり続ける固有の最大時間枠を有してもよい。
・ユーザは、特定鍵８０１のポリシを（Ｑａｐｐアプリケーション上、またはＱサーバウェブサイト上の何れかで）直接管理することができる。これには、特定のサイトを、認証を要求するように「アップグレード」することが含まれることになろう。例えば、プロバイダがその時点で２ファクタ（電話および秘密データ）を要求していれば、ユーザは、生体ファクタを追加するように要件をアップグレードすることができ、そうなれば、このユーザに関しては、３ファクタ認証の提供なしに特定のプロバイダにおけるそのアカウントがアクセスされることはない。
・他の実施形態では、ユーザは、プロバイダ証書およびＱ活性署名ブロックを受信し、かつＱａｐｐにおいてこの署名を検証することを選択することも可能性である。
プロバイダポリシ

【0087】

本発明は、プロバイダがＱサーバを信用してプロバイダチェックの大部分をスキップすることを可能にする設定オプションを含み、またはプロバイダがユーザからのあらゆるもの（追加の認証ファクタを除く）を再検証することを可能にする。下記は、プロバイダ上で使用可能な主要設定のうちの幾つかである。
・ユーザ認証情報を再検証する。これには、ユーザ認証情報が登録の間に承認されたものと同じであること、証書が期限切れでないこと、認証の間に返された署名入りデータが、先に同意された証書を用いて署名されていること、の検証が含まれる。
・Ｑｓｉｄの取得時点で、Ｑサーバに作成させるのではなく、プロバイダ固有のＱ活性を生成する。（これにより、Ｑサーバによるリプレイ攻撃の実行が防止される。）
・再登録をオンまたはオフにする。これによりプロバイダは、ユーザに、再検査について、鍵を紛失して再登録される必要があるのか、と質問することができる。オフにされれば、プロバイダは、Ｑサーバが認証検査を実行しているものと信用する。
・ユーザのブラウザに、ユーザのブラウザがプロバイダに最初に接続する際に与えられるクッキーを用いて、Ｑコードを見たブラウザがログインしたブラウザと同じであることを検証する。

【0088】

４）プロバイダに対する書類による既存ユーザ登録
ＱＲコードを介してユーザのモバイルデバイスへ送信されるＱｓｉｄを用いることの１つの優位点は、既存のプロバイダアカウントの最初の登録が、メーラまたは書類による開始によって実行され得ることにある。これの優位点は、登録プロセスがプロバイダの通知（口座明細書または公共料金勘定書等）を介して、または初期セットアップの間（銀行口座開設または住宅融資を受けるために出かけるとき等）に開始される可能性もあることにある。図１０を参照されたい。この登録プロセスの下では、下記のステップが発生する：
・プロバイダが、アカウントをセットアップしている場合、または既存ユーザの登録を希望する場合、プロバイダは、用紙１０００上に、ユーザとプロバイダアカウントとが認証サーバを介して相互に関連づけられることを可能にする一意のＱコード１００８をプリントする。Ｑコードは、ヘッダブロック（後述する）と、１００１においてサーバにより同意された登録Ｉｄ（ＱＥｉｄ）とを含み、ＱＥｉｄは、登録コードが有効である限り全ユーザに渡って一意であることが保証され、かつ登録セッションの簡易識別子として作用する。
・１００２において、ユーザは、認証アプリケーション（Ｑａｐｐ）１０１を用いてＱコードをスキャンする。ユーザは、（Ｑａｐｐポリシに基づいて）認証アプリケーションを開始する前にその秘密データを入力する必要がある場合もあれば、ない場合もある。Ｑａｐｐは、Ｑコードを復号し、これが適正なコードであることを確認し、次に、Ｑｓｉｄを抽出する。
・１００３において、Ｑａｐｐは、（ＱサーバがＱａｐｐユーザを検査できるように）クライアント−認証ＳＳＬ上で認証サーバへ接続し、認証サーバの証書を検査し、次に、Ｑｅｉｄを送信する。
・認証サーバは、Ｑａｐｐへ、下記を含むセッションデータ１００４を送り返す。
・Ｑ活性数字およびセッションのタイプ（ログインまたは登録）。
・ユーザが接続しようとしているプロバイダの識別名、ロゴおよび読取り可能な名前。任意選択の実施形態は、プロバイダの鍵で署名されたプロバイダの証書およびＱ活性を送信し、プロバイダの検証を可能にするが、より高いＣＰＵオーバーヘッドを要する。
・要求されるプロバイダの認証ポリシ（なし、パスワード、生体データ、他）。
・Ｑａｐｐは、ユーザに、「プロバイダＸが登録を要求しています」という登録を承認するためのメッセージを示す。ユーザが承認すれば、Ｑａｐｐは、ユーザに、必要な任意の追加的認証１００５（例えば、顔認識、他）を入力するように要求する。
・Ｑａｐｐは、ユーザとプロバイダとの間で用いるための公開／秘密鍵ペアを生成する。
・Ｑａｐｐは、証書署名要求および他の任意選択の認証情報１００６を送る。
・認証サーバは、適宜、パラメータおよび生体データを検証し、かつ証書署名要求に署名する。
・認証サーバは、次に、Ｑａｐｐへ、プロバイダに関する公開証書（オプション）およびユーザに関する署名入り証書を送り返す。認証サーバは、次に、証書を（ユーザ、プロバイダ）ペアに関連づける。
・次に、認証サーバは、１００７において、新たに生成されたユーザ−プロバイダ証書を含む登録情報をプロバイダへ送る。プロバイダは、プロバイダが絶えずＱサーバをポーリングすること、両者が絶えず接続されていること、またはＱサーバがプロバイダへ直に接続する能力を有することを含み、任意数のアーキテクチャを介して接触されてもよい。プロバイダは、登録ＩＤに基づいてセッションを検証し、首尾良く検証されれば、ユーザの公開証書およびユーザアカウントＩＤ（Ｑｉｄ）を保存する。

【0089】

ユーザは、次に、追加の検証情報をタイピングすることなく認証システムへ登録され、これで、簡易なマルチファクタ認証でログインすることができる。第２の実施形態では、プロバイダは、再登録プロセスと同様に、ここで他の検証層を提供することによって、ユーザが初回使用で追加情報を入力するように要求してもよい。
通知プロセスの詳細な実施の例

【0090】

１）プロバイダは、ユーザへメッセージを送る。
ユーザ−プロバイダの関係性が（登録プロセスを介して）設定されると、プロバイダは、固有のユーザアカウントに関連づけられる一意のユーザアカウントＩＤを有する。図１１を参照されたい。プロバイダにおいて、検証されるべき、またはユーザへメッセージ送信されるべきイベントが発生すれば、下記のプロセスが発生する：
・プロバイダは、１１００において、Ｑサーバへ、プロバイダに既に格納されかつプロバイダ証書、メッセージで署名されたユーザの証書で暗号化されることが可能なユーザのアカウントＩＤ（Ｑｉｄ）、トランザクションＩＤおよびメッセージを送信する。要求は、ユーザがトランザクションを承認する必要があるかどうか、および承認のために何らかの認証が要求されるかどうかを明示するヘッダも含む。トランザクションＩＤは、配信または承認を検査すべく、後に特定のトランザクションを識別するために使用される。第２の実施形態では、メッセージに関してユーザを正しく識別するために、Ｑｉｄの代わりに、既にログインしているユーザのＱｓｉｄが使用されることが可能性である。
・１１０１において、Ｑサーバは、ユーザ・モバイル・デバイスのＱａｐｐへの接続を開始する。接続開始は、プッシュ機構、オープン・ネットワーク・ポート上で発生することも可能性であり、またはＱａｐｐは、モバイルデバイスのアーキテクチャおよび利用可能なサービスに依存して、定期的にＱサーバをポーリングする、またはＱサーバへ接続されたままになることも可能である。
・Ｑサーバは、Ｑａｐｐへ、トランザクションＩＤ、メッセージブロックおよびポリシ要件を含むメッセージ要求を送る。Ｑａｐｐは、次に、１１０２において、メッセージを復号し、メッセージをユーザに示し、要求されれば、検証のために承認および追加的な認証情報を入手する。
・Ｑａｐｐは、次に、１１０３において、応答を生成してこれをＱサーバへ送り返し、Ｑサーバは、１１０４において、これをプロバイダへ転送して返す。応答には、ユーザの承認回答、追加的な認証情報およびメッセージが示されたことの検査が含まれてもよい。ある実施形態では、プロバイダは、１つまたは複数のメッセージに応答して、Ｑサーバを絶えずポーリングしてもよい。第２の実施形態では、ユーザのブラウザは、ユーザが検査を要求したトランザクションを開始した後にＱサーバをポーリングし、完了すると、ブラウザは、プロバイダに通知のステータスをチェックするように告げる。第３の実施形態では、Ｑサーバは、プロバイダへ直に接続する。

【0091】

これと同じプロセスは、Ｑサーバ上にアカウントを有していて既に証書を交換している２ユーザ間でメッセージを共有するために使用されることも可能である。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【国際調査報告】