特許7408882 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ 楽天株式会社の特許一覧

特許7408882認証システム、認証装置、認証方法、及びプログラム

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-12-22

(45)【発行日】2024-01-05

(54)【発明の名称】認証システム、認証装置、認証方法、及びプログラム

(51)【国際特許分類】

G06F 21/31 20130101AFI20231225BHJP

G06F 21/32 20130101ALI20231225BHJP

H04L 9/16 20060101ALI20231225BHJP

【ＦＩ】

G06F21/31

G06F21/32

H04L9/16

【請求項の数】 9

(21)【出願番号】P 2023540796

(86)(22)【出願日】2021-12-29

(86)【国際出願番号】 JP2021049015

(87)【国際公開番号】W WO2023127160

(87)【国際公開日】2023-07-06

【審査請求日】2023-07-03

【早期審査対象出願】

(73)【特許権者】

【識別番号】399037405

【氏名又は名称】楽天グループ株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】弁理士法人はるか国際特許事務所

(72)【発明者】

【氏名】蔡永男

【審査官】中里裕正

(56)【参考文献】

【文献】特開２００４－３１８６９１（ＪＰ，Ａ）

【文献】特開２００２－２５９３４３（ＪＰ，Ａ）

【文献】特開２００３－３３８８１４（ＪＰ，Ａ）

【文献】特開２００７－１５６７８５（ＪＰ，Ａ）

【文献】特開平０５－１０２９６１（ＪＰ，Ａ）

【文献】特開平０９－０８３５０６（ＪＰ，Ａ）

【文献】特許第２６８９３８３（ＪＰ，Ｂ２）

【文献】特開２００６－３４０２９６（ＪＰ，Ａ）

【文献】特表２００１－５２４７７１（ＪＰ，Ａ）

【文献】特開２００６－２３８２７３（ＪＰ，Ａ）

【文献】特開２００２－２９０３９７（ＪＰ，Ａ）

【文献】DAVIES, D. W. and PRICE, W. L.，ネットワーク・セキュリティ，pp.136-138，日経マグロウヒル社，1985年12月05日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ２１／３１

Ｇ０６Ｆ２１／３２

Ｈ０４Ｌ９／１６

(57)【特許請求の範囲】

【請求項1】

【請求項2】

ユーザのユーザ装置と、前記ユーザが所定のサービスにログインするための多要素認証を実行する認証装置と、を含む認証システムであって、
前記ユーザ装置は、
生体情報とは異なる認証情報であって、前記ユーザが前記サービスにログインするたびに更新される前記認証情報を変換するための変換情報として、前記変換情報が取得される第１取得時点が属する第１取得期間の時間帯に応じた前記変換情報を取得する変換情報取得部と、
前記変換情報に基づいて、前記認証情報を変換する変換部と、
前記認証装置に対し、変換後の前記認証情報と、前記生体情報と、を送信し、前記第１取得期間の前記時間帯の終了間際になった場合には、前記認証装置に対し、前記第１取得期間に関する第１取得期間情報を更に送信する情報送信部と、
を含み、
前記認証装置は、
前記ユーザ装置から、前記変換後の認証情報と、前記生体情報と、を受信し、前記終了間際になった場合には、前記ユーザ装置から、前記第１取得期間情報を更に受信する情報受信部と、
前記変換後の認証情報を逆変換するための逆変換情報を取得し、前記終了間際になった場合には、前記第１取得期間情報に基づいて、前記逆変換情報を取得する逆変換情報取得部と、
前記逆変換情報に基づいて、前記変換後の認証情報を逆変換する逆変換部と、
前記逆変換部により逆変換された前記認証情報と、前記生体情報と、に基づいて、前記多要素認証を実行する多要素認証部と、
を含む認証システム。

【請求項3】

ユーザのユーザ装置と、前記ユーザが所定のサービスにログインするための多要素認証を実行する認証装置と、を含む認証システムであって、
前記ユーザ装置は、
生体情報とは異なる認証情報であって、前記ユーザが前記サービスにログインするたびに更新される前記認証情報を変換するための変換情報として、前記変換情報が取得される第１取得時点が属する第１取得期間に応じた前記変換情報を取得する変換情報取得部と、
前記変換情報に基づいて、前記認証情報を変換する変換部と、
前記認証装置に対し、変換後の前記認証情報と、前記生体情報と、前記第１取得期間に関する第１取得期間情報と、を送信する情報送信部と、
を含み、
前記認証システムは、複数の期間の各々と、前記変換後の認証情報を逆変換するための逆変換情報と、を関連付けて管理する管理装置を更に含み、
前記認証装置は、
前記ユーザ装置から、前記変換後の認証情報と、前記生体情報と、前記第１取得期間情報と、を受信する情報受信部と、
前記管理装置に対し、前記逆変換情報を要求する逆変換情報要求部と、
を含み、
前記管理装置は、前記認証装置からの要求を受け付けた場合の時点が属する期間に応じた前記逆変換情報を送信し、
前記管理装置は、前記認証装置からの要求を受け付けた場合の時点が前記第１取得期間よりも後の第２取得期間である場合に、前記認証装置に対し、前記第１取得期間に応じた前記逆変換情報と、前記第２取得期間に応じた前記逆変換情報と、を含む複数の前記逆変換情報を送信し、
前記認証装置は、
前記第１取得期間情報に基づいて、前記複数の逆変換情報の中から、前記第１取得期間に応じた前記逆変換情報を取得する逆変換情報取得部と、
前記第１取得期間に応じた前記逆変換情報に基づいて、前記変換後の認証情報を逆変換する逆変換部と、
前記逆変換部により逆変換された前記認証情報と、前記生体情報と、に基づいて、前記多要素認証を実行する多要素認証部と、
を更に含む認証システム。

【請求項4】

ユーザのユーザ装置と、前記ユーザが所定のサービスにログインするための多要素認証を実行する認証装置と、を含む認証システムであって、
前記ユーザ装置は、
生体情報とは異なる認証情報であって、前記ユーザが前記サービスにログインするたびに更新される前記認証情報を変換するための変換情報を取得する変換情報取得部と、
複数の変換方法の中から、前記認証情報が変換される第１変換時点が属する第１変換期間に応じた前記変換方法を選択する変換方法選択部と、
前記変換情報に基づいて、前記変換方法選択部により選択された前記変換方法で前記認証情報を変換する変換部と、
前記認証装置に対し、変換後の前記認証情報と、前記生体情報と、を送信する情報送信部と、
を含み、
前記認証装置は、
前記ユーザ装置から、前記変換後の認証情報と、前記生体情報と、を受信する情報受信部と、
前記変換後の認証情報を逆変換するための逆変換情報を取得する逆変換情報取得部と、
複数の逆変換方法の中から、前記第１変換期間に応じた前記逆変換方法を選択する逆変換方法選択部と、
前記逆変換情報に基づいて、前記逆変換方法選択部により選択された逆変換方法で前記変換後の認証情報を逆変換する逆変換部と、
前記逆変換部により逆変換された前記認証情報と、前記生体情報と、に基づいて、前記多要素認証を実行する多要素認証部と、
を含み、
前記情報送信部は、前記第１変換期間の時間帯の終了間際になった場合には、前記認証装置に対し、前記第１変換期間に関する第１期間情報を更に送信し、
前記情報受信部は、前記終了間際になった場合には、前記ユーザ装置から、前記第１期間情報を更に受信し、
前記逆変換方法選択部は、前記終了間際になった場合には、前記第１期間情報に基づいて、前記第１変換期間に応じた前記逆変換方法を選択する、
認証システム。

【請求項5】

ユーザのユーザ装置と、前記ユーザが所定のサービスにログインするための多要素認証を実行する認証装置と、を含む認証システムであって、
前記認証システムは、
選択装置と、前記ユーザ装置から所定の生成要求が受け付けられた場合に、所定の識別情報と、変換情報及び逆変換情報と、を生成して互いに関連付ける関連付け部と、
を更に含み、
前記ユーザ装置は、
生体情報とは異なる認証情報であって、前記ユーザが前記サービスにログインするたびに更新される前記認証情報を変換するための前記変換情報を取得する変換情報取得部と、
前記識別情報を取得する識別情報取得部と、
前記識別情報に基づいて、前記選択装置に対し、前記認証情報の変換方法の選択を要求する変換方法要求部と、
を含み、
前記選択装置は、前記ユーザ装置からの要求が受け付けられた場合に、前記ユーザ装置に対し、複数の前記変換方法のうちの何れかの選択結果を送信する第１送信部を含み、
前記ユーザ装置は、
前記選択装置による選択結果に基づいて、複数の変換方法のうちの何れかを選択する変換方法選択部と、
前記変換情報に基づいて、前記変換方法選択部により選択された前記変換方法で前記認証情報を変換する変換部と、
前記認証装置に対し、変換後の前記認証情報と、前記生体情報と、前記識別情報と、を送信する情報送信部と、
を含み、
前記認証装置は、
前記ユーザ装置から、前記変換後の認証情報と、前記生体情報と、前記識別情報と、を受信する情報受信部と、
前記選択装置に対し、前記識別情報に基づいて、前記逆変換方法の選択を要求する逆変換方法要求部と、
を含み、
前記選択装置は、前記認証装置からの要求が受け付けられた場合に、前記認証装置に対し、複数の前記逆変換方法のうちの何れかの選択結果を送信する第２送信部を更に含み、
前記認証装置は、
前記選択装置による選択結果に基づいて、複数の前記逆変換方法の中から、前記変換方法選択部により選択された前記変換方法に対応する前記逆変換方法を選択する逆変換方法選択部と、
前記変換後の認証情報を逆変換するための前記逆変換情報を取得する逆変換情報取得部と、
前記逆変換情報に基づいて、前記逆変換方法選択部により選択された前記逆変換方法で前記変換後の認証情報を逆変換する逆変換部と、
前記逆変換部により逆変換された前記認証情報と、前記生体情報と、に基づいて、前記多要素認証を実行する多要素認証部と、
を更に含む認証システム。

【請求項6】

ユーザのユーザ装置と、前記ユーザが所定のサービスにログインするための多要素認証を実行する認証装置であって、
前記ユーザ装置から、生体情報とは異なる認証情報であって、前記ユーザが前記サービスにログインするたびに更新される前記認証情報を変換するための変換情報として、前記変換情報が取得される第１取得時点が属する第１取得期間の日及び時間帯に応じた前記変換情報による変換後の前記認証情報と、前記生体情報と、前記第１取得期間の分及び秒に関する第１取得期間情報と、を受信する情報受信部と、
前記第１取得期間情報に基づいて、前記変換後の認証情報を逆変換するための逆変換情報であって、前記第１取得期間の日及び時間帯に応じた前記逆変換情報を取得する逆変換情報取得部と、
前記逆変換情報に基づいて、前記変換後の認証情報を逆変換する逆変換部と、
前記逆変換部により逆変換された前記認証情報と、前記生体情報と、に基づいて、前記多要素認証を実行する多要素認証部と、
を含む認証装置。

【請求項7】

ユーザのユーザ装置と、前記ユーザが所定のサービスにログインするための多要素認証を実行する認証装置と、を利用した認証方法であって、
前記ユーザ装置は、
生体情報とは異なる認証情報であって、前記ユーザが前記サービスにログインするたびに更新される前記認証情報を変換するための変換情報として、前記変換情報が取得される第１取得時点が属する第１取得期間の日及び時間帯に応じた前記変換情報を取得する変換情報取得ステップと、
前記変換情報に基づいて、前記認証情報を変換する変換ステップと、
前記認証装置に対し、変換後の前記認証情報と、前記生体情報と、前記第１取得期間の分及び秒に関する第１取得期間情報と、を送信する情報送信ステップと、
を実行し、
前記認証装置は、
前記ユーザ装置から、前記変換後の認証情報と、前記生体情報と、前記第１取得期間情報と、を受信する情報受信部ステップ、
前記第１取得期間情報に基づいて、前記変換後の認証情報を逆変換するための逆変換情報であって、前記第１取得期間の日及び時間帯に応じた前記逆変換情報を取得する逆変換情報取得ステップと、
前記逆変換情報に基づいて、前記変換後の認証情報を逆変換する逆変換ステップと、
前記逆変換部により逆変換された前記認証情報と、前記生体情報と、に基づいて、前記多要素認証を実行する多要素認証ステップと、
を実行する認証方法。

【請求項8】

ユーザが所定のサービスにログインするための多要素認証を実行する認証装置と通信可能なユーザ装置を、
生体情報とは異なる認証情報であって、前記ユーザが前記サービスにログインするたびに更新される前記認証情報を変換するための変換情報として、前記変換情報が取得される第１取得時点が属する第１取得期間の日及び時間帯に応じた前記変換情報を取得する変換情報取得部、
前記変換情報に基づいて、前記認証情報を変換する変換部、
前記認証装置に対し、変換後の前記認証情報と、前記生体情報と、前記第１取得期間の分及び秒に関する第１取得期間情報と、を送信する情報送信部、
として機能させるためのプログラム。

【請求項9】

ユーザのユーザ装置と通信可能であり、前記ユーザが所定のサービスにログインするための多要素認証を実行する認証装置を、
前記ユーザ装置から、生体情報とは異なる認証情報であって、前記ユーザが前記サービスにログインするたびに更新される前記認証情報を変換するための変換情報であって、前記変換情報が取得される第１取得時点が属する第１取得期間の日及び時間帯に応じた前記変換情報による変換後の認証情報と、前記生体情報と、前記第１取得期間の分及び秒に関する第１取得期間情報と、を受信する情報受信部、
前記第１取得期間情報に基づいて、前記変換後の認証情報を逆変換するための逆変換情報であって、前記第１取得期間の日及び時間帯に応じた前記逆変換情報を取得する逆変換情報取得部、
前記逆変換情報に基づいて、前記変換後の認証情報を逆変換する逆変換部、
前記逆変換部により逆変換された前記認証情報と、前記生体情報と、に基づいて、前記多要素認証を実行する多要素認証部、
として機能させるためのプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、認証システム、認証方法、及びプログラムに関する。

【背景技術】

【0002】

従来、複数の要素を組み合わせた認証方式である多要素認証が知られている。例えば、特許文献１には、ユーザが入力したユーザＩＤと、ユーザＩＤに基づいて生成されたユーザパラメータで変換した生体情報と、を利用した多要素認証が記載されている。特許文献２には、多要素認証ではないが、ランダムに生成されたソルトに基づいて、生体情報を変換して生体認証を実行することが記載されている。特許文献３には、生体認証が成功した場合に、ユーザを識別可能なネットワークアカウントと、公開鍵及び秘密鍵と、を利用したチャレンジアンドレスポンスを実行する多要素認証が記載されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特許第４９６６７６５号公報

【文献】特許第６８６６８０３号公報

【文献】再公表２０２０－８５１４１号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、特許文献１では、ユーザパラメータを生成するために、ユーザＩＤがネットワーク上に送信され、悪意のある第三者にユーザＩＤが盗まれる可能性があるので、多要素認証におけるセキュリティを十分に高めることができない。特許文献２の技術は、そもそも多要素認証を想定していない。特許文献３の技術は、生体認証が成功した後に、ネットワークアカウントがネットワーク上に送信され、悪意のある第三者にネットワークアカウントが盗まれる可能性があるので、多要素認証におけるセキュリティを十分に高めることができない。

【0005】

本開示の目的の１つは、多要素認証におけるセキュリティを高めることである。

【課題を解決するための手段】

【0006】

