JP2016201699A - 情報処理装置、認証方法及びプログラム - Google Patents

Abstract

【課題】取引の安全性をより高めることができる。【解決手段】本開示の一実施形態に係る情報処理装置は、通信手段と、提示手段と、格納手段と、認証手段とを含む。通信手段は、製造および修正の少なくとも１つの権限がハードウェアによって直接または間接に特定の者に限定される信頼ソフトウェアの通信機能のみを介して、ユーザからの入力を必要とする１以上の承認内容を通信相手から受信する。提示手段は、前記信頼ソフトウェアの表示機能のみを介して前記１以上の承認内容をユーザに提示する。格納手段は、前記通信相手との認証に用いる鍵を格納する。認証手段は、前記信頼ソフトウェアの入力機能のみを介して取得した前記ユーザからの指示に応じて、前記鍵を用いた認証コードを生成する。【選択図】図２

Description

本発明は、情報処理装置、認証方法及びプログラムに関する。

近年のインターネットの普及に伴い、インターネットバンキングなどを利用して銀行取引や決済取引を簡単に行うことができ、ユーザの利便性が高まっている。一方で、元来ＰＣなどで利用するオペレーティングシステム（ＯＳ）は、利用者が自由にプログラムを開発および導入できるように設計されてきたこともあり、ＯＳやＯＳ上で動作するアプリケーションがマルウェアなどのウィルスに感染する可能性が高い。例えば、取引内容を悪意のある差し替えや改ざんすることにより不正の利益を得るＭｉｔＢ（Ｍａｎ ｉｎ ｔｈｅ Ｂｒｏｗｓｅｒ）攻撃の被害が深刻化している。近年では、いわゆるスマートフォンなど、Ａｎｄｒｏｉｄ（登録商標）ＯＳが動作する携帯端末でも同様の問題が深刻化しており、対策が急務である。
上述の問題に対し、ＵＳＢデバイスを接続し、ＰＣの処理とは別の通信処理を行うことで、ＭｉｔＢ攻撃対策を行う技術がある（例えば、非特許文献１参照）。

Thomas Weigold, Thorsten Kramp, Reto Hermann, Frank Horing, Peter Buhler, and Michael Baentsch,"The Zurich Trusted Information Channel- an Efficient Defence Against Man-in-the-Middle and Malicious software Attacks"，TRUST 2008, LNCS 4968, pp. 75-91, 2008.

しかし、上述の手法では、認証の際にスマートフォンとは別に、決済処理専用のデバイスが必要となるため、携帯性や取引の利便性の観点から、ユーザにとっては煩わしさが生じる。

本発明は、上述した事情を考慮してなされたものであり、取引の安全性をより高めることができる情報処理装置、認証方法及びプログラムを提供することを目的とする。

上述の課題を解決するため、本実施形態にかかる情報処理装置は、通信手段と、提示手段と、格納手段と、認証手段とを含む。通信手段は、製造および修正の少なくとも１つの権限がハードウェアによって直接または間接に特定の者に限定される信頼ソフトウェアの通信機能のみを介して、ユーザからの入力を必要とする１以上の承認内容を通信相手から受信する。提示手段は、前記信頼ソフトウェアの表示機能のみを介して前記１以上の承認内容をユーザに提示する。格納手段は、前記通信相手との認証に用いる第１鍵を格納する。認証手段は、前記信頼ソフトウェアの入力機能のみを介して取得した前記ユーザからの指示に応じて、前記第１鍵を用いた認証コードを生成する。

本発明の情報処理装置、認証方法及びプログラムによれば、取引の安全性をより高めることができる。

本実施形態に係る情報処理装置を含む端末のアーキテクチャを示す図。 本実施形態に係る情報処理装置を示すブロック図。 情報処理装置と通信相手との通信処理の時系列を示すシーケンス図。 通信相手ごとに鍵を変更する場合の情報処理装置の詳細を示すブロック図。 Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌで情報処理装置に認証されたアプリケーションを信頼ソフトウェアとして用いる場合のセキュアエレメントとを含むブロック図。

以下、図面を参照しながら本発明の実施形態に係る情報処理装置、認証方法及びプログラムについて詳細に説明する。なお、以下の実施形態中では、同一の番号を付した部分については同様の動作を行うものとして、重ねての説明を省略する。

本実施形態に係る情報処理装置を含む端末のアーキテクチャについて図１を参照して説明する。
図１は、いわゆるスマートフォンなどのＯＳが動作する端末のアーキテクチャ１００である。

アーキテクチャ１００は、セキュアエレメント１０１、信頼ソフトウェア１０２、ＯＳ（オペレーティングシステム）１０３およびアプリケーション１０４−１および１０４−２を含む。

セキュアエレメント１０１は、本実施形態に係る情報処理装置を含み、例えばＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）、ＵＳＩＭ（Ｕｎｉｖｅｒｓａｌ ＳＩＭ）などのような耐タンパー性を有したハードウェアである。

