セキュリティモジュール内のセキュア化されたリソースの割り当て方法
【課題】 本発明の目的は、電話等の携帯機器のセキュリティモジュールにリソースを割り当てるための方法であって、通信業者及びアプリケーションプロバイダ等、様々な当事者のセキュリティに関する要件を考慮した方法を提供することである。この目的は、通信業者により管理されるネットワークに接続された装置のセキュリティモジュールの、アプリケーションプロバイダによって使用されるリソースの割り当て方法であって、一対の非対称鍵を生成し、プライベート鍵をセキュリティモジュール内に保存し、公開鍵を機関に保存する工程と、機関の少なくとも１つの公開鍵をセキュリティモジュール内に入力する工程と、少なくも１つのプロバイダの公開鍵を含むプロバイダの要求を通信業者が受信する工程と、通信業者が、プロバイダの公開鍵を伴うリソースの予約指示をセキュリティモジュールに送信する工程と、通信業者が、セキュリティモジュールの公開鍵をプロバイダに送信する工程と、プロバイダとセキュリティモジュールの間にセキュア化された通信を確立する工程とを含むリソースの割り当て方法により達成される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は携帯電話とも呼ばれる無線電話の分野に関する。より詳細には本発明は、特定のアプリケーションプロバイダに公開されたセキュリティ機構を前提とする拡張機能に関する。
【０００２】
携帯電話のセキュリティモジュールは、「ＳＩＭカード」という名称の方がより知られているが、これは、携帯電話の安全性の核心となるものである。電話通信業者は、そのネットワークへの接続を所望する全ての電話を確実に識別するのに必要な情報を、製造時又は個人登録段階時に入力する。
【０００３】
この目的のためセキュリティモジュールは少なくとも、ユニークな番号と、確実にＳＩＭカードを識別することができる暗号鍵を含む。
【０００４】
このカードは当初は専ら電話サービスだけのものであったが、株式相場又は気象情報の表示など、新しいアプリケーションが誕生した。
【０００５】
この種のアプリケーションを実現するための最初のモデルは、これらのデータの提供業者を、これらデータを当該電話に送信する通信業者に接続するものであった。
【０００６】
この方法は天気など一般的な情報には好適であるが、銀行残高などの重要なデータに関しては不適当である。
【０００７】
従って、そのようなデータが携帯電話通信業者を経由しなければならないことは受け入れ難いことから、この種のサービスは機密性という問題に直面した。
【０００８】
別のアプローチは、セキュアな方法でＳＩＭカードにアクセスするための暗号手段（特に鍵）をプロバイダに付与するというものであった。このアプローチは、通信業者にとっては受け入れ難い、例えば、プロバイダへの通信業者の機密情報の送信という、前述の問題とは逆の問題に直面した。
【０００９】
米国特許第６３８５７２３号明細書（特許文献１）は、電子カード（ＩＣカード）にアプリケーションをロードする方法について記述している。記述されている方法はアプリケーションをカード内にロードできるようになる前に、ロードするアプリケーションを機関（認証機関）により認証することを内容とする。この方法は、高いセキュリティは保証するものの、柔軟さは全くなく、アプリケーションに変更を加える度毎に機関を介在させる。
【００１０】
欧州特許出願第０９７３１３５号明細書（特許文献２）もまた先行技術を記述するものである。専用の機械のみがセキュリティパラメータを更新する資格をもつ。これはむしろ、保護されたゾーン外で行われるセキュリティモジュールの初期化である。この書類では、後でロードされたアプリケーションのアクセス又は終了を可能にする情報は記述されていない。
【特許文献１】米国特許第６３８５７２３号
【特許文献２】欧州特許出願第０９７３１３５号
【発明の開示】
【発明が解決しようとする課題】
【００１１】
従って本発明の目的は、様々な当事者のセキュリティに関する要件を考慮し、セキュア化されたアプリケーションの分散的なダウンロード及び管理を提案することが可能な方法を提供することである。
【課題を解決するための手段】
【００１２】
この目的は、通信業者により管理されるネットワークに接続された装置のセキュリティモジュールの、アプリケーションプロバイダによって使用されるリソースの割り当て方法であって、
【００１３】
‐ 一対の非対称鍵を生成し、プライベート鍵をセキュリティモジュール内に保存し、公開鍵を機関に保存する工程と、
【００１４】
‐ 機関の少なくとも１つの公開鍵をセキュリティモジュール内に入力する工程と、
【００１５】
‐ 少なくも１つのプロバイダの公開鍵を含むプロバイダの要求を通信業者が受信する工程と、
【００１６】
‐ 通信業者が、プロバイダの公開鍵を伴うリソースの予約指示をセキュリティモジュールに送信する工程と、
【００１７】
‐ 通信業者が、セキュリティモジュールの公開鍵をプロバイダに送信する工程と、
【００１８】
‐ プロバイダとセキュリティモジュールの間にセキュア化された通信を確立する工程と、
【００１９】
‐ プロバイダがセキュリティモジュール内にアプリケーションをロードする工程と
を含むリソースの割り当て方法により達成される。
【００２０】
この方法は、あるリソースの予約、更にはそのブロックが通信業者の管理下にある一方で、このリソースの活用はプロバイダの管理下にあり、通信業者はやりとりされるデータにはアクセスできないため、管理された方法でリソースが割り当てられるという長所を有する。
【００２１】
リソースとは、ある部分がプログラムで構成され、また別のある部分がデータで構成されるセキュリティモジュールのメモリ領域である。
【００２２】
セキュリティモジュールのプロセッサは、セキュアな方法、即ち実行に当たってはリソースの領域以外のメモリ領域の範囲を使用しない方法で、リソースのプログラムを実行する。
【００２３】
このリソースにより、プロバイダは例えば銀行の口座番号を保存したり口座所有者を識別したりすることができる。
【００２４】
通信業者がリソースの終了を所望する場合、リソースの管理に関してセキュリティモジュールと対話できるのはその通信業者だけである。リソースの終了又は解放により、このリソース専用のメモリ領域の非アクティブ化又は消去、特に対応するプロバイダの公開鍵の非アクティブ化又は消去が生じる。
【００２５】
この公開鍵が物理的又は仮想的に消失することにより、プロバイダとセキュリティモジュールの間における一切の新規の相互認証が禁止され、同時に、このブロック又は解放されたリソース内でのプロバイダによるアプリケーションの更新又は新規なダウンロードが阻止される。リソース領域は、各領域の使用についての定義が格納されることになる管理部分を含む。
【００２６】
この管理部分は通信業者によって管理される。この管理部分は、プロバイダの識別子、このプロバイダの鍵、及びメモリ領域のアドレシングができるようにする情報を含む。プロバイダが、限られた時間、リソースを使用することができる場合には、この部分は日付情報も含むことができる。この日付を超過すると、リソースは非アクティブ化又は消去され、特にプロバイダの公開鍵が非アクティブ化又は消去される。
【００２７】
別の変形形態によれば、プロバイダ及び／又はエンドユーザーが、限られた実行回数だけリソースを使用することができる場合には、この部分は実行回数情報も含むことができる。この実行回数を超過すると、リソースは非アクティブ化又は消去され、特にプロバイダの公開鍵が非アクティブ化又は消去される。
【発明を実施するための最良の形態】
【００２８】
本発明は、非限定的例として示した添付の図面を参照して行う以下の詳細説明により、よりよく理解されよう。
【００２９】
図１によれば、セキュリティモジュールの製造者などのエンティティＰＳによりセキュリティモジュールＵＳ−ＳＭの初期化が行われる。このエンティティＰＳは、これらのモジュールの管理を担当する機関に対応する公開鍵ＫＰｕＩＳ、並びにこのセキュリティモジュールに固有なプライベート鍵ＫＰｒＵＳを設定する。
【００３０】
以下に記述するように、対称鍵の生成に用いられる生成データｂ、Ｍ（ベース、モジューロ）など他のカスタム化パラメータもセキュリティモジュール内に保存することができる。
【００３１】
カスタム化エンティティＰＳはカスタム化情報、即ちある所与のモジュール（通常、ユニークなアドレス又はユニークな識別子によって識別される）について、その公開鍵ＫＰｕＵＳ、を機関ＩＳに返す。モジュールのメモリサイズ、暗号化モジュールのようなモジュールの特性等、他のデータも機関によって記憶される。
【００３２】
図２は通信業者ＯＰに対するプロバイダＦＯによるリソースの要求操作を示す図である。
【００３３】
プロバイダＦＯは、あるセキュリティモジュールのリソースにアクセスできるようにするために、まず通信業者ＯＰに問い合わせる。次にプロバイダＦＯ及び通信業者ＯＰはパートナシップの方法について同意することになる。われわれの例によれば、通信業者ＯＰと機関ＩＳは異なる２つのエンティティであるので、通信業者ＯＰは必要な情報を機関ＩＳに対し要求する。別の例では、通信業者ＯＰが機関ＩＳの機能を含むことが可能である。
【００３４】
プロバイダＦＯは特にその公開鍵ＫＰｕＦＯを通信業者ＯＰに送信し、必要なリソースの特性を通信業者に知らせる。対称鍵の生成に用いるデータｂ、Ｍもこの時送信することができる。
【００３５】
図３は３つの操作ＳＥＲ、ＲＥＳ及びＡＣＴを示す図である。
【００３６】
予約工程ＲＥＳはセキュリティモジュール内にリソースを作ることを内容とする。加入者は、プロバイダＦＯが提案したサービスを利用したいとの希望を、自身のセキュリティモジュールＵＳ−ＳＭを経由して通信業者ＯＰに送ることができる。そのような場合、通信業者ＯＰはプロバイダＦＯから公開鍵ＫＰｕＦＯを回収し、次に、セキュリティモジュール内でリソースＲＳＣの予約操作を開始する。通信業者は各セキュリティモジュールについてのリソースの使用に関する情報を持つ。通信業者は、プロバイダＦＯのニーズの種類、例えば要求されるメモリ空間のサイズに応じて、最適なリソースを決定する。
【００３７】
通信業者は予約命令をセキュリティモジュールに送るが、勿論この命令は通信業者のプライベート鍵ＫＰｒＯＰによりセキュア化されている。この命令はリソースを予約する。即ち、メモリ領域の一部が、プロバイダとの対話を許可するのに適したデータを受け取る。この操作の際、セキュリティモジュールはプロバイダから、公開鍵ＫＰｕＦＯ、即ちセキュリティモジュールがこのプロバイダとの間でセキュア化されたリンクを確立することができるようにする鍵を受け取る。
【００３８】
この操作の間、通信業者は、もしセキュリティモジュールの鍵を持っていない場合には、機関ＩＳに対し鍵を要求することができる。当然のことながら、この要求はこれらの２つのエンティティの間においてセキュア化された方法で行われる。
【００３９】
第２工程ＡＣＴは、加入者又はセキュリティモジュールのデータをプロバイダＦＯに送信することを内容とする。通信業者ＯＰは、公開鍵ＫＰｕＵＳ、及び自身に割り当てられたリソースＲＳＣの識別子をプロバイダに知らせる。
【００４０】
各セキュリティモジュールの公開鍵がユニークであるということは、一旦セキュリティモジュールＵＳ−ＳＭが識別されると、通信業者ＯＰ又は機関ＩＳは、このモジュールに固有な公開鍵ＫＰｕＵＳをプロバイダに送信するためにデータベース内でこの鍵を検索する。
【００４１】
この初期化が行われたら、このサービスの使用工程ＳＥＲをアクティブ化することができ、ユーザーは、ユーザーがプロバイダに直接リンクできる専用の番号をコールする。プロバイダは最初の任務として、セキュリティモジュールＵＳ−ＳＭ内の、通信業者によって割り当てられたメモリ領域に自身のアプリケーションをロードする。コード及び／又はデータのセキュアなやりとりのためにセッション鍵ＫＳが生成される。
【００４２】
図４はセキュリティモジュールの編成を示す図である。セキュリティモジュールは、処理ユニットＣＰＵ、モジュールの作動プログラムが保存される作業メモリＭＥＭ、外部リソース用のメモリ領域から成る。この領域は、リソースＲＳＣ１からＲＳＣ４を定義するデータを含む第１の定義部分ＤＥＦを有する。実際には、リソースのメモリ領域は必ずしも予め分割されている必要はない。プロバイダが通信業者に対しリソースを要求する時には、必要なメモリサイズを指定することもできる。従って、各リソースが使うメモリが少なければ少ないほど、リソースのメモリ領域はより多くの異なるリソースを含むことができる。定義部分ＤＥＦは各リソースの開始及び終了情報を含む。
【００４３】
各リソースＲＳＣには、例えば、暗号アルゴリズム或いは他の特別な計算プロセス等、セキュリティモジュールＵＳ−ＳＭ上で使用可能ないくつかのプログラミングインタフェース（又はライブラリ）へのアクセス権を示す追加情報を関連付けることができる。そのような情報は例えばＤＥＦ領域又はそれぞれのＲＥＳ領域内に保存することができる。
【００４４】
モジュールＩ／Ｏは携帯電話などのホスト機器との通信を図式化する。
【００４５】
２つのエンティティ間でセキュア化された接続を確立するにはいくつかの方法がある。本発明の範囲内では、一対の非対称鍵を使用し、主エンティティがプライベート鍵を有し、第３のエンティティが公開鍵を受け取るようになっている。プライベート鍵は原則として通信手段によっては送信されず、セキュア化初期化工程時に装置内に直接入力される。公開鍵は、上で記述した、この装置と対話するための手順に従い送信される。
【００４６】
実際には、公開鍵のやりとりはこの鍵に関連付けられた証明書を使用して行われることが多い。エンティティＢがエンティティＡから公開鍵を受け取る時、この鍵は、エンティティＡが信頼している機関、例えば通信業者により署名された証明書の中に含まれている。また、エンティティＡ及びＢが既に予め相互認証していて、通信に用いるチャンネルが安全であって、証明書なしの公開鍵を送信し合うことができるようになる場合もある。
【００４７】
鍵ＲＳＡ等の非対称鍵によりパートナの認証を行うことが可能である。エンティティＡは、自身のプライベート鍵ＫＰｒＡを使用する操作により自身の認証を行う。するとエンティティＢは、対応する公開鍵ＫＰｕＡを使用してこの認証の有効性を確認することができる。非対称鍵に基づいた暗号化は重く、大がかりな暗号化手段を必要とする。通常、非対称鍵は、対称セッション鍵の認証及び生成に使用されるのはそのためである。また、認証用として非対称鍵を使用し、対称セッション鍵の生成用としてＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎが記述した方法を用いることも可能である。
【００４８】
実施形態のうちの１つによれば、リソースを予約する工程は、プロバイダの公開鍵ＫＰｕＦＯの送信に加え、このプロバイダに固有なＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎパラメータ、即ちモジュールＭ又はベースｂの送信を含む。従って、プロバイダと加入者のセキュリティモジュールの間におけるセッション鍵の確立の際には、これらのパラメータが使用されるが、その時、これらのパラメータを再送信する必要はない。
【００４９】
セキュリティモジュールと通信業者の間にセッション鍵を生成するために、この同じＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎ法を使用することが可能であり、その場合、セキュリティモジュールを初期化する工程は、通信業者に固有なＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎパラメータをセキュリティモジュール内に入力することを内容とする追加の工程を含むことがある。
【００５０】
セキュア化されたリンクの確立の第１形態によれば、２つの装置間のデータのやりとりには他方の装置の公開鍵が用いられる。この方法は、やりとりをセキュア化することが可能な対称鍵ＫＳが生成されると同時に、パートナの認証が行われるという長所を有する。
【００５１】
セキュア化されたリンクの確立の第２形態によれば、Ｄｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎパラメータに基き、従来の方法によりエンティティＡとＢの間にセッション鍵が生成される。一旦このセッション鍵が確立されると、相互認証手順が開始する。例えばエンティティＡは、自身のプライベート鍵ＫＰｒＡを使用して、Ｄｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎネゴシエーションの際にＢとの間でやりとりされる値のうちのいくつかに署名し、このようにして生成した署名をＢに送ることができる。するとエンティティＢは、鍵ＫＰｕＡにより書名を確認してＡを認証することができる。同様にエンティティＢは、自身のプライベート鍵ＫＰｒＢを使用して、Ｄｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎネゴシエーションの際にＡとの間でやりとりされる値のうちのいくつかに署名し、このようにして生成した署名をＡに送ることができる。するとエンティティＡは、鍵ＫＰｕＢにより書名を確認してＢを認証することができる。
【００５２】
このセキュア化されたリンクを確立するために、例えば、前述の２つの工程を逆にすることにより、即ち、２つのパートナを認証するのに公開／プライベート鍵暗号化を使用し、次にセッション鍵を生成する等、他の方法も存在する。
【００５３】
実際には、種々のエンティティが様々な工程に関わることがあり得る。鍵の生成は第１機関に委任され、第１機関は、これらの鍵、少なくともプライベート部分を、セキュリティモジュールのカスタム化のために、インテグレータに通知する。この生成はセキュリティモジュール内で直接行うことができること、及び初期化工程の際、セキュアな環境下で、公開鍵のみが通信されることに留意すべきである。
【００５４】
各セキュリティモジュールのユニークな番号（ＵＡ）に関連付けられた公開鍵のこのデータベースは、通信業者によって管理されるか、第３のエンティティに委ねられる。通信業者の代わりにリソースの割り当て機能を確保するのはこのエンティティである。
【００５５】
本発明の別の実施形態によれば、アプリケーションのロードはグローバルな方法で行うことができるのが望ましい。セキュリティモジュールはモジュール毎にユニークな鍵を使用することから、リソースの予約時に、中間工程が付加される。通信業者ＯＰによりセキュリティモジュールに送信されるパラメータに、ある所与のアプリケーションに関して全てのセキュリティモジュールに共通な鍵であるドメイン鍵が付加される。リソースの定義は、セキュリティモジュールのハードウェア的能力に応じて、各セキュリティモジュールに特有であるが、一旦定義されると、全てのモジュールに共通な論理名称及び共通鍵が与えられる。従ってプロバイダＦＯは、接続されている全てのモジュールに分散モードにて自身のアプリケーションを同時にダウンロードするか、このモジュールがプロバイダのサーバーに呼び出された時に、セキュリティモジュールとは独立した手順によりダウンロードすることができる。このドメイン鍵ＤＫは本方法の実施方法によって、対称型とすることも、非対称型とすることも可能である。この鍵は、セキュア化されたリンクの確立時、セキュリティモジュールの公開／プライベート鍵の対はこの鍵に取って換えられる。
【図面の簡単な説明】
【００５６】
【図１】図１はセキュリティモジュールの個人登録段階を示す図である。
【図２】図２はプロバイダと通信業者の間の送信を示す図である。
【図３】図３は３つのエンティティ間のデータのやりとりを示す図である。
【図４】図４はリソース割り当てセキュリティモジュールを示す図である。
【技術分野】
【０００１】
本発明は携帯電話とも呼ばれる無線電話の分野に関する。より詳細には本発明は、特定のアプリケーションプロバイダに公開されたセキュリティ機構を前提とする拡張機能に関する。
【０００２】
携帯電話のセキュリティモジュールは、「ＳＩＭカード」という名称の方がより知られているが、これは、携帯電話の安全性の核心となるものである。電話通信業者は、そのネットワークへの接続を所望する全ての電話を確実に識別するのに必要な情報を、製造時又は個人登録段階時に入力する。
【０００３】
この目的のためセキュリティモジュールは少なくとも、ユニークな番号と、確実にＳＩＭカードを識別することができる暗号鍵を含む。
【０００４】
このカードは当初は専ら電話サービスだけのものであったが、株式相場又は気象情報の表示など、新しいアプリケーションが誕生した。
【０００５】
この種のアプリケーションを実現するための最初のモデルは、これらのデータの提供業者を、これらデータを当該電話に送信する通信業者に接続するものであった。
【０００６】
この方法は天気など一般的な情報には好適であるが、銀行残高などの重要なデータに関しては不適当である。
【０００７】
従って、そのようなデータが携帯電話通信業者を経由しなければならないことは受け入れ難いことから、この種のサービスは機密性という問題に直面した。
【０００８】
別のアプローチは、セキュアな方法でＳＩＭカードにアクセスするための暗号手段（特に鍵）をプロバイダに付与するというものであった。このアプローチは、通信業者にとっては受け入れ難い、例えば、プロバイダへの通信業者の機密情報の送信という、前述の問題とは逆の問題に直面した。
【０００９】
米国特許第６３８５７２３号明細書（特許文献１）は、電子カード（ＩＣカード）にアプリケーションをロードする方法について記述している。記述されている方法はアプリケーションをカード内にロードできるようになる前に、ロードするアプリケーションを機関（認証機関）により認証することを内容とする。この方法は、高いセキュリティは保証するものの、柔軟さは全くなく、アプリケーションに変更を加える度毎に機関を介在させる。
【００１０】
欧州特許出願第０９７３１３５号明細書（特許文献２）もまた先行技術を記述するものである。専用の機械のみがセキュリティパラメータを更新する資格をもつ。これはむしろ、保護されたゾーン外で行われるセキュリティモジュールの初期化である。この書類では、後でロードされたアプリケーションのアクセス又は終了を可能にする情報は記述されていない。
【特許文献１】米国特許第６３８５７２３号
【特許文献２】欧州特許出願第０９７３１３５号
【発明の開示】
【発明が解決しようとする課題】
【００１１】
従って本発明の目的は、様々な当事者のセキュリティに関する要件を考慮し、セキュア化されたアプリケーションの分散的なダウンロード及び管理を提案することが可能な方法を提供することである。
【課題を解決するための手段】
【００１２】
この目的は、通信業者により管理されるネットワークに接続された装置のセキュリティモジュールの、アプリケーションプロバイダによって使用されるリソースの割り当て方法であって、
【００１３】
‐ 一対の非対称鍵を生成し、プライベート鍵をセキュリティモジュール内に保存し、公開鍵を機関に保存する工程と、
【００１４】
‐ 機関の少なくとも１つの公開鍵をセキュリティモジュール内に入力する工程と、
【００１５】
‐ 少なくも１つのプロバイダの公開鍵を含むプロバイダの要求を通信業者が受信する工程と、
【００１６】
‐ 通信業者が、プロバイダの公開鍵を伴うリソースの予約指示をセキュリティモジュールに送信する工程と、
【００１７】
‐ 通信業者が、セキュリティモジュールの公開鍵をプロバイダに送信する工程と、
【００１８】
‐ プロバイダとセキュリティモジュールの間にセキュア化された通信を確立する工程と、
【００１９】
‐ プロバイダがセキュリティモジュール内にアプリケーションをロードする工程と
を含むリソースの割り当て方法により達成される。
【００２０】
この方法は、あるリソースの予約、更にはそのブロックが通信業者の管理下にある一方で、このリソースの活用はプロバイダの管理下にあり、通信業者はやりとりされるデータにはアクセスできないため、管理された方法でリソースが割り当てられるという長所を有する。
【００２１】
リソースとは、ある部分がプログラムで構成され、また別のある部分がデータで構成されるセキュリティモジュールのメモリ領域である。
【００２２】
セキュリティモジュールのプロセッサは、セキュアな方法、即ち実行に当たってはリソースの領域以外のメモリ領域の範囲を使用しない方法で、リソースのプログラムを実行する。
【００２３】
このリソースにより、プロバイダは例えば銀行の口座番号を保存したり口座所有者を識別したりすることができる。
【００２４】
通信業者がリソースの終了を所望する場合、リソースの管理に関してセキュリティモジュールと対話できるのはその通信業者だけである。リソースの終了又は解放により、このリソース専用のメモリ領域の非アクティブ化又は消去、特に対応するプロバイダの公開鍵の非アクティブ化又は消去が生じる。
【００２５】
この公開鍵が物理的又は仮想的に消失することにより、プロバイダとセキュリティモジュールの間における一切の新規の相互認証が禁止され、同時に、このブロック又は解放されたリソース内でのプロバイダによるアプリケーションの更新又は新規なダウンロードが阻止される。リソース領域は、各領域の使用についての定義が格納されることになる管理部分を含む。
【００２６】
この管理部分は通信業者によって管理される。この管理部分は、プロバイダの識別子、このプロバイダの鍵、及びメモリ領域のアドレシングができるようにする情報を含む。プロバイダが、限られた時間、リソースを使用することができる場合には、この部分は日付情報も含むことができる。この日付を超過すると、リソースは非アクティブ化又は消去され、特にプロバイダの公開鍵が非アクティブ化又は消去される。
【００２７】
別の変形形態によれば、プロバイダ及び／又はエンドユーザーが、限られた実行回数だけリソースを使用することができる場合には、この部分は実行回数情報も含むことができる。この実行回数を超過すると、リソースは非アクティブ化又は消去され、特にプロバイダの公開鍵が非アクティブ化又は消去される。
【発明を実施するための最良の形態】
【００２８】
本発明は、非限定的例として示した添付の図面を参照して行う以下の詳細説明により、よりよく理解されよう。
【００２９】
図１によれば、セキュリティモジュールの製造者などのエンティティＰＳによりセキュリティモジュールＵＳ−ＳＭの初期化が行われる。このエンティティＰＳは、これらのモジュールの管理を担当する機関に対応する公開鍵ＫＰｕＩＳ、並びにこのセキュリティモジュールに固有なプライベート鍵ＫＰｒＵＳを設定する。
【００３０】
以下に記述するように、対称鍵の生成に用いられる生成データｂ、Ｍ（ベース、モジューロ）など他のカスタム化パラメータもセキュリティモジュール内に保存することができる。
【００３１】
カスタム化エンティティＰＳはカスタム化情報、即ちある所与のモジュール（通常、ユニークなアドレス又はユニークな識別子によって識別される）について、その公開鍵ＫＰｕＵＳ、を機関ＩＳに返す。モジュールのメモリサイズ、暗号化モジュールのようなモジュールの特性等、他のデータも機関によって記憶される。
【００３２】
図２は通信業者ＯＰに対するプロバイダＦＯによるリソースの要求操作を示す図である。
【００３３】
プロバイダＦＯは、あるセキュリティモジュールのリソースにアクセスできるようにするために、まず通信業者ＯＰに問い合わせる。次にプロバイダＦＯ及び通信業者ＯＰはパートナシップの方法について同意することになる。われわれの例によれば、通信業者ＯＰと機関ＩＳは異なる２つのエンティティであるので、通信業者ＯＰは必要な情報を機関ＩＳに対し要求する。別の例では、通信業者ＯＰが機関ＩＳの機能を含むことが可能である。
【００３４】
プロバイダＦＯは特にその公開鍵ＫＰｕＦＯを通信業者ＯＰに送信し、必要なリソースの特性を通信業者に知らせる。対称鍵の生成に用いるデータｂ、Ｍもこの時送信することができる。
【００３５】
図３は３つの操作ＳＥＲ、ＲＥＳ及びＡＣＴを示す図である。
【００３６】
予約工程ＲＥＳはセキュリティモジュール内にリソースを作ることを内容とする。加入者は、プロバイダＦＯが提案したサービスを利用したいとの希望を、自身のセキュリティモジュールＵＳ−ＳＭを経由して通信業者ＯＰに送ることができる。そのような場合、通信業者ＯＰはプロバイダＦＯから公開鍵ＫＰｕＦＯを回収し、次に、セキュリティモジュール内でリソースＲＳＣの予約操作を開始する。通信業者は各セキュリティモジュールについてのリソースの使用に関する情報を持つ。通信業者は、プロバイダＦＯのニーズの種類、例えば要求されるメモリ空間のサイズに応じて、最適なリソースを決定する。
【００３７】
通信業者は予約命令をセキュリティモジュールに送るが、勿論この命令は通信業者のプライベート鍵ＫＰｒＯＰによりセキュア化されている。この命令はリソースを予約する。即ち、メモリ領域の一部が、プロバイダとの対話を許可するのに適したデータを受け取る。この操作の際、セキュリティモジュールはプロバイダから、公開鍵ＫＰｕＦＯ、即ちセキュリティモジュールがこのプロバイダとの間でセキュア化されたリンクを確立することができるようにする鍵を受け取る。
【００３８】
この操作の間、通信業者は、もしセキュリティモジュールの鍵を持っていない場合には、機関ＩＳに対し鍵を要求することができる。当然のことながら、この要求はこれらの２つのエンティティの間においてセキュア化された方法で行われる。
【００３９】
第２工程ＡＣＴは、加入者又はセキュリティモジュールのデータをプロバイダＦＯに送信することを内容とする。通信業者ＯＰは、公開鍵ＫＰｕＵＳ、及び自身に割り当てられたリソースＲＳＣの識別子をプロバイダに知らせる。
【００４０】
各セキュリティモジュールの公開鍵がユニークであるということは、一旦セキュリティモジュールＵＳ−ＳＭが識別されると、通信業者ＯＰ又は機関ＩＳは、このモジュールに固有な公開鍵ＫＰｕＵＳをプロバイダに送信するためにデータベース内でこの鍵を検索する。
【００４１】
この初期化が行われたら、このサービスの使用工程ＳＥＲをアクティブ化することができ、ユーザーは、ユーザーがプロバイダに直接リンクできる専用の番号をコールする。プロバイダは最初の任務として、セキュリティモジュールＵＳ−ＳＭ内の、通信業者によって割り当てられたメモリ領域に自身のアプリケーションをロードする。コード及び／又はデータのセキュアなやりとりのためにセッション鍵ＫＳが生成される。
【００４２】
図４はセキュリティモジュールの編成を示す図である。セキュリティモジュールは、処理ユニットＣＰＵ、モジュールの作動プログラムが保存される作業メモリＭＥＭ、外部リソース用のメモリ領域から成る。この領域は、リソースＲＳＣ１からＲＳＣ４を定義するデータを含む第１の定義部分ＤＥＦを有する。実際には、リソースのメモリ領域は必ずしも予め分割されている必要はない。プロバイダが通信業者に対しリソースを要求する時には、必要なメモリサイズを指定することもできる。従って、各リソースが使うメモリが少なければ少ないほど、リソースのメモリ領域はより多くの異なるリソースを含むことができる。定義部分ＤＥＦは各リソースの開始及び終了情報を含む。
【００４３】
各リソースＲＳＣには、例えば、暗号アルゴリズム或いは他の特別な計算プロセス等、セキュリティモジュールＵＳ−ＳＭ上で使用可能ないくつかのプログラミングインタフェース（又はライブラリ）へのアクセス権を示す追加情報を関連付けることができる。そのような情報は例えばＤＥＦ領域又はそれぞれのＲＥＳ領域内に保存することができる。
【００４４】
モジュールＩ／Ｏは携帯電話などのホスト機器との通信を図式化する。
【００４５】
２つのエンティティ間でセキュア化された接続を確立するにはいくつかの方法がある。本発明の範囲内では、一対の非対称鍵を使用し、主エンティティがプライベート鍵を有し、第３のエンティティが公開鍵を受け取るようになっている。プライベート鍵は原則として通信手段によっては送信されず、セキュア化初期化工程時に装置内に直接入力される。公開鍵は、上で記述した、この装置と対話するための手順に従い送信される。
【００４６】
実際には、公開鍵のやりとりはこの鍵に関連付けられた証明書を使用して行われることが多い。エンティティＢがエンティティＡから公開鍵を受け取る時、この鍵は、エンティティＡが信頼している機関、例えば通信業者により署名された証明書の中に含まれている。また、エンティティＡ及びＢが既に予め相互認証していて、通信に用いるチャンネルが安全であって、証明書なしの公開鍵を送信し合うことができるようになる場合もある。
【００４７】
鍵ＲＳＡ等の非対称鍵によりパートナの認証を行うことが可能である。エンティティＡは、自身のプライベート鍵ＫＰｒＡを使用する操作により自身の認証を行う。するとエンティティＢは、対応する公開鍵ＫＰｕＡを使用してこの認証の有効性を確認することができる。非対称鍵に基づいた暗号化は重く、大がかりな暗号化手段を必要とする。通常、非対称鍵は、対称セッション鍵の認証及び生成に使用されるのはそのためである。また、認証用として非対称鍵を使用し、対称セッション鍵の生成用としてＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎが記述した方法を用いることも可能である。
【００４８】
実施形態のうちの１つによれば、リソースを予約する工程は、プロバイダの公開鍵ＫＰｕＦＯの送信に加え、このプロバイダに固有なＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎパラメータ、即ちモジュールＭ又はベースｂの送信を含む。従って、プロバイダと加入者のセキュリティモジュールの間におけるセッション鍵の確立の際には、これらのパラメータが使用されるが、その時、これらのパラメータを再送信する必要はない。
【００４９】
セキュリティモジュールと通信業者の間にセッション鍵を生成するために、この同じＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎ法を使用することが可能であり、その場合、セキュリティモジュールを初期化する工程は、通信業者に固有なＤｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎパラメータをセキュリティモジュール内に入力することを内容とする追加の工程を含むことがある。
【００５０】
セキュア化されたリンクの確立の第１形態によれば、２つの装置間のデータのやりとりには他方の装置の公開鍵が用いられる。この方法は、やりとりをセキュア化することが可能な対称鍵ＫＳが生成されると同時に、パートナの認証が行われるという長所を有する。
【００５１】
セキュア化されたリンクの確立の第２形態によれば、Ｄｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎパラメータに基き、従来の方法によりエンティティＡとＢの間にセッション鍵が生成される。一旦このセッション鍵が確立されると、相互認証手順が開始する。例えばエンティティＡは、自身のプライベート鍵ＫＰｒＡを使用して、Ｄｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎネゴシエーションの際にＢとの間でやりとりされる値のうちのいくつかに署名し、このようにして生成した署名をＢに送ることができる。するとエンティティＢは、鍵ＫＰｕＡにより書名を確認してＡを認証することができる。同様にエンティティＢは、自身のプライベート鍵ＫＰｒＢを使用して、Ｄｉｆｆｉｅ＆Ｈｅｌｌｍａｎｎネゴシエーションの際にＡとの間でやりとりされる値のうちのいくつかに署名し、このようにして生成した署名をＡに送ることができる。するとエンティティＡは、鍵ＫＰｕＢにより書名を確認してＢを認証することができる。
【００５２】
このセキュア化されたリンクを確立するために、例えば、前述の２つの工程を逆にすることにより、即ち、２つのパートナを認証するのに公開／プライベート鍵暗号化を使用し、次にセッション鍵を生成する等、他の方法も存在する。
【００５３】
実際には、種々のエンティティが様々な工程に関わることがあり得る。鍵の生成は第１機関に委任され、第１機関は、これらの鍵、少なくともプライベート部分を、セキュリティモジュールのカスタム化のために、インテグレータに通知する。この生成はセキュリティモジュール内で直接行うことができること、及び初期化工程の際、セキュアな環境下で、公開鍵のみが通信されることに留意すべきである。
【００５４】
各セキュリティモジュールのユニークな番号（ＵＡ）に関連付けられた公開鍵のこのデータベースは、通信業者によって管理されるか、第３のエンティティに委ねられる。通信業者の代わりにリソースの割り当て機能を確保するのはこのエンティティである。
【００５５】
本発明の別の実施形態によれば、アプリケーションのロードはグローバルな方法で行うことができるのが望ましい。セキュリティモジュールはモジュール毎にユニークな鍵を使用することから、リソースの予約時に、中間工程が付加される。通信業者ＯＰによりセキュリティモジュールに送信されるパラメータに、ある所与のアプリケーションに関して全てのセキュリティモジュールに共通な鍵であるドメイン鍵が付加される。リソースの定義は、セキュリティモジュールのハードウェア的能力に応じて、各セキュリティモジュールに特有であるが、一旦定義されると、全てのモジュールに共通な論理名称及び共通鍵が与えられる。従ってプロバイダＦＯは、接続されている全てのモジュールに分散モードにて自身のアプリケーションを同時にダウンロードするか、このモジュールがプロバイダのサーバーに呼び出された時に、セキュリティモジュールとは独立した手順によりダウンロードすることができる。このドメイン鍵ＤＫは本方法の実施方法によって、対称型とすることも、非対称型とすることも可能である。この鍵は、セキュア化されたリンクの確立時、セキュリティモジュールの公開／プライベート鍵の対はこの鍵に取って換えられる。
【図面の簡単な説明】
【００５６】
【図１】図１はセキュリティモジュールの個人登録段階を示す図である。
【図２】図２はプロバイダと通信業者の間の送信を示す図である。
【図３】図３は３つのエンティティ間のデータのやりとりを示す図である。
【図４】図４はリソース割り当てセキュリティモジュールを示す図である。
【特許請求の範囲】
【請求項１】
通信業者(OP)により管理されるネットワークに接続された装置のセキュリティモジュールの、アプリケーションプロバイダ(FO)によって使用されるリソース(RSC)の割り当て方法であって、
‐ 一対の非対称鍵を生成し、プライベート鍵をセキュリティモジュール(US-SM)内に保存し、公開鍵(KPuUS)を機関(IS)に保存する工程と、
‐ 機関の少なくとも１つの公開鍵(KPuUS)をセキュリティモジュール(US-SM)内に入力する工程と、
‐ プロバイダ(FO)の要求を通信業者(OP)が受信し、少なくも１つのプロバイダの公開鍵(KPuFO)を含むこの要求を機関(IS)に送信する工程と、
‐ 通信業者(OP)が、プロバイダの公開鍵(KPuFO)を伴うリソース(RSC)の予約指示をセキュリティモジュール(US-SM)に送信する工程と、
‐ 通信業者(OP)が、セキュリティモジュールの公開鍵(KPuUS)をプロバイダ(FO)に送信する工程と、
‐ プロバイダ(FO)とセキュリティモジュール(US-SM)の間にセキュア化された通信を確立する工程と、
‐ プロバイダ(FO)がセキュリティモジュール(US-SM)内にアプリケーションをロードする工程と
を含むリソースの割り当て方法。
【請求項２】
セキュリティモジュールにより一対の非対称鍵が生成され、公開鍵が機関に送信されることを特徴とする、請求項１記載のリソースの割り当て方法。
【請求項３】
通信業者に固有のセッション鍵(M, b)の初期化パラメータが、初期化時にセキュリティモジュール内に保存されることを特徴とする、請求項１記載のリソースの割り当て方法。
【請求項４】
プロバイダがセッション鍵(M, b)の初期化パラメータを通信業者に送信し、リソースの予約時にこれらのパラメータがセキュリティモジュールに送信されることを特徴とする、請求項１ないし３いずれか１項に記載のリソースの割り当て方法。
【請求項５】
プロバイダとセキュリティモジュールの間のセキュア化された通信の確立が、セキュリティモジュールによるプロバイダの公開鍵の使用、及びプロバイダによるセキュリティモジュールの公開鍵の使用に基づくことを特徴とする、請求項１ないし４いずれか１項に記載のリソースの割り当て方法。
【請求項６】
通信業者とセキュリティモジュールの間のセキュア化された通信の確立が、通信業者の初期化パラメータ(M, b)を使用するセッション鍵の生成に基づくことを特徴とする、請求項３記載のリソースの割り当て方法。
【請求項７】
プロバイダとセキュリティモジュールの間のセキュア化された通信の確立が、プロバイダの初期化パラメータ(M, b)を使用するセッション鍵の生成に基づくことを特徴とする、請求項４記載のリソースの割り当て方法。
【請求項８】
機関(IS)及び通信業者(OP)が同一のエンティティを形成することを特徴とする、請求項１ないし７いずれか１項に記載のリソースの割り当て方法。
【請求項９】
リソース(RES)の予約指示が、あるアプリケーションに特有であってこのアプリケーションを所有する全てのセキュリティモジュールに共通なドメイン鍵(DK)の送信を含み、プロバイダFOとセキュリティモジュールの間のセキュア化された通信の確立にこの鍵が使用されることを特徴とする、請求項１ないし８いずれか１項に記載のリソースの割り当て方法。
【請求項１】
通信業者(OP)により管理されるネットワークに接続された装置のセキュリティモジュールの、アプリケーションプロバイダ(FO)によって使用されるリソース(RSC)の割り当て方法であって、
‐ 一対の非対称鍵を生成し、プライベート鍵をセキュリティモジュール(US-SM)内に保存し、公開鍵(KPuUS)を機関(IS)に保存する工程と、
‐ 機関の少なくとも１つの公開鍵(KPuUS)をセキュリティモジュール(US-SM)内に入力する工程と、
‐ プロバイダ(FO)の要求を通信業者(OP)が受信し、少なくも１つのプロバイダの公開鍵(KPuFO)を含むこの要求を機関(IS)に送信する工程と、
‐ 通信業者(OP)が、プロバイダの公開鍵(KPuFO)を伴うリソース(RSC)の予約指示をセキュリティモジュール(US-SM)に送信する工程と、
‐ 通信業者(OP)が、セキュリティモジュールの公開鍵(KPuUS)をプロバイダ(FO)に送信する工程と、
‐ プロバイダ(FO)とセキュリティモジュール(US-SM)の間にセキュア化された通信を確立する工程と、
‐ プロバイダ(FO)がセキュリティモジュール(US-SM)内にアプリケーションをロードする工程と
を含むリソースの割り当て方法。
【請求項２】
セキュリティモジュールにより一対の非対称鍵が生成され、公開鍵が機関に送信されることを特徴とする、請求項１記載のリソースの割り当て方法。
【請求項３】
通信業者に固有のセッション鍵(M, b)の初期化パラメータが、初期化時にセキュリティモジュール内に保存されることを特徴とする、請求項１記載のリソースの割り当て方法。
【請求項４】
プロバイダがセッション鍵(M, b)の初期化パラメータを通信業者に送信し、リソースの予約時にこれらのパラメータがセキュリティモジュールに送信されることを特徴とする、請求項１ないし３いずれか１項に記載のリソースの割り当て方法。
【請求項５】
プロバイダとセキュリティモジュールの間のセキュア化された通信の確立が、セキュリティモジュールによるプロバイダの公開鍵の使用、及びプロバイダによるセキュリティモジュールの公開鍵の使用に基づくことを特徴とする、請求項１ないし４いずれか１項に記載のリソースの割り当て方法。
【請求項６】
通信業者とセキュリティモジュールの間のセキュア化された通信の確立が、通信業者の初期化パラメータ(M, b)を使用するセッション鍵の生成に基づくことを特徴とする、請求項３記載のリソースの割り当て方法。
【請求項７】
プロバイダとセキュリティモジュールの間のセキュア化された通信の確立が、プロバイダの初期化パラメータ(M, b)を使用するセッション鍵の生成に基づくことを特徴とする、請求項４記載のリソースの割り当て方法。
【請求項８】
機関(IS)及び通信業者(OP)が同一のエンティティを形成することを特徴とする、請求項１ないし７いずれか１項に記載のリソースの割り当て方法。
【請求項９】
リソース(RES)の予約指示が、あるアプリケーションに特有であってこのアプリケーションを所有する全てのセキュリティモジュールに共通なドメイン鍵(DK)の送信を含み、プロバイダFOとセキュリティモジュールの間のセキュア化された通信の確立にこの鍵が使用されることを特徴とする、請求項１ないし８いずれか１項に記載のリソースの割り当て方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００９−５１４２５５（Ｐ２００９−５１４２５５Ａ）
【公表日】平成２１年４月２日（２００９．４．２）
【国際特許分類】
【出願番号】特願２００６−５１６１７６（Ｐ２００６−５１６１７６）
【出願日】平成１６年６月２２日（２００４．６．２２）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５１１９８
【国際公開番号】ＷＯ２００４／１１４２２９
【国際公開日】平成１６年１２月２９日（２００４．１２．２９）
【出願人】（５００４７７９９７）ナグラカード エス． アー． (16)
【Ｆターム（参考）】
【公表日】平成２１年４月２日（２００９．４．２）
【国際特許分類】
【出願日】平成１６年６月２２日（２００４．６．２２）
【国際出願番号】ＰＣＴ／ＥＰ２００４／０５１１９８
【国際公開番号】ＷＯ２００４／１１４２２９
【国際公開日】平成１６年１２月２９日（２００４．１２．２９）
【出願人】（５００４７７９９７）ナグラカード エス． アー． (16)
【Ｆターム（参考）】
[ Back to top ]