JP4251667B2 - アプリケーション履歴リストを有する集積回路カード - Google Patents

Description

発明の背景
集積回路（ＩＣ）カードは、主に、配布された安全な情報処理を低価格で提供するために理想的なツールであるため、今日の世界において多くの異なる目的のために、ますます多く用いられつつある。ＩＣカードは「スマートカード」とも呼ばれ、典型的には従来のクレジットカードのサイズのカードであるが、カード上にコンピュータチップを含む。ＩＣカード上のコンピュータチップは典型的には、マイクロプロセッサと、読出し専用メモリ（ＲＯＭ）と、電気消去可能プログラマブル読出し専用メモリ（ＥＥＰＲＯＭ）と、ランダムアクセスメモリ（ＲＡＭ）と、入／出力（Ｉ／Ｏ）メカニズムと、動作中のマイクロプロセッサをサポートする他の回路とを含む。コンピュータチップは、カードに格納された１以上のアプリケーションを実行し得る。格納し実行するためにＩＣカードが用いられているアプリケーションの例は、クレジット／デビット、電子マネー／パース、電話コーリングカード、および得意客報酬アプリケーションを含む。
アプリケーションが最初にＩＣカードにロードされるとき、アプリケーションは、アプリケーションに関連するデータを含み得る。このようなデータは、例えば、カード保持者の氏名および口座番号などの、カード保持者を識別するデータを含み得る。さらに、上記関連するデータは、アプリケーションをロードしたことに対してアプリケーションプロバイダによりカード保持者に提供されるプロモーショナルまたはボーナスバリューをも含み得る。例えば、電話コーリングカードのアプリケーションの場合、アプリケーションプロバイダは、ある長さの無料通話時間を提供し得る。別の例として、電子パースのアプリケーションの場合、アプリケーションプロバイダは、ボーナス電子キャッシュを提供し得る。さらに別の例として、フリークエントフライヤー得意客アプリケーションの場合、アプリケーションプロバイダは、フリーマイル数を提供し得る。プロモーショナルまたはボーナスバリューを提供するためにアプリケーションデータを用いることは、アプリケーションをロードする際の完全性に関して、ＩＣカード製造者およびアプリケーションプロバイダに潜在的な問題を引き起こす。最初にアプリケーションがロードされるときに、カード保持者が意図的にまたは非意図的にアプリケーションをコピーしてその後アプリケーションに関連するデータ値を再ロードするためにアプリケーションを再ロードすることを防止するために、解決法が必要である。アプリケーションの反復する再ロードにより、カード保持者は、資格のないはずの無制限の量のプロモーショナルまたはボーナスバリューを入手し得る可能性がある。しかし同時に、カード保持者は、アプリケーションを更新するなどの合法的理由によりアプリケーションを再ロードする必要があり得る。
従って、アプリケーションが一旦ＩＣカードにロードされるとカード保持者がアプリケーションを不法に再ロードすることを妨げるように、ＩＣカードにアプリケーションをロードする方法が必要である。
上記の技術的チャレンジおよび必要性に、技術的解決法を提供する本発明におよる実施形態によって取り組まれる。
発明の要旨
本発明の好適な実施形態によると、アプリケーションコピーを集積回路カード回路にロードする方法であって、アプリケーションコピーがアプリケーションの複数のコピーのうちの１つである方法が提供される。アプリケーションコピーは、アプリケーションを他のアプリケーションから識別する関連するアプリケーション識別子と、アプリケーションの各コピー毎に独自であるアプリケーションコピー番号とを有する。集積回路カードは、マイクロプロセッサとマイクロプロセッサに連結されたメモリとを含む。メモリは、集積回路カードに以前にロードされているアプリケーションのアプリケーション識別子とアプリケーションコピー番号とを格納するアプリケーション履歴リスト領域を含む。上記方法は、アプリケーションコピー、アプリケーション識別子、およびアプリケーションコピー番号を集積回路カードによって受け取る工程と、アプリケーション識別子とアプリケーションコピー番号とがアプリケーション履歴リスト領域に含まれているか否かを集積回路カードによって決定する工程と、アプリケーション識別子およびアプリケーションコピー番号がアプリケーション履歴リスト領域に含まれている場合は、集積回路カードによるアプリケーションコピーのロードが失敗する工程とを含む。
本明細書および添付の請求の範囲において、アプリケーションコピー番号に関して用いられる用語「独自」は、２つのタイプの番号、すなわち（１）実際に独自であると決定された非ランダム番号、および（２）あるカード保持者にとって蓋然的に独自であると決定されたランダム番号との両方を意味する。
本発明の好適な実施形態による方法は、メモリの所定の部分をアプリケーション履歴リスト領域に割り当てる工程と、アプリケーション履歴リスト領域がフルであるか否かを集積回路カードによって決定する工程と、アプリケーション履歴リストがフルである場合に、アプリケーションコピーをロードすることに失敗する工程とをさらに含む。
本発明の好適な実施形態による方法は、アプリケーション識別子およびアプリケーションコピー番号がアプリケーション履歴リスト領域に含まれない場合に、アプリケーション識別子とアプリケーションコピー番号とをアプリケーション履歴リスト領域に追加する工程をさらに含む。従って、アプリケーションが一旦集積回路カードにロードされると、アプリケーションのコピーに関連するアプリケーション識別子とアプリケーションコピー番号とが、将来の照合のためにアプリケーション履歴リスト領域に格納される。
本発明の好適な実施形態による方法は、繰り返されるアプリケーションのロードに関心のないアプリケーションプロバイダが、アプリケーション履歴リスト領域内でのアプリケーション識別子およびアプリケーションコピー番号の格納を回避し得るメカニズムをも提供し得る。例えば、ゼロというアプリケーションコピー番号は、アプリケーションが望まれるだけ何度でも再ロードされ得ることを示すために用いられ得る。従って、本発明の好適な実施形態の方法は、アプリケーション識別子およびアプリケーションコピー番号がアプリケーション履歴領域に含まれず且つアプリケーションコピー番号がゼロでない場合に、アプリケーション識別子およびアプリケーションコピー番号をアプリケーション履歴リスト領域に追加する工程をさらに含み得る。
アプリケーションコピーは、アプリケーションコードおよびアプリケーションデータの両方を含み得る。アプリケーション識別子およびアプリケーションコピー番号はアプリケーションデータ内に含まれ得る。
好適には、アプリケーションコピー、アプリケーション識別子、およびアプリケーションコピー番号は、アプリケーションプロバイダによって集積回路カードに送信される。好適には、アプリケーションプロバイダは、アプリケーションコピーを集積回路カードに送信する前に、アプリケーションコピーの少なくとも一部分を暗号化する。アプリケーションプロバイダが、アプリケーションコピーの暗号化された部分の暗号化に関する情報を含む鍵トランスフォーメーションユニットを送信することもまた好適である。集積回路カードが第１の公開鍵対を有し、アプリケーションプロバイダが、集積回路カードに鍵トランスフォーメーションユニットを送信する前に、第１の公開鍵対の公開鍵で鍵トランスフォーメーションユニットを暗号化することがさらに好適である。
アプリケーションプロバイダが第１の公開鍵対の公開鍵で鍵トランスフォーメーションユニットを暗号化すると、集積回路カードは、暗号化された鍵トランスフォーメーションユニットを第１の公開鍵対の秘密鍵で解読し得る。鍵トランスフォーメーションユニットが一旦解読されると、集積回路カードは、解読された鍵トランスフォーメーションユニット内に含まれる情報を用いて、アプリケーションコピーを解読し得る。
アプリケーションプロバイダが第２の公開鍵対を有し、アプリケーションプロバイダが、第２の公開鍵対の秘密鍵でアプリケーションコピーを暗号化することにより、署名されたアプリケーションコピーを生成することもまた好適である。アプリケーションプロバイダはその後、アプリケーションコピーと署名されたアプリケーションコピーとの両方を集積回路カードに送信し得る。
アプリケーションプロバイダが、第２の公開鍵対の公開鍵を、第３の公開鍵対を有する証明機関に登録することがさらに好適である。証明機関はその後、第２の公開鍵対の公開鍵を、第３の公開鍵対の秘密鍵で暗号化することにより、アプリケーションプロバイダに証明書を提供し得る。アプリケーションプロバイダは、証明書を集積回路カードに送信し得る。
証明書が集積回路カードに送信されると、集積回路カードは、第３の公開鍵対の公開鍵を用いて証明書を解読することにより、第２の鍵対の公開鍵を入手し得る。集積回路カードはその後、第２の公開鍵対の公開鍵を用いて、署名されたアプリケーションコピーを確認し得る。署名されたアプリケーションコピーが確認されない場合、集積回路カードは、アプリケーションコピーのロードに失敗し得る。
本発明の別の実施形態によると、マイクロプロセッサおよびマイクロプロセッサに連結されたメモリを含む集積回路カードが提供される。メモリは、アプリケーション識別子とアプリケーションコピー番号とを格納するアプリケーション履歴リスト領域を含む。各アプリケーション識別子と各アプリケーションコピー番号とは、アプリケーションコピーに関連する。アプリケーションコピーは、アプリケーションの複数のコピーの１つである。各アプリケーション識別子は、アプリケーションを他のアプリケーションから独自に識別し、各アプリケーションコピー番号は、アプリケーションコピーを他のアプリケーションコピーから独自に識別する。本発明の集積回路カードは、メモリ領域にロードされるべきアプリケーションコピーに関連するアプリケーション識別子およびアプリケーションコピー番号がアプリケーション履歴リスト内に含まれているか否かを決定する手段と、上記関連するアプリケーション識別子および上記関連するアプリケーションコピー番号がアプリケーション履歴リスト領域に含まれている場合に、上記ロードされるべきアプリケーションコピーのロードに失敗する手段とをさらに含む。
図面の簡単な説明
本発明による実施形態を、添付の図面を参照しながら実施例としてのみ説明する。
図１は、本発明の好適な実施形態によるＩＣカードの模式的表示である。
図２は、本発明の好適な実施形態によるＩＣカードおよびターミナルの斜視図である。
図３は、本発明の好適な実施形態によるＩＣカードの機能的ブロック図である。
図４は、本発明の好適な実施形態によるＩＣカードに、アプリケーションプロバイダにより遠隔的にアプリケーションをロードするシステムの図である。
図５は、本発明の好適な実施形態によるアプリケーションロードユニットの模式的表示である。
図６は、本発明の好適な実施形態による図５のアプリケーションロードユニットを処理する例示的ステップのフローチャートである。
図７は、本発明の好適な実施形態によるＩＣカードの動作システムにより実行され得るファイルローディングルーチンの例示的ステップを示すフローチャートである。
発明の詳細な説明
図１は、本出願の請求の範囲に記載の発明に用いられ得る典型的ＩＣカード１０の模式的表現を提供する。ＩＣカード１０は、１以上の電気コンタクト１４が接続された集積回路１２を含む。
図２は、ＩＣカード１０が通信するデバイスの例を示す。本明細書および添付の請求の範囲において、用語「インターフェースデバイス」および「ターミナル」は、ＩＣカードが通信し得るデバイスを包括的に説明するために用いられる。図２に示すように、典型的ターミナル２０は、カードリーダ２２、キーパッド２４、およびディスプレイ２６を含む。キーパッド２４およびディスプレイ２６は、ＩＣカード１０のユーザがターミナルとインタラクトすることを可能にする。キーパッド２４は、ユーザが、トランザクションを選択すること、暗証番号（「ＰＩＮ」）を入力すること、およびトランザクション情報を入力することを可能にする。ディスプレイ２６は、ユーザが、情報メッセージおよびデータエントリ用のプロンプトを受け取ることを可能にする。他のタイプのターミナルは、ＩＣカードと互換性のあるＡＴＭ機および電話を含み得る。
図３は、集積回路１２の機能的ブロック図である。集積回路１２は、少なくとも、プロセシングユニット１００およびメモリユニット１１０を含む。好適には、集積回路１２はさらに、制御ロジック１５０、タイマ１６０、セキュリティ回路１７０、入／出力ポート１８０、およびコプロセッサ１９０を含む。制御ロジック１５０は、プロセシングユニット１００と共に、メモリユニット１１０と入／出力ポート１８０との間の通信を処理するために必要な制御を提供する。タイマ１６０は、プロセシングユニット１００および制御ロジック１５０のためのタイミング基準信号を提供する。セキュリティ回路１７０は好適には、製造中のテストのために、入／出力ポート１８０を内部回路に接続する可溶性リンクを提供する。可溶性リンクは、テストの完了後焼けて、敏感な回路領域への後のアクセスを制限する。コプロセッサ１９０は、暗号作成アルゴリズムにより必要とされるような、複雑な演算をリアルタイムに行う能力を提供する。
メモリユニット１１０は、揮発性および不揮発性メモリ並びに読出し専用およびプログラマブルメモリなどの異なるタイプのメモリを含み得る。例えば、図３に示すように、メモリユニット１１０は、読出し専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読出し専用メモリ（ＥＥＰＲＯＭ）、およびランダムアクセスメモリ（ＲＡＭ）を含み得る。
メモリユニット１１０は、秘密暗号作成鍵およびユーザＰＩＮなどのＩＣカードデータを格納する。秘密暗号作成鍵は、公開鍵対のプライベート鍵などの、任意のタイプの周知の暗号作成鍵であり得る。好適には、秘密暗号作成鍵は、ＩＣカードの外部からアクセス不可能であるかまたは非常に限定されたアクセス可能性を有するＲＯＭまたはＥＥＰＲＯＭの安全な領域に格納される。
メモリユニット１１０はさらに、ＩＣカードの動作システムを格納する。動作システムは、ＩＣカードアプリケーションをロードし実行し、ＩＣカードアプリケーションに対するファイル管理および他の基本的なカードサービスを提供する。好適には、動作システムはＲＯＭに格納される。
動作システムによって提供される基本的サービスに加えて、メモリユニット１１０はさらに、１以上のＩＣカードアプリケーションを含み得る。例えば、ＩＣカードが電子キャッシュカードとして用いられる場合、ＭＯＮＤＥＸ^TM ＰＵＲＳＥ（Ｍｏｎｄｅｘ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｌｉｍｉｔｅｄ提供）と呼ばれるアプリケーションがＩＣカードに含まれ得る。上記アプリケーションは、金融機関におけるユーザの口座からのある通貨の電子値をＩＣカードにロードする。好適には、ＩＣカード１０の動作システムは、Ｍｏｎｄｅｘ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｌｉｍｉｔｅｄ提供のＭＵＬＴＯＳ^TM動作システムなどの複数のアプリケーションをサポートすべきである。
ＩＣカードアプリケーションは、プログラムおよび関連するデータファイルの両方を含み得る。これらは典型的には、ＥＥＰＲＯＭに格納される。アプリケーションプログラムは、プロセシングユニット１００のネイティブプログラミングコードで書かれていてもよいし、より高いレベルの言語で書かれていてもよい。より高いレベルの言語は、プロセシングユニット１００で実行される前に翻訳されなければならない。ＩＣカードで用いられる、このようなより高いレベルの言語の例は、ＭＵＬＴＯＳ^TM Ｅｘｅｃｕｔａｂｌｅ Ｌａｎｇｕａｇｅ（ＭＥＬ）である。都合のよいことに、ＭＥＬなどのより高いレベルの言語を用いることにより、アプリケーションプログラムは、再書込みの必要なく、複数のハードウェアプラットフォーム上で実行することができる。
ＩＣカードは典型的には、ＩＣカード上にメモリを搭載することによるサイズおよび価格上の制限により限定されたメモリ容量を有し得るため、ＩＣカードはさらに、ＲＯＭ内に格納されたプリミティブを有し得る。プリミティブは、数学的機能などの、頻繁に用いられる機能または手順を行うサブルーチンである。プリミティブは通常、プロセシングユニット１００のネイティブ言語で書かれており、その結果、非常に迅速に実行され得る。
図４に、アプリケーションプロバイダ４０１からＩＣカード４０３にアプリケーションを遠隔的にロードするシステムの図を示す。アプリケーションプロバイダ４０１は、カード発行元、銀行、またはアプリケーションローディングサービスを提供する他のエンティティであり得る。ＩＣカード４０３は、インターフェースデバイス４０５を介してアプリケーションプロバイダ４０１と通信される。インターフェースデバイス４０５は、銀行のターミナル、ＡＴＭ、またはＩＣカードと通信する他のデバイスであり得る。アプリケーションプロバイダ４０１およびインターフェースデバイス４０５は、データ線４０７により通信する。データ線４０７は、電話線、ケーブル線、衛星リンク、インターネット接続、イントラネット接続、または他の任意のタイプの通信リンクであり得る。
ＩＣカードを遠隔的にロードする際、アプリケーションプロバイダは、いくつかの安全性に関する事項に取り組むことが必要である。第１に、アプリケーションプロバイダは、アプリケーションがアプリケーションを受け取ることを意図されているカード保持者のみに送信されることを確認しなければならない。第２に、アプリケーションプロバイダは、ロードされるべきアプリケーション内に含まれる機密またはトレードシークレット情報の秘密性を確認しなければならない。第３に、データ線４０７はオープンリンクであり、送信中のアプリケーションを遮断または置換する可能性のある第三者に曝され得るため、アプリケーションプロバイダは、ＩＣカードがアプリケーションを認証することを可能にする安全上の手段を取らなければならない。
これらの安全上の問題に対する解決策は典型的には、対称的および／または非対称的暗号作成技術を用いた暗号化を含む。対称的暗号作成は、「鍵」と呼ばれる同一の数字を用いてデータを符号化および復号化することを含む。鍵は秘密に保持されなければならない。他方、「公開鍵」暗号作成とも呼ばれる非対称的暗号作成は、１つの鍵でデータを符号化し別の鍵でデータを復号化することを含む。２つの鍵は、鍵対と呼ばれ、鍵対の一方は秘密に保持されなければならないが、鍵対の他方は公的に配布され得る。鍵対の各鍵は、データを符号化するために用いられるが、データが一方の鍵を用いて一旦符号化されると、他方の鍵を用いてしか復号化され得ない。
図４のシステムにおいて、アプリケーションプロバイダ４０１およびＩＣカード４０３が各々、暗号作成鍵対を有すると仮定する。暗号作成鍵の作成は、当業者によって知られた任意の様式で行われる。システムはさらに、証明機関（ＣＡ）４０９を利用する。ＣＡ４０９もまた暗号作成鍵対を有する。ＣＡ４０９は、公開鍵対の秘密鍵をプライベート保持し、且つ、例えばアプリケーションプロバイダ４０１の識別などの他のエンティティの識別を認証すると信用されている任意のエンティティであり得る。
図４のシステムにおいて、アプリケーションプロバイダ４０１は、ＣＡ４０９で公開鍵の登録を申請する。これを行うためには、アプリケーションプロバイダ４０１は、ＣＡ４０９の識別要件を満たさなければならない。アプリケーションプロバイダ４０１がこれらの識別要件を満たす場合、ＣＡ４０９は、アプリケーションロード証明書（ＡＬＣ）４１３を発行する。ＡＬＣ４１３は、ＣＡ４０９の秘密鍵によって符号化された、すなわち「署名された」アプリケーションプロバイダ４０１の公開鍵を含む。ＡＬＣ４１３は、ＣＡ４０９の公開鍵を用いて復号化され得る。ＣＡ４０９は公的に配布される。ＣＡ４０９は、秘密鍵をプライベートに保持し且つアプリケーションプロバイダ４０１の識別を認証すると信用されているため、ＡＬＣ４１３を受け取るいずれのエンティティも、証明書に含まれる公開鍵がアプリケーションプロバイダ４０１に属することを保証される。
アプリケーションをＩＣカード４０３にロードするために、アプリケーションプロバイダ４０１は、アプリケーションロードユニット（ＡＬＵ）４１１をデータ線４０７を介してインターフェースデバイス４０５に送信する。ＡＬＵ４１１のコンテンツを模式的に図５に示す。ＡＬＵは好適には、アプリケーションユニット（ＡＵ）４１５、署名されたアプリケーションユニット（ＡＵ_S）４１７、鍵トランスフォーメーションユニット（ＫＴＵ）４１９、およびＡＬＣ４１３を含む。
ＡＵ４１５は、ＩＣカードに格納されるべきアプリケーションコードおよびデータを含む。アプリケーションコードおよびデータの機密またはトレードシークレット部分を保護するために、アプリケーションコードおよびデータの一部またはすべてが暗号化され得る。
ＡＵ_S４１７は、ＡＵ４１５がアプリケーションプロバイダ４０１の秘密鍵で署名したアプリケーションコードおよびデータである。ＩＣカード４０３は、ＡＬＣ４１３で提供されたアプリケーションプロバイダ４０１の公開鍵を用いて、ＡＵ_S４１７を復号化し、ＡＵ４１５が送信中に変更されていないことを確認するために、ＡＵ４１５と比較する。
ＫＴＵ４１９は、ＡＵ４１５の暗号化された部分に関連する情報を含む。この情報は、ＩＣカード４０３がこれらの暗号化された部分を復号化して、アプリケーションコードおよびデータがＩＣカード４０３によってアクセスされ得るようになることを可能にする。ＫＴＵ４１９はＩＣカード４０３の公開鍵で署名される。このことは、意図されたＩＣカード４０３のみがＫＴＵ４１９を復号化し得る（ＩＣカードの秘密鍵を用いて）ことを保証する。ＫＴＵ４１９が一旦復号化されると、ＩＣカード４０３はＫＴＵ４１９に含まれる情報を用いて、ＡＵ４１５のアプリケーションコードおよびデータの暗号化された部分を復号化し得る。
図６は、ＩＣカード４０３によって受け取られたＡＬＵ４１１を処理するステップのフローチャートを示す。ステップ６０１において、ＩＣカード４０３は、アプリケーションプロバイダ４０１からのＡＬＵ４１１を受け取る。ＡＬＵ４１１は、ＡＵ４１５、ＡＵ_S４１７、ＫＴＵ４１９およびＡＬＣ４１３のメモリ内の位置を示すヘッダ情報と共にＩＣカード４０３のＥＥＰＲＯＭ内に入れられる。
ステップ６０３において、ＡＬＣ４１３は、ＣＡ４０９の公開鍵を用いて復号化される。ＩＣカード４０３は、好適には、ＣＡ公開鍵のコピーをメモリ内に格納する。なぜなら、ＣＡ公開鍵は多くのトランザクションにおいて用いられ得るからである。あるいは、ＩＣカードは、インターフェースデバイス４０５などの信用された格納位置から公開鍵を入手し得る。一旦復号化されると、ＡＬＣ４１３は、ＩＣカード４０３に、アプリケーションプロバイダ４０１の公開鍵の信用されたコピーを提供する。
ステップ６０５において、ＩＣカード４０３は、アプリケーションプロバイダの公開鍵を用いて、ＡＵ４１５が送信中に変更されなかったことを確認する。ＩＣカード４０３は、アプリケーションプロバイダ４０１の公開鍵を用いて、アプリケーションプロバイダ４０１の秘密鍵で署名されたＡＵ_S４１７を復号化する。ＡＵ_S４１７が一旦復号化されると、復号化されたＡＵ_S４１７がＡＵ４１５と比較される。２つのユニットが合致すると、ＡＵ４１５は確認される。
ステップ６０７において、ＩＣカード４０３の公開鍵で暗号化されているＫＴＵ４１９は、ＩＣカード４０３のプライベート鍵を用いて復号化される。ステップ６０９において、復号化されたＫＴＵ４９１内の情報はＡＵ４１５の暗号化された部分を復号化するために用いられる。ＫＴＵ４１９は、例えば、ＡＵ４１５を復号化する際に用いられるアルゴリズムまたは鍵のいずれかを含み得る。
上述したセキュリティおよび認証手段に加えて、他の安全性に関する手段および認証手段もまた採用され得る。セキュリティおよび認証の更なる方法は、例えば、１９９８年２月１９日に出願されたＥｖｅｒｅｔｔらの”Ｍｕｌｔｉ−Ａｐｐｌｉｃａｔｉｏｎ ＩＣ Ｃａｒｄ Ｓｙｓｔｅｍ”という名称の関連する国際特許出願ＰＣＴ／ＧＢ９８／００５３１、および１９９８年５月１１日に出願されたＲｉｃｈａｒｄｓらの”Ｋｅｙ Ｔｒａｎｓｆｏｒｍａｔｉｏｎ Ｕｎｉｔ ｆｏｒ ａｎ ＩＣ Ｃａｒｄ”という名称の米国出願において取り組まれている。これらの出願は両方とも、それぞれ添付のアネックスＡおよびアネックスＢ、並びにアネックスＣとして、ここに参考のため援用される。
本発明の好適な実施形態によると、ＡＵ４１５のデータ部分は、ＩＣカード４０３にロードされるべきアプリケーション用のアプリケーション識別子とアプリケーションコピー番号とを含む。アプリケーションコピー番号は、ＩＣカード４０３にロードされるべきアプリケーションの各コピー毎に独自である。本明細書および添付の請求の範囲において、アプリケーションコピー番号に関して用いられる用語「独自」は、実際に独自であると決定された非ランダム番号と、あるＩＣカードにとって蓋然的に独自であると決定されたランダム番号との両方を意味する。好適には、アプリケーション識別子およびアプリケーションコピー番号を含むＡＵ４１５のデータ部分が符号化される（そして、ＫＴＵ４１９は、このデータ部分を復号化するために必要な情報を含む）。
図７は、ＡＵ４１５内に含まれるアプリケーション識別子とアプリケーションコピー番号とを利用して、カード保持者が同一のアプリケーションをＩＣカード４０３に繰り返しロードすることを妨げるために、ＩＣカード４０３の動作システムによって実行され得る、ファイルローディングルーチンのステップを示すフローチャートである。図７の実施形態において、アプリケーションコピー番号は、「ランダムシード」とも呼ばれるランダム番号である。ステップ７０１において、ファイルローディングルーチンは、動作システムのセキュリティマネジャつまりＯＳ＿Ｓｅｃｕｒｉｔｙ＿Ｍａｎａｇｅｒから、ファイルローディングコマンドｌｏａｄ＿ｆｉｌｅ＿ｃｏｍｍａｎｄを受け取る。動作システムのＯＳ＿Ｓｅｃｕｒｉｔｙ＿Ｍａｎａｇｅｒは、図６を参照して述べたように、ＡＬＵ４１１のベリフィケーションと復号化を行う。
ステップ７０３において、アプリケーションに関連するアプリケーション識別子およびランダムシードは、それぞれ、ｌｏａｄ＿ｆｉｌｅ＿ｃｏｍｍａｎｄ．ａｐｐｌｉｃａｔｉｏｎ＿ｉｄおよびｌｏａｄ＿ｆｉｌｅ＿ｃｏｍｍａｎｄ．ｒａｎｄｏｍ＿ｓｅｅｄと呼ばれ、ｏｓ＿ｇｌｏｂａｌ＿ｄａｔａ．ａｐｐ＿ｈｉｓｏｔｏｒｙ＿ｌｉｓｔと呼ばれる、ＩＣカードに格納されたアプリケーション履歴リスト内のエントリと照合される。アプリケーション履歴リストは、ＩＣカード４０３にロードされたアプリケーションに関連するアプリケーション識別子およびランダムシードの各セット用のエントリを含む。アプリケーション履歴リストは、ＩＣカードの外部からはアクセス不可能であるＥＥＰＲＯＭの安全な領域に格納されることが好適である。
ロードされるべきアプリケーションに関連するアプリケーション識別子およびランダムシードがアプリケーション履歴リスト内に見い出された場合、ステップ７０５において、応答ステータスｌｏａｄ＿ｆｉｌｅ＿ｒｅｓｐｏｎｓｅ．ｓｔａｔｕｓが「失敗」に設定され、エラー記述ｌｏａｄ＿ｆｉｌｅ＿ｒｅｓｐｏｎｓｅ．ｅｒｒｏｒ＿ｃａｕｓｅが「以前にロードされたアプリケーション」に設定される。エラー応答ｌｏａｄ＿ｆｉｌｅ＿ｒｅｓｐｏｎｓｅは、ＯＳ＿Ｓｅｃｕｒｉｔｙ＿Ｍａｎａｇｅｒに戻り、アプリケーションが以前にＩＣカードにロードされているためにロードファイルルーチンがアプリケーションのロードに失敗したことを示す。
ロードされるべきアプリケーションに関連するアプリケーション識別子およびランダムシードがアプリケーション履歴リスト内に見い出されない場合、ステップ７０７において、ランダムシードが照合されてランダムシードがゼロに等しいか否かが決定され、アプリケーション履歴リストが照合されてアプリケーション履歴リストがフルであるか否かが決定される。ゼロの値を有するランダムシードは、アプリケーションがデータ中に含まれる経済的値を含まないことを示し、そのため、望まれるだけ何度でも再ロードされ得る。アプリケーションに関連するランダムシードがゼロでなく（アプリケーションに含まれる経済的値があることを示す）アプリケーション履歴リストがフルである場合、応答ステータスｌｏａｄ＿ｆｉｌｅ＿ｒｅｓｐｏｎｓｅ．ｓｔａｔｕｓは「失敗」に設定され、エラー記述ｌｏａｄ＿ｆｉｌｅ＿ｒｅｓｐｏｎｓｅ．ｅｒｒｏｒ＿ｃａｕｓｅは「アプリケーション履歴フル」に設定される。この場合、アプリケーション履歴リストはフルであるため、アプリケーションはロードされ得ず、従って、アプリケーション識別子およびランダムシードは将来の照合のためにアプリケーション履歴リストに追加され得ない。
ステップ７０３または７０７においてエラー状態がトリガされた場合、ステップ７１１において、アプリケーションに関連するディレクトリファイル記録がＩＣカードのディレクトリファイルに追加される。すなわち、アプリケーションがＩＣカード４０３にロードされる。ステップ７１３において、ランダムシードがゼロに等しいか否かが照合される。ランダムシードがゼロに等しくない場合（アプリケーションに含まれる経済的値があることを示す）、アプリケーション識別子およびランダムシードは、ＩＣカードにロードされることが求められている次のアプリケーションとの照合のために、アプリケーション履歴リストに追加される。アプリケーション履歴リストを更新した後、応答ステータスｌｏａｄ＿ｆｉｌｅ＿ｒｅｓｐｏｎｓｅ．ｓｔａｔｕｓは「成功」に設定されて、ＯＳ＿Ｓｅｃｕｒｉｔｙ＿Ｍａｎａｇｅｒに送信される。
ランダムシードがゼロに等しい場合（アプリケーションに含まれる経済的値がないことを示す）、アプリケーション識別子およびランダムシードは、アプリケーション履歴リストに追加されない。代わりに、ステップ７１７がスキップされ、応答ステータスｌｏａｄ＿ｆｉｌｅ＿ｒｅｓｐｏｎｓｅ．ｓｔａｔｕｓが「成功」に設定されてＯＳ＿Ｓｅｃｕｒｉｔｙ＿Ｍａｎａｇｅｒに送信される。
都合のよいことに、図７のファイルローディングルーチンは、カード保持者がアプリケーションを不法に再ロードすることを防止する。カード保持者がＩＣカードにロードされるべきアプリケーションを遮断およびコピーしても、カード保持者は後にアプリケーションを再ロードし得ない。なぜなら、一旦アプリケーションがロードされると、アプリケーション識別子およびランダムシードはＩＣカードに永久的に格納されるからである。カード保持者がアプリケーションを再ロードしようとしても、ＩＣカードの動作システムがアプリケーションの再ロードに失敗する。なぜなら、アプリケーションのアプリケーション識別子およびランダムシードがＩＣカードのアプリケーション履歴リストのエントリに合致するからである。
他方、カード保持者がアプリケーションプロバイダからのアプリケーションを合法的に再ロードすることは妨げられない。アプリケーションプロバイダは提供するアプリケーションの各コピーに対して新しいランダムシードを生成するため、カード保持者がアプリケーションプロバイダから同一のランダムシードを有するアプリケーションの第２のコピーを受け取るとは考えられない。もちろん、アプリケーションプロバイダは、カード保持者が同一のランダムシードを２度受け取る可能性が十分低いことを確実にするために、十分な長さのランダムシードを用いなければならない。
あるいは、アプリケーションプロバイダは、ランダム番号を用いる代わりに、各カード保持者に提供するアプリケーションのコピーに関連する独自の番号を持ち得る。例えば、アプリケーションプロバイダは、提供したアプリケーションのコピー数を記録するカウンタを保持し得る。アプリケーションプロバイダは、カウンタの値を用いて、カード保持者にアプリケーションのコピーを提供する度に独自の番号を提供し得る。しかし、ランダムシードの実施形態の方が好適である。なぜなら、より管理し易いからである（すなわち、格納または管理することが必要な情報がないからである）。
本発明をあるいくつかの好適な実施形態に照らして述べてきたが、添付の請求の範囲に規定される、本発明の思想および範囲から逸脱することなく、様々な改変、変更および置換が当業者に知られているかまたは明らかである。
本開示の範囲は、請求の範囲に記載されているか否かまたは本発明によって解決しようとしている問題点のいずれかまたは全てを軽減するか否かにかかわらず、本明細書に明示的または暗示的に開示されたすべての新しい特徴または特徴の組み合わせ、およびそれらを一般化したものをすべて含む。本出願は、本出願および本出願から派生する更なる出願の審査中に、このような新しい特徴に関する新しい請求項が作成され得ることを告知する。特に、添付の請求の範囲を参照すると、従属項の特徴が、独立項の特徴と、請求の範囲に挙げられた特定の組み合わせのみならず任意の適切な様式で組み合わせられ得る。
アネックスＣ
ICカード配送鍵セット
集積回路（「ＩＣ」）カードは、今日世界中で、多くの異なる目的のためにますます多く使用されている。ＩＣカード（スマートカードとも呼ばれる）は、典型的に、従来のクレジットカードの大きさであり、コンピュータチップを有している。このコンピュータチップには、マイクロプロセッサ、リードオンリーメモリ（ＲＯＭ）、電気的消去可能プログラム可能リードオンリーメモリ（ＥＥＰＲＯＭ）、入力／出力（Ｉ／Ｏ）メカニズム、および、動作中にマイクロプロセッサをサポートするその他の回路が含まれている。ＩＣカードは、そのメモリ内に、単一のアプリケーションを有していてもよいし、あるいは、複数の独立したアプリケーションを有していてもよい。ＭＵＬＴＯＳ^TMは、他のプラットフォームの中でもとりわけＩＣカード上で動作し、そのカード上で複数のアプリケーションの実行を可能にするマルチアプリケーションオペレーティングシステムである。これにより、カードユーザは、そのカードを使用するために挿入した端末（即ち、ＡＴＭ、電話および／またはＰＯＳ）の種類に関わらず、そのカードに保存された多数のプログラム（例えば、クレジット／デビット、電子マネー／財布、および／またはロイヤリティアプリケーション）を実行することができるようになる。
テレフォンカードおよび電子キャッシュカードのような従来の単一アプリケーションＩＣカードは、カードユーザに与えられる前に、その製造の時点で、単一のアプリケーションを付与される。しかし、たとえカードユーザまたはカード発行者がアプリケーションの改変を望んだとしても、カード発行後にアプリケーションを改変または変更することはできない。さらに、あるカードユーザが、そのユーザに対して発行されたＩＣカードに、様々なアプリケーション機能、例えば、電子財布およびクレジット／デビット機能の両方を果たして欲しい場合、カードユーザは複数の物理的カードを持ち運ばなければならない。これは、非常に煩雑で不便である。アプリケーション開発者（application developer）またはカードユーザが、２つの異なるアプリケーション間での相互作用またはデータ交換、例えば、財布機能がフリークエントフライヤーロイヤリティアプリケーションと相互作用することを望んだ場合、カードユーザは、カードを入れる端末に複数のカードを代わる代わる出し入れしなければならず、処理が、困難で、時間がかかり、不便なものになる。
従って、同じＩＣカード上に複数アプリケーションを保存することは有益である。例えば、カードユーザは、同じカード上に財布アプリケーションおよびクレジット／デビットアプリケーションの両方を有し、買物を行うときにどちらの種類の支払い（電子キャッシュまたはクリジットカード）を使用するのかを選択し得る。十分なメモリが存在し、且つ、複数のアプリケーションをサポートできるオペレーティングシステムがカード上にあれば、１枚のＩＣカードに複数のアプリケーションを付与することができる。複数のアプリケーションを予め選択して、それらを製造段階でカードのメモリ内に入れておくことも可能であるが、必要に応じて、製造後に、そのカードのアプリケーションをロードおよび削除できるようにすることも有益であろう。
１枚のカード上に複数のアプリケーションを保存する向上した柔軟性および性能は、個々のカードとアプリケーション提供者との間で交換され、また、アプリケーションをロードおよび削除する際に全システム内で交換される情報（アプリケーションコードおよび関連するデータを含む）の完全性および安全性に関して克服すべき新たな課題を生み出す。カード、カード発行者、システムオペレータおよびアプリケーション提供者間で安全にデータを交換できる能力、ならびに、ローカル端末から、または、電話線、インターネット、イントラネット接続、もしくはその他のデータ経路上で遠隔的に、何時でも安全にアプリケーションをロードおよび削除できる能力をＩＣカードシステム内に持つことは有益であろう。典型的にこれらのデータ送信線は安全な線ではないので、これらの送信線上で送られるアプリケーションが改竄されることなく意図したカード上にのみロードされることを確実にするためには、複数のセキュリティおよびエンティティ認証技術を確立しなければならない。
特に、カード所有者が利用できる新たなアプリケーションが増え続けている状況では、上記のように、発行後にＩＣカード上にアプリケーションを追加する能力をシステムに持たせることが重要である。このことは、ＩＣカードの寿命の長さを守るために必要である。さもなくば、アプリケーションが古くなったときに、そのカードが無用になってしまう。遠隔位置から、および、アプリケーション提供者の端末からの直接接続によって、アプリケーションを追加できるようにすることは有益であろう。例えば、カードユーザが、そのユーザのＩＣカードをホームコンピュータに差し込んで、インターネット上でアプリケーションをダウンロードできれば有用であろう。アプリケーションコードおよび関連データをインターネット等のセキュリティが確立されていない通信線上で送信する場合、この種のアプリケーション遠隔ロードは複数のセキュリティ上のリスクを生じる。
アプリケーションまたはデータをＩＣカードに送信するエンティティは、意図したＩＣカードのみが送信データを受け取ることを必要とする。第三者が、データを傍受してそのデータを見ることができてはいけない。さらに、送信側エンティティは、情報を要求したＩＣカードが実際に全体ＩＣカードシステムの一部であり、単にシステムの一部のふりをしているのではないということの検証を要求する。これらの懸念は、遠隔的アプリケーションロードおよびローカル端末によるアプリケーションロードの両方において生じる。
従って、本発明の目的の１つは安全な配送技術を提供することであり、具体的には、ＩＣカード上にロードされ得るスマートカードアプリケーションを含むデータの安全な配送を可能にする安全なＩＣカードシステムを提供することである。
発明の要旨
上記およびその他の目的が本発明によって達成される。本発明は、アプリケーションを含むデータのＩＣカード上への安全な配送を行うＩＣカード方法および装置を提供する。これには、１対のシークレットおよび公開鍵のＩＣカード上での保存、保存された公開鍵のＩＣカードからの取り出し、公開鍵を用いた配送対象データの少なくとも一部の暗号化、暗号化されたデータのＩＣカードへの送信、およびＩＣカードの秘密鍵を用いた暗号化データの復号化が含まれる。
好適な実施形態においては、証明機関（ＣＡ）またはＩＣカードシステムの全体的なセキュリティを管理するエンティティが、ＩＣカードの公開鍵のコピーを暗号化（またはデジタル署名）し、署名されたコピーはＩＣカード上にも保存される。データをＩＣカードに送信するエンティティは、ＩＣカードの署名された公開鍵を取り出し、そして、ＣＡの公開鍵を用いて署名された公開鍵を検証することによって、ＣＡがそのカードを承認したことを検証することができる。検証が成功すると、ＣＡがＩＣカードを承認したことをエンティティが検証したことになる。
【図面の簡単な説明】
本発明の例示的な実施形態を示す添付の図面に関連して以下の詳細な説明を読むことにより、本発明のさらなる目的、特徴および利点が明らかになるであろう。
図１Ａは、配送側エンティティからＩＣカードにデータを安全に配送する安全なデータ配送システムのブロック図である。
図１Ｂは、アプリケーション提供者からＩＣカードにアプリケーションをロードするアプリケーションロードシステムのブロック図である。
図２は、アプリケーションロードユニットの内容を図示したものである。
図３は、アプリケーションユニットを図示したものである。
図４は、あるＩＣカードについての個々の鍵組を提供する工程のフローチャートである。
図５は、鍵変換ユニットを図示したものである。
図６は、鍵変換ユニットの平文を図示したものである。
図７は、アプリケーションロード証明書（Application Load Certificate）を図示したものである。
図８は、アプリケーションユニットが復号化される様子を図示したものである。
図９は、アプリケーションロードユニットを処理する際に行われる工程を示すフローチャートである。
図１０は、ＫＴＵを処理する際に行われる工程を示すフローチャートである。
図１１は、アプリケーションロードユニットを受け取り、これを処理することができるＩＣカードの構成要素を示すブロック図である。
そうでないことが記載されている場合を除き、全図面を通して、同じ参照番号および文字は、例示された各実施形態において同じ特徴部、部材、構成要素および部分を示すために用いられている。さらに、以下で図面を参照しながら本発明を説明するが、これは例示的な実施形態に関する説明である。添付のクレームによって規定される本発明の真の範囲および趣旨から逸脱することなく、記載された実施形態に変更および改変を加えることが可能であることが意図されている。
発明の詳細な説明
そのＩＣカードの寿命の任意の時点で、複数のアプリケーションオペレーティングシステムを含むＩＣカード上にアプリケーションをロードできる能力を持つことは有益である。この柔軟性によって、カードのユーザが、定期的に新しいアプリケーションをＩＣカードに追加すること、ならびに、より新しいバージョンのアプリケーションがリリースされたときに、新しいバージョンのアプリケーションを用いて古いアプリケーションを更新することが可能になる。例えば、カードユーザは、初めに、財布または電子キャッシュアプリケーション（例えば、ＭＯＮＤＥＸ^TM）が保存されたＩＣカードを持ち得る。ユーザがこのカードを持ってからしばらくした後、このユーザは、クレジット／デビットアプリケーションのような追加アプリケーションをこのカード上にロードし得る。カード上にクレジット／デビットアプリケーションをロードしてからしばらくした後、そのクレジット／デビットアプリケーションの新しいバージョンが利用可能になり得る。その時、このカードユーザが、そのＩＣカード上の古いアプリケーションを消去して、さらなる機能を有し得るクレジット／デビットアプリケーションの新しいバージョンに置き換えることは可能であるべきである。さらに、ＩＣカードは、新しいクレジットカード口座番号または更新された情報等の個人情報に関するデータを受け取る必要がある。
ＩＣカードの寿命サイクルにおける複数の異なる時点でアプリケーションのロードおよびデータの送信を行うという柔軟性は、カード上にアプリケーションをロードするプロセスに関してセキュリティ上の問題を生じる。マルチアプリケーションオペレーティングシステム環境においては、アプリケーションおよびデータのロードを、銀行のＡＴＭマシンのような端末と、電話線、ケーブル線、インターネット、衛星または他の通信手段等の遠隔通信リンク上との両方で行えることが有益である。ＩＣカード上にアプリケーションおよびデータをロードする際、アプリケーション提供者は、ロードすべきアプリケーションに関するセキュリティを提供する必要がある。第１に、アプリケーション提供者は、そのアプリケーションを受け取ることが意図された正しいカードユーザにのみアプリケーションが送られることを確実にしなければならない。第２に、アプリケーションおよび関連データは、個人的または企業秘密情報を含み得る。このような個人的または企業秘密情報は暗号化することにより、暗号化されたアプリケーションコードおよびデータの内容をＩＣカード以外のエンティティが見れないようにする必要がある。アプリケーションコードおよびデータの一部が秘密であり、他の部分は秘密ではない場合もある。本願では、カードにロードするアプリケーションおよび関連データの一部または全ての内容の認証および保護という問題に対処する。
本明細書中、複数の暗号化／復号化技術が記載される。対称暗号化および非対称暗号化という２つの基本的な種類の暗号化がある。対称暗号化では、式および鍵を用いてデータを変換することにより、データを暗号化する数式の一部として秘密鍵を用いる。データを暗号化した後、これと同じ秘密鍵を復号化アルゴリズムとともに用いて、別のパーティが、この暗号化されたデータを復号化することができる。同じ鍵は暗号化および復号化のために用いられ、技術は対称的である。対称アルゴリズムの従来例の１つは、ＤＥＳである。
非対称暗号化技術では、１対をなす異なる２つの鍵を用いて情報の暗号化および復号化を行う。これらの２つの鍵は、通常、プライベートまたは秘密鍵および公開鍵と呼ばれる。この１対の鍵の一方を用いてデータを暗号化した場合、そのデータの復号化には他方の鍵が用いられる。データの送り主が、そのデータをその送り主の秘密鍵を用いて署名すると、公開鍵を持っていれば誰でもそのメッセージを検証できる。典型的に、公開鍵は公に知られているので、秘密鍵を用いて署名されたデータの内容を保護することはできないが、特定の秘密鍵によってそのデータが署名されているかどうかを判定することによってそのデータの起源（origination）は検証できる。この認証プロセスは、デジタル署名と呼ばれる。人物Ａが人物Ｂに送ろうとしているメッセージを人物Ａが認証したい場合、人物Ａは、人物Ａの秘密鍵を用いてその文書に署名する。人物Ｂがそのメッセージを受け取ると、人物Ｂは、人物Ａの公開鍵を用いてそのメッセージを検証する。その公開鍵を用いてそのメッセージが検証されると、その文書が人物Ａの秘密鍵を用いて署名されたことを人物Ｂが知ることになる。このようにして、メッセージの起源（origin）が認証される。
非対称鍵組を用いてメッセージの内容を保護することも可能である。人物Ａが、人物Ｂに、他の誰も読むことのできない暗号化されたメッセージを送りたい場合、人物Ａは、そのデータまたはメッセージを人物Ｂの公開鍵を用いて暗号化し、それを人物Ｂに送る。そうすれば、人物Ｂの秘密鍵の所有者しかそのデータを復号化できなくなる。複数の鍵の組み合わせを用いれば、ある人物がそのメッセージの認証および暗号化の両方を行うことが可能である。非対称の鍵対には、カードセキュリティに関していくつかの強力な用途がある。しかし、非対称暗号化は、対称暗号化と比べて比較的プロセッサコストが高くつく（プロセッサコストは演算時間と関連している）。非対称暗号化方法の一例は、ＲＳＡ^▲Ｒ▼である。
暗号化方法をより強力にするハイブリッド対称暗号化方法の１つは、２つの対称鍵を用いてデータを暗号化することである。この技術はトリプルＤＥＳと呼ばれ、鍵１を用いてデータを符号化し、鍵２を用いてそのデータを復号化し（これにより、そのデータをさらに符号化することになる）、そして、再び鍵１を用いてそのデータをさらに符号化するものである。データがその目的地に到着した後、鍵１を用いてそのデータを復号化し、鍵２を用いてそのデータを符号化し、そして、鍵１を用いてそのデータを復号化する。これらの余分な符号化および復号化ステップによって、この技術はより強力になるとともに、両方の鍵がそろっていない状態で適切に復号化することがより困難になる。
図１Ａは、ＩＣカードシステム内において、安全にデータを配送する際に使用されるエンティティのブロック図を示す。送信側エンティティ１は、カード発行者、銀行、ＩＣカード、またはデータをＩＣカード３に配送することを望んでいる他のエンティティであり得る。好ましくは、送信側エンティティ１がデータ配送プロセスを開始する。あるいは、カードが送信側エンティティ１からのデータを要求する場合には、ＩＣカード３がデータ配送プロセスを開始してもよい。
送信側エンティティ１は、インターフェースデバイス５（例えば、ＩＣカードと通信する端末）に接続される。データ経路７は、電話線、イントラネット、インターネット、衛星リンクまたは任意の他の種類の通信リンクであり得る。本実施例の場合、ＩＣカード３から遠隔の位置に配置された送信側エンティティ１が、データを安全にＩＣカードへ送ることを望んでいる。しかし、データリンクが「オープン」リンクであり（即ち、プライベートリンクではなく）、送信されているデータを第三者が傍受したり、あるいはすり替えたりしている可能性があるので、送信されたデータを意図したＩＣカードのみが受け取ることを保証するにはセキュリティ対策が必要である。ＩＣカードがＩＣカードシステムの一部としてその有効性が証明されていることを認証するために、証明機関９を用いることも可能である。
図１Ａにおいて、ＩＣカード３のために、秘密（またはシークレット）鍵１９および対応する公開鍵１５を生成する。好ましくは、これらの鍵は、ＲＳＡ▲Ｒ▼等の非対称暗号化アルゴリズムを用いて生成される。これらの鍵は、ＣＡ９または任意の他の場所で生成され得る。なぜなら、これらの鍵は、ＩＣカード３にしか特異的でなく、他のコピーを保持しておく必要がないからである。３番目のデータ項目である公開鍵証明（public key certificate）１７もＩＣカード３上で生成および保存される。
公開鍵証明１７は、ＣＡ９のプライベート鍵を用いて公開鍵１５に署名することによって生成される。これにより、ＩＣカードの個々の鍵組を証明するために、ＣＡがＩＣカードの公開鍵にデジタル署名したことを、ＣＡ９の公開鍵を持つ人物が検証することが可能になる。公開鍵証明は、ＩＣカードの秘密／公開鍵組が生成されたときに、またはそれ以降のある時点で、ＣＡによって生成される。
送信側エンティティ１がデータ配送を開始すると、インターフェースデバイス５を通してＩＣカード３へのコンタクトがとられ、ＩＣカード３がその公開鍵１５およびその公開鍵証明１７を送信側エンティティ１に送る。その後、送信側エンティティは、この公開鍵証明をＣＡ１３の公開鍵（ＣＡ１３の公開鍵は、ＣＡ９から公に入手可能であり、送信側エンティティ１内に保存され得る）を用いて検証し、これにより、ＣＡ９がその公開鍵にデジタル署名したかどうかを判定し、ＩＣカードが有効なカードであることを検証する。
その後、送信側エンティティ１は、ＩＣカードの公開鍵を用いて送信すべきデータを暗号化する。その後、送信側エンティティ１は、暗号化されたデータ１１をインターフェースデバイス５およびＩＣカード３に送信する。ＩＣカード３は、この暗号化されたデータを、対応するプライベート鍵（秘密鍵とも呼ばれる）１９を用いて復号化する。その後、このデータはＩＣカード３によって処理され得る。そのプライベート鍵のコピーを持っているのはＩＣカード３だけであり、意図したＩＣカードだけが暗号化されたデータにアクセスできる。これにより、第三者が暗号化されたデータにアクセスできないこと、ひいては、意図されたＩＣカードだけがそのデータを読んで処理することができることが確実になる。
図１Ｂは、ＩＣカード上にアプリケーションをロードするための安全な方法を示す。図１Ｂは、安全な遠隔アプリケーションローディングプロセスに使用されるエンティティのブロック図を示す。アプリケーションプロバイダ１０１は、カードの発行者、銀行、またはアプリケーションローディングサービスを提供する他のエンティティであり得る。アプリケーションプロバイダ１０１は、ＩＣカード１０３上へのアプリケーションローディングプロセスを起動する。ＩＣカード１０３は、データコンデット１０７に接続され、データコンデット１０７は、インターフェイスデバイス１０５（例えば、ＩＣカードと通信する端末）に接続されている。データコンデット１０７は、電話回線、イントラネット、インターネット、衛星リンク、またはその他の任意のタイプの通信リンクであり得る。アプリケーションプロバイダ１０１は、ＩＣカード１０３から遠隔に配置され、ＩＣカードへアプリケーションを送信してロードすることを所望する。しかしながら、データリンクがオープンリンクであり、送信されるアプリケーションを妨害したり置換する第三者に晒されているために、アプリケーション自体を認証する安全手段、アプリケーションプロバイダ、およびＩＣカードが、システムの整合性を確実にするために使用されなければならない。送信されているいくつかのデータが識別されたシステム一部であることの認証を補助するためには、ＣＡ１０９も使用され得る。
図１Ｂでは、アプリケーションプロバイダは、インターフェースデバイス１０５へ、そして最終的にはＩＣカード１０３へ、アプリケーションロードユニット１１１を送信する。ＡＬＵは、アプリケーション自体および認証に必要なセキュリティデータを含み、アプリケーションコードおよび関連データを保護する。ＡＬＵは、図２において詳細を論じたが、本明細書の他の図とも関連がある。ＡＬＵ１１１は、好適には、証明機構（ＣＡ）１０９からアプリケーションプロバイダ１０１に送信されるアプリケーションロード証明（ＡＬＣ）１１３データをも含む。証明機構は、ＩＣカード上にロードされるべき各アプリケーションに対するアプリケーションロード証明を供給することによって、システムの全体的なセキュリティを管理する。アプリケーションプロバイダ１０１およびＩＣカード１０３の両方は、個々の公開／秘密鍵セットを有する。認証とセキュリティのプロセスを以下に説明する。
図２は、アプリケーションロードプロセス中にアプリケーションローダからＩＣカードに送信されるアプリケーションロードユニットの構成要素を説明する図を示す。アプリケーションロードユニット（ＡＬＵ）２０１は、アプリケーションユニット（ＡＵ）２０３、アプリケーションユニット署名（ＡＵｓ）２０５、鍵変換ユニット（ＫＴＵ）２０７、およびアプリケーションロード証明（ＡＬＣ）２０９を含む。ＡＬＣ２０１は、データ送信中に使用される従来フォーマットで初期化される。ＡＵ２０３は、ＩＣカード上に記憶されるべきアプリケーションコードおよびデータを含み、それらの一部またはすべてが、秘密部分を、もしくはコードおよび／またはデータ部分を保護するために暗号化される。ＡＵ２０３を、図３を参照してさらに詳細に説明する。
ＡＵｓ２０５は、アプリケーションプロバイダの秘密鍵でデジタル的に署名されたアプリケーションコードおよびデータＡＵ２０３である。アプリケーションプロバイダの公開鍵は、ＡＬＣ２０９の一部として送信され、アプリケーションの作成者としてアプリケーションプロバイダを認証するのに使用される。ＡＬＣ２０９は、カード識別情報およびアプリケーションプロバイダの公開鍵から構成され、証明機構の秘密鍵によって署名される。以下、これらの要素をすべて、より詳細に説明する。
ＫＴＵ２０７は、指定された部分をＩＣカードが復号化するのを可能にする、ＡＵ２０３（アプリケーションのコードおよびデータ）の暗号化に関する情報を含み、これにより、アプリケーションおよびデータはＩＣカードによってアクセスされ得るが、アプリケーションプロバイダとＩＣカードとの間での送信中にデータを保護する。ＫＴＵ２０７は、アプリケーションが意図されるＩＣカードの公開鍵を暗号化されており、これにより、意図されたＩＣカードのみが、ＫＴＵ情報を用いたアプリケーションコードおよびデータを復号化できることを確実にする。この要素は図５を参照して説明する。
図３は、アプリケーションロードユニットの一部であるアプリケーションユニット２０３の図を示す。ＡＵ２０３は、カードユーザのＩＣカード上にロードされるべきプログラムコードおよび関連データ両方を含む。プログラムコードは、ＩＣカードのマイクロプロセッサによって実行される複数のプログラム命令を含む。プログラム命令は、ＩＣカード上に記憶されているオペレーションシステムが解釈できる任意のプログラミング言語で記述され得る。
例えばＭＵＬＴＯＳシステムでは、プログラムはＭＥＬ^TM（ＭＵＬＴＯＳ実行可能言語）で記述され得る。たいていのアプリケーションは、カード上にロードされなければならない関連データを有する。例えば、人名またはアカウント番号などカードユーザを識別するデータは、クレジット／デビットアプリケーションを伴う安全な方式においてロードされ得る。アプリケーションプロバイダは、データによって表される電子キャッシュを、電子パースアプリケーションをインストールするときに助成として提供し得る。このデータのいくつかまたは全部が、第三者から秘密に保たれることが所望される。ひいては、アプリケーションコード自体が独占物であると見なされ得、その一部が他者からは秘密であることが所望され得る。鍵変換ユニット（ＫＴＵ）の使用は、アプリケーションプロバイダーがアプリケーションの選択された部分を秘密として暗号化し、第三者からそれを保護することを可能にする。
アプリケーションユニット部分３０５は、アプリケーションプロバイダからＩＣカードに送信されるべきプログラムコードを指示する。アプリケーションユニット部分３０７は、ＩＣカード上にロードされるべきアプリケーションの一部として送信されるべき関連データを指示する。この例では、アプリケーションユニットの３つの個別領域が、単一のＤＥＳまたは３重のＤＥＳのいずれかを用いて暗号化されることが示されている。暗号化される部分および暗号化のタイプに関する任意の数の変更が、本願記載の技術を用いて実施され得る。
この例では、暗号化されたロケーション３０９は、３重ＤＥＳ技術を用いて暗号化されたアプリケーションユニット２０３の第１の部分を示す。上述の暗号化プロセスは、対称的鍵および従来公知のＤＥＳベースアルゴリズムを用いてデータを変換することを含む。データはその後、従来公知のＤＥＳベース復号化アルゴリズムにデータを代入することにより復元され得る。暗号化ロケーション３１１は、３重ＤＥＳを用いて暗号化されたアプリケーションユニット２０３の第２の部分を示す。暗号化ロケーション３１３は、単一のＤＥＳを用いて暗号化された第３の部分を示す。単一ＤＥＳは、より少ない計算しか復号化に要さず、後述するＫＴＵの一部として、より少ない領域しか占有しない。アプリケーションローダからＩＣカードへ送信中に、第三者によってアプリケーションユニットが妨害された場合、第三者が正しい鍵および復号化アルゴリズムを有するまで、暗号化された部分は、読み出され得ない。従って、情報はＫＴＵ内で保護される。
ＫＴＵは、アプリケーションユニットのどの部分が暗号化されるか、どの暗号化アルゴリズムが使用されるか、およびテキストの復号化に使用される単数または複数の鍵を記述することによって、アプリケーションおよび関連データの意図するＩＣカードが、アプリケーションユニットの暗号化部分を復号化することを可能にする。この情報は、アプリケーションプロバイダと意図されるＩＣカードとの間で高度に秘密であり、従って意図されるカードに極めて特殊な方式で保護される。送信されるＡＬＵ全体の一部であるＫＴＵを暗号化するために、特定の意図されるＩＣカードのための個別鍵セットが使用される。鍵セットおよびその作成を以下に説明する。
本発明によれば、ＣＡにおいて実行される安全処理の一つは、カード上に記憶された各ＩＣカードのための個別化された鍵セットを作成することである。鍵は、オフカード検証（即ちカードが正真のカードであることを検証する）および安全なデータ配送に使用される。鍵作成プロセスを図４に概略的に示す。鍵セットは、３つの異なる鍵データアイテムから構成される。即ち、カードのみが知っているカード秘密鍵、カード上に記憶されているカードの公開鍵、およびＣＡの秘密鍵によって署名されたカード公開鍵であるカード公開鍵証明である。以下、鍵セットの個々の鍵を、より詳細に説明する。
工程４０１は、カードのメモリ内の個別ＩＣカードに対して、カード特定的に配送された秘密鍵を記憶する。この秘密鍵は、ＲＳＡ^▲Ｒ▼など標準的な非対称暗号化技術からＣＡにより作成され、カード許可デバイスを介してカード上にロードされる。ひとたびカード上に記憶されれば、ＣＡはそれ自身のメモリから秘密鍵に関するあらゆるデータを消去する。従って、カード自体のみがその秘密鍵を知っている。カード内の秘密鍵情報を含んでいるデータ要素は、「ｍｋｄ＿ｓｋ」と呼ばれ、ＭＵＬＴＯＳ鍵データ秘密鍵を意味する。
工程４０３は、カードのメモリ内の個々のＩＣカードのためのカード特定的に配送された公開鍵を記憶する。この公開鍵は、好適には、工程４０１において秘密鍵を作成するのに使用された非対称暗号化技術からＣＡによって作成される。秘密鍵と同じく、ひとたびカード上に公開鍵が記憶されれば、ＣＡ（または他の鍵プロバイダ）は、そのシステムから公開鍵データを削除するので、公開鍵の唯一の複製はカード内に保存される。カードの公開鍵情報を含むデータ要素は「ｍｋｄ＿ｐｋ」と呼ばれ、ＭＵＬＴＯＳ鍵データ公開鍵を意味する。
工程４０５は、カードメモリ内の個々のＩＣカードのためのカード特定的に配送された公開鍵証明を記憶する。カードの公開鍵証明情報を含むデータ要素は、「ｍｋｄ＿ｐｋ＿ｃ」と呼ばれ、ＭＵＬＴＯＳ鍵データ公開鍵証明を意味する。この公開鍵証明は、好適には、以下に示すようにＣＡの秘密鍵で配送公開鍵「ｍｋｄ＿ｐｋ」に署名することにより作成される。
ｍｋｄ＿ｐｋ＿ｃ＝［ｍｋｄ＿ｐｋ］_{CA_sk}
これは、個々のカードの公開鍵証明が、ＣＡの秘密鍵を個々のカードの公開鍵に適用して作成されることを意味する。このプロセスは、ＣＡにおいて実施される。公開鍵証明はＣＡによって保存され、これにより、必要に応じて公開鍵を再作成することができる。
端末がＩＣカードから公開鍵証明を読み出し得、ＣＡが署名をし、それにより個々のＩＣカードを認可したことを検証できる。これは、ｍｋｄ＿ｐｋに署名するのに使用されたＣＡ鍵セットの公開要素で公開鍵証明を検証することによって達成される。
図５は、ＫＴＵ２０７の内容を図示したものであり、ヘッダ部分５０１およびＫＴＵ暗号文部分５０３を含んでいる。図５に示すように、ヘッダ情報５０１は、例えば、ａｐｐｌｉｃａｔｉｏｎ＿ｉｄ＿ｎｏ（アプリケーション識別番号）、ｍｃｄ＿ｎｏ（ＩＣカード番号）および／またはｍｓｍ＿ｃｏｎｔｒｏｌ＿ｄａｔａ＿ｄａｔｅ（ＩＣカードが発行された日付）などの識別子または許可情報５０５を含む。追加の識別子も含まれ得る。これらの識別子により、システムは、ＡＬＵを受信するＩＣカードが意図されたＩＣカードであることを検証できる。許可データは、上記参照した関連出願に詳細に記載されている。
ＫＴＵ暗号文５０３は、ボックス５０７に示す意図されたＩＣカードの公開鍵ｍｋｄ＿ｐｋで暗号化されたＫＴＵ平文（暗号化されていない）に対応する。ＫＴＵ平文は、図６においてさらに説明する。公開鍵ｍｋｄ＿ｐｋは、アプリケーションプロバイダーによって、意図されたＩＣカードから取得される。ＩＣカードの公開鍵は、誰でも自由に利用でき、カードまたはＣＡから直接入手できる。ＫＴＵ平文をＩＣカードの公開鍵で暗号化することによって、意図されたＩＣカードのみが公開／秘密鍵対の秘密鍵を用いてＫＴＵ暗号文を復号化することができる。これは、意図されたＩＣカードのみが、ＫＴＵ平文の内容を決定し、ロードされるアプリケーションの暗号化部分を識別し、鍵を用いてアプリケーション全体および関連データを復号化し復元できることを意味する。その他のエンティティは、ＩＣカードの秘密鍵を有さないので、送信されているプログラムコードおよびデータのセキュリティと整合性とが確保される。
図６は、ＫＴＵ平文６０１を示す図である。ＫＴＵ平文６０１は、好適には、識別子フィールド６０３、ｎｏ＿ａｒｅａ＿ｄｉｓｃｒｉｐｔｏｒｓフィールド６０５、ａｌｇ＿ｉｄフィールド６０７、ａｒｅａ＿ｓｔａｒｔフィールド６０９、ａｒｅａ＿ｌｅｎｇｔｈ６１１、ｋｅｙ＿ｌｅｎｇｔｈフィールド６１３、ｋｅｙ＿ｄａｔａフィールド６１５、ならびに、アプリケーションユニット内に存在する暗号化領域の数によって追加の領域および鍵フィールドを含む。識別子６０３は、ＫＴＵが適用されるアプリケーションユニットの識別情報を含む。
Ｎｏ＿ａｒｅａ＿ｄｅｓｃｒｉｐｔｏｒｓ６０５は、いくつの数のＡＵの異なる部分が暗号化されたのかを示す。図３の例では、領域記述子の数は３である。フィールド６０７は、暗号化された第１の領域のためのアルゴリズム識別子を含む。アルゴリズムは、例えば、ＤＥＳまたは三重ＤＥＳであり得る。フィールド６０９は、第１の暗号化領域の開始を指示する。この指示は、ＡＵの開始からのオフセットであり得る。例えば、オフセットは、１００により得る。これは、第１の領域が、アプリケーションユニットの１００番目のバイトから開始することを意味する。フィールド６１１は、第１の暗号化部分の領域長を指示する。このフィールドにより、ＩＣカード上のマイクロプロセッサは、どの程度の大きさの領域が暗号化され、領域の開始といつ結合されたのかを知ることができ、ＩＣカードマイクロプロセッサは、アプリケーションユニットの正しい部分を暗号化できる。フィールド６１３は、アプリケーションユニットの特定の暗号化部分に対する鍵長を指示する。鍵の長さは、異なる暗号化技術によって異なる。鍵長フィールドによって、ＩＣカードは鍵データの長さを知ることができる。フィールド６１５は、特定の暗号化部分に対する鍵データを指示する。鍵データは、暗号化部分のアルゴリズム同一性およびロケーションとともに使用され、暗号化部分をデコードする。一つ以上の暗号化部分が指示されている場合、アルゴリズムを参照する追加のデータ、開始ロケーション、長さ、鍵長および鍵データが、ＫＴＵ平文内に存在する。複数のフィールドを記載したが、本発明にすべてのフィールドが必要なのではない。しかしながら、最も重要なフィールドは、鍵データ自体である。
図７は、アプリケーションロード証明（ＡＬＣ）２０９を示す図である。ＡＬＣ２０９は、ヘッダ７０１およびアプリケーションプロバイダ公開鍵７０３を含む。次に、ヘッダ７０１およびアプリケーションプロバイダ公開鍵７０３は、ＣＡの秘密鍵で署名（暗号化）される。従って、ＣＡのみがＣＡプライベート鍵を知っているので、ＡＬＣ２０９は、ロードされる各アプリケーションに対してＣＡによってアプリケーションプロバイダに供給されなければならない。ヘッダ７０１は、アプリケーションが意図されるアプリケーションプロバイダおよびＩＣカードに関する情報を含む。ＡＬＣ２０９は、識別情報を使用し得るアプリケーションプロバイダによって正しいＡＬＵ内に配置される。アプリケーションプロバイダ公開鍵７０３は、識別データとともにＣＡに供給される。次に、ＣＡは、認証性を検証したあとで、この情報に署名し、アプリケーションプロバイダに署名されたＡＬＣを返送する。ＩＣカードは、ＡＬＵ２０１の一部としてＡＬＣ２０９を受け取るとき、ＣＡの公開鍵でＡＬＣ２０９を検証する。これにより、ＣＡがアプリケーションロード証明に署名し、それが本物であることを確証する。情報を検証した後で、ヘッダ識別情報７０１がチェックされ、アプリケーションプロバイダ公開鍵が復元される。この公開鍵は、ＩＣカード上にロードされるべきアプリケーションおよびコードが適切なアプリケーションプロバイダによって作成されたことを検証するのに使用される。
図８は、ＡＵ２０３がアプリケーションプロバイダによって署名されたことを検証するために、アプリケーションプロバイダの公開鍵を使用してＡＵ署名２０５を検証することを示した図である。ＡＵ署名２０５は、アプリケーションプロバイダ公開鍵８０１で検証され、ＡＵ２０３と比較される。データブロックがマッチした場合、ＩＣカードは、アプリケーションプロバイダがアプリケーションユニットに署名（暗号化）し、アプリケーションが本物であることを検証した。この認証は、アプリケーションプロバイダのみが秘密鍵を有するので、有効である。アプリケーションプロバイダ公開鍵がＣＡによって署名されたアプリケーションロード証明２０９の一部として供給されているので、ＩＣカードは、この情報を効率よく処理し得る。従って、外部ロケーションから公開鍵を復元して、アプリケーションを認証する必要がない。
図９は、アプリケーションロードユニットがＩＣカードによって受け取られたときに、これを処理するための工程のフローチャートを示す。ＡＬＵを受け取る前に、所望により、ＩＣカードの同一性に関して同一性チェックが実行され得る。ＡＬＵプロセス技術は、ロードされるアプリケーションが、（１）正しいアプリケーションプロバイダからであり、（２）意図されるカードにロードされ、（３）ＣＡによって証明されていることを検証することを含む、数々のさらなる検証を提供する。また、ＡＬＵプロセス技術は、プログラムコードおよび関連データの部分を、ＩＣカードが安全な方式で復号化できるようにする配送復号化鍵の配送を可能にする。工程９０１では、ＩＣカードがアプリケーションプロバイダからＡＬＵを受け取る。ＡＬＵは、端末接続、遠隔接続（contactless connection）、電話、コンピュータ、イントラネット、インターネット、または他の任意の通信手段を介して送信され得る。ＡＬＵは、ＩＣカードのＩ／Ｏバッファに、ＡＵ２０３、ＡＵ署名２０５、ＫＴＵ２０７、およびＡＬＣ２０９の開始アドレスを指示するヘッダ情報とともに配置される。あるいは、ＩＣカードは、これら４つのユニットの相対アドレスロケーションを決定し得る。
工程９０３は、ＣＡ公開鍵を備えたＡＬＣ２０９を検証する。各ＩＣカードは、好適には、そのメモリ内にＣＡ公開鍵の複製を記憶する。これは、ＣＡ公開鍵が多くのトランスアクションに使用されるからである。あるいは、ＩＣカードは、公知の記憶ロケーションから公開鍵を取得し得る。ＣＡ公開鍵がＡＬＣ２０９を適切に検証した場合、ＩＣカードは、ＣＡが秘密鍵によってＡＬＣ２０９に署名し、従って、アプリケーションロード証明は適切であることを検証する。ＩＣカードが、ＡＬＣを適切に検証しなかった場合、ＡＬＣはＣＡによって署名されておらず、証明は適切でない。そこで、アプリケーションローディングプロセスは終了する。
次に、工程９０５が、アプリケーションロード証明において送られた識別情報に対してＩＣカードの同一性をチェックし、カードがアプリケーションを受け取ることを意図されたものであることを確実にする。この許可チェックは、上記に確認した関連特許出願に記載されている。識別データの一致が存在しない場合、アプリケーションローディングプロセスは終了する。識別データが一致する場合、プロセスは継続する。
工程９０７は、検証されたＡＬＣから復元されたアプリケーションプロバイダの公開鍵を用い、ＡＵ署名２０５を検証する。ＡＬＵがアプリケーションプロバイダにより作成されているとき、アプリケーションユニット２０３は、アプリケーションプロバイダの秘密鍵で署名され、アプリケーションが正しいアプリケーションプロバイダによって供給されたことを認証する。次に、アプリケーションプロバイダは、ＡＬＣを介してＩＣカードに公開鍵を供給する。ひいては、ＩＣカードは、ＡＵ署名２０５を検証する。２つのデータブロックが一致した場合、ＡＬＵはアプリケーションプロバイダによって作成されたとして検証される。アプリケーションプロバイダの公開鍵は、ＣＡによって署名されたＡＬＣの一部であるので、ＣＡは、適切な公開鍵がＩＣカードに供給されたことを確証する。アプリケーションプロバイダと、ＣＡと、意図されたＩＣカードとの間のこの特殊な鍵インタラクションは、安全システムの一部であるＩＣカードへの偽造、もしくは未許可のアプリケーションまたはデータが、ロードされないことを確証する。
次に、工程９１１が、唯一意図されたカードのみがアプリケーションを受け取ることをさらに検証するＫＴＵ認証チェックを処理する。ＫＴＵ認証チェックは、第三者が何らかにおいてＡＬＵを妨害した場合でも、第三者がＡＵの暗号部分を読み出せず、ＡＵを復号化する鍵を受け取れないことを確証する。この工程を図１０においてさらに示す。
図１０は、ＫＴＵ認証プロセスの工程を示す。工程１００１は、好適には任意であるので破線で示されているが、ＩＣカードの同一性を再度チェックする。識別情報は、ＫＴＵデータの一部として送られ得る。しかしながら、このチェックは既に工程９０５において実施されているので、任意である。
次に、工程１００３が、ＩＣカードの秘密鍵（ｍｋｄ＿ｓｋ）を用いてＫＴＵ暗号文５０３を復号化する。ＫＴＵ平文は、意図されるカードの公開鍵（ｍｋｄ＿ｐｋ）を用いて、先だって暗号化されている。これは、唯一意図されたカードの秘密鍵の保持者のみが、暗号化されたメッセージを復号化し得ることを意味する。アプリケーションプロバイダは、ＩＣカード自体から（図４およびｍｋｄ鍵セットに関する関連テキストを参照）、または公開鍵を保持するデータベースのいずれかから、意図されるＩＣカードの公開鍵を入手する。ＩＣカードがＫＴＵ暗号文を適切に復号化しない場合、ＫＴＵはそのカードには意図されておらず、アプリケーションローディングプロセスは停止する。ＩＣカードがＫＴＵ暗号文を適切に復号化した場合、プロセスは継続する。
工程１００５は、アプリケーションユニット（ＡＵ）の暗号化領域を識別する。図６を参照して説明したＫＴＵ平文の例では、ＩＣカードは、相対的開始アドレスおよび領域長フィールドを使用して、暗号化される部分を決定している。工程１００５も、識別された部分を暗号化するのにどの暗号化技術を用いるかを識別し、これにより、適切な復号化技術が使用され得る。例えば、この技術は単一または三重のＤＥＳにより得る。あるいは、この技術は、システムに使用され識別の必要がないデフォルト技術であり得る。
次に、工程１００７が、ＫＴＵ平文からの鍵を復元し、識別された部分を識別された復号化技術で復号化する。これにより、ひとたびすべての暗号化部分が復号化されれば、ＩＣカードはＥＥＰＲＯＭに記憶されるＡＵの復号化された部分を有する。
工程１００９は、その他に任意の暗号化領域が存在する場合をチェックする。図３に記載の例では、３つの暗号化領域が存在する。暗号化領域の数は、図６の例ではフィールドである。しかしながら、部分の数は、他の従来手段を用いて決定し得る。追加の暗号化領域が存在する場合、プロセスは工程１００５に飛ぶ。追加の暗号化領域が存在しない場合、プロセスは工程１０１１から継続する。
次に、工程１０１１は、復号化されたＡＵをＩＣカードのメモリ内にロードする。ＡＬＵは、すべての認証および復号化チェックを通過し、ついにアプリケーションはＩＣカード上に適切に存在し、カードユーザによって実行され使用され得る。図９および図１０において、異なるチェックが特定順序で提示されたが、チェックは任意の順序で実施し得る。記載したすべての技術は、ＡＬＵに最良の安全性を提供することに関連して使用されたが、一つ以上の個別技術が、個別の目的のため、または他の従来安全技術との組み合わせで使用され得る。
図１１は、ＡＬＵがロードされ処理され得るＩＣカードチップのブロック図の例を示す。使用されるＩＣカード上には集積回路が配置される。ＩＣカードは、好適には、中央演算装置１１０１、ＲＡＭ１１０３、ＥＥＰＲＯＭ１１０５、ＲＯＭ１１０７、タイマ１１０９、制御ロジック１１１１、Ｉ／Ｏポート１１１３、および安全回路１１１５を含み、これらは従来のデータバスによって互いに接続されている。
メモリカード内の制御ロジック１１１１は、入力／出力ポートを介してカードのメモリへの読み出し／書き込みを取り扱うのに充分なシーケンスおよびスイッチングを供給する。制御ロジックを備えたＣＰＵ１１０１は、計算、メモリロケーションへのアクセス、メモリ内容の変更、および入力／出力ポートの管理を実施する。カードのなかには、暗号処理など複雑な演算を取り扱うためのコプロセッサを有するものがある。入力／出力ポート１１１３は、ＣＰＵおよび制御ロジックの制御下で、カードとカードインターフェイスデバイスの間の通信のために使用される。タイマ１１０９（クロックパルスを生成し供給する）は、メモリアクセス、メモリ読み出しまたは書き込み、処理、およびデータ通信を完成する一連の工程を介して、制御ロジック１１１１およびＣＰＵ１１０１を駆動する。タイマーは、呼び出し持続時間などのアプリケーションの特徴を供給するのに用いられ得る。セキュリティ回路１１１５は、製造中におけるテストの必要に応じて、入力／出力配線を内部回路に接続する可融性の（fusible）接続を含んでいるが、この回路はテストの完了時に、その後のアクセスを防ぐために壊され（「溶融し（blown）」）、その後のアクセスを防ぐ。ＡＬＵが認証され検証された後のＡＵデータは、ＥＥＰＲＯＭ１１０５に記憶される。ＩＣカードのプライベート鍵は、安全なメモリロケーションに記憶される。ＩＣカードの公開鍵および公開鍵証明は、好適には、ＥＥＰＲＯＭ１１０５に記憶される。本明細書に記載される認証プロセスは、ＣＰＵ１１０１により実行される。
また、図１１は、アプリケーションプロバイダ、送信エンティティ、およびＣＡの可能な構成を示す。アプリケーションプロバイダ内に存在するＣＰＵ１１０１は、本明細書に記載した暗号化技術を用いて必要な情報を暗号化し、必要なデータ処理を実行する。証明機構に存在するＣＰＵ１１０１は、本明細書に記載したアプリケーションロード証明および公開鍵証明に署名するのに使用される。
上記内容は、本願発明の原理を単に例示したものである。従って、本明細書には明示的に図示または記載しないが、本発明の原理を実施し、それにより、本発明の精神および範囲内にある多数のシステムおよび方法を、当業者が考案できることは理解される。
例えば、本明細書ではアプリケーションのロードを記載しているが、同等の安全ローディングプロセスを、データブロック、データファイル、ワードプロセッシング文書、または安全な方式で送信を要する他の任意のタイプのデータなど、他のタイプのデータの送信に適用し得る。

