JP6777288B2 - Processor - Google Patents

Description

Embodiments of the present invention generally relate to the field of information processing, and more particularly to the field of security for computing systems and microprocessors.

Ensuring execution and consistency between applications and their data within computer systems is becoming increasingly important. Security technology in the prior art cannot provide secure applications and data flexibly, reliably and appropriately.

The embodiment of the present invention is shown as an example without limitation in the accompanying drawings, and the members having the same reference numbers in the drawings are similar members.

It is a block diagram of a microprocessor which can utilize at least one embodiment of this invention. It is a block diagram of the shared bus computer system which can utilize at least one embodiment of this invention. It is a block diagram of the point-to-point interconnect computer system which can utilize at least one embodiment of this invention. It is a block diagram of a multi-core microprocessor which can utilize at least one embodiment of this invention. It is a possible implementation example of the secure enclave (SE) of one embodiment of the present invention. It is a block diagram of a microprocessor which can utilize at least one embodiment of this invention. An example of a control structure for accessing a part of the enclave page cache that can be implemented in one embodiment of the present invention is shown. An example of a thread control structure according to an embodiment of the present invention is shown, and stitching between data structures is shown. A step in a software authentication process known as quartering, which can be seen in one embodiment of the present invention, is shown. Each step for generating quotes from a measured register set in one embodiment of the present invention is shown. The EADD process for updating the measured value register MR_EADD in one embodiment of the present invention is shown. An EREPORT instruction is shown which produces a report according to an embodiment of the present invention. The relay protection mechanism found in one embodiment of the present invention is shown. An example of a part of the MAC tree structure of the relay protection mechanism found in one embodiment of the present invention is shown. An embodiment of the present invention showing how to implement a page defect error code map is shown. An example of the process of generating a permit to launch an enclave according to an embodiment of the present invention is shown. An implementation example of the platform key hierarchy for secure enclave of a single package in one embodiment of the present invention is shown. An example of a microcode-based secure enclave key hierarchy in one embodiment of the present invention is shown. An enclave CTL_MSR register that can be seen in one embodiment of the present invention is shown. The cipher block chain algorithm used in one embodiment of the present invention is shown. It is a flowchart which shows the encryption of the single AES block in one Embodiment of this invention. It is a flowchart which shows the cipher example of a plurality of AES blocks using the cipher block chain algorithm implemented in one Embodiment of this invention. An embodiment of an application and an interrupt stack after being interrupted by a stack switch is shown. An example of a method of implementing a stack of a plurality of state save area slots according to an embodiment of the present invention is shown. A portion of a state machine having interrupt, failure, and trap state transitions in one embodiment of the invention is shown. A processor package for a digital random number generator in one embodiment of the present invention is shown. The debug register DR7 2700 according to the embodiment of the present invention is shown.

Embodiments of the present invention relate to techniques for providing secure applications and data flexibly and reliably. Although there are a plurality of embodiments of the present invention in a plurality of embodiments, an attachment called "Secure Enclave Architecture" is incorporated herein by reference as at least one embodiment. However, the incorporated literature does not limit the scope of embodiments of the invention, and other embodiments are available within the spirit and scope of the invention. Here, an example of the invention according to the embodiment will be described.
[Item 1]
Execution logic that executes at least the first instruction to move the protected data between the enclave page cache (EPC) and the system memory during the execution of the program to access the protected data.
Translation Lookaside Buffer (TLB) and
With
The TLB contains at least one bit indicating that at least one entry in the TLB is for an enclave.
Processor.
[Item 2]
Security maps (SMAPs) are used to help ensure program integrity when the program is stored on a hard disk drive or protected memory.
The processor according to item 1.
[Item 3]
Execution logic at least executes a second instruction that identifies the software thread running in the secure enclave and informs the user's program of the nature of the software thread.
The processor according to item 1 or 2.
[Item 4]
Execution logic dynamically accesses at least one information field, including a secure map (SMAP) field and a security information (SEC_INFO) field, in order to determine the integrity of the data stored in the secure enclave. Execute at least 2 instructions,
The processor according to any one of items 1 to 3.
[Item 5]
The execution logic at least executes a second instruction that reports the state of the secure enclave stored in memory to either the local agent or the remote agent.
The processor according to any one of items 1 to 4.
[Item 6]
A crypto memory aperture (CMA) that protects a software program from attacks while it is running,
The processor according to any one of items 1 to 5, further comprising a secure map (SMAP) that protects the software program while it is not running.
[Item 7]
Execution logic executes at least one secure enclave access instruction that allocates or deallocates the corresponding memory or software thread in the secure enclave.
The processor according to any one of items 1 to 6.
[Item 8]
Further equipped with SMAP, a hierarchical protection tree that allows multiple memory updates within a secure enclave in a single processor cycle.
The processor according to any one of items 1 to 7.
[Item 9]
Execution logic at least executes a second instruction that provides a unique key for a secure enclave.
The processor according to any one of items 1 to 8.
[Item 10]
Execution logic at least executes a second instruction that builds a trusted environment managed by an untrusted agent.
The processor according to any one of items 1 to 9.
[Item 11]
Execution logic at least executes a second instruction that determines the validity of the license to access the secure enclave by comparing the size of the enclave to the size specified by the license certificate.
The processor according to any one of items 1 to 10.
[Item 12]
Execution logic manages secure enclave user-level policies and is controlled by control bits.
The processor according to any one of items 1 to 11.
[Item 13]
The execution logic executes at least a second instruction granting the user access to at least one instance of the licensed secure enclave.
The processor according to any one of items 1 to 12.
[Item 14]
The execution logic causes secure debugging of the enclave, at least executes a second instruction that violates the enclave security of only the enclaves that are allowed to be debugged.
The processor according to any one of items 1 to 13.
[Item 15]
Execution logic that executes at least one instruction that allocates or deallocates memory pages to the Enclave Page Cache (EPC), respectively.
Translation Lookaside Buffer (TLB) and
With
The TLB contains at least one bit indicating that at least one entry in the TLB is for an enclave.
Processor.

FIG. 1 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. In particular, FIG. 1 shows a microprocessor 100 having one or more processor cores 105 and 110, each associated with local caches 107 and 113. Further, FIG. 1 shows a shared cache memory 115 that stores at least a portion of the information stored in each of the local caches 107 and 113. In some embodiments, the microprocessor 110 also has other logic not shown in FIG. 1, such as an integrated memory controller, an integrated graphic controller, and other logic in a computer system, such as I / O control. It can also include the logic that performs the function). In one embodiment, each microprocessor in a multiprocessor system or each processor core in a multicore processor, in at least one embodiment, comprises or is associated with a logic 119 for performing a secure enclave technique. ing. The logic includes circuits, software (embodied in tangible media), or both to allocate resources between multiple cores or processors more efficiently than some prior art implementations. Can be done.

For example, FIG. 2 shows a front side bus (FSB) computer system that can utilize one embodiment of the present invention. A local level 1 (L1) cache memory 220, wherein any of the processors 201, 205, 210, or 215 includes or is associated with processor cores 223, 227, 233, 237, 243, 247, 253, 257. You can access any of the information 225, 230, 235, 240, 245, 250, 255. Furthermore, any of the processors 201, 205, 210, or 215 has information from system memory 260 or from either shared level 2 (L2) caches 203, 207, 213, or 217 via chipset 265. Can be accessed. One or more of the processors shown in FIG. 2 may include, or may be associated with, logic 219 performing a secure enclave technique in at least one embodiment.

In addition to the FSB computer system shown in FIG. 2, other system configurations such as point-to-point (P2P) interconnect systems and ring interconnect systems can also be used in collaboration with various embodiments of the present invention. For example, the P2P system of FIG. 3 can include several processors, of which two processors 370 and 380 are exemplified. Processors 370 and 380 may include local memory controller hubs (MCH) 372,382 to connect with memories 32, 34, respectively. Processors 370 and 380 can use PtP interface circuits 378 and 388 to exchange data via point-to-point (PtP) interface 350. Processors 370 and 380 can each use point-to-point interface circuits 376, 394, 386, 398 to exchange data with the chipset 390 via the individual PtP interfaces 352 and 354. The chipset 390 can also exchange data with the high performance graphics circuit 338 via the high performance graphics interface 339. Embodiments of the present invention may be located within any processor having any number of processor cores, or may be located within 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). In addition, if a shared cache (not shown) is included in a processor outside both processors but is connected to both processors via a p2p interconnect and the processor is put into low power mode, then both or one of these processors It is also possible to configure the local cache information of the above to be stored in the shared cache. One or more processors or cores shown in FIG. 3 may include, or may be associated with, logic 319 that performs secure enclave technology in at least one embodiment.

One or more aspects of at least one embodiment can be implemented by representative data stored on a machine-readable medium representing various logics in the processor, and the machine can read the data. Manufacture the logic that implements the techniques described herein. Representations such as those known as "IP cores" are stored on tangible machine-readable media ("tapes") and are used by a variety of customers or manufacturers to load logic or processors into the actual manufacturing machine. It may be supplied to the equipment.

Therefore, methods and devices for directing microarchitecture memory area access have been described. The above description is intended as an example and not a limitation. Many other embodiments will also be apparent to those skilled in the art who have read and understood the above description. The scope of the present invention is therefore determined with reference to the appended claims and the full range of equivalents that the claims may include.

A secure enclave is an instruction set that provides an application with a secure place to execute code and store data within the context of an OS process. Applications that run in this environment are called enclaves. Enclave is performed from the Enclave Page Cache (EPC). The enclave page is loaded into the EPC by the OS. Each time the Enclave page is retrieved from the EPC, cryptographic protection can be used to protect the confidentiality of the Enclave and detect tampering when the Enclave is returned to the EPC. Within the EPC, enclave data is protected using access control mechanisms provided by the processor. Table 2-1 below provides a complete list of unprivileged enclave instructions.

These instructions are executed only in ring 3. At all other times, they produce # UD defects. Table 2-2 provides a list of privileged instructions.

The Enclave Page Cache (EPC) is where you can execute enclave code to access protected enclave data. The EPC is located within the physical address space of the platform, but access is only possible using the SE instruction. The EPC may include pages from many different enclaves and provides an access control mechanism that protects the integrity and confidentiality of the pages. The page cache maintains a coherence protocol similar to that used for the platform's coherent physical memory.

EPC can be instantiated in several ways. For example, it can be constructed from a dedicated SRAM on the processor package. Crypto Memory Aperture is known as a preferred implementation mechanism. By this mechanism, the EPC can be increased. The CMA will be described in detail below.

The Enclave Page Cache Map (EPCM) contains state information associated with each page in the EPC. This state provides information such as the enclave to which the page belongs, the state of the loaded page, and so on. When the page is retrieved from the EPC, the state information is also exported and protected using cryptographic means. When reloading the enclave page into the EPC, verify the state information.

FIG. 4 is a block diagram of a multi-core microprocessor 499 that can utilize at least one embodiment of the present invention. The microprocessor 499 can include a plurality of cores 400, 420. The core 400 can include a CR3 402, SMBR404, a page miss handler 408, a PMHE410, and a translation lookaside buffer 412. Core 420 can include CR3 422, SMBR424, page miss handler 428, PMHE430, and translation lookaside buffer 432. In some embodiments of the invention, microprocessor 499 includes a level 1 cache 440 shared between core 400 and core 420. The level 1 cache 440 can exchange data with the final level cache 445. The home agent 450 can connect to the final level cache 445 and attach to the crypto engine 452. The home agent 450 can assess the physical address space 488 of the crypto memory aperture 480 via the memory controller 454. The crypto memory aperture 480 includes an enclave page cache 482, an enclave page cache map 484, an auxiliary storage 486, and a portion 488 of the physical address space.

CMA is a mechanism that helps instantiate EPC, EPCM, and other SE-related structures. An aperture is an area of physical address space that is prepared for this purpose.

EPCs and EPCMs (and other implementation data structures) are mapped to certain locations within the aperture. Auxiliary storage is the actual data for these resources. When the EPC memory request is generated, the CMA remaps to the location of the auxiliary storage that contains the encrypted EPC data and acquires that data.

In general, most SEs are implemented in microcode. Hardware support is required at multiple locations, including CMA, out-of-package and in-core data movement control logic.

FIG. 5 is a possible implementation example of a secure enclave (SE) according to an embodiment of the present invention. The operating system and the VMM 542 can utilize the ELPG instruction 540 to load the enclave page of the enclave 532 into the enclave page cache 544. When the microprocessor is not running inside the enclave 532, the enclave page cache 544 is protected from software access by the SERR register 532. When running in an enclave, the microcode page table provides protection 548. A VMCS is associated with each VM. The VM510 is connected to the VMCS515. The VM520 is connected to the VMCS525. The VM530 is connected to the VMCS535. The SMM500 may be in a separate container and the processor state may be in a separate container.

FIG. 5 is a high-level schematic of an embodiment of a secure enclave implementation. In this implementation, the EPC is maintained in a separate container managed by microcode. The container is inaccessible if it is not running inside the enclave. Upon entering the enclave, control is transferred to the enclave code within the EPC contained in a separate container.

Any page defects or exceptions that occur while running in the enclave are reflected in the associated OS or VMM by microcode. Access control to the EPC is provided by the SE Range Register (SERR) when the machine is not running in the enclave. When the machine is running internally, the microcode provides page table level protection to prevent access to other EPC entries that do not belong to the running enclave.

One way to implement secure enclave is to use microcode functionality within some processors to provide instructions and protection. This feature would meet the security requirements of securely achieving the goals of Enclave.

The SERR register shown in FIG. 2-2 is implemented in the page miss handler PMH. Registers may be enabled and disabled independently for each logical processor.

An option in performance-enhancing implementations is to provide one or several bits to indicate that the translation lookaside buffer (TLB) entry is for an enclave or a particular enclave. If these bits are not provided, a TLB flush is required to prevent other code from accessing the enclave when exiting the enclave.

Compare the enclave bit with the enclave mode bit. The surplus bits provide the function of the enclave space id. Certain enclaves may be assigned an id. The id is compared to the id of the running enclave as part of the address check. TLB support is an option for performance improvement. If an entry is invalidated in the TLB by the removal of EPC data, a special microcoded shootdown mechanism is required. In one embodiment, the microcode contacts all other cores within the enclave trust boundary to ensure that this entry is not in any TLB. In other embodiments, the microcode may be provided with a means of ensuring that another processor has invalidated the TLB entry.

