JP2013065340A - リトリーブ可能なトークン（例えば、スマートカード）内の独立した実行環境におけるアプリケーション間のセキュリティで保護されたリソース共有 - Google Patents

Abstract

【課題】独立した実行環境におけるアプリケーション間のセキュリティで保護されたリソース共有を可能にし、さらに関連する装置と強化されたスマートな通信を可能にしたリトリーブ可能なトークンを提供する。
【解決手段】リトリーブ可能なトークンは、少なくとも１つの装置に対する少なくとも１つの物理通信チャネルと、前記少なくとも１つ装置に対する少なくとも２つの論理通信チャネルを有し、前記２つの論理通信チャネルに関連する２つの実行環境を同時に実行するように構成され、前記２つの実行環境はそれぞれのアプリケーションを実行し、前記それぞれのアプリケーションはリソースを共有する。
【選択図】図２

Description

本発明は、サービスを提供する受信装置の中に導入される集積回路カードなどの、認証および／または権利を含むトークンに関し、そのような受信装置は、サービスを提供する前に、トークンの中に格納されている多くの権利の認証または読み取りを要求する。

そのようなトークンとは、例えば、クレジットカード、ＳＩＭカード、プリペイドカード、あるいはカード形状またはスティック形状であることが可能なＵＳＢ認証トークンである。

集積回路カード（ＩＣカードまたは「スマートカード」）は、アプリケーションに対して強化されたセキュリティおよびプライバシーの機能を提供するのに理想的に適している、本来的にセキュリティで保護されたコンピューティングプラットフォームである。また、ＩＣカードは、ユーザ加入データ、ユーザ秘密キー、およびその他の秘密データまたは機密データを格納する場所として、無線電話機、およびその他の通信装置においても使用されている。

ＩＣカードは、秘密キーとキー要素、アカウント番号と値、パスワードと共有秘密、承認と許可などの、機微な情報のためのセキュリティで保護された格納ファシリティおよびコンピュータ設備のための手段を提供する。

同時に、それらのＩＣカード、およびその他のトークンの多くは、敵対敵なコード（ウイルス、トロイの木馬など）からの潜在的な危険にさらされているホスト環境内で、その情報を露顕させることなしに使用することができる、孤立した処理ファシリティを提供する。これは、秘密キーを使用しての、個人的身元証明のためのデジタル署名の生成、共有される秘密に基づくネットワーク認証、値の電子的表現の保持、オフライン状況において使用するためのポータブルな許可など然るべき操作にとって極めて重要となる。

現在のＩＣカードは、非同期プロトコルが使用されており、ＡＰＤＵコマンドが、アプリケーションレベル情報を伝送する、ＩＳＯ７８１６標準において定義された通信プロトコルを使用する。また、このプロトコルは、移動電話機においても使用されており、ＧＳＭ標準および３ＧＰＰ標準が、このプロトコルに準拠する。

今日、新たなＩＣカードに組み込まれている、さらなる、より迅速な同期通信プロトコルが存在する。これにより、ＩＳＯ７８１６通信プロトコルと並行した、同期通信プロトコル（例えば、ＵＳＢ、またはその他）の追加が可能になる。各通信チャネルは、異なるピン接点セットを使用するので、この２つのプロトコルの間で相互依存関係は、全く存在しない。

今日、無線ハンドセット、または他の任意の通信デバイスなどの、ＩＣカードをホストしている端末装置は、異なる計算サービスを呼び出す、またはデータの取り出しを生じさせる、特定のコマンド（ＡＰＤＵコマンドと呼ばれる）を送ることにより、ＩＣカードサービスを使用する。サービス、またはデータの取り出しは、要求を実行し、必要とされているデータを戻すＩＣカードアプリケーションによって実行される。

新たなカードは、カードの異なるピン接点セット上に追加の、独立した通信プロトコル（例えば、ＵＳＢ）を組み込む。その場合、カードは、その２つの通信チャネルを２つの独立したプロセスによって管理する。

本発明の目的は、リトリーブ可能なトークンが、関連する装置と強化された通信を有することを可能にする、すなわち、外部世界とのよりスマートな通信を可能にすることである。