Claims (18)

1. アプリケーションコピーを集積回路カード上にロードする方法であって、該アプリケーションコピーは、１つのアプリケーションの、複数のコピーのうちの１つであり、該アプリケーションコピーは、他のアプリケーションからの該アプリケーションおよび該アプリケーションの各コピーに固有のアプリケーションコピーナンバーを独自に識別する関連アプリケーション識別子を有し、該集積回路カードは、マイクロプロセッサおよび該マイクロプロセッサに結合されたメモリを含み、該メモリが、既に該集積回路カード上にロードされたアプリケーションのアプリケーション識別子およびアプリケーションコピーナンバーを格納するためのアプリケーション履歴リスト領域を含み、該方法は、
   該アプリケーションコピー、該アプリケーション識別子、および該アプリケーションコピーナンバーを該集積回路カードによって受け取るステップと、
   該アプリケーション識別子および該アプリケーションコピーナンバーが該アプリケーション履歴リスト領域に含まれるかどうかを、該集積回路カードによって判定するステップと、
   該アプリケーション識別子および該アプリケーションコピーナンバーが該アプリケーション履歴リスト領域に含まれる場合、該集積回路カードによって該アプリケーションコピーのロードを停止するステップと、
   を含む方法。
2. 前記アプリケーション履歴リスト領域に、前記メモリの所定部分を割り当てるステップと、
   該アプリケーション履歴リスト領域が満杯であるかどうかを、該集積回路カードによって判定するステップと、
   該アプリケーション履歴リスト領域が満杯である場合、該アプリケーションコピーのロードを停止するステップと、
   をさらに含む請求項１に記載の方法。
