JP6777288B2 - Processor - Google Patents
Processor Download PDFInfo
- Publication number
- JP6777288B2 JP6777288B2 JP2019020537A JP2019020537A JP6777288B2 JP 6777288 B2 JP6777288 B2 JP 6777288B2 JP 2019020537 A JP2019020537 A JP 2019020537A JP 2019020537 A JP2019020537 A JP 2019020537A JP 6777288 B2 JP6777288 B2 JP 6777288B2
- Authority
- JP
- Japan
- Prior art keywords
- enclave
- key
- page
- epc
- instruction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Storage Device Security (AREA)
- Memory System Of A Hierarchy Structure (AREA)
Description
本発明の実施形態は概して、情報処理分野に係り、より詳しくは、コンピューティングシステムおよびマイクロプロセッサのセキュリティ分野に係る。 Embodiments of the present invention generally relate to the field of information processing, and more particularly to the field of security for computing systems and microprocessors.
コンピュータシステム内におけるアプリケーションおよびそのデータの間の実行および整合性を確保することは、益々重要になってきている。先行技術におけるセキュリティ技術では、セキュアなアプリケーションおよびデータを柔軟に且つ信頼性高く適切に提供することができない。 Ensuring execution and consistency between applications and their data within computer systems is becoming increasingly important. Security technology in the prior art cannot provide secure applications and data flexibly, reliably and appropriately.
本発明の実施形態は、添付図面において限定ではなく例示として示されており、図面において同様の参照番号を付された部材同士は同様の部材である。 The embodiment of the present invention is shown as an example without limitation in the accompanying drawings, and the members having the same reference numbers in the drawings are similar members.
本発明の実施形態は、セキュアなアプリケーションおよびデータを柔軟に且つ信頼性高く提供する技術に係る。本発明には複数の態様の複数の実施形態があるが、「セキュアなエンクレーブアーキテクチャ」なる添付書類を、少なくとも1つの実施形態としてここに参照として組み込む。しかし、組み込まれた文献は、本発明の実施形態の範囲を制限するものではなく、本発明の精神および範囲内で他の実施形態も利用可能である。ここで、実施形態に係る発明の一例を記載する。
[項目1]
保護データにアクセスする、プログラムの実行中に、保護データを、エンクレーブページキャッシュ(EPC)とシステムメモリとの間で移動させる第1の命令を少なくとも実行する実行論理と、
トランスレーション・ルックアサイド・バッファ(TLB)と、
を備え、
TLBは、TLB中の少なくとも1つのエントリがエンクレーブ用であることを示す少なくとも1つのビットを含む、
プロセッサ。
[項目2]
プログラムがハードディスクドライブまたは保護メモリに格納されているときに、セキュリティマップ(SMAP)がプログラムの整合性の確保を助けるために使用される、
項目1に記載のプロセッサ。
[項目3]
実行論理は、セキュアなエンクレーブで実行されているソフトウェアスレッドを識別する、ユーザのプログラムにソフトウェアスレッドの実体を知らせる第2の命令を少なくとも実行する、
項目1又は2に記載のプロセッサ。
[項目4]
実行論理は、セキュアなエンクレーブに格納されているデータの整合性を判断するべく、セキュアなマップ(SMAP)フィールドとセキュリティ情報(SEC_INFO)フィールドとを含む少なくとも1つの情報フィールドに動的にアクセスする第2の命令を少なくとも実行する、
項目1から3のいずれか1項に記載のプロセッサ。
[項目5]
実行論理は、メモリに格納されているセキュアなエンクレーブの状態を、ローカルエージェントまたは遠隔エージェントのいずれかに報告する第2の命令を少なくとも実行する、
項目1から4のいずれか1項に記載のプロセッサ。
[項目6]
ソフトウェアプログラムの実行中に、ソフトウェアプログラムを攻撃から保護するクリプト・メモリ・アパーチャ(CMA)と、
ソフトウェアプログラムが実行していない間にソフトウェアプログラムを保護するセキュアなマップ(SMAP)と
を更に備える項目1から5のいずれか1項に記載のプロセッサ。
[項目7]
実行論理は、セキュアなエンクレーブ内の対応するメモリまたはソフトウェアスレッドの割り当てまたは割り当て解除をする少なくとも1つのセキュアなエンクレーブアクセス命令を実行する、
項目1から6のいずれか1項に記載のプロセッサ。
[項目8]
単一のプロセッササイクルにおいてセキュアなエンクレーブ内で複数のメモリ更新を行わせる階層保護ツリー、SMAPを更に備える、
項目1から7のいずれか1項に記載のプロセッサ。
[項目9]
実行論理は、セキュアなエンクレーブに固有キーを提供する第2の命令を少なくとも実行する、
項目1から8のいずれか1項に記載のプロセッサ。
[項目10]
実行論理は、アントラステッド・エージェントが管理するトラステッド環境を構築する第2の命令を少なくとも実行する、
項目1から9のいずれか1項に記載のプロセッサ。
[項目11]
実行論理は、セキュアなエンクレーブにアクセスするためのライセンスの有効性を、エンクレーブのサイズをライセンス証明書が規定するサイズと比較して判断する第2の命令を少なくとも実行する、
項目1から10のいずれか1項に記載のプロセッサ。
[項目12]
実行論理は、セキュアなエンクレーブのユーザレベルのポリシー管理を行い、制御ビットにより制御される、
項目1から11のいずれか1項に記載のプロセッサ。
[項目13]
実行論理は、ユーザに対してライセンス許諾されるセキュアなエンクレーブの少なくとも1つのインスタンスに対するアクセスを許可する第2の命令を少なくとも実行する、
項目1から12のいずれか1項に記載のプロセッサ。
[項目14]
実行論理は、セキュアなエンクレーブのデバッグを行わせる、デバッグを許可されたエンクレーブのみのエンクレーブセキュリティを侵害する第2の命令を少なくとも実行する、
項目1から13のいずれか1項に記載のプロセッサ。
[項目15]
それぞれエンクレーブページキャッシュ(EPC)に対してメモリページの割り当てまたは割り当て解除を行う少なくとも1つの命令を実行する実行論理と、
トランスレーション・ルックアサイド・バッファ(TLB)と、
を備え、
TLBは、TLB中の少なくとも1つのエントリがエンクレーブ用であることを示す少なくとも1つのビットを含む、
プロセッサ。
Embodiments of the present invention relate to techniques for providing secure applications and data flexibly and reliably. Although there are a plurality of embodiments of the present invention in a plurality of embodiments, an attachment called "Secure Enclave Architecture" is incorporated herein by reference as at least one embodiment. However, the incorporated literature does not limit the scope of embodiments of the invention, and other embodiments are available within the spirit and scope of the invention. Here, an example of the invention according to the embodiment will be described.
[Item 1]
Execution logic that executes at least the first instruction to move the protected data between the enclave page cache (EPC) and the system memory during the execution of the program to access the protected data.
Translation Lookaside Buffer (TLB) and
With
The TLB contains at least one bit indicating that at least one entry in the TLB is for an enclave.
Processor.
[Item 2]
Security maps (SMAPs) are used to help ensure program integrity when the program is stored on a hard disk drive or protected memory.
The processor according to
[Item 3]
Execution logic at least executes a second instruction that identifies the software thread running in the secure enclave and informs the user's program of the nature of the software thread.
The processor according to
[Item 4]
Execution logic dynamically accesses at least one information field, including a secure map (SMAP) field and a security information (SEC_INFO) field, in order to determine the integrity of the data stored in the secure enclave. Execute at least 2 instructions,
The processor according to any one of
[Item 5]
The execution logic at least executes a second instruction that reports the state of the secure enclave stored in memory to either the local agent or the remote agent.
The processor according to any one of
[Item 6]
A crypto memory aperture (CMA) that protects a software program from attacks while it is running,
The processor according to any one of
[Item 7]
Execution logic executes at least one secure enclave access instruction that allocates or deallocates the corresponding memory or software thread in the secure enclave.
The processor according to any one of
[Item 8]
Further equipped with SMAP, a hierarchical protection tree that allows multiple memory updates within a secure enclave in a single processor cycle.
The processor according to any one of
[Item 9]
Execution logic at least executes a second instruction that provides a unique key for a secure enclave.
The processor according to any one of
[Item 10]
Execution logic at least executes a second instruction that builds a trusted environment managed by an untrusted agent.
The processor according to any one of
[Item 11]
Execution logic at least executes a second instruction that determines the validity of the license to access the secure enclave by comparing the size of the enclave to the size specified by the license certificate.
The processor according to any one of
[Item 12]
Execution logic manages secure enclave user-level policies and is controlled by control bits.
The processor according to any one of
[Item 13]
The execution logic executes at least a second instruction granting the user access to at least one instance of the licensed secure enclave.
The processor according to any one of
[Item 14]
The execution logic causes secure debugging of the enclave, at least executes a second instruction that violates the enclave security of only the enclaves that are allowed to be debugged.
The processor according to any one of
[Item 15]
Execution logic that executes at least one instruction that allocates or deallocates memory pages to the Enclave Page Cache (EPC), respectively.
Translation Lookaside Buffer (TLB) and
With
The TLB contains at least one bit indicating that at least one entry in the TLB is for an enclave.
Processor.
図1は、本発明の少なくとも1つの実施形態を利用することができるマイクロプロセッサのブロック図である。特に図1は、それぞれがローカルキャッシュ107と113とに関連付けられた1以上のプロセッサコア105および110を有するマイクロプロセッサ100を示す。さらに図1には、ローカルキャッシュ107および113のそれぞれに格納されている情報の少なくとも一部のバージョンを格納する共有キャッシュメモリ115が示されている。一部の実施形態では、マイクロプロセッサ110はまた、図1に示されていない他の論理(例えば、集積メモリコントローラ、集積グラフィックコントローラ、および、コンピュータシステム内の、例えばI/O制御等の他の機能を実行する論理)を含むこともできる。一実施形態では、マルチプロセッサシステム内の各マイクロプロセッサまたはマルチコアプロセッサ内の各プロセッサコアは、少なくとも1つの実施形態では、セキュアなエンクレーブ技術を実行するための論理119を含む、または論理119と関連付けられている。論理には回路、ソフトウェア(有形媒体に具現化されている)、またはこれら両方を含むことで、一部の先行技術の実装例よりも効率的に複数のコアまたはプロセッサ間のリソース割り当てを行うことができる。
FIG. 1 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. In particular, FIG. 1 shows a
例えば図2は、本発明の一実施形態を利用することができるフロントサイドバス(FSB)コンピュータシステムを示す。プロセッサ201、205,210、または215いずれもが、プロセッサコア223、227、233、237、243、247、253、257を含む、またはこれらと関連付けられているローカルレベル1(L1)キャッシュメモリ220、225、230、235、240、245、250、255のうちいずれかの情報にアクセスすることができる。さらには、プロセッサ201、205、210、または215いずれもが、チップセット265を介して、システムメモリ260から、または、共有レベル2(L2)キャッシュ203、207、213、217のいずれかからの情報にアクセスすることができる。図2に示すプロセッサのうち1以上は、少なくとも一実施形態におけるセキュアなエンクレーブ技術を実行する論理219を含む、または論理219と関連付けられてよい。
For example, FIG. 2 shows a front side bus (FSB) computer system that can utilize one embodiment of the present invention. A local level 1 (L1)
図2に示すFSBコンピュータシステムに加えて、ポイントツーポイント(P2P)インターコネクトシステムおよびリングインターコネクトシステム等の他のシステム構成を、本発明の様々な実施形態と協働して利用することもできる。例えば図3のP2Pシステムは、幾つかプロセッサを含むことができ、このうち2つのプロセッサ370、380が例示されている。プロセッサ370、380はそれぞれ、メモリ32、34と接続するためにローカルメモリコントローラハブ(MCH)372、382を含んでよい。プロセッサ370、380は、PtPインタフェース回路378、388を利用してポイントツーポイント(PtP)インタフェース350を介してデータを交換することができる。プロセッサ370、380はそれぞれ、ポイントツーポイントインタフェース回路376、394、386、398を利用して個々のPtPインタフェース352、354を介してチップセット390とデータを交換することができる。チップセット390はさらに、高性能グラフィックインタフェース339を介して高性能グラフィック回路338とデータを交換することができる。本発明の実施形態は、任意の数のプロセッサコアを有する任意のプロセッサ内に配置されてもよいし、または、図3のPtPバスエージェントそれぞれの内部に配置されてもよい。一実施形態では、任意のプロセッサコアが、ローカルキャッシュメモリ(不図示)を含む、またはこれと関連付けられていてよい。さらに、共有キャッシュ(不図示)が、両プロセッサ外のプロセッサに含まれていながらも、p2pインターコネクトを介して両プロセッサに接続されており、プロセッサを低電力モードにする場合、これらプロセッサの両方または片方のローカルキャッシュ情報を共有キャッシュに格納できる、という構成も可能である。図3に示す1以上のプロセッサまたはコアは、少なくとも1つの実施形態においては、セキュアなエンクレーブ技術を実行する論理319を含む、または論理319と関連付けられていてよい。
In addition to the FSB computer system shown in FIG. 2, other system configurations such as point-to-point (P2P) interconnect systems and ring interconnect systems can also be used in collaboration with various embodiments of the present invention. For example, the P2P system of FIG. 3 can include several processors, of which two
少なくとも1つの実施形態の1以上の態様は、プロセッサ内の様々な論理を表す機械可読媒体に格納される代表的なデータにより実装することができ、データが機械により読み出されることで、機械は、ここに記載する技術を実行する論理を製造する。「IPコア」として知られているような表現は、有形の機械可読媒体(「テープ」)に格納されて、論理またはプロセッサを実際に製造する製造機械に装填するために様々な顧客または製造用設備に供給されてよい。 One or more aspects of at least one embodiment can be implemented by representative data stored on a machine-readable medium representing various logics in the processor, and the machine can read the data. Manufacture the logic that implements the techniques described herein. Representations such as those known as "IP cores" are stored on tangible machine-readable media ("tapes") and are used by a variety of customers or manufacturers to load logic or processors into the actual manufacturing machine. It may be supplied to the equipment.
従って、マイクロアーキテクチャメモリ領域アクセスを方向付ける方法および装置が記載された。上述した記載は、例示を意図しており限定は意図していない。数多くの他の実施形態も、上述した記載を読み理解した当業者には明らかであろう。従って本発明の範囲は、添付請求項および請求項が含みうる均等物の全範囲を参照して決定される。 Therefore, methods and devices for directing microarchitecture memory area access have been described. The above description is intended as an example and not a limitation. Many other embodiments will also be apparent to those skilled in the art who have read and understood the above description. The scope of the present invention is therefore determined with reference to the appended claims and the full range of equivalents that the claims may include.
セキュアなエンクレーブは、アプリケーションにOSプロセスのコンテキスト内でコードを実行してデータを格納させるための安全な場所を提供する命令セットである。この環境下で実行されるアプリケーションはエンクレーブと称される。エンクレーブは、エンクレーブページキャッシュ(EPC)から実行される。エンクレーブページは、OSによりEPCに装填される。エンクレーブのページがEPCから取り出されるたびに、暗号保護を利用して、エンクレーブの機密性を保護して、エンクレーブをEPCに戻すときの改ざんを検知することができる。EPC内で、エンクレーブデータは、プロセッサが提供するアクセス制御メカニズムを利用して保護される。以下の表2−1は、特権のないエンクレーブ命令の完全リストを提供している。
これらの命令はリング3でのみ実行される。全ての他の時点においては、これらは#UD不良を生成する。表2−2は、特権を有する命令のリストを提供する。
エンクレーブページキャッシュ(EPC)は、エンクレーブコードを実行して、保護されたエンクレーブデータにアクセスする場所である。EPCは、プラットフォームの物理アドレス空間内に配置されるが、アクセスはSE命令を利用してのみ可能となる。EPCは、多くの異なるエンクレーブからのページを含んでよく、ページの整合性および機密性を保護するアクセス制御メカニズムを提供する。ページキャッシュは、プラットフォームのコヒーレントな物理メモリに利用されるものに類似したコヒーレンスプロトコルを維持している。 The Enclave Page Cache (EPC) is where you can execute enclave code to access protected enclave data. The EPC is located within the physical address space of the platform, but access is only possible using the SE instruction. The EPC may include pages from many different enclaves and provides an access control mechanism that protects the integrity and confidentiality of the pages. The page cache maintains a coherence protocol similar to that used for the platform's coherent physical memory.
EPCは幾つかの方法でインスタンス化することができる。例えば、プロセッサパッケージ上の専用SRAMから構築することができる。クリプト・メモリ・アパーチャ(Crypto Memory Aperture)が好適な実装メカニズムとして知られている。このメカニズムにより、EPCを大きくすることができる。CMAについては以下で詳述する。 EPC can be instantiated in several ways. For example, it can be constructed from a dedicated SRAM on the processor package. Crypto Memory Aperture is known as a preferred implementation mechanism. By this mechanism, the EPC can be increased. The CMA will be described in detail below.
エンクレーブページキャッシュマップ(EPCM)は、EPC内の各ページに関連付けられた状態情報を含む。この状態は、ページが属すエンクレーブ、装填されるページの状態等の情報を提供する。EPCからページが取り出されると、状態情報もエクスポートされて、暗号手段を利用して保護される。エンクレーブページをEPCに再装填するときには、状態情報を検証する。 The Enclave Page Cache Map (EPCM) contains state information associated with each page in the EPC. This state provides information such as the enclave to which the page belongs, the state of the loaded page, and so on. When the page is retrieved from the EPC, the state information is also exported and protected using cryptographic means. When reloading the enclave page into the EPC, verify the state information.
図4は、本発明の少なくとも1つの実施形態を利用することができるマルチコアマイクロプロセッサ499のブロック図である。マイクロプロセッサ499は、複数のコア400、420を含むことができる。コア400は、CR3 402、SMBR404、ページミスハンドラ408、PMHE410、および変換ルックアサイドバッファ412を含むことができる。コア420は、CR3 422、SMBR424、ページミスハンドラ428、PMHE430、および変換ルックアサイドバッファ432を含むことができる。本発明の一部の実施形態では、マイクロプロセッサ499は、コア400とコア420との間で共有されるレベル1キャッシュ440を含む。レベル1キャッシュ440は、最終レベルのキャッシュ445との間でデータをやりとりすることができる。ホームエージェント450は、最終レベルのキャッシュ445に接続して、暗号エンジン452に接続(attach to)することができる。ホームエージェント450は、クリプト・メモリ・アパーチャ480の物理アドレス空間488を、メモリコントローラ454を介して評価(assess)することができる。クリプト・メモリ・アパーチャ480は、エンクレーブページキャッシュ482、エンクレーブページキャッシュマップ484、補助格納部486、物理アドレス空間の一部488を含む。
FIG. 4 is a block diagram of a
CMAは、EPC、EPCM、その他SE関連の構造をインスタンス化する助けを行うメカニズムである。アパーチャとは、この目的の利用に備えさせられる物理アドレス空間の一領域のことである。 CMA is a mechanism that helps instantiate EPC, EPCM, and other SE-related structures. An aperture is an area of physical address space that is prepared for this purpose.
EPCおよびEPCM(およびその他の実装データ構造)は、アパーチャ内のある位置にマッピングされる。補助格納部は、これらリソースのための実際のデータのことである。EPCのメモリ要求が生成されると、CMAは、暗号化されたEPCデータが含まれている補助格納部の位置に再マッピングを行い、そのデータを取得する。 EPCs and EPCMs (and other implementation data structures) are mapped to certain locations within the aperture. Auxiliary storage is the actual data for these resources. When the EPC memory request is generated, the CMA remaps to the location of the auxiliary storage that contains the encrypted EPC data and acquires that data.
一般的には、殆どのSEは、マイクロコードに実装される。CMA、パッケージ外およびコア内のデータ移動制御する論理を含む複数の位置にハードウェアによるサポートが必要である。 In general, most SEs are implemented in microcode. Hardware support is required at multiple locations, including CMA, out-of-package and in-core data movement control logic.
図5は、本発明の一実施形態のセキュアなエンクレーブ(SE)の可能性のある実装例である。オペレーティングシステムおよびVMM542は、ELPG命令540を利用して、エンクレーブ532のエンクレーブページを、エンクレーブページキャッシュ544に装填することができる。マイクロプロセッサがエンクレーブ532内で実行していないときには、エンクレーブページキャッシュ544はSERRレジスタ532によるソフトウェアアクセスから保護される。エンクレーブ内で実行する場合には、マイクロコードページテーブルが保護548を提供する。各VMにはVMCSが関連付けられている。VM510はVMCS515に接続されている。VM520はVMCS525に接続されている。VM530はVMCS535に接続されている。SMM500は、別個のコンテナにあってよく、プロセッサ状態は別個のコンテナにあってよい。
FIG. 5 is a possible implementation example of a secure enclave (SE) according to an embodiment of the present invention. The operating system and the
図5は、セキュアなエンクレーブ実装の一実施形態の高レベル概略図である。この実装例では、EPCは、マイクロコードが管理する別個のコンテナに維持されている。コンテナは、エンクレーブ内で実行されていない場合にはアクセス不可能である。エンクレーブに入った場合には、制御は、別個のコンテナに含まれているEPC内のエンクレーブコードに移される。 FIG. 5 is a high-level schematic of an embodiment of a secure enclave implementation. In this implementation, the EPC is maintained in a separate container managed by microcode. The container is inaccessible if it is not running inside the enclave. Upon entering the enclave, control is transferred to the enclave code within the EPC contained in a separate container.
エンクレーブ内で実行されている間に起こったページ不良または例外は全て、マイクロコードにより関連OSまたはVMMに反映される。機械がエンクレーブ内で実行していない場合には、EPCへのアクセス制御はSEレンジレジスタ(SERR)により提供される。機械が内部で実行されている場合には、マイクロコードはページテーブルレベルの保護を提供して、実行されているエンクレーブに属さない他のEPCエントリへのアクセスを禁止する。 Any page defects or exceptions that occur while running in the enclave are reflected in the associated OS or VMM by microcode. Access control to the EPC is provided by the SE Range Register (SERR) when the machine is not running in the enclave. When the machine is running internally, the microcode provides page table level protection to prevent access to other EPC entries that do not belong to the running enclave.
セキュアなエンクレーブを実装する一方法に、一部のプロセッサ内のマイクロコード機能を利用して命令および保護を行う、というものがある。この機能は、エンクレーブの目的達成をセキュアに行うというセキュリティ要件に適合しているだろう。 One way to implement secure enclave is to use microcode functionality within some processors to provide instructions and protection. This feature would meet the security requirements of securely achieving the goals of Enclave.
図2−2に示すSERRレジスタは、ページミスハンドラPMHに実装される。レジスタは、各論理プロセッサについて独立してイネーブルおよびディセーブルされてよい。 The SERR register shown in FIG. 2-2 is implemented in the page miss handler PMH. Registers may be enabled and disabled independently for each logical processor.
性能を向上させる実装におけるオプションとして、変換ルックアサイドバッファ(TLB)のエントリがエンクレーブまたは特定のエンクレーブ用であることを示すために、1ビットまたは幾つかのビットを提供する、というものがある。これらのビットが提供されていない場合には、エンクレーブを退出するときに、他のコードがこのエンクレーブにアクセスしないようにするためにTLBフラッシュが必要となる。 An option in performance-enhancing implementations is to provide one or several bits to indicate that the translation lookaside buffer (TLB) entry is for an enclave or a particular enclave. If these bits are not provided, a TLB flush is required to prevent other code from accessing the enclave when exiting the enclave.
エンクレーブビットをエンクレーブモードビットと比較する。余剰ビットは、エンクレーブ空間idの機能を提供する。特定のエンクレーブはidを割り当てられてよい。idは、アドレスチェックの一環として、実行中のエンクレーブのidと比較される。TLBサポートは、性能向上策の1つのオプションである。EPCデータの除去によってあるエントリがTLBで無効化された場合、特定のマイクロコード化された撃墜メカニズム(special microcoded shootdown mechanism)が必要となる。一実施形態では、マイクロコードがエンクレーブ信頼境界(enclave trust boundary)内の全ての他のコアと接触をとり、このエントリがどのTLB内にもないことを確かめる。他の実施形態では、他のプロセッサがTLBエントリを無効化したことを確かめる手段をマイクロコードに提供するようにしてもよい。 Compare the enclave bit with the enclave mode bit. The surplus bits provide the function of the enclave space id. Certain enclaves may be assigned an id. The id is compared to the id of the running enclave as part of the address check. TLB support is an option for performance improvement. If an entry is invalidated in the TLB by the removal of EPC data, a special microcoded shootdown mechanism is required. In one embodiment, the microcode contacts all other cores within the enclave trust boundary to ensure that this entry is not in any TLB. In other embodiments, the microcode may be provided with a means of ensuring that another processor has invalidated the TLB entry.
DMAスヌープを回避してEPCに対して無効化するためには、特別なSADおよび/またはTADエントリが提供される。これら専用のレジスタがEPCを保護する。これは、SERRと同じ値に設定される。 Special SAD and / or TAD entries are provided to avoid the DMA snoop and disable it for the EPC. These dedicated registers protect the EPC. This is set to the same value as SERR.
一実施形態では、各エンクレーブのセキュアなエンクレーブに対してセキュアな鍵を保証するために、マイクロコードは乱数へのセキュアなアクセスを利用することができる。 In one embodiment, the microcode can utilize secure access to random numbers to guarantee a secure key for each enclave's secure enclave.
エンクレーブは改ざんされないように保護されてよい。改ざん保護に利用されるメカニズムの詳細は、実装例に応じて変わる。これにより、エンクレーブが改ざんされると、改ざんを検知したスレッド上でのさらなる実行が防止される。ユーザにエンクレーブの状態を理解させるために、構築されているエンクレーブを証明するための立証メカニズムを設ける。これには、エンクレーブコンテンツの情報を提示するEREPORT命令が含まれる。 The enclave may be protected from tampering. The details of the mechanism used for tamper protection will vary depending on the implementation example. This prevents further execution on the thread that detected the tampering when the enclave is tampered with. In order to make the user understand the state of the enclave, a proof mechanism for proving the built enclave is provided. This includes an EREPORT instruction that presents information about the enclave content.
エンクレーブ設計で必要となるマイクロコード符号を簡略化するために、アーキテクチャエンクレーブというコンセプトが開発された。この種類のエンクレーブには、エンクレーブのためのコードの原本に基づいて特別なアクセス特権が与えられる。 The concept of architecture enclave was developed to simplify the microcode code required for enclave design. This type of enclave is given special access privileges based on the original code for the enclave.
電力サイクルにおけるエンクレーブ状態は、ソフトウェアポリシーに依存している。CMA内のデータは、電力停止時に失われる。エンクレーブを保存することが望ましい場合には、ソフトウェアによって電力サイクルにおいてエンクレーブデータが失われないように保証することができる。EPCに常駐するデータは、ソフトウェアがエンクレーブをS3電力状態中に生かしておきたい場合には、メモリにフラッシュすることができる。ソフトウェアは、電力喪失時にアプリケーションに全てのエンクレーブの除去を義務付ける選択を行うこともできる。 The enclave state in the power cycle depends on the software policy. The data in the CMA is lost during a power outage. If it is desirable to store the enclave, the software can ensure that the enclave data is not lost during the power cycle. The data resident in the EPC can be flushed to memory if the software wants to keep the enclave alive during the S3 power state. The software can also choose to require the application to remove all enclaves in the event of a power loss.
エンクレーブはその位置に応じて保護される。CPUパッケージ外のデータは、暗号化および整合性チェックを利用して保護される。エンクレーブページキャッシュ内のコードおよびデータについては、ページがアクセス制御メカニズムを利用して保護される。 The enclave is protected according to its location. Data outside the CPU package is protected using encryption and integrity checks. For code and data in the enclave page cache, the page is protected using access control mechanisms.
図6は、本発明の少なくとも1つの実施形態を利用することができるマイクロプロセッサのブロック図である。図6は、複数のプロセッサコア600、605、610、615、およびキャッシュ620を有するマイクロプロセッサ600を示す。エンクレーブデータ635は暗号化することができる。クリプト・メモリ・アパーチャデータ630は、エンクレーブデータ635の保護に利用される。
FIG. 6 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. FIG. 6 shows a
システムメモリに常駐しているエンクレーブページは、暗号化および整合性を利用して保護される。ページのEPCへの装填においては、ページはEPCにコピーされ、復号化されて、そのページの整合性をチェックする。図6は、データのこの部分を示している。 Enclave pages that reside in system memory are protected using encryption and integrity. When loading a page into the EPC, the page is copied to the EPC, decrypted, and checked for the integrity of the page. FIG. 6 shows this part of the data.
EPC内に常駐しているエンクレーブページは、システムメモリに格納されてから、エンクレーブキーを利用して暗号化される。認証情報もページ格納時に格納される。EPC内のエンクレーブデータは、復号(unencrypt)されてアクセス制御メカニズムにより保護される。プロセッサは、データの所有権を持つエンクレーブしかアクセスできないように、このデータを保護する。 The enclave page resident in the EPC is stored in the system memory and then encrypted by using the enclave key. Authentication information is also stored when the page is stored. The enclave data in the EPC is unencrypted and protected by an access control mechanism. The processor protects this data so that only the enclave that owns the data can access it.
EPCに常駐しているエンクレーブページが、キャッシュから、CPUパッケージ外のメインメモリに強制的に移動させられると、CMA暗号化により保護される。CMAは、このデータを暗号化してデータの機密性を実現する。EPCの整合性は、EPCに対する読み書きを防止するレンジレジスタにより提供される。 When the enclave page resident in the EPC is forcibly moved from the cache to the main memory outside the CPU package, it is protected by CMA encryption. The CMA encrypts this data to ensure the confidentiality of the data. EPC integrity is provided by range registers that prevent reading and writing to the EPC.
図7は、本発明の一実施形態に実装可能なエンクレーブページキャッシュの一部分にアクセスする制御構造の一例を示す。エンクレーブページキャッシュ720の各ページは、エンクレーブページキャッシュマップ710内に対応するメタデータを有していてよい。図7に示すメタデータにおいて、リニアアドレス700のセットを含むセキュアなエンクレーブが、リニアアドレスがエンクレーブページキャッシュマップ710に格納されているリニアアドレスに合致する場合、エンクレーブページキャッシュ720に格納されているデータにアクセスすることができる。
FIG. 7 shows an example of a control structure that accesses a part of the enclave page cache that can be implemented in one embodiment of the present invention. Each page of the
図7は、EPCおよびEPCMの配置および利用法を示す。EPCは4kページに分割される。各エンクレーブは、EPCに常駐している幾つかの数のページを有してよい。EPCの各ページのEPCMのエントリには、セキュリティを確保するために必要なメタ情報を提供するものもある。EPCMの詳細は実施例に固有である。 FIG. 7 shows the arrangement and usage of EPC and EPCM. The EPC is divided into 4k pages. Each enclave may have several pages resident in the EPC. Some EPCM entries on each page of the EPC provide the meta information needed to ensure security. The details of the EPCM are specific to the examples.
アプリケーションがエンクレーブの装填を所望する場合には、OSのシステムルーチンを呼び出す。OSはEPC内に数ページを割り当てようとする。空いている場所がない場合には、OSはビクティム・エンクレーブを選択して除去する。OSは、ビクティム・エンクレーブのページを、各ページについてEWBINVPG命令を利用して強制的に除去(evict)する。OSが強制除去を完了すると、ECREATEコマンドを利用してエンクレーブにセキュアなエンクレーブ制御構造(SECS)を追加する。SECSを生成した後で、OSは、EADDPRE命令の利用によりアプリケーションにより要求されたようにページをエンクレーブに追加する。 If the application wants to load the enclave, it calls the OS system routines. The OS tries to allocate several pages in the EPC. If there is no vacant space, the OS will select and remove the Victim Enclave. The OS evicts the pages of the Victim Enclave using the EWBINVPG instruction for each page. When the OS completes the forced removal, it uses the ECREATE command to add a secure enclave control structure (SECS) to the enclave. After generating the SECS, the OS adds the page to the enclave as required by the application by using the EADDPRE instruction.
データページをエンクレーブに追加するには、OSは先ず、EADDSMAP命令を利用してSMAPページをエンクレーブに追加する。エンクレーブのサイズおよび配置に応じて、OSは複数のSMAPページを割り当てる場合がある。エンクレーブページ全てがエンクレーブに追加されると、OSはEINIT命令を実行して、エンクレーブを実行する。EINIT命令に対するパラメータは、エンクレーブがその機械上での実行を許可されていることを示す認可状である。アプリケーションの装填時には許可状を生成する必要がある。EINITが無事に完了すると、アプリケーションはEENTER命令を実行してエンクレーブに入ることができる。 To add a data page to the enclave, the OS first adds the SMAP page to the enclave using the EADDSMAP instruction. The OS may allocate multiple SMAP pages, depending on the size and placement of the enclave. When all the enclave pages are added to the enclave, the OS executes the EIINT instruction to execute the enclave. The parameter to the EINIT instruction is a permit indicating that the enclave is authorized to run on its machine. A permit must be generated when the application is loaded. Upon successful completion of EINIT, the application can execute the EENTER instruction to enter the enclave.
エンクレーブが構築され、実行準備が整った旨の表示がなされると、アプリケーションは、エンクレーブに物理的メモリを追加したり取り除いたりする必要がある場合がある。エンクレーブにはこれを助けるために、さらなるメモリを追加させる命令が存在する。メモリをエンクレーブに追加する際、メモリはエンクレーブ内の正確なリニアアドレスに割り当てられる。OSはこのメモリページを、リニアアドレスを示すEPCにコピーする。EADDPOST命令を実行して、このメモリをエンクレーブ(enclave enclave)に追加する。SMAPノードがEPC内に常駐していない場合には、先ずこれを装填する。 Once the enclave has been built and indicated that it is ready to run, the application may need to add or remove physical memory from the enclave. Enclave has instructions to add more memory to help with this. When adding memory to the enclave, the memory is assigned to the exact linear address in the enclave. The OS copies this memory page to the EPC indicating the linear address. Execute the EADDPOST instruction to add this memory to the enclave enclave. If the SMAP node is not resident in the EPC, load it first.
メモリをエンクレーブにコピーした後は、ソフトウェアは、ページを受諾してから、内部的にアクセスできるようになっていてよい。エンクレーブは、EACCEPT命令を実行することによりデータを受諾する。この命令は、エンクレーブ内のソフトウェアによってのみ実行可能である。 After copying the memory to the enclave, the software may accept the page and then be able to access it internally. The enclave accepts the data by executing the EACCEPT instruction. This instruction can only be executed by the software in the enclave.
一部の場合には、ソフトウェアは、エンクレーブメモリの特性の修正を望む場合がる。そのためには、SMAPを更新する必要がある。例えばソフトウェアが、別のスレッドエントリポイントであるTCSをエンクレーブ内に生成しようとする場合を考える。この場合、エンクレーブは、EMODIFY命令を利用してページのSMAP特性を変更するようOSに要求する。特性が変更された後で、エンクレーブソフトウェアは、EACCEPT命令を実行して、ページの利用を許可する。 In some cases, the software may want to modify the characteristics of the enclave memory. For that, it is necessary to update SMAP. For example, consider the case where software attempts to generate another thread entry point, the TCS, in an enclave. In this case, the enclave requires the OS to use the EMODIFY instruction to change the SMAP characteristics of the page. After the properties have changed, the enclave software executes the EACCEPT instruction to allow the page to be used.
メモリページはエンクレーブから除去することもできる。エンクレーブがページの除去の準備ができている場合には、OSに要求を送る。OSは、EREMOVE命令を実行して、SMAPからページを除去させる。EREMOVE命令はさらに、EPCエントリの無効化も行う。 Memory pages can also be removed from the enclave. If the enclave is ready to remove the page, it sends a request to the OS. The OS executes the EREMOVE instruction to remove the page from SMAP. The EREMOVE instruction also invalidates the EPC entry.
エンクレーブ環境の整合性を確保する方法としては、アクセスチェックを数回行う、というものがある。実施される様々なセキュリティ特性のなかには、データをEPCに正確に位置させて、データがエンクレーブの間でリークしないようにして、参照アドレスが破損しないようにすることで、コードがエンクレーブの異なるリニアアドレスに移動させられないようにする、というものがある。 One way to ensure the integrity of the enclave environment is to perform access checks several times. Among the various security characteristics implemented, the code is a linear address with different enclaves by accurately positioning the data in the EPC so that the data does not leak between enclaves and the reference address is not corrupted. There is something to prevent it from being moved to.
アクセス保護要件は、レンジャレジスタおよびマイクロコード管理されたシャドーページテーブルを利用して実装することができる。別の実施形態では、シャドーページテーブルのオーバヘッドを回避するために、ページミスハンドラハードウェアを修正して、同じアクセス制御要件を実行することができる。 Access protection requirements can be implemented using ranger registers and microcode-managed shadow page tables. In another embodiment, the page miss handler hardware can be modified to implement the same access control requirements to avoid shadow page table overhead.
EPCは、LPがマイクロコードモードで実行中、または、LPがエンクレーブ内で実行中であり、アクセスされているリニアアドレスがそのエンクレーブがカバーするリニアアドレスレンジに属している場合にのみ、論理プロセッサ(LP)によりアクセス可能である。言い換えると、EPCレンジに行くことが許されるのはマイクロコードアクセスまたはエンクレーブアクセスのみである。EPCレンジに対する他のアクセスはすべて、不法とみなされる。 The EPC is a logical processor only if the LP is running in microcode mode, or if the LP is running in an enclave and the linear address being accessed belongs to the linear address range covered by that enclave. It is accessible by LP). In other words, only microcode access or enclave access is allowed to go to the EPC range. All other access to the EPC range is considered illegal.
エンクレーブアクセスは、EPCに属す物理アドレスに対して解決(resolve)されてよい。アクセスがEPC外であるが、リニアアドレスが、アドレスがエンクレーブ内にあると示している場合には、アクセスは停止されてよい。OSに対する不良または命令は、報告を行う。 Enclave access may be resolved for a physical address that belongs to the EPC. Access may be suspended if the access is outside the EPC, but the linear address indicates that the address is inside the enclave. Any defects or instructions to the OS will be reported.
エンクレーブ内のアドレスに対するアクセスは、アクセスを成功させるためにEPC内に位置させることができる。エントリがEPCに存在するかのチェックは、通常、EPCMをチェックして、有効なビットを検証することにより行われる。各EPCページは特定のエンクレーブ専用である。そのEPCエントリに対する参照は、EPCページを所有するエンクレーブによってのみ可能である。これは、実行中のエンクレーブのSECSに、参照しているページが合致するかを検証することでチェックすることができる。 Access to the address in the enclave can be located in the EPC for successful access. Checking for the presence of an entry in the EPC is usually done by checking the EPCM and verifying the valid bits. Each EPC page is dedicated to a particular enclave. References to that EPC entry are only possible by the enclave that owns the EPC page. This can be checked by verifying that the referenced page matches the SECS of the running enclave.
各EPCページは、エンクレーブ用の特定のリニアアドレスページを表す。要求されているリニアアドレスは、EPC内のページのリニアアドレスに整合する場合がある。例えばEPCMエントリは、エンクレーブページがEPCに導入されるリニアアドレスを格納する。エンクレーブアクセスがEPCページに対して解決される場合には、ページを導入するリニアアドレスは、現在の要求のリニアアドレスと合致する。 Each EPC page represents a specific linear address page for the enclave. The requested linear address may match the linear address of the page in the EPC. For example, the EPCM entry stores the linear address where the enclave page is introduced into the EPC. If enclave access is resolved for an EPC page, the linear address that introduces the page matches the linear address of the current request.
エンクレーブのリニアアドレスマッピングは破損していてはいけない。リニアアドレスのページテーブルが破損している場合には、アクセスが不法なものとされる。これにより、攻撃者がコードおよびデータをエンクレーブの付近またはその中に運び入れることを防止する。 The enclave's linear address mapping must not be corrupted. If the linear address page table is corrupted, access is illegal. This prevents an attacker from bringing code and data into or near the enclave.
OS/VMMが初期化の後にエンクレーブにページを追加すると、EADDPOST命令が、そのページのEPCMに「係属中」ビットを設定する。係属中を示すビットは、後続するEPC書き戻しおよび強制除去(SEC_INFOを利用する)を経ても生存し続ける。エンクレーブは、EACCEPTを発行して、係属中のビットをクリアすることができる。エンクレーブアクセスが、係属中のビットが設定されたEPCページに対して解決された場合には、LPは、OS/VMMにEF_PENDING不良を発行する。 When the OS / VMM adds a page to the enclave after initialization, the EADDPOST instruction sets the "pending" bit on the ECM M of that page. The pending bit continues to survive the subsequent EPC writeback and forced removal (using SEC_INFO). The enclave can issue an EACCEPT to clear the pending bits. If the enclave access is resolved for an EPC page with a pending bit set, the LP issues an EF_PENDING defect to the OS / VMM.
OS/VMMが中継保護されたエンクレーブページをEPCに装填すると、FCR(フレッシュチェック要求された)ビットが、そのページのEPCMエントリに設定される。OS/VMMは、そのEPCページに対してEUPSMAP命令を実行してこのビットをクリアすることで、このビットをクリアすることができる。エンクレーブアクセスの継続は、このページのFCRビットが設定されていない場合に限って許可される。さもなくば、LPはEF_FRESH_CHK不良をOS/VMMに送信する。 When the OS / VMM loads an EPC with a relay-protected enclave page, the FCR (Fresh Check Requested) bit is set in the EPCM entry for that page. The OS / VMM can clear this bit by executing the EUPSMAP instruction for the EPC page and clearing this bit. Continued enclave access is only allowed if the FCR bit on this page is not set. Otherwise, the LP sends an EF_FRESH_CHK defect to the OS / VMM.
各EPCMエントリは、エンクレーブがそのページに対する書き込みを許可されているかを示す「ダーティ」なビットを含む。エンクレーブのエンクレーブページに対する書き込みは、EPCMのそのページのダーティビットが設定されているときに限って許可される。さもなくば、LPはEF_EWRITEをOS/VMMに発行する。OS/VMMは、そのページに対してEUPSMAP命令を実行することで、ダーティビットを設定することができる。 Each ECCM entry contains a "dirty" bit that indicates whether the enclave is allowed to write to that page. Writing to an enclave page of an enclave is only allowed if the dirty bit for that page in the EPC M is set. Otherwise, LP will issue EF_EWRITE to OS / VMM. The OS / VMM can set the dirty bit by executing the EUPSMAP instruction for the page.
論理プロセッサがエンクレーブ内で実行しているときはいつでも、そのエンクレーブのSECSページがEPC内に存在しうる。しかし、SEセキュリティモデルでは、エンクレーブは、自身のSECSに直接メモリアクセスを行うことは許可されていない(ただしエンクレーブは、完全にセキュリティを脅かすという前提で、自身のエンクレーブキーを読み出すことはできる)。エンクレーブアクセスが、そのエンクレーブに対してSECSを保持するEPCページに対して解決される場合には、OS/VMMは、EF_ATTRIB_SECS不良を介して通知を受ける。エンクレーブは、TSC属性セットを有するページの修正は許可されていない。エンクレーブがEPCに装填されたTCSの修正を試みると、OS/VMMは、EF_ATTRIB_TCS不良を介して通知を受ける。以下の表のサイズフィールドにおいては、4:32および64ビットモード両方の4バイトフィールド、8:32および64ビットモード両方の8バイトフィールド、および、8(4):両方のモードにおける8バイトフィールド(上位4バイトは32ビットモードでは無視される)という値および指標を利用することができる。 Whenever a logical processor is running in an enclave, the SECS page for that enclave can be in the EPC. However, the SE security model does not allow enclaves to have direct memory access to their SECS (although enclaves can read their enclave keys on the assumption that they are completely security threatening). If the enclave access is resolved for an EPC page that holds SECS for that enclave, the OS / VMM will be notified via EF_ATTRIB_SECS failure. Enclave is not allowed to modify pages that have a TSC attribute set. When the Enclave attempts to modify the TCS loaded in the EPC, the OS / VMM is notified via EF_ATTRIB_TCS failure. In the size fields in the table below, 4-byte fields in both 4:32 and 64-bit modes, 8-byte fields in both 8:32 and 64-bit modes, and 8 (4): 8-byte fields in both modes ( The upper 4 bytes are ignored in 32-bit mode) values and indicators are available.
注:一部のフィールドは、小文字の「o」から始まる名称を有する(例えばoLSP)。これらフィールドはポインタであるが、エンクレーブでは、エンクレーブのベースに対するオフセットとして表される。この表記法により、エンクレーブページの計測値を、エンクレーブを生成した位置から独立させることができる。 Note: Some fields have names that start with a lowercase "o" (eg oLSP). These fields are pointers, but in the enclave they are represented as offsets to the base of the enclave. This notation allows the measurement on the enclave page to be independent of the position where the enclave was created.
注:フィールドは(未だ)特に決まった順序で記載されていない。一部のフィールドは、銘々のデータ構造内の異なるメモリページに移動させられてよく、これにより例えば異なる保護手段が可能となる。
各スレッドには、スレッド制御構造(TCS)が関連付けられている。TCSは以下を含む。
<状態セーブ領域オフセット(oSSA)>
状態セーブ領域オフセット(oSSA)は、エンクレーブで実行中に生じる割り込みまたは例外にプロセッサ状態をセーブするのに利用される状態セーブフレームのスタックを指し示している。次の状態セーブ領域(NSSA)が割り込みマイクロコードにより利用されて、エンクレーブでの実行中に生じる割り込みまたは例外のどこにプロセッサ状態をセーブするかが判断される。これは、oSSAがアドレス指定するフレームアレイへのインデックスである。セーブ領域(CSSA)のカウントは、このTCSに利用可能なSSAフレームの数を特定する。割り込みまたは例外が生じ、且つ、これ以上利用可能なSSAフレームがない場合には(NSSA>=CSSA)、割り込みまたは例外がまだ起こりえて、プロセッサ状態がクリアされるが、TCSは無効(INVALID)であるとして表示される。
<State save area offset (oSSA)>
The state save area offset (oSSA) points to a stack of state save frames used to save processor state to interrupts or exceptions that occur during execution in the enclave. The next state save area (NSSA) is utilized by the interrupt microcode to determine where to save the processor state in interrupts or exceptions that occur during execution in the enclave. This is an index into the frame array addressed by oSSA. The save area (CSSA) count identifies the number of SSA frames available for this TCS. If an interrupt or exception occurs and no more SSA frames are available (NSSA> = CSSA), an interrupt or exception can still occur and the processor state is cleared, but TCS is disabled (INVALID). Displayed as being.
エンクレーブでの実行中に割り込みが起こった場合には、機械の状態がTCS::SSA(状態セーブ領域)にセーブされる。この領域には以下が含まれる。
TCS::SSAは、割り込みが生じたときにもページアウトされない。EENTERは、SSAがEPC内にあることをチェックして、物理アドレスをキャッシュする。ページが強制移動させられている場合には、EWBINVPGを実行中のプロセッサが、SSAを利用してスレッドを現在実行中のプロセッサでエンクレーブを退出させて、ページ不良を報告する。 TCS :: SSA is not paged out when an interrupt occurs. EENTER checks that the SSA is in the EPC and caches the physical address. If the page is forcibly moved, the processor running EWBINVPG uses the SSA to exit the enclave with the processor currently running the thread and report a page defect.
図8は、データ構造全ての縫合方法を示す。煩雑にならないように、全てのスレッドのそれぞれの構造は示していない。アントラステッドスタック(Untrusted Stacks)およびそれに関連するポインタも省かれている。図8は、本発明の一実施形態におけるスレッド制御構造の一例を示しており、セーブ状態領域同士の縫合を示す。状態セーブ領域ポインタ800は、セーブ領域0 820を指し示している。現在の状態セーブ領域805は、セーブ領域1 824を指し示している。次の状態セーブ領域810は、次のセーブ領域828を指し示している。セーブ状態領域の数は、利用可能なセーブ状態領域の数への参照を提供している。
FIG. 8 shows the suturing method for all data structures. To avoid complication, the structure of each thread is not shown. Untrusted Stacks and their associated pointers have also been omitted. FIG. 8 shows an example of a thread control structure according to an embodiment of the present invention, and shows suturing between save state regions. The state save
ページ情報(PAGE_INFO)は、EPC−管理命令へのパラメータとして利用されるアーキテクチャデータ構造である。
セキュリティ情報(SEC_INFO)データ構造は、偽造保護に必要な暗号メタデータを保持する。
証明書(CERT)とは、アーキテクチャエンクレーブを提供される証明書構造であり、EMKPERMITに渡される。この構造は4096バイトであり、ページを整列されてよい(page-aligned)。
ERPORT構造は、EREPORT命令の出力である。
計測値(MEASUREMENTS)は、ERDMR命令の出力パラメータであり、指定されたSECSからとられたエンクレーブの計測値レジスタ値(Measurement Register values)が含まれている。
キー要求(KEY_REQUEST)は、EGETKEY命令への入力パラメータであり、適切なキー、および、そのキーを導出するために必要なさらなるパラメータを選択するのに利用される。
この構造を、キー導出で利用することで、エンクレーブのセキュリティバージョンおよびエンクレーブのSE TCBに基づいてキーが生成される。TCBセキュリティバージョン構造の詳細については、プラットフォームTCB復帰仕様を参照のこと。
エンクレーブページキャッシュ・マップ(EPCM)は、プロセッサがページキャッシュの内容を追跡するために利用するセキュアな構造である。EPCMは、EPCに現在装填されている各ページのきっちり1つのエントリを保持する。
証明(認証)(attestation)は、特に遠隔の実体に対して、ソフトウェア1つがプラットフォーム上に構築されている、と示すプロセスである。セキュアなエンクレーブの場合には、遠隔のプラットフォームが、ソフトウェアが、そのソフトウェアが秘匿性およびデータ保護の観点で信頼性を確認される前に、エンクレーブ内で保護されている正規のプラットフォーム上で動作するように遠隔プラットフォームにより構築するメカニズムである。証明処理は、計測、格納、およびレポート(報告)という3段階からなる。 Attestation is the process of showing that one piece of software is built on a platform, especially to remote entities. In the case of a secure enclave, the remote platform runs on a legitimate platform protected within the enclave before the software is validated in terms of confidentiality and data protection. It is a mechanism built by a remote platform. The proof process consists of three stages: measurement, storage, and reporting.
エンクレーブの計測期間には、事前エンクレーブ構築と事後エンクレーブ構築という2つの期間が存在する。エンクレーブ命令は、構築されたエンクレーブを計測させる役割を果たす。ひとたびエンクレーブが構築されると、エンクレーブ内のソフトウェアが計測をする責任を負う。 There are two periods of enclave measurement, pre-enclave construction and post-enclave construction. The enclave instruction serves to measure the constructed enclave. Once the enclave is built, the software within the enclave is responsible for the measurements.
図9は、本発明の一実施形態にみることができる、クオーティングと称されるソフトウェア認証プロセスの一ステップを示す。一実施形態では、署名処理910により、計測値レジスタ901、902、903、904から、連結されたデータに、署名キー915を適用する。署名処理910の結果がクオート920である。
FIG. 9 shows one step of a software certification process called quartering, which can be seen in one embodiment of the present invention. In one embodiment, the
暗号結合計測(cryptographically binds measurements)を報告する処理は、プラットフォームにエンクレーブを生成するときになされる。このメカニズムは、この種類の機能が時にTPMコマンドとしてプラットフォームで利用可能になっていることから、しばしば「クオーティング」と称される。計測値レジスタ(MR)の値は、連結されてから、非対称鍵を用いて署名される。これに対向する者は単に、クオート構造で署名を検証して、このクオートの正当性を立証する必要がある。 The process of reporting cryptographically binds measurements is done when generating an enclave on the platform. This mechanism is often referred to as "quarting" because this type of functionality is sometimes available on the platform as a TPM command. The values in the measurement register (MR) are concatenated and then signed with an asymmetric key. Opponents simply need to verify the signature with a quote structure to justify this quote.
図10は、本発明の一実施形態における、計測値レジスタセット1000からクオートを生成するための各ステップを示す。ローカルレポート1005は、計測値レジスタ1000に対称認証キーでアクセスすることで生成することができる。クオーティング・エンクレーブ1025は、ローカルレポート1005を匿名のクオート1010または通常のクオート1020に変換するソフトウェアを含んでよい。
FIG. 10 shows each step for generating a quote from the measured value register set 1000 in one embodiment of the present invention. The
非対称鍵に関する計算の性質上、および、エンクレーブリーフの命令数を低減させたいという要望から、非対称署名を行わせる命令は含めないこととする。以下の図に示す我々の採る方法では、対称鍵認証キーに基づいて「レポート」を生成して、これらの対称鍵に基づく「レポート」を、エンクレーブを利用してそれ自身が保護されているソフトウェアを利用して、非対称署名の「クオート」に変換させる。クオーティング・エンクレーブ(Quoting Enclave)は、プラットフォーム証明キーにアクセスを有するまでに先ず認証されねばならないことから、クオーティング・エンクレーブ自身が、認証エンクレーブとして知られている特殊用途のエンクレーブである。 Due to the nature of calculations related to asymmetric keys and the desire to reduce the number of instructions in the enclave leaf, instructions that cause asymmetric signatures are not included. Our method, shown in the figure below, is software that generates "reports" based on symmetric key authentication keys and protects the "reports" based on these symmetric keys using enclaves. Is used to convert to an asymmetric signature "quote". The Quoting Enclave itself is a special purpose enclave known as a certified enclave, as the Quoting Enclave itself must first be authenticated before it has access to the platform certification key.
各エンクレーブは、2つの256ビットの幅の計測値レジスタ(MR_EADD&MR_POLICY)および2つのレザーブされたレジスタを提供する。これら計測値レジスタは、エンクレーブのSECS内に含められている。 Each enclave provides two 256-bit wide measurement registers (MR_EADD & MR_POLICY) and two leathered registers. These measurement value registers are included in the SECS of the enclave.
図11は、本発明の一実施形態における計測値レジスタMR_EADD1100を更新するEADDプロセスを示す。拡張処理1115は、MR_EADD1100の現在の値、ページデータ1105、およびページメタデータ1110を入力として利用することができる。拡張処理の出力がMR_EADD'1120であり、これは、MR_EADD1100に格納される次の値となる。
FIG. 11 shows an EADD process for updating the measurement value register MR_EADD1100 according to an embodiment of the present invention. The
MR_EADDは、EINIT命令が呼び出される前にEADD命令を利用して構築されたものであるので、エンクレーブの集合計測値を含んでいる。これはマイクロコードにより書き込まれるので、エンクレーブコードが読み取りだけができるSECSのページに配置される必要がある。EADDは、呼び出される毎に、SHA256をページデータおよびそのページに関連付けられたセキュリティメタデータに計算して(つまり、これはページおよびページのSEC_INFOフラグの(エンクレーブのベースアドレスに対する)相対アドレスである)、この値をMR_EADD1100に拡張する。「拡張」とは、新たなMR値=ハッシュ(古いMR値||入力値)という意味である。 Since MR_EADD was constructed by using the EADD instruction before the EIIND instruction was called, it includes the set measurement value of the enclave. Since it is written by microcode, the enclave code needs to be placed on a readable SECS page. Each time the EADD is called, it calculates SHA256 into the page data and the security metadata associated with that page (ie, this is the relative address (that is, to the base address of the enclave) of the page and the SEC_INFO flag of the page). , This value is extended to MR_EADD1100. "Extended" means new MR value = hash (old MR value || input value).
MR_POLICYは、エンクレーブの起動を許可するポリシーを認証するときに利用されるポリシーの値を含んでいる。この値は、起動時にSECS内に配置されたエンクレーブ許可証から取り出されて、EINIT命令が成功裏に完了したものとしてコピーされたものである。MR_POLICYは、マクロコードによってのみ書き込まれるので、エンクレーブコードからは読み取りしかできないSECSのページに配置される必要がある。 MR_POLICY contains the value of the policy used when authenticating the policy that allows the activation of the enclave. This value was taken from the enclave permit placed in the SECS at startup and copied as if the EIINT instruction had been successfully completed. Since MR_POLICY is written only by the macro code, it needs to be placed on the SECS page that can only be read from the enclave code.
図12は、本発明の一実施形態におけるレポートを生成するEREPORT命令を示す。キーID1200、所有者エポック1205、パッケージヒューズキー1210、および固定ストリングMACキー1215が、導出命令1220に入力される可能性がある。導出1220の出力は、CMAC1225を、TCBバージョン1232、ISVバージョン1234、機能1236、フラグ1238、ユーザデータ1240、および計測値レジスタ1242の現在の値とともに入力することができる。CMAC1225の出力は、MAC1244に格納することができる。EREPORT命令の出力は、キー識別子1230、TCBバージョン1232、ISVバージョン1234、機能1236、フラグ1238、ユーザデータ1240、計測値レジスタ1242、およびMAC1244を含むことができる。
FIG. 12 shows an EREPORT instruction that produces a report according to an embodiment of the present invention.
EREPORT命令は、対称鍵ベースのGMACを計測値レジスタ、ユーザデータ、およびさらなるコンテキスト情報(例えば、エンクレーブの機能およびフラグ)に行うための中間鍵を生成する。 The EREPORT instruction generates an intermediate key for performing symmetric key-based GMAC on measurement registers, user data, and additional contextual information (eg, enclave functions and flags).
計測値レジスタに加えて、ユーザは256ビットの幅のデータブロックを提供して、レポートに含めさせることができる。ユーザは、多くのアプリケーション特定の値(例えばチャレンジャNONCEおよび/またはアプリケーション作成キー)の証明を希望する。これらの値は、単一のハッシュに低減(reduce)され、レポート内に含ませることができる。 In addition to the measurement register, the user can provide a 256-bit wide data block for inclusion in the report. The user wants to prove many application-specific values (eg, challenger NONCE and / or application creation key). These values are reduced to a single hash and can be included in the report.
キーの磨耗を防ぐために、EREPORTを繰り返し呼び出して、乱数128ビット値(reportKeyIDとして知られている)を、プロセッサの各電力サイクルで生成して、内部の位置に格納する。この値は、この値を利用した2∧32AES処理の後に増分される。一実施形態では、EREPORT命令への各呼び出しによってこの値を1つ増分させる。
レポート構造中のフラグフィールドは、チャレンジャがエンクレーブを信頼してよいかを確かめるために有用なので、エンクレーブについてのある状態情報を決定するために、または、EREPORT命令を呼び出したときに利用することができる。
一実施形態では、適切な機能セットを有するアーキテクチャエンクレーブが、EGETKEYコマンドを有するCMAC処理で利用されるキーを取得することがアーキテクチャにより許可されているので、現在実行されているハードウェアでレポートが生成されたことを検証することができる。この機能はクオーティング・アーキテクチャ・エンクレーブに限定されている。 In one embodiment, the architecture enclave with the appropriate feature set is allowed by the architecture to obtain the key used in CMAC processing with the EGETKEY command, so the report is generated on the currently running hardware. It can be verified that it was done. This feature is limited to the Quartering Architecture Enclave.
エンクレーブ外で実行しているときにエンクレーブの計測値を取得するために、ERDMR(計測値読み取り)命令が提供される。この命令は、有効なSECSページへのポインタ、および、計測値を配信するアドレスへのポインタを採る。計測値は、MEASUREMENT構造の形態で配信される。MEASUREMENT構造は暗号による保護(暗号保護)はされない。
エンクレーブページキャッシュ内にないときにはエンクレーブページは暗号により保護される。暗号保護には、機密保護、偽造保護、および再生保護という3つのレベルがある。一実施形態では、アプリケーションが、同じエンクレーブの他のページについて選択された保護レベルとは独立して各エンクレーブページの保護レベルを選択することができる。エンクレーブの実装により、アプリケーションは、偽造保護、偽造保護、および再生保護、機密保護および偽造保護、および機密保護、偽造保護、よび再生保護という組み合わせから選択を行うことができる。機密保護および偽造保護をエンクレーブページに行うには、GCM(Galois Counter Mode)等の幾つかの認証された暗号モードのうちいずれかを、AES等の適切な暗号法とともに利用することができる。しかし、再生保護には、より高度な解決法が要求される。 Enclave pages are cryptographically protected when they are not in the enclave page cache. There are three levels of cryptographic protection: security, counterfeit protection, and replay protection. In one embodiment, the application can select the protection level for each enclave page independently of the protection level selected for other pages in the same enclave. Enclave implementation allows applications to choose from a combination of counterfeit protection, counterfeit protection, and rehabilitation protection, security and counterfeit protection, and security, counterfeit protection, and rehabilitation protection. For security and counterfeit protection on enclave pages, any of several authenticated cipher modes such as GCM (Galois Counter Mode) can be used with appropriate cryptography such as AES. However, regeneration protection requires more sophisticated solutions.
図13は、本発明の一実施形態にみることができる、偽造保護および再生保護メカニズムを示している。偽造保護により、攻撃者が、プログラムが生成していない暗号化されたデータの別の値で置き換えることが防がれる。レプレイ保護により、攻撃者が、プログラムが生成した現在の最新値ではない暗号化されたデータの値で置き換えることが防がれる。ノードバージョン番号1300はIV1310に入り、その後GMAC1325アルゴリズムに入ることができる。子1305のバージョン番号は、データ1315をGMAC1325アルゴリズムに送ることができる。GMAC1325アルゴリズムは、キー1320、IV1310、およびデータ1315を組み合わせてMAC1330を生成する。
FIG. 13 shows a counterfeit protection and regeneration protection mechanism that can be seen in one embodiment of the present invention. Counterfeit protection prevents an attacker from replacing the encrypted data that the program did not generate with another value. Replay protection prevents an attacker from replacing the value of encrypted data that is not currently up-to-date generated by the program.
再生保護によって、論理プロセッサが任意の時点に見るエンクレーブの全てのコンテンツが、破損してないエンクレーブの単一のスナップショットに属するように保証される。従って再生保護メカニズムは、エンクレーブバージョンのコンセプトを定義して、偽造保護されたエンクレーブページが、エンクレーブのそのバージョンに属すかを判断するメカニズムを提供する必要がある。この目的のために、再生保護メカニズムは、GMAC等のメッセージ認証アルゴリズムを利用して、偽造保護されたエンクレーブページ各々の内容をページバージョン番号に結びつける。GMACの場合には、このバージョンは、図13に示す初期化ベクトル(IV)の一部として利用することができる。 Playback protection ensures that all content in the enclave that the logical processor sees at any given time belongs to a single snapshot of the uncorrupted enclave. Regeneration protection mechanisms therefore need to define the concept of an enclave version and provide a mechanism to determine if a counterfeit protected enclave page belongs to that version of the enclave. For this purpose, the replay protection mechanism utilizes a message authentication algorithm such as GMAC to link the content of each counterfeit protected enclave page to the page version number. In the case of GMAC, this version is available as part of the initialization vector (IV) shown in FIG.
図14は、本発明の一実施形態に見られる中継保護メカニズムのMACツリー構造の部分の一例を示す。リーフノード1425は、個々のMACコンテンツページ1430のバージョン情報を含みうる。1420等の各リーフノードは、個々のMACコンテンツページを含む(不図示)。各内部ノード1410、1415は、リンク先の子のグループのバージョン情報を含みうる。ルート1400は、ツリーデータ構造の最高位のノードである。
FIG. 14 shows an example of a part of the MAC tree structure of the relay protection mechanism found in one embodiment of the present invention.
全エンクレーブに対するバージョン付けを拡張するために、再生保護メカニズムは、バージョンツリーを維持する。リーフノードは、エンクレーブインスタンスの個々の再生保護されたページのバージョンを含む。各内部ノードは、子の各グループのバージョンを提供するので、それらが表すページのバージョン情報を論理的に保持している。図14はこのコンセプトを図式化している。 To extend versioning for all enclaves, the replay protection mechanism maintains a version tree. The leaf node contains the individual play-protected page versions of the enclave instance. Since each internal node provides a version of each group of children, it logically holds the version information of the page they represent. FIG. 14 illustrates this concept.
一実施形態では、O(n)ページをO(log n)へと処理する必要のあるデータ数を低減させるようにツリー構造が選択されている。ハッシュツリーではなくてバージョンツリーを利用することで、ツリーを更新することなくEPCからのページの強制退去が可能となる。 In one embodiment, the tree structure is chosen to reduce the number of data that needs to be processed into O (log n) pages. By using the version tree instead of the hash tree, it is possible to forcibly remove the page from the EPC without updating the tree.
再生保護では各ページのバージョンが暗号的に自身の内容に結び付けられている必要があるので、再生保護では偽造保護が必要となる。従って、SEアーキテクチャにおいては偽造保護が必須である。さらに、SEを始めから実装しておくことにより、サポートされる保護の組み合わせのリストがさらに制限されうる。 Playback protection requires counterfeit protection because the version of each page must be cryptographically tied to its own content. Therefore, counterfeit protection is essential in the SE architecture. Moreover, implementing SE from the beginning can further limit the list of supported protection combinations.
OS/VMMは、ECREATE命令を実行することによりエンクレーブを生成する。エンクレーブの生成中に、エンクレーブにより保護されるリニアアドレスの範囲が特定される。このリニアアドレスの範囲は、エンクレーブリニア空間(ELS)レンジとして知られている。 The OS / VMM creates an enclave by executing the ECREATE instruction. During enclave generation, the range of linear addresses protected by the enclave is identified. This range of linear addresses is known as the Enclave Linear Space (ELS) range.
ひとたびエンクレーブが生成されると、ELSレンジに属している個々のページを、EADDPRE命令を利用してエンクレーブに追加する。EADDPRE命令は、追加されたページの各々を、これらのページをエンクレーブページキャッシュ内に移動させることにより、エンクレーブ保護領域に移動させる。EWBINVPGを利用してこれらページのいずれかがEPC外に置かれている場合、論理プロセッサは、これらページに暗号保護を行う。 Once the enclave is generated, individual pages belonging to the ELS range are added to the enclave using the EADDPRE instruction. The EADDPRE instruction moves each of the added pages to the enclave protected area by moving these pages into the enclave page cache. If any of these pages are located outside the EPC using EWBINVPG, the logical processor provides cryptographic protection to these pages.
暗号保護は、各エンクレーブページに暗号メタデータを関連付けることにより行われる。メタデータは、uCodeのフローにより、様々なプロセッサ命令がエンクレーブページのコンテンツを復号して、各エンクレーブページの信頼性/フレッシュネスを検証するために利用される。SEアーキテクチャは、暗号メタデータを更新、管理、およびその正当性を立証(validate)するためにこのような命令を幾つか提供する。 Cryptographic protection is provided by associating cryptographic metadata with each enclave page. The metadata is used by various processor instructions to decrypt the contents of the enclave page and verify the reliability / freshness of each enclave page according to the uCode flow. The SE architecture provides several such instructions to update, manage, and validate cryptographic metadata.
各エンクレーブページは、セキュリティ情報SEC_INFOデータ構造に関連付けられている。SEC_INFOデータ構造の目的は、ページを復号および検証する必要のある暗号メタデータを保持することである。SEC_INFO構造の様々なフィールドは以下の通りである。
セキュリティ情報フラグ(SEC_INFO.Flags)は、保護されているページのページタイプ、暗号およびアクセス保護を記述する。
セキュリティマップ(SMAP)は、エンクレーブページのフレッシュネスを検証するために必要となる暗号メタデータを格納するのに利用されるデータ構造である(つまり再生保護)。セキュリティマップは、エンクレーブの特定のスナップショットの完全バージョンのツリーを表す。セキュリティマップの各ノードは、256の子のノード(リーフノードの場合にはエンクレーブページ)のバージョンを保持する。セキュリティノードに関するさらなるメタデータが、特定のSMAPノードのSEC_INFO内に含められる。 A security map (SMAP) is a data structure used to store cryptographic metadata needed to verify the freshness of an enclave page (ie, replay protection). The security map represents a tree of full versions of a particular snapshot of the enclave. Each node in the security map holds a version of 256 child nodes (enclave pages in the case of leaf nodes). Further metadata about the security node is included within the SEC_INFO of a particular SMAP node.
一実施形態では、セキュリティマップツリーは2レベル深くてよく(セキュリティマップの深さは、SEアーキテクチャによりサポートされるエンクレーブのサイズに関している。Gen1では、SEアーキテクチャは最大エンクレーブサイズ32GBをサポートしている。)、エンクレーブ内のエンクレーブページのエンクレーブオフセットを利用してアクセスされる。SMAPのルートは、SECSに含められ、128の子のノードのバージョンのみを保持する。エンクレーブオフセットのビットは、適切な子を選択するのに利用され、SMAPにインデックスするのに利用される。gen1では、エンクレーブオフセットは35ビット長である。エンクレーブオフセットは、以下の公式により抽出される(エンクレーブリニアアドレス&エンクレーブマスク)。エンクレーブマスクは、(エンクレーブのサイズ−1)で求められ、ECREATE中に計算することができる。
一般的には、深さl>1において、ビットN−(l)×8からN−(l+1)×8+1を利用して、次のレベルの適切な子を選択する。 Generally, at a depth of l> 1, bits N- (l) x 8 to N- (l + 1) x 8 + 1 are used to select the appropriate child of the next level.
注:セキュリティマップは、論理データ構造であり、アーキテクチャではない。論理プロセッサは、SMAPが位置しているリニアアドレス空間の位置についてすら認識していない。システムソフトウェアは、セキュリティマップを維持および探索(walking)する役割を担う。セキュリティマップの各個々のノードは、アーキテクチャにより定義された構造を有するが、アーキテクチャは、セキュリティマップがどのようにメモリ内に維持されているかを特定しない。しかし、セキュリティマップ内の各ノードが、セキュリティマップ内によく定義された論理位置を有しており、ノードがマップ内であちこち移動する場合にはセキュリティマップに関する様々なプロセッサ命令が、それを攻撃のシナリオとして解釈する、ということに留意されたい。 Note: Security maps are logical data structures, not architectures. The logical processor is not even aware of the location in the linear address space where SMAP is located. The system software is responsible for maintaining and walking the security map. Each individual node of the security map has a structure defined by the architecture, but the architecture does not specify how the security map is maintained in memory. However, each node in the security map has a well-defined logical position in the security map, and when the node moves around in the map, various processor instructions on the security map attack it. Note that it is interpreted as a scenario.
ルートセキュリティノードは、SECSに含まれており、128の子のバージョン情報を含んでいる。非ルートセキュリティノードは、保護されたページであり、関連付けられたSEC_INFO(and its associated SEC_INFO)である。保護されたページは、256の子のバージョン情報を含む。
SEC_INFOは、SMAP内のSMAPの位置を含む。SMAPの位置は、リニア/エンクレーブオフセットおよびページタイプSMAP_LEVEL_1およびSMAP_LEVEL_2により決定される。 SEC_INFO includes the location of SMAP within SMAP. The position of SMAP is determined by the linear / enclave offset and page types SMAP_LEVEL_1 and SMAP_LEVEL_2.
再生保護されたエンクレーブページを追加するためには、SMAPの親が生成されて、FCRビットがクリアされた状態でEPC内に常駐している必要がある。エンクレーブページの整合性を検証するために、論理プロセッサは、SEC_INFO構造内のIV_Pおよびkey_idを利用してキーを生成する。このキーを利用して、SEC_INFO構造およびページの内容内のフラグに対してMACを計算する。計算されたMACは、SEC_INFO構造内に設けられているMACと比較される。MAC同士が整合する場合に、このページが整合性チェックに合格したとみなすことができる。 In order to add a play-protected enclave page, the SMAP parent must be generated and resident in the EPC with the FCR bit cleared. To verify the integrity of the enclave page, the logical processor utilizes IV_P and key_id in the SEC_INFO structure to generate the key. This key is used to calculate the MAC for the SEC_INFO structure and the flags in the page content. The calculated MAC is compared with the MAC provided in the SEC_INFO structure. If the MACs match, this page can be considered to have passed the consistency check.
論理プロセッサは、ELPG命令を利用してEPCにページを装填するときに、ページの整合性を検証する。この命令の一部として、論理プロセッサは、ページの検証に利用されたSEC_INF構造からIV_Pを記憶する(note down)。 The logical processor verifies the integrity of the page when loading the page into the EPC using the ELPG instruction. As part of this instruction, the logical processor notes down IV_P from the SEC_INF structure used to validate the page.
エンクレーブページのフレッシュネスを検証するために、論理プロセッサは、エンクレーブページおよびそのsmapの親がEPCに装填されており、smapの親がフレッシュであることを検証する。そして、ページのバージョンを、smapの親に格納されているバージョンと比較する。これら2つのバージョンが合致した場合には、プロセッサは、このページの新たなバージョンを生成して、smapの親のバージョンとエンクレーブページのバージョンを更新する。最後に、エンクレーブページをフレッシュであると表示する。 To verify the freshness of the enclave page, the logical processor verifies that the enclave page and its smap parent are loaded into the EPC and the smap parent is fresh. Then, the version of the page is compared with the version stored in the parent of smap. If these two versions match, the processor will generate a new version of this page to update the parent version of smap and the version of the enclave page. Finally, display the enclave page as fresh.
注:新たなバージョン生成によって、ページを修正可能なものにすることができる。これにより、アーキテクチャおよび実装両方が簡単になる。 Note: A new version generation can make the page modifiable. This simplifies both architecture and implementation.
エンクレーブページを除去するために、論理プロセッサは、エンクレーブページとそのsmapの親とがEPCに装填されており、両方ともフレッシュであることを検証する。そして、smapの親のページのバージョンを0に設定して、エンクレーブページのEPCスロットを利用可能であると表示する。 To remove the enclave page, the logical processor verifies that the enclave page and its smap parent are loaded into the EPC and both are fresh. Then, the version of the parent page of smap is set to 0 to indicate that the EPC slot of the enclave page is available.
エンクレーブページキャッシュ(EPC)は、CPUが、SE暗号保護により暗号保護を受けていないエンクレーブページを一時的に格納するために利用するセキュアなストレージである。 The Enclave Page Cache (EPC) is a secure storage used by the CPU to temporarily store enclave pages that are not cryptographically protected by SE cryptographic protection.
以下の要件がEPCで特定される。非デバッグエンクレーブに属すEPCに装填されるエンクレーブメモリページへのアクセスは、エンクレーブ外のソフトウェア実体による修正から保護することができる。攻撃者は、直接のハードウェア攻撃では、EPCに装填されている非デバッグエンクレーブに属す平文データを読み取ることができない。また攻撃者は、直接のハードウェア攻撃では、非デバッグエンクレーブに属すEPCのデータを修正することができない。システムのCPUは、EPCに装填されるデータにコヒーレント且つセキュアにアクセスすることができる。 The following requirements are specified in the EPC. Access to enclave memory pages loaded into an EPC belonging to a non-debug enclave can be protected from modification by software entities outside the enclave. An attacker cannot read the plaintext data belonging to the non-debugging enclave loaded in the EPC by a direct hardware attack. In addition, an attacker cannot modify the data of the EPC belonging to the non-debug enclave by a direct hardware attack. The CPU of the system can coherently and securely access the data loaded in the EPC.
EPCを実装するメカニズムは幾つかある。EPCは、オンダイSRAMまたはeDRAMの上に実装可能である。EPCはさらに、CPUの最終レベルキャッシュのやり方を動的に隔離することにより構築することもできる。この実装例では、パッケージの外部からの許可されていないアクセスからEPCを保護することができる。一方でシステム内の他のパッケージは、EPCにコヒーレント且つセキュアにアクセスすることができる。 There are several mechanisms for implementing EPC. The EPC can be mounted on top of on-die SRAM or eDRAM. EPC can also be constructed by dynamically isolating the CPU's final level cache method. In this implementation example, the EPC can be protected from unauthorized access from outside the package. On the other hand, other packages in the system can coherently and securely access the EPC.
EPCを実装する別のメカニズムに、クリプト・メモリ・アパーチャ(Crypto Memory Aperture)がある。クリプト・メモリ・アパーチャ(Crypto Memory Aperture)は、プラットフォームDRAMを利用して暗号により保護された揮発性ストレージを生成する費用効果のよいメカニズムを提供する。CMAは、CPUアンコア(CPU uncore)内の1以上の戦略的に配置された暗号ユニットを利用してカスタマ技術が必要とする様々なレベルの保護を提供する。様々なアンコア(uncore)エージェントは、CMAに対するメモリアクセスを認識し、これら25のアクセスをアンコア内に位置しているクリプト・コントローラにルーティングするよう修正される。クリプト・コントローラは、所望の保護レベルに応じて、プラットフォームDRAMへの1以上のメモリアクセスを生成して、暗号文を取得する。そして、暗号文を処理して、平文を得て、元のCMAメモリ要求を満たす。CMAは、Intel QuickPathインターコネクト(QPI)プロトコルに完全に統合されており、QPIプロトコルへのセキュリティ拡張によりマルチパッケージプラットフォームにスケーリングされる。マルチパッケージプラットフォーム30の構成では、CMAは、外的に対面している(externally facing)QPIリンク層のリンクレベルのセキュリティ(Link−Sec)エンジンを利用して、Intel CPUの間のメモリ転送を保護する。 Another mechanism for implementing EPC is the Crypto Memory Aperture. Crypto Memory Aperture provides a cost-effective mechanism for using platform DRAM to generate cryptographically protected volatile storage. The CMA utilizes one or more strategically placed cryptographic units within a CPU uncore to provide the various levels of protection required by customer technology. Various uncore agents are modified to recognize memory access to the CMA and route these 25 accesses to crypto controllers located within the uncore. The crypto controller generates one or more memory accesses to the platform DRAM to obtain the ciphertext, depending on the desired level of protection. Then, the ciphertext is processed to obtain the plaintext and satisfy the original CMA memory request. CMA is fully integrated with the Intel QuickPath Interconnect (QPI) protocol and will be scaled to a multi-package platform with security enhancements to the QPI protocol. In the configuration of the multi-package platform 30, the CMA utilizes a link-level security (Link-Sec) engine in the externally facing QPI link layer to protect memory transfers between Intel CPUs. To do.
SECSは、EPCに現在装填されている場合にアクティブと称される。本書類では後述するように、OS/VMMは、EPCに装填されるものを管理する役割を果たす。しかし、EPCにエンクレーブページを装填する間に、OS/VMMは、その対象ページ自身がSECSである場合を除いて、CPUにそのページのSECSの所在を伝える。装填されているページがSECSではない場合には、CPUは、そのページに対応するSECSをEPC内に配置するよう要求する。エンクレーブのページを装填する前にはいつでも、OS/VMMは、そのエンクレーブのSECSをEPCに装填してよい(MAY load)。 SECS is referred to as active when it is currently loaded on the EPC. As will be described later in this document, the OS / VMM plays a role of managing what is loaded in the EPC. However, while loading the enclave page into the EPC, the OS / VMM informs the CPU of the location of the SECS of the page unless the target page itself is the SECS. If the loaded page is not SECS, the CPU requests that the SECS corresponding to that page be placed in the EPC. At any time before loading an enclave page, the OS / VMM MAY load the EPC with the enclave's SECS.
CPUは、SECSをEPCに装填することのできる回数に対しては制約を課しはしないが、OS/VMMがエンクレーブページキャッシュにSECSのコピーを複数装填するようなことが頻繁に行われるとは考えにくい。とはいえ、もしも同じSECSの複数のコピーがEPCに装填される場合には、これらコピーそれぞれを別個のアクティブSECSインスタンスとして捉え、アクティブSECSの異なるインスタンスに属すEPCに装填されたエンクレーブページを、ハードウェアによりそれぞれ異なるエンクレーブに属すものとして捉える。 The CPU does not impose a limit on the number of times the SECS can be loaded into the EPC, but it is often the case that the OS / VMM loads multiple copies of the SECS into the enclave page cache. Very Hard to think. However, if multiple copies of the same SECS are loaded into the EPC, each of these copies will be considered as a separate active SECS instance, and the enclave pages loaded into the EPC belonging to different instances of the active SECS will be hardened. It is regarded as belonging to different enclaves depending on the wear.
OS/VMMは、EPCを、システムアドレス空間の物理メモリの連続ブロックとしてとらえる(10)。しかし、内部ストレージを低減させて、高速インデックスを可能とするために、CPUは、スロット識別子(SID)を各EPCページに関連付ける。EPCページの物理アドレスおよび対応するスロット識別子は、以下のように互いに関連している。
sid=(page_pa-epc_base_pa)>>12
page_pa=pc_base_p|(sid<<12)
The OS / VMM regards the EPC as a continuous block of physical memory in the system address space (10). However, in order to reduce internal storage and enable fast indexing, the CPU associates a slot identifier (SID) with each EPC page. The physical address of the EPC page and the corresponding slot identifier are related to each other as follows.
sid = (page_pa-epc_base_pa) >> 12
page_pa = pc_base_p | (sid << 12)
ハードウェアは、0xFFという特殊なスロットを用いて、無効なスロットを示す。EPCスロット識別子は、uCodeおよびPMH両方により利用されて、エンクレーブページに関する情報を追跡する。 The hardware uses a special slot called 0xFF to indicate an invalid slot. The EPC slot identifier is utilized by both uCode and PMH to track information about the enclave page.
EPCに装填される全てのエンクレーブページは、よく定義されたシステム物理アドレスを有する。EPCに属す物理アドレスおよびEPCスロット識別子間に一対一のマッピング関係があることから、EPCに装填される各ページは自身のEPCスロット識別子あるいはEPC_SIDを有するということができよう。 Every enclave page loaded into the EPC has a well-defined system physical address. Since there is a one-to-one mapping relationship between the physical address belonging to the EPC and the EPC slot identifier, it can be said that each page loaded in the EPC has its own EPC slot identifier or EPC_SID.
加えて、SECSページを除く、EPCに装填される全てのエンクレーブページは、アクティブSECSインスタンスと関連付けられる。アクティブSECSインスタンスが、EPCに装填されたSECSページにすぎないことを想起されたい。この結果、アクティブSECSページも自身のEPC_SIDを有する。非SECSエンクレーブページが属すSECSページのEPC_SIDは、非SECS25ページのSECS_SIDと称される。EPCに装填される各ページについて、ハードウェアはSECS_SIDの記録をとっておく。EPCに装填されるSECSページのSECS_SIDは、0xFF(または無効SID)と定義される。 In addition, all enclave pages loaded into the EPC, with the exception of SECS pages, are associated with an active SECS instance. Recall that the active SECS instance is just a SECS page loaded into the EPC. As a result, the active SECS page also has its own EPC_SID. The EPC_SID of the SECS page to which the non-SECS enclave page belongs is referred to as the SECS_SID of the non-SECS 25 page. For each page loaded into the EPC, the hardware keeps a record of SECS_SID. The SECS_SID of the SECS page loaded into the EPC is defined as 0xFF (or invalid SID).
EPCMは、プロセッサがページキャッシュの内容を追跡するために利用するセキュアな構造である。30EPCMは、EPCに現在装填されている各ページのきっちり1つのエントリを保持する。それが表すページにおいては、各EPCMエントリが、ページが属すエンクレーブ、ページがエンクレーブページキャッシュに移動させられるリニアアドレス、ページのバージョン等の情報を追跡する。EPCM構造は、アドレス変換フローにおいてCPUにより利用されて、EPCに装填されるエンクレーブページに対してアクセス制御を実施する。EPCMエントリは、(x)uCodeにより、様々な命令フローの一環として管理される。 The ECCM is a secure structure used by the processor to track the contents of the page cache. The 30 EPCM holds exactly one entry for each page currently loaded in the EPC. In the page it represents, each EPCM entry tracks information such as the enclave to which the page belongs, the linear address by which the page is moved to the enclave page cache, and the page version. The EPCM structure is utilized by the CPU in the address translation flow to perform access control on the enclave page loaded in the EPC. The EPC M entry is managed by (x) uCode as part of various instruction flows.
本発明の一実施形態では、エンクレーブページキャッシュ(EPC)は、割り当て、割り当て解除が動的に行われてよい。一実施形態では、オペレーティングシステム等のソフトウェアが、EPC等のメモリページを割り当てたり、EPCのメモリ割り当て解除を行ったりする。一実施形態では、オペレーティングシステムは、エンクレーブの任意のページをEPC内に割り当てることもできる。一部の実施形態では、EPCは、メモリ内の全ての利用可能な位置を占めてよい。一実施形態において、動的EPCの固定EPCとの1つの違いは、動的EPCがメモリのページの追加および除去を可能とすることである。一実施形態では、ソフトウェアドライバ等の論理が、メモリ領域をEPCとして割り当てたり、EPCのメモリ割り当てを解除したりする。一実施形態では、起動前処理によりメモリの各ページのメタデータの格納に利用できるメモリがチェックされ、ソフトウェアがページをEPCまたは非EPCであると宣言し、ハードウェア論理が各ページの属性の追跡・実施(enforce)を行ってよい。 In one embodiment of the invention, the enclave page cache (EPC) may be dynamically allocated and deallocated. In one embodiment, software such as an operating system allocates memory pages such as EPC and deallocates memory of EPC. In one embodiment, the operating system can also allocate any page of the enclave within the EPC. In some embodiments, the EPC may occupy all available locations in memory. In one embodiment, one difference between the dynamic EPC and the fixed EPC is that the dynamic EPC allows the addition and removal of pages of memory. In one embodiment, the logic of a software driver or the like allocates a memory area as an EPC or cancels the memory allocation of the EPC. In one embodiment, preboot processing checks the memory available for storing metadata for each page of memory, the software declares the page EPC or non-EPC, and the hardware logic tracks the attributes of each page.・ Enforcement may be performed.
一実施形態では、ハードウェア論理は、変換ルックアサイドバッファ(TLB)およびページミスハンドラ(PMH)によって、EPCとして利用されるメモリに対するアクセスを制御してよい。一実施形態では、検索アドレスがTLB内に合致するものがあるとき(TLBヒットとして知られている)、セキュアなエンクレーブがEPCを退出するときにTLBをフラッシュしてよい。一実施形態では、検索アドレスがTLBに合致するものがない場合(TLBミスとして知られている)、さらなるルックアップによって、複数のメモリ参照においてエンクレーブページキャッシュマップ(EPCM)からデータを取得することができる。一実施形態では、PMHは、EPCMのルックアップを行うことができる。別の実施形態では、PMHのレンジレジスタをチェックして、連続物理アドレス、EPCに対する制御を制御する。オペレーティングシステムは、EPCページへのアクセスとして、直接メモリアクセス(DMA)を許可しない。もしもメモリの戻りページが、エンクレーブページとして表示されていた場合には、そのページのセキュアなエンクレーブ制御構造識別子(SECSID)を、現在実行中のエンクレーブと比較して、アクセスがセキュアであることを確かめてよい。戻りページのSECSIDと、現在実行中のエンクレーブのものとが合致しない場合には、PMHは停止メッセージを発行してよい。メモリの戻りページがエンクレーブページとして表示されていない場合、またはメモリの戻りページがエンクレーブページとして表示されており、そのページのSECSIDが実行中のエンクレーブのものと合致する場合には、PMHは、ページ変換をTLBに装填してよい。一実施形態では、キャッシュタグを利用して、書き戻しサイクルで他のラインからエンクレーブラインを識別することができる。しかし、少なくとも1つの実施形態では、そのタイプのメモリ要求が書き戻しサイクル中にEPCMにアクセスすると論理が判断する場合には、キャッシュタグは利用されない。 In one embodiment, hardware logic may control access to memory utilized as an EPC by a translation lookaside buffer (TLB) and a page miss handler (PMH). In one embodiment, the TLB may be flushed when the secure enclave exits the EPC when there is a match in the TLB (known as a TLB hit). In one embodiment, if the search address does not match the TLB (known as a TLB miss), further lookups may be used to retrieve data from the Enclave Page Cache Map (EPCM) in multiple memory references. it can. In one embodiment, the PMH can perform an EPCM lookup. In another embodiment, the PMH range register is checked to control control over continuous physical addresses and EPCs. The operating system does not allow direct memory access (DMA) as access to EPC pages. If the memory return page is displayed as an enclave page, compare the page's secure enclave control structure identifier (SECSID) with the currently running enclave to ensure that access is secure. You can. If the SECSID on the return page does not match that of the currently running enclave, PMH may issue a stop message. If the memory return page is not displayed as an enclave page, or if the memory return page is displayed as an enclave page and the SECSID of that page matches that of the running enclave, then the PMH is a page. The conversion may be loaded into the TLB. In one embodiment, cache tags can be used to identify enclave lines from other lines in a write-back cycle. However, in at least one embodiment, the cache tag is not utilized if the logic determines that a memory request of that type will access the EPCM during the write-back cycle.
本発明の一実施形態では、ソフトウェア、BIOSが、オペレーティングシステムが起動してエンクレーブページを作成する前に、メモリを割り当てることができる。一実施形態では、ソフトウェアは、BIOSの一連のステップによりEPCを生成することができる。BIOSは、あるメモリをメタデータの格納用にリザーブすることができ、各プロセッサについてレンジレジスタを設定することができる。BIOSは、ベースアドレスおよびメモリサイズを入力とすることができる。システム構成は、MCHECKという処理によりチェックされて、全てのパッケージおよび全てのコアにおける全てのレジスタを、エンクレーブ外のアクセスから保護することができる目的に適した設定とする。MCHECKは、システムがリセットされるまでレジスタをロックする。別の実施形態では、ソフトウェアは、メモリの部分をEPCの一部と宣言することの出来るEPCADDとして知られている命令によりEPCにページを追加することができる。EPCADDシーケンスは、メモリアドレスを入力とすることができ、成功または失敗を示すメッセージを出力することができる。EPCADDが成功を示すメッセージを出力する場合には、EPCADDは、EPCM.Eビットを設定することができ、その物理アドレスに対応するページをシステムの全てのTLBからフラッシュする。本発明の一実施形態では、EPCADDは、RAXにおける01のエラーコードを戻して、入力アドレスを有するページが既にEPCページであることを示し、02のエラーコードを戻して、入力アドレスが範囲外であることを示すことができる。EPCADDがEPCの一部であるとして宣言するメモリページは、EPCセマンティクスにデータにアクセスするよう要求してよい。本発明のこの実施形態では、ソフトウェアは、EWBINVGとして知られている命令のEPCからページを除去して、暗号化されたデータを、暗号保護および整合性保護を継続させながら、引き続き利用可能にすることができる。このフォーマットのデータは、ハードディスクドライブの通常メモリに格納することができる。また別の実施形態では、EPCREMOVEとして知られている命令のソフトウェアが、EPC内のページを除去して、暗号化されたデータを利用不可能にすることができる。EPCREMOVEを実行するハードウェアは、ページおよびEPCMの部分をクリアする。EPCREMOVEは、先ずEWBINVPGを実行することなく実行することができる。一実施形態では、EPCREMOVEシーケンスは、メモリアドレスに基づいてEPCからページを除去することができる。本発明の一実施形態では、EPCREMOVE命令は、RAXに01のエラーコードを含み、除去されるページが、セキュアなエンクレーブ制御構造(SECS)の一部であり、除去不可能であることを示し、02のエラーコードは、除去されるページがEPCページではないことを示す。メモリのページのグローバルTLB撃墜は、本発明の一実施形態におけるEPCREMOVEから生じてよく、ページに前に占有されていたメモリは、汎用ソフトウェアアクセス用に利用可能となってよい。 In one embodiment of the invention, the software, BIOS, can allocate memory before the operating system boots and creates an enclave page. In one embodiment, the software can generate an EPC through a series of steps in the BIOS. The BIOS can reserve a memory for storing metadata and set a range register for each processor. The BIOS can input the base address and memory size. The system configuration is checked by a process called MCHECK, and the settings are suitable for the purpose of protecting all registers in all packages and all cores from access outside the enclave. MCHECK locks the registers until the system is reset. In another embodiment, the software can add pages to the EPC by an instruction known as EPCADD that can declare a portion of memory as part of the EPC. The EPCADD sequence can take a memory address as input and output a message indicating success or failure. If the EPCADD outputs a message indicating success, the EPCADD may output an EPCADD. The E-bit can be set and the page corresponding to that physical address will be flushed from all TLBs in the system. In one embodiment of the invention, the EPCADD returns an error code of 01 in RAX to indicate that the page with the input address is already an EPC page, returns an error code of 02, and the input address is out of range. It can be shown that there is. Memory pages that the EPCADD declares to be part of the EPC may require EPC semantics to access the data. In this embodiment of the invention, the software removes pages from the EPC of the instruction known as EWBINVG to keep the encrypted data available while continuing cryptographic and integrity protection. be able to. Data in this format can be stored in the normal memory of the hard disk drive. In yet another embodiment, instruction software known as EPCREMOVE can remove pages within the EPC to make encrypted data unusable. The hardware that performs EPCREMOVE clears the page and the EPC M part. EPCREMOVE can be performed without first executing EWBINVPG. In one embodiment, the EPCREMOVE sequence can remove pages from the EPC based on the memory address. In one embodiment of the invention, the EPCREMOVE instruction contains an error code of 01 in the RAX, indicating that the page being removed is part of a secure enclave control structure (SECS) and cannot be removed. The error code of 02 indicates that the page to be removed is not an EPC page. The global TLB shot down of a page of memory may result from an EPCR EMOVE in one embodiment of the invention, and the memory previously occupied by the page may be available for general purpose software access.
PMHは、メモリ空間の保護されている領域へのアクセスを防止する。アーキテクチャによっては、これは、EPCへのアクセスの物理アドレスチェックのみといった簡単なもので済むこともある。さらなるPMHサポートを利用して、SEの性能向上または別の実装が可能となる場合もある。SEアーキテクチャは、エンクレーブページキャッシュに対するエンクレーブページへの不正アクセス防止にページミスハンドラ(PMH)を利用する。PMHは様々なイベントを検知して、これらイベントをマイクロコードに報告する。マイクロコードは、イベントをOS/VMMに報告してよい。次いでOS/VMMは、不良を修復するために適切な命令を実行することができる。 PMH prevents access to protected areas of memory space. Depending on the architecture, this may be as simple as checking the physical address of access to the EPC. Further PMH support may be used to improve SE performance or allow alternative implementations. The SE architecture utilizes a page miss handler (PMH) to prevent unauthorized access to the enclave page for the enclave page cache. PMH detects various events and reports these events to microcode. Microcode may report the event to the OS / VMM. The OS / VMM can then execute the appropriate instructions to repair the defect.
ECREATE命令を利用してエンクレーブを作成する場合には、リニアアドレスレンジをそのエンクレーブに対して指定する。このレンジは、そのエンクレーブの「リニアアドレスレンジ(linear address range)」と称される。エンクレーブのリニアアドレスレンジに属すメモリページは全て、エンクレーブの保護下にあり、SEC_INFOエントリが関連付けられていると考えることができる。 When creating an enclave using the ECREATE instruction, a linear address range is specified for that enclave. This range is referred to as the "linear address range" of the enclave. All memory pages belonging to the enclave's linear address range are under enclave protection and can be considered to have an SEC_INFO entry associated with them.
あるエンクレーブのリニアアドレスレンジに属すメモリページも、「エンクレーブページ(enclave page)」と称される。エンクレーブ内で実行しているプログラムは、エンクレーブページキャッシュ内に装填されておりそのページの所有者であるエンクレーブであるエンクレーブページにのみアクセスを許可される。プロセッサは、こうではない場合には例外クラスイベントを生成する。OS/VMMは、必要に応じて、エンクレーブページをEPCに装填する責任を負う。 A memory page that belongs to a linear address range of an enclave is also called an "enclave page". Programs running inside the enclave are loaded into the enclave page cache and are only allowed access to the enclave page that is the owner of the page. The processor raises an exception class event otherwise. The OS / VMM is responsible for loading the Enclave page into the EPC as needed.
論理プロセッサがエンクレーブを実行しており、そのエンクレーブページにメモリアクセスを生成する場合、このメモリアクセスは「エンクレーブアクセス(enclave access)」と称される。正しい実体によりアクセスされていることを確かめるためにかドレスチェックが行われてよい。 When a logical processor is performing an enclave and generates memory access to its enclave page, this memory access is referred to as "enclave access". A dress check may be done to ensure that it is being accessed by the correct entity.
一実施形態では、PMHは、アクセス制御機能を提供して、プログラムがエンクレーブ内で実行していないときにEPCを保護する。各論理プロセッサについてイネーブルされているレンジレジスタは、プロセッサがエンクレーブコードを実行していないときにEPCに対するアクセスを制限する。このレンジレジスタは、プロセッサがエンクレーブコードの実行を開始するとディセーブルされる。その持ち場において、プロセッサは特殊なページテーブルを定位置に置く。これらページテーブルは、プロセッサによる制御を受けて、そのエンクレーブが所有しているEPCページのみにアクセスを許可する。プロセッサおよびマイクロコードは、これら2つのメカニズムを利用してEPCへのアクセスを制限する。 In one embodiment, the PMH provides access control functionality to protect the EPC when the program is not running in the enclave. The range registers enabled for each logical processor limit access to the EPC when the processor is not executing enclave code. This range register is disabled when the processor starts executing enclave code. In that place, the processor puts a special page table in place. These page tables are controlled by the processor to allow access only to EPC pages owned by the enclave. Processors and microcode utilize these two mechanisms to limit access to the EPC.
一部の実施形態では、性能、実装の複雑性、シリコンのコストといった数多くの軸同士の間を調整されてよい。この章では、開発者に対して可能性ある調整例の幾つかを示すために3つの実装例を紹介する。以下の表8−1は、これら保護の例および必要となるPMHサポートを示す。
表8−1の第1行に示すとおり、必要なアクセス制御保護を提供するには追加のレンジレジスタは1つでよい。この特定の実装例では、他の保護はマイクロによって提供される。レンジレジスタは、論理プロセッサごとにイネーブルされてよい。このメカニズムを利用する基本実装例を図2−2に示す。 As shown in the first line of Table 8-1, only one additional range register is required to provide the required access control protection. In this particular implementation, other protections are provided by the micro. Range registers may be enabled on a per logical processor basis. An example of basic implementation using this mechanism is shown in Fig. 2-2.
PMHは、マイクロコードモードでもエンクレーブモードでも実行されていないLPからCMAレンジ(CPUのCMRRがカバーしている)へのアクセスを除去するよう修正される。加えて、エンクレーブモードで実行しているLPは、CMAのEPCサブレンジにのみアクセスを許可される。 The PMH is modified to remove access to the CMA range (covered by the CPU's CMRR) from LPs that are not running in either microcode or enclave mode. In addition, LPs running in enclave mode are only allowed access to the CMA's EPC subrange.
図15は、ページ不良エラーコードマップの実装を示す本発明の一実施形態を示す。ビット5 1540が設定されている場合、ビット9、ビット8、ビット7、ビット6を一緒に復号して、ページ不良エラーコードを決定することができる。resビット1512、I/Dビット1514、REVDビット1516、U/Sビット1518、W/Rビット1520、Pビット1522。
FIG. 15 shows an embodiment of the present invention showing the implementation of a page defect error code map. When
あるページがEPCにない場合、その旨を伝えるために「不良」がOS/VMMに提供される。表8−2に示すように、ページ不良エラーコードマップを変更する。これは、不良条件を報告するために利用される新たなビットを示している。EPC不良がない場合には、ビット5をゼロに設定して、ビット6から9もゼロに設定する。不良がEPC条件に起因している場合には、ビット5を設定して、ソフトウェアはビット6から9を復号して、EPC不良条件を解明してもよい。不良タイプについてのさらなる情報は次のセクションに記す。
If a page is not on the EPC, a "bad" is provided to the OS / VMM to inform it. Change the page defect error code map as shown in Table 8-2. This points to a new bit used to report bad conditions. If there is no EPC defect,
ページ不良エラーコードのビット5が設定されている場合、ビット6から9が所与であると解釈される(表8−2)。これは、このページ不良を起こした条件を示している。状態の一部は、通常処理では生じ得ないであろう不法の条件を示しており、OS/VMM管理エラーを示している。
攻撃からEPCを保護するためには、プラットフォームの全てのTLBのEPCアドレスを無効化するメカニズムを利用することができる。この特徴により、全てのコアに対して、特定のページの無効化を知らせることができる。次いで、全てのプロセッサから撃墜完了報告を受けるまで待つ。 To protect the EPC from attacks, a mechanism can be used to invalidate the EPC addresses of all TLBs on the platform. This feature allows all cores to be notified of a particular page being disabled. Then wait until all processors report the completion of the shooting.
エンクレーブが退出するたびに(EEXIT)、TLBは、TLBに現在存在しているエンクレーブページへのアクセスを禁ずることができる(may not allow accesses)。これは、TLBのクリアにより、またはさらなるビットを利用してエンクレーブエントリをタグ付けすることにより可能となる。 Each time the enclave exits (EEXIT), the TLB may not allow access to the enclave page that currently exists in the TLB. This is possible by clearing the TLB or by using additional bits to tag the enclave entry.
また別の方法としては、エンクレーブ退出時にTLBでエンクレーブビットを利用して、全てのエンクレーブエントリをクリアする、というものもある。別の方法としては、幾つかのビットを利用して特定のエンクレーブを特定するものもある。この場合、エンクレーブエントリは強制的に除去される必要がない。エンクレーブエントリは、tlbに残されてよい。アドレスをルックアップのためにtlbに送る場合には、これらビットはルックアップに追加される。これらビットは、エンクレーブの身元を示すコアからのエンクレーブidと比較される。ビットが合致した場合には、要求はこのエンクレーブから来ていることになる。合致しない場合には、要求がこのエンクレーブからのものではないことになるので、ルックアップはこの位置にヒットしない。 Another method is to use the enclave bit in the TLB when leaving the enclave to clear all enclave entries. Alternatively, some bits are used to identify a particular enclave. In this case, the enclave entry does not need to be forcibly removed. The enclave entry may be left in the tlb. If the address is sent to the tlb for lookup, these bits are added to the lookup. These bits are compared to the enclave id from the core that identifies the enclave. If the bits match, then the request comes from this enclave. If they do not match, the lookup does not hit this position because the request is not from this enclave.
エンクレーブ認証は、エンクレーブコードのエンクレーブ内における実行を許可した認可機関(つまり、このコードの著者/承認者)を見つける手段を提供する。エンクレーブ認証はさらに、エンクレーブマイクロコードフロー、フレキシブルシール&レポート、および、幾つかの新たなビジネスモデルの実施点を外部委託するファウンデーションも提供する。 Enclave certification provides a means of finding an authorization body (ie, the author / approver of this code) who has authorized the execution of the enclave code within the enclave. Enclave Certification also offers Enclave Microcode Flow, Flexible Seals & Reports, and a foundation that outsources the implementation of some new business models.
セキュアエンクレーブアーキテクチャのある態様では、マイクロコード化された命令内の実装にあまり適していない複雑、且つ時間のかかるフローが必要となる場合がある。これに対する解決法は、セキュアエンクレーブアーキテクチャのこれらの部分をマイクロコードに外部委託することである。多くの場合、任されたコードは、繊細なプロセッサまたはプラットフォームデータへの特別なアクセスを要求する。例えばEPID信号は、単一の命令には長すぎる。この代わりに、クオーティング・エンクレーブを利用して、EPID秘密鍵への特別なアクセスを許可することにより、EPID署名されたクオートを生成する。エンクレーブ認証により、Intelは、クオーティング・エンクレーブのみによって、EPIDキーに対するアクセス等の特別なエンクレーブに許可された追加機能を特定することができる。Intelが提供するエンクレーブは、追加機能を有し、コアのエンクレーブ機能を実装するが、アーキテクチャエンクレーブと称される。 Some aspects of the secure enclave architecture may require complex and time consuming flows that are not well suited for implementation within microcoded instructions. The solution to this is to outsource these parts of the secure enclave architecture to microcode. Often, the entrusted code requires special access to sensitive processor or platform data. For example, the EPID signal is too long for a single instruction. Instead, a quartering enclave is used to generate an EPID-signed quote by allowing special access to the EPID private key. Enclave authentication allows Intel to identify additional features granted to a special enclave, such as access to an EPID key, only by quartering enclave. The enclave provided by Intel has additional functionality and implements the core enclave functionality, but is referred to as the architecture enclave.
エンクレーブ・シール・ストレージは、エンクレーブのある属性(例えば装填時間計測値)にデータを暗号化する機能をエンクレーブソフトウェアに提供する。エンクレーブ証明フレームワークによって、エンクレーブは、エンクレーブを計測した証拠を外部の実体に提供することができる。多くの状況において、エンクレーブの正確なソフトウェアハッシュよりも、データのシールまたはエンクレーブのソースに対する証明のほうが望ましい。 Enclave Seal Storage provides enclave software with the ability to encrypt data to certain attributes of the enclave (eg, load time measurements). The Enclave Proof Framework allows Enclave to provide evidence of measuring Enclave to external entities. In many situations, a seal of data or proof to the source of the enclave is preferable to the exact software hash of the enclave.
一実施形態では、認証されたエンクレーブにおける署名が確認されると、エンクレーブの署名に利用されたキーの公的な部分は、シール&証明メカニズムに利用可能となり、この結果、販売業者は、エンクレーブ計測値に基づく強固な保護と、エンクレーブのコードのソースに基づくこれよりも柔軟な保護との間で選択することができるようになる。 In one embodiment, once the signature in the authenticated enclave is confirmed, the public part of the key used to sign the enclave becomes available for the seal & certification mechanism, which allows the distributor to measure the enclave. You will be able to choose between strong value-based protection and more flexible protection based on the source of the enclave code.
エンクレーブ認証は2つの部分に分割される。各エンクレーブは、Intelにそのルートを辿る(rooted back to Intel)ことができる署名鎖(signature chain)を有するエンクレーブライセンスを伴っている。エンクレーブライセンスは、そのエンクレーブのソース/責任実体、エンクレーブが必要とする特別な機能、および、そのエンクレーブを実現する特別なビジネスモデル/取り決めを特定するために必要な追加情報を示す。ライセンスは、特別なエンクレーブに対するものであってよく、これは、このエンクレーブの計測値を示しており、または、キーについて示しており、これが後に必要に応じてエンクレーブに署名することができるようになる。 Enclave certification is divided into two parts. Each enclave comes with an enclave license that has a signature chain that allows Intel to follow its roots back to Intel. An enclave license indicates the source / responsible entity of the enclave, the special features required by the enclave, and the additional information needed to identify the special business model / arrangement that enables the enclave. The license may be for a special enclave, which indicates a measurement of this enclave, or a key, which will later be able to sign the enclave as needed. ..
例えばAが、Aのビデオプレーヤで利用するエンクレーブを製造するライセンスを購入する場合を考える。このために、Intelは、販売業者Aのビデオプレーヤのルートキーと、Intelが販売業者Aがビデオプレーヤエンクレーブでの利用を許可される機能とに関するライセンスを生成する。次に販売業者Aは、ビデオプレーヤのルートキーを利用して、リリースする各ビデオプレーヤ修正版についての個々のライセンスファイルに署名する。これにより、エンクレーブのライセンス鎖が、複数の中間ライセンスを含むことになる。 For example, consider the case where A purchases a license to manufacture an enclave for use in A's video player. To this end, Intel will generate licenses for the root key of Distributor A's video player and Intel for features that Distributor A is authorized to use in the video player enclave. Distributor A then uses the video player's root key to sign an individual license file for each modified version of the video player to be released. This will cause the Enclave license chain to include multiple intermediate licenses.
署名されたライセンス鎖は、エンクレーブ起動プロセス中の評価には理想的とはいえないので、代わりに、これらを、許可証(permit)と称される単一の命令の実行しやすい構造(single instruction digestible structure)に組み込む。許可証は、CMACアルゴリズムを利用して対称認証され、エンクレーブの初期化(EINIT)中に解釈される。
ラインセンスの部分の殆どが許可証にコピーされ、同様の構造を成す。ライセンスIDは、ビジネス上の取り決めを特定するための64ビットの数値である。ライセンスの種類は、ライセンスを適用するプラットフォームを特定する。バルクライセンスにより、このエンクレーブを、セキュアなエンクレーブをサポートしているプラットフォーム上に立ち上げることができる。プラットフォームごとのライセンスにより、プラットフォームは先ず示されているライセンス認可機関に接触をとり、エンクレーブを立ち上げる許可を要求する。ひとたび許可されると、ライセンス認可機関とは接触をとる必要はなくなるが、これにより、ライセンス認可機関は、このエンクレーブが配置されたプラットフォームの数を課金目的で追跡することができる。このエンクレーブをライセンスしたISVは、エンクレーブのこのバージョンのセキュリティバージョン番号を構築することもできる。こうすることで、このバージョンがシールするデータを、前のバージョンではなくて将来のバージョンについて利用可能とすることができる。フラグフィールドは、この許可証を適用するために設定されうるエンクレーブのためのフラグを示す。機能マスクは、このエンクレーブに許可されうる特別な機能のビットマスクである。親のキーハッシュとは、このエンクレーブのライセンスを署名して、キーを署名した公開鍵でハッシュした公開鍵のハッシュである。実体ハッシュとは、このライセンスを適用する実体の予期されるハッシュである。エンクレーブの場合には、これは、適切に構築されたエンクレーブのMR.EADDの値である。ライセンスキーにおいては、これは公開鍵のハッシュである。 Most of the licensed part is copied to the permit and has a similar structure. The license ID is a 64-bit number for identifying business arrangements. The license type identifies the platform to which the license applies. The bulk license allows you to launch this enclave on a platform that supports secure enclaves. With a per-platform license, the platform first contacts the indicated licensing authority and requests permission to launch Enclave. Once authorized, there is no need to contact the licensing authority, which allows the licensing authority to track the number of platforms on which this enclave is located for billing purposes. ISVs licensed for this enclave may also build a security version number for this version of the enclave. This makes the data sealed by this version available for future versions rather than previous versions. The flag field indicates a flag for the enclave that can be set to apply this permit. The functional mask is a bitmask of special functionality that may be allowed for this enclave. The parent key hash is the hash of the public key that signed the license for this enclave and hashed it with the public key that signed the key. The entity hash is the expected hash of the entity to which this license applies. In the case of an enclave, this is a properly constructed enclave MR. It is a value of EADD. For license keys, this is a hash of the public key.
ライセンスにおいては、ライセンスを署名するのに利用される公開鍵を、ライセンス自身に含める。許可証はCPUキーを利用してMACされる。正規のcpuMACは、EMKPERMIT命令がこの許可証を、ライセンス鎖が今度はIntelに対して認証されたことを示す。ライセンスの種類がバルクではない場合には、ライセンスMACが、アーキテクチャライセンスエンクレーブが適切なライセンス認可機関に連絡して、このプラットフォームがエンクレーブを立ち上げうるという確認を受けたことを示す。 In the license, the public key used to sign the license is included in the license itself. The permit is MACd using the CPU key. Legitimate cpuMAC indicates that the EMKPERMIT instruction has authenticated this permit and the license chain has now been authenticated against Intel. If the license type is not bulk, the license MAC indicates that the architecture license enclave has contacted the appropriate licensing authority to confirm that the platform can launch the enclave.
全てのエンクレーブが許可証を要求するわけではない。エンクレーブの開発をし易くするために、開発中およびソフトウェアのライフサイクルのデバッグ段階に許可証をオプションとする。以下のポリシーがEINITにより実施される。非デバッグエンクレーブは常に許可証を立ち上げることを要求する。デバッグエンクレーブは、許可証なしに立ち上げられる。しかし、EINITに許可証が提示されない場合には、MR.Policy、ISV Secバージョン、許可証の見るバージョン(Permit See Version)、および機能の全てを0に設定する。 Not all enclaves require a permit. Permits are optional during development and during the debugging phase of the software life cycle to facilitate enclave development. The following policies will be implemented by EIINT. Non-debug enclaves always require a permit to be launched. The debug enclave is launched without a permit. However, if the permit is not presented to EINIT, MR. Set all of the Policy, ISV Sec version, Permit See Version, and features to 0.
許可証がデバッグエンクレーブの立ち上げに利用される場合には、permit−>フラグ「デバッグ」を設定することができ、デバッグエンクレーブが許可する機能のみを許可証に設定することができる。 When the permit is used to launch the debug enclave, permit-> flag "debug" can be set, and only the functions permitted by the debug enclave can be set in the permit.
図16は、本発明の一実施形態のエンクレーブを立ち上げる許可証を生成するプロセスの一例を示す。このプロセスは、3つの段階(許可証発行1600、さらなるライセンス承認1640、および初期化エンクレーブ1680)を有することができる。許可証発行1600段階では、ISVキー許可証1615を、EMKPERMIT命令1612をISVキーライセンス1610に実行することにより生成することができる。CPUのみ用のMACを有するエンクレーブ許可証1625は、EKPERMIT命令1612を、エンクレーブライセンス1620およびISVキー許可証1615に行うことにより生成することができる。さらなるライセンス承認1640段階では、CPUのみ用のMACを有するエンクレーブ許可証1625、および、ライセンスされる情報に対応する第三者エンクレーブ1642が、ライセンスエンクレーブ1644に入り、ライセンスエンクレーブ1644が、CPU用のMACおよびライセンスを有するエンクレーブ許可証1645を生成する。初期化エンクレーブ1680段階では、エンクレーブSECS1682、および、CPU用のMACおよびライセンスを有するエンクレーブ許可証1645が、EINIT1684命令に対する入力とされてよい。EINIT1684mリtリの出力は、ISVエンクレーブ1685となる。
FIG. 16 shows an example of a process of generating a permit to launch an enclave according to an embodiment of the present invention. This process can have three stages:
エンクレーブを起動するには、ソフトウェアとともに出荷されるライセンスから許可証を生成して、CPUに提供して、エンクレーブを開始させることができる。このプロセスは、許可証発行、さらなるライセンス承認、および、エンクレーブ初期化という3つの段階に分割することができる。図16は、このプロセスのフローを示す。 To activate the enclave, a permit can be generated from the license shipped with the software and provided to the CPU to initiate the enclave. This process can be divided into three stages: permit issuance, further license approval, and enclave initialization. FIG. 16 shows the flow of this process.
EMKPERMITという新たな命令を利用して、ライセンスから許可証を生成する。EMKPERMITは、単一のライセンスから単一の許可証を生成するが、連続呼び出しされることで、ライセンスの鎖を、許可書キーを利用してMACを有する単一の許可証に変換することもできる。次のセクションでは、このことを詳述する。 A new instruction called EMKPERMIT is used to generate a permit from a license. EMKPERMIT generates a single permit from a single license, but can also be called consecutively to convert a chain of licenses into a single permit with a MAC using a permit key. it can. The next section details this.
各ライセンスは、許可証を利用可能とするためにとることができるさらなるステップを決定する「ライセンスの種類」を含む。プラットフォームごとのライセンスは、クラウドのライセンス認可機関に、エンクレーブが配置されるプラットフォームの課金額を維持するよう要求する。この種類のライセンスにおいては、さらなる段階が必要となる。つまり、ライセンスエンクレーブと称されるアーキテクチャエンクレーブは、クラウドのライセンス認可機関と交渉して、承認されると、ライセンスキーを用いて許可証にさらなるMACを提供する。例えばアーキテクチャエンクレーブは常にバルクライセンスであり、これは、実行するためにライセンスキーMACが不要であることを意味する。これらは、セキュアなエンクレーブをサポートする任意のプラットフォーム上で動作する。 Each license includes a "license type" that determines the further steps that can be taken to make the permit available. Per-platform licensing requires the cloud licensing authority to maintain the billing amount for the platform on which the enclave is located. Further steps are required for this type of license. That is, an architecture enclave, called a license enclave, negotiates with the cloud licensing authority and, when approved, uses the license key to provide additional MAC to the permit. Architecture enclaves, for example, are always bulk licenses, which means that no license key MAC is required to run them. They run on any platform that supports secure enclave.
エンクレーブの初期化において許可証が実施形態される。初期化中に許可証が処理され、エンクレーブ計測値が許可証内のものと合致した場合には、MACは正しいことになり、エンクレーブが起動される。EINITはライセンスの種類を見て、さらなる承認を要するライセンスのライセンスMACのみを調査する。 A permit is implemented in the initialization of the enclave. If the permit is processed during initialization and the enclave measurements match those in the permit, the MAC is correct and the enclave is activated. EINIT looks at license types and only looks at licensed MACs for licenses that require further approval.
EMKPERMITは、ライセンス上のRSA署名を検証するのに必要となる時間のために、特権付き命令である。この命令は、検証して、その内容から許可証を生成する非常に単純な署名付き証明書をとる。ライセンスは、署名およびそれを署名するのに利用するキーの公開部分の両方を含む。これにより、uCodeは、Intelのライセンス署名キーのハッシュのみを格納して、Intelが署名したライセンスを認証することができる。EMKPERMITは、さらに、キーの認証された承認を提供することにより、ISVキーが署名したライセンスを認証することができる。これは、ISVの公開鍵のハッシュを含む許可証を作成することによって行われる。この結果、EMKPERMITがIntelのライセンスを、内部ハッシュ、あるいは、第2の許可証に提供されているハッシュを持つISVキーを利用して、Intelのライセンスを検証することができる。 EMKPERMIT is a privileged instruction for the time required to verify the RSA signature on the license. This instruction takes a very simple signed certificate that validates and generates a permit from its contents. The license includes both the signature and the public part of the key used to sign it. This allows uCode to store only the hash of the Intel license signing key and authenticate the Intel-signed license. EMKPERMIT can also authenticate the license signed by the ISV key by providing an authenticated authorization of the key. This is done by creating a permit containing a hash of the ISV's public key. As a result, EMKPERMIT can verify Intel's license using an internal hash or an ISV key with the hash provided in the second permit.
EMKPERMITは、ライセンスへのポインタ、キー許可証へのオプションのポインタ、および、出力許可証へのポインタという3つのパラメータをとる。Intelが署名したライセンスについては、キー許可証が空値であり、内部的にハードコードされた許可証パラメータのセットが利用される。アーキテクチャエンクレーブのライセンスを認証する呼び出し方法を利用して、その許可証を生成する。EMKPERMITは、このライセンスの公開鍵がuCodeにより認可されるようにする(含まれている公開鍵のハッシュを内部ハッシュと比較することにより)。 EMKPERMIT takes three parameters: a pointer to a license, an optional pointer to a key permit, and a pointer to an output permit. For licenses signed by Intel, the key permit is empty and an internally hard-coded set of permit parameters is used. Generate the permit using a calling method that authenticates the architecture enclave license. EMKPERMIT ensures that the public key of this license is authorized by uCode (by comparing the hash of the included public key with the internal hash).
ISVの場合には、ISVのキーは、Intelが署名したライセンスを有する。キー許可証を利用しないEMKPERMITの呼び出しには、Intelのキーハッシュを利用して、ライセンス上の署名を検証して、ISVキーのハッシュを認可する許可証を生成して、合法なライセンス署名キーを表す。そしてEMKPERMITを再度呼び出す(ISVのキーの許可証を含む)。EMKPERMITは、キーの許可証のMACを認証して、前にIntelのハッシュを利用したISVキーのハッシュを利用する。エンクレーブライセンスの公開鍵がISVキーの値にハッシュを行い、且つ、エンクレーブライセンスがそれにより適切な署名を行う、ということを仮定して、EMKPERMITは、エンクレーブ用の許可証を生成する。この許可証は、ライセンス情報(全鎖で一貫していてよい)、ライセンス鎖の全ての公開鍵のハッシュ、エンクレーブの計測値、およびその機能を示している。 In the case of ISVs, the ISV key has a license signed by Intel. For calls to EMKPERMIT that do not use a key permit, use Intel's key hash to verify the license signature, generate a permit to authorize the ISV key hash, and use a legal license signing key. Represent. Then call EMKPERMIT again (including the ISV key permit). EMKPERMIT authenticates the MAC of the key permit and uses the hash of the ISV key, which previously used the hash of Intel. EMKPERMIT generates a permit for enclave, assuming that the public key of the enclave license hashes the value of the ISV key and the enclave license thereby signs appropriately. This permit shows license information (which may be consistent across all chains), hashes of all public keys in the license chain, enclave measurements, and their capabilities.
以下のステップがu−codeによりEMKPERMIT中にとられる。
ライセンスエンクレーブは、uCodeが見える範囲の外で起動されるエンクレーブについての決定をするように設計される。例えばuCodeは、ISVのIntelとのビジネスにおける取り決めにより、さらなるエンクレーブ配置が許可されるかを評価する。ライセンスエンクレーブは、アセスメントを行う必要がある全ての材料の収集、および、エンクレーブの起動のさらなる承認、拒絶を行うように設計されている。ライセンスエンクレーブは、複雑なビジネスにおける取り決めのみをサポートする必要があり、バルクライセンス(例えば、必要とされている回数だけ任意のプラットフォームでエンクレーブを起動させる機能)には必要がない。 The license enclave is designed to make decisions about enclaves that are launched outside the visible range of the uCode. For example, uCode evaluates whether further enclave placements are allowed by ISV business arrangements with Intel. The License Enclave is designed to collect all materials that need to be assessed and to further approve or reject the activation of the Enclave. License enclaves only need to support complex business arrangements, not bulk licenses (eg, the ability to launch enclaves on any platform as many times as needed).
ライセンスエンクレーブは、システムサービスであることが予期されている。ライセンスが、ライセンスエンクレーブからのさらなる承認が必要であると示す場合、EMKPERMITが生成したライセンス鎖およびエンクレーブ許可証をライセンスエンクレーブに渡す。ライセンスエンクレーブは次に、承認要求を生成する。そしてアプリケーションはこの承認要求を適切なライセンス認可機関に送り、ここで承認通知が生成される。そしてライセンスエンクレーブに戻されて、ライセンスエンクレーブは、ライセンスキーを利用して、ライセンスMACフィールド内の許可証をMACする。 License Enclave is expected to be a system service. If the license indicates that further approval from the license enclave is required, the license chain and enclave permit generated by EMKPERMIT are passed to the license enclave. The license enclave then generates an approval request. The application then sends this authorization request to the appropriate licensing authority, where an authorization notice is generated. Then returned to the license enclave, the license enclave uses the license key to MAC the permit in the license MAC field.
エンクレーブに対して許可証が発行されると、エンクレーブ機動プロセスでu−codeを利用して評価して実施することができる。これは、許可証のリニアアドレスをパラメータとして利用して、EINIT命令の一部として実施される。(1)スクラッチパッドの許可証をコピーする、(2)許可証上のcpuMACを、許可証キーを利用して検証する、(3)ライセンスタイプ!=バルクである場合には、ライセンスMACを、ライセンスキーを利用して検証する、(4)許可証内の計測値を、SECS内のMR.EADDと比較する、(5)許可証内のフラグを、SECS内のフラグと比較する、(6)許可証内のPubkeyハッシュをMR.Policyにコピーする、(7)ISV SVNをSECSにコピーする、(8)許可証内の機能マップをSECSにコピーする、という、さらなるステップをEINITに、認証されたエンクレーブメカニズムの一環として追加する。 Once a permit is issued to the enclave, it can be evaluated and implemented using u-code in the enclave maneuvering process. This is done as part of the EIINT instruction, using the linear address of the permit as a parameter. (1) Copy the scratchpad permit, (2) Verify the cpuMAC on the permit using the permit key, (3) License type! = In the case of bulk, the license MAC is verified using the license key. (4) The measured value in the permit is measured by MR. Compare with EADD, (5) compare the flag in the permit with the flag in SECS, (6) compare the Pubkey hash in the permit with MR. Additional steps are added to EINIT, such as copying to Policy, (7) copying ISV SVN to SECS, and (8) copying the functional map in the permit to SECS, as part of the authenticated enclave mechanism.
<機能>
現在の機能マップは、このエンクレーブに利用可能な128ビットマスクの機能である。
The current feature map is the 128-bit mask feature available for this enclave.
空間は、EINITがとるアクションに基づいて組織化される。ビット00−03は、リングレベルの制約がこのエンクレーブ上でアクティブになったときの将来の利用のためにリザーブされる。04−07は、将来許可されるページ保護を示すためにリザーブされている。08−23は、EGETKEYを通じて利用可能なプロセッサキーである。24−31は、他の制御(例えば証明のために名称ベースのモードを利用する、または、将来制限を希望する技術に対するもの等)のためである。一部の機能は、デバッグモードでエンクレーブによって利用されない。デバッグ列は、ある機能をデバッグモードにおいて利用して合法かを示す。 Spaces are organized based on the actions taken by EINIT. Bits 00-03 are reserved for future use when ring-level constraints are activated on this enclave. 04-07 is reserved to indicate future permitted page protection. 08-23 is a processor key available through EGETKEY. 24-31 is for other controls (eg, utilizing name-based modes for proof, or for technologies for which future restrictions are desired). Some features are not utilized by Enclave in debug mode. The debug column indicates whether a feature is legal to use in debug mode.
将来の世代においては、ビット00は、リングレベルおよびVTの制約が、このエンクレーブに適用されることを示していてよい。ビット01−02は、エンクレーブが実行を許可されるリングレベルを示しており、ビット02は、エンクレーブがVTルートモードで実行されるか示している。各EENTERにおいて、現在のCPLをビット01−02に比較して、このエンクレーブがこのリングレベルにおいて実行を許可されているかを判断する。これを実行する試みが誤ったリングで行われる場合、EENTERは失敗する。同様に、リング制約がアクティブな場合は、エンクレーブは、ビット03が起動中にはVTルートモードからしか入ることができない。第一世代では、これらビットがMBZである。 In future generations, bit 00 may indicate that ring level and VT constraints apply to this enclave. Bits 01-02 indicate the ring level at which the enclave is allowed to execute, and bit 02 indicates whether the enclave is executed in VT root mode. At each EENTER, the current CPL is compared to bits 01-02 to determine if this enclave is allowed to run at this ring level. If an attempt to do this is made in the wrong ring, EENTER will fail. Similarly, if the ring constraint is active, the enclave can only be entered from VT root mode while bit 03 is up. In the first generation, these bits are MBZ.
エンクレーブページは、暗号化されても、整合性のみを保護されてもよい。さらに、ページは実行可能であってもなくてもよい。将来の世代においては、これらの属性を追跡して、EPCMのセキュリティ情報の部分で実施することができる。ページが実施可能であるか、またはエンクレーブが既にEINITされているかに基づいて、エンクレーブのエンクレーブページへの暗号化の利用を制御するために機能ビットがリザーブされる。 Enclave pages may be encrypted or only integrity protected. In addition, the page may or may not be executable. In future generations, these attributes can be tracked and implemented in the security information portion of the EPC M. Function bits are reserved to control the use of encryption for the enclave's enclave page, based on whether the page is feasible or the enclave has already been EINITed.
多くのアーキテクチャエンクレーブは、CPU内で、またはCPUにより保護されているキーへのアクセスを要求するリング3の実体である。EGETKEYはこれらキーに対するアクセスを提供し、機能ビットは、キーへのアクセスを許可することができるか決定するためにEGETKEYにより利用される。
Many architectural enclaves are entities of the
以下は、これら特性および短い説明を有する現在のアーキテクチャエンクレーブのリストである。 The following is a list of current architectural enclaves with these characteristics and a brief description.
プロビジョンエンクレーブは、KEY_PROVISION機能を有し、Intelにより承認されており、新たなデバイス証明キー(DAK)またはプロビジョン証明キー(PAK)が必要になるたびに、単一のパッケージプラットフォーム上で実行される。その目的は、エンクレーブに、EGETKEYが提供するプロビジョンシードに基づいて、デバイスID&プロビジョンキーを導出させる、というものである。次いでプロビジョンエンクレーブは、これらキーを利用して、プロビジョンサーバに対してプラットフォームの正当性を証明して、デバイス証明キー(DAK)を取得する。DAKを取得した後で、プロビジョンエンクレーブは、オプションとしてDAKを利用して、プラットフォーム証明キー(PAK)プロバイダとの間で認証を行い、PAKを再試行する。PAKの利用により、特定のISVについて保証することで、ユーザによりよいプライバシーを提供することができ、そのアクティビティがそのプラットフォームの前の所有者のものに関連付けられなくなる。PAKを取得してから、プロビジョンエンクレーブは、クオーティング・エンクレーブが取得することができるように、それをシールする。 Provision Enclave has KEY_PROVISION functionality, is Intel approved, and runs on a single package platform each time a new device certification key (DAK) or provision certification key (PAK) is required. To. The purpose is to have the enclave derive the device ID & provision key based on the provision seed provided by EGETKEY. The Provision Enclave then uses these keys to prove the platform's legitimacy to the Provision Server and obtain a Device Certification Key (DAK). After obtaining the DAK, Provision Enclave will optionally use the DAK to authenticate with the Platform Proof Key (PAK) provider and retry the PAK. The use of PAK can provide better privacy to the user by guaranteeing for a particular ISV and the activity will no longer be associated with that of the previous owner of the platform. After obtaining the PAK, the Provision Enclave seals it so that the Quartering Enclave can obtain it.
クオーティング・エンクレーブは、機能KEY_REPORTを有し、エンクレーブにより承認されており、EPIDキーをプロビジョンするのに利用されたプロビジョンエンクレーブ(通常はIntel)と同じ著者を有する。その位置は、全てのappsに対して利用可能であるOSサービスである。その目的は、エンクレーブにプラットフォームEPIDキーのシールを解かせることである。EREPORTからのレポートは入力として提供される。エンクレーブは、EGETKEYを利用して、レポートキーを取得する。レポートキーは、次に、レポートを検証するのに利用される。エンクレーブは、EPIDの利用によりクオートに署名する。 The quartering enclave has the function KEY_REPORT, is approved by the enclave, and has the same author as the provision enclave (usually Intel) used to provision the EPID key. The location is an OS service that is available for all applications. Its purpose is to have the enclave unseal the platform EPID key. The report from EREPORT is provided as input. Enclave uses EGETKEY to obtain a report key. The report key is then used to validate the report. Enclave signs quotes by using EPID.
ライセンスエンクレーブは、KEY_LICENSE機能を有し、Intelにより認可され、Root Intelにより署名されており、エンクレーブ(OSサービス)とともに出荷され、単独でインスタンス化されている。その目的は、複雑なライセンスポリシーを評価することである。エンクレーブがライセンスエンクレーブからさらなるライセンス確認を要求する場合には、EINITは、ライセンスエンクレーブがライセンスキーを利用してその許可証をCMACした後に限り、それを受け付けることができる。 The licensed enclave has the KEY_LICENSE function, is licensed by Intel, is signed by Intel, is shipped with the enclave (OS service), and is instantiated independently. Its purpose is to evaluate complex licensing policies. If the Enclave requests further license confirmation from the License Enclave, EINIT may only accept it after the License Enclave has used the license key to CMAC the permit.
単一のパッケージシステムにおいて、エンクレーブのアーキテクチャが利用する全ての対称キーを、プロセッサのヒューズアレイに格納された単一の特異性ソースから導出する。キー階層は、SE TCB階層に分割されて、これはプラットフォーム実装に依存しており、その構造が全てのセキュアなエンクレーブ実装にわたり一貫したSEキー階層である。TCB復帰用のキーイング材料およびEPIDプロビジョンの基礎は、SEキー階層のルートとして機能するSE TCB階層により提供される。エンクレーブ命令セットおよびトラステッドアーキテクチャエンクレーブ両方で利用される全てのキーイング材料は、SEキー階層により提供される。 In a single package system, all symmetric keys used by the Enclave architecture are derived from a single singularity source stored in the processor's fuse array. The key hierarchy is divided into SE TCB hierarchies, which are platform implementation dependent and whose structure is consistent across all secure enclave implementations. The keying material for TCB return and the basis of the EPID provision are provided by the SE TCB hierarchy, which serves as the root of the SE key hierarchy. All keying materials used in both the Enclave instruction set and the trusted architecture Enclave are provided by the SE key hierarchy.
プラットフォームは、ヒューズされている128ビットのプラットフォーム固有キーを提供する。これらキーは、秘密のCPU論理に格納されているキーを利用してヒューズで暗号化される。幾つかの単一の目的のキーはこのキーを利用して導出され、TCB復帰技術は、プラットフォームの要件に基づいて適用される。結果生じるキーは、SEキー階層のルートとして機能する。 The platform provides a 128-bit platform-specific key that is fused. These keys are encrypted with a fuse using the keys stored in the secret CPU logic. Several single-purpose keys are derived using this key, and TCB return technology is applied based on platform requirements. The resulting key serves as the root of the SE key hierarchy.
アーキテクチャエンクレーブのキーは、EGETKEY命令を利用して取得される。 The key of the architecture enclave is obtained using the EGETKEY instruction.
エンクレーブアーキテクチャは、REPORTの値の証明をプラットフォーム外のシステムに提供するために非対称キーの利用を必要とする。このキー(EPIDキー)は、最初はヒューズで提供されるが、配置後にキー階層から導出されるキーの1つを利用して再度プロビジョンされてよい。EPID証明キーのプロビジョン方法は、本明細書の範囲外である。さらなる情報は、デバイス証明キー(DAK)プロビジョン仕様を参照されたい。 The enclave architecture requires the use of asymmetric keys to provide proof of the value of REPORT to off-platform systems. This key (EPID key) is initially provided by the fuse, but may be reprovisioned using one of the keys derived from the key hierarchy after placement. EPID certification key provisioning methods are outside the scope of this specification. For more information, see Device Certification Key (DAK) Provision Specification.
最後に、エンクレーブのアーキテクチャも、全てのプロセッサの論理にあるキーを利用して、OEMにおけるキーイング材料をプロビジョンする。このキーはアウトオブボックス経験グローバルキー(Out-of-Box Experience Global Key)として知られている。我々は、このキーに同様の導出処理を行い、ISVの固有性を提供する。OOBキーから導出されたこれらキーのISVによる利用法は、本明細書の範囲外である。 Finally, Enclave's architecture also utilizes keys in the logic of all processors to provision keying materials in OEMs. This key is known as the Out-of-Box Experience Global Key. We perform a similar derivation process on this key to provide the ISV's uniqueness. ISV usage of these keys derived from OOB keys is outside the scope of this specification.
キー階層のSE TCBの部分はプラットフォーム特有であり、全ての基礎は、同じ基本のキーセットを必要とする。我々はこれらをベースキーと称す。これらは全てヒューズキーおよび論理キー内に導出され、SEキー階層のルートである。次いでこれらキーは、SE命令により、SEアーキテクチャで直接利用される全てのキーを導出するために利用される。これらキーはTCBキー階層の結果である。4つのSEベースキーに、プラットフォーム固有メカニズムによりSEアーキテクチャに利用可能となるEPIDコンポーネントが足し合わせられる。表12−1は、これらキーをそれぞれ示す。
図17は、単一のパッケージのセキュアなエンクレーブのためのプラットフォームキー階層の実装を示す本発明の一実施形態を示す。ボックスベースキー外1700は、利用可能な導出リソース1750から導出され1702、ボックスキー外1704が生成される。利用可能な導出リソース1750は、固有値1752、所有者エポック1754、セキュアなエンクレーブセキュリティバージョン1756、SECS計測値レジスタ1758、ISVセキュリティバージョン1760、およびSECSフラグ1762を含むエレメントを有するストリングである。プロビジョンキー1710は、Intelバックエンドに対してプラットフォームの正当性を証明することができる。EPID ID1712は署名キーである。初期safeIDキーブロブ1718は、クオートであり、safeIDシード1716に関連付けられている。ベースopsキー1714は、利用可能な導出リソース1750からの情報と組み合わせられて、エンクレーブキー1730、許可証キー1732、ライセンスキー1734、レポートキー1736、認証キー1738、およびシールキー1740を含む一連のキーを導出する1720ことができる。
FIG. 17 shows an embodiment of the invention showing an implementation of a platform key hierarchy for secure enclaving of a single package. The box-based key outside 1700 is derived from the available derived
図17aは、マルチパッケージキー階層の一実施形態を示す。 FIG. 17a shows an embodiment of the multi-package key hierarchy.
セキュアなエンクレーブ命令およびデータ構造は、キーイング材料のソースであるベースキーに依存している。表12−1に示すプラットフォームキー階層は、プラットフォームキー材料の階層関係、および、プラットフォームルートキーからのキーの導出方法の記述である。 Secure enclave instructions and data structures rely on the base key, which is the source of the keying material. The platform key hierarchy shown in Table 12-1 is a description of the hierarchical relationship of platform key materials and the method of deriving the key from the platform root key.
エンクレーブラップキー(enclave wrapping key)1752は、エンクレーブページキャッシュ(EPC)内で保護されていない間にセキュアなエンクレーブ制御構造(SECS)のページを暗号化するのに利用される対称キーである。 The enclave wrapping key 1752 is a symmetric key used to encrypt secure Enclave Control Structure (SECS) pages while they are not protected within the Enclave Page Cache (EPC).
許可証キー1754は、許可証に正当性および整合性を提供するのに利用され、これにはエンクレーブの機能およびライセンス情報が含まれる。許可証はMACされて、EINITへの遷移中にその整合性が確かめられる。このキーはEMKPERMIT uCodeおよびEINITにより利用される。
The
ライセンスキー1756は、uCodeにより評価不可能なライセンスポリシーに準拠してアサートするのに利用される(is used assert compliance with)。ライセンスキーは、EINITが評価するライセンスエンクレーブから認証された承認を生成するのに利用される。EINIT uCodeが利用するこのキーは、EGETKEYを介して利用可能であり、KEY_LICENSE機能セットとともにエンクレーブされる。
The
レポートキー1758は、レポートの正当性および整合性を提供するのに利用される。レポートは、ERREPORTによりMACされ、クオーティング・エンクレーブに遷移する間に、整合性を確かめられる。このキーはEREPORT uCodeにより利用され、QUOTE機能セットを有するエンクレーブに対してEGETKEYを介して利用可能となる。 The report key 1758 is used to provide the validity and integrity of the report. The report is MACd by ERREPORT and verified for integrity during the transition to the quartering enclave. This key is utilized by the EREPORT uCode and becomes available via EGETKEY for enclaves with the QUATE feature set.
認証キー1760は、エンクレーブ固有キーであり、クオーティング・エンクレーブからISVエンクレーブに送信されるデータの正当性および整合性を提供するのに利用され、エンクレーブからエンクレーブへの認証を同じプラットフォームで実現する。キーは、EGETKEYを介して全てのエンクレーブに利用可能となり、ISV_AUTH機能セットを有するエンクレーブが、必要としているキーを特定することができる。
The
シールキー1762は、128ビットを各エンクレーブに提供して、それらの含む繊細なデータを暗号化させる。複数のシールポリシーをこのシールキーに統合することで、ISVに、どのソフトウェアを使ってデータのシールを解くかについての柔軟性を持たせることができる。これらのキーは、EGETKEを介して任意のエンクレーブに利用可能となるが、個々にはシールキーは、要求されているシールポリシーに合致するエンクレーブにのみ利用可能となる。 The seal key 1762 provides 128 bits to each enclave to encrypt the sensitive data it contains. By integrating multiple seal policies into this seal key, ISVs can be given the flexibility of which software to use to unseal data. These keys will be available to any enclave via EGETKE, but individually seal keys will only be available to enclaves that meet the required seal policy.
EPID ID1712は、パッケージを一意に識別する。その唯一の目的は、デバイス証明キーのプロビジョンを可能とする、ということであり、デバイス証明キーは、EPIDベースの匿名証明キーである。EPID IDは、プロビジョンエンクレーブのみにアクセス可能である。プロビジョンエンクレーブは、これをセキュアなチャネルを介して、承認されたプロビジョンサーバのみに提供し、しかもこれは、ユーザまたはオペレーティングシステムが開始するプロビジョンプロセス中に限って行われる。このIDは、PROVISIONING機能を有するエンクレーブに対してEGETKEYを介して利用可能となる。 EPID ID 1712 uniquely identifies the package. Its sole purpose is to enable provisioning of device certification keys, which are EPID-based anonymous certification keys. EPID ID is accessible only to Provision Enclave. Provision Enclave provides this over a secure channel only to authorized provision servers, and this is done only during the provision process initiated by the user or operating system. This ID becomes available via EGETKEY to the enclave having the PROVISIONING function.
プロビジョンキー1710は、Intelバックエンドにプラットフォームの正当性を証明すること、および、現在のSE TCBの実行を認証することに利用される。プロビジョンキーへのアクセスを示すことで、プロビジョンサーバは、エンクレーブが実際はEPID IDを所有しており、少なくとも特定のTCBセキュリティバージョン上で実行されているデバイスであることを確かめることができる。プロビジョンキーは、このパッケージおよびこれを要求するプロビジョンエンクレーブの署名者に固有である。これにより、単一のプラットフォームで利用されている場合、これら複数のプロビジョンインフラストラクチャの間を分離させることができる。このキーはEGETKEYを介して、KEY_PROVISION機能を有するエンクレーブに利用可能である。
The
プロビジョンシールキーは、所有権に変更があった後であっても取得可能な方法でプロビジョンを暗号化することができるように、128ビットキーをプロビジョンエンクレーブに与える。このキーを利用して古いEPIDを暗号化することで、新たなEPIDの取得中にプラットフォームが無効になったことを証明することができる。プロビジョンキーはこのパッケージおよびこれを要求するプロビジョンエンクレーブの署名者に固有である。これにより、単一のプラットフォームで利用されている場合、これら複数のプロビジョンインフラストラクチャの間を分離させることができる。このキーはEGETKEYを介して、KEY_PROVISION機能を有するエンクレーブに利用可能である。 The provision seal key gives the provision enclave a 128-bit key so that the provision can be encrypted in a way that can be obtained even after a change in ownership. By using this key to encrypt the old EPID, it is possible to prove that the platform was disabled while acquiring the new EPID. The provision key is unique to the signer of this package and the provision enclave requesting it. This allows the separation between these multiple provision infrastructures when used on a single platform. This key is available via EGETKEY to enclaves with KEY_PROVISION functionality.
ISVアウトオブボックス(OOB)経験キー1700は、全てのIntelプラットフォームとISVとの間の共有キーである。このキーは、特定のISVに固有のOOBルートから導出される。ISVは、このキーに購入アクセスすることができ、このキーに対して秘密を暗号化して、OEMのハードディスク画像内に配置することができる。これらの秘密は、セキュアなエンクレーブ内で安全に実行されているこれらのコードのみがアクセス可能であり、プラットフォームはオンライン動作または完全な証明キープロビジョンを行う必要がない。これらキーはEGETKEYを介して、OOB機能を有するエンクレーブに利用可能である。
The ISV Out of Box (OOB)
プロビジョンキーは、セキュアなエンクレーブアーキテクチャに対して重要なキーであるが、プラットフォーム・キーイング材料からは導出されない。これらキーは、プロビジョンサーバまたはオフライン技術からプロビジョンされる。デバイス証明キー(DAK)は、個々のエンクレーブの特性を証明するための匿名署名キー(EPID)利用である。これは、キーまたは秘密のプロビジョン中にISVにより利用され、この繊細な情報を改ざんされていないアプリケーションの保護された導入にのみ送信するようにする。 Provision keys are important keys for secure enclave architectures, but are not derived from platform keying materials. These keys are provisioned from the provision server or offline technology. A device proof key (DAK) is the use of an anonymous signature key (EPID) to prove the characteristics of an individual enclave. It is utilized by ISVs during key or secret provisions to ensure that this sensitive information is only sent to the protected deployment of an untampered application.
デバイス証明キーには2つのソースがある。好適なアーキテクチャは、ヒューズで圧縮される初期DAKを、EPIDキーブロブおよびEPIDエントロピーとして出荷する。これにより、プラットフォームは、最初の電源投入直後に証明を開始することができるようになる。第2のソースは、DAKプロビジョンサーバに接触をとり、EPID IDおよびプロビジョンキーを利用してハードウェアの正当性を証明した後に1つがダウンロードされる。この2番目の方法は、ヒューザされたEPID キーを有さないプラットフォームおよび基礎となるTCBのバージョンを無効化した後のプラットフォームにより利用される。EPIDヒューズは、EGETKEYを介してPROVISIONING機能を有するエンクレーブにアクセス可能である。 There are two sources for device certification keys. A suitable architecture ships the fuse-compressed initial DAK as EPID key blobs and EPID entropy. This allows the platform to begin certification immediately after the first power up. The second source is downloaded after contacting the DAK provision server and using the EPID ID and provision key to justify the hardware. This second method is utilized by platforms that do not have a fused EPID key and after disabling the underlying TCB version. The EPID fuse can access the enclave with PROVISIONING function via EGETKEY.
プラットフォーム証明キー(PAK)は、オプションとしてさらなるプライバシーのレベルを提供する。DAKのある利用を関連付けることもできる。特にISVエンクレーブが名称ベースの証明機能を有する場合には、単一のISVが、所与のEPIDがこのサービスを再利用するか判断することができる。(しかし複数のISVの間で、ユーザの追跡のための結託は行われない)。DAKは、所有者にではなくて、むしろプラットフォームに結び付けられているので、この関連付けは、ウォータフォール・イベント中継続する。従って一部のユーザは、第三者にPAKを発行してもらって日々の証明に利用するより、も自身のDAKを利用して自分のプラットフォームの正当性を証明するほうを好む。マルチパッケージのプラットフォームでは、各パッケージのDAKは、PAK(証明におけるプラットフォーム全体を表す)を構築するのに利用される。 The Platform Certification Key (PAK) optionally offers an additional level of privacy. Some uses of DAK can also be associated. A single ISV can determine if a given EPID will reuse this service, especially if the ISV enclave has a name-based certification function. (But there is no collusion between multiple ISVs to track users). This association continues during the waterfall event, as the DAK is tied to the platform rather than to the owner. Therefore, some users prefer to use their DAK to prove the legitimacy of their platform rather than having a third party issue a PAK for daily proof. On multi-package platforms, the DAK of each package is used to build a PAK (representing the entire platform in the proof).
ユーザがアクセス可能なキーのキー導出は、NIST特殊公報800−108(擬似乱数関数を利用するキー導出について推奨されている)に準拠する。キー導出関数の構成においては、擬似乱数関数(PRF)が必要である。PRFは、NIST SP800−38Bに定義されているAES−CMACアルゴリズム、処理のブロック暗号モードについて推奨−認証のためのCMACモード、2005年5月(http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf)に基づく。一般的なキー導出は、DerivativeKey=PRFParentKey(DerivativeString)である。 The key derivation of a user-accessible key conforms to NIST Special Publication 800-108 (recommended for key derivation using a pseudo-random function). A pseudo-random number function (PRF) is required in the construction of the key derivation function. PRF recommends AES-CMAC algorithm defined in NIST SP800-38B, block cipher mode of processing-CMAC mode for authentication, May 2005 (http://csrc.nist.gov/publications/nistpubs) /800-108/sp800-108.pdf). A common key derivation is DerivativeKey = PRF ParentKey (DerivativeString).
導出ストリング(derivative string)は、要求されている特定のキーに基づく8つの要素からなるサブセットからなる。表12−2は、導出の一部となりうる利用可能なエレメントをそれぞれ説明している。
各キーは、予め定義された導出要素のセットを有しており、これは導出ストリングを含む。表12−3は、キー階層の各キーに含まれる要素を示している。各列はキーを表し、行は、そのキーに特定の要素が含まれているかを示す。デバッグストリングは、要求を発するエンクレーブのSECSが、デバッグモードにあることを示している場合に含められ、「要求」は、このエレメントが要求されておらず、キー導出のために要求において選択可能であることを示している。
セキュアなエンクレーブは、起動シーケンスの幾つかのポイントでソフトウェアのセキュリティ侵害を分離させ復帰させる技術をサポートしている。分離をサポートするために、エンクレーブに提供された全ての長期キーイング材料を、現在のTCBのセキュリティバージョンを利用して導出する。 Secure Enclave supports technology that isolates and recovers software breaches at several points in the boot sequence. To support the separation, all long-term keying materials provided to the enclave are derived utilizing the current security version of TCB.
このセクションでは、復帰可能なTCBが、uCode、MCHECK、およびマイクロコード(またはuVMM)からなるプラットフォームのアーキテクチャの一例について説明する。ハードウェア要件は、どのSEサポートプラットフォームについても同じであってよいが、具体的なキーフローは、特定のTCB要素に依存している。ここで利用されている技術に類似した技術を利用して他のプラットフォームをサポートすることもできる。 This section describes an example of a platform architecture where a recoverable TCB consists of uCode, MCHECK, and microcode (or uVMM). The hardware requirements may be the same for any SE support platform, but the specific key flow depends on the particular TCB element. Other platforms can also be supported using technologies similar to those used here.
CPUベースの保護技術をサポートするためには、ハードウェアに以下のキーが必要である。これらキーはTCBキー階層の基盤となる。
<ステッピング固有の256ビットの論理キー>
256ビットの論理キーは、128ビットのヒューズ・ラップキー、および、128ビットのアウトオブボックス経験キー(out-of-box experience key)という2つの部分に分割される。しかし、uCodeを追加する単一の128ビットのキーを両方について利用することもできる。
<ダイ固有の544ビットのヒューズキー>
これらには、32ビットのグループid、256ビットのSafeIdA.x値、および256ビットのプレシードが含まれる。A.x値および256ビットのプレシードは、上述した128ビットのヒューズ・ラップキーで暗号化される。
<一次レジスタ>
キー導出プロセスでは、キーを格納して、パッケージ上に置き、uCodeのみに利用可能とさせる必要がある。プラットフォームのランタイム中は2つの128ビットレジスタが必要である。CMAが起動して動作するまでの間は、EPIDキーのために、さらなる256ビットの空間が必要である。この後は、該さらなる256ビットはCPUには不要となる。
<TCB SVNレジスタ>
このレジスタは、各TCB層にSVNを保持するよう分割された64ビットのロック可能レジスタである。分割の仕方はプラットフォーム設計者の裁量に任されているが、8個の8ビットのSVNに分割する、というのが妥当に思われる。このレジスタの各部分は、独立してロック可能である。
To support CPU-based protection technology, the following keys are required in the hardware. These keys form the basis of the TCB key hierarchy.
<256-bit logical key unique to stepping>
The 256-bit logical key is divided into two parts: a 128-bit fuse wrap key and a 128-bit out-of-box experience key. However, a single 128-bit key that adds uCode can also be used for both.
<544-bit fuse key unique to the die>
These include a 32-bit group id, a 256-bit SafeIdA.x value, and a 256-bit preseed. The A.x value and the 256-bit preseed are encrypted with the 128-bit fuse wrap key described above.
<Primary register>
In the key derivation process, it is necessary to store the key, place it on the package, and make it available only to uCode. Two 128-bit registers are required during platform runtime. An additional 256-bit space is required for the EPID key until the CMA is up and running. After this, the additional 256 bits are no longer needed by the CPU.
<TCB SVN register>
This register is a 64-bit lockable register divided to hold an SVN in each TCB layer. The method of division is left to the discretion of the platform designer, but it seems reasonable to divide it into eight 8-bit SVNs. Each part of this register can be locked independently.
キーを特定のTCBバージョンのセットに結合することは、ヒューズキーから第1セットのキーを、開始される機動シーケンスの種類に基づいてuCodeに導出させることにより行われる。このヒューズをロックした後、起動シーケンスの各装填において鎖状に導出(a chain of derivations)が行われる。 Binding a key to a particular TCB version set is done by having uCode derive the first set of keys from the fuse key based on the type of maneuvering sequence initiated. After locking this fuse, a chain of derivations is performed at each loading in the activation sequence.
低レベルのコードを装填した後で、鎖は、エンクレーブで実行されているソフトウェアの、ISVが割り当てられたセキュリティバージョン(ISV assigned security version)を含み続ける。特定の構成においては、現在のバージョンから導出したキー、および、前の構成からのキーにアクセスすることができる。これにより、新たな安定性のあるバージョンへユーザデータを途切れなく遷移させることができる。 After loading low-level code, the chain continues to contain ISV-assigned security versions of the software running in the enclave. In certain configurations, you can access the keys derived from the current version and the keys from the previous configuration. This allows user data to transition seamlessly to a new, stable version.
ダイ固有のキーが生成されると、キー・ラップ・キーで暗号化される。これにより、ハードウェア監視ツールを利用してキーを抽出し、その部分に配置される前に通過するキーを保護することが益々難しくなる。 When a die-specific key is generated, it is encrypted with a key wrap key. This makes it increasingly difficult to use hardware monitoring tools to extract keys and protect the keys that pass before they are placed in that area.
これらキーを暗号化するのに利用される暗号アルゴリズムは、10ラウンドの128ビットのAES−ECB復号である。キー生成サーバは、AES−ECB暗号化を各キーに行い、ヒューズで焼かれる暗号文キーを生成する。 The cryptographic algorithm used to encrypt these keys is 10 rounds of 128-bit AES-ECB decryption. The key generation server performs AES-ECB encryption on each key and generates a fuse-burned ciphertext key.
TCBキー階層におけるキー導出に利用される擬似乱数機能(PRF)は、プラットフォームに特有である。AES−NIをサポートするプラットフォーム用には、128ビットのAES−ECBが推奨される。目的は、他のキーからキーを導出するための不可逆的な方法を提供する、というものである。このセクションでは、以下の関数のプロトタイプを利用する。
キー導出ではPRFに3つの方法がある。PRFループ導出は、異なるSVNのキー間の関係を構築しつつ、uCode SVNをキーに投入するのに利用される。具体的には、PRELoop(x-1)=PRFPRELoop(x)(const)である。 There are three methods for PRF in key derivation. PRF loop derivation is used to populate a key with a uCode SVN while building relationships between keys of different SVNs. Specifically, PRELoop (x-1) = PRF PRELoop (x) (const).
これにより、データを前方マイグレーションさせる。uCode SVN3を実行する場合を例にとる。エンクレーブはEGETKEYを利用して、このバージョンに基づくシールキーを取得して(PRELoop(3))、これを利用してデータをシールする。フィールドuCodeのアップグレードを配信し、次の起動uCode SVNは4である。アップグレードの後で、EGETKEY実装は、PRFLoop(4)にアクセス可能となる。エンクレーブが、EGETKEYにSVN3キーを送るよう要求する場合、PRELoop(3)=PRFPRELoop(4)(constant)を計算して、古いシールキーを取得することができる。 This causes the data to be migrated forward. Take the case of executing uCode SVN3 as an example. Enclave uses EGETKEY to obtain a seal key based on this version (PRELoop (3)) and use it to seal the data. Delivering a field uCode upgrade, the next launch uCode SVN is 4. After the upgrade, the EGETKEY implementation will have access to PRFLoop (4). If the enclave requires EGETKEY to send an SVN3 key, PRELoop (3) = PRF PRELoop (4) (constant) can be calculated to get the old seal key.
この特性を構築するには、PRFのループを利用するが、特性PRFPRELoop(x-1)がPRFPRELoop(x)から計算されるので、SVNの最大値を構築して、ここから減算していく必要がある。特定の最大値は、要求される性能に基づいて各プラットフォームの種類に対して構築する必要がある。最大値の初期値としては32を推奨する。PRFループ導出は、以下のようになる。
この方法は、uCodeのSVNをSVNキーに投入するために利用され、SEベースのキーの基礎となるキーである。ヒューズされるダイ固有キーは、288ビットのEPID値、および、256ビットのランダムキーを含む。全てのエフェメラルではない対称鍵は、これら256ビット(2個の128ビットキーからなる)から導出することができる。従って、単一のキーから複数のキーを導出するための技術の作成が可能である。こうするためには、ヒューズキーが復号されると、これを利用して異なる固定定数を利用してPRFを呼び出すことができる。鍵を分割すると、一般的には以下のような形になる。 This method is used to populate the UCode SVN into the SVN key and is the basis for SE-based keys. The die-specific key to be fused includes a 288-bit EPID value and a 256-bit random key. All non-ephemeral symmetric keys can be derived from these 256 bits (consisting of two 128-bit keys). Therefore, it is possible to create a technique for deriving a plurality of keys from a single key. To do this, once the fuse key has been decoded, it can be used to call the PRF with different fixed constants. When the key is split, it generally looks like this:
この技術は、EPID IDおよびプロビジョンIDの一部として利用される乱数を生成するのに利用される。 This technique is used to generate random numbers that are used as part of the EPID ID and Provision ID.
SVNキーがuCode SVNに基づいてループ導出されると、SE CMA等の、離れた保護メモリ内に格納することができる。マイクロコードは、SVNキーからキーを導出するためだけに、マイクロコードに曝されるMSRを利用する。MSRは、導出の基礎が、グローバルなアウトオブボックスのキーなのか、ヒューズキーなのか、および、各TCB層について要求されているSVNセットを示すキー選択器を利用する。これにより、要求が現在の値以下であることを確かめることができる。UCodeは、任意の必要なPREを利用して、古いSVNキー、PRF,および要求されているTCB SVNを取得することができる。
適切なSVNキーが利用可能になると、要求されているTCB SVNのCMACのキーとして利用される。マイクロコードは、これをCMACキーとして、Opsキー、またはプロビジョンベースキーの固定ストリングについてSEOpsシード(Intelが知らないヒューズキーの部分から導出した値)に対して利用する。つまり、se_base_key=CMAC(svn_base_key,se_ops_seed)である。 Once the appropriate SVN key is available, it will be used as the CMAC key for the requested TCB SVN. The microcode uses this as a CMAC key for the Ops key, or the SEOps seed (value derived from the fuse key part unknown to Intel) for the fixed string of the provision base key. That is, se_base_key = CMAC (svn_base_key, se_ops_seed).
図18は、本発明の一実施形態における、マイクロコードベースのセキュアなエンクレーブキー階層の一例を示す。リセットマイクロコード1800階層では、グローバル・ラップ論理キー1801およびインテルが知っている固有のルートヒューズ1802を、ラップ解除1806機能への入力として利用する。ラップ解除1806およびマイクロコードSVN1805の出力がPRFループ1808に入力される。マイクロコードSVN1805およびグローバルルート論理キー1803は別のPRFループ1809に入る。PRFループ1808の出力は、SVNキー1810レジスタに格納される。PRFループ1809の出力は、グローバルキーレジスタ1812に格納される。マイクロコードSVN1805は、TCB SVNレジスタ1814に格納される。グローバルラップ論理キー1801およびSE EPID A.xヒューズ1893は、ラップ解除1807関数に入力され、結果をSE EPID1816レジスタに格納する。MCheck1820階層においては、MCheckSVN1821およびTCB SVNレジスタ1814の出力が、TCB SVNレジスタ1826に格納される。SVNキーレジスタ1810は、マイクロコードSVNレジスタ1822に格納される。グローバルキーレジスタ1812は、グローバルキーレジスタ1824に格納される。SE EPID1816は、SE EPID1828に格納される。装填マイクロコード1830階層では、マイクロコードSVN1831およびTCB SVNレジスタ1826の出力を、TCB SVNレジスタ1846に格納する。マイクロコードSVNレジスタ1822は、マイクロコードSVNレジスタ1832に格納される。グローバルキーレジスタ1824は、グローバルキーレジスタ1834に格納される。SE EPID1828は、SE EPID1838に格納される。XuMSR導出キー1840階層では、マイクロコードSVN差異1841がPRFループ1842およびPRFループ1844に入る。マイクロコードSVN1832レジスタがデータをPRFループ1842に送り、グローバルキーレジスタ1834がデータをPRFループ1844に送る。PRFループ1842の出力およびTCB SVNレジスタ1836の出力が、PRFループ1846に入り、PRFループ1844の出力およびTCB SVNレジスタ1836の出力が、PRFループ1848に入る。PRFループ1846の出力は、SVNベースキー1850に格納され、PRFループ1848の出力はグローバルキー1852に格納される。マイクロコード1860階層では、Intelが知らない固有のルートヒューズ1894をシード1 1856に格納して、EPIDグループIDヒューズがEPIDグループ1858に格納される。シード1 1856は、PREループ1886およびPRE1888に入る。PREループ1888の出力は、SE EPIDシード1 1892である。PRFループ1886の出力はSE opsシード1890である。SE opsシード1890は、SVNベースキー1850から得られ、要求されたSVN1864は、CMAC1868関数に入り、SE opsキー1872を生成する。現在のSVN1862は、SVNベースキー1850から得られ、CMAC1866関数に入り、SEプロビジョンキー1870を生成する。SVNベースキーが{0、0、0}1874に等しい場合、SVNベースキー1850は、シード0 1876に格納される。シード0 1876は、PRFループ1878およびPRFループ1880に入る。PRFループ1878の出力は、SE EPID ID1882であり、PRFループ1880の出力は、SE EPIDシード0 1884である。
FIG. 18 shows an example of a microcode-based secure enclave key hierarchy in one embodiment of the present invention. The
全てのコアが同期して、ドアベルまたは類似したメカニズムを利用して、全てがMCHECKに入るようにする。全てのコアがMCHECKを実行中になると、(1)uCodeが、ヒューズの読み取り、復号、およびロックを行う、(2)uCodeがPRFループをSVNキーに、PRFループをOOBEキーに利用して、uCodeのSVNを両キーに投入する。uCodeは、そのSVNをTCB SVNレジスタに書き込み、その部分をロックする、(3)MCHECKローダまたは早期MCKECKコードが、MCHECKのSVNをTCB SVNレジスタに書き込み、ロックする、(4)マイクロコードパッチ・ローダが、マイクロコードパッチSVNをTCB SVNレジスタに書き込み、ロックする、という各ステップがBSPから行われる。APは、キーフローに参加しない。 All cores are synchronized and utilize a doorbell or similar mechanism to ensure that everything is in MCHECK. When all cores are running MCHECK, (1) uCode reads, decrypts, and locks the fuse, (2) uCode uses the PRF loop for the SVN key and the PRF loop for the OOBE key. Insert the uCode SVN into both keys. uCode writes its SVN to the TCB SVN register and locks its portion, (3) the MCHECK loader or early MCKECK code writes and locks the MCHECK SVN to the TCB SVN register, (4) the microcode patch loader. However, each step of writing the microcode patch SVN to the TCB SVN register and locking it is performed from the BSP. AP does not participate in the key flow.
マイクロコード初期化中、またはEGETKEYの呼び出し時に、マイクロコードは、要求を満たすのに必要となるSEベースキーを計算する。ベースキーは、さらに性能向上のために利用するために、CMA内にキャッシュされてよい。表12−4は、ベースキーの計算方法を示す。
プラットフォームのウォータフォールでユーザのプライバシーおよびデータを保護するために、256ビットのランダム所有者エポックをキー導出に含める。この値は、所有者変更中にランダムに作成される。エンクレーブキーを利用する前に、ソフトウェアは、所有者エポックをSE_EPOCH_MSRに書き込んでよい。これはBIOSがフラッシュに永久書き込みを行うことにより実行されてよい。一部のユーザ入力(ユーザ起動パスワードのハッシュ等)からこれを計算することもできる。または、エンクレーブの利用を許可する前に、セキュアなエンクレーブドライバにより提供されてもよい。 Include a 256-bit random owner epoch in the key derivation to protect user privacy and data in platform waterfall. This value is randomly created during the owner change. Prior to utilizing the enclave key, the software may write the owner epoch to SE_EPOCH_MSR. This may be done by the BIOS doing a permanent write to the flash. This can also be calculated from some user input (such as a hash of the user activation password). Alternatively, it may be provided by a secure enclave driver before permitting the use of the enclave.
この値の機密性は、プラットフォームにより暗号化されるデータが、ウォータフォールの後でラップトップの所有者により最初に認可されているエンクレーブでは復号できないことを保証する必要がある。この値のセキュリティ侵害は、エンクレーブデータのセキュリティ侵害につながらない。 The confidentiality of this value must ensure that the data encrypted by the platform cannot be decrypted by the enclave that was first authorized by the laptop owner after the waterfall. A security breach of this value does not lead to a security breach of enclave data.
SEキー情報構造は、メモリまたはパッケージの保護された領域に格納されている非永久構造である。CMAが最もよく利用される位置であるが、オンダイで保護されたストレージのいずれかを利用することも可能である。電源投入中には、SEキー情報を初期化することができる。キーIDは乱数値に設定され、キーカウントは0に設定される。エンクレーブキー、許可書キー、およびレポートキーが利用されるごとに、キーIDが読み出され(the KeyID read)、キーカウントを増分する。2^32個のキーが利用された後で、キーIDが新たな乱数の値に変更され、キーカウントが0にリセットされる。SEキー情報配置を5に示す。
電源が投入されると、プラットフォームキーテーブルをuCodeにより初期化する。BIOSその他のホストファームウェアは、現在の所有者エポックを、永久ストレージから、または、ユーザから取得して、これをLoadOwnerEpochMSRに書き込む。この時点ではエンクレーブキー階層が利用可能である。 When the power is turned on, the platform key table is initialized by uCode. The BIOS and other host firmware get the current owner epoch from permanent storage or from the user and write it to the LoadOwnerEpochMSR. At this point, the enclave key hierarchy is available.
エンクレーブのアーキテクチャの多くは、エンクレーブデータの認証および機密性を提供するためにキーが利用され、プロセッサの複雑性を最小限にとどめるために、アーキテクチャエンクレーブを利用して、高レベルの利用のためにこれらキーを処理する。例えば、クオーティング・エンクレーブは、REPORTキーを利用して、EREPORT命令により生成されたREPORT構造がプラットフォーム上に作成されたことを確認して、PERMITINGエンクレーブは、PERMITキーを利用して、エンクレーブが起動されたときにEINITが消費するエンクレーブPERMITを生成する。 Many of Enclave's architectures utilize keys to provide authentication and confidentiality of Enclave data, and utilize Architecture Enclave to minimize processor complexity for high-level use. Handle these keys. For example, the quartering enclave uses the REPORT key to confirm that the REPORT structure generated by the EREPORT instruction has been created on the platform, and the PERMITING enclave uses the PERMIT key to activate the enclave. Generates an enclave PERMIT that EINIT consumes when it is done.
加えて、任意のアプリケーションレベルのエンクレーブが、エンクレーブ外のプラットフォーム上の格納されている秘密をシールするためにキーにアクセスする必要があり、アプリケーションエンクレーブが再度確立されたとき(電力サイクル中であっても)シールは解除される。 In addition, any application-level enclave needs to access the key to seal a stored secret on a platform outside the enclave, and when the application enclave is reestablished (during a power cycle). Also) the seal is released.
こうするためのメカニズムはEGETKEY命令である。これは、現在のソフトウェア環境について秘密を構築するための単一のインタフェースである。
EGETKEYは現在、以下のキーにアクセスを提供している:(1)プロビジョンキーID(プロセッサについて一意に暗号化された(プロビジョンキーを利用して)データブロブを識別するために、アーキテクチャ・プロビジョン・エンクレーブが利用する)、(2)プロビジョンキー(プロセッサについて一意に暗号化されたデータブロブを復号するために、アーキテクチャ・プロビジョン・エンクレーブが利用する)、(3)プロビジョンシールキー(エンクレーブが、所有者が変わっても復号できるような形にEPIDを暗号化するために、アーキテクチャ・プロビジョン・エンクレーブが利用する)、(4)許可証キー(許可証を作成するためにアーキテクチャ許可証エンクレーブが利用する)、(5)レポートキー(レポート構造を検証するために、アーキテクチャ・クオーティング・エンクレーブが利用する)、(6)ISV認証キー(ISV AUTH KEY)(特定の対象アプリケーションエンクレーブのための認証データを作成するために、アーキテクチャ・クオーティング・エンクレーブが利用する)、(7)認証キー(AUTH KEY)(アーキテクチャ・クオーティング・エンクレーブが受け取ったデータを認証するために、アプリケーションエンクレーブが利用する)、(8)シールキー(エンクレーブ外に格納を希望するデータを暗号化するために、アプリケーションエンクレーブが利用する)、(9)OOB経験キー(アウトオブボックス経験利用のために(例えばBluRayプレーヤ)暗号化データを予めプロビジョンするために、ISVが利用する)。
The mechanism for doing this is the EGETKEY instruction. This is a single interface for building secrets about the current software environment.
EGETKEY currently provides access to the following keys: (1) Provision Key ID (architecture to identify data blobs that are uniquely encrypted (using the provision key) for the processor). (Used by Provision Enclave), (2) Provision Key (used by Architecture Provision Enclave to decrypt data blobs uniquely encrypted for the processor), (3) Provision Seal Key (Used by Architecture Provision Enclave to encrypt EPID in a way that Enclave can decrypt even if the owner changes), (4) License Key (Architecture to create a permit) License Enclave (used by Permission Enclave), (5) Report Key (used by Architecture Quarting Enclave to verify report structure), (6) ISV Authentic Key (ISV AUTOH KEY) (Specific Target Application Enclave) Used by Architecture Quarting Enclave to create authentication data for), (7) Authentic Key (AUTOKEY) (Application Enclave to authenticate data received by Architecture Quarting Enclave) (Used by), (8) Seal key (used by application enclave to encrypt data desired to be stored outside the enclave), (9) OOB experience key (for out-of-box experience use (eg) BluRay player) Used by ISV to pre-provision encrypted data).
これら値の殆どは、未加工でプロセッサに常駐はせず、実際には、単一のヒューズキーの値からEGETKEYの要求に応じて導出される。これらキーのそれぞれが単一のキーではなく、可能性のあるセットからの単一のキーにあるときに要求に応じて導出される。配信された特定のキーは、複数のパラメータに依存しており、そのうち一部がユーザ選択可能であり、その他がシステムまたは特定の状態に基づいている。 Most of these values are raw, non-processor resident, and are actually derived from the value of a single fuse key at the request of EGETKEY. Derived on demand when each of these keys is in a single key from a possible set rather than a single key. The particular key delivered depends on multiple parameters, some of which are user-selectable and others of which are based on the system or certain conditions.
キーを選択するために、キー要求構造をEGETKEY命令への入力として利用する。キーを選択することに加えて、ユーザは、キー要求構造を利用して、キー生成中に利用を希望する、制御下にあるこれら変数を、呼び出し者に特定させる。以下の図面は、キー要求構造を示す。
キー選択は、ユーザが必要とするキーを特定するのに利用され、キーポリシーは、キーを作成するのに利用されるさらなる値を確かめるのに利用される(それが、アーキテクチャエンクレーブの特定のセキュリティバージョンであろうと、アーキテクチャエンクレーブの特定のセキュリティバージョンであろうと、アプリケーションエンクレーブの特定のバージョンであろうと、現在のエンクレーブに関連付けられた計測値レジスタであろうと(EGETKEYがENCLAVE内から呼び出されるとき))。 Key selection is used to identify the key that the user needs, and key policy is used to ascertain the additional values used to create the key (that is, the specific security of the architecture enclave). Whether it is a version, a specific security version of the architecture enclave, a specific version of the application enclave, or a measurement register associated with the current enclave (when EGETKEY is called from within ENCLAVE). ..
さらなるランダムネスがキー導出に利用することもでき、これは特に、キーの消耗を防止するために必要であり、PERMITINGおよびQUOTINGアーキテクチャエンクレーブにより利用される。また、シールキー(SEALing key)を作成するときにもアプリケーションエンクレーブにより利用される。ゼロにセットされたフィールドは、ランダムネスを追加しないことを意味しており、そうでない場合にはフィールドは、256ビットの整列したデータの値を指し示すことになる。以下の表は、キー選択フィールドの構造を特定する。
キーポリシーは、ビットフィールドセレクタであり、特定の値(ユーザまたはシステム状態いずれからのものであっても)が、キー導出に利用されるかを判断するのに利用される。
<エンクレーブレジスタおよび制御>
2つのイネーブルレベルがエンクレーブに提供される。第1のイネーブルは、BIOSによるビットセットのoptである。これは一度の書き込み関数(write once function)である。次のリセットまでにエンクレーブ機能をイネーブルまたはディセーブルする。第2のイネーブルは、OSまたはVMMに提供されて、必要に応じてエンクレーブ機能をONまたはOFFに切り替える。 Two enable levels are provided to the enclave. The first enable is the opt of the bit set by the BIOS. This is a write once function. Enables or disables the enclave feature before the next reset. The second enable is provided to the OS or VMM to switch the enclave function on or off as needed.
図19は、本発明の一実施形態にみることができるエンクレーブCTL_MSRレジスタを示す。最下位ビットがイネーブル1900である。レジスタのビット1が1910でOnである。ビット2から63はリザーブされている。
FIG. 19 shows an enclave CTL_MSR register that can be seen in one embodiment of the present invention. The least significant bit is
エンクレーブ機能は、先ず、図19に示すエンクレーブCTL_MSRにイネーブルビットを設定することから始まる。このビットは、パッケージのリセットが行われるとディセーブルに初期設定される。このビットは、パッケージリセットの後に一度書き込むことができる。 The enclave function first begins by setting an enable bit in the enclave CTL_MSR shown in FIG. This bit is initially disabled when the package is reset. This bit can be written once after a package reset.
BIOSは、ビットをセットして、エンクレーブをイネーブルする。BIOSがビットをクリアすると、エンクレーブは、その部分がリセットされるまでイネーブルすることができない。 The BIOS sets the bit to enable the enclave. When the BIOS clears a bit, the enclave cannot be enabled until that part is reset.
ソフトウェアは、CPUID命令を実行することで、エンクレーブのサポートを検知することができる。CPUIDは、エンクレーブがサポートされているか否かを示す結果を戻す。 The software can detect enclave support by executing a CPUID instruction. CPUID returns a result indicating whether enclave is supported.
ビットのOptがクリアされると、CPUIDは、そのエンクレーブを実行しないことを報告する。 When the Bit Opt is cleared, the CPUID reports that it will not execute the enclave.
システムソフトウェアは、図19に示すエンクレーブCTL_MSRを利用してエンクレーブ機能を制御する。Onビットは、ソフトウェアに、エンクレーブ機能に対するアクセスを動的に制御させる。 The system software uses the enclave CTL_MSR shown in FIG. 19 to control the enclave function. The On-bit allows the software to dynamically control access to the enclave function.
ソフトウェアは、CPUID命令を実行することで、エンクレーブのサポートを検知することができる。エンクレーブCTL MSRにONビットがセットされている場合に、エンクレーブサポートが示される。 The software can detect enclave support by executing a CPUID instruction. Enclave support is indicated when the ON bit is set in the enclave CTL MSR.
TCSMSRレジスタは、TCSのアドレスを含む各プロセッサ上のレジスタであり、例外処理およびRDTCSPTRにより利用される。エンクレーブに入るときに装填される。レジスタは、EENTERを実行するときにTCSの値を装填され、ERDTCSPTRにより読み取られる。レジスタサイズは、プロセッサのモードに基づく。 The TCSMSR register is a register on each processor that contains the address of the TCS and is utilized by exception handling and RDTCSPTR. Loaded when entering the enclave. The register is loaded with the value of TCS when executing EENTER and is read by ERDTCSPTR. The register size is based on the processor mode.
各プロセッサ上にあるエンクレーブ・ベースアドレスレジスタは、実行中のエンクレーブの下位アドレスを含み、マイクロコードによりエンクレーブに入るときに装填される。レジスタサイズは、プロセッサのモードに基づく。このレジスタはソフトウェアからは見えず、一時的なマイクロコード(microcode temporary)である。 The enclave base address register on each processor contains the lower address of the enclave in progress and is loaded as it enters the enclave by microcode. The register size is based on the processor mode. This register is invisible to the software and is a microcode temporary.
レジスタは、現在のエンクレーブのアドレスの上限を保持し、エンクレーブに入るときに装填される。レジスタは、エンクレーブが実行を開始するときに、SECSに格納されている値を装填される。これは、一時的なマイクロコードレジスタである。レジスタサイズは、プロセッサのモードに基づく。 The register holds the current enclave address limit and is loaded when entering the enclave. The register is loaded with the value stored in the SECS when the enclave starts execution. This is a temporary microcode register. The register size is based on the processor mode.
エンクレーブページキャッシュ(EPC)最大サイズレジスタは、EPCの最大サイズを示す。このサイズは、4096バイトのページの数で与えられる。これは32ビットのレジスタである。このレジスタは、読み取り専用であり、現在の設計でEPCがサポートする最大サイズを示す。 The Enclave Page Cache (EPC) Maximum Size Register indicates the maximum size of the EPC. This size is given by the number of pages of 4096 bytes. This is a 32-bit register. This register is read-only and indicates the maximum size that the EPC supports in the current design.
EPCサイズレジスタEPC_SIZE MSRは、EPCの現在定義されているサイズを示す。レジスタを装填することで、EPCがそのサイズに定義される。この値は、4096ビットのページで与えられる。例えば、4096ビットのページ1枚が1である。レジスタの値は、EPC_MAX値を超えることはできない。値がEPC_MAX値を超えると、WRMSR命令によりGP不良がとられる。このレジスタに書き込むことで、書き込み前に、EPCの全てのデータが無効化される。ソフトウェアは、このレジスタを更新する前に(必要であれば)全てのEPCエントリをセーブしてよい。 The EPC size register EPC_SIZE MSR indicates the currently defined size of the EPC. Loading a register defines the EPC to that size. This value is given on a 4096-bit page. For example, one 4096-bit page is 1. The register value cannot exceed the EPC_MAX value. When the value exceeds the EPC_MAX value, a GP defect is taken by the WRMSR instruction. By writing to this register, all data of the EPC is invalidated before writing. The software may save all EPC entries (if necessary) before updating this register.
EPCベースレジスタは、EPCのベースの位置を示す。このレジスタに書き込むことで、書き込み前に、EPCの全てのデータが無効化される。ソフトウェアは、このレジスタを更新する前に(必要であれば)全てのEPCエントリをセーブしてよい。 The EPC base register indicates the position of the base of the EPC. By writing to this register, all data of the EPC is invalidated before writing. The software may save all EPC entries (if necessary) before updating this register.
概して、外部インタフェースは、エンクレーブのセキュリティを侵害しうる転送またはトランザクションを許可しない。セキュアなエンクレーブは、エンクレーブキーについてランダムな数を要求する。乱数生成器は、マイクロコードによりセキュアにアクセス可能である。パーツのコアに配置される必要はない。 In general, the external interface does not allow transfers or transactions that could compromise the security of the enclave. Secure enclave requires a random number of enclave keys. The random number generator is securely accessible by microcode. It does not have to be placed in the core of the part.
図26は、本発明の一実施形態における、デジタル乱数生成器のためのプロセッサパッケージを示す。プロセッサパッケージ2600は、コア0 2640、コア1 2670という複数のコアを含みうる。コア0 2640は、マイクロコード2642、マイクロコード2644、マイクロコード2646、RNGマイクロコードモジュール2650、およびRNGキュー2654を含んでよい。コア1 2670は、マイクロコード2672、マイクロコード2674、マイクロコード2676、RNGマイクロコードモジュール2680、およびRNGキュー2684を含んでよい。読み取りランダム命令2630は、マイクロコード2642と通信してよく、読み取りランダム命令2635は、マイクロコード2672と通信してよい。プロセッサパッケージ2600は、さらに、DRNG2602を含んでよく、DRNG2602は、STD2608、OPE2610、PSK2612、およびTSC2614をとる。DRNG2602は、デジタルエントロピーソース2604を取得することができ、これはオンラインの自己テスト2606に接続する。オンラインの自己テスト2606の出力は、組み合わせられた調節器/決定論ランダムビット生成器(DRBG)2620の1つの入力であってよい。
FIG. 26 shows a processor package for a digital random number generator in one embodiment of the present invention. The
エンクレーブは、作成時にデバッグエンクレーブとして設定されてよい。デバッグエンクレーブは、EDBGRDおよびEDBGWR命令を利用してエンクレーブの内容に外部アクセスすることができる。デバッグエンクレーブは、ECREATE内にデバッグエンクレーブを設定することによりセットアップされる。このビットはエンクレーブのECS内に格納される。 The enclave may be set as a debug enclave at creation time. The debug enclave can use the EDBGRD and EDBGWR instructions to externally access the contents of the enclave. The debug enclave is set up by setting the debug enclave in ECREATE. This bit is stored in the ECS of the enclave.
デバッグビットクレアで作成されるエンクレーブは、生成エンクレーブである。エンクレーブは、EPCは、エンクレーブがデバッグエンクレーブであると示すデバッグビットを含んでいる。エンクレーブは、メインメモリ内に、またはディスク上に、暗号化されたままで残っている。エンクレーブの内容を探す必要のあるデバッガは、メモリをEPCに装填する。EDBGRDおよびEDBGWR命令を利用して、EPCに常駐するエンクレーブメモリの位置にアクセスすることができる。デバッグエンクレーブは、実行するために許可証を必要とせず、有効な許可証なしに実行される。 The enclave created by the debug bit claire is a generated enclave. The enclave contains a debug bit indicating that the EPC is a debug enclave. The enclave remains encrypted, either in main memory or on disk. Debuggers that need to find the contents of the enclave load memory into the EPC. The EDBGRD and EDBGWR instructions can be used to access the location of the enclave memory resident in the EPC. The debug enclave does not require a permit to run and runs without a valid permit.
生成エンクレーブに入るときにデバッグ制御レジスタDR7は、TCSセーブ領域にセーブされる。DR7は図27に示されている。図27は、本発明の一実施形態では、デバッグレジスタDR7 2700である。レジスタDR7 2700は、L0 2702、L1 2706、L2 2710、L3 2714、G0 2704、G1 2708、G2 2712、およびG3 2716を含む。DR7 レジスタ2700の他のビットは、LE2718、GE2720、001 2722、GD2724、00 2726、R/W0 2728、LEN0 2730、R/W1 2732、LEN1 2734、R/W2 2736、LEN2 2738、R/W3 2740、およびLEN3 2742を含む。
The debug control register DR7 is saved in the TCS save area when entering the generation enclave. DR7 is shown in FIG. FIG. 27 is a debug register DR7 2700 in one embodiment of the present invention.
ビットL3−L0およびG3−G0は、0の値に設定されている。DR7は、エンクレーブの退出時に元の値に設定される。 Bits L3-L0 and G3-G0 are set to a value of 0. DR7 is set to the original value when leaving the enclave.
デバッグエンクレーブについては、デバッグレジスタの値を変更しない。RFLAGS.TFは、EENTER命令の開始時に設定され、以下の2つの場合を考慮に入れる必要がある。 For debug enclaves, do not change the debug register value. FLAGS. The TF is set at the start of the EENTER instruction and needs to take into account the following two cases:
1つの場合は、デバッガがレガシー(非SE認識)である、または、エンクレーブが生成(非デバッグ)モードにある場合である。 One is when the debugger is legacy (non-SE recognition) or the enclave is in generate (non-debug) mode.
SE認識デバッガは、デバッグモード・エンクレーブを対象としている。 The SE recognition debugger is intended for debug mode enclave.
第1の場合には、#DB例外が、次のEEXIT命令の対象において生じうる。これにより、エンクレーブが、大きく、不透明な処理(large, opaque operation)として取り扱われる。第2の場合には、ユーザは、エンクレーブによる単一のステップへの完全な自由度を利用することができる(complete freedom to single step through the enclave)。この行為は、エンクレーブ内の3つのデータフィールド、および、EENTER、EEXIT、および、EIRETにおけるRFLAGS.TFの特殊処理によりサポートされる。
TCSセーブ領域にレジスタ値をセーブする。レジスタは0に設定される。エンクレーブの終了時には、レジスタは、エントリ値に復元される。エンクレーブが、開始時にイネーブルされた分岐トレース(branch trace)を有する場合、EENTERがエンクレーブに入る前の最終エントリとなる。エンクレーブの終了時に、終了後の始めの位置が分岐トレースに書き込まれる。 The register value is saved in the TCS save area. The register is set to 0. At the end of the enclave, the register is restored to the entry value. If the enclave has a branch trace enabled at the start, it will be the last entry before EENTER enters the enclave. At the end of the enclave, the starting position after the end is written to the branch trace.
Int nおよびInt 3命令は、エンクレーブ内で実行されるときにGP不良として報告される。デバッガは、エンクレーブをデバッグするときにGP不良条件をフックすることができる。
The Int n and
本文書では、AESブロック暗号のためにCMACモード処理を実施する新規な技術を記載する。CMACは、メッセージの真偽をサポートするモードであり、メッセージAおよびキーKを入力として受け付けて、認証タグTを戻す。認証タグの導出は、CBC(暗号ブロック鎖)アルゴリズムを利用して行われる。CMACは、長さ拡張攻撃に対する保護メカニズムを含むために、CBCよりも複雑である。これらを「CMACの3つの特性」と称する。以下では、CBCおよびCMACを概略する。 This document describes a novel technique for performing CMAC mode processing for AES block ciphers. CMAC is a mode that supports the authenticity of a message, accepts a message A and a key K as inputs, and returns an authentication tag T. Derivation of the authentication tag is performed using a CBC (cryptographic block chain) algorithm. CMAC is more complex than CBC because it includes a protection mechanism against extended length attacks. These are referred to as "three characteristics of CMAC". The following outlines CBC and CMAC.
図20は、本発明の一実施形態で利用される暗号ブロック鎖アルゴリズムを示す。初期化ベクトル2000およびステージ1入力2010は、排他的論理和ゲート2012に入る。排他的論理和ゲート2012の出力は、ステージ1ブロック暗号2015に入る。ステージ1ブロック暗号出力2018は次に、ステージ2排他的論理和ゲート2022に、ステージ2入力2020とともに入る。排他的論理和ゲート2022の出力は、ステージ2ブロック暗号2025に入る。ステージ2ブロック暗号出力2028は、暗号ブロック鎖の次の段階に入る(不図示)。
FIG. 20 shows a cryptographic block chain algorithm used in one embodiment of the present invention. The
CBCアルゴリズムは、ブロック暗号を利用して、一部のデータの機密性を確保する、または、このデータの認証タグを計算する。CBCアルゴリズムの基本をなす構想は、前の暗号からの出力が、暗号化前に次の入力ブロックでXORされる、というものである。このようにして、入力データに存在しうるパターンを、暗号文から排除することができる。また、ブロック暗号のトランザクションの間のXOR処理の組み合わせにより、理想的には許されない(forgeable)メッセージ認証タグを導出するために混合が大幅に行われる(strong mixing)。 The CBC algorithm uses a block cipher to ensure the confidentiality of some data or to calculate the authentication tag for this data. The basic idea of the CBC algorithm is that the output from the previous cipher is XORed in the next input block before encryption. In this way, patterns that may exist in the input data can be excluded from the ciphertext. Also, the combination of XOR processing between block cipher transactions results in a large amount of mixing to derive an ideally forgeable message authentication tag.
CBCアルゴリズムは、図20と以下に示される。暗号は、AESの場合同様に、128ビットの暗号と想定する。
CMACの仕様は、CBCアルゴリズムを初期化および終了させるために3つのさらなるアルゴリズムを含む。これらは、CMACの「3つの特徴」と称される。1つ目の特徴は、対称鍵Kから2つのサブキー値K1およびK2を導出することに関する。サブキーK1およびK2は、中間値Lから導出される。CMACは、対称鍵の値Kを利用して、ゼロからなるストリング(つまり0128)に、対称鍵値Kを利用して対称鍵ブロック暗号変換を行うことでLが得られる、と示している。この関係を、式(1)L=CIPHERK(0128)で示す。 The CMAC specification includes three additional algorithms to initialize and terminate the CBC algorithm. These are referred to as the "three features" of CMAC. The first feature relates to deriving two subkey values K 1 and K 2 from the symmetric key K. The subkeys K 1 and K 2 are derived from the intermediate value L. CMAC shows that L can be obtained by performing a symmetric key block cipher conversion using the symmetric key value K to a string consisting of zeros (that is, 0 128 ) using the symmetric key value K. .. This relationship is expressed by the formula (1) L = CIPHER K (0 128 ).
Lが導出されると、Lの最上位ビットをチェックする。これがゼロであれば、K1を、左に1ビットシフトすることにより、Lから導出される。そうでない場合は、Lを左に1ビットシフトして、特殊な値RbでXORして、K1を生成する。Rbは、バイナリ形式の(012010000111)として定義される。K2も同じプロシージャでK1から生成される。サブキーK1、K2の導出は、以下の擬似符号に示されている。MSB()がある値の最上位ビットを示すこととする。
CMACの第2の特徴は、入力データにCBCアルゴリズムを利用する前に、パディングを行うことに関している。データの最後のブロックが完全なブロックではない場合にはそのブロックを、1に必要な数の0を付けたビットでパディングして、最終的なブロックが完全なものになるようにする。 The second feature of CMAC is to pad the input data before using the CBC algorithm. If the last block of data is not a complete block, pad it with the required number of 0 bits to make the final block complete.
CMACの第3の特徴は、長さ拡張攻撃を回避するために行われる最終ブロックに対する修正に関している。最終ブロックが完全に1ではない場合(パディング不要の場合)には、最終ブロックをサブキーK1でXORする。そうでない場合には、サブキーK2でXORする。CMACタグ生成および検証アルゴリズムを以下に示す。 A third feature of CMAC relates to modifications to the final block made to avoid length extension attacks. In the case the last block is not completely 1 (in the case of padding necessary), to XOR the last block with subkeys K 1. If not, XOR with subkey K 2 . The CMAC tag generation and verification algorithm is shown below.
以下では、対称鍵ブロック暗号がAESとして利用され、プロセッサがAESラウンド加速(AES round acceleration)の命令セットをサポートしている場合の、CBC()アルゴリズムの実装方法例を示す。Intelアーキテクチャは、ウェストミア(Westmere)プロセッサ(2009)およびそれ以降の時間フレームにおいて4つの新たな命令をサポートする。これら命令は、AESENC(AESラウンド暗号)、AESENCLAST(AES最終ラウンド暗号)、AESDEC(AESラウンド復号)、AESDECLAST(AES最終ラウンド復号)である。これら命令の仕様を以下に示す。
タグ検証プロセスがタグ生成と同じであることから、CMACモードを、AESラウンド命令を利用して実装するには、AESENC AESENCLASTのみの呼び出しで十分である。図21は、単一のAESブロックの暗号化と関連付けられたフローチャートである。図22は、CBCアルゴリズムを利用する多数のAESブロックの暗号化と関連付けられたフローチャートを示す。 Since the tag verification process is the same as tag generation, a call to AESENC AESENCEST alone is sufficient to implement CMAC mode using the AES round instruction. FIG. 21 is a flowchart associated with encryption of a single AES block. FIG. 22 shows a flowchart associated with encryption of a large number of AES blocks utilizing the CBC algorithm.
キースケジュール変換を実装するためには、逆混合列(inverse mix columns)用のAESIMC命令とAESKEYGENASSIST命令とを利用することができる。AESKEYGENASSISTは、暗号化に利用されるラウンドキーを生成するために利用される。AESIMCは、暗号ラウンドキーを、均等な逆暗号化モデルに従って復号に利用可能な形式に変換するために利用される。AESIMCおよびAESKEYGENASSIST命令は、http://softwarecommunity.intel.com/articles/eng/3788.htmに記載されている。 In order to implement the key schedule conversion, the AESIMC instruction and the AESKEYGENASSIST instruction for inverse mix columns can be used. AESKEYGENASSIST is used to generate a round key used for encryption. AESIMC is used to convert a cryptographic round key into a format that can be used for decryption according to an even inverse cryptographic model. The AESIMC and AESKEYGENASSIST instructions are described at http://softwarecommunity.intel.com/articles/eng/3788.htm.
CMACは、128ビットの量のビッグエンディアン記述を利用して示される。CMACをリトルエンディアン・マシンを利用して正確に実装するには、16バイト幅の反映処理をソースコード実装のある時点で行う必要がある。この処理は、PSHUFB命令(1クロック・レイテンシー、スループット)の利用により迅速に行うことができる。以下に、バイトシャッフルが必要な時点を記述する。 CMAC is shown using a 128-bit amount of big endian description. In order to implement CMAC accurately using a little endian machine, it is necessary to perform a 16-byte wide reflection process at some point in the source code implementation. This process can be performed quickly by using the PSHUFB instruction (1 clock latency, throughput). The time when bite shuffle is required is described below.
SUBKEYS()アルゴリズム実装バイト反映(byte reflection)は、AES暗号をゼロストリングに利用して導出された後であって、2つのサブキーが導出される前に、Lに対して行われる必要がある。バイト反映は、2つのサブキーに対して、Lから導出された後で必要である。SUBKEYS()実装は、以下のCで示される。
次に、最終ブロックが完全ではない場合に限って、最終ブロックに対するバイト反映をパディングの前後に行う必要がある。これらのステップは以下のCの実装例に示されている。
function_pshufb()が、128ビット幅のバイト反映を行う。 function_pshufb () reflects 128-bit wide bytes.
<SMIのSE要件>
エンクレーブは、SMM空間内での実行を許可されていない。エンクレーブをSMMモードで実行しようとすると、命令のGP不良が生じる。SMIがエンクレーブ内で実行している間に生じると、プロセッサは、レジスタ状態を、遠隔のエンクレーブ内にセーブして、終了する。終了すると、TBD MSRビットを、エンクレーブの実行中にSMIが生じたことを示すように設定する。SMMコードは、エンクレームデータにアクセスできない。EPC領域に接触しようと試みると、実際のモードではジャンクデータを戻し、保護されたモードではEPCページ不良を戻すこととなる。
<SE requirements for SMI>
Enclave is not allowed to run in SMM space. Attempting to execute the enclave in SMM mode results in a GP failure of the instruction. If it occurs while the SMI is running in the enclave, the processor saves the register state in the remote enclave and exits. Upon completion, the TBD MSR bit is set to indicate that SMI has occurred during execution of the enclave. The SMM code cannot access the enclaim data. Attempts to contact the EPC area will return junk data in the actual mode and return bad EPC pages in the protected mode.
一部の命令は実行が許可されない。どの命令が合法かを決定するためには幾つかの一般法則が利用される。
1.エンクレーブ内ではリングレベルの変更は許可されない。リングレベルの変更または変更の可能性の命令は禁止されている。
2.外部ソフトウェアは、エンクレーブ内のVMEXITSにサービス提供できない。エンクレーブ内でVMEXITを生成する、または生成する可能性のある全ての命令を禁ずる。
3.ソフトウェアは、エンクレーブ内で仮想マシンを生成することができない。全てのVMX命令を禁ずる。
4.エンクレーブの内部でI/O参照を実行する命令を禁ずる。
Some instructions are not allowed to be executed. Several general rules are used to determine which instruction is legal.
1. 1. Ring level changes are not allowed within the enclave. Orders to change or change the ring level are prohibited.
2. External software cannot service VMEXITS in the enclave. Prohibits all instructions that generate or may generate VMEXIT in the enclave.
3. 3. The software cannot create virtual machines in the enclave. Prohibit all VMX instructions.
4. Prohibit instructions to execute I / O references inside the enclave.
エンクレーブの第一世代では、プロセッサは、エンクレーブに入るときに、IOPLセットを0として、リング3で実行されてよい。エンクレーブを仮想化または非仮想化環境で実行する際に、プログラミング環境を保存するためには、表18−1にリストされている命令が合法である。
エンクレーブ内の状態には制約が課されている。エンクレーブに入るとき、GDTR.limit、LDTR.limit, IA32_EFER.SCE、および、IA32_SYSENTER_CSをTCS領域にセーブする。ローカルの値がクリアされる。これらレジスタへアクセスする、またはアクセスを生じさせる命令は、エンクレーブ内で失敗する。GDTR.limit、LDTR.limit, IA32_EFER.SCE、および、IA32_SYSENTER_CSは、エンクレーブを抜けるときに復元される。
エンクレーブの寿命は、独立した(distinct phases)に分類できる。第1の段階は、エンクレーブ生成である。第2の段階は、エンクレーブ利用である。最終の段階は、エンクレーブ破壊である。 Enclave life can be categorized as distinct phases. The first step is enclave generation. The second stage is the use of enclaves. The final stage is the destruction of the enclave.
エンクレーブの生成および利用には、OS/VMMのサポートが必要となる。エンクレーブはOS/VMMにセキュリティ面で依存しないが、一定のハードウェアデータ構造を適切に維持するためにはOS/VMMが必要となる。OS/VMMがこれら構造の維持に失敗すると、セキュリティは損なわれないが、エンクレーブ全体が不良となる場合がある。 OS / VMM support is required to generate and use enclaves. Enclave does not depend on OS / VMM in terms of security, but OS / VMM is required to properly maintain a certain hardware data structure. If the OS / VMM fails to maintain these structures, security is not compromised, but the entire enclave may be defective.
幾つかの命令は、エンクレーブの証明、秘密データのシールおよびシール解除、および、認証されたエンクレーブの許可をサポートする。 Some orders support proof of enclave, sealing and unsealing of confidential data, and authorization of authenticated enclave.
第1の段階では、エンクレーブは、アプリケーションによる利用に備えて、セキュアに構築され、内部ソフトウェア環境が設定されていてよい。3つの命令を利用してエンクレーブを生成する。第1の命令ECREATEは、最初の状態環境を設定する。この命令は、エンクレーブキーを生成し、装填し、暗号化を行い、エンクレーブデータ構造の格納に利用される2ページの整合性チェックを行う。第2の命令EADDPREは、エンクレーブに1ページのデータを追加する。詳しくは、エンクレーブ内のコード、スタック、およびヒープに必要なページを追加する。第3の命令EINITは、公知の状態に内部ソフトウェア環境を設定する。この命令の完了時には、エンクレーブは第2の段階である「利用」に移動している。 In the first stage, the enclave may be securely constructed and the internal software environment may be set up for use by the application. Create an enclave using three instructions. The first instruction, ECREATE, sets the initial state environment. This instruction generates an enclave key, loads it, encrypts it, and performs a two-page integrity check used to store the enclave data structure. The second instruction, EADDPRE, adds one page of data to the enclave. For more information, add the required pages to the code, stack, and heap in the enclave. The third instruction, EINIT, sets the internal software environment to a known state. Upon completion of this order, the enclave has moved to the second stage, "utilization."
EINITを実行する前に、構築ソフトウェアは許可証を、EMKPERMITを実行することにより、または、許可エンクレーブを利用することにより取得していてよい。 Prior to executing EINIT, the construction software may obtain a permit by executing EMKPERMIT or by using a permit enclave.
エンクレーブは、EENTER命令により入力される。この命令により、マシンがエンクレーブモードへと遷移する。そして、予め定義されたエントリポイントへ制御を渡す。EEXIT命令は、エンクレーブから外部アプリケーションに戻る。EIRRET命令は、割り込みの終了からエンクレーブに戻る。 The enclave is input by the EENTER instruction. This instruction causes the machine to transition to enclave mode. It then passes control to a predefined entry point. The EXIT instruction returns from the enclave to the external application. The EIRRET instruction returns to the enclave from the end of the interrupt.
EENTERまたはEIRETを介してエンクレーブに入る際には、以下の処理を命令により実行する。すなわち、処理は、GDTR.limitのセーブおよびクリア、LDTR.limit、IA32_EFER.SCE、IA32_SYSENTER_CSである。抜けるときに、GDTR、LDTR、IA32_EFER、および、IA32_SYSENTER_CSを復元する(On exit restore GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS)。 When entering the enclave via EENTER or EIRET, the following processing is executed by instruction. That is, the processing is save and clear of GDTR.limit, LDTR.limit, IA32_EFER.SCE, IA32_SYSENTER_CS. Restore GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS when exiting (On exit restore GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS).
エンクレーブの破壊には命令は存在しない。 There is no command to destroy the Enclave.
EDBG_READ命令は、デバッグエンクレーブ内のある位置の8バイトの読み取りを行う。非デバッグエンクレーブにはアクセスが許可されていない。EDBG_WRITE命令は、デバッグエンクレーブ内のある位置への8バイトの書き込みを行う。非デバッグエンクレーブにはアクセスが許可されていない。 The EDBG_READ instruction reads 8 bytes at a certain position in the debug enclave. No access is allowed to the non-debug enclave. The EDBG_WRITE instruction writes 8 bytes to a certain position in the debug enclave. No access is allowed to the non-debug enclave.
エンクレーブページキャッシュ(EPC)は、2つの命令を解して管理される。2つの命令は、EPCページ(ELPGおよびEWBINVPG)を装填/格納する。 The Enclave Page Cache (EPC) is managed by solving two instructions. The two instructions load / store EPC pages (ELPG and EWBINVPG).
EREPORTは、エンクレーブ計測値を保持する暗号的に保護された構造を生成する。EGETKEYは、様々な種類のエンクレーブ固有キーを取得する手段を提供する。EMKPERMITは、認証されたエンクレーブに対する許可証を生成するために利用される。
注3:将来のバージョンでは、リング0からもエンクレーブへのエントリが可能となるかもしれない。
EREPORT produces a cryptographically protected structure that holds enclave measurements. EGETKEY provides a means to obtain various types of enclave-specific keys. EMKPERMIT is used to generate a permit for a certified enclave.
Note 3 : In future versions, it may be possible to enter the enclave from
割り込みが生じると、プロセッサ状態をエンクレーブ内にセーブして(隠して)、状態をクリアする。さらに、割り込みの戻りアドレスを隠してもよい。 When an interrupt occurs, the processor state is saved (hidden) in the enclave to clear the state. In addition, the interrupt return address may be hidden.
エンクレーブの実行中に生じる割り込みは、オペレーティングシステムが予期するような形態の割り込みスタックに情報をプッシュして、OSコードを変更する必要がないようにする。これを遂行するために、トランポリンコードへのポインタを、割り込みスタックへとRIPとしてプッシュする。このトランポリンコードは、ゆくゆくは、特殊パラメータ(q.v.)を有するEENTER命令によりエンクレーブへ戻る。 Interrupts that occur during enclave execution push information into the interrupt stack in the form that the operating system expects, eliminating the need to change the OS code. To accomplish this, a pointer to the trampoline code is pushed onto the interrupt stack as a RIP. This trampoline code eventually returns to the enclave by an EENTER instruction with a special parameter (q.v.).
利用される割り込みスタックは、非SEモードで利用されたものと同じ規則により選択される。つまり規則とは、(1)特権付きレベル変更がある場合には、割り込みスタックは、新たなリングに関連付けられたものである、(2)特権付きレベル変更がない場合には、現在のアントラステッド・スタック(Untrusted Stack)を利用する、(3)IA−32e ISTメカニズムを利用する場合には、この方法を利用して割り込みスタックを選択する。 The interrupt stack used is selected according to the same rules used in non-SE mode. So the rules are (1) the interrupt stack is associated with the new ring if there is a privileged level change, and (2) the current untrusted if there is no privileged level change. -Use the stack (Untrusted Stack). (3) When using the IA-32e IST mechanism, use this method to select the interrupt stack.
図23は、スタックスイッチで割り込んだ後のアプリケーションおよび割り込みスタックの一実施形態を示す。現在のセーブ状態領域フレーム2300は、RSPレジスタ2305を含む。スレッド制御構造2310は、状態セーブ領域2312および割り込み戻りルーチン2314のカウントを含みうる。割り込みスタック2330は、SSレジスタ2332、RSPレジスタ2334、フラグレジスタ2336、CSレジスタ2338、命令レジスタ2340、およびエラーコード2342を含む。割り込みスタック2330は、RSPレジスタ2334内のデータを、アプリケーションスタック2320およびセーブ状態領域2300のカウントに送ってよい。エラーコード2342は、プッシュ2346後に、RSPから来てよい。割り込みルーティングルーチン2314および命令レジスタ2340は、uRTS2344のスレッドごとのトランポリンを送出する。
FIG. 23 shows an embodiment of an application and interrupt stack after being interrupted by a stack switch. The current save
いずれの場合にも、割り込みスタックおよびそれにプッシュされた情報の選択は、非SE処理と矛盾しない。図23は、スタックスイッチで割り込んだ後の、アプリケーションおよび割り込みスタックを示す。スタックスイッチのない割り込みは、アプリケーションスタックを利用する。加えて、TCSポインタは、後ほどEENTER命令が、割り込み後にエンクレーブを再開するときに利用するので、RBXに配置される。 In either case, the interrupt stack and the selection of information pushed to it are consistent with non-SE processing. FIG. 23 shows the application and interrupt stack after interrupting with a stack switch. Interrupts without a stack switch use the application stack. In addition, the TCS pointer is placed in the RBX because it will be used later by the EENTER instruction when resuming enclave after an interrupt.
TCS::IRR(割り込み戻りルーチン)は、後に特別なスレッドに戻る、スレッドごとのコードシーケンスを指し示している。このポインタは、戻りRIPとして割り込みスタックにプッシュされる。これによりデータ構造のセットが、IRETを、割り込み戻りコード(特別なEENTER命令を含む)が実行されるアプリケーションに戻す。EENTERは、割り込み時に初期化されるRBXレジスタをとり、これをTCSとして利用して、エンクレーブに再度入る。 The TCS :: IRR (Interrupt Return Routine) points to a thread-by-thread code sequence that later returns to a special thread. This pointer is pushed onto the interrupt stack as a return RIP. This causes the set of data structures to return the IRET to the application on which the interrupt return code (including the special EENTER instruction) is executed. EENTER takes an RBX register that is initialized at the time of interrupt, uses this as a TCS, and re-enters the enclave.
CF(キャリー・フラグ)、SF(サイン・フラグ)、PF(パリティ・フラグ)、OF(オーバフロー・フラグ)、AS(調節フラグ)、DF(方向フラグ)、ZF(ゼロ・フラグ)というRFLAGSのビットは、レジスタを割り込みスタックにプッシュする前にクリアされる。 RFLAGS bits such as CF (carry flag), SF (sign flag), PF (parity flag), OF (overflow flag), AS (adjustment flag), DF (direction flag), ZF (zero flag) Is cleared before pushing the register to the interrupt stack.
図24は、本発明の一実施形態の複数の状態セーブ領域スロットのスタックを実装することのできる方法を示す。スレッド制御構造2400は、次の状態セーブ領域スロット2402、現在の状態セーブ領域スロット2404、および、状態セーブ領域スロット2406を含んでよい。状態セーブ領域0 2410、状態セーブ領域12412、および状態セーブ領域N 2418は、状態セーブ領域内の3つの別個の選択位置である。次の状態セーブ領域スロット2402は、状態セーブ領域で利用される位置を特定する(状態セーブ領域0 2410)。現在の状態セーブ領域スロット2404は、状態セーブ領域で利用される位置を特定する(状態セーブ領域1 2412)。状態セーブ領域スロット2406は、状態セーブ領域で利用される位置を特定する(状態セーブ領域N 2418)。
FIG. 24 shows a method in which a stack of multiple state save area slots according to an embodiment of the present invention can be implemented. The
状態セーブ領域は、割り込み時点のエンクレーブ状態を保持する。割り込みは、次のエンクレーブに再度入る可能性のあるユーザモードに送られうるので、SSAは、図19−3に示すような複数のSSAスロットからなるスタックである。利用される状態セーブ領域の位置は、TCSの3つの変数により制御されるが、3つの変数とは、状態セーブ領域スロット(NSSA)の数(状態セーブ領域スタックの全スロット数を定義する)、現在の状態のセーブ領域スロット(CSSA)(次の割り込み上で利用される現在のスロットを定義する)、状態セーブ領域(SSA)(割り込み上にプロセッサ状態をセーブするのに利用されるセーブ領域スロットのセット)である。 The state save area holds the enclave state at the time of interruption. The SSA is a stack of multiple SSA slots as shown in FIG. 19-3, as interrupts can be sent to user mode, which may re-enter the next enclave. The position of the state save area used is controlled by three TCS variables, which are the number of state save area slots (NSSA) (defining the total number of slots in the state save area stack). Current state save area slot (CSAS) (defines the current slot used on the next interrupt), state save area (SSA) (save area slot used to save the processor state on the interrupt) Set).
エンクレーブ内のスレッド上で実行中に割り込みが生じたときには、マイクロコードが、TCS::SSAおよびTCS::CSSAを調べて、利用されるセーブ領域を決定する。プロセッサ状態がセーブされクリアされ(秘密のリークを防止するために)、TCS::CSSAを増分する。後述するように、最終スロットで例外が生じた場合には、例外をエンクレーブに送ることができない。 When an interrupt occurs during execution on a thread in the enclave, the microcode examines the TCS :: SSA and TCS :: CSSA to determine the save area used. Processor state is saved and cleared (to prevent secret leaks) and TCS :: CSSA is incremented. As will be described later, if an exception occurs in the final slot, the exception cannot be sent to the enclave.
注:EENTERでは、CCSAをNSSA未満としてよく、割り込みについて少なくとも1つのセーブ領域が存在するよう保証される(割り込みから戻るためにEENTERを利用中ではない限り)。 Note: In EENTER, CCSA may be less than NSSA and it is guaranteed that there is at least one save area for the interrupt (unless you are using EENTER to return from the interrupt).
図25は、割り込み、不良、およびトラップの状態遷移を有する状態マシンの一部を示す。可能性のある状態は、非アクティブ2500、アクティブ2510、予期2520、処理済み(EENTER不法)2530、および処理中2540である。EENTERがTCS:ENTRY2502に配置されると、非アクティブ2500は、アクティブ2510に遷移する。EEXIT2504が生じると、アクティブ2510は非アクティブ2500に遷移する。割り込み、不良、またはトラップ2512が生じると、アクティブ2510は予期2520に遷移する。EIRET2514が生じると、予期2520はアクティブ2510に遷移する。EENTERがTCS:HANDLER2524に配置されると、予期2520が処理中2540に遷移する。EIRET2522が生じると、予期2520が処理中2540に遷移する。割り込み、不良、またはトラップ2526が生じると、処理中2540は予期2520に遷移する。EEXIT2532が生じると、処理中2540が処理済み2530に遷移する。エンクレーブ例外ハンドラで処理割り込みが生じ、EIRET2534が生じると、処理済2530が処理中2540に遷移する。エンクレーブ例外ハンドラからではない処理割り込みが生じ、EIRET2534が生じると、処理済み2530がアクティブ2510に遷移する。点線の遷移2522、2526、2534は、エンクレーブ例外ハンドラ内の割り込みの処理中のみに生じる。
FIG. 25 shows a portion of a state machine with interrupt, bad, and trap state transitions. Possible states are inactive 2500, active 2510, expected 2520, processed (EENTER illegal) 2530, and
図25は、エンクレーブ状態マシンの、割り込みに対処する部分を示す。割り込みは、オプションのスタックスイッチおよび割り込みスタックに合成割り込みフレームをプッシュすることから始まる。イベントが割り込みであった場合には、エンクレーブは割り込み状態に入る。イベントが例外であった場合には、エンクレーブは例外状態に入る。これら2つの状態は、エンクレーブへのエンクレーブ例外を確実に配信するために、さらには、攻撃アプリケーションコードによるスプリアス例外の配信を妨げるために、区別される。 FIG. 25 shows a portion of the enclaved machine that handles interrupts. Interrupts begin by pushing a synthetic interrupt frame onto the optional stack switch and interrupt stack. If the event was an interrupt, the enclave goes into an interrupted state. If the event was an exception, the enclave goes into an exceptional state. These two states are distinguished to ensure that the enclave exception is delivered to the enclave and to prevent the attacking application code from delivering the spurious exception.
割り込み状態に遷移すると、アントラステッド・コード(アプリケーション、OSまたはこれらの両方)は、EENTER/RETURN_FROM_INTERRUPTを利用したエンクレーブの再開を行うだけでよい。 Upon transitioning to the interrupted state, the untrusted code (application, OS, or both) need only resume enclave using EENTER / RETURN_ROM_INTERRUPT.
例外状態に遷移すると、アントラステッド・コード(アプリケーション、OSまたはこれらの両方)は、(1)EIRETを利用してエンクレーブを再開して割り込まれたIPに戻る。これは、例えばページ不良を処理する方法である。割り込みが不良により生じ、不良条件を修正するために何も行われていない場合には、不良命令を再度実行して、不良を再度起こす(and will fault again)。しかしトラップの後のEIRETは、トラップ命令の後に命令に戻る、(2)エンクレーブ例外ハンドラを呼び出す、(3)スレッドまたはエンクレーブを破棄する、と決定してよい。 Upon transition to an exceptional state, the untrusted code (application, OS, or both) resumes enclave using (1) EIRET and returns to the interrupted IP. This is, for example, a method of dealing with page defects. If the interrupt is caused by a defect and nothing is done to correct the failure condition, the bad instruction is re-executed to cause the failure again (and will fault again). However, the EIRET after the trap may decide to return to the instruction after the trap instruction, (2) call the enclave exception handler, and (3) destroy the thread or enclave.
予期状態のEENTERは、処理中状態に進む。トラップハンドラからのEEXIT(処理中状態)は、処理済状態に進む。ENTER/NORMALは、この状態において不法である。トランポリンからのEIRETは、最後の割り込みからSSAにプッシュされた状態(アクティブまたは処理中状態)を再開する。 EENTER in the expected state advances to the processing state. EXIT (processing state) from the trap handler proceeds to the processed state. ENTER / NORMAL is illegal in this state. EIRET from the trampoline resumes the state pushed to the SSA (active or in-flight state) from the last interrupt.
セキュアなエンクレーブ命令を2つのオペコード(つまり、特権付きオペコードと特権なしオペコード)に分割する。命令処理は、命令の呼び出し時にRAXの値により決定される。
ECREATE命令は、保護されているSECSを初期化する。ソースオペランドは、page_info構造を指し示している。コンテンツページフィールドは、保護されていないSECS構造を指し示している。SECS構造は、ページが整列されていてもよい。SECSベースの下位の12ビットおよび境界値は0であってよい。SECSは、EPC内の空のスロットのアドレスである。sec_infoは、保護されていないsec_info構造のアドレスである。対応するsec_infoフラグフィールドは、適切に初期化されてよい。
<EADDPRE>
<命令の説明>
EADDPREは、特権のあるソフトウェアに、lin_addrが指定するエンクレーブ内のページに、エンクレーブの外部のページをコピーさせ、エンクレーブページの属性は、sec_infoフラグフィールドを利用して設定される。命令の一部として、ページをハッシュして、結果生じるハッシュ値を、エンクレーブの計測値レジスタに拡張する。EADDPREは、EINIT命令がまだ初期化していないエンクレーブに対してのみ実行することができる。
<Explanation of instructions>
EADDPRE causes privileged software to copy pages outside the enclave to pages in the enclave specified by lin_addr, and the attributes of the enclave page are set using the sec_info flag field. As part of the instruction, the page is hashed and the resulting hash value is extended to the enclave's measurement register. EADDPRE can only be executed for enclaves where the EINIT instruction has not yet been initialized.
<EADDPOST>
<命令の説明>
EALLOCATEは、特権のあるソフトウェアに、lin_addrが指定するエンクレーブのSMAPエントリを初期化させ、エンクレーブページの属性は、sec_infoフラグフィールドを利用して設定される。エンクレーブがページにアクセスできるようになる前に、EACCEPT命令を用いてエンクレーブのページにアクセスしてよい。EALLOCATEは、EINIT命令が初期化したエンクレーブにのみ実行される。
<Explanation of instructions>
EALLOCATE initializes the SMAP entry of the enclave specified by lin_addr in the privileged software, and the attributes of the enclave page are set using the sec_info flag field. The Enclave page may be accessed using the EACCEPT instruction before the Enclave can access the page. EALLOCATE is executed only in the enclave initialized by the EINIT instruction.
<EMKPERMIT>
<命令の説明>
エンクレーブまたはライセンスを認証して、これを用いて許可証を生成する。rbx==NULLである場合には、証明書はIntelにより署名されてよい。他の場合には、ライセンスは、rbx許可証に示されるキーにより署名されてよい。
<Explanation of instructions>
Authenticate the enclave or license and use it to generate a permit. If rbx == NULL, the certificate may be signed by Intel. In other cases, the license may be signed with the key shown on the rbx permit.
<EINIT>
<命令の説明>
EINITは、エンクレーブを、ソフトウェア環境で実行準備できた状態として表示する。ついに初期化に成功すると(At the end successful initialization)、EENTERをエンクレーブに対して許可する。
<Explanation of instructions>
EIINT displays the enclave as ready to run in the software environment. When the initialization is finally successful (At the end successful initialization), EENTER is allowed to the enclave.
<ELPG>
<命令の説明>
この命令は、ページをエンクレーブページキャッシュ(EPC)に装填するのに利用される。
<Explanation of instructions>
This instruction is used to load the page into the Enclave Page Cache (EPC).
<EWBINVPG>
<命令の説明>
この命令は、EPCからメインメモリにダーティページを書き戻すために利用される。
<Explanation of instructions>
This instruction is used to write the dirty page back from the EPC to main memory.
<EUPSMAP>
<命令の説明>
この命令は、EPCに常駐しているエンクレーブページのバージョンをチェックおよび更新する。
<Explanation of instructions>
This instruction checks and updates the version of the enclave page residing on the EPC.
<EREMOVE>
<命令の説明>
この命令は、データがEPCに装填されたときにSMAPを更新する。
<Explanation of instructions>
This instruction updates SMAP when the data is loaded into the EPC.
<EADDSMAP>
<命令の説明>
この命令は、エンクレーブを既に初期化したとき、SMAPに新たなページを追加するために利用される。
<Explanation of instructions>
This instruction is used to add a new page to SMAP when the enclave has already been initialized.
<EMODIFY>
<命令の説明>
この命令は、SEC_INFOフィールドを修正して、エンクレーブが該エンクレーブ内のページを修正することを許可する。エンクレーブは、ページに対する変更を要求するが、プロセスを完了するために変更を受け付けてもよい。
<Explanation of instructions>
This instruction modifies the SEC_INFO field to allow the enclave to modify the pages within the enclave. The enclave requests changes to the page, but may accept changes to complete the process.
<EACCEPT>
<命令の説明>
エンクレーブ内のソフトウェアは、この命令を利用して、SEC_INFOフィールドへの変更を受け付ける。これにより、SMAPを新たなページタイプに更新することができる。
<Explanation of instructions>
The software in the enclave uses this instruction to accept changes to the SEC_INFO field. This allows SMAP to be updated with a new page type.
<EENTER>
<命令の説明>
EENTER命令は、エンクレーブに実行を渡す。命令の最後に、CPUは、TCS oENTRYまたはoHANDLERで指定されるIPで、エンクレーブモードで実行されている。EENTERは、TCSが有効であり、エントリ可能であることを確かめる。TCSおよび対応するSSAは、命令を続けるためにメモリに常駐させてよい。EENTERはさらに、状態マシンをチェックして、エントリのタイプを判断し、TCS内で一度に1つの論理プロセッサのみがアクティブであることを確かめる。RFLAGS.TFは、EENTER上で、僅かに修正された振る舞いを有する。RFLAGS.TFがTCS.SAVE_TFに格納されて、その後、TCS.TFから装填される。次にデバッグ例外が、RFLAGS.TFの更新値に応じて条件付きで生成される。エンクレーブがデバッグモードにない場合には、デバッグレジスタDR7をTCS.DR7にセーブして、クリアする。IA32_DEBUGCTL MSRについても同様である。
<Explanation of instructions>
The EENTER instruction passes execution to the enclave. At the end of the instruction, the CPU is running in enclave mode with the IP specified by TCS oENTRY or oHANDRER. EENTER verifies that TCS is valid and can be entered. The TCS and the corresponding SSA may be resident in memory to continue the instruction. EENTER also checks the state machine to determine the type of entry and ensures that only one logical processor is active in the TCS at a time. FLAGS. TF has a slightly modified behavior on EENTER. FLAGS. TF is TCS. It is stored in SAVE_TF and then TCS. Loaded from TF. The next debug exception is FLAGS. Conditionally generated according to the updated value of TF. If the enclave is not in debug mode, debug register DR7 is set to TCS. Save to DR7 and clear. The same applies to IA32_DEBUGCTL MSR.
<RFLAGS.TFの振る舞い>
EENTERの実行開始時のRFLAGS.TFの値は、EENTER完了時のトラップに影響しない。TCSから装填されるRFLAGS.TFの値は、トラップがとられているかを決定する。
<DR7の振る舞い>
エンクレーブがデバッグモードにない場合には、デバッグレジスタDR7をTCS.DR7にセーブして、クリアする。
<IA32_DEBUG_CTLの振る舞い>
エンクレーブがデバッグモードにない場合には、IA32_DEBUG_CTL MSRをTCS.DEBUG_CTLにセーブして、クリアする。
FLAGS. At the start of execution of EENTER. The value of TF does not affect the trap at the completion of EENTER. FLAGS. Loaded from TCS. The value of TF determines if a trap has been taken.
<Behavior of DR7>
If the enclave is not in debug mode, debug register DR7 is set to TCS. Save to DR7 and clear.
<Behavior of IA32_DEBUG_CTL>
If the enclave is not in debug mode, TCS. IA32_DEBUG_CTL MSR. Save to DEBUG_CTL and clear.
<EEXIT>
EEXITは、エンクレーブの外部へと抜ける。
<命令の説明>
EEXITは、エンクレーブモードをディセーブルして、RBSが指定する位置に分岐する。この命令によりレジスタは影響を受けない。秘密がいずれかのレジスタに含まれる場合には、これらレジスタをクリアするのはエンクレーブソフトウェアの任務となる。RFLAGS.TFは、EEXIT上で、僅かに修正された振る舞いを有する。RFLAGS.TFがTCS.SAVE_TFから装填される。次に、デバッグ例外が、RFLAGS.TFの更新値に応じて条件CR-0021付きで生成される。エンクレーブがデバッグモードにない場合には、デバッグレジスタDR7をTCS.DR7に装填する。この振る舞い、および、RFLAGS.TFの振る舞いは、???に詳述されている。
EEXIT goes out of the enclave.
<Explanation of instructions>
EEEXIT disables the enclave mode and branches to the position specified by the RBS. The register is unaffected by this instruction. If the secret is contained in any of the registers, it is the responsibility of the enclave software to clear these registers. FLAGS. TF has a slightly modified behavior on EEXIT. FLAGS. TF is TCS. Loaded from SAVE_TF. Next, the debug exception is FLAGS. It is generated with the condition CR-0021 according to the update value of TF. If the enclave is not in debug mode, debug register DR7 is set to TCS. Load into DR7. This behavior and RFLAGS. What is the behavior of TF? ?? ?? It is detailed in.
<RFLAGS.TFの振る舞い>
EEXITの実行開始時のRFLAGS.TFの値は、EEXITの完了時のトラップには影響しない。SSAから装填されるRFLAGS.TFの値は、トラップをとるかを決定する。
<DR7の振る舞い>
エンクレーブがデバッグモードにない場合には、デバッグレジスタDR7をTCS.DR7に装填する。
<IA32_DEBUG_CTLの振る舞い>
エンクレーブがデバッグモードにない場合には、IA32_DEBUG_CTL MSRをTCS.DEBUG_CTLから装填する。
FLAGS. At the start of execution of EEXIT. The value of TF does not affect the trap at the completion of EXIT. FLAGS. Loaded from SSA. The value of TF determines whether to take a trap.
<Behavior of DR7>
If the enclave is not in debug mode, debug register DR7 is set to TCS. Load into DR7.
<Behavior of IA32_DEBUG_CTL>
If the enclave is not in debug mode, TCS. IA32_DEBUG_CTL MSR. Load from DEBUG_CTL.
<EIRET>
<命令の説明>
EIRET命令は、SSAに前に格納していたマシン状態を利用して、例外または割り込みのために中断していたエンクレーブの実行を再開する。EIRETは、TCSが有効であり、再開可能であることを確かめる。TCSおよび対応するSSAが、処理を進めるために命令のためのメモリに常駐している場合がある。EIRETはさらに、状態マシンをチェックして、エントリの種類を判断し、TCS内で一度に1つの論理プロセッサのみがアクティブであることを確かめる。RFLAGS.TFがEIRET上に設定されている場合、命令の完了時にデバッグ例外が生じる(つまり、通常のTFの振る舞い)。この例外は、エンクレーブ内で生じたものとして報告され(通常のSEで定義されている方法により)、内部では命令は実行されない。EIRETはSSAからのRFLAGSを復元するので、TFは、EIRETの終了時に設定されてよい。この場合、TFは、以下の命令に影響する(これも通常のTFの振る舞いである)。
<Explanation of instructions>
The EIRET instruction takes advantage of the machine state previously stored in the SSA to resume execution of the enclave that was suspended due to an exception or interrupt. EIRET ensures that TCS is valid and resumable. The TCS and the corresponding SSA may be resident in memory for instructions to proceed. EIRET also checks the state machine to determine the type of entry and ensures that only one logical processor is active in the TCS at a time. FLAGS. If TF is set on EIRET, a debug exception will be thrown at the completion of the instruction (ie normal TF behavior). This exception is reported as occurring within the enclave (by the method defined in normal SE) and no instructions are executed internally. The TF may be set at the end of the EIRET, as the EIRET restores the RFLAGS from the SSA. In this case, the TF affects the following instructions (which is also normal TF behavior).
<RFLAGS.TFの振る舞い>
RFLAG.TFがEIRET命令の始めに設定されている場合、#DBが完了後に生じる。例外は、TFが設定されていなければ制御が転送されたRIPで報告される。実際、エンクレーブにおいて転送処理は行われない。EIRETの通常処理の一環として、RFLAGSをSSAコピーから復元する。結果生じるTFが設定されている場合には、エンクレーブ内の対象命令の実行後に#DBが生じる。これらの振る舞いは、通常のIA IRET命令の振る舞いと矛盾しない。
<DR7の振る舞い>
DR7は、最後の割り込みまたは例外で前にセーブされたSSAコピーからを復元される。
<IA32_DEBUG_CTLの振る舞い>
IA32_DEBUG_CTL MSRは、最後の割り込みまたは例外で前にセーブされたSSAコピーから復元される。
RFLAG. If TF is set at the beginning of the EIRET instruction, it will occur after #DB is completed. Exceptions are reported in the RIP to which control was transferred if TF was not configured. In fact, no transfer processing is performed in the enclave. Restore FLAGS from an SSA copy as part of the normal processing of EIRET. If the resulting TF is set, #DB will occur after the execution of the target instruction in the enclave. These behaviors are consistent with the behavior of normal IA IRET instructions.
<Behavior of DR7>
DR7 is restored from the previously saved SSA copy with the last interrupt or exception.
<Behavior of IA32_DEBUG_CTL>
The IA32_DEBUG_CTL MSR is restored from the previously saved SSA copy on the last interrupt or exception.
<EREPORT>
EREPORT命令は、エンクレーブの内容に関する計測値を報告する。
<命令の説明>
EREPORTは、エンクレーブ計測値レジスタ、その機能およびデバッグステータス(フラグ)を取得する。これらの値全ては、対称メッセージ認証コードを利用して保護され、REPORTキーを利用して検証することができる。REPORTキーを要求するエンクレーブでは、適切な機能がSECSに設定されて、EGETKEY命令によりこれを取得することができる。この命令の結果は、宛先位置output_buffer_laに配置される。
The EREPORT instruction reports measurements regarding the contents of the enclave.
<Explanation of instructions>
EREPORT acquires the enclave measurement value register, its function, and debug status (flag). All of these values are protected using a symmetric message authentication code and can be verified using a REPORT key. In an enclave that requires a REPORT key, an appropriate function is set in SECS and can be obtained by the EGETKEY instruction. The result of this instruction is placed at the destination position output_buffer_la.
<ERDMR>
ERDMR命令は、エンクレーブSECSから計測値レジスタの値を読み取る。
<命令の説明>
この命令は、エンクレーブ外からのみ実行可能である。SECSが有効なSECページを指し示している場合には、命令は、output_buffer_laにより特定されるアドレスに、エンクレーブ計測値レジスタの内容を出力する。
The ERDMR instruction reads the value of the measured value register from the enclave SECS.
<Explanation of instructions>
This instruction can only be executed from outside the enclave. If SECS points to a valid SEC page, the instruction outputs the contents of the enclave measurement register to the address specified by output_buffer_la.
<EGETKEY>
エンクレーブコードにより利用されて、プロセッサキー階層から特定のキーを戻す。
<命令の説明>
要求されるキーは、KeyRequest構造を利用して特定され、そのアドレスは入力として提供される。このアドレスは自然整列される。出力は常に256ビットのデータ値となる。この値とするためには、output_laは自然整列される必要がある。
Used by the enclave code to return a specific key from the processor key hierarchy.
<Explanation of instructions>
The requested key is identified using the KeyRequest structure and its address is provided as an input. This address is naturally aligned. The output is always a 256-bit data value. To get this value, output_la needs to be naturally aligned.
<ERDTCSPTR>
<命令の説明>
ERDTCSPTR命令は、現在のTCSリニアアドレスをRBXに読み込むために利用される。
<Explanation of instructions>
The ERDTCSPTR instruction is used to read the current TCS linear address into the RBX.
<EDBGRD>
<命令の説明>
EDBGRD命令は、デバッグエンクレーブから8バイトを読み取るのに利用される。
<Explanation of instructions>
The EDBGRD instruction is used to read 8 bytes from the debug enclave.
<EDBGWR>
<命令の説明>
EDBGWR命令は、8バイトをデバッグ・エンクレーブページに書き込むために利用される。
<Explanation of instructions>
The EDBGWR instruction is used to write 8 bytes to the debug enclave page.
<ERDINFO>
ERDINFO命令は、エンクレーブページキャッシュの内容に関する情報を戻す。
<命令の説明>
エンクレーブ外で実行されると、EREPORTは、自身の機能およびデバッグステータス(フラグ)を、エンクレーブ計測値レジスタに報告する。これらの値全ては、対称メッセージ認証コードを利用して保護され、EVERIFYREPORT命令を利用して検証することができる。この命令の結果は、宛先位置output_buffer_laに配置される。
The ERDINFO instruction returns information about the contents of the enclave page cache.
<Explanation of instructions>
When run outside the enclave, EREPORT reports its functionality and debug status (flags) to the enclave measurement register. All of these values are protected using a symmetric message authentication code and can be verified using the EVERIFY REPORT instruction. The result of this instruction is placed at the destination position output_buffer_la.
<ルーチン参照>
<退出(Exit)>
このセクションでは、退出処理についての擬似コードを提供する。このコードは、エンクレーブコードが計画していないエンクレーブからの退出があるときに呼び出される。エンクレーブの実行は、停止した場所から再開される。再開に必要な情報は、外部スタック上にセーブされる。プロセッサのアーキテクチャ状態は、適切なセーブ領域にセーブされる。
<Exit>
This section provides pseudo-code for exit processing. This code is called when the enclave code has an unplanned exit from the enclave. Enclave execution resumes from where it stopped. The information needed to resume is saved on the external stack. The architectural state of the processor is saved in the appropriate save area.
<リーダ・ロックの取得>
RWロックにより、論理プロセッサは、共有リソースにアクセスして、スレッドが共有リソースにアクセスすることのできる2つのモードを提供する。この2つのモードとは、(1)共有モード:複数のリーダ論理プロセッサに対する共有の読み取り専用アクセスを許可し、これにより、これら複数のプロセッサが、共有リソースからコンカレントにデータを読み出すことができるようになるモード、(2)排他的モード:一度の1つの書き込み論理プロセッサへの読み書きアクセスを許可するモードであり、排他的モードでロックが取得されると、他のスレッドは、書き込みを行っている実体がロックを解除するまでは共有リソースにアクセスできなくなる、である。
The RW lock allows the logical processor to access the shared resource and provide two modes in which the thread can access the shared resource. The two modes are: (1) Shared mode: Allows shared read-only access to multiple reader logical processors, which allows these multiple processors to read data concurrently from shared resources. Mode, (2) Exclusive mode: A mode that allows read / write access to one write logical processor at a time. When a lock is acquired in exclusive mode, other threads are writing. You will not be able to access the shared resource until you unlock it.
<サブルーチンの説明>
このサブルーチンは、実際のところ、uCodeがPMHアドレス−変換機能をuCodeに曝すとき利用されるハードウェアの追加である。XUTRANSLATEは、主に、PMHコンテキストおよびリニアアドレスを入力として、出力として最終物理アドレスを生成するuOpである。PMHがページテーブル・ウォークの間に不良条件に遭遇すると、これらがuCodeに報告される。uOpの詳細は、本書類の範囲外である。
<Explanation of subroutine>
This subroutine is actually an addition of the hardware used when uCode exposes the PMH address-translation function to uCode. XUTRANSLATE is a uOP that mainly takes PMH context and linear address as input and generates the final physical address as output. If PMH encounters bad conditions during the page table walk, these will be reported to uCode. The details of uOp are outside the scope of this document.
<サブルーチンの説明>
このサブルーチンは、識別されたキーを有する導出バッファ(DerivationBuffer)にCMAC処理を行うことでキーを生成する際に利用される。導出バッファは、128ビットの倍数でなくてはならない。
This subroutine is used when generating a key by performing CMAC processing on a derivation buffer (DerivationBuffer) having the identified key. The derivation buffer must be a multiple of 128 bits.
Claims (11)
請求項1に記載のプロセッサ。 It has an execution logic that executes an instruction to report the state of a secure enclave stored in memory to either a local agent or a remote agent.
The processor according to claim 1 .
前記ソフトウェアプログラムが実行していない間に前記ソフトウェアプログラムを保護するセキュアなマップ(SMAP)と
を備える
請求項1または2に記載のプロセッサ。 A crypto memory aperture (CMA) that protects the software program from attacks while the software program is running.
It has a secure map (SMAP) that protects the software program while it is not running.
The processor according to claim 1 or 2 .
請求項1から3のいずれか一項に記載のプロセッサ。 Includes execution logic that executes at least one secure enclave access instruction to allocate or deal with the corresponding memory or software thread in the secure enclave.
The processor according to any one of claims 1 to 3 .
請求項1から4のいずれか一項に記載のプロセッサ。 Equipped with SMAP, a hierarchical protection tree that allows multiple memory updates within a secure enclave in a single processor cycle
The processor according to any one of claims 1 to 4 .
請求項1から5のいずれか一項に記載のプロセッサ。 Has execution logic to execute instructions to provide a unique key to a secure enclave
The processor according to any one of claims 1 to 5 .
請求項1から6のいずれか一項に記載のプロセッサ。 Provides logic to execute instructions to build a trusted environment managed by an untrusted agent
The processor according to any one of claims 1 to 6 .
請求項1から7のいずれか一項に記載のプロセッサ。 It has the logic to execute an instruction to judge the validity of the license for accessing the secure enclave by comparing the size of the enclave with the size specified by the license certificate.
The processor according to any one of claims 1 to 7 .
請求項1から8のいずれか一項に記載のプロセッサ。 Includes control bit-controlled logic for secure enclave user-level policy management
The processor according to any one of claims 1 to 8 .
請求項1から9のいずれか一項に記載のプロセッサ。 Provide logic to execute at least one instruction to grant access to at least one instance of a secure enclave licensed to a user
Processor according to any one of claims 1 to 9.
請求項1から10のいずれか一項に記載のプロセッサ。 It has the logic to execute at least one instruction to compromise the enclave security of only the enclaves that are allowed to debug, which allows secure debugging of the enclave.
The processor according to any one of claims 1 to 10 .
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019020537A JP6777288B2 (en) | 2019-02-07 | 2019-02-07 | Processor |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2019020537A JP6777288B2 (en) | 2019-02-07 | 2019-02-07 | Processor |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2016250111A Division JP6480403B2 (en) | 2016-12-22 | 2016-12-22 | apparatus |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2019109910A JP2019109910A (en) | 2019-07-04 |
JP6777288B2 true JP6777288B2 (en) | 2020-10-28 |
Family
ID=67179968
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2019020537A Active JP6777288B2 (en) | 2019-02-07 | 2019-02-07 | Processor |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP6777288B2 (en) |
Families Citing this family (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20220012355A1 (en) * | 2021-09-23 | 2022-01-13 | Intel Corporation | Provisioning federated computation on distributed private data |
Family Cites Families (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP4226760B2 (en) * | 2000-05-08 | 2009-02-18 | 株式会社東芝 | Microprocessor, multitask execution method using the same, and multired execution method |
JP4098478B2 (en) * | 2001-01-31 | 2008-06-11 | 株式会社東芝 | Microprocessor |
JP4263976B2 (en) * | 2003-09-24 | 2009-05-13 | 株式会社東芝 | On-chip multi-core tamper resistant processor |
-
2019
- 2019-02-07 JP JP2019020537A patent/JP6777288B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
JP2019109910A (en) | 2019-07-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10885202B2 (en) | Method and apparatus to provide secure application execution | |
JP5443599B2 (en) | Method and apparatus for providing secure application execution | |
US8972746B2 (en) | Technique for supporting multiple secure enclaves | |
US10685145B2 (en) | Secure processor and a program for a secure processor | |
US7073059B2 (en) | Secure machine platform that interfaces to operating systems and customized control programs | |
US8904189B1 (en) | System and method for validating program execution at run-time using control flow signatures | |
JP2005527019A (en) | Multi-token seal and seal release | |
JP6068325B2 (en) | Processor that provides secure application execution | |
JP6777288B2 (en) | Processor | |
JP6480403B2 (en) | apparatus | |
JP6085320B2 (en) | Processor, program, system and method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190306 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20190306 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20200526 |
|
A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20200825 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20200908 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20200928 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 6777288 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |