JP7358659B1 - 通信システム、通信方法、及びプログラム - Google Patents

Abstract

通信システム（Ｓ）は、第１装置（１０）及び第２装置（２０）を含む。第１装置（１０）の変換部（３０３）は、元データに対し、元データが変換される第１時点が属する第１期間に応じた第１変換を行って、第１変換データを生成する。送信部（３０４）は、第２装置（２０）に対し、第１変換データを送信する。第２装置（２０）の受信部（２０１）は、第１装置（１０）から、第１変換データを受信する。逆変換部（２０４）は、第１変換データに対し、第１期間に応じた第１逆変換を行って、元データを取得する。

Description

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

従来、通信分野において、元データの内容が第三者に知られないように、元データを変換する技術が知られている。例えば、特許文献１には、ユーザが入力したユーザＩＤに基づいて、ユーザパラメータを生成し、当該生成されたユーザパラメータに基づいて、元データの一例である生体データを変換する技術が記載されている。例えば、特許文献２には、公開鍵暗号方式を利用して、元データの一例であるソルトを変換する技術が記載されている。例えば、特許文献３には、公開鍵暗号方式の一種であるチャレンジアンドレスポンスと呼ばれる技術が記載されている。

特許第４９６６７６５号公報 特許第６８６６８０３号公報 再公表２０２０－８５１４１号公報

しかしながら、特許文献１の技術では、ネットワーク上にユーザパラメータが送信されるので、悪意のある第三者がユーザパラメータを容易に取得できる。第三者が、ユーザの生体データを何らかの形で入手すると、不正に入手したユーザパラメータ及び生体データを利用したなりすましが可能になる。ユーザパラメータは、一度発行されると原則として変わらないユーザＩＤに基づいて生成されるので、第三者は、一度入手したユーザパラメータを利用して、長期間にわたってなりすましが可能になる。

特許文献２－３の公開鍵暗号方式は、第三者に公開される公開鍵と、第三者には公開されない秘密鍵と、のペアを利用した暗号方式である。しかしながら、秘密鍵は、原則として変わらない情報なので、第三者が何らかの形で秘密鍵を入手すると、第三者は、一度入手した秘密鍵を利用して、長期間にわたって不正が可能になる。特許文献１－３の技術では、長期間にわたる不正が可能になるので、通信におけるセキュリティを十分に高めることができなかった。

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

本開示の一態様に係る通信システムは、第１装置及び第２装置を含む通信システムであって、前記第１装置は、元データに対し、前記元データが変換される第１時点が属する第１期間に応じた第１変換を行って、第１変換データを生成する変換部と、前記第２装置に対し、前記第１変換データを送信する送信部と、を含み、前記第２装置は、前記第１装置から、前記第１変換データを受信する受信部と、前記第１変換データに対し、前記第１期間に応じた第１逆変換を行って、前記元データを取得する逆変換部と、を含む。

本開示によれば、通信におけるセキュリティが高まる。

通信システムの全体構成の一例を示す図である。 第１実施形態における多要素認証の流れの一例を示す図である。 第１実施形態の通信システムで実現される機能の一例を示す機能ブロック図である。 ソルトデータベースの一例を示す図である。 ユーザデータベースの一例を示す図である。 第１実施形態の通信システムで実行される処理の一例を示す図である。 第１実施形態の通信システムで実行される処理の一例を示す図である。 第２実施形態における多要素認証の流れの一例を示す図である。 第３実施形態における多要素認証の流れの一例を示す図である。 第３実施形態の通信システムで実現される機能ブロックの一例を示す図である。 変形例１における多要素認証の流れの一例を示す図である。

［１．第１実施形態］
本開示に係る通信システムの実施形態の例である第１実施形態を説明する。第１実施形態では、ユーザの認証が行われる場面に通信システムを適用した場合を例に挙げるが、通信システムは、任意の場面に適用可能である。他の場面への適用例は、後述の変形例４で説明する。

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

ソルトサーバ１０は、サーバコンピュータである。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、ハードディスク等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

ソルトサーバ１０は、第３装置の一例である。このため、ソルトサーバ１０と記載した箇所は、第３装置と読み替えることができる。第３装置は、任意の装置であってよく、ソルトサーバ１０のようなサーバコンピュータに限られない。例えば、第３装置は、パーソナルコンピュータ、タブレット端末、又はスマートフォンであってもよい。

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

ソルト自体は、公知のソルトを利用可能である。例えば、ソルトは、ランダムな値である。ソルトは、任意の形式であってよく、例えば、数字、文字、その他の記号、又はこれらの組み合わせである。ソルトサーバ１０は、ソルトを生成してもよいし、ソルトの生成自体は、ソルトサーバ１０以外の他の装置で行われてもよい。

認証サーバ２０は、サーバコンピュータである。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

認証サーバ２０は、第２装置の一例である。このため、認証サーバ２０と記載した箇所は、第２装置と読み替えることができる。第２装置は、任意の装置であってよく、認証サーバ２０のようなサーバコンピュータに限られない。例えば、第２装置は、パーソナルコンピュータ、タブレット端末、又はスマートフォンであってもよい。

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

