JP2012530961A - Method and apparatus for providing secure application execution - Google Patents

Abstract

Disclosed is a technique that enables secure application and data consistency within a computer system. In one embodiment, one or more secure enclaves are built that can store and execute applications and data.
[Selection] Figure 1

Description

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

  Ensuring execution and consistency between applications and their data within a computer system is becoming increasingly important. Prior art security techniques cannot provide secure applications and data in a flexible and reliable manner.

  Embodiments of the present invention are illustrated by way of example and not limitation in the accompanying drawings, in which like reference numerals denote like members.

FIG. 6 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. 1 is a block diagram of a shared bus computer system that can utilize at least one embodiment of the present invention. FIG. FIG. 3 is a block diagram of a point-to-point interconnect computer system that can utilize at least one embodiment of the present invention. 1 is a block diagram of a multi-core microprocessor that can utilize at least one embodiment of the present invention. FIG. FIG. 4 is a possible implementation of a secure enclave (SE) of an embodiment of the present invention. FIG. 6 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. Fig. 4 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. 4 illustrates an example of a thread control structure in one embodiment of the present invention, illustrating stitching of data structures. Fig. 4 illustrates a step of a software authentication process known as quota, which can be found in an embodiment of the present invention. FIG. 6 shows steps for generating quotes from a measurement value register set in an embodiment of the present invention. FIG. 6 shows an EADD process for updating a measurement value register MR_EADD in an embodiment of the present invention. Fig. 6 illustrates an EEPPORT instruction for generating a report in an embodiment of the present invention. Fig. 4 illustrates a relay protection mechanism found in an embodiment of the present invention. Fig. 4 illustrates an example of a portion of a MAC tree structure of a relay protection mechanism found in an embodiment of the present invention. 4 shows an embodiment of the present invention showing how to implement a page fault error code map. FIG. 6 illustrates an example of a process for generating a permit to launch an enclave according to an embodiment of the present invention. FIG. 6 illustrates an example implementation of a platform key hierarchy for a single package secure enclave in an embodiment of the invention. FIG. Fig. 4 illustrates an example of a microcode based secure enclave key hierarchy in an embodiment of the present invention. Fig. 4 illustrates an enclave CTL_MSR register that can be found in one embodiment of the invention. Fig. 4 illustrates a cryptographic block chain algorithm utilized in one embodiment of the present invention. 6 is a flowchart illustrating encryption of a single AES block in an embodiment of the present invention. It is a flowchart which shows the encryption example of several AES block using the encryption block chain | strand algorithm implemented by one Embodiment of this invention. Fig. 4 illustrates an embodiment of an application and interrupt stack after interrupting with a stack switch. 6 illustrates an example of a method for implementing a stack of multiple state save area slots according to an embodiment of the present invention. FIG. 4 illustrates a portion of a state machine having interrupt, fault, and trap state transitions in an embodiment of the invention. Fig. 3 illustrates a processor package for a digital random number generator in an embodiment of the invention. Fig. 8 shows a debug register DR7 2700 in an embodiment of the invention.

  Embodiments described herein relate to a technique for providing a secure application and data in a flexible and reliable manner. Although the present invention has multiple embodiments of multiple aspects, the appendix “Secure Enclave Architecture” is hereby incorporated by reference as at least one embodiment. However, the incorporated literature does not limit the scope of the embodiments of the invention, and other embodiments may be used within the spirit and scope of the invention.

  FIG. 1 is a block diagram of a microprocessor that can utilize at least one embodiment of the present invention. In particular, FIG. 1 shows a microprocessor 100 having one or more processor cores 105 and 110, each associated with a local cache 107 and 113, respectively. Further, FIG. 1 shows a shared cache memory 115 that stores at least a partial version of information stored in each of the local caches 107 and 113. In some embodiments, the microprocessor 110 may also include other logic not shown in FIG. 1 (eg, integrated memory controller, integrated graphics controller, and other logic within the computer system, such as I / O control). Logic to perform the function). In one embodiment, each microprocessor in a multiprocessor system or each processor core in a multicore processor includes or is associated with logic 119 in at least one embodiment to perform secure enclave technology. ing. Logic includes circuitry, software (implemented in a tangible medium), or both, allowing for more efficient resource allocation between multiple cores or processors than some prior art implementations Can do.

  For example, FIG. 2 illustrates a front side bus (FSB) computer system that can utilize an embodiment of the present invention. Any of the processors 201, 205, 210, or 215 includes a local level 1 (L1) cache memory 220 that includes or is associated with processor cores 223, 227, 233, 237, 243, 247, 253, 257, Information of any of 225, 230, 235, 240, 245, 250, and 255 can be accessed. Furthermore, any of the processors 201, 205, 210, or 215 can receive information from the system memory 260 or from the shared level 2 (L2) caches 203, 207, 213, and 217 via the chipset 265. Can be accessed. One or more of the processors shown in FIG. 2 may include or be associated with logic 219 that performs secure enclave technology 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 may include several processors, of which two processors 370 and 380 are illustrated. Processors 370 and 380 may include local memory controller hubs (MCH) 372 and 382 for connection with memories 32 and 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 can also 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, if a shared cache (not shown) is included in processors outside both processors but is connected to both processors via a p2p interconnect, and both or one of these processors are put into low power mode. The local cache information can be stored in the shared cache. One or more processors or cores shown in FIG. 3 may include or be associated with logic 319 that performs secure enclave technology in at least one embodiment.

  One or more aspects of at least one embodiment can be implemented by representative data stored on a machine-readable medium that represents various logic within the processor, where the data is read by the machine, Manufacture logic that implements the techniques described herein. The representation as known as "IP core" is stored on a tangible machine readable medium ("tape") for various customers or manufacturing to load logic or a processor into the actual manufacturing machine. May be supplied to the facility.

  Accordingly, a method and apparatus for directing microarchitecture memory region access has been described. The above description is intended to be illustrative and not limiting. Numerous other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. Accordingly, the scope of the invention should be determined with reference to the appended claims and the full scope of equivalents which can be included.