信頼ソフトウェア１０２は、製造および修正の少なくとも１つの権限がハードウェアを介して直接的または間接的に特定の者に限定されるソフトウェアであり、信頼ソフトウェア１０２がファームウェアおよびＯＳの場合は、メーカー、キャリアなど、ハードウェアを製造販売している一部の事業者に製造または修正の権限が限定されるファームウェアまたはＯＳである。信頼ソフトウェア１０２がアプリケーションの場合は、ファームウェアまたはＯＳに組み込まれたコード署名などの技術的な方法によって、特定のアプリケーションベンダーにソフトウェアの製造または修正の権限が限定されるアプリケーションである。

信頼ソフトウェア１０２の一例としては、ＳＩＭ Ａｐｐｌｉｃａｔｉｏｎ Ｔｏｏｌｋｉｔ、ＢＩＯＳ、ＧＳＭＡ Ｈａｎｄｓｅｔ ＡＰＩｓ ＆ Ｒｅｑｕｉｒｅｍｅｎｔｓに定義されたＡｃｃｅｓｓ Ｃｏｎｔｒｏｌで情報処理装置に認証されたアプリケーション、およびＧｌｏｂａｌＰｌａｔｆｏｒｍ Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔに定義されたＴｒｕｓｔｅｄ Ａｐｐｌｉｃａｔｉｏｎが挙げられる。信頼ソフトウェア１０２は、少なくとも、通信機能、表示機能および入力機能を有する。信頼ソフトウェア１０２の通信機能、表示機能および入力機能はそれぞれ、ＯＳ１０３またはＯＳ上で動作するアプリケーション１０４を介さずに、通信相手と通信したり、ユーザに対して画面を表示したり、ユーザからの入力を受け付けたりすることができる。

なお、信頼ソフトウェア１０２として、ＧＳＭＡ Ｈａｎｄｓｅｔ ＡＰＩｓ ＆ Ｒｅｑｕｉｒｅｍｅｎｔｓに定義されたＡｃｃｅｓｓ Ｃｏｎｔｒｏｌで情報処理装置に認証されたアプリケーションを用いる場合は、ＯＳ１０３およびアプリケーション１０４の一部を利用することになる。

ＯＳ１０３は、システムを動作させるための一般的なＯＳであり、例えば、Ａｎｄｒｏｉｄ（登録商標）ＯＳが該当する。

アプリケーション１０４−１およびアプリケーション１０４−２は、一般の事業者または個人がＯＳを利用して製造したソフトウェアであり、ユーザがＯＳの機能を介して利用するソフトウェアである。アプリケーション１０４は、例えば、オンライン銀行アプリケーション、インターネットブラウザが挙げられる。

次に、本実施形態に係る情報処理装置について図２のブロック図を参照して説明する。
本実施形態に係る情報処理装置２００は、通信部２０１、鍵格納部２０２、認証部２０３および提示部２０４を含む。

通信部２０１は、信頼ソフトウェア１０２の通信機能のみを介して通信相手から承認内容を受信する。通信相手は、例えば、銀行、オンラインショップ等のプロバイダであり、取引に秘匿性やＭｉｔＢ攻撃耐性が要求される通信相手である。なお、これらの通信相手に限定されず、取引に秘匿性やＭｉｔＢ攻撃耐性が要求されない通信相手でもよい。承認内容とは、例えば、銀行との取引内容やオンラインショップにおける決済内容といった、ユーザの承認を含む、ユーザからの何らかの入力を必要とする内容である。なお、以下では、１つの承認内容を受信して処理する場合を想定して説明するが、複数の承認内容を受信する場合であっても同様に処理できる。通信部２０１は、後述の認証部２０３から暗号化データを受け取る場合、暗号化データを信頼ソフトウェア１０２の通信機能のみを介して通信相手（または外部のデバイス）に出力する。

なお、通信部２０１は、通信相手からの情報をインターネット経由で取得または通信相手に情報をインターネット経由で提供してもよいし、信頼ソフトウェア１０２を介してショートメールサービス（ＳＭＳ）および非接触通信（ＮＦＣなど）を用いて情報を取得してもよいし、ＳＭＳおよびＮＦＣを用いて情報を提供してもよい。

鍵格納部２０２は、通信相手との認証に用いる鍵を格納する。鍵としては、共通鍵暗号方式を用いる場合は、通信相手と同一の共通鍵を格納すればよいし、公開鍵暗号方式（ＩＤベース暗号方式）を用いる場合は、鍵センター（図示せず）より配布される固有の秘密鍵を格納すればよい。鍵格納部２０２は、鍵として通信相手との認証に用いる鍵のほか、セキュアエレメントごとに一意である利用者を特定するための識別子と任意の値である世代を含む付帯情報とを格納してもよい。

認証部２０３は、通信部２０１から承認内容を、鍵格納部２０２から鍵をそれぞれ受け取る。認証部２０３は、承認内容にデジタル署名および認証コードの少なくともどちらか１つが付される場合、承認内容に付されるデジタル署名または認証コードについて認証処理を行い、認証処理が成功したかどうかを示す認証結果を生成する。

