(57)【要約】  少なくとも１つのアプリケーション（４６，４２）をスマートカード（３００）、特に多機能スマートカードにインストールする少なくとも１つのインストール権限を管理する管理システムと方法であって、アプリケーション、特にスマートカード（３００）上のアプリケーションをコントロールする少なくとも１つの第一者即ち第１ユニット、特にスマートカード発行者（１０）がこのアプリケーション管理（４４）を少なくとも１つの第二者即ち第２ユニット（２０）に移譲することができる管理システムと方法を提供するために、少なくとも１つの第三者即ち第３ユニット（３０）、特に少なくともひとつのサードパーティアプリケーション提供者にインストール権限（４０ａ）を行使すること、特に自身のアプリケーション（４２）をスマートカード（３００）上にインストールすることを認証する役割が、少なくとも１つの第一者即ち第１ユニット（１０）、特にスマートカードの発行者（３００）から、少なくとも１つの第二者即ち第２ユニットに委譲することが可能である限りにおいて、管理システム（１００）を、前記インストール権限（４０ａ）、特にスマートカード（３００）上の権限を管理するよう構成することを提案する。【選択図】図１
2008533547.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも1つのアプリケーション（４６、４２）をスマートカード（３００）、特に多機能スマートカード上にインストールするための、少なくとも１つのインストール権限（４０ａ）を管理する管理システム（１００）であって、
少なくとも１つの第三者即ち第３ユニット（３０）、特に少なくとも１つのサードパーティアプリケーション提供者に、前記インストール権限（４０ａ）を行使すること、特に自身のアプリケーション（４２）をスマートカード（３００）上にインストールすることを認証（２２）する役割が、少なくとも１つの第一者即ち第１ユニット（１０）、特にスマートカード（３００）の発行者から少なくとも１つの第二者即ち第２ユニットへ移譲（４４）可能である限りにおいて、前記インストール権限（４０ａ）を、特にスマートカード（３００）上のものを管理するよう構成されていることを特徴とする管理システム。
【請求項２】
支持される前記インストール権限（４０ａ）は、
アプリケーション（４２）依存であり、及び／又は
アプリケーション（４２）非依存であり、及び／又は
該インストール権限（４０ａ）が、スマートカード（３００）上において、少なくとも１つのデジタル証明書（４０ｂ）、特に第一者即ち第１ユニット（１０）によって提供される証明書の形式で実行され又は少なくとも表現されており、及び
管理システム（１００）が該デジタル証明書（４０ｂ）を管理するよう構成されていることを特徴とする、請求項１に記載の管理システム。
【請求項３】
アプリケーション管理（４０）の役割は、少なくとも１つの管理権付与アプリケーション（４６）が前記第二者即ち第２ユニット（２０）によって前記スマートカード（３００）上にインストールされると、すぐに前記第一者即ち第１ユニット（１０）から該第二者即ち第２ユニット（２０）に移譲されることを特徴とする、請求項１又は２に記載の管理システム。
【請求項４】
前記管理権付与アプリケーション（４６）がインストールされると、すぐに前記第二者即ち第２ユニット（２０）の少なくとも１つの公開鍵がインストール権限（４０ａ）の検証に使われるように管理システム（１００）が設計された少なくとも１つのアプリケーションを特徴とする請求項３に記載の管理システム。
【請求項５】
前記アプリケーション管理の役割（４０）は、前記管理権付与アプリケーション（４６）が削除及び／又はアンインストールされると、すぐに前記第二者即ち第２ユニット（２０）から前記第一者即ち第１ユニット（１０）に戻ることを特徴とする、請求項３又は４記載の管理システム。
【請求項６】
前記第二者即ち第２ユニット（２０）が、
前記スマートカード（３００）上に管理権付与アプリケーション（４６）として少なくとも１つの支払いアプリケーションをインストールした後に、前記アプリケーション管理（４０）の役割を得た支払い機関であり、及び／又は
該スマートカード（３００）上にすでにどのアプリケーションが存在するか識別可能であり、及び／又は
該スマートカード（３００）上ですでに利用可能な他のアプリケーションの少なくとも１つの個別アプリケーションコードのチェックが可能であり、及び／又は
該スマートカード（３００）上にすでに存在するアプリケーションに少なくとも１つの削除要求を開始できることを特徴とする、請求項１から５のいずれか１つに記載の管理システム。
【請求項７】
前記第一者即ち第１ユニット（１０）、及び／又は前記第二者即ち第２ユニット（２０）、及び／又は前記第三者即ち第３ユニット（３０）、及び／又は少なくとも１つのそれ以外の者即ちそれ以外のユニットが、前記スマートカード（３００）上の少なくとも１つのアプリケーションを削除及び／又はアンインストールすることができ、この削除及び／又はアンインストールの動作がユーザ（４００）によって確認されなければならないことを特徴とする、請求項１から６のいずれか１つに記載の管理システム。
【請求項８】
前記スマートカード（３００）上のあらゆる変化、特に該スマートカード（３００）上で生じるあらゆるインストール又は削除が、該スマートカード（３００）の前記ユーザ（４００）によって確認される必要があり、該ユーザ（４００）による確認が、特に前記管理システム（１００）によって実施されることを特徴とする、請求項１から７のいずれか１つに記載の管理システム。
【請求項９】
前記管理システム（１００）は、少なくとも１つのホスト端末（５００）を経由して少なくとも１つの確認要求（４８）を送り、かつ
該確認要求（４８）は前記スマートカード（３００）の前記ユーザ（４００）によって確認されなければならず、該確認要求（４８）は、
該ホスト端末（５００）の少なくともひとつのボタンを押す、若しくは
少なくとも１つのカード所有者認証プロセスを完了する、特に
少なくとも１つのＰＩＮ（Ｐｅｒｓｏｎａｌ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｎｕｍｂｅｒ：個人識別番号）の入力、及び／又は
少なくとも１つの生体的特徴を識別することにより完了されることを特徴とする、請求項８記載の管理システム。
【請求項１０】
請求項１から９のいずれか１つに記載の少なくとも１つの管理システム（１００）を特徴とする集積回路（２００）。
【請求項１１】
請求項１０記載の少なくとも１つの集積回路を特徴とするスマートカード（３００）、特に多機能スマートカード。
【請求項１２】
少なくとも1つのアプリケーション（４６、４２）をスマートカード（３００）、特に多機能スマートカード上にインストールするための、少なくとも１つのインストール権限（４０ａ）を管理する方法であって、
少なくとも１つの第三者即ち第３ユニット（３０）、特に少なくとも１つのサードパーティアプリケーション提供者に、前記インストール権限（４０ａ）を行使すること、特に前記スマートカード（３００）上に自身のアプリケーションをインストールすることを認証する役割が、少なくとも１つの第一者即ち第１ユニット（１０）、特に該スマートカード（３００）発行者から少なくとも１つの第二者即ち第２ユニットへ移譲（４４）可能である限りにおいて、前記インストール権限（４０ａ）を管理することを特徴とする方法。
【請求項１３】
請求項１１記載の多機能スマートカード（３００）上の柔軟で移譲可能なアプリケーション管理のために、請求項１から９のいずれか１つに記載の少なくとも１つの管理システム（１００）、及び／又は請求項１０記載の少なくとも１つの集積回路（２００）、及び／又は請求項１２記載の方法を使用する方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、スマートカード上に、特に多機能スマートカード上に、少なくとも１つのアプリケーションをインストールするための、少なくとも１つのインストール権限を管理する、管理システムと方法に関する。
【背景技術】
【０００２】
先行技術文献である特許文献１には、スマートカードキオスク向けのプログラミングインターフェースが開示されている。より詳細には、特許文献１は、スマートカードを所持するユーザと取引をするためのソフトウェアを、アプリケーション提供者や販売者がインストールすることができるいくつかのキオスクを記載している。このキオスクはこれらのアプリケーションに対し標準インターフェースを提供するため、ユーザの所持するスマートカードの種類によらず取引が可能になり、そのカード上のデータ構造を更新することができる。しかし、このプログラミングインターフェースはスマートカード上のアプリケーションに対する管理の委任には関連していない。
【特許文献１】国際公開第９７／１０５６２号パンフレット
【０００３】
安全にスマートカード内のコマンドを読み込む方法、特にスマートカード上で読み込みや実行しなくてはならないアプリケーションやコマンドを認証するための基本的な技術は、先行技術文献である特許文献２に開示されており、この技術では、２つの当事者双方がスマートカード上での実行を許可してよいアプリケーションについて同意しなくてはならない。特に、特許文献２は、例えばカード発行者と信頼できる第三者といった２つの独立した当事者にまずそのようなコマンドを承認させて認証コードを生成させることにより、どのようにしてコマンド及び／又はアプリケーションをスマートカード上に安全に読み込むかについて記載している。これら２つの当事者双方は、スマートカードの分野において公知である秘密鍵を保持しているので、スマートカードがコマンド実行前にそのコマンドやアプリケーションが本当にこれらの当事者達に承認されているか判定することができる。しかし特許文献２は１つの当事者がスマートカード上のアプリケーションをコントロールし、後でこのコントロールを第２の当事者に移譲することを可能にする機能について論じていない。
【特許文献２】欧州特許出願公開第０  ７９８  ６７３号明細書
【０００４】
先行技術文献である特許文献３は、発行後のスマートカード上へのアプリケーションダウンロードを開示している。特に、ここに記載の方法は、スマートカード発行後、特に耐用期間の間、カード発行者がアプリケーションを追加することを可能とする。アプリケーションはカードドメインと呼ばれる第２のアプリケーション経由でインストールすることができる。このように、ＧＰＯＰ（Ｇｌｏｂａｌ  Ｐｌａｔｆｏｒｍ／Ｏｐｅｎ  Ｐｌａｔｆｏｒｍ：グローバルプラットフォーム／オープンプラットフォーム）標準中でも規定される、いわゆるＳＤ（Ｓｅｃｕｒｉｔｙ  Ｄｏｍａｉｎ：セキュリティ領域）の基本機能が記載されている。しかし、特許文献３は管理委任、即ちカード発行者以外の誰かに発行後にアプリケーションをインストールさせることの可能性について論じていない。さらに、特許文献３はカード上にインストールされうるアプリケーションに関する管理の移譲にも関連しない。
【特許文献３】国際公開第９８／４３２１２号パンフレット
【０００５】
グローバルプラットフォーム／オープンプラットフォーム標準の範囲で、どのように委任管理が行われるかは先行技術文献である特許文献４に記載されている。委任管理とはカード発行者がネットワークにつながっていなくても、アプリケーション提供者自身が所有するアプリケーションを発行後にスマートカード上にインストールできるということを意味する。これと対照的に、これ以前のスマートカードシステムはアプリケーションの追加は発行者のみが可能であった。
【特許文献４】米国特許出願公開第２００２／００４０９３６号明細書
【０００６】
グローバルプラットフォームの仕様（非特許文献１を参照）は動的な多機能スマートカードのアーキテクチャと標準規格を規定する。グローバルプラットフォームの目的は、アプリケーションに対する販売者及びハードウェアから独立したインターフェース、並びにカードから分離した管理システムを提供することである。このグローバルプラットフォーム標準は、このような多機能カード管理システムを規定する、現在知られている唯一の（そして最も進んだ）標準である。グローバルプラットフォームでは、カード発行者はスマートカード上のアプリケーション管理に関して最も強力なコントロールを持つ。このカード発行者は、読み込み操作、インストール操作及び削除操作を実行することのできる、スマートカード上のカードマネージャへのマスターキーを持つ。
【非特許文献１】“グローバルプラットフォームコンソーシアム  カード仕様書  ２．１．１版”（ＧｌｏｂａｌＰｌａｔｆｏｒｍ  Ｃｏｎｓｏｒｔｉｕｍ，Ｃａｒｄ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ，  Ｖｅｒｓｉｏｎ２．１．１）、[ｏｎｌｉｎｅ]、２００３年３月、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｇｌｏｂａｌｐｌａｔｆｏｒｍ．ｏｒｇ／＞
【０００７】
グローバルプラットフォームは他のアプリケーション提供者がカード上にあるセキュリティ領域の鍵を取得することを可能にする。セキュリティ領域は鍵の取り扱い、暗号化、復号化等といった安全に関するサービスを所有者に対して提供する特別なアプリケーションであり、新しいアプリケーションをスマートカード上へ読み込み及びインストールするために、アプリケーション提供者によって利用される。アプリケーションはアプリケーション提供者のセキュリティ領域に関連付けられる。セキュリティ領域の鍵を持つアプリケーション提供者は、もしカード発行者に事前に承認されているなら、セキュリティ領域への安全なチャネルを設定し、自身のアプリケーションをインストールすることができる。これはグローバルプラットフォームにおける委任管理といわれる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
アプリケーションがインストール可能になる前に、アプリケーション提供者はカード発行者からインストールトークンを得なくてはならない。このトークン、即ち事前認証は、主なアプリケーションコードと許可された権限を固有に特定し、カード発行者によって電子的に署名されている。セキュリティ領域はこのトークンを、トークンを検証し実際のアプレット又はアプリケーションのインストールを行うカードマネージャに渡す。アプリケーション提供者には自分のセキュリティ領域に関連するアプリケーションを削除することが認められている。
【０００９】
グローバルプラットフォーム標準はさらにカード発行者以外の者にカード上にどのアプリケーションをインストールできるかを共に決定することを許容する。この者はＣＡＧＰ（Ｃｏｎｔｒｏｌｉｎｇ  Ａｕｔｈｏｒｉｔｙ  ｗｉｔｈｉｎ  Ｇｌｏｂａｌ  Ｐｌａｔｆｏｒｍ：グローバルプラットフォームにおけるコントロール局）と呼ばれる。このコントロール局は、カード上ではＣＡＳＤ（Ｃｏｎｔｒｏｌｉｎｇ  Ａｕｔｈｏｒｉｔｙ  Ｓｅｃｕｒｉｔｙ  Ｄｏｍａｉｎ：コントロール局セキュリティ領域）と呼ばれる特別なセキュリティ領域として表される。
【００１０】
ＣＡＳＤがスマートカード上にある場合には、新しいアプリケーションは、インストール可能になる前に、コントロール局から読み込んだファイル署名を付加的に伴っていなければならない。つまり、委任管理経由でインストールされるアプリケーション、特にアプリケーションプロバイダのセキュリティ領域経由のものは、発行者による読み込み及び／又はインストールトークンと、コントロール局によるアプリケーションコード上の署名との両方を伴わなければならない。それゆえに、発行者とコントロール局の双方はスマートカード上にアプリケーションがインストール可能になる前に、このアプリケーションを承認していなくてはならない。グローバルプラットフォーム仕様は多機能スマートカードのカード管理を扱う進歩的な方法を提供しているが、グローバルプラットフォームシステムには限界もある。例えば、グローバルプラットフォームは、支払機関が自身のアプリケーションをインストールし、アプリケーション管理機能を引継ぐようなシナリオをサポートしていない。アプリケーション管理とはスマートカード上にどのアプリケーションをインストールしてよいかを支配することである。
【００１１】
さらに、グローバルプラットフォームはアプリケーション提供者が求める任意のコードをインストールできるような柔軟な権限は許可していない。このようなアプリケーション非依存のインストール権限は、カード発行者が個々のアプリケーションごとに新しいインストール権を発行したくないような状況（このような状況は、多くのアプリケーション提供者全てがインストールしたいアプリケーションコードの複数のバージョンをもつ場合に、面倒な仕事となるだろう）で役立ちうる。
【００１２】
アプリケーション非依存のインストール権限は、例えばアプリケーション提供者は有害なコードをインストールしないことに当事者双方が同意した場合、アプリケーション提供者に対して発行されうる。つまりサードパーティアプレットの正しい動作は合法的に施行される。
【００１３】
上に述べた不利益と欠点にはじまり、議論した先行技術文献を考慮すると、この発明の目的は、技術分野の項で説明したような種類の管理システムと技術分野の項で説明したような方法をさらに発展させることであり、スマートカード上のアプリケーションをコントロールする少なくとも１つの第一者即ち第１ユニット、特にスマートカード発行者が、このコントロールを少なくとも１つの第二者即ち第２ユニットに移譲することができるようにしている。
【課題を解決するための手段】
【００１４】
この発明の目的は請求項１の特徴を含む管理システム及び請求項１２の特徴を含む方法により達成される。この発明の有利な実施態様と適切な改良は請求項１の従属項に開示されている。
【００１５】
この発明は主に移譲可能なアプリケーション管理の考えに基づいている。即ちスマートカード上のアプリケーションをコントロールする第１ユニット即ち第一者を有し、後からこの制御を少なくとも１つの第２ユニット即ち第二者へ移譲可能とする機能を含む。
【００１６】
このように、スマートカード上にどのアプリケーションのインストールを許可するかのコントロールが第一者即ち第１ユニットから第二者即ち第２ユニットに移譲される範囲において、この発明による管理システムは、従来の管理システムに比べはるかに柔軟な方法でアプリケーション管理を取り扱う。第一者即ち第１ユニット、特にスマートカードの発行者は、例えばスマートカード上にどのアプリケーションをインストールできるかについての完全なコントロールを特定の当事者に引き継がせる。
【００１７】
この発明の好ましい実施態様では、この種のアプリケーション管理は、第一者即ち第１ユニットに少なくとも１つのデジタル証明書（デジタル証明書の詳細は下記の“図面の簡単な説明”の項で詳細に述べる。）の形式で少なくとも1つのインストール権限を提供させることにより達成される。
【００１８】
有利には、新しいアプリケーションがインストールされた際、これらのインストール権限は、第一者即ち第１ユニットのカード上での代理、特にカード発行者のカード上での代理であるマネジメントシステム又はカードマネージャによって判定される。
【００１９】
さらに好適な実施態様では、例えば少なくとも１つの支払いアプリケーションのように、少なくとも１つの管理権付与アプリケーションをインストールするための、少なくとも１つの特別な種類のアプリケーションスロットを実装することが提案される。これによって、例えば支払い機関のような第２ユニットが第一者即ち第１ユニットから適切なインストール権限を取得している場合に、第２ユニットが例えば支払いアプレットのような自身の管理権付与アプリケーションをインストールできるという利点が導かれる。この管理権付与アプリケーションがインストールされるとすぐに、管理システム、特にカードマネージャは、第一者即ち第１ユニットの公開鍵の代わりに第２ユニットの公開鍵をインストール権限の検証に利用するようになる。
【００２０】
さらに、好ましい実施態様では、この管理権付与アプリケーションが削除されると、この管理システムはインストール権限検証用の鍵を第一者即ち第１ユニットの公開鍵へと戻す。
【００２１】
このアプリケーション管理を引継ぐ能力は、例えば第２ユニットがスマートカード上に不正使用を防がなくてはならない重要なアプリケーションをインストールし、第２ユニットにスマートカードの取引責任が移るような状況で役に立つ。この場合、第２ユニットは、他のアプリケーションをスマートカード上にインストールしてよいかかどうかの基となる、強化されたコントロールを要求する。この特徴は次の状況に例示される。支払い機関は、管理権付与アプリケーションがカード上にインストールされるとすぐに、スマートカードを使った経済取引に対して責任を持つ。この支払い機関は、有害の可能性がある（支払いアプレットを不正使用できる）コードがスマートカードに進入するのを防止するために、他のどのアプリケーションをインストールしてよいかをコントロールしたい。従来のグローバルプラットフォーム／オープンプラットフォームのようなシステムでは、あるアプリケーションがスマートカード上にインストール可能になる前に、署名の提供を必須とするコントロール局を有効にすることが可能であった。しかしながら、発行者からの読み込みトークン及び／又はインストールトークンは依然として同様に要求される。つまりこれは単にアプリケーション提供者が取得すべき特別な権限に過ぎない。これに対して、この発明はアプリケーション管理を支払い機関のようなコントロール局に対して完全に移譲することを可能にする。従来のカード管理システムでは、支払い機関は通常スマートカードをコントロールできるカード発行者であった。この発明によりカード発行者が例えば支払い機関である第２ユニットから独立してスマートカードを発行することが可能になる。
【００２２】
さらに、この発明の好ましい実施態様では、第２ユニットは管理権付与アプリケーションを、たとえ他の第三者アプリケーションがインストールされた後であっても、後からインストールすることができる。この場合、第２ユニットは他のどのアプリケーションがすでにスマートカード上に存在しているのかを判定できる必要がある。有利な実施態様では、第２ユニットは、例えば少なくとも１つの中央サーバで判定できるアプリケーション識別子とアプリケーション提供者識別子を検索することができるか、インストールされたアプレット又はアプリケーションの正確なアプリケーションコードを読み出すことができる。このオプションは管理システムによって提供されるのが好ましく、随意に土台となるオペレーティングシステムによってサポートされてもよい。
【００２３】
第２ユニットがスマートカード上に第２ユニットが信頼しないサードパーティアプリケーションを発見した場合には、第２ユニットは例えば支払いアプレットをインストールしない。このような場合、好ましい実施態様によれば、第２ユニットはすでにスマートカード上に存在するアプリケーション、特に信頼できないアプリケーションに対して、少なくとも１つの削除要求を発生することができる。しかし、この発明の有効な改良によると、第一者即ち第１ユニットのアプリケーションは第一者即ち第１ユニットしか削除することができない。
【００２４】
この発明のさらに好ましい実施態様では、スマートカード第一者即ち第１ユニット、及び／又はスマートカード第二者即ち第２ユニット、及び／又はスマートカード第三者即ち第３ユニット及び／又は、少なくとも１つのスマートカードのそれ以外の者即ちそれ以外のユニットは、スマートカード上に存在する少なくとも１つのアプリケーションを削除及び／又はアンインストールすることを許可されており、随意にこの削除及び／又はアンインストールの動作はユーザが確認しなれければならない。
【００２５】
ユーザの観点では、ユーザにどのアプリケーションを彼又は彼女のスマートカードで利用するかについて決定権を与えることは好ましい。従って、この発明の有利な実施態様では、カードのあらゆる変更、特にスマートカード上で生じるいかなるインストール又は削除をもユーザに確認させることが提案されている。
【００２６】
さらに、この発明の好ましい実施態様では、要求されるカードの変更の際、管理システムが少なくとも１つの確認要求をユーザに送ることにより、ユーザによる確認の手配をしている。このような要求は、好ましくは少なくとも１つのスマートカード読取装置を経由して、少なくとも１つのユーザのホスト端末に送られる。
【００２７】
有利な実施態様では、利用者は、例えばホスト端末の少なくとも１つのボタン又はキーを押す、及び／又は端末のＰＩＮ（Ｐｅｒｓｏｎａｌ  Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｎｕｍｂｅｒ：個人識別番号）を入力することにより、及び／又は少なくとも１つの生体的特徴によって識別することにより、カードの変化を確認することができる。後者の形式は、意図したユーザしか動作が行えないため、より安全である。
【００２８】
この発明はさらに、少なくとも１つの上記管理システムを含む及び／又は上記方法により操作される集積回路にも関する。
【００２９】
さらにこの発明はスマートカード、特に、少なくとも１つの上記ＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ：集積回路）を含む多機能スマートカードに関する。最後に、この発明は、少なくとも１つの上記管理システムの使用、及び／又は少なくとも１つの上記集積回路の使用、及び／又は上記多機能スマートカードの柔軟で移譲可能なアプリケーション管理の上記方法の使用に関する。
【００３０】
すでに上述したように、有利なやり方でこの発明の教示を具体化及び改良するいくつかの選択肢が存在する。この目的のために、請求項１の従属項が参照される。この発明の更なる改良、特徴及び利点は、例示的な好ましい実施態様と、添付の図を参照しつつ、以下に詳細に説明される。
【００３１】
図１はこの発明の管理システムの一実施態様と、この発明の方法の工程を概略的に示す。この例示的実施態様は、従来の多機能スマートカードが、カード発行者１０に、どのアプリケーションをユーザ４００のスマートカードにインストールしてよいかをコントロール可能にするカード管理システムを採用しているという問題から始まる。しかし、このシステムはその他の（承認された）者がアプリケーション管理機能を引継ぎ可能でなくてはならないビジネスモデルをサポートするのに十分柔軟ではない。
【００３２】
このような機能は、例えば支払い機関が自身の支払いアプレットをスマートカード３００にインストールして、このスマートカード３００を使った経済取引に責任を持つようになる状況で望まれる。この場合、支払い機関２０は、有害な可能性のあるコードを防止する上で、自身の支払いアプリケーション４６以外に、他のどのアプリケーション４２の実行を許可するかをコントロールすることを望む。
【００３３】
この発明では、このようなビジネスモデルを可能にするための証明書４０ｂに基づく柔軟なカード管理システム１００が提案されている。図１はこのような多機能スマートカード３００上で柔軟かつ移譲可能なアプリケーション管理をするための管理システム１００と、スマートカード３００上に設置され管理システム１００を含む集積回路２００の、第１の実施態様を示す。
【００３４】
第一者即ち第１ユニット、即ちスマートカード発行者１０が、１又は複数のインストール権限４０ａを、他の当事者２０、３０、特に第二者即ち第２ユニット、即ち支払い機関２０と、第三者即ち第３ユニット、即ちサードパーティアプリケーション提供者３０に発行する。図１に示される例の場合、スマートカード発行者１０は前記インストール権限４０ａを支払い機関２０に発行する。そしてこの支払い機関２０はこのインストール権限４０ａをスマートカード３００に提示し、ここでカード管理システム（いわゆるカードマネージャ１００）が権限を解釈及び検証できる。この解釈及び検証のために、管理権付与アプリケーション、即ち支払いアプリケーション４６をスマートカード３００上にインストールすることが認められている。
【００３５】
この管理システム１００は、１又はそれ以上のアプリケーション提供者３０にそれぞれ自身のアプリケーション４２をスマートカード３００にインストールすることを承認（図１の参照番号２２を参照）する役割が、スマートカード発行者１０から支払い機関２０に委譲（図１の参照番号４４参照）できる限りにおいて、スマートカード３００に関する前記インストール権限４０ａを管理するように設計されている。
【００３６】
このアプリケーション管理４０の移譲４４は、インストール権限４０ａがスマートカード発行者１０に残らず、スマートカード発行者１０から支払い機関２０に移っている限りにおいて、図１から取り除くことができる。結果として、現在このアプリケーション管理４０に責任があるこの支払い機関２０が、サードパーティアプリケーション提供者３０にインストール権限４０aを行使することを承認（図１の参照番号２２参照）することができる。
【００３７】
これに関連して、前記支払い機関２０によって支払いアプレット４６がスマートカード３００上にインストールされると、すぐにアプリケーション管理４０の役割はスマートカード発行者１０から支払い機関２０に委譲される。このように、支払い機関２０が自身の支払いアプリケーション４６をインストールした後に、支払い機関はインストール権限４０aを第三者即ちアプリケーション提供者３０に対し発行することが可能になる（図１の参照番号２２参照）。アプリケーション提供者３０は、自身のアプリケーション４２をインストールするために、前記インストール権限４０aをスマートカード３００に提供することができる。
【００３８】
管理権付与アプリケーション４６がスマートカード３００から削除及び／又はアンインストールされると、すぐに、例えば安全上の理由及び／又はカードアプリケーション管理４０のコントロールの理由から、アプリケーション管理４０の役割は支払い機関２０からカード発行者１０に戻る（図１の参照番号５４参照）。
【００３９】
この管理システム１００はアプリケーション依存のインストール権限もアプリケーション非依存のインストール権限４０aもサポートし、このときインストール権限４０ａはスマートカード発行者１０から提供されるデジタル証明書４０ｂの形でスマートカード３００上に実装又は表現される。次に、このようなデジタル証明書によっていかに柔軟にインストール権限４０ａを作ることができるかを説明する。
【００４０】
基本的に、デジタル証明書４０ｂは作者から電子署名と共に提供されるメッセージ又は記述である。署名者は典型的にはメッセージ全体のハッシュに対し秘密鍵を使って暗号化することによって、このような電子署名を作成する。誰もが署名者の公開鍵を使って含まれるハッシュ値を検索し、このハッシュ値とメッセージから自己生成されるハッシュ値を比較することで、この署名を検証することができる（デジタル証明書の詳細はＢ．Ｓｃｈｎｅｉｅｒ、“応用暗号  第２版”（Ａｐｐｌｉｅｄ  Ｃｒｙｐｔｏｇｒａｐｈｙ、Ｓｅｃｏｎｄ  ｅｄｉｔｉｏｎ）、１９９６年を参照）。
【００４１】
この発明では、アプリケーション４２、４６のスマートカード３００上へのインストールを承認するインストール権限４０ａは、以下に示す特定のフィールドを持つデジタル証明書４０ｂを定義することで作ることができる。
【００４２】
Ｃ［ｄＡＭ］｛Ｔｙｐｅ，  Ｄａｔａ，  Ｖａｌｉｄ，  ｅＡＭ，  ＡｐｐＩＤ，  ＣｏｄｅＩＤ，  ｅＡＰ，  Ｔａｒｇｅｔ，  Ｏｐｔｉｏｎｓ｝      （１）
【００４３】
この構造は、カード発行者１０か支払い機関２０のどちらか一方であるアプリケーション管理者の秘密鍵ｄＡＭによって署名された、証明書４０ｂを示す。この証明書４０ｂは以下のフィールドを含む。
【００４４】
Ｔｙｐｅ：証明書の種類を表す。Ｔｙｐｅはサードパーティアプリケーション提供者へのインストール権限４０ａ（例えばＴｙｐｅ＝ＩＲ）か、支払い機関へのインストール権限４０ａ（例えばＴｙｐｅ＝Ｐａｙ）どちらかを示す。
【００４５】
Ｄａｔｅ：証明書の発行日を示す。
【００４６】
Ｖａｌｉｄ：証明書の有効期限又は有効期間を示す。
【００４７】
ｅＡｍ：証明書発行者であるアプリケーションマネージャ１０、２０の公開鍵を示す。
【００４８】
ＡｐｐＩＤ：インストールされるアプリケーション４２、４６の固有識別子を示す。この値はアプリケーション依存のインストール権限（例えばＡｐｐＩＤ＝０）に関することを示すためにも使うことができる。
【００４９】
ＣｏｄｅＩＤ：インストールされるアプリケーション４２、４６のコードを識別する識別子を示す。このＣｏｄｅＩＤはアプリケーションコードにハッシュ関数を適用することにより生成されるのが望ましい。
【００５０】
ｅＡＰ：アプリケーション提供者２０又は３０の公開鍵を示す。これはアプリケーション提供者２０又は３０とカードマネージャ又は管理システム１００との間に安全な通信経路を設定するときに使われる。
【００５１】
Ｔａｒｇｅｔ：どのスマートカード３００にインストール権限４０ａを適用するかを示す。スマートカード識別番号のセットをここに示すことができる。あるいは、インストール権限４０ａが全てのスマートカード３００に対して有効であるということ（Ｔａｒｇｅｔ＝Ａｌｌ）を示すこともできる。
【００５２】
Ｏｐｔｉｏｎｓ：いくつかの他の証明書オプションを示すための領域。例えば証明書の失効（例えばオンライン失効サーバの名前）はこのＯｐｔｉｏｎｓフィールドに表示できる。
【００５３】
以下に、柔軟なカード管理システム１００で供給されるインストール権限４０ａのいくつかの例を示す。
【００５４】
最初に、サードパーティアプリケーションに対するインストール権限のいくつかの例を説明する。
【００５５】
公開鍵ｅＡＰ１をもつサードパーティアプリケーション提供者３０に、アプリケーション識別子ＡＰ１Ａ１をもつアプリケーション４２のインストールを許可するインストール権限４０ａは以下のとおりである。
【００５６】
Ｃ［ｄＩｓｓｕｅｒ］｛Ｔｙｐｅ＝ＩＲ，  Ｄａｔｅ＝０５−１０−２００３，  Ｖａｌｉｄ＝ｔｉｌｌ  ２００４，  ｅＡＭ＝ｅＩｓｓｕｅｒ，  ＡｐｐＩＤ＝ＡＰ１Ａ１，  ＣｏｄｅＩＤ＝２８２６４４６５２７１１８２，  ｅＡｐ＝ｅＡＰ１，  Ｔａｒｇｅｔ＝（０１４４２３−０１４５２０），  Ｏｐｔｉｏｎｓ｝      （２）
【００５７】
このインストール権限４０ａはカード発行者１０により発行され、シリアル番号が０１４４２３から０１４５２０で、支払いアプリケーション４６がインストールされていないスマートカード３００上へのインストールを可能にする。例えばこの中の１つのスマートカード３００がＶＩＳＡ（Ｒ）の支払いアプレットを持っているとき、ＶＩＳＡ（Ｒ）（支払い機関２０のような機能）はこのようなインストール権限４０ａに署名しなくてはならず、証明書は下記のようになる可能性がある。
【００５８】
Ｃ［ｄＶＩＳＡ］（Ｔｙｐｅ＝ＩＲ，  Ｄａｔｅ＝０５−１０−２００３，  Ｖａｌｉｄ＝１  ｙｅａｒ，  ｅＡＭ＝ｅＶＩＳＡ  ，  ＡｐｐＩＤ＝ＡＰ１Ａ１，  ＣｏｄｅＩＤ＝２８２６４４６５２７１１８２，  ｅＡＰ＝ｅＡＰ１，  Ｔａｒｇｅｔ＝Ａｌｌ，  Ｏｐｔｉｏｎｓ）      （３）
【００５９】
このようなインストール権限４０ａはアプリケーション識別子とコード識別子の指定を省略することにより、アプリケーション非依存にすることができる。この例を以下の証明書で示す。
【００６０】
Ｃ［ｄＶＩＳＡ］｛Ｔｙｐｅ＝ＩＲ，  Ｄａｔｅ＝０５−１０−２００３，  Ｖａｌｉｄ＝１  ｙｅａｒ，  ｅＡＭ＝ｅＶＩＳＡ，  ＡｐｐＩＤ＝０，  ＣｏｄｅＩＤ＝０，  ｅＡｐ＝ｅＡＰ１，  Ｔａｒｇｅｔ＝Ａｌｌ，  Ｏｐｔｉｏｎｓ｝      （４）
【００６１】
次に、支払い機関４６のインストール権限４０ａの例を示す。
【００６２】
カード発行者１０は、支払い機関２０が自身の支払いアプレット４６をインストールしてこのスマートカード３００上のアプリケーション管理を引継ぐ（参照番号４４参照）ことを可能にする、特別なインストール権限４０ａを発行できる。次の例では、ＶＩＳＡ（Ｒ）（公開鍵ｅＶＩＳＡで特定される）が権限４０ａを与えられ、支払いアプレット４６をインストールし、アプリケーションマネージャになっている。
【００６３】
Ｃ［ｄＩｓｓｕｅｒ］｛Ｔｙｐｅ＝Ｐａｙ，  Ｄａｔｅ＝０２−０８−２００３，  Ｖａｌｉｄ＝ｔｉｌｌ  ２００５，  ｅＡＭ＝ｅＩｓｓｕｅｒｒ，  ＡｐｐＩＤ＝０，  ＣｏｄｅＩＤ＝０，  ｅＡＰ＝ｅＶＩＳＡ，  Ｔａｒｇｅｔ＝Ａｌｌ，  Ｏｐｔｉｏｎｓ｝      （５）
【００６４】
このインストール権限４０ａを受けると、カードマネージャは（カードマネージャが公開鍵を知っている）カード発行者１０からの署名をチェックし、支払い期間２０とのＳＡＣ（Ｓｅｃｕｒｅ  Ａｕｔｈｅｎｔｉｃａｔｅｄ  Ｃｈａｎｎｅｌ：安全認証済みチャネル）を設定する。この証明書の中で示される公開鍵ｅＶＩＳＡはこのようなＳＡＣを設定するために使われる。このＳＡＣ上で、ＶＩＳＡ（Ｒ）は自身の支払いアプリケーション４６をインストールし、公開鍵を、その後インストール権限４０ａを検証するために必ず使われるカードマネージャに伝える。あるいは、公開鍵ｅＶＩＳＡをこの目的に使う。
【００６５】
スマートカード３００上のこの管理システム又はカードマネージャ１００は、カード発行者１０の公開鍵ｅｉｓｓｕｅｒを知っているので、証明書を検証できる。そして発行者１０の秘密鍵ｄｉｓｓｕｅｒで署名された証明書がチェックされる。上記権限４０ａは支払い機関２０に自身のアプリケーション４６をインストールすることを許可する。このときから、カードマネージャ１００は、支払い機関２０の公開鍵（この例ではｅＶＩＳＡ）をメモリ上に保存する。
【００６６】
このとき、この公開鍵は、上記で説明したラベル（２）及び（３）を付した権限のように、ＶＩＳＡ（Ｒ）により発行されたインストール権限４０ａをチェックする単に使うことができる。ＶＩＳＡ（Ｒ）のアプレットが取り除かれるとすぐに、カードマネージャ１００は公開鍵ｅＶＩＳＡを削除し、そしてインストール権限４０ａをカード発行者１０の公開鍵ｅｉｓｓｕｅｒを使ってチェックする。
【００６７】
スマートカード３００上で生じる任意のこのような削除又はインストールはスマートカード３００のユーザ４００によって確認される必要がある。この目的のために、管理システム１００はスマートカード３００のユーザ４００のホスト端末５００に確認要求４８を送る。
【図面の簡単な説明】
【００６８】
【図１】この発明に従う管理システムの実施態様とこの発明に従う方法の作用を概略的に示す。
【符号の説明】
【００６９】
１００ カードマネージャ又はカード管理システム
１０  スマートカード３００上の少なくとも１つのアプリケーションをコントロールする第一者即ち第１ユニット、特にスマートカード３００の発行者 
２０  第二者又は第２ユニット、特に支払い機関
２２  第三者又は第３ユニットがスマートカード３００に自身のアプリケーション４２をインストールすることの承認、特に第三者即ち第３ユニットへのインストール権限４０ａの発行
３０  第三者即ち第３ユニット、特にサードパーティアプリケーション提供者
４０  アプリケーション管理 
４０ａ  インストール権限
４０ｂ  デジタル証明書、 特にスマートカード３００上のインストール権限４０ａを表す。
４２  アプリケーション、特に第三者即ち第３ユニットのアプリケーション 
４４  第一者即ち第１ユニットから第二者即ち第２ユニットへの認証２２の役割及び／又はアプリケーション管理４０の役割の移譲
４６  管理権付与アプリケーション、特に支払いアプリケーション
４８  確認要求
５４  第二者即ち第２ユニット２０から第一者即ち第１ユニットへの認証２２及び／又はアプリケーション管理２２の返還 
２００  集積回路
３００ スマートカード, 特に多機能スマートカード 
４００ ユーザ
５００  ホスト端末
【図１】
2008533547.tif 000003
【国際調査報告】
2008533547.tif 000004
2008533547.tif 000005
2008533547.tif 000006