A secure enclave is an instruction set that provides a secure location for an application to execute code and store data within the context of an OS process. An application executed in this environment is called an enclave. Enclaves are executed from an enclave page cache (EPC). The enclave page is 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 enclave's confidentiality and detect tampering when returning the enclave to the EPC. Within the EPC, the enclave data is protected using an access control mechanism provided by the processor. Table 2-1 below provides a complete list of unprivileged enclave instructions.

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

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

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

  The enclave page cache map (EPCM) includes state information associated with each page in the EPC. This status provides information such as the enclave to which the page belongs, the status of the loaded page, and so on. When a page is retrieved from the EPC, the status information is also exported and protected using encryption means. When reloading the enclave page into the EPC, the status 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 CR3 422, SMBR 424, page miss handler 428, PMHE 430, and translation lookaside buffer 432. In some embodiments of the present invention, the microprocessor 499 includes a level 1 cache 440 that is shared between the core 400 and the core 420. The level 1 cache 440 can exchange data with the final level cache 445. The home agent 450 can connect to the final level cache 445 and attach to the cryptographic engine 452. The home agent 450 can assess the physical address space 488 of the crypto memory aperture 480 via the memory controller 454. The crypto memory aperture 480 includes an enclave page cache 482, an enclave page cache map 484, an auxiliary storage 486, and a portion 488 of the physical address space.

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

  EPC and EPCM (and other implementation data structures) are mapped to certain locations within the aperture. The auxiliary storage is the actual data for these resources. When an EPC memory request is generated, the CMA performs remapping to the location of the auxiliary storage unit containing the encrypted EPC data, and acquires the data.

  In general, most SEs are implemented in microcode or extended microcode. Hardware support is required at multiple locations including CMA, logic to control data movement outside the package and within the core.

  FIG. 5 is a possible implementation of a secure enclave (SE) of one embodiment of the present invention. The operating system and VMM 542 can utilize the ELPG instruction 540 to load the enclave page of the enclave 532 into the enclave page cache 544. The enclave page cache 544 is protected from software access by the SERR register 532 when the microprocessor is not executing in the enclave 532. The microcode page table provides protection 548 when executed in an enclave. 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 diagram of one embodiment of a secure enclave implementation. In this implementation, the EPC is maintained in a separate container managed by microcode. A container is inaccessible when not running in an enclave. When entering the enclave, control is transferred to the enclave code in the EPC contained in a separate container.

  Any page faults or exceptions that occurred while running in the enclave are reflected in the associated OS or VMM by microcode. 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 and prohibits access to other EPC entries that do not belong to the enclave being executed.

  One way to implement a secure enclave is to use microcode functionality in some processors to provide instructions and protection. This feature will meet the security requirements of secure enclave objectives.

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

  An option in an implementation that improves performance is to provide one or several 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 when leaving the enclave to prevent other code from accessing the enclave.

  Compare the enclave bit with the enclave mode bit. The surplus bit provides the function of the enclave space id. A particular enclave may be assigned an id. The id is compared with the id of the running enclave as part of the address check. TLB support is one option for improving performance. If an entry is invalidated in the TLB due to 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 verify that this entry is not in any TLB. In other embodiments, microcode may be provided with a means of verifying that another processor has invalidated the TLB entry.

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

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

  The enclave may be protected from tampering. The details of the mechanism used for tamper protection vary depending on the implementation. Thus, when the enclave is tampered with, further execution on the thread that has detected tampering is prevented. In order for the user to understand the state of the enclave, a verification mechanism is provided to prove the enclave being constructed. This includes an EEPPORT instruction that presents information about the enclave content.

  In order to simplify the microcode code required for enclave design, the concept of an architectural 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 depends on the software policy. Data in the CMA is lost when power is shut down. If it is desirable to save the enclave, the software can ensure that no enclave data is lost during the power cycle. Data resident on the EPC can be flushed to memory if the software wants to keep the enclave alive during the S3 power state. The software can also choose to require the application to remove all enclaves when power is lost.

  The enclave is protected depending on its position. Data outside the CPU package is protected using encryption and integrity checking. For code and data in the enclave page cache, the page is protected using an access control mechanism.

  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. The enclave data 635 can be encrypted. The crypto memory aperture data 630 is used to protect the enclave data 635.

  Enclave pages residing in system memory are protected using encryption and integrity. In loading a page into an 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.

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

  If an enclave page resident in the EPC is forcibly moved from the cache to the main memory outside the CPU package, it is protected by CMA encryption. CMA encrypts this data to realize data confidentiality. EPC consistency 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 the enclave page cache 720 may have corresponding metadata in the enclave page cache map 710. In the metadata shown in FIG. 7, if the secure enclave 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 Can be accessed.

  FIG. 7 shows the placement and usage of EPC and EPCM. The EPC is divided into 4k pages. Each enclave may have several numbers of pages that are resident in the EPC. Some EPCM entries of each page of the EPC provide meta information necessary for ensuring security. Details of the EPCM are specific to the embodiment.

  If the application wants to load the enclave, it calls an OS system routine. The OS tries to allocate several pages in the EPC. If there is no space available, the OS selects and removes the victim enclave. The OS forcibly evicts the victim enclave page using the EWBINVPG instruction for each page. When the OS completes the forced removal, a secure enclave control structure (SECS) is added to the enclave using the ECREATE command. After generating the SECS, the OS adds the page to the enclave as requested by the application using the EADDPRE instruction.

  To add a data page to the enclave, the OS first adds a SMAP page to the enclave using the EADDDSMAP instruction. Depending on the size and placement of the enclave, the OS may allocate multiple SMAP pages. When all enclave pages are added to the enclave, the OS executes the EINIT instruction to execute the enclave. The parameter for the EINIT instruction is an authorization letter indicating that the enclave is allowed to execute on the machine. A permission must be generated when loading the application. If EINIT completes successfully, the application can execute the EENTER command to enter the enclave.

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

  After copying the memory to the enclave, the software may be able to access the page internally after accepting the page. The enclave accepts the data by executing an EACCEPT instruction. This instruction can only be executed by software in the enclave.

  In some cases, the software may want to modify the characteristics of the enclave memory. For this purpose, SMAP needs to be updated. For example, consider the case where software attempts to generate another thread entry point, TCS, in the enclave. In this case, the enclave requests the OS to change the SMAP characteristics of the page using the EMODIFY instruction. After the characteristics are changed, the enclave software executes an EACCEPT instruction to allow the use of the page.

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

  One way to ensure the consistency of the enclave environment is to perform an access check several times. Among the various security features that are implemented, the code is located exactly at the EPC so that the data does not leak between the enclaves and the reference address is not corrupted, so that the code has different linear addresses in the enclave. There is something to prevent it from being moved to.

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

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

  Enclave accesses may be resolved against physical addresses 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 stopped. A defect or command to the OS is reported.

  Access to an address in the enclave can be located in the EPC for successful access. Checking whether an entry exists in the EPC is usually done by checking the EPCM to verify 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 that the referenced page matches the SECS of the running enclave.

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

  The enclave's linear address mapping must not be corrupted. If the linear address page table is corrupted, access is illegal. This prevents attackers from bringing 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 for that page. The bit indicating pending remains alive even after subsequent EPC writeback and forced removal (using SEC_INFO). The enclave can issue an 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 a relay protected enclave page into the EPC, the FCR (fresh check requested) bit is set in the EPCM entry for that page. The OS / VMM can clear this bit by executing the EUPSMMAP instruction for the EPC page and clearing this bit. Continuation of enclave access is allowed only if the FCR bit for this page is not set. Otherwise, the LP sends an EF_FRESH_CHK failure to the OS / VMM.

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

  Whenever a logical processor is executing in an enclave, the SECS page for that enclave may exist in the EPC. However, in the SE security model, enclaves are not allowed to make direct memory accesses to their SECS (although enclaves can read their enclave keys on the premise that they completely compromise security). If an enclave access is resolved to an EPC page that holds SECS for that enclave, the OS / VMM is notified via an EF_ATTRIB_SECS failure. Enclaves are not allowed to modify pages that have a TSC attribute set. When the enclave attempts to modify the TCS loaded in the EPC, the OS / VMM is notified via an EF_ATTRIB_TCS failure. In the size field in the table below, a 4-byte field in both 4:32 and 64-bit modes, an 8-byte field in both 8:32 and 64-bit modes, and 8 (4): an 8-byte field in both modes ( The upper 4 bytes are ignored in 32-bit mode).

  Note: Some fields have names that begin with a lowercase “o” (eg, oLSP). These fields are pointers, but are represented in the enclave as offsets to the base of the enclave. With this notation, the measurement value of the enclave page can be made independent of the position where the enclave is generated.

Note: The fields are not listed (yet) in any particular order. Some fields may be moved to different memory pages within the branded data structure, allowing for different protection measures, for example.

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

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

The thread state can take one of five values.

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

If an interrupt occurs during execution in the enclave, 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 checks that the SSA is in the EPC and caches the physical address. If the page is forcibly moved, the processor executing EWBINVPG uses SSA to leave the enclave on the processor currently executing the thread and reports a page failure.

  FIG. 8 shows the stitching method for all data structures. To avoid complications, the structure of each thread is not shown. Untrusted stacks and associated pointers are also omitted. FIG. 8 shows an example of a thread control structure according to an embodiment of the present invention, and shows stitching between 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 save state areas available.

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

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

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

The SEC_INFO flag and the EPC flag include a bit indicating a page type.

The SEC_INFO flag is a bit set that describes and explains 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 and passed to EMKPERMIT. This structure is 4096 bytes and the page may be page-aligned.

The ERPORT structure is the output of an ERPORT instruction.

The measurement value (MEASUREMENTS) is an output parameter of the ERDMR instruction and includes measurement register values of the enclave taken from the designated SECS.

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

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

Using this structure in key derivation, a key is generated based on the enclave's security version and the enclave's SE TCB. Refer to the platform TCB reversion specification for details of the TCB security version structure.

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

