JP2017097659A - Ｉｃカード、データ保護方法、セキュリティ関連プログラム、及び通信システム - Google Patents

Abstract

【課題】多大な開発コストを要せずに、携帯端末装置のセキュリティの向上を図れるようにする。【解決手段】ＵＩＣＣ２０には、ＴＰＭアプレット４０が実装される。ＴＰＭアプレット４０は、携帯端末装置１０からのセキュリティに関連するコマンドを受信し、セキュリティに関連するコマンドに応じてセキュリティに関連する処理を実行し、セキュリティに関連する処理のレスポンスを携帯端末装置１０に返信する。【選択図】 図１

Description

本発明は、ＩＣカード、データ保護方法、セキュリティ関連プログラム、及び通信システムに関する。

近年、スマートフォンと称される携帯端末装置が急速に普及している。携帯端末装置にはメモリが搭載されており、このメモリには、様々なアプリケーション・プログラムの一時的な情報や恒久的に保存するべき情報が格納される。携帯端末装置では、それぞれのアプリケーション・プログラムは、サンドボックスと呼ばれる限定的なメモリ空間でのみ実行され、アプリケーション・プログラムがオペレーションシステム（ＯＳ；Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やハードウェア、他アプリケーション・プログラムに悪影響を与えないような仕組みが実装されている。

しかしながら、アプリケーション・プログラムをサンドボックスでのみ実行されるようにしたとしても、携帯端末装置の情報の流出は完全に防止できない。たとえば、アプリケーション・プログラムをインストールするときに、アプリケーション・プログラムがユーザにカメラ機能や位置情報送信機能のアクセス許可を求める場合がある。この場合、多くのユーザは、インストール手順の煩わしさから、アクセス許可に応じてしまう。ところが、アクセス許可に応じてしまうと、アプリケーション・プログラムはこれらの機能が使用できることになり、たとえばユーザの携帯端末で取得された位置情報が意思に反して送信されてしまい、ユーザのプライバシーが守られなくなるといった問題が生じてくる。

そこで、携帯端末装置にティー・ピー・エム（ＴＰＭ；Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ Ｍｏｄｕｌｅ）の機能を持たせることが考えられる。ＴＰＭは、主にパーソナルコンピュータ（ＰＣ；Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）のマザーボード等に搭載されるチップ（セキュアモジュール）であり、バイオス（ＢＩＯＳ；Ｂａｓｉｃ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）及びＯＳ等が不正な操作を受けていないかをチェックしたり、ＰＣに格納されたデータの暗号化を管理しアクセス可能なデバイスを制限したりすることができる（例えば特許文献１）。

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

しかしながら、ＴＰＭのチップを携帯端末装置に搭載するためには、そのための基板を新しく開発していかなければならない。また、ＴＰＭチップと携帯端末装置のソフトウェア（ＯＳ等）との間で通信するための機能、エー・ピー・アイ（ＡＰＩ；Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）、およびライブラリ等を新しく作らなければならず、多大な開発期間と開発コストとが必要となる。

上述の課題を鑑み、本発明は、多大な開発コストを要せずに、セキュリティの向上を図れるようにした、ＩＣカード、データ保護方法、セキュリティ関連プログラム、及び通信システムを提供することを目的とする。

上述の課題を解決するために、本発明の一態様に係るＩＣカードは、携帯端末装置で通信を行うための情報が収められたＩＣカードであって、前記携帯端末装置からのセキュリティに関連するコマンドを受信するコマンド受信部と、前記セキュリティに関連するコマンドに応じて、セキュリティに関連する処理を実行するセキュリティ機能実行部と、前記セキュリティに関連する処理のレスポンスを前記携帯端末装置に返信するレスポンス送信部と、を備えることを特徴とする。

本発明の一態様に係るデータ保護方法は、通信を行うための情報が収められたＩＣカードを装着して使用する携帯端末装置のデータ保護方法であって、前記携帯端末装置が前記ＩＣカードにセキュリティに関連するコマンドを送信する工程と、前記ＩＣカードが前記セキュリティに関連するコマンドに応じてセキュリティに関連する処理を実行する工程と、前記ＩＣカードが前記携帯端末装置に前記セキュリティに関連する処理のレスポンスを返信する工程と、を含むことを特徴とする。

本発明の一態様に係るセキュリティ関連プログラムは、携帯端末装置で通信を行うための情報が収められたＩＣカードに実装されるセキュリティ関連プログラムであって、前記携帯端末装置からのセキュリティに関連するコマンドを受信するステップと、前記セキュリティに関連するコマンドに応じてセキュリティに関連する処理を実行するステップと、前記セキュリティに関連する処理のレスポンスを前記携帯端末装置に返信するステップと、を含むことを特徴とする。

本発明の一態様に係る通信システムは、通信を行うための情報が収められたＩＣカードと、前記ＩＣカードを装着して処理を行う携帯端末装置とからなる通信システムであって、前記携帯端末装置は、前記ＩＣカードにセキュリティに関連するコマンドを送信するコマンド送信部と、前記ＩＣカードから返信されるレスポンスを受信するレスポンス受信部とを備え、前記ＩＣカードは、前記携帯端末装置からのセキュリティに関連するコマンドを受信するコマンド受信部と、前記セキュリティに関連するコマンドに応じて、セキュリティに関連する処理を実行するセキュリティ機能実行部と、前記セキュリティに関連する処理のレスポンスを前記携帯端末装置に返信するレスポンス送信部とを備えることを特徴とする。

本発明によれば、携帯端末装置で通信を行うための情報が収められたＩＣカードに、セキュリティに関連する処理の実行機能が収められる。これにより、携帯端末装置のセキュリティを向上させることができる。また、本発明によれば、ＴＰＭチップの開発が不要であり、また、携帯端末装置とＩＣカードとの通信には、既存のプロトコルを用いることができる。このため、開発コストを抑えることができる。

