JP2013242878A - 仮想サブスクライバ識別モジュール - Google Patents

Abstract

【課題】ＳＩＭカードまたはＵＩＣＣのセキュリティは、それが常駐するデバイス全体のセキュリティの属性に強くリンクされていない。モバイル金融取引などの高度なサービスやアップリケーションに関するセキュリティのスケーリング（拡大縮小）のコンセプトの適用を制限する。これらの問題のすべてが、たとえばＭ２Ｍ通信シナリオで、モバイルネットワークに接続された自律的デバイスに対して切迫している。ＳＩＭ機能に対するより動的で同時に安全なソフトウェアベースの解決策が必要である。
【解決手段】ｖＳＩＭサービスを提供するように構成されたＭＴＰを開示する。ＭＴＰは、ＭＴＰの製造メーカに関係する信用証明書を格納し、提供するように構成されたＴＳＳ−ＤＭ（デバイス製造メーカートラステッドサブシステム）と、ＭＮＯに関係する信用証明書を格納し、提供するように構成されたＭＮＯ−ＴＳＳ（と、ＭＴＰのユーザに関係する信用証明書を格納し提供するように構成されたＴＳＳ−ＤＯ／ＴＳＳ−Ｕとを含む。
【選択図】図１

Description

本発明は、無線通信に関する。

無線通信デバイスの数の増加に伴って、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ：契約者情報記録モジュール、電話番号を特定するための固有のＩＤ番号が記録されたＩＣモジュール）カードまたはＵＩＣＣ（Ｕｎｉｖｅｒｓａｌ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ Ｃａｒｄ）内で実行される現在のＳＩＭ機能に対するより動的な解決策を提供し、現代のおよび開発中のモバイル通信ネットワークに関して、いくつかの短所を克服する必要がある。ＵＩＣＣは、そこからＳＩＭ認証アルゴリズムを実行し、信用証明書を格納する、安全な実行および格納環境を有する。

しかしながら、ＵＩＣＣのコスト、その非実用的な形状因子、および制限された機能性が、モバイルネットワークの操作者（オペレータ）が無線デバイスを購入してからしばらく後でのみ知るアプリケーションでの使用を妨げる。あるいは、ＵＩＣＣは、複数の操作者のネットワークを１つのデバイス内で同時にサポートしまたはアクセスしなければならない時に、役に立たなくなくなる。モバイルネットワークおよびサービスのサブスクリプション（加入契約）を更新するか、あるいは変更する方法は、ＳＩＭカードに関して制限されているので、無線の配備が望まれる場合に、一般に欠如している。

さらに、ＳＩＭカードまたはＵＩＣＣは、一般に、非常に安全と考えられるが、このセキュリティは、それが常駐するデバイス全体のセキュリティの属性に強くリンクされていない。これは、モバイル金融取引などの高度なサービスやアップリケーションに関するセキュリティのスケーリング（拡大縮小）のコンセプトの適用を制限する。これらの問題のすべてが、たとえばｍａｃｈｉｎｅ−ｔｏ−ｍａｃｈｉｎｅ（Ｍ２Ｍ）通信シナリオで、モバイルネットワークに接続された自律的デバイスに対して切迫している。

したがって、ＳＩＭ機能に対するより動的で同時に安全なソフトウェアベースの解決策が必要である。

ｖＳＩＭ（ｖｉｒｔｕａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｉｄｅｎｔｉｆｙ Ｍｏｄｕｌｅ；仮想サブスクライバ識別モジュール）サービスを提供するように構成されたＭＴＰ（Ｍｏｂｉｌｅ Ｔｒｕｓｔｅｄ Ｐｌａｔｆｏｒｍ；携帯情報機器向けのセキュリティ機構仕様、移動体通信セキュリティプラットフォーム）を開示する。一実施形態では、ＭＴＰは、ＭＴＰの製造メーカに関係する信用証明書を格納し、提供するように構成されたＴＳＳ−ＤＭ（装置製造メーカの信頼されたサブシステム）と、ＭＮＯ（移動体通信オペレータ）に関係する信用証明書を格納し、提供するように構成されたＴＳＳ−ＭＮＯ（モバイルネットワークオペレータ−トラステッドサブシステム）と、ＭＴＰのユーザに関係する信用証明書を格納し、提供するように構成されたＴＳＳ−ＤＯ／ＴＳＳ−Ｕ（装置所有者／ユーザの信頼されたサブシステム）とを含む。ＴＳＳ−ＭＮＯは、ＭＮＯに関係する信用証明書情報を格納し、提供し、かつ処理するように構成されたｖＳＩＭ（仮想契約者情報記録モジュール）コアサービスユニットを含む。ＴＳＳ−ＤＯ／ＴＳＳ−Ｕは、ＭＴＰのユーザに関係する信用証明書情報を格納し、提供し、かつ処理するように構成されたｖＳＩＭ管理ユニットを含む。ＴＳＳ−ＤＯ／ＴＳＳ−ＵおよびＴＳＳ−ＭＮＯは、トラステッドｖＳＩＭサービスを介して通信する。オプション（随意）で、ＭＴＰは、デバイスユーザ機能およびデバイス所有者機能をＴＳＳ−ＤＯとＴＳＳ−Ｕとに分離することができ、ＭＴＰの第２ユーザに関係する信用証明書を格納し、提供するように構成された第２のＴＳＳ−Ｕを含むことができる。また、ＭＴＰは、ＭＴＰの所有者に関係する信用証明書を格納し、提供するように構成されたＴＳＳ−ＤＯ（デバイス所有者−トラステッドサブシステム）を含むことができる。ＭＴＰは、第２のＭＮＯに関係する信用証明書を格納し、提供するように構成された第２のＭＮＯ−ＴＳＳをも含むことができる。

ｖＳＩＭサービスを提供する際に使用されるトラステッドサブシステムをリモート（遠隔）で作成する手順をも開示する。

ｖＳＩＭサービスを提供する際に使用されるトラステッドサブシステムを登録し、記録する手順をも開示する。

遠隔位置からＭＴＰにｖＳＩＭサービスを提供する際に使用されるトラステッドサブシステムを配送する手順をも開示する。

ソースＭＴＰからターゲットＭＴＰにｖＳＩＭサービスを提供する際に使用されるトラステッドサブシステムを移行する手順をも開示する。

ｖＳＩＭ構成を使用するサブスクライバ（電話加入者）が無線ネットワークにアクセスすることを可能にする３つの関連する方法をも開示する。

より詳細な理解は、添付図面に関連して例として与えられた下記の説明から得ることができる。

以上説明したように、本発明により、ＳＩＭ機能に対するより動的で同時に安全なソフトウェアベースの解決策が与えられる。

図１は、ソフトウェアベースのｖＳＩＭ（ｖｉｒｔｕａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｆｙ ｍｏｄｕｌｅ）を使用することで、サービスを使用し、サブスクライバアイデンティティを判定するように構成された通信システムアーキテクチャの例を示す図である。 図２は、単一ユーザのモバイルトラステッドプラットフォーム（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ）のｖＳＩＭアーキテクチャの例を示す図である。 図３は、マルチユーザモバイルトラステッドプラットフォームのｖＳＩＭアーキテクチャ３００の例を示す図である。 図４は、初期のモバイルトラステッドプラットフォーム上でＴＳＳ−ＭＮＯをインストールする手順を示す図である。 図５は、ｖＳＩＭ信用証明書のサブスクライバ登録および配送の手順を示す図である。 図６は、ｖＳＩＭ信用証明書のサブスクライバ関連部分の安全な配送およびインストールの第２フェーズの手順の例を示す図である。 図７は、ソースプラットフォームからターゲットプラットフォームへｖＳＩＭ信用証明書またはその実行環境を移行する手順の例を示す図である。 図８は、通信サブスクライバのアクセスを可能にする第１手順を実行するように構成された通信システムの例を示す図である。 図９は、通信サブスクライバのアクセスを可能にする第２手順を実行するように構成された通信システムの例を示す図である。 図１０は、通信サブスクライバのアクセスを可能にする第２手順を実行するように構成された通信システムのもう１つの例を示す図である。 図１１Ａは、一般ネットワークインフラストラクチャについて通信サブスクライバのアクセスを可能にする第３手順を示す図である。 図１１Ｂは、一般ネットワークインフラストラクチャについて通信サブスクライバのアクセスを可能にする第３手順を示す図である。

以下で言及する時に、用語「無線送受信ユニット（ＷＴＲＵ）」は、ユーザ装置（ＵＥ）、移動局、固定のまたは可動のサブスクライバユニット、ポケットベル、セル電話機、携帯情報端末（ＰＤＡ）、コンピュータ、モバイルトラステッドプラットフォーム、または無線環境内で動作できるすべての他のタイプのユーザデバイスを含むが、これらに限定はされない。下で言及する時に、用語「基地局」は、Ｎｏｄｅ−Ｂ、サイトコントローラ、アクセスポイント（ＡＰ）、または無線環境内で動作できるすべての他のタイプのインターフェースするデバイスを含むが、これらに限定はされない。用語「信頼性（ｔｒｕｓｔｗｏｒｔｈｉｎｅｓｓ）」は、アプリケーションおよび／またはサービスの状態を記述する標準と考えられる。この状態は、アプリケーションおよび／またはサービスが、その保全性および正しい機能の表示を直接にまたは間接に提供できることを意味する。

図１に、ソフトウェアベースのｖＳＩＭ（ｖｉｒｔｕａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｆｙ ｍｏｄｕｌｅ）を使用することでサービスを使用し、サブスクライバアイデンティティを判定するように構成された通信システムアーキテクチャの例を示す。通信システム１００は、ユーザすなわちデバイスの所有者（持ち主）（ＤＯ）１１０、トラステッドモバイルプラットフォーム１２０、基地局１３０、ＭＮＯ（ネットワークサービスプロバイダ；移動体通信事業者）１４０、およびＰＯＳ（店舗、販売場所）１５０を含む。ＤＯ １１０は、ＰＯＳ １５０との登録および記録１５５のためにＰＯＳと通信する。ＰＯＳ １５０は、サブスクライバ登録１６０を実行するためにＭＮＯ １４０と通信する。ＭＮＯ １４０は、ｖＳＩＭ信用証明書１６５を配送するためにトラステッドモバイルプラットフォームと通信する。ＤＯ １１０は、ユーザを認証する１７０ためにトラステッドモバイルプラットフォーム １２０に情報を提供する。その後、トラステッドモバイルプラットフォームは、サブスクライバ認証１７５を基地局１３０に送信する。その後、基地局１３０は、ユーザ認証情報を検証するためにＭＮＯ １４０と通信する。

一般に、図１のｖＳＩＭアーキテクチャは、永久的に割り当てられたトラステッドアンカ（ｔｒｕｓｔｅｄ ａｎｃｈｏｒ；信頼アンカ）に基づき、複数の別々のトラステッド実行環境またはサブシステムをサポートする、トラステッドオペレーティングシステムによって保護される。図示されているように、１つの実行環境が、特定の利害関係者に割り当てられ、図示されたものを超える追加の利害関係者が、存在することが可能である。

図１に示されたアーキテクチャは、４つの重要なエンティティを考慮に入れている。このシナリオ（筋書き）では、ＤＯ／Ｕは、モバイル通信ネットワークおよびそこで提供されるサービス（たとえば、ＧＳＭ、ＵＭＴＳ電話、データサービス、または特殊化されたロケーションベースのサービス）を使用するために、ＭＮＯとの長期的関係を確立することを意図している。

物理的に存在するＳＩＭカードを使用する代わりに、ＭＮＯは、ＭＴＰ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ）にソフトウェアベースのアクセス認可信用証明書またはｖＳＩＭ信用証明書を提供する。ｖＳＩＭ信用証明書は、サブスクライバ関連部分およびユーザ関連部分からなる。登録されたデバイスユーザが、最初に通信ネットワークによって認可されなければならなくなるたびに、そのユーザは、まず、ｖＳＩＭ信用証明書のユーザ関連部分を介してｖＳＩＭサービスについて認証される。通信関係の過程において、このサービスは、ｖＳＩＭ信用証明書のサブスクライバ関連部分をネットワーク認証に使用する。

図２に、単一ユーザのＭＴＰ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ）２００のｖＳＩＭアーキテクチャの例を示す。モバイルトラステッドプラットフォーム ２００は、３つの別々のＴＳＳ（トラステッドサブシステム）２０２、２０４、２０６を含む。第１のＴＳＳ ２０２は、ＤＭ（デバイス製造メーカー）に割り当てられる。第２のＴＳＳ ２０４は、ＭＮＯ（ネットワークサービスプロバイダ）に割り当てられる。第３のトラステッドＴＳＳ ２０６は、ＤＯ ２０６に割り当てられる。ＴＳＳ−ＤＯを、ユーザに割り当てることもできる（ＴＳＳ−Ｕ）ことに留意されたい。３つのＴＳＳ ２０２、２０４、２０６のそれぞれが、標準サービスユニット２１０ａ、２１０ｂ、２１０ｃ、トラステッドサービスユニット２１２ａ、２１２ｂ、２１２ｃ、およびトラステッドリソースユニット２１４ａ、２１４ｂ、２１４ｃを含む。ＭＮＯトラステッドＴＳＳ ２０４は、ＭＮＯに関係するＳＩＭ機能を実行するｖＳＩＭコアユニット２２０をも含む。ＤＯトラステッドＴＳＳ ２０６は、ＤＯに関係するＳＩＭ機能を実行するｖＳＩＭ管理ユニット２２２をも含む。ｖＳＩＭコアユニット２２０およびｖＳＩＭ管理ユニット２２２は、トラステッドリンク２２４を介して通信し、組み合わさって、少なくとも従来のＵＳＩＭ（ｕｎｉｖｅｒｓａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ：全域契約者情報記録モジュール）の機能を実行する。