本発明の別の目的は、リトリーブ可能なトークンのリソースのより効率的な使用を可能にすることである。

以上の目的で、本発明によれば、添付の特許請求の範囲に記載されるリトリーブ可能なトークンが提案される。

本発明のその他の特徴および利点は、添付の図面に関連して解釈される、以下の説明から明白となろう。

本発明によるＩＣカード内の環境構成を示す概略図である。 本発明によるＩＣカード内のファイルの構成を示す概略図である。 本発明の特定の実施形態におけるアプリケーションの協働の実施例を示す図である。

図１に示されるとおり、次の２つの仮想実行環境、または論理実行環境に関連して、ＩＣカードを以下に説明する。すなわち、このケースでは、ＡＰＤＵ実行環境１００である第１の実行環境、および以降、「新たな実行環境」２００と呼ばれる第２の実行環境である。

より一般的には、リトリーブ可能なトークンは、少なくとも１つの物理通信チャネルをホストすることができ、少なくとも１つの論理通信チャネルが開かれることが可能なスマートカード、または任意のセキュリティで保護されたリトリーブ可能なトークンであることが可能である。

一般的な意味によれば、実行環境は、所与のアプリケーションを実行するためにＩＣカード内で所与の時点で使用される、基礎にあるプログラムセットおよび／またはパラメータセットとして理解される。

そのような実行環境には、オペレーティングシステムが含まれることも、含まれないことも可能である。例えば、実行環境は、所与のオペレーティングシステムに適用されるパラメータセットに主に存することが可能であり、そのパラメータセットは、実行環境ごとに異なる。

しかし、実行は、所与のオペレーティングシステムを指定することに限定されない。

また、実行環境は、他の点では普通のオペレーティングシステムより上に位置する特定のプログラムセットを含むという事実に起因して、特定的であることも可能である。

「ＡＰＤＵ実行環境」１００は、すべての既存の標準が適用される既存の（レガシな）実行環境である。例えば、ＳＩＭカードの場合、「ＡＰＤＵ実行環境」１００は、カードが、ネットワーク認証、ＳＩＭツールキットアプリケーション、その他のために実施するアプリケーションおよびサービスを定義するすべての標準に関わる。

「新たな実行環境」２００は、古い実行環境（「ＡＰＤＵ実行環境」）とは独立であり、古い実行環境とは全く通信を有さない。これは、現在のカードアプリケーションが影響を受けないことを確実にするために重要である。

このケースでは、両方の実行環境共にセキュリティで保護されている。

一般的な下位互換性の必要性は、これら２つの実行環境１００および２００におけるアプリケーションの間で分離（ファイアウォール処理）を課す。

「新たな実行環境」２００は、「ＡＰＤＵ実行環境」１００の場合と同様に、いくつかのアプリケーションの実行を可能にすることができる。新たな実行環境２００のアプリケーションに関する例が、いくつかのＷｅｂアプリケーションを統合することができるＷｅｂサーバである。

「新たな実行環境」２００は、「ＡＰＤＵ実行環境」におけるレガシなアプリケーションとは独立した新たなアプリケーションセットを実施することができる。しかし、カード発行者は、レガシな環境（「ＡＰＤＵ実行環境」）の挙動に干渉しない、あるレベルのデータ共有およびオペレーティングシステムサービスを可能にすることを所望する可能性がある。

好ましい実施形態では、異なる環境１００および２００の下で実行されているアプリケーションが、セキュリティで保護された形でデータを交換する。

また、これら２つの実行環境におけるアプリケーション間の通信プロトコルも、セキュリティで保護されたデータ共有または関数共有を可能にするために実施されることが可能である。

より一般的には、共有されるリソースは、前記２つのアプリケーションの少なくともいずれかによって使用されることが可能なデータを担持し、そのデータは、許可されていないエンティティによるアクセスから保護されている。

この原理は、２つより多くのプロトコルスタックに拡張されることが可能である。リトリーブ可能なトークンが、２つだけの物理レイヤを有する場合でも、それらの物理レイヤが、いくつかのプロトコルスタックの間で共有されることが可能である。