The enclave page cache map (EPCM) is a secure structure that the processor uses to track the contents of the page cache. The EPCM keeps exactly one entry for each page currently loaded in the EPC.

  Attestation is a process that indicates that a piece of software is built on the platform, especially for remote entities. In the case of a secure enclave, the remote platform runs on a legitimate platform that is protected within the enclave before the software is verified for confidentiality and data protection. It is a mechanism built by a remote platform. The certification process consists of three stages: measurement, storage, and report (report).

  There are two periods in the enclave measurement period: pre-enclave construction and post-enclave construction. The enclave instruction serves to cause the constructed enclave to be measured. Once the enclave is built, the software in the enclave is responsible for taking measurements.

  FIG. 9 illustrates one step of a software authentication process called quoting that can be found in one embodiment of the present invention. In one embodiment, the signature key 915 is applied to the concatenated data from the measurement value registers 901, 902, 903, 904 by the signature processing 910. The result of the signature processing 910 is a quote 920.

  The process of reporting cryptographically binds measurements is done when creating an enclave on the platform. This mechanism is often referred to as “quoting” because this type of functionality is sometimes available on the platform as TPM commands. The value of the measurement value register (MR) is concatenated and then signed using an asymmetric key. The opposite party simply needs to verify the signature in the quote structure to prove the validity of this quote.

  FIG. 10 shows the steps for generating quotes from the measured value register set 1000 in an 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 quota enclave 1025 may include software that converts the local report 1005 into an anonymous quote 1010 or a regular quote 1020.

  Because of the nature of the calculation related to the asymmetric key and the desire to reduce the number of instructions in the enclave, an instruction that causes an asymmetric signature is not included. Our approach, shown in the diagram below, generates “reports” based on symmetric key authentication keys, and generates “reports” based on these symmetric keys using software that is itself protected using an enclave. Is converted to “quote” of an asymmetric signature. The Quoting Enclave is a special-purpose enclave known as an authentication enclave, because the Quoting Enclave itself must first be authenticated before it can access the platform certification key.

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

  FIG. 11 shows an EADD process for updating the measurement value register MR_EADD 1100 according to an embodiment of the present invention. The extension process 1115 can use the current value of the MR_EADD 1100, the page data 1105, and the page metadata 1110 as inputs. 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 the collective measurement value of the enclave. Since this is written in microcode, the enclave code needs to be placed on a SECS page that can only be read. Each time EADD is invoked, it calculates SHA256 into the page data and security metadata associated with that page (ie, this is the relative address (relative to the enclave base address) of the page and the SEC_INFO flag for the page). This value is extended to MR_EADD1100. “Extended” means new MR value = hash (old MR value || input value).

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

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

  The EEPPORT instruction generates an intermediate key for performing a symmetric key based GMAC on the measurement registers, user data, and further context information (eg, enclave functions and flags).

  In addition to the measurement register, the user can provide a 256-bit wide data block to be included in the report. The user desires proof of many application specific values (e.g., 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, REPERT is called repeatedly to generate a random 128-bit value (known as reportKeyID) generated at each power cycle of the processor and stored in an internal location. This value is incremented after 2∧32 AES processing using this value. In one embodiment, this value is incremented by one with each call to the EEPPORT instruction.

Table 5-2: EEPPORT structure

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

Table 5-4: Flags

  In one embodiment, an architecture enclave with the appropriate feature set is allowed by the architecture to obtain the key used in CMAC processing with the EGETKEY command, so the report is generated on the currently running hardware. Can be verified. This feature is limited to the Quartz Architecture Enclave.

An ERDMR (Read Measured Value) instruction is provided to obtain the measured value of the enclave when executing 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. Measurements are distributed in the form of a MEASUREMENT structure. The MEASUREMENT structure is not protected by encryption (encryption protection).

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

  FIG. 13 illustrates a counterfeit protection and replay protection mechanism that can be found in one embodiment of the present invention. Forgery protection prevents an attacker from replacing another value of encrypted data that the program did not generate. Replay protection prevents attackers from replacing encrypted data values that are not the current current value generated by the program. Node version number 1300 can 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 a MAC 1330.

  Replay protection ensures that all the contents of the enclave that the logical processor sees at any point in time belong to a single snapshot of the undamaged enclave. Therefore, the replay protection mechanism needs to define the concept of an enclave version and provide a mechanism to determine whether a counterfeit protected enclave page belongs to that version of the enclave. For this purpose, the playback protection mechanism uses a message authentication algorithm such as GMAC to bind the contents of each forgery-protected enclave page to the page version number. 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 one embodiment of the present invention. Leaf node 1425 may include version information for individual MAC content pages 1430. Each leaf node, such as 1420, includes an individual MAC content page (not shown). Each internal node 1410, 1415 may include version information of a linked child group. The root 1400 is the highest node in the tree data structure.

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

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

  In reproduction protection, the version of each page needs to be cryptographically linked to its own content, so reproduction protection requires forgery protection. Therefore, forgery protection is essential in the SE architecture. Furthermore, by implementing SE from the beginning, the list of supported protection combinations can be further limited.

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

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

  Cryptographic protection is performed by associating cryptographic metadata with each enclave page. The metadata is used by the uCode flow for various processor instructions to decrypt the content of the enclave page and verify the reliability / freshness of each enclave page. The SE architecture provides several such instructions for updating, managing, and validating its 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 requires the page to be decrypted and verified. 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 protected page.

  A security map (SMAP) is a data structure used to store cryptographic metadata necessary for verifying the freshness of an enclave page (ie, playback protection). The security map represents a full version tree of a particular snapshot of the enclave. Each node in the security map holds a version of 256 child nodes (enclave page 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 (security map depth relates to the size of the enclave supported by the SE architecture. In Gen1, the SE architecture supports a maximum enclave size of 32 GB. ), Accessed using the enclave offset of the enclave page in the enclave. The SMAP root is included in the SECS and holds only 128 child node versions. The bits in the enclave offset are used to select the appropriate child and are used to index into the SMAP. In gen1, the enclave offset is 35 bits long. The enclave offset is extracted by the following formula (enclave linear address & enclave mask). The enclave mask is determined by (enclave size-1) and can be calculated during ECREATE.

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

  Note: A security map is a logical data structure, not an architecture. The logical processor is not even aware of the location of the linear address space where the SMAP is located. System software is responsible for maintaining and walking the security map. Each individual node of the security map has a structure defined by the architecture, but the architecture does not specify how the security map is maintained in memory. However, each node in the security map has a well-defined logical location in the security map, and if a node moves around in the map, various processor instructions related to the security map Note that it is interpreted as a scenario.

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

  SEC_INFO contains the location of the SMAP within the SMAP. The position of the 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 parent must be created and resident in the EPC with the FCR bit cleared. In order to verify the integrity of the enclave page, the logical processor generates a key using IV_P and key_id in the SEC_INFO structure. This key is used to calculate the MAC for flags in the SEC_INFO structure and page content. The calculated MAC is compared with the MAC provided in the SEC_INFO structure. If the MACs match, this page can be considered to have passed the consistency check.

  When the logical processor loads a page into the EPC using the ELPG instruction, it verifies the integrity of the page. As part of this instruction, the logical processor stores the IV_P from the SEC_INF structure used for page verification (note down).

  To verify the freshness of the enclave page, the logical processor verifies that the enclave page and its smap parent are loaded into the EPC and that the smap parent is fresh. The page version is then compared with the version stored in the parent of the map. If these two versions match, the processor generates a new version of this page and updates the parent version of the map and the version of the enclave page. Finally, the enclave page is displayed as fresh.

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

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

  The enclave page cache (EPC) is a secure storage that is used by the CPU to temporarily store an enclave page that is not protected by SE encryption protection.

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

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

  Another mechanism for implementing EPC is Crypto Memory Aperture. Crypto Memory Aperture provides a cost-effective mechanism for creating cryptographically protected volatile storage using platform DRAM. CMA utilizes one or more strategically placed cryptographic units within a CPU uncore to provide various levels of protection required by customer technology. Various uncore agents are modified to recognize memory accesses to the CMA and 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 the ciphertext, depending on the desired protection level. The ciphertext is then processed to obtain plaintext to satisfy the original CMA memory request. CMA is fully integrated into the Intel QuickPath Interconnect (QPI) protocol and scaled to a multi-package platform with security extensions to the QPI protocol. In the multi-package platform 30 configuration, the CMA protects memory transfers between Intel CPUs using the link-level security (Link-Sec) engine of the externally facing QPI link layer. To do.

  SECS is referred to as active when it is currently loaded into the EPC. As described later in this document, the OS / VMM serves to manage what is loaded into the EPC. However, while loading an enclave page on the EPC, the OS / VMM tells the CPU where the SECS is for the page, unless the target page itself is SECS. If the loaded page is not SECS, the CPU requests that the SECS corresponding to that page be placed in the EPC. At any time before loading an enclave page, the OS / VMM MAY load the SECS of that enclave into the EPC.

  The CPU does not impose a limit on the number of times that SECS can be loaded into the EPC, but the OS / VMM frequently loads multiple copies of SECS into the enclave page cache. Very Hard to think. However, if multiple copies of the same SECS are loaded into an EPC, each of these copies is treated as a separate active SECS instance, and the enclave page loaded into the EPC belonging to a different instance of the active SECS is We regard it as belonging to different enclaves depending on the wear.

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

  The hardware indicates an invalid slot using a special slot of 0xFF. The EPC slot identifier is used by both uCode and PMH to track information about the enclave page.

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

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

  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 in the EPC. In the page it represents, each EPCM entry tracks information such as the enclave to which the page belongs, the linear address to which the page is moved to the enclave page cache, the version of the page, and so on. The EPCM structure is used by the CPU in the address translation flow to perform access control on the enclave page loaded in the EPC. EPCM entries are managed by (x) uCode as part of various instruction flows.

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

  In one embodiment, hardware logic may control access to memory utilized as an EPC by a translation lookaside buffer (TLB) and a page miss handler (PMH). In one embodiment, the TLB may be flushed when a secure enclave exits the EPC when there is a match in the TLB (known as a TLB hit). In one embodiment, if no search address matches the TLB (known as a TLB miss), further lookup may retrieve data from the Enclave Page Cache Map (EPCM) in multiple memory references. it can. In one embodiment, the PMH may 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 was displayed as an enclave page, compare the secure enclave control structure identifier (SECSID) of the page with the currently executing enclave to verify that the access is secure. It's okay. If the SECSID on the return page does not match that of the currently executing enclave, the PMH may issue a stop message. If the memory return page is not displayed as an enclave page, or if the memory return page is displayed as an enclave page and the SECSID for that page matches that of the running enclave, the PMH The conversion may be loaded into the TLB. In one embodiment, cache tags can be utilized to identify enclave lines from other lines in a writeback cycle. However, in at least one embodiment, the cache tag is not utilized if the logic determines that that type of memory request accesses the EPCM during a write-back cycle.

  In one embodiment of the invention, the software, BIOS, can allocate memory before the operating system boots and creates an enclave page. In one embodiment, the software can generate an EPC through a series of steps in the BIOS. The BIOS can reserve a memory for storing metadata and can set a range register for each processor. The BIOS can take a base address and a memory size as inputs. The system configuration is checked by a process called MCHECK to make a setting suitable for the purpose of protecting all registers in all packages and all cores from access outside the enclave. MCHECK locks the register until the system is reset. In another embodiment, software can add a page to an EPC with an instruction known as EPCADD that can declare a portion of memory as part of the EPC. The EPCADD sequence can take a memory address as input and can output a message indicating success or failure. When EPCADD outputs a message indicating success, EPCADD is stored in EPCM. The E bit can be set and the page corresponding to that physical address is flushed from all TLBs in 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, returns an error code of 02, and the input address is out of range. You can show that there is. Memory pages that EPCADD declares as part of EPC may require EPC semantics to access the data. In this embodiment of the invention, the software removes the page from the EPC of the instruction known as EWBINVG, making the encrypted data still available while continuing cryptographic and integrity protection. be able to. Data in this format can be stored in the normal memory of the hard disk drive. In yet another embodiment, instruction software known as EPCREMOVE can remove pages in the EPC, making encrypted data unavailable. The hardware executing EPCREMOVE clears the page and the EPCM part. EPCREMOVE can be executed without first executing EWBINVPG. In one embodiment, the EPCREMOVE sequence can remove pages from the EPC based on the memory address. In one embodiment of the present invention, the EPCREMOVE instruction includes an error code of 01 in RAX, indicating that the page being removed is part of a secure enclave control structure (SECS) and cannot be removed; An error code of 02 indicates that the page to be removed is not an EPC page. A global TLB down of a page of memory may result from EPCREMOVE in one embodiment of the present invention, and memory previously occupied by the page may be made available for general purpose software access.

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

  When an enclave is created using an ECREATE instruction, a linear address range is designated for the enclave. This range is referred to as the “linear address range” of the enclave. All memory pages belonging to the enclave linear address range are under enclave protection and can be considered to have associated SEC_INFO entries.

  A memory page belonging to a linear address range of an enclave is also referred to as an “enclave page”. A program running in an enclave is allowed access only to an enclave page that is loaded in the enclave page cache and is the enclave that is the owner of the page. Otherwise, the processor generates an exception class event. The OS / VMM is responsible for loading enclave pages into the EPC as needed.

  When a logical processor is performing an enclave and creates a memory access for that enclave page, this memory access is referred to as “enclave access”. A dress check may be performed to ensure that it is being accessed by the correct entity.

  In one embodiment, the PMH provides an access control function 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 begins to execute the enclave code. In its place, the processor places a special page table in place. These page tables allow access only to EPC pages owned by the enclave under the control of the processor. The processor and microcode use these two mechanisms to restrict access to the EPC.

In some embodiments, a number of axes such as performance, implementation complexity, and silicon cost may be coordinated. This chapter introduces three implementations to show some of the possible adjustments to developers. 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-extensions. The range register may be enabled for each logical processor. An example of basic implementation that uses this mechanism is shown in Figure 2-2.

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

  FIG. 15 illustrates one embodiment of the present invention illustrating the implementation of a page fault error code map. If bit 51540 is set, bit 9, bit 8, bit 7 and bit 6 can be decoded together to determine the 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 page is not in the EPC, a “bad” is provided to the OS / VMM to convey that effect. As shown in Table 8-2, the page failure error code map is changed. This indicates a new bit 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 software may decode bits 6 through 9 to resolve the EPC failure condition. More information about the defect type is given in the next section.

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

  To protect EPC from attacks, a mechanism that invalidates the EPC address of all TLBs on the platform can be used. This feature can inform all cores of the invalidation of a specific page. Next, it waits until it receives a shooting completion report from all the processors.

  Each time an enclave exits (EEXIT), the TLB may forbid access to an enclave page that currently exists in the TLB. This can be done by clearing the TLB or by tagging the enclave entry using additional bits.

  Another method is to clear all enclave entries using the enclave bit in the TLB when leaving the enclave. Another method uses several bits to identify a particular enclave. In this case, the enclave entry need not be forcibly removed. The enclave entry may be left in tlb. If the address is sent to tlb for lookup, these bits are added to the lookup. These bits are compared with the enclave id from the core that indicates the identity of the enclave. If the bits match, the request is from this enclave. If it does not match, the lookup will not hit this position because the request is not from this enclave.

  Enclave authentication provides a means of finding an authorized authority (ie, the author / approver of this code) that has authorized the enclave code to execute within the enclave. Enclave certification also provides a foundation to outsource enclave microcode flow, flexible seals & reports, and some new business model implementation points.

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

  Enclave seal storage provides enclave software with the ability to encrypt data to certain attributes of the enclave (eg, load time measurements). The enclave proof framework allows an enclave to provide outside entities with evidence of measuring the enclave. In many situations, proof of the data seal or source of the enclave is preferable to the exact software hash of the enclave.

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

  Enclave authentication is divided into two parts. Each enclave is accompanied by an enclave license with a signature chain that can be rooted back to Intel. The enclave license indicates the source / responsibility entity of the enclave, the special features required by the enclave, and the additional information needed to identify the specific business model / arrangement that implements the enclave. The license may be for a special enclave, which indicates the measurement value for this enclave, or for a key that will later be able to sign the enclave if necessary .

  For example, consider the case where A purchases a license for manufacturing an enclave used by A's video player. For this purpose, Intel generates a license regarding the root key of the video player of the seller A and the functions that the seller A is allowed to use in the video player enclave. Next, merchant A uses the video player's root key to sign an individual license file for each video player modified version to be released. As a result, the enclave license chain includes a plurality of intermediate licenses.

Since signed license chains are not ideal for evaluation during the enclave activation process, they are instead replaced by a single instruction executable structure called a permit. digestible structure). The permit is symmetric authenticated using the CMAC algorithm and interpreted during enclave initialization (EINIT).

  Most of the parts of the license are copied to the permit and have a similar structure. The license ID is a 64-bit numerical value for specifying a business agreement. The license type specifies the platform to which the license is applied. A 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 license 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 the security version number for this version of the enclave. This way, the data sealed by this version can be made available for future versions rather than the previous version. The flag field indicates a flag for the enclave that can be set to apply this permit. The function mask is a bit mask of special functions that can be allowed for this enclave. The parent key hash is a hash of a public key obtained by signing the enclave license and hashing the key with the signed public key. The entity hash is an expected hash of the entity to which this license applies. In the case of an enclave, this is the MR. This is the value of EADD. For license keys, this is a hash of the public key.

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

  Not all enclaves require a permit. To facilitate the development of the enclave, permits are optional during development and during the debugging phase of the software life cycle. The following policies are enforced by EINIT. Non-debug enclaves always require that a license be launched. The debug enclave is launched without a permit. However, if no permit is presented to EINIT, MR. Policy, ISV Sec version, Permit See Version, and function are all set to zero.

  When the permit is used for starting the debug enclave, the permission-> flag “debug” can be set, and only the function permitted by the debug enclave can be set as the permit.

  FIG. 16 illustrates an example of a process for generating a permit to launch an enclave according to one embodiment of the present invention. This process can have three stages: permit issuance 1600, further license approval 1640, and initialization enclave 1680. In the license issuance 1600 stage, the ISV key permit 1615 can be generated by executing the EMKPERMIT instruction 1612 on the ISV key license 1610. An enclave permit 1625 having a CPU only MAC can be generated by issuing an EKPERMIT instruction 1612 to the enclave license 1620 and the ISV key permit 1615. In a further license approval 1640 stage, an enclave permit 1625 with a CPU-only MAC and a third party enclave 1642 corresponding to the licensed information enters the license enclave 1644, where the license enclave 1644 is a MAC for the CPU. And an enclave permit 1645 with license. In the initialization enclave 1680 stage, the enclave SECS 1682 and the enclave permit 1645 with the MAC and license for the CPU may be input to the EINIT 1684 instruction. The output of EINIT 1684m is an ISV enclave 1685.

  To activate the 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 phases: permit issuance, further license approval, and enclave initialization. FIG. 16 shows the flow of this process.

  A license is generated from the license using a new command called EMKPERMIT. EMKPERMIT generates a single license from a single license, but can be called continuously to convert a chain of licenses into a single license with MAC using a license key. it can. The next section details this.

  Each license includes a “license type” that determines the further steps that can be taken to make the permit available. The license for each platform requires the cloud licensing authority to maintain the billing amount for the platform on which the enclave is located. This type of license requires additional steps. That is, an architecture enclave, called a license enclave, negotiates with the cloud licensing authority and, when approved, provides additional MAC to the permit using the license key. For example, an architecture enclave is always a bulk license, which means that a license key MAC is not required to execute. They run on any platform that supports secure enclaves.

  A permit is implemented in the initialization of the enclave. If the permit is processed during initialization and the enclave measurement matches that in the permit, the MAC is correct and the enclave is activated. EINIT looks at the type of license and examines only the license MAC for licenses that require further approval.

  EMKPERMIT is a privileged instruction because of the time required to verify the RSA signature on the license. This instruction takes a very simple signed certificate that conforms to the uCode patch format and verifies and generates a permit from its contents. The license includes both the signature and the public part of the key used to sign it. Thereby, uCode can authenticate the license signed by Intel by storing only the hash of the license signature key of Intel. The EMKPERMIT can also authenticate the license signed by the ISV key by providing an authorized authorization of the key. This is done by creating a permit containing a hash of the ISV's public key. As a result, EMKPERMIT can verify the Intel license using the Intel license using the internal hash or the ISV key having the hash provided in the second permit.

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

  In the case of ISV, the ISV key has a license signed by Intel. To call EMKPERMIT without using a key certificate, use Intel's key hash to verify the signature on the license, generate a license that authorizes the hash of the ISV key, and provide a legal license signature key. Represent. Then call EMKPERMIT again (including ISV key permit). EMKPERMIT authenticates the MAC of the key certificate and uses the hash of the ISV key that previously used the Intel hash. Assuming that the enclave license's public key hashes the value of the ISV key and the enclave license thereby signs appropriately, EMKPERMIT generates a license for the enclave. This permit indicates the license information (which may be consistent throughout the chain), the hash of all public keys in the license chain, the enclave measurement, 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 the range where uCode is visible. For example, uCode evaluates whether further enclave placement is permitted due to business arrangements with ISV's Intel. The license enclave is designed to collect all the materials that need to be assessed and to further approve and 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).

  The license enclave is expected to be a system service. If the license indicates that further approval from the license enclave is required, the license chain generated by EMKPERMIT and the enclave permit are passed to the license enclave. The license enclave then generates an approval request. The application then sends this approval request to the appropriate license authority, where an approval notification is generated. Returning to the license enclave, the license enclave MACs the permit in the license MAC field using the license key.

  When a permit is issued to the enclave, it can be evaluated and implemented using u-code in the enclave maneuver process. This is implemented as part of the EINIT command, using the linear address of the permit as a parameter. (1) Copy the scratch pad permit, (2) Verify cpuMAC on the permit using the permit key, (3) License type! = If bulk, the license MAC is verified using the license key. (4) The measured value in the permit is changed to MR. Compare with EADD, (5) Compare flag in permit with flag in SECS, (6) Set pubkey hash in permit to MR. Add additional steps to EINIT as part of the authenticated enclave mechanism: Copy to Policy, (7) Copy ISV SVN to SECS, and (8) Copy the function map in the permit to SECS.

<Function>
The current function map is a 128 bit mask function available for this enclave.

  The space is organized based on the actions taken by EINIT. Bits 00-03 are reserved for future use when a ring level constraint is activated on this enclave. 04-07 is reserved to indicate page protection allowed in the future. 08-23 is a processor key that can be used through EGETKEY. 24-31 is for other controls (e.g., using name-based mode for certification, or for technologies that wish to be restricted in the future). Some features are not used by the enclave in debug mode. The debug column indicates whether a function is legal in the debug mode.

  In future generations, bit 00 may indicate that ring level and VT constraints apply to this enclave. Bit 01-02 indicates the ring level at which the enclave is allowed to execute, and bit 02 indicates whether the enclave is executed in the VT root mode. At each EENTER, the current CPL is compared 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 on 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 active. In the first generation, these bits are MBZ.

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

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

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

  Provision Enclave has KEY_PROVISION functionality, is approved by Intel, and runs on a single package platform each time a new Device Certification Key (DAK) or Provision Certification Key (PAK) is required The The purpose is to let the enclave derive the device ID & provision key based on the provision seed provided by EGETKEY. The provision enclave then uses these keys to prove the validity of the platform to the provision server and obtain a device certification key (DAK). After obtaining the DAK, the Provision Enclave optionally uses the DAK to authenticate with a Platform Certification Key (PAK) provider and retry the PAK. By using a PAK, guaranteeing for a particular ISV can provide the user with better privacy and the 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 Quarting Enclave can obtain it.

  The quota enclave has the function KEY_REPORT, is approved by the enclave, and has the same author as the provision enclave (usually Intel) used to provision the EPID key. The location is an OS service that is available for all apps. Its purpose is to let the enclave unseal the platform EPID key. A report from EEPPORT is provided as input. The enclave obtains a report key using EGETKEY. The report key is then used to verify the report. The enclave signs the quotes using the EPID.

  The license enclave has a KEY_LICENSE function, is authorized by Intel, signed by Root Intel, shipped with the enclave (OS service), and instantiated alone. Its purpose is to evaluate complex license policies. If the enclave requests further license confirmation from the license enclave, EINIT can accept it only after the license enclave has CMACed 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 whose structure is a consistent SE key hierarchy across all secure enclave implementations. The keying material for TCB reversion and the basis of EPID provision is provided by the SE TCB hierarchy, which serves as the root of the SE key hierarchy. All keying material utilized in both the enclave instruction set and the trusted architecture enclave is provided by the SE key hierarchy.

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

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

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

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

The SE TCB portion of the key hierarchy is platform specific and all foundations require the same basic key set. We call these base keys. These are all derived in the fuse key and logical key and are the root of the SE key hierarchy. These keys are then used by the SE instruction to derive all 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 are made available to the SE architecture through platform specific mechanisms. Table 12-1 shows these keys.

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

  FIG. 17a illustrates one embodiment of a multi-package key hierarchy.

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

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

  Permit key 1754 is used to provide legitimacy and integrity to the permit, including enclave functionality and license information. The permit is MACed and its consistency 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 cannot be evaluated by uCode (is used assert compliance with). The license key is used to generate an authorized authorization from the license enclave that EINIT evaluates. This key used by EINIT uCode is available via EGETKEY and is enclaveed with the KEY_LICENSE feature set.

  Report key 1758 is used to provide the legitimacy and consistency of the report. The report is MACed by ERREPORT and verified for consistency during the transition to the quota enclave. This key is used by the ERAPORT uCode and is available via EGETKEY to the enclave with the QUIOTE function set.

  The authentication key 1760 is an enclave-specific key and is used to provide the correctness and integrity of data sent from the quartering enclave to the ISV enclave and provides enclave-to-enclave authentication on the same platform. Keys are made available to all enclaves via EGETKEY, and an enclave with an ISV_AUTH function set can identify the keys it needs.

  Seal key 1762 provides 128 bits to each enclave to encrypt the sensitive data they contain. By integrating multiple seal policies into this seal key, the ISV can have the flexibility to use which software to unseal the data. These keys are available for any enclave via EGETKE, but individually the seal keys are only available for enclaves that meet the required seal policy.

  The EPID ID 1712 uniquely identifies the package. Its sole purpose is to allow provisioning of device certification keys, which are EPID-based anonymous certification keys. The EPID ID is accessible only to the provision enclave. Provision enclaves provide this only to authorized provision servers via a secure channel, and only during the provisioning process initiated by the user or operating system. This ID can be used via EGETKEY to an enclave having a PROVISIONING function.

  Provision key 1710 is used to prove platform validity to the Intel backend and to authenticate the execution of the current SE TCB. By indicating access to the provision key, the provision server can ascertain that the enclave is actually a device that has an EPID ID and is running on at least a particular TCB security version. The provision key is unique to the signer of this package and the provision enclave that requires it. This allows separation between these multiple provision infrastructures when used on a single platform. This key can be used for an enclave having a KEY_PROVISION function via EGETKEY.

  The provision seal key gives a 128-bit key to the provision enclave so that the provision can be encrypted in an obtainable manner even after ownership changes. By encrypting the old EPID using this key, it is possible to prove that the platform has become invalid during acquisition of a new EPID. The provision key is unique to the signer of this package and the provision enclave that requires it. This allows separation between these multiple provision infrastructures when used on a single platform. This key can be used for an enclave having a KEY_PROVISION function via EGETKEY.

  The ISV Out of Box (OOB) experience key 1700 is a shared key between all Intel platforms and ISVs. This key is derived from the OOB root that is specific to a particular ISV. The ISV can purchase access to this key and encrypt the secret against this key and place it in the OEM hard disk image. These secrets are only accessible by those codes that are securely executed within the secure enclave, and the platform does not need to perform online operations or full proof key provisioning. These keys can be used for an enclave having an OOB function via EGETKEY.

  The provision key is an important key to a secure enclave architecture, but is not derived from platform keying material. These keys are provisioned from a provision server or off-line technology. The device certification key (DAK) is the use of an anonymous signature key (EPID) to prove the characteristics of individual enclaves. This is used by the ISV during key or secret provisioning to ensure that this sensitive information is sent only to protected installations of untampered applications.

  There are two sources of device certification keys. The preferred architecture ships the initial DAK that is compressed with a fuse as an EPID key blob and EPID entropy. This allows the platform to begin certification immediately after the first power up. The second source is downloaded after contacting the DAK provision server and using the EPID ID and provision key to validate the hardware. 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 having a PROVISIONING function via EGETKEY.

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

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

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

Each key has a predefined set of derived elements, which includes a derived string. Table 12-3 shows the elements included in each key of the key hierarchy. Each column represents a key, and a row indicates whether that key contains a particular element. The debug string is included if the SECS of the enclave issuing the request indicates that it is in debug mode, and “request” is not required for this element and can be selected in the request for key derivation. It shows that there is.

  Secure enclaves support technologies that isolate and recover software security breaches at several points in the boot sequence. In order to support separation, all long-term keying material provided to the enclave is derived utilizing the current TCB security version.

  This section describes an example of a platform architecture where the recoverable TCB consists of uCode, MCHECK, and microcode extension (or uVMM). The hardware requirements may be the same for any SE support platform, but the specific keyflow depends on the specific TCB element. Other platforms can be supported using techniques similar to those used here. On platforms that support patch-at-reset, this mechanism compliments the patch at reset and restores uCode fully (provides evidence of separation by upgrade and encryption in modified uCode). Can be included).

In order to support CPU-based protection technology, the hardware requires the following keys: These keys are the basis for the TCB key hierarchy.
<256-bit logical key unique to stepping>
The 256-bit logical key is divided into two parts: a 128-bit fuse wrap key and a 128-bit out-of-box experience key. However, a single 128-bit key that adds uCode can 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 preseed. 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, placed on the package, and made available only to uCode. Two 128-bit registers are required during the platform runtime. Until the CMA is up and running, additional 256-bit space is required for the EPID key. After this, the additional 256 bits are not needed by the CPU.
<TCB SVN register>
This register is a 64-bit lockable register divided to hold SVN in each TCB layer. The way of splitting is at the discretion of the platform designer, but it seems reasonable to split it into eight 8-bit SVNs. Each part of this register can be locked independently.

  Combining keys into a specific set of TCB versions is based on the type of maneuver sequence that is initiated from the fuse key to the first set of keys (ie, whether to patch at reset or patch later) This is done by deriving to uCode. After locking this fuse, a chain of derivations is performed at each loading of the activation sequence.

  After loading the low level code, the chain continues to contain the ISV assigned security version of the software running in the enclave. In certain configurations, keys derived from the current version and keys from previous configurations can be accessed. Thereby, user data can be transitioned to a new stable version without interruption.

  Once the die-specific key is generated, it is encrypted with the key wrap key. This makes it increasingly difficult to extract keys using a hardware monitoring tool and protect the passing keys 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 pseudo-random 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 goal is to provide an irreversible way to derive keys from other keys. This section uses the following function prototype:

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

As a result, the data is migrated forward. Take the case of executing uCode SVN3 as an example. The enclave uses EGETKEY to obtain a seal key based on this version (PRELoop (3)), and uses this to seal the data. Deliver field uCode patch upgrade, the next boot uCode SVN is 4. After the upgrade, the EGETKEY implementation will be able to access PRFLoop (4). If the enclave requests EGETKEY to send the SVN3 key, it can calculate PRELoop (3) = PRF _{PRELoop (4)} (constant) to obtain the old seal key.

To build this characteristic, a PRF loop is used. Since the characteristic 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 maximum values need to be built for each platform type based on the patch and the likelihood of performance required. 32 is recommended as the initial maximum value. The PRF loop derivation is as follows.

  This method is used to populate uCode SVN into the SVN key and is the basis of the SE-based key. The die unique key to be fused includes a 288-bit EPID value and a 256-bit random key. All non-ephemeral symmetric keys can be derived from these 256 bits (consisting of two 128-bit keys). Therefore, it is possible to create a technique for deriving a plurality of keys from a single key. To do this, once the fuse key is decrypted, it can be used to call the PRF using a different fixed constant. When a key is divided, it generally takes the following form.

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

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

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

  FIG. 18 shows an example of a microcode-based secure enclave key hierarchy in one embodiment of the present invention. In the reset microcode 1800 hierarchy, the global wrap logic key 1801 and the unique root fuse 1802 known to Intel are utilized as inputs to the unwrap 1806 function. The outputs of wrap release 1806 and microcode SVN 1805 are input to PRF loop 1808. Microcode SVN 1805 and global root logical key 1803 enter another PRF loop 1809. The output of the PRF loop 1808 is stored in the SVN key 1810 register. The output of the PRF loop 1809 is stored in the global key register 1812. Microcode SVN 1805 is stored in TCB SVN register 1814. Global wrap logic key 1801 and SE EPID A.x fuse 1893 are input to the unwrap 1807 function and store the result in the SE EPID 1816 register. In the MCcheck 1820 hierarchy, the outputs of the MCcheck 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. The global key register 1812 is stored in the global key register 1824. The SE EPID 1816 is stored in the SE EPID 1828. In the loaded 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. The global key register 1824 is stored in the global key register 1834. The SE EPID 1828 is stored in the SE EPID 1838. In the XuMSR derived key 1840 hierarchy, the microcode SVN difference 1841 enters the PRF loop 1842 and the PRF loop 1844. Microcode SVN 1832 register sends data to PRF loop 1842 and global key register 1834 sends data to 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, a unique root fuse 1894 that Intel does not know is stored in seed 1 1856 and an EPID group ID fuse is stored in EPID group 1858. 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 a 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, the SVN base key 1850 is stored in seed 0 1876. Seed 0 1876 enters PRF loop 1878 and PRF loop 1880. The output of PRF loop 1878 is SE EPID ID 1882 and the output of PRF loop 1880 is SE EPID seed 0 1884.

  All cores are synchronized and utilize a doorbell or similar mechanism to ensure that everything enters the MCHECK. When all cores are executing MCHECK, (1) uCode reads, decodes, and locks the fuse. (2) uCode uses the PRF loop as the SVN key and the PRF loop as the OOBE key. Insert uCode SVN into both keys. uCode writes its SVN into the TCB SVN register and locks that part, (3) MCHECK loader or early MCHECK code writes and locks MCHECK's SVN into TCB SVN register, (4) Microcode extension patch Each step from the BSP is that the loader writes and locks the microcode extension patch SVN into the TCB SVN register. APs do not participate in keyflows.

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

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

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

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

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

  Many enclave architectures use keys to provide authentication and confidentiality of enclave data, and use architecture enclaves for high-level usage to minimize processor complexity. Process these keys. For example, the quota enclave uses the REPORT key to confirm that the REPORT structure generated by the ERPORT instruction has been created on the platform, and the PERMITTING enclave uses the PERMIT key to start the enclave. Generates an enclave PERMIT consumed by EINIT when done.

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

