JP4127862B2 - Ｉｃカード配送鍵セット - Google Patents

Description

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

Claims (10)

1. 複数の集積回路カード（3）のうちの１つの集積回路カードに対する鍵セット(15，19)を用いることにより、データ(11)を送信デバイスから該１つの該集積回路カード上に配送する方法であって、該複数の集積回路カードのうちの該１つの集積回路カードに対する該鍵セット（15，19）は、該複数の集積回路カードのうちの他の集積回路カードに対する鍵セットと異なり、該方法は、
   認証デバイスが、該１つの集積回路カード上に配置されたメモリに秘密鍵／公開鍵対(15，19)を記憶させるステップであって、該秘密鍵／公開鍵対（15，19）は、該複数の集積回路カードのうちの他の集積回路カードに記憶された秘密鍵／公開鍵対と異なる、ステップと、
   該送信デバイスが、該１つの集積回路カードから該記憶された公開鍵(15)を取り出すステップと、
   該送信デバイスが、該取り出された公開鍵を用いて、該データのうちの該１つの集積回路カードへの配送用の部分を暗号化するステップと、
   該送信デバイスが、該取り出された公開鍵を用いて、該データのうちの該１つの集積回路カードへの配送用の暗号化された部分を識別するＫＴＵデータを暗号化するステップと、
   該送信デバイスが、該データのうちの暗号化された部分と、該データのうちの暗号化された部分を識別する該暗号化されたＫＴＵデータとを該１つの集積回路カードに送信するステップと、
   該１つの集積回路カードが、該ＫＴＵデータを復号化するステップと、
   該１つの集積回路カードが、該１つの集積回路カードの秘密鍵を用いて暗号化されたものとして該ＫＴＵデータによって識別される該データの部分を復号化するステップと
   を含み、該ＫＴＵデータは、該データの各領域を配送用に暗号化するためにどの暗号化技術が用いられたかをさらに識別する、方法。
2. 前記１つの集積回路カード上に前記復号化されたデータを記憶するステップをさらに含む、請求項１に記載の方法。
3. 前記認証デバイスが前記１つの集積回路カードの公開鍵にデジタル的に署名し、前記秘密鍵／公開鍵対（15，19）の前記記憶された秘密鍵を用いて該１つの集積回路カードの公開鍵に署名することによって、該１つの集積回路カードの公開鍵証明書が生成され、該１つの集積回路カードに記憶され、該公開鍵証明書は、前記複数の集積回路カードのうちの他の集積回路カードの公開鍵証明書と異なり、該公開鍵証明書が前記送信するステップよりも前に、該秘密鍵／公開鍵対（15，19）の該記憶された公開鍵（15）を用いて、該記憶された秘密鍵が該公開鍵証明書に署名するために用いられたか否かを決定することによって、前記送信デバイスにおいて検証される、請求項１または請求項２に記載の方法。
4. 前記集積回路カードの公開鍵および秘密鍵が、非対称技術を用いて提供される、請求項１〜３のいずれかに記載の方法。
5. 前記非対称技術がＲＳＡである、請求項４に記載の方法。
6. 複数の集積回路カード（3）のうちの１つの集積回路カードに対する鍵セット（15，19）を用いることにより、データを送信デバイスから該１つの集積回路カード上に配送するシステムであって、該複数の集積回路カードのうちの該１つの集積回路カードに対する該鍵セット（15，19）は、該複数の集積回路カードのうちの他の集積回路カードに対する鍵セットと異なり、該システムは、
   該１つの集積回路カード上に配置されたメモリに秘密鍵／公開鍵対（15，19）を記憶させる認証デバイスであって、該秘密鍵／公開鍵対（15，19）は、該複数の集積回路カードのうちの他の集積回路カードに記憶された秘密鍵／公開鍵対と異なる、認証デバイスを備え、
   該送信デバイスは、該記憶された公開鍵(15)を該１つの集積回路カードから取り出し、
   該送信デバイスは、該取り出された公開鍵を用いて、該データのうちの該１つの集積回路カードへの配送用の部分を暗号化し、
   該送信デバイスは、該１つの集積回路カードの該取り出された公開鍵を用いて、該データのうちの該１つの集積回路カードへの配送用の暗号化された部分を識別するＫＴＵデータを暗号化し、
   該送信デバイスは、該データのうちの暗号化された部分と、該データのうちの暗号化された部分を識別する該暗号化されたＫＴＵデータとを該１つの集積回路カードに送信し、
   該１つの集積回路カードは、該ＫＴＵデータを復号化し、
   該１つの集積回路カードは、暗号化されたものとして該ＫＴＵデータによって識別される該データの部分を復号化し、
   該ＫＴＵデータは、復号化技術を用いることできるように、該データの各暗号化領域を暗号化するために用いられた暗号化技術をさらに識別する、システム。
7. 前記復号化されたデータを前記１つの集積回路カード上に記憶する手段をさらに含む、請求項６に記載のシステム。
8. 前記秘密鍵／公開鍵対（15，19）の前記記憶された秘密鍵を用いて前記認証デバイスが前記１つの集積回路カードの公開鍵にデジタル的に署名することによって生成される該１つの集積回路カードの公開鍵証明書であって、該公開鍵証明書は、前記複数の集積回路カードのうちの他の集積回路カードの公開鍵証明書と異なり、該公開鍵証明書は、該１つの集積回路カードに記憶されている、公開鍵証明書をさらに含み、
   前記送信デバイスにおいて該公開鍵証明書を検証する手段をさらに含み、該手段は、該秘密鍵／公開鍵対（15，19）の該記憶された公開鍵（15）を用いて、該記憶された秘密鍵が該公開鍵証明書に署名するために用いられたか否かを決定することによって、該公開鍵証明書を検証する、請求項６または請求項７に記載のシステム。
9. 前記集積回路カードの公開鍵および秘密鍵が、任意の非対称技術を用いて提供される、請求項６〜８のいずれかに記載のシステム。
10. 前記非対称技術がＲＳＡである、請求項９に記載のシステム。

Images