JP6760631B1 - 認証リクエストシステム及び認証リクエスト方法 - Google Patents

Abstract

【課題】認証対象の所有物が増えてもサービスシステムによる認証処理の処理負荷を増やさないようにする。【解決手段】第１の情報を持ちユーザに発行された第１の所有物と、ユーザの情報処理端末である第２の所有物にインストールされるアプリとが備えられる。ユーザに発行された第２の情報が第２の所有物に格納される。アプリが、第１の所有物から第１の情報を読み取る。アプリが、複数所有物がそれぞれ持つ複数の情報（読み取られた第１の情報と格納されている第２の情報とを含む）を用いて情報を生成する。アプリが、当該生成された情報を受信情報（サービスシステムから受信した情報）に対する処理で用いることで、サービスシステムによる認証処理において検証される情報である対象情報を生成する。アプリが、対象情報が関連付けられた認証リクエストをサービスシステムに送信する。【選択図】図３

Description

本発明は、概して、認証技術に関する。

１要素認証や多要素認証が知られている。多要素認証の一例が、２要素認証である。２要素認証の技術は、例えば特許文献１に開示されている。

特許第６１９９５０６号公報

１要素認証でも多要素認証でも、一般に、記憶情報としてパスワードが採用されている。しかし、パスワードは、記憶情報なので、忘れられてしまうことがある。また、記憶情報としてのパスワードは、漏洩する（盗られる）ことがあり、且つ、通常、ユーザは、パスワードが漏洩し（盗られ）ても、被害があるまで気づくことができない。

本願発明者が鋭意検討した結果、記憶情報を不要としても安全性を維持する認証方法の一つとして、ユーザの複数の所有物を認証するとの知見を得るに至った。

複数所有物の確認は、人間によって行われる業務プロセスの中で人間によって行われることがある。例えば、銀行のような所定の機関において、所定の用紙にユーザが印章を押すことで形成された印影と、ユーザの印鑑証明書との比較が人間により行われることがある。また、例えば、不在配達証明の所有者が不在配達証明を郵便局に持参した場合、局員は、不在配達証明の他に当該所有者の身分証（例えば、運転免許証又は健康保険証）を確認することがある。

このように、所有物を複数とした場合、複数所有物の各々が個別に確認される。このため、サービスシステムでの認証に複数所有物の認証を適用した場合、サービスシステムは、複数所有物の各々を個別に認証することになる。

しかし、そうすると、サービスシステムの処理負荷は、認証対象の所有物が多い程大きくなる。

第１の情報を持ちユーザに発行された第１の所有物と、ユーザの情報処理端末である第２の所有物にインストールされるアプリとが備えられる。ユーザに発行された第２の情報が第２の所有物に格納される。アプリが、第１の所有物から第１の情報を読み取る。アプリが、複数所有物がそれぞれ持つ複数の情報（読み取られた第１の情報と格納されている第２の情報とを含む）を用いて情報を生成する。アプリが、当該生成された情報を受信情報（サービスシステムから受信した情報）に対する処理で用いることで、サービスシステムによる認証処理において検証される情報である対象情報を生成する。アプリが、対象情報が関連付けられた認証リクエストをサービスシステムに送信する。「複数所有物がそれぞれ持つ複数の情報」は、第１の所有物から読み取られた第１の情報と、第２の所有物に格納されている第２の情報といった二つの情報でもよいし、当該二つの情報の他に、第１の所有物及び第２の所有物以外の一つ以上の所有物がそれぞれ持つ一つ以上の情報を含んでもよい。

なお、「所有物」しての物の所有権を必ずしもユーザが持たなくてもよい。例えば、少なくとも一つの所有物（例えば、第１の所有物）はユーザへ貸し出され所定の条件が満たされた場合に所定の返却先に返却される物でもよい。

複数所有物がそれぞれ持つ複数の情報から情報が生成される。サービスシステムからの受信情報に対して当該情報を用いて処理することで得られた情報である対象情報が、サービスシステムへの認証リクエストに関連付けられる。所有物の数に関わらず、サービスシステムは、認証処理において当該対象情報を検証すればよい。このため、所有物が増えてもサービスシステムによる認証処理の処理負荷を増やさないようにすることができる。

実施形態に係るシステム全体の構成を示す。 準備フェーズでの準備処理の流れを示す。 認証アプリ２０１及びサービスシステム１３の機能を示す。 ２段階の認証フェーズを示す。 比較例１に係る認証と種々の情報とを示す。 比較例２に係る認証と種々の情報とを示す。 ケース１に係る認証と種々の情報とを示す。 ケース２に係る認証と種々の情報とを示す。 ケース３に係る認証と種々の情報とを示す。 ケース４に係る認証と種々の情報とを示す。 ケース５に係る認証と種々の情報とを示す。 ケース６に係る認証と種々の情報とを示す。 ケース７に係る認証と種々の情報とを示す。

以下の説明では、「通信インターフェース装置」は、一つ以上の通信インターフェースデバイスでよい。一つ以上の通信インターフェースデバイスは、一つ以上の同種の通信インターフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「メモリ」は、一つ以上の記憶デバイスの一例である一つ以上のメモリデバイスであり、典型的には主記憶デバイスでよい。メモリにおける少なくとも一つのメモリデバイスは、揮発性メモリデバイスであってもよいし不揮発性メモリデバイスであってもよい。

また、以下の説明では、「永続記憶装置」は、一つ以上の記憶デバイスの一例である一つ以上の永続記憶デバイスでよい。永続記憶デバイスは、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）でよく、具体的には、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）、ＮＶＭｅ（Non-Volatile Memory Express）ドライブ、又は、ＳＣＭ（Storage Class Memory）でよい。