The mechanism for doing this is the EGETKEY command. This is a single interface for building secrets about the current software environment.
EGETKEY currently provides access to the following keys: (1) Provision key ID (to identify the data blob that is uniquely encrypted (using the provision key) for the processor (2) Provision key (used by Architecture Provision Enclave to decrypt data blob uniquely encrypted for the processor), (3) Provision seal key (Used by the architecture provision enclave to encrypt the EPID in such a way that the enclave can be decrypted even if the owner changes), (4) a permit key (an architecture to create a permit) (5) Report key (Report) (6) ISV AUTH key (ISV AUTH KEY) (to create authentication data for a specific target application enclave to verify the structure) (Used by the enclave), (7) Authentication key (AUTH KEY) (Used by the application enclave to authenticate the data received by the architecture / quoting / enclave), (8) Seal key (stored outside the enclave) (9) OOB experience key (for example, BluRay player) for pre-provisioning encrypted data for out-of-box experience utilization (eg, BluRay player) To use).

  Most of these values are raw and do not reside in the processor, but are actually derived from a single fuse key value in response to EGETKEY requirements. Derived on demand when each of these keys is not a single key but a single key from a possible set. The specific key delivered depends on a number of parameters, some of which are user selectable and others based on the system or specific conditions.

To select a key, the key request structure is used as an input to the EGETKEY instruction. In addition to selecting a key, the user uses a key request structure to cause the caller to identify those variables under control that he wishes to use during key generation. The following drawings show the key request structure.

  The key selection is used to identify the key that 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 specific security version of an architecture enclave, a specific version of an application enclave, or 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 particularly necessary to prevent key exhaustion and is used by the PERMITTING and QUATING architecture enclaves. It is also used by the application enclave when creating a seal key (SEALing key). A field set to zero means no randomness is added, otherwise the field will point to a 256-bit aligned data value. The following table specifies the structure of the key selection field.

The key policy is a bit field selector and 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 function before the next reset. The second enable is provided to the OS or VMM to switch the enclave function ON or OFF as needed.

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

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

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

  Software can detect enclave support by executing a CPUID instruction. CPUID returns a result indicating whether enclaves are supported.

  When the bit Opt is cleared, the CPUID reports that it does not execute the 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 a CPUID instruction. Enclave support is indicated when the ON bit is set in the enclave CTL MSR.

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

  The enclave base address register on each processor contains the low address of the executing enclave and is loaded when the enclave is entered by microcode. The register size is based on the processor mode. This register is invisible to software and is a temporary microcode.

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

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

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

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

  In general, the external interface does not allow transfers or transactions that can compromise the security of the enclave. A secure enclave requires a random number for the enclave key. The random number generator is securely accessible by microcode. There is no need to place it in the core of the part.

  FIG. 26 illustrates a processor package for a digital random number generator in one embodiment of the invention. The processor package 2600 can include a plurality of cores, core 0 2640 and core 1 2670. Core 0 2640 may include external instruction microcode 2642, internal function microcode 2644, internal function microcode 2646, RNG microcode module 2650, and RNG queue 2654. Core 1 2670 may include external instruction microcode 2672, internal function microcode 2675, internal function microcode 2676, RNG microcode module 2680, and RNG queue 2684. Read random instruction 2630 may communicate with external instruction microcode 2642 and read random instruction 2635 may communicate with external 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 that connects to an online self test 2606. The output of the online self test 2606 may be one input of a combined regulator / deterministic random bit generator (DRBG) 2620.

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

  The enclave created by the debug bitclaire is a generation enclave. The enclave includes a debug bit that indicates that the enclave is a debug enclave. The enclave remains encrypted in main memory or on disk. A debugger that 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 run and runs 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. Register DR7 2700 includes L0 2702, L1 2706, L2 2710, L3 2714, G0 2704, G1 2708, G2 2712, and G3 2716. Other bits of the DR7 register 2700 are: LE2718, GE2720, 001 2722, GD2724, 00 2726, R / W0 2728, LEN0 2730, R / W1 2732, LEN1 2734, R / W2 2736, LEN2 2738, R / W3 2740, And LEN3 2742.

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

  For debug enclaves, the value of the debug register is not changed. RFLAGS. The TF is set at the start of the EENTER command and needs to take the following two cases into account.

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

  The SE-aware debugger is intended for debug mode enclaves.

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

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

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

  This document describes a novel technique for performing CMAC mode processing for AES block ciphers. CMAC is a mode that supports message authenticity, accepts message A and key K as input, and returns an authentication tag T. The authentication tag is derived using a CBC (encryption block chain) algorithm. CMAC is more complex than CBC because it includes a protection mechanism against length extension attacks. These are referred to as “three characteristics of CMAC”. In the following, CBC and CMAC are outlined.

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

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

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

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

When L is derived, the most significant bit of L is checked. If this is zero, the K _1, by 1 bit shift to the left is derived from L. Otherwise, the 1-bit shift to L to the left, and XOR with a special value R _b, to produce a K _1. R _b is defined as (0 ¹²⁰ 10000111) in binary format. K _{2 is} also generated from K _{1 in the} same procedure. Derivation of the subkeys K ₁ and K ₂ is shown in the following pseudo code. MSB () indicates the most significant bit of a value.

  The second feature of CMAC relates to padding before using the CBC algorithm for input data. If the last block of data is not a complete block, the block is padded with the necessary number of zeroed bits to make the final block complete.

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

In the following, an example of how to implement the CBC () algorithm when a symmetric key block cipher is used as AES and the processor supports an AES round acceleration instruction set is shown. The Intel architecture supports four new instructions in the Westmere processor (2009) and subsequent time frames. These instructions are AESENC (AES round cipher), AESENCLAST (AES final round cipher), AESDEC (AES round decryption), and AESDECLAST (AES final 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 flowchart associated with encryption of multiple AES blocks utilizing the CBC algorithm.

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

  The CMAC is indicated using a 128-bit quantity of big endian description. In order to accurately implement CMAC using a little endian machine, it is necessary to perform a 16-byte width reflection process at a certain point of implementation of the source code. This processing can be quickly performed by using a PSHUFB instruction (one clock latency, throughput). The following points describe when byte shuffling is necessary.

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

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

  function_pshufb () performs byte reflection of 128-bit width.

<SE requirements for SMI>
The enclave is not allowed to execute in the SMM space. Attempting to run the enclave in SMM mode results in a GP failure of the instruction. If SMI occurs while executing in the enclave, the processor saves the register state in the remote enclave and exits. When finished, the TBD MSR bit is set to indicate that an SMI occurred during enclave execution. The SMM code cannot access the claim data. Attempting to touch the EPC area will return junk data in the actual mode and return an EPC page failure in the protected mode.

Some instructions are not allowed to execute. Several general rules are used to determine which instructions are legal.
1. Ring level changes are not allowed within the enclave. Ordering ring level changes or possible changes is prohibited.
2. External software cannot service VMEXITS in the enclave. Forbid all instructions that create or may generate VMEXIT in the enclave.
3. The software cannot create a virtual machine within the enclave. Forbid all VMX instructions.
4). Instructions that perform I / O references inside the enclave are prohibited.

