トークン共有システムおよび方法
小売商、銀行、販売業者、他の消費者等のような多様な組の認証要求を持つエンティティに対して、消費者のようなエンティティを認証するスケーラブルなシステムおよび方法である。トークンのような認証信用証明書は、信用証明書の所有者を認証する方法として、いくつかのリソースの間で共有することができる。
【発明の詳細な説明】
【関連出願の相互参照】
【０００１】
本出願は、２００５年５月６日に出願された米国仮特許出願シリアル番号第６０／６７８，２１４号の利益を主張している。この特許出願の開示は、その全体が参照によりここに組み込まれている。
【発明の分野】
【０００２】
本発明の分野は、コンピュータの安全性、特に、認証である。
【本発明の背景】
【０００３】
企業は、自身のデータおよび情報技術の機密性、完全性および保証されたサービスを保護するために強力な認証技術を使用していることで知られている。この認証技術は、デジタル証明書を各従業員に発行することや、トークンを各従業員に提供すること等を含むさまざまな方法を使用して実現されている。企業向けの強力な認証は、比較的、実現しやすい。その理由は、一般的に、単一性のエンティティが存在し、制御されるグループのユーザが、単一性のエンティティに対して、ユーザ自身、すなわち企業自身を認証しなければならないからである。
【０００４】
消費者適用に対して強力な認証技術を適用することは困難である。デジタル証明書およびトークンは、小売商のような他のエンティティと消費者との対話に対する妨げであると認識されていたり、消費者も他のエンティティも自発的に負担しようとしない費用であったりする。しかしながら、識別子の盗用、フィッシング、中間者攻撃、およびクレジットカードの盗難のような、ハッカーによってもたらされる脅威がますます巧妙化し、与えられる損害が大きくなる観点から、いくつかの強力な認証技術を積極的に取り入れようとする消費者の意向は、増すものと予期することができる。これは、オンラインで行われる商取引および他の活動の量が年々増加することによってさらに強まる。
【０００５】
実際には、危険に対する未解決の脅威および不愉快な出来事の結果として生じた蓄積そのものが、消費者活動のオンライン環境への継続的移行に対する現代の障害であると考えられる。より強力な認証が消費者に対して必要であるが、ある既知の解決策を実現することは困難である。例えば、大部分の企業のクライアントとは異なった方法で、消費者は、幅広いさまざまなエンティティに対して消費者自体を認証しなければならない。消費者は、一般的に、異なるエンティティに関係付けられている異なる認証証明書を常に監視することを望まない。例えば、多くの消費者は、銀行、クレジットカード、サービスプロバイダ、医療および役所の複数の口座を持っている。消費者による強力な認証から、これらのそれぞれの口座は利益を得る。このケースでは、口座ごとに１つの認証デバイスが消費者に発行される場合、消費者のポケットまたはキーリングがデバイスでいっぱいになる。これは、消費者にとって望ましくないことである。
【０００６】
必要とされるものは、幅広い企業に対して消費者自体を認証するために、消費者によって使用することが可能な共有トークンを使用して、動作可能である認証システムおよび方法である。多くのサイトにわたって単一のトークンを共有できる場合、消費者は、セル電話機、車のキーまたはクレジットカードとほとんど同じように、必要なパーソナルツールとしてこれらを携帯し始める可能性が非常に高い。
【詳細な説明】
【０００７】
ここで用いているような「識別子の共有」は、トークンの保持者のパーソナル識別子を認証する能力を共有することを意味している。「第２の要素の共有」は、トークンに関係付けられているエリアスを認証する能力を共有することを意味している。例えば、２要素認証システムは、パーソナル識別番号（「ＰＩＮ」、すなわち「第１の要素」）とワンタイムパスワード（「ＯＴＰ」、すなわち「第２の要素」）とを含んでいてもよい。ＰＩＮは、トークンの個人保持者と認証システムとの間で共有されるシークレットである。特定のＯＴＰは、一連の数字のうちの１つであってもよく、一連の数字は、所定のトークンによってのみに一意的に発生されたり、認証システムによってチェックすることができる。認証システムがＰＩＮをユーザから受け取って確認したとき、そのユーザはその特定のＰＩＮと相関付けられているので、システムはユーザを認証することができる。同様に、認証システムがＯＴＰをトークンから受け取って確認したとき、そのトークンはその特定のＯＴＰと相関付けられているので、認証システムはトークンを認証することができる。識別子共有システムにおいて、いくつかのエンティティのうちの何らかのものが、例えば、ＰＩＮに基づいて、またはＰＩＮとＯＴＰとに基づいて、ユーザの識別子を認証することができる。第２の要素の共有システムにおいて、いくつかのエンティティのうちの何らかのものが、ＯＴＰを使用して、トークン自体を認証することができる。例として、２要素認証デバイスを使用して、識別子および第２の要素の共有について説明しているが、本発明にしたがうと、あらゆる認証スキームを使用することができる。例えば、デジタル証明書および／またはチャンレンジ−応答スキームを第２の要素の共有に使用することができる。
【０００８】
中央トークンサービスモデル
本発明の実施形態にしたがった中央トークンサービスインフラストラクチャは、例えば、ハードウェアトークン上に記憶および／またはハードウェアトークンによって実現される、証明書またはＯＴＰのような、第２の要素の信用証明書を提供したり妥当性確認をしたりするために使用される。第２の要素を実現するトークンは、さまざまなアプリケーションおよび／またはウェブサイトのうちの任意のものにおいてアクティブ化されてもよい。アプリケーション自体のユーザデータベースにおいて、ユーザ名およびパスワードのような第１の要素をアプリケーションが管理することができる。トークンのアクティブ化の一部分として、アプリケーションは、ローカルユーザ名と、トークンシリアル番号のような共有される第２の要素のトークン識別子との間のマッピングを記憶することができる。
【０００９】
妥当性確認のために、ユーザは、ユーザ名およびパスワードのような第１の要素と、トークンからのＯＴＰまたはトークン上に記憶されている証明書のような第２の要素とを入力することができる。アプリケーションは、ローカル的に、第１の要素の妥当性確認をすることができる。妥当性確認が成功したとき、アプリケーションは、第１の要素に関係付けられているトークンシリアル番号を取り出し、例えば、インターネット、仮想私設ネットワーク等のようなネットワークを通して、中央バリデーションサービスに妥当性確認要求を送ることによって、第２の要素の妥当性確認をすることができる。第２の妥当性確認を実現するために、アプリケーションをホスト管理している企業は、バリデーションプロキシ（「認証エージェント」）を中央バリデーションサービスに配備してもよい。
【００１０】
図１は、本発明の実施形態にしたがった中央バリデーションサービスを示している。インターネットサービスプロバイダ（「ＩＳＰ」）１０１および銀行１０２は、ネットワーク１０４を通して中央バリデーションサービス１０３に結合されている。ＩＳＰ１０１は、ＩＳＰアプリケーション１０５と、ＩＳＰ認証エージェント１０６と、ＩＳＰユーザ記憶装置１０７とを備えていてもよい。ＩＳＰユーザ記憶装置は、第１の要素を、（ＩＳＰ顧客、アドミニストレータ、従業員等の識別子のような）ユーザの識別子と相関付ける、１つ以上の第１の要素およびユーザ識別子のデータベースであってもよい。銀行１０２は、銀行業務アプリケーション１０８と、銀行認証エージェント１０９と、銀行ユーザ記憶装置１１０とを備えていてもよい。銀行ユーザ記憶装置１１０は、第１の要素を、（銀行口座保持者、銀行行員、銀行ＩＴアドミニストレータ、銀行の従業員等のような）ユーザの識別子と相関付けるデータベースであってもよい。エンドユーザ１１１は、共有されているトークンをアクティブ化することができ、そして、トークンは、この例では、ＩＳＰ１０１と銀行１０２との間で共有される。ＩＳＰ１０１に対してユーザ自身を認証するために、エンドユーザ１１１は、ユーザ自身のＩＳＰユーザ名を入力してもよく、このケースでは、ユーザ名は、自身のｅメールアドレス、例えば、ｊｏｅ＠ｉｓｐ．ｃｏｍ．である。また、エンドユーザ１１１は、自身の関係するパスワード（例えば、「ｒｏｌｆ３６２」）と自身のトークンからのＯＴＰとを入力することができる。ＩＳＰは、ＩＳＰユーザ記憶装置１０７を調べることによって、エンドユーザ１１１によって提供されたユーザ名およびパスワードの妥当性確認をする。ユーザ記憶装置１０７中のレコードの例は、ユーザ名と、ユーザパスワードと、デバイス識別子とを含む。例えば、（ｊｏｅ＠ｉｓｐ．ｃｏｍ、「ｒｏｌｆ３６２」、２７５８２３４３）がある。ＩＳＰ１０１は、エンドユーザ１１１から受け取ったＯＴＰとユーザ記憶装置から取り出されたトークン識別子とを含む要求を中央バリデーションサービス１０３に送ることができる。中央バリデーションサービス１０３は、トークンバリデーションアプリケーション１１２とトークン記憶装置１１３とを備えていてもよい。トークン記憶装置１１３は、データベースであってもよく、このデータベースは、トークン識別子を、予め計算されたＯＴＰと、および／またはトークン識別子に関係付けられているトークン中に記憶されている１つ以上のシークレットと、および／またはトークンからのＯＴＰを確認するのに必要とされる他の情報と相関付けるものである。バリデーションアプリケーション１１２は、受け取ったＯＴＰをトークン記憶装置１１３から獲得された１つ以上のＯＴＰと比較することができ、および／またはトークン記憶装置１１３から獲得されたデータに基づいて、受け取ったＯＴＰとの比較のためのＯＴＰを計算することができる。中央バリデーションサービス１０３は、ＯＴＰの妥当性確認が成功したか、または成功しなかったことを示す応答メッセージをＩＳＰ１０１に送ることができる。エンドユーザ１１１からのユーザ名／パスワードおよびＯＴＰの双方の妥当性確認が成功した場合、ＩＳＰ１０１が、インターネットサービスをエンドユーザ１１１に提供することができる。
【００１１】
同様に、エンドユーザ１１１は、ユーザ名（例えば、ｊｓｍｉｔｈ＠ｂａｎｋ．ｃｏｍ）とパスワードとを銀行１０２に提供することができ、銀行１０２は、銀行ユーザ記憶装置１１０を使用して、ユーザ名およびパスワードの妥当性確認をすることができる。銀行１０２は、エンドユーザ１１１から受け取ったＯＴＰとトークン識別子とを中央バリデーションサービス１０３に送ることができ、中央バリデーションサービス１０３がこのＯＴＰおよびトークン識別子の有効性確認をし、応答メッセージを銀行に送ることができる。ユーザ名およびパスワードとＯＴＰとの双方の妥当性確認が成功した場合、銀行１０２は、エンドユーザ１１１口座情報と銀行業務サービスに対するアクセスをエンドユーザ１１１に提供することができる。
【００１２】
この例では、エンドユーザ１１１が、最初に、ＩＳＰ１０１、銀行１０２、または中央バリデーションサービス１０３のいずれかのものからのトークンを獲得することができる。各アプリケーションは、トランザクションに対する認証サービスおよび商品を当事者に提供する中央バリデーションサービスおよびトークン発行者に支払うことができる。
【００１３】
分散型バリデーションシステム
本発明の別の実施形態にしたがった分散型アーキテクチャを使用して、第２の要素の妥当性確認をすることができる。図２は、分散型バリデーションアーキテクチャの実施形態を示している。ＩＳＰ２０４および銀行１０２は、インターネットのようなネットワーク１０４を通して、トークンルックアップサービス２０１に結合されている。ＩＳＰ２０４はトークン記憶装置２０３を備えていてもよく、トークン記憶装置２０３はデータベースであってもよい。これは、トークン識別子を、予め計算されたＯＴＰと、および／またはトークン識別子に関係付けられているトークン中に記憶されている１つ以上のシークレットと、および／またはトークンからのＯＴＰを確認するのに必要とされる他の情報と相関付けるものである。この相関付けは、ＩＳＰ２０４におけるワンタイムパスワードバリデーションサーバ２０５において実現されてもよい。
【００１４】
トークンルックアップサービス２０１は、トークンマッピング記憶装置２０２を備えていてもよい。トークンマッピング記憶装置２０２は、トークンシリアル番号を、バリデーションサーバ２０５のネットワークアドレス（例えば、ＩＰアドレス）と相関付けるレコードを含むデータベースであってもよく、バリデーションサーバ２０５は、トークンからの第２の要素の証明書の妥当性確認をすることができる。このようなバリデーションサーバは、そのトークンシリアル番号に対する認証バリデーションノード（ＡＶＮ）である。いくつかのＡＶＮは、分散型バリデーションサーバのネットワークを備えていてもよい。トークンマッピング記憶装置において記憶されているレコードの例は、（ＩＰ−アドレス、Ｔｏｋｅｎ＿Ｉｄｅｎｔｉｆｉｅｒ）、例えば、（１２３．２１．３．１５６，１４５３４２２２０７）であってもよい。この例では、１２３．２１．３．１５６は、ワンタイムパスワードバリデーションサーバ２０５のネットワークアドレスであってもよく、１４５３４２２２０７は、ワンタイムパスワードがサーバ２０５によって妥当性確認されるべきトークンの識別子であってもよい。
【００１５】
図１中に示している例では、ＩＳＰ１０１は、トークンシリアル番号のリストまたは配列をトークンルックアップサービス２０１に登録することによって、トークン発行者として機能することができる。シリアル番号のリストまたは配列は、トークンマッピング記憶装置２０２中に記憶されていてもよく、トークンマッピング記憶装置２０２が、シリアル番号をＩＳＰ１０１のＩＰアドレスと相関付ける。銀行１０２は、信頼性のある当事者として機能する。銀行１０２によって提供される情報およびサービスに対するアクセスをエンドユーザ１１１が要求した（銀行が、トークンのユーザによってアクセスが試された「リソース」である）とき、エンドユーザ１１１が、第１および第２の認証要素とエンドユーザ１１１トークンのシリアル番号とを銀行１０２に提供する。銀行１０２は、銀行ユーザ記憶装置１１０を使用して、（ユーザ名およびパスワードのような）第１の要素の妥当性確認をすることができる。これは、銀行１０２、例えば、認証エージェント１０９が実現されるサーバにおいて、リソースバリデーションサーバを使用して実現されてもよい。リソースバリデーションサーバは、ジョーのユーザ名とトークンシリアル番号との間のマッピングをローカルユーザ記憶装置中に記憶することができる。また、リソースバリデーションサーバは、トークンのＡＶＮ情報をローカル的にキャッシュすることができる。リソースバリデーションサーバはＤＮＳキャッシングに対して実現されるとき、キャッシングが実現されてもよい。
【００１６】
また、銀行１０２は、エンドユーザ１１１によって提供されるトークンシリアル番号を含む要求をトークンルックアップサービス２０１に送ることができる。トークンマッピング記憶装置２０２は、トークンシリアル番号をＡＶＮ ＩＰアドレスと相関付け、この例では、ＡＶＮ ＩＰアドレスはＩＳＰ１０１のＩＰアドレスである。トークンルックアップサービス２０１はＡＶＮ（ＩＳＰ１０１）のＩＰアドレスを銀行１０２に返すことができる。ＩＳＰ１０１は、トークン記憶装置２０３とトークンバリデーションアプリケーション２０５を備えていてもよい。銀行１０２は妥当性確認要求をＩＳＰ１０１に送ることができ、ＩＳＰ１０１は、トークンバリデーションアプリケーション２０５とトークン記憶装置２０３とを使用して、第２の要素の妥当性確認をすることができる。ＩＳＰ１０１は、応答メッセージにおいて、妥当性確認の結果を銀行１０２に送ることができる。
【００１７】
図２中に示されている例では、エンドユーザ１１１は、自身のユーザ名（ｊｏｅ＠ｉｓｐ．ｃｏｍ）、自身の関係するパスワード（「ｒｏｌｆ３６２」）および自身のトークンからのＯＴＰを使用して、自身のＩＳＰに対して認証することができる。ＩＳＰおよび銀行の双方は分散型バリデーションサービスを実現するので、エンドユーザ１１１は、自身のユーザ名（ｊｓｍｉｔｈ＠ｂａｎｋ．ｃｏｍ）、関係するパスワード（「Ｒｏｌｆ３６２」）および自身のＩＳＰ発行トークンからのＯＴＰを利用して、銀行１０２において自身のオンライン銀行業務アプリケーションにログインすることができる。
【００１８】
トークン発行者、信頼性のある当事者およびトークンルックアップサービス２０１は、必要に応じて、互いに自身を認証することができる。このことは、第２の要素の妥当性確認に対する認証機能および請求機能を当事者が取り入れることを可能にし、１組の豊富なビジネスモデルが可能になる。
【００１９】
クレデンシャルウォレット
本発明の別の実施形態にしたがうと、Ｊａｖａ（登録商標）セル電話機のような次世代移動体デバイス、ならびに、記憶およびアプリケーション能力を備えているＰＤＡ、ならびに、証明書を管理する何らかの形態のグラフィックインターフェイスに対して、クレデンシャルウォレットモデルに影響を及ぼす。この実施形態では、移動体デバイスは、第２の要素の信用証明書の複数のインスタンスを含むことが可能な「ウォレット」であってもよい。強力な認証を必要とする各サイトに対して、適切な１つまたは複数の信用証明書にアクセスすることができる。
【００２０】
図３中に示されている例では、（示されていない）エンドユーザ１１１の移動体電話機が、異なるアプリケーションおよび／またはサイトに対して提供されている異なるＯＴＰ信用証明書を持っていてもよい。エンドユーザ１１１は、自身のＩＳＰユーザ名（例えば、ｊｏｅ＠ｉｓｐ．ｃｏｍ）、関係するパスワード（「ｒｏｌｆ３６２」）およびＩＳＰ３０１に対する適切なＯＴＰ値を使用することによって、ＩＳＰ３０１にログインすることができる。ＩＳＰ３０１に対する第２の要素は、ＩＳＰバリデーションアプリケーション３０３およびトークン記憶装置２０３を使用して、妥当性確認することができる。エンドユーザ１１１は、図４中に示しているように、ＩＳＰ３０１に対する適切なＯＴＰ値を獲得することができる。エンドユーザ１１１は、セル電話機４０３のディスプレイスクリーン４０２上に示されている適切なアイコンにカーソル４０１をスクロールすることができる。エンドユーザ１１１にＰＩＮ４０４を入力するように依頼し、ＰＩＮは、セル電話機４０３によって妥当性確認をすることができる。ＰＩＮの妥当性確認が成功すると、ＯＴＰ値４０５がスクリーン４０２上に表示される。
【００２１】
エンドユーザ１１１は、自身のユーザ名（例えば、ｊｓｍｉｔｈ＠ｂａｎｋ．ｃｏｍ）、関係するパスワード（「ｒｏｌｆ３２」）、およびエンドユーザ１１１のセル電話機によって発生されるような、自身の銀行のＯＴＰトークンからのＯＴＰ値を使用することによって、自身のオンライン銀行口座にログオンすることができる。銀行３０２に対する第２の要素は、銀行バリデーションアプリケーション３０４およびトークン記憶装置３０５を使用して、妥当性確認をすることができる。
【００２２】
このクレデンシャルウォレットの実施形態では、各エンティティは、各エンティティ自体の第１および第２の要素の認証インフラストラクチャを配備することができる。トークン自体が共有されていないので、外部認証／妥当性確認の当事者による依存性はない。むしろ、適切なソフトウェアを備えているセル電話機のような、共通のトークンを発生させるデバイスをさまざまなトークンが「共有」している。
【００２３】
先に説明した実施形態のそれぞれは、共存することが可能であり、そして同一の認証ネットワークに参加できるように組み込むことが可能である。各実施形態は、共通の目的状態に向けた進化的プロセスの一部分として、単独で配備することができ、各実施形態は、信頼されて、フレキシブルで、経済的で、使用しやすい、消費者アプリケーション向けの認証システムである。
【００２４】
本発明の実施形態は、信用証明書の識別子を使用している複数のシステムにわたって、さまざまなデバイスのユーザおよび／または信用証明書を関係付けて認証することができる。信用証明書の識別子は、（名前またはＥメールアドレスのような）ユーザの識別子であってもよく、また、（数字のような）匿名の識別子であってもよい。匿名の識別子は、（ユーザ名および／またはトークン識別子のハッシング、信用証明書の照会のような）１組のユーザ識別子の一方向変換の結果のような内部（ｏｐａｑｕｅ）識別子である。
【００２５】
本発明の実施形態は、内部識別子を真の識別子から発生させるアノニマイザサービスをサポートすることができる。さらに、信頼性のある異なる当事者によって、同一のデバイスに対して、異なった信用証明書の識別子を同一のユーザに使用することができる。信用証明書は、プライバシーを保護する方法で、例えば、ランダム化（純粋なランダム化、ランダム暗号化等）またはユーザの追跡を回避する何らかの適したプロセスを使用することによって送信されてもよい。
【００２６】
本発明の実施形態にしたがった方法は、トークンＩＤ、すなわちトークンルックアップサービスに基づいて、正確な妥当性確認ノードを見つけるサービスを説明することができる。トークンルックアップサービスは、トークンバリデーションノードに対してトークン識別子をマッピングするリストを管理することができる。各トークンに対して、１つより多いトークン識別子があってもよい。認証された当事者は、トークンルックアップサービスに問い合わせて、正確な妥当性確認ノードをサービスごとに決定することができる。本発明は、複数のデバイスおよび複数の認証アルゴリズムによってワークを動作させることができる。本発明は、デスクトップＰＣ上のソフトウェア、移動体デバイス上のソフトウェア、専用ハードウェア、あるいは他の何らかの適切なプラットフォームで実現されてもよい。
【００２７】
本発明は、信用証明書および認証アルゴリズムに基づいて、ワンタイムパスワード、チャレンジ／応答およびＰＫＩ（デジタル証明書）を使用することができる。匿名のデバイスおよび信用証明書、ならびにパーソナル識別子を含んでいるデバイスおよび信用証明書を使用することができる。
【００２８】
本発明の実施形態は中央サービスを含んでおり、この中央サービスによって、複数の信頼性のある当事者が、同一の認証デバイスまたは信用証明書に対する妥当性確認要求を送ることが可能になる。
【００２９】
本発明の実施形態は、「トークンウォレット」に使用されてもよい。これらのウォレットには、異なるサービスに対する複数の信用証明書が含まれていてもよい。ウォレットにおける各信用証明書は、複数のサービスによって使用することができる。ウォレットは、１つより多い共有されている信用証明書、共有されていない信用証明書、ならびにＯＴＰ信用証明書、デジタル証明書、チャレンジおよび応答の信用証明書等のような複数のタイプの信用証明書を含んでいてもよい。ウォレットには、１つより多い各タイプの信用証明書が含まれていてもよく、または、何らかのタイプの信用証明書がまったく含まれていなくてもよい。
【００３０】
本発明の実施形態は、中央メンテナンス機能を備えていてもよい。信用証明書が紛失されたり、壊されたり、盗用された場合、すべてのアプリケーションにわたって、トークンを単一の動作でディセーブルすることができる。信用証明書が無効にされたり、または悪用された場合、アドミニストレータが、すべてのアプリケーションまたは指定されたサブセットのアプリケーションにわたって信用証明書をディセーブルすることができる。これもまた単一の動作で実行することができる。
【００３１】
前述のものは、本発明の例示を意味しており、本発明の範囲を限定するものではないことを意味している。上記に明示的に記述されていない他の実施形態は、当業者によって正しく認識されるように特許請求の範囲によって含まれている。
【図面の簡単な説明】
【００３２】
【図１】図１は、本発明の実施形態にしたがった中央バリデーションサービスを示している。
【図２】図２は、本発明の実施形態にしたがった分散型バリデーションサービスを示している。
【図３】図３は、本発明の実施形態にしたがったクレデンシャルウォレットアーキテクチャを示している。
【図４】図４は、本発明の実施形態にしたがって、複数のトークンを発生させることができる単一のデバイスのセル電話機のインプリメンテーションを示している。
【関連出願の相互参照】
【０００１】
本出願は、２００５年５月６日に出願された米国仮特許出願シリアル番号第６０／６７８，２１４号の利益を主張している。この特許出願の開示は、その全体が参照によりここに組み込まれている。
【発明の分野】
【０００２】
本発明の分野は、コンピュータの安全性、特に、認証である。
【本発明の背景】
【０００３】
企業は、自身のデータおよび情報技術の機密性、完全性および保証されたサービスを保護するために強力な認証技術を使用していることで知られている。この認証技術は、デジタル証明書を各従業員に発行することや、トークンを各従業員に提供すること等を含むさまざまな方法を使用して実現されている。企業向けの強力な認証は、比較的、実現しやすい。その理由は、一般的に、単一性のエンティティが存在し、制御されるグループのユーザが、単一性のエンティティに対して、ユーザ自身、すなわち企業自身を認証しなければならないからである。
【０００４】
消費者適用に対して強力な認証技術を適用することは困難である。デジタル証明書およびトークンは、小売商のような他のエンティティと消費者との対話に対する妨げであると認識されていたり、消費者も他のエンティティも自発的に負担しようとしない費用であったりする。しかしながら、識別子の盗用、フィッシング、中間者攻撃、およびクレジットカードの盗難のような、ハッカーによってもたらされる脅威がますます巧妙化し、与えられる損害が大きくなる観点から、いくつかの強力な認証技術を積極的に取り入れようとする消費者の意向は、増すものと予期することができる。これは、オンラインで行われる商取引および他の活動の量が年々増加することによってさらに強まる。
【０００５】
実際には、危険に対する未解決の脅威および不愉快な出来事の結果として生じた蓄積そのものが、消費者活動のオンライン環境への継続的移行に対する現代の障害であると考えられる。より強力な認証が消費者に対して必要であるが、ある既知の解決策を実現することは困難である。例えば、大部分の企業のクライアントとは異なった方法で、消費者は、幅広いさまざまなエンティティに対して消費者自体を認証しなければならない。消費者は、一般的に、異なるエンティティに関係付けられている異なる認証証明書を常に監視することを望まない。例えば、多くの消費者は、銀行、クレジットカード、サービスプロバイダ、医療および役所の複数の口座を持っている。消費者による強力な認証から、これらのそれぞれの口座は利益を得る。このケースでは、口座ごとに１つの認証デバイスが消費者に発行される場合、消費者のポケットまたはキーリングがデバイスでいっぱいになる。これは、消費者にとって望ましくないことである。
【０００６】
必要とされるものは、幅広い企業に対して消費者自体を認証するために、消費者によって使用することが可能な共有トークンを使用して、動作可能である認証システムおよび方法である。多くのサイトにわたって単一のトークンを共有できる場合、消費者は、セル電話機、車のキーまたはクレジットカードとほとんど同じように、必要なパーソナルツールとしてこれらを携帯し始める可能性が非常に高い。
【詳細な説明】
【０００７】
ここで用いているような「識別子の共有」は、トークンの保持者のパーソナル識別子を認証する能力を共有することを意味している。「第２の要素の共有」は、トークンに関係付けられているエリアスを認証する能力を共有することを意味している。例えば、２要素認証システムは、パーソナル識別番号（「ＰＩＮ」、すなわち「第１の要素」）とワンタイムパスワード（「ＯＴＰ」、すなわち「第２の要素」）とを含んでいてもよい。ＰＩＮは、トークンの個人保持者と認証システムとの間で共有されるシークレットである。特定のＯＴＰは、一連の数字のうちの１つであってもよく、一連の数字は、所定のトークンによってのみに一意的に発生されたり、認証システムによってチェックすることができる。認証システムがＰＩＮをユーザから受け取って確認したとき、そのユーザはその特定のＰＩＮと相関付けられているので、システムはユーザを認証することができる。同様に、認証システムがＯＴＰをトークンから受け取って確認したとき、そのトークンはその特定のＯＴＰと相関付けられているので、認証システムはトークンを認証することができる。識別子共有システムにおいて、いくつかのエンティティのうちの何らかのものが、例えば、ＰＩＮに基づいて、またはＰＩＮとＯＴＰとに基づいて、ユーザの識別子を認証することができる。第２の要素の共有システムにおいて、いくつかのエンティティのうちの何らかのものが、ＯＴＰを使用して、トークン自体を認証することができる。例として、２要素認証デバイスを使用して、識別子および第２の要素の共有について説明しているが、本発明にしたがうと、あらゆる認証スキームを使用することができる。例えば、デジタル証明書および／またはチャンレンジ−応答スキームを第２の要素の共有に使用することができる。
【０００８】
中央トークンサービスモデル
本発明の実施形態にしたがった中央トークンサービスインフラストラクチャは、例えば、ハードウェアトークン上に記憶および／またはハードウェアトークンによって実現される、証明書またはＯＴＰのような、第２の要素の信用証明書を提供したり妥当性確認をしたりするために使用される。第２の要素を実現するトークンは、さまざまなアプリケーションおよび／またはウェブサイトのうちの任意のものにおいてアクティブ化されてもよい。アプリケーション自体のユーザデータベースにおいて、ユーザ名およびパスワードのような第１の要素をアプリケーションが管理することができる。トークンのアクティブ化の一部分として、アプリケーションは、ローカルユーザ名と、トークンシリアル番号のような共有される第２の要素のトークン識別子との間のマッピングを記憶することができる。
【０００９】
妥当性確認のために、ユーザは、ユーザ名およびパスワードのような第１の要素と、トークンからのＯＴＰまたはトークン上に記憶されている証明書のような第２の要素とを入力することができる。アプリケーションは、ローカル的に、第１の要素の妥当性確認をすることができる。妥当性確認が成功したとき、アプリケーションは、第１の要素に関係付けられているトークンシリアル番号を取り出し、例えば、インターネット、仮想私設ネットワーク等のようなネットワークを通して、中央バリデーションサービスに妥当性確認要求を送ることによって、第２の要素の妥当性確認をすることができる。第２の妥当性確認を実現するために、アプリケーションをホスト管理している企業は、バリデーションプロキシ（「認証エージェント」）を中央バリデーションサービスに配備してもよい。
【００１０】
図１は、本発明の実施形態にしたがった中央バリデーションサービスを示している。インターネットサービスプロバイダ（「ＩＳＰ」）１０１および銀行１０２は、ネットワーク１０４を通して中央バリデーションサービス１０３に結合されている。ＩＳＰ１０１は、ＩＳＰアプリケーション１０５と、ＩＳＰ認証エージェント１０６と、ＩＳＰユーザ記憶装置１０７とを備えていてもよい。ＩＳＰユーザ記憶装置は、第１の要素を、（ＩＳＰ顧客、アドミニストレータ、従業員等の識別子のような）ユーザの識別子と相関付ける、１つ以上の第１の要素およびユーザ識別子のデータベースであってもよい。銀行１０２は、銀行業務アプリケーション１０８と、銀行認証エージェント１０９と、銀行ユーザ記憶装置１１０とを備えていてもよい。銀行ユーザ記憶装置１１０は、第１の要素を、（銀行口座保持者、銀行行員、銀行ＩＴアドミニストレータ、銀行の従業員等のような）ユーザの識別子と相関付けるデータベースであってもよい。エンドユーザ１１１は、共有されているトークンをアクティブ化することができ、そして、トークンは、この例では、ＩＳＰ１０１と銀行１０２との間で共有される。ＩＳＰ１０１に対してユーザ自身を認証するために、エンドユーザ１１１は、ユーザ自身のＩＳＰユーザ名を入力してもよく、このケースでは、ユーザ名は、自身のｅメールアドレス、例えば、ｊｏｅ＠ｉｓｐ．ｃｏｍ．である。また、エンドユーザ１１１は、自身の関係するパスワード（例えば、「ｒｏｌｆ３６２」）と自身のトークンからのＯＴＰとを入力することができる。ＩＳＰは、ＩＳＰユーザ記憶装置１０７を調べることによって、エンドユーザ１１１によって提供されたユーザ名およびパスワードの妥当性確認をする。ユーザ記憶装置１０７中のレコードの例は、ユーザ名と、ユーザパスワードと、デバイス識別子とを含む。例えば、（ｊｏｅ＠ｉｓｐ．ｃｏｍ、「ｒｏｌｆ３６２」、２７５８２３４３）がある。ＩＳＰ１０１は、エンドユーザ１１１から受け取ったＯＴＰとユーザ記憶装置から取り出されたトークン識別子とを含む要求を中央バリデーションサービス１０３に送ることができる。中央バリデーションサービス１０３は、トークンバリデーションアプリケーション１１２とトークン記憶装置１１３とを備えていてもよい。トークン記憶装置１１３は、データベースであってもよく、このデータベースは、トークン識別子を、予め計算されたＯＴＰと、および／またはトークン識別子に関係付けられているトークン中に記憶されている１つ以上のシークレットと、および／またはトークンからのＯＴＰを確認するのに必要とされる他の情報と相関付けるものである。バリデーションアプリケーション１１２は、受け取ったＯＴＰをトークン記憶装置１１３から獲得された１つ以上のＯＴＰと比較することができ、および／またはトークン記憶装置１１３から獲得されたデータに基づいて、受け取ったＯＴＰとの比較のためのＯＴＰを計算することができる。中央バリデーションサービス１０３は、ＯＴＰの妥当性確認が成功したか、または成功しなかったことを示す応答メッセージをＩＳＰ１０１に送ることができる。エンドユーザ１１１からのユーザ名／パスワードおよびＯＴＰの双方の妥当性確認が成功した場合、ＩＳＰ１０１が、インターネットサービスをエンドユーザ１１１に提供することができる。
【００１１】
同様に、エンドユーザ１１１は、ユーザ名（例えば、ｊｓｍｉｔｈ＠ｂａｎｋ．ｃｏｍ）とパスワードとを銀行１０２に提供することができ、銀行１０２は、銀行ユーザ記憶装置１１０を使用して、ユーザ名およびパスワードの妥当性確認をすることができる。銀行１０２は、エンドユーザ１１１から受け取ったＯＴＰとトークン識別子とを中央バリデーションサービス１０３に送ることができ、中央バリデーションサービス１０３がこのＯＴＰおよびトークン識別子の有効性確認をし、応答メッセージを銀行に送ることができる。ユーザ名およびパスワードとＯＴＰとの双方の妥当性確認が成功した場合、銀行１０２は、エンドユーザ１１１口座情報と銀行業務サービスに対するアクセスをエンドユーザ１１１に提供することができる。
【００１２】
この例では、エンドユーザ１１１が、最初に、ＩＳＰ１０１、銀行１０２、または中央バリデーションサービス１０３のいずれかのものからのトークンを獲得することができる。各アプリケーションは、トランザクションに対する認証サービスおよび商品を当事者に提供する中央バリデーションサービスおよびトークン発行者に支払うことができる。
【００１３】
分散型バリデーションシステム
本発明の別の実施形態にしたがった分散型アーキテクチャを使用して、第２の要素の妥当性確認をすることができる。図２は、分散型バリデーションアーキテクチャの実施形態を示している。ＩＳＰ２０４および銀行１０２は、インターネットのようなネットワーク１０４を通して、トークンルックアップサービス２０１に結合されている。ＩＳＰ２０４はトークン記憶装置２０３を備えていてもよく、トークン記憶装置２０３はデータベースであってもよい。これは、トークン識別子を、予め計算されたＯＴＰと、および／またはトークン識別子に関係付けられているトークン中に記憶されている１つ以上のシークレットと、および／またはトークンからのＯＴＰを確認するのに必要とされる他の情報と相関付けるものである。この相関付けは、ＩＳＰ２０４におけるワンタイムパスワードバリデーションサーバ２０５において実現されてもよい。
【００１４】
トークンルックアップサービス２０１は、トークンマッピング記憶装置２０２を備えていてもよい。トークンマッピング記憶装置２０２は、トークンシリアル番号を、バリデーションサーバ２０５のネットワークアドレス（例えば、ＩＰアドレス）と相関付けるレコードを含むデータベースであってもよく、バリデーションサーバ２０５は、トークンからの第２の要素の証明書の妥当性確認をすることができる。このようなバリデーションサーバは、そのトークンシリアル番号に対する認証バリデーションノード（ＡＶＮ）である。いくつかのＡＶＮは、分散型バリデーションサーバのネットワークを備えていてもよい。トークンマッピング記憶装置において記憶されているレコードの例は、（ＩＰ−アドレス、Ｔｏｋｅｎ＿Ｉｄｅｎｔｉｆｉｅｒ）、例えば、（１２３．２１．３．１５６，１４５３４２２２０７）であってもよい。この例では、１２３．２１．３．１５６は、ワンタイムパスワードバリデーションサーバ２０５のネットワークアドレスであってもよく、１４５３４２２２０７は、ワンタイムパスワードがサーバ２０５によって妥当性確認されるべきトークンの識別子であってもよい。
【００１５】
図１中に示している例では、ＩＳＰ１０１は、トークンシリアル番号のリストまたは配列をトークンルックアップサービス２０１に登録することによって、トークン発行者として機能することができる。シリアル番号のリストまたは配列は、トークンマッピング記憶装置２０２中に記憶されていてもよく、トークンマッピング記憶装置２０２が、シリアル番号をＩＳＰ１０１のＩＰアドレスと相関付ける。銀行１０２は、信頼性のある当事者として機能する。銀行１０２によって提供される情報およびサービスに対するアクセスをエンドユーザ１１１が要求した（銀行が、トークンのユーザによってアクセスが試された「リソース」である）とき、エンドユーザ１１１が、第１および第２の認証要素とエンドユーザ１１１トークンのシリアル番号とを銀行１０２に提供する。銀行１０２は、銀行ユーザ記憶装置１１０を使用して、（ユーザ名およびパスワードのような）第１の要素の妥当性確認をすることができる。これは、銀行１０２、例えば、認証エージェント１０９が実現されるサーバにおいて、リソースバリデーションサーバを使用して実現されてもよい。リソースバリデーションサーバは、ジョーのユーザ名とトークンシリアル番号との間のマッピングをローカルユーザ記憶装置中に記憶することができる。また、リソースバリデーションサーバは、トークンのＡＶＮ情報をローカル的にキャッシュすることができる。リソースバリデーションサーバはＤＮＳキャッシングに対して実現されるとき、キャッシングが実現されてもよい。
【００１６】
また、銀行１０２は、エンドユーザ１１１によって提供されるトークンシリアル番号を含む要求をトークンルックアップサービス２０１に送ることができる。トークンマッピング記憶装置２０２は、トークンシリアル番号をＡＶＮ ＩＰアドレスと相関付け、この例では、ＡＶＮ ＩＰアドレスはＩＳＰ１０１のＩＰアドレスである。トークンルックアップサービス２０１はＡＶＮ（ＩＳＰ１０１）のＩＰアドレスを銀行１０２に返すことができる。ＩＳＰ１０１は、トークン記憶装置２０３とトークンバリデーションアプリケーション２０５を備えていてもよい。銀行１０２は妥当性確認要求をＩＳＰ１０１に送ることができ、ＩＳＰ１０１は、トークンバリデーションアプリケーション２０５とトークン記憶装置２０３とを使用して、第２の要素の妥当性確認をすることができる。ＩＳＰ１０１は、応答メッセージにおいて、妥当性確認の結果を銀行１０２に送ることができる。
【００１７】
図２中に示されている例では、エンドユーザ１１１は、自身のユーザ名（ｊｏｅ＠ｉｓｐ．ｃｏｍ）、自身の関係するパスワード（「ｒｏｌｆ３６２」）および自身のトークンからのＯＴＰを使用して、自身のＩＳＰに対して認証することができる。ＩＳＰおよび銀行の双方は分散型バリデーションサービスを実現するので、エンドユーザ１１１は、自身のユーザ名（ｊｓｍｉｔｈ＠ｂａｎｋ．ｃｏｍ）、関係するパスワード（「Ｒｏｌｆ３６２」）および自身のＩＳＰ発行トークンからのＯＴＰを利用して、銀行１０２において自身のオンライン銀行業務アプリケーションにログインすることができる。
【００１８】
トークン発行者、信頼性のある当事者およびトークンルックアップサービス２０１は、必要に応じて、互いに自身を認証することができる。このことは、第２の要素の妥当性確認に対する認証機能および請求機能を当事者が取り入れることを可能にし、１組の豊富なビジネスモデルが可能になる。
【００１９】
クレデンシャルウォレット
本発明の別の実施形態にしたがうと、Ｊａｖａ（登録商標）セル電話機のような次世代移動体デバイス、ならびに、記憶およびアプリケーション能力を備えているＰＤＡ、ならびに、証明書を管理する何らかの形態のグラフィックインターフェイスに対して、クレデンシャルウォレットモデルに影響を及ぼす。この実施形態では、移動体デバイスは、第２の要素の信用証明書の複数のインスタンスを含むことが可能な「ウォレット」であってもよい。強力な認証を必要とする各サイトに対して、適切な１つまたは複数の信用証明書にアクセスすることができる。
【００２０】
図３中に示されている例では、（示されていない）エンドユーザ１１１の移動体電話機が、異なるアプリケーションおよび／またはサイトに対して提供されている異なるＯＴＰ信用証明書を持っていてもよい。エンドユーザ１１１は、自身のＩＳＰユーザ名（例えば、ｊｏｅ＠ｉｓｐ．ｃｏｍ）、関係するパスワード（「ｒｏｌｆ３６２」）およびＩＳＰ３０１に対する適切なＯＴＰ値を使用することによって、ＩＳＰ３０１にログインすることができる。ＩＳＰ３０１に対する第２の要素は、ＩＳＰバリデーションアプリケーション３０３およびトークン記憶装置２０３を使用して、妥当性確認することができる。エンドユーザ１１１は、図４中に示しているように、ＩＳＰ３０１に対する適切なＯＴＰ値を獲得することができる。エンドユーザ１１１は、セル電話機４０３のディスプレイスクリーン４０２上に示されている適切なアイコンにカーソル４０１をスクロールすることができる。エンドユーザ１１１にＰＩＮ４０４を入力するように依頼し、ＰＩＮは、セル電話機４０３によって妥当性確認をすることができる。ＰＩＮの妥当性確認が成功すると、ＯＴＰ値４０５がスクリーン４０２上に表示される。
【００２１】
エンドユーザ１１１は、自身のユーザ名（例えば、ｊｓｍｉｔｈ＠ｂａｎｋ．ｃｏｍ）、関係するパスワード（「ｒｏｌｆ３２」）、およびエンドユーザ１１１のセル電話機によって発生されるような、自身の銀行のＯＴＰトークンからのＯＴＰ値を使用することによって、自身のオンライン銀行口座にログオンすることができる。銀行３０２に対する第２の要素は、銀行バリデーションアプリケーション３０４およびトークン記憶装置３０５を使用して、妥当性確認をすることができる。
【００２２】
このクレデンシャルウォレットの実施形態では、各エンティティは、各エンティティ自体の第１および第２の要素の認証インフラストラクチャを配備することができる。トークン自体が共有されていないので、外部認証／妥当性確認の当事者による依存性はない。むしろ、適切なソフトウェアを備えているセル電話機のような、共通のトークンを発生させるデバイスをさまざまなトークンが「共有」している。
【００２３】
先に説明した実施形態のそれぞれは、共存することが可能であり、そして同一の認証ネットワークに参加できるように組み込むことが可能である。各実施形態は、共通の目的状態に向けた進化的プロセスの一部分として、単独で配備することができ、各実施形態は、信頼されて、フレキシブルで、経済的で、使用しやすい、消費者アプリケーション向けの認証システムである。
【００２４】
本発明の実施形態は、信用証明書の識別子を使用している複数のシステムにわたって、さまざまなデバイスのユーザおよび／または信用証明書を関係付けて認証することができる。信用証明書の識別子は、（名前またはＥメールアドレスのような）ユーザの識別子であってもよく、また、（数字のような）匿名の識別子であってもよい。匿名の識別子は、（ユーザ名および／またはトークン識別子のハッシング、信用証明書の照会のような）１組のユーザ識別子の一方向変換の結果のような内部（ｏｐａｑｕｅ）識別子である。
【００２５】
本発明の実施形態は、内部識別子を真の識別子から発生させるアノニマイザサービスをサポートすることができる。さらに、信頼性のある異なる当事者によって、同一のデバイスに対して、異なった信用証明書の識別子を同一のユーザに使用することができる。信用証明書は、プライバシーを保護する方法で、例えば、ランダム化（純粋なランダム化、ランダム暗号化等）またはユーザの追跡を回避する何らかの適したプロセスを使用することによって送信されてもよい。
【００２６】
本発明の実施形態にしたがった方法は、トークンＩＤ、すなわちトークンルックアップサービスに基づいて、正確な妥当性確認ノードを見つけるサービスを説明することができる。トークンルックアップサービスは、トークンバリデーションノードに対してトークン識別子をマッピングするリストを管理することができる。各トークンに対して、１つより多いトークン識別子があってもよい。認証された当事者は、トークンルックアップサービスに問い合わせて、正確な妥当性確認ノードをサービスごとに決定することができる。本発明は、複数のデバイスおよび複数の認証アルゴリズムによってワークを動作させることができる。本発明は、デスクトップＰＣ上のソフトウェア、移動体デバイス上のソフトウェア、専用ハードウェア、あるいは他の何らかの適切なプラットフォームで実現されてもよい。
【００２７】
本発明は、信用証明書および認証アルゴリズムに基づいて、ワンタイムパスワード、チャレンジ／応答およびＰＫＩ（デジタル証明書）を使用することができる。匿名のデバイスおよび信用証明書、ならびにパーソナル識別子を含んでいるデバイスおよび信用証明書を使用することができる。
【００２８】
本発明の実施形態は中央サービスを含んでおり、この中央サービスによって、複数の信頼性のある当事者が、同一の認証デバイスまたは信用証明書に対する妥当性確認要求を送ることが可能になる。
【００２９】
本発明の実施形態は、「トークンウォレット」に使用されてもよい。これらのウォレットには、異なるサービスに対する複数の信用証明書が含まれていてもよい。ウォレットにおける各信用証明書は、複数のサービスによって使用することができる。ウォレットは、１つより多い共有されている信用証明書、共有されていない信用証明書、ならびにＯＴＰ信用証明書、デジタル証明書、チャレンジおよび応答の信用証明書等のような複数のタイプの信用証明書を含んでいてもよい。ウォレットには、１つより多い各タイプの信用証明書が含まれていてもよく、または、何らかのタイプの信用証明書がまったく含まれていなくてもよい。
【００３０】
本発明の実施形態は、中央メンテナンス機能を備えていてもよい。信用証明書が紛失されたり、壊されたり、盗用された場合、すべてのアプリケーションにわたって、トークンを単一の動作でディセーブルすることができる。信用証明書が無効にされたり、または悪用された場合、アドミニストレータが、すべてのアプリケーションまたは指定されたサブセットのアプリケーションにわたって信用証明書をディセーブルすることができる。これもまた単一の動作で実行することができる。
【００３１】
前述のものは、本発明の例示を意味しており、本発明の範囲を限定するものではないことを意味している。上記に明示的に記述されていない他の実施形態は、当業者によって正しく認識されるように特許請求の範囲によって含まれている。
【図面の簡単な説明】
【００３２】
【図１】図１は、本発明の実施形態にしたがった中央バリデーションサービスを示している。
【図２】図２は、本発明の実施形態にしたがった分散型バリデーションサービスを示している。
【図３】図３は、本発明の実施形態にしたがったクレデンシャルウォレットアーキテクチャを示している。
【図４】図４は、本発明の実施形態にしたがって、複数のトークンを発生させることができる単一のデバイスのセル電話機のインプリメンテーションを示している。
【特許請求の範囲】
【請求項１】
認証システムにおいて、
識別子を有し、ワンタイムパスワードを発生させるように構成および配置されているトークンと、
トークンによって発生されたワンタイムパスワードの妥当性確認をするように構成および配置され、ネットワークアドレスを有しているワンタイムパスワードバリデーションサーバと、
トークン識別子をバリデーションサーバのネットワークのロケーションと相関付けるように構成および配置されているトークンルックアップサービスと、
トークンのユーザによって提供された少なくとも第１の認証要素の妥当性確認をし、第１の要素の妥当性確認が成功した場合、ワンタイムパスワードバリデーションサーバのロケーションに対する要求をトークンルックアップサーバに送り、ワンタイムパスワードバリデーション要求をワンタイムパスワードバリデーションサーバに送るように構成および配置されているリソースバリデーションサーバとを具備する認証システム。
【請求項２】
トークンのユーザによって提供された第１の認証要素は、ユーザ名を含む請求項１記載のシステム。
【請求項３】
トークンのユーザによって提供された第１の認証要素は、トークンのユーザとリソースバリデーションサービスとの間で共有されるシークレットを含む請求項１記載のシステム。
【請求項４】
プロセッサと、
プロセッサに結合されているメモリとを具備し、
プロセッサおよびメモリは、ワンタイムパスワードバリデーションサーバのネットワークアドレスとトークン識別子とを記憶するように構成および配置され、
ワンタイムパスワードバリデーションサーバは、トークン識別子に対応しているトークンによって発生されるワンタイムパスワードの妥当性確認をするように構成および配置されているトークンルックアップサーバ。
【請求項５】
プロセッサおよびメモリは、
トークンのワンタイムパスワードバリデーションサーバのネットワークアドレスに対する要求であって、トークンに対応しているトークン識別子を含む要求を受け取り、
受け取ったトークン識別子に対応するネットワークアドレスを決定し、
要求に応答して、決定されたネットワークアドレスを送るようにさらに構成および適合されている請求項４記載のトークンルックアップサーバ。
【請求項６】
認証する方法において、
トークンルックアップサービスにおいて、ワンタイムパスワードバリデーションサーバのネットワークアドレスに対する要求であって、トークン識別子を含む要求を受け取ることと、
ワンタイムパスワードバリデーションサーバと受け取ったトークン識別子とに対応しているネットワークアドレスを決定することと、
要求に応答して、ネットワークアドレスを送ることとを含む方法。
【請求項１】
認証システムにおいて、
識別子を有し、ワンタイムパスワードを発生させるように構成および配置されているトークンと、
トークンによって発生されたワンタイムパスワードの妥当性確認をするように構成および配置され、ネットワークアドレスを有しているワンタイムパスワードバリデーションサーバと、
トークン識別子をバリデーションサーバのネットワークのロケーションと相関付けるように構成および配置されているトークンルックアップサービスと、
トークンのユーザによって提供された少なくとも第１の認証要素の妥当性確認をし、第１の要素の妥当性確認が成功した場合、ワンタイムパスワードバリデーションサーバのロケーションに対する要求をトークンルックアップサーバに送り、ワンタイムパスワードバリデーション要求をワンタイムパスワードバリデーションサーバに送るように構成および配置されているリソースバリデーションサーバとを具備する認証システム。
【請求項２】
トークンのユーザによって提供された第１の認証要素は、ユーザ名を含む請求項１記載のシステム。
【請求項３】
トークンのユーザによって提供された第１の認証要素は、トークンのユーザとリソースバリデーションサービスとの間で共有されるシークレットを含む請求項１記載のシステム。
【請求項４】
プロセッサと、
プロセッサに結合されているメモリとを具備し、
プロセッサおよびメモリは、ワンタイムパスワードバリデーションサーバのネットワークアドレスとトークン識別子とを記憶するように構成および配置され、
ワンタイムパスワードバリデーションサーバは、トークン識別子に対応しているトークンによって発生されるワンタイムパスワードの妥当性確認をするように構成および配置されているトークンルックアップサーバ。
【請求項５】
プロセッサおよびメモリは、
トークンのワンタイムパスワードバリデーションサーバのネットワークアドレスに対する要求であって、トークンに対応しているトークン識別子を含む要求を受け取り、
受け取ったトークン識別子に対応するネットワークアドレスを決定し、
要求に応答して、決定されたネットワークアドレスを送るようにさらに構成および適合されている請求項４記載のトークンルックアップサーバ。
【請求項６】
認証する方法において、
トークンルックアップサービスにおいて、ワンタイムパスワードバリデーションサーバのネットワークアドレスに対する要求であって、トークン識別子を含む要求を受け取ることと、
ワンタイムパスワードバリデーションサーバと受け取ったトークン識別子とに対応しているネットワークアドレスを決定することと、
要求に応答して、ネットワークアドレスを送ることとを含む方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００８−５４１２４２（Ｐ２００８−５４１２４２Ａ）
【公表日】平成２０年１１月２０日（２００８．１１．２０）
【国際特許分類】
【出願番号】特願２００８−５１０２５６（Ｐ２００８−５１０２５６）
【出願日】平成１８年５月５日（２００６．５．５）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０１７４０４
【国際公開番号】ＷＯ２００６／１２１８５４
【国際公開日】平成１８年１１月１６日（２００６．１１．１６）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
【公表日】平成２０年１１月２０日（２００８．１１．２０）
【国際特許分類】
【出願日】平成１８年５月５日（２００６．５．５）
【国際出願番号】ＰＣＴ／ＵＳ２００６／０１７４０４
【国際公開番号】ＷＯ２００６／１２１８５４
【国際公開日】平成１８年１１月１６日（２００６．１１．１６）
【出願人】（５０２３７７３５０）ベリサイン・インコーポレイテッド (28)
【Ｆターム（参考）】
[ Back to top ]