特定のケースでは、物理レイヤは、いくつかの論理チャネル（または「パイプ」）のためのサポートを提供することができる。したがって、その概念を説明すると、ＵＳＢプロトコルが、同一の物理媒体上で、いくつかの論理パイプ（エンドポイント）をサポートすることができる。一部の論理パイプは、あるプロトコルスタックに専用であることが可能であり、他の一部は、別のプロトコルスタックに専用であることが可能である。この概念が、ＵＳＢ環境内で「複合デバイス」と名付けられる。

論理チャネルまたは仮想チャネルは、ユーザには、特定のデータチャネルとして現れるが、この現れる論理チャネルとは非常に異なる物理的手段に基づいて実施されることが可能である。論理チャネルを構成する真の手段は、物理チャネルと呼ばれる。それらの真の手段は、現れる論理チャネルとは完全に異なることが可能である。

同一のＵＳＢコネクタを介して、ホストは、いくつかのタイプのデバイス（例えば、マウス、キーボード）を管理することができる。現在のＩＣカードは、物理通信チャネルの数とは独立した、少なくとも２つの論理通信チャネルをホストすることができる。

ＵＳＢインタフェースをホストすることができるＩＣカードに適用された概念は、本発明を利用することができる。ＵＳＢレイヤを介して、例えば、ＴＣＰ／ＩＰスタックおよび大容量ストレージスタックのカードレベルにおけるホストを想像することができる。

このＵＳＢ通信に加えて、スマートカードは、通常のＩＳＯ７８１６プロトコルを使用して、別の通信リンクを確立する。この実施例は、少なくとも３つの異なるプロトコルスタックが、同一のスマートカード内で実行されることが可能であることを示す。したがって、本発明は、各々の特定の文脈において、アプリケーションが、異なるプロトコルスタックを実行している実行環境間の、セキュリティで保護され、制御されたブリッジを確立することができる場合に適用可能である。

したがって、本発明は、ＩＳＯ７８１６プロトコルを実行しているが、複数の論理チャネル、あるいはマルチメディアカードまたはドングル（例えば、ＵＳＢドングル）と併せて、スマートカード内にて有用に使用されることが可能である。

また、本発明は、独立した物理通信チャネルと論理通信チャネルの組合せを有する能力をよく示す、以下のシナリオにも適用されるが、このシナリオには限定されない。すなわち、
１つのＵＳＢ通信チャネルを有し、いくつかの論理チャネル（「パイプ」）と共に、ＡＰＤＵコマンドが、１つの論理チャネル上で送られて、レガシなアプリケーションにアドレスし、ＴＣＰ／ＩＰプロトコルスタックが、その他の論理チャネル上で実行されるリトリーブ可能なトークン。
異なる孤立した実行環境に各々が連携している、１つまたは複数の物理チャネルまたは論理チャネルを有するリトリーブ可能なトークン。物理通信チャネルは、以下の実施例であることが可能であるが、これらの実施例には限定されない。すなわち、
マルチメディアメモリカード（ＭＭＣ）プロトコル
ＳＰＩ（シリアル周辺インタフェース）プロトコル
ＵＳＢプロトコル
スマートカード非接触プロトコル
ＩＳＯ７８１６プロトコル
ＩＳＯ（ＦＣＤ）１５６９３プロトコル
ＩＳＯ１４４４３プロトコル
ＴＳ１０２．２２１標準において定義された通信プロトコル

複数の実行環境間における、好ましくは規定されたデータ共有およびオペレーティングシステムサービス共有は、いくつかの機構に依拠することが可能であり、組み合わせの中で１組だけを考慮する。
一方が、データ生産側であり、他方が、データ消費側である場合における、２つの実行環境における２つのアプリケーション間のパイプ
１つのアプリケーションが、ファイルへの読み取りアクセスを有し、他方のアプリケーションが、同一のファイルへの読み取り／書き込みアクセスを有する場合（１つのアプリケーションが、生産側であり、他方のアプリケーションが、消費側である場合におけるパイプの実装のような）における、ファイル共有
カードオペレーティングシステムによって内部で定義され実装され、２つのアプリケーションによって共有される通信プロトコル
カードオペレーティングシステムのリエントラント関数および関数ライブラリの共有