3. 前記アプリケーション履歴リスト領域に前記アプリケーション識別子および前記アプリケーションコピーナンバーが含まれない場合、該アプリケーション識別子および該アプリケーションコピーナンバーを、該アプリケーション履歴リスト領域に加えるステップをさらに含む、請求項１または請求項２に記載の方法。
4. 前記アプリケーション履歴リスト領域に前記アプリケーション識別子および前記アプリケーションコピーナンバーが含まれず、かつ、該アプリケーションコピーナンバーがゼロでない場合、該アプリケーション識別子および該アプリケーションコピーナンバーを、該アプリケーション履歴リスト領域に加えるステップをさらに含む、請求項１または請求項２に記載の方法。
5. 前記アプリケーションコピーが、アプリケーションコードおよびアプリケーションデータを含み、かつ、該アプリケーションデータの一部分が、グッズまたはサービスと交換し得る値のユニットを含む、請求項１から４のいずれかに記載の方法。
6. 前記アプリケーションコピーがアプリケーションコードおよびアプリケーションデータを含み、かつ、前記アプリケーション識別子および前記アプリケーションコピーナンバーが該アプリケーションデータに含まれる、請求項１から５のいずれかに記載の方法。
7. アプリケーションプロバイダによって、前記アプリケーションコピー、前記アプリケーション識別子、および前記アプリケーションコピーナンバーを、前記集積回路カードに送信するステップをさらに含む、請求項１から６のいずれかに記載の方法。
8. 前記アプリケーションコピーを前記集積回路カードに送信する前に、前記アプリケーションプロバイダによって、該アプリケーションコピーの少なくとも一部分を暗号化するステップをさらに含む、請求項７に記載の方法。
9. 前記アプリケーションコピーの前記一部分の前記暗号化に関する情報を含む鍵変換ユニットを、前記アプリケーションプロバイダによって送信するステップをさらに含む、請求項８に記載の方法。
10. 前記集積回路カードが第１の公開鍵対を有し、前記方法は、
    前記鍵変換ユニットを前記集積回路カードに送信する前に、前記アプリケーションプロバイダによって、該第１の公開鍵対の該公開鍵で該鍵変換ユニットを暗号化するステップをさらに含む、
    請求項９に記載の方法。
