JP2019109910A - Processor - Google Patents

Abstract

To make it possible to obtain secure application and consistency of data in a computer system.SOLUTION: In a microprocessor 100, each of processor cores 105, 110 has a logic 119 for carrying out a secured enclave technique. Resources are effectively allocated between a plurality of cores or processors, thereby one or more secured enclaves which can store and carry out an application or data is established.SELECTED DRAWING: Figure 1

Description

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

  Ensuring the execution and integrity between applications and their data within computer systems is becoming increasingly important. Security techniques in the prior art do not provide flexible, reliable and appropriate provision of secure applications and data.

  Embodiments of the present invention are illustrated by way of example and not limitation in the accompanying drawings, in which like reference numbers refer to like parts in each other.

FIG. 1 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. FIG. 5 is a block diagram of a shared bus computer system that can utilize at least one embodiment of the present invention. FIG. 1 is a block diagram of a point-to-point interconnect computer system that can utilize at least one embodiment of the present invention. FIG. 1 is a block diagram of a multi-core microprocessor that can utilize at least one embodiment of the present invention. FIG. 7 is a possible implementation of a secure enclave (SE) of an embodiment of the present invention. FIG. 1 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. FIG. 6 illustrates an example of a control structure for accessing a portion of an enclave page cache that can be implemented in an embodiment of the present invention. Fig. 6 shows an example of a thread control structure in an embodiment of the present invention, showing the stitching of data structures; Fig. 5 illustrates one step of a software authentication process known as Quoting, which can be found in an embodiment of the present invention. Fig. 6 illustrates the steps for generating quotes from the measurement value register set, in an embodiment of the present invention. Fig. 6 shows an EADD process for updating the measurement value register MR_EADD in an embodiment of the present invention. 7 illustrates an EREPORT instruction that generates a report in one embodiment of the present invention. Fig. 6 illustrates a relay protection mechanism found in an embodiment of the present invention. FIG. 7 illustrates an example of a portion of a MAC tree structure of a relay protection mechanism found in an embodiment of the present invention. 7 illustrates an embodiment of the invention showing the implementation of a page fault error code map. FIG. 7 illustrates an example of a process of generating a permit to launch an enclave of an embodiment of the present invention. FIG. 16 illustrates an example implementation of a platform key hierarchy for secure enclave of a single package in an embodiment of the present invention. FIG. 7 illustrates an example of a microcode based secure enclave key hierarchy in an embodiment of the present invention. Fig. 7 illustrates an enclave CTL MSR register that can be found in an embodiment of the present invention. Fig. 6 illustrates a cipher block chain algorithm utilized in one embodiment of the present invention. FIG. 6 is a flow chart illustrating the encryption of a single AES block in one embodiment of the present invention. FIG. 6 is a flow chart illustrating an example of encryption of a plurality of AES blocks utilizing a cipher block chain algorithm implemented in an embodiment of the present invention. FIG. 7 illustrates one embodiment of an application and interrupt stack after being interrupted by a stack switch. FIG. 7 illustrates an example of a method of implementing a stack of state save area slots according to an embodiment of the invention. FIG. 7 illustrates a portion of a state machine having interrupt, fault, and trap state transitions in one embodiment of the present invention. 2 illustrates a processor package for a digital random number generator in one embodiment of the present invention. 7 illustrates a debug register DR7 2700 in one embodiment of the present invention.

Embodiments of the present invention relate to techniques for flexibly and reliably providing secure applications and data. While the present invention has multiple embodiments of aspects, the "Secure Enclave Architecture" appendix is incorporated herein by reference as at least one embodiment. However, the incorporated documents do not limit the scope of the embodiments of the present invention, and other embodiments are also available within the spirit and scope of the present invention. Here, an example of the invention concerning an embodiment is described.
[Item 1]
Execution logic for accessing protected data, at least executing a first instruction to move the protected data between the enclave page cache (EPC) and the system memory during execution of the program;
Translation Lookaside Buffer (TLB),
Equipped with
The TLB includes at least one bit indicating that at least one entry in the TLB is for enclave.
Processor.
[Item 2]
A Security Map (SMAP) is 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]
The execution logic executes at least a second instruction that informs the user's program of the entity of the software thread, which identifies the software thread being executed in the secure enclave.
The processor according to item 1 or 2.
[Item 4]
The execution logic dynamically accesses at least one information field including a secure map (SMAP) field and a security information (SEC_INFO) field to determine the integrity of 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 executes at least a second instruction to report the state of the secure enclave stored in the 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 the software program from attack while the software program is running;
The processor according to any one of the preceding claims, further comprising: a secure map (SMAP) protecting the software program while the software program is not running.
[Item 7]
The 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]
SMAP, a hierarchical protection tree that allows multiple memory updates to be made in a secure enclave in a single processor cycle
The processor according to any one of Items 1 to 7.
[Item 9]
The execution logic executes at least a second instruction that provides the secure enclave with a unique key,
The processor according to any one of items 1 to 8.
[Item 10]
The execution logic executes at least a second instruction to build a trusted environment managed by the untrusted agent,
The processor according to any one of Items 1 to 9.
[Item 11]
The execution logic executes at least a second instruction to determine the validity of the license for accessing the secure enclave by comparing the size of the enclave with the size prescribed by the license certificate.
The processor according to any one of Items 1 to 10.
[Item 12]
Execution logic performs secure enclave user level policy management 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 to grant the user access to at least one instance of the secure enclave licensed.
The processor according to any one of Items 1 to 12.
[Item 14]
The execution logic executes at least a second instruction for enforcing secure enclave debugging that violates enclave-only enclave security for which debugging is permitted.
14. The processor according to any one of items 1 to 13.
[Item 15]
Execution logic that executes at least one instruction to allocate or deallocate memory pages to the enclave page cache (EPC), respectively;
Translation Lookaside Buffer (TLB),
Equipped with
The TLB includes at least one bit indicating that at least one entry in the TLB is for 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 associated with local caches 107 and 113, respectively. Also shown in FIG. 1 is a shared cache memory 115 which stores at least a version of the information stored in each of the local caches 107 and 113. In some embodiments, microprocessor 110 may also include other logic not shown in FIG. 1 (eg, an integrated memory controller, an integrated graphics controller, and other such as I / O control within a computer system). It can also include logic to perform the function. In one embodiment, each microprocessor in a multiprocessor system or each processor core in a multi-core processor, in at least one embodiment, includes or is associated with logic 119 for performing secure enclave techniques. ing. By including circuits, software (implemented in tangible media), or both in logic, to allocate resources among multiple cores or processors more efficiently than some prior art implementations Can.

  For example, FIG. 2 shows a front side bus (FSB) computer system that can utilize an embodiment of the present invention. A local level 1 (L1) cache memory 220, any of the processors 201, 205, 210 or 215 including or associated with processor cores 223, 227, 233, 237, 243, 247, 253, 257 Any of 225, 230, 235, 240, 245, 250, 255 can be accessed. Furthermore, any of the processors 201, 205, 210, or 215 may receive information from the system memory 260 via the chipset 265, or from any of the shared level 2 (L2) caches 203, 207, 213, 217. You can access to One or more of the processors shown in FIG. 2 may include or be associated with logic 219 that implements the 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 utilized in conjunction with various embodiments of the present invention. For example, the P2P system of FIG. 3 can include several processors, of which two processors 370, 380 are illustrated. Processors 370, 380 may include local memory controller hubs (MCHs) 372, 382 to interface with memories 32, 34, respectively. Processors 370, 380 can exchange data via point-to-point (PtP) interface 350 utilizing PtP interface circuits 378, 388. Processors 370, 380 can exchange data with chipset 390 via individual PtP interfaces 352, 354 utilizing point-to-point interface circuits 376, 394, 386, 398, respectively. Chipset 390 may further exchange data with high performance graphics circuitry 338 via 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, shared caches (not shown) are connected to both processors via the p2p interconnect, even though they are included in processors outside of both processors, and if you want the processors to be in low power mode, either or both of these processors It is also possible that the local cache information of can be stored in the shared cache. The one or more processors or cores shown in FIG. 3 may, in at least one embodiment, include or be associated with logic 319 that implements secure enclave technology.

  One or more aspects of at least one embodiment can be implemented by representative data stored on a machine-readable medium representing various logic in a processor, which can be read by the machine Produce logic that implements the techniques described herein. A representation such as known as an "IP core" is stored in a tangible machine readable medium ("tape") for various customers or manufacturers to load into a manufacturing machine that actually manufactures the logic or processor. It may be supplied to the facility.

  Thus, methods and apparatus for directing micro-architecture memory area accesses have been described. The above description is intended to be illustrative and not limiting. Many other embodiments will be apparent to those skilled in the art upon reading and understanding the above description. Accordingly, the scope of the present invention should be determined with reference to the appended claims, and the full scope of equivalents that may be included.

