上述の現行システムの欠点の少なくともいくつかを解消するために、1つまたは複数のデバイス上の1つまたは複数の別々のドメインを1つまたは複数の異なるローカルもしくはリモートの所有者が所有または制御することを可能にするとともに、同時に、それらのドメインのあるレベルのシステム全体の管理を実現する方法および手段を開示する。これらの方法および手段を具現化する例示的なシステムは、1つまたは複数のデバイスを備えることができ、それらのデバイスのそれぞれが少なくとも1つのプラットフォームによってサポートされる1つまたは複数のドメインを備えることができる。それぞれのプラットフォームは、それらのドメイン用に低水準のコンピューティング、ストレージ、または通信リソースを提供することができる。プラットフォームは、いくつかのハードウェア、1つのオペレーティングシステム、および他の低水準ファームウェアもしくはソフトウェア(ブートコード、BIOS、ドライバなど)、およびそのようなリソースに対する各構成データからなるものとしてよい。それぞれのドメインは、少なくとも1つのプラットフォーム上で実行されるコンピューティング、ストレージ、または通信リソースの一構成を備えることができ、それぞれのドメインは、そのドメインのローカルまたはリモートに配置されうるドメインの所有者に対する機能を実行するように構成することができる。それぞれのドメインは、異なる所有者を有することができ、それぞれの所有者は、そのドメインのオペレーションに対するポリシーだけでなくドメインが置かれるプラットフォームおよび他のドメインに関するそのドメインのオペレーションに対するポリシーを指定することができる。
それぞれのドメインは、コンピューティング、ストレージ、もしくは通信リソース(入力の観点から)またはコンピューティング、ストレージ、または通信リソース(出力の観点から)を使用することによってドメインが提供する機能に関して、他のドメインから分離することができる。それぞれのドメインは、共通の基盤プラットフォームのコンピューティング、ストレージ、または通信リソースもしくは機能を利用することができる。共通プラットフォームによって提供されるそのような機能のうちのいくつかを共有することができるドメインもある。プラットフォームリソース機能のそのような共有は、いずれのドメインによる共通リソースもしくは機能の利用を別のドメインによるそのような利用から分離できる形で行うことができる。例えば、そのような分離は、デバイスのプラットフォーム側で厳格なアクセス制御を、ドメインのリソースへのアクセスがプラットフォームおよび/またはドメインの所有者によって許可されたドメインの外部のユーザ、所有者、または他のエンティティもしくはプロセスにのみ許されるようにドメインのそれぞれにプラットフォームが提供するリソースに強制することによって達成されうる。プラットフォームは、ドメインの機能のどれもがデバイス上のドメインのどれかの外側にあるデバイスのリソースに依存する限りにおいて、デバイス上の分離されたドメインのどれかの一部ではないデバイスの部分から単純に構成されるものであってもよい。
同じもしくは異なるプラットフォーム上の、または同じもしくは異なるデバイス上の、2つのドメイン間の通信は、安全な通信にすることができる、つまり、ドメインは互いに安全な方法で認証すること(例えば、暗号化手段を使用することによって)、また機密性、完全性、および新鮮さなどのセキュリティの態様についてそれらの間で交換されるメッセージを保護することもできるということである。ドメインが置かれているプラットフォームが備える暗号化手段を使用して、そのような2つのドメイン間のそのような安全な通信を行うことができる。
システム全体のドメインマネージャを、いくつかのドメインのうちの1つに置くことができる。システム全体のドメインマネージャは、それが置かれているドメインのポリシーを強制することができ、またシステム全体のドメインマネージャが置かれているドメインに関するそれらの各ポリシーによる他のドメインの強制を調整することができる。それに加えて、システム全体のドメインマネージャは、各ポリシーに従って他のドメイン間の相互のやり取りを調整することができる。システム全体のドメインマネージャが置かれているドメインは、そのドメインを収容するデバイスの所有者によって所有されうる。あるいは、そのようなドメインは、そのドメインを収容するデバイスを所有しえない所有者によって所有されうる。
図1は、このようなシステムの一実施形態を例示している。図示されているように、システムは、1つまたは複数のデバイス100、110、および120を備えることができる。それぞれのデバイスは、少なくとも1つのプラットフォームによってサポートされる1つまたは複数のドメインを備えることができる。例えば、デバイス100は、1つのドメイン106および1つまたは複数の他のドメイン101、102を備えることができる。これらのドメインはデバイス100に関して例示されているが、他の実施形態では、ドメインの個数は加減できる。これらのドメイン101、102、106のそれぞれは、デバイスの少なくとも1つのプラットフォーム105上で実行されるコンピューティング、ストレージ、または通信リソースの一構成を備えることができる。それぞれのドメインは、そのドメインのローカルまたはリモートに配置されうるドメインの所有者に対する機能を実行するように構成することができる。例えば、ドメイン106は、デバイス所有者(図示せず)によって所有されうるが、ドメイン101、102は、1つまたは複数のリモートの所有者によって所有されうる。それぞれのドメインは、異なる所有者を有することができるか、または、デバイスの複数のドメインが、同じ所有者によって所有されうる。それぞれの所有者は、そのドメインのオペレーションに対するポリシーだけでなくドメインが動作するプラットフォーム、ドメインが置かれているデバイス、および同じもしくは異なるデバイス内の他のドメインに関するそのドメインのオペレーションに対するポリシーを指定することができる。
上述のように、システムは、他のドメインが置かれている他のデバイスも備えることができる。例えば、デバイス110は、ドメイン111および112を備えることができ、それぞれが同じリモートの所有者によって所有されうる。もちろん、その代わりに、ドメイン111および112のそれぞれが、異なる所有者によって所有される可能性もある。ドメイン111、112のそれぞれは、デバイス110のプラットフォーム115上で実行されるコンピューティング、ストレージ、または通信リソースの一構成を備えることができる。同様に、デバイス120は、ドメイン111および112を備えることができる。この例に示されているように、これらのドメインのそれぞれは、異なる所有者によって所有されうる。あるいは、これらのドメインは、同じ所有者によって所有される可能性もある。ここでもまた、ドメイン121、122のそれぞれは、デバイス120のプラットフォーム125上で実行されるコンピューティング、ストレージ、または通信リソースの一構成を備えることができる。
システム全体のドメインマネージャ(SDM)107を、いくつかのドメインのうちの1つに置くことができる。この例では、SDM107は、デバイス100のドメイン上に置かれる。一実施形態では、SDMが置かれるドメイン(例えば、ドメイン106)は、デバイス100の所有者によって所有される。SDM107は、デバイス100内に備えられている通信メカニズムを介してデバイス100上のリモートのドメイン101と通信する。それに加えて、SDM107は、有線もしくは無線チャネルとすることができる各通信チャネル131、132、141、142を介して他のデバイス上のドメインと通信する。通信チャネル131、132、141、および142は、安全であるものとしてよい。SDM107は、それが置かれているドメイン106のポリシーを強制することができ、またドメイン106に関するそれらの各ポリシーによる他のドメイン101、111、112、121、122の強制を調整することができる。それに加えて、SDM107は、他のドメイン間の相互のやり取りを、それらの各ポリシーさらにはSDMが置かれているドメインのポリシー(その特定のドメインの所有者のポリシーとなる)に従って調整することができる。
一例として、一実施形態では、ドメインは、サービスプロバイダによって所有されうる。例えば、デバイス100のドメイン102は、例にすぎないがモバイルネットワーク通信事業者などのサービスプロバイダによって所有されうる。そのドメイン102は、デバイス100を認証する加入者識別モジュール(SIM)機能、または場合によってはそれと同等である、デバイスの所有者もしくはユーザの加入を、サービスプロバイダに対して実行し、デバイス100とサービスプロバイダとの間の通信を使用可能にすることができる。
上述のSDMの機能に加えて、SDM107は、情報にアクセスし、前記の1つまたは複数のドメインによる使用に利用可能なリソースのリストを提供することができる。SDM107は、リモートの所有者によって所有されるドメインのロードおよびメンテナンスも監視することができる。SDM107は、これが置かれているデバイス100のユーザに、これがロードすることができるドメインのリストを提供し、リストにあるドメインのうちどれをロードすべきかを選択するようユーザに求めることができる。SDMは、プラットフォームまたはデバイス上に、ロードするのに十分なコンピューティングリソースがあるかどうかも評価し、したがって、1つまたは複数のドメインのオペレーションをサポートすることができる。
また上述のように、SDM107は、本明細書ではシステム全体のドメインポリシー(SDP)とも称することができる、そのポリシーだけでなく他のドメインのポリシー、つまりドメイン固有のポリシー(DP)を強制することに加わることもできる。SDM107では、新規ドメインをロードするかどうかを評価する際に1つまたは複数の既存のドメインのポリシーを考慮することができる。例えば、リモートの所有者によって所有される所与のドメインのポリシーは、特定の種類の他のドメインがアクティブになったときに所与のドメインが非アクティブにされることを指定することができる。別の例では、リモートの所有者によって所有される所与のドメインのポリシーは、特定の他のリモートの所有者によって所有される別のドメインがアクティブになったときに所与のドメインが非アクティブにされることを指定することができる。さらに別の例では、リモートの所有者によって所有される所与のドメインのポリシーは、特定の種類の他のドメインがアクティブになったときに所与のドメインのオペレーションがある種の特定の様式に制限されることを指定することができる。さらに別の例では、リモートの所有者によって所有される所与のドメインのポリシーは、特定の他のリモートの所有者によって所有される別のドメインがアクティブになったときに所与のドメインのオペレーションがある種の特定の様式に制限されることを指定することができる。SDM107は、これらの種類のポリシーのすべての強制を受け持つことができる。
SDM107は、リモートの所有者が後で所有権を取得できるドメインの確立またはロードを行うこともできる。例えば、このようなドメインは、本明細書において「手つかずの(pristine)」状態と称される、状態において確立することができ、所有者によって所有されず、またSDM107は、リモートの所有者によるドメインの所有権の確立を管理することができる。
そのために、SDM107は、リモートの所有者がドメインの所有権を確立するかどうかを判定する際に考慮することができる情報をリモートの所有者に送信することができる。この情報は、(i)所有権の探索先となるドメインの完全性のアテステーションを示す情報、および(ii)システムの少なくとも1つの他のドメインの完全性のアテステーションを示す情報のうちの少なくとも一方を含むことができる。この情報は、(i)所有権の探索先となるドメインが動作する際のリソースを使用するプラットフォームの完全性のアテステーションを示す情報、および(ii)システムの少なくとも1つの他のドメインが動作する際のリソースを使用するプラットフォームの完全性のアテステーションを示す情報も含むことができる。それに加えて、この情報は、デバイスの現在の環境に関する情報を含むことができる。このような情報は、(i)システム内の多数の他のドメインを示す値、(ii)システム内の他のドメインの性質の要約を提示する情報、および(iii)所有権の確立が試みられているドメインによる使用に利用可能なプラットフォームのリソースを指定する情報のうちの少なくとも1つを含むことができる。システムの他のドメインに関する情報をリモートの所有者に提供する程度は、機密性および/または分離に関するこれらの他のドメインの各ポリシーを条件とするものとしてよい。
リモートの所有者がドメインの所有権を取得した後、リモートの所有者は、そのドメインに対するある程度の制御を実行することができる。例えば、リモートの所有者がドメインの所有権を確立した後、そのドメインは、リモートの所有者から、暗号鍵、構成情報、パラメータ、および実行可能コードのうちの少なくとも1つを受け取ってドメインの機能性を高めることができる。別の例では、リモートの所有者がドメインの所有権を確立した後、そのドメインは、リモートの所有者からそのドメイン固有のポリシーを受け取ることができる。
本明細書で開示されているシステムは、1つまたは複数のドメインの分離およびセキュリティも規定することができる。例えば、これらのドメインのうちの1つまたは複数は、他のドメインから分離された安全な実行およびストレージ環境を備えることができる。そのような安全な環境を確保するために、図1のデバイス100のプラットフォーム105などの、1つまたは複数のドメインが確立されるデバイスのプラットフォームは、信頼の基礎103を備えることができる。信頼の基礎103は、ハードウェアリソースの変化しない、および変更できないセットを備えることができ、その完全性は、事前確立され、ドメインのリモートの所有者を含む他者によって信頼されることができる。ドメイン101などの、ドメインの完全性は、信頼の基礎103によってアンカーされた信頼の連鎖によって確立されうる。例えば、ドメイン101の完全性は、ドメイン101の少なくとも1つのコンポーネントの、信頼の基礎103によって生成されうる測定結果を、信頼の基礎103に格納され、ドメインの完全性を検証するために信頼の基礎によって使用されうる、参照完全性基準(reference integrity metric)と比較することによって確立されることができる。あるいは、リモートの所有者側で参照完全性基準を格納し、測定結果を、参照完全性基準との比較のためにリモートの所有者に送信することができる。ドメインの完全性は、測定結果が参照完全性基準と一致する場合に検証されうる。例示的な一実施形態では、測定結果は、コンポーネント上で計算されたハッシュ値を含み、参照完全性基準は、コンポーネント上ですでに計算されており、参照完全性基準の真正性を示す情報を提供するデジタル証明書が添付されたハッシュ値を含みうる。参照完全性基準は、製造の時点で、またはデバイスをその所有者に引き渡す時点で、デバイスに事前に組み込むことができる。参照完全性基準は、デバイスを製造し/その所有者に納入した後に通信チャネル(例えば、無線通信チャネル)を介してリモートのソースから配送され、引き渡し後にデバイス内に組み込むことができる。参照完全性基準は、証明書に同封されたデバイスに配送されうる。このような証明書は、デバイスへの配送後に使用のため信頼できる第三者によって検証されうる。
本明細書で開示されているシステム、並びにその様々な方法および手段は、広範にわたるコンピューティングおよび通信の背景状況において具現化されうる。そこで、図1の例示的なデバイス100、110、および120などのシステムのデバイスは、様々な形態をとりうる。例えば、限定はしないが、システムのデバイスは、無線送信/受信ユニット(WTRU)、ユーザ装置(UE)、移動局、固定または移動式加入者装置、ページャー、携帯電話、パーソナルデジタルアシスタント(PDA)、コンピュータ、マシン間(M2)デバイス、SIMカード、ユニバーサル集積回路カード(UICC)、スマートカード、ジオトラッキング(geo-tracking)デバイス、センサー/ネットワーク間ノード、計量デバイス(水道、ガス、電気のメーターなど)、または無線もしくは有線環境において動作することが可能である他の種類のコンピューティングもしくは通信デバイスを含むことができる。下記の図および説明では、無線送信/受信ユニット(WTRU)における本開示のシステムおよび方法の多数の追加の例示的な実施形態を取りあげる。しかし、これらの実施形態は、単に例示的なものにすぎず、本明細書で開示されているシステムおよび方法は、決してこれらの実施形態に限定されない。むしろ、上述されているように、本明細書で説明されているシステムおよび方法は、広範にわたるコンピューティングおよび通信環境において使用することができる。
図2は、本明細書で説明されているシステムおよび方法が具現化されうるWTRUの一実施形態を例示する図である。図示されているように、WTRUは、UE200などの、モバイルデバイスを含むものとしてよい。UE200は、モバイル機器(ME)210および信頼できるハードウェア加入モジュール(Trusted Hardware Subscription Module)(THSM)220を備えることができる。それに加えて、THSM220は、THSMデバイス製造業者(DM)ドメイン221、THSMデバイス所有者(DO)ドメイン222、THSMデバイスユーザ(DUまたはU)ドメイン223、システム全体のドメインマネージャ(SDM)230、ドメイン間ポリシーマネージャ240、ならびにROのドメインA224、ROのドメインB225、およびROのドメインC226などの1つまたは複数のリモートの所有者(RO)ドメインをさらに備えることができる。さらに、UE200は、例示されていないコンポーネント、つまり、プロセッサ、受信機、送信機、およびアンテナを備えることができる。本明細書で説明されている例示的な実装は、図2に関して説明されているようなコンポーネントを指すものとしてよい。
THSMは、SIM機能、USIM機能、ISIM機能、およびアクセスネットワーク加入によって典型的に実行される機能を含む、信頼できる加入管理機能を提供するハードウェアベースのモジュールであるものとしてよい。THSMは、ハードウェアで保護されたモジュールであってよい。これは、関連するセキュリティ機能を備えるように特に設計されたハードウェアを含むことができる。これは、複数の分離されたドメインを内部的にサポートすることが可能であるものとしてよい。ドメインは、リモートの所有者(RO)と称される明確に区別される所有者によって請求または所有されうる。ROによって請求されるドメインは、各ROに対するプロキシとして動作しうる。
これらのドメインのうちの1つまたは複数は、信頼できる加入識別管理(Trusted Subscription Identity Management)(TSIM)などの加入管理機能を実行することができる。TSIM機能を持つ複数のドメインが単一のTHSM上に存在しうるため、THSMは、複数のROに対して加入管理をサポートすることができる。TSIM対応ドメインの管理のいくつかの態様は、システム全体のドメインマネージャ(SDM)と称される単一の管理機能によって実行されうる。他の態様は、個別のドメイン内で、または個別のドメイン上で、個別に管理されうる。
ユニバーサルモバイルテレコミュニケーションシステム(UMTS)環境に関して説明されているけれども、当業者であれば、本明細書で説明されている方法および装置は、本出願の範囲を超えることなく他の環境にも適用することが可能であることを理解することができる。TSIMは、「加入アプリケーション」の代表例であるものとしてよい。例えば、3G UMTSネットワークで動作するWTRU上で実装された場合、TSIMは、その機能の一部として、UMTSの認証と鍵照合(AKA)機能を含む、加入関係機能のすべてを含むことができる。TSIMは、UICCなどの、特定のハードウェアに束縛されない。これは、UICC上にしか存在しえない、USIMとは対照的である。その代わりに、TSIMは、本明細書で説明されているような信頼できるハードウェア加入モジュール(THSM)上に実装されうる。当業者であれば、本明細書で説明されているようなTHSMの機能は、本出願の範囲を超えることなく、欧州電気通信標準化機構(ETSI)のUICC要件に適合するUICCまたはグローバルプラットフォームの仕様に適合するスマートカードなどの、UICCまたは類似のスマートカードに組み込むことができることも理解するであろう。
WTRUは、THSMおよびモバイル機器(ME)を備えることができる。MEは、モデム、ラジオ、電源、およびWTRUに典型的に見られる他のさまざまな特徴を備えることができる。THSMは、別のハードウェアベースのモジュールを含みうる。THSMは、WTRU上に埋め込まれるか、または独立したものとすることができる。THSMは、WTRU上に埋め込まれる場合であってもMEから論理的に分離されているものとしてよい。THSMは、1つまたは複数のドメインを備え、それぞれがドメインの特定の所有者によって所有され、安全な信頼できるサービスおよびアプリケーションを提供することを目的として所有者の利益ために運用されうる。したがって、例えば、DMのドメインはTDDMと表され、DOのドメインはTDDOと表される。THSMにおけるドメインは、MEにおいて実行するのに安全または都合がよいというわけではないセキュリティ上重要な機能およびアプリケーションを実行することができる。
いくつかのドメインは、1つまたは複数のサービスプロバイダによって所有され、管理されうる。例えば、モバイルネットワーク通信事業者(MNO)、無線ローカルエリアネットワーク(WLAN)プロバイダ、またはWiMaxプロバイダなどの他の通信ネットワーク事業者、モバイル決済、モバイル発券、デジタル著作権管理(DRM)、モバイルTV、または位置情報サービスにおけるサービスプロバイダなどのアプリケーションサービスプロバイダ、またはIPマルチメディアコアネットワークサブシステム(IMS)サービスプロバイダが挙げられる。加入管理は、サービスプロバイダによって所有されているドメインによってサポートされうる。簡単のため、THSMドメイン上に実装される加入管理機能は、これ以降、TSIM機能と表されるものとしてよい。TSIM機能のサポートは、ドメインによって異なっていてもよい。例えば、サポートされているTSIM機能は、携帯端末のUICC上でUSIMおよびISIMアプリケーションによって提供されるものと似た機能を含むことができる。THSMは、UICCのように、TSIMによって提供される機能のほか、機能、アプリケーションおよびデータを含むことができる。
TSIMは、ソフトウェアユニットまたは仮想アプリケーションであってよい。TSIMは、最初に、特定のネットワーク通信事業者またはパブリックランドモバイルネットワーク(PLMN)に関連する資格証明を有していなくてもよい。TSIMは、UMTSセルラーアクセスネットワークの加入資格証明/アプリケーションの管理を指すものとしてよい。例えば、TSIMは、UMTS認証鍵などの強い秘密(Ki)の管理を含むことができる。M2Mの背景状況において、TSIMは、M2M接続性識別管理(MCIM)も含みうる。
THSMは、トラステッドプラットフォームモジュール(TPM)またはモバイルトラステッドモジュール(MTM)を有するコンピューティングデバイスに見られる測定の信頼の基礎(RTM)に似た「測定のコア信頼の基礎(RoT)(CRTM)」ユニットを備えることができる。THSMのCRTMは、例えば、THSMのブート時にTHSMブートコードの完全性を測定することができる。完全性基準は、Extendオペレーションを通じて、例えば、暗号ダイジェスト値のオペレーションをTHSMのブートコード、BIOS、および適宜、バージョン番号、ソフトウェア構成、またはリリース番号などのTHSMの製造業者の特性に対し適用することによって計算されうる。例えば、完全性基準は、SHA−Xなどのあるバージョンのセキュアハッシュアルゴリズム(SHA)ハッシングアルゴリズムを使用して計算することができる。
THSMは、完全性基準を保護されたストレージに格納するように構成された、TPMまたはMTMに見られるストレージ用の信頼の基礎(root of trust for storage)(RTS)に似た、「ストレージのコアRoT(CRTS)」ユニットを備えることができる。THSMは、THSMの完全性測定結果を外部チャレンジャに報告するように構成された、TPMまたはMTMに見られる報告用の信頼の基礎(root of trust for reporting)(RTR)に似た、「報告のコアRoT(CRTR)」ユニットを備えることもできる。
したがって、THSMは、信頼測定、ストレージ、および報告に関してTPMまたはMTMに似た機能を効果的に実現することができる。THSMは、複数のトラステッドステークホルダーエンジン(trusted stakeholder engines)を実現する機能を備えることもできる。さらに、THSMは、各マルチプルステークホルダートラステッドサブシステム(multiple-stakeholder trusted subsystems)を実現するように構成することができる。したがって、THSMは、TCGモバイルフォンワーキンググループ(MPWG)の仕様によって定められているような信頼できる携帯電話に似たものとしてよい。
THSMは、例えば、本明細書で説明されているコアRoT機能を使用して複数の内部「ステークホルダードメイン」を構築するように構成されうる。ステークホルダーは、THSMデバイス製造業者(DM)、THSMデバイス所有者(DO)、またはTHSMデバイスユーザ(DU)であるものとしてよい。DUは、DOと同じであるか、またはDOと明確に区別されてもよい。THSM毎に複数のDUがあってもよい。ステークホルダーは、DOによって特にリース(lease)されるか、または所有されているドメインの異なるリモートの所有者(RO)でもよい。例えば、MNO、IMSサービスプロバイダ、非3GPPアクセスネットワーク通信事業者、または付加価値アプリケーションサービスプロバイダなどの第三世代パートナーシッププロジェクト(3GPP)PLMN事業者は、ステークホルダーであってよい。
いくつかのドメインは、必須であり、その場合、これらはTHSMの製造時に予め構成されているものとすることができる。例えば、DMのドメインは、必須であり、事前構成されたファイルに従ってブート時に構築またはロードされうる。DOのドメインも必須であり、事前に用意されている構成に合わせて構築されうる。あるいは、ドメインは、ダウンロードした構成ファイルに従って構築することができる。
DMのドメイン以外のドメインは、ドメインの所有者によって「請求」または「所有」される前に、リモート所有権取得(RTO)プロセスを受ける必要があるものとしてよい。特定のドメインがRTOプロセスを通る前に、指定されていない所有者の「手つかずの」ドメインが存在する可能性がある。この場合、ドメインに対して請求される特定の所有権はない。
THSM上のドメインは、THSM−MEインターフェースを介してMEと通信し、情報を交換することができる。例えば、ドメインは、ブートアップまたはRTOプロセスの実行時にMEと通信することができる。THSM−MEインターフェース上で交換されるデータの保護が必要になる場合がある。
THSM−MEインターフェース上のすべての通信の完全性保護が必要になる場合がある。例えば、完全性保護では、認証された鍵交換メカニズムを使用することによって交換される1つまたは複数の事前に用意された一時鍵などの、暗号鍵を使用することができる。暗号鍵は、Ktemp_lなどのように対称的であるか、または完全性についてTHSMによって使用される公開または秘密鍵のKpub/priv_THSM_temp_Iおよび完全性についてMEによって使用される公開または秘密鍵のKpub/priv_ME_temp_Iなどのように非対称的であってよい。一時鍵は、インターフェースの保護に使用することができる。例えば、一時鍵は、有効期間に関連付けられるか、または一度だけ、または所定の回数だけ使用できる。
THSM−MEインターフェース上の通信の機密性も、暗号手段を使用して保護することができる。認証された鍵交換メカニズムを使用することによって交換される1つまたは複数の事前に用意された一時鍵を使用することができる。暗号鍵は、暗号化のためのKtemp_Cなどのように対称的であるか、または暗号化のためにTHSMによって使用される公開または秘密鍵のKpub/priv_THSM_temp_Cおよび暗号化のためにMEによって使用される公開または秘密鍵のKpub/priv_ME_temp_Cなどのように非対称的であってよい。本明細書で説明されているRTOの方法および装置は、簡単のため、事前に用意された対称一時鍵を使用することを前提とする。しかし、当業者であれば、本出願の範囲を超えることなく他の鍵実装を使用することができることを理解するであろう。
ROによりTHSM−ME間で平文で渡されるメッセージに関するリプレイアタックの防止を行うことができる。THSM−ME上で送信されるそれぞれのメッセージは、ノンス(nonce)を使って新鮮さのクオリティを保持することができる。簡単のため、本明細書で説明されているRTOプロトコルは、ME−THSMインターフェース上で交換されるすべてのメッセージのアンチリプレイ保護機能を備えるが、当業者であれば、本出願の範囲を超えることなく他のインターフェース保護構成も使用できることを理解するであろう。
ハッシュ値に署名を適用することができる。例えば、ハッシュ値は、SHA−Xアルゴリズムによって生成することができる。信頼できる第三者が、証明書(CertTSIM)を使用して、THSMに関連付けられている、KTSIM-PrivおよびKTSIM-Pubなどの秘密−公開鍵ペアを証明することができる。信頼できる第三者が、証明書(CertRO)を使用して、ネットワークに関連付けられている、KRO-PrivおよびKRO-Pubなどの別の鍵セットを証明することができる。これらの証明書は、注目しているドメインに割り振られた保護されているストレージに格納することができる。
THSMプラットフォーム、特にTSIMが公開鍵KRO-Pubを使用して、ROからの署名を検証するか、またはROに送信されたメッセージを暗号化することができる。ネットワーク側で署名のため秘密鍵KRO-Privを使用し、また対応する公開鍵を使用してTSIMによって暗号化されたメッセージを解読することができる。公開−秘密鍵ペアKTSIM-PubおよびKTSM-Privは、TSIMとROの役割が入れ替わっていることを除き類似の機能を備えることができる。あるいは、ROとTSIMの両方において、暗号化と署名のために別々の鍵ペアがあってもよい。
鍵ペアKRO-PrivとKRO-Pub、およびKTSIM-PrivとKTSIM-Pubは、所有者、ユーザ、またはその両方によって選択された特定のネットワークサービスに依存しうる。ROなどのそれぞれのサービスプロバイダは、そのプロバイダに関連付けられているTHSM上のそれぞれのドメインに対するそれ自身の証明された公開−秘密鍵ペアを有することができる。選択されたサービスは、鍵ペアのどのセットを使用するかを決定することができる。例えば、公開鍵ペアのセットは、選択されたサービスプロバイダおよびTHSM上の関連付けられているドメインによって決定されうる。使用される鍵ペアのネゴシエーションはない場合がある。公開または秘密鍵ペアは、サービスプロバイダによって決定され、THSMサブシステムもしくはドメインに緊密に関連付けられうる。
THSM TDDOは、「システム全体のドメインマネージャ」(SDM)を構成することができる。SDMは、「システム全体のドメインポリシー」(SDP)を含む事前構成されたファイルを保護して格納することができる。SDMは、SDPに従ってTHSMに対するROのドメインを構築またはロードすることができる。SDMは、DOのドメインの手つかずの構成に含まれうる。SDMは、事前構成されたSDPを使用して、他のドメインのうちのどれを、どのような順序で構築すべきかを決定することができる。
SDMは、ROドメインに代わって、ROドメインによって要求されたときに、THSMプラットフォーム環境要約(Platform Environment Summary)(TPES)およびTHSMプラットフォーム完全性アテステーション(Platform Integrity Attestation)(TPIA)を作成して提供することができる。TPESは、THSMの最新の「環境」に関する要約情報を記述するものとすることができる。このような情報は、THSM上の、機密性および分離に関して各ドメインポリシーによって条件付けられるか、または許されるような、ドメインの個数および性質要約、ならびに要求側ドメインとの機能またはリソースの通信および共有に利用可能であると思われるTHSM上の残りのリソースを含むことができる。TPIAは、THSMのドメインのうちの1つまたは複数における完全性アテステーションの集まりを含むことができる。TPIAは、前記ドメインをサポートするプラットフォームの完全性アテステーションも含みうる。TPIAは、注目しているドメイン、およびTHSM上の手つかずのドメインに対しRTOプロセスを実行することに関心のあるROなどの、外部ベリファイアに対してこれらのドメインをサポートするプラットフォームの信頼状態のアテステーションを行うために使用されうる。RO、またはROのドメイン(TDRO)は、SDMにTPIAを要求することができる。SDMは、SDPに従って要求を義務付けるか、または拒絶することができる。
SDMは、THSMの、サービス要員などの、物理的に存在するデバイス所有者とやり取りし、構築すべき他のドメインおよびその構築順序をインタラクティブに識別することもできる。さらに、SDMは、THSMの物理的に存在するユーザとやり取りして構築すべきドメインとその構築順序に対する入力を与えるようにユーザのドメインに要求することもできる。この情報は、ドメイン構築プロセスの入力として使用することができる。
THSMは、ROのドメインに対してRTOプロセスを実行する場合、リモートの所有権取得プロトコルの完了前に4つの明確に区別されるシステム状態に至ることができるように構成されうる。THSMプレブートシステム状態は、THSMが「電源オン」されていないことを示すものとしてよい。THSM_TDDM_LOAD_COMPLETEシステム状態は、THSM上のDMのドメインがTHSMの電源オン後の最初のステップとして構築またはロードされていることを示すものとしてよい。THSM_TDDO_LOAD_COMPLETEシステム状態は、DOのドメイン(TDDO)が利用可能な最終構成に合わせて構築またはロードされたことを示すものとしてよい。この「利用可能な最終構成」は、DOのドメインがそれ自体のためにRTOプロセスに通ったことがない場合に、「手つかずの」構成であるか、または「事後RTO」構成であるものとすることができる。DMのドメインは、DOのドメインを構築またはロードすることができる。DOのドメインが少なくとも1つのRTOプロセスを通る前に、DOのドメインは、「手つかずの」状態にあり、特定のDOによって請求または所有されることはありえない。「手つかずの」ドメインは、「シェル」を含むことができる。はじめてDOのドメインが構築またはロードされたときには、「利用可能な最終構成」(これ以降、最終構成(Last Configuration)と称する)は事前構成ファイルに由来するものである。あるいは、「最終構成」が、ROのドメインに対するRTOプロセスによるものである場合、THSM上の特定のドメインは、少なくとも1回、リモート所有権取得プロトコルを通り、リモートの所有者は、TSSROの所有権を取得している可能性がある。これは、リモートの所有権取得が完了した後に、プラットフォーム上に構成された信頼できるサブシステムを示すものとしてよい。この状態に到達したとき、またはその前に、特定のROが他のタスクの実行を開始することがある。
THSM_TDRO_LOAD_COMPLETEシステム状態は、ROのドメイン(TDRO)が利用可能な最終構成に合わせて構築またはロードされたことを示すものとしてよい。この「利用可能な最終構成」は、ROのドメインがそれ自体のためにRTOプロセスに通ったことがない場合に、「手つかずの」構成であるか、または「事後RTO」構成であるものとすることができる。DMのドメインは、ROのドメインを構築またはロードすることができる。DOのドメインが少なくとも1つのRTOプロセスを通る前に、DOのドメインは、「手つかずの」状態にあり、特定のDOによって請求または所有されることはありえない。「手つかずの」ドメインは、「シェル」を含むことができる。はじめてROのTDが構築またはロードされたときには、「最終構成」は事前構成ファイルに由来するものである。
あるいは、「最終構成」が、ROのTDに対するRTOプロセスによるものである場合、THSM上の特定のTDは、少なくとも1回、RTOプロトコルを通るものとしてよく、ROは、TDROの所有権を取得している。これは、RTOが完了した後に、プラットフォーム上に構成された信頼できるサブシステムを示すものとしてよい。この状態に到達するときまでに、特定のROが他のタスクの実行を開始することがある。ROのTD(TDRO)はMNOのTDである場合、この段階により、MNOのTDは、そのTDRO上に実現された最終的な信頼できる加入識別管理(TSIM)機能を提供することができる。
あるいは、DOのTDの代わりに、DMのTDに、システム全体のドメインマネージャ(SDM)を実装することができる。DOは、DMのTDに適切な許可データを付与した後に、DMのTDが備えるSDMを使用して、THSM上のさまざまなリモートの所有者TDの作成、ロード、および他の何らかの形の管理を行うタスクを実行することができる。この場合のTHSMシステムブートシーケンスおよびRTOプロセスシーケンスの詳細は、本明細書で説明されている詳細と異なる場合があるが、出願の範囲内にある。この場合のブートアップおよびRTOプロセスは、DOまたはDOのTDがDMのTDが備えるSDMをどのように使用するか、例えば、どのような種類の許可データを与えることができるか(またどのようにして与えることができるか)の記述とともに、本明細書で説明されているのと類似のものであってよい。例えば、スマートカードとして具現化されたTHSMは、カードマネージャを備えることができ、これはカード発行者の代わりにカード上のセキュリティドメインを管理する役割を有する、グローバルプラットフォームなどの規格によって指定されたカードマネージャ機能をサポートする機能を備える。カード発行者は、DMと類似しており、カードマネージャは、SDMの機能の一部を備えることができる。したがって、カードマネージャは、DMのドメイン内に保持されているSDMに類似のものであってよい。
第1の実施形態では、MEは、セキュアブート機能を備えるように構成され、THSMは、完全なMTM機能を備えるように構成されうる。電源オン時に、MEは安全にブートすることができる。例えば、MEは、オープンモバイルターミナルプラットフォーム(OMTP)の信頼できる実行環境TROの仕様などに従って非TCG「セキュア」ブートを実行することができる。ブート時に、THSMは、最初に、例えば、ブートアップによって、THSM DMのドメイン(TDDM)を構築し、次いで、「手つかずの」THSM DOのドメイン(TDDO)を構築することができる。DOおよびDUが分離している場合、THSMは、THSM DUのドメインも構築することができる。
THSM TDDMは、THSMで保護されている事前構成されたファイルで最初に構築しておき、ブート時に利用可能にすることができる。THSM TDDOは、事前構成されたファイルで大半が構築されうるが、RTOプロセスを使用して構築することもできる。THSM TDDOは、RTOプロトコルを通ることができる。このプロトコルは、ROのドメイン(TDRO)に対するRTOプロトコルと同じ形態をとるか、または異なるプロトコルであってもよい。THSM TEDOがRTOプロトコルを通らない場合、所有権を取得するために必要な資格証明が事前構成され、事前に用意される。THSM TEDOは、DOによって所有されうる。DOは、実際の人間ユーザもしくは所有者、企業もしくはその情報技術(IT)部門などの組織、またはリモートのネットワーク通信事業者(NO)でるものとしてよい。
THSM TDUは、THSM TEDO内に事前に用意された事前構成ファイルで構築することができる。THSMのROドメインは、最初に、THSM DOのシステム全体のドメインポリシー(SDP)に従って、「手つかずの」構成に合わせて構築することができる。THSMのROドメインは、ROによるRTOプロセスを通ることができる。DOのドメインのSDMは、SDPに従って、ROのドメインに対するRTOプロセスを管理することができる。THSMのROが、MNOであり、ROのドメインがMNOのドメインである場合、そのようなMNOのドメインは、i)MNOのドメインをMNOに登録する方法、ii)加入資格証明(例えば、USIMまたはMCIM秘密鍵Kiおよび国際移動電話加入者識別番号(IMSI)など)をMNOのモバイルネットワークからTHSM上のMNOのドメインにロールオフし、次いでそこに用意する方法、およびiii)加入資格証明をダウンロードした後、そのような資格証明を取り扱う、または使用する機能、またはさらには加入管理機能を備えるドメインを一方のデバイスから別のデバイスへ移行する方法を定めるプロトコルを通ることもできる。そのようなプロトコルは、i)登録プロトコル、ii)資格証明ロールオフプロトコル、および3)移行プロトコルとそれぞれ称することができる。THSMのROドメインは、RTOが完了した後に、その自構成のアテステーションを行い、それをROに報告することができる。
MEが実行することができる信頼構築メカニズムのみが電源投入時セキュアブートプロセスを実行する第1の実施形態では、ME構成は、MEまたはTHSMによってさらにアテステーション可能でない場合がある。あるいは、MEは、セキュアブートを完了するときに、自己完全性チェックを実行し、完全性値(IV)を生成することができる。MEは、機密性および完全性保護用のエンジンなどのソフトウェアを、無線(OTA)による方法を使用して、UMTSセキュリティモード機能などのセキュリティモード機能などに従ってインストールすることができる。適宜、ROによるRTOプロセスを介してROのドメインの所有権を取得する場合、ROは、RTOプロセスを完了させるために受け入れることができるTHSMの条件に関する自身のポリシーをダウンロードするか、または他の何らかの形でインポートし、次いでアサートすることができる。ROは、ROがTHSM全体の条件、THSMの他のドメインの構築構造の条件、またはその両方に合意したときにTHSMプラットフォーム上に自分のドメインをインストールする「ゲートキープ」を行うように構成されうる。したがって、RTOプロセスの一部として、ROは、DOのドメインのSDMと何らかの情報の交換を行って、DOの条件または「ドメイン構築プラン」を識別し、そのような条件がROに受け入れ可能である場合のみRTOプロセスを完了させることができる。ROドメインは、権利を持つこともでき、最初にTHSM上にそのRTO完了ROのドメインを構築することに合意した後THSMの条件またはドメイン構築プランの変更があれば更新するか、または通知するようにそのような権利を強制する機能を実行するように構成されうる。ROのドメイン固有のポリシー(DP)では、ROのドメインに通知する必要があると思われる変更の種類を指定することができる。
SDMは、対象となるROに関連付けられているROドメインに対するRTOプロセスを開始することができる。これは、ROのドメインが「手つかずの」、「未請求」状態にある場合に起こりうる。例えば、ROのドメインに、DOのドメインとDOにより「Domain X」(TDx)と名付けることができる。ドメインは、今のところ未請求のシェルまたは「手つかずの」状態で作成されうる。このような場合、SDMはRTOプロセスを開始することができ、これにより、ドメインTDxの代わりに、対象のROと接触する。ROがこのドメインについてRTOプロセスを通った後、SDMは、この同じドメインについて別のRTOプロセスを開始することができなくなる。その代わりに、ROそれ自体が、この特定のドメイン上で別の種類の所有権取得プロセスを開始することができる。そのような所有権取得プロセスは、これまでに指定されているRTOプロセスと、前者がデバイスの所有者/ユーザまたはデバイスそれ自体によってローカルで開始されるのではなくリモートの所有者によってリモートで開始されうるという点で異なることがある(場合によってはSDMまたはDOのドメインの調整の下で)。DOは、ROのドメインがRTOプロセスを通り、そうして適切なROによって「請求」または「所有」された後でも、ROのドメインの削除、破壊、または切断を行う権限を保持することができる。しかし、DOは、一般に、ROのドメイン内に格納されている秘密を知ること、またはROのドメイン内で実行される計算または機能の中間結果を知ることができない可能性がある。
SDMが手つかずのROのドメインに対してRTOプロセスを開始する前に、利用可能なリソースのリストにドメイン構築が載っていないか調べることができる。リストは、DMのドメインによって保持されうる。SDMは、「望ましいドメイン」リストを調べることもできる。望ましいドメインリストは、DOのドメインTDDO内に保持されうる。SDMは、システムドメインポリシー(SDP)、およびDMのドメインからのクエリに利用可能であると思われる、THSMの既存のドメインの、またプラットフォームの、信頼状態を含む現在状態を調べることもできる。この情報を使用して、特定のROのドメインに望ましいRTOプロセスが利用可能なリソースおよびポリシーの下で可能であり、望ましいドメインリストの下で望ましく、THSMの既存のドメインの状態、例えば、信頼状態の下で許されるかどうかを判定することができる。
あるいは、リモートの所有者のドメイン(TDRO)は、単独でRTOプロセスを開始し、管理することもできる。TDROは、未請求で、RTOプロセスの前の「手つかずの」状態にあるものとしてよい。「手つかずの」ROのドメインTDROは、ブートアップ後に対象のROと接触し、RTOプロセスを自立的に開始させることを可能にする事前構成済みの機能を備えることができる。適宜、取得側TDROがTHSMの所有者またはユーザにプロンプトを出し、次いでTHSMの所有者またはユーザから「うなずき」を得てRTOプロセスを開始した後、RTOプロセスを開始することができる。(ターゲットの)リモートの所有者RO_targetによって作成され、所有されることが意図されているが、RTOプロセスを介してまだ所有されていない、まだ「手つかずの」状態にあるドメインTDは、これ以降TDRO_target*と称されるものとしてよい。
別の代替的形態では、TDROは、特定のROによる少なくとも1つのRTOプロセスを通っており、これは、ROによって現在「請求」または「所有」されている可能性がある。ドメインTDDOなどのTHSM上のDOまたはそのプロキシが同じROのドメインに対し別のRTOプロセスを開始することが許されうるかどうかは、ROのポリシーおよび/またはSDMのポリシーに依存しうる。SDMは、RTOの目的を調べ、そのポリシー構造内の許容可能な目的または活動に基づいて、そのような新しいRTOを進めることを許すかどうかを決定することができる。リモートの信号送信経由のRO、またはROのドメイン(TDRO)は、同じROを持つドメインに対して別のRTOプロセスを開始することができる。これは、ROがTDRO内の構成ファイル、セキュリティポリシー、または実行可能コードを更新する必要がある場合に起こりうる。ROは、更新をダウンロードすることができる。更新は、非RTOの無線(OTA)による更新プロセスで実行できる。しかし、場合によっては、ROまたはTDROは、別のRTOプロセスを使用していくつかのファイルもしくはコードを更新することができる。
「手つかずの」TDROは、それ自身のためにRTOプロセスを開始するときに、DMのドメインによって保持されうる、ドメイン構築に対する利用可能なソースのリストを調べるためにSDMに依存する必要がある場合がある。TDROは、DOのドメイン内に保持されうる、「望ましいドメイン」リスト、システムドメインポリシー(SDP)、およびDMのドメインからのクエリに利用可能であると思われる、THSMの既存のドメインの信頼状態を含む現在状態を調べるためにSDMにも依存しうる。この情報を使用して、特定のROのドメインに望ましいRTOプロセスが利用可能なリソースおよびポリシーの下で可能であり、望ましいドメインリストの下で望ましく、THSMの既存のドメインの状態または信頼状態の下で許されるかどうかを判定することができる。
SDMポリシーは、DOに対する所有権取得(TO)プロセス実行時に構成されうる。このプロセスは、ブートプロセスの実行時に強制される既存の構成構造を介して、ローカルで実行できる。DOのTOは、リモートでも実行することができ、このプロセスは、RTOをブロックまたは許可するためのSDMexaminationが非デバイス所有者のリモートの所有者に対するRTOプロセスの場合と異なりDOのドメインに対するTOプロセスの場合には呼び出されないという点を除き、本明細書で指定されているように、デバイス所有者のドメインではないドメインの所有権取得とともに使用することが意図されているRTOプロセスに類似するものとしてよい。SDPは、ローカルで実行されうるDO所有権取得プロセスの際に(DOが物理的に存在し、デバイスとインタラクティブにやり取りする)、またはリモートに位置するデバイス所有者とのリモートのインタラクティブなやり取りを伴う形で確立されうる。SDPのコンポーネントは、すべての非DOドメインに共通の許容可能な活動または目的のリストである。このリストは、ドメインの所有権取得を許可されないリモートの所有者を指定する追加のエントリも含みうる。
第2の実施形態では、MEは、セキュアブート機能を有し、そのブートコードの一部の「セキュアブート」チェック機能の一部を実行するためにTHSMに依存しうる。MEは、OMTP TR0セキュアブートなどの非TCGセキュアブートを実行することができる。THSMを使用して、MEの完全性をチェックし、THSMに与えられる物理的保護を「利用する」ことができる。例えば、MEは、未加工データをTHSMに送信することができ、THSMは、MEの完全性をチェックすることができる。WTRUは、MEとTHSMとの間にセキュアチャネルを設けるメカニズム、およびMEの完全性チェックをTHSM側で実行することを目的としてコードまたはデータをTHSMに安全な方法で送信し、THSMとセキュアチャネルなどを介して安全に通信することを少なくとも信頼できるMEの「いくぶん信頼に足る」部分を実装することができる。THSMは、その中に、MEに代わってMEのコードの一部を格納することもできる。これらのコードは、ブートプロセスの実行時にME内にロードすることができる。THSMは、MEの完全性チェックを実行するか、またはMEに対するコードの一部を格納しロードする役割を受け持つことができるが、それは、それ自身とMEとの間でTHSMがハードウェアベースの保護メカニズムを持つことでより信頼性の高い環境となりうるからである。第3の実施形態では、THSMは、セキュアブートの一部またはMEのコードの完全性チェックを実行することができる。これは、ROをアテステーション可能であるものとしてよい。MEは、単一の信頼できるエンティティ、つまりモバイルトラステッド環境(MTE)を備えることができる。MTEは、MEの残り部分より信頼できるME内の論理的に分離されている環境であるものとすることができる。MTEは、ハードウェアベースの信頼の基礎(RoT)などのいくつかのハードウェアベースの保護メカニズムを利用することができる。MEのベースコードがロードされた後、MTEをロードすることができる。MTEは、外部ベリファイアに信頼できる署名鍵の使用などの信頼の証明を与えることができるという意味で信頼できるエンティティであるものとしてよい。MTEは、信頼できるエンティティであるけれども、実際のTPMに関連付けられている測定プログラムコードである測定用のコアな信頼の基礎を有することができない。MEが、電力を供給されるデバイスとして、THSMが動作しうる「プラットフォーム」を提供する限り、MEは、本明細書ではMEプラットフォームと称することができる。MTEは、MEプラットフォームの完全性の証拠を集めて、その証拠を、MTE内で保護されている署名鍵の使用によってなされる少なくとも完全性保護の下で、ポストブートSDMなどのTHSM内の信頼できるエンティティに回送するように構成されうる。THSMは、TCG TPMまたはMTMに似た完全性測定および検証機能を実装するので、THSMは、「Extend」オペレーションを実行するTCG TPMまたはMTMの機能も実装することができ、これにより、現在のソフトウェアの測定結果を、ソフトウェアのロードの状態の推移を示すプラットフォーム構成レジスタ(PCR)の現在値と組み合わせて、PCRに対する新しい値を計算する。THSMは、ダイジェスト値(ソフトウェアコンポーネントの完全性の未加工の測定値である)またはPCRの値を、THSMに対してMEプラットフォームが信頼性のアテステーションを行うために使用することができる別の完全性データに変換するメカニズムを実装することもできる。簡単のため、MEプラットフォーム完全性の収集データは、これ以降、MEプラットフォーム完全性データ(MPID)と表すことができる。THSMは、MEまたはMTEに対するドメインを維持することができない。THSMは、事前構成されたファイルから、またはDMとのリアルタイムの接触によって、計算されたダイジェストをチェックする際に突き合わせる認定済みの基準を取得することができるものとしてよい。一致していると判定された場合、次にMEのアテステーションを行うことができる。MTEは、型式番号、実行が意図されているサービスの種類、およびサービスの対象者などの、MEの「環境」を記述するデータを収集することができる場合もある。簡単のため、MEのそのような環境記述は、これ以降、MEプラットフォーム環境調査(MPES)と表すことができる。THSM DOのROは、その自ドメインとともにMEプラットフォームの完全性のアテステーションを行うことができる。このアテステーションは、特許文献1において指定されているような、M2Mを背景とする、トラステッド環境(TRE)のM2ME妥当性確認機能に類似しているものとしてよい。MEは、継続的に、単独で、またはTHSMからの要求があったときに、その変化する状態をTHSMに報告することができる。
第4の実施形態では、MEとTHSMの両方を、完全なMTM機能を実行するように構成することができる。ME、またはそのドメインが信頼に足るかどうかは、MEによって、またはそのドメインによって直接的に、アテステーション可能であるものとしてよい。MEのROドメインは、継続的に、または要求があったときに、その状態をROに報告することができる。THSMのROドメインも同様に機能しうる。MEのROドメインおよびTHSMのROドメインによる報告は、同期させることができ、また互いに束縛することもできる。これらの報告は、プロトコルフローの共通セッションを使用して行うこともできる。
この実施形態では、MEは、本明細書で説明されているようにTHSMのいくつかの機能を実行するように構成されうる。MEは、自らの1つまたは複数のドメインを備え、それぞれ特定の所有者に関係するものとしてよい。これらのドメインは、THSMによる信頼できるエンティティの特性を備えるものとしてよい。そのようなドメインは、デバイス製造業者(DM)ドメインおよびユーザ(U)ドメインを含みうる。これらのドメインは、THSMと同様にして事前構成することができる。ME上のドメインをTHSM上のドメインから区別するために、文字MEに、ドメインそれ自体を指定する文字を下付き文字にして付けることができる。したがって、DMに対するドメインは、MEDMで表すことができる。THSM上のデバイス所有者(DO)ドメインは、ME側のドメインを監視して、SDMに置かれるシステム全体のドメインポリシー(SDP)への準拠を確認することができる。ME内にそれぞれのドメインを作成する場合に、SDMとの通信により、THSM DOはそれぞれの新しいドメイン構成を認識することができる。
MEは、THSMにおけるSDMと同様に機能しうる、プラットフォームドメインマネージャ(MEPDM)として称されうる、ドメインマネージャを備えることができる。MEPDMは、MEDM内に置かれ、最初は、DMによって定義されるような事前構成を有することができる。この初期構成は、その目的と機能に関して、THSM上のTDDMの初期の事前構成された定義と類似するものとすることができる。MEDMのセットアップは、TDDOがTHSMにおいてインスタンス化された後に行われるように時間設定することができる。SDMが、MEDMに対するセットアップが完了したことを通知された場合、これは、システム全体の制約条件に応じて、SDPに由来する、またはSDPの反射におけるポリシー制約条件を課すことができる。SDMは、THSM上に多数のリモートの所有者およびそのドメインのリストを保持することができる。ドメインが、リストに載っている所有者の1人に属するME上に作成され、管理される場合、SDMは、ME上のそれらのドメインの作成および管理の特定の制御を行うことができる。
この実施形態では、MEは、完全なMTM機能を有することができる。したがって、これは、測定用のコアな信頼の基礎(CRTM)、報告用のコアな信頼の基礎(CRTR)、およびストレージ用のコアな信頼の基礎(CRTS)を備えることができる。THSM上で、ドメイン加入機能はTSIM機能によって管理されうる。THSM内の一方のドメインおよびME内の他方のドメインなどの2つのドメインが、同じROに対するものである場合、THSM上のドメインは、そのリモートの所有者に対する加入機能およびその管理などの、非常に高レベルのセキュリティおよび/または信頼を必要とするROに対する機能またはサービスに使用することができるが、ME上のドメインは、それでもまだ特定のレベルのセキュリティまたは信頼を必要としうるがTHSM上のドメインから予想される機能およびサービスに必要なレベルと同じレベルではない同じROに対する機能またはサービスに使用することができる。事前構成されたファイルから構築されないドメインは、リモート所有権取得(RTO)プロセスを通じて構成されうる。典型的なリモートの所有者(RO)に対するMEのRTOは、THSMのものと類似していてもよい。
ME上のドメインは、リモートの所有者に対する加入管理に使用されることが意図されていない場合がある。その代わりに、これらは、ユーザ、所有者、リモートの所有者、またはこれらの組み合わせのために計算およびリソースを必要とするタスクを実行するために使用されることが意図されていてもよい。例えば、これらのドメインは、THSM上の比較的限られたリソースに対して実用的でない可能性のあるタスクを実行することができる。ME上のドメインは、1回作成されてその後明示的に削除されるまでME内に留まる代わりに、これらのドメインは仮想化の場合と同様にブート時に、またはさらには実行時のセッションにおいて作成され、一時的なセッションベースで特定の目的に使用されうるという点で「つかの間の」または「一時的な」ものであってもよい。ME上のドメインのリモートの所有者は、他のリモートの所有者によって所有されるME上の他のドメインまたはTHSM上のそのような他のドメインのリソースおよびその目的の割り当てのアテステーションがなされた調査を要求し取得することに関して同じレベルの特権を有することはできない。
モバイルトラステッドプラットフォームのデバイス所有者がMNOリモート所有者とも称される特定のPLMNによって事前割り当ておよび初期化がなされていない「ブランク」のWTRUを購入し、制約なしでモバイルネットワーク通信事業者を任意に選択できるようにする方法を提供すると有益である。この方法は、リモートの所有者がPLMN事業者であるか、または加入アプリケーションの対象となる他の類似の事業者である場合にUMTSデバイス(UE)などの、WTRUの、RTOプロセスなどの、所有権取得プロセスを実行することを含み、THSM内のドメインであり、正しいROによって請求されうる、ROのドメインなどの、サブシステムをセットアップし、カスタマイズし、ファイナライズすることができる。
すでに述べたように、信頼できるハードウェア加入モジュール(THSM)は、IMS加入識別モジュール(ISIM)などの、PLMN事業者のための加入アプリケーションおよび他の付加価値サービスの機能を備える改竄防止機能付きハードウェアコンポーネントモジュールとして構築されるか、またはTHSM内に、そのような改竄防止機能付きハードウェアコンポーネントモジュールを備えることができる。THSMは、WTRUから取り外し可能であるか、または取り外し不可能であるものとしてよい。UICCの機能強化バージョンまたはグローバルプラットフォーム規格に準拠するスマートカードは、そのようなTHSMの一実施形態であるものとしてよい。
所有権取得オペレーションは、通信事業者またはPLMNとWTRUとの間の基本的な「信頼」関係を構築する。この手順で、汎用の「信頼できる」ソフトウェア構成を有する「手つかずの」エンジンを備える「ブランクトラステッド」TSIMをインストールしてインスタンス化することができる。このサブシステムは、プラットフォームが「手つかずの」構成およびセキュリティ属性の証拠をもたらすことが可能である場合に、リモートの所有者によって「認定」されうる。図3および3Aは、本明細書で説明されている第1の実施形態に特に関係しているときにこのプロセスの一例を示している。リモートの所有者は、要求されたサービスをユーザに提供し、適切なセキュリティポリシーをセットアップし、サービスと矛盾しないデバイス構成を強制するモバイルネットワークであってもよい。このプロトコルに対する所有者はローカルに置かれていてもよい。
図3および3Aは、例示的なブートアップおよびRTOプロセスを例示している。MEは、プレブート状態304を有することができる。符号306でデバイスを電源オンにすることができる。MEは、符号308で、「セキュア」ブート(非TCG)を実行することができる。MEは、ベースコードブート状態310に到達することができる。さらに、MEは、符号312で、「ベースブート完了」信号をTHSMに送信することができる。MEは、符号314で、基本構成により追加のソフトウェアをロードすることができる。MEブートは、符号316で、完了(アプリケーションロード)状態になるものとしてよい。MEは、符号318で、THSMにブート完了メッセージを送信することができる。
THSMは、プレブート状態330にあるものとしてよい。THSMは、符号334で、TEDMをロードすることができる。THSMは、構成時に事前構成されたファイルを受け取ることができ、例えば、符号336は、事前構成されたファイルの使用を例示している。符号338で、THSMは、「TDDM構築」状態(基本構成状態)に到達しうる。THSMは、例えば符号340に例示されているように、ROドメインに対する利用可能なリソースに関するDMの仕様を受信することができる。
符号342で、TDDMは、TDDOを構築することができる(TDDOはSDMを含むことができる)。符号344で、THSMは、保存済み構成ファイルを使用して、例えば、ドメインを構築することができる(前のRTOがあるため利用可能である場合がある)。符号346で、THSMは、TDDO構築状態(SDMを含む)に到達することができ、TDDOは、DOによって未請求であるか、または請求済みであるものとしてよい。符号350で、TDDOはTDuを構築することができる。符号352で、DOから入力を受け取ることができる。符号354で、THSMは、TDu構築状態に到達することができ、TDuは、未請求であるか、または請求済みであるものとしてよい。符号356で、THSMは、DOまたはDUから入力を受け取ることができる(例えば、ファイルまたはインタラクティブな操作によって、DOがどのドメインを構築したいかを指定する)。符号358で、TDDOは、ROドメイン、TDROを構築することができる。
次に図3Aを参照すると、符号362で、THSMが、TDROが構築された状態に到達することができ、TDROは、ROによって未請求であるか、または請求済みであるものとしてよいことがわかる。符号366で、SDMが、RTOを実行するようにTDROに要求することができるか、またはTDROが、RTOを実行することをSDMに通知する(または要求する)ことができる。符号370で、TDROはRTOプロセスを開始することができる。符号380では、代表的なリモートの所有者(RO1...ROn)がいる。符号384で、情報を交換することができる。例えば、リモートの所有者によるRTOプロセスの一部として、交換される情報は、アテステーション、構成、ポリシー、目的、証明書(本明細書ではCERTと称する)、鍵、およびSPからTDROまでのうちの1つまたは複数の含むことができる。適宜、ROは、RTOプロセスの実行中にDOの「環境」または「ドメインプラン」を見いだすことができ、それが環境/プランと一致する場合にプロセスを続行させることができる。
符号372で、THSMは、さまざまなドメインに対するシステム構成を取り込み/更新し、その情報を保存し、その情報をTHSM内の不揮発性の保護されたメモリに格納することができる。符号374で、THSMは、ポストRTO TDROを持つ状態に到達することができる。
第1の実施形態を参照すると、DOのRTOによって形成されたポリシードメインは、その後のRTOプロセスのドメイン構成に影響を及ぼす規定を含みうる。RTOプロトコルは、非DO ROに適していることがある。ドメイン固有のポリシー(DP)は、RTOトランザクションの実行時にダウンロードすることができる。DOに対するDPは、ROに対するDPと、そのようなDP(DPDO)がTHSM内の、リモートで所有されうる、他のドメインを構築し、維持するために使用することを目的とするシステム全体のドメインポリシー(SDP)を含みうるという点で、異なる場合がある。RTOプロセスの実行前に、またはRTOプロセスの実行中に、ドメインのROは、信頼できる第三者(TTP)から、THSMのすべてのドメインもしくはすべてのドメインのサブセットをサポートするハードウェアもしくはソフトウェアの構成および現在完全性状態に対する参照完全性基準(RIMRO)を取得することができ、
TTP→RO:RIMRO={THSMのドメインをサポートするHW/SWの構成および状態、および/またはダイジェスト値} 式1
と表すことができる。
いくつかの場合において、TTPは、ROが検証しようとしているドメインを含む、THSMのHWおよびSWのサブセットに対しRIMROを提供することができる。RIMROSを提供するために複数のTTPが必要になる場合があり、ROは集合的な参照基準を集めて形成する。RTOプロセスが適用されるTHSMのターゲットドメイン(TDRO_target)は、THSMのSDMの助けを借りて、そのROに署名されたTHSMプラットフォーム完全性アテステーション(TPIA)を提供するように構成されうる。TPIAは、THSM上のドメインの個別の完全性アテステーションおよび/またはTDRO_targetによるRTOプロセスの完了を許す前にターゲットドメインのROが検証しようとしているデバイスのプラットフォームの完全性アテステーションの連結であるものとしてよい。THSMのターゲットドメイン(TDRO_target)は、THSMのSDMの助けを借りて、そのROに署名されたTHSMプラットフォーム環境要約(TPES)を提供することができるものとしてよい。TPESは、THSM上の他のドメインの数および性質、およびTERO_targetのために使用することが可能な、THSMのプラットフォームのリソースなどの残りの利用可能なリソースを含む、THSMの環境の要約を含むことができ、
TDRO_target→RO:[TPIA]signed||[TPES]signed 式2
と表すことができる。
あるいは、ROが注目するすべてのドメイン上のすべてのアテステーションを含むことができるTPIAを報告する代わりに、SDMは、すべてのドメインの完全性のチェックを済ませ、それらが信頼に足るものであるとみなすことを示す、半自立的ステートメントであってもよい、署名されたステートメントを提供することができる。このアテステーションは、ドメインの集まりの完全性のローカルでの検証を含みうる。ローカルのベリファイアは、THSM上のそれぞれのドメインに対する有効な構成リストを含みうる。SDMは、ローカルのベリファイアに、AIKによって署名されうるTPIAを提供することができる。個別の完全性アテステーションの検証は、構成リストに載っている対応するローカルに格納されているエントリと一致することを要求する場合がある。SDMは、TPIAを組み立てて、それぞれのドメインが信頼に足ることを証明するのに必要な完全性測定、ロギング、およびPCRへの拡張を実行することができる。これらの測定、およびその拡張は、必要なドメインに対するアテステーションが行われたことを立証するためにベリファイアによって使用されうる。
検証が行われた後、ローカルのベリファイアは、関連するアテステーションが行われことを示すステートメントを作成し、このステートメントに、認証された鍵ペア(Ksign_verify_priv、Ksign_verify_pub)からの秘密鍵とともに署名する。署名されたTPESと連結された署名入りの検証ステートメントを含むメッセージは、
TDRO_target→RO:[検証ステートメント]Ksign_verify_priv||[TPES]signed 式3
と表すことができる。
TTP(s)からの{RIMRO}並びにTDRO_targetからの署名されたTPIAおよび署名されたTPESを受け取った後、ROは、TDRO_targetがRTOプロセスを続行するために同意できるとROが判断したTHSM内の環境などの環境内に入っており、TDRO_targetおよびROが注目する他の任意のドメインをサポートするハードウェアまたはソフトウェアが、完全性がROにとって同意できるものである状態にあるかどうかを検証することができる。
手つかずのドメインに対するRTOプロトコルは、電源投入時に開始することができる。適宜、RTOプロトコルは、電源投入後に開始することもできる。THSMのセキュアブートが完了すると、ドメインのその結果の構築は、最初など、初期の電源オン時にプラットフォームの状態、またはデバイスがすでにブートアップされ、次いで電源が落とされたときの前の状態を反映する内容を持つ構成ファイルによって決定されうる。したがって、デバイスは、TDDM構築、「手つかずの」TDDO、および「手つかずの」TEU状態を含む基本構成をとる可能性がある。あるいは、WTRUは、後の構成、例えば、前のブートアップおよびTDDM、「ポストRTO」TDDO、および「ポストRTO」TEU状態を含むドメイン構築もしくはRTOプロセスに基づく構成をとることができる。別の代替的形態では、WTRUは、図2に示されているような、追加のドメインの拡大セットも含む構成をとることができる。そのようなドメインは、前の電源投入セッション時に作成されている可能性がある、また所有権は、前のセッションで行われたすでに実行されているRTOプロセスにより各所有者によって取得されている可能性がある。
第1の実施形態を参照すると、プラットフォームの安全で信頼できるエンティティとして、THSMは所有権取得プロトコルを制御し、MEが信頼に足る初期状態にあるかどうかを判定することができることがわかる。事前に用意された鍵Ktempを使用して、THSM−MEインターフェース上で送信されるメッセージの機密性を保護することができる。簡単のため、暗号化されたメッセージAを{A}で表し、メッセージの署名を[A]で表し、表記IDMEおよびIDTHSMは、それぞれ、MEとTHSMの事前に用意された一時IDを表す。
RTOの開始は、TDDOのSDMが、ROによって、その特定のROによるRTOプロセスの後に請求されることが意図されている「未請求」で、「手つかずの」ドメインに対するRTOを開始することを含むことができる。ユーザは、MEプラットフォームの電源オン操作を開始することができる。電源オン時に、MEは、これが「アライブ」になるベースコードの、OMTPによって定められたブートなどの「非TCG」「セキュアブート」を実行することができる。非TCGセキュアブートプロセスの一部として、MEのベースコードの完全性を自立的にチェックすることができる。
第3の実施形態を参照すると、ベースコードのブートプロセスの完了後にモバイルトラステッド環境(MTE)をロードすることができることがわかる。署名鍵を使用することで、MTEは、MEプラットフォーム構成の完全性のアテステーションを行うことができる。
MEは、ベースコードをロードした後に、信号を定期的にTHSMに送信し、最小限の安全な設定でブートしたことを指示することができる。THSMのDOのドメインは信号が送信されたときにはまだブートされていない場合があるため、MEは、同じ信号を、異なるランダムなノンス(nonce_1)とともに、THSMのDOのドメインから送り返される確認応答信号を受信するまで送信することができる。この信号は、
Def)Package_1=「MEベースコードブート完了」MSG||nonce_1||IDME ME→THSMのTDDO:Package_1||[SHA−X(Package_1)]Ktemp_I 式4
として表すことができる。
第3の実施形態を参照すると、信号送受信は、
Def)Package_1=「MEベースコードブート完了&MTEロード」MSG||nonce_1||IDME ME→THSMのTDDO:Package_1||[SHA−X(Package_1)]Ktemp_I 式5
として表すことができる。
THSMは、「安全に」ブートすることができ、したがって、THSMは、そのDMのドメイン、「手つかずの」DOのドメイン、ユーザのドメイン、およびROによって所有されることが意図されているが、まだROによって所有されていないと思われる少なくとも1つの「手つかずの」ドメインをロードしている可能性がある。また、これらのドメインをロードする際に、ドメインのコード状態のそれぞれの完全性を、ドメインのそれぞれの参照完全性基準(RIM)と突き合わせてチェックすることができる。チェックは、TCG MPWG仕様などの仕様に従って実行されうる。
デバイス所有者のドメイン(TDDO)は、DOに対するRTOプロセスをすでに通っている場合に、「事前構成された」構成、または「最後に保存された(後/前RTO)」構成のいずれかに合わせてロードすることができる。DOのドメインは、ロードされるときに、システム全体のドメインマネージャ(SDM)を含むことができる。SDMは、他のリモートの所有者(RO)に属すドメインの構築またはロードおよびメンテナンスを監視することができる。SDMは、DMのドメインからの「ドメインに対して利用可能なリソースのリスト」を調べることができ、TDDOが保護する、システム全体のドメインポリシー(SDP)を調べることもできる。
ブート時に、SDMは、THSMの人間のユーザまたは人間の所有者(DO)に「構築することができるドメインのリスト」をプロンプトとして表示し、構築するドメインを選択する入力を要求することができる。ユーザまたは所有者からその入力を取得した後、SDMは、人間の所有者またはユーザからの応答で指定されたドメインのみを構築する作業を進めることができる。SDMは、MEとのインタラクティブなやり取りにより、これらのトランザクションに対するユーザインターフェース(UI)を構成することができる。
セキュアブートの後、THSMのTDDOは、「THSMブート完了」メッセージをMEに送信することができる。TDDOは、このメッセージ内に、ロードされるROのドメインの数および名前などの、ドメインの現在状態の外部開示可能な要約を含めることもできる。TDDOのSDMは、ドメインの現在状態の要約の外部への開示の範囲を決定して強制することができ、そのような決定は、SDP、および/またはTHSMおよび/またはME上のドメインのドメイン固有のポリシー(DP)に基づくものとしてよい。TDDOは、このメッセージ内のPackage_1を受け取ったことを、SHA−X完全性チェックコード入力の一部として受信したnonce_1を含めることによって確認することができ、これは、以下のように表すことができる。
Def) Package_2=「THSMブート完了」MSG||nonce_2||IDTHSM
TDDO→ME:Package_2||[SHA−X(Package_1||nonce_1)]Ktemp_I 式6
IDTHSMなどのTHSMのIDは、DMのドメインTDDM内に保持することができ、またTDDMのIDと同等であるものとしてよい。DOのドメインTDDOは、それをTDDMからフェッチして、式6においてPackage_2を構成することができる。
「THSMブート完了」信号に応答して、MEは引き続きそのブートプロセスを完了させることができる。そのブートプロセスを完了した後、MEは、THSMのTDDOに、
Def) Package_3=「MEブート完了」||nonce_3
ME→TDDO:Package_3||[SHA−X(Package_3|| nonce_2)]Ktemp_I 式7
として表すことができるメッセージを送信することができる。
以下は、DOのドメインのSDMが現在「手つかず」であるROのドメインに対するRTOプロセスを開始し、監視する場合に適用される。
TDDOがMEからPackage_2を受信した後、RTOプロセスを開始することができる。TDDO内のシステム全体のドメインマネージャは、「手つかずの」ターゲットROのドメイン(TD*RO_Target)にRTOプロセスを起動するように要求することによってRTOプロセスを開始することができる。SDMは、自立的に、または人間の所有者もしくはユーザによって促されたときに、このプロセスを開始することができる。SDMは、TD*ROに、ターゲットROに対するRTOプロセスを起動する要求を送信することができる。この要求には、ROのIDまたはネットワークアクセス識別子(NAI)など、ターゲットROの素性を示すもの、および現在の要求の有効期間を含めることができる。要求の一部として、またはその要求に同伴する別のパッケージとして、SDMは、「許可されたROのドメインに対するSDPの条件」(以下、SCARDと称する)のリストも送信することができる。SDMは、意図されたRTOプロセスの後に完了するときにTDROに対する「ターゲットドメインプラン」を送信することもできる。このメッセージングは、
Def) Package_4a=
Request_to_start_RTO||SCARD||ターゲットドメインプラン||nonce_4
SDM→TD*RO_Target:Package_4a||[SHA−X(Package_4a)]Ksign_SDM 式8
として表すことができる。
TD*RO_Targetは、Package_4を受信したことに対する応答として、その要求を受け入れるか、または拒絶することができる。この要求は、ROにROのドメインの所有権を取らせるための「オファー」として解釈されうる。TD*RO_Targetは、事前構成された基準、またはロードされたそれ自身の「手つかずの」バージョンのROのドメインポリシーに基づいて決定を下すことができる。TD*RO_Targetは、RTO、SCARD、およびターゲットドメインプランを開始する要求を調べて、実際のターゲットのリモートの所有者が不在の場合に、実際のターゲットのリモートの所有者のために、そのような決定を下すように構成されうる。これは、
Def) Package_5a=Okay(またはNot_Okay)_to_start_RTO||nonce_5a
TD*RO_target→SDM:
Package_5a||[SHA−X(Package_5a)||nonce_4]Ksign_TD*RO_Target 式9
として表すことができる。
「手つかずの」ターゲットROのドメイン(TD*RO_Target)が、このプロセスを開始することができる。TD*RO_Targetは、SDMにRTOプロセスに対する「最終ドメインプラン」をアラートすることができる。SDMは、その要求を認めるか、または拒絶することができる。SDMがその要求を認めた場合、TD*ROはRTOプロセスを起動することができ、これは
Def) Package_5b=Intend_tostart_RTO||最終ドメインプラン||nonce_5b
TD*RO_Target→SDM:Package_5b||[SHA−X(Package_5b)]Ksign_TD*RO_Target 式10
として表すことができる。
Package_5aまたはPackage_5bを受信したことに応答して、SDMは、TD*RO_Targetに対するRTOプロセスについて、TDDOに対するRTOプロセスによって事前構成されるか、または取得されうるシステムドメインポリシー(SDP)、所有者によって事前構成されるか、または供給されうる「望ましいドメイン」のリスト、DMのドメインによって保持され、継続的に更新されうる「ドメインに利用可能なリソース」のリスト、またはTHSM内のドメインの現在状態を調べることができる。
SDMは、THSM上で複数のドメインを構築または維持するために利用可能である、仮想マシンのスレッドのためのメモリもしくはコンピューティングリソースなどのリソースが十分にあるかどうか、THSM内のドメインの現在状態が「望ましいドメイン」リストで指定された状態と一致しているかどうか、「望ましいドメイン」内の新規ドメインの構築またはロードが、THSM内のドメインの現在状態によってサポート可能であり、またSDPの下で許されるかどうか、またはドメインの1つまたは複数がRTOプロセスを通る必要があるかどうかを評価することもできる。
SDMが、利用可能なリソース、THSMの既存のドメインの現在状態、およびSDPに従ってTD*RO_TargetがRTOプロセスを通ると判定した場合、SDMは、この判定(TD*RO_Target)を示して、TD*RO_Targetおよびその周囲のドメインの評価のためにRTOプロセス実行時にROに多数の完全性アテステーション回送する準備をする作業を続けることができる。これは、
Def) Package_6=Okay_to_go_ahead_with_RTO||nonce_6
SDM→TD*RO_Target:
Package_6||[SHA−X(Package_6)||nonce_5(aまたはb)]Ksign_SDM 式11
として表すことができる。
SDMは、人間のユーザに対して、例えば、WTRU上に表示されるメッセージによって特定のドメインに対するRTOプロセスを開始しようとしていることを知らせることができる。SDMは、「RTOプロセスを起動する望ましいドメインおよび望ましいRO」のリストをプロンプトとして人間のユーザもしくは人間の所有者(DO)に示し、そのプロンプトへの応答として所有者もしくはユーザが指定するROのドメインのみに対してRTOプロセスを開始する作業を続けることもできる。SDMは、これらのトランザクションに対するユーザインターフェース(UI)を構成するMEとインタラクティブなやり取りをすることができる。
TD*RO_Targetは、SDMに、THSMプラットフォーム完全性アテステーション(TPIA)およびTHSMプラットフォーム環境要約(TPES)を作成するために使用することができる資料を準備するように要求することができる。これは、
Def) Package_7=Request_for_TPIA||Request_for_TPES||nonce_7
TD*RO_Target→SDM:
Package_7||[SHA−X(Package_7)||nonce_6]Ksign_TD*RO_Target 式12
として表すことができる。
第3の実施形態を参照すると、要求は、
Def) Package_7a=Request_for_TPIA||Request_for_TPES||MPIDの要求||MPESの要求||nonce_7a
TD*RO_Target→SDM:
Package_7a||[SHA−X(Package_7a||nonce_6)]Ksign_TD*RO_Target 式13
として表すことができることがわかる。
TPIAおよびTPESの要求では、ROは、SDMから探すTPIAおよびTPESに関する情報の種類を指定することができる。例えば、TPIAについては、完全性の検証を望んでいる、それ自身とは別の、ドメインの名前または範囲を指定することができる。同様に、TPESについては、ROは、それ自身とは別のドメインの所有者の、ネットワーク割り当て識別子(NAI)などの、公開IDを指定することが可能である。
第3の実施形態を参照すると、ターゲットROは、MEプラットフォームの完全性に関する情報(これ以降MPIDと称する)およびME環境に関する他の情報を要求することもできる。あるいは、ROは、MTEがロードされ、MPIDおよびMPESがMEによってSDMに送信されたことを示す単純な指標を要求することもできる。MTE、つまりMEプラットフォームに置かれている信頼できるエンティティは、SDMによってそうするように要求されたときに値MPIDおよびMPESを準備することができる。この要求は、
Def) Package_7b=MPIDの要求||MPESの要求||nonce_7b
SDM→MTE:
Package_7b||[SHA−X(Package_7b)]Ksign_SDM 式14
として表すことができる。
MTEは、MEから構成データを収集し、MPIDを構築することができる。MEプラットフォーム環境調査(MPES)を行うために、環境データも取得することができる。これらの値は、時間の経過とともに変化する可能性のある現在のME状態に基づいていてもよい。更新された値は、もしME状態の変化の後に将来の要求がなされるのであればSDMに送信されうる。一般に、MTEは、SDMに、
Def) Package_8a=MPID||MPES||CertMTE
MTE→SDM:
Package_8a||[SHA−X(Package_8a||nonce_7b)]Ksign_MTE 式14
として表すことができる応答を送信することができる。
MTEは、公開鍵KMTE_Pubを含む、CAによって署名されうる、証明書を提供することができる。そのため、SDMはCA署名の検証を通じてこの公開鍵の真正性を検証し、これにより、MTEからのメッセージの完全性をKMTE_Pubでチェックすることができる。SDMは、TPIAおよびTPESを準備し、後で、これらをTD*RO_Targetに回送することができる。
TPIAの準備のために、SDMは、「手つかずの」TDROの、「手つかずの」TDROによる完全性アテステーション、TEDMの、TEDMによる完全性アテステーション、TEDOの、TEDOによる完全性アテステーション、TEUの、TEUによる完全性アテステーション(デバイスユーザがDOと異なる場合)、およびROが注目している他の既存のTDROの、またそのTDROによる完全性アテステーションなどの完全性アテステーションを収集することができる。
あるいは、SDMは、PCRから完全性値を収集した後、コードおよびデータなどの、測定ログのローカルにおける自立的チェックおよび再計算のプロセスによって、各ドメインに対するPCRからのダイジェスト値と突き合わせてドメインを検証することができる。これは、TTP(PCA)が各ドメインを含むであろう最新のコードを認識しないときに実行することができ、TTPは、WTRU上で、TPM、またはMTMに対し認定されているAIKにリンクした署名鍵を認定することができる。TTPは、ROがSDMからのTPIAを比較するために使用することができるダイジェスト基準に対する参照値を提供するようには構成されえない。SDMは、ドメインに対するコードのダイジェストを再計算し、見積もられたPCR値と比較することによって、ドメインに対し得られるPCR見積もりが最新のものであるかどうかをローカルでチェックすることができる。次いで、このローカルでのチェックに通ったことを条件として、SDMは、TPIAに署名し、これをTDRO_targetに受け渡し、またMTE、もしくはMEによりROtargetに受け渡すことができる。
別の代替的形態である、3方向検証では、SDMは、TPIAの一部として、ドメインの、実際のコードなどの、ダイジェストおよび測定ログを提供することができる。ROは、ダイジェストとともにコードを取得するときに、TTPからダイジェストに対する参照基準を取得することができ、測定ログからダイジェストを再計算することができ、それを、TDRO_Targetから受け取った見積もられたPCRダイジェストさらにはTTPから受け取ったダイジェストの参照基準と比較することができる。
TPIAは、測定ログがある場合もない場合も、PCR見積もりが行われるときの「ローカルの時間」を示す情報も含むことができ、個別のドメインに対するダイジェストの見積もりに効果的にタイムスタンプを付けることができる。これは、ドメインのPCRダイジェストのそれぞれが最後にSDMによって取得された時間を示すある種の情報となる。測定ログがROに送信されない場合、PCRのタイムスタンプを付けた見積もりは、ローカルのダイジェストが取得され、TPIAに含まれる時間がアテステーション検証において使用できるほど十分に最近であるかどうかを決定することに関して、TPIAに示されているアテステーションを検証する必要があるときにROへの何らかの追加情報を提供することができる。そのようなタイムスタンプに使用されるクロックは、信頼に足るクロックであるものとしてよい。
3方向検証が失敗した場合、ROは、TTPがそれに、望ましいダイジェストから計算することができる更新された参照基準または測定ログを提供するよう要求することができる。ROは、3方向検証をリトライすることができる。検証が成功した場合、RTOが続行される。検証が失敗し、成功する3方向検証がROポリシーによって必要とされる場合、RTOを終了することができる。
DOドメインの完全性アテステーションに関して、SDMは、SDMの固有の機能などを通じて、自立的にそれを取得することができる。完全性アテステーションでは、DOのドメインを除き、SDMは、他の各ドメインに、各自の完全性アテステーションを行い、それに署名するよう要求することができる。SDMは、その要求に、SDMがドメインに安全性アテステーションを要求し、取得する権限を有しているかチェックするために受け取り側が使用することができる、トークンなどの許可データを含めることができる。要求は、ターゲットROおよびターゲットROの要求の回送者としてのSDMが、受け取り側のドメインの完全性をチェックするために必要とする受け取り側のドメインのプラットフォーム構成レジスタ(PCR)の範囲も含むことができる。この要求は、
Def) Package_8b(i)=Request_for_Attestation||nonce_8b(i), i=1,2, ...,N
SDM→TDDomain(i):
Package_8b(i)||[SHA−X(Package_8b(i))]Ksign_SDM 式15
として表すことができる。
NをSDMによるPCR値の収集元のドメインの数として、domain(i),i=1,2,...,Nと表されるドメインのそれぞれは、最初に、アテステーションの要求の中の許可データをチェックし、次いで、アテステーションの要求において指定されているようなPCRの範囲のPCR値をフェッチする。このオペレーションは、
Def) Package_8c(i) =
PCRの指定された範囲の値||nonce_8c(i),i=1,2,..,N
TDDomain(i)→SDM:
Package_8c(i)||[SHA−X(Package_8c(i)||nonce_8b(i)]Ksign_TD_Domain(i) 式16
として表すことができる。
SDMは、THSMプラットフォーム完全性アテステーション(TPIA)を実行して、全てのアテステーションを連結し、それに、署名鍵で署名することができる。これは、
Def) TPIA=連結{Domain(i)からの署名されたPCR値},i=1,2,...,N 式17
と表すことができる。
TPESの準備のため、SDMは、DMのドメインから取得することができるTHSM HWおよびSW構成およびバージョン番号、BIOS構成、プラットフォーム上のドメインの個数、現在のドメインのために使い切ったメモリなどの総プラットフォームリソース、既存のもしくは新規のドメインのさらなる構築もしくは拡張のため残してあるプラットフォームリソース、ドメインの名前、またはそれらの所有者の、NAIなどの、名前もしくはID(各ドメイン所有者によって許可されている場合)、日時、または上記の環境情報がSDMによって収集された場合に日時ではなく利用可能であれば単調カウンタ値、他の任意の関連する情報など、TDDM、TDDO、およびTDDomains(i)から収集する情報を連結することによってTPESを生成することができる。この要求は、
Def) TPES={収集された情報} 式18
で表すことができる。
SDMは、TPIAおよびTPESに署名し、これらをTD*RO_Targetに回送することができる。SDMは、SCARDを調べることができなかった場合にDOが手つかずのTD*RO_Targetに依存する必要のないように署名されたSCARDを含めることもできる。SCARDを、TPIAおよびTPESとともに、ROに送信することができ、これにより、ROは、SCARD、TPIA、およびTPESを調べた後に所有権取得を進める決定を下すことができる。このメッセージングは、
SDM→TDRO_Target:
SCARD||nonce_8fb||[SHA−X(SCARD)||nonce_8fb)]Ksign_SDM TPIA||Concatenation{nonce_8c(i)}[SHA−X(TPIA)||Concatenation{nonce_8c(i)}]Ksign_SDM,
TPES||nonce_8f||[SHA−X(TPES||nonce_8f)]Ksign_SDM
OR
SCARD||TPIA||TPES||[SHA−X(SCARD||TPIA||TPES||nonce_8f)]Ksign_SDM 式19
として表すことができる。
SDMからTPIA、TPESおよびSCARDを受け取った後、TD*RO_Targetは、SDMの公開署名鍵でチェックすることによってそれらの完全性をチェックすることができる。次いで、TPIA、TPES、SCARD、ユーザが望むサービスを示す目的情報要素(P)、および所有権取得メッセージの要求(request_TO)をMEに送信することができる。RTOプロセスが、完全なTSIM能力のために用意されなければならないドメインに対するものである場合、TSIM機能に関する署名付き証明書(CertTSIM)を作成し、上記のパッケージとともに送信することもできる。
TSIM機能に使用される証明書は2つ以上ありうる。1つは手つかずのTSIM機能に対するもの(CERT*TSIM)であり、ほかは、完全にインスタンス化または更新されている機能に対するものである。手つかずのTSIM機能の証明書は、DMに対する証明書構造にモジュール方式で埋め込むことができ、例えば、DMからの機能である手つかずのドメイン内にプラグインとして差し込むことができる。
TDROが前もって少なくとも1つのRTOを通った後にROがRTOプロセスを実行する場合、これはもはや、CERT*TSIMを送信する必要がなくなるが、それは、この証明書が手つかずのドメインとともに使用する場合にしか適さなくなるからであり、TDROはもはやそうでなくなっている。したがって、この場合、ROは、更新された証明書CERTTSIMを送信することができる。
コンテンツは、TD*RO_Targetによって使用される前に、手つかずのTD*RO_TargetがロードされたときにターゲットROがすでに知られている場合に、例えば証明書転送によって、または事前構成によってすでに利用可能になっていると思われる、ターゲットROの公開鍵(K_Target_RO_pub)で暗号化することができる。TSIMは、署名鍵K_TSIM-Signとともに事前に用意することができる。この秘密署名鍵の公開鍵は、ターゲットROに事前に配布することができる。IDMEは、ME IDを安全に保持するTHSM DMドメインTDDMからTD*RO_Targetが取得するMEのIDである。これは、
Def) Package_9=
SCARD||TPIA||TPES||P||Request_TO||CertTSIM||IDME||nonce_9
TD*RO_Target→ME:
{Package_9}K_Target_RO_Pub||[SHA−X(Package_9)]K_TSIM-SIGN 式20
として表すことができる。
第3の実施形態を参照すると、値MPIAおよびMPESをメッセージに追加することができることがわかる。MPIAは、MTEによってコンパイルされた構成データ(MPID)に基づきTHSMにおいて計算されたダイジェストを含むことができる。このダイジェストのアテステーションは、構成ファイル内にすでに存在しているか、またはDMとのリアルタイムの通信を介して配信された取得済みの認定された基準を使ってチェックする場合にのみ行うことができる。完全性および環境情報に対するRO要求によれば、式20は、SDMがMPIDおよびMPESを正常に受信したことを示す単純な指示を含むことができる。これは、
Def) Package_9=
SCARD||TPIA||TPES||MPIA||MPES||P||Request_TO||CertTSIM||IDME||nonce_9
TD*RO_Target→ME:
{Package_9}K_Target_RO_Pub||[SHA−X(Package_9)]K_TSIM-SIGN 式21
として表すことができる。
MEは、上記のメッセージ全体をROに転送することができ、これは
ME→ターゲットRO:
{Package_9}K_Target_RO_Pub||[SHA−X(Package_9)]K_TSIM-SIGN 式22
として表すことができる。
第3の実施形態を参照すると、メッセージは、MPIAおよびMPESを含むことがわかる。
ROは秘密鍵KTarget_RO_priv.を使用してPackage_10を復号し、MEのIDをチェックし、メッセージを解釈する。ROは、SCARDを解釈して、SDPからのそれらの条件に「合意」できるか調べることができる。ROがSCARDに合意した場合、例えば、手つかずのTD*RO_Targetからの値TPIA を解釈して、サービス資格証明または構成制御がターゲットROのドメインTD*RO_Targetに与えられる前に初期TSIM状態全体を表すことができる。値Pは、ユーザが望んでいるサービスを示すものとして解釈することができる。TSIM対応TD*RO_Targetの場合にMNOとすることもできる、ターゲットROは、TTPと無関係に取得した参照完全性基準(RIM)値(RIMRO)と比較することによってTPIAに示されているように注目するドメインの完全性を検証することができる。
MNOは、例えばTTPにWTRU/THSMの供給者によって提供される証明書を通じてTPIAの予想値を知る機能を有するものとしてよい。第3の実施形態を参照すると、MPIAおよびMPESの予想値は、THSMによってそれが信頼に足るかどうかのアテステーションが行われている場合に、MTEが信頼できるエンティティであるという事実によって可能にされる認証プロセスを通じて前もって知ることができることがわかる。
ターゲットROは、受け取ったTPESを調べ、ROがRTOプロセスをさらに進めることができるという背景状況において例えばTPESによって表されるような「周囲システム環境」がターゲットROにとって「合意可能」であるTHSMシステム内にTD*RO_Targetがあるかどうかを評価することができる。
TPIA、TPES、目的P、Request_TO、ならびに第3の実施形態を参照して、MPIAおよびMPESをチェックした後、MNOなどのターゲットROは、ターゲットROによって「所有権が取得される」ことを要求している手つかずのTD*RO_Target、さらには、TD*RO_Targetを含む、全体としてTHSMが、RTOプロセスについてターゲットROをさらに進行させるのに、またTD*RO_TargetがターゲットROとインタラクティブにやり取りしていくつかの事前に指定されている基本サービスを提供することをターゲットROに認めさせるのに十分「信頼に足る」と判定することができる。
TD*RO_Targetの所有権取得を実行して、ドメインが後で鍵、より完全な構成、パラメータ、および実行ファイルをダウンロードしてインストールし、基本的な「手つかずの」状態が許容する以上の機能を持たせ、またターゲットリモート所有者(RO)によって請求または所有され、管理されるようにするために、ターゲットROは、実行ファイルを含みうる構成信号(CONFIG)を送信することができる。ROは、TDRO_Targetが受け取ったCONFIGに従って構成、パラメータ、および実行ファイルをインストールする場合にインストール後状態と一致しうる、RIMTSIMと称するTSIMに対するRIMも送信する。RIMTSIMは、TD*RO_Target上のセキュアメモリ内に格納することができ、また将来のブート時にTSIM機能の完全性をチェックするために使用することができる。採用されるセキュリティ対策さらには他の構成上の課題を指定する、ドメインポリシー(DP)をトランザクションに含めることができる。
RO固有のドメインポリシー(DP)は、SDMによって保持され、THSM上の特定のROによって所有される1つまたは複数のドメインを構築し、管理するためのプランを表すシステム全体のドメインポリシー(SDP)と異なっていてもよい。RO固有のDPは、その特定のドメインに固有であり、それに限定されるドメイン内アプリケーションおよびセキュリティ対策のみに適用されるポリシーまたはプランを含むことができる。
いくつかのROは、DPがTHSM上で他のROが構築または管理されることに「合意可能である」ものに関して制限を課す規定も含むようにDPを作成することができる。例えば、モバイルネットワーク通信事業者(MNO_A)は、THSM上の他のドメインのうちのいくつかのドメインの状態および性質に関するDPMNO_Aにおいて指定されている条件のうちのいくつかが十分に満たされていないことが判明した場合に、そのターゲットドメイン(TDMNO_A)が、DPMNO_Aをダウンロードしインストールした後に、例えば、そのサービスもしくは活動に対する一組の制約条件を適用されるように、自分のDPMNO_Aを作成することができる。例えば、MNOは、DPMNO_Aを実装することができ、これにより、TDMNO_Aは、TDMNO_AがTHSM内のより大きな環境を調査した後にアクティブ化された自らのTSIM機能を持つ他のMNOのドメインが同じTHSM上にインストールされアクティブ状態にあることを見いだした場合に、そのTSIM機能を無効にする。
TD*RO_Targetは、Pにおける要求されたサービスに対応する形でそれ自身を構成することが必要になる場合がある。例えば、ROは、MEに応答を送信することができ、メッセージの機密は、公開鍵KTSIM_Pubを使用して保護される。MEは、このメッセージをTHSM上のTD*Target_ROに転送することができる。CertROはターゲットROの公開鍵K_RO−privを含むものとしてよい。ROは、このときに、TSIMの参照完全性基準(RIM)を送信することができる。ROの応答は、
Def) Package_10=
{CONFIG,DPRO,IDRO,RIMTSiM}KTSIM-Pub||CertRO||CertTSIM||nonce_10
ターゲットRO→ME:
{Package_10}K_RO-Priv||[SHA−X(Package_13||nonce_9)]K_TSIM-SIGN 式23
ME→TD*Target_RO:
{Package_10}K_RO-Priv||[SHA−X(Package_13||nonce_9]K_TSIM-SIGN 式24
として表すことができる。
TD*RO_Targetは、公開鍵KTSIM-Privでメッセージを復号し、CAでその証明書をチェックした後にCertROにおいて公開鍵KRO_pubを使用してRO署名を検証することができる。これは、TSIMアプリケーションの受け取った参照完全性基準RIMTSIMを安全に格納することができる。これは、IDROからのROのIDをチェックし、次いで、ROのポリシーDPROをチェックし、CONFIGの構成およびインストールの残り部分を続けることができるかどうかを決定することができる。TD*RO_Targetは、CONFIGを介して再構成を実行し、「完了」ドメイン状態に到達することができ、次いで、セルフテストを実行しTSIM機能の測定された基準がネットワークによって通信され、RIMTSIMにおいて表されているものと一致するかどうかを判定する。ドメインTDRO_Targetは、これで「完了」となり、もはや「手つかず」ではなくなり、したがって表記中のアスタリスク*を取り外す。これは、
TD*Target_R:DPROをチェックし、RIMTSIMを格納し、CONFIGをインストールする
→ TDTarget_RO:ROのドメインは「完了」である 式25
として表すことができる。
完了したドメインTDTarget_ROは、「RTO成功およびドメイン完了」ステータスメッセージをMEに送信し、これはターゲットROに回送することができる。これは、
Def) Package_11={「ドメイン完了」||IDRO_Target}K_RO-Pub||nonce_11
TDTarget_RO→ME:
Package_11||[SHA−X(Package_11||nonce_10)]K_TSIM-SIGN 式26
として表すことができる。
適宜、MEは、電話の登録および資格証明のロールアウトが現在可能な状態にあることを示す、例えばWTRUの画面に表示されるステータスメッセージをユーザに送信することができる。
MEは、プラットフォームの再構成が正常に完了し、TSIM資格証明の登録をすることが可能な状態であることを示すステータスメッセージをROに回送することができる。TDRO_Targetは「THSM_TDRO_LOAD_COMPLETE」状態に至っている。このメッセージは、
ME→ターゲットRO:
Package_11||[SHA−X(Package_11||nonce_10)]K_TSIM_SIGN 式27
として表すことができる。
このRTOプロトコルは、THSMの所有者またはユーザとしての加入者を、加入サービスを提供する3G UMTSネットワーク通信事業者に登録するためのプロトコルの先行プロトコルとして使用され、また共有鍵Kおよび加入者識別IMSIのダウンロードおよび提供を含む、認証および鍵照合(AKA)の資格証明のダウンロードおよび提供を行うための後続プロトコルとしても使用されうる。
公開−秘密鍵セットに対する証明書CertTSIMおよびCertROは、これらが使用されるメッセージに入れて配信することができる。あるいは、ROのドメイン(TDRO)およびROは、信頼できる第三者から各証明書を取得することができる。この取得は、
TTP→ME→TDRO:CertRO
TTP→RO:CertTSIM 式28
として表すことができる。
別の代替的形態では、ROの証明書CertROは、ネットワークからMEに配信することができ、THSMの証明書CertTSIMは、これらが使用されるメッセージの配信の前にMEからネットワークに配信することができる。したがって、通信は、本明細書で説明されている暗号化されたメッセージの前に送信することができ、これらの通信は、
ME→RO:CertTSIM(ステップ9のメッセージが送信される前)
RO→ME:CERTRO(ステップ13のメッセージが送信される前) 式29
として表すことができる。
これらの代替的証明書配信方法のそれぞれについて、エントリIDは、公開暗号鍵が使用されるメッセージに添付することができる。
別の代替的形態では、公開鍵の代わりに対称鍵を使用することで、メッセージの機密性を保護することができる。それぞれの場合において、送信者は、例えば疑似乱数生成器(PRNG)を使用して対称鍵Ksを生成し、公開鍵ではなく、この鍵を使用して、メッセージの機密性を保護することができる。対称暗号鍵は、公開鍵で保護されている暗号化されたメッセージとともに、受信者に送信することもできる。したがって、受信者は、秘密鍵で鍵Ksにアクセスし、次いでそれを使用してメッセージを復号することができる。
第2の実施形態を参照すると、THSMおよびMEは、第1の実施形態のものと異なる場合のあることがわかる。THSMは、MEそれ自体またはMTEなどのME内の信頼できるエンティティの代わりに、MEがブートするときにMEのコードの一部または全部の完全性チェックを実行するように構成されうる。適宜、THSMは、MEのブートコードの一部または全部を格納することもできる。THSMは、MEの完全性のアテステーションを外部のエバリュエータに対して行うようには構成することができない。これは、ブート時にMEコードの完全性の「ローカル」チェックを実行するように構成することができる。
MEに対する完全性値は、ブートアッププロセスで使用することができ、RTOプロセスでは使用することができない。MEのセキュアブートの結果得られるMEコードおよび構成状態を表す、meas_MEで表される、MEの完全性測定は、THSMのDMのドメインTEDMによって行うことができる。THSMのTDDMは、meas_MEの有効性をチェックすることができるが、プラットフォームアテステーションに組み込むことはできない。
第4の実施形態を参照すると、MEは、例えばTCG MPWGの意味で、信頼できるMEであるものとしてよいことがわかる。MEは、モバイルトラステッドモジュール(MTM)を備えることができ、またMTMをストレージ、報告、測定、検証、および強制のための信頼の基礎を与える信頼点として有するので信頼されることができる。
図4および4Aは、リモート所有権取得プロセスの例示的な呼流れ図を示している。例えば、図4および4Aは、ME402、TDDO404、SDM406、TD*Target_RO408、およびターゲットRO410のうちの1つまたは複数の間の例示的な呼を示している。図4および4Aの矢印は、発呼側/着呼側を表すものとしてよい。
図2および図3に示されているように、SDMは、THSMに置かれているシステム全体のドメインマネージャを備え、DOの機能の一部を提供することができる。SDMは、デバイス内のすべてのドメインセットアップの監視および調整を行い、そのような全てのドメインが、SDPに準拠して、またドメイン固有のポリシーに従って、そのようなポリシーにおける競合を他のドメインのDOおよびROの代わりにSDMによる仲裁で解消しようとする限りにおいて、動作し、互いにインタラクティブにやり取りすることを確実にするものとしてよい。TDDOは、THSMにおける必須のデバイス所有者ドメインを含むことができる。TDDOは、SDMを含み、したがって、システムレベルのドメインポリシーを維持することができる。MTEは、ME側に対するポリシーマネージャMEPDMを含むことができる。MEPDMは、ME上でポリシーマネージャ機能を実行することができるが、THSMにおけるSDMの監視を受けるものとしてよい。ME*Target_ROは、許可されたリモートの所有者によるリモートの所有権に対して手つかずのドメインのセットアップを含むことができる。ターゲットROは、ME*Target_ROの所有権を要求するリモートの所有者を含んでいてもよい。
MEは、認識されたリモートの所有者によるME上のドメインのリモート所有権取得がサポートされるように完全なMTM機能を持つものとしてよい。第1の実施形態を参照して説明されているRTOのものと同様に、これらは、本質的に、THSMおよびMEの両方の同じリモートの所有者によって所有されるドメインに対してMEPDMの上でSDMによって行われる最終的なポリシー制御によって異なる。したがって、THSM上でドメインをさらに所有する同じリモートの所有者によって所有されるMEドメインの形成および管理は、SDMのポリシーに適合する方法でなされなければならない。
図4をなおも参照すると、ベースコードブートは、符号41でME402によって実行されうる。符号415で、THSMは安全にブートすることができる。THSMは、SDMが含まれる、DOのドメインをロードすることができ、SDMは、1)ドメイン構築に利用可能なリソース、および/または2)ユーザへの受け入れ可能なドメインのリストを備えることができる。符号42で、THSMはそのブートを完了することができる。符号425で、MEはそのブートを完了することができる。符号43で、MEはそのブートが完了していることを示すことができる。このプロセスにおいて、DMのドメインが構築され、オプションのユーザドメイン(MEu)も構築され、また利用可能なリソースがチェックされる。DMのドメインは、MEデバイスに対するドメインポリシーの初期構成および仕様を提供するMEPDMを備えることができる。MEDMの事前構成により、このポリシーは、MEドメインとTHSMドメインとの間の、共通のリモートの所有者とともに、THSM上の一方のドメインとME上の他方のドメインなど、これらのドメインに対するポリシーに関してSDPのものと整合するようにされうる。
図4をなおも参照すると、事前構成されたドメインを持つMEは、符号431で「ブート完了」メッセージを送信し、RTOを開始することができることがわかる。このメッセージは、DMドメインポリシーおよびMEにおける利用可能なリソースに関する明示的な情報を含みうる。符号44で、ターゲットドメインプランを含む、RTOを開始する要求が送信されうる。符号455で、RTO開始要求を受け入れるか、または拒絶する決定を、TD*Target_RO408側で下すことができる。符号45で、RTOを開始するかどうかを示すメッセージを送信することができる。あるいは、符号456で、RTOは、TD*Target_RO408から開始することができる。符号451で、TD*Target_RO408は、「RTO最終ドメインプランを開始する意図」を送信することができる。
SDMは、THSMのシステム全体のドメインポリシー(SDP)を評価し、どのような制約をMEドメインに課すか、または割り当てるかを決定することによってMEブートメッセージに応答することができる。これらのポリシー制約条件は、MEおよびTHSM上で、どのようなドメインがそれらの関連するリモートの所有者に従って許容可能であるかを決める条件を含むものとしてよい。SDMは、リモートの所有者が気づいているものを含めて、THSM上にドメインを有する同じリモートの所有者によって所有されるドメインに対してMEによる使用が許されるシステム全体のリソースを決定することができる。MEPDMは、式7のメッセージを介してこの情報を受信することができる。SDMは、そのベースポリシーへのポリシー制約条件およびそのリソースリストへの許容可能なリソースを含むこともできる。MEPDMが情報を受け取った後、これは、ME上のリソースおよびドメインの管理に関する決定を下し、強制することに関して、そのような全ての決定についてSDMから許可を取得する必要なしにいくつかの特権を行使することができる。
図4をなおも参照すると、プロセスは符号465に続くことがわかる。符号465で、SDP、利用可能なリソース、および/または受け入れ可能なドメインおよび/または状態をチェックすることができる。符号46で、「開始OK」信号を送信することができる。符号47で、TPIA、TPES、MPID、およびMPESの要求を送信することができる。符号475で、SDM406は、例えば、ドメイン毎にPCRの範囲にわたって既存のドメインから完全性アテステーションを収集/連結し、および/またはTPES情報を収集および/または連結することができる。
符号471で、MPIDおよびMPESの要求を送信することができる。符号476で、MPIDおよびMPESの要求に対する応答をMTE側で処理することができる。符号48で、MPIDおよびMPESを信頼の証明とともに、署名鍵を付けて送信することができる。符号481で、TPIA、TPES、MPID、およびMPESをSDM406からTE*Target_RO408に送信することができる。符号485で、THSMは、MPID(未加工データ)からのダイジェストMPIAを計算し、MPIAをチェックすることができる。受け入れ可能である場合、ダイジェストMPIAをROに送信することができる。符号49で、TPIA||TPES||MPIA||MPES||目的||RTOに対する要求を送信することができる。
図4Aを参照し、RTOプロセスを続けると、符号410で、TPIA||TPES||MPIA||MPES||目的||RTOメッセージがターゲットRO410に送信されうることがわかる。符号418で、ターゲットRO410は、例えば、TPIA、TPES、MPIA、MPES、および目的をチェックすること、RIMTDROに対して手つかずのドメインが信頼に足るものかどうかを判定すること、DPの受け入れ可能性をチェックすること、または完了ドメイン状態を構築するCONFIGを作成することのうちの1つまたは複数を実行することができる。
上記の代替えとして、TD*Target_RO408がMPIAおよびMPESの代わりにMEが信頼に足るものであることを単純に示す情報をSDMに要求するが、その場合、SDMは、TPIA、TPES、およびMEの信頼性指示を与える。しかし、SDMは、それでも、MTEにMPIAおよびMPESを要求し、受け取る。
図4aをなおも参照すると、符号411で、メッセージCONFIG||DP||RIMTDRO||ROが送信されうることがわかる。符号412で、CONFIG||DP||RIMTDRO||ROメッセージを転送することができる。符号428で、ドメインを構築し、構成して、完全性をRIMTDROに対してチェックすることができる。それに加えて、TD*Target_ROの所有権を取得し、そうして、TDTarget_ROに変換することができる。符号413で、ドメイン完了メッセージを送信することができる。符号414で、ドメイン完了メッセージを転送することができる。
図5および5Aは、完全なアテステーション(例えば、第4の実施形態に関係する)を伴うリモート所有権取得プロセスの例示的な呼流れ図を示している。例えば、図5および5Aは、SDM502、TDDO504、MEPDM506、ME*Target_RO508、およびターゲットRO510のうちの1つまたは複数の間の例示的な呼を示している。図5および5Aの矢印は、発呼側/着呼側を表すものとしてよい。符号51で、ベースコードブート完了メッセージを送信することができる。それに応答して、符号515で、THSMは、SDMを含む、DOドメインを安全にブートし、ロードすることができる。符号52で、THSMブート完了メッセージを送信することができる。それに応答して、符号525で、MEは安全にブートすることができ、これは、MEPDMが含まれる、DMドメインをロードすることと、さらには利用可能なリソースをチェックすることを含みうる。MEPDMは、SDPおよび利用可能なリソースと一致するドメインポリシーを指定する初期構成を行うことができる。符号53で、DMのドメイン(ポリシー情報)およびME内の利用可能なリソースを含む、MEセキュアブートが完了したことを示すメッセージを送信することができる。符号531で、「MEブートが完了」メッセージをSDM502に転送することができる。符号535で、SDM502は、例えば、システム全体のポリシーを評価し、MEに対する許容可能なドメイン、リソース、およびポリシー制約条件を決定することができる。符号54で、ドメインポリシー制約条件および/または許容可能なリソースに関する情報を与えるメッセージを送信することができる。符号545で、ポリシー制約条件をベースポリシーに付加し、必要ならば、リソースリストを修正することもできる。
図5および5Aの要素55〜511は、図4および4Aに示されているような要素45〜411と類似のものであってよい。値MPIAおよびMPESの評価は、式14から19までの評価と類似するものであってよい。MEは、MTM対応であり、ただ単に未加工データMPIDではなく、ダイジェストMPIAを単独で計算するように構成することができる。SDMによって伝えられる更新されたポリシー制約条件は、禁止されたドメインまたはドメインポリシーが実現されないようにチェックすることができる。ポリシーのチェックおよび評価は、MEPDMによって実行されうる。
符号55で、ターゲットドメインプランを含みうる、RTOを開始する要求が送信されうる。符号555で、MEPDM側で、RTO要求を受け入れるか、または拒絶する決定を下すことができる。符号551で、RTOを開始するかどうかを示すメッセージを送信することができる。代替的形態では、符号556で、RTOを開始する意図がMEターゲットから始まるものとしてよい。符号56で、「RTOを開始する意図」メッセージを送信することができる。符号565で、1)拡張ドメインポリシー、および/または2)拡張ポリシーによる利用可能なリソース、受け入れ可能なドメイン、および状態をチェックし、および/または評価することができる。符号561で、RTOを開始することが受け入れ可能であることを示すメッセージを送信することができる。符号57で、MEドメインセットからの、MPIAおよびMPESの要求を送信することができる。符号575で、ドメイン毎のPCRの範囲にわたる既存のドメイン(MPIA)からの完全性アテステーションの収集および連結を、MPES情報の収集および連結とともに実行することができる。符号58で、MPIAおよびMPESを送信することができる。符号59で、MPIA||MPES||目的||RTO要求を送信することができる(メッセージ完全性および機密性は、認証された公開/秘密鍵で保護されうる)。符号595で、ターゲットRO510は、例えば、MPIA、MPES、および目的をチェックすること、RIMTSIMに対して手つかずのドメインが信頼に足るものかどうかを判定すること、DPの受け入れ可能性をチェックすること、または完了ドメイン状態を構築するCONFIGを作成することのうちの1つまたは複数を実行することができる。符号514で、メッセージCONFIG||DP||RIMTSIM||ROを送信することができる。符号515で、ドメインを構築し、構成して、完全性をRIMTDROに対してチェックすることができる。それに加えて、ME*Target_ROの所有権を取得し、そうして、METarget_ROに変換することができる。符号511で、ドメイン完了メッセージを送信することができる(署名付き、完全性保護)。MEは、ターゲットROと直接通信することができ、したがって、図3および3Aに示されているようなメッセージ転送は、使用されず、メッセージの数を減らすことができる。手つかずのエンジン信頼性検証に対するRIM証明書に関するものとともにMEとターゲットROとの間のメッセージングにおける公開/秘密鍵の交換に必要な証明書に関する詳細は、図5に示されていない。
図6は、THSMの例示的な状態定義、遷移、および制御点定義を示している。例として、特許文献1において定義および基本機能が定義されている、M2M通信識別モジュール(MCIM)のライフサイクルは、本明細書で定義されている。THSMは、MCIMの、状態定義および遷移を含む、機能性および特徴を改善し、一般化することができる。
状態601で、THSMは、プレブート状態にあるものとしてよい。第1のユーザがTHSMの電源をオンにし、THSMは安全にブートし、THSMは状態602にあるものとしてよい。状態602で、DMおよびDOは、手つかずの状態で存在することができる。DMドメインを事前構成ファイルから構築することができ、THSMは状態606にあるものとしてよい。状態606で、THSMは、ポストブート2状態に入り、TDDMがロードされうる。状態606からは、DOドメインを事前構成ファイルまたはダウンロードファイルから構築することができ、THSMを状態605に残す。状態605で、THSMは、ポストブート3状態に入り、そこでTDDOが構築されうるが、TDUまたはTDROは、ロードできない。状態605から、DOドメイン(SDM)は、ユーザのドメインをロードし、THSMを状態604に残すことができる。状態604で、THSMは、ポストブート状態2aに入り、そこでTDUがロードされるが、ROドメインは、ロードできない。状態605から、手つかずのROドメインを、SDPに基づいて構築し、THSMを状態707に残すことができる。状態707で、THSMは、ポストブート状態7に入り、そこでTDROおよびTDDOがロードされているが、TDUは、ロードできない。状態607から、TDDO(SDM)は、TDUをロードし、THSMを状態608に残すことができる。状態608で、THSMは、DO、DU、およびROドメインをロードしておくことができる。
状態601から、ユーザは電源をオンにし、THSMは安全にブートし、THSMを状態603に残すことができる。状態603で、THSMに、格納されている構成をロードすることができ、そこでは、格納されている構成は一番最近に電源をオフにする前の構成であった。状態603から、構成を変更するポストブートトランザクションを実行し、THSMを状態610に残すことができる。状態610で、THSMは、1つまたは複数のすでにアクティブの状態が非アクティブになる。状態603から状態610に到達するプロセスと同様に、THSMは状態609にあってよく、そこで、THSMは1つまたは複数のアクティブなドメインを有する。状態609から、構成変更イベントの結果、遷移が生じて、THSMを再び状態610に残すことができる。
状態604、605、607、および608で、THSMは、新規ポリシーおよび/または実行ファイルもしくは非アクティブ状態への遷移で再構成することができる。それに加えて、状態605で、SDPを格納することができる。
ドメイン管理の第1の方法では、ドメイン所有者からのポリシー、つまり、システム全体のドメインポリシー(SDP)は、非常に制約的であり、また「静的」であり、新規ドメイン活動または目的に関して厳しいルールを有している可能性がある。これらのポリシーは、新規ドメインエントリまたは既存のドメインが更新される毎にROと通信する必要性を軽減する傾向があると思われる。
ドメイン管理の第2の方法では、SDPは、制約が少なく、活動および目的に関してより柔軟に対応できる。すべての新規ドメインエントリおよびすべてのドメイン変更が既存のドメイン所有者に報告されうる。この結果、プラットフォームとROとの間の最初のネゴシエーションおよびその後のネゴシエーションが実行されうるポリシー強制のより動的なシステムが得られる。
ドメイン管理の第1の方法を参照すると、SDPは、事前構成リスト内で例外なく許可されているドメインを指定することができる。このリストは、ROの種類および(種類毎に)許可される数に関する情報を含むことができる。このリストは、ドメインがセットアップされた後ROが提供することができるサービスの種類も含むことができる。RO候補は、リストで示されている条件を満たすROであるものとしてよい。ROは、リストおよびポリシー制約条件などの条件に関して、例えば式9に示されているような、RTOプロセスの一部としてアラートされうる。ROは、SCARDを受け取った後、注目しているプラットフォームまたはデバイス上のステークホルダーになりたいかどうかを独立して決定することができる。ROに送られる条件は、ドメインの種類およびその目的を含むことができるが、他のROの素性を保護するために、他のROのリストの実際の名前については含まないようにできる。ROがRTOを完遂することを決定した場合、ポリシーからの逸脱がこのRO、またはプラットフォーム上で現在アクティブである他のRO、または将来アクティブになる可能性のある他のROによって許されないことは確実であるものとしてよい。その結果、ROは、実行される可能性のあるその後のRTOにアラートされる必要はなく、またアラートされることもない。
ドメイン管理の第2の方法を参照すると、どのようなリモートの所有者が特定のROの種類を識別することなく許可されるかなどの比較的広範な制約条件のみ、またROからSDMへのより多くの情報の要求またはいくつかのネゴシエーションなどの、より多くのインタラクティブなやり取りを許すポリシーを、RTOプロセスにおいて遂行することができることがわかる。ドメイン構成が変更されるときに、SDMとすべてのROとの間に進行中の協力もありうる。したがって、最初の、さらにはその後のネゴシエーションは、RO/SDMの動力学の一部として実行されうる。
RTOプロセスの一部として、ROは、TPIA、TPES、およびSCARDなどの、必要とされる、アテステーションおよびポリシー条件の情報を与えられ、これは、構成およびその信頼性に関する、第1の方法の場合と比較してより一般的な情報を含みうる。既存のドメイン構成に基づき、ターゲットROは、RTOを継続するかどうかを決定することができる。ターゲットROが所有権取得に反対する決定を即座に下さない限り、SDMとのネゴシエーションプロセスは続きうる。例えば、SDMは、ターゲットROのドメインがアクティブである間アクティブでありうるドメインタイプおよびアテンダントサービス、またはそれが反対する種類のドメインがアクティブになろうとしている場合の続けるべき手順をターゲットROに要求することができる。ROは、例えば、いくつかの他のドメインタイプまたはいくつかの他のROが所有するドメインさえもアクティブになるか、またはアクティブになろうとしているときに自ドメインが非アクティブにされることを要求する場合があるか、またはアクティブのままであるが、容量または能力を減らした状態にすることを要求する場合もある。SDMは、アラートすべきイベント発生をROに要求することもできる。そのようなイベントは、アクティブまたは非アクティブになる、それが反対する、ドメインタイプを含む可能性がある。ROは、いくつかの他の所有者によって保持される他のドメインタイプまたはドメインが、自ドメインがアクティブである間、一切の活動から完全にブロックされることを要求することもできる。
SDMは、そのような条件を受け入れるか、または拒絶する決定をすることができる。広範な一組のポリシー要件で動作するけれども、SDMは、ROからの要求を受け入れることが「静的な」システムドメインポリシー(SDP)の契約内示書にそのまま適合しうるかどうかを決定する自由度と意味論的な能力を有することができる。
図7は、ROドメインが達成しうる例示的な状態および動的に管理された環境において遷移が発生しうる条件を示している。状態701で、ヌル状態が存在する可能性があり、例えば、ROは構築されえない。状態701から、手つかずのROドメインを、SDPに従って構築し、ROドメインを状態702に残すことができる。状態702から、ROがTPIA、TPES、およびSCARDを取得することを含む、RTOプロセスを実行することができる。さらに、ROは、RTOの条件を受け入れて、ROドメインを状態703に残すことができる。状態703から、新規アクティブドメインとのポリシー競合があると判定されることがあり、それに応答して、ROドメインの機能を低減するか、または非アクティブにし、ROドメインを状態704に残す。また状態703から、ROドメインは更新されたポリシー/構成変更を受け取り、その結果、ROドメインは修正された構成および/または更新されたポリシー制約条件を有することになる。状態706から、新規アクティブドメインとのポリシー競合があると判定されることがあり、それに応答して、ROドメインの機能を低減するか、または非アクティブにし、ROドメインを状態704に残す。また状態703から、新規ソフトウェアコンポーネントを、ダウンロードまたはRTOを介して導入することができ、その結果、ROドメインの状態が修正/拡張され、ROドメインを状態705に残す。状態705から、新規アクティブドメインとのポリシー競合があると判定されることがあり、それに応答して、ROドメインの機能を低減するか、または非アクティブにし、ROドメインを状態704に残す。
符号711に例示されているように、702、703、704、705、または706のROドメインはヌルになり、例えば、DO、ROなどによって削除されうる。符号741に例示されているように、非アクティブ/低減機能のROドメインは、状態703、705、または706に、例えば、ROドメインを状態704に移動させた競合を解決することによって移動することができる。符号751に例示されているように、状態705にあるROドメインは、状態703、704、または706に移動することができる。符号761に例示されているように、状態706にあるROドメインは、状態703、705、または706に移動することができる。
ROドメインの管理に関して、動的ドメイン管理の一部として許されうるものは、イベントが展開するときに変更する要件をネゴシエートすることに対するものである。例えば、ROは、以前に異議のあった、別のROによって提供される特定のサービスが、もはやそのサービスと競争する必要がなくなったと判断された結果、現在では許可可能であると決定することがありうる。時間の経過によるビジネスモデルの変化は、RO候補による戦略およびポリシーのネゴシエートに影響を及ぼしうる。動的ポリシー構造を採用するSDPは、そのような戦略変更に対応するようになされうる。
限定はしないが、自動支払いサービスと組み合わせたM2Mジオトラッキングなどのサービスでは、優先ローミングパートナーシップ、またはROのクローズドグループが形成されうる。このようなグループ化されたサービスは、類似のまたは異なるサービスパートナーを提供する異なる通信事業者が互いに提携する場合に、優先するクローズドグループに至る可能性がある。サービス、通信事業者、またはその両方の優先グループは、デバイスユーザへのバンドルサービスまたは抱き合わせ販売として提供されうる。
第1の例では、パッケージは、地球を巡る間に追跡可能である。数百万のこのようなジオトラッキングデバイスが利用される可能性がある。パッケージが大陸を横断する際に、異なる国の異なる通信事業者による接続性を提供される。したがって、接続するために、ユーザは、複数のローミングプロファイルを使用する必要がある場合がある。これらのローミングプロファイルは、さまざまなリモートの通信事業者にまたがっており、それぞれのドメインがリモートの通信事業者によって所有され管理されているのでドメイン間ポリシーとして管理される。ポリシーは、ローミングベースのソリューションをサポートする代わりに新しいサービスプロバイダへの完全な引き継ぎをサポートするよう強制することもできる。
第2の例では、スマートメータリング事業者とジオトラッキング事業者との間の提携が説明される。これらのドメインは、異なる通信事業者によって所有され運営されうる。事業提携またはユーザの好みにより、ドメインを組み合わせてジョイントプロファイルをサポートすることができる。労力、ストレージ、または駐車などの、リソースの利用度に基づく課金の場合、自動支払いサービスをパッケージの追跡と平行して使用することができる。共存するサービスが独立したカテゴリに分類されるこのような事例では、ドメイン間ポリシー管理のサポートを使用することができる。
ドメイン間ポリシーマネージャ(IDPM)は、ドメインのグループ挙動を決定するポリシーを管理することができる。ドメイン間ポリシー(IDP)は、RTOプロセスにおいてそれぞれのROによってダウンロードされうる。IDPは、それぞれのROによって署名された証明書によって認証されうる。これらの証明書は、IDPとともに発行されうる。あるいは、これらのポリシーは、外部サービスディーラーによって認定され、ダウンロードされうる。優先事業者リストを作成することに関心を持つデバイスユーザまたはデバイス所有者は、IDPを作成することができる。IDPMは、これらのポリシーを、IDPを選択する候補ポリシーまたは優先度の受け入れ可能な交差を評価し、次いでその結果得られるポリシーを強制することによって処理することができる。
あるいは、IDPMをSDMに、その機能の1つとして、またはTHSM上にロード(構築)またはダウンロードされうる別のエンティティとして追加することができる。
アテステーションプロトコルの一部として、TDROは、ROに、TPIA、TPES、およびSCARDのハッシュ値を、これらの測定結果を全部送信する代わりに、送信することができる。ROは、単独で、またはTTPを使って、そのようなハッシュ値を検証し、それによりTDROおよび周囲システムの実行可能性の評価を行う手段を有することができる。この方法は、特許文献1において指定されているような、半自立妥当性確認(SAV)に類似しているものとしてよい。アテステーション段階で、TPIA、TPES、およびSCARD測定のうちの1つまたは2つを送出することができる。
THSMは、MEの一部として埋め込んで一体にできる。そのようなデバイスに対するRTOプロセスは、MEとTHSMとの間のインターフェースがないので、簡素化することができる。
特徴および要素は、特定の組み合わせを用いて説明されているが、それぞれの特徴または要素は、他の特徴および要素なしで単独で、または他の特徴および要素とのさまざまな組み合わせで、または他の特徴および要素なしで使用することができる。本明細書で取りあげられている方法または流れ図は、汎用コンピュータまたはプロセッサにより実行できるようにコンピュータ可読記憶媒体内に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにより実装されうる。コンピュータ可読記憶媒体の実施例として、読み取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよびリムーバブルディスクなどの磁気媒体、光磁気媒体、ならびにCD−ROMディスクおよびデジタル多用途ディスク(DVD)などの光学媒体がある。
好適なプロセッサとして、例えば、汎用プロセッサ、専用プロセッサ、従来型のプロセッサ、デジタルシグナルプロセッサ(DSP)、複数のマイクロプロセッサ、DSPコアとの関連性を持つ1つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)回路、他のタイプの集積回路(IC)および/または状態機械がある。
ソフトウェアとの関連性を持つプロセッサは、無線送信受信ユニット(WTRU)、ユーザ装置(UE)、端末、基地局、無線ネットワークコントローラ(RNC)、またはホストコンピュータにおいて使用する無線周波トランシーバを実装するために使用できる。WTRUは、カメラ、ビデオカメラモジュール、テレビ電話、スピーカーフォン、バイブレーションデバイス、スピーカー、マイク、テレビトランシーバ、ハンズフリーヘッドセット、キーボード、Bluetooth(登録商標)モジュール、周波数変調(FM)無線ユニット、液晶ディスプレイ(LCD)表示装置、有機発光ダイオード(OLED)表示装置、デジタル音楽プレーヤー、メディアプレーヤー、ビデオゲーム機モジュール、インターネットブラウザ、および/または無線ローカルエリアネットワーク(WLAN)モジュールまたはウルトラワイドバンド(UWB)モジュールなどの、ハードウェアおよび/またはソフトウェアで実装された、モジュール群と併せて使用できる。