JP2018032369A - 認証システム、ならびに、プログラム - Google Patents

Abstract

【課題】アクセス端末からサーバへサインインするためのキーコードを、トークン端末を用いて安全に使用者に提示するのに好適な認証システムを提供する。【解決手段】サーバ１６１は、トークン端末１２１から送られたアクセス情報とサーバ１６１に割り当てられたサイトシードからユーザシードを計算し、トークン端末１２１に登録させる。トークン端末１２１は、サーバ１６１から独立して共有シードを取得し、共有シードとユーザシードからキーコードを計算してユーザに提示する。ユーザがキーコードをアクセス端末１４１に入力すると、アクセス端末１４１は、キーコードが指定された要求をサーバ１６１に送る。サーバ１６１は、送られた要求に係るアクセス情報を取得し、アクセス情報とサーバ１６１に割り当てられたサイトシードから照合シードを計算し、共有シードを取得し、照合コードを計算し、キーコードと照合コードの一致をサインインの必要条件とする。【選択図】図１

Description

本発明は、アクセス端末からサーバへサインインするためのキーコードを、トークン端末を用いて安全に使用者に提示するのに好適な認証システム、ならびに、コンピュータを当該トークン端末、管理装置、もしくはサーバとして機能させるプログラムを記録した非一時的なコンピュータ読取可能な情報記録媒体に関する。

従来から、ワンタイムパスワードをソフトウェアトークンによりユーザに提示する技術が提案されている。

たとえば、特許文献1には、
(1)セキュリティトークンに割り当てられたトークンIDを認証データベースで管理し、
(2)同期サーバは認証データベースから得たトークンIDと現在時刻を組み合わせてシードとして、当該シードからトークンコードを生成し、
(3)情報通信端末はセキュリティトークンから得たトークンIDと現在時刻を組み合わせてシードとして、当該シードからトークンコードを生成し、
(4)情報通信端末を見てユーザが入力したトークンコード(パスワード)が、同期サーバが生成したものと一致するか否かによって認証を行い、
(5)シードとして、トークンIDのほか、ユーザ名やユーザのメールアドレスを利用できる
という技術が開示されている。

また、非特許文献1には、
(1)ユーザが、専用アプリをスマートフォンにインストールし、
(2)ユーザが、専用アプリにメールアドレス(ユーザID)を登録すると、当該メールアドレスが有効であることを確認するためのメールが、当該メールアドレスに届き、
(3)届いたメール内に記載されているコードを、ユーザが、専用アプリに入力すると、メールアドレスの登録が完了し、
(4)ユーザが、サーバに割り当てられたコラボコード(サーバID)を専用アプリに入力すると、専用アプリに登録されたメールアドレスを認証プラットフォームに送り、
(5)認証プラットフォームは、専用アプリから送られたメールアドレスチェックしてから、当該サーバ用のキーコード(パスワード)を専用アプリに伝達し、
(6)キーコードが伝達された専用アプリは、サーバ用のスロットを作り、
(7)当該スロットをタップすると、乱数表内において、キーコードを、ユーザが定めた順序および位置にしたがって乱数表に埋め込んで提示する
という技術が開示されている。

一方で、複数のサービスに対して同じパスワードを設定してしまうユーザも多い。このため、ユーザが設定したパスワードが何らかの原因で流出すると、さまざまなサービスに対する侵入が可能となってしまう。

また、認証に用いるパスワードをユーザに定期的に更新させようとしても、手間がかかることから、更新を怠ったり、簡単なパスワードを設定してしまうことが多い。

このため、特許文献2では、リマインダ端末がパスワードを乱数表に埋め込んで提示し、乱数表の中からユーザが自身で定めた位置および順序で要素を選択すると、選択された要素を並べることによりパスワードが得られ、当該パスワードやユーザ名が、近接通信によりリマインダ端末からアクセス端末へ送られて、サーバへのサインインが行われる技術が提案されている(段落0109-0116等)。

特開2014-229306号公報 特許第5906363号公報

永田一八, ITセキュリティの教科書, 第74頁, マイナビ出版, 2016年1月25日発売

したがって、サービスごとに異なるパスワードが、ユーザ自身が考え出すことなしに、容易に設定されるようにしたり、パスワードを定期的に更新したり、パスワードをワンタイムパスワード化したりしたい、という要望が強い。

一方で、パスワード等の流出を抑制し、個人情報を保護するという観点から、ユーザ情報は、必要最小限だけをサーバに置くこととしたい、という要望がある。

本発明は、上記のような課題を解決するためのもので、アクセス端末からサーバへサインインするためのキーコードを、トークン端末を用いて安全に使用者に提示するのに好適な認証システム、ならびに、コンピュータを当該トークン端末、管理装置、もしくはサーバとして機能させるプログラムを記録した非一時的なコンピュータ読取可能な情報記録媒体を提供することを目的とする。

本発明に係る認証システムは、トークン端末を用いて、サイトシードが非公開に割り当てられたサーバへの、アクセス端末を介したサインインを許可するか否かを、前記サーバが判定するための認証システムである。

まず、本認証システムにおいて、前記トークン端末を使用する使用者が、前記サーバを前記トークン端末へ登録するために、
(a)前記トークン端末は、
前記サーバへサインインするためのアクセス情報を指定され、
前記指定されたアクセス情報を管理装置へ伝達し、
(b)前記管理装置は、
少なくとも、前記伝達されたアクセス情報と、前記サーバに割り当てられたサイトシードと、に、第1関数を適用することにより、前記サーバに対するユーザシードを取得し、
前記取得されたユーザシードを前記トークン端末に伝達し、
(c)前記トークン端末は、
前記伝達されたユーザシードを記録することにより、前記サーバを前記トークン端末へ登録する。

さらに、本認証システムにおいて、前記使用者が、前記サーバが登録された前記トークン端末を用いて、前記アクセス端末を介した前記サーバへのサインインを試行するために、
(d)前記トークン端末は、
前記試行されるサインインに対して前記サーバから独立して取得され、前記サーバと共有されるべき共有シードを取得し、
少なくとも、前記取得された共有シードと、前記記録されたユーザシードと、に第2関数を適用することにより、キーコードを取得し、
前記使用者へ、前記取得されたキーコードを提示し、
(e)前記アクセス端末は、
前記トークン端末により前記使用者へ提示されたキーコードを受け付け、
前記受け付けられたキーコードが指定された要求を、前記サーバへ送信し、
(f)前記サーバは、
前記送信された要求を受信し、
前記受信された要求に係るアクセス情報を取得し、
少なくとも、前記取得されたアクセス情報と、前記サーバに割り当てられた前記サイトシードと、に、前記第1関数を適用することにより、照合シードを取得し、
前記試行されるサインインに対して前記トークン端末から独立して取得され、前記トークン端末と共有されるべき共有シードを取得し、
少なくとも、前記取得された共有シードと、前記取得された照合シードと、に前記第2関数を適用することにより、照合コードを取得し、
前記受信されたキーコードと、前記取得された照合コードと、が一致することを、前記アクセス端末を介した前記要求に係るサインインを許可する必要条件とする。

ここで、管理装置とサーバは、異なるコンピュータにてそれぞれの機能に応じたプログラムを動作させることにより実現することもできるし、一つのコンピュータにて両機能を果たす一つのプログラムを動作させることにより、実現することもできる。

また、トークン端末とアクセス端末は、異なるコンピュータにてそれぞれの機能に応じたプログラムを動作させることにより実現することもできるし、一つのコンピュータにて両機能を果たす一つのプログラムを動作させることにより、実現することもできる。

本発明によれば、アクセス端末からサーバへサインインするためのキーコードを、トークン端末を用いて安全に使用者に提示するのに好適な認証システム、ならびに、コンピュータを当該トークン端末、管理装置、もしくはサーバとして機能させるプログラムを記録した非一時的なコンピュータ読取可能な情報記録媒体を提供することができる。

本発明の実施例に係る認証システムの概要を示す説明図である。 本発明の実施例に係る認証システムにおいてユーザIDを結び付ける際の情報のやりとりの様子を示す説明図である。 本発明の実施例に係る認証システムにおいてトークン端末にサーバを登録する際の情報のやりとりの様子を示す説明図である。 本発明の実施例に係る認証システムにおいてサーバへサインインする際の情報のやりとりの様子を示す説明図である。 本発明の実施例に係るユーザIDの結び付け処理の制御の流れを示すフローチャートである。 ユーザID入力フォームの表示例を示す説明図である。 符丁情報入力フォームの表示例を示す説明図である。 本発明の実施例に係るサーバ登録処理の制御の流れを示すフローチャートである。 コラボコード入力フォームの表示例を示す説明図である。 サインイン処理の制御の流れを示すフローチャートである。 サービス選択フォームの表示例を示す説明図である。 キーコードを直接表示する例を示す説明図である。 キーコードを乱数表に埋め込んで表示する例を示す説明図である。

以下に本発明の実施形態を説明する。なお、本実施形態は説明のためのものであり、本願発明の範囲を制限するものではない。したがって、当業者であればこれらの各要素もしくは全要素をこれと均等なものに置換した実施形態を採用することが可能であるが、これらの実施形態も本発明の範囲に含まれる。

(認証システムの基本構成)
図1は、本発明の実施例に係る認証システムの概要を示す説明図である。以下、本図を参照して説明する。

本実施例に係る認証システム101は、トークン端末121と、アクセス端末141と、サーバ161と、管理装置181と、を備える。

典型的には、複数のサーバ161に対して1台の管理装置181が用意される。ただし、各サーバ161が管理装置181の機能を同時に果たすように構成して、独立した管理装置181を省略することも可能である。

典型的には、トークン端末121としては、スマートフォンやファブレット等の可搬情報端末を使用し、アクセス端末141としては、パーソナルコンピュータやウィンドウシステム用端末等を使用する。ただし、1台のコンピュータにトークン端末121用のプログラムとアクセス端末141用のプログラムとを実行可能にインストールすれば、トークン端末121とアクセス端末141を一体に構成することができる。

このほか、トークン端末121が管理装置181の機能を果たすように構成して、独立した管理装置181を省略し、認証システム101がトークン端末121、アクセス端末141、サーバ161からなるように構成することも可能である。

これらの機器は、インターネット、携帯電話通信網、Wi-Fi(Wireless Fidelity)等の無線LAN(Local Area Network)等のコンピュータ通信網191を介して、相互に通信することができる。なお、サーバ161と、管理装置181と、が独立した機器で構成されている場合、両者の通信には、専用回線を利用することも可能である。また、通信に各種の暗号化を施すことも可能である。

以下では、認証システム101に含まれる2つの要素間での情報のやりとりを通信により行う態様を説明する。なお、当該2つの要素を一体のコンピュータ上に構成する態様では、当該コンピュータ上に実現された各機能を果たすモジュール同士が、当該コンピュータが有するメモリ、レジスタ、記憶装置、記録媒体等を介して、これらの情報のやりとりを行うこととすれば良い。

なお、本図においては、トークン端末121にサーバ161を登録する際に利用される通信経路、ならびに、アクセス端末141からサーバ161へサインインする際に利用される通信経路を点線の両矢印にて図示している。このように、一旦運用が開始された後は、管理装置181とサーバ161の間の通信や、管理装置181とアクセス端末141の間の通信は、行っても良いが、必要ではない点に、本実施形態の特徴の一つがある。

また、後述するようにトークン端末121と、アクセス端末141と、は、たとえばBluetooth(登録商標)のような近接場通信にて情報のやりとりができるようにしても良いし、共通する無線LANのアクセスポイントに接続されていることを条件に、局所通信が実行されることとしても良い。

トークン端末121は、ユーザが各サーバ161へサインインするためのキーコード(パスワード)を当該ユーザに提示する機能を果たす。典型的には、トークン端末121として、各種の携帯端末、たとえば、携帯電話、スマートフォン、タブレット、PDA(Personal Data Assistant)、ウェアラブル端末などを利用することができる。