また、以下の説明では、「記憶装置」は、メモリと永続記憶装置の少なくともメモリでよい。

また、以下の説明では、「プロセッサ」は、一つ以上のプロセッサデバイスでよい。少なくとも一つのプロセッサデバイスは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサデバイスでよいが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサデバイスでもよい。少なくとも一つのプロセッサデバイスは、シングルコアでもよいしマルチコアでもよい。少なくとも一つのプロセッサデバイスは、プロセッサコアでもよい。少なくとも一つのプロセッサデバイスは、処理の一部又は全部を行うハードウェア記述言語によりゲートアレイの集合体である回路（例えばＦＰＧＡ（Field-Programmable Gate Array）、ＣＰＬＤ（Complex Programmable Logic Device）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサデバイスでもよい。

また、以下の説明では、「ｘｘｘテーブル」といった表現にて、入力に対して出力が得られる情報を説明することがあるが、当該情報は、どのような構造のデータでもよいし（例えば、構造化データでもよいし非構造化データでもよいし）、入力に対する出力を発生するニューラルネットワーク、遺伝的アルゴリズムやランダムフォレストに代表されるような学習モデルでもよい。従って、「ｘｘｘテーブル」を「ｘｘｘ情報」と言うことができる。また、以下の説明において、各テーブルの構成は一例であり、一つのテーブルは、二つ以上のテーブルに分割されてもよいし、二つ以上のテーブルの全部又は一部が一つのテーブルであってもよい。

また、以下の説明では、「ｙｙｙ部」の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよいし、それらの組合せによって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置及び／又はインターフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が一つの機能にまとめられたり、一つの機能が複数の機能に分割されたりしてもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通符号を使用し、同種の要素を区別する場合は、参照符号を使用することがある。

図１は、実施形態に係るシステム全体の構成を示す。

本実施形態において、ユーザ１４の複数所有物は、サービス企業１５（又は、他の所定の機関）からユーザ１４に発行されたカード２８と、ユーザ１４のスマートフォン１１である。スマートフォン１１に後述の認証アプリ（アプリの一例）がインストールされ実行される。認証アプリが、複数所有物がそれぞれ持つ複数の情報を用いて情報を生成し、当該生成された情報をサービスシステム１３からの受信情報に対する処理で用いることで対象情報（サービスシステム１３による認証処理において検証される情報）を生成し、対象情報が関連付けられた認証リクエスト（認証のリクエスト）をサービスシステム１３に送信する。複数所有物は、カード２８及びスマートフォン１１の少なくとも一つに代えて又は加えて、一つ以上の他種の所有物が採用されてもよい。例えば、カード２８及びスマートフォン１１の他に、ＵＳＢ（Universal Serial Bus）メモリのような可搬型の記憶装置がユーザの所有物の一例として採用されてもよい。本実施形態では、説明を簡単にするために、複数所有物は、カード２８及びスマートフォン１１という２つの所有物である。

本実施形態では、多段階認証の一例としての２段階認証が採用される。例えば、スマートフォン１１の認証アプリからの上述の認証リクエストに応答してサービスシステム１３により行われる認証が、１段階目の認証の一例である。１段階目の認証に成功した後に、スマートフォン１１の別アプリ（又は、ＰＣ（Personal Computer）１２のようなスマートフォン１１とは別の情報処理端末）からパスワード（例えば、ワンタイムパスワード、又は、ユーザの記憶情報としてのパスワード）がサービスシステム１３に入力され、当該入力されたパスワードの検証が、２段階目の認証の一例である。２段階目の認証に成功した場合に、サービスシステム１３は、ユーザに対して、サービスシステム１３へのログインを許可したり、サービスシステム１３が提供するサービスの利用を許可したりすることができる。

カード２８は、ユーザ１４に発行された第１の所有物の一例である。カード２８は、磁気カードやＩＣカードといった任意の種類のカードでよい。カード２８は、情報１（第１の情報の一例）を持つ。本実施形態では、カード２８は、二次元バーコード２７を一方の面（例えば表面）に有し、二次元バーコード２７が、情報１を表す。情報１は、二次元バーコード２７として表されることに代えて又は加えて、磁気やＩＣのような、カードが持つ記憶領域に格納されてもよい。

スマートフォン１１は、情報処理端末の一例である。スマートフォン１１に代えて、タブレットＰＣが採用されてもよい。スマートフォン１１は、タッチパネル型ディスプレイ１１１、記憶装置１１３と、通信インターフェース装置１１４と、読取装置１１５と、それらに接続されたプロセッサ１１２とを有する。タッチパネル型ディスプレイ１１１は、入力デバイスと表示デバイスが一体になった装置である。読取装置１１５は、一つ以上の読取デバイスでよい。読取デバイスは、情報１の読取が可能なデバイスであればよく、本実施形態では、二次元バーコード２７を撮影するためのカメラである。読取装置１１５は、カメラに代えて又は加えて、他種の読取デバイス、例えば非接触型のカードリーダを含んでもよい。

スマートフォン１１に、情報２（第２の情報の一例）が格納される。情報１及び情報２の少なくとも一方が、ユーザ１４に固有の情報である。

サービスシステム１３は、本実施形態では一つ以上の物理的な計算機であるが、それに代えて、クラウド基盤のような計算リソース群（複数の計算リソース）上に実現されるシステム（例えば、クラウドコンピューティングのサービスシステム）でもよい。サービスシステム１３は、通信インターフェース装置１３３と、記憶装置１３１と、それらに接続されたプロセッサ１３２とを有する。

