JP2018137587A - 認証鍵共有システムおよび認証鍵共有方法 - Google Patents

Abstract

【課題】端末間で秘密鍵のコピーを行うことなく、認証用秘密鍵の共有を実現する認証鍵共有システムおよび認証鍵共有方法を提供する。
【解決手段】認証鍵共有システム１は、端末１０が、セキュア領域１２内において、所有者からのマスタコードの入力を受付けるマスタコード管理部１２４と、第三者サーバ２０が生成・保管するランダム文字列からなるサブコードを、第三者サーバ２０から払出しさせて取得するサブコード管理部１２５と、マスタコードとサブコードとの組み合わせを用いて、同一所有者の端末１０上では同じとなる入力文字列を生成し、当該入力文字列から派生させて秘密鍵を生成する秘密鍵生成ロジック１２３と、を備える。
【選択図】図１

Description

本発明は、認証鍵共有システムおよび認証鍵共有方法に関する。

インターネットの利用者は、パソコンやスマートフォン、タブレット端末等の複数の端末を使って、オンラインバンキングやネットショッピング等の各種Ｗｅｂサービスを利用している。Ｗｅｂサービスを利用するときには、利用者認証が必要であり、利用者ＩＤ（IDentifier、識別子）とパスワードを用いるのが一般的である。
しかしながら、安易に設定したパスワードが推測されてしまう、不正アクセスによりＷｅｂサービスサーバからパスワードが漏洩してしまうなどして、パスワードが盗まれてしまう事件が多発している。

パスワード認証に替わる利用者認証技術として、パスワードレス認証のデファクト標準技術（ＦＩＤＯ：Fast IDentity Online）という、公開鍵暗号を用いたＷｅｂサービスの利用者認証技術がある。ＦＩＤＯでは、サービス毎に異なる公開鍵・秘密鍵ペアを生成し、公開鍵をサービスサイト側に配置して、秘密鍵を端末内のセキュア領域に閉じ込めておく。秘密鍵の利用（チャレンジ・レスポンス認証における署名等）は端末上で生体認証を行うことが前提となっており、かつ、秘密鍵の利用はセキュア領域内で行われ、端末外に秘密鍵が出ていくことはないことからセキュリティが高い。
ＦＩＤＯでは、利用者認証の前段階として、利用者が所有する端末が公開鍵暗号の秘密鍵と公開鍵のペアを生成して、秘密鍵を端末に保管し、公開鍵をＷｅｂサービスサーバに登録する。公開鍵を登録するときには、Ｗｅｂサービスサーバが利用者の本人確認を行う。
Ｗｅｂサービスサーバが利用者を認証するときには、（１）Ｗｅｂサービスサーバが乱数を生成して端末に送信し、（２）端末が秘密鍵を用いて乱数に署名してＷｅｂサービスサーバに送信し、（３）Ｗｅｂサービスサーバが署名を検証する。（３）の署名検証が成功すれば、利用者認証が成功したことになり、利用者はＷｅｂサービスを利用することができる。

ＦＩＤＯでは、秘密鍵が不正に持ち出されたり利用されたりすることがないように、端末のセキュア領域に秘密鍵が保管されることを求めている。秘密鍵がセキュア領域に保管されることで、盗まれたり、正規の秘密鍵所有者以外に利用されたり、マルウェアのような不正なプログラムからアクセスされたりすることを防ぐことができる。しかし、秘密鍵がセキュア領域から一切取り出せないとすると、正規の利用者が別の端末からＷｅｂサービスサーバにアクセスすることができなくなってしまうという問題が生じる。すなわち、複数の端末からＷｅｂサービスを利用できない。

図８は、ＦＩＤＯ対応の複数端末を利用するときに生じる問題を説明する図である。
図８に示すように、利用者は端末Ｘ９１を使ってサービスＡサーバ９８とサービスＢサーバ９９にアクセスしている。サービスＡサーバ９８には公開鍵Ａ９８１が、サービスＢサーバ９９には公開鍵Ｂ９９１が登録済みである。公開鍵Ａ９８１とペアになる秘密鍵Ａ９１２と、公開鍵Ｂ９９１とペアになる秘密鍵Ｂ９１３とは、端末Ｘ９１のセキュア領域９１１に格納されている。
ただし、新しい端末を利用する場合、セキュア領域９２１内には鍵がないことから、サービス毎に再度鍵ペアの生成・登録を行う必要があり、複数の端末を使う場合、端末数×サービス数だけ登録作業が必要となり、利便性が低い。

例えば、利用者が新しい端末Ｙ９２からサービスＡサーバ９８にアクセスするには、端末Ｙ９２のセキュア領域９２１に秘密鍵Ａ９１２を格納する必要がある。しかし、端末Ｘ９１のセキュア領域９１１から秘密鍵Ａ９１２が取り出せない（端末Ｙ９２のセキュア領域９２１にコピーできない）ので、端末Ｙ９２では利用者認証ができない。サービスＢサーバ９９についても同様である。利用者が端末Ｙ９２からサービスＡサーバ９８とサービスＢサーバ９９にアクセスするには、端末Ｙ９２からサービスＡサーバ９８とサービスＢサーバ９９に対して公開鍵の再登録が必要となる。再登録は、サービス数（サーバ台数）×端末数の分だけ必要であり、本人確認を含めて大きな手間となる。

この新しい端末を導入する（複数端末を利用する）ときの再登録の問題を解決する技術として、端末間でセキュアな鍵の共有を行う非特許文献１に記載の技術がある。
非特許文献１には、第三者が端末所有者の本人確認を行った上で、所有者証明書を端末に発行することを前提として、所有者が同一である所有者証明書（非特許文献１記載のユーザ証明書）が発行された端末間に限っては秘密鍵のコピー（複製）を可能とする手法が示されている。

図９は、所有者証明書を用いたセキュア領域間の秘密鍵コピーを説明する図である。
図９に示すように、端末ＸＸ９３は、所有者証明書に対応したセキュア領域９３１を、端末ＹＹ９４は所有者証明書に対応したセキュア領域９４１を、それぞれ備えている。端末管理サーバ１００は、端末ＸＸ９３の所有者の本人確認をしたうえで、所有者証明書Ｘ９３４を発行する。発行された所有者証明書Ｘ９３４は端末ＸＸ９３のセキュア領域９３１に格納される。端末ＹＹ９４についても同様であり、端末管理サーバ１００から発行された所有者証明書Ｙ９４４は、セキュア領域９４１に格納される。

所有者証明書Ｘ９３４に示される所有者と所有者証明書Ｙ９４４に示される所有者とが一致したときに端末ＸＸ９３のセキュア領域９３１から端末ＹＹ９４のセキュア領域９４１へ秘密鍵Ａ９１２と秘密鍵Ｂ９１３がコピー可能となる。利用者はコピーされた秘密鍵Ａ９４２と秘密鍵Ｂ９４３を用いて、端末ＹＹ９４からサービスＡサーバ９８とサービスＢサーバ９９に対して認証可能となる。所有者証明書を用いた秘密鍵コピーにより公開鍵の再登録は不要となる。

図１０は、標準技術（ＦＩＤＯ）において端末に求められる機能を説明する図である。
図１０に示すように、端末９５は、Ｗｅｂアプリ９５１と、ＦＩＤＯクライアント９５２と、FIDO Authenticator（図１０の破線内参照）に対応したセキュア領域９５３と、を備える。
セキュア領域９５３には、秘密鍵生成部９５４、秘密鍵利用部９５５、秘密鍵保管部９５６、および生体認証部９５９が備えられる。秘密鍵保管部９５６には、公開鍵Ａとペアになる秘密鍵Ａ９５７と、公開鍵Ｂとペアになる秘密鍵Ｂ９５８とが格納されている。

ＦＩＤＯクライアント９５２は、Ｗｅｂアプリ９５１の秘密鍵生成要求に従って秘密鍵生成部９５４に秘密鍵生成要求を発行する。秘密鍵生成部９５４は、通常領域のＦＩＤＯクライアント９５２からの指示を受け、秘密鍵の生成を行う。
また、ＦＩＤＯクライアント９５２は、Ｗｅｂアプリ９５１の認証時の署名要求に従って秘密鍵利用部９５５に署名要求を発行する。秘密鍵利用部９５５は、通常領域のＦＩＤＯクライアント９５２からの指示を受け、秘密鍵の利用（署名、暗号化、復号化等）を行う。
秘密鍵保管部９５６は、秘密鍵生成部９５４により生成された、または秘密鍵利用部９５５により利用された秘密鍵Ａ９５７と秘密鍵Ｂ９５８を格納する。
生体認証部９５９は、通常領域のＦＩＤＯクライアント９５２からの指示を受け、生体（指紋、虹彩）認証等のユーザ認証を実行する。

図１１は、従来の認証鍵の共有手法（鍵コピー）において端末に求められる機能を説明する図である。
図１１に示すように、端末９６は、Ｗｅｂアプリ９６１と、ＦＩＤＯクライアント９６２と、セキュア領域９６３と、を備える。セキュア領域９６３には、FIDO Authenticator（図１１の破線内参照）に対応した秘密鍵生成部９６４、秘密鍵利用部９６５、秘密鍵保管部９６６および生体認証部９６９と、コピー（複製）のための追加機能（図１１の一点鎖線内参照）として秘密鍵コピー送信部９７０および（発行、保管、比較等）の証明書管理部９７１とが備えられる。秘密鍵保管部９６６は、秘密鍵Ａ９６７と秘密鍵Ｂ９６８とを格納する。

秘密鍵コピー送信部９７０は、セキュア領域９６３において、証明書管理部９７１からの要求に従って証明書管理部９７１に秘密鍵保管部９６６に格納されている秘密鍵Ａ９６７と秘密鍵Ｂ９６８を送信する。証明書管理部９７１は、秘密鍵Ａ９６７と秘密鍵Ｂ９６８を用いて証明書の発行、保管、比較等を行う。
一方、秘密鍵コピー送信部９７０は、他端末９７からの秘密鍵コピー要求を受付け、秘密鍵を他端末９７に送信する。
上記コピーのための追加機能は、必要な追加機能の規模が大きく、また、セキュリティ担保のために高い品質が求められることから、高コストとなる。

緒方祐介、大森芳彦、山下高生、岩田哲弥、"非対称鍵を利用した認証方式の秘密鍵の維持管理に関する考察", 電子情報通信学会通信ソサイエティ大会、B-7-9、2016．

従来の認証鍵の共有手法（鍵コピー）を実現するためには、図１１の一点鎖線に示すように、秘密鍵をコピーする機能を端末９６内に追加実装する必要がある。しかし、以下の理由から、コピーのための機能を追加実装することはコストが高いことが想定され、普及の疎外となることが懸念される。
ＦＩＤＯ標準実装は、秘密鍵の端末外への取り出しを想定していないため、本機能は完全に新規に実装すべき機能である。秘匿性の高い認証情報を取り扱う機能は、端末のセキュア領域（ＴＥＥ：Trusted Execution Environment）内で実行することが求められる。しかしながら、ＴＥＥでは通常の実行環境（Android等）と比較して限られた開発環境しか提供されておらず、大規模な機能をＴＥＥアプリケーションとして開発するコストは高い。しかも、秘密鍵を外部に送信するインタフェースを持つことから、セキュリティを十分に考慮した設計（送信時の暗号化処理、コピー先端末の認証処理等）が必要となる。また、悪用されないよう堅牢である要求があり、高いソフトウェア品質が必要となる。

このような背景を鑑みて本発明がなされたのであり、本発明は、端末間で秘密鍵のコピーを行うことなく、認証用秘密鍵の共有を実現する認証鍵共有システムおよび認証鍵共有方法を提供することを課題とする。

前記した課題を解決するため、請求項１に記載の発明は、秘密鍵を用いて認証する複数の端末と、前記端末の所有者の本人確認を行う第三者サーバとが、通信ネットワークを介して接続され、複数端末間で認証用秘密鍵を共有する認証鍵共有システムであって、前記端末は、外部から不正に侵入できないように管理された領域であるセキュア領域を有し、前記セキュア領域内において、前記所有者からのマスタコードの入力を受付けるマスタコード管理部と、前記第三者サーバが生成・保管するランダム文字列からなるサブコードを、前記第三者サーバから払出しさせて取得するサブコード管理部と、前記マスタコードと前記サブコードとの組み合わせを用いて、同一所有者の端末上では同じとなる入力文字列を生成し、当該入力文字列をもとに秘密鍵を生成する秘密鍵生成部と、を備えることを特徴とする認証鍵共有システムとした。

また、請求項４に記載の発明は、秘密鍵を用いて認証する複数の端末と、前記端末の所有者の本人確認を行う第三者サーバとが、通信ネットワークを介して接続され、複数端末間で認証用秘密鍵を共有する認証鍵共有システムの認証鍵共有方法であって、前記端末は、外部から不正に侵入できないように管理された領域であるセキュア領域を有し、前記セキュア領域内において、前記所有者からのマスタコードの入力を受付けるステップと、前記第三者サーバが生成・保管するランダム文字列からなるサブコードを、前記第三者サーバから払出させて取得するステップと、前記マスタコードと前記サブコードとの組み合わせを用いて、同一所有者の端末上では同じとなる入力文字列を生成し、当該入力文字列をもとに秘密鍵を生成するステップと、を実行する認証鍵共有方法とした。