In the first generation of enclaves, the processor may run on ring 3 with the IOPL set at 0 when entering the enclave. The instructions listed in Table 18-1 are legal for preserving the programming environment when running the enclave in a virtualized or non-virtualized environment.

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

  The life of an enclave can be classified as distinct phases. The first stage is enclave formation. The second stage is enclave utilization. The final stage is enclave destruction.

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

  Some instructions support enclave verification, confidential data sealing and unsealing, and authorized enclave authorization.

  In the first stage, the enclave may be securely constructed and an internal software environment set up for use by applications. An enclave is generated using three instructions. The first instruction ECREATE sets the initial state environment. This instruction generates, loads, encrypts the enclave key, and performs a two-page consistency check that is used to store the enclave data structure. The second instruction EADDPRE adds one page of data to the enclave. For more information, add the necessary pages for the code, stack, and heap in the enclave. The third instruction EINIT sets the internal software environment to a known state. Upon completion of this command, the enclave has moved to the second stage, “use”.

  Prior to running EINIT, the building software may have obtained a license by running EMKPERMIT or by using an authorization enclave.

  The enclave is input by an EENTER command. This command causes the machine to enter enclave mode. Then, control is transferred 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 the enclave via EENTER or EIRET, the following processing is executed according to instructions. That is, the processes are saving and clearing GDTR.limit, LDTR.limit, IA32_EFER.SCE, and IA32_SYSENTER_CS. When exiting, restore GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS (On exit restore GDTR, LDTR, IA32_EFER, and IA32_SYSENTER_CS).

  There is no command to destroy the enclave.

  The EDBG_READ instruction reads 8 bytes at a certain position in the debug enclave. Access is not allowed for non-debug enclaves. The EDBG_WRITE instruction writes 8 bytes to a certain location in the debug enclave. Access is not allowed for non-debug enclaves.

  The enclave page cache (EPC) is managed through two instructions. Two instructions load / store EPC pages (ELPG and EWBINVPG).

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

Note ² : Although there is no model available for “internal”, there is no known damage related to permitting execution from the inside to EMKPERMIT.
Note ³ : In future versions, it may be possible to enter the enclave from Ring 0 as well.

  When an interrupt occurs, the processor state is saved (hidden) in the enclave and the state is cleared. Further, the return address of the interrupt may be hidden.

  Interrupts that occur during enclave execution push information to the form of an interrupt stack as expected by the operating system so that there is no need to change the OS code. To accomplish this, a pointer to the trampoline code is pushed as a RIP onto the interrupt stack. This trampoline code eventually returns to the enclave with an EENTER command having a special parameter (q.v.).

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

  FIG. 23 illustrates one embodiment of the application and interrupt stack after interrupting with a stack switch. The current save state area frame 2300 includes an RSP register 2305. Thread control structure 2310 may include a count 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 application stack 2320 and the save state area 2300 count. Error code 2342 may come from RSP after push 2346. The interrupt routing routine 2314 and the instruction register 2340 send a trampoline for each uRTS 2344 thread.

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

  TCS :: IRR (Interrupt Return Routine) points to a code sequence for each thread that later returns to a special thread. This pointer is pushed onto the interrupt stack as a return RIP. This causes the set of data structures to return the IRET to the application where the interrupt return code (including the special EENTER command) is executed. EENTER takes an RBX register that is initialized at the time of interruption, uses this as a TCS, and reenters the enclave.

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

  FIG. 24 illustrates how a stack of multiple state save area slots can be implemented in one embodiment of the present invention. 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 identifies the location 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 1 2412). The state save area slot 2406 specifies a position used in the state save area (state save area N 2418).

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

  When an interrupt occurs during execution 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 increments TCS :: CSSA. As will be described later, if an exception occurs in the last slot, the exception cannot be sent to the enclave.

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

  FIG. 25 shows a portion of a state machine with interrupt, bad, and trap state transitions. Possible states are inactive 2500, active 2510, expectation 2520, processed (EENTER illegal) 2530, and in process 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. Active 2510 transitions to expectation 2520 when an interrupt, fault, or trap 2512 occurs. When EIRET 2514 occurs, expectation 2520 transitions to active 2510. When EENTER is placed in TCS: HANDLER 2524, expectation 2520 transitions to in-process 2540. When EIRET 2522 occurs, expectation 2520 transitions to 2540 during processing. When an interrupt, bad, or trap 2526 occurs, the in-process 2540 transitions to an expectation 2520. When EEXIT 2532 occurs, in-process 2540 transitions to processed 2530. When a processing interrupt occurs in the enclave exception handler and EIRET 2534 occurs, processed 2530 transitions to in-process 2540. When a processing interrupt that is not from the enclave exception handler occurs and an EIRET 2534 occurs, the processed 2530 transitions to the active 2510. Dotted transitions 2522, 2526, 2534 occur only during the handling of interrupts in the enclave exception handler.

  FIG. 25 shows the portion of the enclave state machine that handles interrupts. Interrupts begin by pushing a composite interrupt frame to the optional stack switch and interrupt stack. If the event is an interrupt, the enclave enters the interrupt state. If the event is an exception, the enclave enters an exception state. These two states are differentiated to ensure delivery of enclave exceptions to the enclave and to further prevent delivery of spurious exceptions by attacking application code.

  Upon transitioning to the interrupt state, the untrusted code (application, OS, or both) only needs to restart the enclave using EENTER / RETURN_FROM_INTERRUPT.

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

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

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

The ECREATE instruction initializes the protected SECS. The source operand points to the page_info structure. The content page field points to an unprotected SECS structure. The SECS structure may have pages aligned. The SECS base lower 12 bits and the boundary value may be zero. SECS is the address of an empty slot in the EPC. sec_info is the address of the unprotected sec_info structure. The corresponding sec_info flag field may be appropriately initialized.

<EADDPRE>
<Description of instruction>
EADDPRE causes privileged software to copy a page outside the enclave to a 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 extended to the enclave's measurement value register. EADDPRE can only be executed for enclaves that have not yet been initialized by 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 enclave instruction may be used to access the enclave page. EALLOCATE is only executed for enclaves that have been initialized by the EINIT instruction.

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

<EINIT>
<Description of instruction>
EINIT displays the enclave as ready for execution in the software environment. Finally, when initialization is successful (At the end successful initialization), EENTER is permitted to the enclave.

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

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

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

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

<EADDDSMAP>
<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 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 accepts a change to the SEC_INFO field using this instruction. Thereby, SMAP can be updated to a new page type.

<EENTER>
<Description of instruction>
The EENTER command passes execution to the enclave. At the end of the instruction, the CPU is running in enclave mode with an IP specified by TCS oENTRY or oHANDLER. EENTER confirms that the TCS is valid and can be entered. The TCS and corresponding SSA may reside in memory to continue the instruction. EENTER also checks the state machine to determine the type of entry and ensures that only one logical processor is active at a time in the TCS. RFLAGS. TF has a slightly modified behavior on EENTER. RFLAGS. TF is TCS. Stored in SAVE_TF, and then TCS. Loaded from TF. Next, the debug exception is RFLAGS. Conditionally generated according to the update 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. Behavior of TF>
RFLAGS. At the start of execution of EENTER The value of TF does not affect the trap when EENTER is completed. RFLAGS .. loaded from TCS. The value of TF determines whether a 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, set IA32_DEBUG_CTL MSR to TCS. Save to DEBUG_CTL and clear.

<EEXIT>
EEXIT exits out of the enclave.
<Description of instruction>
EEXIT disables the enclave mode and branches to the position specified by the RBS. This instruction does not affect the register. If secrets are contained in any of the registers, it is up to the enclave software to clear these 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 a condition CR-0021 in accordance with the update value of TF. When the enclave is not in the debug mode, the debug register DR7 is set to TCS. Load DR7. This behavior and RFLAGS. What is the behavior of TF? ? ? Is described in detail.

<RFLAGS. Behavior of TF>
RFLAGS. At the start of execution of EEXIT. The value of TF does not affect the trap when EEXIT is completed. RFLAGS. The value of TF determines whether a trap is taken.
<DR7 behavior>
When the enclave is not in the debug mode, the debug register DR7 is set to TCS. Load DR7.
<Behavior of IA32_DEBUG_CTL>
If the enclave is not in debug mode, set IA32_DEBUG_CTL MSR to TCS. 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 that was suspended due to an exception or interrupt. EIRET verifies that the TCS is valid and can be resumed. The TCS and corresponding SSA may reside in memory for instructions to proceed. EIRET further checks the state machine to determine the type of entry and verifies that only one logical processor is active at a time in the TCS. RFLAGS. If TF is set on EIRET, a debug exception occurs on completion of the instruction (ie normal TF behavior). This exception is reported as occurring in the enclave (in the manner defined in normal SE) and no instructions are executed internally. Since EIRET restores RFLAGS from SSA, TF may be set at the end of EIRET. In this case, TF affects the following instructions (this is also normal TF behavior):