Special SAD and / or TAD entries are provided to avoid the DMA snoop and disable it for the EPC. These dedicated registers protect the EPC. This is set to the same value as SERR.

In one embodiment, the microcode can utilize secure access to random numbers to guarantee a secure key for each enclave's secure enclave.

The enclave may be protected from tampering. The details of the mechanism used for tamper protection will vary depending on the implementation example. This prevents further execution on the thread that detected the tampering when the enclave is tampered with. In order to make the user understand the state of the enclave, a proof mechanism for proving the built enclave is provided. This includes an EREPORT instruction that presents information about the enclave content.

The concept of architecture enclave was developed to simplify the microcode code required for enclave design. This type of enclave is given special access privileges based on the original code for the enclave.

The enclave state in the power cycle depends on the software policy. The data in the CMA is lost during a power outage. If it is desirable to store the enclave, the software can ensure that the enclave data is not lost during the power cycle. The data resident in the EPC can be flushed to memory if the software wants to keep the enclave alive during the S3 power state. The software can also choose to require the application to remove all enclaves in the event of a power loss.

The enclave is protected according to its location. Data outside the CPU package is protected using encryption and integrity checks. For code and data in the enclave page cache, the page is protected using access control mechanisms.

FIG. 6 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. FIG. 6 shows a microprocessor 600 with multiple processor cores 600, 605, 610, 615, and cache 620. Enclave data 635 can be encrypted. The crypto memory aperture data 630 is used to protect the enclave data 635.

Enclave pages that reside in system memory are protected using encryption and integrity. When loading a page into the EPC, the page is copied to the EPC, decrypted, and checked for the integrity of the page. FIG. 6 shows this part of the data.

The enclave page resident in the EPC is stored in the system memory and then encrypted by using the enclave key. Authentication information is also stored when the page is stored. The enclave data in the EPC is unencrypted and protected by an access control mechanism. The processor protects this data so that only the enclave that owns the data can access it.

When the enclave page resident in the EPC is forcibly moved from the cache to the main memory outside the CPU package, it is protected by CMA encryption. The CMA encrypts this data to ensure the confidentiality of the data. EPC integrity is provided by range registers that prevent reading and writing to the EPC.

FIG. 7 shows an example of a control structure that accesses a part of the enclave page cache that can be implemented in one embodiment of the present invention. Each page of the enclave page cache 720 may have corresponding metadata in the enclave page cache map 710. In the metadata shown in FIG. 7, if the secure enclave containing the set of linear addresses 700 matches the linear address stored in the enclave page cache map 710, the data stored in the enclave page cache 720. Can be accessed.

FIG. 7 shows the arrangement and usage of EPC and EPCM. The EPC is divided into 4k pages. Each enclave may have several pages resident in the EPC. Some EPCM entries on each page of the EPC provide the meta information needed to ensure security. The details of the EPCM are specific to the examples.

If the application wants to load the enclave, it calls the OS system routines. The OS tries to allocate several pages in the EPC. If there is no vacant space, the OS will select and remove the Victim Enclave. The OS evicts the pages of the Victim Enclave using the EWBINVPG instruction for each page. When the OS completes the forced removal, it uses the ECREATE command to add a secure enclave control structure (SECS) to the enclave. After generating the SECS, the OS adds the page to the enclave as required by the application by using the EADDPRE instruction.

To add a data page to the enclave, the OS first adds the SMAP page to the enclave using the EADDSMAP instruction. The OS may allocate multiple SMAP pages, depending on the size and placement of the enclave. When all the enclave pages are added to the enclave, the OS executes the EIINT instruction to execute the enclave. The parameter to the EINIT instruction is a permit indicating that the enclave is authorized to run on its machine. A permit must be generated when the application is loaded. Upon successful completion of EINIT, the application can execute the EENTER instruction to enter the enclave.

Once the enclave has been built and indicated that it is ready to run, the application may need to add or remove physical memory from the enclave. Enclave has instructions to add more memory to help with this. When adding memory to the enclave, the memory is assigned to the exact linear address in the enclave. The OS copies this memory page to the EPC indicating the linear address. Execute the EADDPOST instruction to add this memory to the enclave enclave. If the SMAP node is not resident in the EPC, load it first.

After copying the memory to the enclave, the software may accept the page and then be able to access it internally. The enclave accepts the data by executing the EACCEPT instruction. This instruction can only be executed by the software in the enclave.

In some cases, the software may want to modify the characteristics of the enclave memory. For that, it is necessary to update SMAP. For example, consider the case where software attempts to generate another thread entry point, the TCS, in an enclave. In this case, the enclave requires the OS to use the EMODIFY instruction to change the SMAP characteristics of the page. After the properties have changed, the enclave software executes the EACCEPT instruction to allow the page to be used.

Memory pages can also be removed from the enclave. If the enclave is ready to remove the page, it sends a request to the OS. The OS executes the EREMOVE instruction to remove the page from SMAP. The EREMOVE instruction also invalidates the EPC entry.

One way to ensure the integrity of the enclave environment is to perform access checks several times. Among the various security characteristics implemented, the code is a linear address with different enclaves by accurately positioning the data in the EPC so that the data does not leak between enclaves and the reference address is not corrupted. There is something to prevent it from being moved to.

Access protection requirements can be implemented using ranger registers and microcode-managed shadow page tables. In another embodiment, the page miss handler hardware can be modified to implement the same access control requirements to avoid shadow page table overhead.

The EPC is a logical processor only if the LP is running in microcode mode, or if the LP is running in an enclave and the linear address being accessed belongs to the linear address range covered by that enclave. It is accessible by LP). In other words, only microcode access or enclave access is allowed to go to the EPC range. All other access to the EPC range is considered illegal.

Enclave access may be resolved for a physical address that belongs to the EPC. Access may be suspended if the access is outside the EPC, but the linear address indicates that the address is inside the enclave. Any defects or instructions to the OS will be reported.

Access to the address in the enclave can be located in the EPC for successful access. Checking for the presence of an entry in the EPC is usually done by checking the EPCM and verifying the valid bits. Each EPC page is dedicated to a particular enclave. References to that EPC entry are only possible by the enclave that owns the EPC page. This can be checked by verifying that the referenced page matches the SECS of the running enclave.

Each EPC page represents a specific linear address page for the enclave. The requested linear address may match the linear address of the page in the EPC. For example, the EPCM entry stores the linear address where the enclave page is introduced into the EPC. If enclave access is resolved for an EPC page, the linear address that introduces the page matches the linear address of the current request.

The enclave's linear address mapping must not be corrupted. If the linear address page table is corrupted, access is illegal. This prevents an attacker from bringing code and data into or near the enclave.

When the OS / VMM adds a page to the enclave after initialization, the EADDPOST instruction sets the "pending" bit on the ECM M of that page. The pending bit continues to survive the subsequent EPC writeback and forced removal (using SEC_INFO). The enclave can issue an EACCEPT to clear the pending bits. If the enclave access is resolved for an EPC page with a pending bit set, the LP issues an EF_PENDING defect to the OS / VMM.

When the OS / VMM loads an EPC with a relay-protected enclave page, the FCR (Fresh Check Requested) bit is set in the EPCM entry for that page. The OS / VMM can clear this bit by executing the EUPSMAP instruction for the EPC page and clearing this bit. Continued enclave access is only allowed if the FCR bit on this page is not set. Otherwise, the LP sends an EF_FRESH_CHK defect to the OS / VMM.

Each ECCM entry contains a "dirty" bit that indicates whether the enclave is allowed to write to that page. Writing to an enclave page of an enclave is only allowed if the dirty bit for that page in the EPC M is set. Otherwise, LP will issue EF_EWRITE to OS / VMM. The OS / VMM can set the dirty bit by executing the EUPSMAP instruction for the page.

Whenever a logical processor is running in an enclave, the SECS page for that enclave can be in the EPC. However, the SE security model does not allow enclaves to have direct memory access to their SECS (although enclaves can read their enclave keys on the assumption that they are completely security threatening). If the enclave access is resolved for an EPC page that holds SECS for that enclave, the OS / VMM will be notified via EF_ATTRIB_SECS failure. Enclave is not allowed to modify pages that have a TSC attribute set. When the Enclave attempts to modify the TCS loaded in the EPC, the OS / VMM is notified via EF_ATTRIB_TCS failure. In the size fields in the table below, 4-byte fields in both 4:32 and 64-bit modes, 8-byte fields in both 8:32 and 64-bit modes, and 8 (4): 8-byte fields in both modes ( The upper 4 bytes are ignored in 32-bit mode) values and indicators are available.

Note: Some fields have names that start with a lowercase "o" (eg oLSP). These fields are pointers, but in the enclave they are represented as offsets to the base of the enclave. This notation allows the measurement on the enclave page to be independent of the position where the enclave was created.

Note: The fields are (yet) not listed in any particular order. Some fields may be moved to different memory pages within each data structure, which allows, for example, different safeguards.

スレッド状態は５つの値のうちいずれかをとることができる。

A thread control structure (TCS) is associated with each thread. TCS includes:

The thread state can take any of five values.

<State save area offset (oSSA)>
The state save area offset (oSSA) points to a stack of state save frames used to save processor state to interrupts or exceptions that occur during execution in the enclave. The next state save area (NSSA) is utilized by the interrupt microcode to determine where to save the processor state in interrupts or exceptions that occur during execution in the enclave. This is an index into the frame array addressed by oSSA. The save area (CSSA) count identifies the number of SSA frames available for this TCS. If an interrupt or exception occurs and no more SSA frames are available (NSSA> = CSSA), an interrupt or exception can still occur and the processor state is cleared, but TCS is disabled (INVALID). Displayed as being.

If an interrupt occurs during execution in the enclave, the machine state is saved in the TCS :: SSA (state save area). This area includes:

TCS :: SSA is not paged out when an interrupt occurs. EENTER checks that the SSA is in the EPC and caches the physical address. If the page is forcibly moved, the processor running EWBINVPG uses the SSA to exit the enclave with the processor currently running the thread and report a page defect.

FIG. 8 shows the suturing method for all data structures. To avoid complication, the structure of each thread is not shown. Untrusted Stacks and their associated pointers have also been omitted. FIG. 8 shows an example of a thread control structure according to an embodiment of the present invention, and shows suturing between save state regions. The state save area pointer 800 points to the save area 0 820. The current state save area 805 points to the save area 1 824. The next state save area 810 points to the next save area 828. The number of save state areas provides a reference to the number of save state areas available.

ＳＥＣ＿ＩＮＦＯフラグおよびＥＰＣフラグは、ページの種類を示すビットを含んでいる。

ＳＥＣ＿ＩＮＦＯフラグは、エンクレーブページの状態を記述・説明するビットセットである。

Page information (PAGE_INFO) is an architectural data structure used as a parameter to the EPC-management instruction.

The SEC_INFO flag and the EPC flag include bits indicating the page type.

The SEC_INFO flag is a bit set that describes and describes the state of the enclave page.

The security information (SEC_INFO) data structure holds the cryptographic metadata needed for counterfeit protection.

A certificate (CERT) is a certificate structure provided with an architecture enclave and is passed to EMKPERMIT. This structure is 4096 bytes and may be page-aligned.

The ERPORT structure is the output of the EREPORT instruction.

The measured value (MEASUREMENTS) is an output parameter of the ERDMR instruction, and includes the measured value register value (Measurement Register values) of the enclave taken from the specified SECS.

The key request (KEY_REQUEST) is an input parameter to the EGETKEY instruction and is used to select the appropriate key and additional parameters needed to derive that key.

ＥＰＣＭフラグとは、エンクレーブページの状態を記述するビットのセットである。

By using this structure in key derivation, a key is generated based on the security version of the enclave and the SE TCB of the enclave. For more information on the TCB security version structure, see Platform TCB Return Specification.

The ECCM flag is a set of bits that describe the state of the enclave page.

The Enclave Page Cache Map (EPCM) is a secure structure that the processor uses to track the contents of the page cache. The EPCM holds exactly one entry for each page currently loaded in the EPC.

Attestation is the process of showing that one piece of software is built on a platform, especially to remote entities. In the case of a secure enclave, the remote platform runs on a legitimate platform protected within the enclave before the software is validated in terms of confidentiality and data protection. It is a mechanism built by a remote platform. The proof process consists of three stages: measurement, storage, and reporting.

There are two periods of enclave measurement, pre-enclave construction and post-enclave construction. The enclave instruction serves to measure the constructed enclave. Once the enclave is built, the software within the enclave is responsible for the measurements.

FIG. 9 shows one step of a software certification process called quartering, which can be seen in one embodiment of the present invention. In one embodiment, the signature process 910 applies the signature key 915 to the concatenated data from the measured value registers 901, 902, 903, 904. The result of signature processing 910 is quote 920.

The process of reporting cryptographically binds measurements is done when generating an enclave on the platform. This mechanism is often referred to as "quarting" because this type of functionality is sometimes available on the platform as a TPM command. The values in the measurement register (MR) are concatenated and then signed with an asymmetric key. Opponents simply need to verify the signature with a quote structure to justify this quote.

FIG. 10 shows each step for generating a quote from the measured value register set 1000 in one embodiment of the present invention. The local report 1005 can be generated by accessing the measurement value register 1000 with a symmetric authentication key. The quartering enclave 1025 may include software that transforms the local report 1005 into an anonymous quote 1010 or a regular quote 1020.

Due to the nature of calculations related to asymmetric keys and the desire to reduce the number of instructions in the enclave leaf, instructions that cause asymmetric signatures are not included. Our method, shown in the figure below, is software that generates "reports" based on symmetric key authentication keys and protects the "reports" based on these symmetric keys using enclaves. Is used to convert to an asymmetric signature "quote". The Quoting Enclave itself is a special purpose enclave known as a certified enclave, as the Quoting Enclave itself must first be authenticated before it has access to the platform certification key.

Each enclave provides two 256-bit wide measurement registers (MR_EADD & MR_POLICY) and two leathered registers. These measurement value registers are included in the SECS of the enclave.

FIG. 11 shows an EADD process for updating the measurement value register MR_EADD1100 according to an embodiment of the present invention. The expansion process 1115 can use the current value of MR_EADD1100, page data 1105, and page metadata 1110 as inputs. The output of the extended processing is MR_EADD'1120, which is the next value stored in MR_EADD1100.

Since MR_EADD was constructed by using the EADD instruction before the EIIND instruction was called, it includes the set measurement value of the enclave. Since it is written by microcode, the enclave code needs to be placed on a readable SECS page. Each time the EADD is called, it calculates SHA256 into the page data and the security metadata associated with that page (ie, this is the relative address (that is, to the base address of the enclave) of the page and the SEC_INFO flag of the page). , This value is extended to MR_EADD1100. "Extended" means new MR value = hash (old MR value || input value).