次に、２つの実行環境１００と２００の間の好ましい対話を示す図２を説明する。図２では、Ａｐｐ２は、「ＡＰＤＵ実行環境」１００のアプリケーションＡｐｐＡおよびＡｐｐＢと情報および／またはサービスを共有することができる「新たな実行環境」２００のアプリケーションである。

好ましい実施形態では、ＩＣカードは、両方の環境でアプリケーションを同時に、すなわち、ＡｐｐＡとＡｐｐ２とを同時に実行する。

しかし、アプリケーションＡｐｐＡ、ＡｐｐＢ、およびＡｐｐ２は、必ずしも同時にアクティブではない。ＡｐｐＡおよび／またはＡｐｐＢが、呼び出され、いくらかのデータを生成しており、そのデータが、Ａｐｐ２が実行を開始した際、Ａｐｐ２によって使用されることが可能であることが生じる可能性がある。

スマートカードの基本となるオペレーティングシステム３００は、以下のタイプのリソースおよびデータ共有機構を提供する。すなわち、
アクセス制御リスト（ＡＣＬ）によって制御されるファイル共有
アクセス制御リスト（ＡＣＬ）によって制御されるストリームベースの通信（データパイプ）
下記特性を満たすアプリケーション間の専用通信機構、すなわち、
それらの機構は、２つの異なる実行環境において実行されている２つのアプリケーション間でデータを送受信することを可能にする。
その通信機構へのアクセスは、アクセス制御リスト（ＡＣＬ）によって制御される。
カードの基本となるオペレーティングシステム３００における共有ライブラリによって公開される再入可能な関数
一方の実行環境において実行されているアプリケーションによって、他方の実行環境（例えば、ＲＰＣ様の）において実行されているアプリケーションに公開されるリエントラント関数
アクセス制御リスト（ＡＣＬ）は、アプリケーションまたはアプリケーションを呼び出したエンティティを識別し、そのアプリケーションまたはエンティティにアクセス権を付加する好ましい手段である。ＡＣＬは、下記アイテムのペアとして表されることが可能である。すなわち、
＜ｉｄ、アクセス条件＞
ｉｄは、下記のいずれかであることが可能である。
実行環境におけるアプリケーションｉｄ
タスクの実行がアプリケーションによって行われているユーザｉｄ
タスクの実行がアプリケーションによって行われている外部エンティティ（例えば、カード管理者またはスーパユーザ）

アクセス条件は、以下のいずれかであることが可能であるが、それらには限定されない。すなわち、読み取り、書き込み、実行または以上のアクションの任意の組合せである。

カードオペレーティングシステムは、２つの実行環境１００および２００に共有リソースを提供することができる。アプリケーションは、共有リソースを使用するアクセス権を、そのリソースに対する、そのアプリケーションのアクセス権を定義するＡＣＬが存在する場合、有する。共有リソースは、２つの実行環境間の通信機構であること、または一組の共有関数であることが可能である。各アプリケーションには、そのアプリケーションが、各リソースに付加された対応するアクセス条件（ＡＣＬ）を満たす場合、共有リソースを使用する権利が与えられることが可能である。

ＡＣＬは、カード管理者と呼ばれるエンティティによって定義される。通常、これは、カード発行者または「スーパユーザ」である。このエンティティは、実行環境間におけるリソースの共有のために、カード内のＡＣＬを定義すること、および変更することができる。

「スーパユーザ」の身元は、通常、管理者キーの所有の証拠を提供する暗号手段によって証明される。

次に、図３を参照して、さらなる「新たな実行環境」２００も有するＳＩＭカードの実施例を見ることにする。

図３は、前述したアプリケーション、ＡｐｐＡ、ＡｐｐＢ、およびＡｐｐ２などの、ＧＳＭ標準タイプのアプリケーションとＷｅｂタイプのアプリケーションの間における通信機構を示す。破線は、アプリケーションが、それらのアプリケーション間でデータを交換できること、またはいくつかの共通のリソースを共有できることを示す。データの実際の通信は、以下に説明するとおり、オペレーティングシステム３００によって実施されるファイル共有によって、または共有ライブラリを呼び出すことによって行われる。