A secure enclave is a set of instructions that provides an application a safe place to execute code and store data within the context of the OS process. An application that runs under this environment is called an enclave. Enclaves are implemented from the enclave page cache (EPC). Enclave pages are loaded into the EPC by the OS. Each time an enclave page is retrieved from the EPC, cryptographic protection can be used to protect the confidentiality of the enclave and to detect tampering when returning the enclave to the EPC. Within the EPC, enclave data is protected utilizing access control mechanisms provided by the processor. Table 2-1 below provides a complete list of non-privileged enclave instructions.

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

  Enclave page cache (EPC) is a place to execute enclave code to access protected enclave data. The EPC is located in the platform's physical address space, but access is only possible using SE instructions. An EPC may include pages from many different enclaves, and provides access control mechanisms to protect page integrity and confidentiality. The page cache maintains a coherence protocol similar to that used for the platform's coherent physical memory.

  EPCs can be instantiated in several ways. For example, it can be constructed from a dedicated SRAM on a processor package. Crypto Memory Aperture is known as the preferred implementation mechanism. This mechanism can increase the EPC. CMA is described in more 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 and the state of the page being loaded. When a page is retrieved from the EPC, state information is also exported and protected using cryptographic means. When reloading the enclave page into the EPC, the state information is verified.

  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. Core 400 may include CR3 402, SMBR 404, page miss handler 408, PMHE 410, and translation lookaside buffer 412. Core 420 may include CR 3 422, SMBR 424, page miss handler 428, PMHE 430, and translation lookaside buffer 432. In some embodiments of the present invention, microprocessor 499 includes 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 attach 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 store 486, and a portion 488 of physical address space.

  CMA is a mechanism that helps instantiate EPC, EPCM, and other SE related structures. An aperture is a region of physical address space that is provisioned for use in this purpose.

  The EPC and EPCM (and other implementation data structures) are mapped to a location within the aperture. Auxiliary storage is the actual data for these resources. Once the EPC's memory request is generated, the CMA remaps to the location of the auxiliary storage that contains the encrypted EPC data and gets 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 logic to control data movement.

  FIG. 5 is a possible implementation of a secure enclave (SE) of one embodiment of the present invention. The operating system and VMM 542 may load the enclave page of the enclave 532 into the enclave page cache 544 utilizing ELPG instructions 540. When the microprocessor is not executing in enclave 532, enclave page cache 544 is protected from software access by SERR register 532. When implemented within an enclave, the microcode page table provides protection 548. Each VM is associated with a VMCS. The VM 510 is connected to the VMCS 515. The VM 520 is connected to the VMCS 525. The VM 530 is connected to the VMCS 535. The SMM 500 may be in a separate container, and the processor state may be in a separate container.

  FIG. 5 is a high level schematic of one 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 not running within the enclave. Once in the enclave, control is transferred to the enclave code in the EPC contained in a separate container.

  Any page faults or exceptions that occur while executing within the enclave are reflected by the microcode to the relevant OS or VMM. If the machine is not running in an enclave, access control to the EPC is provided by the SE Range Register (SERR). If the machine is running internally, the microcode provides page table level protection to prohibit access to other EPC entries that do not belong to the enclave being executed.

  One way to implement a secure enclave is to take advantage of microcode capabilities in some processors to provide instruction and protection. This feature will meet the security requirements of securing the enclave's purpose.

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

  An option in the performance enhancing implementation is to provide a bit or bits to indicate that a translation lookaside buffer (TLB) entry is for an enclave or a specific 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 extra bits provide the function of the enclave space id. Specific enclaves may be assigned an id. The id is compared to the running enclave id as part of the address check. TLB support is one option for performance improvement. If an entry is invalidated in the TLB due to the removal of EPC data, a special microcoded shootdown mechanism is required. In one embodiment, the microcode contacts all other cores in the enclave trust boundary to make sure that the entry is not in any TLB. In other embodiments, the microcode may be provided with means to verify that another processor has invalidated the TLB entry.

  Special SAD and / or TAD entries are provided to avoid DMA snoops and invalidate for 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.

  Enclaves may be protected from tampering. The details of the mechanism used for tamper protection vary depending on the implementation. In this way, if the enclave is tampered with, further execution on the tampering detected thread is prevented. In order to make the user understand the state of the enclave, establish a verification mechanism to prove the enclave being constructed. This includes an EREPORT instruction that presents information on enclave content.

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

  The enclave state in the power cycle is dependent on the software policy. Data in the CMA is lost at power down. If it is desirable to save the enclave, software can ensure that the enclave data is not lost in the power cycle. The data resident in the EPC can be flushed to memory if the software wishes to keep the enclave alive during the S3 power state. The software can also make a choice to force the application to remove all enclaves on power loss.

  Enclaves are protected according to their position. Data outside the CPU package is protected using encryption and integrity checking. For code and data in the enclave page cache, pages are 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 having a plurality of processor cores 600, 605, 610, 615 and a cache 620. Enclave data 635 can be encrypted. Crypto memory aperture data 630 is used to protect enclave data 635.

  Enclave pages resident in system memory are protected using encryption and integrity. In loading a page into the EPC, the page is copied to the EPC and decrypted to check the integrity of the page. FIG. 6 shows this part of the data.

  Enclave pages resident in the EPC are stored in system memory and then encrypted using the enclave key. Authentication information is also stored at the time of page storage. Enclave data in the EPC is unencrypted and protected by the access control mechanism. The processor protects this data so that only the enclaves with ownership of the data can access it.

  Enclave pages residing in the EPC are protected by CMA encryption when they are forcibly moved from cache to main memory outside the CPU package. The CMA encrypts this data to achieve data confidentiality. The integrity of the EPC is provided by a range register that prevents reading and writing to the EPC.

  FIG. 7 illustrates an example of a control structure for accessing a portion of an enclave page cache that can be implemented in an embodiment of the present invention. Each page of enclave page cache 720 may have corresponding metadata in enclave page cache map 710. In the metadata shown in FIG. 7, when the secure enclave including 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 You can access to

  FIG. 7 shows the placement and use of EPC and EPCM. The EPC is divided into 4k pages. Each enclave may have some number of 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 embodiment.

  If the application wants to load the enclave, it calls the OS's system routine. The OS tries to allocate several pages in the EPC. If there is no free place, the OS chooses to remove the victim enclave. The OS forces the victim enclave pages to be evicted using the EWBINVPG instruction for each page. When the OS completes the forced removal, add secure enclave control structure (SECS) to the enclave using ECREATE command. After generating the SECS, the OS adds pages to the enclave as requested by the application through the use of the EADDPRE instruction.

  To add data pages to the enclave, the OS first adds SMAP pages to the enclave using the EADDS MAP instruction. Depending on the size and placement of the enclave, the OS may allocate multiple SMAP pages. When all the enclave pages are added to the enclave, the OS executes the EINIT instruction to execute the enclave. The parameter to the EINIT instruction is a certificate indicating that the enclave is authorized to execute on that machine. At the time of loading the application it is necessary to generate a permit. If EINIT completes successfully, the application can execute the EENTER instruction to enter the enclave.

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

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

  In some cases, software may wish to modify the characteristics of the enclave memory. In order to do so, it is necessary to update SMAP. For example, consider the case where software tries to create another thread entry point, TCS, in an enclave. In this case, the enclave requests the OS to change the SMAP properties of the page using the EMODIFY instruction. After the property is 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 for page removal, it sends a request to the OS. The OS executes the EREMOVE instruction to remove the page from the SMAP. The EREMOVE instruction also performs the invalidation of the EPC entry.

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

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

  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 is in the linear address range covered by the 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 accesses to the EPC range are considered illegal.

  Enclave access may be resolved to the physical address belonging to the EPC. If the access is outside the EPC but the linear address indicates that the address is in the enclave, the access may be halted. Defects or orders for the OS report.

  Access to addresses in the enclave can be located in the EPC for successful access. Checking if an entry is present in the EPC is usually done by checking the EPCM and verifying valid bits. Each EPC page is dedicated to a specific enclave. Reference to that EPC entry is only possible by the enclave that owns the EPC page. This can be checked by verifying whether the referring enclave SECS matches the reference page.

  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 a linear address at which the enclave page is introduced into the EPC. If the enclave access is resolved to an EPC page, the linear address introducing the page matches the linear address of the current request.

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

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

  When the OS / VMM loads the relay protected enclave page into the EPC, the FCR (fresh check requested) bit is set in the EPCM entry of that page. The OS / VMM can clear this bit by executing the EUPSMAP instruction on the EPC page to clear this bit. Enclave access continuation is allowed only if the FCR bit of this page is not set. Otherwise, the LP sends an EF_FRESH_CHK fault to the OS / VMM.

  Each EPCM entry contains a "dirty" bit that indicates whether the enclave is allowed to write to the page. Writing to an enclave enclave page is only allowed when the dirty bit for that page of the EPCM is set. Otherwise, LP issues EF_EWRITE to the OS / VMM. The OS / VMM can set the dirty bit by executing the EUPSMAP instruction on the page.

  Whenever a logical processor is executing in an enclave, that enclave's SECS page may be present in the EPC. However, according to the SE security model, enclaves are not permitted to perform direct memory access to their SECS (although enclaves can read their enclave keys on the premise that they are completely security threatening). If the enclave access is resolved for the EPC page that holds the SECS for that enclave, then the OS / VMM is notified via the EF_ATTRIB_SECS fault. Enclaves are not allowed to modify pages with TSC attribute sets. When the enclave attempts to modify the TCS loaded into the EPC, the OS / VMM is notified via the EF_ATTRIB_TCS fault. In the size fields in the following table, 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) and values and indices can be used.

  Note: Some fields have names starting with the lower case "o" (e.g. 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 of the enclave page to be independent of the position at which the enclave was generated.

Note: The fields are not (yet) listed in a particular order. Some fields may be moved to different memory pages in the data structure of interest, which allows, for example, different protection measures.

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

Each thread is associated with a thread control structure (TCS). TCS includes:

The thread state can take one of five values.

<State save area offset (oSSA)>
State Save Area Offset (oSSA) points to a stack of state save frames that are 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 processor state to an interrupt or exception that occurs during execution in the enclave. This is an index into the frame array that the oSSA addresses. The save area (CSSA) count specifies the number of SSA frames available to this TCS. If an interrupt or exception occurs and there is no more SSA frame available (NSSA> = CSSA), the interrupt or exception can still occur and the processor state is cleared but TCS is invalid (INVALID) Displayed as being.

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

  TCS :: SSA is not paged out when an interrupt occurs. EENTER caches the physical address, checking that the SSA is in the EPC. If the page is forced to move, the processor executing EWBINVPG uses SSA to cause the thread executing processor to exit the enclave and report a page fault.

  FIG. 8 shows the stitching method for all data structures. For the sake of brevity, the respective structures of all threads are not shown. Untrusted Stacks and their associated pointers are also omitted. FIG. 8 shows an example of a thread control structure according to an embodiment of the present invention, showing the stitching of save state areas. State save area pointer 800 points to save area 0 820. The current state save area 805 points to 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 available save state areas.

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

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

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

The SEC_INFO flag and the EPC flag contain bits that indicate the type of page.

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 cryptographic metadata necessary for forgery protection.

A certificate (CERT) is a certificate structure provided with an architecture enclave, which 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 measurement values (MEASUREMENTS) are output parameters of the ERDMR instruction, and include measurement value register values (Measurement Register values) of the enclave taken from the designated SECS.

The key request (KEY_REQUEST) is an input parameter to the EGETKEY command and is used to select the appropriate key and any further 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 details on TCB security version structure, please refer to platform TCB return specification.

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

An 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 into the EPC.

  Attestation is the process of indicating to a remote entity that one piece of software is built on the platform. In the case of a secure enclave, the remote platform operates on the legitimate platform protected within the enclave before the software is verified for confidentiality and data protection. Is a mechanism built by remote platform. The proof process consists of three steps: measurement, storage, and reporting.

  During the enclave measurement period, there are two periods: pre-enclave construction and post-enclave construction. Enclave instructions play a role in measuring the constructed enclave. Once the enclave is built, the software in the enclave is responsible for measuring.

  FIG. 9 illustrates one step in the software authentication process referred to as queuing that can be found in one embodiment of the present invention. In one embodiment, signature processing 910 applies signature key 915 to the concatenated data from measurement value registers 901, 902, 903, and 904. The result of the signing process 910 is a 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 "quoting" because this type of functionality is sometimes made available to the platform as TPM commands. The values of the measurement value register (MR) are concatenated and then signed using an asymmetric key. The opposite party simply needs to verify the signature in the quote structure to establish the legitimacy of the quote.

  FIG. 10 illustrates the steps for generating quotes from the measurement 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 quotation enclave 1025 may include software that converts the local report 1005 into an anonymous quote 1010 or a regular quote 1020.

  Due to the nature of computations regarding asymmetric keys and because of the desire to reduce the number of instructions in Enclays Briefs, we will not include the instructions that cause asymmetric signatures. In our approach, shown in the figure below, we generate "reports" based on symmetric key authentication keys and use "enclaves" to protect "reports" based on these symmetric keys. To convert them into asymmetric signature "quotes". Because the Quating Enclave must first be authenticated before it has access to the platform certification key, the Quoting Enclave itself is a special-purpose enclave known as an Authentication Enclave.

  Each enclave provides two 256 bit wide measurement value registers (MR_EADD & MR_POLICY) and two absorbed registers. These measurement value registers are included in the enclave's SECS.

  FIG. 11 shows the EADD process of updating the measurement value register MR_EADD 1100 in one embodiment of the present invention. The extension process 1115 can use the current value of MR_EADD 1100, page data 1105, and page metadata 1110 as input. The output of the extension process is MR_EADD'1120, which is the next value stored in MR_EADD1100.

  Since MR_EADD is constructed using the EADD instruction before the EINIT instruction is called, it includes enclave set metrics. Since this is written by microcode, the enclave code needs to be placed on the SECS page which can only be read. Each time EADD is called, it calculates SHA256 to the page data and the security metadata associated with the page (ie it is the relative address (to the base address of the enclave) of the page and the SEC_INFO flag of the page) , Extend this value to MR_EADD1100. “Extended” means that the new MR value = hash (old MR value || input value).

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

  FIG. 12 shows an EREPORT instruction that generates a report in one embodiment of the present invention. A key ID 1200, an owner epoch 1205, a package fuse key 1210, and a fixed string MAC key 1215 may be input to the derivation instruction 1220. The output of the derivation 1220 may input the CMAC 1225 along with the TCB version 1232, the ISV version 1234, the function 1236, the flag 1238, the user data 1240, and the current value of the measurement value register 1242. The output of CMAC 1225 can be stored in MAC 1244. 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 value register 1242, and MAC 1244.

  The EREPORT instruction generates an intermediate key to do symmetric key based GMAC on the measurement value register, user data, and additional context information (eg, enclave functions and flags).

  In addition to the measurement value registers, the user can provide 256 bit wide data blocks to be included in the report. The user desires 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, the EREPORT is called repeatedly to generate a random 128-bit value (known as reportKeyID) at each processor power cycle and store it in an internal location. This value is incremented after 2.sup.32 AES 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 to see if the challenger may trust the enclave, so it can be used to determine certain state information about the enclave or when invoking the EREPORT instruction. .

Table 5-4: Flags

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

An ERDMR (measure reading) instruction is provided to obtain enclave measurements when running outside the enclave. This instruction takes a pointer to a valid SECS page and a pointer to the address to which the measurement value is delivered. The measurements are distributed in the form of a MEASUREMENT structure. The MEASUREMENT structure is not cryptographically protected.

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

  FIG. 13 illustrates a forgery protection and replay protection mechanism that can be found in one embodiment of the present invention. Counterfeit protection prevents an attacker from replacing the encrypted data not generated by the program with another value of the data. Replay protection prevents an attacker from replacing with the value of encrypted data that is not the current up-to-date value generated by the program. Node version number 1300 may enter IV 1310 and then enter the GMAC 1325 algorithm. The version number of child 1305 can send data 1315 to the GMAC 1325 algorithm. The GMAC 1325 algorithm combines the key 1320, IV 1310, and data 1315 to generate the MAC 1330.

  Replay protection ensures that all content of the enclave that the logical processor sees at any given time belongs to a single snapshot of the uncorrupted enclave. Therefore, the replay protection mechanism needs to define the concept of the enclave version to provide a mechanism to determine whether the forged protected enclave page belongs to that version of the enclave. To this end, the replay protection mechanism ties the contents of each forged protected enclave page to a page version number using a message authentication algorithm such as GMAC. In the case of GMAC, this version can be used as part of the initialization vector (IV) shown in FIG.

  FIG. 14 shows an example of a portion of the MAC tree structure of the relay protection mechanism found in an embodiment of the present invention. Leaf nodes 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. The root 1400 is the top node of the tree data structure.

  In order to extend the versioning for all enclaves, the playback protection mechanism maintains a version tree. Leaf nodes contain versions of individual replay protected pages of the enclave instance. As each internal node provides a version of each group of children, it logically holds the version information of the page that they represent. Figure 14 illustrates this concept.

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

  Reproduction protection requires forgery protection, as reproduction protection requires that each page version be cryptographically linked to its content. Therefore, forgery protection is essential in the SE architecture. Furthermore, implementing SE from scratch may further limit the list of supported protection combinations.

  The OS / VMM generates an enclave by executing the ECREATE command. During generation of the enclave, the range of linear addresses protected by the enclave is identified. This linear address range is known as the enclave linear space (ELS) range.

  Once the enclave is created, the 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 into the enclave protected area by moving those pages into the enclave page cache. If any of these pages are located outside of the EPC using EWBNVPG, the logical processor will provide cryptographic protection to these pages.

  Cryptographic protection is achieved by associating cryptographic metadata with each enclave page. The metadata is used by the flow of uCode to enable various processor instructions to decrypt the contents of the enclave page and to verify the reliability / freshness of each enclave page. The SE architecture provides some 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 hold cryptographic metadata that needs to be decrypted and verified for the page. The various fields of the SEC_INFO structure are as follows:

The security information flag (SEC_INFO.Flags) describes the page type, encryption and access protection of the page being protected.

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

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

  In general, at depth l> 1, bits N- (l) x8 to N- (l + 1) x8 + 1 are used to select the appropriate child at the next level.

  Note: The security map is a logical data structure, not an architecture. The logic processor does not even know about the location of the linear address space where the SMAP is located. System software is responsible for maintaining and walking security maps. Each individual node of the security map has an architecture defined structure, 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 location in the security map, and various processor instructions for the security map attack it if the node moves around in the map. Note that it is interpreted as a scenario.

The root security node is included in SECS and contains version information of 128 children. 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 of 256 children.

  SEC_INFO contains the position of SMAP in 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 replay protected enclave page, the SMAP's parent needs to be created and reside in the EPC with the FCR bit cleared. To verify the integrity of the enclave page, the logical processor generates keys using IV_P and key_id in the SEC_INFO structure. This key is used to calculate the MAC for the SEC_INFO structure and the flags in the content of the page. The calculated MAC is compared to the MAC provided in the SEC_INFO structure. If the MACs match, this page can be considered to pass the consistency check.

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

  To verify the freshness of the enclave page, the logic processor verifies that the enclave page and its smap's parent have been loaded into the EPC and that the smap's parent is fresh. Then compare the version of the page with the version stored in the parent of smap. If these two versions match, the processor generates a new version of this page to update the parent version of the smap and the enclave page version. Finally, show the enclave page as fresh.

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

  To remove the enclave page, the logic processor verifies that the enclave page and its smap's parent have been loaded into the EPC and both are fresh. Then, set the version of the smap's parent page to 0, indicating that the EPC slot of the enclave page is available.

  Enclave page cache (EPC) is a secure storage that the CPU uses to temporarily store enclave pages that are not cryptographically protected by SE cryptographic protection.

  The following requirements are identified in the EPC: Access to enclave memory pages loaded into EPCs belonging to non-debug enclaves can be protected from modification by software entities outside the enclave. Attackers can not read plaintext data belonging to non-debug enclaves loaded in the EPC with direct hardware attacks. Also, attackers can not modify the data of EPCs belonging to non-debug enclaves with direct hardware attacks. The system's CPU can coherently and securely access the data loaded into the EPC.

  There are several mechanisms to implement EPC. The EPC can be implemented on an on-die SRAM or eDRAM. The EPC can also be built by dynamically isolating the CPU's final level cache approach. In this implementation, the EPC can be protected from unauthorized access from outside the package. Meanwhile, other packages in the system can access the EPC coherently and securely.

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

  The SECS is said to be active when currently loaded into the EPC. As described later in this document, the OS / VMM is responsible for managing what is loaded into the EPC. However, while loading the enclave page into the EPC, the OS / VMM informs the CPU of the SECS's whereabouts of the page except when the target page itself is SECS. If the page being loaded is not a SECS, the CPU requests that the SECS corresponding to the page be placed in the EPC. At any time prior to loading an enclave page, the OS / VMM MAY load the enclave's SECS into the EPC.

  The CPU imposes no restrictions on the number of times that the SECS can be loaded into the EPC, but it is likely that the OS / VMM will load multiple copies of the SECS into the enclave page cache frequently. Very Hard to think. However, if multiple copies of the same SECS are loaded into the EPC, then each of these copies is considered as a separate active SECS instance, and enclave pages loaded into EPCs belonging to different instances of active SECS can be It is regarded as belonging to different enclaves depending on the wear.

The OS / VMM sees the EPC as a contiguous block of physical memory in system address space (10). However, in order to reduce internal storage and allow for a fast index, 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 one another as follows.
sid = (page_pa-epc_base_pa) >> 12
page_pa = pc_base_p | (sid << 12)

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

  All enclave pages loaded into the EPC have a well-defined system physical address. Because there is a one-to-one mapping between the physical address belonging to the EPC and the EPC slot identifier, each page loaded into the EPC could be said to have its own EPC slot identifier or EPC_SID.

  In addition, all enclave pages loaded into the EPC, except the SECS pages, are associated with the active SECS instance. Recall that the active SECS instance is only the 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. The hardware keeps a record of SECS_SID for each page loaded into the EPC. The SECS_SID of the SECS page loaded into the EPC is defined as 0xFF (or invalid SID).

  The EPCM is a secure structure that the processor uses to track the contents of the page cache. The 30 EPCM holds exactly one entry for each page currently loaded into 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, the version of the page, and so on. The EPCM structure is utilized by the CPU in the address translation flow to perform access control on enclave pages loaded into the EPC. EPCM entries are managed by (x) uCode as part of various instruction flows.

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

  In one embodiment, hardware logic may control access to memory utilized as an EPC by means of a translation lookaside buffer (TLB) and a page miss handler (PMH). In one embodiment, the secure enclave may flush the TLB as it exits the EPC when there is a match for the search address in the TLB (known as a TLB hit). In one embodiment, if there is no search address that matches the TLB (known as a TLB miss), then further lookup may retrieve data from the Enclave Page Cache Map (EPCM) at 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 the continuous physical address, EPC. 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, then compare the secure enclave control structure identifier (SECSID) of the page with the currently executing enclave to ensure that the access is secure. You may If the SECSID of the return page does not match the one of the currently executing enclave, the PMH may issue a stop message. If the return page of memory is not displayed as an enclave page, or if the return page of memory is displayed as an enclave page and the SECSID of the page matches that of the executing enclave, then PMH will The translation 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 type of memory request accesses the EPCM during a write back cycle.

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

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

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

  Memory pages that belong to a certain enclave linear address range are also referred to as "enclave pages". Programs running within the enclave are only allowed access to the enclave page that is loaded into the enclave page cache and is the enclave owner of the page. The processor generates an exception class event if this is not the case. The OS / VMM is responsible for loading the enclave page into the EPC as needed.

  If the logical processor is executing an enclave and generates a memory access to the enclave page, this memory access is referred to as "enclave access". A dress check may be performed to make sure that the correct entity is being accessed.

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

In some embodiments, coordination may be made between many axes such as performance, implementation complexity, cost of silicon. In this chapter, three implementation examples are introduced to show the developer some of the possible tuning examples. Table 8-1 below shows examples of these protections and the required PMH support.

  As shown in the first row of Table 8-1, there may be one additional range register to provide the necessary access control protection. In this particular implementation, other protection is provided by Micro. Range registers may be enabled per logical processor. A basic implementation using this mechanism is shown in Figure 2-2.

  The PMH is modified to remove access to the LP to CMA range (covered by the CMRR of the CPU) that is not running in microcode mode or in enclave mode. In addition, LPs running in enclave mode are only allowed access to the EPC sub-range of the CMA.

  FIG. 15 shows an embodiment of the invention showing the implementation of a page failure error code map. If bit 51540 is set, then bit 9, bit 8, bit 7, bit 6 can be decoded together to determine a page fault 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 certain page is not found in the EPC, a "bad" is provided to the OS / VMM to indicate that. As shown in Table 8-2, the page failure error code map is changed. This indicates a new bit that is used to report a bad condition. If there is no EPC failure, bit 5 is set to zero and bits 6 to 9 are also set to zero. If the failure is due to an EPC condition, bit 5 may be set and the software may decode bits 6 through 9 to resolve the EPC failure condition. Further information on defect types is provided in the next section.

If bit 5 of the page fault error code is set, then bits 6 to 9 are interpreted as given (Table 8-2). This indicates the condition that caused this page failure. Some of the states indicate illegal conditions that may not occur in normal processing, and indicate OS / VMM management errors.

  To protect the EPC from attacks, a mechanism can be used to invalidate the EPC addresses of all TLBs in the platform. This feature allows all cores to be notified of the invalidation of a particular page. It then waits until it receives a shoot complete report from all processors.

  Each time an enclave exits (EEXIT), the TLB may may not allow access to the enclave pages currently present in the TLB. This can be done by clearing the TLB or by tagging the enclave entry using additional bits.

  Another way is to use the enclave bit in the TLB at enclave exit to clear all enclave entries. Another way is to use a few bits to identify a particular enclave. In this case, enclave entries do not have to be forcibly removed. Enclave entries may be left in tlb. When sending the address to tlb for lookup, these bits are added to the lookup. These bits are compared to the enclave id from the core that indicates the enclave's identity. If the bits match, then the request is coming from this enclave. If not, the lookup will not hit this location as the request will not be from this enclave.

  Enclave certification provides a means of finding the authorizing authority (ie, the author / author of this code) that has been authorized to execute the enclave code within the enclave. Enclave certification also provides a foundation to entrust implementation points of Enclave Microcode Flow, Flexible Seals & Reports, and several new business models.

  Certain aspects of the secure enclave architecture may require complex and time-consuming flows that are not well suited to implementation within microcoded instructions. The solution to this is to outsource these parts of the secure enclave architecture to microcode. In many cases, delegated code requires special access to delicate processor or platform data. For example, the EPID signal is too long for a single instruction. Instead, it generates an EPID signed quote by allowing special access to the EPID private key using a Quoting Enclave. Enclave authentication allows Intel to identify additional features that are authorized to a special enclave, such as access to EPID keys, by only the quarts enclave. The enclave provided by Intel has additional functionality and implements the core enclave functionality, but is referred to as an architectural enclave.

  Enclave Seal Storage provides the enclave software with the ability to encrypt data to certain attributes (eg, load time measurements) of the enclave. The enclave proof framework allows the enclave to provide the external entity with evidence of the enclave being measured. In many situations, it may be desirable to seal the data or prove to the source of the enclave rather than the exact software hash of the enclave.

  In one embodiment, once the signature in the certified enclave is verified, the public part of the key used to sign the enclave is made available to the seal & certification mechanism, so that the merchant can not measure the enclave It allows you to choose between strong protection based on values and more flexible protection based on the source of the enclave code.

  Enclave certification is divided into two parts. Each enclave is accompanied by an enclave license that has a signature chain that can be rooted back to Intel on Intel. The enclave license indicates the source / responsible entity of the enclave, the special features that the enclave needs, and the additional information needed to identify the particular business model / arrangement that will implement the enclave. The license may be for a special enclave, which indicates the measurement of this enclave or indicates for the key, which will later be able to sign the enclave as required .

  For example, consider the case where A purchases a license to produce an enclave for use with A's video player. To this end, Intel generates a license for the root key of vendor A's video player and the features Intel is authorized to use for vendor A's video player enclave. Vendor A then uses the video player's root key to sign an individual license file for each video player modification to be released. This will result in the enclave license chain including multiple intermediate licenses.

Since the signed license chain is not ideal for evaluation during the enclave activation process, instead, they are a single instruction easy-to-implement structure called permit. Incorporate into the digestible structure). The permit is symmetrically authenticated using the CMAC algorithm and interpreted during enclave initialization (EINIT).

  Most of the license part is copied to the permit and forms a similar structure. The license ID is a 64-bit number for identifying a business arrangement. The type of license specifies the platform to which the license applies. The bulk license allows this enclave to be launched 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 the 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 deployed for billing purposes. The ISV that licensed this enclave can also build a security version number for this version of the enclave. In this way, the data that this version seals can be made available for future versions rather than previous ones. The flag field indicates a flag for enclave that may be set to apply this permit. The feature mask is a bit mask of special features that can be granted to this enclave. The parent's key hash is the hash of the public key that has been signed with this enclave license and hashes the key with the signed public 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 the value of EADD. In the license key, this is a hash of the public key.

  In a license, the license itself includes the public key used to sign the license. The permit is MAC using the CPU key. The genuine cpuMAC indicates that the EMKPERMIT command has this permit, and that the license chain is now certified against Intel. If the type of license is not bulk, the license MAC indicates that the architecture license enclave has contacted the appropriate license authority to confirm that this platform can launch the enclave.

  Not all enclaves require a permit. To facilitate the development of enclaves, permit is an option during development and during the debugging phase of the software life cycle. The following policies are enforced by EINIT. Non-debugging enclaves always require the launch of a permit. Debug enclaves are launched without a permit. However, if EINIT is not presented with a permit, MR. Set Policy, ISV Sec version, Permit See Version, and all features to 0.

  If the permit is used for launching a debug enclave, the permit-> flag "debug" can be set, and only the function permitted by the debug enclave can be set to the permit.

  FIG. 16 illustrates an example of a process of generating a permit to launch an enclave of one embodiment of the present invention. This process can have three phases (Permit Issue 1600, Additional License Approval 1640, and Initialization Enclave 1680). In the permit issuance step 1600, an ISV key permit 1615 may be generated by executing the EMKPERMIT instruction 1612 on the ISV key license 1610. An enclave permit 1625 having a MAC only for the CPU can be generated by performing an EKPERMIT instruction 1612 on the enclave license 1620 and the ISV key permit 1615. In a further license approval step 1640, an enclave permit 1625 having a MAC only for the CPU, and a third party enclave 1642 corresponding to the information to be licensed enter the license enclave 1644, and the license enclave 1644 controls the MAC for the CPU. And generate a licensed enclave permit 1645. At the initialization enclave 1680 stage, enclave SECS 1682 and a MAC and licensed enclave permit 1645 for the CPU may be input to the EINIT 1684 instruction. The output of the EINIT 1684m is an ISV enclave 1685.

  To activate an enclave, a license can be generated from a 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.

  Generate a permit from the license using a new instruction called EMKPERMIT. Although EMKPERMIT generates a single permit from a single license, it can also be used to convert a chain of licenses into a single permit with a MAC using a permit key, by being called sequentially it can. The next section will elaborate on this.

  Each license includes a "type of license" which determines further steps that can be taken to make the permit available. The per platform license requires the cloud licensing authority to maintain the charge for the platform on which the enclave is deployed. This type of license requires additional steps. That is, an architecture enclave, referred to as a license enclave, negotiates with the cloud licensing authority and, if approved, provides an additional MAC for the permit using the license key. For example, the architecture enclave is always a bulk license, which means that no license key MAC is required to execute. These run on any platform that supports secure enclaves.

  A permit is implemented in the enclave initialization. If the permit is processed during initialization and the enclave measurements match those in the permit, then the MAC will be correct and the enclave will be activated. EINIT looks at the type of license and examines only the license MAC of the license requiring further approval.

  EMKPERMIT is a privileged instruction due to the time required to verify the RSA signature on the license. This instruction validates and takes a very simple signed certificate that 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 Intel's license signing key to authorize the Intel-signed license. The EMKPERMIT can further authenticate the license signed by the ISV key by providing an authorized approval of the key. This is done by creating a permit that contains the hash of the ISV's public key. As a result, EMKPERMIT can verify Intel's license using Intel's license, 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 null and an internally hard-coded set of permit parameters is used. The architecture enclave license is generated using a calling method to validate the license. EMKPERMIT ensures that the public key of this license is authorized by uCode (by comparing the hash of the contained public key with the internal hash).

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

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

  The license enclave is designed to make decisions about enclaves that are activated outside of what uCode can see. For example, uCode will assess whether further enclave placement is permitted by arrangements in business with ISV's Intel. The license enclave is designed to collect all the material that needs to be assessed and to further approve or reject the enclave activation. License enclaves need to support only complex business arrangements, not bulk licenses (eg, the ability to launch an enclave on any platform as many times as needed).

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

  Once a permit is issued for the enclave, it can be evaluated and implemented using u-code in the enclave maneuver process. This is implemented as part of the EINIT instruction, using the linear address of the permit as a parameter. (1) copy the scratch pad permit, (2) verify the cpu MAC 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 measurement value in the permit is recorded in MR. (5) compare the flag in the permit with the flag in the SECS, (6) compare the Pubkey hash in the permit with the MR. The additional steps of copying to Policy, (7) copying ISV SVN to SECS, and (8) copying functional map in permit to SECS, are added to EINIT as part of the certified enclave mechanism.

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

  Spaces are organized based on the actions that EINIT takes. Bits 00-03 are reserved for future use when ring level constraints become active on this enclave. 04-07 are reserved to indicate page protection to be permitted in the future. 08-23 are processor keys available through EGETKEY. 24-31 are for other controls (e.g., for techniques that use name-based mode for proofing, or for which technology wants to be restricted in the future) Some features are not used by the enclave in debug mode. The debug column indicates whether a certain function is used in the debug mode and it is legal.

  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 to be performed in VT root mode. At each EENTER, compare the current CPL to bits 01-02 to determine if this enclave is allowed to execute 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 enter from VT root mode while bit 03 is awake. In the first generation, these bits are MBZ.

  Enclave pages may be encrypted or only integrity protected. Furthermore, the page may or may not be executable. In future generations, these attributes can be tracked and implemented in the security information portion of EPCM. Function bits are reserved to control the use of encryption on the enclave enclave page based on whether the page is workable or the enclave is already EINIT.

  Many architecture enclaves are ring 3 entities that require access to the CPU or key protected by the CPU. EGETKEY provides access to these keys, and feature bits are used by EGETKEY to determine if access to the key can be granted.

  The following is a list of current architecture enclaves with these characteristics and a short description.

  The Provision Enclave has the KEY_PROVISION feature, is approved by Intel, and runs on a single packaged platform whenever a new Device Certification Key (DAK) or Provision Certification Key (PAK) is needed. Ru. The purpose is to have the enclave derive a 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, the Provision Enclave authenticates with the Platform Proof Key (PAK) provider, optionally using the DAK, and retries the PAK. The use of PAKs can provide better privacy for users by guaranteeing for a particular ISV, and that activity will not be associated with that of the previous owner of the platform. After obtaining the PAK, the Provision Enclave seals it so that the Quating Enclave can obtain it.

  The Quotating 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 EPID keys. Its location is an OS service that is available to all apps. The purpose is to have the enclave unseal the platform EPID key. Reports from EREPORT are provided as input. The enclave uses EGETKEY to obtain a report key. The report key is then used to validate the report. Enclaves sign quotes through the use of EPIDs.

  The license enclave has a KEY_LICENSE function, is licensed by Intel, is signed by Root Intel, is shipped with the enclave (OS service) and is instantiated alone. Its purpose is to evaluate complex license policies. If the enclave requests a further license confirmation from the license enclave, EINIT can only accept it after the license enclave CMACs its permit using the license key.

  In a single package system, all symmetric keys utilized 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 the structure is a consistent SE key hierarchy across all secure enclave implementations. The keying material for TCB reversion and the basis of the EPID provision is provided by the SE TCB hierarchy which serves as the root of the SE key hierarchy. All keying materials utilized in both the enclave instruction set and the trusted architecture enclave are provided by the SE key hierarchy.

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

  The architecture enclave key 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 re-provisioned using one of the keys derived from the key hierarchy after placement. The method of provision of the EPID certification key is outside the scope of the present specification. For more information, see Device Certification Key (DAK) Provision Specification.

  Finally, Enclave's architecture also uses the keys in all processor logic to provision keying material at the OEM. This key is known as the Out-of-Box Experience Global Key. We perform a similar derivation on this key to provide the ISV's uniqueness. The use by ISVs of these keys derived from OOB keys is beyond the scope of this document.

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

  FIG. 17 shows an embodiment of the invention showing an implementation of a platform key hierarchy for secure enclave of a single package. An out-of-box based key 1700 is derived 1702 from available derived resources 1750 and an out-of-box key 1704 is generated. The available derived resources 1750 are strings with elements including unique value 1752, owner epoch 1754, secure enclave security version 1756, SECS metering register 1758, ISV security version 1760, and SECS flag 1762. The provision key 1710 can prove the legitimacy of the platform to the Intel backend. The EPID ID 1712 is a signature key. The initial safeID keyblob 1718 is a quote and is associated with the safeID seed 1716. The base ops key 1714 is combined with information from the available derived resources 1750 into a series of keys including an enclave key 1730, a permit key 1732, a license key 1734, a report key 1736, an authentication key 1738, and a seal key 1740. Can be derived 1720.

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

  Secure enclave instructions and data structures rely on the base key being the source of keying material. The platform key hierarchy shown in Table 12-1 is a description of the hierarchical relationship of the platform key material and how to derive the key from the platform root key.

  Enclave wrapping key 1752 is a symmetric key used to encrypt secure enclave control structure (SECS) pages while not protected in the enclave page cache (EPC).

  The Permit Key 1754 is used to provide legitimacy and integrity to the Permit, including Enclave function and license information. The permit is MAC and its integrity is verified during the transition to EINIT. This key is used by EMKPERMIT uCode and EINIT.

  The license key 1756 is used to assert in accordance with a license policy that can not be evaluated by uCode (is used assert compliance with). The license key is used to generate a certified authorization from the license enclave that EINIT evaluates. This key, which EINIT uCode uses, is available via EGETKEY and is enclaved with the KEY_LICENSE feature set.

  Report key 1758 is used to provide report legitimacy and integrity. The reports are MACd by ERREPORT to ensure integrity while transitioning to a Qualing Enclave. This key is utilized by the EREPORT uCode and is available via the EGETKEY to enclaves with the QUOTE feature set.

  The authentication key 1760 is an enclave-specific key and is used to provide legitimacy and integrity of the data sent from the quarting enclave to the ISV enclave, and provides enclave to enclave authentication on the same platform. Keys are available to all enclaves via EGETKEY, and enclaves with the ISV_AUTH feature set can identify the keys they need.

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

  The EPID ID 1712 uniquely identifies a package. Its sole purpose is to enable the provision of a device certification key, which is an EPID-based anonymous certification key. The EPID ID is accessible only to provision enclaves. The provision enclave provides this over the secure channel only to the approved provision server, but only during the user or operating system initiated provision process. This ID will be available to the enclave with PROVISIONING function via EGETKEY.

  The provision key 1710 is used to prove the validity of the platform to the Intel backend and to authenticate the current SE TCB execution. By indicating access to the provision key, the provision server can verify that the enclave is in fact the device that owns the EPID ID and is running at least on a particular TCB security version. The provision key is specific to this package and the signatories of the provision enclaves that require it. This allows separation between these multiple provision infrastructures when used on a single platform. This key is available to enclaves with the KEY_PROVISION function via EGETKEY.

  Provision seal keys provide provision enclaves with 128-bit keys so that they can be encrypted in a manner that can be obtained even after a change in ownership. By encrypting the old EPID using this key, it is possible to prove that the platform has been invalidated while acquiring a new EPID. The provision key is specific to this package and the signatories of the provision enclaves that require it. This allows separation between these multiple provision infrastructures when used on a single platform. This key is available to enclaves with the KEY_PROVISION function via EGETKEY.

  The ISV out of box (OOB) experience key 1700 is a shared key between all Intel platforms and the ISV. This key is derived from the OOB root specific to a particular ISV. The ISV can have purchase access to this key, encrypt the secret for this key, and place it in the OEM's hard disk image. These secrets are accessible only to those codes that are securely executed within the secure enclave, and the platform does not have to perform on-line operation or complete proof key provision. These keys are available to enclaves with OOB functionality via EGETKEY.

  The provision key is an important key for a secure enclave architecture but is not derived from the platform keying material. These keys are provisioned from a provision server or offline technology. Device Certification Key (DAK) is the use of Anonymous Signature Key (EPID) to certify the characteristics of individual enclaves. This is used by the ISV during key or secret provisioning to ensure that this sensitive information is only sent to the protected introduction of the unaltered application.

  The device certificate key has two sources. The preferred architecture ships the fuse-compressed initial DAK as an EPID keyblob and EPID entropy. This allows the platform to start certification immediately after the first power up. The second source contacts the DAK provision server and uses the EPID ID and the provision key to prove the correctness of the hardware and one is downloaded. This second method is used by platforms that do not have a fused EPID key and platforms after invalidating the underlying TCB version. The EPID fuse can access an enclave with PROVISIONING function via EGETKEY.

  The platform certificate key (PAK) optionally provides an additional level of privacy. It is also possible to associate certain uses of DAK. A single ISV can determine if a given EPID reuses this service, especially if the ISV enclave has a name-based proof function. (But there is no collusion for tracking users between multiple ISVs). This association continues throughout the waterfall event since DAK is tied to the platform rather than to the owner. Therefore, some users prefer to use their own DAK to prove the legitimacy of their platform rather than having a third party issue a PAK and use it for daily proofing. On multi-package platforms, each package's DAK is used to build a PAK (representing the entire platform in the proof).