ユーザＰＣ３０は、第１装置の一例である。このため、ユーザＰＣ３０と記載した箇所は、第１装置と読み替えることができる。第１装置は、任意の装置であってよく、ユーザＰＣ３０のようなパーソナルコンピュータに限られない。例えば、第１装置は、タブレット端末、スマートフォン、又はウェアラブル端末であってもよい。他にも例えば、第１装置は、ゲーム機、自動販売機、ＰＯＳ端末、又はＡＴＭといった他の装置であってもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なお、ユーザがログインした後に、悪意のある第三者が、クロスサイトスクリプティング（ＸＳＳ）攻撃等によって、変換後のＴＵＩＤ「３２０８７０」と、ユーザの顔写真と、を盗んだとすると、ソルトが切り替わるまでは、第三者によるなりすましが可能になる恐れがある。そこで、認証サーバ２０は、ユーザがログインした場合に、新たなＴＵＩＤを発行し、ユーザデータベースＤＢ２に格納してもよい。即ち、認証サーバ２０は、ユーザがログインするたびに、ＴＵＩＤを更新してもよい。新たなＴＵＩＤが「４１７６３２」だったとすると、認証サーバ２０は、ユーザＰＣ３０に対し、新たなＴＵＩＤ「４１７６３２」を含む認証結果を送信すればよい。これにより、ユーザがログインするたびにＴＵＩＤが変わるので、第三者が上記のようなクロスサイトスクリプティング（ＸＳＳ）攻撃等をしたとしても認証を成功させることができず、なりすましを防止できる。新たなＴＵＩＤ「４１７６３２」は、ソルトサーバ１０から受信済みのソルト「８４１４」で変換されてもよい。この場合、認証サーバ２０は、新たなＴＵＩＤを変換するための変換関数を記憶し、ユーザＰＣ３０は、変換後の新たなＴＵＩＤを逆変換するための逆変換関数ｆ^－１を記憶しているものとする。この逆変換でも、ソルトサーバ１０から受信済みのソルト「８４１４」が利用されてもよい。

以上のように、第１実施形態の通信システムＳは、ユーザがログインする時の日及び時間帯の組み合わせに応じたソルトに基づいて、ＴＵＩＤを変換したり、変換後のＴＵＩＤを逆変換したりする。これにより、ＴＵＩＤがそのままネットワークＮ上に送信されないので、第三者は、ＴＵＩＤを簡単に入手できないようになる。更に、ソルトは、ある一定の期間だけ有効なので、第三者が何らかの形でソルトを取得したとしても、このソルトが有効な期間を一定程度の長さに抑えることができるので、通信におけるセキュリティが高まるようになっている。以降、第１実施形態の通信システムＳの詳細を説明する。

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

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

[データ記憶部]
データ記憶部１００は、ソルトを管理するために必要なデータを記憶する。例えば、データ記憶部１００は、複数の期間の各々と、ソルト（変換情報及び逆変換情報の一例）と、が関連付けられたソルトデータベースＤＢ１を記憶する。ソルトサーバ１０は、ソルトデータベースＤＢ１により、複数の期間の各々と、変換情報及び逆変換情報と、を関連付けて管理する。変換情報及び逆変換情報が、ソルト以外の名前で呼ばれる情報であれば、ソルトサーバ１０は、ソルトデータベースＤＢ１以外の名前で呼ばれるデータベースを利用して、変換情報及び逆変換情報を管理すればよい。

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

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

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

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

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

第１実施形態では、ＴＵＩＤの変換と、変換後のＴＵＩＤの逆変換と、で同じソルトが利用される場合を例に挙げる。このため、ソルトは、変換情報の一例であり、逆変換情報の一例でもある。ソルトと記載した箇所は、変換情報と読み替えることができる。ソルトと記載した箇所は、逆変換情報と読み替えることもできる。変換情報は、暗号理論における暗号鍵である。逆変換情報は、暗号理論における復号鍵である。第１実施形態では、変換情報及び逆変換情報が互いに同じなので、変換情報及び逆変換情報は、暗号理論における共通鍵に相当する。変換情報及び逆変換情報は、鍵以外の名前で呼ばれてもよく、例えば、ファイルの暗号化で用いられるパスワードが変換情報及び逆変換情報に相当してもよい。

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

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

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

例えば、ソルトサーバ１０が、ある第１時点が属する第１期間（図２の例であれば、２日の０１時台）に、認証サーバ２０からソルト要求を受け付けたとする。第１時点は、ソルトサーバ１０がユーザＰＣ３０からのソルト要求を受け付けた場合の時点である。送信部１０３は、第１期間にユーザＰＣ３０からのソルト要求を受け付けた場合に、ユーザＰＣ３０に対し、第１ソルトを送信する。第１ソルトは、第１期間に応じたソルトである。図２の例であれば、第１期間が「２日」の「０１時」なので、第１ソルトは、ソルトデータベースＤＢ１において、「２日」の「０１時」に関連付けられたソルト「８４１４」である。以降では、第１期間に応じた第１ソルトと、他の期間に応じた他のソルトと、を区別しない時は、単にソルトと記載する。

送信部１０３は、第１期間に認証サーバ２０からのソルト要求を受け付けた場合に、認証サーバ２０に対し、第１ソルトを送信する。即ち、送信部１０３は、認証サーバ２０からのソルト要求と、ユーザＰＣ３０からのソルト要求と、を同じ第１期間に受け付けた場合に、認証サーバ２０及びユーザＰＣ３０の各々に対し、同じ第１ソルトを送信する。第１実施形態では、送信部１０３は、認証サーバ２０からのソルト要求と、ユーザＰＣ３０からのソルト要求と、を互いに異なる期間に受け付けた場合には、認証サーバ２０及びユーザＰＣ３０の各々に対し、互いに異なるソルトを送信するものとする。この場合、ＴＵＩＤの変換で用いられるソルトと、ＴＵＩＤの逆変換で用いられるソルトと、が対応しないので、正常な逆変換が行われずに認証処理が失敗するので、一連の認証処理の流れがやり直される。

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

［更新部］
更新部１０４は、ソルトデータベースＤＢ１を更新する。更新部１０４は、所定の更新条件が満たされたか否かを判定し、更新条件が満たされた場合に、ソルトデータベースＤＢ１を更新する。更新条件は、ソルトデータベースＤＢ１を更新するための条件である。更新条件は、任意の条件を設定可能である。第１実施形態では、毎日の０時が訪れること（日付が変わること）が更新条件に相当する場合を例に挙げるが、更新条件は、管理者が所定の操作をすること、認証処理が所定回数以上実行されること、又はソルトが所定回数以上取得されること、といった他の条件であってもよい。