本開示の一態様に係る認証システムは、ユーザ装置及び認証装置を含む認証システムであって、前記ユーザ装置は、生体情報とは異なる認証情報を変換するための変換情報を取得する変換情報取得部と、前記変換情報に基づいて、前記認証情報を変換する変換部と、前記認証装置に対し、変換後の前記認証情報と、前記生体情報と、を送信する情報送信部と、を含み、前記認証装置は、前記ユーザ装置から、前記変換後の認証情報と、前記生体情報と、を受信する情報受信部と、前記変換後の認証情報を逆変換するための逆変換情報を取得する逆変換情報取得部と、前記逆変換情報に基づいて、前記変換後の認証情報を逆変換する逆変換部と、前記逆変換部により逆変換された前記認証情報と、前記生体情報と、に基づいて、多要素認証を実行する多要素認証部と、を含む。

【発明の効果】

【0007】

本開示によれば、多要素認証におけるセキュリティが高まる。

【図面の簡単な説明】

【0008】

【図1】認証システムの全体構成の一例を示す図である。

【図2】第１実施形態における多要素認証の流れの一例を示す図である。

【図3】第１実施形態の認証システムで実現される機能の一例を示す機能ブロック図である。

【図4】ソルトデータベースの一例を示す図である。

【図5】ユーザデータベースの一例を示す図である。

【図6】第１実施形態の認証システムで実行される処理の一例を示す図である。

【図7】第１実施形態の認証システムで実行される処理の一例を示す図である。

【図8】第２実施形態における多要素認証の流れの一例を示す図である。

【図9】第３実施形態における多要素認証の流れの一例を示す図である。

【図10】第３実施形態の認証システムで実現される機能ブロックの一例を示す図である。

【図11】第４実施形態における多要素認証の流れの一例を示す図である。

【図12】第４実施形態の認証システムで実現される機能ブロックの一例を示す図である。

【図13】第５実施形態における多要素認証の流れの一例を示す図である。

【図14】第６実施形態における認証システムの全体構成の一例を示す図である。

【図15】第６実施形態における多要素認証の流れの一例を示す図である。

【図16】第６実施形態の認証システムで実現される機能ブロックの一例を示す図である。

【図17】変形例１における多要素認証の流れの一例を示す図である。

【発明を実施するための形態】

【0009】

［１．第１実施形態］
本開示に係る認証システムの実施形態の例である第１実施形態を説明する。

【0010】

［１－１．認証システムの全体構成］
図１は、認証システムの全体構成の一例を示す図である。図１に示すように、認証システムＳは、ソルトサーバ１０、認証サーバ２０、及びユーザＰＣ３０を含む。ソルトサーバ１０、認証サーバ２０、及びユーザＰＣ３０は、インターネット又はＬＡＮ等のネットワークＮに接続可能である。認証システムＳは、少なくとも１台のコンピュータを含めばよく、図１の例に限られない。

【0011】

ソルトサーバ１０は、サーバコンピュータである。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。ソルトサーバ１０は、管理装置の一例である。このため、ソルトサーバ１０と記載した箇所は、管理装置と読み替えることができる。

【0012】

管理装置は、暗号理論におけるソルトを管理する装置である。ソルトは、変換対象となる情報を変換するための情報である。ソルトは、変換対象となる情報とともに、変換関数に入力される情報である。変換は、暗号化又はハッシュ化と呼ばれることもある。変換は、可逆性がある。変換後の情報は、逆変換することによって、変換前の情報に戻すことができる。ソルトを管理するとは、ソルトを記憶することである。

【0013】

ソルト自体は、公知のソルトを利用可能である。例えば、ソルトは、ランダムな値である。ソルトは、任意の形式であってよく、例えば、数字、文字、その他の記号、又はこれらの組み合わせである。管理装置は、ソルトを生成してもよいし、ソルトの生成自体は、管理装置以外の他の装置で行われてもよい。管理装置は、任意の装置であってよく、ソルトサーバ１０のようなサーバコンピュータに限られない。例えば、管理装置は、パーソナルコンピュータ、タブレット端末、又はスマートフォンであってもよい。

【0014】

認証サーバ２０は、サーバコンピュータである。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。認証サーバ２０は、認証装置の一例である。このため、認証サーバ２０と記載した箇所は、認証装置と読み替えることができる。

【0015】

認証装置は、認証を実行する装置である。認証は、ユーザの正当性を確認する処理である。認証装置は、種々のタイプの認証を実行可能である。例えば、認証装置は、生体認証、所持認証、知識認証、又はこれらの組み合わせを実行可能である。認証装置は、任意の装置であってよく、認証サーバ２０のようなサーバコンピュータに限られない。例えば、認証装置は、パーソナルコンピュータ、タブレット端末、又はスマートフォンであってもよい。他にも例えば、認証装置は、ゲーム機、自動販売機、ＰＯＳ端末、又はＡＴＭといった他の装置であってもよい。

【0016】

ユーザＰＣ３０は、ユーザのパーソナルコンピュータである。制御部３１、記憶部３２、及び通信部３３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部３４は、マウス、キーボード、又はタッチパネル等の入力デバイスである。表示部３５は、液晶ディスプレイ又は有機ＥＬディスプレイである。撮影部３６は、少なくとも１台のカメラを含む。ユーザＰＣ３０は、ユーザ装置の一例である。このため、ユーザＰＣ３０と記載した箇所は、ユーザ装置と読み替えることができる。

【0017】

ユーザ装置は、認証時における認証情報を取得する装置である。ユーザ装置は、ユーザが操作可能な装置である。ユーザ装置は、ユーザの所有物であってもよいし、特にユーザの所有物ではなくてもよい。ユーザ装置は、任意の装置であってよく、ユーザＰＣ３０のようなパーソナルコンピュータに限られない。例えば、ユーザ装置は、タブレット端末、スマートフォン、又はウェアラブル端末であってもよい。他にも例えば、ユーザ装置は、ゲーム機、自動販売機、ＰＯＳ端末、又はＡＴＭといった他の装置であってもよい。

【0018】

なお、記憶部１２，２２，３２に記憶されるプログラムは、ネットワークＮを介して供給されるようにしてもよい。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）と、外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）と、の少なくとも一方を介して、情報記憶媒体に記憶されたプログラムが供給されてもよい。

【0019】

［１－２．第１実施形態における認証システムの概要］
認証システムＳでは、ユーザの正当性を確認するために、多要素認証が実行される。多要素認証とは、複数の要素を組み合わせた認証である。第１実施形態では、２つの要素を組み合わせた２要素認証を例に挙げるが、３つ以上の要素を組み合わせた多要素認証であってもよい。要素自体は、種々の種類を利用可能であり、例えば、生体要素、所持要素、又は知識要素であってもよい。

【0020】

多要素認証では、要素に応じた認証情報が利用される。認証情報自体は、種々の種類を利用可能である。例えば、生体認証では、顔写真、顔の特徴量、指紋の写真、指紋の特徴量、静脈のスキャン画像、又は静脈の特徴量といった生体情報が認証情報に相当する。所持認証では、ワンタイムパスワード、ＩＣカードに記録された情報、又はトークンに記録された情報といった所持情報が認証情報に相当する。知識認証では、ユーザＩＤ、パスワード、ＰＩＮ、又は秘密の質問といった知識情報が認証情報に相当する。

【0021】

第１実施形態では、オンラインサービスにログインするために多要素認証が実行される場合を例に挙げるが、多要素認証は、任意の場面に適用可能である。例えば、オンラインサービスに対する申込時、電子決済の実行時、又は、オンライン上で行政手続が行われる時といった他の場面にも、多要素認証を適用可能である。オンラインサービス自体は、種々のサービスを適用可能である。例えば、金融サービス、通信サービス、決済サービス、電子商取引サービス、又はＳＮＳがオンラインサービスに相当してもよい。

【0022】

例えば、ユーザが、オンラインサービスの利用登録をすると、オンラインサービスにログインするためのユーザＩＤ及びパスワードが発行される。ユーザは、ユーザＰＣ３０でオンラインサービスのウェブサイトにアクセスし、ユーザＩＤ及びパスワードを入力する。認証サーバ２０は、ユーザが入力したユーザＩＤ及びパスワードに基づいて、ユーザの正当性を確認する。ユーザの正当性が確認されると、ユーザは、オンラインサービスにログインできる。

【0023】

ログインのたびにユーザＩＤ及びパスワードの入力が要求されると、非常に手間がかかる。このため、顔認証及びパスワード認証を組み合わせた多要素認証により、ユーザＩＤの入力の手間を軽減することが考えられる。しかしながら、この場合にもパスワードを入力する手間が発生する。操作部３４に対する入力を発生させずに顔認証だけでユーザをログインさせると、顔が似た他のユーザとの誤認証が発生する可能性がある。３Ｄセンサを含む撮影部３６であれば、ある程度の精度で顔認証を実行できるが、それでも誤認証が発生することがある。撮影部３６が３Ｄセンサを含まない場合には、誤認証の確率が高まる。ユーザの顔写真を何らかの形で手に入れた第三者がユーザになりすます可能性もある。

【0024】

そこで、第１実施形態では、操作部３４からの入力を発生させず、かつ、セキュリティを担保するために、ユーザがオンラインサービスにログインすると、認証サーバ２０は、一時的なユーザＩＤを発行する。以降、この一時的なユーザＩＤを、ＴＵＩＤ（Temporary User ID）という。ＴＵＩＤは、ユーザを識別可能な情報である。ＴＵＩＤは、所定の無効条件が満たされると無効になる。第１実施形態では、ユーザがオンラインサービスにログインすることが無効条件に相当する場合を例に挙げるが、無効条件は、任意の条件であってよい。例えば、無効条件は、所定の有効期限が経過すること、一定回数のログインが発生すること、又はユーザが所定の操作をすることであってもよい。

【0025】

認証サーバ２０が発行したＴＵＩＤは、ユーザＰＣ３０に記録される。第１実施形態では、ＴＵＩＤがブラウザのｃｏｏｋｉｅとして記録される場合を説明するが、ｃｏｏｋｉｅ以外の情報としてＴＵＩＤが記録されてもよい。ＴＵＩＤは、表示部３５に表示されてもよいが、原則としてユーザの目に触れないものとする。２回目以降のログインでは、顔認証とともに、ＴＵＩＤを利用したＴＵＩＤ認証が実行される。ＴＵＩＤが記録されたユーザＰＣ３０でなければＴＵＩＤ認証が成功しないので、ＴＵＩＤ認証は、所持認証の一種である。顔認証及びＴＵＩＤ認証を組み合わせた多要素認証であれば、操作部３４からの入力を発生させず、かつ、ある程度のセキュリティを担保できると考えられる。

【0026】

しかしながら、同じＴＵＩＤを長期間使いまわすと、悪意のある第三者に、有効なＴＵＩＤが盗まれる可能性がある。例えば、リプレイアタックによって第三者にｃｏｏｋｉｅが盗まれてしまい、ｃｏｏｋｉｅに含まれるＴＵＩＤも盗まれる可能性がある。第三者が、ＴＵＩＤだけではなく、ユーザの顔写真も何らかの形で入手したとすると、なりすましが可能になってしまう。このため、ある一定期間でＴＵＩＤを無効にすることも考えられる。

【0027】

しかしながら、ＴＵＩＤがすぐに無効になると、あまり頻繁にはログインしないユーザは、ユーザＩＤ及びパスワードを毎回入力する必要があるので、ユーザの利便性が低下する。そこで、第１実施形態では、ユーザの利便性を高めつつ、第三者にＴＵＩＤを盗まれないようにするために、ソルトを利用してＴＵＩＤを変換するようにしている。ただし、同じソルトを長期間使いまわすと、第三者にソルト自体を盗まれる可能性があるので、ユーザがログインする日及び時間帯に応じたソルトが利用されるようになっている。

【0028】

図２は、第１実施形態における多要素認証の流れの一例を示す図である。図２のように、ユーザがオンラインサービスにログインする場合、ユーザＰＣ３０は、ソルトサーバ１０に対し、ソルトを取得するためのソルト要求を送信する。図２の例では、ｇｅｔＳａｌｔ（）といったコマンドがソルト要求に含まれる。このコマンドは、ソルトに関する条件が含まれていないので、悪意のある第三者がソルト要求を盗み見たとしても、どのような条件でソルトが生成されているかを特定することはできない。

【0029】

ソルトサーバ１０は、ソルト要求を受信すると、ソルトデータベースＤＢ１を参照し、現在の日及び時間帯に応じたソルトを取得する。図２のように、ソルトデータベースＤＢ１には、日及び時間帯の組み合わせごとに、ソルトが格納されている。例えば、１ヶ月を３１日間として、１日の２４時間を１時間ごとの時間帯で区切ったとすると、図２の例では、３１×２４＝７４４通りのソルトがソルトデータベースＤＢ１に格納されている。ソルトサーバ１０が、ソルトデータベースＤＢ１からソルトを取得する時点が「２０２１年１２月２日０１時２５分３４秒」だったとすると、ソルトサーバ１０は、「２日」及び「０１時」に応じたソルト「８４１４」を取得してユーザＰＣ３０に送信する。

【0030】

ユーザＰＣ３０は、ソルトサーバ１０からソルト「８４１４」を受信すると、ソルト「８４１４」と、所定の変換関数ｆと、に基づいて、ＴＵＩＤ「３１２４５６」を変換する。図２の例では、変換関数ｆは、ＴＵＩＤ「３１２４５６」にソルト「８４１４」を加算する関数である。変換後のＴＵＩＤは、これらの和の「３２０８７０」になる。ユーザＰＣ３０は、撮影部３６が生成したユーザの顔写真と、変換後のＴＵＩＤ「３２０８７０」と、を含む認証要求を、認証サーバ２０に送信する。

【0031】

認証サーバ２０は、認証要求を受信すると、ソルトサーバ１０に対し、ソルト要求を送信する。図２の例では、ユーザＰＣ３０からソルトサーバ１０に対するソルト要求と、認証サーバ２０からソルトサーバ１０に対するソルト要求と、は同じ形式である。このため、認証サーバ２０からソルトサーバ１０に対するソルト要求も、ｇｅｔＳａｌｔ（）といったように、ソルトの条件が分からないようになっている。ソルト要求の形式を共通にすることによって、ソルトサーバ１０のＡＰＩも共通化できる。

【0032】

ソルトサーバ１０は、認証サーバ２０からソルト要求を受信すると、ソルトデータベースＤＢ１を参照し、現在の日及び時間帯に応じたソルトを取得する。ソルトサーバ１０が、ソルトデータベースＤＢ１からソルトを取得する時点が「２０２１年１２月２日０１時２５分３５秒」だったとすると、ソルトサーバ１０は、「２日」及び「０１時」に応じたソルト「８４１４」を、認証サーバ２０に送信する。このソルト「８４１４」は、ユーザＰＣ３０に送信されたものと同じである。

【0033】

認証サーバ２０は、ソルトサーバ１０からソルト「８４１４」を受信すると、ソルト「８４１４」と、逆変換関数ｆ^－１と、に基づいて、ユーザＰＣから受信した変換後のＴＵＩＤ「３２０８７０」を逆変換する。図２の例では、逆変換関数ｆ^－１は、変換後のＴＵＩＤ「３２０８７０」からソルト「８４１４」を減算する関数である。認証サーバ２０は、逆変換により、ＴＵＩＤ「３１２４５６」を取得する。

【0034】