キーコードの提示の手法は、特許文献1に開示するような当該ユーザのみにわかる形態、すなわち、第三者が盗み見ただけではキーコードが直ちに窃取されることはないような形態としても良いし、キーコードをそのまま提示することとしても良い。

アクセス端末141は、ユーザがサーバ161へサインインして、サーバ161の各種資源を利用し、サービスを受けるための端末である。典型的には、ユーザは、サーバ161へサインインするために、アクセス端末141上で動作するブラウザやターミナルソフトウェアから、サーバ161にアクセスする。アクセス端末141としては、各種の据置き型コンピュータやX端末などのエミュレータ端末を利用することができる。また、アクセス端末141として、トークン端末121と同じ機器を利用することとしても良い。

サーバ161は、ユーザに、資源の利用等、各種のサービスを提供する。サーバ161は、アクセス端末141にてユーザが入力したユーザIDおよびキーコードを、アクセス端末141から取得して、利用の権限を有するか否かの認証を行うことにより、ユーザによる資源の利用の可否を決定する。

サーバ161には、サーバ名が割り当てられる。サーバ名は、サーバ161として機能するコンピュータのサーバID(IDentifier)、たとえば、ホスト名、IP(Internet Protocol)アドレス、ドメイン名、資源を提供する窓口となるURL(Universal Resource Locator)等により表現される。

また、サーバ161には、提供するサービスに応じてサイトシードが割り当てられている。各サイトシードは、当該サイトシードが割り当てられたサーバ161を管理する管理装置181と共有されるが、これら以外の機器に対しては非公開のもので、いわゆる秘密鍵に類似する機能を有する。

管理装置181は、サーバ161にサインインするための情報をトークン端末121に登録する仲立ちをする。また、管理装置181は、トークン端末121に登録されるユーザIDが有効であるか否かの確認を行う。

本態様では、トークン端末121とアクセス端末141を使用するユーザが、1つのユーザIDを共用したり、異なるユーザIDを割り当てたりして、複数のサーバ161にサインインすることができる。また、ユーザ自身が主たる連絡先として使用するメールアドレス等をサーバ161にユーザIDとして明かさずに、容易にサインインすることができる。

なお、アクセス端末141からサーバ161へ送信されたサインインの要求に対して、サーバ161は当該サインインの可否を判定するが、サインインが許可されることによって、サーバ161が提供する各種のコンテンツ提供サービスがアクセス端末141から利用できるようにしても良いし、サーバ161にて動作するシェルプログラムとターミナルプログラムで動作するコマンドラインから対話できるようにしても良いし、サーバ161が管理する各種の資源の利用(たとえば、電子錠の開閉、電子スイッチの切り替え、電気製品に対する制御コマンドの送付等)ができるようにしても良い。

(ユーザIDをトークン端末に結び付ける)
図2は、本発明の実施例に係る認証システムにおいてユーザIDを結び付ける際の情報のやりとりの様子を示す説明図である。以下、本図を参照して説明する。

まず、トークン端末121を管理装置181に管理させ、トークン端末121にユーザ自身のユーザIDを結び付ける手順を説明する。

ユーザは、トークン端末121に、当該トークン端末121にてサインインを管理したいユーザIDを入力する(201)。ユーザIDとしては、メールアドレス、携帯電話番号、固定電話番号、ファクシミリ番号、SNS(Social Network Service)やチャットシステムのユーザ名等、ユーザへの連絡がとれる各種の宛先情報を採用することができる。ユーザIDとしては、ユーザ自身が確実に記憶しているものを採用することが望ましく、今日の多くのウェブサービスでは、ユーザが使用するメールアドレスをユーザIDとして採用している。

入力されたユーザIDは、トークン端末121から管理装置181へ伝達される(202)。

すると、管理装置181は、伝達されたユーザID宛に問合せを送付する(203)。本図では、当該問合せはユーザへ送付されるように図示しているが、問合せメッセージの宛先は、ユーザIDとして採用する連絡先情報に応じて、トークン端末121やアクセス端末141を構成する各種携帯端末やコンピュータ、電話、ファクシミリ装置など、適宜選択される。

問合せには、管理装置181にてランダムに設定した文字列や音声、画像などの符丁情報を指定することが望ましい。また、当該符丁情報には、数分、数時間、あるいは数日程度の時間長の有効期限を設けることが望ましい。ユーザが、問合せに指定された符丁情報をトークン端末121に入力すると(204)、当該符丁情報が指定された回答がトークン端末121から管理装置181へ送付される(205)。

管理装置181は、正しい符丁情報が指定された回答が、問合せから有効期限内にトークン端末121から到着したことをもって、当該トークン端末121にて入力されたユーザIDが有効であることを確認する(206)。

すると、管理装置181は、当該ユーザIDが当該トークン端末121に結び付けられた旨の報告をトークン端末121に送付する(207)。トークン端末121は、有効である旨が管理装置181にて確認されたユーザIDを記録する(208)。そして、以降にサーバへサインインしようとする際のユーザIDとして、当該確認済のユーザIDを選択可能とする。

(サーバをトークン端末に登録する)
ユーザがサーバ161へサインインするために、当該サーバ161をトークン端末121に登録する手順について説明する。図3は、本発明の実施例に係る認証システムにおいてトークン端末にサーバを登録する際の情報のやりとりの様子を示す説明図である。

ユーザは、トークン端末121に対して、サーバ161に割り当てられたコラボコードと、サーバ161へサインインするためのアクセス情報と、を入力する(211)。なお、以下では、理解を容易にするため、サーバ161ヘサインインするためのユーザIDをアクセス情報として利用する例について説明する。アクセス情報に利用できるその他の情報については、後述する。

コラボコードは、登録コードとも呼ばれ、サーバ161ならびにサーバ161にて提供されるサービスを識別するための識別名であり、典型的には、サーバ161の運営者と管理装置181の運営者の間の契約等によって決定され、サーバ161が提供するサービスごとに、異なるコラボコードが割り当てられる。

上記201-207にてトークン端末121に結び付けられたユーザIDからいずれかを、当該サーバ161へのサインイン用に選択することで、当該ユーザIDが入力されたものとすることができる。なお、未だトークン端末121に結び付けられていないユーザIDをユーザが入力した場合には、以下の処理に先立って、上記202-208と同様の処理を実行すれば良い。

すると、トークン端末121は、コラボコードとユーザID(u)を、管理装置181へ伝達する(212)。

すると、管理装置181は、伝達されたコラボコードに対してサーバ161との間で共有されるが他者には非公開であるサイトシード(s)を取得する。そして、管理装置181と各サーバ161との間で共有される第1関数(F)を、伝達されたユーザID(u)と取得されたサイトシード(s)とに適用して、ユーザシード(v)を取得する(213)。
v = F(u,s)

ここで使用する第1関数、ならびに、後述する第2関数(H)には、任意の一方向性関数、ダイジェスト関数、暗号学的ハッシュ関数を含むハッシュ関数等を利用することができる。

第1関数や第2関数を、複数の引数に対して適用する場合には、当該複数の引数を1つの引数にまとめてから上記の一方向性関数等を適用すれば良い。引数をまとめるには、当該複数の引数を所定の順序で並べて所定の区切子で連結したり、各引数の中身の一部または全部を所定の順序で入れ換えたり、あらかじめ定めた文字列(「salt」と呼ばれることがある。)を先頭や末尾に付加したり、等の処理を施せば良い。

なお、第1関数(F)は、トークン端末121やアクセス端末141に対して非公開とすることが望ましい。また、管理装置181と各サーバ161で一つの第1関数を共有するのではなく、各サーバ161ごとに異なる第1関数を利用したり、サーバ161のグループごと(たとえば、グループ企業が運営するサーバ群ごと。)に異なる第1関数を利用することもできる。

管理装置181がユーザシード(v)をトークン端末121へ伝達(214)すると、トークン端末121は、サーバ161の識別名(コラボコード、サーバ名、あるいは、サービス名等。)と、ユーザシード(v)と、を対応付けて、トークン端末121に記録する(215)。ユーザID (u)は、典型的には、ユーザシード(v)およびサーバ161の識別名に対応付けてトークン端末121に記録するが、ユーザが頭の中に記憶するだけでも良い。

これで、1つのサーバ161に対するサインインの準備が整ったことになる。ここまでの手順において、サーバ161側では、ユーザ登録等の処理は一切不要である。また、以降の手順においては、トークン端末121は、他の機器との通信やインタラクションができないオフライン状態であっても、キーコードを提示する処理が可能である。

なお、後述するように、トークン端末161に1個以上のユーザIDが既に結び付けられている場合には、新たなエイリアスを管理装置181に発行させて、これをサーバ161にサインインするためのユーザIDとすることも可能である。この場合、ユーザによるユーザIDの入力(211)は省略され、トークン端末161に既に結び付けられているいずれかのユーザIDが管理装置181へ伝達(212)されて、管理装置181にて伝達されたユーザIDに対するエイリアスが発行され、当該エイリアスを元にユーザシードが計算される(213)。その後、管理装置181からは、ユーザシードとエイリアスとがトークン端末121へ伝達(214)され、これらがトークン端末121に記録される(215)。

(サーバへサインイン)
上記のように、トークン端末121に対してサーバ161の登録がされた後は、ユーザは、トークン端末121を参照することにより、アクセス端末141を介して、サーバ161へのサインインが可能となる。

このサインインにおいては、サインインを試行するユーザが使用するトークン端末121と、サーバ161との間で、当該サインインの試行について共有されるべき共有シードが利用される。共有シードは、正しいユーザによる使用であれば、同じ値を持つことが期待される情報のことである。典型的には、トークン端末121と、サーバ161と、は、共有シードをそれぞれが無連絡で取得する。すなわち、共有シードは、トークン端末121とサーバ161との間の通信やインタラクションは必要とされず、互いに独立して取得されるが、両者にて取得される共有シードは一致する、という性質を有するものである。共有シードとして利用が可能なものには、たとえば、以下のようなものがある。

まず、サインインに使用するユーザIDを、共有シードとすることができる。上記のように、トークン端末121にサーバ161を登録する際に、ユーザIDもトークン端末121に記録されるので、トークン端末121では、これを共有シードとして取得する。一方、サーバ161にサインインしようとする際には、ユーザは、ユーザIDをアクセス端末141を介してサーバ161へ入力する。したがって、サーバ161は、ユーザにより入力されたユーザIDを、共有シードとして取得する。

このほか、サインインの試行が行われている現在の日時を所定の単位で表現した値を、共有シードとすることもできる。トークン端末121と、サーバ161と、は、それぞれ独立して、ユーザがサインインしようといる現在日時を取得し、これを所定単位に揃えることで、同じ値を持つ共有シードを取得することができる。

このほかの共有シードの態様については、後述する。なお、上述のユーザIDならびに現在日時、および、後述する態様を組み合わせて、共有シードとすることも可能である。以下では、理解を容易にするため、ユーザIDと現在日時の組み合わせを、共有シードとして利用する態様を説明する。図4は、本発明の実施例に係る認証システムにおいてサーバへサインインする際の情報のやりとりの様子を示す説明図である。

まず、ユーザは、トークン端末121に登録済みのサーバ161の中から、サインインしようとするサーバの識別名(コラボコード、サーバID等)を選択する(221)。

すると、トークン端末121は、選択されたサーバの識別名に対して登録されたユーザID (u)、ユーザシード(v)、ならびに、所定単位にて表現された現在の日時(d)を取得し、これらに対して第2関数(H)を適用して、キーコード(k)を取得する(222)。
k = H(u,v,d) = H(u,F(u,s),d)

トークン端末121は、サイトシード(s)自体は不知であるが、サーバを登録する際に、ユーザシード(v)を取得するため、結果として、サイトシード(s)に依存するキーコード(k)を得ることができる。