本発明の第１の実施形態に係る通信システムの概要の説明図である。 本発明の第１の実施形態における携帯端末装置の概要を示すブロック図である。 本発明の第１の実施形態におけるＵＩＣＣの構成を示すブロック図である。 アプレットの構造を示す説明図である。 ＵＩＣＣのＣＰＵの機能構造を示すブロック図である。 携帯端末装置からＵＩＣＣに送る通信コマンドの構造を示す説明図である。 ＵＩＣＣから携帯端末装置に返信する通信レスポンスの構造を示す説明図である。 「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストの説明図である。 「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストの説明図である。 本発明の第１の実施形態に係る通信システムにおける携帯端末装置とＵＩＣＣとの間のデータ通信のシーケンス図である。 本発明の第１の実施形態に係る通信システムにおけるＵＩＣＣ側でのＴＰＭアプレットのコマンド処理を示すフローチャートである。 本発明の第１の実施形態に係る通信システムにおける携帯端末装置側でのＴＰＭアプレットのコマンド処理を示すフローチャートである。

以下、本発明の実施の形態について図面を参照しながら説明する。図１は、本発明の第１の実施形態に係る通信システム１の概要を示すものである。

図１において、携帯端末装置１０は、スマートフォンと称される端末装置である。携帯端末装置１０には、各種のアプリケーション・プログラムをインストールすることができる。これらのアプリケーション・プログラムは、サンドボックスと称される限定的なメモリ空間でのみ実行されるようにして、セキュリティの向上が図られている。

携帯端末装置１０は、ＵＩＣＣ（ユー・アイ・シー・シー；Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）２０を装着して使用する。ＵＩＣＣ２０は、通信を行うための情報が収められたＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ；アイシー）カードであり、ＳＩＭカード（シムカード；Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ Ｃａｒｄ）とも称される。ＵＩＣＣ２０は、耐ダンパー性をもったセキュアなＩＣカードであり、外部からの悪意ある攻撃から情報を守る堅牢な構造を持っている。なお、ＵＩＣＣ２０は、クレジットカードサイズで提供されＩＣチップの部分だけ切り離して携帯端末装置１０に装着される場合もある。

本実施形態では、ＵＩＣＣ２０のアプリケーション・プログラムとして、ＴＰＭアプレット４０が搭載される。ＴＰＭは、ティー・シー・ジー（ＴＣＧ；Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐ）が定める高セキュリティーモジュールの総称であり、ＰＣ等に搭載されている。ＴＰＭアプレット４０は、セキュリティ関連の処理を実行する。すなわち、ＴＰＭアプレット４０は、機器の起動時に各部品やＯＳが偽造されているかどうかをチェックしたり、各機器がもつデータを安全に暗号化したりする機能をもつ。また、ＴＰＭアプレット４０は、暗号化機能に伴う鍵の発行機能をもつ。本実施形態では、ＵＩＣＣ２０のアプリケーション・プログラムで提供されるＴＰＭアプレット４０を用いることで、データの暗号化や復号化、デジタル署名の生成・検証、改竄の検知等を行うことができる。

図２は、携帯端末装置１０の概要を示すブロック図である。図２に示すように、携帯端末装置１０は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ；中央演算処理装置）１１、メインメモリ１２、補助メモリ１３、ディスプレイ１４、タッチスクリーン１５、無線通信部１６、カードリーダ／ライタ１７をハードウェアモジュールとして備える。これらのハードウェアモジュールは、バス１８により相互接続されている。

ＣＰＵ１１は、携帯端末装置１０の各種ハードウェアモジュールを制御する。ＣＰＵ１１は、補助メモリ１３に格納された各種プログラムをメインメモリ１２に読み出すとともに、メインメモリ１２に読み出した各種プログラムを実行することで、各種機能を実現する。

メインメモリ１２は、ＣＰＵ１１のワークエリアとして使用され、ＣＰＵ１１による処理に必要な各種データを記憶する。メインメモリ１２としては、例えばＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ ｒｅａｄ／ｗｒｉｔｅ Ｍｅｍｏｒｙ；読み書き可能なメモリ）などが用いられる。

補助メモリ１３は、携帯端末装置１０を動作させる各種プログラムを格納している。補助メモリ１３としては、例えば、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ；ハードディスクドライブ）やフラッシュメモリ等の不揮発メモリが用いられる。

ディスプレイ１４は、ＣＰＵ１１により制御され、ユーザに提示する画像情報を表示する。タッチスクリーン１５は、ディスプレイ１４に貼り付けられ、ユーザの指先やペン先などで接触された位置情報を入力する。ディスプレイ１４に各種のアイコンを表示し、タッチスクリーン１５をタップしたり、フリックしたりすることで、ジー・ユー・アイ（ＧＵＩ；Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）が提供できる。

無線通信部１６は、ＣＰＵ１１により制御され、３Ｇ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ；第３世代移動通信システム）、またはＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ；ロング・ターム・エボリューション）などによる通信機能を提供する。

カードリーダ／ライタ１７は、ＵＩＣＣ２０の読み出し／書き込みを行う。本実施形態では、携帯端末装置１０とＵＩＣＣ２０との間のデータの転送には、既存の通信プロトコル（ＩＳＯ７８１６−３）が用いられる。この通信プロトコルについては、後に説明する。カードリーダ／ライタ１７は、ＩＳＯ７８１６−３に準拠したコマンド送信部と、レスポンス受信部として機能する。

図３は、ＵＩＣＣ２０の構成を示すブロック図である。図３に示すように、ＵＩＣＣ２０は、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、不揮発性メモリ２４と、通信部２５とを備える。