このようにすることで、認証鍵共有システムは、端末間で秘密鍵のコピーを行うのではなく、同一所有者の端末上では同じ秘密鍵を生成可能とする。これにより、端末間の直接のやり取りがなく鍵の共有が可能となり、複数端末間での秘密鍵の共有を実現することができる。また、サービス毎の鍵の登録作業は端末数に依らず一度だけ行えばよくなる。

請求項２に記載の発明は、前記端末は、前記入力文字列を生成するための前記サブコードを前記第三者サーバに保管させることを特徴とする請求項１に記載の認証鍵共有システムとした。

このように、分散保管することで、単一の攻撃により、入力文字列全体が盗難されることを困難にすることができ、攻撃への耐性を高めることができる。

請求項３に記載の発明は、前記第三者サーバは、他の前記端末の前記サブコード管理部からの前記サブコードの発行要求に応答して、保管した前記サブコードを払出しすることを特徴とする請求項２に記載の認証鍵共有システムとした。

このようにすることで、サブコードの払出しには、第三者サーバの本人確認が必須となるので、意図しない不正な鍵の共有を防止することができる。仮に第三者サーバが攻撃を受け、サブコードが流出したとしても、マスタコードと両方が揃わないと鍵を生成できない。

本発明によれば、端末間で秘密鍵のコピーを行うことなく、認証用秘密鍵の共有を実現する認証鍵共有システムおよび認証鍵共有方法を提供することができる。

本発明の実施形態に係る認証鍵共有システムを示す構成図である。 本実施形態に係る認証鍵共有システムを構成する端末のサブコード管理テーブルの一例を示す図である。 本実施形態に係る認証鍵共有システムの認証鍵共有方法の動作概要を示す図である。 本実施形態に係る認証鍵共有システムが実行する、事前処理（マスタ／サブコード設定）の流れを示すシーケンス図である。 本実施形態に係る認証鍵共有システムが実行する、鍵の登録処理を示すシーケンス図である。 本実施形態に係る認証鍵共有システムを構成する端末の秘密鍵生成部により実行される、入力文字列からの非対称鍵生成プロセスを説明する図である。 本実施形態に係る認証鍵共有システムが実行する、鍵の再生成処理を示すシーケンス図である。 ＦＩＤＯ対応の複数端末を利用するときに生じる問題を説明する図である。 所有者証明書（非特許文献１記載のユーザ証明書）を用いたセキュア領域間の秘密鍵コピーを説明する図である。 標準技術（ＦＩＤＯ）において端末に求められる機能を説明する図である。 従来の認証鍵の共有手法（鍵コピー）において端末に求められる機能を説明する図である。

以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）における認証鍵共有システム等について説明する。
（実施形態）
図１は、本発明の実施形態に係る認証鍵共有システムを示す構成図である。
［認証鍵共有システムの全体構成］
図１に示すように、本実施形態に係る認証鍵共有システム１は、端末１０（１０Ａ：鍵を生成・登録・利用する端末）、端末１０（１０Ｂ：鍵を再生成・利用する端末）に加え、ネットワーク上に、第三者サーバ２０と、端末１０が利用する１つ以上のＷｅｂサービス（装置）３０と、を含んで構成される。端末１０Ａと端末１０Ｂとを特に区別する必要がない場合には、端末１０と記す。
なお、端末１０と、第三者サーバ２０と、Ｗｅｂサービス３０のＷｅｂサーバ３１１（後記）およびＦＩＤＯサーバ３１２（後記）とは、通信ネットワーク（図示省略）で接続されており、相互に通信可能である。
認証鍵共有システム１は、秘密鍵を用いて認証する複数の端末１０と、端末１０の所有者の本人確認を行う第三者サーバ２０とが、通信ネットワークを介して接続され、複数端末１０間で認証用秘密鍵を共有する。
認証鍵共有システム１は、端末１０間で秘密鍵のコピーを行うのではなく、同一所有者の端末１０上では同じ秘密鍵を生成可能とすることにより、複数の端末１０間での認証用秘密鍵の共有を実現する。

<端末の構成>
端末１０は、通常のアプリケーション等が動作する領域である通常領域１１と、マルウェア等が混入しないように管理された領域（外部から不正に侵入できないように管理された領域）であるセキュア領域１２とを論理的に備える。
通常領域１１は、一般のアプリケーションプログラムが実行される環境である。通常領域１１は、Ｗｅｂクライアント１１１と、ＦＩＤＯクライアント１１２とが備わる。

Ｗｅｂクライアント１１１は、Ｗｅｂサービス３０のＷｅｂサーバ３１１にＷｅｂサービスを利用して鍵登録要求および認証要求を発行する。
ＦＩＤＯクライアント１１２は、Ｗｅｂサービス３０のＦＩＤＯサーバ３１２から鍵要求を受付け、秘密鍵生成機能部１２２（後記）に鍵生成要求を発行する。また、ＦＩＤＯクライアント１１２は、Ｗｅｂサービス３０のＦＩＤＯサーバ３１２から認証要求を受付け、秘密鍵利用部１２１（後記）に認証要求を発行する。

セキュア領域１２は、外部から不正に侵入できないように管理された領域である。セキュア領域１２は、一般のアプリケーションプログラムから隔離された実行環境であり、データや計算処理が保護される。ＣＰＵ（Central Processing Unit）やＯＳ（Operating System）の特権モードで実行され、特定のプログラムや特定の手順によってのみ、セキュア領域１２のプログラムの呼び出しやデータへのアクセスが可能となる。

セキュア領域１２は、秘密鍵利用部１２１と、秘密鍵生成機能部１２２と、秘密鍵保管部１２６と、生体認証部１２７と、が備わる。秘密鍵生成機能部１２２は、秘密鍵生成ロジック１２３（秘密鍵生成部）と、マスタコード管理部１２４と、サブコード管理部１２５と、を有する。

秘密鍵利用部１２１は、通常領域１１のＦＩＤＯクライアント１１２からの指示を受け、秘密鍵の利用（署名、暗号化、復号化等）を行う。

秘密鍵生成機能部１２２は、通常領域１１のＦＩＤＯクライアント１１２からの指示を受け、特定の入力文字列もとに秘密鍵を生成する。すなわち、秘密鍵生成機能部１２２は、従来、ランダム生成していた秘密鍵を、特定の入力文字列から派生させて秘密鍵を生成する。同じ入力文字列からは、同じ秘密鍵が生成できるようにすることで、入力文字列を共有している端末１０は、同じ秘密鍵が生成可能である。

入力文字列は、ユーザ（所有者）が記憶する「マスタコード」と、第三者サーバ２０が生成・保管する「サブコード」の組み合わせを用いる。サブコードは、ランダム文字列であり、入力文字列のエントロピーを高めることでブルートフォース攻撃や辞書攻撃等のクラッキング攻撃への耐性を持たせる。サブコードの取得には、第三者サーバ２０による端末所有者の本人確認が必要であり、同一人物が保有する端末上にしか払い出されないことを担保する。
なお、上記秘密鍵生成機能部１２２は、ＦＩＤＯを含む標準技術に求められる鍵生成部の拡張機能として実装される。