ＩＣカードは、関連するＧＳＭ標準において定義されたすべてのサービスを実施し、それらのサービスはすべて、ＡＰＤＵ実行環境１００において実行される。ＡＰＤＵ実行環境１００は、ＩＳＯ７８１６標準化プロトコルおよびＧＳＭ標準化プロトコルを介して移動電話機と通信する。

「新たな実行環境」２００は、ＴＣＰ／ＩＰおよびＨＴＴＰが上にあるＵＳＢプロトコルを介して、移動電話機と通信し、以下のタスクを実行することができるアプリケーション２５０を有するＨＴＴＰ Ｗｅｂサーバを実行する。すなわち、
移動電話機にインストールされたコンテンツについての情報を受け取る、
移動電話機にインストールされたコンテンツを実行する許可をコンピュータ処理する（デジタル権利管理アプリケーション）。

この目的で、アプリケーション２５０は、ＧＳＭ標準環境１００のアプリケーション１４０によって格納されたライセンスファイル１５０から、許可、すなわち、ライセンス情報を取得する必要がある。そのライセンスファイルは、ＯＴＡメッセージ（Ｏｖｅｒ ｔｈｅ Ａｉｒプロトコル）を介してカード内で更新されており、このプロトコルは、ＧＳＭ標準において定義されているプロトコルである。ＡＰＤＵ実行環境１００において実行されているアプリケーション１４０が、そのメッセージを受け取り、それに応じて、ライセンスファイル１５０を更新している。ＧＳＭアプリケーション１４０は、ライセンスファイル１５０に対する読み取り−書き込み許可をアプリケーション１４０に与えるＡＣＬが存在するので、そのライセンスファイルを更新することができる。

ライセンス情報、すなわち、コンテンツを実行する許可を取得するため、「新たな実行環境」２００におけるＷｅｂアプリケーション２５０は、ライセンス情報が格納される共有ライセンスファイル１５０を読み取る。Ｗｅｂアプリケーション２５０は、共有ライセンスファイル１５０に対する読み取り専用許可をアプリケーション２５０に与える、アプリケーション２５０に関するＡＣＬが存在するので、そのファイルを読み取ることができる。このため、Ｗｅｂアプリケーション１４０は、移動電話機にインストールされたコンテンツへのアクセスを得る。

Ｗｅｂアプリケーション２５０が、そのファイルに書き込みも行おうと試みた場合、オペレーティングシステム３００は、その書き込みを許可せず、例外を破棄する。

また、「新たな実行環境」２００において実行されるＷｅｂアプリケーション２５０は、コンテンツの解読を実行してから、ユーザに有益なさらなる実行のために、解読されたコンテンツを移動電話機にレンダリングする必要もある。

その目的で、Ｗｅｂアプリケーション２５０は、その解読を実行し、作成中に、またはＯＴＡアップデート（Ｏｖｅｒ ｔｈｅ Ａｉｒ ｐｒｏｔｏｃｏｌ）中にカード内で個人設定されているキーを使用する、ＧＳＭ標準実行環境１００におけるライブラリ１６０にアクセスする必要がある。その目的で、Ｗｅｂアプリケーション２５０は、ＧＳＭ標準アプリケーションと共有される解読ライブラリ１６０の中に格納されている解読関数を実行する権利がある。というのは、その共有される関数に対する「実行」許可を、アプリケーション２５０に与えるＡＣＬが存在するからである。

Claims (21)

1. 少なくとも１つの装置に対する少なくとも１つの物理通信チャネルと、前記少なくとも１つ装置に対する少なくとも２つの論理通信チャネルとを具える、認証および／または権利を含むＩＣカードなどのリトリーブ可能なトークンであって、
   各論理通信チャネルは、異なる実行環境と連携する、トークン。