MR_POLICY contains the value of the policy used when authenticating the policy that allows the activation of the enclave. This value was taken from the enclave permit placed in the SECS at startup and copied as if the EIINT instruction had been successfully completed. Since MR_POLICY is written only by the macro code, it needs to be placed on the SECS page that can only be read from the enclave code.

FIG. 12 shows an EREPORT instruction that produces a report according to an embodiment of the present invention. Key ID 1200, owner epoch 1205, package fuse key 1210, and fixed string MAC key 1215 may be entered in the derivation command 1220. The output of the derivation 1220 can input the CMAC 1225 along with the current values of the TCB version 1232, ISV version 1234, function 1236, flag 1238, user data 1240, and measurement register 1242. The output of CMAC1225 can be stored in MAC1244. The output of the EREPORT instruction can include key identifier 1230, TCB version 1232, ISV version 1234, function 1236, flag 1238, user data 1240, measurement register 1242, and MAC 1244.

The EREPORT instruction generates an intermediate key for performing symmetric key-based GMAC on measurement registers, user data, and additional contextual information (eg, enclave functions and flags).

In addition to the measurement register, the user can provide a 256-bit wide data block for inclusion in the report. The user wants to prove many application-specific values (eg, challenger NONCE and / or application creation key). These values are reduced to a single hash and can be included in the report.

表５−２：ＥＲＥＰＯＲＴ構造 To prevent key wear, EREPORT is repeatedly called to generate a 128-bit random number (known as the reportKeyID) at each power cycle of the processor and store it in an internal location. This value is incremented after 2∧32AES processing using this value. In one embodiment, each call to the EREPORT instruction increments this value by one.

Table 5-2: EREPORT structure

表５−４：フラグ The flag field in the report structure is useful for ascertaining whether the challenger can trust the enclave, so it can be used to determine some state information about the enclave or when calling the EREPORT instruction. ..

Table 5-4: Flags

In one embodiment, the architecture enclave with the appropriate feature set is allowed by the architecture to obtain the key used in CMAC processing with the EGETKEY command, so the report is generated on the currently running hardware. It can be verified that it was done. This feature is limited to the Quartering Architecture Enclave.

An ERDMR (measurement read) instruction is provided to obtain an enclave measurement when running outside the enclave. This instruction takes a pointer to a valid SECS page and a pointer to an address that delivers measurements. The measured values are delivered in the form of a MEASUREMENT structure. The MEASUREMENT structure is not protected by cryptography (cryptographic protection).

Enclave pages are cryptographically protected when they are not in the enclave page cache. There are three levels of cryptographic protection: security, counterfeit protection, and replay protection. In one embodiment, the application can select the protection level for each enclave page independently of the protection level selected for other pages in the same enclave. Enclave implementation allows applications to choose from a combination of counterfeit protection, counterfeit protection, and rehabilitation protection, security and counterfeit protection, and security, counterfeit protection, and rehabilitation protection. For security and counterfeit protection on enclave pages, any of several authenticated cipher modes such as GCM (Galois Counter Mode) can be used with appropriate cryptography such as AES. However, regeneration protection requires more sophisticated solutions.

FIG. 13 shows a counterfeit protection and regeneration protection mechanism that can be seen in one embodiment of the present invention. Counterfeit protection prevents an attacker from replacing the encrypted data that the program did not generate with another value. Replay protection prevents an attacker from replacing the value of encrypted data that is not currently up-to-date generated by the program. Node version number 1300 can enter IV1310 and then the GMAC1325 algorithm. The version number of child 1305 can send data 1315 to the GMAC 1325 algorithm. The GMAC 1325 algorithm combines keys 1320, IV1310, and data 1315 to generate MAC 1330.

Playback protection ensures that all content in the enclave that the logical processor sees at any given time belongs to a single snapshot of the uncorrupted enclave. Regeneration protection mechanisms therefore need to define the concept of an enclave version and provide a mechanism to determine if a counterfeit protected enclave page belongs to that version of the enclave. For this purpose, the replay protection mechanism utilizes a message authentication algorithm such as GMAC to link the content of each counterfeit protected enclave page to the page version number. In the case of GMAC, this version is available as part of the initialization vector (IV) shown in FIG.

FIG. 14 shows an example of a part of the MAC tree structure of the relay protection mechanism found in one embodiment of the present invention. Leaf node 1425 may include version information for individual MAC content pages 1430. Each leaf node, such as 1420, contains an individual MAC content page (not shown). Each internal node 1410, 1415 may include version information of the linked child group. Route 1400 is the highest node in the tree data structure.

To extend versioning for all enclaves, the replay protection mechanism maintains a version tree. The leaf node contains the individual play-protected page versions of the enclave instance. Since each internal node provides a version of each group of children, it logically holds the version information of the page they represent. FIG. 14 illustrates this concept.

In one embodiment, the tree structure is chosen to reduce the number of data that needs to be processed into O (log n) pages. By using the version tree instead of the hash tree, it is possible to forcibly remove the page from the EPC without updating the tree.

Playback protection requires counterfeit protection because the version of each page must be cryptographically tied to its own content. Therefore, counterfeit protection is essential in the SE architecture. Moreover, implementing SE from the beginning can further limit the list of supported protection combinations.

The OS / VMM creates an enclave by executing the ECREATE instruction. During enclave generation, the range of linear addresses protected by the enclave is identified. This range of linear addresses is known as the Enclave Linear Space (ELS) range.

Once the enclave is generated, individual pages belonging to the ELS range are added to the enclave using the EADDPRE instruction. The EADDPRE instruction moves each of the added pages to the enclave protected area by moving these pages into the enclave page cache. If any of these pages are located outside the EPC using EWBINVPG, the logical processor provides cryptographic protection to these pages.

Cryptographic protection is provided by associating cryptographic metadata with each enclave page. The metadata is used by various processor instructions to decrypt the contents of the enclave page and verify the reliability / freshness of each enclave page according to the uCode flow. The SE architecture provides several such instructions to update, manage, and validate cryptographic metadata.

Each enclave page is associated with a security information SEC_INFO data structure. The purpose of the SEC_INFO data structure is to retain cryptographic metadata that needs to be decrypted and validated. The various fields of the SEC_INFO structure are:

Security information flags (SEC_INFO. Flags) describe the page type, encryption and access protection of protected pages.

A security map (SMAP) is a data structure used to store cryptographic metadata needed to verify the freshness of an enclave page (ie, replay protection). The security map represents a tree of full versions of a particular snapshot of the enclave. Each node in the security map holds a version of 256 child nodes (enclave pages in the case of leaf nodes). Further metadata about the security node is included within the SEC_INFO of a particular SMAP node.

In one embodiment, the security map tree may be two levels deeper (security map depth relates to the size of the enclave supported by the SE architecture. In Gen1, the SE architecture supports a maximum enclave size of 32 GB. ), Accessed using the enclave offset of the enclave page in the enclave. The SMAP route is included in the SECS and holds only 128 child node versions. The bits of the enclave offset are used to select the appropriate child and are used to index into SMAP. In gen1, 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 (enclave size-1) and can be calculated during ECREATE.

Generally, at a depth of l> 1, bits N- (l) x 8 to N- (l + 1) x 8 + 1 are used to select the appropriate child of the next level.

Note: Security maps are logical data structures, not architectures. The logical processor is not even aware of the location in the linear address space where SMAP is located. The system software is responsible for maintaining and walking the security map. Each individual node of the security map has a structure defined by the architecture, but the architecture does not specify how the security map is maintained in memory. However, each node in the security map has a well-defined logical position in the security map, and when the node moves around in the map, various processor instructions on the security map attack it. Note that it is interpreted as a scenario.

The root security node is included in the SECS and contains 128 child version information. A non-root security node is a protected page and is an associated SEC_INFO (and its associated SEC_INFO). The protected page contains version information for 256 children.

SEC_INFO includes the location of SMAP within SMAP. The position of SMAP is determined by the linear / enclave offset and page types SMAP_LEVEL_1 and SMAP_LEVEL_2.

In order to add a play-protected enclave page, the SMAP parent must be generated and resident in the EPC with the FCR bit cleared. To verify the integrity of the enclave page, the logical processor utilizes IV_P and key_id in the SEC_INFO structure to generate the key. This key is used to calculate the MAC for the SEC_INFO structure and the flags in the page content. The calculated MAC is compared with the MAC provided in the SEC_INFO structure. If the MACs match, this page can be considered to have passed the consistency check.

The logical processor verifies the integrity of the page when loading the page into the EPC using the ELPG instruction. As part of this instruction, the logical processor notes down IV_P from the SEC_INF structure used to validate the page.

To verify the freshness of the enclave page, the logical processor verifies that the enclave page and its smap parent are loaded into the EPC and the smap parent is fresh. Then, the version of the page is compared with the version stored in the parent of smap. If these two versions match, the processor will generate a new version of this page to update the parent version of smap and the version of the enclave page. Finally, display the enclave page as fresh.

Note: A new version generation can make the page modifiable. This simplifies both architecture and implementation.

To remove the enclave page, the logical processor verifies that the enclave page and its smap parent are loaded into the EPC and both are fresh. Then, the version of the parent page of smap is set to 0 to indicate that the EPC slot of the enclave page is available.

The Enclave Page Cache (EPC) is a secure storage used by the CPU to temporarily store enclave pages that are not cryptographically protected by SE cryptographic protection.

The following requirements are specified in the EPC. Access to enclave memory pages loaded into an EPC belonging to a non-debug enclave can be protected from modification by software entities outside the enclave. An attacker cannot read the plaintext data belonging to the non-debugging enclave loaded in the EPC by a direct hardware attack. In addition, an attacker cannot modify the data of the EPC belonging to the non-debug enclave by a direct hardware attack. The CPU of the system can coherently and securely access the data loaded in the EPC.

There are several mechanisms for implementing EPC. The EPC can be mounted on top of on-die SRAM or eDRAM. EPC can also be constructed by dynamically isolating the CPU's final level cache method. In this implementation example, the EPC can be protected from unauthorized access from outside the package. On the other hand, other packages in the system can coherently and securely access the EPC.

Another mechanism for implementing EPC is the Crypto Memory Aperture. Crypto Memory Aperture provides a cost-effective mechanism for using platform DRAM to generate cryptographically protected volatile storage. The CMA utilizes one or more strategically placed cryptographic units within a CPU uncore to provide the various levels of protection required by customer technology. Various uncore agents are modified to recognize memory access to the CMA and route these 25 accesses to crypto controllers located within the uncore. The crypto controller generates one or more memory accesses to the platform DRAM to obtain the ciphertext, depending on the desired level of protection. Then, the ciphertext is processed to obtain the plaintext and satisfy the original CMA memory request. CMA is fully integrated with the Intel QuickPath Interconnect (QPI) protocol and will be scaled to a multi-package platform with security enhancements to the QPI protocol. In the configuration of the multi-package platform 30, the CMA utilizes a link-level security (Link-Sec) engine in the externally facing QPI link layer to protect memory transfers between Intel CPUs. To do.

SECS is referred to as active when it is currently loaded on the EPC. As will be described later in this document, the OS / VMM plays a role of managing what is loaded in the EPC. However, while loading the enclave page into the EPC, the OS / VMM informs the CPU of the location of the SECS of the page unless the target page itself is the SECS. If the loaded page is not SECS, the CPU requests that the SECS corresponding to that page be placed in the EPC. At any time before loading an enclave page, the OS / VMM MAY load the EPC with the enclave's SECS.

The CPU does not impose a limit on the number of times the SECS can be loaded into the EPC, but it is often the case that the OS / VMM loads multiple copies of the SECS into the enclave page cache. Very Hard to think. However, if multiple copies of the same SECS are loaded into the EPC, each of these copies will be considered as a separate active SECS instance, and the enclave pages loaded into the EPC belonging to different instances of the active SECS will be hardened. It is regarded as belonging to different enclaves depending on the wear.

The OS / VMM regards the EPC as a continuous block of physical memory in the system address space (10). However, in order to reduce internal storage and enable fast indexing, the CPU associates a slot identifier (SID) with each EPC page. The physical address of the EPC page and the corresponding slot identifier are related to each other as follows.
sid = (page_pa-epc_base_pa) >> 12
page_pa = pc_base_p | (sid << 12)

The hardware uses a special slot called 0xFF to indicate an invalid slot. The EPC slot identifier is utilized by both uCode and PMH to track information about the enclave page.

Every enclave page loaded into the EPC has a well-defined system physical address. Since there is a one-to-one mapping relationship between the physical address belonging to the EPC and the EPC slot identifier, it can be said that each page loaded in the EPC has its own EPC slot identifier or EPC_SID.

In addition, all enclave pages loaded into the EPC, with the exception of SECS pages, are associated with an active SECS instance. Recall that the active SECS instance is just a SECS page loaded into the EPC. As a result, the active SECS page also has its own EPC_SID. The EPC_SID of the SECS page to which the non-SECS enclave page belongs is referred to as the SECS_SID of the non-SECS 25 page. For each page loaded into the EPC, the hardware keeps a record of SECS_SID. The SECS_SID of the SECS page loaded into the EPC is defined as 0xFF (or invalid SID).

The ECCM is a secure structure used by the processor to track the contents of the page cache. The 30 EPCM holds exactly one entry for each page currently loaded in the EPC. In the page it represents, each EPCM entry tracks information such as the enclave to which the page belongs, the linear address by which the page is moved to the enclave page cache, and the page version. The EPCM structure is utilized by the CPU in the address translation flow to perform access control on the enclave page loaded in the EPC. The EPC M entry is managed by (x) uCode as part of various instruction flows.

In one embodiment of the invention, the enclave page cache (EPC) may be dynamically allocated and deallocated. In one embodiment, software such as an operating system allocates memory pages such as EPC and deallocates memory of EPC. In one embodiment, the operating system can also allocate any page of the enclave within the EPC. In some embodiments, the EPC may occupy all available locations in memory. In one embodiment, one difference between the dynamic EPC and the fixed EPC is that the dynamic EPC allows the addition and removal of pages of memory. In one embodiment, the logic of a software driver or the like allocates a memory area as an EPC or cancels the memory allocation of the EPC. In one embodiment, preboot processing checks the memory available for storing metadata for each page of memory, the software declares the page EPC or non-EPC, and the hardware logic tracks the attributes of each page.・ Enforcement may be performed.

