JPWO2019026873A1 - 相互認証システム、認証用画像及び記録媒体 - Google Patents

Abstract

セキュリティリスクを増大させることなく、簡易に本人認証を行うための相互認証システムの提供。発行者情報を含んだ二次元コードと、利用者が申請した当該利用者自身の情報を含む申請情報と、前記申請情報と紐づけられて、複数の文字列を組み合わせて構成されるＩＤ情報と、を用いて、発行者と利用者とが正当であることを互いに認証するための相互認証システムであって、前記ＩＤ情報のそれぞれによって異なる固有の彩紋図形を形成する彩紋形成手段と、各文字列に対応した基本彩紋図形の組み合わせパターンを用いて前記彩紋図形から前記ＩＤ情報を復号する彩紋判別手段と、前記彩紋判別手段によって復号された前記ＩＤ情報が、前記二次元コードに含まれた前記発行者情報と対応するものであるか否かを判別する認証手段と、を有することを特徴とする相互認証システム。

Description

本発明は、相互認証システム及び当該相互認証システムに用いられる認証用画像または当該認証用画像が印刷された記録媒体に関する。

金融機関の本人認証システムにおいては、セキュリティ向上のため、ユーザーが入力した住所や電話番号等の利用者情報に基づいて封書を郵送し、封書に記載のコードを用いて認証する方法が用いられている。
しかしながら、このような方法では、ユーザーは封書に書かれたＵＲＬに自身の携帯端末等を用いてアクセスし、その上で記載されたＰＩＮコード等を入力する手間がかかるため、ユーザーの認証にかかる手間が大きかった。
また、偽装されにくい郵送物の例としては例えば特願２０１７−０１４５５９（特願２０１６−０１６２４３）に記載されたような彩紋を印刷物とする手法が考えられるが、Ｗｅｂ上にあるデータとかかる彩紋とを関連付けるのが難しい。

こうした問題を回避するために、携帯端末を用いて簡単にＷｅｂ上の情報にアクセスする方法としては、例えばＱＲコード（登録商標、以下同じ）のような二次元コードを用いる方法が考えられる（例えば特許文献１等参照）。
しかしながらＱＲコードは基本的に読み取ることができれば誰でもアクセスできてしまうために、途中経路で第３者に見られる等のセキュリティリスクが増大してしまう。

また、このような郵送方式では、例えば悪意ある第３者によりＱＲコードを送付されたときには、利用者が不用意にアクセスしてしまう等の問題もあり、利用者と発行者とで相互に認証可能な方法であることが最も望ましい。

特開２００９−１２４３１１号公報 杉井 靖典"金融分野へのブロックチェーン利活用に際する実装課題と安全対策"、［online］、平成２８年８月２３日、第１回ＦｉｎＴｅｃｈフォーラム−ＦｉｎＴｅｃｈと情報セキュリティ、［平成２９年７月２７日検索］、インターネット＜URL：https://www.boj.or.jp/announcements/release_2016/rel160831b.htm/＞

本発明は、かかる問題を解決するためのものであり、セキュリティリスクを増大させることなく、簡易に本人認証を行うための相互認証システムの提供を目的とする。

上述した課題を解決するため、本発明の相互認証システムは、発行者情報を含んだ二次元コードと、利用者が申請した当該利用者自身の情報を含む申請情報と、前記申請情報と紐づけられて、複数の文字列を組み合わせて構成されるＩＤ情報と、を用いて、発行者と利用者とが正当であることを互いに認証するための相互認証システムであって、前記ＩＤ情報のそれぞれによって異なる固有の彩紋図形を形成する彩紋形成手段と、各文字列に対応した基本彩紋図形の組み合わせパターンを用いて前記彩紋図形から前記ＩＤ情報を復号する彩紋判別手段と、前記彩紋判別手段によって復号された前記ＩＤ情報が、前記二次元コードに含まれた前記発行者情報と対応するものであるか否かを判別する認証手段と、を有することを特徴とする。

本発明によれば、セキュリティリスクを増大させることなく、簡易に本人認証を行うことができる。

本発明の実施形態に係る相互認証システムの全体構成の一例を示す図である。 申請情報として記録される情報の一例を示す図である。 登録情報として記録される情報の一例を示す図である。 登録情報に含まれる情報の一例を示す図である。 図１に示した発行者情報を含むトークンの構成例についての概念図である。 図１に示した認証用の図柄を示す図である。 図１に示した相互認証システムの認証動作の一例を示すフロー図である。 図１に示した相互認証システムのデータのやり取りを示す図である。 本発明の第２の実施形態の構成の一例を示す図である。 本発明の変形例の構成の一例を示す図である。