図３に、マルチユーザＭＴＰ３００のｖＳＩＭアーキテクチャの例を示す。モバイルトラステッドプラットフォーム ３００は、４つの別々のＴＳＳ ３０２、３０４、３０６、および３０８を含む。第１のＴＳＳ ３０２は、ＤＭ（デバイス製造メーカー）に割り当てられる。第２のトラステッドＴＳＳ ３０４は、ネットワークサービスプロバイダに割り当てられる。第３のＴＳＳ ３０６は、第１ユーザに割り当てられる。第４のＴＳＳ ３０８は、デバイス所有者３０８に割り当てられる。４つのＴＳＳ ３０２、３０４、３０６、および３０８のそれぞれは、標準サービス（ｎｏｒｍａｌ ｓｅｒｖｉｃｅｓ）ユニット３１０ａ、３１０ｂ、３１０ｃ、３１０ｄ、トラステッドサービスユニット３１２ａ、３１２ｂ、３１２ｃ、およびリソースユニット３１４ａ、３１４ｂ、３１４ｃを含む。ＭＮＯ ＴＳＳ ３０４は、ＭＮＯに関係するＳＩＭ機能を実行するｖＳＩＭコアユニット３２０をも含む。ユーザＴＳＳ ３０６／３０８は、ローカルユーザの管理および認証に関係する機能を実行するｖＳＩＭサブスクライバ管理サービス３２２／３２３をも含む。より具体的に言うと、このサービスは、ローカルユーザのアイデンティティに関して認証が与えられるように、ｖＳＩＭコアサービス３２０に認証オラクル（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｏｒａｃｌｅ）を提供する。ｖＳＩＭコアユニット３２０およびｖＳＩＭ管理ユニット３２２は、トラステッドリンク３２４を介して通信し、それらが協働して、少なくとも従来のＵＳＩＭ（ｕｎｉｖｅｒｓａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）の機能を実行する。

一般に、ＭＴＰ ２００および３００は、複数の保護された別々の実行環境をサポートする。各環境は、利害関係者（ｓｔａｋｅｈｏｌｄｅｒ）に関連するエリアを表す。ＭＴＰ ２００および３００は、従来のスマートカードベースのＳＩＭカードおよびその機能を置換するｖＳＩＭサービスを実施するように構成されている。一般に、ｖＳＩＭサービスは、（少なくとも）図２に示された３つの異なる実行環境に拡張されるが、例によって図３に示された、多数の他の実行環境をサポートするように拡張することもできる。

図２および図３に示されているように、複数の異なるｓｉｇｍａ（利害関係者）すなわち、ＤＭ（デバイス製造メーカー）、ネットワークアクセスおよびサービスプロバイダ（モバイルネットワークオペレータ、ＭＮＯ）、ＤＯ（デバイス所有者）、およびＵ（ユーザ）が考慮される。トラステッドサブシステムＴＳＳ−ｓｉｇｍａは、ＴＥ−ｓｉｇｍａ（トラステッド実行環境、セキュリティ実施環境）およびＴＭ（交換不能セキュリティモジュール、トラステッドモジュール）またはＲＯ（遠隔の持ち主）もしくはｓｉｇｍａ（利害関係者）に関連するＴＭ−ｓｉｇｍａ（セキュリティモジュールのエンティティ）を含む論理ユニットとして構成される。ＴＳＳ−ｓｉｇｍａは、必ずすべての所与のデータに署名し、暗号化するように構成される。ＴＳＳ−ｓｉｇｍａは、トラステッドサービスＲＴＶ−ｓｉｇｍａへのアクセスを有する。このサービスは、たとえば、基準データに基づく定義されたシステム状態の検証の責任を負う。本明細書で提案される類似するアーキテクチャのさまざまな他のトラステッドサブシステムを、以下で例として説明する。これは、利害関係者ＤＭ、ＭＮＯ、ＤＯ、およびＵのサブシステムＴＳＳ−ＤＭ ２０２および３０２、ＴＳＳ−ＭＮＯ ２０４および３０４、ＴＳＳ−ＤＯ ２０６および３０６、ならびにＴＳＳ−Ｕ ２０６および３０８を含む。

ＴＳＳ−ＤＭ ２０２および３０２は、そのインストールされたハードウェアコンポーネントと一緒にデバイスの保全性（ｉｎｔｅｇｒｉｔｙ）、構成、およびインストールの責任を負う。ＴＳＳ−ＤＭ ２０２および３０２は、デバイスのすべてのセキュリティに敏感なリソースを提供する。ＴＳＳ−ＤＭ ２０２および３０２は、一般に、すべての内部通信および外部通信を制御し、通信チャネルを保護する。その結果、ＴＳＳ−ｓｉｇｍａのすべてのプロトコルメッセージは、その宛先ポイントのＴＳＳ−ＤＭ ２０２および３０２の通信サービスによって伝送される。

あるプラットフォームのすべてのサブスクリプション依存およびサブスクライバ（電話加入者、契約者）関連のネットワークプロバイダサービスは、ＴＳＳ−ＭＮＯ ２０４および３０４に割り当てられる。このサブシステムは、ｖＳＩＭ信用証明書のサブスクライバ関連部分を管理し、保護する責任を負い、サブスクライバのクライアントサイドネットワーク認証を実行する。このサブシステムは、このためにｖＳＩＭ−ＣＯＲＥ（ｖＳＩＭコアサービス）を提供する。ｖＳＩＭ−ＣＯＲＥ ２２０および３２０は、従来のＳＩＭの本質的機能（サブスクライバ認証）を置換するように構成されるが、他の認証機能にも対処することができる。用語「トラステッドサブシステムＴＳＳ−ＭＮＯ」は、必要なｖＳＩＭ−ＣＯＲＥサービス２２０および３２０を提供する完全装備のＴＳＳ−ＭＮＯと同義である。ＴＳＳ−ＤＭおよびＴＳＳ−ＭＮＯの組合せも可能である。ｖＳＩＭコアサービスが、サブスクライバデータの安全な格納および使用ならびにＭＮＯとのサブスクライバ認証の責任を負うことにも留意されたい。

ＴＳＳ−Ｕ ２０６および３０６は、すべてのユーザ関連情報およびプライベート情報、具体的にはユーザの関連するアクセス認可信用証明書（ｖＳＩＭ信用証明書のユーザ関連部分）を保護する。ＴＳＳ−Ｕ ２０６および３０６は、ｖＳＩＭの管理サービス（ｖＳＩＭ−ＭＧＭＴ）２２２のインスタンスを作成する。このサービスは、ユーザ情報の管理およびローカルユーザに関する認証応答の計算の責任を負う。サービスｖＳＩＭ−ＭＧＭＴは、サービスｖＳＩＭ−ＣＯＲＥに内部認証オラクルを与える。したがって、ｖＳＩＭ−ＭＧＭＴは、認証照会の後に、ローカルユーザのアイデンティティの証明を提供することができる。このサービスは、ｖＳＩＭのユーザ管理、具体的にはデバイスユーザのアドミニストレーションおよび管理の責任を負う。ｖＳＩＭ内の所有者管理サービスｖＳＩＭ−ＯｗｎＭＧＭＴは、機能的にｖＳＩＭ−ＭＧＭＴにイメージ化される。すべてのＴＳＳ−Ｕが、ディジタル署名のために所期のプラットフォームユーザＵによってのみアクセスでき使用できる適切な暗号法鍵を生成できることにも留意されたい。

ＴＳＳ−ＤＯ ２０６および３０８は、ｖＳＩＭの持ち主の管理サービス（ｖＳＩＭ−ＯｗｎＭｇｍｔ）のインスタンスを作成する。このサービスは、所有者情報を管理し、ローカルユーザまたはサービスプロバイダに関するものなどの事業管理（ａｄｍｉｎｉｓｔｒａｔｉｖｅ ｍａｎａｇｅｍｅｎｔ）の責任を負う。ＴＳＳ−ＤＯおよびＴＳＳ−Ｕを、単一ユーザシステムについては図２に示されているように１つに組み合わせることもできる。

一般に、ＭＴＰは、ハードウェアプラットフォームに永久的に関連付けられた交換不能なセキュリティモジュール（トラステッドモジュール、ＴＭ）を有するモバイルプラットフォームである。検討中のｖＳＩアーキテクチャの文脈では、ＭＴＰは、従来のＳＩＭカードなどのサブスクライバ認証用の従来のセキュリティトークンを義務的に備えてはいない。ＭＴＰは、トラステッドオペレーティングシステムを動作させる。トラステッドソフトウェアレイヤ（ｔｒｕｓｔｅｄ ｓｏｆｔｗａｒｅ ｌａｙｅｒ；信頼されたソフトウェア層）は、保護され隔離された実行およびメモリ機能を有する複数の別々のトラステッドサブシステム（ＴＳＳ＿ＳＩＧＭＡ）をサポートする。

各トラステッドサブシステム（ＴＳＳ＿ＳＩＧＭＡ）は、利害関係者のクリティカルなセキュリティ機能に使用される。トラステッドサブシステムは、セキュリティモジュールのトラステッドエンティティ（ＴＭ−ＳＩＧＭＡ）および関連するトラステッド実行環境（トラステッドエンジン、ＴＥ＿ＳＩＧＭＡ）、ならびにトラステッドサービス（ＴＳ＿ＳＩＧＭＡ）からなる。遠隔所有者ＤＭ、ＭＮＯ、Ｕの代わりに、少なくとも、３つのトラステッドサブシステムＴＳＳ−ＤＭ、ＴＳＳ−ＭＮＯ、ＴＳＳ−Ｕが、ＭＴＰ上に存在する。手順を、単一ユーザシステムについて説明する。デバイス所有者ＤＯおよびＴＳＳ−ＤＯの機能は、ＵまたはＴＳＳ−Ｕについてイメージ化される。

ＭＮＯが、公開鍵インフラストラクチャの必要な機能を直接にまたは間接に提供することに留意されたい。ＭＮＯは、証明機関ＣＡによって発行された証明書Ｃｅｒｔ−ＭＮＯを所有する。この証明書は、ＭＮＯのアイデンティティを公開鍵Ｋ−ｐｕｂ−ＭＮＯにリンクし、この公開鍵Ｋ−ｐｕｂ−ＭＮＯは、ディジタル署名をチェックするのに必要である。この証明書は、ＭＴＰおよびすべての組込みサービスから使用可能である。

以下で説明する手順が、例のみのために単一ユーザシステムを検討することに留意されたい。その結果、デバイス所有者ＤＯは、ユーザＵと同等にされる。図３に示されているように、別々のＴＳＳ−ＤＯおよびＴＳＳ−Ｕを有する複数ユーザシステムでのサブスクライバ認証の方法は、類似する形で実行され、本願の範囲内にあるはずである。他のマルチユーザシナリオ、たとえば（１）１つのＴＳＳ−Ｕおよび複数のＴＳＳ−ＭＮＯ、（２）１つのＴＳＳ−ＭＮＯおよび複数のＴＳＳ−Ｕ、ならびに（３）複数のＴＳＳ−Ｕおよび複数のＴＳＳ−ＭＮＯが可能である。所有権制御（ｏｗｎｅｒｓｈｉｐ ｃｏｎｔｒｏｌ）の迂回を防ぐために、１つのＤＯだけが、すべてのそのような構成で許容可能であるとしている。さまざまなマルチユーザシナリオで、ｖＳＩＭ−ＭＧＭＴサービスは、ＤＯだけに適用されるので、すべてのユーザならびに複数のｖＳＩＭ−ＣＯＲＥサービス表明について立場を明らかにせず、これらと互換になるように構成される。したがって、単一ユーザについて、ｖＳＩＭ−ＭＧＭＴは、ｖＳＩＭ−ＭＧＭＴ−ＤＯ機能およびｖＳＩＭ−ＭＧＭＴ−Ｕ機能に分離される。これは、たとえばユーザのグループ（たとえば、家族）が同一のＭＮＯ加入を使用する場合、または、その一方で、単一のユーザが、状況に応じて、たとえば海外にいる時に、複数のＭＮＯ加入から選択したい時のアプリケーション（適用）のシナリオに有利である。これらを実施する好ましい方法は、ｖＳＩＭ−ＣＯＲＥおよび／またはｖＳＩＭ−ＭＧＭＴのいずれかが、めいめいのＴＳＳの間およびさまざまなｖＳＩＭ−ＭＧＭＴおよびｖＳＩＭ−ＯｗｎＭｇｍｔの間の所望の１対ｎ関係、ｎ対１関係、またはｎ対ｍ関係を確立するために、めいめいの他のＴＳＳ内のめいめいの他のサービスの認可秘密（ａｕｔｈｏｒｉｚａｔｉｏｎ ｓｅｃｒｅｔ）を含む保護されたデータベースを保持することである。

図２および図３の提案されるｖＳＩＭアーキテクチャは、従来のセキュリティトークンに基づくサブスクライバ認証用の従来のアーキテクチャと同等のセキュリティ特性を仮定する。具体的に言うと、これらのアーキテクチャは、保護されたストレージ機能、別々の改竄保護された実行環境、およびユーザの認証を引き受ける。ｖＳＩＭプラットフォームは、認可される対象だけがｖＳＩＭ信用証明書の保護されたデータにアクセスし、またはこれを操作することができることをも保証しなければならない。これは、データが、ｖＳＩＭ実行環境へまたは他のトラステッドサービスへ移動中であるか、ＭＴＰの揮発性メモリまたは不揮発性メモリに格納されているか、実行環境内で実行されまたは使用されるか、認可された対象によってさまざまなトラステッド環境の間で転送される間に、特に重要である。これは、セキュリティに敏感なデータを破壊も変更もできず、アクセス制御機構を開始することもできない、攻撃者の特徴を含む。このシステムは、セキュリティに敏感なデータの消失および脱出をも防ぎ、すべての必要なサービスが使用可能であり、機能することを保証しなければならない。具体的に言うと、ｖＳＩＭアーキテクチャは、認可された対象が適切な（ローカルまたは遠隔の）所有者を介してのみセキュリティに敏感なサービスにアクセスできることを保証しなければならない。

図４に、ＭＮＯ ４０８と通信するＴＳＳ−ＤＭ（デバイス製造メーカー用のＴＳＳ）４０４およびＴＳＳ−Ｕ（ユーザ用のＴＳＳ）４０２を有する初期モバイルトラステッドプラットフォーム ４０３上でＭＮＯ−ＴＳＳ ４０６をインストールする手順４００を示す。用語ＴＳＳ−ＭＮＯが、この手順によって確立されるトラステッドサブシステムとこの手順の終りにＴＳＳ−ＭＮＯになるＴＥ−ＭＮＯ（ＴＥ（トラステッド実行環境）ＭＮＯ）との両方を指すのに使用されることに留意されたい。ＲＯ（遠隔所有者）による占有は、遠隔所有者または利害関係者とＭＴＰとの間の信頼の基礎的で基本的な関係を確立する。この手順は、空のまたは初期の実行環境が存在することを必要とする。手順の第１部分４１０は、空の実行環境の準備専用であり、第２部分４１２は、新たに作成されるＴＥ（トラステッドエンジン）の遠隔所有権獲得専用である。ＴＳＳ＊−ＭＮＯ（初期ＴＳＳ−ＭＮＯ）は、基本機能性および／または複数のトラステッドサービスを有するＴＥ＊−ＭＮＯ（初期標準実行環境）からなる。サブシステムＴＳＳ＊−ＭＮＯが、ＭＮＯにその手の付けられていない構成、構造、およびそのセキュリティポリシに関する適合の証明を与えることができる時には、サブシステムＴＳＳ＊−ＭＮＯは、ＭＮＯによって証明される。