なお、典型的には、第2関数(H)は、認証システム101内の各トークン端末121および各サーバ161に共有されるが、サーバ161ごとに異なるものを採用しても良い。サーバ161ごとに異なる第2関数(H)を利用する場合には、当該第2関数(H)の設定を管理装置181に登録しておき、各サーバ161に対するスロットを作成するときに、管理装置181からトークン端末121へ、使用する第2関数(H)を提供すれば良い。

一般に、暗号学的ハッシュ関数は、
(1)ハッシュ関数の適用結果からハッシュ関数が適用された引数を推定することが困難であり(原像計算困難性)、
(2)異なる引数に対して同じ結果が得られることが極めて稀であって、そのような引数を見つけることが難しい(第2原像計算困難性、強衝突耐性)、
という性質を有することが望ましいとされる。

一方で、第2関数による計算の結果であるキーコード(k)は、後述するように、ユーザがサインイン時に入力する値であるから、合理的な文字列長(たとえば、英数字で4桁乃至8桁)とする必要がある。

したがって、第2関数においては、第2原像計算困難性、強衝突耐性等の要件は緩和するする必要がある。たとえば、第2関数として、「暗号学的ハッシュ関数にて得られたハッシュ値を所定定数で除算した余りを得る演算」を、採用すれば良い。

一方で、第1関数の計算においては、上記の暗号学的な性質を満たすことも可能である。たとえば、引数となる情報を単純に連結した情報のビット数よりも、計算によって得られるハッシュ値のビット数が大きくなるようにしても良い。たとえば、第1関数の適用によって得られるハッシュ値のバイト数を1バイト(=8ビット)増やせば、攻撃者がスキャンしなければならない空間が256倍に増すと考えられるからである。

第1関数ならびに第2関数の一例として採用可能なSHA-3においては、適用結果のビット数を可変とするハッシュ関数(SHAKE128, SHAKE256等。)も採用が可能である。したがって、ユーザID、サイトシードおよび日付の連結長のバイト長よりも長くなるように、適切な一方向性関数を選択することが望ましい。

なお、SHA-2などのハッシュ関数においては、出力長は、512ビット等の固定長である。そこで、適用結果が固定長のハッシュ関数等を複数用意してから元のデータに適用したのち、適用結果を所定の順序で連結したり、要素を所定の規則に応じて入れ換えたりすることで、第1関数の適用結果のビット数を大きくすることができる。また、元のデータの先頭や末尾に所定の異なる文字列(ソルトに相当する。)を付加してから、適用結果が固定長の、1つのハッシュ関数等をそれぞれに適用して、得られた結果を所定の順序で連結したり、連結結果に含まれる要素を所定の規則に応じて入れ換えたりしても良い。さらに、これらの手法を組み合わせることも可能である。

さて、トークン端末121は、計算されたキーコード(k)を、ユーザに提示する(223)。なお、複数のサーバ161に対して異なるユーザIDを使用している場合等に、ユーザがサインインに際して入力すべき情報をわかりやすく提供するため、トークン端末121は、使用されているユーザID(u)をさらに提示しても良い。また、一つのユーザIDが登録済みの全サーバ161について共用されている場合等、ユーザがユーザIDを記憶している場合には、トークン端末121は、ユーザID(u)の提示を省略することもできる。

ユーザは、サーバ161にサインインするためのユーザID(u)と、提示されたキーコード(k)と、を、アクセス端末141で動作するブラウザに表示されたサインインフォームや、ターミナルソフトウェアから発せられたログインプロンプトに対して入力する(224)。

すると、アクセス端末141は、入力されたユーザID(u)とキーコード(k)を、サーバ161に送信する(225)。

ユーザID(u)とキーコード(k)を受信したサーバ161は、所定単位にて表現された現在の日時(e)を取得し、自身が提供するサービスに対して設定されたサイトシード(s)、第1関数(F)、第2関数(H)により、照合シード(w)および照合コード(h)を、以下のように計算する。
w = F(u,s);
h = H(u,w,d) = H(u,F(u,s),e)

ユーザID(u)とサイトシード(s)とが一致していれば、ユーザシード(v)と照合シード(w)とは一致し(v = w)、さらに、トークン端末121における現在日時(d)とサーバ161における現在日時(e)とが所定単位の精度で一致(d = e)していれば、キーコード(k)と照合コード(h)も一致する(k = h)はずである。一方で、ユーザIDや、ユーザシード生成時に参照されたサイトシードや、両日時が不一致であれば、k ≠ hとなる。

そこで、サーバ161は、キーコード(k)と照合コードを対比して、両者が一致することをサインインのための必要条件とし(226)、対比の結果に基づいて、サインインの可否をアクセス端末141に知らせる(227)。サインインに成功した場合には、アクセス端末141を介してユーザとサーバ161との間で、サービスの提供が行われる(228)。

ここで、第1関数および第2関数は、上記の暗号学的性質を有し、ユーザシード(v)は、ユーザID(u)およびサイトシード(s)ごとに異なるから、ある時点でのユーザID(u)とキーコード(k)の組み合わせが漏洩したり、攻撃者が用意したトークン端末141に記録された情報を参照したりしても、サイトシード(s)や第1関数(F)を推測することは困難である。

サーバ161では、ユーザが使用するユーザID以外の個人情報を一切管理しなくとも、ユーザに対するサインインの可否を決定して、サービスを提供することが可能となる。このため、本態様によれば、「ユーザが他のサービスでも共用しているパスワードの漏洩」が生ずることは一切ない。

また、ユーザIDを介した連絡が可能であることは、事前に管理装置181が確認済みであるから、サーバ161にて独自にユーザIDの有効性確認をする必要はない。このため、サーバ161へのサインインに必要なユーザの事前作業は、トークン端末141にてコラボコードを入力し、使用するユーザIDを選択するだけであり、サーバ161における確認の手間、ならびに、ユーザの手間を大幅に削減することができる。

なお、現在日時の取得ならびに第2関数の適用は、省略することとしても良い。この態様では、サーバ161ごとに異なる固定パスワードを容易に配布することができるようになる。固定パスワードを更新するには、新たなサイトシードを設定した上で、ユーザに対して、トークン端末121から管理装置181にアクセスして、サーバの再登録をするか、ユーザIDを変更するよう促せば良い。

また、第2関数が適用される現在日時の単位は、分、時、日、週、月、年など、各種の期間とすることが可能である。単位を短くすれば、従来から使用されているワンタイムパスワードと同様の効果を得ることができ、単位を長くすれば、パスワードの定期更新を自動的に行ってユーザの手間を減らすことが可能となる。

さて、上記の説明では、アクセス情報としてユーザID(u)を採用し、これとサイトシード(s)に第1関数(F)を適用して、ユーザシード(v)ならびに照合シード(w)を計算していた。

ここで、アクセス情報としては、
(1)アクセス端末141からサーバ161へサインイン要求が送られた際に、サーバ161が当該サインイン要求から取得可能であり、
(2)あらかじめ、トークン端末121へサーバ161を登録する際に、ユーザがアクセス端末141から情報を得てトークン端末121へ手入力したり、トークン端末121とアクセス端末141のペアリングを行うことでトークン端末121がアクセス端末141から取得したり、が可能である
という条件を満たす任意の情報を採用することができる。

たとえば、上記のように、ユーザID(u)は、あらかじめユーザが知得しているものであり、ユーザがトークン端末121へ手入力が可能であり、ユーザがアクセス端末141を介してサーバ161へサインインしようとする際に、ユーザが入力する情報であるから、アクセス情報として利用することができる。

このほか、サインイン要求が伝送されるアクセス端末141の端末識別情報を、アクセス情報とすることもできる。たとえば、アクセス端末141がサーバ161と通信する際に自身を識別するためにアクセス端末141に割り当てられたMAC(Media Access Control)アドレス、IPアドレス(グローバルなIPv4アドレス、IPv6アドレス等)、ホスト名、ドメイン名、FQDN(Fully Qualified Domain Name)、IoT(Internet on Things)で利用されるユビキタスな識別子であるucode等を利用しても良い。

また、アクセス端末141とサーバ161の間で電子証明書のやりとりが行われるプロトコルに基づいた通信が行われる場合には、アクセス端末141のクライアント証明書等を、アクセス端末141の端末識別情報とすることもできる。

これらの端末識別情報は、サインイン要求を伝達するための通信が確立されると、サーバ161がアクセス端末141から取得される情報である点で、ユーザが指定するユーザIDとは異なる。

上記のように、アクセス端末141を識別する端末識別情報をアクセス情報として採用した場合には、ユーザシード(v)および照合シード(w)も、端末識別情報に依存することになる。したがって、トークン端末121にサーバ161を登録する際に設定されたアクセス端末141を介してであれば、トークン端末121から提示されたキーコードを使用することによってサーバ161にサインインが可能となる。

しかしながら、トークン端末121から提示されたキーコードを使用して、上記以外のアクセス端末141からサーバ161へサインインを試みた場合には、アクセス情報が一致しないため、ユーザシード(v)と照合シード(w)が一致しない。キーコード(k)と照合コード(h)が不一致となるため、他のアクセス端末141からのサインイン要求は拒否される。

このように、本態様によれば、アクセス端末141を限定するアクセス制限が可能となるが、サーバ161へのサインインに利用可能なアクセス端末141に関するブラックリストやホワイトリストを、事前にサーバ161にて用意する必要がない、という大きな効果を有する。

なお、アクセス情報として、ユーザIDとアクセス端末141の端末識別情報の両方を組み合わせて採用することもできるし、いずれか一方のみを採用することもできる。ユーザIDは、多くの適用分野では、アクセス情報と共有シードの一方もしくは双方に利用することが望ましい。ただし、ユーザが誰であるかを問わず、特定のアクセス端末141からのサインインのみを許すような態様では、ユーザIDをアクセス情報と共有シードのいずれにも採用しないことも可能である。

このように、本態様では、ユーザに関する情報をサーバ161に明示的に渡さずとも、ユーザやアクセス端末141が正当な使用権を有するものか否かを判定できる。したがって、たとえば、公衆無線LANのサービスをキャピティブポータル下で提供する際に、当該公衆無線LANを利用可能なアクセス端末141を管理するために好適である。

MACアドレス等の短い端末識別情報は、ユーザが自身で手入力することも可能であるが、電子証明書やucode等の長い端末識別情報は、ユーザが自身で手入力することが難しいことも多い。このような場合には、トークン端末121と、ユーザが使用するアクセス端末141と、を事前に近接場通信や局所通信にてペアリングし、アクセス端末141の端末識別情報をトークン端末121に吸い出して、登録することとしても良い。ユーザは、サーバ161をトークン端末121に登録する際に、いずれのアクセス端末141を使用してサインインするのか選択しても良いし、トークン端末121に登録された各アクセス端末141について、ユーザシードを取得してトークン端末121に保管することとしても良い。

この態様では、ユーザは、どのアクセス端末141を利用して、どのサーバ161へのサインインを試行するのか、を選択すると、利用すべきキーコードが提示されることとなる。

なお、アクセス端末141の端末識別情報をアクセス情報として利用する態様は、トークン端末121によって管理装置181の機能を果たすように構成する場合にも好適である。

以下では、各機器の処理、ならびに、上記基本構成に付加可能な機能について、詳細に説明する。以下では、共有シードとしてユーザIDおよび現在の日時を利用し、アクセス情報としてユーザIDを利用した例を説明しているが、上記の種々の情報を共有シードおよびアクセス情報として利用した態様も、本発明の範囲に含まれる。

