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

Abstract

(57)【要約】 データをＩＣカード上へと安全に配送するための方法および装置。例えば、ＩＣカードの外側に配置されたソースからアプリケーションプログラムを含むデータを安全な様態で配送するために、この方法が使用される。データの少なくとも一部分が、目的のＩＣカードユニットの公開鍵／秘密鍵対の公開鍵を用いて暗号化される。次に、暗号化されたデータはＩＣカードに送られ、ＩＣカードが固有のシークレットキーを用いて鍵変換ユニットを検証する。次に、データはＩＣカード上に記憶され得る。承認されたシステム全体の部分となるようにカードが承認(authorize)されていることを検証するのに、証明機関によって署名された公開鍵のコピーが使用され得る。

Description

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

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 9/10 Ｇ０６Ｆ 9/06 ６６０Ｇ // Ｇ０７Ｆ 7/10 ６４０Ａ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ， ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，Ｌ Ｓ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ， ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，Ｅ Ｅ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＧＨ，ＧＭ，ＧＷ，ＨＵ ，ＩＤ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ， ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，Ｍ Ｄ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ， ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，Ｖ Ｎ，ＹＵ，ＺＷ (72)発明者 エバレット，デイビッド バーリントン イギリス国 ビーエヌ２ ８エイエイチ イースト サセックス，ブライトン，ソル トディーン，アシュダウン アベニュー 31 (72)発明者 バイナー，ジョン チャールズ イギリス国 ウィンドゥルシャルム，ウッ ドランズ レーン，ハイズ（番地なし) 【要約の続き】

Claims (1)

1. 【特許請求の範囲】 １．集積回路カードに関する個別化された鍵セット(15，19)を用いることにより 、データ(11)を該集積回路カード(3)上に配送する方法であって、該方法は、 該集積回路カード上の該メモリに、該集積回路カードに固有のプライベート鍵 ／公開鍵対(15，19)を記憶するステップと、 集積回路カードから該記憶された公開鍵(15)を取り出すステップと、 該取り出された公開鍵を用いて、該データの少なくとも一部分を暗号化して、 該カード上に送信するステップと、 暗号化されたデータを該集積回路カードに送信するステップと、 該暗号化されたデータを、該集積回路カードのプライベート鍵を用いて復号化 して、該配送されたデータを回復するステップと、 を含む方法。 ２．前記集積回路カード上に前記復号化されたデータを記憶するステップをさら に含む請求項１に記載の方法。 ３．証明機関が前記集積回路カードの公開鍵にデジタル的に署名して、該カード に固有であり、かつ、該カードに記憶された公開鍵証明書を生成し、該公開鍵証 明書が該送信ステップよりも前に検証される、請求項１または請求項２に記載の 方法。 ４．前記送信ステップよりも前に、前記公開鍵証明書が、前記証明機関の記憶さ れた公開鍵で検証される、請求項３に記載の方法。 ５．前記記憶された公開鍵を取り出すステップが、前記公開鍵証明書を復号化す るステップと、該復号化された公開鍵証明書を該記憶された公開鍵と比較するス テップとを含む、請求項３または４に記載の方法。 ６．前記集積回路カードの公開鍵およびプライベート鍵が、非対称技術を用いて 提供される、前記請求項のいずれかに記載の方法。 ７．前記非対称技術がＲＳＡである、請求項６に記載の方法。 ８．カードについての個別化された鍵セットを用いることにより、集積回路カー ド上にデータを配送する方法であって、該方法は、 証明機関についての第１の固有のプライベート／公開鍵対を提供するステップ と、 該集積回路カード上に配置されたメモリ内の該集積回路カードについて該個別 化された鍵セットを形成する第２の固有のプライベート／公開鍵対を記憶するス テップと、 該第１の証明機関のプライベート鍵で該第２の公開鍵を暗号化して、公開鍵証 明書を形成するステップと、 該公開鍵証明書を集積回路カード上に記憶するステップと、 該記憶された公開鍵証明書を該集積回路カードから取り出すステップと、 該第１の公開鍵で該公開鍵証明書で検証して、該公開鍵証明書が有効であるこ とを確実にするステップと、 該取り出された第２の公開鍵を用いて該データの少なくとも一部分を暗号化す るステップと、 該暗号化されたデータを該集積回路カードに配送するステップと、 該第２のプライベートキーを用いて該暗号化されたデータを復号化して、該デ ータを取り出すステップと、 を含む方法。 ９．前記データがアプリケーションを含む請求項８に記載の方法。 １０．前記カードについての個別化された鍵セット(15,19)を用いることによっ て、集積回路カード(3)上にデータ(11)を配送するシステムであって、 該集積回路カードに固有のプライベート鍵／公開鍵対(15,19)を、該集積回路 カード上に配置されたメモリに記憶する手段と、 該記憶された公開鍵(15)を該集積回路カードから取り出す手段と、 取り出された公開鍵を用いて、該カード上に配送される該データの少なくとも 一部分を暗号化する手段と、 該暗号化されたデータを該集積回路カードに伝送する手段と、 該配送されたデータを回復するために、該集積回路カードのプライベート鍵を 用いて、該暗号化されたデータを復号化する手段と、 を含むシステム。 １１．前記復号化されたデータを前記集積回路カード上に記憶する手段をさらに 含む、請求項１０に記載のシステム。 １２．証明機関によってデジタル的に署名された前記集積回路カードの公開鍵を 含む公開鍵証明書であって、該公開鍵証明書が該カードに固有であり、かつ、該 カードに記憶された、公開鍵証明書をさらに含むシステムであって、該公開鍵証 明書を検証する手段をさらに含む、請求項１０または請求項１１に記載のシステ ム。 １３．前記検証を行う手段が、前記証明機関の記憶された公開鍵で公開鍵証明書 を検証する手段を含む、請求項１２に記載のシステム。 １４．前記公開鍵を取り出す手段が前記公開鍵証明書を復号化する手段を含み、 該復号化された公開鍵証明書を前記記憶された公開鍵と比較する手段をさらに含 む、請求項１２または請求項１３に記載のシステム。 １５．前記集積回路カードの公開鍵／プライベート鍵が、任意の非対称技術を用 いて提供される、前記請求項のいずれかに記載のシステム。 １６．前記非対称技術がＲＳＡである、請求項１５に記載のシステム。