手順４００の前処理部分４１０は、４２０で、ＴＳＳ−Ｕ ４０２がＴＳＳ−ＭＮＯを確立する要求をＴＳＳ−ＤＭ ４０４に送信する時に開始される。次に、ＴＳＳ−ＤＭ ４０４は、４２２で、オリジナル実行環境をインストールする。次に、ＴＳＳ−ＤＭ ４０４は、４２４で、初期セットアップシーケンスを新たに作成されたＴＥ＊−ＭＮＯに送信する。４２６で、「空の」実行環境ＴＥ＊−ＭＮＯが確立され、セキュリティモジュールＴＭ−ＭＮＯ ４０６の新しいエンティティが、アクティブ化されるか作成される。さらに、初期実行環境ＴＥ＊−ＭＮＯが、確立され、準備される。具体的に言うと、エンドースメント鍵対（ｅｎｄｏｒｓｅｍｅｎｔ ｋｅｙ ｐａｉｒ）ＥＫ＊−ＴＳＳ−ＭＮＯが、対応する保証された証書（ｅｎｄｏｒｓｅｍｅｎｔ ｃｅｒｔｉｆｉｃａｔｅ）Ｃｅｒｔ−ＴＳＳ−ＭＮＯと一緒に、ＴＥ＊ＭＮＯ内で作成される。ＴＳＳ−ＭＮＯ ４０６は、４２８で、状態メッセージをＴＳＳ−ＤＭ ４０４に送り返す。

手順４００の遠隔所有権獲得部分４１２は、４３０で、ＴＳＳ−ＤＭ ４０４がＭＮＯ（遠隔所有者）による占有の要求メッセージをＭＮＯ ４０８に送信する時に開始される。次に、ＭＮＯ ４０８は、４３２で、トラステッドモバイルプラットフォーム４０１および実行環境ＴＳ−ＭＮＯ ４０６の検証を実行する。次に、ＭＮＯ ４０８は、４３４で、状態メッセージをＴＳＳ−ＤＭ ４０４に送信する。次に、ＴＳＳ−ＤＭ ４０４は、４３６で、証明書ＣＥＲＴ＿ＭＮＯおよび追加情報をＭＮＯ ４０８に送信する。次に、ＭＮＯ ４０８は、４３８で、証明書ＣＥＲＴ＿ＭＮＯをチェックし、署名し、構成およびセキュリティポリシをセットアップする。ＭＮＯ ４０８は、４４０で、状態メッセージをＴＳＳ−ＤＭ ４０４に送信する。次に、ＴＳＳ−ＤＭ ４０４は、実行環境ＴＳＳ−ＭＮＯ ４０６の完成をＴＳＳ−ＭＮＯ ４０６に送信する。次に、ＴＳＳ−ＭＮＯは、４４４で、ＣＥＲＴ＿ＭＮＯをインストールし、最終セットアップおよびインストール手順を実行することによって初期セットアップを完了する。その後、ＴＳＳ−ＭＮＯ ４０６は、４４６で、状態メッセージをＴＳＳ−ＤＭ ４０４に送り返す。ＴＳＳ−ＤＭ ４０４は、４４８で、状態メッセージをＴＳＳ−ＤＯ ４０２に転送する。ＴＳＳ−ＤＭ ４０４は、４５０で、状態メッセージをＭＮＯ ４０８にも送信する。

図４は、遠隔所有権獲得手順の特定の実施態様を説明するものであるが、次の説明は、図４の手順に類似する終点を有する、より一般的な手順を説明する。ＭＴＰのＤＯ（デバイス所有者）は、ユーザＵまたはデバイス所有者ＤＯが任意の所与のＭＮＯを制限なしに自由に選択できるようにするために、特定のＭＮＯによって事前に割り当てられず、初期化されていない、携帯電話機などの「空の」通信端末を購入できなければならない。図４の手順は、遠隔所有者によってＴＳＳ−ＭＮＯの占有を実行し、ＭＮＯによってｖＳＩＭ実行環境の確立を完成するのに使用される。この方法を、任意の所与の遠隔所有者に直接に転送することができ、この方法が、ＭＮＯに制限されないことに留意されたい。

次に、ＴＥ＊−ＭＮＯは、その現在の状態を認証する。認証は、遠隔所有者ＭＮＯのＲＩＭ（基準値）および対応する証明書を使用して、ＴＳＳ−ＤＭのローカルベリファイヤ（検証者）ＲＴＶ−ＤＭによって実行することができる。ＴＥ＊−ＭＮＯ（初期状態のトラステッドエンジン）に対応するＲＩＭが、必ずしも特定のＭＮＯに関連付けられない場合があり、初期基本機能性を超える構成を有しない場合があることに留意されたい。一致するＲＩＭおよび／または対応するＲＩＭ証明書が実行環境について入手可能ではない場合には、認証を、外部の（受け入れられた）検証エンティティを使用して実行することができる。認証ＡＴＴＥＳＴ（Ｓ_i）は、ＲＴＶ署名アイデンティティ（ＲＴＶＡＩ）によって署名される。
ＴＥ^* _MNO→ＭＮＯ ： ＡＴＴＥＳＴ（Ｓ_i） （式１）

ＴＥ＊−ＭＮＯは、対称セッション鍵Ｋｓを生成し、これを使用して、エンドースメント鍵ＥＫ＊−ＴＳＳ−ＭＮＯの公開部分、対応する証明書Ｃｅｒｔ−ＴＳＳ＊−ＭＮＯ、認証データ、および所期の目的に関する情報を暗号化する。次に、ＴＥ＊−ＭＮＯは、セッション鍵Ｋｓを公開鍵Ｋ−ｐｕｂ−ＭＮＯと一緒に暗号化し、両方のメッセージをＭＮＯに送信する。一般性を失わずに、ＴＥ＊−ＭＮＯは、エンドースメント鍵ＥＫ＊−ＴＳＳ−ＭＮＯおよび対応する証明書Ｃｅｒｔ−ＴＳＳ＊−ＭＮＯ、証明データ、ならびに所期の目的に関する情報ではなく、認証アイデンティティ鍵ＡＩＫ＊−ＴＳＳ−ＭＮＯを使用することができる。

この鍵Ｋ−ｐｕｂ−ＭＮＯが、公に入手可能であるか、デバイス製造メーカーによってプリインストールされるかのいずれかであると仮定する。

認証（式１）、ＥＫ＊−ＴＳＳ−ＭＮＯ、およびその証明書、ならびにそれを暗号化するセッション鍵Ｋｓ（式２）を、別々ではあるが同一セッション内で（すなわち、同一のセッションナンスによって区切られて）送信することができる。代替案では、送信を、同一のセッション鍵Ｋｓを使用して一回で行うことができ、したがって、この場合には、

である。

ＭＮＯがメッセージを受信した後に、それらのメッセージは、非対称鍵Ｋ−ｐｕｂ−ＭＮＯの秘密部分を使用して暗号化解除される。

後続ステップでは、ＭＮＯは、証明データを検証し、ＴＳＳ＊−ＭＮＯの所期の目的をチェックする。実行環境のデータおよびデバイス証明が有効であり、所期の目的が受け入れられる場合には、ＭＮＯは、個々のセキュリティポリシＳＰ−ＭＮＯを作成する。ＭＮＯは、Ｃｅｒｔ−ＴＳＳ−ＭＮＯに署名し、「完成した」ＴＳＳ−ＭＮＯのＲＩＭ値およびＲＩＭ証明書を生成し、この「完成した」ＴＳＳ−ＭＮＯは、特定のサービスプロバイダと共に動作するように構成される。これらは、ＴＳＳ−ＭＮＯのローカル検証に必要である。

ＭＮＯは、初期構成ＳＣ−ＴＳＳ−ＭＮＯをも生成する。これは、実行環境を個別化するのに、または所期の目的および特定のセキュリティポリシに関して実行環境を完成させるのに使用される。個別化は、一般に、適当な機能性を使用可能にするために当初には存在しないソフトウェアを含む。ＲＩＭおよびＲＩＭ証明書は、この初期構成を反映するために生成される。次のステップでは、ＭＮＯは、ＥＫ−ｐｕｂ−ＴＳＳ−ＭＮＯ（鍵の公開部分）を使用してメッセージを暗号化し、このパケットをＴＥ＊−ＭＮＯに送信し、この送信は、具体的には、ＴＳＳ−ＤＭによって提供される基本ネットワーク接続を介して実行することができる。ＳＰ−ＴＳＳ−ＭＮＯおよびＳＣ−ＴＳＳ−ＭＮＯがＭＮＯ固有であり、ＳＰ−ＴＳＳ−ＭＮＯおよびＳＣ−ＴＳＳ−ＭＮＯに対応する、ＴＳＳ−ＭＮＯの期待される「完成後」状態が、新しいＲＩＭ証明書によって定義される必要があることに留意されたい。

実行環境ＴＥ＊−ＭＮＯは、受信したパケットを暗号化解除し、これをＴＳＳ−ＭＮＯ内にインストールする。最後に、確立は、構成ＳＣ−ＴＳＳ−ＭＮＯに基づいて完了する。これは、具体的には、まだインストールされておらず、ＳＣ−ＴＳＳ−ＭＮＯによって要求されるすべてのサービスが、ＴＳＳ−ＭＮＯ内に導入されるかインストールされることを意味する。

ｖＳＩＭ信用証明書のサブスクライバ登録および配送の手順を、図５に示し、以下で説明する。ｖＳＩＭサービスを利用するために、アクセス認可信用証明書（ｖＳＩＭ信用証明書）が、ＭＴＰ ２００から使用可能でなければならない。このｖＳＩＭ信用証明書は、（１）ＭＮＯ ５０６によって生成され、ＭＮＯまたはＤＭによって事前にインストールされるか、（２）ｖＳＩＭ信用証明書をインストールするのに使用される当初には秘密の情報に基づくか、（３）所有権獲得プロセス中に生成される（ＭＮＯ ５０６およびユーザＵ ５０２によって）かのいずれかである。

ｖＳＩＭアーキテクチャのサービスは、トラステッドソフトウェアアプリケーションとして実施されるので、ｖＳＩＭ信用証明書のめいめいのサブスクライバ関連部分は、ＭＮＯによってｖＳＩＭサービスに安全に送信されなければならない。従来のＳＩＭベースのシステムでは、サブスクライバは、登録の直後にセキュリティトークン（スマートカード／ＳＩＭカード）を受け取る。ｖＳＩＭ信用証明書とは異なって、このセキュリティトークンは、物理的に存在し、めいめいのＰＯＳ用のプリインストールされた鍵またはＳＩＭ信用証明書と共に配送される。

予備フェーズ（図示せず）で、ＭＴＰ ２００は、証明された初期スタートアップ手順を実行済みであり、ＯＳおよびそのトラステッドユニットの特定のトラステッドソフトウェアレイヤをロード済みである。これは、トラステッド実行環境を、その組込みサービスｖＳＩＭ−ＣＯＲＥおよびｖＳＩＭ−ＭＧＭＴと一緒に含む。プラットフォームの信頼性は、チェック済みであり、インストールされたハードウェアおよび動作中のソフトウェアは、信頼され、受け入れられ、もっともらしい状態および構成である。したがって、プラットフォームは、ｖＳＩＭ機能をインストールされて「セキュアブートを達成した」と説明される状態にある。さらに、要求時に、プラットフォームは、認可されたエンティティを介してこの状態を報告し、状態を証明することもできる。

ＰＯＳ ５０４は、ＭＮＯ ５０６に、任意の所与の個数の以前に生成された登録チケットＴｉｃｋｅｔ−ｉを注文する。
ＰＯＳ→ＭＮＯ ： チケット要求（すなわち、注文） （式５）

ＩＭＳＩ−ｉは、ｉｎｔｅｒｎａｔｉｏｎａｌ ｍｏｂｉｌｅ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙを表す。あるいは、これを、認可されたセンタによって割り当てられるランダムだが曖昧ではないＩＤ（識別子）またはサービスが通信ネットワークを介して提供されるサービスサブスクライバのＩＤを意味するＩＤとすることができる。ＩＭＳＩ−ｉがＩＭＳＩである場合には、そのようなチケットを、その一意インデックスによって区別することができる。

用語ＲＡＮＤ−ｉは、ｒａｎｄｏｍ ｖａｌｕｅ（乱数値）を表す。この値は、プロトコル中にＴＳＳ−ＭＮＯ ２０４のアイデンティティをチェックするために必要である。ＡＵＴＨ−ｉの使用によって、ＭＴＰ ２００は、ｔｉｃｋｅｔ−ｉの保全性および真正性をチェックすることができる。ＡＵＴＨ−ｉは、ＭＮＯ ５０６の秘密鍵によって署名されたＭＮＯ ５０６の署名である。ＡＵＴＨ−ｉを暗号化解除することによって、ＰＯＳ ５０４は、Ｔｉｃｋｅｔ−ｉを創作したＭＮＯ ５０６を識別することができる。ＭＮＯ ５０６によるＰＯＳ ５０４の認証は、本明細書で説明されるプロトコルでは考慮されないが、チケットを占有し分配するのに十分に信頼できると考えられる。ＭＮＯ ５０６は、複数のチケットをＰＯＳ ５０４に送信する。登録チケットは、３つ組｛ＩＭＳＩｉ，ＲＡＮＤｉ，ＡＵＴＨｉ｝からなる。
ＭＮＯ→ＰＯＳ ： Ｔｉｃｋｅｔ_i ：＝ ｛ＩＭＳＩ_i，ＲＡＮＤ_i，ＡＵＴＨ_i｝ （式５ｂ）