また、認証部２０３は、信頼ソフトウェア１０２の入力機能のみを介してユーザ指示を取得する場合、鍵格納部２０２から鍵を受け取り、ユーザ指示に応じて、鍵を用いて認証コードを生成する。認証部２０３は、認証コードを用いて外部に送信すべきユーザ指示を暗号化し、暗号化データを生成する。なお、認証部２０３は、暗号化データを生成する場合に、共通鍵暗号方式を用いる場合は、例えばＩＥＴＦ ＲＦＣ ２１０４で記載されたＨＭＡＣ（Ｈａｓｈ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）等で認証コードを生成し、ＩＳＯ／ＩＥＣ １８０３３−３で定義されたＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）等の暗号化アルゴリズムで暗号化を行う。ＩＤベース暗号方式を用いる場合は、ＩＤベース署名を認証コードとしてＩＤベース暗号で暗号化して送信してもよい。

さらに、認証部２０３は、共通鍵暗号方式を用いる場合は、ＨＭＡＣ等で生成した認証コードから部分ビット列を抽出した短いワンタイムパスワードを認証コードとして生成してもよい。

提示部２０４は、認証部２０３からプロバイダから受信した承認内容に付された認証コードまたはデジタル署名が真正であるか否かの認証結果を受け取り、認証結果が認証処理が成功したことを示す場合、信頼ソフトウェア１０２の表示機能のみを介して取引情報を実行して良いか否かを確認する承認内容をユーザに提示する。なお、承認内容にデジタル署名または認証コードが付されていない場合、提示部２０４は、認証部２０３の認証処理を経ずに、通信部２０１から承認内容を受け取ってもよい。

次に、本実施形態に係る情報処理装置２００と通信相手との通信処理について、図３のシーケンス図を参照して説明する。
図３は、ユーザ３５１と通信相手である銀行３５２との間の決済取引に関する通信処理の一例を時系列で示したシーケンス図である。ユーザ３５１は、情報処理装置２００と信頼ソフトウェア１０２とを搭載する端末（携帯電話、スマートフォン、タブレットなど）を用いて取引を行う例を示す。なお、図３の例では、通信処理の暗号化方式として、共通鍵暗号方式を用いる場合を想定し、銀行３５２と情報処理装置２００との間で共通の鍵ｋ_１およびｋ_２を保持しているとする。

ステップＳ３０１では、ユーザ３５１から、端末のＯＳ上で動作するＷｅｂブラウザまたはアプリケーションを用いて、取引内容ｘを銀行３５２に送信する。

ステップＳ３０２では、銀行３５２が、ユーザ３５１から取引内容ｘを受け取り、取引内容ｘについて暗号化し、ｘの暗号化データｅ_１を生成する。ｘの暗号化は、例えば、以下の処理を行えばよい。まず、取引内容ｘ、時刻情報ｔ_１および１６０ビット以上の暗号学的乱数を用いるランダム値ｒをパラメータとして、鍵ｋ_１についての任意の関数Ｈ_ｋ１を計算することで、認証コードｃ_１を生成する。続いて、取引内容ｘ、時刻情報ｔ_１、ランダム値ｒおよび認証コードｃ_１をパラメータとして、鍵ｋ_２についての任意の関数Ｅ_ｋ２を計算した計算結果を、ｘの暗号化データｅ_１として用いればよい。なお、時刻情報ｔ_１は、認証コードｅ_１の生成時の時刻である。

なお、銀行３５２では、ランダム値ｒを取引ＩＤとして（ｒ，ｘ，ｔ_１）をデータベース（図示せず）に格納しておく。

ステップＳ３０３では、銀行３５２が、暗号化データｅ_１をユーザ３５１の端末に送信する。

ステップＳ３０４では、端末の信頼ソフトウェア１０２が、通信機能を用いて銀行３５２から暗号化データｅを受信し、情報処理装置２００の通信部２０１が、信頼ソフトウェア１０２を介して、暗号化データｅ_１を受信する。

ステップＳ３０５では、情報処理装置２００の認証部２０３が、暗号化データｅ_１を復号して、（ｘ，ｔ_１，ｒ，ｃ_１）を得る。認証部２０３は、以下の２つの条件を満たすかどうかを判定する。
（１）認証コードｃ_１が一致するか、すなわちＨ_ｋ１（ｘ、ｔ_１、ｒ）＝ｃ_１
（２）時刻情報ｔ_１が誤差ｗ以内であるか、すなわちｔ∈［ｔｉｍｅ−ｗ、ｔｉｍｅ＋ｗ］
認証部２０３は、上記（１）および（２）の条件を満たす場合、認証処理が成功したという認証結果を生成する。（１）および（２）の条件の少なくとも１つを満たさない場合、認証処理が失敗したとして通信処理を終了する。ここでは、認証処理が成功したという認証結果を得ると想定する。

ステップＳ３０６では、認証処理が成功しているので、情報処理装置２００の提示部２０４が、信頼ソフトウェア１０２の表示機能を介して、復号した取引結果ｘをユーザ３５１に提示する。具体的には、信頼ソフトウェア１０２の表示機能のみによって、取引内容ｘが端末の画面に表示され、ユーザ３５１は、取引内容ｘを閲覧することができる。

ステップＳ３０７では、ユーザ３５１が、信頼ソフトウェア１０２の表示機能を介して表示された取引結果ｘに対して、ＯＫであるかＮＧであるかを判断し、判断結果として信頼ソフトウェア１０２の入力機能のみを用いてＯＫまたはＮＧを入力する。なお、ここでは、ＯＫまたはＮＧの二択としているが、数値や文字列を入力してもよい。

