JP2017152880A - 認証システム、鍵処理連携方法、および、鍵処理連携プログラム - Google Patents
認証システム、鍵処理連携方法、および、鍵処理連携プログラム Download PDFInfo
- Publication number
- JP2017152880A JP2017152880A JP2016032659A JP2016032659A JP2017152880A JP 2017152880 A JP2017152880 A JP 2017152880A JP 2016032659 A JP2016032659 A JP 2016032659A JP 2016032659 A JP2016032659 A JP 2016032659A JP 2017152880 A JP2017152880 A JP 2017152880A
- Authority
- JP
- Japan
- Prior art keywords
- authentication
- key
- web service
- terminal
- authentication module
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Abstract
【課題】ＷＥＢサービス向けのオンライン認証に用いられる鍵の紛失を回避し、ＷＥＢサービス向けのオンライン認証を確実に実行させる。
【解決手段】ユーザ認証を行う認証モジュール３０を備える端末２０と、端末２０が利用するＷＥＢサービス１０と、所定の鍵を保有する認証鍵リレー型キーストア４０と、を備える認証システム１００にて、ＷＥＢサービス１０は、端末２０がＷＥＢサービス１０にアクセスするための認証に用いられるＷＥＢサービス認証用公開鍵ＰＫ１を有しており、キーストア４０は、ＷＥＢサービス認証用秘密鍵ＳＫ１、および、認証モジュール３０の認証に用いられる認証モジュール認証用秘密鍵ＳＫ３を、耐タンパー領域Ｒ３内に閉じ込めており、端末２０は、認証モジュール認証用公開鍵ＰＫ３を有しており、公開鍵ＰＫ３および秘密鍵ＳＫ３を用いて処理される情報を、端末２０とキーストア４０との間で暗号化して送受信する。
【選択図】図１
【解決手段】ユーザ認証を行う認証モジュール３０を備える端末２０と、端末２０が利用するＷＥＢサービス１０と、所定の鍵を保有する認証鍵リレー型キーストア４０と、を備える認証システム１００にて、ＷＥＢサービス１０は、端末２０がＷＥＢサービス１０にアクセスするための認証に用いられるＷＥＢサービス認証用公開鍵ＰＫ１を有しており、キーストア４０は、ＷＥＢサービス認証用秘密鍵ＳＫ１、および、認証モジュール３０の認証に用いられる認証モジュール認証用秘密鍵ＳＫ３を、耐タンパー領域Ｒ３内に閉じ込めており、端末２０は、認証モジュール認証用公開鍵ＰＫ３を有しており、公開鍵ＰＫ３および秘密鍵ＳＫ３を用いて処理される情報を、端末２０とキーストア４０との間で暗号化して送受信する。
【選択図】図１
Description
本発明は、電子鍵（以下、単に、「鍵」と呼ぶ場合がある。）による暗号化の技術に関する。
スマートホンなどの端末がＷＥＢサービスを利用する際のセキュリティをいかに向上させるかが重要視されている。近年では、パスワードに依存しないオンライン認証として、鍵による暗号化を用いたオンライン認証が、ＦＩＤＯ（Fast Identity Online） Allianceなどによって提唱されている。このオンライン認証では、ＷＥＢサービスに公開鍵を持たせ、端末に秘密鍵を持たせる。端末は、オンライン認証に利用可能な認証モジュールを備えており、認証モジュールの専用の領域に秘密鍵を閉じ込めたまま認証を行うことができる。なお、鍵を「閉じ込める」とは、領域内に生成した鍵は、その鍵を削除するまでに領域外に取り出さないことを意味する。
諸事情により、端末が備える認証モジュールを紛失してしまった場合、認証モジュール内の秘密鍵も紛失してしまう。しかし、端末に新たな認証モジュールを備えたとしても、紛失前の秘密鍵と同じ秘密鍵を用意することはできない。その結果、秘密鍵を紛失した端末が、秘密鍵の紛失前から継続する態様でＷＥＢサービスを利用することはもはやできない。なお、現時点では、ＦＩＤＯでは鍵を復旧する技術が規定されていない。
特許文献１には、特定の複数の利用者を対象にして、本人確認を実行することができるグループを設定し、本人確認ができれば鍵の復旧を行う技術について開示されている。
しかし、特許文献１の技術を用いても、不特定多数の者が利用するＷＥＢサービスに対しては、本人確認を実行することができるグループを設定することが困難であるため、本人確認をしつつ鍵の復旧を行うことはできない。
このような事情に鑑みて、本発明は、ＷＥＢサービス向けのオンライン認証に用いられる鍵の紛失を回避し、ＷＥＢサービス向けのオンライン認証を確実に実行させることを課題とする。
前記した課題を解決するため、請求項１に記載の発明は、ユーザ認証を行う認証モジュールを備える端末と、前記端末が利用するＷＥＢサービスと、所定の鍵を保有するキーストアと、が通信可能に接続されている認証システムであって、前記ＷＥＢサービスは、前記端末が前記ＷＥＢサービスにアクセスするための認証に用いられるＷＥＢサービス認証用公開鍵を有しており、前記キーストアは、前記ＷＥＢサービス認証用公開鍵の対となるＷＥＢサービス認証用秘密鍵、および、前記認証モジュールの認証に用いられる認証モジュール認証用秘密鍵を、耐タンパー領域内に閉じ込めており、前記端末は、前記認証モジュール認証用秘密鍵の対となる認証モジュール認証用公開鍵を有しており、前記認証モジュール認証用公開鍵および前記認証モジュール認証用秘密鍵を用いて処理される情報を、前記端末と前記キーストアとの間で暗号化して送受信する、ことを特徴とする。
また、請求項５に記載の発明は、ユーザ認証を行う認証モジュールを備える端末と、前記端末が利用するＷＥＢサービスと、所定の鍵を保有するキーストアと、が通信可能に接続されている認証システムにおける鍵処理連携方法であって、前記ＷＥＢサービスが、前記端末が前記ＷＥＢサービスにアクセスするための認証に用いられるＷＥＢサービス認証用公開鍵を有し、前記キーストアが、前記ＷＥＢサービス認証用公開鍵の対となるＷＥＢサービス認証用秘密鍵を耐タンパー領域内に閉じ込める、という態様において、前記キーストアが、前記認証モジュールの認証に用いられる、認証モジュール認証用秘密鍵および認証モジュール認証用公開鍵を生成し、前記認証モジュール認証用公開鍵を前記端末に送信するステップと、前記認証モジュール認証用公開鍵および前記認証モジュール認証用秘密鍵を用いて処理される情報を、前記端末と前記キーストアとの間で暗号化して送受信するステップ、とを実行する、ことを特徴とする。
また、請求項６に記載の発明は、ユーザ認証を行う認証モジュールを備える端末と、前記端末が利用するＷＥＢサービスと、所定の鍵を保有するキーストアと、が通信可能に接続されている認証システムの前記キーストアとしてのコンピュータを、前記ＷＥＢサービスが、前記端末が前記ＷＥＢサービスにアクセスするための認証に用いられるＷＥＢサービス認証用公開鍵を有し、前記キーストアが、前記ＷＥＢサービス認証用公開鍵の対となるＷＥＢサービス認証用秘密鍵を耐タンパー領域内に閉じ込める、という態様において、前記認証モジュールの認証に用いられる、認証モジュール認証用秘密鍵および認証モジュール認証用公開鍵を生成し、前記認証モジュール認証用公開鍵を前記端末に送信する手段と、前記認証モジュール認証用公開鍵および前記認証モジュール認証用秘密鍵を用いて処理される情報を、前記端末と前記キーストアとの間で暗号化して送受信する手段、として機能させるための鍵処理連携プログラムである。
請求項１，５，６に記載の発明によれば、端末側の認証モジュール認証用公開鍵、および、キーストア側の認証モジュール認証用秘密鍵を用いて、ユーザ認証結果とＷＥＢサービス認証用秘密鍵とを関連付けることで、両者間の処理順序や関係を一意にすることができる。従来は、秘密鍵を利用する際は認証が必要で、キーストアの認証モジュール認証用秘密鍵とＷＥＢサービス認証用秘密鍵といった２種類の秘密鍵を利用する場合は、秘密鍵の利用ごとにユーザの認証を行い（つまり、ユーザ認証を２回実施し）、各認証で承認を得る必要があるが、本方式では、ユーザの認証から鍵の利用順序を一意にすることが可能であるため、ユーザの認証を１回実施すればよい。その結果、ＷＥＢサービスでの認証時におけるユーザの操作量は、従来のＦＩＤＯの認証方式のときと同じにすることができる。よって、なりすましや中間者攻撃などの、キーストアに直接アクセスする不正の操作を見極めて、防止することができ、高セキュリティを実現することができる。
また、鍵の処理が可能な領域が限定されていることから、平文が限定的な領域内でしか扱われないようになり、キーストアの運用者でも情報の改ざん、盗聴、送受信する情報の不正利用を行うことができず、セキュリティの向上に寄与する。
また、端末側にＷＥＢサービス認証用秘密鍵が存在しないため、ユーザによるＷＥＢサービス認証用秘密鍵の紛失は起こりえず、ＷＥＢサービスの継続利用の中断を回避することができる。
したがって、ＷＥＢサービス向けのオンライン認証に用いられる鍵の紛失を回避し、ＷＥＢサービス向けのオンライン認証を確実に実行させることができる。
また、鍵の処理が可能な領域が限定されていることから、平文が限定的な領域内でしか扱われないようになり、キーストアの運用者でも情報の改ざん、盗聴、送受信する情報の不正利用を行うことができず、セキュリティの向上に寄与する。
また、端末側にＷＥＢサービス認証用秘密鍵が存在しないため、ユーザによるＷＥＢサービス認証用秘密鍵の紛失は起こりえず、ＷＥＢサービスの継続利用の中断を回避することができる。
したがって、ＷＥＢサービス向けのオンライン認証に用いられる鍵の紛失を回避し、ＷＥＢサービス向けのオンライン認証を確実に実行させることができる。
また、請求項２に記載の発明は、請求項１に記載の発明であって、前記端末に設定された画面ロックが解除されたことによるユーザ認証を、前記キーストアにアクセスするための前記認証モジュール認証用公開鍵を利用する権限を与える認証とする、ことを特徴とする。
請求項２に記載の発明によれば、画面ロック解除によるユーザ認証の成功が実現したときのみキーストアへのアクセスが可能となるような仕組みを導入することができる。よって、外部のアプリケーションなどから認証モジュール認証用公開鍵へのアクセスを制限し、不正な鍵の利用を防止することができ、さらにセキュリティを向上させることができる。
また、請求項３に記載の発明は、請求項２に記載の発明であって、前記ＷＥＢサービスが前記端末のユーザを登録する際、または、前記ＷＥＢサービスにアクセスしようとする前記端末のユーザを認証する際、前記端末が前記認証モジュール認証用公開鍵を有しており、かつ、前記キーストアが前記認証モジュール認証用秘密鍵を有している、という鍵の持ち合いを、前記端末と前記キーストアとの間で確認し、前記鍵の持ち合いが成立していないとき、前記ＷＥＢサービスが前記端末のユーザを登録する際、または、前記ＷＥＢサービスにアクセスしようとする前記端末のユーザを認証する際、前記端末と前記キーストアとの間で前記鍵の持ち合いを成立させる処理を実行する、ことを特徴とする。
請求項３に記載の発明によれば、ＷＥＢサービスでのユーザの登録の段階、または、ＷＥＢサービスにアクセスしようとする端末のユーザの認証の段階にて、端末とキーストアとの間で鍵の持ち合いを確実に実現するため、端末の画面ロック解除がキーストア側でのユーザ認証を兼ねるようにすることで、鍵の持ち合いの成立後は、ＷＥＢサービス向けのユーザ認証だけで済ませることができ、処理負荷を低減することができる。
また、請求項４に記載の発明は、請求項１から請求項３のいずれか１項に記載の認証システムであって、前記キーストアを第１のキーストアとしてインターネット側に配置し、所定の鍵を保有する第２のキーストアをローカルネットワーク側に配置し、前記端末のユーザの初期登録に関する処理を前記第２のキーストアで実行し、前記第２のキーストアで実行したときの処理結果を暗号化して、前記第１のキーストアに送信する、ことを特徴とする。
請求項４に記載の発明によれば、保有する情報を厳重に管理しているローカルネットワーク側に配置した第２のキーストアが、端末のユーザの初期登録を行うため、外部からの機能の乗っ取りなどの不正な操作をさらに困難にすることができ、さらにセキュリティを向上させることができる。
本発明によれば、ＷＥＢサービス向けのオンライン認証に用いられる鍵の紛失を回避し、ＷＥＢサービス向けのオンライン認証を確実に実行させることができる。
本発明の実施形態について、図面を参照しながら詳細に説明する。
（背景説明）
ＷＥＢサービスではＰＷ（パスワード）による認証が限界を迎えている。辞書攻撃等によるアカウントの不正操作が頻発しているのが現状である。ＰＷに依存しない認証方法として、鍵による認証が検討されている（標準規格策定団体；FIDO Alliance、2012年発足）。
ＦＩＤＯ（First IDentity Online）Allianceは、秘密鍵を生成した場所に閉じ込めたまま、認証に利用することでセキュリティを高めている。ＦＩＤＯAllianceは、標準化された公開鍵暗号方式（ＰＫＩ：Public Key Infrastructure）に基づいている。標準のプロトコルは２つあり、１つは、２要素認証の技術を進化させた認証Ｕ２Ｆ（Universal Second Factor）プロトコル、もう１つは、ＦＩＤＯ標準に対応したモバイルなどのデバイス経由でパスワードを使用しない認証ＵＡＦ（Universal Authentication Framework）プロトコルである。ＦＩＤＯの標準認証には、生体認証技術やＴＰＭ（Trusted Platform Module）、ＮＦＣ（Near Field Communication）に対応し、デバイスやプラグインにも対応しているため、ＷＥＢサイトやクラウドアプリもＦＩＤＯに準拠した対応デバイスにより、オンライン認証の強化を図ることができる。
（背景説明）
ＷＥＢサービスではＰＷ（パスワード）による認証が限界を迎えている。辞書攻撃等によるアカウントの不正操作が頻発しているのが現状である。ＰＷに依存しない認証方法として、鍵による認証が検討されている（標準規格策定団体；FIDO Alliance、2012年発足）。
ＦＩＤＯ（First IDentity Online）Allianceは、秘密鍵を生成した場所に閉じ込めたまま、認証に利用することでセキュリティを高めている。ＦＩＤＯAllianceは、標準化された公開鍵暗号方式（ＰＫＩ：Public Key Infrastructure）に基づいている。標準のプロトコルは２つあり、１つは、２要素認証の技術を進化させた認証Ｕ２Ｆ（Universal Second Factor）プロトコル、もう１つは、ＦＩＤＯ標準に対応したモバイルなどのデバイス経由でパスワードを使用しない認証ＵＡＦ（Universal Authentication Framework）プロトコルである。ＦＩＤＯの標準認証には、生体認証技術やＴＰＭ（Trusted Platform Module）、ＮＦＣ（Near Field Communication）に対応し、デバイスやプラグインにも対応しているため、ＷＥＢサイトやクラウドアプリもＦＩＤＯに準拠した対応デバイスにより、オンライン認証の強化を図ることができる。
<ＦＩＤＯAllianceの認証方法>
図１７は、ＦＩＤＯAllianceの認証方法を説明する図である。
図１７に示すように、ＷＥＢサービス１０は、アカウント１１と、アカウント１１に関連付けられたＷＥＢサービス認証用公開鍵ＰＫ１と、を有する。スマートホン等の端末２０は、ＦＩＤＯAllianceの認証モジュール３０に接続可能である。認証モジュール３０は、認証判定モジュール３１と、ＷＥＢサービス認証用秘密鍵ＳＫ１を保管する鍵処理保管領域Ｒ１と、を有する。ＷＥＢサービス１０と認証モジュール３０が接続された端末２０とは、ＦＩＤＯ（ＵＡＦ）プロトコルに準拠した認証を行う。
ＷＥＢサービス１０では、アカウント１１と公開鍵ＰＫ１とは関連付けられている。
図１７は、ＦＩＤＯAllianceの認証方法を説明する図である。
図１７に示すように、ＷＥＢサービス１０は、アカウント１１と、アカウント１１に関連付けられたＷＥＢサービス認証用公開鍵ＰＫ１と、を有する。スマートホン等の端末２０は、ＦＩＤＯAllianceの認証モジュール３０に接続可能である。認証モジュール３０は、認証判定モジュール３１と、ＷＥＢサービス認証用秘密鍵ＳＫ１を保管する鍵処理保管領域Ｒ１と、を有する。ＷＥＢサービス１０と認証モジュール３０が接続された端末２０とは、ＦＩＤＯ（ＵＡＦ）プロトコルに準拠した認証を行う。
ＷＥＢサービス１０では、アカウント１１と公開鍵ＰＫ１とは関連付けられている。
図１７に示すように、秘密鍵ＳＫ１・公開鍵ＰＫ１のペアを認証デバイス（図１７では認証モジュール３０）で生成し、秘密鍵ＳＫ１は認証デバイスに閉じ込めておく。閉じ込めておくとは、秘密鍵ＳＫ１については、鍵の生成から削除まで認証モジュール３０の鍵処理保管領域Ｒ１から取り出さないことをいう。秘密鍵ＳＫ１を生成した場所（鍵処理保管領域Ｒ１）に閉じ込めたまま、認証に利用することでセキュリティを高めている。セキュリティを高める工夫として、さらに認証デバイスに閉じ込めた鍵による認証は、所有物による認証の性質も兼ね備えることでセキュリティを強化している。
<ＦＩＤＯAllianceの認証方法の特徴>
図１８は、ＦＩＤＯAllianceの認証方法の特徴を説明する図である。
図１８に示すように、ＷＥＢサービス１０は、ＷＥＢサービスアプリケーション１３と、ＦＩＤＯサーバ１５とを有し、ＷＥＢサービスアプリケーション１３は、ユーザ管理ＤＢ１４に格納されたアカウント１１を参照する。ＦＩＤＯサーバ１５は、ＷＥＢサービス認証用公開鍵ＰＫ１を格納する鍵管理領域１６を有する。
ＷＥＢサービス１０は、メタデータサービス１との間で、認証モジュールの情報３を相互に参照する。メタデータサービス１は、メタデータサービス向け公開鍵ＰＫ２を有する。認証モジュールの情報３には、認証モジュールの認証方法（ＰＩＮ（Personal Identification Number）、虹彩、指紋等）の認証の精度等の情報が記載されている。
図１８は、ＦＩＤＯAllianceの認証方法の特徴を説明する図である。
図１８に示すように、ＷＥＢサービス１０は、ＷＥＢサービスアプリケーション１３と、ＦＩＤＯサーバ１５とを有し、ＷＥＢサービスアプリケーション１３は、ユーザ管理ＤＢ１４に格納されたアカウント１１を参照する。ＦＩＤＯサーバ１５は、ＷＥＢサービス認証用公開鍵ＰＫ１を格納する鍵管理領域１６を有する。
ＷＥＢサービス１０は、メタデータサービス１との間で、認証モジュールの情報３を相互に参照する。メタデータサービス１は、メタデータサービス向け公開鍵ＰＫ２を有する。認証モジュールの情報３には、認証モジュールの認証方法（ＰＩＮ（Personal Identification Number）、虹彩、指紋等）の認証の精度等の情報が記載されている。
端末２０は、ブラウザ・アプリ２１、ＦＩＤＯクライアント２２、認証管理情報２３、および認証モジュールドライバ２４を有する（アプリケーションを「アプリ」と略記する場合がある）。ＦＩＤＯクライアント２２は、ＷＥＢサービス１０との間でＦＩＤＯ（ＵＡＦ）プロトコルに準拠して、ＷＥＢサービス１０側の認証ポリシーに従った認証を行う。認証ポリシーとは、ＷＥＢサービス１０側がユーザに提示する、サービスに必要な認証方式や認証の強度の条件のことをいう。
認証モジュール３０は、認証モジュールドライバ２４、認証判定モジュール３１、および鍵処理保管領域Ｒ１を有する。図１８の場合、鍵処理保管領域Ｒ１は、ＷＥＢサービス認証用秘密鍵ＳＫ１のほか、メタデータサービス向け秘密鍵ＳＫ２を保管する。なお、認証モジュール３０は、様々な形態を許容されている。ＦＩＤＯのＵＡＦプロトコルが動作すれば、ハードウェアやソフトウェアでの実現は問わない。また、端末２０に備え付けのものでもよいし、取り外せるものでもよい。
認証判定モジュール３１は、ユーザが予め認証モジュールに登録しておいた、Credentialを用いて、ユーザの認証の際に、ユーザから提示された情報が、Credential 情報と照合し良否を判定する。以降では、ＰＩＮコードや生体情報等の、ユーザを認証するための情報をCredential（クレデンシャル）と呼ぶ。ユーザから提示された情報が、Credential情報と照合して良であれば、秘密鍵・公開鍵の生成許可（ＷＥＢサービス１０への登録時）か、秘密鍵の利用許可（ＷＥＢサービス１０への認証時）を与える。
鍵処理保管領域Ｒ１は、鍵の生成や署名、暗号化、復号といった鍵の関する処理と、鍵の処理に必要な鍵自体を保存する機能を有する。
鍵処理保管領域Ｒ１は、鍵の生成や署名、暗号化、復号といった鍵の関する処理と、鍵の処理に必要な鍵自体を保存する機能を有する。
ここで、鍵の種別について説明する。
鍵は、ＷＥＢサービス向け公開鍵・秘密鍵と、メタデータサービス向け公開鍵・秘密鍵との２種類がある。
ＷＥＢサービス向け公開鍵・秘密鍵は、ＷＥＢサービス毎、アカウント毎に異なる鍵を生成する。
また、メタデータサービス向け公開鍵・秘密鍵は、認証モジュールのモデル（認証方式や鍵の保管領域などが定められた仕様）ごとに発行する。ＦＩＤＯの認証モジュールとして認証を得たタイミングで、秘密鍵・公開鍵を生成する。秘密鍵は認証モジュールに埋め込んで出荷する。
鍵は、ＷＥＢサービス向け公開鍵・秘密鍵と、メタデータサービス向け公開鍵・秘密鍵との２種類がある。
ＷＥＢサービス向け公開鍵・秘密鍵は、ＷＥＢサービス毎、アカウント毎に異なる鍵を生成する。
また、メタデータサービス向け公開鍵・秘密鍵は、認証モジュールのモデル（認証方式や鍵の保管領域などが定められた仕様）ごとに発行する。ＦＩＤＯの認証モジュールとして認証を得たタイミングで、秘密鍵・公開鍵を生成する。秘密鍵は認証モジュールに埋め込んで出荷する。
ＦＩＤＯ認証の特徴は、下記の通りである。
ＷＥＢサービス１０毎に求めるユーザの認証レベルが異なるため、多様な認証レベルに対応する必要があり、ＷＥＢサービス１０側で認証方式（ＰＩＮ、指紋、虹彩等のユーザを識別する方式）等を設定できるようになっている。
端末２０のユーザは、ＷＥＢサービス１０側で指定された認証ポリシーを満たす、認証判定モジュールを搭載した認証判定モジュール３１を利用する必要がある。ＷＥＢサービス１０側は、どのモデルの認証モジュールが利用されたか、メタデータサービス１を利用して検証できるようになっている。
ＷＥＢサービス１０毎に求めるユーザの認証レベルが異なるため、多様な認証レベルに対応する必要があり、ＷＥＢサービス１０側で認証方式（ＰＩＮ、指紋、虹彩等のユーザを識別する方式）等を設定できるようになっている。
端末２０のユーザは、ＷＥＢサービス１０側で指定された認証ポリシーを満たす、認証判定モジュールを搭載した認証判定モジュール３１を利用する必要がある。ＷＥＢサービス１０側は、どのモデルの認証モジュールが利用されたか、メタデータサービス１を利用して検証できるようになっている。
<ＦＩＤＯAllianceの利用手順>
図１９は、ＦＩＤＯAllianceの利用手順を説明する図である。
（手順１）事前登録
図１９に示すように、認証モジュール３０にＰＩＮコードや生体情報を登録する。
図１９は、ＦＩＤＯAllianceの利用手順を説明する図である。
（手順１）事前登録
図１９に示すように、認証モジュール３０にＰＩＮコードや生体情報を登録する。
（手順２）ＷＥＢサービスでのアカウント生成
図１９に示すように、アカウント入力フォームに情報を入力し、ＷＥＢサービス１０側で本人確認を行う。ＩＤ（ログイン名など）とパスワードを設定する。
図１９に示すように、アカウント入力フォームに情報を入力し、ＷＥＢサービス１０側で本人確認を行う。ＩＤ（ログイン名など）とパスワードを設定する。
（手順３）ＷＥＢサービスのＦＩＤＯ方式への認証方法の切替
図１９に示すように、パスワードによりＷＥＢサービス１０にログインし、ＦＩＤＯ方式の認証に切替処理を実行する。ＷＥＢサービス１０に登録する際、認証モジュール３０でユーザの認証を行う。問題がなければ、認証モジュール３０内で公開鍵ＰＫ１・秘密鍵ＳＫ１のペアを生成し、公開鍵ＰＫ１をＷＥＢサービス１０へ送付する。公開鍵ＰＫ１は、メタデータサービス向けの秘密鍵ＳＫ２で署名して送付する。ＷＥＢサービス１０側で、メタデータを参照し、メタデータサービス１にある公開鍵ＰＫ２で検証する。
図１９に示すように、パスワードによりＷＥＢサービス１０にログインし、ＦＩＤＯ方式の認証に切替処理を実行する。ＷＥＢサービス１０に登録する際、認証モジュール３０でユーザの認証を行う。問題がなければ、認証モジュール３０内で公開鍵ＰＫ１・秘密鍵ＳＫ１のペアを生成し、公開鍵ＰＫ１をＷＥＢサービス１０へ送付する。公開鍵ＰＫ１は、メタデータサービス向けの秘密鍵ＳＫ２で署名して送付する。ＷＥＢサービス１０側で、メタデータを参照し、メタデータサービス１にある公開鍵ＰＫ２で検証する。
（手順４）ＦＩＤＯ方式での認証
図１９に示すように、ＷＥＢサービス１０側から認証要求があるため、認証モジュール３０でユーザの認証を実行する。問題がなければ、鍵処理保管領域Ｒ１の秘密鍵ＳＫ１，ＳＫ２へのアクセス許可を与え、秘密鍵ＳＫ１，ＳＫ２で署名を行い、ＷＥＢサービス１０側へ返す。ＷＥＢサービス１０側では、アカウント１１に紐付けてある、公開鍵ＰＫ１で署名が検証できれば、認証ＯＫと判定する。
図１９に示すように、ＷＥＢサービス１０側から認証要求があるため、認証モジュール３０でユーザの認証を実行する。問題がなければ、鍵処理保管領域Ｒ１の秘密鍵ＳＫ１，ＳＫ２へのアクセス許可を与え、秘密鍵ＳＫ１，ＳＫ２で署名を行い、ＷＥＢサービス１０側へ返す。ＷＥＢサービス１０側では、アカウント１１に紐付けてある、公開鍵ＰＫ１で署名が検証できれば、認証ＯＫと判定する。
<公開鍵を用いた認証（ＦＩＤＯ）の問題点>
図２０は、公開鍵を用いた認証（ＦＩＤＯ）の問題点を説明する図である。
公開鍵を用いた認証（ＦＩＤＯ）では、認証デバイスに鍵を閉じ込めているため、認証デバイスを紛失すると秘密鍵も失う、という問題点がある。
具体的には、図２０（ａ）に示すように、認証モジュール３０が取り付けられた端末２０が、ＦＩＤＯの認証を行い、ＷＥＢサービス１０を利用する場合において、諸事情により認証モジュール３０を紛失（秘密鍵ＳＫ１も紛失）したとする。このとき、新しい認証モジュールを（新）認証モジュール３０Ａとして用意し、端末２０に（新）認証モジュール３０Ａを取り付けたとしても、図２０（ｂ）に示すように、ＷＥＢサービス１０が保持する公開鍵ＰＫ１のペアとなる秘密鍵は、（新）認証モジュール３０Ａには無い（作り出すこともできない）。その結果、端末２０のユーザは、秘密鍵ＳＫ１の紛失前から継続する態様でＷＥＢサービス１０を利用することはできない。
ＦＩＤＯでは、鍵の新規登録については規定されているが、鍵の紛失時の対応策については標準化技術では規定されておらず、上記の問題点に対処していない。
図２０は、公開鍵を用いた認証（ＦＩＤＯ）の問題点を説明する図である。
公開鍵を用いた認証（ＦＩＤＯ）では、認証デバイスに鍵を閉じ込めているため、認証デバイスを紛失すると秘密鍵も失う、という問題点がある。
具体的には、図２０（ａ）に示すように、認証モジュール３０が取り付けられた端末２０が、ＦＩＤＯの認証を行い、ＷＥＢサービス１０を利用する場合において、諸事情により認証モジュール３０を紛失（秘密鍵ＳＫ１も紛失）したとする。このとき、新しい認証モジュールを（新）認証モジュール３０Ａとして用意し、端末２０に（新）認証モジュール３０Ａを取り付けたとしても、図２０（ｂ）に示すように、ＷＥＢサービス１０が保持する公開鍵ＰＫ１のペアとなる秘密鍵は、（新）認証モジュール３０Ａには無い（作り出すこともできない）。その結果、端末２０のユーザは、秘密鍵ＳＫ１の紛失前から継続する態様でＷＥＢサービス１０を利用することはできない。
ＦＩＤＯでは、鍵の新規登録については規定されているが、鍵の紛失時の対応策については標準化技術では規定されておらず、上記の問題点に対処していない。
<図２０の問題点の解決の方向性>
図２１は、図２０の問題点の解決の方向性を説明する図である。
図２１に示すように、ＷＥＢサービス１０のＷＥＢサービス認証用公開鍵ＰＫ１のペアとなるＷＥＢサービス認証用秘密鍵ＳＫ１を、インターネット上のサーバ（以降では、認証鍵リレー型キーストア４０と呼ぶ）に保管する。この秘密鍵ＳＫ１と認証モジュール３０の関係を認証鍵リレー型キーストア４０で保持する。つまり、これまではＦＩＤＯプロトコルに従って認証モジュール内で実行していた秘密鍵に関する処理を、認証鍵リレー型キーストア４０側で実行するようなシステムを提案する。
図２１は、図２０の問題点の解決の方向性を説明する図である。
図２１に示すように、ＷＥＢサービス１０のＷＥＢサービス認証用公開鍵ＰＫ１のペアとなるＷＥＢサービス認証用秘密鍵ＳＫ１を、インターネット上のサーバ（以降では、認証鍵リレー型キーストア４０と呼ぶ）に保管する。この秘密鍵ＳＫ１と認証モジュール３０の関係を認証鍵リレー型キーストア４０で保持する。つまり、これまではＦＩＤＯプロトコルに従って認証モジュール内で実行していた秘密鍵に関する処理を、認証鍵リレー型キーストア４０側で実行するようなシステムを提案する。
<図２１の課題>
図２２は、図２１の課題を説明する図である。
図２２（ａ）に示すように、認証判定モジュール３１、および、秘密鍵ＳＫ１を保管する鍵処理保管領域Ｒ１が、認証モジュール３０内に閉じている。このため、ＷＥＢサービス認証用秘密鍵ＳＫ１が端末２０の認証モジュール３０側にある場合、認証判定モジュール３１によるユーザの認証結果と、秘密鍵ＳＫ１の処理とが関連付いていることが保証されている。
図２２は、図２１の課題を説明する図である。
図２２（ａ）に示すように、認証判定モジュール３１、および、秘密鍵ＳＫ１を保管する鍵処理保管領域Ｒ１が、認証モジュール３０内に閉じている。このため、ＷＥＢサービス認証用秘密鍵ＳＫ１が端末２０の認証モジュール３０側にある場合、認証判定モジュール３１によるユーザの認証結果と、秘密鍵ＳＫ１の処理とが関連付いていることが保証されている。
しかし、図２２（ｂ）に示すように、ＷＥＢサービス認証用秘密鍵ＳＫ１が認証鍵リレー型キーストア４０側にある場合、秘密鍵ＳＫ１が鍵処理保管領域Ｒ１に無いため、認証判定モジュール３１によるユーザの認証結果と、秘密鍵ＳＫ１の処理とが関連付いていることが保証されない。このため、ＷＥＢサービス１０は、秘密鍵ＳＫ１による署名を受け取ったとしても、その署名が、認証判定モジュール３１が正しく認証したことに起因する結果物であるのか、認証判定モジュール３１を介することなく認証鍵リレー型キーストア４０にアクセスし、秘密鍵ＳＫ１の処理がなされたことに起因する結果物であるのか、判別できない。その結果、認証鍵リレー型キーストア４０内のＷＥＢサービス認証用秘密鍵ＳＫ１を不正に利用し、なりすましが行われる場合がある。
［認証システムの構成］
図１は、本実施形態の認証システムを示す全体構成図である。図１に示すように、本実施形態の認証システム１００は、ＷＥＢサービス１０と、端末２０と、認証モジュール３０（認証デバイス）と、認証鍵リレー型キーストア４０（キーストア）と、メタデータサービス１と、認証局５０と、を備える。
図１は、本実施形態の認証システムを示す全体構成図である。図１に示すように、本実施形態の認証システム１００は、ＷＥＢサービス１０と、端末２０と、認証モジュール３０（認証デバイス）と、認証鍵リレー型キーストア４０（キーストア）と、メタデータサービス１と、認証局５０と、を備える。
<ＷＥＢサービス>
ＷＥＢサービス１０は、ＷＥＢサイトをオンライン上に有しており、端末２０が利用して、端末２０のユーザに対して所定のサービス（ＷＥＢサービス）を提供する。ＷＥＢサービス１０は、ＷＥＢサービスアプリケーション１３と、ＦＩＤＯサーバ１５とを有する。
ＷＥＢサービス１０は、ＷＥＢサイトをオンライン上に有しており、端末２０が利用して、端末２０のユーザに対して所定のサービス（ＷＥＢサービス）を提供する。ＷＥＢサービス１０は、ＷＥＢサービスアプリケーション１３と、ＦＩＤＯサーバ１５とを有する。
ＷＥＢサービスアプリケーション１３は、ＷＥＢサービスに供するプロセスを実行するアプリケーションである。ＷＥＢサービスアプリケーション１３は、ユーザごとに作成されたアカウント１１を格納するユーザ管理ＤＢ１４を有する。
ＦＩＤＯサーバ１５は、ＦＩＤＯによる認証を行うサーバである。ＦＩＤＯサーバ１５は、ＷＥＢサービス認証用公開鍵ＰＫ１を格納する鍵管理領域１６を有する。
ＷＥＢサービス認証用公開鍵ＰＫ１は、ＷＥＢサービスを利用する端末２０のユーザを認証するときに利用される公開鍵である。
また、ＦＩＤＯサーバ１５は、メタデータサービス１の認証モジュールの情報３を参照することができる。
ＷＥＢサービス認証用公開鍵ＰＫ１は、ＷＥＢサービスを利用する端末２０のユーザを認証するときに利用される公開鍵である。
また、ＦＩＤＯサーバ１５は、メタデータサービス１の認証モジュールの情報３を参照することができる。
<端末>
端末１２０は、スマートホン，携帯電話，タブレット等の携帯端末、ノート型／デスクトップ型ＰＣ、各種電子機器である。本実施形態では、スマートホンを例に採る。端末２０は、ブラウザ・アプリ２１と、ＦＩＤＯクライアント２２と、認証管理情報２３と、認証モジュールドライバ２４と、端末側連携認証機能２５と、画面ロック解除機能２６と、ＯＳ用アカウント管理機能２７と、ＯＳ鍵処理保管領域Ｒ２と、を備える。端末１２０は、ユーザ認証を行う認証モジュール３０を備える。
端末１２０は、スマートホン，携帯電話，タブレット等の携帯端末、ノート型／デスクトップ型ＰＣ、各種電子機器である。本実施形態では、スマートホンを例に採る。端末２０は、ブラウザ・アプリ２１と、ＦＩＤＯクライアント２２と、認証管理情報２３と、認証モジュールドライバ２４と、端末側連携認証機能２５と、画面ロック解除機能２６と、ＯＳ用アカウント管理機能２７と、ＯＳ鍵処理保管領域Ｒ２と、を備える。端末１２０は、ユーザ認証を行う認証モジュール３０を備える。
ブラウザ・アプリ２１は、ＷＥＢサービス１０のＷＥＢサイトを閲覧させる。
ＦＩＤＯクライアント２２は、ＦＩＤＯによる認証に要する処理をＦＩＤＯサーバ１５に要求する。
認証管理情報２３は、ユーザを認証するためのさまざまな値を関連付けて管理する情報である。認証管理情報２３の詳細は、後記する。
認証モジュールドライバ２４は、端末２０が認証モジュール３０の処理を制御するためのドライバである。
ＦＩＤＯクライアント２２は、ＦＩＤＯによる認証に要する処理をＦＩＤＯサーバ１５に要求する。
認証管理情報２３は、ユーザを認証するためのさまざまな値を関連付けて管理する情報である。認証管理情報２３の詳細は、後記する。
認証モジュールドライバ２４は、端末２０が認証モジュール３０の処理を制御するためのドライバである。
端末側連携認証機能２５は、端末２０側で、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１（後記）と所定の情報のやり取りを行う。なお、「ＫＳ」はキーストア（Key Store）の略記である。端末側連携認証機能２５は、認証モジュール認証用公開鍵ＰＫ３を利用する。端末側連携認証機能２５は、やり取りする情報を暗号化することができる（詳細は後記）。
認証モジュール認証用公開鍵ＰＫ３は、認証モジュール３０を認証するときに用いられる公開鍵である（詳細は後記）。
なお、端末側連携認証機能２５は、端末２０のＯＳ側（Operating System：オペレーティングシステム。図示せず。）に実装してもよいし、認証モジュール３０側に実装してもよい。
認証モジュール認証用公開鍵ＰＫ３は、認証モジュール３０を認証するときに用いられる公開鍵である（詳細は後記）。
なお、端末側連携認証機能２５は、端末２０のＯＳ側（Operating System：オペレーティングシステム。図示せず。）に実装してもよいし、認証モジュール３０側に実装してもよい。
画面ロック解除機能２６は、端末２０の画面ロックを解除する。画面ロックは、端末２０の電源投入後または、スリープ状態からの復帰後、所定の画面（例：ホーム画面）を表示するために、ユーザにパスワードやパターンの入力を求める機能である。画面ロック解除機能２６が画面ロックの設定の処理を行ってもよい。
ＯＳ用アカウント管理機能２７は、端末２０のＯＳ（Operating System：オペレーティングシステム。図示せず。）が、ユーザのアカウントを管理できるようにする。ＯＳ用アカウント管理機能２７は、アカウント管理情報２８を備える。アカウント管理情報２８は、端末２０のＯＳにて、ユーザのアカウントを管理するための様々な値を関連付けて管理する情報である。アカウント管理情報２８の詳細は、後記する。
ＯＳ鍵処理保管領域Ｒ２は、端末２０のＯＳによって保管される様々な種類の鍵を管理する。ＯＳ鍵処理保管領域Ｒ２には、認証モジュールアサーションキーＡＫ２と、端末側認証モジュール毎の対称鍵ＳＹＫ１が保管されている。
認証モジュールアサーションキーＡＫ２は、ユーザ認証のアサーションを暗号化・復号化する共通鍵である。
端末側認証モジュール毎の対称鍵ＳＹＫ１は、端末２０側にて、認証モジュール３０ごとに用意されている対称鍵である。
ＯＳ鍵処理保管領域Ｒ２は、耐タンパー性があり、鍵に関する処理（鍵の生成、署名検証、証明生成、暗号化、復号化など）が可能なモジュールであることが好ましい。しかし、鍵の保管と鍵の処理を限られた領域内のみで実行するのであれば、ソフトウェアなどでの実装でもよい。
認証モジュールアサーションキーＡＫ２は、ユーザ認証のアサーションを暗号化・復号化する共通鍵である。
端末側認証モジュール毎の対称鍵ＳＹＫ１は、端末２０側にて、認証モジュール３０ごとに用意されている対称鍵である。
ＯＳ鍵処理保管領域Ｒ２は、耐タンパー性があり、鍵に関する処理（鍵の生成、署名検証、証明生成、暗号化、復号化など）が可能なモジュールであることが好ましい。しかし、鍵の保管と鍵の処理を限られた領域内のみで実行するのであれば、ソフトウェアなどでの実装でもよい。
<認証モジュール>
認証モジュール３０は、端末２０のユーザを認証するための認証デバイスである。認証モジュール３０は、認証判定モジュール３１と、鍵処理保管領域Ｒ１と、を有する。
認証判定モジュール３１は、あらかじめ登録されたCredentialを用いて、ユーザ認証の際、ユーザから提示された情報がCredentialに一致すれば、鍵処理保管領域Ｒ１へのアクセスが許可される。
鍵処理保管領域Ｒ１は、認証モジュール３０よって保管される様々な種類の鍵を管理する。鍵処理保管領域Ｒ１には、メタデータサービス向け秘密鍵ＳＫ２と、認証モジュールアサーションキーＡＫ１と、が保管されている。
メタデータサービス向け秘密鍵ＳＫ２は、認証モジュール３０が、メタデータサービス１の認証モジュールの情報３を利用するための秘密鍵である。
認証モジュールアサーションキーＡＫ１は、ユーザ認証のアサーションを暗号化・復号化する共通鍵である。
鍵処理保管領域Ｒ１は、耐タンパー性があり、鍵に関する処理（鍵の生成、署名検証、証明生成、暗号化、復号化など）が可能なモジュールであることが好ましい。しかし、鍵の保管と鍵の処理を限られた領域内のみで実行するのであれば、ソフトウェアなどでの実装でもよい。
認証モジュール３０は、端末２０のユーザを認証するための認証デバイスである。認証モジュール３０は、認証判定モジュール３１と、鍵処理保管領域Ｒ１と、を有する。
認証判定モジュール３１は、あらかじめ登録されたCredentialを用いて、ユーザ認証の際、ユーザから提示された情報がCredentialに一致すれば、鍵処理保管領域Ｒ１へのアクセスが許可される。
鍵処理保管領域Ｒ１は、認証モジュール３０よって保管される様々な種類の鍵を管理する。鍵処理保管領域Ｒ１には、メタデータサービス向け秘密鍵ＳＫ２と、認証モジュールアサーションキーＡＫ１と、が保管されている。
メタデータサービス向け秘密鍵ＳＫ２は、認証モジュール３０が、メタデータサービス１の認証モジュールの情報３を利用するための秘密鍵である。
認証モジュールアサーションキーＡＫ１は、ユーザ認証のアサーションを暗号化・復号化する共通鍵である。
鍵処理保管領域Ｒ１は、耐タンパー性があり、鍵に関する処理（鍵の生成、署名検証、証明生成、暗号化、復号化など）が可能なモジュールであることが好ましい。しかし、鍵の保管と鍵の処理を限られた領域内のみで実行するのであれば、ソフトウェアなどでの実装でもよい。
<認証鍵リレー型キーストア>
認証鍵リレー型キーストア４０は、ＷＥＢサービス認証用秘密鍵ＳＫ１などの鍵をオンライン上（インターネット側）で保管するサーバである。認証鍵リレー型キーストア４０は、ＫＳ側連携認証機能４１と、ユーザ管理ＤＢ４２と、アカウント管理ＷＥＢアプリ４３と、耐タンパー領域Ｒ３と、サーバ証明書ＣＥ１と、を備える。
認証鍵リレー型キーストア４０は、ＷＥＢサービス認証用秘密鍵ＳＫ１などの鍵をオンライン上（インターネット側）で保管するサーバである。認証鍵リレー型キーストア４０は、ＫＳ側連携認証機能４１と、ユーザ管理ＤＢ４２と、アカウント管理ＷＥＢアプリ４３と、耐タンパー領域Ｒ３と、サーバ証明書ＣＥ１と、を備える。
ＫＳ側連携認証機能４１は、認証鍵リレー型キーストア４０側で、端末２０の端末側連携認証機能２５と所定の情報のやり取りを行う。ＫＳ側連携認証機能４１は、やり取りする情報を暗号化することができる（詳細は後記）。
ユーザ管理ＤＢ４２は、端末２０のユーザに関する情報を格納する。
アカウント管理ＷＥＢアプリ４３は、ユーザ管理ＤＢ４２に格納された情報について、読み出したり、書き換えたりして管理する。
ユーザ管理ＤＢ４２は、端末２０のユーザに関する情報を格納する。
アカウント管理ＷＥＢアプリ４３は、ユーザ管理ＤＢ４２に格納された情報について、読み出したり、書き換えたりして管理する。
耐タンパー領域Ｒ３は、認証モジュール３０よって保管される様々な種類の鍵を管理する。鍵処理保管領域Ｒ１には、ＷＥＢサービス認証用秘密鍵ＳＫ１と、認証モジュール認証用秘密鍵ＳＫ３と、サーバの秘密鍵ＳＫ４と、ＫＳ側認証モジュール毎の対称鍵ＳＹＫ２と、が保管されている。
ＷＥＢサービス認証用秘密鍵ＳＫ１は、ＷＥＢサービスを利用する端末２０のユーザを認証するときに利用される秘密鍵である。ＷＥＢサービス認証用秘密鍵ＳＫ１は、ＷＥＢサービス認証用公開鍵ＰＫ１と対をなす。
認証モジュール認証用秘密鍵ＳＫ３は、認証モジュール３０を認証するときに用いられる秘密鍵である（詳細は後記）。認証モジュール認証用秘密鍵ＳＫ３は、認証モジュール認証用公開鍵ＰＫ３と対をなす。図１に示すように、端末２０が認証モジュール認証用公開鍵ＰＫ３を有し、認証鍵リレー型キーストア４０が認証モジュール認証用秘密鍵ＳＫ３を有するという鍵の持ち合いが実現される。
サーバの秘密鍵ＳＫ４は、サーバ証明書ＣＥ１に示される署名に用いられる秘密鍵である。
ＫＳ側認証モジュール毎の対称鍵ＳＹＫ２は、認証鍵リレー型キーストア４０側にて、認証モジュール３０ごとに用意されている対称鍵である。
耐タンパー領域Ｒ３は、耐タンパー性があり、鍵に関する処理（鍵の生成、署名検証、証明生成、暗号化、復号化など）が可能なモジュールであることが好ましい。しかし、鍵の保管と鍵の処理を限られた領域内のみで実行するのであれば、ソフトウェアなどでの実装でもよい。
ＷＥＢサービス認証用秘密鍵ＳＫ１は、ＷＥＢサービスを利用する端末２０のユーザを認証するときに利用される秘密鍵である。ＷＥＢサービス認証用秘密鍵ＳＫ１は、ＷＥＢサービス認証用公開鍵ＰＫ１と対をなす。
認証モジュール認証用秘密鍵ＳＫ３は、認証モジュール３０を認証するときに用いられる秘密鍵である（詳細は後記）。認証モジュール認証用秘密鍵ＳＫ３は、認証モジュール認証用公開鍵ＰＫ３と対をなす。図１に示すように、端末２０が認証モジュール認証用公開鍵ＰＫ３を有し、認証鍵リレー型キーストア４０が認証モジュール認証用秘密鍵ＳＫ３を有するという鍵の持ち合いが実現される。
サーバの秘密鍵ＳＫ４は、サーバ証明書ＣＥ１に示される署名に用いられる秘密鍵である。
ＫＳ側認証モジュール毎の対称鍵ＳＹＫ２は、認証鍵リレー型キーストア４０側にて、認証モジュール３０ごとに用意されている対称鍵である。
耐タンパー領域Ｒ３は、耐タンパー性があり、鍵に関する処理（鍵の生成、署名検証、証明生成、暗号化、復号化など）が可能なモジュールであることが好ましい。しかし、鍵の保管と鍵の処理を限られた領域内のみで実行するのであれば、ソフトウェアなどでの実装でもよい。
サーバ証明書ＣＥ１は、認証局５０が発行した電子証明書であり、ＷＥＢサイト所有者の情報・送信情報の暗号化に必要な鍵・証明書発行者の署名データを持つ。
<メタデータサービス>
メタデータサービス１は、さまざまな種類が存在する認証モジュールに関する情報を、認証モジュールの情報３として管理する。認証モジュールの情報３の詳細については後記する。
メタデータサービス１は、メタデータサービス向け公開鍵ＰＫ２を用いて認証モジュールの情報３を保管する。ＷＥＢサービス１０のＦＩＤＯサーバ１５は、認証モジュールの情報３を参照することができる。認証鍵リレー型キーストア４０は、認証モジュールの情報３を参照することができる。メタデータサービス向け公開鍵ＰＫ２は、メタデータサービス向け秘密鍵ＳＫ２と対をなす。
メタデータサービス１は、さまざまな種類が存在する認証モジュールに関する情報を、認証モジュールの情報３として管理する。認証モジュールの情報３の詳細については後記する。
メタデータサービス１は、メタデータサービス向け公開鍵ＰＫ２を用いて認証モジュールの情報３を保管する。ＷＥＢサービス１０のＦＩＤＯサーバ１５は、認証モジュールの情報３を参照することができる。認証鍵リレー型キーストア４０は、認証モジュールの情報３を参照することができる。メタデータサービス向け公開鍵ＰＫ２は、メタデータサービス向け秘密鍵ＳＫ２と対をなす。
<認証局>
認証局５０は、他の当事者にデジタル公開鍵証明書を発行する実体である。認証局５０は、サーバ証明書ＣＥ２と、サーバの公開鍵ＰＫ４とを有する。
サーバ証明書ＣＥ２は、サーバ証明書ＣＥ１と同等である。
サーバの公開鍵ＰＫ４は、サーバ証明書ＣＥ１に示される署名に用いられる秘密鍵である。サーバの公開鍵ＰＫ４は、サーバの秘密鍵ＳＫ４と対をなす。
認証局５０は、他の当事者にデジタル公開鍵証明書を発行する実体である。認証局５０は、サーバ証明書ＣＥ２と、サーバの公開鍵ＰＫ４とを有する。
サーバ証明書ＣＥ２は、サーバ証明書ＣＥ１と同等である。
サーバの公開鍵ＰＫ４は、サーバ証明書ＣＥ１に示される署名に用いられる秘密鍵である。サーバの公開鍵ＰＫ４は、サーバの秘密鍵ＳＫ４と対をなす。
［データの保持形式］
次に、データの保持形式について説明する。
<メタデータサービスの認証モジュールの情報>
図２は、メタデータサービス１の認証モジュールの情報３の構造図である。
図２に示すように、認証モジュールの情報３は、認証モジュールモデルＩＤ（３ａ）毎に、認証方式３ｂ、メタデータサービス向け公開鍵ＩＤ（３ｃ）、認証モジュールの実装形態３ｄ、鍵処理保管領域の実装形態３ｅ、鍵の保管領域３ｆ、および認証精度３ｇを有する。本実施形態では、認証モジュールの情報３が、図２の太枠で囲んだ鍵の保管領域３ｆを持つことを特徴とする。
次に、データの保持形式について説明する。
<メタデータサービスの認証モジュールの情報>
図２は、メタデータサービス１の認証モジュールの情報３の構造図である。
図２に示すように、認証モジュールの情報３は、認証モジュールモデルＩＤ（３ａ）毎に、認証方式３ｂ、メタデータサービス向け公開鍵ＩＤ（３ｃ）、認証モジュールの実装形態３ｄ、鍵処理保管領域の実装形態３ｅ、鍵の保管領域３ｆ、および認証精度３ｇを有する。本実施形態では、認証モジュールの情報３が、図２の太枠で囲んだ鍵の保管領域３ｆを持つことを特徴とする。
認証モジュールモデルＩＤ（３ａ）は、認証方式３ｂ、メタデータサービス向け公開鍵ＩＤ（３ｃ）、認証モジュールの実装形態３ｄ、鍵処理保管領域の実装形態３ｅ、鍵の保管領域３ｆ、および認証精度３ｇによって規定される認証モジュール３０の仕様（モデル）の識別子である。認証モジュールモデルＩＤ（３ａ）は、例えば、1111#aaaa，0000#dddd，…など９桁の英数文字列で表すことができる。
認証方式３ｂは、認証モジュール３０が採用する認証方式の名称である。
メタデータサービス向け公開鍵ＩＤ（３ｃ）は、該当の認証モジュールモデルに紐付けられているメタデータサービス向け公開鍵ＰＫ２の識別子である。
メタデータサービス向け公開鍵ＩＤ（３ｃ）は、該当の認証モジュールモデルに紐付けられているメタデータサービス向け公開鍵ＰＫ２の識別子である。
認証モジュールの実装形態３ｄおよび鍵の保管領域の実装形態３ｅは、ハードウェアまたはソフトウェアにより実装される。ハードウェア実装は、ソフトウェア実装よりもセキュリティレベルが高い。
鍵の保管領域３ｆは、ＷＥＢサービス認証用秘密鍵ＳＫ１の保管場所を特定し、本実施形態では、認証モジュール３０内（具体的には、鍵処理保管領域Ｒ１）か、認証鍵リレー型キーストア（具体的には、耐タンパー領域Ｒ３）のいずれかである。認証モジュールの情報３に鍵の保管領域３ｆを設定することにより、ＷＥＢサービス１０が、ＷＥＢサービス１０自身の認証に求める要件を満たす認証モジュール３０を選択することができる。具体的には、ＷＥＢサービス１０の提供に求められるセキュリティレベルを満たすことができる認証方式をＷＥＢサイトの事業者が選択することができる。また、必要とするセキュリティレベルがそれぞれ異なる多様なＷＥＢサービスの認証要件に応じることができる。
鍵の保管領域３ｆは、ＷＥＢサービス認証用秘密鍵ＳＫ１の保管場所を特定し、本実施形態では、認証モジュール３０内（具体的には、鍵処理保管領域Ｒ１）か、認証鍵リレー型キーストア（具体的には、耐タンパー領域Ｒ３）のいずれかである。認証モジュールの情報３に鍵の保管領域３ｆを設定することにより、ＷＥＢサービス１０が、ＷＥＢサービス１０自身の認証に求める要件を満たす認証モジュール３０を選択することができる。具体的には、ＷＥＢサービス１０の提供に求められるセキュリティレベルを満たすことができる認証方式をＷＥＢサイトの事業者が選択することができる。また、必要とするセキュリティレベルがそれぞれ異なる多様なＷＥＢサービスの認証要件に応じることができる。
認証精度３ｇは、認証モジュールモデルから決定することができる。例えば、ＰＩＮ入力は、５桁の数字である。また、指紋認証、虹彩認証など生体認証システムの精度は、ＦＲＲ（False Rejection：本人拒否率）とＦＡＲ（False Acceptance：他人受入率）の組合せで評価される。
なお、図２に示す認証モジュールの情報３は、一例であって、上記の情報の一部を削除したり、他の情報を追加したりすることができる。
［端末側が保持する情報］
次に、端末２０側が保持する情報について説明する。端末２０側が保持する情報は、具体的には、認証管理情報２３と、アカウント管理情報２８である。
図３は、端末が保持する情報の構造図である。図３では木構造として示されている。図３の説明（および後記する図４の説明）において、「ｘｘのＩＤ」と「ｙｙのＩＤ」とが線で結ばれる場合、当該線に付された「１…１」は、１つのｘｘのＩＤには１つｙｙのＩＤが対応していることを示す。また、「ｘｘのＩＤ」と「ｙｙのＩＤ」とが線で結ばれる場合、当該線に付された「１…ｎ（ｎは２以上の整数）」は、１つのｘｘのＩＤには複数のｙｙのＩＤが対応していることを示す。
次に、端末２０側が保持する情報について説明する。端末２０側が保持する情報は、具体的には、認証管理情報２３と、アカウント管理情報２８である。
図３は、端末が保持する情報の構造図である。図３では木構造として示されている。図３の説明（および後記する図４の説明）において、「ｘｘのＩＤ」と「ｙｙのＩＤ」とが線で結ばれる場合、当該線に付された「１…１」は、１つのｘｘのＩＤには１つｙｙのＩＤが対応していることを示す。また、「ｘｘのＩＤ」と「ｙｙのＩＤ」とが線で結ばれる場合、当該線に付された「１…ｎ（ｎは２以上の整数）」は、１つのｘｘのＩＤには複数のｙｙのＩＤが対応していることを示す。
<認証管理情報>
図３（ａ）に示すように、端末２０側が保持する認証管理情報２３は、ＷＥＢサービスのアプリケーションＩＤ（２３ａ）と、ＷＥＢサービスのユーザＩＤ（２３ｂ）と、認証モジュールモデルＩＤ（２３ｃ）と、ＷＥＢサービス認証用秘密鍵のＩＤ（２３ｄ）と、認証モジュール認証用公開鍵のＩＤ（２３ｅ）と、認証鍵リレー型キーストアのユーザＩＤ（２３ｆ）と、認証鍵リレー型キーストアのＵＲＬ（Uniform Resource Locator）（２３ｇ）と、を有する。
図３（ａ）に示すように、端末２０側が保持する認証管理情報２３は、ＷＥＢサービスのアプリケーションＩＤ（２３ａ）と、ＷＥＢサービスのユーザＩＤ（２３ｂ）と、認証モジュールモデルＩＤ（２３ｃ）と、ＷＥＢサービス認証用秘密鍵のＩＤ（２３ｄ）と、認証モジュール認証用公開鍵のＩＤ（２３ｅ）と、認証鍵リレー型キーストアのユーザＩＤ（２３ｆ）と、認証鍵リレー型キーストアのＵＲＬ（Uniform Resource Locator）（２３ｇ）と、を有する。
ＷＥＢサービスのアプリケーションＩＤ（２３ａ）は、ＷＥＢサービス１０のＷＥＢサービスアプリ１３の識別子であり、ＦＩＤＯで規定される。例えば、ＷＥＢサービスのアプリケーションＩＤ（２３ａ）は、例えば、ＷＥＢサービス１０のＵＲＬまたはそのＵＲＬのハッシュ値とすることができる。ＷＥＢサービスのアプリケーションＩＤ（２３ａ）は、最上位に位置し、その１つ下位のＷＥＢサービスのユーザＩＤ（２３ｂ）に「１…ｎ」で対応する（ＷＥＢサービスのユーザＩＤ（２３ｂ）が「ｎ（複数）」に相当）。
ＷＥＢサービスのユーザＩＤ（２３ｂ）は、ＷＥＢサービス１０を利用するユーザ（ユーザ管理ＤＢ１４に登録済み）の識別子である。ＷＥＢサービスのユーザＩＤ（２３ｂ）は、その１つ下位の認証モジュールＩＤ（２３ｃ）に「１…ｎ」で対応する（認証モジュールＩＤが「ｎ（複数）」に相当）。また、ＷＥＢサービスのユーザＩＤ（２３ｂ）は、その１つ下位の認証鍵リレー型キーストアのユーザＩＤ（２３ｆ）に「１…１」で対応する。
認証モジュールモデルＩＤ（２３ｃ）は、認証モジュールの情報３の認証モジュールモデルＩＤ（３ａ）（図２参照）と同等である。認証モジュールモデルＩＤ（２３ｃ）は、ＷＥＢサービス認証用秘密鍵のＩＤ（２３ｄ）に「１…ｎ」で対応する（ＷＥＢサービス認証用秘密鍵のＩＤ（２３ｄ）が「ｎ（複数）」に相当）。また、認証モジュールモデルＩＤ（２３ｃ）は、その１つ下位の認証モジュール認証用公開鍵のＩＤ（２３ｅ）に「１…１」で対応する。
ＷＥＢサービス認証用秘密鍵のＩＤ（２３ｄ）は、ＷＥＢサービス認証用秘密鍵ＳＫ１の識別子である。
認証モジュール認証用公開鍵のＩＤ（２３ｅ）は、認証モジュール認証用公開鍵ＰＫ３の識別子である。
認証モジュール認証用公開鍵のＩＤ（２３ｅ）は、認証モジュール認証用公開鍵ＰＫ３の識別子である。
認証鍵リレー型キーストアのユーザＩＤ（２３ｆ）は、認証鍵リレー型キーストア４０を利用するユーザ（ユーザ管理ＤＢ４２に登録済み）の識別子である。認証鍵リレー型キーストアのユーザＩＤ（２３ｆ）は、その１つ下位の認証鍵リレー型キーストアのＵＲＬ（２３ｇ）に「１…１」で対応する。
認証鍵リレー型キーストアのＵＲＬ（２３ｇ）は、認証鍵リレー型キーストア４０の所在を示す。
認証鍵リレー型キーストアのＵＲＬ（２３ｇ）は、認証鍵リレー型キーストア４０の所在を示す。
なお、図３（ａ）に示す認証管理情報２３は、一例であって、上記の情報（ＩＤ）の一部を削除したり、他の情報を追加したりすることができる。
<アカウント管理情報>
また、図３（ｂ）に示すように、端末２０側が保持するアカウント管理情報２８は、ＯＳのユーザアカウント（２８ａ）と、認証モジュールアサーションキーＩＤ（２８ｂ）と、端末側認証モジュール毎の対称鍵ＩＤ（２８ｃ）と、認証モジュール認証用鍵ペアのＩＤ（２８ｄ）と、を有する。
また、図３（ｂ）に示すように、端末２０側が保持するアカウント管理情報２８は、ＯＳのユーザアカウント（２８ａ）と、認証モジュールアサーションキーＩＤ（２８ｂ）と、端末側認証モジュール毎の対称鍵ＩＤ（２８ｃ）と、認証モジュール認証用鍵ペアのＩＤ（２８ｄ）と、を有する。
ＯＳのユーザアカウント（２８ａ）は、端末２０のユーザに対して生成されたアカウントであり、ＷＥＢサービス１０のアカウント１１に相当する。ＯＳのユーザアカウント（２８ａ）は最上位に位置し、その１つ下位の認証モジュールアサーションキーＩＤ（２８ｂ）に「１…ｎ」で対応する（認証モジュールアサーションキーＩＤ（２８ｂ）が「ｎ（複数）」に相当）。
認証モジュールアサーションキーＩＤ（２８ｂ）は、認証モジュールアサーションキーＡＫ２の識別子である。認証モジュールアサーションキーＩＤ（２８ｂ）は、その１つ下位の端末側認証モジュール毎の対称鍵ＩＤ（２８ｃ）に「１…１」で対応する。
端末側認証モジュール毎の対称鍵ＩＤ（２８ｃ）は、端末側認証モジュール毎の対称鍵ＳＹＫ１の識別子である。端末側認証モジュール毎の対称鍵ＩＤ（２８ｃ）は、その１つ下位の認証モジュール認証用鍵ペアのＩＤ（２８ｄ）に「１…１」で対応する。
認証モジュール認証用鍵ペアのＩＤ（２８ｄ）は、認証モジュール認証用鍵（ＰＫ３，ＳＫ３）の識別子である。
端末側認証モジュール毎の対称鍵ＩＤ（２８ｃ）は、端末側認証モジュール毎の対称鍵ＳＹＫ１の識別子である。端末側認証モジュール毎の対称鍵ＩＤ（２８ｃ）は、その１つ下位の認証モジュール認証用鍵ペアのＩＤ（２８ｄ）に「１…１」で対応する。
認証モジュール認証用鍵ペアのＩＤ（２８ｄ）は、認証モジュール認証用鍵（ＰＫ３，ＳＫ３）の識別子である。
なお、図３（ｂ）に示すアカウント管理情報２８は、一例であって、上記の情報（ＩＤ）の一部を削除したり、他の情報を追加したりすることができる。
［認証鍵リレー型キーストア側が保持する情報］
次に、認証鍵リレー型キーストア４０側が保持する情報について説明する。認証鍵リレー型キーストア４０側が保持する情報は、具体的には、ユーザ管理ＤＢ４２の情報である。
図４は、認証鍵リレー型キーストアが保持するユーザ管理ＤＢの情報の構造図である。図４では木構造として示されている。
次に、認証鍵リレー型キーストア４０側が保持する情報について説明する。認証鍵リレー型キーストア４０側が保持する情報は、具体的には、ユーザ管理ＤＢ４２の情報である。
図４は、認証鍵リレー型キーストアが保持するユーザ管理ＤＢの情報の構造図である。図４では木構造として示されている。
<ユーザ管理ＤＢの情報>
図４に示すように、ユーザ管理ＤＢ４２は、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）と、認証モジュールモデルＩＤ（４２ｂ）と、認証モジュール認証用公開鍵のＩＤ（４２ｃ）と、ＫＳ側認証モジュール毎の対称鍵ＩＤ（４２ｄ）と、認証モジュール認証用秘密鍵のＩＤ（４２ｅ）と、ＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）と、ＷＥＢサービスのユーザＩＤ（４２ｇ）と、ＷＥＢサービスのアプリケーションＩＤ（４２ｈ）と、を有する。
図４に示すように、ユーザ管理ＤＢ４２は、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）と、認証モジュールモデルＩＤ（４２ｂ）と、認証モジュール認証用公開鍵のＩＤ（４２ｃ）と、ＫＳ側認証モジュール毎の対称鍵ＩＤ（４２ｄ）と、認証モジュール認証用秘密鍵のＩＤ（４２ｅ）と、ＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）と、ＷＥＢサービスのユーザＩＤ（４２ｇ）と、ＷＥＢサービスのアプリケーションＩＤ（４２ｈ）と、を有する。
認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、認証鍵リレー型キーストア４０を利用するユーザ（ユーザ管理ＤＢ４２に登録済み）の識別子であり、認証管理情報２３の認証鍵リレー型キーストアのユーザＩＤ（２３ｆ）と同等である。
認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、その１つ下位の認証モジュールモデルＩＤ（４２ｂ）に「１…１」で対応する。
また、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、その１つ下位の認証モジュール認証用公開鍵のＩＤ（４２ｃ）に「１…ｎ」で対応する（認証モジュール認証用公開鍵のＩＤ（４２ｃ）が「ｎ（複数）」に相当）。
また、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、その１つ下位のＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）に「１…ｎ」で対応する（ＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）が「ｎ（複数）」に相当）。
認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、その１つ下位の認証モジュールモデルＩＤ（４２ｂ）に「１…１」で対応する。
また、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、その１つ下位の認証モジュール認証用公開鍵のＩＤ（４２ｃ）に「１…ｎ」で対応する（認証モジュール認証用公開鍵のＩＤ（４２ｃ）が「ｎ（複数）」に相当）。
また、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、その１つ下位のＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）に「１…ｎ」で対応する（ＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）が「ｎ（複数）」に相当）。
認証モジュールモデルＩＤ（４２ｂ）は、認証モジュールの情報３の認証モジュールモデルＩＤ（３ａ）（図２参照）と同等である。
認証モジュール認証用公開鍵のＩＤ（４２ｃ）は、認証モジュール認証用公開鍵ＰＫ３の識別子であり、認証管理情報２３の認証モジュール認証用公開鍵のＩＤ（２３ｅ）と同等である。認証モジュール認証用公開鍵のＩＤ（４２ｃ）は、ＫＳ側認証モジュール毎の対称鍵ＩＤ（４２ｄ）に「１…１」で対応する。
ＫＳ側認証モジュール毎の対称鍵ＩＤ（４２ｄ）は、ＫＳ側認証モジュール毎の対称鍵ＳＹＫ２の識別子である。ＫＳ側認証モジュール毎の対称鍵ＩＤ（４２ｄ）は、認証モジュール認証用秘密鍵のＩＤ（４２ｅ）に「１…１」で対応する。
認証モジュール認証用秘密鍵のＩＤ（４２ｅ）は、認証モジュール認証用秘密鍵ＳＫ３の識別子である。
認証モジュール認証用秘密鍵のＩＤ（４２ｅ）は、認証モジュール認証用秘密鍵ＳＫ３の識別子である。
ＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）は、ＷＥＢサービス認証用秘密鍵ＳＫ１の識別子であり、認証管理情報２３のＷＥＢサービス認証用秘密鍵のＩＤ（２３ｄ）と同等である。ＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）は、その１つ下位のＷＥＢサービスのユーザＩＤ（４２ｇ）に「１…１」で対応する。
ＷＥＢサービスのユーザＩＤ（４２ｇ）は、ＷＥＢサービス１０を利用するユーザ（ユーザ管理ＤＢ１４に登録済み）の識別子であり、認証管理情報２３のＷＥＢサービスのユーザＩＤ（２３ｂ）と同等である。ＷＥＢサービスのユーザＩＤ（４２ｇ）は、その１つ下位のＷＥＢサービスのアプリケーションＩＤ（４２ｈ）に「１…１」で対応する。
ＷＥＢサービスのアプリケーションＩＤ（４２ｈ）は、ＷＥＢサービス１０のＷＥＢサービスアプリ１３の識別子であり、認証管理情報２３のＷＥＢサービスのアプリケーションＩＤ（２３ａ）と同等である。ＷＥＢサービスのアプリケーションＩＤ（４２ｈ）は、例えば、ＷＥＢサービス１０のＵＲＬまたはそのＵＲＬのハッシュ値とすることができる。
なお、図４に示すユーザ管理ＤＢ４２は、一例であって、上記の情報（ＩＤ）の一部を削除したり、他の情報を追加したりすることができる。
≪処理≫
次に、本実施形態の認証システムが実行する処理について説明する。この説明をする際、以下に述べる事項を前提とする。
・端末２０はスマートホンであり、認証モジュール３０を備える。このスマートホンは、例えば、指紋認証を行うことができる。なお、端末２０は、ＰＣやタブレットでもよい。また、認証モジュール３０は、端末２０に搭載される態様であってもよいし、端末２０に着脱可能に取り付けられていてもよい。
・スマートホンの利用者と、ＷＥＢサービスの利用者は同一人物（ユーザＵ）である。
・スマートホンは画面ロック機能を有しており、スマートホンの利用は画面ロック解除を行ってから可能になる。
・スマートホンの画面ロック解除機能用の認証デバイスと、認証モジュールの認証デバイスは共用利用可能である。
次に、本実施形態の認証システムが実行する処理について説明する。この説明をする際、以下に述べる事項を前提とする。
・端末２０はスマートホンであり、認証モジュール３０を備える。このスマートホンは、例えば、指紋認証を行うことができる。なお、端末２０は、ＰＣやタブレットでもよい。また、認証モジュール３０は、端末２０に搭載される態様であってもよいし、端末２０に着脱可能に取り付けられていてもよい。
・スマートホンの利用者と、ＷＥＢサービスの利用者は同一人物（ユーザＵ）である。
・スマートホンは画面ロック機能を有しており、スマートホンの利用は画面ロック解除を行ってから可能になる。
・スマートホンの画面ロック解除機能用の認証デバイスと、認証モジュールの認証デバイスは共用利用可能である。
認証システムが実行する処理は、（１）シナリオＡ 事前設定、（２）シナリオＢ 初期登録、（３）シナリオＣ ＷＥＢサイトへの登録、（４）シナリオＤ ＷＥＢサイトでの認証、の順で進行し、以下、個別に説明する。
［（１）シナリオＡ 事前設定］
シナリオＡでは、画面ロック解除の設定、および、認証モジュールの設定を行う。
図５に示すように、シナリオＡの処理は、ステップＡ１から開始する。
シナリオＡでは、画面ロック解除の設定、および、認証モジュールの設定を行う。
図５に示すように、シナリオＡの処理は、ステップＡ１から開始する。
ステップＡ１にて、ユーザＵが端末２０を操作して、画面ロック解除機能２６およびＯＳ用アカウント管理機能２７に対し、画面ロック解除設定の要求が入力される。
次に、ステップＡ２にて、ＯＳ用アカウント管理機能２７は、ユーザＵのアカウントを作成する。なお、この段階でのアカウントの作成は、端末２０がＰＣの場合には必須となる。
次に、ステップＡ２にて、ＯＳ用アカウント管理機能２７は、ユーザＵのアカウントを作成する。なお、この段階でのアカウントの作成は、端末２０がＰＣの場合には必須となる。
次に、ステップＡ３にて、画面ロック解除機能２６は、画面ロック解除を設定する。例えば、端末２０がスマートホンである場合、画面ロック解除用のクレデンシャル（Credential）として、ＰＩＮコードやパターンが設定されたり、指紋が登録されたりする。また、端末２０がＰＣである場合、画面ロック解除用のクレデンシャルとしてパスワードが登録される。
次に、ステップＡ４にて、ＯＳ用アカウント管理機能２７は、作成したアカウントと、設定または登録した画面ロック解除とを関連付ける。関連付けた情報は、アカウント管理情報２８（図１）に格納することができる。
次に、ステップＡ５にて、画面ロック解除機能２６およびＯＳ用アカウント管理機能２７は、画面ロック解除設定の応答（ＯＫ）をユーザＵに向けて出力する。具体的には、画面ロック解除設定が完了したことの画面表示や音声出力がなされる。
次に、ステップＡ５にて、画面ロック解除機能２６およびＯＳ用アカウント管理機能２７は、画面ロック解除設定の応答（ＯＫ）をユーザＵに向けて出力する。具体的には、画面ロック解除設定が完了したことの画面表示や音声出力がなされる。
次に、ステップＡ６にて、ユーザＵが端末２０を操作して、端末側連携認証機能２５を介して、ＦＩＤＯクライアント２２および認証モジュールドライバ２４に対し、認証モジュール設定の要求が入力される。
次に、ステップＡ７にて、ＦＩＤＯクライアント２２および認証モジュールドライバ２４は、認証モジュール３０を介して、ユーザ認証のクレデンシャルの要求をユーザＵに向けて出力する。具体的には、クレデンシャルの提示を促す画面表示や音声出力がなされる。
次に、ステップＡ７にて、ＦＩＤＯクライアント２２および認証モジュールドライバ２４は、認証モジュール３０を介して、ユーザ認証のクレデンシャルの要求をユーザＵに向けて出力する。具体的には、クレデンシャルの提示を促す画面表示や音声出力がなされる。
次に、ステップＡ８にて、ユーザＵが端末２０を操作して、認証モジュール３０に対し、ユーザ認証のクレデンシャルが提示されるように入力される。
次に、ステップＡ９にて、認証モジュール３０は、入力された、ユーザ認証のクレデンシャルを認証判定モジュール３１に登録する。クレデンシャルの登録が完了すると、認証モジュール３０は、そのクレデンシャルに対応する認証モジュールモデルＩＤを生成する。
次に、ステップＡ９にて、認証モジュール３０は、入力された、ユーザ認証のクレデンシャルを認証判定モジュール３１に登録する。クレデンシャルの登録が完了すると、認証モジュール３０は、そのクレデンシャルに対応する認証モジュールモデルＩＤを生成する。
次に、ステップＡ１０にて、認証モジュール３０は、ＦＩＤＯクライアント２２および認証モジュールドライバ２４に対し、クレデンシャルの登録の完了（ＯＫ）を通知するとともに、生成した認証モジュールモデルＩＤを送信する。
次に、ステップＡ１１にて、ＦＩＤＯクライアント２２および認証モジュールドライバ２４は、端末側連携認証機能２５を介して、ＯＳ用アカウント管理機能２７に対し、認証モジュールアサーションキーを要求する。
次に、ステップＡ１２にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内に、端末側認証モジュール毎の対称鍵ＳＹＫ１を生成する。
次に、ステップＡ１１にて、ＦＩＤＯクライアント２２および認証モジュールドライバ２４は、端末側連携認証機能２５を介して、ＯＳ用アカウント管理機能２７に対し、認証モジュールアサーションキーを要求する。
次に、ステップＡ１２にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内に、端末側認証モジュール毎の対称鍵ＳＹＫ１を生成する。
次に、ステップＡ１３にて、端末２０は、端末２０および認証モジュール３０間に亘ってＥＣＤＨＥ（Diffie-Hellman鍵交換）−ＥＣＤＳＡ（Elliptic Curve Digital Signature Algorithm）鍵共有アルゴリズムを実行し、鍵処理保管領域Ｒ１に認証モジュールアサーションキーＡＫ１を生成し、ＯＳ鍵処理保管領域Ｒ２に認証モジュールアサーションキーＡＫ２を生成する。ＥＣＤＨＥ−ＥＣＤＳＡ鍵共有アルゴリズムを利用すると、端末側連携認証機能２５が認証モジュール３０側に実装してあっても、セキュアに秘密鍵を共有することができる。ただし、鍵共有アルゴリズムは、ＲＳＡ（Rivest-Shamir-Adleman）方式などの他の方式であってもよい。また、ＯＳ鍵処理保管領域Ｒ２で共通鍵（認証モジュールアサーションキーＡＫ１，ＡＫ２）を生成して、認証モジュール３０の鍵処理保管領域Ｒ１に認証モジュールアサーションキーＡＫ１を送付してもよい。
次に、ステップＡ１４にて、ＯＳ用アカウント管理機能２７は、ＯＳのアカウント管理情報２８（図１）に、端末側認証モジュール毎の対称鍵ＳＹＫ１と、認証モジュールアサーションキーＡＫ２と、認証モジュールモデルＩＤとを関連付けて保存する。このような保存は、認証モジュールの設定が完了したことを意味する。その結果、端末２０の画面ロック解除での認証により、ログインしたアカウントの端末側認証モジュール毎の対称鍵ＳＹＫ１と認証モジュールアサーションキーＡＫ２とが利用可能となる。
次に、ステップＡ１５にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５、ＦＩＤＯクライアント２２、認証モジュールドライバ２４を介して、認証モジュール３０の設定の応答（ＯＫ）をユーザＵに向けて出力する。具体的には、認証モジュール３０の設定が完了したことの画面表示や音声出力がなされる。
以上により、シナリオＡの処理が完了する。
シナリオＡによれば、画面ロック解除の設定、および、認証モジュールの設定を実現することができる。
シナリオＡによれば、画面ロック解除の設定、および、認証モジュールの設定を実現することができる。
［（２）シナリオＢ 初期登録］
シナリオＢでは、認証鍵リレー型キーストア４０と認証モジュール３０間で認証モジュール認証用鍵を持ち合う。
図６に示すように、シナリオＢの処理は、ステップＢ１から開始する。
シナリオＢでは、認証鍵リレー型キーストア４０と認証モジュール３０間で認証モジュール認証用鍵を持ち合う。
図６に示すように、シナリオＢの処理は、ステップＢ１から開始する。
ステップＢ１にて、ユーザＵが端末２０を操作して、画面ロック解除機能２６に対し、画面ロック解除の指示が入力される。
次に、ステップＢ２にて、ＯＳ用アカウント管理機能２７は、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスを許可する。つまり、端末２０の画面ロック解除での認証が成功し、ログインしたアカウントの端末側認証モジュール毎の対称鍵ＳＹＫ１と認証モジュールアサーションキーＡＫ２とが利用可能となる。
次に、ステップＢ２にて、ＯＳ用アカウント管理機能２７は、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスを許可する。つまり、端末２０の画面ロック解除での認証が成功し、ログインしたアカウントの端末側認証モジュール毎の対称鍵ＳＹＫ１と認証モジュールアサーションキーＡＫ２とが利用可能となる。
次に、ステップＢ３にて、ＯＳ用アカウント管理機能２７は、画面ロック解除が成功したこと（ＯＫ）をユーザに向けて出力する。具体的には、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスが許可されたことを示す画面表示や音声出力がなされる。
次に、ステップＢ４にて、ユーザＵが端末２０を操作して、ブラウザ・アプリ２１を介して、認証鍵リレー型キーストア４０のアカウント管理ＷＥＢアプリ４３にアクセスする。このアクセスは、例えば、ＳＳＬ（Secure Sockets Layer）／ＴＳＬ（Transport Layer Security）接続を利用することができる。なお、前提として、認証鍵リレー型キーストア４０が有する（ユーザＵの）アカウントは事前に作成してあるとする。認証鍵リレー型キーストア４０側でのアカウントの認証は、ＩＤやパスワードなどによる認証を実行することができる。
次に、ステップＢ５にて、ユーザＵが端末２０を操作して、アカウント管理ＷＥＢアプリ４３に対し、認証モジュール登録の要求が入力される。例えば、ブラウザ画面に「認証モジュール登録」ボタンが表示されており、そのボタンが押下されることで入力される。
次に、ステップＢ６にて、アカウント管理ＷＥＢアプリ４３は、ＫＳ側連携認証機能４１に対し、認証モジュール登録の要求（ステップＢ５でユーザＵが入力した要求と同等）を送信する。
次に、ステップＢ６にて、アカウント管理ＷＥＢアプリ４３は、ＫＳ側連携認証機能４１に対し、認証モジュール登録の要求（ステップＢ５でユーザＵが入力した要求と同等）を送信する。
次に、ステップＢ７にて、ＫＳ側連携認証機能４１は、耐タンパー領域Ｒ３内に認証モジュール認証用鍵を生成するように認証鍵リレー型キーストア４０に要求する。
次に、ステップＢ８にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内に認証モジュール認証用鍵、つまり、認証モジュール認証用公開鍵ＰＫ３、および、認証モジュール認証用秘密鍵ＳＫ３を生成する。
次に、ステップＢ９にて、認証鍵リレー型キーストア４０は、サーバの秘密鍵ＳＫ４を用いて、耐タンパー領域Ｒ３内で認証モジュール認証用公開鍵ＰＫ３に署名する。
次に、ステップＢ８にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内に認証モジュール認証用鍵、つまり、認証モジュール認証用公開鍵ＰＫ３、および、認証モジュール認証用秘密鍵ＳＫ３を生成する。
次に、ステップＢ９にて、認証鍵リレー型キーストア４０は、サーバの秘密鍵ＳＫ４を用いて、耐タンパー領域Ｒ３内で認証モジュール認証用公開鍵ＰＫ３に署名する。
次に、ステップＢ１０にて、認証鍵リレー型キーストア４０は、署名された認証モジュール認証用公開鍵ＰＫ３を耐タンパー領域Ｒ３から取り出し、ＫＳ側連携認証機能４１に送付する。
次に、ステップＢ１１にて、ＫＳ側連携認証機能４１は、アカウント管理ＷＥＢアプリ４３に対し、署名された認証モジュール認証用公開鍵ＰＫ３を送付する。
次に、ステップＢ１２にて、アカウント管理ＷＥＢアプリ４３は、ブラウザ・アプリ２１を介して、端末側連携認証機能２５に対し、署名された認証モジュール認証用公開鍵ＰＫ３を送付する。
次に、ステップＢ１１にて、ＫＳ側連携認証機能４１は、アカウント管理ＷＥＢアプリ４３に対し、署名された認証モジュール認証用公開鍵ＰＫ３を送付する。
次に、ステップＢ１２にて、アカウント管理ＷＥＢアプリ４３は、ブラウザ・アプリ２１を介して、端末側連携認証機能２５に対し、署名された認証モジュール認証用公開鍵ＰＫ３を送付する。
次に、ステップＢ１３にて、端末側連携認証機能２５は、署名された認証モジュール認証用公開鍵ＰＫ３の署名を検証する。
仮に、署名が真正（ＯＫ）であった場合、ステップＢ１４にて、端末側連携認証機能２５は、ＦＩＤＯクライアント２２、認証モジュールドライバ２４、および、認証モジュール３０を介して、認証の要求をユーザＵに向けて出力する。具体的には、クレデンシャルの提示を促す画面表示や音声出力がなされる。
仮に、署名が真正（ＯＫ）であった場合、ステップＢ１４にて、端末側連携認証機能２５は、ＦＩＤＯクライアント２２、認証モジュールドライバ２４、および、認証モジュール３０を介して、認証の要求をユーザＵに向けて出力する。具体的には、クレデンシャルの提示を促す画面表示や音声出力がなされる。
図７に示すように、次に、ステップＢ１５にて、ユーザＵが端末２０を操作して、認証モジュール３０に対し、ユーザ認証のクレデンシャルが提示されるように入力される。
次に、ステップＢ１６にて、認証判定モジュール３１は、提示されたクレデンシャルを用いてユーザ認証を検証する、つまり、ユーザＵが本人であるか否か判定する。
仮に、ユーザＵが本人（ＯＫ）であった場合、ステップＢ１７にて、認証判定モジュール３１は、メタデータサービス向け秘密鍵ＳＫ２を用いて、鍵処理保管領域Ｒ１内で認証モジュールモデルＩＤ３０１（図５のステップＡ１０にて生成された認証モジュールモデルＩＤであり、認証管理情報２３（図３（ａ））が備える認証モジュールモデルＩＤ２３ｃに対応する）に署名する。
仮に、ユーザＵが本人（ＯＫ）であった場合、ステップＢ１７にて、認証判定モジュール３１は、メタデータサービス向け秘密鍵ＳＫ２を用いて、鍵処理保管領域Ｒ１内で認証モジュールモデルＩＤ３０１（図５のステップＡ１０にて生成された認証モジュールモデルＩＤであり、認証管理情報２３（図３（ａ））が備える認証モジュールモデルＩＤ２３ｃに対応する）に署名する。
次に、ステップＢ１８にて、認証判定モジュール３１は、アサーション３０２を生成し、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、署名付き認証モジュールモデルＩＤ３０１およびアサーション３０２を暗号化する。
次に、ステップＢ１９にて、認証モジュール３０は、ＦＩＤＯクライアント２２、認証モジュールドライバ２４、端末側連携認証機能２５を介して、ＯＳ用アカウント管理機能２７に対し、暗号化された、認証モジュールモデルＩＤ３０１およびアサーション３０２を送信する。
次に、ステップＢ１９にて、認証モジュール３０は、ＦＩＤＯクライアント２２、認証モジュールドライバ２４、端末側連携認証機能２５を介して、ＯＳ用アカウント管理機能２７に対し、暗号化された、認証モジュールモデルＩＤ３０１およびアサーション３０２を送信する。
次に、ステップＢ２０にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、暗号化された、認証モジュールモデルＩＤ３０１およびアサーション３０２を、認証モジュールアサーションキーＡＫ２で復号し、アサーション検証をする。本実施形態では、アサーションの検証結果は良であったとする。
次に、ステップＢ２１にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５に対し、アサーションの検証結果が良であったこと（認証ＯＫ）を通知するとともに、復号化された、署名付き認証モジュールモデルＩＤ３０１を送信する。
次に、ステップＢ２１にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５に対し、アサーションの検証結果が良であったこと（認証ＯＫ）を通知するとともに、復号化された、署名付き認証モジュールモデルＩＤ３０１を送信する。
次に、ステップＢ２２にて、端末側連携認証機能２５は、ブラウザ・アプリ２１、および、アカウント管理ＷＥＢアプリを介して、ＫＳ側連携認証機能４１に対し、署名付き認証モジュールモデルＩＤ３０１を送信する。
次に、ステップＢ２３にて、ＫＳ側連携認証機能４１は、メタデータサービス１を参照し、メタデータサービス向け公開鍵ＰＫ２を取得する。
次に、ステップＢ２４にて、ＫＳ側連携認証機能４１は、メタデータサービス向け公開鍵ＰＫ２を用いて、署名付き認証モジュールモデルＩＤ３０１の署名を検証する。
次に、ステップＢ２３にて、ＫＳ側連携認証機能４１は、メタデータサービス１を参照し、メタデータサービス向け公開鍵ＰＫ２を取得する。
次に、ステップＢ２４にて、ＫＳ側連携認証機能４１は、メタデータサービス向け公開鍵ＰＫ２を用いて、署名付き認証モジュールモデルＩＤ３０１の署名を検証する。
図８に示すように、仮に、署名が真正であった（署名検証ＯＫ）場合（ステップＢ２５）、ステップＢ２６にて、ＫＳ側連携認証機能４１は、アカウント管理ＷＥＢアプリ４３、および、ブラウザ・アプリ２１を介して、端末側連携認証機能２５に対し、署名が真正であったこと（ＯＫ）を通知する。なお、ステップＢ２６にて、ユーザＵに関する情報が、ユーザ管理ＤＢ４２（図４参照）に登録される。
次に、ステップＢ２７にて、端末側連携認証機能２５は、（ステップＢ１３（図６）で署名が真正と判定された）認証モジュール認証用公開鍵ＰＫ３をＯＳ鍵処理保管領域Ｒ２内に送付する。
次に、ステップＢ２８にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内の認証モジュール認証用公開鍵ＰＫ３を、端末側認証モジュール毎の対称鍵ＳＹＫ１（図５のステップＡ１２参照）を用いて暗号化する。また、ＯＳ用アカウント管理機能２７は、暗号化した認証モジュール認証用公開鍵ＰＫ３を端末側連携認証機能２５に送信する。
次に、ステップＢ２８にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内の認証モジュール認証用公開鍵ＰＫ３を、端末側認証モジュール毎の対称鍵ＳＹＫ１（図５のステップＡ１２参照）を用いて暗号化する。また、ＯＳ用アカウント管理機能２７は、暗号化した認証モジュール認証用公開鍵ＰＫ３を端末側連携認証機能２５に送信する。
次に、ステップＢ２９にて、端末側連携認証機能２５は、ＯＳ用アカウント管理機能２７から受信した認証モジュール認証用公開鍵ＰＫ３と、ＫＳ側連携認証機能４１のＵＲＬとを、端末２０のＯＳで扱う（ユーザＵの）アカウントと関連付けて保存する。これにより、認証モジュール認証用公開鍵ＰＫ３が、端末２０のロック解除での認証によりログインしたアカウントに関連付けられる。また、このような保存は、認証モジュール３０の登録が完了したことを意味する。画面ロック解除と認証鍵リレー型キーストア４０へのアクセスに必要な鍵を、画面ロックのアカウントと関連付けることで、認証鍵リレー型キーストア４０へのアクセスのための認証を、画面ロック解除によって実行することができる。
次に、ステップＢ３０にて、端末側連携認証機能２５は、ブラウザ・アプリ２１を介して、アカウント管理ＷＥＢアプリ４３に対し、認証モジュール３０の登録が端末２０側で完了したこと（ＯＫ）を通知する。アカウント管理ＷＥＢアプリ４３は、認証モジュール３０の登録を反映するようにユーザ管理ＤＢ４２を更新する。
次に、ステップＢ３１にて、アカウント管理ＷＥＢアプリ４３は、ブラウザ・アプリ２１に対し、認証モジュール３０の登録が認証鍵リレー型キーストア４０側で完了したことを通知する。その結果、端末２０の画面を見ているユーザＵは、認証モジュール登録の要求（ステップＢ５）の応答として、認証モジュール３０の登録が完了したことを認識することができる。
次に、ステップＢ３１にて、アカウント管理ＷＥＢアプリ４３は、ブラウザ・アプリ２１に対し、認証モジュール３０の登録が認証鍵リレー型キーストア４０側で完了したことを通知する。その結果、端末２０の画面を見ているユーザＵは、認証モジュール登録の要求（ステップＢ５）の応答として、認証モジュール３０の登録が完了したことを認識することができる。
一方、仮に、署名が真正でなかった（署名検証ＮＧ）場合（ステップＢ３２）、ステップＢ３３にて、ＫＳ側連携認証機能４１は、アカウント管理ＷＥＢアプリ４３、および、ブラウザ・アプリ２１を介して、端末側連携認証機能２５に対し、署名が真正でなかったこと（ＮＧ）を通知する。
次に、ステップＢ３４にて、端末側連携認証機能２５は、（ステップＢ１３（図６）で署名が真正と判定された）認証モジュール認証用公開鍵ＰＫ３を削除する。
次に、ステップＢ３５にて、端末側連携認証機能２５は、ブラウザ・アプリ２１を介して、アカウント管理ＷＥＢアプリ４３に対し、認証モジュール認証用公開鍵ＰＫ３の削除が端末２０側で完了したことを通知する。
次に、ステップＢ３６にて、アカウント管理ＷＥＢアプリ４３は、ブラウザ・アプリ２１に対し、認証モジュール認証用公開鍵ＰＫ３の削除が認証鍵リレー型キーストア４０側で完了したことを通知する。その結果、端末２０の画面を見ているユーザＵは、認証モジュール登録の要求（ステップＢ５）の応答として、認証モジュール３０の登録が失敗したことを認識することができる。
次に、ステップＢ３５にて、端末側連携認証機能２５は、ブラウザ・アプリ２１を介して、アカウント管理ＷＥＢアプリ４３に対し、認証モジュール認証用公開鍵ＰＫ３の削除が端末２０側で完了したことを通知する。
次に、ステップＢ３６にて、アカウント管理ＷＥＢアプリ４３は、ブラウザ・アプリ２１に対し、認証モジュール認証用公開鍵ＰＫ３の削除が認証鍵リレー型キーストア４０側で完了したことを通知する。その結果、端末２０の画面を見ているユーザＵは、認証モジュール登録の要求（ステップＢ５）の応答として、認証モジュール３０の登録が失敗したことを認識することができる。
以上により、シナリオＢの処理が完了する。
シナリオＢによれば、認証鍵リレー型キーストア４０と認証モジュール３０間で認証モジュール認証用鍵を持ち合う（認証鍵リレー型キーストア４０が認証モジュール認証用秘密鍵ＳＫ３を持ち、認証モジュール３０が（暗号化された）認証モジュール認証用公開鍵ＰＫ３を持つ）ことができる。
シナリオＢによれば、認証鍵リレー型キーストア４０と認証モジュール３０間で認証モジュール認証用鍵を持ち合う（認証鍵リレー型キーストア４０が認証モジュール認証用秘密鍵ＳＫ３を持ち、認証モジュール３０が（暗号化された）認証モジュール認証用公開鍵ＰＫ３を持つ）ことができる。
［（３）シナリオＣ ＷＥＢサイトへの登録］
シナリオＣでは、認証鍵リレー型キーストア４０でＷＥＢサービス認証用秘密鍵ＳＫ１を生成し、ＷＥＢサービス１０側と鍵を共有する。
図９に示すように、シナリオＣの処理は、ステップＣ１から開始する。
シナリオＣでは、認証鍵リレー型キーストア４０でＷＥＢサービス認証用秘密鍵ＳＫ１を生成し、ＷＥＢサービス１０側と鍵を共有する。
図９に示すように、シナリオＣの処理は、ステップＣ１から開始する。
ステップＣ１にて、ユーザＵが端末２０を操作して、画面ロック解除機能２６に対し、画面ロック解除の指示が入力される。
次に、ステップＣ２にて、ＯＳ用アカウント管理機能２７は、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスを許可する。つまり、認証鍵リレー型キーストア４０へのアクセスのための認証が画面ロック解除により完了する。
次に、ステップＣ２にて、ＯＳ用アカウント管理機能２７は、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスを許可する。つまり、認証鍵リレー型キーストア４０へのアクセスのための認証が画面ロック解除により完了する。
次に、ステップＣ３にて、ＯＳ用アカウント管理機能２７は、画面ロック解除が成功したこと（ＯＫ）をユーザに向けて出力する。具体的には、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスが許可されたこと、そして、認証鍵リレー型キーストア４０へのアクセスが許可されたことを示す画面表示や音声出力がなされる。
次に、ステップＣ４にて、ユーザＵが端末２０を操作して、ブラウザ・アプリ２１を介して、ＷＥＢサービス１０のＷＥＢサイトにアクセスし、（新規登録用に）ログインする。なお、ＦＩＤＯ ＵＡＦ 1.0では、ＷＥＢサービス１０側で、ユーザＵのアカウントは予め作成しておくことになっており、本実施形態でも予め作成してあるとし、ＷＥＢサイトでのログインをできるようにする。
次に、ステップＣ５にて、ユーザＵが端末２０を操作して、ブラウザ・アプリ２１を介して、ＷＥＢサービス１０に対し、ユーザＵのアカウントの認証の方式を、ＦＩＤＯの認証方式に切り替える要求が入力される。
次に、ステップＣ６にて、ＷＥＢサービス１０が、ブラウザ・アプリ２１、ＦＩＤＯクライアント２２、および、認証モジュールドライバ２４を介して、認証モジュール３０に対し、ＦＩＤＯの登録要求（ＦＩＤＯの登録に関する要求）を送信する。
次に、ステップＣ７にて、認証モジュール３０が、ユーザ認証の要求をユーザＵに向けて出力する。具体的には、ユーザ認証に用いるクレデンシャルの提示を促す画面表示や音声出力がなされる。
次に、ステップＣ７にて、認証モジュール３０が、ユーザ認証の要求をユーザＵに向けて出力する。具体的には、ユーザ認証に用いるクレデンシャルの提示を促す画面表示や音声出力がなされる。
次に、ステップＣ８にて、ユーザＵが端末２０を操作して、認証モジュール３０に対し、ユーザ認証のクレデンシャルが提示されるように入力される。
次に、ステップＣ９にて、認証判定モジュール３１は、入力されたクレデンシャルを用いて、ユーザ認証を検証する、つまり、ユーザＵが本人であるか否か判定する。
仮に、ユーザＵが本人（ＯＫ）であった場合、ステップＣ１０にて、認証判定モジュール３１は、アサーション３０３を生成し、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、アサーション３０３およびＦＩＤＯ登録要求３０４（ステップＣ６の要求に相当）を暗号化する。
次に、ステップＣ９にて、認証判定モジュール３１は、入力されたクレデンシャルを用いて、ユーザ認証を検証する、つまり、ユーザＵが本人であるか否か判定する。
仮に、ユーザＵが本人（ＯＫ）であった場合、ステップＣ１０にて、認証判定モジュール３１は、アサーション３０３を生成し、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、アサーション３０３およびＦＩＤＯ登録要求３０４（ステップＣ６の要求に相当）を暗号化する。
次に、ステップＣ１１にて、認証モジュール３０は、ＦＩＤＯクライアント２２および認証モジュールドライバ２４に対し、暗号化された、アサーション３０３およびＦＩＤＯ登録要求３０４を送信するとともに、ＷＥＢサービス認証用鍵の生成要求を送信する。ＷＥＢサービス認証用鍵とは、ＷＥＢサービス認証用公開鍵ＰＫ１およびＷＥＢサービス認証用秘密鍵ＳＫ１である。
次に、ステップＣ１２にて、ＦＩＤＯクライアント２２および認証モジュールドライバ２４は、端末側連携認証機能２５に対し、暗号化された、アサーション３０３およびＦＩＤＯ登録要求３０４を送信するとともに、ＷＥＢサービス認証用鍵の生成要求を送信する。
次に、ステップＣ１２にて、ＦＩＤＯクライアント２２および認証モジュールドライバ２４は、端末側連携認証機能２５に対し、暗号化された、アサーション３０３およびＦＩＤＯ登録要求３０４を送信するとともに、ＷＥＢサービス認証用鍵の生成要求を送信する。
次に、ステップＣ１３にて、端末側連携認証機能２５は、ＯＳ用アカウント管理機能２７に対し、暗号化用の共通鍵の生成要求を送信するとともに、暗号化されたアサーション３０３（暗号化されたＦＩＤＯ登録要求３０４も含む。）、および、（図８のステップＢ２９にて保存されている）暗号化された認証モジュール認証用公開鍵ＰＫ３を送信する。
次に、ステップＣ１４にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、暗号化された、アサーション３０３およびＦＩＤＯ登録要求３０４を、認証モジュールアサーションキーＡＫ２で復号し、アサーション検証をする。本実施形態では、アサーションの検証結果は良（ＯＫ）であったとする。
次に、ステップＣ１４にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、暗号化された、アサーション３０３およびＦＩＤＯ登録要求３０４を、認証モジュールアサーションキーＡＫ２で復号し、アサーション検証をする。本実施形態では、アサーションの検証結果は良（ＯＫ）であったとする。
図１０に示すように、次に、ステップＣ１５にて、ＯＳ用アカウント管理機能２７は、例えばＡＥＳ（Advanced Encryption Standard：高度暗号化標準）に従う共通鍵ＣＫを生成する。また、ＯＳ用アカウント管理機能２７は、Ｃｈａｌｌｅｎｇｅ２０１（チャレンジ）を生成し、共通鍵ＣＫで暗号化する。Ｃｈａｌｌｅｎｇｅ２０１は、周知のチャレンジ／レスポンス認証に用いられるランダムな数値列である。
次に、ステップＣ１６にて、ＯＳ用アカウント管理機能２７は、暗号化された認証モジュール認証用公開鍵ＰＫ３を端末側認証モジュール毎の対称鍵ＳＹＫ１（図５のステップＡ１２参照）を用いて復号し、復号化した認証モジュール認証用公開鍵ＰＫ３を用いて共通鍵ＣＫを暗号化する。
次に、ステップＣ１６にて、ＯＳ用アカウント管理機能２７は、暗号化された認証モジュール認証用公開鍵ＰＫ３を端末側認証モジュール毎の対称鍵ＳＹＫ１（図５のステップＡ１２参照）を用いて復号し、復号化した認証モジュール認証用公開鍵ＰＫ３を用いて共通鍵ＣＫを暗号化する。
次に、ステップＣ１７にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５を介して、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１に、暗号化された共通鍵ＣＫと、暗号化されたＣｈａｌｌｅｎｇｅ２０１とを送付し、ＫＳ側連携認証機能４１が耐タンパー領域Ｒ３内に、暗号化された共通鍵ＣＫと、暗号化されたＣｈａｌｌｅｎｇｅ２０１を格納する。
次に、ステップＣ１８にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、認証モジュール認証用秘密鍵ＳＫ３を用いて、共通鍵ＣＫを復号する。
次に、ステップＣ１９にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、復号化した共通鍵ＣＫを用いて、Ｃｈａｌｌｅｎｇｅ２０１を復号し、Ｒｅｓｐｏｎｓｅ４０１を計算する。Ｒｅｓｐｏｎｓｅ４０１は、周知のチャレンジ／レスポンス認証に用いられるランダムな数値列である。また、認証鍵リレー型キーストア４０は、Ｒｅｓｐｏｎｓｅ４０１を共通鍵ＣＫで暗号化する。
次に、ステップＣ１９にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、復号化した共通鍵ＣＫを用いて、Ｃｈａｌｌｅｎｇｅ２０１を復号し、Ｒｅｓｐｏｎｓｅ４０１を計算する。Ｒｅｓｐｏｎｓｅ４０１は、周知のチャレンジ／レスポンス認証に用いられるランダムな数値列である。また、認証鍵リレー型キーストア４０は、Ｒｅｓｐｏｎｓｅ４０１を共通鍵ＣＫで暗号化する。
次に、ステップＣ２０にて、認証鍵リレー型キーストア４０は、ＫＳ側連携認証機能４１、および、端末２０の端末側連携認証機能２５を介して、ＯＳ用アカウント管理機能２７に対し、暗号化されたＲｅｓｐｏｎｓｅ４０１を送付する。
次に、ステップＣ２１にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、共通鍵ＣＫを用いて、暗号化されたＲｅｓｐｏｎｓｅ４０１を復号し、検証をする。本実施形態では、Ｒｅｓｐｏｎｓｅ４０１の検証結果は良（ＯＫ）であったとする。
次に、ステップＣ２１にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、共通鍵ＣＫを用いて、暗号化されたＲｅｓｐｏｎｓｅ４０１を復号し、検証をする。本実施形態では、Ｒｅｓｐｏｎｓｅ４０１の検証結果は良（ＯＫ）であったとする。
次に、ステップＣ２２にて、ＯＳ用アカウント管理機能２７は、共通鍵ＣＫを用いて、ＦＩＤＯ登録要求３０４を暗号化する。
次に、ステップＣ２３にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５を介して、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１に、暗号化されたＦＩＤＯ登録要求３０４を送付し、ＫＳ側連携認証機能４１が耐タンパー領域Ｒ３内に、暗号化されたＦＩＤＯ登録要求３０４を格納する。
次に、ステップＣ２３にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５を介して、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１に、暗号化されたＦＩＤＯ登録要求３０４を送付し、ＫＳ側連携認証機能４１が耐タンパー領域Ｒ３内に、暗号化されたＦＩＤＯ登録要求３０４を格納する。
次に、ステップＣ２４にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、（ステップＣ１８にて復号化した）共通鍵ＣＫを用いて、暗号化されたＦＩＤＯ登録要求３０４を復号する。そして、認証鍵リレー型キーストア４０は、ＦＩＤＯ登録要求３０４の処理を実施し、処理結果としてのＦＩＤＯ登録応答４０２を生成する。
次に、ステップＣ２５にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、ＷＥＢサービス認証用鍵（ペア）、つまり、ＷＥＢサービス認証用公開鍵ＰＫ１およびＷＥＢサービス認証用秘密鍵ＳＫ１を生成する。
次に、ステップＣ２５にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、ＷＥＢサービス認証用鍵（ペア）、つまり、ＷＥＢサービス認証用公開鍵ＰＫ１およびＷＥＢサービス認証用秘密鍵ＳＫ１を生成する。
次に、ステップＣ２６にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、共通鍵ＣＫを用いて、ＦＩＤＯ登録応答４０２およびＷＥＢサービス認証用公開鍵ＰＫ１を暗号化する。また、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１は、端末２０の端末側連携認証機能２５を介して、ＯＳ用アカウント管理機能２７に対し、暗号化された、ＦＩＤＯ登録応答４０２およびＷＥＢサービス認証用公開鍵ＰＫ１を送付する。なお、認証鍵リレー型キーストア４０が有する共通鍵ＣＫは、本ステップ完了後に破棄してもよい。
次に、ステップＣ２７にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、共通鍵ＣＫを用いて、暗号化された、ＦＩＤＯ登録応答４０２およびＷＥＢサービス認証用公開鍵ＰＫ１を復号する。なお、端末２０が有する共通鍵ＣＫは、本ステップ完了後に破棄してもよい。
図１１に示すように、次に、ステップＣ２８にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、ＦＩＤＯ登録応答４０２およびＷＥＢサービス認証用公開鍵ＰＫ１を、認証モジュールアサーションキーＡＫ２で暗号化する。
図１１に示すように、次に、ステップＣ２８にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、ＦＩＤＯ登録応答４０２およびＷＥＢサービス認証用公開鍵ＰＫ１を、認証モジュールアサーションキーＡＫ２で暗号化する。
次に、ステップＣ２９にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５、ＦＩＤＯクライアント２２および認証モジュールドライバ２４を介して、認証モジュール３０に対し、暗号化された、ＦＩＤＯ登録応答４０２およびＷＥＢサービス認証用公開鍵ＰＫ１を送信する。
次に、ステップＣ３０にて、認証判定モジュール３１は、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、暗号化された、ＦＩＤＯ登録応答４０２およびＷＥＢサービス認証用公開鍵ＰＫ１を復号する。
次に、ステップＣ３０にて、認証判定モジュール３１は、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、暗号化された、ＦＩＤＯ登録応答４０２およびＷＥＢサービス認証用公開鍵ＰＫ１を復号する。
次に、ステップＣ３１にて、認証判定モジュール３１は、メタデータサービス向け秘密鍵ＳＫ２を用いて、鍵処理保管領域Ｒ１内で、ＦＩＤＯ登録応答４０２に署名する。
次に、ステップＣ３２にて、認証モジュール３０は、ブラウザ・アプリ２１、ＦＩＤＯクライアント、および、認証モジュールドライバ２４を介して、署名付きＦＩＤＯ登録応答４０２、および、ＷＥＢサービス認証用公開鍵ＰＫ１を、ＷＥＢサービス１０に送信する。
次に、ステップＣ３２にて、認証モジュール３０は、ブラウザ・アプリ２１、ＦＩＤＯクライアント、および、認証モジュールドライバ２４を介して、署名付きＦＩＤＯ登録応答４０２、および、ＷＥＢサービス認証用公開鍵ＰＫ１を、ＷＥＢサービス１０に送信する。
次に、ステップＣ３３にて、ＷＥＢサービス１０は、メタデータサービス１を参照し、メタデータサービス向け公開鍵ＰＫ２を取得する。
次に、ステップＣ３４にて、ＷＥＢサービス１０は、メタデータサービス向け公開鍵ＰＫ２を用いて、署名付きＦＩＤＯ登録応答４０２の署名を検証する。
次に、ステップＣ３４にて、ＷＥＢサービス１０は、メタデータサービス向け公開鍵ＰＫ２を用いて、署名付きＦＩＤＯ登録応答４０２の署名を検証する。
仮に、署名が真正であった（ＯＫ）場合、ステップＣ３５にて、ＷＥＢサービス１０は、ＷＥＢサービス認証用公開鍵ＰＫ１を、ユーザＵのアカウント（図１の符号１１）に紐付けて保存する。保存先は、ＷＥＢサービス１０のＦＩＤＯサーバ１５の鍵管理領域１６（図１参照）である。
次に、ステップＣ３６にて、ＷＥＢサービス１０は、ブラウザ・アプリ２１に対し、ＦＩＤＯの認証方式への切り替えが完了したことを通知する。その結果、端末２０の画面を見ているユーザＵは、ＦＩＤＯの認証方式への切り替えの要求（ステップＣ５）の応答として、認証方式がＦＩＤＯの認証方式に切り替わったことを認識することができる。また、端末２０は、ステップＣ３６でのＷＥＢサービス１０からの通知に含まれている情報を用いて、ユーザＵがＷＥＢサービス１０を利用することに関する認証管理情報２３（図３（ａ）参照）を作成し、記憶する。
以上により、シナリオＣの処理が完了する。
シナリオＣによれば、認証鍵リレー型キーストア４０でＷＥＢサービス認証用秘密鍵ＳＫ１を生成し、ＷＥＢサービス１０側と鍵を共有することができる。つまり、ＷＥＢサービス認証用秘密鍵ＳＫ１は、従来のように、認証モジュール３０側にではなく、ＷＥＢサービス１０側に持たせることができる。その結果、ユーザＵの端末２０を、ＷＥＢサービス１０のＷＥＢサイトに登録することができる。
シナリオＣによれば、認証鍵リレー型キーストア４０でＷＥＢサービス認証用秘密鍵ＳＫ１を生成し、ＷＥＢサービス１０側と鍵を共有することができる。つまり、ＷＥＢサービス認証用秘密鍵ＳＫ１は、従来のように、認証モジュール３０側にではなく、ＷＥＢサービス１０側に持たせることができる。その結果、ユーザＵの端末２０を、ＷＥＢサービス１０のＷＥＢサイトに登録することができる。
［（４）シナリオＤ ＷＥＢサイトでの認証］
シナリオＤでは、認証鍵リレー型キーストア４０で保管してあるＷＥＢサービス認証用秘密鍵ＳＫ１を利用して、ＷＥＢサービス１０のＷＥＢサイトにログインする。
図１２に示すように、シナリオＤの処理は、ステップＤ１から開始する。
シナリオＤでは、認証鍵リレー型キーストア４０で保管してあるＷＥＢサービス認証用秘密鍵ＳＫ１を利用して、ＷＥＢサービス１０のＷＥＢサイトにログインする。
図１２に示すように、シナリオＤの処理は、ステップＤ１から開始する。
ステップＤ１にて、ユーザＵが端末２０を操作して、画面ロック解除機能２６に対し、画面ロック解除の指示が入力される。
次に、ステップＤ２にて、ＯＳ用アカウント管理機能２７は、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスを許可する。つまり、認証鍵リレー型キーストア４０へのアクセスのための認証が画面ロック解除により完了する。
次に、ステップＤ２にて、ＯＳ用アカウント管理機能２７は、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスを許可する。つまり、認証鍵リレー型キーストア４０へのアクセスのための認証が画面ロック解除により完了する。
次に、ステップＤ３にて、ＯＳ用アカウント管理機能２７は、画面ロック解除が成功したこと（ＯＫ）をユーザに向けて出力する。具体的には、ユーザアカウントに対応したＯＳ鍵処理保管領域Ｒ２へのアクセスが許可されたこと、そして、認証鍵リレー型キーストア４０へのアクセスが許可されたことを示す画面表示や音声出力がなされる。
次に、ステップＤ４にて、ユーザＵが端末２０を操作して、ブラウザ・アプリ２１を介して、ＷＥＢサービス１０のＷＥＢサイトにアクセスし、ログインを要求する。
次に、ステップＤ５にて、ＷＥＢサービス１０が、ブラウザ・アプリ２１、ＦＩＤＯクライアント２２、および、認証モジュールドライバ２４を介して、認証モジュール３０に対し、ＦＩＤＯの認証要求（ＦＩＤＯの認証に関する要求）を送信する。
次に、ステップＤ６にて、認証モジュール３０が、ユーザ認証の要求をユーザＵに向けて出力する。具体的には、ユーザ認証に用いるクレデンシャルの提示を促す画面表示や音声出力がなされる。
次に、ステップＤ６にて、認証モジュール３０が、ユーザ認証の要求をユーザＵに向けて出力する。具体的には、ユーザ認証に用いるクレデンシャルの提示を促す画面表示や音声出力がなされる。
次に、ステップＤ７にて、ユーザＵが端末２０を操作して、認証モジュール３０に対し、ユーザ認証のクレデンシャルが提示されるように入力される。
次に、ステップＤ８にて、認証判定モジュール３１は、入力されたクレデンシャルを用いて、ユーザ認証を検証する、つまり、ユーザＵが本人であるか否か判定する。
仮に、ユーザＵが本人（ＯＫ）であった場合、ステップＤ９にて、認証判定モジュール３１は、アサーション３０５を生成し、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、アサーション３０５およびＦＩＤＯ認証要求３０６（ステップＤ５の要求に相当）を暗号化する。
次に、ステップＤ８にて、認証判定モジュール３１は、入力されたクレデンシャルを用いて、ユーザ認証を検証する、つまり、ユーザＵが本人であるか否か判定する。
仮に、ユーザＵが本人（ＯＫ）であった場合、ステップＤ９にて、認証判定モジュール３１は、アサーション３０５を生成し、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、アサーション３０５およびＦＩＤＯ認証要求３０６（ステップＤ５の要求に相当）を暗号化する。
次に、ステップＤ１０にて、認証モジュール３０は、ＦＩＤＯクライアント２２および認証モジュールドライバ２４に対し、暗号化された、アサーション３０５およびＦＩＤＯ認証要求３０６を送信するとともに、ＷＥＢサービス認証用鍵の署名要求を送信する。ＷＥＢサービス認証用鍵とは、ＷＥＢサービス認証用公開鍵ＰＫ１およびＷＥＢサービス認証用秘密鍵ＳＫ１である。
次に、ステップＤ１１にて、ＦＩＤＯクライアント２２および認証モジュールドライバ２４は、端末側連携認証機能２５に対し、暗号化された、アサーション３０５およびＦＩＤＯ認証要求３０６を送信するとともに、ＷＥＢサービス認証用鍵の生成要求を送信する。
次に、ステップＤ１１にて、ＦＩＤＯクライアント２２および認証モジュールドライバ２４は、端末側連携認証機能２５に対し、暗号化された、アサーション３０５およびＦＩＤＯ認証要求３０６を送信するとともに、ＷＥＢサービス認証用鍵の生成要求を送信する。
次に、ステップＤ１２にて、端末側連携認証機能２５は、ＯＳ用アカウント管理機能２７に対し、暗号化用の共通鍵の生成要求を送信するとともに、暗号化されたアサーション３０３（暗号化されたＦＩＤＯ認証要求３０６も含む。）、および、（図８のステップＢ２９にて保存されている）暗号化された認証モジュール認証用公開鍵ＰＫ３を送信する。
次に、ステップＤ１３にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、暗号化された、アサーション３０５およびＦＩＤＯ認証要求３０６を、認証モジュールアサーションキーＡＫ２で復号し、アサーション検証をする。本実施形態では、アサーションの検証結果は良（ＯＫ）であったとする。
次に、ステップＤ１３にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、暗号化された、アサーション３０５およびＦＩＤＯ認証要求３０６を、認証モジュールアサーションキーＡＫ２で復号し、アサーション検証をする。本実施形態では、アサーションの検証結果は良（ＯＫ）であったとする。
図１３に示すように、次に、ステップＤ１４にて、ＯＳ用アカウント管理機能２７は、例えばＡＥＳに従う共通鍵ＣＫを生成する。また、ＯＳ用アカウント管理機能２７は、Ｃｈａｌｌｅｎｇｅ２０１（チャレンジ）を生成し、共通鍵ＣＫで暗号化する。
次に、ステップＤ１５にて、ＯＳ用アカウント管理機能２７は、暗号化された認証モジュール認証用公開鍵ＰＫ３を端末側認証モジュール毎の対称鍵ＳＹＫ１（図５のステップＡ１２参照）を用いて復号し、復号化した認証モジュール認証用公開鍵ＰＫ３を用いて共通鍵ＣＫを暗号化する。
次に、ステップＤ１５にて、ＯＳ用アカウント管理機能２７は、暗号化された認証モジュール認証用公開鍵ＰＫ３を端末側認証モジュール毎の対称鍵ＳＹＫ１（図５のステップＡ１２参照）を用いて復号し、復号化した認証モジュール認証用公開鍵ＰＫ３を用いて共通鍵ＣＫを暗号化する。
次に、ステップＤ１６にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５を介して、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１に、暗号化された共通鍵ＣＫと、暗号化されたＣｈａｌｌｅｎｇｅ２０１とを送付し、ＫＳ側連携認証機能４１が耐タンパー領域Ｒ３内に、暗号化された共通鍵ＣＫと、暗号化されたＣｈａｌｌｅｎｇｅ２０１を格納する。
次に、ステップＤ１７にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、認証モジュール認証用秘密鍵ＳＫ３を用いて、共通鍵ＣＫを復号する。
次に、ステップＤ１８にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、復号化した共通鍵ＣＫを用いて、Ｃｈａｌｌｅｎｇｅ２０１を復号し、Ｒｅｓｐｏｎｓｅ４０１を計算する。また、認証鍵リレー型キーストア４０は、Ｒｅｓｐｏｎｓｅ４０１を共通鍵ＣＫで暗号化する。
次に、ステップＤ１８にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、復号化した共通鍵ＣＫを用いて、Ｃｈａｌｌｅｎｇｅ２０１を復号し、Ｒｅｓｐｏｎｓｅ４０１を計算する。また、認証鍵リレー型キーストア４０は、Ｒｅｓｐｏｎｓｅ４０１を共通鍵ＣＫで暗号化する。
次に、ステップＤ１９にて、認証鍵リレー型キーストア４０は、ＫＳ側連携認証機能４１、および、端末２０の端末側連携認証機能２５を介して、ＯＳ用アカウント管理機能２７に対し、暗号化されたＲｅｓｐｏｎｓｅ４０１を送付する。
次に、ステップＤ２０にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、共通鍵ＣＫを用いて、暗号化されたＲｅｓｐｏｎｓｅ４０１を復号し、検証をする。本実施形態では、Ｒｅｓｐｏｎｓｅ４０１の検証結果は良（ＯＫ）であったとする。
次に、ステップＤ２０にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、共通鍵ＣＫを用いて、暗号化されたＲｅｓｐｏｎｓｅ４０１を復号し、検証をする。本実施形態では、Ｒｅｓｐｏｎｓｅ４０１の検証結果は良（ＯＫ）であったとする。
次に、ステップＤ２１にて、ＯＳ用アカウント管理機能２７は、共通鍵ＣＫを用いて、ＦＩＤＯ認証要求３０６を暗号化する。
次に、ステップＤ２２にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５を介して、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１に、暗号化されたＦＩＤＯ認証要求３０６を送付し、ＫＳ側連携認証機能４１が耐タンパー領域Ｒ３内に、暗号化されたＦＩＤＯ認証要求３０６を格納する。
次に、ステップＤ２２にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５を介して、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１に、暗号化されたＦＩＤＯ認証要求３０６を送付し、ＫＳ側連携認証機能４１が耐タンパー領域Ｒ３内に、暗号化されたＦＩＤＯ認証要求３０６を格納する。
次に、ステップＤ２３にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、（ステップＤ１７にて復号化した）共通鍵ＣＫを用いて、暗号化されたＦＩＤＯ認証要求３０６を復号する。そして、認証鍵リレー型キーストア４０は、ＦＩＤＯ認証要求３０６の処理を実施し、処理結果としてのＦＩＤＯ認証応答４０３を生成する。
次に、ステップＤ２４にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、ＷＥＢサービス認証用秘密鍵ＳＫ１を用いて、ＦＩＤＯ認証応答４０３に署名する。
次に、ステップＤ２４にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、ＷＥＢサービス認証用秘密鍵ＳＫ１を用いて、ＦＩＤＯ認証応答４０３に署名する。
次に、ステップＤ２５にて、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、共通鍵ＣＫを用いて、ＦＩＤＯ認証応答４０３を暗号化する。また、図１３および図１４に示すように、認証鍵リレー型キーストア４０のＫＳ側連携認証機能４１は、端末２０の端末側連携認証機能２５を介して、ＯＳ用アカウント管理機能２７に対し、暗号化されたＦＩＤＯ認証応答４０３を送付する。
図１４に示すように、次に、ステップＤ２６にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、共通鍵ＣＫを用いて、暗号化されたＦＩＤＯ認証応答４０３を復号する。
次に、ステップＤ２７にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、ＦＩＤＯ認証応答４０３を、認証モジュールアサーションキーＡＫ２で暗号化する。
次に、ステップＤ２７にて、ＯＳ用アカウント管理機能２７は、ＯＳ鍵処理保管領域Ｒ２内で、ＦＩＤＯ認証応答４０３を、認証モジュールアサーションキーＡＫ２で暗号化する。
次に、ステップＤ２８にて、ＯＳ用アカウント管理機能２７は、端末側連携認証機能２５、ＦＩＤＯクライアント２２および認証モジュールドライバ２４を介して、認証モジュール３０に対し、暗号化されたＦＩＤＯ認証応答４０３を送信する。
次に、ステップＤ２９にて、認証判定モジュール３１は、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、暗号化されたＦＩＤＯ認証応答４０３を復号する。
次に、ステップＤ２９にて、認証判定モジュール３１は、認証モジュールアサーションキーＡＫ１を用いて、鍵処理保管領域Ｒ１内で、暗号化されたＦＩＤＯ認証応答４０３を復号する。
次に、ステップＤ３０にて、認証モジュール３０は、ブラウザ・アプリ２１、ＦＩＤＯクライアント、および、認証モジュールドライバ２４を介して、署名付きＦＩＤＯ認証応答４０３をＷＥＢサービス１０に送信する。
次に、ステップＤ３１にて、ＷＥＢサービス１０は、ＷＥＢサービス認証用公開鍵ＰＫ１を用いて、署名付きＦＩＤＯ認証応答４０３の署名を検証する。
仮に、署名が真正であった（ＯＫ）場合、ステップＤ３２にて、ＷＥＢサービス１０は、ブラウザ・アプリ２１に対し、ＦＩＤＯの認証が完了（ＯＫ）し、ＷＥＢサイトへのログインが許可された（ＯＫ）ことを通知する。その結果、端末２０の画面を見ているユーザＵは、ユーザ認証の要求（ステップＤ６）の応答として、ＦＩＤＯの認証が完了し、ＷＥＢサイトへのログインが許可されたことを認識することができる。
以上により、シナリオＤの処理が完了する。
シナリオＤによれば、認証鍵リレー型キーストア４０で保管してあるＷＥＢサービス認証用秘密鍵ＳＫ１を利用して、ＷＥＢサービス１０のＷＥＢサイトにログインすることができる。
シナリオＤによれば、認証鍵リレー型キーストア４０で保管してあるＷＥＢサービス認証用秘密鍵ＳＫ１を利用して、ＷＥＢサービス１０のＷＥＢサイトにログインすることができる。
［認証鍵リレー型キーストアのセキュリティを高めた構成］
インターネット側では多様な攻撃が考えられ、認証鍵リレー型キーストア４０の内部の機能部やアプリケーションが乗っ取られ、不正な操作が行われる可能性がある。例えば、認証鍵リレー型キーストア４０の利用者を識別する認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、ＷＥＢサービス認証用秘密鍵ＳＫ１および認証モジュール認証用秘密鍵ＳＫ３と所定の関係を有しているため（図４参照）、この所定の関係を利用するアプリケーションが乗っ取られた場合、不正の書き換えが行われる可能性がある。
インターネット側では多様な攻撃が考えられ、認証鍵リレー型キーストア４０の内部の機能部やアプリケーションが乗っ取られ、不正な操作が行われる可能性がある。例えば、認証鍵リレー型キーストア４０の利用者を識別する認証鍵リレー型キーストアのユーザＩＤ（４２ａ）は、ＷＥＢサービス認証用秘密鍵ＳＫ１および認証モジュール認証用秘密鍵ＳＫ３と所定の関係を有しているため（図４参照）、この所定の関係を利用するアプリケーションが乗っ取られた場合、不正の書き換えが行われる可能性がある。
このような事情に鑑みて、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）と、ＷＥＢサービス認証用秘密鍵ＳＫ１および認証モジュール認証用秘密鍵ＳＫ３との関連付けを、インターネット側ではなく、ローカルネットワーク側で行う。
具体的には、図１５（ａ）に示すように、本実施形態の認証システム１００は、インターネット側に配置されている認証鍵リレー型キーストア４０（第１のキーストア）と同じ機能を備える認証鍵リレー型キーストア４０−１（第２のキーストア）をローカルネットワーク側に配置する。認証鍵リレー型キーストア４０−１が備える、ＫＳ側連携認証機能４１−１、ユーザ管理ＤＢ４２−１、アカウント管理ＷＥＢアプリ４３−１、耐タンパー領域Ｒ３−１はそれぞれ、認証鍵リレー型キーストア４０が備える、ＫＳ側連携認証機能４１、ユーザ管理ＤＢ４２、アカウント管理ＷＥＢアプリ４３、耐タンパー領域Ｒ３と同等である。
具体的には、図１５（ａ）に示すように、本実施形態の認証システム１００は、インターネット側に配置されている認証鍵リレー型キーストア４０（第１のキーストア）と同じ機能を備える認証鍵リレー型キーストア４０−１（第２のキーストア）をローカルネットワーク側に配置する。認証鍵リレー型キーストア４０−１が備える、ＫＳ側連携認証機能４１−１、ユーザ管理ＤＢ４２−１、アカウント管理ＷＥＢアプリ４３−１、耐タンパー領域Ｒ３−１はそれぞれ、認証鍵リレー型キーストア４０が備える、ＫＳ側連携認証機能４１、ユーザ管理ＤＢ４２、アカウント管理ＷＥＢアプリ４３、耐タンパー領域Ｒ３と同等である。
ローカルネットワークは、例えば、通信会社の通信キャリア網やクレジットカード会社などの厳密な本人確認を求められる事業者が独自に構築したネットワークである。そのようなローカルネットワークは、外部とは隔離されており、外部から不特定多数のアクセスを受け付けない高セキュリティな特性を持っているといえる。
認証鍵リレー型キーストア４０−１のアカウント管理ＷＥＢアプリ４３−１は、端末２０の登録、追加、変更、削除の機能を有する。アカウント管理ＷＥＢアプリ４３−１は、これらの機能を用いて、ユーザＩＤと認証モジュール認証用鍵のＩＤとの関連付けや、端末２０−認証鍵リレー型キーストア４０−１間の鍵の共有を行うことができる。
端末２０の初期登録の段階（図６〜図８に示すシナリオＢ参照）で、認証鍵リレー型キーストア４０の代わりに認証鍵リレー型キーストア４０−１が、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）と、ＷＥＢサービス認証用秘密鍵ＳＫ１および認証モジュール認証用秘密鍵ＳＫ３との関連付けを、暗号化されるように行う。具体的には、図１５（ｂ）に示すように、認証鍵リレー型キーストア４０−１は、認証鍵リレー型キーストア４０−１のユーザ管理ＤＢ４２−１が管理する情報（図４参照）のうち、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）と、認証モジュールモデルＩＤ（４２ｂ）と、認証モジュール認証用公開鍵のＩＤ（４２ｃ）と、ＫＳ側認証モジュール毎の対称鍵ＩＤ（４２ｄ）と、認証モジュール認証用秘密鍵のＩＤ（４２ｅ）を含む部分情報を、耐タンパー領域Ｒ３−１内で、認証鍵リレー型キーストア４０−１のサーバの秘密鍵ＳＫ４を用いて、一体のデータとして暗号化して、ユーザ管理ＤＢ４２−１に登録しておく。さらに、図１５（ｂ）に示すように、暗号化された一体のデータに対して、データ検索用のＩＤとして、認証鍵リレー型キーストアのユーザＩＤ（４２ａ−１）と、認証モジュールモデルＩＤ（４２ｂ−１）と、認証モジュール認証用公開鍵のＩＤ（４２ｃ−１）とを付加する。
その後、認証鍵リレー型キーストア４０−１のユーザ管理ＤＢ４２−１と、認証鍵リレー型キーストア４０のユーザ管理ＤＢ４２との間で同期処理を行い、認証鍵リレー型キーストア４０のユーザ管理ＤＢ４２を更新する。その結果、認証鍵リレー型キーストア４０のユーザ管理ＤＢ４２に、暗号化された一体のデータが登録される。
認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、サーバの公開鍵ＰＫ４を用いて、一体のデータを復号する。また、認証鍵リレー型キーストア４０は、認証モジュール認証用秘密鍵ＳＫ３を用いて、復号化した一体のデータを検証することで、正しい端末２０から送られてきたことを確認することができる。
上記のように、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）と、ＷＥＢサービス認証用秘密鍵ＳＫ１および認証モジュール認証用秘密鍵ＳＫ３との関連付けを、高セキュリティのローカルネットワーク側で行う。このため、この関連付けの不正な書き換えを未然に防ぐことができる。また、仮に、認証鍵リレー型キーストア４０（インターネット側）で不正な書き換えがなされたとしても、認証鍵リレー型キーストア４０−１のユーザ管理ＤＢ４２−１の情報と照らし合わせることで、不正な書き換えを耐タンパー領域Ｒ３内で判定することができるため、結果的には、不正な書き換えを防止することができる。
図１６を参照して、一体のデータに関する処理の続きを説明する。図１６（ａ）は、図１５（ａ）と同じである。
認証鍵リレー型キーストア４０のアカウント管理ＷＥＢアプリ４３は、ＷＥＢサービス１０またはＷＥＢサイトの登録、認証、削除の機能を有する。アカウント管理ＷＥＢアプリ４３は、これらの機能を用いて、認証鍵リレー型キーストアのユーザＩＤと、ＷＥＢサービス認証用秘密鍵のＩＤと、ＷＥＢサービスのアプリケーションＩＤとを関係付けたり、秘密鍵ＳＫ１，ＳＫ３を生成したりする。
認証鍵リレー型キーストア４０のアカウント管理ＷＥＢアプリ４３は、ＷＥＢサービス１０またはＷＥＢサイトの登録、認証、削除の機能を有する。アカウント管理ＷＥＢアプリ４３は、これらの機能を用いて、認証鍵リレー型キーストアのユーザＩＤと、ＷＥＢサービス認証用秘密鍵のＩＤと、ＷＥＢサービスのアプリケーションＩＤとを関係付けたり、秘密鍵ＳＫ１，ＳＫ３を生成したりする。
端末２０のＷＥＢサイトへの登録の段階（図９〜図１１に示すシナリオＣ参照）、または、ＷＥＢサイトでの認証の段階（図１２〜図１４に示すシナリオＤ参照）で、認証鍵リレー型キーストア４０は、耐タンパー領域Ｒ３内で、一体のデータを復号した後、復号化した一体のデータに対し、ＷＥＢサイトに関する情報を付加してユーザ管理ＤＢ４２に登録する。具体的には、認証鍵リレー型キーストア４０は、復号化した一体のデータを構成する、認証鍵リレー型キーストアのユーザＩＤ（４２ａ）と、認証モジュールモデルＩＤ（４２ｂ）と、認証モジュール認証用公開鍵のＩＤ（４２ｃ）と、ＫＳ側認証モジュール毎の対称鍵ＩＤ（４２ｄ）と、認証モジュール認証用秘密鍵のＩＤ（４２ｅ）を含む部分情報に、ＷＥＢサービス認証用秘密鍵のＩＤ（４２ｆ）と、ＷＥＢサービスのユーザＩＤ（４２ｇ）と、ＷＥＢサービスのアプリケーションＩＤ（４２ｈ）とを関連付ける。その結果、ユーザ管理ＤＢ４２が管理する情報（図４参照）と同じ構造を持つ情報が生成される。また、認証鍵リレー型キーストア４０のアカウント管理ＷＥＢアプリ４３は、生成した情報を用いて秘密鍵ＳＫ１の生成（シナリオＣ）や、秘密鍵ＳＫ１を用いた署名（シナリオＤ）などを行う。
認証鍵リレー型キーストア４０のアカウント管理ＷＥＢアプリ４３は、所定の処理が完了したら、図１６（ｂ）に示すように、ユーザ管理ＤＢ４２が管理する情報（図４参照）と同じ構造を持つ情報を、耐タンパー領域Ｒ３内で、認証鍵リレー型キーストア４０−１のサーバの秘密鍵ＳＫ４を用いて、再度、一体のデータとして暗号化して、暗号化した一体のデータをユーザ管理ＤＢ４２に出力し、保管する。このとき、暗号化された一体のデータに対して、データ検索用のＩＤとして、認証鍵リレー型キーストアのユーザＩＤ（４２ａ−１）と、認証モジュールモデルＩＤ（４２ｂ−１）と、認証モジュール認証用公開鍵のＩＤ（４２ｃ−１）とを付加しておく。
なお、認証鍵リレー型キーストア４０のユーザ管理ＤＢ４２と、認証鍵リレー型キーストア４０−１のユーザ管理ＤＢ４２−１との間で同期処理を行い、認証鍵リレー型キーストア４０−１のユーザ管理ＤＢ４２−１を更新してもよい。
なお、認証鍵リレー型キーストア４０のユーザ管理ＤＢ４２と、認証鍵リレー型キーストア４０−１のユーザ管理ＤＢ４２−１との間で同期処理を行い、認証鍵リレー型キーストア４０−１のユーザ管理ＤＢ４２−１を更新してもよい。
上記のように、認証鍵リレー型キーストア４０のユーザ管理ＤＢ４２が管理する情報を暗号化することで、外部の不正の書き換えを防ぐことができる。
（まとめ）
ユーザ認証を実行する装置（端末２０）と、ＷＥＢサービス認証用秘密鍵ＳＫ１を保有する装置（認証鍵リレー型キーストア４０）とを異ならせる場合、ユーザ認証結果とＷＥＢサービス認証用秘密鍵ＳＫ１とが当然には関連付いていないため、両者間の処理順序や関係が保証されていない。しかし、本実施形態によれば、端末２０側の認証モジュール認証用公開鍵ＰＫ３、および、認証鍵リレー型キーストア４０側の認証モジュール認証用秘密鍵ＳＫ３を用いて、ユーザ認証結果とＷＥＢサービス認証用秘密鍵ＳＫ１とを関連付けることで、両者間の処理順序や関係を一意にすることができる。従来は、秘密鍵を利用する際は認証が必要で、認証鍵リレー型キーストア４０の認証モジュール認証用秘密鍵ＳＫ３とＷＥＢサービス認証用秘密鍵ＳＫ１といった２種類の秘密鍵を利用する場合は、秘密鍵の利用ごとにユーザの認証を行い（つまり、ユーザ認証を２回実施し）、各認証で承認を得る必要があるが、本方式では、ユーザの認証から鍵の利用順序を一意にすることが可能であるため、ユーザの認証を１回実施すればよい。その結果、ＷＥＢサービス１０での認証時におけるユーザの操作量は、従来のＦＩＤＯの認証方式のときと同じにすることができる。よって、なりすましや中間者攻撃などの、認証鍵リレー型キーストア４０に直接アクセスする不正の操作を見極めて、防止することができ、高セキュリティを実現することができる。
また、鍵の処理が可能な領域が限定されていることから、平文が限定的な領域内でしか扱われないようになり、認証鍵リレー型キーストア４０の運用者でも情報の改ざん、盗聴、送受信する情報の不正利用を行うことができず、セキュリティの向上に寄与する。
また、端末２０側にＷＥＢサービス認証用秘密鍵ＳＫ１が存在しないため、ユーザによる秘密鍵ＳＫ１の紛失は起こりえず、ＷＥＢサービスの継続利用の中断を回避することができる。
したがって、ＷＥＢサービス向けのオンライン認証に用いられる鍵の紛失を回避し、ＷＥＢサービス向けのオンライン認証を確実に実行させることができる。
なお、認証システム１００に認証鍵リレー型キーストア４０を追加しても、端末２０とＷＥＢサービス１０間のＦＩＤＯ（ＵＡＦ）プロトコルに特別な追加や変更を必要としないため、認証システム１００に認証鍵リレー型キーストア４０を導入することは容易である。
ユーザ認証を実行する装置（端末２０）と、ＷＥＢサービス認証用秘密鍵ＳＫ１を保有する装置（認証鍵リレー型キーストア４０）とを異ならせる場合、ユーザ認証結果とＷＥＢサービス認証用秘密鍵ＳＫ１とが当然には関連付いていないため、両者間の処理順序や関係が保証されていない。しかし、本実施形態によれば、端末２０側の認証モジュール認証用公開鍵ＰＫ３、および、認証鍵リレー型キーストア４０側の認証モジュール認証用秘密鍵ＳＫ３を用いて、ユーザ認証結果とＷＥＢサービス認証用秘密鍵ＳＫ１とを関連付けることで、両者間の処理順序や関係を一意にすることができる。従来は、秘密鍵を利用する際は認証が必要で、認証鍵リレー型キーストア４０の認証モジュール認証用秘密鍵ＳＫ３とＷＥＢサービス認証用秘密鍵ＳＫ１といった２種類の秘密鍵を利用する場合は、秘密鍵の利用ごとにユーザの認証を行い（つまり、ユーザ認証を２回実施し）、各認証で承認を得る必要があるが、本方式では、ユーザの認証から鍵の利用順序を一意にすることが可能であるため、ユーザの認証を１回実施すればよい。その結果、ＷＥＢサービス１０での認証時におけるユーザの操作量は、従来のＦＩＤＯの認証方式のときと同じにすることができる。よって、なりすましや中間者攻撃などの、認証鍵リレー型キーストア４０に直接アクセスする不正の操作を見極めて、防止することができ、高セキュリティを実現することができる。
また、鍵の処理が可能な領域が限定されていることから、平文が限定的な領域内でしか扱われないようになり、認証鍵リレー型キーストア４０の運用者でも情報の改ざん、盗聴、送受信する情報の不正利用を行うことができず、セキュリティの向上に寄与する。
また、端末２０側にＷＥＢサービス認証用秘密鍵ＳＫ１が存在しないため、ユーザによる秘密鍵ＳＫ１の紛失は起こりえず、ＷＥＢサービスの継続利用の中断を回避することができる。
したがって、ＷＥＢサービス向けのオンライン認証に用いられる鍵の紛失を回避し、ＷＥＢサービス向けのオンライン認証を確実に実行させることができる。
なお、認証システム１００に認証鍵リレー型キーストア４０を追加しても、端末２０とＷＥＢサービス１０間のＦＩＤＯ（ＵＡＦ）プロトコルに特別な追加や変更を必要としないため、認証システム１００に認証鍵リレー型キーストア４０を導入することは容易である。
また、本実施形態によれば、画面ロック解除によるユーザ認証の成功が実現したときのみ認証鍵リレー型キーストア４０へのアクセスが可能となるような仕組みを導入することができる。よって、外部のアプリケーションなどから認証モジュール認証用公開鍵ＰＫ３へのアクセスを制限し、不正な鍵の利用を防止することができ、さらにセキュリティを向上させることができる。
また、本実施形態によれば、保有する情報を厳重に管理しているローカルネットワーク側に配置した認証鍵リレー型キーストア４０−１が、端末２０のユーザの初期登録を行うため、外部からの機能の乗っ取りなどの不正な操作をさらに困難にすることができ、さらにセキュリティを向上させることができる。
≪その他≫
（１）：本実施形態において、ＷＥＢサービス１０が端末２０のユーザを登録する際（図９〜図１１に示すシナリオＣ）、または、ＷＥＢサービス１０にアクセスしようとする端末のユーザを認証する際（図１２〜図１３に示すシナリオＤ）、端末２０が認証モジュール認証用公開鍵ＰＫ３を有しており、かつ、認証鍵リレー型キーストア４０が認証モジュール認証用秘密鍵ＳＫ３を有している、という鍵の持ち合いを、端末２０と認証鍵リレー型キーストア４０との間で確認することができる。その確認の結果、鍵の持ち合いが成立していないとき（公開鍵ＰＫ３、秘密鍵ＳＫ３の一方または両方が消失しているとき）、ＷＥＢサービス１０が端末２０のユーザを登録する際（シナリオＣ）、または、ＷＥＢサービス１０にアクセスしようとする端末のユーザを認証する際（シナリオＤ）、端末２０と認証鍵リレー型キーストア４０との間で鍵の持ち合いを成立させる（公開鍵ＰＫ３および秘密鍵ＳＫ３を復旧させる）処理を実行することができる。端的にいえば、シナリオＣ，Ｄの段階で、シナリオＢの初期登録（図６〜図８参照）を改めて実行する。
（１）：本実施形態において、ＷＥＢサービス１０が端末２０のユーザを登録する際（図９〜図１１に示すシナリオＣ）、または、ＷＥＢサービス１０にアクセスしようとする端末のユーザを認証する際（図１２〜図１３に示すシナリオＤ）、端末２０が認証モジュール認証用公開鍵ＰＫ３を有しており、かつ、認証鍵リレー型キーストア４０が認証モジュール認証用秘密鍵ＳＫ３を有している、という鍵の持ち合いを、端末２０と認証鍵リレー型キーストア４０との間で確認することができる。その確認の結果、鍵の持ち合いが成立していないとき（公開鍵ＰＫ３、秘密鍵ＳＫ３の一方または両方が消失しているとき）、ＷＥＢサービス１０が端末２０のユーザを登録する際（シナリオＣ）、または、ＷＥＢサービス１０にアクセスしようとする端末のユーザを認証する際（シナリオＤ）、端末２０と認証鍵リレー型キーストア４０との間で鍵の持ち合いを成立させる（公開鍵ＰＫ３および秘密鍵ＳＫ３を復旧させる）処理を実行することができる。端的にいえば、シナリオＣ，Ｄの段階で、シナリオＢの初期登録（図６〜図８参照）を改めて実行する。
不正の操作を防止するという観点からいえば、ＷＥＢサービス１０の登録時・認証時には、ＷＥＢサービス１０向けのユーザ認証に加え、端末２０が認証鍵リレー型キーストア４０にアクセスするときに認証鍵リレー型キーストア４０側でのユーザ認証も行う必要がある。つまり、ユーザ認証を２回行う必要がある。しかし、本実施形態によれば、ＷＥＢサービス１０でのユーザの登録の段階、または、ＷＥＢサービス１０にアクセスしようとする端末２０のユーザの認証の段階にて、端末２０と認証鍵リレー型キーストア４０との間で鍵の持ち合いを確実に実現するため、端末２０の画面ロック解除が認証鍵リレー型キーストア４０側でのユーザ認証を兼ねるようにすることで、鍵の持ち合いの成立後は、ＷＥＢサービス１０向けのユーザ認証だけで済ませることができ、処理負荷を低減することができる。
（２）：なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上述文書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
（３）：また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
また、本実施形態で説明した種々の技術を適宜組み合わせた技術を実現することもできる。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
その他、ハードウェア、ソフトウェア、フローチャートなどについて、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
１００ 認証システム
１ メタデータサービス
３ 認証モジュールの情報
１０ ＷＥＢサービス
２０ 端末
２３ 認証管理情報
２５ 端末側連携認証機能
２６ 画面ロック解除機能
２７ ＯＳ用アカウント管理機能
２８ アカウント管理情報
３０ 認証モジュール
３１ 認証判定モジュール
４０ 認証鍵リレー型キーストア（キーストア：第１のキーストア）
４０−１ 認証鍵リレー型キーストア（第２のキーストア）
４１ ＫＳ側連携認証機能
４２ ユーザ管理ＤＢ
４３ アカウント管理ＷＥＢアプリ
５０ 認証局
ＰＫ１ ＷＥＢサービス認証用公開鍵
ＳＫ１ ＷＥＢサービス認証用秘密鍵
ＰＫ２ メタデータサービス向け公開鍵
ＳＫ２ メタデータサービス向け秘密鍵
ＰＫ３ 認証モジュール認証用公開鍵
ＳＫ３ 認証モジュール認証用秘密鍵
ＰＫ４ サーバの公開鍵
ＳＫ４ サーバの秘密鍵
１ メタデータサービス
３ 認証モジュールの情報
１０ ＷＥＢサービス
２０ 端末
２３ 認証管理情報
２５ 端末側連携認証機能
２６ 画面ロック解除機能
２７ ＯＳ用アカウント管理機能
２８ アカウント管理情報
３０ 認証モジュール
３１ 認証判定モジュール
４０ 認証鍵リレー型キーストア（キーストア：第１のキーストア）
４０−１ 認証鍵リレー型キーストア（第２のキーストア）
４１ ＫＳ側連携認証機能
４２ ユーザ管理ＤＢ
４３ アカウント管理ＷＥＢアプリ
５０ 認証局
ＰＫ１ ＷＥＢサービス認証用公開鍵
ＳＫ１ ＷＥＢサービス認証用秘密鍵
ＰＫ２ メタデータサービス向け公開鍵
ＳＫ２ メタデータサービス向け秘密鍵
ＰＫ３ 認証モジュール認証用公開鍵
ＳＫ３ 認証モジュール認証用秘密鍵
ＰＫ４ サーバの公開鍵
ＳＫ４ サーバの秘密鍵
Claims (6)
- ユーザ認証を行う認証モジュールを備える端末と、前記端末が利用するＷＥＢサービスと、所定の鍵を保有するキーストアと、が通信可能に接続されている認証システムであって、
前記ＷＥＢサービスは、前記端末が前記ＷＥＢサービスにアクセスするための認証に用いられるＷＥＢサービス認証用公開鍵を有しており、
前記キーストアは、前記ＷＥＢサービス認証用公開鍵の対となるＷＥＢサービス認証用秘密鍵、および、前記認証モジュールの認証に用いられる認証モジュール認証用秘密鍵を、耐タンパー領域内に閉じ込めており、
前記端末は、前記認証モジュール認証用秘密鍵の対となる認証モジュール認証用公開鍵を有しており、
前記認証モジュール認証用公開鍵および前記認証モジュール認証用秘密鍵を用いて処理される情報を、前記端末と前記キーストアとの間で暗号化して送受信する、
ことを特徴とする認証システム。 - 前記端末に設定された画面ロックが解除されたことによるユーザ認証を、前記キーストアにアクセスするための前記認証モジュール認証用公開鍵を利用する権限を与える認証とする、
ことを特徴とする請求項１に記載の認証システム。 - 前記ＷＥＢサービスが前記端末のユーザを登録する際、または、前記ＷＥＢサービスにアクセスしようとする前記端末のユーザを認証する際、
前記端末が前記認証モジュール認証用公開鍵を有しており、かつ、前記キーストアが前記認証モジュール認証用秘密鍵を有している、という鍵の持ち合いを、前記端末と前記キーストアとの間で確認し、
前記鍵の持ち合いが成立していないとき、前記ＷＥＢサービスが前記端末のユーザを登録する際、または、前記ＷＥＢサービスにアクセスしようとする前記端末のユーザを認証する際、前記端末と前記キーストアとの間で前記鍵の持ち合いを成立させる処理を実行する、
ことを特徴とする請求項２に記載の認証システム。 - 前記キーストアを第１のキーストアとしてインターネット側に配置し、所定の鍵を保有する第２のキーストアをローカルネットワーク側に配置し、
前記端末のユーザの初期登録に関する処理を前記第２のキーストアで実行し、前記第２のキーストアで実行したときの処理結果を暗号化して、前記第１のキーストアに送信する、
ことを特徴とする請求項１から請求項３のいずれか１項に記載の認証システム。 - ユーザ認証を行う認証モジュールを備える端末と、前記端末が利用するＷＥＢサービスと、所定の鍵を保有するキーストアと、が通信可能に接続されている認証システムにおける鍵処理連携方法であって、
前記ＷＥＢサービスが、前記端末が前記ＷＥＢサービスにアクセスするための認証に用いられるＷＥＢサービス認証用公開鍵を有し、前記キーストアが、前記ＷＥＢサービス認証用公開鍵の対となるＷＥＢサービス認証用秘密鍵を耐タンパー領域内に閉じ込める、という態様において、
前記キーストアが、
前記認証モジュールの認証に用いられる、認証モジュール認証用秘密鍵および認証モジュール認証用公開鍵を生成し、前記認証モジュール認証用公開鍵を前記端末に送信するステップと、
前記認証モジュール認証用公開鍵および前記認証モジュール認証用秘密鍵を用いて処理される情報を、前記端末と前記キーストアとの間で暗号化して送受信するステップ、とを実行する、
ことを特徴とする鍵処理連携方法。 - ユーザ認証を行う認証モジュールを備える端末と、前記端末が利用するＷＥＢサービスと、所定の鍵を保有するキーストアと、が通信可能に接続されている認証システムの前記キーストアとしてのコンピュータを、
前記ＷＥＢサービスが、前記端末が前記ＷＥＢサービスにアクセスするための認証に用いられるＷＥＢサービス認証用公開鍵を有し、前記キーストアが、前記ＷＥＢサービス認証用公開鍵の対となるＷＥＢサービス認証用秘密鍵を耐タンパー領域内に閉じ込める、という態様において、
前記認証モジュールの認証に用いられる、認証モジュール認証用秘密鍵および認証モジュール認証用公開鍵を生成し、前記認証モジュール認証用公開鍵を前記端末に送信する手段と、
前記認証モジュール認証用公開鍵および前記認証モジュール認証用秘密鍵を用いて処理される情報を、前記端末と前記キーストアとの間で暗号化して送受信する手段、
として機能させるための鍵処理連携プログラム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016032659A JP6438901B2 (ja) | 2016-02-24 | 2016-02-24 | 認証システム、鍵処理連携方法、および、鍵処理連携プログラム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2016032659A JP6438901B2 (ja) | 2016-02-24 | 2016-02-24 | 認証システム、鍵処理連携方法、および、鍵処理連携プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2017152880A true JP2017152880A (ja) | 2017-08-31 |
| JP6438901B2 JP6438901B2 (ja) | 2018-12-19 |
Family
ID=59739767
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2016032659A Active JP6438901B2 (ja) | 2016-02-24 | 2016-02-24 | 認証システム、鍵処理連携方法、および、鍵処理連携プログラム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP6438901B2 (ja) |
Cited By (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP3490220A1 (en) * | 2017-11-22 | 2019-05-29 | Canon Kabushiki Kaisha | Information processing apparatus |
| JP2021504860A (ja) * | 2017-11-27 | 2021-02-15 | ノック ノック ラブズ， インコーポレイテッド | トランザクション確認及び暗号通貨のためのセキュアな鍵記憶装置の拡張 |
| US11563738B2 (en) | 2019-09-10 | 2023-01-24 | Fujitsu Limited | Control method and information processing apparatus |
| US11792024B2 (en) | 2019-03-29 | 2023-10-17 | Nok Nok Labs, Inc. | System and method for efficient challenge-response authentication |
| US11831409B2 (en) | 2018-01-12 | 2023-11-28 | Nok Nok Labs, Inc. | System and method for binding verifiable claims |
| US11909892B2 (en) | 2018-12-12 | 2024-02-20 | Nec Corporation | Authentication system, client, and server |
| US11929997B2 (en) | 2013-03-22 | 2024-03-12 | Nok Nok Labs, Inc. | Advanced authentication techniques and applications |
| KR102654886B1 (ko) | 2017-11-27 | 2024-04-04 | 노크 노크 랩스, 인코포레이티드 | 트랜잭션 확인 및 암호화폐를 위한 보안 키 저장소의 확장 |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004032311A (ja) * | 2002-06-25 | 2004-01-29 | Nec Corp | Ｐｋｉ対応の証明書確認処理方法及びその装置、並びにｐｋｉ対応の証明書確認処理プログラム |
| US20140258712A1 (en) * | 2012-06-25 | 2014-09-11 | At&T Intellectual Property I, L.P. | Secure Socket Layer Keystore and Truststore Generation |
| US20140335827A1 (en) * | 2011-02-16 | 2014-11-13 | Sony Mobile Communications Inc. | Display processing apparatus |
-
2016
- 2016-02-24 JP JP2016032659A patent/JP6438901B2/ja active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2004032311A (ja) * | 2002-06-25 | 2004-01-29 | Nec Corp | Ｐｋｉ対応の証明書確認処理方法及びその装置、並びにｐｋｉ対応の証明書確認処理プログラム |
| US20140335827A1 (en) * | 2011-02-16 | 2014-11-13 | Sony Mobile Communications Inc. | Display processing apparatus |
| US20140258712A1 (en) * | 2012-06-25 | 2014-09-11 | At&T Intellectual Property I, L.P. | Secure Socket Layer Keystore and Truststore Generation |
Non-Patent Citations (4)
| Title |
|---|
| 中谷 裕一 ほか: "運用性とコストを考慮したセキュアなユーザ認証方式の提案", 電子情報通信学会２０１５年総合大会講演論文集 通信２, vol. Ｂ−７−８６, JPN6018044005, 24 February 2015 (2015-02-24), JP, pages 236, ISSN: 0003915558 * |
| 植田 広樹 ほか: "鍵管理システム −ＰＫＩの容易な適用に向けて−", ＮＴＴ Ｒ＆Ｄ, vol. 第４９巻 第１１号, JPN6009040946, 10 November 2000 (2000-11-10), JP, pages 668 - 677, ISSN: 0003915559 * |
| 緒方 祐介 ほか: "ＷＥＢサービス向けの鍵による認証における鍵の管理に関する考察", 電子情報通信学会２０１５年総合大会講演論文集 通信２, vol. ＢＳ−４−４, JPN6018044004, 24 February 2015 (2015-02-24), JP, pages 127, ISSN: 0003915557 * |
| 緒方 祐介 ほか: "公開鍵秘密鍵を用いた認証方式に関するセキュリティ、利便性、運用性における一考察", 電子情報通信学会技術研究報告, vol. 115, no. 252, JPN6017016807, 8 October 2015 (2015-10-08), JP, pages 13 - 18, ISSN: 0003915556 * |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11929997B2 (en) | 2013-03-22 | 2024-03-12 | Nok Nok Labs, Inc. | Advanced authentication techniques and applications |
| EP3490220A1 (en) * | 2017-11-22 | 2019-05-29 | Canon Kabushiki Kaisha | Information processing apparatus |
| KR20190059219A (ko) * | 2017-11-22 | 2019-05-30 | 캐논 가부시끼가이샤 | 정보 처리 장치, 정보 처리 장치를 위한 방법, 및 프로그램 기억 매체 |
| US11093602B2 (en) | 2017-11-22 | 2021-08-17 | Canon Kabushiki Kaisha | Information processing apparatus, method for information processing apparatus, and program storage medium |
| KR102393024B1 (ko) * | 2017-11-22 | 2022-05-02 | 캐논 가부시끼가이샤 | 정보 처리 장치, 정보 처리 장치를 위한 방법, 및 프로그램 기억 매체 |
| US11868995B2 (en) | 2017-11-27 | 2024-01-09 | Nok Nok Labs, Inc. | Extending a secure key storage for transaction confirmation and cryptocurrency |
| JP7391860B2 (ja) | 2017-11-27 | 2023-12-05 | ノック ノック ラブズ， インコーポレイテッド | トランザクション確認及び暗号通貨のためのセキュアな鍵記憶装置の拡張 |
| JP2021504860A (ja) * | 2017-11-27 | 2021-02-15 | ノック ノック ラブズ， インコーポレイテッド | トランザクション確認及び暗号通貨のためのセキュアな鍵記憶装置の拡張 |
| KR102654886B1 (ko) | 2017-11-27 | 2024-04-04 | 노크 노크 랩스, 인코포레이티드 | 트랜잭션 확인 및 암호화폐를 위한 보안 키 저장소의 확장 |
| US11831409B2 (en) | 2018-01-12 | 2023-11-28 | Nok Nok Labs, Inc. | System and method for binding verifiable claims |
| US11909892B2 (en) | 2018-12-12 | 2024-02-20 | Nec Corporation | Authentication system, client, and server |
| US11792024B2 (en) | 2019-03-29 | 2023-10-17 | Nok Nok Labs, Inc. | System and method for efficient challenge-response authentication |
| US11563738B2 (en) | 2019-09-10 | 2023-01-24 | Fujitsu Limited | Control method and information processing apparatus |
Also Published As
| Publication number | Publication date |
|---|---|
| JP6438901B2 (ja) | 2018-12-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6586446B2 (ja) | 通信端末および関連システムのユーザーの識別情報を確認するための方法 | |
| US20190140844A1 (en) | Identity-linked authentication through a user certificate system | |
| JP6438901B2 (ja) | 認証システム、鍵処理連携方法、および、鍵処理連携プログラム | |
| US20190173873A1 (en) | Identity verification document request handling utilizing a user certificate system and user identity document repository | |
| KR102202547B1 (ko) | 액세스 요청을 검증하기 위한 방법 및 시스템 | |
| CN110990827A (zh) | 一种身份信息验证方法、服务器及存储介质 | |
| CN106453361B (zh) | 一种网络信息的安全保护方法及系统 | |
| KR20110057128A (ko) | 휴대용 장치 연결 | |
| US8397281B2 (en) | Service assisted secret provisioning | |
| US11424915B2 (en) | Terminal registration system and terminal registration method with reduced number of communication operations | |
| CN109716725B (zh) | 数据安全系统及其操作方法和计算机可读存储介质 | |
| US11722303B2 (en) | Secure enclave implementation of proxied cryptographic keys | |
| EP3766267A1 (en) | Trust extension in a secure communication framework | |
| US20140250499A1 (en) | Password based security method, systems and devices | |
| US20240039707A1 (en) | Mobile authenticator for performing a role in user authentication | |
| CN112733129A (zh) | 一种服务器带外管理的可信接入方法 | |
| CN115473655B (zh) | 接入网络的终端认证方法、装置及存储介质 | |
| KR101996317B1 (ko) | 인증변수를 이용한 블록체인 기반의 사용자 인증 시스템 및 그 방법 | |
| KR102053993B1 (ko) | 인증서를 이용한 사용자 인증 방법 | |
| KR101619928B1 (ko) | 이동단말기의 원격제어시스템 | |
| KR102288445B1 (ko) | 단체용 인증모듈의 온보딩 방법, 장치 및 프로그램 | |
| CA3172049A1 (en) | Exporting remote cryptographic keys | |
| KR102288444B1 (ko) | 인증모듈의 펌웨어 업데이트 방법, 장치 및 프로그램 | |
| JP2013073627A (ja) | Ｐｃアクセス制御方法、それを含むモジュール、サーバ、及びシステム | |
| TWI778319B (zh) | 跨平台授權存取資源方法及授權存取系統 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180220 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20181018 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20181113 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20181119 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6438901 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |