Nを2以上の整数とするとき、N個の分散鍵情報と、そのN個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであって、N-1個の分散鍵情報がひとつずつ分配されるN-1台の認証関連サーバと、残りの1個の分散鍵情報を保持する認証部と、前記N-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報と前記認証部から取得された分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備え、前記認証部は、認証情報の検証が要求されると、前記N-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報と当該認証部が保持する分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証することを特徴とする認証システム。前記N-1台の認証関連サーバは、前記認証部における認証情報の検証の結果を利用するサービスを提供するサービス提供サーバを含むことを特徴とする請求項1に記載の認証システム。前記N-1台の認証関連サーバは、サービス提供サーバを管理する主体から認証を委託された委託先が管理する委託先サーバを含むことを特徴とする請求項2に記載の認証システム。ひとりのユーザに対してN個の分散鍵情報とそのN個の分散鍵情報から生成される秘密鍵情報との組み合わせが設定され、複数のユーザのそれぞれに対してそれぞれ異なる組み合わせが設定されており、前記認証部は、認証情報の検証が要求されると、前記N-1台の認証関連サーバにそのユーザを特定するユーザIDをネットワークを介して送信し、前記N-1台の認証関連サーバのうちの少なくともひとつは、受信されたユーザIDによって特定されるユーザが当該認証関連サーバにおいて認証すべきでない対象として登録されている場合、当該認証関連サーバが保持しているそのユーザIDに対応する分散鍵情報の前記認証部への送信を制限することを特徴とする請求項1から3のいずれかに記載の認証システム。前記発行部は、ユーザからの発行要求の取得にかかわらず、前記N-1台の認証関連サーバからネットワークを介してN-1個の分散鍵情報を取得し、前記認証部から分散鍵情報を取得することを特徴とする請求項1から4のいずれかに記載の認証システム。前記認証情報は秘密鍵情報に基づいて生成されるワンタイムパスワードであることを特徴とする請求項1から5のいずれかに記載の認証システム。前記認証部における認証情報の検証の結果を利用するサービスごとに分散鍵情報の個数が設定されることを特徴とする請求項1から6のいずれかに記載の認証システム。Nを2以上の整数とするとき、N個の分散鍵情報と、そのN個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムにおける認証方法であって、前記認証システムはN-1台の認証関連サーバを備え、N-1個の分散鍵情報は前記N-1台の認証関連サーバにひとつずつ分配されており、本認証方法は、ユーザからネットワークを介して発行要求を取得すると、N個の分散鍵情報から前記法則にしたがい生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信するステップと、認証情報の検証が要求されると、前記N-1台の認証関連サーバからネットワークを介してN-1個の分散鍵情報を取得するステップと、取得されたN-1個の分散鍵情報と残りの1個の分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を生成された秘密鍵情報に基づき検証するステップと、を含むことを特徴とする認証方法。Nを2以上の整数とするとき、N個の分散鍵情報のうちのひとつを保持する分散鍵保持部と、ユーザがN個の分散鍵情報から所定の法則にしたがい予め生成された秘密鍵情報に基づく認証情報を受信した場合にその受信に応じてユーザがネットワークを介して送信する認証情報を受信する認証情報受信部と、前記認証情報受信部によって認証情報が受信されると、前記分散鍵保持部によって保持される分散鍵情報以外のN-1個の分散鍵情報がひとつずつ分配されているN-1台の認証関連サーバからネットワークを介してN-1個の分散鍵情報を取得する分散鍵取得部と、前記分散鍵取得部によって取得されたN-1個の分散鍵情報と前記分散鍵保持部によって保持される分散鍵情報とから前記法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、前記認証情報受信部によって受信された認証情報を前記秘密鍵生成部によって生成された秘密鍵情報に基づき検証する検証部と、を備えることを特徴とする認証管理サーバ。ユーザからの発行要求の取得にかかわらず、Nを2以上の整数とするとき、N個の分散鍵情報がひとつずつ分配されたN台の認証関連サーバからネットワークを介してN個の分散鍵情報を取得する分散鍵取得部と、前記分散鍵取得部によって取得されたN個の分散鍵情報から所定の法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、ユーザからネットワークを介して発行要求を取得する発行要求取得部と、前記発行要求取得部によって発行要求が取得されると、前記秘密鍵生成部によって生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する認証情報送信部と、を備え、ユーザは前記認証情報送信部によって送信された認証情報の受信に応じて認証情報を前記N個の認証関連サーバのうちのひとつにネットワークを介して送信し、その認証関連サーバはユーザからネットワークを介して認証情報を受信すると、他のN-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報とその認証関連サーバに分配された分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報をその認証関連サーバによって生成された秘密鍵情報に基づき検証することを特徴とする認証管理サーバ。Nを2以上の整数とするとき、N個の分散鍵情報のうちのひとつを保持する認証部と、前記認証部によって保持される分散鍵情報以外のN-1個の分散鍵情報がひとつずつ分配されているN-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報と前記認証部から取得された分散鍵情報とから所定の法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備え、前記認証部は、認証情報の検証が要求されると、前記N-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報と当該認証部が保持する分散鍵情報とから前記法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証することを特徴とする認証管理サーバ。インターネットは基本的に性善説に基づいて設計されている仕組みであるが、インターネットに多種多様な人々が接続可能となっている現在にはこの設計思想は適さなくなってきていると考えられる。セキュリティに関して、特許文献1に記載されるようなアプリケーションを絞った対症療法的な手当は可能であっても、根本的な解決にはならないであろう。したがって、オンライン認証の設計思想を変更する必要がある。本発明はこうした課題に鑑みてなされたものであり、その目的は、破ることがより困難な認証を実現する認証技術の提供にある。本発明のある態様は認証システムに関する。この認証システムは、Nを2以上の整数とするとき、N個の分散鍵情報と、そのN個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであって、N-1個の分散鍵情報がひとつずつ分配されるN-1台の認証関連サーバと、残りの1個の分散鍵情報を保持する認証部と、N-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報と認証部から取得された分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備える。認証部は、認証情報の検証が要求されると、N-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報と当該認証部が保持する分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証する。この態様によると、N-1台の認証関連サーバおよび認証部にN個の分散鍵情報がひとつずつ分配されている状況において、N個の分散鍵情報から生成された秘密鍵情報に基づく認証情報がユーザに送信され、ユーザから取得された認証情報が認証部によって生成された秘密鍵情報に基づき検証される。本発明の別の態様は、認証管理サーバである。この認証管理サーバは、Nを2以上の整数とするとき、N個の分散鍵情報のうちのひとつを保持する分散鍵保持部と、ユーザがN個の分散鍵情報から所定の法則にしたがい予め生成された秘密鍵情報に基づく認証情報を受信した場合にその受信に応じてユーザがネットワークを介して送信する認証情報を受信する認証情報受信部と、認証情報受信部によって認証情報が受信されると、分散鍵保持部によって保持される分散鍵情報以外のN-1個の分散鍵情報がひとつずつ分配されているN-1台の認証関連サーバからネットワークを介してN-1個の分散鍵情報を取得する分散鍵取得部と、分散鍵取得部によって取得されたN-1個の分散鍵情報と分散鍵保持部によって保持される分散鍵情報とから法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、認証情報受信部によって受信された認証情報を秘密鍵生成部によって生成された秘密鍵情報に基づき検証する検証部と、を備える。本発明のさらに別の態様もまた、認証管理サーバである。この認証管理サーバは、ユーザからの発行要求の取得にかかわらず、Nを2以上の整数とするとき、N個の分散鍵情報がひとつずつ分配されたN台の認証関連サーバからネットワークを介してN個の分散鍵情報を取得する分散鍵取得部と、分散鍵取得部によって取得されたN個の分散鍵情報から所定の法則にしたがい秘密鍵情報を生成する秘密鍵生成部と、ユーザからネットワークを介して発行要求を取得する発行要求取得部と、発行要求取得部によって発行要求が取得されると、秘密鍵生成部によって生成された秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する認証情報送信部と、を備える。ユーザは認証情報送信部によって送信された認証情報の受信に応じて認証情報をN個の認証関連サーバのうちのひとつにネットワークを介して送信し、その認証関連サーバはユーザからネットワークを介して認証情報を受信すると、他のN-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報とその認証関連サーバに分配された分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報をその認証関連サーバによって生成された秘密鍵情報に基づき検証する。本発明のさらに別の態様もまた、認証管理サーバである。この認証管理サーバは、Nを2以上の整数とするとき、N個の分散鍵情報のうちのひとつを保持する認証部と、認証部によって保持される分散鍵情報以外のN-1個の分散鍵情報がひとつずつ分配されているN-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報と認証部から取得された分散鍵情報とから所定の法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して発行要求を取得するとその秘密鍵情報に基づく認証情報をユーザにネットワークを介して送信する発行部と、を備える。認証部は、認証情報の検証が要求されると、N-1台の認証関連サーバからネットワークを介して取得されたN-1個の分散鍵情報と当該認証部が保持する分散鍵情報とから法則にしたがい秘密鍵情報を生成し、ユーザからネットワークを介して取得された認証情報を当該認証部によって生成された秘密鍵情報に基づき検証する。なお、以上の構成要素の任意の組み合わせや、本発明の構成要素や表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で相互に置換したものもまた、本発明の態様として有効である。本発明によれば、破ることがより困難な認証を実現できる。以下、本発明を好適な実施の形態をもとに図面を参照しながら説明する。各図面に示される同一または同等の構成要素、部材、処理には、同一の符号を付するものとし、適宜重複した説明は省略する。図1は、実施の形態に係る認証システム10の構成を示す模式図である。認証システム10はインターネット6などのネットワークを介してユーザのユーザPCPersonalComputer2と接続される。認証システム10は、乙電子商店サーバ12と、甲銀行決済サーバ14と、指定信用情報機関サーバ16と、認証局サーバ18と、発行局サーバ20と、を備える。乙電子商店サーバ12、甲銀行決済サーバ14、指定信用情報機関サーバ16、認証局サーバ18、発行局サーバ20はいずれもインターネット6と接続される。発行局サーバ20は、インターネット6とは異なるネットワークである移動体通信網8と接続される。ユーザはユーザPC2およびユーザ携帯電話4を有し、ユーザPC2はインターネット6と接続され、ユーザ携帯電話4は移動体通信網8と接続される。乙電子商店サーバ12を管理する乙電子商店は甲銀行決済サーバ14を管理する甲銀行に、乙電子商店サーバ12が提供するECElectronicCommerceサイトにおけるネット決済機能の提供を委託している。甲銀行決済サーバ14はそのECサイトにインターネット6を介してネット決済機能を提供する。甲銀行は認証局サーバ18および発行局サーバ20の両者を管理する丙セキュリティサービス社にネット決済における利用認証を委託している。利用認証は、例えばユーザがネット決済を利用してもよいか否かを判断することである。利用認証は、ユーザの真偽を判断するユーザ認証であってもよく、またはユーザ認証をその一部に含んでもよい。甲銀行は、信用情報に基づく信用認証を指定信用情報機関サーバ16を管理する指定信用情報機関に委託している。信用認証は利用認証の一部として利用認証のプロセスに組み込まれており、例えばユーザの年齢や性別や前科性犯罪履歴などや自己破産履歴などに基づきネット決済を利用しても良いか否かを判断することである。認証システム10では、甲銀行決済サーバ14と指定信用情報機関サーバ16と認証局サーバ18とにひとつずつ分配される3個の分散鍵情報と、その3個の分散鍵情報から所定の結合法則にしたがい生成される秘密鍵情報と、を使用して利用認証が行われる。したがって、認証局サーバ18だけではネット決済における利用認証は完結せず甲銀行もその利用認証のプロセスに参加することとなるので、甲銀行が認証のリスクをコントロールすることができる。その結果、丙セキュリティサービス社、指定信用情報機関、もしくは甲銀行自身のいずれかまたは複数において情報が漏洩し悪意の第3者がその情報を手にしたとしても、利用認証が破られる可能性はより低くなる。したがって、甲銀行が丙セキュリティサービス社を完全に信用してそこに利用認証を丸投げする以外のよりセキュアなオプション、すなわちいずれの事業者も相互に信頼しない性悪説を前提とするよりセキュアな認証システムの提供が可能となる。所定の結合法則は例えば、秘密鍵情報をSSSharedSecret4、3個の分散鍵情報をSS1、SS2、SS3と表記するとき、SS4をSS1、SS2、SS3から以下の式1にしたがって生成することである。SS4=FSS1、SS2、SS3...式1ここで、Fx、y、zは値x、値y、値zを変数とする関数である。この法則では、SS1、SS2、SS3の全てが揃わなければSS4を得ることはできない。あるいはまた、所定の結合法則は、公知のしきい値暗号系のアルゴリズムに基づくものであってもよい。本実施の形態に係る認証システム10では、3個の分散鍵情報および秘密鍵情報はユーザごとに設定される。すなわち、ひとりのユーザに対して3個の分散鍵情報とその3個の分散鍵情報から生成される秘密鍵情報との組み合わせが設定され、複数のユーザのそれぞれに対してそれぞれ異なる組み合わせが設定されている。また、ネット決済サービスごと、例えばネット決済サービスの種類ごとに分散鍵情報の個数が設定される。例えば、通常決済では3個の分散鍵情報が使用され、簡易決済では2個使用される。これにより、トレードオフの関係にあるセキュリティの強さと認証にかかる手間、時間とをサービスごとにより自由に設定できる。乙電子商店サーバ12は、インターネット6を介してユーザに所定のサービス、ここではECを提供するサーバである。乙電子商店サーバ12は処理部と保持部とを有しいずれも不図示、保持部は認証先管理テーブル22を保持する。乙電子商店サーバ12の処理部は、甲銀行決済サーバ14が提供するネット決済機能が組み込まれたECサイトを、インターネット6を介してユーザPC2のディスプレイに表示させる。乙電子商店サーバ12の処理部は、ECサイトにおいてネット決済が指定されると、利用認証のためにユーザPC2を認証局サーバ18にリダイレクトする。認証局サーバ18および発行局サーバ20は、インターネット6および移動体通信網8を介してネット決済における利用認証を行うサーバである。認証局サーバ18は処理部114と保持部116とを有しいずれも図14で図示、保持部116は第3分散鍵情報40と、第3分散鍵管理テーブル42と、第1分散鍵取得先テーブル44と、OTP発行先テーブル46と、を保持する。発行局サーバ20は処理部102と保持部104とを有しいずれも図13で図示、保持部104は秘密鍵情報48と、秘密鍵管理テーブル50と、第2分散鍵取得先テーブル52と、を保持する。認証局サーバ18は、ユーザPC2がリダイレクトされてくると、ユーザ携帯電話4から発行局サーバ20に発行要求を送信するようインターネット6を介してユーザに通知する。発行局サーバ20は、ユーザから移動体通信網8を介して発行要求を取得すると、そのユーザに対応する秘密鍵情報を特定し、特定された秘密鍵情報に基づく認証情報、例えば秘密鍵情報を入力とする所定の生成アルゴリズムによって生成されるワンタイムパスワードOneTimePassword、以下OTPと称すをユーザに移動体通信網8を介して送信する。認証局サーバ18は、ユーザからインターネット6を介してOTPを取得し、それを検証する。発行要求は、例えば利用認証においてOTPの発行を要求する情報である。甲銀行決済サーバ14は、インターネット6を介して乙電子商店サーバ12に所定のリソースやサービス、ここではネット決済機能を提供するサーバである。甲銀行決済サーバ14は、認証局サーバ18における検証の結果、ユーザがネット決済を利用してもよいと判定されると、所定の決済サイトをインターネット6を介してユーザPC2のディスプレイに表示させる。甲銀行決済サーバ14は処理部と保持部とを有しいずれも不図示、保持部は第1分散鍵情報24と、第1分散鍵管理テーブル26と、サービス認証管理テーブル28と、利用判断委託先テーブル30と、第1利用可否テーブル32と、を保持する。指定信用情報機関サーバ16は、利用認証の一部として信用認証を行うサーバである。指定信用情報機関サーバ16は処理部と保持部とを有しいずれも不図示、保持部は第2分散鍵情報34と、第2分散鍵管理テーブル36と、第2利用可否テーブル38と、を保持する。図2は、第1分散鍵管理テーブル26の一例を示すデータ構造図である。第1分散鍵管理テーブル26は、ユーザを特定するユーザIDと、甲銀行決済サーバ14が提供するネット決済サービスを特定するサービスIDと、第1分散鍵情報を特定する第1分散鍵IDと、を対応付けて保持する。図2においては、乙電子商店サーバ12が提供するECサイトにおける通常決済のネット決済サービスを特定するサービスIDは甲銀行通常決済ECであり、簡易決済のネット決済サービスを特定するサービスIDは甲銀行簡易決済ECである。第1分散鍵IDはユーザIDおよびサービスIDに対応する第1分散鍵情報を甲銀行決済サーバ14において特定するIDであり、例えば第1分散鍵情報の名称や保持部内でのアドレス等である。図3は、サービス認証管理テーブル28の一例を示すデータ構造図である。サービス認証管理テーブル28は、サービスIDと、甲銀行がそのサービスIDによって特定されるネット決済サービスについて利用認証を委託している事業者が管理する発行局サーバを特定するIDと、その事業者が管理する認証局サーバを特定するIDと、を対応付けて保持する。サーバを特定するIDは例えばそのサーバのURLUniformResourceLocatorである。図3においては、認証局サーバ18のURLはwwwninshou1...であり、発行局サーバ20のURLはwwwhakkou...である。図4は、利用判断委託先テーブル30の一例を示すデータ構造図である。利用判断委託先テーブル30は、サービスIDと、甲銀行がそのサービスIDによって特定されるネット決済サービスについて信用認証を委託している機関が管理するサーバのURLと、を対応付けて保持する。図4においては、指定信用情報機関サーバ16のURLはwwwninshou2...である。利用判断委託先テーブル30は、認証局サーバ18および発行局サーバ20に送信され、または認証局サーバ18および発行局サーバ20によって参照されることによって、分散鍵情報の取得先を更新するために使用されてもよい。図5は、第1利用可否テーブル32の一例を示すデータ構造図である。第1利用可否テーブル32は甲銀行が設定するいわゆるブラックリストであり、サービスIDと、ユーザIDと、利用可否に関する情報と、を対応付けて保持する。利用可否に関する情報は、サービスIDによって特定されるネット決済サービスについて、ユーザIDによって特定されるユーザの利用を甲銀行が許す場合は可に、許さない場合は否に、設定される。図6は、第2分散鍵管理テーブル36の一例を示すデータ構造図である。第2分散鍵管理テーブル36は、ユーザIDと、サービスIDと、第2分散鍵情報を特定する第2分散鍵IDと、を対応付けて保持する。第2分散鍵IDはユーザIDおよびサービスIDに対応する第2分散鍵情報を指定信用情報機関サーバ16において特定するIDである。図7は、第2利用可否テーブル38の一例を示すデータ構造図である。第2利用可否テーブル38は指定信用情報機関が設定するいわゆるブラックリストであり、サービスIDと、ユーザIDと、利用可否に関する情報と、を対応付けて保持する。利用可否に関する情報は、サービスIDによって特定されるネット決済サービスについて、ユーザIDによって特定されるユーザの利用を指定信用情報機関が許す場合は可に、許さない場合は否に、設定される。図8は、第3分散鍵管理テーブル42の一例を示すデータ構造図である。第3分散鍵管理テーブル42は、ユーザIDと、サービスIDと、第3分散鍵情報を特定する第3分散鍵IDと、を対応付けて保持する。第3分散鍵IDはユーザIDおよびサービスIDに対応する第3分散鍵情報を認証局サーバ18において特定するIDである。図9は、第1分散鍵取得先テーブル44の一例を示すデータ構造図である。第1分散鍵取得先テーブル44は、サービスIDと、そのサービスIDによって特定されるネット決済サービスの利用認証における分散鍵情報の取得先のサーバのURLと、を対応付けて保持する。第1分散鍵取得先テーブル44は、ネット決済サービスごとに、使用される分散鍵情報の個数およびそれらの分散鍵情報の分配先を保持していると言える。図9において、甲銀行決済サーバ14のURLはwwwkoubank...である。第2分散鍵取得先テーブル52の構成は第1分散鍵取得先テーブル44の構成と同様である。図10は、OTP発行先テーブル46の一例を示すデータ構造図である。OTP発行先テーブル46は、サービスIDと、そのサービスIDによって特定されるネット決済サービスの利用認証においてOTPを発行する発行局サーバのURLと、を対応付けて保持する。図11は、秘密鍵管理テーブル50の一例を示すデータ構造図である。秘密鍵管理テーブル50は、ユーザIDと、サービスIDと、秘密鍵情報を特定する秘密鍵IDと、を対応付けて保持する。秘密鍵IDはユーザIDおよびサービスIDに対応する秘密鍵情報を発行局サーバ20において特定するIDである。図12は、認証先管理テーブル22の一例を示すデータ構造図である。認証先管理テーブル22は、サービスIDと、そのサービスIDによって特定されるネット決済サービスの利用認証を行うためのリダイレクト先のサーバのURLと、を対応付けて保持する。図13は、発行局サーバ20の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのCPUcentralprocessingunitをはじめとする素子や機械装置で実現でき、ソフトウエア的にはプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。なお、説明をより明瞭とするため図13において秘密鍵情報48の図示を省略する。発行局サーバ20は処理部102と保持部104とを備える。処理部102は、第1分散鍵取得部106と、第1秘密鍵生成部108と、発行要求取得部110と、OTP送信部112と、を含む。処理部102は、ユーザからの発行要求の取得にかかわらず例えば定期的に秘密鍵情報を更新する。第1分散鍵取得部106は定期的に、ユーザごとおよびネット決済サービスごとに、分散鍵情報の分配先からインターネット6を介して分散鍵情報を取得する。例えば一日一回、第1分散鍵取得部106は第2分散鍵取得先テーブル52を参照してあるユーザおよびあるネット決済サービスについての分散鍵情報の分配先を特定する。第1分散鍵取得部106は、特定された分配先のサーバにインターネット6を介して分散鍵情報を問い合わせる。第1分散鍵取得部106は、その問い合わせに応じて送信されてきた分散鍵情報を受信する。第1秘密鍵生成部108は、第1分散鍵取得部106によって取得された分散鍵情報から結合法則にしたがい秘密鍵情報を生成する。第1秘密鍵生成部108は、生成された秘密鍵情報をユーザごとおよびネット決済サービスごとに保持部104に保持させると共に秘密鍵管理テーブル50に登録する。発行要求取得部110は、ユーザのユーザ携帯電話4から移動体通信網8を介して発行要求を取得する。この発行要求は、利用認証の対象となっているネット決済サービスのサービスIDを含む。OTP送信部112は、発行要求取得部110が発行要求を取得すると、発行要求を送信したユーザのユーザIDおよび発行要求に含まれるサービスIDの両者に対応する秘密鍵IDを秘密鍵管理テーブル50から抽出する。OTP送信部112は、抽出された秘密鍵IDによって特定される秘密鍵情報を保持部104から取得する。OTP送信部112は、取得された秘密鍵情報を入力とする生成アルゴリズムによってOTPを生成し、生成されたOTPをユーザ携帯電話4に移動体通信網8を介して送信する。図14は、認証局サーバ18の機能および構成を示すブロック図である。ここに示す各ブロックは、ハードウエア的には、コンピュータのCPUをはじめとする素子や機械装置で実現でき、ソフトウエア的にはプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウエア、ソフトウエアの組合せによっていろいろなかたちで実現できることは、本明細書に触れた当業者には理解されるところである。なお、説明をより明瞭とするため図14において第3分散鍵情報40の図示を省略する。認証局サーバ18は処理部114と保持部116とを備える。処理部114は、OTP入力要求部118と、OTP受信部120と、第2分散鍵取得部122と、第2秘密鍵生成部124と、検証部126と、を含む。OTP入力要求部118は、ユーザPC2が乙電子商店サーバ12によってリダイレクトされてくると、リダイレクトの原因となったネット決済サービスの利用認証においてOTPを発行する発行局サーバのURLをOTP発行先テーブル46を参照して決定する。OTP入力要求部118は、決定された発行局サーバのURLをインターネット6を介してユーザPC2のディスプレイに表示させ、OTPの入力を要求する。ユーザはユーザPC2のディスプレイに表示されたURLをユーザ携帯電話4のブラウザに打ち込む。ユーザ携帯電話4は移動体通信網8を介して発行局サーバ、この場合は発行局サーバ20にアクセスする。ユーザ携帯電話4が移動体通信網8を介して発行局サーバ20からOTPを受信した場合、ユーザは受信したOTPを見てユーザPC2にOTPを入力する。ユーザPC2はインターネット6を介してそのOTPを認証局サーバ18に送信する。OTP受信部120は、そのようにして送信されたOTPを受信する。第2分散鍵取得部122は、OTP受信部120によってOTPが受信されると、OTPを送信したユーザおよび利用認証の対象となっているネット決済サービスについて、分散鍵情報の分配先からインターネット6を介して分散鍵情報を取得する。第2分散鍵取得部122は第1分散鍵取得先テーブル44を参照して、利用認証の対象となっているネット決済サービスについての分散鍵情報の分配先を特定する。第2分散鍵取得部122は、特定された分配先のサーバにインターネット6を介して分散鍵情報を問い合わせる。第2分散鍵取得部122は、その問い合わせに応じて送信されてきた分散鍵情報を受信する。第2分散鍵取得部122は、分配先のひとつが認証局サーバ18自身である場合は、保持部116から対応する第3分散鍵情報を取得する。第2秘密鍵生成部124は、第2分散鍵取得部122によって取得された分散鍵情報から結合法則にしたがい秘密鍵情報を生成する。第2秘密鍵生成部124は、OTP受信部120によるOTPの受信に応じて動的に秘密鍵情報を生成すると言える。検証部126は、OTP受信部120によって受信されたOTPを第2秘密鍵生成部124によって生成された秘密鍵情報に基づき検証する。特に検証部126は、第2秘密鍵生成部124によって生成された秘密鍵情報を入力とする生成アルゴリズムによってOTPを生成し、生成されたOTPとOTP受信部120によって受信されたOTPとが一致するか否かを判定する。ここで使用される生成アルゴリズムは、OTP送信部112で使用される生成アルゴリズムと同一である。一致する場合、検証部126はユーザはネット決済を利用してもよいと判定し、一致しない場合、検証部126は利用不可と判定する。検証部126は利用してもよいと判定された場合、乙電子商店サーバ12が所有する検証鍵情報に対応する署名鍵情報をインターネット6を介してユーザPC2に送信する。検証部126は、検証後、検証に使用したOTPおよび生成された秘密鍵情報を破棄する。これによりOTPや秘密鍵情報の漏洩のリスクを低減できる。以上の構成による認証システム10の動作を説明する。図15は、認証システム10における一連の処理の一例を時系列に沿って示すチャートである。図16は、図15の続きのチャートである。発行局サーバ20の第1分散鍵取得部106は定期的に、例えばユーザIDA001およびサービスID甲銀行通常決済ECについて分散鍵情報を問い合わせる。第1分散鍵取得部106は第2分散鍵取得先テーブル52を参照して甲銀行決済サーバ14、指定信用情報機関サーバ16および認証局サーバ18を問い合わせ先として特定し、ユーザIDA001およびサービスID甲銀行通常決済ECを含む第1SS問い合わせ信号S1、S2、S3を各問い合わせ先にインターネット6を介して送信するS202。甲銀行決済サーバ14の処理部、指定信用情報機関サーバ16の処理部および認証局サーバ18の処理部114はそれぞれ、第1SS問い合わせ信号S1、S2、S3の受信に応じて、その保持部が有する対応する分散鍵情報を含む第1SS応答信号S4、S5、S6をインターネット6を介して発行局サーバ20に送信する。発行局サーバ20の第1分散鍵取得部106は第1SS応答信号S4、S5、S6を受信するS204。発行局サーバ20の第1秘密鍵生成部108は、受信された第1SS応答信号S4、S5、S6に含まれる3個の分散鍵情報からユーザIDA001およびサービスID甲銀行通常決済ECについての秘密鍵情報を生成し、保持部104に保持させると共に秘密鍵管理テーブル50に登録するS206。発行局サーバ20は上記の処理をユーザごと、ネット決済サービスごとに行う。ユーザIDA001のユーザは、乙電子商店サーバ12がインターネット6を介して提供するECサイトにおいて商品を選択し、支払画面において甲銀行が提供する通常決済のネット決済サービスを指定する。図17は、支払画面300の代表画面図である。支払画面300は、支払情報表示領域302と、通常決済ボタン304と、簡易決済ボタン306と、代引きボタン308と、クレジットカードボタン310と、を有する。ユーザが通常決済ボタン304を押し下げることにより、通常決済のネット決済サービスが指定される。図15に戻り、ユーザPC2は、ユーザによる通常決済のネット決済サービスの指定を決済要求S7としてインターネット6を介して乙電子商店サーバ12に送信するS208。乙電子商店サーバ12は、決済要求S7を受信すると、認証局サーバ18によって発行される署名鍵情報を検証するための検証鍵情報の更新が必要か否かを認証局サーバ18にインターネット6を介して問い合わせるS210。認証局サーバ18は、更新が必要であれば新たな検証鍵情報を、必要でなければその旨を、インターネット6を介して乙電子商店サーバ12に送信するS212。乙電子商店サーバ12は、決済要求S7を受信すると、図12に示される認証先管理テーブル22を参照して、ユーザによって指定された通常決済のネット決済サービスに対応するリダイレクト先を認証局サーバ18と決定し、ユーザPC2を認証局サーバ18のURLにリダイレクトするS214。このリダイレクトに際し、乙電子商店サーバ12またはユーザPC2からリダイレクト先である認証局サーバ18に、ユーザIDA001およびサービスID甲銀行通常決済ECが通知される。認証局サーバ18のOTP入力要求部118は、ユーザPC2がリダイレクトされると、図10に示されるOTP発行先テーブル46を参照して、ユーザによって指定された通常決済のネット決済サービスの利用認証においてOTPを発行する発行局サーバを発行局サーバ20と決定する。認証局サーバ18のOTP入力要求部118は、決定された発行局サーバ20のURLwwwhakkou...を表示しOTPの入力を促すOTP入力画面を、インターネット6を介してユーザPC2のディスプレイに表示させる。特に認証局サーバ18のOTP入力要求部118は、OTP入力画面をディスプレイに表示させるための画面情報をOTP入力要求S8としてユーザPC2に送信するS216。図18は、OTP入力画面312の代表画面図である。OTP入力画面312は、URL表示領域314と、サービスID表示領域316と、OTP入力領域318と、OKボタン320と、を有する。URL表示領域314には、認証局サーバ18によって決定された発行局サーバ20のURLが表示される。サービスID表示領域316には、ユーザによって指定された通常決済のネット決済サービスのサービスIDが表示される。OTP入力領域318、OKボタン320は後述する。図15に戻り、ユーザはユーザ携帯電話4のブラウザにURL表示領域314に表示されるURLwwwhakkou...を入力し、ユーザ携帯電話4は入力されたURLwwwhakkou...に基づいて移動体通信網8を介して発行局サーバ20にアクセスする。発行局サーバ20とユーザとの間でユーザIDA001およびパスワードを利用する所定のユーザ認証が行われる。ユーザ認証が成功すると、ユーザはサービスID表示領域316に表示されるサービスID甲銀行通常決済ECをユーザ携帯電話4に入力し、ユーザ携帯電話4はそのサービスID甲銀行通常決済ECを含む発行要求S9を移動体通信網8を介して発行局サーバ20に送信することでOTPの発行を要求するS218。発行局サーバ20の発行要求取得部110は、発行要求S9を受信する。発行局サーバ20のOTP送信部112は、発行要求取得部110によって発行要求S9が受信されると、図11に示される秘密鍵管理テーブル50から、ユーザ認証で認証されたユーザIDA001および発行要求S9に含まれるサービスID甲銀行通常決済ECに対応する秘密鍵IDSS4Aを抽出するS220。OTP送信部112は、抽出された秘密鍵IDSS4Aによって特定される秘密鍵情報に基づいてOTPを生成するS222。OTP送信部112は、生成されたOTPを含むOTP発行信号S10を移動体通信網8を介してユーザ携帯電話4に送信するS224。図16を参照すると、ユーザ携帯電話4は、OTP発行信号S10を受信すると、OTP発行信号S10に含まれるOTPをユーザ携帯電話4のディスプレイに表示させる。ユーザは、ユーザ携帯電話4のディスプレイでOTPを確認し、図18に示されるOTP入力画面312のOTP入力領域318にOTPを入力し、OKボタン320を押し下げる。ユーザPC2はOKボタン320が押し下げられると、OTP入力領域318に入力されたOTPを含む認証要求S11をインターネット6を介して認証局サーバ18に送信するS226。認証局サーバ18のOTP受信部120は認証要求S11を受信する。認証局サーバ18の第2分散鍵取得部122は、OTP受信部120によって認証要求S11が受信されると、ユーザIDA001およびサービスID甲銀行通常決済ECについて分散鍵情報を問い合わせる。第2分散鍵取得部122は第1分散鍵取得先テーブル44を参照して甲銀行決済サーバ14、指定信用情報機関サーバ16および認証局サーバ18自身を問い合わせ先として特定する。第2分散鍵取得部122は、第3分散鍵管理テーブル42からユーザIDA001およびサービスID甲銀行通常決済ECの両者に対応する第3分散鍵IDSS3Aを抽出し、抽出された第3分散鍵IDSS3Aによって特定される第3分散鍵情報を保持部116から取得する。また第2分散鍵取得部122は、ユーザIDA001およびサービスID甲銀行通常決済ECを含む第2SS問い合わせ信号S12、S13を認証局サーバ18自身以外の各問い合わせ先にインターネット6を介して送信するS228。甲銀行決済サーバ14および指定信用情報機関サーバ16はそれぞれ、第2SS問い合わせ信号S13、S12を受信すると、自身が設定する基準に基づいた独自の認証を行うS230、S232。ここでの独自の認証の結果は利用認証が成功するための必要条件を構成するが十分条件ではない。甲銀行決済サーバ14は、受信された第2SS問い合わせ信号S13に含まれるユーザIDA001によって特定されるユーザが当該甲銀行決済サーバ14において認証すべきでない対象として登録されている場合、当該甲銀行決済サーバ14の保持部が保持しているそのユーザIDA001に対応する第1分散鍵情報の認証局サーバ18への送信を制限する。図19は、甲銀行決済サーバ14における独自の認証処理の一例を示すフローチャートである。甲銀行決済サーバ14の処理部は、第2SS問い合わせ信号S13を受信しS302、受信された第2SS問い合わせ信号S13からユーザIDA001およびサービスID甲銀行通常決済ECを抽出するS304。処理部は、抽出されたサービスID甲銀行通常決済ECおよび第2SS問い合わせ信号S13の送信元である認証局サーバ18の組がサービス認証管理テーブル28に登録されているか否かを判定するS306。登録されていない場合S306のN、処理部は認証を許可しない旨を認証局サーバ18に通知するS310。これにより例えば、分散鍵情報の問い合わせが、甲銀行が利用認証を委託している認証局サーバからの問い合わせかどうかを確認することができる。登録されている場合S306のY、処理部は、抽出されたユーザIDA001によって特定されるユーザが抽出されたサービスID甲銀行通常決済ECによって特定される通常決済のネット決済サービスを利用してもよいか否かを、第1利用可否テーブル32を参照して判定するS308。利用不可と判定された場合S308の否、処理部は認証を許可しない旨を認証局サーバ18にインターネット6を介して通知するS310。利用可と判定された場合S308の可、処理部は、第1分散鍵管理テーブル26からユーザIDA001およびサービスID甲銀行通常決済ECの両者に対応する第1分散鍵IDSS1Aを抽出するS312。処理部は、抽出された第1分散鍵IDSS1Aによって特定される第1分散鍵情報を甲銀行決済サーバ14の保持部から取得し、取得された第1分散鍵情報を含む第2SS応答信号S14を認証局サーバ18にインターネット6を介して送信するS314。指定信用情報機関サーバ16は、受信された第2SS問い合わせ信号S12に含まれるユーザIDA001によって特定されるユーザが当該指定信用情報機関サーバ16において認証すべきでない対象として登録されている場合、当該指定信用情報機関サーバ16の保持部が保持しているそのユーザIDA001に対応する第2分散鍵情報の認証局サーバ18への送信を制限する。指定信用情報機関サーバ16における独自の認証処理の一例は図19に示されるものに準じる。図16に戻り、認証局サーバ18の処理部114は、甲銀行決済サーバ14または指定信用情報機関サーバ16から認証を許可しない旨の通知を受けると、利用認証の不成功をユーザPC2にインターネット6を介して通知しS234、利用認証の処理を中断または終了する。認証局サーバ18の第2分散鍵取得部122は、問い合わせ先の全てすなわち甲銀行決済サーバ14および指定信用情報機関サーバ16からそれぞれ第2SS応答信号S14、S15を受信するS236。第2分散鍵取得部122は、受信された第2SS応答信号S14、S15から、それらに含まれる2個の分散鍵情報すなわちユーザIDA001およびサービスID甲銀行通常決済ECの両者に対応する第1分散鍵情報および第2分散鍵情報を抽出するS238。認証局サーバ18の第2秘密鍵生成部124は、ユーザIDA001およびサービスID甲銀行通常決済ECについて、第2分散鍵取得部122によって取得された第1分散鍵情報、第2分散鍵情報および第3分散鍵情報から結合法則にしたがい秘密鍵情報を生成するS240。認証局サーバ18の検証部126は、生成された秘密鍵情報に基づいてOTPを生成しS242、生成されたOTPと認証要求S11に含まれるOTPとが一致するか否かを判定するS244。一致しない場合、認証局サーバ18の処理部114は利用認証の不成功をユーザPC2にインターネット6を介して通知しS246、利用認証の処理を中断または終了する。一致する場合、認証局サーバ18の検証部126は署名鍵情報を含む認証成功信号S16をユーザPC2にインターネット6を介して送信するS248。ユーザPC2は、認証成功信号S16を受信すると、受信された認証成功信号S16から署名鍵情報を抽出する。ユーザPC2は、抽出された署名鍵情報を含む署名鍵提示信号S17を乙電子商店サーバ12にインターネット6を介して送信するS250。乙電子商店サーバ12の処理部は、署名鍵提示信号S17を受信すると、受信された署名鍵提示信号S17に含まれる署名鍵情報を、予め保持している検証鍵情報によって検証するS252。検証の結果、検証鍵情報と署名鍵情報とが対応しないと判定された場合、乙電子商店サーバ12の処理部は利用認証の不成功をユーザPC2にインターネット6を介して通知しS254、利用認証の処理を中断または終了する。検証の結果、検証鍵情報と署名鍵情報とが対応すると判定された場合、乙電子商店サーバ12の処理部はユーザPC2のディスプレイに認証成功画面を表示させると共にユーザPC2を甲銀行決済サーバ14が提供する決済サイトにリダイレクトするS256。その後、決済サイトを通じて甲銀行決済サーバ14とユーザPC2との間で決済処理が行われるS258。図20は、認証成功画面322の代表画面図である。図21は、決済画面324の代表画面図である。ステップS258の決済処理において甲銀行決済サーバ14は決済画面324をユーザPC2のディスプレイに表示させる。上述の実施の形態において、保持部の例は、ハードディスクやメモリである。また、本明細書の記載に基づき、各部を、図示しないCPUや、インストールされたアプリケーションプログラムのモジュールや、システムプログラムのモジュールや、ハードディスクから読み出したデータの内容を一時的に記憶するメモリなどにより実現できることは本明細書に触れた当業者には理解されるところである。本実施の形態に係る認証システム10によると、破ることがより困難な利用認証の仕組みを実現できる。以下の4つの状況においてこの仕組みがいかに機能するかを説明する。1甲銀行や指定信用情報機関や丙セキュリティサービス社の内部から、またはインターネット6上の通信傍受によって第1分散鍵情報、第2分散鍵情報および第3分散鍵情報のうちの2つまでが外部に流出した場合この場合、秘密鍵情報は第1分散鍵情報、第2分散鍵情報および第3分散鍵情報の全てが揃わないと生成できないので、悪意の第3者が流出した分散鍵情報を手にしたとしても、認証局サーバ18における認証で必要なOTPを生成することができない。2発行局サーバ20からユーザ携帯電話4へ送信されるOTPが傍受された場合この場合、一般に認証プロセスのなかにいる真正のユーザのほうが悪意の第3者よりも早くOTPを認証局サーバ18に送る。すると認証局サーバ18におけるOTPの検証後そのOTPは破棄されるので、傍受されたOTPが悪意の第3者から送信されてきても検証を通過しない。また、悪意の第3者がOTPを真正のユーザよりも早く認証局サーバ18に送ったとしても、真正のユーザは自己のOTPが否定されたことをもって悪意の第3者の存在に気付くことができる。3秘密鍵情報が外部に流出し、悪意の第3者がOTPを複製することが可能となった場合この場合、例えば甲銀行、指定信用情報機関および丙セキュリティサービス社のうちの少なくともひとつが任意のタイミングで、例えば定期的に、自己の分散鍵情報の更新を行うことで、OTPの複製のリスクを回避できる。すなわち、漏洩した可能性のある秘密鍵情報を任意のタイミングで無効にすることができる。4ユーザが署名鍵情報を偽造し、認証局サーバ18や発行局サーバ20を通さずに偽造した署名鍵情報を乙電子商店サーバ12に提供した場合この場合、乙電子商店サーバ12における署名鍵の検証は通過するかも知れないが、偽造された署名鍵情報に係るネット決済サービスについて甲銀行決済サーバ14は認証局サーバ18から分散鍵情報の要求を受けていないので、その事実をもって偽造を検知できる。すなわち、甲銀行決済サーバ14に利用認証に係る分散鍵情報が分配されている場合、このような署名鍵偽造の場合も検知できる。また、本実施の形態に係る認証システム10では、甲銀行決済サーバ14は第1分散鍵情報を有しており、利用認証の際に認証局サーバ18からの問い合わせに応じて第1分散鍵情報を提供するか否かを通じて利用認証に参加することとなる。したがって、利用認証を丙セキュリティサービス社に委託する甲銀行自体が認証リスクをコントロールすることができる。また、甲銀行は自らが独自に設定できるブラックリストすなわち第1利用可否テーブル32に照らし合わせてユーザへの認証判断を行うことができる。また、本実施の形態に係る認証システム10では、指定信用情報機関サーバ16は第2分散鍵情報を有しており、利用認証の際に認証局サーバ18からの問い合わせに応じて第2分散鍵情報を提供するか否かを通じて利用認証に参加することとなる。したがって、甲銀行から信用認証を委託された指定信用情報機関は信用情報に照らし合わせてユーザへの認証判断を行うことができる。これにより、甲銀行は委託先を適宜設定することで自己や丙セキュリティサービス社では設定が困難な判断軸に基づいた認証判断を利用認証に組み込むことができる。また、本実施の形態に係る認証システム10では、発行局サーバ20はユーザからの発行要求の取得にかかわらずに分散鍵情報を問い合わせて取得する。したがって、ユーザからの発行要求の取得を契機として分散鍵情報を問い合わせる場合と比較して、1回の利用認証に必要な通信量を低減できる。また、発行局サーバ20ではユーザからの発行要求の取得に同期して分散鍵情報を問い合わせる必要はないので、例えば夜間等の通信量の比較的少ない期間に分散鍵情報を集めておくことができ効率的である。また、本実施の形態に係る認証システム10ではユーザに秘密鍵情報に基づくOTPを発行する。これにより、他のより複雑な認証情報を使用する場合と比較してユーザの負担、手間を軽減できる。特にOTPをユーザPC2に打ち込むことは比較的容易であり、ユーザPC2およびユーザ携帯電話4の両方を使用する現実的な認証システムが提供される。利用認証に関わるユーザ側の端末の数を増やすことにより利用認証をよりセキュアにできる。以上、実施の形態に係る認証システム10の構成と動作について説明した。この実施の形態は例示であり、その各構成要素や各処理の組み合わせにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。実施の形態では、認証システム10は3個の分散鍵情報とその3個の分散鍵情報から結合法則にしたがい生成される秘密鍵情報と、を使用する場合について説明したが、これに限られず、Nを2以上の整数とするとき、N個の分散鍵情報と、そのN個の分散鍵情報から所定の法則にしたがい生成される秘密鍵情報と、を使用する認証システムであればよい。この認証システムは、認証局サーバとN-1台の認証関連サーバとを備え、N個の分散鍵情報はN-1台の認証関連サーバおよび認証局サーバにひとつずつ分配されていてもよい。甲銀行決済サーバはN-1台の認証関連サーバのうちのひとつであってもよい。指定信用情報機関サーバはN-1台の認証関連サーバのうちのひとつであってもよい。乙電子商店サーバはN-1台の認証関連サーバのうちのひとつであってもよい。実施の形態では、認証局サーバ18と発行局サーバ20とが別体のサーバでありインターネット6を介して互いに通信する場合について説明したが、これに限られず、認証システムは認証局サーバ18、発行局サーバ20の代わりに認証局サーバ18の機能および発行局サーバ20の機能の両方を備える単体のサーバを備えてもよい。実施の形態では、甲銀行決済サーバ14はインターネット6を介して乙電子商店サーバ12にネット決済機能を提供する場合について説明したが、これに限られない。例えば認証システムは、認証局サーバ18と、発行局サーバ20と、認証局サーバ18におけるOTPの検証の結果を利用するサービスを提供するサービス提供サーバと、サービス提供サーバによって提供されるサービスを利用するサービス利用サーバと、を備えてもよい。実施の形態では、甲銀行は指定信用情報機関に信用認証を委託する場合について説明したが、これに限られず、例えば甲銀行はユーザ認証以外の所定の認証を所定の機関に委託してもよい。この所定の機関は、例えば業界標準団体や公的な管轄機関例えば、金融庁や警察庁やインターネットにおける発言ログなどを管理する機関である。この場合、その所定の機関が管理するサーバに分散鍵情報が分配される。実施の形態では、ユーザPC2およびユーザ携帯電話4を利用して利用認証を行う場合について説明したが、これに限られず、例えばユーザPCのみで利用認証を行ってもよい。この場合、例えばOTP入力画面はOTP生成ボタンを有してもよく、このボタンが押し下げられるとユーザPCは発行局サーバ20にインターネット6を介してアクセスし、OTPの発行を要求する。この要求に対して発行されたOTPは、例えばユーザPCのディスプレイに別画面で表示されてもよい。あるいはまた、ユーザはユーザPCまたはユーザ携帯電話から電子メールを使用してOTPの発行を要求してもよい。実施の形態では、乙電子商店サーバ12は認証先管理テーブル22を有しユーザPC2リダイレクトの際にはこの認証先管理テーブル22を参照する場合について説明したが、これに限られず、乙電子商店サーバはユーザPC2リダイレクトの際リダイレクト先を甲銀行決済サーバに問い合わせてもよい。実施の形態では、認証局サーバ18の第2分散鍵取得部122はOTP受信部120によってOTPが受信されると分散鍵情報を取得する場合について説明したが、これに限られず、第2分散鍵取得部は認証情報の検証が要求されると分散鍵情報を取得してもよい。例えば、第2分散鍵取得部はユーザPC2がリダイレクトされてきたことを契機として分散鍵情報を取得してもよい。ユーザPC2のリダイレクトもまたOTPの検証の要求とみなされうるからである。実施の形態では、甲銀行決済サーバ14および指定信用情報機関サーバ16において、認証局サーバ18からの分散鍵情報の問い合わせに応じて独自の認証処理が行われる場合について説明したが、これに限られず、例えば発行局サーバ20からの分散鍵情報の問い合わせに応じて独自の認証処理が行われてもよい。実施の形態の図15および図16に示されるチャートでは、ユーザによって通常決済のネット決済サービスが指定され、利用認証に3個の分散鍵情報が使用される場合について説明したが、これに限られない。例えば、ユーザによって簡易決済のネット決済サービスが指定された場合、認証局サーバ18の第2分散鍵取得部122および発行局サーバ20の第1分散鍵取得部106はそれぞれ、図9に示される第1分散鍵取得先テーブル44およびそれと同様な第2分散鍵取得先テーブル52を参照し、甲銀行決済サーバ14および認証局サーバ18からひとつずつ合計2個の分散鍵情報を取得してもよい。実施の形態では、認証システム10はサービス提供サーバとして甲銀行によって管理される甲銀行決済サーバ14を含み、委託先サーバとして指定信用情報機関によって管理される指定信用情報機関サーバ16を含む場合について説明したが、これに限られず、例えばサービス提供サーバは子会社や日本ブランチやアクワイアラーによって管理されるサーバであってもよく、委託先サーバはそれらに対応する親会社や海外本社やイシュアラーによって管理されるサーバであってもよい。