認証システム、認証方法および認証管理サーバ
【課題】オンライン認証の設計思想を変更する必要がある。
【解決手段】認証システム１０は、第１分散鍵情報が分配される甲銀行決済サーバ１４と、第２分散鍵情報が分配される指定信用情報機関サーバ１６と、第３分散鍵情報が分配される認証局サーバ１８と、発行局サーバ２０と、を備える。発行局サーバ２０は、甲銀行決済サーバ１４、指定信用情報機関サーバ１６および認証局サーバ１８から取得される第１、第２および第３分散鍵情報から秘密鍵情報を生成し、ユーザからインターネット６を介して発行要求を取得するとその秘密鍵情報に基づくＯＴＰをユーザに送信する。認証局サーバ１８は、ユーザからインターネット６を介してＯＴＰを取得すると、第１、第２および第３分散鍵情報を取得してそれらから秘密鍵情報を生成し、ユーザから取得されたＯＴＰを生成された秘密鍵情報に基づき検証する。
【解決手段】認証システム１０は、第１分散鍵情報が分配される甲銀行決済サーバ１４と、第２分散鍵情報が分配される指定信用情報機関サーバ１６と、第３分散鍵情報が分配される認証局サーバ１８と、発行局サーバ２０と、を備える。発行局サーバ２０は、甲銀行決済サーバ１４、指定信用情報機関サーバ１６および認証局サーバ１８から取得される第１、第２および第３分散鍵情報から秘密鍵情報を生成し、ユーザからインターネット６を介して発行要求を取得するとその秘密鍵情報に基づくＯＴＰをユーザに送信する。認証局サーバ１８は、ユーザからインターネット６を介してＯＴＰを取得すると、第１、第２および第３分散鍵情報を取得してそれらから秘密鍵情報を生成し、ユーザから取得されたＯＴＰを生成された秘密鍵情報に基づき検証する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証システム、認証方法および認証管理サーバに関する。
【背景技術】
【０００２】
現在、社会へのインターネットの浸透により、商取引等の様々なサービスをオンラインで受けることができるようになっている。例えばパソコンや携帯電話からオンラインモールにアクセスし、そこでショッピングを楽しむことができる。オンラインモールでの決済は通常電子的に行われ、現金を郵送したりする必要もない。
【０００３】
しかしながら、かかる利便性の影にオンライン特有の危険性が潜んでいることを忘れてはならない。そのような危険性のなかでも最近クローズアップされているもののひとつに情報の漏洩がある。オンライン処理では、例えば認証の鍵情報やユーザＩＤなどがひとつのサーバのハードディスクドライブから別のサーバのハードディスクドライブへと有線または無線もしくはそれらの組み合わせの通信路を使用して運ばれる。そしてこのような情報の伝搬が多数回繰り返される。これらの段階のどこかで例えば情報の不正な複製や通信の傍受などによって情報が漏洩する可能性がある。認証の鍵情報やユーザＩＤなどが流出すると、それが悪意の第３者の手に渡り悪用される可能性がある。
【０００４】
従来では、例えば特許文献１に、安全性を高めた共同購入サービスの提供を容易にする共同購入実現装置が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１５７６７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
インターネットは基本的に性善説に基づいて設計されている仕組みであるが、インターネットに多種多様な人々が接続可能となっている現在にはこの設計思想は適さなくなってきていると考えられる。セキュリティに関して、特許文献１に記載されるようなアプリケーションを絞った対症療法的な手当は可能であっても、根本的な解決にはならないであろう。したがって、オンライン認証の設計思想を変更する必要がある。
【０００７】
本発明はこうした課題に鑑みてなされたものであり、その目的は、破ることがより困難な認証を実現する認証技術の提供にある。
【課題を解決するための手段】
【０００８】
本発明のある態様は認証システムに関する。この認証システムは、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報と、そのＮ個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであって、Ｎ−１個の分散鍵情報がひとつずつ分配されるＮ−１台の認証関連サーバと、残りの１個の分散鍵情報を保持する認証部と、Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と認証部から取得された分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備える。認証部は、認証情報の検証が要求されると、Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と当該認証部が保持する分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証する。
【０００９】
この態様によると、Ｎ−１台の認証関連サーバおよび認証部にＮ個の分散鍵情報がひとつずつ分配されている状況において、Ｎ個の分散鍵情報から生成された秘密鍵情報に基づく認証情報がユーザに送信され、ユーザから取得された認証情報が認証部によって生成された秘密鍵情報に基づき検証される。
【００１０】
本発明の別の態様は、認証管理サーバである。この認証管理サーバは、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報のうちのひとつを保持する分散鍵保持部と、ユーザがＮ個の分散鍵情報から所定の法則にしたがい予め生成された秘密鍵情報に基づく認証情報を受信した場合にその受信に応じてユーザがネットワークを介して送信する認証情報を受信する認証情報受信部と、認証情報受信部によって認証情報が受信されると、分散鍵保持部によって保持される分散鍵情報以外のＮ−１個の分散鍵情報がひとつずつ分配されているＮ−１台の認証関連サーバからネットワークを介してＮ−１個の分散鍵情報を取得する分散鍵取得部と、分散鍵取得部によって取得されたＮ−１個の分散鍵情報と分散鍵保持部によって保持される分散鍵情報とから法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、認証情報受信部によって受信された認証情報を秘密鍵生成部によって生成された秘密鍵情報に基づき検証する検証部と、を備える。
【００１１】
本発明のさらに別の態様もまた、認証管理サーバである。この認証管理サーバは、ユーザからの発行要求の取得にかかわらず、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報がひとつずつ分配されたＮ台の認証関連サーバからネットワークを介してＮ個の分散鍵情報を取得する分散鍵取得部と、分散鍵取得部によって取得されたＮ個の分散鍵情報から所定の法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、ユーザからネットワークを介して発行要求を取得する発行要求取得部と、発行要求取得部によって発行要求が取得されると、秘密鍵生成部によって生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する認証情報送信部と、を備える。ユーザは認証情報送信部によって送信された認証情報の受信に応じて認証情報をＮ個の認証関連サーバのうちのひとつにネットワークを介して送信し、その認証関連サーバはユーザからネットワークを介して認証情報を受信すると、他のＮ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報とその認証関連サーバに分配された分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報をその認証関連サーバによって生成された秘密鍵情報に基づき検証する。
【００１２】
本発明のさらに別の態様もまた、認証管理サーバである。この認証管理サーバは、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報のうちのひとつを保持する認証部と、認証部によって保持される分散鍵情報以外のＮ−１個の分散鍵情報がひとつずつ分配されているＮ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と認証部から取得された分散鍵情報とから所定の法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備える。認証部は、認証情報の検証が要求されると、Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と当該認証部が保持する分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証する。
【００１３】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１４】
本発明によれば、破ることがより困難な認証を実現できる。
【図面の簡単な説明】
【００１５】
【図１】実施の形態に係る認証システムの構成を示す模式図である。
【図２】図１の第１分散鍵管理テーブルの一例を示すデータ構造図である。
【図３】図１のサービス認証管理テーブルの一例を示すデータ構造図である。
【図４】図１の利用判断委託先テーブルの一例を示すデータ構造図である。
【図５】図１の第１利用可否テーブルの一例を示すデータ構造図である。
【図６】図１の第２分散鍵管理テーブルの一例を示すデータ構造図である。
【図７】図１の第２利用可否テーブルの一例を示すデータ構造図である。
【図８】図１の第３分散鍵管理テーブルの一例を示すデータ構造図である。
【図９】図１の第１分散鍵取得先テーブルの一例を示すデータ構造図である。
【図１０】図１のＯＴＰ発行先テーブルの一例を示すデータ構造図である。
【図１１】図１の秘密鍵管理テーブルの一例を示すデータ構造図である。
【図１２】図１の認証先管理テーブルの一例を示すデータ構造図である。
【図１３】図１の発行局サーバの機能および構成を示すブロック図である。
【図１４】図１の認証局サーバの機能および構成を示すブロック図である。
【図１５】図１の認証システムにおける一連の処理の一例を時系列に沿って示すチャートである。
【図１６】図１５の続きのチャートである。
【図１７】支払画面の代表画面図である。
【図１８】ＯＴＰ入力画面の代表画面図である。
【図１９】甲銀行決済サーバにおける独自の認証処理の一例を示すフローチャートである。
【図２０】認証成功画面の代表画面図である。
【図２１】決済画面の代表画面図である。
【発明を実施するための形態】
【００１６】
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
【００１７】
図１は、実施の形態に係る認証システム１０の構成を示す模式図である。認証システム１０はインターネット６などのネットワークを介してユーザのユーザＰＣ（Personal Computer）２と接続される。認証システム１０は、乙電子商店サーバ１２と、甲銀行決済サーバ１４と、指定信用情報機関サーバ１６と、認証局サーバ１８と、発行局サーバ２０と、を備える。乙電子商店サーバ１２、甲銀行決済サーバ１４、指定信用情報機関サーバ１６、認証局サーバ１８、発行局サーバ２０はいずれもインターネット６と接続される。発行局サーバ２０は、インターネット６とは異なるネットワークである移動体通信網８と接続される。ユーザはユーザＰＣ２およびユーザ携帯電話４を有し、ユーザＰＣ２はインターネット６と接続され、ユーザ携帯電話４は移動体通信網８と接続される。
【００１８】
乙電子商店サーバ１２を管理する乙電子商店は甲銀行決済サーバ１４を管理する甲銀行に、乙電子商店サーバ１２が提供するＥＣ（Electronic Commerce）サイトにおけるネット決済機能の提供を委託している。甲銀行決済サーバ１４はそのＥＣサイトにインターネット６を介してネット決済機能を提供する。甲銀行は認証局サーバ１８および発行局サーバ２０の両者を管理する丙セキュリティサービス社にネット決済における利用認証を委託している。
【００１９】
「利用認証」は、例えばユーザがネット決済を利用してもよいか否かを判断することである。「利用認証」は、ユーザの真偽を判断するユーザ認証であってもよく、またはユーザ認証をその一部に含んでもよい。
【００２０】
甲銀行は、信用情報に基づく信用認証を指定信用情報機関サーバ１６を管理する指定信用情報機関に委託している。
「信用認証」は利用認証の一部として利用認証のプロセスに組み込まれており、例えばユーザの年齢や性別や前科（性犯罪履歴など）や自己破産履歴などに基づきネット決済を利用しても良いか否かを判断することである。
【００２１】
認証システム１０では、甲銀行決済サーバ１４と指定信用情報機関サーバ１６と認証局サーバ１８とにひとつずつ分配される３個の分散鍵情報と、その３個の分散鍵情報から所定の結合法則にしたがい生成される秘密鍵情報と、を使用して利用認証が行われる。
【００２２】
したがって、認証局サーバ１８だけではネット決済における利用認証は完結せず甲銀行もその利用認証のプロセスに参加することとなるので、甲銀行が認証のリスクをコントロールすることができる。その結果、丙セキュリティサービス社、指定信用情報機関、もしくは甲銀行自身のいずれかまたは複数において情報が漏洩し悪意の第３者がその情報を手にしたとしても、利用認証が破られる可能性はより低くなる。したがって、甲銀行が丙セキュリティサービス社を完全に信用してそこに利用認証を「丸投げ」する以外のよりセキュアなオプション、すなわちいずれの事業者も相互に信頼しない性悪説を前提とするよりセキュアな認証システムの提供が可能となる。
【００２３】
所定の結合法則は例えば、秘密鍵情報をＳＳ（Shared Secret）４、３個の分散鍵情報をＳＳ１、ＳＳ２、ＳＳ３と表記するとき、ＳＳ４をＳＳ１、ＳＳ２、ＳＳ３から以下の式１にしたがって生成することである。
ＳＳ４＝Ｆ（ＳＳ１、ＳＳ２、ＳＳ３） …（式１）
ここで、Ｆ（ｘ、ｙ、ｚ）は値ｘ、値ｙ、値ｚを変数とする関数である。この法則では、ＳＳ１、ＳＳ２、ＳＳ３の全てが揃わなければＳＳ４を得ることはできない。
あるいはまた、所定の結合法則は、公知のしきい値暗号系のアルゴリズムに基づくものであってもよい。
【００２４】
本実施の形態に係る認証システム１０では、３個の分散鍵情報および秘密鍵情報はユーザごとに設定される。すなわち、ひとりのユーザに対して３個の分散鍵情報とその３個の分散鍵情報から生成される秘密鍵情報との組み合わせが設定され、複数のユーザのそれぞれに対してそれぞれ異なる組み合わせが設定されている。
また、ネット決済サービスごと、例えばネット決済サービスの種類ごとに分散鍵情報の個数が設定される。例えば、通常決済では３個の分散鍵情報が使用され、簡易決済では２個使用される。これにより、トレードオフの関係にあるセキュリティの強さと認証にかかる手間、時間とをサービスごとにより自由に設定できる。
【００２５】
乙電子商店サーバ１２は、インターネット６を介してユーザに所定のサービス、ここではＥＣを提供するサーバである。乙電子商店サーバ１２は処理部と保持部とを有し（いずれも不図示）、保持部は認証先管理テーブル２２を保持する。乙電子商店サーバ１２の処理部は、甲銀行決済サーバ１４が提供するネット決済機能が組み込まれたＥＣサイトを、インターネット６を介してユーザＰＣ２のディスプレイに表示させる。乙電子商店サーバ１２の処理部は、ＥＣサイトにおいてネット決済が指定されると、利用認証のためにユーザＰＣ２を認証局サーバ１８にリダイレクトする。
【００２６】
認証局サーバ１８および発行局サーバ２０は、インターネット６および移動体通信網８を介してネット決済における利用認証を行うサーバである。認証局サーバ１８は処理部１１４と保持部１１６とを有し（いずれも図１４で図示）、保持部１１６は第３分散鍵情報４０と、第３分散鍵管理テーブル４２と、第１分散鍵取得先テーブル４４と、ＯＴＰ発行先テーブル４６と、を保持する。発行局サーバ２０は処理部１０２と保持部１０４とを有し（いずれも図１３で図示）、保持部１０４は秘密鍵情報４８と、秘密鍵管理テーブル５０と、第２分散鍵取得先テーブル５２と、を保持する。
【００２７】
認証局サーバ１８は、ユーザＰＣ２がリダイレクトされてくると、ユーザ携帯電話４から発行局サーバ２０に発行要求を送信するようインターネット６を介してユーザに通知する。発行局サーバ２０は、ユーザから移動体通信網８を介して発行要求を取得すると、そのユーザに対応する秘密鍵情報を特定し、特定された秘密鍵情報に基づく認証情報、例えば秘密鍵情報を入力とする所定の生成アルゴリズムによって生成されるワンタイムパスワード（One Time Password、以下ＯＴＰと称す）をユーザに移動体通信網８を介して送信する。認証局サーバ１８は、ユーザからインターネット６を介してＯＴＰを取得し、それを検証する。発行要求は、例えば利用認証においてＯＴＰの発行を要求する情報である。
【００２８】
甲銀行決済サーバ１４は、インターネット６を介して乙電子商店サーバ１２に所定のリソースやサービス、ここではネット決済機能を提供するサーバである。甲銀行決済サーバ１４は、認証局サーバ１８における検証の結果、ユーザがネット決済を利用してもよいと判定されると、所定の決済サイトをインターネット６を介してユーザＰＣ２のディスプレイに表示させる。
甲銀行決済サーバ１４は処理部と保持部とを有し（いずれも不図示）、保持部は第１分散鍵情報２４と、第１分散鍵管理テーブル２６と、サービス認証管理テーブル２８と、利用判断委託先テーブル３０と、第１利用可否テーブル３２と、を保持する。
【００２９】
指定信用情報機関サーバ１６は、利用認証の一部として信用認証を行うサーバである。指定信用情報機関サーバ１６は処理部と保持部とを有し（いずれも不図示）、保持部は第２分散鍵情報３４と、第２分散鍵管理テーブル３６と、第２利用可否テーブル３８と、を保持する。
【００３０】
図２は、第１分散鍵管理テーブル２６の一例を示すデータ構造図である。第１分散鍵管理テーブル２６は、ユーザを特定するユーザＩＤと、甲銀行決済サーバ１４が提供するネット決済サービスを特定するサービスＩＤと、第１分散鍵情報を特定する第１分散鍵ＩＤと、を対応付けて保持する。図２においては、乙電子商店サーバ１２が提供するＥＣサイトにおける通常決済のネット決済サービスを特定するサービスＩＤは「甲銀行通常決済＠ＥＣ」であり、簡易決済のネット決済サービスを特定するサービスＩＤは「甲銀行簡易決済＠ＥＣ」である。第１分散鍵ＩＤはユーザＩＤおよびサービスＩＤに対応する第１分散鍵情報を甲銀行決済サーバ１４において特定するＩＤであり、例えば第１分散鍵情報の名称や保持部内でのアドレス等である。
【００３１】
図３は、サービス認証管理テーブル２８の一例を示すデータ構造図である。サービス認証管理テーブル２８は、サービスＩＤと、甲銀行がそのサービスＩＤによって特定されるネット決済サービスについて利用認証を委託している事業者が管理する発行局サーバを特定するＩＤと、その事業者が管理する認証局サーバを特定するＩＤと、を対応付けて保持する。サーバを特定するＩＤは例えばそのサーバのＵＲＬ（Uniform Resource Locator）である。図３においては、認証局サーバ１８のＵＲＬは「www.ninshou1.…」であり、発行局サーバ２０のＵＲＬは「www.hakkou.…」である。
【００３２】
図４は、利用判断委託先テーブル３０の一例を示すデータ構造図である。利用判断委託先テーブル３０は、サービスＩＤと、甲銀行がそのサービスＩＤによって特定されるネット決済サービスについて信用認証を委託している機関が管理するサーバのＵＲＬと、を対応付けて保持する。図４においては、指定信用情報機関サーバ１６のＵＲＬは「www.ninshou2.…」である。利用判断委託先テーブル３０は、認証局サーバ１８および発行局サーバ２０に送信され、または認証局サーバ１８および発行局サーバ２０によって参照されることによって、分散鍵情報の取得先を更新するために使用されてもよい。
【００３３】
図５は、第１利用可否テーブル３２の一例を示すデータ構造図である。第１利用可否テーブル３２は甲銀行が設定するいわゆるブラックリストであり、サービスＩＤと、ユーザＩＤと、利用可否に関する情報と、を対応付けて保持する。利用可否に関する情報は、サービスＩＤによって特定されるネット決済サービスについて、ユーザＩＤによって特定されるユーザの利用を甲銀行が許す場合は「可」に、許さない場合は「否」に、設定される。
【００３４】
図６は、第２分散鍵管理テーブル３６の一例を示すデータ構造図である。第２分散鍵管理テーブル３６は、ユーザＩＤと、サービスＩＤと、第２分散鍵情報を特定する第２分散鍵ＩＤと、を対応付けて保持する。第２分散鍵ＩＤはユーザＩＤおよびサービスＩＤに対応する第２分散鍵情報を指定信用情報機関サーバ１６において特定するＩＤである。
【００３５】
図７は、第２利用可否テーブル３８の一例を示すデータ構造図である。第２利用可否テーブル３８は指定信用情報機関が設定するいわゆるブラックリストであり、サービスＩＤと、ユーザＩＤと、利用可否に関する情報と、を対応付けて保持する。利用可否に関する情報は、サービスＩＤによって特定されるネット決済サービスについて、ユーザＩＤによって特定されるユーザの利用を指定信用情報機関が許す場合は「可」に、許さない場合は「否」に、設定される。
【００３６】
図８は、第３分散鍵管理テーブル４２の一例を示すデータ構造図である。第３分散鍵管理テーブル４２は、ユーザＩＤと、サービスＩＤと、第３分散鍵情報を特定する第３分散鍵ＩＤと、を対応付けて保持する。第３分散鍵ＩＤはユーザＩＤおよびサービスＩＤに対応する第３分散鍵情報を認証局サーバ１８において特定するＩＤである。
【００３７】
図９は、第１分散鍵取得先テーブル４４の一例を示すデータ構造図である。第１分散鍵取得先テーブル４４は、サービスＩＤと、そのサービスＩＤによって特定されるネット決済サービスの利用認証における分散鍵情報の取得先のサーバのＵＲＬと、を対応付けて保持する。第１分散鍵取得先テーブル４４は、ネット決済サービスごとに、使用される分散鍵情報の個数およびそれらの分散鍵情報の分配先を保持していると言える。図９において、甲銀行決済サーバ１４のＵＲＬは「www.koubank.…」である。
第２分散鍵取得先テーブル５２の構成は第１分散鍵取得先テーブル４４の構成と同様である。
【００３８】
図１０は、ＯＴＰ発行先テーブル４６の一例を示すデータ構造図である。ＯＴＰ発行先テーブル４６は、サービスＩＤと、そのサービスＩＤによって特定されるネット決済サービスの利用認証においてＯＴＰを発行する発行局サーバのＵＲＬと、を対応付けて保持する。
【００３９】
図１１は、秘密鍵管理テーブル５０の一例を示すデータ構造図である。秘密鍵管理テーブル５０は、ユーザＩＤと、サービスＩＤと、秘密鍵情報を特定する秘密鍵ＩＤと、を対応付けて保持する。秘密鍵ＩＤはユーザＩＤおよびサービスＩＤに対応する秘密鍵情報を発行局サーバ２０において特定するＩＤである。
【００４０】
図１２は、認証先管理テーブル２２の一例を示すデータ構造図である。認証先管理テーブル２２は、サービスＩＤと、そのサービスＩＤによって特定されるネット決済サービスの利用認証を行うためのリダイレクト先のサーバのＵＲＬと、を対応付けて保持する。
【００４１】
図１３は、発行局サーバ２０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
なお、説明をより明瞭とするため図１３において秘密鍵情報４８の図示を省略する。
【００４２】
発行局サーバ２０は処理部１０２と保持部１０４とを備える。処理部１０２は、第１分散鍵取得部１０６と、第１秘密鍵生成部１０８と、発行要求取得部１１０と、ＯＴＰ送信部１１２と、を含む。
【００４３】
処理部１０２は、ユーザからの発行要求の取得にかかわらず例えば定期的に秘密鍵情報を更新する。
第１分散鍵取得部１０６は定期的に、ユーザごとおよびネット決済サービスごとに、分散鍵情報の分配先からインターネット６を介して分散鍵情報を取得する。例えば一日一回、第１分散鍵取得部１０６は第２分散鍵取得先テーブル５２を参照してあるユーザおよびあるネット決済サービスについての分散鍵情報の分配先を特定する。第１分散鍵取得部１０６は、特定された分配先のサーバにインターネット６を介して分散鍵情報を問い合わせる。第１分散鍵取得部１０６は、その問い合わせに応じて送信されてきた分散鍵情報を受信する。
【００４４】
第１秘密鍵生成部１０８は、第１分散鍵取得部１０６によって取得された分散鍵情報から結合法則にしたがい秘密鍵情報を生成する。第１秘密鍵生成部１０８は、生成された秘密鍵情報をユーザごとおよびネット決済サービスごとに保持部１０４に保持させると共に秘密鍵管理テーブル５０に登録する。
【００４５】
発行要求取得部１１０は、ユーザのユーザ携帯電話４から移動体通信網８を介して発行要求を取得する。この発行要求は、利用認証の対象となっているネット決済サービスのサービスＩＤを含む。
【００４６】
ＯＴＰ送信部１１２は、発行要求取得部１１０が発行要求を取得すると、発行要求を送信したユーザのユーザＩＤおよび発行要求に含まれるサービスＩＤの両者に対応する秘密鍵ＩＤを秘密鍵管理テーブル５０から抽出する。ＯＴＰ送信部１１２は、抽出された秘密鍵ＩＤによって特定される秘密鍵情報を保持部１０４から取得する。ＯＴＰ送信部１１２は、取得された秘密鍵情報を入力とする生成アルゴリズムによってＯＴＰを生成し、生成されたＯＴＰをユーザ携帯電話４に移動体通信網８を介して送信する。
【００４７】
図１４は、認証局サーバ１８の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
なお、説明をより明瞭とするため図１４において第３分散鍵情報４０の図示を省略する。
【００４８】
認証局サーバ１８は処理部１１４と保持部１１６とを備える。処理部１１４は、ＯＴＰ入力要求部１１８と、ＯＴＰ受信部１２０と、第２分散鍵取得部１２２と、第２秘密鍵生成部１２４と、検証部１２６と、を含む。
【００４９】
ＯＴＰ入力要求部１１８は、ユーザＰＣ２が乙電子商店サーバ１２によってリダイレクトされてくると、リダイレクトの原因となったネット決済サービスの利用認証においてＯＴＰを発行する発行局サーバのＵＲＬをＯＴＰ発行先テーブル４６を参照して決定する。ＯＴＰ入力要求部１１８は、決定された発行局サーバのＵＲＬをインターネット６を介してユーザＰＣ２のディスプレイに表示させ、ＯＴＰの入力を要求する。
【００５０】
ユーザはユーザＰＣ２のディスプレイに表示されたＵＲＬをユーザ携帯電話４のブラウザに打ち込む。ユーザ携帯電話４は移動体通信網８を介して発行局サーバ、この場合は発行局サーバ２０にアクセスする。ユーザ携帯電話４が移動体通信網８を介して発行局サーバ２０からＯＴＰを受信した場合、ユーザは受信したＯＴＰを見てユーザＰＣ２にＯＴＰを入力する。ユーザＰＣ２はインターネット６を介してそのＯＴＰを認証局サーバ１８に送信する。ＯＴＰ受信部１２０は、そのようにして送信されたＯＴＰを受信する。
【００５１】
第２分散鍵取得部１２２は、ＯＴＰ受信部１２０によってＯＴＰが受信されると、ＯＴＰを送信したユーザおよび利用認証の対象となっているネット決済サービスについて、分散鍵情報の分配先からインターネット６を介して分散鍵情報を取得する。第２分散鍵取得部１２２は第１分散鍵取得先テーブル４４を参照して、利用認証の対象となっているネット決済サービスについての分散鍵情報の分配先を特定する。第２分散鍵取得部１２２は、特定された分配先のサーバにインターネット６を介して分散鍵情報を問い合わせる。第２分散鍵取得部１２２は、その問い合わせに応じて送信されてきた分散鍵情報を受信する。第２分散鍵取得部１２２は、分配先のひとつが認証局サーバ１８自身である場合は、保持部１１６から対応する第３分散鍵情報を取得する。
【００５２】
第２秘密鍵生成部１２４は、第２分散鍵取得部１２２によって取得された分散鍵情報から結合法則にしたがい秘密鍵情報を生成する。第２秘密鍵生成部１２４は、ＯＴＰ受信部１２０によるＯＴＰの受信に応じて動的に秘密鍵情報を生成すると言える。
【００５３】
検証部１２６は、ＯＴＰ受信部１２０によって受信されたＯＴＰを第２秘密鍵生成部１２４によって生成された秘密鍵情報に基づき検証する。特に検証部１２６は、第２秘密鍵生成部１２４によって生成された秘密鍵情報を入力とする生成アルゴリズムによってＯＴＰを生成し、生成されたＯＴＰとＯＴＰ受信部１２０によって受信されたＯＴＰとが一致するか否かを判定する。ここで使用される生成アルゴリズムは、ＯＴＰ送信部１１２で使用される生成アルゴリズムと同一である。一致する場合、検証部１２６はユーザはネット決済を利用してもよいと判定し、一致しない場合、検証部１２６は利用不可と判定する。検証部１２６は利用してもよいと判定された場合、乙電子商店サーバ１２が所有する検証鍵情報に対応する署名鍵情報をインターネット６を介してユーザＰＣ２に送信する。
【００５４】
検証部１２６は、検証後、検証に使用したＯＴＰおよび生成された秘密鍵情報を破棄する。これによりＯＴＰや秘密鍵情報の漏洩のリスクを低減できる。
【００５５】
以上の構成による認証システム１０の動作を説明する。
図１５は、認証システム１０における一連の処理の一例を時系列に沿って示すチャートである。図１６は、図１５の続きのチャートである。発行局サーバ２０の第１分散鍵取得部１０６は定期的に、例えばユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」について分散鍵情報を問い合わせる。第１分散鍵取得部１０６は第２分散鍵取得先テーブル５２を参照して甲銀行決済サーバ１４、指定信用情報機関サーバ１６および認証局サーバ１８を問い合わせ先として特定し、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」を含む第１ＳＳ問い合わせ信号Ｓ１、Ｓ２、Ｓ３を各問い合わせ先にインターネット６を介して送信する（Ｓ２０２）。
【００５６】
甲銀行決済サーバ１４の処理部、指定信用情報機関サーバ１６の処理部および認証局サーバ１８の処理部１１４はそれぞれ、第１ＳＳ問い合わせ信号Ｓ１、Ｓ２、Ｓ３の受信に応じて、その保持部が有する対応する分散鍵情報を含む第１ＳＳ応答信号Ｓ４、Ｓ５、Ｓ６をインターネット６を介して発行局サーバ２０に送信する。発行局サーバ２０の第１分散鍵取得部１０６は第１ＳＳ応答信号Ｓ４、Ｓ５、Ｓ６を受信する（Ｓ２０４）。発行局サーバ２０の第１秘密鍵生成部１０８は、受信された第１ＳＳ応答信号Ｓ４、Ｓ５、Ｓ６に含まれる３個の分散鍵情報からユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」についての秘密鍵情報を生成し、保持部１０４に保持させると共に秘密鍵管理テーブル５０に登録する（Ｓ２０６）。発行局サーバ２０は上記の処理をユーザごと、ネット決済サービスごとに行う。
【００５７】
ユーザＩＤ「Ａ００１」のユーザは、乙電子商店サーバ１２がインターネット６を介して提供するＥＣサイトにおいて商品を選択し、支払画面において甲銀行が提供する通常決済のネット決済サービスを指定する。
図１７は、支払画面３００の代表画面図である。支払画面３００は、支払情報表示領域３０２と、通常決済ボタン３０４と、簡易決済ボタン３０６と、代引きボタン３０８と、クレジットカードボタン３１０と、を有する。ユーザが通常決済ボタン３０４を押し下げることにより、通常決済のネット決済サービスが指定される。
【００５８】
図１５に戻り、ユーザＰＣ２は、ユーザによる通常決済のネット決済サービスの指定を決済要求Ｓ７としてインターネット６を介して乙電子商店サーバ１２に送信する（Ｓ２０８）。乙電子商店サーバ１２は、決済要求Ｓ７を受信すると、認証局サーバ１８によって発行される署名鍵情報を検証するための検証鍵情報の更新が必要か否かを認証局サーバ１８にインターネット６を介して問い合わせる（Ｓ２１０）。認証局サーバ１８は、更新が必要であれば新たな検証鍵情報を、必要でなければその旨を、インターネット６を介して乙電子商店サーバ１２に送信する（Ｓ２１２）。
【００５９】
乙電子商店サーバ１２は、決済要求Ｓ７を受信すると、図１２に示される認証先管理テーブル２２を参照して、ユーザによって指定された通常決済のネット決済サービスに対応するリダイレクト先を認証局サーバ１８と決定し、ユーザＰＣ２を認証局サーバ１８のＵＲＬにリダイレクトする（Ｓ２１４）。このリダイレクトに際し、乙電子商店サーバ１２またはユーザＰＣ２からリダイレクト先である認証局サーバ１８に、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」が通知される。
【００６０】
認証局サーバ１８のＯＴＰ入力要求部１１８は、ユーザＰＣ２がリダイレクトされると、図１０に示されるＯＴＰ発行先テーブル４６を参照して、ユーザによって指定された通常決済のネット決済サービスの利用認証においてＯＴＰを発行する発行局サーバを発行局サーバ２０と決定する。認証局サーバ１８のＯＴＰ入力要求部１１８は、決定された発行局サーバ２０のＵＲＬ「www.hakkou.…」を表示しＯＴＰの入力を促すＯＴＰ入力画面を、インターネット６を介してユーザＰＣ２のディスプレイに表示させる。特に認証局サーバ１８のＯＴＰ入力要求部１１８は、ＯＴＰ入力画面をディスプレイに表示させるための画面情報をＯＴＰ入力要求Ｓ８としてユーザＰＣ２に送信する（Ｓ２１６）。
【００６１】
図１８は、ＯＴＰ入力画面３１２の代表画面図である。ＯＴＰ入力画面３１２は、ＵＲＬ表示領域３１４と、サービスＩＤ表示領域３１６と、ＯＴＰ入力領域３１８と、ＯＫボタン３２０と、を有する。ＵＲＬ表示領域３１４には、認証局サーバ１８によって決定された発行局サーバ２０のＵＲＬが表示される。サービスＩＤ表示領域３１６には、ユーザによって指定された通常決済のネット決済サービスのサービスＩＤが表示される。ＯＴＰ入力領域３１８、ＯＫボタン３２０は後述する。
【００６２】
図１５に戻り、ユーザはユーザ携帯電話４のブラウザにＵＲＬ表示領域３１４に表示されるＵＲＬ「www.hakkou.…」を入力し、ユーザ携帯電話４は入力されたＵＲＬ「www.hakkou.…」に基づいて移動体通信網８を介して発行局サーバ２０にアクセスする。発行局サーバ２０とユーザとの間でユーザＩＤ「Ａ００１」およびパスワードを利用する所定のユーザ認証が行われる。ユーザ認証が成功すると、ユーザはサービスＩＤ表示領域３１６に表示されるサービスＩＤ「甲銀行通常決済＠ＥＣ」をユーザ携帯電話４に入力し、ユーザ携帯電話４はそのサービスＩＤ「甲銀行通常決済＠ＥＣ」を含む発行要求Ｓ９を移動体通信網８を介して発行局サーバ２０に送信することでＯＴＰの発行を要求する（Ｓ２１８）。
【００６３】
発行局サーバ２０の発行要求取得部１１０は、発行要求Ｓ９を受信する。発行局サーバ２０のＯＴＰ送信部１１２は、発行要求取得部１１０によって発行要求Ｓ９が受信されると、図１１に示される秘密鍵管理テーブル５０から、ユーザ認証で認証されたユーザＩＤ「Ａ００１」および発行要求Ｓ９に含まれるサービスＩＤ「甲銀行通常決済＠ＥＣ」に対応する秘密鍵ＩＤ「ＳＳ４Ａ」を抽出する（Ｓ２２０）。ＯＴＰ送信部１１２は、抽出された秘密鍵ＩＤ「ＳＳ４Ａ」によって特定される秘密鍵情報に基づいてＯＴＰを生成する（Ｓ２２２）。ＯＴＰ送信部１１２は、生成されたＯＴＰを含むＯＴＰ発行信号Ｓ１０を移動体通信網８を介してユーザ携帯電話４に送信する（Ｓ２２４）。
【００６４】
図１６を参照すると、ユーザ携帯電話４は、ＯＴＰ発行信号Ｓ１０を受信すると、ＯＴＰ発行信号Ｓ１０に含まれるＯＴＰをユーザ携帯電話４のディスプレイに表示させる。ユーザは、ユーザ携帯電話４のディスプレイでＯＴＰを確認し、図１８に示されるＯＴＰ入力画面３１２のＯＴＰ入力領域３１８にＯＴＰを入力し、ＯＫボタン３２０を押し下げる。ユーザＰＣ２はＯＫボタン３２０が押し下げられると、ＯＴＰ入力領域３１８に入力されたＯＴＰを含む認証要求Ｓ１１をインターネット６を介して認証局サーバ１８に送信する（Ｓ２２６）。
【００６５】
認証局サーバ１８のＯＴＰ受信部１２０は認証要求Ｓ１１を受信する。認証局サーバ１８の第２分散鍵取得部１２２は、ＯＴＰ受信部１２０によって認証要求Ｓ１１が受信されると、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」について分散鍵情報を問い合わせる。第２分散鍵取得部１２２は第１分散鍵取得先テーブル４４を参照して甲銀行決済サーバ１４、指定信用情報機関サーバ１６および認証局サーバ１８自身を問い合わせ先として特定する。第２分散鍵取得部１２２は、第３分散鍵管理テーブル４２からユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」の両者に対応する第３分散鍵ＩＤ「ＳＳ３Ａ」を抽出し、抽出された第３分散鍵ＩＤ「ＳＳ３Ａ」によって特定される第３分散鍵情報を保持部１１６から取得する。また第２分散鍵取得部１２２は、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」を含む第２ＳＳ問い合わせ信号Ｓ１２、Ｓ１３を認証局サーバ１８自身以外の各問い合わせ先にインターネット６を介して送信する（Ｓ２２８）。
【００６６】
甲銀行決済サーバ１４および指定信用情報機関サーバ１６はそれぞれ、第２ＳＳ問い合わせ信号Ｓ１３、Ｓ１２を受信すると、自身が設定する基準に基づいた独自の認証を行う（Ｓ２３０、Ｓ２３２）。ここでの独自の認証の結果は利用認証が成功するための必要条件を構成するが十分条件ではない。
【００６７】
甲銀行決済サーバ１４は、受信された第２ＳＳ問い合わせ信号Ｓ１３に含まれるユーザＩＤ「Ａ００１」によって特定されるユーザが当該甲銀行決済サーバ１４において認証すべきでない対象として登録されている場合、当該甲銀行決済サーバ１４の保持部が保持しているそのユーザＩＤ「Ａ００１」に対応する第１分散鍵情報の認証局サーバ１８への送信を制限する。
【００６８】
図１９は、甲銀行決済サーバ１４における独自の認証処理の一例を示すフローチャートである。甲銀行決済サーバ１４の処理部は、第２ＳＳ問い合わせ信号Ｓ１３を受信し（Ｓ３０２）、受信された第２ＳＳ問い合わせ信号Ｓ１３からユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」を抽出する（Ｓ３０４）。処理部は、抽出されたサービスＩＤ「甲銀行通常決済＠ＥＣ」および第２ＳＳ問い合わせ信号Ｓ１３の送信元である認証局サーバ１８の組がサービス認証管理テーブル２８に登録されているか否かを判定する（Ｓ３０６）。登録されていない場合（Ｓ３０６のＮ）、処理部は認証を許可しない旨を認証局サーバ１８に通知する（Ｓ３１０）。これにより例えば、分散鍵情報の問い合わせが、甲銀行が利用認証を委託している認証局サーバからの問い合わせかどうかを確認することができる。
【００６９】
登録されている場合（Ｓ３０６のＹ）、処理部は、抽出されたユーザＩＤ「Ａ００１」によって特定されるユーザが抽出されたサービスＩＤ「甲銀行通常決済＠ＥＣ」によって特定される通常決済のネット決済サービスを利用してもよいか否かを、第１利用可否テーブル３２を参照して判定する（Ｓ３０８）。利用不可と判定された場合（Ｓ３０８の否）、処理部は認証を許可しない旨を認証局サーバ１８にインターネット６を介して通知する（Ｓ３１０）。利用可と判定された場合（Ｓ３０８の可）、処理部は、第１分散鍵管理テーブル２６からユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」の両者に対応する第１分散鍵ＩＤ「ＳＳ１Ａ」を抽出する（Ｓ３１２）。処理部は、抽出された第１分散鍵ＩＤ「ＳＳ１Ａ」によって特定される第１分散鍵情報を甲銀行決済サーバ１４の保持部から取得し、取得された第１分散鍵情報を含む第２ＳＳ応答信号Ｓ１４を認証局サーバ１８にインターネット６を介して送信する（Ｓ３１４）。
【００７０】
指定信用情報機関サーバ１６は、受信された第２ＳＳ問い合わせ信号Ｓ１２に含まれるユーザＩＤ「Ａ００１」によって特定されるユーザが当該指定信用情報機関サーバ１６において認証すべきでない対象として登録されている場合、当該指定信用情報機関サーバ１６の保持部が保持しているそのユーザＩＤ「Ａ００１」に対応する第２分散鍵情報の認証局サーバ１８への送信を制限する。指定信用情報機関サーバ１６における独自の認証処理の一例は図１９に示されるものに準じる。
【００７１】
図１６に戻り、認証局サーバ１８の処理部１１４は、甲銀行決済サーバ１４または指定信用情報機関サーバ１６から認証を許可しない旨の通知を受けると、利用認証の不成功をユーザＰＣ２にインターネット６を介して通知し（Ｓ２３４）、利用認証の処理を中断または終了する。
【００７２】
認証局サーバ１８の第２分散鍵取得部１２２は、問い合わせ先の全てすなわち甲銀行決済サーバ１４および指定信用情報機関サーバ１６からそれぞれ第２ＳＳ応答信号Ｓ１４、Ｓ１５を受信する（Ｓ２３６）。第２分散鍵取得部１２２は、受信された第２ＳＳ応答信号Ｓ１４、Ｓ１５から、それらに含まれる２個の分散鍵情報（すなわちユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」の両者に対応する第１分散鍵情報および第２分散鍵情報）を抽出する（Ｓ２３８）。
【００７３】
認証局サーバ１８の第２秘密鍵生成部１２４は、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」について、第２分散鍵取得部１２２によって取得された第１分散鍵情報、第２分散鍵情報および第３分散鍵情報から結合法則にしたがい秘密鍵情報を生成する（Ｓ２４０）。
【００７４】
認証局サーバ１８の検証部１２６は、生成された秘密鍵情報に基づいてＯＴＰを生成し（Ｓ２４２）、生成されたＯＴＰと認証要求Ｓ１１に含まれるＯＴＰとが一致するか否かを判定する（Ｓ２４４）。一致しない場合、認証局サーバ１８の処理部１１４は利用認証の不成功をユーザＰＣ２にインターネット６を介して通知し（Ｓ２４６）、利用認証の処理を中断または終了する。一致する場合、認証局サーバ１８の検証部１２６は署名鍵情報を含む認証成功信号Ｓ１６をユーザＰＣ２にインターネット６を介して送信する（Ｓ２４８）。
【００７５】
ユーザＰＣ２は、認証成功信号Ｓ１６を受信すると、受信された認証成功信号Ｓ１６から署名鍵情報を抽出する。ユーザＰＣ２は、抽出された署名鍵情報を含む署名鍵提示信号Ｓ１７を乙電子商店サーバ１２にインターネット６を介して送信する（Ｓ２５０）。
【００７６】
乙電子商店サーバ１２の処理部は、署名鍵提示信号Ｓ１７を受信すると、受信された署名鍵提示信号Ｓ１７に含まれる署名鍵情報を、予め保持している検証鍵情報によって検証する（Ｓ２５２）。検証の結果、検証鍵情報と署名鍵情報とが対応しないと判定された場合、乙電子商店サーバ１２の処理部は利用認証の不成功をユーザＰＣ２にインターネット６を介して通知し（Ｓ２５４）、利用認証の処理を中断または終了する。検証の結果、検証鍵情報と署名鍵情報とが対応すると判定された場合、乙電子商店サーバ１２の処理部はユーザＰＣ２のディスプレイに認証成功画面を表示させると共にユーザＰＣ２を甲銀行決済サーバ１４が提供する決済サイトにリダイレクトする（Ｓ２５６）。その後、決済サイトを通じて甲銀行決済サーバ１４とユーザＰＣ２との間で決済処理が行われる（Ｓ２５８）。
【００７７】
図２０は、認証成功画面３２２の代表画面図である。
図２１は、決済画面３２４の代表画面図である。ステップＳ２５８の決済処理において甲銀行決済サーバ１４は決済画面３２４をユーザＰＣ２のディスプレイに表示させる。
【００７８】
上述の実施の形態において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【００７９】
本実施の形態に係る認証システム１０によると、破ることがより困難な利用認証の仕組みを実現できる。以下の４つの状況においてこの仕組みがいかに機能するかを説明する。
（１）甲銀行や指定信用情報機関や丙セキュリティサービス社の内部から、またはインターネット６上の通信傍受によって第１分散鍵情報、第２分散鍵情報および第３分散鍵情報のうちの２つまでが外部に流出した場合
この場合、秘密鍵情報は第１分散鍵情報、第２分散鍵情報および第３分散鍵情報の全てが揃わないと生成できないので、悪意の第３者が流出した分散鍵情報を手にしたとしても、認証局サーバ１８における認証で必要なＯＴＰを生成することができない。
【００８０】
（２）発行局サーバ２０からユーザ携帯電話４へ送信されるＯＴＰが傍受された場合
この場合、一般に認証プロセスのなかにいる真正のユーザのほうが悪意の第３者よりも早くＯＴＰを認証局サーバ１８に送る。すると認証局サーバ１８におけるＯＴＰの検証後そのＯＴＰは破棄されるので、傍受されたＯＴＰが悪意の第３者から送信されてきても検証を通過しない。また、悪意の第３者がＯＴＰを真正のユーザよりも早く認証局サーバ１８に送ったとしても、真正のユーザは自己のＯＴＰが否定されたことをもって悪意の第３者の存在に気付くことができる。
【００８１】
（３）秘密鍵情報が外部に流出し、悪意の第３者がＯＴＰを複製することが可能となった場合
この場合、例えば甲銀行、指定信用情報機関および丙セキュリティサービス社のうちの少なくともひとつが任意のタイミングで、例えば定期的に、自己の分散鍵情報の更新を行うことで、ＯＴＰの複製のリスクを回避できる。すなわち、漏洩した（可能性のある）秘密鍵情報を任意のタイミングで無効にすることができる。
【００８２】
（４）ユーザが署名鍵情報を偽造し、認証局サーバ１８や発行局サーバ２０を通さずに偽造した署名鍵情報を乙電子商店サーバ１２に提供した場合
この場合、乙電子商店サーバ１２における署名鍵の検証は通過するかも知れないが、偽造された署名鍵情報に係るネット決済サービスについて甲銀行決済サーバ１４は認証局サーバ１８から分散鍵情報の要求を受けていないので、その事実をもって偽造を検知できる。すなわち、甲銀行決済サーバ１４に利用認証に係る分散鍵情報が分配されている場合、このような署名鍵偽造の場合も検知できる。
【００８３】
また、本実施の形態に係る認証システム１０では、甲銀行決済サーバ１４は第１分散鍵情報を有しており、利用認証の際に認証局サーバ１８からの問い合わせに応じて第１分散鍵情報を提供するか否かを通じて利用認証に参加することとなる。したがって、利用認証を丙セキュリティサービス社に委託する甲銀行自体が認証リスクをコントロールすることができる。また、甲銀行は自らが独自に設定できるブラックリストすなわち第１利用可否テーブル３２に照らし合わせてユーザへの認証判断を行うことができる。
【００８４】
また、本実施の形態に係る認証システム１０では、指定信用情報機関サーバ１６は第２分散鍵情報を有しており、利用認証の際に認証局サーバ１８からの問い合わせに応じて第２分散鍵情報を提供するか否かを通じて利用認証に参加することとなる。したがって、甲銀行から信用認証を委託された指定信用情報機関は信用情報に照らし合わせてユーザへの認証判断を行うことができる。これにより、甲銀行は委託先を適宜設定することで自己や丙セキュリティサービス社では設定が困難な判断軸に基づいた認証判断を利用認証に組み込むことができる。
【００８５】
また、本実施の形態に係る認証システム１０では、発行局サーバ２０はユーザからの発行要求の取得にかかわらずに分散鍵情報を問い合わせて取得する。したがって、ユーザからの発行要求の取得を契機として分散鍵情報を問い合わせる場合と比較して、１回の利用認証に必要な通信量を低減できる。また、発行局サーバ２０ではユーザからの発行要求の取得に同期して分散鍵情報を問い合わせる必要はないので、例えば夜間等の通信量の比較的少ない期間に分散鍵情報を集めておくことができ効率的である。
【００８６】
また、本実施の形態に係る認証システム１０ではユーザに秘密鍵情報に基づくＯＴＰを発行する。これにより、他のより複雑な認証情報を使用する場合と比較してユーザの負担、手間を軽減できる。特にＯＴＰをユーザＰＣ２に打ち込むことは比較的容易であり、ユーザＰＣ２およびユーザ携帯電話４の両方を使用する現実的な認証システムが提供される。利用認証に関わるユーザ側の端末の数を増やすことにより利用認証をよりセキュアにできる。
【００８７】
以上、実施の形態に係る認証システム１０の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００８８】
実施の形態では、認証システム１０は３個の分散鍵情報とその３個の分散鍵情報から結合法則にしたがい生成される秘密鍵情報と、を使用する場合について説明したが、これに限られず、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報と、そのＮ個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであればよい。この認証システムは、認証局サーバとＮ−１台の認証関連サーバとを備え、Ｎ個の分散鍵情報はＮ−１台の認証関連サーバおよび認証局サーバにひとつずつ分配されていてもよい。甲銀行決済サーバはＮ−１台の認証関連サーバのうちのひとつであってもよい。指定信用情報機関サーバはＮ−１台の認証関連サーバのうちのひとつであってもよい。乙電子商店サーバはＮ−１台の認証関連サーバのうちのひとつであってもよい。
【００８９】
実施の形態では、認証局サーバ１８と発行局サーバ２０とが別体のサーバでありインターネット６を介して互いに通信する場合について説明したが、これに限られず、認証システムは認証局サーバ１８、発行局サーバ２０の代わりに認証局サーバ１８の機能および発行局サーバ２０の機能の両方を備える単体のサーバを備えてもよい。
【００９０】
実施の形態では、甲銀行決済サーバ１４はインターネット６を介して乙電子商店サーバ１２にネット決済機能を提供する場合について説明したが、これに限られない。例えば認証システムは、認証局サーバ１８と、発行局サーバ２０と、認証局サーバ１８におけるＯＴＰの検証の結果を利用するサービスを提供するサービス提供サーバと、サービス提供サーバによって提供されるサービスを利用するサービス利用サーバと、を備えてもよい。
【００９１】
実施の形態では、甲銀行は指定信用情報機関に信用認証を委託する場合について説明したが、これに限られず、例えば甲銀行はユーザ認証以外の所定の認証を所定の機関に委託してもよい。この所定の機関は、例えば業界標準団体や公的な管轄機関（例えば、金融庁や警察庁）やインターネットにおける発言ログなどを管理する機関である。この場合、その所定の機関が管理するサーバに分散鍵情報が分配される。
【００９２】
実施の形態では、ユーザＰＣ２およびユーザ携帯電話４を利用して利用認証を行う場合について説明したが、これに限られず、例えばユーザＰＣのみで利用認証を行ってもよい。この場合、例えばＯＴＰ入力画面はＯＴＰ生成ボタンを有してもよく、このボタンが押し下げられるとユーザＰＣは発行局サーバ２０にインターネット６を介してアクセスし、ＯＴＰの発行を要求する。この要求に対して発行されたＯＴＰは、例えばユーザＰＣのディスプレイに別画面で表示されてもよい。あるいはまた、ユーザはユーザＰＣまたはユーザ携帯電話から電子メールを使用してＯＴＰの発行を要求してもよい。
【００９３】
実施の形態では、乙電子商店サーバ１２は認証先管理テーブル２２を有しユーザＰＣ２リダイレクトの際にはこの認証先管理テーブル２２を参照する場合について説明したが、これに限られず、乙電子商店サーバはユーザＰＣ２リダイレクトの際リダイレクト先を甲銀行決済サーバに問い合わせてもよい。
【００９４】
実施の形態では、認証局サーバ１８の第２分散鍵取得部１２２はＯＴＰ受信部１２０によってＯＴＰが受信されると分散鍵情報を取得する場合について説明したが、これに限られず、第２分散鍵取得部は認証情報の検証が要求されると分散鍵情報を取得してもよい。例えば、第２分散鍵取得部はユーザＰＣ２がリダイレクトされてきたことを契機として分散鍵情報を取得してもよい。ユーザＰＣ２のリダイレクトもまたＯＴＰの検証の要求とみなされうるからである。
【００９５】
実施の形態では、甲銀行決済サーバ１４および指定信用情報機関サーバ１６において、認証局サーバ１８からの分散鍵情報の問い合わせに応じて独自の認証処理が行われる場合について説明したが、これに限られず、例えば発行局サーバ２０からの分散鍵情報の問い合わせに応じて独自の認証処理が行われてもよい。
【００９６】
実施の形態の図１５および図１６に示されるチャートでは、ユーザによって通常決済のネット決済サービスが指定され、利用認証に３個の分散鍵情報が使用される場合について説明したが、これに限られない。例えば、ユーザによって簡易決済のネット決済サービスが指定された場合、認証局サーバ１８の第２分散鍵取得部１２２および発行局サーバ２０の第１分散鍵取得部１０６はそれぞれ、図９に示される第１分散鍵取得先テーブル４４およびそれと同様な第２分散鍵取得先テーブル５２を参照し、甲銀行決済サーバ１４および認証局サーバ１８からひとつずつ合計２個の分散鍵情報を取得してもよい。
【００９７】
実施の形態では、認証システム１０はサービス提供サーバとして甲銀行によって管理される甲銀行決済サーバ１４を含み、委託先サーバとして指定信用情報機関によって管理される指定信用情報機関サーバ１６を含む場合について説明したが、これに限られず、例えばサービス提供サーバは子会社や日本ブランチやアクワイアラーによって管理されるサーバであってもよく、委託先サーバはそれらに対応する親会社や海外本社やイシュアラーによって管理されるサーバであってもよい。
【符号の説明】
【００９８】
２ ユーザＰＣ、 ４ ユーザ携帯電話、 ６ インターネット、 ８ 移動体通信網、 １０ 認証システム、 １２ 乙電子商店サーバ、 １４ 甲銀行決済サーバ、 １６ 指定信用情報機関サーバ、 １８ 認証局サーバ、 ２０ 発行局サーバ。
【技術分野】
【０００１】
本発明は、認証システム、認証方法および認証管理サーバに関する。
【背景技術】
【０００２】
現在、社会へのインターネットの浸透により、商取引等の様々なサービスをオンラインで受けることができるようになっている。例えばパソコンや携帯電話からオンラインモールにアクセスし、そこでショッピングを楽しむことができる。オンラインモールでの決済は通常電子的に行われ、現金を郵送したりする必要もない。
【０００３】
しかしながら、かかる利便性の影にオンライン特有の危険性が潜んでいることを忘れてはならない。そのような危険性のなかでも最近クローズアップされているもののひとつに情報の漏洩がある。オンライン処理では、例えば認証の鍵情報やユーザＩＤなどがひとつのサーバのハードディスクドライブから別のサーバのハードディスクドライブへと有線または無線もしくはそれらの組み合わせの通信路を使用して運ばれる。そしてこのような情報の伝搬が多数回繰り返される。これらの段階のどこかで例えば情報の不正な複製や通信の傍受などによって情報が漏洩する可能性がある。認証の鍵情報やユーザＩＤなどが流出すると、それが悪意の第３者の手に渡り悪用される可能性がある。
【０００４】
従来では、例えば特許文献１に、安全性を高めた共同購入サービスの提供を容易にする共同購入実現装置が提案されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００６−１５７６７０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
インターネットは基本的に性善説に基づいて設計されている仕組みであるが、インターネットに多種多様な人々が接続可能となっている現在にはこの設計思想は適さなくなってきていると考えられる。セキュリティに関して、特許文献１に記載されるようなアプリケーションを絞った対症療法的な手当は可能であっても、根本的な解決にはならないであろう。したがって、オンライン認証の設計思想を変更する必要がある。
【０００７】
本発明はこうした課題に鑑みてなされたものであり、その目的は、破ることがより困難な認証を実現する認証技術の提供にある。
【課題を解決するための手段】
【０００８】
本発明のある態様は認証システムに関する。この認証システムは、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報と、そのＮ個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであって、Ｎ−１個の分散鍵情報がひとつずつ分配されるＮ−１台の認証関連サーバと、残りの１個の分散鍵情報を保持する認証部と、Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と認証部から取得された分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備える。認証部は、認証情報の検証が要求されると、Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と当該認証部が保持する分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証する。
【０００９】
この態様によると、Ｎ−１台の認証関連サーバおよび認証部にＮ個の分散鍵情報がひとつずつ分配されている状況において、Ｎ個の分散鍵情報から生成された秘密鍵情報に基づく認証情報がユーザに送信され、ユーザから取得された認証情報が認証部によって生成された秘密鍵情報に基づき検証される。
【００１０】
本発明の別の態様は、認証管理サーバである。この認証管理サーバは、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報のうちのひとつを保持する分散鍵保持部と、ユーザがＮ個の分散鍵情報から所定の法則にしたがい予め生成された秘密鍵情報に基づく認証情報を受信した場合にその受信に応じてユーザがネットワークを介して送信する認証情報を受信する認証情報受信部と、認証情報受信部によって認証情報が受信されると、分散鍵保持部によって保持される分散鍵情報以外のＮ−１個の分散鍵情報がひとつずつ分配されているＮ−１台の認証関連サーバからネットワークを介してＮ−１個の分散鍵情報を取得する分散鍵取得部と、分散鍵取得部によって取得されたＮ−１個の分散鍵情報と分散鍵保持部によって保持される分散鍵情報とから法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、認証情報受信部によって受信された認証情報を秘密鍵生成部によって生成された秘密鍵情報に基づき検証する検証部と、を備える。
【００１１】
本発明のさらに別の態様もまた、認証管理サーバである。この認証管理サーバは、ユーザからの発行要求の取得にかかわらず、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報がひとつずつ分配されたＮ台の認証関連サーバからネットワークを介してＮ個の分散鍵情報を取得する分散鍵取得部と、分散鍵取得部によって取得されたＮ個の分散鍵情報から所定の法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、ユーザからネットワークを介して発行要求を取得する発行要求取得部と、発行要求取得部によって発行要求が取得されると、秘密鍵生成部によって生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する認証情報送信部と、を備える。ユーザは認証情報送信部によって送信された認証情報の受信に応じて認証情報をＮ個の認証関連サーバのうちのひとつにネットワークを介して送信し、その認証関連サーバはユーザからネットワークを介して認証情報を受信すると、他のＮ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報とその認証関連サーバに分配された分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報をその認証関連サーバによって生成された秘密鍵情報に基づき検証する。
【００１２】
本発明のさらに別の態様もまた、認証管理サーバである。この認証管理サーバは、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報のうちのひとつを保持する認証部と、認証部によって保持される分散鍵情報以外のＮ−１個の分散鍵情報がひとつずつ分配されているＮ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と認証部から取得された分散鍵情報とから所定の法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備える。認証部は、認証情報の検証が要求されると、Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と当該認証部が保持する分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証する。
【００１３】
なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１４】
本発明によれば、破ることがより困難な認証を実現できる。
【図面の簡単な説明】
【００１５】
【図１】実施の形態に係る認証システムの構成を示す模式図である。
【図２】図１の第１分散鍵管理テーブルの一例を示すデータ構造図である。
【図３】図１のサービス認証管理テーブルの一例を示すデータ構造図である。
【図４】図１の利用判断委託先テーブルの一例を示すデータ構造図である。
【図５】図１の第１利用可否テーブルの一例を示すデータ構造図である。
【図６】図１の第２分散鍵管理テーブルの一例を示すデータ構造図である。
【図７】図１の第２利用可否テーブルの一例を示すデータ構造図である。
【図８】図１の第３分散鍵管理テーブルの一例を示すデータ構造図である。
【図９】図１の第１分散鍵取得先テーブルの一例を示すデータ構造図である。
【図１０】図１のＯＴＰ発行先テーブルの一例を示すデータ構造図である。
【図１１】図１の秘密鍵管理テーブルの一例を示すデータ構造図である。
【図１２】図１の認証先管理テーブルの一例を示すデータ構造図である。
【図１３】図１の発行局サーバの機能および構成を示すブロック図である。
【図１４】図１の認証局サーバの機能および構成を示すブロック図である。
【図１５】図１の認証システムにおける一連の処理の一例を時系列に沿って示すチャートである。
【図１６】図１５の続きのチャートである。
【図１７】支払画面の代表画面図である。
【図１８】ＯＴＰ入力画面の代表画面図である。
【図１９】甲銀行決済サーバにおける独自の認証処理の一例を示すフローチャートである。
【図２０】認証成功画面の代表画面図である。
【図２１】決済画面の代表画面図である。
【発明を実施するための形態】
【００１６】
以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。
【００１７】
図１は、実施の形態に係る認証システム１０の構成を示す模式図である。認証システム１０はインターネット６などのネットワークを介してユーザのユーザＰＣ（Personal Computer）２と接続される。認証システム１０は、乙電子商店サーバ１２と、甲銀行決済サーバ１４と、指定信用情報機関サーバ１６と、認証局サーバ１８と、発行局サーバ２０と、を備える。乙電子商店サーバ１２、甲銀行決済サーバ１４、指定信用情報機関サーバ１６、認証局サーバ１８、発行局サーバ２０はいずれもインターネット６と接続される。発行局サーバ２０は、インターネット６とは異なるネットワークである移動体通信網８と接続される。ユーザはユーザＰＣ２およびユーザ携帯電話４を有し、ユーザＰＣ２はインターネット６と接続され、ユーザ携帯電話４は移動体通信網８と接続される。
【００１８】
乙電子商店サーバ１２を管理する乙電子商店は甲銀行決済サーバ１４を管理する甲銀行に、乙電子商店サーバ１２が提供するＥＣ（Electronic Commerce）サイトにおけるネット決済機能の提供を委託している。甲銀行決済サーバ１４はそのＥＣサイトにインターネット６を介してネット決済機能を提供する。甲銀行は認証局サーバ１８および発行局サーバ２０の両者を管理する丙セキュリティサービス社にネット決済における利用認証を委託している。
【００１９】
「利用認証」は、例えばユーザがネット決済を利用してもよいか否かを判断することである。「利用認証」は、ユーザの真偽を判断するユーザ認証であってもよく、またはユーザ認証をその一部に含んでもよい。
【００２０】
甲銀行は、信用情報に基づく信用認証を指定信用情報機関サーバ１６を管理する指定信用情報機関に委託している。
「信用認証」は利用認証の一部として利用認証のプロセスに組み込まれており、例えばユーザの年齢や性別や前科（性犯罪履歴など）や自己破産履歴などに基づきネット決済を利用しても良いか否かを判断することである。
【００２１】
認証システム１０では、甲銀行決済サーバ１４と指定信用情報機関サーバ１６と認証局サーバ１８とにひとつずつ分配される３個の分散鍵情報と、その３個の分散鍵情報から所定の結合法則にしたがい生成される秘密鍵情報と、を使用して利用認証が行われる。
【００２２】
したがって、認証局サーバ１８だけではネット決済における利用認証は完結せず甲銀行もその利用認証のプロセスに参加することとなるので、甲銀行が認証のリスクをコントロールすることができる。その結果、丙セキュリティサービス社、指定信用情報機関、もしくは甲銀行自身のいずれかまたは複数において情報が漏洩し悪意の第３者がその情報を手にしたとしても、利用認証が破られる可能性はより低くなる。したがって、甲銀行が丙セキュリティサービス社を完全に信用してそこに利用認証を「丸投げ」する以外のよりセキュアなオプション、すなわちいずれの事業者も相互に信頼しない性悪説を前提とするよりセキュアな認証システムの提供が可能となる。
【００２３】
所定の結合法則は例えば、秘密鍵情報をＳＳ（Shared Secret）４、３個の分散鍵情報をＳＳ１、ＳＳ２、ＳＳ３と表記するとき、ＳＳ４をＳＳ１、ＳＳ２、ＳＳ３から以下の式１にしたがって生成することである。
ＳＳ４＝Ｆ（ＳＳ１、ＳＳ２、ＳＳ３） …（式１）
ここで、Ｆ（ｘ、ｙ、ｚ）は値ｘ、値ｙ、値ｚを変数とする関数である。この法則では、ＳＳ１、ＳＳ２、ＳＳ３の全てが揃わなければＳＳ４を得ることはできない。
あるいはまた、所定の結合法則は、公知のしきい値暗号系のアルゴリズムに基づくものであってもよい。
【００２４】
本実施の形態に係る認証システム１０では、３個の分散鍵情報および秘密鍵情報はユーザごとに設定される。すなわち、ひとりのユーザに対して３個の分散鍵情報とその３個の分散鍵情報から生成される秘密鍵情報との組み合わせが設定され、複数のユーザのそれぞれに対してそれぞれ異なる組み合わせが設定されている。
また、ネット決済サービスごと、例えばネット決済サービスの種類ごとに分散鍵情報の個数が設定される。例えば、通常決済では３個の分散鍵情報が使用され、簡易決済では２個使用される。これにより、トレードオフの関係にあるセキュリティの強さと認証にかかる手間、時間とをサービスごとにより自由に設定できる。
【００２５】
乙電子商店サーバ１２は、インターネット６を介してユーザに所定のサービス、ここではＥＣを提供するサーバである。乙電子商店サーバ１２は処理部と保持部とを有し（いずれも不図示）、保持部は認証先管理テーブル２２を保持する。乙電子商店サーバ１２の処理部は、甲銀行決済サーバ１４が提供するネット決済機能が組み込まれたＥＣサイトを、インターネット６を介してユーザＰＣ２のディスプレイに表示させる。乙電子商店サーバ１２の処理部は、ＥＣサイトにおいてネット決済が指定されると、利用認証のためにユーザＰＣ２を認証局サーバ１８にリダイレクトする。
【００２６】
認証局サーバ１８および発行局サーバ２０は、インターネット６および移動体通信網８を介してネット決済における利用認証を行うサーバである。認証局サーバ１８は処理部１１４と保持部１１６とを有し（いずれも図１４で図示）、保持部１１６は第３分散鍵情報４０と、第３分散鍵管理テーブル４２と、第１分散鍵取得先テーブル４４と、ＯＴＰ発行先テーブル４６と、を保持する。発行局サーバ２０は処理部１０２と保持部１０４とを有し（いずれも図１３で図示）、保持部１０４は秘密鍵情報４８と、秘密鍵管理テーブル５０と、第２分散鍵取得先テーブル５２と、を保持する。
【００２７】
認証局サーバ１８は、ユーザＰＣ２がリダイレクトされてくると、ユーザ携帯電話４から発行局サーバ２０に発行要求を送信するようインターネット６を介してユーザに通知する。発行局サーバ２０は、ユーザから移動体通信網８を介して発行要求を取得すると、そのユーザに対応する秘密鍵情報を特定し、特定された秘密鍵情報に基づく認証情報、例えば秘密鍵情報を入力とする所定の生成アルゴリズムによって生成されるワンタイムパスワード（One Time Password、以下ＯＴＰと称す）をユーザに移動体通信網８を介して送信する。認証局サーバ１８は、ユーザからインターネット６を介してＯＴＰを取得し、それを検証する。発行要求は、例えば利用認証においてＯＴＰの発行を要求する情報である。
【００２８】
甲銀行決済サーバ１４は、インターネット６を介して乙電子商店サーバ１２に所定のリソースやサービス、ここではネット決済機能を提供するサーバである。甲銀行決済サーバ１４は、認証局サーバ１８における検証の結果、ユーザがネット決済を利用してもよいと判定されると、所定の決済サイトをインターネット６を介してユーザＰＣ２のディスプレイに表示させる。
甲銀行決済サーバ１４は処理部と保持部とを有し（いずれも不図示）、保持部は第１分散鍵情報２４と、第１分散鍵管理テーブル２６と、サービス認証管理テーブル２８と、利用判断委託先テーブル３０と、第１利用可否テーブル３２と、を保持する。
【００２９】
指定信用情報機関サーバ１６は、利用認証の一部として信用認証を行うサーバである。指定信用情報機関サーバ１６は処理部と保持部とを有し（いずれも不図示）、保持部は第２分散鍵情報３４と、第２分散鍵管理テーブル３６と、第２利用可否テーブル３８と、を保持する。
【００３０】
図２は、第１分散鍵管理テーブル２６の一例を示すデータ構造図である。第１分散鍵管理テーブル２６は、ユーザを特定するユーザＩＤと、甲銀行決済サーバ１４が提供するネット決済サービスを特定するサービスＩＤと、第１分散鍵情報を特定する第１分散鍵ＩＤと、を対応付けて保持する。図２においては、乙電子商店サーバ１２が提供するＥＣサイトにおける通常決済のネット決済サービスを特定するサービスＩＤは「甲銀行通常決済＠ＥＣ」であり、簡易決済のネット決済サービスを特定するサービスＩＤは「甲銀行簡易決済＠ＥＣ」である。第１分散鍵ＩＤはユーザＩＤおよびサービスＩＤに対応する第１分散鍵情報を甲銀行決済サーバ１４において特定するＩＤであり、例えば第１分散鍵情報の名称や保持部内でのアドレス等である。
【００３１】
図３は、サービス認証管理テーブル２８の一例を示すデータ構造図である。サービス認証管理テーブル２８は、サービスＩＤと、甲銀行がそのサービスＩＤによって特定されるネット決済サービスについて利用認証を委託している事業者が管理する発行局サーバを特定するＩＤと、その事業者が管理する認証局サーバを特定するＩＤと、を対応付けて保持する。サーバを特定するＩＤは例えばそのサーバのＵＲＬ（Uniform Resource Locator）である。図３においては、認証局サーバ１８のＵＲＬは「www.ninshou1.…」であり、発行局サーバ２０のＵＲＬは「www.hakkou.…」である。
【００３２】
図４は、利用判断委託先テーブル３０の一例を示すデータ構造図である。利用判断委託先テーブル３０は、サービスＩＤと、甲銀行がそのサービスＩＤによって特定されるネット決済サービスについて信用認証を委託している機関が管理するサーバのＵＲＬと、を対応付けて保持する。図４においては、指定信用情報機関サーバ１６のＵＲＬは「www.ninshou2.…」である。利用判断委託先テーブル３０は、認証局サーバ１８および発行局サーバ２０に送信され、または認証局サーバ１８および発行局サーバ２０によって参照されることによって、分散鍵情報の取得先を更新するために使用されてもよい。
【００３３】
図５は、第１利用可否テーブル３２の一例を示すデータ構造図である。第１利用可否テーブル３２は甲銀行が設定するいわゆるブラックリストであり、サービスＩＤと、ユーザＩＤと、利用可否に関する情報と、を対応付けて保持する。利用可否に関する情報は、サービスＩＤによって特定されるネット決済サービスについて、ユーザＩＤによって特定されるユーザの利用を甲銀行が許す場合は「可」に、許さない場合は「否」に、設定される。
【００３４】
図６は、第２分散鍵管理テーブル３６の一例を示すデータ構造図である。第２分散鍵管理テーブル３６は、ユーザＩＤと、サービスＩＤと、第２分散鍵情報を特定する第２分散鍵ＩＤと、を対応付けて保持する。第２分散鍵ＩＤはユーザＩＤおよびサービスＩＤに対応する第２分散鍵情報を指定信用情報機関サーバ１６において特定するＩＤである。
【００３５】
図７は、第２利用可否テーブル３８の一例を示すデータ構造図である。第２利用可否テーブル３８は指定信用情報機関が設定するいわゆるブラックリストであり、サービスＩＤと、ユーザＩＤと、利用可否に関する情報と、を対応付けて保持する。利用可否に関する情報は、サービスＩＤによって特定されるネット決済サービスについて、ユーザＩＤによって特定されるユーザの利用を指定信用情報機関が許す場合は「可」に、許さない場合は「否」に、設定される。
【００３６】
図８は、第３分散鍵管理テーブル４２の一例を示すデータ構造図である。第３分散鍵管理テーブル４２は、ユーザＩＤと、サービスＩＤと、第３分散鍵情報を特定する第３分散鍵ＩＤと、を対応付けて保持する。第３分散鍵ＩＤはユーザＩＤおよびサービスＩＤに対応する第３分散鍵情報を認証局サーバ１８において特定するＩＤである。
【００３７】
図９は、第１分散鍵取得先テーブル４４の一例を示すデータ構造図である。第１分散鍵取得先テーブル４４は、サービスＩＤと、そのサービスＩＤによって特定されるネット決済サービスの利用認証における分散鍵情報の取得先のサーバのＵＲＬと、を対応付けて保持する。第１分散鍵取得先テーブル４４は、ネット決済サービスごとに、使用される分散鍵情報の個数およびそれらの分散鍵情報の分配先を保持していると言える。図９において、甲銀行決済サーバ１４のＵＲＬは「www.koubank.…」である。
第２分散鍵取得先テーブル５２の構成は第１分散鍵取得先テーブル４４の構成と同様である。
【００３８】
図１０は、ＯＴＰ発行先テーブル４６の一例を示すデータ構造図である。ＯＴＰ発行先テーブル４６は、サービスＩＤと、そのサービスＩＤによって特定されるネット決済サービスの利用認証においてＯＴＰを発行する発行局サーバのＵＲＬと、を対応付けて保持する。
【００３９】
図１１は、秘密鍵管理テーブル５０の一例を示すデータ構造図である。秘密鍵管理テーブル５０は、ユーザＩＤと、サービスＩＤと、秘密鍵情報を特定する秘密鍵ＩＤと、を対応付けて保持する。秘密鍵ＩＤはユーザＩＤおよびサービスＩＤに対応する秘密鍵情報を発行局サーバ２０において特定するＩＤである。
【００４０】
図１２は、認証先管理テーブル２２の一例を示すデータ構造図である。認証先管理テーブル２２は、サービスＩＤと、そのサービスＩＤによって特定されるネット決済サービスの利用認証を行うためのリダイレクト先のサーバのＵＲＬと、を対応付けて保持する。
【００４１】
図１３は、発行局サーバ２０の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵ（central processing unit）をはじめとする素子や機械装置で実現でき、ソフトウエア的にはプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
なお、説明をより明瞭とするため図１３において秘密鍵情報４８の図示を省略する。
【００４２】
発行局サーバ２０は処理部１０２と保持部１０４とを備える。処理部１０２は、第１分散鍵取得部１０６と、第１秘密鍵生成部１０８と、発行要求取得部１１０と、ＯＴＰ送信部１１２と、を含む。
【００４３】
処理部１０２は、ユーザからの発行要求の取得にかかわらず例えば定期的に秘密鍵情報を更新する。
第１分散鍵取得部１０６は定期的に、ユーザごとおよびネット決済サービスごとに、分散鍵情報の分配先からインターネット６を介して分散鍵情報を取得する。例えば一日一回、第１分散鍵取得部１０６は第２分散鍵取得先テーブル５２を参照してあるユーザおよびあるネット決済サービスについての分散鍵情報の分配先を特定する。第１分散鍵取得部１０６は、特定された分配先のサーバにインターネット６を介して分散鍵情報を問い合わせる。第１分散鍵取得部１０６は、その問い合わせに応じて送信されてきた分散鍵情報を受信する。
【００４４】
第１秘密鍵生成部１０８は、第１分散鍵取得部１０６によって取得された分散鍵情報から結合法則にしたがい秘密鍵情報を生成する。第１秘密鍵生成部１０８は、生成された秘密鍵情報をユーザごとおよびネット決済サービスごとに保持部１０４に保持させると共に秘密鍵管理テーブル５０に登録する。
【００４５】
発行要求取得部１１０は、ユーザのユーザ携帯電話４から移動体通信網８を介して発行要求を取得する。この発行要求は、利用認証の対象となっているネット決済サービスのサービスＩＤを含む。
【００４６】
ＯＴＰ送信部１１２は、発行要求取得部１１０が発行要求を取得すると、発行要求を送信したユーザのユーザＩＤおよび発行要求に含まれるサービスＩＤの両者に対応する秘密鍵ＩＤを秘密鍵管理テーブル５０から抽出する。ＯＴＰ送信部１１２は、抽出された秘密鍵ＩＤによって特定される秘密鍵情報を保持部１０４から取得する。ＯＴＰ送信部１１２は、取得された秘密鍵情報を入力とする生成アルゴリズムによってＯＴＰを生成し、生成されたＯＴＰをユーザ携帯電話４に移動体通信網８を介して送信する。
【００４７】
図１４は、認証局サーバ１８の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウエア的にはプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。
なお、説明をより明瞭とするため図１４において第３分散鍵情報４０の図示を省略する。
【００４８】
認証局サーバ１８は処理部１１４と保持部１１６とを備える。処理部１１４は、ＯＴＰ入力要求部１１８と、ＯＴＰ受信部１２０と、第２分散鍵取得部１２２と、第２秘密鍵生成部１２４と、検証部１２６と、を含む。
【００４９】
ＯＴＰ入力要求部１１８は、ユーザＰＣ２が乙電子商店サーバ１２によってリダイレクトされてくると、リダイレクトの原因となったネット決済サービスの利用認証においてＯＴＰを発行する発行局サーバのＵＲＬをＯＴＰ発行先テーブル４６を参照して決定する。ＯＴＰ入力要求部１１８は、決定された発行局サーバのＵＲＬをインターネット６を介してユーザＰＣ２のディスプレイに表示させ、ＯＴＰの入力を要求する。
【００５０】
ユーザはユーザＰＣ２のディスプレイに表示されたＵＲＬをユーザ携帯電話４のブラウザに打ち込む。ユーザ携帯電話４は移動体通信網８を介して発行局サーバ、この場合は発行局サーバ２０にアクセスする。ユーザ携帯電話４が移動体通信網８を介して発行局サーバ２０からＯＴＰを受信した場合、ユーザは受信したＯＴＰを見てユーザＰＣ２にＯＴＰを入力する。ユーザＰＣ２はインターネット６を介してそのＯＴＰを認証局サーバ１８に送信する。ＯＴＰ受信部１２０は、そのようにして送信されたＯＴＰを受信する。
【００５１】
第２分散鍵取得部１２２は、ＯＴＰ受信部１２０によってＯＴＰが受信されると、ＯＴＰを送信したユーザおよび利用認証の対象となっているネット決済サービスについて、分散鍵情報の分配先からインターネット６を介して分散鍵情報を取得する。第２分散鍵取得部１２２は第１分散鍵取得先テーブル４４を参照して、利用認証の対象となっているネット決済サービスについての分散鍵情報の分配先を特定する。第２分散鍵取得部１２２は、特定された分配先のサーバにインターネット６を介して分散鍵情報を問い合わせる。第２分散鍵取得部１２２は、その問い合わせに応じて送信されてきた分散鍵情報を受信する。第２分散鍵取得部１２２は、分配先のひとつが認証局サーバ１８自身である場合は、保持部１１６から対応する第３分散鍵情報を取得する。
【００５２】
第２秘密鍵生成部１２４は、第２分散鍵取得部１２２によって取得された分散鍵情報から結合法則にしたがい秘密鍵情報を生成する。第２秘密鍵生成部１２４は、ＯＴＰ受信部１２０によるＯＴＰの受信に応じて動的に秘密鍵情報を生成すると言える。
【００５３】
検証部１２６は、ＯＴＰ受信部１２０によって受信されたＯＴＰを第２秘密鍵生成部１２４によって生成された秘密鍵情報に基づき検証する。特に検証部１２６は、第２秘密鍵生成部１２４によって生成された秘密鍵情報を入力とする生成アルゴリズムによってＯＴＰを生成し、生成されたＯＴＰとＯＴＰ受信部１２０によって受信されたＯＴＰとが一致するか否かを判定する。ここで使用される生成アルゴリズムは、ＯＴＰ送信部１１２で使用される生成アルゴリズムと同一である。一致する場合、検証部１２６はユーザはネット決済を利用してもよいと判定し、一致しない場合、検証部１２６は利用不可と判定する。検証部１２６は利用してもよいと判定された場合、乙電子商店サーバ１２が所有する検証鍵情報に対応する署名鍵情報をインターネット６を介してユーザＰＣ２に送信する。
【００５４】
検証部１２６は、検証後、検証に使用したＯＴＰおよび生成された秘密鍵情報を破棄する。これによりＯＴＰや秘密鍵情報の漏洩のリスクを低減できる。
【００５５】
以上の構成による認証システム１０の動作を説明する。
図１５は、認証システム１０における一連の処理の一例を時系列に沿って示すチャートである。図１６は、図１５の続きのチャートである。発行局サーバ２０の第１分散鍵取得部１０６は定期的に、例えばユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」について分散鍵情報を問い合わせる。第１分散鍵取得部１０６は第２分散鍵取得先テーブル５２を参照して甲銀行決済サーバ１４、指定信用情報機関サーバ１６および認証局サーバ１８を問い合わせ先として特定し、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」を含む第１ＳＳ問い合わせ信号Ｓ１、Ｓ２、Ｓ３を各問い合わせ先にインターネット６を介して送信する（Ｓ２０２）。
【００５６】
甲銀行決済サーバ１４の処理部、指定信用情報機関サーバ１６の処理部および認証局サーバ１８の処理部１１４はそれぞれ、第１ＳＳ問い合わせ信号Ｓ１、Ｓ２、Ｓ３の受信に応じて、その保持部が有する対応する分散鍵情報を含む第１ＳＳ応答信号Ｓ４、Ｓ５、Ｓ６をインターネット６を介して発行局サーバ２０に送信する。発行局サーバ２０の第１分散鍵取得部１０６は第１ＳＳ応答信号Ｓ４、Ｓ５、Ｓ６を受信する（Ｓ２０４）。発行局サーバ２０の第１秘密鍵生成部１０８は、受信された第１ＳＳ応答信号Ｓ４、Ｓ５、Ｓ６に含まれる３個の分散鍵情報からユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」についての秘密鍵情報を生成し、保持部１０４に保持させると共に秘密鍵管理テーブル５０に登録する（Ｓ２０６）。発行局サーバ２０は上記の処理をユーザごと、ネット決済サービスごとに行う。
【００５７】
ユーザＩＤ「Ａ００１」のユーザは、乙電子商店サーバ１２がインターネット６を介して提供するＥＣサイトにおいて商品を選択し、支払画面において甲銀行が提供する通常決済のネット決済サービスを指定する。
図１７は、支払画面３００の代表画面図である。支払画面３００は、支払情報表示領域３０２と、通常決済ボタン３０４と、簡易決済ボタン３０６と、代引きボタン３０８と、クレジットカードボタン３１０と、を有する。ユーザが通常決済ボタン３０４を押し下げることにより、通常決済のネット決済サービスが指定される。
【００５８】
図１５に戻り、ユーザＰＣ２は、ユーザによる通常決済のネット決済サービスの指定を決済要求Ｓ７としてインターネット６を介して乙電子商店サーバ１２に送信する（Ｓ２０８）。乙電子商店サーバ１２は、決済要求Ｓ７を受信すると、認証局サーバ１８によって発行される署名鍵情報を検証するための検証鍵情報の更新が必要か否かを認証局サーバ１８にインターネット６を介して問い合わせる（Ｓ２１０）。認証局サーバ１８は、更新が必要であれば新たな検証鍵情報を、必要でなければその旨を、インターネット６を介して乙電子商店サーバ１２に送信する（Ｓ２１２）。
【００５９】
乙電子商店サーバ１２は、決済要求Ｓ７を受信すると、図１２に示される認証先管理テーブル２２を参照して、ユーザによって指定された通常決済のネット決済サービスに対応するリダイレクト先を認証局サーバ１８と決定し、ユーザＰＣ２を認証局サーバ１８のＵＲＬにリダイレクトする（Ｓ２１４）。このリダイレクトに際し、乙電子商店サーバ１２またはユーザＰＣ２からリダイレクト先である認証局サーバ１８に、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」が通知される。
【００６０】
認証局サーバ１８のＯＴＰ入力要求部１１８は、ユーザＰＣ２がリダイレクトされると、図１０に示されるＯＴＰ発行先テーブル４６を参照して、ユーザによって指定された通常決済のネット決済サービスの利用認証においてＯＴＰを発行する発行局サーバを発行局サーバ２０と決定する。認証局サーバ１８のＯＴＰ入力要求部１１８は、決定された発行局サーバ２０のＵＲＬ「www.hakkou.…」を表示しＯＴＰの入力を促すＯＴＰ入力画面を、インターネット６を介してユーザＰＣ２のディスプレイに表示させる。特に認証局サーバ１８のＯＴＰ入力要求部１１８は、ＯＴＰ入力画面をディスプレイに表示させるための画面情報をＯＴＰ入力要求Ｓ８としてユーザＰＣ２に送信する（Ｓ２１６）。
【００６１】
図１８は、ＯＴＰ入力画面３１２の代表画面図である。ＯＴＰ入力画面３１２は、ＵＲＬ表示領域３１４と、サービスＩＤ表示領域３１６と、ＯＴＰ入力領域３１８と、ＯＫボタン３２０と、を有する。ＵＲＬ表示領域３１４には、認証局サーバ１８によって決定された発行局サーバ２０のＵＲＬが表示される。サービスＩＤ表示領域３１６には、ユーザによって指定された通常決済のネット決済サービスのサービスＩＤが表示される。ＯＴＰ入力領域３１８、ＯＫボタン３２０は後述する。
【００６２】
図１５に戻り、ユーザはユーザ携帯電話４のブラウザにＵＲＬ表示領域３１４に表示されるＵＲＬ「www.hakkou.…」を入力し、ユーザ携帯電話４は入力されたＵＲＬ「www.hakkou.…」に基づいて移動体通信網８を介して発行局サーバ２０にアクセスする。発行局サーバ２０とユーザとの間でユーザＩＤ「Ａ００１」およびパスワードを利用する所定のユーザ認証が行われる。ユーザ認証が成功すると、ユーザはサービスＩＤ表示領域３１６に表示されるサービスＩＤ「甲銀行通常決済＠ＥＣ」をユーザ携帯電話４に入力し、ユーザ携帯電話４はそのサービスＩＤ「甲銀行通常決済＠ＥＣ」を含む発行要求Ｓ９を移動体通信網８を介して発行局サーバ２０に送信することでＯＴＰの発行を要求する（Ｓ２１８）。
【００６３】
発行局サーバ２０の発行要求取得部１１０は、発行要求Ｓ９を受信する。発行局サーバ２０のＯＴＰ送信部１１２は、発行要求取得部１１０によって発行要求Ｓ９が受信されると、図１１に示される秘密鍵管理テーブル５０から、ユーザ認証で認証されたユーザＩＤ「Ａ００１」および発行要求Ｓ９に含まれるサービスＩＤ「甲銀行通常決済＠ＥＣ」に対応する秘密鍵ＩＤ「ＳＳ４Ａ」を抽出する（Ｓ２２０）。ＯＴＰ送信部１１２は、抽出された秘密鍵ＩＤ「ＳＳ４Ａ」によって特定される秘密鍵情報に基づいてＯＴＰを生成する（Ｓ２２２）。ＯＴＰ送信部１１２は、生成されたＯＴＰを含むＯＴＰ発行信号Ｓ１０を移動体通信網８を介してユーザ携帯電話４に送信する（Ｓ２２４）。
【００６４】
図１６を参照すると、ユーザ携帯電話４は、ＯＴＰ発行信号Ｓ１０を受信すると、ＯＴＰ発行信号Ｓ１０に含まれるＯＴＰをユーザ携帯電話４のディスプレイに表示させる。ユーザは、ユーザ携帯電話４のディスプレイでＯＴＰを確認し、図１８に示されるＯＴＰ入力画面３１２のＯＴＰ入力領域３１８にＯＴＰを入力し、ＯＫボタン３２０を押し下げる。ユーザＰＣ２はＯＫボタン３２０が押し下げられると、ＯＴＰ入力領域３１８に入力されたＯＴＰを含む認証要求Ｓ１１をインターネット６を介して認証局サーバ１８に送信する（Ｓ２２６）。
【００６５】
認証局サーバ１８のＯＴＰ受信部１２０は認証要求Ｓ１１を受信する。認証局サーバ１８の第２分散鍵取得部１２２は、ＯＴＰ受信部１２０によって認証要求Ｓ１１が受信されると、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」について分散鍵情報を問い合わせる。第２分散鍵取得部１２２は第１分散鍵取得先テーブル４４を参照して甲銀行決済サーバ１４、指定信用情報機関サーバ１６および認証局サーバ１８自身を問い合わせ先として特定する。第２分散鍵取得部１２２は、第３分散鍵管理テーブル４２からユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」の両者に対応する第３分散鍵ＩＤ「ＳＳ３Ａ」を抽出し、抽出された第３分散鍵ＩＤ「ＳＳ３Ａ」によって特定される第３分散鍵情報を保持部１１６から取得する。また第２分散鍵取得部１２２は、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」を含む第２ＳＳ問い合わせ信号Ｓ１２、Ｓ１３を認証局サーバ１８自身以外の各問い合わせ先にインターネット６を介して送信する（Ｓ２２８）。
【００６６】
甲銀行決済サーバ１４および指定信用情報機関サーバ１６はそれぞれ、第２ＳＳ問い合わせ信号Ｓ１３、Ｓ１２を受信すると、自身が設定する基準に基づいた独自の認証を行う（Ｓ２３０、Ｓ２３２）。ここでの独自の認証の結果は利用認証が成功するための必要条件を構成するが十分条件ではない。
【００６７】
甲銀行決済サーバ１４は、受信された第２ＳＳ問い合わせ信号Ｓ１３に含まれるユーザＩＤ「Ａ００１」によって特定されるユーザが当該甲銀行決済サーバ１４において認証すべきでない対象として登録されている場合、当該甲銀行決済サーバ１４の保持部が保持しているそのユーザＩＤ「Ａ００１」に対応する第１分散鍵情報の認証局サーバ１８への送信を制限する。
【００６８】
図１９は、甲銀行決済サーバ１４における独自の認証処理の一例を示すフローチャートである。甲銀行決済サーバ１４の処理部は、第２ＳＳ問い合わせ信号Ｓ１３を受信し（Ｓ３０２）、受信された第２ＳＳ問い合わせ信号Ｓ１３からユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」を抽出する（Ｓ３０４）。処理部は、抽出されたサービスＩＤ「甲銀行通常決済＠ＥＣ」および第２ＳＳ問い合わせ信号Ｓ１３の送信元である認証局サーバ１８の組がサービス認証管理テーブル２８に登録されているか否かを判定する（Ｓ３０６）。登録されていない場合（Ｓ３０６のＮ）、処理部は認証を許可しない旨を認証局サーバ１８に通知する（Ｓ３１０）。これにより例えば、分散鍵情報の問い合わせが、甲銀行が利用認証を委託している認証局サーバからの問い合わせかどうかを確認することができる。
【００６９】
登録されている場合（Ｓ３０６のＹ）、処理部は、抽出されたユーザＩＤ「Ａ００１」によって特定されるユーザが抽出されたサービスＩＤ「甲銀行通常決済＠ＥＣ」によって特定される通常決済のネット決済サービスを利用してもよいか否かを、第１利用可否テーブル３２を参照して判定する（Ｓ３０８）。利用不可と判定された場合（Ｓ３０８の否）、処理部は認証を許可しない旨を認証局サーバ１８にインターネット６を介して通知する（Ｓ３１０）。利用可と判定された場合（Ｓ３０８の可）、処理部は、第１分散鍵管理テーブル２６からユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」の両者に対応する第１分散鍵ＩＤ「ＳＳ１Ａ」を抽出する（Ｓ３１２）。処理部は、抽出された第１分散鍵ＩＤ「ＳＳ１Ａ」によって特定される第１分散鍵情報を甲銀行決済サーバ１４の保持部から取得し、取得された第１分散鍵情報を含む第２ＳＳ応答信号Ｓ１４を認証局サーバ１８にインターネット６を介して送信する（Ｓ３１４）。
【００７０】
指定信用情報機関サーバ１６は、受信された第２ＳＳ問い合わせ信号Ｓ１２に含まれるユーザＩＤ「Ａ００１」によって特定されるユーザが当該指定信用情報機関サーバ１６において認証すべきでない対象として登録されている場合、当該指定信用情報機関サーバ１６の保持部が保持しているそのユーザＩＤ「Ａ００１」に対応する第２分散鍵情報の認証局サーバ１８への送信を制限する。指定信用情報機関サーバ１６における独自の認証処理の一例は図１９に示されるものに準じる。
【００７１】
図１６に戻り、認証局サーバ１８の処理部１１４は、甲銀行決済サーバ１４または指定信用情報機関サーバ１６から認証を許可しない旨の通知を受けると、利用認証の不成功をユーザＰＣ２にインターネット６を介して通知し（Ｓ２３４）、利用認証の処理を中断または終了する。
【００７２】
認証局サーバ１８の第２分散鍵取得部１２２は、問い合わせ先の全てすなわち甲銀行決済サーバ１４および指定信用情報機関サーバ１６からそれぞれ第２ＳＳ応答信号Ｓ１４、Ｓ１５を受信する（Ｓ２３６）。第２分散鍵取得部１２２は、受信された第２ＳＳ応答信号Ｓ１４、Ｓ１５から、それらに含まれる２個の分散鍵情報（すなわちユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」の両者に対応する第１分散鍵情報および第２分散鍵情報）を抽出する（Ｓ２３８）。
【００７３】
認証局サーバ１８の第２秘密鍵生成部１２４は、ユーザＩＤ「Ａ００１」およびサービスＩＤ「甲銀行通常決済＠ＥＣ」について、第２分散鍵取得部１２２によって取得された第１分散鍵情報、第２分散鍵情報および第３分散鍵情報から結合法則にしたがい秘密鍵情報を生成する（Ｓ２４０）。
【００７４】
認証局サーバ１８の検証部１２６は、生成された秘密鍵情報に基づいてＯＴＰを生成し（Ｓ２４２）、生成されたＯＴＰと認証要求Ｓ１１に含まれるＯＴＰとが一致するか否かを判定する（Ｓ２４４）。一致しない場合、認証局サーバ１８の処理部１１４は利用認証の不成功をユーザＰＣ２にインターネット６を介して通知し（Ｓ２４６）、利用認証の処理を中断または終了する。一致する場合、認証局サーバ１８の検証部１２６は署名鍵情報を含む認証成功信号Ｓ１６をユーザＰＣ２にインターネット６を介して送信する（Ｓ２４８）。
【００７５】
ユーザＰＣ２は、認証成功信号Ｓ１６を受信すると、受信された認証成功信号Ｓ１６から署名鍵情報を抽出する。ユーザＰＣ２は、抽出された署名鍵情報を含む署名鍵提示信号Ｓ１７を乙電子商店サーバ１２にインターネット６を介して送信する（Ｓ２５０）。
【００７６】
乙電子商店サーバ１２の処理部は、署名鍵提示信号Ｓ１７を受信すると、受信された署名鍵提示信号Ｓ１７に含まれる署名鍵情報を、予め保持している検証鍵情報によって検証する（Ｓ２５２）。検証の結果、検証鍵情報と署名鍵情報とが対応しないと判定された場合、乙電子商店サーバ１２の処理部は利用認証の不成功をユーザＰＣ２にインターネット６を介して通知し（Ｓ２５４）、利用認証の処理を中断または終了する。検証の結果、検証鍵情報と署名鍵情報とが対応すると判定された場合、乙電子商店サーバ１２の処理部はユーザＰＣ２のディスプレイに認証成功画面を表示させると共にユーザＰＣ２を甲銀行決済サーバ１４が提供する決済サイトにリダイレクトする（Ｓ２５６）。その後、決済サイトを通じて甲銀行決済サーバ１４とユーザＰＣ２との間で決済処理が行われる（Ｓ２５８）。
【００７７】
図２０は、認証成功画面３２２の代表画面図である。
図２１は、決済画面３２４の代表画面図である。ステップＳ２５８の決済処理において甲銀行決済サーバ１４は決済画面３２４をユーザＰＣ２のディスプレイに表示させる。
【００７８】
上述の実施の形態において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないＣＰＵや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。
【００７９】
本実施の形態に係る認証システム１０によると、破ることがより困難な利用認証の仕組みを実現できる。以下の４つの状況においてこの仕組みがいかに機能するかを説明する。
（１）甲銀行や指定信用情報機関や丙セキュリティサービス社の内部から、またはインターネット６上の通信傍受によって第１分散鍵情報、第２分散鍵情報および第３分散鍵情報のうちの２つまでが外部に流出した場合
この場合、秘密鍵情報は第１分散鍵情報、第２分散鍵情報および第３分散鍵情報の全てが揃わないと生成できないので、悪意の第３者が流出した分散鍵情報を手にしたとしても、認証局サーバ１８における認証で必要なＯＴＰを生成することができない。
【００８０】
（２）発行局サーバ２０からユーザ携帯電話４へ送信されるＯＴＰが傍受された場合
この場合、一般に認証プロセスのなかにいる真正のユーザのほうが悪意の第３者よりも早くＯＴＰを認証局サーバ１８に送る。すると認証局サーバ１８におけるＯＴＰの検証後そのＯＴＰは破棄されるので、傍受されたＯＴＰが悪意の第３者から送信されてきても検証を通過しない。また、悪意の第３者がＯＴＰを真正のユーザよりも早く認証局サーバ１８に送ったとしても、真正のユーザは自己のＯＴＰが否定されたことをもって悪意の第３者の存在に気付くことができる。
【００８１】
（３）秘密鍵情報が外部に流出し、悪意の第３者がＯＴＰを複製することが可能となった場合
この場合、例えば甲銀行、指定信用情報機関および丙セキュリティサービス社のうちの少なくともひとつが任意のタイミングで、例えば定期的に、自己の分散鍵情報の更新を行うことで、ＯＴＰの複製のリスクを回避できる。すなわち、漏洩した（可能性のある）秘密鍵情報を任意のタイミングで無効にすることができる。
【００８２】
（４）ユーザが署名鍵情報を偽造し、認証局サーバ１８や発行局サーバ２０を通さずに偽造した署名鍵情報を乙電子商店サーバ１２に提供した場合
この場合、乙電子商店サーバ１２における署名鍵の検証は通過するかも知れないが、偽造された署名鍵情報に係るネット決済サービスについて甲銀行決済サーバ１４は認証局サーバ１８から分散鍵情報の要求を受けていないので、その事実をもって偽造を検知できる。すなわち、甲銀行決済サーバ１４に利用認証に係る分散鍵情報が分配されている場合、このような署名鍵偽造の場合も検知できる。
【００８３】
また、本実施の形態に係る認証システム１０では、甲銀行決済サーバ１４は第１分散鍵情報を有しており、利用認証の際に認証局サーバ１８からの問い合わせに応じて第１分散鍵情報を提供するか否かを通じて利用認証に参加することとなる。したがって、利用認証を丙セキュリティサービス社に委託する甲銀行自体が認証リスクをコントロールすることができる。また、甲銀行は自らが独自に設定できるブラックリストすなわち第１利用可否テーブル３２に照らし合わせてユーザへの認証判断を行うことができる。
【００８４】
また、本実施の形態に係る認証システム１０では、指定信用情報機関サーバ１６は第２分散鍵情報を有しており、利用認証の際に認証局サーバ１８からの問い合わせに応じて第２分散鍵情報を提供するか否かを通じて利用認証に参加することとなる。したがって、甲銀行から信用認証を委託された指定信用情報機関は信用情報に照らし合わせてユーザへの認証判断を行うことができる。これにより、甲銀行は委託先を適宜設定することで自己や丙セキュリティサービス社では設定が困難な判断軸に基づいた認証判断を利用認証に組み込むことができる。
【００８５】
また、本実施の形態に係る認証システム１０では、発行局サーバ２０はユーザからの発行要求の取得にかかわらずに分散鍵情報を問い合わせて取得する。したがって、ユーザからの発行要求の取得を契機として分散鍵情報を問い合わせる場合と比較して、１回の利用認証に必要な通信量を低減できる。また、発行局サーバ２０ではユーザからの発行要求の取得に同期して分散鍵情報を問い合わせる必要はないので、例えば夜間等の通信量の比較的少ない期間に分散鍵情報を集めておくことができ効率的である。
【００８６】
また、本実施の形態に係る認証システム１０ではユーザに秘密鍵情報に基づくＯＴＰを発行する。これにより、他のより複雑な認証情報を使用する場合と比較してユーザの負担、手間を軽減できる。特にＯＴＰをユーザＰＣ２に打ち込むことは比較的容易であり、ユーザＰＣ２およびユーザ携帯電話４の両方を使用する現実的な認証システムが提供される。利用認証に関わるユーザ側の端末の数を増やすことにより利用認証をよりセキュアにできる。
【００８７】
以上、実施の形態に係る認証システム１０の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００８８】
実施の形態では、認証システム１０は３個の分散鍵情報とその３個の分散鍵情報から結合法則にしたがい生成される秘密鍵情報と、を使用する場合について説明したが、これに限られず、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報と、そのＮ個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであればよい。この認証システムは、認証局サーバとＮ−１台の認証関連サーバとを備え、Ｎ個の分散鍵情報はＮ−１台の認証関連サーバおよび認証局サーバにひとつずつ分配されていてもよい。甲銀行決済サーバはＮ−１台の認証関連サーバのうちのひとつであってもよい。指定信用情報機関サーバはＮ−１台の認証関連サーバのうちのひとつであってもよい。乙電子商店サーバはＮ−１台の認証関連サーバのうちのひとつであってもよい。
【００８９】
実施の形態では、認証局サーバ１８と発行局サーバ２０とが別体のサーバでありインターネット６を介して互いに通信する場合について説明したが、これに限られず、認証システムは認証局サーバ１８、発行局サーバ２０の代わりに認証局サーバ１８の機能および発行局サーバ２０の機能の両方を備える単体のサーバを備えてもよい。
【００９０】
実施の形態では、甲銀行決済サーバ１４はインターネット６を介して乙電子商店サーバ１２にネット決済機能を提供する場合について説明したが、これに限られない。例えば認証システムは、認証局サーバ１８と、発行局サーバ２０と、認証局サーバ１８におけるＯＴＰの検証の結果を利用するサービスを提供するサービス提供サーバと、サービス提供サーバによって提供されるサービスを利用するサービス利用サーバと、を備えてもよい。
【００９１】
実施の形態では、甲銀行は指定信用情報機関に信用認証を委託する場合について説明したが、これに限られず、例えば甲銀行はユーザ認証以外の所定の認証を所定の機関に委託してもよい。この所定の機関は、例えば業界標準団体や公的な管轄機関（例えば、金融庁や警察庁）やインターネットにおける発言ログなどを管理する機関である。この場合、その所定の機関が管理するサーバに分散鍵情報が分配される。
【００９２】
実施の形態では、ユーザＰＣ２およびユーザ携帯電話４を利用して利用認証を行う場合について説明したが、これに限られず、例えばユーザＰＣのみで利用認証を行ってもよい。この場合、例えばＯＴＰ入力画面はＯＴＰ生成ボタンを有してもよく、このボタンが押し下げられるとユーザＰＣは発行局サーバ２０にインターネット６を介してアクセスし、ＯＴＰの発行を要求する。この要求に対して発行されたＯＴＰは、例えばユーザＰＣのディスプレイに別画面で表示されてもよい。あるいはまた、ユーザはユーザＰＣまたはユーザ携帯電話から電子メールを使用してＯＴＰの発行を要求してもよい。
【００９３】
実施の形態では、乙電子商店サーバ１２は認証先管理テーブル２２を有しユーザＰＣ２リダイレクトの際にはこの認証先管理テーブル２２を参照する場合について説明したが、これに限られず、乙電子商店サーバはユーザＰＣ２リダイレクトの際リダイレクト先を甲銀行決済サーバに問い合わせてもよい。
【００９４】
実施の形態では、認証局サーバ１８の第２分散鍵取得部１２２はＯＴＰ受信部１２０によってＯＴＰが受信されると分散鍵情報を取得する場合について説明したが、これに限られず、第２分散鍵取得部は認証情報の検証が要求されると分散鍵情報を取得してもよい。例えば、第２分散鍵取得部はユーザＰＣ２がリダイレクトされてきたことを契機として分散鍵情報を取得してもよい。ユーザＰＣ２のリダイレクトもまたＯＴＰの検証の要求とみなされうるからである。
【００９５】
実施の形態では、甲銀行決済サーバ１４および指定信用情報機関サーバ１６において、認証局サーバ１８からの分散鍵情報の問い合わせに応じて独自の認証処理が行われる場合について説明したが、これに限られず、例えば発行局サーバ２０からの分散鍵情報の問い合わせに応じて独自の認証処理が行われてもよい。
【００９６】
実施の形態の図１５および図１６に示されるチャートでは、ユーザによって通常決済のネット決済サービスが指定され、利用認証に３個の分散鍵情報が使用される場合について説明したが、これに限られない。例えば、ユーザによって簡易決済のネット決済サービスが指定された場合、認証局サーバ１８の第２分散鍵取得部１２２および発行局サーバ２０の第１分散鍵取得部１０６はそれぞれ、図９に示される第１分散鍵取得先テーブル４４およびそれと同様な第２分散鍵取得先テーブル５２を参照し、甲銀行決済サーバ１４および認証局サーバ１８からひとつずつ合計２個の分散鍵情報を取得してもよい。
【００９７】
実施の形態では、認証システム１０はサービス提供サーバとして甲銀行によって管理される甲銀行決済サーバ１４を含み、委託先サーバとして指定信用情報機関によって管理される指定信用情報機関サーバ１６を含む場合について説明したが、これに限られず、例えばサービス提供サーバは子会社や日本ブランチやアクワイアラーによって管理されるサーバであってもよく、委託先サーバはそれらに対応する親会社や海外本社やイシュアラーによって管理されるサーバであってもよい。
【符号の説明】
【００９８】
２ ユーザＰＣ、 ４ ユーザ携帯電話、 ６ インターネット、 ８ 移動体通信網、 １０ 認証システム、 １２ 乙電子商店サーバ、 １４ 甲銀行決済サーバ、 １６ 指定信用情報機関サーバ、 １８ 認証局サーバ、 ２０ 発行局サーバ。
【特許請求の範囲】
【請求項１】
Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報と、そのＮ個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであって、
Ｎ−１個の分散鍵情報がひとつずつ分配されるＮ−１台の認証関連サーバと、
残りの１個の分散鍵情報を保持する認証部と、
前記Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と前記認証部から取得された分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備え、
前記認証部は、認証情報の検証が要求されると、前記Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と当該認証部が保持する分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証することを特徴とする認証システム。
【請求項２】
前記Ｎ−１台の認証関連サーバは、前記認証部における認証情報の検証の結果を利用するサービスを提供するサービス提供サーバを含むことを特徴とする請求項１に記載の認証システム。
【請求項３】
前記Ｎ−１台の認証関連サーバは、サービス提供サーバを管理する主体から認証を委託された委託先が管理する委託先サーバを含むことを特徴とする請求項２に記載の認証システム。
【請求項４】
ひとりのユーザに対してＮ個の分散鍵情報とそのＮ個の分散鍵情報から生成される秘密鍵情報との組み合わせが設定され、複数のユーザのそれぞれに対してそれぞれ異なる組み合わせが設定されており、
前記認証部は、認証情報の検証が要求されると、前記Ｎ−１台の認証関連サーバにそのユーザを特定するユーザＩＤをネットワークを介して送信し、
前記Ｎ−１台の認証関連サーバのうちの少なくともひとつは、受信されたユーザＩＤによって特定されるユーザが当該認証関連サーバにおいて認証すべきでない対象として登録されている場合、当該認証関連サーバが保持しているそのユーザＩＤに対応する分散鍵情報の前記認証部への送信を制限することを特徴とする請求項１から３のいずれかに記載の認証システム。
【請求項５】
前記発行部は、ユーザからの発行要求の取得にかかわらず、前記Ｎ−１台の認証関連サーバからネットワークを介してＮ−１個の分散鍵情報を取得し、前記認証部から分散鍵情報を取得することを特徴とする請求項１から４のいずれかに記載の認証システム。
【請求項６】
前記認証情報は秘密鍵情報に基づいて生成されるワンタイムパスワードであることを特徴とする請求項１から５のいずれかに記載の認証システム。
【請求項７】
前記認証部における認証情報の検証の結果を利用するサービスごとに分散鍵情報の個数が設定されることを特徴とする請求項１から６のいずれかに記載の認証システム。
【請求項８】
Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報と、そのＮ個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムにおける認証方法であって、前記認証システムはＮ−１台の認証関連サーバを備え、Ｎ−１個の分散鍵情報は前記Ｎ−１台の認証関連サーバにひとつずつ分配されており、本認証方法は、
ユーザからネットワークを介して発行要求を取得すると、Ｎ個の分散鍵情報から前記法則にしたがい生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信するステップと、
認証情報の検証が要求されると、前記Ｎ−１台の認証関連サーバからネットワークを介してＮ−１個の分散鍵情報を取得するステップと、
取得されたＮ−１個の分散鍵情報と残りの１個の分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を生成された秘密鍵情報に基づき検証するステップと、を含むことを特徴とする認証方法。
【請求項９】
Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報のうちのひとつを保持する分散鍵保持部と、
ユーザがＮ個の分散鍵情報から所定の法則にしたがい予め生成された秘密鍵情報に基づく認証情報を受信した場合にその受信に応じてユーザがネットワークを介して送信する認証情報を受信する認証情報受信部と、
前記認証情報受信部によって認証情報が受信されると、前記分散鍵保持部によって保持される分散鍵情報以外のＮ−１個の分散鍵情報がひとつずつ分配されているＮ−１台の認証関連サーバからネットワークを介してＮ−１個の分散鍵情報を取得する分散鍵取得部と、
前記分散鍵取得部によって取得されたＮ−１個の分散鍵情報と前記分散鍵保持部によって保持される分散鍵情報とから前記法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、
前記認証情報受信部によって受信された認証情報を前記秘密鍵生成部によって生成された秘密鍵情報に基づき検証する検証部と、を備えることを特徴とする認証管理サーバ。
【請求項１０】
ユーザからの発行要求の取得にかかわらず、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報がひとつずつ分配されたＮ台の認証関連サーバからネットワークを介してＮ個の分散鍵情報を取得する分散鍵取得部と、
前記分散鍵取得部によって取得されたＮ個の分散鍵情報から所定の法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、
ユーザからネットワークを介して発行要求を取得する発行要求取得部と、
前記発行要求取得部によって発行要求が取得されると、前記秘密鍵生成部によって生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する認証情報送信部と、を備え、
ユーザは前記認証情報送信部によって送信された認証情報の受信に応じて認証情報を前記Ｎ個の認証関連サーバのうちのひとつにネットワークを介して送信し、その認証関連サーバはユーザからネットワークを介して認証情報を受信すると、他のＮ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報とその認証関連サーバに分配された分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報をその認証関連サーバによって生成された秘密鍵情報に基づき検証することを特徴とする認証管理サーバ。
【請求項１１】
Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報のうちのひとつを保持する認証部と、
前記認証部によって保持される分散鍵情報以外のＮ−１個の分散鍵情報がひとつずつ分配されているＮ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と前記認証部から取得された分散鍵情報とから所定の法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備え、
前記認証部は、認証情報の検証が要求されると、前記Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と当該認証部が保持する分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証することを特徴とする認証管理サーバ。
【請求項１】
Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報と、そのＮ個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであって、
Ｎ−１個の分散鍵情報がひとつずつ分配されるＮ−１台の認証関連サーバと、
残りの１個の分散鍵情報を保持する認証部と、
前記Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と前記認証部から取得された分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備え、
前記認証部は、認証情報の検証が要求されると、前記Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と当該認証部が保持する分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証することを特徴とする認証システム。
【請求項２】
前記Ｎ−１台の認証関連サーバは、前記認証部における認証情報の検証の結果を利用するサービスを提供するサービス提供サーバを含むことを特徴とする請求項１に記載の認証システム。
【請求項３】
前記Ｎ−１台の認証関連サーバは、サービス提供サーバを管理する主体から認証を委託された委託先が管理する委託先サーバを含むことを特徴とする請求項２に記載の認証システム。
【請求項４】
ひとりのユーザに対してＮ個の分散鍵情報とそのＮ個の分散鍵情報から生成される秘密鍵情報との組み合わせが設定され、複数のユーザのそれぞれに対してそれぞれ異なる組み合わせが設定されており、
前記認証部は、認証情報の検証が要求されると、前記Ｎ−１台の認証関連サーバにそのユーザを特定するユーザＩＤをネットワークを介して送信し、
前記Ｎ−１台の認証関連サーバのうちの少なくともひとつは、受信されたユーザＩＤによって特定されるユーザが当該認証関連サーバにおいて認証すべきでない対象として登録されている場合、当該認証関連サーバが保持しているそのユーザＩＤに対応する分散鍵情報の前記認証部への送信を制限することを特徴とする請求項１から３のいずれかに記載の認証システム。
【請求項５】
前記発行部は、ユーザからの発行要求の取得にかかわらず、前記Ｎ−１台の認証関連サーバからネットワークを介してＮ−１個の分散鍵情報を取得し、前記認証部から分散鍵情報を取得することを特徴とする請求項１から４のいずれかに記載の認証システム。
【請求項６】
前記認証情報は秘密鍵情報に基づいて生成されるワンタイムパスワードであることを特徴とする請求項１から５のいずれかに記載の認証システム。
【請求項７】
前記認証部における認証情報の検証の結果を利用するサービスごとに分散鍵情報の個数が設定されることを特徴とする請求項１から６のいずれかに記載の認証システム。
【請求項８】
Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報と、そのＮ個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムにおける認証方法であって、前記認証システムはＮ−１台の認証関連サーバを備え、Ｎ−１個の分散鍵情報は前記Ｎ−１台の認証関連サーバにひとつずつ分配されており、本認証方法は、
ユーザからネットワークを介して発行要求を取得すると、Ｎ個の分散鍵情報から前記法則にしたがい生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信するステップと、
認証情報の検証が要求されると、前記Ｎ−１台の認証関連サーバからネットワークを介してＮ−１個の分散鍵情報を取得するステップと、
取得されたＮ−１個の分散鍵情報と残りの１個の分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を生成された秘密鍵情報に基づき検証するステップと、を含むことを特徴とする認証方法。
【請求項９】
Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報のうちのひとつを保持する分散鍵保持部と、
ユーザがＮ個の分散鍵情報から所定の法則にしたがい予め生成された秘密鍵情報に基づく認証情報を受信した場合にその受信に応じてユーザがネットワークを介して送信する認証情報を受信する認証情報受信部と、
前記認証情報受信部によって認証情報が受信されると、前記分散鍵保持部によって保持される分散鍵情報以外のＮ−１個の分散鍵情報がひとつずつ分配されているＮ−１台の認証関連サーバからネットワークを介してＮ−１個の分散鍵情報を取得する分散鍵取得部と、
前記分散鍵取得部によって取得されたＮ−１個の分散鍵情報と前記分散鍵保持部によって保持される分散鍵情報とから前記法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、
前記認証情報受信部によって受信された認証情報を前記秘密鍵生成部によって生成された秘密鍵情報に基づき検証する検証部と、を備えることを特徴とする認証管理サーバ。
【請求項１０】
ユーザからの発行要求の取得にかかわらず、Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報がひとつずつ分配されたＮ台の認証関連サーバからネットワークを介してＮ個の分散鍵情報を取得する分散鍵取得部と、
前記分散鍵取得部によって取得されたＮ個の分散鍵情報から所定の法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、
ユーザからネットワークを介して発行要求を取得する発行要求取得部と、
前記発行要求取得部によって発行要求が取得されると、前記秘密鍵生成部によって生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する認証情報送信部と、を備え、
ユーザは前記認証情報送信部によって送信された認証情報の受信に応じて認証情報を前記Ｎ個の認証関連サーバのうちのひとつにネットワークを介して送信し、その認証関連サーバはユーザからネットワークを介して認証情報を受信すると、他のＮ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報とその認証関連サーバに分配された分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報をその認証関連サーバによって生成された秘密鍵情報に基づき検証することを特徴とする認証管理サーバ。
【請求項１１】
Ｎを２以上の整数とするとき、Ｎ個の分散鍵情報のうちのひとつを保持する認証部と、
前記認証部によって保持される分散鍵情報以外のＮ−１個の分散鍵情報がひとつずつ分配されているＮ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と前記認証部から取得された分散鍵情報とから所定の法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備え、
前記認証部は、認証情報の検証が要求されると、前記Ｎ−１台の認証関連サーバからネットワークを介して取得されたＮ−１個の分散鍵情報と当該認証部が保持する分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証することを特徴とする認証管理サーバ。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【公開番号】特開２０１２−２０９７８２（Ｐ２０１２−２０９７８２Ａ）
【公開日】平成２４年１０月２５日（２０１２．１０．２５）
【国際特許分類】
【出願番号】特願２０１１−７４１５７（Ｐ２０１１−７４１５７）
【出願日】平成２３年３月３０日（２０１１．３．３０）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２４年１０月２５日（２０１２．１０．２５）
【国際特許分類】
【出願日】平成２３年３月３０日（２０１１．３．３０）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]