認証サーバ２０は、ＴＵＩＤ「３１２４５６」を取得すると、ユーザデータベースＤＢ２にＴＵＩＤ「３１２４５６」が存在するか否かを確認する。ユーザデータベースＤＢ２には、多要素認証における正解となる認証情報が格納されている。ＴＵＩＤ「３１２４５６」の存在有無を確認する処理は、ＴＵＩＤ認証に相当する。ユーザデータベースＤＢ２にＴＵＩＤ「３１２４５６」が格納されていなければ、その時点でエラーとなり、ユーザはログインできない。

【0035】

認証サーバ２０は、ＴＵＩＤ「３１２４５６」がユーザデータベースＤＢ２に存在することを確認すると、ＴＵＩＤ「３１２４５６」に関連付けられてユーザデータベースＤＢ２に格納された顔の特徴量を取得する。認証サーバ２０は、当該取得された顔の特徴量と、ユーザＰＣ３０から受信した顔写真から計算した顔の特徴量と、に基づいて、顔認証を実行する。認証サーバ２０は、顔認証が成功すると、ユーザＰＣ３０に対し、多要素認証が成功したことを示す認証結果を送信する。ユーザＰＣ３０は、この認証結果を受信すると、オンラインサービスにログインした状態になる。

【0036】

なお、認証サーバ２０は、ユーザがログインした場合に、新たなＴＵＩＤを発行し、ユーザデータベースＤＢ２に格納してもよい。即ち、認証サーバ２０は、ユーザがログインするたびに、ＴＵＩＤを更新してもよい。新たなＴＵＩＤが「４１７６３２」だったとすると、認証サーバ２０は、ユーザＰＣ３０に対し、新たなＴＵＩＤ「４１７６３２」を含む認証結果を送信すればよい。新たなＴＵＩＤ「４１７６３２」は、ソルトサーバ１０から受信済みのソルト「８４１４」で変換されてもよい。この場合、認証サーバ２０は、新たなＴＵＩＤを変換するための変換関数を記憶し、ユーザＰＣ３０は、変換後の新たなＴＵＩＤを逆変換するための逆変換関数ｆ^－１を記憶しているものとする。この逆変換でも、ソルトサーバ１０から受信済みのソルト「８４１４」が利用されてもよい。

【0037】

以上のように、第１実施形態の認証システムＳは、ユーザがログインする時の日及び時間帯の組み合わせに応じたソルトに基づいて、ＴＵＩＤを変換したり、変換後のＴＵＩＤを逆変換したりする。これにより、ＴＵＩＤがそのままネットワークＮ上に送信されないので、第三者は、ＴＵＩＤを簡単に入手できないようになる。このため、多要素認証におけるセキュリティが高まるようになっている。以降、第１実施形態の認証システムＳの詳細を説明する。

【0038】

［１－３．第１実施形態の認証システムで実現される機能］
図３は、第１実施形態の認証システムＳで実現される機能の一例を示す機能ブロック図である。

【0039】

［１－３－１．ソルトサーバにおいて実現される機能］
データ記憶部１００は、記憶部１２を主として実現される。ソルト生成部１０１、ソルト要求受信部１０２、及びソルト送信部１０３は、制御部１１を主として実現される。

【0040】

[データ記憶部]
データ記憶部１００は、ソルトを管理するために必要なデータを記憶する。例えば、データ記憶部１００は、ソルトデータベースＤＢ１を記憶する。

【0041】

図４は、ソルトデータベースＤＢ１の一例を示す図である。ソルトデータベースＤＢ１は、ソルトが格納されたデータベースである。例えば、ソルトデータベースＤＢ１には、日及び時間帯の組み合わせごとに、ソルトが格納される。即ち、ソルトデータベースＤＢ１には、日及び時間帯の組み合わせと、ソルトと、が関連付けられている。ソルトデータベースＤＢ１に格納されるソルトは、予め定められたタイミングで更新されてもよい。

【0042】

図４の例では、過去の日及び時間で利用されたソルトと、未来の日及び時間で利用される予定のソルトと、も格納される場合を説明するが、現在の日及び時間で利用されるソルトだけがソルトデータベースＤＢ１に格納されてもよい。例えば、現時点が「２０２１年１２月２日０１：２５：３４」だったとすると、「２日」及び「０１時」のソルトだけがソルトデータベースＤＢ１に格納されてもよい。この場合、「２０２１年１２月２日０２：００：００」になると、「２日」及び「０２時」のソルトだけがソルトデータベースＤＢ１に格納される。

【0043】

なお、データ記憶部１００は、ソルトデータベースＤＢ１以外の他の任意のデータを記憶可能である。例えば、データ記憶部１００は、ソルトを生成するためのアルゴリズムを記憶してもよい。データ記憶部１００は、認証サーバ２０及びユーザＰＣ３０とソルトのやりとりをするためのＡＰＩに関するデータを記憶してもよい。第１実施形態では、認証サーバ２０及びユーザＰＣ３０から同じ形式のソルト要求を受け付けることができるように、認証サーバ２０及びユーザＰＣ３０で共通のＡＰＩとするが、認証サーバ２０用のＡＰＩと、ユーザＰＣ３０用のＡＰＩと、が異なってもよい。

【0044】

［ソルト生成部］
ソルト生成部１０１は、所定のアルゴリズムに基づいて、ソルトを生成する。例えば、ソルト生成部１０１は、ランダムな値になるように、ソルトを生成する。ランダムな値を生成する方法自体は、公知の種々の方法を利用可能である。例えば、ソルト生成時のタイムスタンプを利用する方法であってもよいし、タイムスタンプ以外の他のデータを利用する方法であってもよい。ソルト生成部１０１は、ソルトデータベースＤＢ１に、生成したソルトを格納する。

【0045】

第１実施形態では、ソルト生成部１０１は、将来の日及び時間帯の組み合わせごとに、ソルトを生成する。ソルト生成部１０１は、この組み合わせと、生成したソルトと、を関連付けてソルトデータベースＤＢ１に格納する。ソルト生成部１０１は、所定のタイミングで、ソルトデータベースＤＢ１に格納されたソルトを更新してもよい。このタイミングは、任意のタイミングであってよく、例えば、ある月の初日、ある週の初日、又は１日の始まりといったタイミングであってもよい。

【0046】

第１実施形態では、ＴＵＩＤの変換と、変換後のＴＵＩＤの逆変換と、で同じソルトが利用される場合を例に挙げる。このため、ソルトは、変換情報の一例であり、逆変換情報の一例でもある。ソルトと記載した箇所は、変換情報と読み替えることができる。ソルトと記載した箇所は、逆変換情報と読み替えることもできる。変換情報は、暗号理論における暗号鍵である。逆変換情報は、暗号理論における復号鍵である。第１実施形態では、変換情報及び逆変換情報が互いに同じなので、変換情報及び逆変換情報は、暗号理論における共通鍵に相当する。

【0047】

変換情報及び逆変換情報は、互いに異なってもよい。例えば、変換情報は、暗号理論における公開鍵であり、逆変換情報は、暗号理論における秘密鍵であってもよい。逆に、変換情報は、暗号理論における秘密鍵であり、逆変換情報は、暗号理論における公開鍵であってもよい。変換情報及び逆変換情報が互いに異なる場合、ソルトデータベースＤＢ１には、変換情報及び逆変換情報の両方が格納される。これら両方のうちの変換情報がユーザＰＣ３０に送信され、逆変換情報が認証サーバ２０に送信される。第１実施形態のように、日及び時間帯の組み合わせに応じた変換情報及び逆変換情報にするのであれば、ソルトデータベースＤＢ１には、日及び時間帯の組み合わせごとに、変換情報及び逆変換情報の組み合わせが格納される。

【0048】

［ソルト要求受信部］
ソルト要求受信部１０２は、認証サーバ２０及びユーザＰＣ３０の各々からソルト要求を受信する。ソルト要求は、ソルトを要求するために送信される所定形式の情報である。図２では、ｇｅｔＳａｌｔ（）といったコマンドを含むソルト要求を例に挙げたが、ソルト要求は、ソルトが要求されたことを示す情報であればよい。第１実施形態では、認証サーバ２０からのソルト要求と、ユーザＰＣ３０からのソルト要求と、が同じ形式である場合を説明するが、これらの形式は、互いに異なってもよい。

【0049】

［ソルト送信部］
ソルト送信部１０３は、認証サーバ２０及びユーザＰＣ３０の各々に対し、ソルトを送信する。第１実施形態では、ソルト送信部１０３は、認証サーバ２０及びユーザＰＣ３０の各々に対し、ソルトが取得される時点であるソルト取得時点が属する日及び時間帯に応じたソルトを送信する。ソルト取得時点は、ソルト要求が受信されてからソルトが送信されるまでの間の時点であればよい。ソルト送信部１０３は、ソルトデータベースＤＢ１を参照し、ソルト取得時点が属する日及び時間帯の組み合わせを特定する。ソルト送信部１０３は、認証サーバ２０及びユーザＰＣ３０の各々に対し、当該特定した組み合わせに関連付けられたソルトを送信する。

【0050】

なお、図３では、１つのソルト送信部１０３だけを示しているが、ユーザＰＣ３０に対するソルトの送信と、認証サーバ２０に対するソルトの送信と、を別々の機能として捉えることもできる。このため、ソルト送信部１０３が、ユーザＰＣ３０からのソルト要求が受け付けられた場合に、ユーザＰＣ３０に対し、ソルトを送信する第１ソルト送信部１０３Ａと、認証サーバ２０からのソルト要求が受け付けられた場合に、認証サーバ２０に対し、ソルトを送信する第２ソルト送信部１０３Ｂと、を含むと捉えることもできる。ユーザＰＣ３０に対するソルトの送信手順と、認証サーバ２０に対するソルトの送信手順と、が異なる場合には、第１ソルト送信部１０３Ａは、ユーザＰＣ３０に対するソルトの送信手順に沿って、ユーザＰＣ３０に対し、ソルトを送信すればよい。第２ソルト送信部１０３Ｂは、認証サーバ２０に対するソルトの送信手順に沿って、認証サーバ２０に対し、ソルトを送信すればよい。

【0051】

［１－３－２．認証サーバにおいて実現される機能］
データ記憶部２００は、記憶部２２を主として実現される。情報受信部２０１、ソルト要求部２０２、ソルト取得部２０３、逆変換部２０４、多要素認証部２０５、ＴＵＩＤ生成部２０６、及び認証結果送信部２０７が実現される。

【0052】

［データ記憶部］
データ記憶部２００は、多要素認証に必要なデータを記憶する。例えば、データ記憶部２００は、ユーザデータベースＤＢ２を記憶する。

【0053】

図５は、ユーザデータベースＤＢ２の一例を示す図である。ユーザデータベースＤＢ２は、ユーザに関する情報が格納されたデータベースである。例えば、ユーザデータベースＤＢ２には、ユーザＩＤ、パスワード、氏名、ＴＵＩＤ、顔写真、及び顔の特徴量が格納される。ユーザデータベースＤＢ２に格納される情報は、任意の種類であってよく、図５の例に限られない。例えば、ユーザＰＣ３０とのセッションを維持するためのセッションＩＤ、ユーザによる過去のログイン履歴、又はユーザによるオンラインサービスの利用履歴がユーザデータベースＤＢ２に格納されてもよい。

【0054】

顔写真は、生体情報の一例である。ＴＵＩＤは、生体情報とは異なる認証情報の一例である。このため、顔写真について説明している箇所は、生体情報と読み替えることができる。ＴＵＩＤについて説明している箇所は、生体情報とは異なる認証情報と読み替えることができる。生体情報と、生体情報とは異なる認証情報と、の組み合わせは、任意の組み合わせであってよい。この組み合わせは、多要素認証における要素の組み合わせである。

【0055】

生体情報は、生体認証で利用される情報である。生体情報自体は、種々の情報であってよく、例えば、顔の特徴量が生体情報に相当してもよい。顔の特徴量が変換されたテンプレートと呼ばれる情報が生体情報に相当してもよい。顔認証以外の生体認証が利用される場合には、生体認証に応じた生体情報が利用されるようにすればよい。他の生体情報の例は、先述した通りである。生体情報とは異なる認証情報は、生体情報とともに多要素認証で利用される情報である。この認証情報は、所持情報又は知識情報である。３要素以上の多要素認証であれば、生体情報とは異なる認証情報は、複数存在してもよい。

【0056】

なお、データ記憶部２００は、ユーザデータベースＤＢ２以外の他の任意のデータを記憶可能である。例えば、データ記憶部２００は、逆変換関数ｆ^－１を記憶してもよい。例えば、データ記憶部２００は、ＴＵＩＤを生成するアルゴリズムを記憶してもよい。

【0057】

［情報受信部］
情報受信部２０１は、ユーザＰＣ３０から、変換後のＴＵＩＤと、顔写真と、を受信する。顔写真を受信するとは、顔が撮影された画像の画像データを受信することである。顔写真は、静止画であってもよいし、動画に含まれる個々のフレームであってもよい。第１実施形態では、変換後のＴＵＩＤと、顔写真と、が認証要求に含まれる場合を例に挙げる。このため、情報受信部２０１は、ユーザＰＣ３０から認証要求を受信することによって、変換後のＴＵＩＤと、顔写真と、を受信する。認証要求は、多要素認証を実行するための要求である。認証要求は、所定の形式の情報が送信されることにより行われるようにすればよい。認証要求は、他の情報が含まれてもよい。例えば、認証要求には、ユーザＰＣ３０のＩＰアドレスといったように、ユーザＰＣ３０を識別可能な情報が含まれてもよい。

【0058】

［ソルト要求部］
ソルト要求部２０２は、ソルトサーバ１０に対し、ソルトを要求する。ソルトを要求するためのソルト要求については、先述した通りである。第１実施形態では、ソルト要求部２０２は、ソルトサーバ１０に対し、ソルトの取得ルールに関する情報を含まないソルト要求を送信する。例えば、日及び時間帯の組み合わせに応じたソルトが取得される場合、取得ルールは、日及び時間帯の組み合わせとなる。ソルト要求には、日及び時間帯の情報は含まれないので、取得ルールに関する情報が含まれない。

【0059】

取得ルールに関する情報がソルト要求に含まれない点は、他の取得ルールを採用する場合も同様である。例えば、時間帯を考慮せずに日ごとに異なるソルトにする場合には、取得ルールは、日のみとなる。ソルト要求には、日に関する情報は含まれないので、取得ルールに関する情報が含まれない。例えば、日を考慮せずに時間帯ごとに異なるソルトにする場合には、取得ルールは、時間帯のみとなる。ソルト要求には、時間帯に関する情報は含まれないので、取得ルールに関する情報が含まれない。

【0060】

なお、ソルト要求には、ソルトの取得ルールが含まれてもよい。例えば、ソルトを生成するための種となる情報がソルト要求に含まれてもよい。この場合、種が同じでなければ同じソルトにはならないので、認証サーバ２０及びユーザＰＣ３０の間で、ソルトを生成した種が共有されるものとする。例えば、後述の第２実施形態のように、ソルトの取得ルールの一部（第２実施形態では、ＴＵＩＤの下２桁）がソルト要求に含まれてもよい。

【0061】

［ソルト取得部］
ソルト取得部２０３は、変換後のＴＵＩＤを逆変換するためのソルトを取得する。このソルトは、逆変換情報の一例である。ソルト取得部２０３は、逆変換情報取得部の一例である。このため、ソルト取得部２０３について説明している箇所は、逆変換情報取得部と読み替えることができる。逆変換情報取得部は、ソルトを一例とする逆変換情報を取得する。逆変換情報がソルト以外の名前で呼ばれる場合には、逆変換情報取得部は、この名前に応じた名前で呼ばれてよい。例えば、逆変換情報が鍵と呼ばれる場合には、逆変換情報取得部は、鍵を取得する。