ＣＰＵ２１は、ＵＩＣＣ２０のデータの処理の制御を行う。ＲＯＭ２２は、基本となる各種プログラムを格納する。ＲＡＭ２３は、ＣＰＵ２１のワークエリアとして使用される。不揮発性メモリ２４は、ＵＩＣＣの動作制御に必要な各種のプログラムやデータを記憶する。通信部２５は、携帯端末装置１０側のカードリーダ／ライタ１７と通信を行う。通信部２５は、ＩＳＯ７８１６−３に準拠したコマンド受信部と、レスポンス送信部として機能する。

ＵＩＣＣ２０は、ＪａｖａＣａｒｄ（登録商標）アプレットをサポートしている。図４は、ＪａｖａＣａｒｄ（登録商標）アプレットの構造を示すものである。図４に示すように、ＶＭ（Ｖｉｒｔｕａｌ Ｍａｃｈｉｎｅ；仮想機械）制御部５１により仮想マシンが構築される。そして、ＶＭ制御部５１上に、アプレット制御部５２が設けられ、アプレット制御部５２により、アプレット５３が実行される。暗号機能５５及びメモリ制御５６は、ＶＭ制御部５１により管理される。

図５は、ＣＰＵ２１の機能構造を示すものである。図５に示すように、ＣＰＵ２１は、通信制御部６１と、メモリ制御部６２と、ＶＭ制御部６３と、アプレット制御部６４とからなる。通信制御部６１は、通信部２５によるデータ通信の制御を行う。メモリ制御部６２は、ＲＯＭ２２、ＲＡＭ２３、不揮発性メモリ２４によるデータの読み出し／書き込みの制御を行う。ＶＭ制御部６３は、仮想マシンの制御を行う。アプレット制御部６４は、ＶＭ制御部６３上で実行されるＪａｖａＣａｒｄ（登録商標）アプレットの制御を行う。

次に、本発明の第１の実施形態でのＴＰＭ機能について説明する。前述したように、本実施形態では、ＴＰＭアプレット４０を、ＵＩＣＣ２０のアプリケーション・プログラムとして搭載している。このＴＰＭアプレット４０は、上述のＪａｖａＣａｒｄ（登録商標）によるアプレットとして実現できる。

また、携帯端末装置１０とＵＩＣＣ２０との間のデータの転送には、既存の通信プロトコル（ＩＳＯ７８１６−３）が用いられる。この通信プロトコルは、クレジットカードやＵＩＣＣに代表されるＩＣカードの規格を定めた国際標準規格であり、ＡＰＤＵ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ；アプリケーション・プロトコル・データ・ユニット）と呼ばれるコマンド群により、ＩＣカードとデータ通信を行うことを定めている。また、この通信プロトコルでは、エラーの処理方法等も規定されている。

本実施形態では、図６及び図７に示すように、携帯端末装置１０とＵＩＣＣ２０との間のデータの転送に、既存の通信のプロトコル（ＩＳＯ７８１６−３）のＡＰＤＵコマンド及びＡＰＤＵレスポンスが用いられる。そして、このＡＰＤＵコマンド及びＡＰＤＵレスポンスのデータ中に、ＴＰＭアプレットのためのコマンドやリターンコードを組み込んでいる。

図６は、携帯端末装置１０からＵＩＣＣ２０に送る通信コマンドの構造を示すものである。この通信コマンドは、ＩＣカードの通信プロトコル（ＩＳＯ７８１６−３）のＡＰＤＵコマンドに基づいている。図６に示すように、ＡＰＤＵコマンドは、「ＣＬＡ」、「ＩＮＳ」、「Ｐ１」、「Ｐ２」、「Ｌｃ」、「ＤＡＴＡ」、「Ｌｅ」からなる。「ＣＬＡ」は、命令クラスである。「ＩＮＳ」は、命令コードである。「Ｐ１」及び「Ｐ２」は、命令パラメータである。「Ｌｃ」は、コマンドのデータフィールドに含まれるバイト数である。「ＤＡＴＡ」は、コマンドで送信されるデータバイト列である。「Ｌｅ」は、レスポンスのデータフィールドに含まれる予定の最大バイト数である。

また、ＡＰＤＵコマンドの「ＤＡＴＡ」中には、ＴＰＭのコマンドが組み込まれる。ＴＰＭコマンドは、「ＴＡＧ」、「ＰａｒａｍＳｉｚｅ」、「Ｏｒｄｉｎａｌ」、「Ｄａｔａ」からなる。「ＴＡＧ」は、識別用のタグである。「ＰａｒａｍＳｉｚｅ」は、全バイト数である。「Ｏｒｄｉｎａｌ」は、コマンドである。「Ｄａｔａ」はデータバイト列である。このＴＰＭコマンドは、ＴＰＭ Ｍａｉｎ ｐａｒｔ３に基づいている。

図７は、ＵＩＣＣ２０から携帯端末装置１０に返信する通信レスポンスの構造を示すものである。この通信レスポンスは、ＩＣカードの通信プロトコル（ＩＳＯ７８１６−３）のＡＰＤＵレスポンスに基づいている。図７に示すように、ＡＰＤＵレスポンスは、「ＤＡＴＡ」、「ＳＷ」からなる。「ＤＡＴＡ」は、ＡＰＤＵレスポンスで受信されるデータバイト列である。「ＳＷ」は、コマンド処理の状態を示すステータスワードである。コマンドが正常に終了した場合、「ＳＷ」の値として「０ｘ９０００」が返される。それ以外のレスポンスは、エラーまたはウォーニングが発生したことを示している。

また、ＡＰＤＵレスポンスの「ＤＡＴＡ」中には、ＴＰＭレスポンスが組み込まれる。ＴＰＭレスポンスは、「ＴＡＧ」、「ＰａｒａｍＳｉｚｅ」、「ＲｅｔｕｒｎＣｏｄｅ」、「Ｄａｔａ」からなる。「ＴＡＧ」は、識別用のタグである。「ＰａｒａｍＳｉｚｅ」は、全バイト数である。「ＲｅｔｕｒｎＣｏｄｅ」は、オペレーションのリターンコードである。「Ｄａｔａ」はデータバイト列である。ＴＰＭレスポンスは、ＴＰＭ Ｍａｉｎ ｐａｒｔ３に基づいている。