本発明の第１の実施形態として、相互認証システム１００について説明する。
相互認証システム１００は、利用者Ｐが用いているスマートフォンや携帯電話等の情報通信端末としての携帯端末１０と、利用者Ｐに対してサービスを提供する発行者Ｑが管理する登録手段としての登録サーバー５０と、を含んで構成されるネットワークシステムである。
相互認証システム１００は、利用者Ｐが登録サーバー５０にアクセスすることで入力された利用者Ｐの個人情報を含む申請情報に基づいて、後述する認証用画像たる認証図柄を発行する彩紋形成手段たる彩紋発行サーバー８０を有している。
相互認証システム１００は、後述する認証図柄を用いて利用者Ｐの認証を行うための認証手段としての認証サーバー６０を有している。

なお、本実施形態においては、発行者Ｑの提供するクレジットカード発行サービスについて、利用者Ｐが取得を申請し、利用者Ｐと発行者Ｑとが互いに認証する方法について述べるが、かかる構成に限定されるものではない。
また、本実施形態では特に登録サーバー５０と認証サーバー６０とを別個に設けたが、一体のサーバー内に登録サーバー５０の機能と、認証サーバー６０の機能とを持たせるものであっても良い。
また、本実施形態では説明の簡単化のため、図１に示すように、発行者Ｑが登録サーバー５０と認証サーバー６０と彩紋発行サーバー８０の全てを管理するような構成としたが、かかる構成に限定されるものではない。例えば発行者Ｑが外部の登録サーバー５０や彩紋発行サーバー８０や認証サーバー６０を利用する形であっても良い。

登録サーバー５０は、発行者Ｑの提供するサービス、ここでは例えばクレジットカードの発行サービスを行うＷｅｂサーバーである。
登録サーバー５０は、利用者Ｐが利用者自身の個人情報すなわち申請情報Ｒを登録するための情報入力部５１と、情報入力部５１に入力された利用者Ｐの申請情報Ｒと発行者Ｑの発行者情報とに基づいてＪＷＴ（ＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ）等のトークンを発行するトークン発行部５２と、を有している。

ここで申請情報Ｒは、図２に示すような利用者Ｐの住所や電話番号などの個人情報を含んだ情報であり、登録サーバー５０は、利用者Ｐ自身が入力したかかる情報と、発行者Ｑの識別番号などの情報に基づいて、図３のように彩紋ＩＤ９２’や有効期間等を付記した形で、発行者Ｑの情報を含む登録情報Ｒ’として記録する。
彩紋ＩＤ９２’は、６桁〜８桁の英数字の羅列で構成されたＩＤ番号であり、ランダムに発行されるＩＤ情報である。なお本実施形態では、特に６〜８桁の英数字の羅列により彩紋ＩＤ９２’を表すこととしたが、かかる構成に限定されるものではなく、任意の桁数や文字列・記号等を用いることが可能である。
後述する署名の仕組みにより、彩紋ＩＤ９２’自身は重複しても良く、登録情報Ｒ’内には、彩紋ＩＤ９２’と登録情報Ｒ’との組み合わせが登録されている。
トークン発行部５２は、図４、図５に示すように、少なくとも発行者Ｑを識別するための発行者識別番号や、発行日時、有効期間、有効期間の開始日・終了日、宛先等の発行者情報を含んだトークンであるＪＷＴを発行する。かかるＪＷＴは、ＵＲＬセーフのトークンであり、彩紋ＩＤ９２’を用いて署名される。
なお、「ＵＲＬセーフ」とは、ＵＲＬに含めることの出来ない記号等の文字を含まないことを示し、ここではトークンそのものをＵＲＬの一部として利用可能である程度の意味で用いている。

ＪＷＴについての説明をする前に、鍵付きハッシュとも呼ばれるＨＭＡＣ（Ｈａｓｈ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）という処理について説明する。
ＨＭＡＣは、ＳＨＡ−２などの反復暗号ハッシュ関数を鍵と組み合わせて使用することで改ざんや偽装を検知するための仕組みである。
ＪＷＴは、かかるＨＭＡＣを用いて得られるトークンであり、図５に示すように、ヘッダと、エンティティと、フッタと、に分かれている。
ＪＷＴはエンティティ（またはフッタ）にある値にヘッダのアルゴリズムで処理をかけるとフッタ（またはエンティティ）に一致する。
すなわちＪＷＴは、登録情報Ｒ’から一部の情報、例えば図４に示すような情報を抜き出してエンティティとし、彩紋ＩＤ９２’を鍵として、ヘッダに含まれるアルゴリズムに基づき処理することで生成されるトークンである。
なお、このような処理を、本実施形態においては「（ＪＷＴを）彩紋ＩＤ９２’によって署名する」と表記するが、このような処理は、実装上は彩紋ＩＤ９２’をエンティティとして、図４のエンティティの内容を鍵としても成立する。

なお、ＪＷＴには、同じトークンを用いて複数回認証させる、所謂リプレイ行為に対する対策として、ワンタイムキーを盛り込んでおくことが望ましい。すなわち、本実施形態では、トークンに対して読み取り回数を制限する回数制御機能を付加されている。
かかる構成にすることで、後述する認証サーバー６０による認証操作が初回のみ認証されることとなるので、よりセキュリティ強度が向上する。
本実施形態では、特に図４に示すような情報を用いてトークンのエンティティを作成したが、かかる構成に限定されるものではなく、その他の情報を付加情報として含んでいても良い。

登録サーバー５０は、登録情報Ｒ’を彩紋発行サーバー８０へと送信する。
なお、本実施形態では、認証およびトークン発行を行う登録サーバー５０と、彩紋発行サーバー８０とは別個のサーバーがネットワークを介して接続されている態様として記載するが、かかる構成に限定されるものではない。
例えば、同一端末上で認証、トークン発行、彩紋発行、の全ての機能を備える構成としても良い。

彩紋発行サーバー８０は、登録情報Ｒ’に基づいて得られたＪＷＴをハッシュ化してＱＲコード等の二次元コードの形式で埋め込むとともに、彩紋ＩＤ９２’の数字の羅列を基本彩紋図形の組み合わせパターンを用いて彩紋図形へと変換する。
言い換えると彩紋発行サーバー８０は、彩紋ＩＤ９２’に基づいて彩紋図形を形成する彩紋形成手段８１と、登録情報Ｒ’に基づいて第１の二次元コードとしてＱＲコード９１を発行する二次元コード生成手段８２とを有している。
なお、本実施形態では、読み取りの可用性を高めるために二次元コードとしてＱＲコードを用いているが、かかる構成に限定されるものではなく、その他の二次元コードを用いたとしても良い。またバーコードなどであっても良い。

二次元コード生成手段８２は、登録情報Ｒ’のうち、特にＪＷＴをハッシュ化したアクセスコードであるhashコードを図６に示すようにＱＲコード９１として形成する。
ＱＲコード９１には、認証サーバー６０のＵＲＬが記載されており、例えばhttp://************/hashコード/等のＵＲＬへ携帯端末を接続させるようになっている。

彩紋形成手段８１は、彩紋ＩＤ９２’に基づいて、数字の羅列のパターンから図６に示すような特有の波状線・弧線または円形などを組み合わせた精密な幾何学的模様に変換する。
このときの模様を「彩紋」と呼称し、彩紋図形９２として図示する。
かかる彩紋図形は、彩紋ＩＤ９２’のそれぞれに基づいてすべて異なるように構成された固有の図柄であり、従って彩紋形成手段８１は、ＩＤ情報のそれぞれによって異なる固有の彩紋図形を形成する。
彩紋は、本実施形態では、６桁〜８桁の英数字によって定められる基本図形の集合であり、利用者Ｐや第３者が彩紋図形９２を見たときに、容易に番号を類推することができないように図案化されている。
かかる構成により、彩紋図形９２を第３者が盗み見たとしても、偽造や複製が困難である。

なお、かかる彩紋図形９２の生成手段や印刷方法については、例えば０〜９の十種類の特定形状の基本彩紋図形のパターンを、桁数による特定の位置に、特定の大きさで重ね合わせて形成する等の方法が考えられる。
また、既に挙げた特願２０１６−０１６２４３に示すような印刷方法によって印刷されるものであっても良い。

彩紋発行サーバー８０は、かかるＱＲコード９１と、ＱＲコード９１の周囲を囲繞するように形成された彩紋図形９２とを、一体の図案である認証用画像として機能する認証図柄９３としてシート９０の紙面に印刷する。

シート９０には、例えば認証図柄９３の他、利用者Ｐの送付先住所、氏名、かかる認証図柄９３の有効期限や、認証方法の案内などを記載しても良い。
また、例えば利用者Ｐ本人が申請情報Ｒの申し込み時に入力したＰＩＮコードのようなパスコードを本人確認用に記載しても良い。
すなわち、シート９０は本実施形態では、相互認証システム１００に用いられる認証用記録媒体として機能する。