ステップＳ３０８では、情報処理装置の通信部２０１が、ユーザ３５１から信頼ソフトウェア１０２の入力機能に入力された「ＯＫ」または「ＮＧ」を、ユーザ指示ｙとして取得する。具体的には、信頼ソフトウェア１０２が、信頼ソフトウェア１０２の入力機能に入力された「ＯＫ」または「ＮＧ」を情報処理装置２００で取り扱い可能なユーザ指示ｙに変換して、情報処理装置２００の通信部２０１に渡す。例えば、「ＯＫ」が入力された場合は「１」を生成し、「ＮＧ」が入力された場合は「０（ゼロ）」を生成する。ここでは、「ＯＫ」が入力されたとして、ユーザ指示「ｙ＝１」が生成される場合を想定する。

ステップＳ３０９では、情報処理装置２００の認証部２０３が、ユーザ指示ｙを暗号化して暗号化データｅ_２を生成する。暗号化データｅ_２の生成方法としては、ステップＳ３０２と同様に、まず、ユーザ指示ｙ、時刻情報ｔ_２およびランダム値ｒをパラメータとして、鍵ｋ_１についての任意な関数Ｈ_ｋ１を計算することで、認証コードｃ_２を生成する。続いて、ユーザ指示ｙ、時刻情報ｔ_２、ランダム値ｒおよび認証コードｃ_２をパラメータとして、鍵ｋ_２についての任意の関数Ｅ_ｋ２を計算した計算結果を、暗号化データｅ_２として用いればよい。
なお、時刻情報ｔ_２は、例えば、信頼ソフトウェア１０２経由で認証コードｃ_２の生成時点の時刻を取得すればよい。

ステップＳ３１０では、情報処理装置２００の通信部２０１が、信頼ソフトウェア１０２の通信機能を介して暗号化データｅ_２を送信する。

ステップＳ３１１では、銀行３５２が、ユーザ３５１から暗号化データｅ_２を受け取り、暗号化データｅ_２を復号する。復号が成功すると想定すると、ユーザ指示ｙ、時刻情報ｔ_２およびランダム値ｒを得ることができる。
銀行３５２は、以下の２つの条件を満たすかどうかを判定する。
（３）認証コードｃ_２が一致するか、すなわちＨ_ｋ１（ｘ、ｔ_２、ｒ）＝ｃ_２
（４）時刻情報ｔ_２が誤差ｗ以内であるか、すなわちｔ_２∈［ｔｉｍｅ−ｗ、ｔｉｍｅ＋ｗ］
銀行３５２は、（３）および（４）の条件を満たす場合、ランダム値ｒを取引ＩＤとして格納したデータベースから、ランダム値ｒに対応する取引内容ｘおよび時刻情報ｔ_１を検索し、タイムアウト時間ｔ_０に対して「ｔ＜ｔ_２≦ｔｉｍｅ かつ ｔ_２＜ｔ＋ｔ_０」を満たし、かつ「ユーザ指示ｙ＝１」を満たすかどうかを判定する。ここで、タイムアウト時間ｔ_０は、銀行３５２とユーザ３５１との取引を中止するための閾値となる時間である。

ステップＳ３１２では、銀行３５２が、「ｔ＜ｔ_２≦ｔｉｍｅ かつ ｔ_２＜ｔ＋ｔ_０」を満たし、かつ「ユーザ指示ｙ＝１」を満たす場合に、取引ｘを実行すればよい。以上で情報処理装置２００と通信相手との通信処理を終了する。

なお、プロバイダなどの通信相手と通信を行う場合は、鍵漏洩時のセキュリティの観点から、プロバイダごとに鍵をユーザの識別子とを変更することが望ましい。

通信相手ごとに鍵を変更する場合の情報処理装置の詳細について図４のブロック図を参照して説明する。
図４に示す情報処理装置４００は、通信部２０１、鍵格納部２０２、提示部２０４、第１識別子格納部４０１、第２識別子格納部４０２、識別子変換部４０３、鍵変換部４０４および認証部４０５を含む。
通信部２０１、鍵格納部２０２および提示部２０４については、図２に示す情報処理装置２００における動作と同様であるので、ここでの説明を省略する。

第１識別子格納部４０１は、自己の識別子（第１識別子ともいう）を格納する。
第２識別子格納部４０２は、通信相手の識別子を格納する。なお、第２識別子格納部４０２は、通信相手の識別子に、世代を含む付帯情報を対応付けて格納してもよい。世代は任意の値であり、１，２，３，・・・といったカウンタ値でもよいし、１２８ｂｉｔ程度の物理乱数または暗号学的擬似乱数などでもよい。

識別子変換部４０３は、第１識別子格納部４０１から第１識別子を、第２識別子格納部４０２から通信相手の識別子をそれぞれ受け取り、通信相手の識別子で表される通信相手に応じて第１識別子を変換し、第２識別子を生成する。第１識別子から第２識別子への変換は、例えば任意のハッシュ関数を用いて変換すればよい。
鍵変換部４０４は、鍵格納部２０２から鍵を、第２識別子格納部４０２から通信相手の識別子をそれぞれ受け取り、通信相手に応じて第１鍵を変換し、第２鍵を生成する。第１鍵から第２鍵への変換は、例えば任意のハッシュ関数を用いて変換すればよい。