In one embodiment, hardware logic may control access to memory utilized as an EPC by a translation lookaside buffer (TLB) and a page miss handler (PMH). In one embodiment, the TLB may be flushed when the secure enclave exits the EPC when there is a match in the TLB (known as a TLB hit). In one embodiment, if the search address does not match the TLB (known as a TLB miss), further lookups may be used to retrieve data from the Enclave Page Cache Map (EPCM) in multiple memory references. it can. In one embodiment, the PMH can perform an EPCM lookup. In another embodiment, the PMH range register is checked to control control over continuous physical addresses and EPCs. The operating system does not allow direct memory access (DMA) as access to EPC pages. If the memory return page is displayed as an enclave page, compare the page's secure enclave control structure identifier (SECSID) with the currently running enclave to ensure that access is secure. You can. If the SECSID on the return page does not match that of the currently running enclave, PMH may issue a stop message. If the memory return page is not displayed as an enclave page, or if the memory return page is displayed as an enclave page and the SECSID of that page matches that of the running enclave, then the PMH is a page. The conversion may be loaded into the TLB. In one embodiment, cache tags can be used to identify enclave lines from other lines in a write-back cycle. However, in at least one embodiment, the cache tag is not utilized if the logic determines that a memory request of that type will access the EPCM during the write-back cycle.

In one embodiment of the invention, the software, BIOS, can allocate memory before the operating system boots and creates an enclave page. In one embodiment, the software can generate an EPC through a series of steps in the BIOS. The BIOS can reserve a memory for storing metadata and set a range register for each processor. The BIOS can input the base address and memory size. The system configuration is checked by a process called MCHECK, and the settings are suitable for the purpose of protecting all registers in all packages and all cores from access outside the enclave. MCHECK locks the registers until the system is reset. In another embodiment, the software can add pages to the EPC by an instruction known as EPCADD that can declare a portion of memory as part of the EPC. The EPCADD sequence can take a memory address as input and output a message indicating success or failure. If the EPCADD outputs a message indicating success, the EPCADD may output an EPCADD. The E-bit can be set and the page corresponding to that physical address will be flushed from all TLBs in the system. In one embodiment of the invention, the EPCADD returns an error code of 01 in RAX to indicate that the page with the input address is already an EPC page, returns an error code of 02, and the input address is out of range. It can be shown that there is. Memory pages that the EPCADD declares to be part of the EPC may require EPC semantics to access the data. In this embodiment of the invention, the software removes pages from the EPC of the instruction known as EWBINVG to keep the encrypted data available while continuing cryptographic and integrity protection. be able to. Data in this format can be stored in the normal memory of the hard disk drive. In yet another embodiment, instruction software known as EPCREMOVE can remove pages within the EPC to make encrypted data unusable. The hardware that performs EPCREMOVE clears the page and the EPC M part. EPCREMOVE can be performed without first executing EWBINVPG. In one embodiment, the EPCREMOVE sequence can remove pages from the EPC based on the memory address. In one embodiment of the invention, the EPCREMOVE instruction contains an error code of 01 in the RAX, indicating that the page being removed is part of a secure enclave control structure (SECS) and cannot be removed. The error code of 02 indicates that the page to be removed is not an EPC page. The global TLB shot down of a page of memory may result from an EPCR EMOVE in one embodiment of the invention, and the memory previously occupied by the page may be available for general purpose software access.

PMH prevents access to protected areas of memory space. Depending on the architecture, this may be as simple as checking the physical address of access to the EPC. Further PMH support may be used to improve SE performance or allow alternative implementations. The SE architecture utilizes a page miss handler (PMH) to prevent unauthorized access to the enclave page for the enclave page cache. PMH detects various events and reports these events to microcode. Microcode may report the event to the OS / VMM. The OS / VMM can then execute the appropriate instructions to repair the defect.

When creating an enclave using the ECREATE instruction, a linear address range is specified for that enclave. This range is referred to as the "linear address range" of the enclave. All memory pages belonging to the enclave's linear address range are under enclave protection and can be considered to have an SEC_INFO entry associated with them.

A memory page that belongs to a linear address range of an enclave is also called an "enclave page". Programs running inside the enclave are loaded into the enclave page cache and are only allowed access to the enclave page that is the owner of the page. The processor raises an exception class event otherwise. The OS / VMM is responsible for loading the Enclave page into the EPC as needed.

When a logical processor is performing an enclave and generates memory access to its enclave page, this memory access is referred to as "enclave access". A dress check may be done to ensure that it is being accessed by the correct entity.

In one embodiment, the PMH provides access control functionality to protect the EPC when the program is not running in the enclave. The range registers enabled for each logical processor limit access to the EPC when the processor is not executing enclave code. This range register is disabled when the processor starts executing enclave code. In that place, the processor puts a special page table in place. These page tables are controlled by the processor to allow access only to EPC pages owned by the enclave. Processors and microcode utilize these two mechanisms to limit access to the EPC.

In some embodiments, a number of axes may be coordinated, such as performance, mounting complexity, and cost of silicon. This chapter introduces three implementation examples to show developers some possible tuning examples. Table 8-1 below shows examples of these protections and the PMH support required.

As shown in the first line of Table 8-1, only one additional range register is required to provide the required access control protection. In this particular implementation, other protections are provided by the micro. Range registers may be enabled on a per logical processor basis. An example of basic implementation using this mechanism is shown in Fig. 2-2.

The PMH is modified to remove access to the CMA range (covered by the CPU's CMRR) from LPs that are not running in either microcode or enclave mode. In addition, LPs running in enclave mode are only allowed access to the CMA's EPC subrange.

FIG. 15 shows an embodiment of the present invention showing the implementation of a page defect error code map. When bit 5 1540 is set, bit 9, bit 8, bit 7, and bit 6 can be decoded together to determine the page defect error code. res bit 1512, I / D bit 1514, REVD bit 1516, U / S bit 1518, W / R bit 1520, P bit 1522.

If a page is not on the EPC, a "bad" is provided to the OS / VMM to inform it. Change the page defect error code map as shown in Table 8-2. This points to a new bit used to report bad conditions. If there is no EPC defect, bit 5 is set to zero, and bits 6 to 9 are also set to zero. If the defect is due to the EPC condition, bit 5 may be set and the software may decode bits 6 to 9 to clarify the EPC defect condition. More information on bad types can be found in the next section.

If bit 5 of the page failure error code is set, then bits 6-9 are interpreted as given (Table 8-2). This indicates the condition that caused this page defect. Some of the states indicate illegal conditions that would not be possible with normal processing, indicating OS / VMM management errors.

To protect the EPC from attacks, a mechanism can be used to invalidate the EPC addresses of all TLBs on the platform. This feature allows all cores to be notified of a particular page being disabled. Then wait until all processors report the completion of the shooting.

Each time the enclave exits (EEXIT), the TLB may not allow access to the enclave page that currently exists in the TLB. This is possible by clearing the TLB or by using additional bits to tag the enclave entry.

Another method is to use the enclave bit in the TLB when leaving the enclave to clear all enclave entries. Alternatively, some bits are used to identify a particular enclave. In this case, the enclave entry does not need to be forcibly removed. The enclave entry may be left in the tlb. If the address is sent to the tlb for lookup, these bits are added to the lookup. These bits are compared to the enclave id from the core that identifies the enclave. If the bits match, then the request comes from this enclave. If they do not match, the lookup does not hit this position because the request is not from this enclave.

Enclave certification provides a means of finding an authorization body (ie, the author / approver of this code) who has authorized the execution of the enclave code within the enclave. Enclave Certification also offers Enclave Microcode Flow, Flexible Seals & Reports, and a foundation that outsources the implementation of some new business models.

Some aspects of the secure enclave architecture may require complex and time consuming flows that are not well suited for implementation within microcoded instructions. The solution to this is to outsource these parts of the secure enclave architecture to microcode. Often, the entrusted code requires special access to sensitive processor or platform data. For example, the EPID signal is too long for a single instruction. Instead, a quartering enclave is used to generate an EPID-signed quote by allowing special access to the EPID private key. Enclave authentication allows Intel to identify additional features granted to a special enclave, such as access to an EPID key, only by quartering enclave. The enclave provided by Intel has additional functionality and implements the core enclave functionality, but is referred to as the architecture enclave.

Enclave Seal Storage provides enclave software with the ability to encrypt data to certain attributes of the enclave (eg, load time measurements). The Enclave Proof Framework allows Enclave to provide evidence of measuring Enclave to external entities. In many situations, a seal of data or proof to the source of the enclave is preferable to the exact software hash of the enclave.

In one embodiment, once the signature in the authenticated enclave is confirmed, the public part of the key used to sign the enclave becomes available for the seal & certification mechanism, which allows the distributor to measure the enclave. You will be able to choose between strong value-based protection and more flexible protection based on the source of the enclave code.

Enclave certification is divided into two parts. Each enclave comes with an enclave license that has a signature chain that allows Intel to follow its roots back to Intel. An enclave license indicates the source / responsible entity of the enclave, the special features required by the enclave, and the additional information needed to identify the special business model / arrangement that enables the enclave. The license may be for a special enclave, which indicates a measurement of this enclave, or a key, which will later be able to sign the enclave as needed. ..

For example, consider the case where A purchases a license to manufacture an enclave for use in A's video player. To this end, Intel will generate licenses for the root key of Distributor A's video player and Intel for features that Distributor A is authorized to use in the video player enclave. Distributor A then uses the video player's root key to sign an individual license file for each modified version of the video player to be released. This will cause the Enclave license chain to include multiple intermediate licenses.

Signed license chains are not ideal for evaluation during the enclave launch process, so instead they are single instructions, called permits. Incorporate into digestible structure). The permit is symmetrically authenticated using the CMAC algorithm and interpreted during enclave initialization (EINIT).

Most of the licensed part is copied to the permit and has a similar structure. The license ID is a 64-bit number for identifying business arrangements. The license type identifies the platform to which the license applies. The bulk license allows you to launch this enclave on a platform that supports secure enclaves. With a per-platform license, the platform first contacts the indicated licensing authority and requests permission to launch Enclave. Once authorized, there is no need to contact the licensing authority, which allows the licensing authority to track the number of platforms on which this enclave is located for billing purposes. ISVs licensed for this enclave may also build a security version number for this version of the enclave. This makes the data sealed by this version available for future versions rather than previous versions. The flag field indicates a flag for the enclave that can be set to apply this permit. The functional mask is a bitmask of special functionality that may be allowed for this enclave. The parent key hash is the hash of the public key that signed the license for this enclave and hashed it with the public key that signed the key. The entity hash is the expected hash of the entity to which this license applies. In the case of an enclave, this is a properly constructed enclave MR. It is a value of EADD. For license keys, this is a hash of the public key.

In the license, the public key used to sign the license is included in the license itself. The permit is MACd using the CPU key. Legitimate cpuMAC indicates that the EMKPERMIT instruction has authenticated this permit and the license chain has now been authenticated against Intel. If the license type is not bulk, the license MAC indicates that the architecture license enclave has contacted the appropriate licensing authority to confirm that the platform can launch the enclave.

Not all enclaves require a permit. Permits are optional during development and during the debugging phase of the software life cycle to facilitate enclave development. The following policies will be implemented by EIINT. Non-debug enclaves always require a permit to be launched. The debug enclave is launched without a permit. However, if the permit is not presented to EINIT, MR. Set all of the Policy, ISV Sec version, Permit See Version, and features to 0.

When the permit is used to launch the debug enclave, permit-> flag "debug" can be set, and only the functions permitted by the debug enclave can be set in the permit.

FIG. 16 shows an example of a process of generating a permit to launch an enclave according to an embodiment of the present invention. This process can have three stages: permit issuance 1600, additional license approval 1640, and initialization enclave 1680. At the permit issuance stage 1600, an ISV key permit 1615 can be generated by executing the EMKPERMIT instruction 1612 on the ISV key license 1610. An enclave permit 1625 with a MAC for the CPU only can be generated by issuing the EKPERMIT instruction 1612 to the enclave license 1620 and the ISV key permit 1615. In the further license approval 1640 stage, an enclave permit 1625 having a MAC for the CPU only, and a third-party enclave 1642 corresponding to the licensed information enter the license enclave 1644, and the license enclave 1644 is the MAC for the CPU. And generate a licensed enclave permit 1645. In the initialization enclave 1680 stage, the enclave SECS1682 and the enclave permit 1645 with the MAC and license for the CPU may be input to the EIINT1684 instruction. The output of EINIT1684m liter is ISV Enclave 1685.

To activate the enclave, a permit can be generated from the license shipped with the software and provided to the CPU to initiate the enclave. This process can be divided into three stages: permit issuance, further license approval, and enclave initialization. FIG. 16 shows the flow of this process.

A new instruction called EMKPERMIT is used to generate a permit from a license. EMKPERMIT generates a single permit from a single license, but can also be called consecutively to convert a chain of licenses into a single permit with a MAC using a permit key. it can. The next section details this.

Each license includes a "license type" that determines the further steps that can be taken to make the permit available. Per-platform licensing requires the cloud licensing authority to maintain the billing amount for the platform on which the enclave is located. Further steps are required for this type of license. That is, an architecture enclave, called a license enclave, negotiates with the cloud licensing authority and, when approved, uses the license key to provide additional MAC to the permit. Architecture enclaves, for example, are always bulk licenses, which means that no license key MAC is required to run them. They run on any platform that supports secure enclave.

A permit is implemented in the initialization of the enclave. If the permit is processed during initialization and the enclave measurements match those in the permit, the MAC is correct and the enclave is activated. EINIT looks at license types and only looks at licensed MACs for licenses that require further approval.

EMKPERMIT is a privileged instruction for the time required to verify the RSA signature on the license. This instruction takes a very simple signed certificate that validates and generates a permit from its contents. The license includes both the signature and the public part of the key used to sign it. This allows uCode to store only the hash of the Intel license signing key and authenticate the Intel-signed license. EMKPERMIT can also authenticate the license signed by the ISV key by providing an authenticated authorization of the key. This is done by creating a permit containing a hash of the ISV's public key. As a result, EMKPERMIT can verify Intel's license using an internal hash or an ISV key with the hash provided in the second permit.

EMKPERMIT takes three parameters: a pointer to a license, an optional pointer to a key permit, and a pointer to an output permit. For licenses signed by Intel, the key permit is empty and an internally hard-coded set of permit parameters is used. Generate the permit using a calling method that authenticates the architecture enclave license. EMKPERMIT ensures that the public key of this license is authorized by uCode (by comparing the hash of the included public key with the internal hash).