発行者Ｑは、かかる彩紋発行サーバー８０の出力した郵送物たるシート９０を、利用者Ｐへと郵送により送付する。
このように、シート９０を申請情報Ｒで指定した場所に送付することで、カードの審査項目に必要な、申請した利用者Ｐ本人が、登録した住所・氏名の人物であることの確認を行うことができる。
なお、ここでは郵送としたが、その他の方法であっても良い。また、本実施形態においては、クレジットカードの申請処理であるために、郵送として、印刷物であるシート９０を利用者Ｐに届ける方法としているが、本人確認をもっと緩くしても良い場合には、例えば認証図柄９３を電子メール等で送付する形式であっても良い。

認証サーバー６０は、認証図柄９３の画像から彩紋図形９２を識別するための彩紋判別手段６１と、彩紋判別手段６１が識別した彩紋図形９２が正当なものであるかどうかを判別する彩紋認証手段６２と、を有している。
認証サーバー６０は、トークン発行部５２が発行したトークンが記録されているトークンデータベース６３と、トークンデータベース６３とＱＲコード９１とを用いてＱＲコード９１の正当性を認証するＱＲコード認証手段６４と、を有している。

彩紋判別手段６１は、ＱＲコード９１と彩紋図形９２とが同一の画像に収まった画像データから、彩紋図形９２とＱＲコード９１とを分解して識別する画像認識手段である。
例えば、図６に示したような認証図柄であれば、ＱＲコード９１の４隅に配置された識別子を用いて、ＱＲコード９１を読み取り、かかる画像データのうち、ＱＲコード９１以外の部分を用いて彩紋図形９２を識別する。

さて、かかる郵送されたシート９０を用いて相互に認証する仕組みについて図７、図８を用いて説明する。

図７に示すように、シート９０が利用者Ｐの手元に届けられた時点で、金融機関の認証に必要な条件である、「住所」と「利用者Ｐ」が正当であることが確認される。
利用者Ｐは、まずシート９０を手持ちの携帯端末１０１にインストールされたアプリ１０２を用いて撮影する。
このとき、利用者Ｐは、認証図柄９３のうち少なくとも一部が同一の画像に収まるように撮影し、画像データ９４を取得する（ステップＳ１０１）。なお、「少なくとも一部」とは認証図柄９３の認証が通る範囲で適宜設計されて良いが、ＱＲコード９１の四隅に配置された識別子が全て入ること、彩紋図形９２の１／４以上を含むこと、の２点を満たしていることが望ましい。
彩紋図形９２は、周期性を持つため、全体の１／４以上があれば彩紋ＩＤ９２’を判別可能である。

また、ステップＳ１０１において、例えばアプリ１０２がその機能として、郵送されてきた紙自体が、間違いなく発行者Ｑのものであるかどうかを識別するとしても良い。
具体的には、例えばシート９０自体に微小な彩紋や、識別用の図形等を印刷し、かかる識別用の彩紋を認識したことを条件として、認証図柄９３の認識を行うこととしても良い。
かかる構成によれば、例えば第３者が発行者Ｑに成りすましてシート９０の類似品を送付したときにも、利用者Ｐに不要なアクセスをさせることがないという利点がある。

アプリ１０２は、画像データ９４を撮影すると、ＱＲコード９１を読み取る（ステップＳ１０２）。
既に述べたように、ＱＲコード９１にはアクセス先として認証サーバー６０のＵＲＬが指示されているから、アプリ１０２は、かかる指示に従って該当するＵＲＬ（認証サーバー６０）に接続する。
このとき、接続先のＵＲＩは、ＪＷＴがハッシュ化されたhashコードを含んでいるから、利用者Ｐに固有の接続先である。
アプリ１０２は、次いで画像データ９４を認証サーバー６０に送信する（ステップＳ１０３）。
認証サーバー６０は、画像データ９４について、彩紋判別手段６１を用いて彩紋図形９２とＱＲコード９１とに分解して識別する（ステップＳ１０４）。

彩紋認証手段６２は、彩紋形成手段８１が形成したのと逆の操作により、彩紋図形９２の周期性と形状の組み合わせに基づいて、６〜８桁の彩紋ＩＤ９２’を復号する。言い換えれば分解された彩紋図形９２は、彩紋認証手段６２によって、彩紋図形９２から彩紋ＩＤ９２’へと逆変換される（ステップＳ１０５）。