更新部１０４は、更新条件が満たされた場合に、ソルト生成部１０１にソルトを生成させ、ソルトデータベースＤＢ１に格納する。ソルトデータベースＤＢ１が更新されるたびに、ソルトの生成条件（例えば、タイムスタンプ）が異なるものとする。このため、ソルトデータベースＤＢ１が更新されるたびに、異なる値のソルトが生成される。図４のデータ格納例であれば、毎日の０時が訪れた場合に、その日の００時から２３時までのソルトが生成されるように、ソルトデータベースＤＢ１が更新される。

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

［データ記憶部］
データ記憶部２００は、ユーザＰＣ３０との通信に必要なデータを記憶する。第１実施形態では、通信システムＳにおいて多要素認証が実行されるので、データ記憶部２００は、多要素認証に必要なデータを記憶する。例えば、データ記憶部２００は、ユーザデータベースＤＢ２を記憶する。

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

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

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

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

［受信部］
受信部２０１は、ユーザＰＣ３０から、変換後のＴＵＩＤを受信する。受信部２０１は、任意の期間に応じたソルトで変換された変換後のＴＵＩＤを受信可能である。先述した第１期間に応じたソルトで変換された変換後のＴＵＩＤは、第１変換データの一例である。このため、第１期間に応じたソルトで変換された変換後のＴＵＩＤについて説明している箇所は、第１変換データと読み替えることができる。第１変換データは、元データの一例であるＴＵＩＤに対して第１期間に応じた第１変換が行われたデータである。元データは、変換の対象となるデータである。元データは、変換前のデータである。元データは、暗号理論における平文に相当する。第１実施形態では、元データは、ユーザＰＣ３０のユーザに関する認証データである。元データは、変換前のデータなので、生データと呼ばれることもある。

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

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

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

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

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

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

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

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

ソルト取得部２０３は、第１期間に応じたソルトを取得すればよい。例えば、ソルト取得部２０３は、ソルトデータベースＤＢ１において、第１期間に関連付けられた第１ソルトを取得する。ソルト取得部２０３は、ソルトデータベースＤＢ１が更新された後は、更新後のデータベースにおいて、第１期間に関連付けられた第１ソルトを取得する。ソルトサーバ１０が認証サーバ２０からのソルト要求を受け付けた時点が属する期間が、第１期間よりも後の第２期間だった場合には、ソルト取得部２０３は、第２期間に応じたソルトを取得する。

［逆変換部］
逆変換部２０４は、第１変換データの一例である変換後のＴＵＩＤに対し、第１期間に応じた第１逆変換を行って、元データ及び認証データの一例であるＴＵＩＤを取得する。第１逆変換は、第１変換に応じた逆変換である。第１逆変換は、暗号理論における復号化である。認証サーバ２０が変換後のＴＵＩＤを逆変換する時点が、第１期間よりも後の第２期間であれば、逆変換部２０４は、第２変換データに対し、第２期間に応じた第２逆変換を行って、元データを取得する。

逆変換部２０４は、第１期間に応じた第１ソルトに基づいて、変換後のＴＵＩＤを逆変換することによって、第１逆変換を行う。第１逆変換のための逆変換関数ｆ^－１は、データ記憶部２００に記憶されているものとする。逆変換部２０４は、逆変換情報の一例である第１ソルトに基づいて、変換後のＴＵＩＤを逆変換関数ｆ^－１で逆変換する。図２の例であれば、逆変換部２０４は、変換後のＴＵＩＤから第１ソルトを減算することによって、変換後のＴＵＩＤを逆変換してＴＵＩＤを取得する。

なお、逆変換自体は、種々の逆変換関数ｆ^－１を利用可能であり、図２のような減算に限られない。例えば、加算、乗算、除算、行列変換、その他の計算、又はこれらの組み合わせにより、逆変換が行われてもよい。図２の例では、説明の簡略化のために、変換関数ｆ及び逆変換関数ｆ^－１がそれぞれ単純な加算及び減算である場合を示しているが、実際には、ある程度複雑な計算式であるものとする。更に、逆変換は、暗号理論における復号化に限られず、圧縮されたファイルの解凍であってもよい。解凍が逆変換に相当する場合、圧縮が変換に相当する。圧縮は、ファイルに対して何らかの変換が行われるので、第１実施形態における変換に相当する。解凍は、圧縮済みのファイルを元の状態に戻す処理なので、第１実施形態における逆変換に相当する。

［処理実行部］
処理実行部２０５は、第１逆変換により取得された認証データに基づいて、ユーザに関する認証処理を実行する。第１実施形態では、認証処理の一例として多要素認証を説明するが、認証処理は、１要素認証であってもよい。例えば、顔認証が利用されずに、ＴＵＩＤの認証のみが実行されてもよい。また、処理実行部２０５は、通信システムＳを適用する場面に応じた処理を実行すればよく、処理実行部２０５が実行する処理は、認証処理に限られない。他の場面に通信システムＳを適用した場合の処理は、後述の変形例で説明する。処理実行部２０５は、逆変換部２０４により取得された元データに基づいて、所定の処理を実行すればよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

［ソルト取得部］
ソルト取得部３０２は、元データの一例であるＴＵＩＤを変換するためのソルトであって、第１期間に応じた第１ソルトを取得する。この第１ソルトは、第１変換情報の一例である。ソルト取得部３０２は、変換情報取得部の一例である。このため、ソルト取得部３０２について説明している箇所は、変換情報取得部と読み替えることができる。変換情報取得部は、ソルトを一例とする変換情報を取得する。変換情報がソルト以外の名前で呼ばれる場合には、変換情報取得部は、この名前に応じた名前で呼ばれてよい。例えば、変換情報が鍵又はパスワードと呼ばれる場合には、変換情報取得部は、鍵又はパスワードを取得する。

第１実施形態では、ソルトサーバ１０からユーザＰＣ３０へのソルトの取得と、ソルトサーバ１０から認証サーバ２０へのソルトの取得と、が同じ手順で行われるので、ソルト取得部３０２の処理は、認証サーバ２０のソルト取得部２０３の処理と同様である。このため、ソルトサーバ１０からソルトを取得する点、日及び時間帯の組み合わせに応じたソルトを取得する点についても同様である。

第１実施形態では、第１期間は、日及び時間帯の組み合わせで示されるので、ソルト取得部３０２は、第１期間が示す日及び時間帯の組み合わせに応じた第１ソルトを取得する。ソルト取得部３０２は、ソルトデータベースＤＢ１において、第１期間に関連付けられた第１ソルトを取得する。ソルト取得部３０２は、ソルトデータベースＤＢ１が更新された後は、更新後のソルトデータベースＤＢ１において、第１期間に関連付けられた第１ソルトを取得する。ソルト取得部３０２は、ソルトサーバ１０から、第１ソルトを取得する。

［変換部］
変換部３０３は、元データ及び認証データの一例であるＴＵＩＤに対し、ＴＵＩＤが変換される第１時点が属する第１期間に応じた第１変換を行って、第１変換データを生成する。第１変換は、第１期間に応じた変換である。第１実施形態では、第１期間に応じた第１ソルトに基づく変換が第１変換に相当する。第１時点とは異なる第２時点ではあるが、第１時点と同じ第１期間に属する第２時点であれば、第１変換が行われる。このため、変換部３０３は、第１期間に属し、かつ、第１時点とは異なる第２時点にＴＵＩＤが変換される場合に、ＴＵＩＤに対し、第１変換を行って、第１変換データを生成する。

一方で、第１期間とは異なる第２期間であれば、第１変換とは異なる第２変換が行われる。このため、変換部３０３は、第１期間とは異なる第２期間に属し、かつ、第１時点及び第２時点とは異なる第３時点にＴＵＩＤが変換される場合に、ＴＵＩＤに対し、第２期間に応じた第２変換を行って、第２変換データを生成する。第１実施形態では、第２期間に応じた第２ソルトに基づく変換が第２変換に相当する。変換関数ｆ自体は、第１変換と第２変換で同じであるが、変換関数ｆに入力されるソルトは、第１変換の場合には第１ソルトであり、第２変換の場合には第２ソルトなので、第１変換と第２変換は、互いに異なる変換である。即ち、第１変換で利用される第１変換情報の一例である第１ソルトと、第２変換で利用される第２変換情報の一例である第２ソルトと、は互いに異なる。

変換部３０３は、第１ソルトに基づいて、ＴＵＩＤを変換することによって、第１変換を行う。変換は、暗号理論における暗号化である。変換は、ＴＵＩＤに対して何らかの変更がなされるものであればよい。例えば、ＴＵＩＤを何らかの関数に入力すること、ＴＵＩＤの一部を変更すること、ＴＵＩＤの全部を変更すること、ＴＵＩＤに対して何らかの情報を付加すること、又はＴＵＩＤの一部を削除することが変換に相当する。逆変換は、これらの逆方向の処理（ＴＵＩＤを元に戻す処理）であればよい。先述したように、ファイルの圧縮が変換に相当し、ファイルの解凍が逆変換に相当してもよい。この場合、第１ソルトをパスワードとして利用し、圧縮又は解凍が実行される。

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

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

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

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

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

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

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

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

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

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

第１実施形態の通信システムＳによれば、ユーザＰＣ３０は、ＴＵＩＤに対し、第１期間に応じた第１変換を行って、変換後のＴＵＩＤを生成する。ユーザＰＣ３０は、認証サーバ２０に対し、変換後のＴＵＩＤを送信する。認証サーバ２０は、ユーザＰＣ３０から、変換後のＴＵＩＤを受信する。認証サーバ２０は、変換データに対し、第１期間に応じた第１逆変換を行って、ＴＵＩＤを取得する。これにより、変換後のＴＵＩＤがネットワーク上に送信され、第三者にＴＵＩＤが取得されないので、通信におけるセキュリティが高まる。第三者が第１変換の仕組みを何らかの形で取得したとしても、この仕組みを利用できる期間が制限されているので、不正が行われる期間を一定程度に抑えることができ、通信におけるセキュリティが高まる。

また、ユーザＰＣ３０は、互いに異なる第１時点及び第２時点だったとしても、同じ第１期間に属するのであれば、第１変換を行う。ユーザＰＣ３０は、第１期間とは異なる第２期間に属する第３時点にＴＵＩＤが変換される場合に、ＴＵＩＤに対し、第２変換を行う。認証サーバ２０は、第１期間には第１逆変換を行って、ＴＵＩＤを取得する。認証サーバ２０は、第２期間には第２逆変換を行って、ＴＵＩＤを取得する。これにより、第１期間と第２期間で異なる変換をすることができるので、第三者が第１変換の仕組みを何らかの形で取得したとしても、第２期間になれば第１変換を利用できなくなるので、通信におけるセキュリティが高まる。

また、ユーザＰＣ３０は、第１ソルトに基づいて、ＴＵＩＤを変換することによって、第１変換を行う。認証サーバ２０は、第１ソルトに基づいて、変換後のＴＵＩＤを逆変換することによって、第１逆変換を行う。これにより、変換関数ｆ及び逆変換関数ｆ^－１を変えることなく、期間に応じて利用するソルトを変えることによって、通信におけるセキュリティが高まる。

また、認証サーバ２０及びユーザＰＣ３０の各々は、第１期間が示す日及び時間帯の組み合わせに応じた第１ソルトを取得する。これにより、第１ソルトが有効な期間を時間帯単位で設定することができるので、第１ソルトが有効な期間を比較的短くすることができる。第三者が第１ソルトを取得したとしても、第１ソルトを利用できる期間が短いので、通信におけるセキュリティが効果的に高まる。

また、認証サーバ２０及びユーザＰＣ３０の各々は、ソルトデータベースＤＢ１において、第１期間に関連付けられた第１ソルトを取得する。これにより、予めソルトデータベースＤＢ１に第１ソルトを格納することによって、その場で第１ソルトを生成する必要がなくなるので、通信時に必要な処理を簡易化できる。その結果、ソルトサーバ１０の処理負荷を軽減し、認証処理の完了までに要する時間が短くなる。