In the case of ISVs, the ISV key has a license signed by Intel. For calls to EMKPERMIT that do not use a key permit, use Intel's key hash to verify the license signature, generate a permit to authorize the ISV key hash, and use a legal license signing key. Represent. Then call EMKPERMIT again (including the ISV key permit). EMKPERMIT authenticates the MAC of the key permit and uses the hash of the ISV key, which previously used the hash of Intel. EMKPERMIT generates a permit for enclave, assuming that the public key of the enclave license hashes the value of the ISV key and the enclave license thereby signs appropriately. This permit shows license information (which may be consistent across all chains), hashes of all public keys in the license chain, enclave measurements, and their capabilities.

The following steps are taken during EMKPERMIT by u-code.

The license enclave is designed to make decisions about enclaves that are launched outside the visible range of the uCode. For example, uCode evaluates whether further enclave placements are allowed by ISV business arrangements with Intel. The License Enclave is designed to collect all materials that need to be assessed and to further approve or reject the activation of the Enclave. License enclaves only need to support complex business arrangements, not bulk licenses (eg, the ability to launch enclaves on any platform as many times as needed).

License Enclave is expected to be a system service. If the license indicates that further approval from the license enclave is required, the license chain and enclave permit generated by EMKPERMIT are passed to the license enclave. The license enclave then generates an approval request. The application then sends this authorization request to the appropriate licensing authority, where an authorization notice is generated. Then returned to the license enclave, the license enclave uses the license key to MAC the permit in the license MAC field.

Once a permit is issued to the enclave, it can be evaluated and implemented using u-code in the enclave maneuvering process. This is done as part of the EIINT instruction, using the linear address of the permit as a parameter. (1) Copy the scratchpad permit, (2) Verify the cpuMAC on the permit using the permit key, (3) License type! = In the case of bulk, the license MAC is verified using the license key. (4) The measured value in the permit is measured by MR. Compare with EADD, (5) compare the flag in the permit with the flag in SECS, (6) compare the Pubkey hash in the permit with MR. Additional steps are added to EINIT, such as copying to Policy, (7) copying ISV SVN to SECS, and (8) copying the functional map in the permit to SECS, as part of the authenticated enclave mechanism.

<Function>
The current feature map is the 128-bit mask feature available for this enclave.

Spaces are organized based on the actions taken by EINIT. Bits 00-03 are reserved for future use when ring-level constraints are activated on this enclave. 04-07 is reserved to indicate future permitted page protection. 08-23 is a processor key available through EGETKEY. 24-31 is for other controls (eg, utilizing name-based modes for proof, or for technologies for which future restrictions are desired). Some features are not utilized by Enclave in debug mode. The debug column indicates whether a feature is legal to use in debug mode.

In future generations, bit 00 may indicate that ring level and VT constraints apply to this enclave. Bits 01-02 indicate the ring level at which the enclave is allowed to execute, and bit 02 indicates whether the enclave is executed in VT root mode. At each EENTER, the current CPL is compared to bits 01-02 to determine if this enclave is allowed to run at this ring level. If an attempt to do this is made in the wrong ring, EENTER will fail. Similarly, if the ring constraint is active, the enclave can only be entered from VT root mode while bit 03 is up. In the first generation, these bits are MBZ.

Enclave pages may be encrypted or only integrity protected. In addition, the page may or may not be executable. In future generations, these attributes can be tracked and implemented in the security information portion of the EPC M. Function bits are reserved to control the use of encryption for the enclave's enclave page, based on whether the page is feasible or the enclave has already been EINITed.

Many architectural enclaves are entities of the ring 3 that require access to keys within or by the CPU. EGETKEY provides access to these keys, and functional bits are used by EGETKEY to determine if access to the keys can be granted.

The following is a list of current architectural enclaves with these characteristics and a brief description.

Provision Enclave has KEY_PROVISION functionality, is Intel approved, and runs on a single package platform each time a new device certification key (DAK) or provision certification key (PAK) is required. To. The purpose is to have the enclave derive the device ID & provision key based on the provision seed provided by EGETKEY. The Provision Enclave then uses these keys to prove the platform's legitimacy to the Provision Server and obtain a Device Certification Key (DAK). After obtaining the DAK, Provision Enclave will optionally use the DAK to authenticate with the Platform Proof Key (PAK) provider and retry the PAK. The use of PAK can provide better privacy to the user by guaranteeing for a particular ISV and the activity will no longer be associated with that of the previous owner of the platform. After obtaining the PAK, the Provision Enclave seals it so that the Quartering Enclave can obtain it.

The quartering enclave has the function KEY_REPORT, is approved by the enclave, and has the same author as the provision enclave (usually Intel) used to provision the EPID key. The location is an OS service that is available for all applications. Its purpose is to have the enclave unseal the platform EPID key. The report from EREPORT is provided as input. Enclave uses EGETKEY to obtain a report key. The report key is then used to validate the report. Enclave signs quotes by using EPID.

The licensed enclave has the KEY_LICENSE function, is licensed by Intel, is signed by Intel, is shipped with the enclave (OS service), and is instantiated independently. Its purpose is to evaluate complex licensing policies. If the Enclave requests further license confirmation from the License Enclave, EINIT may only accept it after the License Enclave has used the license key to CMAC the permit.

In a single package system, all symmetric keys used by the Enclave architecture are derived from a single singularity source stored in the processor's fuse array. The key hierarchy is divided into SE TCB hierarchies, which are platform implementation dependent and whose structure is consistent across all secure enclave implementations. The keying material for TCB return and the basis of the EPID provision are provided by the SE TCB hierarchy, which serves as the root of the SE key hierarchy. All keying materials used in both the Enclave instruction set and the trusted architecture Enclave are provided by the SE key hierarchy.

The platform provides a 128-bit platform-specific key that is fused. These keys are encrypted with a fuse using the keys stored in the secret CPU logic. Several single-purpose keys are derived using this key, and TCB return technology is applied based on platform requirements. The resulting key serves as the root of the SE key hierarchy.

The key of the architecture enclave is obtained using the EGETKEY instruction.

The enclave architecture requires the use of asymmetric keys to provide proof of the value of REPORT to off-platform systems. This key (EPID key) is initially provided by the fuse, but may be reprovisioned using one of the keys derived from the key hierarchy after placement. EPID certification key provisioning methods are outside the scope of this specification. For more information, see Device Certification Key (DAK) Provision Specification.

Finally, Enclave's architecture also utilizes keys in the logic of all processors to provision keying materials in OEMs. This key is known as the Out-of-Box Experience Global Key. We perform a similar derivation process on this key to provide the ISV's uniqueness. ISV usage of these keys derived from OOB keys is outside the scope of this specification.

The SE TCB part of the key hierarchy is platform specific and all foundations require the same basic key set. We call these base keys. These are all derived in the fuse key and the logical key and are the root of the SE key hierarchy. These keys are then used by the SE instruction to derive all the keys directly used in the SE architecture. These keys are the result of the TCB key hierarchy. The four SE base keys are combined with the EPID components made available to the SE architecture by platform-specific mechanisms. Table 12-1 shows each of these keys.

FIG. 17 shows an embodiment of the invention showing an implementation of a platform key hierarchy for secure enclaving of a single package. The box-based key outside 1700 is derived from the available derived resource 1750 to generate 1702 and the box key outside 1704. The available derived resource 1750 is a string having elements containing a unique value 1752, an owner epoch 1754, a secure enclave security version 1756, a SECS measurement register 1758, an ISV security version 1760, and a SECS flag 1762. Provision key 1710 can justify the platform to the Intel backend. EPID ID 1712 is a signature key. The initial safeID key blob 1718 is a quote and is associated with a safeID seed 1716. The base ops key 1714, combined with information from the available derived resource 1750, is a set 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 seal key 1740. Can be derived from 1720.

FIG. 17a shows an embodiment of the multi-package key hierarchy.

Secure enclave instructions and data structures rely on the base key, which is the source of the keying material. The platform key hierarchy shown in Table 12-1 is a description of the hierarchical relationship of platform key materials and the method of deriving the key from the platform root key.

The enclave wrapping key 1752 is a symmetric key used to encrypt secure Enclave Control Structure (SECS) pages while they are not protected within the Enclave Page Cache (EPC).

The permit key 1754 is used to provide legitimacy and integrity to the permit, which includes Enclave features and license information. The permit is MACd and its integrity is verified during the transition to EINIT. This key is utilized by EM KPERMIT uCode and EINIT.

The license key 1756 is used to assert compliance with a license policy that cannot be evaluated by uCode. The license key is used to generate an authenticated authorization from the license enclave evaluated by EINIT. This key, used by EIINT uCode, is available via EGETKEY and is enclaved with the KEY_LICENSE feature set.

The report key 1758 is used to provide the validity and integrity of the report. The report is MACd by ERREPORT and verified for integrity during the transition to the quartering enclave. This key is utilized by the EREPORT uCode and becomes available via EGETKEY for enclaves with the QUATE feature set.

The authentication key 1760 is an enclave-specific key that is used to provide the legitimacy and integrity of the data sent from the quartering enclave to the ISV enclave to provide enclave-to-enclave authentication on the same platform. The keys will be available to all enclaves via EGETKEY and enclaves with the ISV_AUTO feature set will be able to identify the keys they need.

The seal key 1762 provides 128 bits to each enclave to encrypt the sensitive data it contains. By integrating multiple seal policies into this seal key, ISVs can be given the flexibility of which software to use to unseal data. These keys will be available to any enclave via EGETKE, but individually seal keys will only be available to enclaves that meet the required seal policy.

EPID ID 1712 uniquely identifies the package. Its sole purpose is to enable provisioning of device certification keys, which are EPID-based anonymous certification keys. EPID ID is accessible only to Provision Enclave. Provision Enclave provides this over a secure channel only to authorized provision servers, and this is done only during the provision process initiated by the user or operating system. This ID becomes available via EGETKEY to the enclave having the PROVISIONING function.

The provision key 1710 is used to justify the platform to the Intel backend and to authenticate the current SETCB execution. By showing access to the provision key, the provision server can ensure that the enclave actually owns the EPID ID and is at least a device running on a particular TCB security version. The provision key is unique to the signer of this package and the provision enclave requesting it. This allows the separation between these multiple provision infrastructures when used on a single platform. This key is available via EGETKEY to enclaves with KEY_PROVISION functionality.

The provision seal key gives the provision enclave a 128-bit key so that the provision can be encrypted in a way that can be obtained even after a change in ownership. By using this key to encrypt the old EPID, it is possible to prove that the platform was disabled while acquiring the new EPID. The provision key is unique to the signer of this package and the provision enclave requesting it. This allows the separation between these multiple provision infrastructures when used on a single platform. This key is available via EGETKEY to enclaves with KEY_PROVISION functionality.

The ISV Out of Box (OOB) Experience Key 1700 is a shared key between all Intel platforms and ISVs. This key is derived from an OOB route specific to a particular ISV. ISVs can purchase access to this key, encrypt the secret against this key, and place it in the OEM's hard disk image. These secrets are only accessible to those codes that are securely running within a secure enclave, and the platform does not need to operate online or perform a full proof key provision. These keys are available to enclaves with OOB functionality via EGETKEY.

Provision keys are important keys for secure enclave architectures, but are not derived from platform keying materials. These keys are provisioned from the provision server or offline technology. A device proof key (DAK) is the use of an anonymous signature key (EPID) to prove the characteristics of an individual enclave. It is utilized by ISVs during key or secret provisions to ensure that this sensitive information is only sent to the protected deployment of an untampered application.

There are two sources for device certification keys. A suitable architecture ships the fuse-compressed initial DAK as EPID key blobs and EPID entropy. This allows the platform to begin certification immediately after the first power up. The second source is downloaded after contacting the DAK provision server and using the EPID ID and provision key to justify the hardware. This second method is utilized by platforms that do not have a fused EPID key and after disabling the underlying TCB version. The EPID fuse can access the enclave with PROVISIONING function via EGETKEY.

The Platform Certification Key (PAK) optionally offers an additional level of privacy. Some uses of DAK can also be associated. A single ISV can determine if a given EPID will reuse this service, especially if the ISV enclave has a name-based certification function. (But there is no collusion between multiple ISVs to track users). This association continues during the waterfall event, as the DAK is tied to the platform rather than to the owner. Therefore, some users prefer to use their DAK to prove the legitimacy of their platform rather than having a third party issue a PAK for daily proof. On multi-package platforms, the DAK of each package is used to build a PAK (representing the entire platform in the proof).