【0062】

第１実施形態では、ソルトサーバ１０がソルトを管理するので、ソルト取得部２０３は、ソルトサーバ１０からソルトを取得する。ソルトは、認証サーバ２０自身が管理してもよい。即ち、認証サーバ２０が管理装置に相当してもよい。この場合、データ記憶部２００は、ソルトデータベースＤＢ１を記憶する。更に、この場合、ソルトサーバ１０で実現されるものとして説明したソルト生成部１０１、ソルト要求受信部１０２、及びソルト送信部１０３は、認証サーバ２０により実現される。

【0063】

第１実施形態では、ソルト取得部２０３は、日及び時間帯の組み合わせに応じたソルトを取得する。日及び時間帯の組み合わせは、第１取得期間の一例である。このため、日及び時間帯の組み合わせについて説明している箇所は、第１取得期間と読み替えることができる。第１取得期間は、ソルトが取得される第１取得時点が属する期間である。第１実施形態では、第１取得期間が日及び時間帯の組み合わせで示される場合を例に挙げるが、第１取得期間は、日だけを意味してもよいし、時間帯だけを意味してもよい。

【0064】

第１取得期間の区切り方は、第１実施形態のような１時間単位に限られない。個々の期間の長さは、１時間よりも長くてもよいし短くてもよい。ある期間と他の期間の長さが異なってもよい。第１取得期間が日及び時間帯の組み合わせ以外の他の意味だったとしても、ソルト取得部２０３は、第１取得期間に応じたソルトを取得すればよい。個々の期間と、ソルトと、の関係は、ソルトデータベースＤＢ１に格納されているものとする。ソルト取得部２０３は、第１取得期間に応じたソルトを取得すればよい。

【0065】

［逆変換部］
逆変換部２０４は、ソルト取得部２０３により取得されたソルトに基づいて、変換後のＴＵＩＤを逆変換する。逆変換は、暗号理論における復号化である。逆変換のための逆変換関数ｆ^－１は、データ記憶部２００に記憶されているものとする。逆変換部２０４は、逆変換情報の一例であるソルトに基づいて、変換後のＴＵＩＤを逆変換関数ｆ^－１で逆変換する。図２の例であれば、逆変換部２０４は、変換後のＴＵＩＤからソルトを減算することによって、変換後のＴＵＩＤを逆変換してＴＵＩＤを取得する。

【0066】

なお、逆変換自体は、種々の逆変換関数ｆ^－１を利用可能であり、図２のような減算に限られない。例えば、加算、乗算、除算、行列変換、その他の計算、又はこれらの組み合わせにより、逆変換が行われてもよい。図２の例では、説明の簡略化のために、変換関数ｆ及び逆変換関数ｆ^－１がそれぞれ単純な加算及び減算である場合を示しているが、実際には、ある程度複雑な計算式であるものとする。

【0067】

［多要素認証部］
多要素認証部２０５は、逆変換部２０４により逆変換されたＴＵＩＤと、情報受信部２０１が受信した顔写真と、に基づいて、多要素認証を実行する。先述したように、多要素認証自体は、種々の種類を利用可能である。第１実施形態では、多要素認証部２０５は、ユーザデータベースＤＢ２を参照し、逆変換部２０４により逆変換されたＴＵＩＤに関連付けられた顔の特徴量を取得する。この顔の特徴量は、多要素認証における正解となる認証情報である。ユーザデータベースＤＢ２に格納された顔の特徴量のうち、逆変換部２０４により逆変換されたＴＵＩＤに関連付けられた顔の特徴量だけが比較対象となる。他の顔の特徴量は、比較対象にならない。

【0068】

多要素認証部２０５は、情報受信部２０１が受信した顔写真に基づいて、顔の特徴量を計算する。顔の特徴量の計算方法自体は、種々の計算方法を利用可能である。例えば、コントラストフィルタ又は主成分分析を利用した計算方法により、顔の特徴量が計算されてもよい。顔の特徴量は、多次元ベクトル、配列、又は単一の数値といった任意の形式で表現可能である。顔認証は、顔の特徴量同士を比較するものではなく、２枚の顔写真を機械学習モデルに入力して類否を判定するタイプのものであってもよい。

【0069】

多要素認証部２０５は、ユーザデータベースＤＢ２から取得した顔の特徴量と、情報受信部２０１が受信した顔写真から計算した顔の特徴量と、の類否を判定する。例えば、顔の特徴量が多次元ベクトルで表現される場合、ベクトル空間上における顔の特徴量の距離が閾値未満であることは、特徴量が類似することに相当する。多要素認証部２０５は、顔の特徴量が互いに類似する場合、多要素認証が成功したと判定する。多要素認証部２０５は、顔の特徴量が互いに類似しない場合、多要素認証が失敗したと判定する。

【0070】

［ＴＵＩＤ生成部］
ＴＵＩＤ生成部２０６は、所定のアルゴリズムに基づいて、ＴＵＩＤを生成する。ＴＵＩＤ生成部２０６は、ユーザＰＣ３０にＴＵＩＤが存在しない場合に、ユーザＰＣ３０に新たに記録するＴＵＩＤを生成する。ＴＵＩＤ生成部２０６は、ユーザＰＣ３０にＴＵＩＤが存在する状態で、このＴＵＩＤに代えてユーザＰＣ３０に書き込むＴＵＩＤ（更新後のＴＵＩＤ）を生成する。

【0071】

例えば、ＴＵＩＤ生成部２０６は、ランダムな値になるように、ＴＵＩＤを生成する。ランダムな値を生成する方法自体は、公知の種々の方法を利用可能である。例えば、ＴＵＩＤ生成時のタイムスタンプを利用する方法であってもよいし、タイムスタンプ以外の他のデータを利用する方法であってもよい。ＴＵＩＤ生成部２０６は、ユーザデータベースＤＢ２に、生成したＴＵＩＤを格納する。

【0072】

ＴＵＩＤ生成部２０６は、他のユーザのＴＵＩＤと重複しないように、ＴＵＩＤを生成してもよい。ＴＵＩＤ生成部２０６は、顔が似ていない他のユーザのＴＵＩＤとの重複は許可するが、顔が似た他のユーザのＴＵＩＤと重複しないように、ＴＵＩＤを生成してもよい。ＴＵＩＤ生成部２０６は、多要素認証が成功した場合に、ＴＵＩＤを生成してもよい。即ち、ＴＵＩＤ生成部２０６は、ユーザがオンラインサービスにログインするたびに、ＴＵＩＤを生成してもよい。１回目のログインであれば、ＴＵＩＤ生成部２０６は、ユーザＩＤ及びパスワードの認証が成功した場合に、ＴＵＩＤを生成する。

【0073】

なお、ＴＵＩＤが生成されるタイミングは、任意のタイミングであってよく、第１実施形態の例に限られない。例えば、１回のログインだけでＴＵＩＤが無効になるのではなくい、２回以上の所定回数だけ同じＴＵＩＤを有効にする場合には、ＴＵＩＤ生成部２０６は、当該所定回数のログインが発生するたびに、ＴＵＩＤを生成してもよい。例えば、ＴＵＩＤに有効期限を設ける場合には、ＴＵＩＤ生成部２０６は、有効期限が近づいた時にユーザがログインした場合に、ＴＵＩＤを生成してもよい。

【0074】

［認証結果送信部］
認証結果送信部２０７は、ユーザＰＣ３０に対し、多要素認証の認証結果を送信する。認証結果は、多要素認証が成功したか否かを示す所定の形式の情報である。例えば、認証結果は、ログインが許可されたか否かが示される。第１実施形態では、ログインのタイミングで新たなＴＵＩＤが生成されるので、認証結果には、ＴＵＩＤが生成したＴＵＩＤが含まれる。

【0075】

なお、多要素認証が成功すると、所定の処理の実行が許可される。第１実施形態では、この処理の一例として、オンラインサービスへのログインを説明するが、この処理は、多要素認証が成功したことを条件として許可される処理であればよい。この処理は、認証システムＳを適用する場面に応じて定めればよい。例えば、金融サービスに認証システムＳを適用する場合には、振込の実行が所定の処理に相当してもよい。例えば、決済サービスに認証システムＳを適用する場合には、決済の実行が所定の処理に相当してもよい。例えば、電子商取引サービスに認証システムＳを適用する場合には、商品の購入が所定の処理に相当してもよい。所定の処理は、他の任意の処理であってよい。

【0076】

［１－３－３．ユーザＰＣにおいて実現される機能］
データ記憶部３００は、記憶部３２を主として実現される。ソルト要求部３０１、ソルト取得部３０２、変換部３０３、情報送信部３０４、及び認証結果受信部３０５は、制御部３１を主として実現される。

【0077】

［データ記憶部］
データ記憶部３００は、多要素認証に必要なデータを記憶する。例えば、データ記憶部３００は、ＴＵＩＤ及び変換関数ｆを記憶する。ユーザの顔写真を生成するために撮影部３６を利用しない場合には、データ記憶部３００は、ユーザの顔写真の画像データを記憶してもよい。例えば、オンラインサービス用のアプリケーションが用意されている場合には、データ記憶部３００は、このアプリケーションを記憶してもよい。

【0078】

［ソルト要求部］
ソルト要求部３０１は、ソルトサーバ１０に対し、ソルトを要求する。ソルトを要求するためのソルト要求については、先述した通りである。第１実施形態では、ソルト要求部３０１は、ソルトサーバ１０に対し、ソルトの取得ルールに関する情報を含まないソルト要求を送信する。この点は、認証サーバ２０のソルト要求部２０２と同様である。ソルト要求に関する他の点についても、ソルト要求部２０２の処理で説明した通りである。

【0079】

第１実施形態では、ソルト要求部３０１は、撮影部３６により顔写真が生成された場合に、ソルトサーバ１０に対し、ソルトを要求する。ソルト要求部３０１は、任意のタイミングでソルトを要求すればよく、顔写真が生成されたタイミングに限られない。例えば、ソルト要求部３０１は、オンラインサービス用のアプリケーションが起動したタイミング、ユーザがログインをするための操作をしたタイミング、又はオンラインサービスのウェブサイトへのアクセスが発生したタイミングで、ソルトを要求してもよい。

【0080】

［ソルト取得部］
ソルト取得部３０２は、顔写真とは異なるＴＵＩＤを変換するためのソルトを取得する。第１実施形態では、ソルトサーバ１０からユーザＰＣ３０へのソルトの取得と、ソルトサーバ１０から認証サーバ２０へのソルトの取得と、が同じ手順で行われるので、ソルト要求部３０１の処理は、認証サーバ２０のソルト要求部２０２の処理と同様である。このため、ソルトサーバ１０からソルトを取得する点、ソルトが取得される第１取得時点が属する第１取得期間に応じたソルトを取得する点、日及び時間帯の組み合わせに応じたソルトを取得する点についても同様である。

【0081】

［変換部］
変換部３０３は、ソルトに基づいて、ＴＵＩＤを変換する。変換は、暗号理論における暗号化である。変換は、ＴＵＩＤに対して何らかの変更がなされるものであればよい。例えば、ＴＵＩＤを何らかの関数に入力すること、ＴＵＩＤの一部を変更すること、ＴＵＩＤの全部を変更すること、ＴＵＩＤに対して何らかの情報を付加すること、又はＴＵＩＤの一部を削除することが変換に相当する。逆変換は、これらの逆方向の処理（ＴＵＩＤを元に戻す処理）であればよい。

【0082】

変換のための変換関数ｆは、データ記憶部３００に記憶されているものとする。変換部３０３は、変換情報の一例であるソルトに基づいて、変換前のＴＵＩＤを変換関数ｆで変換する。図２の例であれば、変換部３０３は、変換前のＴＵＩＤにソルトを加算することによって、変換前のＴＵＩＤを変換し、変換後のＴＵＩＤを取得する。変換自体は、種々の変換関数を利用可能であり、図２のような加算に限られない。例えば、減算、乗算、除算、行列変換、その他の計算、又はこれらの組み合わせにより、変換が行われてもよい。

【0083】

［情報送信部］
情報送信部３０４は、認証サーバ２０に対し、変換後のＴＵＩＤと、顔写真と、を送信する。第１実施形態では、変換後のＴＵＩＤと、顔写真と、が認証要求に含まれる場合を例に挙げる。このため、情報送信部３０４は、認証サーバ２０に対し、変換後のＴＵＩＤと、顔写真と、を含む認証要求を送信することによって、変換後のＴＵＩＤと、顔写真と、を送信する。情報送信部３０４は、変換後のＴＵＩＤと、顔写真と、を１つのデータにまとめて送信しなくてもよい。情報送信部３０４は、変換後のＴＵＩＤと、顔写真と、を別々に送信してもよい。なお、顔写真もそのまま送信されるのではなく、ソルト又は他の暗号鍵に基づいて変換されてもよい。ユーザＰＣ３０側で顔の特徴量が計算されて、当該計算された顔の特徴量が生体情報として送信されてもよい。

【0084】

［認証結果受信部］
認証結果受信部３０５は、認証サーバ２０から、認証結果を受信する。この認証結果が成功を示す場合、ユーザがオンラインサービスにログインする。即ち、先述した所定の処理の実行が許可される。新たなＴＵＩＤが認証結果に含まれている場合、認証結果受信部３０５は、認証結果に含まれるＴＵＩＤをデータ記憶部３００に記録する。それまでに記録されていた古いＴＵＩＤは、データ記憶部３００から破棄される。

【0085】

［１－４．第１実施形態の認証システムで実行される処理］
図６及び図７は、第１実施形態の認証システムＳで実行される処理の一例を示す図である。制御部１１，２１，３１がそれぞれ記憶部１２，２２，３２に記憶されたプログラムを実行することによって、図６及び図７の処理が実行される。図６及び図７の処理が実行されるにあたり、ユーザのユーザＩＤ及びパスワードが発行済みであるものとする。また、ソルトデータベースＤＢ１にソルトが格納済みであるものとする。

【0086】

図６のように、ユーザＰＣ３０は、オンラインサービスのアプリケーションを起動させ、記憶部３２にＴＵＩＤがあるか否かを判定する（Ｓ１）。ＴＵＩＤがないと判定された場合（Ｓ１；Ｎ）、ユーザＰＣ３０は、操作部３４の検出信号に基づいて、ユーザによるユーザＩＤ及びパスワードの入力を受け付ける（Ｓ２）。認証サーバ２０及びユーザＰＣ３０の間で、オンラインサービスにログインするためのログイン処理が実行される（Ｓ３）。Ｓ３では、ユーザデータベースＤＢ２に基づいて、ユーザＩＤ及びパスワードの正当性が確認される。ログインが成功すると、認証サーバ２０は、新たなＴＵＩＤを発行し（Ｓ４）、ユーザＰＣ３０に対し、新たなＴＵＩＤを含む認証結果を送信する（Ｓ５）。

【0087】

ユーザＰＣ３０は、認証結果を受信すると（Ｓ６）、認証結果に含まれるＴＵＩＤを記憶部３２に記録し（Ｓ７）、本処理は終了する。Ｓ７において、ＴＵＩＤは、ｃｏｏｋｉｅの一部として記録されてもよい。その後、ユーザＰＣ３０は、ユーザにオンラインサービスを利用させるための処理を実行する。ユーザがオンラインサービスからログアウトするための操作をすると、認証サーバ２０及びユーザＰＣ３０の間で、オンラインサービスからログアウトするためのログアウト処理が実行される。