サービスシステム１３を管理するサービス企業１５がある。サービス企業１５（又は、他の所定の機関）からユーザ１４にカード２８が発行される。

本実施形態では、準備フェーズと運用フェーズとがある。準備フェーズは、サービスシステム１３が提供するサービスの利用のための準備処理が行われるフェーズである。運用フェーズは、準備処理が完了したユーザ１４がサービスシステム１３の認証処理を経てサービスシステム１３のサービスを利用するフェーズである。

図２は、準備フェーズでの準備処理の流れを示す。

ユーザ１４が、スマートフォン１１（或いはＰＣ１２）のような情報処理端末を通じて、サービスシステム１３に対し、サービスシステム１３が提供するサービスの利用のための申込を行う（Ｓ１）。Ｓ１の申込では、ユーザの氏名、住所、電話番号、メールアドレス及びユーザＩＤのような所定の複数種類の情報項目の各々について、ユーザにより情報がサービスシステム１３に入力される。

Ｓ１においてサービスシステム１３に入力された情報が、必要に応じてサービス企業１５により審査される（Ｓ２）。

ユーザ１４がＳ２の審査にパスした場合、サービス企業１５からユーザ１４に対し、カード２８及び案内用紙２６が郵送される（Ｓ３）。カード２８は、ユーザ１４の認証対象となる所有物であり、情報１（第１の情報の一例）を表す二次元バーコード２７を持つ。案内用紙２６は、所定の案内（説明）と情報２（第２の情報の一例）を表す二次元バーコード２５とを持つ。二次元バーコード２５は、情報２の他に、サービスシステム１３の名称のような他種の情報を表してもよい。

ユーザ１４は、スマートフォン１１に、アプリストア２０（アプリのマーケットプレイス）から、認証アプリ２０１をインストールする（Ｓ４）。

インストールされた認証アプリ２０１はスマートフォン１１において起動される。認証アプリ２０１は、ユーザ操作（スマートフォン１１に対してユーザ１４が行う操作）に応答して、スマートフォン１１のカメラを通じて、案内用紙２６の二次元バーコード２５が表す情報２を読み取る（Ｓ５）。認証アプリ２０１は、読み取った情報２を、認証アプリ２０１が管理する記憶領域（例えば、認証アプリ２０１それ自体の所定のフィールド）に設定する（Ｓ６）。これにより、準備処理が完了し、認証アプリ２０１から認証リクエストをサービスシステム１３に送るための処理を行うことが可能な状態となる。なお、認証アプリ２０１が管理する記憶領域は、スマートフォン１１の記憶装置１１３が提供する記憶領域の一部でよい。

以上の準備処理は一例でよい。例えば、ユーザ１４用のカード２８がユーザ１４に渡りユーザ１４用の情報２がユーザ１４のスマートフォン１１にインストールされた認証アプリ２０１に設定さえされれば、どのような方法が採用されてもよい。例えば、認証アプリ２０１が二次元バーコード２５から情報２を読み取ることに代えて、認証アプリ２０１がサービスシステム１３から情報２を取得することが採用されてもよい。また、例えば、案内用紙２６に掲載されている二次元バーコード２５が情報２を表すことに代えて、人間が理解可能な文字列が情報２を表してもよく、ユーザ１４が、当該文字列を、認証アプリ２０１に手入力してもよい。

また、案内用紙２６が持つ二次元バーコード２５は、情報２の他に、他種の情報、例えばサービスシステム１３の名称及びＵＲＬ（Uniform Resource Locator）を含む情報を表してもよい。認証アプリ２０１は、二次元バーコード２５から読み取った情報を、認証アプリ２０１が管理する記憶領域に設定してよい。
また、準備処理の方法は、全てのサービスや全てのサービスシステム１３に共通でなくてもよい。例えば、認証アプリ２０１に情報２を設定する方法として、第１のサービス（又は、第１のサービスシステム）に関しては、二次元バーコードから読み取られた情報２を設定する方法が採用され、第２のサービス（又は、第２のサービスシステム）に関しては、文字列が表す情報２をユーザ１４が手入力することにより設定する方法が採用されてよい。
同様に、カード２８のような第１の所有物の種類や、情報１を表す方法や、情報１を認証アプリ２０１が取得する方法も、全てのサービスや全てのサービスシステム１３に共通でなくてもよい。

図３は、認証アプリ２０１及びサービスシステム１３の機能を示す。図３において、破線矢印は、準備フェーズでの流れを示し、実線矢印は、運用フェーズでの流れを示す。

認証アプリ２０１は、読取部３０１及び認証リクエスト部３０３を有する。また、認証アプリ２０１は、設定管理テーブル３０２を管理する。設定管理テーブル３０２は、認証アプリ２０１が管理する記憶領域に設定された情報を保持するテーブルである。

読取部３０１は、スマートフォン１１が有する読取装置１１５（図１参照）の一例であるカメラを通じて、案内用紙２６が持つ二次元バーコード２５から情報を読み取ったり、カード２８が持つ二次元バーコード２７から情報を読み取ったりする。読取部３０１は、案内用紙２６が持つ二次元バーコード２５から読み取った情報を、設定管理テーブル３０２に登録する。情報２を含む情報を設定管理テーブル３０２に登録することが、情報２を含む情報を認証アプリ２０１が管理する記憶領域に設定することである。読取部３０１は、カード２８が持つ二次元バーコード２７から読み取った情報（情報１を含む情報）を、認証リクエスト部３０３に渡す。

