説明

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

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

【発明の詳細な説明】
【技術分野】
【0001】
本発明は、サービスを提供する受信装置の中に導入される集積回路カードなどの、認証および/または権利を含むトークンに関し、そのような受信装置は、サービスを提供する前に、トークンの中に格納されている多くの権利の認証または読み取りを要求する。
【背景技術】
【0002】
そのようなトークンとは、例えば、クレジットカード、SIMカード、プリペイドカード、あるいはカード形状またはスティック形状であることが可能なUSB認証トークンである。
【0003】
集積回路カード(ICカードまたは「スマートカード」)は、アプリケーションに対して強化されたセキュリティおよびプライバシーの機能を提供するのに理想的に適している、本来的にセキュリティで保護されたコンピューティングプラットフォームである。また、ICカードは、ユーザ加入データ、ユーザ秘密キー、およびその他の秘密データまたは機密データを格納する場所として、無線電話機、およびその他の通信装置においても使用されている。
【0004】
ICカードは、秘密キーとキー要素、アカウント番号と値、パスワードと共有秘密、承認と許可などの、機微な情報のためのセキュリティで保護された格納ファシリティおよびコンピュータ設備のための手段を提供する。
【0005】
同時に、それらのICカード、およびその他のトークンの多くは、敵対敵なコード(ウイルス、トロイの木馬など)からの潜在的な危険にさらされているホスト環境内で、その情報を露顕させることなしに使用することができる、孤立した処理ファシリティを提供する。これは、秘密キーを使用しての、個人的身元証明のためのデジタル署名の生成、共有される秘密に基づくネットワーク認証、値の電子的表現の保持、オフライン状況において使用するためのポータブルな許可など然るべき操作にとって極めて重要となる。
【0006】
現在のICカードは、非同期プロトコルが使用されており、APDUコマンドが、アプリケーションレベル情報を伝送する、ISO7816標準において定義された通信プロトコルを使用する。また、このプロトコルは、移動電話機においても使用されており、GSM標準および3GPP標準が、このプロトコルに準拠する。
【0007】
今日、新たなICカードに組み込まれている、さらなる、より迅速な同期通信プロトコルが存在する。これにより、ISO7816通信プロトコルと並行した、同期通信プロトコル(例えば、USB、またはその他)の追加が可能になる。各通信チャネルは、異なるピン接点セットを使用するので、この2つのプロトコルの間で相互依存関係は、全く存在しない。
【0008】
今日、無線ハンドセット、または他の任意の通信デバイスなどの、ICカードをホストしている端末装置は、異なる計算サービスを呼び出す、またはデータの取り出しを生じさせる、特定のコマンド(APDUコマンドと呼ばれる)を送ることにより、ICカードサービスを使用する。サービス、またはデータの取り出しは、要求を実行し、必要とされているデータを戻すICカードアプリケーションによって実行される。
【0009】
新たなカードは、カードの異なるピン接点セット上に追加の、独立した通信プロトコル(例えば、USB)を組み込む。その場合、カードは、その2つの通信チャネルを2つの独立したプロセスによって管理する。
【発明の概要】
【発明が解決しようとする課題】
【0010】
本発明の目的は、リトリーブ可能なトークンが、関連する装置と強化された通信を有することを可能にする、すなわち、外部世界とのよりスマートな通信を可能にすることである。
【0011】
本発明の別の目的は、リトリーブ可能なトークンのリソースのより効率的な使用を可能にすることである。
【課題を解決するための手段】
【0012】
以上の目的で、本発明によれば、添付の特許請求の範囲に記載されるリトリーブ可能なトークンが提案される。
【0013】
本発明のその他の特徴および利点は、添付の図面に関連して解釈される、以下の説明から明白となろう。
【図面の簡単な説明】
【0014】
【図1】本発明によるICカード内の環境構成を示す概略図である。
【図2】本発明によるICカード内のファイルの構成を示す概略図である。
【図3】本発明の特定の実施形態におけるアプリケーションの協働の実施例を示す図である。
【発明を実施するための形態】
【0015】
図1に示されるとおり、次の2つの仮想実行環境、または論理実行環境に関連して、ICカードを以下に説明する。すなわち、このケースでは、APDU実行環境100である第1の実行環境、および以降、「新たな実行環境」200と呼ばれる第2の実行環境である。
【0016】
より一般的には、リトリーブ可能なトークンは、少なくとも1つの物理通信チャネルをホストすることができ、少なくとも1つの論理通信チャネルが開かれることが可能なスマートカード、または任意のセキュリティで保護されたリトリーブ可能なトークンであることが可能である。
【0017】
一般的な意味によれば、実行環境は、所与のアプリケーションを実行するためにICカード内で所与の時点で使用される、基礎にあるプログラムセットおよび/またはパラメータセットとして理解される。
【0018】
そのような実行環境には、オペレーティングシステムが含まれることも、含まれないことも可能である。例えば、実行環境は、所与のオペレーティングシステムに適用されるパラメータセットに主に存することが可能であり、そのパラメータセットは、実行環境ごとに異なる。
【0019】
しかし、実行は、所与のオペレーティングシステムを指定することに限定されない。
【0020】
また、実行環境は、他の点では普通のオペレーティングシステムより上に位置する特定のプログラムセットを含むという事実に起因して、特定的であることも可能である。
【0021】
「APDU実行環境」100は、すべての既存の標準が適用される既存の(レガシな)実行環境である。例えば、SIMカードの場合、「APDU実行環境」100は、カードが、ネットワーク認証、SIMツールキットアプリケーション、その他のために実施するアプリケーションおよびサービスを定義するすべての標準に関わる。
【0022】
「新たな実行環境」200は、古い実行環境(「APDU実行環境」)とは独立であり、古い実行環境とは全く通信を有さない。これは、現在のカードアプリケーションが影響を受けないことを確実にするために重要である。
【0023】
このケースでは、両方の実行環境共にセキュリティで保護されている。
【0024】
一般的な下位互換性の必要性は、これら2つの実行環境100および200におけるアプリケーションの間で分離(ファイアウォール処理)を課す。
【0025】
「新たな実行環境」200は、「APDU実行環境」100の場合と同様に、いくつかのアプリケーションの実行を可能にすることができる。新たな実行環境200のアプリケーションに関する例が、いくつかのWebアプリケーションを統合することができるWebサーバである。
【0026】
「新たな実行環境」200は、「APDU実行環境」におけるレガシなアプリケーションとは独立した新たなアプリケーションセットを実施することができる。しかし、カード発行者は、レガシな環境(「APDU実行環境」)の挙動に干渉しない、あるレベルのデータ共有およびオペレーティングシステムサービスを可能にすることを所望する可能性がある。
【0027】
好ましい実施形態では、異なる環境100および200の下で実行されているアプリケーションが、セキュリティで保護された形でデータを交換する。
【0028】
また、これら2つの実行環境におけるアプリケーション間の通信プロトコルも、セキュリティで保護されたデータ共有または関数共有を可能にするために実施されることが可能である。
【0029】
より一般的には、共有されるリソースは、前記2つのアプリケーションの少なくともいずれかによって使用されることが可能なデータを担持し、そのデータは、許可されていないエンティティによるアクセスから保護されている。
【0030】
この原理は、2つより多くのプロトコルスタックに拡張されることが可能である。リトリーブ可能なトークンが、2つだけの物理レイヤを有する場合でも、それらの物理レイヤが、いくつかのプロトコルスタックの間で共有されることが可能である。
【0031】
特定のケースでは、物理レイヤは、いくつかの論理チャネル(または「パイプ」)のためのサポートを提供することができる。したがって、その概念を説明すると、USBプロトコルが、同一の物理媒体上で、いくつかの論理パイプ(エンドポイント)をサポートすることができる。一部の論理パイプは、あるプロトコルスタックに専用であることが可能であり、他の一部は、別のプロトコルスタックに専用であることが可能である。この概念が、USB環境内で「複合デバイス」と名付けられる。
【0032】
論理チャネルまたは仮想チャネルは、ユーザには、特定のデータチャネルとして現れるが、この現れる論理チャネルとは非常に異なる物理的手段に基づいて実施されることが可能である。論理チャネルを構成する真の手段は、物理チャネルと呼ばれる。それらの真の手段は、現れる論理チャネルとは完全に異なることが可能である。
【0033】
同一のUSBコネクタを介して、ホストは、いくつかのタイプのデバイス(例えば、マウス、キーボード)を管理することができる。現在のICカードは、物理通信チャネルの数とは独立した、少なくとも2つの論理通信チャネルをホストすることができる。
【0034】
USBインタフェースをホストすることができるICカードに適用された概念は、本発明を利用することができる。USBレイヤを介して、例えば、TCP/IPスタックおよび大容量ストレージスタックのカードレベルにおけるホストを想像することができる。
【0035】
このUSB通信に加えて、スマートカードは、通常のISO7816プロトコルを使用して、別の通信リンクを確立する。この実施例は、少なくとも3つの異なるプロトコルスタックが、同一のスマートカード内で実行されることが可能であることを示す。したがって、本発明は、各々の特定の文脈において、アプリケーションが、異なるプロトコルスタックを実行している実行環境間の、セキュリティで保護され、制御されたブリッジを確立することができる場合に適用可能である。
【0036】
したがって、本発明は、ISO7816プロトコルを実行しているが、複数の論理チャネル、あるいはマルチメディアカードまたはドングル(例えば、USBドングル)と併せて、スマートカード内にて有用に使用されることが可能である。
【0037】
また、本発明は、独立した物理通信チャネルと論理通信チャネルの組合せを有する能力をよく示す、以下のシナリオにも適用されるが、このシナリオには限定されない。すなわち、
1つのUSB通信チャネルを有し、いくつかの論理チャネル(「パイプ」)と共に、APDUコマンドが、1つの論理チャネル上で送られて、レガシなアプリケーションにアドレスし、TCP/IPプロトコルスタックが、その他の論理チャネル上で実行されるリトリーブ可能なトークン。
異なる孤立した実行環境に各々が連携している、1つまたは複数の物理チャネルまたは論理チャネルを有するリトリーブ可能なトークン。物理通信チャネルは、以下の実施例であることが可能であるが、これらの実施例には限定されない。すなわち、
マルチメディアメモリカード(MMC)プロトコル
SPI(シリアル周辺インタフェース)プロトコル
USBプロトコル
スマートカード非接触プロトコル
ISO7816プロトコル
ISO(FCD)15693プロトコル
ISO14443プロトコル
TS102.221標準において定義された通信プロトコル
【0038】
複数の実行環境間における、好ましくは規定されたデータ共有およびオペレーティングシステムサービス共有は、いくつかの機構に依拠することが可能であり、組み合わせの中で1組だけを考慮する。
一方が、データ生産側であり、他方が、データ消費側である場合における、2つの実行環境における2つのアプリケーション間のパイプ
1つのアプリケーションが、ファイルへの読み取りアクセスを有し、他方のアプリケーションが、同一のファイルへの読み取り/書き込みアクセスを有する場合(1つのアプリケーションが、生産側であり、他方のアプリケーションが、消費側である場合におけるパイプの実装のような)における、ファイル共有
カードオペレーティングシステムによって内部で定義され実装され、2つのアプリケーションによって共有される通信プロトコル
カードオペレーティングシステムのリエントラント関数および関数ライブラリの共有
【0039】
次に、2つの実行環境100と200の間の好ましい対話を示す図2を説明する。図2では、App2は、「APDU実行環境」100のアプリケーションAppAおよびAppBと情報および/またはサービスを共有することができる「新たな実行環境」200のアプリケーションである。
【0040】
好ましい実施形態では、ICカードは、両方の環境でアプリケーションを同時に、すなわち、AppAとApp2とを同時に実行する。
【0041】
しかし、アプリケーションAppA、AppB、およびApp2は、必ずしも同時にアクティブではない。AppAおよび/またはAppBが、呼び出され、いくらかのデータを生成しており、そのデータが、App2が実行を開始した際、App2によって使用されることが可能であることが生じる可能性がある。
【0042】
スマートカードの基本となるオペレーティングシステム300は、以下のタイプのリソースおよびデータ共有機構を提供する。すなわち、
アクセス制御リスト(ACL)によって制御されるファイル共有
アクセス制御リスト(ACL)によって制御されるストリームベースの通信(データパイプ)
下記特性を満たすアプリケーション間の専用通信機構、すなわち、
それらの機構は、2つの異なる実行環境において実行されている2つのアプリケーション間でデータを送受信することを可能にする。
その通信機構へのアクセスは、アクセス制御リスト(ACL)によって制御される。
カードの基本となるオペレーティングシステム300における共有ライブラリによって公開される再入可能な関数
一方の実行環境において実行されているアプリケーションによって、他方の実行環境(例えば、RPC様の)において実行されているアプリケーションに公開されるリエントラント関数
アクセス制御リスト(ACL)は、アプリケーションまたはアプリケーションを呼び出したエンティティを識別し、そのアプリケーションまたはエンティティにアクセス権を付加する好ましい手段である。ACLは、下記アイテムのペアとして表されることが可能である。すなわち、
<id、アクセス条件>
idは、下記のいずれかであることが可能である。
実行環境におけるアプリケーションid
タスクの実行がアプリケーションによって行われているユーザid
タスクの実行がアプリケーションによって行われている外部エンティティ(例えば、カード管理者またはスーパユーザ)
【0043】
アクセス条件は、以下のいずれかであることが可能であるが、それらには限定されない。すなわち、読み取り、書き込み、実行または以上のアクションの任意の組合せである。
【0044】
カードオペレーティングシステムは、2つの実行環境100および200に共有リソースを提供することができる。アプリケーションは、共有リソースを使用するアクセス権を、そのリソースに対する、そのアプリケーションのアクセス権を定義するACLが存在する場合、有する。共有リソースは、2つの実行環境間の通信機構であること、または一組の共有関数であることが可能である。各アプリケーションには、そのアプリケーションが、各リソースに付加された対応するアクセス条件(ACL)を満たす場合、共有リソースを使用する権利が与えられることが可能である。
【0045】
ACLは、カード管理者と呼ばれるエンティティによって定義される。通常、これは、カード発行者または「スーパユーザ」である。このエンティティは、実行環境間におけるリソースの共有のために、カード内のACLを定義すること、および変更することができる。
【0046】
「スーパユーザ」の身元は、通常、管理者キーの所有の証拠を提供する暗号手段によって証明される。
【0047】
次に、図3を参照して、さらなる「新たな実行環境」200も有するSIMカードの実施例を見ることにする。
【0048】
図3は、前述したアプリケーション、AppA、AppB、およびApp2などの、GSM標準タイプのアプリケーションとWebタイプのアプリケーションの間における通信機構を示す。破線は、アプリケーションが、それらのアプリケーション間でデータを交換できること、またはいくつかの共通のリソースを共有できることを示す。データの実際の通信は、以下に説明するとおり、オペレーティングシステム300によって実施されるファイル共有によって、または共有ライブラリを呼び出すことによって行われる。
【0049】
ICカードは、関連するGSM標準において定義されたすべてのサービスを実施し、それらのサービスはすべて、APDU実行環境100において実行される。APDU実行環境100は、ISO7816標準化プロトコルおよびGSM標準化プロトコルを介して移動電話機と通信する。
【0050】
「新たな実行環境」200は、TCP/IPおよびHTTPが上にあるUSBプロトコルを介して、移動電話機と通信し、以下のタスクを実行することができるアプリケーション250を有するHTTP Webサーバを実行する。すなわち、
移動電話機にインストールされたコンテンツについての情報を受け取る、
移動電話機にインストールされたコンテンツを実行する許可をコンピュータ処理する(デジタル権利管理アプリケーション)。
【0051】
この目的で、アプリケーション250は、GSM標準環境100のアプリケーション140によって格納されたライセンスファイル150から、許可、すなわち、ライセンス情報を取得する必要がある。そのライセンスファイルは、OTAメッセージ(Over the Airプロトコル)を介してカード内で更新されており、このプロトコルは、GSM標準において定義されているプロトコルである。APDU実行環境100において実行されているアプリケーション140が、そのメッセージを受け取り、それに応じて、ライセンスファイル150を更新している。GSMアプリケーション140は、ライセンスファイル150に対する読み取り−書き込み許可をアプリケーション140に与えるACLが存在するので、そのライセンスファイルを更新することができる。
【0052】
ライセンス情報、すなわち、コンテンツを実行する許可を取得するため、「新たな実行環境」200におけるWebアプリケーション250は、ライセンス情報が格納される共有ライセンスファイル150を読み取る。Webアプリケーション250は、共有ライセンスファイル150に対する読み取り専用許可をアプリケーション250に与える、アプリケーション250に関するACLが存在するので、そのファイルを読み取ることができる。このため、Webアプリケーション140は、移動電話機にインストールされたコンテンツへのアクセスを得る。
【0053】
Webアプリケーション250が、そのファイルに書き込みも行おうと試みた場合、オペレーティングシステム300は、その書き込みを許可せず、例外を破棄する。
【0054】
また、「新たな実行環境」200において実行されるWebアプリケーション250は、コンテンツの解読を実行してから、ユーザに有益なさらなる実行のために、解読されたコンテンツを移動電話機にレンダリングする必要もある。
【0055】
その目的で、Webアプリケーション250は、その解読を実行し、作成中に、またはOTAアップデート(Over the Air protocol)中にカード内で個人設定されているキーを使用する、GSM標準実行環境100におけるライブラリ160にアクセスする必要がある。その目的で、Webアプリケーション250は、GSM標準アプリケーションと共有される解読ライブラリ160の中に格納されている解読関数を実行する権利がある。というのは、その共有される関数に対する「実行」許可を、アプリケーション250に与えるACLが存在するからである。

