JP2017152877A - 電子鍵再登録システム、電子鍵再登録方法およびプログラム - Google Patents

Abstract

【課題】電子鍵再登録時において、オンラインによる鍵の復旧が可能な電子鍵再登録システム、電子鍵再登録方法およびプログラムを提供する。
【解決手段】電子鍵再登録システム１００は、メタデータサービス１５０が、認証方式を認証の強度毎にグループ分けした認証レベル情報をメタデータ２００として有する。認証鍵リレー型キーストア１４０は、ＷＥＢサービス１１０に認証モジュール１３０を登録する際に提示された認証ポリシー１１３を保管し、認証モジュール１３０の変更または追加時に、メタデータサービス１５０の認証レベル情報を参照し、参照した認証レベルと保管している認証モジュール１３０の認証ポリシー１１３とに基づいて、変更または追加される認証モジュール１３０の認証モジュール関連付け情報１３３と保持しているＷＥＢサービス向け秘密鍵１４２とを関連付ける。
【選択図】図１

Description

本発明は、電子鍵再登録システム、電子鍵再登録方法およびプログラムに関する。

鍵による暗号化を用いると、情報を第三者に盗み見られることなく安全に送信することができる。鍵による暗号化は公開鍵暗号方式と共通鍵方式があり、鍵を紛失すると暗号化された情報が復号できなくなる。この対処方法として鍵を復旧できるようにする方法が提案されている。

特許文献１には、利用者からの生成要求に基づいて暗号処理に用いる鍵を生成して利用者に渡す鍵生成手段を持つ鍵生成機関装置と、上記鍵生成機関装置で生成された鍵を暗号化された状態で保管する鍵保管機関装置と、利用者からのリカバリ要求に基づいて上記鍵保管機関装置から鍵を取り出したのち、復号して利用者に渡す鍵リカバリ手段を持つ鍵リカバリ機関装置とを備える鍵リカバリシステムにおける鍵リカバリ権限管理方法が記載されている。特許文献１に記載の鍵リカバリ権限管理方法は、社内で利用する鍵システムを想定しており、あるグループに所属していることを確認することで、鍵の復旧を可能としている。正当な権限のない者に鍵の復旧をさせることはできないが、社内ではそこに存在する人物と権限の関係を直接確認できるため実行可能である。また、グループに所属する人数は数百〜数千人程度で直接確認による方法が可能である。

特開２０００−２８６８３１号公報

特許文献１に記載の技術では、社内向けであれば本人確認を行った上で鍵の復旧を実行することは可能である。しかしながら、ＷＥＢサービスの場合はユーザの数は数万人に達し、さらにオンライン上の繋がりだけで直接的な関係を持たないことが多く復旧の際に本人かどうか確認する方法が困難であるという課題がある。

このような背景を鑑みて本発明がなされたのであり、本発明は、電子鍵再登録時において、オンラインによる鍵の復旧が可能な電子鍵再登録システム、電子鍵再登録方法およびプログラムを提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、秘密鍵と公開鍵のペアを生成し、生成した前記秘密鍵を閉じ込めて保管する鍵処理保管領域と、前記秘密鍵との関連付け情報と、を有する認証デバイスと、認証方式および認証の強度を示す認証ポリシーに従って、利用可能な前記認証デバイスを決定するとともに、前記認証デバイスで生成された前記公開鍵を管理するＷＥＢサービスと、前記ＷＥＢサービスとの間で鍵を利用して前記認証デバイスの情報を保管するメタデータサービスと、前記関連付け情報を、ネットワーク上で保持するキーストアと、を備え、前記メタデータサービスは、前記認証方式を前記認証の強度毎にグループ分けした認証レベル情報をメタデータとして有し、前記キーストアは、前記ＷＥＢサービスに前記認証デバイスを登録する際に提示された前記認証ポリシーを保管し、前記認証デバイスの変更または追加時に、変更または追加される前記認証デバイスの前記関連付け情報を取得し、取得した前記関連付け情報を基に、前記メタデータサービスの前記認証レベル情報を参照し、参照した前記認証レベル情報の認証レベルと保管している前記認証デバイスの前記認証ポリシーとに基づいて、変更または追加される前記認証デバイスの前記関連付け情報と保持している前記秘密鍵とを関連付けることを特徴とする電子鍵再登録システムとした。

また、請求項７に記載の発明は、秘密鍵と公開鍵のペアを生成し、生成した前記秘密鍵を閉じ込めて保管する鍵処理保管領域と、前記秘密鍵との関連付け情報と、を有する認証デバイスと、認証方式および認証の強度を示す認証ポリシーに従って、利用可能な前記認証デバイスを決定するとともに、前記認証デバイスで生成された前記公開鍵を管理するＷＥＢサービスと、前記ＷＥＢサービスとの間で鍵を利用して前記認証デバイスの情報を保管するとともに、前記認証方式を前記認証の強度毎にグループ分けした認証レベル情報をメタデータとして有するメタデータサービスと、前記関連付け情報と、前記ＷＥＢサービスに前記認証デバイスを登録する際に提示された前記認証ポリシーとをネットワーク上で保管するキーストアと、を備える電子鍵再登録システムの電子鍵再登録方法であって、前記キーストアは、前記認証デバイスの変更または追加時に、変更または追加される前記認証デバイスの前記関連付け情報を取得するステップと、取得した前記関連付け情報を基に、前記メタデータサービスの前記認証レベル情報を参照するステップと、参照した前記認証レベル情報の認証レベルと保管している前記認証デバイスの前記認証ポリシーとに基づいて、変更または追加される前記認証デバイスの前記関連付け情報と保持している前記秘密鍵とを関連付けるまたは関連付け不可を決定するステップと、を実行することを特徴とする電子鍵再登録方法とした。

また、請求項８記載の発明は、秘密鍵と公開鍵のペアを生成し、生成した前記秘密鍵を閉じ込めて保管する鍵処理保管領域と、前記秘密鍵との関連付け情報と、を有する認証デバイスと、認証方式および認証の強度を示す認証ポリシーに従って、利用可能な前記認証デバイスを決定するとともに、前記認証デバイスで生成された前記公開鍵を管理するＷＥＢサービスと、前記ＷＥＢサービスとの間で鍵を利用して前記認証デバイスの情報を保管するとともに、前記認証方式を前記認証の強度毎にグループ分けした認証レベル情報をメタデータとして有するメタデータサービスと、前記関連付け情報と、前記ＷＥＢサービスに前記認証デバイスを登録する際に提示された前記認証ポリシーとをネットワーク上で保管するキーストアと、を備える電子鍵再登録システムの前記キーストアとしてのコンピュータを、前記認証デバイスの変更または追加時に、変更または追加される前記認証デバイスの前記関連付け情報を取得する取得手段、取得した前記関連付け情報を基に、前記メタデータサービスの前記認証レベル情報を参照する参照手段、参照した前記認証レベル情報の認証レベルと保管している前記認証デバイスの前記認証ポリシーとに基づいて、変更または追加される前記認証デバイスの前記関連付け情報と保持している前記秘密鍵とを関連付けるまたは関連付け不可を決定する決定手段、として機能させるためのプログラムとした。

このようにすることで、ＷＥＢサービス側は特に何も処理負担することなく、認証モジュールの追加や交換が本システム側で処理完了できる。また、ユーザが利用している各ＷＥＢサービスへの認証モジュールの追加や更新の手間を軽減することができる。また、ＷＥＢサービス向け秘密鍵を、ネットワーク上のサーバで保管しているので、ＷＥＢサービス向けの秘密鍵が認証モジュールの紛失とともになくなることがないため、ユーザからの鍵紛失時のＷＥＢサービス側への問い合わせが減り、ＷＥＢサービス側の運用負担を軽減することができる。

また、請求項２に記載の発明は、前記キーストアが、前記認証デバイスの変更または追加時に、前記メタデータサービスから参照した前記認証レベル情報の認証レベルが、保管している前記認証デバイスの前記認証ポリシーの認証レベル以上の場合に、変更または追加される前記認証デバイスの前記関連付け情報と保持している前記秘密鍵とを関連付けることを特徴とする電子鍵再登録システムとした。

このようにすることで、ＷＥＢサービス側は特に何も処理負担することなく、認証モジュールの更新や追加が本システム側で処理完了できる。また、ユーザが利用している各ＷＥＢサービスへの認証モジュールの追加や更新の手間を軽減することができる。また、ユーザが利用している各ＷＥＢサービスへの認証モジュールの追加や更新の手間を軽減することができる。

また、請求項３に記載の発明は、前記認証デバイスを備える端末が、ネットワーク上の認証サーバと前記キーストアに接続可能な場合、前記端末と前記認証サーバ間は鍵を利用して前記キーストアにログインし、前記キーストアは、前記端末を前記認証サーバへリダイレクトさせて、前記端末と前記認証サーバ間で利用者認証を実行させ、前記認証サーバから受け取った認証結果アサーションが良であるならば、前記端末にアクセス許可することを特徴とする電子鍵再登録システムとした。

このようにすることで、キーストアは、端末を認証サーバへリダイレクトさせて、端末と認証サーバ間で利用者認証を実行させることで、オンラインで対面での本人確認相当のユーザの確認を取ることができる。

また、請求項４に記載の発明は、前記認証デバイスを備える端末が、ネットワーク上の認証サーバと前記キーストアに接続可能な場合、前記端末と前記キーストア間で利用者認証を実行し、前記利用者認証実行後、前記キーストアは、利用者ＩＤを生成し、前記認証サーバは、前記キーストアとの認証結果アサーションが良であるならば、前記キーストアとの間で前記利用者ＩＤを共有し、前記キーストアは、前記利用者ＩＤを保存するとともに、前記端末に利用者ＩＤの登録完了を通知することを特徴とする電子鍵再登録システムとした。

このようにすることで、キーストアは、利用者ＩＤの生成要求時、認証サーバとの間で認証結果アサーションを実行し、端末に利用者ＩＤの登録完了を通知するので、ＷＥＢサービス側は特に何も処理負担することなく、利用者ＩＤの登録を行うことができる。

また、請求項５に記載の発明は、前記認証デバイスを備える端末が、ネットワーク上の認証サーバと前記キーストアに接続可能な場合、前記キーストアは、前記端末から利用者ＩＤの確認要求を受け付けたならば、前記認証サーバに前記利用者ＩＤを要求し、前記認証サーバは、前記キーストアとの認証結果アサーションが良であるならば、前記キーストアに前記利用者ＩＤを送信することを特徴とする電子鍵再登録システムとした。

このようにすることで、キーストアは、利用者ＩＤの確認要求時、認証サーバとの間で認証結果アサーションを実行し、端末に利用者ＩＤを送信するので、ＷＥＢサービス側は特に何も処理負担することなく、利用者ＩＤの確認を行うことができる。

また、請求項６に記載の発明は、前記メタデータサービスは、さらに前記秘密鍵の保管領域情報を前記メタデータとして有し、前記ＷＥＢサービスからの要求に応じて、前記秘密鍵の保管領域情報を参照させることを特徴とする電子鍵再登録システムとした。

このようにすることで、キーストアは、メタデータサービスのメタデータを参照することで、同じ認証レベルであれば、どの認証モジュールで認証を行ってもよいため、認証モジュールを追加・変更した際に、認証レベルが同じ認証モジュールであれば、ＷＥＢサービス側に認証レベルを確認する必要がない。これにより、ＷＥＢサービス側に再度、利用可能な認証モジュールかどうか問い合わせる回数（頻度）を大幅に減らすことができ、ユーザの手間およびＷＥＢサービス側の運用負担を低減することができる。

本発明によれば、電子鍵再登録時において、オンラインによる鍵の復旧が可能な電子鍵再登録システム、電子鍵再登録方法およびプログラムを提供することができる。