本実施形態では、図６に示したように、ＡＰＤＵコマンドの「ＤＡＴＡ」中に、ＴＰＭのコマンドを組み込むようにしている。また、図７に示したように、ＡＰＤＵレスポンスの「ＤＡＴＡ」中に、ＴＰＭレスポンスを組み込むようにしている。

また、本実施形態では、図８に示すようなＡＰＤＵコマンドの「ＩＮＳ」とＴＰＭコマンドの「Ｏｒｄｉｎａｌ」との紐付けリスト（コマンド対応リスト）や、図９に示すようなＴＰＭレスポンスの「ＲｅｔｕｒｎＣｏｄｅ」とＡＰＤＵレスポンスの「ＳＷ」との紐付けリスト（レスポンス対応リスト）が用いられる。これらの紐付けリストは、携帯端末装置１０の補助メモリ１３及びＵＩＣＣ２０の不揮発性メモリ２４に記憶されている。これらの紐付けリストを用いることで、正規のＴＰＭコマンドやＴＰＭリターンコードであるかどうかを判定できる。

図８は、「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストを示すものである。この「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストでは、ＡＰＤＵコマンド（ＩＳＯ７８１６−３）での「ＩＮＳ」値の意味と、ＴＰＭコマンド（ＴＰＭ Ｍａｉｎ ｐａｒｔ３）での「Ｏｒｄｉｎａｌ」値の意味とが等しくなるような組み合わせが行われている。但し、「ＩＮＳ＝Ａ４」は、アプレットの選択で使用するため、使用不可とされている。ＵＩＣＣ２０は、ＡＰＤＵコマンドを受信すると、受信したＡＰＤＵコマンドの中から「ＩＮＳ」の値と「Ｏｒｄｉｎａｌ」の値を抽出する。ＵＩＣＣ２０は、「ＩＮＳ」の値と「Ｏｒｄｉｎａｌ」の値が図８に示す「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストに適合するかどうかを判定する。そして、「ＩＮＳ」の値と「Ｏｒｄｉｎａｌ」の値が「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストに適合する場合のみ、ＴＰＭコマンドの実行を行う。

図９は、「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストを示すものである。この「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストでは、ＡＰＤＵレスポンス（ＩＳＯ７８１６−３）での「ＳＷ」の値の意味と、ＴＰＭリターンコード（ＴＰＭ Ｍａｉｎ ｐａｒｔ３）での「ＲｅｔｕｒｎＣｏｄｅ」の値の意味とが等しくなるような組み合わせが行われている。携帯端末装置１０は、ＡＰＤＵレスポンスを受信すると、受信したＡＰＤＵレスポンスの中から「ＳＷ」の値と「ＲｅｔｕｒｎＣｏｄｅ」の値を抽出し、「ＳＷ」の値と「ＲｅｔｕｒｎＣｏｄｅ」の値が図９に示す「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストに適合するかどうかを判定する。そして、「ＳＷ」の値と「ＲｅｔｕｒｎＣｏｄｅ」の値が「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストに適合する場合のみ、正規のレスポンスとして処理する。

次に、本発明の第１の実施形態に係る通信システムの動作について、図１０のシーケンス図を参照しながら説明する。

図１０は、本発明の第１の実施形態に係る通信システムにおける携帯端末装置１０とＵＩＣＣ２０との間のデータ通信のシーケンス図である。同図において、アプリケーション・プログラム３０の実行処理は、携帯端末装置１０にインストールされているソフトウェアにより行われる。携帯端末装置１０の実行処理は、携帯端末装置１０の各種の機能により実行される。ＴＰＭアプレット４０の実行処理は、ＵＩＣＣ２０に実装されたＴＰＭアプレットにより行われる。ＵＩＣＣ２０の実行処理は、ＵＩＣＣ２０の各種の機能により行われる。

図１０において、携帯端末装置１０のＧＵＩによりアプリケーション・プログラム３０が選択されると（ステップＳ１）、携帯端末装置１０は、アプリケーション・プログラム３０の起動処理を行い（ステップＳ２）、ＵＩＣＣ２０にアクセス要求を行う（ステップＳ３）。

ＵＩＣＣ２０は、携帯端末装置１０からアクセス要求を受信すると、携帯端末装置１０にアクセス許可のレスポンスを返信する（ステップＳ４）。

携帯端末装置１０は、「ＴＰＭアプレット」を選択ファイルとしてＡＰＤＵコマンドを生成し、このＡＰＤＵコマンドをＵＩＣＣ２０に送信する（ステップＳ５）。

ＵＩＣＣ２０は、「ＴＰＭアプレット」を選択ファイルとするＡＰＤＵコマンドを受信すると、ＴＰＭアプレット４０があるかどうかをチェックし（ステップＳ６）、ＴＰＭアプレット４０があれば、ＴＰＭアプレット４０を選択する（ステップＳ７）。

そして、ＵＩＣＣ２０は正常終了レスポンスを携帯端末装置１０のアプリケーション・プログラム３０に返信する（ステップＳ８）。

携帯端末装置１０のアプリケーション・プログラム３０で、ＴＰＭコマンドが選択されると（ステップＳ９）、アプリケーション・プログラム３０は、選択されたＴＰＭコマンドに対応するＴＰＭコマンドとＡＰＤＵコマンドを「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストから取得する（ステップＳ１０）。

そして、アプリケーション・プログラム３０は、「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストから取得したＴＰＭコマンドとＡＰＤＵコマンドに基づいて、「ＩＮＳ」の値をＡＰＤＵコマンドの「ＩＮＳ」にセットし、ＡＰＤＵコマンドを生成する（ステップＳ１１）。