ステップＳ１０４において分割されたＱＲコード９１については、彩紋認証手段６２による認証と並行してＱＲコード認証手段６４によって、ＱＲコード９１自体の認証が進められる。
ＱＲコード認証手段６４は、ＱＲコード９１の読み取りを行い、得られたhashコードと、トークンデータベース６３に記録された対応するＪＷＴを、彩紋ＩＤ９２’を鍵として用いて署名したものと比較する（ステップＳ１１０）。
かかる比較によって、画像データ９４すなわち利用者Ｐに届いたシート９０に記載された彩紋図形９２と、ＱＲコード９１との組み合わせが、登録サーバー５０において記録された登録情報Ｒ’と対応する組み合わせであるか否かを、登録情報Ｒ’を参照することなく判別できる。

この点について具体的に説明する。
登録サーバー５０に登録された登録情報Ｒ’は、様々な個人情報を含んでいるが、かかる登録情報Ｒ’をそのまま登録サーバー５０と認証サーバー６０との間で送受信することは、途中経路での読み取りなど不要なセキュリティリスクを生じる。
そこで、本実施形態では、登録情報Ｒ’に基づいてＪＷＴを生成するとともに、彩紋ＩＤ９２’を鍵として、ＨＭＡＣでＪＷＴを署名した結果をさらにハッシュ化してhashコードとしている。
かかるhashコードは、ＱＲコード９１の接続先であり、ＱＲコード９１から復元可能である。
ここで、アプリ１０２が、前記のhashコードにアクセスした時点でＪＷＴ本体をダウンロードする処理とすれば、ＱＲコードから読み取ったＵＲＩに含まれるhashコードと、ＵＲＩからダウンロードしたＪＷＴ本体のハッシュとを比較・確認することで、利用者Ｐ側においても、認証サーバー６０にあるＪＷＴ本体が改ざんされていないことが確認できる。
なお、かかる比較はやらなくても良い。その場合にはアプリ１０２は後述する認証の可否のみを受け取ればよく、ＪＷＴ本体をダウンロードする必要がなくなるから、ＪＷＴの送受信が不要になってＪＷＴのエンティティを不正取得されないというメリットがある。

さて、彩紋ＩＤ９２’を鍵として、ＨＭＡＣを用いてＪＷＴを署名すると、ＪＷＴから得られたハッシュ値であるhashコードからは、元の情報を復元することができない。
なおこのときＪＷＴは、利用者Ｐ自身が登録サーバー５０に送信した登録情報Ｒ’を含むトークンである。

登録情報Ｒ’に基づいて生成されたエンティティを同様の手順によって彩紋ＩＤ９２’によって署名すると、同一のトークンを得ることができるため、ハッシュ値が同一であることにより、ＨＭＡＣの際に署名に用いられた彩紋ＩＤ９２’と、トークンとの組み合わせが正当であることを認証できる。

従って、認証サーバー６０は、ＪＷＴを登録サーバー５０から受け取り、トークンデータベース６３に記録している。
トークンデータベース６３には、ＪＷＴが記録されているから、トークン認証手段６２がステップＳ１１０の操作を行うことで、利用者Ｐの持つシート９０と、登録情報Ｒ’から得られたＪＷＴとが正当なものであることを認証できる。

認証サーバー６０は、彩紋認証手段６２の彩紋認証ステップであるステップＳ１０６と、ＱＲコード認証手段６４のＱＲコード認証ステップであるステップＳ１１０とが何れも正当であると承認されたかどうかを判別する（ステップＳ１２０）。
ステップＳ１２０において、何れも正当であると認証されたことを条件として、認証サーバー６０は、認証された旨の結果を携帯端末に返すとともに、指示コード６５を携帯端末に送信する（ステップＳ２０１）。
なお、ステップＳ１２０において、正当なものではないと判断された場合には、認証不可の旨を携帯端末に返す（ステップＳ１２１）。

指示コード６５は、本実施形態では、発行者Ｑが管理する登録サーバー５０あるいは特定の電話番号に対して電話をかけるように指示するためのコードである。
ステップＳ２０１において、アプリ１０２が指示コード６５を受信すると、アプリ１０２から特定の電話番号に電話をかけ、電話口において登録時に利用者Ｐが入力したＰＩＮコードの入力を求められる（ステップＳ２０２）。
ステップＳ２０２において、金融機関の登録条件において必要とされる、利用者Ｐの電話番号が利用者Ｐ本人のものであるかどうかの確認を行うことができる。
かかる構成により、利用者Ｐの電話番号の確認が必要な場合には、かかる処理を入れることで、同時に利用者Ｐ本人の電話番号からかけられたかどうかの確認を行うことができる。