また、ソルトサーバ１０は、ソルトデータベースＤＢ１を更新する。これにより、同じソルトを長期間利用することがなくなるので、通信におけるセキュリティが高まる。

また、認証サーバ２０及びユーザＰＣ３０の各々は、ソルトサーバ１０に対し、ソルト要求を送信する。ソルトサーバ１０は、認証サーバ２０及びユーザＰＣ３０の各々に対し、第１ソルトを送信する。認証サーバ２０及びユーザＰＣ３０の各々は、ソルトサーバ１０から、第１ソルトを取得する。これにより、認証サーバ２０が第１ソルトを管理しなくてすむので、通信における処理負荷を分散させることができる。即ち、ソルトサーバ１０及び認証サーバ２０で通信に必要な処理を分散することができる。このため、認証サーバ２０の処理負荷を軽減できる。

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

また、認証サーバ２０は、第１逆変換により取得されたＴＵＩＤに基づいて、認証処理を実行し、認証処理が成功した場合に、新たなＴＵＩＤを生成する。これにより、認証時のセキュリティが高まる。例えば、ユーザがログインするたびにＴＵＩＤが変わるので、第三者が先述したクロスサイトスクリプティング攻撃等をしたとしても認証を成功させることができないので、なりすましを防止できる。

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

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

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

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

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

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

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

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

第２実施形態の第１変換は、第１期間及びＴＵＩＤの一部分に応じた変換である。変換部３０３は、第１変換情報に基づいて、ＴＵＩＤのうち、下２桁以外の残り部分を変換することによって、第１変換データを生成する。残り部分は、元データの一部分以外の部分である。ＴＵＩＤが６桁であれば、残り部分は、上４桁である。ソルトを利用した変換方法自体は、第１実施形態で説明した通りである。

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

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

第２実施形態の第１逆変換は、第１期間と、未変換の一部分と、に応じた逆変換である。逆変換部２０４は、逆変換情報に基づいて、第１変換データの一例である変換後のＴＵＩＤの残り部分（上４桁）を逆変換して残り部分を取得し、当該残り部分と、未変換の一部分と、に基づいて、ＴＵＩＤを取得する。図８の例であれば、逆変換部２０４は、逆変換によってＴＵＩＤの上４桁「３１２４」を取得するので、上４桁「３１２４」と、ユーザＰＣ３０から受信した下２桁「００」と、に基づいて、ＴＵＩＤ「３１２４００」を取得する。図８の例では、上４桁「３１２４」と下２桁「００」に付加される場合を説明するが、予め定められた結合ルールに基づいて、元データであるＴＵＩＤが取得されるようにすればよい。

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

また、ユーザＰＣ３０は、第１ソルトに基づいて、ＴＵＩＤのうち、下２桁以外の残り部分である上４桁を変換することによって、変換後のＴＵＩＤの上４桁を生成する。認証サーバ２０は、第１ソルトに基づいて、変換後のＴＵＩＤの上４桁を逆変換してＴＵＩＤの上４桁を取得し、当該上４桁と、未変換の下２桁と、に基づいて、ＴＵＩＤを取得する。これにより、ＴＵＩＤを複数の部分に分割したとしても、認証サーバ２０は、１つにまとめたＴＵＩＤを取得し、認証処理を確実に完了できる。

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

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

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

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

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

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

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

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

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

第３実施形態では、時間帯は、第１期間の一例である。このため、時間帯について説明している箇所は、第１期間と読み替えることができる。第３実施形態では、第１期間が時間帯で示される場合を説明するが、第１期間は、第１実施形態及び第２実施形態のように日及び時間帯の組み合わせで示されてもよいし、日だけで示されてもよい。第１期間が他の意味だったとしても、変換関数選択部３０６は、第１期間が示す時間帯に応じた変換関数ｆを選択する。個々の期間と、変換関数ｆと、の関係は、予めデータ記憶部３００に定義されているものとする。

変換部３０３は、変換関数選択部３０６により選択された変換関数ｆに基づいて、ＴＵＩＤを変換することによって、第１変換を行う。変換関数選択部３０６により選択された変換関数ｆが利用される点で、第１実施形態及び第２実施形態とは異なるが、他の点については同様である。

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

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

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

第３実施形態の通信システムＳによれば、ユーザＰＣ３０は、複数の変換関数ｆの中から、第１期間に応じた変換関数ｆを選択し、ＴＵＩＤを変換する。認証サーバ２０は、複数の逆変換関数ｆ^－１の中から、第１期間に応じた逆変換関数ｆ^－１を選択し、変換後のＴＵＩＤを逆変換する。これにより、変換後のＴＵＩＤがネットワーク上に送信され、第三者がＴＵＩＤを取得しにくくなるので、通信におけるセキュリティが高まる。また、変換関数ｆが動的に変わるので、第三者が変換の仕組みを把握しにくくなり、通信におけるセキュリティがより高まる。

また、ユーザＰＣ３０は、第１期間が示す時間帯に応じた変換関数ｆを選択する。認証サーバ２０は、第１期間が示す時間帯に応じた逆変換関数ｆ^－１を選択する。これにより、変換関数ｆがより短い期間に応じて変わるので、同じ変換関数ｆを使いまわす頻度が更に下がり、第三者が変換の仕組みを把握しにくくなる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ソルトサーバ１０は、認証サーバ２０からの要求を受け付けた時点が第１期間よりも後の第２期間である場合に、認証サーバ２０に対し、第１期間に応じたソルトと、第２期間に応じたソルトと、を含む複数のソルトを送信する。日及び時間帯の組み合わせは、第２期間の一例である。このため、日及び時間帯の組み合わせについて説明している箇所は、第２期間と読み替えることができる。

図１１の例であれば、第１期間は、「２日」の「０１時」である。この第１期間の終了時点は、「２日」の「０２：００：００」の直前の時点（例えば、「２日」の「０１：５９：５９」）である。図１１の例では、第１時点である「２０２１年１２月２日０１：５９：５９」がこの終了時点と同じ又は間際なので、ソルトサーバ１０は、第１期間である「２日」の「０１時」のソルト「８４１４」と、第１期間の次の第２期間である「２日」の「０２時」のソルト「９４３６」と、を送信する。

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

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

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

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

また、ソルトサーバ１０は、認証サーバ２０からのソルト要求を受け付けた時点が第１期間よりも後の第２期間である場合に、認証サーバ２０に対し、第１期間に応じたソルトと、第２期間に応じたソルトと、を含む複数のソルトを送信する。認証サーバ２０は、第１期間情報の一例であるタイムスタンプに基づいて、複数のソルトの中から、逆変換で利用する第１ソルトを選択する。これにより、逆変換を正確に実行することができるので、多要素認証が失敗してやり直すといった手間を省くことができる。

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

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

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

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

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

［４－３．変形例３］
例えば、ユーザがログインする前に、悪意のある第三者がクロスサイトスクリプティング攻撃等によって、ユーザＰＣ３０内のＴＵＩＤ、変換関数ｆ、ソルトサーバ１０へのアクセス方法（例えば、特定のＩＰアドレスに対し、ｇｅｔＳａｌｔ（）のコマンドを送信してソルトを取得する流れ）、及びユーザの顔写真が盗まれたとする。この場合、ユーザがログインするたびにＴＵＩＤを更新したとしても、第三者は、ソルトサーバ１０にアクセスする一連の流れと、認証に必要な情報を入手しているので、なりすますしが可能になる恐れがある。

そこで、ユーザが、認証サーバ２０に顔写真等の情報を登録したり、ユーザＩＤ及びパスワード等を利用して安全な方法でログインしたりする場合に、ユーザＰＣ３０は、自身に関する複数の情報に基づくハッシュ値を生成して認証サーバ２０に送信してもよい。このハッシュ値は、ユーザＩＤに関連付けられてユーザデータベースＤＢ２に格納される。ユーザがＴＵＩＤを利用した認証を実行してログインする場合には、ユーザＰＣ３０の送信部３０４は、認証サーバ２０に対し、変換後のＴＵＩＤと、ユーザＰＣ３０に関する複数の情報に基づくハッシュ値と、を送信する。第１実施形態等で説明したように、送信部３０４は、ユーザの顔写真も送信する。

認証サーバ２０の処理実行部２０５は、第１逆変換により取得されたＴＵＩＤと、ハッシュ値と、に基づいて、認証処理を実行する。第１実施形態等で説明した通信システムＳは、ＴＵＩＤ認証だけではなく、顔認証も併用されるので、処理実行部２０５は、ＴＵＩＤ、顔の特徴量、及びハッシュ値に基づいて、認証処理を実行する。このため、変形例３の認証処理は、三要素認証となる。ＴＵＩＤと顔の特徴量を利用した認証は、第１実施形態等で説明した通りである。処理実行部２０５は、ユーザＰＣ３０から受信したハッシュ値と、ユーザのユーザＩＤに関連付けられてユーザデータベースＤＢ２に格納されたハッシュ値と、が一致するか否かを判定する。これらが一致する場合には、ハッシュ値を利用した認証が成功する。

なお、ハッシュ値を生成するための複数の情報としては、任意の情報を組み合わせ可能である。例えば、ユーザＰＣ３０は、ユーザＰＣ３０の種類、オペレーティングシステムの種類、ブラウザの種類といった複数の情報に基づいて、ハッシュ値を生成してもよい。他にも例えば、ユーザＰＣ３０のシリアル番号、ＳＩＭカードの番号、又は通信カードのＭＡＣアドレスといった他の情報に基づいて、ハッシュ値が生成されてもよい。ハッシュ値を生成するためのハッシュ関数自体は、種々のハッシュ関数を利用可能である。ハッシュ値は、ユーザＰＣ３０に記憶されるのではなく、認証のたびに生成されるものとする。

変形例３の通信システムＳによれば、ハッシュ値を利用した認証によって、セキュリティが高まる。例えば、悪意のある第三者がユーザＰＣ３０内のＴＵＩＤ等を不正に入手したとしても、ハッシュ値までは特定できない可能性が高いので、セキュリティが高まる。

［４－４．変形例４］
例えば、通信システムＳは、認証処理が実行される場面以外の他の場面に適用可能である。他の場面としては、電子メールを送信する場面、ファイルをアップロード又はダウンロードする場面、ＳＮＳの投稿が行われる場面、ブラウザで何らかのページを表示させる場面、又はユーザが個人情報をアップロード又はダウンロードする場面といった他の画面にも通信システムＳを適用可能である。

例えば、電子メールを送信する場面に通信システムＳを適用したとすると、第１装置は、電子メールの送信側のコンピュータであり、第２装置は、電子メールの受信側のコンピュータである。元データは、電子メールのデータである。元データには、電子メールの本文が含まれる。電子メールに添付ファイルが添付される場合には、元データには、添付ファイルが含まれる。第１装置は、電子メールである元データに対し、第１期間に応じた第１ソルトに基づいて、第１変換を行って、第１変換データを生成する。第１変換データは、変換後の電子メールである。第１装置は、第２装置に対し、変換後の電子メールである第１変換データを送信する。第２装置は、第１変換データを受信すると、第１ソルトに基づいて第１逆変換を行って、元データである電子メールを取得する。第１ソルトの取得方法は、第１実施形態～第３実施形態及び変形例１～３で説明した通りである。

例えば、ファイルをアップロードする場面に通信システムＳを適用したとすると、第１装置は、ファイルをアップロードするユーザのコンピュータであり、第２装置は、ファイルを受信するサーバである。元データは、アップロード対象のファイルである。第１装置は、アップロード対象のファイルである元データに対し、第１期間に応じた第１ソルトに基づいて、第１変換を行って、第１変換データを生成する。第１変換データは、変換後のファイルである。第１装置は、第２装置に対し、変換後のファイルである第１変換データを送信する。第２装置は、第１変換データを受信すると、第１ソルトに基づいて第１逆変換を行って、元データであるファイルを取得する。ソルトの取得方法は、第１実施形態～第３実施形態及び変形例１～３で説明した通りである。