そして、アプリケーション・プログラム３０は、ＡＰＤＵコマンドのＤａｔａ領域にＴＰＭコマンドを組み込み（ステップＳ１２）、携帯端末装置１０はこのＡＰＤＵコマンドをＵＩＣＣ２０に送信する（ステップＳ１３）。

ＵＩＣＣ２０は、携帯端末装置１０からＡＰＤＵコマンドを受信すると、このＡＰＤＵコマンドが通信プロトコルに合致しているかをチェックし（ステップＳ１４）、通信プロトコルに合致していれば、このＡＰＤＵコマンドをＴＰＭアプレット４０に転送する（ステップＳ１５）。

ＴＰＭアプレット４０は、ＡＰＤＵコマンドから「ＩＮＳ」の値と「Ｏｒｄｉｎａｌ」の値とを抽出し、「ＩＮＳ」の値で示されるＡＰＤＵコマンドと、「Ｏｒｄｉｎａｌ」の値で示されるＴＰＭコマンドとが「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストに合致するかを確認する（ステップＳ１６）。

ＴＰＭアプレット４０は、「ＩＮＳ」の値と「Ｏｒｄｉｎａｌ」の値とが「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストに合致していれば、ＴＰＭコマンド処理を実行する（ステップＳ１７）。

ＴＰＭアプレット４０は、ＴＰＭ処理の実行結果に応じて、「ＲｅｔｕｒｎＣｏｄｅ」を生成し、「ＲｅｔｕｒｎＣｏｄｅ」と一致するＡＰＤＵレスポンスの「ＳＷ」を「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストから取得する（ステップＳ１８）。

そして、ＴＰＭアプレット４０は、ＡＰＤＵレスポンスのＤａｔａ領域にＴＰＭレスポンスを組み込み（ステップＳ１９）、「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストから取得した「ＳＷ」の値をＡＰＤＵレスポンスの「ＳＷ」に組み込み（ステップＳ２０）、ＡＰＤＵレスポンスを生成する。

ＵＩＣＣ２０は、このＡＰＤＵレスポンスを携帯端末装置１０のアプリケーション・プログラム３０に送信する（ステップＳ２１）。

携帯端末装置１０のアプリケーション・プログラム３０は、ＵＩＣＣ２０からのＡＰＤＵレスポンスを受信すると、このＡＰＤＵレスポンスからＴＰＭレスポンスを抽出する（ステップＳ２２）。

そして、アプリケーション・プログラム３０は、受信したＡＰＤＵレスポンスの中から「ＳＷ」の値と「ＲｅｔｕｒｎＣｏｄｅ」の値を抽出し、ＡＰＤＵレスポンスの「ＳＷ」の値とＴＰＭレスポンスの「ＲｅｔｕｒｎＣｏｄｅ」の値が「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストに適合するかどうかを確認し（ステップＳ２３）、「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストに適合する場合のみ、正規のレスポンスとして処理する。

図１１は、ＵＩＣＣ２０側でのＴＰＭアプレットのコマンド処理を示すフローチャートである。

ＵＩＣＣ２０のＣＰＵ２１は、「Ｓｅｌｅｃｔ Ｆｉｌｅ」のＡＰＤＵコマンドを受信すると（ステップＳ１０１）、選択ファイルとして指定されている「ＴＰＭアプレット」が選択可能かどうかを判定する（ステップＳ１０２）。

ステップＳ１０２で、「ＴＰＭアプレット」が選択可能でなければ（ステップＳ１０２：Ｎｏ）、ＣＰＵ２１は、ファイルが選択できないことを示す「ＳＷ」の値をセットし（ステップＳ１０５）、ＡＰＤＵレスポンスを送信して（ステップＳ１０６）、処理を終了する。

ステップＳ１０２で、「ＴＰＭアプレット」が選択可能なら（ステップＳ１０２：Ｙｅｓ）、ＣＰＵ２１は、ＴＰＭアプレットを選択し（ステップＳ１０５）、「ＳＷ＝０ｘ９０００」のレスポンスを返信する（ステップＳ１０６）。ここで、「ＳＷ＝０ｘ９０００」は、正常終了を意味している。

ＵＩＣＣ２０のＣＰＵ２１は、ＡＰＤＵコマンドの受信を待機しており（ステップＳ１０７）、ＡＰＤＵコマンドの受信を確認すると（ステップＳ１０８）、このＡＰＤＵコマンドが通信プロトコルに従ったクラスであるかどうかのＣＬＡチェックを行い（ステップＳ１０９）、ＣＬＡチェックが正常に終了したかどうかを判定する（ステップＳ１１０）。

ステップＳ１１０で、ＣＬＡチェックが正常に終了していなければ（ステップＳ１１０：Ｎｏ）、ＣＰＵ２１は、ＣＬＡチェックが正常に終了しないことを示す「ＳＷ」の値をＡＰＤＵレスポンスにセットし（ステップＳ１０３）、ＡＰＤＵレスポンスを送信して（ステップＳ１０４）、処理を終了する。

ステップＳ１１０で、ＣＬＡチェックが正常に終了していれば（ステップＳ１１０：Ｙｅｓ）、ＣＰＵ２１は、ＡＰＤＵコマンドの「ＩＮＳ」の値が「Ｓｅｌｅｃｔ Ｆｉｌｅ」以外かどうかを判定する（ステップＳ１１１）。

ステップＳ１１１で、「ＩＮＳ」の値が「Ｓｅｌｅｃｔ Ｆｉｌｅ」の場合には（ステップＳ１１１：Ｎｏ）、ＣＰＵ２１は、ＴＰＭエラーをＴＰＭレスポンスの「ＲｅｔｕｒｎＣｏｄｅ」に設定して、ＡＰＤＵレスポンスの「ＤＡＴＡ」にセットする（ステップＳ１１２）。

