(57)【特許請求の範囲】
【請求項１】
鍵管理を提供するセキュリティサーバを操作する方法であって、
ユーザに関連付けられるネットワーク装置から通信チャンネルを介して、前記ネットワーク装置で特定ユーザのためのユーザインタフェースウィンドウのアクティベーションを求める要求を、受け取るステップと、
音声又はテキストメッセージを介してユーザの電話機に送られるべきアクティベーションＰＩＮを帯域外認証システムに伝送するステップと、
前記ネットワーク装置から前記通信チャンネルを介して、以前に伝送されたＰＩＮを受け取るステップと、
受け取ったＰＩＮに基づいて前記ユーザを認証するステップと、
前記ユーザインタフェースウィンドウ及び前記セキュリティサーバの間のセキュアな独立した暗号化された通信チャンネルを、前記ユーザを認証した後に前記通信チャンネルの上に、確立するステップと、及び
（ａ）公開鍵暗号ベース操作及び（ｂ）対称鍵暗号ベース操作の少なくとも１つに対する鍵資料を（ｉ）生成して前記セキュアな独立した暗号化された通信チャンネルを介して前記ユーザインタフェースウィンドウに送信するステップ、及び、（ａ）公開鍵暗号ベース操作及び（ｂ）対称鍵暗号ベース操作の少なくとも１つに対する鍵資料を（ｉｉ）前記ユーザインタフェースウィンドウから前記セキュアな独立した暗号化された通信チャンネルを介して受け取るステップ、のうち少なくとも１つのステップと、
を含む方法。
【請求項２】
公開鍵暗号のための前記鍵使用が生成され伝送されるが、更に、
前記セキュアな独立した暗号化された通信チャンネルを介して、前記ユーザに関連付けかつユーザインタフェースウィンドウで以前に生成された私有鍵／公開鍵のペアであるＤｕ／Ｐｕの公開鍵Ｐｕを受け取るステップと、
前記セキュアな独立した暗号化された通信チャンネルを介して、前記セキュリティサーバ又は外部の認証機関によって署名され、かつ、前記ユーザを前記受け取った公開鍵Ｐｕと関連付けさせる証明書及びその証明書の記憶のための命令、を前記ユーザインタフェースウィンドウに伝送するステップと、を更に含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記セキュリティサーバは中間又はルート認証機関として行動するが、ここで、
ローカルに記憶された認証機関鍵資料を使用して証明書を生成しかつ署名するステップ、を更に含むことを特徴とする請求項２に記載の方法。
【請求項４】
前記証明書が外部の認証機関によって署名されるが、ここで、
未署名の証明書を前記外部の認証機関に伝送するステップと、及び
前記ユーザインタフェースウィンドウへ署名済みの証明書を伝送する前に、前記認証機関から前記署名済みの証明書を受け取るステップと、を含むことを特徴とする請求項２に記載の方法。
【請求項５】
前記伝送された記憶の命令は、（ｉ）メモリ内に、（ｉｉ）前記ネットワーク装置のオペレーティングシステムの鍵ストア内に、又は、（ｉｉｉ）その両方内に、ユーザ私有鍵Ｄｕ及び署名済み証明書の記憶を要求することを特徴とする請求項２に記載の方法。
【請求項６】
前記伝送された記憶の命令は、明示的又は黙示的に、命令を提供しないことにより、記憶の決定を前記ユーザインタフェースウィンドウに委ねることを特徴とする請求項５に記載の方法。
【請求項７】
対称鍵暗号操作のための前記鍵資料は、前記セキュリティサーバによって生成され伝送されるが、ここで、
前記ユーザインタフェースウィンドウ又は第三者ネットワークサイトから、前記ユーザ又はファイルに関係付けられた固有の識別情報を含む認証された要求を、受け取るステップと、
一方向性関数を使用して、固有の対称鍵Ｋを生成するステップと、ここで、この鍵Ｋの値は、前記受け取った固有の識別情報及び前記セキュリティサーバにのみ知られる秘密から導かれ、及び
リクエスタに生成された前記対称鍵Ｋを伝送するステップと、を更に含むことを特徴とする請求項１に記載の方法。
【請求項８】
前記セキュリティサーバは、トランザクション上のデジタル署名を得るために公開鍵暗号操作を実行するが、ここで、
第三者ネットワークサイトから、前記トランザクション及び前記トランザクションのデジタル署名のための要求を受け取るステップと、
前記セキュアな独立した暗号化された通信チャンネルを介して前記ユーザインタフェースウィンドウへ、前記トランザクション及びデジタル署名を求める要求を伝送するステップと、
前記ユーザインタフェースウィンドウから前記セキュアな独立した暗号化された通信チャンネルを介して、前記ユーザと関連付けられた私有鍵／公開鍵のペアであるＤｕ／Ｐｕの私有鍵Ｄｕでデジタル署名された伝送されたトランザクションのハッシュを受け取るステップと、
第三者ネットワークサイトへ、受け取られた前記トランザクションのデジタル署名済みハッシュ及び証明書を、前記ハッシュを再計算して前記伝送された証明書に含まれる前記ユーザの公開鍵Ｐｕを前記伝送されデジタル署名されたハッシュに、伝送された証明書に含まれるユーザの公開鍵Ｐｕを適用することにより復元されるハッシュと、それとを比較することにより、第三者ネットワークサイトがそのデジタル署名を確認するという明示的又は黙示的な命令と共に、伝送するステップと、を含むことを特徴とする請求項１に記載の方法。
【請求項９】
更に、前記ユーザインタフェースウィンドウへ、前記ユーザに表示するために、前記セキュアな独立した暗号化された通信チャンネルを介して、前記ネットワーク装置で表示されるブラウザウィンドウにおいて表示されるトランザクションを電子的に署名するための個人識別番号（ＰＩＮ）を伝送するステップとを更に含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ＰＩＮが、前記セキュリティサーバ及び第三者ネットワークによって共有されるが、前記ユーザには共有されない秘密に対応することを特徴とする請求項９に記載の方法。
【請求項１１】
前記伝送されたトランザクションが、前記ユーザインターフェースウィンドウにおいて前記ユーザにそのトランザクションを表示し、及び、そのトランザクションのデジタル署名に先立ち前記ユーザの承認を得るような、明示的又は黙示的な命令を含むことを特徴とする請求項８に記載の方法。
【請求項１２】
更に、前記公開鍵Ｐｕを、前記セキュアな独立した暗号化された通信チャンネルを介して前記ユーザインタフェースウィンドウから、受け取るステップと、
前記セキュリティサーバ又は外部の認証機関によって署名され、かつ、前記受け取った公開鍵Ｐｕに前記ユーザを関連付ける証明書、及び、その証明書及び前記ユーザの私有鍵Ｄｕの記憶のための命令、を前記セキュアな独立した暗号化された通信チャンネルを介して前記ユーザインタフェースウィンドウに伝送するステップと、を含み、
前記命令は、（ｉ）メモリ内に、（ｉｉ）前記ネットワーク装置のオペレーティングシステムの鍵ストア内に、又は、（ｉｉｉ）他のローカルアプリケーションの利益のためその両方内に、前記ユーザの私有鍵Ｄｕ及び署名済みの証明書の記憶を前記ユーザインタフェースウィンドウが行うように、明示的に又は黙示的に命令することを特徴とする請求項８に記載の方法。
【請求項１３】
更に、前記ハッシュを再計算し、それを、前記受け取った証明書に含まれるユーザの公開鍵Ｐｕを前記受け取ったデジタル署名されたハッシュに適用することにより前記受け取ったデジタル署名されたハッシュから復元されたハッシュと比較し、それによりデジタル署名を確認する、ステップを更に含むことを特徴とする請求項８に記載の方法。
【請求項１４】
前記対称鍵暗号ベース操作が共有する暗号鍵を含み、ここで、
第三者ネットワークサイトから、送信者識別、受信者識別、及び文書識別の特定の組合せで、集合的に文書ＩＤというものに関連付けられた１又はそれ以上の暗号鍵を求める要求を受け取るステップと、
一方向性関数、文書ＩＤ、セキュリティサーバにのみ知られる秘密、及び他の情報に基づき、各文書ＩＤに対する１又はそれ以上の対称暗号鍵を生成するステップと、
第三者ネットワークサイトへ、適当な１又は複数の暗号鍵で適用可能な文書ＩＤによって表される文書を暗号化して前記ユーザにその暗号化された文書を伝送するという明示的な又は黙示的な命令と共に暗号鍵を伝送するステップと、
前記ネットワーク装置上で操作され、及び、適用可能な文書ＩＤによって表される暗号化された文書を開くために使用される、ユーザインタフェースウィンドウ以外のソフトウェアから、その要求が適用可能な文書ＩＤを含むところ、その適用可能な文書ＩＤによって表される暗号化された文書を復号するために必要とされる１又はそれ以上の対称暗号鍵を求める要求を、受け取るステップと、
適用可能な１つ又はそれ以上の対称暗号鍵を再計算又は受け取るステップと、及び
ユーザインタフェースウィンドウへ、再計算された又は受け取られた適用可能な１つ又はそれ以上の対称暗号鍵を、適用可能な文書ＩＤによって表される暗号化された文書を復号するために前記ソフトウェア内に入力するためユーザに、適用可能な１又はそれ以上の対称暗号鍵を表示するような明示的な又は黙示的な命令と共に、伝送するステップと、
を含む請求項１に記載の方法。
【請求項１５】
前記ソフトウェアから１又はそれ以上の対称暗号鍵を求める要求が、その暗号化された文書を開けようと試みるソフトウェアと通信状態にあるネットワークサイトを介して受け取られることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記セキュリティサーバが前記文書を開けようと試みるソフトウェアと通信状態にあるネットワークサイトから適用可能な１つ又はそれ以上の対称暗号鍵を受け取り、及び、
前記ユーザインタフェースウィンドウへ伝送された適用可能な１つ又はそれ以上の対称暗号鍵が、前記ネットワークサイトから受け取られる適用可能な１つ又はそれ以上の対称暗号鍵であることを特徴とする請求項１４に記載の方法。
【請求項１７】
前記セキュリティサーバは、一方向性関数に基づいて、前記適用可能な文書ＩＤ、前記セキュリティサーバに対してのみ知られる秘密及び他の情報、前記適用可能な１又はそれ以上の対称暗号鍵を再計算し、及び
前記ユーザインタフェースウィンドウへ伝送される適用可能な１又はそれ以上の対称暗号鍵が、再計算された１又はそれ以上の対称暗号鍵であることを特徴とする請求項１４に記載の方法。
【請求項１８】
前記対称鍵暗号ベース操作がトークン認証コードハードウェア又はソフトウェアのためのシードを提供するステップを含み、ここで、
前記ユーザインタフェースウィンドウから、トークンシードを求める要求と、（ｉ）ユーザ識別子及び（ｉｉ）シードが要求されるトークン識別子の少なくとも１つとを受け取るステップと、
一方向性関数、少なくとも１つの識別子、前記セキュリティサーバにのみ知られる秘密、及び他の情報に基づいて、シードを生成するステップと、及び
前記セキュアな独立した暗号化された通信チャンネルを介して前記ユーザインタフェースウィンドウへ、生成されたシードを、（ｉ）前記トークンのシードのためのインタフェース内へと前記ユーザによって入力するために前記ユーザインタフェースウィンドウディスプレイ上に前記ユーザへと伝送されたシードを表示し、又は、（ｉｉ）ユーザが介入することなく伝送されたシードを前記トークンのシードのためのインタフェース内へと直接入力するような明示的又は黙示的な命令と共に、伝送するステップと、
を含むことを特徴とする請求項１に記載の方法。
【請求項１９】
前記伝送されたシードが、最終シードを生成するためにトークンソフトウェアによって処理されるための中間シードであることを特徴とする請求項１８に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本出願は、２０１０年５月１４日に出願された米国特許仮出願第６１／３３４，７７６号に基づいて優先権を主張する、「フレキシブル疑似帯域外認証アーキテクチャ（ＦＬＥＸＩＢＬＥ  ＱＵＡＳＩ  ＯＵＴ  ＯＦ  ＢＡＮＤ  ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＡＲＣＨＩＴＥＣＴＵＲＥ）」の名称で２０１１年４月６日に出願された、係属中の出願番号第１３／０８１，１５０号に関連する。本出願は、２０１０年４月２６日に出願された米国特許仮出願第６１／３２７，７２３号に基づいて優先権を主張する、「ＩＰＨＯＮＥＳ（登録商標）及び他のスマートモバイル通信装置を使用した安全及び効果的なログイン及び取引認証（ＳＥＣＵＲＥ  ＡＮＤ  ＥＦＦＩＣＩＥＮＴ  ＬＯＧＩＮ  ＡＮＤ  ＴＲＡＮＳＡＣＴＩＯＮ  ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＵＳＩＮＧ  ＩＰＨＯＮＥＳ（ＴＭ）  ＡＮＤ  ＯＴＨＥＲ  ＳＭＡＲＴ  ＭＯＢＩＬＥ  ＣＯＭＭＵＮＩＣＡＴＩＯＮ  ＤＥＶＩＣＥＳ）」の名称で２０１１年４月６日に出願された、係属中の出願番号第１３／０８１，０６７号にもまた関連する。本出願は、「プロジェクトシール（Ｐｒｏｊｅｃｔ  Ｓｅａｌ）」の名称で２００９年１１月２日に出願された米国特許仮出願第６１／２５７，２０７号に基づいて優先権を主張する、「安全なサイト及びユーザ認証のための新しい方法（Ａ  ＮＥＷ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＥＣＵＲＥ  ＳＩＴＥ  ＡＮＤ  ＵＳＥＲ  ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ）」の名称で２０１０年１１月２日に出願された、係属中の出願番号第１２／９３８，１６１号にもまた関連する。本出願は、係属中の出願番号第１２／９３８，１６１号の継続出願である、「安全なユーザ及びサイト認証のための新しい方法（Ａ  ＮＥＷ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＥＣＵＲＥ  ＵＳＥＲ  ＡＮＤ  ＳＩＴＥ  ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ）」の名称で２０１１年１月１４日に出願された、係属中の出願番号第１３／００６，８０６号にもまた関連する。本出願は、「認証―ゲームチェンジャ―（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ−Ｔｈｅ  Ｇａｍｅ  Ｃｈａｎｇｅｒ）」の名称で２０１０年１月２７日に出願された米国特許仮出願第６１／２９８，５５１号に基づいて優先権を主張する、「安全なユーザ及び取引認証並びにリスク管理のための新しい方法（Ａ  ＮＥＷ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＥＣＵＲＥ  ＵＳＥＲ  ＡＮＤ  ＴＲＡＮＳＡＣＴＩＯＮ  ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＡＮＤ  ＲＩＳＫ  ＭＡＮＡＧＥＭＥＮＴ）」の名称で２０１１年１月２１日に出願された、係属中の出願番号第１３／０１１，５８７号にもまた関連する。本出願は、係属中の出願番号第１３／０１１，５８７号の一部継続出願である、「安全なユーザ及び取引認証並びにリスク管理のための新しい方法（Ａ  ＮＥＷ  ＭＥＴＨＯＤ  ＦＯＲ  ＳＥＣＵＲＥ  ＵＳＥＲ  ＡＮＤ  ＴＲＡＮＳＡＣＴＩＯＮ  ＡＵＴＨＥＮＴＩＣＡＴＩＯＮ  ＡＮＤ  ＲＩＳＫ  ＭＡＮＡＧＥＭＥＮＴ）」の名称で２０１１年１月２１日に出願された、出願番号第１３／０１１，７３９号にもまた関連する。上記特定された出願の内容は、本明細書に参照により全体が組み込まれる。
【０００２】
技術分野
本発明は、セキュリティ及びプライバシに関する。より詳細には、鍵管理のための疑似帯域外認証（ｑｕａｓｉ  ｏｕｔ  ｏｆ  ｂａｎｄ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ）（ＱＯＯＢＡ）アーキテクチャの使用に関する。
【背景技術】
【０００３】
発明の背景
マンインザミドル（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ）（ＭＩＴＭ）及びマンインザブラウザ（ｍａｎ−ｉｎ−ｔｈｅ−ｂｒｏｗｓｅｒ）（ＭＩＴＢ）技術に基づく、サイト固有攻撃の高度化が、我々の現在の認証技術に深遠な意味を持つ。特に、正規のユーザがログインのために初期資格証明（ｉｎｉｔｉａｌ  ｃｒｅｄｅｎｔｉａｌｓ）を与えた後に、これらの攻撃がトランザクションを操作するので、初回ログイン認証の強度は、益々関連性がなくなっていく。この傾向に反応して、先頭を行くような機関は、例えばＥＭＶ−ＣＡＰベースのトークン認証コードのような、トランザクション認証システムを配備し始め、或いはユーザが実際にバックエンドでは見られているトランザクションを意図したことを保証する帯域外認証（ｏｕｔ  ｏｆ  ｂａｎｄ  ａｕｔｈｅｎｔｉｃａｔｉｏｎ）（ＯＯＢＡ）技術を使用してきた。しかしながら、そのようなアプローチは、本質的に使用が簡単ではなく、その結果、配備されても、プロファイル変更のような高リスク・トランザクション又はたまのイベントに対してのみ一般に使用される。大部分のトランザクションに対して、「如何に容易か？如何に安全か？如何にコストがかかるか？」というトレードオフにおいて妥当なポイントを、現在の如何なる認証ソリューションも提供しない。
【０００４】
以前の仕事において（上で特定される関連出願を参照）、我々は、従来の認証システムに関するいくつかの問題に対処するイノベーションを記述した。特に、ユーザが実際にバックエンドで見られているトランザクションを意図していたことを確実にする、ＱＯＯＢＡ技術を使用するという概念を我々は導入した。また、ウェブサイトとＱＯＯＢＡセキュリティサーバとの間において共有される秘密に基づき、そのウェブサイトへのログイン（即ち、そのウェブサイトへのユーザ認証）を可能にするような、ワンタイムパスワード（ｏｎｅ  ｔｉｍｅ  ｐａｓｓｗｏｒｄ）（ＯＴＰ）をユーザに提供するために、これらの技術が如何に使用できるかを我々は記述した。このようにして、これらの技術は、ワンタイムパスワードのセキュリティを提供するために使用できるが、全ての従来のワンタイムパスワードシステムが要求してきたユーザ毎の共有秘密を必要とはしない。
【０００５】
「如何に容易か？如何に安全か？如何にコストがかかるか？」というトレードオフにおいて妥当なポイントでの大部分のトランザクションに対する認証ソリューションを提供するという問題点に言及すべく、我々の以前の仕事を我々はまた拡張した。
【０００６】
ここで、さまざまな状況で表面化する鍵管理問題に対するソリューションを考慮すべく、我々は従来の仕事を拡張する。多くの潜在的な例のうちの３つは、以下を含む。
【０００７】
以下に、鍵管理がＱＯＯＢＡアーキテクチャの上に如何に有益に階層化できたかの種々の例を我々は記述するであろう。我々の第１の例は、デジタル署名に関する。デジタル署名を要求するアプリケーションにおいて、ユーザは、私有鍵（ｐｒｉｖａｔｅ  ｋｅｙ）及びデジタル証明書、即ち、認証機関（Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ）によって認証される公開鍵及びユーザのアイデンティティの結合を備えている必要がある。セキュリティサーバを含み、如何なる第三者にも知られないような私有鍵の使用は、いくつかのアプリケーションに対して必要な強い否認防止を提供する。「デジタル署名（ｄｉｇｉｔａｌ  ｓｉｇｎａｔｕｒｅｓ）」として公開鍵暗号で作られる署名を参照するという業界の協定に我々は従う。当業者には理解されることだが、上述のようなＱＯＯＢＡシステムがすでに備えるような、共有秘密を備える根本的な対称暗号（ｓｙｍｍｅｔｒｉｃ  ｃｒｙｐｔｏｇｒａｐｈｙ）に基づく署名は、通常「電子署名（ｅｌｅｃｔｒｏｎｉｃ  ｓｉｇｎａｔｕｒｅｓ）」と呼ばれる。
【０００８】
我々の第２の例は、暗号化されたドキュメントデリバリに関する。例えば、仲介業務明細のＰＤＦのような、暗号化されたファイルがユーザに送られるとき、ユーザは、ファイルが暗号化された鍵の提供を受ける必要がある。
【０００９】
我々の第３の例は、トークン認証コードに関する。ユーザが、ワンタイムパスワード生成装置又はトランザクション認証コードのため、トークン認証コードを提供されるとき、ユーザのトークンは、共有秘密鍵を提供される必要がある。この場合、共有秘密鍵がしばしば「シード（ｓｅｅｄ）」として特徴付けられることを当業者は認識するであろう。
【００１０】
これらのすべての例において、鍵管理は、システムのコストを直接的に増加させ、間接的にセキュリティをもたらす。鍵は、同期して生成、配布、及び維持される必要がある。鍵が紛失、破損又は盗難にあったとき、鍵管理は、通常大きなコストの発生源であり、システムにおける脆弱性のポイントである。
【発明の概要】
【発明が解決しようとする課題】
【００１１】
発明の目的
したがって、本発明の目的は、デジタル署名、暗号化及びトークンシード管理のために鍵管理を実行するようにＱＯＯＢＡシステムを活用する革新的な方法を提供することである。
【００１２】
本発明の更なる目的、有利なこと、新規な特徴は、本発明の実施によるだけでなく、以下の詳細な記述を含むこの開示から、当業者に明らかとなるであろう。本発明が好適な実施形態に関して以下に記述される一方で、本発明がそれに限定されないことは理解されるべきである。本明細書の教示に接する当業者は、本明細書に開示され特許請求の範囲とされる本発明の範囲内にあり、且つ本発明が注目に値する有用性を持ち得る、さらなる具体例、変形及び実施形態を他の利用分野と同様、認識するだろう。
【課題を解決するための手段】
【００１３】
発明の概要開示
本発明のある好ましい態様によれば、セキュリティサーバは、疑似帯域外認証システム上に階層化された鍵管理を提供するように操作されることができる。ユーザに関連する、デスクトップコンピュータのようなネットワーク装置で、特定ユーザのためのユーザインタフェースウィンドウのアクティベーションの要求は、通信チャネルを介してネットワーク装置から受け取られる。この点において、通信チャネルは、非セキュア（ｎｏｎ−ｓｅｃｕｒｅ）又は「クリア（ｃｌｅａｒ）」と時々呼ばれるものである。通信プロトコルにおいてこの点で非セキュア・チャンネルを持つことが、通常であることは、当業者に認知されるだろう。例えば、ユーザがＳＳＬで保護されたウェブサイトと通信を始めるとき、セキュリティ保護されていない又はクリアなＴＣＰ／ＩＰ接続が最初に設定され、その後になってからのみ、非セキュアな又はクリアなＴＣＰ／ＩＰ接続の上にＳＳＬセキュリティが確立される。
【００１４】
次に、セキュリティサーバにユーザを認証させるために、音声又はテキストメッセージを介して、アクティベーションＰＩＮ（個人識別番号（ｐｅｒｓｏｎａｌ  ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  ｎｕｍｂｅｒ））が、ユーザの電話機に送信（ｆｏｒｗａｒｄｉｎｇ）するために、帯域外認証（ＯＯＢＡ）システムに伝送される。例えば、ＯＯＢＡシステムは、ユーザの自宅又は携帯電話をコールしてユーザに言語でＰＩＮを伝達するかもしれず、又はユーザのスマートフォン、例えばユーザのＩＰｈｏｎｅ（登録商標）又はＢｌａｃｋｂｅｒｒｙ（登録商標）にテキストメッセージを送信し、文書形態でユーザにＰＩＮを伝達するかもしれない。どちらの場合でも、ユーザは、伝達されたＰＩＮをユーザインタフェースウィンドウに入力、即ち、コピーしなければならず、それがセキュリティサーバに返送されるようになる。この方法において、セキュリティサーバによってＯＯＢＡシステムに以前に伝送されたＰＩＮは、通信チャネルを介してユーザのネットワーク装置から戻されセキュリティサーバによって受け取られ、そして、戻ってきたＰＩＮに基づいて、ユーザが認証され、又は認証拒否がなされる。
【００１５】
セキュリティサーバによってユーザが認証されていることを前提として、ユーザインタフェースウィンドウとセキュリティサーバとの間に、セキュアな、独立した、暗号化された通信チャネルが、最初に設立した通信チャネルの上に確立される。このセキュアなチャネルの確立と共に、公開鍵（ｐｕｂｌｉｃ  ｋｅｙ）及び／又は対称鍵（ｓｙｍｍｅｔｒｉｃ  ｋｅｙ）暗号ベースの操作のための鍵資料（ｋｅｙ  ｍａｔｅｒｉａｌ）及び／又は証明資料（ｃｅｒｔｉｆｉｃａｔｅ  ｍａｔｅｒｉａｌ）は、生成されることができ、ユーザインタフェースウィンドウとセキュリティサーバとの間で安全に伝送されることができる。鍵資料及び証明資料が、当該技術分野でよく理解されている用語であることは、多分ここで留意するに値するであろう。例えば、鍵資料は、しばしば対称鍵又は非対称鍵（ａｓｙｍｍｅｔｒｉｃ  ｋｅｙｓ）を含み、証明資料は、しばしばユーザアイデンティティ（ｕｓｅｒ  ｉｄｅｎｔｉｔｙ）及び公開鍵の結合（ｂｉｎｄｉｎｇ）を含む。
【００１６】
公開鍵暗号のための鍵資料の生成及び伝送を含む実装において、セキュリティサーバは、ユーザに関連し及びユーザインタフェースウィンドウによって以前に生成された私有鍵／公開鍵ペアＤｕ／Ｐｕを好ましくは受信する。公開鍵Ｐｕは、セキュアな、独立した、暗号化された通信チャネルを介して、ユーザインタフェースウィンドウから受信される。それに応じて、セキュリティサーバは、ユーザと受信した公開鍵Ｐｕとを関連づける署名された証明書、及び、その証明書の記憶のための命令、を伝送し、その両方はセキュアなチャネルを介してユーザインタフェースウィンドウに行く。
【００１７】
証明書は、セキュリティサーバ自体又は外部の認証権利者、例えば第三者の認証機関によって署名されてよい。セキュリティサーバが中間又はルート認証機関（Ｉｎｔｅｒｍｅｄｉａｔｅ  ｏｒ  Ｒｏｏｔ  Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ）として行動する場合は、好ましくはセキュリティサーバは、ローカルに記憶された認証機関鍵資料を使用して証明書を生成し、署名する。一方、証明書が、外部の認証機関によって署名されるならば、セキュリティサーバは、好ましくは、署名のない証明書をその外部の認証機関に送信し、その認証機関から署名済みの証明書を受信する。そのような場合は、セキュリティサーバによってユーザインタフェースウィンドウに伝送されるものが、外部の認証機関によって署名された証明書である。
【００１８】
伝送された記憶命令は、実装に依存するが、ユーザのネットワーク装置上のメモリ内、又は、ネットワーク装置のＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムのようなオペレーティングシステムの鍵ストア内、或いはその両方内に、ユーザ私有鍵Ｄｕ及び署名済み証明書の記憶を要求してもよい。或いは、伝送された記憶命令は、明示的又は黙示的に、ユーザインタフェースウィンドウに記憶の決定を委ねるようにしてもよい。例えば、記憶命令が提供されないときは、これはユーザインタフェースウィンドウによって、ユーザ私有鍵Ｄｕ及び署名済み証明書を何処に記憶するかの決定はユーザインタフェースウィンドウによるとするための黙示的な命令とみなされてよい。記憶領域は、ユーザインタフェースウィンドウのみのためであってよく、又は、追加的にブラウザアプリケーションを含む、他のローカルアプリケーションのためであってもよい。
【００１９】
対称鍵暗号操作のために、鍵資料のセキュリティサーバによる生成及び伝送を含む実装において、セキュリティサーバは、ユーザに関連した、或いは、ファイル、即ち、文書であって、例えばＡｄｏｂｅ（登録商標）又はＷｉｎＺｉｐ（登録商標）のファイル又は文書のようなものに関連した固有の識別情報を含む、認証された要求を有益に受信する。この情報は、ユーザインタフェースウィンドウ、又は、商人又は銀行のウェブサイトのような第三者ネットワークサイト、から受信することができる。要求をどの実体から受信するかに関係なく、セキュリティサーバは、固有の対称鍵Ｋを生成する。鍵Ｋは、一方向性関数を使用して生成され、鍵の値は、受信した固有の識別情報及びセキュリティサーバのみが知る秘密から導かれる。セキュリティサーバは、対称鍵Ｋをリクエスタ（ｒｅｑｕｅｓｔｅｒ）、即ち、ユーザインタフェースウィンドウ又は第三者ネットワークサイトに伝送する。
【００２０】
トランザクションでデジタル署名を得るために公開鍵暗号操作を実行するセキュリティサーバを含む実装において、セキュリティサーバは、トランザクション、及び、商人又は銀行のウェブサイトのような第三者ネットワークサイトからトランザクションのデジタル署名を求める要求を、有利に受信する。セキュリティサーバは、トランザクション及びデジタル署名の要求を、セキュアなチャネルを介して、ユーザインタフェースウィンドウに伝送する。それに応じて、セキュリティサーバは、ユーザインタフェースウィンドウから、セキュアなチャネルを介して、ユーザの私有鍵Ｄｕでデジタル署名済みの伝送されたトランザクションのハッシュ（ｈａｓｈ）を受信する。セキュリティサーバは、次に受信したトランザクションのデジタル署名済みハッシュ及び証明書を、第三者ネットワークサイトに伝送する。セキュリティサーバは、また、ハッシュを再計算することにより、更に、伝送された証明書に含まれるユーザ公開鍵Ｐｕを伝送されたデジタル署名済みハッシュに適用することにより伝送されたデジタル署名済みハッシュから復元できるハッシュとそれとを比較することにより、第三者ネットワークサイトがデジタル署名を確認するような命令を、送信する。この命令は、明示的又は黙示的であってもよい。例えば、セキュリティサーバは、確認に関する命令を提供しなくてもよく、これは第三者ネットワークサイトによって、上述の方法で確認を実行する黙示的な命令とみなしてよい。
【００２１】
デジタル署名が要求されるとしても、トランザクションでユーザの電子署名を更に得ることが望ましいかもしれない。もしそうであれば、セキュリティサーバは、ユーザへの提示のためにユーザインタフェースウィンドウへと、ユーザのネットワーク装置に表示されたブラウザウィンドウ内に提示されたトランザクションに電子的に署名するための、個人識別番号（ＰＩＮ）を伝送できる。ＰＩＮは、セキュアな、独立した、暗号化された通信チャネルを介して伝送される。ユーザは、ユーザインタフェースウィンドウに提示される伝送されたＰＩＮを、ブラウザウィンドウ内に入力し、それにより、ユーザがビジネスをトランザクションするための第三者ネットワークサイトと通信し、トランザクションに電子的に署名する。ＰＩＮが、ユーザによってではなく、セキュリティサーバ及び第三者ネットワークサイトによって共有される秘密に対応することがきわめて好ましい。
【００２２】
伝送されたトランザクションは、ユーザインタフェースウィンドウ内でユーザに対してトランザクションを示す、及び／又は、トランザクションのデジタル署名に先立ちユーザの承認を得る、命令を含んでもよいし、含まなくてもよい。ここで再び、命令は、明示的又は黙示的であってもよい。例えば、承認の場合、トランザクションをユーザインタフェースウィンドウがデジタル署名するのに先立って、トランザクションのユーザ承認が、ユーザに、ユーザインタフェースウィンドウに提示される承認済みボタンをクリックすることを要求してもよい。或いは、トランザクションがユーザインタフェースウィンドウに最初に提示された後、所定の時間内に、ユーザインタフェースウィンドウに提示されるトランザクションを、ユーザが拒否しないことによって承認の合図とすることもあるかもしれない。
【００２３】
デジタル署名の場合では、ユーザインタフェースウィンドウは、他のローカルアプリケーションの利益のために、ユーザの私有鍵Ｄｕ及び署名された証明書の記憶を、メモリ内又はネットワーク装置のオペレーティングシステムの鍵ストア内、或いはその両方で、行うことができる。セキュリティサーバはまた、トランザクションの受信したデジタルに署名されたハッシュ、及び、証明書、を第三者ネットワークサイトへ伝送する前に、デジタル署名を確認してもよい。署名を確認するために、セキュリティサーバは、トランザクションのハッシュを再計算し、受信した証明書に含まれるユーザの公開鍵Ｐｕをトランザクションの受信されたデジタルに署名されたハッシュに適用することにより、受信されたデジタルに署名されたハッシュから復元されたハッシュとそれとを比較する。
【００２４】
共有する暗号鍵を含む対称鍵暗号ベースの操作を実行するセキュリティサーバを含む実装では、セキュリティサーバは、例えば商人、銀行、米国政府等の第三者ネットワークサイトから、集合的に文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）とされる、送信者識別、受信者識別及び文書識別の特定の組み合わせに関連した１又はそれ以上の暗号鍵を求める要求を受信する。
【００２５】
セキュリティサーバは、次に各文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）のために１つ又はそれ以上の対称暗号鍵を生成する。対称暗号鍵は、一方向性関数、適用可能な文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）、セキュリティサーバのみに知られる秘密、及び、もし望まれるならば、対称暗号鍵を生成するために一般に用いられ、当業者に周知である他の情報、に基づいて生成される。セキュリティサーバは、生成された暗号鍵を、第三者ネットワークサイトに伝送するが、これは、適切な鍵（複数可）で適用可能な文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）によって表される文書を暗号化し、暗号化された文書をユーザに伝送せよ、という命令によって行われるのである。ここで再び、命令は、明示的又は黙示的であってもよい。
【００２６】
セキュリティサーバは次に、特定の適用可能な文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）によって表される文書の復号に必要とされる、１つ又はそれ以上の対称暗号鍵を求める要求を受信する。その要求は、適用可能な文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）を含み、ユーザインタフェースウィンドウ以外のソフトウェアから受信されるが、そのソフトウェアはネットワーク装置の上で作動し、適用可能な文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）によって表される暗号化された文書を開けるために使用される。例えば、その要求は、Ａｄｏｂｅ（登録商標）又はＷｉｎＺｉｐ（登録商標）又はブラウザソフトウェアから受信されてもよい。ソフトウェアから直接、その要求を受信することは、場合により好ましいかもしれない。しかしながら、他の場合では、その文書を開こうとするソフトウェアと通信状態にあるネットワークサイトを介して、ソフトウェアからの要求を受信することが好ましいかもしれない。
【００２７】
セキュリティサーバは、適用可能な１つ又はそれ以上の対称暗号鍵を再計算するか、又は受信する。セキュリティサーバは次に、再計算又は受信した適用可能な暗号鍵（複数可）を、ユーザインタフェースウィンドウに伝送する。命令は、適用可能な鍵（複数可）と共に伝送され、コピー即ち、適用可能な文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）で表される文書を復号するソフトウェアに入力するために、適用可能な鍵（複数可）をユーザに示す。ここで再び、ユーザインタフェースウィンドウへの命令は、明示的又は黙示的であってもよい。
【００２８】
受信する場合は、適用可能な対称暗号鍵（複数可）は、文書を開けようとするソフトウェアと通信状態にあるネットワークサイトから受信し、ユーザインタフェースウィンドウに伝送される鍵（複数可）は、セキュリティサーバによってネットワークサイトから受信された鍵（複数可）である。再計算する場合は、セキュリティサーバは、一方向性関数、適用可能な文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）、セキュリティサーバのみに知られる秘密及び他の情報に基づく適用可能な鍵（複数可）を再計算し、ユーザインタフェースウィンドウに伝送される鍵（複数可）は、再計算された鍵（複数可）である。
【００２９】
トークン認証コードハードウェア又はソフトウェアのためにシードを提供するように、対称鍵暗号ベースの操作を実行するセキュリティサーバを含む実装において、セキュリティサーバは、ユーザインタフェースウィンドウからトークンシードを求める要求を受信する。トークンシードの要求と共に、セキュリティサーバはまた、ユーザ識別子及び／又はシードが要求されるトークン識別子を受信する。
【００３０】
セキュリティサーバは、一方向性関数、識別子若しくは複数の識別子、セキュリティサーバのみに知られる秘密、及び当業者に周知である他の情報、に基づいて、シードを生成する。セキュリティサーバは次に、生成されたシードを明示的又は黙示的な命令と共に、ユーザインタフェースウィンドウに伝送し、ユーザによるトークンのシードのためのインタフェースへの入力のために、伝送されたシードをユーザに対し、ユーザインタフェースウィンドウディスプレイ上に提示するか、又は、ユーザが介入することなく伝送されたシードをトークンのシードのためのインタフェース内へと直接入力する。この伝送は、セキュアな、独立した、暗号化された通信チャネルを介して、ユーザインタフェースウィンドウへと行われる。伝送されたシードは、ある実装においては、最終シードを生成するために、トークンソフトウェアによって処理されるであろう、中間のシードに有益になるかもしれない。
【図面の簡単な説明】
【００３１】
図面の簡潔な記述
【図１】図１は、本発明による、フレキシブル疑似帯域外認証アーキテクチャの主コンポーネントを描いている。
【図２】図２は、本発明による、上部に階層化した鍵管理機能性を有するフレキシブル疑似帯域外認証アーキテクチャを示す。
【発明を実施するための形態】
【００３２】
発明の好ましい実施例
ＱＯＯＢＡに関する以前の仕事の一般的な概説
以前の仕事において、我々は、ユーザデバイス上に表示されるウィンドウに到達する独立したチャネルを持つ、ネットワークベースのセキュリティサーバの導入が、ユーザのブラウザ、コンピュータソフトウェア又はスマートフォン又は他のモバイル通信デバイスアプリケーション、及び、１又はそれ以上のユーザネットワーク装置を介してログイン又はトランザクション許可を提供するために訪れるウェブサイト、と連動して如何に用いることができるか、を記述してきた。
【００３３】
ＱＯＯＢＡは、ユーザにとって当然と感じるような方法において、すべてのトランザクションを認証するために使用できるようなソリューションを作成するための、革新的なアプローチである。この中心的な概念は、セキュアなサーバ（ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ））への独立した暗号化されたチャネルを有する、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）である、小さなセキュアなウィンドウを作成することである。ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）は、ゼロダウンロードブラウザポップアップ（ｚｅｒｏ−ｄｏｗｎｌｏａｄ  ｂｒｏｗｓｅｒ  ｐｏｐ−ｕｐ）（ＱＯＯＢＡポップアップウィンドウ（ＱＯＯＢＡ  Ｐｏｐ−ｕｐ  Ｗｉｎｄｏｗ））、小さなデスクトップアプリケーション（ｄｅｓｋｔｏｐ  ａｐｐｌｉｃａｔｉｏｎ）（ＱＯＯＢＡソフトウェアウィンドウ（ＱＯＯＢＡ  Ｓｏｆｔｗａｒｅ  Ｗｉｎｄｏｗ））又はスマートフォン（ＱＯＯＢＡフォンウィンドウ（ＱＯＯＢＡ  Ｐｈｏｎｅ  Ｗｉｎｄｏｗ））上のアプリとして実装され得る。イノベーションに対する重要な側面は、ソフトトークンの場合とは異なり、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）は、長期秘密のセキュアな記憶を必要としないことである。むしろ、ＱＯＯＢＡウィンドウは、帯域外認証を使用することによりログインの間に「アクティブ化（ａｃｔｉｖａｔｅｄ）」される。ＱＯＯＢＡネットワーク（ＱＯＯＢＡ  Ｎｅｔｗｏｒｋ）の一部である、ウェブサイト（例えば、商人又は銀行ウェブサイト）でユーザがトランザクションを行うので、ＱＯＯＢＡウィンドウは、ウェブサイトがユーザの意図を信用する旨のトランザクションが、ユーザのブラウザを介して、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）内においてそのトランザクションを表示するＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）にセキュアに送信される。ユーザはまた、オプションとして、ログイン又はトランザクションの許可の目的のためにウェブサイトへの認証をするブラウザ内へと、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）から、ユーザがカットアンドペーストできるトランザクション署名を示される。
【００３４】
フレキシブルＱＯＯＢＡアーキテクチャーに関する以前の仕事の概説
ＱＯＯＢＡソリューションは、使いやすさ、所有の全体のコスト、及び、ここで特に関心のあるセキュリティに関して、以下の利益を有する。
【００３５】
第１に使いやすさに関するが、ユーザは、帯域外認証のために使用される電話機へのアクセスを持つことを超えて、新しい装置を持つこともなければ又は記憶すべきパスワードを持つこともない。ユーザは、如何なる暗号に関するトランザクションコードを装置に入力する必要がなく、結果をブラウザ内にタイプする必要がない。その代わり、ユーザは、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）内において全トランザクションを見て、数クリックでトランザクション署名をコピーアンドペーストすることができる。
【００３６】
第２に所有の全体コストに関して、ＱＯＯＢＡアーキテクチャは、総ライフサイクルコストを著しく減少させる。ＱＯＯＢＡアーキテクチャは、新しいハードウェアを必要とせず、ソフトトークンと違って、ユーザ毎に、秘密の設定及び管理を要求しない。更に、ウェブサイトとＱＯＯＢＡサーバとの間の全ての通信は、ブラウザを介して行うことができ、ウェブサイトにおける統合要求は極めて軽い。ＱＯＯＢＡソリューションの全体のコストは、同等のソフトトークン配備より著しく少なく、かつ、物理的トークンのそれより遥かに少なくなるように、設計される。
【００３７】
最後にセキュリティに関するが、更に以下に述べるように、確実性のレベルは、使用されるＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）のフォームファクタに依存する。スマートフォンベースのＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）、即ち、ＱＯＯＢＡフォンウィンドウ（ＱＯＯＢＡ  Ｐｈｏｎｅ  Ｗｉｎｄｏｗ）は、最高の確実性を備えるが、ゼロダウンロードポップアップ、即ち、ＱＯＯＢＡポップアップウィンドウ（ＱＯＯＢＡ  Ｐｏｐ−ｕｐ  Ｗｉｎｄｏｗ，）でさえも、アタッカに対するハードルを著しく引き上げる。ソフトウェアＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  ｗｉｎｄｏｗ）、即ち、ＱＯＯＢＡソフトウェアウィンドウ（ＱＯＯＢＡ  Ｓｏｆｔｗａｒｅ  Ｗｉｎｄｏｗ）は、ほとんどすべてのリスクレベルに対して、ほぼ満足できるものである。
【００３８】
我々の以前の仕事において、我々は、フレキシブルＱＯＯＢＡアーキテクチャを使用するＱＯＯＢＡソリューションを実装することにより、如何にＱＯＯＢＡネットワーク（ＱＯＯＢＡ  Ｎｅｔｗｏｒｋ）内のウェブサイトが、トランザクションに対して適切なあるタイプのトランザクション認可及びフォームファクタを要求又は選択することを許すかについて記述してきた。例えば、ユーザは、デスクトップ上だけでなくスマートフォン上においても、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）を同時に有することができる。大抵のトランザクションは、ユーザのデスクトップＱＯＯＢＡソフトウェアウィンドウ（ＱＯＯＢＡ  Ｓｏｆｔｗａｒｅ  Ｗｉｎｄｏｗ）に送信され得るが（これは、はるかに便利である）、最も高いリスクのトラザクションは、ユーザのスマートフォンＱＯＯＢＡフォンウィンドウ（ＱＯＯＢＡ  Ｐｈｏｎｅ  Ｗｉｎｄｏｗ）に送信され得る。ユーザは、承認ボタンをただクリックすることで、大部分のトラザクションの承認を要求され得るが、単に何ら行動を取らないことにより他のトランザクションを、及び、トランザクションに関してセキュアな電子署名を入力することにより他のトランザクションを、承認するように、許され得る。
【００３９】
ＱＯＯＢＡアーキテクチャ上への鍵管理のオーバーレイ
ここで、ＱＯＯＢＡアーキテクチャ上に鍵管理のためのコンポーネントを我々が如何にオーバーレイするかを記述する。
【００４０】
ＱＯＯＢＡシステム
ここで図１を参照しつつ、本発明によると、ＱＯＯＢＡシステムは、その上で作動し表示されるＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０及びブラウザウィンドウ（Ｂｒｏｗｓｅｒ  Ｗｉｎｄｏｗ）１１２を有するデスクトップパーソナルコンピューティング装置１００と、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５と、及び、その上で作動可能なＱＯＯＢＡアプリケーションプログラミングインタフェース（ＱＯＯＢＡ  Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ）（ＡＰＩ）１５５を有するウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０と、からなる。実際の実装において、一般的に複数のウェブサイトがあることは理解されるべきである。固定電話、携帯電話、又はスマートフォンであるかもしれないユーザの電話機１７５をユーザが使用して、ブートストラップ認証をするために、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５によって利用されるＯＯＢＡサービス（ＯＯＢＡ  Ｓｅｒｖｉｃｅ）１６５もまた、示されるように、システムに含まれる。
【００４１】
上において参照される関連出願において、より詳細に記述されるように、ユーザは、典型的にＯＯＢＡサービス（ＯＯＢＡ  Ｓｅｒｖｉｃｅ）１６５を介して帯域外認証を使用することによりＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０をアクティブ化し、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５とのセッションを確立する。ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０は、ＱＯＯＢＡネットワーク（ＱＯＯＢＡ  Ｎｅｔｗｏｒｋ）に参加し、そして、ユーザによって知られる又は共有されていないＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５との共有秘密を確立するために、ワンタイムセットアッププロセスを経る。ユーザが通信チャネル４５０を介してＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５とアクティブセッションを持ちつつ、通信チャネル４００を介してウェブサイト（Ｗｅｂｓｉｔｅ）１５０にもいるとき、バックエンド通信チャネル５００を介してトランザクションをＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５に直接送ることによって、ウェブサイトは、ＱＯＯＢＡ  ＡＰＩ  １５５を使用してトランザクション認証を要求できる。ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５は、次に、ユーザに対して、図１においてウィンドウ（Ｗｉｎｄｏｗ）１１０として示される、適用可能なＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）内にトランザクションを表示する。
【００４２】
ＱＯＯＢＡウィンドウ（複数）
ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５は、表示されたＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０内で、ユーザに対しさまざまな情報を提示することができる。例えば、以前の仕事において我々が記述したように、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５は、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０内で、ユーザに対しトランザクションを表示することができ、要求があれば、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０内にトランザクション、即ち、トランザクションから得た電子的署名、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５及びウェブサイト（Ｗｅｂｓｉｔｅ）１５０の間で共有される秘密、及び、その他の情報、をもまた表示することができる。これは、通信チャネル６００を介して成し遂げられる。ユーザは、トランザクションを受け入れるか、又は、拒否するかの選択を、オプションとして与えられる。行動を何もしないことによって、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０内でＯＫをクリックして通信チャネル６００を介してＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５に信号を返信することによって、又は、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０からブラウザウィンドウ（Ｂｒｏｗｓｅｒ  Ｗｉｎｄｏｗ）１１２内に表示されるウェブアプリケーションの中へとトランザクション署名をコピーアンドペーストして次に通信チャネル４００を介してウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０に返信することによって、受動的に承諾を信号で伝えることができる。ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０からのトランザクション署名が、ブラウザウィンドウ（Ｂｒｏｗｓｅｒ  Ｗｉｎｄｏｗ）１１２内に表示されるウェブアプリケーションの中へとペーストされるならば、トランザクション、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５及びウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０の間で共有される秘密、及び、他の情報を使用して、ウェブサイト（Ｗｅｂｓｉｔｅ）１５０は署名を確認できる。
【００４３】
このように、１つの承認タイプは、「インフォーム（ＩＮＦＯＲＭ）」と特徴付けられるかもしれない。トランザクションは単にユーザに示されるだけで、確認は要求されない。これは「アクティビティストリーム（ａｃｔｉｖｉｔｙ  ｓｔｒｅａｍ）」に類似しており、用心深いユーザを安心させることができる。別の承認タイプは、「コンファーム（ＣＯＮＦＩＲＭ）」と特徴付けられることができる。ユーザは、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０内で、トランザクションを確認するか、又は拒否するかを求められ、この応答は、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５を介してウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０に返信される。更に他の承認タイプは、「サイン（ＳＩＧＮ）」と特徴付けられることができる。ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５は、「トランザクション署名（ｔｒａｎｓａｃｔｉｏｎ  ｓｉｇｎａｔｕｒｅ）」として機能するであろう、パーソナルＩＤ番号（ＰＩＮ）を生成し、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０内で、又はスマートフォン上のＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）（図示せず）内で、ユーザに対しそれを示す。ユーザは、このトランザクション署名をブラウザウィンドウ１１２内へとコピーし、それをウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０に送信する。ＰＩＮが、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５及びウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０の間で共有される秘密（ユーザには決して明かされない）から導かれるので、ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０は、独立してトランザクション署名を再計算することができ、そして、そのようにしてトランザクションを確認できる。これは、トランザクション認証コードシステムの同じセキュリティ効果を達成するが、ユーザ毎には秘密の設定をすることができないことが、分かるであろう。
【００４４】
ブラウザ及び／又は使用されているオペレーティングシステム（ＯＳ）並びにＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０のフォームファクタにもかかわらず、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）１２５へのユーザインタフェースは、大抵は一定のままである。ＱＯＯＢＡエクスペリエンスが装置に合わせて最適化されている、スマートフォン上でユーザがブラウジングするときが、ユーザエクスペリエンスの逸脱する唯一のユースケースである。
【００４５】
上述の通り、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０は、少なくとも３つのフォームファクタの１つで実装され得るが、ＱＯＯＢＡポップアップウィンドウ（ＱＯＯＢＡ  Ｐｏｐ−ｕｐ  Ｗｉｎｄｏｗ）と通常呼ばれ如何なるソフトウェアのダウンロードも必要としないブラウザポップアップと、ＱＯＯＢＡソフトウェアウィンドウ（ＱＯＯＢＡ  Ｓｏｆｔｗａｒｅ  Ｗｉｎｄｏｗ）と通常呼ばれデスクトップ上にインストールされる小さなアプリケーションと、及びＱＯＯＢＡフォンウィンドウ（ＱＯＯＢＡ  Ｐｈｏｎｅ  Ｗｉｎｄｏｗ）と通常呼ばれるスマートフォンアプリとである。
【００４６】
同じユーザが、異なる時間に異なるフォームファクタを使用していることはあり得る。例えば、ソフトウェアＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）をインストールして殆どの時間それを使用するユーザが、ある他のデスクトップ（ローミング）で、ブラウザポップアップＱＯＯＢＡウィンドウ（ｂｒｏｗｓｅｒ  ｐｏｐ−ｕｐ  ＱＯＯＢＡ  Ｗｉｎｄｏｗ）を使用するかもしれない。大抵のトランザクションがデスクトップウィンドウ内に表示される一方、ある高リスクトランザクションに対して、ウェブサイトはスマートフォンＱＯＯＢＡウィンドウ（ｓｍａｒｔｐｈｏｎｅ  ＱＯＯＢＡ  Ｗｉｎｄｏｗ）上にトランザクションの表示を要求するかもしれない。ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）１１０のルックアンドフィール（ｌｏｏｋ  ａｎｄ  ｆｅｅｌ）は、特定のＱＯＯＢＡネットワーク（ＱＯＯＢＡ  Ｎｅｔｗｏｒｋ）によって、完全にカスタマイズ可能である。それ自身のウェブサイトのためだけであることが意図される銀行のための実装は、ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）１５０のような、さまざまな電子商取引ウェブサービス（ｅＣｏｍｍｅｒｃｅ  ｗｅｂ  ｓｅｒｖｉｃｅｓ）内へと認証を提供する支払いサービスによる実装からは、非常に異なるように見えかつ感じる（ｌｏｏｋ  ａｎｄ  ｆｅｅｌ）かもしれない。多数の要素が記述されるが、それらの多くはオプションであることを理解されたい。
【００４７】
ＱＯＯＢＡアーキテクチャー（ＱＯＯＢＡ  Ａｒｃｈｉｔｅｃｔｕｒｅ）を使用する鍵管理
図２を参照して、ユーザのデスクトップ１００上のＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）又はユーザのスマートフォン１７５上のＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）（図示せず）とＱＯＯＢＡセキュリティサーバ１２５との間のセキュアな、暗号化された、独立したチャネル６００の確立がＱＯＯＢＡシステムの中枢となる。上述のように、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）は、ユーザトランザクションを表示し、そのトランザクションを確認する、即ち、承認する機会を提供するために使用される。
【００４８】
図２で示すように、ユーザのデスクトップ３００上におけるＱＯＯＢＡ鍵管理ロジック−クライアント（ＱＯＯＢＡ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  Ｌｏｇｉｃ−Ｃｌｉｅｎｔ）（ＫＭＬＣ）６１０と、ＱＯＯＢＡセキュリティサーバ３２５上におけるＱＯＯＢＡ鍵管理ロジック−サーバ（ＱＯＯＢＡ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  Ｌｏｇｉｃ−Ｓｅｒｖｅｒ）（ＫＭＬＳ）６２０と、ウェブサービス３５０上におけるＱＯＯＢＡ鍵管理ロジック−ＡＰＩ（ＱＯＯＢＡ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  Ｌｏｇｉｃ−ＡＰＩ）（ＫＭＬＡＰＩ）６３０と、及び「非ブラウザ（ｎｏｎ−ｂｒｏｗｓｅｒ）」デスクトップ又はスマートフォンソフトウェア（例えばＡｃｒｏｂａｔ  Ｒｅａｄｅｒ）３１４の可能性と、を、我々はここで、アーキテクチャに導入する。ＫＭＬＣ６１０及びＫＭＬＳ６２０は、ＱＯＯＢＡウィンドウ３１０及びＱＯＯＢＡセキュリティサーバ３２５の間のセキュアなＱＯＯＢＡチャネル６００を介して通信する。ＫＭＬＳ６２０及びＫＭＬＡＰＩ６３０は、ＱＯＯＢＡセキュリティサーバ３２５及びウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０の間のバックエンド通信チャネル５００を介して通信する。
【００４９】
図２を更に参照すると、上述のフレームワーク内で、鍵生成は、以下の通りに進行する。ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０がアクティブ化された後のある時点で、ＫＭＬＣ６１０は私有鍵／公開鍵のペア、例えばＤｕ／Ｐｕを生成し、私有鍵Ｄｕをセキュアに記憶する（典型的にはメモリ内に）。ＫＭＬＣ６１０は、公開鍵ＰｕをＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５に送信するが、その要求はＫＭＬＳ６２０によってインターセプトされる。デジタル証明書（「サート（Ｃｅｒｔ）」）は、ユーザの公開鍵Ｐｕを含むが、ＫＭＬＳ６２０によって準備され、２つのうちの１つが起きる。
【００５０】
もし、ＫＭＬＳ６２０が中間（Ｉｎｔｅｒｍｅｄｉａｔｅ）又はルート認証機関（ｒｏｏｔ  Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ）を演じることができるならば、ＫＭＬＳ６２０は証明書に署名し、署名済みの証明書をＫＭＬＣ６１０に返送し、そこでローカルにそれを維持する（好ましくはメモリ内に）。例えば、ＫＭＬＳ６２０は、その私有鍵／公開鍵のペアであるＤｓ／Ｐｓの私有鍵Ｄｓで、サート（Ｃｅｒｔ）に署名でき、［サート（Ｃｅｒｔ）］Ｄｓは、ＫＭＬＣ６１０に返送される。
【００５１】
他方、もしＫＭＬＳ６２０が「登録認定機関（ｒｅｇｉｓｔｒａｔｉｏｎ  ａｕｔｈｏｒｉｔｙ）」として行動するのであれば、ＫＭＬＳ６２０は、外部の認証機関（Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ）９００に証明書の要求を送り、認証機関が証明書を作成し、それをＫＭＬＳ６２０に返送し、そして、ＫＭＬＳ６２０は順に証明書を６１０に返送し、６１０は証明書をローカルに維持する（好ましくはメモリ内に）。そのような場合、サート（Ｃｅｒｔ）は、認証機関（Ｃｅｒｔｉｆｉｃａｔｅ  Ａｕｔｈｏｒｉｔｙ）によって、その私有鍵／公開鍵のペアであるＤｃａ／Ｐｃａのうちの私有鍵Ｄｃａでもって署名されるであろうし、［サート（Ｃｅｒｔ）］Ｄｃａは、ＫＭＬＳ６２０に返送される。ＫＭＬＳ６２０は次に、受信した署名済みのサート（Ｃｅｒｔ）、即ち、［サート（Ｃｅｒｔ）］ＤｃａをＫＭＬＣ６１０に送る。
【００５２】
比較的に短寿命、即ち、一時的になるように、かつ、ＱＯＯＢＡセッションそれ自体の寿命と一致するように、発行されるサート（Ｃｅｒｔ）にとって、いずれの場合であっても好ましい。アクティベーションと鍵生成が同時になるように単純化することにより、デジタル証明書及び私有鍵を長期間にわたりローカルに記憶する必要性が回避される。
【００５３】
幾つかの状況下では、以下でより詳細に述べるように、私有鍵及び証明書が、同じデスクトップ（或いはモバイル装置）上において、例えばブラウザ３１２又はドキュメントプロセッサ３１４のような、他のアプリケーションによって必要とされるかもしれない。ＭＳ  Ｗｉｎｄｏｗｓ（登録商標）又はＡｐｐｌｅ  ＭａｃＯＳ（登録商標）が行うように、もし下層にあるオペレーティングシステムが標準的な鍵ストアをサポートするならば、ＫＭＬＣ６１０は、鍵を鍵ストアに委託し、適当な時にそれを削除するということを課され得る。
【００５４】
公開鍵暗号に適切な鍵、即ち、非対称鍵の上述のような生成に加えて、鍵管理システムはまた、対称鍵を生成し、配布することができる。ＫＭＬＳ６２０内に組み込まれた、機能的な共有秘密生成機（ｆｕｎｃｔｉｏｎ  Ｓｈａｒｅｄ＿Ｓｅｃｒｅｔ＿Ｇｅｎｅｒａｔｏｒ（））であって、ユーザＩＤ（ＵｓｅｒＩＤ）（おそらくユーザの固定電話又は携帯電話番号）、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５のみに知られる長寿命の秘密、及び他の種々のパラメータのようなファクタを入力として受け取り、共有秘密Ｋ（ｓｈａｒｅｄ＿ｓｅｃｒｅｔ  Ｋ）を出力として生成するものが、これの中枢となる。１つの与えられたセットの入力に対して、同じ共有秘密が確定的に計算されるであろうことに留意することは重要である。異なる認証された主体が、適用可能な入力パラメータをＫＭＬＳ６２０に供給することで、適切な対称鍵の提供をＫＭＬＳ６２０に要求できる。
【００５５】
アプリケーションによっては、ＱＯＯＢＡ鍵管理ロジック（ＱＯＯＢＡ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  Ｌｏｇｉｃ）は、上述のような、非対称（即ち、公開）鍵暗号又は対称鍵暗号の機能の１つ又は両方を活用するかもしれないことは、留意すべきである。我々は、その鍵生成機能を含む鍵管理システムをここにおいて記述してきたが、これらの機能を利用する３つの例のアプリケーションに我々の注目を向ける。
【００５６】
デジタル署名のためにＱＯＯＢＡ鍵管理を使用すること
先述のように、あるアプリケーションに対して、公開鍵暗号を使用するデジタル署名が、電子トランザクション署名よりもより適切であると考えられる。デジタル署名は、以下に記述されるステップを使用して達成される。
【００５７】
エンドユーザは、ブラウザウィンドウ３１２内でブラウズして、ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０でトランザクションを実施する。ウェブサービス３５０は、ＫＭＬＡＰＩ６３０を使用して、要求される「デジタル署名（ｄｉｇｉｔａｌ  ｓｉｇｎｉｎｇ）」と共にトランザクション署名の要求を行う。この要求は、セキュアなバックエンド通信チャネル５００を介して、ＫＭＬＳ６２０に送信される。要求は次に、デジタル署名が要求されることを示す表示と共に、セキュアなチャネル６００を介して、ＫＭＬＳ６２０からＫＭＬＣ６１０に送信される。ＱＯＯＢＡトランザクション署名ＰＩＮは、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５によってオプションとして生成され、デジタル署名要求と共に送信される。上述のように、ＰＩＮは、もし望まれるならば、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５により、図示のデスクトップ３００上に表示されるＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０というよりはむしろ、ユーザのスマートフォン（図示せず）上に表示される、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０に類似する、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）へと、コネクション（ｃｏｎｎｅｃｔｉｏｎ：接続）６００に類似のパーシステントコネクション（ｐｅｒｓｉｓｔｅｎｔ  ｃｏｎｎｅｃｔｉｏｎ：持続的な接続）を介して送信できることを理解すべきである。
【００５８】
ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０は、通常通りユーザにトランザクションを表示し、トランザクション署名ＰＩＮ、即ち、電子署名をブラウザウィンドウ３１２内にコピーすることを、ユーザにオプションとして要求する。並行して、ＫＭＬＣ６１０は、トランザクションにおけるハッシュを計算し（「ハッシュトラン（ＨａｓｈＴｒａｎ）」）、及び、以前にメモリに記憶されていたユーザの私有鍵Ｄｕを使用してデジタル署名を計算するが、その結果は［ハッシュトラン（ＨａｓｈＴｒａｎ）］Ｄｕとなる。このプロセスは、いわゆる舞台裏で、又は、トランザクションに署名をすることに同意をユーザに求めることにより、起こり得る。どちらの場合でも、デジタル署名Ｄｕは、ハッシュされたトランザクション［ハッシュトラン（ＨａｓｈＴｒａｎ）］に適用される。トランザクション［ハッシュトラン（ＨａｓｈＴｒａｎ）］Ｄｕというデジタルに署名されたハッシュは、次に、セキュアなチャネル６００を介して、ＫＭＬＣ６１０からＫＭＬＳ６２０に、デジタル証明書［サート（Ｃｅｒｔ）］Ｄｓ又は［サート（Ｃｅｒｔ）］Ｄｃａと共に送信される。
【００５９】
ＫＭＬＳ６２０は、ハッシュトラン（ＨａｓｈＴｒａｎ）を得るためにユーザの公開鍵Ｐｕをデジタル署名［ハッシュトラン（ＨａｓｈＴｒａｎ）］Ｄｕに適用すること、及び、独立に生成されたハッシュトランと比較すること、によって、署名の検証をオプションとして実行できる。検証が実行されるか否かにかかわらず、ＫＭＬＳ６２０は、セキュアなチャネル５００を介して、署名をＫＭＬＡＰＩ６３０に送る。
【００６０】
ＫＭＬＡＰＩ６３０は、ハッシュ値であるハッシュトラン（ＨａｓｈＴｒａｎ）を再計算することができ、デジタル証明書であるサート（Ｃｅｒｔ）に含まれるユーザの公開鍵Ｐｕを使用して、その署名を確認することができる。このように、ＫＭＬＡＰＩ６３０は、ＫＭＬＳ６２０公開鍵Ｐｓを［サート（Ｃｅｒｔ）］Ｄｓに、又は認証管理者公開鍵Ｐｃａを［サート（Ｃｅｒｔ）］Ｄｃａに適用し、Ｐｕを回復する。次に回復されたＰｕを［ハッシュトラン（ＨａｓｈＴｒａｎ）］Ｄｕに適用し、ハッシュトラン（ＨａｓｈＴｒａｎ）を復元し、それを単独で生成されたハッシュトラン（ＨａｓｈＴｒａｎ）と比較して署名を確認する。
【００６１】
上記の記述で、ハッシュはＫＭＬＣ６１０で作成されることに留意されたい。しかしながら、それはＫＭＬＡＰＩ６３０又はＫＭＬＳ６２０でも同様に容易に作成され得るところ、各主体がその信頼性を確保するために、それを再計算しがちである。
【００６２】
この例では、全トランザクションは、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０にやって来る。一方、もし文書がこのアプローチを使用して署名される必要があるならば、例えばブラウザ３１２又は非ブラウザアプリ３１４のような、他のアプリケーションに利用可能な鍵を作るであろう、ユーザのデスクトップ３００上において利用できる鍵ストアに、私有鍵及び公開鍵をＫＭＬＣに委ねさせるように、機能を拡張することができる。ＫＭＬＣは、適切な時期に、鍵ストアからユーザ鍵を削除する責任があるであろう。
【００６３】
暗号鍵を共有するためにＱＯＯＢＡ鍵管理を使用すること
データが、暗号化され、そして、Ｅメールのようなストアアンドフォワードシステム（ｓｔｏｒｅ  ａｎｄ  ｆｏｒｗａｒｄ  ｓｙｓｔｅｍ）における受信者に送信されることはしばしば起きる。例えば、規則は、財務諸表又は健康記録のような文書は、Ｅメールの添付ファイルとして送信されるならば、暗号化して送信されなければならないことを要求する。例えばＷｉｎＺｉｐ（登録商標）及びＡｃｒｏｂａｔ  Ｒｅａｄｅｒ（登録商標）のような多くのアプリケーションは、パスワードベースの暗号化機能を組み込んできた。そこで、復号パスワードが如何にしてユーザに送信されるかについて、疑問が生じる。１つのアプローチは、共有パスワードに関し推測的に同意することである。このアプローチの欠点は、漏らされたパスワードが、多くの文書を復号するために使用されることができることであり、ユーザはパスワードを忘れがちであるので、複雑なパスワードを要求することがまた困難であることである。この問題を解決するためのＱＯＯＢＡ鍵管理システム（ＱＯＯＢＡ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ）を使用する３つのアプローチが、以下に記述される。
【００６４】
アプローチ１
例えば、固有の文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）によって、一義的に識別される文書は、ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０によって、例えば８文字の英数字ＰＩＮのようなＰＩＮから導かれる鍵で暗号化され、次に、例えばＥメールを介してユーザに送信される。この考察の目的に対して、文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）は、送信者ＩＤ、受信者ＩＤ、及び文書ＩＤ（文書識別）の特定の組み合わせに関連した固有の値である。ユーザが、例えばＷｉｎＺｉｐ（登録商標）及びＡｃｒｏｂａｔ  Ｒｅａｄｅｒ（登録商標）のようなデスクトップ上のソフトウェアアプリケーションを典型的に使用するように、あるアプリケーション３１４を使用して文書を開けるとき、プログラムは、ユーザが特定の文書を読もうとしていることを示す信号をウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０に送信する。アプリケーション３１４はブラウザであってもよいが、この考察における目的に対して、図２に示すように、他のデスクトップソフトウェアであると仮定されている。
【００６５】
ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０は、文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）によって参照された文書が最初に暗号化されたＰＩＮを取得し、次にＫＭＬＡＰＩ６３０を使用してＰＩＮをＱＯＯＢＡサーバ３２５に送信する。ＱＯＯＢＡサーバ３２５は、ＫＭＬＳ６２０を使用し、ＰＩＮをＫＭＬＣ６１０に送付し、ＰＩＮは次に、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０内でユーザに対して表示される。
【００６６】
ユーザは、ＰＩＮをアプリケーション３１４内へとコピーし、復号は正常に進行する。一般に、アプリケーション３１４への変更が要求されないことはよく見るべきである。開いたときに、メッセージをウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０にトリガする能力は、すでに多くのアプリケーション（例えばＡｄｏｂｅ  Ｒｅａｄｅｒ）に組み込まれている機能である。
【００６７】
アプローチ２
上記のアプローチの１つの欠点は、ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０が、文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤｓ）及びＰＩＮ（ＰＩＮｓ）のリストを維持しなければならないことである。この問題を解決する１つの方法は、各文書が暗号化される際の鍵を、ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０のみに知られる長期の秘密及び文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）を入力として取得する関数の結果となるようにすることである。この方法により、アプローチ１に記載のようにユーザが文書を開けようと試みた後に、鍵が動的に生成されることができる。
【００６８】
アプローチ３
上述のことの１つの欠点は、文書が開けられるときに、ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０が利用可能で、かつ、オンラインであるという前提条件があることである。文書を生成し配布するシステムの幾つかは、バックエンドバッチシステム（ｂａｃｋ−ｅｎｄ  ｂａｔｃｈ  ｓｙｓｔｅｍｓ）であるので、この前提条件は常に適用できるものではないかもしれない。ＱＯＯＢＡ鍵管理（ＱＯＯＢＡ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ）の共有秘密生成機能は、以下のように、この問題を解決するために使用できる。
【００６９】
ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０は、暗号化したい文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤｓ）を、１つずつ、又は、よりあり得るのはバッチファイルにおいて、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５に送信する。この考察の目的に対して、そのファイルは、送信者及び受信者のＩＤ（ＩＤｓ）のようなエンベロープ情報を含むことが仮定される。ＫＭＬＳ６２０は、上述の共有秘密生成機（Ｓｈａｒｅｄ＿Ｓｅｃｒｅｔ＿Ｇｅｎｅｒａｔｏｒ（））を使用し、各文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）のための暗号鍵を計算する。例えば、１つの文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）のための鍵Ｋ１、別の文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）のためのＫ２、別の文書ＩＤ（ＤｏｃｕｍｅｎｔＩＤ）のためのＫ３などである。これらの鍵は次に、ＫＭＬＳ６２０によってウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０に返送される。ウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０は次に、適用可能な鍵でそれぞれの文書毎に暗号化し、暗号化した文書を、例えばＥメールを介して、それぞれの適用可能なユーザに送信する。
【００７０】
適用可能なユーザは、他のデスクトップソフトウェア３１４を使用して文書を開き、それによって、別の通信チャネルであるセキュアなウェブ接続７５０を介してＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５に直接的に鍵を求める要求をトリガする。これは、ノンブラウザソフトウェア３１４からＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５への直接接続７５０であり、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０によらないものであることに留意するべきである。
【００７１】
この行動は、ＫＭＬＳ６２０が共有秘密生成機（Ｓｈａｒｅｄ＿Ｓｅｃｒｅｔ＿Ｇｅｎｅｒａｔｏｒ（））を使用して、例えばＫ１、Ｋ２、Ｋ３などのような適用可能な暗号鍵を再計算するという結果になる。適用可能な鍵は次に、ＫＭＬＣ６１０に送信され、前述したようにノンブラウザウィンドウ（Ｎｏｎ−Ｂｒｏｗｓｅｒ  Ｗｉｎｄｏｗ）３１４内へとコピーするために、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０内でユーザに対し表示される。
【００７２】
我々の例としてノンブラウザソフトウェア（例えばＡｃｒｏｂａｔ  Ｒｅａｄｅｒ）を使用して我々は上述してきたが、同じ機能が、ブラウザベースのウェブアプリケーションに使用できる。
【００７３】
「シーディング（Ｓｅｅｄｉｎｇ）」ワンタイムパスワード（Ｏｎｅ−Ｔｉｍｅ−Ｐａｓｓｗｏｒｄｓ）（ＯＴＰｓ）及びトランザクション認証トークンのためにＱＯＯＢＡ鍵管理を使用すること
例えばハードウェア、ソフトウェア、スマートフォンアプリ等のような、ワンタイムパスワード（Ｏｎｅ−ｔｉｍｅ−ｐａｓｓｗｏｒｄｓ）（ＯＴＰｓ）及びトランザクション認証（Ｔｒａｎｓａｃｔｉｏｎ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）のトークン認証コードは全て、トークン内に及びバックエンドシステムにも記憶される鍵を必要とする。これらの鍵を管理すること（「シーズ（ｓｅｅｄｓ）」と通常呼ばれる）は、コスト及び複雑さを持ち込むことになる。ＱＯＯＢＡ鍵管理システム（ＱＯＯＢＡ  Ｋｅｙ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）は、このプロセスを大幅に単純化するために使用できる。
【００７４】
この考察の目的に対して、トークン認証コード（図示せず）は、ハードウェア、ソフトウェアとして、又はモバイルフォンアプリとして実装されることが仮定される。トークンは、シードの存在しない不活性の状態（又はシードのリフレッシュが必要）で始まる。要求は、ユーザによってＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０内で直接的に、或いはＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５へ又はシーディングイベントを要求する外部のウェブサービス（Ｗｅｂ  Ｓｅｒｖｉｃｅ）３５０へ、トークンから直接的に行われる。ユーザＩＤ（ＵｓｅｒＩＤ）を識別するある固有の識別子は、ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５に提供される。
【００７５】
ＱＯＯＢＡサーバ（ＱＯＯＢＡ  Ｓｅｒｖｅｒ）３２５内にあるＫＭＬＳ６２０は、そのユーザの固有のシードを生成する共有秘密生成機（Ｓｈａｒｅｄ＿Ｓｅｃｒｅｔ＿Ｇｅｎｅｒａｔｏｒ（））内へとの、入力として、ＫＭＬＳ６２０のみに知られる長期秘密を含む、固有のユーザＩＤ（ＵｓｅｒＩＤ）及び他の情報を使用する。このシードは、セキュアなチャネル６００を介して、ＫＭＬＣ６１０に返送され、次にＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０内においてユーザに対し表示される。ユーザは、そのシードをソフトウェア又はスマートフォンアプリトークン（ｓｍａｒｔｐｈｏｎｅ  ａｐｐ  ｔｏｋｅｎ）内へと入力する。我々は、実際のシードが、ユーザが入力するシードを変換する機能によって生成されるかもしれないことを留意する。大抵のトランザクション認証コードは実際持っているキーパッドを有する場合においてのみ、ハードウェアに対して、これは機能することが認識されるであろう。
【００７６】
上記の変形として、トランザクション認証コードが、機能の一部として、ＱＯＯＢＡウィンドウ（ＱＯＯＢＡ  Ｗｉｎｄｏｗ）３１０内へと直接的に組み入れられ得ることを留意されたい。一見したところ、この根拠は明白ではないかもしれないが、例えばＥＭＶ／ＣＡＰのような既存のシステムとの互換性が、このアプローチの根拠を提供する。トランザクション認証コードのこのオンデマンドシーディングが、プロビジョニングのコストを大いに簡素化する。
【図１】
0005683746.tif 000002
【図２】
0005683746.tif 000003