図1は、この発明の一実施形態による認証鍵複製システム2の構成を示すブロック図である。認証鍵複製システム2は、それぞれ情報通信手段8に接続される、1または2以上のサービス用機器3、1または2以上のバックアップ用サーバ4、管理用サーバ5、1または2以上の第1の認証用機器6および1または2以上の第2の認証用機器7を備えている。
つぎに、図2は、サービス用機器3、バックアップ用サーバ4、管理用サーバ5、第1の認証用機器6および第2の認証用機器7の構成を例示するブロック図である。
図2に示すように、第1の認証用機器6は第1の認証側制御部60を備えている。第1の認証側制御部60は、第1の認証側秘密鍵を記憶する第1の認証側記憶部68を備えている。
サービス用機器3はサービス側制御部30を備えている。サービス側制御部30は、第1の認証側秘密鍵に対応する第1の認証側公開鍵を記憶するサービス側記憶部31を備えている。
サービス側制御部30は、第1の認証用機器6から送信された認証鍵バックアップ要求信号に基づいてマスタ側鍵ペアを用いた第1の認証用機器6の公開鍵認証を実行する第1の認証用機器認証部32を備えている。
サービス側記憶部31は、第1の認証用機器認証部32による認証が成功したことを条件に、第1の認証用機器6から受信した、第2の認証側公開鍵の受取権限を証明する受取権限データであって、引渡権限データに対して非対称暗号鍵の関係を有する受取権限データを記憶するよう構成されている。
サービス側制御部30は、バックアップ用サーバ4から送信された認証鍵復元要求信号に基づいてバックアップ側鍵ペアを用いたバックアップ用サーバ4の認証を実行するバックアップ用サーバ認証部33を備えている。
サービス側記憶部31は、バックアップ用サーバ認証部33による認証が成功したことを条件に、バックアップ用サーバ4から受信した第2の認証側公開鍵を記憶するよう構成されている。
バックアップ用サーバ4はバックアップ側制御部40を備えている。バックアップ側制御部40は、第2の認証側公開鍵の引渡権限を証明する引渡権限データを記憶するバックアップ側記憶部41を備えている。
第2の認証用機器7は第2の認証側制御部70を備えている。第2の認証側制御部70は、第2の認証側公開鍵に対応する第2の認証側秘密鍵を記憶する第2の認証側記憶部71を備えている。
管理用サーバ5は管理側制御部50を備えている。管理側制御部50は、サービス用機器3の提供するサービスと第1の認証用機器6のユーザとを関連付けて記憶する管理側記憶部58を備えている。
管理側制御部50は、第1の認証用機器6から受信した認証鍵バックアップ要求信号に基づいて、当該信号をサービス用機器3に転送する。管理側制御部50は、また、バックアップ用サーバ4から受信した認証鍵復元要求信号にもとづいて、当該信号をサービス用機器3に転送する。
この実施形態においては、上記引渡権限データは、バックアップ側秘密鍵であり、受取権限データは、バックアップ側秘密鍵に対応するバックアップ側公開鍵である。また、サービス側制御部30のバックアップ用サーバ認証部33は、バックアップ用サーバ4から送信された認証鍵復元要求信号に基づいてバックアップ側鍵ペアを用いたバックアップ用サーバの公開鍵認証を実行するよう構成されている。また、上記バックアップ側公開鍵は、認証局署名済みのサーバ証明書付き公開鍵である。
サービス用機器3のサービス側記憶部31は、さらにサービス側秘密鍵を記憶している。また、第1の認証用機器6の第1の認証側記憶部68およびバックアップ用サーバ4のバックアップ側記憶部41は、さらにサービス側秘密鍵に対応するサービス側公開鍵を記憶している。
そして、第1の認証用機器6の第1の認証側制御部60は、サービス用機器3に受取権限データを送信する際に、サービス側公開鍵により暗号化した受取権限データを送信するよう構成され、サービス用機器3のサービス側記憶部31は、第1の認証用機器6から受信した暗号化された受取権限データをサービス側秘密鍵により復号化して記憶するよう構成されている。
また、バックアップ用サーバ4のバックアップ側制御部40は、サービス用機器3に第2の認証側公開鍵を送信する際に、サービス側公開鍵により暗号化した第2の認証側公開鍵を送信するよう構成され、サービス用機器3のサービス側記憶部31は、バックアップ用サーバ4から受信した暗号化された第2の認証側公開鍵をサービス側秘密鍵により復号化して記憶するよう構成されている。
サービス用機器3のサービス側制御部30は、さらに、復元許可証明データ生成部35を備えている。復元許可証明データ生成部35は、第1の認証用機器認証部32による認証が成功したことを条件に、復元許可証明データを生成してサービス側記憶部31に記憶させるとともに、当該復元許可証明データを第1の認証用機器6に送信する。そして、復元許可証明データ生成部35は、生成された復元許可証明データを第1の認証用機器6に送信する際に、受取権限データおよび第1の認証側公開鍵を用いて暗号化するよう構成されている。
第1の認証用機器6の第1の認証側制御部60は、受信した復元許可証明データをバックアップ用サーバ4に転送する復元許可証明データ転送部69を備えている。復元許可証明データ転送部69は、暗号化された復元許可証明データをバックアップ用サーバ4に転送する際に、第1の認証側秘密鍵を用いて復号化するよう構成されている。
バックアップ用サーバ4のバックアップ側制御部40は、復元許可証明データ受信部45と、復元許可証明データ送信部46とを備えている。復元許可証明データ受信部45は、復元許可証明データを受信してバックアップ側記憶部41に記憶させる。復元許可証明データ受信部45は、復元許可証明データをバックアップ側記憶部41に記憶させる際に、第1の認証側秘密鍵を用いて復号化された復元許可証明データをさらに引渡権限データを用いて復号化するよう構成されている。
復元許可証明データ送信部46は、サービス用機器3のサービス側制御部30のバックアップ用サーバ認証部33による認証に際し、第2の認証側公開鍵とともに復元許可証明データをサービス用機器3に送信する。復元許可証明データ送信部46は、復元許可証明データをサービス用機器3に送信する際に、サービス側公開鍵を用いて暗号化するよう構成されている。
サービス用機器3のサービス側制御部30は、バックアップ用サーバ4から送信された復元許可証明データの真偽を判定する復元許可証明データ真偽判定部36を備えている。復元許可証明データ真偽判定部36は、暗号化された復元許可証明データの真偽を判定する際に、サービス側秘密鍵を用いて復号化するよう構成されている。
サービス側記憶部31は、バックアップ用サーバ認証部33による認証が成功し、かつ、復元許可証明データ真偽判定部36により復元許可証明データが真正であると判定されたことを条件に、バックアップ用サーバ4から受信した第2の認証側公開鍵を記憶するよう構成されている。
つぎに、図3は、図2に示すサービス用機器3、バックアップ用サーバ4、管理用サーバ5、第1の認証用機器6および第2の認証用機器7のハードウェア構成の一例を示すブロック図である。
サービス用機器3は、とくに限定されるものではなく、たとえばパーソナルコンピュータであってもよいし、タブレット型コンピュータであってもよいし、携帯情報端末装置であってもよいし、いわゆるスマートフォンに代表される携帯電話機であってもよい。さらに、家庭用電気機器、生産用機器、自動車などの運輸用機器であってもよい。
バックアップ用サーバ4、管理用サーバ5、第1の認証用機器6および第2の認証用機器7についても同様である。要は、情報通信手段8に接続される機器であれば、サービス用機器3、バックアップ用サーバ4、管理用サーバ5、第1の認証用機器6または第2の認証用機器7として、本願発明を適用することができる。
図3は、サービス用機器3、バックアップ用サーバ4および管理用サーバ5が、いずれも、一般的なサーバコンピュータと同様の構成であり、第1の認証用機器6および第2の認証用機器7が、いずれもスマートフォンである場合のハードウェア構成を例示したものである。
サービス用機器3は、認証鍵複製システム2のサービス用機器3側のプログラムを記憶した記録媒体であり、サービス側テーブル310(後述)の記憶媒体でもあるハードディスクを備えたHDD(ハードディスクドライブ)等の補助記憶装置55、補助記憶装置55に記憶されたプログラムがロードされる主記憶装置54、主記憶装置54にロードされたプログラムを実行するサービス側制御部30に対応するCPU51,LCD(液晶表示装置)等の表示装置52,キーボード、マウス、トラックパッド等の入力装置53、および、情報通信手段8を介してバックアップ用サーバ4、管理用サーバ5、第1の認証用機器6および第2の認証用機器7と通信するための通信インタフェース56を備えている。
バックアップ用サーバ4および管理用サーバ5も、サービス用機器3と同様のハードウェア構成である。
第1の認証用機器6は、認証鍵複製システム2の第1の認証用機器6側のプログラムを記憶した記録媒体であり、第1の認証側テーブル680(後述)の記憶媒体でもあるフラッシュメモリを搭載したSSD(ソリッドステートドライブ)等の補助記憶装置65、補助記憶装置65に記憶されたプログラムがロードされる主記憶装置64、主記憶装置64にロードされたプログラムを実行する第1の認証側制御部60に対応するCPU61、LCD(液晶表示装置)等の表示装置62,入力キー、タッチパネル等の入力装置63、および、情報通信手段8を介してサービス用機器3、バックアップ用サーバ4、管理用サーバ5および第2の認証用機器7と通信するための通信インタフェース66、を備えている。
第2の認証用機器7も、第1の認証用機器6と同様のハードウェア構成である。
図10は、第1の認証側記憶部68を構成する第1の認証側テーブル680のデータ構成の一例を示す図面である。図11は、サービス側記憶部31を構成するサービス側テーブル310のデータ構成の一例を示す図面である。図12は、バックアップ側記憶部41を構成するバックアップ側テーブル410のデータ構成の一例を示す図面である。図13は、管理側記憶部58を構成する管理側テーブル580のデータ構成の一例を示す図面である。
図4〜図9は、認証鍵複製システム2における各種処理の流れの一例を示すフローチャートである。
図4〜図13を参照しつつ、認証鍵複製システム2における各種処理について説明する。
まず、認証鍵登録処理について説明する。図4は、公開鍵認証のための認証鍵としてマスタ側鍵ペアおよびサービス側鍵ペアを用いた場合における認証鍵登録処理の一例を示すフローチャートである。サービス側鍵ペアは、サービス側秘密鍵とサービス側公開鍵とにより構成される鍵ペアである。
図4に示すように、まず、サービス用機器3は、第1の認証用機器6のユーザからの認証鍵登録要求を受取る(ステップS91)。これは、たとえば、サービス用機器3の表示装置52に表示されたログイン画面(図示せず)において、ユーザが認証鍵登録ボタン(図示せず)を操作することにより実行される。
続いて、サービス用機器3と第1の認証用機器6との間でペアリング処理が実行され、両機器間の通信が確立される(ステップS92)。ペアリング処理の方法はとくに限定されるものではなく、たとえば、サービス用機器および第1の認証用機器6の通信機能を用いて、両機器間で直接行うようにしてもよいし、インターネットなどの情報通信網を介して行うようにしてもよい。さらに、管理用サーバ5を介して行うようにすることもできる。
つぎに、サービス用機器3は、サービス側鍵ペア、すなわち、当該サービス用機器3の提供するサービスであるサービスSに係る秘密鍵であるサービス側秘密鍵と当該サービス側秘密鍵に対応する公開鍵であるサービス側公開鍵、を生成して、サービス側テーブル310に記憶する(ステップS93)。
図11に示すサービス側テーブル310において、内部ユーザIDフィールドが「N/A(該当なし)」となっているレコードであって、鍵グループIDフィールドが同一値(たとえば「0」)となっている一対のレコードがサービス側鍵ペアに対応する。この一対のレコードのうち鍵種別フィールドが「秘密鍵」となっているレコードの鍵データフィールドがサービス側秘密鍵を表し、鍵種別フィールドが「公開鍵」となっているレコードの鍵データフィールドがサービス側公開鍵を表す。サービス側テーブル310には、2組のサービス側鍵ペアが記憶されている。
サービス側公開鍵に認証済みサーバ証明書を付加するか否かは任意(オプション)であるが、認証済みサーバ証明書付のサービス側公開鍵については、サービス側テーブル310において、当該レコードのサーバ証明書データフィールドにサーバ証明書データが記憶される。
一方、第1の認証用機器6は、マスタ側鍵ペア、すなわち、第1の認証用機器6に係る秘密鍵である第1の認証側秘密鍵と当該第1の認証側秘密鍵に対応する公開鍵である第1の認証側公開鍵、を生成して、第1の認証側テーブル680に記憶するとともに(ステップS94)、生成した第1の認証側公開鍵をサービス用機器3に送信する(ステップS95)。
図10に示す第1の認証側テーブル680において、サービスIDフィールド、サービス名フィールドおよび内部ユーザIDフィールドがいずれも「N/A(該当なし)」となっているレコードであって、鍵グループIDフィールドが同一値(たとえば「0」)となっている一対のレコードがマスタ側鍵ペアに対応する。この一対のレコードのうち鍵種別フィールドが「秘密鍵」となっているレコードの鍵データフィールドが第1の認証側秘密鍵を表し、鍵種別フィールドが「公開鍵」となっているレコードの鍵データフィールドが第1の認証側公開鍵を表す。第1の認証側テーブル680には、2組のマスタ側鍵ペアが記憶されている。
サービス用機器3は、第1の認証側公開鍵を受信すると、サービスSに係る第1の認証用機器6のユーザの識別標識である内部ユーザIDを生成し、受信した第1の認証側公開鍵を当該内部ユーザIDに対応付けて、サービス側テーブル310に記憶する(ステップS96)。
図11に示すサービス側テーブル310において、内部ユーザIDフィールドが「N/A(該当なし)」以外の値(たとえば「AAA」)となっており、かつ、復元限定フラグフィールドが「0」となっているレコードの鍵データフィールドが、当該内部ユーザIDに対応する第1の認証側公開鍵を表す。なお、復元限定フラグフィールドが「1」となっているレコードの鍵データフィールドは、当該内部ユーザIDに対応するバックアップ側公開鍵を表す。
サービス側テーブル310に2つの第1の認証側公開鍵が記憶されている。これらの第1の認証側公開鍵に対応するレコードのうち、鍵グループIDフィールドが同一値(たとえば「0」)となっているレコードは同一グループとして管理され、たとえば、後述のログイン処理において、当該内部ユーザIDに対応する第1の認証側公開鍵とともに、同一の鍵グループIDフィールドを持つサービス側秘密鍵を用いて、エンティティ認証が行われる。
サービス用機器3は、さらに、ステップS93において生成したサービス側公開鍵を、サービスSの識別標識であるサービスID、当該サービスIDに対応するサービス名、および上記内部ユーザIDとともに、第1の認証用機器6に送信する(ステップS97)。当該サービス側公開鍵が認証済みサーバ証明書付きのものである場合には、当該認証済みサーバ証明書を添付して送信する。
第1の認証用機器6は、サービス用機器3からサービス側公開鍵、サービスID、サービス名、内部ユーザIDを受信すると、これらを関連付けて第1の認証側テーブル680に記憶する(ステップS98)。受信したサービス側公開鍵に認証済みサーバ証明書が添付されている場合には、当該認証済みサーバ証明書に記載されたサービス用機器からの受信でないときは、認証鍵登録処理をエラー終了させる。
図10に示す第1の認証側テーブル680において、サービスIDフィールド、サービス名フィールドおよび内部ユーザIDフィールドがいずれも「N/A(該当なし)」以外の値(たとえば「SSS」、「サービスS」、「AAA」)となっているレコードの鍵データフィールドが、当該サービスIDに対応するサービス側公開鍵を表す。
第1の認証側テーブル680に3つのサービス側公開鍵が記憶されている。これらのサービス側公開鍵に対応するレコードのうち、鍵グループIDフィールドが同一値(たとえば「0」)となっているレコードは同一グループとして管理され、たとえば、後述のログイン処理において、当該サービスIDに対応するサービス側公開鍵とともに、同一の鍵グループIDフィールドを持つ第1の認証側秘密鍵を用いて、エンティティ認証が行われる。
図4に示す処理が完了すると、サービス用機器3の表示装置52の表示画面(図示せず)および第1の認証用機器6の表示装置62の表示画面(図示せず)に、それぞれ、認証鍵登録処理が完了した旨の表示がなされ、認証鍵登録処理が終了する。
なお、図4に示す処理において、複数のサービス側鍵ペアを生成し、サービス側鍵ペアおよびこれに対応する1または2以上の第1の認証側公開鍵を同一グループとして管理するよう構成したが、この発明はこれに限定されるものではない。たとえば、サービス側鍵ペアを、異なる第1の認証用機器6に対し別個に生成・記憶するようにしてもよいし、異なる第1の認証用機器6に対し全て共通のサービス側鍵ペアを用いることもできる。後者の場合、ステップS93の処理は、一度実行しておけば、認証鍵登録処理ごとに実行する必要はない。
また、図4に示す処理において、複数のマスタ側鍵ペアを生成し、マスタ側鍵ペアおよびこれに対応する1または2以上のサービス側公開鍵を同一グループとして管理するよう構成したが、この発明はこれに限定されるものではない。たとえば、マスタ側鍵ペアを、異なるサービス用機器3に対し別個に生成・記憶するようにしてもよいし、異なるサービス用機器3に対し全て共通のマスタ側鍵ペアを用いることもできる。後者の場合、ステップS94の処理は、一度実行しておけば、認証鍵登録処理ごとに実行する必要はない。
つぎに、公開鍵認証によるエンティティ認証の一例について説明する。図5は、認証鍵複製システム2におけるマスタ側鍵ペアおよびサービス側鍵ペアを用いたログイン処理の一例を示すフローチャートである。
図5に示すように、まず、サービス用機器3は、第1の認証用機器6のユーザからのログイン要求を受取る(ステップS51)。これは、たとえば、サービス用機器3の表示装置52に表示されたログイン画面(図示せず)において、ユーザが認証ボタン(図示せず)を操作することにより実行される。
続いて、サービス用機器3と第1の認証用機器6との間でペアリング処理が実行され、両機器間の通信が確立される(ステップS52)。ペアリング処理の方法は認証鍵登録処理における場合と同様である(図4、ステップS92参照)。
つぎに、サービス用機器3は、自己の提供するサービスのサービスID(たとえば「SSS」)を含むサービスIDの認証(すなわち、当該サービスIDに係るサービスを提供するサービス用機器3の認証。以下同様)を求める情報を、第1の認証用機器6に通知する(ステップS53)。当該サービスIDに係るサービス側公開鍵が認証済みサーバ証明書付きのものである場合には、当該サービスIDに当該認証済みサーバ証明書を添付して通知する。
第1の認証用機器6は、通知されたサービスIDに対応する内部ユーザIDおよび鍵データを、第1の認証側テーブル680から抽出し、抽出した鍵データ(すなわち、サービス側公開鍵)に基づいてチャレンジを生成し、生成したチャレンジを内部ユーザIDとともに、サービス用機器3に送信する(ステップS54)。通知されたサービスIDに認証済みサーバ証明書が添付されている場合には、当該認証済みサーバ証明書に記載されたサービス用機器からの通知でないときは、ログイン処理をエラー終了させる。
チャレンジの生成方法はとくに限定されるものではないが、たとえば、乱数を生成し、抽出した上記サービス側公開鍵を用いて、この乱数を暗号化することで、チャレンジを生成することができる。
サービス用機器3は、チャレンジと内部ユーザIDとを受信すると、受信したチャレンジを、サービス側テーブル310に記憶されているサービス側秘密鍵を用いて復号化して乱数を得、得られた乱数に基づいてレスポンスを生成して第1の認証用機器6に送信する(ステップS55)。
サービス側テーブル310に記憶されている複数のサービス側秘密鍵のうち、チャレンジの復号化に用いられるサービス側秘密鍵は、受信した内部ユーザIDに対応する認証側公開鍵と同一の鍵グループIDフィールドを持つサービス側秘密鍵である。
レスポンスの生成方法はとくに限定されるものではないが、たとえば、得られた乱数に特定のハッシュ関数を用いて算出されたハッシュ値をレスポンスとすることができる。
第1の認証用機器6は、レスポンスを受信する一方、ステップS54において生成した乱数に、ステップS55において用いられるハッシュ関数と同一のハッシュ関数を用いた演算を行って得られるハッシュ値を算出し、この2つのハッシュ値が一致するか否かを判断する(ステップS56)。
2つのハッシュ値が一致しない場合は、サービスIDの認証は失敗した(サービスIDが真正でない)と判断し、ログイン処理を終了する(ステップS61)。
一方、ステップS56において、2つのハッシュ値が一致する場合は、サービスIDの認証は成功した(サービスIDが真正である)と判断され、内部ユーザIDの認証(すなわち、当該内部ユーザIDに係るユーザの使用する第1の認証用機器6の認証。以下同様)を求める情報がサービス用機器3に送信され、制御は、ステップS57に移される。
ステップS57〜ステップS59の処理は、第1の認証用機器6とサービス用機器3の役割が逆転しているが、上記ステップS54〜ステップS56の処理と略同様の処理である。
すなわち、ステップS57において、サービス用機器3は、ステップS55において第1の認証用機器6から受信した内部ユーザIDに対応する第1の認証側公開鍵を、サービス側テーブル310から抽出し、抽出した第1の認証側公開鍵に基づいてチャレンジを生成し、生成したチャレンジを第1の認証用機器6に送信する(ステップS57)。
チャレンジの生成方法はとくに限定されるものではないが、たとえば、乱数を生成し、抽出した上記第1の認証側公開鍵を用いて、この乱数を暗号化することで、チャレンジを生成することができる。
第1の認証用機器6は、チャレンジを受信すると、受信したチャレンジを、第1の認証側テーブル680に記憶されている第1の認証側秘密鍵を用いて復号化して乱数を得、得られた乱数に基づいてレスポンスを生成してサービス用機器3に送信する(ステップS58)。
第1の認証側テーブル680に記憶されている複数の第1の認証側秘密鍵のうち、復号化に用いられる第1の認証側秘密鍵は、ステップS54において受信したサービスIDに対応するサービス側公開鍵と同一の鍵グループIDフィールドを持つ第1の認証側秘密鍵である。
レスポンスの生成方法はとくに限定されるものではないが、たとえば、得られた乱数に特定のハッシュ関数を用いて算出されたハッシュ値をレスポンスとすることができる。
サービス用機器3は、レスポンスを受信する一方、ステップS57において生成した乱数に、ステップS58において用いられるハッシュ関数と同一のハッシュ関数を用いた演算を行って得られるハッシュ値を算出し、この2つのハッシュ値が一致するか否かを判断する(ステップS59)。
2つのハッシュ値が一致しない場合は、内部ユーザIDの認証は失敗した(内部ユーザIDが真正でない)と判断し、ログイン処理を終了する(ステップS61)。
一方、ステップS59において、2つのハッシュ値が一致する場合は、内部ユーザIDの認証は成功した(内部ユーザIDが真正である)と判断され、サービス用機器3の提供するサービス(たとえばサービスS)へのログインが許可される(ステップS60)。
ログインが許可されると、サービス用機器3の表示装置52の表示画面(図示せず)および第1の認証用機器6の表示装置62の表示画面(図示せず)に、それぞれ、その旨の表示がなされ、ログイン処理が終了する。この後、ユーザは、たとえば、サービスSを利用することが可能となる。
なお、上述の実施形態においては、公開鍵認証によるエンティティ認証(この例では、図5に示すログイン処理)として、サービスIDのエンティティ認証(サービスIDの正当性を検証するための第1の認証機器6による認証。図5、ステップS54〜ステップS56)および内部ユーザIDのエンティティ認証(内部ユーザIDの正当性を検証するためのサービス用機器3による認証。図5、ステップS57〜ステップS59)の双方向の認証処理を行うよう構成したが、この発明はこれに限定されるものではない。
提供されるサービスの種類・性質・利用態様などに応じ、公開鍵認証によるエンティティ認証として、内部ユーザIDのエンティティ認証(図5、ステップS57〜ステップS59)のみを実行するよう構成することもできる。
また、公開鍵認証によるエンティティ認証の態様はとくに限定されるものではない。たとえば、ソフトウェアの利用認証、ウェブサイトへのログイン認証、ウェブショッピング等における決済サービス認証(リダイレクトによる決済サービスへの移行を含む)など、あらゆる認証に公開鍵認証によるエンティティ認証を適用することができる。
つぎに、認証鍵の複製処理、すなわち、マスタ側鍵ペアの複製処理について説明する。図6は、認証鍵の複製処理における手順の一例を示すフローチャートである。
認証鍵の複製処理において、まず認証鍵バックアップ処理が実行される(ステップS10)。
図7は、認証鍵バックアップ処理(ステップS10)における手順の一例を示すフローチャートである。
図7に示すように、まず、第1の認証用機器6は、バックアップ用サーバ4にログインし、バックアップ用サーバ4との間でペアリングが成立すると、バックアップ用サーバ4に対しバックアップ側公開鍵の送信を要求する(ステップS11)。
バックアップ用サーバ4は、バックアップ側鍵ペア、すなわち、バックアップ側秘密鍵と当該バックアップ側秘密鍵に対応する公開鍵であるバックアップ側公開鍵、を予め生成して、バックアップ側テーブル410に記憶している。
図12に示すバックアップ側テーブル410において、サービスIDフィールド、サービス名フィールドおよび内部ユーザIDフィールドがいずれも「N/A(該当なし)」となっているレコードであって、鍵グループIDフィールドが同一値(たとえば「0」)となっている一対のレコードがバックアップ側鍵ペアに対応する。この一対のレコードのうち鍵種別フィールドが「秘密鍵」となっているレコードの鍵データフィールドがバックアップ側秘密鍵を表し、鍵種別フィールドが「公開鍵」となっているレコードの鍵データフィールドがバックアップ側公開鍵を表す。バックアップ側テーブル410には、1組のバックアップ側鍵ペアが記憶されている。
この実施形態においては、バックアップ側公開鍵に、認証局署名済みの当該バックアップ用サーバ4のサーバ証明書が付加されている(バックアップ側テーブル410のサーバ証明書データ/復元許可証明データフィールド参照)。
第1の認証用機器6からの要求(ステップS11)に応じて、バックアップ用サーバ4は、第1の認証用機器6に、上記サーバ証明書付きのバックアップ側公開鍵を送信する(ステップS12)。
第1の認証用機器6は、バックアップ側公開鍵を受信して、一時記憶する(ステップS13)。なお、受信したバックアップ側公開鍵の送信元が上記サーバ証明書に記載されたサーバ(バックアップ用サーバ4)でない場合は、認証鍵バックアップ処理をエラー終了するよう構成されている。
つぎに、第1の認証用機器6は、サービス用機器3の提供する特定のサービスのサービスIDとこれに対応する内部ユーザIDを第1の認証側テーブル680から抽出し、抽出されたサービスIDおよび内部ユーザIDの指定を含む認証鍵バックアップ要求信号としてのバックアップ側公開鍵登録要求信号を、管理用サーバ5に送信する(ステップS14)。
管理用サーバ5は、管理側テーブル580に基づいて、サービスIDからサービス用機器3を特定し、内部ユーザIDの指定を含むバックアップ側公開鍵登録要求信号を、特定されたサービス用機器3に転送する(ステップS15)。
図13に示す管理側テーブル580において、サービスID、内部ユーザIDが相互に関連付けて記憶されている。図示しないが、サービスIDに対応するサービス用機器3の連絡先、および内部ユーザIDに対応するユーザの連絡先も、併せて記憶されている。
管理側テーブル580において、有効フラグフィールドは、当該サービスIDと内部ユーザIDとの組み合わせが有効か否かを示すフラグであり、当該フラグ値が「1」であれば有効、「0」であれば無効である。たとえば、当該サービスIDと内部ユーザIDとの組み合わせに係るマスタ側秘密鍵の記憶された第1の認証用機器6が盗難にあったり、紛失したりした場合には、ユーザからの無効化依頼にしたがって、当該サービスIDと内部ユーザIDとの組み合わせを無効化する。
当該サービスIDと内部ユーザIDとの組み合わせが無効になっている場合、管理用サーバ5は、ステップS15において、バックアップ側公開鍵登録要求信号を転送することなく、認証鍵バックアップ処理をエラー終了するよう構成されている。これにより、悪意の第三者による認証鍵の複製を防止することができる。
つぎに、サービス用機器3は、管理用サーバ5から、内部ユーザIDの指定を含むバックアップ側公開鍵登録要求信号を受信すると、受信した内部ユーザIDに対応する第1の認証側公開鍵を、サービス側テーブル310から抽出し、抽出した第1の認証側公開鍵に基づいてチャレンジを生成し、生成したチャレンジを第1の認証用機器6に送信する(ステップS16)。
チャレンジの生成方法はとくに限定されるものではないが、たとえば、乱数を生成し、抽出した上記第1の認証側公開鍵を用いて、この乱数を暗号化することで、チャレンジを生成することができる。
第1の認証用機器6は、チャレンジを受信すると、受信したチャレンジを、第1の認証側テーブル680に記憶されている第1の認証側秘密鍵を用いて復号化して乱数を得、得られた乱数に基づいてレスポンスを生成し、生成したレスポンスに内部ユーザIDおよびステップS13において受信したバックアップ側公開鍵を付加したものを、サービス側公開鍵により暗号化したうえで、サービス用機器3に送信する(ステップS17)。
第1の認証側テーブル680に記憶されている複数の第1の認証側秘密鍵のうち、チャレンジの復号化に用いられる第1の認証側秘密鍵は、ステップS14において管理用サーバ5に送信したバックアップ側公開鍵登録要求信号に含まれる内部ユーザIDに対応するサービス側公開鍵と同一の鍵グループIDフィールドを持つ第1の認証側秘密鍵である。
レスポンスの生成方法はとくに限定されるものではないが、たとえば、得られた乱数に特定のハッシュ関数を用いて算出されたハッシュ値をレスポンスとすることができる。
第1の認証側テーブル680に記憶されている複数のサービス側公開鍵のうち、レスポンスの暗号化に用いられるサービス側公開鍵は、ステップS14において管理用サーバ5に送信したバックアップ側公開鍵登録要求信号に含まれるサービスIDに対応するサービス側公開鍵である。
サービス用機器3は、暗号化された内部ユーザIDおよびバックアップ側公開鍵の付加されたレスポンスを受信して、サービス側秘密鍵で復号化して、内部ユーザID、バックアップ側公開鍵およびハッシュ値を得る一方、ステップS16において生成した乱数に、ステップS17において用いられるハッシュ関数と同一のハッシュ関数を用いた演算を行って得られるハッシュ値を算出し、この2つのハッシュ値が一致するか否かを判断し、一致する場合には、得られた上記バックアップ側公開鍵と内部ユーザIDとを関連付けてサービス側テーブル310に記憶する(ステップS18)。
サービス側テーブル310に記憶されている複数のサービス側秘密鍵のうち、チャレンジの復号化に用いられるサービス側秘密鍵は、ステップS16において管理用サーバ5から受信したバックアップ側公開鍵登録要求信号に含まれる内部ユーザIDに対応する第1の認証側公開鍵と同一の鍵グループIDフィールドを持つサービス側秘密鍵である。
なお、2つのハッシュ値が一致しない場合は、内部ユーザIDの認証は失敗した(内部ユーザIDが真正でない)と判断し、認証鍵バックアップ処理を終了する。
つぎに、サービス用機器3は、復元許可証明データを生成してサービス側テーブル310に記憶するとともに、この復元許可証明データにサービス側公開鍵、サービスIDおよび内部ユーザIDを付加したものを、バックアップ側公開鍵および第1の認証側公開鍵により暗号化したうえで、第1の認証用機器6に送信する(ステップS19)。
図11に示すサービス側テーブル310において、復元限定フラグフィールドに「1」の記載されたレコードが、ステップS18において記憶されたバックアップ側公開鍵に対応するレコードである。当該レコードのサーバ証明書データフィールドには、当該バックアップ側公開鍵に付随するバックアップ用サーバ5のサーバ証明書データが記憶され、復元許可証明データフィールドには、ステップS19において生成された復元許可証明データが記憶されている。
復元限定フラグフィールドは、当該公開鍵が専ら認証鍵の復元に用いられるものであるか否かを表すフィールドであり、当該フィールド値が「1」の場合は、当該公開鍵が専ら認証鍵の復元に用いられるものであることを表す。したがって、当該フィールド値が「1」の公開鍵、すなわち、バックアップ側公開鍵をエンティティ認証に使用することはできない。このため、仮に当該バックアップ側公開鍵に対応するバックアップ側秘密鍵が盗まれたり紛失したりしたとしても、これを入手した第三者のエンティティ認証に悪用されることはない。
第1の認証用機器6は、ステップS19において送信された、バックアップ側公開鍵および第1の認証側公開鍵により暗号化された上記データを受信し、対応する第1の認証側秘密鍵により復号化したうえで、バックアップ用サーバ5に転送する(ステップS20)。
バックアップ用サーバ5は、ステップS20において送信された第1の認証側秘密鍵により復号化された上記データを受信すると、これをさらにバックアップ側秘密鍵により復号化して、上記データ、すなわち復元許可証明データにサービス側公開鍵、サービスIDおよび内部ユーザIDを付加したものを得、これをバックアップ側テーブル410に記憶する(ステップS21)。
図12に示すバックアップ側テーブル410において、サービスIDフィールド、サービス名フィールドおよび内部ユーザIDフィールドがいずれも「N/A(該当なし)」以外の値(たとえば「SSS」、「サービスS」、「AAA」)となっているレコードが、ステップS21において記憶されたデータである。当該レコードのサーバ証明書データ/復元許可証明データフィールドには、復元許可証明データが記憶されている。
なお、第1の認証用機器6にもバックアップ用サーバ4にも同一のサービス側公開鍵を配布するような場合(たとえば、サービス側鍵ペアとして汎用のサービス側鍵ペアを用いる場合)には、ステップS19からステップS21の処理におけるサービス側公開鍵の移送に替えて、第1の認証用機器6の記憶しているサービス側公開鍵にサービスIDおよび内部ユーザIDを付加したデータ(図10、第1の認証側テーブル680参照)を、第1の認証用機器6からバックアップ用サーバ4に、直接、送信するようにしてもよい。この場合、当該データを、送信前に第1の認証用機器6においてバックアップ側公開鍵により暗号化し、受信後にバックアップ用サーバ4においてバックアップ側秘密鍵により復号化するよう構成することもできる。
また、この実施形態においては、図7に示す認証鍵バックアップ処理において、バックアップ側鍵ペアとして、予め生成された1組の汎用のバックアップ側鍵ペアを用いるよう構成しているが、この発明はこれに限定されるものではない。たとえば、認証鍵バックアップ処理において、予め生成された2以上の汎用のバックアップ側鍵ペアを、適宜使い分けて用いるよう構成することもできる。また、ステップS12において、第1の認証用機器6からのバックアップ側公開鍵の送信要求を受信するたびに、個別のバックアップ側鍵ペアを生成して用いるよう構成することもできる。
図6に戻って、このようにして認証鍵バックアップ処理(ステップS10)が実行される。その後、第1の認証用機器6の故障、紛失、盗難その他の事情により認証鍵の復元が必要になったとき、認証鍵復元処理が実行される(ステップS30)。認証鍵復元処理に先立ち、認証鍵の復元先となる第2の認証用機器7が、たとえば第1の認証用機器6のユーザにより準備される。
図8は、認証鍵復元処理(ステップS30)における手順の一例を示すフローチャートである。
図8に示すように、まず、第2の認証用機器7のユーザ(第1の認証用機器6のユーザと同一のユーザ)が、たとえば、当該ユーザのログインID、ログインパスワードを用いてバックアップ用サーバ4にログインし、バックアップ用サーバ4との間でペアリングが成立すると、バックアップ用サーバ4は、第2の認証用機器7に対し第2の認証側公開鍵の送信を要求する(ステップS31)。
第2の認証用機器7は、スペア側鍵ペア、すなわち、第2の認証側秘密鍵と当該第2の認証側秘密鍵に対応する公開鍵である第2の認証側公開鍵、を予め生成して、第2の認証側テーブル(図示せず)に記憶している。マスタ側鍵ペアに替えてスペア側鍵ペアを記憶している点を除き、第2の認証側テーブルの構成は第1の認証側テーブル680の構成と同様である。
バックアップ用サーバ4からの要求(ステップS31)に応じて、第2の認証用機器7は、バックアップ用サーバ4に、上記第2の認証側公開鍵を送信する(ステップS32)。
バックアップ用サーバ4は、第2の認証側公開鍵を受信して、一時記憶する(ステップS33)。
つぎに、バックアップ用サーバ4は、第2の認証用機器7によって特定された、認証鍵の復元に係るサービスのサービスIDとこれに対応する内部ユーザIDの指定を含む認証鍵復元要求信号としての第2の認証側公開鍵登録要求信号を、管理用サーバ5に送信する(ステップS34)。
第2の認証用機器7による認証鍵の復元に係るサービスの特定方法はとくに限定されるものではないが、たとえば、ステップS31におけるログインが成功してペアリングが成立した後、バックアップ用サーバ4が、バックアップ側テーブル410から抽出した当該ユーザに係るサービス名等の一覧を、バックアップ用サーバ4の表示装置52の表示画面(図示せず)に表示し、当該一覧の中から認証鍵の復元に係るサービスを特定させるようにすることができる。
管理用サーバ5は、管理側テーブル580に基づいて、サービスIDからサービス用機器3を特定し、内部ユーザIDの指定を含む第2の認証側公開鍵登録要求信号を、特定されたサービス用機器3に転送する(ステップS35)。
管理側テーブル580において、当該サービスIDと内部ユーザIDとの組み合わせが無効になっている場合(有効フラグのフラグ値が「0」である場合)、管理用サーバ5は、ステップS35において、第2の認証側公開鍵登録要求信号を転送することなく、認証鍵復元処理をエラー終了するよう構成されている。これにより、悪意の第三者による認証鍵の複製を防止することができる。
つぎに、サービス用機器3は、管理用サーバ5から、内部ユーザIDの指定を含む第2の認証側公開鍵登録要求信号を受信すると、サービス側テーブル310に記憶されているバックアップ側公開鍵(復元限定フラグのフラグ値が「1」であるレコードに含まれる鍵データ)の中から、受信した内部ユーザIDに対応するバックアップ側公開鍵を抽出し、抽出したバックアップ側公開鍵に基づいてチャレンジを生成し、生成したチャレンジをバックアップ用サーバ4に送信する(ステップS36)。
チャレンジの生成方法はとくに限定されるものではないが、たとえば、乱数を生成し、抽出した上記バックアップ側公開鍵を用いて、この乱数を暗号化することで、チャレンジを生成することができる。
なお、ステップS36におけるチャレンジの送信に際し、送信先が当該バックアップ側公開鍵のサーバ証明書に記載されたサーバ(バックアップ用サーバ4)でない場合は、認証鍵復元処理をエラー終了するよう構成されている。
バックアップ用サーバ4は、チャレンジを受信すると、受信したチャレンジを、バックアップ側テーブル410に記憶されているバックアップ側秘密鍵を用いて復号化して乱数を得、得られた乱数に基づいてレスポンスを生成し、生成したレスポンスに、認証鍵バックアップ処理において第1の認証用機器6を介して受信した(図7、ステップS21参照)復元許可証明データと、当該データに対応する内部ユーザIDと、ステップS33において受信した第2の認証側公開鍵を付加したものを、サービス側公開鍵により暗号化したうえでサービス用機器3に送信する(ステップS37)。
レスポンスの生成方法はとくに限定されるものではないが、たとえば、得られた乱数に特定のハッシュ関数を用いて算出されたハッシュ値をレスポンスとすることができる。
バックアップ側テーブル410に記憶されている複数のサービス側公開鍵のうち、レスポンスの暗号化に用いられるサービス側公開鍵は、ステップS34において管理用サーバ5に送信した第2の認証側公開鍵登録要求信号に含まれるサービスIDに対応するサービス側公開鍵である。
サービス用機器3は、暗号化された復元許可証明データ、内部ユーザIDおよび第2の認証側公開鍵の付加されたレスポンスを受信して、サービス側秘密鍵で復号化して、復元許可証明データ、内部ユーザID、第2の認証側公開鍵およびハッシュ値を得る一方、ステップS36において生成した乱数に、ステップS37において用いられるハッシュ関数と同一のハッシュ関数を用いた演算を行って得られるハッシュ値を算出し、この2つのハッシュ値が一致するか否かを判断し、一致する場合には、さらに、得られた上記復元許可証明データが真正なものであるか否かを判断し、復元許可証明データが真正なものである場合には、得られた上記第2の認証側公開鍵と内部ユーザIDとを関連付けてサービス側テーブル310に記憶する(ステップS38)。
サービス側テーブル310に記憶されている複数のサービス側秘密鍵のうち、チャレンジの復号化に用いられるサービス側秘密鍵は、ステップS36において管理用サーバ5から受信した第2の認証側公開鍵登録要求信号に含まれる内部ユーザIDに対応する第1の認証側公開鍵と同一の鍵グループIDフィールドを持つサービス側秘密鍵である。
上記復元許可証明データが真正なものであるか否かの判断は、受信した当該復元許可証明データと、バックアップ側テーブル410のデータとを照合することにより行われる。当該復元許可証明データと同一のデータを有するレコードがバックアップ側テーブル410に存在し、かつ、当該レコードを構成するサービスIDおよび内部ユーザIDが、当該認証鍵復元処理に係るサービスIDおよび内部ユーザIDと同一であれば、上記復元許可証明データが真正なものであると判断される。
なお、ステップS38において、2つのハッシュ値が一致しない場合、すなわち、バックアップ用サーバ4の認証が失敗した場合や、上記復元許可証明データが真正なものでないと判断された場合には、バックアップ用サーバ4が真正でないと判断され、認証鍵復元処理はエラー終了する。
ステップS38において、バックアップ用サーバ4の認証が成功し、かつ、上記復元許可証明データが真正なものであると判断された場合、サービス用機器3は、さらに、サービス側公開鍵にサービスIDおよび内部ユーザIDを付加したものを、上記第2の認証側公開鍵およびバックアップ側公開鍵により暗号化したうえで、バックアップ用サーバ4に送信する(ステップS39)。
バックアップ用サーバ4は、ステップS39において送信された、第2の認証側公開鍵およびバックアップ側公開鍵により暗号化された上記データを受信し、バックアップ側秘密鍵により復号化したうえで、第2の認証用機器7に転送する(ステップS40)。
第2の認証用機器7は、ステップS40において送信された、バックアップ側秘密鍵により復号化された上記データを受信すると、これをさらに第2の認証側秘密鍵により復号化して、上記データ、すなわちサービス側公開鍵にサービスIDおよび内部ユーザIDを付加したものを得、これを第2の認証側テーブル(図示せず)に記憶する(ステップS41)。
なお、バックアップ用サーバ4にも第2の認証用機器7にも同一のサービス側公開鍵を配布するような場合(たとえば、サービス側鍵ペアとして汎用のサービス側鍵ペアを用いる場合)には、ステップS39からステップS41の処理に替えて、バックアップ用サーバ4の記憶しているサービス側公開鍵にサービスIDおよび内部ユーザIDを付加したデータ(図12、バックアップ側テーブル410参照)を、バックアップ用サーバ4から第2の認証用機器7に、直接、送信するようにしてもよい。この場合、当該データを、送信前にバックアップ用サーバ4において第2の認証側公開鍵により暗号化し、受信後に第2の認証用機器7において第2の認証側秘密鍵により復号化するよう構成することもできる。
このようにして、認証鍵復元処理が完了すると、以後、当該サービスIDに係るサービスにおいて、第1の認証用機器6の替わりに第2の認証用機器7を用いて、公開鍵認証によるログイン処理(図5参照)など公開鍵認証によるエンティティ認証が可能となる。もちろん、第1の認証用機器6と第2の認証用機器7とを並存させることも可能である。
つぎに、バックアップ用サーバ4を介在させることなく、第1の認証用機器6と第2の認証用機器7との間で、直接、認証鍵を複製する処理(直接複製処理)について説明する。
図9は、直接複製処理における手順の一例を示すフローチャートである。
図9に示すように、第1の認証用機器6と第2の認証用機器7との間でペアリングが成立すると、第1の認証用機器6は、第2の認証用機器7に対し第2の認証側公開鍵の送信を要求する(ステップS71)。
第2の認証用機器7は、スペア側鍵ペア、すなわち、第2の認証側秘密鍵と当該第2の認証側秘密鍵に対応する公開鍵である第2の認証側公開鍵、を予め生成して、第2の認証側テーブル(図示せず)に記憶している。マスタ側鍵ペアに替えてスペア側鍵ペアを記憶している点を除き、第2の認証側テーブルの構成は第1の認証側テーブル680の構成と同様である。
第1の認証用機器6からの要求(ステップS71)に応じて、第2の認証用機器7は、第1の認証用機器6に、上記第2の認証側公開鍵を送信する(ステップS72)。
第1の認証用機器6は、第2の認証側公開鍵を受信して、一時記憶する(ステップS73)。
つぎに、第1の認証用機器6は、認証鍵の複製に係るサービスのサービスIDとこれに対応する内部ユーザIDの指定を含む直接複製要求信号としての第2の認証側公開鍵登録要求信号を、管理用サーバ5に送信する(ステップS74)。
認証鍵の複製に係るサービスの特定方法はとくに限定されるものではないが、たとえば、第1の認証用機器6が、第1の認証側テーブル680から抽出した当該ユーザに係るサービス名等の一覧を、第1の認証用機器6の表示装置62の表示画面(図示せず)に表示し、当該一覧の中から認証鍵の複製に係るサービスを特定させるようにすることができる。
管理用サーバ5は、管理側テーブル580に基づいて、サービスIDからサービス用機器3を特定し、内部ユーザIDの指定を含む第2の認証側公開鍵登録要求信号を、特定されたサービス用機器3に転送する(ステップS75)。
管理側テーブル580において、当該サービスIDと内部ユーザIDとの組み合わせが無効になっている場合(有効フラグのフラグ値が「0」である場合)、管理用サーバ5は、ステップS75において、第2の認証側公開鍵登録要求信号を転送することなく、当該直接複製処理をエラー終了するよう構成されている。これにより、悪意の第三者による認証鍵の複製を防止することができる。
つぎに、サービス用機器3は、管理用サーバ5から、内部ユーザIDの指定を含む第2の認証側公開鍵登録要求信号を受信すると、サービス側テーブル310に記憶されている第1の認証側公開鍵(復元限定フラグのフラグ値が「0」であるレコードに含まれる鍵データ)の中から、受信した内部ユーザIDに対応する第1の認証側公開鍵を抽出し、抽出した第1の認証側公開鍵に基づいてチャレンジを生成し、生成したチャレンジを第1の認証用機器6に送信する(ステップS76)。
チャレンジの生成方法はとくに限定されるものではないが、たとえば、乱数を生成し、抽出した上記第1の認証側公開鍵を用いて、この乱数を暗号化することで、チャレンジを生成することができる。
第1の認証用機器6は、チャレンジを受信すると、受信したチャレンジを、第1の認証側テーブル680に記憶されている第1の認証側秘密鍵を用いて復号化して乱数を得、得られた乱数に基づいてレスポンスを生成し、生成したレスポンスに、当該直接複製処理に係る内部ユーザIDと、ステップS73において受信した第2の認証側公開鍵を付加したものを、サービス側公開鍵により暗号化したうえでサービス用機器3に送信する(ステップS77)。
レスポンスの生成方法はとくに限定されるものではないが、たとえば、得られた乱数に特定のハッシュ関数を用いて算出されたハッシュ値をレスポンスとすることができる。
第1の認証側テーブル680に記憶されている複数のサービス側公開鍵のうち、レスポンスの暗号化に用いられるサービス側公開鍵は、ステップS74において管理用サーバ5に送信した第2の認証側公開鍵登録要求信号に含まれるサービスIDに対応するサービス側公開鍵である。
サービス用機器3は、暗号化された内部ユーザIDおよび第2の認証側公開鍵の付加されたレスポンスを受信して、サービス側秘密鍵で復号化して、内部ユーザID、第2の認証側公開鍵およびハッシュ値を得る一方、ステップS76において生成した乱数に、ステップS77において用いられるハッシュ関数と同一のハッシュ関数を用いた演算を行って得られるハッシュ値を算出し、この2つのハッシュ値が一致するか否かを判断し、一致する場合には、得られた上記第2の認証側公開鍵と内部ユーザIDとを関連付けてサービス側テーブル310に記憶する(ステップS78)。
サービス側テーブル310に記憶されている複数のサービス側秘密鍵のうち、チャレンジの復号化に用いられるサービス側秘密鍵は、ステップS76において管理用サーバ5から受信した第2の認証側公開鍵登録要求信号に含まれる内部ユーザIDに対応する第1の認証側公開鍵と同一の鍵グループIDフィールドを持つサービス側秘密鍵である。
なお、ステップS78において、2つのハッシュ値が一致しない場合、すなわち、第1の認証用機器6の認証が失敗した場合には、第1の認証用機器6が真正でないと判断され、当該直接複製処理はエラー終了する。
ステップS78において、第1の認証用機器6の認証が成功した場合、サービス用機器3は、さらに、サービス側公開鍵にサービスIDおよび内部ユーザIDを付加したものを、上記第2の認証側公開鍵および第1の認証側公開鍵により暗号化したうえで、第1の認証用機器6に送信する(ステップS79)。
第1の認証用機器6は、ステップS79において送信された、第2の認証側公開鍵および第1の認証側公開鍵により暗号化された上記データを受信し、第1の認証側秘密鍵により復号化したうえで、第2の認証用機器7に転送する(ステップS80)。
第2の認証用機器7は、ステップS80において送信された、第1の認証側秘密鍵により復号化された上記データを受信すると、これをさらに第2の認証側秘密鍵により復号化して、上記データ、すなわちサービス側公開鍵にサービスIDおよび内部ユーザIDを付加したものを得、これを第2の認証側テーブル(図示せず)に記憶する(ステップS81)。
なお、第1の認証用機器6にも第2の認証用機器7にも同一のサービス側公開鍵を配布するような場合(たとえば、サービス側鍵ペアとして汎用のサービス側鍵ペアを用いる場合)には、ステップS79からステップS81の処理に替えて、第1の認証用機器6の記憶しているサービス側公開鍵にサービスIDおよび内部ユーザIDを付加したデータ(図12、第1の認証側テーブル680参照)を、第1の認証用機器6から第2の認証用機器7に、直接、送信するようにしてもよい。この場合、当該データを、送信前に第1の認証用機器6において第2の認証側公開鍵により暗号化し、受信後に第2の認証用機器7において第2の認証側秘密鍵により復号化するよう構成することもできる。
このようにして、直接複製処理が完了すると、以後、当該サービスIDに係るサービスにおいて、第1の認証用機器6のほかに、第2の認証用機器7も、公開鍵認証によるログイン処理(図5参照)など公開鍵認証によるエンティティ認証に用いることが可能となる。もちろん、この後、第1の認証用機器6を無効化することも可能である。
なお、上述の認証鍵バックアップ処理(図7参照)、認証鍵復元処理(図8参照)および直接複製処理(図9参照)においては、公開鍵認証によるエンティティ認証(この例では、図5に示すログイン処理)として、サービスIDのエンティティ認証および内部ユーザIDのエンティティ認証の双方向の認証処理を行う場合を想定して説明したが、この発明はこれに限定されるものではない。
たとえば、公開鍵認証によるエンティティ認証として、内部ユーザIDのエンティティ認証(図5、ステップS57〜ステップS59)のみを実行する場合にも、この発明を適用することができる。この場合には、認証鍵復元処理(図8参照)におけるサービス側公開鍵の送信、転送、登録の各処理(ステップS39ないしステップS41参照)、ならびに、直接複製処理(図9参照)におけるサービス側公開鍵の送信、転送、登録の各処理(ステップS79ないしステップS81参照)を省略することができる。
また、上述の実施形態においては、管理用サーバ5を実機として実現した場合を例に説明したが、この発明はこれに限定されるものではない。管理用サーバ5を仮想マシンとして実現することもできる。この場合、サービス用機器3と管理用サーバ5とを同一の物理マシン上に並存させることもできる。また、サービス用機器3自体に管理用サーバ5の機能を持たせるよう構成することもできる。
また、上述の実施形態においては、1つのバックアップサーバ4を備え、サービス用機器3のサービス側制御部30のバックアップ用サーバ認証部33は、バックアップ用サーバ4の認証を実行するよう構成され、サービス側記憶部31は、サービス側制御部30のバックアップ用サーバ認証部33によるバックアップ用サーバ4の認証が成功したことを条件に、バックアップ用サーバ4から受信した第2の認証側公開鍵を記憶するよう構成された場合について説明したが、この発明はこれに限定されるものではない。
たとえば、バックアップ用サーバを複数備え、サービス用機器のサービス側制御部のバックアップ用サーバ認証部は、複数のバックアップ用サーバの認証を実行するよう構成され、サービス側記憶部は、サービス側制御部のバックアップ用サーバ認証部による所定数以上のバックアップ用サーバの認証が成功したことを条件に、いずれかのバックアップ用サーバから受信した第2の認証側公開鍵を記憶するよう構成することもできる。
なお、図4に示すステップS92、ステップS94、ステップS95、ステップS98、図5に示すステップS52、ステップS54、ステップS56、ステップS58、図7に示すステップS11、ステップS13、ステップS14、ステップS17、ステップS20、図9に示すステップS71、ステップS73、ステップS74、ステップS77、ステップS80が、図2の第1の認証用機器6の第1の認証側制御部60に対応する。
このうち、ステップS94、ステップS98が、第1の認証側記憶部68に対応する。ステップS20が、復元許可証明データ転送部69に対応する。
図4に示すステップS91、ステップS92、ステップS93、ステップS96、ステップS97、図5に示すステップS51、ステップS52、ステップS53、ステップS55、ステップS57、ステップS59、ステップS61、ステップS60、図7に示すステップS16、ステップS18、ステップS19、図8に示すステップS36、ステップS38、ステップS39、図9に示すステップS76、ステップS78、ステップS79が、図2のサービス用危機3のサービス側制御部30に対応する。
このうち、ステップS93、ステップS96、ステップS18、ステップS38が、サービス側記憶部31に対応する。ステップS16、ステップS18が、第1の認証用機器認証部32に対応する。ステップS36、ステップS38が、バックアップ用サーバ認証部33に対応する。ステップS19が復元許可証明データ生成部35に対応する。ステップS38が復元許可証明データ真偽判定部36に対応する。
図7に示すステップS12、ステップS21、図8に示すステップS31、ステップS33、ステップS34、ステップS37、ステップS40が、図2のバックアップ用サーバ4のバックアップ側制御部40に対応する。
このうち、ステップS21がバックアップ側記憶部41に対応する。また、ステップS21は復元許可証明データ受信部45に対応する。ステップS37が復元許可証明データ送信部46に対応する。
図8に示すステップS32、ステップS41、図9に示すステップS72、ステップS81が、図2の第2の認証用機器7の第2の認証側制御部70に対応する。
図7に示すステップS15、図8のステップS35、図9のステップS75が、図2の管理用サーバ5の管理側制御部50に対応する。
なお、上記直接複製処理(図9参照)を考慮した場合、この発明は、次のように把握することもできる。
[発明A]
第1の認証側制御部を備えた第1の認証用機器と、
サービス側制御部を備え、情報通信手段を介して前記第1の認証用機器と通信可能なサービス用機器と、
第2の認証側制御部を備え、前記情報通信手段を介して前記第1の認証用機器およびサービス用機器と通信可能な第2の認証用機器と、
を備えた認証鍵複製システムであって、
前記第1の認証側制御部は、第1の認証側秘密鍵を記憶する第1の認証側記憶部を備え、
前記サービス側制御部は、第1の認証側秘密鍵に対応する第1の認証側公開鍵を記憶するサービス側記憶部を備え、
前記第2の認証側制御部は、第2の認証側秘密鍵を記憶する第2の認証側記憶部を備え、
前記サービス側制御部は、前記第1の認証用機器から送信された直接複製要求信号に基づいて第1の認証側秘密鍵および第1の認証側公開鍵を用いた前記第1の認証用機器の公開鍵認証を実行する第1の認証用機器認証部、を備え、
前記サービス側記憶部は、前記第1の認証用機器認証部による認証が成功したことを条件に、前記第1の認証用機器から受信した、第2の認証側秘密鍵に対応する第2の認証側公開鍵を記憶するよう構成されたこと、
を特徴とする認証鍵複製システム。
[発明B]
発明Aの認証鍵複製システムにおいて、
前記サービス側記憶部は、さらにサービス側秘密鍵を記憶し、
前記第1の認証側記憶部は、さらにサービス側秘密鍵に対応するサービス側公開鍵を記憶し、
前記第1の認証側制御部は、前記サービス用機器に第2の認証側公開鍵を送信する際に、サービス側公開鍵により暗号化した第2の認証側公開鍵を送信するよう構成され、
前記サービス側記憶部は、前記第1の認証用機器から受信した暗号化されたサービス側公開鍵をサービス側秘密鍵により復号化して記憶するよう構成されたこと、
を特徴とする、認証鍵複製システム。
[発明C]
発明AないしBのいずれかの認証鍵複製システムに用いられる前記第1の認証用機器。
[発明D]
発明AないしBのいずれかの認証鍵複製システムに用いられる前記第2の認証用機器。
[発明E]
発明AないしBのいずれかの認証鍵複製システムに用いられる前記サービス用機器。
[発明F]
コンピュータを、発明Cの第1の認証用機器の第1の認証側制御部、発明Dの第2の認証用機器の第2の認証側制御部または発明Eのサービス用機器のサービス側制御部として機能させるためのプログラム。
[発明G]
発明Fのプログラムを記憶した記録媒体。
[発明H]
第1の認証用機器と、情報通信手段を介して前記第1の認証用機器と通信可能なサービス用機器と、前記情報通信手段を介して前記第1の認証用機器およびサービス用機器と通信可能な第2の認証用機器と、を備えた認証鍵複製システム、を用いた認証鍵複製方法であって、
前記第1の認証用機器が、第1の認証側秘密鍵を記憶するステップと、
前記サービス用機器が、第1の認証側秘密鍵に対応する第1の認証側公開鍵を記憶するステップと、
前記第2の認証用機器が、第2の認証側秘密鍵を記憶するステップと、
前記サービス用機器が、前記第1の認証用機器から送信された直接複製要求信号に基づいて第1の認証側秘密鍵および第1の認証側公開鍵を用いた前記第1の認証用機器の公開鍵認証を実行する第1の認証用機器認証ステップと、
前記サービス用機器が、前記第1の認証用機器認証ステップによる認証が成功したことを条件に、前記第1の認証用機器から受信した、第2の認証側秘密鍵に対応する第2の認証側公開鍵を記憶するステップと、を備えたこと、
を特徴とする認証鍵複製方法。
なお、上述の実施形態においては、認証鍵複製システム2のサービス用機器3およびバックアップ用サーバ4側のプログラムを記憶した記録媒体として、HDDに装着されたハードディスクを例示し、第1の認証用機器6および第2の認証用機器7側のプログラムを記憶した記録媒体として、SSDに装着されたフラッシュメモリを例示しているが、プログラムを記憶した記録媒体はこれらに限定されるものではなく、プログラムを記憶した記録媒体として、たとえば、外部メモリカード、CD−ROM、DVD−ROM、フレキシブルディスク、磁気テープを用いることもできる。さらに、主記憶装置もプログラムを記憶した記録媒体として用いることができる。
また、プログラムの配布態様は特に限定されるものではなく、記録媒体にプログラムを記憶した状態で配布するほか、有線や無線の情報通信手段を介して当該プログラムを配布するようにしてもよい。
また、プログラムの記録態様は特に限定されるものではない。直接実行できる形で記録媒体に記憶したり配布したりする他、たとえば、解凍して使用するように圧縮された形で記録媒体に記憶したり配布したりすることもできる。
なお、上述の各実施形態においては、コンピュータを用いて図2の各機能を実現する場合を例に説明したが、これらの機能の一部または全部を、ハードウェアロジックを用いて構成するようにしてもよい。
また、上述のブロック図、ハードウェア構成、フローチャート、データベース(テーブル)の構成等は、例として挙げたものであり、本願発明は、これらに限定されるものではない。
上記においては、本発明を好ましい実施形態として説明したが、各用語は、限定のために用いたのではなく、説明のために用いたものであって、本発明の範囲および精神を逸脱することなく、添付のクレームの範囲において、変更することができるものである。また、上記においては、本発明のいくつかの典型的な実施形態についてのみ詳細に記述したが、当業者であれば、本発明の新規な教示および利点を逸脱することなしに上記典型的な実施形態において多くの変更が可能であることを、容易に認識するであろう。したがって、そのような変更はすべて、本発明の範囲に含まれるものである。