(ユーザIDの結び付け処理)
トークン端末121にユーザIDを結び付ける処理は、スマートフォン等をトークン端末121として機能させるプログラムを、当該スマートフォン等で初めて実行した際、あるいは、トークン端末121の使用者が、新たなメールアドレス等を当該トークン端末121に新たなユーザIDとして追加したくなった際に実行される。したがって、1つのユーザIDの結び付けは、サインインしようとするサーバを追加するたびに行う必要はなく、1つのトークン端末121に対して全部で1回で済む。

図5は、本発明の実施例に係るユーザIDの結び付け処理の制御の流れを示すフローチャートである。以下、本図を参照して説明する。

本処理が開始されると、トークン端末121は、ユーザに、使用したいユーザIDの入力を求める(ステップS301)。

図6は、ユーザID入力フォームの表示例を示す説明図である。ユーザは、トークン端末121の画面に表示されたユーザID入力フォーム401のユーザID入力欄402に、希望のユーザIDを入力して、「次へ」ボタン403をクリック(「クリック」には、ボタン等の操作対象をタッチスクリーンにてタッチ、プレス等する処理を含む。また、キーボードやマウスによって、ボタン等の操作対象を選択する処理も含む。)する。

なお、処理を途中で中止したい場合には「キャンセル」ボタン404をクリックすれば良い(以下同様)。「キャンセル」ボタン404をクリックして、処理を途中で中止した場合の制御の流れについては、理解を容易にするため、本図では図示を省略している。

ユーザIDが入力されると、トークン端末121は、管理装置181へ、入力されたユーザIDを伝達する(ステップS302)。

管理装置181は、トークン端末121から伝達されたユーザIDを受け付けると(ステップS303)、当該伝達元のトークン端末121の識別名と、当該伝達されたユーザIDと、に対応付けられる問合せを生成する(ステップS304)。上記のように、問合せには、ランダムに設定された文字列や音声、画像等の符丁情報が指定される。この符丁情報は、後述するように、トークン端末121のユーザが自分で後から入力するものである。

そして、当該ユーザID宛に当該生成された問合せを送付し(ステップS305)、当該ユーザID、当該トークン端末121の識別名、ならびに、当該問合せに係る符丁情報を互いに対応付けて、回答待ちキューに登録する(ステップS306)。なお、各符丁情報は、回答待ちキューに登録されてから所定の有効期間が経過すると、回答待ちキューから除去される(図示せず)。また、1つのユーザIDならびに1つのトークン端末121の識別名に対応付けて回答待ちキューに格納可能な符丁情報の数は1つとし、重複している場合には、新しいもので上書きすることが望ましい。

ユーザIDとしてメールアドレスを採用する態様では、問合せは当該メールアドレスに電子メールの形式で送付される。携帯電話番号を採用する態様では、問合せは、ショートメッセージの形式、あるいは、音声により電話をかける形式で送付される。

ファクシミリ番号を採用する態様では、問合せは、ファクシミリにて送付される。各種SNSのアカウント名を採用する態様では、当該SNSにおける文字チャット、音声チャット、ダイレクトメッセージ等の形式で、問合せが送付される。

なお、スマートフォンをトークン端末121として利用している場合には、当該スマートフォンにて、電子メールの受信、ショートメッセージの受信、電話による音声の聞き取り、SNSへのアクセス等を可能とすることができる。この場合には、上記の問合せは、トークン端末121に伝達されることになる。

また、トークン端末121のハードウェア自体に問合せが伝達されない場合は、トークン端末121のユーザがファクシミリ装置や固定電話等、何らかの機器を介して問合せを受け取れば良い。

さて、ステップS302の後、トークン端末121は、ユーザに伝達された問合せに指定された符丁情報を、入力するよう求める(ステップS307)。なお、トークン端末121は、符丁情報の入力を求めた(ステップS307)後に、サーバ181へユーザIDを伝達(ステップS302)する、等のように、適宜処理の順序を入れ換えても良い。

図7は、符丁情報入力フォームの表示例を示す説明図である。ユーザは、トークン端末121の画面に表示された符丁情報入力フォーム411の符丁情報入力欄412に、ユーザに伝達された問合せに指定された符丁情報を入力して、「次へ」ボタン403をクリックする。なお、ユーザID表示欄413には、ユーザID入力フォーム401にて入力したユーザIDが表示されている。

すると、トークン端末121は、ステップS307にて入力された符丁情報と、ステップS301にて入力されたユーザIDとが指定された回答を、管理装置181へ送付する(ステップS308)。

管理装置181は、送付された回答を受け付け(ステップS309)、回答待ちキューにおいて、回答の送付元であるトークン端末121の識別名ならびに回答に指定されたユーザIDに対応付けられて登録されている符丁情報があり、さらに、当該登録されている符丁情報と、回答に指定された符丁情報と、が一致するか否かをか調べる(ステップS310)。この条件を満たすものがなければ(ステップS310; No)、ユーザIDの結び付けに失敗した旨の報告を、当該トークン端末121に送付する(ステップS311)。

一方、上記条件を満たすものがあれば(ステップS310;Yes)、管理装置181は、回答の送付元であるトークン端末121の識別名と、当該回答に指定されているユーザIDと、を、結び付けて記録する(ステップS312)。トークン端末121の識別名と、ユーザIDと、が、管理装置181にて結び付けて記録されていれば、当該トークン端末121に対して、当該ユーザIDが有効であることが確認済であることがわかる。

そして、管理装置181は、ユーザIDの有効性が確認でき、ならびにトークン端末121との結び付けが成功した旨の報告を、当該トークン端末121に送付する(ステップS313)。

トークン端末121は、送付された報告を受け付け(ステップS314)、当該報告が結び付けに失敗した旨を表すものであれば(ステップS315;失敗)、その旨の警告をユーザに提示して(ステップS316)、本処理を終了する。ユーザが再度ユーザIDの指定を試みる場合には、ステップS301以降の処理が繰り返される。

一方、当該報告が、ユーザIDの有効性が確認でき、トークン端末121との結び付けが成功した旨の報告であれば(ステップS315;成功)、トークン端末121において、有効性が確認されたユーザIDのリストに当該ユーザIDを追加して(ステップS317)、本処理を終了する。

なお、実際には、管理装置181は、外部から受け付けた各種のパケットを吟味して、その内容に応じた処理を実行する、という処理を繰り返している。本図では、その繰り返しの中で依存関係のある処理を抜き出して、ステップS303-S306と、ステップS309-S313と、を時系列順に記載してある。

以上、ユーザIDの有効性確認ならびにトークン端末121の使用者との結び付けの確認の典型例について説明したが、たとえば葉書等の郵送によったり、管理装置181の管理者とユーザが対面にて確認したり等、他の公知の手法を採用しても良い。

また、管理者が、ユーザIDとの結び付けの登録を、管理装置181ならびにトークン端末121にて済ませた上で、当該登録済みのトークン端末121を使用者に渡す、という態様を採用することもできる。

(サーバ登録処理)
トークン端末121にサーバを登録する処理は、スマートフォン等をトークン端末121として機能させるプログラムを実行した後、トークン端末121の使用者が、所定のボタンやメニューを選択した際等に実行される。図8は、本発明の実施例に係るサーバ登録処理の制御の流れを示すフローチャートである。以下、本図を参照して説明する。

本処理が開始されると、トークン端末121は、ユーザに、今後利用したいサービスを提供しているサーバのコラボコードと、当該サーバに使いたいユーザIDと、の入力を求める(ステップS601)。

図9は、コラボコード入力フォームの表示例を示す説明図である。ユーザは、トークン端末121の画面に表示されたサーバ登録フォーム421のコラボコード入力欄422に、希望のコラボコードを入力する。ユーザIDリスト423には、管理装置181と当該トークン端末121との間で有効性が確認済みのユーザIDが列挙されるので、ユーザは、その中からいずれかをチェックして選択する。そして「次へ」ボタン403をクリックする。

なお、ユーザIDの自由入力欄(図示せず)を設けても良い。ユーザIDリスト423に列挙されていないユーザIDが当該自由入力欄に入力された場合には、以降の処理に先行して、上述のユーザIDの結び付け処理(ステップS301-)を実行すれば良い。

すると、トークン端末121は、管理装置181へ、入力されたコラボコードおよび選択されたユーザID(u)を伝達する(ステップS602)。

管理装置181は、伝達されたコラボコードならびにユーザID(u)を受け付ける(ステップS603)。そして、伝達元のトークン端末121の識別名と、伝達されたユーザID(u)と、が、結び付けて記録されているか否か、すなわち、当該トークン端末121に対して当該ユーザID(u)の有効性が確認済か否か、調べる(ステップS604)。

確認済でなければ(ステップS604; No)、サーバの登録に失敗した旨の報告を、トークン端末121に伝達する(ステップS605)。

一方、ユーザID(u)がトークン端末121に対して有効であることが確認済みであれば(ステップS604; Yes)、管理装置181は、コラボコードに対応付けられているサイトシードの取得を試みる(ステップS606)。

サイトシードがなければ、(ステップS606; No)、管理装置181は、処理をステップS605に進め、サーバの登録に失敗した旨の報告を、トークン端末121に伝達する。

一方、コラボコードに対応付けられているサイトシードがあれば(ステップS606; Yes)、管理装置181は、当該伝達されたユーザID(u)と、当該取得されたサイトシード(s)と、に第1関数(F)を適用して、ユーザシード(v)を計算する(ステップS607)。
v = F(u,s)

そして、管理装置181は、計算されたユーザシード(v)を指定した報告を、トークン端末121に伝達する(ステップS608)。

トークン端末121は、管理装置181から伝達された報告を受け付け(ステップS609)、当該報告にユーザシード(v)が指定されていなければ、(ステップS610; No)、ユーザIDもしくはコラボコードが無効である旨の警告をユーザに提示して(ステップS611)、本処理を終了する。ユーザが再度サーバの登録を試みる場合には、ステップS601以降の処理が繰り返される。

一方、当該報告にユーザシード(v)が指定されていれば(ステップS610; Yes)、当該報告はサーバの登録に成功したことを示しているので、トークン端末121は、コラボコード(もしくは、コラボコードにあらかじめ対応付けられたサービス名やサーバ名、アイコン等を用いても良い。)と、ユーザが選択したユーザID(u)と、管理装置181から伝達されたユーザシード(v)と、を対応付けて記録し(ステップS612)、本処理を終了する。

理解を容易にするため、トークン端末121には、あらかじめ複数の「空きスロット」が用意されており、コラボコード等と、ユーザIDと、ユーザシードと、の対応付けが登録されるごとにある「空きスロット」にこれらの情報が埋め込まれ、情報が埋め込まれた「スロット」によって、サインインしようとするサーバ161のサービスやサインインに使用するユーザIDおよびユーザコードを識別するものとする。

(サインイン処理)
本実施形態では、上記のように、コラボコードを介してトークン端末121にサーバ161が登録されただけで、ユーザがサーバ161へサインインするためのキーコード(パスワード)を配布することができる。図10は、サインイン処理の制御の流れを示すフローチャートである。

上記のように、サーバ161へのサインインには、トークン端末121とは独立したアクセス端末141を利用しても良いし、トークン端末121とアクセス端末141を一つのコンピュータによって実現しても良い。以下では、理解を容易にするため、トークン端末121とアクセス端末141が異なる機器である状況を想定して説明する。

ユーザが、トークン端末121においてサインイン処理に対応付けられたメニュー項目やボタンを選択すると、トークン端末121における本処理が開始される。そして、トークン端末121は、ユーザに、サインインしたいサーバ161のサービスの選択を促す(ステップS701)。

図11は、サービス選択フォームの表示例を示す説明図である。本図に示すように、トークン端末121の画面には、サービス選択フォーム431が表示される。サービス選択フォーム431には、登録されたスロットを表すスロットボタン432が複数表示され、各スロットボタン432には、当該サービスを表す名称(たとえば、コラボコードを使用することができる。)が、ラベルされている。