認証部４０５は、上述の認証部２０３とほぼ同様の動作を行うが、識別子変換部４０３から第２識別子を、鍵変換部４０４から第２鍵をそれぞれ受け取り、第２識別子および第２鍵を用いて認証を行う点が異なる。

次に、情報処理装置４００が共通鍵暗号方式を用いる場合の認証処理について説明する。ここでは、情報処理装置４００とプロバイダとの間の通信における認証処理を想定する。

情報処理装置４００には、鍵センターから、任意のプロバイダ（および付帯情報）とセキュアエレメント１０１との鍵Ｋ_ｉｊを導出可能なＫ_ｉが、ユーザの鍵として配布される。鍵センターのマスター鍵をＭとすれば、Ｋ_ｉ＝Ｅ_Ｍ（ｉ）で表せる。

プロバイダには、鍵センターから、プロバイダの識別子（および付帯情報）に対応する鍵セットＫｊが配布される。プロバイダの識別子（および付帯情報）をｊとすると、Ｋ_ｊ＝｛Ｋ_１ｊ，Ｋ_２ｊ，...，Ｋ_ｎｊ｝と表せる（ｎは、３以上の整数）。情報処理装置４００とプロバイダとは、互いにＫ_ｉｊを導出可能であり、例えば情報処理装置４００では、鍵変換部４０４が、Ｋ_ｉ（第１鍵）をＫ_ｉｊ（第２鍵）に変換する際に以下の式（１）を用いて導出すればよい。

よって、情報処理装置４００とプロバイダとの間で共通鍵としてＫ_ｉｊを用いた暗号通信とメッセージ認証とを行うことができる。

一方、識別子については、識別子変換部４０３が、プロバイダの識別子ｊに応じて、ユーザｉ（第１識別子）を式（２）を用いてＩＤ_ｉｊ（第２識別子）に変換する。

情報処理装置４００にはサイズが小さいコンパクトな鍵導出アルゴリズムを用いて、プロバイダ側の鍵の格納サイズを大きくすることで、記憶容量の制限が厳しいセキュアエレメント１０１の記憶領域を大幅に節約することができる。また、プロバイダの識別子に加え、世代などの付帯情報を用いて鍵を生成することで、プロバイダ側で鍵の漏洩がある場合でも世代を更新するだけでよく、同じ識別子を保持したまま鍵Ｋ_ｉｊを変更することができる。よって、利便性を保持したまま、取引の安全性を高い状態に保持できる。

次に、情報処理装置４００がＩＤベース暗号方式を用いる場合の処理について説明する。
情報処理装置４００には、秘密鍵Ｋ_ｉが配布される。鍵センターのマスター秘密鍵をＳとすれば、Ｋ_ｉ＝Ｇｅｎ（Ｓ，ｉ）で表せる。

プロバイダには、プロバイダｊに対して、秘密鍵Ｋ_ｊが配布される。マスター秘密鍵Ｓを用いれば、Ｋ_ｊ＝Ｇｅｎ（Ｓ，ｊ）で表せる。

暗号通信を行う場合は、情報処理装置４００が、識別子ｉと通信相手に送信するメッセージｍとを用いて、暗号化アルゴリズムＥにより、暗号文ｃを生成する。すなわち、ｃ＝Ｅ_ｉ（ｍ）で表せる。

復号側であるプロバイダでは、暗号文ｃと秘密鍵Ｋ_ｉとを用いて、復号アルゴリズムＤによりメッセージを復号する。すなわち、

で表せる。
また、デジタル署名の作成の場合は、秘密鍵Ｋ_ｊとメッセージｍとから署名アルゴリズムＳを用いて署名ｓを作成する。すなわち、

で表せる。
検証の場合は、署名ｓと署名者の識別子ｊとを用いて検証アルゴリズムＶを通した結果が、メッセージｍと一致するかどうかで判定されればよい。

なお、上記の全てのアルゴリズムは、公開パラメータＰも入力されているものとする。
また、例えば以下の式（３）および式（４）に示す式において、鍵変換部４０４が、Ｋ_ｉ（第１鍵）をＩＤベース暗号の準同型性を用いてｉ’、Ｋｉ’（第２鍵）にそれぞれ変換して用いればよい。

なお、式（３）および式（４）は、ＲＦＣ５０９１ ＢＢ０４方式に相手の識別子に応じた識別子変換および鍵変換を施した例であり、ｈは｛０，１｝＊→Ｚｑ＊の一方向性ハッシュ関数であり、ＧｑはＲＦＣ５０９１ ＢＢ０４方式の公開パラメータである。

一方、識別子については、識別子変換部４０３が、プロバイダの識別子ｊに応じて、ユーザｉ（第１識別子）を式（５）を用いてＩＤ_ｉｊ（第２識別子）に変換する。

上記のＩＤベース暗号方式を用いれば、情報処理装置４００内にはプロバイダの識別子および付帯情報を格納しておけばよいため、必要となる記憶容量を節約できる。また、プロバイダの鍵漏洩についても世代などの付帯情報を更新することで、セキュリティレベルを維持することができる。

次に、信頼ソフトウェアとして、ＧＳＭＡ Ｈａｎｄｓｅｔ ＡＰＩｓ ＆ Ｒｅｑｕｉｒｅｍｅｎｔｓに定義されたＡｃｃｅｓｓ Ｃｏｎｔｒｏｌで情報処理装置２００に認証されたアプリケーションを用いる場合について図５を参照して説明する。
図５に示すブロック図は、各要素がどのアーキテクチャに属するかを示したものである。
図５では、アーキテクチャとして、アプリケーション領域５５１、ネイティブユーザ領域５５２、システム領域５５３およびセキュアエレメント領域５５４が示される。

アプリケーション領域５５１には、プロバイダアプリケーション５０１およびＳＩＭ−ＯＴＰアクセス部５０２が含まれる。
ネイティブユーザ領域５５２には、ネイティブコード部５０９が含まれる。

システム領域５５３には、ランタイム部５０３、Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４、証明書格納部５０５、画面表示ライブラリ５１０およびディスプレイドライバ５１１が含まれる。
セキュアエレメント領域５５４には、証明書ハッシュ格納部５０６、セキュアエレメント内Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ部５０７および情報処理装置５０８が含まれる。

プロバイダアプリケーション５０１は、ユーザによりインストールされるアプリケーションである。なお、プロバイダアプリケーション５０１は、正規ルートのみからダウンロード可能とする。
ＳＩＭ−ＯＴＰアクセス部５０２は、セキュアエレメント領域５５４に対するデータの送受信を行う。

ランタイム部５０３は、例えばアンドロイドランタイムであり、Ｄａｌｖｉｋ仮想マシンを含み、Ｊａｖａ（登録商標）コードにより、ＳＩＭ−ＯＴＰアクセス部５０２およびＯｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４からのデータが処理される。なお、Ｊａｖａコードによる処理は、セキュアエレメントから情報を取り出す処理のみである。
Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４は、ＳＩＭａｌｉａｎｃｅにて標準化されたＡＰＩであり、Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌを含む。Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌは、ＧＳＭＡで標準化された機能である。

証明書格納部５０５は、プロバイダアプリケーション５０１のＵＩＤとアプリケーション証明書情報とを対応付けて格納する。
証明書ハッシュ格納部５０６は、セキュアエレメント領域５５４に情報処理装置５０８が登録される場合に、情報処理装置５０８にアクセスするアプリケーションのアプリケーション証明書のハッシュ値（ＳＨＡ１）を事前に格納する。

セキュアエレメント内Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ部５０７は、ＧＳＭＡにて標準化された機能であり、証明書格納部５０５に格納されるアプリケーション証明書情報に基づくハッシュ値と証明書ハッシュ格納部５０６に格納されるハッシュ値とを比較する。
情報処理装置５０８は、上述の情報処理装置２００，４００と同様の動作を行い、ＯＴＰの生成、セッション鍵の交換、取引情報の暗号化、および暗号化された取引情報の送信を行う。

ネイティブコード部５０９は、セッション鍵の交換や、暗号化された取引情報を復号化し、取引情報をネイティブコードにより送信する。
画面表示ライブラリ５１０は、画面表示を行うためのライブラリである。
ディスプレイドライバ５１１は、ディスプレイに取引情報などを表示させるためのドライバである。

次に、図５に示す信頼ソフトウェアを用いたアクセス制御処理について具体的に説明する。
ここでは、セキュアエレメントとしてＳＩＭを想定し、プロバイダアプリケーション５０１として、銀行アプリを想定する。また、証明書ハッシュ格納部５０６に銀行アプリに関するアプリケーション証明書のハッシュ値が予め格納される場合を想定する。

ステップＳ１では、銀行アプリがインストールされる場合、インストールと同時に、システム領域５５３の証明書格納部５０５に、銀行アプリのＵＩＤとアプリケーション証明書情報とが対応付けて登録される。
ステップＳ２では、銀行アプリからＳＩＭ内の情報処理装置５０８に処理実行の要求が行われる。この場合、銀行アプリは、ＳＩＭ−ＯＴＰアクセス部５０２およびランタイム部５０３を介して、Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４にアクセスする。

ステップＳ３では、Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４が、処理実行の要求に含まれる銀行アプリのＵＩＤを取得する。
ステップＳ４では、Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４が、証明書格納部５０５からＵＩＤに該当するアプリケーション証明書情報を検索して取得する。

ステップＳ５では、Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４が、Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌを経由して、セキュアエレメント領域５５４内のセキュアエレメント内Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ部５０７にアプリケーション証明書情報を渡す。
ステップＳ６では、セキュアエレメント内Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ部５０７が、アプリケーション証明書情報と合致するハッシュ値と、証明書ハッシュ格納部５０６に格納されるハッシュ値とを比較する。

ステップＳ７では、比較した２つのハッシュ値が同じである場合、正常な処理であると判定され、Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４が、情報処理装置５０８に処理実行の要求を渡す。その後、情報処理装置５０８では、処理結果をＯｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４、ランタイム部５０３およびＳＩＭ−ＯＴＰアクセス部５０２を介して銀行アプリに送信する。
一方、比較した２つのハッシュ値が異なる場合、不正なアクセスであると判定され、Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部５０４、ランタイム部５０３およびＳＩＭ−ＯＴＰアクセス部５０２を介して銀行アプリにエラーコードを返す。以上でアクセス制御の処理を終了する。

