(57)【要約】本明細書では、潜在的に信頼できない要求元と関連付けられたセキュア・カーネル上で実行するトラストレットを含むネスト状信頼実行環境（ＴｒＥＥ）に保護データーを配信するための方法、システム、およびデバイスについて記載する。１つの態様において、ターゲティング・プロトコル・ヘッド、あるいは要求元と鍵管理システムまたはその他の保護データーの記憶装置との間における他の仲介が、潜在的に信頼できない要求元からの保護データーを求める要求と、セキュア・カーネルの証明報告書とを受け取ることができる。ターゲティング・プロトコル・ヘッドは、転送暗号鍵を、証明報告書から導き出された第２暗号鍵によって暗号化することができる。ターゲティング・プロトコル・ヘッドは、保護データーを引き出し、転送暗号鍵および認証タグによって、保護データーを暗号化することができる。認証タグは、要求元をトラストレットＩＤとバインドする。ターゲティング・プロトコル・ヘッドは、暗号化した転送暗号鍵、暗号化した保護データー、および暗号化した認証タグを要求元に供給することができる。【選択図】図１Ｃ
2020506612.tif 000002
【特許請求の範囲】
【請求項１】
コンピューティング・システムであって、
プロセッサーと、
前記プロセッサーに通信可能に結合され、命令を格納するメモリーと、
を備え、前記命令が前記プロセッサーによって実行されると、前記コンピューティング・システムに、
ネスト状ＴｒＥＥと関連付けられた、潜在的に信頼できない要求元からの保護データーを求める要求と、セキュア・カーネルの証明報告書とを受け取る動作であって、前記ネスト状ＴｒＥＥが、前記セキュア・カーネル上で実行するトラストレットを備え、前記トラストレットがトラストレットＩＤと関連付けられる、動作と、
前記証明報告書から導き出された第２暗号鍵で転送暗号鍵を暗号化する動作と、
前記保護データーを引き出す動作と、
前記転送暗号鍵および認証タグによって、前記保護データーを暗号化する動作であって、前記認証タグが、前記要求元を前記トラストレットＩＤとバインドする、動作と、
前記暗号化した転送暗号鍵、前記暗号化した保護データー、および暗号化した認証タグを前記要求元に供給する動作と、
を実行させる、コンピューティング・システム。
【請求項２】
請求項１に記載のコンピューティング・システムにおいて、前記トラストレットＩＤが、トラストレット・タイプとセッションＩＤとを含む、コンピューティング・システム。
【請求項３】
請求項２に記載のコンピューティング・システムにおいて、前記第２暗号鍵が、セキュア・カーネル暗号鍵を含む、コンピューティング・システム。
【請求項４】
請求項３に記載のコンピューティング・システムにおいて、前記セキュア・カーネル暗号鍵に対応する秘密セキュア・カーネル暗号鍵が、前記暗号化した保護データーを解読するために必要とされる、コンピューティング・システム。
【請求項５】
請求項１に記載のコンピューティング・システムにおいて、前記命令が、前記プロセッサーによって実行されると、前記コンピューティング・システムに、
前記トラストレットＩＤを、認可トラストレットＩＤのリストと比較する動作と、
前記トラストレットＩＤが、前記認可トラストレットＩＤのリストと関連付けられる場合にのみ、前記保護データーを前記転送暗号鍵および認証タグで暗号化する動作と、
を実行させる追加の命令を含む、コンピューティング・システム。
【請求項６】
セキュア・カーネル上で実行するトラストレットを備えるネスト状信頼実行環境（ＴｒＥＥ）に保護データーを配信する方法であって、前記トラストレットおよびセキュア・カーネルが双方共、潜在的に信頼できない要求元と関連付けられ、前記方法が、
ターゲティング・プロトコル・ヘッドによって、前記ネスト状ＴｒＥＥと関連付けられた潜在的に信頼できない要求元からの保護データーを求める要求と、前記セキュア・カーネルの証明報告書とを受け取るステップであって、前記トラストレットがトラストレットＩＤと関連付けられる、ステップと、
前記証明報告書から導き出された第２暗号鍵で転送暗号鍵を暗号化するステップと、
前記ターゲティング・プロトコル・ヘッドによって、前記保護データーを引き出すステップと、
前記保護データーを前記転送暗号鍵および認証タグで暗号化するステップであって、前記認証タグが前記要求元を前記トラストレットＩＤとバインドする、ステップと、
前記暗号化した転送暗号鍵、前記暗号化した保護データー、および暗号化した認証タグを前記要求元に供給するステップと、
を含む、方法。
【請求項７】
請求項６に記載の方法において、前記トラストレットＩＤが、トラストレット・タイプとセッションＩＤとを含む、方法。
【請求項８】
請求項７に記載の方法において、前記第２暗号鍵が、セキュア・カーネル暗号鍵を含む、方法。
【請求項９】
請求項８に記載の方法において、前記セキュア・カーネル暗号鍵に対応する秘密セキュア・カーネル暗号鍵が、前記暗号化した保護データーを解読するために必要とされる、方法。
【請求項１０】
請求項７に記載の方法であって、更に、
前記潜在的に信頼できない要求元によって、前記暗号化した転送暗号鍵と前記認証付き暗号化保護データーとを受け取るステップと、
前記潜在的に信頼できない要求元によって、前記暗号化した転送暗号鍵および前記認証付き暗号化保護データーを前記セキュア・カーネルに送るステップであって、前記セキュア・カーネルが、前記第２暗号鍵に対応する秘密第２暗号鍵で前記転送鍵を解読し、前記解読した転送鍵で前記保護データーを解読する、ステップと、
を含む、方法。
【請求項１１】
請求項１０に記載の方法において、前記潜在的に信頼できない要求元によって、前記暗号化した転送暗号鍵および前記認証付き暗号化保護データーを前記セキュア・カーネルに送るステップが、前記暗号化した転送暗号鍵および前記認証付き暗号化保護データーを前記トラストレットに送り、前記トラストレットが、前記暗号化した転送暗号鍵および前記認証付き暗号化保護データーを前記セキュア・カーネルに転送するステップを含む、方法。
【請求項１２】
請求項１０に記載の方法において、前記セキュア・カーネルが、前記トラストレット・タイプおよびセッションＩＤに基づいて、前記認証付き暗号化保護データーが前記トラストレットに向けられたものであることを確認し、前記トラストレット・タイプおよびセッションＩＤに基づいて、前記解読した保護データーを前記トラスタオレットに送る、方法。
【請求項１３】
請求項６に記載の方法において、前記保護データーが、ラッピング・キーを含む、方法。
【請求項１４】
請求項６に記載の方法であって、更に、
前記ターゲティング・プロトコル・ヘッドによって、前記トラストレットＩＤを、認可トラストレットＩＤのリストと比較するステップと、
前記トラストレットＩＤが、前記認可トラストレットＩＤのリストと関連付けられる場合にのみ、前記ターゲティング・プロトコル・ヘッドによって、前記保護データーを前記転送暗号鍵および認証タグで暗号化するステップと、
を含む、方法。
【請求項１５】
セキュア・カーネル上で実行するトラストレットを備えるネスト状信頼実行環境（ＴｒＥＥ）に保護デー タを配信するための命令を含むコンピューター読み取り可能記憶媒体であって、前記媒体が命令を含み、コンピューター・システム上で前記命令が実行されると、少なくとも、
前記ネスト状ＴｒＥＥと関連付けられた潜在的に信頼できない要求元からの保護データーを求める要求と、前記セキュア・カーネルの証明報告書とを受け取る**動作であって、前記トラストレットがトラストレットＩＤと関連付けられる、動作と、
転送暗号鍵を、前記証明報告書から導き出された第２暗号鍵によって暗号化する動作と、
前記保護データーを引き出す動作と、
前記保護データーを、前記転送暗号鍵および認証タグによって暗号化する動作であって、前記認証タグが前記要求元を前記トラストレットＩＤとバインドする、動作と、
前記暗号化した転送暗号鍵、前記暗号化した保護データー、および暗号化した認証タグを前記要求元に供給する動作と、
を前記コンピューター・システムに実行させる、コンピューター読み取り可能記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
[0001]  本開示は、一般には、コンピューティング・デバイスにおける信頼および／または分離(isolated)実行環境に関し、更に特定すれば、１つ以上の秘密または鍵の信頼実行環境への安全な配信に関する。
【背景技術】
【０００２】
[0002]  鍵管理システム（ＫＭＳ：key management system）とは、秘密の記憶装置(store)である。秘密とは、通例、公開ＩＤ、防護されている値(guarded value)、および誰がその値を入手することができるか管理するポリシーである。場合によっては、秘密は有効期限、その他のメタデーター等を有することもある。典型的な使用事例では、要求元(requestor)がＫＭＳに認証し、安全なチャネルを確立し、秘密ＩＤを提示することによって秘密値を要求し、平文の秘密値を要求元に戻すことをＫＭＳに期待する。この値は、要求元とＫＭＳとの間における安全なチャネルによって、不正な盗聴や改竄から保護される。
【０００３】
[0003]  信頼実行環境（ＴｒＥＥ：Trusted Execution Environment）は、本明細書において使用する場合、仮想セキュア・モード（ＶＳＭ）トラストレット(trustlet)、ＳＧＸアプリケーション、ＡＲＭ  ＴｒｕｓｔＺｏｎｅアプリケーション、または何らかの他の類似するビークル(vehicle)の内任意のものを含むことができる。ＴｒＥＥには、通常共通して有するいくつかの一意のプロパティがある。ＴｒＥＥは、一般に、完全な暗号スタックを有する（言い換えると、スペクトル全体にわたって、安全な乱数発生から、秘密鍵を使用するハッシング、暗号化、および署名ライブラリーに及ぶ、最大限の機能選択肢(full menu)までの多種多様な暗号プリミティブを有すると仮定することができる）。また、ＴｒＥＥは、通常、小数のまたは限定されたＩ／Ｏ装備を有するか、あるいは関連付けられており、通例では、信頼されていない「外部世界」によって要求が開始される、要求主導型アーキテクチャ(request driven architecture)に限定される。例えば、ＶＳＭトラストレットは、未認証リモート・プロシージャ・コール（ＲＰＣ：Remote Procedure Calls)を使用することができる。また、ＴｒＥＥはＴｒＥＥの外部では入手できない鍵素材またはデーターにアクセスすることもできる。これによって、ＴｒＥＥは、とりわけ、信頼されていないＩ／Ｏを使用してデーターを格納し、次いでそれを読み出すことが可能になり、改竄に対する耐性および状態の機密性(confidentiality of state)を保証する。また、ＴｒＥＥは、一般に、立証可能なコード(attestable code)、コンフィギュレーション、および鍵素材も有する、またはこれらと関連付けられる。具体的には、立証可能な鍵素材は、ＴｒＥＥが、サードパーティから、それに対して暗号化されたメッセージを受信し、ＴｒＥＥから来たものとして、サードパーティへのメッセージに署名することを可能にする。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
[0004]  他のアプリケーションと同様、ＴｒＥＥによるＫＭＳの使用においても安全性の限界が露呈することがある。したがって、ＫＭＳから供給される鍵を、ＴｒＥＥと共に利用して、またはＴｒＥＥにおいて利用して、安全性を高めるための改善を行うことができる。
【課題を解決するための手段】
【０００５】
[0005]  本開示の実例は、限定ではなく、方法、システム、および種々のデバイスを含む。１つの態様において、潜在的に信頼できない要求元と関連付けられたセキュア・カーネル上で実行するトラストレットを含むネスト状信頼実行環境（ＴｒＥＥ）に保護データーを配信する方法を、少なくとも部分的に、ターゲティング・プロトコル・ヘッド、あるいは要求元と鍵管理システムまたはその他の保護データーの記憶装置との間における他の仲介によって実行することができる。ターゲティング・プロトコル・ヘッドは、潜在的に信頼できない要求元からの保護データーを求める要求と、セキュア・カーネルの証明報告書とを受け取ることができる。ターゲティング・プロトコル・ヘッドは、証明報告書から導き出される第２暗号鍵で転送暗号鍵を暗号化することができる。ターゲティング・プロトコル・ヘッドは、保護データーを引き出し、転送暗号鍵および認証タグによって、保護データーを暗号化することができる。認証タグは、要求元をトラストレットＩＤとバインドする。ターゲティング・プロトコル・ヘッドは、暗号化した転送暗号鍵、暗号化した保護データー、および暗号化した認証タグを要求元に供給することができる。
【図面の簡単な説明】
【０００６】
[0007]  これより、本開示の実施形態について、添付図面を参照しながら、更に深く説明する。図面において、
【図１Ａ】図１Ａは、要求元と鍵管理システムとの間で鍵を交換するシステムおよびプロセスの３つの例を表す。
【図１Ｂ】図１Ｂは、要求元と鍵管理システムとの間で鍵を交換するシステムおよびプロセスの３つの例を表す。
【図１Ｃ】図１Ｃは、要求元と鍵管理システムとの間で鍵を交換するシステムおよびプロセスの３つの例を表す。
【図２】分離領域または信頼実行環境（ＴｒＥＥ）を実装する制御プログラム・モニタの一例を示す図である。
【図３】仲介ターゲティング・プロトコル・ヘッドを利用して、保護データーを信頼ＴｒＥＥに配信するプロセス例を表す。
【図４Ａ】図４Ａは、仲介ターゲティング・プロトコル・ヘッドを利用して、保護データーをＴｒＥＥに配信する他のプロセス例を示す。
【図４Ｂ】図Ｂは、仲介ターゲティング・プロトコル・ヘッドを利用して、保護データーをＴｒＥＥに配信する他のプロセス例を示す。
【図５Ａ】図５Ａは、仲介ターゲティング・プロトコル・ヘッドを利用して、保護データーをネスト状ＴｒＥＥに配信するプロセス例を表す。
【図５Ｂ】図５Ｂは、仲介ターゲティング・プロトコル・ヘッドを利用して、保護データーをネスト状ＴｒＥＥに配信するプロセス例を表す。
【図６】説明するプロセスの内１つ以上を実装することができるシステム例を示す。
【図７】トランスポート・キーおよび／または保護データーを安全にＴｒＥＥに配信するために使用されるデーター構造の例を表す。
【図８】他のＴｒＥＥの暗号鍵に基づいて(based around)仲介ターゲティング・プロトコル・ヘッドを利用して保護データーをネスト状ＴｒＥＥに配信する他のプロセス例を表す。
【図９】内部ＴｒＥＥの暗号鍵に基づいて仲介ターゲティング・プロトコル・ヘッドを利用して保護データーをネスト状ＴｒＥＥに配信する他のプロセス例を表す。
【図１０】本明細書において説明する技法を具体化することができる汎用コンピューティング環境の例を表す。
【発明を実施するための形態】
【０００７】
[0018]  本明細書では、少なくとも１つの鍵（例えば、署名鍵または暗号鍵）または保護データー／秘密を、１つ以上の物理または仮想コンピューティング・デバイスのような、コンピューティング・デバイスの信頼実行環境（ＴｒＥＥ）内に安全に配信するシステムおよび技法について説明する。１つの態様において、鍵の要求元と、鍵管理システムまたは保護データーを所有するエンティティとの間に、仲介を実装することができる。仲介を、本明細書では、ターゲティング・プロトコル・ヘッドと呼ぶこともある。鍵の要求元は、安全実行環境またはＴｒＥＥと関連付けることができ、安全実行環境はＶＳＭトラストレット、ＳＧＸアプリケーション、ＡＲＭ  ＴｒｕｓｔＺｏｎｅアプリケーション、または何らかのその他の類似するビークルの内１つ以上を含むことができる。ＴｒＥＥは、要求元から分離されてもよい。要求元は、１つ以上の秘密をＴｒＥＥまたはＴｒＥＥ内部で実行する特定のトラストレットに配信するように、ターゲティング・プロトコル・ヘッドに要求することができる。ターゲティング・プロトコル・ヘッドは、要求に応答して、ＴｒＥＥへの配信のために１つ以上の秘密を入手するために、鍵管理システム、または秘密を保持している他のエンティティと通信することができる。ターゲティング・プロトコル・ヘッドは、保護データーが要求元にも攻撃者にもアクセス可能にならないように、特定的に保護データーをＴｒＥＥに導く(target)ことができる。
【０００８】
[0019]  ある態様では、ターゲティング・プロトコル・ヘッドの実装により、要求元と鍵管理システムとの間における安全なチャネルの必要性をなくすることができる。ターゲティング・プロトコル・ヘッドは、本明細書において説明するＴｒＥＥターゲティング技法を使用して、秘密／データーが要求元にはアクセスすることができないように、１つ以上の秘密またはデーターをＴｒＥＥまたはネスト状ＴｒＥＥ（例えば、セキュア・カーネル上で実行するトラストレット）に送ることも可能にする。場合によっては、保護データーの所有者が、種々の理由のいずれかのために、要求元には保護データーをアクセスできないままにしておくことを希望できるように、要求元を信頼できないまたは潜在的に潜在できないものにすることもできる。場合によっては、要求元が信頼できることを断定する(establish)こと、あるいは要求元が信頼できるままでいることを確認することが難しいまたは厄介なこともある。これらの懸念の多くは、要求元は信頼できないと仮定し、ＴｒＥＥを要求元から分離することによって、払拭することができる。この分離により、異なる種類の攻撃に対して、セキュリティを著しく強化することができ、以下で更に詳しく説明するように、他の便益および利点を得ることができる。
【０００９】
[0020]  図１Ａは、要求元と鍵管理システムとの間で鍵を交換するためのシステムおよびプロセス例１００ａを示す。図示のように、要求元または要求元デバイス１２０は、クライアント・デバイスまたはクライアント側１１０と関連付けられ、鍵管理システム、あるいはサーバーまたはサーバー側１０５と関連付けられた、何らかの所望の秘密（１つまたは複数）１１５の保持者と通信することができる。要求元１２０は、例えば、特定の保護データーにアクセスする、１つ以上の保護プロセスを実行する等のために、１つ以上の秘密または保護データーを鍵管理システム１１５に要求することができる。要求元１２０および鍵管理システム（ＫＭＳ）１１５は、公開鍵−秘密鍵セキュリティ・システムまたは、当技術分野において知られているような、他の鍵プロトコルを利用して、所望の秘密／データーを交換することができる。
【００１０】
[0021]  要求元１２０は、最初に動作１２５において、ＫＭＳ１１５と認証し、当技術分野において知られている技法の内任意のものによって、安全な通信チャネルを確立することができる。動作１２５は、公開鍵システム等を利用する動作を含んでもよい。次に、動作１２５によって確立された安全なチャネルを利用して、要求元１２０は１つ以上の秘密／保護データーを求める要求を、動作１３０において、ＫＭＳ１１５に送ることができる。この要求を検証した(verify)ときに、ＫＭＳ１１５は、動作１３５において、安全な通信チャネルを通じて、秘密または要求されたデーターを要求元１２０に返すことができる。当技術分野では標準的であるが、１３５において、安全なチャネル上(above)には追加の保護を全く設けずに、この安全なチャネルを通じて秘密／要求データーを送信することができる。その結果、動作１３５において送信された秘密／データーは、要求元デバイス１２０に露出されるおそれがある。
【００１１】
[0022]  図１Ｂは、信頼実行環境（ＴｒＥＥ）１４０の代わりに、要求元１２０とＫＭＳ１１５との間で１つ以上の秘密または保護データーを一層安全に交換するためのシステムおよびプロセス例１００ｂを示す。信頼実行環境（ＴｒＥＥ）１４０は、飛び地(enclave)、即ち、要求元１２０と関連付けられた分離実行環境を示すために使用される別の用語(term)である。要求元１２０とＫＭＳ１１５との間で１つ以上の秘密または保護データーを一層安全に交換するためのシステムおよびプロセス例１００ｂを示す。ＴｒＥＥ１４０は、ＴｒＥＥ１４０内に収容されているコードおよび／またはデーターが要求元１２０によってアクセスすること（例えば、読み取りおよび／または書き込み）ができないように、要求元１２０から分離することができる。図２は、信頼実行環境例２００を示し、ここでは、コンピューティング・デバイス２０５がロジック２１０（例えば、コード）、およびデーターのような状態情報２２０を含むことができる。状態情報２２０は、不正アクセスから保護する(secure)ことができるように、分離領域２１５に格納または配置することができる。場合によっては、分離領域２１５内にあるデーターは、分離領域２１５と関連付けられたロジック２１０以外のいずれのエンティティであっても、直接読み取りも書き込みも行うことはできない。分離ロジック２１０は、どの種類のアクセスを、どの型または部分のデーター２２０に許可するか決定する。一例では、ロジック２１０は、データー２２０に関連付けられた値を増加することおよび読み取ることを許可するが、それ以外でデーター２２０を修正することは許可しないとしてもよい。他の例では、ロジック２１０は、鍵を使用する暗号動作を許可するが、それでも鍵自体の値へのアクセスは付与しないとしてもよい。図示する例では、ロジックまたはコード２１０はＣＰＭ２０５の一般的な領域、即ち、アクセス可能な領域内にあってもよい。しかしながら、場合によっては、ロジック２１０が状態情報２２０と同じまたは異なる分離領域内に配置されてもよいことは認められてしかるべきである。
【００１２】
[0023]  システム１００ｂに戻り、ターゲティング・プロトコル・ヘッド（ＴＰＨ）１５０は、要求元１２０／ＴｒＥＥ１４０とＫＭＳ１１５との間の仲介として役割を果たすために、サーバー側１０５に実装することができる。プロトコル・ヘッドとは、通例では、特定のプロトコルをネーティブに話さない(speak)システムの隠れ蓑になる(front)プロトコル・ハンドラのソフトウェア実施態様を指すとしてよい。ターゲティングとは、実行環境の暗号化ターゲティング(cryptographic targeting)を指すとしてよい。一緒に合わせると、この用語はＴｒＥＥにおける応答をターゲットにする秘密を引き出すためのプロトコルを実装するソフトウェアおよび／またはハードウェアを示すことができる。ある態様では、ターゲティング・プロトコル・ヘッド１５０は、例えば、ＫＭＳ１１５とは異なるハードウェア、ソフトウェア上で実行すること、および／またはＫＭＳ１１５とは別個に実行することができる、仮想またはクラウド・リソースとして実装することもできる。ある態様では、データー・センターのようなエンティティが、例えば、サービスとして、ターゲティング・プロトコル・ヘッド１５０をホストするおよび／または提供することもできる。ターゲティング・プロトコル・ヘッド１５０は、２つの主要な機能、１）ＫＭＳ１１５と通信し外部エンティティから秘密または保護データーを入手する機能、および２）要求元１２０のＴｒＥＥ１４０への応答をターゲットにする機能を実行することができる。ターゲティング・プロトコル・ヘッド１５０を使用する結果、要求元１２０はＫＭＳ１１５に直接認証する必要がなくなる。ＫＭＳ１１５は、その秘密をターゲティング・プロトコル・ヘッド１５０に生成する(yield)が、要求元１２０には生成しない。ターゲティング・プロトコル・ヘッド１５０の機能は、要求元１２０のＴｒＥＥ１４０への応答をターゲットにすることであり、こうして、要求元１２０が秘密／保護データーの平文を入手できないことを保証する。代わりに、ターゲティング・プロトコル・ヘッド１５０は、要求元１２０の代わりに、ＫＭＳ１１５に認証することができるが、要求元１２０の識別情報(identity)を使用して、または使用せずに、そのようにすることができる。場合によっては、ターゲティング・プロトコル・ヘッド１５０が要求元１２０のＴｒＥＥ１４０に返そうとしている秘密がもうすぐ「安全な状態」になることを、ターゲティング・プロトコル・ヘッド１５０が確信しなければならないこともある。この場合、要求元１２０は、ＴｒＥＥ１４０の状態について証明可能な情報(attestable information)をターゲティング・プロトコル・ヘッド１５０に提供することができる。この証明可能な情報は、ＴｒＥＥ１４０と関連付けられた、証明可能な鍵素材を含み、ＴｒＥＥ１４０への応答を暗号化することができる。
【００１３】
[0024]  場合によっては、１つ以上のトラストレットによって供給されるような、複数の異なるプロセスがセキュア・カーネル内において同時に動作することもあり、各トラストレットおよびセキュア・カーネルは各々ＴｒＥＥ１４０として見なされる（例えば、これはネスト状ＴｒＥＥの例である）。このシナリオでは、異なるトラストレットの各々には、セッションＩＤ、トラストレット・タイプ、および／またはセキュア・カーネル内で個々のトランスレットを識別するために使用することができるその他のＩＤ（例えば、双方共ＴｒＥＥ１４０として表される）と関連付けることができる。ターゲティング・プロトコル・ヘッド１５０からの応答は、要求において識別されたＴｒＥＥ１４０内における特定のトラストレットに絞って、導くことができる。これについては、以下で更に詳しく説明する。
【００１４】
[0025]  ＴｒＥＥ１４０のターゲティングの場合、要求元１２０とターゲティング・プロトコル・ヘッド１５０との間に安全なチャネルを設ける本質的な必要性はない。何故なら、要求元１２０自体が信頼されて応答が送られるのではないからである。しかしながら、例えば、要求自体へのアクセスによって望ましくない情報開示が発生する可能性があるので、要求自体（要求元が欲しい秘密）へのアクセスを保護するために、認証動作１６０によって、要求元１２０とターゲティング・プロトコル・ヘッド１５０との間に安全なチャネルを追加してもよいことは認められてしかるべきである。動作１６０における認証の後に、またはその代わりに、要求元１２０は、例えば、動作１５５においてＴｒＥＥ１４０に配信するために、ＴｒＥＥ１４０に代わって、１つ以上の秘密、あるいは１つの秘密または保護データーを求める要求をターゲティング・プロトコル・ヘッド１５０に送ることができる。ある態様では、要求にＴｒＥＥ１４０を関連付けること、または要求がＴｒＥＥ１４０を識別することができる。ターゲティング・プロトコル・ヘッド１５０は、ＴｒＥＥ１４０が信頼できるか否か判断することができる。１つの態様では、要求元１２０の認証は、一種のクリーン・ルーム・プロビジョニング(clean room provisioning)を頼りにしてもよい。他の態様では、認証は証明(attestation)を頼りにしてもよい。
【００１５】
[0026]  クリーン・ルーム・プロビジョニングは、要求元１２０のデバイスが、例えば、新品であり、悪意のあるソフトウェアに侵されていないと正当に仮定されるときに、使用することができる。クリーン・ルーム・プロビジョニングを使用して、要求元と関連付けられたＴｒＥＥに保護データーを配信するためのプロセス例については、図３を参照して以下で更に詳しく説明する。証明（例えば、証明サービス）を使用して、要求元と関連付けられたＴｒＥＥに保護データーを配信するためのプロセス例については、図４を参照して以下で更に詳しく説明する。
【００１６】
[0027]  いずれの場合でも、一旦ＴＰＨ１５０が要求元１２０を認証したなら、および／またはＴｒＥＥ１４０の信頼性を断定したなら、ＴＰＨ１５０は動作１６５において、ＫＭＳ１１５を認証し、ＫＭＳ１１５との安全な通信チャネルを確立することができる。ある態様では、ＫＭＳ１１５は、ライセンス、許可、パスワード等のような、１つ以上の秘密または保護データーを保持する任意のエンティティを含むことができ、または任意のエンティティと関連付けることができる。ＫＭＳ１１５との安全な通信チャネルを確立したとき、ＴＰＨ１５０は、動作１７０において、保護データーを求める要求を送ることができる。ＫＭＳ１１５は、動作１７５において、要求された秘密を返すことができる。ＴＰＨ１５０は、ＴｒＥＥ１４０において秘密（１つまたは複数）または保護データーをターゲットにして、動作１８０において１つ以上の秘密を送ることができる。
【００１７】
[0028]  ある態様では、動作１８０において、保護データーをＴｒＥＥ１４０に配信するときに、以下のデーター構造の内少なくとも１つを利用することができる。ＴｒＥＥ識別情報(TrEE identity)または証明プロセスまたは証明ログの周囲に、あるいはネスト状ＴｒＥＥの例（例えば、セキュア・カーネル上で実行するトラストレット）内に組み込む(build)ことができる暗号識別鍵(encryption identity key)、同様に証明プロセスの周囲に組み込むことができる署名識別鍵(signing identity key) 。これらについては、以下で更に詳しく説明する。
【００１８】
[0029]  図１Ｃは、信頼実行環境（ＴｒＥＥ）１４０の代わりに、要求元１２０とＫＭＳ１１５との間において１つ以上の秘密または保護データーを安全に交換するための他のシステムおよびプロセス例１００ｃを示す。システム１００ｃは、以上で説明したシステム１００ｂの具体的な例であるとして差し支えない。システム１００ｃでは、ターゲティング・プロトコル・ヘッド１５０はホスト・ガーディアン・サービス（ＨＧＳ：host guardian service）１５０ａにしてもよい。システム１００ｃにおいて、ＨＧＳ１５０ａは、例えば、クラウド・ホスト１８５、あるいはＴｒＥＥ１４０をインスタンス化するまたはそうでなければ制御することができる他のエンティティからキー・プロテクター(key protector)１９０を受け取ることができる。システム１００ｃにおいて、要求元１２０は、例えば、クラウド・ホスト１８５によって提供される仮想機械と関連付けることができる。ＫＰ１９０は、"Secure Transport of Encrypted Virtual Machines with Continuous Owner Access"（連続所有者アクセスによる暗号化仮想機械の安全な輸送）と題し、２０１４年９月９日に出願された関連米国特許出願第１４／４８１，３９９号（米国特許出願公開第２０１５／３１８９８６号明細書）に記載されているキー・プロテクターの１つ以上の態様を組み込むことができる。ＫＰ１９０は、トランスポート・キーのような、ＴｒＥＥ１４０によって使用可能な１つ以上の秘密を収容することができる。ＫＰ１９０は、本質的に、トランスポート・キーにアクセスすることを許可された１組のガーディアン(guardian)のみにアクセス可能になるように、トランスポート・キーにラッピングを施すことができる。動作１６５においてＫＭＳ１１５との安全な通信チャネルを認証および確立した後、ＫＰ１９０の内容を読み取り、トランスポート・キーを引き出すために、動作１７０ａにおいて、ＨＧＳ１５０ａが解読鍵をＫＭＳ１１５に要求することができるように、 ＫＰ１９０を暗号化することができる。応答して、ＫＭＳ１１５は、動作１７５ａにおいて、解読鍵をＨＧＳに送ることができる。次いで、ＨＧＳ１５０ａは、解読鍵を使用してＫＰ１９０を解読し、１つ以上の秘密（例えば、トランスポート・キー）を引き出して、ＴｒＥＥ１４０に送ることができる。次いで、ＨＧＳ１５０ａは、動作１８０において、以下で更に詳しく説明する１つ以上のアドレシング技法によって、秘密またはトランスポート・キーをＴｒＥＥに送ることができる。ある態様では、ＫＰ１９０からのデーターに基づいて、ＴｒＥＥ１４０にアドレスすることもできる。
【００１９】
[0030]  尚、場合によっては、ＨＧＳ１５０ａおよびＫＭＳ１１５が１つのエンティティとなり、これらの間に通信チャネルを確立する必要をなくし、認証も不要とするようにしてもよいことは認められてしかるべきである。
【００２０】
[0031]  システム１００ｃでは、要求元１２０とＨＧＳ１５０ａとの間における認証は不要である。クラウドまたはファブリック・ホスト(fabric host)１８０が健全である限り、どのファブリック・ホストがＨＧＳ１５０ａと通信しているのかは、それがファブリックにおけるサーバーの１つであるのであれば（これは証明によって検証することができる）、問題にならない。
【００２１】
[0032]  図３は、要求元のＴｒＥＥに保護データーを配信するためのプロセス例３００を示し、ここでは、要求元は信頼をおけるものと仮定する（例えば、悪意のソフトウェアに侵されていない）。本明細書において使用する場合、いずれの図においてもボックスまたは動作の破線は随意であり、その動作は除外してもよいことを示す。プロセス３００は、ＴｒＥＥによって生成された、またはＴｒＥＥを開始した要求元のセキュア・カーネルによって生成された、公開鍵秘密鍵対（例えば、非対称鍵対）の公開鍵のような、ＴｒＥＥと関連付けられた暗号鍵を利用することができる。他の場合では、暗号鍵は対称型であってもよい。本明細書において使用する場合、セキュア・カーネルとは、当技術分野では知られているように、もっと高いレベルのセキュリティと関連付けられたコンピューティング・デバイスの任意の部分を指すことができる。
【００２２】
[0033]  このシナリオでは、動作３０２において、ＴｒＥＥ１４０を起動する(launch)または開始する(initiate)ことができ、動作３０４において、１つ以上の秘密鍵（例えば、秘密暗号鍵）および対応する公開鍵を、ＴｒＥＥ１４０の内部で生成することができる。次いで、動作３０６において、対応する公開鍵をＴＰＨ１５０に登録し、要求元の識別情報(identity)および／または要求元デバイスの識別情報と関連付けることができる。場合によっては、ＴｒＥＥ１４０の公開鍵を１回だけ登録すればよく、公開鍵を登録した後に、プロセス３００が動作３０８において開始できるようにする。その後、要求元１２０は、動作３０８において、任意の知られている認証技法によって、ＴＰＨ１５０と認証することができる。次いで、ＴＰＨ１５０は、例えば、要求元１２０の識別情報と関連付けることができるＴｒＥＥ１４０の登録公開鍵に基づいて、ＴｒＥＥ１４０への応答を配信するときに使用する公開鍵を調べることができる。このプロセスを「クリーン・ルーム」プロビジョニングと呼ぶことができる。何故なら、要求元１２０が、不良品でないことがわかっている(known-good)とき、または信頼がおける状態にあるときにしか、これを安全に行うことができないからである。この例では、証明書に基づく認証の必要はなく、要求元１２０がＴｒＥＥ健全性証明書（ＴＨＣ：TrEE Health Certificate）をＴＰＨ１５０に送らなくてよい。何故なら、要求元１２０は信頼できるからである。遍在的証明サービス(ubiquitous attestation services)がない場合、正しいＴｒＥＥ１４０がＴＰＨ１５０によってターゲットにされていることを実証する(validate)ことは実行可能な選択肢である。
【００２３】
[0034]  次に、動作３１２において、ＴＰＨ１５０は、ＴｒＥＥ１４０への配信のための保護データーを、例えば、先に説明したように、ＫＭＳ１１５から入手することができる。動作３１０によってアクセスしたＴｒＥＥ公開鍵を使用して、ＴＰＨ１５０は、次に、動作３１４において、入手した保護データーを含むメッセージを、ＴｒＥＥ１４０に送るために、作成する(construct)ことができる。ＴＰＨ１５０は、動作３１６において、このメッセージを要求元１２０に送ることができる。
【００２４】
[0035]  このメッセージを受信すると、動作３１８において、要求元１２０はこれをＴｒＥＥ１４０に転送することができる。要求元１２０はＴｒＥＥの秘密鍵にアクセスすることができないので、要求元１２０は、メッセージを解読して保護データーにアクセスすることができない。動作３２０において、ＴｒＥＥ１４０は、その秘密鍵を使用してメッセージを解読し、保護データーにアクセスすることができる。
【００２５】
[0036]  図４Ａは、信頼できない要求元のＴｒＥＥに保護データーを配信するためのプロセス例４００を示す。プロセス４００は、公開鍵−秘密鍵対の公開鍵のような、ＴｒＥＥと関連付けられた暗号鍵を利用することができる。これは、ＴｒＥＥによって生成されるか、またはネスト状ＴｒＥＥの場合のように、ＴｒＥＥを開始した要求元のセキュア・カーネルによって生成され、ここではこれをトラストレットと呼ぶことができる。加えてまたは代わりに、プロセス４００は、外部ＴｒＥＥと見なしてもよい、セキュア・カーネルの署名鍵を利用してもよい。トラストレットは、ネストされるかまたは、ＴｒＥＥと関連付けられたセキュア・カーネル上で実行する。署名鍵は、ＴｒＥＥによって生成された鍵対の内公開鍵を証明する(certify)ために使用することができる。これについては、以下で更に詳しく説明する。
【００２６】
[0037]  プロセス４００にしたがって、動作４０２におけるＴｒＥＥの初期化後に、要求元１２０は、動作４０６において、証明報告(attestation report)または報告書(statement)を証明サービスに要求することができる。図４Ｂは、証明報告書または報告を証明サービス４２４から入手するためのプロセス例を示す。図４Ｂの例では、要求元１２０は、動作４２６において、ＴｒＥＥ１４０（トラストレット）の公開鍵（ＩＤＫ＿Ｅ）またはＴｒＥＥ（セキュア・カーネル）の署名鍵（ＩＤＫ＿Ｓ）を収容するブート(boot)において、証明ログ（ＴＣＧログ）を作成することができる。次いで、動作４２８において、要求元１２０は、ＴＣＧログを証明サービス４２４に提示することができる。場合によっては、ＴＰＨ１５０は、ＴＰＨ１５０によって信頼された証明サービスを指示する(direct)か、または、要求元１２０がこの証明サービスを選択することもできる。動作４３０において、証明サービス４２４は、ＴＣＧログを検査し、ＴｒＥＥ１４０（セキュア・カーネル）の暗号鍵（ＩＤＫ＿Ｅ）および／または署名鍵（ＩＤＫ＿Ｓ）に基づいて、ＴｒＥＥ健全性証明書（ＴＨＣ）を発行することができる。次いで、証明サービス２４２は、動作４３２において、ＴＨＣ（ここでは、証明報告書とも呼ぶ）を要求元１２０に返すことができる。
【００２７】
[0038]  動作４０６において証明報告書を入手すると、要求元１２０は、動作４０８において、この証明報告書および保護データーを求める要求をＴＰＨ１５０に、ＴｒＥＥ１４０の代わりに送ることができる。ＴＨＣ即ち証明報告書は、要求元１２０の項目名（認証中に断定された要求元の識別情報と証明書との間でバインド(binding)を作成するため）と、応答を定式化するときに応答側（ＴＰＨ１５０）が使用すべき鍵（例えば、暗号鍵または署名鍵）とを収容することができる。
【００２８】
[0039]  ある態様では、信頼できるプラットフォーム・モジュール（ＴＰＭ：trusted platform module)の暗号鍵（ＥＫ）というような、改竄防止識別情報を、要求元１２０と関連付ける。要求元１２０の証明は、当技術分野では知られているように、ＴＰＭ  ＥＫを使用して実行することができる。
【００２９】
[0040]  ある態様では、帯域外において、またはＴＨＣの一部であってもよい発行ポリシー（ＩＰ：issuance policy）オブジェクト識別子（ＯＩＤ：object identifier)を通じて、ＴｒＥＥは、要求元１２０を介して、ＴＰＨ１５０に、鍵が暗号鍵かまたは署名鍵か伝えることもできる。使用する鍵間の選択は、先に説明したように、応答を構成する(structure)ために使用するメカニズムの選択に影響を及ぼす可能性がある。重要なこととして、証明書を裏付ける秘密鍵の所有の証明は、ＴＰＨ１５０によって要求されない。 これは、単に、要求元は対応する秘密鍵にアクセスすることができないため、間違った証明書が与えられた場合、要求元１２０は応答を全く解明することができないからである。
【００３０】
[0041]  図５Ａおよび図５Ｂは、信頼できない要求元のネスト状ＴｒＥＥに保護データーを配信するためのプロセス例５００を示す。ある態様では、１つのＴｒＥＥが他のＴｒＥＥ内に収容されるように、２つ以上のＴｒＥＥがネストされることもある。本明細書において言及する場合、トラストレットとは、外側のＴｒＥＥに収容されたネスト状ＴｒＥＥである。一例では、外側のＴｒＥＥが、仮想信頼レベルと関連付けられたメモリーの特定のパーティションのような、オペレーティング・システムの信頼部分のセキュア・カーネルを含んでもよい。これについては、図６を参照して以下で更に詳しく説明する。プロセス５００は、例えば、外側のＴｒＥＥの暗号鍵だけが入手可能であるときに利用することができる。場合によっては、外側のＴｒＥＥは、トラストレットをインスタンス化した機械のセキュア・カーネルであってもよい。
【００３１】
[0042]  プロセス５００は、動作５０２において開始することができ、ここで、要求元１２０は、この要求元１２０によって決定された「セッション識別子」を有するトラストレットを起動する。セッション識別子は、トラストレットがどのコンテンツまたはデーターに作用するかに関するあるいは特定する識別子、トラストレット（例えば、「特定のタイトル」を再生するためのストリーミング・コンテンツ・アプリケーション・トラストレット） のユーザーに関する識別子等のように、任意の種類の識別子を含んでもよい。一例では、セッションＩＤは３２ビット値であってもよい。この値は、保存することができ、トラストレットの使用期限(lifetime)の間読み取り専用であってもよく、トラストレットをターゲットにしたメッセージを受信するときに、セキュア・カーネルに入手可能であってもよい。この値がない可能性もあり（プロセス起動時に指定されていない）、その場合、セッションＩＤはゼロであると仮定することができる。
【００３２】
[0043]  次に、動作５０４において、要求元１２０はＴＰＨ１５０に認証することができる（前述のように随意であるが、要求元間に実際に相違がない場合というような、非常に限られた状況においてのみ随意である）。ＴｒＥＥ（例えば、ＴｒＥＥの鍵）と要求元の識別情報との間にバインドがあることが望まれる一例は、実例をあげると、映画のようなコンテンツ項目の再生が、ライセンスまたは加入者の妥当性判断(validation)によって制約されるときである（例えば、ＮｅｔＦｌｉｘユーザーが映画を再生するためのライセンスを取得したいが、ＮｅｔＦｌｉｘは、映画のライセンスを受けるのはその加入者であることを確認したい（それらのＴｒＥＥ内部で））。
【００３３】
[0044]  要求元１２０は、図４Ｂを参照して先に説明したプロセス４０６にしたがってというようにして、動作５０６において、ＴＰＨ１５０によって信頼されている証明サービスから、証明報告書を入手することができる。次に、要求元１２０は、動作５０８において、証明報告書をＴＰＨ１５０に提示することができる。尚、先に説明したクリーン・ルーム・プロビジョニングの例では、証明は必要でないことは認められてしかるべきであり、ここでも該当するとしてよい。  
【００３４】
[0045]  証明報告書を受信すると、動作５１０において、ＴＰＨ１５０はこの証明報告書を検証することができる（または、先のクリーン・ルーム・プロビジョニングの例の場合、要求元の識別情報に基づいてその鍵を調べる）。プロセス５００のこの時点において、要求元１２０は、外側ＴｒＥＥにアドレスするためにはどの鍵を使用すべきか分かっている。ある態様では、証明報告書または要求から得られた鍵は、外側ＴｒＥＥまたはセキュア・カーネル（そして、内側トラストレットではない）の暗号鍵であるという指示を、要求または証明報告書と共に含ませることができ、あるいは他の方法でまたは帯域外において、デフォルト手順として設定して等で、ＴＰＨ１５０に伝達することができる。次に、動作５１１において、ＴＰＨ１５０は、要求において示された保護データーを、例えば、ＫＭＳ１１５から、あるいはライセンス、パスワード、許可、および／またはその他の情報を保持している１つ以上のサービスというような、保護データーを保持している任意の他のエンティティから入手することができる。
【００３５】
[0046]  ＴＰＨ１５０は、動作５１２において、例えば、要求に基づいて、またはＴＰＨ１５０自体に基づいて、ターゲットにするのはどのトラストレット・タイプか決定することができる（例えば、ＮｅｔＦｌｉｘのような特定の目的またはアプリケーションに合わせて特定的に、 各ＴＰＨ１５０を設計することができる）。先に図１Ｃを参照して説明したような、ＫＰを利用する例では、トラストレット・タイプをＫＰにおいてエンコードすることができる。いくつかの他の例では、トラストレット・タイプは、ＨＧＳ１５０ａを利用する実施態様におけるように、デフォルトで設定する、またはハード・コード化することができる。ＨＧＳの例では、ＨＧＳ１５０ａは、常に、仮想モード・セキュア・プロセス（ＶＭＳＰ）トラストレットをターゲットにすることができる。このトラストレット・タイプは、ハード・コード化されてもよい（ＫＰはその情報を収容していないため）。
【００３６】
[0047]  ターゲットにすべきトラストレット・タイプを決定するとき、ＴＰＨ１５０は、動作５１４において、ＴｒＥＥに送る保護データーを含むメッセージを組み立てる(construct)ことができる。動作５１４の更に詳しい例を図５Ｂに示す。
【００３７】
[0048]  ある態様では、動作５１４は、更に、動作５３６を含むことができ、ここで、ＴＰＨ１５０は２つのランダム対称鍵、転送鍵ＴＸおよびラッピング・キーＴＷを生成する。次に、ＴＰＨ１５０は、動作５３８において、ＴＨＣ（証明報告書の一部）における公開鍵を使用してＴＸを暗号化することができる（例えば、ＴＨＣは、署名鍵ではなく、暗号鍵に基づくと仮定する）。ある態様では、動作５３８は、ＲＳＡ暗号化およびＯＡＥＰパディングを使用して、ホストのＩＤＫでＴＸを暗号化する動作を含むことができる。ある態様では、ＴＰＨ１５０は、動作５４０において、例えば、トラストレットが認可されていること、または保護データーにアクセスする正しい許可を有すること（例えば、オンライン・サービスまたはコンテンツ項目に対して支払いを済ませている）を検証するために、トラストレットのセッションＩＤを検証することができる。場合によっては、セッションＩＤがトラストレット・タイプを含むこともあるが、他の例では、トラストレット・タイプは、ＫＰにエンコードされる、またはハード・コード化されることさえもある。次いで、ＴＰＨ１５０は、動作５４２および５４４において、ＴＸを使用してＴＷを暗号化することができ、トラストレット・タイプおよびトラストレットのセッションＩＤを連結し(concatenated)、「認証タグ」として使用することができる。尚、認証タグの使用は、ＡＥＳ−ＧＣＭプロトコルのアーチファクトであり、他の暗号化プロトコルは異なる方式を使用して、同じ効果が得られることを注記しておく。認証タグの背後にある考えは、ＴＷをトラストレット・タイプおよびセッションＩＤと一緒に、これらが送信中に攻撃者によって切断されることができないように、バインドすることである。これを暗号を使用して達成するには、複数の他の方法がある。本明細書においてＡＥＳ−ＧＣＭについて記載したのは、この機能をネーティブに(natively)提供するからであり、したがって有利であるからである。
【００３８】
[0049]  次いで、ＴＰＨ１５０は、動作５４６において、暗号化ＴＸと、ＴＷの認証付き暗号とを要求元１２０に送ることができる。図５Ａに戻って、図５Ｂの動作によって生成することができる、および／またはＴＷと同様の方法で暗号化された保護データーを含むことができるメッセージ５１６を受信した後、要求元１２０は、動作５１８において、このメッセージをトラストレットに転送することができる。トラストレットはメッセージを解読することができないので（ＴＷにおいて取得しようとする）、トラストレットは、動作５２０において、このメッセージをセキュア・カーネルに渡すことができる。あるいは、要求元１２０が、トラストレットを迂回して、応答をセキュア・カーネルに送ることもでき、セキュア・カーネルは、それがＴＷを解読したときに、トラストレットに新たな情報を気付かせる。
【００３９】
[0050]  次に、動作５２２において、セキュア・カーネルは、その秘密暗号鍵を使用して、ＴＸを解読し、次いでこのＴＸを使用してＴＷを解読し、認証タグを使用して、正しいセッションＩＤを有する正しいトラストレット・タイプが、メッセージを解読することを要求していることを確認することができる。認証タグが検証された場合、動作５２４において、セキュア・カーネルはＴＷをトラストレットに返すことができる。次いで、トラストレットは、受信したＴＷを使用して、任意のサイズでよい保護データーのような、ＴＷが暗号化しているものは何でも、解読することができる。
【００４０】
[0051]  ある態様では、セキュア・カーネルが、メッセージを受信し、解読し、ターゲットにされている正しいトラストレットに渡すために、１つ以上のＡＰＩによって定められるような、１つ以上のプロセスを実装することができる。ＡＰＩは、暗号化され特定のトラストレットがターゲットにされたメッセージを受信し、ＩＤＫ（セキュア・カーネル識別情報暗号鍵）の秘密部分を使用して、ＴＸを解読することができる。ＡＰＩは、コール元トラストレットのトラストレット・タイプとセッションＩＤとの連結(concatenation)をタグとして使用して、それ自体の認証タグを組み立てることができる（明らかなセキュリティ上の理由により、供給された認証タグを使用することはできない）。次いで、トラストレット・タイプおよびセッションＩＤを入手することができる。認証に成功したなら、ＡＰＩは次にＴＸを使用してＴＷを解読することができる。解読に成功したなら、ＡＰＩは次にＴＷをトラストレットに返すことができる。
【００４１】
[0052]  一例では、受信されたメッセージは、次の情報を含むことができる。バージョン数（例えば、０）、転送鍵暗号プロトコルＩＤ（例えば、ＲＳＡ２０４８）、転送鍵暗号パディングＩＤ（例えば、ＯＡＥＰ）、ラッピング・キー暗号プロトコルＩＤ（例えば、ＡＥＳ−ＧＣＭ）、転送鍵暗号文の長さ、ラッピング・キー認証タグの長さ（無視される）、ラッピング・キー暗号文の長さ、ならびに、転送鍵暗号文、ラッピング・キー認証タグ（無視される）、およびラッピング・キー暗号文。尚、これは、メッセージを組み立てることができる多くの方法の中の一例に過ぎないことは、認められてしかるべきである。
【００４２】
[0053]  ある態様では、以上で説明したシステムまたはプロセス１００、３００、４００、または５００の１つ以上において、プロセス／システム１００は、リソース、または仮想セキュア・モード（ＶＳＭ：Virtual Secure Mode）を実装する仮想機械において実装することもできる。仮想機械のコンテキストにおけるＶＳＭおよび関連する概念は、"Virtual Secure Mode for Virtual Machines"（仮想機械のための仮想セキュア・モード）と題し、２０１４年２月２１日に出願された米国特許出願第１４／１８６，４１５号（米国特許出願公開第２０１５／０８２３０５号明細書）に記載されている。図６は、異なる仮想信頼レベルＶＴＬ０  ６１０およびＶＴＬ１  ６１５に分割されたＶＳＭコンピューティング環境を含む、システムまたはホスト・オペレーティング・システム６００を示す。システム６００は、ＶＳＭにおいて動作するコンピューティング環境を含むクラウド・ホスト１８０のような、システム１００ａ、１００ｂ、または１００ｃの１つ以上の態様を更に具体化した実施態様であるとしてもよい。ＶＴＬ０  ６１０は、ユーザ・モード６２０と通常カーネル・モード６３０とを含むことができ、ＶＴＬ１  ６１５は、ユーザ・モード６２５とセキュア・カーネル・モード６３５とを含むことができる。異なるＶＴＬは、例えば、物理コンピューティング・コンポーネントまたは仮想コンピューティング・リソース（例えば、１つ以上の仮想機械）上で実行するハイパーバイザーによって供給することができ、ハイパーバイザーは、ＶＴＬ０  ６１０およびＶＴＬ１  ６１５と相互作用し、特定のプロセス等のためのメモリーへのアクセスに対する制約によってＶＴＬ０  ６１０およびＶＴＬ１  ６１５を定める。図示する例では、ＶＴＬ１  ６１５がＶＴＬ０  ６１０よりも保護されて、ＶＴＬ１と関連付けられたデーターもしくはコードを読み取るおよび／または書き込むためにはより高度なアクセスが要求されるようにしてもよい。ＶＴＬ０  ６１０は、要求元１２０に対応するとしてもよく、一方ＶＴＬ１  ６１５はＴｒＥＥ１４０に対応するとしてもよい。システム６００については、以下で、ＫＰ７００を利用するものとして説明する。しかしながら、これは一例として示すに過ぎず、システム６００は、ＫＰを使用せずに、先に説明した証明／認証方式を利用しても、同様の効果を得ることができる。
【００４３】
[0054]  システム６００を参照しながら説明したように、ホスト６００のクライアント・アプリ６５０／ＶＴＬ０  ６１０は、要求元１２０に対応するとしてもよく、一方ＶＴＬ１  ６１５および更に具体的には、ＶＴＬ１  ６１５のセキュア・カーネル６３５はＴｒＥＥ１４０に対応するとしてもよい。ある態様では、トラストレット６４０が、プロセス５００を参照しながら説明した、ネスト状トラストレットに対応するのでもよい。ある態様では、システム６００が、先に説明したプロセス５００を実装してもよい。他の例では、システム６００は、図８および図９を参照しながら以下で説明するプロセス８００および／または９００を実装することもでき、プロセス５００および８００間における主要な相違は、トラストレットを初期化するためにＫＰを使用すること、そして一層包括的なＴＰＨ１５０の代わりに、ＨＧＳ１５０ａの具体的な実施態様を使用することである。
【００４４】
[0055]  図示のように、１つ以上のＴｒＥＥまたはトラストレット６４０は、ＶＴＬ１  ６１５のユーザ・モード６２５に内在することができる。ある態様では、１つ以上のトラストレット６４０にアクセスすること、または仮想機械セキュア・プロセス（ＶＭＳＰ：Virtual Machine Secure Process）６４５と関連付けることができる。クライアント動作、アプリケーション、プログラム等を含む６５０（クライアント）は、ＶＴＬ０  ６１０のユーザ・モード６２０において動作することができる。ＶＴＬ１  ６１５のユーザ・モード６２５に内在するサーバー６５５は、ＲＰＣ６６０を介して、クライアント６５０と通信することができる。図示のように、クライアント６５０は、例えば、ＶＭＳＰ６４５を利用して、１つ以上のＲＰＣ６６０を介して、１つ以上の安全な動作を実行するために、トラストレット６４０の開始(initiation)を要求することができる。他の態様では、サーバー６５５が、クライアント６５０からの明示的な要求を受けることなく、トラストレット６４０を開始することもできる。いずれの場合であっても、サーバー６５５は、トラストレット（１つまたは複数）６４０を開始することができ、特定のトラストレット・タイプがトラストレットのパラメータを識別し、セッションＩＤがトラストレット６４０の特定のインスタンスを識別する。ある態様では、図１Ｃを参照しながらシステム１００ｃにおいて先に説明したような、ＫＰ４０５を含むデーター構造によって、トラストレット・タイプを初期化することができる。ＫＰ７００のようなＫＰを含むデーター構造の例を図７に示す。
【００４５】
[0056]  データー構造７００は、キー・プロテクター（ＫＰ：key protector）７０５を含むことができる。これは、"Secure Transport of Encrypted Virtual Machines with Continuous Owner Access"（連続所有者アクセスによる暗号化仮想機械の安全な移送）と題し、２０１４年９月９日に出願された米国特許出願第１４／４８１，３９９号（米国特許出願公開第２０１５／３１８９８６号明細書）に記載されているような、暗号鍵（ここでは、トランスポート・キーＴＫ）の暗号ラッピング(cryptographic wrapping)である。ＫＰ７０５は、ＴＫ７１０および／またはその他の保護データーに対するアクセスが、正規エンティティのみに与えられることを確保する。ＴＫ７１０は、ＴｒＥＥ１４０に配信される鍵であり、ＫＰ７０５によって、あるいは場合によってはラッピング・キーまたはＴＷによってラッピングすることができる。ＴＫ７１０は、価値が高い秘密と見なすこともできる。場合によっては、ＴＫ７１０をＫＭＳ１１５において解読することができる。
【００４６】
[0057]  また、データー構造７００は、仮想機械データー（ＶＭＤ：virtual machine data）７３０も含むことができ、仮想機械データー７３０は、トラストレットを初期化するためのデーターを含むことができる。ＶＭＤ７３０は、ワシントン州ＲｅｄｍｏｎｄのＭｉｃｒｏｓｏｆｔ  Ｃｏｒｐｏｒａｔｉｏｎから入手可能なＢｉｔＬｏｃｋｅｒのような、該当する暗号化技術を使用して暗号化することができる。フル・ボリューム暗号鍵（ＦＶＥＫ：full volume encryption key）７２５は、ＶＭＤ７３０を解読するために使用することができ、仮想信頼プラットフォーム・モジュール（ＶＴＰＭ：virtual trusted platform module）によって保護することができる。その状態（７２５）は、暗号化され、メタデーターの一部としてＫＰ７０５と共に格納される。ある態様では、ＦＶＥＫ７２５は、ボリューム・マスター・キー（ＶＭＫ）７２０によって暗号化することもできる。ＶＴＰＭ状態７２５自体は、ＫＰ７０５によってラッピングされた鍵を使用して暗号化される。ある態様では、ＶＴＰＭ７２５は、ＰＣＲ値が予測された状態にある場合、ＴＰＭが鍵素材へのアクセス、例えば、解読を許可するように、ＴＫ７１０（価値が高い秘密）およびＰＣＲ値に対する「密封」(seal)データー（例えば、ＰＣＲ７）によって暗号化することもできる。この場合、ＴＰＭプロテクタは、１つ以上のＰＣＲが予測された状態にある場合何らかの秘密を開封する(unseal)ためにＴＰＭに供給されるデーター構造である。その他の場合、非ＴＰＭプロテクタも同様に使用することができる。
【００４７】
[0058]  ボリューム・マスター・キー（ＶＭＫ）７２０は、ＶＴＰＭ７２５によって開封することができる。ＶＴＰＭ状態７２５は、ＫＰ７０５内部でＴＫ７１０によって暗号化することができる。場合によっては、ＶＭＫ７２０がビットロッカー・ボリューム・マスター・キー(Bitlocker Volume Master Key)であってもよく、価値が低い秘密という印を付けることができる。
【００４８】
[0059]  ＫＰ７００の各フィールドまたはブロックは、暗号（鍵、データー）表記のように、それが暗号化するものに関して記述することもできる。
ＶＭＤＤＩＳＫ：暗号（ＦＶＥＫ、平文ディスク・データー）
ＦＶＥＫＤＩＳＫ：暗号（ＶＭＫ、ＦＶＥＫ）
ＶＭＫＤＩＳＫ：暗号（ＶＭＫ）
ＶＴＰＭＤＩＳＫ：暗号（ＴＫ、ＶＴＰＭ）
ＴＫＤＩＳＫ：暗号（ＫＰ、ＴＫ）
ＫＰ：ＫＰは、ＶＭと関連付けられ、トラストレットは実際には決してそれを見るには至らない。ＫＰはＫＭＳに送られ(goes to)、ＫＭＳはそれを解読し、ＴＫをトラストレットに返す（先に説明したターゲティング・メカニズムによって）。ＴＫはｖＴＰＭを解読し、ｖＴＰＭはＶＭＫを開封し、ＦＶＥＫを生成する。
【００４９】
[0060]  一例では、ＫＰ４０５、ＶＴＰＭ状態４１５、ＶＭＫ４２０、およびＶＭＤ４３０は、ディスク上に格納されたデーターであってもよい。ＶＴＰＭ状態４１５は、ＶＴＰＭが作成されたときに初期化されてもよく、一意であることが確保されればよい。例えば、生成された秘密または保護データーのランタイム一意性について、ＶＴＰＭはセキュア・カーネルによって提供されるＲＮＧのセキュリティを頼りにする。トラストレットが解読されたＴＫ７１０を使用してＶＴＰＭ状態４１５を解読した後、ＶＭＤ７３０にアクセスするための残りの動作は、物理機械と物理ＴＰＭとの間で実行される動作と同じまたは同様であってよい。これらの動作には、ＶＴＰＭがＶＳＭの測定を実行すること、ＶＴＰＭ測定値を使用してＶＭＫを開封すること（その結果、ＦＶＥＫ７２５をオペレーティング・システムのローダーに供給することになる）、およびオペレーティング・システムがＦＶＥＫ７２５を使用してＶＭＤ７３０を解読することを含むことができる。
【００５０】
[0061]  トラストレットを起動するために、クライアント６５０はデーター構造７００を要求する、および／または受け取ることができる。クライアント６５０は、ＫＰ７０５またはデーター構造７００全体をＴＰＨ１５０に送ることができ（または、ある実施態様では、ＨＧＳ１５０ａ）、ＴＰＨ１５０は、ＴＫ７１０を解読するために、ＫＭＳ１１５と通信することができる。次いで、ＴＰＨは、例えば、以下で説明するプロセス８００によって、ＩＤＫ＿ｐｕｂ６６５を利用して、トラストレット６４０と関連付けられたセキュア・カーネル６３５において、ＴＫ７１０をターゲットにすることができる。セキュア・カーネル６３５は、起動時に、ＩＤＫ＿ｐｕｂおよびＩＤＫ＿ｐｒｉを入手することができる。セキュア・カーネル６３５は、その秘密鍵６７５（例えば、ＩＤＫ＿ｐｒｉ）を使用して、ＴＫ７１０を解読しサーバー６５５に返すことができる。次いで、サーバー６５５はＴＫ７１０をトラストレット６４０に配信することができる。場合によっては、セキュア・カーネル６３５はＴＫ７１０を直接トラストレット６４０に返すこともできる。ある態様では、保護データーをＴＫ７１０と共にトラストレット６４０に配信し、ＴＫ７１０によって暗号化することができる。このように、トラストレット６４０は、ＴＫ７１０を使用して、保護データーを解読することができる。
【００５１】
[0062]  図８は、ＴｒＥＥまたはトラストレットの識別鍵(identity key)を使用して、トランスポート・キーおよび／またはこのトランスポート・キーによって暗号化された保護データーを、ＴｒＥＥまたは特定のトラストレットに導くためのプロセス例８００を示す。更に具体的には、プロセス８００は、トラストレットのセキュア・カーネルの暗号鍵によって、トラストレットをターゲットにする方法を示す。
【００５２】
[0063]  クラウド・ファブリック・ホストまたはホストＯＳ（例えば、ホストＯＳ６００）は、トランスポート・キーを受け取るために一連のステップを実行する。クラウド・ファブリック・ホストは、最初に、図４Ｂを参照しながら先に説明したプロセスにしたがってというようにして、動作６０２において、例えば、ＴｒＥＥまたはトラストレットと関連付けられたセキュア・カーネルの暗号識別鍵（ＩＤＫ＿Ｅ）の周囲に作られた(build)ＴｒＥＥ健康証明書（ＴＨＣ）を入手することができる。１つの態様では、動作６０２は、ＩＤＫ＿Ｅの公開バージョンを収容するブートにおいて、ホストによって証明ログ（ＴＣＧログ）を作成する動作を含むことができ、ＩＤＫ＿Ｅの秘密部分は、トラストレットと関連付けられたＶＳＭセキュア・カーネル（ＳＫ）内に存在する。証明ログは、証明サービス（ＡＳ）に提示することができる。ＡＳは、この証明ログを検査し、ＩＤＫ＿Ｅの周囲に作られたＴＨＣ（例えば、非対称鍵の公開部分）をホストに発行することができる。ある態様では、ＩＤＫ＿Ｅと同様、「署名識別鍵」（ＤＤＫ＿Ｓ）も作成することができ、図９を参照して以下で更に詳しく説明するように、署名識別鍵はその周囲に作られた別個のＴＨＣを有することができる。鍵配信問題に対する解決策は、以下で説明するように、ＩＤＫ＿ＥまたはＩＤＫ＿Ｓのいずれかを使用して構築することができる。
【００５３】
[0064]  新たな遮蔽(shielded)ＶＭをロードするときが来たとき、ホストは、動作８０４において、ＶＭのＫＰを入手し、ＴＰＨ（例えば、ＴＰＨ１５０）との会話(conversation)を開始する。その目的は、ＫＰによって暗号化されたＴＫをＶＭＳＰトラストレットに注入することである。
【００５４】
[0065]  ＫＰをＴＫと交換するために、ホストは、動作８０６において、ＴＰＨ１５０のようなＴＰＨに、ＫＰおよび「トランスレット識別情報」を、ＴＨＣと共に、提示することができる。また、クラウド・ファブリック・ホストは、動作８０８において、ＫＰから導き出された「セッションＩＤ」（ＫＰＳＩＤ）を有するトラストレットまたはＴｒＥＥを開始することもできる。ある態様では、受信したＫＰが、ＳＨＡ−２ハッシュをそれに対して作成する、または他の一方向関数を利用することによって、セッションＩＤ値の基礎を形成する。ＴＰＨは、動作８２２において、ＴＨＣを検査し、動作８２４において、ＫＰを解読してＴＫにアクセスするために、ＫＭＳ１１５のようなＫＭＳ、あるいは所有する他のエンティティ、もしくは保護データーおよび／またはＫＰに対する解読鍵にアクセスすることができる他のエンティティと通信することができる。動作８２６において、ＴＰＨは、例えば、プロセス５００を参照しながら先に説明したように、特殊な暗号構成を使用して、計算したＫＰＳＩＤを有するトラストレットをターゲットにすることができる。
【００５５】
[0066]  要求元またはクライアント６５０は、ＴＰＨからの応答を受信し、与えられたＫＰＳＩＤと共にそれをトラストレットに転送することができる。トラストレットまたはサーバーは、動作８１０において、ＳＶＭセキュア・カーネルに、応答を解読しそれをＴＫに返すように要請することができる。セキュア・カーネルは、動作８１２において、応答を検査し、それがトラストレット・タイプおよびトラストレットのセッションＩＤをターゲットにすることの有効性を判断し(validate)、動作８１８において、一致がある場合、鍵だけを返す。このため、ＴＰＨの応答が悪の手に落ちた場合でも、意味を理解することは暗号的に不可能である。この鍵を受信したとき、ホストは、動作８２０において、この鍵を解読してＴｒＥＥに供給し、この時点で、プロセス８００は終了することができる。
【００５６】
[0067]  図９は、セキュア・カーネルの署名鍵を使用して、トランスポート・キーおよび／またはこのトランスポート・キーによって暗号化された保護データーをトラストレットに導くための他のプロセス例９００を示す。更に具体的には、プロセス９００は、セキュア・カーネルの署名鍵によって証明されたトラストレットの暗号鍵によって、このトラストレットをターゲットにする方法を示す。
【００５７】
[0068]  プロセス８００は、全てのトラストレット間で共有される識別暗号鍵によって、どのように応答を間接的にトラストレットに導くことができるかを示す。しかしながら、ＴｒＥＥが証明可能な識別署名鍵を有する場合、他の手法も使用してもよい。ここでは、各トラストレットがそれ自体の暗号鍵対を生成し、この対の公開鍵部であるＩＤＫ＿Ｓを使用して、セキュア・カーネルに証明させることができる。尚、このような証明は、鍵をトラストレット・タイプおよびトラストレットのセッションＩＤに暗号的にバインドすることも必要であることを注記しておく。
【００５８】
鍵の証明＝σＩＤＫ＿Ｓ（Ｔｒｕｓｔｌｅｔ＿Ｅｎｃｒｙｐｔｉｏｎ＿Ｋｅｙ＿Ｐｕｂ，  Ｔｒｕｓｔｌｅｔ＿Ｔｙｐｅ，  Ｓｅｓｓｉｏｎ＿ＩＤ）
ここで、σＩＤＫ＿Ｓは、与えられた鍵を使用する、その入力（）、およびそれに続くこれらの入力に対する署名の連結を示す。
【００５９】
この場合、要求元は、トラストレットの鍵を、ＴＨＣおよび鍵証明(key certification)と共にＴＰＨに提示し、ＴＰＨは、動作８２２および８２４において、プロセス８００から差別化されるように、トランスポート・キーを暗号化してトラストレットの暗号鍵にすることによって応答する。
【００６０】
[0069]  ある態様では、「セキュリティ・バージョン番号」（ＳＶＮ：security version number）も、他の種類の攻撃を防止し、ＴｒＥＥが古くなく、潜在的に攻撃されやすいバージョンではないことを確認するために、鍵証明において使用または指示されてもよい。場合によっては、セキュア・カーネルは証明されたが、内側トラストレットはされないならば（例えば、証明が既に行われた後に、トラストレットに要求(demand)がロードされた場合）、トラストレットのＳＶＮを含ませることによって、ＴＨＣには問題がなくても(okay)、古い方の攻撃されやすいトラストレットをターゲットにすることを拒否するように、ＴＰＨ１５０に命令することができる。
【００６１】
[0070]  プロセス８００および９００の２つの手法間における相違の１つは、トラストレットまたはＴｒＥＥ  ＩＤ、セッションＩＤ、およびトランスポート・キー間のバインドを実施するのは何か、ということである。プロセス８００では、それはセキュア・カーネルであり、プロセス９００では、それはＴＰＨ１５０である。他の主要な相違には、どのようにして応答を暗号的に構成するか(structure)があげられる。前者の場合では、応答はセキュア・カーネルに導かれ、次いで、セキュア・カーネルは、どのトラストレットが応答を見ることを許可されるか判断する。後者の場合では、応答は直接トラストレットに導かれ、トラストレットの鍵はセキュア・カーネルの鍵によって証明される。
【００６２】
[0071]  ある態様では、以上で説明した技法は、コンテナに対する完全な資格証明の分離(credential isolation)に対応するために実装することもできる。基本的な問題は同じであり、コンテナはそのホストに資格証明書を要求すればよい。次いで、ホストはコンテナの代わりに何らかのＫＭＳに資格証明書を要求することができる。要求された資格証明書が暗号化されずにホストに返された場合（例えば、資格証明書が要求に応じて到達し、コンテナ・イメージの一部でない）、「遅い資格証明バインド」(late credential binding)となる。このバインドは、有益であるが、資格証明書の分離には至らず、ホストが不正アクセスされた場合、資格証明書が開示されることになる。
【００６３】
[0072]  実施形態において、コンピューティング・システムは、
[0073]  プロセッサーと、
[0074]  プロセッサーに通信可能に結合されたメモリーと、
を備える。メモリーは、命令を格納し、プロセッサーによって命令が実行されると、コンピューティング・システムに次の動作を実行させる。
【００６４】
[0075]  ネスト状ＴｒＥＥと関連付けられた、潜在的に信頼できない要求元からの保護データーを求める要求と、セキュア・カーネルの証明報告書とを受け取る動作であって、ネスト状ＴｒＥＥが、セキュア・カーネル上で実行するトラストレットを備え、トラストレットがトラストレットＩＤと関連付けられる。
【００６５】
[0076]  証明報告書から導き出された第２暗号鍵で転送暗号鍵を暗号化する動作。
[0077]  保護データーを引き出す動作。
[0078]  転送暗号鍵および認証タグによって保護データーを暗号化する動作であって、認証タグが要求元をトラストレットＩＤとバインドする。
【００６６】
[0079]  暗号化した転送暗号鍵、暗号化した保護データー、および暗号化した認証タグを要求元に供給する。
[0080]  ２．請求項１記載のコンピューティング・システムにおいて、トラストレットＩＤが、トラストレット・タイプおよびセッションＩＤを含む。請求項１記載のコンピューティング・システムにおいて。
【００６７】
[0081]  実施形態では、第２暗号鍵がセキュア・カーネル暗号鍵を含む。
[0082]  実施形態では、セキュア・カーネル暗号鍵に対応する秘密セキュア・カーネル暗号鍵が、暗号化した保護データーを解読するために必要とされる。
【００６８】
[0083]  実施形態では、前述の命令が追加命令を含み、プロセッサーによって追加命令が実行されると、コンピューティング・システムに以下の動作を実行させる。
[0084]  トラストレットＩＤを 認可トラストレットＩＤのリストと比較する動作。
【００６９】
[0085]  トラストレットＩＤが、認可トラストレットＩＤのリストと関連付けられる場合にのみ、転送暗号鍵および認証タグで保護データーを暗号化する動作。
[0086]  実施形態では、セキュア・カーネル上で実行するトラストレットを備えるネスト状信頼実行環境（ＴｒＥＥ）に保護データーを配信する方法において、トラストレットおよびセキュア・カーネルが双方共、潜在的に信頼できない要求元と関連付けられる。この方法は、以下のステップを含む。
【００７０】
[0087]  ターゲティング・プロトコル・ヘッドによって、ネスト状ＴｒＥＥと関連付けられた潜在的に信頼できない要求元からの保護データーを求める要求と、セキュア・カーネルの証明報告書とを受け取るステップであって、トラストレットがトラストレットＩＤと関連付けられる。
【００７１】
[0088]  証明報告書から導き出された第２暗号鍵で転送暗号鍵を暗号化するステップ。
[0089]  ターゲティング・プロトコル・ヘッドによって、保護データーを引き出すステップ。
【００７２】
[0090]  転送暗号鍵および認証タグによって保護データーを暗号化するステップであって、認証タグが要求元をトラストレットＩＤとバインドする。
[0091]  暗号化した転送暗号鍵、暗号化した保護データー、および暗号化した認証タグを要求元に供給するステップ。
【００７３】
[0092]  実施形態では、トラストレットＩＤがトラストレット・タイプとセッションＩＤとを含む。
[0093]  実施形態では、第２暗号鍵がセキュア・カーネル暗号鍵を含む。
【００７４】
[0094]  実施形態では、セキュア・カーネル暗号鍵に対応する秘密セキュア・カーネル暗号鍵が、暗号化した保護データーを解読するために必要とされる。
[0095]  実施形態では、この方法は、更に、以下のステップを含む。
【００７５】
[0096]  潜在的に信頼できない要求元によって、暗号化した転送暗号鍵と、認証付き暗号化保護データー(authenticated encrypted protected data)とを受け取るステップ。
[0097]  潜在的に信頼できない要求元によって、暗号化した転送暗号鍵と、認証付き暗号化保護データーとをセキュア・カーネルに送るステップであって、セキュア・カーネルは、第２暗号鍵に対応する秘密第２暗号鍵で転送鍵を解読し、解読した転送鍵で保護データーを解読する。
【００７６】
[0098]  実施形態では、潜在的に信頼できない要求元によって、暗号化した転送暗号鍵と、認証付き暗号化保護データーとをセキュア・カーネルに送るステップが、暗号化した転送暗号鍵と、認証付き暗号化保護データーとをトラストレットに送るステップを含み、トラストレットが、暗号化した転送暗号鍵と、認証付き暗号化保護データーとをセキュア・カーネルに転送する。
【００７７】
[0099]  実施形態では、セキュア・カーネルが、認証付き暗号化保護データーがトラストレットに向けられたものであることを、トラストレット・タイプおよびセッションＩＤに基づいて確認し、トラストレット・タイプおよびセッションＩＤに基づいて、解読した保護データーをトラストレットに送る。
【００７８】
[00100]  実施形態では、保護データーがラッピング・キーを含む。
[00101]  実施形態では、この方法は、更に、以下のステップを含む。
[00102]  ターゲティング・プロトコル・ヘッドによって、トラストレットＩＤを、認可トラストレットＩＤのリストと比較するステップ。
【００７９】
[00103]  トラストレットＩＤが、認可トラストレットＩＤのリストと関連付けられる場合にのみ、ターゲティング・プロトコル・ヘッドによって、転送暗号鍵および認証タグで保護データーを暗号化するステップ。
【００８０】
[00104]  実施形態では、コンピューター読み取り可能記憶媒体が、セキュア・カーネル上で実行するトラストレットを備えるネスト状信頼実行環境（ＴｒＥＥ）に保護データーを配信するための命令を含む。この媒体は命令を含み、コンピューター・システムによって命令が実行されると、少なくとも以下の動作を、コンピューター・システムに実行させる。
【００８１】
[00105]  ネスト状ＴｒＥＥと関連付けられた潜在的に信頼できない要求元からの保護データーを求める要求と、セキュア・カーネルの証明報告書とを受け取る動作であって、トラストレットがトラストレットＩＤと関連付けられる。
【００８２】
[00106]  証明報告書から導き出された第２暗号鍵で転送暗号鍵を暗号化する動作。
[00107]  保護データーを引き出す動作。
[00108]  転送暗号鍵および認証タグによって保護データーを暗号化する動作であって、認証タグが要求元をトラストレットＩＤとバインドする。
【００８３】
[00109]  暗号化した転送暗号鍵、暗号化した保護データー、および暗号化した認証タグを要求元に供給する動作。
[00110]  実施形態では、トラストレットＩＤが、トラストレット・タイプとセッションＩＤとを含む。
【００８４】
[00111]  実施形態では、第２暗号鍵が、セキュア・カーネル暗号鍵を含む。
[00112]  実施形態では、セキュア・カーネル暗号鍵に対応する秘密セキュア・カーネル暗号鍵が、暗号化した保護データーを解読するために必要とされる。
【００８５】
[00113]  実施形態では、保護データーがラッピング・キーを含む。
[00114]  実施形態では、命令は、更に、コンピューティング・システム上で実行されると、コンピューティング・システムに、少なくとも以下の動作を実行させる命令を含む。
【００８６】
[00115]  トラストレットＩＤを、認可トラストレットＩＤのリストと比較する動作。
[00116]  トラストレットＩＤが、認可トラストレットＩＤのリストと関連付けられる場合にのみ、転送暗号鍵および認証タグで保護データーを暗号化するステップ。
【００８７】
[00117]  以上で説明した技法は、以下で説明するように、１つ以上のコンピューティング・デバイスまたは環境上で実装することができる。図１０は、例えば、要求元１２０、ＴｒＥＥ１４０、ＴＰＨ１５０、ホストＯＳ６００、ＡＳ４２４、ＫＭＳ１１５の内１つ以上を具体化することができる汎用コンピューティング環境の例を表す。本明細書において説明した技法のいくつかを具体化することができる。コンピューティング・システム環境１００２は、適したコンピューティング環境の一例に過ぎず、ここに開示した主題の使用範囲や機能に関して限定を示唆することは全く意図していない。また、コンピューティング環境１００２が、動作環境例１００２において示されるコンポーネントの内いずれか１つまたは組み合わせに関して、何らかの依存性や要件を有するように解釈してはならない。ある実施形態では、種々の図示するコンピューティング・エレメントが、本開示の特定の態様をインスタンス化するように構成された回路を含むこともできる。例えば、本開示において使用する回路(circuitry)という用語は、ファームウェアまたはスイッチによって機能（１つまたは複数）を実行するように構成された特殊ハードウェア・コンポーネントを含むことができる。他の実施形態例では、回路という用語は、汎用処理ユニット、メモリー等を含み、機能（１つまたは複数）を実行するように動作可能なロジックを具体化するソフトウェア命令によって構成される。回路がハードウェアおよびソフトウェアの組み合わせを含む実施形態例では、実施者(implementer)がロジックを具体化するソース・コードを書くのでもよく、このソース・コードは、汎用処理ユニットによって処理することができる、機械読み取り可能コードにコンパイルすることができる。技術的現状はハードウェア、ソフトウェア、またはハードウェア／ソフトウェアの組み合わせの間の差が殆どなくなるところまで発展したことは当業者は認めることができるはずであるので、特定の機能を実装するためにハードウェアまたはソフトウェアのどちらを選択するかは、実施者に委ねられる設計の選択事項に過ぎない。更に具体的には、ソフトウェア・プロセスを等価のハードウェア構造に変換でき、ハードウェア構造自体を等価なソフトウェア・プロセスに変換できることは、当業者は認めることができる。つまり、ハードウェアの実施態様かまたはソフトウェアの実施態様かの選択は、設計選択事項の１つであり、実施者に委ねられる。
【００８８】
[00118]  コンピューター１００２は、移動体デバイスまたはスマート・フォン、タブレット、ラップトップ、デスクトップ・コンピューター、またはネットワーク接続されたデバイスの集合体、クラウド・コンピューティング・リソース等の内任意のものを含むことができ、通例、種々のコンピューター読み取り可能媒体を含む。コンピューター読み取り可能媒体は、コンピューター１００２によってアクセスすることができる任意の入手可能な媒体とすることができ、揮発性および不揮発性双方の媒体、リムーバブルおよび非リムーバブル媒体を含む。システム・メモリー１０２２は、リード・オンリー・メモリー（ＲＯＭ）１０２３およびランダム・アクセス・メモリー（ＲＡＭ）１０６０のような、揮発性および／または不揮発性メモリーの形態のコンピューター読み取り可能記憶媒体を含む。 基本入力／出力システム１０２４（ＢＩＯＳ）は、起動中のように、コンピューター１００２内部のエレメント間で情報を転送するのを助ける基本的なルーチンを収容し、通例ＲＯＭ１０２３に格納されている。ＲＡＭ１０６０は、通例、処理ユニット１０５９に直ちにアクセス可能な、および／または処理ユニット１０５９上で現在処理されているデーターおよび／またはプログラム・モジュールを収容する。一例として、そして限定ではなく、図１０は、オペレーティング・システム１０２５、アプリケーション・プログラム１０２６、ＴｒＥＥターゲティング・アプリケーション１０６５を含むその他のプログラム・モジュール１０２７、およびプログラム・データー１０２８を示す。
【００８９】
[00119]  また、コンピューター１００２は、その他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体も含むことができる。一例としてに過ぎないが、図１０は、非リムーバブル不揮発性磁気媒体に対する読み出しまたは書き込みを行うハード・ディスク・ドライブ１０３８、リムーバブル不揮発性磁気ディスク１０５４に対する読み出しまたは書き込みを行う磁気ディスク・ドライブ１０３９、およびＣＤ  ＲＯＭまたはその他の光媒体のようなリムーバブル不揮発性光ディスク１０５３に対する読み出しまたは書き込みを行う光ディスク・ドライブ１００４を示す。動作環境例において使用することができるその他のリムーバブル／非リムーバブル、揮発性／不揮発性コンピューター記憶媒体には、磁気テープ・カセット、フラッシュ・メモリー・カード、ディジタル・バーサタイル・ディスク、ディジタル・ビデオ・テープ、ソリッド・ステートＲＡＭ、ソリッド・ステートＲＯＭ等が含まれるが、これらに限定されるのではない。ハード・ディスク・ドライブ１０３８は、通例、インターフェース１０３４のような非リムーバブル・メモリー・インターフェースを介して、システム・バス１０２１に接続され、更に、磁気ディスク・ドライブ１０３９および光ディスク・ドライブ１００４は、通例、インターフェース１０３５または１０３６のようなリムーバブル・メモリー・インターフェースによって、システム・バス１０２１に接続される。
【００９０】
[00120]  以上で論じ図１０に示したドライブおよびそれらに付随するコンピューター記憶媒体は、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、およびコンピューター１００２のためのその他のデーターのストレージを提供する。図１０において、例えば、ハード・ディスク・ドライブ１０３８は、オペレーティング・システム１０５８、アプリケーション・プログラム１０５７、その他のプログラム・モジュール１０５６、およびプログラム・データー１０５５を格納するものとして示されている。尚、これらのコンポーネントは、オペレーティング・システム１０２５、アプリケーション・プログラム１０２６、その他のプログラム・モジュール１０２７、およびプログラム・データー１０２８と同じであることも、異なることも可能である。オペレーティング・システム１０５８、アプリケーション・プログラム１０５７、その他のプログラム・モジュール１０５６、およびプログラム・データー１０５５には、ここでは異なる番号が与えられているのは、少なくとも、これらが異なるコピーであることを示すためである。ユーザーは、一般にマウス、トラックボール、またはタッチ・パッドと呼ばれる、キーボード１０５１およびポインティング・デバイス１０５２のような、入力デバイスを介して、コマンドおよび情報をコンピューター１００２に入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナー、網膜スキャナー等を含むこともできる。これらおよびその他の入力デバイスは、多くの場合、システム・バス１０２１に結合されたユーザー入力インターフェース１０３６を介して、処理ユニット１０５９に接続されるが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）のような他のインターフェース、およびバス構造によって接続されてもよい。モニター１０４２またはその他の型式のディスプレイ・デバイスも、ビデオ・インターフェース１０３２のようなインターフェースを介して、システム・バス１０２１に接続される。モニターに加えて、コンピューターは、スピーカー１０４４およびプリンター１０４３のような他の周辺出力デバイスも含むことができ、これらは出力周辺インターフェース１０３３を介して接続することができる。
【００９１】
[00121]  コンピューター１００２は、リモート・コンピューター１０４６のような、１つ以上のリモート・コンピューターへの論理接続を用いて、ネットワーク接続環境において動作することもできる。リモート・コンピューター１０４６は、パーソナル・コンピューター、サーバー、ルーター、ネットワークＰＣ、ピア・デバイスまたは他の一般的なネットワーク・ノードであってもよく、通例、コンピューター１００２に関して以上で説明したエレメントの多くまたは全部を含むことができるが、図１０には、メモリー記憶デバイス１０４７しか示されていない。図１０に示す論理接続は、ローカル・エリア・ネットワーク（ＬＡＮ）１０４５およびワイド・エリア・ネットワーク（ＷＡＮ）１０４９を含むが、他のネットワークを含むこともできる。このようなネットワーク接続環境は、事務所、企業規模のコンピューター・ネットワーク、イントラネット、インターネット、およびクラウド・コンピューティング・リソースでは極普通である。
【００９２】
[00122]  ＬＡＮネットワーク接続環境において用いられる場合、コンピューター１００２は、ネットワーク・インターフェースまたはアダプター１０３７を介してＬＡＮ１０４５に接続することができる。ＷＡＮネットワーク接続環境において使用される場合、コンピューター１００２は、通例、モデム１００５、またはインターネットのようなＷＡＮ１０４９上で通信を確立する他の手段を含む。モデム１００５は、内蔵型でも外付け型でもよく、ユーザー入力インターフェース１０３６または他のしかるべきメカニズムを介してシステム・バス１０２１に接続することができる。ネットワーク接続環境では、コンピューター１００２に関して図示したプログラム・モジュールまたはその一部が、リモート・メモリー記憶デバイスに格納されてもよい。一例として、そして限定ではなく、図１０は、リモート・アプリケーション・プログラム１０４８を、メモリー・デバイス１０４７上に存在するものとして示す。尚、 図示するネットワーク接続は例であり、コンピューター間で通信リンクを確立する他の手段を用いてもよいことは認められよう。
【００９３】
[00123]  ある態様では、その他のプログラム１０２７は、先に説明したような機能を含む、ＴｒＥＥターゲティング・コンポーネントまたはアプリケーション１０６５を含むこともできる。場合によっては、ＴｒＥＥターゲティング・アプリケーション１０６５は、プロセス３００、４００、５００、８００、および／または９００の動作の一部または全部を実行することができる。
【００９４】
[00124]  以上の章において説明したプロセス、方法、およびアルゴリズムの各々は、１つ以上のコンピューターまたはコンピューター・プロセッサーによって実行されるコード・モジュールにおいて具体化し、コード・モジュールによって完全にまたは部分的に自動化することができる。コード・モジュールは、ハード・ドライブ、ソリッド・ステート・メモリー、光ディスク等のような、任意の型式の非一時的コンピューター読み取り可能媒体またはコンピューター記憶デバイス上に格納することができる。プロセスおよびアルゴリズムは、部分的にまたは全体的に、特定用途回路内に実装することもできる。開示したプロセスおよびプロセス・ステップの結果は、例えば、揮発性または不揮発性ストレージのような、任意の種類の非一時的コンピューター・ストレージに、永続的にまたはそれ以外で、格納することができる。以上で説明した種々の特徴およびプロセスは、互いに独立して使用されてもよく、または種々の方法で組み合わされてもよい。全ての可能なコンビネーションおよびサブコンビネーションは、本開示の範囲内に該当することを意図している。加えて、特定の方法またはプロセス・ブロックは、実施態様によっては、省略されてもよい。本明細書において説明した方法およびプロセスは、いずれの特定のシーケンスにも限定されず、それに関係するブロックまたは状態は、しかるべき他のシーケンスで実行することができる。例えば、説明したブロックまたは状態は、特定的に開示したもの以外の順序で実行されてもよく、複数のブロックまたは状態を組み合わせて１つのブロックまたは状態にしてもよい。ブロックまたは状態の例は、連続して、並列に、または何らかのその他の様態で実行することができる。開示した実施形態例にブロックまたは状態を追加することも、削除することも可能である。本明細書において説明したシステム例およびコンポーネント例は、説明したもとのは異なる構成にしてもよい。例えば、開示した実施形態例と比較して、エレメントを追加すること、削除すること、または再構成することもできる。
【００９５】
[00125]  また、種々の品目が、使用されている間メモリー内またはストレージ上に格納されているように示されたこと、そしてこれらの品目またはその一部は、メモリー管理およびデーター保全の目的のために、メモリーと他の記憶デバイスとの間で転送されてもよいことは認められよう。あるいは、他の実施形態では、ソフトウェア・モジュールおよび／またはシステムの一部または全部が、他のデバイス上にあるメモリーにおいて実行し、コンピューター間通信によって、図示したコンピューティング・システムと通信するのでもよい。更に、ある実施形態では、システムおよび／またはモジュールの一部または全部が、少なくとも部分的にファームウェアおよび／またはハードウェアでというように、他の方法で実装または提供されてもよく、ファームウェアおよび／またはハードウェアには、１つ以上の特定用途集積回路（ＡＳＩＣ）、標準的集積回路、コントローラー（例えば、しかるべき命令を実行することによるコントローラーであり、マイクロコントローラーおよび／または埋め込み型コントローラーを含む）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、複合プログラマブル論理デバイス（ＣＰＬＤ）等が含まれるが、これらに限定されるのではない。また、モジュール、システム、およびデーター構造の一部または全部は、しかるべきドライブによってまたはしかるべき接続を介して読み取るために、ハード・ディスク、メモリー、ネットワークまたは携帯用メディア商品というような、コンピューター読み取り可能媒体上に（例えば、ソフトウェア命令または構造化されたデーターとして）格納することもできる。本明細書および請求項に限って言えば、「コンピューター読み取り可能記憶媒体」という用語およびその変形は、波形、信号、および／またはその他の一時的および／または無形(intangible)通信媒体を含まない。また、システム、モジュール、およびデーター構造は、ワイヤレス系および有線／ケーブル系媒体を含む、種々のコンピューター読み取り可能送信媒体上において生成されたデーター信号（例えば、搬送波あるいはその他のアナログまたはディジタル伝搬信号の一部として）送信することもでき、種々の形態をなすこともできる（例えば、１つまたは多重化アナログ信号の一部として、あるいは複数のディスクリート・ディジタル・パケットまたはフレームとして）。このようなコンピューター・プログラム製品は、他の実施形態では、他の形態をなすこともできる。したがって、本開示は、他のコンピューター・システム構成でも実施することができる。
【００９６】
[00126]  とりわけ、「できる」(can)、「であればできた」(could)、「かもしれない」(might) 、「してもよい」(may)、「例えば」(e.g.)等のような、本明細書において使用した条件付き表現は、別段特に明言されていなければ、または使用される文脈において他の意味に理解される場合を除き、一般に、特定の実施形態は特定の特徴、エレメント、および／またはステップを含むが、他の実施形態はこれらを含まないことを伝えることを意図している。つまり、このような条件付き文言は、一般に、特徴、エレメント、および／またはステップが１つ以上の実施形態に対して多少なりとも必要であることを含意することを意図するのではなく、あるいは１つ以上の実施形態が、これらの特徴、エレメント、および／またはステップがいずれかの特定の実施形態に含まれるか否か、あるいは実行されるか否かについて、著者(author)の入力または催促の有無には関係なく決定するロジックを必然的に含むことを含意することを意図するのでもない。「備える」(comprising)、「含む」(including)、「有する」(having)等の用語は、同意義語であり、包含的に使用され、追加のエレメント、特徴、アクト、動作等を除外しない。また、「または」(or)という用語は、その包含的な意味で使用される（そして、その除外的意味ではない）ので、例えば、エレメントのリストを接続するために使用される場合、「または」という用語は、そのリストにおけるエレメントの１つ、いくつか、または全部を意味する。
【００９７】
[00127]  以上、特定の実施形態例について説明したが、これらの実施形態は一例として提示されたに過ぎず、本明細書において開示した発明の範囲を限定することを意図するのではない。つまり、以上の説明において、何らかの特定の特徴、特性、ステップ、モジュール、またはブロックが必須である、または不可欠であることを含意することを意図するものはない。実際、本明細書において説明した新規な方法およびシステムは、種々の他の形態で具体化することもでき、更に、本明細書において説明した方法およびシステムの形態における種々の省略、交換、および変更も、本明細書において開示した発明の主旨から逸脱することなく、行うことができる。添付する特許請求の範囲およびその均等物は、本明細書において開示した発明の内特定のものの範囲および主旨に該当するような形態および変更に及ぶことを意図している。
【図１Ａ】
2020506612.tif 000003
【図１Ｂ】
2020506612.tif 000004
【図１Ｃ】
2020506612.tif 000005
【図２】
2020506612.tif 000006
【図３】
2020506612.tif 000007
【図４Ａ】
2020506612.tif 000008
【図４Ｂ】
2020506612.tif 000009
【図５Ａ】
2020506612.tif 000010
【図５Ｂ】
2020506612.tif 000011
【図６】
2020506612.tif 000012
【図７】
2020506612.tif 000013
【図８】
2020506612.tif 000014
【図９】
2020506612.tif 000015
【図１０】
2020506612.tif 000016
【国際調査報告】
2020506612.tif 000017
2020506612.tif 000018