設定管理テーブル３０２は、サービスシステム１３毎にレコードを有し、レコードが、当該サービスシステム１３に対応した情報（二次元バーコード２５から読み取られた情報）を保持する。当該情報は、情報２の他に、サービスシステム１３の名称及びＵＲＬを含む。このように、本実施形態では、複数のサービスシステム１３Ａ、１３Ｂ、…について認証アプリ２０１を一つとする（共通とする）ことができる。言い換えれば、認証アプリ２０１は、サービスシステム１３毎に用意されてもよいが、本実施形態のように、サービスシステム１３が複数存在しても認証アプリ２０１は１つで済ますことができる。なお、サービスシステム１３毎に、サービスシステム１３のＵＲＬは、案内用紙２６が持つ二次元バーコード２５から読み取られ設定管理テーブル３０２に設定されることに代えて又は加えて、当該サービスシステム１３に対応したカード２８が持つ二次元バーコード２７から読み取られてもよい。いずれにしても、ユーザ１４に送付された正しい情報の一部としてのＵＲＬに従うアクセスが行われるので、偽のサイトに誘い込まれるといったことを防ぐことができる。

認証リクエスト部３０３は、設定管理テーブル３０２を参照し、設定管理テーブル３０２に登録されているサービスシステム名（サービスシステム１３の名称）の一覧であるサービスシステム一覧を、スマートフォン１１のディスプレイ１１１に表示する。サービスシステム名には、サービスシステムのＵＲＬが関連付けられていてよい。認証リクエスト部３０３は、サービスシステム一覧からユーザ所望のサービスシステム名を選択するユーザ操作（例えば、ユーザ所望のサービスシステム１３のサービスシステム名に対するタッチ操作）を受け付ける。認証リクエスト部３０３は、当該ユーザ操作に応答して、ユーザ所望のサービスシステム１３Ａに対する認証リクエストを生成し、生成した認証リクエストを、当該サービスシステム１３Ａに送信する。認証リクエストの生成において、認証リクエスト部３０３は、サービスシステム１３Ａに対応した情報２を設定管理テーブル３０２から取得し、当該情報２と、読取部３０１からの情報１（カード２８が持つ二次元バーコード２７から読み取られた情報１）とを用いて一つの情報を生成する。認証リクエスト部３０３は、当該生成した情報をサービスシステム１３Ａからの受信情報に対する処理に用いることで対象情報を生成し、ユーザＩＤ及び対象情報を関連付けた認証リクエストを生成し、当該認証リクエストをサービスシステム１３Ａに送信する。認証リクエストに関連付けられるユーザＩＤは、下記のうちのいずれでもよい。
・スマートフォン１１に対してユーザ１４から手入力されたユーザＩＤ。
・設定管理テーブル３０２から取得されたユーザＩＤ。（案内用紙２６が持つ二次元バーコード２５が表す、情報２以外の情報が、ユーザＩＤを含んでおり、設定管理テーブル３０２にユーザＩＤが登録されていてよい。）
・読取部３０１から受けたユーザＩＤ。（カード２８が持つ二次元バーコード２７が表す、情報１以外の情報が、ユーザＩＤを含んでおり、認証リクエスト部３０３が、カード２８が持つ二次元バーコード２７から読み取られた情報１及びユーザＩＤを読取部３０１から受けてよい。）

サービスシステム１３において、記憶装置１３１に格納されている一つ以上のプログラムをプロセッサ１３２が実行することで、認証処理部３１１及びサービス提供部３１３が実現される。また、ユーザ管理テーブル３１２が、記憶装置１３１に格納される。ユーザ管理テーブル３１２は、ユーザ毎にレコードを有し、レコードが、ユーザのユーザＩＤと、当該ユーザに対する送信情報（当該ユーザに対して認証処理のために送信された情報）とを保持する。ユーザに対する送信情報が、認証アプリ２０１にとってはサービスシステム１３からの受信情報である。

認証処理部３１１が、認証アプリ２０１から認証リクエストを受信し、当該認証リクエストに応答して、当該認証リクエストに関連付けられている対象情報を検証する認証処理を行う。例えば、認証処理部３１１は、認証処理において、認証リクエストに関連付けられているユーザＩＤに対応した送信情報をユーザ管理テーブル３１２から特定し、特定された送信情報に、認証リクエストに関連付けられている対象情報が適合するか否かを判定してよい。

サービス提供部３１３は、認証処理部３１１の認証処理において認証が成功した場合、認証リクエストの送信元のユーザに対してサービスを提供する。

本実施形態では、認証は２段階である。

図４は、２段階の認証フェーズを示す。

１段階目の認証フェーズでは、サービスシステム１３へ第１の認証リクエストを送信することと（Ｓ４０１）、当該第１の認証リクエストに応答してサービスシステム１３により第１の認証処理を行うこと（Ｓ４０２）、及び、第１の認証処理の結果に従う第１のレスポンスを返すこと（Ｓ４０３）が行われる。

２段階目の認証フェーズでも、サービスシステム１３へ第２の認証リクエストを送信することと（Ｓ４５１）、当該第２の認証リクエストに応答してサービスシステム１３により第２の認証処理を行うこと（Ｓ４５２）、及び、第２の認証処理の結果に従うレスポンスを返すこと（Ｓ４５３）が行われる。

複数所有物認証の認証フェーズは、１段階目の認証フェーズと２段階目の認証フェーズのどちらでもよい。例えば、１段階目の認証フェーズにおいて複数所有物の認証が行われ、当該認証に成功した場合に、２段階目の認証フェーズにおいて、スマートフォン１１及びＰＣ１２のいずれかからユーザＩＤ及びパスワードが関連付けられた第２の認証リクエストが送信されてもよい。或いは、例えば、１段階目の認証フェーズにおいてユーザＩＤ及びパスワードが関連付けられた第１の認証リクエストがサービスシステム１３に送信されて当該パスワードの認証が行われ、当該認証に成功した場合に、２段階目の認証フェーズにおいて、複数所有物の認証が行われてよい。
また、２段階の認証フェーズは、次のように表現されてよい。すなわち、１段階目の認証フェーズは、サービスシステム１３においてユーザ１４に関しclosedの状態の認証シャッター（第２の認証リクエストの受け付けを制御するための論理的なシャッター）をopenの状態に変更するための認証フェーズでよい。２段階目の認証フェーズは、ユーザ１４に関し認証シャッターの状態がopenの場合に当該ユーザ１４について第２の認証リクエストを受け付ける認証フェーズでよい。認証シャッターの状態がopenになってから一定時間経過したら自動的に認証シャッターの状態はclosedとされてよい。認証シャッターの状態がclosedの場合、第２の認証リクエストの受け付けは不可である。

また、必ずしも２段階の認証のような多段階認証が採用されなくてもよい。また、例えば、１段階目の認証フェーズにおける認証リクエストに、２段階目の認証フェーズでの認証処理において検証される情報も関連付けることで、２段階目の認証フェーズでの認証リクエストが不要とされてもよい。

本実施形態では、認証対象の複数所有物は、カード２８とスマートフォン１１である。サービスシステム１３毎に、ユーザ１４に対して発行された情報として、情報１と情報２のように、ユーザ１４の所有物の数に応じた数の情報があり、各々の情報は、いずれかの所有物に保持される。本実施形態では、情報１を、カード２８が持ち、情報２を、スマートフォン１１が持つ。以下の説明において情報１として採用される情報は、情報１として採用されることに代えて情報２として採用されてもよく、同様に、以下の説明において情報２として採用される情報は、情報２として採用されることに代えて情報１として採用されてもよい（つまり、情報１と情報２が逆であってもよい）。ユーザ１４に対して発行された複数の情報の秘密性が異なっている場合、秘密性の高い情報を、スマートフォン１１に格納される情報２とし、秘密性の低い情報を、カード２８が持つ情報１とすることが好ましい。

情報１、情報２及び対象情報（認証リクエストに関連付けられる情報）として採用される情報は様々である。一例として、下記比較例１及び２がある。
・比較例１（図５参照）：情報１が、ユーザの公開鍵証明書である。情報２が、当該公開鍵に対応する秘密鍵である。サービスシステム１３からの受信情報が、何らかの情報である。対象情報が、情報１と、情報２で署名された受信情報である。認証処理では、情報１と署名との各々が検証される。
・比較例２（図６参照）：情報１が、ユーザ証明書Ａ（第１のユーザ証明書）である。情報２が、ユーザ証明書Ｂ（第２のユーザ証明書）である。対象情報が、情報１と情報２である。認証処理では、情報１と情報２との各々が検証される。

比較例１に係る対象情報は、以下の（情報Ｘ）の一例である。比較例２に係る対象情報は、以下の（情報Ｙ）である。
（情報Ｘ）情報１と情報２とのうちの一方の情報をサービスシステム１３からの受信情報に対して用いることで生成された情報と、情報１と情報２とのうちの他方の情報。
（情報Ｙ）情報１と情報２。

比較例１及び比較例２のいずれでも、複数所有物認証それ自体は実現され、故に、ユーザ１４の記憶情報を不要にすることが可能である。

しかし、比較例１及び比較例２のいずれも、二つの所有物のいずれもが正しい所有物であろうという仮定の下、二つの所有物の各々についての情報が検証される。つまり、比較例１及び比較例２のいずれについても、対象情報が、所有物の数に応じた数の情報を含み、情報毎の検証が必要となる。

そこで、本実施形態では、下記の（情報Ｚ）の一例としての情報が、対象情報として採用される。つまり、本実施形態では、二つの所有物のどちらも正しい所有物でないと得られない一つの情報を用いて生成された情報が対象情報とされ、当該対象情報について検証が行われればよい。このため、所有物が増えてもサービスシステム１３による認証処理の処理負荷を増やさないようにすることができる。
（情報Ｚ）情報１と情報２を用いて生成された情報をサービスシステム１３からの受信情報に対する処理で用いることで生成された情報。

具体的には、（情報Ｚ）は、情報１及び情報２を用いて生成された情報を鍵として、サービスシステム１３からの受信情報を暗号化又は復号する、或いは、サービスシステム１３からの受信情報に電子署名を付与することで生成された情報でよい。サービスシステム１３からの受信情報（例えば乱数r）は、認証リクエストがサービスシステム１３に送信された後から（情報Ｚ）が作成される前までの間の任意のタイミングにおいて認証アプリ２０１がサービスシステム１３から受信した情報でよい。また、情報１及び情報２のいずれも、どのような情報でもよい。すなわち、情報１及び情報２のいずれも、（情報Ｚ）を作成するために必要な任意の情報でよい。

図７は、ケース１に係る認証と種々の情報とを示す。