秘密鍵生成ロジック１２３は、マスタコードとサブコードとの組み合わせを用いて、同一所有者の端末１０上では同じとなる入力文字列を生成し、当該入力文字列から派生させて秘密鍵を生成する。
秘密鍵生成ロジック１２３は、入力文字列から非対称鍵を生成する（後記図６参照）。具体的には、秘密鍵生成ロジック１２３は、非対称鍵暗号に基づいたＦＩＤＯを含む標準技術において、マスタコード、サブコード、AppID（サイトＩＤ）、UserID，（ユーザＩＤ）を入力として用い、サイトおよびユーザごとに固有な秘密鍵を派生生成させる。

マスタコード管理部１２４は、ユーザ（所有者）が記憶するマスタコードを取得する。マスタコード管理部１２４は、ユーザからのマスタコード（例えば、文字列）の入力を受付ける。このマスタコードは、ユーザ自身が記憶しているものであるが、ユーザしか参照できない状態であれば、記憶以外の方法で管理することに特に制限はない。例えば、これまでのパスワード管理と同じように、管理ツールを使う、印刷して施錠・保管する等である。

サブコード管理部１２５は、第三者サーバ２０が生成・保管するランダム文字列からなるサブコードを、第三者サーバ２０から払出しさせて取得する。サブコード管理部１２５は、第三者サーバ２０のサブコード管理機能部２１２（後記）から払出したサブコード（ランダム文字列）（後記図２参照）を管理する。

秘密鍵保管部１２６は、公開鍵Ａとペアになる秘密鍵Ａと、公開鍵Ｂとペアになる秘密鍵Ｂとを保管する。秘密鍵保管部１２６は、セキュア領域１２内のみからアクセス可能なストレージ（記憶手段）である。

生体認証部１２７は、通常領域１１のＦＩＤＯクライアント１１２からの指示を受け、生体情報（指紋、虹彩）やＰＩＮ（Personal Identification Number）を用いた情報等のユーザ認証を実行する。生体認証部１２７は、例えばスキャナ（図示省略）により読み取られた生体情報の生体認証を行う。

<第三者サーバ>
第三者サーバ２０は、端末１０側で上記入力文字列を生成するためのサブコードを、端末１０または所有者からは分散して保管する。第三者サーバ２０は、他の端末１０のサブコード管理部１２５からのサブコードの発行要求に応答して、サブコードを払出しする。
第三者サーバ２０は、本人確認部２１１と、サブコード管理機能部２１２と、を備える。
本人確認部２１１は、公的ＩＤ（免許証等）の対面提示や、既発行の電子証明書の提示等により本人確認情報の正当性を確認する。
サブコード管理機能部２１２は、一台目の端末１０Ａの場合、サブコードとしてランダム文字列を生成し、生成したサブコードをユーザ名と紐づけてサブコード管理テーブル２２０（図２参照）に保管する。サブコード管理機能部２１２は、二台目の端末１０Ｂの場合、サブコード管理テーブル２２０を参照し、ユーザ名と紐づけられたサブコードを取得する。

図２は、第三者サーバ２０のサブコード管理機能部２１２が備える、サブコード管理テーブル２２０の一例を示す図である。
図２に示すようには、サブコード管理テーブル２２０は、ユーザ名（user_x，User_y，…）と、このユーザ名と紐づけたサブコード（9d3ed234ssg，9filsk03os80，…）の列からなる。ユーザ名は、端末１０において登録・認証を行うユーザの名称であり、ユーザは一般的には端末所有者本人である。
サブコードは、このユーザ名と紐づけたランダム文字列（9d3ed234ssg，9filsk03os80，…）であり、第三者サーバ２０が生成・保管する。サブコードは、ランダム生成として入力文字列を推測困難にする。入力文字列のエントロピーを高めることでブルートフォース攻撃や辞書攻撃等のクラッキング攻撃への耐性を持たせる。サブコードの取得には、第三者サーバ２０による端末所有者の本人確認が必要であり、同一人物が保有する端末上にしか払い出されないことを担保する。
ここで、入力文字列は、マスタコードとサブコードとに分割して分散保管（マスタコードは、ユーザの記憶、サブコードは第三者サーバ２０に保管）される。入力文字列をマスタコードとサブコードとに分散保管することで、単一の攻撃により、入力文字列全体が盗難されることを困難にすることができ、攻撃への耐性を高めることができる。

<Ｗｅｂサービス>
Ｗｅｂサービス（装置）３０は、図１に示すように、Ｗｅｂサーバ３１１と、ＦＩＤＯサーバ３１２と、を備える。
Ｗｅｂサービス（装置）３０は、認証ポリシ（図示省略）を備える。この認証ポリシには、認証用秘密鍵の共有の可否、認証方式や認証精度、秘密鍵の保管場所等のＷｅｂサービスにアクセスする端末に求められる情報が含まれる。

Ｗｅｂサーバ３１１は、端末１０間で秘密鍵を共有する際に、端末１０のＷｅｂクライアント１１１からＷｅｂサービス利用のための鍵の登録要求または認証要求を受け付ける。例えば、鍵を生成・登録・利用する端末１０Ａが、Ｗｅｂサーバ３１１に鍵の登録要求を発行する場合、Ｗｅｂサーバ３１１は、認証ポリシを参照し、Ｗｅｂサービス利用可であるならば、ＦＩＤＯサーバ３１２に認証要求を出力する。ＦＩＤＯサーバ３１２は、端末１０ＡのＦＩＤＯクライアント１１２にＷｅｂサービス固有のＩＤ（AppID）および、登録中のユーザを一意に識別するＩＤ（UserID）と、ランダムなチャレンジ文字列を送信する。
また、鍵を再生成・利用する端末１０Ｂが、Ｗｅｂサーバ３１１に鍵の再生処理要求を発行する場合、Ｗｅｂサーバ３１１は、認証ポリシを参照し、Ｗｅｂサービス利用可であるならば、ＦＩＤＯサーバ３１２に認証要求を出力する。ＦＩＤＯサーバ３１２は、端末１０ＢのＦＩＤＯクライアント１１２にAppID、UserIDと、ランダムなチャレンジ文字列を送信する。

以下、上述のように構成された認証鍵共有システムの認証鍵共有方法について説明する。
［原理説明］
まず、本発明の基本的な考え方について述べる。
認証鍵共有システム１は、端末１０間で秘密鍵のコピーを行うのではなく、同一所有者の端末１０上では同じ秘密鍵を生成可能とすることにより、複数の端末１０間での認証鍵の共有を実現する。