【特許請求の範囲】
【請求項1】
少なくとも1つの装置に対する少なくとも1つの物理通信チャネルと、前記少なくとも1つ装置に対する少なくとも2つの論理通信チャネルとを具える、認証および/または権利を含むICカードなどのリトリーブ可能なトークンであって、
各論理通信チャネルは、異なる実行環境と連携する、トークン。
【請求項2】
ポータブルなものが、マルチメディアメモリカードである、請求項1に記載のリトリーブ可能なトークン。
【請求項3】
装置が、移動通信ハンドセットである、請求項1に記載のリトリーブ可能なトークン。
【請求項4】
装置が、パーソナルコンピュータである、請求項1に記載のリトリーブ可能なトークン。
【請求項5】
前記少なくとも1つの物理通信チャネルが、USBプロトコルを使用する、請求項1に記載のリトリーブ可能なトークン。
【請求項6】
前記少なくとも1つの物理通信チャネルが、SPIプロトコルを使用する、請求項1に記載のリトリーブ可能なトークン。
【請求項7】
前記少なくとも1つの物理通信チャネルが、MMCプロトコルを使用する、請求項1に記載のリトリーブ可能なトークン。
【請求項8】
少なくとも1つの物理通信チャネルが、非接触スマートカード向けのプロトコルを使用する、請求項1に記載のリトリーブ可能なトークン。
【請求項9】
通信プロトコルが、ISO(FCD)15693において定義される、請求項8に記載のリトリーブ可能なトークン。
【請求項10】
通信プロトコルが、ISO14443において定義される、請求項8に記載のリトリーブ可能なトークン。
【請求項11】
物理通信チャネルの少なくとも1つが、TS102.221標準において定義されたプロトコルを使用する、請求項1に記載のリトリーブ可能なトークン。
【請求項12】
物理通信チャネルの少なくとも1つが、ISO7816標準において定義されたプロトコルを使用する、請求項1に記載のリトリーブ可能なトークン。
【請求項13】
少なくとも2つの物理チャネルを含み、前記物理チャネルの少なくとも1つが、他の物理チャネルとは独立である、請求項1に記載のリトリーブ可能なトークン。
【請求項14】
各実行環境において独立に実行されることが可能な少なくとも2つのアプリケーションを含み、前記少なくとも2つのアプリケーション間で共有されるリソースを含む、請求項1に記載のリトリーブ可能なトークン。
【請求項15】
アクセス条件リスト(ACL)を含み、前記リソースは、前記アクセス条件リスト(ACL)に基づき、前記少なくとも2つのアプリケーションによって共有される、請求項14に記載のリトリーブ可能なトークン。
【請求項16】
アプリケーション間で共有されることが可能なリソースが、共有ファイルであり、アクセス条件リストの前記アクセス条件は、それぞれのアプリケーションを、そのファイル上でそれぞれの動作と連携させ、前記それぞれのアプリケーションを、前記ファイル上で前記それぞれの動作を実行するのを許可する、請求項15に記載のリトリーブ可能なトークン。
【請求項17】
異なる実行環境におけるアプリケーション間で共有されることが可能なリソースが、「先入れ先出し」(FIFO)の形でデータが書き込まれる共有オブジェクトであり、アクセス条件は、それぞれのアプリケーションを、そのファイル上でそれぞれの動作と連携させ、前記それぞれのアプリケーションが、そのオブジェクトにて前記それぞれの動作を実行するのを許可する、請求項15に記載のリトリーブ可能なトークン。
【請求項18】
異なる実行環境における前記アプリケーションに共通するオペレーティングシステムを格納して、実行するリトリーブ可能なトークンであって、
異なる実行環境におけるアプリケーション間で共有されることが可能なリソースが、共通のオペレーティングシステムによって実施され、アクセス条件が、共有される関数を呼び出すアプリケーションのそれぞれの権利を指定するアクセス条件リスト(ACL)の中で定義される、前記共有される関数である、請求項15に記載のトークン。
【請求項19】
実行環境において実行される第1のアプリケーションは、別の実行環境における第2のアプリケーションと関数を共有することを、他方のアプリケーションが、その関数を呼び出すことを許すことによって行うことができ、アクセス条件(ACL)は、第2のアプリケーションが、その共有される関数にアクセスするように、リトリーブ可能なトークン内で定義される、請求項14に記載のリトリーブ可能なトークン。
【請求項20】
2つの異なる環境下でそれぞれ実行される2つのアプリケーションを含み、前記2つのアプリケーションを同時に実行する、請求項14に記載のリトリーブ可能なトークン。
【請求項21】
2つの異なる環境下でそれぞれ実行される2つのアプリケーションを含み、2つのアプリケーション間におけるデータおよび/または関数のセキュリティで保護された共有を可能にする、2つの実行環境における前記アプリケーション間の通信プロトコルを含む、請求項14に記載のリトリーブ可能なトークン。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate


【公開番号】特開2013−65340(P2013−65340A)
【公開日】平成25年4月11日(2013.4.11)
【国際特許分類】
【外国語出願】
【出願番号】特願2012−261109(P2012−261109)
【出願日】平成24年11月29日(2012.11.29)
【分割の表示】特願2007−501379(P2007−501379)の分割
【原出願日】平成17年3月2日(2005.3.2)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(504326572)ジエマルト・エス・アー (31)
【Fターム(参考)】