仮想サブスクライバ識別モジュール
vSIM(virtual subscriber identify module)サービスを提供するように構成されたMTP(mobile trusted platform)を開示する。一実施形態では、MTPは、MTPの製造メーカーに関係する信用証明書を格納し、提供するように構成されたTSS−DM(デバイス製造メーカートラステッドサブシステム)と、MNO(モバイルネットワークオペレータ)に関係する信用証明書を格納し、提供するように構成されたMNO−TSS(モバイルネットワークオペレータ−トラステッドサブシステム)と、MTPのユーザに関係する信用証明書を格納し、提供するように構成されたTSS−DO/TSS−U(デバイスユーザ/所有者−トラステッドサブシステム)とを含む。TSS−MNOは、MNOに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIMコアサービスユニットを含む。TSS−DO/TSS−Uは、MTPのユーザ/所有者に関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM管理ユニットを含む。TSS−DO/TSS−UおよびTSS−MNOは、トラステッドvSIMサービスを介して通信する。
【発明の詳細な説明】
【技術分野】
【0001】
本願は、無線通信に関する。
【背景技術】
【0002】
無線通信デバイスの数の増加に伴って、SIM(Subscriber Identity Module:契約者情報記録モジュール、電話番号を特定するための固有のID番号が記録されたICモジュール)カードまたはUICC(Universal Integrated Circuit Card)内で実行される現在のSIM機能に対するより動的な解決策を提供し、現代のおよび開発中のモバイル通信ネットワークに関して、いくつかの短所を克服する必要がある。UICCは、そこからSIM認証アルゴリズムを実行し、信用証明書を格納する、安全な実行および格納環境を有する。しかし、UICCのコスト、その非実用的な形状因子、および制限された機能性が、モバイルネットワークの操作者(オペレータ)が無線デバイスを購入してからしばらく後でのみ知るアプリケーションでの使用を妨げる。あるいは、UICCは、複数の操作者のネットワークを1つのデバイス内で同時にサポートしまたはアクセスしなければならない時に、役に立たなくなくなる。モバイルネットワークおよびサービスのサブスクリプション(加入契約)を更新するか、あるいは変更する方法は、SIMカードに関して制限されているので、無線の配備が望まれる場合に、一般に欠如している。
【0003】
さらに、SIMカードまたはUICCは、一般に、非常に安全と考えられるが、このセキュリティは、それが常駐するデバイス全体のセキュリティの属性に強くリンクされていない。これは、モバイル金融取引などの高度なサービスやアップリケーションに関するセキュリティのスケーリング(拡大縮小)のコンセプトの適用を制限する。これらの問題のすべてが、たとえばmachine−to−machine(M2M)通信シナリオで、モバイルネットワークに接続された自律的デバイスに対して切迫している。
【発明の概要】
【発明が解決しようとする課題】
【0004】
したがって、SIM機能に対するより動的で同時に安全なソフトウェアベースの解決策が必要である。
【課題を解決するための手段】
【0005】
vSIM(virtual Subscriber Identify Module;仮想サブスクライバ識別モジュール)サービスを提供するように構成されたMTP(Mobile Trusted Platform;携帯情報機器向けのセキュリティ機構仕様、移動体通信セキュリティプラットフォーム)を開示する。一実施形態では、MTPは、MTPの製造メーカーに関係する信用証明書を格納し、提供するように構成されたTSS−DM(装置製造メーカーの信頼されたサブシステム)と、MNO(移動体通信オペレータ)に関係する信用証明書を格納し、提供するように構成されたTSS−MNO(モバイルネットワークオペレータ−トラステッドサブシステム)と、MTPのユーザに関係する信用証明書を格納し、提供するように構成されたTSS−DO/TSS−U(装置所有者/ユーザの信頼されたサブシステム)とを含む。TSS−MNOは、MNOに関係する信用証明書情報を格納し、提供し、かつ処理するように構成されたvSIM(仮想契約者情報記録モジュール)コアサービスユニットを含む。TSS−DO/TSS−Uは、MTPのユーザに関係する信用証明書情報を格納し、提供し、かつ処理するように構成されたvSIM管理ユニットを含む。TSS−DO/TSS−UおよびTSS−MNOは、トラステッドvSIMサービスを介して通信する。オプション(随意)で、MTPは、デバイスユーザ機能およびデバイス所有者機能をTSS−DOとTSS−Uとに分離することができ、MTPの第2ユーザに関係する信用証明書を格納し、提供するように構成された第2のTSS−Uを含むことができる。また、MTPは、MTPの所有者に関係する信用証明書を格納し、提供するように構成されたTSS−DO(デバイス所有者−トラステッドサブシステム)を含むことができる。MTPは、第2のMNOに関係する信用証明書を格納し、提供するように構成された第2のMNO−TSSをも含むことができる。
【0006】
vSIMサービスを提供する際に使用されるトラステッドサブシステムをリモート(遠隔)で作成する手順をも開示する。
【0007】
vSIMサービスを提供する際に使用されるトラステッドサブシステムを登録し、記録する手順をも開示する。
【0008】
遠隔位置からMTPにvSIMサービスを提供する際に使用されるトラステッドサブシステムを配送する手順をも開示する。
【0009】
ソースMTPからターゲットMTPにvSIMサービスを提供する際に使用されるトラステッドサブシステムを移行する手順をも開示する。
【0010】
vSIM構成を使用するサブスクライバ(電話加入者)が無線ネットワークにアクセスすることを可能にする3つの関連する方法をも開示する。
【0011】
より詳細な理解は、添付図面に関連して例として与えられた下記の説明から得ることができる。
【図面の簡単な説明】
【0012】
【図1】ソフトウェアベースのvSIM(virtual subscriber identify module)を使用することで、サービスを使用し、サブスクライバアイデンティティを判定するように構成された通信システムアーキテクチャの例を示す図である。
【図2】単一ユーザのモバイルトラステッドプラットフォーム(mobile trusted platform)のvSIMアーキテクチャの例を示す図である。
【図3】マルチユーザモバイルトラステッドプラットフォームのvSIMアーキテクチャ300の例を示す図である。
【図4】初期のモバイルトラステッドプラットフォーム上でTSS−MNOをインストールする手順を示す図である。
【図5】vSIM信用証明書のサブスクライバ登録および配送の手順を示す図である。
【図6】vSIM信用証明書のサブスクライバ関連部分の安全な配送およびインストールの第2フェーズの手順の例を示す図である。
【図7】ソースプラットフォームからターゲットプラットフォームへvSIM信用証明書またはその実行環境を移行する手順の例を示す図である。
【図8】通信サブスクライバのアクセスを可能にする第1手順を実行するように構成された通信システムの例を示す図である。
【図9】通信サブスクライバのアクセスを可能にする第2手順を実行するように構成された通信システムの例を示す図である。
【図10】通信サブスクライバのアクセスを可能にする第2手順を実行するように構成された通信システムのもう1つの例を示す図である。
【図11A】一般ネットワークインフラストラクチャについて通信サブスクライバのアクセスを可能にする第3手順を示す図である。
【図11B】一般ネットワークインフラストラクチャについて通信サブスクライバのアクセスを可能にする第3手順を示す図である。
【発明を実施するための形態】
【0013】
以下で言及する時に、用語「無線送受信ユニット(WTRU)」は、ユーザ装置(UE)、移動局、固定のまたは可動のサブスクライバユニット、ポケットベル、セル電話機、携帯情報端末(PDA)、コンピュータ、モバイルトラステッドプラットフォーム、または無線環境内で動作できるすべての他のタイプのユーザデバイスを含むが、これらに限定はされない。下で言及する時に、用語「基地局」は、Node−B、サイトコントローラ、アクセスポイント(AP)、または無線環境内で動作できるすべての他のタイプのインターフェースするデバイスを含むが、これらに限定はされない。用語「信頼性(trustworthiness)」は、アプリケーションおよび/またはサービスの状態を記述する標準と考えられる。この状態は、アプリケーションおよび/またはサービスが、その保全性および正しい機能の表示を直接にまたは間接に提供できることを意味する。
【0014】
図1に、ソフトウェアベースのvSIM(virtual subscriber identify module)を使用することでサービスを使用し、サブスクライバアイデンティティを判定するように構成された通信システムアーキテクチャの例を示す。通信システム100は、ユーザすなわちデバイスの所有者(持ち主)(DO)110、トラステッドモバイルプラットフォーム120、基地局130、MNO(ネットワークサービスプロバイダ;移動体通信事業者)140、およびPOS(店舗、販売場所)150を含む。DO 110は、POS 150との登録および記録155のためにPOSと通信する。POS 150は、サブスクライバ登録160を実行するためにMNO 140と通信する。MNO 140は、vSIM信用証明書165を配送するためにトラステッドモバイルプラットフォームと通信する。DO 110は、ユーザを認証する170ためにトラステッドモバイルプラットフォーム 120に情報を提供する。その後、トラステッドモバイルプラットフォームは、サブスクライバ認証175を基地局130に送信する。その後、基地局130は、ユーザ認証情報を検証するためにMNO 140と通信する。
【0015】
一般に、図1のvSIMアーキテクチャは、永久的に割り当てられたトラステッドアンカ(trusted anchor;信頼アンカ)に基づき、複数の別々のトラステッド実行環境またはサブシステムをサポートする、トラステッドオペレーティングシステムによって保護される。図示されているように、1つの実行環境が、特定の利害関係者に割り当てられ、図示されたものを超える追加の利害関係者が、存在することが可能である。
【0016】
図1に示されたアーキテクチャは、4つの重要なエンティティを考慮に入れている。このシナリオ(筋書き)では、DO/Uは、モバイル通信ネットワークおよびそこで提供されるサービス(たとえば、GSM、UMTS電話、データサービス、または特殊化されたロケーションベースのサービス)を使用するために、MNOとの長期的関係を確立することを意図している。
【0017】
物理的に存在するSIMカードを使用する代わりに、MNOは、MTP(mobile trusted platform)にソフトウェアベースのアクセス認可信用証明書またはvSIM信用証明書を提供する。vSIM信用証明書は、サブスクライバ関連部分およびユーザ関連部分からなる。登録されたデバイスユーザが、最初に通信ネットワークによって認可されなければならなくなるたびに、そのユーザは、まず、vSIM信用証明書のユーザ関連部分を介してvSIMサービスについて認証される。通信関係の過程において、このサービスは、vSIM信用証明書のサブスクライバ関連部分をネットワーク認証に使用する。
【0018】
図2に、単一ユーザのMTP(mobile trusted platform)200のvSIMアーキテクチャの例を示す。モバイルトラステッドプラットフォーム 200は、3つの別々のTSS(トラステッドサブシステム)202、204、206を含む。第1のTSS 202は、DM(デバイス製造メーカー)に割り当てられる。第2のTSS 204は、MNO(ネットワークサービスプロバイダ)に割り当てられる。第3のトラステッドTSS 206は、DO 206に割り当てられる。TSS−DOを、ユーザに割り当てることもできる(TSS−U)ことに留意されたい。3つのTSS 202、204、206のそれぞれが、標準サービスユニット210a、210b、210c、トラステッドサービスユニット212a、212b、212c、およびトラステッドリソースユニット214a、214b、214cを含む。MNOトラステッドTSS 204は、MNOに関係するSIM機能を実行するvSIMコアユニット220をも含む。DOトラステッドTSS 206は、DOに関係するSIM機能を実行するvSIM管理ユニット222をも含む。vSIMコアユニット220およびvSIM管理ユニット222は、トラステッドリンク224を介して通信し、組み合わさって、少なくとも従来のUSIM(universal subscriber identity module:全域契約者情報記録モジュール)の機能を実行する。
【0019】
図3に、マルチユーザMTP300のvSIMアーキテクチャの例を示す。モバイルトラステッドプラットフォーム 300は、4つの別々のTSS 302、304、306、および308を含む。第1のTSS 302は、DM(デバイス製造メーカー)に割り当てられる。第2のトラステッドTSS 304は、ネットワークサービスプロバイダに割り当てられる。第3のTSS 306は、第1ユーザに割り当てられる。第4のTSS 308は、デバイス所有者308に割り当てられる。4つのTSS 302、304、306、および308のそれぞれは、標準サービス(normal services)ユニット310a、310b、310c、310d、トラステッドサービスユニット312a、312b、312c、およびリソースユニット314a、314b、314cを含む。MNO TSS 304は、MNOに関係するSIM機能を実行するvSIMコアユニット320をも含む。ユーザTSS 306/308は、ローカルユーザの管理および認証に関係する機能を実行するvSIMサブスクライバ管理サービス322/323をも含む。より具体的に言うと、このサービスは、ローカルユーザのアイデンティティに関して認証が与えられるように、vSIMコアサービス320に認証オラクル(authentication oracle)を提供する。vSIMコアユニット320およびvSIM管理ユニット322は、トラステッドリンク324を介して通信し、それらが協働して、少なくとも従来のUSIM(universal subscriber identity module)の機能を実行する。
【0020】
一般に、MTP 200および300は、複数の保護された別々の実行環境をサポートする。各環境は、利害関係者(stakeholder)に関連するエリアを表す。MTP 200および300は、従来のスマートカードベースのSIMカードおよびその機能を置換するvSIMサービスを実施するように構成されている。一般に、vSIMサービスは、(少なくとも)図2に示された3つの異なる実行環境に拡張されるが、例によって図3に示された、多数の他の実行環境をサポートするように拡張することもできる。
【0021】
図2および図3に示されているように、複数の異なるsigma(利害関係者)すなわち、DM(デバイス製造メーカー)、ネットワークアクセスおよびサービスプロバイダ(モバイルネットワークオペレータ、MNO)、DO(デバイス所有者)、およびU(ユーザ)が考慮される。トラステッドサブシステムTSS−sigmaは、TE−sigma(トラステッド実行環境、セキュリティ実施環境)およびTM(交換不能セキュリティモジュール、トラステッドモジュール)またはRO(遠隔の持ち主)もしくはsigma(利害関係者)に関連するTM−sigma(セキュリティモジュールのエンティティ)を含む論理ユニットとして構成される。TSS−sigmaは、必ずすべての所与のデータに署名し、暗号化するように構成される。TSS−sigmaは、トラステッドサービスRTV−sigmaへのアクセスを有する。このサービスは、たとえば、基準データに基づく定義されたシステム状態の検証の責任を負う。本明細書で提案される類似するアーキテクチャのさまざまな他のトラステッドサブシステムを、以下で例として説明する。これは、利害関係者DM、MNO、DO、およびUのサブシステムTSS−DM 202および302、TSS−MNO 204および304、TSS−DO 206および306、ならびにTSS−U 206および308を含む。
【0022】
TSS−DM 202および302は、そのインストールされたハードウェアコンポーネントと一緒にデバイスの保全性(integrity)、構成、およびインストールの責任を負う。TSS−DM 202および302は、デバイスのすべてのセキュリティに敏感なリソースを提供する。TSS−DM 202および302は、一般に、すべての内部通信および外部通信を制御し、通信チャネルを保護する。その結果、TSS−sigmaのすべてのプロトコルメッセージは、その宛先ポイントのTSS−DM 202および302の通信サービスによって伝送される。
【0023】
あるプラットフォームのすべてのサブスクリプション依存およびサブスクライバ(電話加入者、契約者)関連のネットワークプロバイダサービスは、TSS−MNO 204および304に割り当てられる。このサブシステムは、vSIM信用証明書のサブスクライバ関連部分を管理し、保護する責任を負い、サブスクライバのクライアントサイドネットワーク認証を実行する。このサブシステムは、このためにvSIM−CORE(vSIMコアサービス)を提供する。vSIM−CORE 220および320は、従来のSIMの本質的機能(サブスクライバ認証)を置換するように構成されるが、他の認証機能にも対処することができる。用語「トラステッドサブシステムTSS−MNO」は、必要なvSIM−COREサービス220および320を提供する完全装備のTSS−MNOと同義である。TSS−DMおよびTSS−MNOの組合せも可能である。vSIMコアサービスが、サブスクライバデータの安全な格納および使用ならびにMNOとのサブスクライバ認証の責任を負うことにも留意されたい。
【0024】
TSS−U 206および306は、すべてのユーザ関連情報およびプライベート情報、具体的にはユーザの関連するアクセス認可信用証明書(vSIM信用証明書のユーザ関連部分)を保護する。TSS−U 206および306は、vSIMの管理サービス(vSIM−MGMT)222のインスタンスを作成する。このサービスは、ユーザ情報の管理およびローカルユーザに関する認証応答の計算の責任を負う。サービスvSIM−MGMTは、サービスvSIM−COREに内部認証オラクルを与える。したがって、vSIM−MGMTは、認証照会の後に、ローカルユーザのアイデンティティの証明を提供することができる。このサービスは、vSIMのユーザ管理、具体的にはデバイスユーザのアドミニストレーションおよび管理の責任を負う。vSIM内の所有者管理サービスvSIM−OwnMGMTは、機能的にvSIM−MGMTにイメージ化される。すべてのTSS−Uが、ディジタル署名のために所期のプラットフォームユーザUによってのみアクセスでき使用できる適切な暗号法鍵を生成できることにも留意されたい。
【0025】
TSS−DO 206および308は、vSIMの持ち主の管理サービス(vSIM−OwnMgmt)のインスタンスを作成する。このサービスは、所有者情報を管理し、ローカルユーザまたはサービスプロバイダに関するものなどの事業管理(administrative management)の責任を負う。TSS−DOおよびTSS−Uを、単一ユーザシステムについては図2に示されているように1つに組み合わせることもできる。
【0026】
一般に、MTPは、ハードウェアプラットフォームに永久的に関連付けられた交換不能なセキュリティモジュール(トラステッドモジュール、TM)を有するモバイルプラットフォームである。検討中のvSIアーキテクチャの文脈では、MTPは、従来のSIMカードなどのサブスクライバ認証用の従来のセキュリティトークンを義務的に備えてはいない。MTPは、トラステッドオペレーティングシステムを動作させる。トラステッドソフトウェアレイヤ(trusted software layer;信頼されたソフトウェア層)は、保護され隔離された実行およびメモリ機能を有する複数の別々のトラステッドサブシステム(TSS_SIGMA)をサポートする。
【0027】
各トラステッドサブシステム(TSS_SIGMA)は、利害関係者のクリティカルなセキュリティ機能に使用される。トラステッドサブシステムは、セキュリティモジュールのトラステッドエンティティ(TM−SIGMA)および関連するトラステッド実行環境(トラステッドエンジン、TE_SIGMA)、ならびにトラステッドサービス(TS_SIGMA)からなる。遠隔所有者DM、MNO、Uの代わりに、少なくとも、3つのトラステッドサブシステムTSS−DM、TSS−MNO、TSS−Uが、MTP上に存在する。手順を、単一ユーザシステムについて説明する。デバイス所有者DOおよびTSS−DOの機能は、UまたはTSS−Uについてイメージ化される。
【0028】
MNOが、公開鍵インフラストラクチャの必要な機能を直接にまたは間接に提供することに留意されたい。MNOは、証明機関CAによって発行された証明書Cert−MNOを所有する。この証明書は、MNOのアイデンティティを公開鍵K−pub−MNOにリンクし、この公開鍵K−pub−MNOは、ディジタル署名をチェックするのに必要である。この証明書は、MTPおよびすべての組込みサービスから使用可能である。
【0029】
以下で説明する手順が、例のみのために単一ユーザシステムを検討することに留意されたい。その結果、デバイス所有者DOは、ユーザUと同等にされる。図3に示されているように、別々のTSS−DOおよびTSS−Uを有する複数ユーザシステムでのサブスクライバ認証の方法は、類似する形で実行され、本願の範囲内にあるはずである。他のマルチユーザシナリオ、たとえば(1)1つのTSS−Uおよび複数のTSS−MNO、(2)1つのTSS−MNOおよび複数のTSS−U、ならびに(3)複数のTSS−Uおよび複数のTSS−MNOが可能である。所有権制御(ownership control)の迂回を防ぐために、1つのDOだけが、すべてのそのような構成で許容可能であるとしている。さまざまなマルチユーザシナリオで、vSIM−MGMTサービスは、DOだけに適用されるので、すべてのユーザならびに複数のvSIM−COREサービス表明について立場を明らかにせず、これらと互換になるように構成される。したがって、単一ユーザについて、vSIM−MGMTは、vSIM−MGMT−DO機能およびvSIM−MGMT−U機能に分離される。これは、たとえばユーザのグループ(たとえば、家族)が同一のMNO加入を使用する場合、または、その一方で、単一のユーザが、状況に応じて、たとえば海外にいる時に、複数のMNO加入から選択したい時のアプリケーション(適用)のシナリオに有利である。これらを実施する好ましい方法は、vSIM−COREおよび/またはvSIM−MGMTのいずれかが、めいめいのTSSの間およびさまざまなvSIM−MGMTおよびvSIM−OwnMgmtの間の所望の1対n関係、n対1関係、またはn対m関係を確立するために、めいめいの他のTSS内のめいめいの他のサービスの認可秘密(authorization secret)を含む保護されたデータベースを保持することである。
【0030】
図2および図3の提案されるvSIMアーキテクチャは、従来のセキュリティトークンに基づくサブスクライバ認証用の従来のアーキテクチャと同等のセキュリティ特性を仮定する。具体的に言うと、これらのアーキテクチャは、保護されたストレージ機能、別々の改竄保護された実行環境、およびユーザの認証を引き受ける。vSIMプラットフォームは、認可される対象だけがvSIM信用証明書の保護されたデータにアクセスし、またはこれを操作することができることをも保証しなければならない。これは、データが、vSIM実行環境へまたは他のトラステッドサービスへ移動中であるか、MTPの揮発性メモリまたは不揮発性メモリに格納されているか、実行環境内で実行されまたは使用されるか、認可された対象によってさまざまなトラステッド環境の間で転送される間に、特に重要である。これは、セキュリティに敏感なデータを破壊も変更もできず、アクセス制御機構を開始することもできない、攻撃者の特徴を含む。このシステムは、セキュリティに敏感なデータの消失および脱出をも防ぎ、すべての必要なサービスが使用可能であり、機能することを保証しなければならない。具体的に言うと、vSIMアーキテクチャは、認可された対象が適切な(ローカルまたは遠隔の)所有者を介してのみセキュリティに敏感なサービスにアクセスできることを保証しなければならない。
【0031】
図4に、MNO 408と通信するTSS−DM(デバイス製造メーカー用のTSS)404およびTSS−U(ユーザ用のTSS)402を有する初期モバイルトラステッドプラットフォーム 403上でMNO−TSS 406をインストールする手順400を示す。用語TSS−MNOが、この手順によって確立されるトラステッドサブシステムとこの手順の終りにTSS−MNOになるTE−MNO(TE(トラステッド実行環境)MNO)との両方を指すのに使用されることに留意されたい。RO(遠隔所有者)による占有は、遠隔所有者または利害関係者とMTPとの間の信頼の基礎的で基本的な関係を確立する。この手順は、空のまたは初期の実行環境が存在することを必要とする。手順の第1部分410は、空の実行環境の準備専用であり、第2部分412は、新たに作成されるTE(トラステッドエンジン)の遠隔所有権獲得専用である。TSS*−MNO(初期TSS−MNO)は、基本機能性および/または複数のトラステッドサービスを有するTE*−MNO(初期標準実行環境)からなる。サブシステムTSS*−MNOが、MNOにその手の付けられていない構成、構造、およびそのセキュリティポリシに関する適合の証明を与えることができる時には、サブシステムTSS*−MNOは、MNOによって証明される。
【0032】
手順400の前処理部分410は、420で、TSS−U 402がTSS−MNOを確立する要求をTSS−DM 404に送信する時に開始される。次に、TSS−DM 404は、422で、オリジナル実行環境をインストールする。次に、TSS−DM 404は、424で、初期セットアップシーケンスを新たに作成されたTE*−MNOに送信する。426で、「空の」実行環境TE*−MNOが確立され、セキュリティモジュールTM−MNO 406の新しいエンティティが、アクティブ化されるか作成される。さらに、初期実行環境TE*−MNOが、確立され、準備される。具体的に言うと、エンドースメント鍵対(endorsement key pair)EK*−TSS−MNOが、対応する保証された証書(endorsement certificate)Cert−TSS−MNOと一緒に、TE*MNO内で作成される。TSS−MNO 406は、428で、状態メッセージをTSS−DM 404に送り返す。
【0033】
手順400の遠隔所有権獲得部分412は、430で、TSS−DM 404がMNO(遠隔所有者)による占有の要求メッセージをMNO 408に送信する時に開始される。次に、MNO 408は、432で、トラステッドモバイルプラットフォーム401および実行環境TS−MNO 406の検証を実行する。次に、MNO 408は、434で、状態メッセージをTSS−DM 404に送信する。次に、TSS−DM 404は、436で、証明書CERT_MNOおよび追加情報をMNO 408に送信する。次に、MNO 408は、438で、証明書CERT_MNOをチェックし、署名し、構成およびセキュリティポリシをセットアップする。MNO 408は、440で、状態メッセージをTSS−DM 404に送信する。次に、TSS−DM 404は、実行環境TSS−MNO 406の完成をTSS−MNO 406に送信する。次に、TSS−MNOは、444で、CERT_MNOをインストールし、最終セットアップおよびインストール手順を実行することによって初期セットアップを完了する。その後、TSS−MNO 406は、446で、状態メッセージをTSS−DM 404に送り返す。TSS−DM 404は、448で、状態メッセージをTSS−DO 402に転送する。TSS−DM 404は、450で、状態メッセージをMNO 408にも送信する。
【0034】
図4は、遠隔所有権獲得手順の特定の実施態様を説明するものであるが、次の説明は、図4の手順に類似する終点を有する、より一般的な手順を説明する。MTPのDO(デバイス所有者)は、ユーザUまたはデバイス所有者DOが任意の所与のMNOを制限なしに自由に選択できるようにするために、特定のMNOによって事前に割り当てられず、初期化されていない、携帯電話機などの「空の」通信端末を購入できなければならない。図4の手順は、遠隔所有者によってTSS−MNOの占有を実行し、MNOによってvSIM実行環境の確立を完成するのに使用される。この方法を、任意の所与の遠隔所有者に直接に転送することができ、この方法が、MNOに制限されないことに留意されたい。
【0035】
次に、TE*−MNOは、その現在の状態を認証する。認証は、遠隔所有者MNOのRIM(基準値)および対応する証明書を使用して、TSS−DMのローカルベリファイヤ(検証者)RTV−DMによって実行することができる。TE*−MNO(初期状態のトラステッドエンジン)に対応するRIMが、必ずしも特定のMNOに関連付けられない場合があり、初期基本機能性を超える構成を有しない場合があることに留意されたい。一致するRIMおよび/または対応するRIM証明書が実行環境について入手可能ではない場合には、認証を、外部の(受け入れられた)検証エンティティを使用して実行することができる。認証ATTEST(Si)は、RTV署名アイデンティティ(RTVAI)によって署名される。
TE*MNO→MNO : ATTEST(Si) (式1)
【0036】
TE*−MNOは、対称セッション鍵Ksを生成し、これを使用して、エンドースメント鍵EK*−TSS−MNOの公開部分、対応する証明書Cert−TSS*−MNO、認証データ、および所期の目的に関する情報を暗号化する。次に、TE*−MNOは、セッション鍵Ksを公開鍵K−pub−MNOと一緒に暗号化し、両方のメッセージをMNOに送信する。一般性を失わずに、TE*−MNOは、エンドースメント鍵EK*−TSS−MNOおよび対応する証明書Cert−TSS*−MNO、証明データ、ならびに所期の目的に関する情報ではなく、認証アイデンティティ鍵AIK*−TSS−MNOを使用することができる。
【0037】
この鍵K−pub−MNOが、公に入手可能であるか、デバイス製造メーカーによってプリインストールされるかのいずれかであると仮定する。
【0038】
【数1】
【0039】
認証(式1)、EK*−TSS−MNO、およびその証明書、ならびにそれを暗号化するセッション鍵Ks(式2)を、別々ではあるが同一セッション内で(すなわち、同一のセッションナンスによって区切られて)送信することができる。代替案では、送信を、同一のセッション鍵Ksを使用して一回で行うことができ、したがって、この場合には、
【0040】
【数2】
【0041】
である。
【0042】
MNOがメッセージを受信した後に、それらのメッセージは、非対称鍵K−pub−MNOの秘密部分を使用して暗号化解除される。
【0043】
後続ステップでは、MNOは、証明データを検証し、TSS*−MNOの所期の目的をチェックする。実行環境のデータおよびデバイス証明が有効であり、所期の目的が受け入れられる場合には、MNOは、個々のセキュリティポリシSP−MNOを作成する。MNOは、Cert−TSS−MNOに署名し、「完成した」TSS−MNOのRIM値およびRIM証明書を生成し、この「完成した」TSS−MNOは、特定のサービスプロバイダと共に動作するように構成される。これらは、TSS−MNOのローカル検証に必要である。
【0044】
MNOは、初期構成SC−TSS−MNOをも生成する。これは、実行環境を個別化するのに、または所期の目的および特定のセキュリティポリシに関して実行環境を完成させるのに使用される。個別化は、一般に、適当な機能性を使用可能にするために当初には存在しないソフトウェアを含む。RIMおよびRIM証明書は、この初期構成を反映するために生成される。次のステップでは、MNOは、EK−pub−TSS−MNO(鍵の公開部分)を使用してメッセージを暗号化し、このパケットをTE*−MNOに送信し、この送信は、具体的には、TSS−DMによって提供される基本ネットワーク接続を介して実行することができる。SP−TSS−MNOおよびSC−TSS−MNOがMNO固有であり、SP−TSS−MNOおよびSC−TSS−MNOに対応する、TSS−MNOの期待される「完成後」状態が、新しいRIM証明書によって定義される必要があることに留意されたい。
【0045】
【数3】
【0046】
実行環境TE*−MNOは、受信したパケットを暗号化解除し、これをTSS−MNO内にインストールする。最後に、確立は、構成SC−TSS−MNOに基づいて完了する。これは、具体的には、まだインストールされておらず、SC−TSS−MNOによって要求されるすべてのサービスが、TSS−MNO内に導入されるかインストールされることを意味する。
【0047】
vSIM信用証明書のサブスクライバ登録および配送の手順を、図5に示し、以下で説明する。vSIMサービスを利用するために、アクセス認可信用証明書(vSIM信用証明書)が、MTP 200から使用可能でなければならない。このvSIM信用証明書は、(1)MNO 506によって生成され、MNOまたはDMによって事前にインストールされるか、(2)vSIM信用証明書をインストールするのに使用される当初には秘密の情報に基づくか、(3)所有権獲得プロセス中に生成される(MNO 506およびユーザU 502によって)かのいずれかである。
【0048】
vSIMアーキテクチャのサービスは、トラステッドソフトウェアアプリケーションとして実施されるので、vSIM信用証明書のめいめいのサブスクライバ関連部分は、MNOによってvSIMサービスに安全に送信されなければならない。従来のSIMベースのシステムでは、サブスクライバは、登録の直後にセキュリティトークン(スマートカード/SIMカード)を受け取る。vSIM信用証明書とは異なって、このセキュリティトークンは、物理的に存在し、めいめいのPOS用のプリインストールされた鍵またはSIM信用証明書と共に配送される。
【0049】
予備フェーズ(図示せず)で、MTP 200は、証明された初期スタートアップ手順を実行済みであり、OSおよびそのトラステッドユニットの特定のトラステッドソフトウェアレイヤをロード済みである。これは、トラステッド実行環境を、その組込みサービスvSIM−COREおよびvSIM−MGMTと一緒に含む。プラットフォームの信頼性は、チェック済みであり、インストールされたハードウェアおよび動作中のソフトウェアは、信頼され、受け入れられ、もっともらしい状態および構成である。したがって、プラットフォームは、vSIM機能をインストールされて「セキュアブートを達成した」と説明される状態にある。さらに、要求時に、プラットフォームは、認可されたエンティティを介してこの状態を報告し、状態を証明することもできる。
【0050】
POS 504は、MNO 506に、任意の所与の個数の以前に生成された登録チケットTicket−iを注文する。
POS→MNO : チケット要求(すなわち、注文) (式5)
【0051】
IMSI−iは、international mobile subscriber identityを表す。あるいは、これを、認可されたセンタによって割り当てられるランダムだが曖昧ではないID(識別子)またはサービスが通信ネットワークを介して提供されるサービスサブスクライバのIDを意味するIDとすることができる。IMSI−iがIMSIである場合には、そのようなチケットを、その一意インデックスによって区別することができる。
【0052】
用語RAND−iは、random value(乱数値)を表す。この値は、プロトコル中にTSS−MNO 204のアイデンティティをチェックするために必要である。AUTH−iの使用によって、MTP 200は、ticket−iの保全性および真正性をチェックすることができる。AUTH−iは、MNO 506の秘密鍵によって署名されたMNO 506の署名である。AUTH−iを暗号化解除することによって、POS 504は、Ticket−iを創作したMNO 506を識別することができる。MNO 506によるPOS 504の認証は、本明細書で説明されるプロトコルでは考慮されないが、チケットを占有し分配するのに十分に信頼できると考えられる。MNO 506は、複数のチケットをPOS 504に送信する。登録チケットは、3つ組{IMSIi,RANDi,AUTHi}からなる。
MNO→POS : Ticketi := {IMSIi,RANDi,AUTHi} (式5b)
【0053】
それ自体の信頼のルートを有する複数のTE*−MNO(初期のトラステッドサブシステム)がDMによってインストールされる場合には、MNO 506が、これらのサブシステムの所有権を別々に入手し、これによってそれぞれを別個のデバイスとみなすことが可能である。このシナリオでは、複数のユーザが、これらの別々のサブシステムを介して1対1の基礎で登録することができる。
【0054】
図4で説明した登録手順が、図5の登録手順ならびに本願で説明する後続のプロトコルとは別個であることにも留意されたい。したがって、図5の手順は、特定の所有権獲得手順の使用を必要としない。
【0055】
ユーザ登録およびvSIM信用証明書ロールアウト手順は、2つのフェーズに分離される。次の手順は、図5に示され、第1フェーズを説明するものである。ユーザ登録およびMNO 506のサブスクライバ関連サービスに関する登録は、第1フェーズで指定される。
【0056】
ユーザは、TSS−U/DO 206によって生成される、TSS−U/DO 206のローカルユーザの新しいアイデンティティ信用証明書(vSIM信用証明書のユーザ関連部分)を要求することによって、このプロトコルを開始する。このために、ローカルユーザは、550で、一意アイデンティティコードID−U、彼の個人登録データREGDATA−U、および秘密認可パスワードCHV−UをトラステッドサービスvSIM−MGMTにサブミットする。一意ID−Uの使用は、同一のU(ユーザ)502がvSIMユーザ登録目的で同一のMNO 506へ同一のプラットフォームを登録するのに異なるID−Uを使用できる可能性をなくす。式6に示された情報は、POS 504で創作され、その一部はユーザ502によって生成され(おそらくはREGDATAおよびCHV−U)、一部(ID−U)はPOS 504自体によって生成される。
U→vSIMMGMT : IDU,CHVU,REGDATAU (式6)
【0057】
次に、vSIM−MGMTは、552で、非対称署名鍵対K−Uを生成し、ユーザの関連情報のすべて(REGDATA−U、K−Uの公開部分)を含む対応する証明書を生成する。次に、サービスvSIM−MGMTは、554で、K−Uの秘密部分によって署名された証明書CERT−Uおよび認証をサービスvSIM−ECOREに送信する。トラステッド環境の範囲内で、セキュアリンクがvSIM−MGMTとvSIM−COREとの間で確立されると仮定する。
vSIMMGMT→vSIMCORE : ATTEST(Si),CERTU (式7)
【0058】
この点で、サービスvSIM−MGMTは、登録手順を開始し、サービスvSIM−COREのローカルベリファイヤ(RTV−MNO)に対してその現在の状態および構成を証明する。TSS−MNO 204は、基準データに基づいて、提供されたデータをチェックする。次に、TSS−MNO 204は、現在の実行環境の状態が有効で受け入れられる状態であるかどうかをチェックする。証明された非対称鍵対K−Uは、ステップ556で、現在の実行環境の認証がそれによって検証される手段として働く。vSIM−COREは、デバイスの確実性(reliability)を判定するや否や、一意識別子PIDを生成し、この値をvSIM−MGMTに送信する558。
vSIMCORE→vSIMMGMT : PID (式8)
【0059】
ユーザは、560で、登録データREGDATA−U(たとえば、名前、住所、アカウンティング情報、個人識別番号)およびPIDを、セキュアチャネルと考えられるものを介して(必要な場合には暗号化が実行される)POSに送信する。サービスvSIM−COREは、ユーザU 502の登録手順を開始する。このために、vSIM−COREは、それ自体の証明書および受信したユーザ証明書に署名する。次に、vSIM−COREは、このパケットをPOS 504に送信する。
U→POS : PID,REGDATAU (式9a)
vSIMCORE→POS : CERTTSS_MNO,CERTU (式9b)
【0060】
【数4】
【0061】
POS 504は、要求を受信した後に、564で、ticket−iを選択し、これを鍵K−pub−TSS−MNO 204にバインドし、566で、これをTSS−MNO 204に送り返す。PIDは、ユーザがチケットと共にそれによって一意に識別されるハンドルを提供する。また、POS 504は、ユーザをvSIM−COREによって行われている登録要求に関連付けるのにPIDを使用することができる。この場合に、POS 504は、インターネットポータルなど、MNOによって公認される任意の所与の売り場(店舗)とすることができる。
【0062】
【数5】
【0063】
POS 504は、ユーザUならびにデバイスの信頼性を判定し終えるや否や、CERT−UおよびIMSI−i(選択されたチケットの)をREGDATA−Uに追加する。次に、POS 504は、その署名鍵K−POSの秘密部分を用いて、収集された情報に署名し、署名されたデータおよび署名を(オンラインまたはオフラインで)MNOに送信する568。POS 504は、オプションで、K−MNOの公開部分を使用して、データを暗号化することができる。
POS→MNO : IMSIi,CERTU,REGDATAU
: SIGNPOS(IMSIi,CERTU,REGDATAU)
(式11)
【0064】
MNO 506は、データをチェックし、IMSI−i、対称鍵Ki、および証明書CERT−Uを使用して、vSIM信用証明書のサブスクライバ関連部分を生成する。次に、MNO 506は、秘密署名鍵K−MNOを用いてこのバンドルに署名し、最後に、570で、その認証センタ内で署名されたvSIM信用証明書およびめいめいのNONCEをアクティブ化する。
【0065】
次に、MTP 200は、既存通信チャネルを介してMNO 506の使用可能な登録サービスを要求することができる。このサービスは、たとえば、ネットワーク遠隔通信サービスまたはインターネットサービスとして実施することができる。
【0066】
上の、図5に示された登録プロセスの変形(図示せず)は、POSの認証および可能な認証を含む。この変形は、ならず者POSが他のおそらくは偽のPOSと共謀することができるという、MNOおよびユーザへの脅威を軽減する。この変形は、MNOから受信したチケットの複数のコピーを他のPOSに分配し、これらを多数のデバイスおよびユーザに分配し、これに関して料金を課すことができる。MNOは、この種類の詐欺を起点のPOSまでトレースバックすることができるが、この攻撃は、それでも、異なる国のPOSなどのいくつかの分散シナリオで成功する可能性がある。これを防ぐために、TSS_MNOは、POSの信頼性を証明する情報を入手する必要がある。
【0067】
前述の脅威を、次のように軽減することができる。登録チケットの注文の時に(式5)、POSは、POSによって署名された、同一のメッセージまたは別々のメッセージ内の、Trusted Computing Groupの遠隔認証プロトコルによって指定される、認証データATTEST_POSを送信することによって、MNOに向かう遠隔認証をも実行する。POSからMNOへのチケット要求または注文メッセージは、今や、POS認証データを含まなければならない。
POS→MNO : チケット要求,ATTEST_POS (式5c)
【0068】
MNOが、トラステッドサードパーティから、POSがその認証データに署名するのに使用した署名鍵の暗号化解除鍵およびその鍵の証明書を入手済みでなければならないことに留意されたい。チケット注文および認証メッセージは、どの場合でも、たとえば反射攻撃を防ぐために共通のナンスによって、1つのセッション内に制限されなければならない。次に、MNOは、チケット注文が信頼できる状態の既知のPOSから発することを知る。これは、POSが、POSインフラストラクチャ内またはその外部の許可されない当事者によってアクセス可能ではない保護されたメモリ位置にチケットを保存することを必要とする。POSにサブミットされたチケットは、MNOによって、POS署名鍵Tr−POSおよび鍵のこのセットの信頼状態を示すディジタル証明書CERT−Tr−POSを増補される。次に、これらの鍵は、式10に示されているように、TSS−MNOへのメッセージに署名するのに、POSによって使用される566。
【0069】
TSS−MNOとPOSとの間の信頼レベルをさらに高めるために、メッセージ交換を、登録データを送信する前にチケット要求に含めることができる560(式9a〜c)。すなわち、チケット要求を示す、TSS−MNOの暗号化鍵の公開部分を含むTSS−MNOからの初期メッセージの受信時に、POSは、後続通信用のセキュアチャネルを確立するために、TSS−MNOの暗号化鍵の公開部分を用いて暗号化されたCert−Tr−POSおよびオプションで暗号化鍵を含む、Tr−POSを用いて署名されたメッセージを送信する。TSS−MNOは、Cert−Tr−POSからTr−POS公開鍵を抽出し、それを用いてこのデータパケットの署名を検証する。次に、TSS−MNOは、Cert−Tr−POSのMNO署名を検証する。次に、TSS−MNOは、初期チケット要求に対する応答が、その信頼性がMNOによって証明されるPOSから発することを知る。次に、TSS−MNOは、オプションで、存在する場合に暗号化鍵を暗号化解除する。POSとデバイスとの間のすべての後続通信が、この鍵を用いて保護される。TSS−MNOは、受信されたチケット566の証明書をチケット要求初期交換で受信された証明書と比較して、Cert−Tr−POSによって知らされる信頼できる状態にあるPOSによって入手されたチケットを受信することを保証することができる。
【0070】
もう1つの実施形態では、POSは、以前に信頼できると証明されてはいない。さらに、POSは、MNOに対してそれ自体を認証することができない。したがって、POSの信頼性は、保証されない。この実施形態は、ユーザプラットフォームとMNOとの間での証明された非対称鍵対の確立に頼る。そのような鍵対は、遠隔所有権獲得プロトコル中に確立することができる。確立されたならば、その鍵対は、クリティカルデータを処理するためにPOSの信頼性に頼ることを減らす機構を提供する。このセキュリティ構成変更を用いると、MNOは、TSS−MNOの公開鍵を用いて暗号化され、K−MNOの秘密部分を使用して署名されたチケットをPOSに送信する。
【0071】
必要な秘密鍵を有するTSS−MNOだけがメッセージを暗号化解除できることを考慮すると、POSによって管理される複数MNOシナリオが使用される。TSS−MNOの鍵証明書は、POSが、所与のユーザ用のチケットを送信したMNOとの関連付けを行うことを可能にする。POSは、この形で、複数のMNOに関して関連付けを行うこともでき、したがって、チケットを受信するTSS−MNOがそれを暗号化解除できることを保証することができる。チケット情報をバインドするためのメッセージを、このプロセスに組み込むことができることに留意されたい。
【0072】
成功の登録を仮定すると、TSS−MNOは、暗号化解除されたチケットからIMSIを抽出し、これをMNOの公開鍵(上で確立された鍵対)を用いて暗号化し、K−priv−TSS−MNOを用いてこれに署名し、このメッセージをPOSに送信する。署名検証の後に、POSは、暗号化されたIMSIをユーザ証明書および登録データと一緒に、関連付けられたMNOに渡す。信用証明書の最終的なロールアウトは、下で式16および式17で示すものと本質的に同一の形で実行される。
【0073】
チケット情報の機密性は、潜在的に悪意のあるPOSから保護される。チケットを、ユーザプラットフォームおよびMNOのどちらに対しても悪用することはできない。チケットを、たとえば悪党のユーザまたはPOSにリダイレクトすることもできない。REGDATAUおよびCERTUを含む他の情報は、POSによってアクセス可能であり、したがって、可能なスプーフィング攻撃の対象である。しかし、この情報は、保全性保護され、したがって、そのような攻撃は、防がれる。
【0074】
図6に、図2のモバイルトラステッドプラットフォーム 200へのvSIM信用証明書のサブスクライバ関連部分の安全な配送およびインストールの第2フェーズ(変形ではない基本モデルによる)の手順の例を示す。vSIM信用証明書のサブスクライバ関連部分を得るために、ユーザは、MNO 604の登録サービスに申し込む。このために、ユーザU 602は、彼のID−Uおよび関連するパスワードCHV−UをサービスvSIM−MGMTにサブミットする。次に、vSIM−MGMTは、650で、保護されたメモリから関連する鍵対Ku(vSIM信用証明書のユーザ関連部分)をロードする。
U→vSIMMGMT : IDU,CHVU (式12)
【0075】
その後、vSIM−MGMTは、652で、ロールアウト手順を初期化し、このために、要求をvSIM−COREに送信する。
vSIMMGMT→vSIMCORE : init_rollout_vsim (式13)
【0076】
要求メッセージが受信された後に、vSIM−COREは、654で、めいめいのticketiを公開し、ticket−iの真正性および保全性をチェックする。次に、vSIM−COREは、ticket−iから値NONCE−Uを抽出し、U 602に、vSIM−MGMTを介して彼のアイデンティティを検証するように要求する。
vSIMCORE→vSIMMGMT : NONCEU (式14)
【0077】
サービスvSIM−MGMTは、ID−UおよびREGDATAUと一緒にNONCE−Uに署名する。このバンドルは、655でvSIM−COREに送り返される。
【0078】
【数6】
【0079】
サービスvSIM−COREは、メッセージを受信し終えるや否や、vSIM信用証明書配送要求を生成し、これをMNOの割り当てられた登録サービスにサブミットする656。このために、サービスvSIM−COREは、ticket−iからNONCE−MNOを抽出し、IMSI−iと一緒にこれに署名する。次に、vSIM−COREは、その生成された署名および受信されたユーザ署名を、ある検疫チャネルまたはインターネットを介してMNOに送信する656。
【0080】
【数7】
【0081】
vSIM COREからの要求が受信された後に、MNO 604は、658で、メッセージ、CERT−U、およびCert−TSS−MNOを(受信されたデータに基づく、ローカルメモリから、またはPOS(図示せず)によって提供される証明書に基づくのいずれかの検証によって)チェックする。情報が無効であるか拒絶される場合には、MNO 604は、エラーメッセージを応答し、このプロトコルを打ち切る。両方ともチケットから抽出されるNONCEMNOおよびNONCEUは、それぞれMNO 604およびU 602へのチャレンジである。REGDATAUは、IDUとの相関を可能にするために送信される。これらは、新鮮さのためには使用されず、新鮮さは、さまざまな形で、たとえば、メッセージに適切な粒度のタイムスタンプを追加することによって、達成することができる。
【0082】
もう1つのシナリオでは、要求は、MNO 604によって承認される。次に、MNOは、vSIM−COREへの送信のためにvSIM信用証明書のサブスクライバ関連部分を準備する。MNO 604は、ランダムに選択されるセッション鍵Ksを生成する。その後、鍵Ksは、660で、TSS−MNO 204からの対応する鍵と一緒に、ターゲットプラットフォームにリンクされ、その結果、データ(この場合には鍵Ks)を、関連する認可されたエンティティだけが使用できるようになる。MNO 604は、662で、セッション鍵と一緒にvSIM信用証明書のサブスクライバ関連部分を暗号化し、両方をTSS−MNO 204に送信する。
【0083】
【数8】
【0084】
最後に、TSS−MNO 204は、セッション鍵Ksを公開する。この鍵を用いて、TSS−MNO 204は、vSIM信用証明書のサブスクライバ関連部分を暗号化解除し、付随する署名をチェックする。暗号化解除が成功して実行され、検証された時に、vSIM−COREは、受信されたvSIM信用証明書を1つまたは複数の有効なプラットフォーム構成上で封印する。次に、vSIM−COREは、664で、手順を終了し、インストールを終える。
【0085】
代替案では、MNO 604は、分離された鍵Ksを生成し、vSIM信用証明書の暗号化されたサブスクライバ関連部分をticket−iに組み込むことができる。この場合に、MNO 604は、662で、ターゲットプラットフォームのvSIM−COREに鍵Ksだけを送信する。
【0086】
図7に、ソースプラットフォーム701からターゲットプラットフォーム707へvSIM信用証明書またはその実行環境を移行する手順の例を示す。この手順は、TSS−DO−S 702およびTSS−MNO−S 704を含むソースプラットフォーム701と、TSS−MNO−T 706およびTSS−DO−T 708を含むターゲットプラットフォーム707との間で実行される。SRK(ストレージルート鍵)を含むすべてのセキュリティに敏感なデータが、ターゲットTSS−MNO−Tに移行される。これは、両方のサブシステムTSS−MNO−SおよびTSS−MNO−T上に同一のRO(遠隔所有者)を必要とする。
【0087】
図7の移行手順は、完全な鍵階層を、(1)同一の利害関係者の実行環境の間で(2)このために特定のセキュリティポリシが両方のプラットフォームに存在し、認可される時に限って移行できることをもたらす。移行に関するこれらの制約は、1つのMNOだけがかかわることを必要とするが、信用証明書を、あるサブシステムから異なる所有者を有する別のサブシステムに移行することができる。利害関係者が同一であることの検証は、認証機構を介してソースエンティティおよび宛先エンティティによって実行することができる。構成転送は、ソフトウェアスイートを除いて信用証明書およびポリシだけが、あるプラットフォームから別のプラットフォームに移行され、移行が機能性と独立になるように、一般化することができる。
【0088】
この手順は、TSS−DO−S 702が、750で、TSS−MNO−S 704にサブシステム移行の要求を送信する時に開始される。TSS−MNO−S 704は、751で、ユーザのサービスレベルおよびターゲットMNOとの契約関係が移行を可能にするかどうかをチェックする。次に、TSS−MNO−S 704は、752で、サブシステム移行の要求(TSS−MNO−S−→TSS−MNO−T)をTSS−MNO−T 706に送信する。次に、TSS−MNO−T 706は、754で、ターゲットプラットフォーム707が許容できる状態であることを保証するために、TSS−MNO−S 704のローカル検証を実行する。次に、TSS−MNO−Tは、756で、移行を実行することの検証要求をTSS−DO−T 708に送信する。TSS−DO−T 708は、758で、確認を実行する。成功の検証の時に、TSS−DO−T 708は、760で、TSS−MNO−T 706に状態メッセージを送信する。次に、TSS−MNO−T 706は、762で、NONCE−MNO−Tを生成する。TSS−MNO−T 706は、764で、その証明書、ナンスNONCE−MNO−T、現在の状態Si,t、およびセキュリティポリシをTSS−MNO−S 704に送信する。次に、TSS−MNO−S 704は、766で、プラットフォームの検証を実行し、プラットフォームを移行のために準備する。成功の検証の時には、TSS−MNO−S 704は、768で、ソースプラットフォーム701のシリアル化を実行する。シリアル化とは、受け取る当事者がエンティティをそのオリジナルの形に再構成することを可能にするための、情報のビットストリームへのそのエンティティの変換と、通信チャネルを介するその運搬とである。次に、TSS−MNO−S 704は、770で、ソースサブシステムTSS−MNO−Sのシリアル化されたエンティティを含むメッセージをTSS−MNO−T 706に送信する。TSS−MNO−Tは、772で、ソースサブシステムをインポートする。次に、TSS−MNO−Tは、774で、TSS−MNO−S 704に状態メッセージを送信する。TSS−MNO.Sは、776でTSS−MNO−Sを破壊する。
【0089】
図7は、移行手順の特定の実施態様を示すが、次のセクションは、図7の手順に類似する終点を有するより一般的な手順を説明する。このために、デバイス所有者は、TSS−MNO−Sの移行サービスを開始する。
DOS→TSSMNO,S : init_migrate_vsim (式18)
【0090】
このサービスは、次の基本機能を提供する。プラットフォームMTP−S(またはTSS−DM)は、ターゲットプラットフォームMTP−Tへのセキュアチャネル(たとえばTLS、ここで、通信テクノロジを、Bluetooth、WLAN、USBなどとすることができる)を展開するために、TSS−MNO−Sの移行サービスによって割り当てられる。
【0091】
接続が使用可能になった後に、TSS−MNO−Tは、インポート手順を実行するためにTSS−MNO−T内のめいめいの移行サービスをアクティブ化する。
【0092】
TSS−MNO−Sの認証データが、セキュアチャネルを使用してTSS−MNO−Tに送信される。
【0093】
【数9】
【0094】
次に、ターゲットサブシステムTSS−MNO−Tは、TSS−MNO−Sのローカルチェックを実行する。752で受信される構成認証情報が無効である場合には、TSS−MNO−Tは、エラーメッセージを応答し、このプロトコルを打ち切る。それ以外の場合には、TSS−MNO−Tは、ローカル所有者DOによる確認を要求する。
【0095】
次に、ターゲットサブシステムTSS−MNO−Tは、乱数値NONCE−MNO−Tを生成する。その信頼性の証明を提供するために、TSS−MNO−Tは、すべての必要な情報をソースサブシステムTSS−MNO−Sに送信する。これは、Si,tの現在の状態、TSS−MNO−Tの証明書、セキュリティポリシSP−MNO−T、および値NONCE−MNO−Tを含む。
TSSMNO,T→TSSMNO,S : Si,T,CertTSSMNO,T
SPMNO,T,NONCEMNO,T
(式20)
【0096】
ターゲットサブシステムからのメッセージが受信された後に、TSS−MNO−Sは、TSS−MNO−Tの状態をチェックする。ターゲットシステムが、トラステッド状態にあり、受け入れられるセキュリティポリシおよび構成を実行する場合には、TSS−MNO−Sの現在の状態が、値NONCE−MNO−Tにリンクされ、すべてのさらなるアクションが、停止され、これによって、TSS−MNO−Sを非アクティブ化する。適用可能な場合に、ソースシステムが、ターゲットシステムを再アクティブ化するために適切なデータをサブミットすることに留意されたい。
【0097】
TSS−MNO−Sは、対称移行鍵K−Mを生成し、そのエンティティをシリアル化し、これをK−Mを用いて暗号化する。K−Mは、TSS−MNO−Tの受け入れられる構成にリンクされる。次に、リンクされた鍵K−Mおよび暗号化されたエンティティは、ターゲットプラットフォームTSS−MNO−Tに送信される。これは、具体的には、完全に隔離された鍵階層K−MNO−Sを、SRK−MNO−S、セキュリティポリシSP−MNO−S、および必要なSC−MNO−Sと一緒に含む。二重ナンスが、新鮮さを保存し、反射攻撃を防ぐために含まれる。状態報告など、ソースプラットフォームへのすべての戻りメッセージは、メッセージの新鮮さを維持するためにナンスNONCE−MNO−Sを必要とする。
【0098】
【数10】
【0099】
最後に、ターゲットサブシステムTSS−MNO−Tは、受信したK−Mを暗号化解除し、それ自体のSRKとしてSRK−MNO−Sを使用する。このサブシステムは、受信したセキュリティポリシSP−MNO−Sおよびサブシステム構成SC−MNO−Sをチェックする。次に、この情報を用いて、TSS−MNO−Tは、ソースサブシステムの内部構造を形成する。
【0100】
TSS−MNO−Tが成功して完成された後に、ターゲットプラットフォームは、状態レポートを送信し、適用可能な場合には、プラットフォーム認証をソースシステムに送信する。
【0101】
ソースプラットフォームTSS−MNO−Tは、すべてのセキュリティに敏感なデータを削除するか、これらを永久的に使用不能にする。次に、ソースシステムは、適用可能な場合に、状態レポートをターゲットシステムに送信し、かつ/またはプラットフォーム認証を実行する。
【0102】
図7の移行プロセスでは、実用上、ソースMNOおよびターゲットMNOが同一であると仮定する。この制限は、同一プロトコルの他の変形で取り除くことができ、それと同時に、ソースからターゲットへTSS−MNOのシリアル化されたエンティティを転送する必要が排除される。このために、ターゲット上の移行サービスは、ターゲット上のTSSがそれに関して必ずしも存在しない、指定されたターゲットMNO−B−Tと共に、ソースTSS−MNO−A−Sから許可された移行要求を受信することができる。この場合に、ターゲットは、まず、TSS−MNO−B−Tをインストールするために、MNO−Bとの遠隔所有権獲得手順を呼び出す。移行プロトコルは、本質的に未変更で実行できるが、TSS−MNO−A−Sのシリアル化されたエンティティの送信を省略し、その代わりに、MNO−Bと協力するネットワークアクセス、請求、および他の所望の機能に必要なそのTSSの非実行可能部分、具体的にはソースvSIMのIMSIだけを送信する。IMSI移行に関して、サブスクライバは、新しいIMSIが作成され、MNO−Bによって使用される時であっても、古い一意のサブスクライバ番号MSISDNを持ち続けることができる。
【0103】
図8に、図2のトラステッドモバイルプラットフォーム200のソフトウェアベースの認可信用証明書を使用してセルベースの通信ネットワークへの通信サブスクライバ802のアクセスを可能にする第1手順を実行するように構成された通信システムの例を示す。図8の手法は、ソフトウェアベースのアクセス認可信用証明書を使用して無線通信ネットワークへの通信サブスクライバ802のアクセスを可能にする。
【0104】
仮想ソフトウェアベースのアクセス認可信用証明書の主目的は、無線通信ネットワーク内のサブスクライバ認証用の従来のセキュリティトークン(SIMカード)の機能的代用を保証することである。従来のSIM機能の代用を提供することという主目的に加えて、この手順は、アクセス認可信用証明書を指定されたトラステッドプラットフォーム構成にリンクする。
【0105】
すべてのサブスクライバ関連の方法は、TSS−MNO内で、サービスvSIM−COREの使用によって実行される。GSM標準規格A3およびA8のアルゴリズムを、例のために下で示すが、類似する技法を、他の無線テクノロジの認証アルゴリズムと共に使用することもできる。下で提示する例では、これらのアルゴリズムは、サブスクライバ認証および鍵生成の責任を負う。通信チャネルを保護するアルゴリズムA5/3は、TSS−DMに統合される。
【0106】
図8の手順が始まる前に、MTP 200が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。この手順は、具体的には、サービスvSIM−COREおよびvSIM−MGMTのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。MTPは、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。
【0107】
この手順は、2つのフェーズに分割される。フェーズ1は、サービスvSIM−COREおよびvSIM−MGMTを初期化するためのプロトコルを構成する。たとえば、サブスクライバ認証は、たとえばGSM標準規格を考慮に入れ、MNOとデバイスとの間で行われる認証プロトコルメッセージに対する変更なしで認証アルゴリズムを実行するのにvSIM信用証明書を使用して、フェーズ2で実行される。
【0108】
フェーズ1は、ローカルユーザがvSIMサービスを初期化し、認証を実行する時に開始される。このために、ユーザ802は、850で、彼の曖昧でない識別子ID−Uを、正しいパスワードCHV−Uと一緒にvSIM−MGMTサービスに送信する。
【0109】
サービスvSIM−MGMTは、852で、送信されたユーザデータをチェックし、このチェックが成功である場合には、めいめいのアイデンティティ信用証明書(vSIM信用証明書のユーザ関連部分)を保護されたストレージエリアからロードする。アイデンティティ信用証明書は、具体的には、ユーザU 802の署名鍵を含む。
U→vSIMMGMT : IDU,CHVU (式22)
【0110】
次に、サービスvSIM−MGMTは、854で、サービスvSIM−COREのトラステッドインターフェースに接続し、初期化要求をvSIM−COREに送信する。vSIM−COREは、この要求を受信した後に、856で、乱数値RAND−AUTHを生成し、この値を認証メッセージとしてサービスvSIM−MGMTに送信する。
vSIMCORE→vSIMMGMT : RANDAUTH (式23)
【0111】
サービスvSIM−MGMTは、ユーザUの署名鍵のめいめいの秘密部分を使用し、認証メッセージRAND−AUTHに署名し、この値をサービスvSIM−COREに送り返す。
vSIMMGMT→vSIMCORE : SIGNU(RANDAUTH) (式24)
【0112】
vSIM−COREは、署名されたメッセージを受信するや否や、メッセージ状態をチェックする。成功のチェックの後に、サービスvSIM−COREは、vSIM信用証明書のサブスクライバ関連部分を暗号化解除し、GSMアルゴリズムA3およびA8を初期化する。初期化のために、vSIM−COREは、858で、vSIM信用証明書のサブスクライバデータIMSI−iおよびKiを使用する。
【0113】
フェーズ2は、vSIM−COREがMNOと間接的に(TSS−DMを介して)通信する時に開始される。かかわる通信当事者の間の通信は、透過的に行われる。このために、TSS−DM 202は、これらのメッセージをサービスvSIM−COREとMNO 806との間で中継する適切な方法またはサービスを提供しなければならない。
【0114】
次のプロトコルシーケンスは、GSMネットワーク内でのvSIMベースの認証方法を表し、例としてのみ提供される。まず、MTPは、認証方法を初期化し、このために、コマンドGSM_AUTH_ALGORITHMをTSS−MNOのサービスvSIM−COREに送信する。
【0115】
次のステップで、MTP 200は、860で、TSS−DMを介するネットワーク806へのアクセスを確立する。今や、サブスクライバ認証が、次の手順に従って実行される862。このために、TSS−MNO 204は、識別子IMSI−i(またはTMSI−i)をMNOに送信する。
vSIMCORE→MNO : IMSIi (式25)
【0116】
MNO 806は、一連の認証3つ組を内部で生成する。これらの3つ組は、認証要求RAND−i、一時セッション鍵Kc、および期待される認証応答SRESを含む。KcおよびSRESは、GSM A3/A8アルゴリズムを使用して計算される。MNO 806は、認証要求RAND−iをMTP 200に応答する。
MNO→vSIMCORE : RANDi (式26)
【0117】
RAND−iは、TSS−DM 202によってTSS−MNOのサービスvSIM−COREに中継される。次に、vSIM−COREは、鍵Kiと一緒にA3アルゴリズムを使用する。A3アルゴリズムの結果は、認証応答SRES*である。
【0118】
vSIM−COREは、このメッセージSRES*をMNOに送信する。
vSIMCORE→MNO : SRES* (式27)
【0119】
最後に、MNOは、SRESをSRES*と比較する。これらが同一である場合には、サブスクライバが認証されたと考えられる。vSIM−COREおよびMNOは、共有されるセッション鍵Kcを演繹し、KcをTSS−DMに送信する。次に、TSS−DMは、セキュア通信チャネルを確立するためにKcを受け入れる。
【0120】
図9および図10に、図2のトラステッドモバイルプラットフォーム200の遠隔認証を使用してセルベースの通信ネットワークへのユーザのアクセスを可能にする第2手順を実行するように構成された通信システムの例を示す。図9では、一般通信領域910およびより小さいMNO領域915があり、MNO領域915は、完全に一般通信領域910の境界内にある。ネットワーク918は、別々の、MNOに関係するサブスクリプション依存サービス920、サブスクリプション独立(加入独立)サービス925、ならびにロケーションベースのサービスおよび/または無線ローカルエリアネットワーク(WLAN)などの他のサービス930をも含む。
【0121】
図8の手順と比較して、この第2手順は、公益事業など、サブスクリプション独立および/または非サブスクライバ関連である無料サービスまたはオプションのサービスを使用するために、ネットワークへのアクセスを保証するのにプラットフォーム認証の技術的可能性を使用する。
【0122】
従来のSIM機能の代用を提供するという主目的に加えて、第2手順は、アクセス認可信用証明書を指定されたトラステッドプラットフォーム構成にリンクし、MNOとMTPとの間の相互認証を提供する。さらに、第2手順は、一般通信領域内のサブスクリプション独立および/または非サブスクライバ関連サービスへのコアネットワークアクセス、SIMロックなどの微細粒度の機能制限、ならびにサービスの動的ダウングレード/アップグレードを提供する。
【0123】
図9に示されているように、一般にアクセス可能な通信領域内のすべてのデバイスは、コアネットワークのサブスクリプション独立および/または非サブスクライバ関連サービス(MNOに関して)を使用し、またはこれにアクセスすることができる。そのようなサービスは、たとえば、ロケーションベースのサービスまたはWLANベースのインターネットアクセスとすることができる。携帯電話機が一般通信領域に関連する場合について、その携帯電話機は、認証機構を使用して、コアネットワークへのアクセスを入手する。
【0124】
MNOのサブスクライバ認証される領域(サブスクリプション依存MNOサービス)への遷移は、vSIM信用証明書の使用によるサブスクライバ認証の成功の完了を必要とする。したがって、MTPは、MNOによって提供される特定の通信サービス(GSM、UMTSなど)の領域内のサービスヘのアクセスならびにコアネットワークによって提供されるサービスへのアクセスを有する。
【0125】
図10に、図2のMTP 200の遠隔証明を使用してセルベースの通信ネットワークへの通信サブスクライバのアクセスを可能にする第2手順の例を示す。この手順を開始できる前に、MTP 200が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。この手順は、具体的には、サービスvSIM−COREおよびvSIM−MGMTのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。MTP 200は、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。
【0126】
図10の手順は、3つのフェーズに分割される。この手順の第1フェーズは、コアネットワークへのアクセスを記述する。この手順は、プラットフォーム認証およびチケッティング機構を使用する。第2フェーズでは、vSIM信用証明書を初期化する。最後に、第3フェーズは、サブスクライバ認証の方法を実施する。
【0127】
フェーズ1は、MTP 200がデバイスの基本認証を初期化する時に開始される。このために、トラステッド実行環境TSS−DM 202は、MNO 1006にプラットフォーム認証およびデバイス認証を指示する。次に、TSS−DM 202は、1050で、この要求を実行し、めいめいのNAP−MNO(ネットワークアクセスポイント1002)に接続する。このために、TSS−DM 202は、乱数値RAND−BASEを生成し、プラットフォーム認証を実行する。その後、基本認証サービスは、実行環境TSS−DM 202値RAND−BASE、認証データ、およびその証明書Cert−DMをネットワークアクセスポイントNAP−MNOに送信する。
TEDM→NAPMNO : RANDBASE,CertTSSDM
ATTEST(Si) (式28)
【0128】
この要求がNAP−MNOによって受信されるや否や、NAP−MNOは、MTP 200の状態をチェックする。保全性チェックが不合格であるか、受け入れられる基準状態が見つからない場合には、NAP−MNOは、このプロトコルを打ち切り、エラーメッセージを応答する。プラットフォームの証明が成功である場合には、MTP 200は、信頼できると考えられる。
【0129】
次に、NAP−MNOの公認されたエンティティは、セッション鍵K−BASEと一緒にネットワークチケットを生成する1052。そのようなエンティティは、たとえば、モバイルネットワークプロバイダMNOの一部であるAUC−MNO(認証センタ)とすることができる。K−BASEは、MTPとNAP−MNOとの間でトンネルを確立する、最小限に使用されるセッション鍵である。このトンネルは、大量のデータ暗号化作業負荷を実行するトラフィック指向鍵の分配を保護するのに使用することができる。この鍵の選択は、認証トラステッドサードパーティによって行われる。
【0130】
チケットは、本質的に次の情報を含み、ここで、REALMは、デバイスとの直接通信に用いられるPLMNエンティティ(AuC、VLR、HLRなど)を識別し、LIFETIMEは、チケット満了値を識別する。
TicketBASE := {IDMTP,IDNAP,KBASE,REALMBASE,LIFETIMEBASE} (式29)
【0131】
次に、AUC−MNOは、1054で、公開(または、適用可能な場合には共有)鍵K−NAPを使用してTicket−BASEを暗号化し、K−BASEをK−TSS−DMの公開鍵にバインドすることによってK−BASEをも暗号化し、この両方をNAP−MNOに送信する。NAP−MNOは、1056で、この情報をクライアントプラットフォームに中継する。このメッセージは、めいめいの公開鍵K−TSS−DMおよび有効なプラットフォーム構成と一緒にトラステッドサブシステムTSS−DM 202にリンクもされる。TSS−DM 202が、単独ではTicket−BASEを暗号化解除できないことに留意されたい。というのは、このチケットを、秘密K−NAPを使用することによってのみ暗号化解除することができ、TSS−DM 202がそれを有していないからである。そうではなく、TSS−DM 202は、より後のステップで暗号化されたTicket−BASEをNAP−MNOに転送し、このNAP−MNOで、暗号化されたTicket−BASEを暗号化解除することができる。
【0132】
【数11】
【0133】
TSS−DM 202は、署名されたメッセージを受信するや否や、1058で、署名された値RAND−BASEの状態をチェックする。情報が無効であるか拒絶される場合には、このサブシステムは、エラーメッセージを応答し、このプロトコルを打ち切る。別の場合には、AUC−MNOは、認証応答によって証明される。
【0134】
次に、TSS−DM 202は、セッション鍵K−BASEを暗号化解除し、オーセンティケータA−MTPと一緒に、暗号化されたTicket−BASEをNAP−MNOに送信する。現在のケースでは、オーセンティケータA−MTPは、プラットフォームアイデンティティID−MTP、現在のネットワークアドレスADDR、およびタイムスタンプTIMEからなる。
【0135】
【数12】
【0136】
チケットベースTicket−BASEは、単純にTSSDMによってネットワークに渡され、このネットワークで暗号化解除される。NAP−MNOは、暗号化されたチケットを受信し終えた時に、組み込まれた情報を検証する。K−NAPの公開部分を使用するTicket−BASEの暗号化を用いて、有効なバインディングが行われる。具体的に言うと、K−BASEは、チケットの一部として、NAPにバインドされる。状態が有効である場合には、プラットフォームが証明され、一般サービスへのアクセスが許可される。限定的利用セッション鍵K−BASEは、今や、MTP 200とNAP−MNOとの両方にバインドされて、この2つのエンティティの間でセキュアトンネルをセットアップする。
【0137】
フェーズ2の手順は、図8の手順の850〜858に類似している。
【0138】
フェーズ3を完了するための2つのオプションがあり、第1のオプションは、たとえばGSM標準規格との互換性を有するサブスクライバ認証を実行する。追加のステップで、鍵K−BASEが、1070で、NAP−MNOおよびMTPの側でセッション鍵Kcによって置換される。
【0139】
この点で、相互認証が、AUC−MNOとUとの間で実行される。AUC−MNOは、1056で、署名された認証要求によって証明される。その一方で、ユーザ1008は、SRESによって彼のアイデンティティを検証する。NAP−MNOとU 1008との間の認証は、有効なメッセージ鍵Kcによって暗黙のうちに検証される。
【0140】
この方法を、1056で、暗号化された鍵メッセージに前もってRAND−iを組み込むことによって最適化することができる。この場合に、vSIM−COREは、このメッセージからRAND−iを抽出し、認証応答SRESを計算し、この両方の結果をMNOに送信する。MNOは、期待されるSRESおよび対応するセッション鍵Kcを内部で生成する。
【0141】
これらのエンティティの明示的認証が要求される時には、追加ステップを実行しなければならない。NAPは、プラットフォームに関して、次の手順によって証明される。まず、NAPは、オーセンティケータAuからタイムスタンプを除去する。次に、NAPは、その値を増分し、共有セッション鍵Kc(またはそれから導出された鍵)を使用して暗号化する。最後に、NAPは、そのメッセージをMTPに送り返す。
【0142】
フェーズ3の第2のオプション(図示せず)では、認証方法は、GSM認証標準規格から逸脱することができる。この変形は、PLMNのセキュリティにおけるかなりの増加をもたらす、わずかに変更された認証方法を表す。具体的に言うと、SS7(signal system 7)のプロトコルエラーを、この形で回避することができる。
【0143】
次の変形は、フェーズ1からのコアネットワークアクセスに関する前者のネゴシエートされた情報を利用する。従来のGSMインフラストラクチャでは、認証3つ組は、SS7ネットワークを介して送信される。この3つ組は、チャレンジRAND、正しいレスポンスSRES、およびメッセージ鍵Kcを含む。
【0144】
モバイル通信ネットワークへの初期アクセスは、メッセージ鍵K−BASEによって確立されるが、この鍵の更新は、不要である。これは、具体的には、セッション鍵Kcの組込みに適用される。これによって、保護されないセッション鍵の伝送が回避される。
【0145】
このオプションの基本的な目的は、鍵K−BASEを基礎として保護されるNAP−MNOとMTPとの間の既存通信トンネルを利用することである。セッション鍵を更新するのではなく、MNOは、サービス更新メッセージだけをめいめいのネットワークアクセスポイントNAPおよびMTPに送信する。
【0146】
現在のPLMNでは、たとえばGSMシステムまたはUMTSシステムではIMSI番号によって表される、ネットワークサブスクライバのアドレス空間が、不足しがちである。チケットに基づくネットワークアクセスメソッドは、この問題を克服する形である。このために、IMSI情報(または、類似するネットワークサブスクライバID)を、TSS−DMによってNAP−MNOに配送されるMTPアイデンティティと一緒に、またはTSS−DMが入手し、NAP−MNOに転送できる任意の他のアイデンティティを担持する情報と一緒に使用することができる。上のプロトコルが成功し、要求するMTPがネットワークアクセスを得た後に、NAP−MNOは、同一IMSIを有する通信を現在のADDRデータに正しくマッピングし、これによって正しいエンティティに正しくマッピングするために、デバイスから発出するまたはデバイスに向けられるサービス要求に能動的に用いられる。やはり、ADDRデータが、GSMシステムまたはUMTSシステムの文脈ではIMSIまたはTMSIになることに留意されたい。すなわち、NAP−MNOは、PLMN基地局の既存識別方法を拡張する。
【0147】
この方法を使用して、具体的には、たとえばmachine−to−machine通信の場合または単一の利害関係者に属するデバイスフリートについて、グループIMSIアドレッシングを確立することができる。
【0148】
さらに、同一デバイスの複数のネットワークアクセスチケットが、Ticket−BASE内の追加情報によっても示される、異なるサービスレベルまたは料金について同時に有効であることができる。これらの追加のアイデンティティ情報を使用して、同一のまたは異なるMTP上で同一のIMSIを共有する異なるvSIMエンティティおよび/またはユーザを識別することもできる。
【0149】
チケットを、たとえばある種のサービスのアクセシビリティの期間またはそのような時間期間中の特定の料金を判定する有効性期間情報に関する情報によって増補することもできる。次に、NAPまたは別のエンティティは、チケットアイデンティティおよびそれに関連する既知の有効性期間に基づいてそのような時間限定サービスを決定し、それに関する決定を実施するタスクを入手する。
【0150】
図11に、一般ネットワークインフラストラクチャのサブスクライバ認証の第3手順を示す。図11の手順について、vSIM信用証明書のサブスクライバ関連部分の構造設計およびトラステッドサービスvSIM−COREの機能性または統合されたアルゴリズムは、ある種の要件を厳守しなければならない。
【0151】
図11のvSIM信用証明書は、対象のアイデンティティに基づくアクセス認可信用証明書である。このアクセス認可信用証明書は、2G/3G構造モールド(structural mold)にはバインドされず、図8および図10の対応物の一般化であり、通信サブスクライバのアイデンティティを証明するのに使用される。vSIM信用証明書は、対象U 1110の一意識別子ID−Uおよび暗号法の暗号化機構(たとえば、対称鍵または非対称鍵)または非暗号法の暗号化機構(たとえば、一方向ハッシュチェーン)に基づく少なくとも1つの情報アイテムを含む。認可された対象だけが、vSIM信用証明書を生成するか読み取り、あるいは含まれる情報を変更することができる。vSIM信用証明書は、デバイスアイデンティティまたは有効な適用エリアのリストなどの追加情報を含むことができる。
【0152】
MTP 1108は、別々の保護された実行環境内で動作するvSIM−COREサービスのインスタンスを作成する。サービスvSIM−COREは、サブスクライバ認証のコア機能の責任を負う。具体的に言うと、このサービスは、実際の認証機構を実行する。機構または手順の特定の設計は、特定の応用例に依存する。サービスvSIM−COREは、おそらくは特定のユースケースに基づいて、トラステッド機能性をインポートすることができ、他の(外部の)トラステッドサービスを提供することもできる。vSIM−COREは、vSIM信用証明書の少なくとも1つのサブスクライバ関連部分をも含む。
【0153】
図11の手順が開始される前に、MTP 1108が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。これは、具体的には、サービスvSIM−COREおよびvSIM−MGMTのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。MTPは、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。
【0154】
図11の手順は、3つのフェーズに分割される。フェーズ1 1120は、遠隔証明である。フェーズ2 1130は、vSIM信用証明書の初期化である。フェーズ3 1140は、サブスクライバ認証手順である。
【0155】
フェーズ1 1120では、プラットフォーム認証が、上の例によって説明されたようにデバイス認証を実行するのに使用される。図11に提供されたこの一般的なケースでは、ネットワークエンティティMNO 1112は、一般ネットワークインフラストラクチャのめいめいのエンティティによって置換される。そのようなエンティティは、たとえば、このネットワーク内のALS(認証サーバ)とすることができ、このサーバは、必ずしも2Gテクノロジまたは3Gテクノロジに束縛されるのではなく、long term evolution(LTE)などの将来のネットワークに適用することができる。
【0156】
フェーズ2 1130すなわちvSIMサービスの初期化およびvSIM信用証明書の初期化は、図10のフェーズ2手順に類似する形で実行される。しかし、この手順は、一般化された仮定に基づき、したがって、さらなる認証の方法およびプロトコルのためのより幅広い基礎を使用可能にする。
【0157】
フェーズ3 1140は、ALSによって提供されるサービスの所与のサブスクライバを認証し、認可する、サブスクライバ認証手順である。対照的に、図8および図10の手順は、共有される秘密情報(GSMによる対称鍵Ki)のサブスクライバ認証の手順に限定される。具体的に言うと、この限定は、図11の包括的手順には存在しない。したがって、図11の手順では、共有される秘密は使用されず、認証プロセスは、完全に証明書ベースの非対称暗号法に基づく。たとえば、証明書機関(CA)を用いるDiffie−Hellmanを使用して、鍵交換を、トラステッドエンティティの間で行うことができる。そのようなシナリオでは、当事者は、CAによる検証を伴う相互アイデンティティを必要とする。
【0158】
フェーズ3 1140では、乱数値RAND−SRVが、ALS上のサービスの拡張を要求するのに使用される。TE−MNOは、ticket−BASEからRAND−SRVを抽出する。次に、TSS−MNOが、認証応答XRES*−SRVを作り、その秘密署名鍵K−priv−TM−ASを用いてRAND−SRVに署名する。UIDおよびサービス識別子SRVと一緒に、この署名XRES*−SRVは、ALSに送信される。ALSは、このメッセージを受信するや否や、XRES*−SRVの署名を検証する。署名が有効である場合には、プラットフォームが証明され、サービス拡張が実行される。
【0159】
特徴および要素を、上で特定の組合せで説明したが、各特徴または要素を、他の特徴および要素を伴わずに単独で、または他の特徴および要素を伴ってもしくは伴わずにさまざまな組合せで使用することができる。本明細書で提供される方法または流れ図は、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読格納媒体に組み込まれる、コンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読格納媒体の例は、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにCD−ROMディスクおよびディジタル多用途ディスク(DVD)などの光媒体を含む。
【0160】
適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、ディジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアに関連する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、すべての他のタイプの集積回路(IC)、および/または状態機械を含む。
【0161】
ソフトウェアに関連するプロセッサを使用して、無線送受信ユニット(WTRU)、ユーザ機器(UE)、端末、基地局、無線ネットワークコントローラ(RNC)、またはすべてのホストコンピュータで使用されるラジオ周波数トランシーバを実施することができる。WTRUは、カメラ、ビデオカメラモジュール、ビデオ電話機、スピーカホン、振動デバイス、スピーカ、マイクロホン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、液晶ディスプレイ(LCD)ディスプレイユニット、有機発光ダイオード(OLED)ディスプレイユニット、ディジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザ、および/またはすべての無線ローカルエリアネットワーク(WLAN)もしくはウルトラワイドバンド(UWB)モジュールなどのハードウェアおよび/またはソフトウェアで実施されるモジュールに関連して使用される。
【0162】
実施形態
1.vSIM(virtual subscriber identity module)−coreトラステッド実行環境およびvSIM−MGMT(vSIM−management)トラステッド実行環境を有するMTP(mobile trusted processor)上でvSIM信用証明書を登録し、受信する方法であって、
登録およびチケットの要求をトラステッドPOS(売り場、店舗)に送信することと、
要求および他の信頼検証手順に応答してトラステッドPOSからチケットを受信することと
を含むことを特徴とする方法。
2.POSとのトラステッド関係を確立すること
をさらに含むことを特徴とする実施形態1に記載の方法。
3.トラステッド関係の確立は、POSと共に認証手順を実行することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
4.トラステッド関係の確立は、POSと共に認証手順を実行することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
5.vSIM(virtual subscriber identity module)−coreトラステッド実行環境およびvSIM−MGMT(vSIM−management)トラステッド実行環境を有するMTP(mobile trusted processor)にvSIM信用証明書を登録し、供給する、遠隔POS(売り場)によって実行される方法であって、
登録およびチケットの要求をMTPから受信することと、
登録チケットを選択することと、
MTPに関係するサブスクライバ登録データおよび登録チケットの要求をMNO(ネットワークプロバイダ)に送信することと、
MNOから登録チケットを受信することと、
登録チケットをMTPに送信することと
を含むことを特徴とする方法。
6.POSは、トラステッドPOSであることを特徴とする前の実施形態のいずれか一項に記載の方法。
7.MTPに関係するサブスクライバ登録データおよび登録チケットの要求を送信することは、認証データを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
8.MNOとのトラステッド関係を確立することをさらに含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
9.MTPとのトラステッド関係を確立することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
10.受信されたチケット要求は、公開暗号化鍵の少なくとも一部を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
11.MTPに関係するサブスクライバ登録データおよび登録チケットの要求は、認証用の署名を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
12.登録チケットは、認証情報を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
13.登録チケットは、認証情報を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
14.登録チケットは、署名された証明書を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
15.MTPを用いて証明された非対称鍵対を確立すること
をさらに含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
16.受信された登録チケットは、暗号化されていることを特徴とする前の実施形態のいずれか一項に記載の方法。
17.POSは、信頼されないことを特徴とする前の実施形態のいずれか一項に記載の方法。
18.MTP(mobile trusted platform)であって、
MTPの製造メーカーに関係する信用証明書を格納し、提供するように構成されたTSS−DM(デバイス製造メーカートラステッドサブシステム)と、
MNO(モバイルネットワークオペレータ)に関係する信用証明書を格納し、提供するように構成されたTSS−MNO(モバイルネットワークオペレータ−トラステッドサブシステム)と、
MTPのユーザに関係する信用証明書を格納し、提供するように構成されたTSS−U(デバイスユーザ−トラステッドサブシステム)と
を含むことを特徴とするMTP。
19.TSS−MNOは、MNOに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM(virtual subscriber identity module)コアサービスユニットを含むことを特徴とする実施形態18に記載のMTP。
20.TSS−DOは、MTPのユーザに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM(virtual subscriber identity module)管理ユニットを含むことを特徴とする実施形態18〜19のいずれか一項に記載のMTP。
21.TSS−DOおよびTSS−MNOは、トラステッドvSIM(virtual subscriber identity module)サービスを介して通信することを特徴とする実施形態18〜20のいずれか一項に記載のMTP。
22.MTPの第2ユーザに関係する信用証明書を格納し、提供するように構成された第2TSS−U
をさらに含むことを特徴とする実施形態18〜21のいずれか一項に記載のMTP。
23.MTPの所有者に関係する信用証明書を格納し、提供するように構成されたデバイス所有者−トラステッドサブシステムTSS−DO
をさらに含むことを特徴とする実施形態18〜22のいずれか一項に記載のMTP。
24.第2MNOに関係する信用証明書を格納し、提供するように構成された第2TSS−MNO
をさらに含むことを特徴とする実施形態18〜23のいずれか一項に記載のMTP。
【技術分野】
【0001】
本願は、無線通信に関する。
【背景技術】
【0002】
無線通信デバイスの数の増加に伴って、SIM(Subscriber Identity Module:契約者情報記録モジュール、電話番号を特定するための固有のID番号が記録されたICモジュール)カードまたはUICC(Universal Integrated Circuit Card)内で実行される現在のSIM機能に対するより動的な解決策を提供し、現代のおよび開発中のモバイル通信ネットワークに関して、いくつかの短所を克服する必要がある。UICCは、そこからSIM認証アルゴリズムを実行し、信用証明書を格納する、安全な実行および格納環境を有する。しかし、UICCのコスト、その非実用的な形状因子、および制限された機能性が、モバイルネットワークの操作者(オペレータ)が無線デバイスを購入してからしばらく後でのみ知るアプリケーションでの使用を妨げる。あるいは、UICCは、複数の操作者のネットワークを1つのデバイス内で同時にサポートしまたはアクセスしなければならない時に、役に立たなくなくなる。モバイルネットワークおよびサービスのサブスクリプション(加入契約)を更新するか、あるいは変更する方法は、SIMカードに関して制限されているので、無線の配備が望まれる場合に、一般に欠如している。
【0003】
さらに、SIMカードまたはUICCは、一般に、非常に安全と考えられるが、このセキュリティは、それが常駐するデバイス全体のセキュリティの属性に強くリンクされていない。これは、モバイル金融取引などの高度なサービスやアップリケーションに関するセキュリティのスケーリング(拡大縮小)のコンセプトの適用を制限する。これらの問題のすべてが、たとえばmachine−to−machine(M2M)通信シナリオで、モバイルネットワークに接続された自律的デバイスに対して切迫している。
【発明の概要】
【発明が解決しようとする課題】
【0004】
したがって、SIM機能に対するより動的で同時に安全なソフトウェアベースの解決策が必要である。
【課題を解決するための手段】
【0005】
vSIM(virtual Subscriber Identify Module;仮想サブスクライバ識別モジュール)サービスを提供するように構成されたMTP(Mobile Trusted Platform;携帯情報機器向けのセキュリティ機構仕様、移動体通信セキュリティプラットフォーム)を開示する。一実施形態では、MTPは、MTPの製造メーカーに関係する信用証明書を格納し、提供するように構成されたTSS−DM(装置製造メーカーの信頼されたサブシステム)と、MNO(移動体通信オペレータ)に関係する信用証明書を格納し、提供するように構成されたTSS−MNO(モバイルネットワークオペレータ−トラステッドサブシステム)と、MTPのユーザに関係する信用証明書を格納し、提供するように構成されたTSS−DO/TSS−U(装置所有者/ユーザの信頼されたサブシステム)とを含む。TSS−MNOは、MNOに関係する信用証明書情報を格納し、提供し、かつ処理するように構成されたvSIM(仮想契約者情報記録モジュール)コアサービスユニットを含む。TSS−DO/TSS−Uは、MTPのユーザに関係する信用証明書情報を格納し、提供し、かつ処理するように構成されたvSIM管理ユニットを含む。TSS−DO/TSS−UおよびTSS−MNOは、トラステッドvSIMサービスを介して通信する。オプション(随意)で、MTPは、デバイスユーザ機能およびデバイス所有者機能をTSS−DOとTSS−Uとに分離することができ、MTPの第2ユーザに関係する信用証明書を格納し、提供するように構成された第2のTSS−Uを含むことができる。また、MTPは、MTPの所有者に関係する信用証明書を格納し、提供するように構成されたTSS−DO(デバイス所有者−トラステッドサブシステム)を含むことができる。MTPは、第2のMNOに関係する信用証明書を格納し、提供するように構成された第2のMNO−TSSをも含むことができる。
【0006】
vSIMサービスを提供する際に使用されるトラステッドサブシステムをリモート(遠隔)で作成する手順をも開示する。
【0007】
vSIMサービスを提供する際に使用されるトラステッドサブシステムを登録し、記録する手順をも開示する。
【0008】
遠隔位置からMTPにvSIMサービスを提供する際に使用されるトラステッドサブシステムを配送する手順をも開示する。
【0009】
ソースMTPからターゲットMTPにvSIMサービスを提供する際に使用されるトラステッドサブシステムを移行する手順をも開示する。
【0010】
vSIM構成を使用するサブスクライバ(電話加入者)が無線ネットワークにアクセスすることを可能にする3つの関連する方法をも開示する。
【0011】
より詳細な理解は、添付図面に関連して例として与えられた下記の説明から得ることができる。
【図面の簡単な説明】
【0012】
【図1】ソフトウェアベースのvSIM(virtual subscriber identify module)を使用することで、サービスを使用し、サブスクライバアイデンティティを判定するように構成された通信システムアーキテクチャの例を示す図である。
【図2】単一ユーザのモバイルトラステッドプラットフォーム(mobile trusted platform)のvSIMアーキテクチャの例を示す図である。
【図3】マルチユーザモバイルトラステッドプラットフォームのvSIMアーキテクチャ300の例を示す図である。
【図4】初期のモバイルトラステッドプラットフォーム上でTSS−MNOをインストールする手順を示す図である。
【図5】vSIM信用証明書のサブスクライバ登録および配送の手順を示す図である。
【図6】vSIM信用証明書のサブスクライバ関連部分の安全な配送およびインストールの第2フェーズの手順の例を示す図である。
【図7】ソースプラットフォームからターゲットプラットフォームへvSIM信用証明書またはその実行環境を移行する手順の例を示す図である。
【図8】通信サブスクライバのアクセスを可能にする第1手順を実行するように構成された通信システムの例を示す図である。
【図9】通信サブスクライバのアクセスを可能にする第2手順を実行するように構成された通信システムの例を示す図である。
【図10】通信サブスクライバのアクセスを可能にする第2手順を実行するように構成された通信システムのもう1つの例を示す図である。
【図11A】一般ネットワークインフラストラクチャについて通信サブスクライバのアクセスを可能にする第3手順を示す図である。
【図11B】一般ネットワークインフラストラクチャについて通信サブスクライバのアクセスを可能にする第3手順を示す図である。
【発明を実施するための形態】
【0013】
以下で言及する時に、用語「無線送受信ユニット(WTRU)」は、ユーザ装置(UE)、移動局、固定のまたは可動のサブスクライバユニット、ポケットベル、セル電話機、携帯情報端末(PDA)、コンピュータ、モバイルトラステッドプラットフォーム、または無線環境内で動作できるすべての他のタイプのユーザデバイスを含むが、これらに限定はされない。下で言及する時に、用語「基地局」は、Node−B、サイトコントローラ、アクセスポイント(AP)、または無線環境内で動作できるすべての他のタイプのインターフェースするデバイスを含むが、これらに限定はされない。用語「信頼性(trustworthiness)」は、アプリケーションおよび/またはサービスの状態を記述する標準と考えられる。この状態は、アプリケーションおよび/またはサービスが、その保全性および正しい機能の表示を直接にまたは間接に提供できることを意味する。
【0014】
図1に、ソフトウェアベースのvSIM(virtual subscriber identify module)を使用することでサービスを使用し、サブスクライバアイデンティティを判定するように構成された通信システムアーキテクチャの例を示す。通信システム100は、ユーザすなわちデバイスの所有者(持ち主)(DO)110、トラステッドモバイルプラットフォーム120、基地局130、MNO(ネットワークサービスプロバイダ;移動体通信事業者)140、およびPOS(店舗、販売場所)150を含む。DO 110は、POS 150との登録および記録155のためにPOSと通信する。POS 150は、サブスクライバ登録160を実行するためにMNO 140と通信する。MNO 140は、vSIM信用証明書165を配送するためにトラステッドモバイルプラットフォームと通信する。DO 110は、ユーザを認証する170ためにトラステッドモバイルプラットフォーム 120に情報を提供する。その後、トラステッドモバイルプラットフォームは、サブスクライバ認証175を基地局130に送信する。その後、基地局130は、ユーザ認証情報を検証するためにMNO 140と通信する。
【0015】
一般に、図1のvSIMアーキテクチャは、永久的に割り当てられたトラステッドアンカ(trusted anchor;信頼アンカ)に基づき、複数の別々のトラステッド実行環境またはサブシステムをサポートする、トラステッドオペレーティングシステムによって保護される。図示されているように、1つの実行環境が、特定の利害関係者に割り当てられ、図示されたものを超える追加の利害関係者が、存在することが可能である。
【0016】
図1に示されたアーキテクチャは、4つの重要なエンティティを考慮に入れている。このシナリオ(筋書き)では、DO/Uは、モバイル通信ネットワークおよびそこで提供されるサービス(たとえば、GSM、UMTS電話、データサービス、または特殊化されたロケーションベースのサービス)を使用するために、MNOとの長期的関係を確立することを意図している。
【0017】
物理的に存在するSIMカードを使用する代わりに、MNOは、MTP(mobile trusted platform)にソフトウェアベースのアクセス認可信用証明書またはvSIM信用証明書を提供する。vSIM信用証明書は、サブスクライバ関連部分およびユーザ関連部分からなる。登録されたデバイスユーザが、最初に通信ネットワークによって認可されなければならなくなるたびに、そのユーザは、まず、vSIM信用証明書のユーザ関連部分を介してvSIMサービスについて認証される。通信関係の過程において、このサービスは、vSIM信用証明書のサブスクライバ関連部分をネットワーク認証に使用する。
【0018】
図2に、単一ユーザのMTP(mobile trusted platform)200のvSIMアーキテクチャの例を示す。モバイルトラステッドプラットフォーム 200は、3つの別々のTSS(トラステッドサブシステム)202、204、206を含む。第1のTSS 202は、DM(デバイス製造メーカー)に割り当てられる。第2のTSS 204は、MNO(ネットワークサービスプロバイダ)に割り当てられる。第3のトラステッドTSS 206は、DO 206に割り当てられる。TSS−DOを、ユーザに割り当てることもできる(TSS−U)ことに留意されたい。3つのTSS 202、204、206のそれぞれが、標準サービスユニット210a、210b、210c、トラステッドサービスユニット212a、212b、212c、およびトラステッドリソースユニット214a、214b、214cを含む。MNOトラステッドTSS 204は、MNOに関係するSIM機能を実行するvSIMコアユニット220をも含む。DOトラステッドTSS 206は、DOに関係するSIM機能を実行するvSIM管理ユニット222をも含む。vSIMコアユニット220およびvSIM管理ユニット222は、トラステッドリンク224を介して通信し、組み合わさって、少なくとも従来のUSIM(universal subscriber identity module:全域契約者情報記録モジュール)の機能を実行する。
【0019】
図3に、マルチユーザMTP300のvSIMアーキテクチャの例を示す。モバイルトラステッドプラットフォーム 300は、4つの別々のTSS 302、304、306、および308を含む。第1のTSS 302は、DM(デバイス製造メーカー)に割り当てられる。第2のトラステッドTSS 304は、ネットワークサービスプロバイダに割り当てられる。第3のTSS 306は、第1ユーザに割り当てられる。第4のTSS 308は、デバイス所有者308に割り当てられる。4つのTSS 302、304、306、および308のそれぞれは、標準サービス(normal services)ユニット310a、310b、310c、310d、トラステッドサービスユニット312a、312b、312c、およびリソースユニット314a、314b、314cを含む。MNO TSS 304は、MNOに関係するSIM機能を実行するvSIMコアユニット320をも含む。ユーザTSS 306/308は、ローカルユーザの管理および認証に関係する機能を実行するvSIMサブスクライバ管理サービス322/323をも含む。より具体的に言うと、このサービスは、ローカルユーザのアイデンティティに関して認証が与えられるように、vSIMコアサービス320に認証オラクル(authentication oracle)を提供する。vSIMコアユニット320およびvSIM管理ユニット322は、トラステッドリンク324を介して通信し、それらが協働して、少なくとも従来のUSIM(universal subscriber identity module)の機能を実行する。
【0020】
一般に、MTP 200および300は、複数の保護された別々の実行環境をサポートする。各環境は、利害関係者(stakeholder)に関連するエリアを表す。MTP 200および300は、従来のスマートカードベースのSIMカードおよびその機能を置換するvSIMサービスを実施するように構成されている。一般に、vSIMサービスは、(少なくとも)図2に示された3つの異なる実行環境に拡張されるが、例によって図3に示された、多数の他の実行環境をサポートするように拡張することもできる。
【0021】
図2および図3に示されているように、複数の異なるsigma(利害関係者)すなわち、DM(デバイス製造メーカー)、ネットワークアクセスおよびサービスプロバイダ(モバイルネットワークオペレータ、MNO)、DO(デバイス所有者)、およびU(ユーザ)が考慮される。トラステッドサブシステムTSS−sigmaは、TE−sigma(トラステッド実行環境、セキュリティ実施環境)およびTM(交換不能セキュリティモジュール、トラステッドモジュール)またはRO(遠隔の持ち主)もしくはsigma(利害関係者)に関連するTM−sigma(セキュリティモジュールのエンティティ)を含む論理ユニットとして構成される。TSS−sigmaは、必ずすべての所与のデータに署名し、暗号化するように構成される。TSS−sigmaは、トラステッドサービスRTV−sigmaへのアクセスを有する。このサービスは、たとえば、基準データに基づく定義されたシステム状態の検証の責任を負う。本明細書で提案される類似するアーキテクチャのさまざまな他のトラステッドサブシステムを、以下で例として説明する。これは、利害関係者DM、MNO、DO、およびUのサブシステムTSS−DM 202および302、TSS−MNO 204および304、TSS−DO 206および306、ならびにTSS−U 206および308を含む。
【0022】
TSS−DM 202および302は、そのインストールされたハードウェアコンポーネントと一緒にデバイスの保全性(integrity)、構成、およびインストールの責任を負う。TSS−DM 202および302は、デバイスのすべてのセキュリティに敏感なリソースを提供する。TSS−DM 202および302は、一般に、すべての内部通信および外部通信を制御し、通信チャネルを保護する。その結果、TSS−sigmaのすべてのプロトコルメッセージは、その宛先ポイントのTSS−DM 202および302の通信サービスによって伝送される。
【0023】
あるプラットフォームのすべてのサブスクリプション依存およびサブスクライバ(電話加入者、契約者)関連のネットワークプロバイダサービスは、TSS−MNO 204および304に割り当てられる。このサブシステムは、vSIM信用証明書のサブスクライバ関連部分を管理し、保護する責任を負い、サブスクライバのクライアントサイドネットワーク認証を実行する。このサブシステムは、このためにvSIM−CORE(vSIMコアサービス)を提供する。vSIM−CORE 220および320は、従来のSIMの本質的機能(サブスクライバ認証)を置換するように構成されるが、他の認証機能にも対処することができる。用語「トラステッドサブシステムTSS−MNO」は、必要なvSIM−COREサービス220および320を提供する完全装備のTSS−MNOと同義である。TSS−DMおよびTSS−MNOの組合せも可能である。vSIMコアサービスが、サブスクライバデータの安全な格納および使用ならびにMNOとのサブスクライバ認証の責任を負うことにも留意されたい。
【0024】
TSS−U 206および306は、すべてのユーザ関連情報およびプライベート情報、具体的にはユーザの関連するアクセス認可信用証明書(vSIM信用証明書のユーザ関連部分)を保護する。TSS−U 206および306は、vSIMの管理サービス(vSIM−MGMT)222のインスタンスを作成する。このサービスは、ユーザ情報の管理およびローカルユーザに関する認証応答の計算の責任を負う。サービスvSIM−MGMTは、サービスvSIM−COREに内部認証オラクルを与える。したがって、vSIM−MGMTは、認証照会の後に、ローカルユーザのアイデンティティの証明を提供することができる。このサービスは、vSIMのユーザ管理、具体的にはデバイスユーザのアドミニストレーションおよび管理の責任を負う。vSIM内の所有者管理サービスvSIM−OwnMGMTは、機能的にvSIM−MGMTにイメージ化される。すべてのTSS−Uが、ディジタル署名のために所期のプラットフォームユーザUによってのみアクセスでき使用できる適切な暗号法鍵を生成できることにも留意されたい。
【0025】
TSS−DO 206および308は、vSIMの持ち主の管理サービス(vSIM−OwnMgmt)のインスタンスを作成する。このサービスは、所有者情報を管理し、ローカルユーザまたはサービスプロバイダに関するものなどの事業管理(administrative management)の責任を負う。TSS−DOおよびTSS−Uを、単一ユーザシステムについては図2に示されているように1つに組み合わせることもできる。
【0026】
一般に、MTPは、ハードウェアプラットフォームに永久的に関連付けられた交換不能なセキュリティモジュール(トラステッドモジュール、TM)を有するモバイルプラットフォームである。検討中のvSIアーキテクチャの文脈では、MTPは、従来のSIMカードなどのサブスクライバ認証用の従来のセキュリティトークンを義務的に備えてはいない。MTPは、トラステッドオペレーティングシステムを動作させる。トラステッドソフトウェアレイヤ(trusted software layer;信頼されたソフトウェア層)は、保護され隔離された実行およびメモリ機能を有する複数の別々のトラステッドサブシステム(TSS_SIGMA)をサポートする。
【0027】
各トラステッドサブシステム(TSS_SIGMA)は、利害関係者のクリティカルなセキュリティ機能に使用される。トラステッドサブシステムは、セキュリティモジュールのトラステッドエンティティ(TM−SIGMA)および関連するトラステッド実行環境(トラステッドエンジン、TE_SIGMA)、ならびにトラステッドサービス(TS_SIGMA)からなる。遠隔所有者DM、MNO、Uの代わりに、少なくとも、3つのトラステッドサブシステムTSS−DM、TSS−MNO、TSS−Uが、MTP上に存在する。手順を、単一ユーザシステムについて説明する。デバイス所有者DOおよびTSS−DOの機能は、UまたはTSS−Uについてイメージ化される。
【0028】
MNOが、公開鍵インフラストラクチャの必要な機能を直接にまたは間接に提供することに留意されたい。MNOは、証明機関CAによって発行された証明書Cert−MNOを所有する。この証明書は、MNOのアイデンティティを公開鍵K−pub−MNOにリンクし、この公開鍵K−pub−MNOは、ディジタル署名をチェックするのに必要である。この証明書は、MTPおよびすべての組込みサービスから使用可能である。
【0029】
以下で説明する手順が、例のみのために単一ユーザシステムを検討することに留意されたい。その結果、デバイス所有者DOは、ユーザUと同等にされる。図3に示されているように、別々のTSS−DOおよびTSS−Uを有する複数ユーザシステムでのサブスクライバ認証の方法は、類似する形で実行され、本願の範囲内にあるはずである。他のマルチユーザシナリオ、たとえば(1)1つのTSS−Uおよび複数のTSS−MNO、(2)1つのTSS−MNOおよび複数のTSS−U、ならびに(3)複数のTSS−Uおよび複数のTSS−MNOが可能である。所有権制御(ownership control)の迂回を防ぐために、1つのDOだけが、すべてのそのような構成で許容可能であるとしている。さまざまなマルチユーザシナリオで、vSIM−MGMTサービスは、DOだけに適用されるので、すべてのユーザならびに複数のvSIM−COREサービス表明について立場を明らかにせず、これらと互換になるように構成される。したがって、単一ユーザについて、vSIM−MGMTは、vSIM−MGMT−DO機能およびvSIM−MGMT−U機能に分離される。これは、たとえばユーザのグループ(たとえば、家族)が同一のMNO加入を使用する場合、または、その一方で、単一のユーザが、状況に応じて、たとえば海外にいる時に、複数のMNO加入から選択したい時のアプリケーション(適用)のシナリオに有利である。これらを実施する好ましい方法は、vSIM−COREおよび/またはvSIM−MGMTのいずれかが、めいめいのTSSの間およびさまざまなvSIM−MGMTおよびvSIM−OwnMgmtの間の所望の1対n関係、n対1関係、またはn対m関係を確立するために、めいめいの他のTSS内のめいめいの他のサービスの認可秘密(authorization secret)を含む保護されたデータベースを保持することである。
【0030】
図2および図3の提案されるvSIMアーキテクチャは、従来のセキュリティトークンに基づくサブスクライバ認証用の従来のアーキテクチャと同等のセキュリティ特性を仮定する。具体的に言うと、これらのアーキテクチャは、保護されたストレージ機能、別々の改竄保護された実行環境、およびユーザの認証を引き受ける。vSIMプラットフォームは、認可される対象だけがvSIM信用証明書の保護されたデータにアクセスし、またはこれを操作することができることをも保証しなければならない。これは、データが、vSIM実行環境へまたは他のトラステッドサービスへ移動中であるか、MTPの揮発性メモリまたは不揮発性メモリに格納されているか、実行環境内で実行されまたは使用されるか、認可された対象によってさまざまなトラステッド環境の間で転送される間に、特に重要である。これは、セキュリティに敏感なデータを破壊も変更もできず、アクセス制御機構を開始することもできない、攻撃者の特徴を含む。このシステムは、セキュリティに敏感なデータの消失および脱出をも防ぎ、すべての必要なサービスが使用可能であり、機能することを保証しなければならない。具体的に言うと、vSIMアーキテクチャは、認可された対象が適切な(ローカルまたは遠隔の)所有者を介してのみセキュリティに敏感なサービスにアクセスできることを保証しなければならない。
【0031】
図4に、MNO 408と通信するTSS−DM(デバイス製造メーカー用のTSS)404およびTSS−U(ユーザ用のTSS)402を有する初期モバイルトラステッドプラットフォーム 403上でMNO−TSS 406をインストールする手順400を示す。用語TSS−MNOが、この手順によって確立されるトラステッドサブシステムとこの手順の終りにTSS−MNOになるTE−MNO(TE(トラステッド実行環境)MNO)との両方を指すのに使用されることに留意されたい。RO(遠隔所有者)による占有は、遠隔所有者または利害関係者とMTPとの間の信頼の基礎的で基本的な関係を確立する。この手順は、空のまたは初期の実行環境が存在することを必要とする。手順の第1部分410は、空の実行環境の準備専用であり、第2部分412は、新たに作成されるTE(トラステッドエンジン)の遠隔所有権獲得専用である。TSS*−MNO(初期TSS−MNO)は、基本機能性および/または複数のトラステッドサービスを有するTE*−MNO(初期標準実行環境)からなる。サブシステムTSS*−MNOが、MNOにその手の付けられていない構成、構造、およびそのセキュリティポリシに関する適合の証明を与えることができる時には、サブシステムTSS*−MNOは、MNOによって証明される。
【0032】
手順400の前処理部分410は、420で、TSS−U 402がTSS−MNOを確立する要求をTSS−DM 404に送信する時に開始される。次に、TSS−DM 404は、422で、オリジナル実行環境をインストールする。次に、TSS−DM 404は、424で、初期セットアップシーケンスを新たに作成されたTE*−MNOに送信する。426で、「空の」実行環境TE*−MNOが確立され、セキュリティモジュールTM−MNO 406の新しいエンティティが、アクティブ化されるか作成される。さらに、初期実行環境TE*−MNOが、確立され、準備される。具体的に言うと、エンドースメント鍵対(endorsement key pair)EK*−TSS−MNOが、対応する保証された証書(endorsement certificate)Cert−TSS−MNOと一緒に、TE*MNO内で作成される。TSS−MNO 406は、428で、状態メッセージをTSS−DM 404に送り返す。
【0033】
手順400の遠隔所有権獲得部分412は、430で、TSS−DM 404がMNO(遠隔所有者)による占有の要求メッセージをMNO 408に送信する時に開始される。次に、MNO 408は、432で、トラステッドモバイルプラットフォーム401および実行環境TS−MNO 406の検証を実行する。次に、MNO 408は、434で、状態メッセージをTSS−DM 404に送信する。次に、TSS−DM 404は、436で、証明書CERT_MNOおよび追加情報をMNO 408に送信する。次に、MNO 408は、438で、証明書CERT_MNOをチェックし、署名し、構成およびセキュリティポリシをセットアップする。MNO 408は、440で、状態メッセージをTSS−DM 404に送信する。次に、TSS−DM 404は、実行環境TSS−MNO 406の完成をTSS−MNO 406に送信する。次に、TSS−MNOは、444で、CERT_MNOをインストールし、最終セットアップおよびインストール手順を実行することによって初期セットアップを完了する。その後、TSS−MNO 406は、446で、状態メッセージをTSS−DM 404に送り返す。TSS−DM 404は、448で、状態メッセージをTSS−DO 402に転送する。TSS−DM 404は、450で、状態メッセージをMNO 408にも送信する。
【0034】
図4は、遠隔所有権獲得手順の特定の実施態様を説明するものであるが、次の説明は、図4の手順に類似する終点を有する、より一般的な手順を説明する。MTPのDO(デバイス所有者)は、ユーザUまたはデバイス所有者DOが任意の所与のMNOを制限なしに自由に選択できるようにするために、特定のMNOによって事前に割り当てられず、初期化されていない、携帯電話機などの「空の」通信端末を購入できなければならない。図4の手順は、遠隔所有者によってTSS−MNOの占有を実行し、MNOによってvSIM実行環境の確立を完成するのに使用される。この方法を、任意の所与の遠隔所有者に直接に転送することができ、この方法が、MNOに制限されないことに留意されたい。
【0035】
次に、TE*−MNOは、その現在の状態を認証する。認証は、遠隔所有者MNOのRIM(基準値)および対応する証明書を使用して、TSS−DMのローカルベリファイヤ(検証者)RTV−DMによって実行することができる。TE*−MNO(初期状態のトラステッドエンジン)に対応するRIMが、必ずしも特定のMNOに関連付けられない場合があり、初期基本機能性を超える構成を有しない場合があることに留意されたい。一致するRIMおよび/または対応するRIM証明書が実行環境について入手可能ではない場合には、認証を、外部の(受け入れられた)検証エンティティを使用して実行することができる。認証ATTEST(Si)は、RTV署名アイデンティティ(RTVAI)によって署名される。
TE*MNO→MNO : ATTEST(Si) (式1)
【0036】
TE*−MNOは、対称セッション鍵Ksを生成し、これを使用して、エンドースメント鍵EK*−TSS−MNOの公開部分、対応する証明書Cert−TSS*−MNO、認証データ、および所期の目的に関する情報を暗号化する。次に、TE*−MNOは、セッション鍵Ksを公開鍵K−pub−MNOと一緒に暗号化し、両方のメッセージをMNOに送信する。一般性を失わずに、TE*−MNOは、エンドースメント鍵EK*−TSS−MNOおよび対応する証明書Cert−TSS*−MNO、証明データ、ならびに所期の目的に関する情報ではなく、認証アイデンティティ鍵AIK*−TSS−MNOを使用することができる。
【0037】
この鍵K−pub−MNOが、公に入手可能であるか、デバイス製造メーカーによってプリインストールされるかのいずれかであると仮定する。
【0038】
【数1】
【0039】
認証(式1)、EK*−TSS−MNO、およびその証明書、ならびにそれを暗号化するセッション鍵Ks(式2)を、別々ではあるが同一セッション内で(すなわち、同一のセッションナンスによって区切られて)送信することができる。代替案では、送信を、同一のセッション鍵Ksを使用して一回で行うことができ、したがって、この場合には、
【0040】
【数2】
【0041】
である。
【0042】
MNOがメッセージを受信した後に、それらのメッセージは、非対称鍵K−pub−MNOの秘密部分を使用して暗号化解除される。
【0043】
後続ステップでは、MNOは、証明データを検証し、TSS*−MNOの所期の目的をチェックする。実行環境のデータおよびデバイス証明が有効であり、所期の目的が受け入れられる場合には、MNOは、個々のセキュリティポリシSP−MNOを作成する。MNOは、Cert−TSS−MNOに署名し、「完成した」TSS−MNOのRIM値およびRIM証明書を生成し、この「完成した」TSS−MNOは、特定のサービスプロバイダと共に動作するように構成される。これらは、TSS−MNOのローカル検証に必要である。
【0044】
MNOは、初期構成SC−TSS−MNOをも生成する。これは、実行環境を個別化するのに、または所期の目的および特定のセキュリティポリシに関して実行環境を完成させるのに使用される。個別化は、一般に、適当な機能性を使用可能にするために当初には存在しないソフトウェアを含む。RIMおよびRIM証明書は、この初期構成を反映するために生成される。次のステップでは、MNOは、EK−pub−TSS−MNO(鍵の公開部分)を使用してメッセージを暗号化し、このパケットをTE*−MNOに送信し、この送信は、具体的には、TSS−DMによって提供される基本ネットワーク接続を介して実行することができる。SP−TSS−MNOおよびSC−TSS−MNOがMNO固有であり、SP−TSS−MNOおよびSC−TSS−MNOに対応する、TSS−MNOの期待される「完成後」状態が、新しいRIM証明書によって定義される必要があることに留意されたい。
【0045】
【数3】
【0046】
実行環境TE*−MNOは、受信したパケットを暗号化解除し、これをTSS−MNO内にインストールする。最後に、確立は、構成SC−TSS−MNOに基づいて完了する。これは、具体的には、まだインストールされておらず、SC−TSS−MNOによって要求されるすべてのサービスが、TSS−MNO内に導入されるかインストールされることを意味する。
【0047】
vSIM信用証明書のサブスクライバ登録および配送の手順を、図5に示し、以下で説明する。vSIMサービスを利用するために、アクセス認可信用証明書(vSIM信用証明書)が、MTP 200から使用可能でなければならない。このvSIM信用証明書は、(1)MNO 506によって生成され、MNOまたはDMによって事前にインストールされるか、(2)vSIM信用証明書をインストールするのに使用される当初には秘密の情報に基づくか、(3)所有権獲得プロセス中に生成される(MNO 506およびユーザU 502によって)かのいずれかである。
【0048】
vSIMアーキテクチャのサービスは、トラステッドソフトウェアアプリケーションとして実施されるので、vSIM信用証明書のめいめいのサブスクライバ関連部分は、MNOによってvSIMサービスに安全に送信されなければならない。従来のSIMベースのシステムでは、サブスクライバは、登録の直後にセキュリティトークン(スマートカード/SIMカード)を受け取る。vSIM信用証明書とは異なって、このセキュリティトークンは、物理的に存在し、めいめいのPOS用のプリインストールされた鍵またはSIM信用証明書と共に配送される。
【0049】
予備フェーズ(図示せず)で、MTP 200は、証明された初期スタートアップ手順を実行済みであり、OSおよびそのトラステッドユニットの特定のトラステッドソフトウェアレイヤをロード済みである。これは、トラステッド実行環境を、その組込みサービスvSIM−COREおよびvSIM−MGMTと一緒に含む。プラットフォームの信頼性は、チェック済みであり、インストールされたハードウェアおよび動作中のソフトウェアは、信頼され、受け入れられ、もっともらしい状態および構成である。したがって、プラットフォームは、vSIM機能をインストールされて「セキュアブートを達成した」と説明される状態にある。さらに、要求時に、プラットフォームは、認可されたエンティティを介してこの状態を報告し、状態を証明することもできる。
【0050】
POS 504は、MNO 506に、任意の所与の個数の以前に生成された登録チケットTicket−iを注文する。
POS→MNO : チケット要求(すなわち、注文) (式5)
【0051】
IMSI−iは、international mobile subscriber identityを表す。あるいは、これを、認可されたセンタによって割り当てられるランダムだが曖昧ではないID(識別子)またはサービスが通信ネットワークを介して提供されるサービスサブスクライバのIDを意味するIDとすることができる。IMSI−iがIMSIである場合には、そのようなチケットを、その一意インデックスによって区別することができる。
【0052】
用語RAND−iは、random value(乱数値)を表す。この値は、プロトコル中にTSS−MNO 204のアイデンティティをチェックするために必要である。AUTH−iの使用によって、MTP 200は、ticket−iの保全性および真正性をチェックすることができる。AUTH−iは、MNO 506の秘密鍵によって署名されたMNO 506の署名である。AUTH−iを暗号化解除することによって、POS 504は、Ticket−iを創作したMNO 506を識別することができる。MNO 506によるPOS 504の認証は、本明細書で説明されるプロトコルでは考慮されないが、チケットを占有し分配するのに十分に信頼できると考えられる。MNO 506は、複数のチケットをPOS 504に送信する。登録チケットは、3つ組{IMSIi,RANDi,AUTHi}からなる。
MNO→POS : Ticketi := {IMSIi,RANDi,AUTHi} (式5b)
【0053】
それ自体の信頼のルートを有する複数のTE*−MNO(初期のトラステッドサブシステム)がDMによってインストールされる場合には、MNO 506が、これらのサブシステムの所有権を別々に入手し、これによってそれぞれを別個のデバイスとみなすことが可能である。このシナリオでは、複数のユーザが、これらの別々のサブシステムを介して1対1の基礎で登録することができる。
【0054】
図4で説明した登録手順が、図5の登録手順ならびに本願で説明する後続のプロトコルとは別個であることにも留意されたい。したがって、図5の手順は、特定の所有権獲得手順の使用を必要としない。
【0055】
ユーザ登録およびvSIM信用証明書ロールアウト手順は、2つのフェーズに分離される。次の手順は、図5に示され、第1フェーズを説明するものである。ユーザ登録およびMNO 506のサブスクライバ関連サービスに関する登録は、第1フェーズで指定される。
【0056】
ユーザは、TSS−U/DO 206によって生成される、TSS−U/DO 206のローカルユーザの新しいアイデンティティ信用証明書(vSIM信用証明書のユーザ関連部分)を要求することによって、このプロトコルを開始する。このために、ローカルユーザは、550で、一意アイデンティティコードID−U、彼の個人登録データREGDATA−U、および秘密認可パスワードCHV−UをトラステッドサービスvSIM−MGMTにサブミットする。一意ID−Uの使用は、同一のU(ユーザ)502がvSIMユーザ登録目的で同一のMNO 506へ同一のプラットフォームを登録するのに異なるID−Uを使用できる可能性をなくす。式6に示された情報は、POS 504で創作され、その一部はユーザ502によって生成され(おそらくはREGDATAおよびCHV−U)、一部(ID−U)はPOS 504自体によって生成される。
U→vSIMMGMT : IDU,CHVU,REGDATAU (式6)
【0057】
次に、vSIM−MGMTは、552で、非対称署名鍵対K−Uを生成し、ユーザの関連情報のすべて(REGDATA−U、K−Uの公開部分)を含む対応する証明書を生成する。次に、サービスvSIM−MGMTは、554で、K−Uの秘密部分によって署名された証明書CERT−Uおよび認証をサービスvSIM−ECOREに送信する。トラステッド環境の範囲内で、セキュアリンクがvSIM−MGMTとvSIM−COREとの間で確立されると仮定する。
vSIMMGMT→vSIMCORE : ATTEST(Si),CERTU (式7)
【0058】
この点で、サービスvSIM−MGMTは、登録手順を開始し、サービスvSIM−COREのローカルベリファイヤ(RTV−MNO)に対してその現在の状態および構成を証明する。TSS−MNO 204は、基準データに基づいて、提供されたデータをチェックする。次に、TSS−MNO 204は、現在の実行環境の状態が有効で受け入れられる状態であるかどうかをチェックする。証明された非対称鍵対K−Uは、ステップ556で、現在の実行環境の認証がそれによって検証される手段として働く。vSIM−COREは、デバイスの確実性(reliability)を判定するや否や、一意識別子PIDを生成し、この値をvSIM−MGMTに送信する558。
vSIMCORE→vSIMMGMT : PID (式8)
【0059】
ユーザは、560で、登録データREGDATA−U(たとえば、名前、住所、アカウンティング情報、個人識別番号)およびPIDを、セキュアチャネルと考えられるものを介して(必要な場合には暗号化が実行される)POSに送信する。サービスvSIM−COREは、ユーザU 502の登録手順を開始する。このために、vSIM−COREは、それ自体の証明書および受信したユーザ証明書に署名する。次に、vSIM−COREは、このパケットをPOS 504に送信する。
U→POS : PID,REGDATAU (式9a)
vSIMCORE→POS : CERTTSS_MNO,CERTU (式9b)
【0060】
【数4】
【0061】
POS 504は、要求を受信した後に、564で、ticket−iを選択し、これを鍵K−pub−TSS−MNO 204にバインドし、566で、これをTSS−MNO 204に送り返す。PIDは、ユーザがチケットと共にそれによって一意に識別されるハンドルを提供する。また、POS 504は、ユーザをvSIM−COREによって行われている登録要求に関連付けるのにPIDを使用することができる。この場合に、POS 504は、インターネットポータルなど、MNOによって公認される任意の所与の売り場(店舗)とすることができる。
【0062】
【数5】
【0063】
POS 504は、ユーザUならびにデバイスの信頼性を判定し終えるや否や、CERT−UおよびIMSI−i(選択されたチケットの)をREGDATA−Uに追加する。次に、POS 504は、その署名鍵K−POSの秘密部分を用いて、収集された情報に署名し、署名されたデータおよび署名を(オンラインまたはオフラインで)MNOに送信する568。POS 504は、オプションで、K−MNOの公開部分を使用して、データを暗号化することができる。
POS→MNO : IMSIi,CERTU,REGDATAU
: SIGNPOS(IMSIi,CERTU,REGDATAU)
(式11)
【0064】
MNO 506は、データをチェックし、IMSI−i、対称鍵Ki、および証明書CERT−Uを使用して、vSIM信用証明書のサブスクライバ関連部分を生成する。次に、MNO 506は、秘密署名鍵K−MNOを用いてこのバンドルに署名し、最後に、570で、その認証センタ内で署名されたvSIM信用証明書およびめいめいのNONCEをアクティブ化する。
【0065】
次に、MTP 200は、既存通信チャネルを介してMNO 506の使用可能な登録サービスを要求することができる。このサービスは、たとえば、ネットワーク遠隔通信サービスまたはインターネットサービスとして実施することができる。
【0066】
上の、図5に示された登録プロセスの変形(図示せず)は、POSの認証および可能な認証を含む。この変形は、ならず者POSが他のおそらくは偽のPOSと共謀することができるという、MNOおよびユーザへの脅威を軽減する。この変形は、MNOから受信したチケットの複数のコピーを他のPOSに分配し、これらを多数のデバイスおよびユーザに分配し、これに関して料金を課すことができる。MNOは、この種類の詐欺を起点のPOSまでトレースバックすることができるが、この攻撃は、それでも、異なる国のPOSなどのいくつかの分散シナリオで成功する可能性がある。これを防ぐために、TSS_MNOは、POSの信頼性を証明する情報を入手する必要がある。
【0067】
前述の脅威を、次のように軽減することができる。登録チケットの注文の時に(式5)、POSは、POSによって署名された、同一のメッセージまたは別々のメッセージ内の、Trusted Computing Groupの遠隔認証プロトコルによって指定される、認証データATTEST_POSを送信することによって、MNOに向かう遠隔認証をも実行する。POSからMNOへのチケット要求または注文メッセージは、今や、POS認証データを含まなければならない。
POS→MNO : チケット要求,ATTEST_POS (式5c)
【0068】
MNOが、トラステッドサードパーティから、POSがその認証データに署名するのに使用した署名鍵の暗号化解除鍵およびその鍵の証明書を入手済みでなければならないことに留意されたい。チケット注文および認証メッセージは、どの場合でも、たとえば反射攻撃を防ぐために共通のナンスによって、1つのセッション内に制限されなければならない。次に、MNOは、チケット注文が信頼できる状態の既知のPOSから発することを知る。これは、POSが、POSインフラストラクチャ内またはその外部の許可されない当事者によってアクセス可能ではない保護されたメモリ位置にチケットを保存することを必要とする。POSにサブミットされたチケットは、MNOによって、POS署名鍵Tr−POSおよび鍵のこのセットの信頼状態を示すディジタル証明書CERT−Tr−POSを増補される。次に、これらの鍵は、式10に示されているように、TSS−MNOへのメッセージに署名するのに、POSによって使用される566。
【0069】
TSS−MNOとPOSとの間の信頼レベルをさらに高めるために、メッセージ交換を、登録データを送信する前にチケット要求に含めることができる560(式9a〜c)。すなわち、チケット要求を示す、TSS−MNOの暗号化鍵の公開部分を含むTSS−MNOからの初期メッセージの受信時に、POSは、後続通信用のセキュアチャネルを確立するために、TSS−MNOの暗号化鍵の公開部分を用いて暗号化されたCert−Tr−POSおよびオプションで暗号化鍵を含む、Tr−POSを用いて署名されたメッセージを送信する。TSS−MNOは、Cert−Tr−POSからTr−POS公開鍵を抽出し、それを用いてこのデータパケットの署名を検証する。次に、TSS−MNOは、Cert−Tr−POSのMNO署名を検証する。次に、TSS−MNOは、初期チケット要求に対する応答が、その信頼性がMNOによって証明されるPOSから発することを知る。次に、TSS−MNOは、オプションで、存在する場合に暗号化鍵を暗号化解除する。POSとデバイスとの間のすべての後続通信が、この鍵を用いて保護される。TSS−MNOは、受信されたチケット566の証明書をチケット要求初期交換で受信された証明書と比較して、Cert−Tr−POSによって知らされる信頼できる状態にあるPOSによって入手されたチケットを受信することを保証することができる。
【0070】
もう1つの実施形態では、POSは、以前に信頼できると証明されてはいない。さらに、POSは、MNOに対してそれ自体を認証することができない。したがって、POSの信頼性は、保証されない。この実施形態は、ユーザプラットフォームとMNOとの間での証明された非対称鍵対の確立に頼る。そのような鍵対は、遠隔所有権獲得プロトコル中に確立することができる。確立されたならば、その鍵対は、クリティカルデータを処理するためにPOSの信頼性に頼ることを減らす機構を提供する。このセキュリティ構成変更を用いると、MNOは、TSS−MNOの公開鍵を用いて暗号化され、K−MNOの秘密部分を使用して署名されたチケットをPOSに送信する。
【0071】
必要な秘密鍵を有するTSS−MNOだけがメッセージを暗号化解除できることを考慮すると、POSによって管理される複数MNOシナリオが使用される。TSS−MNOの鍵証明書は、POSが、所与のユーザ用のチケットを送信したMNOとの関連付けを行うことを可能にする。POSは、この形で、複数のMNOに関して関連付けを行うこともでき、したがって、チケットを受信するTSS−MNOがそれを暗号化解除できることを保証することができる。チケット情報をバインドするためのメッセージを、このプロセスに組み込むことができることに留意されたい。
【0072】
成功の登録を仮定すると、TSS−MNOは、暗号化解除されたチケットからIMSIを抽出し、これをMNOの公開鍵(上で確立された鍵対)を用いて暗号化し、K−priv−TSS−MNOを用いてこれに署名し、このメッセージをPOSに送信する。署名検証の後に、POSは、暗号化されたIMSIをユーザ証明書および登録データと一緒に、関連付けられたMNOに渡す。信用証明書の最終的なロールアウトは、下で式16および式17で示すものと本質的に同一の形で実行される。
【0073】
チケット情報の機密性は、潜在的に悪意のあるPOSから保護される。チケットを、ユーザプラットフォームおよびMNOのどちらに対しても悪用することはできない。チケットを、たとえば悪党のユーザまたはPOSにリダイレクトすることもできない。REGDATAUおよびCERTUを含む他の情報は、POSによってアクセス可能であり、したがって、可能なスプーフィング攻撃の対象である。しかし、この情報は、保全性保護され、したがって、そのような攻撃は、防がれる。
【0074】
図6に、図2のモバイルトラステッドプラットフォーム 200へのvSIM信用証明書のサブスクライバ関連部分の安全な配送およびインストールの第2フェーズ(変形ではない基本モデルによる)の手順の例を示す。vSIM信用証明書のサブスクライバ関連部分を得るために、ユーザは、MNO 604の登録サービスに申し込む。このために、ユーザU 602は、彼のID−Uおよび関連するパスワードCHV−UをサービスvSIM−MGMTにサブミットする。次に、vSIM−MGMTは、650で、保護されたメモリから関連する鍵対Ku(vSIM信用証明書のユーザ関連部分)をロードする。
U→vSIMMGMT : IDU,CHVU (式12)
【0075】
その後、vSIM−MGMTは、652で、ロールアウト手順を初期化し、このために、要求をvSIM−COREに送信する。
vSIMMGMT→vSIMCORE : init_rollout_vsim (式13)
【0076】
要求メッセージが受信された後に、vSIM−COREは、654で、めいめいのticketiを公開し、ticket−iの真正性および保全性をチェックする。次に、vSIM−COREは、ticket−iから値NONCE−Uを抽出し、U 602に、vSIM−MGMTを介して彼のアイデンティティを検証するように要求する。
vSIMCORE→vSIMMGMT : NONCEU (式14)
【0077】
サービスvSIM−MGMTは、ID−UおよびREGDATAUと一緒にNONCE−Uに署名する。このバンドルは、655でvSIM−COREに送り返される。
【0078】
【数6】
【0079】
サービスvSIM−COREは、メッセージを受信し終えるや否や、vSIM信用証明書配送要求を生成し、これをMNOの割り当てられた登録サービスにサブミットする656。このために、サービスvSIM−COREは、ticket−iからNONCE−MNOを抽出し、IMSI−iと一緒にこれに署名する。次に、vSIM−COREは、その生成された署名および受信されたユーザ署名を、ある検疫チャネルまたはインターネットを介してMNOに送信する656。
【0080】
【数7】
【0081】
vSIM COREからの要求が受信された後に、MNO 604は、658で、メッセージ、CERT−U、およびCert−TSS−MNOを(受信されたデータに基づく、ローカルメモリから、またはPOS(図示せず)によって提供される証明書に基づくのいずれかの検証によって)チェックする。情報が無効であるか拒絶される場合には、MNO 604は、エラーメッセージを応答し、このプロトコルを打ち切る。両方ともチケットから抽出されるNONCEMNOおよびNONCEUは、それぞれMNO 604およびU 602へのチャレンジである。REGDATAUは、IDUとの相関を可能にするために送信される。これらは、新鮮さのためには使用されず、新鮮さは、さまざまな形で、たとえば、メッセージに適切な粒度のタイムスタンプを追加することによって、達成することができる。
【0082】
もう1つのシナリオでは、要求は、MNO 604によって承認される。次に、MNOは、vSIM−COREへの送信のためにvSIM信用証明書のサブスクライバ関連部分を準備する。MNO 604は、ランダムに選択されるセッション鍵Ksを生成する。その後、鍵Ksは、660で、TSS−MNO 204からの対応する鍵と一緒に、ターゲットプラットフォームにリンクされ、その結果、データ(この場合には鍵Ks)を、関連する認可されたエンティティだけが使用できるようになる。MNO 604は、662で、セッション鍵と一緒にvSIM信用証明書のサブスクライバ関連部分を暗号化し、両方をTSS−MNO 204に送信する。
【0083】
【数8】
【0084】
最後に、TSS−MNO 204は、セッション鍵Ksを公開する。この鍵を用いて、TSS−MNO 204は、vSIM信用証明書のサブスクライバ関連部分を暗号化解除し、付随する署名をチェックする。暗号化解除が成功して実行され、検証された時に、vSIM−COREは、受信されたvSIM信用証明書を1つまたは複数の有効なプラットフォーム構成上で封印する。次に、vSIM−COREは、664で、手順を終了し、インストールを終える。
【0085】
代替案では、MNO 604は、分離された鍵Ksを生成し、vSIM信用証明書の暗号化されたサブスクライバ関連部分をticket−iに組み込むことができる。この場合に、MNO 604は、662で、ターゲットプラットフォームのvSIM−COREに鍵Ksだけを送信する。
【0086】
図7に、ソースプラットフォーム701からターゲットプラットフォーム707へvSIM信用証明書またはその実行環境を移行する手順の例を示す。この手順は、TSS−DO−S 702およびTSS−MNO−S 704を含むソースプラットフォーム701と、TSS−MNO−T 706およびTSS−DO−T 708を含むターゲットプラットフォーム707との間で実行される。SRK(ストレージルート鍵)を含むすべてのセキュリティに敏感なデータが、ターゲットTSS−MNO−Tに移行される。これは、両方のサブシステムTSS−MNO−SおよびTSS−MNO−T上に同一のRO(遠隔所有者)を必要とする。
【0087】
図7の移行手順は、完全な鍵階層を、(1)同一の利害関係者の実行環境の間で(2)このために特定のセキュリティポリシが両方のプラットフォームに存在し、認可される時に限って移行できることをもたらす。移行に関するこれらの制約は、1つのMNOだけがかかわることを必要とするが、信用証明書を、あるサブシステムから異なる所有者を有する別のサブシステムに移行することができる。利害関係者が同一であることの検証は、認証機構を介してソースエンティティおよび宛先エンティティによって実行することができる。構成転送は、ソフトウェアスイートを除いて信用証明書およびポリシだけが、あるプラットフォームから別のプラットフォームに移行され、移行が機能性と独立になるように、一般化することができる。
【0088】
この手順は、TSS−DO−S 702が、750で、TSS−MNO−S 704にサブシステム移行の要求を送信する時に開始される。TSS−MNO−S 704は、751で、ユーザのサービスレベルおよびターゲットMNOとの契約関係が移行を可能にするかどうかをチェックする。次に、TSS−MNO−S 704は、752で、サブシステム移行の要求(TSS−MNO−S−→TSS−MNO−T)をTSS−MNO−T 706に送信する。次に、TSS−MNO−T 706は、754で、ターゲットプラットフォーム707が許容できる状態であることを保証するために、TSS−MNO−S 704のローカル検証を実行する。次に、TSS−MNO−Tは、756で、移行を実行することの検証要求をTSS−DO−T 708に送信する。TSS−DO−T 708は、758で、確認を実行する。成功の検証の時に、TSS−DO−T 708は、760で、TSS−MNO−T 706に状態メッセージを送信する。次に、TSS−MNO−T 706は、762で、NONCE−MNO−Tを生成する。TSS−MNO−T 706は、764で、その証明書、ナンスNONCE−MNO−T、現在の状態Si,t、およびセキュリティポリシをTSS−MNO−S 704に送信する。次に、TSS−MNO−S 704は、766で、プラットフォームの検証を実行し、プラットフォームを移行のために準備する。成功の検証の時には、TSS−MNO−S 704は、768で、ソースプラットフォーム701のシリアル化を実行する。シリアル化とは、受け取る当事者がエンティティをそのオリジナルの形に再構成することを可能にするための、情報のビットストリームへのそのエンティティの変換と、通信チャネルを介するその運搬とである。次に、TSS−MNO−S 704は、770で、ソースサブシステムTSS−MNO−Sのシリアル化されたエンティティを含むメッセージをTSS−MNO−T 706に送信する。TSS−MNO−Tは、772で、ソースサブシステムをインポートする。次に、TSS−MNO−Tは、774で、TSS−MNO−S 704に状態メッセージを送信する。TSS−MNO.Sは、776でTSS−MNO−Sを破壊する。
【0089】
図7は、移行手順の特定の実施態様を示すが、次のセクションは、図7の手順に類似する終点を有するより一般的な手順を説明する。このために、デバイス所有者は、TSS−MNO−Sの移行サービスを開始する。
DOS→TSSMNO,S : init_migrate_vsim (式18)
【0090】
このサービスは、次の基本機能を提供する。プラットフォームMTP−S(またはTSS−DM)は、ターゲットプラットフォームMTP−Tへのセキュアチャネル(たとえばTLS、ここで、通信テクノロジを、Bluetooth、WLAN、USBなどとすることができる)を展開するために、TSS−MNO−Sの移行サービスによって割り当てられる。
【0091】
接続が使用可能になった後に、TSS−MNO−Tは、インポート手順を実行するためにTSS−MNO−T内のめいめいの移行サービスをアクティブ化する。
【0092】
TSS−MNO−Sの認証データが、セキュアチャネルを使用してTSS−MNO−Tに送信される。
【0093】
【数9】
【0094】
次に、ターゲットサブシステムTSS−MNO−Tは、TSS−MNO−Sのローカルチェックを実行する。752で受信される構成認証情報が無効である場合には、TSS−MNO−Tは、エラーメッセージを応答し、このプロトコルを打ち切る。それ以外の場合には、TSS−MNO−Tは、ローカル所有者DOによる確認を要求する。
【0095】
次に、ターゲットサブシステムTSS−MNO−Tは、乱数値NONCE−MNO−Tを生成する。その信頼性の証明を提供するために、TSS−MNO−Tは、すべての必要な情報をソースサブシステムTSS−MNO−Sに送信する。これは、Si,tの現在の状態、TSS−MNO−Tの証明書、セキュリティポリシSP−MNO−T、および値NONCE−MNO−Tを含む。
TSSMNO,T→TSSMNO,S : Si,T,CertTSSMNO,T
SPMNO,T,NONCEMNO,T
(式20)
【0096】
ターゲットサブシステムからのメッセージが受信された後に、TSS−MNO−Sは、TSS−MNO−Tの状態をチェックする。ターゲットシステムが、トラステッド状態にあり、受け入れられるセキュリティポリシおよび構成を実行する場合には、TSS−MNO−Sの現在の状態が、値NONCE−MNO−Tにリンクされ、すべてのさらなるアクションが、停止され、これによって、TSS−MNO−Sを非アクティブ化する。適用可能な場合に、ソースシステムが、ターゲットシステムを再アクティブ化するために適切なデータをサブミットすることに留意されたい。
【0097】
TSS−MNO−Sは、対称移行鍵K−Mを生成し、そのエンティティをシリアル化し、これをK−Mを用いて暗号化する。K−Mは、TSS−MNO−Tの受け入れられる構成にリンクされる。次に、リンクされた鍵K−Mおよび暗号化されたエンティティは、ターゲットプラットフォームTSS−MNO−Tに送信される。これは、具体的には、完全に隔離された鍵階層K−MNO−Sを、SRK−MNO−S、セキュリティポリシSP−MNO−S、および必要なSC−MNO−Sと一緒に含む。二重ナンスが、新鮮さを保存し、反射攻撃を防ぐために含まれる。状態報告など、ソースプラットフォームへのすべての戻りメッセージは、メッセージの新鮮さを維持するためにナンスNONCE−MNO−Sを必要とする。
【0098】
【数10】
【0099】
最後に、ターゲットサブシステムTSS−MNO−Tは、受信したK−Mを暗号化解除し、それ自体のSRKとしてSRK−MNO−Sを使用する。このサブシステムは、受信したセキュリティポリシSP−MNO−Sおよびサブシステム構成SC−MNO−Sをチェックする。次に、この情報を用いて、TSS−MNO−Tは、ソースサブシステムの内部構造を形成する。
【0100】
TSS−MNO−Tが成功して完成された後に、ターゲットプラットフォームは、状態レポートを送信し、適用可能な場合には、プラットフォーム認証をソースシステムに送信する。
【0101】
ソースプラットフォームTSS−MNO−Tは、すべてのセキュリティに敏感なデータを削除するか、これらを永久的に使用不能にする。次に、ソースシステムは、適用可能な場合に、状態レポートをターゲットシステムに送信し、かつ/またはプラットフォーム認証を実行する。
【0102】
図7の移行プロセスでは、実用上、ソースMNOおよびターゲットMNOが同一であると仮定する。この制限は、同一プロトコルの他の変形で取り除くことができ、それと同時に、ソースからターゲットへTSS−MNOのシリアル化されたエンティティを転送する必要が排除される。このために、ターゲット上の移行サービスは、ターゲット上のTSSがそれに関して必ずしも存在しない、指定されたターゲットMNO−B−Tと共に、ソースTSS−MNO−A−Sから許可された移行要求を受信することができる。この場合に、ターゲットは、まず、TSS−MNO−B−Tをインストールするために、MNO−Bとの遠隔所有権獲得手順を呼び出す。移行プロトコルは、本質的に未変更で実行できるが、TSS−MNO−A−Sのシリアル化されたエンティティの送信を省略し、その代わりに、MNO−Bと協力するネットワークアクセス、請求、および他の所望の機能に必要なそのTSSの非実行可能部分、具体的にはソースvSIMのIMSIだけを送信する。IMSI移行に関して、サブスクライバは、新しいIMSIが作成され、MNO−Bによって使用される時であっても、古い一意のサブスクライバ番号MSISDNを持ち続けることができる。
【0103】
図8に、図2のトラステッドモバイルプラットフォーム200のソフトウェアベースの認可信用証明書を使用してセルベースの通信ネットワークへの通信サブスクライバ802のアクセスを可能にする第1手順を実行するように構成された通信システムの例を示す。図8の手法は、ソフトウェアベースのアクセス認可信用証明書を使用して無線通信ネットワークへの通信サブスクライバ802のアクセスを可能にする。
【0104】
仮想ソフトウェアベースのアクセス認可信用証明書の主目的は、無線通信ネットワーク内のサブスクライバ認証用の従来のセキュリティトークン(SIMカード)の機能的代用を保証することである。従来のSIM機能の代用を提供することという主目的に加えて、この手順は、アクセス認可信用証明書を指定されたトラステッドプラットフォーム構成にリンクする。
【0105】
すべてのサブスクライバ関連の方法は、TSS−MNO内で、サービスvSIM−COREの使用によって実行される。GSM標準規格A3およびA8のアルゴリズムを、例のために下で示すが、類似する技法を、他の無線テクノロジの認証アルゴリズムと共に使用することもできる。下で提示する例では、これらのアルゴリズムは、サブスクライバ認証および鍵生成の責任を負う。通信チャネルを保護するアルゴリズムA5/3は、TSS−DMに統合される。
【0106】
図8の手順が始まる前に、MTP 200が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。この手順は、具体的には、サービスvSIM−COREおよびvSIM−MGMTのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。MTPは、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。
【0107】
この手順は、2つのフェーズに分割される。フェーズ1は、サービスvSIM−COREおよびvSIM−MGMTを初期化するためのプロトコルを構成する。たとえば、サブスクライバ認証は、たとえばGSM標準規格を考慮に入れ、MNOとデバイスとの間で行われる認証プロトコルメッセージに対する変更なしで認証アルゴリズムを実行するのにvSIM信用証明書を使用して、フェーズ2で実行される。
【0108】
フェーズ1は、ローカルユーザがvSIMサービスを初期化し、認証を実行する時に開始される。このために、ユーザ802は、850で、彼の曖昧でない識別子ID−Uを、正しいパスワードCHV−Uと一緒にvSIM−MGMTサービスに送信する。
【0109】
サービスvSIM−MGMTは、852で、送信されたユーザデータをチェックし、このチェックが成功である場合には、めいめいのアイデンティティ信用証明書(vSIM信用証明書のユーザ関連部分)を保護されたストレージエリアからロードする。アイデンティティ信用証明書は、具体的には、ユーザU 802の署名鍵を含む。
U→vSIMMGMT : IDU,CHVU (式22)
【0110】
次に、サービスvSIM−MGMTは、854で、サービスvSIM−COREのトラステッドインターフェースに接続し、初期化要求をvSIM−COREに送信する。vSIM−COREは、この要求を受信した後に、856で、乱数値RAND−AUTHを生成し、この値を認証メッセージとしてサービスvSIM−MGMTに送信する。
vSIMCORE→vSIMMGMT : RANDAUTH (式23)
【0111】
サービスvSIM−MGMTは、ユーザUの署名鍵のめいめいの秘密部分を使用し、認証メッセージRAND−AUTHに署名し、この値をサービスvSIM−COREに送り返す。
vSIMMGMT→vSIMCORE : SIGNU(RANDAUTH) (式24)
【0112】
vSIM−COREは、署名されたメッセージを受信するや否や、メッセージ状態をチェックする。成功のチェックの後に、サービスvSIM−COREは、vSIM信用証明書のサブスクライバ関連部分を暗号化解除し、GSMアルゴリズムA3およびA8を初期化する。初期化のために、vSIM−COREは、858で、vSIM信用証明書のサブスクライバデータIMSI−iおよびKiを使用する。
【0113】
フェーズ2は、vSIM−COREがMNOと間接的に(TSS−DMを介して)通信する時に開始される。かかわる通信当事者の間の通信は、透過的に行われる。このために、TSS−DM 202は、これらのメッセージをサービスvSIM−COREとMNO 806との間で中継する適切な方法またはサービスを提供しなければならない。
【0114】
次のプロトコルシーケンスは、GSMネットワーク内でのvSIMベースの認証方法を表し、例としてのみ提供される。まず、MTPは、認証方法を初期化し、このために、コマンドGSM_AUTH_ALGORITHMをTSS−MNOのサービスvSIM−COREに送信する。
【0115】
次のステップで、MTP 200は、860で、TSS−DMを介するネットワーク806へのアクセスを確立する。今や、サブスクライバ認証が、次の手順に従って実行される862。このために、TSS−MNO 204は、識別子IMSI−i(またはTMSI−i)をMNOに送信する。
vSIMCORE→MNO : IMSIi (式25)
【0116】
MNO 806は、一連の認証3つ組を内部で生成する。これらの3つ組は、認証要求RAND−i、一時セッション鍵Kc、および期待される認証応答SRESを含む。KcおよびSRESは、GSM A3/A8アルゴリズムを使用して計算される。MNO 806は、認証要求RAND−iをMTP 200に応答する。
MNO→vSIMCORE : RANDi (式26)
【0117】
RAND−iは、TSS−DM 202によってTSS−MNOのサービスvSIM−COREに中継される。次に、vSIM−COREは、鍵Kiと一緒にA3アルゴリズムを使用する。A3アルゴリズムの結果は、認証応答SRES*である。
【0118】
vSIM−COREは、このメッセージSRES*をMNOに送信する。
vSIMCORE→MNO : SRES* (式27)
【0119】
最後に、MNOは、SRESをSRES*と比較する。これらが同一である場合には、サブスクライバが認証されたと考えられる。vSIM−COREおよびMNOは、共有されるセッション鍵Kcを演繹し、KcをTSS−DMに送信する。次に、TSS−DMは、セキュア通信チャネルを確立するためにKcを受け入れる。
【0120】
図9および図10に、図2のトラステッドモバイルプラットフォーム200の遠隔認証を使用してセルベースの通信ネットワークへのユーザのアクセスを可能にする第2手順を実行するように構成された通信システムの例を示す。図9では、一般通信領域910およびより小さいMNO領域915があり、MNO領域915は、完全に一般通信領域910の境界内にある。ネットワーク918は、別々の、MNOに関係するサブスクリプション依存サービス920、サブスクリプション独立(加入独立)サービス925、ならびにロケーションベースのサービスおよび/または無線ローカルエリアネットワーク(WLAN)などの他のサービス930をも含む。
【0121】
図8の手順と比較して、この第2手順は、公益事業など、サブスクリプション独立および/または非サブスクライバ関連である無料サービスまたはオプションのサービスを使用するために、ネットワークへのアクセスを保証するのにプラットフォーム認証の技術的可能性を使用する。
【0122】
従来のSIM機能の代用を提供するという主目的に加えて、第2手順は、アクセス認可信用証明書を指定されたトラステッドプラットフォーム構成にリンクし、MNOとMTPとの間の相互認証を提供する。さらに、第2手順は、一般通信領域内のサブスクリプション独立および/または非サブスクライバ関連サービスへのコアネットワークアクセス、SIMロックなどの微細粒度の機能制限、ならびにサービスの動的ダウングレード/アップグレードを提供する。
【0123】
図9に示されているように、一般にアクセス可能な通信領域内のすべてのデバイスは、コアネットワークのサブスクリプション独立および/または非サブスクライバ関連サービス(MNOに関して)を使用し、またはこれにアクセスすることができる。そのようなサービスは、たとえば、ロケーションベースのサービスまたはWLANベースのインターネットアクセスとすることができる。携帯電話機が一般通信領域に関連する場合について、その携帯電話機は、認証機構を使用して、コアネットワークへのアクセスを入手する。
【0124】
MNOのサブスクライバ認証される領域(サブスクリプション依存MNOサービス)への遷移は、vSIM信用証明書の使用によるサブスクライバ認証の成功の完了を必要とする。したがって、MTPは、MNOによって提供される特定の通信サービス(GSM、UMTSなど)の領域内のサービスヘのアクセスならびにコアネットワークによって提供されるサービスへのアクセスを有する。
【0125】
図10に、図2のMTP 200の遠隔証明を使用してセルベースの通信ネットワークへの通信サブスクライバのアクセスを可能にする第2手順の例を示す。この手順を開始できる前に、MTP 200が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。この手順は、具体的には、サービスvSIM−COREおよびvSIM−MGMTのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。MTP 200は、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。
【0126】
図10の手順は、3つのフェーズに分割される。この手順の第1フェーズは、コアネットワークへのアクセスを記述する。この手順は、プラットフォーム認証およびチケッティング機構を使用する。第2フェーズでは、vSIM信用証明書を初期化する。最後に、第3フェーズは、サブスクライバ認証の方法を実施する。
【0127】
フェーズ1は、MTP 200がデバイスの基本認証を初期化する時に開始される。このために、トラステッド実行環境TSS−DM 202は、MNO 1006にプラットフォーム認証およびデバイス認証を指示する。次に、TSS−DM 202は、1050で、この要求を実行し、めいめいのNAP−MNO(ネットワークアクセスポイント1002)に接続する。このために、TSS−DM 202は、乱数値RAND−BASEを生成し、プラットフォーム認証を実行する。その後、基本認証サービスは、実行環境TSS−DM 202値RAND−BASE、認証データ、およびその証明書Cert−DMをネットワークアクセスポイントNAP−MNOに送信する。
TEDM→NAPMNO : RANDBASE,CertTSSDM
ATTEST(Si) (式28)
【0128】
この要求がNAP−MNOによって受信されるや否や、NAP−MNOは、MTP 200の状態をチェックする。保全性チェックが不合格であるか、受け入れられる基準状態が見つからない場合には、NAP−MNOは、このプロトコルを打ち切り、エラーメッセージを応答する。プラットフォームの証明が成功である場合には、MTP 200は、信頼できると考えられる。
【0129】
次に、NAP−MNOの公認されたエンティティは、セッション鍵K−BASEと一緒にネットワークチケットを生成する1052。そのようなエンティティは、たとえば、モバイルネットワークプロバイダMNOの一部であるAUC−MNO(認証センタ)とすることができる。K−BASEは、MTPとNAP−MNOとの間でトンネルを確立する、最小限に使用されるセッション鍵である。このトンネルは、大量のデータ暗号化作業負荷を実行するトラフィック指向鍵の分配を保護するのに使用することができる。この鍵の選択は、認証トラステッドサードパーティによって行われる。
【0130】
チケットは、本質的に次の情報を含み、ここで、REALMは、デバイスとの直接通信に用いられるPLMNエンティティ(AuC、VLR、HLRなど)を識別し、LIFETIMEは、チケット満了値を識別する。
TicketBASE := {IDMTP,IDNAP,KBASE,REALMBASE,LIFETIMEBASE} (式29)
【0131】
次に、AUC−MNOは、1054で、公開(または、適用可能な場合には共有)鍵K−NAPを使用してTicket−BASEを暗号化し、K−BASEをK−TSS−DMの公開鍵にバインドすることによってK−BASEをも暗号化し、この両方をNAP−MNOに送信する。NAP−MNOは、1056で、この情報をクライアントプラットフォームに中継する。このメッセージは、めいめいの公開鍵K−TSS−DMおよび有効なプラットフォーム構成と一緒にトラステッドサブシステムTSS−DM 202にリンクもされる。TSS−DM 202が、単独ではTicket−BASEを暗号化解除できないことに留意されたい。というのは、このチケットを、秘密K−NAPを使用することによってのみ暗号化解除することができ、TSS−DM 202がそれを有していないからである。そうではなく、TSS−DM 202は、より後のステップで暗号化されたTicket−BASEをNAP−MNOに転送し、このNAP−MNOで、暗号化されたTicket−BASEを暗号化解除することができる。
【0132】
【数11】
【0133】
TSS−DM 202は、署名されたメッセージを受信するや否や、1058で、署名された値RAND−BASEの状態をチェックする。情報が無効であるか拒絶される場合には、このサブシステムは、エラーメッセージを応答し、このプロトコルを打ち切る。別の場合には、AUC−MNOは、認証応答によって証明される。
【0134】
次に、TSS−DM 202は、セッション鍵K−BASEを暗号化解除し、オーセンティケータA−MTPと一緒に、暗号化されたTicket−BASEをNAP−MNOに送信する。現在のケースでは、オーセンティケータA−MTPは、プラットフォームアイデンティティID−MTP、現在のネットワークアドレスADDR、およびタイムスタンプTIMEからなる。
【0135】
【数12】
【0136】
チケットベースTicket−BASEは、単純にTSSDMによってネットワークに渡され、このネットワークで暗号化解除される。NAP−MNOは、暗号化されたチケットを受信し終えた時に、組み込まれた情報を検証する。K−NAPの公開部分を使用するTicket−BASEの暗号化を用いて、有効なバインディングが行われる。具体的に言うと、K−BASEは、チケットの一部として、NAPにバインドされる。状態が有効である場合には、プラットフォームが証明され、一般サービスへのアクセスが許可される。限定的利用セッション鍵K−BASEは、今や、MTP 200とNAP−MNOとの両方にバインドされて、この2つのエンティティの間でセキュアトンネルをセットアップする。
【0137】
フェーズ2の手順は、図8の手順の850〜858に類似している。
【0138】
フェーズ3を完了するための2つのオプションがあり、第1のオプションは、たとえばGSM標準規格との互換性を有するサブスクライバ認証を実行する。追加のステップで、鍵K−BASEが、1070で、NAP−MNOおよびMTPの側でセッション鍵Kcによって置換される。
【0139】
この点で、相互認証が、AUC−MNOとUとの間で実行される。AUC−MNOは、1056で、署名された認証要求によって証明される。その一方で、ユーザ1008は、SRESによって彼のアイデンティティを検証する。NAP−MNOとU 1008との間の認証は、有効なメッセージ鍵Kcによって暗黙のうちに検証される。
【0140】
この方法を、1056で、暗号化された鍵メッセージに前もってRAND−iを組み込むことによって最適化することができる。この場合に、vSIM−COREは、このメッセージからRAND−iを抽出し、認証応答SRESを計算し、この両方の結果をMNOに送信する。MNOは、期待されるSRESおよび対応するセッション鍵Kcを内部で生成する。
【0141】
これらのエンティティの明示的認証が要求される時には、追加ステップを実行しなければならない。NAPは、プラットフォームに関して、次の手順によって証明される。まず、NAPは、オーセンティケータAuからタイムスタンプを除去する。次に、NAPは、その値を増分し、共有セッション鍵Kc(またはそれから導出された鍵)を使用して暗号化する。最後に、NAPは、そのメッセージをMTPに送り返す。
【0142】
フェーズ3の第2のオプション(図示せず)では、認証方法は、GSM認証標準規格から逸脱することができる。この変形は、PLMNのセキュリティにおけるかなりの増加をもたらす、わずかに変更された認証方法を表す。具体的に言うと、SS7(signal system 7)のプロトコルエラーを、この形で回避することができる。
【0143】
次の変形は、フェーズ1からのコアネットワークアクセスに関する前者のネゴシエートされた情報を利用する。従来のGSMインフラストラクチャでは、認証3つ組は、SS7ネットワークを介して送信される。この3つ組は、チャレンジRAND、正しいレスポンスSRES、およびメッセージ鍵Kcを含む。
【0144】
モバイル通信ネットワークへの初期アクセスは、メッセージ鍵K−BASEによって確立されるが、この鍵の更新は、不要である。これは、具体的には、セッション鍵Kcの組込みに適用される。これによって、保護されないセッション鍵の伝送が回避される。
【0145】
このオプションの基本的な目的は、鍵K−BASEを基礎として保護されるNAP−MNOとMTPとの間の既存通信トンネルを利用することである。セッション鍵を更新するのではなく、MNOは、サービス更新メッセージだけをめいめいのネットワークアクセスポイントNAPおよびMTPに送信する。
【0146】
現在のPLMNでは、たとえばGSMシステムまたはUMTSシステムではIMSI番号によって表される、ネットワークサブスクライバのアドレス空間が、不足しがちである。チケットに基づくネットワークアクセスメソッドは、この問題を克服する形である。このために、IMSI情報(または、類似するネットワークサブスクライバID)を、TSS−DMによってNAP−MNOに配送されるMTPアイデンティティと一緒に、またはTSS−DMが入手し、NAP−MNOに転送できる任意の他のアイデンティティを担持する情報と一緒に使用することができる。上のプロトコルが成功し、要求するMTPがネットワークアクセスを得た後に、NAP−MNOは、同一IMSIを有する通信を現在のADDRデータに正しくマッピングし、これによって正しいエンティティに正しくマッピングするために、デバイスから発出するまたはデバイスに向けられるサービス要求に能動的に用いられる。やはり、ADDRデータが、GSMシステムまたはUMTSシステムの文脈ではIMSIまたはTMSIになることに留意されたい。すなわち、NAP−MNOは、PLMN基地局の既存識別方法を拡張する。
【0147】
この方法を使用して、具体的には、たとえばmachine−to−machine通信の場合または単一の利害関係者に属するデバイスフリートについて、グループIMSIアドレッシングを確立することができる。
【0148】
さらに、同一デバイスの複数のネットワークアクセスチケットが、Ticket−BASE内の追加情報によっても示される、異なるサービスレベルまたは料金について同時に有効であることができる。これらの追加のアイデンティティ情報を使用して、同一のまたは異なるMTP上で同一のIMSIを共有する異なるvSIMエンティティおよび/またはユーザを識別することもできる。
【0149】
チケットを、たとえばある種のサービスのアクセシビリティの期間またはそのような時間期間中の特定の料金を判定する有効性期間情報に関する情報によって増補することもできる。次に、NAPまたは別のエンティティは、チケットアイデンティティおよびそれに関連する既知の有効性期間に基づいてそのような時間限定サービスを決定し、それに関する決定を実施するタスクを入手する。
【0150】
図11に、一般ネットワークインフラストラクチャのサブスクライバ認証の第3手順を示す。図11の手順について、vSIM信用証明書のサブスクライバ関連部分の構造設計およびトラステッドサービスvSIM−COREの機能性または統合されたアルゴリズムは、ある種の要件を厳守しなければならない。
【0151】
図11のvSIM信用証明書は、対象のアイデンティティに基づくアクセス認可信用証明書である。このアクセス認可信用証明書は、2G/3G構造モールド(structural mold)にはバインドされず、図8および図10の対応物の一般化であり、通信サブスクライバのアイデンティティを証明するのに使用される。vSIM信用証明書は、対象U 1110の一意識別子ID−Uおよび暗号法の暗号化機構(たとえば、対称鍵または非対称鍵)または非暗号法の暗号化機構(たとえば、一方向ハッシュチェーン)に基づく少なくとも1つの情報アイテムを含む。認可された対象だけが、vSIM信用証明書を生成するか読み取り、あるいは含まれる情報を変更することができる。vSIM信用証明書は、デバイスアイデンティティまたは有効な適用エリアのリストなどの追加情報を含むことができる。
【0152】
MTP 1108は、別々の保護された実行環境内で動作するvSIM−COREサービスのインスタンスを作成する。サービスvSIM−COREは、サブスクライバ認証のコア機能の責任を負う。具体的に言うと、このサービスは、実際の認証機構を実行する。機構または手順の特定の設計は、特定の応用例に依存する。サービスvSIM−COREは、おそらくは特定のユースケースに基づいて、トラステッド機能性をインポートすることができ、他の(外部の)トラステッドサービスを提供することもできる。vSIM−COREは、vSIM信用証明書の少なくとも1つのサブスクライバ関連部分をも含む。
【0153】
図11の手順が開始される前に、MTP 1108が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。これは、具体的には、サービスvSIM−COREおよびvSIM−MGMTのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。MTPは、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。
【0154】
図11の手順は、3つのフェーズに分割される。フェーズ1 1120は、遠隔証明である。フェーズ2 1130は、vSIM信用証明書の初期化である。フェーズ3 1140は、サブスクライバ認証手順である。
【0155】
フェーズ1 1120では、プラットフォーム認証が、上の例によって説明されたようにデバイス認証を実行するのに使用される。図11に提供されたこの一般的なケースでは、ネットワークエンティティMNO 1112は、一般ネットワークインフラストラクチャのめいめいのエンティティによって置換される。そのようなエンティティは、たとえば、このネットワーク内のALS(認証サーバ)とすることができ、このサーバは、必ずしも2Gテクノロジまたは3Gテクノロジに束縛されるのではなく、long term evolution(LTE)などの将来のネットワークに適用することができる。
【0156】
フェーズ2 1130すなわちvSIMサービスの初期化およびvSIM信用証明書の初期化は、図10のフェーズ2手順に類似する形で実行される。しかし、この手順は、一般化された仮定に基づき、したがって、さらなる認証の方法およびプロトコルのためのより幅広い基礎を使用可能にする。
【0157】
フェーズ3 1140は、ALSによって提供されるサービスの所与のサブスクライバを認証し、認可する、サブスクライバ認証手順である。対照的に、図8および図10の手順は、共有される秘密情報(GSMによる対称鍵Ki)のサブスクライバ認証の手順に限定される。具体的に言うと、この限定は、図11の包括的手順には存在しない。したがって、図11の手順では、共有される秘密は使用されず、認証プロセスは、完全に証明書ベースの非対称暗号法に基づく。たとえば、証明書機関(CA)を用いるDiffie−Hellmanを使用して、鍵交換を、トラステッドエンティティの間で行うことができる。そのようなシナリオでは、当事者は、CAによる検証を伴う相互アイデンティティを必要とする。
【0158】
フェーズ3 1140では、乱数値RAND−SRVが、ALS上のサービスの拡張を要求するのに使用される。TE−MNOは、ticket−BASEからRAND−SRVを抽出する。次に、TSS−MNOが、認証応答XRES*−SRVを作り、その秘密署名鍵K−priv−TM−ASを用いてRAND−SRVに署名する。UIDおよびサービス識別子SRVと一緒に、この署名XRES*−SRVは、ALSに送信される。ALSは、このメッセージを受信するや否や、XRES*−SRVの署名を検証する。署名が有効である場合には、プラットフォームが証明され、サービス拡張が実行される。
【0159】
特徴および要素を、上で特定の組合せで説明したが、各特徴または要素を、他の特徴および要素を伴わずに単独で、または他の特徴および要素を伴ってもしくは伴わずにさまざまな組合せで使用することができる。本明細書で提供される方法または流れ図は、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読格納媒体に組み込まれる、コンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読格納媒体の例は、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにCD−ROMディスクおよびディジタル多用途ディスク(DVD)などの光媒体を含む。
【0160】
適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、ディジタル信号プロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアに関連する1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、すべての他のタイプの集積回路(IC)、および/または状態機械を含む。
【0161】
ソフトウェアに関連するプロセッサを使用して、無線送受信ユニット(WTRU)、ユーザ機器(UE)、端末、基地局、無線ネットワークコントローラ(RNC)、またはすべてのホストコンピュータで使用されるラジオ周波数トランシーバを実施することができる。WTRUは、カメラ、ビデオカメラモジュール、ビデオ電話機、スピーカホン、振動デバイス、スピーカ、マイクロホン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Bluetooth(登録商標)モジュール、周波数変調(FM)ラジオユニット、液晶ディスプレイ(LCD)ディスプレイユニット、有機発光ダイオード(OLED)ディスプレイユニット、ディジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザ、および/またはすべての無線ローカルエリアネットワーク(WLAN)もしくはウルトラワイドバンド(UWB)モジュールなどのハードウェアおよび/またはソフトウェアで実施されるモジュールに関連して使用される。
【0162】
実施形態
1.vSIM(virtual subscriber identity module)−coreトラステッド実行環境およびvSIM−MGMT(vSIM−management)トラステッド実行環境を有するMTP(mobile trusted processor)上でvSIM信用証明書を登録し、受信する方法であって、
登録およびチケットの要求をトラステッドPOS(売り場、店舗)に送信することと、
要求および他の信頼検証手順に応答してトラステッドPOSからチケットを受信することと
を含むことを特徴とする方法。
2.POSとのトラステッド関係を確立すること
をさらに含むことを特徴とする実施形態1に記載の方法。
3.トラステッド関係の確立は、POSと共に認証手順を実行することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
4.トラステッド関係の確立は、POSと共に認証手順を実行することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
5.vSIM(virtual subscriber identity module)−coreトラステッド実行環境およびvSIM−MGMT(vSIM−management)トラステッド実行環境を有するMTP(mobile trusted processor)にvSIM信用証明書を登録し、供給する、遠隔POS(売り場)によって実行される方法であって、
登録およびチケットの要求をMTPから受信することと、
登録チケットを選択することと、
MTPに関係するサブスクライバ登録データおよび登録チケットの要求をMNO(ネットワークプロバイダ)に送信することと、
MNOから登録チケットを受信することと、
登録チケットをMTPに送信することと
を含むことを特徴とする方法。
6.POSは、トラステッドPOSであることを特徴とする前の実施形態のいずれか一項に記載の方法。
7.MTPに関係するサブスクライバ登録データおよび登録チケットの要求を送信することは、認証データを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
8.MNOとのトラステッド関係を確立することをさらに含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
9.MTPとのトラステッド関係を確立することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
10.受信されたチケット要求は、公開暗号化鍵の少なくとも一部を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
11.MTPに関係するサブスクライバ登録データおよび登録チケットの要求は、認証用の署名を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
12.登録チケットは、認証情報を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
13.登録チケットは、認証情報を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
14.登録チケットは、署名された証明書を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
15.MTPを用いて証明された非対称鍵対を確立すること
をさらに含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
16.受信された登録チケットは、暗号化されていることを特徴とする前の実施形態のいずれか一項に記載の方法。
17.POSは、信頼されないことを特徴とする前の実施形態のいずれか一項に記載の方法。
18.MTP(mobile trusted platform)であって、
MTPの製造メーカーに関係する信用証明書を格納し、提供するように構成されたTSS−DM(デバイス製造メーカートラステッドサブシステム)と、
MNO(モバイルネットワークオペレータ)に関係する信用証明書を格納し、提供するように構成されたTSS−MNO(モバイルネットワークオペレータ−トラステッドサブシステム)と、
MTPのユーザに関係する信用証明書を格納し、提供するように構成されたTSS−U(デバイスユーザ−トラステッドサブシステム)と
を含むことを特徴とするMTP。
19.TSS−MNOは、MNOに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM(virtual subscriber identity module)コアサービスユニットを含むことを特徴とする実施形態18に記載のMTP。
20.TSS−DOは、MTPのユーザに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM(virtual subscriber identity module)管理ユニットを含むことを特徴とする実施形態18〜19のいずれか一項に記載のMTP。
21.TSS−DOおよびTSS−MNOは、トラステッドvSIM(virtual subscriber identity module)サービスを介して通信することを特徴とする実施形態18〜20のいずれか一項に記載のMTP。
22.MTPの第2ユーザに関係する信用証明書を格納し、提供するように構成された第2TSS−U
をさらに含むことを特徴とする実施形態18〜21のいずれか一項に記載のMTP。
23.MTPの所有者に関係する信用証明書を格納し、提供するように構成されたデバイス所有者−トラステッドサブシステムTSS−DO
をさらに含むことを特徴とする実施形態18〜22のいずれか一項に記載のMTP。
24.第2MNOに関係する信用証明書を格納し、提供するように構成された第2TSS−MNO
をさらに含むことを特徴とする実施形態18〜23のいずれか一項に記載のMTP。
【特許請求の範囲】
【請求項1】
vSIM(virtual subscriber identity module)−coreトラステッド実行環境およびvSIM−MGMT(vSIM−management)トラステッド実行環境を有するMTP(mobile trusted processor)上でvSIM信用証明書を登録し、受信する方法であって、
登録およびチケットの要求をトラステッドPOS(売り場)に送信するステップと、
前記要求および他の信頼検証手順に応答して前記トラステッドPOSからチケットを受信するステップと
を含むことを特徴とする方法。
【請求項2】
前記POSとのトラステッド関係を確立するステップ
をさらに含むことを特徴とする請求項1に記載の方法。
【請求項3】
トラステッド関係の前記確立は、前記POSと共に認証手順を実行するステップを含むことを特徴とする請求項2に記載の方法。
【請求項4】
トラステッド関係の前記確立は、前記POSと共に認証手順を実行するステップを含むことを特徴とする請求項2に記載の方法。
【請求項5】
vSIM(virtual subscriber identity module)−coreトラステッド実行環境およびvSIM−MGMT(vSIM−management)トラステッド実行環境を有するMTP(mobile trusted processor)にvSIM信用証明書を登録し、供給する、遠隔POS(売り場)によって実行される方法であって、
登録およびチケットの要求を前記MTPから受信するステップと、
登録チケットを選択するステップと、
前記MTPに関係するサブスクライバ登録データおよび登録チケットの要求をMNO(ネットワークプロバイダ)に送信するステップと、
前記MNOから登録チケットを受信するステップと、
前記登録チケットを前記MTPに送信するステップと
を含むことを特徴とする方法。
【請求項6】
前記POSは、トラステッドPOSであることを特徴とする請求項5に記載の方法。
【請求項7】
前記MTPに関係するサブスクライバ登録データおよび登録チケットの要求を送信するステップは、認証データを含むことを特徴とする請求項5に記載の方法。
【請求項8】
前記MNOとのトラステッド関係を確立するステップをさらに含むことを特徴とする請求項5に記載の方法。
【請求項9】
前記MTPとのトラステッド関係を確立するステップをさらに含むことを特徴とする請求項5に記載の方法。
【請求項10】
前記受信されたチケット要求は、公開暗号化鍵の少なくとも一部を含むことを特徴とする請求項5に記載の方法。
【請求項11】
前記MTPに関係するサブスクライバ登録データおよび登録チケットの要求は、認証用の署名を含むことを特徴とする請求項5に記載の方法。
【請求項12】
登録チケットは、認証情報を含むことを特徴とする請求項5に記載の方法。
【請求項13】
登録チケットは、認証情報を含むことを特徴とする請求項5に記載の方法。
【請求項14】
登録チケットは、署名された証明書を含むことを特徴とする請求項5に記載の方法。
【請求項15】
前記MTPを用いて証明された非対称鍵対を確立するステップ
をさらに含むことを特徴とする請求項5に記載の方法。
【請求項16】
前記受信された登録チケットは、暗号化されていることを特徴とする請求項5に記載の方法。
【請求項17】
前記POSは、信頼されないことを特徴とする請求項5に記載の方法。
【請求項18】
MTP(mobile trusted platform)であって、
前記MTPの製造メーカーに関係する信用証明書を格納し、提供するように構成されたTSS−DM(デバイス製造メーカートラステッドサブシステム)と、
MNO(モバイルネットワークオペレータ)に関係する信用証明書を格納し、提供するように構成されたTSS−MNO(モバイルネットワークオペレータ−トラステッドサブシステム)と、
前記MTPのユーザに関係する信用証明書を格納し、提供するように構成されたTSS−U(デバイスユーザ−トラステッドサブシステム)と
を含むことを特徴とするMTP。
【請求項19】
前記TSS−MNOは、前記MNOに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM(virtual subscriber identity module)コアサービスユニットを含むことを特徴とする請求項18に記載のMTP。
【請求項20】
TSS−DOは、前記MTPの前記ユーザに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM(virtual subscriber identity module)管理ユニットを含むことを特徴とする請求項18に記載のMTP。
【請求項21】
TSS−DOおよび前記TSS−MNOは、トラステッドvSIM(virtual subscriber identity module)サービスを介して通信することを特徴とする請求項18に記載のMTP。
【請求項22】
前記MTPの第2のユーザに関係する信用証明書を格納し、提供するように構成された第2のTSS−U
をさらに含むことを特徴とする請求項1に記載のMTP。
【請求項23】
前記MTPの所有者に関係する信用証明書を格納し、提供するように構成されたデバイス所有者−トラステッドサブシステムTSS−DO
をさらに含むことを特徴とする請求項18に記載のMTP。
【請求項24】
第2のMNOに関係する信用証明書を格納し、提供するように構成された第2のTSS−MNO
をさらに含むことを特徴とする請求項18に記載のMTP。
【請求項1】
vSIM(virtual subscriber identity module)−coreトラステッド実行環境およびvSIM−MGMT(vSIM−management)トラステッド実行環境を有するMTP(mobile trusted processor)上でvSIM信用証明書を登録し、受信する方法であって、
登録およびチケットの要求をトラステッドPOS(売り場)に送信するステップと、
前記要求および他の信頼検証手順に応答して前記トラステッドPOSからチケットを受信するステップと
を含むことを特徴とする方法。
【請求項2】
前記POSとのトラステッド関係を確立するステップ
をさらに含むことを特徴とする請求項1に記載の方法。
【請求項3】
トラステッド関係の前記確立は、前記POSと共に認証手順を実行するステップを含むことを特徴とする請求項2に記載の方法。
【請求項4】
トラステッド関係の前記確立は、前記POSと共に認証手順を実行するステップを含むことを特徴とする請求項2に記載の方法。
【請求項5】
vSIM(virtual subscriber identity module)−coreトラステッド実行環境およびvSIM−MGMT(vSIM−management)トラステッド実行環境を有するMTP(mobile trusted processor)にvSIM信用証明書を登録し、供給する、遠隔POS(売り場)によって実行される方法であって、
登録およびチケットの要求を前記MTPから受信するステップと、
登録チケットを選択するステップと、
前記MTPに関係するサブスクライバ登録データおよび登録チケットの要求をMNO(ネットワークプロバイダ)に送信するステップと、
前記MNOから登録チケットを受信するステップと、
前記登録チケットを前記MTPに送信するステップと
を含むことを特徴とする方法。
【請求項6】
前記POSは、トラステッドPOSであることを特徴とする請求項5に記載の方法。
【請求項7】
前記MTPに関係するサブスクライバ登録データおよび登録チケットの要求を送信するステップは、認証データを含むことを特徴とする請求項5に記載の方法。
【請求項8】
前記MNOとのトラステッド関係を確立するステップをさらに含むことを特徴とする請求項5に記載の方法。
【請求項9】
前記MTPとのトラステッド関係を確立するステップをさらに含むことを特徴とする請求項5に記載の方法。
【請求項10】
前記受信されたチケット要求は、公開暗号化鍵の少なくとも一部を含むことを特徴とする請求項5に記載の方法。
【請求項11】
前記MTPに関係するサブスクライバ登録データおよび登録チケットの要求は、認証用の署名を含むことを特徴とする請求項5に記載の方法。
【請求項12】
登録チケットは、認証情報を含むことを特徴とする請求項5に記載の方法。
【請求項13】
登録チケットは、認証情報を含むことを特徴とする請求項5に記載の方法。
【請求項14】
登録チケットは、署名された証明書を含むことを特徴とする請求項5に記載の方法。
【請求項15】
前記MTPを用いて証明された非対称鍵対を確立するステップ
をさらに含むことを特徴とする請求項5に記載の方法。
【請求項16】
前記受信された登録チケットは、暗号化されていることを特徴とする請求項5に記載の方法。
【請求項17】
前記POSは、信頼されないことを特徴とする請求項5に記載の方法。
【請求項18】
MTP(mobile trusted platform)であって、
前記MTPの製造メーカーに関係する信用証明書を格納し、提供するように構成されたTSS−DM(デバイス製造メーカートラステッドサブシステム)と、
MNO(モバイルネットワークオペレータ)に関係する信用証明書を格納し、提供するように構成されたTSS−MNO(モバイルネットワークオペレータ−トラステッドサブシステム)と、
前記MTPのユーザに関係する信用証明書を格納し、提供するように構成されたTSS−U(デバイスユーザ−トラステッドサブシステム)と
を含むことを特徴とするMTP。
【請求項19】
前記TSS−MNOは、前記MNOに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM(virtual subscriber identity module)コアサービスユニットを含むことを特徴とする請求項18に記載のMTP。
【請求項20】
TSS−DOは、前記MTPの前記ユーザに関係する信用証明書情報を格納し、提供し、処理するように構成されたvSIM(virtual subscriber identity module)管理ユニットを含むことを特徴とする請求項18に記載のMTP。
【請求項21】
TSS−DOおよび前記TSS−MNOは、トラステッドvSIM(virtual subscriber identity module)サービスを介して通信することを特徴とする請求項18に記載のMTP。
【請求項22】
前記MTPの第2のユーザに関係する信用証明書を格納し、提供するように構成された第2のTSS−U
をさらに含むことを特徴とする請求項1に記載のMTP。
【請求項23】
前記MTPの所有者に関係する信用証明書を格納し、提供するように構成されたデバイス所有者−トラステッドサブシステムTSS−DO
をさらに含むことを特徴とする請求項18に記載のMTP。
【請求項24】
第2のMNOに関係する信用証明書を格納し、提供するように構成された第2のTSS−MNO
をさらに含むことを特徴とする請求項18に記載のMTP。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11A】
【図11B】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11A】
【図11B】
【公表番号】特表2011−516931(P2011−516931A)
【公表日】平成23年5月26日(2011.5.26)
【国際特許分類】
【出願番号】特願2010−526001(P2010−526001)
【出願日】平成20年9月19日(2008.9.19)
【国際出願番号】PCT/US2008/077029
【国際公開番号】WO2009/039380
【国際公開日】平成21年3月26日(2009.3.26)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(510030995)インターデイジタル パテント ホールディングス インコーポレイテッド (229)
【Fターム(参考)】
【公表日】平成23年5月26日(2011.5.26)
【国際特許分類】
【出願日】平成20年9月19日(2008.9.19)
【国際出願番号】PCT/US2008/077029
【国際公開番号】WO2009/039380
【国際公開日】平成21年3月26日(2009.3.26)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.GSM
【出願人】(510030995)インターデイジタル パテント ホールディングス インコーポレイテッド (229)
【Fターム(参考)】
[ Back to top ]