(57)【要約】【課題】テンプレート保護技術において、変換パラメータの改竄によるなりすまし攻撃を防止する。【解決手段】認証システム９は、ソルト生成サーバ１とサービスを提供するサービス側サーバ３とがクライアント端末４の生体データから生成されたテンプレートを認証する。ソルト生成サーバ１は、サービス側サーバ３が提供するサービスの識別情報をパラメータとして得られる乱数ソルトであって変換パラメータを生成するために用いられる乱数ソルトを生成する。ソルト生成サーバ１は、生成された乱数ソルトを秘密鍵２３によって署名された署名乱数ソルトをサービス側サーバ３に配布する。サービス側サーバ３は、秘密鍵２３に対応する公開鍵３５を用いて署名乱数ソルトの署名を検証する。サービス側サーバ３は、署名乱数ソルトの署名の検証に成功すると、署名乱数ソルトを管理する。【選択図】図１
2019036781.tif 000002
【特許請求の範囲】
【請求項１】
第１サーバとサービスを提供する第２サーバとがクライアント端末の生体データから生成されたテンプレートを認証する認証システムにおいて、
前記第１サーバは、
前記第２サーバが提供するサービスの識別情報をパラメータとして得られる乱数ソルトであって変換パラメータを生成するために用いられる乱数ソルトを生成する生成部と、
前記生成部によって生成された乱数ソルトを秘密鍵によって署名された署名乱数ソルトを前記第２サーバに配布する配布部と、を有し、
前記第２サーバは、
前記秘密鍵に対応する公開鍵を用いて前記署名乱数ソルトの署名を検証する検証部と、
前記検証部によって前記署名乱数ソルトの署名の検証に成功すると、前記署名乱数ソルトを管理する管理部と、を有する
ことを特徴とする認証システム。
【請求項２】
前記生成部は、新たなサービスの連携の依頼を受け付けると、前記新たなサービスに対応する前記第２サーバが提供するサービスの識別情報をパラメータとする乱数ソルトを生成し、前記第２サーバと異なる他の第２サーバから乱数ソルトを収集し、収集した乱数ソルトを用いて、生成した乱数ソルトとの重複をチェックし、重複がなくなるまで乱数ソルトを再生成する
ことを特徴とする請求項１に記載の認証システム。
【請求項３】
前記クライアント端末は、
クライアントのテンプレートを登録または認証する際に、所望するサービスを提供する前記第２サーバにサービスの識別情報を送信する送信部と、
前記第２サーバから、前記サービスの識別情報に対応する署名乱数ソルトを受信する受信部と、
前記秘密鍵に対応する公開鍵を用いて前記署名乱数ソルトの署名を検証する検証部と、
前記検証部によって前記署名乱数ソルトの署名の検証に成功すると、乱数ソルトを用いて生体データからテンプレートを生成するデータ生成部と、
前記データ生成部によって生成されたテンプレートを前記第２サーバに対して登録または認証を要求する要求部と、
を有することを特徴とする請求項１または請求項２に記載の認証システム。
【請求項４】
前記クライアント端末において、
前記検証部は、前記第２サーバから送信された前記署名乱数ソルトの署名を検証するとともに、前記第１サーバに前記第２サーバへの前記署名乱数ソルトの配布結果のチェックを依頼し、
前記データ生成部は、前記検証部によって前記署名乱数ソルトの署名の検証に成功し、且つ前記署名乱数ソルトの配布結果が正常であれば、乱数ソルトを用いてテンプレートを生成する
ことを特徴とする請求項３に記載の認証システム。
【請求項５】
前記データ生成部は、前記乱数ソルトを用いて変換パラメータを生成し、生成した変換パラメータを用いてテンプレートを生成する機能を認証ライブラリの内部で実行する
ことを特徴とする請求項３または請求項４に記載の認証システム。
【請求項６】
前記配布部は、前記生成部によって生成された乱数ソルトを前記第１サーバで秘密鍵によって署名し、署名された署名乱数ソルトを前記第２サーバに配布する
ことを特徴とする請求項１に記載の認証システム。
【請求項７】
前記第２サーバは、
新たなサービスの識別情報をパラメータとする乱数ソルトを生成する生成部と、
前記生成部によって生成された乱数ソルトを秘密鍵によって署名された署名乱数ソルトをサービスごとに管理する管理部と、
をさらに有することを特徴とする請求項１に記載の認証システム。
【請求項８】
前記第２サーバにおいて、
前記生成部が、新たなサービスの識別情報をパラメータとする、乱数ソルトおよびチャレンジを生成し、前記乱数ソルトおよびチャレンジを前記クライアント端末に送信し、
さらに、前記クライアント端末によって生成されたテンプレートを、前記乱数ソルトおよびチャレンジを用いて認証する認証部を有する
ことを特徴とする請求項７に記載の認証システム。
【請求項９】
第１サーバとサービスを提供する第２サーバとがクライアント端末の生体データから生成されたテンプレートを認証する認証システムの認証方法であって、
前記第１サーバは、
前記第２サーバが提供するサービスの識別情報をパラメータとして得られる乱数ソルトであって変換パラメータを生成するために用いられる乱数ソルトを生成し、
該生成した乱数ソルトを秘密鍵によって署名された署名乱数ソルトを前記第２サーバに配布し、
前記第２サーバは、
前記秘密鍵に対応する公開鍵を用いて、前記第１サーバから配布された前記署名乱数ソルトの署名を検証し、
前記署名乱数ソルトの署名の検証に成功すると、前記署名乱数ソルトを管理する
処理を実行する認証方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認証システムなどに関する。
【背景技術】
【０００２】
近年、スマートフォンやタブレットなどのモバイル端末からクラウドサービスを利用する際に、生体認証を使って本人を確認する技術が知られている。かかる技術には、生体データをあらかじめ生体保護データ（テンプレート）に変換して登録しておき、認証時に取得した生体データを変換して、登録されているテンプレートと照合して本人を確認する生体テンプレート保護技術がある。生体テンプレート保護技術では、テンプレートを、変換パラメータを使って生成する。
【０００３】
テンプレート保護技術の一例として、クライアント側で変換パラメータを管理する技術がある（例えば、特許文献１参照）。かかる技術では、クライアント端末が、登録時に、ユーザの生体情報を取得し、取得した生体情報を、ＩＣカード等に保存された変換パラメータであってユーザに対して発行された変換パラメータで変換してテンプレートを作成する。そして、クライアント端末は、作成したテンプレートを変換パラメータに対する検証情報とともに認証サーバに登録する。認証サーバは、認証時に、検証情報を用いてクライアント端末が変換パラメータを知っていることを検証し、ユーザの生体情報を変換パラメータで変換した照合情報とテンプレートとを照合することで本人確認を行う。
【０００４】
また、別のテンプレート保護技術の例として、サーバ側で変換パラメータを管理する技術がある（例えば、特許文献３参照）。かかる技術では、パラメータ管理サーバが、クライアント端末から送られたユーザＩＤと、マスター鍵と、一時パラメータとを用いて変換パラメータを生成する。クライアント端末は、生体情報センサによって取得された生体情報から特徴量を抽出し、パラメータ管理サーバで生成された変換パラメータを用いて特徴量を変換して変換特徴量を生成する。認証サーバは、クライアント端末から送られた変換特徴量と予め補完されたテンプレートとを照合することで本人確認を行う。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−９２４１３号公報
【特許文献２】特開２０１３−１７８８０１号公報
【特許文献３】特開２００９−９２９３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、従来のテンプレート保護技術では、変換パラメータが改竄されると、攻撃者によるなりすまし攻撃を防止することができないという問題がある。
【０００７】
例えば、テンプレート保護技術の一例では、クライアント端末が、攻撃者により改竄された変換パラメータを使って任意の生体保護データを生成することにより、なりすまし攻撃が可能となり、なりすまし攻撃を防止することができない。
【０００８】
テンプレート保護技術の別の例では、パラメータ管理サーバが変換パラメータを生成し、生成した変換パラメータをクライアント端末に送信する。したがって、変換パラメータがパラメータ管理サーバからクライアント端末に送信される際に変換パラメータが改竄されると、クライアント端末は、偽の変換パラメータと偽の生体データを使って任意の生体保護データを生成することになる。この結果、攻撃者によるなりすまし攻撃を防止することができない。
【０００９】
本発明は、１つの側面では、テンプレート保護技術において、変換パラメータの改竄によるなりすまし攻撃を防止することを目的とする。
【課題を解決するための手段】
【００１０】
１つの態様では、認証システムは、第１サーバとサービスを提供する第２サーバとクライアント端末とを有する。前記第１サーバは、前記第２サーバが提供するサービスの識別情報をパラメータとする乱数ソルトであって変換パラメータを生成するために用いられる乱数ソルトを生成する生成部と、前記生成部によって生成された乱数ソルトを秘密鍵によって署名された署名乱数ソルトを前記第２サーバに配布する配布部と、を有する。前記第２サーバは、前記秘密鍵に対応する公開鍵を用いて前記署名乱数ソルトの署名を検証する検証部と、前記検証部によって前記署名乱数ソルトの署名の検証に成功すると、前記署名乱数ソルトを管理する管理部と、を有する。
【発明の効果】
【００１１】
１実施態様によれば、テンプレート保護技術において、変換パラメータの改竄によるなりすまし攻撃を防止することができる。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１に係る認証システムの構成を示す機能ブロック図である。
【図２】図２は、実施例１に係るソルト生成の一例を説明する図である。
【図３】図３は、メタデータの一例を示す図である。
【図４】図４は、実施例１に係るソルト署名検証結果管理テーブルの一例を示す図である。
【図５Ａ】図５Ａは、実施例１に係るソルト管理テーブルの一例を示す図である。
【図５Ｂ】図５Ｂは、実施例１に係るソルト管理テーブルの別の例を示す図である。
【図６】図６は、実施例１に係るソルト生成処理のフローチャートの一例を示す図である。
【図７】図７は、実施例１に係るソルト管理処理のフローチャートの一例を示す図である。
【図８】図８は、実施例１に係る生体保護データ生成処理のフローチャートの一例を示す図である。
【図９】図９は、実施例１に係る保護データ生成可否判定処理のフローチャートの一例を示す図である。
【図１０】図１０は、実施例２に係る認証システムの構成を示す機能ブロック図である。
【図１１】図１１は、実施例２に係るソルト生成処理のフローチャートの一例を示す図である。
【図１２】図１２は、実施例３に係る認証システムの構成を示す機能ブロック図である。
【図１３】図１３は、実施例３に係る保護データ生成可否判定処理のフローチャートの一例を示す図である。
【図１４】図１４は、実施例４に係る認証システムの構成を示す機能ブロック図である。
【図１５】図１５は、実施例５に係る認証システムの構成を示す機能ブロック図である。
【図１６】図１６は、実施例５に係るソルト管理テーブルの一例を示す図である。
【図１７】図１７は、認証プログラムを実行するコンピュータの一例を示す図である。
【発明を実施するための形態】
【００１３】
以下に、本願の開示する認証システムおよび認証方法の実施例を図面に基づいて詳細に説明する。なお、本発明は、実施例により限定されるものではない。
【実施例１】
【００１４】
［実施例に係る認証システムの構成］
図１は、実施例１に係る認証システムの構成を示す機能ブロック図である。図１に示す認証システム９は、テンプレートと呼ばれる生体データから生成された生体保護データ（テンプレート）を登録しておき、認証時に取得した生体データを変換したデータと照合することで本人を確認する生体テンプレート保護機能を備える。サービス側のサーバは、サービスにアクセスするクライアントの生体保護データを認証するために、テンプレート保護で用いる変換パラメータの元データであるソルトの署名つきソルトを管理する。このため、認証システム９は、サービス側のサーバが追加されるとき、信頼できる認証局にテンプレート保護で用いるソルトを署名させ、サービス側のサーバへの署名つきソルトの配布を署名検証に成功したときだけ可能とする。なお、ここでいう「変換パラメータ」とは、生体データから生体保護データに変換する際に用いられるパラメータのことをいう。「ソルト」とは、変換パラメータを生成するための元データのことをいい、例えば疑似乱数生成器により得られる乱数で表わされる。
【００１５】
認証システム９は、ソルト生成サーバ１、認証局２、サービス側サーバ３およびクライアント端末４を有する。
【００１６】
ソルト生成サーバ１は、サービスに対応するソルトを生成し、サービスを提供するサービス側サーバ３に、生成したソルトを配信する。ソルト生成サーバ１は、サービス連携部１１、ソルト生成部１２およびソルト署名検証結果管理テーブル１３を有する。なお、ソルト生成部１２は、生成部および配布部の一例である。
【００１７】
サービス連携部１１は、新規のサービスを提供するサービス側サーバ３をソルト生成サーバ１に連携させるとき、連携するサービス側サーバ３から、サービスの識別情報を取得する。そして、サービス連携部１１は、取得した識別情報をソルト生成部１１に引き渡す。ここでいう識別情報とは、例えば、サービスのアドレスを含む。サービスのアドレスは、メタデータに含まれる。
【００１８】
ソルト生成部１２は、サービスに対応するソルトを生成する。例えば、ソルト生成部１１は、サービス連携部１２から引き渡されたサービスの識別情報をパラメータとして疑似乱数生成器に引き渡し、出力された乱数をソルトとして生成する。
【００１９】
ここで、ソルト生成の一例を、図２を参照して説明する。なお、図２では、ソルト生成サーバ１が新規のサービスＸと連携する場合であるとする。図２は、実施例１に係るソルト生成の一例を説明する図である。図２に示すように、サービス連携部１１は、新規のサービスＸのメタデータ３４が存在するアドレスを登録する（ａ１）。サービス連携部１１は、登録したサービスＸのアドレスからサービスＸのメタデータ３５を取得し（ａ２）、ソルト生成部１２に引き渡す。ここでいうメタデータ３５には、サービスＸのアドレス３４ａおよびサービスＸのサーバ証明書３４ｂが含まれる。そして、ソルト生成部１２は、サービス連携部１１から引き渡されたメタデータ３４に含まれるサービスＸのアドレス３４ａをパラメータとして疑似乱数生成器に引き渡し（ａ３）、出力された乱数をソルトとして生成する（ａ４）。なお、ソルト生成部１２は、ソルトを、サービスＸのアドレス３４ａの代わりに、サービスＸのサーバ証明書３４ｂに含まれるコモンネームを用いて生成しても良い。
【００２０】
ここで、サービスＸのメタデータ３４の一例を、図３を参照して説明する。図３は、メタデータの一例を示す図である。図３に示すように、サービスＸのメタデータファイルには、サービスＸのアドレス３４ａとしてサービスＸのＵＲＬ（Uniform  Resource  Locator）「ｈｔｔｐｓ：・・・」が設定されている。サービスＸのサーバ証明書３４ｂとして「ＧＩＦＩＡＣＡｇｗ・・・」が設定されている。
【００２１】
図１に戻って、また、ソルト生成部１２は、生成されたソルトの署名を認証局２に依頼する。ソルト生成部１２は、署名されたソルトを、サービスを提供するサービス側サーバ３に配布する。そして、ソルト生成部１２は、署名つきソルトの配布先と配布履歴をサービスに対応づけてソルト署名検証結果管理テーブル１３に記録する。
【００２２】
また、ソルト生成部１２は、サービス側サーバ３から署名ソルトの署名検証結果を受け付けると、署名検証結果をサービスに対応づけてソルト署名検証結果管理テーブル１３に記録する。
【００２３】
ソルト署名検証結果管理テーブル１３は、署名つきソルトをサービス側サーバ３へ配布した際の配布履歴および署名つきソルトのサービス側サーバ３での検証結果を管理する。ここで、ソルト署名検証結果管理テーブル１３の一例を、図４を参照して説明する。
【００２４】
図４は、実施例１に係るソルト署名検証結果管理テーブルの一例を示す図である。図４に示すように、ソルト署名検証結果管理テーブル１３は、日時１３ａ、署名つきソルトの配布先１３ｂ、サービスＩＤ１３ｃおよび署名検証結果１３ｄを対応づけて記憶する。日時１３ａは、署名つきソルトを配布した日時、または署名つきソルトの署名検証結果を受け付けた日時である。署名つきソルトの配布先１３ｂは、署名つきソルトを配布したサービスのアドレスを示す。サービスのアドレスには、一例として、サービスのＵＲＬが挙げられる。サービスＩＤ（identifier）１３ｃは、サービスを一意に識別する識別子を示す。署名検証結果１３ｄは、署名つきソルトを、サービスを提供するサービス側サーバ３で検証した結果を示す。言い換えれば、署名検証結果１３ｄは、ソルト生成サーバ１からサービス側サーバ３へ署名つきソルトを配布した配布結果を示す。一例として、署名の検証に成功した場合には、署名検証結果１３には、「検証成功」が記憶される。署名の検証に失敗した場合には、署名検証結果１３には、「検証失敗」が記憶される。
【００２５】
一例として、日時１３ａが「2016/12/22  20:10:10」である場合に、署名つきソルトの配布先１３ｂとして「https://serviceX/」、サービスＩＤ１３ｃとして「１」、署名検証結果１３ｄとして「検証成功」が記憶されている。
【００２６】
図１に戻って、認証局２は、ソルトを署名する。例えば、認証局２は、電子認証において信頼できる第３者機関（ＴＴＰ：Trusted  Third  Party）のことをいう。認証局２は、署名部２１を有し、公開鍵２２および秘密鍵２３を管理する。
【００２７】
署名部２１は、ソルト生成サーバ１からソルトの署名の依頼を受け付けると、秘密鍵２３を用いて当該ソルトを署名する。そして、署名部２１は、署名つきソルトをソルト生成サーバ１に送信する。
【００２８】
サービス側サーバ３は、ソルトを管理し、ソルトを用いて生成された生体保護データを認証する。サービス側サーバ３は、ソルト署名検証部３１、ソルト管理部３２および認証部３３を有する。また、サービス側サーバ３は、メタデータ３４、公開鍵３５、ソルト管理テーブル３６および生体保護データ３７を有する。なお、ソルト署名検証部３１は、検証部の一例である。ソルト管理部３２は、管理部の一例である。
【００２９】
メタデータ３４は、サービスごとに備える。メタデータ３４の内容は、図３で説明したとおりであるので、その説明を省略する。メタデータ３４は、ソルト生成サーバ１からのサービスの連携要求に基づいてソルト生成サーバ１に送信される。
【００３０】
公開鍵３５は、認証局２に管理された公開鍵２２と同じものである。
【００３１】
ソルト管理テーブル３６は、署名つきソルトをサービスおよびソルトに対応づけて管理する。なお、ソルト管理テーブル３６のデータ構造は、後述する。
【００３２】
生体保護データ３７は、ユーザごとに記憶される。なお、生体保護データ３７は、クライアント端末４によって生成される。
【００３３】
ソルト署名検証部３１は、署名つきソルトを検証する。例えば、ソルト署名検証部３１は、ソルト生成サーバ１から署名つきソルトを受け取ると、公開鍵３６を用いて署名つきソルトの署名を検証する。そして、ソルト署名検証部３１は、署名検証結果をソルト生成サーバ１に送信する。
【００３４】
ソルト管理部３２は、署名検証に成功した場合には、署名つきソルトを管理する。例えば、ソルト管理部３２は、ソルト署名検証部３１によって署名つきソルトの署名の検証に成功した場合には、署名つきソルトをサービスおよびソルトに対応づけてソルト管理テーブル３６に記録する。
【００３５】
ここで、ソルト管理テーブル３６の一例を、図５Ａおよび図５Ｂを参照して説明する。図５Ａは、実施例１に係るソルト管理テーブルの一例を示す図である。図５Ａに示すように、ソルト管理テーブル３６は、更新日時３６ａ、サービスＩＤ３６ｂ、ソルトＩＤ３６ｃおよび署名つきソルト３６ｄを対応づけて記憶する。更新日時３６ａは、このレコードを更新した日時を示す。サービスＩＤ３６ｂは、サービスを一意に識別する識別子を示す。サービスＩＤ３６ｂは、図４のサービスＩＤ１３ｃに対応する。ソルトＩＤ３６ｃは、ソルトを一意に識別する識別子を示す。署名つきソルト３６ｄは、署名検証に成功した署名つきのソルトである。
【００３６】
一例として、更新日時３６ａが「2016/12/22  20:10:10」である場合に、サービスＩＤ３６ｂとして「１」、ソルトＩＤ３６ｃとして「１」、署名つきソルト３６ｄとして「ａ／nft0a23/s1gia1」を記憶している。
【００３７】
図５Ｂは、実施例１に係るソルト管理テーブルの別の例を示す図である。図５Ａでは、ソルト管理テーブル３６は、サービスＩＤ３６ｂごとに、署名つきソルト３６ｄを管理すると説明した。図５Ｂでは、ソルト管理テーブル３６は、サービスＩＤ３６ｂおよびユーザＩＤ３６ｅごとに、署名つきソルト３６ｄを管理する。すなわち、ソルト管理テーブル３６が、サービスに加えてユーザごとのソルトを管理する場合である。図５Ｂに示すように、ソルト管理テーブル３６は、更新日時３６ａ、サービスＩＤ３６ｂ、ユーザＩＤ３６ｅ、ソルトＩＤ３６ｃおよび署名つきソルト３６ｄを対応づけて記憶する。ユーザＩＤ３６ｅは、ユーザを一意に識別する識別子を示す。
【００３８】
一例として、更新日時３６ａが「2016/12/22  20:10:10」である場合に、サービスＩＤ３６ｂとして「１」、ユーザＩＤ３６ｅとして「user001」、ソルトＩＤ３６ｃとして「１」、署名つきソルト３６ｄとして「ａ／nft0a23/s1gia1」を記憶している。同じサービスＩＤ３６ｂについて、更新日時３６ａが「2016/12/23  12:05:35」である場合に、ユーザＩＤ３６ｅとして「user002」、ソルトＩＤ３６ｃとして「２」、署名つきソルト３６ｄとして「Pagpo＆t0a8nbafa?」を記憶している。
【００３９】
なお、ソルト管理テーブル３６は、さらに、生体認証の種別を追加しても良い。例えば、生体認証の種別として指紋認証や手のひら静脈認証などを追加しても良い。また、ソルト管理テーブル３６は、さらに、生体認証の種別およびどの認証される対象を追加しても良い。例えば、生体認証の種別として指紋認証、認証される対象として右手人差し指などを追加しても良い。生体認証の種別として手のひら静脈認証、認証される対象として右手を追加しても良い。
【００４０】
図１に戻って、認証部３３は、クライアント端末４から送信されたサービスＩＤを受け付けると、ソルト管理テーブル３６を参照し、サービスＩＤに対応する署名つきソルト３６ｄを取得し、取得した署名つきソルト３６ｄをクライアント端末４に送信する。
【００４１】
また、認証部３３は、クライアント端末４から生体保護データの登録処理要求を受け付けると、クライアント端末４から送信されたユーザの生体保護データを記憶部に登録する。また、認証部３３は、クライアント端末４から生体保護データの認証処理要求を受け付けると、クライアント端末４から送信されたユーザの生体保護データと登録された生体保護データ３７とを照合し、送信された生体保護データを認証する。
【００４２】
クライアント端末４は、サービス側サーバ３に生体保護データを登録または認証させる場合に、サービス側サーバ３から署名つきソルトを取得し、署名つきソルトの署名の検証に成功したソルトを用いて変換パラメータを生成する。そして、クライアント端末４は、変換パラメータと生体データとを用いて生体保護データを生成する。クライアント端末４は、ソルト署名検証部４１、変換パラメータ生成部４２および生体保護データ生成部４３を有する。また、クライアント端末４は、公開鍵４４を有する。なお、ソルト署名検証部４１、変換パラメータ生成部４２および生体保護データ生成部４３は、認証ライブラリ４０に組み込まれる。これにより、生成される変換パラメータが認証ライブラリ４０の内部に隠蔽されることができる。また、ソルト署名検証部４１は、送信部および受信部の一例である。変換パラメータ生成部４２および生体保護データ生成部４３は、データ生成部の一例である。生体保護データ生成部４３は、要求部の一例である。
【００４３】
公開鍵４４は、認証局２に管理された公開鍵２２と同じものである。
【００４４】
ソルト署名検証部４１は、署名つきソルトを検証する。例えば、ソルト署名検証部４１は、生体保護データの登録要求または認証要求を受け付けると、所望するサービスを提供するサービス側サーバ３に当該サービスのサービスＩＤを送信し、サービス側サーバ３からサービスＩＤに対応する署名つきソルトを受信する。そして、ソルト署名検証部４１は、受信した署名つきソルトの署名を、公開鍵４４を用いて検証する。そして、ソルト署名検証部４１は、署名検証に成功すると、ソルトを変換パラメータ生成部４２に引き渡す。
【００４５】
変換パラメータ生成部４２は、署名検証に成功したソルトをパラメータとして変換パラメータを生成する。
【００４６】
生体保護データ生成部４３は、変換パラメータ生成部４２によって生成された変換パラメータと生体データとを用いて生体保護データを生成する。なお、生体データは、クライアント端末４に内蔵または外付けされた生体センサから取得されれば良い。生体センサには、例えば、指紋センサや手のひら静脈センサなどが挙げられる。そして、生体保護データ生成部４３は、生成した生体保護データとサービスＩＤとユーザを一意に識別するユーザＩＤとを含む、生体保護データの登録処理または認証処理をサービス側サーバ３に要求する。
【００４７】
［ソルト生成サーバ１側のソルト生成処理のフローチャート］
ここで、ソルト生成サーバ１側のソルト生成処理のフローチャートを、図６を参照して説明する。図６は、実施例１に係るソルト生成処理のフローチャートの一例を示す図である。
【００４８】
図６に示すように、サービス連携部１１は、新規サービスの連携の依頼を受け付けたか否かを判定する（ステップＳ１１）。新規サービスの連携の依頼を受け付けていないと判定した場合には（ステップＳ１１；Ｎｏ）、サービス連携部１１は、当該依頼を受け付けるまで、判定処理を繰り返す。
【００４９】
一方、新規サービスの連携の依頼を受け付けたと判定した場合には（ステップＳ１１；Ｙｅｓ）、サービス連携部１１は、連携するサービスのメタデータが公開されているアドレスを登録する（ステップＳ１２）。そして、サービス連携部１１は、サービスを提供するサーバ環境からメタデータを取得する（ステップＳ１３）。
【００５０】
サービス連携部１１は、メタデータの取得に成功したか否かを判定する（ステップＳ１４）。メタデータの取得に成功しなかったと判定した場合には（ステップＳ１４；Ｎｏ）、サービス連携部１１は、ソルト生成処理を終了する。
【００５１】
一方、メタデータの取得に成功したと判定した場合には（ステップＳ１４；Ｙｅｓ）、ソルト生成部１２は、メタデータからサービスのアドレスを抽出する（ステップＳ１５）。そして、ソルト生成部１２は、サービスのアドレスをパラメータとしてソルトを生成する（ステップＳ１６）。例えば、ソルト生成部１２は、サービスのアドレスをパラメータとして疑似乱数生成器に引き渡し、出力された乱数をソルトとして生成する。
【００５２】
続いて、ソルト生成部１２は、認証局２にソルトの署名を依頼する（ステップＳ１７）。そして、ソルト生成部１２は、認証局２から、秘密鍵２３を使って署名された署名つきソルトを取得する（ステップＳ１８）。ソルト生成部１２は、署名つきソルトを、サービスを提供するサービス側サーバ３に送信する（ステップＳ１９）。
【００５３】
その後、ソルト生成部１２は、サービス側サーバ３から署名検証結果を受け取ったか否かを判定する（ステップＳ２０）。署名検証結果を受け取っていないと判定した場合には（ステップＳ２０；Ｎｏ）、ソルト生成部１２は、署名検証結果を受け取るまで、判定処理を繰り返す。
【００５４】
一方、署名検証結果を受け取ったと判定した場合には（ステップＳ２０；Ｙｅｓ）、ソルト生成部１２は、サービス側サーバ３における署名検証結果を管理する（ステップＳ２１）。例えば、ソルト生成部１２は、ソルト署名検証結果管理テーブル１３に対して署名検証結果をサービスに対応づけて記録する。そして、ソルト生成部１２は、ソルト生成処理を終了する。
【００５５】
［サービス側サーバ３のソルト管理処理のフローチャート］
ここで、サービス側サーバ３のソルト管理処理のフローチャートを、図７を参照して説明する。図７は、実施例１に係るソルト管理処理のフローチャートの一例を示す図である。
【００５６】
図７に示すように、ソルト署名検証部３１は、署名つきソルトを受け付けたか否かを判定する（ステップＳ３１）。署名つきソルトを受け付けていないと判定した場合には（ステップＳ３１；Ｎｏ）、ソルト署名検証部３１は、受け付けるまで、判定処理を繰り返す。
【００５７】
一方、署名つきソルトを受け付けたと判定した場合には（ステップＳ３１；Ｙｅｓ）、ソルト署名検証部３１は、公開鍵３５で署名つきソルトを検証する（ステップＳ３２）。ソルト管理部３２は、検証に成功したか否かを判定する（ステップＳ３３）。検証に成功したと判定した場合には（ステップＳ３３；Ｙｅｓ）、ソルト管理部３２は、署名つきソルトをサービスおよびソルトに対応づけてソルト管理テーブル３６に登録する（ステップＳ３４）。そして、ソルト管理部３２は、ステップＳ３６に移行する。
【００５８】
一方、検証に成功しなかったと判定した場合には（ステップＳ３３；Ｎｏ）、ソルト管理部３２は、署名つきソルトをソルト管理テーブル３６に登録しない（ステップＳ３５）。そして、ソルト管理部３２は、ステップＳ３６に移行する。
【００５９】
ステップＳ３６において、ソルト管理部３２は、署名検証結果をソルト生成サーバ１に返信する（ステップＳ３６）。そして、ソルト管理部３２は、ソルト管理処理を終了する。
【００６０】
［クライアント端末４の生体保護データ生成処理のフローチャート］
ここで、クライアント端末４の生体保護データ生成処理のフローチャートを、図８を参照して説明する。図８は、実施例１に係る生体保護データ生成処理のフローチャートの一例を示す図である。
【００６１】
図８に示すように、ソルト署名検証部４１は、ユーザから生体保護データの登録要求または認証要求を受け付けたか否かを判定する（ステップＳ４１）。受け付けていないと判定した場合には（ステップＳ４１；Ｎｏ）、ソルト署名検証部４１は、受け付けるまで、判定処理を繰り返す。
【００６２】
一方、受け付けたと判定した場合には（ステップＳ４１；Ｙｅｓ）、ソルト署名検証部４１は、要求したユーザのユーザＩＤを取得する（ステップＳ４２）。例えば、登録要求または認証要求には、例えば、ユーザの生体情報、ユーザのユーザＩＤおよび提供を所望するサービスのサービスＩＤが含まれる。かかる場合には、ソルト署名検証部４１は、登録要求または認証要求からユーザＩＤを取得する。
【００６３】
そして、ソルト署名検証部４１は、生体情報を取得する（ステップＳ４３）。例えば、ソルト署名検証部４１は、登録要求または認証要求から生体情報を取得する。
【００６４】
そして、ソルト署名検証部４１は、所望するサービスを提供するサービス側サーバ３の当該サービスのサービスＩＤを取得する（ステップＳ４４）。例えば、ソルト署名検証部４１は、登録要求または認証要求からサービスＩＤを取得する。
【００６５】
そして、ソルト署名検証部４１は、保護データ生成可否判定処理を実行する（ステップＳ４５）。なお、保護データ生成可否判定処理のフローチャートは、後述する。
【００６６】
そして、生体保護データ生成部４３は、生体保護データを生成可能であるか否かを判定する（ステップＳ４６）。生体保護データを生成可能であると判定した場合には（ステップＳ４６；Ｙｅｓ）。生体保護データ生成部４３は、生成された変換パラメータと生体情報とを用いて生体保護データを生成する（ステップＳ４７）。
【００６７】
そして、生体保護データ生成部４３は、生成した生体保護データとユーザＩＤとを含む、生体保護データの登録処理または認証処理をサービスＩＤに対応するサービス側サーバ３に要求する（ステップＳ４８）。そして、生体保護データ生成部４３は、生体保護データ生成処理を終了する。
【００６８】
一方、生体保護データを生成可能でないと判定した場合には（ステップＳ４６；Ｎｏ）。生体保護データ生成部４３は、エラーを戻す（ステップＳ４９）。そして、生体保護データ生成部４３は、生体保護データ生成処理を終了する。
【００６９】
［クライアント端末４の保護データ生成可否判定処理のフローチャート］
ここで、クライアント端末４の保護データ生成可否判定処理のフローチャートを、図９を参照して説明する。図９は、実施例１に係る保護データ生成可否判定処理のフローチャートの一例を示す図である。
【００７０】
図９に示すように、ソルト署名検証部４１は、サービスＩＤに対応するサービス側サーバ３から署名つきソルトを取得する（ステップＳ５１）。ソルト署名検証部４１は、取得した署名つきソルトの署名を、公開鍵４４を用いて検証する（ステップＳ５２）。
【００７１】
ソルト署名検証部４１は、検証に成功したか否かを判定する（ステップＳ５３）。検証に成功したと判定した場合には（ステップＳ５３；Ｙｅｓ）、変換パラメータ生成部４２は、ソルトをパラメータとして変換パラメータを生成する（ステップＳ５４）。そして、変換パラメータ生成部４２は、生成した変換パラメータとともに生体保護データを生成可能である旨を生体保護データ生成処理に戻す。
【００７２】
一方、検証に成功しないと判定した場合には（ステップＳ５３；Ｎｏ）、変換パラメータ生成部４２は、エラーを生体保護データ生成処理に戻す（ステップＳ５５）。すなわち、変換パラメータ生成部４２は、生体保護データを生成可能でない旨を生体保護データ生成処理に戻す。
【００７３】
［実施例１の効果］
このようにして、上記実施例１では、ソルト生成サーバ１は、サービス側サーバ３が提供するサービスの識別情報をパラメータとして得られる乱数ソルトであって変換パラメータを生成するために用いられる乱数ソルトを生成する。ソルト生成サーバ１は、生成された乱数ソルトを秘密鍵２３によって署名された署名乱数ソルトをサービス側サーバ３に配布する。サービス側サーバ３は、秘密鍵２３に対応する公開鍵３５を用いて署名乱数ソルトの署名を検証する。サービス側サーバ３は、署名乱数ソルトの署名の検証に成功すると、署名乱数ソルトを管理する。かかる構成によれば、ソルト生成サーバ１が、サービス側サーバ３の乱数ソルトを一元的に生成し、署名された乱数ソルトをサービス側サーバ３に送信することで、生体保護データを生成するために使われる変換パラメータの元データとなる乱数ソルトの改竄を抑制できる。この結果、ソルト生成サーバ１は、乱数ソルトの改竄、ひいては変換パラメータの改竄によるなりすまし攻撃を防止することができる。言い換えれば、ソルト生成サーバ１は、偽の乱数ソルトを使って生成された生体保護データによりなりすまし攻撃されることを防止できる。
【００７４】
また、上記実施例１では、クライアント端末４は、クライアントの生体保護データを登録または認証する際に、所望するサービスを提供するサービス側サーバ３にサービスの識別情報を送信する。クライアント端末４は、サービス側サーバ３から、サービスの識別情報に対応する署名乱数ソルトを受信する。そして、クライアント端末４は、秘密鍵２３に対応する公開鍵４４を用いて署名乱数ソルトの署名を検証する。クライアント端末４は、署名乱数ソルトの署名の検証に成功すると、乱数ソルトを用いて生体保護データを生成する。クライアント端末４は、生成された生体保護データをサービス側サーバ３に対して登録または認証を要求する。かかる構成によれば、クライアント端末４は、乱数ソルトの改竄、ひいては変換パラメータの改竄によるなりすまし攻撃を防止することができる。言い換えれば、クライアント端末４は、偽の乱数ソルトを用いて、偽の生体保護データを生成しないので、なりすまし攻撃を防止できる。
【００７５】
また、上記実施例１では、クライアント端末４は、乱数ソルトを用いて変換パラメータを生成し、生成した変換パラメータを用いて生体保護データを生成する機能を認証ライブラリ４０の内部で実行する。かかる構成によれば、クライアント端末４は、変換パラメータを認証ライブラリ４０の内部に隠蔽することで、変換パラメータの改竄によるなりすまし攻撃を防止することができる。
【実施例２】
【００７６】
ところで、実施例１では、ソルト生成サーバ１では、ソルト生成部１２は、新規に連携するサービスの識別情報をパラメータとして乱数のソルトを生成するとして説明した。しかしながら、ソルト生成部１２は、これに限定されず、既に配布済みのソルトを収集し、新規に生成されたソルトの重複チェックをし、重複する場合には、重複がなくなるまで乱数のソルトを再生成しても良い。
【００７７】
そこで、実施例２では、ソルト生成部１２が、既に配布済みのソルトを収集し、新規に生成されたソルトの重複チェックをし、重複する場合には、重複がなくなるまで乱数のソルトを再生成する場合について説明する。
【００７８】
［実施例２に係る認証システムの構成］
図１０は、実施例２に係る認証システムの構成を示す機能ブロック図である。なお、図１に示す認証システム９と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例１と実施例２とが異なるところは、ソルト生成サーバ１にソルト重複チェック部５１を追加した点にある。なお、ソルト重複チェック部５１は、生成部の一例である。
【００７９】
ソルト重複チェック部５１は、ソルト生成部１２によって新規に生成されたソルトの重複チェックを行う。例えば、ソルト重複チェック部５１は、ソルト生成サーバ１と既に連携されているサービスを提供するサービス側サーバ３から配布済みのソルトを収集する。ソルト重複チェック部５１は、新規に生成されたソルトが収集されたソルトと重複していないかをどうかをチェックする。
【００８０】
ソルト重複チェック部５１は、重複していない場合には、重複していない旨をソルト生成部１２に通知する。この後、ソルト生成部１２は、生成されたソルトの署名を認証局２に依頼し、署名されたソルト（署名つきソルト）を、新規に連携するサービスを提供するサービス側サーバ３に配布する。
【００８１】
ソルト重複チェック部５１は、重複している場合には、サービスの識別情報に数字や文字列を追加した情報をソルト生成部１２に引き渡す。この後、ソルト生成部１２は、ソルト重複チェック部５１から引き渡された情報をパラメータとして疑似乱数生成器に引き渡し、出力された乱数をソルトとして再生成する。すなわち、ソルト生成部１２は、生成されるソルトが重複しなくなるまでソルトの生成を繰り返す。
【００８２】
［ソルト生成サーバ１側のソルト生成処理のフローチャート］
ここで、ソルト生成サーバ１側のソルト生成処理のフローチャートを、図１１を参照して説明する。図１１は、実施例２に係るソルト生成処理のフローチャートの一例を示す図である。なお、図１１のステップＳ６１〜Ｓ６６は、図６のステップＳ１１〜Ｓ１６と同様であるので、その説明を簡略する。図１１のステップＳ７１〜Ｓ７５は、図６のステップＳ１７〜Ｓ２１と同様であるので、その説明を簡略する。図６と図１１とが異なるところは、ステップＳ６７〜Ｓ７０である。
【００８３】
図１１に示すように、サービス連携部１１は、新規サービスの連携の依頼を受け付けたか否かを判定する（ステップＳ６１）。新規サービスの連携の依頼を受け付けていないと判定した場合には（ステップＳ６１；Ｎｏ）、サービス連携部１１は、当該依頼を受け付けるまで、判定処理を繰り返す。
【００８４】
一方、新規サービスの連携の依頼を受け付けたと判定した場合には（ステップＳ６１；Ｙｅｓ）、サービス連携部１１は、連携するサービスのメタデータが公開されているアドレスを登録する（ステップＳ６２）。そして、サービス連携部１１は、サービスを提供するサーバ環境からメタデータを取得する（ステップＳ６３）。
【００８５】
サービス連携部１１は、メタデータの取得に成功したか否かを判定する（ステップＳ６４）。メタデータの取得に成功しなかったと判定した場合には（ステップＳ６４；Ｎｏ）、サービス連携部１１は、ソルト生成処理を終了する。
【００８６】
一方、メタデータの取得に成功したと判定した場合には（ステップＳ６４；Ｙｅｓ）、ソルト生成部１２は、メタデータからサービスのアドレスを抽出する（ステップＳ６５）。そして、ソルト生成部１２は、サービスのアドレスをパラメータとしてソルトを生成する（ステップＳ６６）。
【００８７】
続いて、ソルト重複チェック部５１は、連携している他のサービスを提供するサービス側サーバ３から配布済みのソルトを収集する（ステップＳ６７）。そして、ソルト重複チェック部５１は、生成したソルトと収集した配布済みのソルトとの重複チェックを行う（ステップＳ６８）。ソルト重複チェック部５１は、重複しているか否かを判定する（ステップＳ６９）。
【００８８】
重複していると判定した場合には（ステップＳ６９；Ｙｅｓ）、ソルト生成部１２は、サービスのアドレスを加工した加工アドレスをパラメータとしてソルトを再生成する（ステップＳ７０）。例えば、ソルト生成部１２は、サービスのアドレスに数字や文字列を追加した情報をパラメータとしてソルトを再生成する。そして、ソルト生成部１２は、再生成したソルトの重複チェックをさせるべく、ステップＳ６８に移行する。
【００８９】
一方、重複していないと判定した場合には（ステップＳ６９；Ｎｏ）、ソルト生成部１２は、認証局２にソルトの署名を依頼する（ステップＳ７１）。そして、ソルト生成部１２は、認証局２から、秘密鍵２３を使って署名された署名つきソルトを取得する（ステップＳ７２）。ソルト生成部１２は、署名つきソルトを、サービスを提供するサービス側サーバ３に送信する（ステップＳ７３）。
【００９０】
その後、ソルト生成部１２は、サービス側サーバ３から署名検証結果を受け取ったか否かを判定する（ステップＳ７４）。署名検証結果を受け取っていないと判定した場合には（ステップＳ７４；Ｎｏ）、ソルト生成部１２は、署名検証結果を受け取るまで、判定処理を繰り返す。
【００９１】
一方、署名検証結果を受け取ったと判定した場合には（ステップＳ７４；Ｙｅｓ）、ソルト生成部１２は、サービス側サーバ３における署名検証結果を管理する（ステップＳ７５）。例えば、ソルト生成部１２は、ソルト署名検証結果管理テーブル１３に対して署名検証結果をサービスに対応づけて記録する。そして、ソルト生成部１２は、ソルト生成処理を終了する。
【００９２】
［実施例２の効果］
このようにして、上記実施例２では、ソルト生成サーバ１は、新たなサービスの連携の依頼を受け付けると、新たなサービスに対応するサービス側サーバ３が提供するサービスの識別情報をパラメータとする乱数ソルトを生成する。そして、ソルト生成サーバ１は、新たなサービスに対応するサービス側サーバ３と異なる他のサービス側サーバ３から乱数ソルトを収集する。そして、ソルト生成サーバ１は、収集した乱数ソルトを用いて、生成した乱数ソルトとの重複をチェックし、重複がなくなるまで乱数ソルトを再生成する。かかる構成によれば、ソルト生成サーバ１は、複数のサービス側サーバ３間での乱数ソルトの重複をチェックすることで、乱数ソルトの改竄の検出を効率的に且つ的確に行うことができる。
【実施例３】
【００９３】
ところで、実施例１、２では、クライアント端末４のソルト署名検証部４１が、所望するサービスを提供するサービス側サーバ３からサービスＩＤに対応する署名つきソルトを受信し、受信した署名つきソルトの署名を、公開鍵４４を用いて検証する。すなわち、クライアント端末４は、サービス側サーバ３との間で、署名つきソルトの署名を検証する。しかしながら、クライアント端末４は、サービス側サーバ３との間に限定されず、さらに、ソルト生成サーバ１との間で署名つきソルトの署名を検証しても良い。
【００９４】
そこで、実施例３では、クライアント端末４が、サービス側サーバ３との間、ソルト生成サーバ１との間で、署名つきソルトの署名を検証する場合について説明する。
【００９５】
［実施例３に係る認証システムの構成］
図１２は、実施例３に係る認証システムの構成を示す機能ブロック図である。なお、図１および図１０に示す認証システム９と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例１、２と実施例３とが異なるところは、ソルト生成サーバ１にソルト配布結果チェック部６１を追加した点にある。また、クライアント端末４にソルト配布結果問合せ部６２を追加した点にある。なお、ソルト配布結果問合せ部６２は、検証部の一例である。
【００９６】
ソルト生成サーバ１のソルト配布結果チェック部６１は、ソルト生成サーバ１からサービス側サーバ３へのソルトの配布結果をチェックする。例えば、ソルト配布結果チェック部６１は、クライアント端末４から、提供を所望するサービスに対応するソルトの配布結果のチェック依頼を受け付けると、ソルト署名検証結果管理テーブル１３を参照して、ソルトの配布結果をチェックする。一例として、ソルト配布結果チェック部６１は、ソルト署名検証結果管理テーブル１３を参照して、チェック依頼に含まれるサービスＩＤに対応する署名検証結果１３ｄを取得する。そして、ソルト配布結果チェック部６１は、取得した署名検証結果１３ｄをソルトの配布結果としてクライアント端末４に通知する。すなわち、ソルト配布結果チェック部６１は、署名検証結果１３ｄが「検証成功」であれば、ソルトの配布結果が成功である旨をクライアント端末４に通知する。ソルト配布結果チェック部６１は、署名検証結果１３ｄが「検証失敗」であれば、ソルトの配布結果が失敗である旨をクライアント端末４に通知する。
【００９７】
クライアント端末４のソルト配布結果問合せ部６２は、ソルト生成サーバ１からサービス側サーバ３へのソルトの配布結果をソルト生成サーバ１に問い合わせる。例えば、ソルト配布結果問合せ部６２は、ソルト生成サーバ１に対して、提供を所望するサービスに対応するソルトの配布結果のチェックを依頼する。ソルト配布結果問合せ部６２は、ソルト生成サーバ１から、ソルトの配布結果を取得する。この後、変換パラメータ生成部４２は、ソルト署名検証部４１による署名検証が成功し、且つソルト生成サーバ１からのソルトの配布結果が成功であれば、署名検証に成功したソルトをパラメータとして変換パラメータを生成する。
【００９８】
［クライアント端末４の生体保護データ生成処理のフローチャート］
クライアント端末４の生体保護データ生成処理のフローチャートは、図８と同様であるので、その説明を省略する。
【００９９】
［クライアント端末４の保護データ生成可否判定処理のフローチャート］
クライアント端末４の保護データ生成可否判定処理のフローチャートを、図１３を参照して説明する。図１３は、実施例３に係る保護データ生成可否判定処理のフローチャートの一例を示す図である。なお、図１３のステップＳ８１〜Ｓ８３、Ｓ８６およびＳ８７は、図９のステップＳ５１〜Ｓ５５と同様であるので、その説明を簡略する。図９と図１３とが異なるところは、ステップＳ８４〜Ｓ８５である。
【０１００】
図１３に示すように、ソルト署名検証部４１は、サービスＩＤに対応するサービス側サーバ３から署名つきソルトを取得する（ステップＳ８１）。ソルト署名検証部４１は、取得した署名つきソルトの署名を、公開鍵４４を用いて検証する（ステップＳ８２）。
【０１０１】
ソルト署名検証部４１は、検証に成功したか否かを判定する（ステップＳ８３）。検証に成功しないと判定した場合には（ステップＳ８３；Ｎｏ）、ソルト署名検証部４１は、エラーを生体保護データ生成処理に戻すべく、ステップＳ８７に移行する。
【０１０２】
一方、検証に成功したと判定した場合には（ステップＳ８３；Ｙｅｓ）、ソルト配布結果問合せ部６２は、ソルト生成サーバ１のソルトの配布結果をチェックする（ステップＳ８４）。例えば、ソルト配布結果問合せ部６２は、ソルト生成サーバ１に対して、提供を所望するサービスに対応するソルトの配布結果のチェックを依頼する。
【０１０３】
そして、ソルト配布結果問合せ部６２は、ソルト生成サーバ１からソルトの配布結果を受け取ると、ソルトの配布結果が成功であるか否かを判定する（ステップＳ８５）。ソルトの配布結果が成功であると判定した場合には（ステップＳ８５；Ｙｅｓ）、変換パラメータ生成部４２は、ソルトをパラメータとして変換パラメータを生成する（ステップＳ８６）。そして、変換パラメータ生成部４２は、生成した変換パラメータとともに生体保護データを生成可能である旨を生体保護データ生成処理に戻す。
【０１０４】
一方、ソルトの配布結果が成功しないと判定した場合には（ステップＳ８５；Ｎｏ）、変換パラメータ生成部４２は、エラーを生体保護データ生成処理に戻すべく、ステップＳ８７に移行する。ステップＳ８７において、ソルト署名検証部４１または変換パラメータ生成部４２は、エラーを生体保護データ生成処理に戻す（ステップＳ８７）。すなわち、ソルト署名検証部４１または変換パラメータ生成部４２は、生体保護データを生成可能でない旨を生体保護データ生成処理に戻す。
【０１０５】
［実施例３の効果］
このようにして、上記実施例３では、クライアント端末４は、サービス側サーバ３から送信された署名付きソルトの署名を検証するとともに、ソルト生成サーバ１にサービス側サーバ３への署名つきソルトの配布結果のチェックを依頼する。クライアント端末４は、署名つきソルトの署名の検証に成功し、且つ署名つきソルトの配布結果が正常であれば、ソルトを用いて生体保護データを生成する。かかる構成によれば、クライアント端末４は、サービス側サーバ３との間、ソルト生成サーバ１との間で、署名つきソルトの署名を検証することで、さらに、ソルトの改竄を的確に検出できる。
【実施例４】
【０１０６】
ところで、実施例１，２では、ソルト生成サーバ１が、サービスに対応するソルトを生成し、生成されたソルトの署名を認証局２に依頼すると説明した。しかしながら、ソルト生成サーバ１は、これに限定されず、ソルトの署名を認証局２に依頼する代わりに、ソルトの署名を自サーバ１で行っても良い。
【０１０７】
そこで、実施例４では、ソルト生成サーバ１が、ソルトの署名を自サーバで行う場合について説明する。
【０１０８】
［実施例４に係る認証システムの構成］
図１４は、実施例４に係る認証システムの構成を示す機能ブロック図である。なお、図１０に示す認証システム９と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例２と実施例４とが異なるところは、認証局２を削除した点にある。また、実施例２と実施例４とが異なるところは、ソルト生成サーバ１のソルト生成部１２をソルト生成部１２Ａに変更し、ソルト生成サーバ１に署名部２１Ａ、公開鍵２２Ａおよび秘密鍵２３Ａを追加した点にある。すなわち、ソルト生成サーバ１は、公開鍵２２Ａおよび秘密鍵２３Ａを管理する。
【０１０９】
ソルト生成部１２Ａは、サービスに対応するソルトを生成する。例えば、ソルト生成部１２Ａは、サービス連携部１１から引き渡されたサービスの識別情報をパラメータとして疑似乱数生成器に引き渡し、出力された乱数をソルトとして生成する。
【０１１０】
また、ソルト生成部１２Ａは、生成されたソルトの署名を署名部２１Ａに依頼する。ソルト生成部１２Ａは、署名されたソルトを、サービスを提供するサービス側サーバ３に配布する。そして、ソルト生成部１２Ａは、署名つきソルトの配布先と配布履歴をサービスに対応づけてソルト署名検証結果管理テーブル１３に記録する。
【０１１１】
また、ソルト生成部１２Ａは、サービス側サーバ３から署名ソルトの署名検証結果を受け付けると、署名検証結果をサービスに対応づけてソルト署名検証結果管理テーブル１３に記録する。
【０１１２】
署名部２１Ａは、ソルト生成部１２Ａからソルトの署名の依頼を受け付けると、秘密鍵２３Ａを用いて当該ソルトを署名する。そして、署名部２１Ａは、署名つきソルトをソルト生成部１２Ａに引き渡す。
【０１１３】
［実施例４の効果］
このようにして、上記実施例４では、ソルト生成サーバ１は、生成されたソルトを自サーバ１で管理された秘密鍵２３Ａを用いて署名し、署名された署名つきソルトをサービス側サーバ１に配布する。かかる構成によれば、ソルト生成サーバ１が、ソルトを自サーバ１で署名することで、ソルトの署名の運用コストを抑制できる。加えて、ソルト生成サーバ１は、署名つきのソルトを高速に生成し、署名つきのソルトを高速にサービス側サーバ３に組み込むことができる。
【実施例５】
【０１１４】
ところで、実施例１〜４では、サービス側サーバ３では、１つのサーバ環境が１つのサービスのソルトを管理すると説明した。しかしながら、サービス側サーバ３では、これに限定されず、１つのサーバ環境が複数のサービスのソルトを管理しても良い。
【０１１５】
そこで、実施例５では、サービス側サーバ３では、１つのサーバ環境が複数のサービスのソルトを管理する場合について説明する。
【０１１６】
［実施例５に係る認証システムの構成］
図１５は、実施例５に係る認証システムの構成を示す機能ブロック図である。なお、図１に示す認証システム９と同一の構成については同一符号を示すことで、その重複する構成および動作の説明については省略する。実施例１と実施例５とが異なるところは、サービス側サーバ３をサービス側サーバ３Ａに変更し、サービス側サーバ３Ａが１台である点にある。また、実施例１と実施例５とが異なるところは、ソルト生成サーバ１の機能をサービス側サーバ３Ａに追加した点にある。すなわち、サービス側サーバ３Ａにソルト生成部１２Ｂおよびソルト重複チェック部５１Ｂを追加し、ソルト管理テーブル３６をソルト管理テーブル３６Ｂに変更した点にある。
【０１１７】
ソルト生成部１２Ｂは、サービスに対応するソルトを生成する。例えば、ソルト生成部１２Ｂは、管理者から新規に追加するサービスの識別情報を受け取ると、受け取った識別情報をパラメータとして疑似乱数生成器に引き渡し、出力された乱数をソルトとして生成する。
【０１１８】
また、ソルト生成部１２Ｂは、生成したソルトの重複をソルト重複チェック部５１Ｂにチェックさせる。ソルト生成部１２Ｂは、生成したソルトが重複していれば、ソルト重複チェック部５１Ｂから引き渡された情報をパラメータとして疑似乱数生成器に引き渡し、出力された乱数をソルトとして再生成する。そして、ソルト生成部１２Ｂは、生成したソルトの重複をソルト重複チェック部５１Ｂにチェックさせる。ソルト生成部１２Ｂは、生成したソルトが重複しなくなるまで、ソルトの再生成を繰り返す。
【０１１９】
また、ソルト生成部１２Ｂは、生成したソルトが重複していなければ、生成されたソルトの署名を認証局２に依頼する。そして、ソルト生成部１２Ｂは、署名つきソルトをサービスおよびソルトに対応づけてソルト管理テーブル３６Ｂに記録する。
【０１２０】
ここで、ソルト管理テーブル３６Ｂの一例を、図１６を参照して説明する。図１６は、実施例５に係るソルト管理テーブルの一例を示す図である。図１６に示すように、ソルト管理テーブル３６Ｂは、更新日時３６ａ、サービスＩＤ３６ｂ、ソルトＩＤ３６ｃおよび署名つきソルト３６ｄを対応づけて記憶する。更新日時３６ａは、このレコードを更新した日時を示す。サービスＩＤ３６ｂは、サービスを一意に識別する識別子を示す。サービスＩＤ３６ｂは、例えば、管理者から受け取られたサービスの識別情報である。ソルトＩＤ３６ｃは、ソルトを一意に識別する識別子を示す。署名つきソルト３６ｄは、認証局２によって生成された署名つきのソルトである。
【０１２１】
一例として、更新日時３６ａが「2016/12/22  20:10:10」である場合に、サービスＩＤ３６ｂとして「１」、ソルトＩＤ３６ｃとして「１」、署名つきソルト３６ｄとして「ａ／nft0a23/s1gia1」を記憶している。更新日時３６ａが「2016/12/23  12:05:35」である場合に、サービスＩＤ３６ｂとして「２」、ソルトＩＤ３６ｃとして「２」、署名つきソルト３６ｄとして「Pagpo&t0a8nbafa?」を記憶している。すなわち、ソルト管理テーブル３６Ｂは、サービスＩＤ３６ｂごとの署名つきソルト３６ｄを記憶している。
【０１２２】
図１５に戻って、ソルト重複チェック部５１Ｂは、ソルト生成部１２Ｂによって新規に生成されたソルトの重複チェックを行う。例えば、ソルト重複チェック部５１Ｂは、ソルト管理テーブル３６Ｂを参照して、署名つきソルトから得られる生成済みのソルトを収集する。ソルト重複チェック部５１Ｂは、新規に生成されたソルトが収集されたソルトと重複していないかをチェックする。
【０１２３】
ソルト重複チェック部５１Ｂは、重複していない場合には、重複していない旨をソルト生成部１２Ｂに通知する。
【０１２４】
ソルト重複チェック部５１Ｂは、重複している場合には、サービスの識別情報に数字や文字列を追加した情報をソルト生成部１２Ｂに引き渡す。
【０１２５】
［実施例５の効果］
このようにして、上記実施例５では、サービス側サーバ３が、新たなサービスの識別情報をパラメータとするソルトを生成する。サービス側サーバ３は、生成されたソルトを秘密鍵によって署名された署名つきソルトをサービスごとに管理する。かかる構成によれば、サービス側サーバ３は、ソルトを一元的に生成するソルト生成サーバ１がなくても、秘密鍵によって署名された署名つきソルトを追加するため、偽のソルトを追加することがなく、なりすまし攻撃を防止できる。
【０１２６】
［その他］
なお、サービス側サーバ３では、認証部３３は、クライアント端末４から送信されたサービスＩＤを受け付けると、ソルト管理テーブル３６から、サービスＩＤに対応する署名つきソルト３６ｄを取得し、クライアント端末４に送信する。そして、認証部３３は、クライアント端末４から生体保護データの認証処理要求を受け付けると、クライアント端末４から送信されたユーザの生体保護データと登録された生体保護データ３７とを照合し、ユーザの生体保護データを認証すると説明した。しかしながら、認証部３３は、チャレンジを用いたチャレンジ／レスポンス認証を行っても良い。例えば、認証部３３は、クライアント端末４から送信されたサービスＩＤを受け付けると、サービスＩＤをパラメータとするチャレンジを生成し、サービスＩＤに紐付けてチャレンジを管理する。そして、認証部３３は、ソルト管理テーブル３６から、サービスＩＤに対応する署名つきソルト３６ｄを取得し、取得した署名つきソルト３６ｄと生成したチャレンジとをクライアント端末４に送信する。クライアント端末４は、生体保護データとチャレンジとソルトとを一方向性関数のパラメータとして指定してレスポンスコードを生成する。クライアント端末４は、レスポンスコード、サービスＩＤおよびユーザＩＤを含む生体保護データの認証処理要求をサービス側サーバ３に送信する。サービス側サーバ３では、認証部３３は、クライアント端末４から生体保護データの認証処理要求を受け付けると、サービスＩＤに紐づくチャレンジとソルトと、ユーザＩＤに紐づく生体保護データとを一方向性関数のパラメータとして指定して認証データを生成し、クライアント端末４から送信されたレスポンスコードと、生成した認証データとを照合し、レスポンスコードを認証する。すなわち、認証部３３は、生体保護データを認証する。これにより、認証部３３は、認証時にチャレンジを用いた認証を行うことで、照合する対象であるレスポンスコードと認証データとがワンタイム化されることとなり、通信経路上でレスポンスコードが改竄されたとしても、改竄を確実に検出することができる。この結果、認証部３３は、なりすまし攻撃されることを防止できる。
【０１２７】
また、実施例では、ソルト生成部１２は、サービスに対応するソルトを生成すると説明した。しかしながら、ソルト生成部１２は、これに限定されず、サービスおよびユーザに対応するソルトを生成しても良い。かかる場合には、ソルト生成部１２は、サービスの識別情報（例えばアドレス）に加え、ユーザの識別情報（例えばユーザＩＤ）をパラメータとして疑似乱数生成器に引き渡し、出力された乱数をソルトとして生成すれば良い。これにより、ソルト生成部１２は、サービスおよびユーザごとのソルトを生成することができ、サービスおよびユーザごとのソルトの改竄をユーザごとに検出することができる。
【０１２８】
また、ソルト生成サーバ１は、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記したサービス連携部１１およびソルト生成部などを搭載することによって実現することができる。サービス側サーバ３は、既知のパーソナルコンピュータ、ワークステーションなどの情報処理装置に、上記したソルト署名検証部３１、ソルト管理部３２および認証部３３などを搭載することによって実現することができる。
【０１２９】
また、図示した認証システム９の各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的態様は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、ソルト生成部１２を、ソルトを生成する生成部と、ソルトの署名を認証局２に依頼する依頼部とに分離しても良い。また、ソルト署名検証部３１とソルト管理部３２とを１つの部として統合しても良い。また、ソルト署名喧噪結果管理テーブル１３を記憶する記憶部をソルト生成サーバ１の外部装置としてネットワーク経由で接続するようにしても良い。
【０１３０】
また、上記実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１に示したソルト生成サーバ１およびサービス側サーバ３と同様の機能を実現する認証プログラムを実行するコンピュータの一例を説明する。図１７は、認証プログラムを実行するコンピュータの一例を示す図である。
【０１３１】
図１７に示すように、コンピュータ２００は、各種演算処理を実行するＣＰＵ２０３と、ユーザからのデータの入力を受け付ける入力装置２１５と、表示装置２０９を制御する表示制御部２０７とを有する。また、コンピュータ２００は、記憶媒体からプログラムなどを読取るドライブ装置２１３と、ネットワークを介して他のコンピュータとの間でデータの授受を行う通信制御部２１７とを有する。また、コンピュータ２００は、各種情報を一時記憶するメモリ２０１と、ＨＤＤ（Hard  Disk  Drive）２０５を有する。そして、メモリ２０１、ＣＰＵ２０３、ＨＤＤ２０５、表示制御部２０７、ドライブ装置２１３、入力装置２１５、通信制御部２１７は、バス２１９で接続されている。
【０１３２】
ドライブ装置２１３は、例えばリムーバブルディスク２１１用の装置である。ＨＤＤ２０５は、認証プログラム２０５ａおよび認証処理関連情報２０５ｂを記憶する。
【０１３３】
ＣＰＵ２０３は、認証プログラム２０５ａを読み出して、メモリ２０１に展開し、プロセスとして実行する。かかるプロセスは、ソルト生成サーバ１およびサービス側サーバ３の各機能部に対応する。認証処理関連情報２０５ｂは、ソルト署名検証結果管理テーブル１３などに対応する。また、認証処理関連情報２０５ｂは、ソルト管理テーブル３６などに対応する。そして、例えばリムーバブルディスク２１１が、認証プログラム２０５ａなどの各情報を記憶する。
【０１３４】
なお、認証プログラム２０５ａについては、必ずしも最初からＨＤＤ２０５に記憶させておかなくても良い。例えば、コンピュータ２００に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に当該プログラムを記憶させておく。そして、コンピュータ２００がこれらから認証プログラム２０５ａを読み出して実行するようにしても良い。
【符号の説明】
【０１３５】
１  ソルト生成サーバ
１１  サービス連携部
１２、１２Ａ、１２Ｂ  ソルト生成部
１３  ソルト署名検証結果管理テーブル
２  認証局
２１、２１Ａ  署名部
２２、２２Ａ  公開鍵
２３、２３Ａ  秘密鍵
３、３Ａ  サービス側サーバ
３１  ソルト署名検証部
３２  ソルト管理部
３３  認証部
３４  メタデータ
３５  公開鍵
３６、３６Ｂ  ソルト管理テーブル
３７  生体保護データ
４  クライアント端末
４０  認証ライブラリ
４１  ソルト署名検証部
４２  変換パラメータ生成部
４３  生体保護データ生成部
４４  公開鍵
５１、５１Ｂ  ソルト重複チェック部
６１  ソルト配布結果チェック部
６２  ソルト配布結果問合せ部
９  認証システム
【図１】
2019036781.tif 000003
【図２】
2019036781.tif 000004
【図３】
2019036781.tif 000005
【図４】
2019036781.tif 000006
【図５Ａ】
2019036781.tif 000007
【図５Ｂ】
2019036781.tif 000008
【図６】
2019036781.tif 000009
【図７】
2019036781.tif 000010
【図８】
2019036781.tif 000011
【図９】
2019036781.tif 000012
【図１０】
2019036781.tif 000013
【図１１】
2019036781.tif 000014
【図１２】
2019036781.tif 000015
【図１３】
2019036781.tif 000016
【図１４】
2019036781.tif 000017
【図１５】
2019036781.tif 000018
【図１６】
2019036781.tif 000019
【図１７】
2019036781.tif 000020