ユーザが、所望のサービスに対するスロットボタン432をクリックすると、当該スロットボタン432に対応付けられたスロットが選択されたことになる。すると、トークン端末121は、選択されたスロットに対して記録されたユーザID(u)およびユーザシード(v)を取得する(ステップS702)。

さらに、キーコード(パスワード)が日時によって変化するようにするため、トークン端末121は、所定単位にて現在日時(d)を取得する(ステップS703)。

そして、トークン端末121は、取得されたユーザID(u)、ユーザシード(v)、現在日時(d)に第2関数(H)を適用することにより、キーコード(k)を計算する(ステップS704)。
k = H(u,v,d)

さらに、トークン端末121は、ユーザID(u)および計算されたキーコード(k)を、画面に表示する(ステップS705)。図12は、キーコードを直接表示する例を示す説明図である。

本図では、キーコードフォーム441のキーコード欄442に、8桁の数字「62563893」が表示されている。これがサインインに使用するキーコードであり、当該キーコードは、現在日時(d)を参照してキーコードを採用する場合には、ワンタイムパスワード、あるいは、所定単位の期間ごとに自動更新されるパスワードとして機能する。

また、本図に示すように、ユーザID欄443には、ユーザID(u)として、「xxx@yyy.zzz.com」が表示されている。これがサインインに使用するユーザIDである。さらに、サーバ欄444には、サービスを表す識別名として、「コラボコードC」が表示されている。なお、ユーザID(u)をユーザが頭の中だけで記憶する場合には、キーコードフォーム441ならびにステップS705におけるユーザID欄443およびユーザID(u)の表示を省略することもできる。

図13は、キーコードを乱数表に埋め込んで表示する例を示す説明図である。本図では、キーコード欄442には乱数表が表示されている。キーコード「62563893」は、1行5列、3行3列、5行4列、4行4列に、分割して格納されている。この位置および順序は、トークン端末121を使用するユーザがあらかじめ設定したものであり、ユーザが個々のパスワードのかわりに記憶することで、いわゆるI-know認証を行うためのものである。

非特許文献1に開示する技術と同様に、ユーザは、自分が設定した順序で、乱数表から、自分が設定した位置の桝目を選び、選ばれた桝目に埋め込まれた要素を連結することで、キーコードを得ることができる。

なお、キーコードフォーム441の表示は、一定時間(典型的には、数十秒乃至数分)が経過したら自動的に消去されることが望ましい。また、キーコードフォーム441における「キャンセル」ボタン404をクリックすることで、キーコードフォーム441の表示を終了することとしても良い。

トークン端末121の画面に表示されたキーコードフォーム441を見たユーザは、アクセス端末141にて起動されたブラウザにおいて、サインインしようとするサービスにアクセスしたり、あるいは、アクセス端末141にて起動されたターミナルソフトウェアで、サインインしようとするサーバ161にアクセスしたりする。すると、サーバ161からの指示に基づいて、アクセス端末141にて、サインインフォームやログインプロンプトが表示される。

すなわち、アクセス端末141は、サインインフォームやログインプロンプトに対して、キーコードフォーム441に表示されたユーザID(u)およびキーコード(k)を入力するよう促す(ステップS706)。前述の表示例では、ユーザは、ユーザID(u)として「xxx@yyy.zzz.com」を、キーコード(k)として「62563893」を、それぞれ入力することになる。

ユーザがこれらの情報を入力すると、アクセス端末141は、入力されたユーザID(u)およびキーコード(k)が指定されたサインイン要求を、サーバ161へ送信する(ステップS707)。

なお、ユーザID(u)とキーコード(k)の入力および送信は、別個に行っても良い。たとえば、ターミナルソフトウェアにおけるログインプロンプトでは、まずユーザIDの入力プロンプトが表示され、これに対してユーザIDを入力すると、直ちにその情報がサーバ161に伝達され、その後にキーコード(パスワード)の入力プロンプトが表示され、これに対してキーコードを入力すると、直ちにその情報がサーバ161に伝達される、という形式を採用する場合もある。このような態様であっても、サインインに使用するユーザID(u)およびキーコード(k)が、アクセス端末141からサーバ161へ伝達されることにかわりはない。

さて、サーバ161は、アクセス端末141から、サインイン要求に係るユーザID(u)およびキーコード(k)を受信すると(ステップS708)、当該提供するサービスに対して設定されたサイトシード(s)、および、所定単位で表現された現在日時(e)を取得し(ステップS709)、受信されたユーザID(u)、取得されたサイトシード(s)、および、現在日時(e)に対して、第1関数(F)および第2関数(H)を適用し、照合シード(w)および照合コード(h)を計算する(ステップS710)。
w = F(u,s);
h = H(u,w,e)

そして、サーバ161は、受信されたキーコード(k)と、計算された照合コード(h)と、が、一致するか否かを調べる(ステップS711)。

両者が一致しなければ(ステップS711; No)、サインインは失敗した旨の失敗応答を、アクセス端末141に対して送信する(ステップS712)。

一方、両者が一致すれば(ステップS711; Yes)、サインインは成功した旨の成功応答を、アクセス端末141に対して送信する(ステップS713)。

アクセス端末141は、サーバ161から送信された応答を受信する(ステップS714)。サインインに成功したか否かは、当該応答が成功応答か失敗応答かによって区別できる。サインインに失敗していれば(ステップS715; No)、ユーザIDやキーコードが誤っている、あるいは、キーコードの有効期限が徒過した等の原因によりサインインできなかった旨を表す警告を発して(ステップS716)、本処理を終了する。ユーザが再度サインインを試みる場合には、ステップS701以降の処理を繰り返すことになる。

一方、サインインに成功していれば(ステップS715; Yes)、アクセス端末141とサーバ161との間で、サービスの提供がなされる(ステップS717)。

このように、本実施形態によれば、トークン端末121へのサーバ161の登録では、事前に有効性が確認されたユーザIDを使用するが、トークン端末121は管理装置181と通信ができれば十分であり、トークン端末121とサーバ161との間の通信やインタラクションは不要である。

また、本実施形態によれば、各種の個人情報を新たに入力する必要はない。さらに、本実施形態によれば、自分で他のサービスと重複せず、忘れにくいパスワードをわざわざ考え出す必要もない。たとえば、無料の体験会員登録などに本態様を適用すれば、ユーザは気軽にサービスの体験登録ができる。

一方で、サービス提供者は、ユーザへの連絡が可能なユーザIDを得ることができるため、その後のプロモーションを効果的に進めることができる。

なお、トークン端末121自体がアクセス端末141としても機能する場合には、トークン端末121に自動サインイン機能を付加することもできる。

すなわち、図12に示すように、トークン端末121は、キーコードフォーム441に「開く」ボタン445等を用意する。

ユーザがこのボタンをクリックすると、トークン端末121は、トークン端末121内のブラウザやターミナルソフトウェア等を起動して、選択されたスロットに係るサーバへのアクセスを当該ブラウザ等に開始させる。そして、トークン端末121は、サインイン情報としてユーザ名やキーコードをブラウザやターミナルソフトウェア等へ自動入力する処理を行う。

図13に示すキーコードフォーム441においては、ユーザが、乱数表の中からユーザが設定した順序ならびに位置の要素をクリックすると、トークン端末121は、クリックされた要素の中身を並べたものをキーコードとする。そして、図12において「開く」ボタン445をクリックした場合と同様に、自動入力処理を行うのである。

また、特許文献2に開示されるようなブラウザ用のプラグインを用意し、トークン端末121とアクセス端末141との間で近接通信を行って、ユーザ名やキーコードをトークン端末121からアクセス端末141へ伝送し、アクセス端末141のブラウザにて、ユーザ名やキーコードを自動入力することとしても良い。

図12に係る自動入力の態様では、トークン端末を持っていることによる認証(I-have認証)が行われ、図13に係る自動入力の態様では、I-have認証に加えて、さらに、自分用の順序および位置を知っていることによる認証(I-know認証)が行われており、ユーザ名はキーコードを手で直接入力する場合と、安全性は変わらないまま、ユーザの利便性を高めることができる。

(アカウント情報とブラック/ホワイトリスト)
サーバ161が、サインインに成功したユーザIDに応じて各種サービスを提供するためには、データベース等で、ユーザIDを鍵としてサービスの提供の経緯等のアクティビティを管理する必要がある。

したがって、サーバ161は、データベースに、たとえば、ユーザのアクティビティ(アカウント情報)として、サインインに成功した日時や、ユーザからの要求に応じて提供したサービスの種類や提供日時などを記録しても良い。

また、過去に提供したサービスにおいて問題を起こしたユーザのユーザIDを、サーバ161にてブラックリストに登録しておき、キーコードと照合コードの対比に先立って、あるいは、対比に成功した後に、サインイン要求に係るユーザIDがブラックリストに登録されているか否かを調べても良い。

この態様では、サーバ161は、ユーザIDがブラックリストに登録されている場合には、サインインを失敗させる。

また、特定のメールアドレスのみ(たとえば、社員に割り当てられた社用のメールアドレス)をサーバ161にてホワイトリストに登録しておき、ユーザIDがホワイトリストに登録されていなければ、サインインを失敗させることとしても良い。

ホワイトリストやブラックリストには、具体的なユーザIDそのものを登録しても良いし、メールアドレスのドメイン部分や国部分をチェックするように構成しても良い。

これらの態様では、キーコードと照合コードが一致することは、サインインが成功するための必要条件として機能することになる。

(ユーザIDのエイリアス)
上記の実施例では、ユーザIDとして、ユーザ自身が使用するメールアドレス等を採用していた。しかしながら、ユーザ自身が使用するメールアドレスをサーバ161に明かしたくないこともある。本実施例は、このような要望に応えるため、ユーザIDの別名(エイリアス; alias)を提供することができる。以下、理解を容易にするため、ユーザIDならびにそのエイリアスとして、メールアドレスを利用する場合を掲げて説明するが、各種SNSのユーザ名、アカウント名、ショートメッセージの送り先となる携帯電話番号、サーバ161からユーザが使用するスマートフォン等への通知に使用する各種の端末識別情報やユーザ識別情報など、ユーザとの連絡がとりうる各種の連絡先情報を、ユーザIDならびにそのエイリアスとして採用することが可能である。

まず、ユーザが主に使用するメールアドレスが、xxx@yyy.zzz.com である場合を考える。ユーザは、トークン端末121として機能するスマートフォンや、メール送受を行うことが可能なアクセス端末141において、当該メールアドレス宛の各種のメッセージを受信することができる。

一方、管理装置181は、メールサーバとしても機能し、当該メールサーバにて管理されるドメインが ppp.qqq.com であるものとする。

管理装置181は、確認済みの連絡先であるメールアドレス xxx@yyy.zzz.com が紐付けられたトークン端末121に対して、xxx@yyy.zzz.com のエイリアスを発行して、両者を対応付けて管理装置181が有するデータベースに登録する。

発行されるエイリアスのメールアドレスのドメイン名部分は、管理装置181にて管理されるドメイン名をそのまま採用し、ユーザ名部分は、ランダムでユニークな文字列とするのが、最も単純な構成である。この場合、エイリアスは、たとえば、t6tsae67-pdsb2kjyb92-s6q8ymp8xa4z9@ppp.qqq.comなどのような姿となる。

このほか、エイリアスを生成するために、確認済みの連絡先である xxx@yyy.zzz.com と、発行の日時や当該エイリアスが何番目のものであるかを表す数値と、に、上記の一方向性関数やハッシュ関数等を適用することによって、メールアドレスのユーザ名部分を生成することとしても良い。

管理装置181は、SMTP(send mail transfer protocol)などのプロトコルに基づいてt6tsae67-pdsb2kjyb92-s6q8ymp8xa4z9@ppp.qqq.com 宛の電子メールが到着すると、これをメールアドレス xxx@yyy.zzz.com に転送する。あるいは、xxx@yyy.zzz.com に紐付けられているスマートフォン(典型的には、トークン端末121。)のアプリケーション(典型的には、スマートフォンをトークン端末121として機能させるプログラム。)に対して、スマートフォンのオペレーティングシステムが提供する通知機能を用いて、通知しても良い。