<RFLAGS. Behavior of TF>
RFLAG. If TF is set at the beginning of the EIRET instruction, #DB occurs after completion. The exception is reported in the RIP to which control has been transferred unless TF is set. Actually, no transfer process is performed in the enclave. As part of normal EIRET processing, RFLAGS is restored from the SSA copy. If the resulting TF is set, #DB occurs after execution of the target instruction in the enclave. These behaviors are consistent with the behavior of normal IA IRET instructions.
<DR7 behavior>
DR7 is restored from the previously saved SSA copy at the last interrupt or exception.
<Behavior of IA32_DEBUG_CTL>
The IA32_DEBUG_CTL MSR is restored from the SSA copy previously saved with the last interrupt or exception.

<EEPPORT>
The EEPPORT instruction reports measurements related to the contents of the enclave.
<Description of instruction>
EEPPORT acquires the enclave measurement value register, its function, and debug status (flag). All of these values are protected using a symmetric message authentication code and can be verified using a REPORT key. In an enclave that requires a REPORT key, the appropriate function is set in SECS and can be obtained by the EGETKEY command. The result of this instruction is placed at 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 SECS points to a valid SEC page, the instruction outputs the contents of the enclave measurement value register to the address specified by output_buffer_la.

<EGETKEY>
Used by the enclave code to return a specific key from the processor key hierarchy.
<Description of instruction>
The required key is specified using the KeyRequest structure and its address is provided as input. This address is naturally aligned. The output is always a 256-bit data value. To achieve 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 the RBX.

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

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

<ERDINFO>
The ERDINFO instruction returns information about the contents of the enclave page cache.
<Description of instruction>
When executed outside the enclave, EEPPORT reports its capabilities and debug status (flag) to the enclave measurement register. All of these values are protected using a symmetric message authentication code and can be verified using the EVERIFYREPORT instruction. The result of this instruction is placed at the destination location output_buffer_la.

<Routine reference>
<Exit>
This section provides pseudo code for exit processing. This code is called when there is an exit from an enclave that the enclave code does not plan. Enclave execution resumes from where it stopped. Information necessary for resumption is saved on the external stack. The processor architecture state is saved in the appropriate save area.

<Acquisition of reader / lock>
With the RW lock, the logical processor accesses the shared resource and provides two modes in which threads can access the shared resource. These two modes are: (1) Shared mode: Permits shared read-only access to multiple reader logical processors so that these multiple processors can read data from shared resources concurrently. (2) Exclusive mode: a mode that allows read / write access to one write logical processor at a time. When a lock is acquired in the exclusive mode, other threads are entities that are writing. The shared resource cannot be accessed until the lock is released.

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

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

In general, most of the SE is implemented in microcode. Hardware support is required at multiple locations including CMA, logic to control data movement outside the package and within the core.

EPC during LP execution microcode mode, or, LP is running in the enclave, only if the linear address being accessed belongs to a linear address range that enclave covers, logic Accessible by the processor (LP). In other words, it is only microcode access or enclave access to be allowed to go to EPC range. All other accesses to the EPC range are considered illegal.

Note: The fields are not listed (yet) in any particular order. Some fields may be moved to different memory pages within the branded data structure, allowing for different protection measures, for example.

In some embodiments, a number of axes such as performance, implementation complexity, and silicon cost may be coordinated. This chapter introduces three implementations to show some of the possible adjustments to developers. 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 therefore are provided to the micro. The range register may be enabled for each logical processor. An example of basic implementation that uses this mechanism is shown in Figure 2-2.

PMH are modified to remove access to microswitch code mode CMA range from the LP has not been executed in the enclave mode (CMRR of the CPU is covered). In addition, LPs running in enclave mode are only allowed access to the CMA EPC subrange.

Since signed license chains are not ideal for evaluation during the enclave activation process, they are instead replaced by a single instruction executable structure called a permit. digestible structure). The permit is symmetric authenticated using the CMAC algorithm and interpreted during enclave initialization (EINIT).

EMKPERMIT is a privileged instruction because of the time required to verify the RSA signature on the license. This instruction, to validate, to take a very simple signed certificate to generate a permit from its contents. The license includes both the signature and the public part of the key used to sign it. Thereby, uCode can authenticate the license signed by Intel by storing only the hash of the license signature key of Intel. The EMKPERMIT can also authenticate the license signed by the ISV key by providing an authorized authorization of the key. This is done by creating a permit containing a hash of the ISV's public key. As a result, EMKPERMIT can verify the Intel license using the Intel license using the internal hash or the ISV key having the hash provided in the second permit.

This section describes an example of a 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 keyflow depends on the specific TCB element. Other platforms can be supported using techniques similar to those used here .

Coupling the key to a specific set of TCB versions is done by having the uCode derive the first set of keys from the fuse key based on the type of maneuver sequence being initiated. After locking this fuse, a chain of derivations is performed at each loading of the activation sequence.

As a result, the data is migrated forward. Take the case of executing uCode SVN3 as an example. The enclave uses EGETKEY to obtain a seal key based on this version (PRELoop (3)), and uses this to seal the data. Deliver the field uCode upgrade and the next activation uCode SVN is 4. After the upgrade, the EGETKEY implementation will be able to access PRFLoop (4). If the enclave requests EGETKEY to send the SVN3 key, it can calculate PRELoop (3) = PRF _{PRELoop (4)} (constant) to obtain the old seal key.

To build this characteristic, a PRF loop is used. Since the characteristic 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 maximum value, it is necessary to construct for the type of each platform on the basis of the performances requested. 32 is recommended as the initial maximum value. The PRF loop derivation is as follows.

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

When the appropriate SVN key is available, it is used as the CMAC key for the requested TCB SVN. Microcode, as a CMAC key to this, Ops key, or to use for a fixed string of pro-vision-based key for SEOps seed (a value that Intel has been derived from the portion of the fuse key do not know). That is, se_base_key = CMAC (svn_base_key, se_ops_seed).

All cores are synchronized and utilize a doorbell or similar mechanism to ensure that everything enters the MCHECK. When all cores are executing MCHECK, (1) uCode reads, decodes, and locks the fuse. (2) uCode uses the PRF loop as the SVN key and the PRF loop as the OOBE key. Insert uCode SVN into both keys. uCode writes the SVN the TCB SVN register, lock the portion, (3) MCHECK loader or early MCKECK code, write a SVN of MCHECK the TCB SVN register, lock, (4) microcode patch loader, writing microcode patch SVN to TCB SVN register, locks, each step that is performed from the BSP. APs do not participate in keyflows.

During microcode initializes, or when EGETKEY call, microcode calculates the SE base key needed to satisfy the request. The base key may be cached in the CMA for use for further performance improvement. Table 12-4 shows the calculation method of the base key.

FIG. 26 illustrates a processor package for a digital random number generator in one embodiment of the invention. The processor package 2600 can include a plurality of cores, core 0 2640 and core 1 2670. Core 0 2640, microcode 2642, microcode 2644 may include microcode 2646, RNG microcode module 2650, and RNG queue 2654. Core 1 2670, microcode 2672, microcode 2674 may include microcode 2676, RNG microcode module 2680, and RNG queue 2684. Reading random instructions 2630 may communicate with microcode 2642, read the random instructions 2635 may communicate with 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 that connects to an online self test 2606. The output of the online self test 2606 may be one input of a combined regulator / deterministic random bit generator (DRBG) 2620.

<Description of subroutine>
This subroutine, indeed, uCode the PMH address - an additional hardware utilized when exposing the conversion function u Code. XUTRANSLATE is a u Op that mainly receives a PMH context and a linear address as input and generates a final physical address as output. If PMH encounters bad conditions during the page table walk, these are reported to u Code. The details of u Op are outside the scope of this document.

Claims (15)

  Execution executing at least a first instruction for moving the protection data between an enclave page cache (EPC) and a second storage area during execution of a program executed in protection mode that accesses the protection data A processor with logic.   The processor of claim 1, wherein a security map (SMAP) helps to ensure the integrity of the program when the program is stored on a hard disk drive or protected memory.   A processor comprising execution logic for executing a first instruction for identifying a software thread executing in a secure enclave and informing a user program of the identity of the software thread.   A first instruction for dynamically accessing 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 A processor having at least execution logic to be executed.   A processor comprising execution logic that executes a first instruction that reports a state of a secure enclave stored in memory to either a local agent or a remote agent. A crypto memory aperture (CMA) that protects the software program from attacks during execution of the software program;
A processor comprising: a secure map (SMAP) that protects the software program while the software program is not running.   A processor comprising execution logic that executes at least one secure enclave access instruction that allocates or deallocates a corresponding memory or software thread in the secure enclave.   A processor with a hierarchical protection tree, SMAP, that allows multiple memory updates within a secure enclave in a single processor cycle.   A processor comprising execution logic for executing a first instruction that provides a unique key to a secure enclave.   A processor comprising logic for executing a first instruction to build a trusted environment managed by an untrusted agent.   A processor comprising logic for executing instructions to determine the validity of a license for accessing a secure enclave by comparing the size of the enclave with a size specified by a license certificate.   A processor with logic controlled by control bits for user-level policy management of secure enclaves.   A processor comprising logic that executes at least one instruction that grants access to at least one instance of a secure enclave licensed to a user.   A processor comprising logic to execute at least one instruction that violates enclave security of only enclaves that are allowed to debug, enabling secure enclave debugging.   A processor comprising execution logic that executes at least one instruction that allocates or deallocates memory pages to each enclave page cache (EPC).

Images