なお、ステップＳ２０１以降のステップについては、金融機関の登録条件として電話番号が要求されるために、相互認証システムで行うものとしたが、かかる登録条件は、それぞれの分野に合わせて適宜変更して良い。
なお、ここではＰＩＮコードを登録時に利用者Ｐ本人が入力したものとしたため、シート９０にはかかるＰＩＮコードを記載する必要がなくなり、さらにセキュリティに配慮した状態で金融機関の登録が可能となる。

また、かかるシート９０を戸籍に登録された有権者の住所に配布すれば、認証が成立したことを条件として電子投票に用いる投票券とすることもできる。かかる構成によれば、ＪＷＴのワンタイムキーによって電子投票による複数投票を容易に検知できるとともに、通常の投票券への引き換えには従来通り引換所にて確認を行えばいいので、利用者Ｐの手間が軽減される。

本実施形態では、彩紋ＩＤ９２’のそれぞれによって異なる固有の彩紋図形を形成する彩紋形成手段８２と、各文字列に対応した基本彩紋図形の組み合わせパターンを用いて彩紋図形９２から彩紋ＩＤ９２’を復号する彩紋判別手段６１と、彩紋判別手段６１によって復号された彩紋ＩＤ９２’が、ＱＲコードに含まれた発行者情報と対応するものであるか否かを判別する認証手段６０と、を有している。
かかる構成により、セキュリティリスクを増大させることなく、簡易に本人認証を行うことができる。
また、利用者Ｐは、認証図柄９３を撮影した画像データ９４を送付するだけで良いため、認証時における操作の煩雑さを軽減することができる。

本実施形態では、二次元コードとしてＱＲコードを用いる。かかる構成により、読み取りの速度が向上して利便性を向上させつつも、読み取りを行うだけでは認証が行われないため、第３者がシート９０を盗み見たとしても、セキュリティ上問題にならず、セキュリティリスクを低減する。

また本実施形態では、ＱＲコード９１は、発行者情報を含んだトークンに基づいて形成される。
かかる構成により、発行者Ｑの情報を含めて改ざんを行うとトークンによる認証が通らなくなるので、セキュリティが強化される。

また、本実施形態では、ＪＷＴには読み取り回数を制限する回数制御機能を付加している。
かかる構成により、例えば既に使われたシート９０が、再度用いられて認証サーバー６０の認証を通そうとしたときにも、複数回登録による警告画面を表示するなどの対策が可能となる。

また、本実施形態では、認証サーバー６０は、彩紋ＩＤ９２’を鍵として、ＱＲコード９１に記載された発行者Ｑの情報を含むＪＷＴを署名したものであることを認証する。
かかる構成により、発行者Ｑの情報が改ざんされている場合にも認証が通らなくなるため、偽装に対してセキュリティが強化される。

また本実施形態の相互認証システムは、ＱＲコード９１と、彩紋図形９２とが一体に形成された認証図柄９３と、認証図柄９３が印刷されたシート９０と、を用いて認証するものである。
認証サーバー６０は、認証図柄９３を撮影することでシート９０が正当なものであることを確認する。
かかる構成により、利用者Ｐは認証図柄９３の撮影のみで利用者Ｐ宛に届いた郵便物が真正なものであるとの認証を行うことができて、セキュリティ向上と利便性の向上とを両立できる。

また本実施形態では、認証図柄９３は、ＱＲコード９１と、彩紋図形９２とが一体に形成され、彩紋図形９２は、ＱＲコード９１の周囲を囲繞するように形成される。
かかる構成により、撮影時に同一の画像内にＱＲコード９１と彩紋図形９２とを認識できない場合には認証が失敗するので、全く同一の複製物でない限り認証が通らないので成りすまし等のセキュリティリスクを低減することができる。

本発明の第２の実施形態として、認証サーバー６０を用いない形態についても説明する。
本実施形態では、相互認証システム２００は、図９に示すように、データオブジェクトのハッシュを用いてアドレスを決定する、ＩＰＦＳ（InterPlanetary File System）という分散ファイル管理システムを用いた相互認証システムである。

相互認証システム２００は、第１の実施形態と同様の構成を有するが認証方式だけが異なっている。
ＩＰＦＳ方式の分散ファイル管理システムにおいては、利用者Ｐが登録サーバー５０に申請情報Ｒを記録すると、登録サーバー５０が申請情報Ｒに発行者Ｑの情報を付加して、登録情報Ｒ’を生成する。
また、トークン発行部５２は、かかる登録情報Ｒ’に基づいて、第１の実施形態と同様に発行者Ｑの情報を含んだ形で、彩紋ＩＤ９２’で署名されたＪＷＴを発行する。
かかるＪＷＴが生成されると同時に、ＪＷＴをハッシュ化したハッシュ値がアドレスとなるから、彩紋ＩＤ９２’を含んだ登録情報Ｒ’を生成することで、彩紋ＩＤ９２’もしくはＱＲコード９１が分からない限り、当該アドレスにはたどり着けないことになる。