本発明の実施形態に係る電子鍵再登録システムを示す構成図である。 本発明の実施形態に係る電子鍵再登録システムのメタデータサービスのメタデータを表にして示す図である。 本発明の実施形態に係る電子鍵再登録システムのユーザと通信キャリアとの契約後の利用者認証用保持データを表にして示す図である。 本発明の実施形態に係る電子鍵再登録システムの認証鍵リレー型キーストアとネットワーク認証サーバ間で信頼関係確立後の利用者認証用保持データを表にして示す図である。 本発明の実施形態に係る電子鍵再登録システムの認証鍵リレー型キーストアとネットワーク認証サーバ間で信頼関係が確立し利用者認証の事前設定後の利用者認証用保持データを表にして示す図である。 本発明の実施形態に係る電子鍵再登録システムの契約が完了し、認証鍵リレー型キーストアとネットワーク認証サーバ間で信頼関係が確立し利用者認証の事前設定後さらに、利用者ＩＤを登録した場合の利用者認証用保持データを表にして示す図である。 本発明の実施形態に係る電子鍵再登録システムの認証鍵リレー型キーストア側の保持情報のデータ構造を示す図である。 本発明の実施形態に係る電子鍵再登録システムの利用者認証事前登録を説明するシーケンス（動作例Ａ）である。 本発明の実施形態に係る電子鍵再登録システムのクラウドのサーバリソースが様々な価格形態で提供されていることを説明する図である。利用者認証事前登録を説明するシーケンス（動作例Ａ）である。 本発明の実施形態に係る電子鍵再登録システムの利用者認証を説明するシーケンス（動作例Ｂ）である。 本発明の実施形態に係る電子鍵再登録システムの利用者認証を説明するシーケンス（動作例Ｂ）である。 本発明の実施形態に係る電子鍵再登録システムの利用者ＩＤの登録を説明するシーケンス（動作例Ｃ）である。 本発明の実施形態に係る電子鍵再登録システムの利用者ＩＤの確認を説明するシーケンス（動作例Ｄ）である。 本発明の実施形態に係る電子鍵再登録システムの端末の更新を説明するシーケンス（動作例Ｅ）である。 本発明の実施形態に係る電子鍵再登録システムの端末の更新を説明するシーケンス（動作例Ｅ）である。 本発明の実施形態に係る電子鍵再登録システムの認証鍵リレー型キーストア、ＷＥＢサービス(甲)、およびＷＥＢサービス(乙)に保持される秘密鍵および認証ポリシーを示す図である。 本発明の実施形態に係る電子鍵再登録システムの (新)認証モジュール（モデルＢ）(新)と甲サービス向け秘密鍵(甲)の関連付け実行を説明する図である。 本発明の実施形態に係る電子鍵再登録システムの端末の追加を説明するシーケンス（動作例Ｆ）である。 本発明の実施形態に係る電子鍵再登録システムの端末の追加を説明するシーケンス（動作例Ｆ）である。 本発明の実施形態に係る電子鍵再登録システムの認証鍵リレー型キーストア１４０に保持される秘密鍵および認証ポリシーを示す図である。 本発明の実施形態に係る電子鍵再登録システムの第２認証モジュール（モデルＢ）(新)と甲サービス向け秘密鍵(甲)の関連付け実行を説明する図である。 本発明の実施形態に係る電子鍵再登録システムの固定回線などを利用した家電への適用例を示す構成図である。 本発明の実施形態に係る電子鍵再登録システムのＨＧＷの登録を説明する図である。 本発明の実施形態に係る電子鍵再登録システムの家電の登録を説明する図である。 ＦＩＤＯAllianceの認証方法を説明する図である。 ＦＩＤＯAllianceの認証方法の特徴を説明する図である。 ＦＩＤＯAllianceの利用手順を説明する図である。 公開鍵を用いた認証（ＦＩＤＯ）の問題点を説明する図である。 図２８の問題点の解決の方向性を説明する図である。 図２９の課題を説明する図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）における電子鍵再登録システム等について説明する。
（背景説明）
ＷＥＢサービスではＰＷ（パスワード）による認証が限界を迎えている。辞書攻撃等によるアカウントの不正操作が頻発しているのが現状である。ＰＷに依存しない認証方法として、鍵による認証が検討されている（標準規格策定団体；FIDO Alliance、2012年発足）。
ＦＩＤＯ（First IDentity Online）Allianceは、秘密鍵を生成した場所に閉じ込めたまま、認証に利用することでセキュリティを高めている。ＦＩＤＯAllianceは、標準化された公開鍵暗号方式（ＰＫＩ）に基づいている。標準のプロトコルは２つあり、１つは、２要素認証の技術を進化させた認証Ｕ２Ｆ（Universal Second Factor）プロトコル、もう1つは、ＦＩＤＯ標準に対応したモバイルなどのデバイス経由でパスワードを使用しない認証ＵＡＦ（Universal Authentication Framework）プロトコルである。ＦＩＤＯの標準認証には、生体認証技術やＴＰＭ（Trusted Platform Module）、ＮＦＣ（Near Field Communication）に対応し、デバイスやプラグインにも対応しているため、ＷＥＢサイトやクラウドアプリもＦＩＤＯに準拠した対応デバイスにより、オンライン認証の強化を図ることができる。

<ＦＩＤＯAllianceの認証方法>
図２５は、ＦＩＤＯAllianceの認証方法を説明する図である。
図２５に示すように、ＷＥＢサービス１０は、アカウント１１と、アカウント１１に関連付けられた公開鍵１２と、を有する。スマートホン（以下、適宜スマホという）等の端末２０は、ＦＩＤＯAllianceの認証モジュール３０に接続可能である。認証モジュール３０は、認証判定モジュール３１と、秘密鍵３２を保管する鍵処理保管領域３３と、を有する。ＷＥＢサービス１０と認証モジュール３０が接続された端末２０とは、ＦＩＤＯ（ＵＡＦ）プロトコルに準拠した認証を行う。
ＷＥＢサービス１０では、アカウント１１と公開鍵１２とは関連付けられている。

図２５に示すように、秘密鍵３２・公開鍵１２のペアを認証デバイス（図２５では認証モジュール３０）で生成し、秘密鍵３２は認証デバイスに閉じ込めておく。閉じ込めておくとは、秘密鍵３２については、鍵の生成から削除まで認証モジュール３０の鍵処理保管領域３３から取り出さないことをいう。秘密鍵３２を生成した場所（鍵処理保管領域３３）に閉じ込めたまま、認証に利用することでセキュリティを高めている。セキュリティを高める工夫として、さらに認証デバイスに閉じ込めた鍵による認証は、所有物による認証の性質も兼ね備えることでセキュリティを強化している。

<ＦＩＤＯAllianceの認証方法の特徴>
図２６は、ＦＩＤＯAllianceの認証方法の特徴を説明する図である。
図２６に示すように、ＷＥＢサービス１０は、ＷＥＢサービスアプリケーション１３と、ＦＩＤＯサーバ１５とを有し、ＷＥＢサービスアプリケーション１３は、ユーザ管理データベース（ＤＢ）１４に格納されたアカウント１１を参照する。ＦＩＤＯサーバ１５は、ＷＥＢサービス向け公開鍵１２を格納する鍵管理領域１６を有する。
ＷＥＢサービス１０は、メタデータサービス１との間で、認証モジュールの情報３を相互に参照する。メタデータサービス１は、メタデータサービス向け公開鍵２を有する。認証モジュールの情報３には、認証モジュールの認証方法（ＰＩＮ、虹彩、指紋等）の認証の精度等の情報が記載されている。

端末２０は、ブラウザ・アプリケーション２１、ＦＩＤＯクライアント２２、認証領域情報２３、および認証モジュールドライバ２４を有する。ＦＩＤＯクライアント２２は、ＷＥＢサービス１０との間でＦＩＤＯ（ＵＡＦ）プロトコルに準拠して、ＷＥＢサービス１０側の認証ポリシーに従った認証を行う。認証ポリシーとは、ＷＥＢサービス１０側がユーザに提示する、サービスに必要な認証方式や認証の強度の条件のことをいう。

認証モジュール３０は、認証モジュールドライバ２４、認証判定モジュール３１、および鍵処理保管領域３３を有する。図２６の場合、鍵処理保管領域３３は、ＷＥＢサービス向け秘密鍵３２のほか、メタデータサービス向け秘密鍵３４を保管する。なお、認証モジュール３０は、様々な形態を許容されている。ＦＩＤＯのＵＡＦプロトコルが動作すれば、ハードウェアやソフトウェアでの実現は問わない。また、端末に備え付けのものでもよいし、取り外せるものでもよい。

認証判定モジュール３１は、ユーザが予め認証モジュールに登録しておいた、Credentialを用いて、ユーザの認証の際に、ユーザから提示された情報が、Credential 情報と照合し良否を判定する。以降では、ＰＩＮコードや生体情報等の、ユーザを認証するための情報をCredentialと呼ぶ。ユーザから提示された情報が、Credential 情報と照合して良であれば、秘密鍵・公開鍵を生成許可（ＷＥＢサービス１０への登録時）か、秘密鍵の利用許可（ＷＥＢサービス１０への認証時）を与える。
鍵処理保管領域３３は、鍵の生成や署名、暗号化、復号といった鍵の関する処理と、鍵の処理に必要な鍵自体を保存する機能を有する。

ここで、鍵の種別について説明する。
鍵は、ＷＥＢサービス向け公開鍵・秘密鍵と、メタデータサービス向け公開鍵・秘密鍵との２種類がある。
ＷＥＢサービス向け公開鍵・秘密鍵は、ＷＥＢサービス毎、アカウント毎に異なる鍵が生成される。
また、メタデータサービス向け公開鍵・秘密鍵は、認証モジュールのモデルごとに発行される。ＷＥＢサービス１０は、ＦＩＤＯの認証モジュールとして認証を得たタイミングで、メタデータサービス向け秘密鍵・公開鍵を生成する。メタデータサービス向け秘密鍵３４は、認証モジュール３０の鍵処理保管領域３３に埋め込んで出荷される。

ＦＩＤＯ認証の特徴は、下記の通りである。
ＷＥＢサービス１０毎に求めるユーザの認証レベルが異なるため、多様な認証レベルに対応する必要があり、ＷＥＢサービス１０側で認証方式（ＰＩＮ、指紋、虹彩等のユーザを識別する方式）等を設定できるようになっている。
ユーザは、ＷＥＢサービス１０側で指定された認証ポリシーを満たす、認証判定モジュールを搭載した認証判定モジュール３１を利用する必要がある。ＷＥＢサービス１０側は、どのモデルの認証モジュールが利用されたか、メタデータサービス１を利用して検証できるようになっている。

<ＦＩＤＯAllianceの利用手順>
図２７は、ＦＩＤＯAllianceの利用手順を説明する図である。
（手順１）事前登録
図２７に示すように、認証モジュール３０にＰＩＮコードや生体情報を登録する。

（手順２）ＷＥＢサービスでのアカウント生成
図２７に示すように、アカウント入力フォームに情報を入力し、ＷＥＢサービス１０側で本人確認を行う。ＩＤとパスワードを設定する。

（手順３）ＷＥＢサービスのＦＩＤＯ方式への認証方法の切替
図２７に示すように、パスワードによりＷＥＢサービス１０にログインし、ＦＩＤＯ方式の認証に切替処理を実行する。ＷＥＢサービス１０に登録する際、認証モジュール３０でユーザの認証を行う。問題がなければ、認証モジュール３０内で公開鍵・秘密鍵のペアを生成し、公開鍵側をＷＥＢサービス１０へ送付する。公開鍵は、メタデータサービス向けの秘密鍵３４で署名して送付する。ＷＥＢサービス１０側で、メタデータを参照し、メタデータサービス１にある公開鍵２で検証する。

（手順４）ＦＩＤＯ方式での認証
図２７に示すように、ＷＥＢサービス１０側から認証要求があるため、認証モジュール３０でユーザの認証を実行する。問題がなければ、鍵処理保管領域３３の秘密鍵３２，３４へのアクセス許可を与え、秘密鍵３２，３４で署名を行い、ＷＥＢサービス１０側へ返す。ＷＥＢサービス１０側では、アカウントに紐付けてある、公開鍵で署名が検証できれば、認証ＯＫと判定する。

<公開鍵を用いた認証（ＦＩＤＯ）の問題点>
公開鍵を用いた認証（ＦＩＤＯ）の問題点は、下記（１），（２）である。
（問題点１）
認証デバイスに鍵を閉じ込めているため、認証デバイスを紛失すると秘密鍵も失う。ＦＩＤＯでは、鍵の新規登録については規定されているが、鍵の紛失時の対応策については標準化技術では規定されていない。

（問題点２）
鍵を紛失しても、ユーザがこれまで利用していたアカウントを継続利用したいという要望に応えられない。ユーザは、利用していたすべてＷＥＢサービスに対し、新たな鍵ペアを生成し、再度登録する必要があり、手間がかかる。

図２８は、公開鍵を用いた認証（ＦＩＤＯ）の問題点を説明する図である。
図２８（ａ）に示すように、メタデータサービス向けの鍵ペアは、認証モジュールのモデルごとに異なる鍵である。
図２８白抜き矢印に示すように、認証モジュール３０を紛失し、新たな認証モジュールを利用する場合（「アクセス許可」を求める場合）を想定する。新たな認証モジュール３０Ａは、以前利用していた認証モジュール３０とは異なるモデルのものを利用する場合であるとする。
図２８（ｂ）に示すように、新たな認証デバイスを用意しても、ＷＥＢサービス１０と対をなす、秘密鍵が無いため、サービスを利用できない。

<図２８の問題点の解決の方向性>
図２９は、図２８の問題点の解決の方向性を説明する図である。
図２９に示すように、ＷＥＢサービス１０と対応付けられているＷＥＢサービス向けの秘密鍵を、インターネット上のサーバ（以降では、認証鍵リレー型キーストア４０と呼ぶ）に保管する。この秘密鍵と認証モジュール３０の関係を認証鍵リレー型キーストア４０で保持する。
端末紛失時は、新たな端末を認証鍵リレー型キーストア４０に登録し、ＷＥＢサービス向け秘密鍵３２と関連付ける。