そして、ＣＰＵ２１は、「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストを参照して（ステップＳ１１３）、ＴＰＭエラーに対応するステータスワードをＡＰＤＵレスポンスの「ＳＷ」の値にセットし（ステップＳ１１４）、ＡＰＤＵレスポンスを送信する（ステップＳ１１５）。

ステップＳ１１１で、「ＩＮＳ」の値が「Ｓｅｌｅｃｔ Ｆｉｌｅ」以外の場合には（ステップＳ１１１：Ｙｅｓ）、ＣＰＵ２１は、ＡＰＤＵコマンドの「ＤＡＴＡ」中の「ＴＡＧ」値がＴＰＭコマンドのものかを判定する（ステップＳ１１６）。

ＡＰＤＵコマンドの「ＤＡＴＡ」中の「ＴＡＧ」値がＴＰＭコマンドのものでない場合には（ステップＳ１１６：Ｎｏ）、ＣＰＵ２１は、ステップＳ１１２からステップＳ１１５の処理を行い、エラーに対応する「ＲｅｔｕｒｎＣｏｄｅ」と「ＳＷ」とを設定したＡＰＤＵレスポンスを送信する。

ステップＳ１１６で、ＡＰＤＵコマンドの「ＤＡＴＡ」中の「ＴＡＧ」値がＴＰＭコマンドのものである場合には、（ステップＳ１１６：Ｙｅｓ）、ＣＰＵ２１は、「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストを参照し（ステップＳ１１７）、ＡＰＤＵコマンドの「ＩＮＳ」とＴＰＭコマンドの「Ｏｒｄｉｎａｌ」との組み合わせが「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストに合致しているかどうかを判定する（ステップＳ１１８）。

ステップＳ１１８で、ＡＰＤＵコマンドの「ＩＮＳ」とＴＰＭコマンドの「Ｏｒｄｉｎａｌ」との組み合わせが「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストに合致していない場合には（ステップＳ１１８：Ｎｏ）、ＣＰＵ２１は、ステップＳ１１２からステップＳ１１５の処理を行い、エラーに対応する「ＲｅｔｕｒｎＣｏｄｅ」と「ＳＷ」とを設定したＡＰＤＵレスポンスを送信する。

ステップＳ１１８で、ＡＰＤＵコマンドの「ＩＮＳ」とＴＰＭコマンドの「Ｏｒｄｉｎａｌ」との組み合わせが「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストに合致している場合には（ステップＳ１１８：Ｙｅｓ）、ＣＰＵ２１は、「ＴＡＧ」と「Ｏｒｄｉｎａｌ」との組み合わせを参照し（ステップＳ１１９）、「ＴＡＧ」と「Ｏｒｄｉｎａｌ」との組み合わせと処理が正しいかどうかを判定する（ステップＳ１２０）。

ステップＳ１２０で、「ＴＡＧ」と「Ｏｒｄｉｎａｌ」との組み合わせと処理が正しくない場合には（ステップＳ１２０：Ｎｏ）、ＣＰＵ２１は、ステップＳ１１２からステップＳ１１５の処理を行い、エラーに対応する「ＲｅｔｕｒｎＣｏｄｅ」と「ＳＷ」とを設定したＡＰＤＵレスポンスを送信する。

ステップＳ１２０で、「ＴＡＧ」と「Ｏｒｄｉｎａｌ」との組み合わせと処理が正しい場合には（ステップＳ１２０：Ｙｅｓ）、ＣＰＵ２１は、ＴＰＭコマンドの「Ｏｒｄｉｎａｌ」に相当するセキュリティに関連する処理を実行する（ステップＳ１２１）。

そして、ＣＰＵ２１は、ＴＰＭコマンドの各パラメータが正しいかをチェックし（ステプＳ１２２）、「Ｏｒｄｉｎａｌ」の処理結果は正しいかをチェックする（ステップＳ１２３）。

ステップＳ１２２でＴＰＭコマンドのパラメータが正しくない場合には（ステップＳ１２２：Ｎｏ）、ＣＰＵ２１は、ステップＳ１１２からステップＳ１１５の処理を行い、エラーに対応する「ＲｅｔｕｒｎＣｏｄｅ」と「ＳＷ」とを設定したＡＰＤＵレスポンスを送信する。

同様に、ステップＳ１２３で「Ｏｒｄｉｎａｌ」の処理結果は正しくない場合には（ステップＳ１２３：Ｎｏ）、ＣＰＵ２１は、ステップＳ１１２からステップＳ１１５の処理を行い、エラーに対応する「ＲｅｔｕｒｎＣｏｄｅ」と「ＳＷ」とを設定したＡＰＤＵレスポンスを送信する。

ステップＳ１２２でＴＰＭコマンドのパラメータが正しく設定されており（ステップＳ１２２：Ｙｅｓ）、ステップＳ１２３で「Ｏｒｄｉｎａｌ」の処理結果は正しい場合には（ステップＳ１２３：Ｙｅｓ）、ＣＰＵ２１は、正常終了の「ＲｅｔｕｒｎＣｏｄｅ」をＴＰＭレスポンスに設定して、ＡＰＤＵレスポンスの「ＤＡＴＡ」にセットする（ステップＳ１２４）。

そして、ＣＰＵ２１は、ＡＰＤＵレスポンスの「ＳＷ」を「ＳＷ＝０ｘ９０００」にセットし（ステップＳ１２５）、このＡＰＤＵレスポンスを送信する（ステップＳ１１５）。

図１２は、携帯端末装置１０側でのＴＰＭアプレットのコマンド処理を示すフローチャートである。