11. 前記集積回路カードによって、前記暗号化された鍵変換ユニットを前記第１の公開鍵対のシークレット鍵で復号化するステップと、
    該復号化された鍵変換ユニットに含まれる情報を用いて、前記アプリケーションコピーを復号化するステップと、
    をさらに含む請求項１０に記載の方法。
12. 前記アプリケーションプロバイダが第２の公開鍵対を有し、前記方法は、
    前記アプリケーションコピーを前記第２の公開鍵対のシークレット鍵で暗号化することにより、サインされたアプリケーションコピーを該アプリケーションプロバイダによって形成するステップと、
    該アプリケーションプロバイダによって、該サインされたアプリケーションコピーを前記集積回路カードに送信するステップと、
    をさらに含む、請求項７から１１のいずれかに記載の方法。
13. 前記第２の公開鍵対の公開鍵を、第３の公開鍵対を有する証明機関で登録するステップと、
    該第２の公開鍵対の公開鍵を該第３の公開鍵対のシークレット鍵で暗号化することによって、該証明機関により前記アプリケーションプロバイダに証明書を提供するステップと、
    該アプリケーションプロバイダにより、該証明書を前記集積回路カードに送信するステップと、
    をさらに含む請求項１２に記載の方法。
14. 前記第３の公開鍵対の公開鍵を用いて前記証明書を復号化することにより、前記集積回路カードによって前記第２の鍵対の公開鍵を得るステップと、
    該第２の公開鍵対の公開鍵を用いて、該集積回路カードによって、前記サインされたアプリケーションコピーを検証するステップと、
    該サインされたアプリケーションコピーが検証されない場合、該集積回路カードにより該アプリケーションコピーのロードを停止するステップと、
    をさらに含む、請求項１３に記載の方法。