<図２９の課題>
図３０は、図２９の課題を説明する図である。
図３０（ａ）に示すように、ＷＥＢサービス１０は、さらに認証ポリシー１７を有する。認証モジュール３０は、ＷＥＢサービス１０が提示する認証ポリシー１７に従った認証を行う。
新たな認証モジュール３０Ａを利用する場合、図３０（ｂ）に示すように、ＷＥＢサービス１０は、新たな認証モジュール３０ＡがＷＥＢサービス１０の認証ポリシー１７に合致するかを判定する必要がある。このためには、新たな認証モジュール３０ＡがＷＥＢサービス１０の認証ポリシー１７に合致するかをＷＥＢサービス１０に再度、問い合わせる必要がある。

このように、認証モジュール３０を、以前利用していた認証モジュール３０と異なるモデルの認証モジュール３０Ａに交換すると、ＷＥＢサービス１０側に再度、利用可能な認証モジュールかどうか問い合わせる必要がある。ＦＩＤＯ ＵＡＦでは、ＷＥＢサービス１０側が利用可能な認証モジュールを決める方式を採るためである。ユーザはＷＥＢサービス１０に対し、認証モジュールの再登録を行う必要あり、ユーザの手間がかかる。また、ＷＥＢサービス１０側もユーザの本人確認を行う必要があるため、運用負担が増加する。
また、新たな認証モジュール３０Ａを利用したい場合、ＷＥＢサービス１０に対し、認証モジュール３０Ａの追加の手続きを行う必要があり、ユーザの手間がかかる。

（実施形態）
図１は、本発明の実施形態に係る電子鍵再登録システムを示す構成図である。本実施形態は、公開鍵暗号方式における、秘密鍵紛失時の復旧技術、例えば、鍵による認証方法を提供するＷＥＢサービス向けのオンラインによる鍵の復旧技術に適用した例である。
［構成］
図１に示す、電子鍵再登録システム１００は、ＷＥＢサービス１１０と、端末１２０と、認証モジュール１３０（認証デバイス）と、認証鍵リレー型キーストア１４０（キーストア）と、メタデータサービス１５０と、ネットワーク認証サーバ１６０と、を備える。

<ＷＥＢサービス>
ＷＥＢサービス１１０は、アカウント１１１と、ＷＥＢサービス向け公開鍵１１２と、認証方式や認証の強度の認証ポリシー１１３と、を保管する。ＷＥＢサービス１１０は、認証ポリシー１１３に従って、利用可能な認証モジュール１３０を決定するとともに、認証モジュール１３０で生成された公開鍵（ＷＥＢサービス向け公開鍵１１２）を管理する。
認証ポリシー１１３は、ＷＥＢサービス１１０に認証モジュール１３０を登録する際に提示された認証ポリシーである。後記するように、ＷＥＢサービス１１０の認証ポリシー１１３は、認証鍵リレー型キーストア１４０にも保管される。

<端末>
端末１２０は、スマートホン，携帯電話，タブレット等の携帯端末、ノート型／デスクトップ型ＰＣ、各種電子機器である。本実施形態では、スマートホンを例に採る。端末１２０は、ネットワーク（以下、適宜ＮＷという。）認証アプリケーション（以下、適宜認証アプリという。）１２１と、スマホ用秘密鍵１２２を格納するＮＷ認証アプリ限定領域１２３と、を備える。ＮＷ認証アプリ限定領域１２３には、スマホ用秘密鍵１２２（後記）が保管される。

<認証モジュール>
認証モジュール１３０（モデルＡ）は、認証判定モジュール１３１と、生成したメタデータサービス向け秘密鍵１３２（モデルＡ）を閉じ込めて保管するとともに、認証モジュール関連付け情報１３３（モデルＡ）を保管する鍵処理保管領域１３４と、を有する。
なお、本明細書において、（モデルＡ）は、端末１２０の紛失、変更または追加を契機として、認証モジュール１３０を登録するあるいは追加する場合に、(旧)認証モジュール１３０の各部品であることを明示するために便宜的に付したものである。また、後記（モデルＢ）は、新たに認証モジュール１３０を登録または追加する場合に、(新)認証モジュール１３０の各部品であることを区別するためのものである。

<認証鍵リレー型キーストア>
認証鍵リレー型キーストア１４０は、ＷＥＢサービスのＵＲＬ（Uniform Resource Locator）１４１と、認証ポリシー１１３と、ＷＥＢサービス向け秘密鍵１４２と、(旧)認証モジュール関連付け情報１３３（モデルＡ）と、をネットワーク上で保持する。
認証鍵リレー型キーストア１４０は、ＷＥＢサービス１１０に認証モジュール１３０を登録する際に提示された認証ポリシー１１３（ＷＥＢサービス１１０に保管されている認証ポリシー１１３と同一）を保管している。すなわち、認証鍵リレー型キーストア１４０と認証モジュール１３０（モデルＡ）とは、公開鍵秘密鍵等の認証モジュール関連付け情報１３３（モデルＡ）を持ち合う。

認証鍵リレー型キーストア１４０は、ＷＥＢサービス１１０に認証モジュール１３０を登録する際に提示された認証ポリシー１１３を保管し、認証モジュール１３０の紛失、変更または追加時に、変更または追加される認証モジュール１３０の認証モジュール関連付け情報１３３を取得し、取得した認証モジュール関連付け情報１３３を基に、メタデータサービス１５０の認証レベル情報２０２（図２）を参照し、参照した認証レベル情報２０２の認証レベルと保管している認証モジュール１３０の認証ポリシー１１３とに基づいて、変更または追加される認証モジュール１３０の認証モジュール関連付け情報１３３と保持している秘密鍵とを関連付けるまたは関連付け不可を決定する。

認証鍵リレー型キーストア１４０は、認証モジュール１３０の紛失、変更または追加時に、メタデータサービス１５０から参照した認証レベル情報２０２（図２）の認証レベルが、保管している認証モジュール１３０の認証ポリシー１１３の認証レベル以上の場合に、変更または追加される認証モジュール１３０の認証モジュール関連付け情報１３３と保持している秘密鍵とを関連付ける（後記動作例Ｅ，Ｆ参照）。

認証鍵リレー型キーストア１４０は、端末１２０をネットワーク認証サーバ１６０へリダイレクトさせて、端末１２０とネットワーク認証サーバ１６０間で利用者認証を実行させ、ネットワーク認証サーバ１６０から受け取った認証結果アサーションが良であるならば、端末１２０にアクセス許可する（後記動作例Ｂ参照）。

認証鍵リレー型キーストア１４０は、利用者認証実行後、利用者ＩＤ１８１（図１２）を生成し、ネットワーク認証サーバ１６０は、認証鍵リレー型キーストア１４０との認証結果アサーションが良であるならば、認証鍵リレー型キーストア１４０との間で利用ＩＤを共有し、認証鍵リレー型キーストア１４０は、利用者ＩＤ１８１を保存するとともに、端末１２０に利用者ＩＤ１８１の登録完了を通知する（後記動作例Ｃ参照）。

認証鍵リレー型キーストア１４０は、認証鍵リレー型キーストア１４０は、端末１２０から利用者ＩＤ１８１（図１３）の確認要求を受け付けたならば、ネットワーク認証サーバ１６０に利用者ＩＤ１８１を要求し、ネットワーク認証サーバ１６０は、認証鍵リレー型キーストア１４０との認証結果アサーションが良であるならば、認証鍵リレー型キーストア１４０に利用ＩＤを送信する（後記動作例Ｄ参照）。

<メタデータサービス>
メタデータサービス１５０は、ＷＥＢサービス１１０との間で鍵（メタデータサービス向け公開鍵・秘密鍵）を利用して認証モジュール１３０の情報を保管する。
メタデータサービス１５０は、認証モジュールの認証方式等の情報を格納するメタデータ２００（図２）と、（モデルＡ）メタデータサービス向け公開鍵１５１と、（モデルＡ）認証モジュールの情報１５２と、（モデルＢ）メタデータサービス向け公開鍵１５３と、（モデルＢ）認証モジュールの情報１５４と、を有する。
メタデータサービス１５０は、メタデータ２００（図２）として認証方式を認証の強度毎にグループ分けした認証レベル情報２０２（図２）と、秘密鍵の保管領域２０７（図２）と、を有し、ＷＥＢサービス１１０からの要求に応じて、秘密鍵の保管領域２０７を参照させる。

<ネットワーク認証サーバ>
ネットワーク認証サーバ１６０は、ＬＴＥ（Long Term Evolution）網や３Ｇ（3rd Generation）網と連携したネットワーク上の認証サーバである。
ネットワーク認証サーバ１６０は、スマホ用公開鍵１６１を保管（格納）する耐タンパー領域１６２と、ユーザ管理データベース（ＤＢ）１６３と、サーバ証明書１６４と、を備える。スマホ用公開鍵１６１は、非正規な手段による機密データの読み取りを防ぐ能力を有する耐タンパー領域１６２に格納される。サーバ証明書１６４とは、ＷＥＢサイト所有者の情報・送信情報の暗号化に必要な鍵・証明書発行者の署名データを持った電子証明書である。ユーザ管理ＤＢ１６３には、ＩＭＳＩ（International Mobile Subscriber Identity、電話番号など）、ＰＩＮ（Personal Identification Number）コード、ＫＳ（Key Store）用秘密鍵、ＫＳ用共通鍵、スマホ用公開鍵、およびＫＳ利用者ＩＤが保管（格納）される。

［データの保持形式］
次に、データの保持形式について説明する。
<メタデータサービスの認証モジュールの認証方式等の情報>
図２は、メタデータサービス１５０のメタデータ２００を表にして示す図である。
図２に示すように、メタデータサービス１５０のメタデータ２００は、認証モジュールモデルＩＤ２０１毎に、認証レベル情報２０２、認証方式２０３、メタデータサービス向け公開鍵２０４、認証モジュールの実装形態２０５、鍵処理保管領域の実装形態２０６、秘密鍵の保管領域２０７、および認証精度情報２０８を有する。本実施形態では、メタデータが図２の太枠で囲んだ認証レベル情報２０２および秘密鍵の保管領域２０７を持つことを特徴とする。認証レベル情報２０２および秘密鍵の保管領域２０７は、従来のメタデータにはなかった情報である。

認証モジュールモデルＩＤ２０１は、例えば1111#aaaa，0000#dddd，…など９桁の英数文字列である。
認証レベル情報２０２は、認証のセキュリティレベル(強度)であり、Lv１，Lv２，…などの数値が大きいと認証レベルが高い。なお、この認証レベル情報２０２は、メタデータサービス１５０を運用する機関が格付けを行う。
認証レベル情報２０２の各レベルに対応する認証方式２０３が決められている。認証レベル情報２０２のレベルが同一であっても認証方式が異なる場合もある。換言すれば、異なる認証方式が認証レベル情報２０２の同一のレベルに属することもある。また、後記するように、同一の認証方式であっても、認証モジュールの実装形態２０５および鍵処理保管領域の実装形態２０６のハードウェア実装またはソフトウェア実装のいずれであるかにより認証レベル情報２０２が異なる場合がある。
図２に示すように、例えば認証レベルLv１は、ボタンの押下、ＵＳＢによる接続である。認証レベルLv２は、ＰＩＮ入力、指紋認証である。認証レベルLv３にも指紋認証がある。認証レベルLv４は、虹彩認証、高精度指紋認証、である。

認証モジュールの実装形態２０５および鍵処理保管領域の実装形態２０６は、ハードウェアまたはソフトウェアにより実装される。ハードウェア実装は、ソフトウェア実装よりもセキュリティレベルが高い。例えば、認証モジュールモデルＩＤ２０１の6666#uuuuと3333#ababと5555#ccccに、認証方式が同じ「指紋認証」が存在するが、認証モジュールの実装形態２０５および鍵処理保管領域の実装形態２０６がいずれも「ソフトウェア」の場合は、認証レベル情報２０２が認証レベルLv２である。また、認証モジュールの実装形態２０５が「ハードウェア」、鍵処理保管領域の実装形態２０６が「ソフトウェア」の場合は、認証レベル情報２０２は認証レベルLv３である。認証モジュールの実装形態２０５および鍵処理保管領域の実装形態２０６がいずれも「ハードウェア」の場合は、認証レベル情報２０２が認証レベルLv４であり、認証方式は「高精度指紋認証」となる。

秘密鍵の保管領域２０７は、Lv１−Lv３は、認証モジュール１３０内であり、Lv４は、認証鍵リレー型キーストア１４０である。なお、図２の情報に、さらに認証鍵リレー型キーストア１４０を利用していることを示す情報を付加してもよい。このようにすれば、これにより、ＷＥＢサービスの認証に対する多様な要望に応じることができる。

認証精度情報２０８は、Lv２のＰＩＮ入力は、５桁の数字である。また、指紋認証、虹彩認証など生体認証システムの精度は、ＦＲＲ（False Rejection：本人拒否率）とＦＡＲ（False Acceptance：他人受入率）の組合せで評価される。

このように、メタデータサービス１５０は、認証モジュール１３０（図１）を認証レベル情報２０２でカテゴリー分けしたメタデータ２００を持っている。ＷＥＢサービス事業者は、自身のサービスに合わせた認証ポリシーを、認証レベルを指定することで設定することができる。ここで、同じ認証レベルであれば、どの認証モジュール１３０（図１）で認証を行ってもよい。ちなみに、従来のＦＩＤＯでは、ＷＥＢサービス側が認証モジュールＩＤや認証方式、認証モジュールの実装形態等を指定することで、ＷＥＢサービス側が要求する認証ポリシーを指定していた。

従来は、認証方式等を細かく指定しなければならず、認証モジュール間の認証レベルの互換性がないため、ＷＥＢサービス側にＷＥＢサービスが要求する認証レベルに合致するか、確認する必要がある。これに対して、本実施形態では、同じ認証レベルであれば、どの認証モジュール１３０で認証を行ってもよいため、認証モジュール１３０を追加・変更した際に、認証レベル情報２０２が同じ認証モジュールであれば、ＷＥＢサービス１１０側に認証レベルを確認する必要がない。ただし、メタデータサービス１５０がメタデータ２００の認証レベル情報２０２および秘密鍵の保管領域２０７を持つことに加えて、認証鍵リレー型キーストア１４０が、ＷＥＢサービス１１０に認証モジュール１３０を登録する際に提示された認証ポリシー１１３（ＷＥＢサービス１１０に保管されている認証ポリシー１１３と同一）を保管していること、および認証鍵リレー型キーストア１４０が、認証モジュールの追加・変更の際に、メタデータサービス１５０のメタデータ２００を参照して、保管している認証ポリシー１１３とメタデータ２００の認証レベル情報２０２を基に新認証モジュールを登録するシーケンスおよび処理を実行すること、が必要である（後記）。

［利用者認証用保持データ］
次に、利用者認証用保持データについて説明する。
<ユーザと通信キャリアとの契約後>
図３は、ユーザと通信キャリアとの契約後の利用者認証用保持データを表にして示す図である。
図３に示すように、ユーザと通信キャリアと、さらにネットワーク認証サーバ１６０は、共通のＩＭＳＩ（International Mobile Subscriber Identity：国際的な加入者識別番号）を有する。スマートホン（端末１２０）は、契約者共通鍵を有し、ＬＴＥ／３Ｇ網側は、契約者共通鍵、契約者情報およびＰＩＮコードを有する。また、ネットワーク認証サーバ１６０は、この段階ではＩＭＳＩとＰＩＮコードのみを有する。

<信頼関係確立後>
図４は、認証鍵リレー型キーストア１４０とネットワーク認証サーバ１６０間で信頼関係確立後の利用者認証用保持データを表にして示す図である。
図４に示すように、認証鍵リレー型キーストア１４０とネットワーク認証サーバ１６０間で信頼関係確立後には、ネットワーク認証サーバ１６０は、ＩＭＳＩと、ＰＩＮコードと、ＫＳ用秘密鍵と、ＫＳ用共通鍵と、を有する。また、認証鍵リレー型キーストア１４０は、ネットワーク認証サーバ１６０のＫＳ用秘密鍵に対応するＫＳ用公開鍵と、ＫＳ用共通鍵と、を有する。
このように、認証鍵リレー型キーストア１４０毎にネットワーク認証サーバ１６０と異なる鍵を共有し、鍵を共有することにより両サーバ間で信頼関係を構築する。
ＮＷ認証用共通鍵は、必要に応じて毎回生成し、公開鍵、秘密鍵で暗号化し、共有し合うことが好ましい。ただし、公開鍵、秘密鍵は、同時に生成し、以降は定期的に鍵を更新することでもよい。
以降の例では、既にＮＷ共通鍵を持ち合った状態であるとして記載する。

<利用者認証の事前設定後>
図５は、契約が完了し、認証鍵リレー型キーストア１４０とネットワーク認証サーバ１６０間で信頼関係が確立し利用者認証の事前設定後の利用者認証用保持データを表にして示す図である。
図５に示すように、利用者認証の事前設定後には、スマートホン（端末１２０）は、ＩＭＳＩ、契約者共通鍵、およびスマホ用秘密鍵を有し、ＬＴＥ／３Ｇ網側は、ＩＭＳＩ、契約者共通鍵、契約者情報およびＰＩＮコードを有する。
ネットワーク認証サーバ１６０は、ＩＭＳＩと、ＰＩＮコードと、ＫＳ用秘密鍵と、ＫＳ用共通鍵と、スマホ用公開鍵と、を有する。また、認証鍵リレー型キーストア１４０は、ネットワーク認証サーバ１６０のＫＳ用秘密鍵に対応するＫＳ用公開鍵と、ＫＳ用共通鍵と、を有する。

<利用者ＩＤを登録した場合>
図６は、契約が完了し、認証鍵リレー型キーストア１４０とネットワーク認証サーバ１６０間で信頼関係が確立し利用者認証の事前設定後さらに、利用者ＩＤを登録した場合の利用者認証用保持データを表にして示す図である。
図６に示すように、利用者認証の事前設定後さらに、利用者ＩＤを登録した場合、スマートホン（端末１２０）は、ＩＭＳＩ、契約者共通鍵、およびスマホ用秘密鍵を有し、ＬＴＥ／３Ｇ網側は、ＩＭＳＩ、契約者共通鍵、契約者情報およびＰＩＮコードを有する。
ネットワーク認証サーバ１６０は、ＩＭＳＩと、ＰＩＮコードと、ＫＳ用秘密鍵と、ＫＳ用共通鍵と、スマホ用公開鍵と、利用者ＩＤと認証鍵リレー型キーストアのＵＲＬと、を有する。また、認証鍵リレー型キーストア１４０は、ネットワーク認証サーバ１６０のＫＳ用秘密鍵に対応するＫＳ用公開鍵と、ＫＳ用共通鍵と、利用者ＩＤと、を有する。

［認証鍵リレー型キーストア側の保持情報］
次に、認証鍵リレー型キーストア１４０側の保持情報について説明する。
図７は、認証鍵リレー型キーストア１４０側の保持情報のデータ構造（木構造）を示す図である。図７のデータ構造の説明において、「ｘｘのＩＤ」と「ｙｙのＩＤ」とが線で結ばれる場合、当該線に付された「１…１」は、１つのｘｘのＩＤには１つｙｙのＩＤが対応していることを示す。また、「ｘｘのＩＤ」と「ｙｙのＩＤ」とが線で結ばれる場合、当該線に付された「１…ｎ（ｎは２以上の整数）」は、１つのｘｘのＩＤには複数のｙｙのＩＤが対応していることを示す。１対ｎ対応となっているのは、１つの認証モジュールを複数のＷＥＢサービスの認証に利用できることを意味する。ＷＥＢサービス認証用の鍵ペアは、ＷＥＢサービス毎かつアカウント毎に異なる鍵を用いる。

図７に示すように、認証鍵リレー型キーストア１４０側の保持情報は、「認証鍵リレー型キーストアのユーザＩＤ」を最上位とし、「認証鍵リレー型キーストアのユーザＩＤ」の下位に「認証モジュールモデルＩＤ」がある。「認証モジュールモデルＩＤ」は、「１…１」で「認証レベル」に対応するとともに、「１…ｎ」で「ＷＥＢサービス認証用秘密鍵のＩＤ」に対応する。
「ＷＥＢサービス認証用秘密鍵のＩＤ」は、「１…１」で「ＷＥＢサービス認証用秘密鍵」に対応するとともに、「１…１」で「ＷＥＢサービスのユーザＩＤ」に対応する。
「ＷＥＢサービスのユーザＩＤ」は、「１…１」で「ＷＥＢサービスのアプリケーションＩＤ」に対応する。
「ＷＥＢサービスのアプリケーションＩＤ」は、「１…１」で「ＷＥＢサービスの認証ポリシー」に対応する。

［動作］
以下、上述のように構成された電子鍵再登録システム１００の動作について説明する。
動作の前提として、ユーザは２つのＷＥＢサービス（甲サービス、乙サービス）を利用しており、既に、どちらのＷＥＢサービスにも認証モジュール(旧)を登録済みであるとする。また、新たに用意する新認証モジュールは、既に利用していた旧認証モジュールと異なるモデルであるとする。
動作例Ａ〜動作例Ｆの概要は、下記の通りである。
動作例Ａ（図８および図９）は、「利用者認証事前登録」であり、スマートホン等の端末１２０とネットワーク認証サーバ１６０との間で鍵を持ち合う。
動作例Ｂ（図１０および図１１）は、「利用者認証」であり、端末１２０とネットワーク認証サーバ１６０との間で鍵を利用して、認証鍵リレー型キーストア１４０にログインする。
動作例Ｃ（図１２）は、「利用者ＩＤの登録」であり、認証鍵リレー型キーストア１４０で利用者ＩＤを生成し、ネットワーク認証サーバ１６０と共有する。
動作例Ｄ（図１３）は、「利用者ＩＤの確認」であり、認証鍵リレー型キーストアの利用者ＩＤをネットワーク認証サーバに問い合わせ確認する。
動作例Ｅ（図１４ないし図１７）は、「端末の更新」であり、端末１２０の更新による、認証モジュール１３０の変更を行う。
動作例Ｆ（図１８ないし図２１）は、「端末の追加」であり、端末１２０の追加等による、認証モジュール１３０の追加を行う。

［利用者認証事前登録］（動作例Ａ）
図８および図９は、利用者認証事前登録を説明するシーケンスである。図８および図９において、ネットワーク認証サーバ１６０は、ＬＴＥ／３Ｇ網側インタフェース２を介してＬＴＥ／３Ｇ網１に接続され、またインターネット側インタフェース３を介してインターネット４に接続されている。
図８に示すように、端末１２０は、ＩＭＳＩ（電話番号など）、および契約者共通鍵を保管する。ＬＴＥ／３Ｇ網２上のサーバ（事業者サーバを含む）（図示省略）には、ＩＭＳＩ、契約者共通鍵、および契約者情報が保管される。ネットワーク認証サーバ１６０は、ＩＭＳＩ、ＰＩＮコード、ＫＳ用秘密鍵、およびＫＳ用共通鍵を保管する。インターネット４上のサーバ（クラウドサーバを含む）（図示省略）には、認証鍵リレー型キーストア１４０が設置される。認証鍵リレー型キーストア１４０は、ＫＳ用秘密鍵、およびＫＳ用共通鍵を保管する。

ここで、秘密鍵・公開鍵、ＮＷ認証用共通鍵は、事前にネットワーク認証サーバ１６０側と認証鍵リレー型キーストア１４０側で持ち合っておく。なお、ＩＭＳＩ、契約者共通鍵、契約者情報、およびＰＩＮコードは、通信キャリアとの契約時に対面による本人確認を行ったのち、設定する（以降、本人確認等は店舗で行う）。

端末１２０は、ＬＴＥ／３Ｇ網１上のサーバ（以下、ＬＴＥ／３Ｇ網１という）にＬＴＥ／３Ｇ網接続要求を送信する（図８のステップＳ１０１：以下図８参照）。
ＬＴＥ／３Ｇ網１は、ＬＴＥ／３Ｇ網接続要求を受けて、端末１２０との間で契約者共有鍵を用いた認証を行う（ステップＳ１０２）。
ＬＴＥ／３Ｇ網１は、ＩＰアドレス払い出し（ステップＳ１０３）、ネットワーク認証サーバ１６０にＩＭＳＩ、ＩＰアドレスを送付する（ステップＳ１０４）。

ネットワーク認証サーバ１６０は、ＩＭＳＩ、ＩＰアドレス送付を受けて、ＩＭＳＩにＩＰアドレスを関連付けて保存するとともに（ステップＳ１０５）、ＩＰアドレスを関連付けたＩＭＳＩを端末１２０に送信する（ステップＳ１０６のＯＫ）。

以降のシーケンスは、店舗で実行される。
端末１２０は、ＬＴＥ／３Ｇ網側からのアクセスにより、ネットワーク認証サーバ１６０に接続する（ステップＳ１０７）。
ネットワーク認証サーバ１６０は、端末１２０にＰＩＮ認証要求を送信する（ステップＳ１０８）。
端末１２０は、ＰＩＮ認証要求を受けて、ＮＷ認証アプリを起動する（ステップＳ１０９）。ＮＷ認証アプリ起動により、ＰＩＮ入力が可能になる。端末１２０は、ＰＩＮ入力結果をネットワーク認証サーバ１６０に送信する（ステップＳ１１０）。

ネットワーク認証サーバ１６０は、ＩＭＳＩにＩＰアドレスと発信元のＩＰアドレスおよび、ＰＩＮが一致することを確認する（ステップＳ１１１）。ＩＭＳＩにＩＰアドレスと発信元のＩＰアドレスおよび、ＰＩＮが一致することを確認すると、このＰＩＮ確認情報を端末１２０に送信する（ステップＳ１１２）。
端末１２０は、ＰＩＮ確認要求を受けて、ネットワーク認証サーバ１６０に利用者登録要求を送信する（ステップＳ１１３）。