図１２において、アプリケーション・プログラムが起動されると（ステップＳ２０１）、ＵＩＣＣ２０との通信が開始される（ステップＳ２０２）。

ＣＰＵ１１は、ＡＰＤＵコマンドの「ＩＮＳ」に、「Ｓｅｌｅｃｔ Ｆｉｌｅ」を示す値を組み込み、選択ファイルとして「ＴＰＭアプレット」を指定する（ステップＳ２０３）。

そして、ＣＰＵ１１は、このＡＰＤＵコマンドを送信する（ステップＳ２０４）。

スマートフォンのＣＰＵ１１は、ＵＩＣＣ２０からのＡＰＤＵレスポンスの受信を待ち（ステップＳ２０５）、ＡＰＤＵレスポンスの受信を確認すると（ステップＳ２０６）、このＡＰＤＵレスポンスの「ＳＷ」が「ＳＷ＝０ｘ９０００」であるかどうかを判定する（ステップＳ２０７）。

「ＳＷ」が「ＳＷ＝０ｘ９０００」であれば（ステップＳ２０７：Ｙｅｓ）、ＣＰＵ１１は、ＴＰＭ機能を選択する（ステップＳ２０８）。

ＡＰＤＵレスポンスの「ＳＷ」が「ＳＷ＝０ｘ９０００」以外であれば（ステップＳ２０７：Ｎｏ）、処理は終了される。

使用するＴＰＭ機能が指定されると（ステップＳ２０８）、ＣＰＵ１１は、「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストを参照し（ステップＳ２０９）、「ＩＮＳ」と「Ｏｒｄｉｎａｌ」との紐付けリストから、ＴＰＭ機能に対応するＡＰＤＵコマンドの「ＩＮＳ」とＴＰＭコマンドの「Ｏｒｄｉｎａｌ」の値をバッファにセットする（ステップＳ２１０）。

ＣＰＵ１１は、ＴＰＭコマンドの「Ｏｒｄｉｎａｌ」に沿って、「ＴＡＧ」、「ＰａｒａｍＳｉｚｅ」、「Ｄａｔａ」をバッファにセットし（ステップＳ２１１）、パラメータ「Ｐ１」及び「Ｐ２」をバッファにセットする（ステップＳ２１２）。

そして、ＣＰＵ１１は、「ＤＡＴＡ」領域に設定する長さをＡＰＤＵコマンドの「Ｌｃ」の値として設定し（ステップＳ２１３）、このＡＰＤＵコマンドを送信する（ステップＳ２１４）。

スマートフォンのＣＰＵ１１は、ＡＰＤＵレスポンスの受信を待機し（ステップＳ２１５）、ＡＰＤＵレスポンスの受信を確認すると（ステップＳ２１６）、このＡＰＤＵレスポンスの末尾の「ＳＷ」が「ＳＷ＝０ｘ９０００」であるかどうかを判定する（ステップＳ２１７）。

ステップＳ２１７で、ＡＰＤＵレスポンスの「ＳＷ」が「ＳＷ＝０ｘ９０００」であれば（ステップＳ２１７：Ｙｅｓ）、ＣＰＵ１１は、ＡＰＤＵレスポンスの「ＤＡＴＡ」領域にあるＴＰＭレスポンスをバッファに格納する（ステップＳ２１８）。

そして、ＣＰＵ１１は、ＴＰＭレスポンスの「ＲｅｔｕｒｎＣｏｄｅ」の値によって、アプリケーション・プログラムの処理を選択し（ステップＳ２１９）、アプリケーション・プログラムの処理を実行する（ステップＳ２２０）。

そして、ＣＰＵ１１は、アプリケーション・プログラムの処理の完了を確認し（ステップＳ２２１）、ＡＰＤＵコマンドの送信が必要であるかどうかを判定する（ステップＳ２２２）。

ＡＰＤＵコマンドの送信が必要なら（ステップＳ２２２：Ｙｅｓ）、ステップＳ２１４に行き、ＡＰＤＵコマンドを送信する。

ＡＰＤＵコマンドの送信が必要でなければ（ステップＳ２２２：Ｎｏ）、ＣＰＵ１１は、処理をステップＳ２０８に移し、使用するＴＰＭ機能の選択を待機する。

ステップＳ２１７で、ＡＰＤＵレスポンスの「ＳＷ」ドが「ＳＷ＝０ｘ９０００」以外であれば（ステップＳ２１７：Ｎｏ）、ＣＰＵ１１は、実行エラーを表示する（ステップＳ２２３）。

そして、ＣＰＵ１１は、「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストを参照して（ステップＳ２２４）、受信したＡＰＤＵレスポンスの「ＳＷ」の値が「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストに存在するかどうかを判定する（ステップＳ２２５）。

ステップＳ２２５で、受信したＡＰＤＵレスポンスの「ＳＷ」の値が「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストになければ（ステップＳ２２５：Ｎｏ）、ＣＰＵ１１は異常終了として処理し（ステップＳ２２６）、ステップＳ２０８に行き、使用するＴＰＭ機能の選択を待機する。

ステップＳ２２５で、受信したＡＰＤＵレスポンスの「ＳＷ」の値が「ＳＷ」と「ＲｅｔｕｒｎＣｏｄｅ」との紐付けリストに存在する場合には（ステップＳ２２５：Ｙｅｓ）、ＣＰＵ１１は、「ＳＷ」の値と「ＲｅｔｕｒｎＣｏｄｅ」の値は再処理を必要とするかどうかを判定する（ステップＳ２２７）。

ステップＳ２２７で、再処理が必要でない場合には（ステップＳ２２７：Ｎｏ）、ＣＰＵ１１は、処理をステップＳ２０８に進め、使用するＴＰＭ機能の選択を待機する。

ステップＳ２２７で、再処理が必要な場合には（ステップＳ２２７：Ｙｅｓ）、ステップＳ２１８からステップＳ２２０の処理を行い、再処理を実行する。