以上に示した本実施形態によれば、通信相手との決済処理を含む通信処理において、耐タンパー性を有するセキュアエレメントに含まれる情報処理装置、および、信頼ソフトウェアの通信機能、表示機能および入力機能のみを用いて決済処理を行うことにより、ＯＳやＯＳ上で動作するアプリケーションがマルウェアなどにより感染している場合でも、マルウェアに感染したＯＳやアプリケーションを介することなく通信処理を行うことできる。よって、アプリケーションを介して通信処理を実行するよりも、取引の安全性を飛躍的に向上させることができる。

上述の実施形態の中で示した処理手順に示された指示は、ソフトウェアであるプログラムに基づいて実行されることが可能である。汎用の計算機システムが、このプログラムを予め記憶しておき、このプログラムを読み込むことにより、上述した情報処理装置による効果と同様な効果を得ることも可能である。上述の実施形態で記述された指示は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フレキシブルディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ±Ｒ、ＤＶＤ±ＲＷ、Ｂｌｕ−ｒａｙ（登録商標）Ｄｉｓｃなど）、半導体メモリ、又はこれに類する記録媒体に記録される。コンピュータまたは組み込みシステムが読み取り可能な記録媒体であれば、その記憶形式は何れの形態であってもよい。コンピュータは、この記録媒体からプログラムを読み込み、このプログラムに基づいてプログラムに記述されている指示をＣＰＵで実行させれば、上述した実施形態の情報処理装置と同様な動作を実現することができる。もちろん、コンピュータがプログラムを取得する場合又は読み込む場合はネットワークを通じて取得又は読み込んでもよい。
また、記録媒体からコンピュータや組み込みシステムにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワーク等のＭＷ（ミドルウェア）等が本実施形態を実現するための各処理の一部を実行してもよい。
さらに、本実施形態における記録媒体は、コンピュータあるいは組み込みシステムと独立した媒体に限らず、ＬＡＮやインターネット等により伝達されたプログラムをダウンロードして記憶または一時記憶した記録媒体も含まれる。
また、記録媒体は１つに限られず、複数の媒体から本実施形態における処理が実行される場合も、本実施形態における記録媒体に含まれ、媒体の構成は何れの構成であってもよい。

なお、本実施形態におけるコンピュータまたは組み込みシステムは、記録媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するためのものであって、パソコン、マイコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であってもよい。
また、本実施形態におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本実施形態における機能を実現することが可能な機器、装置を総称している。

本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行なうことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。

１００・・・アーキテクチャ、１０１・・・セキュアエレメント、１０２・・・信頼ソフトウェア、１０３・・・オペレーティングシステム、１０４−１，１０４−２・・・アプリケーション、２００，４００・・・情報処理装置、２０１・・・通信部、２０２・・・鍵格納部、２０３・・・認証部、２０４・・・提示部、３５１・・・ユーザ、３５２・・・銀行、４０１・・・第１識別子格納部、４０２・・・第２識別子格納部、４０３・・・識別子変換部、４０４・・・鍵変換部、４０５・・・認証部、５０１・・・プロバイダアプリケーション、５０２・・・ＳＩＭ−ＯＴＰアクセス部、５０３・・・ランタイム部、５０４・・・Ｏｐｅｎ Ｍｏｂｉｌｅ ＡＰＩ部、５０５・・・証明書格納部、５０６・・・証明書ハッシュ格納部、５０７・・・セキュアエレメント内Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ部、５０８・・・情報処理装置、５０９・・・ネイティブコード部、５１０・・・画面表示ライブラリ、５１１・・・ディスプレイドライバ、５５１・・・アプリケーション領域、５５２・・・ネイティブユーザ領域、５５３・・・システム領域、５５４・・・セキュアエレメント領域。

信頼ソフトウェア１０２は、製造および修正の権限がハードウェアを介して直接的または間接的に特定の者に限定されるソフトウェアであり、信頼ソフトウェア１０２がファームウェアおよびＯＳの場合は、メーカー、キャリアなど、ハードウェアを製造販売している一部の事業者に製造および修正の権限がハードウェア等によって技術的に限定されるファームウェアおよびＯＳである。信頼ソフトウェア１０２がアプリケーションの場合は、ハードウェア、ファームウェアまたはＯＳに組み込まれたコード署名などの技術的な方法によって、特定のアプリケーションベンダーにソフトウェアの製造および修正の権限が限定されるアプリケーションである。

信頼ソフトウェア１０２の一例としては、ＳＩＭ Ａｐｐｌｉｃａｔｉｏｎ Ｔｏｏｌｋｉｔ、ＢＩＯＳ、ＧＳＭＡ Ｈａｎｄｓｅｔ ＡＰＩｓ ＆ Ｒｅｑｕｉｒｅｍｅｎｔｓに定義されたＡｃｃｅｓｓ Ｃｏｎｔｒｏｌで情報処理装置に認証されたアプリケーション、およびＧｌｏｂａｌＰｌａｔｆｏｒｍ Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔに定義されたＴｒｕｓｔｅｄ Ａｐｐｌｉｃａｔｉｏｎが挙げられる。信頼ソフトウェア１０２は、少なくとも、通信機能、表示機能および入力機能を有する。信頼ソフトウェア１０２の通信機能、表示機能および入力機能はそれぞれ、ＯＳ１０３またはＯＳ上で動作するアプリケーション１０４に妨げられずに、通信相手と通信したり、ユーザに対して画面を表示したり、ユーザからの入力を受け付けたりすることができる。

