図1は、この発明の一実施形態による情報通信システム2の構成を示すブロック図である。情報通信システム2は、情報通信網8に接続される複数の機器としての第1の機器6および第2の機器7と、情報通信網8に接続されるサーバ装置4と、を備えている。
なお、図1は、1の第1の機器6と1の第2の機器7とのペアリングを成立させる場合の例であるが、1の第1の機器6と複数の第2の機器7とのペアリングを成立させるよう構成することもできる(後述)。
つぎに、図2は、第1の機器6、第2の機器7およびサーバ装置4の構成を例示するブロック図である。
図2に示すように、第1の機器6は第1制御部10を備えている。第1制御部10はペアリング提供処理部11を備えている。
ペアリング提供処理部11はペアリング提供処理を実行する。ペアリング提供処理において、提供用文字列が第1の機器6の表示装置に表示される。提供用文字列は、一定時間ごとに桁上げしつつ最下位桁に新たな文字を追加することで一定時間ごとに変化するよう構成された一定桁数の文字列である。また、ペアリング提供処理において、提供用文字列を含むペアリング提供情報がサーバ装置4に送信される。
第2の機器7は、第2制御部15を備えている。第2制御部15はペアリング受諾処理部16を備えている。
ペアリング受諾処理部16はペアリング受諾処理を実行する。ペアリング受諾処理において、受諾用文字列が第2の機器7の表示装置に表示される。受諾用文字列は、第1の機器6の表示装置に表示された提供用文字列に基づいて第2の機器7の入力装置から入力された文字列である。また、ペアリング受諾処理において、受諾用文字列を含むペアリング受諾情報がサーバ装置4に送信される。
ペアリング受諾処理部16は桁上げ処理部17を備えている。桁上げ処理部17は、第1の機器6における提供用文字列の変化に対応するために、変化前の提供用文字列に対応する受諾用文字列を桁上げしつつ最下位桁に第2の機器7の入力装置から入力された新たな文字に対応する文字を追加することで、変化後の提供用文字列に対応する受諾用文字列を生成する。
桁上げ処理部17は、さらに、第1の機器6における提供用文字列の桁上げに同期して受諾用文字列の桁上げを行うよう構成されている。
サーバ装置4はサーバ側制御部20を備えている。サーバ側制御部20はペアリング判定処理部21を備えている。
ペアリング判定処理部21は、第1の機器6から受信したペアリング提供情報に含まれる提供用文字列と、第2の機器7から受信したペアリング受諾情報に含まれる受諾用文字列とを比較し、これらが一致すると判定したことを条件として、第1の機器6と第2の機器7との間にペアリングが成立したと判定する。
ペアリング判定処理部21は、さらに、再ペアリング実行指示処理部22を備えている。
再ペアリング実行指示処理部22は、第2の機器7から受信したペアリング受諾情報に含まれる受諾用文字列と一致する提供用文字列に対応する第1の機器6が複数存在する場合は、複数の第1の機器6に対して、再度、ペアリング提供処理を実行するよう促すとともに、第2の機器7に対して、再度、ペアリング受諾処理を実行するよう指示する。
第2の機器7のペアリング受諾処理部16は、さらに、確認用文字列表示処理部18を備えている。
確認用文字列表示処理部18は、サーバ装置4のペアリング判定処理部21において提供用文字列と受諾用文字列とが一致すると判定されたことを条件として、第2の機器7の表示装置に確認用文字列を表示する。
第1の機器6のペアリング提供処理部11は、さらに、応答用文字列取得処理部12を備えている。
応答用文字列取得処理部12は応答用文字列を取得する。応答用文字列は、第2の機器7の表示装置に表示された確認用文字列に基づいて第1の機器6の入力装置から入力された文字列である。
サーバ装置4のペアリング判定処理部21は、さらに、第2の機器7の表示装置に表示された確認用文字列と第1の機器6によって取得された応答用文字列とが一致したことを条件として、第1の機器6と第2の機器7とのペアリングが成立したと判定するよう構成されている。
サーバ装置4はデータベース25を備えている。データベース25は待受けテーブル26を備えている。待受けテーブル26については後述する。
つぎに、図3は、応用例としての情報通信システム2を構成する、サービス用機器40および認証用機器30の構成を例示するブロック図である。
サービス用機器40は特定のサービスを提供する機器である。認証用機器30は特定のサービスを利用する際の認証を行う機器である。
図3に示す情報通信システム2は、第1の機器6および第2の機器7の一方を、サービス用機器40とし、他方を認証用機器30として、サービス用機器40と認証用機器30とのペアリングが成立したことを前提に、特定のサービスを利用可能とするための認証を行うシステムである。
図3に示すように、認証用機器30は認証側制御部31を備えている。認証側制御部31は認証側登録部32を備えている。
認証側登録部32は、認証用機器30側の秘密鍵である認証側秘密鍵と当該認証側秘密鍵に対応する公開鍵である認証側公開鍵とを生成して、当該認証側秘密鍵を記憶するとともに、当該認証側公開鍵をサービス用機器40に送信する。
サービス用機器40はサービス側制御部41を備えている。サービス側制御部41はサービス側登録部42を備えている。
サービス側登録部42は、認証用機器30から認証側公開鍵を受信すると、特定のサービスに係る認証用機器30の識別標識である内部ユーザIDを生成し、認証側公開鍵を当該内部ユーザIDに対応付けて記憶するとともに、当該内部ユーザIDを認証用機器30に送信する。
サービス用機器40のサービス側制御部41は、サービス側暗号部43を備えている。
サービス側暗号部43は、認証用機器30から内部ユーザIDを指定した認証を求める情報を受信すると、サービス側暗号化データを生成し、認証用機器30に送信する。サービス側暗号化データは、当該サービス用機器40において用意した任意のデータであるサービス側元データを、サービス側登録部42に記憶されている内部ユーザIDに対応する認証側公開鍵を用いて暗号化したデータである。
認証用機器30の認証側制御部31は、認証側復号部34を備えている。
認証側復号部34は、サービス側復号化データに所定の演算を施して得られるサービス側演算化データをサービス用機器40に送信する。サービス側復号化データは、サービス用機器40から受信したサービス側暗号化データを、当該認証側登録部32に記憶されている認証側秘密鍵を用いて復号化したデータである。
サービス用機器40のサービス側制御部41は内部ユーザID真正判定部45を備えている。
内部ユーザID真正判定部45は、認証用機器30から受信したサービス側演算化データが、サービス側元データに当該所定の演算を施して得られるデータと一致する場合は、内部ユーザIDが真正であると判定する。
サービス側登録部42は、さらに、当該サービス用機器40側の秘密鍵であるサービス側秘密鍵と当該サービス側秘密鍵に対応する公開鍵であるサービス側公開鍵とを生成して、当該サービス側秘密鍵を記憶するとともに、当該サービス側公開鍵を、当該サービス用機器40に係る特定のサービスの識別標識であるサービスIDとともに、認証用機器30に送信する。
認証側登録部32は、さらに、サービス用機器40からサービス側公開鍵を受信すると、当該サービス側公開鍵を当該サービスIDと関連付けて記憶する。
認証用機器30の認証側制御部31は、認証側暗号部33を備えている。
認証側暗号部33は、サービス用機器40からサービスIDを指定した認証を求める情報を受信すると、認証側暗号化データを生成し、サービス用機器40に送信する。認証側暗号化データは、当該認証用機器30において用意した任意のデータである認証側元データを、認証側登録部32に記憶されているサービスIDに対応するサービス側公開鍵を用いて暗号化したデータである。
サービス用機器40のサービス側制御部41は、サービス側復号部44を備えている。
サービス側復号部44は、認証側復号化データに所定の演算を施して得られる認証側演算化データを認証用機器30に送信する。認証側復号化データは、認証用機器30から受信した認証側暗号化データを、当該サービス側登録部42に記憶されているサービス側秘密鍵を用いて復号化したデータである。
認証用機器30の認証側制御部31は、サービスID真正判定部35を備えている。
サービスID真正判定部35は、サービス用機器40から受信した認証側演算化データが、認証側元データに当該所定の演算を施して得られるデータと一致する場合は、サービスIDが真正であると判定する。
認証用機器30は認証側テーブル36を備えている。サービス用機器40はサービス側テーブル46を備えている。これらのテーブル36、46については後述する。
つぎに、図4は、図2または図3に示すサーバ装置4、第1の機器6および第2の機器7(第1の機器6または第2の機器7でもある認証用機器30またはサービス用機器40を含む。以下同様。)のハードウェア構成の一例を示すブロック図である。
サーバ装置4は、とくに限定されるものではないが、この例では、一般的なサーバコンピュータと同様の構成である。
サーバ装置4は、情報通信システム2のサーバ装置4側のプログラムを記憶した記録媒体であり、データベース25の記憶媒体でもあるハードディスクを備えたHDD(ハードディスクドライブ)等の補助記憶装置55、補助記憶装置55に記憶されたプログラムがロードされる主記憶装置54、主記憶装置54にロードされたプログラムを実行するサーバ側制御部20に対応するCPU51,LCD(液晶表示装置)等の表示装置52,キーボード、マウス、トラックパッド等の入力装置53、および、情報通信網8を介して第1の機器6または第2の機器7と通信するための通信インタフェース56を備えている。
第1の機器6は、とくに限定されるものではなく、たとえばパーソナルコンピュータであってもよいし、タブレット型コンピュータであってもよいし、携帯情報端末装置であってもよいし、いわゆるスマートフォンに代表される携帯電話機であってもよい。さらに、家庭用電気機器、生産用機器、自動車などの運輸用機器であってもよい。第2の機器7についても同様である。要は、情報通信網8に接続される機器であれば、第1の機器6または第2の機器7として、本願発明を適用することができる。
図4は、第1の機器6および第2の機器7が、いずれもスマートフォンである場合のハードウェア構成を例示したものである。
第1の機器6は、情報通信システム2の第1の機器6側のプログラムを記憶した記録媒体であるフラッシュメモリを搭載したSSD(ソリッドステートドライブ)等の補助記憶装置65、補助記憶装置65に記憶されたプログラムがロードされる主記憶装置64、主記憶装置64にロードされたプログラムを実行する第1制御部10に対応するCPU61、LCD(液晶表示装置)等の表示装置62,入力キー、タッチパネル等の入力装置63、および、情報通信網8を介してサーバ装置4および第2の機器7と通信するための通信インタフェース66、を備えている。
第2の機器7も、第1の機器6と同様のハードウェア構成である。
情報通信網8は、情報を伝達するための通信ネットワークであって、有線、無線の別を問わない。情報通信網8として、インターネットに代表されるWAN(Wide Area Network)、LAN(Local Area Network)等のコンピュータネットワーク、電話回線(携帯電話回線を含む。以下同様。)あるいはこれらを組合わせたものが例示される。
つぎに、図5〜図10は、本願におけるペアリングを実行する処理(以下、「ペアリング処理」ということがある。)の流れの一例を示すフローチャートである。以下、サーバ装置4をサーバ4、第1の機器6をプロバイダ6、第2の機器7をレジスタ7ということがある。また、情報通信網8として、インターネット、または、インターネットと電話回線とを組み合わせたものを例に説明する。
図11A〜図15Bは、ペアリング処理における、プロバイダ6またはレジスタ7の表示画面の一例を示す図面である。図16は、待受けテーブル26のデータ構成の一例を示す図面である。図17A、図17Bは、ペアリング処理における一部の処理を説明するための図面である。
図5〜図17Bを参照しつつ、ペアリング処理について説明する。
図5に示すように、プロバイダ6のCPU61(以下、単に「プロバイダ6」ということがある。)は、提供用文字列の表示指示の有無を監視している(ステップS1)。
ステップS1において、プロバイダ6の入力装置63(以下、単に「プロバイダ6」ということがある。)から、提供用文字列の表示指示が入力されると、ストリームシードを生成し、生成したストリームシードとタイムヘッダとの組み合わせであるストリームシードデータを、プロバイダ6の記憶装置、すなわち、主記憶装置64または補助記憶装置65(以下、単に「プロバイダ6」ということがある。)に記憶するとともに、サーバ4に送信する。(ステップS2)。
ストリームシードとは、提供用文字列の素となる文字列であって、提供用文字列の桁数より大きい桁数の文字列である。ストリームシードの構成はとくに限定されるものではないが、たとえば、乱数により構成することができる。
なお、提供用文字列の文字種および文字数は、とくに限定されるものではないが、この実施形態においては、提供用文字列が4桁の数字である場合を例に説明することとする。そして、ストリームシードを183桁の数字としている。この理由については後述する。
タイムヘッダは、ストリームシードから提供用文字列を抽出するタイミングの基準となる時刻である。タイムヘッダの決定方法については、後述する。
サーバ4のCPU51(以下、単に「サーバ4」ということがある。)は、ストリームシードデータを受信すると、待受けテーブル26を検索し、受信したストリームシードデータに一致する既登録のストリームシードデータが存在するか否かをチェックする(ステップS3、ステップS4)。
受信したストリームシードデータに一致する既登録のストリームシードデータが存在する場合は、プロバイダ6に対し、ストリームシードデータ再生成の要求を送信し、要求を受けたプロバイダ6は、ステップS2に制御を戻す(ステップS5)。
一方、ステップS4において、受信したストリームシードデータに一致する既登録のストリームシードデータが存在しない場合、サーバ4は、当該ペアリング(セッション)を特定する識別標識としてプロバイダIDを生成し、プロバイダIDと受信したストリームシードデータとを対応付けたレコードを、新たに待受けテーブル26に登録する(ステップS6)。
図16に示すように、待受けテーブル26のレコードは、プロバイダIDおよびストリームシードデータの2つのフィールドにより構成され、ストリームシードデータは、タイムヘッダおよびストリームシードの2つのサブフィールドにより構成されている。
つぎに、サーバ4は、プロバイダ6に対し、プロバイダID(この例では、図16に示す待受けテーブル26の最上行のレコードに対応する「123456」)を含むペアリングの待受け開始要求を送信する(ステップS7)。
この要求を受信したプロバイダ6は、プロバイダIDを記憶するとともに、提供用文字列の表示画面を初期化し(ステップS8)、提供用文字列を表示する(ステップS9)。
図11Aに示すように、プロバイダ6の初期化された表示画面80の提供用文字列表示部81には、提供用文字列「3517」が表示されている。これは、ステップS2においてプロバイダ6に記憶されたストリームシードの先頭桁から連続する4桁の数字を抽出したものである。当然のことながら、この数字は、図16に示す待受けテーブル26におけるプロバイダID「123456」に対応するストリームシードの先頭から連続する4桁の数字に一致している。
つぎに、プロバイダ6は、提供用文字列の桁上げタイミングが到来したか否かを監視しており(ステップS10)、桁上げタイミングが到来すると、提供用文字列の桁上げ処理を行い、制御をステップS9に戻す(ステップS11)。
提供用文字列の桁上げタイミングはとくに限定されるものではないが、この実施形態においては、当該ストリームシードに対応するタイムヘッダの示す時刻から10秒経過ごとに桁上げ処理を実行するよう構成している。
なお、タイムヘッダは、当該ストリームシードの生成時刻および提供用文字列の桁上げの時間間隔に基づいて決定される。内部時計の基準時、たとえば、午前0時からストリームシードの生成時刻までの経過時間を提供用文字列の桁上げの時間間隔で除した値の整数部分と提供用文字列の桁上げの時間間隔との積に相当する時刻とすることができる。
この例では、提供用文字列の桁上げの時間間隔が10秒であるから、当該ストリームシードの生成時刻から10秒未満の端数を減じた時刻がタイムヘッダの示す時刻となっている。
図11Bに示すように、桁上げ処理が実行された後の表示画面80の提供用文字列表示部81には、提供用文字列「5179」が表示されている。これは、ステップS2においてプロバイダ6に記憶されたストリームシードの第2桁から連続する4桁の数字を抽出したものである。当然のことながら、この数字は、図16に示す待受けテーブル26におけるプロバイダID「123456」に対応するストリームシードの第2桁から連続する4桁の数字に一致している。
以下、同様に、桁上げ処理が実行されるたびに、提供用文字列は、「1797」(図11C参照)、「7973」(図11D参照)へと変化する。
一般的な表現を用いれば、この実施形態においては、提供用文字列の桁数をn桁とし、ストリームシードを構成する文字列の文字数をm(m>n)桁としたとき、ストリームシードを構成する文字列の先頭から連続するn桁の文字列を抽出して提供用文字列を構成するとともに、一定時間経過ごとに抽出する文字列を1桁下位にずらせることで、提供用文字列を一定時間ごとに変化するよう構成している。
上述のように、この例では、ストリームシードを183桁の数字としている。これは、提供用文字列を4桁の数字とし、10秒経過ごとに提供用文字列の桁上げ処理を行うとして、最大30分間の待受けを可能とするためである。もちろん、ストリームシードの桁数は、これに限定されるものではない。
つぎに、図6に示すように、レジスタ7のCPU61(以下、単に「レジスタ7」ということがある。)は、受諾用文字列の入力画面の起動指示の有無を監視している(ステップS12)。
ステップS12において、レジスタ7の入力装置63(以下、単に「レジスタ7」ということがある。)から、受諾用文字列の入力画面の起動指示が入力されると、レジスタ7は、初期パラメータの設定を行うとともに、対象プロバイダ値に「ALL」をセットする(ステップS13)。
初期パラメータの設定には、内部時計の校正が含まれる。内部時計の校正は、たとえば、インターネット上の特定のタイムサーバとの間で時刻を同期することにより行われる。なお、内部時計の校正は、プロバイダ6においても同様の方法で適時実行されており、その結果、両者の間で内部時計の同期がとれている。
対象プロバイダ値については、後述する。
つづいて、レジスタ7は、受諾用文字列を入力するための画面を初期化して表示する(ステップS14)。
図12Aに示すように、レジスタ7の初期化された表示画面70には、入力用キーボタン73が表示され、数字入力が可能となっている。残時間表示部74には、後述の受諾用文字列の桁上げまでの残時間がグラフ(この例では棒グラフ)表示されている。この例では、残時間が少なくなるほど棒グラフの長さが短くなるよう構成されている。受諾用文字列表示部71には、まだ何も表示されていない。ペアリングボタン72は、受諾用文字列表示部71に4桁の数字が表示されたとき以外は操作できないよう構成されている。
図11Aに示すプロバイダ6の表示画面80の提供用文字列表示部81に表示された提供用文字列「3517」を見たレジスタ7の操作者により、レジスタ7への受諾用文字列の入力が行われると(ステップS15)、レジスタ7は、ペアリングボタン72が操作されたか否かを判断する(ステップS16)。
レジスタ7への受諾用文字列の入力が行われた状態の表示画面70を図12Bに示す。なお、この状態では、ペアリングボタン72は操作可能となっている。
ステップS16においてペアリングボタン72が操作されないときは、レジスタ7は、受諾用文字列の桁上げタイミングが到来したか否かを監視し(ステップS17)、桁上げタイミングが到来すると、受諾用文字列の桁上げ処理を行い、制御をステップS15に戻す(ステップS18)。
受諾用文字列の桁上げはプロバイダ6における提供用文字列の桁上げと同期して行われるよう構成されている。すなわち、受諾用文字列の桁上げのタイミングは、提供用文字列の桁上げのタイミングと同様の方法で決定される。この例では、レジスタ7の内部時計の正10秒毎に受諾用文字列の桁上げを行えば、プロバイダ6における提供用文字列の桁上げと同期することになる。
図12Cに示すように、桁上げ処理が実行された後の表示画面70の受諾用文字列表示部71には、新たな受諾用文字列の上3桁「517」が表示され、受諾用文字列の最下位桁が空白となっている。この状態においては、ペアリングボタン72は操作不能となっている。
この状態から、図11Bに示すプロバイダ6の表示画面80の提供用文字列表示部81に表示された提供用文字列「5179」を見たレジスタ7の操作者により、受諾用文字列の最下位桁に1桁の数字(この場合は「9」)が入力されると、図12Dに示すように、表示画面70の受諾用文字列表示部71には、完全な受諾用文字列「5179」が表示され、ペアリングボタン72は操作可能となる。
しかし、何らかの理由でペアリングボタン72を操作するのが遅れ、その間に、プロバイダ6の表示画面80に表示された提供用文字列が、「1797」(図11C参照)、「7973」(図11D参照)と変化してしまった場合でも、レジスタ7の操作者により、既入力の受諾用文字列の最下位桁に「7」、「3」を追加入力することで、レジスタ7の表示画面70の受諾用文字列表示部71には、現時点における完全な受諾用文字列「7973」が表示され、ペアリングボタン72は操作可能となる。
ここで、ペアリングボタン72が操作されると、レジスタ7は、入力された受諾用文字列、タイムスタンプ、および、対象プロバイダ値(ステップS13において設定された値、または、後述のステップS25において設定された値)をサーバ4に送信する(ステップS19)。
タイムスタンプは、当該ペアリングボタン72の操作時刻および提供用文字列の桁上げの時間間隔に基づいて、上記タイムヘッダの決定方法と同様の方法で決定される。
つぎに、図7に示すように、サーバ4は、受信した受諾用文字列、タイムスタンプ、および、対象プロバイダ値に基づいて待受けテーブル26を検索し(ステップS20)、該当するプロバイダ6の有無を判断する(ステップS21)。
ステップS20、ステップS21について詳述する。
対象プロバイダ値とは、上記ステップS20における待受けテーブル26の検索の対象となるレコードを特定するための情報であり、対象プロバイダ値として設定されたプロバイダIDを持つレコードが検索の対象となる。対象プロバイダ値が「ALL」の場合は、待受けテーブル26の全レコードが検索対象となる。
ステップS20において受信した受諾用文字列、タイムスタンプ、および、対象プロバイダ値を図17Aに例示する。この場合、対象プロバイダ値が「ALL」であるから、待受けテーブル26の全レコードが検索対象となる。
タイムスタンプの時刻と待受けテーブル26の検索対象となるレコードのタイムヘッダの時刻との差を、提供用文字列の桁上げの時間間隔(この例では10秒)で除した値sを算出する。
提供用文字列の桁数をn桁(この例では4桁)とした場合、当該レコードのストリームシードを構成する文字列の先頭桁からs桁下位にずれた位置にある文字を先頭とする連続するn桁の文字列を抽出し、この抽出した文字列と受信した受諾用文字列とを比較する。
両者が一致すれば、ステップS21において、該当するプロバイダ6が存在すると判断される。
たとえば、図17Aに示す受信情報と、図17Bに示す待受けテーブル26のプロバイダID「123456」であらわされるレコードとを比較すれば、上記s=3となる。これに基づいて当該レコードのストリームシードを構成する文字列から抽出した4桁の文字列は「7973」となり、これは、図17Aに示す受諾用文字列「7973」に一致する。したがって、この場合、ステップS21において、該当するプロバイダ6が存在すると判断されることになる。
検索対象となっているレコードすべてについて、上記判断が行われる。
この結果、ステップS21において該当するプロバイダ6が存在しないと判断されると、その旨の情報が、サーバ4からレジスタ7に送信され、図13Aに示すように、レジスタ7の表示画面70に「無効なPINです」との表示がなされる(ステップS22)。この表示は、当該レジスタ7から入力されサーバ6に送信された受諾用文字列が無効であることを示す表示である。
ステップS22の表示後、レジスタ7は、制御をステップS13(図6参照)に戻す。
一方、ステップS21において該当するプロバイダ6が存在すると判断されると、サーバ4は、該当するプロバイダの数が1つか複数かを判断する(ステップS23)。
ステップS23において、該当するプロバイダの数が複数であると判断すると、サーバ4は、該当するすべてのプロバイダ6に対し、その旨の情報を送信し、この情報を受信したプロバイダ6は、制御をステップS2(図5参照)に戻し、再度、ストリームシードの生成・送信から始める。
ステップS23において、該当するプロバイダ6の数が複数となるのは、ペアリングの待受けをしている複数のプロバイダ6間で、ある時点での提供用文字列が偶然に一致したためであると考えられる。そこで、当該プロバイダ6に対して、再度、ストリームシードの生成・送信からやり直しをさせ、偶然の一致を解消して、所望の相手とのペアリングを実現させるのである。
なお、ステップS23において、該当するプロバイダの数が複数であると判断された場合、制御を、ステップS2ではなくステップS9(図5参照)に戻し、該当する各プロバイダに、提供用文字列の表示を継続させるよう構成することもできる。提供用文字列の桁上げの時間間隔(この例では10秒)が経過すると提供用文字列が自動的に変化するため、変化後の提供用文字列が、該当する複数のプロバイダ間で再び一致する可能性は、極めて低いと考えられるからである。
なお、ステップS23において、該当するプロバイダの数が複数であると判断すると、サーバ4は、レジスタ7に対して、その旨および該当する複数のプロバイダIDを含む情報を送信する(ステップS24)。
この情報を受信したレジスタ7は、上記ステップS13(図6参照)と同様の処理を行う(ステップS25)。ただし、ステップS13と異なり、ステップS25においては、対象プロバイダ値として、サーバ4から受信した複数のプロバイダIDのリストが設定される。
つづいて、図13Bに示すように、レジスタ7の表示画面70に「追加の認証を求められています」との表示がなされる(ステップS26)。この表示は、当該レジスタ7から入力されサーバ6に送信された受諾用文字列によっては、ペアリングが成立しなかったことを示すエラー表示である。
当該表示画面70に表示された「続ける」ボタン75が操作されると、レジスタ7は、制御をステップS14(図6参照)に戻し、再度、受諾用文字列の入力画面の初期化からやり直す。
一方、ステップS23において該当するプロバイダ6の数が1つであると判断されると、サーバ4は、その旨の情報を当該プロバイダ6に送信し、図8に示すように、この情報を受信したプロバイダ6において、当該情報に係るペアリングのモードがマルチプルペアリングモードであるか否かが判断される(ステップS27)。
図14に示すように、マルチプルペアリングモードとは、1のプロバイダ6と複数のレジスタ7a、7b、7cとの間のペアリング(マルチプルペアリング)を許容するモードである。これは、1のプロバイダ6と1のレジスタ7a、1のプロバイダ6と1のレジスタ7b、1のプロバイダ6と1のレジスタ7cからなる3つのシングルペアリング(1対1のペアリング)を1回のペアリング処理で実現するモードと見ることができる。
なお、当該ペアリングのモードがマルチプルペアリングモードであるかシングルペアリングモード(1回のペアリング処理で1つのシングルペアリングのみを許容するモード)であるかは、前もって(たとえば図5に示すステップS1において)設定されて、プロバイダ6に記憶されている。
ステップS27において、マルチプルペアリングモードであると判断されると、当該レジスタ(たとえば、図14に示すレジスタ7a)に、その旨およびプロバイダIDを含む情報が送信され、当該レジスタ7aの表示画面70に、ペアリングが成功した旨の表示(図示せず)がなされ(ステップS32)、ペアリング処理は続行される。
この場合、プロバイダ6の操作者が、残りのレジスタ(たとえば、図14に示すレジスタ7b、レジスタ7c)との間のペアリングが成功したと判断した場合や、ペアリング処理を中止すると判断した場合の処理については、後述する。
一方、ステップS27において、マルチプルペアリングモードでないと判断されると、つぎに、プロバイダ6において、当該情報に係るペアリングのモードがセーフペアリングモードであるか否かが判断される(ステップS28)。
セーフペアリングモードとは、より安全にペアリングを行うためのモードである。当該ペアリングのモードがセーフペアリングモードであるか通常のペアリングモード(セーフペアリングモードでないモード)であるかは、前もって(たとえば図5に示すステップS1において)設定されて、プロバイダ6に記憶されている。
ステップS28において、セーフペアリングモードでないと判断されると、プロバイダ6はサーバ4に、プロバイダIDを含むペアリング待受け終了コマンドを送信する(ステップS29)。
サーバ4は、ペアリング待受け終了コマンドを受信すると、待受けテーブル26のレコードのうち、当該プロバイダIDに対応するレコードを無効化する(ステップS31)。当該プロバイダIDに対応するペアリングが成立したため、当該レコードを維持する必要がなくなったからである。レコードの無効化は、たとえば、当該レコードの削除や、当該レコードに無効フラグをたてる等の方法により行うことができる。
これと同時に、当該プロバイダ6の表示画面80に、ペアリングが成功した旨の表示(図示せず)がなされる(ステップS30)。また、ペアリングの相手となるレジスタ7に、その旨およびプロバイダIDを含む情報が送信され、当該レジスタ7の表示画面70に、ペアリングが成功した旨の表示(図示せず)がなされ(ステップS32)、ペアリング処理は終了する。
一方、ステップS28において、セーフペアリングモードであると判断されると、図9に示すように、プロバイダ6はレジスタ7に、確認用文字列発行要求およびプロバイダIDを含む情報を送信する(ステップS33)。
確認用文字列発行要求を受信したレジスタ7は、確認用文字列を発行し(ステップS34)、発行した確認用文字列を表示する(ステップS35)。
図15Aに示すように、レジスタ7の表示画面70の確認用文字列表示部76には、確認用文字列「8451」が表示されている。確認用文字列の生成方法はとくに限定されるものではないが、たとえば、レジスタ7の乱数生成機能を利用して生成することができる。確認用文字列の文字種、文字数はとくに限定されるものではないが、ここでは、4桁の数字を例示する。
一方、図15Bに示すように、プロバイダ6の表示画面80には、入力用キーボタン83が表示され、数字入力が可能となっている。確認ボタン85は、応答用文字列が入力されて応答用文字列表示部84に4桁の数字が表示されたとき以外は操作できないよう構成されている。
図15Aに示すレジスタ7の表示画面70の確認用文字列表示部76に表示された確認用文字列「8451」を見たプロバイダ6の操作者により、プロバイダ6への応答用文字列の入力が行われ、確認ボタン85が操作されると(ステップS36)、プロバイダ6は、入力された応答用文字列をレジスタ7に送信する(ステップS37)。
レジスタ7は、受信した応答用文字列と確認用文字列とを比較し(ステップS38)、一致しない場合は、当該ペアリングが失敗した旨の表示(図示せず)を行う(ステップS40)。
一方、ステップS38において、応答用文字列と確認用文字列とが一致した場合は、当該レジスタ7の表示画面70に、ペアリングが成功した旨の表示(図示せず)がなされるとともに(ステップS39)、上記ステップS29(図8参照)に制御を移す。
さて、図10に示すように、プロバイダ6は、待受け終了指示を監視している(ステップS41)。
図14に示すマルチプルペアリングモードにおいて、プロバイダ6の操作者が、残りのレジスタ(たとえば、図14に示すレジスタ7b、レジスタ7c)との間のペアリングが成功したと判断した場合や、ペアリング処理を中止すると判断した場合、待受け終了ボタン82を操作することで、ペアリング処理を中止することができる。シングルペアリングモードにおいて、ペアリング成立前にペアリング処理を中止する場合も、同様である。
待受け終了ボタン82が操作されると、プロバイダ6はサーバ4に、プロバイダIDを含むペアリング待受け終了コマンドを送信し、上記ステップS31(図8参照)に制御が移される(ステップS42)。
これと同時に、当該プロバイダ6の表示画面80に、待受けが終了した旨の表示(図示せず)がなされ(ステップS43)、ペアリング処理が終了する。
なお、上述の実施形態においては、提供用文字列の桁数をn桁とし、予め作成したストリームシードを構成する文字列の文字数をm(m>n)桁としたとき、ストリームシードを構成する文字列の先頭から連続するn桁の文字列を抽出して提供用文字列を構成するとともに、一定時間経過ごとに抽出する文字列を1桁下位にずらせることで、提供用文字列を一定時間ごとに変化するよう構成した場合の例について説明したが、この発明はこれに限定されるものではない。
たとえば、最初に任意のn桁の文字列のみを生成して提供用文字列とし、一定時間ごととにこれを繰り上げて最上位桁の文字を削除するとともに、任意の新たな文字をその都度生成して最下位桁に追加するよう構成することもできる。
また、上述の実施形態においては、受諾用文字列の桁上げを、提供用文字列の桁上げと同期して行うよう構成した場合の例について説明したが、受諾用文字列の桁上げタイミングを、提供用文字列の桁上げタイミングと無関係に行うよう構成することもできる。
たとえば、受諾用文字列の桁数をn桁したとき、既入力の受諾用文字列(n桁)が表示された状態において新たな文字が第2の機器の入力装置から入力されたタイミングで、受諾用文字列の桁上げを行うよう構成することもできる。
つぎに、図18〜図22は、本願のペアリング処理を利用したエンティティ認証処理(以下、単に「認証処理」ということがある。)の流れの一例を示すフローチャートである。認証処理におけるペアリング処理では、プロバイダ6の操作者とレジスタ7の操作者が同一である点で、上述のペアリング処理と異なる。
図23〜図24は、認証処理における、認証用機器30およびサービス用機器40の表示画面の推移の一例を示す図面である。図25、図26は、それぞれ認証側テーブル36およびサービス側テーブル46のデータ構成の一例を示す図面である。
図18〜図26を参照しつつ、認証処理について説明する。
認証処理のうち、最初に、認証登録処理について説明する。認証登録処理は、サービス用機器40によって提供される特定のサービス(以下、「サービスA」ということがある。)を利用する際の認証キーとして、認証用機器30を登録する処理である。
図18に示すように、認証登録処理においては、まず、認証用機器30とサービス用機器40との間でペアリング処理が実行される(ステップS49)。
認証登録処理におけるペアリング処理においては、とくに限定されるものではないが、たとえば、認証用機器30をプロバイダ6とし、サービス用機器40をレジスタ7として、上記ペアリング処理と同様の処理が実行される。ただし、ステップS49のペアリング処理においては、その性質上、原則として、マルチプルペアリングモード(図8、ステップS27参照)は想定されておらず待受け終了処理(図10参照)も想定されていない。また、認証用機器30、サービス用機器40における表示内容も、上記実施形態におけるプロバイダ6、レジスタ7の表示内容と一部異なる。
図23の(a)に示すように、認証登録処理においては、まず、サービス用機器40の表示画面210に新規サービス利用登録画面が表示される。この画面から、ユーザ名その他登録に必要な情報が入力される。ここで認証キー登録ボタン215が操作されるとともに、認証用機器30の表示画面110の認証キー追加ボタン(図示せず)が操作されると、ペアリング処理が開始される。
ペアリング処理が開始されると、図23の(b)に示すように、認証用機器30の表示画面110の提供用文字列表示部111に、提供用文字列が表示される。
操作者はこれを見て、図23の(c)に示すサービス用機器40の表示画面210に表示された入力用キーボタン213を操作して受諾用文字列を入力する。受諾用文字列表示部212に受諾用文字列が表示された状況で登録ボタン214(図12A等のペアリングボタン72に相当する。)が操作されると、ペアリング処理が実行される。
その結果、認証用機器30とサービス用機器40との間でペアリングが成立すると、図18に示すように、ペアリング成立による相互通信可能な状態を利用して、サービス用機器40と認証用機器30との間で公開鍵送信処理が自動的に実行される(ステップS50)。
図19は、公開鍵送信処理(ステップS50)の詳細な流れの一例を示すフローチャートである。公開鍵送信処理において、サービス用機器40は、サービス側鍵ペア、すなわち、サービスAに係る秘密鍵であるサービス側秘密鍵と当該サービス側秘密鍵に対応する公開鍵であるサービス側公開鍵、を生成して、サービス側テーブル46に記憶する(ステップS54)。
図26に示すサービス側テーブル46において、内部ユーザIDフィールドが「N/A(該当なし)」となっているレコードであって、鍵グループIDフィールドが同一値(たとえば「0」)となっている一対のレコードがサービス側鍵ペアに対応する。この一対のレコードのうち種別フィールドが「秘密鍵」となっているレコードの鍵フィールドがサービス側秘密鍵を表し、種別フィールドが「公開鍵」となっているレコードの鍵フィールドがサービス側公開鍵を表す。サービス側テーブル46には、2対のサービス側鍵ペアが記憶されている。
一方、認証用機器30は、認証側鍵ペア、すなわち、認証用機器30に係る秘密鍵である認証側秘密鍵と当該認証側秘密鍵に対応する公開鍵である認証側公開鍵、を生成して、認証側テーブル36に記憶するとともに(ステップS51)、生成した認証側公開鍵をサービス用機器40に送信する(ステップS52)。
図25に示す認証側テーブル36において、サービスIDフィールド、サービス名フィールドおよび内部ユーザIDフィールドがいずれも「N/A(該当なし)」となっているレコードであって、鍵グループIDフィールドが同一値(たとえば「0」)となっている一対のレコードが認証側鍵ペアに対応する。この一対のレコードのうち種別フィールドが「秘密鍵」となっているレコードの鍵フィールドが認証側秘密鍵を表し、種別フィールドが「公開鍵」となっているレコードの鍵フィールドが認証側公開鍵を表す。認証側テーブル36には、2対の認証側鍵ペアが記憶されている。
サービス用機器40は、認証側公開鍵を受信すると、サービスAに係る認証用機器30の識別標識である内部ユーザIDを生成し、受信した認証側公開鍵を当該内部ユーザIDに対応付けて、サービス側テーブル46に記憶する(ステップS55)。
図26に示すサービス側テーブル46において、内部ユーザIDフィールドが「N/A(該当なし)」以外の値(たとえば「BBB」)となっているレコードの鍵フィールドが、当該内部ユーザIDに対応する認証側公開鍵を表す。
サービス側テーブル46に3つの認証側公開鍵が記憶されている。これらの認証側公開鍵に対応するレコードのうち、鍵グループIDフィールドが同一値(たとえば「0」)となっているレコードは同一グループとして管理され、後述のように、認証実行処理において、当該内部ユーザIDに対応する認証側公開鍵とともに、同一の鍵グループIDフィールドを持つサービス側秘密鍵を用いて、正当性検証処理が行われる。
サービス用機器40は、さらに、ステップS54において生成したサービス側公開鍵を、サービスAの識別標識であるサービスID、当該サービスIDに対応するサービス名、および上記内部ユーザIDとともに、認証用機器40に送信する(ステップS56)。
認証用機器30は、サービス用機器40からサービス側公開鍵、サービスID、サービス名、内部ユーザIDを受信すると、これらを関連付けて認証側テーブル36に記憶する(ステップS53)。
図25に示す認証側テーブル36において、サービスIDフィールド、サービス名フィールドおよび内部ユーザIDフィールドがいずれも「N/A(該当なし)」以外の値(たとえば「AAA」、「サービスA」、「BBB」)となっているレコードの鍵フィールドが、当該サービスIDに対応するサービス側公開鍵を表す。
認証側テーブル36に3つのサービス側公開鍵が記憶されている。これらのサービス側公開鍵に対応するレコードのうち、鍵グループIDフィールドが同一値(たとえば「0」)となっているレコードは同一グループとして管理され、後述のように、認証実行処理において、当該サービスIDに対応するサービス側公開鍵とともに、同一の鍵グループIDフィールドを持つ認証側秘密鍵を用いて、正当性検証処理が行われる。
図18に示す処理が完了すると、図23の(d)および(e)に示すように、サービス用機器40の表示画面210および認証用機器30の表示画面110に、それぞれ、認証登録処理が完了した旨の表示がなされ、認証登録処理(図18参照)が終了する。
なお、図18に示す処理において、複数のサービス側鍵ペアを生成し、サービス側鍵ペアおよびこれに対応する1または2以上の認証側公開鍵を同一グループとして管理するよう構成したが、この発明はこれに限定されるものではない。たとえば、サービス側鍵ペアを、異なる認証用機器30に対し別個に生成・記憶するようにしてもよいし、異なる認証用機器30に対し全て共通のサービス側鍵ペアを用いることもできる。後者の場合、ステップS54の処理は、一度実行しておけば、認証登録処理ごとに実行する必要はない。
また、図18に示す処理において、複数の認証側鍵ペアを生成し、認証側鍵ペアおよびこれに対応する1または2以上のサービス側公開鍵を同一グループとして管理するよう構成したが、この発明はこれに限定されるものではない。たとえば、認証側鍵ペアを、異なるサービス用機器40に対し別個に生成・記憶するようにしてもよいし、異なるサービス用機器40に対し全て共通の認証側鍵ペアを用いることもできる。後者の場合、ステップS51の処理は、一度実行しておけば、認証登録処理ごとに実行する必要はない。
つぎに、認証実行処理について説明する。認証実行処理は、認証登録処理によって認証キーとして登録された認証用機器30を用いて、サービス用機器40によって提供されるサービスAを利用するための認証を行う処理である。
図20に示すように、認証実行処理においては、まず、認証用機器30とサービス用機器40との間でペアリング処理が実行される(ステップS49)。
認証実行処理におけるペアリング処理においては、とくに限定されるものではないが、たとえば、サービス用機器40をプロバイダ6とし、認証用機器30をレジスタ7として、認証登録処理におけるペアリング処理と同様の処理が実行される。
図24の(a)に示すように、認証実行処理においては、まず、サービス用機器40の表示画面210に認証開始画面が表示される。この画面からキー認証ボタン216が操作されると、ペアリング処理が開始される。
なお、この例では、上記認証開始画面から、ログインIDおよびパスワードを入力することによっても、認証用機器30を用いることなく、認証が可能となるよう構成されている。
さて、キー認証ボタン216の操作によりペアリング処理が開始されると、図24の(b)に示すように、サービス用機器40の表示画面210の提供用文字列表示部211に、提供用文字列が表示される。
操作者はこれを見て、図24の(c)に示す認証用機器30の表示画面110に表示された入力用キーボタン113を操作して受諾用文字列を入力する。受諾用文字列表示部112に受諾用文字列が表示された状況で認証ボタン114(図12A等のペアリングボタン72に相当する。)が操作されると、ペアリング処理が実行される。
その結果、認証用機器30とサービス用機器40との間でペアリングが成立すると、図20に示すように、ペアリング成立による相互通信可能な状態を利用して、サービス用機器40と認証用機器30との間で正当性検証処理が自動的に実行される(ステップS60)。
図21および図22は、正当性検証処理(ステップS60)の詳細な流れの一例を示すフローチャートである。正当性検証処理において、サービス用機器40は、サービスAに係るサービスIDの指定を含む認証を求める情報を認証用機器30に送信する(ステップS61)。
認証用機器30は、当該認証を求める情報を受信すると、認証側元データとして乱数を生成する(ステップS62)。この乱数を認証側乱数とよぶ。もちろん、認証側元データは乱数に限定されるものではなく、認証用機器30において用意した任意のデータであればよい。
認証用機器30は、受信したサービスIDに対応するサービス側公開鍵および内部ユーザIDを、認証用機器30の認証側テーブル36(以下、単に「認証用機器30」ということがある。)から読み出し、読み出したサービス側公開鍵を用いて、認証側乱数を暗号化する(ステップS63)。この暗号化された認証側乱数が、認証側暗号化データである。
認証用機器30は、上記認証側暗号化データと読み出した内部ユーザIDとを、サービス用機器40に送信する(ステップS64)。
サービス用機器40は、認証側暗号化データと内部ユーザIDとを受信すると、受信した認証側暗号化データを、サービス側テーブル46に記憶されているサービス側秘密鍵を用いて復号化する(ステップS65)。サービス側テーブル46に記憶されている複数のサービス側秘密鍵のうち、復号化に用いられるサービス側秘密鍵は、受信した内部ユーザIDに対応する認証側公開鍵と同一の鍵グループIDフィールドを持つサービス側秘密鍵である。この復号化された認証側暗号化データが、認証側復号化データである。
サービス用機器40は、認証側復号化データに所定の演算を施して認証側演算化データを得る(ステップS66)。この例では、所定の演算として、不可逆的な一方向性関数を含む関数、たとえば、特定のハッシュ関数を用いた演算を行うよう構成している。したがって、ステップS66において、認証側復号化データに特定のハッシュ関数を用いた演算を行い、認証側演算化データであるハッシュ値を算出する。
もちろん、所定の演算は、ハッシュ関数を用いた演算に限定されるものではない。たとえば、認証側演算化データを認証側復号化データと同一の値とすることもできる。この場合、所定の演算は「1」を乗ずる演算、とみることができる。
サービス用機器40は、算出されたハッシュ値を認証用機器30に送信する(ステップS67)。
認証用機器30は、ハッシュ値を受信する一方(ステップS69)、ステップS62において生成した認証側乱数に、ステップS66において用いられるハッシュ関数と同一のハッシュ関数を用いた演算を行って得られるハッシュ値を算出し(ステップS68)、この2つのハッシュ値が一致するか否かを判断する(ステップS70)。
2つのハッシュ値が一致しない場合は、サービスIDの認証は失敗した(サービスIDが真正でない)と判断し、認証実行処理を終了する(ステップS71)。
一方、ステップS70において、2つのハッシュ値が一致する場合は、サービスIDの認証は成功した(サービスIDが真正である)と判断され、つぎの認証を求める情報がサービス用機器40に送信され、制御は、図22に示すステップS72に移される。
ステップS72〜ステップS81の処理は、認証用機器30とサービス用機器40の役割が逆転しているが、上記ステップS62〜ステップS71の処理と略同様の処理である。
すなわち、ステップS72において、サービス用機器40は、サービス側元データとして乱数を生成する(ステップS72)。この乱数をサービス側乱数とよぶ。もちろん、サービス側元データは乱数に限定されるものではなく、サービス用機器40において用意した任意のデータであればよい。
サービス用機器40は、ステップS65において認証用機器30から受信した内部ユーザIDに対応する認証側公開鍵を、サービス用機器40のサービス側テーブル46(以下、単に「サービス用機器40」ということがある。)から読み出し、読み出した認証側公開鍵を用いて、サービス側乱数を暗号化する(ステップS73)。この暗号化されたサービス側乱数が、サービス側暗号化データである。
サービス用機器40は、上記サービス側暗号化データを、認証用機器30に送信する(ステップS74)。
認証用機器30は、受信したサービス側暗号化データを、認証側テーブル36に記憶されている認証側秘密鍵を用いて復号化する(ステップS75)。認証側テーブル36に記憶されている複数の認証側秘密鍵のうち、復号化に用いられる認証側秘密鍵は、ステップS62において受信したサービスIDに対応するサービス側公開鍵と同一の鍵グループIDフィールドを持つ認証側秘密鍵である。この復号化されたサービス側暗号化データが、サービス側復号化データである。
認証用機器30は、サービス側復号化データに所定の演算を施してサービス側演算化データを得る(ステップS76)。この例では、所定の演算として、不可逆的な一方向性関数を含む関数、たとえば、特定のハッシュ関数を用いた演算を行うよう構成している。したがって、ステップS76において、サービス側復号化データに特定のハッシュ関数を用いた演算を行い、サービス側演算化データであるハッシュ値を算出する。
もちろん、所定の演算は、ハッシュ関数を用いた演算に限定されるものではない。たとえば、サービス側演算化データをサービス側復号化データと同一の値とすることもできる。この場合、所定の演算は「1」を乗ずる演算、とみることができる。
認証用機器30は、算出されたハッシュ値をサービス用機器40に送信する(ステップS77)。
サービス用機器40は、ハッシュ値を受信する一方(ステップS79)、ステップS72において生成したサービス側乱数に、ステップS76において用いられるハッシュ関数と同一のハッシュ関数を用いた演算を行って得られるハッシュ値を算出し(ステップS78)、この2つのハッシュ値が一致するか否かを判断する(ステップS80)。
2つのハッシュ値が一致しない場合は、内部ユーザIDの認証は失敗した(内部ユーザIDが真正でない)と判断し、認証実行処理を終了する(ステップS81)。
一方、ステップS80において、2つのハッシュ値が一致する場合は、内部ユーザIDの認証は成功した(内部ユーザIDが真正である)と判断され、図20に示す認証実行処理が成功したと判断される(ステップS82)。
認証実行処理が成功すると、図24の(d)に示すように、サービス用機器40の表示画面210に、認証が成功した旨の表示がなされ、認証実行処理(図20参照)が終了する。
この後、利用者(操作者)は、サービス用機器40によって提供されるサービスAを利用することが可能となる。
なお、上述の実施形態においては、正当性検証処理(図20、ステップS60)として、サービスIDの正当性検証処理(図21、ステップS61〜ステップS71)および内部ユーザIDの正当性検証処理(図22、ステップS72〜ステップS82)の双方の正当性検証処理を行うよう構成したが、この発明はこれに限定されるものではない。
提供されるサービスの種類・性質・利用態様などに応じ、正当性検証処理(図20、ステップS60)として、サービスIDの正当性検証処理(図21、ステップS61〜ステップS71)および内部ユーザIDの正当性検証処理(図22、ステップS72〜ステップS82)のいずれか一方のみを実行するよう構成することもできる。
また、本発明による認証の態様はとくに限定されるものではない。たとえば、ソフトウェアの利用認証、ウェブサイトへのログイン認証、ウェブショッピング等における決済サービス認証(リダイレクトによる決済サービスへの移行を含む)など、あらゆる認証に本発明を適用することができる。
さらに、本発明による認証実行処理(図20参照)済みのサービスの利用中に、当該サービスの一部について、さらに認証実行処理を行うよう構成することもできる。
たとえば、ウェブサイトへの本発明によるログイン認証を済ませた上でサービス用機器40を用いて当該ウェブサイトを利用しているときに、利用者から当該ウェブサイトにおける特定の重要なサービス(たとえば、物品の売買)の提供が求められると、当該特定の重要なサービス提供の諾否の確認を認証用機器30に表示し、認証用機器30から承諾をする旨の入力があった場合に、重ねて本発明による認証実行処理を行うよう構成するのである。
この場合、先の認証実行処理(図20参照)によるペアリング処理(ステップS49参照)が完了し、サービス用機器40と認証用機器30との間の通信は確立していることから、後の認証実行処理においては、あらためてペアリング処理を行う必要はなく、正当性検証処理(ステップS60参照)と同様の処理のみを実行すれば足りる。
なお、上述の認証処理においては、認証用機器30を実機として実現した場合を例に説明したが、この発明はこれに限定されるものではない。認証用機器30を仮想マシンとして実現することもできる。この場合、サービス用機器40と認証用機器30とを同一の物理マシン上に並存させることもできる。
なお、上述の認証処理においては、本願の第1ないし第4のいずれかの発明による情報通信システムにおいて、第1および第2の機器の一方を、特定のサービスを提供する機器であるサービス用機器とし、他方を、当該特定のサービスを利用する際の認証を行う機器である認証用機器とし、サービス用機器と認証用機器とのペアリングが成立したことを前提に、当該特定のサービスを利用可能とするための認証を行う場合を例に説明したが、認証処理は、これに限定されるものではない。
何らかの手段を用いてサービス用機器と認証用機器との間で相手を特定して通信が確立されたこと(広義のペアリングの成立)を前提に、当該特定のサービスを利用可能とするための認証を行うよう構成することもできる。
この場合、サービス用機器と認証用機器との間のペアリングは、インターネット等の情報通信網を介して行うようにしてもよいが、より一般的に、情報通信手段を介して行うよう構成することができる。
ここで、情報通信手段とは、電気信号、光信号等に変換された情報を伝達するための通信手段であって、有線、無線の別を問わない。情報通信手段として、インターネットに代表されるWAN(Wide Area Network)、LAN(Local Area Network)等のコンピュータネットワーク、電話回線(携帯電話回線を含む。)、専用回線等の通信回線、Bluetoothその他の近距離無線通信、赤外線等による通信、通信ケーブルによる通信、機器相互の接触による通信、または、これらを組み合わせたものが例示される。
すなわち、何らかの手段を用いてペアリング処理(図18および図20、ステップS49)に相当する処理(サービス用機器と認証用機器との間で相手を特定して通信を確立する処理)を行い、続いて、公開鍵送信処理(図18、ステップS50)または正当性検証処理(図20、ステップS60)を実行することで、認証登録処理(図18)または認証実行処理(図20)と同等の処理を行うことができる。
この場合、この発明は、次のように把握することができる。
[発明A]
特定のサービスを提供する機器であるサービス用機器と、当該特定のサービスを利用する際の認証を行う機器であって情報通信手段を介して前記サービス用機器と通信可能な機器である認証用機器と、を備えた情報通信システムにおいて、
前記サービス用機器と前記認証用機器とのペアリングが成立したことを前提に、当該特定のサービスを利用可能とするための認証を行うシステムであって、
前記認証用機器は、当該認証用機器側の秘密鍵である認証側秘密鍵と当該認証側秘密鍵に対応する公開鍵である認証側公開鍵とを生成して、当該認証側秘密鍵を記憶するとともに、当該認証側公開鍵を前記サービス用機器に送信する認証側登録部、を備えた認証側制御部を備え、
前記サービス用機器は、前記認証用機器から前記認証側公開鍵を受信すると、前記特定のサービスに係る前記認証用機器の識別標識である内部ユーザIDを生成し、前記認証側公開鍵を当該内部ユーザIDに対応付けて記憶するとともに、当該内部ユーザIDを前記認証用機器に送信するサービス側登録部、を備えたサービス側制御部を備え、
前記サービス側制御部は、前記認証用機器から内部ユーザIDを指定した認証を求める情報を受信すると、当該サービス用機器において用意した任意のデータであるサービス側元データを前記サービス側登録部に記憶されている前記内部ユーザIDに対応する認証側公開鍵を用いて暗号化したデータであるサービス側暗号化データを前記認証用機器に送信するサービス側暗号部、を備え、
前記認証側制御部は、前記サービス用機器から受信したサービス側暗号化データを当該認証側登録部に記憶されている前記認証側秘密鍵を用いて復号化したデータであるサービス側復号化データに所定の演算を施して得られるサービス側演算化データを前記サービス用機器に送信する認証側復号部、を備え、
前記サービス側制御部は、前記認証用機器から受信したサービス側演算化データが、前記サービス側元データに当該所定の演算を施して得られるデータと一致する場合は、前記内部ユーザIDが真正であると判定する内部ユーザID真正判定部、を備えたこと、
を特徴とする、情報通信システム。
[発明B]
発明Aの情報通信システムにおいて、
前記サービス側登録部は、さらに、当該サービス用機器側の秘密鍵であるサービス側秘密鍵と当該サービス側秘密鍵に対応する公開鍵であるサービス側公開鍵とを生成して、当該サービス側秘密鍵を記憶するとともに、当該サービス側公開鍵を、当該サービス用機器に係る特定のサービスの識別標識であるサービスIDとともに、前記認証用機器に送信し、
前記認証側登録部は、さらに、前記サービス用機器から前記サービス側公開鍵を受信すると、当該サービス側公開鍵を当該サービスIDと関連付けて記憶し、
前記認証側制御部は、前記サービス用機器からサービスIDを指定した認証を求める情報を受信すると、当該認証用機器において用意した任意のデータである認証側元データを前記認証側登録部に記憶されている前記サービスIDに対応する前記サービス側公開鍵を用いて暗号化したデータである認証側暗号化データを前記サービス用機器に送信する認証側暗号部、を備え、
前記サービス側制御部は、前記認証用機器から受信した認証側暗号化データを当該サービス側登録部に記憶されているサービス側秘密鍵を用いて復号化したデータである認証側復号化データに所定の演算を施して得られる認証側演算化データを前記認証用機器に送信するサービス側復号部、を備え、
前記認証側制御部は、前記サービス用機器から受信した認証側演算化データが、前記認証側元データに当該所定の演算を施して得られるデータと一致する場合は、前記サービスIDが真正であると判定するサービスID真正判定部、を備えたこと、
を特徴とする、情報通信システム。
[発明C]
特定のサービスを提供する機器であるサービス用機器と、当該特定のサービスを利用する際の認証を行う機器であって情報通信手段を介して前記サービス用機器と通信可能な機器である認証用機器と、を備えた情報通信システムにおいて、
前記サービス用機器と前記認証用機器とのペアリングが成立したことを前提に、当該特定のサービスを利用可能とするための認証を行うシステムであって、
前記サービス用機器は、当該サービス用機器側の秘密鍵であるサービス側秘密鍵と当該サービス側秘密鍵に対応する公開鍵であるサービス側公開鍵とを生成して、当該サービス側秘密鍵を記憶するとともに、当該サービス側公開鍵を、当該サービス用機器に係る特定のサービスの識別標識であるサービスIDとともに、前記認証用機器に送信するサービス側登録部、を備えたサービス側制御部を備え、
前記認証用機器は、前記サービス用機器から前記サービス側公開鍵を受信すると、当該サービス側公開鍵を当該サービスIDと関連付けて記憶する認証側登録部、を備えた認証側制御部を備え、
前記認証側制御部は、前記サービス用機器からサービスIDを指定した認証を求める情報を受信すると、当該認証用機器において用意した任意のデータである認証側元データを前記認証側登録部に記憶されている前記サービスIDに対応する前記サービス側公開鍵を用いて暗号化したデータである認証側暗号化データを前記サービス用機器に送信する認証側暗号部、を備え、
前記サービス側制御部は、前記認証用機器から受信した認証側暗号化データを当該サービス側登録部に記憶されているサービス側秘密鍵を用いて復号化したデータである認証側復号化データに所定の演算を施して得られる認証側演算化データを前記認証用機器に送信するサービス側復号部、を備え、
前記認証側制御部は、前記サービス用機器から受信した認証側演算化データが、前記認証側元データに当該所定の演算を施して得られるデータと一致する場合は、前記サービスIDが真正であると判定するサービスID真正判定部、を備えたこと、
を特徴とする、情報通信システム。
[発明D]
発明AないしCのいずれかの情報通信システムに用いられる前記サービス用機器。
[発明E]
発明AないしCのいずれかの情報通信システムに用いられる前記認証用機器。
[発明F]
コンピュータを、発明Dのサービス用機器のサービス側制御部、または、発明Eの認証用機器の認証側制御部として機能させるためのプログラム。
[発明G]
発明Fのプログラムを記憶した記録媒体。
[発明H]
特定のサービスを提供する機器であるサービス用機器と、当該特定のサービスを利用する際の認証を行う機器であって情報通信手段を介して前記サービス用機器と通信可能な機器である認証用機器と、を備えた情報通信システムであって、前記サービス用機器と前記認証用機器とのペアリングが成立したことを前提に、当該特定のサービスを利用可能とするための認証を行う情報通信システム、を用いて行う情報通信方法であって、
前記認証用機器が、当該認証用機器側の秘密鍵である認証側秘密鍵と当該認証側秘密鍵に対応する公開鍵である認証側公開鍵とを生成して、当該認証側秘密鍵を記憶するとともに、当該認証側公開鍵を前記サービス用機器に送信する認証側登録ステップと、
前記サービス用機器が、前記認証用機器から前記認証側公開鍵を受信すると、前記特定のサービスに係る前記認証用機器の識別標識である内部ユーザIDを生成し、前記認証側公開鍵を当該内部ユーザIDに対応付けて記憶するとともに、当該内部ユーザIDを前記認証用機器に送信するサービス側登録ステップと、
前記サービス用機器が、前記認証用機器から内部ユーザIDを指定した認証を求める情報を受信すると、当該サービス用機器において用意した任意のデータであるサービス側元データを前記サービス側登録部に記憶されている前記内部ユーザIDに対応する認証側公開鍵を用いて暗号化したデータであるサービス側暗号化データを前記認証用機器に送信するサービス側暗号ステップと、
前記認証用機器が、前記サービス用機器から受信したサービス側暗号化データを当該認証側登録部に記憶されている前記認証側秘密鍵を用いて復号化したデータであるサービス側復号化データに所定の演算を施して得られるサービス側演算化データを前記サービス用機器に送信する認証側復号ステップと、
前記サービス用機器が、前記認証用機器から受信したサービス側演算化データが、前記サービス側元データに当該所定の演算を施して得られるデータと一致する場合は、前記内部ユーザIDが真正であると判定する内部ユーザID真正判定ステップと、
を備えたこと、
を特徴とする、情報通信方法。
[発明I]
特定のサービスを提供する機器であるサービス用機器と、当該特定のサービスを利用する際の認証を行う機器であって情報通信手段を介して前記サービス用機器と通信可能な機器である認証用機器と、を備えた情報通信システムであって、前記サービス用機器と前記認証用機器とのペアリングが成立したことを前提に、当該特定のサービスを利用可能とするための認証を行う情報通信システム、を用いて行う情報通信方法であって、
前記サービス用機器が、当該サービス用機器側の秘密鍵であるサービス側秘密鍵と当該サービス側秘密鍵に対応する公開鍵であるサービス側公開鍵とを生成して、当該サービス側秘密鍵を記憶するとともに、当該サービス側公開鍵を、当該サービス用機器に係る特定のサービスの識別標識であるサービスIDとともに、前記認証用機器に送信するサービス側登録ステップと、
前記認証用機器が、前記サービス用機器から前記サービス側公開鍵を受信すると、当該サービス側公開鍵を当該サービスIDと関連付けて記憶する認証側登録ステップと、
前記認証用機器が、前記サービス用機器からサービスIDを指定した認証を求める情報を受信すると、当該認証用機器において用意した任意のデータである認証側元データを前記認証側登録部に記憶されている前記サービスIDに対応する前記サービス側公開鍵を用いて暗号化したデータである認証側暗号化データを前記サービス用機器に送信する認証側暗号ステップと、
前記サービス用機器が、前記認証用機器から受信した認証側暗号化データを当該サービス側登録部に記憶されているサービス側秘密鍵を用いて復号化したデータである認証側復号化データに所定の演算を施して得られる認証側演算化データを前記認証用機器に送信するサービス側復号ステップと、
前記認証用機器が、前記サービス用機器から受信した認証側演算化データが、前記認証側元データに当該所定の演算を施して得られるデータと一致する場合は、前記サービスIDが真正であると判定するサービスID真正判定ステップと、
を備えたこと、
を特徴とする、情報通信方法。
なお、図5に示すステップS1〜ステップS2、ステップS8〜ステップS11、図8に示すステップS27〜ステップS30、図9に示すステップS33、ステップS36〜ステップS37および図10に示すステップS41〜ステップS43が、図2の第1の機器6の第1制御部10に対応する。
このうち、ステップS2、ステップS9〜ステップS11およびステップS36が、ペアリング提供処理部11に対応する。
このうち、ステップS36が応答用文字列取得処理部12に対応する。
図6に示すステップS12〜ステップS19、図7に示すステップS22、ステップS25〜ステップS26、図8に示すステップS32、図9に示すステップS34〜ステップS35およびステップS38〜ステップS40が、図2の第2の機器7の第2制御部15に対応する。
このうち、ステップS15〜ステップS19およびステップS35が、ペアリング受諾処理部16に対応する。
このうち、ステップS15およびステップS17〜ステップS18が桁上げ処理部17に対応し、ステップS35が確認用文字列表示処理部18に対応する。
図5に示すステップS3〜ステップS7、図7に示すステップS20〜ステップS24および図8に示すステップS31が、図2のサーバ装置4のサーバ側制御部20に対応する。
このうち、ステップS20〜ステップS21、ステップS23〜ステップS24およびステップS31が、ペアリング判定処理部21に対応する。
このうち、ステップS23〜ステップS24が再ペアリング実行指示処理部22に対応する。
なお、この実施形態においては、情報通信システム2のサーバ装置4側のプログラムを記憶した記録媒体として、HDDに装着されたハードディスクを例示し、第1の機器6および第2の機器7側のプログラムを記憶した記録媒体として、SSDに装着されたフラッシュメモリを例示しているが、プログラムを記憶した記録媒体はこれらに限定されるものではなく、プログラムを記憶した記録媒体として、たとえば、外部メモリカード、CD−ROM、DVD−ROM、フレキシブルディスク、磁気テープを用いることもできる。さらに、主記憶装置もプログラムを記憶した記録媒体として用いることができる。
また、プログラムの配布態様は特に限定されるものではなく、記録媒体にプログラムを記憶した状態で配布するほか、有線や無線の情報通信手段を介して当該プログラムを配布するようにしてもよい。
また、プログラムの記録態様は特に限定されるものではない。直接実行できる形で記録媒体に記憶したり配布したりする他、たとえば、解凍して使用するように圧縮された形で記録媒体に記憶したり配布したりすることもできる。
なお、上述の各実施形態においては、コンピュータを用いて図2および図3の各機能を実現する場合を例に説明したが、これらの機能の一部または全部を、ハードウェアロジックを用いて構成するようにしてもよい。
また、上述のブロック図、ハードウェア構成、フローチャート、データベース(テーブル)の構成、表示画面の構成等は、例として挙げたものであり、本願発明は、これらに限定されるものではない。
上記においては、本発明を好ましい実施形態として説明したが、各用語は、限定のために用いたのではなく、説明のために用いたものであって、本発明の範囲および精神を逸脱することなく、添付のクレームの範囲において、変更することができるものである。また、上記においては、本発明のいくつかの典型的な実施形態についてのみ詳細に記述したが、当業者であれば、本発明の新規な教示および利点を逸脱することなしに上記典型的な実施形態において多くの変更が可能であることを、容易に認識するであろう。したがって、そのような変更はすべて、本発明の範囲に含まれるものである。