2. ポータブルなものが、マルチメディアメモリカードである、請求項１に記載のリトリーブ可能なトークン。
3. 装置が、移動通信ハンドセットである、請求項１に記載のリトリーブ可能なトークン。
4. 装置が、パーソナルコンピュータである、請求項１に記載のリトリーブ可能なトークン。
5. 前記少なくとも１つの物理通信チャネルが、ＵＳＢプロトコルを使用する、請求項１に記載のリトリーブ可能なトークン。
6. 前記少なくとも１つの物理通信チャネルが、ＳＰＩプロトコルを使用する、請求項１に記載のリトリーブ可能なトークン。
7. 前記少なくとも１つの物理通信チャネルが、ＭＭＣプロトコルを使用する、請求項１に記載のリトリーブ可能なトークン。
8. 少なくとも１つの物理通信チャネルが、非接触スマートカード向けのプロトコルを使用する、請求項１に記載のリトリーブ可能なトークン。
9. 通信プロトコルが、ＩＳＯ（ＦＣＤ）１５６９３において定義される、請求項８に記載のリトリーブ可能なトークン。
10. 通信プロトコルが、ＩＳＯ１４４４３において定義される、請求項８に記載のリトリーブ可能なトークン。
11. 物理通信チャネルの少なくとも１つが、ＴＳ１０２．２２１標準において定義されたプロトコルを使用する、請求項１に記載のリトリーブ可能なトークン。
12. 物理通信チャネルの少なくとも１つが、ＩＳＯ７８１６標準において定義されたプロトコルを使用する、請求項１に記載のリトリーブ可能なトークン。
13. 少なくとも２つの物理チャネルを含み、前記物理チャネルの少なくとも１つが、他の物理チャネルとは独立である、請求項１に記載のリトリーブ可能なトークン。
14. 各実行環境において独立に実行されることが可能な少なくとも２つのアプリケーションを含み、前記少なくとも２つのアプリケーション間で共有されるリソースを含む、請求項１に記載のリトリーブ可能なトークン。
15. アクセス条件リスト（ＡＣＬ）を含み、前記リソースは、前記アクセス条件リスト（ＡＣＬ）に基づき、前記少なくとも２つのアプリケーションによって共有される、請求項１４に記載のリトリーブ可能なトークン。
16. アプリケーション間で共有されることが可能なリソースが、共有ファイルであり、アクセス条件リストの前記アクセス条件は、それぞれのアプリケーションを、そのファイル上でそれぞれの動作と連携させ、前記それぞれのアプリケーションを、前記ファイル上で前記それぞれの動作を実行するのを許可する、請求項１５に記載のリトリーブ可能なトークン。
17. 異なる実行環境におけるアプリケーション間で共有されることが可能なリソースが、「先入れ先出し」（ＦＩＦＯ）の形でデータが書き込まれる共有オブジェクトであり、アクセス条件は、それぞれのアプリケーションを、そのファイル上でそれぞれの動作と連携させ、前記それぞれのアプリケーションが、そのオブジェクトにて前記それぞれの動作を実行するのを許可する、請求項１５に記載のリトリーブ可能なトークン。
18. 異なる実行環境における前記アプリケーションに共通するオペレーティングシステムを格納して、実行するリトリーブ可能なトークンであって、
    異なる実行環境におけるアプリケーション間で共有されることが可能なリソースが、共通のオペレーティングシステムによって実施され、アクセス条件が、共有される関数を呼び出すアプリケーションのそれぞれの権利を指定するアクセス条件リスト（ＡＣＬ）の中で定義される、前記共有される関数である、請求項１５に記載のトークン。
19. 実行環境において実行される第１のアプリケーションは、別の実行環境における第２のアプリケーションと関数を共有することを、他方のアプリケーションが、その関数を呼び出すことを許すことによって行うことができ、アクセス条件（ＡＣＬ）は、第２のアプリケーションが、その共有される関数にアクセスするように、リトリーブ可能なトークン内で定義される、請求項１４に記載のリトリーブ可能なトークン。
20. ２つの異なる環境下でそれぞれ実行される２つのアプリケーションを含み、前記２つのアプリケーションを同時に実行する、請求項１４に記載のリトリーブ可能なトークン。
21. ２つの異なる環境下でそれぞれ実行される２つのアプリケーションを含み、２つのアプリケーション間におけるデータおよび／または関数のセキュリティで保護された共有を可能にする、２つの実行環境における前記アプリケーション間の通信プロトコルを含む、請求項１４に記載のリトリーブ可能なトークン。

Images