The key derivation of a user-accessible key conforms to NIST Special Publication 800-108 (recommended for key derivation using a pseudo-random function). A pseudo-random number function (PRF) is required in the construction of the key derivation function. PRF recommends AES-CMAC algorithm defined in NIST SP800-38B, block cipher mode of processing-CMAC mode for authentication, May 2005 (http://csrc.nist.gov/publications/nistpubs) /800-108/sp800-108.pdf). A common key derivation is DerivativeKey = PRF _ParentKey (DerivativeString).

A derivative string consists of a subset of eight elements based on the particular key requested. Table 12-2 describes each of the available elements that can be part of the derivation.

Each key has a predefined set of derived elements, which contains the derived string. Table 12-3 shows the elements contained in each key in the key hierarchy. Each column represents a key, and the rows indicate whether the key contains a particular element. Debug strings are included when the SECS of the enclave issuing the request indicates that it is in debug mode, and a "request" is not required for this element and can be selected in the request for key derivation. It shows that there is.

Secure Enclave supports technology that isolates and recovers software breaches at several points in the boot sequence. To support the separation, all long-term keying materials provided to the enclave are derived utilizing the current security version of TCB.

This section describes an example of a platform architecture where a recoverable TCB consists of uCode, MCHECK, and microcode (or uVMM). The hardware requirements may be the same for any SE support platform, but the specific key flow depends on the particular TCB element. Other platforms can also be supported using technologies similar to those used here.

To support CPU-based protection technology, the following keys are required in the hardware. These keys form the basis of the TCB key hierarchy.
<256-bit logical key unique to stepping>
The 256-bit logical key is divided into two parts: a 128-bit fuse wrap key and a 128-bit out-of-box experience key. However, a single 128-bit key that adds uCode can also be used for both.
<544-bit fuse key unique to the die>
These include a 32-bit group id, a 256-bit SafeIdA.x value, and a 256-bit preseed. The A.x value and the 256-bit preseed are encrypted with the 128-bit fuse wrap key described above.
<Primary register>
In the key derivation process, it is necessary to store the key, place it on the package, and make it available only to uCode. Two 128-bit registers are required during platform runtime. An additional 256-bit space is required for the EPID key until the CMA is up and running. After this, the additional 256 bits are no longer needed by the CPU.
<TCB SVN register>
This register is a 64-bit lockable register divided to hold an SVN in each TCB layer. The method of division is left to the discretion of the platform designer, but it seems reasonable to divide it into eight 8-bit SVNs. Each part of this register can be locked independently.

Binding a key to a particular TCB version set is done by having uCode derive the first set of keys from the fuse key based on the type of maneuvering sequence initiated. After locking this fuse, a chain of derivations is performed at each loading in the activation sequence.

After loading low-level code, the chain continues to contain ISV-assigned security versions of the software running in the enclave. In certain configurations, you can access the keys derived from the current version and the keys from the previous configuration. This allows user data to transition seamlessly to a new, stable version.

When a die-specific key is generated, it is encrypted with a key wrap key. This makes it increasingly difficult to use hardware monitoring tools to extract keys and protect the keys that pass before they are placed in that area.

The cryptographic algorithm used to encrypt these keys is 10 rounds of 128-bit AES-ECB decryption. The key generation server performs AES-ECB encryption on each key and generates a fuse-burned ciphertext key.

The pseudo-random number function (PRF) used for key derivation in the TCB key hierarchy is platform specific. 128-bit AES-ECB is recommended for platforms that support AES-NI. The purpose is to provide an irreversible way to derive a key from another key. This section makes use of the following function prototypes.

There are three methods for PRF in key derivation. PRF loop derivation is used to populate a key with a uCode SVN while building relationships between keys of different SVNs. Specifically, PRELoop (x-1) = PRF _{PRELoop (x)} (const).

This causes the data to be migrated forward. Take the case of executing uCode SVN3 as an example. Enclave uses EGETKEY to obtain a seal key based on this version (PRELoop (3)) and use it to seal the data. Delivering a field uCode upgrade, the next launch uCode SVN is 4. After the upgrade, the EGETKEY implementation will have access to PRFLoop (4). If the enclave requires EGETKEY to send an SVN3 key, PRELoop (3) = PRF _{PRELoop (4)} (constant) can be calculated to get the old seal key.

To build this characteristic, we use a PRF loop, but since the characteristic PRF _{PRELoop (x-1)} is calculated from the PRF _{PRELoop (x)} , we build the maximum value of SVN and subtract from it. We have to go. A specific maximum should be built for each platform type based on the required performance. 32 is recommended as the initial value of the maximum value. The PRF loop derivation is as follows.

This method is used to populate the UCode SVN into the SVN key and is the basis for SE-based keys. The die-specific key to be fused includes a 288-bit EPID value and a 256-bit random key. All non-ephemeral symmetric keys can be derived from these 256 bits (consisting of two 128-bit keys). Therefore, it is possible to create a technique for deriving a plurality of keys from a single key. To do this, once the fuse key has been decoded, it can be used to call the PRF with different fixed constants. When the key is split, it generally looks like this:

This technique is used to generate random numbers that are used as part of the EPID ID and Provision ID.

When the SVN key is loop-derived based on uCode SVN, it can be stored in a remote protected memory such as SE CMA. The microcode utilizes the MSR exposed to the microcode only to derive the key from the SVN key. The MSR utilizes a key selector that indicates whether the derivation basis is a global out-of-box key or a fuse key, and the required SVN set for each TCB layer. This makes it possible to ensure that the request is less than or equal to the current value. UCode can utilize any required PRE to obtain the old SVN key, PRF, and the requested TCB SVN.

Once the appropriate SVN key is available, it will be used as the CMAC key for the requested TCB SVN. The microcode uses this as a CMAC key for the Ops key, or the SEOps seed (value derived from the fuse key part unknown to Intel) for the fixed string of the provision base key. That is, se_base_key = CMAC (svn_base_key, se_ops_seed).

FIG. 18 shows an example of a microcode-based secure enclave key hierarchy in one embodiment of the present invention. The reset microcode 1800 hierarchy utilizes the global wrap logic key 1801 and the unique root fuse 1802 known to Intel as inputs to the unwrap 1806 function. The outputs of the unwrap 1806 and microcode SVN1805 are input to the PRF loop 1808. Microcode SVN1805 and global root logic key 1803 enter 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. The microcode SVN1805 is stored in the TCB SVN register 1814. The global wrap logic key 1801 and the SE EPID A.x fuse 1893 are input to the unwrap 1807 function and store the result in the SE EPID 1816 register. In the MChack1820 layer, the outputs of the MChackSVN1821 and the 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. The SE EPID 1816 is stored in the SE EPID 1828. In the loading microcode 1830 layer, the outputs of the microcode SVN1831 and the TCB SVN register 1826 are stored in the TCB SVN register 1846. The microcode SVN register 1822 is stored in the microcode SVN register 1832. The global key register 1824 is stored in the global key register 1834. The SE EPID 1828 is stored in the SE EPID 1838. In the XuMSR derivation key 1840 hierarchy, the microcode SVN difference 1841 enters the PRF loop 1842 and the PRF loop 1844. The microcode SVN1832 register sends data to PRF loop 1842, and the global key register 1834 sends data to PRF loop 1844. The output of the PRF loop 1842 and the output of the TCB SVN register 1836 enter the PRF loop 1846, and the output of the PRF loop 1844 and the output of the TCB SVN register 1836 enter the PRF loop 1848. 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, and the EPID group ID fuse is stored in the EPID group 1858. Seed 1 1856 enters PRE loop 1886 and PRE 1888. The output of PRE Loop 1888 is SE EPID Seed 11892. The output of the PRF loop 1886 is a SE ops seed 1890. The SE ops seed 1890 is obtained from the SVN base key 1850 and the requested SVN1864 enters the CMAC1868 function to generate the SE ops key 1872. The current SVN1862 is obtained from the SVN base key 1850 and enters the CMAC1866 function to generate the SE provision key 1870. If the SVN base key is equal to {0, 0, 0} 1874, the SVN base key 1850 is stored in seed 0 1876. Seed 0 1876 enters PRF loop 1878 and PRF loop 1880. The output of the PRF loop 1878 is SE EPID ID 1882 and the output of the PRF loop 1880 is SE EPID seed 0 1884.

All cores are synchronized and utilize a doorbell or similar mechanism to ensure that everything is in MCHECK. When all cores are running MCHECK, (1) uCode reads, decrypts, and locks the fuse, (2) uCode uses the PRF loop for the SVN key and the PRF loop for the OOBE key. Insert the uCode SVN into both keys. uCode writes its SVN to the TCB SVN register and locks its portion, (3) the MCHECK loader or early MCKECK code writes and locks the MCHECK SVN to the TCB SVN register, (4) the microcode patch loader. However, each step of writing the microcode patch SVN to the TCB SVN register and locking it is performed from the BSP. AP does not participate in the key flow.

During microcode initialization, or when calling EGETKEY, the microcode calculates the SE base key required to meet the request. The base key may be cached in the CMA for further performance improvement. Table 12-4 shows the calculation method of the base key.

Include a 256-bit random owner epoch in the key derivation to protect user privacy and data in platform waterfall. This value is randomly created during the owner change. Prior to utilizing the enclave key, the software may write the owner epoch to SE_EPOCH_MSR. This may be done by the BIOS doing a permanent write to the flash. This can also be calculated from some user input (such as a hash of the user activation password). Alternatively, it may be provided by a secure enclave driver before permitting the use of the enclave.

The confidentiality of this value must ensure that the data encrypted by the platform cannot be decrypted by the enclave that was first authorized by the laptop owner after the waterfall. A security breach of this value does not lead to a security breach of enclave data.

The SE key information structure is a non-permanent structure stored in a protected area of memory or a package. The CMA is the most commonly used location, but it is also possible to utilize any of the on-die protected storage. The SE key information can be initialized while the power is turned on. The key ID is set to a random value and the key count is set to 0. Each time the enclave key, permit key, and report key are used, the key ID is read and the key count is incremented. After 2 ^ 32 keys are used, the key ID is changed to a new random number value and the key count is reset to 0. The SE key information arrangement is shown in FIG.

When the power is turned on, the platform key table is initialized by uCode. The BIOS and other host firmware get the current owner epoch from permanent storage or from the user and write it to the LoadOwnerEpochMSR. At this point, the enclave key hierarchy is available.

Many of Enclave's architectures utilize keys to provide authentication and confidentiality of Enclave data, and utilize Architecture Enclave to minimize processor complexity for high-level use. Handle these keys. For example, the quartering enclave uses the REPORT key to confirm that the REPORT structure generated by the EREPORT instruction has been created on the platform, and the PERMITING enclave uses the PERMIT key to activate the enclave. Generates an enclave PERMIT that EINIT consumes when it is done.

In addition, any application-level enclave needs to access the key to seal a stored secret on a platform outside the enclave, and when the application enclave is reestablished (during a power cycle). Also) the seal is released.

The mechanism for doing this is the EGETKEY instruction. This is a single interface for building secrets about the current software environment.
EGETKEY currently provides access to the following keys: (1) Provision Key ID (architecture to identify data blobs that are uniquely encrypted (using the provision key) for the processor). (Used by Provision Enclave), (2) Provision Key (used by Architecture Provision Enclave to decrypt data blobs uniquely encrypted for the processor), (3) Provision Seal Key (Used by Architecture Provision Enclave to encrypt EPID in a way that Enclave can decrypt even if the owner changes), (4) License Key (Architecture to create a permit) License Enclave (used by Permission Enclave), (5) Report Key (used by Architecture Quarting Enclave to verify report structure), (6) ISV Authentic Key (ISV AUTOH KEY) (Specific Target Application Enclave) Used by Architecture Quarting Enclave to create authentication data for), (7) Authentic Key (AUTOKEY) (Application Enclave to authenticate data received by Architecture Quarting Enclave) (Used by), (8) Seal key (used by application enclave to encrypt data desired to be stored outside the enclave), (9) OOB experience key (for out-of-box experience use (eg) BluRay player) Used by ISV to pre-provision encrypted data).

Most of these values are raw, non-processor resident, and are actually derived from the value of a single fuse key at the request of EGETKEY. Derived on demand when each of these keys is in a single key from a possible set rather than a single key. The particular key delivered depends on multiple parameters, some of which are user-selectable and others of which are based on the system or certain conditions.

To select a key, the key request structure is used as an input to the EGETKEY instruction. In addition to selecting a key, the user uses a key request structure to let the caller identify these variables under control that he or she wishes to use during key generation. The following drawing shows the key request structure.

Key selection is used to identify the key that the user needs, and key policy is used to ascertain the additional values used to create the key (that is, the specific security of the architecture enclave). Whether it is a version, a specific security version of the architecture enclave, a specific version of the application enclave, or a measurement register associated with the current enclave (when EGETKEY is called from within ENCLAVE). ..

Further randomness can also be utilized for key derivation, which is especially necessary to prevent key depletion and is utilized by PERMITING and QUATING architecture enclaves. It is also used by the application enclave when creating a SEALing key. A field set to zero means that no randomness is added, otherwise the field will point to a 256-bit aligned data value. The table below identifies the structure of the key selection field.

A key policy is a bitfield selector that is used to determine whether a particular value (whether from a user or system state) is used for key derivation.

<Enclave register and control>

Two enable levels are provided to the enclave. The first enable is the opt of the bit set by the BIOS. This is a write once function. Enables or disables the enclave feature before the next reset. The second enable is provided to the OS or VMM to switch the enclave function on or off as needed.

FIG. 19 shows an enclave CTL_MSR register that can be seen in one embodiment of the present invention. The least significant bit is enable 1900. Bit 1 of the register is 1910 and is On. Bits 2 to 63 are reserved.

The enclave function first begins by setting an enable bit in the enclave CTL_MSR shown in FIG. This bit is initially disabled when the package is reset. This bit can be written once after a package reset.

The BIOS sets the bit to enable the enclave. When the BIOS clears a bit, the enclave cannot be enabled until that part is reset.

The software can detect enclave support by executing a CPUID instruction. CPUID returns a result indicating whether enclave is supported.

When the Bit Opt is cleared, the CPUID reports that it will not execute the enclave.

The system software uses the enclave CTL_MSR shown in FIG. 19 to control the enclave function. The On-bit allows the software to dynamically control access to the enclave function.

The software can detect enclave support by executing a CPUID instruction. Enclave support is indicated when the ON bit is set in the enclave CTL MSR.

The TCSMSR register is a register on each processor that contains the address of the TCS and is utilized by exception handling and RDTCSPTR. Loaded when entering the enclave. The register is loaded with the value of TCS when executing EENTER and is read by ERDTCSPTR. The register size is based on the processor mode.

The enclave base address register on each processor contains the lower address of the enclave in progress and is loaded as it enters the enclave by microcode. The register size is based on the processor mode. This register is invisible to the software and is a microcode temporary.

The register holds the current enclave address limit and is loaded when entering the enclave. The register is loaded with the value stored in the SECS when the enclave starts execution. This is a temporary microcode register. The register size is based on the processor mode.

The Enclave Page Cache (EPC) Maximum Size Register indicates the maximum size of the EPC. This size is given by the number of pages of 4096 bytes. This is a 32-bit register. This register is read-only and indicates the maximum size that the EPC supports in the current design.

The EPC size register EPC_SIZE MSR indicates the currently defined size of the EPC. Loading a register defines the EPC to that size. This value is given on a 4096-bit page. For example, one 4096-bit page is 1. The register value cannot exceed the EPC_MAX value. When the value exceeds the EPC_MAX value, a GP defect is taken by the WRMSR instruction. By writing to this register, all data of the EPC is invalidated before writing. The software may save all EPC entries (if necessary) before updating this register.

The EPC base register indicates the position of the base of the EPC. By writing to this register, all data of the EPC is invalidated before writing. The software may save all EPC entries (if necessary) before updating this register.

In general, the external interface does not allow transfers or transactions that could compromise the security of the enclave. Secure enclave requires a random number of enclave keys. The random number generator is securely accessible by microcode. It does not have to be placed in the core of the part.