図３は、認証鍵共有システム１の認証鍵共有方法の動作概要を示す図である。図３は、本実施形態に係る認証鍵共有システム１を構成する各装置のうち、端末１０（１０Ａ：鍵を生成・登録・利用する端末；一台目の端末）と端末１０（１０Ｂ：鍵を再生成・利用する端末；二台目の端末）と第三者サーバ２０とを抽出して示した図である。
図３の符号ａに示すように、秘密鍵生成機能部１２２は、通常領域１１のＦＩＤＯクライアント１１２から鍵生成要求（登録時）を受け付ける。秘密鍵生成機能部１２２は、秘密鍵の生成機能が一部拡張されており、従来、ランダム生成していた秘密鍵の生成に代えて、特定の入力文字列をもとに秘密鍵を生成する。すなわち、上記機能追加は、秘密鍵の生成機能の一部のみという特徴（ポイント１）を有する。また、端末間の直接のやり取りがなく秘密鍵の共有が可能であるという特徴（ポイント２）を有する。同じ秘密鍵が生成できるようにすることで、入力文字列を共有している端末１０は、同じ秘密鍵を生成可能である。

入力文字列は、ユーザが記憶する「マスタコード」と、第三者サーバ２０が生成・保管する「サブコード」の組み合わせを用いる。すなわち、入力文字列をマスタコード・サブコードに分割して分散保管することで、攻撃への耐性が高いという特徴（ポイント３）を有する。
マスタコードとサブコードは、事前処理により設定される（後記図４参照）。すなわち、図３の符号ｂに示すように、マスタコード（入力文字列）は、ユーザＸ自身が記憶しているものである。ユーザＸは、端末１０にこのマスタコードを入力・設定する（図３の符号ｃ参照）。

一方、図３の符号ｄ示すように、第三者サーバ２０は、サブコードを事前に生成・保管している。サブコードは、ランダム文字列であり、入力文字列のエントロピーを高めることでブルートフォース攻撃や辞書攻撃等のクラッキング攻撃への耐性を持たせる。サブコードの取得には、第三者サーバ２０による端末所有者の本人確認が必要であり、同一人物が保有する端末上にしか払い出されないことを担保する。仮に第三者サーバ２０が攻撃を受け、サブコードが流出したとしても、マスタコードと両方が揃わないと鍵を生成できない。また、サブコードは、ランダム生成として入力文字列を推測困難にして耐性を高めるという特徴（ポイント４）を有する。

第三者サーバ２０は、ユーザＸからサブコードの発行要求があった場合、図３の符号ｅに示すように、所有者の本人確認後、秘密鍵生成機能部１２２に対して払い出しを行う（後記図４参照）。すなわち、サブコードの払い出しに第三者サーバ２０の本人確認を必須とし、意図しない不正な秘密鍵の共有を防止するという特徴（ポイント５）を有する。
図３の符号ｆに示すように、秘密鍵生成機能部１２２は、特定の入力文字列（マスタコードとサブコードとを組み合わせた入力文字列）をもとに生成する（後記図５および図６参照）。生成した秘密鍵は秘密鍵保管部１２６に保管する。

［認証鍵共有システムの処理の流れ］
次に、本実施形態に係る認証鍵共有システム１の、（１）事前処理（マスタおよびサブコード設定）、（２）鍵の登録処理（端末１０Ａ）、（３）入力文字列からの非対称鍵生成プロセス、（４）鍵の再生成処理（端末１０Ｂ）、について説明する。

<事前処理（マスタおよびサブコード設定）>
本実施形態に係る認証鍵共有システム１では、認証に関わる鍵生成・登録・利用の前段として、端末１０にマスタコードおよびサブコードを設定する必要がある。その事前処理を以下に示す。

図４は、本実施形態に係る認証鍵共有システム１が実行する、事前処理（マスタ／サブコード設定）の流れを示すシーケンス図である。
ユーザは、端末１０の秘密鍵生成機能部１２２のマスタコード管理部１２４に対し、マスタコードを入力する（ステップＳ１）。一台目の端末１０Ａでは任意の文字列を設定し、二台目以降は一台目と同じ文字列を設定する。マスタコード管理部１２４は、ユーザ入力されたマスタコードを保管する（ステップＳ２）。

ユーザは、端末１０の秘密鍵生成機能部１２２のサブコード管理部１２５に対し、サブコードの発行操作を行う（ステップＳ３）。サブコード管理部１２５は、第三者サーバ２０のサブコード管理機能部２１２に対し、サブコードの発行要求を行う（ステップＳ４）。サブコード管理機能部２１２は、本人確認部２１１にこのサブコードの発行要求の適否を確認するための確認要求を出力する（ステップＳ５）。本人確認部２１１は、この確認要求を受けてユーザに対して本人確認情報の要求を送信する（ステップＳ６）。

ユーザは、第三者サーバ２０からの本人確認情報の要求を受けて、第三者サーバ２０に対し、本人確認情報の提示を行う（ステップＳ７）。本人確認情報の提示は、公的ＩＤ（免許証等）の対面提示や、既発行の電子証明書の提示等である。
第三者サーバ２０の本人確認部２１１は、ユーザからの本人確認情報の提示を受けて、本人確認情報の正当性を確認する（ステップＳ８）。本人確認部２１１は、本人確認情報の正当性を確認した場合、サブコード管理機能部２１２に確認ＯＫを出力する（ステップＳ９）。

サブコード管理機能部２１２は、端末１０（１０Ａ：鍵を生成・登録・利用する端末；一台目の端末）の場合、サブコードとしてランダム文字列を生成する（ステップＳ１０）。そして、サブコード管理機能部２１２は、生成したサブコードをユーザ名と紐づけてサブコード管理テーブル２２０（図２参照）に保管する（ステップＳ１１）。

一方、サブコード管理機能部２１２は、端末１０（１０Ｂ：鍵を再生成・利用する端末；二台目の端末）の場合、サブコード管理テーブル２２０（図２参照）を参照し、ユーザ名と紐づけられたサブコードを取得する（ステップＳ１２）。
サブコード管理機能部２１２は、端末１０の秘密鍵生成機能部１２２のサブコード管理部１２５にサブコードの払出しを行う（ステップＳ１３）。サブコード管理部１２５は、このサブコードを保管する（ステップＳ１４）。

<鍵の登録処理（端末１０Ａ）>
ＦＩＤＯでは、Ｗｅｂサービス毎に登録処理（Registration）を行う必要がある。本実施形態における秘密鍵の登録処理を以下に述べる。
なお、本発明では端末台数に依らず、サービス毎に一度だけ本登録処理を実行する必要がある。鍵の登録処理を行った端末１０を、端末１０Ａとしてその動作を示す。