ケース１によれば、情報２が、ck（ユーザ１４の共通鍵）であり、情報１が、Enc_ck(sk)（ckで暗号化されたsk（ユーザ１４の秘密鍵））である。サービスシステム１３からの受信情報が、r（サービスシステム１３により生成された乱数）である。対象情報が、Enc_sk(r)（skで暗号化されたr）である。上述した（情報Ｚ）によれば、認証アプリ２０１は対象情報を次のように生成する。すなわち、認証アプリ２０１は、情報１（Enc_ck(sk)）を情報２（ck）で復号することでskを生成し、rをskで暗号化することでEnc_sk(r)を生成する。サービスシステム１３（ユーザ管理テーブル３１２）は、ユーザ毎に、ユーザＩＤの他に当該ユーザのskを保持している。サービスシステム１３の認証処理部３１１が、認証リクエストに関連付いているユーザＩＤに対応したsk及びrをユーザ管理テーブル３１２から取得する。認証処理部３１１が、認証リクエストに関連付いているEnc_sk(r)を取得したskを用いてEnc_sk(r)からrを復号し、復号されたrを、テーブル３１２から取得されたrを用いて検証する。このように、所有物が複数でも、検証対象の情報は１つのrである。

図８は、ケース２に係る認証と種々の情報とを示す。

ケース１との相違点は、認証アプリ２０１が、skを用いてrを暗号化することに代えて、skを用いた電子署名をrに付与する点と、サービスシステム１３（ユーザ管理テーブル３１２）は、ユーザ毎に、skに代えてpk（ユーザ１４の公開鍵）を保持している点である。このため、対象情報が、Sign_sk(r)（skを用いた電子署名付きのr）であり、認証処理部３１１が、認証リクエストに関連付いているSign_sk(r)から、ユーザＩＤに対応したpkを用いてrを取得し、当該取得されたrを、テーブル３１２から取得されたrを用いて検証する。

ケース１及びケース２は、いずれも、サービスシステム１３の認証処理部３１１が、対象情報に対して処理を施すことで取得された情報を検証することの例である。

別の例として、サービスシステム１３からの受信情報が、サービスシステム１３により発行された情報の暗号化情報（サービスシステム１３により発行された情報に対して何らかの処理が施された情報の一例）であり、認証アプリ２０１が、当該暗号化情報に対して復号処理を行ってもよい。当該別の例の具体例が、ケース３及びケース４である。

図９は、ケース３に係る認証と種々の情報とを示す。

ケース１との相違点は、サービスシステム１３からの受信情報が、Enc_pk(r)（pkで暗号化されたr）である点と、サービスシステム１３（ユーザ管理テーブル３１２）が、ユーザ毎に、skに代えてpkを保持している点である。このため、認証アプリ２０１が、情報１と情報２から得られたskを用いてEnc_pk(r)からrを復号し、当該復号されたrを、テーブル３１２から取得されたrを用いて検証する。すなわち、共通鍵暗号系の場合は、skで暗号化し、skで復号するが、公開鍵暗号系の場合は、pkで暗号化しskで復号する。pkは、秘密鍵skに対応する公開鍵である。

図１０は、ケース４に係る認証と種々の情報とを示す。

ケース１との相違点は、サービスシステム１３からの受信情報が、Enc_sk(r)（skで暗号化されたr）である点である。このため、認証アプリ２０１が、情報１と情報２から得られたskを用いてEnc_sk(r)からrを復号し、当該復号されたrを、テーブル３１２から取得されたrを用いて検証する。

ケース３及びケース４のように、サービスシステム１３からの受信情報が、サービスシステム１３の情報が暗号化された情報であり、認証アプリ２０１は、情報１及び情報２を用いて生成された情報の一例であるskを用いて当該受信情報を復号できた場合に、認証リクエストを生成しサービスシステム１３に送信してよい。言い換えれば、認証アプリ２０１は、情報１及び情報２を用いて生成されたskを用いて当該受信情報を復号できなかった場合、認証リクエストをサービスシステム１３に送信しない（例えば、認証リクエストを生成しない）でよい。これにより、下記のうちの少なくとも一つが期待される。
・サービスシステム１３へ無駄に認証リクエストが送信されないので、ネットワークの通信量を減る。
・復号が失敗した理由の一つとして、サービスシステム１３が不正なサービスシステムであることが考えられるが、そのような不正なサービスシステムに情報を送信してしまうこと。

また別の例として、情報１及び情報２から得られるskは、秘密分散法に従い用意されたsk1及びsk2（いずれもskの要素）から生成されてよい。このような例の具体例が、ケース５乃至ケース７である。

図１１は、ケース５に係る認証と種々の情報とを示す。図１２は、ケース６に係る認証と種々の情報とを示す。図１３は、ケース７に係る認証と種々の情報とを示す。

ケース５乃至ケース７のケース１との相違点は、情報１及び情報２のペアが、下記のうちのいずれかである点である。いずれについても、情報１及び情報２からskが生成される。
・情報１がsk1であり、情報２がsk2である。
・情報１がEnc_ck(sk1)（ckで暗号化されたsk1）であり、情報２が、ckとsk2とのセットである。

ケース１との他の相違点は、これまで説明したケース２〜４のいずれかと同様である。例えば、ケース５では、対象情報は、ケース２のようにSign_sk(r)（サービスシステム１３からの受信情報rに、skを用いた電子署名が付与された情報）でもよいし、それに代えて、Enc_sk(r)又はEnc_pk(r)が採用されてもよい。また、ケース６では、受信情報は、ケース４のようにEnc_sk(r)でもよい。また、ケース７では、受信情報は、ケース３のようにEnc_pk(r)でもよい。

以上、一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。

