KR20120099472A

KR20120099472A - Method and apparatus to provide secure application execution

Info

Publication number: KR20120099472A
Application number: KR1020127016450A
Authority: KR
Inventors: 프란시스 엑스 맥킨; 카를로스 브이 로자스; 우데이 알 사바간카르; 사이먼 피 존슨; 빈센트 알 스칼라타; 마이클 에이 골드스미스; 어니 브릭켈; 지앙타오 리; 하워드 씨 허버트; 프라샨트 디완; 스티븐 제이 토롭카; 길버트 네이저; 데이비드 더햄; 개리 그라운케; 버나드 린트; 디케 돈 에이 반; 요셉 치훌라; 스탈린셀바라즈 제야싱; 도렌 스티븐 알 반; 디온 로저스
Original assignee: 인텔 코포레이션
Priority date: 2009-12-22
Filing date: 2009-12-22
Publication date: 2012-09-10
Also published as: WO2011078855A1; WO2011078855A9; GB2481563A; GB2550698B; CN102473224A; DE112009005466T5; CN102473224B; GB201709341D0; BRPI0924512A2; GB2550698A; JP2012530961A; GB2481563B; KR101457355B1; GB201118724D0; JP5443599B2

Abstract

컴퓨터 시스템 내에서 보안 애플리케이션 및 데이터 무결성을 가능하게 하는 기술. 일 실시예에서, 애플리케이션 및 데이터가 저장되고 실행될 수 있는 하나 이상의 보안 엔클레이브가 확립된다. Technology that enables secure application and data integrity within computer systems. In one embodiment, one or more secure enclaves are established in which applications and data can be stored and executed.

Description

보안 애플리케이션 실행을 제공하는 방법 및 장치{METHOD AND APPARATUS TO PROVIDE SECURE APPLICATION EXECUTION}METHOD AND APPARATUS TO PROVIDE SECURE APPLICATION EXECUTION}

본 발명의 실시예는 일반적으로 정보 처리 분야에 관한 것으로, 보다 상세하게는 컴퓨터 시스템 및 마이크로프로세서에서의 보안 분야에 관한 것이다.
Embodiments of the present invention generally relate to the field of information processing, and more particularly to the field of security in computer systems and microprocessors.

컴퓨터 시스템 내에 애플리케이션 및 자신들의 데이터의 실행 및 무결성의 보안을 확보하는 것이 점점 중요해 지고 있다. 종래의 몇몇 보안 기술은 애플리케이션 및 데이터를 유연하지만 신뢰성 있는 방식으로 보안성을 충분히 제공하지 못한다.
It is becoming increasingly important to secure the execution and integrity of applications and their data within computer systems. Some conventional security techniques do not provide sufficient security for applications and data in a flexible but reliable manner.

본 발명의 실시예는 첨부 도면에서 예로서 도시되지만 이에 한정되는 것은 아니며, 도면에서 유사한 참조 번호는 유사한 구성요소를 지칭한다.
도 1은 본 발명의 적어도 하나의 실시예가 사용될 수 있는 마이크로프로세서의 블록도를 도시한다.
도 2는 본 발명의 적어도 하나의 실시예가 사용될 수 있는 공유 버스 컴퓨터 시스템의 블록도를 도시한다.
도 3은 본 발명의 적어도 하나의 실시예가 사용될 수 있는 포인트 대 포인트(point-to-point) 상호접속 컴퓨터 시스템의 블록도를 도시한다.
도 4는 본 발명의 적어도 하나의 실시예가 사용될 수 있는 멀티-코어 마이크로프로세서의 블록도를 도시한다.
도 5는 본 발명의 일시예에서 SE(secure enclave)의 가능한 구현을 도시한다.
도 6은 본 발명의 적어도 하나의 실시예가 사용될 수 있는 마이크로프로세서의 블록도를 도시한다.
도 7은 본 발명의 일 실시예에서 구현될 수 있는 엔클레이브(enclave) 페이지 캐시의 일부를 액세스하기 위한 제어 구조의 예를 도시한다.
도 8은 데이터 구조가 어떻게 함께 합쳐지는지(stitched)를 보여주는 본 발명의 일 실시예에서의 스레드 제어 구조의 예를 도시한다.
도 9는 본 발명의 일 실시예에서 발견될 수 있는, 쿼팅(quoting)으로 알려진 소프트웨어 인증(attestation) 프로세스의 한 단계를 도시한다.
도 10은 본 발명의 일 실시예에서 한 세트의 측정 레지스트로부터 쿼팅을 제조하기 위한 단계들을 도시한다.
도 11은 본 발명의 일 실시예에서 측정 레지스터 MR_EADD를 업데이트하는 EADD 프로세스를 도시한다.
도 12는 본 발명의 일 실시예에서 리포트를 생성하기 위한 EREPORT를 도시한다.
도 13은 본 발명의 일 실시예에서 발견되는 응답-보호 메커니즘을 도시한다.
도 14는 본 발명의 일 실시에에서 발견되는 응답-보호 메커니즘의 MAC 트리 구조 부분의 예를 도시한다.
도 15는 본 발명의 일 실시예에서 페이지 폴트 에러 코드(page fault error code) 맵이 어떻게 구현될 수 있는지를 도시한다.
도 16은 본 발명의 일 실시예에서 엔클레이브를 론칭하라는 퍼밋(permit)을 생성하는 프로세스의 예를 도시한다.
도 17은 본 발명의 일실시예를 위해 단일 패키지 보안 엔클레이브를 위한 플랫폼 키 계층의 가능한 구현예를 도시한다.
도 18은 본 발명의 일 실시예에서 마이크로코드 기반 보안 엔클레이브 키 계층의 예를 도시한다.
도 19는 본 발명의 일 실시예에서 발견될 수 있는 엔클레이브 CTL_MSR 레지스터의 도면이다.
도 20은 본 발명의 일 실시예에서 사용되는 암호 블록 체인 알고리즘을 도시한다.
도 21은 본 발명의 일 실시예에서 단일 AES 블록의 암호화를 도시하는 흐름도이다.
도 22는 본 발명의 일 실시예에서 구현되는 바에 따라 암호 블록 체인 알고리즘을 이용하는 다수의 AES 블록의 암호화의 예를 도시하는 흐름도이다.
도 23은 일 실시예에서 스택 스위치와의 인터럽트 후의 인터럽트 스택 및 애플리케이션을 도시한다.
도 24는 본 발명의 일 실시에에서 다수의 상태 저장 영역 슬롯(state save area slot)의 스택을 구현하기 위한 가능한 방법을 도시한다.
도 25는 본 발명의 일 실시예에서 인터럽트, 폴트(fault) 및 트랩(trap)에 대한 상태 전이를 가는 상태 머신의 일부를 도시한다.
도 26은 본 발명의 일 실시예를 위해 디지털 난수 생성기를 위한 프로세서 패키지를 도시한다.
도 27은 본 발명의 일 실시예를 위해 디버그 레지스터 DR7 2700을 도시한다. Embodiments of the invention are shown by way of example and not by way of limitation in the figures of the drawings in which like reference numerals refer to like elements.
1 shows a block diagram of a microprocessor in which at least one embodiment of the invention may be used.
2 shows a block diagram of a shared bus computer system in which at least one embodiment of the invention may be used.
3 shows a block diagram of a point-to-point interconnect computer system in which at least one embodiment of the invention may be used.
4 shows a block diagram of a multi-core microprocessor in which at least one embodiment of the invention may be used.
5 shows a possible implementation of a secure enclave (SE) in one embodiment of the invention.
6 shows a block diagram of a microprocessor in which at least one embodiment of the invention may be used.
7 shows an example of a control structure for accessing a portion of an enclave page cache that may be implemented in one embodiment of the invention.
8 shows an example of a thread control structure in one embodiment of the present invention showing how the data structures are stitched together.
Figure 9 illustrates one step of a software attestation process known as quoting, which may be found in one embodiment of the present invention.
10 illustrates steps for making a quart from a set of measurement resists in one embodiment of the invention.
11 illustrates an EADD process of updating the measurement register MR_EADD in one embodiment of the present invention.
12 illustrates EREPORT for generating a report in one embodiment of the present invention.
Figure 13 illustrates a response-protection mechanism found in one embodiment of the present invention.
14 shows an example of the MAC tree structure portion of the response-protection mechanism found in one embodiment of the present invention.
15 illustrates how a page fault error code map may be implemented in one embodiment of the invention.
16 shows an example of a process for creating a permit to launch an enclave in one embodiment of the present invention.
Figure 17 illustrates a possible implementation of the platform key hierarchy for a single package secure enclave for one embodiment of the present invention.
18 illustrates an example of a microcode based secure enclave key hierarchy in one embodiment of the present invention.
19 is a diagram of an enclave CTL_MSR register that may be found in one embodiment of the present invention.
20 illustrates a cryptographic blockchain algorithm used in one embodiment of the present invention.
21 is a flow diagram illustrating encryption of a single AES block in one embodiment of the present invention.
FIG. 22 is a flow diagram illustrating an example of encryption of multiple AES blocks using a cryptographic blockchain algorithm as implemented in one embodiment of the invention.
FIG. 23 illustrates an interrupt stack and application after an interrupt with a stack switch in one embodiment. FIG.
FIG. 24 illustrates a possible method for implementing a stack of multiple state save area slots in one embodiment of the present invention.
Figure 25 illustrates a portion of a state machine going through state transitions for interrupts, faults, and traps in one embodiment of the present invention.
26 shows a processor package for a digital random number generator for one embodiment of the present invention.
27 shows debug register DR7 2700 for one embodiment of the present invention.

본 발명의 실시예는 보안 애플리케이션 및 데이터를 유연하지만 신뢰성 있는 방식으로 제공하는 기술에 관한 것이다. 본 발명의 다수의 양상들의 다수의 실시예가 있지만, "Secure Enclaves Architecture"라는 이름으로 첨부된 문서가 여기서 적어도 하나의 실시예의 예로서 참조로서 통합된다. 그러나, 통합된 참조는 본 발명의 실시예의 범위를 어떠한 방식으로든 한정하고자 하는 것은 아니며, 본 발명의 사상 및 범위 내에 있는 다른 실시예들이 사용될 수 있다.Embodiments of the present invention relate to techniques for providing secure applications and data in a flexible but reliable manner. Although there are numerous embodiments of many aspects of the present invention, the document attached with the name "Secure Enclaves Architecture" is incorporated herein by reference as an example of at least one embodiment. However, the integrated reference is not intended to limit the scope of the embodiments of the invention in any way, and other embodiments within the spirit and scope of the invention may be used.

도 1은 본 발명의 적어도 하나의 실시예가 사용될 수 있는 마이크로프로세서를 도시한다. 특히, 도 1은 하나 이상의 프로세서 코어(105 및 110)를 갖는 마이크로프로세서(100)를 도시하며, 여기서 각각의 프로세서 코어는 로컬 캐시(107 및 113)와 각각 연관되어 있다. 도 1에는, 로컬 캐시(107 및 113) 각각에 저장된 적어도 일부의 정보의 버전을 저장할 수 있는 공유 캐시 메모리(115)가 도시되어 있다. 몇몇 실시예에서, 마이크로프로세서(100)는 또한 도 1에는 도시되지 않은 집적 메모리 컨트롤러, 집적 그래픽 컨트롤러 같은 다른 로직뿐만 아니라, I/O 제어와 같은 컴퓨터 시스템 내의 다른 기능을 수행하는 다른 로직을 포함할 수 있다. 일 실시예에서, 멀티-프로세서 시스템 내의 각각의 마이크로프로세서 또는 멀티-코어 프로세서 내의 각각의 프로세서 코어는 적어도 일 실시예에 따라 보안 엔클레이브 기술(secure enclave technique)을 가능하게 하는 로직(119)을 포함하거나 그렇지 않으면 그와 연관되어 있다. 로직은 몇몇 종래의 구현예에서 보다 복수의 코어 또는 프로세서 중에서의 더 효율적인 자원 할당을 가능하게 하는 회로, 소프트웨어(유형의 매체에 구체화됨)를 포함할 수 있다.1 illustrates a microprocessor in which at least one embodiment of the invention may be used. In particular, FIG. 1 shows a microprocessor 100 having one or more processor cores 105 and 110, where each processor core is associated with a local cache 107 and 113, respectively. In FIG. 1, a shared cache memory 115 is shown that can store a version of at least some information stored in each of the local caches 107 and 113. In some embodiments, microprocessor 100 may also include other logic such as integrated memory controllers, integrated graphics controllers, not shown in FIG. 1, as well as other logic to perform other functions within a computer system, such as I / O control. Can be. In one embodiment, each microprocessor in a multi-processor system or each processor core in a multi-core processor includes logic 119 that enables a secure enclave technique in accordance with at least one embodiment. Or otherwise associated with it. The logic may include circuitry, software (embodied in a type of medium) that allows for more efficient resource allocation among a plurality of cores or processors than in some conventional implementations.

도 2는, 예를 들면, 본 발명의 일 실시예가 사용될 수 있는 FSB(front-side-bus)를 도시한다. 임의의 프로세서(201, 205, 210 또는 215)는 프로세서 코어(223, 227, 233, 237, 243, 247, 253, 257) 중 하나 내에 있거나 그렇지 않으면 그와 연관된 임의의 로컬 레벨 원(L1) 캐시 메모리(220, 225, 230, 235, 240, 245, 250, 255)으로부터의 정보를 액세스할 수 있다. 더욱이, 임의의 프로세서(201, 205, 210 또는 215)는 공유 레벨 투(L2) 캐시(203, 207, 213, 217) 중 임의의 하나로부터의 정보 또는 칩셋(265)을 경유하여 시스템 메모리(260)로부터의 정보를 액세스할 수 있다. 도 2의 하나 이상의 프로세서는 적어도 일 실시예에 따라 보안 엔클레이브 기술을 가능하게 하는 로직(219)을 포함하거나 그와 연관될 수 있다.2 illustrates, for example, a front-side-bus (FSB) in which one embodiment of the present invention may be used. Any processor 201, 205, 210, or 215 is any local level one (L1) cache within or otherwise associated with one of the processor cores 223, 227, 233, 237, 243, 247, 253, 257. Information from the memories 220, 225, 230, 235, 240, 245, 250, 255 can be accessed. Moreover, any processor 201, 205, 210, or 215 may be configured to include system memory 260 via chipset 265 or information from any one of the shared level to L2 caches 203, 207, 213, and 217. Information can be accessed. One or more processors of FIG. 2 may include or be associated with logic 219 to enable secure enclave techniques, according to at least one embodiment.

도 2에 도시된 FSB 컴퓨터 시스템에 부가하여, 포인트 대 포인트(P2P) 상호접속 시스템 및 링(ring) 상호접속 시스템을 포함하는 다른 시스템 구성이 본 발명의 다양한 실시예와 결합하여 사용될 수 있다. 예를 들면, 도 3의 P2P 시스템은 몇개의 프로세서를 포함할 수 있으며, 그 중 단지 두 개, 프로세서(370, 380)만이 예로서 도시되어 있다. 프로세서(370, 380)는 각각 메모리(32, 34)와 접속하기 위한 로컬 메모리 컨트롤러 허브(MCH)(372, 382)를 포함할 수 있다. 프로세서(370, 380)는 PtP(point-to-point) 인터페이스 회로(378, 388)를 사용하여 PtP 인터페이스(350)를 통해 데이터를 교환할 수 있다. 프로세서(370, 380)는 포인트 대 포인트 인터페이스 회로(376, 394, 386, 398)를 사용하여 개별 PtP 인터페이스(352, 354)를 통해 칩셋(390)과 데이터를 각각 교환할 수 있다. 칩셋(390)은 또한 고성능 그래픽 인터페이스(339)를 통해 고성능 그래픽 회로(338)와 데이터를 교환할 수 있다. 본 발명의 실시예는 임의의 수의 프로세싱 코어를 가는 임의의 프로세서 내에, 또는 도 3의 PtP 버스 에이전트 각각 내에 위치될 수 있다. 일 실시예에서, 임의의 프로세서 코어는 로컬 캐시 메모리(도시 생략)를 포함하거나 그와 연관될 수 있다. 더욱이, 공유 캐시(도시 생략)는, 프로세서가 저전력 모드에 놓여 있다면 하나 또는 두 개의 프로세서의 로컬 캐시 정보가 공유 캐시에 저장될 수 있도록, 두 개의 프로세서 외부의 어느 한 프로세서에 포함되거나, p2p 상호접속을 통해 프로세서들과 또한 접속될 수 있다. 도 3의 하나 이상의 프로세서 또는 코어는 적어도 하나의 실시예에 따라 보안 엔클레이브 기술을 가능하게 하는 로직(319)을 포함하거나 그와 연관될 수 있다.In addition to the FSB computer system shown in FIG. 2, other system configurations, including point-to-point (P2P) interconnect systems and ring interconnect systems, may be used in conjunction with various embodiments of the present invention. For example, the P2P system of FIG. 3 may include several processors, only two of which are shown as examples. The processors 370 and 380 may include local memory controller hubs (MCHs) 372 and 382 for connecting with the memory 32 and 34, respectively. Processors 370 and 380 may exchange data over PtP interface 350 using point-to-point interface circuits 378 and 388. Processors 370 and 380 may exchange data with chipset 390 via separate PtP interfaces 352 and 354 using point-to-point interface circuits 376, 394, 386 and 398, respectively. Chipset 390 may also exchange data with high performance graphics circuitry 338 via high performance graphics interface 339. Embodiments of the present invention may be located in any processor running any number of processing cores, or in each of the PtP bus agents of FIG. In one embodiment, any processor core may include or be associated with a local cache memory (not shown). Moreover, a shared cache (not shown) may be included in either processor outside of the two processors or the p2p interconnect so that local cache information of one or two processors may be stored in the shared cache if the processor is in a low power mode. It may also be connected to the processors through. One or more processors or cores of FIG. 3 may include or be associated with logic 319 to enable secure enclave techniques, in accordance with at least one embodiment.

적어도 하나의 실시예의 하나 이상의 양상은, 머신에 의해 판독될 때 머신으로 하여금 여기서 설명된 기능을 수행하는 로직을 생성하게 하는, 프로세서 내의 다양한 로직을 나타내는 머신 판독가능 매체 상에 저장된 대표 데이터에 의해 구현될 수 있다. "IP 코어"로 알려진 그러한 표현은 유형의 머신 판독가능 매체("테이프")에 저장될 수 있고, 실제로 로직 또는 프로세서를 제조하는 제조 머신으로 로딩하기 위해 다양한 제조 설비 또는 고객에게 공급될 수 있다.One or more aspects of at least one embodiment are implemented by representative data stored on a machine readable medium representing various logic within a processor that, when read by the machine, causes the machine to generate logic to perform the functions described herein. Can be. Such representations, known as "IP cores", may be stored in tangible machine readable media ("tape") and supplied to various manufacturing facilities or customers for loading into a manufacturing machine that actually manufactures the logic or processor.

따라서, 마이크로-아키텍처 메모리 영역 액세스를 위한 방법 및 장치가 설명되었다. 전술한 설명은 예를 의도한 것이지 제한적인 것은 아니라는 것이 이해되어야 한다. 상기 설명을 읽고 이해함으로써 당업자에게는 다른 많은 실시예가 가능하다는 것이 자명해질 것이다. 본 발명의 범위는, 따라서, 첨부된 청구범위, 및 그러한 청구범위의 권리가 부여되는 균등물의 전체 범위와 함께 결정될 수 있다.Thus, a method and apparatus for micro-architecture memory region access have been described. It is to be understood that the foregoing description is intended to be illustrative, and not restrictive. It will be apparent to those skilled in the art that many other embodiments are possible by reading and understanding the above description. The scope of the invention, therefore, may be determined with the appended claims and the full scope of equivalents to which such claims are entitled.

보안 엔클레이브는 OS 프로세스의 맥락에서 애플리케이션이 코드를 실행하고 데이터를 내부에 저장하는 안전한 장소를 제공하는 명령어들의 세트이다. 이러한 환경에서 실행되는 애플리케이션을 엔클레이브라고 칭한다. 엔클레이브는 EPC(Enclave Page Cache)로부터 실행된다. 엔클레이브 페이지는 OS에 의해 EPC로 로딩된다. 엔클레이브의 페이지가 EPC로부터 제거될 때마다, 엔클레이브의 신뢰성을 보호하고 엔클레이브가 EPC로 다시 로딩될 때 탬퍼링(tampering)을 검출하기 위해 암호 보호가 사용된다. EPC 내부에서, 엔클레이브 프로세서에 의해 제공되는 액세스 제어 메커니즘을 사용하여 보호된다. 아래의 표 2-1은 비특권 엔클레이브 명령어(non privileged enclave instruction)의 완전한 리스트를 제공한다.A secure enclave is a set of instructions that provides a safe place for an application to execute code and store data internally in the context of an OS process. Applications running in this environment are called enclaves. The enclave runs from the Enclave Page Cache (EPC). The enclave page is loaded into the EPC by the OS. Whenever a page of an enclave is removed from an EPC, password protection is used to protect the trustworthiness of the enclave and to detect tampering when the enclave is loaded back into the EPC. Inside the EPC, it is protected using the access control mechanism provided by the enclave processor. Table 2-1 below provides a complete list of non privileged enclave instructions.

[표 2-1]TABLE 2-1

이들 명령어도 링 3에서만 실행할 것이다. 다른 모든 시간에 그들은 #UD 폴트를 생성할 것이다. 표 2-2는 특권 명령어의 리스트를 제공한다.These commands will also run only in ring 3. At all other times they will generate a #UD fault. Table 2-2 provides a list of privileged commands.

[표 2-2]Table 2-2

EPC(Enclave Page Cache)는 엔클레이브 코드가 실행되고 보호된 엔클레이브 데이터가 액세스되는 곳이다. EPC는 플랫폼의 물리적 어드레스 공간 내에 위치되지만, 단지 SE 명령어들을 이용해서만 액세스될 수 있다. EPC는 상이한 많은 엔클레이브로부터의 페이지들을 포함할 수 있지만, 페이지들의 무결성 및 신뢰성을 보호하기 위한 액세스 제어 메커니즘을 제공한다. 페이지 캐시는 플랫폼의 코히런트 물리 메모리용으로 사용되는 것과 유사한 코히런시 프로토콜을 유지한다. Enclave Page Cache (EPC) is where enclave code executes and protected enclave data is accessed. The EPC is located within the platform's physical address space, but can only be accessed using SE instructions. The EPC may include pages from many different enclaves, but provides an access control mechanism to protect the integrity and reliability of the pages. The page cache maintains a coherency protocol similar to that used for the platform's coherent physical memory.

EPC는 몇가지 방법으로 인스턴스화(instantiated)될 수 있다. 이것은 프로세서 패키지 상의 전용 SRAM으로 구성될 수 있다. 바람직한 구현 메커니즘으로는 Crypto Memory Aperture가 알려져 있다. 이 메커니즘은 EPC가 크게 되게 할 수 있다. CMA의 보다 상세한 설명이 아래의 섹션에 설명된다.EPC can be instantiated in several ways. This may consist of dedicated SRAM on the processor package. Crypto Memory Aperture is known as a preferred implementation mechanism. This mechanism can make EPC large. A more detailed description of the CMA is described in the sections below.

EPCM(Enclave Page Cache Map)은 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 a page is removed from the EPC, status information is also sent and protected using cryptographic means. When the enclave page is loaded back into the EPC, the status information is verified.

도 4는 본 발명의 적어도 일 실시예가 사용될 수 있는 멀티-코어 마이크로프로세서(499)의 블록도를 도시한다. 마이크로프로세서(499)는 다수의 코어(400, 420)를 포함할 수 있다. 하나의 코어(400)는 CR3(402), SMBR(404), 페이지-미스 핸들러(408), PMHE(410), 및 변환 색인 버퍼(412)를 포함한다. 하나의 코어(420)smms CR3(422), SMBR(424), 페이지-미스 핸들러(428), PMHE(430), 및 변환 색인 버퍼(432)를 포함한다. 마이크로프로세서(499)는, 본 발명의 일 실시예에서, 코어(400)와 코어(420) 사이에 공유되는 레벨-1 캐시(440)를 포함한다. 레벨-1 캐시(440)는 데이터를 마지막 레벨 캐시(445)로 그리고 그로부터 데이터를 전달할 수 있다. 홈 에이전트(450)는 마지막 레벨 캐시(445)에 접속되고 암호 엔진(452)에 부착될 수 있다. 홈 에이전트(450)는 메모리 컨트롤러(454)를 통해 암호 메모리 어퍼처(crypto memory aperture; 480)의 물리 어드레스 공간(488)을 표명할 수 있다. 암호 메모리 어퍼처(480)는 엔클레이브 페이지 캐시(482), 엔클레이브 페이지 캐시 맵(484), 보조 기억 장치(backing store; 486)을 물리 어드레스 공간(488)의 일부로서 포함한다.4 shows a block diagram of a multi-core microprocessor 499 in which at least one embodiment of the present invention may be used. Microprocessor 499 may include a number of cores 400, 420. One core 400 includes a CR3 402, an SMBR 404, a page-miss handler 408, a PMHE 410, and a translation index buffer 412. One core 420 includes a sms CR3 422, an SMBR 424, a page-miss handler 428, a PMHE 430, and a translation index buffer 432. Microprocessor 499 includes, in one embodiment of the present invention, a level-1 cache 440 shared between core 400 and core 420. Level-1 cache 440 may transfer data to and from the last level cache 445. The home agent 450 may be connected to the last level cache 445 and attached to the crypto engine 452. The home agent 450 may assert the physical address space 488 of the crypto memory aperture 480 through the memory controller 454. The cryptographic memory aperture 480 includes an enclave page cache 482, an enclave page cache map 484, and a backing store 486 as part of the physical address space 488.

CMA는 EPC, EPCM, 및 다른 SE 관련 구조를 인스턴스화하기 위한 지원을 제공하는 메커니즘이다. 어퍼처는 이러한 사용을 위해 예비되는 물리 어드레스 공간 영역이다.CMA is a mechanism that provides support for instantiating EPC, EPCM, and other SE related structures. The aperture is a physical address space area that is reserved for this use.

EPC 및 EPCM(뿐만 아니라 다른 구현 데이터 구조)는 어퍼처 내부의 위치에 매핑된다. 보조 기억 장치는 이들 자원을 위한 실제 데이터이다. EPC에 대한 메모리 요청이 생성될 때, CMA는 암호화된 EPC 데이터를 포함하는 보조 기억 장치 위치로 재매핑하고 데이터를 검색한다.EPC and EPCM (as well as other implementation data structures) are mapped to locations inside the aperture. Auxiliary storage is the actual data for these resources. When a memory request for an EPC is made, the CMA remaps and retrieves the data to an auxiliary storage location that contains encrypted EPC data.

일반적으로, 대부분의 SE는 마이크로코드 또는 확장 마이크로코드로 구현된다. CMA, 패키지 외부 및 코어 내에서의 데이터 이동을 제어하는 로직을 포함하는 몇몇의 장소에 요구되는 하드웨어 지원이 있다.In general, most SEs are implemented in microcode or extended microcode. There is hardware support required in several places, including logic to control data movement within the CMA, outside the package, and within the core.

도 5는 본 발명의 일 실시예에서의 보안 엔클레이브의 가능한 구현예를 도시한다. 운영 시스템 및 VMM(542)는 ELPG 명령어(540)를 사용하여 엔클레이브(532) 내의 엔클레이브 페이지를 엔클레이브 페이지 캐시(544)에 로딩할 수 있다. 마이크로프로세서가 엔클레이브(532) 내에서 실행되지 않을 때, 엔클레이브 페이지 캐시(544)는 SERR 레지스터(548)에 의한 소프트웨어 액세스로부터 보호된다. 엔클레이브 내부에서 실행될 때, 마이크로코드 페이지 테이블은 보호(546)를 제공한다. 각각의 VM은 관계된 VMCS를 구비한다. VM(510)은 VMCS(515)에 접속된다. VM(520)은 VMCS(525)에 접속된다. VM(530)은 VMCS(535)에 접속된다. SMM(500)은 개별의 콘테이너 내에 있을 수 있고, 프로세서 상태는 개별 콘테이너 내에 있을 수 있다.5 illustrates a possible implementation of a secure enclave in one embodiment of the present invention. The operating system and the VMM 542 can load the enclave page in the enclave 532 into the enclave page cache 544 using the ELPG instruction 540. When the microprocessor is not running within enclave 532, enclave page cache 544 is protected from software access by SERR register 548. When executed inside an enclave, the microcode page table provides protection 546. Each VM has an associated VMCS. The VM 510 is connected to the VMCS 515. The VM 520 is connected to the VMCS 525. The VM 530 is connected to the VMCS 535. The SMM 500 can be in a separate container and the processor state can be in a separate container.

도 5는 보안 엔클레이브 구현의 일 실시예의 고레벨 개관이다. 이 구현예에서, EPC는 마이크로코드에 의해 관리되는 개별 콘텐이너로서 유지된다. 콘테이너는 엔클레이브 내부에서 실행되지 않을 때 액세스할 수 없다. 엔클레이브에 들어가면, 개별 콘테이너에 포함된 제어가 EPC 내부의 엔클레이브 코드로 전송된다.5 is a high level overview of one embodiment of a secure enclave implementation. In this embodiment, the EPC is maintained as an individual container managed by microcode. The container cannot be accessed when it is not running inside the enclave. Upon entering the enclave, control contained in the individual container is transferred to the enclave code inside the EPC.

엔클레이브의 내부에서 실행되는 동안 발생하는 임의의 페이지 폴트 또는 예외는 마이크로코드에 의해 담당 OS 또는 VMM으로 반영된다. 머신이 엔클레이브 내부에서 실행되지 않는 경우에는, SERR(SE range register)에 의해 액세스 제어가 EPC에 제공된다. 머신이 내부에서 실행되는 경우에, 마이크로코드는 실행되는 엔클레이브에 속하지 않는 다른 EPC 엔트리로의 액세스를 방지하는 페이지 테이블 레벨 보호를 제공한다.Any page fault or exception that occurs while running inside an enclave is reflected by the microcode to the responsible OS or VMM. If the machine is not running inside the enclave, access control is provided to the EPC by the SE range register (SERR). When the machine is running internally, the microcode provides page table level protection that prevents access to other EPC entries that do not belong to the enclave being executed.

보안 엔클레이브를 구현하기 위한 하나의 옵션은 몇몇 프로세서에서 마이크로코드 능력을 사용하여 보호 및 명령어를 구현하는 것이다. 이 능력은 보안 엔클레이트 자신을 목적을 충족하기 위해 요구하는 보안 요구사항을 만족시킬 수 있다.One option for implementing secure enclaves is to implement protection and instructions using microcode capability on some processors. This ability can meet the security requirements of the security enclosure itself to meet its objectives.

도 202에 도시된 바와 같은 SERR 레지스터는 PMH(Page Miss Handler)에서 구현된다. 레지스터는 각각의 로직 프로세서에 대해 독립적으로 인에이블되고 디스에이블될 수 있다.The SERR register as shown in FIG. 202 is implemented in a page miss handler (PMH). The registers can be enabled and disabled independently for each logic processor.

성능을 향상시키기 위한 구현예에서의 하나의 옵션은 엔클레이브 또는 특정 엔클레이브용인 TLB(Translation Lookaside Buffer) 내의 엔트리를 표시하기 위한 비트 또는 몇몇 비트를 제공하는 것이다. 이들 비트가 제공되지 않는다면, 다른 코드가 그 엔클레이브를 액세스하는 것을 방지하기 위해 그 엔클레이브를 나갈 때 TLB 플러시(flush)가 필요하게 될 것이다.One option in an implementation to improve performance is to provide a bit or some bit to indicate an entry in an Translation Lookaside Buffer (TLB) for an enclave or a specific enclave. If these bits are not provided, a TLB flush will be required when leaving the enclave to prevent other code from accessing the enclave.

엔클레이브 비트는 엔클레이브 모드 비트에 비교된다. 여분의 비트는 엔클레이브 공간 id 기능을 제공할 수 있다. 특정 엔클레이브에 id가 할당될 수 있다. id는 실행중인 엔클레이브의 id와 어드레스 검사의 일부로서 비교될 수 있다. TLB 지원은 선택적인 성능 강화이다. EPC 데이터의 제거로 인해 엔트리가 TLB에서 무효로 될 수 있을 때 특정 마이크로코딩된 셧다운 메커니즘이 필요하게 된다. 일 실시예에서, 마이크로코드는 엔클레이브 신뢰 경계 내의 모든 다른 코어와 접속하고 엔트리가 임의의 TLB에 더 이상 존재하지 않는다는 것을 검증할 수 있다. 다른 실시예들은 다른 프로세서가 TLB 엔트리를 무효로 하였다는 것을 마이크로코드가 보장받도록 하기 위한 수단을 제공할 수 있다. The enclave bit is compared to the enclave mode bit. The extra bits may provide the enclave space id function. An id may be assigned to a particular enclave. The id can be compared as part of the address check with the id of the running enclave. TLB support is an optional performance boost. The removal of EPC data requires a specific microcoded shutdown mechanism when entries can be invalidated in the TLB. In one embodiment, the microcode may connect with all other cores within the enclave trust boundary and verify that the entry no longer exists in any TLB. Other embodiments may provide a means for the microcode to ensure that another processor has invalidated the TLB entry.

DMA 스누프(snoop)를 방지하고, EPC에게 특정 SAD 및/또는 TAD를 무효화하기 위해 엔트리가 제공된다. 이들 전용 레지스터는 EPC의 보호를 제공한다. 이것은 SSERR과 동일 값으로 설정된다.Entries are provided to prevent DMA snoops and to invalidate certain SADs and / or TADs to the EPC. These dedicated registers provide protection of the EPC. This is set to the same value as SSERR.

각각의 엔클레이브에 대한 보안 키를 보장하기 위해, 보안 엔클레이브 마이크로코드는 일 실시예에서 난수로의 보안 액세스를 사용할 수 있다.To ensure a security key for each enclave, the secure enclave microcode may use secure access to random numbers in one embodiment.

엔클레이브는 탬퍼링에 대해 보호될 수 있다. 탬퍼링 보호를 위해 사용되는 메커니즘의 상세는 구현예에 의해 가변한다. 엔클레이브가 탬퍼링될 때, 이것은 탬퍼링이 감지된 스레드 상에서의 추가의 실행을 방지할 것이다. 사용자가 엔클레이브의 상태를 이해하도록 하기 위해, 엔클레이브 구축의 증명을 제공하기 위해 실행되는 인증 메커니즘이 있다. 이것은 엔클레이브 콘텐츠에 정보를 제공하는데 사용되는 EREPORT 명령어를 포함한다.The enclave may be protected against tampering. The details of the mechanism used for tampering protection vary by implementation. When the enclave is tampered, this will prevent further execution on the thread on which tampering was detected. To allow the user to understand the state of the enclave, there is an authentication mechanism implemented to provide proof of enclave construction. This includes the EREPORT command used to provide information to the enclave content.

엔클레이브 디자인에서 요구되는 마이크로코드 코드를 간략히 하기 위해, 구조적 엔클레이브의 개념이 개발되었다. 이들 엔클레이브에는 그 엔클레이브를 위한 코드의 오리지널에 기초하여 부여된 특정 액세스 특권이 있다.To simplify the microcode code required in enclave design, the concept of structural enclave was developed. These enclaves have certain access privileges granted based on the original of the code for that enclave.

전력 사이클 동안의 엔클레이브 상태는 소프트웨어 정책에 의존한다. CMA 내부의 데이터는 전력이 셧다운되면 손실된다. 소프트웨어는, 엔클레이브를 유지하고 싶어하면, 전력 사이클 동안 엔클레이브 데이터가 손실되지 않게 하는 것을 보장할 수 있다. EPC에 상주하는 데이터는, 소프트웨어가 S3 전력 상태에 걸쳐 엔클레이브를 활성(alive)으로 유지하고 싶으면 메모리로 플러싱될 수 있다. 소프트웨어는 전력이 제거될 때 애플리케이션이 모든 엔클레이브를 분해하는 하는 것을 요구하도록 선택할 수 있다. The enclave state during the power cycle depends on the software policy. Data inside the CMA is lost when the power is shut down. The software can ensure that enclave data is not lost during the power cycle if it wishes to maintain the enclave. Data residing in the EPC may be flushed into memory if the software wants to keep the enclave active across the S3 power state. The software can choose to require the application to disassemble all enclaves when power is removed.

엔클레이브는 자신의 위치에 따라 상이하게 보호된다. CPU 패키지 외부의 데이터는 암호화 및 무결성 검사을 사용하여 보호된다. 엔클레이브 페이지 캐시 내의 코드 및 데이터에 대해서, 페이지는 액세스 제어 메커니즘을 사용하여 보호된다.Enclaves are protected differently depending on their 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 an access control mechanism.

도 6은 본 발명의 적어도 일 실시예가 사용될 수 있는 마이크로프로세서의 블록도를 도시한다. 도 6은 다수의 프로세서 코어(600, 605, 610, 615) 및 캐시(620)를 구비하는 마이크로프로세서(600)를 도시한다. 엔클레이브 데이터(635)가 보호될 수 있다. 암호 메모리 어퍼처 데이터(630)를 사용하여 엔클레이브 데이터(635)를 보호한다.6 shows a block diagram of a microprocessor in which at least one embodiment of the invention may be used. 6 shows a microprocessor 600 having a number of processor cores 600, 605, 610, 615 and cache 620. Enclave data 635 may be protected. Encrypted memory aperture data 630 is used to protect enclave data 635.

시스템 메모리에 상주하는 엔클레이브 페이지는 암호화 및 무결성을 사용하여 보호된다. 페이지를 EPC로 로딩하는 동안, 페이지는 EPC에 카피되고, 암호해독되며, 페이지의 무결성이 검사된다. 도 6은 데이터의 이러한 부분을 도시한다.Enclave pages residing in system memory are protected using encryption and integrity. While loading a page into the EPC, the page is copied into the EPC, decrypted, and the integrity of the page is checked. 6 illustrates this portion of data.

EPC 내부에 상주하는 엔클레이브 페이지가 시스템 메모리에 저장될 때, 엔클레이브 키로 암호화된다. 페이지 저장과 동시에 인증 정보도 저장된다. EPC 내부의 엔클레이브 데이터는 액세스 제어 메커니즘에 의해 암호해독되고 보호된다. 프로세서는, 그 데이터를 소유하는 엔클레이브만이 그것을 액세스할 수 있도록 이 데이터를 보호한다.When an enclave page residing inside the EPC is stored in system memory, it is encrypted with an enclave key. In addition to storing the page, authentication information is also stored. Enclave data inside the EPC is decrypted 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 an enclave page residing in the EPC is evicted from the cache into main memory outside the CPU package, it is protected by CMA encryption. CMA will provide data reliability by encrypting data. The integrity of the EPC is provided by a range register that prevents reading and writing to the EPC.

도 7은 본 발명의 일 실시예에서 구현될 수 있는 엔클레이브 페이지 캐시의 일부를 액세스하기 위한 제어 구조의 예를 도시한다. 엔클레이브 페이지 캐시(720)의 각각의 페이지는 엔클레이브 페이지 캐시 맵(710)에 대응하는 메타데이터를 가질 수 있다. 메타데이터가 도 7에 도시되어 있고, 선형 어드레스의 세트(700)를 포함하는 보안 엔클레이브는, 선형 어드레스가 엔클레이브 페이지 캐시 맵(710) 내에 저장된 선형 어드레스에 정합할 때, 엔클레이브 페이지 캐시(720)에 저장된 데이터를 액세스할 수 있다.7 shows an example of a control structure for accessing a portion of an enclave page cache that may be implemented in one embodiment of the invention. Each page of enclave page cache 720 may have metadata corresponding to enclave page cache map 710. 7, and the secure enclave containing the set of linear addresses 700, when the linear address matches a linear address stored in the enclave page cache map 710, 720). &Lt; / RTI >

도 7은 EPC 및 EPCM의 레이아웃 및 사용을 도시한다. EPC는 4k 페이지로 분할된다. 각각의 엔클레이브는 EPC에 상주하는 페이지 중 몇몇을 가질 수 있다. 보안을 보장하는데 필요하게 되는 메타 정보를 제공하는 엔트리가 EPC의 각각의 페이지를 위해 EPCM에 존재한다. EPCM의 상세하는 특정한 구현예이다.7 shows the layout and use of EPC and EPCM. EPC is divided into 4k pages. Each enclave may have several of the pages residing in the EPC. There is an entry in the EPCM for each page of the EPC that provides the meta information needed to ensure security. Details of the EPCM are specific embodiments.

애플리케이션이 엔클레이브를 로딩하고자 할 때, OS 내의 시스템 루틴을 호출할 것이다. OS는 몇몇 페이지를 EPC에 할당하고자 시도할 것이다. 개방 스폿(open spot)이 없다면, OS는 희생 엔클레이브를 선택하여 제거할 것이다. OS는 각각의 페이지에 대해 EWBINVPG 명령어를 사용하여 희생 엔클레이브의 페이지를 퇴거시킬 것이다. OS가 퇴거를 완료하였을 때, ECREATE 커맨드를 사용하여 엔클레이브에 SECS(secure enclaves control structure)를 부가할 것이다. SECS가 생성된 후, OS는 애플리케이션에 의해 요청되는 바에 따라 EADDPRE 명령어를 사용하여 엔클레이브에 페이지를 부가할 것이다.When an application wants to load an enclave, it will call system routines within the OS. The OS will attempt to allocate some pages to the EPC. If there is no open spot, the OS will select and remove the victim enclave. The OS will retire the victim enclave's page using the EWBINVPG instruction for each page. When the OS completes the eviction, it will use the ECREATE command to add a secure enclaves control structure (SECS) to the enclave. After the SECS is generated, the OS will add the page to the enclave using the EADDPRE instruction as requested by the application.

데이터 페이지를 엔클레이브에 부가하기 위해, OS는 EADDSMAP 명령어를 사용하여 SMAP 페이지를 엔클레이브에 우선적으로 부가할 수 있다. 엔클레이브의 크기 및 레이아웃에 의존하여, OS는 몇몇의 SMAP 페이지를 부가할 것이다. 모든 엔클레이브 페이지가 엔클레이브에 부가되면, OS는 엔클레이브가 실행되게 하는 EINIT 명령어를 실행할 것이다. EINIT 명령어에 대한 파라미터는 엔클레이브가 그 머신 상에서 실행되도록 허여되는 것을 도모하는 퍼밋(permit)이다. 애플리케이션이 로딩될 때, 퍼밋이 생성될 필요가 있다. EINIT가 성공적으로 완료된 후, 애플리케이션은 엔클레이브에 들어가도록 EENTER 명령어를 실행할 수 있다.To add a data page to the enclave, the OS may preferentially add a SMAP page to the enclave using the EADDSMAP instruction. Depending on the size and layout of the enclave, the OS will add some SMAP pages. Once all enclave pages have been added to the enclave, the OS will execute the EINIT instruction that causes the enclave to run. The parameter to the EINIT instruction is a permit that allows the enclave to be allowed to run on that machine. When an application is loaded, a permit needs to be created. After EINIT completes successfully, the application can execute the EENTER instruction to enter the enclave.

엔클레이브가 구축되고 실행을 위해 마크(mark)되면, 애플리케이션은 엔클레이브 내부의 물리적 메모리를 부가하거나 뺄 필요가 있을 수 있다. 이것을 지원하기 위해, 부가의 메모리가 엔클레이브에 부가되게 할 수 있는 명령어가 존재한다. 메모리를 엔클레이브에 부가하기 위해, 메모리는 엔클레이브 내부의 올바른 선형 어드레스에 할당된다. OS는 이 메모리 페이지를 선형 어드레스를 나타내는 EPC로 카피한다. EADDPOST 명령어는 이 메모리를 엔클레이브에 부가하도록 실행된다. SMAP 노드가 EPC 내부에 상주하지 않는다면, 우선하여 로딩될 수 있다.Once the enclave is built and marked for execution, the application may need to add or remove physical memory inside the enclave. To support this, there is an instruction that can cause additional memory to be added to the enclave. To add memory to the enclave, the memory is allocated to the correct linear address inside the enclave. The OS copies this memory page into an EPC representing a linear address. The EADDPOST instruction is executed to add this memory to the enclave. If the SMAP node does not reside inside the EPC, it may be loaded first.

메모리가 카피된 후, 엔클레이브 소프트웨어는 내부에 액세스될 수 있기 전에 페이지를 수용할 수 있다. 엔클레이브는 EACCEPT 명령어를 실행함으로써 데이터를 수용한다. 이 명령어는 엔클레이브 내부의 소프트웨어에 의해서만 실행될 수 있다.After the memory is copied, the enclave software can accept the page before it can be accessed internally. The enclave accepts data by executing the EACCEPT instruction. This instruction can only be executed by software inside the enclave.

몇몇의 경우에, 소프트웨어는 엔클레이브 메모리의 특성을 수정하고자 원할 수 있다. 변경을 하기 위해, SMAP는 업데이트될 수 있다. 예를 들면, 소프트웨어는 또 다른 스레드 엔트리 포인트, 엔클레이브 내부의 TCS를 생성하고자 원할 수 있다. 이 경우, 엔클레이브는 OS가 EMODIFY 명령어를 사용하여 페이지의 SMAP 특성을 변경할 것을 요구한다. 특성이 변경된 후, 엔클레이브 소프트웨어는 페이지가 사용될 수 있도록 EACCEPT 명령어를 실행한다.In some cases, software may want to modify the characteristics of the enclave memory. To make the change, the SMAP can be updated. For example, software may want to create another thread entry point, a TCS inside an enclave. In this case, the enclave requires the OS to change the SMAP characteristics of the page using the EMODIFY instruction. After the property is changed, the enclave software executes the EACCEPT instruction to make the page available.

메모리 페이지가 엔클레이브로부터 제거될 수 있다. 엔클레이브가 페이지를 제거하고자 준비되면, 요청을 OS에 보낸다. OS는 SMAP로부터 페이지를 제거할 EREMOVE 명령어를 실행할 것이다. EREMOVE 명령어는 또한 EPC 엔트리를 무효화한다.Memory pages may be removed from the enclave. When the enclave is ready to remove the page, it sends a request to the OS. The OS will execute the EREMOVE command to remove the page from SMAP. The EREMOVE instruction also invalidates the EPC entry.

엔클레이브 환경의 무결성을 보장하기 위해, 다수의 액세스 검사가 행해질 수 있다. 다양한 보안 특성 중에서, 데이터가 엔클레이브 간에 누설되는 것을 방지하도록 데이터가 EPC에 올바르게 위치되어 있고, 코드가 엔클레이브 내의 상이한 선형 어드레스로 이동하지 않는 것을 보장하도록 참조 어드레스가 망가지지 않는 것이 강제된다.To ensure the integrity of the enclave environment, multiple access checks can be made. Among the various security features, it is enforced that the reference address is not broken to ensure that the data is correctly located in the EPC and that the code does not travel to a different linear address within the enclave to prevent data from leaking between enclaves.

범위 레지스터 및 마이크로코드 관리 새도우(shadow) 페이지 테이블을 이용하여 액세스 보호 요구가 구현될 수 있다. 또 다른 실시예에서, 새로우 페이지 테이블의 오버헤드를 피하기 위해, 동일한 액세스 제어 요구를 실행하도록 페이지 미스 핸들러 하드웨어가 수정될 수 있다. Access protection requests can be implemented using range registers and microcode management shadow page tables. In another embodiment, page miss handler hardware may be modified to execute the same access control request to avoid the overhead of the new page table.

EPC는, LP(logical processor)가 마이크로코드 확장 모드에서 실행되거나, 또는 LP가 엔클레이브 내부에서 실행되고 액세스되는 선형 어드레스가 그 엔클레이브에 의해 커버되는 선형 어드레스 범위에 속한다면 LP에 액세스할 수 있다. 환언하면, 단지 마이크로코드 확장 액세스 또는 엔클레이브 액세스만이 EPC 범위로 진행하는 것이 허가된다. EPC 범위로의 임의의 다른 액세스는 불법으로 고려된다.The EPC may access the LP if the logical processor (LP) runs in microcode extended mode, or if the linear address that LP runs inside and is accessed within the enclave falls within the linear address range covered by that enclave. . In other words, only microcode extended access or enclave access is allowed to go into the EPC range. Any other access to the EPC range is considered illegal.

엔클레이브 액세스는 EPC에 속하는 물리적 어드레스로 해결될 수 있다. 액세스가 EPC 외부로 벗어나지만 선형 어드레스가 엔클레이브 내부의 어드레스를 표시하면, 액세스는 중지될 수 있다. OS 또는 명령어에 대한 폴트(fault)가 보고된다.Enclave access may be resolved with a physical address belonging to the EPC. If the access deviates outside the EPC but the linear address indicates an address inside the enclave, the access may be suspended. The fault for the OS or command is reported.

엔클레이브 내의 어드레스로의 액세스는 계속해서 액세스하기 위해 EPC 내부에 위치될 수 있다. 엔트리가 EPC에 존재하는 검사는 일반적으로 유효 비트를 검증하기 위해 EPCM을 검사함으로써 행해진다. 각각의 EPC 페이지는 특정 엔클레이브로 지정된다. EPC 엔트리가 EPC 페이지를 소유하는 엔클레이브에 의해 단지 이루어 질 수 있다는 것을 참조하자. 이것은 참조되는 페이지가 실행 중인 엔클레이브의 SECS와 정합한다는 것을 유효화함으로써 검사된다.Access to addresses in the enclave can be located inside the EPC for continued access. Checking that an entry exists in the EPC is generally done by checking the EPCM to verify valid bits. Each EPC page is assigned a specific enclave. Note that an EPC entry can only be made by the enclave that owns the EPC page. This is checked by validating that the referenced page matches the SECS of the running enclave.

각각의 EPC 페이지는 엔클레이브에 대한 특정 선형 어드레스 페이지를 나타낸다. 요청되는 선형 어드레스는 EPC 내의 페이지의 선형 어드레스와 정합할 수 있다. 예를 들면, EPCM 엔트리는 엔클레이브 페이지가 EPC에 들어온(brought into) 선형 어드레스를 저장한다. 엔클레이브 액세스가 EPC 페이지로 리졸브(resolve)될 때, 페이지가 들어온 선형 어드레스는 현재의 요청의 선형 어드레스와 정합될 수 있다.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, an EPCM entry stores a linear address where the enclave page has brought into the EPC. When the enclave access resolves to an EPC page, the linear address from which the page came in may match the linear address of the current request.

엔클레이브의 선형 어드레스 매핑은 훼손될 수 없다. 선형 어드레스의 페이지 테이블이 훼손되면 그 결과의 액세스는 불법이다. 이것은 공격자가 코드 및 데이터를 엔클레이브 내부 주위에서 이동시키는 것을 방지한다.The linear address mapping of the enclave cannot be compromised. If the page table of the linear address is corrupted, the resulting access is illegal. This prevents an attacker from moving code and data around inside the enclave.

OS/VMM이 초기화된 후 페이지를 엔클레이브에 부가하면, EADDPOST 명령어는 그 페이지를 위해 EPCM에 "펜딩(pending)" 비트를 설정한다. 펜딩 비트는 (SEC_INFO를 사용하는) 후속의 EPC 재기록(wirte-back) 및 퇴거(eviction) 후까지 생존한다. 엔클레이브는 EACCEPT를 발행하여 펜딩 비트를 클리어할 수 있다. 엔클레이브 액세스가 펜딩 비트가 설정된 EPC 페이지로 리졸브되면, LP는 EF_PENDING 폴트를 OS/VMM에 발행한다.If a page is added to an enclave after the OS / VMM has been initialized, the EADDPOST instruction sets the "pending" bit in the EPCM for that page. The pending bit survives following subsequent EPC wipe-back and eviction (using SEC_INFO). The enclave may issue EACCEPT to clear the pending bit. If the enclave access resolves to an EPC page with the pending bit set, the LP issues an EF_PENDING fault to the OS / VMM.

OS/VMM이 응답 보호 엔클레이브 페이지를 EPC로 로딩하는 경우, 그 페이지를 위해 EPCM 엔트리에 FCR(Freshness Check Required) 비트를 설정한다. OS/VMM은 이 비트를 클리어하기 위해 그 EPC 페이지 상에 EUPSMAP 명령어를 실행함으로써 이 비트를 클리어할 수 있다. 엔클레이브 액세스는 그 페이지 상의 FCR 비트가 설정되지 않은 경우에만 계속해서 액세스하는 것이 허용된다. 그렇지 않으면, LP는 EF_FRESH_CHK 폴트를 OS/VMM으로 전달한다.When the OS / VMM loads a response protection enclave page into the EPC, it sets the Freshness Check Required (FCR) bit in the EPCM entry for that page. The OS / VMM can clear this bit by executing an EUPSMAP instruction on that EPC page to clear this bit. Enclave access is allowed to continue accessing only if the FCR bit on that page is not set. Otherwise, the LP forwards the EF_FRESH_CHK fault to the OS / VMM.

각각의 EPCM 엔트리는 엔클레이브가 그 페이지에 기록할 것을 허가받았는지를 나타내는 "더티(dirty)" 비트를 포함한다. 엔클레이브는 EPCM 내의 엔클레이브 페이지에 대한 더티 비트가 설정되어 있으면 그 엔클레이브 페이지에 기록할 것을 허가받는다. 그러한 경우가 아니라면, LP는 EF_EWRITE를 OS/VMM에 발행한다. OS/VMM은 그 페이지 상에 EUPSMAP 명령어를 실행함으로써 더티 비트를 설정할 수 있다.Each EPCM entry contains a "dirty" bit indicating whether the enclave is allowed to write to that page. The enclave is allowed to write to that enclave page if the dirty bit for the enclave page in the EPCM is set. If not, the LP issues EF_EWRITE to the OS / VMM. The OS / VMM can set the dirty bit by executing an EUPSMAP instruction on that page.

로직컬 프로세서가 엔클레이브 내부에서 실행되는 때는 언제나, 그 엔클레이브의 SECS 페이지가 EPC에 제공될 수 있다. 그러나, SE 보안 모델은 엔클레이브가 자기 자신의 SECS로의 임의의 직접적인 메모리 액세스를 하는 것을 허가받지 못할 수 있다는 것을 요구한다(그렇지 않으면, 엔클레이브는 보안을 완전히 상쇄하면서(compromising) 자기 자신의 엔클레이브 키를 판독할 수 있을 것이다). 엔클레이브 액세스가 그 엔클레이브에 대한 SECS를 예비하고 있는 그 EPC 페이지로 리졸브하면, OS/VMM에 EF_ATTRIB_SECS 폴트를 통해 통지된다. 엔클레이브는 TCS 속성 세트를 갖는 어떠한 페이지도 수정하는 것을 허가받지 못한다. 엔클레이브가 EPC로 로딩된 TCS를 수정하고자 시도한다면, OS/VMM에 EF_ATTRIB_TCS 폴트를 통해 통지된다.Whenever a logical processor runs inside an enclave, the SECS page of that enclave may be provided to the EPC. However, the SE security model requires that the enclave may not be allowed to make any direct memory access to its own SECS (otherwise the enclave would completely compromising its own enclave). Key will be read). When an enclave access resolves to its EPC page, which reserves SECS for that enclave, it is notified to the OS / VMM via the EF_ATTRIB_SECS fault. Enclaves are not allowed to modify any page with the TCS attribute set. If the enclave attempts to modify the TCS loaded into the EPC, the OS / VMM is notified via the EF_ATTRIB_TCS fault.

이하의 테이블의 크기 필드에서, 다음의 값 및 표시자가 사용된다:In the size fields of the following table, the following values and indicators are used:

4 32비트 및 64비트 모드에서의 4바이트 필드4 4-byte fields in 32-bit and 64-bit mode

8 32비트 및 64비트 모드에서의 8바이트 필드8-byte fields in 32-bit and 64-bit mode

8(4) 양쪽 모두에서의 8바이트 필드. 상위 4바이트는 32비트 모드에서는 무시된다.8 (4) 8 byte field on both sides. The upper 4 bytes are ignored in 32-bit mode.

주석: 몇몇의 필드는 하위 케이스 "0"에서 시작하는 이름(예를 들면, oLSP)를 갖는다. 이들 필드는 포인터이지만, 엔클레이브의 베이스에 대한 오프셋으로서 엔클레이브에 표시된다. 이 표현은 엔클레이브 페이지의 측정이 그 엔클레이가 생성되는 위치와는 독립적이라는 것을 보장한다.Note: Some fields have names (eg oLSP) starting at the lower case "0". These fields are pointers, but are indicated in the enclave as an offset to the base of the enclave. This representation ensures that the measurement of the enclave page is independent of where the enclave is generated.

주석: 필드는 (아직) 임의의 특정 순서로 설명되는 것은 아니다. 몇몇 필드는, 예를 들면, 상이한 보호 수단을 가능하게 하도록 자신들 각각의 데이터 구조 내의 상이한 메모리 p이지로 이동될 수 있다.Note: The fields are not (yet) described in any particular order. Some fields may, for example, be moved to different memory pages in their respective data structures to enable different protection means.

[표 4-1]Table 4-1

TCS(Thread Control Structure)는 각각의 스레드와 연관된다. TCS는 표 4-2 TCS 레이아웃을 포함한다.Thread Control Structure (TCS) is associated with each thread. The TCS includes the Table 4-2 TCS layout.

스레드 제어 구조Thread control structure

[표 4-2]Table 4-2

스레드 상태는 다음의 5개의 값 중 하나를 가질 수 있다.The thread state can have one of five values:

상태 저장 영역 오프셋(oSSA)State storage offset (oSSA)

상태 저장 영역 오프셋은 엔클레이브에서의 실행 중에 발생하는 인터럽트 또는 익셉션(exception) 시에 프로세서 상태를 저장하는데 사용되는 상태 저장 프레임의 스택을 가리킨다. NSSA(Next State Save Area)는 엔클레이브에서의 실행 중에 발생하는 인터럽트 또는 익셉션 시에 프로세서 상태를 저장할 곳을 결정하기 위해 인터럽트 마이크로코드에 의해 사용된다. 이것은 oSSA에 의해 어드레싱되는 프레임의 어레이로의 인덱스이다. CSSA(Count of Save Area)는 이 TCS에 대해 이용가능한 SSA 프레임의 수를 특정한다. 인터럽트 또는 익셉션이 발생하고 더 이상 SSA 프레임이 이용가능하지 않을 때(NSSA>=CSSA), 인터럽트 또는 익셉션은 여전히 발생하고 프로세서 상태는 클리어될 것이지만, TCS는 INVALID로서 마크될 것이다.State storage area offset refers to the stack of state storage frames used to store the processor state upon interruption or exception occurring during execution in the enclave. Next State Save Area (NSSA) is used by the interrupt microcode to determine where to store the processor state at interrupt or exception occurring during execution in the enclave. This is the index into the array of frames addressed by oSSA. The Count of Save Area (CSSA) specifies the number of SSA frames available for this TCS. When an interrupt or exception occurs and no longer an SSA frame is available (NSSA> = CSSA), the interrupt or exception will still occur and the processor state will be cleared, but the TCS will be marked as INVALID.

엔클레이브에서 실행 중에 발생하는 인터럽트에 대해, 머신 상태는 TCS::SSA(State Save Area)에서 저장될 것이다. 이 영역은 표 4-3. 인터럽트 저장 영역을 포함한다.For interrupts occurring during execution in an enclave, the machine state will be stored in TCS :: SSA (State Save Area). This area is shown in Table 4-3. Contains an interrupt storage area.

TCS::SSA는 인터럽트가 발생하는 시간에는 페이지 아웃(paged out)될 수 없다. EENTER는 SSA가 EPC 내부에 있고 물리 어드레스를 캐싱하는 것을 검사한다. 페이지가 퇴거되는 경우에, EWBINVPG를 실행하는 프로세서는 SSA를 사용하여 스레드를 현재 실행하는 프로세서 상에서 엔클레이브를 강제로 엑시트하고 페이지 폴트를 그에 보고한다.TCS :: SSA cannot be paged out at the time the interrupt occurs. EENTER checks that the SSA is inside the EPC and caches the physical address. If the page is retired, the processor running EWBINVPG uses the SSA to force the enclave exit on the processor currently executing the thread and report a page fault to it.

도 8은 모든 데이터 구조가 어떻게 함께 합쳐지는지를 보여준다. 클러터를 피하기 위해, 모든 스레드에 대해 퍼-스레드 구조(per-thread structure)가 전혀 도시되어 있지 않다. 비신뢰성 스택 및 그와 연관된 포인터 또한 생략된다. 도 8은 본 발명의 일 실시예에서, 저장 상태 영역이 어떻게 함께 합쳐지는지를 보여주는 스레드 제어 구조의 예를 도시한다. 상태 저장 영역 포인터(800)는 저장 영역 0(820)을 포인팅한다. 현재의 상태 저장 영역(805)은 저장 영역 1(824)을 포인팅한다. 그 다음 상태 저장 영역(810)은 그 다음 저장 영역(828)을 포인팅한다. 저장 상태 영역의 번호는 이용가능한 저장 상태 영역의 수의 참조를 제공한다.8 shows how all the data structures are merged together. To avoid clutter, no per-thread structure is shown for all threads. Unreliable stacks and their associated pointers are also omitted. 8 shows an example of a thread control structure showing how storage state regions are merged together in one embodiment of the invention. The state storage area pointer 800 points to storage area 0 820. Current state storage area 805 points to storage area 1 824. State storage area 810 then points to storage area 828. The number of storage state areas provides a reference to the number of storage state areas available.

페이지 정보(PAGE_INFO)는 EPC-관리 명령어에 대한 파라미터로서 사용되는 구조적 데이터 구조이다.Page information (PAGE_INFO) is a structured data structure used as a parameter for an EPC-management instruction.

[표 4-3]Table 4-3

SEC_INFO 플래그 및 EPC 플래그는 페이지의 유형을 나타내는 비트를 포함한다.The SEC_INFO flag and the EPC flag contain bits indicating the type of page.

SEC_INFO 플래그는 엔클레이브 페이지의 상태를 설명하는 비트들의 세트이다.The SEC_INFO flag is a set of bits describing the state of an enclave page.

[표 4-4]Table 4-4

보안 정보(SEC_INFO) 데이터 구조는 위조 방지에 필요한 암호화 메타-데이터를 유지한다.The security information (SEC_INFO) data structure holds cryptographic meta-data necessary for anti-counterfeiting.

[표 4-5]Table 4-5

인증(certificate; CERT)은 구조적 엔클레이브에 제공되고 EMKPERMIT로 보내지는 인증 구조이다. 이 구조는 4096 바이트이고 페이지 정렬될 수 있다.A certificate (CERT) is a certificate structure provided in a structural enclave and sent to EMKPERMIT. This structure is 4096 bytes long and can be page aligned.

[표 4-6]Table 4-6

퍼밋(PERMIT)은 EMKPERMIT 및 퍼밋 엔클레이브로부터 출력되었고 EINIT에 의해 소비되었다. 이것은 4096 바이트이고 페이지 정렬될 수 있다.PERMIT was output from EMKPERMIT and Permit Enclave and was consumed by EINIT. This is 4096 bytes and can be page aligned.

ERPORT 구조는 EREPORT 명령어의 출력이다.The ERPORT structure is the output of the EREPORT command.

[표 4-7]Table 4-7

측정(MEASUREMENTS)은 ERDMR 명령어의 출력 파라미터이다. 이것은 특정 SECS로부터 취해진, 엔클레이브의 측정 레지스터 값들을 포함한다.MEASUREMENTS is an output parameter of the ERDMR command. This includes the measurement register values of the enclave, taken from the particular SECS.

[표 4-8]Table 4-8

키 요청(KEY_REQUEST)는 EGETKEY 명령어에 대한 입력 파라미터이다. 이것은 그 키의 유도에 요구되는 임의의 부가 파라미터 및 적절한 키를 선택하는데 사용된다.The key request (KEY_REQUEST) is an input parameter for the EGETKEY command. This is used to select the appropriate key and any additional parameters required for derivation of that key.

[표 4-9]Table 4-9

[표 4-10]Table 4-10

[표 4-11]Table 4-11

이 구조는 엔클레이브 및 엔클레이브의 SE TCB의 보안 버전에 기초하여 키를 생성하도록 키 유도에 의해 사용된다. TCB 보안 버전 구조에 대한 보다 상세에 대한 Platform TCB Recovery Sepecification 참조.This structure is used by key derivation to generate a key based on the enclave and the secure version of the SE TCB of the enclave. See Platform TCB Recovery Sepecification for more details on the TCB security version structure.

[표 4-12]Table 4-12

[표 4-13]Table 4-13

[표 4-14]Table 4-14

[표 4-15]Table 4-15

EPCM 플래그는 엔클레이브 페이지의 상태를 설명하는 비트들의 세트이다.The EPCM flag is a set of bits describing the state of an enclave page.

[표 4-16]Table 4-16

EPCM(Enclave Page Cache Map)은 페이지 캐시의 콘텐츠를 트랙킹하도록 프로세서에 의해 사용되는 보안 구조이다. EPCM은 EPC로 현재 로딩되는 각 페이지에 대해 정확히 하나의 엔트리를 홀드한다.The Enclave Page Cache Map (EPCM) is a security structure used by the processor to track the contents of the page cache. The EPCM holds exactly one entry for each page currently loaded into the EPC.

[표 4-17]Table 4-17

검증(attestation)은 소프트웨어의 일부가 특히 원격 엔티티로 플랫폼 상에서 확립되었다는 것을 나타내는 프로세스이다. 보안 엔클레이브의 경우, 이것은 비밀 및 보호된 데이터를 갖는 소프트웨어를 신뢰하기 전에 엔클레이브 내에 보호된 인증 플랫폼 상에서 소프트웨어가 실행중이라는 것을 원격 플랫폼이 설정하는 메커니즘이다. 검증 프로세스는 세 개의 페이즈, 즉, 측정, 저장 및 보고를 갖는다.Attestation is a process that indicates that a piece of software has been established on a platform, especially as a remote entity. In the case of a secure enclave, this is the mechanism by which the remote platform establishes that the software is running on a protected authentication platform within the enclave before trusting the software with the secret and protected data. The verification process has three phases: measurement, storage and reporting.

엔클레이브 사전-엔클레이브 설정 및 사후-엔클레이브 설정 내에 두 개의 측정 기간이 있다. 설정되는 대로 엔클레이브의 측정을 제공하는 것이 엔클레이브 명령어의 역할이다. 엔클레이브가 설정되었다면, 엔클레이브 내부의 소프트웨어는 측정을 담당한다.There are two measurement periods within the enclave pre-enclave setup and the post-enclave setup. It is the role of the enclave instruction to provide the measurement of the enclave as set. If the enclave has been set up, the software inside the enclave is responsible for the measurement.

도 9는 본 발명의 일 실시예에서 발견될 수 있는, 쿼팅으로서 알려진 소프트웨어 검증 프로세스의 한 단계를 도시한다. 일 실시예에서, 서명 연산(910)은 측정 레지스터(901, 902, 903, 904)로부터의 연결 데이터에 서명키(915)를 적용한다. 서명 연산(910)의 결과가 쿼팅(quote)(920)이다.9 illustrates one step of a software verification process known as quorum, which may be found in one embodiment of the present invention. In one embodiment, the signature operation 910 applies the signature key 915 to the connection data from the measurement registers 901, 902, 903, 904. The result of the signature operation 910 is a quote 920.

보고 동작은 엔클레이브를 플랫폼으로 생성할 때 만들어지는 측정들을 암호적으로 결합한다. 이 유형의 기능은 종종 플랫폼 상에서 TPM 커맨드로서 이용가능함에 따라, 이 메커니즘은 종종 쿼팅으로서 지칭된다. 측정 레지스터(MR)의 값이 연결된 다음 비대칭 키를 이용하여 서명된다. 임의의 도전자는 쿼팅을 유효화하기 위해 쿼팅 구조의 서명을 간단히 검증해야 한다.The reporting operation cryptographically combines the measurements made when the enclave is created with the platform. As this type of functionality is often available as a TPM command on the platform, this mechanism is often referred to as quota. The value of the measurement register MR is concatenated and then signed using the asymmetric key. Any challenger must simply verify the signature of the quote structure to validate the quote.

도 10은, 본 발명의 일 실시에에서, 측정 레지스터(1000)의 세트로부터 쿼팅을 생성하기 위한 단계를 도시한다. 로컬 레포트(1005)는 비대칭 인증키로 측정 레지스터(1000)를 액세스함으로써 생성될 수 있다. 쿼팅 엔클레이브(1025)는 로컬 레포트(1005)를 익명 쿼팅(anonymous quote)(1010) 또는 정상 쿼팅(normal quote)(1020)으로 변환하는 소프트웨어를 포함할 수 있다.10 illustrates, in one embodiment of the present invention, the generation of a quart from a set of measurement registers 1000. The local report 1005 may be generated by accessing the measurement register 1000 with an asymmetric authentication key. Quoting enclave 1025 may include software that converts local report 1005 to anonymous quote 1010 or normal quote 1020.

비대칭 키와 엔클레이브 리프(leaf)에서 명령어의 수를 줄이기 위한 우리의 희망과 관계된 계산의 성질에 기인하여, 우리는 비대칭 서명하는 명령어를 포함하지 않을 것이다. 이하의 도면에서 도시되는 우리의 접근법은 대칭키 인증 키에 기초하여 '레포트'를 생성하는 하드웨어 기반 메커니즘을 제공하는 것이고, 이들 비대칭키 기반 '레포트'가, 자신이 엔클레이브를 이용하여 보호되는 소프트웨어를 이용하여 비대칭으로 서명된 '쿼팅'으로 변환되도록 할 수 있다. 쿼팅 엔클레이브가 플랫폼 검증 키에 액세스하도록 인증받을 필요가 있음에 따라, 쿼팅 엔클레이브 자체는 인증 엔클레이브로서 알려진 특별 목적의 엔클레이브이다.Due to the nature of the calculations related to our hope for reducing the number of instructions in the asymmetric key and enclave leaf, we will not include instructions that sign asymmetrically. Our approach, shown in the following figures, is to provide a hardware-based mechanism for generating a 'report' based on a symmetric key authentication key, where these asymmetric key-based 'reports' are software that is protected using an enclave. Can be converted to asymmetrically signed 'quoting'. As the quoted enclave needs to be authenticated to access the platform verification key, the quoted enclave itself is a special purpose enclave known as the authentication enclave.

각각의 엔클레이브는 두 개의 256-비트 와이드 측정 레지스터(MR_EADD&MR_POLICY) 및 두 개의 예비 레지스터를 제공한다. 이들 측정 레지스터는 엔클레이브의 SECS 내에 포함된다.Each enclave provides two 256-bit wide measurement registers (MR_EADD & MR_POLICY) and two spare registers. These measurement registers are contained within the SECS of the enclave.

도 11은 본 발명의 일 실시예에서 측정 레지스터 MR_EADD(1100)를 업데이트하는 EADD 프로세스를 도시한다. 확장 연산(1115)은 입력으로서 MR_EADD(1100), 페이지 데이터(1105), 및 페이지 메타 데이터(1110)의 현재 값을 취할 수 있다. 확장 연산의 출력은 MR_EADD'(1120)이며, 이것은 MR_EADD(1100)로 저장하기 위한 다음값이다.11 shows an EADD process for updating the measurement register MR_EADD 1100 in one embodiment of the present invention. The expansion operation 1115 may take as input the current values of MR_EADD 1100, page data 1105, and page metadata 1110. The output of the extension operation is MR_EADD '1120, which is the next value to store in MR_EADD 1100.

MR_EADD는 EINIT 명령어가 호출되기 전에 EADD 명령어를 사용하여 구축됨에 따라 엔클레이브의 총 측정값을 포함한다. 이것은 마이크로코드에 의해서만 기록되고, 따라서, 엔클레이브 코드에 의해서만 판독되는 SECS의 페이지에 놓일 필요가 있다. EADD의 각각의 호출시에, 페이지 데이터 및 그 페이와 연관된 보안 메타 데이터, 즉, 페이지의 상대 어드레스(엔클레이브의 베이스 어스레스에 대한 w.r.t.) 및 페이지의 SEC_INFO. 플래그에 걸쳐 SHA256을 계산하고, 이 값은 MR_EADD(1100)로 확장된다. 여기서, 우리는 '확장'을 다음을 의미하는 것으로 정의한다.MR_EADD contains the total measurement of the enclave as it is built using the EADD instruction before the EINIT instruction is called. It is only written by the microcode and therefore needs to be placed on the page of the SECS which is only read by the enclave code. In each call of EADD, the page data and the security metadata associated with that page, i.e., the relative address of the page (w.r.t. for the base address of the enclave) and the SEC_INFO. Compute SHA256 over the flag, and this value is extended to MR_EADD 1100. Here we define 'extension' as meaning:

새로운 MR값=Hash(구 MR값?입력값)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 to authenticate the policy that authorized the enclave to be launched. This value can be taken from the enclave permit that was placed in SECS at launch and copied as successful completion of the EINIT instruction. MR_POLICY is only written by the microcode, so it needs to be located in the page of the SECS which is only read by the enclave code.

도 12는 본 발명의 일 실시예에서 레포트를 생성하는 EREPORT를 도시한다. KEYID(1200), 오너 에포크(owner epoch)(1205), 패키지 퓨즈 키(1210), 및 고정 스트링 MAC 키(1215)는 유도 명령어(1220)으로의 가능한 입력이다. 유도(1220)dlm 출력은, TCB 버전(1232), ISV 버전(1234), 능력(1236), 플래그(1238), 사용자 데이터(1240) 및 측정 레지스터(1242)의 현재 값과 함께 CMAC(1125)에 입력될 수 있다. CMAC(1225)의 출력은 MAC(1244)에 저장될 수 있다. EREPORT 명령어의 출력은 키 식별(1230), TCB 버전(1232), ISV 버전(1234), 능력(1236), 플래그(1238), 사용자 데이터(1240), 측정 레지스터(1242) 및 MAC(1244)을 포함할 수 있다.12 illustrates an EREPORT for generating a report in one embodiment of the present invention. KEYID 1200, owner epoch 1205, package fuse key 1210, and fixed string MAC key 1215 are possible inputs to derivation command 1220. The derivation 1220 output of dlm, along with the current values of the TCB version 1232, ISV version 1234, capability 1236, flag 1238, user data 1240, and measurement register 1242, is determined by the CMAC 1125. Can be entered. The output of the CMAC 1225 may be stored in the MAC 1244. The output of the EREPORT command includes key identification 1230, TCB version 1232, ISV version 1234, capabilities 1236, flags 1238, user data 1240, measurement registers 1242, and MAC 1244. It may include.

EREPORT 명령어는 측정 레지스터, 사용자 데이터, 및 엔클레이브의 능력 및 플래그 같은 추가의 콘텍스추얼 정보에 걸쳐 대칭키 기반 GMAC을 수행하기 위한 중간 키를 생성한다.The EREPORT instruction generates an intermediate key for performing symmetric key based GMAC across measurement context, user data, and additional contextual information such as enclave's capabilities and flags.

측정 레지스터에 부가하여, 사용자는 또한 레포트에의 포함을 위해 데이터의 256 비트 와이드 블록을 제공할 수 있다. 사용자가 증명하고 싶어하는 많은 특정 값, 예를 들면, 챌린저 NONCE 및/또는 애플리케이션 생성 키가 있다. 이들 값은 단일 해시로 감축되고 포함을 위해 레포트로 제출된다.In addition to the measurement registers, the user can also provide a 256 bit wide block of data for inclusion in the report. There are many specific values that the user would like to prove, such as challenger NONCE and / or application generated keys. These values are reduced to a single hash and submitted to the report for inclusion.

EREPORT를 반복적으로 호출하는 것에 의한 키 소모를 방지하기 위해, 랜덤(128) 비트값(reportKeyID로 알려짐)이 프로세서의 각각의 전력 사이클 상에 생성되고 내부 위치에 저장된다. 이 값은, 이 값을 사용하는 2^32 AES 연산 후에 증분된다. EREPORT 명령어에 대한 각각의 호출은, 일 실시예에서, 이 값을 1만큼 증분시킬 것이다.To prevent key consumption by repeatedly calling EREPORT, a random 128 bit value (known as reportKeyID) is generated on each power cycle of the processor and stored in an internal location. This value is incremented after a 2 ^ 32 AES operation using this value. Each call to the EREPORT instruction will, in one embodiment, increment this value by one.

[표 5-2]Table 5-2

레포트 구조에서의 플래그 필드는 엔클레이브에 관한 임의의 상태 정보를 결정하는데 사용되거나, 또는 그들이 엔클레이브를 신뢰할 수 있는지를 도전자가 표명하는데 유용할 EREPORT 명령어가 호출었을 때 사용될 수 있다.The flag field in the report structure can be used to determine any state information about the enclave, or when the EREPORT instruction is called which will be useful for the challenger to state whether they can trust the enclave.

[표 5-3]Table 5-3

일 실시예에서, 아키텍처는 적절한 능력 설정을 갖는 구조적 엔클레이브가 EGETKEY 커맨드와 CMAC 연산에 사용되는 키를 검색하는 것을 가능하게 따라서, 현재 실행중인 하드웨어 상에 레포트가 생성되었다는 것을 검증할 수 있게 한다. 이러한 능력은 쿼팅 구조적 엔클레이브에 대해서는 제한된다.In one embodiment, the architecture enables a structural enclave with the appropriate capability settings to retrieve the key used for the EGETKEY command and CMAC operation, thus verifying that the report has been generated on the currently running hardware. This capability is limited for the Quoting Structural Enclave.

엔클레이브 외부에서 실행될 때 엔클레이브의 측정을 검색하기 위해, ERDMR판독 측정) 명령어가 제공된다. 이 명령어는 유효 SECS 페이지에 대한 포인터 및 측정이 전달될 어드레스에 대한 포인터를 취한다. 측정은 MEASUREMENT 구조의 형태로 전달된다. MEASRUEMENT 구조는 암호화하여 보호되지 않는다.In order to retrieve the measurement of the enclave when executed outside the enclave, an ERDMR Read Measurement) instruction is provided. This instruction takes a pointer to a valid SECS page and a pointer to the address to which the measurement is to be delivered. The measurement is delivered in the form of a MEASUREMENT structure. The MEASRUEMENT structure is not encrypted and protected.

[표 5-5]Table 5-5

엔클레이브 페이지 캐시 내부에 없을 때 엔클레이브 페이지는 암호적으로 보호된다. 암호 보호의 세 레벨이 있다: 신뢰성 보호, 위조 방지, 및 응답 보호. 일 실시예에서, 애플리케이션은 동일한 엔클레이브의 다른 페이지를 위해 선택된 보호 레벨과는 독립적으로 각각의 엔클레이브 페이지를 위한 보호 레벨을 선택하도록 허용된다. 엔클레이브의 구현 MAY는 애플리케이션이 다음의 조합들 간에서 선택할 수 있게 한다: 위조 방지, 위조 방지 및 응답 보호, 신뢰성 및 위조 방지, 및 신뢰성, 위조 방지, 및 응답 보호. 엔클레이브 페이지 상의 신뢰성 및 위조 방지는, AES와 같은 적절한 암호와 결합하여 GCM(Galois Counter Mode) 같은 몇 개의 인증된 암호 모드 중 하나를 사용하여 달성될 수 있다. 그러나, 응답 보호는 더 복잡한 솔루션을 요구한다.Enclave pages are cryptographically protected when they are not inside the enclave page cache. There are three levels of password protection: reliability protection, anti-counterfeiting, and response protection. In one embodiment, the application is allowed to select a protection level for each enclave page independently of the protection level selected for other pages of the same enclave. Implementation of Enclaves MAY allows an application to choose between the following combinations: anti-counterfeiting, anti-counterfeiting and response protection, reliability and anti-counterfeiting, and reliability, anti-counterfeiting, and response protection. Trust and anti-counterfeiting on the enclave page can be achieved using one of several authenticated cipher modes, such as Galois Counter Mode (GCM) in combination with appropriate ciphers such as AES. However, response protection requires a more complex solution.

도 13은 본 발명의 일 실시예에서 발견되는 위조 방지 및 응답 보호의 메커니즘을 도시한다. 위조 방지는 공격자가 프로그램에 의해 생성되지 않은 암호화된 데이터의 상이한 값을 대체하는 것을 방지한다. 응답 보호는 공격자가 프로그램에 의해 생성되지 않은 현재의 최종값이 아닌 암호화된 데이터의 값을 대체하는 것을 방지한다. 노드 버전 번호(1300)는 IV(1310)에 그리고 다음에 GMAC(1325) 알고리즘에 진입할 수 있다. 자식(children)(1305)에 대한 버전 번호는 데이터(1315)를 GMAC(1325) 알고리즘으로 전송할 수 있다. GMAC(1325) 알고리즘은 키(1320), IV(1310) 및 데이터(1315)를 결합하여 MAC(1330)을 생성한다.Figure 13 illustrates the mechanism of anti-counterfeiting and response protection found in one embodiment of the present invention. Anti-counterfeiting prevents an attacker from substituting different values of encrypted data that are not generated by the program. Response protection prevents an attacker from replacing a value of encrypted data that is not the current final value generated by the program. The node version number 1300 may enter the IV 1310 and then the GMAC 1325 algorithm. The version number for the child 1305 may send data 1315 to the GMAC 1325 algorithm. The GMAC 1325 algorithm combines the keys 1320, IV 1310 and data 1315 to generate the MAC 1330.

응답 보호는, 임의의 주어진 시간에 로직 프로세서에 의해 보여지는 바와 같이 엔클레이브의 모든 콘텐츠가 비손상(non-corrupted) 엔클레이브의 단일 스냅샷에 속한다는 것을 보장한다. 따라서, 응답 보호 메커니즘은 엔클레이브 버전의 개념을 정의하고 위조 방지된 엔클레이브 페이지가 그 엔클레이브의 버전에 속하는지를 결정하는 메커니즘을 제공할 필요가 있다. 이를 위해, 응답 보호 메커니즘은 각각의 위조 방지된 엔클레이브 페이지의 콘텐츠를 GMAC과 같은 메시지 인증 알고리즘을 사용하여 페이지 버전 번호와 연계(tie)시킨다. GMAC의 경우에, 버전은 도 13에 도시된 바와 같이 초기화 벡터(IV)의 일부로서 사용될 수 있다.Response protection ensures that all content of an enclave belongs to a single snapshot of a non-corrupted enclave as seen by the logic processor at any given time. Thus, the response protection mechanism needs to define the concept of an enclave version and provide a mechanism to determine whether an anti-counterfeiting enclave page belongs to that enclave's version. To this end, the response protection mechanism associates the content of each forged anti-enclave page with the page version number using a message authentication algorithm such as GMAC. In the case of GMAC, the version can be used as part of the initialization vector IV as shown in FIG.

도 14는 본 발명의 일 실시예에서 발견되는 응답 보호 메커니즘의 MAC 트리 구조 부분의 예를 도시한다. 리프 노드(leaf node)(1425)는 개별 MAC 콘텐츠 페이지(1430)에 대한 버전 정보를 포함할 수 있다. 1420과 같은 각각의 리프 노드는 개별 MAC 콘텐츠 페이지(도시 생략)를 포함한다. 각각의 내부 노드(1410, 1415)는 자신이 링크되는 자식(children)의 버전 정보를 포함할 수 있다. 루트(root)(1400)는 트리 데이터 구조에서의 최고 레벨 노드이다.Figure 14 shows an example of the MAC tree structure portion of the response protection mechanism found in one embodiment of the present invention. Leaf node 1425 may include version information for an individual MAC content page 1430. Each leaf node, such as 1420, includes a separate MAC content page (not shown). Each internal node 1410, 1415 may include version information of a child to which it is linked. The root 1400 is the top level node in the tree data structure.

버전을 전체 엔클레이브로 확장하기 위해, 응답 보호 메커니즘은 버전 트리를 유지한다. 리프 노드는 엔클레이브 인스턴스의 개별 응답 보호 페이지의 버전을 포함한다. 각각의 내부 노드는 각각의 자식 그룹의 버전을 제공하고, 따라서, 그들이 나타내는 페이지에 대한 버전 정보를 논리적으로 홀드한다. 도 14는 이러한 개념을 그림으로서 도시한다.To extend the version to the entire enclave, the response protection mechanism maintains the version tree. The leaf node contains a version of the individual response protection page of the enclave instance. Each internal node provides a version of each child group, thus logically holding the version information for the page they represent. 14 illustrates this concept as a picture.

일 실시예에서, 트리 구조는 O(n) 페이지에서 O(로그 n)으로 처리되는데 필요한 데이터의 수를 줄이도록 선택되었다. 해시 트리 대신 버전 트리의 사용은 트리 업데이트없이 EPC로부터 페이지 퇴거(eviction)를 가능하게 하기 위해 선택되었다.In one embodiment, the tree structure was chosen to reduce the number of data needed to process O (log n) in O (n) pages. The use of version trees instead of hash trees was chosen to enable page eviction from EPC without tree updates.

응답 보호는 각각의 페이지가 자신의 콘텐츠에 암호적으로 연계되어 있는 자기 자신의 버전을 갖도록 요구할 수 있기 때문에, 응답 보호는 위조 방지를 요구한다. 따라서, SE 아키텍처에서의 위조 방지는 필수이다. 부가하여, SE의 초기 구현은 지원된 보호 조합의 리스트를 추가로 제한할 수 있다.Because response protection can require each page to have its own version that is cryptographically linked to its content, response protection requires anti-counterfeiting. Therefore, anti-counterfeiting in the SE architecture is essential. In addition, the initial implementation of the SE may further restrict the list of supported protection combinations.

OS/VMM은 ECREATE 명령어를 실행함으로써 엔클레이브를 생성한다. 엔클레이브의 생성동안, 엔클레이브에 의해 보호되는 선형 어드레스의 범위가 특정된다. 이 선형 어드레스 범위는 ELS(Enclave Linear Space) 범위로서 알려져 있다.OS / VMM creates an enclave by executing the ECREATE instruction. During the creation of the enclave, the range of linear addresses protected by the enclave is specified. This linear address range is known as an Enclave Linear Space (ELS) range.

엔클레이브가 생성되면, ELS 범위에 속하는 개별 페이지가 EADDPRE 명령어를 사용하여 엔클레이브에 부가된다. EADDPRE 명령어는 부가된 페이지 각각을 이들 페이지를 엔클레이브 페이지 캐시로 이동시킴으로써 엔클레이브 보호 도메인으로 가져온다. EPC 외부의 임의의 이들 페이지가 EWBINVPG을 사용한다면, 로직 프로세서는 이들 페이지에 대하여 암호화 보호를 취할 것이다.Once the enclave is created, individual pages belonging to the ELS range are added to the enclave using the EADDPRE instruction. The EADDPRE instruction brings each added page to the enclave protection domain by moving these pages into the enclave page cache. If any of these pages outside of EPC use EWBINVPG, the logic processor will take cryptographic protection on those pages.

암호화 보호는 암호 메타-데이터를 각각의 엔클레이브 페이지와 연관시킴으로서 달성된다. 이 메타-데이터는 엔클레이브 페이지의 콘텐츠를 암호해독하고 각각의 엔클레이브 페이지의 인증/신선도를 검증하도록 다양한 프로세서 명령어를 위한 uCode 플로우에 의해 사용된다. SE 아키텍처는 몇몇의 그러한 명령어를 암호화 메타-데이터를 업데이트, 관리 및 유효화하도록 제공한다.Encryption protection is achieved by associating cryptographic meta-data with each enclave page. This meta-data is used by the uCode flow for various processor instructions to decrypt the contents of the enclave page and verify the authenticity / freshness of each enclave page. The SE architecture provides several such instructions for updating, managing and validating cryptographic meta-data.

각각의 엔클레이브 페이지는 그와 연관된 보안 정보 SEC_INFO 데이터 구조를 갖는다. SEC_INFO 데이터 구조의 목적은 페이지를 암호해독하고 검증하는데 요구되는 암호화 메타-데이터를 홀드하는 것이다. SEC_INFO 구조의 다양한 필드는 다음과 같다.Each enclave page has a security information SEC_INFO data structure associated with it. The purpose of the SEC_INFO data structure is to hold cryptographic meta-data required to decrypt and verify the page. The various fields of the SEC_INFO structure are as follows:

[표 6-1][Table 6-1]

보안 정보 플래그(SEC_INFO.Flags)는 페이지 유형, 보호된 페이지에 대한 암호화 및 액세스 보호를 설명한다.The security information flags (SEC_INFO.Flags) describe the page type, encryption for protected pages, and access protection.

[표 6-2][Table 6-2]

보안 맵(SMAP)은 엔클레이브 페이지의 신선도(즉, 응답 보호)를 검증하는데 요구되는 암호화 메타-데이터를 저장하는데 사용되는 데이터 구조이다. 보안 맵은 엔클레이브의 특정 스냅샷에 대한 풀 버전 트리를 나타낸다. 보호 맵의 각각의 노드는 256개의 자식 노드(또는 리프 노드의 경우에 엔클레이브 페이지)에 대한 버전을 홀드한다. 보안 노드에 관한 부가의 메타-데이터는 특정 SMAP 노드에 대한 SEC_INFO 내에 포함된다.A security map (SMAP) is a data structure used to store cryptographic meta-data required to verify the freshness (ie, response protection) of an enclave page. The security map represents the full version tree for a specific snapshot of the enclave. Each node of the protection map holds a version for 256 child nodes (or enclave pages in the case of leaf nodes). Additional meta-data about the secure node is included in SEC_INFO for the particular SMAP node.

일 실시예에서, 보안 맵 트리는 두 레벨의 깊이(보안 맵의 깊이는 SE 아키텍처에 의해 지원되는 엔클레이브의 크기에 관한 것이다. 일반적으로, SE 아키텍처는 32GB의 최대 엔클레이브 크기를 지원할 것이다)이고, 그 엔클레이브 내의 엔클레이브 페이지의 엔클레이브 오프셋을 이용하여 액세스된다. SMAP의 루트는 SECS 내에 포함되고 그것은 단지 128개의 자식 노드에 대한 버전만을 홀드한다. 엔클레이브 오프셋으로부터의 비트는 SMAP을 인덱싱하는데 사용되는 적절한 자식을 선택하는데 사용된다. 일반적으로, 엔클레이브 오프셋은 길이가 35비트이다. 엔클레이브 오프셋은 다음의 공식(엔클레이브 선형 어드레스 & 엔클레이브 마스크)에 의해 추출된다. 엔클레이브 마스크는 (엔클레이브의 크기-1)에 의해 결정되고 ECREATE 동안 계산될 수 있다.In one embodiment, the security map tree is at two levels of depth (the depth of the security map relates to the size of the enclave supported by the SE architecture. In general, the SE architecture will support a maximum enclave size of 32 GB), It is accessed using the enclave offset of the enclave page within that enclave. The root of the SMAP is contained in the SECS and it only holds versions for 128 child nodes. Bits from the enclave offset are used to select the appropriate children used to index the SMAP. In general, the enclave offset is 35 bits long. The enclave offset is extracted by the following formula (enclave linear address & enclave mask). The enclave mask is determined by (size of enclave-1) and can be calculated during ECREATE.

[표 6-3]Table 6-3

일반적으로, 깊이 l>1에서, 비트 N-(l)×8 내지 N-(l+1)×8+1이 다음 레벨에서 적절한 자식을 선택하는데 사용된다.In general, at depth l > 1, bits N− (l) × 8 to N− (l + 1) × 8 + 1 are used to select the appropriate child at the next level.

주석 : 보안 맵은 논리적 데이터 구조이고, 구조적인 것이 아니다. 로직 프로세서는 선형 어드레스 공간에서 SAMP가 어디에 위치되어 있는지조차 알지 못한다. 시스템 소프트웨어는 보안 맵을 유지하고 옮기는(walking) 것을 담당한다. 보안 맵의 각각의 개별 노드는 구조적으로 정의된 구조를 갖는다 - 그러나, 아키텍처는 보안 맵이 메모리에 어떻게 유지되는지를 특정하지는 않는다. 그러나, 보안 맵 내의 각각의 노드는 보안 맵 내에 잘 정의된 논리 위치를 갖고, 노드가 맵 내의 주위로 이동되면, 보안 맵과 연관된 다양한 프로세서 명령어는 그것을 공격 시나리오로서 해석할 것이라는 것을 유의하자. Note : Security maps are logical data structures, not structural ones. The logic processor does not even know where the SAMP is located in the linear address space. System software is responsible for maintaining and walking the security map. Each individual node of the security map has a structurally defined structure-however, the architecture does not specify how the security map is maintained in memory. However, note that each node in the security map has a well-defined logical location in the security map, and once the node is moved around in the map, the various processor instructions associated with the security map will interpret it as an attack scenario.

루트 보안 노드는 SECS 내에 포함되고 128개의 자식에 대한 버전 정보를 포함한다. 비루트(non-root) 보안 노드는 보호된 페이지 및 자신의 연관된 SEC_INFO이다. 보호된 페이지는 256개의 자식에 대한 버전 정보를 포함한다.The root secure node is included in the SECS and contains version information for 128 children. A non-root secure node is a protected page and its associated SEC_INFO. The protected page contains version information for 256 children.

[표 6-4]Table 6-4

SEC_INFO는 SMPA 내에 SMAP의 위치를 포함한다. SMAP을 갖는 위치는 선형/엔클레이브 오프셋 및 페이지 유형 SMAP_LEVEL_1 및 SMAP_LEVEL_2에 의해 결정된다.SEC_INFO contains the location of the SMAP within the SMPA. The location with SMAP is determined by the linear / enclave offset and page type SMAP_LEVEL_1 and SMAP_LEVEL_2.

응답 보호 엔클레이브 페이지를 부가하는 것은, SMAP 부모가 생성되었고 EPC 내부에 상주하면서 FCR 비트가 클리어되는 것을 요구한다. 엔클레이브 페이지의 무결성을 검증하기 위해, 로직 프로세서는 SEC_INFO 구조 내의 IV_P 및 key_id를 사용하여 키를 생성한다. 키는 SEC_INFO 구조 내의 플래그 및 페이지의 콘텐츠에 걸쳐 MAC을 계산하는데 사용된다. 계산된 MAC은 SEC_INFO 구조에 위치된 MAC과 비교된다. MAC이 정합되면, 페이지는 무결성 검사를 통과한 것을 고려된다.Adding a response protection enclave page requires that the FCR bit be cleared while the SMAP parent has been created and resides inside the EPC. To verify the integrity of the enclave page, the logic processor generates a key using IV_P and key_id in the SEC_INFO structure. The key is used to compute the MAC across the flag and the content of the page in the SEC_INFO structure. The computed MAC is compared with the MAC located in the SEC_INFO structure. If the MAC matches, the page is considered to have passed the integrity check.

로직 프로세서는 페이지가 ELPG 명령어를 사용하여 EPC에 로딩될 때 페이지의 무결성을 검증한다. 이 명령어의 일부로서, 로직 프로세서는 페이지를 검증하는데 사용된 SEC_INFO 구조로부터 IV-P를 다운(down)한다.The logic processor verifies the integrity of the page as it is loaded into the EPC using ELPG instructions. As part of this instruction, the logic processor downloads the IV-P from the SEC_INFO structure used to verify the page.

엔클레이브 페이지의 신선도를 검증하기 위해, 로직 프로세서는 엔클레이브 페이지 및 자신의 smap 부모가 EPC로 로딩되었고, 그 smap 부모가 신선하다는 것을 검증한다. 다음에, smap 부모에 저장된 버전에 대한 페이지의 버전을 검사하도록 진행된다. 두 개의 버전이 정합하면, 프로세서는 그 페이지에 대한 새로운 버전을 생성하고, smap 부모의 버전 및 엔클레이브 페이지의 버전을 업데이트한다. 마지막으로, 엔클레이브 페이지를 신선한 것으로 마킹한다.To verify the freshness of the enclave page, the logic processor verifies that the enclave page and its smap parent have been loaded into the EPC and that smap parent is fresh. Next, proceed to check the version of the page against the version stored in the smap parent. If the two versions match, the processor creates a new version for that page and updates the version of the smap parent and the version of the enclave page. Finally, mark the enclave page as fresh.

주석 - 새로운 버전의 생성은 페이지가 수정가능하게 한다. 이것은 두 개 모두 아키텍처 및 구현을 간략히 하였다.Annotation-Creating a new version makes the page modifiable. This both simplified the 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. Next, proceed to set the version of the page in the smap parent to 0 and mark the EPC slot of the enclave page available.

엔클레이브 페잊 캐시(EPC)는 엔클레이브 페이지가 SE 암호화 보호에 의해 암호적으로 보호받지 못한 경우 엔클레이브 페이지를 일시적으로 저장하도록 CPU에 의해 사용되는 보안 스토리지이다.The Enclave Perspective Cache (EPC) is a secure storage used by the CPU to temporarily store an Enclave page if the Enclave page is not cryptographically protected by SE encryption protection.

다음의 요구사항은 EPC 상에서 식별된다. 비디버그 엔클레이브에 속하는 EPC로 로딩된 엔클레이브 메모리 페이지로의 액세스는 그 엔클레이브 외부의 소프트웨어 엔티티에 의해 임의의 수정으로부터 보호받을 수 있다. 공격자는 EPC로 로딩된 비디버그 엔클레이브에 속하는 플레인 텍스트 데이터를 직접적인 하드웨어 공격으로 판독할 수 없다. 공격자는 비디버그 엔클레이브에 속하는 EPC 내의 데이터를 직접적인 하드웨어 공격으로 수정할 수 없다. EPC로 로딩된 임의의 데이터는 시스템 내의 CPU로부터 코히런트하고 또한 보안적으로 액세스가능할 수 있다.The following requirements are identified on the EPC. Access to an enclave memory page loaded into an EPC belonging to a non-debug enclave may be protected from any modification by software entities outside that enclave. An attacker cannot read plain text data belonging to a non-debug enclave loaded into an EPC by a direct hardware attack. An attacker cannot modify data in an EPC belonging to a non-debug enclave by a direct hardware attack. Any data loaded into the EPC may be coherent and securely accessible from the CPU in the system.

EPC를 구현하는 몇 개의 메커니즘이 있다. EPC는 온-다이(on-die) SRAM 또는 eDRAM으로서 구현될 수 있다. EPC는 또한 CPU의 최종-레벨 캐시의 동적 격리 방식에 의해 구성될 수 있다. 그러한 구현예에서, EPC는 패키지 외부로부터의 비인증 액세스로부터 보호될 수 있다. 그러나, 시스템 내의 다른 패키지는 EPC를 코히런트하고 또한 보안적으로 액세스할 수 있다.There are several mechanisms for implementing EPC. The EPC may be implemented as on-die SRAM or eDRAM. EPC may also be configured by dynamic isolation of the CPU's last-level cache. In such implementations, the EPC may be protected from unauthorized access from outside the package. However, other packages in the system can coherently and securely access the EPC.

EPC를 구현하는 또 다른 메커니즘은 CMA(Crypto Memory Aperture)이다. CMA는 플랫폼 DREAM을 이용하여 암호로 보호되는 휘발성 스토리지를 생성하는 비용에 있어서 효과적인 메커니즘을 제공한다. CMA는 CPU 언코어(uncore)에 하나 이상의 전랴적으로 배치된 암호화 유닛을 사용하여 고객 기술의 필요에 따라 보호 레벨들의 가변을 제공한다. 다양한 언코어 에이전트는 CMA로 진행하는 메모리 액세스를 인식하고, 그들(25) 액세스를 언코어에 위치된 암호화 컨트롤러로 라우팅하도록 수정된다. 희망하는 보호 레벨에 따라, 암호화 컨트롤러는 암호화 텍스트(cipher-text)를 가져오도록 플랫폼 DRAM으로 하나 이상의 메모리 액세스를 생성한다. 다음에, 플레인 텍스트를 생성하고 원래의 CMA 메모리 요청을 만족시키도록 암호화 텍스트를 처리한다. CMA는 인텔의 QPI(QuickPath Interconnect) 프로토콜에 완전히 통합하고, QPI 프로토콜로의 보안 확장을 구비하면서 멀티-패키지 플랫폼으로 스케일링된다. 멀티-패키지 플랫폼(30) 구성에서, CMA는 외부적으로 대면하는 QPI 링크 레이어에서 Link-Sec(link-level security)을 사용하여 인텔 CPU들 간의 메모리 전이를 보호한다.Another mechanism for implementing EPC is Crypto Memory Aperture (CMA). CMA provides a cost effective mechanism for creating password-protected volatile storage using platform DREAM. CMA uses one or more globally located cryptographic units on a CPU uncore to provide varying levels of protection depending on the needs of customer technology. Various uncore agents are modified to recognize memory accesses going to the CMA and route them 25 to cryptographic controllers located in the uncore. Depending on the desired level of protection, the cryptographic controller creates one or more memory accesses to the platform DRAM to fetch cipher-text. Next, create plain text and process the encrypted text to satisfy the original CMA memory request. CMA is fully integrated into Intel's QuickPath Interconnect (QPI) protocol and scaled to a multi-package platform with security extensions to the QPI protocol. In a multi-package platform 30 configuration, the CMA uses link-level security (Link-Sec) at the externally facing QPI link layer to protect memory transitions between Intel CPUs.

SECS는 현재 EPC로 로딩된다면 활성이라는 것을 말한다. 본 문서에서 이후에 설명되는 바와 같이, OS/VMM은 EPC로 로딩되는 것을 관리하는 것을 담당한다. 그러나, 엔클레이브 페이지를 EPC로 로딩하는 동안, OS/VMM은, 고려 중인 페이지 자체가 언제 SECS가 되는지를 제외하고, 그 페이지에 대한 SECS의 소재를 CPU에게 말할 필요가 있다. 로딩되는 페이지가 SECS가 아닌 경우, CPU는 그 페이지에 대응한 SECS가 EPC 내에 위치되는 것을 요구한다. 엔클레이브에 대하여 임의의 페이지를 로딩하기 전에, OS/VMM MAY는 그 엔클레이브를 위해 SECS를 EPC로 로딩한다.SECS is said to be active if currently loaded into the EPC. As will be described later in this document, the OS / VMM is responsible for managing what is being loaded into the EPC. However, while loading an enclave page into the EPC, the OS / VMM needs to tell the CPU the whereabouts of the SECS for that page, except when the page under consideration becomes the SECS. If the page being loaded is not a SECS, the CPU requires that the SECS corresponding to that page be located in the EPC. Before loading any page for an enclave, OS / VMM MAY loads the SECS into the EPC for that enclave.

CPU는 얼마나 여러번 SECS가 EPC로 로딩되어야 하는지에 대한 어떠한 제한도 강제하지 않는다 - 그러나, OS/VMM이 SECS의 다수의 카피를 엔클레이브 페이지 캐시로 로딩하는 것은 상당히 일반적인 것이 아니다. 그럼에도 불구하고, 동일한 SECS의 다수의 카피가 EPC로 로딩되더라도, 그들 카피 각각은 개별적인 활성 SECS 인스턴스로서 고려되고, 활성 SECS의 상이한 인스턴스에 속하는 EPC로 로딩된 엔클레이브 페이지는 하드웨어에 의해 상이한 엔클레이브에 속하는 것으로 고려된다.The CPU does not enforce any limit on how many times the SECS should be loaded into the EPC-however, it is not quite common for the OS / VMM to load multiple copies of the SECS into the enclave page cache. Nevertheless, even if multiple copies of the same SECS are loaded into the EPC, each of those copies is considered as a separate active SECS instance, and the enclave pages loaded into the EPC belonging to different instances of the active SECS are in different enclaves by hardware. It is considered to belong.

OS/VMM은 시스템 어드레스 공간에서 물리적 메모리의 연속 블록으로서 EPC를 본다. 그러나, 내부 스토리지를 줄이기 위해, 그리고 고속 인덱싱을 가능하게 하기 위해, CPU는 슬롯 식별자(SID)를 각각의 EPC 페이지와 연관시킨다. EPC 페이지의 물리적 어드레스 및 대응하는 슬롯 식별자는 다음과 같이 서로 연관된다.OS / VMM sees EPC as a contiguous block of physical memory in the system address space. However, to reduce internal storage, and to 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 associated with each other as follows.

sid=(page_pa-epc_base_pa)>>12sid = (page_pa-epc_base_pa) >> 12

page_pa=pc_base_p｜<sid<<12)page_pa = pc_base_p ｜ <sid << 12)

하드웨어는 무효 슬롯을 정의하기 위해 특정 슬롯 식별자 0xFF를 사용한다. EPC 슬롯 식별자는 uCode 및 PMH 모두에 의해 사용되어 엔클레이브 페이지에 관한 정보를 트래킹한다.The hardware uses the specific slot identifier 0xFF to define the invalid slot. The EPC slot identifier is used 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 between physical addresses belonging to the EPC and EPC slot identifiers, we say that each page loaded into the EPC has its own EPC slot identifier or EPC_SID.

부가적으로, EPC로 로딩되는, SECS 페이지에 대한 것을 제외하고, 모든 엔클레이브 페이지는 활성 SECS 인스턴스와 연관되어 있다. 활성 SECS 인스턴스는 EPC로 로딩되는 SECS 페이지에 지나지 않는다는 것을 상기하자. 결과적으로, 활성 SECS 페이지는 또한 자기 자신의 EPC_SID를 갖는다. 비SECS 엔클레이브 페이지가 속하는 SECS 페이지의 EPC_SID는 비-SECS 25 페이지에 대한 SECS_SID로서 지칭된다. EPC로 로딩되는 각각의 페이지에 대해, 하드웨어는 SECS_SID를 유지한다. EPC로 로딩되는 SECS 페이지에 대한 SECS_SID는 0xFF, 또는 무효 SID로 정의된다.Additionally, all enclave pages are associated with an active SECS instance, except for SECS pages, which are loaded into the EPC. Recall that an active SECS instance is nothing more than a SECS page loaded into an 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 for the non-SECS 25 page. For each page loaded into the EPC, the hardware maintains SECS_SID. The SECS_SID for the SECS page loaded into the EPC is defined as 0xFF, or an invalid SID.

EPCM은 페이지 캐시의 콘텐츠를 트랙킹하기 위해 프로세서에 의해 사용되는 보안 구조이다. 30 EPCM은 EPC로 현재 로딩되는 각각의 페이지에 대한 정확하게 하나의 엔트리를 홀드한다. 그에 의해 표시되는 페이지에 대해, 각각의 EPCM 엔트리는 그러한 정보를 페이지가 속하는 엔클레이브, 페이지가 엔클레이브 페이지 캐시로 들어온 선형 어드레스, 페이지의 버전 등으로서 트랙킹한다. EPCM 구조는 EPC로 로딩되는 엔클레이브 페이지에 대해 액세스 제어를 강제하도록 어드레스 변환 플로우에서 CPU에 의해 사용된다. EPCM 엔트리는 다양한 명령어 플로우의 일부로서 (x)uCode에 의해 관리된다.EPCM is a security structure used by the processor to track the contents of the page cache. 30 The EPCM holds exactly one entry for each page currently loaded into the EPC. For the page represented by it, each EPCM entry tracks such information as the enclave to which the page belongs, the linear address the page entered into the enclave page cache, the version of the page, and so forth. The EPCM structure is used by the CPU in the address translation flow to enforce access control on enclave pages loaded into the EPC. EPCM entries are managed by (x) uCode as part of various instruction flows.

본 발명의 일 실시예에서, 엔클레이브 페이지 캐시(EPC)는 동적으로 할당되거나 또는 할당해제될 수 있다. 일 실시예에서, 운영 시스템과 같은 소프트웨어는 메모리에 페이지를 EPC로서 동적으로 할당하거나 EPC로부터 메모리를 할당해제할 수 있다. 일 실시예에서, 운영 시스템은 EPC 내에 있게 될 엔클레이브에 임의의 페이지를 할당할 수 있다. EPC는 몇몇 실시예에서 메모리 내의 모든 이용가능한 위치를 차지할 수 있다. 일 실시예에 따라, 고정 EPC로부터 동적 EPC의 하나의 구분은 동적 EPC가 메모리의 페이지의 부가 및 제거를 가능하게 한다는 것이다. 일 실시예에서, 소프트웨어 드라이버와 같은 로직은 EPC에 있게된 메모리 영역을 할당할 수 있고, EPC로부터 메모리를 할당해제할 수 있다. 일 실시예에서, 프리-부트(pre-boot) 프로세스는 메모리의 각 페이지에 대해 메타 데이터를 저장하도록 이용가능한 메모리를 체크하고, 소프트웨어는 EPC 또는 비 EPC에 있게 될 페이지를 선언할 수 있지만, 하드웨어 로직은 각 페이지의 속성을 트랙킹하고 강제할 수 있다.In one embodiment of the invention, the enclave page cache (EPC) may be dynamically allocated or deallocated. In one embodiment, software such as an operating system may dynamically allocate pages to memory as EPCs or deallocate memory from EPCs. In one embodiment, the operating system may assign any page to an enclave that will be in the EPC. The EPC may occupy all available locations in memory in some embodiments. According to one embodiment, one distinction of dynamic EPC from fixed EPC is that dynamic EPC enables the addition and removal of pages of memory. In one embodiment, logic such as a software driver may allocate a memory area that resides in the EPC, and may deallocate memory from the EPC. In one embodiment, the pre-boot process checks the available memory to store metadata for each page of memory, and the software can declare the page to be in an EPC or non-EPC, but hardware Logic can track and enforce the attributes of each page.

일 실시예에서, 하드웨어 로직은 TLB(translation lookaside buffer) 및 PMH(page miss handler)를 통해 EPC로서 사용될 메모리로의 액세스를 제어할 수 있다. 일 실시예에서, 검색 어드레스가 TLB 히트로서 알려진 TLB에서 정합할 때, TLB는 보안 엔클레이브가 EPC를 엑시트(exit)할 때 플러시(flush)될 수 있다. 일 실시예에서, 검색 어드레스는 TLB 미스(miss)로서 알려진 TLB에서 정합하지 않을 때, 여분의 룩업이 다수의 메모리 참조에 대하여 엔클레이브 페이지 캐시 맵(EPCM)으로부터 데이터를 가져올 수 있다. 일 실시예에서, PMH는 EPCM의 룩업을 실행할 수 있다. 또 다른 실시예에서, PMH의 범위 레지스터는 연속적인 물리 어드레스, EPC로의 액세스를 제어하도록 검사된다. 운영 시스템은 DMA(direct memory access)가 EPC 페이지를 액세스하는 것을 가능하게 하지 않는다. 메모리의 리턴된 페이지가 엔클레이브 페이지로서 마킹되면, 페이지의 SECSID(secure enclave control structure identification)은 액세스가 보안인 것을 보장하도록 현재 실행되는 엔클레이브의 것에 대해 검사받을 수 있다. 리턴된 페이지의 SECSID와 현재 실행중인 엔클레이브의 것 사이에 오정합이 있다면, PMH는 중단(abort) 메시지를 발행할 수 있다. 메모리의 리턴된 페이지가 엔클레이브 페이지로서 마킹되지 않거나, 또는 메모리의 리턴된 페이지가 엔클레이브 페이지로서 마킹되고 그 페이지의 SECSID가 실행중인 엔클레이브의 것과 정합한다면, PMH는 페이지 변환을 TLB로 로딩할 수 있다. 일 실시예에서, 캐시 태그는 재기록 사이클에 대해 다른 라인으로부터 엔클레이브 라인을 식별하는데 사용될 수 있다. 그러나, 적어도 하나의 실시예에서, 캐시 태그는 메모리 요청의 유형을 결정하는 로직이 재기록 사이클 동안 EPCM을 액세한다면 사용되지 않는다.In one embodiment, the hardware logic may control access to the memory to be used as the EPC through a translation lookaside buffer (TLB) and a page miss handler (PMH). In one embodiment, when the search address matches in a TLB known as a TLB hit, the TLB may be flushed when the secure enclave exits the EPC. In one embodiment, when the search address does not match in a TLB known as a TLB miss, an extra lookup may pull data from the enclave page cache map (EPCM) for multiple memory references. In one embodiment, the PMH may perform a lookup of the EPCM. In another embodiment, the range register of the PMH is checked to control access to consecutive physical addresses, EPCs. The operating system does not allow direct memory access (DMA) to access the EPC page. If the returned page of memory is marked as an enclave page, the secure enclave control structure identification (SECSID) of the page can be checked for that of the currently executing enclave to ensure that the access is secure. If there is a mismatch between the SECSID of the returned page and that of the currently running enclave, the PMH may issue an abort message. If the returned page in memory is not marked as an enclave page, or if the returned page in memory is marked as an enclave page and the SECSID of that page matches that of the running enclave, the PMH will load the page translation into the TLB. Can be. In one embodiment, cache tags may be used to identify enclave lines from other lines for rewrite cycles. However, in at least one embodiment, the cache tag is not used if the logic that determines the type of memory request accesses the EPCM during the rewrite cycle.

본 발명의 일 실시예에서, 소프트웨어, BIOS는 엔클레이브 페이지를 생성하기 위해 운영 시스템 부트 전에 메모리를 할당할 수 있다. 소프트웨어는, 일 실시예에서, BIOS에서 단계들의 시퀀스로 EPC를 생성할 수 있다. BIOS는 메타 데이터를 저장하고, 각각의 프로세서에 대해, 범위 레지스터를 설정하도록 몇몇 메모리를 예비할 수 있다. BIOS는 베이스 어드레스 및 메모리 크기를 입력으로서 취할 수 있다. 시스템 구성은 모든 패키지 및 모든 코어가 엔클레이브 외부의 액세스로부터 보호를 제공하도록 올바르게 설정되어 있다는 것을 보장하도록 MCHECK로서 알려진 프로세스에 의해 체크된다. MCHECK는 시스템이 리셋될 때까지 레지스터를 잠글 것이다. 또 다른 실시예에서, 소프트웨어는 페이지를, 메모리의 부분이 EPC의 부분이라는 것을 선언하는 EPCADD로서 알려진 명령어에 의해 EPC로 페이지를 부가할 수 있다. EPCADD 시퀀스는 메모리 어드레스를 입력으로서 취할 수 있고 성공 또는 실패를 표시하는 메시지를 출력할 수 있다. 성공을 나타내는 메시지를 출력하는 EPCADD의 경우에, EPCADD는 EPCM.E 비트를 설정할 수 있고 그 물리 어드레스에 대응하는 페이지는 시스템 내의 모든 TLB로부터 플러시된다. 본 발명의 일 실시예에서, EPCADD는 입력 어드레스를 갖는 페이지가 이미 EPC 페이지라는 것을 나타내는 01의 RAX의 에러 코드로, 그리고 입력 어드레스가 범위를 벗어났다는 것을 나타내는 02의 에러 코드로 리턴할 수 있다. EPC의 부분으로서 EPCADD에 의해 선언된 메모리의 페이지는 데이터를 액세스하기 위해 EPC 세맨틱(semantic)을 요구할 수 있다. 본 발명의 이 실시예에서, 소프트웨어는 EWBINVPG로서 알려진 명령어에서 ePC로부터 페이지를 제거할 수 있고, 암호화 및 무결성 보호에 의해 보호되는 동안, 암호화된 데이터가 계속해서 이용하게 할 수 있다. 이 포맷에서의 데이터는 하드 디스크 드라이브의 정규 메모리 상에 저장될 수 있다. 또 다른 실시예에서, 소프트웨어는, EPCREMOVE로서 알려진 명령어에서, EPC 내의 페이지를 제거할 수 있고 암호화된 데이터를 이용불가능하게 할 수 있다. EPCREMOVE를 실행하는 하드웨어는 페이지 및 EPCM의 부분을 클리어한다. EPCREMOVE는 처음에 EWBINVPG를 실행하지 않고 실행될 수 있다. EPCREMOVE 시퀀스는, 일 실시예에서, 메모리 어드레스에 기초하여 EPC로부터 페이지를 제거한다. 본 발명의 실시예에서, EPCREMOVE 명령어는 제거되는 페이지가 SECS(secure enclave control structure)의 일부이고 제거될 수 있다는 것을 나타내는 01의 RAX의 에러 코드, 및 제거되는 페이지가 EPC 페이지가 아니라는 것을 나타내는 02의 에러 코드를 포함할 수 있다. 메모리의 페이지의 글로벌 TLB 셧다운은 본 발명의 일 실시예에서 EPCREMOVE로부터 유래할 수 있고, 페이지에 의해 이전에 점유된 메모리는 일반적인 소프트웨어 액세스를 위해 이용가능하게 된다.In one embodiment of the invention, the software, BIOS may allocate memory prior to booting the operating system to generate an enclave page. The software may, in one embodiment, generate an EPC with a sequence of steps in the BIOS. The BIOS may store some metadata and reserve some memory for each processor to set range registers. The BIOS can take as input the base address and the memory size. System configuration is checked by a process known as MCHECK to ensure that all packages and all cores are correctly set up to provide protection from access outside the enclave. MCHECK will lock the register until the system is reset. In another embodiment, the software may add the page to the EPC by an instruction known as EPCADD that declares that the portion of memory is part of the EPC. The EPCADD sequence can take a memory address as input and output a message indicating success or failure. In the case of EPCADD outputting a message indicating success, EPCADD may set the EPCM.E bit and the page corresponding to that physical address is flushed from all TLBs in the system. In one embodiment of the invention, EPCADD may return with an error code of RAX of 01 indicating that the page with the input address is already an EPC page, and with an error code of 02 indicating that the input address is out of range. . Pages of memory declared by EPCADD as part of EPC may require EPC semantics to access data. In this embodiment of the present invention, the software can remove the page from the ePC in an instruction known as EWBINVPG and allow the encrypted data to continue to be used while protected by encryption and integrity protection. Data in this format can be stored on regular memory of the hard disk drive. In another embodiment, the software may, in an instruction known as EPCREMOVE, remove pages in the EPC and make encrypted data unavailable. The hardware executing EPCREMOVE clears the page and parts of the EPCM. EPCREMOVE can be run without first running EWBINVPG. The EPCREMOVE sequence, in one embodiment, removes a page from the EPC based on the memory address. In an embodiment of the present invention, the EPCREMOVE instruction is an error code of RAX of 01 indicating that the page being removed is part of a secure enclave control structure (SECS) and can be removed, and the 02 of 02 indicating that the page being removed is not an EPC page. It may contain an error code. The global TLB shutdown of a page of memory may be derived from EPCREMOVE in one embodiment of the invention, and the memory previously occupied by the page becomes available for general software access.

PMH는 메모리 스페이스의 보호 영역으로의 액세스를 방지한다. 아키텍처에 의존하여, 이것은 간단히 EPC로의 액세스의 물리 어드레스 검사일 수 있다. 추가의 PMH 지원을 사용하여 SE의 성능 향상 또는 대체 구현을 가능하게 할 수 있다. SE 아키텍처는 엔클레이브 페이지 캐시로 로딩되는 엔클레이브 페이지로의 비인가 액세스를 방지하기 위해 PMH(Page-miss Handler)에 의존한다. PMH는 다양한 이벤트를 검출하고, 그들 이벤트를 다시 마이크로코드로 리포트한다. 마이크로코드는 OS/VMM으로의 이벤트를 리포트할 수 있다. OS/VMM은 다음에 적절한 명령어를 실행하여 폴트를 구제할 수 있다.PMH prevents access to the protected area of the memory space. Depending on the architecture, this may simply be a physical address check of access to the EPC. Additional PMH support can be used to enable performance improvements or alternative implementations of the SE. The SE architecture relies on a page-miss handler (PMH) to prevent unauthorized access to enclave pages loaded into the enclave page cache. PMH detects various events and reports those events back to microcode. The microcode can report events to the OS / VMM. OS / VMM can then remedy the fault by executing the appropriate command:

ECREATE 명령어를 사용하여 엔클레이브가 생성되는 경우, 선형 어드레스 범위가 그 엔클레이브에 대해 특정된다. 이 범위는 그 엔클레이브에 대해 선형 어드레스 범위 로 불린다. 엔클레이브의 선형 어드레스 범위에 속하는 임의의 메모리 페이지는 엔클레이브의 보호 하에 있는 것으로 고려되고, 그들과 연관된 SEC_INFO 엔트리를 갖는다.When an enclave is created using the ECREATE instruction, a linear address range is specified for that enclave. This range is called the linear address range for that enclave. Any memory page that falls within the enclave's linear address range is considered to be under the protection of the enclave and has an SEC_INFO entry associated with it.

엔클레이브의 선형 어드레스 범위에 속하는 메모리 페이지 또한 엔클레이브 페이지 로 지칭된다. 엔클레이브 내부에서 실행중인 프로그램은 그들 페이지가 엔클레이브 페이지 캐시로 로딩되고, 그것이 페이지를 소유하는 엔클레이브이기만 하면 엔클레이브를 액세스하도록 허가 받는다. 프로세서는 이것이 그 경우가 아니라면 익셉션-클래스(exception-class) 이벤트를 생성할 것이다. OS/VMM은 엔클레이브 페이지가 필요에 따라 EPC로 로딩되는 것을 보장하는 것을 담당한다.Memory pages that belong to the linear address range of an enclave are also referred to as enclave pages . Programs running inside an enclave are allowed to access the enclave as long as those pages are loaded into the enclave page cache and that is the enclave that owns the page. The processor will generate an exception-class event if this is not the case. The OS / VMM is responsible for ensuring that the enclave pages are loaded into the EPC as needed.

로직 프로세서가 엔클레이브를 실행하고 있고, 자신의 엔클레이브 페이지로의 메모리 액세스를 생성한다면, 그러한 메모리 액세스는 엔클레이브 액세스 로 지칭된다. 어드레스는 올바른 엔티티에 의해 액세스되는 것을 보장하도록 검사받을 수 있다.If a logic processor is executing an enclave and creates a memory access to its enclave page, such memory access is referred to as enclave access . The address can be checked to ensure that it is accessed by the correct entity.

일 실시예에서, PMH는 프로그램이 엔클레이브에서 실행되지 않을 때 EPC를 보호하기 위한 액세스 제어 기능을 제공한다. 각각의 로직 프로세서에 대해 인에이블되는 범위 레지스터는 프로세서가 엔클레이브 코드를 실행하고 있지 않을 때 EPC로의 액세스를 제한할 것이다. 이 범위 레지스터는 프로세스가 엔클레이브 코드를 실행하기 시작하면 디스에이블된다. 그 곳에서, 프로세서는 특정 페이지 테이블을 제자리에 놓는다. 이들 페이지 테이블은 프로세서에 의해 제어되고 그 엔클레이브에 의해 소유되는 EPC 페이지로의 액세스만을 가능하게 한다. 프로세서 및 마이크로코드는 이들 두 개의 메커니즘을 사용하여 EPC로의 액세스를 제한한다.In one embodiment, the PMH provides access control to protect the EPC when the program is not running in the enclave. An enable range register for each logic processor will restrict access to the EPC when the processor is not executing enclave code. This range register is disabled when a process begins executing enclave code. There, the processor puts a particular page table in place. These page tables allow only access to EPC pages controlled by the processor and owned by the enclave. The processor and microcode use these two mechanisms to restrict access to the EPC.

몇몇 실시예에서, 성능, 구형 복잡도, 및 실리콘 비용을 포함하는 많은 축이되는 방향(axis) 중에 트레이드오프가 이루어질 수 있다. 이 챕터에서는 개발자가 가능한 트레이드오프 중 몇몇을 이해할 수 있도록 세 개의 가능한 구현예가 설명된다. 아래의 표 8-1은 이들 가능한 보호 및 요구되는 PMH 지원을 보여준다.In some embodiments, a tradeoff may be made during many axial axes including performance, spherical complexity, and silicon cost. Three possible implementations are described in this chapter to help developers understand some of the possible tradeoffs. Table 8-1 below shows these possible protections and required PMH support.

[표 8-1]Table 8-1

표 8-1의 제1 행에 도시된 바와 같이, 하나의 추가의 범위 레지스터가 필요한 액세스 제어 보호를 제공하는데 요구되는 전부이다. 이러한 특정 구현예에서, 다른 보호는 마이크로코드 확장에 의해 제공된다. 범위 레지스터는 로직 프로세서를 기초로 인에이블될 수 있다. 이 메커니즘을 사용하는 기본 구현이 도 2-2에 도시되어 있다. As shown in the first row of Table 8-1, one additional range register is all that is required to provide the necessary access control protection. In this particular embodiment, other protection is provided by the microcode extension. The range register may be enabled based on the logic processor. A basic implementation using this mechanism is shown in Figures 2-2.

PMH는 확장된 마이크로코드에서 실행되는 것도 아니고 엔클레이브 모드에서 실행되는 것도 아닌 LP로부터 (CPU 내의 CMRR에 의해 커버되는) CMA 범위로의 액세스를 잘라내는(prune out) 것으로 수정된다. 부가하여, 엔클레이브 모드에서 실행되는 LP는 CMA의 EPC 서브범위를 액세스하도록만 허가받는다.The PMH is modified to prune out access from the LP to the CMA range (covered by CMRR in the CPU) that is not executed in extended microcode or in enclave mode. In addition, LPs running in enclave mode are only allowed to access the EPC subranges of the CMA.

도 15는 본 발명의 일 실시예에서 페이지 폴트 에러 코드 맵이 어떻게 구현될 수 있는지를 도시한다. 비트 5(1540)이 설정될 때, 비트 9, 비트 8, 비트 7 및 비트 6이 함께 디코딩되어 페이지 폴트 에러 코드를 결정한다. res 비트(1512), I/D 비트(1514), RSVD 비트(1516), U/S 비트(1518), W/R 비트(1520), P 비트(1522).15 illustrates how a page fault error code map may be implemented in one embodiment of the invention. When bit 5 1540 is set, bit 9, bit 8, bit 7 and bit 6 are decoded together to determine the page fault error code. res bit 1512, I / D bit 1514, RSVD bit 1516, U / S bit 1518, W / R bit 1520, and P bit 1522.

페이지가 EPC에 제공되지 않을 때, 폴트가 OS/VMM에 제공되어 이 사실을 나타낸다. 페이지 폴트 에러 코드 맵은 표 8-2에 도시된 바와 같이 변경된다. 이것은 폴팅(faulting) 조건을 리포트하는데 사용되는 새로운 비트를 나타낸다. EPC 폴트가 없다면, 비트 5는 제로로 설정되고 비트 6 내지 9 또한 제로로 설정된다. 폴트가 EPC 조건에 기인한 것이라면, 비트 5가 설정될 것이고, 소프트웨어는 EPC 폴팅 조건을 이해하기 위해 비트 6 내지 9f를 디코딩할 수 있다. 폴트 유형에 대한 더 많은 정보는 다음 섹션에서 설명된다.When a page is not provided to the EPC, a fault is provided to the OS / VMM to indicate this fact. The page fault error code map is changed as shown in Table 8-2. This represents a new bit used to report a faulting condition. If there is no EPC fault, bit 5 is set to zero and bits 6 to 9 are also set to zero. If the fault is due to an EPC condition, bit 5 will be set and the software can decode bits 6-9f to understand the EPC fault condition. More information about fault types is described in the next section.

페이지 폴트 에러 코드의 비트 5가 설정될 때, 비트 6 내지 9는 표 8-2에 주어진 바와 같이 해석된다. 이것은 페이지 폴트가 발생하는 조건을 보여준다. 몇몇의 상태는 정상 동작에서는 결코 발생할 수 없는 불법 조건을 나타낸다. 그들은 OS/VMM 관리 에러를 나타낸다.When bit 5 of the page fault error code is set, bits 6 through 9 are interpreted as given in Table 8-2. This shows the condition under which the page fault occurs. Some states represent illegal conditions that can never occur in normal operation. They indicate OS / VMM management errors.

[표 8-2]Table 8-2

공격으로부터 EPC를 보호하기 위해, 플랫폼 상의 모든 TLB에서 EPC 어드레스를 무효화하는 메커니즘이 있을 수 있다. 이 피처는 특정 페이지가 무효화될 것이라는 것을 모든 코어에게 시그널링할 수 있다. 다음에, 모든 프로세서가 셧다운이 완료되었다는 표시를 리턴할 때까지 대기할 수 있다.To protect the EPC from attack, there may be a mechanism to invalidate the EPC address in every TLB on the platform. This feature can signal all cores that a particular page will be invalidated. Next, you can wait until all processors return an indication that the shutdown is complete.

엔클레이브 엑시트, EEXIT가 발생할 때마다, TLB는 TLB에 현재 존재하는 엔클레이브 페이지로의 액세스를 허가하지 않을 수 있다. 이것은 TLB를 클리어링하거나 또는 엔클레이브 엔트리를 태그하기 위한 여분의 비트를 사용함으로써 행해질 수 있다.Each time an enclave exit, EEXIT occurs, the TLB may not allow access to the enclave pages currently present in the TLB. This can be done by clearing the TLB or using extra bits to tag the enclave entry.

하나의 대체예는 모든 엔클레이브 엔트리가 클리어된 엔클레이브 엑시트 상에서 TLB 내의 엔클레이브 비트를 사용한다. 또 다른 대체예는 특정 엔클레이브를 식별하기 위해 몇 개의 비트를 사용한다. 이 경우, 엔클레이브 엔트리는 퇴거될 필요가 없다. 엔클레이브 엔트리는 tlb에 남아 있을 수 있다. 어드레스가 룩업을 위해 tlb로 보내질 때, 이들 비트는 룩업에 첨부된다. 이들 비트는 엔클레이브 아이덴티티를 나타내는 코어로부터의 엔클레이브 id에 비교된다. 비트가 정합하면, 요청이 동일 엔클레이브로부터 나온다. 정합에 실패하면, 요청은 특정 엔클레이브로부터 나오지 않았고 룩업은 그 위치에서 히트(hit)하지 않을 것이다.One alternative uses an enclave bit in the TLB on an enclave exit where all enclave entries are cleared. Another alternative uses several bits to identify a particular enclave. In this case, the enclave entry does not need to be evicted. The enclave entry may remain in tlb. When the address is sent to tlb for lookup, these bits are appended to the lookup. These bits are compared to enclave ids from the core representing the enclave identity. If the bits match, the request comes from the same enclave. If the match fails, the request did not come from the particular enclave and the lookup would not hit at that location.

엔클레이브 인증은, 코드의 저작자/인증자인 엔클레이브 내에서 실행하도록 하는 엔클레이브 코드를 라이센싱한 저작권을 결정하는 수단을 제공한다. 엔클레이브 인증은 또한 엔클레이브 마이크로코드 플로우, Flexible Sealing & Reporting, 뿐만아니라, 다수의 새로운 사업 모델을 위한 강제 포인트(enforcement point)를 아웃소싱하도록 기초(foundation)를 제공한다.Enclave authentication provides a means for determining the copyright licensed enclave code to execute within an enclave that is the author / certifier of the code. Enclave authentication also provides the foundation to outsource enclave microcode flow, Flexible Sealing & Reporting, as well as enforcement points for many new business models.

보안 엔클레이브 아키텍처의 임의의 양상은 복잡하고, 시간 소모의 플로우를 요구하는데, 이는 마이크로코딩된 명령어 내에서 구현하는데 적합하지 않다. 그에 대한 솔루션으로서는 보안 엔클레이브 아키텍처의 부분을 매크로코드로 아웃소싱하는 것이다. 많은 경우에, 아웃소싱된 코드는 민감성 프로세서 또는 플랫폼 데이터로의 특별한 액세스를 요구한다. 예를 들면, EPID 서명은 단일 명령어에 대해 너무 길다. 대신, EPID 개인 키로의 특별한 액세스를 퍼밋함으로써 EPID 서명된 쿼팅을 생성하기 위해 쿼팅 엔클레이브가 사용된다. 엔클레이브 인증은 인텔로 하여금 쿼팅 엔클레이브에 의해서만 EPID 키로의 액세스와 같은 특정 엔클레이브에 대해 퍼밋된 부가의 능력을 특정할 수 있게 한다. 부가의 능력을 갖고 코어 엔클레이브 기능을 구현하는 인텔에 의해 제공되는 엔클레이브가 구조적 엔클레이브로서 지칭된다.Certain aspects of secure enclave architectures are complex and require a time consuming flow, which is not suitable for implementation within microcoded instructions. The solution is to outsource part of the secure enclave architecture to macrocode. In many cases, outsourced code requires special access to sensitive processor or platform data. For example, the EPID signature is too long for a single instruction. Instead, a Quoting Enclave is used to create EPID signed quotes by granting special access to the EPID private key. Enclave authentication allows Intel to specify additional capabilities that are permitted for a particular enclave, such as access to an EPID key only by a quoted enclave. Enclaves provided by Intel that have additional capabilities and implement core enclave functionality are referred to as structural enclaves.

엔클레이브 실링(Sealed) 스토리지는, 로딩 시간 측정과 같은, 엔클레이브의 임의의 속성에 대해 데이터를 암호화하는 능력을 갖는 엔클레이브 소프트웨어를 제공한다. 엔클레이브 검증 프레임워크는 엔클레이브로 하여금 엔클레이브의 측정의 증거를 외부 기관에 제공하도록 할 수 있다. 많은 환경에서, 엔클레이브의 정밀한 소프트웨어 해시보다는 오히려 엔클레이브의 소스로 데이터를 실링하거나 합치는 것이 더 바람직하다.Enclave Sealed Storage provides enclave software with the ability to encrypt data for any attribute of an enclave, such as a load time measurement. The enclave verification framework may allow the enclave to provide external agencies with evidence of the measurement of the enclave. In many circumstances, it is more desirable to seal or merge data into the source of the enclave rather than the precise software hash of the enclave.

일 실시예에서, 인증된 엔클레이브 상의 서명이 검증되면, 엔클레이브를 서명하는데 사용되는 키의 공개 부분이 Sealing & Attestation 메커니즘으로 이용가능하게 되고, 엔클레이브 측정에 기초하는 엄밀한 보호 또는 엔클레이브의 코드의 소스에 기초하는 보다 유연한 보호 간을 벤더(vendor)가 선택할 수 있다.In one embodiment, once the signature on the authenticated enclave is verified, the public portion of the key used to sign the enclave is made available to the Sealing & Attestation mechanism, and the rigid protection or code of the enclave based on the enclave measurement Vendors can choose between more flexible protection based on their source.

엔클레이브 인증은 두 부분으로 분할된다. 각각의 엔클레이브는 서명 체인이 인텔로 다시 루팅(rooted)되면서 엔클레이브 라이센스에 의해 수반된다. 엔클레이브 라이센스는 누가 엔클레이브에 대한 소스/책임있는(accountable) 엔티티인지, 엔클레이브가 요구하는 임의의 특정 능력, 및 이 엔클레이브를 인에이블한 특정 사업 모델/협정을 식별하는데 필요한 임의의 부가의 정보를 나타낸다. 라이센스는 엔클레이브의 측정을 나타내는 특정 엔클레이브에 대한 것일 수 있거나, 또는 필요에 따라 엔클레이브를 서명하도록 허가받은 키를 위한 것일 수 있다.Enclave authentication is divided into two parts. Each enclave is accompanied by an enclave license as the signature chain is rooted back to Intel. An enclave license is who is the source / accountable entity for an enclave, any specific capabilities that the enclave requires, and any additional necessary to identify the specific business model / agreement that enabled this enclave. Represent information. The license may be for a particular enclave representing the measurement of the enclave, or may be for a key authorized to sign the enclave as needed.

예를 들면, A가 A의 비디오 플레이어을 사용하기 위한 엔클레이브를 생성하도록 그들을 인증하는 라이센스를 구매한다. 이를 위해, 인텔은, 인텔이 벤더 A에게 비디오 플레이어 엔클레이브에서의 사용을 허가하는 능력과 함께, 벤더 A의 비디오 플레이어 루트 키에 대한 라이센스를 생성할 수 있다. 벤더 A는 비디오 플레이어 루트 키를 이용하여 그들이 배포하는 각각의 비디오 플레이어 교정판(revision)에 대한 개별적인 라이센스 파일을 서명할 것이다. 이것은 다수의 중간 라이센스를 포함할 수 있는 엔클레이브에 대한 라이센스 체인을 생성한다.For example, A purchases a license that authorizes them to create an enclave for using A's video player. To this end, Intel may generate a license for Vendor A's video player root key, along with the ability of Intel to allow Vendor A to use in the video player enclave. Vendor A will use a video player root key to sign a separate license file for each video player revision they distribute. This creates a license chain for an enclave that can contain multiple intermediate licenses.

서명된 라이센스의 체인은 엔클레이브 론칭 프로세스동안 평가를 위해서는 이상적이지 않고, 따라서, 대신 그들은 퍼밋이라 불리는 단일의 명령어를 간추릴 수 있는(digestible) 구조로 결합된다. 퍼밋은 CMAC 알고리즘을 이용하여 대칭적으로 인증되고 엔클레이브의 초기화(EINIT) 동안 해석된다.The chain of signed licenses is not ideal for evaluation during the enclave launch process, so instead they are combined into a structure that can digest a single instruction called permit. Permits are symmetrically authenticated using the CMAC algorithm and are interpreted during the initialization of the enclave (EINIT).

[표 11-1]Table 11-1

[표 11-2]Table 11-2

라이센스의 구성요소의 대부분은 퍼밋으로 카피되어 유사한 구조를 생성한다. LicenseID는 64 비트의 숫자로 비즈니스 협약을 식별한다. LicenseType은 이 라이센스가 적용되는 플랫폼을 식별한다. 벌크 라이센스는, 보안 엔클레이브를 지원하는 플랫폼 상에서 이 엔클레이브가 시작되도록 허용한다. 플랫폼 당 라이센스는, 플랫폼이 우선 표시된 라이센스 권한(License Authority)를 접촉하도록 요구하고, 엔클레이브를 시작하기 위한 인가를 요청한다. 인가가 주어지면, 라이센스 권한과의 접촉은 더 이상 필요하지 않지만, 이로 인해 라이센스 권한은 비용청구의 목적으로 이 엔클레이브가 배치된 플랫폼의 수를 트랙할 수 있다. 이 엔클레이브를 라이센스한 ISV는 엔클레이브의 이 버전을 위한 보안 버전 숫자를 설정하도록 선택할 수 있다. 이렇게 함으로써, 이 버전에 의해 실링된 데이터는 차후 버전에 사용 가능하도록 될 수 있으나, 이전 버전에는 그렇게 하지 않을 수 있다. Flags 필드는, 이 인가가 적용되기 위해 설정될 수 있는 엔클레이브에 대한 플래그를 표시한다. Capabilities 마스크는 이 엔클레이브에게 주어질 수 있는 특수 능력의 비트 마스크이다. ParentKeyHash는 이 엔클레이브의 라이센스를 서명하며, 그 키를 서명하는 공중 키로 해시된, 공중 키의 해시이다. EntityHash는 이 라이센스가 적용되는 엔터티의 예상되는 해시이다. 엔클레이브의 경우, 이것은 적절히 생성된 엔클레이브에 대한 MR.EADD의 값이다. 라이선싱 키에 대해, 이것은 공중 키의 해시이다.Most of the components of the license are copied into permits to create a similar structure. LicenseID identifies a business agreement as a 64-bit number. LicenseType identifies the platform to which this license applies. The bulk license allows this enclave to be started on platforms that support secure enclaves. The per platform license requires that the platform first contact the indicated License Authority and asks for authorization to start the enclave. Given authorization, no further contact with the license entitlement is required, but this allows the entitlement to track the number of platforms on which this enclave is deployed for billing purposes. The ISV that licensed this enclave may choose to set a secure version number for this version of the enclave. By doing so, the data sealed by this version may be made available to later versions, but not earlier versions. The Flags field indicates the flags for the enclave that this authorization can be set for to apply. Capabilities mask is a bit mask of special capabilities that can be given to this enclave. ParentKeyHash signs the enclave's license and is a hash of the public key, hashed with the public key that signs the key. EntityHash is the expected hash of the entity to which this license applies. For enclaves, this is the value of MR.EADD for the properly generated enclave. For licensing keys, this is a hash of the public key.

라이센스에서, 라이센스를 서명하기 위해 사용된 공중 키는 라이센스 그 자체에 포함되어 있다. 퍼밋은 CPU 키를 사용하여 MAC되어 있다. 적절한 cpuMAC은, 라이센스 체인을 다시 인텔에 유효하게 한 후, EMKPERMIT 명령어가 이 퍼밋을 생성하였음을 나타낸다. LicenseType이 벌크가 아닌 경우, licenseMAC은, 구조적 라이센스 엔클레이브가 적절한 라이센스 권한을 접속하였고, 이 플랫폼이 엔클레이브를 시작할 수 있음을 확인 받았다는 것을 표시한다.In the license, the public key used to sign the license is contained in the license itself. Permit is MACed using a CPU key. The appropriate cpuMAC indicates that the EMKPERMIT instruction generated this permit after validating the license chain back to Intel. If LicenseType is not bulk, licenseMAC indicates that the structured license enclave has connected the appropriate license entitlement and that the platform has been confirmed that it can start the enclave.

모든 엔클레이브가 퍼밋을 요구하는 것은 아니다. 엔클레이브의 개발을 용이하게 하기 위해, 퍼밋은 소프트웨어의 개발 및 디버깅 단계 동안에 선택적일 수 있다. 다음 정책은 EINIT에 의해 실행될 수 있다. 비-디버그 엔클레이브는 항상 퍼밋이 시작되도록 요청한다. 디버그 엔클레이브(Debug Enclave)는 퍼밋없이 시작될 것이다. 그러나, EINIT에 퍼밋이 제시되지 않으면, MR.Policy, IVS Sec Version, Permit Sec Version, 및 Capabilities는 모두 0으로 설정될 것이다.Not all enclaves require a permit. To facilitate the development of the enclave, the permit may be optional during the development and debugging phase of the software. The following policies can be enforced by EINIT. Non-debug enclaves always request a permit to be started. The debug enclave will start without a permit. However, if no permit is specified in the EINIT, then the MR.Policy, IVS Sec Version, Permit Sec Version, and Capabilities will all be set to zero.

디버그 엔클레이브를 시작하는데 퍼밋이 사용되면, permit->Flags[DEBUG]가 설정될 수 있으며, 디버그 엔클레이브에 의해 허용된 능력들만 퍼밋에서 설정될 수 있다.If a permit is used to start a debug enclave, permit-> Flags [DEBUG] can be set, and only the capabilities allowed by the debug enclave can be set in the permit.

도 16은, 본 발명의 일 실시예에서 엔클레이브를 시작하도록 퍼밋을 생성하는 프로세스의 예를 도시한다. 프로세스는 3개의 단계를 가질 수 있다. 즉, 퍼밋 발행(1600), 추가 라이센스 퍼밋(1640), 및 초기화 엔클레이브(1680)를 포함한다. 퍼밋 발행 단계(1600)에서, ISV 키 라이센스(1610)에 대해 EMKPERMIT 명령어(1612)를 실행함으로써 ISV 키 퍼밋(1615)이 생성될 수 있다. CPU 만을 위한 MAC를 갖는 엔클레이브 퍼밋(1625)은, ISV 키 퍼밋(1615) 및 엔클레이브 라이센스(1620)에 대해 EKPERMIT 명령어(1612)를 실행함으로써 생성될 수 있다. 추가의 라이센스 퍼밋 단계(1640)에서, CPU만을 위한 MAC를 갖는 엔클레이브 퍼밋(1625) 및 라이센스될 정보에 대응하는 제3자 엔클레이브가 라이센스 엔클레이브(1644)로 진입하고, 라이센스 엔클레이브(1644)는 CPU 및 라이센스에 대한 MAC를 갖는 엔클레이브 퍼밋(1645)을 생성한다. 초기화 엔클레이브 단계(1680)에서, 엔클레이브 SECS(1682) 및 CPU 및 라이센스에 대한 MAC를 갖는 엔클레이브 퍼밋(1645)는 EINIT(1684)에 대한 입력일 수 있다. EINIT(1684) 명령어의 출력은 ISV 엔클레이브(1685)이다. 16 shows an example of a process for creating a permit to initiate an enclave in one embodiment of the present invention. The process can have three steps. That is, a permit issue 1600, an additional license permit 1640, and an initialization enclave 1680. In the permit issuing step 1600, the ISV key permit 1615 can be generated by executing the EMKPERMIT instruction 1612 for the ISV key license 1610. Enclave permit 1625 with MAC for CPU only can be generated by executing EKPERMIT instruction 1612 for ISV key permit 1615 and enclave license 1620. In an additional license permit step 1640, the enclave permit 1625 with MAC only for the CPU and the third party enclave corresponding to the information to be licensed enter the license enclave 1644, and the license enclave 1644 ) Generates an enclave permit 1645 with a MAC for the CPU and the license. In initialization enclave step 1680, enclave permit 1645 with enclave SECS 1802 and MAC for CPU and license may be input to EINIT 1684. The output of the EINIT 1684 command is an ISV enclave 1685.

엔클레이브를 시작하기 위해, 소프트웨어에 포함된 라이센스로부터 퍼밋이 생성되고, CPU에 제공되어 엔클레이브를 시작할 수 있다. 이 프로세스는 3개로 분할된다. 즉, 퍼밋 발행, 추가 라이센스 퍼밋, 및 엔클레이브 초기화로 분할된다. 참조는 이 프로세스를 통한 흐름을 도시한다.To start an enclave, a permit may be generated from a license included with the software and provided to the CPU to start the enclave. This process is divided into three. That is, issuance of permits, additional license permits, and enclave initializations. Reference shows the flow through this process.

새 명령어 EMKPERMIT가 사용되어 라이센스로부터 퍼밋을 생성하는데 사용된다. EMKPERMIT은 단일 라이센스로부터 단일 퍼밋을 생성하지만, 퍼밋 키를 사용하여 라이센스의 체인을 MAC를 갖는 단일 퍼밋으로 변환하기 위해, 연속적으로 호출될 수 있다. 다음 섹션은 이 프로세스를 더 상세히 설명할 것이다.The new command EMKPERMIT is used to generate a permit from the license. EMKPERMIT generates a single permit from a single license, but can be called in succession to convert the chain of licenses to a single permit with a MAC using the permission key. The next section will explain this process in more detail.

각 라이센스는 라이센스 유형을 포함하며, 이것은 퍼밋이 사용 가능하도록 실행될 수 있는 추가의 단계를 결정한다. 플랫폼 당 라이센스는, 클라우드에서의 라이센스 권한이, 엔클레이브가 배치된 플랫폼의 비용청구 수를 유지하도록 요구할 수 있다. 이 유형의 라이센스에 대해, 추가의 단계가 요구된다. 라이센스 엔클레이브라고 호칭되는 구조적 엔클레이브가 클라우드에서 라이센스 권한과 협상할 것이며, 퍼밋이 있는 경우, 라이센스 키를 사용하여 퍼밋에 대한 추가 MAC를 제공할 것이다. 예를 들어, 구조적 엔클레이브는 항상 벌크 라이센스이며, 이것은 실행을 위해 라이센스 키 MAC를 요구하지 않는다는 것을 의미한다. 이들은 보안 엔클레이브를 지원하는 임의의 플랫폼 상에서 실행된다.Each license includes a license type, which determines the additional steps in which the permit can be executed to make it available. The license per platform may require that the license entitlement in the cloud maintains the billing number of the platform on which the enclave is deployed. For this type of license, additional steps are required. A structural enclave, called a license enclave, will negotiate with license entitlements in the cloud and, if there is a permit, use a license key to provide additional MAC for the permit. For example, an architectural enclave is always a bulk license, which means that it does not require a license key MAC for execution. They run on any platform that supports secure enclaves.

엔클레이브 초기화에서, 퍼밋이 실행된다. 초기화 동안에, 퍼밋이 처리되며, 엔클레이브 측정이 퍼밋 내의 것과 일치하고, MAC이 정확하면, 엔클레이브가 시작된다. EINIT는 라이센스 유형을 볼 것이며, 추가의 퍼밋을 요구하는 라이센스를 위한 라이센스 MAC를 검사만 할 것이다.In enclave initialization, a permit is executed. During initialization, the permit is processed, and if the enclave measurement matches that in the permit, and the MAC is correct, the enclave begins. EINIT will look at the license type and will only check the license MAC for licenses that require additional permits.

EMKPERMIT은, 라이센스에 대한 RSA 서명을 퍼밋하는데 요구되는 시간 때문에, 특권 명령어이다. 이 명령어는, uCode 패치 포맷에 첨부되어, 이것을 퍼밋하고, 그 컨텐츠로부터 퍼밋을 생성하는 매우 단순한 서명된 인증서(credential)이다. 라이센스는, 그것을 서명하는데 사용되는 키의 공중 부분과 서명 모두를 포함한다. 이것은 uCode로 하여금 라이센스 서명 키의 해시를 저장하게만 하고, 인텔 서명 라이센스를 유효하게 한다. EMKPERMIT은 또한, ISV 키의 권한 받은 퍼밋을 제공하기 위해, 이들 키에 의해 서명된 라이센스를 유효화할 수 있다. 이것은, ISV 공중 키의 해시를 포함하는 퍼밋을 생성함으로써 달성된다. 그 결과, 제2 퍼밋에서 제공되는 해시를 갖는 ISV 키 또는 내부 해시를 사용하여 인텔 라이센스를 퍼밋할 수 있다.EMKPERMIT is a privileged command because of the time required to permit RSA signature for a license. This command is a very simple signed credential that attaches to the uCode patch format, commits it, and generates a permit from its contents. The license includes both the public part of the key and the signature used to sign it. This only allows uCode to store a hash of the license signing key and validates the Intel signed license. EMKPERMIT may also validate licenses signed by these keys to provide authorized permissions of the ISV keys. This is accomplished by generating a permit containing a hash of the ISV public key. As a result, the Intel license can be authorized using an internal hash or an ISV key with a hash provided by the second permit.

EMKPERMIT은, 라이센스에 대한 포인터, 키 퍼밋에 대한 선택적 포인터, 및 출력 퍼밋에 대한 포인터를 포함하는, 3개의 파라미터를 취한다. 인텔이 서명한 라이센스에 대해, 키 퍼밋은 무효(null)이고, 퍼밋 파라미터의 내부적으로 하드코딩된 집합이 사용된다. 호출 메소드(calling method)가 사용되어 구조적 엔클레이브의 라이센스를 유효화하고 그것을 위한 퍼밋을 생성한다. EMKPERMIT은, uCode(포함된 공중 키의 해시를 내부 해시와 비교함으로써)에 의해 라이센스 내의 공중 키를 검증하도록 한다.EMKPERMIT takes three parameters, including a pointer to a license, an optional pointer to a key permit, and a pointer to an output permit. For Intel-signed licenses, the key permit is null and an internal hardcoded set of permit parameters is used. The calling method is used to validate the license of the structural enclave and generate a permit for it. EMKPERMIT allows you to verify the public key in the license by uCode (by comparing the hash of the embedded public key with the internal hash).

ISV의 경우, ISV의 키는 인텔에 의해 서명된 라이센스를 가질 것이다. 키 퍼밋 없이 EMKPERMIT을 호출함으로써, 인텔 키 해시를 사용하여 라이센스에 대한 서명을 검증하고, ISV 키의 해시가 합법적인 라이센스 서명 키를 나타내도록 인증하는 퍼밋을 생성할 것이다. EMKPERMIT이 두번 째로 호출되어 ISV의 키의 퍼밋을 포함한다. EMKPERMIT은 키 퍼밋의 MAC를 유효화하고, 사전에 인텔 해시를 사용하였던 ISV 키의 해시를 사용한다. 엔클레이브 라이센스 내의 공중 키를 ISV 키의 값으로 해시하며, 엔클레이브 라이센스는 이것에 의해 적절히 서명되는 것으로 가정하면, EMKPERMIT는 엔클레이브를 위한 퍼밋을 생성할 것이다. 이 퍼밋은, (전체 체인를 통해 일관성이 있을 수 있는) 라이센스 정보, 라이센스 체인에서 모든 공중 키의 해시, 엔클레이브의 측정, 및 그 능력을 표시한다. In the case of an ISV, the ISV's key will have a license signed by Intel. By calling EMKPERMIT without a key permit, you will use Intel key hash to verify the signature on the license, and generate a permit that authenticates the hash of the ISV key to represent a legitimate license signing key. EMKPERMIT is called a second time, containing the permit of the ISV's key. EMKPERMIT validates the MAC of the key permit and uses the hash of the ISV key that previously used the Intel hash. Assuming that the public key in the enclave license is hashed with the value of the ISV key, and the enclave license is properly signed by it, EMKPERMIT will generate a permit for the enclave. This permit displays license information (which may be consistent throughout the entire chain), a hash of all public keys in the license chain, the measurement of the enclave, and its capabilities.

EMKPERMIT 동안에 u-code에 의해 다음 단계가 실행된다.During EMKPERMIT, the next step is executed by u-code.

1. 파라미터를 스크래치 패드(scratch pad)로 카피한다 (레이스 조건 공격에 대한 보호). 1. Copy the parameters to the scratch pad (protection against race condition attack).

2. 라이센스에서 공중 키의 해시를 계산한다. 2. Calculate the hash of the public key in the license.

3. 키 퍼밋 == NULL이면, 3. If key permit == NULL,

a. 라이센스 공중 키 해시 = 인텔 키 해시인지 또는 실패인지 검증한다. a. Verify that License Public Key Hash = Intel Key Hash or Fail.

4. 그렇지 않으면, 4. Otherwise,

a. 퍼밋 키를 사용하여 키 퍼밋의 MAC를 검증한다. a. Use the permit key to verify the MAC of the key permit.

b. 라이센스 공중 키 해시 = 키 퍼밋의 EntityHash인지 또는 실패인지 검증한다. b. Verify that the license public key hash = EntityHash of the key permit or fail.

5. PubKey로 인증서의 서명을 검증한다. 5. Verify the signature of the certificate with PubKey.

6. 라이센스와 키 퍼밋 사이에서 License Info, Capabilities, 및 Flags가 일관성 있는지 확인한다. 6. Verify that License Info, Capabilities, and Flags are consistent between the license and the key permit.

7. 다음을 갖는 퍼밋을 생성한다. 7. Create a permit with:

a. PubKeyHash = Hash(KeyPermit.Hash, Hash(License PubKey)) a. PubKeyHash = Hash (KeyPermit.Hash, Hash (License PubKey))

b. Capabilities = KeyPermit.Capabilities & License.Capabilities b. Capabilities = KeyPermit.Capabilities & License.Capabilities

c. Measurement = License.Measurement c. Measurement = License.Measurement

d. ISV SVN = License SVN d. ISV SVN = License SVN

e. Flags = License Flags e. Flags = License Flags

8. KeyID = 코어에서의 현재 KeyID KeyID = current KeyID in the core

9. cpuMAC = 퍼밋 키를 이용하여 계산된 CMAC 9. cpuMAC = CMAC calculated using Permit Key

10. licenseMAC = 0x0000…0000 10. licenseMAC = 0x0000.. 0000

라이센스 엔클레이브는, uCode에 대한 시인성(visibility) 범위 밖에서 시작되는 엔클레이브에 관한 결정을 하도록 설계된다. 예를 들어, uCode는, ISV의 인텔과의 비즈니스 협약이 추가의 엔클레이브 배치를 허용하는지를 평가할 수 없다. 라이센스 엔클레이브는, 엔클레이브 시작을 평가하고, 퍼밋하거나 거부하는데 필요한 모든 자료들을 수집하도록 설계된다. 라이센스 엔클레이브는, 복잡한 비즈니스 협약을 지원하도록만 요구되며, 필요한 만큼의 많은 플랫폼에서 엔클레이브를 시작하는 능력과 같은 벌크 라이센스에 대해서는 필요하지 않다. The license enclave is designed to make decisions about enclaves that start outside the scope of visibility for uCode. For example, uCode cannot evaluate whether an ISV's business agreement with Intel allows for further enclave deployments. The license enclave is designed to collect all the materials needed to evaluate, permit or reject enclave initiation. License enclaves are only required to support complex business agreements and are not required for bulk licenses such as the ability to initiate enclaves on as many platforms as needed.

라이센스 엔클레이브는, 시스템 서비스일 것으로 예상된다. 라이센스가 라이센스 엔클레이브로부터 추가의 승신을 필요로 했다고 표시하면, EMKPERMIT에 의해 생성된 엔클레이브 퍼밋 및 라이센스의 체인이 라이센스 엔클레이브로 전달된다. 라이센스 엔클레이브는 퍼밋 요청을 생성한다. 애플리케이션은 이 퍼밋 요청을 적절한 라이센스 권한에게 전송하고, 이것은 퍼밋 통지를 생성한다. 이것은 다시 라이센스 엔클레이브로 전달되고, 라이센스 엔클레이브는 라이센스 키를 사용하여licenseMAC 필드에서 퍼밋을 MAC한다.The license enclave is expected to be a system service. If the license indicates that additional entitlement was required from the license enclave, the enclave permit and chain of licenses generated by EMKPERMIT are passed to the license enclave. The license enclave generates a permit request. The application sends this permit request to the appropriate license entitlement, which generates a permit notification. This is passed back to the license enclave, which uses the license key to MAC the permit in the licenseMAC field.

엔클레이브에 대해 퍼밋이 발행되면, 이것은 엔클레이브 시작 프로세스에서 u-code에 의해 평가되고 실행될 수 있다. 이것은 EINIT 명령어의 일부로 행해지며, 이는 파라미터로 퍼밋의 선형 주소를 취한다. 다음 추가 단계가 권한 받은 엔클레이브(Authenticated Enclave) 매커니즘의 일부로 EINIT에 추가된다.Once a permit is issued for an enclave, it can be evaluated and executed by u-code in the enclave start process. This is done as part of the EINIT command, which takes the linear address of the permit as a parameter. The next additional step is added to EINIT as part of the Authorized Enclave mechanism.

1. 퍼밋을 스크래치 패드에 카피한다. 1. Copy the permit to the scratch pad.

2. 퍼밋 키를 사용하여 퍼밋에 대해 cpuMAC를 검증한다. 2. Use the permit key to verify cpuMAC against the permit.

3. LicenseType != Bulk이면, 라이센스 키를 사용하여 licenseMAC를 검증한다. 3. If LicenseType! = Bulk, verify the licenseMAC using the license key.

4. 퍼밋에서의 측정을 SECS 내의 MR.EADD과 비교한다. 4. Compare the measurement at the permit with MR.EADD in SECS.

5. 퍼밋 내의 Flags를 SECS 내의 플래그와 비교한다. 5. Compare the Flags in the Permit to the flags in the SECS.

6. 퍼밋 내의 Pubkey Hash를 MR.Policy로 카피한다. 6. Copy the Pubkey Hash in the permit into MR.Policy.

7. ISV SVN을 SECS로 카피한다. 7. Copy ISV SVN to SECS.

8. 퍼밋 내의 Capability 맵을 SECS로 카피한다. 8. Copy the Capability Map in Permit to SECS.

CapabilitiesCapabilities

현재 능력(capability) 맵은 이 엔클레이브에 사용 가능한 능력의 128 비트 마스크이다.The current capability map is a 128 bit mask of the capabilities available for this enclave.

[표 11-3]Table 11-3

공간은 EINIT에 의해 취해질 동작에 기초하여 조직된다. 비트 00-03, 링 레벨 제한이 이 엔클레이브에 활성화됨에 따라 미래에 사용되기 위해 예비된다. 04-07은 미래에 어떤 페이지 보호가 허용되는지 나타내도록 예비된다. 08-23은 EGETKEY를 통해 사용 가능한 프로세서 키이다. 24-31은, 검증을 위한 이름 기초 모드를 사용하는 것과 같은 다른 제어를 위한 것이거나, 제한하고자 하는 미래 기술을 위한 것이다. 특정 능력은 디버그 모드에서 엔클레이브에 의해 전혀 사용되지 않을 수 있다. Debug 컬럼은 디버그 모드에서 능력이 적법하게 사용될 것인지를 나타낸다.The space is organized based on the action to be taken by the EINIT. Bits 00-03, ring level restrictions are reserved for future use as they are activated in this enclave. 04-07 is reserved to indicate which page protection is allowed in the future. 08-23 are processor keys available through EGETKEY. 24-31 are for other controls, such as using a name based mode for verification, or for future technology to be limited. Certain capabilities may not be used at all by the enclave in debug mode. The Debug column indicates whether the capability will be used legally in debug mode.

미래 생성에서, 비트 00은 링 레벨 및 VT 제한이 이 엔클레이브에 적용됨을 나타낼 수 있다. 비트 01-02는 엔클레이브가 실행되도록 허용되는 링 레벨을 나타내며, 비트 02는 엔클레이브가 VT 루트 모드에서 실행되는지를 나타낸다. 각 EENTER에서, 현재 CPL은 비트 01-02에 대해 비교될 수 있으며, 이로 인해 이 엔클레이브가 이 링 레벨에서 실행되도록 허용되는지 결정된다. 잘못된 링에서 실행되도록 시도된다면, EENTER는 실패할 것이다. 유사하게, 링 제한이 활성화되면, 비트 03이 온(on)일 때, 엔클레이브는 VT 루트 모드로부터만 진입될 것이다. 첫번째 생성에서, 이들 비트는 MBZ이다.In future generations, bit 00 may indicate that ring level and VT restrictions apply to this enclave. Bit 01-02 indicates the ring level at which the enclave is allowed to run and bit 02 indicates whether the enclave is running in VT root mode. In each EENTER, the current CPL can be compared against bits 01-02, which determines if this enclave is allowed to run at this ring level. If you try to run on the wrong ring, EENTER will fail. Similarly, if ring restriction is enabled, when bit 03 is on, the enclave will only enter from VT root mode. In the first generation, these bits are MBZ.

엔클레이브 페이지는 암호화되거나 완전성 보호만 될 수 있다. 또한, 페이지는 실행될 수 있거나 아닐 수 있다. 미래 생성에서, 이들 속성은 트랙되며, EPCM의 보안 정보 부분에서 실행될 수 있다. 이들 능력은 예비되어, 페이지가 실행 가능한지 및 엔클레이브가 이미 EINIT되었는지에 기초하여, 엔클레이브에서 페이지를 엔클레이브 하기 위한 암호화의 적용을 제어한다.Enclave pages can be encrypted or only complete protection. In addition, the page may or may not be executed. In future generations, these attributes are tracked and can be executed in the security information portion of the EPCM. These capabilities are reserved to control the application of encryption to enclave a page in an enclave based on whether the page is executable and whether the enclave has already been EINIT.

많은 구조적 엔클레이브는 CPU 내에서 또는 CPU에 의해 보호되는 키에 대한 액세스를 요구하는 Ring 3 엔터티이다. EGETKEY는 이들 키에 대한 액세스를 제공하는 반면, 능력 비트는 EGETKEY에 의해 사용되어 키에 대한 액세스가 허용될 수 있는지 결정한다.Many architectural enclaves are Ring 3 entities that require access to keys protected in or by the CPU. The EGETKEY provides access to these keys, while the capability bits are used by the EGETKEY to determine if access to the key can be allowed.

다음은 속성과 요약 설명을 포함하는 현재 구조적 엔클레이브의 리스트이다.The following is a list of the current structural enclaves, including their attributes and a summary description.

제공 엔클레이브(Provisioning Enclave)는, KEY_PROVISION 능력을 갖고 인텔에 의해 인증되었으며, 새로운 장치 검증 키(Device Attestation Key, DAK) 또는 제공 검증 키(Provisioning Attestation Key, PAK)가 요구될 때마다 단일 패키지 플랫폼 상에서 실행된다. 이 목적은, EGETKEY에 의해 제공되는 제공 씨드(Provisioning Seed)에 기초하여, 엔클레이브가 장치 ID 및 제공 키(Device ID & Provisioning Key)를 유도하도록 허용하는 것이다. 제공 엔클레이브는 이들 키를 이용하여, 제공 서버에게 플랫폼의 권한을 증명하고, DAK를 검색한다. DAK를 검색한 후, 제공 클레이브는 그것을 실링하여, 쿼팅 엔클레이브가 그것을 검색할 수 있도록 한다. 제공 엔클레이브는 선택적으로 DAK를 사용하여 플랫폼 검증 키(Platform Attestation Key, PAK) 제공자로 인증을 수행하고 PAK를 재시도한다. PAK를 이용함으로써, 특정 ISV에 대해 그 활동이 그 플랫폼의 이전 소유자의 그것과 연관되지 않도록 함으로써, 사용자를 위한 더 좋은 개인 정보 보호를 제공한다. PAK를 검색한 후, 제공 엔클레이브는 이것을 실링하여 쿼팅 엔클레이브가 검색할 수 있도록 한다.Provisioning Enclave is certified by Intel with KEY_PROVISION capability and is available on a single package platform whenever a new Device Attestation Key (DAK) or Provisioning Attestation Key (PAK) is required. Is executed. This purpose is to allow the enclave to derive a Device ID & Provisioning Key based on the Providing Seed provided by the EGETKEY. The provisioning enclave uses these keys to prove the platform's authority to the provisioning server and retrieve the DAK. After retrieving the DAK, the serving clave seals it, allowing the quoted enclave to retrieve it. The serving enclave optionally uses the DAK to authenticate with the Platform Attestation Key (PAK) provider and retry the PAK. By using a PAK, for a particular ISV, the activity is not associated with that of the previous owner of the platform, thereby providing better privacy for the user. After retrieving the PAK, the serving enclave seals it so that the Quoting Enclave can retrieve it.

능력 KEY_REPORT를 갖고 엔클레이브에 의해 인증된 쿼트 엔클레이브는 EPID 키를 제공하는데 사용되는 제공 엔클레이브(전형적으로는 인텔) 동일한 저자를 갖는다. 이것의 위치는 모든 앱에게 이용가능한 OS 서비스이다. 이것의 목적은 엔클레이브가 플랫폼 EPID 키를 언실링하게 하는 것이다. EPREPORT로부터의 레포트는 입력으로서 제공된다. 엔클레이브는 EGETKEY를 사용하여 레포트 키를 검색한다. 레포트 키는 다음에 레포트를 검증하는데 사용된다. 엔클레이브는 EPID를 이용하여 쿼트를 서명한다. A quart enclave with the capability KEY_REPORT and authenticated by the enclave has the same author as the provisioning enclave (typically Intel) used to provide the EPID key. Its location is an OS service available to all apps. The purpose of this is to allow the enclave to unseal the platform EPID key. Reports from EPREPORT are provided as input. The enclave retrieves the report key using EGETKEY. The report key is then used to verify the report. The enclave signs the quotes using the EPID.

능력 KEY_LICENCE를 갖고 인텔에 의해 인가되고 루트 인텔에 의해 서명되는 라이센스 엔클레이브가 엔클레이브(OS Service)에 단독으로 인스턴스되어 장착된다. 이것의 목적은 복잡한 라이센스 정책을 평가하는 것이다. 엔클레이브가 라이센스 엔클레이브로부터 부가의 라이센스 확인을 요구하면, EINIT는 라이센스 엔클레이브가 라이센스 키를 사용한 후 그것을 단지 CMAC 퍼밋으로 수용할 것이다.A license enclave licensed by Intel with the capability KEY_LICENCE and signed by the root Intel is instantiated and mounted solely on the OS Service. The purpose of this is to evaluate complex license policies. If the enclave requires additional license verification from the license enclave, EINIT will only accept it as a CMAC permit after the license enclave uses the license key.

단일 패키지 시스템에서, 엔클레이브의 아키텍처에 의해 사용되는 모든 대칭 키는 프로세서의 퓨즈 어레이에 저장된 고유의 단일 소스로부터 유도된다. 키 계층은, 플랫폼 구현에 의존하는 SE TCB 계층, 및 그 구조가 모든 보안 엔클레이브 구현에 걸쳐 lf관된 SE 키 계층으로 분할된다. TCB 복원을 위한 키잉 재료 및 EPID 제공의 설립이 SE 키 계층을 위해 루트로서 서빙하는 SE TCB 계층에 의해 제공된다. 엔클레이브 명령어 내 및 신뢰의 구조적 엔클레이브 양쪽에서 사용되는 모든 키 재료는 SE 키 계층에 의해 제공된다.In a single package system, all the symmetric keys used by the architecture of the enclave are derived from a unique single source stored in the fuse array of the processor. The key layer is divided into an SE TCB layer that depends on the platform implementation, and an SE key layer whose structure is related to all secure enclave implementations. The establishment of keying material and EPID provision for TCB recovery is provided by the SE TCB layer serving as the root for the SE key layer. All key material used in both the enclave instruction and in the structural enclave of trust is provided by the SE key hierarchy.

플랫폼은 퓨즈에 두 개의 128 비트 고유 키를 제공한다. 이들 키는 비밀 CPU 로직에 저장된 키를 사용하여 퓨즈에서 암호화된다. 몇개의 단일 목적의 키는 이 키에서 유도되고, TCB 복원 기술은 플랫폼의 요구사항에 기초하여 적용된다. 그 결과의 키가 SE 키 계층에서 루트로서 서빙한다.The platform provides two 128-bit unique keys for the fuses. These keys are encrypted in fuses using keys stored in secret CPU logic. Several single purpose keys are derived from this key, and TCB reconstruction techniques are applied based on platform requirements. The resulting key serves as the root in the SE key hierarchy.

구조적 엔클레이브를 위한 키는 EGETKEY 명령어를 이용하여 검색된다.The key for the structural enclave is retrieved using the EGETKEY instruction.

엔클레이브 아키텍처는 또는 플랫폼 외부의 시스템에 대한 REPORT 값의 검증을 제공하기 위해 비대칭 키의 사용을 요구한다. 이 키, EPID 키는 초기에 퓨즈에 제공되지만, 배치 후 키 계층으로부터 유도되는 키들 중 하나를 이용하여 다시 제공될 수 있다. EPID 검증 키를 제공하는 방법은 본 명세서의 범위 밖이다. 더 많은 정보는 DAK(Device Attestation Key) 제공 명세서에서 발견될 수 있다.The enclave architecture also requires the use of asymmetric keys to provide verification of REPORT values for systems outside the platform. This key, the EPID key, is initially provided in the fuse, but can be provided again using one of the keys derived from the key hierarchy after deployment. The method of providing an EPID verification key is outside the scope of this specification. More information can be found in the Device Attestation Key (DAK) Provisioning Specification.

마지막으로, 엔클레이브의 아키텍처는 또한 OEM에서 키 재료를 제공하기 위해 모든 프로세서의 로직에 있는 키를 이용한다. 이 키는 Out-of-Box Experience Global Key로서 알려져 있다. 우리는 ISV 고유성을 제공하기 위해 이 키에 유사한 유도 연산을 수행한다. OOB 키로부터 유도된 이들 키가 ISV에 의해 어떻게 사용되는ㅈ는 본 명세서의 범위 밖이다.Finally, the enclave's architecture also uses keys in the logic of every processor to provide key material from the OEM. This key is known as the Out-of-Box Experience Global Key. We perform a similar derivation operation on this key to provide ISV uniqueness. How these keys derived from OOB keys are used by ISVs is outside the scope of this specification.

키 계층의 SE TCB 부분은 플랫폼에 특정되지만, 모든 기초는 동일한 기본 키들의 세트를 요구한다. 우리는 이들을 베이스 키로 지칭한다. 그들은 모두 퓨즈 키 및 로직 키에서 유도되고, SE 키 계층의 루트이다. 이들 키는 다음에 SSE 명령어에 의해 사용되어 SE 아키텍처에 직접적으로 사용되는 모든 키를 유도한다. 이들 키는 TCB 키 계층의 결과이다. 플랫폼 특정 메커니즘에 의해 SE 아키텍처에 이용가능하게 되는 네 개의 SE Base Key 더하기 EPID 컴포넌트가 있다. 표 12-1은 이들 키 각각을 설명한다.The SE TCB portion of the key hierarchy is platform specific, but all foundations require the same set of basic keys. We refer to them as base keys. They are both derived from fuse keys and logic keys and are the root of the SE key hierarchy. These keys are then used by SSE instructions to derive all the keys used directly in the SE architecture. These keys are the result of the TCB key hierarchy. There are four SE Base Key plus EPID components that are made available to the SE architecture by platform specific mechanisms. Table 12-1 describes each of these keys.

[표 12-1]Table 12-1

도 17은 본 발명의 실시예를 위해 단일 패키지 보안 엔클레이브에 대한 플랫폼의 가능한 구현예를 도시한다. 아웃 오브 더 박스 베이스 키(1700)는 이용가능한 유도 자원(1750)으로부터 도출(1702)되어, 아웃 오브 더 박스 키(1704)를 생성한다. 이용가능한 유도 리소스(1750)는 고정 값(1752), 소유자 에폭크(1754), 보안 엔클레이브 보안 버전(1756), SECS 측정 레지스터(1758), ISV 보안 버전(1760) 및 SECS 플래그(1762)를 포함하는 요소를 갖는 스트링(1752)이다. 제공 키(1710)는 인텔 백엔드에 대한 플랫폼의 인증을 증명할 수 있다. EPID(1712)는 서명 키이다. 초기 safeID 키 블로브(1718)는 쿼트(quote)이고 safeID 시드(1716)과 연관되어 있다. 베이스 옵스 키(1714)는, 엔클레이브 키(1730), 퍼밋 키(1732), 라이센스 키(1734), 레포트 키(1736), 인증 키(1738) 및 실 키(1740)을 포함하는 일련의 키를 유도(1720)하기 위해 이용가능한 유도 자원(1750)으로부터 정보를 조합할 수 있다.17 illustrates a possible implementation of a platform for a single package secure enclave for an embodiment of the invention. Out of the box base key 1700 is derived 1702 from available derived resources 1750 to generate out of the box key 1704. Available derivation resources 1750 include fixed values 1756, owner epoch 1754, secure enclave secure version 1756, SECS measurement registers 1758, ISV secure version 1760, and SECS flag 1762. A string 1702 having an element to contain. The provisioning key 1710 may prove the platform's authentication to the Intel backend. EPID 1712 is a signature key. The initial safeID key blob 1718 is a quote and is associated with the safeID seed 1716. The base ops key 1714 is a series of keys including an enclave key 1730, a permit key 1732, a license key 1734, a report key 1736, an authentication key 1738, and a real key 1740. Information may be combined from the derived resources 1750 available to derive 1720.

도 17a는 멀티패키지 키 계층의 일 실시예를 도시한다.17A illustrates one embodiment of a multipackage key hierarchy.

보안 엔클레이브 명령어 및 데이터 구조는 재료를 키잉(keying)하기 위한 소스로서 베이스 키에 의존한다. 표 12-1에 도시된 플랫폼 키 계층은 플랫폼 키 재료의 계층적 관계 및 키가 플랫폼 루트 키로부터 어떻게 유도되는지를 설명한다.Secure enclave instructions and data structures rely on the base key as a source for keying material. The platform key hierarchy shown in Table 12-1 describes the hierarchical relationship of platform key material and how the key is derived from the platform root key.

엔클레이브 랩핑 키(1752)는 보안 엔클레이브 제어 구조(SECS) 페이지를 암호화하는데 사용되는 대칭 키이지만, 이것은 엔클레이브 페이지 캐시(EPC) 내부에 보호되지 않는다. 이 키는 단지 uCode에 의해 사용된다.Enclave wrapping key 1752 is a symmetric key used to encrypt a secure enclave control structure (SECS) page, but it is not protected inside the enclave page cache (EPC). This key is only used by uCode.

퍼밋 키(1754)는 엔클레이브에 대한 능력 및 라이센싱 정보를 포함하는 퍼밋에 대한 인증 및 무결성을 제공하는데 사용된다. 퍼밋은 자신들의 무결성을 보장하기 위해 MAC되지만, EINIT로 전이한다. 이 키는 EMKPERMIT uCode 및 EINIT에 의해 사용된다.Permit key 1754 is used to provide authentication and integrity for the permit, including the capability and licensing information for the enclave. Permits are MAC to guarantee their integrity, but transition to EINIT. This key is used by EMKPERMIT uCode and EINIT.

라이센스 키(1756)는 uCode에 의해 평가될 수 없는 라이센스 정책을 갖는 컴플라이언스를 표명하는데 사용된다. 라이센스 키는 EINIT에 의해 평가되는 라이센스 엔클레이브로부터의 인증된 승인을 생산하는데 사용된다. 이 키는 EINIT uCode에 의해 사용되고, KEY_LICENSE 능력 세트를 갖는 엔클레이브에게 EGETKEY를 통해 이용가능하다.License key 1756 is used to assert compliance with a license policy that cannot be evaluated by uCode. The license key is used to produce an authorized approval from the license enclave that is evaluated by EINIT. This key is used by EINIT uCode and is available via EGETKEY to enclaves with the KEY_LICENSE capability set.

레포트 키(1758)는 레포트에 대한 인증 및 무결성을 제공하는데 사용된다. 레포트는 자신들의 무결성을 보장하는 한편 쿼팅 엔클레이브로 전이하는 ERPEPORT에 의해 MAC된다. 이 키는 EREPORT uCode에 의해 사용되었고, QUOTE 능력 세트를 갖는 엔클레이브에게 EGETKEY를 통해 이용가능하다.The report key 1758 is used to provide authentication and integrity for the report. Reports are MACed by an ERPEPORT that transitions to the Quoting Enclave while ensuring their integrity. This key was used by the EREPORT uCode and is available via EGETKEY to enclaves with the QUOTE capability set.

소유자 키(1760)는 엔클레이브 특정 키이고, 쿼팅 엔클레이브로부터 ISV 엔클레이브로 전송되는 데이터에 대해 인증 및 무결성을 제공하는데 사용되고, 동일 플랫폼 상에서 엔클레이브 대 엔클레이브 인증을 가능하게 한다. 이 키는 EGETKEY를 통해 모든 엔클레이브에게 이용가능하고, ISV_AUTH 능력을 갖는 엔클레이브는 어떤키를 요구하는지를 특정할 수 있다.The owner key 1760 is an enclave specific key and is used to provide authentication and integrity for data sent from the quoted enclave to the ISV enclave, enabling enclave to enclave authentication on the same platform. This key is available to all enclaves via EGETKEY, and an enclave with ISV_AUTH capability can specify which key to request.

실 키(1762)는 자신들의 민감한 데이터를 암호화하기 위해 128 비트 키를 각각의 엔클레이브를 제공한다. 다수의 실링 정책은, 소프트웨어가 자신들의 데이터를 언실링할 것에 대해 ISV가 유연성을 제공하는, 실 키로 통합될 수 있다. 이들 키는 EGETKEY를 통해 임의의 엔클레이브에게 이용가능하지만, 개별적으로 실 키는 요청되는 실 정책을 만족시키는 엔클레이브에게만 이용가능하다.The real key 1762 provides each enclave with a 128 bit key to encrypt their sensitive data. Multiple sealing policies can be incorporated into a real key, which ISVs provide flexibility for software to unseal their data. These keys are available to any enclave via EGETKEY, but individually the real key is only available to enclaves that satisfy the requested real policy.

EPID ID(1712)는 패키지를 고유하게 식별한다. 이것의 유일한 목적은, EPID 기반 익명의 검증 키인 디바이스 검증 키의 제공을 가능하게 하는 것이다. EPID ID는 유일하게 제공 엔클레이브에게 액세스가능하다. 제공 엔클레이브는 이것을 단지 보안 채널을 거쳐, 사용자 또는 연산 시스템에 의해 개시되는 비저닝 프로세스 동안에만, 승인된 제공 서버로 제공할 것이다. 이 ID는 PROVISIONING 능력을 갖는 엔클레이브에게 EGETKEY를 통해 이용가능하다.EPID ID 1712 uniquely identifies the package. Its sole purpose is to enable the provision of device verification keys, which are EPID based anonymous verification keys. The EPID ID is only accessible to the serving enclave. The provisioning enclave will only provide this to the authorized provisioning server, over the secure channel, during the visioning process initiated by the user or computing system. This ID is available via EGETKEY to enclaves with PROVISIONING capability.

제공 키(1710)는 인텔 백엔드에 대한 플랫폼의 인증을 증명하고 현재의 SE TCB 러닝을 인증하는데 사용된다. 제공 키로의 액세스를 수용함으로써, 제공 서버는 엔클레이브가 사실상 EPID ID의 소유인 디바이스이고, 적어도 특정 TCB 보안 버전을 실행 중이라는 것을 보증한다. 제공 키는 그것을 요청하는 제공된 엔클레이브의 서명자 및 이 패키지에 고유하다. 이것은 단일 플랫폼 상에서 하나 이상이 사용된다면, 제공 기반구조들 간에 분리를 생성한다. 이 키는 KEY_PROVISION 능력을 갖는 엔클레이브에게 EGETKEY를 통해 이용가능하다.The provisioning key 1710 is used to verify the platform's authentication to the Intel backend and to authenticate the current SE TCB learning. By accepting access to the provisioning key, the provisioning server ensures that the enclave is in fact a device owned by the EPID ID and is running at least a particular TCB secure version. The provisioning key is unique to this package and the signer of the provided enclave requesting it. This creates a separation between serving infrastructures if more than one is used on a single platform. This key is available via EGETKEY to enclaves with the KEY_PROVISION capability.

제공 실 키는 소유주의 변경 후에라도 검색될 수 있는 방식으로 제공을 암호화하도록 128-비트 키를 제공 엔클레이브에게 제공한다. 이 키는 플랫폼이 호출되지는 않았지만 새로운 EPID를 획득하였다는 것을 증명하기 위해 구 EPID를 암호화하는데 사용된다. 제공 키는 그것을 요청하는 제공된 엔클레이브의 서명자 및 이 패키지에 고유하다. 이것은 단일 플랫폼 상에서 하나 D상이 사용된다면 제공 기반구조들 간에 분리를 생성한다. 이 키는 KEY_PROVISION 능력을 갖는 엔클레이브에게 EGETKEY를 통해 이용가능하다.The serving seal key provides the serving enclave with a 128-bit key to encrypt the offering in a way that can be retrieved even after the owner's change. This key is used to encrypt the old EPID to prove that the platform has not been called but has obtained a new EPID. The provisioning key is unique to this package and the signer of the provided enclave requesting it. This creates a separation between serving infrastructures if one D phase is used on a single platform. This key is available via EGETKEY to enclaves with the KEY_PROVISION capability.

ISV Out of Box(OOB) Experience Key(1700)는 모든 인텔 플랫폼과 ISV 간의 공유키이다. 이 키는 특정 ISV에 고유하게 OOB Root로부터 유도된다. ISV는, 그들이 이 키에 대한 비밀을 암호화하고 OEM의 하드 디스크 이미지에 배치되게 하는 것을 가능하게 하면서, 이 키로의 액세스를 구매할 수 있다. 이들 비밀은 보안 엔클레이브에서 안전하게 실행되는 자신들의 코드에만 액세스가 가능할 것이고, 플랫폼이 온라인으로 나가거나 완전한 키 검증 프로세스를 진행하는 것을 요구하지 않는다. 이들 키는 OOB 능력을 갖는 엔클레이브에게 EGETKEY를 통해 이용가능하다.The ISV Out of Box (OOB) Experience Key (1700) is a shared key between all Intel platforms and ISVs. This key is derived from the OOB Root unique to a particular ISV. The ISV can purchase access to this key, enabling them to encrypt the secret for this key and place it in the OEM's hard disk image. These secrets will only be accessible to their code running securely in a secure enclave and do not require the platform to go online or go through a complete key verification process. These keys are available via EGETKEY to enclaves with OOB capability.

제공된 키는 보안 엔클레이브 아키텍처에 대해 중요하지만, 플랫폼 키잉 재료로부터 유도되는 것은 아니다. 이들 키는 제공 서버 또는 오프라인 기술로부터 제공된다. 디바이스 검증 키(DAK)는 각각의 엔클레이브의 특성에 대해 검증하기 위해 사용하는 익명의 서명키이다. 이것은 민감한 정보가 자신들의 언탬퍼드 애플리케이션의 보호된 인스턴스로 단지 보내지는 것을 보장하도록 키 또는 비밀 제공 동안 ISV에 의해 사용될 수 있다.The provided key is important for the secure enclave architecture but is not derived from the platform keying material. These keys are provided from a provisioning server or offline technology. The device verification key (DAK) is an anonymous signing key used to verify the characteristics of each enclave. This can be used by the ISV during key or secret provisioning to ensure that sensitive information is only sent to a protected instance of their untampered application.

디바이스 검증 키을 위해 두 가지 소스가 있다. 바람직한 아키텍처는 EPID Key Blob 및 EPID 엔트로피로서 퓨즈에 압축된 초기 DAK를 장착한다. 이것은 플랫폼이 제1 파워 온 직후에 검증을 실행가능하게 한다. 제2 소스는 DAK 제공 서버를 접촉하고, EPID ID 및 제공 키를 사용하여 하드웨어의 합법성을 증명한 후 다운로드하는 것이다. 이 제2 방법은 퓨즈된 EPID 키뿐만 아니라 우리가 하지의 TCB의 버전을 호출한 후 임의의 플랫폼을 갖지 않는 플랫폼에 의해 사용된다. EPID 퓨즈는 PROVISIONING 능력을 갖는 엔클레이브에게 EGETKEY를 통해 액세스 가능하다. There are two sources for device verification keys. The preferred architecture is to mount the initial DAK compressed in the fuse as an EPID key blob and EPID entropy. This allows the platform to execute the verification immediately after the first power on. The second source is to contact the DAK provisioning server, verify the legitimacy of the hardware using the EPID ID and the provisioning key, and download it. This second method is used not only by a fused EPID key but also by a platform that does not have any platform after we call the version of TCB of Haji. EPID fuses are accessible via EGETKEY to enclaves with PROVISIONING capability.

플랫폼 검증 키(PAK)는 프라이버시의 선택적인 부가 레벨을 제공한다. DAK의 임의의 사용과 연관될 수 있다. 특히, ISV 엔클레이브가 이름 기반 검증 능력을 갖는다면, 단일 ISV는 주어진 EPID가 그 서비스를 수정하는지를 결정할 수 있다. (그러나, 다수의 ISV는 사용자를 트랙킹하도록 공모할 수 없다.) DAK가 소유자라기보다는 플랫폼으로 한정되기 때문에, 이 관계는 워터폴(waterfall) 이벤트를 통해 계속된다. 따라서, 몇몇 사용자는 매일 검증을 사용하기 위해 PAK를 발행할 제3자에게 자신들의 플랫폼의 합법성을 표명하도록 자신들의 DAK를 사용하는 것이 바람직할 것이다. 멀티-패키지 플랫폼에서, 각 패키지의 DAK는 검증시에 플랫의 전체를 나타내는 PAK를 확립하는데 사용된다.Platform Validation Key (PAK) provides an optional additional level of privacy. It can be associated with any use of the DAK. In particular, if an ISV enclave has name-based verification capability, a single ISV can determine if a given EPID modifies that service. (However, many ISVs cannot conspire to track users.) Because the DAK is platform specific rather than owner, this relationship continues through a waterfall event. Thus, some users will want to use their DAK to assert the legitimacy of their platform to a third party who will issue a PAK to use daily verification. In a multi-package platform, the DAK of each package is used to establish a PAK representing the entirety of the flat upon verification.

사용자 액세스 가능 키를 위한 키 유도는 NIST 스페셜 공개 800-108(의사 난수 함수를 사용하는 키 도출용 추천)과 부합할 것이다. 키 유도 함수의 구성 시에, 의사 랜덤 함수(PRF)가 필요하다. PRF는 NIST SP 800-38B, 연산의 블록 암호 모드에 대한 추천 - 인증을 위한 CMAC 모드, 2005년 5월, CMAC 에 정의된 AES-CMAC에 기초할 것이다. (http://csrc.nist.govv/publications/nistpubs/800-108/sp800-108.pdf). 키 유도는 일반적으로 다음과 같이 보인다:Key derivation for a user accessible key will be consistent with NIST Special Publication 800-108 (Recommendation for Key Derivation Using Pseudo Random Function). In constructing the key derivation function, a pseudo random function (PRF) is required. The PRF will be based on AES-CMAC as defined in NIST SP 800-38B, Recommendation for Block Cipher Mode of Operations-CMAC Mode for Authentication, May 2005, CMAC. (http: //csrc.nist.govv/publications/nistpubs/800-108/sp800-108.pdf). Key derivation generally looks like this:

유도 스트링은 요청되는 특정 키에 기초하여 8개 요소의 서브세트로 구성된다. 표 12-2는 유도의 일부일 수 있는 각각의 이용가능한 요소를 설명한다.The derived string consists of a subset of eight elements based on the specific key requested. Table 12-2 describes each available element that may be part of the derivation.

[표 12-2]Table 12-2

각각의 키는 유도 스트링을 구성할 미리 정해진 유도 요소들의 집합을 구비한다. 표 12-3은 키 계층으로부터 키 각각에 어떤 요소가 포함되는지를 설명한다. 각각의 행은 키를 나타내고, 행은 그 키에 특정 요소가 포함되는지를 나타낸다. 요청 엔클레이브의 SECS가 디버그 모드에 있다는 것을 나타내면 디버그 스트링이 포함되고, "요청"은 이 요소가 요구되는 것이 아니라 그 키를 유도하기 위해 요청에서 선택가능하다는 것을 나타낸다.Each key has a predetermined set of induction elements that will make up the induction string. Table 12-3 describes what elements are included in each key from the key hierarchy. Each row represents a key and the row indicates whether the key contains a specific element. A debug string is included if the SECS of the request enclave is in debug mode, and a "request" indicates that this element is not required, but selectable in the request to derive its key.

[표 12-3]Table 12-3

소프트웨어의 분리 및 복원을 위한 보안 엔클레이브 지원 기술은 부트 시퀀스의 몇몇 포인트에서 타협한다(compromise). 분리를 지원하기 위해, 엔클레이브에 제공되는 모든 긴 용어 키잉(keying) 재료는 현재 TCB의 보안 버전을 사용하여 유도된다.Secure enclave support techniques for detaching and restoring software compromise at some point in the boot sequence. To support separation, all long term keying material provided to the enclave is derived using the secure version of the current TCB.

이 섹션은 플랫폼의 복원가능한 TCB가 uCode, MCHECK로 구성되는 예시적 아키텍처를 설명하고, 마이크로코드 확장(또는 uVMM)이 설명될 것이다. 하드웨어 요구사항은 임의의 SE 지원 플랫폼에 대해 동일하지만, 정확한 키 플로우는 특정 TCB 요소에 의존한다. 여기서 그들에게 적용되는 유사한 기술을 사용하여 다른 플랫폼이 지원받을 수 있다. Patch-at-Reset을 지원하는 플랫폼을 위해, 이 메커니즘은 uCode 개정들 간의 분리된 업그레이드 및 암호의 증빙을 포함하는, uCode의 완전한 복원을 가능하게 하도록 Patch-at-Reset을 나타낸다(compliment).This section describes an example architecture in which the platform's resilient TCB consists of uCode, MCHECK, and microcode extensions (or uVMM) will be described. The hardware requirements are the same for any SE supported platform, but the exact key flow depends on the specific TCB element. Other platforms can be supported here using similar techniques that apply to them. For platforms that support Patch-at-Reset, this mechanism represents a Patch-at-Reset to enable full restoration of uCode, including separate upgrades between uCode revisions and proof of password.

다음의 키는 CPU 기반 보호 기술을 지원하기 위해 하드웨어에서 요구된다. 이들 키는 TCB 키 계층의 기초이다.The following keys are required in hardware to support CPU-based protection techniques. These keys are the basis of the TCB key hierarchy.

스텝핑 -특정 256-비트 로직 키 : 256-비트 로직키는 두 부분 - 128-비트 퓨즈 래핑 키, 및 128-비트 아웃-오브-박스 경험 키로 분해된다. 그러나, 더 많은 uCode를 부가하는 양자 모두에 대해 단일의 128-비트 키를 사용하는 것이 가능하다. Stepping -Specific 256-Bit Logic Key : The 256-bit logic key is broken down into two parts-a 128-bit fuse wrapping key, and a 128-bit out-of-box experience key. However, it is possible to use a single 128-bit key for both adding more uCode.

퓨즈 키의 다이 -특정 544 비트 : 이것은 32 비트 그룹 id, 256 비트 SafeId A.x 값, 및 프리-씨드의 256 비트를 포함한다. A.x 값 및 256-비트 프리-씨드는 전술한 128-비트 퓨즈 래핑 키로 암호화된다. Die -specific 544 bits of the fuse key : This includes a 32 bit group id, a 256 bit SafeId Ax value, and 256 bits of the pre-seed. The Ax value and 256-bit pre-seed are encrypted with the 128-bit fuse wrapping key described above.

임시 레지스터 : 키-유도 프로세스는 저장되고 vozlw 상에 그리고 uCode에 대해서만 이용가능한 키를 요구한다. 플랫폼 런타임의 듀레이션 동안 두 개의 128 비트 레지스터가 필요하다. CMA가 업 및 런닝할 때까지 EPID 키에 대해 추가의 256 비트 공간이 필요하다. 그 후 추가의 256 비트는 CPU에서 더 이상 필요치 않다. Temporary Registers : Key-derived processes require keys that are stored and available only on vozlw and for uCode. Two 128-bit registers are required during the duration of the platform runtime. Additional 256 bit space is required for the EPID key until the CMA is up and running. After that, an additional 256 bits are no longer needed on the CPU.

TCB SVN 레지스터 : 이 레지스터는 각각의 TCB 레이어에 대해 SVN을 홀드하도록 서브분할된다. 특정 서브분할은 플랫폼 설계자의 재량이지만, 8개의 8비트 SVN이 바람직할 수 있다. 이 레지스터의 각각의 세션은 독리적으로 잠금가능할 수 있다. TCB SVN register : This register is subdivided to hold the SVN for each TCB layer. The particular subdivision is at the discretion of the platform designer, but eight 8-bit SVNs may be desirable. Each session of this register may be uniquely lockable.

TCB 버전의 특정 세트로의 키들의 결합은 시작할 부트 시퀀스의 유형(즉, 리셋에서의 패치 또는 그 후의 패치)에 기초하여, uCode가 퓨즈된 키로부터 제1 키 세트를 유도하게 함으로써 달성된다. 이 후, 퓨즈가 잠금되고, 유도의 체인이 부트 시퀀스의 각 노드에서 발생한다.The combination of keys into a particular set of TCB versions is achieved by having uCode derive the first set of keys from the fused key based on the type of boot sequence to start (ie, a patch at reset or a later patch). After this, the fuse is locked and a chain of induction occurs at each node of the boot sequence.

저레벨 코드가 로딩된 후, 체인은 엔클레이브에서 실행중인 소프트웨어에 대한 ISV 할당 보안 버전을 계속해서 포함한다. 임의의 특정 구성에 대해, 현재의 버전으로부터 유도된 키 및 이전 구성으로부터의 키가 액세스가능하다. 이것은 더 새로운 약점이 없는(non-vulnerable) 끊임없는(seamless) 사용자 데이터 전이를 가능하게 한다.After the low level code is loaded, the chain continues to contain an ISV-assigned secure version of the software running in the enclave. For any particular configuration, keys derived from the current version and keys from the previous configuration are accessible. This enables newer non-vulnerable seamless user data transitions.

다이-특정 키가 생성되면, 이것은 키 래핑 키로 암호화된다. 이것은 하드웨어 모니터링 툴로 키를 추출하는 데 어려움을 증가시킬 뿐만 아니라 부분적으로 쌓이기 전에 통행시 키들에 대해 보호를 제공한다.Once a die-specific key is generated, it is encrypted with a key wrapping key. This not only increases the difficulty of extracting keys with hardware monitoring tools, but also provides protection for keys in transit before they are partially stacked.

이들 키를 암호화하는데 사용되는 암호 알고리즘은 128 비트 AES-ECB 암호해독의 10 라운드이다. 키 생성 서버는 AES-ECB 암호를 각각의 키에 적용하여 퓨즈에서 버닝될(burned) 암호 텍스트 키를 생성할 것이다.The encryption algorithm used to encrypt these keys is 10 rounds of 128-bit AES-ECB decryption. The key generation server will apply an AES-ECB cipher to each key to generate a cipher text key that will be burned in the fuse.

TCB 키 계층에서 키의 유도를 위해 사용되는 PRF(Pseudorandom Function)은 플랫폼에 특정적이다. 우리는 AES-NI을 지원하는 플랫폼을 위해 128 비트 AES-ECB를 추천한다. 목표는 다른 키로부터 키를 유도하기 위해 비가역적인(non-reversible) 방식을 제공하는 것이다. 이 섹션을 위해, 우리는 다음의 기능적 원형을 사용한다.Pseudorandom Functions (PRFs) used for derivation of keys in the TCB key hierarchy are platform specific. We recommend 128-bit AES-ECB for platforms that support AES-NI. The goal is to provide a non-reversible way to derive a key from another key. For this section, we use the following functional prototypes.

PRF에 대하여 키 유도에 사용되는 세 개의 방식이 있다. uCode SVN을 키에 넣기 위해 PRF Loop Derivation이 사용되는 한편, 상이한 SVN들의 키들 간의 관계를 설정한다. 특히, There are three methods used for key derivation for PRF. uCode Sets the relationship between the keys of different SVNs, while PRF Loop Derivation is used to put the SVN into the key. Especially,

이것은 데이터의 순방향 이동을 제공한다. uCode SVN 3을 실행하는 예를 들어보자. 엔클레이브는 EGETKEY를 사용하여 이 버전(PRFLoop(3))을 기초로 실 키(seal key)를 검색한다. 필드에서 uCode 패치 업그레이드가 전달되고 그 다음 부트 uCode SVN은 4이다. 업그레이드 후, EGETKEY 구현은 PRFLoop(4)를 액세스할 것이다. 엔클레이브가 EGETKEY로부터 SVN 3을 요청할 때 PRFLoop(3)=PRF_PRFLoop ₍₄₎를 계산할 수 있고 따라서 이전의 실 키를 검색할 수 있다.This provides forward movement of the data. For example, let's run uCode SVN 3. The enclave uses EGETKEY to retrieve the seal key based on this version (PRFLoop (3)). UCode patch upgrade is passed in the field, and the next boot uCode SVN is 4. After the upgrade, the EGETKEY implementation will access the PRFLoop (4). When the enclave requests SVN 3 from EGETKEY _{, it} can compute PRFLoop (3) = PRF _PRFLoop ₍₄₎ and thus retrieve the previous real key.

이 특성을 확립하기 위해, PRF의 루프가 사용되지만, PRFLoop(x-1)이 PRFLoop(x)로부터 계산되는 특성 때문에, 우리는 최대의 SVN을 확립하고 그로부터 다시 카운트할 필요가 있다. 패치의 유사성 및 요구되는 성능에 기초하여 각각의 플랫폼 유형에 대해 특정 맥스(maxes)가 확립될 필요가 있을 것이다. 우리는 초기 맥스 포인트로서 32를 추천한다.To establish this property, a loop of PRF is used, but because of the property that PRFLoop (x-1) is calculated from PRFLoop (x), we need to establish the maximum SVN and count again from it. Specific maxes will need to be established for each platform type based on the similarity of the patches and the required performance. We recommend 32 as the initial max point.

PRF Loop 유도의 적용은 일반적으로 다음과 같다:The application of PRF Loop derivation is generally as follows:

이 방법은 uCode의 SVN을, SE 베이스 키 후의 하부 키가 될 SVN 키에 넣는데 사용될 것이다. 퓨즈 내의 다이-특성 키는 288 비트 EPID 값 및 256 비트 랜덤 키를 포함한다. 이들 256 비트로부터, 2개의 128 비트 키로 구성되는 모든 비일시적(non-ephemeral) 대칭 키가 유도될 수 있다. 따라서, 단일 키로부터 다수의 키를 유도하는 기술이 생성될 수 있다. 이를 위해, 퓨즈 키가 암호해독 되고, 우리는 이것을 상이한 고정 상수를 이용하는 PRF라 부른다.This method will be used to put the ucode's SVN into the SVN key that will be the subkey after the SE base key. The die-specific key in the fuse includes a 288 bit EPID value and a 256 bit random key. From these 256 bits, all non-ephemeral symmetric keys consisting of two 128 bit keys can be derived. Thus, techniques for deriving multiple keys from a single key can be generated. For this purpose, the fuse key is decrypted and we call it PRF using different fixed constants.

키 분할의 적용은 일반적으로 다음과 같다:The application of key partitioning is generally as follows:

이 기술은 EPID ID의 부분 및 제공 ID로서 사용되는 난수를 생성하는데 사용된다.This technique is used to generate random numbers that are used as part of the EPID ID and as the provided ID.

SVN 키가 uCode SVN에 기초하여 루프 유도되었다면, SE CMA와 같은 보호되는 메모리에서 떨어져서 저장될 수 있다. 확장 마이크로코드는 SVN 키로부터 키를 단지 유도하기 위해서 확장 마이크로코드에 노출되는 MSR을 사용할 것이다. MSR은 유도를 위한 기초가 글로벌 아웃 오프 박스 키인지 또는 퓨즈 키인지를 나타내는 키 선택기, 및 각각의 TCB 계층에 대하여 요청된 SVN들의 세트를 취한다. 이것은 요청이 현재의 값보다 작은지 또는 동일한지를 검증한다. uCode는 구 SVN 키를 검색하기 위해 임의의 필요한 PRF를 적용하고, PRF는 요청 TCB SVN이다.If the SVN key is loop derived based on uCode SVN, it can be stored away from protected memory such as SE CMA. The extended microcode will use the MSR exposed to the extended microcode just to derive the key from the SVN key. The MSR takes a key selector indicating whether the basis for derivation is a global out off box key or a fuse key, and a set of requested SVNs for each TCB layer. This verifies whether the request is less than or equal to the current value. uCode applies any necessary PRF to retrieve the old SVN key, which is the requesting TCB SVN.

적절한 SVN 키가 이용가능하다면, 이 키는 요청된 TCB SVN에 걸쳐 CMAC을 위한 키로서 사용된다. 다음에, 확장 마이크로코드는 이것을 Ops 키를 위한 SE Ops Seed(인텔에 의해 알려지지 않은 퓨즈 키의 부분으로부터 유도된 값), 또는 제공 베이스 키를 위한 고정 스트링으로서 사용한다.If an appropriate SVN key is available, this key is used as the key for the CMAC across the requested TCB SVN. The extended microcode then uses it as a SE Ops Seed for the Ops key (a value derived from a portion of the fuse key not known by Intel), or as a fixed string for the providing base key.

도 18은 본 발명의 일 실시예에서의 마이크로코드 기반 보안 엔클레이브 키 계층의 예를 도시한다. 리셋 마이크로코드(1800) 계층에서, 글로벌 래핑 로직 키(1801) 및 인텔 공지 고유 루트 퓨즈(1802)가 언랩(1806) 함수으로의 입력이다. 언랩(1806) 및 마이크로코드 SVN(1805)의 출력이 PRF 루프(1808)로 입력된다. 마이크로코드 SVN(1805) 및 글로벌 루트 로직 키(1803)는 또 다른 PRF 루프(1809)로 입력된다. PRF 루푸(1808)의 출력은 SVN 키(1810) 레지스터에 저장된다. PRF 루프(1809)의 출력은 글로벌 키 레지스터(1812)에 저장된다. 마이크로코드 SVN(1805)는 레지스터(1814)에 저장된다. 글로벌 래핑 로직 키(1801) 및 SSE EPID A.x 퓨즈(1893)는 언랩(1807) 함수으로의 입력이고 그 결과가 SE EPID(1816) 레지스터에 저장된다. MCheck(1820) 계층에서, MCheck SVN(1821) 및 TCB SVN 레지스터(1814)의 출력은 TCB SVN 레지스터(1826)에 저장된다. SVN 키 레지스터(1810)는 마이크로코드 SVN 레지스터(1822)에 저장된다. 글로벌 키 레지스터(1812)는 글로벌 키 레지스터(1824)에 저장된다. SE EPID(1816)는 SE EPID(1828)에 저장된다. 로드 마이크로코드(1830) 계층에서, 마이크로코드 SVN(1831) 및 TCB SVN 레지스터(1826)의 출력은 TCB SVN 레지스터(1846)에 저장된다. 마이크로코드 SVN 레지스터(1822)는 마이크로코드 SVN 레지스터(1832)에 저장된다. 글로벌 키 레지스터(1824)는 글로벌 키 레지스터(1834)에 저장된다. SE EPID(1828)는 SE EPID(1838)에 저장된다. XuMSR 유도 키(1840) 계층에서, 마이크로코드 SVN 디퍼런스(1841)은 PRF 루프(1842) 및 PRF 루프(1844)로 입력된다. 마이크로코드 SVN(1832) 레지스터는 데이터를 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) 계층에서, 인텔이 알지 못하는 고유 루트 퓨즈(1894)는 시드1(1856)에 저장되는 한편, EPID 그룹 ID 퓨즈는 EPID 그룹(1858)에 저장된다. 시드1(1856)은 PRF 루프(1886) 및 PRF 루프(1888)에 입력된다. PRF 루프(1888)의 출력은 SE EPID 시드1(1892)이다. PRF 루프(1886)의 출력은 SE ops 시드(1890)이다. SVN 베이스 키(1850)로부터 나오는 SE ops 시드(1890) 및 요청된 SVN(1864)은 CMAC(1868) 함수에 입력되어 SE ops 키(1872)를 생성한다. SVN 베이스 키(1850)로부터 나오는 현재의 SVN(1862)는 CMAC(1866) 함수에 입력되어 SE 제공 키(1870)를 생성한다. SVN 베이스 키가 {0,0,0}(1874)와 동일할 때, SVN 베이스 키(1850)는 시드0(1876)에 저장된다. 시드0(1876)은 PRF 루프(1878) 및 PRF 루프(1880)로 입력된다. PRE 루프(1878)의 출력은 SE EPID ID(1882)이고, PRF 루프(1880)의 출력은 SSE EPID 시드0(1884)이다.18 illustrates an example of a microcode based secure enclave key hierarchy in one embodiment of the present invention. In the reset microcode 1800 layer, the global wrapping logic key 1801 and the Intel-known unique root fuse 1802 are inputs to the unwrapping 1806 function. The output of unwrap 1806 and microcode SVN 1805 is input to PRF loop 1808. Microcode SVN 1805 and global root logic key 1803 are entered into another PRF loop 1809. The output of the PRF loop 1808 is stored in the SVN key 1810 register. The output of the PRF loop 1809 is stored in the global key register 1812. Microcode SVN 1805 is stored in register 1814. The global wrapping logic key 1801 and the SSE EPID A. x fuse 1893 are inputs to the unlab 1807 function and the result is stored in the SE EPID 1816 register. In the MCheck 1820 layer, the outputs of the MCheck SVN 1821 and TCB SVN register 1814 are stored in the TCB SVN register 1826. The SVN key register 1810 is stored in the microcode SVN register 1822. The global key register 1812 is stored in the global key register 1824. SE EPID 1816 is stored in SE EPID 1828. In the load microcode 1830 layer, the output of the microcode SVN 1831 and the TCB SVN register 1826 is stored in the TCB SVN register 1846. The microcode SVN register 1822 is stored in the microcode SVN register 1832. Global key register 1824 is stored in global key register 1834. SE EPID 1828 is stored in SE EPID 1838. At the XuMSR inference key 1840 layer, the microcode SVN difference 1841 is input to a PRF loop 1842 and a PRF loop 1844. The microcode SVN 1832 register sends data to the PRF loop 1842 and the global key register 1834 sends the data to the PRF loop 1844. The output of the PRF loop 1842 and the output of the TCB SVN register 1836 are input to the PRF loop 1846 and the output of the PRF loop 1844 and the output of the TCB SVN register 1836 are input to the PRF loop 1848 do. The output of the PRF loop 1846 is stored in the SVN base key 1850, and the output of the PRF loop 1848 is stored in the global key 1852. In the microcode 1860 layer, a unique root fuse 1894 unknown to Intel is stored in seed 1 1856, while the EPID group ID fuse is stored in EPID group 1858. Seed 1 1856 is input to PRF loop 1864 and PRF loop 1888. The output of the PRF loop 1888 is SE EPID seed1 1892. The output of the PRF loop 1886 is the SE ops seed 1890. SE ops seed 1890 coming from SVN base key 1850 and requested SVN 1864 are input to CMAC 1868 function to generate SE ops key 1872. The current SVN 1862 coming from the SVN base key 1850 is input to the CMAC 1866 function to generate the SE provided key 1870. When the SVN base key is equal to {0,0,0} (1874), the SVN base key 1850 is stored at seed 0 (1876). Seed 0 1876 is input to PRF loop 1878 and PRF loop 1880. The output of PRE loop 1878 is SE EPID ID 1882 and the output of PRF loop 1880 is SSE EPID seed0 1884.

모든 코어는 동기되고 그들이 도어벨 또는 유사한 메커니즘을 이용하는 MCHECK 내의 모든 것이라는 것을 보장한다. 모든 코어가 실행중인 MCHECK이면, BSP에 의해 다음 단계가 취해진다. AP는 키 플로우에 참가하지 못한다:All cores are synchronized and ensure that they are all in MCHECK using a doorbell or similar mechanism. If all cores are running MCHECK, the next step is taken by the BSP. The AP does not participate in the key flow:

1. uCode는 퓨즈를 판독, 암호해독 및 잠근다.1. uCode reads, decrypts, and locks fuses.

2. uCode는 PRF 루프를 SVN 키에 적용하고, PRF 루프를 uCode의 SVN을 양쪽 키에 주입하는 OOBE 키에 적용한다. uCode는 자신의 SVN을 TCB SVN 레지스터에 기록하고 그 부분을 잠근다.2. uCode applies the PRF loop to the SVN key and applies the PRF loop to the OOBE key that injects the uCode's SVN into both keys. uCode writes its SVN to the TCB SVN register and locks it.

3. MCHECK 로더(loader) 또는 얼리(early) MCHECK 코드는 MCHECK의 SVN을 TCB SVN 레지스터에 기록하고 그것을 잠근다.3. MCHECK loader or early MCHECK code writes MCHECK's SVN into the TCB SVN register and locks it.

4. 마이크로코드 확장 패치 로더는 마이크로코드 확장 패치 SVN을 TCB SVN 레지스터에 기록하고 그것을 잠근다.4. The microcode extension patch loader writes the microcode extension patch SVN to the TCB SVN register and locks it.

확장 마이크로크드 초기화 동안 또는 EGETKEY를 호출 시에, 확장 마이크로코드는 요청을 만족시키는데 필요한 SE 베이스 키를 계산한다. 베이스 키는 향상된 성능을 위해 미래의 사용을 위해 CMA에서 캐싱될 수 있다.During extended microcode initialization or when calling EGETKEY, the extended microcode calculates the SE base key needed to satisfy the request. The base key can be cached in the CMA for future use for improved performance.

[표 12-4]Table 12-4

사용자 프라이버시 및 플랫폼 워터폴(waterfall)에 걸친 데이터를 보호하기 위해, 256-비트 랜덤 소유자 에포크가 키의 유도에 포함된다. 이 값은 소유권 변경 동안 무작위로 생성된다. 엔클레이브 키의 사용 이전에, 소프트웨어는 OwnerEpoch를 SE_EPOCH_MSR에 기록할 수 있다. 이것은, 플래시에 영구적으로 저장하는 BIOS에 의해 달성될 수 있다. 이것은 사용자 부트 패스워드의 해시와 같은 몇몇의 사용자 입력으로부터 계산될 수 있다. 이것은 또한 엔클레이브를 사용할 수 있기 전에 보안 엔클레이브 드라이버에 의해 제공될 수 있다.To protect data across user privacy and platform waterfalls, a 256-bit random owner epoch is included in the derivation of the key. This value is generated randomly during ownership change. Prior to the use of the enclave key, the software may write the OwnerEpoch to SE_EPOCH_MSR. This can be accomplished by a BIOS that permanently stores in flash. This can be calculated from some user input, such as a hash of the user boot password. This may also be provided by the secure enclave driver before the enclave can be used.

이 값의 신뢰성은, 플랫폼에 의해 암호화된 데이터가 워터폴 후 랩톱을 소유하는 누군가에 의해 암호화되는 것을 보장하는데 요구된다. 이 값을 타협한다고 해서 임의의 엔클레이브 데이터를 타협하는 것은 아니다.The reliability of this value is required to ensure that data encrypted by the platform is encrypted by someone who owns the laptop after the waterfall. Compromising this value does not compromise any enclave data.

SE Key Info 구조는 메모리 또는 패키지의 보호 영역에 저장되는 비영구적 구조이다. CMA는 가장 유사한 위치이지만, 다이 보호 스토리지 상의 어느 곳도 좋다. 파워 온 동안, SE Key Info가 초기화된다. KeyID는 랜덤 값으로 설정되고, 키 카운트는 0으로 설정된다. 엔클레이브 키, 퍼밋 키, 레포트 키의 각각의 사용 시에, KeyID가 판독되고, 키 카운트가 증분된다. 2^32 키 사용 후, KeyID는 새로운 램덤 값으로 변경되고, 키 카운트는 0을 리셋된다. SE Key Info 레이아웃이 5에 도시되어 있다.The SE Key Info structure is a non-persistent structure stored in a protected area of memory or a package. CMA is the most similar location, but it can be anywhere on die protected storage. During power on, SE Key Info is initialized. KeyID is set to a random value and the key count is set to zero. In each use of the enclave key, permit key, and report key, the KeyID is read and the key count is incremented. After using the 2 ^ 32 key, the KeyID is changed to the new random value and the key count is reset to zero. The SE Key Info layout is shown in 5.

[표 12-5]Table 12-5

파워 온 시에, 플랫폼 키 테이블이 uCode에 의해 초기화된다. BIOS 또는 다른 호스트 펌웨어는 영구 스토리지로부터 또는 사용자로부터 현재의 오너 에포크를 요구하고 그것을 LoadOwnerEpochMSR에 기록한다. 이 시점에서, 엔클레이브 키 계층이 이용가능하다.At power on, the platform key table is initialized by uCode. The BIOS or other host firmware requests the current owner epoch from permanent storage or from the user and writes it to LoadOwnerEpochMSR. At this point, the enclave key hierarchy is available.

대부분의 엔클레이브의 아키텍처는 엔클레이브 데이터의 인증 및 신뢰성을 제공하기 위해 키의 사용에 의존하고, 프로세서 복잡도를 최소로 유지하기 위해, 구조적 엔클레이브를 사용하여 고레벨 사용을 위해 이들 키를 처리한다. 예를 들면, 쿼팅 엔클레이브는, EREPORT 명령어에 의해 생성된 REPORT 구조가 플랫폼 상에 생성되었다는 것을 확립하는데 REPORT 키를 사용하고, PERMITING 엔클레이브는 엔클레이브가 론칭 중일 때 EINIT에 의해 소비되는 엔클레이브 PERMIT을 생성하기 위해 PERMIT 키를 사용한다.Most enclave architectures rely on the use of keys to provide authentication and reliability of enclave data, and use architectural enclaves to process these keys for high level use to keep processor complexity to a minimum. For example, the Quoting Enclave uses the REPORT key to establish that the REPORT structure generated by the EREPORT instruction has been created on the platform, and the PERMITING Enclave consumes enclave PERMIT when the enclave is launching. Use the PERMIT key to generate

임의의 애플리케이션 레벨에 부가하여, 엔클레이브는 엔클레이브 외부의 플랫폼 상에 저장되는 비밀을 실링(seal)하기 위해 키로 액세스할 필요가 있고, 애플리케이션 엔클레이브가 재확립될 때 언실링(unsealed)될 것이다.In addition to any application level, the enclave will need to access with a key to seal the secrets stored on the platform outside the enclave and will be unsealed when the application enclave is reestablished. .

이를 행하는 메커니즘이 EGETKEY 명령어이다. 이것은 현재 소프트웨어 환경에 관해 비밀을 확립하는 단일 인터페이스이다.The mechanism for doing this is the EGETKEY command. This is a single interface for establishing a secret about the current software environment.

EGETKEY는 현재 다음의 키로의 액세스를 제공한다:EGETKEY currently provides access to the following keys:

ㆍ PROVISIONING KEY ID - 프로세서에 대해 (PROVISIONING KEY를 사용하여) 고유하게 암호화된 데이터블로브(datablob)를 식별하기 위해 구조적 제공 엔클레이브에 의해 사용됨.PROVISIONING KEY ID-used by the structured provisioning enclave to identify a uniquely encrypted datablob (using PROVISIONING KEY) for the processor.

ㆍ PROVISIONING KEY - 프로세서에 대해 고유하게 암호화된 데이터 블로브를 암호해독하기 위해 구조적 제공 엔클레이브에 의해 사용됨.PROVISIONING KEY-Used by structured serving enclaves to decrypt data blobs that are uniquely encrypted to the processor.

ㆍ PROVISIONING SEAL KEY - 엔클레이브가 오너 변경 후라도 EPID를 암호해독할 수 있도록 EPID를 암호화하기 위해 구조적 제공 엔클레이브에 의해 사용됨.PROVISIONING SEAL KEY-Used by the structured provisioning enclave to encrypt the EPID so that the enclave can decrypt the EPID even after the owner change.

ㆍ PERMIT KEY - PERMIT를 생성하기 위해 구조적 퍼밋팅 엔클레이브에 의해 사용됨.PERMIT KEY-used by structural permitting enclaves to generate PERMITs.

ㆍ REPORT KEY - REPORT 구조를 검증하기 위해 구조적 쿼팅 엔클레이브에 의해 사용됨.REPORT KEY-Used by the structured Quoting Enclave to verify the REPORT structure.

ㆍ ISV AUTH KEY - 특정 타겟 애플리케이션 엔클레이브에 대한 인증 데이터를 생성하기 위해 구조적 쿼팅 엔클레이브에 의해 사용됨.ISV AUTH KEY-used by the Structured Quoting Enclave to generate authentication data for a specific target application enclave.

ㆍ AUTH KEY - 구조적 쿼팅 엔클레이브에 의해 그곳으로 보내진 데이터를 인증하기 위해 애플리케이션 엔클레이브에 의해 사용됨.AUTH KEY-used by the application enclave to authenticate data sent there by the structured quota enclave.

ㆍ SEAL KEY - 엔클레이브 외부에 저장하고 싶어하는 데이터를 암호화하기 위해 애플리케이션 엔클레이브에 의해 사용됨.SEAL KEY-used by the application enclave to encrypt data that it wishes to store outside of the enclave.

ㆍ OOB EXPERIENCE KEY - 아웃-오브-박스 경험 사용(예를 들면, 블루레이 플레이어)을 위해 프리-제공 암호화된 데이터를 위해 ISV에 의해 사용됨.OOB EXPERIENCE KEY-used by ISVs for pre-provided encrypted data for out-of-box experience use (eg Blu-ray player).

대부분의 이들 값은 로우(raw)로 프로세서에 상주하지 않지만, 사실, 단일 퓨즈 키 값으로부터 EGETKEY에 의한 요구로 유도된다. 그들은 이들 키 각각이 다닐 키가 아니지만 가능한 세트로부터의 단일 키에 있는 것으로 요구하여 유도된다. 전달되는 특정 키는 다수의 파라미터에 의존하고, 그 중 몇몇은 사용자가 선택가능하고, 다른 것들은 시스템 또는 특정 상태에 기초한다.Most of these values are raw in the processor, but in fact are derived from a single fuse key value by the request by the EGETKEY. They are derived by requiring that each of these keys is not a key to carry but is in a single key from a possible set. The particular key being delivered depends on a number of parameters, some of which are user selectable, others are based on a system or a specific state.

키를 선택하기 위해 KeyRequest 구조가 EGETKEY 명령어로의 입력으로서 사용된다. 키를 선택할 뿐만 아니라, 사용자는 호출자가 자신이 키의 생성에 사용되기를 바라는 자신의 제어 하에서 그들 변수를 특정하게 하는 KeyRequest 구조를 원한다. 아래의 도면은 KeyRequest 구조를 특정한다:To select the key, the KeyRequest structure is used as input to the EGETKEY command. In addition to selecting keys, the user wants a KeyRequest structure that allows the caller to specify those variables under his control that he wishes to be used to generate the keys. The figure below specifies the KeyRequest structure:

[표 12-6]Table 12-6

KeySelect는 사용자가 요구하는 키를 식별하는데 사용되고, KeyPolicy는 키 생성에 어떤 부가의 값이 사용되는지를 확립하는데 사용된다 - 구조적 엔클레이브의 특정 보안 버전 또는 애플리케이션 엔클레이브의 특정 버전, 또는 (EGETKEY가 ENCLAVE 내로부터 호출될 때) 현재 엔클레이브와 연관된 측정 레지스터의 여부.KeySelect is used to identify the key that the user requires, and KeyPolicy is used to establish what additional values are used to generate the key-a specific secure version of the structural enclave or a specific version of the application enclave, or (EGETKEY ENCLAVE Whether called from within) the measurement register associated with the current enclave.

부가의 randomness 또한 키 유도에 부가될 수 있고, 이것은 특히 키의 소모를 방지하는데 요구되고, PERMITING 및 QUOTING 구조적 엔클레이브에 의해 사용된다. 이것은 또한 SEALing 키를 생성할 때 애플리케이션 엔클레이브에 의해 사용될 수 있다. 필드를 제로로 설정하는 것은 어떠한 부가의 randomness도 부가되지 않을 것이라는 것을 나타내고, 그렇지 않으면, 필드는 256 정렬 데이터 값을 포인팅한다. 아래의 도면은 KeySelect 필드에 대한 구조를 특정한다.Additional randomness can also be added to the key derivation, which is particularly required to prevent the exhaustion of keys and is used by the PERMITING and QUOTING structural enclaves. This can also be used by the application enclave when generating the SEALing key. Setting the field to zero indicates that no additional randomness will be added, otherwise the field points to 256 aligned data values. The figure below specifies the structure for the KeySelect field.

[표 12-7]Table 12-7

KeyPolicy는 비트 필드 선택기이고, 사용자 또는 시스템 상태로부터의 어느 한 특정값이 키 유도에 사용될지를 결정하는데 사용된다.KeyPolicy is a bit field selector and is used to determine which specific value from the user or system state will be used for key derivation.

[표 12-8]Table 12-8

엔클레이브 레지스터 및 제어Enclave Registers and Controls

[표 14-1]Table 14-1

엔클레이브를 위해 두 개의 인에이블링 레벨이 제공된다. 제1 인에이블은 BIOS에 의해 설정된 옵트 인 비트(opt in bit)이다. 이것은 일회 기록 함수이다. 이것은 다음 리셋까지 엔클레이브 능력을 인에이블하거나 디스에이블한다. 제2 인에이블은 엔클레이브 능력을 필요에 따라 동적으로 턴온 또는 턴오프하기 위해 OS 또는 VMM에 제공된다.Two enabling levels are provided for the enclave. The first enable is an opt in bit set by the BIOS. This is a write once function. This enables or disables the enclave capability until the next reset. The second enable is provided to the OS or VMM to dynamically turn on or off the enclave capability as needed.

도 19는 본 발명의 일 실시예에서 발견될 수 있는 엔클레이브 CTL_MSR에 대한 도면이다. 최하위 비트는 Enable 1900이다. 레지스터의 비트 1은 On 1910이다. 비트 2 내지 63은 예비이다.19 is a diagram for an enclave CTL_MSR that may be found in one embodiment of the present invention. The least significant bit is Enable 1900. Bit 1 of the register is On 1910. Bits 2 through 63 are reserved.

엔클레이브 능력은 도 19에 도시된 EnclaveCTL_MSR에서의 Enable 비트를 우선 설정함으로써 인에이블된다. 이 비트는 패키지 리셋이 발생할 때 디스에이블하기 위한 디폴트이다. 이 비트는 패키지 리셋 후 일회 기록될 수 있다.Enclave capability is enabled by first setting the Enable bit in EnclaveCTL_MSR shown in FIG. This bit is the default to disable when a package reset occurs. This bit can be written once after a package reset.

BIOS는 엔클레이브를 인에이블하기 위한 비트를 설정한다. BIOS가 비트를 클리어하면, 엔클레이브는 그 부분이 리셋될 때까지 엔에이블될 수 없다.The BIOS sets a bit to enable the enclave. If the BIOS clears the bit, the enclave cannot be enabled until that part is reset.

소프트웨어는 CPUID 명령어를 실행함으로써 엔클레이브에 대한 지원을 검출할 수 있다. CPUID는 엔클레이브가 지원받고 있는지 또는 아닌지를 나타내는 결과를 리턴할 것이다.The software can detect support for the enclave by executing the CPUID instruction. The CPUID will return a result indicating whether the enclave is supported or not.

옵트 인 비트가 클리어되면, CPUID는 엔클레이브가 실행되지 않을 것이라는 것을 보고한다.If the opt in bit is cleared, the CPUID reports that the enclave will not be executed.

시스템 소프트웨어는 도 19에 도시된 EnclaveCTL_MSR을 이용하여 엔클레이브 능력을 제어한다. On 비트는 소프트웨어가 엔클레이브 능력으로의 액세스를 동적으로 제어할 수 있게 한다.The system software controls the enclave capability using EnclaveCTL_MSR shown in FIG. The On bit allows the software to dynamically control access to the enclave capabilities.

소프트웨어는 CPUID 명령어를 실행함으로써 엔클레이브에 대한 지원을 검출한다. 엔클레이브 지원은 EnclaveCTL MSR에서의 ON 비트가 설정되는지 표시된다.The software detects support for the enclave by executing the CPUID instruction. Enclave support is indicated if the ON bit in the EnclaveCTL MSR is set.

TCSMSR 레지스터는 TCS의 어드레스를 포함하는 각각의 프로세서 상의 레지스터이다. 이것은 익셉션 핸들링 및 RDTCSPTR에 의해 사용된다. 이것은 엔클레이브에 진입할 때 로딩된다. 레지스터는 EENTER가 실행될 때 TCS의 값으로 로딩된다. 이것은 ERDTCSPTR에 의해 판독된다. 레지스터 크기는 프로세서의 모드에 기초한다.The TCSMSR register is a register on each processor that contains the address of the TCS. This is used by exception handling and RDTCSPTR. This is loaded when entering the enclave. The register is loaded with the value of TCS when EENTER is executed. This is read by ERDTCSPTR. The register size is based on the mode of the processor.

각각의 프로세서 상의 엔클레이브 베이스 어드레스 레지스터는 실행중인 엔클레이브의 하위 어드레스를 포함한다. 이것은 마이크로코드에 의해 엔클레이브에 진입할 때 로딩된다. 레지스터 크기는 프로세서의 모드에 기초한다. 이 레지스터는 소프트웨어에게는 가시적이지 않다. 이것은 마이크로코드 템포레리(microcode temporary)이다.The enclave base address register on each processor contains the lower address of the running enclave. It is loaded when entering the enclave by microcode. The register size is based on the mode of the processor. This register is not visible to software. This is a microcode temporary.

레지스터는 현재 엔클레이브의 상위 어드레스 한계를 홀드한다. 이것은 엔클레이브에 진입할 때 로딩된다. 레지스터는 엔클레이브가 실행을 시작할 때 SECS에 저장된 값으로 로딩된다. 이것은 마이크로코드 템포레리 레지스터이다. 레지스터 크기는 프로세서의 모드에 기초한다.The register holds the upper address limit of the current enclave. This is loaded when entering the enclave. The register is loaded with the value stored in the SECS when the enclave starts executing. This is a microcode temporal register. The register size is based on the mode of the processor.

엔클레이브 페이지 캐시(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 4096 byte pages. This is a 32-bit register. This register is read only to indicate the maximum size EPC supported by the current design.

EPC 크기 레지스터 EPC_SIZE MSR은 EPC의 현재 정의된 크기를 나타낸다. 레지스터를 로딩하면 크기로 정의 EPC의 결과를 낳는다. 값은 4096 페이지로 주어진다. 예를 들면, 하나의 4096 비트 페이지는 1일 수 있다. 레지스터의 값은 EPC_MAX 값을 초과할 수 없다. 값이 EPC_MAX 값을 초과하면, WRMSR 명령어에 의해 GP 폴트가 취해진다. 이 레지스터로의 기록은 기록 전에 EPC 내의 모든 데이터를 무효로 할 것이다. 소프트웨어는 이 레지스터를 업데이트하기 전에 (필요하다면) 모든 EPC 엔트리를 저장할 수 있다.EPC Size Register EPC_SIZE The MSR indicates the currently defined size of the EPC. Loading a register results in a defined EPC by size. The value is given in 4096 pages. For example, one 4096 bit page may be one. The value of the register cannot exceed the value of EPC_MAX. If the value exceeds the EPC_MAX value, a GP fault is taken by the WRMSR instruction. Writing to this register will invalidate all data in the EPC before writing. The software can save all EPC entries (if needed) before updating this register.

EPC 베이스 레지스터는 EPC의 베이스의 위치를 나타낸다. 이 레지스터로의 기록은 기록 전에 EPC 내의 모든 데이터를 무효로 할 것이다. 소프트웨어는 이 레지스터를 업데이트하기 전에 (필요하다면) 모든 EPC 엔트리를 저장할 수 있다.The EPC base register indicates the position of the base of the EPC. Writing to this register will invalidate all data in the EPC before writing. The software can save all EPC entries (if needed) before updating this register.

일반적으로, 외부 인터페이스는 엔클레이브의 보안과 타협할 수 있는 어떠한 전이 또는 거래도 가능하지 않다. 보안 엔클레이브는 엔클레이브 키에 대한 난수를 요구한다. 랜덤 비트는 디지털 난수 생성기를 사용하여 생성된다. 난수 생성기는 마이크로코드에 의해 보안적으로 액세스가능할 수 있다. 이것은 부분 코어에 위치될 필요는 없다.In general, the external interface is not capable of any transfer or transaction that can compromise the security of the enclave. The secure enclave requires a random number for the enclave key. Random bits are generated using a digital random number generator. The random number generator may be securely accessible by microcode. It does not need to be located in the partial core.

도 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)는 또한, STD(2608), OPE(2610), PSK(2612) 및 TSC(2614)를 취하는 DRNG(2602)를 포함할 수 있다. DRNG(2602)는 온라인 셀프 테스트(2606)에 접속되는 디지털 엔트로피 소스(2604)를 포함할 수 있다. 온라인 셀프 테스트(2606)의 출력은 결합 콘디셔너/DRBG(deterministic random bit generator)(2620)의 하나의 입력일 수 있다.Figure 26 shows a processor package for a digital random number generator, for one embodiment of the present invention. The processor package 2600 may include a plurality of cores, that is, core 0 2640 and core 1 2670. Core 0 2640 may include an external instruction microcode 2602, an internal function microcode 2644, an internal function microcode 2646, an RNG microcode module 2650, and an RNG queue 2654. Core1 2670 may include an external instruction microcode 2672, an internal function microcode 2674, an internal function microcode 2676, an RNG microcode module 2680, and an RNG queue 2684. Read random instructions 2630 may communicate with external instruction microcode 2262, while read random instructions 2635 may communicate with external microcode 2672. Process package 2600 may also include DRNG 2602 taking STD 2608, OPE 2610, PSK 2612 and TSC 2614. DRNG 2602 may include a digital entropy source 2604 that is connected to online self test 2606. The output of the online self test 2606 may be one input of a combined conditioner / deterministic random bit generator (DRBG) 2620.

엔클레이브는 생성될 때 디버그 엔클레이브로서 설정될 수 있다. 디버그 엔클레이브는 EDBGRD 및 EDBGWR 명령어를 사용하여 엔클레이브 콘텐츠로의 외부 액세스를 가능하게 할 것이다. 디버그 엔클레이브는 ECREATE 명령어에 디버그 플래그를 설정함으로써 셋업된다. 이 비트는 엔클레이브의 SECS 내부에 저장된다. The enclave can be set as a debug enclave when created. The debug enclave will enable external access to enclave content using the EDBGRD and EDBGWR instructions. Debug enclaves are set up by setting debug flags on the ECREATE instruction. This bit is stored inside the SECS of the enclave.

디버그 비트 클리어로 생성되는 엔클레이브는 생산 엔클레이브이다. EPC는 그 엔클레이브가 디버그 엔클레이브라는 것을 나타내는 디버그 비트를 포함한다. 엔클레이브 콘텐츠를 검사하는 것을 필요로 하는 디버거는 메모리를 EPC로 로딩할 것이다. EDBGRD 및 EDBGWR 명령어를 사용하여 EPC에 상주하는 엔클레이브 메모리 위치를 액세스할 수 있다. 디버그 엔클레이브는 실행하기 위해 퍼밋을 요구하지 않는다. 이것은 유효 퍼밋없이 실행될 것이다.The enclave produced by the debug bit clear is a production enclave. The EPC contains a debug bit indicating that the enclave is a debug enclosure. A debugger that needs to check the enclave content will load the memory into the EPC. The EDBGRD and EDBGWR instructions can be used to access enclave memory locations residing in the EPC. Debug enclaves do not require a permit to run. This will run without valid permits.

생산 엔클레이브에 진입할 때, 디버그 제어 레지스터(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) 내의 다른 비트는 LE(2718), GE(2720), 001(2722), GD(2724), 00(2726), R/W0(2728), LEN0(2730), R/W1(2732), LEN1(2734), R/W2(2736), LEN2(2738), R/W3(2740) 및 LEN3(2742)를 포함한다.When entering the production enclave, debug control register DR7 is stored in the TCS storage area. DR7 is shown in FIG. 27. 27 shows debug register DR7 2700 for one embodiment of the present invention. Register DR7 2700 includes bits L0 2702, L1 2706, L2 2710, L3 2714, G0 2704, G1 2708, G2 2712 and G3 2716. The other bits in the DR7 register 2700 are LE 2718, GE 2720, 001 (2722), GD 2724, 00 (2726), R / W0 (2728), LEN0 (2730), R / W1 ( 2732), LEN1 2734, R / W2 2736, LEN2 2738, R / W3 2740 and LEN3 2742.

비트 L3-L0 및 G3-G0은 제로 값으로 설정된다. DR7은 엔클레이브 엑시트에서 자신의 원래 값으로 리턴된다.Bits L3-L0 and G3-G0 are set to zero values. DR7 returns to its original value at the enclave exit.

디버그 엔클레이브를 위해, 디버그 레지스터 값은 변경되지 않는다. RFLAGS.TF가 EENTER 명령의 시작 시에 설정될 때, 두가지 경우가 고려된다:For debug enclaves, the debug register value is not changed. When RFLAGS.TF is set at the start of the EENTER command, two cases are considered:

디버거는 레거시(비 SE-인식)이거나, 엔클레이브가 생산(비-디버그) 모드에 있다.The debugger is either legacy (non SE-aware) or the enclave is in production (non-debug) mode.

SE-인식 디버거는 디버그-모드 엔클레이브를 타겟팅한다.SE-aware debuggers target debug-mode enclaves.

제1의 경우, 다음 EEXIT 명령어의 타겟에 대하여 #DB 익셉션이 발생할 수 있다. 이것은 대규모의 오페크(opague) 연산으로서 엔클레이브를 처리한다. 제2의 경우, 사용자는 엔클레이브를 통해 단일 단계로 자유롭게 완성한다. 이 행동은 엔클레이브 내으 3 데이터 필드 및 EENTER 상의 REFLAGS.TF, EEXIT 및 EIRET의 특별한 프로세싱에 의해 지원된다.In the first case, #DB exception may occur for the target of the next EEXIT command. This handles the enclave as a massive opague operation. In the second case, the user freely completes in a single step via the enclave. This behavior is supported by the special processing of REFLAGS.TF, EEXIT and EIRET on 3 data fields and EENTER in the enclave.

[표 15-1]Table 15-1

[표 15-2]Table 15-2

레지스터 값은 TCS 저장 영역에 저장된다. 레지스터는 0으로 설정된다. 엔클레이브 엑시트에서, 레지스터는 엔트리에서의 값으로 다시 저장된다. 엔클레이브가 엔트리에서 인에이블된 브랜치 트레이스를 갖는다면, EENTER는 엔클레이브 진입전 최종 엔트리이다. 엔클레이브를 나갈 때, 엑시트 후의 제1 위치가 브랜치 트레이스에 기록된다.The register value is stored in the TCS storage area. The register is set to zero. At the enclave exit, the register is stored back to the value at the entry. If the enclave has branch traces enabled in the entry, EENTER is the last entry before enclave entry. When exiting the enclave, the first position after the exit is recorded in the branch trace.

Int n 및 Int 3 명령어는 엔클레이브 내부에서 실행된다면 GP 폴트로서 리포트된다. 디버거는 엔클레이브를 디버깅할 때 GP 폴트 조건을 후크(hook)할 수 있다. Int n and Int 3 instructions are reported as GP faults if executed inside the enclave. The debugger can hook GP fault conditions when debugging the enclave.

이 문서에서, 우리는 AES 블록 암호를 위한 연산의 CMAC 모드를 구현하는 새로운 기술을 설명한다. CMAC은 메시지 인증을 지원하는 모드이다. 입력으로서 메시지 A 및 키 K를 수용하고 인증 태그 T를 리턴한다. 인증 태그의 도출은 CBC(cipher block chaining) 알고리즘을 사용하여 행해진다. CMAC은, 그것이 길이 확장 공격에 대한 보호를 위한 메커니즘을 포함하기 때문에 CBC보다 더 복잡하다. 우리는 이들을 'CMAC의 세가지 특성'으로 칭한다. 다음에서, 우리는 CBC 및 CMAC의 개관을 제공한다.In this document, we describe a new technique for implementing the CMAC mode of operation for AES block ciphers. CMAC is a mode that supports message authentication. Accepts message A and key K as input and returns an authentication tag T. Derivation of the authentication tag is done using a cipher block chaining (CBC) algorithm. CMAC is more complicated than CBC because it includes mechanisms for protection against lengthening attacks. We refer to these as the 'three characteristics of CMAC'. In the following, we provide an overview of the CBC and CMAC.

도 20은 본 발명의 일 실시예에서 사용되는 암호 블록 체인화 알고리즘을 도시한다. 초기화 벡터(2000) 및 스테이지-1 입력(2010)이 배타적 or 게이트(2012)에 입력된다. 배타적 or 게이트(2012)의 출력은 스테이지-원 블록 암호(2015)로 입력된다. 다음에, 스테이지-1 블록 암호 출력(2018)은 스테이지-2 입력(2020)과 함께 스테이지-2 배타적 or 게이트(2022)로 입력된다. 배타적 or 게이트(2022)의 출력은 스테이지-2 블록 암호(2025)로 입력된다. 다음에, 스테이지-2 블록 암호 출력(2028)은 암호 블록 체인의 다음 스테이지(도시 생략)로 입력된다.20 illustrates a cryptographic block chaining algorithm used in one embodiment of the present invention. The initialization vector 2000 and the stage-1 input 2010 are input to the exclusive or gate 2012. The output of exclusive or gate 2012 is input to a stage-one block cipher 2015. Next, stage-1 block cryptographic output 2018 is input to stage-2 exclusive or gate 2022 along with stage-2 input 2020. The output of exclusive or gate 2022 is input to stage-2 block cipher 2025. Next, the stage-2 block cipher output 2028 is input to the next stage (not shown) of the cipher block chain.

CBC 알고리즘은 블록 암호를 이용하여 데이터의 몇몇 부분에 신뢰성을 제공하거나 또는 이 데이터에 대한 인증 태그를 계산한다. CBC 알고리즘 뒤의 주요 아이디어는 이전 암호로부터의 출력이 암호화되기 전에 다음 입력 블록과 XOR된다는 것이다. 이 방식에서, 입력 데이터에서 엑시트될 수 있는 패턴은 암호텍스트에서 제거된다. 또한, 블록 암호의 젼환들 간의 XOR 연산의 조합은 이상적으로 변조가 불가능한 메시지 인증 태그를 도출하는 강력한 혼합(mixing)을 제공한다.The CBC algorithm uses block ciphers to provide trust for some pieces of data or to compute authentication tags for this data. The main idea behind the CBC algorithm is that the output from the previous cipher is XORed with the next input block before it is encrypted. In this way, patterns that can be exited from input data are removed from the ciphertext. In addition, the combination of XOR operations between the exchanges of block ciphers provides a powerful mixing that leads to an ideally unmodifiable message authentication tag.

CBC 알고리즘이 이하에 주어지고 도 20에 도시된다. 암호는 AEA의 경우에 128-비트 블록 암호로 가정된다.The CBC algorithm is given below and shown in FIG. 20. The cipher is assumed to be a 128-bit block cipher in the case of AEA.

CMAC 상세는 CBC 알고리즘을 초기화하고 종결하는 세 개의 부가 알고리즘을 포함한다. 우리는 이들은 CMAC의 "세 가지 특성"으로서 칭한다. 제1 특성은 대칭 키 K로부터 두 개의 서브키 값 K ₁ 및 K ₂ 의 유도에 관한 것이다. 서브키 K ₁ 및 K ₂ 는 중간값 L로부터 유도된다. CMAC은 L이 대칭키 값 k을 이용하여 제로들(즉, 0¹²⁸)로 구성되는 스트링 상에 대칭키 블록 암호 변환을 적용함으로서 유도된다는 것을 설명한다. 그러한 관계가 수학식 1에 도시되어 있다.The CMAC details include three additional algorithms to initialize and terminate the CBC algorithm. We refer to these as the "three characteristics" of the CMAC. The first characteristic relates to the derivation of _two subkey values K ₁ and K ₂ from the symmetric key K. Subkeys K ₁ and K ₂ are derived from the median L. CMAC explains that L is derived by applying a symmetric key block cryptographic transformation on a string consisting of zeros (ie 0 ¹²⁸ ) using a symmetric key value k . Such a relationship is shown in equation (1).

[수학식 1][Equation 1]

L이 도출되면, L의 최상위 비트가 검사된다. 이것이 제로이면, K1은 하나의 비트 위치만큼 왼쪽으로 시프팅함으로써 L로부터 유도된다. 그렇지 않으면, L은 하나의 비트 위치만큼 왼쪽으로 시프트되고 또한 특정 값 R _b 와 XOR되어 K ₁ 을 생성한다. R _b 는 이진 형태의 <0¹²⁰10000111>으로서 정의된다. K ₂ 는 동일한 절차 후에 K ₁ 으로부터 생성된다. If L is derived, the most significant bit of L is checked. If this is zero, K1 is derived from L by shifting left by one bit position. Otherwise, L is shifted left by one bit position and also XORed with a specific value R _b to produce K ₁ . R _b is defined as <0 ¹²⁰ 10000111> in binary form. K ₂ is generated from K ₁ after the same procedure.

서브키 K ₁ 및 K ₂ 의 유도는 아래의 의사-코드(pseudo-code)로 주어진다. MSB()으로 우리는 최상위 비트값을 의미한다.The derivation of subkeys K ₁ and K ₂ is given by the pseudo-code below. With MSB () we mean the most significant bit value.

CMAC의 제2 특성은 CBC 알고리즘을 입력 데이터에 적용하기 전에 발생하는 패딩(padding)에 관한 것이다. 데이터의 최종 블록이 완전한 블록이 아니라면, 블록은 "1"과 동일한 한 비트와 필요에 따라 많은 제로가 이어지도록 패딩되어, 최종 블록이 완성된다.A second characteristic of the CMAC relates to padding that occurs before applying the CBC algorithm to the input data. If the last block of data is not a complete block, the block is padded with one bit equal to " 1 " followed by as many zeros as needed to complete the final block.

CMC의 제3 특성은 길이 확장 공격을 피하기 위해 발생하는 최종 블록에 대한 수정에 관한 것이다. 최종 블록이 완전한 것(패딩이 필요하지 않음)이라면, 최종 블록은 서브키 K ₁ 과 XOR된다. 그렇지 않으면, 이것은 서브키 K ₂ 와 XOR된다.The third characteristic of the CMC relates to modifications to the final block that occur to avoid lengthening attacks. If the last block is complete (no padding required), the last block is XORed with subkey K ₁ . Otherwise, it is XORed with the subkey K ₂ .

CMAC 태그 생성 및 유효화에 대한 알고리즘이 아래에 리스트되어 있다.The algorithms for creating and validating CMAC tags are listed below.

다음에서, 우리는 사용되는 대칭 키 블록 암호가 AES옥 프로세서가 AES 라운드 가속을 위한 명령어의 세트를 지원할 때 CBC() 알고리즘을 어떻게 구현할 수 있는지를 보여준다. 인텔 아키텍처는 웨스트미어 프로세서(2009)의 시간 프레임에서 4개의 새로운 그러한 명령어를 지원한다. 이들 명령어는 AESENC(AES round encryption), AESENCLAST(AES last round encryption), AESDEC(AES round decryption) 및 AESDECLAST(AES last round decryption)이다. 이들 명령어에 대한 상세는 다음과 같다.In the following, we show how the symmetric key block cipher used can implement the CBC () algorithm when the AES Jade processor supports a set of instructions for AES round acceleration. The Intel architecture supports four new such instructions in the time frame of the Westmere processor (2009). These instructions are AES round encryption (AESENC), AES last round encryption (AESENCLAST), AES round decryption (AESDEC) and AES last round decryption (AESDECLAST). Details about these commands follow.

[표 16-1]Table 16-1

AES 라운드 명령어를 사용하여 CMAC 모드를 구현하기 위해, 단지 태그 유효화 프로세스가 태그 생성과 동일하기 때문에, AESENC AESENCLAST를 호출하기에 충분하다. 도 21은 하나의 AES 블록의 암호화와 연관된 플로우 차트를 도시한다. 도 22는 CBC 알고리즘을 이용하여 다수의 AES 블록을 암호화하는 것과 연관된 플로우 차트를 도시한다.In order to implement CMAC mode using the AES round instruction, it is enough to call AESENC AESENCLAST because the tag validation process is the same as tag generation. 21 shows a flow chart associated with encryption of one AES block. 22 shows a flow chart associated with encrypting multiple AES blocks using the CBC algorithm.

키 스케줄 변환을 구현하기 위해, 역 믹스 컬럼을 위한 AESIMC를 사용할 수 있고, 암호화를 위해 사용된 라운드 키를 생성하기 위해 AESKEYGENASSIST 명령어 AESKEYGENASSIST가 사용된다. AESIMC는 암호화 라운드 키를 등가의 역 암호화 모델에 따라 암호해독을 위해 사용가능한 형태로 변환하기 위해 사용된다. AESIMC 및AESKEYGENASSIST 명령어의 설명은, http://softwarecommunity.intel.com/articles/eng;3788.htm에 주어져 있다.To implement key schedule conversion, you can use AESIMC for the inverse mix column, and the AESKEYGENASSIST command AESKEYGENASSIST is used to generate the round key used for encryption. AESIMC is used to convert an encryption round key into a form usable for decryption according to an equivalent inverse encryption model. A description of the AESIMC and AESKEYGENASSIST commands is given at http://softwarecommunity.intel.com/articles/eng;3788.htm.

CMAC은 수반되는 128비트 양에 대한 빅 엔디안 정의(big endian notation)를 사용하여 특정된다. 작은 엔디안 머신에서 CMACmf 올바르게 구현하기 위해, 소스 코드 구현예의 임의의 포인트에서 16 바이트-와이드 바이트 반영 동작을 수행하는 것이 필요하다. 그러한 동작은 PSHUFB 명령어(1 클록 레이턴시, 쓰루풋)을 사용하여 빠르게 수행될 수 있다. 다음에, 우리는 바이트 셔플링(shuffling)이 요구되는 포인트를 설명한다.CMAC is specified using a big endian notation of the amount of 128 bits involved. In order to correctly implement CMACmf in a small endian machine, it is necessary to perform a 16 byte-wide byte reflection operation at any point in the source code implementation. Such operation can be performed quickly using the PSHUFB instruction (one clock latency, throughput). Next, we describe the points at which byte shuffling is required.

SUBKEYS() 알고리즘 구현예에서, 바이트 반영은 AES를 제로 스트링에 적용함으로써 유도된 후 그리고 두 개의 서브키의 유도 전에 L에 요구된다. 그들이 L로부터 유도된 후 두 개의 서브키에 대해 바이트 반영이 또한 요구된다. SUBKEYS() 구현이 아래에 C로 주어진다.In the SUBKEYS () algorithm implementation, byte reflection is required for L after derivation by applying AES to the zero string and before derivation of the two subkeys. Byte reflection is also required for the two subkeys after they are derived from L. The SUBKEYS () implementation is given below in C.

다음에, 이 마지막 블록이 완전하지 않다면 패딩 전 및 후에 마지막 블록에 대해 바이트 반영이 요구된다. 이들 단계가 아래에 C로 도시되어 있다.Next, byte reflection is required for the last block before and after padding if this last block is not complete. These steps are shown below as C.

여기서, 함수 _pshufb()는 128-비트 와이드 바이트 반영을 수행한다.Here, the function _pshufb () performs 128-bit wide byte reflection.

SMI에 대한 SE 요구사항SE Requirements for SMI

엔클레이브는 SMM 공간 내부에서 실행하는 것이 허가되지 않는다. SMM 모드에서 엔클레이브를 실행하고자 하는 시도는 명령어의 GP 폴트를 낳게 된다. 엔클레이브 내부에서 실행동안 SMI가 발생하면, 프로세서는 엔클레이브 내부에 레지스터 상태를 저장하고 엑시트할 수 있다. 엑시트가 발생하면, TBD MSR 비트는 엔클레이브가 실행된 동안 SMI가 발생하였다는 것을 나타내도록 설정된다. SMM 코드는 엔클레이브를 액세스할 수 없다. EPC 영역을 터치하기 위한 시도는 실제 모드에서는 정크 데이터의 리턴이되고 보호 모드에서는 EPC 페이지 폴트가 될 것이다.Enclaves are not allowed to run inside the SMM space. Attempts to execute an enclave in SMM mode result in a GP fault of the instruction. If an SMI occurs during execution inside the enclave, the processor can save and exit the register state inside the enclave. If an exit occurs, the TBD MSR bit is set to indicate that SMI occurred while the enclave was running. The SMM code cannot access the enclave. An attempt to touch the EPC area will result in the return of junk data in real mode and an EPC page fault in protected mode.

임의의 명령어가 실행되는 것은 허가되지 않는다. 어떤 명령어가 합법적인지를 결정하는데 사용되는 다수의 일반적인 규칙이 있다.Any command is not allowed to be executed. There are a number of general rules used to determine which instructions are legal.

1. 링 레벨 변화는 엔클레이브 내부에서는 허가되지 않는다. 링 레벨을 변경 또는 변경시킬 수 있는 명령어는 금지된다.1. Ring level changes are not allowed inside the enclave. Commands that can change or change the ring level are prohibited.

2. 외부의 소프트웨어는 에클레이브 내부의 VMEXITS를 서비스할 수 없다. 엔클레이브 내부에서 VMEXIT를 생성하거나 생성할 수 있는 모든 명령어는 금지된다.2. External software cannot service VMEXITS inside the enclave. Any instruction that can or can generate VMEXIT inside an enclave is prohibited.

3. 소프트웨어는 엔클레이브 내부에서 가상 머신을 생성할 수 없다. 모든 VMX 명령어는 금지된다.3. The software cannot create a virtual machine inside the enclave. All VMX instructions are prohibited.

4. I/O 참조를 수행하는 명령어는 엔클레이브 내부에서 금지된다.4. Instructions to perform I / O references are prohibited inside the enclave.

엔클레이브의 제1 세대에서, 프로세서는 엔클레이브로 진입할 때 IOPL을 0으로 설정하면서 링 3에서 실행될 수 있다.In the first generation of enclaves, the processor may run in ring 3 with IOPL set to zero when entering the enclave.

엔클레이브가 가상 또는 비가상의 환경에서 실행될 때 프로그래밍 환경을 보존하기 위해, 표 18-1에 리스트된 명령어는 불법이다.In order to preserve the programming environment when the enclave runs in a virtual or non-virtual environment, the instructions listed in Table 18-1 are illegal.

[표 18-1]Table 18-1

제한은 엔클레이브 내부의 상태에 부과된다. 엔클레이브에 진입할 때, GDTR.limit, LDTR.limit, IA32_EFER.SCE, 및 IA32_SYSENTER_CS가 TCS 영역에 저장된다. 로컬 값은 클리어된다. 이들 레지스터로 액세스하거나 그로의 액세스를 유발하는 명령어는 엔클레이브 내부에서 실패할 것이다. GDTR.limit, LDTR.limit, IA32_EFER.SCE, 및 IA32_SYSENTER_CS는 엔클레이브를 떠날 때 다시 저장된다.Restrictions are imposed on the state inside the enclave. When entering the enclave, GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS are stored in the TCS area. The local value is cleared. Instructions that access or cause access to these registers will fail inside the enclave. GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS are stored again when leaving the enclave.

[표 18-2]Table 18-2

엔클레이브의 수명은 개별적인 단계(phase)로 분할된다. 제1 단계는 엔클레이브 생성이다. 제2 단계는 엔클레이브 사용이다. 최종 단계는 엔클레이브 파괴이다.The life of the enclave is divided into individual phases. The first step is enclave generation. The second step is the use of enclave. The final step is enclave destruction.

엔클레이브의 생성 및 사용은 OS/VMM의 지원을 요구한다. 엔클레이브가 보안을 위해 OS/vmm에 의존하지 않지만, 임의의 하드웨어 데이터 구조를 적절히 유지하기 위해 OS/VMM을 요구할 것이다. 이들 구조를 유지하기 위한 OS/VMM의 실패는 보안의 손실로 이어지는 것이 아니라 엔클레이브의 총 실패를 야기할 수 있다.Creation and use of enclaves require the support of OS / VMM. Enclaves do not depend on OS / vmm for security, but will require OS / VMM to properly maintain any hardware data structure. Failure of the OS / VMM to maintain these structures may lead to a total failure of the enclave rather than leading to a loss of security.

몇몇 명령어는 엔클레이브의 검증, 비밀 데이터의 실링(sealing) 및 언실링(unsealing), 및 인증된 엔클레이브의 퍼밋을 지원한다.Some instructions support verification of enclaves, sealing and unsealing of secret data, and permitting of authorized enclaves.

제1 단계에서, 엔클레이브는 보안적으로 구성될 수 있고, 내부 소프트웨어 환경은 애플리케이션에 의한 사용을 위해 설정된다. 엔클레이브를 생성하기 위해 세 개의 명령어가 사용된다. 제1 명령인 ECREATE는 초기 상태 환경을 설정한다. 이 명령어는 엔클리이브 키, 로드, 암호화를 생성하고 무결성은 엔클레이브 데이터 구조를 저장하는데 사용되는 두 개의 페이지를 검사한다. 제2 명령어인 EADDPRE는 데이터의 페이지를 엔클레이브에게 부가한다. 이것은 엔클레이브 내부에 코드, 스택, 및 힙(heap)을 위해 필요한 페이지를 부가한다. 제3 명령어인 EINIT는 내부 소프트웨어 환경을 알려진 상태로 설정한다. 이 명령어의 완료시에, 엔클레이브는 제2 단계, 사용으로 이동하였다.In a first step, the enclave can be securely configured and the internal software environment is set up for use by the application. Three instructions are used to create the enclave. The first command, ECREATE, sets the initial state environment. This command generates the enclave key, load, and encryption, and integrity checks the two pages used to store the enclave data structure. The second instruction, EADDPRE, adds a page of data to the enclave. This adds the necessary pages for the code, stack, and heap inside the enclave. The third command, EINIT, sets the internal software environment to a known state. Upon completion of this instruction, the enclave has moved to the second stage, use.

EINIT를 수행하기 전에, 구성 소프트웨어는 EMKPERMIT를 수행하거나 퍼밋 엔클레이브를 사용함으로써 퍼밋을 획득하였을 수 있다.Prior to performing EINIT, the configuration software may have acquired a permit by performing EMKPERMIT or using a permit enclave.

엔클레이브는 EENTER 명령어를 통해 진입된다. 이 명령어는 머신을 엔클레이브 모드로 전이한다. 이것은 미리 정의된 엔트리 포인로 제어를 전이한다. EEXIT 명령어는 엔클레이브로부터 외부의 애플리케이션으로 리턴한다. EIRRET 명령어는 인터럽트 엑시트로부터 엔클레이브로 리턴한다.The enclave is entered via the EENTER instruction. This instruction transitions the machine into enclave mode. This transfers control to the predefined entry point. The EEXIT instruction returns from an enclave to an external application. The EIRRET instruction returns to the enclave from the interrupt exit.

EENTER 또는 EIRET를 통해 엔클레이브에 진입할 때, 명령어에 의해 다음의 연산이 수행된다. GDTR.limit, LDTR.limit, IA32_EFER.SCE, 및 IA32_SYSENTER_CS를 저장하고 클리어한다. 엑시트시에 GDTR, LDTR, IA32_EFER, 및 IA32_SYSENTER_CS를 다시 저장한다.When entering the enclave via EENTER or EIRET, the following operations are performed by the instruction. Save and clear GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS. Save GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS on exit.

엔클레이브를 파괴하는 명령어는 없다.There is no instruction to destroy an enclave.

EDBG_READ 명령어는 디버그 엔클레이브 내부의 위치의 8 바이트 판독을 행한다. 엔클레이브를 비 디버그(non debug)하도록 허가되는 액세스는 없다. EDBG_WRITE 명령어는 디버그 엔클레이브 내부의 위치에 8 바이트 기록을 행한다. 엔클레이브를 비 디버그하도록 허가되는 액세스는 없다.The EDBG_READ instruction performs an 8 byte read of the location inside the debug enclave. No access is allowed to non debug enclaves. The EDBG_WRITE instruction writes 8 bytes to a location inside the debug enclave. There is no access allowed to undebug the enclave.

엔클레이브 페이지 캐시(EPC)는 2개의 명령어를 통해 관리된다. 두 개의 명령어는 EPC 페이지(ELPG 및 EWBINVPG)를 로딩/저장한다.The enclave page cache (EPC) is managed through two instructions. Two instructions load / store the EPC pages (ELPG and EWBINVPG).

EREPORT는 엔클레이브 측정을 홀드하는 암호그래픽적으로 보호되는 구조를 생성한다. EGETKEY는 가변하는 유형의 엔클레이브 특정 키를 검색하는 수단을 제공한다. EMKPERMIT는 인증된 엔클레이브에 대한 퍼밋을 생성하는데 사용된다.EREPORT creates a cryptographically protected structure that holds enclave measurements. EGETKEY provides a means to retrieve enclave specific keys of varying types. EMKPERMIT is used to generate a permit for an authorized enclave.

[표 19-1]Table 19-1

주석: 외부²: 내부용으로 사용되는 모델은 없지만, EMKPERMIT가 내부로부터 실행하게 해도 해로운 것은 알려진 것이 없다.Note: External ² : There is no model used for internal use, but there is nothing known about harming EMKPERMIT from inside.

1-3³: 미래의 버전은 링0으로부터 엔클레이브로의 엔트리를 인에이블할 수 있다.1-3 ³ : Future versions may enable entries from ring 0 to enclave.

인터럽트 시에, 프로세서 상태는 엔클레이브 내부에 저장(및 숨김)될 수 있고 다음에 상태는 클리어된다. 더욱이, 인터럽트의 리턴 어드레스조차 숨겨질 수 있다.Upon interruption, the processor state can be stored (and hidden) inside the enclave and the state is then cleared. Moreover, even the return address of the interrupt can be hidden.

엔클레이브가 실행중인 동안 발생하는 인터럽트는 OS 코드를 변경할 필요를 피하기 위해 운영 시스템이 예상하는 형태로 인터럽트 스택 상에 정보를 푸시할 수 있다. 이를 달성하기 위해, 트램폴린 코드에 대한 포인터가 RIP 같은 인터럽트 스택 상에 푸시된다. 이 트램폴린 코드는 특정 파라미터(q.v.)를 갖는 EENTER 명령어에 의해 엔클레이브로 마침내 리턴된다.Interrupts that occur while the enclave is running can push information onto the interrupt stack in the form expected by the operating system to avoid the need to change the OS code. To accomplish this, a pointer to the trampoline code is pushed onto an interrupt stack, such as a RIP. This trampoline code is finally returned to the enclave by the EENTER instruction with a specific parameter (q.v.).

사용될 인터럽트 스택은 비-SE 모드에 대한 것과 동일한 규칙을 사용하여 선택된다:The interrupt stack to be used is selected using the same rules as for non-SE mode:

ㆍ 특권 레벨 변경이 있다면, 인터럽트 스택은 새로운 링과 연관된 것이 될 것이다.If there is a privilege level change, the interrupt stack will be associated with the new ring.

ㆍ 특권 레벨 변경이 없다면, 현재의 비신뢰성 스택이 사용된다.If there is no privilege level change, the current untrusted stack is used.

ㆍ IA-32e IST 메커니즘이 사용된다면, 인터럽트 스택은 그 방법을 사용하여 선택된다.If the IA-32e IST mechanism is used, the interrupt stack is selected using that method.

도 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)는 uRTS(2344)의 퍼-스레드(per-thread) 트램폴린을 내보낸다.FIG. 23 illustrates an application and interrupt stack after an interrupt with a stack switch in one embodiment. Current storage state region frame 2300 includes an RSP register 2305. Thread control structure 2310 may include a count of state storage area 2312 and interrupt return routine 2314. The interrupt stack 2330 includes an SS register 2332, an RSP register 2334, a flag register 2336, a CS register 2338, an instruction register 2340, and an error code 2234. The interrupt stack 2330 may send data in its RSP register 2334 to the count of the application stack 2320 and the storage state area 2300. Error code 2342 comes from the RSP after push 2346. Interrupt routing routine 2314 and instruction register 2340 emit the per-thread trampoline of uRTS 2344.

모든 경우에, 인터럽트 스택 및 그 위로 푸시되는 정보의 선택은 비-SE 연산과 일치한다. 도 23은 스택 스위치와의 인터럽트 후의 애플리케이션 및 인터럽트스택을 도시한다. 스택 스위치없는 인터럽트는 애플리케이션 스택을 사용한다. 부가하여, TCS 포인터는 인터럽트 후 엔클레이브를 재개할 때 EENTER 명령어에 의해 나중에 사용하기 위해 RBX에 위치된다.In all cases, the choice of interrupt stack and the information pushed on it is consistent with non-SE operations. Figure 23 illustrates an application and interrupt stack after an interrupt with a stack switch. Interrupts without a stack switch use the application stack. In addition, the TCS pointer is located in RBX for later use by the EENTER instruction when resuming the enclave after interruption.

TCS::IRR(Interrupt Retrun Routine)은 특정 스레드로 나중에 리턴될 퍼-스레드 코드를 포인팅한다. 이 포인터는 리턴 RIP와 같이 인터럽트 스택 상에 푸시된다. 이것은 IRET가, 인터럽트 리턴 코드(이 코드는 특화된 EENTER 명령어를 포함함)가 실행되는 애플리케이션으로 리턴되게 하는 데이터 구조의 세트의 결과를 가져온다. EENTER는 인터럽트 시에 초기화(및 OS에 의해 보존)되는 RBX 레지스터를 취하고, 그것을 TCS로서 사용하여 엔클레이브를 다시 진입시킨다(reenter).Interrupt Retrun Routine (TCS :: IRR) points to per-thread code that will later be returned to a particular thread. This pointer is pushed onto the interrupt stack with a return RIP. This results in a set of data structures that cause the IRET to be returned to the application where the interrupt return code (which contains a specialized EENTER instruction) is executed. EENTER takes an RBX register that is initialized (and saved by the OS) at the time of interrupt, and uses it as a TCS to reenter the enclave.

RFLAGS 내의 다음의 비트는 레지스터가 인터럽트 스택 상으로 푸시된 후 클리어된다:The following bits in RFLAGS are cleared after the register is pushed onto the interrupt stack:

CF Carry Flag SF Sign FlagCF Carry Flag SF Sign Flag

PF Parity Flag OF Overflow FlagPF Parity Flag OF Overflow Flag

AF Adjust Flag DF Direction FlagAF Adjust Flag DF Direction Flag

ZF Zero Flag ZF Zero Flag

도 24는 본 발명의 일 실시예에서 다수의 상태 저장 영역 슬롯의 스택을 구현하기 위한 가능한 방법을 도시한다. 스레드 제어 구조(2400)는 다음 상태 저장 영역 슬롯(2402), 현재 상태 저장 영역 슬롯(2404), 및 상태 저장 영역 슬롯(2406)을 포함할 수 있다. 상태 저장 영역 0(2410), 상태 저장 영역 1(2412), 및 상태 저장 영역 N(2418)은 상태 저장 영역 내에 세 개의 개별적을 선택된 위치이다. 다음 상태 저장 영역 슬롯(2402)은 상태 저장 영역(상태 저장 영역 0(2410))에서 사용하기 위한 위치를 특정한다. 현재 상태 저장 영역 슬롯(2404)는 상태 저장 영역(상태 저장 영역 1(2412))에서 사용하기 위한 위치를 특정한다. 상태 저장 영역 슬롯(2406)은 상태 저장 영역(상태 저장 영역 N(2418))에서 사용하기 위한 위치를 특정한다.24 illustrates a possible method for implementing a stack of multiple state storage area slots in one embodiment of the invention. The thread control structure 2400 may include a next state storage area slot 2402, a current state storage area slot 2404, and a state storage area slot 2406. State storage area 0 2410, state storage area 1 2412, and state storage area N 2418 are three individually selected positions within the state storage area. The next state storage area slot 2402 specifies a location for use in the state storage area (state storage area 0 2410). Current state storage area slot 2404 specifies a location for use in state storage area (state storage area 1 2412). State storage area slot 2406 specifies a location for use in the state storage area (state storage area N 2418).

상태 저장 영역은 인터럽트 시에 엔클레이브 상태를 홀드한다. 인터럽트가 사용자 모드로 전달된 다음 엔클레이브로 재진입할 수 있기 때문에, SSA는 도 19-3에 도시된 바와 같이 다수의 SSA의 스택이다. 사용될 상태 저장 영역의 위치는 TCS에서 세 개의 변수에 의해 제어된다: Number of State Save AreaSlots ( NSSA )(상태 저장 영역 스택 내의 슬롯의 총 수를 정의함), Current State Save AreaSlot(CSSA)(다음 인터럽트에서 사용하기 위한 현재 슬롯을 정의함), State Save Area ( SSA )(인터럽트 시에 프로세서 상태를 저장하는데 사용되는 저장 영역 슬롯의 세트). The state storage area holds the enclave state upon interruption. The SSA is a stack of multiple SSAs, as shown in Figures 19-3, because the interrupt can be delivered in user mode and then reenter into the enclave. The location of the state storage area to be used is controlled by three variables in the TCS: Number of State Save AreaSlots ( NSSA ) (which defines the total number of slots in the state storage area stack), Current State Save AreaSlot (CSSA) (which defines the current slot for use at the next interrupt), State Save Area ( SSA ) (set of storage area slots used to save processor state at interrupt time).

엔클레이브 내부의 스레드 상에서 실행되는 동안 인터럽트가 발생할 때, 마이크로코드는 사용하기 위한 저장 영역을 TCS::SSA 및 TCS::CSSA를 검사함으로써 결정한다. 프로세서 상태가 저장되고 클리어(비밀 누설을 피하기 위해)되고 TCS::CSSA가 증분된다. 이후에 설명되는 바와 같이, 익셉션이 최종 슬롯을 취하면, 익셉션을 엔클레이브로 전달하는 것이 가능하지 않을 것이다.When an interrupt occurs while running on a thread inside an enclave, the microcode determines the storage area to use by examining TCS :: SSA and TCS :: CSSA. The processor state is saved and cleared (to avoid secret leaks) and TCS :: CSSA is incremented. As will be explained later, if the exception takes the final slot, it will not be possible to deliver the exception to the enclave.

주석: EENTER 시에, CSSA는 (EENTER가 인터럽트로부터 리턴하는데 사용되지 않는다면) 인터럽트를 위해 이용가능한 적어도 하나의 저장 영역이 있다는 것을 보장하는 <NSSA일 수 있다.Note: At EENTER, CSSA may be <NSSA to ensure that there is at least one storage area available for interrupts (unless EENTER is used to return from interrupts).

도 25는 본 발명의 일 실시예에서 인터럽트, 폴트 및 트랩을 위한 상태 전이를 갖는 상태 머신의 일부를 도시한다. 가능한 상태는 비활성(2500), 활성(2510), 익셉트됨(2520), 핸들링됨(EENTER 불법)(2530), 및 핸들링(2540)이다. EENTER가 TCS:ENTRY(2502)로 디스패치하면, 비활성(2500)이 활성(2510)으로 전이한다. EEXIT(2504)가 발생하면, 활성(2510)은 비활성(2500)으로 전이한다. 인터럽트, 폴트, 또는 트랩(1512)이 발생하면, 활성(1510)은 익셉트됨(2520)으로 전이한다. EIRET(2514)가 발생하면, 예상됨(2520)이 활성(2510)으로 전이한다. EENTER가 TCS:HANDLER(2524)로 디스패치하면, 익셉트됨(2520)은 핸들링(2540)으로 전이한다. EIRET(2522)가 발생하면(2522), 익셉트됨(2520)은 핸들링(2540)으로 전이한다. 인터럽트, 폴트, 또는 트랩(2526)이 발생하면, 핸들링(2540)은 익셉트됨(2520)으로 전이한다. EEXIT(2532)이 발생하면, 핸들링(2540)은 핸들링됨(2530)으로 전이한다. 핸들링이 엔클레이브 익셉션 핸들러 내에서 인터럽트하고 EIRET(2534)가 발생하면, 핸들링됨(2530)은 핸들링(2540)으로 전이한다. 핸들링이 엔클레이브 익셉션 핸들러로부터 인터럽트하는 것이 아니고 EIRET(2534)가 발생하면, 핸들링됨(2530)은 활성(2510)으로 전이한다. 점선 전이(2522, 2526, 2534)는 핸들링이 엔클레이브 익셉션 핸들러 내에서 인터럽트할 때만 발생한다.25 illustrates a portion of a state machine with state transitions for interrupts, faults, and traps in one embodiment of the invention. Possible states are inactive 2500, active 2510, advanced 2520, handled (EENTER illegal) 2530, and handling 2540. If EENTER dispatches to TCS: ENTRY 2502, inactive 2500 transitions to active 2510. When EEXIT 2504 occurs, active 2510 transitions to inactive 2500. When an interrupt, fault, or trap 1512 occurs, the activity 1510 transitions to an accepted 2520. When EIRET 2514 occurs, expected 2520 transitions to activity 2510. When EENTER dispatches to TCS: HANDLER 2524, an unconceived 2520 transitions to handling 2540. When EIRET 2522 occurs (2522), an unconceived (2520) transitions to handling (2540). If an interrupt, fault, or trap 2526 occurs, the handling 2540 transitions to an accepted 2520. If EEXIT 2532 occurs, handling 2540 transitions to handled 2530. If handling is interrupted within the enclave exception handler and EIRET 2534 occurs, handled 2530 transitions to handling 2540. If handling is not interrupting from the enclave exception handler and EIRET 2534 occurs, handled 2530 transitions to active 2510. Dotted line transitions 2522, 2526, and 2534 only occur when handling interrupts within the enclave exception handler.

도 25는 인터럽트를 다루는 엔클레이브 상태 머신의 일부를 도시한다. 인터럽트는 선택적 스택 스위치 및 인터럽트 스택 상으로의 합성(synthetic) 인터럽트 프레임의 푸시로 시작한다. 이벤트가 인터럽트였다면, 엔클레이브는 인터럽트됨 상태에 진입한다. 이벤트가 익셉션이었다면, 엔클레이브는 익셉션됨 상태로 진입한다. 이들 두 개의 상태는 엔클레이브 익셉션을 에클레이브로 전달하는 것을 보장하고 또한 애플리케이션 코드를 공격함으로써 스퓨리어스 익셉션의 전달을 방지하는 것을 보장하기 위해 구별된다.25 shows a portion of an enclave state machine that handles interrupts. Interrupts begin with the push of a synthetic interrupt frame onto the optional stack switch and interrupt stack. If the event was an interrupt, the enclave enters the interrupted state. If the event was an exception, the enclave enters the exceptional state. These two states are distinguished to ensure delivery of enclave exceptions to the enclave and to prevent delivery of spurious exceptions by attacking application code.

인터럽트됨 상태로의 임의의 전이에서, 비신뢰 코드(애플리케이션, OS 또는 양자 모두)는 단지 EENTER/RETURN_FROM_INTERRUPT를 사용하여 엔클레이브를 재개할 수 있다. In any transition to the interrupted state, untrusted code (application, OS or both) can only resume the enclave using EENTER / RETURN_FROM_INTERRUPT.

익셉트됨 상태로의 임의의 전이에서, 비신뢰 코드(애플리케이션, OS 또는 양자 모두)는 다음과 같이 결정된다. In any transition to the accepted state, the untrusted code (application, OS or both) is determined as follows.

ㆍ EIRET를 사용함으로써 엔클레이브를 재개하여 인터럽트된 IP로 리턴한다. 이것은, 예를 들면, 페이지 폴트가 핸들링되는 방식이다. 인터럽트가 폴트에 의한 것이고, 폴트 조건을 정정하기 위해 아무것도 행해지지 않으면, 폴팅(faulting) 명령어가 다시 실행될 것이고 다시 폴팅할 것이다. 그러나, 트랩 후의 EIRET는 트랩핑 명령어 다음 명령어로 리턴할 것이다.Use EIRET to resume the enclave and return to the interrupted IP. This is, for example, the way page faults are handled. If the interrupt is due to a fault and nothing is done to correct the fault condition, the faulting instruction will be executed again and will fault again. However, the EIRET after the trap will return to the instruction following the trapping instruction.

ㆍ 엔클레이브 익셉센 핸들러를 호출한다.Call the enclave exception handler.

ㆍ 스레드 또는 엔클레이브를 포기한다.• Give up the thread or enclave.

예상됨 상태에서의 EENTER는 핸들링 상태로 진행한다. 트랩 핸들러(핸들링 상태)로부터의 EEXIT는 핸들링됨 상태로 진행한다. ENTER/NORMAL은 이 상태에서 불법이다. 탬폴린으로부터의 EIRET는 최종 인터럽트 시에 SSA 상에 푸시된 상태, 활성 또는 핸들링 상태를 재개한다.EENTER in the expected state proceeds to the handling state. EEXIT from the trap handler ( handling state) proceeds to the handled state. ENTER / NORMAL is illegal in this state. EIRET from the tampoline resumes the pushed, active or handling state on the SSA at the last interrupt.

보안 엔클레이브 명령어는 2개의 옵코드, 즉, 특권 옵코드 및 비특권 옵코드로 분할된다. 명령어 연산은 명령어가 호출될 때 RAX에서의 값에 의해 결정된다.The secure enclave instruction is divided into two opcodes: privileged opcode and non-privileged opcode. The instruction operation is determined by the value in RAX when the instruction is called.

[표 19-2]Table 19-2

[표 19-3]Table 19-3

ECREATE 명령어는 보호된 SECS를 초기화한다. 소스 연산자는 page_info 구조를 포인팅한다. 콘텐츠 페이지 필드는 비보호 SECS 구조를 포인팅한다. SEC 구조는 페이지 정렬될 수 있다. SECS 베이스의 하위 12 비트 및 경계값은 0일 수 있다. SECS는 EPC 내의 빈 슬롯의 어드레스이다. sec_info는 비보호 sec_info 구조의 어드레스이다. 대응하는 sec_info 플래그 필드가 적절히 초기화될 수 있다.The ECREATE command initiates a protected SECS. The source operator points to the page_info structure. The content page field points to an unprotected SECS structure. The SEC structure can be page aligned. The lower 12 bits and the boundary value of the SECS base may be zero. SECS is the address of an empty slot in the EPC. sec_info is the address of an unprotected sec_info structure. The corresponding sec_info flag field may be initialized appropriately.

명령어 입력(들)Command input (s)

RAX 0x0RAX 0x0

RBX PAGE_INFORBX PAGE_INFO

포인터
Pointer

명령어 출력Command output

레지스터 RAX.TAX는 명령어가 실패하면 에러 코드를 포함한다.
The register RAX.TAX contains an error code if the instruction fails.

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: US#에 기인REP: attributed to US #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨Address size: ignored

Rex: 무시됨
Rex: Ignored

보호 protect 모드mode 익셉션들Exceptions

#GP(0) 현재 특권 레벨이 0이 아니라면.#GP (0) If the current privilege level is not zero.

#PF(폴트-코드) 액세스 메모리 연산자에 페이지 폴트가 발생하면.#PF (Fault-Code) When a page fault occurs in an access memory operator.

#UD 엔클레이브들이 인에이블되지 않으면.
If #UD enclaves are not enabled.

실제 어드레스 Physical address 모드mode 익셉션들Exceptions

#UD ECREAT 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD ECREAT instruction is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD ECREAT 명령어는 8086 모드에서 인식되지 않음.
#UD ECREAT command not recognized in 8086 mode.

EADDPREEADDPRE

명령어 설명Command Description

EADDPRE는 특권 소프트웨어로 하여금 엔클레이브 외부의 페이지를 lin_addr에 의해 특정된 엔클레이브 내의 페이지로 카피하는 것을 가능하게 하고, sec_info 플래그 필드를 사용하여 엔클레이브 페이지의 속성이 설정된다.EADDPRE enables privileged software to copy pages outside the enclave to pages in the enclave specified by lin_addr, and the attributes of the enclave pages are set using the sec_info flag field.

명령어 부분으로서, 페이지는 해시되고 그 결과의 해시 값은 엔클레이브의 측정 레지스터로 확장된다.As part of the instruction, the page is hashed and the resulting hash value is expanded into the measurement register of the enclave.

EADDPRE는 EINIT 명령어에 의해 아직 초기화되지 않은 엔클레이브 상에서만 수행될 수 있다.
EADDPRE can only be performed on enclaves that have not yet been initialized by the EINIT instruction.

명령어 입력들Command inputs

RAX 0x1RAX 0x1

RBX PAGE_INFORBX PAGE_INFO

포인터 Pointer

RCX EPC 선형 어드레스RCX EPC Linear Address

RDX SMAP 포인터
RDX SMAP Pointer

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: US#에 기인REP: attributed to US #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

#UD EADDPRE 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD EADDPRE command is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD EADDPRE 명령어는 8086 모드에서 인식되지 않음.
#UD EADDPRE command not recognized in 8086 mode.

EADDPOSTEADDPOST

명령어 설명Command Description

EADDPOST는 특권 소프트웨어로 하여금 lin_addr에 의해 특정된 엔클레이브의 SMAP 엔트리를 초기화하고, sec_info 플래그 필드를 사용하여 엔클레이브 페이지의 속성이 설정된다.EADDPOST causes privileged software to initialize the SMAP entry of the enclave specified by lin_addr, and set the attributes of the enclave page using the sec_info flag field.

엔클레이브가 페이지를 액세스하기 전에, EACCEPT 명령어를 사용하여 엔클레이브로 페이지를 수용할 수 있다.Before an enclave can access a page, it can accept the page into the enclave using the EACCEPT instruction.

EADDPOST는 EINIT 명령어에 의해 아직 초기화된 엔클레이브 상에서만 수행될 수 있다.
EADDPOST can only be performed on enclaves that have yet been initialized by the EINIT instruction.

명령어 입력들Command inputs

RAX 0xaRAX 0xa

RBX PAGE_INFORBX PAGE_INFO

포인터 Pointer

RCX EPC 선형 어드레스RCX EPC Linear Address

RDX SMAP 포인터
RDX SMAP Pointer

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: US#에 기인REP: attributed to US #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

#UD EADDPOST 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD EADDPOST command is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD EADDPOST 명령어는 8086 모드에서 인식되지 않음.
#UD EADDPOST command is not recognized in 8086 mode.

EMKPERMITEMKPERMIT

명령어 설명Command Description

엔클레이브 또는 라이센스를 인증하고 그로부터 퍼밋을 생성한다. rbx==NULL이면, 인증서는 인텔에 의해 서명될 수 있다. 그렇지 않으면, 라이센스는 rbx 퍼밋에 표시된 키에 의해 서명될 수 있다.
Authenticate an enclave or license and generate a permit from it. If rbx == NULL, the certificate can be signed by Intel. Otherwise, the license can be signed by the key indicated in the rbx permit.

명령어 입력들Command inputs

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: US#에 기인REP: attributed to US #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

#UD 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD instruction not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD 명령어는 8086 모드에서 인식되지 않음.
#UD command not recognized in 8086 mode.

EINITEINIT

명령어 설명Command Description

ENIT는 소프트웨어 환경에서 실행 준비로서 엔클레이브를 마킹한다. 성공적인 초기화 끝에, 엔클레이브에 대해 EENTER가 허가될 것이다.
ENIT marks an enclave as ready for execution in a software environment. After a successful initialization, EENTER will be granted for the enclave.

명령어 입력들Command inputs

RAX 0x2RAX 0x2

RBX SECS 포인터RBX SECS Pointer

RCX PERMIT 포인터
RCX PERMIT pointer

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

ELPGELPG

명령어 설명Command Description

이 명령어는 페이지를 엔클레이브 페이지 캐시(EPC)로 로딩하는데 사용된다.
This instruction is used to load a page into the Enclave Page Cache (EPC).

명령어 입력들Command inputs

소스 페이지의 선형 어드레스: page_infoLinear address of the source page: page_info

목적지의 선형 어드레스: epc_la
Linear address of the destination: epc_la

명령어 연산Instruction operation

ReturnReturn ::

성공적이라면, 명령어는 ELFAGS 레지스터의 Z 플래그를 0으로 설정하고, 그렇지 않으면 Z 플래그는 1로 설정된다. ENCLAVE_STATUS_MSR은 다음의 이유들 중 하나를 홀드한다. If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons.

1. 페이지 검증 실패1. Page validation failed

2. 파라미터가 올바르게 정렬되지 않음2. Parameters are not aligned correctly

3. page_info 파라미터가 SECS 로딩에 대해 기형
3. page_info parameter is malformed for SECS loading

영향받는 플래그들Affected Flags

연산 참조
Operation reference

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EWBINVPGEWBINVPG

명령어 설명Command Description

이 명령어는 더티 페이지들을 EPC로부터 메인 메모리로 다시 기록하는데 사용된다.
This command is used to write dirty pages back from EPC to main memory.

명령어 입력들Command inputs

page_infopage_info

epc_la
epc_la

명령어 연산Instruction operation

ReturnReturn ::

성공적이라면, 명령어는 ELFAGS 레지스터의 Z 플래그를 0으로 설정하고, 그렇지 않으면 Z 플래그는 1로 설정된다. ENCLAVE_STATUS_MSR은 다음의 이유들 중 하나를 홀드한다:If successful, the instruction sets the Z flag in the ELFAGS register to 0, otherwise the Z flag is set to 1. ENCLAVE_STATUS_MSR holds for one of the following reasons:

1. 특정 EPC 슬롯이 점유되지 않음1. Certain EPC slots are not occupied

2. 파라미터가 올바르게 정렬되지 않음
2. Parameters are not aligned correctly

영향받는 플래그들Affected Flags

연산 참조
Operation reference

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EUPSMAPEUPSMAP

명령어 설명Command Description

이 명령어는 EPC에 상주하는 엔클레이브 페이지의 버전을 검사하고 업데이트한다.
This command checks and updates the version of the enclave page residing in the EPC.

명령어 입력들Command inputs

leafleaf

epc_laepc_la

smap_la
smap_la

명령어 연산Instruction operation

RetrunRetrun ::

1. TBD
1. TBD

영향받는 플래그들Affected Flags

연산 참조
Operation reference

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EREMOVEEREMOVE

명령어 설명Command Description

이 명령어는 데이터가 EPCP에 로딩될 때 SMAP을 업데이트한다.
This command updates the SMAP when data is loaded into the EPCP.

명령어 입력들Command inputs

leafleaf

epc_laepc_la

smap_la
smap_la

명령어 연산Instruction operation

RetrunRetrun ::

2. TBD
2. TBD

영향받는 플래그들Affected Flags

연산 참조
Operation reference

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EADDSMAPEADDSMAP

명령어 설명Command Description

이 명령어는 엔클레이브가 이미 초기화될 때 새로운 페이지를 SMAP에 부가하는데 사용된다.
This instruction is used to add a new page to SMAP when the enclave is already initialized.

명령어 입력들Command inputs

page_infopage_info

epc_laepc_la

smap_lasmap_la

Name of Offset 값Name of Offset value

LIN_ADDR MBZLIN_ADDR MBZ

SOURCE_PAGE 페이지 콘텐츠가 위치하는 페이지의 선형 어드레스Linear address of the page where the SOURCE_PAGE page content is located

SEC_INFO 페이지에 대한 secinfo 구조의 선형 어드레스Linear address of secinfo structure for SEC_INFO page

SECS 빈 슬롯의 EPC의 선형 어드레스
Linear address of EPC in SECS empty slot

명령어 연산Instruction operation

RetrunRetrun ::

3. TBD
3. TBD

영향받는 플래그들Affected Flags

연산 참조
Operation reference

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EMODIFYEMODIFY

명령어 설명Command Description

이 명령어는 엔클레이브가 그 엔클레이브 내부의 페이지를 수정하게 할 수 있도록 SEC_INFO 필드를 수정한다. 엔클레이브는 페이지에 대한 변경을 요청하지만 프로세스를 완료하기 위해 그러한 변경을 수용할 수 있다.
This instruction modifies the SEC_INFO field so that the enclave can modify pages within that enclave. The enclave requests a change to the page but can accept that change to complete the process.

명령어 입력들Command inputs

명령어 연산Instruction operation

RetrunRetrun ::

4. TBD
4. TBD

영향받는 플래그들Affected Flags

연산 참조
Operation reference

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EACCEPTEACCEPT

명령어 설명Command Description

엔클레이브 내부의 소프트웨어는 이 명령을 사용하여 SEC_INFO 필드에 대한 변경을 수용한다. 이것은 SMAP이 새로운 페이지 유형으로 업데이트되도록 할 수 있다.
Software inside the enclave uses this command to accept changes to the SEC_INFO field. This can cause SMAP to be updated with the new page type.

명령어 입력들Command inputs

명령어 연산Instruction operation

RetrunRetrun ::

5. TBD
5. TBD

영향받는 플래그들Affected Flags

연산 참조
Operation reference

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EENTEREENTER

명령어 설명Command Description

EENTER 명령어는 실행을 엔클레이브로 전달한다. 명령어 끝에, CUP는 TCS oENTRY 또는 oHANDLER에 특정된 IP에서 엔클레이브 모드로 실행중이다.The EENTER instruction passes the execution to the enclave. At the end of the command, the CUP is running in enclave mode on the IP specified in the TCS oENTRY or oHANDLER.

EENTER는 TCS가 유효한지 그리고 엔트리에 대해 이용가능한지를 검사한다. TCS 및 대응하는 SSA는 진행할 명령어를 위해 메모리에 상주할 수 있다.EENTER checks whether the TCS is valid and available for the entry. The TCS and the corresponding SSA may reside in memory for instructions to proceed.

EENTER는 또한 엔트리 유형을 결정하도록 상태 머신을 검사하고 단지 하나의 로직 프로세서가 TCS 내부에서 한번에 활성이된다는 것을 검사한다.EENTER also checks the state machine to determine the entry type and checks that only one logic processor is active at a time inside the TCS.

RFLAGS.TF는 EENTER에 대해 약간 수정된 거동을 갖는다. RFLAGS.TF는 TCS.SAVE_TF에 저장된 다음, TCS.TF로부터 로딩된다. 다음에, RFLAGS.TFDML 업데이트된 값에 의존하여 디버그 익셉션이 조건부로 생성된다. 엔클레이브가 디버그 모드에 있지 않다면, 디버그 레지스터 DR7은 TCS.DR7에 저장되고 클리어된다. IA32_DEBUGCTL MSR에 대해서도 유사하다.
RFLAGS.TF has a slightly modified behavior for EENTER. RFLAGS.TF is stored in TCS.SAVE_TF and then loaded from TCS.TF. Next, debug exceptions are conditionally generated depending on the RFLAGS.TFDML updated value. If the enclave is not in debug mode, debug register DR7 is stored and cleared in TCS.DR7. Similar for IA32_DEBUGCTL MSR.

명령어 입력들Command inputs

RAX 0x4RAX 0x4

RBX TCS 포인터
RBX TCS Pointer

명령어 출력들Command outputs

RCX EPC 선형 어드레스
RCX EPC Linear Address

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

RFLAGSRFLAGS .. TFTF 거동 motion

EENTER의 실행 시작시에 RFLAGS.TF의 값은 EENTER의 완료의 트랩에 대해 영향을 받지 않는다. 대신, TCS로부터 로딩되는 RFLAGS.TF의 값은 트랩이 취해지는지 여부를 결정한다.
At the start of the execution of EENTER, the value of RFLAGS.TF is not affected by the trap of completion of EENTER. Instead, the value of RFLAGS.TF loaded from the TCS determines whether a trap is taken.

DR7DR7 거동 motion

엔클레이브가 디버그 모드에 있지 않으면, 디버그 레지스터 DR7은 TCS.DR7에 저장되고 클리어된다.
If the enclave is not in debug mode, debug register DR7 is stored and cleared in TCS.DR7.

IA32IA32 __ DEBUGDEBUG __ CTLCTL 거동 motion

엔클레이브가 디버그 모드에 있지 않으면, IA32_DEBUG_CTL MSR이 TCS에 저장된다. DEBUG_CTL은 클리어된다.
If the enclave is not in debug mode, the IA32_DEBUG_CTL MSR is stored in the TCS. DEBUG_CTL is cleared.

보호 protect 모드mode 익셉션들Exceptions

#GP(0) 현재 특권 레벨이 3이 아니라면.#GP (0) If the current privilege level is not 3.

엔클레이브 내부에서 실행된다면.If run inside the enclave.

프로세서가 SMM에 있다면.If the processor is in the SMM.

세그먼트 레지스터 또는 제한 레지스터가 올바르게 설정되어 있지 않다면If the segment register or limit register is not set correctly

스레드가 사용중이라면If the thread is busy

엔클레이브 모드에서 실행Running in enclave mode

#UD ECALL 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD ECALL instruction is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD ECALL 명령어는 8086 모드에서 인식되지 않음.
#UD ECALL command is not recognized in 8086 mode.

EEXITEEXIT

EEXIT는 엔클레이브 밖으로 나간다.
EEXIT goes out of the enclave.

명령어 설명Command Description

EEXIT는 엔클레이브 모드를 디스에이블하고 RBX에 특정된 위치로 분기한다.EEXIT disables enclave mode and branches to the location specified in RBX.

이 명령어에 의해 영향받는 레지스터는 없다. 비밀이 임의의 레지스터에 포함된다면, 그들 레지스터를 클리어하는 것은 엔클레이브 소프트웨어가 담당한다.There are no registers affected by this instruction. If secrets are contained in any register, it is the Enclave software's responsibility to clear those registers.

RFLAGS.TF는 EEXIT에 대해 약간 수정된 거동을 갖는다. RFLAGS.TF는 TCS.SAVE_TF로부터 로딩된다. RFLAGS.TF의 업데이트된 값에 의존하여 디버그 익셉션이 조건부로 생성된다.RFLAGS.TF has a slightly modified behavior for EEXIT. RFLAGS.TF is loaded from TCS.SAVE_TF. Depending on the updated value of RFLAGS.TF, debug exceptions are conditionally generated.

엔클레이브가 디버그 모드에 있지 않으면, 디버그 레지스터 DR7이 TCR.DR7로부터 로딩된다. 이 거동 및 RFLAGS.TFDML 거동은 ???에 보다 상세히 문서화되어 있다.
If the enclave is not in debug mode, debug register DR7 is loaded from TCR.DR7. This behavior and the RFLAGS.TFDML behavior is documented in more detail in ???.

명령어 입력들Command inputs

RAX 0x6RAX 0x6

RBX 타겟 어드레스
RBX Target Address

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

RFLAGSRFLAGS .. TFTF 거동 motion

EENTER의 실행 시작시에 RFLAGS.TF의 값은 EENTER의 완료의 트랩에 대해 영향을 받지 않는다. 대신, SSA로부터 로딩되는 RFLAGS.TF의 값은 트랩이 취해지는지 여부를 결정한다.
At the start of the execution of EENTER, the value of RFLAGS.TF is not affected by the trap of completion of EENTER. Instead, the value of RFLAGS.TF loaded from the SSA determines whether a trap is taken.

DR7DR7 거동 motion

엔클레이브가 디버그 모드에 있지 않으면, 디버그 레지스터 DR7은 TCS.DR7로부터 로딩된다.
If the enclave is not in debug mode, debug register DR7 is loaded from TCS.DR7.

IA32IA32 __ DEBUGDEBUG __ CTLCTL 거동 motion

엔클레이브가 디버그 모드에 있지 않으면, IA32_DEBUG_CTL MSR이 TCS로부터 로딩된다. If the enclave is not in debug mode, the IA32_DEBUG_CTL MSR is loaded from the TCS.

DEBUG_CTL.
DEBUG_CTL.

보호 protect 모드mode 익셉션들Exceptions

엔클레이브 외부에서 실행된다면.If run outside the enclave.

프로세서가 SMM에 있다면.If the processor is in the SMM.

스레드 사용중이 ACTIVE 또는 HANDLED 상태에 있지 않다면If thread busy is not in ACTIVE or HANDLED state

#UD EEXIT 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD EEXIT instruction is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD EEXIT 명령어는 8086 모드에서 인식되지 않음.
#UD EEXIT command is not recognized in 8086 mode.

EIRETEIRET

명령어 설명Command Description

EIRET 명령어는 SSA에 이전에 저장된 머신 상태를 사용하는 익셉션 또는 인터럽트에 기인하여 인터럽된 엔클레이브의 실행을 재개한다. EIRET는 TCS가 유효하고 재개에 대해 이용가능하다는 것을 검사한다. TCS 및 그에 대응하는 SSA는 진행할 명령어를 위해 메모리에 상주할 수 있다. EIRET는 또한 엔트리 유형을 결정하기 위해 상태 머신을 검사하고, 단지 하나의 로직 프로세서만이 TCS 내부에서 한번에 활성이 되는 것을 검사한다.The EIRET instruction resumes execution of an interrupted enclave due to an exception or interrupt using the machine state previously stored in the SSA. EIRET checks that the TCS is valid and available for resume. The TCS and its corresponding SSA may reside in memory for instructions to proceed. EIRET also checks the state machine to determine the entry type, and checks that only one logic processor is active at a time inside the TCS.

RFLAGS.TF가 EIRET 상에 설정되어 있으면, 디버그 익셉션은 명령어의 완료 시, 즉, 정상 TF 거동시에 발생할 것이다. 이 익셉션은, 어떠한 명령어도 내부에서 실행되지 않으면서, 엔클레이브 내부에서 (일반적인 SE-정의 형식으로) 발생하는 것으로 보고될 것이다. EIRET가 SSA로부터 RFLAGS를 다시 저장하기 때문에, TF는 EIRET의 종료시에 설정될 수 있다. 이 경우에, TF는 다음의 명령어에 여향을 미칠 것이다; 다시, 정상 TF 거동.
If RFLAGS.TF is set on EIRET, the debug exception will occur at the completion of the instruction, that is, during normal TF behavior. This exception will be reported to occur inside the enclave (in normal SE-defined format) without any instructions being executed internally. Since EIRET stores RFLAGS back from SSA, TF can be set at the end of EIRET. In this case, the TF will affect the following instruction; Again, normal TF behavior.

명령어 입력들Command inputs

RAX 0x5RAX 0x5

RBX TCS 포인터
RBX TCS Pointer

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

RFLAGSRFLAGS .. TFTF 거동 motion

EIRET의 실행 시작시에 RFLAGS.TF가 설정되어 있다면, #DB는 완료 후에 발생할 것이다. 익셉션은 제어가 전이된 RIP에서 TF가 설정되지 않았다는 것이 보고될 것이다. 사실상, 엔클레이브 내의 전방 진행은 발생하지 않을 것이다.If RFLAGS.TF was set at the beginning of the EIRET run, #DB will occur after completion. The exception will be reported that no TF is set in the RIP to which control has transferred. In fact, no forward progression in the enclave will occur.

EIRET의 정상 연산 부분으로서, RFLAGS는 SSA 카피로부터 다시 저장된다. 그 결과의 TF가 설정되고, #DB는 엔클레이브 내부의 타겟 명령어의 실행 후에 발생할 것이다.As a normal operation part of EIRET, RFLAGS is stored back from the SSA copy. The resulting TF is set, and #DB will occur after execution of the target instruction inside the enclave.

이들 거동은 정상 IA IRET 명령어의 거동과 일치한다.
These behaviors match those of normal IA IRET instructions.

DR7DR7 거동 motion

DR7은 마지막 인터럽트 또는 익셉션에서 이전에 저장된 SSA 카피로부터 다시 저장된다.
DR7 is saved back from the previously saved SSA copy at the last interrupt or exception.

IA32IA32 __ DEBUGDEBUG __ CTLCTL 거동 motion

IA32_DEBUG_CTL MSR은 마지막 인터럽트 또는 익셉션에 이미 저장된 SSA 카피로부터 다시 저장된다.
The IA32_DEBUG_CTL MSR is saved back from the SSA copy already stored at the last interrupt or exception.

보호 protect 모드mode 익셉션들Exceptions

엔클레이브 내부에서 실행된다면.If run inside the enclave.

프로세서가 SMM에 있다면.If the processor is in the SMM.

스레드 사용중이면If thread is busy

엔클레이브 모드에서 실행Running in enclave mode

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EREPORTEREPORT

EREPORT 명령어는 엔클레이브 콘텐츠에 관한 측정을 보고한다.
The EREPORT instruction reports a measurement on enclave content.

명령어 설명Command Description

EREPORT는 엔클레이브 측정 레지스터, 자신의 능력 및 디버구 상태(플래그)를 검색한다. 이들 모든 값은, REPORT 키를 사용하여 검증될 수 있는 대칭 메시지 인증 코드를 사용하여 보호된다. REPORT 키를 요구하는 엔클레이브는, EGETKEY 명령어를 이용하여 그것을 검색하기 위해, 자신들의 SECS에 적절히 설정된 능력을 가질 수 있다. EREPORT retrieves the enclave measurement registers, their capabilities, and their debug status (flag). All these values are protected using a symmetric message authentication code that can be verified using the REPORT key. Enclaves requesting a REPORT key may have the ability set appropriately in their SECS to retrieve it using the EGETKEY command.

이 명령의 결과가 목적지 위치, output_buffer_la에 집적된다.
The result of this command is integrated into the destination location, output_buffer_la.

명령어 입력들Command inputs

RAX 0x6RAX 0x6

RBX output_buffer_laRBX output_buffer_la

RCX userInput_la
RCX userInput_la

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

#UD EREPORT 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD EREPORT command is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD EREPORT 명령어는 8086 모드에서 인식되지 않음.
#UD EREPORT command is not recognized in 8086 mode.

ERDMRERDMR

ERDMR 명령어는 엔클레이브 SECS 외부의 측정 레지스터 값을 판독한다.
The ERDMR instruction reads the measurement register value outside of the enclave SECS.

명령어 설명Command Description

이 명령어는 단지 엔클레이브 외부로부터만 실행될 수 있다. SECS가 유효 SECS 페이지를 포인팅하면, 이 명령어는 엔클레이브 측정 레지스터의 콘텐츠를 output_buffer_la에 의해 특정된 어드레스로 출력한다.
This instruction can only be executed from outside the enclave. If the SECS points to a valid SECS page, this command outputs the contents of the enclave measurement register to the address specified by output_buffer_la.

명령어 입력들Command inputs

RAX 0x8RAX 0x8

RBX sec_laRBX sec_la

RCX output_buffer_la
RCX output_buffer_la

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

EGETKEYEGETKEY

프로세서 키 계층으로부터 특정 키를 리턴하기 위해 엔클레이브 모드에 의해 사용됨.
Used by enclave mode to return a specific key from the processor key hierarchy.

명령어 설명Command Description

요구되는 키는 KeyRequest 구조를 사용하여 특정되며, 그의 어드레스는 입력으로서 제공된다. 이 어드레스는 자연적으로 정렬될 수 있다.The required key is specified using the KeyRequest structure, whose address is provided as input. This address can be naturally aligned.

출력은 항상 256 비트 데이터 값이다. output_la는 이 값에 대해 자연적으로 정렬될 필요가 있다.
The output is always a 256 bit data value. output_la needs to be sorted naturally for this value.

입력들Inputs

RAX 0x02RAX 0x02

RBX request_laRBX request_la

RCX output_buffer_la
RCX output_buffer_la

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

#UD EGETKEY 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD EGETKEY instruction is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD EGETKEY 명령어는 8086 모드에서 인식되지 않음.
#UD EGETKEY command not recognized in 8086 mode.

ERDTCSPTRERDTCSPTR

명령어 설명Command Description

ERDTCSPTR 명령어는 RBX로의 현재 TCS 선형 어드레스를 판독하는데 사용된다.
The ERDTCSPTR instruction is used to read the current TCS linear address into the RBX.

명령어 출력Command output

RAX 0x3
RAX 0x3

명령어 출력Command output

RBX 현재 TCS 포인터
RBX Current TCS Pointer

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: US#에 기인REP: attributed to US #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

#UD 엔클레이브가 인에이블되지 않으면,If the #UD enclave is not enabled,

#GP(0) 엔클레이브 외부에서 실행된다면.If run outside the #GP (0) enclave.

#UD ERDTCSPTR 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD ERDTCSPTR instruction is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD ERDTCSPTR 명령어는 8086 모드에서 인식되지 않음.
#UD ERDTCSPTR command is not recognized in 8086 mode.

EDBGRDEDBGRD

명령어 설명Command Description

EDBGRD 명령어는 디버그 엔클레이브로부터 8 바이트를 판독하는데 사용된다.
The EDBGRD instruction is used to read 8 bytes from the debug enclave.

명령어 입력들Command inputs

epc_laepc_la

dest
dest

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: UD#에 기인REP: attributed to UD #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

#GP(0) 엔클레이브가 디버그로 마킹되지 않으면#GP (0) If the enclave is not marked for debug

#UD EDBGRD 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD EDBGRD command is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD EDBGRD 명령어는 8086 모드에서 인식되지 않음.
#UD EDBGRD command is not recognized in 8086 mode.

EDBGWREDBGWR

명령어 설명Command Description

EDBGWR 명령어는 엔클레이브 페이지를 디버그하기 위해 8 바이트를 기록하는데 사용된다.
The EDBGWR instruction is used to write 8 bytes to debug the enclave page.

명령어 입력들Command inputs

srcsrc

epc_la
epc_la

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

없음
none

프레픽스의Prefix 사용 use

TBD
TBD

보호 protect 모드mode 익셉션들Exceptions

GP(0) 엔클레이브가 디버그로 마킹되어 있지 않다면If the GP (0) enclave is not marked for debug

#UD EDBGWR 명령어는 실제 어드레스 모드에서 인식되지 않음.
#UD EDBGWR instruction is not recognized in real address mode.

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

#UD EDBGWRITE 명령어는 8086 모드에서 인식되지 않음.
#UD EDBGWRITE command is not recognized in 8086 mode.

ERDINFOERDINFO

ERDINFO 명령어는 엔클레이브 페이지 캐시의 콘텐츠에 관한 정보를 리턴한다.
The ERDINFO instruction returns information about the contents of the enclave page cache.

명령어 설명Command Description

엔클레이브에서 실행된다면, EREPORT는 엔클레이브 측정 레지스터에게 자신의 능력 및 디버그 상태(플래그)를 보고한다. 이들 모든 값은, EVERIFYREPORT 명령어를 사용하여 검증될 수 있는 대칭 메시지 인증 코드를 사용하여 보호된다.If executed in an enclave, EREPORT reports its capability and debug status (flag) to the enclave measurement register. All these values are protected using a symmetric message authentication code that can be verified using the EVERIFYREPORT command.

이 명령의 결과는 목적지 위치, output_buffer_la에 퇴적된다.
The result of this command is deposited at the destination location, output_buffer_la.

명령어 입력들Command inputs

epc_la //EPC 내부의 페이지의 선형 어드레스epc_la // Linear address of the page inside the EPC

page_info //page_info 내부의 SEC_INFO 필드는 유효 포인터로 포퓰레이팅될 수 있다//자연스럽게 정렬된 SEC_INFO 구조
page_info // SEC_INFO field inside page_info can be populated with a valid pointer // naturally aligned SEC_INFO structure

명령어 연산Instruction operation

영향받는 플래그들Affected Flags

RFLAGS.ZF
RFLAGS.ZF

프레픽스의Prefix 사용 use

잠금: UD#에 기인Lock: attributed to UD #

REP: US#에 기인REP: attributed to US #

세그먼트 오버라이드: N/ASegment Override: N / A

연산자 크기: UD#에 기인Operator size: attributed to UD #

어드레스 크기: 무시됨
Address size: ignored

보호 protect 모드mode 익셉션들Exceptions

#UD 엔클레이브들이 인에이블되지 않으면.If #UD enclaves are not enabled.

#GP CPL!=0이면If #GP CPL! = 0

FAULT epc_la가 EPC 내를 포인팅하지 않으면
FAULT epc_la does not point within EPC

가상 8086 Virtual 8086 모드mode 익셉션들Exceptions

루틴 Routine 레퍼런스reference

----------------------------------------------------------------------------------------------------------------------- -------------------

ExitsExits

이 섹션은 엑시트 프로세싱을 위해 의사 코드를 제공한다. 이 코드는 엔클레이브 코드에 의해 계획되지 않은 엔클레이브로부터의 엑시트일 때 호출된다. 엔클레이브 실행은 중지된 곳에서 재개된다. 재개에 필요한 정보는 외부 스택에 저장된다. 프로세서의 아키텍처 상태는 적절한 저장 영역에 저장된다.
This section provides pseudo code for exit processing. This code is called when an exit from an enclave is not planned by the enclave code. Enclave execution resumes where it left off. The information needed to resume is stored on the external stack. The architectural state of the processor is stored in the appropriate storage area.

연산calculate

acquireacquire readerreader locklock

RW 잠금은 로직 프로세서가 공유 자원을 액세스할 수 있게 하고 스레드가 공유 자원을 액세스할 수 있는 두 개의 모드를 제공한다:RW locks allow the logic processor to access shared resources and provide two modes in which threads can access shared resources:

ㆍ 공유 모드는 다수의 판독기 로직 프로세서에 공유 판독전용 액세스를 허가하는데, 이것은 그들이 공유 자원으로부터 동시에 데이터를 판독가능하게 한다.Shared mode grants multiple read logic access to multiple reader logic processors, which allows them to read data simultaneously from shared resources.

ㆍ 독점 모드는 하나의 기록기 로직 프로세서에 한번에 한번의 판독/기록 액세스를 허가한다. 독점 모드에서 잠금이 획득되면, 기록기가 잠금을 해제할 때까지 공유 자원을 액세스할 수 있는 다른 스레드는 없다.
Proprietary mode allows one writer logic processor one read / write access at a time. When a lock is acquired in exclusive mode, no other thread can access the shared resource until the writer releases the lock.

단일 RW 잠금은 어느 하나의 모드에서 획득될 수 있다; 판독기 로직 프로세서는 공유 모드에서 그것을 획득하는 반면, 기록기 로직 프로세서는 독점 모드에서 그것을 획득할 수 있다. 로직 프로세서는 공정한 순서로 요청권을 승인받는다.A single RW lock can be obtained in either mode; The reader logic processor may acquire it in shared mode while the writer logic processor may acquire it in proprietary mode. Logic processors are granted request rights in a fair order.

RW 잠금 함수가 다음에 있다.Here is the RW lock function:

acquire_reader_lock, release_reader_rock, acquire_writer_lock, release_lock.
acquire_reader_lock, release_reader_rock, acquire_writer_lock, release_lock.

서브루틴 설명Subroutine Description

공유 모드에서 잠금을 획득한다.
Acquire the lock in shared mode.

서브루틴 입력Subroutine input

volatile se_rw_lock_t*l
volatile se_rw_lock_t * l

서브루틴 연산Subroutine operation

영향받는 플래그Affected Flag

없음
none

익셉션들Exceptions

없음
none

releaserelease readerreader locklock

서브루틴 설명Subroutine Description

공유 모드에서 획득된 잠금을 해제
Unlock acquired in shared mode

서브루틴 입력들Subroutine inputs

volatile se_rw_lock_t*1
volatile se_rw_lock_t * 1

서브루틴 연산Subroutine operation

영향받는 플래그Affected Flag

없음
none

익셉션들Exceptions

없음
none

acquireacquire writerwriter locklock

서브루틴 설명Subroutine Description

독점 모드에서 잠금 획득
Acquire lock in exclusive mode

서브루틴 입력들Subroutine inputs

volatile se_rw_lock_t*1
volatile se_rw_lock_t * 1

서브루틴 연산Subroutine operation

영향받는 플래그Affected Flag

없음
none

익셉션들Exceptions

없음
none

releaserelease writerwriter locklock

서브루틴 설명Subroutine Description

독점 모드에서 획득된 잠금을 해제
Unlock acquired in exclusive mode

서브루틴 입력들Subroutine inputs

volatile se_rw_lock_t*1
volatile se_rw_lock_t * 1

서브루틴 연산Subroutine operation

영향받는 플래그Affected Flag

없음
none

익셉션들Exceptions

없음
none

xutranslatexutranslate

서브루틴 설명Subroutine Description

이 서브루틴은 사실상 uCode가 PMH 어드레스변환 기능을 xuCode에 노출하여 부가하는 하드웨어이다. XUTRANSLATE는 입력으로서 PMH 콘텍스트, 및 선형 어드레스를 취하는 xuOp이고, 출력으로서 최종 물리 어드레스를 생성한다. PMH가 페이지 테이블 워크동안 임의의 폴트 조건을 만나게 되면, 이들은 xuCode로 보고된다. 이 xuOp의 상세는 본 문서의 범위를 벗어난다.
This subroutine is actually hardware that uCode exposes and adds PMH address translation function to xuCode. XUTRANSLATE is an xuOp that takes a PMH context, and a linear address as input, and generates the final physical address as output. If the PMH encounters any fault condition during the page table walk, they are reported as xuCode. The details of this xuOp are beyond the scope of this document.

서브루틴 입력들Subroutine inputs

TBD
TBD

서브루틴 연산Subroutine operation

영향받는 플래그Affected Flag

없음
none

익셉션들Exceptions

없음
none

deriveKeyderiveKey

서브루틴 설명Subroutine Description

이 서브루틴은 식별된 키를 이용하여 DerivationBuffer에 걸쳐 CMAC 연산을 수행함으로써 키를 생성하는데 사용된다. DerivationBuffer는 다수의 128 비트일 필요가 있다.
This subroutine is used to generate a key by performing a CMAC operation over the DerivationBuffer using the identified key. DerivationBuffer needs to be a number of 128 bits.

서브루틴 입력들Subroutine inputs

pBaseKey- 사용된 베이스 키pBaseKey-the base key used

derivationBuffer- 해시될 고정 크기의 버퍼
derivationBuffer- fixed size buffer to be hashed

서브루틴 연산Subroutine operation

영향받는 플래그Affected Flag

없음
none

익셉션들Exceptions

없음none

Claims

프로세서(a processor)로서,
보호된 데이터를 액세싱하는 프로그램의 실행동안 엔클레이브 페이지 캐시(enclave page cache; EPC)와 제2 스토리지 영역 사이에 상기 보호된 데이터를 이동시키라는 적어도 제1 명령어를 수행하기 위한 실행 로직을 포함하고, 상기 프로그램은 보호 모드에서 실행되는
프로세서.
As a processor,
Execution logic for performing at least a first instruction to move the protected data between an enclave page cache (EPC) and a second storage area during execution of a program that accesses protected data; , The program is running in protected mode
Processor.

제1항에 있어서,
보안 맵(a security map)(SMAP)은 상기 프로그램이 하드 디스크 드라이브 또는 보호된 메모리에 저장될 때 상기 프로그램의 무결성(integrity)을 보장하는데 도움을 주는
프로세서.
The method of claim 1,
A security map (SMAP) helps to ensure the integrity of the program when the program is stored on a hard disk drive or protected memory.
Processor.

프로세서로서,
보안 엔클레이브에서 실행 중인 소프트웨어 스레드(thread)를 식별하라는 제1 명령어를 수행하기 위한 실행 로직을 포함하고, 상기 제1 명령어는 사용자의 프로그램에게 상기 소프트웨어 스레드의 아이덴티티(identity)를 통지하는
프로세서.
As a processor,
Execution logic for performing a first instruction to identify a software thread executing in a secure enclave, wherein the first instruction informs a user's program of the identity of the software thread.
Processor.

프로세서로서,
보안 클레이브에 저장된 데이터의 무결성을 결정하기 위해 적어도 하나의 정보 필드에 동적으로 액세스하라는 적어도 제1 명령어를 수행하기 위한 실행 로직을 포함하고, 상기 적어도 하나의 정보 필드는 보안 맵(SMAP) 필드 및 보안 정보(SEC_INFO) 필드를 포함하는
프로세서.
As a processor,
Execution logic for performing at least a first instruction to dynamically access at least one information field to determine the integrity of data stored in the secure clave, wherein the at least one information field comprises a security map (SMAP) field and a security; Contains information (SEC_INFO) field
Processor.

프로세서로서,
메모리에 저장된 보안 엔클레이브의 상태를 로컬 에이전트 또는 원격 에이전트 중 어느 하나로 레포트하라는 제1 명령어를 수행하기 위한 실행 로직을 포함하는
프로세서.
As a processor,
Execution logic for performing a first instruction to report a state of a secure enclave stored in memory to either a local agent or a remote agent.
Processor.

프로세서로서,
소프트웨어 프로그램이 실행중일 때 공격에 대해 소프트웨어 프로그램을 보호하기 위한 암호 메모리 어퍼처(crypto memory aperture; CMA); 및 소프트웨어 프로그램이 실행되지 않을 때 상기 소프트웨어 프로그램을 보호하기 위한 보안 맵(SMAP)을 포함하는
프로세서.
As a processor,
A crypto memory aperture (CMA) for protecting the software program against attacks when the software program is running; And a security map (SMAP) for protecting the software program when the software program is not running.
Processor.

프로세서로서,
inside(?)_a secure enclave에 대응하는 메모리 또는 소프트웨어 스레드들을 할당하거나 할당해제하라는 적어도 하나의 보안 엔클레이브 액세스 명령어를 수행하기 위한 실행 로직을 포함하는
프로세서.
As a processor,
includes execution logic for executing at least one secure enclave access instruction to allocate or deallocate memory or software threads corresponding to the inside (?) _ a secure enclave.
Processor.

프로세서로서,
단일 프로세서 사이클의 보안 엔클레이브 내에 다수의 메모리 업데이트를 가능하게 하기 위한 계층 보호 트리, SMAP을 포함하는
프로세서.
As a processor,
A layer protection tree, SMAP, to enable multiple memory updates within a single processor cycle of secure enclave
Processor.

프로세서로서,
고유 키를 보안 엔클레이브에 제공하라는 제1 명령어를 수행하기 위한 실행 로직을 포함하는
프로세서.
As a processor,
Execution logic for performing a first instruction to provide a unique key to a secure enclave
Processor.

프로세서로서,
비신뢰 에이전트(an untrusted agent)에 의해 관리될 신뢰 환경(a trusted environment)을 구축하라는 제1 명령어를 수행하기 위한 로직을 포함하는
프로세서.
As a processor,
Logic to perform a first instruction to establish a trusted environment to be managed by an untrusted agent
Processor.

프로세서로서,
보안 엔클레이브를 액세스하기 위한 라이센스의 유효성을 검사하라는 명령어를 수행하기 위한 로직을 포함하고, 상기 명령어는 상기 엔클레이브의 크기를 라이센스 인증서에 의해 규정된 크기와 비교하여 상기 라이센스의 유효성을 판정하는
프로세서.
As a processor,
Logic for performing instructions to validate a license for accessing a secure enclave, wherein the instruction compares the size of the enclave with a size defined by a license certificate to determine the validity of the license.
Processor.

보안 엔클레이브를 위한 사용자-레벨 정책을 인에이블하라는 로직을 포함하는 프로세서로서, 상기 로직은 제어 비트들에 의해 제어되는
프로세서.
A processor comprising logic to enable a user-level policy for a secure enclave, the logic being controlled by control bits.
Processor.

사용자에게 라이센싱될 보안 엔클레이브의 적어도 하나의 인스턴스로의 액세스를 인에이블하라는 적어도 하나의 명령어를 수행하기 위한 로직을 포함하는
프로세서.
Logic for performing at least one instruction to enable a user to access at least one instance of a secure enclave to be licensed
Processor.

프로세서로서,
보안 엔클레이브의 디버깅을 인에이블하라는 적어도 하나의 명령어를 수행하기 위한 로직을 포함하고, 상기 적어도 하나의 명령어는 디버깅될 수 있게 인에이블될 엔클레이브들에 대해서만 엔클레이브 보안을 침해하게 하는 것인
프로세서.
As a processor,
Logic for performing at least one instruction to enable debugging of the secure enclave, wherein the at least one instruction causes the enclave security to be violated only for enclaves to be enabled to be debugged.
Processor.

프로세서로서,
메모리 페이지들을 엔클레이브 페이지 캐시(EPC)로 할당하거나 또는 상기 EPC로부터 할당해제하라는 적어도 하나의 명령어를 수행하기 위한 실행 로직을 포함하는 프로세서.As a processor,
Processor logic for executing at least one instruction to allocate memory pages to an enclave page cache (EPC) or deallocate from the EPC.