図５は、本実施形態に係る認証鍵共有システム１が実行する、鍵の登録処理（端末１０Ａ）を示すシーケンス図である。
端末１０ＡのＷｅｂクライアント１１１は、Ｗｅｂサービス３０のＷｅｂサーバ３１１にログインし、鍵登録要求を送信する（ステップＳ２１）。
Ｗｅｂサーバ３１１は、ＦＩＤＯサーバ３１２に登録要求を出力する（ステップＳ２２）。ＦＩＤＯサーバ３１２は、端末１０のＦＩＤＯクライアント１１２に鍵要求を送信する（ステップＳ２３）。この鍵要求では、Ｗｅｂサービス固有のＩＤ（AppID）および、登録中のユーザを一意に識別するＩＤ（UserID）と、ランダムなチャレンジ文字列を付与する。
なお、図５の破線枠囲みは、ＦＩＤＯ認証の標準動作を示している。

端末１０のＦＩＤＯクライアント１１２は、Ｗｅｂサービス３０のＦＩＤＯサーバ３１２からの鍵要求を受けて、秘密鍵生成機能部１２２の秘密鍵生成ロジック１２３に鍵生成要求を出力する（ステップＳ２４）。
秘密鍵生成機能部１２２の秘密鍵生成ロジック１２３は、端末１０の生体認証部１２７にユーザ認証要求を出力する（ステップＳ２５）。生体認証部１２７は、秘密鍵生成機能部１２２の秘密鍵生成ロジック１２３からのユーザ認証要求を受け、ユーザの生体認証実行する（ステップＳ２６）。ユーザの生体認証は、例えば指紋認証、虹彩認証、ＰＩＮである。生体認証部１２７は、ユーザの生体認証後、この認証結果を秘密鍵生成ロジック１２３に送信する（ステップＳ２７）。

秘密鍵生成機能部１２２のマスタコード管理部１２４は、マスタコードを取得してマスタコードを秘密鍵生成ロジック１２３に出力する（ステップＳ２８）。
秘密鍵生成機能部１２２のサブコード管理部１２５は、サブコードを取得してサブコードを秘密鍵生成ロジック１２３に出力する（ステップＳ２９）。

このように、端末１０ＡのＷｅｂクライアント１１１が、Ｗｅｂサービス３０のＷｅｂサーバ３１１に鍵登録要求を送信すると（ステップＳ２１）、Ｗｅｂサービス３０を経由して、生体認証部１２７が、ユーザの生体認証結果を秘密鍵生成ロジック１２３に送信する（ステップＳ２７）。そして、マスタコード管理部１２４は、マスタコードを取得して秘密鍵生成ロジック１２３に出力し（ステップＳ２８）、サブコード管理部１２５は、サブコードを取得して秘密鍵生成ロジック１２３に出力する（ステップＳ２９）。したがって、認証鍵共有システム１は、端末１０ＡのＷｅｂクライアント１１１による、鍵登録要求を契機として、秘密鍵生成ロジック１２３に、ユーザの生体認証結果、マスタコードおよびサブコードが集められる。

秘密鍵生成機能部１２２の秘密鍵生成ロジック１２３は、取得したAppID，UserID，マスタコード，サブコードから非対称鍵ペアを生成する（ステップＳ３０）。非対称鍵ペアの生成については、図６により後記する。
秘密鍵生成ロジック１２３は、秘密鍵保管部１２６に生成した秘密鍵を保管する（ステップＳ３１）。
秘密鍵生成ロジック１２３は、ＦＩＤＯクライアント１１２に鍵生成応答を送信する（ステップＳ３２）。具体的には、秘密鍵生成ロジック１２３は、ＦＩＤＯクライアント１１２に、生成した公開鍵および、チャレンジ文字列に秘密鍵で署名したもの（レスポンス）を送付する。以下、ＦＩＤＯクライアント１１２、Ｗｅｂクライアント１１１、Ｗｅｂサービス３０のＷｅｂサーバ３１１およびＦＩＤＯサーバ３１２は、標準動作により鍵の登録を完了する。

すなわち、ＦＩＤＯクライアント１１２は、Ｗｅｂサービス３０のＦＩＤＯサーバ３１２に鍵応答を送信する（ステップＳ３３）。
ＦＩＤＯサーバ３１２は、受信した鍵のレスポンスの検証を行う（ステップＳ３４）。そして、ＦＩＤＯサーバ３１２は、UserIDに紐付けて公開鍵を保管する（ステップＳ３５）。その後、ＦＩＤＯサーバ３１２は、Ｗｅｂサーバ３１１に登録応答を出力する（ステップＳ３６）。Ｗｅｂサーバ３１１は、端末１０ＡのＷｅｂクライアント１１１に登録完了を通知する（ステップＳ３７）。

<入力文字列からの非対称鍵生成プロセス>
図６は、端末１０の秘密鍵生成機能部１２２により実行される、入力文字列からの非対称鍵生成プロセスを説明する図である。

（入力プロセス）
端末１０のマスタコード管理部１２４は、ユーザからのマスタコードの入力を受付け、取得したマスタコードを秘密鍵生成ロジック１２３に入力する。
端末１０のサブコード管理部１２５は、取得したサブコードを秘密鍵生成ロジック１２３に入力する。サブコードは、第三者サーバ２０が生成・保管している。
Ｗｅｂサービス３０のＦＩＤＯサーバ３１２は、Ｗｅｂサービス３０固有のＩＤ（AppID）および、登録中のユーザを一意に識別するＩＤ（UserID）を秘密鍵生成ロジック１２３に入力する。上述したように、このAppIDおよびUserIDは、サービスおよびユーザに固有の秘密鍵を生成するために、秘密鍵生成の入力文字列として付加する。

（処理プロセス）
秘密鍵生成ロジック１２３には、1.マスタコード、2.サブコード、3.AppID、4.UserIDが入力される。
秘密鍵生成ロジック１２３は、入力文字列（1.マスタコード、2.サブコード、3.AppID、4.UserID）を入力として、一意に定まる非対称鍵ペアを出力する。例えば、以下の処理プロセスを実行することにより、入力が同じであれば、同じ非対称鍵ペアを生成することが可能となる。

ステップＳ１０１において、全ての入力文字列（1.マスタコード、2.サブコード、3.AppID、4.UserID）を文字列結合し、一つの文字列とする（「文字列結合」）。結合順は任意であるが、常に（1.マスタコード、2.サブコード、3.AppID、4.UserID）を同じ順序で結合するようにする。

ステップＳ１０２において、鍵を生成する（「Key Derivation」）。この入力文字列から、十分に長い特定長（例えば、128bit）の鍵を生成する。鍵生成には、PBKDF2（RFC2898）等の技術を用いる。

ステップＳ１０３において、生成した鍵をSeedとして疑似乱数生成器（図示省略）に入力し、ランダム数列を生成する（「疑似乱数生成」）。