それ自体の信頼のルートを有する複数のＴＥ＊−ＭＮＯ（初期のトラステッドサブシステム）がＤＭによってインストールされる場合には、ＭＮＯ ５０６が、これらのサブシステムの所有権を別々に入手し、これによってそれぞれを別個のデバイスとみなすことが可能である。このシナリオでは、複数のユーザが、これらの別々のサブシステムを介して１対１の基礎で登録することができる。

図４で説明した登録手順が、図５の登録手順ならびに本願で説明する後続のプロトコルとは別個であることにも留意されたい。したがって、図５の手順は、特定の所有権獲得手順の使用を必要としない。

ユーザ登録およびｖＳＩＭ信用証明書ロールアウト手順は、２つのフェーズに分離される。次の手順は、図５に示され、第１フェーズを説明するものである。ユーザ登録およびＭＮＯ ５０６のサブスクライバ関連サービスに関する登録は、第１フェーズで指定される。

ユーザは、ＴＳＳ−Ｕ／ＤＯ ２０６によって生成される、ＴＳＳ−Ｕ／ＤＯ ２０６のローカルユーザの新しいアイデンティティ信用証明書（ｖＳＩＭ信用証明書のユーザ関連部分）を要求することによって、このプロトコルを開始する。このために、ローカルユーザは、５５０で、一意アイデンティティコードＩＤ−Ｕ、彼の個人登録データＲＥＧＤＡＴＡ−Ｕ、および秘密認可パスワードＣＨＶ−ＵをトラステッドサービスｖＳＩＭ−ＭＧＭＴにサブミットする。一意ＩＤ−Ｕの使用は、同一のＵ（ユーザ）５０２がｖＳＩＭユーザ登録目的で同一のＭＮＯ ５０６へ同一のプラットフォームを登録するのに異なるＩＤ−Ｕを使用できる可能性をなくす。式６に示された情報は、ＰＯＳ ５０４で創作され、その一部はユーザ５０２によって生成され（おそらくはＲＥＧＤＡＴＡおよびＣＨＶ−Ｕ）、一部（ＩＤ−Ｕ）はＰＯＳ ５０４自体によって生成される。
Ｕ→ｖＳＩＭ_MGMT ： ＩＤ_U，ＣＨＶ_U，ＲＥＧＤＡＴＡ_U （式６）

次に、ｖＳＩＭ−ＭＧＭＴは、５５２で、非対称署名鍵対Ｋ−Ｕを生成し、ユーザの関連情報のすべて（ＲＥＧＤＡＴＡ−Ｕ、Ｋ−Ｕの公開部分）を含む対応する証明書を生成する。次に、サービスｖＳＩＭ−ＭＧＭＴは、５５４で、Ｋ−Ｕの秘密部分によって署名された証明書ＣＥＲＴ−Ｕおよび認証をサービスｖＳＩＭ−ＥＣＯＲＥに送信する。トラステッド環境の範囲内で、セキュアリンクがｖＳＩＭ−ＭＧＭＴとｖＳＩＭ−ＣＯＲＥとの間で確立されると仮定する。
ｖＳＩＭ_MGMT→ｖＳＩＭ_CORE ： ＡＴＴＥＳＴ（Ｓ_i），ＣＥＲＴ_U （式７）

この点で、サービスｖＳＩＭ−ＭＧＭＴは、登録手順を開始し、サービスｖＳＩＭ−ＣＯＲＥのローカルベリファイヤ（ＲＴＶ−ＭＮＯ）に対してその現在の状態および構成を証明する。ＴＳＳ−ＭＮＯ ２０４は、基準データに基づいて、提供されたデータをチェックする。次に、ＴＳＳ−ＭＮＯ ２０４は、現在の実行環境の状態が有効で受け入れられる状態であるかどうかをチェックする。証明された非対称鍵対Ｋ−Ｕは、ステップ５５６で、現在の実行環境の認証がそれによって検証される手段として働く。ｖＳＩＭ−ＣＯＲＥは、デバイスの確実性（ｒｅｌｉａｂｉｌｉｔｙ）を判定するや否や、一意識別子ＰＩＤを生成し、この値をｖＳＩＭ−ＭＧＭＴに送信する５５８。
ｖＳＩＭ_CORE→ｖＳＩＭ_MGMT ： ＰＩＤ （式８）

ユーザは、５６０で、登録データＲＥＧＤＡＴＡ−Ｕ（たとえば、名前、住所、アカウンティング情報、個人識別番号）およびＰＩＤを、セキュアチャネルと考えられるものを介して（必要な場合には暗号化が実行される）ＰＯＳに送信する。サービスｖＳＩＭ−ＣＯＲＥは、ユーザＵ ５０２の登録手順を開始する。このために、ｖＳＩＭ−ＣＯＲＥは、それ自体の証明書および受信したユーザ証明書に署名する。次に、ｖＳＩＭ−ＣＯＲＥは、このパケットをＰＯＳ ５０４に送信する。
Ｕ→ＰＯＳ ： ＰＩＤ，ＲＥＧＤＡＴＡ_U （式９ａ）
ｖＳＩＭ_CORE→ＰＯＳ ： ＣＥＲＴ_{TSS_MNO}，ＣＥＲＴ_U （式９ｂ）

ＰＯＳ ５０４は、要求を受信した後に、５６４で、ｔｉｃｋｅｔ−ｉを選択し、これを鍵Ｋ−ｐｕｂ−ＴＳＳ−ＭＮＯ ２０４にバインドし、５６６で、これをＴＳＳ−ＭＮＯ ２０４に送り返す。ＰＩＤは、ユーザがチケットと共にそれによって一意に識別されるハンドルを提供する。また、ＰＯＳ ５０４は、ユーザをｖＳＩＭ−ＣＯＲＥによって行われている登録要求に関連付けるのにＰＩＤを使用することができる。この場合に、ＰＯＳ ５０４は、インターネットポータルなど、ＭＮＯによって公認される任意の所与の売り場（店舗）とすることができる。

ＰＯＳ ５０４は、ユーザＵならびにデバイスの信頼性を判定し終えるや否や、ＣＥＲＴ−ＵおよびＩＭＳＩ−ｉ（選択されたチケットの）をＲＥＧＤＡＴＡ−Ｕに追加する。次に、ＰＯＳ ５０４は、その署名鍵Ｋ−ＰＯＳの秘密部分を用いて、収集された情報に署名し、署名されたデータおよび署名を（オンラインまたはオフラインで）ＭＮＯに送信する５６８。ＰＯＳ ５０４は、オプションで、Ｋ−ＭＮＯの公開部分を使用して、データを暗号化することができる。
ＰＯＳ→ＭＮＯ ： ＩＭＳＩ_i，ＣＥＲＴ_U，ＲＥＧＤＡＴＡ_U
： ＳＩＧＮ_POS（ＩＭＳＩ_i，ＣＥＲＴ_U，ＲＥＧＤＡＴＡ_U）
（式１１）

ＭＮＯ ５０６は、データをチェックし、ＩＭＳＩ−ｉ、対称鍵Ｋｉ、および証明書ＣＥＲＴ−Ｕを使用して、ｖＳＩＭ信用証明書のサブスクライバ関連部分を生成する。次に、ＭＮＯ ５０６は、秘密署名鍵Ｋ−ＭＮＯを用いてこのバンドルに署名し、最後に、５７０で、その認証センタ内で署名されたｖＳＩＭ信用証明書およびめいめいのＮＯＮＣＥをアクティブ化する。

次に、ＭＴＰ ２００は、既存通信チャネルを介してＭＮＯ ５０６の使用可能な登録サービスを要求することができる。このサービスは、たとえば、ネットワーク遠隔通信サービスまたはインターネットサービスとして実施することができる。

上の、図５に示された登録プロセスの変形（図示せず）は、ＰＯＳの認証および可能な認証を含む。この変形は、ならず者ＰＯＳが他のおそらくは偽のＰＯＳと共謀することができるという、ＭＮＯおよびユーザへの脅威を軽減する。この変形は、ＭＮＯから受信したチケットの複数のコピーを他のＰＯＳに分配し、これらを多数のデバイスおよびユーザに分配し、これに関して料金を課すことができる。ＭＮＯは、この種類の詐欺を起点のＰＯＳまでトレースバックすることができるが、この攻撃は、それでも、異なる国のＰＯＳなどのいくつかの分散シナリオで成功する可能性がある。これを防ぐために、ＴＳＳ＿ＭＮＯは、ＰＯＳの信頼性を証明する情報を入手する必要がある。

前述の脅威を、次のように軽減することができる。登録チケットの注文の時に（式５）、ＰＯＳは、ＰＯＳによって署名された、同一のメッセージまたは別々のメッセージ内の、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐの遠隔認証プロトコルによって指定される、認証データＡＴＴＥＳＴ＿ＰＯＳを送信することによって、ＭＮＯに向かう遠隔認証をも実行する。ＰＯＳからＭＮＯへのチケット要求または注文メッセージは、今や、ＰＯＳ認証データを含まなければならない。
ＰＯＳ→ＭＮＯ ： チケット要求，ＡＴＴＥＳＴ＿ＰＯＳ （式５ｃ）

ＭＮＯが、トラステッドサードパーティから、ＰＯＳがその認証データに署名するのに使用した署名鍵の暗号化解除鍵およびその鍵の証明書を入手済みでなければならないことに留意されたい。チケット注文および認証メッセージは、どの場合でも、たとえば反射攻撃を防ぐために共通のナンスによって、１つのセッション内に制限されなければならない。次に、ＭＮＯは、チケット注文が信頼できる状態の既知のＰＯＳから発することを知る。これは、ＰＯＳが、ＰＯＳインフラストラクチャ内またはその外部の許可されない当事者によってアクセス可能ではない保護されたメモリ位置にチケットを保存することを必要とする。ＰＯＳにサブミットされたチケットは、ＭＮＯによって、ＰＯＳ署名鍵Ｔｒ−ＰＯＳおよび鍵のこのセットの信頼状態を示すディジタル証明書ＣＥＲＴ−Ｔｒ−ＰＯＳを増補される。次に、これらの鍵は、式１０に示されているように、ＴＳＳ−ＭＮＯへのメッセージに署名するのに、ＰＯＳによって使用される５６６。

ＴＳＳ−ＭＮＯとＰＯＳとの間の信頼レベルをさらに高めるために、メッセージ交換を、登録データを送信する前にチケット要求に含めることができる５６０（式９ａ〜ｃ）。すなわち、チケット要求を示す、ＴＳＳ−ＭＮＯの暗号化鍵の公開部分を含むＴＳＳ−ＭＮＯからの初期メッセージの受信時に、ＰＯＳは、後続通信用のセキュアチャネルを確立するために、ＴＳＳ−ＭＮＯの暗号化鍵の公開部分を用いて暗号化されたＣｅｒｔ−Ｔｒ−ＰＯＳおよびオプションで暗号化鍵を含む、Ｔｒ−ＰＯＳを用いて署名されたメッセージを送信する。ＴＳＳ−ＭＮＯは、Ｃｅｒｔ−Ｔｒ−ＰＯＳからＴｒ−ＰＯＳ公開鍵を抽出し、それを用いてこのデータパケットの署名を検証する。次に、ＴＳＳ−ＭＮＯは、Ｃｅｒｔ−Ｔｒ−ＰＯＳのＭＮＯ署名を検証する。次に、ＴＳＳ−ＭＮＯは、初期チケット要求に対する応答が、その信頼性がＭＮＯによって証明されるＰＯＳから発することを知る。次に、ＴＳＳ−ＭＮＯは、オプションで、存在する場合に暗号化鍵を暗号化解除する。ＰＯＳとデバイスとの間のすべての後続通信が、この鍵を用いて保護される。ＴＳＳ−ＭＮＯは、受信されたチケット５６６の証明書をチケット要求初期交換で受信された証明書と比較して、Ｃｅｒｔ−Ｔｒ−ＰＯＳによって知らされる信頼できる状態にあるＰＯＳによって入手されたチケットを受信することを保証することができる。

もう１つの実施形態では、ＰＯＳは、以前に信頼できると証明されてはいない。さらに、ＰＯＳは、ＭＮＯに対してそれ自体を認証することができない。したがって、ＰＯＳの信頼性は、保証されない。この実施形態は、ユーザプラットフォームとＭＮＯとの間での証明された非対称鍵対の確立に頼る。そのような鍵対は、遠隔所有権獲得プロトコル中に確立することができる。確立されたならば、その鍵対は、クリティカルデータを処理するためにＰＯＳの信頼性に頼ることを減らす機構を提供する。このセキュリティ構成変更を用いると、ＭＮＯは、ＴＳＳ−ＭＮＯの公開鍵を用いて暗号化され、Ｋ−ＭＮＯの秘密部分を使用して署名されたチケットをＰＯＳに送信する。

必要な秘密鍵を有するＴＳＳ−ＭＮＯだけがメッセージを暗号化解除できることを考慮すると、ＰＯＳによって管理される複数ＭＮＯシナリオが使用される。ＴＳＳ−ＭＮＯの鍵証明書は、ＰＯＳが、所与のユーザ用のチケットを送信したＭＮＯとの関連付けを行うことを可能にする。ＰＯＳは、この形で、複数のＭＮＯに関して関連付けを行うこともでき、したがって、チケットを受信するＴＳＳ−ＭＮＯがそれを暗号化解除できることを保証することができる。チケット情報をバインドするためのメッセージを、このプロセスに組み込むことができることに留意されたい。

成功の登録を仮定すると、ＴＳＳ−ＭＮＯは、暗号化解除されたチケットからＩＭＳＩを抽出し、これをＭＮＯの公開鍵（上で確立された鍵対）を用いて暗号化し、Ｋ−ｐｒｉｖ−ＴＳＳ−ＭＮＯを用いてこれに署名し、このメッセージをＰＯＳに送信する。署名検証の後に、ＰＯＳは、暗号化されたＩＭＳＩをユーザ証明書および登録データと一緒に、関連付けられたＭＮＯに渡す。信用証明書の最終的なロールアウトは、下で式１６および式１７で示すものと本質的に同一の形で実行される。

チケット情報の機密性は、潜在的に悪意のあるＰＯＳから保護される。チケットを、ユーザプラットフォームおよびＭＮＯのどちらに対しても悪用することはできない。チケットを、たとえば悪党のユーザまたはＰＯＳにリダイレクトすることもできない。ＲＥＧＤＡＴＡ_UおよびＣＥＲＴ_Uを含む他の情報は、ＰＯＳによってアクセス可能であり、したがって、可能なスプーフィング攻撃の対象である。しかし、この情報は、保全性保護され、したがって、そのような攻撃は、防がれる。

図６に、図２のモバイルトラステッドプラットフォーム ２００へのｖＳＩＭ信用証明書のサブスクライバ関連部分の安全な配送およびインストールの第２フェーズ（変形ではない基本モデルによる）の手順の例を示す。ｖＳＩＭ信用証明書のサブスクライバ関連部分を得るために、ユーザは、ＭＮＯ ６０４の登録サービスに申し込む。このために、ユーザＵ ６０２は、彼のＩＤ−Ｕおよび関連するパスワードＣＨＶ−ＵをサービスｖＳＩＭ−ＭＧＭＴにサブミットする。次に、ｖＳＩＭ−ＭＧＭＴは、６５０で、保護されたメモリから関連する鍵対Ｋｕ（ｖＳＩＭ信用証明書のユーザ関連部分）をロードする。
Ｕ→ｖＳＩＭ_MGMT ： ＩＤ_U，ＣＨＶ_U （式１２）

その後、ｖＳＩＭ−ＭＧＭＴは、６５２で、ロールアウト手順を初期化し、このために、要求をｖＳＩＭ−ＣＯＲＥに送信する。
ｖＳＩＭ_MGMT→ｖＳＩＭ_CORE ： ｉｎｉｔ＿ｒｏｌｌｏｕｔ＿ｖｓｉｍ （式１３）

要求メッセージが受信された後に、ｖＳＩＭ−ＣＯＲＥは、６５４で、めいめいのｔｉｃｋｅｔ_iを公開し、ｔｉｃｋｅｔ−ｉの真正性および保全性をチェックする。次に、ｖＳＩＭ−ＣＯＲＥは、ｔｉｃｋｅｔ−ｉから値ＮＯＮＣＥ−Ｕを抽出し、Ｕ ６０２に、ｖＳＩＭ−ＭＧＭＴを介して彼のアイデンティティを検証するように要求する。
ｖＳＩＭ_CORE→ｖＳＩＭ_MGMT ： ＮＯＮＣＥ_U （式１４）

サービスｖＳＩＭ−ＭＧＭＴは、ＩＤ−ＵおよびＲＥＧＤＡＴＡ_Uと一緒にＮＯＮＣＥ−Ｕに署名する。このバンドルは、６５５でｖＳＩＭ−ＣＯＲＥに送り返される。

サービスｖＳＩＭ−ＣＯＲＥは、メッセージを受信し終えるや否や、ｖＳＩＭ信用証明書配送要求を生成し、これをＭＮＯの割り当てられた登録サービスにサブミットする６５６。このために、サービスｖＳＩＭ−ＣＯＲＥは、ｔｉｃｋｅｔ−ｉからＮＯＮＣＥ−ＭＮＯを抽出し、ＩＭＳＩ−ｉと一緒にこれに署名する。次に、ｖＳＩＭ−ＣＯＲＥは、その生成された署名および受信されたユーザ署名を、ある検疫チャネルまたはインターネットを介してＭＮＯに送信する６５６。

ｖＳＩＭ ＣＯＲＥからの要求が受信された後に、ＭＮＯ ６０４は、６５８で、メッセージ、ＣＥＲＴ−Ｕ、およびＣｅｒｔ−ＴＳＳ−ＭＮＯを（受信されたデータに基づく、ローカルメモリから、またはＰＯＳ（図示せず）によって提供される証明書に基づくのいずれかの検証によって）チェックする。情報が無効であるか拒絶される場合には、ＭＮＯ ６０４は、エラーメッセージを応答し、このプロトコルを打ち切る。両方ともチケットから抽出されるＮＯＮＣＥ_MNOおよびＮＯＮＣＥ_Uは、それぞれＭＮＯ ６０４およびＵ ６０２へのチャレンジである。ＲＥＧＤＡＴＡ_Uは、ＩＤ_Uとの相関を可能にするために送信される。これらは、新鮮さのためには使用されず、新鮮さは、さまざまな形で、たとえば、メッセージに適切な粒度のタイムスタンプを追加することによって、達成することができる。

もう１つのシナリオでは、要求は、ＭＮＯ ６０４によって承認される。次に、ＭＮＯは、ｖＳＩＭ−ＣＯＲＥへの送信のためにｖＳＩＭ信用証明書のサブスクライバ関連部分を準備する。ＭＮＯ ６０４は、ランダムに選択されるセッション鍵Ｋｓを生成する。その後、鍵Ｋｓは、６６０で、ＴＳＳ−ＭＮＯ ２０４からの対応する鍵と一緒に、ターゲットプラットフォームにリンクされ、その結果、データ（この場合には鍵Ｋｓ）を、関連する認可されたエンティティだけが使用できるようになる。ＭＮＯ ６０４は、６６２で、セッション鍵と一緒にｖＳＩＭ信用証明書のサブスクライバ関連部分を暗号化し、両方をＴＳＳ−ＭＮＯ ２０４に送信する。

最後に、ＴＳＳ−ＭＮＯ ２０４は、セッション鍵Ｋｓを公開する。この鍵を用いて、ＴＳＳ−ＭＮＯ ２０４は、ｖＳＩＭ信用証明書のサブスクライバ関連部分を暗号化解除し、付随する署名をチェックする。暗号化解除が成功して実行され、検証された時に、ｖＳＩＭ−ＣＯＲＥは、受信されたｖＳＩＭ信用証明書を１つまたは複数の有効なプラットフォーム構成上で封印する。次に、ｖＳＩＭ−ＣＯＲＥは、６６４で、手順を終了し、インストールを終える。

代替案では、ＭＮＯ ６０４は、分離された鍵Ｋｓを生成し、ｖＳＩＭ信用証明書の暗号化されたサブスクライバ関連部分をｔｉｃｋｅｔ−ｉに組み込むことができる。この場合に、ＭＮＯ ６０４は、６６２で、ターゲットプラットフォームのｖＳＩＭ−ＣＯＲＥに鍵Ｋｓだけを送信する。

図７に、ソースプラットフォーム７０１からターゲットプラットフォーム７０７へｖＳＩＭ信用証明書またはその実行環境を移行する手順の例を示す。この手順は、ＴＳＳ−ＤＯ−Ｓ ７０２およびＴＳＳ−ＭＮＯ−Ｓ ７０４を含むソースプラットフォーム７０１と、ＴＳＳ−ＭＮＯ−Ｔ ７０６およびＴＳＳ−ＤＯ−Ｔ ７０８を含むターゲットプラットフォーム７０７との間で実行される。ＳＲＫ（ストレージルート鍵）を含むすべてのセキュリティに敏感なデータが、ターゲットＴＳＳ−ＭＮＯ−Ｔに移行される。これは、両方のサブシステムＴＳＳ−ＭＮＯ−ＳおよびＴＳＳ−ＭＮＯ−Ｔ上に同一のＲＯ（遠隔所有者）を必要とする。

図７の移行手順は、完全な鍵階層を、（１）同一の利害関係者の実行環境の間で（２）このために特定のセキュリティポリシが両方のプラットフォームに存在し、認可される時に限って移行できることをもたらす。移行に関するこれらの制約は、１つのＭＮＯだけがかかわることを必要とするが、信用証明書を、あるサブシステムから異なる所有者を有する別のサブシステムに移行することができる。利害関係者が同一であることの検証は、認証機構を介してソースエンティティおよび宛先エンティティによって実行することができる。構成転送は、ソフトウェアスイートを除いて信用証明書およびポリシだけが、あるプラットフォームから別のプラットフォームに移行され、移行が機能性と独立になるように、一般化することができる。

この手順は、ＴＳＳ−ＤＯ−Ｓ ７０２が、７５０で、ＴＳＳ−ＭＮＯ−Ｓ ７０４にサブシステム移行の要求を送信する時に開始される。ＴＳＳ−ＭＮＯ−Ｓ ７０４は、７５１で、ユーザのサービスレベルおよびターゲットＭＮＯとの契約関係が移行を可能にするかどうかをチェックする。次に、ＴＳＳ−ＭＮＯ−Ｓ ７０４は、７５２で、サブシステム移行の要求（ＴＳＳ−ＭＮＯ−Ｓ−→ＴＳＳ−ＭＮＯ−Ｔ）をＴＳＳ−ＭＮＯ−Ｔ ７０６に送信する。次に、ＴＳＳ−ＭＮＯ−Ｔ ７０６は、７５４で、ターゲットプラットフォーム７０７が許容できる状態であることを保証するために、ＴＳＳ−ＭＮＯ−Ｓ ７０４のローカル検証を実行する。次に、ＴＳＳ−ＭＮＯ−Ｔは、７５６で、移行を実行することの検証要求をＴＳＳ−ＤＯ−Ｔ ７０８に送信する。ＴＳＳ−ＤＯ−Ｔ ７０８は、７５８で、確認を実行する。成功の検証の時に、ＴＳＳ−ＤＯ−Ｔ ７０８は、７６０で、ＴＳＳ−ＭＮＯ−Ｔ ７０６に状態メッセージを送信する。次に、ＴＳＳ−ＭＮＯ−Ｔ ７０６は、７６２で、ＮＯＮＣＥ−ＭＮＯ−Ｔを生成する。ＴＳＳ−ＭＮＯ−Ｔ ７０６は、７６４で、その証明書、ナンスＮＯＮＣＥ−ＭＮＯ−Ｔ、現在の状態Ｓ_i,t、およびセキュリティポリシをＴＳＳ−ＭＮＯ−Ｓ ７０４に送信する。次に、ＴＳＳ−ＭＮＯ−Ｓ ７０４は、７６６で、プラットフォームの検証を実行し、プラットフォームを移行のために準備する。成功の検証の時には、ＴＳＳ−ＭＮＯ−Ｓ ７０４は、７６８で、ソースプラットフォーム７０１のシリアル化を実行する。シリアル化とは、受け取る当事者がエンティティをそのオリジナルの形に再構成することを可能にするための、情報のビットストリームへのそのエンティティの変換と、通信チャネルを介するその運搬とである。次に、ＴＳＳ−ＭＮＯ−Ｓ ７０４は、７７０で、ソースサブシステムＴＳＳ−ＭＮＯ−Ｓのシリアル化されたエンティティを含むメッセージをＴＳＳ−ＭＮＯ−Ｔ ７０６に送信する。ＴＳＳ−ＭＮＯ−Ｔは、７７２で、ソースサブシステムをインポートする。次に、ＴＳＳ−ＭＮＯ−Ｔは、７７４で、ＴＳＳ−ＭＮＯ−Ｓ ７０４に状態メッセージを送信する。ＴＳＳ−ＭＮＯ．Ｓは、７７６でＴＳＳ−ＭＮＯ−Ｓを破壊する。

図７は、移行手順の特定の実施態様を示すが、次のセクションは、図７の手順に類似する終点を有するより一般的な手順を説明する。このために、デバイス所有者は、ＴＳＳ−ＭＮＯ−Ｓの移行サービスを開始する。
ＤＯ_S→ＴＳＳ_MNO,S ： ｉｎｉｔ＿ｍｉｇｒａｔｅ＿ｖｓｉｍ （式１８）

このサービスは、次の基本機能を提供する。プラットフォームＭＴＰ−Ｓ（またはＴＳＳ−ＤＭ）は、ターゲットプラットフォームＭＴＰ−Ｔへのセキュアチャネル（たとえばＴＬＳ、ここで、通信テクノロジを、Ｂｌｕｅｔｏｏｔｈ、ＷＬＡＮ、ＵＳＢなどとすることができる）を展開するために、ＴＳＳ−ＭＮＯ−Ｓの移行サービスによって割り当てられる。

接続が使用可能になった後に、ＴＳＳ−ＭＮＯ−Ｔは、インポート手順を実行するためにＴＳＳ−ＭＮＯ−Ｔ内のめいめいの移行サービスをアクティブ化する。

ＴＳＳ−ＭＮＯ−Ｓの認証データが、セキュアチャネルを使用してＴＳＳ−ＭＮＯ−Ｔに送信される。

次に、ターゲットサブシステムＴＳＳ−ＭＮＯ−Ｔは、ＴＳＳ−ＭＮＯ−Ｓのローカルチェックを実行する。７５２で受信される構成認証情報が無効である場合には、ＴＳＳ−ＭＮＯ−Ｔは、エラーメッセージを応答し、このプロトコルを打ち切る。それ以外の場合には、ＴＳＳ−ＭＮＯ−Ｔは、ローカル所有者ＤＯによる確認を要求する。

次に、ターゲットサブシステムＴＳＳ−ＭＮＯ−Ｔは、乱数値ＮＯＮＣＥ−ＭＮＯ−Ｔを生成する。その信頼性の証明を提供するために、ＴＳＳ−ＭＮＯ−Ｔは、すべての必要な情報をソースサブシステムＴＳＳ−ＭＮＯ−Ｓに送信する。これは、Ｓ_i,tの現在の状態、ＴＳＳ−ＭＮＯ−Ｔの証明書、セキュリティポリシＳＰ−ＭＮＯ−Ｔ、および値ＮＯＮＣＥ−ＭＮＯ−Ｔを含む。
ＴＳＳ_MNO,T→ＴＳＳ_MNO,S ： Ｓ_i,T，Ｃｅｒｔ_TSSMNO,T
ＳＰ_MNO,T，ＮＯＮＣＥ_MNO,T
（式２０）

ターゲットサブシステムからのメッセージが受信された後に、ＴＳＳ−ＭＮＯ−Ｓは、ＴＳＳ−ＭＮＯ−Ｔの状態をチェックする。ターゲットシステムが、トラステッド状態にあり、受け入れられるセキュリティポリシおよび構成を実行する場合には、ＴＳＳ−ＭＮＯ−Ｓの現在の状態が、値ＮＯＮＣＥ−ＭＮＯ−Ｔにリンクされ、すべてのさらなるアクションが、停止され、これによって、ＴＳＳ−ＭＮＯ−Ｓを非アクティブ化する。適用可能な場合に、ソースシステムが、ターゲットシステムを再アクティブ化するために適切なデータをサブミットすることに留意されたい。