FIG. 26 shows a processor package for a digital random number generator in one embodiment of the present invention. The processor package 2600 may include a plurality of cores, core 0 2640 and core 1 2670. Core 0 2640 may include microcode 2642, microcode 2644, microcode 2646, RNG microcode module 2650, and RNG queue 2654. Core 1 2670 may include microcode 2672, microcode 2674, microcode 2676, RNG microcode module 2680, and RNG queue 2864. The read random instruction 2630 may communicate with the microcode 2642 and the read random instruction 2635 may communicate with the microcode 2672. Processor package 2600 may further include DRNG2602, which takes STD2608, OPE2610, PSK2612, and TSC2614. The DRNG 2602 can acquire a digital entropy source 2604, which connects to an online self-test 2606. The output of the online self-test 2606 may be one input of the combined regulator / deterministic random bit generator (DRBG) 2620.

The enclave may be set as a debug enclave at creation time. The debug enclave can use the EDBGRD and EDBGWR instructions to externally access the contents of the enclave. The debug enclave is set up by setting the debug enclave in ECREATE. This bit is stored in the ECS of the enclave.

The enclave created by the debug bit claire is a generated enclave. The enclave contains a debug bit indicating that the EPC is a debug enclave. The enclave remains encrypted, either in main memory or on disk. Debuggers that need to find the contents of the enclave load memory into the EPC. The EDBGRD and EDBGWR instructions can be used to access the location of the enclave memory resident in the EPC. The debug enclave does not require a permit to run and runs without a valid permit.

The debug control register DR7 is saved in the TCS save area when entering the generation enclave. DR7 is shown in FIG. FIG. 27 is a debug register DR7 2700 in one embodiment of the present invention. Register DR7 2700 includes L0 2702, L1 2706, L2 2710, L3 2714, G0 2704, G1 2708, G2 2712, and G3 2716. The other bits of the DR7 register 2700 are LE2718, GE2720, 001 2722, GD2724, 00 2726, R / W0 2728, LEN0 2730, R / W1 2732, LEN1 2734, R / W2 2736, LEN2 2738, R / W3 2740, And LEN3 2742.

Bits L3-L0 and G3-G0 are set to a value of 0. DR7 is set to the original value when leaving the enclave.

For debug enclaves, do not change the debug register value. FLAGS. The TF is set at the start of the EENTER instruction and needs to take into account the following two cases:

One is when the debugger is legacy (non-SE recognition) or the enclave is in generate (non-debug) mode.

The SE recognition debugger is intended for debug mode enclave.

In the first case, a #DB exception can occur in the subject of the next EXIT instruction. This treats the enclave as a large, opaque operation. In the second case, the user can take advantage of the complete freedom to single step through the enclave. This action involves the three data fields in the enclave, and the RFLAGS in EENTER, EEEXIT, and EIRET. Supported by TF special processing.

The register value is saved in the TCS save area. The register is set to 0. At the end of the enclave, the register is restored to the entry value. If the enclave has a branch trace enabled at the start, it will be the last entry before EENTER enters the enclave. At the end of the enclave, the starting position after the end is written to the branch trace.

The Int n and Int 3 instructions are reported as GP failures when executed in the enclave. The debugger can hook GP bad conditions when debugging an enclave.

This document describes a novel technique for performing CMAC mode processing for AES block ciphers. CMAC is a mode that supports the authenticity of a message, accepts a message A and a key K as inputs, and returns an authentication tag T. Derivation of the authentication tag is performed using a CBC (cryptographic block chain) algorithm. CMAC is more complex than CBC because it includes a protection mechanism against extended length attacks. These are referred to as "three characteristics of CMAC". The following outlines CBC and CMAC.

FIG. 20 shows a cryptographic block chain algorithm used in one embodiment of the present invention. The initialization vector 2000 and the stage 1 input 2010 enter the exclusive OR gate 2012. The output of the exclusive OR gate 2012 enters the stage 1 block cipher 2015. The stage 1 block cipher output 2018 then enters the stage 2 exclusive OR gate 2022 along with the stage 2 input 2020. The output of the exclusive OR gate 2022 enters the stage 2 block cipher 2025. The stage 2 block cipher output 2028 enters the next stage of the cipher block chain (not shown).

The CBC algorithm uses a block cipher to ensure the confidentiality of some data or to calculate the authentication tag for this data. The basic idea of the CBC algorithm is that the output from the previous cipher is XORed in the next input block before encryption. In this way, patterns that may exist in the input data can be excluded from the ciphertext. Also, the combination of XOR processing between block cipher transactions results in a large amount of mixing to derive an ideally forgeable message authentication tag.

The CBC algorithm is shown in FIG. 20 and below. The cipher is assumed to be a 128-bit cipher as in the case of AES.

The CMAC specification includes three additional algorithms to initialize and terminate the CBC algorithm. These are referred to as the "three features" of CMAC. The first feature relates to deriving _two subkey values K ₁ and K ₂ from the symmetric key K. The subkeys K ₁ and K ₂ are derived from the intermediate value L. CMAC shows that L can be obtained by performing a symmetric key block cipher conversion using the symmetric key value K to a string consisting of zeros (that is, 0 ¹²⁸ ) using the symmetric key value K. .. This relationship is expressed by the formula (1) L = CIPHER _K (0 ¹²⁸ ).

When L is derived, the most significant bit of L is checked. If this is zero, it is derived from L by shifting K ₁ by 1 bit to the left. If not, L is shifted to the left by 1 bit and XORed with a special value R _b to generate K ₁ . R _b is defined as (0 ¹²⁰ 10000111) in binary form. K _{2 is} also generated from K _{1 by the} same procedure. The derivation of the subkeys K ₁ and K ₂ is shown in the following pseudo code. It is assumed that MSB () indicates the most significant bit of a certain value.

The second feature of CMAC is to pad the input data before using the CBC algorithm. If the last block of data is not a complete block, pad it with the required number of 0 bits to make the final block complete.

A third feature of CMAC relates to modifications to the final block made to avoid length extension attacks. In the case the last block is not completely 1 (in the case of padding necessary), to XOR the last block with subkeys K _1. If not, XOR with subkey K ₂ . The CMAC tag generation and verification algorithm is shown below.

The following is an example of how to implement the CBC () algorithm when the symmetric key block cipher is used as the AES and the processor supports the AES round acceleration instruction set. The Intel architecture supports four new instructions in the Westmere processor (2009) and subsequent time frames. These instructions are AESENC (AES round encryption), AESENCEST (AES final round encryption), AESDEC (AES round decryption), and AESDECLASS (AES final round decryption). The specifications of these instructions are shown below.

Since the tag verification process is the same as tag generation, a call to AESENC AESENCEST alone is sufficient to implement CMAC mode using the AES round instruction. FIG. 21 is a flowchart associated with encryption of a single AES block. FIG. 22 shows a flowchart associated with encryption of a large number of AES blocks utilizing the CBC algorithm.

In order to implement the key schedule conversion, the AESIMC instruction and the AESKEYGENASSIST instruction for inverse mix columns can be used. AESKEYGENASSIST is used to generate a round key used for encryption. AESIMC is used to convert a cryptographic round key into a format that can be used for decryption according to an even inverse cryptographic model. The AESIMC and AESKEYGENASSIST instructions are described at http://softwarecommunity.intel.com/articles/eng/3788.htm.

CMAC is shown using a 128-bit amount of big endian description. In order to implement CMAC accurately using a little endian machine, it is necessary to perform a 16-byte wide reflection process at some point in the source code implementation. This process can be performed quickly by using the PSHUFB instruction (1 clock latency, throughput). The time when bite shuffle is required is described below.

The SUBKEYS () algorithm implementation byte reflection needs to be done for L after being derived using the AES cipher for the zero string and before the two subkeys are being derived. Byte reflection is required after being derived from L for the two subkeys. The SUBKEYS () implementation is shown in C below.

Next, it is necessary to reflect the bytes for the final block before and after padding only when the final block is not perfect. These steps are shown in the C implementation example below.

function_pshufb () reflects 128-bit wide bytes.

<SE requirements for SMI>
Enclave is not allowed to run in SMM space. Attempting to execute the enclave in SMM mode results in a GP failure of the instruction. If it occurs while the SMI is running in the enclave, the processor saves the register state in the remote enclave and exits. Upon completion, the TBD MSR bit is set to indicate that SMI has occurred during execution of the enclave. The SMM code cannot access the enclaim data. Attempts to contact the EPC area will return junk data in the actual mode and return bad EPC pages in the protected mode.

Some instructions are not allowed to be executed. Several general rules are used to determine which instruction is legal.
1. 1. Ring level changes are not allowed within the enclave. Orders to change or change the ring level are prohibited.
2. External software cannot service VMEXITS in the enclave. Prohibits all instructions that generate or may generate VMEXIT in the enclave.
3. 3. The software cannot create virtual machines in the enclave. Prohibit all VMX instructions.
4. Prohibit instructions to execute I / O references inside the enclave.

In the first generation of enclaves, the processor may run in ring 3 with the IOPL set set to 0 as it enters the enclave. The instructions listed in Table 18-1 are legal to save the programming environment when running the enclave in a virtualized or non-virtualized environment.

There are restrictions on the state inside the enclave. When entering the enclave, save GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS in the TCS area. The local value is cleared. Instructions that access or cause access to these registers fail in the enclave. GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS are restored when exiting the enclave.

Enclave life can be categorized as distinct phases. The first step is enclave generation. The second stage is the use of enclaves. The final stage is the destruction of the enclave.

OS / VMM support is required to generate and use enclaves. Enclave does not depend on OS / VMM in terms of security, but OS / VMM is required to properly maintain a certain hardware data structure. If the OS / VMM fails to maintain these structures, security is not compromised, but the entire enclave may be defective.

Some orders support proof of enclave, sealing and unsealing of confidential data, and authorization of authenticated enclave.

In the first stage, the enclave may be securely constructed and the internal software environment may be set up for use by the application. Create an enclave using three instructions. The first instruction, ECREATE, sets the initial state environment. This instruction generates an enclave key, loads it, encrypts it, and performs a two-page integrity check used to store the enclave data structure. The second instruction, EADDPRE, adds one page of data to the enclave. For more information, add the required pages to the code, stack, and heap in the enclave. The third instruction, EINIT, sets the internal software environment to a known state. Upon completion of this order, the enclave has moved to the second stage, "utilization."

Prior to executing EINIT, the construction software may obtain a permit by executing EMKPERMIT or by using a permit enclave.

The enclave is input by the EENTER instruction. This instruction causes the machine to transition to enclave mode. It then passes control to a predefined entry point. The EXIT instruction returns from the enclave to the external application. The EIRRET instruction returns to the enclave from the end of the interrupt.

When entering the enclave via EENTER or EIRET, the following processing is executed by instruction. That is, the processing is save and clear of GDTR.limit, LDTR.limit, IA32_EFER.SCE, IA32_SYSENTER_CS. Restore GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS when exiting (On exit restore GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS).

There is no command to destroy the Enclave.

The EDBG_READ instruction reads 8 bytes at a certain position in the debug enclave. No access is allowed to the non-debug enclave. The EDBG_WRITE instruction writes 8 bytes to a certain position in the debug enclave. No access is allowed to the non-debug enclave.

The Enclave Page Cache (EPC) is managed by solving two instructions. The two instructions load / store EPC pages (ELPG and EWBINVPG).

注^２：「内部」には利用可能なモデルがないが、内部からＥＭＫＰＥＲＭＩＴに実行を許可することにまつわる被害は知られていない。
注^３：将来のバージョンでは、リング０からもエンクレーブへのエントリが可能となるかもしれない。 EREPORT produces a cryptographically protected structure that holds enclave measurements. EGETKEY provides a means to obtain various types of enclave-specific keys. EMKPERMIT is used to generate a permit for a certified enclave.

Note ² : There is no model available in "inside", but the damage related to permitting EMKPERMIT to execute from inside is not known.
Note ³ : In future versions, it may be possible to enter the enclave from ring 0 as well.

When an interrupt occurs, the processor state is saved (hidden) in the enclave to clear the state. In addition, the interrupt return address may be hidden.

Interrupts that occur during enclave execution push information into the interrupt stack in the form that the operating system expects, eliminating the need to change the OS code. To accomplish this, a pointer to the trampoline code is pushed onto the interrupt stack as a RIP. This trampoline code eventually returns to the enclave by an EENTER instruction with a special parameter (q.v.).

The interrupt stack used is selected according to the same rules used in non-SE mode. So the rules are (1) the interrupt stack is associated with the new ring if there is a privileged level change, and (2) the current untrusted if there is no privileged level change. -Use the stack (Untrusted Stack). (3) When using the IA-32e IST mechanism, use this method to select the interrupt stack.

FIG. 23 shows an embodiment of an application and interrupt stack after being interrupted by a stack switch. The current save state region frame 2300 includes the RSP register 2305. The thread control structure 2310 may include a count of state save areas 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 2342. The interrupt stack 2330 may send the data in the RSP register 2334 to the counts of the application stack 2320 and the save state area 2300. Error code 2342 may come from the RSP after push 2346. The interrupt routing routine 2314 and the instruction register 2340 send out a thread-by-thread trampoline for uRTS2344.

In either case, the interrupt stack and the selection of information pushed to it are consistent with non-SE processing. FIG. 23 shows the application and interrupt stack after interrupting with a stack switch. Interrupts without a stack switch use the application stack. In addition, the TCS pointer is placed in the RBX because it will be used later by the EENTER instruction when resuming enclave after an interrupt.

The TCS :: IRR (Interrupt Return Routine) points to a thread-by-thread code sequence that later returns to a special thread. This pointer is pushed onto the interrupt stack as a return RIP. This causes the set of data structures to return the IRET to the application on which the interrupt return code (including the special EENTER instruction) is executed. EENTER takes an RBX register that is initialized at the time of interrupt, uses this as a TCS, and re-enters the enclave.

RFLAGS bits such as CF (carry flag), SF (sign flag), PF (parity flag), OF (overflow flag), AS (adjustment flag), DF (direction flag), ZF (zero flag) Is cleared before pushing the register to the interrupt stack.

FIG. 24 shows a method in which a stack of multiple state save area slots according to an embodiment of the present invention can be implemented. The thread control structure 2400 may include the next state save area slot 2402, the current state save area slot 2404, and the state save area slot 2406. The state save area 0 2410, the state save area 12412, and the state save area N 2418 are three separate selection positions within the state save area. The next state save area slot 2402 specifies a position used in the state save area (state save area 0 2410). The current state save area slot 2404 specifies a position used in the state save area (state save area 12412). The state save area slot 2406 specifies a position used in the state save area (state save area N 2418).