ステップＳ１０４において、生成した数列を非対称鍵の生成アルゴリズム（例えば、ＤＳＡ、ＲＳＡ等）に与え、非対称鍵を生成する（「非対称鍵の生成」）。
本処理プロセスにより生成した非対称鍵は、従来例のようなランダム生成していた秘密鍵ではなく、特定の入力文字列もとに生成した秘密鍵とそのペアとなる公開鍵である。同じ入力文字列からは、同じ秘密鍵が生成できるようにすることで、入力文字列を共有している端末は、同じ秘密鍵を生成可能である。

（出力プロセス）
秘密鍵生成ロジック１２３は、生成した秘密鍵と公開鍵を出力する。端末１０の秘密鍵保管部１２６は、レスポンスの検証をした後に、生成された秘密鍵を保管する。また、この秘密鍵ペアとなる公開鍵は、UserIDに紐付けてＷｅｂサービス３０のＦＩＤＯサーバ３１２に保管される。

<鍵の再生成処理（端末１０Ｂ）>
本実施形態では、同じマスタコード・サブコードを事前に設定しておくことで、鍵を生成・登録した端末１０Ａ以外の端末１０Ｂであっても、同じ秘密鍵を再生成することができる。同じ秘密鍵を再生成することにより、再登録なしでＦＩＤＯ認証を利用することができる。
端末１０Ａで鍵の生成・登録を行った場合を想定し、同じマスタコード・サブコードを設定した端末１０Ｂで、認証を実行する際の処理手順を示す。

図７は、本実施形態に係る認証鍵共有システム１が実行する、鍵の再生成処理（端末１０Ｂ）を示すシーケンス図である。
端末１０ＢのＷｅｂクライアント１１１は、Ｗｅｂサービス３０のＷｅｂサーバ３１１に認証要求を送信する（ステップＳ４１）。
Ｗｅｂサーバ３１１は、ＦＩＤＯサーバ３１２に認証要求を出力する（ステップＳ４２）。ＦＩＤＯサーバ３１２は、端末１０のＦＩＤＯクライアント１１２に認証要求を送信する（ステップＳ４３）。この認証要求では、Ｗｅｂサービス固有のＩＤ（AppID）および、登録済のユーザを一意に識別するＩＤ（UserID）と、ランダムなチャレンジ文字列を付与する。
なお、図７の破線枠囲みは、ＦＩＤＯ認証の標準動作を示している。

端末１０ＢのＦＩＤＯクライアント１１２は、Ｗｅｂサービス３０のＦＩＤＯサーバ３１２からの認証要求を受けて、端末１０Ｂの秘密鍵利用部１２１に認証要求を出力する（ステップＳ４４）。
秘密鍵利用部１２１は、AppIDに紐付いた鍵の有無を確認する（ステップＳ４５）。秘密鍵利用部１２１は、秘密鍵生成機能部１２２の秘密鍵生成ロジック１２３に鍵生成要求を出力する（ステップＳ４６）。

秘密鍵生成ロジック１２３は、端末１０Ｂの生体認証部１２７にユーザ認証要求を出力する（ステップＳ４７）。生体認証部１２７は、秘密鍵生成機能部１２２の秘密鍵生成ロジック１２３からのユーザ認証要求を受け、ユーザの生体認証実行する（ステップＳ４８）。ユーザの生体認証は、例えば指紋認証、虹彩認証、ＰＩＮである。生体認証部１２７は、ユーザの生体認証後、この認証結果を秘密鍵生成ロジック１２３に送信する（ステップＳ４９）。

秘密鍵生成機能部１２２のマスタコード管理部１２４は、マスタコードを取得して、そのマスタコードを秘密鍵生成ロジック１２３に出力する（ステップＳ５０）。
秘密鍵生成機能部１２２のサブコード管理部１２５は、サブコードを取得してサブコードを秘密鍵生成ロジック１２３に出力する（ステップＳ５１）。

秘密鍵生成機能部１２２の秘密鍵生成ロジック１２３は、取得したAppID，UserID，マスタコード，サブコードから非対称鍵ペアを生成する（ステップＳ５２）。非対称鍵ペアの生成については、前記図６により説明した。
秘密鍵生成ロジック１２３は、秘密鍵保管部１２６に生成した秘密鍵を保管する（ステップＳ５３）。
秘密鍵生成ロジック１２３は、端末１０Ｂの秘密鍵利用部１２１に秘密鍵を取得する（ステップＳ５４）。

秘密鍵利用部１２１は、秘密鍵でチャレンジ文字列に署名する（ステップＳ５５）。そして、秘密鍵利用部１２１は、ＦＩＤＯクライアント１１２に認証応答を出力する（ステップＳ５６）。
ＦＩＤＯクライアント１１２は、Ｗｅｂサービス３０のＦＩＤＯサーバ３１２に認証応答（レスポンス）を送信する（ステップＳ５７）。
ＦＩＤＯサーバ３１２は、受信した公開鍵のレスポンスの検証を行う（ステップＳ５８）。具体的には、ＦＩＤＯサーバ３１２は、登録時に送付され、登録済の公開鍵で検証する。そして、ＦＩＤＯサーバ３１２は、UserIDに紐付けて公開鍵を保管する。その後、ＦＩＤＯサーバ３１２は、Ｗｅｂサーバ３１１に認証応答を出力する（ステップＳ５９）。Ｗｅｂサーバ３１１は、端末１０ＢのＷｅｂクライアント１１１に登録完了を通知する（ステップＳ６０）。

以上説明したように、本実施形態に係る認証鍵共有システム１は、端末１０が、外部から不正に侵入できないように管理された領域であるセキュア領域１２と、セキュア領域１２以外の領域である通常領域１１とを有し、セキュア領域１２内において、所有者からのマスタコードの入力を受付けるマスタコード管理部１２４と、第三者サーバ２０が生成・保管するランダム文字列からなるサブコードを、第三者サーバ２０から払出しさせて取得するサブコード管理部１２５と、マスタコードとサブコードとの組み合わせを用いて、同一所有者の端末１０上では同じとなる入力文字列を生成し、当該入力文字列をもとに秘密鍵を生成する秘密鍵生成ロジック１２３と、を備える。

そして、認証鍵共有システム１の認証鍵共有方法では、端末１０は、セキュア領域１２内において、所有者が記憶するマスタコードを取得するステップと、第三者サーバ２０が生成・保管するランダム文字列からなるサブコードを、第三者サーバ２０から払出させて取得するステップと、マスタコードとサブコードとの組み合わせを用いて、同一所有者の端末１０上では同じとなる入力文字列を生成し、当該入力文字列をもとに秘密鍵を生成するステップと、を実行する。