Key derivation for user accessible keys conforms to NIST Special Publication 800-108 (recommended for key derivation using pseudorandom functions). In the construction of the key derivation function, a pseudorandom function (PRF) is required. PRF uses the AES-CMAC algorithm defined in NIST SP 800-38B, recommended for block cipher mode of processing-CMAC mode for authentication, May 2005 (http://csrc.nist.gov/publications/nistpubs Based on /800-108/sp800-108.pdf). A common key derivation is: DerivativeKey = PRF _ParentKey (DerivativeString).

Derivative strings consist of a subset of eight elements based on the specific key being requested. Table 12-2 describes each of the available elements that can be part of the derivation.

Each key has a pre-defined set of derived elements, which contain derived strings. Table 12-3 shows the elements included in each key of the key hierarchy. Each column represents a key, and a row indicates whether the key contains a specific element. The debug string is included if the enclave SECS originating the request indicates that it is in debug mode, and a "request" is not required for this element and is selectable in the request for key derivation It shows that there is.

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

  In this section, we describe an example of platform architecture where the 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 is dependent on the particular TCB element. Other platforms can be supported using techniques similar to those used here.

The hardware needs the following keys to support CPU-based protection technology. These keys form the basis of the TCB key hierarchy.
<Stepping-specific 256-bit logical key>
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 be used for both.
<Die-specific 544-bit fuse key>
These include a 32-bit group id, a 256-bit SafeIdA.x value, and a 256-bit pre-seed. The A.x value and the 256-bit pre-seed are encrypted with the 128-bit fuse wrap key described above.
<Primary register>
In the key derivation process, the key needs to be stored and placed on the package and made available only to uCode. During the runtime of the platform, two 128-bit registers are required. An additional 256 bits of space are required for the EPID key until the CMA is up and running. After this, the additional 256 bits are unnecessary for the CPU.
<TCB SVN register>
This register is a 64-bit lockable register divided to hold SVN in each TCB layer. The division method is at the discretion of the platform designer, but it seems reasonable to divide it into eight 8-bit SVNs. Each part of this register is independently lockable.

  Combining keys into a particular set of TCB versions is done by having the uCode derive a first set of keys from the fuse keys based on the type of maneuver sequence being initiated. After locking this fuse, a chain of derivations is performed at each load of the start-up sequence.

  After loading the low level code, the chain will continue to include the ISV assigned security version of the software running on the enclave. In certain configurations, keys derived from the current version and keys from previous configurations can be accessed. Thereby, user data can be seamlessly transitioned to a new stable version.

  Once a die specific key is generated, it is encrypted with the key wrap key. This makes it more and more difficult to utilize the hardware monitoring tool to extract the key and to protect the key that passes before being placed in that part.

  The encryption 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 ciphertext key to be burned with a fuse.

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

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

This causes data to be migrated forward. Take uCode SVN3 as an example. The enclave uses EGETKEY to obtain a seal key based on this version (PRELoop (3)) and uses it to seal data. Distribute field uCode upgrade, the next launch uCode is SVN 4. After the upgrade, the EGETKEY implementation will be accessible to PRFLoop (4). If the enclave requests EGETKEY to send an SVN3 key, PRELoop (3) = PRF _{PRELoop (4)} (constant) can be calculated to obtain the old seal key.

In order to construct this property, the loop of PRF is used, but since the property PRF _{PRELoop (x-1)} is calculated from PRF _{PRELoop (x)} , the maximum value of SVN is constructed and subtracted from this. We have to go. Specific maxima need to 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 inject uCode's SVN into the SVN key and is the key underlying SE based keys. The die unique key to be fused includes 288 bits of EPID value and 256 bits of random key. All non-ephemeral symmetric keys can be derived from these 256 bits (consisting of two 128-bit keys). Thus, it is possible to create techniques for deriving multiple keys from a single key. To do this, once the fuse key is decrypted, it can be used to invoke PRF using different fixed constants. When the key is divided, it is generally as follows.

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

Once the SVN key is loop derived based on uCode SVN, it can be stored in a separate 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 key selectors that indicate whether the basis of the derivation is a global out-of-box key, a fuse key, and the SVN set required for each TCB layer. This makes it possible to verify that the request is below the current value. UCode can obtain the old SVN key, the PRF, and the required TCB SVN using any required PRE.

  When the appropriate SVN key is available, it is used as the key of the requested TCB SVN CMAC. The microcode uses this as the CMAC key, for the Ops key, or for the SEOps seed (the value derived from the part of the fuse key that Intel does not know) for the fixed string of the provision base key. That is, se_base_key = CMAC (svn_base_key, se_ops_seed).

  FIG. 18 illustrates an example of a microcode based secure enclave key hierarchy in accordance with one embodiment of the present invention. The reset microcode 1800 hierarchy uses the global wrap logical key 1801 and a unique root fuse 1802 known to Intel as input to the unwrap function 1806 function. The output of unwrapping 1806 and microcode SVN 1805 is input to PRF loop 1808. The microcode SVN 1805 and global root logical key 1803 enter another PRF loop 1809. The output of PRF loop 1808 is stored in SVN key 1810 register. The output of PRF loop 1809 is stored in global key register 1812. The microcode SVN 1805 is stored in the TCB SVN register 1814. Global wrap logic key 1801 and SE EPID A.x fuse 1893 are input to the unwrap function 1807 function and store the result in SE EPID 1816 register. In the MCheck 1820 hierarchy, the outputs of the MCheck SVN 1821 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. Global key register 1812 is stored in global key register 1824. The SE EPID 1816 is stored in the SE EPID 1828. In the loading microcode 1830 hierarchy, the outputs of the microcode SVN 1831 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. Global key register 1824 is stored in 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 SVN 1832 register sends data to the PRF loop 1842 and the global key register 1834 sends data to the PRF loop 1844. The output of PRF loop 1842 and the output of TCB SVN register 1836 enter PRF loop 1846 and the output of PRF loop 1844 and the output of TCB SVN register 1836 enter PRF loop 1848. The output of PRF loop 1846 is stored in SVN base key 1850 and the output of PRF loop 1848 is stored in global key 1852. In the microcode 1860 hierarchy, the EPID group ID fuse is stored in the EPID group 1858, with the unique root fuse 1894 not known to Intel being stored in the seed 1 1856. Seed 1 1856 enters PRE loop 1886 and PRE 1888. The output of PRE loop 1888 is SE EPID seed 1 1892. The output of PRF loop 1886 is SE ops seed 1890. The SE ops seed 1890 is obtained from the SVN base key 1850 and the requested SVN 1864 enters the CMAC 1868 function to generate the SE ops key 1872. The current SVN 1862 is obtained from the SVN base key 1850 and enters the CMAC 1866 function to generate the SE provision key 1870. If the SVN base key is equal to {0, 0, 0} 1874, then the SVN base key 1850 is stored in seed 0 1876. Seed 0 1876 enters the PRF loop 1878 and the PRF loop 1880. The output of PRF loop 1878 is SE EPID ID 1882 and the output of PRF loop 1880 is SE EPID seed 0 1884.

  Make sure all cores are in sync and all in MCHECK using doorbell or similar mechanism. (1) uCode reads, decodes, and locks fuses when all cores are running MCHECK. (2) uCode uses PRF loop as SVN key and PRF loop as OOBE key. Insert uCode's SVN into both keys. uCode writes its SVN to the TCB SVN register and locks that part, (3) The MCHECK loader or early MCKECK code writes and locks the MCHECK SVN to the TCB SVN register, (4) Microcode patch loader Each step of writing and locking the microcode patch SVN into the TCB SVN register is performed from the BSP. The AP does not participate in key flow.

During microcode initialization, or when EGETKEY is called, the microcode calculates the SE base key needed to fulfill the request. The base key may be cached in the CMA for further use for performance improvement. Table 12-4 shows how to calculate the base key.

  Include 256-bit random owner epoch in key derivation to protect user's privacy and data in platform waterfall. This value is randomly generated during owner change. Before using the enclave key, the software may write the owner epoch to SE_EPOCH_MSR. This may be done by the BIOS permanently writing to the flash. It can also be calculated from some user input (such as a hash of a user initiated password). Alternatively, it may be provided by the secure enclave driver prior to authorizing the use of the enclave.

  The secrecy of this value should ensure that the data encrypted by the platform can not be decrypted by the enclave first authorized by the laptop owner after waterfall. Security breaches of this value do not lead to security breaches of enclave data.

The SE key information structure is a non-permanent structure stored in a protected area of memory or package. Although CMA is the most commonly used location, it is possible to use any of the on-die protected storage. While the power is on, the SE key information can be initialized. The key ID is set to a random value and the key count is set to zero. Each time an enclave key, a grant key, and a report key are used, the key ID is read (the KeyID 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 zero. The SE key information arrangement is shown in 5.

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

  Many of Enclave's architectures use keys to provide authentication and confidentiality of enclave data, and use architecture enclaves to achieve high levels of utilization to minimize processor complexity. Process these keys. For example, the quotation enclave confirms that the REPORT structure generated by the EREPORT instruction has been created on the platform using the REPORT key, and the PERMITING enclave activates the enclave using the PERMIT key. Generate the enclave PERMIT that EINIT consumes when it is done.

  In addition, when any application level enclave needs access to the keys to seal the stored secret on the platform outside the enclave, when the application enclave is re-established (during the power cycle) ) The seal is released.

The mechanism for doing this is the EGETKEY command. This is a single interface to build a secret for the current software environment.
EGETKEY currently provides access to the following keys: (1) Provision Key ID (Architect to identify data blobs that are uniquely encrypted for the processor (using the provision key); (2) Provision key (used by the architecture provision enclave to decrypt data blobs uniquely encrypted for the processor) (3) provision seal key (used by the provision enclave) (Used by the architecture provision enclave to encrypt the EPID in such a way that the enclave can decrypt even if the owner changes) (4) Permit key (architect to create a permit Permit (Enclave), (5) Report key (Report) (Architecture Quotating Enclaves use to verify the build), (6) ISV AUTH KEY (Architecture Quotating to create authentication data for a specific target application enclave -Used by the enclave, (7) Authentication key (AUTH KEY) (used by the application enclave to authenticate data received by the architecture quotation enclave), (8) Seal key (stored outside the enclave) (9) OOB experience keys (eg, BluRay players) for pre-provisioning encrypted data for out-of-the-box experience use, to encrypt the desired data. To use).

  Most of these values are raw and non-resident on the processor, and in fact are derived from single fuse key values in response to EGETKEY requests. It is derived on demand when each of these keys is not a single key, but a single key from the possible set. The particular key delivered is dependent on multiple parameters, some of which are user selectable and others are based on system or particular conditions.

The key request structure is used as input to the EGETKEY command to select a key. In addition to selecting keys, the user utilizes a key request structure to allow callers to specify those variables under control that they wish to use during key generation. The following figures show the key request structure.

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

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

A key policy is a bit field selector, which is used to determine whether a particular value (whether from 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 a bit set opt by the BIOS. This is a write once function. Enable or disable the enclave feature by the next reset. The second enable is provided to the OS or VMM to turn the enclave feature on or off as needed.

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

  The enclave function begins by setting the enable bit in the enclave CTL_MSR shown in FIG. This bit is initialized to disabled upon a package reset. This bit can be written once after a package reset.

  The BIOS sets the bit to enable enclave. Once the BIOS clears the bit, the enclave can not be enabled until the part is reset.

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

  When the bit Opt is cleared, the CPUID reports not to execute its enclave.

  The system software controls the enclave function using the enclave CTL_MSR shown in FIG. The On bit allows software to dynamically control access to the enclave function.

  Software can detect enclave support by executing the 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 includes the TCS address, and is used by exception handling and RDTCSPTR. Loaded when entering an enclave. The register is loaded with the value of TCS when EENTER is executed and read by ERDTCSPTR. The register size is based on the mode of the processor.

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

  The register holds the upper limit of the current enclave's address and is loaded when it enters 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 mode of the processor.

  The enclave page cache (EPC) maximum size register indicates the maximum size of the EPC. This size is given by the number of pages of 4096 bytes. This is a 32-bit register. This register is read only and indicates the maximum size that the EPC supports in the current design.

  EPC Size Register EPC_SIZE MSR indicates the currently defined size of EPC. By loading the register, the EPC is defined to that size. This value is given in pages of 4096 bits. For example, one 4096-bit page is one. The value of the register can not exceed the EPC_MAX value. If the value exceeds the EPC_MAX value, the WRMSR instruction causes a GP fault. By writing to this register, all data in the EPC is invalidated before writing. Software may save all EPC entries (if necessary) before updating this register.

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

  Generally, the external interface does not allow transfers or transactions that may compromise the security of the enclave. Secure enclaves require random numbers for enclave keys. The random number generator is securely accessible by microcode. It does not have to be placed at 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 multiple cores, core 02640 and core 12670. 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 2684. The read random instruction 2630 may be in communication with the microcode 2642 and the read random instruction 2635 may be in communication with the microcode 2672. The processor package 2600 may further include a DRNG 2602, which takes the STD 2608, the OPE 2610, the PSK 2612, and the TSC 2614. The DRNG 2602 can obtain a digital entropy source 2604, which connects to an on-line self test 2606. The output of the on-line self-test 2606 may be one input of a combined regulator / deterministic random bit generator (DRBG) 2620.

  Enclaves may be set as debug enclaves at creation time. The debug enclave can externally access the contents of the enclave using the EDBGRD and EDBGWR instructions. The debug enclave is set up by setting the debug enclave in ECREATE. This bit is stored in the enclave's ECS.

  The enclave created by debug bit clair is a generated enclave. For the enclave, the EPC contains debug bits that indicate that the enclave is a debug enclave. Enclaves remain encrypted in main memory or on disk. The debugger, which needs to find the contents of the enclave, loads the 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 execute and is performed without a valid permit.

  When entering the generation enclave, the debug control register DR7 is saved in the TCS save area. DR7 is shown in FIG. FIG. 27 is a debug register DR7 2700 in one embodiment of the present invention. The 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, R / W3 2740 And LEN 3 2742.

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

  For debug enclaves, do not change the value in the debug register. RFLAGS. The TF is set at the start of the EENTER command, and the following two cases need to be taken into account.

  One case is when the debugger is legacy (non SE aware) or if the enclave is in generate (non debug) mode.

  The SE recognition debugger targets debug mode enclaves.

In the first case, a #DB exception may occur at the subject of the next EEXIT instruction. This causes the enclave to be treated as a large, opaque operation. In the second case, the user can take advantage of complete freedom to a single step by the enclave (complete freedom to single step through the enclave). This action consists of three data fields in the enclave, and EENTER, EEXIT, and RFLAGS. Supported by TF special handling.

  Save the register value 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 start up, EENTER will be the last entry before entering the enclave. At the end of the enclave, the beginning position after the end is written to the branch trace.

  Int n and Int 3 instructions are reported as GP fault when executed within the enclave. The debugger can hook a GP fault condition when debugging an enclave.

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

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

  The CBC algorithm uses block ciphers to ensure the confidentiality of some data or to calculate an authentication tag for this data. The idea underlying the CBC algorithm is that the output from the previous cipher is XOR'd with the next input block prior to encryption. In this way, patterns that may be present in the input data can be excluded from the ciphertext. Also, the combination of XORing between block cipher transactions results in a strong mixing to derive an ideally forgeable message authentication tag.

The CBC algorithm is shown in FIG. 20 and below. Encryption is assumed to be 128-bit encryption 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 a symmetric key K. The subkeys K ₁ and K ₂ are derived from the intermediate value L. CMAC indicates that L can be obtained by performing symmetric key block cipher transformation using a symmetric key value K to a string of zeros (ie 0 ¹²⁸ ) using the symmetric key value K . This relationship is shown by the equation (1) L = CIPHER _K (0 ¹²⁸ ).

Once L is derived, the most significant bit of L is checked. If this is zero, it is derived from L by shifting K ₁ one bit to the left. Otherwise, shift L one bit to the left and XOR with the 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 in the} same procedure. The derivation of the subkeys K ₁ , K ₂ is shown in the pseudo code below. Let MSB () indicate the most significant bit of a value.

  The second feature of CMAC relates to padding before using CBC algorithm on input data. If the last block of data is not a complete block, the block is padded with the necessary number of zeros of bits to 1 so that the final block is complete.

The third feature of CMAC relates to the modifications to the final block that are made to avoid length extension attacks. If the final block is not completely 1 (if no padding is necessary), the final block is XORed with the subkey K ₁ . Otherwise, XOR with subkey K ₂ . The CMAC tag generation and verification algorithm is shown below.

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

  Since the tag verification process is the same as tag generation, calling only AESENC AESENCLAST is sufficient to implement CMAC mode using AES round instructions. FIG. 21 is a flowchart associated with encryption of a single AES block. FIG. 22 shows a flow chart associated with the encryption of multiple AES blocks utilizing the CBC algorithm.

  To implement key schedule conversion, AESIMC and AESKEYGENASSIST instructions for inverse mix columns can be used. AESKEYGENASSIST is used to generate a round key that is used for encryption. AESI MC is used to convert a cryptographic round key into a form that can be used for decryption according to the equivalent reverse encryption model. The AESI MC and AESKEYGENASSIST instructions are described at http://softwarecommunity.intel.com/articles/eng/3788.htm.

  CMAC is indicated using a big endian description of 128 bit quantities. In order to implement CMAC correctly using a little endian machine, it is necessary to perform reflection processing of 16-byte width at a certain point of source code implementation. This process can be performed quickly by using the PSHUFB instruction (1 clock latency, throughput). The following describes the point at which byte shuffle is required.

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 two subkeys are derived. Byte reflection is necessary for two subkeys after being derived from L. The SUBKEYS () implementation is denoted by C below.

Next, it is necessary to perform byte reflection on the final block before and after padding only if the final block is not perfect. These steps are illustrated in the C implementation below.

  function_pshufb () performs byte reflection of 128 bit width.

<SE Requirements for SMI>
Enclaves are not allowed to run in SMM space. Attempting to execute an enclave in SMM mode results in a GP fault of the instruction. If the SMI occurs while executing in the enclave, the processor saves the register state in the remote enclave and exits. When complete, the TBD MSR bit is set to indicate that an SMI has occurred during enclave execution. SMM code can not access enclaimed data. Attempts to contact the EPC area will return junk data in the actual mode and return EPC page faults in the protected mode.

Some instructions are not allowed to execute. Several general rules are used to determine which order is legal.
1. Ring level changes are not allowed within the enclave. Ring level change or possible change orders are prohibited.
2. External software can not service VMEXITS in the enclave. Prohibit all instructions that generate or may generate VMEXIT within the enclave.
3. Software can not create virtual machines within an enclave. Prohibit all VMX instructions.
4. Prohibits instructions that perform I / O references inside the enclave.

In the first generation of enclave, the processor may be executed on ring 3 with IOPL set equal to 0 when entering the enclave. When executing enclaves in a virtualized or non-virtualized environment, the instructions listed in Table 18-1 are legal to preserve the programming environment.

Constraints are imposed on the state within the enclave. When entering an 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 within the enclave. GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS are restored when leaving the enclave.

  The lifetimes of enclaves can be classified into distinct phases. The first stage is enclave generation. The second step is enclave utilization. The final stage is enclave destruction.

  The creation and use of enclaves requires OS / VMM support. Enclaves do not rely on OS / VMM for security, but OS / VMM is required to maintain certain hardware data structures properly. If OS / VMM fails to maintain these structures, security is not compromised, but the entire enclave may fail.

  Some commands support enclave certification, sealing and unsealing of secret data, and authorization of certified enclaves.

  In the first phase, the enclave may be securely built and have an internal software environment set up for use by the application. Generate enclaves using three instructions. The first instruction ECREATE sets the initial state environment. This instruction creates, loads, encrypts the enclave key, and performs a two page integrity check that is used to store the enclave data structure. The second instruction EADDPRE adds one page of data to the enclave. Specifically, add the necessary pages to the code, stack, and heap in the enclave. The third instruction EINIT sets the internal software environment to a known state. At the completion of this order, the enclave has moved to the second phase, "use."

  Prior to performing EINIT, the construction software may have obtained a permit by executing EMKPERMIT or by utilizing an permit enclave.

  Enclaves are input by the EENTER command. This instruction causes the machine to transition to enclave mode. Then, control is passed to a predefined entry point. The EEXIT instruction returns from the enclave to the external application. The EIRRET instruction returns to the enclave from the end of the interrupt.

  When entering an enclave via EENTER or EIRET, the following processing is executed according to an 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 order for the destruction of enclaves.

  The EDBG_READ instruction reads eight bytes of a location in the debug enclave. Non-debug enclaves are not allowed access. The EDBG_WRITE instruction writes eight bytes to a location within the debug enclave. Non-debug enclaves are not allowed access.

  The enclave page cache (EPC) is managed through two instructions. 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 unique keys. EMKPERMIT is used to generate a permit for the certified enclave.

Note ² : There is no model available "inside", but there is no known damage from allowing EMKPERMIT to execute from the inside.
Note ³ : Future versions may allow entry to the enclave from ring 0 as well.

  When an interrupt occurs, save (hide) the processor state in the enclave and clear the state. In addition, the return address of the interrupt may be hidden.

  The interrupts that occur during enclave execution push information onto the interrupt stack in the form that the operating system expects, so that it is not necessary to change the OS code. To accomplish this, we push a pointer to the trampoline code onto the interrupt stack as a RIP. This trampoline code is eventually returned to the enclave by the EENTER command with the special parameter (qv).

  The interrupt stack utilized is selected according to the same rules as utilized in non-SE mode. That is, 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. (3) When using the IA-32e IST mechanism, use an untrusted stack, and use this method to select an interrupt stack.

  FIG. 23 illustrates one embodiment of the application and interrupt stack after interrupting at the stack switch. The current save state area frame 2300 includes an RSP register 2305. Thread control structure 2310 may include counts of state save area 2312 and interrupt return routine 2314. The interrupt stack 2330 includes an SS register 2332, an RSP register 2334, a flag register 2336, a CS register 2338, an instruction register 2340, and an error code 2342. The interrupt stack 2330 may send the data in the RSP register 2334 to the count of the application stack 2320 and the save state area 2300. Error code 2342 may come from RSP after push 2346. The interrupt routing routine 2314 and the instruction register 2340 deliver a per-thread trampoline for the uRTS 2344.

  In either case, the choice of interrupt stack and the information pushed to it is consistent with non-SE processing. FIG. 23 shows the application and interrupt stack after interrupting with the stack switch. Stack switchless interrupts utilize the application stack. In addition, the TCS pointer is located at RBX as the EENTER instruction will be used later to resume enclave after an interrupt.

  TCS :: IRR (Interrupt Return Routine) points to a per-thread code sequence which is later returned 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 IRET to the application where the interrupt return code (including the special EENTER instruction) is executed. EENTER takes the RBX register initialized at interrupt time and uses it as a TCS to re-enter the enclave.

  Bits of RFLAGS 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 onto the interrupt stack.

  FIG. 24 illustrates how a stack of state save area slots of one embodiment of the invention can be implemented. The thread control structure 2400 may include a next state save area slot 2402, a current state save area slot 2404, and a state save area slot 2406. State save area 0 2410, state save area 12412, and state save area N 2418 are three separate selected locations within the state save area. The next state save area slot 2402 specifies the position to be used in the state save area (state save area 0 2410). The current state save area slot 2404 identifies the location used in the state save area (state save area 12412). The state save area slot 2406 identifies the position to be used in the state save area (state save area N 2418).

  The state save area holds the enclave state at the point of interruption. Because interrupts can be sent to user modes that may re-enter the next enclave, the SSA is a stack of multiple SSA slots as shown in Figure 19-3. The position of the state save area to be used is controlled by three variables of TCS, where three variables are the number of state save area slots (NSSA) (which defines the total number of slots in the state save area stack), Save area slot in current state (CSSA) (defines the current slot to be used on the next interrupt), state save area (SSA) (save area slot used to save processor state on interrupts) A set of

  When an interrupt occurs while executing on a thread in the enclave, the microcode examines TCS :: SSA and TCS :: CSSA to determine the save area to be used. The processor state is saved and cleared (to prevent secret leaks) and increment TCS :: CSSA. As described below, if an exception occurs in the last slot, the exception can not be sent to the enclave.

  Note: In EENTER, CCSA may be less than NSSA, and it is ensured that there is at least one save area for interrupts (unless EENTER is being used to return from interrupts).

  FIG. 25 shows a portion of a state machine with interrupt, fault, and trap state transitions. Possible states are inactive 2500, active 2510, expected 2520, processed (EENTER illegal) 2530, and in progress 2540. When EENTER is placed in TCS: ENTRY 2502, inactive 2500 transitions to active 2510. When EEXIT 2504 occurs, active 2510 transitions to inactive 2500. When an interrupt, fault, or trap 2512 occurs, active 2510 transitions to anticipation 2520. When EIRET 2514 occurs, anticipation 2520 transitions to active 2510. When EENTER is placed in TCS: HANDLER 2524, anticipation 2520 transitions to 2540 during processing. When EIRET 2522 occurs, anticipation 2520 transitions to 2540 during processing. If an interrupt, fault, or trap 2526 occurs, processing 2540 transitions to anticipation 2520. When EEXIT 2532 occurs, processing 2540 transitions to processed 2530. When a processing interrupt occurs in the enclave exception handler and EIRET 2534 occurs, processed 2530 transitions to 2540 during processing. When a processing interrupt that is not from the enclave exception handler occurs and EIRET 2534 occurs, processed 2530 transitions to active 2510. Dotted transitions 2522, 2526, 2534 occur only during the processing of the interrupt in the enclave exception handler.

  FIG. 25 shows the part of the enclave state machine that deals with interrupts. The interrupt begins with pushing the synthetic interrupt frame onto the optional stack switch and interrupt stack. If the event is an interrupt, the enclave enters an interrupt state. If the event is an exception, the enclave enters an exception state. These two states are distinguished to ensure delivery of the enclave exception to the enclave and also to prevent the delivery of spurious exceptions by the attack application code.

  Upon transitioning to the interrupt state, the untrusted code (application, OS or both) need only resume enclaves using EENTER / RETURN_FROM_INTERRUPT.

  Upon transitioning to the exception state, the untrusted code (application, OS or both) resumes the enclave using (1) EIRET to return to the interrupted IP. This is, for example, a method for processing page faults. If an interrupt is caused by a fault and nothing is done to correct the fault condition, then the fault instruction will be re-executed to cause the fault again. However, EIRET after the trap may decide to return to the instruction after the trap instruction, (2) call the enclave exception handler, (3) destroy the thread or enclave.

  The expected state EENTER goes to the processing state. EEXIT (processing in progress) from the trap handler proceeds to the processed state. ENTER / NORMAL is illegal in this state. EIRET from the trampoline resumes the state (active or in-progress state) pushed to the SSA since the last interrupt.

Split the secure enclave instruction into two opcodes (ie, privileged opcodes and nonprivileged opcodes). Instruction processing is determined by the value of RAX at the time of instruction invocation.

The ECREATE instruction initializes a 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 and boundary value of the SECS base may be zero. SECS is the address of an empty slot in the EPC. sec_info is an address of an unprotected sec_info structure. The corresponding sec_info flag field may be properly initialized.

<EADDPRE>
<Description of instruction>
EADDPRE allows privileged software to copy pages outside the enclave to the page 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 expanded into the enclave's metric register. EADDPRE can only be executed for enclaves that have not yet initialized the EINIT instruction.

<EADDPOST>
<Description of instruction>
EALLOCATE causes privileged software to initialize the enclave SMAP entry specified by lin_addr, and the attributes of the enclave page are set using the sec_info flag field. Before the enclave can access the page, the EACC EPT instruction may be used to access the enclave page. EALLOCATE is only performed on enclaves that have been initialized by the EINIT instruction.

<EMKPERMIT>
<Description of instruction>
Authorize the enclave or license and use it to generate a permit. If rbx == NULL, then the certificate may be signed by Intel. In other cases, the license may be signed by the key indicated on the rbx permit.

<EINIT>
<Description of instruction>
EINIT displays the enclave as ready to run in the software environment. At the end successful initialization, allow EENTER to the enclave.

<ELPG>
<Description of instruction>
This instruction is used to load the page into the enclave page cache (EPC).

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

<EUPSMAP>
<Description of instruction>
This instruction checks and updates the version of the enclave page resident in the EPC.

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

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

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

<EACCEPT>
<Description of instruction>
Software in the enclave uses this instruction to accept changes to the SEC_INFO field. This allows the SMAP to be updated to a new page type.

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

<RFLAGS. TF behavior>
RFLAGS. At the start of EENTER execution. The value of TF does not affect the trap when EENTER completes. RFLAGS. Loaded from TCS. The value of TF determines if the trap is taken.
<DR7 behavior>
When the enclave is not in the debug mode, the 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 exits the enclave.
<Description of instruction>
EEXIT disables enclave mode and branches to the location specified by RBS. This instruction does not affect the register. If the secret is contained in any of the registers, it is the task of the enclave software to clear those registers. RFLAGS. TF has a slightly modified behavior on EEXIT. RFLAGS. TF is TCS. Loaded from SAVE_TF. Next, the debug exception is RFLAGS. It is generated with the condition CR-0021 according to the updated value of TF. When the enclave is not in the debug mode, the debug register DR7 is set to TCS. Load into DR7. This behavior, and RFLAGS. What is the behavior of TF? ? ? Detailed in

<RFLAGS. TF behavior>
RFLAGS. At the start of execution of EEXIT. The value of TF does not affect the trap on completion of EEXIT. RFLAGS. Loaded from SSA. The value of TF determines whether to take a trap.
<DR7 behavior>
When the enclave is not in the debug mode, the 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>
<Description of instruction>
The EIRET instruction uses the machine state previously stored in the SSA to resume execution of the enclave suspended for an exception or interrupt. EIRET verifies that the TCS is valid and can be resumed. The TCS and corresponding SSA may be resident in memory for instructions to proceed. EIRET also checks the state machine to determine the type of entry and to ensure that only one logical processor at a time is active in the TCS. RFLAGS. If TF is set on EIRET, a debug exception will occur at instruction completion (ie normal TF behavior). This exception is reported as occurring within the enclave (in the manner defined by the normal SE) and the instruction is not executed internally. TF may be set at the end of EIRET, since EIRET restores RFLAGS from SSA. In this case, the TF influences the following instructions (also the normal TF behavior):

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

<EREPORT>
The EREPORT command reports measurements on the contents of the enclave.
<Description of instruction>
EREPORT gets the enclave measurement value register, its function and debug status (flag). All these values are protected using symmetric message authentication codes and can be verified using the REPORT key. For an enclave that requires a REPORT key, the appropriate function can be set in the SECS to obtain it with the EGETKEY command. The result of this instruction is placed in the destination location output_buffer_la.

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

<EGETKEY>
Used by the enclave code to return a particular key from the processor key hierarchy.
<Description of instruction>
The required key is identified using the KeyRequest structure, and its address is provided as input. This address is naturally aligned. The output will always be a 256 bit data value. In order to obtain this value, output_la needs to be naturally aligned.

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

<EDBGRD>
<Description of instruction>
The EDBGRD instruction is used to read eight bytes from the debug enclave.

<EDBGWR>
<Description of instruction>
The EDBGWR instruction is used to write eight bytes to the debug enclave page.

<ERDINFO>
The ERDINFO instruction returns information about the contents of the enclave page cache.
<Description of instruction>
When executed out of the enclave, the EREPORT reports its function and debug status (flags) to the enclave metrics register. All these values are protected using the symmetric message authentication code and can be verified using the EVERIFYREPORT instruction. The result of this instruction is placed in the destination location output_buffer_la.

<See routine>
<Exit (Exit)>
This section provides pseudo code for the exit process. This code is called when there is an exit from the enclave that the enclave code has not planned. Enclave execution resumes from where it left off. The information needed to resume is saved on the external stack. The processor's architectural state is saved in the appropriate save area.

Acquisition of reader lock
The RW lock allows the logical processor to access shared resources to provide two modes in which threads can access shared resources. These two modes are: (1) Shared mode: allow shared read-only access to multiple reader logical processors, so that these multiple processors can read data concurrently from shared resources Mode, (2) exclusive mode: a mode that permits read / write access to one write logical processor at a time, and when a lock is acquired in exclusive mode, an entity to which another thread is writing You will not be able to access shared resources until you unlock it.

<Description of subroutine>
This subroutine is actually the addition of hardware that is utilized when uCode exposes the PMH address-to-conversion function to uCode. XUTRANSLATE is a uOp that mainly takes a PMH context and a linear address as input and generates a final physical address as output. When the PMH encounters bad conditions during the page table walk, these are reported to uCode. The details of uOp are beyond the scope of this document.

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

Claims (6)

Providing execution logic to execute a first instruction to access a thread control structure of a software thread being executed in a secure enclave,
The thread control structure stores information about the software thread for saving and returning thread specific information when exiting the secure enclave;
The secure enclave is a protected container,
Processor. The execution logic helps ensure integrity of the enclave page using the secure enclave security map (SMAP) when the enclave page is stored on a hard disk drive or protected memory.
The processor of claim 1. The SMAP stores cryptographic metadata for verifying the freshness of the enclave page.
The processor according to claim 2. The SMAP represents a full version tree for a specific snapshot of an enclave,
The processor according to claim 2. Each node of said SMAP holds a version for at least 256 child nodes,
The processor according to claim 4. Further comprising a data structure storing metadata about the security node;
The processor according to claim 2.

Images