以上説明したように、本発明の実施形態では、ＵＩＣＣ２０のアプリケーション・プログラムとして、ＴＰＭの機能が搭載される。ＵＩＣＣ２０は、携帯端末装置１０で標準搭載されるＩＣチップであり、耐タンパー性をもっている。このため、ＵＩＣＣ２０のアプリケーション・プログラムにＴＰＭ機能を搭載することで、携帯端末装置１０のセキュリティを向上させることができる。

また、本発明の実施形態では、携帯端末装置１０とＵＩＣＣ２０との間のデータの転送に、既存の通信のプロトコル（ＩＳＯ７８１６−３）のＡＰＤＵコマンド及びＡＰＤＵレスポンスを用い、このＡＰＤＵコマンド及びＡＰＤＵレスポンスのデータ中に、ＴＰＭアプレットのためのコマンドやリターンコードを組み込んでいる。このため、ＴＰＭチップと携帯端末装置のソフトウェアとの間で通信するための機能を新たに開発する必要がない。したがって、ＴＰＭ機能を新たに実装するために必要な、基板設計や通信プロトコルの実装などのハードウェア、ソフトウェア両面での開発コストの発生を抑えることが可能である。

また、ＵＩＣＣの規格はＩＳＯ７８１６に定められており、同時期の機種ごとでは同一のものが搭載されている。そのため、ある機種で利用していたＴＰＭ機能を実装したＵＩＣＣを別機種に移すことで、鍵の移行が容易になる。これにより、以前の機種で暗号化していた機密文書を、別機種でも読み取ることが可能である。

なお、通信システム１の全部または一部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより各部の処理を行ってもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。
また、「コンピュータシステム」は、ＷＷＷシステムを利用している場合であれば、ホームページ提供環境（あるいは表示環境）も含むものとする。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含むものとする。また上記プログラムは、前述した機能の一部を実現するためのものであっても良く、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであっても良い。

以上、本発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。

１：通信システム
１０：携帯端末装置
１１：ＣＰＵ
２０：ＵＩＣＣ
２１：ＣＰＵ
３０：アプリケーション・プログラム
４０：ＴＰＭアプレット

Claims (9)

1. 携帯端末装置で通信を行うための情報が収められたＩＣカードであって、
   前記携帯端末装置からのセキュリティに関連するコマンドを受信するコマンド受信部と、
   前記セキュリティに関連するコマンドに応じて、セキュリティに関連する処理を実行するセキュリティ機能実行部と、
   前記セキュリティに関連する処理のレスポンスを前記携帯端末装置に返信するレスポンス送信部と、
   を備えることを特徴とするＩＣカード。
2. 前記セキュリティに関連するコマンドは、前記携帯端末装置から前記ＩＣカードへの通信コマンドの情報中に組み込まれる
   ことを特徴とする請求項１に記載のＩＣカード。
3. 更に、前記セキュリティに関連するコマンドと前記通信コマンドとの対応を示すコマンド対応リストを記憶する記憶部を備え、
   前記セキュリティ機能実行部は、前記コマンド対応リストに基づいて前記情報中に組み込まれた前記セキュリティに関連するコマンドを実行する
   ことを特徴とする請求項２に記載のＩＣカード。
4. 前記セキュリティに関連する処理のレスポンスは、前記ＩＣカードから前記携帯端末装置への通信レスポンスの情報中に組み込まれることを特徴とする請求項１に記載のＩＣカード。
5. 更に、前記セキュリティに関連する処理のレスポンスと前記通信レスポンスとの対応を示すレスポンス対応リストを記憶する記憶部を備え、
   前記レスポンス送信部は、前記レスポンス対応リストに基づいて前記情報中に組み込まれた前記セキュリティに関連する処理のレスポンスを返信する
   ことを特徴とする請求項４に記載のＩＣカード。
6. 前記携帯端末装置と前記ＩＣカードとの間の通信は、ＩＳＯ７８１６に準拠していることを特徴とする請求項１乃至５の何れかに記載のＩＣカード。
7. 通信を行うための情報が収められたＩＣカードを装着して使用する携帯端末装置のデータ保護方法であって、
   前記携帯端末装置が前記ＩＣカードにセキュリティに関連するコマンドを送信する工程と、
   前記ＩＣカードが前記セキュリティに関連するコマンドに応じてセキュリティに関連する処理を実行する工程と、
   前記ＩＣカードが前記携帯端末装置に前記セキュリティに関連する処理のレスポンスを返信する工程と、
   を含むことを特徴とするデータ保護方法。
8. 携帯端末装置で通信を行うための情報が収められたＩＣカードに実装されるセキュリティ関連プログラムであって、
   前記携帯端末装置からのセキュリティに関連するコマンドを受信するステップと、
   前記セキュリティに関連するコマンドに応じてセキュリティに関連する処理を実行するステップと、
   前記セキュリティに関連する処理のレスポンスを前記携帯端末装置に返信するステップと、
   を含むコンピュータにより実行可能なセキュリティ関連プログラム。
9. 通信を行うための情報が収められたＩＣカードと、前記ＩＣカードを装着して処理を行う携帯端末装置とからなる通信システムであって、
   前記携帯端末装置は、前記ＩＣカードにセキュリティに関連するコマンドを送信するコマンド送信部と、前記ＩＣカードから返信されるレスポンスを受信するレスポンス受信部とを備え、
   前記ＩＣカードは、前記携帯端末装置からのセキュリティに関連するコマンドを受信するコマンド受信部と、前記セキュリティに関連するコマンドに応じて、セキュリティに関連する処理を実行するセキュリティ機能実行部と、前記セキュリティに関連する処理のレスポンスを前記携帯端末装置に返信するレスポンス送信部とを備える
   ことを特徴とする通信システム。

Images