【0088】

Ｓ１において、ＴＵＩＤがあると判定された場合（Ｓ１；Ｙ）、ユーザＰＣ３０は、撮影部３６に基づいて、ユーザの顔を撮影して顔写真を生成する（Ｓ８）。ユーザＰＣ３０は、ソルトサーバ１０に対し、ソルト要求を送信する（Ｓ９）。ソルトサーバ１０は、ソルト要求を受信すると（Ｓ１０）、ソルトデータベースＤＢ１に基づいて、ユーザＰＣ３０に対し、現在の日及び時間帯に応じたソルトを送信する（Ｓ１１）。ユーザＰＣ３０は、ソルトサーバ１０からソルトを受信すると（Ｓ１２）、このソルトに基づいて、記憶部３２に記憶されたＴＵＩＤを変換する（Ｓ１３）。

【0089】

図７に移り、ユーザＰＣ３０は、認証サーバ２０に対し、Ｓ１３における変換後のＴＵＩＤと、Ｓ８で生成した顔写真と、を含む認証要求を送信する（Ｓ１４）。認証サーバ２０は、認証要求を受信すると（Ｓ１５）、ソルトサーバ１０に対し、ソルト要求を送信する（Ｓ１６）。ソルトサーバ１０は、ソルト要求を受信すると（Ｓ１７）、ソルトデータベースＤＢ１に基づいて、認証サーバ２０に対し、現在の日及び時間帯に応じたソルトを送信する（Ｓ１８）。

【0090】

認証サーバ２０は、ソルトサーバ１０からソルトを受信すると（Ｓ１９）、このソルトに基づいて、Ｓ１５で受信した認証要求に含まれる変換後のＴＵＩＤを逆変換する（Ｓ２０）。認証サーバ２０は、Ｓ２０で逆変換されたＴＵＩＤと、Ｓ１５で受信した認証要求に含まれる顔写真と、に基づいて、多要素認証を実行する（Ｓ２１）。Ｓ２１では、認証サーバ２０は、ユーザデータベースＤＢ２に基づいて、Ｓ２０で逆変換されたＴＵＩＤに関連付けられた顔の特徴量を取得する。認証サーバ２０は、Ｓ１５で受信した顔写真に基づいて、顔の特徴量を計算する。認証サーバ２０は、当該取得された顔の特徴量の類似度が閾値以上であるか否かを判定する。ＴＵＩＤがユーザデータベースＤＢ２に存在し、顔の特徴量の類似度が閾値以上である場合に、多要素認証が成功する。

【0091】

認証サーバ２０は、多要素認証が成功したか否かを判定する（Ｓ２２）。多要素認証が失敗した場合（Ｓ２２；Ｎ）、本処理は終了する。この場合、ユーザＩＤ及びパスワードの入力が要求されてもよい。多要素認証が成功した場合（Ｓ２２；Ｙ）、オンラインサービスへのユーザのログインが許可され、Ｓ４の処理に移行する。Ｓ４以降の処理により、ユーザＰＣ３０のＴＵＩＤが更新される。

【0092】

第１実施形態の認証システムＳによれば、ユーザＰＣ３０は、顔写真とは異なるＴＵＩＤを変換するためのソルトに基づいて、ＴＵＩＤを変換し、認証サーバ２０に対し、変換後のＴＵＩＤと、顔写真と、を送信する。認証サーバ２０は、変換後のＴＵＩＤを逆変換するためのソルトに基づいて、変換後のＴＵＩＤを逆変換し、当該逆変換されたＴＵＩＤと、顔写真と、に基づいて、多要素認証を実行する。これにより、変換後のＴＵＩＤがネットワーク上に送信され、第三者にＴＵＩＤが取得されないので、多要素認証におけるセキュリティが高まる。

【0093】

また、認証システムＳは、ソルトが取得される第１取得時点が属する第１取得期間に応じたソルトを取得する。これにより、ソルトが有効な期間に制限を設けることができる。第三者がソルトを取得したとしても、このソルトを利用できる期間が制限されているので、多要素認証におけるセキュリティが高まる。

【0094】

また、認証システムＳは、日及び時間帯の組み合わせに応じたソルトを取得する。これにより、ソルトが有効な期間を時間帯単位で設定することができるので、ソルトが有効な期間を比較的短くすることができる。第三者がソルトを取得したとしても、このソルトを利用できる期間が短いので、多要素認証におけるセキュリティが効果的に高まる。

【0095】

また、認証システムＳは、ソルトを管理するソルトサーバ１０を含み、ソルトサーバ１０は、認証サーバ２０及びユーザＰＣ３０に対し、ソルトを送信する。これにより、認証サーバ２０がソルトを管理しなくてすむので、多要素認証における処理負荷を分散させることができる。即ち、ソルトサーバ１０及び認証サーバ２０で多要素認証に必要な処理を分散することができる。このため、認証サーバ２０の処理負荷を軽減できる。

【0096】

また、認証システムＳは、ソルトサーバ１０に対し、ソルトの取得ルールに関する情報を含まない要求を送信する。これにより、悪意のある第三者がソルト要求を盗んだとしても、ＴＵＩＤの変換の仕組みを解読されにくくなる。例えば、日及び時間帯に応じたソルトが取得されていたとしても、ソルト要求だけでは、この取得ルールを把握することができないので、多要素認証におけるセキュリティがより高まる。

【0097】

［２．第２実施形態］
第１実施形態では、日及び時間帯に応じたソルトが利用される場合を説明した。ソルトの取得方法は、第１実施形態の例に限られない。第２実施形態では、ソルトが取得される日と、ＴＵＩＤの一部と、の組み合わせに応じたソルトが利用される場合を説明する。以降の第２実施形態～第６実施形態では、第１実施形態と同様の点については説明を省略する。

【0098】

図８は、第２実施形態における多要素認証の流れの一例を示す図である。図８のように、大まかな流れは、第１実施形態と同様であるが、ソルトの取得方法が第１実施形態とは異なる。例えば、ソルトデータベースＤＢ１には、日及びＴＵＩＤの下２桁の組み合わせごとに、ソルトが格納されている。ユーザＰＣ３０は、ソルトサーバ１０に対し、ＴＵＩＤ「３１２４００」の下２桁「００」を含むソルト要求を送信する。悪意のある第三者は、ＴＵＩＤの下２桁を盗んだとしても、ＴＵＩＤ自体を盗むことはできないし、「００」の数値だけではソルトの取得ルールを把握することもできない。

【0099】

ソルトサーバ１０は、ソルト要求を受信すると、ソルトデータベースＤＢ１を参照し、現在の日と、ソルト要求に含まれるＴＵＩＤの下２桁と、の組み合わせに応じたソルトを取得する。図８の例では、ソルトサーバ１０がユーザＰＣ３０からソルト要求を受信した日である「２日」と、ＴＵＩＤの下２桁である「００」と、に応じたソルト「６４３５」を、ユーザＰＣ３０に送信する。

【0100】

ユーザＰＣ３０は、ソルトサーバ１０からソルト「６４３５」を受信すると、このソルト「６４３５」に基づいて、ＴＵＩＤ「３１２４００」を変換する。図８の例では、ＴＵＩＤの上４桁「３１２４」にソルト「６４３５」を加算した「９５５９」の後に、ＴＵＩＤの下２桁「００」を付加する変換関数ｆが利用されるので、変換後のＴＵＩＤは、「９５５９００」になる。ユーザＰＣ３０は、撮影部３６が生成したユーザの顔写真と、変換後のＴＵＩＤ「９５５９００」と、を含む認証要求を、認証サーバ２０に送信する。

【0101】

認証サーバ２０は、認証要求を受信すると、ソルトサーバ１０に対し、変換後のＴＵＩＤ「９５５９００」のうちの下２桁「００」を含むソルト要求を送信する。ソルトサーバ１０は、ソルト要求を受信すると、ソルトデータベースＤＢ１を参照し、現在の日である「２日」と、ソルト要求に含まれるＴＵＩＤの下２桁である「００」と、の組み合わせに応じたソルト「６４３５」を、認証サーバ２０に送信する。

【0102】

認証サーバ２０は、ソルトサーバ１０からソルト「６４３５」を受信すると、このソルト「６４３５」に基づいて、ユーザＰＣから受信した変換後のＴＵＩＤ「９５５９００」を逆変換する。図８の例では、変換後のＴＵＩＤ「９５５９００」のうちの上４桁「９５５９」からソルト「６４３５」を減算した値の後に、変換後のＴＵＩＤの下２桁「００」を付加する変換関数ｆ^－１が利用される。認証サーバ２０は、逆変換により、ＴＵＩＤの上４桁「３１２４」を取得する。認証サーバ２０は、ＴＵＩＤの上４桁「３１２４」に対し、ＴＵＩＤの下２桁「００」を付加し、ＴＵＩＤ「３１２４００」を取得する。以降の多要素認証の流れは、第１実施形態と同様である。

【0103】

第２実施形態の機能ブロックは、第１実施形態と同様である。ソルト取得部２０３，３０２は、ＴＵＩＤの下２桁に応じたソルトを取得する。ＴＵＩＤの下２桁は、ＴＵＩＤの一部分の一例である。このため、ＴＵＩＤの下２桁について説明している箇所は、ＴＵＩＤの一部分と読み替えることができる。ＴＵＩＤの一部分は、任意の部分であってよく、ＴＵＩＤの下２桁に限られない。例えば、ＴＵＩＤの上１桁であってもよいし、ＴＵＩＤの２桁目～４桁目であってもよい。ＴＵＩＤの一部分は、ＴＵＩＤの上１桁と下１桁といったように、連続した桁でなくてもよい。ＴＵＩＤの一部分の長さも任意の長さであってよい。

【0104】

第２実施形態では、ソルト取得部２０３，３０２は、ソルトが取得される日と、ＴＵＩＤの下２桁と、の組み合わせに応じたソルトを取得する場合を説明するが、ソルト取得部２０３，３０２は、日は関係なく、ＴＵＩＤの下２桁に応じたソルトを取得してもよい。この場合、ソルトデータベースＤＢ１には、ＴＵＩＤの下２桁の候補ごとに、ソルトが定義されているものとする。他にも例えば、ソルト取得部２０３，３０２は、日は関係なく、ソルトが取得される時間帯と、ＴＵＩＤの下２桁との組み合わせに応じたソルトを取得してもよい。この場合、ソルトデータベースＤＢ１には、この組み合わせごとに、ソルトが定義されているものとする。第１実施形態及び第２実施形態を組み合わせて、ソルト取得部２０３，３０２は、日、時間帯、及びＴＵＩＤの下２桁といった３つの組み合わせに応じたソルトを取得してもよい。この場合、ソルトデータベースＤＢ１には、これら３つの組み合わせごとに、ソルトが定義されているものとする。

【0105】

情報送信部３０４は、認証サーバ２０に対し、変換部３０３により変換されていないＴＵＩＤの下２桁を更に送信する。この下２桁は、暗号理論における平文に相当する。第２実施形態では、この下２桁が、変換済みのＴＵＩＤの下２桁として含まれる場合を説明するが、この下２桁は、変換済みのＴＵＩＤとは別の情報として送信されてもよい。この下２桁を変換済みのＴＵＩＤに含めて送信する場合であったとしても、元の位置（下２桁）とは異なる位置（例えば、上２桁）に付加してもよい。この下２桁は、未変換の一部分の一例である。このため、この下２桁について説明している箇所は、未変換の一部分と読み替えることができる。この一部分は、下２桁に限られない点は、先述した通りである。

【0106】

情報受信部２０１は、ユーザＰＣ３０から、未変換のＴＵＩＤの下２桁を更に受信する。第２実施形態では、未変換のＴＵＩＤの下２桁が変換済みのＴＵＩＤの一部として含まれているため、情報受信部２０１は、変換済みのＴＵＩＤを受信することによって、未変換のＴＵＩＤの下２桁を受信する。未変換のＴＵＩＤの下２桁が変換済みのＴＵＩＤとは異なる情報として送信される場合には、情報受信部２０１は、当該異なる情報として送信された未変換のＴＵＩＤの下２桁を受信すればよい。ソルト取得部２０３は、未変換のＴＵＩＤの下２桁に応じたソルトを取得する。ソルト取得部２０３によるソルトの取得方法は、ソルト取得部３０２によるソルトの取得方法と同様である。

【0107】

第２実施形態の認証システムＳによれば、ユーザＰＣ３０は、ＴＵＩＤの下２桁に応じたソルトを取得し、未変換のＴＵＩＤの下２桁を送信する。認証サーバ２０は、ユーザＰＣ３０から、未変換のＴＵＩＤの下２桁を受信し、未変換のＴＵＩＤの下２桁に対応するソルトを取得する。これにより、変換後のＴＵＩＤがネットワーク上に送信され、第三者がＴＵＩＤを取得しにくくなるので、多要素認証におけるセキュリティが高まる。悪意のある第三者がソルト要求を盗んだとしても、ＴＵＩＤの下２桁だけでは、変換の仕組みを把握するのが難しいので、多要素認証におけるセキュリティがより高まる。

【0108】

［３．第３実施形態］
ソルトの取得方法は、第１実施形態及び第２実施形態の例に限られない。第３実施形態では、ソルトを取得するために、日又は時間帯といった時間的な条件が利用されない場合を説明する。第３実施形態では、ソルトサーバ１０がソルトのペアを生成し、当該生成されたペアを利用して、ＴＵＩＤの変換及び逆変換が実行される。ソルトサーバ１０は、３つ以上のソルトのセットを生成してもよい。

【0109】

図９は、第３実施形態における多要素認証の流れの一例を示す図である。図９のように、大まかな流れは、第１実施形態及び第２実施形態と同様であるが、ソルトの取得方法が第１実施形態とは異なる。例えば、ユーザＰＣ３０は、第１実施形態と同様にして、ソルトサーバ１０に対し、ソルト要求を送信する。ソルトサーバ１０は、ソルト要求を受信すると、ソルトのペア「６４３７」「８４１４」を生成してソルトデータベースＤＢ１に格納する。

【0110】

第３実施形態では、ソルトサーバ１０は、ソルトデータベースＤＢ１に予めソルトを格納するのではなく、ソルト要求を受信したその場で動的にソルトのペアを生成する場合を説明する。ソルトのペアは、その場で動的に生成されるのではなく、ソルトデータベースＤＢ１に多数のソルトを予め格納しておき、ソルトサーバ１０が、ソルトデータベースＤＢ１の中からソルトのペアを取得してもよい。ソルトのペアは、一定時間で自動的に削除されてもよい。

【0111】

図９の例では、ソルトサーバ１０は、ソルトのペア「６４３７」「８４１４」を、ユーザＰＣ３０に送信する。ユーザＰＣ３０は、ソルトサーバ１０からソルトのペア「６４３５」「８４１４」を受信すると、２つ目のソルト「８４１４」に基づいて、ＴＵＩＤ「３１２４５６」を変換する。図９の例では、ＴＵＩＤ「３１２４５６」に２つ目のソルト「８４１４」が加算され、変換後のＴＵＩＤは、「３２０８７０」になる。ユーザＰＣ３０は、撮影部３６が生成したユーザの顔写真、１つ目のソルト「６４３７」、及び変換後のＴＵＩＤ「３２０８７０」を含む認証要求を、認証サーバ２０に送信する。

【0112】