エイリアスは、トークン端末121にてxxx@yyy.zzz.com の確認がとれた直後に所定数を発行して、トークン端末121に保管させ、サーバ161の登録時にユーザが選択可能なようにしても良い。トークン端末121からのエイリアス発行の依頼がある度に、新たなエイリアスを発行して、トークン端末121に知らせることとしても良い。

このほか、すでに確認済みの連絡先であるユーザIDが紐付けられたトークン端末121では、サーバ登録時に、ユーザが、ユーザIDとしてエイリアスを使用する旨を指定できるようにしても良い。たとえば、図9に例示するように、ユーザIDリスト423に、「新たなエイリアスを発行」という選択肢を設けておき、これが選択された場合には、管理装置181が新たなエイリアスを発行して、登録しようとするサーバ161に対するユーザIDとして利用できるようにする。

各サーバ161に対するユーザIDおよびキーコードは、図12に示すように、ユーザに提示される。

この態様によれば、ユーザは、自身が主として使用するメールアドレスをサーバ161に知られることなく、サーバ161へのサインインが可能となる。このため、ユーザは、気軽にお試し使用が可能となる。

また、サーバ161は、ユーザへの連絡手段が確保されているため、各種の広告やキャンペーンに係るメッセージをユーザに送ることが可能である。ユーザは、サーバ161が提供するサービスに対する興味がなくなったり、サービスの利用を停止したりする場合には、エイリアス自体の使用をやめても良いし、当該サーバ161から当該エイリアス宛の電子メールが到着したら、電子メールの受信箱から保管庫へ直ちにアーカイブするように設定したり、エイリアス単位でSPAMフィルタを設定したりすることが可能となる。

さらに、本態様では、ユーザが使用中のエイリアスXを、新たなエイリアスYに移行することも容易である。

この場合、ユーザは、上記の実施例と同様に、新たなエイリアスYをユーザIDとして使用して、アクセス端末141からサーバ161にサインインする。

サインインに成功したら、以前のエイリアスXからの移行(アカウント情報の継承、統合、置き換え等を含む。)を、アクセス端末141からサーバ161へ依頼する。

サーバ161は、旧ユーザIDであるXと、新ユーザIDであるYと、の移行依頼があると、両ユーザIDであるXとYとが、同じユーザの使用するユーザIDであるか否かを、管理装置181に質問する。

管理装置181は、質問に係る両ユーザIDであるXとYとのそれぞれに対応付けられて登録されている確認済みの連絡先を取得する。XやYが、トークン端末121に直接紐付けられたメールアドレスであれば、当該メールアドレスが確認済みの連絡先が取得され、エイリアスであれば、当該エイリアスに対応付けられて登録されている確認済の連絡先が取得される。

そして、取得された2つの連絡先が一致しているか否か、を、サーバ161に対して回答する。ユーザが同一であれば、2つの連絡先は一致しているはずである。なお、回答に先立って、管理装置181は、質問を行ったサーバ161ならびに両ユーザID X, Yを指定した確認メッセージを、確認済の連絡先に送り、ユーザに対して、この移行を希望するか否かを問い合わせても良い。希望しない場合には、管理装置181は、2つの連絡先は一致しない旨の回答をサーバ161に対して送る。

サーバ161は、管理装置181からの回答を受け付け、XとYに対応付けられた確認済の連絡先が一致していれば、当該移行は同一ユーザの依頼に係るものと判断して、アカウント情報の継承、統合、あるいは、置換等の処理を行う。

このように、本実施例によれば、ユーザIDを安全かつ容易に変更することができる。また、トークン端末121を紛失したり盗まれたりした場合であっても、ユーザIDを変更することによって、キーコードの系列が変化し、被害の拡大を抑制することができる。

なお、新ユーザID Yと、旧ユーザID Xと、は、互いにエイリアスの関係にある、と考えることも可能である。上記のように移行が行われた後は、旧ユーザID Xは、サーバ161におけるブラックリストに自動登録されることとしても良い。

この技術を、既存のメールサービスにおけるエイリアスに適用することも可能である。たとえば、主メールアドレスxxx@yyy.zzz.comに対して、ユーザ名に付加的な文字列を付けて、xxx+abc123@yyy.zzz.com, xxx+pqr789@yyy.zzz.com のようなエイリアスを利用できるようにしたメールサービスが提供されている。

このサービスでは、ユーザ名の+から@までの間に自由な英数字を付加できるようにしており、メールサーバにエイリアス宛のメールが到着すると、それを主メールアドレスの受信箱に登録する。

このサービスでは、ユーザID同士のエイリアス関係が、当該ユーザIDを対比するだけでわかる。そこで、今回サインインに成功したユーザID(たとえば xxx+pqr789@yyy.zzz.com)が、過去にサインインに成功したユーザID(たとえば xxx@yyy.zzz.com や xxx+abc123@yyy.zzz.com)のエイリアスである場合には、過去にサインインに成功したユーザIDを自動的にブラックリストに移動することとしても良い。

この際に、アカウント情報の継承、統合、置換も、上記の実施例と同様に自動移行すれば、新たなエイリアスに係るIDでサインインするだけで、自動的に、ユーザIDの変更が可能となる。

また、ブラックリストへの登録をせず、どのようなエイリアスを用いた場合であっても、キーコードと照合コードの一致を持って、主アドレスに係るアカウントにサインインできるようにしても良い。

さらに、所定のルールにて主アドレスからエイリアスが順次生成され、当該生成がトークン端末121とサーバ161で同期される態様では、トークン端末121が、今回のサインインで使用すべきユーザIDのエイリアスを、ユーザに提示することとしても良い。

たとえば、付加文字列の後に整数を表す文字列を並べ、サインインを試行する度に当該整数部分がカウントアップされる、という態様では、xxx+0001@yyy.zzz.com, xxx+0002@yyy.zzz.com, xxx+0003@yyy.zzz.com, …のように、規則的にユーザIDが切り替えられることになる。

以上説明した通り、本実施形態におけるキーコードは、ユーザIDに依存させることができる。そこで、ユーザIDそのものを変更することで、発生されるキーコードの系列を切り替えることができる。

そこで、トークン端末121を紛失した場合等、何らかの事情で、サインイン用のユーザIDを切り替えたい場合には、エイリアスを利用することで、サーバ161の管理者の手を煩わせることなく、自動的にユーザIDの変更ができるようになる。

さらに、異なるサーバ161で異なるエイリアスを利用して、各種の個人情報を登録している場合であっても、管理装置181においては、これらの個人情報を元の連絡先(有効性が確認済され、トークン端末121に結び付けられたユーザID)に統合することができる。

したがって、異なるユーザIDを用いて各サーバ161を利用していたとしても、管理装置181にてまとめて個人情報を管理し、ユーザの許諾の下、各サーバ161と管理装置181の間で、個人情報をやりとりできるように構成することが可能である。

(共有シードの態様)
上記実施形態においては、第2関数(H)を、ユーザID(u)、ユーザシード(v)、ならびに、現在日時(d)に適用して、キーコード(k)を取得し、もしくは、照合シード(w)を計算した後、その結果に第2関数(H)を利用して、照合コード(h)を取得していた。

現在日時を参照せず、ユーザIDのみを共有シードとし、本態様を固定パスワードの配布に利用する場合には、管理装置181にて、あらかじめ
v = F(u,s)
のようにユーザシード(v)を計算し、当該ユーザシード(v)をトークン端末121に保存させる。

そして、ユーザがサインインの使用に利用するキーコード(k)を必要とする際に、トークン端末121で、
k = H(u,v)
と計算し、サーバ161では、照合コード(h)を
h = H(u,F(u,s))
と計算する。

なお、ユーザID(u)は、ユーザシード(v)や、サーバ161で計算される照合シードw = F(u,s)に反映されている。そこで、以下のように、ユーザID(u)は共有シードとしないことも可能である。すなわち、トークン端末121の現在日時(d)とサーバ161の現在日時(e)は、独立に取得され、トークン端末121では、
(c1) k = H(v,d)
と計算し、サーバ161では、
(c2) h = H(F(u,s),e)
と計算する。

一般に、第2関数は、ユーザシード(v)もしくは照合シード(w = F(u,s))と、共有シードと、に適用される。

ここで、共有シードとしてユーザID、現在時刻、もしくは、ユーザIDと現在時刻の両者を採用した場合には、サインインに際して、トークン端末121とサーバ161との間の通信やインタラクションを不要とすることができる。

このほか、共有シードとして、キャプチャ(CAPTCHA)を採用することもできる。すなわち、サーバ161は、アクセス端末141のブラウザにて表示されるサインイン用フォームや、ターミナルソフトウェアにて表示されるログインプロンプトにおいて、ランダムに定められた文字列、人間には読み取り可能であるが機械的な文字認識が困難な画像、人間が聞き取れ文字列化することができる音声等をキャプチャとして生成して、これをユーザに提供する。また、サーバ161は、生成されたキャプチャを共有シードとして、照合コードを計算する。

ユーザは、トークン端末121にてキーコードを表示させる前に、サーバ161から提供されたキャプチャを、トークン端末121に入力する。トークン端末121は、入力されたキャプチャを共有シードとして、キーコードを計算する。

この態様では、キャプチャは、サーバ161にて生成され、トークン端末121に入力されて共有されるが、サーバ161とトークン端末121との間の直接の通信やインタラクションは不要であり、ユーザが両者間で共有シードを渡している。ユーザIDを共有シードとする場合には、ユーザが、共有シードをサーバ161へ渡すが、キャプチャを共有シードとする場合には、ユーザは、共有シードをトークン端末141に渡すので、渡す方向は逆向きになっている。

なお、トークン端末121の紛失、盗難に備えるため、トークン端末121にてキーコードが提示されると毎回、もしくは、間欠的に、使用されたユーザIDや、トークン端末121自体の識別情報や、GPSにて測定されたトークン端末121の所在等を、管理装置181に報告することとしても良い。この態様では、サーバ161は、トークン端末121とアクセス端末141の両方におけるユーザのアクティビティを管理するため、サインインの要求があるごとに、管理装置181に問い合わせを行い、管理装置181から最後に報告された内容を取得する。

この態様では、共有シードとして、トークン端末121自体の識別情報や、GPSにて測定されたトークン端末121の所在等を、採用することも可能である。

さらに、共有シードとして、アクセス端末141が固定設置されている場所の地理情報を利用することもできる。

たとえば、本実施形態をホテル、民宿、宅配ボックス、コインロッカー等の施設の電子錠として利用することもできる。この場合には、アクセス端末141用の入力機器として、利用したい施設のドア付近に設置されたタッチスクリーンやテンキーなどを設置する。

ユーザは、利用したい施設あるいは予約した施設に係るスロットをトークン端末121において選択する。さらに、必要に応じて、施設予約時に使用したメールアドレス等のユーザIDや予約番号、ロッカー番号等を入力する。

すると、トークン端末121は、自身が備えるGPSセンサによって、自身の位置(所定の精度で表現された経度ならびに緯度、もしくは、住所や地番等)を調べる。

そして、トークン端末121は、取得されたトークン端末121の位置を、共有シードとして利用して、キーコードを計算し、ユーザに提示する。ユーザは、提示されたキーコードを、予約した施設のドアに設置されたタッチスクリーン等を有するアクセス端末141に入力する。すると、アクセス端末141は、施設の予約を管理するサーバ161へ、サインイン要求を送る。

いずれのサーバ161は、サインイン要求を受信すると、当該サインイン要求に係るキーコードの入力がされたタッチスクリーン等が設置されている施設の位置を管理データベースから取得して、これを共有シードとする。