Claims (9)

1. 製造および修正の少なくとも１つの権限がハードウェアによって直接または間接に特定の者に限定される信頼ソフトウェアの通信機能のみを介して、ユーザからの入力を必要とする１以上の承認内容を通信相手から受信する通信手段と、
   前記信頼ソフトウェアの表示機能のみを介して前記１以上の承認内容をユーザに提示する提示手段と、
   前記通信相手との認証に用いる第１鍵を格納する鍵格納手段と、
   前記信頼ソフトウェアの入力機能のみを介して取得した前記ユーザからの指示に応じて、前記第１鍵を用いた認証コードを生成する認証手段と、を具備することを特徴とする情報処理装置。
2. 自己の第１識別子を格納する第１識別子格納手段と、
   前記通信相手の識別子を格納する第２識別子格納手段と、
   前記通信相手に応じて前記第１識別子を変換し、第２識別子を生成する識別子変換手段と、
   前記通信相手に応じて前記第１鍵を変換し、第２鍵を生成する鍵変換手段と、をさらに具備し、
   前記認証手段は、前記第２識別子および前記第２鍵を用いて認証コードを生成することを特徴とする請求項１に記載の情報処理装置。
3. 前記第１鍵は、共通鍵暗号方式における鍵であり、
   前記鍵変換手段は、前記共通鍵暗号方式により前記第２鍵を生成し、
   前記通信手段は、前記第２鍵を用いて、前記共通鍵暗号方式により前記通信相手と暗号通信およびメッセージ認証することを特徴とする請求項２に記載の情報処理装置。
4. 前記第１鍵は、ＩＤベース暗号方式における秘密鍵であり、
   前記鍵変換手段は、前記ＩＤベース暗号方式により前記第２鍵を生成し、
   前記通信手段は、前記第２鍵を用いて、前記ＩＤベース暗号方式により前記通信相手と暗号通信およびメッセージ認証することを特徴とする請求項２に記載の情報処理装置。
5. 前記第２識別子格納手段は、任意の値である世代を含む付帯情報を前記通信相手の識別子と対応付けてさらに格納することを特徴とする請求項２から請求項４のいずれか１項に記載の情報処理装置。
6. 前記認証手段は、前記１以上の承認内容にデジタル署名および前記認証コードの少なくともどちらか１つが付される場合、該デジタル署名および該認証コードについて認証処理を行い、
   前記提示手段は、前記認証処理が成功した場合に、前記１以上の承認内容を前記ユーザに提示することを特徴とする請求項１から請求項５のいずれか１項に記載の情報処理装置。
7. 前記情報処理装置は、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）に含まれ、前記信頼ソフトウェアは、ＳＩＭ Ａｐｐｌｉｃａｔｉｏｎ Ｔｏｏｌｋｉｔ、ＧＳＭＡ Ｈａｎｄｓｅｔ ＡＰＩｓ ＆ Ｒｅｑｕｉｒｅｍｅｎｔｓに定義されたＡｃｃｅｓｓ Ｃｏｎｔｒｏｌで前記情報処理装置に認証されたアプリケーション、およびＧｌｏｂａｌＰｌａｔｆｏｒｍ Ｔｒｕｓｔｅｄ Ｅｘｅｃｕｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔに定義されたＴｒｕｓｔｅｄ Ａｐｐｌｉｃａｔｉｏｎのいずれか１つであることを特徴とする請求項１から請求項６のいずれか１項に記載の情報処理装置。
8. 製造および修正の少なくとも１つの権限がハードウェアによって直接または間接に特定の者に限定される信頼ソフトウェアの通信機能のみを介して、ユーザからの入力を必要とする１以上の承認内容を通信相手から受信し、
   前記信頼ソフトウェアの表示機能のみを介して前記１以上の承認内容をユーザに提示し、
   前記通信相手との認証に用いる鍵を格納手段に格納し、
   前記信頼ソフトウェアの入力機能のみを介して取得した前記ユーザからの指示に応じて、前記鍵を用いた認証コードを生成することを特徴とする認証方法。
9. コンピュータを、
   製造および修正の少なくとも１つの権限がハードウェアによって直接または間接に特定の者に限定される信頼ソフトウェアの通信機能のみを介して、ユーザからの入力を必要とする１以上の承認内容を通信相手から受信する通信手段と、
   前記信頼ソフトウェアの表示機能のみを介して前記１以上の承認内容をユーザに提示する提示手段と、
   前記通信相手との認証に用いる鍵を格納する格納手段と、
   前記信頼ソフトウェアの入力機能のみを介して取得した前記ユーザからの指示に応じて、前記鍵を用いた認証コードを生成する認証手段として機能させるための認証プログラム。