利用者Ｐがアプリ１０２を用いて彩紋図形９２とＱＲコード９１とを撮影すると、まずＱＲコード９１が読み込まれて、第１の実施形態と同様にＪＷＴがハッシュ化されたhashコードが生成される。
かかるhashコードは、トークン発行部５２が発行したＪＷＴの本体のアドレスそのものであるから、アプリ１０２は、かかるＪＷＴのアドレスへ接続してＪＷＴ本体をダウンロードすることができる。

相互認証システム２００は、画像データ９４から彩紋ＩＤ９２’を復号するとともに、ＱＲコード９１の指定するアドレスに置いてあるＪＷＴ本体を当該彩紋ＩＤ９２’で署名したものと、当該アドレスとが一致するかどうかを判断する。
一致する場合には、携帯端末にかかるアドレスにおいてあるＪＷＴ本体を送信し、一致しない場合には認証が為されなかった旨をアプリ１０２に表示する。
係る判断は、第１の実施形態におけるステップＳ１２０と同様の行為であり、相互認証システム２００自体が認証手段としての機能を有することとなる。
このような方法により、ＪＷＴが生成されると同時に外部からは類推不可能なアドレスに登録情報Ｒ’が格納され、当該アドレスにアクセス可能なのは、シート９０を所持する利用者Ｐのみであるため、利用者Ｐが正当なユーザーであることを認証できる。

なお、本実施形態では、かかる認証手段を、ＩＰＦＳのファイルシステム自体が行っているが、ハッシュによってアドレスが決定され、彩紋ＩＤに相当するＩＤ情報によって署名される仕組みでさえあればよい。具体的には例えばブロックチェーン等の分散台帳システムであっても、同様の認証システムが成立する（、ブロックチェーンのＩＰＦＳ実装については、非特許文献１を参照）。

また、本発明の変形例として、彩紋図形９２とＱＲコード９１とを用いたポイント付与システムについても説明する。なお、以降の説明において、第１の実施形態と重複する部分については、同一の符号を付して説明を省略する。

ポイント付与システム３００は、第１の実施形態と同様に、ＱＲコード９１と、彩紋図形９２とが一体に印刷されたシート９０を用いる認証システムである。
ポイント付与システム３００は、登録情報Ｒ’を用いてＪＷＴ等のトークンを発行するトークン発行部５２と、彩紋発行サーバー８０と、認証サーバー６０と、を有している。

なお、本変形例においては、登録情報Ｒ’は例えば、売れた店舗や品物、値段等の情報により作成された商品情報であり、彩紋ＩＤ９２’を含んでいる。

彩紋発行サーバー８０は、彩紋ＩＤ９２’のそれぞれによって異なる固有の彩紋図形を形成する彩紋形成手段８１と、登録情報Ｒ’に基づいて第１の二次元コードを発行する二次元コード生成手段８２とを有している。

ポイント付与システム３００は、利用者Ｐが店舗あるいはネットショップ等で買い物をしたときに、利用者Ｐに送付されるレシート等の納品書としてのシート９０を送付する。

このようなポイント付与システムにおいては、従来、例えば商品にポイントコードが記載された印刷物を同封して、利用者Ｐにかかるポイントコードを入力させるものが知られている。
また、店頭販売においては、利用者Ｐが予め所持していたポイントカードを提示するものも知られている。
一方で、こういったポイントコードでは、入力の手間がかかることや、ポイントカードを所持していなければならず利用者Ｐの利便性が低いといった欠点がある。
また、このとき本人認証を行わないとすれば、偽造や成りすましによるポイントの不正取得に対して何も対処できないため、現実的ではない。
また他方、本人認証を厳密に行おうとすると、利用者Ｐは、認証の為だけに本来しなくても良いはずの個人情報の入力を要求されることとなり、セキュリティリスクが却って高まってしまうという問題もあった。

そこで、本実施形態のポイント付与システム３００では、納品書にＱＲコード９１と、彩紋図形９２とが一体に印刷されたシート９０を用いることで、アプリ１０２を用いた撮影のみで認証が完了するような相互認証システムの提供を目的とする。

シート９０を利用者Ｐがアプリ１０２を用いて撮影すると、アプリ１０２はＱＲコード９１を読み取って、認証サーバー６０へ撮影された画像データ９４を送信する。
認証サーバー６０は、ＱＲコード９１と彩紋ＩＤ９２’とが正当な組み合わせであるかどうかを、第１の実施形態のステップＳ１０１〜Ｓ１２０に従って認証する。
かかる構成によれば、ネットショッピングで予めポイントカードなどの情報を入力させることなく、商品を受け取った本人だけにポイントを付与することができるから、利便性が向上する。