例えば、第１の所有物は、カード２８に限らず任意の物が採用されてもよい。また、第１の所有物が有する情報１は、二次元バーコードに代えて又は加えて、他種の媒体（例えば、ＩＣ又は可搬型メモリ）から読み取られてもよい。また、情報１の読取方式としては、任意の方式が採用されてよい。

また、例えば、第２の所有物は、スマートフォン１１に限らず任意の情報処理端末が採用されてもよい。例えば、認証アプリ２０１は、スマートフォン１１に代えて、ＰＣ１２にインストールされてもよい。ＰＣ１２にカメラやＩＣカードリーダのような読取装置が接続され、当該読取装置を通じて、情報１及び情報２が読み取られてもよい。

また、例えば、カード２８が、サービスシステム１３のワンタイムパスワードを表示してもよい。認証アプリ２０１が、情報１の他にカード２８が表示しているワンタイムパスワードも読み取ってよい。例えば、ワンタイムパスワードの表示エリアと二次元バーコード２７とがカード２８の同一面にあり、認証アプリ２０１が、カメラの撮影画像から情報１とワンタイムパスワードを取得してもよい。認証アプリ２０１が、当該ワンタイムパスワードをサービスシステム１３に送信してもよい（例えば、ユーザＩＤ及び対象情報の他に当該ワンタイムパスワードを認証リクエストに関連付けてもよい）。これにより、１段階目又は２段階目の認証フェーズにおいてユーザ１４がワンタイムパスワードを手入力する必要が無い。また、なお、カード２８に表示のワンタイムパスワードは、サービスシステム１３との間で同期がとられていて一定時間毎に表示が変更されてもよいし、或いは、カード２８に予め記述されている表（時期とワンタイムパスワードとの関係を表す表）であってもよい。また、ワンタイムパスワードは、所定回数（例えば１回）又は一定期間（例えば１分間）有効なパスワードでよい。ワンタイムパスワードの一般的な目的は、パスワード管理をシステム側が行うことであり、このため、通常、ユーザの手入力が必要となるが、この例では、カメラを通じてカード２８の撮影画像から情報を読み取る複数所有物認証を利用して、ワンタイムパスワードの手入力を不要とすることができる。なお、サービスシステム１３に送信されるワンタイムパスワードは、カード２８から読み取られたワンタイムパスワードに代えて又は加えて、認証アプリ２０１又は別アプリから得られたワンタイムパスワードでもよい。

また、例えば、カード２８が持つ二次元バーコード２７が表す情報（第１の所有物から読み取られた情報の一例）と、案内用紙２６が持つ二次元バーコード２５が表す情報（第２の情報と共に読み取られた情報の一例）との少なくとも一方が、ユーザＩＤとサービスシステム１３のＵＲＬ（Uniform Resource Locator）とを含んでよい。認証アプリ２０１が、読み取られたＵＲＬにあるサービスシステム１３に、読み取られたユーザＩＤが関連付けられた認証リクエストを送信してよい。これによれば、ユーザＩＤの手入力不要に、正しいサービスシステム１３へ正しい認証リクエストを送信することを自動で行うことが期待できる。

また、例えば、スマートフォン１１は、生体認証によりユーザ１４によるユーザ操作を許可してよい。認証アプリ２０１は、認証リクエストの送信先のサービスシステム１３に、ユーザ１４の生体認証が行われたことを表す情報を通知してよい（例えば、当該情報を認証リクエストに関連付けてよい）。

また、例えば、カード２８が持つ二次元バーコード２７から情報を読み取ることは、サービスシステム１３に接続する都度に行われてもよいし、一度生成された対象情報を認証アプリ２０１が保持していて以後の接続（例えば、以後一定期間内での接続）では読み取りが不要とされてもよい。

また、例えば、スマートフォン１１の機種変更が行われた場合、図２に例示の準備処理が機種変更後のスマートフォン１１を用いて行われてもよいが、そのような準備処理を不要にすることができる。具体的には、例えば、カード２８が持つ情報を「A」とした場合、カード２８は、pk=f(A, r)となるAを持つ。pkは、情報１及び情報２から得られるsk（秘密鍵）に対応する公開鍵（又は公開鍵証明書）である。rは、乱数であり、サービスシステム１３（ユーザ管理テーブル３１２）がユーザ毎に持つ。fは、関数であり、例えば排他的論理和である。スマートフォン１１の機種変更（特に、機種変更前のスマートフォンからデータを引き継げない機種変更）が行われる場合、pk’（新しい公開鍵（又は公開鍵証明書））とsk’（新しい秘密鍵）に対してf(A, r’)=pk’となるr’（新しい乱数）をサービスシステム１３（ユーザ管理テーブル３１２）がrの代わりに持つ。

また、例えば、サービスシステム１３（ユーザ管理テーブル３１２）が、ユーザ毎に、最新の（有効な）カードＩＤ（例えば製造番号）又は古い（無効な）カードＩＤを保持してもよい。認証アプリ２０１がカード２８の二次元バーコード２７から読み取った情報は、当該カード２８のカードＩＤを含んでよく、認証アプリ２０１は、認証リクエストに、当該カードＩＤも関連付けてよい。サービスシステム１３の認証処理部３１１は、認証リクエストに関連付いているカードＩＤが、最新のカードＩＤではない場合（或いは、古いカードＩＤに該当する場合）、認証が失敗したと判定してよい。なお、サービスシステム１３（ユーザ管理テーブル３１２）は、更に、カード２８の発行回数を、ユーザ毎に保持してもよい。
また、例えば、ユーザに割り当てられている所有物の個数を「Ｎ」とし、複数所有物認証にパスするために（認証が成功となるために）必要な所有物の個数を「Ｔ」とした場合、必ずしも、Ｎ＝Ｔである必要は無い。準備処理やその後の所有物追加等により、Ｎ個の所有物が１人のユーザ１４に割り当てられ、ユーザ１４の複数所有物の認証は、Ｎ個の所有物のうちのＴ個の所有物の認証でよい（Ｔは、２以上の整数、且つ、Ｔ≦Ｎ）。つまり、ここで、「複数所有物」とは、Ｎ個の所有物のうちのＴ個の所有物を意味してよい。

１１：スマートフォン、１３：サービスシステム、２８：カード

Claims (8)

1. ユーザの複数所有物のうち第１の情報を持ちユーザに発行された第１の所有物と、
   前記複数所有物のうち情報処理端末である第２の所有物にインストールされるアプリと
   を備え、
   前記ユーザのサービス利用申込に対して前記第１の所有物と共に前記ユーザに発行された案内を利用する前記ユーザからの、前記第２の所有物において起動された前記アプリに対するユーザ操作に応答して、前記ユーザに発行された第２の情報が、前記案内又はサービスシステムから、前記第２の所有物における、前記アプリが管理する記憶領域に格納され、
   前記アプリが、
   前記第１の所有物から前記第１の情報を読み取り、
   前記読み取られた第１の情報と前記格納されている第２の情報とを用いて、前記サービスシステムによる認証処理において検証される情報である対象情報を生成し、
   前記対象情報が関連付けられた認証リクエストを前記サービスシステムに送信する、
   認証リクエストシステム。
2. 前記アプリが、
   前記第１の情報及び前記第２の情報を用いて、情報を生成し、
   前記サービスシステムから受信した情報である受信情報に対する処理で前記生成された情報を用いることで、前記サービスシステムによる認証処理において検証される情報である対象情報を生成し、
   前記対象情報は、前記第１の情報及び前記第２の情報を用いて生成された情報を鍵として、前記受信情報を暗号化又は復号する、或いは、前記受信情報に電子署名を付与することで生成された情報である、
   請求項１に記載の認証リクエストシステム。
3. 前記受信情報は、前記サービスシステムの情報が前記ユーザの秘密鍵又は公開鍵を用いて暗号化された情報であり、
   前記アプリは、前記第１の情報及び前記第２の情報を用いて生成された情報である秘密鍵を用いて前記受信情報を復号できなかった場合、前記認証リクエストを前記サービスシステムに送信しない、
   請求項２に記載の認証リクエストシステム。
4. 前記第１の所有物が、前記第１の情報と前記サービスシステムのワンタイムパスワードとを有し、
   前記アプリが、前記第１の情報の他に前記第１の所有物が有するワンタイムパスワードも読み取り、
   前記アプリが、前記対象情報の他に前記ワンタイムパスワードを前記認証リクエストに関連付けて前記サービスシステムに送信する、
   請求項１乃至３のうちのいずれか１項に記載の認証リクエストシステム。
5. 前記第２の情報は、前記第１の情報よりも秘密性の高い情報である、
   請求項１乃至４のうちのいずれか１項に記載の認証リクエストシステム。
6. pk=f(A, r)におけるAが、前記第１の情報であり、
   pkは、前記第１の情報及び前記第２の情報から得られる秘密鍵に対応する公開鍵又は公開鍵証明書であり、
   rは、前記サービスシステムが持つ、前記ユーザに対応した乱数であって、
   fは、関数であり、
   前記第２の所有物の機種変更が行われる場合、pk’とsk’に対してf(A, r’)=pk’となるr’を、前記サービスシステムがrの代わりに持ち、
   pk’は、新しい公開鍵又は新しい公開鍵証明書であり、
   sk’は、新しい秘密鍵であり、
   r’は、新しい乱数である、
   請求項１乃至５のうちのいずれか１項に記載の認証リクエストシステム。
7. 第１の情報を持つ第１の所有物の発行先となるユーザの情報処理端末である第２の所有物に、
   前記ユーザのサービス利用申込に対して前記第１の所有物と共に前記ユーザに発行された案内を利用する前記ユーザからのユーザ操作に応答して、前記ユーザに発行された第２の情報を、前記案内又はサービスシステムから、前記第２の所有物における、管理対象の記憶領域に格納し、
   前記第１の所有物から前記第１の情報を読み取り、
   前記読み取られた第１の情報と前記格納されている第２の情報とを用いて、前記サービスシステムによる認証処理において検証される情報である対象情報を生成し、
   前記対象情報が関連付けられた認証リクエストを前記サービスシステムに送信する、
   ことを実行させるコンピュータプログラム。
8. 第１の情報を持つ第１の所有物の発行先となるユーザの情報処理端末である第２の所有物にアプリが実行されることで、
   前記ユーザのサービス利用申込に対して前記第１の所有物と共に前記ユーザに発行された案内を利用する前記ユーザからの、前記第２の所有物において起動された前記アプリに対するユーザ操作に応答して、前記ユーザに発行された第２の情報を前記第２の所有物における、前記アプリが管理する記憶領域に格納し、
   前記第１の所有物から前記第１の情報を読み取り、
   前記読み取られた第１の情報と前記格納されている第２の情報とを用いて、前記サービスシステムによる認証処理において検証される情報である対象情報を生成し、
   前記対象情報が関連付けられた認証リクエストを前記サービスシステムに送信する、
   ことを実行させる認証リクエスト方法。

Images