他の場面に通信システムＳを適用した場合も同様であり、第１装置は、元データに対し、第１期間に応じた第１変換を行えばよい。第２装置は、第１変換データに対し、第１期間に応じた第１逆変換を行えばよい。変形例４の通信システムＳによれば、種々の場面における通信のセキュリティが高まる。

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

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

Claims (20)

1. 第１装置及び第２装置を含む通信システムであって、
   前記第１装置は、
   元データを変換するための変換情報であって、前記元データが変換される第１時点が属する第１期間の日及び時間帯に応じた第１変換情報を取得する変換情報取得部と、
   前記第１変換情報に基づいて、前記元データを変換することによって第１変換を行って、第１変換データを生成する変換部と、
   前記第２装置に対し、前記第１期間の分及び秒に関する第１期間情報と、前記第１変換データと、を送信する送信部と、
   を含み、
   前記第２装置は、
   前記第１装置から、前記第１期間情報と、前記第１変換データと、を受信する受信部と、
   前記第１期間情報に基づいて、前記第１変換データを逆変換するための逆変換情報であって、前記第１期間の日及び時間帯に応じた第１逆変換情報を取得する逆変換情報取得部と、
   前記第１逆変換情報に基づいて、前記第１変換データを逆変換することによって第１逆変換を行って、前記元データを取得する逆変換部と、
   を含む通信システム。
2. 前記変換部は、前記第１期間に属し、かつ、前記第１時点とは異なる第２時点に前記元データが変換される場合に、前記元データに対し、前記第１変換を行って、前記第１変換データを生成し、
   前記変換部は、前記第１期間とは異なる第２期間に属し、かつ、前記第１時点及び前記第２時点とは異なる第３時点に前記元データが変換される場合に、前記元データに対し、前記第２期間に応じた第２変換を行って、第２変換データを生成し、
   前記逆変換部は、前記第１変換データに対し、前記第１逆変換を行って、前記元データを取得し、
   前記逆変換部は、前記第２変換データに対し、前記第２期間に応じた第２逆変換を行って、前記元データを取得する、
   請求項１に記載の通信システム。
3. 前記第１期間は、日及び時間帯の組み合わせで示され、
   前記変換情報取得部は、前記第１期間が示す日及び時間帯の組み合わせに応じた前記第１変換情報を取得し、
   前記逆変換情報取得部は、前記第１期間が示す日及び時間帯の組み合わせに応じた前記第１逆変換情報を取得する、
   請求項１又は２に記載の通信システム。
4. 前記通信システムは、前記第１期間と、前記第１変換情報と、を関連付けて管理する第３装置を更に含み、
   前記第３装置は、前記第１装置から前記第１変換情報の取得要求を受け付けた場合に、前記第１装置に対し、前記第１期間に応じた前記第１変換情報を送信し、
   前記送信部は、前記第２装置に対し、前記第３装置から受信した前記第１変換情報に応じた前記第１期間情報を送信する、
   請求項１～３の何れかに記載の通信システム。
5. 前記通信システムは、複数の期間の各々と、前記逆変換情報と、を関連付けて管理する第３装置を更に含み、
   前記第２装置は、前記第３装置に対し、前記逆変換情報を要求する逆変換情報要求部を更に含み、
   前記第３装置は、前記第２装置に対し、前記第２装置からの要求を受け付けた場合の時点が属する期間に応じた前記逆変換情報を送信する送信部を更に含み、
   前記第３装置の前記送信部は、前記第２装置からの要求を受け付けた時点が前記第１期間よりも後の第２期間である場合に、前記第２装置に対し、前記第１期間に応じた前記第１逆変換情報と、前記第２期間に応じた第２逆変換情報と、を含む複数の前記逆変換情報を送信し、
   前記逆変換情報取得部は、前記第１期間情報に基づいて、前記複数の逆変換情報の中から前記第１逆変換情報を選択する、
   請求項１～４の何れかに記載の通信システム。
6. 前記変換情報取得部は、前記第１期間と、前記元データの一部分と、に応じた前記第１変換情報を取得し、
   前記第１変換は、前記第１期間及び前記一部分に応じた変換であり、
   前記送信部は、前記第２装置に対し、未変換の前記一部分を更に送信し、
   前記逆変換情報取得部は、前記第１期間と、前記未変換の一部分と、に応じた前記逆変換情報を取得し、
   前記第１逆変換は、前記第１期間と、前記未変換の一部分と、に応じた逆変換である、
   請求項１に記載の通信システム。
7. 前記変換部は、前記第１変換情報に基づいて、前記元データのうち、前記一部分以外の残り部分を変換することによって、前記第１変換データを生成し、
   前記逆変換部は、前記逆変換情報に基づいて、前記第１変換データを逆変換して前記残り部分を取得し、当該残り部分と、前記未変換の一部分と、に基づいて、前記元データを取得する、
   請求項６に記載の通信システム。
8. 前記通信システムは、複数の期間の各々と、前記変換情報及び前記逆変換情報と、が関連付けられたデータベースを記憶するデータ記憶部を更に含み、
   前記変換情報取得部は、前記データベースにおいて、前記第１期間に関連付けられた前記第１変換情報を取得し、
   前記逆変換情報取得部は、前記データベースにおいて、前記第１期間に関連付けられた前記第１逆変換情報を取得する、
   請求項１に記載の通信システム。
9. 前記通信システムは、前記データベースを更新する更新部を更に含む、
   請求項８に記載の通信システム。