認証サーバ２０は、認証要求を受信すると、ソルトサーバ１０に対し、１つ目のソルト「６４３７」を含むソルト要求を送信する。このソルト要求は、ユーザＰＣ３０が送信するソルト要求とは異なる。このソルト要求は、ユーザＰＣ３０に送信されたソルトのペアを削除する旨のコマンドが含まれる。ソルトサーバ１０は、ソルト要求を受信すると、ソルトデータベースＤＢ１を参照し、ソルト要求に含まれる１つ目のソルト「６４３７」に関連付けられた２つ目のソルト「８４１４」を取得し、認証サーバ２０に送信する。ソルトサーバ１０は、ソルトデータベースＤＢ１からソルトのペア「６４３７」「８４１４」を削除する。１つ目のソルト「６４３７」は、２つ目のソルト「８４１４」を検索するためのクエリ及びインデックスとして利用される。

【0113】

認証サーバ２０は、ソルトサーバ１０から２つ目のソルト「８４１４」を受信すると、このソルト「８４１４」に基づいて、ユーザＰＣから受信した変換後のＴＵＩＤ「３２０８７０」を逆変換する。図９の例では、ＴＵＩＤ「３２０８７０」からソルト「８４１４」を減算する変換関数ｆ^－１が利用される。認証サーバ２０は、逆変換により、ＴＵＩＤ「３１２４５６」を取得する。以降の多要素認証の流れは、第１実施形態と同様である。

【0114】

図１０は、第３実施形態の認証システムＳで実現される機能ブロックの一例を示す図である。図１０のように、第３実施形態では、関連付け部１０４及び識別情報取得部３０６が実現される。関連付け部１０４は、制御部１１を主として実現される。識別情報取得部３０６は、制御部３１を主として実現される。

【0115】

関連付け部１０４は、１つ目のソルトと、２つ目のソルトと、を関連付ける。ここでの関連付けるとは、一方から他方を検索可能にすることである。例えば、ソルトデータベースＤＢ１で同じレコードに格納することは、関連付けることに相当する。１つ目のソルトは、所定の識別情報の一例である。２つ目のソルトは、変換情報及び逆変換情報の一例である。このため、１つ目のソルトについて説明している箇所は、識別情報と読み替えることができる。２つ目のソルトについて説明している箇所は、変換情報又は逆変換情報と読み替えることができる。

【0116】

識別情報は、変換情報及び逆変換情報の少なくとも一方を識別可能な情報である。識別情報は、任意の情報であってよく、１つ目のソルトに限られない。例えば、識別情報は、２つ目のソルトを生成するたびに増加又は減少する番号であってもよいし、ソルトとは異なる方法で生成したＩＤであってもよい。例えば、識別情報は、ユーザＰＣ３０のＩＰアドレス又はＭＡＣアドレスであってもよい。例えば、２つ目のソルトが識別情報に相当し、１つ目のソルトが変換情報及び逆変換情報に相当してもよい。変換情報及び逆変換情報が別々のソルトであり、識別情報は、これら別々のソルトに関連付けられた更に別のソルトであってもよい。この場合、計３つのソルトが取得される。

【0117】

例えば、関連付け部１０４は、ユーザＰＣ３０からソルト要求が受け付けられた場合に、１つ目のソルト及び２つ目のソルトを生成して互いに関連付ける。ソルトの生成方法自体は、第１実施形態及び第２実施形態と同様であってよい。関連付け部１０４は、ソルト生成部１０１の処理として実行されてもよい。関連付け部１０４は、ソルトのペアを生成し、このペアのうちの一方を１つ目のソルトとし、他方を２つ目のソルトとして、ソルトデータベースＤＢ１に格納する。第３実施形態では、ソルト要求が生成要求の一例である。このため、ソルト要求について説明している箇所は、生成要求と読み替えることができる。生成要求は、ソルトを生成するための要求であればよく、ソルト要求に限られない。生成要求は、ソルト要求とは別の要求であってもよい。

【0118】

識別情報取得部３０６は、１つ目のソルトを取得する。例えば、ソルト要求に応じて１つ目のソルトが生成される場合、識別情報取得部３０６は、ソルト要求に応じて生成された１つ目のソルトを取得する。ソルト取得部３０２は、ソルト要求に応じて生成された２つ目のソルトを取得する。情報送信部３０４は、認証サーバ２０に対し、１つ目のソルトを更に送信する。情報受信部２０１は、ユーザＰＣ３０から、１つ目のソルトを更に受信する。ソルト取得部３０２は、１つ目のソルトに関連付けられた２つ目のソルトを取得する。これらの流れは、図９で説明した通りである。

【0119】

第３実施形態の認証システムＳによれば、１つ目のソルトと、２つ目のソルトと、を関連付けておき、２つ目のソルトでＴＵＩＤを変換する。１つ目のソルトは、変換後のＴＵＩＤとともに認証サーバ２０に送信される。認証サーバ２０は、１つ目のソルトに関連付けられた２つ目のソルトを取得し、変換後のＴＵＩＤを逆変換する。これにより、変換後のＴＵＩＤがネットワーク上に送信され、第三者がＴＵＩＤを取得しにくくなるので、多要素認証におけるセキュリティが高まる。悪意のある第三者がソルト要求を盗んだとしても、１つ目のソルトでは、変換の仕組みを把握するのが難しいので、多要素認証におけるセキュリティがより高まる。

【0120】

また、認証システムＳは、ユーザＰＣ３０からソルト要求が受け付けられた場合に、１つ目のソルト及び２つ目のソルトを生成して互いに関連付ける。これにより、ソルト要求が受け付けられるたびに動的にソルトを生成できるので、同じソルトを一定期間使いまわすことがなくなり、多要素認証におけるセキュリティがより高まる。更に、ソルトサーバ１０がソルトのペアをすぐに削除するようにすれば、第三者がソルトのペアを入手しにくくなるので、セキュリティがより高まる。

【0121】

［４．第４実施形態］
第１実施形態～第３実施形態では、ソルトの取得方法を工夫することによって、多要素認証におけるセキュリティを高める場合について説明した。多要素認証におけるセキュリティを高める方法は、第１実施形態～第３実施形態の例に限られない。第４実施形態では、ユーザＰＣは、ＴＵＩＤを変換する時間帯に応じて変換関数ｆを使い分けることによって、多要素認証におけるセキュリティを高めるようにしている。ユーザＰＣ３０は、複数の変換関数ｆを予め記憶しており、何れかの変換関数ｆでＴＵＩＤを変換可能する。

【0122】

図１１は、第４実施形態における多要素認証の流れの一例を示す図である。第４実施形態では、大まかな流れは、第１実施形態～第３実施形態と同様であってよい。図１１の例では、第１実施形態と同様のソルトの取得方法を例に挙げる。ユーザＰＣ３０がソルトを取得するまでの流れは、第１実施形態と同様である。ユーザＰＣ３０は、ソルトサーバ１０から、現在の日「２日」及び時間帯「０１時」に応じたソルト「８４１４」を取得する。

【0123】

第４実施形態では、ユーザＰＣ３０は、ＴＵＩＤを変換する時間帯に基づいて、変換関数ｆを使い分ける。例えば、ユーザＰＣ３０は、時間帯「００時」～「２３時」にそれぞれ対応する変換関数ｆ０～ｆ２３を記憶する。以降、変換関数ｆ０～ｆ２３を区別しない時は、単に変換関数ｆと記載する。個々の変換関数ｆが示す計算方法は、互いに異なるものとする。このため、同じソルトだったとしても変換関数ｆが異なれば、変換後のＴＵＩＤの値も異なる。

【0124】

図１１の例では、ユーザＰＣ３０は、ＴＵＩＤを変換する時間帯が「０１時」なので、変換関数ｆ０～ｆ２３のうち、変換関数ｆ１を選択する。変換関数ｆ１は、第１実施形態の図２で説明した変換関数ｆと同様であるものとする。このため、ユーザＰＣ３０は、第１実施形態と同様にしてＴＵＩＤを変換し、認証サーバ２０に対し、変換済みのＴＵＩＤを送信する。認証サーバ２０は、変換済みのＴＵＩＤを受信すると、第１実施形態と同様にして、ソルトサーバ１０からソルトを取得する。

【0125】

第４実施形態では、認証サーバ２０は、ＴＵＩＤを変換する時間帯に基づいて、逆変換関数ｆ^－１を使い分ける。例えば、認証サーバ２０は、時間帯「００時」～「２３時」にそれぞれ対応する逆変換関数ｆ^－１０～ｆ^－１２３を記憶する。以降、逆変換関数ｆ^－１０～ｆ^－１２３を区別しない時は、単に逆変換関数ｆ^－１と記載する。個々の逆変換関数ｆ^－１が示す計算方法は、互いに異なる。このため、同じソルトだったとしても逆変換関数ｆ^－１が異なれば、逆変換後のＴＵＩＤの値も異なる。

【0126】

個々の逆変換関数ｆ^－１が示す計算方法は、時間帯を同じとする変換関数ｆに対応したものになる。正確なＴＵＩＤを取得するためには、ユーザＰＣ３０が利用した変換関数ｆに対応した逆変換関数ｆ^－１で逆変換をする必要がある。図１１の例では、ＴＵＩＤを逆変換する時間帯が「０１時」なので、逆変換関数ｆ^－１０～ｆ^－１２３のうち、逆変換関数^－１ｆ１を選択する。逆変換関数ｆ^－１１は、ユーザＰＣ３０が利用した変換関数ｆ１に対応する。このため、認証サーバ２０は、第１実施形態と同様にしてＴＵＩＤを変換し、正確なＴＵＩＤを取得できる。以降の多要素認証の流れは、第１実施形態と同様である。

【0127】

図１２は、第４実施形態の認証システムＳで実現される機能ブロックの一例を示す図である。図１２のように、第４実施形態では、逆変換関数選択部２０８及び変換関数選択部３０７が実現される。逆変換関数選択部２０８は、制御部２１を主として実現される。変換関数選択部３０７は、制御部３１を主として実現される。

【0128】

変換関数選択部３０７は、複数の変換関数ｆのうちの何れかを選択する。変換関数ｆは、変換方法の一例である。このため、変換関数ｆについて説明している箇所は、変換方法と読み替えることができる。変換方法は、ＴＵＩＤを変換する方法である。変換方法は、ＴＵＩＤをどのように変換するかを定義したものであればよく、変換関数ｆに限られない。例えば、変換方法は、関数とは呼ばれない計算式、又は、暗号化アルゴリズムであってもよい。

【0129】

変換関数選択部３０７は、所定の選択方法に基づいて、複数の変換関数ｆのうちの何れかを選択すればよい。第４実施形態では、選択方法の一例として時間帯を利用する場合を説明する。変換関数選択部３０７は、時間帯に応じた変換関数ｆを選択する。時間帯及び変換関数ｆの関係は、予めデータ記憶部３００に定義されているものとする。変換関数選択部３０７は、現在の時間帯に対応する変換関数ｆを選択する。第４実施形態では、時間帯が示す数値「００」～「２３」と、変換関数「ｆ０」～「ｆ２３」に含まれる数値と、が互いに対応している。

【0130】

時間帯は、第１変換期間の一例である。このため、時間帯について説明している箇所は、第１変換期間と読み替えることができる。第１変換期間は、ＴＵＩＤが変換される第１変換時点が属する期間である。第１実施形態では、第１変換期間が時間帯で示される場合を説明するが、第１変換期間は、日及び時間帯の組み合わせで示されてもよいし、日だけで示されてもよい。第１変換期間が他の意味だったとしても、変換関数選択部３０７は、ＴＵＩＤが変換される第１変換時点が属する第１変換期間に応じた変換関数ｆを選択する。個々の期間と、変換関数ｆと、の関係は、予めデータ記憶部３００に定義されているものとする。第１変換期間は、第１取得期間と同様に、１時間単位に限られず、任意の長さであってよい。

【0131】

変換部３０３は、ソルトに基づいて、変換関数選択部３０７により選択された変換関数ｆでＴＵＩＤを変換する。変換関数選択部３０７により選択された変換関数ｆが利用される点で、第１実施形態～第３実施形態とは異なるが、他の点については同様である。

【0132】

逆変換関数選択部２０８は、複数の逆変換関数ｆ^－１の中から、変換関数選択部３０７により選択された変換関数ｆに対応する逆変換関数ｆ^－１を選択する。逆変換関数ｆ^－１は、逆変換方法の一例である。このため、逆変換関数ｆ^－１について説明している箇所は、逆変換方法と読み替えることができる。逆変換方法は、変換後のＴＵＩＤを逆変換する方法である。逆変換方法は、変換後のＴＵＩＤをどのように逆変換するかを定義したものであればよく、逆変換関数ｆ^－１に限られない。例えば、逆変換方法は、関数とは呼ばれない計算式、又は、復号化アルゴリズムであってもよい。

【0133】

逆変換関数選択部２０８は、所定の選択方法に基づいて、複数の逆変換関数ｆ^－１のうちの何れかを選択すればよい。第４実施形態では、選択方法の一例として時間帯を利用する場合を説明する。逆変換関数選択部２０８は、時間帯に応じた逆変換関数ｆ^－１を選択する。時間帯及び逆変換関数ｆ^－１の関係は、予めデータ記憶部２００に定義されているものとする。逆変換関数選択部２０８は、現在の時間帯に対応する逆変換関数ｆ^－１を選択する。例えば、逆変換関数選択部２０８は、変換関数選択部３０７により選択された変換関数ｆに対応する逆変換関数ｆ^－１として、第１変換期間に応じた逆変換関数ｆ^－１を選択する。

【0134】

逆変換部２０４は、ソルトに基づいて、逆変換関数選択部２０８により選択された逆変換関数ｆ^－１で変換後のＴＵＩＤを逆変換する。逆変換関数選択部２０８により選択された逆変換関数ｆ^－１が利用される点で、第１実施形態～第３実施形態とは異なるが、他の点については同様である。

【0135】

第４実施形態の認証システムＳによれば、ソルトに基づいて、複数の変換関数ｆの中から選択された変換関数ｆでＴＵＩＤを変換する。認証システムＳは、ソルトに基づいて、複数の逆変換関数ｆ^－１の中から選択された逆変換関数ｆ^－１で変換後のＴＵＩＤを逆変換する。これにより、変換後のＴＵＩＤがネットワーク上に送信され、第三者がＴＵＩＤを取得しにくくなるので、多要素認証におけるセキュリティが高まる。また、変換関数ｆが動的に変わるので、第三者が変換の仕組みを把握しにくくなり、多要素認証におけるセキュリティがより高まる。

【0136】

また、認証システムＳは、ＴＵＩＤが変換される第１変換時点が属する第１変換期間に応じた変換関数ｆに対応する逆変換関数ｆ^－１として、第１変換期間に応じた逆変換関数ｆ^－１を選択する。これにより、変換関数ｆが期間に応じて変わるので、同じ変換関数ｆを使いまわす頻度が下がり、第三者が変換の仕組みを把握しにくくなる。

【0137】

また、認証システムＳは、第１変換期間は、時間帯で示され、変換関数選択部３０７は、時間帯に応じた変換関数ｆを選択し、逆変換関数選択部２０８は、時間帯に応じた逆変換関数ｆ^－１を選択する。これにより、変換関数ｆがより短い期間に応じて変わるので、同じ変換関数ｆを使いまわす頻度が更に下がり、第三者が変換の仕組みを把握しにくくなる。

【0138】