ＴＳＳ−ＭＮＯ−Ｓは、対称移行鍵Ｋ−Ｍを生成し、そのエンティティをシリアル化し、これをＫ−Ｍを用いて暗号化する。Ｋ−Ｍは、ＴＳＳ−ＭＮＯ−Ｔの受け入れられる構成にリンクされる。次に、リンクされた鍵Ｋ−Ｍおよび暗号化されたエンティティは、ターゲットプラットフォームＴＳＳ−ＭＮＯ−Ｔに送信される。これは、具体的には、完全に隔離された鍵階層Ｋ−ＭＮＯ−Ｓを、ＳＲＫ−ＭＮＯ−Ｓ、セキュリティポリシＳＰ−ＭＮＯ−Ｓ、および必要なＳＣ−ＭＮＯ−Ｓと一緒に含む。二重ナンスが、新鮮さを保存し、反射攻撃を防ぐために含まれる。状態報告など、ソースプラットフォームへのすべての戻りメッセージは、メッセージの新鮮さを維持するためにナンスＮＯＮＣＥ−ＭＮＯ−Ｓを必要とする。

最後に、ターゲットサブシステムＴＳＳ−ＭＮＯ−Ｔは、受信したＫ−Ｍを暗号化解除し、それ自体のＳＲＫとしてＳＲＫ−ＭＮＯ−Ｓを使用する。このサブシステムは、受信したセキュリティポリシＳＰ−ＭＮＯ−Ｓおよびサブシステム構成ＳＣ−ＭＮＯ−Ｓをチェックする。次に、この情報を用いて、ＴＳＳ−ＭＮＯ−Ｔは、ソースサブシステムの内部構造を形成する。

ＴＳＳ−ＭＮＯ−Ｔが成功して完成された後に、ターゲットプラットフォームは、状態レポートを送信し、適用可能な場合には、プラットフォーム認証をソースシステムに送信する。

ソースプラットフォームＴＳＳ−ＭＮＯ−Ｔは、すべてのセキュリティに敏感なデータを削除するか、これらを永久的に使用不能にする。次に、ソースシステムは、適用可能な場合に、状態レポートをターゲットシステムに送信し、かつ／またはプラットフォーム認証を実行する。

図７の移行プロセスでは、実用上、ソースＭＮＯおよびターゲットＭＮＯが同一であると仮定する。この制限は、同一プロトコルの他の変形で取り除くことができ、それと同時に、ソースからターゲットへＴＳＳ−ＭＮＯのシリアル化されたエンティティを転送する必要が排除される。このために、ターゲット上の移行サービスは、ターゲット上のＴＳＳがそれに関して必ずしも存在しない、指定されたターゲットＭＮＯ−Ｂ−Ｔと共に、ソースＴＳＳ−ＭＮＯ−Ａ−Ｓから許可された移行要求を受信することができる。この場合に、ターゲットは、まず、ＴＳＳ−ＭＮＯ−Ｂ−Ｔをインストールするために、ＭＮＯ−Ｂとの遠隔所有権獲得手順を呼び出す。移行プロトコルは、本質的に未変更で実行できるが、ＴＳＳ−ＭＮＯ−Ａ−Ｓのシリアル化されたエンティティの送信を省略し、その代わりに、ＭＮＯ−Ｂと協力するネットワークアクセス、請求、および他の所望の機能に必要なそのＴＳＳの非実行可能部分、具体的にはソースｖＳＩＭのＩＭＳＩだけを送信する。ＩＭＳＩ移行に関して、サブスクライバは、新しいＩＭＳＩが作成され、ＭＮＯ−Ｂによって使用される時であっても、古い一意のサブスクライバ番号ＭＳＩＳＤＮを持ち続けることができる。

図８に、図２のトラステッドモバイルプラットフォーム２００のソフトウェアベースの認可信用証明書を使用してセルベースの通信ネットワークへの通信サブスクライバ８０２のアクセスを可能にする第１手順を実行するように構成された通信システムの例を示す。図８の手法は、ソフトウェアベースのアクセス認可信用証明書を使用して無線通信ネットワークへの通信サブスクライバ８０２のアクセスを可能にする。

仮想ソフトウェアベースのアクセス認可信用証明書の主目的は、無線通信ネットワーク内のサブスクライバ認証用の従来のセキュリティトークン（ＳＩＭカード）の機能的代用を保証することである。従来のＳＩＭ機能の代用を提供することという主目的に加えて、この手順は、アクセス認可信用証明書を指定されたトラステッドプラットフォーム構成にリンクする。

すべてのサブスクライバ関連の方法は、ＴＳＳ−ＭＮＯ内で、サービスｖＳＩＭ−ＣＯＲＥの使用によって実行される。ＧＳＭ標準規格Ａ３およびＡ８のアルゴリズムを、例のために下で示すが、類似する技法を、他の無線テクノロジの認証アルゴリズムと共に使用することもできる。下で提示する例では、これらのアルゴリズムは、サブスクライバ認証および鍵生成の責任を負う。通信チャネルを保護するアルゴリズムＡ５／３は、ＴＳＳ−ＤＭに統合される。

図８の手順が始まる前に、ＭＴＰ ２００が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。この手順は、具体的には、サービスｖＳＩＭ−ＣＯＲＥおよびｖＳＩＭ−ＭＧＭＴのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。ＭＴＰは、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。

この手順は、２つのフェーズに分割される。フェーズ１は、サービスｖＳＩＭ−ＣＯＲＥおよびｖＳＩＭ−ＭＧＭＴを初期化するためのプロトコルを構成する。たとえば、サブスクライバ認証は、たとえばＧＳＭ標準規格を考慮に入れ、ＭＮＯとデバイスとの間で行われる認証プロトコルメッセージに対する変更なしで認証アルゴリズムを実行するのにｖＳＩＭ信用証明書を使用して、フェーズ２で実行される。

フェーズ１は、ローカルユーザがｖＳＩＭサービスを初期化し、認証を実行する時に開始される。このために、ユーザ８０２は、８５０で、彼の曖昧でない識別子ＩＤ−Ｕを、正しいパスワードＣＨＶ−Ｕと一緒にｖＳＩＭ−ＭＧＭＴサービスに送信する。

サービスｖＳＩＭ−ＭＧＭＴは、８５２で、送信されたユーザデータをチェックし、このチェックが成功である場合には、めいめいのアイデンティティ信用証明書（ｖＳＩＭ信用証明書のユーザ関連部分）を保護されたストレージエリアからロードする。アイデンティティ信用証明書は、具体的には、ユーザＵ ８０２の署名鍵を含む。
Ｕ→ｖＳＩＭ_MGMT ： ＩＤ_U，ＣＨＶ_U （式２２）

次に、サービスｖＳＩＭ−ＭＧＭＴは、８５４で、サービスｖＳＩＭ−ＣＯＲＥのトラステッドインターフェースに接続し、初期化要求をｖＳＩＭ−ＣＯＲＥに送信する。ｖＳＩＭ−ＣＯＲＥは、この要求を受信した後に、８５６で、乱数値ＲＡＮＤ−ＡＵＴＨを生成し、この値を認証メッセージとしてサービスｖＳＩＭ−ＭＧＭＴに送信する。
ｖＳＩＭ_CORE→ｖＳＩＭ_MGMT ： ＲＡＮＤ_AUTH （式２３）

サービスｖＳＩＭ−ＭＧＭＴは、ユーザＵの署名鍵のめいめいの秘密部分を使用し、認証メッセージＲＡＮＤ−ＡＵＴＨに署名し、この値をサービスｖＳＩＭ−ＣＯＲＥに送り返す。
ｖＳＩＭ_MGMT→ｖＳＩＭ_CORE ： ＳＩＧＮ_U（ＲＡＮＤ_AUTH） （式２４）

ｖＳＩＭ−ＣＯＲＥは、署名されたメッセージを受信するや否や、メッセージ状態をチェックする。成功のチェックの後に、サービスｖＳＩＭ−ＣＯＲＥは、ｖＳＩＭ信用証明書のサブスクライバ関連部分を暗号化解除し、ＧＳＭアルゴリズムＡ３およびＡ８を初期化する。初期化のために、ｖＳＩＭ−ＣＯＲＥは、８５８で、ｖＳＩＭ信用証明書のサブスクライバデータＩＭＳＩ−ｉおよびＫｉを使用する。

フェーズ２は、ｖＳＩＭ−ＣＯＲＥがＭＮＯと間接的に（ＴＳＳ−ＤＭを介して）通信する時に開始される。かかわる通信当事者の間の通信は、透過的に行われる。このために、ＴＳＳ−ＤＭ ２０２は、これらのメッセージをサービスｖＳＩＭ−ＣＯＲＥとＭＮＯ ８０６との間で中継する適切な方法またはサービスを提供しなければならない。

次のプロトコルシーケンスは、ＧＳＭネットワーク内でのｖＳＩＭベースの認証方法を表し、例としてのみ提供される。まず、ＭＴＰは、認証方法を初期化し、このために、コマンドＧＳＭ＿ＡＵＴＨ＿ＡＬＧＯＲＩＴＨＭをＴＳＳ−ＭＮＯのサービスｖＳＩＭ−ＣＯＲＥに送信する。

次のステップで、ＭＴＰ ２００は、８６０で、ＴＳＳ−ＤＭを介するネットワーク８０６へのアクセスを確立する。今や、サブスクライバ認証が、次の手順に従って実行される８６２。このために、ＴＳＳ−ＭＮＯ ２０４は、識別子ＩＭＳＩ−ｉ（またはＴＭＳＩ−ｉ）をＭＮＯに送信する。
ｖＳＩＭ_CORE→ＭＮＯ ： ＩＭＳＩ_i （式２５）

ＭＮＯ ８０６は、一連の認証３つ組を内部で生成する。これらの３つ組は、認証要求ＲＡＮＤ−ｉ、一時セッション鍵Ｋｃ、および期待される認証応答ＳＲＥＳを含む。ＫｃおよびＳＲＥＳは、ＧＳＭ Ａ３／Ａ８アルゴリズムを使用して計算される。ＭＮＯ ８０６は、認証要求ＲＡＮＤ−ｉをＭＴＰ ２００に応答する。
ＭＮＯ→ｖＳＩＭ_CORE ： ＲＡＮＤ_i （式２６）

ＲＡＮＤ−ｉは、ＴＳＳ−ＤＭ ２０２によってＴＳＳ−ＭＮＯのサービスｖＳＩＭ−ＣＯＲＥに中継される。次に、ｖＳＩＭ−ＣＯＲＥは、鍵Ｋｉと一緒にＡ３アルゴリズムを使用する。Ａ３アルゴリズムの結果は、認証応答ＳＲＥＳ＊である。

ｖＳＩＭ−ＣＯＲＥは、このメッセージＳＲＥＳ＊をＭＮＯに送信する。
ｖＳＩＭ_CORE→ＭＮＯ ： ＳＲＥＳ＊ （式２７）

最後に、ＭＮＯは、ＳＲＥＳをＳＲＥＳ＊と比較する。これらが同一である場合には、サブスクライバが認証されたと考えられる。ｖＳＩＭ−ＣＯＲＥおよびＭＮＯは、共有されるセッション鍵Ｋｃを演繹し、ＫｃをＴＳＳ−ＤＭに送信する。次に、ＴＳＳ−ＤＭは、セキュア通信チャネルを確立するためにＫｃを受け入れる。

図９および図１０に、図２のトラステッドモバイルプラットフォーム２００の遠隔認証を使用してセルベースの通信ネットワークへのユーザのアクセスを可能にする第２手順を実行するように構成された通信システムの例を示す。図９では、一般通信領域９１０およびより小さいＭＮＯ領域９１５があり、ＭＮＯ領域９１５は、完全に一般通信領域９１０の境界内にある。ネットワーク９１８は、別々の、ＭＮＯに関係するサブスクリプション依存サービス９２０、サブスクリプション独立（加入独立）サービス９２５、ならびにロケーションベースのサービスおよび／または無線ローカルエリアネットワーク（ＷＬＡＮ）などの他のサービス９３０をも含む。

図８の手順と比較して、この第２手順は、公益事業など、サブスクリプション独立および／または非サブスクライバ関連である無料サービスまたはオプションのサービスを使用するために、ネットワークへのアクセスを保証するのにプラットフォーム認証の技術的可能性を使用する。

従来のＳＩＭ機能の代用を提供するという主目的に加えて、第２手順は、アクセス認可信用証明書を指定されたトラステッドプラットフォーム構成にリンクし、ＭＮＯとＭＴＰとの間の相互認証を提供する。さらに、第２手順は、一般通信領域内のサブスクリプション独立および／または非サブスクライバ関連サービスへのコアネットワークアクセス、ＳＩＭロックなどの微細粒度の機能制限、ならびにサービスの動的ダウングレード／アップグレードを提供する。

図９に示されているように、一般にアクセス可能な通信領域内のすべてのデバイスは、コアネットワークのサブスクリプション独立および／または非サブスクライバ関連サービス（ＭＮＯに関して）を使用し、またはこれにアクセスすることができる。そのようなサービスは、たとえば、ロケーションベースのサービスまたはＷＬＡＮベースのインターネットアクセスとすることができる。携帯電話機が一般通信領域に関連する場合について、その携帯電話機は、認証機構を使用して、コアネットワークへのアクセスを入手する。

ＭＮＯのサブスクライバ認証される領域（サブスクリプション依存ＭＮＯサービス）への遷移は、ｖＳＩＭ信用証明書の使用によるサブスクライバ認証の成功の完了を必要とする。したがって、ＭＴＰは、ＭＮＯによって提供される特定の通信サービス（ＧＳＭ、ＵＭＴＳなど）の領域内のサービスヘのアクセスならびにコアネットワークによって提供されるサービスへのアクセスを有する。

図１０に、図２のＭＴＰ ２００の遠隔証明を使用してセルベースの通信ネットワークへの通信サブスクライバのアクセスを可能にする第２手順の例を示す。この手順を開始できる前に、ＭＴＰ ２００が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。この手順は、具体的には、サービスｖＳＩＭ−ＣＯＲＥおよびｖＳＩＭ−ＭＧＭＴのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。ＭＴＰ ２００は、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。

図１０の手順は、３つのフェーズに分割される。この手順の第１フェーズは、コアネットワークへのアクセスを記述する。この手順は、プラットフォーム認証およびチケッティング機構を使用する。第２フェーズでは、ｖＳＩＭ信用証明書を初期化する。最後に、第３フェーズは、サブスクライバ認証の方法を実施する。

フェーズ１は、ＭＴＰ ２００がデバイスの基本認証を初期化する時に開始される。このために、トラステッド実行環境ＴＳＳ−ＤＭ ２０２は、ＭＮＯ １００６にプラットフォーム認証およびデバイス認証を指示する。次に、ＴＳＳ−ＤＭ ２０２は、１０５０で、この要求を実行し、めいめいのＮＡＰ−ＭＮＯ（ネットワークアクセスポイント１００２）に接続する。このために、ＴＳＳ−ＤＭ ２０２は、乱数値ＲＡＮＤ−ＢＡＳＥを生成し、プラットフォーム認証を実行する。その後、基本認証サービスは、実行環境ＴＳＳ−ＤＭ ２０２値ＲＡＮＤ−ＢＡＳＥ、認証データ、およびその証明書Ｃｅｒｔ−ＤＭをネットワークアクセスポイントＮＡＰ−ＭＮＯに送信する。
ＴＥ_DM→ＮＡＰ_MNO ： ＲＡＮＤ_BASE，Ｃｅｒｔ_TSSDM
ＡＴＴＥＳＴ（Ｓ_i） （式２８）

この要求がＮＡＰ−ＭＮＯによって受信されるや否や、ＮＡＰ−ＭＮＯは、ＭＴＰ ２００の状態をチェックする。保全性チェックが不合格であるか、受け入れられる基準状態が見つからない場合には、ＮＡＰ−ＭＮＯは、このプロトコルを打ち切り、エラーメッセージを応答する。プラットフォームの証明が成功である場合には、ＭＴＰ ２００は、信頼できると考えられる。

次に、ＮＡＰ−ＭＮＯの公認されたエンティティは、セッション鍵Ｋ−ＢＡＳＥと一緒にネットワークチケットを生成する１０５２。そのようなエンティティは、たとえば、モバイルネットワークプロバイダＭＮＯの一部であるＡＵＣ−ＭＮＯ（認証センタ）とすることができる。Ｋ−ＢＡＳＥは、ＭＴＰとＮＡＰ−ＭＮＯとの間でトンネルを確立する、最小限に使用されるセッション鍵である。このトンネルは、大量のデータ暗号化作業負荷を実行するトラフィック指向鍵の分配を保護するのに使用することができる。この鍵の選択は、認証トラステッドサードパーティによって行われる。

チケットは、本質的に次の情報を含み、ここで、ＲＥＡＬＭは、デバイスとの直接通信に用いられるＰＬＭＮエンティティ（ＡｕＣ、ＶＬＲ、ＨＬＲなど）を識別し、ＬＩＦＥＴＩＭＥは、チケット満了値を識別する。
Ｔｉｃｋｅｔ_BASE ：＝ ｛ＩＤ_MTP，ＩＤ_NAP，Ｋ_BASE，ＲＥＡＬＭ_BASE，ＬＩＦＥＴＩＭＥ_BASE｝ （式２９）

次に、ＡＵＣ−ＭＮＯは、１０５４で、公開（または、適用可能な場合には共有）鍵Ｋ−ＮＡＰを使用してＴｉｃｋｅｔ−ＢＡＳＥを暗号化し、Ｋ−ＢＡＳＥをＫ−ＴＳＳ−ＤＭの公開鍵にバインドすることによってＫ−ＢＡＳＥをも暗号化し、この両方をＮＡＰ−ＭＮＯに送信する。ＮＡＰ−ＭＮＯは、１０５６で、この情報をクライアントプラットフォームに中継する。このメッセージは、めいめいの公開鍵Ｋ−ＴＳＳ−ＤＭおよび有効なプラットフォーム構成と一緒にトラステッドサブシステムＴＳＳ−ＤＭ ２０２にリンクもされる。ＴＳＳ−ＤＭ ２０２が、単独ではＴｉｃｋｅｔ−ＢＡＳＥを暗号化解除できないことに留意されたい。というのは、このチケットを、秘密Ｋ−ＮＡＰを使用することによってのみ暗号化解除することができ、ＴＳＳ−ＤＭ ２０２がそれを有していないからである。そうではなく、ＴＳＳ−ＤＭ ２０２は、より後のステップで暗号化されたＴｉｃｋｅｔ−ＢＡＳＥをＮＡＰ−ＭＮＯに転送し、このＮＡＰ−ＭＮＯで、暗号化されたＴｉｃｋｅｔ−ＢＡＳＥを暗号化解除することができる。

ＴＳＳ−ＤＭ ２０２は、署名されたメッセージを受信するや否や、１０５８で、署名された値ＲＡＮＤ−ＢＡＳＥの状態をチェックする。情報が無効であるか拒絶される場合には、このサブシステムは、エラーメッセージを応答し、このプロトコルを打ち切る。別の場合には、ＡＵＣ−ＭＮＯは、認証応答によって証明される。

次に、ＴＳＳ−ＤＭ ２０２は、セッション鍵Ｋ−ＢＡＳＥを暗号化解除し、オーセンティケータＡ−ＭＴＰと一緒に、暗号化されたＴｉｃｋｅｔ−ＢＡＳＥをＮＡＰ−ＭＮＯに送信する。現在のケースでは、オーセンティケータＡ−ＭＴＰは、プラットフォームアイデンティティＩＤ−ＭＴＰ、現在のネットワークアドレスＡＤＤＲ、およびタイムスタンプＴＩＭＥからなる。

チケットベースＴｉｃｋｅｔ−ＢＡＳＥは、単純にＴＳＳ_DMによってネットワークに渡され、このネットワークで暗号化解除される。ＮＡＰ−ＭＮＯは、暗号化されたチケットを受信し終えた時に、組み込まれた情報を検証する。Ｋ−ＮＡＰの公開部分を使用するＴｉｃｋｅｔ−ＢＡＳＥの暗号化を用いて、有効なバインディングが行われる。具体的に言うと、Ｋ−ＢＡＳＥは、チケットの一部として、ＮＡＰにバインドされる。状態が有効である場合には、プラットフォームが証明され、一般サービスへのアクセスが許可される。限定的利用セッション鍵Ｋ−ＢＡＳＥは、今や、ＭＴＰ ２００とＮＡＰ−ＭＮＯとの両方にバインドされて、この２つのエンティティの間でセキュアトンネルをセットアップする。

フェーズ２の手順は、図８の手順の８５０〜８５８に類似している。

フェーズ３を完了するための２つのオプションがあり、第１のオプションは、たとえばＧＳＭ標準規格との互換性を有するサブスクライバ認証を実行する。追加のステップで、鍵Ｋ−ＢＡＳＥが、１０７０で、ＮＡＰ−ＭＮＯおよびＭＴＰの側でセッション鍵Ｋｃによって置換される。

この点で、相互認証が、ＡＵＣ−ＭＮＯとＵとの間で実行される。ＡＵＣ−ＭＮＯは、１０５６で、署名された認証要求によって証明される。その一方で、ユーザ１００８は、ＳＲＥＳによって彼のアイデンティティを検証する。ＮＡＰ−ＭＮＯとＵ １００８との間の認証は、有効なメッセージ鍵Ｋｃによって暗黙のうちに検証される。

この方法を、１０５６で、暗号化された鍵メッセージに前もってＲＡＮＤ−ｉを組み込むことによって最適化することができる。この場合に、ｖＳＩＭ−ＣＯＲＥは、このメッセージからＲＡＮＤ−ｉを抽出し、認証応答ＳＲＥＳを計算し、この両方の結果をＭＮＯに送信する。ＭＮＯは、期待されるＳＲＥＳおよび対応するセッション鍵Ｋｃを内部で生成する。

これらのエンティティの明示的認証が要求される時には、追加ステップを実行しなければならない。ＮＡＰは、プラットフォームに関して、次の手順によって証明される。まず、ＮＡＰは、オーセンティケータＡｕからタイムスタンプを除去する。次に、ＮＡＰは、その値を増分し、共有セッション鍵Ｋｃ（またはそれから導出された鍵）を使用して暗号化する。最後に、ＮＡＰは、そのメッセージをＭＴＰに送り返す。

フェーズ３の第２のオプション（図示せず）では、認証方法は、ＧＳＭ認証標準規格から逸脱することができる。この変形は、ＰＬＭＮのセキュリティにおけるかなりの増加をもたらす、わずかに変更された認証方法を表す。具体的に言うと、ＳＳ７（ｓｉｇｎａｌ ｓｙｓｔｅｍ ７）のプロトコルエラーを、この形で回避することができる。

次の変形は、フェーズ１からのコアネットワークアクセスに関する前者のネゴシエートされた情報を利用する。従来のＧＳＭインフラストラクチャでは、認証３つ組は、ＳＳ７ネットワークを介して送信される。この３つ組は、チャレンジＲＡＮＤ、正しいレスポンスＳＲＥＳ、およびメッセージ鍵Ｋｃを含む。

モバイル通信ネットワークへの初期アクセスは、メッセージ鍵Ｋ−ＢＡＳＥによって確立されるが、この鍵の更新は、不要である。これは、具体的には、セッション鍵Ｋｃの組込みに適用される。これによって、保護されないセッション鍵の伝送が回避される。

このオプションの基本的な目的は、鍵Ｋ−ＢＡＳＥを基礎として保護されるＮＡＰ−ＭＮＯとＭＴＰとの間の既存通信トンネルを利用することである。セッション鍵を更新するのではなく、ＭＮＯは、サービス更新メッセージだけをめいめいのネットワークアクセスポイントＮＡＰおよびＭＴＰに送信する。

現在のＰＬＭＮでは、たとえばＧＳＭシステムまたはＵＭＴＳシステムではＩＭＳＩ番号によって表される、ネットワークサブスクライバのアドレス空間が、不足しがちである。チケットに基づくネットワークアクセスメソッドは、この問題を克服する形である。このために、ＩＭＳＩ情報（または、類似するネットワークサブスクライバＩＤ）を、ＴＳＳ−ＤＭによってＮＡＰ−ＭＮＯに配送されるＭＴＰアイデンティティと一緒に、またはＴＳＳ−ＤＭが入手し、ＮＡＰ−ＭＮＯに転送できる任意の他のアイデンティティを担持する情報と一緒に使用することができる。上のプロトコルが成功し、要求するＭＴＰがネットワークアクセスを得た後に、ＮＡＰ−ＭＮＯは、同一ＩＭＳＩを有する通信を現在のＡＤＤＲデータに正しくマッピングし、これによって正しいエンティティに正しくマッピングするために、デバイスから発出するまたはデバイスに向けられるサービス要求に能動的に用いられる。やはり、ＡＤＤＲデータが、ＧＳＭシステムまたはＵＭＴＳシステムの文脈ではＩＭＳＩまたはＴＭＳＩになることに留意されたい。すなわち、ＮＡＰ−ＭＮＯは、ＰＬＭＮ基地局の既存識別方法を拡張する。

この方法を使用して、具体的には、たとえばｍａｃｈｉｎｅ−ｔｏ−ｍａｃｈｉｎｅ通信の場合または単一の利害関係者に属するデバイスフリートについて、グループＩＭＳＩアドレッシングを確立することができる。

さらに、同一デバイスの複数のネットワークアクセスチケットが、Ｔｉｃｋｅｔ−ＢＡＳＥ内の追加情報によっても示される、異なるサービスレベルまたは料金について同時に有効であることができる。これらの追加のアイデンティティ情報を使用して、同一のまたは異なるＭＴＰ上で同一のＩＭＳＩを共有する異なるｖＳＩＭエンティティおよび／またはユーザを識別することもできる。

チケットを、たとえばある種のサービスのアクセシビリティの期間またはそのような時間期間中の特定の料金を判定する有効性期間情報に関する情報によって増補することもできる。次に、ＮＡＰまたは別のエンティティは、チケットアイデンティティおよびそれに関連する既知の有効性期間に基づいてそのような時間限定サービスを決定し、それに関する決定を実施するタスクを入手する。

図１１に、一般ネットワークインフラストラクチャのサブスクライバ認証の第３手順を示す。図１１の手順について、ｖＳＩＭ信用証明書のサブスクライバ関連部分の構造設計およびトラステッドサービスｖＳＩＭ−ＣＯＲＥの機能性または統合されたアルゴリズムは、ある種の要件を厳守しなければならない。

図１１のｖＳＩＭ信用証明書は、対象のアイデンティティに基づくアクセス認可信用証明書である。このアクセス認可信用証明書は、２Ｇ／３Ｇ構造モールド（ｓｔｒｕｃｔｕｒａｌ ｍｏｌｄ）にはバインドされず、図８および図１０の対応物の一般化であり、通信サブスクライバのアイデンティティを証明するのに使用される。ｖＳＩＭ信用証明書は、対象Ｕ １１１０の一意識別子ＩＤ−Ｕおよび暗号法の暗号化機構（たとえば、対称鍵または非対称鍵）または非暗号法の暗号化機構（たとえば、一方向ハッシュチェーン）に基づく少なくとも１つの情報アイテムを含む。認可された対象だけが、ｖＳＩＭ信用証明書を生成するか読み取り、あるいは含まれる情報を変更することができる。ｖＳＩＭ信用証明書は、デバイスアイデンティティまたは有効な適用エリアのリストなどの追加情報を含むことができる。

ＭＴＰ １１０８は、別々の保護された実行環境内で動作するｖＳＩＭ−ＣＯＲＥサービスのインスタンスを作成する。サービスｖＳＩＭ−ＣＯＲＥは、サブスクライバ認証のコア機能の責任を負う。具体的に言うと、このサービスは、実際の認証機構を実行する。機構または手順の特定の設計は、特定の応用例に依存する。サービスｖＳＩＭ−ＣＯＲＥは、おそらくは特定のユースケースに基づいて、トラステッド機能性をインポートすることができ、他の（外部の）トラステッドサービスを提供することもできる。ｖＳＩＭ−ＣＯＲＥは、ｖＳＩＭ信用証明書の少なくとも１つのサブスクライバ関連部分をも含む。

図１１の手順が開始される前に、ＭＴＰ １１０８が、初期スタートアッププロセスを実行済みであり、トラステッドオペレーティングシステムおよびトラステッドサービスをロード済みであると仮定する。これは、具体的には、サービスｖＳＩＭ−ＣＯＲＥおよびｖＳＩＭ−ＭＧＭＴのインスタンス化を含む。プラットフォームの信頼性がチェックされ、その結果、インストールされたハードウェアおよび実行中のソフトウェアは、トラステッド状態および構成にあるようになる。ＭＴＰは、認可されたエンティティによって照会された時に、この状態を報告し、証明することができる。

図１１の手順は、３つのフェーズに分割される。フェーズ１ １１２０は、遠隔証明である。フェーズ２ １１３０は、ｖＳＩＭ信用証明書の初期化である。フェーズ３ １１４０は、サブスクライバ認証手順である。

フェーズ１ １１２０では、プラットフォーム認証が、上の例によって説明されたようにデバイス認証を実行するのに使用される。図１１に提供されたこの一般的なケースでは、ネットワークエンティティＭＮＯ １１１２は、一般ネットワークインフラストラクチャのめいめいのエンティティによって置換される。そのようなエンティティは、たとえば、このネットワーク内のＡＬＳ（認証サーバ）とすることができ、このサーバは、必ずしも２Ｇテクノロジまたは３Ｇテクノロジに束縛されるのではなく、ｌｏｎｇ ｔｅｒｍ ｅｖｏｌｕｔｉｏｎ（ＬＴＥ）などの将来のネットワークに適用することができる。

フェーズ２ １１３０すなわちｖＳＩＭサービスの初期化およびｖＳＩＭ信用証明書の初期化は、図１０のフェーズ２手順に類似する形で実行される。しかし、この手順は、一般化された仮定に基づき、したがって、さらなる認証の方法およびプロトコルのためのより幅広い基礎を使用可能にする。

フェーズ３ １１４０は、ＡＬＳによって提供されるサービスの所与のサブスクライバを認証し、認可する、サブスクライバ認証手順である。対照的に、図８および図１０の手順は、共有される秘密情報（ＧＳＭによる対称鍵Ｋｉ）のサブスクライバ認証の手順に限定される。具体的に言うと、この限定は、図１１の包括的手順には存在しない。したがって、図１１の手順では、共有される秘密は使用されず、認証プロセスは、完全に証明書ベースの非対称暗号法に基づく。たとえば、証明書機関（ＣＡ）を用いるＤｉｆｆｉｅ−Ｈｅｌｌｍａｎを使用して、鍵交換を、トラステッドエンティティの間で行うことができる。そのようなシナリオでは、当事者は、ＣＡによる検証を伴う相互アイデンティティを必要とする。

フェーズ３ １１４０では、乱数値ＲＡＮＤ−ＳＲＶが、ＡＬＳ上のサービスの拡張を要求するのに使用される。ＴＥ−ＭＮＯは、ｔｉｃｋｅｔ−ＢＡＳＥからＲＡＮＤ−ＳＲＶを抽出する。次に、ＴＳＳ−ＭＮＯが、認証応答ＸＲＥＳ＊−ＳＲＶを作り、その秘密署名鍵Ｋ−ｐｒｉｖ−ＴＭ−ＡＳを用いてＲＡＮＤ−ＳＲＶに署名する。ＵＩＤおよびサービス識別子ＳＲＶと一緒に、この署名ＸＲＥＳ＊−ＳＲＶは、ＡＬＳに送信される。ＡＬＳは、このメッセージを受信するや否や、ＸＲＥＳ＊−ＳＲＶの署名を検証する。署名が有効である場合には、プラットフォームが証明され、サービス拡張が実行される。

特徴および要素を、上で特定の組合せで説明したが、各特徴または要素を、他の特徴および要素を伴わずに単独で、または他の特徴および要素を伴ってもしくは伴わずにさまざまな組合せで使用することができる。本明細書で提供される方法または流れ図は、汎用コンピュータまたはプロセッサによる実行のためにコンピュータ可読格納媒体に組み込まれる、コンピュータプログラム、ソフトウェア、またはファームウェアで実施することができる。コンピュータ可読格納媒体の例は、読取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにＣＤ−ＲＯＭディスクおよびディジタル多用途ディスク（ＤＶＤ）などの光媒体を含む。

適切なプロセッサは、たとえば、汎用プロセッサ、特殊目的プロセッサ、従来のプロセッサ、ディジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、すべての他のタイプの集積回路（ＩＣ）、および／または状態機械を含む。

ソフトウェアに関連するプロセッサを使用して、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、無線ネットワークコントローラ（ＲＮＣ）、またはすべてのホストコンピュータで使用されるラジオ周波数トランシーバを実施することができる。ＷＴＲＵは、カメラ、ビデオカメラモジュール、ビデオ電話機、スピーカホン、振動デバイス、スピーカ、マイクロホン、テレビジョントランシーバ、ハンズフリーヘッドセット、キーボード、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、ディジタル音楽プレイヤ、メディアプレイヤ、ビデオゲームプレイヤモジュール、インターネットブラウザ、および／またはすべての無線ローカルエリアネットワーク（ＷＬＡＮ）もしくはウルトラワイドバンド（ＵＷＢ）モジュールなどのハードウェアおよび／またはソフトウェアで実施されるモジュールに関連して使用される。

実施形態
１．ｖＳＩＭ（ｖｉｒｔｕａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）−ｃｏｒｅトラステッド実行環境およびｖＳＩＭ−ＭＧＭＴ（ｖＳＩＭ−ｍａｎａｇｅｍｅｎｔ）トラステッド実行環境を有するＭＴＰ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｐｒｏｃｅｓｓｏｒ）上でｖＳＩＭ信用証明書を登録し、受信する方法であって、
登録およびチケットの要求をトラステッドＰＯＳ（売り場、店舗）に送信することと、
要求および他の信頼検証手順に応答してトラステッドＰＯＳからチケットを受信することと
を含むことを特徴とする方法。
２．ＰＯＳとのトラステッド関係を確立すること
をさらに含むことを特徴とする実施形態１に記載の方法。
３．トラステッド関係の確立は、ＰＯＳと共に認証手順を実行することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
４．トラステッド関係の確立は、ＰＯＳと共に認証手順を実行することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
５．ｖＳＩＭ（ｖｉｒｔｕａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）−ｃｏｒｅトラステッド実行環境およびｖＳＩＭ−ＭＧＭＴ（ｖＳＩＭ−ｍａｎａｇｅｍｅｎｔ）トラステッド実行環境を有するＭＴＰ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｐｒｏｃｅｓｓｏｒ）にｖＳＩＭ信用証明書を登録し、供給する、遠隔ＰＯＳ（売り場）によって実行される方法であって、
登録およびチケットの要求をＭＴＰから受信することと、
登録チケットを選択することと、
ＭＴＰに関係するサブスクライバ登録データおよび登録チケットの要求をＭＮＯ（ネットワークプロバイダ）に送信することと、
ＭＮＯから登録チケットを受信することと、
登録チケットをＭＴＰに送信することと
を含むことを特徴とする方法。
６．ＰＯＳは、トラステッドＰＯＳであることを特徴とする前の実施形態のいずれか一項に記載の方法。
７．ＭＴＰに関係するサブスクライバ登録データおよび登録チケットの要求を送信することは、認証データを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
８．ＭＮＯとのトラステッド関係を確立することをさらに含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
９．ＭＴＰとのトラステッド関係を確立することを含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
１０．受信されたチケット要求は、公開暗号化鍵の少なくとも一部を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
１１．ＭＴＰに関係するサブスクライバ登録データおよび登録チケットの要求は、認証用の署名を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
１２．登録チケットは、認証情報を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
１３．登録チケットは、認証情報を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
１４．登録チケットは、署名された証明書を含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
１５．ＭＴＰを用いて証明された非対称鍵対を確立すること
をさらに含むことを特徴とする前の実施形態のいずれか一項に記載の方法。
１６．受信された登録チケットは、暗号化されていることを特徴とする前の実施形態のいずれか一項に記載の方法。
１７．ＰＯＳは、信頼されないことを特徴とする前の実施形態のいずれか一項に記載の方法。
１８．ＭＴＰ（ｍｏｂｉｌｅ ｔｒｕｓｔｅｄ ｐｌａｔｆｏｒｍ）であって、
ＭＴＰの製造メーカーに関係する信用証明書を格納し、提供するように構成されたＴＳＳ−ＤＭ（デバイス製造メーカートラステッドサブシステム）と、
ＭＮＯ（モバイルネットワークオペレータ）に関係する信用証明書を格納し、提供するように構成されたＴＳＳ−ＭＮＯ（モバイルネットワークオペレータ−トラステッドサブシステム）と、
ＭＴＰのユーザに関係する信用証明書を格納し、提供するように構成されたＴＳＳ−Ｕ（デバイスユーザ−トラステッドサブシステム）と
を含むことを特徴とするＭＴＰ。
１９．ＴＳＳ−ＭＮＯは、ＭＮＯに関係する信用証明書情報を格納し、提供し、処理するように構成されたｖＳＩＭ（ｖｉｒｔｕａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）コアサービスユニットを含むことを特徴とする実施形態１８に記載のＭＴＰ。
２０．ＴＳＳ−ＤＯは、ＭＴＰのユーザに関係する信用証明書情報を格納し、提供し、処理するように構成されたｖＳＩＭ（ｖｉｒｔｕａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）管理ユニットを含むことを特徴とする実施形態１８〜１９のいずれか一項に記載のＭＴＰ。
２１．ＴＳＳ−ＤＯおよびＴＳＳ−ＭＮＯは、トラステッドｖＳＩＭ（ｖｉｒｔｕａｌ ｓｕｂｓｃｒｉｂｅｒ ｉｄｅｎｔｉｔｙ ｍｏｄｕｌｅ）サービスを介して通信することを特徴とする実施形態１８〜２０のいずれか一項に記載のＭＴＰ。
２２．ＭＴＰの第２ユーザに関係する信用証明書を格納し、提供するように構成された第２ＴＳＳ−Ｕ
をさらに含むことを特徴とする実施形態１８〜２１のいずれか一項に記載のＭＴＰ。
２３．ＭＴＰの所有者に関係する信用証明書を格納し、提供するように構成されたデバイス所有者−トラステッドサブシステムＴＳＳ−ＤＯ
をさらに含むことを特徴とする実施形態１８〜２２のいずれか一項に記載のＭＴＰ。
２４．第２ＭＮＯに関係する信用証明書を格納し、提供するように構成された第２ＴＳＳ−ＭＮＯ
をさらに含むことを特徴とする実施形態１８〜２３のいずれか一項に記載のＭＴＰ。

本発明は、一般的に無線通信システムに利用することができる。

１１０、５０２ ユーザ
１２０ トラステッドモバイルプラットフォーム
１３０ 基地局
１４０、５０６ ネットワークサービスプロバイダ
１５０、５０４ ＰＯＳ売り場
２００ 単一ユーザＭＴＰ
３００ マルチユーザＭＴＰ

Claims (9)

1. 無線送受信ユニット（ＷＴＲＵ）の上にあるモバイルトラステッドプラットフォーム（ＭＴＰ）であって、
   前記ＷＴＲＵの上にあるメモリを経由して、
   前記ＭＴＰの製造者に関係する信用証明書を格納しおよび提供するように構成された第１のトラステッドサブシステムであって、離れた利害関係者と通信をし、および、前記利害関係者が所有するために、前記ＭＴＰ上の実行環境上で第２のトラステッドサブシステムを確立するよう構成された第１のトラステッドサブシステムと、
   前記ＭＴＰ上で、前記第１のトラステッドサブシステムから分離されおよび隔離されている前記第２のトラステッドサブシステムであって、前記ＷＴＲＵ上にある前記メモリを経由して、前記離れた利害関係者に関係する信用証明書を格納しおよび提供するよう構成された前記第２のトラステッドサブシステムと
   を備えたことを特徴とするＭＴＰ。
2. 前記第２のトラステッドサブシステムは、前記離れた利害関係者に関係する信用証明書情報を格納し、提供し、および処理するよう構成された、仮想サブスクライバ識別モジュール（ｖＳＩＭ）コアサービスユニットを含むことを特徴とする請求項１に記載のＭＴＰ。
3. 前記ＷＴＲＵ上にある前記メモリを経由して、前記ＭＴＰの所有者に関連する信用証明書を格納しおよび提供するよう構成された第３のトラステッドサブシステムをさらに備えたことを特徴とする請求項１に記載のＭＴＰ。
4. 前記ＷＴＲＵ上にある前記メモリを経由して、第２の離れた利害関係者に関連する信用証明書を格納しおよび提供するよう構成された第３のトラステッドサブシステムをさらに備えたことを特徴とする請求項１に記載のＭＴＰ。
5. 前記ＭＴＰ上で、前記第１のトラステッドサブシステムおよび前記第２のトラステッドサブシステムから分離されおよび隔離されている第３のトラステッドサブシステムであって、前記ＷＴＲＵ上にある前記メモリを経由して、前記ＭＴＰのユーザに関連する信用証明書を格納しおよび提供するよう構成された第３のトラステッドサブシステム
   をさらに備えたことを特徴とする請求項１に記載のＭＴＰ。
6. 前記第３のトラステッドサブシステムは、前記ＭＴＰの前記ユーザに関係する信用証明書情報を格納し、提供し、および処理するよう構成された、仮想サブスクライバ識別モジュール（ｖＳＩＭ）管理ユニットを含むことを特徴とする請求項５に記載のＭＴＰ。
7. 前記第２のトラステッドサブシステムおよび前記第３のトラステッドサブシステムは、トラステッド仮想サブスクライバ識別モジュール（ｖＳＩＭ）サービスを通して、通信するように構成されていることを特徴とする請求項５に記載のＭＴＰ。
8. 前記ＭＴＰ上で、前記第１のトラステッドサブシステム、前記第２のトラステッドサブシステムおよび前記第３のトラステッドサブシステムから分離されおよび隔離されている第４のトラステッドサブシステムであって、前記ＷＴＲＵ上にある前記メモリを経由して、前記ＭＴＰの第２のユーザに関連する信用証明書を格納しおよび提供するよう構成された第４のトラステッドサブシステム
   をさらに備えたことを特徴とする請求項５に記載のＭＴＰ。
9. 前記第１のトラステッドサブシステムは、デバイス製造者トラステッドサブシステム（ＴＳＳ−ＤＭ）を含み、前記第２のトラステッドサブシステムはリモート移動ネットワークオペレータ（ＭＮＯ）トラステッドサブシステム（ＴＳＳ−ＭＮＯ）を含み、前記第３のトラステッドサブシステムはデバイスユーザトラステッドサブシステム（ＴＳＳ−Ｕ）を含むことを特徴とする請求項５に記載のＭＴＰ。

Images