15. 集積回路カードであって、
    マイクロプロセッサと、
    該マイクロプロセッサに結合されたメモリであって、該メモリは、アプリケーション識別子およびアプリケーションコピーナンバーを格納するためのアプリケーション履歴リスト領域を含み、各アプリケーション識別子および各アプリケーションコピーナンバーは、アプリケーションコピーに関連し、該アプリケーションコピーは、ある１つのアプリケーションの複数のコピーのうちの１つであり、各アプリケーション識別子は、他のアプリケーションからのアプリケーションを独自に識別し、そして、各アプリケーションコピーナンバーは、他のアプリケーションコピーからのアプリケーションコピーを独自に識別する、メモリと、
    該メモリ領域にロードされるアプリケーションコピーに関連する、アプリケーション識別子およびアプリケーションコピーナンバーが、該アプリケーション履歴リスト領域に含まれるかどうかを判定する手段と、
    該関連アプリケーション識別子および該関連アプリケーションコピーナンバーが該アプリケーション履歴リスト領域に含まれる場合に、ロードされる該アプリケーションコピーのロードを停止する手段と、
    を含む集積回路カード。
16. 前記アプリケーション履歴リスト領域が、前記メモリの、割り当てられた所定部分であり、前記集積回路カードは、
    該アプリケーション履歴リスト領域が満杯であるかどうかを判定する手段と、
    該アプリケーション履歴リスト領域が満杯である場合に、ロードされる該アプリケーションコピーのロードを停止する手段と、
    を含む請求項１５に記載の集積回路カード。
17. 前記アプリケーション識別子および前記アプリケーションコピーナンバーが前記アプリケーション履歴リスト領域に含まれない場合、ロードされる該アプリケーションコピーの前記関連アプリケーション識別子および前記関連アプリケーションコピーナンバーを、該アプリケーション履歴リスト領域に加える手段をさらに含む、請求項１５または請求項１６に記載の集積回路カード。
18. 前記アプリケーション識別子および前記アプリケーションコピーナンバーが前記アプリケーション履歴リスト領域に含まれず、かつ、該アプリケーションコピーナンバーがゼロでない場合、ロードされる該アプリケーションコピーの前記関連アプリケーション識別子および前記関連アプリケーションコピーナンバーを、該アプリケーション履歴リスト領域に加える手段をさらに含む、請求項１５から１７のいずれかに記載の集積回路カード。

Images