［５．第５実施形態］
変換関数ｆ及び逆変換関数ｆ^－１は、他の任意の選択方法によって選択可能であり、第４実施形態の例に限られない。第５実施形態では、時間帯といった時間的な条件ではなく、ソルトサーバ１０が生成したソルトのペアを利用する場合を例に挙げる。第５実施形態におけるソルトのペアの生成方法は、第３実施形態と同様であるものとする。第５実施形態では、ソルトサーバ１０がソルトのペアを生成し、当該生成されたペアを利用して、変換関数ｆ及び逆変換関数ｆ^－１が選択される。

【0139】

図１３は、第５実施形態における多要素認証の流れの一例を示す図である。図１３のように、大まかな流れは、第３実施形態と同様であるが、複数の変換関数ｆ０～ｆ９と、複数の逆変換関数ｆ^－１と、が用意されている点で第３実施形態とは異なる。例えば、ユーザＰＣ３０は、第３実施形態と同様にして、ソルトサーバ１０からソルトのペア「６４３７」「８４１４」を取得する。

【0140】

ユーザＰＣ３０は、１つ目のソルトの下１桁に基づいて、変換関数ｆを使い分ける。例えば、ユーザＰＣ３０は、下１桁「０」～「９」にそれぞれ対応する変換関数ｆ１～ｆ９を記憶する。図１３の例では、１つ目のソルト「６４３７」の下１桁「７」に対応する変換関数ｆ７が選択される。この変換関数ｆ７は、第３実施形態の図９で説明した変換関数ｆと同様であるものとする。変換関数ｆ７が選択された後のユーザＰＣ３０の処理は、第３実施形態と同様である。認証サーバ２０は、変換済みのＴＵＩＤを受信すると、第３実施形態と同様にして、ソルトサーバ１０からソルトのペア「６４３７」「８４１４」を取得する。

【0141】

第５実施形態では、認証サーバ２０は、１つ目のソルトの下１桁に基づいて、逆変換関数ｆ^－１を使い分ける。例えば、ユーザＰＣ３０は、下１桁「０」～「９」にそれぞれ対応する逆変換関数ｆ^－１１～ｆ^－１９を記憶する。図１３の例では、１つ目のソルト「６４３７」の下１桁「７」に対応する逆変換関数ｆ^－１７が選択される。この逆変換関数ｆ^－１７は、第３実施形態の図９で説明した逆変換関数ｆ^－１と同様であるものとする。逆変換関数ｆ^－１７が選択された後の認証サーバ２０の処理を含む多要素認証の流れは、第３実施形態と同様である。

【0142】

第５実施形態の認証システムＳは、第３実施形態と同様の関連付け部１０４及び識別情報取得部３０６を含む。情報受信部２０１、ソルト取得部２０３，３０２、及び情報送信部３０４の処理も、概ね第３実施形態で説明した通りである。第５実施形態の逆変換関数選択部２０８は、１つ目のソルトに基づいて、逆変換関数ｆ^－１を選択する。１つ目のソルトと、逆変換関数ｆ^－１と、の関係は、予めデータ記憶部２００に定義されているものとする。逆変換関数選択部２０８は、１つ目のソルトに対応する逆変換関数ｆ^－１を選択する。第５実施形態では、１つ目のソルトの下１桁が利用される場合を説明するが、逆変換関数選択部２０８は、１つ目のソルトの他の部分に基づいて、逆変換関数ｆ^－１を選択してもよい。

【0143】

第５実施形態の認証システムＳによれば、１つ目のソルトと、２つ目のソルトと、を関連付けておき、２つ目のソルトでＴＵＩＤを変換する。１つ目のソルトは、変換後のＴＵＩＤとともに認証サーバ２０に送信される。認証サーバ２０は、１つ目のソルトに関連付けられた２つ目のソルトを取得し、１つ目のソルトに基づいて選択した逆変換関数ｆ^－１に基づいて、変換後のＴＵＩＤを逆変換する。これにより、変換関数ｆが動的に変わるので、第三者が変換の仕組みを把握しにくくなり、多要素認証におけるセキュリティがより高まる。悪意のある第三者がソルト要求を盗んだとしても、１つ目のソルトでは、変換の仕組みを把握するのが難しいので、多要素認証におけるセキュリティがより高まる。

【0144】

【0145】

［６．第６実施形態］
第４実施形態及び第５実施形態では、認証サーバ２０及びユーザＰＣ３０がそれぞれ逆変換関数ｆ^－１及び変換関数ｆを選択する場合を説明したが、逆変換関数ｆ^－１及び変換関数ｆは、第三者サーバにより選択されてもよい。

【0146】

図１４は、第６実施形態における認証システムＳの全体構成の一例を示す図である。図１４のように、第６実施形態の認証システムＳは、選択サーバ４０を含む。選択サーバ４０は、サーバコンピュータである。制御部４１、記憶部４２、及び通信部４３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。選択サーバ４０は、選択装置の一例である。このため、選択サーバ４０と記載した箇所は、選択装置と読み替えることができる。

【0147】

選択装置は、変換関数ｆ及び逆変換関数ｆ^－１を選択する装置である。選択装置は、任意の装置であってよく、選択サーバ４０のようなサーバコンピュータに限られない。例えば、選択装置は、パーソナルコンピュータ、タブレット端末、又はスマートフォンであってもよい。他にも例えば、選択装置は、ゲーム機、自動販売機、ＰＯＳ端末、又はＡＴＭといった他の装置であってもよい。

【0148】

図１５は、第６実施形態における多要素認証の流れの一例を示す図である。第６実施形態では、大まかな流れは、第４実施形態又は第５実施形態と同様であってよい。図１５の例では、第５実施形態と同様の選択方法を例に挙げる。ユーザＰＣ３０がソルトのペアを取得するまでの流れは、第５実施形態と同様である。図１５では、１つ目のソルトを「６４３０」とする。

【0149】

第６実施形態では、ユーザＰＣ３０は、選択サーバ４０に対し、１つ目のソルト「６４３０」を送信する。選択サーバ４０は、関数データベースＤＢ３を記憶する。関数データベースＤＢ３には、１つ目のソルトの下１桁、変換関数ｆ、及び逆変換関数ｆ^－１が関連付けられている。図１５の例では、ｆの後の数値が同じ逆変換関数ｆ^－１が対応しているので、関数データベースＤＢ３に変換関数ｆのみを示しているが、関数データベースには、
変換関数ｆ及び逆変換関数ｆ^－１の両方が格納されていてもよい。関数データベースＤＢ３における関連付けは、所定のタイミングで更新されるものとする。例えば、選択サーバ４０は、定期的に、関数データベースＤＢ３における関連付けをランダムに更新する。

【0150】

選択サーバ４０は、ユーザＰＣ３０から受信した１つ目のソルトの下１桁「０」に基づいて、変換関数ｆを選択する。変換関数ｆを選択する主体が選択サーバ４０になるが、変換関数ｆの選択自体は、第４実施形態及び第５実施形態と同様であってよい。選択サーバ４０は、ユーザＰＣ３０に対し、変換関数ｆの選択結果「ｆ７」を送信する。ユーザＰＣ３０は、変換関数ｆの選択結果「ｆ７」を受信すると、ＴＵＩＤを変換する。この変換自体は、第４実施形態及び第５実施形態と同様であってよい。以降の流れは、認証サーバ２０がソルトサーバ１０からソルトのペアを取得するまでは、第５実施形態と同様である。

【0151】

認証サーバ２０は、選択サーバ４０に対し、１つ目のソルト「６４３０」を送信する。選択サーバ４０は、認証サーバ２０から受信した１つ目のソルトの下１桁に基づいて、逆変換関数ｆ^－１７を選択する。逆変換関数ｆ^－１７を選択する主体が選択サーバ４０になるが、逆変換関数ｆ^－１の選択自体は、第４実施形態及び第５実施形態と同様であってよい。選択サーバ４０は、認証サーバ２０に対し、逆変換関数ｆ^－１の選択結果「ｆ^－１７」を送信する。認証サーバ２０は、逆変換関数ｆ^－１の選択結果を受信すると、変換済みのＴＵＩＤを逆変換する。この逆変換自体は、第４実施形態及び第５実施形態と同様であってよい。以降の多要素認証の流れは、第４実施形態及び第５実施形態と同様である。

【0152】

図１６は、第６実施形態の認証システムＳで実現される機能ブロックの一例を示す図である。図１６のように、第６実施形態では、変換関数要求部３０８、逆変換関数要求部２０９、データ記憶部４００、第１送信部４０１、及び第２送信部４０２が実現される。逆変換関数要求部２０９は、制御部２１を主として実現される。変換関数要求部３０８は、制御部３１を主として実現される。データ記憶部４００は、記憶部４２を主として実現される。第１送信部４０１及び第２送信部４０２は、制御部４１を主として実現される。

【0153】

変換関数要求部３０８は、選択サーバ４０に対し、変換関数ｆの選択を要求する。以降、この要求を変換関数選択要求という。変換関数選択要求は、所定の形式により行われるようにすればよい。変換関数選択要求は、選択サーバ４０が変換関数ｆを選択するための基準となる情報を含んでもよいし、変換関数ｆを選択する旨のコマンドのみを含んでもよい。第６実施形態では、変換関数選択要求は、１つ目のソルトを含む場合を説明する。

【0154】

逆変換関数要求部２０９は、選択サーバ４０に対し、逆変換関数ｆ^－１の選択を要求する。以降、この要求を逆変換関数選択要求という。逆変換関数選択要求は、所定の形式により行われるようにすればよい。逆変換関数選択要求は、選択サーバ４０が逆変換関数ｆ^－１を選択するための基準となる情報を含んでもよいし、逆変換関数ｆ^－１を選択する旨のコマンドのみを含んでもよい。第６実施形態では、逆変換関数選択要求は、１つ目のソルトを含む場合を説明する。

【0155】

第１送信部４０１は、ユーザＰＣ３０からの変換関数選択要求が受け付けられた場合に、ユーザＰＣ３０に対し、複数の変換関数ｆのうちの何れかの選択結果を送信する。選択サーバ４０は、変換関数選択要求が受け付けられた場合に、所定の選択方法に基づいて、複数の変換関数ｆのうちの何れかを選択する。第６実施形態では、第５実施形態と同様に、この選択方法が１つ目のソルトの下１桁の値である場合を説明するが、選択方法は、他の任意の方法であってよい。例えば、１つ目のソルトの上１桁の値であってもよいし、２つ目のソルトの値であってもよい。他にも例えば、第４実施形態と同様に、変換関数選択要求が受け付けられた時間帯であってもよい。第１送信部４０１は、選択サーバ４０が選択した変換関数ｆを識別可能な情報を、選択結果として送信する。

【0156】

第２送信部４０２は、認証サーバ２０からの逆変換関数選択要求が受け付けられた場合に、認証サーバ２０に対し、複数の逆変換関数ｆ^－１のうちの何れかの選択結果を送信する。選択サーバ４０は、逆変換関数選択要求が受け付けられた場合に、所定の選択方法に基づいて、複数の逆変換関数ｆ^－１のうちの何れかを選択する。第６実施形態では、第５実施形態と同様に、この選択方法が１つ目のソルトの下１桁の値である場合を説明するが、選択方法は、他の任意の方法であってよい。例えば、１つ目のソルトの上１桁の値であってもよいし、２つ目のソルトの値であってもよい。他にも例えば、第４実施形態と同様に、逆変換関数選択要求が受け付けられた時間帯であってもよい。第２送信部４０２は、選択サーバ４０が選択した逆変換関数ｆ^－１を識別可能な情報を、選択結果として送信する。

【0157】

変換関数選択部３０７は、選択サーバ４０による選択結果に基づいて、変換関数ｆを選択する。選択サーバ４０により選択された変換関数ｆが利用される点で、第４実施形態及び第５実施形態とは異なるが、他の点については同様である。

【0158】

逆変換関数選択部２０８は、選択サーバ４０による選択結果に基づいて、逆変換関数ｆ^－１を選択する。選択サーバ４０により選択された逆変換関数ｆ^－１が利用される点で、第４実施形態及び第５実施形態とは異なるが、他の点については同様である。

【0159】

第６実施形態の認証システムＳによれば、選択サーバ４０が、認証サーバ２０及びユーザＰＣ３０からの要求に基づいて、逆変換関数ｆ^－１及び変換関数ｆを選択する。これにより、逆変換関数ｆ^－１及び変換関数ｆを選択するアルゴリズムを認証サーバ２０及びユーザＰＣ３０で持つ必要がなくなるので、多要素認証の仕組みを簡略化できる。更に、関数データベースＤＢ３に定義された逆変換関数ｆ^－１及び変換関数ｆを定期的に変更しやすくなるので、第三者が変換の仕組みを推測しにくくなり、セキュリティが高まる。

【0160】

［７．変形例］
なお、本開示は、以上に説明した第１実施形態～第６実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

【0161】

［７－１．変形例１］
例えば、第１実施形態の図２の例において、ユーザＰＣ３０からのソルト要求が受け付けられた時点が「２０２１年１２月２日０１：５９：５９」であり、認証サーバ２０からのソルト要求が受け付けられた時点が「２０２１年１２月２日０２：００：００」だったとする。この場合、ユーザＰＣ３０が取得するソルトは「８４１４」になり、認証サーバ２０が取得するソルトは「９４３６」になる。この場合、ＴＵＩＤの変換で利用されるソルトと、変換後のＴＵＩＤの逆変換で利用されるソルトと、が異なるので、認証サーバ２０は、正確なＴＵＩＤを取得できない。そこで、変形例１では、ユーザＰＣ３０から認証サーバ２０に対し、ＴＵＩＤの変換で利用したソルトがどの時間帯のものなのかを識別可能な情報が送信される場合を説明する。

【0162】

図１７は、変形例１における多要素認証の流れの一例を示す図である。変形例１では、ソルトサーバ１０がユーザＰＣ３０からソルト要求を受信するまでの流れは、第１実施形態と同様である。ソルトサーバ１０は、ユーザＰＣ３０からソルト要求を受信すると、現時点が属する日及び時間帯に応じた１つ目のソルトと、次の時間帯に応じた２つ目のソルトと、をユーザＰＣ３０に送信する。

【0163】

図１７の例では、ユーザＰＣ３０からのソルト要求が受け付けられた時点を、「２０２１年１２月２日０１：５９：５９」とする。ソルトサーバ１０は、「２日」及び「０１時」に応じた１つ目のソルト「８４１４」と、次の時間帯である「２日」及び「０２時」に応じた２つ目のソルト「９４３６」と、のペアを、ユーザＰＣ３０に送信する。ユーザＰＣ３０は、ソルトサーバ１０から、ソルトのペア「８４１４」「９４３６」を受信する。

【0164】

ユーザＰＣ３０は、ソルトのペア「８４１４」「９４３６」のうちの何れかを選択する。ユーザＰＣ３０は、所定の選択方法に基づいて、ソルトを選択すればよい。変形例１では、１つ目のソルトを選択することが決められている場合を例に挙げるが、他の選択方法に基づいてソルトが選択されてもよい。例えば、ユーザＰＣ３０は、ソルト要求を送信した時点、ソルトのペアを受信した時点、又はソルトを選択する時点に基づいて、ソルトを選択してもよい。

【0165】

図１７の例では、ユーザＰＣ３０は、１つ目のソルト「８４１４」に基づいて、ＴＵＩＤ「３１２４５６」を変換する。変換後のＴＵＩＤは、「３２０８７０」になる。ユーザＰＣ３０は、認証サーバ２０に対し、変換後のＴＵＩＤ「３２０８７０」と、１つ目のソルト「８４１４」に対応する時間帯を識別可能なタイムスタンプ「５９：５９」と、を送信する。このタイムスタンプは、現在の時点「２０２１年１２月２日０１：５９：５９」であってもよいが、第三者に入手される情報を少なくするために、「５９：５９」のみが送信されるものとする。タイムスタンプは、ソルト要求を送信した時点、ソルトを受信した時点、ＴＵＩＤを変換した時点、又は変換後のＴＵＩＤが送信される時点の何れが利用されてもよい。