従来技術では、下記のデメリットがある。
ＦＩＤＯ標準実装は、秘密鍵の端末外への取り出しを想定していない。このため、セキュア領域内のアプリケーションとして開発する場合、開発環境が限られているためコストが高くなる。また、秘密鍵を外部に送信するインタフェースを持つことから、セキュリティを十分に考慮した設計が必要となる。また、悪用されないよう、堅牢かつ高いソフトウェア品質が必要である。
これに対して、本実施形態では、端末間で秘密鍵のコピーを行うのではなく、同一所有者の端末上では同じ秘密鍵を生成可能とする。これにより、端末間の直接のやり取りがなく鍵の共有が可能となり、複数端末間での認証鍵の共有を実現することができる。また、鍵の生成機能の一部拡張のみで認証鍵の共有が実現可能になる。

以下、本実施形態の具体的効果について述べる。
本実施形態では、同一所有者の端末間で同一の認証用秘密鍵を生成することが可能となる。このため、サービス毎の鍵の登録作業は端末数に依らず一度だけ行えばよくなる。そのための機能は、標準技術（ＦＩＤＯ）に求められる鍵生成機能の一部への機能追加であるため、新規にコピー機能を実装する必要がある従来技術（鍵コピー）より普及性の面で優れる。

従来技術（鍵のコピー）では、各サービスについて、どの端末で鍵の生成・登録を行ったか（すなわちどの端末に秘密鍵が存在するか）をユーザが把握し、他の端末で同サービスを利用する場合、鍵を生成した端末から、新端末に明示的に鍵をコピーする必要があった。

本実施形態では、同じマスタコード・サブコードを事前に設定しておくことで、鍵を生成・登録した端末以外でも、同じ秘密鍵を再生成することにより、再登録なしでＦＩＤＯ認証を利用することができる。すなわち、同じマスタコードとサブコードが設定されていればどの端末でもサービス毎に同じ秘密鍵が自動生成されることになる。このため、サービス毎にどの端末で鍵の登録を行ったかを意識する必要がなく、ユーザ負担が小さい。

本実施形態では、サブコードはランダム文字列である。サブコードはランダム生成としているので、入力文字列を推測困難にすることができ、入力文字列のエントロピーを高めることができる。ブルートフォース攻撃や辞書攻撃等のクラッキング攻撃への耐性を持たせることができる。

本実施形態では、秘密鍵生成ロジック１２３は、ＦＩＤＯを含む標準技術に求められる鍵生成部の拡張機能として実装されるので、標準技術（ＦＩＤＯ）に求められる鍵生成機能の一部への機能追加であるため、新規にコピー機能を実装する必要がある従来技術（鍵コピー）より普及性の面で優れる。

本実施形態では、複数端末１０間で秘密鍵を共有する場合、秘密鍵をやり取りすることなく、各端末１０の秘密鍵生成ロジック１２３が、入力文字列から派生させて秘密鍵を生成するので、端末間で秘密鍵のコピーを行うことなく、複数端末間での認証鍵の共有を実現することができる。

本実施形態では、端末１０は、生成した入力文字列をマスタコードとサブコードとに分割し、当該サブコードを第三者サーバ２０に保管させるので、分散保管することで、単一の攻撃により、入力文字列全体が盗難されることを困難にすることができ、攻撃への耐性を高めることができる。

本実施形態では、第三者サーバ２０は、所有者の本人確認後、サブコードを払出しする。第三者サーバは、他の端末１０のサブコード管理部１２５からのサブコードの発行要求に応答して、サブコードを払出しする。サブコードの払出しには、第三者サーバ２０の本人確認を必須となるので、意図しない不正な鍵の共有を防止することができる。仮に第三者サーバ２０が攻撃を受け、サブコードが流出したとしても、マスタコードと両方が揃わないと鍵を生成できない。

本実施形態では、秘密鍵生成ロジック１２３は、非対称鍵暗号に基づいたＦＩＤＯを含む標準技術において、入力文字列（マスタコード、サブコード、AppID、UserID）を入力として、サイトおよびユーザごとに固有な認証鍵を派生生成させる。
これにより、入力が同じであれば、同じ非対称鍵ペアを生成することが可能となる。

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

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

１ 認証鍵共有システム
１０ 端末
１０Ａ 端末（鍵を生成・登録・利用する端末；一台目の端末）
１０Ｂ 端末（鍵を再生成・利用する端末；二台目の端末）
１１ 通常領域
１２ セキュア領域
２０ 第三者サーバ
３０ Ｗｅｂサービス
１１１ Ｗｅｂクライアント
１１２ ＦＩＤＯクライアント
１２１ 秘密鍵利用部
１２２ 秘密鍵生成機能部
１２３ 秘密鍵生成ロジック（秘密鍵生成部）
１２４ マスタコード管理部
１２５ サブコード管理部
１２６ 秘密鍵保管部
１２７ 生体認証部
２２０ サブコード管理テーブル
２１１ 本人確認部
２１２ サブコード管理機能部
３１１ Ｗｅｂサービスサーバ
３１２ ＦＩＤＯサーバ

Claims (4)

1. 秘密鍵を用いて認証する複数の端末と、前記端末の所有者の本人確認を行う第三者サーバとが、通信ネットワークを介して接続され、複数端末間で認証用秘密鍵を共有する認証鍵共有システムであって、
   前記端末は、
   外部から不正に侵入できないように管理された領域であるセキュア領域を有し、
   前記セキュア領域内において、
   前記所有者からのマスタコードの入力を受付けるマスタコード管理部と、
   前記第三者サーバが生成・保管するランダム文字列からなるサブコードを、前記第三者サーバから払出しさせて取得するサブコード管理部と、
   前記マスタコードと前記サブコードとの組み合わせを用いて、同一所有者の端末上では同じとなる入力文字列を生成し、当該入力文字列をもとに秘密鍵を生成する秘密鍵生成部と、
   を備えることを特徴とする認証鍵共有システム。
2. 前記端末は、
   前記入力文字列を生成するための前記サブコードを前記第三者サーバに保管させる
   ことを特徴とする請求項１に記載の認証鍵共有システム。
3. 前記第三者サーバは、
   他の前記端末の前記サブコード管理部からの前記サブコードの発行要求に応答して、保管した前記サブコードを払出しする
   ことを特徴とする請求項２に記載の認証鍵共有システム。
4. 秘密鍵を用いて認証する複数の端末と、前記端末の所有者の本人確認を行う第三者サーバとが、通信ネットワークを介して接続され、複数端末間で認証用秘密鍵を共有する認証鍵共有システムの認証鍵共有方法であって、
   前記端末は、
   外部から不正に侵入できないように管理された領域であるセキュア領域を有し、
   前記セキュア領域内において、
   前記所有者からのマスタコードの入力を受付けるステップと、
   前記第三者サーバが生成・保管するランダム文字列からなるサブコードを、前記第三者サーバから払出させて取得するステップと、
   前記マスタコードと前記サブコードとの組み合わせを用いて、同一所有者の端末上では同じとなる入力文字列を生成し、当該入力文字列をもとに秘密鍵を生成するステップと、
   を実行する認証鍵共有方法。

Images