このように、本態様では、トークン端末121は、GPSセンサによって共有シードを取得し、サーバ161は、サインイン要求の送信元であるアクセス端末141が設置されている場所を管理データベースから取得してこれを共有シードとすることで、物理的なキーを用意しなくとも、施設利用者が使用するスマートフォン等を電子鍵とすることが可能となる。

なお、上記の説明では、位置情報や日時情報を所定の単位で表現することとしているため、位置や日時が各単位の境界付近にある場合の誤差を考慮する必要がある。たとえば、日時を1時間単位で表現する場合に、サーバ161で取得された現在の日時が、13時58分であったとする。

このとき、サーバ161では、ひとまずは、13時を共有シードとして採用して照合コードを計算し、キーコードと対比する。両者が一致しなければ、14時を共有シードとして採用して照合コードを計算し、キーコードと対比することで、サインインの可否を決めるのである。

一方で、現在の日時が13時24分であった場合には、単位の境界から十分に離れているので、共有シードとして13時のみを採用すれば良い。

このように、サーバ161にて取得された位置・日時情報が、所定単位の境界の前後の所定誤差範囲内に含まれる場合には、境界前後の両方を共有シードとして採用することができる。

(ユーザIDと秘密情報)
インターネットバンキング等では、ユーザはメールアドレスを介して銀行から連絡を受け、口座番号によって口座を管理する。そこで、ユーザIDとしてメールアドレスを使用するが、サインインの際に、アクセス端末141に対して、メールアドレスではなく口座番号を入力して、これをユーザ識別情報とすることも可能である。

この態様では、サーバ側は、サインインに際して入力された口座番号に対するメールアドレスをアカウント情報のデータベースから取得して、これをユーザIDとする。

口座番号のように、サインインの際に入力する情報の方が、連絡先に使用される情報よりも秘匿性が高い場合等には、サインインの際に入力すべきユーザ識別情報をトークン端末121に記録せず、ユーザが頭の中に記憶しておく。サーバ161は、サインインの際にユーザにより入力されたユーザ識別情報から、ユーザIDを取得する。このようにしてユーザIDが得られれば、上記実施形態を適用することができる。

(プログラムとの関係)
上記の各実施例のトークン端末121、アクセス端末141、サーバ161、管理装置181は、各種のプログラムを各種のコンピュータのハードウェア上で実行することにより、実現することができる。

一般には、コンピュータは、非一時的(non-transitory)情報記録媒体に記録されたプログラムを、一時的(temporary)記憶装置であるRAM(Random Access Memory)に読み出してから、CPU(Central Processing Unit)あるいはプロセッサが読み出されたプログラムに含まれる指令を実行する。ただし、ROMとRAMを一つのメモリ空間にマッピングして実行することが可能なアーキテクチャでは、ROMに格納されたプログラムに含まれる指令を、直接CPUが読み出して実行する。CPUあるいはプロセッサ等は、RAM等と協働して、当該ハードウェアが備えるNIC(Network Interface Card)やディスプレイ、マイク、スピーカなどの機器を制御する。

ここで、各プログラムは、コンパクトディスク、フレキシブルディスク、ハードディスク、光磁気ディスク、ディジタルビデオディスク、磁気テープ、ROM(Read Only Memory)、EEPROM(Electrically Erasable Programmable ROM)、フラッシュメモリ、半導体メモリ等のコンピュータ読み取り可能な非一時的(non-transitory)情報記録媒体に記録することができる。この情報記録媒体は、各ハードウェアとは独立して配布・販売することができる。

さらに、上記のプログラムは、プログラムが実行されるコンピュータとは独立して、コンピュータ通信網等の一時的(transitory)伝送媒体を介して、配布装置等から、各ハードウェアへ配布することもできる。

なお、上記のプログラムを、電子回路の動作レベル記述用のプログラミング言語によって記述することも可能である。この場合には、上記のプログラムから、電子回路の配線図やタイミングチャート等、各種の設計図が生成され、当該設計図に基づいて、上記の画像処理装置を構成する電子回路を作成することができる。たとえば、上記のプログラムから、FPGA(Field Programmable Gate Array)技術によって再プログラム可能なハードウェア上に、上記画像処理装置を、構成することができるほか、ASIC(Application Specific Integrated Circuit)技術によって、特定用途専用の電子回路を構成することも可能である。

この場合、トークン端末121、アクセス端末141、サーバ161、管理装置181の各部は、これに割り当てられた処理を実行するように構成(configure)される。

(まとめ)
以上説明した通り、本実施形態によれば、トークン端末を用いて、サイトシードが非公開に割り当てられたサーバへの、アクセス端末を介したサインインを許可するか否かを、前記サーバが判定するための、以下の認証システムを提供することができる。すなわち、
(1)前記トークン端末を使用する使用者が、前記サーバを前記トークン端末へ登録するために、
(a)前記トークン端末は、
前記サーバへサインインするためのアクセス情報を指定され、
前記指定されたアクセス情報を管理装置へ伝達し、
(b)前記管理装置は、
少なくとも、前記伝達されたアクセス情報と、前記サーバに割り当てられたサイトシードと、に、第1関数を適用することにより、前記サーバに対するユーザシードを取得し、
前記取得されたユーザシードを前記トークン端末に伝達し、
(c)前記トークン端末は、
前記伝達されたユーザシードを記録することにより、前記サーバを前記トークン端末へ登録し、
(2)前記使用者が、前記サーバが登録された前記トークン端末を用いて、前記アクセス端末を介した前記サーバへのサインインを試行するために、
(d)前記トークン端末は、
前記試行されるサインインに対して前記サーバから独立して取得され、前記サーバと共有されるべき共有シードを取得し、
少なくとも、前記取得された共有シードと、前記記録されたユーザシードと、に第2関数を適用することにより、キーコードを取得し、
前記使用者へ、前記取得されたキーコードを提示し、
(e)前記アクセス端末は、
前記トークン端末により前記使用者へ提示されたキーコードを受け付け、
前記受け付けられたキーコードが指定された要求を、前記サーバへ送信し、
(f)前記サーバは、
前記送信された要求を受信し、
前記受信された要求に係るアクセス情報を取得し、
少なくとも、前記取得されたアクセス情報と、前記サーバに割り当てられた前記サイトシードと、に、前記第1関数を適用することにより、照合シードを取得し、
前記試行されるサインインに対して前記トークン端末から独立して取得され、前記トークン端末と共有されるべき共有シードを取得し、
少なくとも、前記取得された共有シードと、前記取得された照合シードと、に前記第2関数を適用することにより、照合コードを取得し、
前記受信されたキーコードと、前記取得された照合コードと、が一致することを、前記アクセス端末を介した前記要求に係るサインインを許可する必要条件とする。

また、上記認証システムにおいて、
前記トークン端末において、前記指定されるアクセス情報には、前記サーバへサインインするためのユーザIDが含まれ、
前記アクセス端末は、前記サーバへサインインするためのユーザIDを受け付け、
前記アクセス端末は、前記受け付けられたユーザIDを、前記サーバへ送信し、もしくは、前記要求に指定してから前記要求を前記サーバへ送信し、
前記サーバにおいて、前記取得されるアクセス情報には、前記送信されたユーザID、もしくは、前記要求に指定されたユーザIDが含まれる
ように構成することができる。

また、上記認証システムにおいて、
前記トークン端末は、所定単位で表現された現在の日時を、前記共有シードとして取得し、
前記サーバは、前記所定単位で表現された現在の日時を、前記共有シードとして取得する
ように構成することができる。

また、上記認証システムにおいて、
前記トークン端末は、前記伝達されたユーザシードと、前記指定されたユーザIDと、を対応付けて記録し、
前記トークン端末は、前記記録されたユーザIDを、前記共有シードとして取得し、
前記サーバは、前記受信されたユーザIDを、前記共有シードとして取得する
ように構成することができる。

また、上記認証システムにおいて、
前記サーバは、キャプチャ(CAPTCHA)を生成し、
前記サーバは、前記生成されたキャプチャを、前記共有シードとして取得し、
前記サーバは、前記生成されたキャプチャを前記アクセス端末へ送り、
前記アクセス端末は、前記サーバから送られた前記キャプチャを前記使用者に提示し、
前記トークン端末は、前記アクセス端末により提示された前記キャプチャを前記トークン端末へ入力するよう前記使用者に促し、
前記トークン端末は、前記入力されたキャプチャを、前記共有シードとして取得する
ように構成することができる。

また、上記認証システムにおいて、
前記トークン端末において、前記指定されるアクセス情報には、前記サーバへサインインするための前記アクセス端末に割り当てられた端末識別情報が含まれ、
前記サーバは、前記要求を受信することにより、当該要求を送信した前記アクセス端末に割り当てられた端末識別情報を取得し、
前記サーバは、前記取得された端末識別情報を含む前記アクセス情報を取得する
ように構成することができる。

また、上記認証システムにおいて、
前記トークン端末は、前記伝達されたユーザシードと、前記指定されたユーザIDと、を対応付けて記録し、
前記トークン端末は、前記記録されたユーザIDのエイリアスを生成して、前記生成されたエイリアスを、前記共有シードとして取得し、
前記生成されたエイリアスを、前記サーバへサインインするためのユーザIDとして、前記アクセス端末に受け付けさせるよう、前記使用者へ促し、
前記サーバは、前記受信されたユーザIDを、前記共有シードとして取得し、
前記サーバは、前記受信されたユーザIDをエイリアスとする元のユーザIDを取得し、
前記サーバは、前記アクセス端末を介したサインインを、前記取得された元のユーザIDに係るアカウント情報に対して、許可する
ように構成することができる。

また、上記認証システムにおいて、
前記第1関数は、一方向性関数であり、当該第1関数が適用された結果のビット数は、当該第1関数が適用される引数のビット数以上であり、
前記第2関数は、ハッシュ関数であり、前記第2関数の適用結果は、所定の長さの文字列である
ように構成することができる。

また、上記認証システムにおいて、
前記使用者が、前記サーバを前記トークン端末へ登録するために、前記使用者は、
(g)前記管理装置にて有効であることが確認済の連絡先、ならびに、
(h)前記管理装置により、当該連絡先と対応付けられたエイリアス
からいずれかを、前記ユーザIDとして指定し、
前記エイリアスを宛先とするメッセージは、前記管理装置に伝送され、前記管理装置は、当該メッセージを、当該エイリアスと対応付けられた前記連絡先に伝送する
ように構成することができる。

また、上記認証システムにおいて、
前記使用者が、前記サーバを前記トークン端末へ登録するために、前記使用者が、前記管理装置によって前記連絡先に対応付けられるべきエイリアスであって、前記管理装置から前記トークン端末に未伝達のエイリアスを、前記ユーザIDとして指定すると、
(i)前記管理装置は、前記ユーザシードとともに、前記対応付けられたエイリアスを、前記トークン端末に伝達し、
(j)前記トークン端末は、前記伝達されたエイリアスを、前記指定されたユーザIDとみなし、
前記使用者が、前記サーバが登録された前記トークン端末を用いて、前記アクセス端末を介して前記サーバへサインインするために、
(k)前記トークン端末は、前記取得されたキーコードとともに、前記ユーザIDとみなされて記録された前記エイリアスを、前記使用者へ、提示する
ように構成することができる。

また、上記認証システムにおいて、
前記受信されたユーザIDによる前記アクセス端末を介したサインインが許可された後、
前記サーバが、前記アクセス端末から他のユーザIDの指定を受け付けると、前記サインインが許可されたユーザIDと、前記指定された他のユーザIDと、が、同一の使用者の連絡先もしくは当該連絡先に対応付けられたエイリアスであるか否かを問う質問を、前記管理装置へ送り、
前記管理装置は、前記サインインが許可されたユーザIDと、前記他のユーザIDと、が、同一の使用者の連絡先もしくは当該連絡先に対応付けられたエイリアスであるか否かを示す返答を、前記サーバへ送る
ように構成することができる。

また、上記認証システムにおいて、
前記受信されたユーザIDによる前記アクセス端末を介したサインインが許可された後、
前記サーバが、前記アクセス端末から、前記サインインが許可されたユーザIDと、前記他のユーザIDと、の間で、アカウント情報を継承し、統合し、もしくは、置き換える依頼を受け付けると、前記サーバは、前記管理装置へ、前記質問を送り、
前記サインインが許可されたユーザIDと、前記他のユーザIDと、が、同一の使用者の連絡先もしくは当該連絡先に対応付けられたエイリアスである旨を示す回答が、前記管理装置から送られると、前記サーバは、前記依頼に係るアカウント情報の継承、統合、もしくは、置き換えを実行する
ように構成することができる。

また、上記認証システムにおいて、
前記認証システムは、互いに異なるサイトシードが互いに非公開に割り当てられた複数のサーバのそれぞれが、当該それぞれのサーバへのサインインを許可するか否かを判定するため、
前記管理装置は、前記複数のサーバのそれぞれに割り当てられたサイトシードを、当該それぞれのサーバと、他のサーバには非公開に共有し、
前記管理装置は、前記第1関数を、前記複数のサーバと非公開に共有し、
前記トークン端末は、前記使用者に、前記複数のサーバのいずれかに対応付けられた登録コードを指定させ、
前記トークン端末は、前記指定された登録コードに対応付けられたサーバを、前記トークン端末へ登録すべきサーバとする
ように構成することができる。

また、上記認証システムにおいて、
前記管理装置は、前記伝達されたユーザIDが有効であることが、
(x)確認済であれば、前記サーバに対するユーザシードを取得し、
(y)確認済でなければ、前記伝達されたユーザIDを宛先とする問合せを送付し、前記送付された問合せに対する回答があることをもって、前記問合せの宛先とされたユーザIDが有効であることを確認した後に、前記サーバに対するユーザシードを取得する
ように構成することができる。

また、上記認証システムにおいて、
前記サーバは、
前記受信されたユーザIDが、許可パターンにマッチすること、もしくは、禁止パターンにマッチしないことを、前記受信されたユーザIDによる前記アクセス端末を介したサインインを許可する必要条件とする
ように構成することができる。

また、上記認証システムにおいて、
前記アクセス端末は、前記ユーザIDにかえて、前記使用者がサインインしようとする前記サーバにおいて当該ユーザIDに対応付けられているユーザ識別情報を受け付け、
前記アクセス端末は、前記受け付けられたユーザ識別情報を前記サーバへ送信し、
前記サーバは、前記アクセス端末から送信されたユーザ識別情報を受信し、
前記サーバは、前記サーバにおいて前記受信されたユーザ識別情報に対応付けられているユーザIDを取得し、当該取得されたユーザIDを、前記受信されたユーザIDとみなす
ように構成することができる。

また、上記認証システムにおいて、
前記トークン端末は、前記アクセス端末により実現される
ように構成することができる。

また、上記認証システムにおいて、
前記管理装置は、前記サーバもしくは前記トークン端末により実現される
ように構成することができる。

このほか、コンピュータを、上記のトークン端末として機能させるプログラムならびに当該プログラムが記録された非一時的なコンピュータ読取可能な情報記録媒体を提供することができる。
また、コンピュータを、上記のサーバとして機能させるプログラムならびに当該プログラムが記録された非一時的なコンピュータ読取可能な情報記録媒体を提供することができる。
また、コンピュータを、上記の管理装置として機能させるプログラムならびに当該プログラムが記録された非一時的なコンピュータ読取可能な情報記録媒体を提供することができる。

本発明は、本発明の広義の精神と範囲を逸脱することなく、様々な実施の形態及び変形が可能とされるものである。また、上述した実施の形態は、この発明を説明するためのものであり、本発明の範囲を限定するものではない。すなわち、本発明の範囲は、実施の形態ではなく、特許請求の範囲によって示される。そして、特許請求の範囲内及びそれと同等の発明の意義の範囲内で施される様々な変形が、この発明の範囲内とみなされる。

本発明によれば、アクセス端末からサーバへサインインするためのキーコードを、トークン端末を用いて安全に使用者に提示するのに好適な認証システム、ならびに、コンピュータを当該トークン端末、管理装置、もしくはサーバとして機能させるプログラムを記録した非一時的なコンピュータ読取可能な情報記録媒体を提供することができる。

101 認証システム
121 トークン端末
141 アクセス端末
161 サーバ
181 管理装置
401 ユーザID入力フォーム
402 ユーザID入力欄
403 「次へ」ボタン
404 「キャンセル」ボタン
411 符丁情報入力フォーム
412 符丁情報入力欄
413 ユーザID表示欄
421 サーバ登録フォーム
422 コラボコード入力欄
423 ユーザIDリスト
431 サービス選択フォーム
432 スロットボタン
441 キーコードフォーム
442 キーコード欄
443 ユーザID欄
444 サーバ欄
445 「開く」ボタン

Claims (12)

1. トークン端末を用いて、サイトシードが非公開に割り当てられたサーバへの、アクセス端末を介したサインインを許可するか否かを、前記サーバが判定するための認証システムであって、
   (1)前記トークン端末を使用する使用者が、前記サーバを前記トークン端末へ登録するために、
   (a)前記トークン端末は、
   前記サーバへサインインするためのアクセス情報を指定され、
   前記指定されたアクセス情報を前記サーバへ伝達し、
   (b)前記サーバは、
   少なくとも、前記伝達されたアクセス情報と、前記サーバに割り当てられたサイトシードと、に、第1関数を適用することにより、前記サーバに対するユーザシードを取得し、
   前記取得されたユーザシードを前記トークン端末に伝達し、
   (c)前記トークン端末は、
   前記伝達されたユーザシードを記録することにより、前記サーバを前記トークン端末へ登録し、
   (2)前記使用者が、前記サーバが登録された前記トークン端末を用いて、前記アクセス端末を介した前記サーバへのサインインを試行するために、
   (d)前記トークン端末は、
   前記試行されるサインインに対して前記サーバから独立して取得され、前記サーバと共有されるべき共有シードを取得し、
   少なくとも、前記取得された共有シードと、前記記録されたユーザシードと、に第2関数を適用することにより、キーコードを取得し、
   前記使用者へ、前記取得されたキーコードを提示し、
   (e)前記アクセス端末は、
   前記トークン端末により前記使用者へ提示されたキーコードを受け付け、
   前記受け付けられたキーコードが指定された要求を、前記サーバへ送信し、
   (f)前記サーバは、
   前記送信された要求を受信し、
   前記受信された要求に係るアクセス情報を取得し、
   少なくとも、前記取得されたアクセス情報と、前記サーバに割り当てられた前記サイトシードと、に、前記第1関数を適用することにより、照合シードを取得し、
   前記試行されるサインインに対して前記トークン端末から独立して取得され、前記トークン端末と共有されるべき共有シードを取得し、
   少なくとも、前記取得された共有シードと、前記取得された照合シードと、に前記第2関数を適用することにより、照合コードを取得し、
   前記受信されたキーコードと、前記取得された照合コードと、が一致することを、前記アクセス端末を介した前記要求に係るサインインを許可する必要条件とする
   ことを特徴とする認証システム。
2. 前記トークン端末において、前記指定されるアクセス情報には、前記サーバへサインインするためのユーザIDが含まれ、
   前記アクセス端末は、前記サーバへサインインするためのユーザIDを受け付け、
   前記アクセス端末は、前記受け付けられたユーザIDを、前記サーバへ送信し、もしくは、前記要求に指定してから前記要求を前記サーバへ送信し、
   前記サーバにおいて、前記取得されるアクセス情報には、前記送信されたユーザID、もしくは、前記要求に指定されたユーザIDが含まれる
   ことを特徴とする請求項1に記載の認証システム。
3. 前記トークン端末は、所定単位で表現された現在の日時を、前記共有シードとして取得し、
   前記サーバは、前記所定単位で表現された現在の日時を、前記共有シードとして取得する
   ことを特徴とする請求項1に記載の認証システム。
4. 前記トークン端末は、前記伝達されたユーザシードと、前記指定されたユーザIDと、を対応付けて記録し、
   前記トークン端末は、前記記録されたユーザIDを、前記共有シードとして取得し、
   前記サーバは、前記受信されたユーザIDを、前記共有シードとして取得する
   ことを特徴とする請求項2に記載の認証システム。
5. 前記サーバは、キャプチャ(CAPTCHA)を生成し、
   前記サーバは、前記生成されたキャプチャを、前記共有シードとして取得し、
   前記サーバは、前記生成されたキャプチャを前記アクセス端末へ送り、
   前記アクセス端末は、前記サーバから送られた前記キャプチャを前記使用者に提示し、
   前記トークン端末は、前記アクセス端末により提示された前記キャプチャを前記トークン端末へ入力するよう前記使用者に促し、
   前記トークン端末は、前記入力されたキャプチャを、前記共有シードとして取得する
   ことを特徴とする請求項1に記載の認証システム。
6. 前記トークン端末において、前記指定されるアクセス情報には、前記サーバへサインインするための前記アクセス端末に割り当てられた端末識別情報が含まれ、
   前記サーバは、前記要求を受信することにより、当該要求を送信した前記アクセス端末に割り当てられた端末識別情報を取得し、
   前記サーバは、前記取得された端末識別情報を含む前記アクセス情報を取得する
   ことを特徴とする請求項1に記載の認証システム。
7. 前記トークン端末は、前記伝達されたユーザシードと、前記指定されたユーザIDと、を対応付けて記録し、
   前記トークン端末は、前記記録されたユーザIDのエイリアスを生成して、前記生成されたエイリアスを、前記共有シードとして取得し、
   前記生成されたエイリアスを、前記サーバへサインインするためのユーザIDとして、前記アクセス端末に受け付けさせるよう、前記使用者へ促し、
   前記サーバは、前記受信されたユーザIDを、前記共有シードとして取得し、
   前記サーバは、前記受信されたユーザIDをエイリアスとする元のユーザIDを取得し、
   前記サーバは、前記アクセス端末を介したサインインを、前記取得された元のユーザIDに係るアカウント情報に対して、許可する
   ことを特徴とする請求項2に記載の認証システム。
8. 前記第1関数は、一方向性関数であり、当該第1関数が適用された結果のビット数は、当該第1関数が適用される引数のビット数以上であり、
   前記第2関数は、ハッシュ関数であり、前記第2関数の適用結果は、所定の長さの文字列である
   ことを特徴とする請求項1に記載の認証システム。
9. 前記サーバは、
   前記受信されたユーザIDが、許可パターンにマッチすること、もしくは、禁止パターンにマッチしないことを、前記受信されたユーザIDによる前記アクセス端末を介したサインインを許可する必要条件とする
   ことを特徴とする請求項2に記載の認証システム。
10. 前記アクセス端末は、前記ユーザIDにかえて、前記使用者がサインインしようとする前記サーバにおいて当該ユーザIDに対応付けられているユーザ識別情報を受け付け、
    前記アクセス端末は、前記受け付けられたユーザ識別情報を前記サーバへ送信し、
    前記サーバは、前記アクセス端末から送信されたユーザ識別情報を受信し、
    前記サーバは、前記サーバにおいて前記受信されたユーザ識別情報に対応付けられているユーザIDを取得し、当該取得されたユーザIDを、前記受信されたユーザIDとみなす
    ことを特徴とする請求項2に記載の認証システム。
11. コンピュータを、請求項1に記載のトークン端末として機能させることを特徴とするプログラム。
12. コンピュータを、請求項1に記載のサーバとして機能させることを特徴とするプログラム。

Images