また、ＱＲコード９１にＪＷＴを用いているから、発行者Ｑの偽装や、有効期限の改ざんも難しく、セキュリティリスクを低減することができる。
また、携帯端末にインストールされたアプリ１０２を用いているので、付与されたポイントをアプリ１０２と紐づけて管理すればよいため、個人情報の入力が不要となり、利用者Ｐの利便性を向上させつつも、不要な個人情報の入力というセキュリティリスクを低減することができる。

以上本発明の好ましい実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、上述の説明で特に限定していない限り、特許請求の範囲に記載された本発明の趣旨の範囲内において、種々の変形・変更が可能である。

本発明の実施の形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施の形態に記載されたものに限定されるものではない。

５０ 登録サーバー
６０ 認証手段（認証サーバー）
８０ 彩紋発行サーバー
８１ 彩紋形成手段
８２ 二次元コード生成手段
９０ 記録媒体（シート）
９１ 第１の二次元コード（ＱＲコード）
９２ 彩紋図形
９２’ ＩＤ情報（彩紋ＩＤ）
９３ 認証図柄
１００ 相互認証システム
２００ 相互認証システム
３００ 相互認証システム（ポイント付与システム）
Ｒ 申請情報
Ｒ’ 登録情報（発行者情報を含む）

Claims (11)

1. 発行者情報を含んだ二次元コードと、
   利用者が申請した当該利用者自身の情報を含む申請情報と、
   前記申請情報と紐づけられて、複数の文字列を組み合わせて構成されるＩＤ情報と、
   を用いて、発行者と利用者とが正当であることを互いに認証するための相互認証システムであって、
   前記ＩＤ情報のそれぞれによって異なる固有の彩紋図形を形成する彩紋形成手段と、
   各文字列に対応した基本彩紋図形の組み合わせパターンを用いて前記彩紋図形から前記ＩＤ情報を復号する彩紋判別手段と、
   前記彩紋判別手段によって復号された前記ＩＤ情報が、前記二次元コードに含まれた前記発行者情報と対応するものであるか否かを判別する認証手段と、を有することを特徴とする相互認証システム。
2. 請求項１に記載の相互認証システムにおいて、
   前記二次元コードとしてＱＲコードを用いることを特徴とする相互認証システム。
3. 請求項２に記載の相互認証システムにおいて、
   前記ＱＲコードは、発行者情報を含んだトークンに基づいて形成されることを特徴とする相互認証システム。
4. 請求項３に記載の相互認証システムであって、
   前記トークンには読み取り回数を制限する回数制御機能を付加したことを特徴とする相互認証システム。
5. 請求項３または４に記載の相互認証システムであって、
   前記認証手段は、前記ＩＤ情報を鍵として、前記二次元コードに記載された前記発行者情報を含む前記トークンを署名したものであることを確認して認証する特徴とする相互認証システム。
6. 請求項５に記載の相互認証システムであって、
   前記認証手段として、前記トークンが前記ＩＤ情報によって署名されることでアドレスが決定する分散ファイル管理システムを用いることを特徴とする相互認証システム。
7. 請求項１乃至６の何れか１つに記載の相互認証システムであって、
   前記彩紋形成手段は、前記ＩＤ情報を構成する各文字列に対応する基本彩紋図形の組み合わせパターンを重ね合わせて前記彩紋図形を形成することを特徴とする相互認証システム。
8. 請求項１乃至７の何れか１つに記載の相互認証システムであって、
   前記二次元コードと、前記彩紋図形とが一体に形成された認証用画像と、当該画像が印刷された記録媒体と、を用い、
   前記認証手段は、前記認証用画像を撮影することで前記記録媒体が正当なものであることを確認する相互認証システム。
9. 請求項８に記載の相互認証システムにおいて用いられる認証用画像であって、
   当該認証用画像は、前記二次元コードと、前記彩紋図形とが一体に形成され、
   前記彩紋図形は、前記二次元コードの周囲を囲繞するように形成されることを特徴とする認証用画像。
10. 請求項９に記載の認証用画像を印刷された記録媒体。
11. 請求項１乃至８の何れか１つに記載の相互認証システムであって、
    前記認証手段は、少なくとも前記二次元コードと、前記彩紋図形の一部とを同一の画面で撮影された認証用画像を用いて認証を行うことを特徴とする相互認証システム。

Images