【0166】

認証サーバ２０は、変換後のＴＵＩＤ「３２０８７０」と、タイムスタンプ「５９：５９」と、を受信すると、ソルトサーバ１０に対し、ソルト要求を送信する。ソルトサーバ１０は、認証サーバ２０からソルト要求を受信すると、現時点が属する日及び時間帯に応じたソルトと、次又は前の時間帯に応じたソルトと、のペアを、認証サーバ２０に送信する。

【0167】

図１７の例では、認証サーバ２０からのソルト要求が受け付けられた時点を、「２０２１年１２月２日０１：５９：５９」とする。この場合、ソルトサーバ１０は、「２日」及び「０１時」に応じた１つ目のソルト「８４１４」と、次の時間帯である「２日」及び「０２時」に応じた２つ目のソルト「９４３６」と、のペアを、認証サーバ２０に送信する。認証サーバ２０は、ソルトサーバ１０から、ソルトのペア「８４１４」「９４３６」を受信する。

【0168】

一方、認証サーバ２０からのソルト要求が受け付けられた時点が「２０２１年１２月２日０２：００：００」だったとする。この場合、ソルトサーバ１０は、前の時間帯である「２日」及び「０１時」に応じた１つ目のソルト「８４１４」と、現時点が属する時間帯である「２日」及び「０２時」に応じた２つ目のソルト「９４３６」と、のペアを、認証サーバ２０に送信する。認証サーバ２０は、ソルトサーバ１０から、ソルトのペア「８４１４」「９４３６」を受信する。このように、ソルトサーバ１０は、時間帯の区切りの直前であるか直後であるかに応じて、１つ前の時間帯のソルトを送信するか、１つ後の時間帯のソルトを送信するか、を制御してもよい。

【0169】

認証サーバ２０は、ユーザＰＣ３０から受信したタイムスタンプ「５９：５９」により、時間帯が相対的に前のソルトが変換で利用されたことを特定できる。即ち、認証サーバ２０から受信したソルトのペアのうち、１つ目のソルトが利用されたことを特定できる。認証サーバ２０は、１つ目のソルト「８４１４」に基づいて、変換後のＴＵＩＤ「３２０８７０」の逆変換を実行する。以降の流れは、第１実施形態と同様である。

【0170】

一方、ユーザＰＣ３０から受信したタイムスタンプが「００：００」だったとする。この場合、ユーザＰＣ３０は、ソルト「８４１４」ではなく、ソルト「９４３６」を利用してＴＵＩＤ「３１２４５６」を変換している。この場合、認証サーバ２０は、このタイムスタンプに基づいて、時間帯が相対的に後のソルトが変換で利用されたことを特定できる。即ち、認証サーバ２０は、２つ目のソルト「９４３６」に基づいて、逆変換を実行する。

【0171】

なお、図１７の例において、ソルトサーバ１０がユーザＰＣ３０からのソルト要求を受け付けた時点が「２０２１年１２月１日２３：５９：５９」だったとする。ソルトサーバ１０は、「１日」及び「２３時」に応じた１つ目のソルト「８２０１」と、翌日の「２日」及び「００時」に応じた２つ目のソルト「６４３５」と、をユーザＰＣ３０に送信すればよい。

【0172】

情報送信部３０４は、認証サーバ２０に対し、第１取得期間に関する第１取得期間情報を更に送信する。第１実施形態で説明したように、第１取得期間は、ソルトが取得される第１取得時点が属する期間である。図１７の例では、「２日」の「０１時」が第１取得期間に相当する。第１取得期間情報は、どの期間のソルトを利用すべきかを識別可能な情報である。図１７の例では、タイムスタンプ「５９：５９」が第１取得期間情報に相当する。このため、タイムスタンプ「５９：５９」について説明している箇所は、第１取得期間情報と読み替えることができる。

【0173】

情報受信部２０１は、ユーザＰＣ３０から、第１取得期間情報を更に受信する。図１７の例では、情報受信部２０１は、ユーザＰＣ３０から、第１取得期間情報として、タイムスタンプ「５９：５９」を受信する。情報受信部２０１が第１取得期間情報を受信すると、ソルト要求部２０２は、ソルトサーバ１０に対し、ソルトを要求する。ソルト要求については、第１実施形態～第６実施形態で説明した通りである。

【0174】

ソルトサーバ１０は、認証サーバ２０からの要求を受け付けた場合に、認証サーバ２０に対し、ソルトが取得される第２取得時点が属する第２取得期間に応じたソルトと、第２取得期間の前又は後の第３期間に応じたソルトと、を含む複数のソルトを送信する。日及び時間帯の組み合わせは、第２取得期間の一例である。このため、日及び時間帯の組み合わせについて説明している箇所は、第２取得期間と読み替えることができる。第２取得期間は、ソルトが取得される第２取得時点が属する期間である。第２取得期間は、逆変換情報に相当するソルトが取得される期間という点で第１取得期間とは異なるが、他の点については、第１取得期間と同様である。

【0175】

例えば、ソルトサーバ１０は、第２取得時点が第２取得期間の終了間際であれば、第２取得期間に応じたソルトと、第２取得期間の後の期間である第３期間に応じたソルトと、を含む複数のソルトを送信する。終了間際とは、第２取得期間の終了時点から所定時間以内（例えば、数秒～１分以内）のことである。図１７の例であれば、第２取得期間は、「２日」の「０１時」である。この第２取得期間の終了時点は、「２日」の「０２：００：００」の直前の時点（例えば、「２日」の「０１：５９：５９」）である。図１７の例では、第２取得時点である「２０２１年１２月２日０１：５９：５９」がこの終了時点と同じ又は間際なので、ソルトサーバ１０は、第２取得期間である「２日」の「０１時」のソルト「８４１４」と、第２取得期間の次の期間である「２日」の「０２時」のソルト「９４３６」と、を送信する。

【0176】

例えば、ソルトサーバ１０は、第２取得時点が第２取得期間の開始直後であれば、第２取得期間に応じたソルトと、第２取得期間の後の期間である第３期間に応じたソルトと、を含む複数のソルトを送信する。開始直後とは、第２取得期間の開始時点から所定時間以内（例えば、数秒～１分以内）のことである。例えば、図１７の例において、第２取得時点が「２０２１年１２月２日０１：５９：５９」ではなく「２０２１年１２月２日０２：００：００」だったとする。この場合、第２取得期間は、「２日」の「０２時」である。この第２取得期間の開始時点は、「２日」の「０２：００：００」である。第２取得時点である「２０２１年１２月２日０２：００：００」がこの開始時点と同じ又は直後なので、ソルトサーバ１０は、第２取得期間の前の期間である「２日」の「０１時」のソルト「８４１４」と、第２取得期間である「２日」の「０２時」のソルト「９４３６」と、を送信する。

【0177】

ソルト取得部２０３は、第１取得期間情報に基づいて、第１取得期間に応じたソルトを取得する。ソルト取得部２０３は、第１取得期間情報に基づいて、ソルトサーバ１０から受信した複数のソルトの中から、第１取得期間に応じたソルトを取得する。図１７の例では、ソルト取得部２０３は、第１取得期間情報に基づいて、ソルトサーバ１０から受信したソルトのペアのうちの何れかを選択する。図１７の例であれば、ソルト取得部２０３は、タイムスタンプ「５９：５９」により、時間的に前のソルトを選択すればよいことを特定できる。このため、ソルト取得部２０３は、１つめのソルト「８４１４」を選択する。ソルト「８４１４」が選択された後の逆変換の処理は、第１実施形態～第６実施形態と同様である。

【0178】

一方、図１７の例において、タイムスタンプが「５９：５９」ではなく「００：００」だったとする。この場合、ソルト取得部２０３は、タイムスタンプ「００：００」により、時間的に後のソルトを選択すればよいことを特定できる。このため、ソルト取得部２０３は、２つめのソルト「９４３６」を選択する。ソルト「９４３６」が選択された後の逆変換の処理は、第１実施形態～第６実施形態と同様である。

【0179】

変形例１の認証システムＳによれば、ユーザＰＣ３０は、認証サーバ２０に対し、ＴＵＩＤの変換時点に対応するタイムスタンプを更に送信する。認証サーバ２０は、ユーザＰＣ３０から受信したタイムスタンプに基づいて、ソルトを取得する。これにより、ある時間帯の終了間際にソルトが取得されたとしても、多要素認証を正確に実行することができる。このため、多要素認証が失敗してやり直すといった手間を省くことができるので、ユーザの利便性が高まる。ソルトサーバ１０、認証サーバ２０、及びユーザＰＣ３０も不要な処理を実行しないので、これらの処理負荷を軽減できる。

【0180】

また、ソルトサーバ１０は、認証サーバ２０からの要求を受け付けた場合に、認証サーバ２０に対し、第２取得期間に応じたソルトと、第２取得期間の前又は後の第３期間に応じたソルトと、を含む複数のソルトを送信する。認証サーバ２０は、ユーザＰＣ３０から受信したタイムスタンプに基づいて、複数のソルトの中から、逆変換に適したソルトを取得する。これにより、逆変換を正確に実行することができるので、多要素認証が失敗してやり直すといった手間を省くことができる。

【0181】

［７－２．変形例２］
例えば、第４実施形態（図１１）のように変換関数ｆ及び逆変換関数ｆ^－１を選択した場合にも、変形例１と同様の課題が発生する可能性がある。例えば、ユーザＰＣ３０が変換を行う時点が「２０２１年１２月２日０１：５９：５９」であり、認証サーバ２０が逆変換を行う時点が「２０２１年１２月２日０２：００：００」だったとする。この場合、ＴＵＩＤの変換関数ｆと、変換後のＴＵＩＤの逆変換関数ｆ^－１と、が対応しないので、認証サーバ２０が正確なＴＵＩＤを取得できない可能性がある。

【0182】

そこで、変形例２では、変形例１と同様に、ユーザＰＣ３０が認証サーバ２０に対し、タイムスタンプ「５９：５９」を送信するものとする。このタイムスタンプにより、認証サーバ２０は、逆変換を行う時点が「２０２１年１２月２日０２：００：００」だったとしても、１つ前の時間帯に対応する逆変換関数ｆ^－１を利用すればよいことを特定できる。

【0183】

情報送信部３０４は、認証サーバ２０に対し、第１変換期間に関する変換期間情報を更に送信する。第４実施形態で説明したように、第１変換期間は、ソルトが変換される第１変換時点が属する期間である。上記の例では、「２日」の「０１時」が第１変換期間に相当する。変換期間情報は、どの期間の逆変換関数ｆ^－１を利用すべきかを識別可能な情報である。上記の例では、タイムスタンプ「５９：５９」が変換期間情報に相当する。このため、タイムスタンプ「５９：５９」について説明している箇所は、変換期間情報と読み替えることができる。情報受信部２０１は、ユーザＰＣ３０から、変換期間情報を更に受信する。

【0184】

逆変換関数選択部２０８は、変換期間情報に基づいて、第１変換期間に応じた逆変換関数ｆ^－１を選択する。逆変換関数ｆ^－１を選択する時点ではなく、変換期間情報に基づいて逆変換関数ｆ^－１が選択される点で第４実施形態とは異なるが、他の点は、第４実施形態と同様である。逆変換関数選択部２０８は、変換期間情報に基づいて、複数の逆変換関数ｆ^－１の中から、第１変換期間に応じた逆変換関数ｆ^－１を選択すればよい。

【0185】

なお、第４実施形態及び第６実施形態を組み合わせた構成に対し、変形例２を適用してもよい。この場合、選択サーバ４０は、認証サーバ２０からの要求を受け付けた場合に、認証サーバ２０に対し、逆変換関数ｆ^－１が選択される第２変換時点が属する第２変換期間に応じた逆変換関数ｆ^－１と、第２変換期間の前又は後の第３期間に応じた逆変換関数ｆ^－１と、を含む複数の逆変換関数ｆ^－１を送信する。

【0186】

変形例２の認証システムＳによれば、ユーザＰＣ３０は、認証サーバ２０に対し、第１変換期間に関する変換期間情報を送信する。認証サーバ２０は、ユーザＰＣ３０から受信した変換期間情報に基づいて、第１変換期間に応じた逆変換関数ｆ^－１を選択する。これにより、多要素認証におけるセキュリティが高まる。ある時間帯の終了間際にＴＵＩＤの変換が実行されたとしても、多要素認証を正確に実行することができる。このため、多要素認証が失敗してやり直すといった手間を省くことができるので、ユーザの利便性が高まる。ソルトサーバ１０、認証サーバ２０、及びユーザＰＣ３０も不要な処理を実行しないので、これらの処理負荷を軽減できる。

【0187】

［７－３．変形例３］
例えば、認証システムＳは、ランダムに生成されたソルトを取得するソルト取得部３０２、ソルトに基づいて、ユーザの生体情報とは異なり、かつ、ユーザを識別可能なユーザ識別情報を変換する変換部３０３と、変換部３０３により変換されたユーザ識別情報と、生体情報と、に基づいて、多要素認証を実行する多要素認証部２０５と、を含んでもよい。個々の処理の詳細は、第１実施形態～第６実施形態で説明した通りである。ＴＵＩＤは、ユーザ識別情報に相当する。ユーザ識別情報は、ユーザを何らか識別可能な情報であればよく、ＴＵＩＤに限られない。例えば、ユーザ識別情報は、ユーザＩＤ、メールアドレス、又は電話番号であってもよい。ユーザ識別情報は、認証情報の一例である。ユーザデータベースＤＢ２には、正解となるユーザ識別情報及び生体情報のペアが格納されているものとする。

【0188】

変形例３のソルト取得部３０２、変換部３０３、及び多要素認証部２０５は、１台のコンピュータにより実現されてもよい。これらが複数台のコンピュータで実現される場合には、ユーザＰＣ３０以外の第１のコンピュータによりソルト取得部３０２及び変換部３０３が実現され、認証サーバ２０以外の第２のコンピュータにより多要素認証部２０５が実現されてもよい。第１のコンピュータは、変換済みのユーザ識別情報と、生体情報と、を第２のコンピュータに送信する。第２のコンピュータは、第１のコンピュータから受信したこれらの情報に基づいて、多要素認証を実行すればよい。

【0189】

変形例３の認証システムＳによれば、第１実施形態～第６実施形態と同様の理由で、セキュリティが高まる。

【0190】

［７－４．その他変形例］
例えば、第１実施形態～第６実施形態を組み合わせてもよい。上記変形例を組み合わせてもよい。

【0191】

例えば、変形例１又は変形例２の処理は、ある時間帯の終了間際にのみ実行されるようにしてもよい。例えば、ソルトサーバ１０で実現されるものとして説明した機能は、認証サーバ２０又はユーザＰＣ３０で実現されてもよい。この場合、認証システムＳは、ソルトサーバ１０を含まなくてもよい。例えば、認証システムＳが複数のサーバコンピュータを含む場合には、複数のサーバコンピュータで機能が分担されてもよい。また例えば、データ記憶部１００，２００で記憶されるものとして説明したデータは、ソルトサーバ１０又は認証サーバ２０以外のコンピュータによって記憶されてもよい。

【図1】