ネットワーク認証サーバ１６０は、既に、該当ユーザのＩＭＳＩにスマホ用公開鍵が関連付けられていないことを確認する（図９のステップＳ１１４：以下図９参照）。
すなわち、いったんスマホ用鍵ペアを共有すると、ユーザの操作のみで変更できないようにするために、スマホ用公開鍵がすでにＩＭＳＩに関連付けられている場合、ネットワーク認証サーバのオペレータ操作により削除を行う。これにより、店舗で確認した利用者が実際に生体認証を行いながら、登録するところを確認することで、生体認証と実際に利用している利用者を関連付けることができる。
ネットワーク認証サーバ１６０は、既に、該当ユーザのＩＭＳＩにスマホ用公開鍵が関連付けられていないことを確認すると、端末１２０に本人認証要求を送信する（ステップＳ１１５）。

端末１２０は、本人認証要求を受けて、生体認証を実行し（ステップＳ１１６）、生体認証の確認が取れた場合、生体認証が取れた旨の肯定的応答をネットワーク認証サーバ１６０に返す（ステップＳ１１７）。
端末１２０は、ネットワーク認証サーバ１６０との間でＥＣＤＨＥ-ＥＣＤＳＡによる一時的な共通鍵を生成する（ステップＳ１１８）。
端末１２０は、公開鍵・秘密鍵を生成し（ステップＳ１１９）、公開鍵を一時的な共通鍵で暗号化する（ステップＳ１２０）。
端末１２０は、暗号化された公開鍵をネットワーク認証サーバ１６０に送付する（ステップＳ１２１）。

ネットワーク認証サーバ１６０は、スマホ用公開鍵を受け取り、スマホ用公開鍵を基に一時的な共通鍵で復号する（ステップＳ１２２）。そして、ネットワーク認証サーバ１６０は、一時的な共通鍵を破棄し（ステップＳ１２３）、ＩＭＳＩに関連付けて、スマホ用公開鍵を保存する（ステップＳ１２４）。
ネットワーク認証サーバ１６０は、端末１２０に利用者認証登録完了を送信して（ステップＳ１２５）、ネットワーク認証サーバ１６０側での利用者認証事前登録を完了する。
一方、端末１２０は、上記ステップＳ１２１で暗号化された公開鍵の送付後、一時的な共通鍵破棄する（ステップＳ１２６）。
以上で、利用者認証事前登録が完了する。

［利用者認証］（動作例Ｂ）
図１０および図１１は、利用者認証を説明するシーケンスである。図１０および図１１において、ネットワーク認証サーバ１６０は、ＬＴＥ／３Ｇ網側インタフェース２を介してＬＴＥ／３Ｇ網１に接続され、またインターネット側インタフェース３を介してインターネット４に接続されている。
図１０に示すように、端末１２０は、ＩＭＳＩ、契約者共通鍵、およびスマートホン用秘密鍵を保管する。ＬＴＥ／３Ｇ網２上のサーバ（事業者サーバを含む）（図示省略）には、ＩＭＳＩ、契約者共通鍵、および契約者情報が保管される。ネットワーク認証サーバ１６０は、ＩＭＳＩ、ＰＩＮコード、ＫＳ用秘密鍵、ＫＳ用共通鍵、およびスマートホン用公開鍵を保管する。インターネット４上のサーバ（クラウドサーバを含む）（図示省略）には、認証鍵リレー型キーストア１４０が設置される。認証鍵リレー型キーストア１４０は、ＫＳ用公開鍵およびＫＳ用共通鍵を保管する。
ここで、秘密鍵・公開鍵、ＮＷ認証用共通鍵は、事前にネットワーク認証サーバ１６０側と認証鍵リレー型キーストア１４０側で持ち合っておく。

端末１２０は、ＬＴＥ／３Ｇ網１にＬＴＥ／３Ｇ網接続要求を送信する（図１０のステップＳ２０１：以下図１０参照）。
ＬＴＥ／３Ｇ網１は、ＬＴＥ／３Ｇ網接続要求を受けて、端末１２０との間で契約者共有鍵を用いた認証を行う（ステップＳ２０２）。
ＬＴＥ／３Ｇ網１は、ＩＰアドレス払い出し（ステップＳ２０３）、ネットワーク認証サーバ１６０にＩＭＳＩ、ＩＰアドレスを送付する（ステップＳ２０４）。

ネットワーク認証サーバ１６０は、ＩＭＳＩ、ＩＰアドレス送付を受けて、ＩＭＳＩにＩＰアドレスを関連付けて保存するとともに（ステップＳ２０５）、ＩＰアドレスを関連付けたＩＭＳＩを端末１２０に送信する（ステップＳ２０６のＯＫ）。

端末１２０は、認証鍵リレー型キーストア１４０にアクセスする（ステップＳ２０７）。
認証鍵リレー型キーストア１４０は、端末１２０に認証要求とネットワーク認証サーバ１６０へＬＴＥ／３Ｇ網側インタフェース２を指定してリダイレクトするように要求する（ステップＳ２０８）。
端末１２０は、認証鍵リレー型キーストア１４０からの認証要求およびリダイレクト要求を受けて、ネットワーク認証サーバ１６０にＬＴＥ／３Ｇ網側インタフェース２を指定してリダイレクトする（ステップＳ２０９）。

ネットワーク認証サーバ１６０は、接続元ＩＰアドレスから、ＩＭＳＩを特定し、既に、該当ユーザのＩＭＳＩにスマホ用公開鍵が関連付けられていることを確認する（ステップＳ２１０）。
ネットワーク認証サーバ１６０は、端末１２０に生体認証要求およびchallengeを送付する（ステップＳ２１１）。
端末１２０は、生体認証要求およびchallengeを受けて、生体認証を実行し、challengeからresponseを計算してネットワーク認証サーバ１６０に送信する（ステップＳ２１２）。

ネットワーク認証サーバ１６０は、challengeからresponseを計算し、受信したresponseと一致することを確認する（図１１のステップＳ２１３：以下図１１参照）。
ネットワーク認証サーバ１６０は、認証結果アサーション１７１を生成するとともに、共通鍵で暗号化し、秘密鍵で署名する（ステップＳ２１４）。
ネットワーク認証サーバ１６０は、端末１２０に認証鍵リレー型キーストア１４０へリダイレクトするように要求する（ステップＳ２１５）。
端末１２０は、ネットワーク認証サーバ１６０からのリダイレクト要求を受けて、認証鍵リレー型キーストア１４０にリダイレクトする（ステップＳ２１６）。

認証鍵リレー型キーストア１４０は、端末１２０からのリダイレクトを受けて、署名検証を行う（ステップＳ２１７）。認証鍵リレー型キーストア１４０は、署名がＯＫであれば、署名を付け替える（ステップＳ２１８）。この場合、公開鍵で署名する。
認証鍵リレー型キーストア１４０は、ネットワーク認証サーバ１６０にインターネット側インタフェース指定して認証結果アサーション１７１を照会する（ステップＳ２１９）。
ネットワーク認証サーバ１６０は、署名を検証し、復号を行い、認証結果アサーション１７１を検証する（ステップＳ２２０）。
ネットワーク認証サーバ１６０は、認証結果アサーション１７１の検証がＯＫの場合、認証鍵リレー型キーストア１４０にＯＫを送信する（ステップＳ２２１）。
認証鍵リレー型キーストア１４０は、端末１２０にアクセス許可、認証完了を送信して、利用者認証を完了する（ステップＳ２２２）。
以上で、利用者認証が完了する。

［利用者ＩＤの登録］（動作例Ｃ）
図１２は、利用者ＩＤの登録を説明するシーケンスである。図１２において、ネットワーク認証サーバ１６０は、ＬＴＥ／３Ｇ網側インタフェース２を介してＬＴＥ／３Ｇ網１に接続され、またインターネット側インタフェース３を介してインターネット４に接続されている。
図１２に示すように、端末１２０は、ＩＭＳＩ、契約者共通鍵、およびスマートホン用秘密鍵を保管する。ＬＴＥ／３Ｇ網２上のネットワーク認証サーバ１６０は、ＩＭＳＩ、ＰＩＮコード、ＫＳ用秘密鍵、ＫＳ用共通鍵、およびスマートホン用公開鍵を保管する。インターネット４上の認証鍵リレー型キーストア１４０は、ＫＳ用公開鍵およびＫＳ用共通鍵を保管する。

ここで、秘密鍵・公開鍵、ＮＷ認証用共通鍵は、事前にネットワーク認証サーバ１６０側と認証鍵リレー型キーストア１４０側で持ち合っておく。
端末１２０は、利用者ＩＤの登録の場合、認証鍵リレー型キーストア１４０にアクセスする（ステップＳ３０１）。
認証鍵リレー型キーストア１４０は、端末１２０との間で、[動作例Ｂ]の「利用者認証による認証」（図１０および図１１のシーケンス参照）を実行する（ステップＳ３０２）。
端末１２０は、認証鍵リレー型キーストア１４０に利用者ＩＤ生成を要求する（ステップＳ３０３）。

認証鍵リレー型キーストア１４０は、端末１２０からの利用者ＩＤ生成を受けて、利用者ＩＤを生成する（ステップＳ３０４）。
認証鍵リレー型キーストア１４０は、認証結果アサーション１７１と利用者ＩＤ１８１をＫＳ用共通鍵で暗号化し、ＫＳ用公開鍵で署名する（ステップＳ３０５）。
認証鍵リレー型キーストア１４０は、ネットワーク認証サーバ１６０にインターネット側インタフェース指定して認証結果アサーション１７１を照会する（ステップＳ３０６）。

ネットワーク認証サーバ１６０は、署名を検証し、復号を行い、認証結果アサーション１７１を検証する（ステップＳ３０７）。
ネットワーク認証サーバ１６０は、利用者ＩＤ１８１と認証鍵リレー型キーストア１４０のＵＲＬとＩＭＳＩを関連付けて保存する（ステップＳ３０８）。
ネットワーク認証サーバ１６０は、認証結果アサーション１７１の検証がＯＫの場合、認証鍵リレー型キーストア１４０にＯＫを送信する（ステップＳ３０９）。
認証鍵リレー型キーストア１４０は、利用者ＩＤ１８１を保存する（ステップＳ３１０）。
認証鍵リレー型キーストア１４０は、端末１２０に利用者ＩＤ登録完了を送信して（ステップＳ３１１）、利用者ＩＤの登録を完了する。
以上で、利用者ＩＤの登録が完了する。

［利用者ＩＤの確認］（動作例Ｄ）
図１３は、利用者ＩＤの確認を説明するシーケンスである。図１３において、ネットワーク認証サーバ１６０は、ＬＴＥ／３Ｇ網側インタフェース２を介してＬＴＥ／３Ｇ網１に接続され、またインターネット側インタフェース３を介してインターネット４に接続されている。
図１３に示すように、端末１２０は、ＩＭＳＩ、契約者共通鍵、およびスマートホン用秘密鍵を保管する。ＬＴＥ／３Ｇ網２上のネットワーク認証サーバ１６０は、ＩＭＳＩ、ＰＩＮコード、ＫＳ用秘密鍵、ＫＳ用共通鍵、およびスマートホン用公開鍵を保管する。インターネット４上の認証鍵リレー型キーストア１４０は、ＫＳ用公開鍵およびＫＳ用共通鍵を保管する。
ここで、秘密鍵・公開鍵、ＮＷ認証用共通鍵は、事前にネットワーク認証サーバ１６０側と認証鍵リレー型キーストア１４０側で持ち合っておく。

端末１２０は、利用者ＩＤの確認の場合、認証鍵リレー型キーストア１４０に対して利用者ＩＤの確認が必要となる操作を行う（ステップＳ４０１）。
認証鍵リレー型キーストア１４０は、端末１２０との間で、[動作例Ｂ]の「利用者認証による認証」（図１０および図１１のシーケンス参照）を実行する（ステップＳ４０２）。ただし、すでに、ネットワーク認証サーバから有効な認証結果アサーションがあれば省略可能である。
なお、本動作例Ｄは、利用者ＩＤの確認であるため、動作例Ｃ（図１２のステップＳ３０３の利用者ＩＤ要求およびステップＳ３０４の利用者ＩＤ生成）シーケンスはない。

認証鍵リレー型キーストア１４０は、認証結果アサーション１７１をＫＳ用共通鍵で暗号化し、ＫＳ用公開鍵で署名する（ステップＳ４０３）。
認証鍵リレー型キーストア１４０は、ネットワーク認証サーバ１６０に認証結果アサーション１７１により利用者ＩＤの要求を行う（ステップＳ４０４）。

ネットワーク認証サーバ１６０は、署名を検証し、復号を行い、認証結果アサーション１７１を検証する（ステップＳ４０５）。
ネットワーク認証サーバ１６０は、利用者ＩＤ１８１と認証鍵リレー型キーストア１４０のＵＲＬと対応する利用者ＩＤ１８１を検索し、利用者ＩＤ１８１をＫＳ用秘密鍵で暗号化する（ステップＳ４０６）。
ネットワーク認証サーバ１６０は、認証結果アサーション１７１の検証がＯＫの場合、認証鍵リレー型キーストア１４０にＯＫを送信する（ステップＳ４０７）。
認証鍵リレー型キーストア１４０は、利用者ＩＤ１８１をＫＳ用公開鍵で復号する（ステップＳ４０８）。
以上で、利用者ＩＤの確認が完了する。

［端末の更新］（動作例Ｅ）
図１４および図１５は、端末の更新を説明するシーケンスである。図１４および図１５は、端末の更新による、認証モジュールの変更を説明する。前提として、ユーザは２つのＷＥＢサービス（甲サービス、乙サービス）を利用しており、既に、どちらのＷＥＢサービスにも(旧)認証モジュール（モデルＡ）を登録済みである。新たに用意する(新)認証モジュール（モデルＢ）は、既に利用していた(旧)認証モジュールと異なるモデルであるとする。
図１４に示すように、(旧)認証モジュール１３０（モデルＡ）は、(旧)認証モジュール関連付け情報（モデルＡ）１３３を有する。

図１６は、認証鍵リレー型キーストア１４０、ＷＥＢサービス１１０(甲)、およびＷＥＢサービス１１０(乙)に保持される秘密鍵および認証ポリシーを示す図である。
図１６（ａ）に示すように、認証鍵リレー型キーストア１４０は、利用者ＩＤ１８１と、ＷＥＢサービス（甲サービス）の認証ポリシー１１３(甲)と、甲サービス向け秘密鍵１４２(甲)と、ＷＥＢサービス（乙サービス）の認証ポリシー１１３(乙)と、乙サービス向け秘密鍵１４２(乙)と、(旧)認証モジュール関連付け情報（モデルＡ）１３３(旧)と、を有する。このように、認証鍵リレー型キーストア１４０は、(旧)認証モジュール関連付け情報（モデルＡ）１３３(旧)に対し、ＷＥＢサービス向けの秘密鍵１４２とＷＥＢサービスから提示された認証ポリシー１１３を関連付けて保持する。

図１６（ｂ）に示すように、ＷＥＢサービス（甲サービス）１１０(甲)は、認証ポリシー１１３(甲)と、甲サービス向け秘密鍵１４２(甲)と、を有する。図１６（ｃ）に示すように、ＷＥＢサービス（乙サービス）１１０(乙)は、認証ポリシー１１３(乙)と、甲サービス向け秘密鍵１４２(乙)と、を有する。

図１４に示すように、メタデータサービス１５０は、メタデータ２００（図２）を有する。
図１４のシーケンスに示すように、(旧)認証モジュール１３０（モデルＡ）は、認証鍵リレー型キーストア１４０との間で、[動作例Ｃ]の「利用者ＩＤの登録」（図１２のシーケンス参照）を実行する（ステップＳ５０１）。

<紛失・変更>
図１４に示すように、スマートホン等の端末１２０を紛失・変更した場合、 (旧)認証モジュール１３０（モデルＡ）に代わって、(新)認証モジュール（モデルＢ）１３０(新)が下記シーケンスを実行する。
ここで、端末１２０にビルトインされている(新)認証モジュール（モデルＢ）１３０(新)を登録することを前提とする。ほかに認証鍵リレー型キーストア１４０に登録されている認証モジュール１３０がある場合は、後記[動作例Ｆ]の「端末の追加」シーケンスで対応可能である。また、スマートホン等の端末１２０を購入する際に、利用者認証事前登録を完了させていることとする。

(新)認証モジュール（モデルＢ）１３０(新)は、認証鍵リレー型キーストア１４０に利用者認証（詳細はスマートホン等の[動作例Ｂ]の「利用者認証」（図１０および図１２）参照）によるログインを行う（ステップＳ５０２）。
認証鍵リレー型キーストア１４０は、(新)認証モジュール（モデルＢ）１３０(新)との間で利用者ＩＤの確認（詳細は[動作例Ｄ]の「利用者ＩＤの登録」（図１２）参照）を実行する（ステップＳ５０３）。これにより、これまで認証鍵リレー型キーストア１４０を利用していたユーザかどうかを確認することが可能になる。オンラインにより対面で確認した本人確認レベルのユーザ登録が完了する。

(新)認証モジュール（モデルＢ）１３０(新)は、認証鍵リレー型キーストア１４０に(新)認証モジュール関連付け情報（モデルＢ）１３３(新)を送信して(新)認証モジュール（モデルＢ）１３０(新)の登録を実行する（ステップＳ５０４）。(新)認証モジュール（モデルＢ）１３０(新)の登録により、(新)認証モジュール（モデルＢ）１３０(新)と認証鍵リレー型キーストア１４０間で、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)を持ち合う。

<メタデータサービスのメタデータ参照>
認証鍵リレー型キーストア１４０は、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)を基に、メタデータサービス１５０のメタデータ２００（図２）を参照する（ステップＳ５０５）。
メタデータサービス１５０は、認証鍵リレー型キーストア１４０に、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)に基づくメタデータ２００（図２）を送信する（ステップＳ５０６）。

<更新処理>
認証鍵リレー型キーストア１４０は、認証ポリシー（甲サービス）１１３と(新)認証モジュール関連付け情報（モデルＢ）１３３(新)のメタデータ２００の認証レベル情報２０２とを比較する（ステップＳ５０７：以下図１５参照）。
特に、認証鍵リレー型キーストア１４０は、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が(旧)認証モジュール１３０（モデルＡ）の認証レベル情報２０２と同等かより高いかを判定する（ステップＳ５０８）。
(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が(旧)認証モジュール１３０（モデルＡ）の認証レベル情報２０２と同等かより高い場合（ステップＳ５０８のＹｅｓ）、(新)認証モジュール（モデルＢ）１３０(新)と甲サービス向け秘密鍵１４２(甲)を関連付ける関連付け実行リスト１９１のＷＥＢサービス（甲サービス）１１０(甲)を追加する（ステップＳ５０９）。

図１７は、(新)認証モジュール（モデルＢ）１３０(新)と甲サービス向け秘密鍵１４２(甲)の関連付け実行を説明する図である。
図１７（ａ）に示すように、認証鍵リレー型キーストア１４０は、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が(旧)認証モジュール１３０（モデルＡ）の認証レベル情報２０２と同等かより高い場合、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)と甲サービス向け秘密鍵１４２(甲)を関連付けて、関連付け実行リスト１９１（図１５）を作成する。この場合、関連付け実行リスト１９１には、関連付けＷＥＢサービス（甲サービス）１１０(甲)が追加される。この関連付け実行リスト１９１を基に、(旧)認証モジュール１３０（モデルＡ）を(新)認証モジュール（モデルＢ）１３０(新)に更新することが可能になる。

例えば、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が認証レベルLv２（図２）であり、(旧)認証モジュール１３０（モデルＡ）の認証レベル情報２０２がLv２（図２）である場合、認証レベル情報２０２は同じレベルであるので、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)と甲サービス向け秘密鍵１４２(甲)とは関連付け可能である。この場合、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)と甲サービス向け秘密鍵１４２(甲)とを関連付ける関連付け実行リスト１９１が作成される。本実施形態の特徴として、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が(旧)認証モジュール１３０（モデルＡ）の認証レベル情報２０２を見ているだけであって、両者の認証方式の一致は見ていない。

上記の例で、(新)認証モジュール（モデルＢ）１３０(新)の認証レベルLv２の認証方式が「ＰＩＮ入力」、(旧)認証モジュール１３０（モデルＡ）の認証レベルLv２の認証方式が「指紋認証」である場合、両者の認証方式は異なっているが認証レベルLv２は同じであるので関連付け実行リスト１９１が作成される。同様に、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が認証レベルLv２（図２）であり、(旧)認証モジュール１３０（モデルＡ）の認証レベル情報２０２がLv４（図２）である場合、認証レベルは一致していないが(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２はより高いので、関連付け実行リスト１９１が作成される。

従来のＦＩＤＯ ＵＡＦでは、認証モジュールを、以前利用していた認証モジュールと異なるモデルの認証モジュールに交換すると、ＷＥＢサービス側に再度、認証方式の一致も含めて、利用可能な認証モジュールかどうか問い合わせる必要がある。このため、ユーザの手間、ＷＥＢサービス側の運用負担が増加していた。これに対して、本実施形態では、認証鍵リレー型キーストア１４０は、メタデータサービス１５０のメタデータ２００（図２）を参照することで、認証レベルを比較する（すなわち認証方式の完全一致まで見ない）ので、ＷＥＢサービス側に再度、利用可能な認証モジュールかどうか問い合わせる回数（頻度）を大幅に減らすことができ、ユーザの手間およびＷＥＢサービス側の運用負担を低減することができる。

図１５のシーケンスに戻って、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が(旧)認証モジュール１３０（モデルＡ）の認証レベル情報２０２に達していない場合、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)と甲サービス向け秘密鍵１４２(甲)を関連付けない関連付け不可リスト１９２を作成する（ステップＳ５１０）。図１７（ｂ）に示すように、認証鍵リレー型キーストア１４０は、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が(旧)認証モジュール１３０（モデルＡ）の認証レベル情報２０２に達していない場合（ステップＳ５０８のＮｏ）、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)と甲サービス向け秘密鍵１４２(甲)とを関連付けせず、関連付け不可リスト１９２（図１５）を作成する。
上記ステップＳ５０７〜ステップＳ５１０の処理を、説明の便宜上「処理Ａ」という。
上記処理Ａを各ＷＥＢサービスの認証ポリシーで実行する。ＷＥＢサービスがｎ（ｎは自然数）ある場合には、上記処理Ａは各ＷＥＢサービスの認証ポリシーでｎ回実行される。

認証鍵リレー型キーストア１４０は、(新)認証モジュール（モデルＢ）１３０(新)に関連付け結果（関連付け実行リスト１９１または関連付け不可リスト１９２）を送付する（ステップＳ５１１）。(新)認証モジュール（モデルＢ）１３０(新)は、送付された関連付け結果に従って自身の関連付け実行リスト１９１または関連付け不可リスト１９２を更新する。
なお、関連付けができなかったＷＥＢサービスについては、ユーザ側で実行する必要がある。

［端末の追加］（動作例Ｆ）
図１８および図１９は、端末の追加を説明するシーケンスである。図１８および図１９は、端末の追加による、認証モジュールの変更を説明する。前提として、ユーザは２つのＷＥＢサービス（甲サービス、乙サービス）を利用しており、既に、どちらのＷＥＢサービスにも第１認証モジュール（モデルＡ）は登録済みである。新たに追加する第２認証モジュール（モデルＢ）は、既に利用していた第１認証モジュールと異なるモデルであるとする。
図１８に示すように、第１認証モジュール１３０（モデルＡ）は、第１認証モジュール関連付け情報（モデルＡ）１３３を有する。

図２０は、認証鍵リレー型キーストア１４０に保持される秘密鍵および認証ポリシーを示す図である。
図２０に示すように、認証鍵リレー型キーストア１４０は、ＷＥＢサービス（甲サービス）の認証ポリシー１１３(甲)と、甲サービス向け秘密鍵１４２(甲)と、ＷＥＢサービス（乙サービス）の認証ポリシー１１３(乙)と、乙サービス向け秘密鍵１４２(乙)と、第１認証モジュール関連付け情報（モデルＡ）１３３(旧)と、を有する。このように、認証鍵リレー型キーストア１４０は、第１認証モジュール関連付け情報（モデルＡ）１４３に対し、ＷＥＢサービス向けの秘密鍵１４２とＷＥＢサービスから提示された認証ポリシー１１３を関連付けて保持する。

<追加>
図１８に示すように、スマートホン等の端末１２０を追加した場合、第１認証モジュール１３０（モデルＡ）に加えて、第２認証モジュール（モデルＢ）１３０(新)が追加され、第２認証モジュール（モデルＢ）１３０(新)が下記シーケンスを実行する。

第２認証モジュール（モデルＢ）１３０(新)は、認証鍵リレー型キーストア１４０に第１認証モジュール（モデルＡ）１３０(旧)を用いてログインを行う（ステップＳ６０１）。
第２認証モジュール（モデルＢ）１３０(新)は、認証鍵リレー型キーストア１４０に第２認証モジュール関連付け情報（モデルＢ）１３３(新)を送信して第２認証モジュール（モデルＢ）１３０(新)の登録を実行する（ステップＳ６０２）。第２認証モジュール（モデルＢ）１３０(新)の登録により、第２認証モジュール（モデルＢ）１３０(新)と認証鍵リレー型キーストア１４０間で、第２認証モジュール関連付け情報（モデルＢ）１３３(新)を持ち合う。

<メタデータサービスのメタデータ参照>
認証鍵リレー型キーストア１４０は、第２認証モジュール関連付け情報（モデルＢ）１３３(新)を基に、メタデータサービス１５０のメタデータ２００（図２）を参照する（ステップＳ６０３）。
メタデータサービス１５０は、認証鍵リレー型キーストア１４０に、第２認証モジュール関連付け情報（モデルＢ）１３３(新)に基づくメタデータ２００（図２）を送信する（ステップＳ６０４）。

<更新処理>
認証鍵リレー型キーストア１４０は、認証ポリシー（甲サービス）１１３と第２認証モジュール関連付け情報（モデルＢ）１３３(新)のメタデータ２００の認証レベル情報２０２とを比較する（ステップＳ６０５ 以下図１９参照）。
特に、認証鍵リレー型キーストア１４０は、第２認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が第１認証モジュール１３０（モデルＡ）の認証レベル情報２０２と同等かより高いかを判定する（ステップＳ６０６）。
第２認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が第１認証モジュール１３０（モデルＡ）の認証レベル情報２０２と同等かより高い場合（ステップＳ６０６のＹｅｓ）、第２認証モジュール（モデルＢ）１３０(新)と甲サービス向け秘密鍵１４２(甲)を関連付ける関連付け実行リスト１９１のＷＥＢサービス（甲サービス）１１０(甲)を追加する（ステップＳ６０７）。

図２１は、第２認証モジュール（モデルＢ）１３０(新)と甲サービス向け秘密鍵１４２(甲)の関連付け実行を説明する図である。
図２１（ａ）に示すように、認証鍵リレー型キーストア１４０は、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が第１認証モジュール１３０（モデルＡ）の認証レベル情報２０２と同等かより高い場合、第２認証モジュール関連付け情報（モデルＢ）１３３(新)と甲サービス向け秘密鍵１４２(甲)を関連付けて、関連付け実行リスト１９１（図１９）を作成する。この場合、関連付け実行リスト１９１には、関連付けＷＥＢサービス（甲サービス）１１０(甲)が追加される。この関連付け実行リスト１９１を基に、第１認証モジュール１３０（モデルＡ）を第２認証モジュール（モデルＢ）１３０(新)に更新することが可能になる。

図１９のシーケンスに戻って、(新)認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が第１認証モジュール１３０（モデルＡ）の認証レベル情報２０２に達していない場合、(新)認証モジュール関連付け情報（モデルＢ）１３３(新)と甲サービス向け秘密鍵１４２(甲)を関連付けない関連付け不可リスト１９２を作成する（ステップＳ６０８）。すなわち、図２１（ｂ）に示すように、認証鍵リレー型キーストア１４０は、第２認証モジュール（モデルＢ）１３０(新)の認証レベル情報２０２が第１認証モジュール１３０（モデルＡ）の認証レベル情報２０２に達していない場合（ステップＳ６０６のＮｏ）、第２認証モジュール関連付け情報（モデルＢ）１３３(新)と甲サービス向け秘密鍵１４２(甲)とを関連付けせず、関連付け不可リスト１９２（図１９）を作成する。
上記ステップＳ６０５〜ステップＳ６０８の処理を、説明の便宜上「処理Ｂ」という。
上記処理Ｂを各ＷＥＢサービスの認証ポリシーで実行する。

認証鍵リレー型キーストア１４０は、第２認証モジュール（モデルＢ）１３０(新)に関連付け結果（関連付け実行リスト１９１または関連付け不可リスト１９２）を送付する（ステップＳ６０９）。第２認証モジュール（モデルＢ）１３０(新)は、送付された関連付け結果に従って自身の関連付け実行リスト１９１または関連付け不可リスト１９２を更新する。
なお、関連付けができなかったＷＥＢサービスについては、ユーザ側で実行する必要がある。

以上説明したように、本実施形態に係る電子鍵再登録システム１００は、秘密鍵と公開鍵のペアを生成し、生成した秘密鍵を閉じ込めて保管する鍵処理保管領域１３４（図１）と、秘密鍵との認証モジュール関連付け情報１３３と、を有する認証モジュール１３０と、認証方式や認証の強度の認証ポリシー１１３に従って、利用可能な認証モジュール１３０を決定するとともに、認証モジュール１３０で生成された公開鍵を管理するＷＥＢサービス１１０と、ＷＥＢサービス１１０との間で鍵を利用して認証モジュール１３０の情報を保管するメタデータサービス１５０と、認証モジュール関連付け情報１３３を、ネットワーク上で保持する認証鍵リレー型キーストア１４０と、を備える。

メタデータサービス１５０は、認証方式を認証の強度毎にグループ分けした認証レベル情報２０２（図２）をメタデータ２００として有する。認証鍵リレー型キーストア１４０は、ＷＥＢサービス１１０に認証モジュール１３０を登録する際に提示された認証ポリシー１１３を保管し、認証モジュール１３０の紛失、変更または追加時に、変更または追加される認証モジュール１３０の認証モジュール関連付け情報１３３を取得し、取得した認証モジュール関連付け情報１３３を基に、メタデータサービス１５０の認証レベル情報２０２を参照し、参照した認証レベル情報２０２の認証レベルと保管している認証モジュール１３０の認証ポリシー１１３とに基づいて、変更または追加される認証モジュール１３０の認証モジュール関連付け情報１３３と保持している秘密鍵とを関連付けること、または関連付けが不可であることを決定する。

このようにすることで、ＷＥＢサービス１１０側は特に何も処理負担することなく、認証モジュール１３０の追加や交換が本システム側で処理完了できる。また、ユーザが利用している各ＷＥＢサービス１１０への認証モジュールの追加や更新の手間を軽減することができる。軽減効果は、下記の通りである。
すなわち、ユーザの操作量で比較した場合、本システムがない場合（ＦＩＤＯそのものの方式の場合）には、「ユーザが利用する認証モジュール数×ＷＥＢサイト数の操作回数」である。これに対して、本システムを適用する場合、「ユーザが利用する認証モジュール数＋ＷＥＢサイト数の操作回数」となり、認証モジュールの追加や更新の手間を大幅に軽減することができる。

また、ＷＥＢサービス向け秘密鍵を、ネットワーク（インターネット４）上のサーバ（認証鍵リレー型キーストア１４０）で保管しているので、ＷＥＢサービス向けの秘密鍵が認証モジュールの紛失とともになくなることがないため、ユーザからの鍵紛失時のＷＥＢサービス側への問い合わせが減り、ＷＥＢサービス側の運用負担を軽減することができる。

また、本実施形態では、認証鍵リレー型キーストア１４０は、認証モジュール１３０の紛失、変更または追加時に、メタデータサービス１５０から参照した認証レベル情報２０２の認証レベルが、保管している認証モジュール１３０の認証ポリシー１１３の認証レベル以上の場合に、変更または追加される認証モジュール１３０の認証モジュール関連付け情報１３３と保持している秘密鍵とを関連付ける。

これにより、ＷＥＢサービス１１０側は特に何も処理負担することなく、認証モジュール１３０の更新や追加が本システム側で処理完了できる。また、ユーザが利用している各ＷＥＢサービス１１０への認証モジュールの追加や更新の手間を軽減することができる。また、ユーザが利用している各ＷＥＢサービス１１０への認証モジュールの追加や更新の手間を軽減することができる。

また、本実施形態では、認証モジュール１３０を備える端末１２０が、ネットワーク上のネットワーク認証サーバ１６０と認証鍵リレー型キーストア１４０に接続可能な場合、端末１２０とネットワーク認証サーバ１６０間は鍵を利用して認証鍵リレー型キーストア１４０にログインし、認証鍵リレー型キーストア１４０は、端末１２０をネットワーク認証サーバ１６０へリダイレクトさせて、端末１２０とネットワーク認証サーバ１６０間で利用者認証を実行させ、ネットワーク認証サーバ１６０から受け取った認証結果アサーションが良であるならば、端末１２０にアクセス許可する。

従来、ＷＥＢサービスの場合はユーザの数が多く、オンライン上の繋がりだけで直接的な関係を持たないことが多いため復旧の際に本人かどうか確認することが困難であった。
また、従来のＦＩＤＯ ＵＡＦ方式では、以前利用していた認証モジュールと異なるモデルの認証モジュールに交換すると、ＷＥＢサービス側に再度、利用可能な認証モジュールかどうか問い合わせる必要がある。ユーザはＷＥＢサービスに対し、認証モジュールの再登録を行う必要あり、ユーザの手間がかかる。また、ＷＥＢサービス側もユーザの本人確認を行う必要があるため、運用負担が増加する。例えば、認証鍵リレー型キーストアに登録してある、認証モジュールをすべて紛失した状態で、該当のアカウントを継続利用したくて新たな認証モジュールを認証鍵リレー型キーストアに登録する場合、それまで該当のアカウントを利用していたユーザか、確認する必要がある。

これに対して、本実施形態では、認証鍵リレー型キーストア１４０は、端末１２０をネットワーク認証サーバ１６０へリダイレクトさせて、端末１２０とネットワーク認証サーバ１６０間で利用者認証を実行させることで、オンラインで対面での本人確認相当のユーザの確認を取ることができる。

また、本実施形態では、認証モジュール１３０を備える端末１２０が、ネットワーク上のネットワーク認証サーバ１６０と認証鍵リレー型キーストア１４０に接続可能な場合、端末１２０と認証鍵リレー型キーストア１４０間で利用者認証を実行し、利用者認証実行後、認証鍵リレー型キーストア１４０は、利用者ＩＤ１８１を生成し、ネットワーク認証サーバ１６０は、認証鍵リレー型キーストア１４０との認証結果アサーションが良であるならば、認証鍵リレー型キーストア１４０との間で利用ＩＤを共有し、認証鍵リレー型キーストア１４０は、利用者ＩＤ１８１を保存するとともに、端末１２０に利用者ＩＤ１８１の登録完了を通知する。

これにより、認証鍵リレー型キーストア１４０は、利用者ＩＤ１８１の生成要求時、ネットワーク認証サーバ１６０との間で認証結果アサーションを実行し、自身は利用者ＩＤ１８１を保存するとともに、端末１２０に利用者ＩＤ１８１の登録完了を通知するので、ＷＥＢサービス１１０側は特に何も処理負担することなく、利用者ＩＤ１８１の登録を行うことができる。その結果、ユーザが利用している各ＷＥＢサービス１１０への認証モジュールの登録の手間を軽減することができる。

また、本実施形態では、認証モジュール１３０を備える端末１２０が、ネットワーク上のネットワーク認証サーバ１６０と認証鍵リレー型キーストア１４０に接続可能な場合、認証鍵リレー型キーストア１４０は、端末１２０から利用者ＩＤ１８１の確認要求を受け付けたならば、ネットワーク認証サーバ１６０に利用者ＩＤ１８１を要求し、ネットワーク認証サーバ１６０は、認証鍵リレー型キーストア１４０との認証結果アサーションが良であるならば、認証鍵リレー型キーストア１４０に利用ＩＤを送信する。

これにより、認証鍵リレー型キーストア１４０は、利用者ＩＤ１８１の確認要求時、ネットワーク認証サーバ１６０との間で認証結果アサーションを実行し、自身は利用者ＩＤ１８１を保存するとともに、端末１２０に利用者ＩＤ１８１の登録完了を通知するので、ＷＥＢサービス１１０側は特に何も処理負担することなく、利用者ＩＤ１８１の確認を行うことができる。

また、本実施形態では、メタデータサービス１５０は、さらに秘密鍵の保管領域２０７をメタデータ２００として有し、ＷＥＢサービス１１０からの要求に応じて、秘密鍵の保管領域２０７を参照させる。

これにより、認証鍵リレー型キーストア１４０は、メタデータサービス１５０のメタデータ２００（図２）を参照することで、認証レベルを比較する（すなわち認証方式の完全一致まで見ない）ので、ＷＥＢサービス側に再度、利用可能な認証モジュールかどうか問い合わせる回数（頻度）を大幅に減らすことができ、ユーザの手間およびＷＥＢサービス側の運用負担を低減することができる。すなわち、従来は、認証方式等細かく指定しなければならず、認証モジュール間の認証レベルの互換性がないため、ＷＥＢサービス側にＷＥＢサービスが要求する認証レベルに合致するか、確認する必要がある。本実施形態では、同じ認証レベルであれば、どの認証モジュールで認証を行ってもよいため、認証モジュールを追加・変更した際に、認証レベルが同じ認証モジュールであれば、ＷＥＢサービス側に認証レベルを確認する必要がない。

また、本実施形態に係る電子鍵再登録システム１００は、メタデータ２００（図２）の認証レベル情報２０２の認証レベルLv３，Lv４に示すように、指紋や光彩などの生体認証の結果生成した鍵を用いることも可能である。生体認証の結果生成した鍵と通信キャリアのＩＭＳＩを関連付けることで、通信キャリアの契約者情報と利用者の関係を付けることができ、対面で行う本人確認に相当するレベルでのユーザの確認をオンラインにより、パスワードに依らない認証で実行可能である。

［適用例］
本実施形態に係る電子鍵再登録システムは、固定回線を利用した家電へ適用することができる。
<構成>
図２２ないし図２４は、本発明の実施形態に係る電子鍵再登録システムの固定回線などを利用した家電への適用例を示す図である。図２２は、電子鍵再登録システム１００Ａの構成図である。
図２２に示すように、電子鍵再登録システム１００Ａは、ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃと、認証鍵リレー型キーストア１４０と、メタデータサービス１５０と、光ファイバーなどの固定回線による通信キャリア網１と自宅３１０内ネットワークの橋渡しを行うＨＧＷ（Home Gate Way）３００と、を備える。

ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃは、図１のＷＥＢサービス１１０と同一構成である。ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃは、自宅３１０内ネットワークに接続された家電３１１，３１２，３１３にそれぞれ対応している。家電３１１，３１２，３１３は、ＰＣ，ＡＶ機器，タブレット，電話機などのいわゆる情報機器のほか、白物家電や照明・エアコン・セキュリティ機器など屋内設備機器がある。また、家電３１１，３１２，３１３とＨＧＷ３００とを繋ぐネットワークは、有線ＬＡＮのほか、無線ＬＡＮ、Bluetooth（登録商標）などの特定近距離無線でもよい。
ＨＧＷ３００は、図１の端末１２０および認証モジュール１３０としての機能を備える。また、ＩＭＳＩは、固定回線用電話番号である。

ＨＧＷ３００の動作は、ＨＧＷ３００を図１の端末１２０および認証モジュール１３０に置き換えた上で、動作例Ａ〜Ｆと同様の動作シーケンスで実現する。
図２２の通信キャリア網１は、例えばＬＴＥ／３Ｇ網である。図２２のネットワークは、例えばインターネット４であり、インターネット４上のサーバ（事業者用サーバ、クラウドサーバを含む）に、ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃ、認証鍵リレー型キーストア１４０、メタデータサービス１５０、およびネットワーク認証サーバ１６０（図示省略）が置かれる。

<ＨＧＷの登録>
図２３は、図２２の電子鍵再登録システム１００ＡのＨＧＷ３００の登録を説明する図である。
図２３に示すように、ＨＧＷ３００の設置時等に、通信キャリア事業者の契約者の確認を基に、ＨＧＷ３００と認証鍵リレー型キーストア１４０間で鍵（ＨＧＷ向けの秘密鍵３０１とＨＧＷ向けの公開鍵３３１）を持ち合う。この鍵は、通信キャリアが対面によりユーザを確認し、ＨＧＷ３００を設置した際に、設置作業の一環として鍵を持ち合う操作を行ってもよい。

次に、ＰＣ等で、ＨＧＷ３００を経由して、ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃにアクセスし、アカウントを登録する。アカウント登録手続きの中で、ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃが認証のための公開鍵（ＷＥＢサービス向けの公開鍵１１２Ａ，１１２Ｂ，１１２Ｃ）の登録を要求する。その登録要求はＨＧＷ３００で処理を行う。ＨＧＷ３００は、認証鍵リレー型キーストア１４０に鍵の生成要求を送信し、ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃ側の鍵（ＷＥＢサービス向けの秘密鍵１４２Ａ，１４２Ｂ，１４２Ｃ）を生成し、ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃに公開鍵（ＷＥＢサービス向けの公開鍵１１２Ａ，１１２Ｂ，１１２Ｃ）を送る。
ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃの分だけ登録を繰り返すことで、利用するすべてのＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃと、認証鍵リレー型キーストア１４０間で鍵を持ち合う。

<家電の登録>
図２４は、図２２の電子鍵再登録システムの家電３１１，３１２，３１３の登録を説明する図である。
図２４に示すように、家電３１１，３１２，３１３をＨＧＷ３００に接続すると、ＨＧＷ３００と認証鍵リレー型キーストア１４０間で接続された家電用の鍵ペア（家電の秘密鍵３２１，３２２，３２３）を生成し持ち合う。鍵の生成能力を備えた家電であれば、家電側で鍵を生成し、ＨＧＷ３００を通じて認証鍵リレー型キーストア１４０と鍵の共有を行ってもよい。
その際、認証鍵リレー型キーストア１４０は、ＨＧＷ３００の秘密鍵３０１・公開鍵３３１を用いて認証を行うことで、ＨＧＷ３００の公開鍵３３１と家電３１１，３１２，３１３の公開鍵３４１，３４２，３４３の関係を付けることができる。また、家電３１１，３１２，３１３の公開鍵３４１，３４２，３４３とＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃ向け秘密鍵１４２Ａ，１４２Ｂ，１４２Ｃの関係を付ける。

これにより、家電をＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃにログインさせて、サービスを提供するようなＷＥＢサービスがあった場合、すべてのＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃに家電を登録する必要がなく、ユーザの登録回数の負担を軽減している。さらに、ＷＥＢサービス１１０Ａ，１１０Ｂ，１１０Ｃ側は、対面や書類により厳密に本人確認を実施し上で持ち合ったＨＧＷ３００の公開鍵３３１と、それと関連付けて家電３１１，３１２，３１３の公開鍵３４１，３４２，３４３を登録することで、家電３１１，３１２，３１３の所有者の関係をＨＧＷ３００によって接続されている範囲に限定することができる。これにより、家電３１１，３１２，３１３のユーザをより厳密に特定できるようになる。
このように、電子鍵再登録システム１００Ａは、自宅３１０に多数の家電３１１，３１２，３１３がある際の追加、変更にも適用可能であり、図１ないし図２１で述べた電子鍵再登録システム１００と、同様の効果を得ることができる。

なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。

２ ＬＴＥ／３Ｇ網側インタフェース
４ インターネット（ネットワーク）
１００，１００Ａ 電子鍵再登録システム
１１０，１１０Ａ，１１０Ｂ，１１０Ｃ ＷＥＢサービス
１１１ アカウント
１１２，１１２Ａ，１１２Ｂ，１１２Ｃ ＷＥＢサービス向け公開鍵
１１３ 認証ポリシー
１２０ 端末
１２１ 認証アプリケーション
１２２ スマホ用秘密鍵
１２３ ＮＷ認証アプリ限定領域
１３０ 認証モジュール（認証デバイス）
１３１ 認証判定モジュール
１３２ メタデータサービス向け秘密鍵
１３３ 認証モジュール関連付け情報
１３４ 鍵処理保管領域
１４０ 認証鍵リレー型キーストア（キーストア）
１４１ ＷＥＢサービスのＵＲＬ
１４２，１４２Ａ，１４２Ｂ，１４２Ｃ ＷＥＢサービス向け秘密鍵
１５０ メタデータサービス
１５１ メタデータサービス向け公開鍵
１５２ 認証モジュールの情報
１５３ メタデータサービス向け公開鍵
１５４ 認証モジュールの情報
１６０ ネットワーク認証サーバ
１６１ スマホ用公開鍵
１６２ 耐タンパー領域
１６３ ユーザ管理データベース（ＤＢ）
１６４ サーバ証明書
１９１ 関連付け実行リスト
１９２ 関連付け不可リスト
２００ メタデータ
２０１ 認証モジュールモデルＩＤ
２０２ 認証レベル情報
２０３ 認証方式
２０４ メタデータサービス向け公開鍵
２０５ 認証モジュールの実装形態
２０６ 鍵処理保管領域の実装形態
２０７ 秘密鍵の保管領域
２０８ 認証精度情報
３００ ＨＧＷ
３１１，３１２，３１３ 家電
３２１，３２２，３２３ 家電の秘密鍵
３０１ ＨＧＷの秘密鍵
３３１ ＨＧＷの公開鍵
３４１，３４２，３４３ 家電の公開鍵

Claims (8)

1. 秘密鍵と公開鍵のペアを生成し、生成した前記秘密鍵を閉じ込めて保管する鍵処理保管領域と、前記秘密鍵との関連付け情報と、を有する認証デバイスと、
   認証方式および認証の強度を示す認証ポリシーに従って、利用可能な前記認証デバイスを決定するとともに、前記認証デバイスで生成された前記公開鍵を管理するＷＥＢサービスと、
   前記ＷＥＢサービスとの間で鍵を利用して前記認証デバイスの情報を保管するメタデータサービスと、
   前記関連付け情報を、ネットワーク上で保持するキーストアと、を備え、
   前記メタデータサービスは、
   前記認証方式を前記認証の強度毎にグループ分けした認証レベル情報をメタデータとして有し、
   前記キーストアは、
   前記ＷＥＢサービスに前記認証デバイスを登録する際に提示された前記認証ポリシーを保管し、
   前記認証デバイスの変更または追加時に、
   変更または追加される前記認証デバイスの前記関連付け情報を取得し、取得した前記関連付け情報を基に、前記メタデータサービスの前記認証レベル情報を参照し、
   参照した前記認証レベル情報の認証レベルと保管している前記認証デバイスの前記認証ポリシーとに基づいて、変更または追加される前記認証デバイスの前記関連付け情報と保持している前記秘密鍵とを関連付ける
   ことを特徴とする電子鍵再登録システム。
2. 前記キーストアは、前記認証デバイスの変更または追加時に、
   前記メタデータサービスから参照した前記認証レベル情報の認証レベルが、保管している前記認証デバイスの前記認証ポリシーの認証レベル以上の場合に、変更または追加される前記認証デバイスの前記関連付け情報と保持している前記秘密鍵とを関連付ける
   ことを特徴とする請求項１に記載の電子鍵再登録システム。
3. 前記認証デバイスを備える端末が、ネットワーク上の認証サーバと前記キーストアに接続可能な場合、
   前記端末と前記認証サーバ間は鍵を利用して前記キーストアにログインし、
   前記キーストアは、
   前記端末を前記認証サーバへリダイレクトさせて、前記端末と前記認証サーバ間で利用者認証を実行させ、
   前記認証サーバから受け取った認証結果アサーションが良であるならば、前記端末にアクセス許可する
   ことを特徴とする請求項１に記載の電子鍵再登録システム。
4. 前記認証デバイスを備える端末が、ネットワーク上の認証サーバと前記キーストアに接続可能な場合、
   前記端末と前記キーストア間で利用者認証を実行し、
   前記利用者認証実行後、前記キーストアは、利用者ＩＤを生成し、
   前記認証サーバは、前記キーストアとの認証結果アサーションが良であるならば、前記キーストアとの間で前記利用者ＩＤを共有し、
   前記キーストアは、前記利用者ＩＤを保存するとともに、前記端末に利用者ＩＤの登録完了を通知する
   ことを特徴とする請求項１に記載の電子鍵再登録システム。
5. 前記認証デバイスを備える端末が、ネットワーク上の認証サーバと前記キーストアに接続可能な場合、
   前記キーストアは、前記端末から利用者ＩＤの確認要求を受け付けたならば、前記認証サーバに前記利用者ＩＤを要求し、
   前記認証サーバは、前記キーストアとの認証結果アサーションが良であるならば、前記キーストアに前記利用者ＩＤを送信する
   ことを特徴とする請求項１に記載の電子鍵再登録システム。
6. 前記メタデータサービスは、さらに前記秘密鍵の保管領域情報を前記メタデータとして有し、
   前記ＷＥＢサービスからの要求に応じて、前記秘密鍵の保管領域情報を参照させる
   ことを特徴とする請求項１に記載の電子鍵再登録システム。
7. 秘密鍵と公開鍵のペアを生成し、生成した前記秘密鍵を閉じ込めて保管する鍵処理保管領域と、前記秘密鍵との関連付け情報と、を有する認証デバイスと、
   認証方式および認証の強度を示す認証ポリシーに従って、利用可能な前記認証デバイスを決定するとともに、前記認証デバイスで生成された前記公開鍵を管理するＷＥＢサービスと、
   前記ＷＥＢサービスとの間で鍵を利用して前記認証デバイスの情報を保管するとともに、前記認証方式を前記認証の強度毎にグループ分けした認証レベル情報をメタデータとして有するメタデータサービスと、
   前記関連付け情報と、前記ＷＥＢサービスに前記認証デバイスを登録する際に提示された前記認証ポリシーとをネットワーク上で保管するキーストアと、を備える電子鍵再登録システムの電子鍵再登録方法であって、
   前記キーストアは、
   前記認証デバイスの変更または追加時に、
   変更または追加される前記認証デバイスの前記関連付け情報を取得するステップと、
   取得した前記関連付け情報を基に、前記メタデータサービスの前記認証レベル情報を参照するステップと、
   参照した前記認証レベル情報の認証レベルと保管している前記認証デバイスの前記認証ポリシーとに基づいて、変更または追加される前記認証デバイスの前記関連付け情報と保持している前記秘密鍵とを関連付けるまたは関連付け不可を決定するステップと、を実行する
   ことを特徴とする電子鍵再登録方法。
8. 秘密鍵と公開鍵のペアを生成し、生成した前記秘密鍵を閉じ込めて保管する鍵処理保管領域と、前記秘密鍵との関連付け情報と、を有する認証デバイスと、
   認証方式および認証の強度を示す認証ポリシーに従って、利用可能な前記認証デバイスを決定するとともに、前記認証デバイスで生成された前記公開鍵を管理するＷＥＢサービスと、
   前記ＷＥＢサービスとの間で鍵を利用して前記認証デバイスの情報を保管するとともに、前記認証方式を前記認証の強度毎にグループ分けした認証レベル情報をメタデータとして有するメタデータサービスと、
   前記関連付け情報と、前記ＷＥＢサービスに前記認証デバイスを登録する際に提示された前記認証ポリシーとをネットワーク上で保管するキーストアと、を備える電子鍵再登録システムの前記キーストアとしてのコンピュータを、
   前記認証デバイスの変更または追加時に、
   変更または追加される前記認証デバイスの前記関連付け情報を取得する取得手段、
   取得した前記関連付け情報を基に、前記メタデータサービスの前記認証レベル情報を参照する参照手段、
   参照した前記認証レベル情報の認証レベルと保管している前記認証デバイスの前記認証ポリシーとに基づいて、変更または追加される前記認証デバイスの前記関連付け情報と保持している前記秘密鍵とを関連付けるまたは関連付け不可を決定する決定手段、として機能させるためのプログラム。

Images