10. 前記通信システムは、複数の期間の各々と、前記変換情報及び前記逆変換情報と、を関連付けて管理する第３装置を更に含み、
    前記第１装置は、前記第３装置に対し、前記変換情報を要求する変換情報要求部を更に含み、
    前記第１時点は、前記第３装置が前記第１装置からの要求を受け付けた場合の時点であり、
    前記第３装置は、前記第１装置に対し、前記第１変換情報を送信する送信部を更に含み、
    前記変換情報取得部は、前記第３装置から、前記第１変換情報を取得し、
    前記第２装置は、前記第３装置に対し、前記逆変換情報を要求する逆変換情報要求部を更に含み、
    前記第３装置は、前記第１期間に前記第２装置からの要求を受け付けた場合に、前記第２装置に対し、前記第１逆変換情報を送信し、
    前記逆変換情報取得部は、前記第３装置から、前記第１逆変換情報を取得する、
    請求項１に記載の通信システム。
11. 前記変換情報要求部は、前記第３装置に対し、前記変換情報の取得ルールに関する情報を含まない要求を送信し、
    前記逆変換情報要求部は、前記第３装置に対し、前記逆変換情報の取得ルールに関する情報を含まない要求を送信する、
    請求項１０に記載の通信システム。
12. 前記第１装置は、複数の変換方法の中から、前記第１期間に応じた第１変換方法を選択する変換方法選択部を更に含み、
    前記変換部は、前記第１変換方法に基づいて、前記元データを変換することによって、前記第１変換を行い、
    前記第２装置は、複数の逆変換方法の中から、前記第１期間に応じた第１逆変換方法を選択する逆変換方法選択部を更に含み、
    前記逆変換部は、前記第１逆変換方法に基づいて、前記元データを逆変換することによって、前記第１逆変換を行う、
    請求項１～１１の何れかに記載の通信システム。
13. 前記第１期間は、時間帯で示され、
    前記変換方法選択部は、前記第１期間が示す時間帯に応じた前記第１変換方法を選択し、
    前記逆変換方法選択部は、前記第１期間が示す時間帯に応じた前記第１逆変換方法を選択する、
    請求項１２に記載の通信システム。
14. 前記送信部は、前記第２装置に対し、前記第１期間に関する第１期間情報を更に送信し、
    前記受信部は、前記第１装置から、前記第１期間情報を更に受信し、
    前記逆変換方法選択部は、前記第１期間情報に基づいて、前記第１期間に応じた前記逆変換方法を選択する、
    請求項１２又は１３に記載の通信システム。
15. 前記元データは、前記第１装置のユーザに関する認証データであり、
    前記変換部は、前記認証データに対し、前記第１変換を行って、前記第１変換データを生成し、
    前記逆変換部は、前記第１変換データに対し、前記第１逆変換を行って、前記認証データを取得し、
    前記第２装置は、
    前記第１逆変換により取得された前記認証データに基づいて、前記ユーザに関する認証処理を実行する処理実行部と、
    前記認証処理が成功した場合に、新たな前記認証データを生成する生成部と、
    を更に含む、
    請求項１～１４の何れかに記載の通信システム。
16. 前記元データは、前記第１装置のユーザに関する認証データであり、
    前記変換部は、前記認証データに対し、前記第１変換を行って、前記第１変換データを生成し、
    前記送信部は、前記第１変換データと、前記第１装置に関する複数の情報に基づくハッシュ値と、を送信し、
    前記逆変換部は、前記第１変換データに対し、前記第１逆変換を行って、前記認証データを取得し、
    前記第２装置は、前記第１逆変換により取得された前記認証データと、前記ハッシュ値と、に基づいて、前記ユーザに関する認証処理を実行する処理実行部を更に含む、
    請求項１～１４の何れかに記載の通信システム。
17. 前記処理実行部は、前記第１装置から受信した前記ハッシュ値と、予めデータベースに格納されたハッシュ値と、に基づいて、前記認証処理を実行する、
    請求項１６に記載の通信システム。
18. 第１装置及び第２装置の間の通信方法であって、
    前記第１装置は、
    元データを変換するための変換情報であって、前記元データが変換される第１時点が属する第１期間の日及び時間帯に応じた第１変換情報を取得する変換情報取得ステップと、
    前記第１変換情報に基づいて、前記元データを変換することによって第１変換を行って、第１変換データを生成する変換ステップと、
    前記第２装置に対し、前記第１期間の分及び秒に関する第１期間情報と、前記第１変換データと、を送信する送信ステップと、
    を実行し、
    前記第２装置は、
    前記第１装置から、前記第１期間情報と、前記第１変換データと、を受信する受信ステップと、
    前記第１期間情報に基づいて、前記第１変換データを逆変換するための逆変換情報であって、前記第１期間の日及び時間帯に応じた第１逆変換情報を取得する逆変換情報取得ステップと、
    前記第１逆変換情報に基づいて、前記第１変換データを逆変換することによって第１逆変換を行って、前記元データを取得する逆変換ステップと、
    を実行する通信方法。
19. 第２装置と通信可能な第１装置を、
    元データを変換するための変換情報であって、前記元データが変換される第１時点が属する第１期間の日及び時間帯に応じた第１変換情報を取得する変換情報取得部、
    前記第１変換情報に基づいて、前記元データを変換することによって第１変換を行って、第１変換データを生成する変換部、
    前記第２装置に対し、前記第１期間の分及び秒に関する第１期間情報と、前記第１変換データと、を送信する送信部、
    として機能させるためのプログラム。
20. 第１装置と通信可能な第２装置を、
    前記第１装置から、元データに対し、前記元データを変換するための変換情報であって、前記元データが変換される第１時点が属する第１期間の日及び時間帯に応じた第１変換情報に基づいて第１変換が行われた第１変換データと、前記第１期間の分及び秒に関する第１期間情報と、を受信する受信部、
    前記第１期間情報に基づいて、前記第１変換データを逆変換するための逆変換情報であって、前記第１期間の日及び時間帯に応じた第１逆変換情報を取得する逆変換情報取得部、
    前記第１逆変換情報に基づいて、前記第１変換データを逆変換することによって第１逆変換を行って、前記元データを取得する逆変換部、
    としてコンピュータを機能させるためのプログラム。

Images