(57)【要約】【課題】端末間の通信回数を削減することができる端末登録システムおよび端末登録方法を提供する。【解決手段】端末登録システム１０００は、既存端末Ａ１１０が、ＴＥＥを含むセキュア領域に、端末の所有者を示す所有者証明書を発行する証明書発行部１１７と、同一の所有者証明書を有する端末間で連携をするとともに、暗号鍵を生成する既存端末側連携部１１４と、認証用秘密鍵を管理する認証鍵管理部１１６と、を備え、また、ＲＥＥを含む端末環境に、端末間の通信を行う端末間連携アプリ１１１を備え、新規端末Ｂ１２０は、新規端末Ｂ１２０側の端末間連携アプリ１２１から既存端末Ａ１１０に対して、暗号鍵による暗号化通信の開始要求を行い、既存端末Ａ１１０の既存端末側連携部１１４は、認証用秘密鍵を暗号鍵で暗号化した連携用データを、同一の所有者証明書を有する新規端末Ｂ１２０に送付する。【選択図】図１
2020028036.tif 000002
【特許請求の範囲】
【請求項１】
秘密鍵を用いてＦＩＤＯ（Fast IDentity Online）認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、
登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムであって、
前記端末は、ＴＥＥ（Trusted Execution Environmen）を含むセキュア領域に、端末の所有者を示す所有者証明書を発行する証明書発行部と、同一の所有者証明書を有する端末間で連携をする連携部と、暗号鍵を生成する暗号鍵生成部と、認証用秘密鍵を管理する認証鍵管理部と、を備え、
ＲＥＥ（Rich Execution Environment）を含む端末環境に、端末間の通信を行う通信部を備え、
前記新規端末は、当該新規端末側の前記通信部から前記登録済み端末に対して、暗号鍵による暗号化通信の開始要求を行い、
前記登録済み端末の前記連携部は、前記認証用秘密鍵を前記暗号鍵で暗号化した連携用データを、同一の前記所有者証明書を有する前記新規端末に送付する
ことを特徴とする端末登録システム。
【請求項２】
前記連携部は、所定時間内の通信開始要求回数を判定する閾値を有し、
前記登録済み端末の前記連携部は、前記新規端末からの通信開始要求回数が前記閾値を超えた場合、前記連携用データの送付を行わない
ことを特徴とする請求項１に記載の端末登録システム。
【請求項３】
前記登録済み端末の前記連携部は、前記新規端末側で前記暗号鍵が利用可能になることを確認することなく、前記連携用データの送付を行う
ことを特徴とする請求項１に記載の端末登録システム。
【請求項４】
前記連携部は、前記新規端末からの通信開始要求回数が前記閾値を超えた場合、ユーザに知らせる提示手段と、
ユーザによる可否の判断を受付ける受付手段と、をさらに備える
ことを特徴とする請求項２に記載の端末登録システム。
【請求項５】
前記連携部は、連携処理時に、連携処理中の前記新規端末をユーザに通知する
ことを特徴とする請求項１に記載の端末登録システム。
【請求項６】
前記登録済み端末の前記証明書発行部は、ユーザが命名する前記新規端末の名称を、前記所有者証明書と紐付けて保管する
ことを特徴とする請求項１に記載の端末登録システム。
【請求項７】
秘密鍵を用いてＦＩＤＯ（Fast IDentity Online）認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、
登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムの端末登録方法であって、
前記端末は、ＴＥＥ（Trusted Execution Environmen）を含むセキュア領域に、端末の所有者を示す所有者証明書を発行する証明書発行部と、同一の所有者証明書を有する端末間で連携をする連携部と、暗号鍵を生成する暗号鍵生成部と、認証用秘密鍵を管理する認証鍵管理部と、を有し、
ＲＥＥを含む端末環境に、端末間の通信を行う通信部を有し、
前記新規端末は、当該新規端末側の前記通信部から前記登録済み端末に対して、暗号鍵による暗号化通信の開始要求を行うステップを実行し、
前記登録済み端末の前記連携部は、前記認証用秘密鍵を前記暗号鍵で暗号化した連携用データを、同一の前記所有者証明書を有する前記新規端末に送付するステップを実行する
端末登録方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末登録システムおよび端末登録方法に関する。
【背景技術】
【０００２】
パスワード認証に替わる利用者認証技術として、パスワードレス認証のデファクト標準技術（ＦＩＤＯ：Fast IDentity Online）という、公開鍵暗号を用いたＷｅｂサービスの利用者認証技術がある（非特許文献１参照）。
ＦＩＤＯでは、サービス毎に異なる公開鍵・秘密鍵ペアを生成し、公開鍵をサービスサイト側に配置して、秘密鍵を端末内に閉じ込める。秘密鍵の利用（チャレンジ・レスポンス認証における署名）は端末上で生体認証を行うことが前提となっており、かつ、秘密鍵の利用はAuthenticator内で行われ、端末外に秘密鍵が出ていくことはないことからセキュリティが高い。
ＦＩＤＯ認証を利用するためには、事前にサービスサイトに対して端末のRegistrationを行い、アカウントにその端末の公開鍵を紐付けておく必要がある。標準技術においてRegistrationは、ＦＩＤＯ以外の認証方法でアカウントにログインした上で実行することが想定されている。
【０００３】
図１４は、標準技術（ＦＩＤＯ）の特徴を説明する図であり、図１４（ａ）は端末の認証を示し、図１４（ｂ）は新規端末の登録を示す。
図１４（ａ）に示すように、端末１は、生体認証等でアクセス制御される。端末１と、サービスサイトＡ２１およびサービスサイトＢ２２とは、ＦＩＤＯプロトコルで認証される。利用者は端末１を使ってサービスサイトＡ２１とサービスサイトＢ２２にアクセスしている。
サービスサイトＡ２１およびサービスサイトＢ２２は、端末毎に個別の鍵を登録する。また、端末１は、サイト毎に個別の鍵ペアを生成する。
サービスサイトＡ２１には公開鍵Ａが、サービスサイトＢ２２には公開鍵Ｂが登録済みである。
端末１のセキュア領域（Authenticator）１０には、公開鍵Ａとペアになる秘密鍵Ｂが格納されている。
【０００４】
図１４（ｂ）は、標準技術（ＦＩＤＯ）において、新規端末の登録を説明する図である。図１４（ｂ）における端末２は、端末１とは別に新しく追加される端末（以下、新規端末２という）である。新規端末２は、端末の追加、変更（例えば、スマートフォンとタブレット端末の２台持ち、端末の機種変更）によって生じる。新規端末２でＦＩＤＯ認証を利用するためには、事前に全サービスサイトに対して端末のRegistrationを行い、アカウントにその端末の公開鍵を紐付けておく必要がある。
図１４（ｂ）に示すように、新規端末２を利用する場合、新規端末２のAuthenticator１０内には鍵がないことから、サービス毎に再度鍵ペアの生成・登録を行う必要がある。
【０００５】
標準技術（ＦＩＤＯ）では、認証用の秘密鍵を端末内に閉じ込めてセキュリティを高める。端末を追加・変更する場合、すべてのサービスサイトに対して新規端末の鍵を再登録する必要があるという利便性上の問題がある。
この問題の解決策として、端末間の連携による手法１と手法２とがある。
【０００６】
図１５は、端末間の連携による認証鍵のコピー技術（手法１）を説明する図である。
図１５に示すように、既存端末１と新規端末２間でセキュアな通信路３を確立し、セキュアな通信路３を介して認証鍵を複製する。
両端末の連携（端末間での秘密鍵の複製）によって、複数サイトに対する再登録の利便性を向上させる。
【０００７】
図１６は、電子署名の付与による登録認可技術（手法２）を説明する図である。
図１６に示すように、既存端末１と新規端末２間でセキュアな通信路３を確立し、セキュアな通信路３を介して認可情報を付与（電子署名の付与）する。初回アクセス時にサービスサイト２０に電子署名の付与による登録認可を行う。
両端末の連携（電子署名の付与による登録認可）によって、複数サイトに対する再登録の利便性を向上させる。
【０００８】
上述した、端末間の連携による手法１および手法２においては、攻撃者がアカウントを乗っ取るために、攻撃者自身の端末（新規端末）とユーザの端末（既存端末）を連携させようとする攻撃が行われることが懸念される。
このような攻撃への対策として、端末のセキュア領域（ＴＥＥ：Trusted Execution Environment等）に、端末の所有者を示す電子証明書（所有者証明書）を発行し、同一の所有者証明書を有する端末間でしか連携をしないようにする手法が提案されている。
【０００９】
図１７は、同一の所有者証明書を有する端末間でしか連携をしないようにする手法３を説明する図である。
端末のセキュア領域１０に所有者証明書１１を格納する。所有者証明書１１は、信頼できる第三者が、所有者の本人確認を行った上で発行する電子証明書である。所有者証明書１１は、信頼できる第三者が、対面等の確実性が高い手段でユーザの本人確認を行った上で発行することを想定する。
所有者証明書１１を用いた相互認証により、同一所有者であることが確認できたとき、セキュアな通信路３を確立する。すなわち、両端末の所有者証明書１１を用いた相互認証を行い、所有者の一致が確認できたときのみ、端末間のセキュアな通信路を確立して連携を許容する。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】FIDO Alliance,“SIMPLER, STRONGER AUTHENTICATION”, FIDO is the World’s Largest Ecosystem for Standards-Based, Interoperable Authentication ［online］,［平成３０年８月８日検索］,インターネット  〈 https://fidoalliance.org/〉
【発明の概要】
【発明が解決しようとする課題】
【００１１】
ＦＩＤＯの認証鍵は、マルウェア等が手出しできないＴＥＥ等のセキュア領域内で厳密に管理されることが想定されており、そのセキュリティレベルを保つためには、端末間のセキュアな通信路を確立する機能はＴＥＥ内のセキュアアプリケーションとして実装するのが望ましい。また、電子証明書を用いた相互認証に基づき、セキュアな通信路を確立するための汎用的な標準プロトコルとして、ＴＬＳ（Transport Layer Security）が広く用いられている。
【００１２】
しかし、Android（登録商標）等の通常の端末環境（ＲＥＥ: Rich Execution Environment）と比べて、ＴＥＥには限られた実行環境しか提供されておらず、ＴＬＳプロトコルをフルに実装するセキュアアプリケーションの実装コストは高いことが想定される。特に、汎用的なクライアント・サーバ間の相互認証プロトコルであるＴＬＳをそのまま実装すると、端末間の通信回数が多くなる。通信はＲＥＥで行うことが一般的であり、ＴＥＥとＲＥＥ間のコンテキストスイッチを意識した状態管理が煩雑となることが想定される。なお、ＣＰＵの状態のことをコンテキスト、保存と復帰を行いコンテキストを切り替えることをコンテキストスイッチという。
【００１３】
このような背景を鑑みて本発明がなされたのであり、本発明は、端末間の通信回数を削減することができる端末登録システムおよび端末登録方法を提供することを課題とする。
【課題を解決するための手段】
【００１４】
前記した課題を解決するため、請求項１に記載の発明は、秘密鍵を用いてＦＩＤＯ認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムであって、前記端末は、ＴＥＥを含むセキュア領域に、端末の所有者を示す所有者証明書を発行する証明書発行部と、同一の所有者証明書を有する端末間で連携をする連携部と、暗号鍵を生成する暗号鍵生成部と、認証用秘密鍵を管理する認証鍵管理部と、を備え、ＲＥＥを含む端末環境に、端末間の通信を行う通信部を備え、前記新規端末は、当該新規端末側の前記通信部から前記登録済み端末に対して、暗号鍵による暗号化通信の開始要求を行い、前記登録済み端末の前記連携部は、前記認証用秘密鍵を前記暗号鍵で暗号化した連携用データを、同一の前記所有者証明書を有する前記新規端末に送付することを特徴とする端末登録システムとした。
【００１５】
また、請求項７に記載の発明は、秘密鍵を用いてＦＩＤＯ認証する複数の端末と、前記端末が利用するサービスサイトとが通信可能に接続され、登録済み端末を用いて、複数の前記サービスサイトに対する新規端末を登録する端末登録システムの端末登録方法であって、前記端末は、ＴＥＥ（Trusted Execution Environmen）を含むセキュア領域に、端末の所有者を示す所有者証明書を発行する証明書発行部と、同一の所有者証明書を有する端末間で連携をする連携部と、暗号鍵を生成する暗号鍵生成部と、認証用秘密鍵を管理する認証鍵管理部と、を有し、ＲＥＥを含む端末環境に、端末間の通信を行う通信部を有し、前記新規端末は、当該新規端末側の前記通信部から前記登録済み端末に対して、暗号鍵による暗号化通信の開始要求を行うステップを実行し、前記登録済み端末の前記連携部は、前記認証用秘密鍵を前記暗号鍵で暗号化した連携用データを、同一の前記所有者証明書を有する前記新規端末に送付するステップを実行する端末登録方法とした。
【００１６】
このようにすることで、一つのオペレーション（端末間での証明書の交換処理／端末間の連携処理）において、必須となる通信回数は最大でも端末間で１往復となる。これにより、ＲＥＥへのコンテキストスイッチを意識したＴＥＥ内の状態数が削減される。
【００１７】
請求項２に記載の発明は、前記連携部が、所定時間内の通信開始要求回数を判定する閾値を有し、前記登録済み端末の前記連携部は、前記新規端末からの通信開始要求回数が前記閾値を超えた場合、前記連携用データの送付を行わないことを特徴とする請求項１に記載の端末登録システムとした。
【００１８】
このようにすることで、暗号化データを多数取得することにより暗号鍵の生成方法を推測し、認証鍵を盗難しようとする攻撃を防ぐことができる。
【００１９】
請求項３に記載の発明は、前記登録済み端末の前記連携部は、前記新規端末側で前記暗号鍵が利用可能になることを確認することなく、前記連携用データの送付を行うことを特徴とする請求項１に記載の端末登録システムとした。
【００２０】
このようにすることで、ＴＬＳと比較して端末間の通信回数を削減することができる。
【００２１】
請求項４に記載の発明は、前記連携部は、前記新規端末からの通信開始要求回数が前記閾値を超えた場合、ユーザに知らせる提示手段と、ユーザによる可否の判断を受付ける受付手段と、をさらに備えることを特徴とする請求項２に記載の端末登録システムとした。
【００２２】
このようにすることで、ユーザによる誤操作等の可能性を排除することができる。ＴＥＥの警告画面は、マルウェア等によって改ざんできないため、セキュアにユーザ意志を確認できる。
【００２３】
請求項５に記載の発明は、前記連携部は、連携処理時に、連携処理中の前記新規端末をユーザに通知することを特徴とする請求項１に記載の端末登録システムとした。
【００２４】
このようにすることで、意図しない端末間で連携が行われようとしていることに気づきやすくなる効果がある。
【００２５】
請求項６に記載の発明は、前記登録済み端末の前記証明書発行部は、ユーザが命名する前記新規端末の名称を、前記所有者証明書と紐付けて保管することを特徴とする請求項１に記載の端末登録システムとした。
【００２６】
このようにすることで、他証明書を取得する際に、その端末を識別可能なわかりやすい名称を、ユーザがセキュアに命名できる。
【発明の効果】
【００２７】
本発明によれば、端末間の通信回数を削減することができる端末登録システムおよび端末登録方法を提供することができる。
【図面の簡単な説明】
【００２８】
【図１】本発明の実施形態に係る端末登録システムを示す構成図である。
【図２】本実施形態に係る端末登録システムの端末間の相互認証を実装する場合のシーケンス図である。
【図３】比較例のＴＬＳ標準を実装した場合のＴＥＥの必要状態を示す状態遷移図である。
【図４】本実施形態に係る端末登録システムのＴＥＥの必要状態を示す状態遷移図であり、（ａ）は端末間での証明書の交換処理を示し、（ｂ）は端末間の連携処理を示す。
【図５】本実施形態に係る端末登録システムの所有者証明書の発行シーケンスを示す図である。
【図６】本実施形態に係る端末登録システムのサービスサイトへの鍵登録を示すシーケンス図である。
【図７】本実施形態に係る端末登録システムのサービスサイトへの認証を示すシーケンス図である。
【図８】本実施形態に係る端末登録システムの証明書の交換シーケンスを示す図である。
【図９】本実施形態に係る端末登録システムの端末間の連携のシーケンスを示す図である。
【図１０】図９に続くシーケンス図である。
【図１１】本実施形態に係る端末登録システムの閾値超過時の処理を適用した端末間の連携のシーケンスを示す図である。
【図１２】本実施形態に係る端末登録システムの名称命名機能を適用した証明書の交換のシーケンスを示す図である。
【図１３】本実施形態に係る端末登録システムの意図しない端末の確認処理を適用した端末間の連携のシーケンスを示す図である。
【図１４】標準技術（ＦＩＤＯ）の特徴を説明する図であり、（ａ）は端末の認証を示し、（ｂ）は新規端末の登録を示す。
【図１５】端末間の連携による認証鍵のコピー技術（手法１）を説明する図である。
【図１６】電子署名の付与による登録認可技術（手法２）を説明する図である。
【図１７】同一の所有者証明書を有する端末間でしか連携をしないようにする手法３を説明する図である。
【図１８】標準的なＴＬＳに基づいて端末間の相互認証を実装する場合のシーケンス図である。
【発明を実施するための形態】
【００２９】
以下、図面を参照して本発明を実施するための形態（以下、「本実施形態」という）における端末登録システム等について説明する。
まず、本発明と既存技術との関係性について説明する。
図１８は、標準的なＴＬＳに基づいて端末間の相互認証を実装する場合のシーケンス図である。
図１８おいて、端末１は既存端末Ａ（以下、既存端末Ａ１）であり、端末２は新規端末Ｂ（以下、新規端末Ｂ２）であるとする。
新規端末Ｂ２は、例えば追加や変更（例えば、スマートフォンとタブレット端末の２台持ち、端末の機種変更）である。この場合、ＦＩＤＯ標準では、新規端末Ｂ２で新たに鍵ペアの生成・各Ｗｅｂサービスへの紐づけ（Registration）が必要となる。しかし、煩雑となる。そこで、秘密鍵を既存端末Ａ１から複製してくることにより、新規端末Ｂ２でのRegistration実行を回避する。
【００３０】
シーケンスは、ＴＬＳにおけるクライアントとなった側、ここでは既存端末Ａ１から通信を開始する。既存端末Ａ１は、新規端末Ｂ２に通信開始要求を送信する（ステップＳ１１）。
新規端末Ｂ２は、リプレイ攻撃を防ぐために、乱数を生成して通信要求（乱数Ｂ＋所有者証明書Ｂ）を送付する（ステップＳ１２）。
【００３１】
既存端末Ａ１は、新規端末Ｂ２から送付された証明書を検証・比較する（ステップＳ１３）。証明書の検証がＯＫであれば、新規端末Ｂ２に所有者証明書Ａを送信する（ステップＳ１４）。
新規端末Ｂ２は、既存端末Ａ１から送付された証明書を検証・比較する（ステップＳ１５）。
【００３２】
既存端末Ａ１は、所有者証明書Ａの送信後、連携用データを送付する側である既存端末Ａで暗号鍵Ａを生成する（ステップＳ１６）。
既存端末Ａ１は、受信した所有者証明書Ｂに紐づく公開鍵で暗号鍵Ａ Wrapする（ステップＳ１７）。
新規端末Ｂ２は、所有者証明書Ｂのユーザが通信していることの証明のため、所有者証明書Ｂに紐づく秘密鍵で暗号鍵Ａ Unwrapする（ステップＳ１８）。
【００３３】
既存端末Ａ１は、所有者証明書Ａのユーザが通信していることの証明のため、これまでの通信内容に所有者証明書Ａに紐づく秘密鍵で署名する（ステップＳ１９）。
新規端末Ｂ２は、所有者証明書Ａのユーザが通信相手であることの確認のため、公開鍵Ａで署名検証する（ステップＳ２０）。
【００３４】
既存端末Ａ１は、新規端末Ｂ２に暗号化通信の開始通知を行う（ステップＳ２１）。
新規端末Ｂ２は、既存端末Ａ１からの開始通知を受けて、既存端末Ａ１にUnwrapした暗号鍵Ａを利用して暗号化通信の開始通知を行う（ステップＳ２２）。
既存端末Ａ１は、新規端末Ｂ２からの開始通知により、所有者証明書Ｂのユーザが通信相手であることの確認ができる。
【００３５】
既存端末Ａ１は、実際のデータ通信を開始し、暗号鍵Ａで暗号化して連携用データを送信する（ステップＳ２３）。
以上、標準的なＴＬＳに基づいて端末間の相互認証を実装する場合のシーケンスについて説明した。
【００３６】
標準的なＴＬＳは、汎用的なクライアント・サーバ間の相互認証プロトコルであるＴＬＳをそのまま実装する。図１８に示すように、ＴＬＳをそのまま実装しているので、端末間の通信回数が多くなる。また、通信は、ＲＥＥで行うことが一般的であり、ＴＥＥとＲＥＥ間のコンテキストスイッチを意識した状態管理が煩雑となることが想定される。
ここで、想定するＴＥＥアプリ開発における一般的な制限について述べる。
（１）ＴＥＥアプリ実装時に利用可能な標準ライブラリ群は限定されている。
（２）ＴＥＥアプリはＣ言語による実装が前提である。このため、より生産性の高い先端的な開発言語（Java, Python等）は利用できない。
（３）ＲＥＥアプリとは別の個別の配信サーバを用意することが前提である。このため、ＴＥＥアプリのアップデートは高コストとなる。
【００３７】
（実施形態）
図１は、本発明の実施形態に係る端末登録システムを示す構成図である。
［端末登録システムの全体構成］
図１に示すように、本実施形態に係る端末登録システム１０００は、既存端末Ａ１１０（登録済み端末）、新規端末Ｂ１２０に加え、ネットワーク上に、他の当事者に公開鍵証明書を発行する認証局１３０と、サービスサイト１４０と、を含んで構成される。
端末登録システム１０００は、秘密鍵を用いてＦＩＤＯ認証する複数の端末と、端末が利用するサービスサイト１４０とが通信可能に接続され、既存端末Ａ１１０を用いて、サービスサイト１４０に対する新規端末Ｂ１２０を登録する。
なお、既存端末Ａ１１０と、新規端末Ｂ１２０と、認証局１３０と、サービスサイト１４０とは、通信ネットワーク（図示省略）で接続されており、相互に通信可能である。
【００３８】
<サービスサイト１４０>
サービスサイト１４０は、Ｗｅｂアプリケーションサーバ（Web application server）と、ＦＩＤＯサーバと、を備える。Ｗｅｂアプリケーションサーバは、ソフトウェアの実行環境や連携機能などを持つＷｅｂサーバである。Ｗｅｂアプリケーションサーバは、ＦＩＤＯサーバと接続・連携して複雑な処理を行う機能を持つ。Ｗｅｂアプリケーションサーバは、例えばＥＣ（Electronic Commerce）サイトを運営するサービス事業者が運用するＷｅｂサーバであり、サービスを利用するユーザの登録と認証とを行う。
【００３９】
<既存端末Ａ１１０，新規端末Ｂ１２０の構成>
既存端末Ａ１１０，新規端末Ｂ１２０は、認証用端末であり、例えばスマートフォン，携帯電話，タブレット等の携帯端末、ノート型／デスクトップ型ＰＣ、各種電子機器である。本実施形態では、スマートフォンを例に採る。
既存端末Ａ１１０，新規端末Ｂ１２０は、通常のアプリケーション（以下、アプリという）等が動作する領域である通常の端末環境（ＲＥＥ）と、マルウェア等が混入しないように管理されたセキュア領域（ＴＥＥ）とを論理的に備える。ＲＥＥは、一般のアプリケーションプログラムが実行される環境である。また、ＴＥＥは、セキュア領域であり、生体情報（指紋情報など）が保管される。ＴＥＥは、ＣＰＵ（Central Processing Unit）やＯＳ（Operating System）の特権モードで実行され、特定のプログラムや特定の手順によってのみ、ＴＥＥのプログラムの呼び出しやデータへのアクセスが可能となる。
【００４０】
まず、既存端末Ａ１１０の構成について説明する。
既存端末Ａ１１０のＲＥＥには、端末間連携アプリ１１１（通信部）と、認証アプリ１１２と、証明書発行アプリ１１３とが備わる。
図１の矢印に示すように、既存端末Ａ１１０の端末間連携アプリ１１１は、新規端末Ｂ１２０の端末間連携アプリ１２１との間でＲＥＥによる通信を行う。
【００４１】
既存端末Ａ１１０のＴＥＥには、同一の所有者証明書を有する端末間で連携をする既存端末側連携部１１４と、認証アプリ１１２に接続される認証部１１５と、認証用秘密鍵を管理する認証鍵管理部１１６と、証明書発行アプリ１１３に接続され、端末の所有者を示す所有者証明書を発行する証明書発行部１１７と、証明書管理部１１８とが備わる。
【００４２】
既存端末側連携部１１４は、既存端末側連携機能群として、関数１−１（後記）に従って証明書を受信する証明書受信部１１４ａと、関数２−１（後記）に従って証明書を送信する証明書送信部１１４ｂと、関数３Ａ−１（後記）に従って端末間連携を行う端末間連携部１１４ｃと、を有する。上記関数は、制御シーケンスのなかで、各部が特定の操作または処理を実行する機能を便宜的にいうものである。
また、既存端末側連携部１１４は、暗号鍵を生成する暗号鍵生成部としての機能を有する。
【００４３】
既存端末側連携部１１４は、所定時間内の通信開始要求回数を判定する閾値を有し、
新規端末Ｂ１２０からの通信開始要求回数が閾値を超えた場合、連携用データの送付を行わない。
既存端末側連携部１１４は、新規端末Ｂ１２０側で暗号鍵が利用可能になることを確認することなく、連携用データの送付を行う。
既存端末側連携部１１４は、端末間の所有者証明書の交換、検証および比較を、端末間の連携に先立って行う。
既存端末側連携部１１４は、新規端末Ｂ１２０からの通信開始要求回数が閾値を超えた場合、ユーザに知らせる提示手段と、ユーザによる可否の判断を受付ける受付手段と、をさらに備える。
既存端末側連携部１１４は、連携処理時に、連携処理中の新規端末をユーザに通知する。
【００４４】
認証鍵管理部１１６は、サービスサイト１４０ごとの鍵（例えばＲＳＡ等の非対称鍵）である認証用秘密鍵Ａを有する。
【００４５】
証明書発行部１１７は、端末の所有者を示す所有者証明書を発行する。証明書発行部１１７は、ユーザが命名する新規端末の名称を、所有者証明書と紐付けて保管する。
【００４６】
証明書管理部１１８は、本人証明秘密鍵Ａと、自証明書Ａと、他証明書とを管理する。
上記自証明書Ａは、自端末の公開鍵証明書（例えばX.509形式）であり、また本人証明秘密鍵Ａは、この公開鍵証明書に紐づく秘密鍵である。上記他証明書は、保存した他端末の公開鍵証明書（例えばX.509形式）である。
【００４７】
次に、新規端末Ｂ１２０の構成について説明する。新規端末Ｂ１２０は、既存端末Ａ１１０と同様の構成を採る。
新規端末Ｂ１２０のＲＥＥには、端末間連携アプリ１２１（通信部）と、認証アプリ１２２と、証明書発行アプリ１２３とが備わる。
図１の矢印に示すように、新規端末Ｂ１２０の端末間連携アプリ１２１は、既存端末Ａ１１０の端末間連携アプリ１１１との間でＲＥＥによる通信を行う。
【００４８】
新規端末Ｂ１２０のＴＥＥには、同一の所有者証明書を有する端末間で連携をする新規端末側連携部１２４と、認証アプリ１２２に接続される認証部１２５と、認証用秘密鍵を管理する認証鍵管理部１２６と、証明書発行アプリ１２３に接続され、端末の所有者を示す所有者証明書を発行する証明書発行部１２７と、証明書管理部１２８とが備わる。
【００４９】
新規端末側連携部１２４は、新規端末側連携機能群として、関数１−１（後記）に従って証明書を受信する証明書受信部１２４ａと、関数２−１（後記）に従って証明書を送信する証明書送信部１２４ｂと、関数３Ａ−１（後記）に従って端末間連携を行う端末間連携部１２４ｃと、を有する。
認証鍵管理部１２６は、サービスサイト１４０ごとの鍵（例えばＲＳＡ等の非対称鍵）である認証用秘密鍵Ａを有する。
証明書管理部１２８は、本人証明秘密鍵Ｂと、自証明書Ｂと、他証明書とを管理する。
上記自証明書Ａは、自端末の公開鍵証明書（例えばX.509形式）であり、また本人証明秘密鍵Ｂは、この公開鍵証明書に紐づく秘密鍵である。上記他証明書は、保存した他端末の公開鍵証明書（例えばX.509形式）である。
【００５０】
以下、上述のように構成された端末登録システムの端末登録方法について説明する。
［動作概要］
まず、本実施形態に係る端末登録システムの端末登録方法の動作概要について述べる。
本実施形態に係る端末登録システムは、新規端末をセットアップするための端末間の相互認証というユースケースに絞ることで、ＴＬＳのシーケンス図（図１８参照）と比較して端末間の通信回数を削減することを特徴とする。
【００５１】
想定するユースケースとシンプル化ポイントは、下記の通りである。
（１）端末間の関係性は、同等であるとする。すなわち、どちらの端末がクライアント、サーバというわけではなく、同等である。これにより、クライアントから通信の開始要求を行うプロセスを省略する。
（２）端末間連携の頻度は、それほど多くないものとする。端末間連携の頻度は、新規端末を利用開始する場合、あるいはいずれかの端末で新規サイトの登録を行い、端末間の鍵の同期が必要となった場合に限定する。
（３）一定時間内の通信要求回数に制限をつけた上で、相手側で暗号鍵が利用可能になったかを確認せずに連携用データの送付を行う。
（４）特定の端末間でのみ連携を行う（すなわち、サーバが不特定多数のクライアントから通信を受け付けるモデルではない）。このため、端末間での所有者証明書の交換・検証・比較は、連携時ではなく事前に行っておくことにする。
【００５２】
なお、同一人物が、既存端末Ａと新規端末Ｂとを両方持っており、既存端末Ａから新規端末Ｂに、乗り換えて鍵を登録する場合は問題ない。また、既存端末Ａから通信の開始要求を始める場合は、新規端末Ｂが悪意の人であるとしても攻撃されるおそれはない。しかし、本実施形態の構成を採り、しかも新規端末Ｂが悪意の人だった場合、端末間の関係性が同等であるとすると、新規端末Ｂによる擾乱のリスクが増えるおそれがある。
そこで、本実施形態に係る端末登録システムでは、悪意の第三者にデータを集めさせないために、一定時間内の通信要求回数に制限することで、擾乱のリスク回避を図る。
【００５３】
図２は、本実施形態に係る端末登録システムの端末間の相互認証を実装する場合のシーケンス図である。
図２では、前記図１８に示すシーケンス図と同一処理を行うシーケンスには同一ステップ番号を付している。
図２において、図１８と対比して削減された処理ブロックおよび通信手順については破線で示している。すなわち、図２の破線に示す処理ブロックおよび通信手順は、削減されており存在しないが、説明の便宜上、表記したものである。
【００５４】
ＴＬＳ標準では暗号鍵を生成するクライアントから通信を開始するが、本実施形態に係る端末登録システムの端末間連携のユースケースでは、サーバ側（暗号鍵を受け取る側）、ここでは新規端末Ｂ２から通信を開始する。新規端末Ｂ２は、リプレイ攻撃を防ぐために、乱数を生成して通信要求（乱数Ｂ＋所有者証明書Ｂ）を送付する（ステップＳ１２）。すなわち、図２の破線に示す既存端末Ａ１からの通信開始要求（前記図１８のステップＳ１１）は存在しない。
上記（１）の「端末間の関係性が同等であること」を適用したものである。
【００５５】
次に、上記（４）の「特定の端末間でのみ連携を行うこと」を適用することで、前記図１８のステップＳ１３、ステップＳ１４、ステップＳ１５を省く。連携の可能性がある端末間で事前に所有者証明書の交換・検証が済んでいることを前提とする。
【００５６】
既存端末Ａ１は、ＴＬＳ標準のシーケンスのように新規端末Ｂ２に所有者証明書Ａを送信することなく、直ちに暗号鍵Ａを生成する（ステップＳ１６）。
既存端末Ａ１は、受信した所有者証明書Ｂに紐づく公開鍵で暗号鍵Ａ Wrapする（ステップＳ１７）。
新規端末Ｂ２は、所有者証明書Ｂのユーザが通信していることの証明のため、所有者証明書Ｂに紐づく秘密鍵で暗号鍵Ａ Unwrapする（ステップＳ１８）。
【００５７】
既存端末Ａ１は、所有者証明書Ａのユーザが通信していることの証明のため、これまでの通信内容に所有者証明書Ａに紐づく秘密鍵で署名する（ステップＳ１９）。
新規端末Ｂ２は、所有者証明書Ａのユーザが通信相手であることの確認のため、公開鍵Ａで署名検証する（ステップＳ２０）。
【００５８】
ＴＬＳ標準では暗号鍵を生成するクライアントから暗号化通信の開始通知を行い、クライアントはサーバからの開始通知を受け取るが、本実施形態に係る端末登録システムの端末間連携のシーケンスでは、これらクライアント・サーバ間の暗号化通信の開始通知を省略する（前記図１８のステップＳ２１、ステップＳ２２を省略する）。すなわち、上記ステップＳ２０までで、たがいに暗号鍵でやり取りができている。第三者は鍵をもっておらず、Unwrapできないので、鍵を送るのと同時に先行してデータを送っても、第三者は復号化できないであろうという考え方である。
【００５９】
ただし、暗号学的にはセキュリティレベルを少し下げていることになる。本実施形態に係る端末登録システムでは、鍵の再登録の頻度は低く攻撃を受ける可能性が小さいことと、悪意の第三者にデータを集めさせないために、一定時間内の通信要求回数に制限することで、リスク回避を行っている。
【００６０】
上記（３）の「一定時間内の通信要求回数に制限」（後記）するため、既存端末Ａ１は、一定時間内の送信回数を確認する（ステップＳ３１）。
既存端末Ａ１は、実際のデータ通信を開始し、暗号鍵Ａで暗号化して連携用データを送信する（ステップＳ２３）。
【００６１】
上記一定時間内の通信要求回数に制限（ステップＳ３１）について説明する。
・通信回数の削減アプローチ
本実施形態に係る端末登録システムの端末間連携のシーケンスでは、暗号化通信の開始通知（新規端末Ｂ２で暗号鍵ＡのUnwrapができたかどうかの確認）を行うことなく、暗号鍵Ａによる暗号通信を開始する。暗号化通信の開始通知を行うことなく、暗号鍵Ａによる暗号通信を開始できる理由は、相手が秘密鍵Ｂを持たない攻撃者の端末でも、暗号鍵ＡのUnwrapができないと連携用データを復号できない、からである。ただし、下記リスクが残存する。
【００６２】
・残存するリスク
新規端末Ｂ２が悪意の端末であるとする。攻撃者である新規端末Ｂ２が何度も通信要求を行い、多数の暗号化された連携用データを取得する。これにより、新規端末Ｂ２は、暗号鍵Ａの生成ルールの推測を試みることができる。
・上記リスクの対策
本実施形態では、一定時間内に、既存端末Ａが通信要求に対応する回数の閾値を設けておき、その回数を超過した場合、要求を拒否する（ステップＳ３１）。
以上、本実施形態に係る端末登録システムの端末間連携のシーケンスについて説明した。
【００６３】
［作用効果］
次に、本実施形態に係る端末登録システムの作用効果について説明する。
<比較例>
図３は、比較例のＴＬＳ標準を実装した場合のＴＥＥの必要状態を示す状態遷移図である。図３中、左側が既存端末Ａ側の状態、右側が新規端末Ｂ側の状態である。
ＴＬＳ標準を実装した場合のＴＥＥでは、既存端末Ａ側と新規端末Ｂ側とは、端末間の連携処理を行う。換言すれば、既存端末Ａ側と新規端末Ｂ側とは、端末間の連携処理を行うことが前提である。
既存端末Ａ側の状態Ａ−１では、新規端末Ｂ側に通信開始要求を発行する（図３の符号ａ参照）。また、通信によるコンテキストスイッチを行って、状態Ａ−２に遷移する（図３の符号ｂ参照）。
【００６４】
新規端末Ｂ側では、既存端末Ａ側からの通信開始要求をトリガとして状態Ｂ−１が発生する。新規端末Ｂ側の状態Ｂ−１では、乱数Ｂの生成および証明書Ｂを取得して、既存端末Ａ側に乱数Ｂおよび証明書Ｂを送付するとともに（図３の符号ｃ参照）、状態Ｂ−２に遷移する（図３の符号ｄ参照）。
【００６５】
既存端末Ａ側の状態Ａ−２では、新規端末Ｂ側からの応答待ち、証明書Ｂ検証／（「／」は、「および／または」、を表記する。以下同様。）比較、証明書Ａ取得、暗号鍵生成／Wrap、および通信内容署名を行って、新規端末Ｂ側にこれら証明書Ａ、Wrap暗号鍵、署名付情報、および暗号通信開始通知を送付するとともに（図３の符号ｅ参照）、状態Ａ−３に遷移する（図３の符号ｆ参照）。
【００６６】
新規端末Ｂ側の状態Ｂ−２では、既存端末Ａ側からの証明書Ａ、Wrap暗号鍵、署名付情報、暗号通信開始通知を受信する。状態Ｂ−２では、既存端末Ａ側からの応答待ち、証明書Ａ検証／比較、暗号鍵Unwrap、および署名検証を行って、既存端末Ａ側に暗号通信開始通知を送付するとともに（図３の符号ｇ参照）、状態Ｂ−３に遷移する（図３の符号ｈ参照）。
【００６７】
既存端末Ａ側の状態Ａ−３では、新規端末Ｂ側からの応答待ち、データ暗号化を行って、新規端末Ｂ側に連携用データを送付する（図３の符号ｉ参照）。
新規端末Ｂ側の状態Ｂ−３では、既存端末Ａ側からの応答待ち、受信した連携用データをデータ保管する。
なお、既存端末Ａ側の状態Ａ−３と新規端末Ｂ側の状態Ｂ−３で状態遷移は終了となる。
【００６８】
<実施形態>
図４は、本実施形態に係る端末登録システムのＴＥＥの必要状態を示す状態遷移図であり、図４（ａ）は端末間での証明書の交換処理を示し、図４（ｂ）は端末間の連携処理を示す。図４（ａ）（ｂ）中、左側が既存端末Ａ側の状態、右側が新規端末Ｂ側の状態である。
本実施形態に係る端末登録システムは、端末間での証明書の交換処理と、端末間の連携処理とに分けられる。
図４（ａ）に示す端末間での証明書の交換処理は、端末ペアごとに一度だけ実行される。なお、図４（ａ）の状態ｘは、既存端末Ａ側または新規端末Ｂ側で同じ処理であることを示している。
【００６９】
図４（ａ）に示すように、一方の端末側の状態ｘ−１では、証明書ｘを取得し、他方の端末側の状態ｙ−１にこの証明書ｘを送付する。
他方の端末側の状態ｙ−１では、証明書ｘを検証／比較し、証明書ｘ保管する。
例えば、一方の端末側が既存端末Ａ側である場合、既存端末Ａ側の状態ｘ−１では、証明書ｘを取得し、新規端末Ｂ側の状態ｙ−１にこの証明書ｘを送付する（図４（ａ）の符号ｊ参照）。新規端末Ｂ側の状態ｙ−１では、証明書ｘを検証／比較し、証明書ｘ保管する。このような証明書の交換処理は、端末ペア毎に一度だけ実行される。
【００７０】
図４（ｂ）に示すように、端末間の連携処理は、新規端末Ｂ側の状態Ｂ−１が開始となる。新規端末Ｂ側の状態Ｂ−１が開始となる理由については、前記図２の暗号鍵を受け取る側の新規端末Ｂ２から通信を開始するシーケンスで説明した。
【００７１】
新規端末Ｂ側の状態Ｂ−１では、乱数Ｂを生成し、既存端末Ａ側に生成した乱数Ｂを送付するとともに（図４（ｂ）の符号ｋ参照）、通信によるコンテキストスイッチを行って、状態Ｂ−３に遷移する（図４（ｂ）の符号ｌ参照）。
【００７２】
既存端末Ａ側の状態Ａ−１では、受信した乱数Ｂをもとに、暗号鍵生成／Wrap、通信内容署名、通信回数確認、およびデータ暗号化を行って、新規端末Ｂ側にこれらWrap暗号鍵、署名付情報、および連携用データを送付する（図４（ｂ）の符号ｍ参照）。
【００７３】
新規端末Ｂ側の状態Ｂ−３では、既存端末Ａ側からの応答待ち、暗号鍵Unwrap、署名検証、およびデータ保管する。
なお、既存端末Ａ側の状態Ａ−１と新規端末Ｂ側の状態Ｂ−３で状態遷移は終了となる。
【００７４】
図３に示す比較例と、図４に示す本実施形態とを比較して分かるように、本実施形態では、一つのオペレーション（端末間での証明書の交換処理／端末間の連携処理）において、必須となる通信回数は最大でも端末間で１往復となる。これにより、ＲＥＥへのコンテキストスイッチを意識したＴＥＥ内の状態数が削減される。
【００７５】
［実施例］
以下、本実施形態の実施例について説明する。
所有者証明書の発行シーケンス（図５参照）、サービスサイトへの鍵登録（図６参照）、およびサービスサイトへの認証シーケンス（図７参照）は、既存技術にそのまま適用したものである。この既存技術については、既存端末Ａ１１０と新規端末Ｂ１２０とは、同一処理を行う。このため、既存端末Ａ１１０の処理を代表して説明する。
【００７６】
<所有者証明書の発行シーケンス>
所有者証明書の発行シーケンスは、一般的な電子証明書の発行手順に従い、端末に所有者証明書（自証明書）を発行する。
図５は、所有者証明書の発行シーケンスを示す図である。
ユーザは、申請情報入力を含む証明書発行の操作を行う（ステップＳ１０１）。ユーザによる証明書発行の操作は、証明書発行アプリ１１３が受付ける。
証明書発行アプリ１１３は、証明書発行部１１７に本人証明鍵の生成要求を送付する（ステップＳ１０２）。
証明書発行部１１７は、非対称鍵ペアの生成を行う（ステップＳ１０３）。
証明書発行部１１７は、証明書管理部１１８に本人証明用秘密鍵を送付する（ステップＳ１０４）。
証明書管理部１１８は、証明書管理部１１８から送付された本人証明用秘密鍵を保管する（ステップＳ１０５）。
【００７７】
証明書発行部１１７は、証明書発行アプリ１１３に本人証明用公開鍵を送付する（ステップＳ１０６）。
証明書発行アプリ１１３は、証明書発行要求（ＣＳＲ）の生成を行う（ステップＳ１０７）。
証明書発行アプリ１１３は、証明書発行部１１７を経由して証明書管理部１１８にＣＳＲへの署名要求を送付する（ステップＳ１０８）。
証明書管理部１１８は、秘密鍵での署名を行う（ステップＳ１０９）。
証明書管理部１１８は、証明書発行部１１７を経由して証明書発行アプリ１１３に署名付きＣＳＲを送付する（ステップＳ１１０）。
証明書発行アプリ１１３は、認証局１３０に署名付きＣＳＲを送付する（ステップＳ１１１）。
【００７８】
認証局１３０は、署名検証を行う（ステップＳ１１２）。
認証局１３０は、ユーザに対面での身分証確認等により申請情報の正当性を確認する（ステップＳ１１３）。
認証局１３０は、申請情報の正当性確認した場合、証明書発行アプリ１１３に所有者証明書を発行する（ステップＳ１１４）。
証明書発行アプリ１１３は、証明書発行部１１７を経由して証明書管理部１１８に所有者証明書を送付する（ステップＳ１１５）。
証明書管理部１１８は、秘密鍵と紐付けて自証明書として保管する（ステップＳ１１６）。
証明書管理部１１８は、証明書発行部１１７を経由して証明書発行アプリ１１３に完了通知を送付する（ステップＳ１１７）。
証明書発行アプリ１１３は、ユーザに完了通知を送付する（ステップＳ１１８）。
【００７９】
<サービスサイトへの鍵登録>
ＦＩＤＯ ＵＡＦが規定する認証方式に基づき、端末の公開鍵をサービスサイト１４０に登録する。
本登録処理は、ユーザが所有する端末のいずれか１台（ここでは既存端末Ａ１１０とする）でのみ行えばよい。それ以外の端末（ここでは新規端末Ｂ１２０）は、後述の端末間連携処理を行うことにより、既存端末Ａ１１０が生成した秘密鍵を利用可能となるため、新たに新規端末Ｂ１２０で生成した公開鍵を登録する処理は不要となる。
【００８０】
図６は、サービスサイトへの鍵登録を示すシーケンス図である。
ユーザは、認証アプリ１１２にサービスサイト１４０への登録操作を行う（ステップＳ２０１）。
認証アプリ１１２は、サービスサイト１４０の登録サイトへアクセスする（ステップＳ２０２）。
サービスサイト１４０は、認証アプリ１１２に登録要求を送付する（ステップＳ２０３）。
認証アプリ１１２は、認証部１１５に認証鍵の生成要求を送付する（ステップＳ２０４）
認証部１１５は、ユーザに同意確認する（ステップＳ２０５）。
認証部１１５は、非対称鍵ペアの生成を行う（ステップＳ２０６）。
認証部１１５は、認証鍵管理部１１６に認証用秘密鍵を送付する（ステップＳ２０７）。
【００８１】
認証鍵管理部１１６は、認証用秘密鍵を保管する（ステップＳ２０８）。
認証部１１５は、登録応答の生成を行う（ステップＳ２０９）。
認証部１１５は、登録応答への署名要求を送付する（ステップＳ２１０）。
認証鍵管理部１１６は、秘密鍵で署名生成する（ステップＳ２１１）。
認証鍵管理部１１６は、認証部１１５を経由して認証アプリ１１２に署名付き登録応答を送付する（ステップＳ２１２）。
認証アプリ１１２は、サービスサイト１４０に署名付き登録応答する（ステップＳ２１３）。
サービスサイト１４０は、署名検証する（ステップＳ２１４）。
サービスサイト１４０は、認証アプリ１１２に登録完了通知を送付する（ステップＳ２１５）。
認証アプリ１１２は、ユーザに完了通知を送付する（ステップＳ２１６）。
【００８２】
<サービスサイトへの認証>
ＦＩＤＯ ＵＡＦが規定する認証方式（チャレンジ・レスポンス認証）に基づき、サービスサイトへの認証を行う。
図７は、サービスサイトへの認証を示すシーケンス図である。
ユーザは、認証アプリ１１２にサービスサイトへの認証操作を行う（ステップＳ３０１）。
認証アプリ１１２は、サービスサイト１４０の認証サイトへアクセスする（ステップＳ３０２）。
サービスサイト１４０は、認証アプリ１１２にチャレンジ文字列等による認証要求を送付する（ステップＳ３０３）。
認証アプリ１１２は、認証部１１５に署名要求を送付する（ステップＳ３０４）。
【００８３】
認証部１１５は、ユーザに同意確認する（ステップＳ３０５）。
認証部１１５は、認証鍵管理部１１６にチャレンジ文字列への署名要求を送付する（ステップＳ３０６）。
認証鍵管理部１１６は、サイトに対応する認証用秘密鍵での署名を行う（ステップＳ３０７）。
認証鍵管理部１１６は、認証部１１５を経由して認証アプリ１１２に署名付きチャレンジによる認証応答を行う（ステップＳ３０８）。
認証アプリ１１２は、サービスサイト１４０に署名付き認証応答を送付する（ステップＳ３０９）。
サービスサイト１４０は、署名検証を行う（ステップＳ３１０）。
サービスサイト１４０は、認証アプリ１１２に認証完了通知する（ステップＳ３１１）。
認証アプリ１１２は、ユーザに完了通知を送付する（ステップＳ３１２）。
【００８４】
<証明書の交換>
証明書の交換シーケンスは、連携を行う端末間で所有者証明書を交換し、保管する。
証明書の交換シーケンスは、動作概要で述べた前記（４）の特定の端末間でのみ連携を行う動作の具体例である。サーバが不特定多数のクライアントから通信を受け付けるモデルではないため、端末間での所有者証明書の交換・検証・比較は、連携時ではなく事前に行っておく。この操作は、連携を行う端末ペア（既存端末Ａ１１０と新規端末Ｂ１２０）について、双方向に行っておく必要がある
【００８５】
図８は、証明書の交換シーケンスを示す図である。
送信側端末は、既存端末Ａまたは新規端末Ｂのいずれであってもよく、受信側端末は、既存端末Ａまたは新規端末Ｂのいずれであってもよい（ただし、送信側端末で選んだ端末の他方側）。図８では、送信側端末に図１の既存端末Ａ１１０を用い、受信側端末に図１の新規端末Ｂ１２０を用いた例である。
ユーザは、既存端末Ａ１１０の端末間連携アプリ１１１に対し証明書の送信操作を行うとともに（ステップＳ４０１）、新規端末Ｂ１２０の端末間連携アプリ１２１に対し証明書の受信操作を行う（ステップＳ４０２）。
新規端末Ｂ１２０の端末間連携アプリ１２１は、既存端末Ａ１１０の端末間連携アプリ１１１との間でＮＦＣ，Bluetooth等による通信路を確立する（ステップＳ４０３）。
【００８６】
既存端末Ａ１１０の端末間連携アプリ１１１は、証明書送信部１１４ｂを経由して証明書管理部１１８に証明書取得要求を送信する（ステップＳ４０４）。
既存端末Ａ１１０の証明書管理部１１８は、証明書送信部１１４ｂを経由して端末間連携アプリ１１１に自証明書を発行する（ステップＳ４０５）。
上記、証明書送信部１１４ｂが証明書管理部１１８に証明書取得要求を送信し、証明書管理部１１８が証明書送信部１１４ｂに自証明書を発行する、操作（図８の関数２−１破線囲み参照）が前記図１の証明書送信部１１４ｂの「関数２−１」操作に該当する。
【００８７】
既存端末Ａ１１０の端末間連携アプリ１１１は、証明書管理部１１８が発行した自証明書をもとに、新規端末Ｂ１２０の端末間連携アプリ１２１に所有者証明書（送信側証明書）を送付する（ステップＳ４０６）。
【００８８】
新規端末Ｂ１２０の端末間連携アプリ１２１は、新規端末側連携部１２４の証明書受信部１２４ａに、新規端末Ｂ１２０の端末間連携アプリ１２１から送信された送信側証明書を送付する（ステップＳ４０７）。
証明書受信部１２４ａは、送信側証明書の検証を行う（ステップＳ４０８）。
証明書受信部１２４ａは、証明書管理部１２８に自証明書の要求を送付する（ステップＳ４０９）。
証明書管理部１２８は、証明書受信部１２４ａに受信側証明書を送付する（ステップＳ４１０）。
証明書受信部１２４ａは、送信側証明書と受信側証明書とを比較する（ステップＳ４１１）。送信側証明書と受信側証明書との比較は、ＣＮ（Common name）値が一致する等、予め定められた所有者一致条件を満たすか否かを確認する。
【００８９】
証明書受信部１２４ａは、証明書管理部１２８に送信側証明書の保管要求を送付する（ステップＳ４１２）。
証明書管理部１２８は、送信側証明書を他証明書として保管する（ステップＳ４１３）。
証明書管理部１２８は、証明書受信部１２４ａに完了通知を送付する（ステップＳ４１４）。
上記図８の関数１−１破線囲み操作が前記図１の新規端末Ｂ１２０の証明書受信部１２４ａの「関数１−１」操作に該当する。
【００９０】
証明書受信部１２４ａは、端末間連携アプリ１２１に完了通知を送付する（ステップＳ４１５）
端末間連携アプリ１２１は、既存端末Ａ１１０の端末間連携アプリ１１１に完了通知を送信する（ステップＳ４１６）。
既存端末Ａ１１０の端末間連携アプリ１１１は、ユーザに完了通知を送信する（ステップＳ４１７）
新規端末Ｂ１２０の端末間連携アプリ１２１は、ユーザに完了通知を送信する（ステップＳ４１８）
【００９１】
<端末間の連携>
端末間の連携は、端末間を連携させて、認証用秘密鍵のセキュアな端末間複製を実現する。
【００９２】
図９および図１０は、端末間の連携のシーケンスを示す図である。図１０は、図９に続くシーケンス図である。
送信側端末は、既存端末Ａであり、受信側端末は、新規端末Ｂである。
図９に示すように、ユーザは、既存端末Ａ１１０の端末間連携アプリ１１１に対し連携操作（例えば、端末間連携アプリの起動操作）を行うとともに（ステップＳ５０１）、新規端末Ｂ１２０の端末間連携アプリ１２１に対し連携操作を行う（ステップＳ５０２）。
新規端末Ｂ１２０の端末間連携アプリ１２１は、既存端末Ａ１１０の端末間連携アプリ１１１との間でＮＦＣ，Bluetooth等による通信路の確立を行う（ステップＳ５０３）。
【００９３】
新規端末Ｂ１２０の端末間連携アプリ１２１は、新規端末側連携部１２４の端末間連携部１２４ｃに受信側開始処理を要求する（ステップＳ５０４）。
端末間連携部１２４ｃは、乱数Ｂを生成／保持する（ステップＳ５０５）。
端末間連携部１２４ｃは、証明書管理部１２８に自証明書のＩＤ参照を要求する（ステップＳ５０６）。
証明書管理部１２８は、端末間連携部１２４ｃに自証明書のＩＤ参照結果を送付する（ステップＳ５０７）。
上記、端末間連携部１２４ｃが乱数Ｂを生成／保持するとともに、証明書管理部１２８に自証明書のＩＤ参照を要求し、証明書管理部１２８が端末間連携部１２４ｃに自証明書のＩＤ参照結果を送付する、操作（図９の関数３Ｂ−１破線囲み参照）が前記図１の端末間連携部１２４ｃの「関数３Ｂ−１」操作に該当する。
【００９４】
端末間連携部１２４ｃは、端末間連携アプリ１２１に、乱数Ｂおよび自証明書ＩＤについて処理引き渡しを行う（ステップＳ５０８）。
新規端末Ｂ１２０の端末間連携アプリ１２１は、既存端末Ａ１１０の端末間連携アプリ１１１に、乱数Ｂおよび受信側証明書ＩＤについて複製要求通信を行う（ステップＳ５０９）。
既存端末Ａ１１０の端末間連携アプリ１１１は、既存端末側連携部１１４の端末間連携部１１４ｃに対し複製要求処理（複製要求通信）を行う（ステップＳ５１０）。
【００９５】
以下、端末間連携部１１４ｃは、図９の破線囲みに示す関数３Ａ−１操作を実行する。この関数３Ａ−１操作は、図１の端末間連携部１１４ｃの「関数３Ａ−１」操作に該当する。すなわち、端末間連携部１１４ｃは、一定時間内の要求回数確認・更新を行う（ステップＳ５１１）。なお、要求回数が閾値を超過した場合の準正常処理は図１１で後述する。
端末間連携部１１４ｃは、暗号鍵Ａ生成を行う（ステップＳ５１２）。
端末間連携部１１４ｃは、証明書管理部１１８に他証明書（受信側証明書ＩＤ）を要求する（ステップＳ５１３）。
証明書管理部１１８は、端末間連携部１１４ｃに他証明書（受信側）を送付する（ステップＳ５１４）。
【００９６】
端末間連携部１１４ｃは、他証明書の公開鍵で暗号鍵ＡをWrapする（ステップＳ５１５）。
端末間連携部１１４ｃは、証明書管理部１１８に複製要求通信への署名要求を送付（ステップＳ５１６）。
証明書管理部１１８は、自証明書に紐づく秘密鍵で署名する（ステップＳ５１７）。
証明書管理部１１８は、端末間連携部１１４ｃに対し署名付き複製要求通信を行う（ステップＳ５１８）。
【００９７】
端末間連携部１１４ｃは、ユーザとの間でユーザの同意確認を行う（ステップＳ５１９）。
端末間連携部１１４ｃは、認証鍵管理部１１６に認証用秘密鍵取得の要求を送付する（ステップＳ５２０）。
認証鍵管理部１１６は、取得要求された認証用秘密鍵を端末間連携部１１４ｃに送付する（ステップＳ５２１）。
端末間連携部１１４ｃは、秘密鍵を暗号鍵Ａで暗号化する（ステップＳ５２２）。
端末間連携部１１４ｃは、証明書管理部１１８に自証明書のＩＤ参照を要求する（ステップＳ５２３）。
証明書管理部１１８は、端末間連携部１１４ｃに自証明書を送付する（ステップＳ５２４）。
上記、端末間連携部１１４ｃが一定時間内の要求回数確認・更新（ステップＳ５１１）〜端末間連携部１１４ｃが証明書管理部１１８から自証明書を受け取る（ステップＳ５２４）までの操作（図９の関数３Ａ−１破線囲み参照）が前記図１の端末間連携部１１４ｃの「関数３Ａ−１」操作に該当する。
【００９８】
端末間連携部１１４ｃは、端末間連携アプリ１１１を経由して新規端末Ｂ１２０の端末間連携アプリ１２１に、Wrapされた暗号鍵Ａ、署名付き複製要求通信、暗号化された認証鍵、送信側証明書ＩＤを送付する複製応答通信を行う（ステップＳ５２５）。
【００９９】
図１０に示すように、新規端末Ｂ１２０の端末間連携アプリ１２１は、端末間連携部１２４ｃに複製応答通信のために処理戻しを行う（ステップＳ５２６）。
以下、端末間連携部１２４ｃは、図１０の破線囲みに示す関数３Ｂ−２操作を実行する。この関数３Ｂ−２操作は、図１の端末間連携部１２４ｃの「関数３Ｂ−２」操作に該当する。すなわち、端末間連携部１２４ｃは、証明書管理部１２８に他証明書（送信側証明書ＩＤ）を要求する（ステップＳ５２７）。
証明書管理部１２８は、端末間連携部１２４ｃに他証明書（送信側）を送付する（ステップＳ５２８）。
【０１００】
端末間連携部１２４ｃは、他証明書の公開鍵で署名検証する（ステップＳ５２９）。
端末間連携部１２４ｃは、証明書管理部１２８に暗号鍵AのUnwrap要求を送付（ステップＳ５３０）。
証明書管理部１２８は、自証明書に紐づく秘密鍵でUnwrapする（ステップＳ５３１）。
証明書管理部１２８は、暗号鍵Ａで認証用秘密鍵を復号化する（ステップＳ５３２）。
証明書管理部１２８は、認証用秘密鍵を保管する（ステップＳ５３３）。
上記、端末間連携部１２４ｃが他証明書（送信側証明書ＩＤ）要求（ステップＳ５２７）〜端末間連携部１２４ｃが認証用秘密鍵を保管（ステップＳ５３３）までの操作（図９の関数３Ｂ−２破線囲み参照）が前記図１の端末間連携部１２４ｃの「関数３Ｂ−２」操作に該当する。
【０１０１】
端末間連携部１２４ｃは、端末間連携アプリ１２１に処理完了通知を送付する（ステップＳ５３３）。
端末間連携アプリ１２１は、既存端末Ａ１１０の端末間連携アプリ１１１に完了通知を送信する（ステップＳ５３４）。
既存端末Ａ１１０の端末間連携アプリ１１１は、ユーザに完了通知を送信する（ステップＳ５３５）。
新規端末Ｂ１２０の端末間連携アプリ１２１は、ユーザに完了通知を送信する（ステップＳ５３６）。
以上、「証明書の交換」（図８参照）と「端末間の連携」（図９および図１０参照）について説明した。
【０１０２】
<閾値超過時の処理方法>
次に、閾値超過時の処理方法について説明する。
暗号化データを多数取得することで、暗号鍵の生成方法を推測し、認証鍵を盗難しようとする攻撃が考えられる。
本実施形態では、認証鍵の複製要求の回数が、事前に定められた閾値（例えば１時間に３回まで等）を超過した場合、その要求を拒否する。
一方で、ユーザによる誤操作等の可能性もあるため、その時点でユーザに警告画面を表示し、操作に進むかどうかを選択させる機能をＴＥＥ内に配備する。ＴＥＥの警告画面は、マルウェア等によって改ざんできないため、セキュアにユーザ意志を確認できる。その際に、事前に登録されたユーザしか持ちえないクレデンシャル（ＰＩＮ入力や生体情報の提示等）の入力をセキュアに受付、検証する機能をＴＥＥに配備することで、より確実性を高めることが好ましい。
【０１０３】
図１１は、閾値超過時の処理を適用した端末間の連携のシーケンスを示す図である。図９と同一処理を行うステップには同一符号を付している。閾値超過時の処理は、送信側端末で行う処理であるので、図１１は、図９のうち送信側端末（既存端末Ａ）のシーケンスを抜粋して示している。
図１１に示すように、既存端末Ａ１１０の端末間連携アプリ１１１は、既存端末側連携部１１４の端末間連携部１１４ｃに対し複製要求処理（複製要求通信）を行う（ステップＳ５１０）。
端末間連携部１１４ｃは、図１１の破線囲みに示す関数３Ａ−１操作を実行する。この関数３Ａ−１操作は、図１の端末間連携部１１４ｃの「関数３Ａ−１」操作に該当する。すなわち、端末間連携部１１４ｃは、一定時間内の要求回数確認・更新を行う（ステップＳ５１１）。
端末間連携部１１４ｃは、ユーザに対し一定時間内の要求回数が多いことの警告画面を表示する（ステップＳ６０１）。
端末間連携部１１４ｃは、ユーザによる承諾・拒否の判断（ＰＩＮ等クレデンシャルの提示）を受け取る（ステップＳ６０２）。
端末間連携部１１４ｃは、ユーザ意志およびクレデンシャルを確認する（ステップＳ６０３）。
以下、図９の端末間連携部１１４ｃの「関数３Ａ−１」操作と同様の処理を行う。
【０１０４】
<名称命名機能>
次に、名称命名機能について説明する。
他証明書を取得する際に、その端末を識別可能なわかりやすい名称を、ユーザがセキュアに命名できる機能をＴＥＥに設置する。
図１２は、名称命名機能を適用した証明書の交換のシーケンスを示す図である。図８と同一処理を行うステップには同一符号を付している。名称命名機能の処理は、受信側端末で行う処理であるので、図１２は、図８のうち受信側端末（新規端末Ｂ１２０）のシーケンスを抜粋して示している。
図１２に示す関数１−１破線囲み操作が前記図１の新規端末Ｂ１２０の証明書受信部１２４ａの「関数１−１」操作に該当する。
証明書受信部１２４ａは、予め定められた所有者一致条件を満たすかを確認（ＣＮ値が一致する等）して、送信側証明書と受信側証明書の比較を行う（ステップＳ４１１）。
【０１０５】
証明書受信部１２４ａは、ユーザに送信側端末の命名要求を送付する（ステップＳ７０１）。
証明書受信部１２４ａは、ユーザから、わかりやすい名称の入力を受け取る（ステップＳ７０２）。
証明書受信部１２４ａは、証明書管理部１２８に、わかりやすい名称が付加された送信側証明書の保管要求を送付する（ステップＳ７０３）。
証明書管理部１２８は、送信側証明書を他証明書として名称と紐づけて保管する（ステップＳ７０４）。
証明書管理部１２８は、証明書受信部１２４ａに完了通知を送付する（ステップＳ７０５）。
【０１０６】
<意図しない端末の確認>
連携処理時に、相手の端末をセキュアにユーザに通知する機能をＴＥＥに設置することで、意図しない端末間で連携が行われようとしていることに気づきやすくなる。
【０１０７】
図１３は、意図しない端末の確認処理を適用した端末間の連携のシーケンスを示す図である。図９と同一処理を行うステップには同一符号を付している。意図しない端末の確認処理は、送信側端末で行う処理であるので、図１３は、図９のうち送信側端末（既存端末Ａ）のシーケンスを抜粋して示している。
図１１に示す関数３Ａ−１操作が図１の端末間連携部１１４ｃの「関数３Ａ−１」操作に該当する。すなわち、端末間連携部１１４ｃは、証明書管理部１１８に他証明書要求（受信側証明書ＩＤ）を送付する（ステップＳ８０１）。
証明書管理部１１８は、端末間連携部１１４ｃに他証明書、名称（受信側）を送付する（ステップＳ８０２）。
端末間連携部１１４ｃは、ユーザに対し、端末の名称を表示する（ステップＳ８０３）。
端末間連携部１１４ｃは、ユーザから、意図している端末であることを確認する（ステップＳ８０４）。
【０１０８】
以上説明したように、本実施形態に係る端末登録システム１０００は、既存端末Ａ１１０が、ＴＥＥを含むセキュア領域に、端末の所有者を示す所有者証明書を発行する証明書発行部１１７と、同一の所有者証明書を有する端末間で連携をするとともに、暗号鍵を生成する既存端末側連携部１１４と、認証用秘密鍵を管理する認証鍵管理部１１６と、を備え、また、ＲＥＥを含む端末環境に、端末間の通信を行う端末間連携アプリ１１１を備え、新規端末Ｂ１２０は、新規端末Ｂ１２０側の端末間連携アプリ１２１から既存端末Ａ１１０に対して、暗号鍵による暗号化通信の開始要求を行い、既存端末Ａ１１０の既存端末側連携部１１４は、認証用秘密鍵を暗号鍵で暗号化した連携用データを、同一の所有者証明書を有する新規端末Ｂ１２０に送付する。
【０１０９】
この構成により、ＴＬＳと比較して端末間の通信回数を削減することができる。例えば、一つのオペレーション（端末間での証明書の交換処理／端末間の連携処理）において、必須となる通信回数は最大でも端末間で１往復となる。これにより、ＲＥＥへのコンテキストスイッチを意識したＴＥＥ内の状態数が削減される。
【０１１０】
なお、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、明細書中や図面中に示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
【０１１１】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。
【符号の説明】
【０１１２】
１１０  既存端末Ａ（登録済み端末）
１１１，１２１  端末間連携アプリ（通信部）
１１２  認証アプリ
１１３  証明書発行アプリ
１１４  既存端末側連携部
１１４ａ  証明書受信部
１１４ｂ  証明書送信部
１１４ｃ  端末間連携部
１１５，１２５  認証部
１１６，１２６  認証鍵管理部
１１７，１２７  証明書発行部
１１８，１２８  証明書管理部
１２０  新規端末Ｂ
１２４  新規端末側連携部
１３０  認証局
１４０  サービスサイト
１０００  端末登録システム
【図１】
2020028036.tif 000003
【図２】
2020028036.tif 000004
【図３】
2020028036.tif 000005
【図４】
2020028036.tif 000006
【図５】
2020028036.tif 000007
【図６】
2020028036.tif 000008
【図７】
2020028036.tif 000009
【図８】
2020028036.tif 000010
【図９】
2020028036.tif 000011
【図１０】
2020028036.tif 000012
【図１１】
2020028036.tif 000013
【図１２】
2020028036.tif 000014
【図１３】
2020028036.tif 000015
【図１４】
2020028036.tif 000016
【図１５】
2020028036.tif 000017
【図１６】
2020028036.tif 000018
【図１７】
2020028036.tif 000019
【図１８】
2020028036.tif 000020