The state save area holds the enclave state at the time of interruption. The SSA is a stack of multiple SSA slots as shown in FIG. 19-3, as interrupts can be sent to user mode, which may re-enter the next enclave. The position of the state save area used is controlled by three TCS variables, which are the number of state save area slots (NSSA) (defining the total number of slots in the state save area stack). Current state save area slot (CSAS) (defines the current slot used on the next interrupt), state save area (SSA) (save area slot used to save the processor state on the interrupt) Set).

When an interrupt occurs during execution on a thread in the enclave, the microcode examines the TCS :: SSA and TCS :: CSSA to determine the save area used. Processor state is saved and cleared (to prevent secret leaks) and TCS :: CSSA is incremented. As will be described later, if an exception occurs in the final slot, the exception cannot be sent to the enclave.

Note: In EENTER, CCSA may be less than NSSA and it is guaranteed that there is at least one save area for the interrupt (unless you are using EENTER to return from the interrupt).

FIG. 25 shows a portion of a state machine with interrupt, bad, and trap state transitions. Possible states are inactive 2500, active 2510, expected 2520, processed (EENTER illegal) 2530, and processing 2540. When the EENTER is placed at TCS: ENTRY2502, the inactive 2500 transitions to the active 2510. When EXIT2504 occurs, the active 2510 transitions to the inactive 2500. When an interrupt, failure, or trap 2512 occurs, the active 2510 transitions to the expected 2520. When EIRET2514 occurs, the expected 2520 transitions to the active 2510. When the EENTER is placed at TCS: HANDLER2524, the expected 2520 transitions to the processing 2540. When EIRET2522 occurs, the expected 2520 transitions to 2540 during processing. In the event of an interrupt, failure, or trap 2526, the processing 2540 transitions to the expected 2520. When EXIT2532 occurs, the processing 2540 transitions to the processed 2530. When a processing interrupt occurs in the enclave exception handler and EIRET2534 occurs, the processed 2530 transitions to the processing 2540. When a processing interrupt that is not from the enclave exception handler occurs and EIRET2534 occurs, the processed 2530 transitions to the active 2510. Dotted line transitions 2522, 2526, 2534 occur only during the processing of interrupts in the enclave exception handler.

FIG. 25 shows a portion of the enclaved machine that handles interrupts. Interrupts begin by pushing a synthetic interrupt frame onto the optional stack switch and interrupt stack. If the event was an interrupt, the enclave goes into an interrupted state. If the event was an exception, the enclave goes into an exceptional state. These two states are distinguished to ensure that the enclave exception is delivered to the enclave and to prevent the attacking application code from delivering the spurious exception.

Upon transitioning to the interrupted state, the untrusted code (application, OS, or both) need only resume enclave using EENTER / RETURN_ROM_INTERRUPT.

Upon transition to an exceptional state, the untrusted code (application, OS, or both) resumes enclave using (1) EIRET and returns to the interrupted IP. This is, for example, a method of dealing with page defects. If the interrupt is caused by a defect and nothing is done to correct the failure condition, the bad instruction is re-executed to cause the failure again (and will fault again). However, the EIRET after the trap may decide to return to the instruction after the trap instruction, (2) call the enclave exception handler, and (3) destroy the thread or enclave.

EENTER in the expected state advances to the processing state. EXIT (processing state) from the trap handler proceeds to the processed state. ENTER / NORMAL is illegal in this state. EIRET from the trampoline resumes the state pushed to the SSA (active or in-flight state) from the last interrupt.

Divide the secure enclave instruction into two opcodes (ie, privileged and unprivileged opcodes). The instruction processing is determined by the value of RAX when the instruction is called.

The ECREATE instruction initializes the protected SECS. The source operand points to the page_info structure. The content page field points to an unprotected SECS structure. The SECS structure may be page-aligned. The lower 12 bits of the SECS base and the boundary value may be 0. 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 properly initialized.

<EADDPRE>
<Explanation of instructions>
EADDPRE causes privileged software to copy pages outside the enclave to pages in the enclave specified by lin_addr, and the attributes of the enclave page are set using the sec_info flag field. As part of the instruction, the page is hashed and the resulting hash value is extended to the enclave's measurement register. EADDPRE can only be executed for enclaves where the EINIT instruction has not yet been initialized.

<EADDPOST>
<Explanation of instructions>
EALLOCATE initializes the SMAP entry of the enclave specified by lin_addr in the privileged software, and the attributes of the enclave page are set using the sec_info flag field. The Enclave page may be accessed using the EACCEPT instruction before the Enclave can access the page. EALLOCATE is executed only in the enclave initialized by the EINIT instruction.

<EMKPERMIT>
<Explanation of instructions>
Authenticate the enclave or license and use it to generate a permit. If rbx == NULL, the certificate may be signed by Intel. In other cases, the license may be signed with the key shown on the rbx permit.

<EINIT>
<Explanation of instructions>
EIINT displays the enclave as ready to run in the software environment. When the initialization is finally successful (At the end successful initialization), EENTER is allowed to the enclave.

<ELPG>
<Explanation of instructions>
This instruction is used to load the page into the Enclave Page Cache (EPC).

<EWBINVPG>
<Explanation of instructions>
This instruction is used to write the dirty page back from the EPC to main memory.

<EUPSMAP>
<Explanation of instructions>
This instruction checks and updates the version of the enclave page residing on the EPC.

<EREMOVE>
<Explanation of instructions>
This instruction updates SMAP when the data is loaded into the EPC.

<EADDSMAP>
<Explanation of instructions>
This instruction is used to add a new page to SMAP when the enclave has already been initialized.

<EMODIFY>
<Explanation of instructions>
This instruction modifies the SEC_INFO field to allow the enclave to modify the pages within the enclave. The enclave requests changes to the page, but may accept changes to complete the process.

<EACCEPT>
<Explanation of instructions>
The software in the enclave uses this instruction to accept changes to the SEC_INFO field. This allows SMAP to be updated with a new page type.

<EENTER>
<Explanation of instructions>
The EENTER instruction passes execution to the enclave. At the end of the instruction, the CPU is running in enclave mode with the IP specified by TCS oENTRY or oHANDRER. EENTER verifies that TCS is valid and can be entered. The TCS and the corresponding SSA may be resident in memory to continue the instruction. EENTER also checks the state machine to determine the type of entry and ensures that only one logical processor is active in the TCS at a time. FLAGS. TF has a slightly modified behavior on EENTER. FLAGS. TF is TCS. It is stored in SAVE_TF and then TCS. Loaded from TF. The next debug exception is FLAGS. Conditionally generated according to the updated value of TF. If the enclave is not in debug mode, debug register DR7 is set to TCS. Save to DR7 and clear. The same applies to IA32_DEBUGCTL MSR.

<RFLAGS. Behavior of TF>
FLAGS. At the start of execution of EENTER. The value of TF does not affect the trap at the completion of EENTER. FLAGS. Loaded from TCS. The value of TF determines if a trap has been taken.
<Behavior of DR7>
If the enclave is not in debug mode, debug register DR7 is set to TCS. Save to DR7 and clear.
<Behavior of IA32_DEBUG_CTL>
If the enclave is not in debug mode, TCS. IA32_DEBUG_CTL MSR. Save to DEBUG_CTL and clear.

<EEXIT>
EEXIT goes out of the enclave.
<Explanation of instructions>
EEEXIT disables the enclave mode and branches to the position specified by the RBS. The register is unaffected by this instruction. If the secret is contained in any of the registers, it is the responsibility of the enclave software to clear these registers. FLAGS. TF has a slightly modified behavior on EEXIT. FLAGS. TF is TCS. Loaded from SAVE_TF. Next, the debug exception is FLAGS. It is generated with the condition CR-0021 according to the update value of TF. If the enclave is not in debug mode, debug register DR7 is set to TCS. Load into DR7. This behavior and RFLAGS. What is the behavior of TF? ?? ?? It is detailed in.

<RFLAGS. Behavior of TF>
FLAGS. At the start of execution of EEXIT. The value of TF does not affect the trap at the completion of EXIT. FLAGS. Loaded from SSA. The value of TF determines whether to take a trap.
<Behavior of DR7>
If the enclave is not in debug mode, debug register DR7 is set to TCS. Load into DR7.
<Behavior of IA32_DEBUG_CTL>
If the enclave is not in debug mode, TCS. IA32_DEBUG_CTL MSR. Load from DEBUG_CTL.

<EIRET>
<Explanation of instructions>
The EIRET instruction takes advantage of the machine state previously stored in the SSA to resume execution of the enclave that was suspended due to an exception or interrupt. EIRET ensures that TCS is valid and resumable. The TCS and the corresponding SSA may be resident in memory for instructions to proceed. EIRET also checks the state machine to determine the type of entry and ensures that only one logical processor is active in the TCS at a time. FLAGS. If TF is set on EIRET, a debug exception will be thrown at the completion of the instruction (ie normal TF behavior). This exception is reported as occurring within the enclave (by the method defined in normal SE) and no instructions are executed internally. The TF may be set at the end of the EIRET, as the EIRET restores the RFLAGS from the SSA. In this case, the TF affects the following instructions (which is also normal TF behavior).

<RFLAGS. Behavior of TF>
RFLAG. If TF is set at the beginning of the EIRET instruction, it will occur after #DB is completed. Exceptions are reported in the RIP to which control was transferred if TF was not configured. In fact, no transfer processing is performed in the enclave. Restore FLAGS from an SSA copy as part of the normal processing of EIRET. If the resulting TF is set, #DB will occur after the execution of the target instruction in the enclave. These behaviors are consistent with the behavior of normal IA IRET instructions.
<Behavior of DR7>
DR7 is restored from the previously saved SSA copy with the last interrupt or exception.
<Behavior of IA32_DEBUG_CTL>
The IA32_DEBUG_CTL MSR is restored from the previously saved SSA copy on the last interrupt or exception.

<EREPORT>
The EREPORT instruction reports measurements regarding the contents of the enclave.
<Explanation of instructions>
EREPORT acquires the enclave measurement value register, its function, and debug status (flag). All of these values are protected using a symmetric message authentication code and can be verified using a REPORT key. In an enclave that requires a REPORT key, an appropriate function is set in SECS and can be obtained by the EGETKEY instruction. The result of this instruction is placed at the destination position output_buffer_la.

<ERDMR>
The ERDMR instruction reads the value of the measured value register from the enclave SECS.
<Explanation of instructions>
This instruction can only be executed from outside the enclave. If SECS points to a valid SEC page, the instruction outputs the contents of the enclave measurement register to the address specified by output_buffer_la.

<EGETKEY>
Used by the enclave code to return a specific key from the processor key hierarchy.
<Explanation of instructions>
The requested key is identified using the KeyRequest structure and its address is provided as an input. This address is naturally aligned. The output is always a 256-bit data value. To get this value, output_la needs to be naturally aligned.

<ERDTCSPTR>
<Explanation of instructions>
The ERDTCSPTR instruction is used to read the current TCS linear address into the RBX.

<EDBGRD>
<Explanation of instructions>
The EDBGRD instruction is used to read 8 bytes from the debug enclave.

<EDBGWR>
<Explanation of instructions>
The EDBGWR instruction is used to write 8 bytes to the debug enclave page.

<ERDINFO>
The ERDINFO instruction returns information about the contents of the enclave page cache.
<Explanation of instructions>
When run outside the enclave, EREPORT reports its functionality and debug status (flags) to the enclave measurement register. All of these values are protected using a symmetric message authentication code and can be verified using the EVERIFY REPORT instruction. The result of this instruction is placed at the destination position output_buffer_la.

<Routine reference>
<Exit>
This section provides pseudo-code for exit processing. This code is called when the enclave code has an unplanned exit from the enclave. Enclave execution resumes from where it stopped. The information needed to resume is saved on the external stack. The architectural state of the processor is saved in the appropriate save area.

<Acquisition of reader lock>
The RW lock allows the logical processor to access the shared resource and provide two modes in which the thread can access the shared resource. The two modes are: (1) Shared mode: Allows shared read-only access to multiple reader logical processors, which allows these multiple processors to read data concurrently from shared resources. Mode, (2) Exclusive mode: A mode that allows read / write access to one write logical processor at a time. When a lock is acquired in exclusive mode, other threads are writing. You will not be able to access the shared resource until you unlock it.

<Explanation of subroutine>
This subroutine is actually an addition of the hardware used when uCode exposes the PMH address-translation function to uCode. XUTRANSLATE is a uOP that mainly takes PMH context and linear address as input and generates the final physical address as output. If PMH encounters bad conditions during the page table walk, these will be reported to uCode. The details of uOp are outside the scope of this document.

<Explanation of subroutine>
This subroutine is used when generating a key by performing CMAC processing on a derivation buffer (DerivationBuffer) having the identified key. The derivation buffer must be a multiple of 128 bits.

Claims (11)

At least an instruction to dynamically access at least one information field, including a secure map (SMAP) field and a security information (SEC_INFO) field, to determine the integrity of the data stored in the secure enclave. A processor with execution logic to execute. It has an execution logic that executes an instruction to report the state of a secure enclave stored in memory to either a local agent or a remote agent.
The processor according to claim 1 . A crypto memory aperture (CMA) that protects the software program from attacks while the software program is running.
It has a secure map (SMAP) that protects the software program while it is not running.
The processor according to claim 1 or 2 . Includes execution logic that executes at least one secure enclave access instruction to allocate or deal with the corresponding memory or software thread in the secure enclave.
The processor according to any one of claims 1 to 3 . Equipped with SMAP, a hierarchical protection tree that allows multiple memory updates within a secure enclave in a single processor cycle
The processor according to any one of claims 1 to 4 . Has execution logic to execute instructions to provide a unique key to a secure enclave
The processor according to any one of claims 1 to 5 . Provides logic to execute instructions to build a trusted environment managed by an untrusted agent
The processor according to any one of claims 1 to 6 . It has the logic to execute an instruction to judge the validity of the license for accessing the secure enclave by comparing the size of the enclave with the size specified by the license certificate.
The processor according to any one of claims 1 to 7 . Includes control bit-controlled logic for secure enclave user-level policy management
The processor according to any one of claims 1 to 8 . Provide logic to execute at least one instruction to grant access to at least one instance of a secure enclave licensed to a user
Processor according to any one of claims 1 to 9. It has the logic to execute at least one instruction to compromise the enclave security of only the enclaves that are allowed to debug, which allows secure debugging of the enclave.
The processor according to any one of claims 1 to 10 .

Images