WO2011078855A1 - Procédé et appareil permettant d'exécuter une application sécurisée - Google Patents

Procédé et appareil permettant d'exécuter une application sécurisée Download PDF

Info

Publication number
WO2011078855A1
WO2011078855A1 PCT/US2009/069212 US2009069212W WO2011078855A1 WO 2011078855 A1 WO2011078855 A1 WO 2011078855A1 US 2009069212 W US2009069212 W US 2009069212W WO 2011078855 A1 WO2011078855 A1 WO 2011078855A1
Authority
WO
WIPO (PCT)
Prior art keywords
enclave
page
epc
key
instruction
Prior art date
Application number
PCT/US2009/069212
Other languages
English (en)
Other versions
WO2011078855A9 (fr
Inventor
Francis X. Mckeen
Carlos V. Rozas
Uday R. Savagankar
Simon P. Johnson
Vincent R. Scarlata
Michael A. Goldsmith
Ernie Brickell
Jiangtao Li
Howard C. Herbert
Prashant Dewan
Stephen J. Tolopka
Gilbert Neiger
David Durham
Gary Graunke
Bernard Lint
Don A. Van Dyke
Joseph Cihula
Stalinselvaraj Jeyasingh
Stephen R. Van Doren
Dion Rodgers
John Garney
Original Assignee
Intel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=44196072&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2011078855(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Priority to GB1118724.2A priority Critical patent/GB2481563B/en
Priority to GB1709341.0A priority patent/GB2550698B/en
Priority to PCT/US2009/069212 priority patent/WO2011078855A1/fr
Priority to DE112009005466T priority patent/DE112009005466T5/de
Priority to BRPI0924512A priority patent/BRPI0924512A2/pt
Application filed by Intel Corporation filed Critical Intel Corporation
Priority to CN200980160114.XA priority patent/CN102473224B/zh
Priority to KR1020127016450A priority patent/KR101457355B1/ko
Priority to JP2012516046A priority patent/JP5443599B2/ja
Publication of WO2011078855A1 publication Critical patent/WO2011078855A1/fr
Publication of WO2011078855A9 publication Critical patent/WO2011078855A9/fr
Priority to US13/527,547 priority patent/US9087200B2/en
Priority to US13/802,272 priority patent/US10102380B2/en
Priority to US16/123,593 priority patent/US10885202B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491—Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2105—Dual mode as a secondary aspect

Definitions

  • Embodiments of the invention relate generally to the field of information processing and more specifically, to the field of security in computing systems and microprocessors.
  • Figure 1 illustrates a block diagram of a microprocessor, in which at least one embodiment of the invention may be used
  • Figure 2 illustrates a block diagram of a shared bus computer system, in which at least one embodiment of the invention may be used;
  • Figure 3 illustrates a block diagram a point-to-point interconnect computer system, in which at least one embodiment of the invention may be used.
  • Figure 4 illustrates a block diagram of a multi-core microprocessor, in which at least one embodiment of the invention may be used.
  • FIG. 5 illustrates a possible implementation of a secure enclave (SE) in one embodiment of the invention.
  • Figure 6 illustrates a block diagram of a microprocessor, in which at least one embodiment of the invention may be used.
  • Figure 7 illustrates an example of a control structure for accessing a portion of the enclave page cache that can be implemented in one embodiment of the invention.
  • Figure 8 illustrates an example of a thread control structure in one embodiment of the invention, showing how the data structures are stitched together.
  • Figure 9 illustrates one step of the process of software attestation known as quoting, which can be found in one embodiment of the invention.
  • Figure 10 illustrates the steps, in one embodiment of the invention, to produce quotes from a set of measurement registers.
  • Figure 11 illustrates the EADD process to update the measure register MR_EADD in one embodiment of the invention.
  • Figure 12 illustrates the EREPORT instruction that creates reports in one embodiment of the invention.
  • Figure 13 illustrates the mechanism of replay -protection found in one embodiment of the invention.
  • Figure 14 illustrates an example of the MAC tree structure portion of the replay - protection mechanism found in one embodiment of the invention.
  • Figure 15 illustrates in one embodiment of the invention how a page fault error code map can be implemented.
  • Figure 16 illustrates an example of a process to create a permit to launch an enclave in one embodiment of the invention.
  • Figure 17 illustrates for one embodiment of the invention a possible
  • Figure 18 illustrates an example of a microcode based secure enclave key hierarchy in one embodiment of the invention.
  • Figure 19 is a diagram for the enclave CTL MSR register, which can be found in one embodiment of the invention.
  • Figure 20 illustrates the cipher block chaining algorithm used in one embodiment of the invention.
  • Figure 21 is a flow chart illustrating the encryption of a single AES block in one embodiment of the invention.
  • Figure 22 is a flow chart that illustrates an example of the encryption of multiple
  • Figure 23 illustrates in one embodiment the application and interrupt stacks after an interrupt with a stack switch.
  • Figure 24 illustrates a possible way to implement a stack of multiple state save area slots in one embodiment of the invention.
  • Figure 25 illustrates in one embodiment of the invention a portion of the state machines with state transitions for interrupts, faults, and traps.
  • Figure 26 illustrates, for one embodiment of the invention, the processor package for a digital random number generator.
  • Figure 27 illustrates, for one embodiment of the invention, a debug register DR7
  • Embodiments of the invention pertain to a technique for providing secure application and data in a flexible but reliable manner.
  • the attached document entitled "Secure Enclaves Architecture" is hereby incorporated by referrence as an example of at least one embodiment.
  • the incorporated reference is not intended to limit the scope of embodiments of the invention in any way and other embodiments may be used while remaining within the spirit and scope of the invention.
  • Figure 1 illustrates a microprocessor in which at least one embodiment of the invention may be used.
  • Figure 1 illustrates microprocessor 100 having one or more processor cores 105 and 1 10, each having associated therewith a local cache 107 and 113, respectively.
  • a shared cache memory 115 which may store versions of at least some of the information stored in each of the local caches 107 and 1 13.
  • microprocessor 100 may also include other logic not shown in Figure 1, such as an integrated memory controller, integrated graphics controller, as well as other logic to perform other functions within a computer system, such as I/O control.
  • each microprocessor in a multi-processor system or each processor core in a multi-core processor may include or otherwise be associated with logic 1 19 to enable secure enclave techniques, in accordance with at least one embodiment.
  • the logic may include circuits, software (embodied in a tangible medium) or both to enable more efficient resource allocation among a plurality of cores or processors than in some prior art implementations.
  • FIG. 2 illustrates a front-side-bus (FSB) computer system in which one embodiment of the invention may be used.
  • Any processor 201, 205, 210, or 215 may access information from any local level one (LI) cache memory 220, 225, 230, 235, 240, 245, 250, 255 within or otherwise associated with one of the processor cores 223, 227, 233, 237, 243, 247, 253, 257.
  • any processor 201, 205, 210, or 215 may access information from any one of the shared level two (L2) caches 203, 207, 213, 217 or from system memory 260 via chipset 265.
  • L2 shared level two
  • One or more of the processors in Figure 2 may include or otherwise be associated with logic 219 to enable secure enclave techniques, in accordance with at least one embodiment.
  • P2P point-to-point
  • ring interconnect systems may be used in conjunction with various embodiments of the invention, including point-to-point (P2P) interconnect systems and ring interconnect systems.
  • the P2P system of Figure 3 may include several processors, of which only two, processors 370, 380 are shown by example.
  • Processors 370, 380 may each include a local memory controller hub (MCH) 372, 382 to connect with memory 32, 34.
  • MCH local memory controller hub
  • Processors 370, 380 may exchange data via a point-to-point (PtP) interface 350 using PtP interface circuits 378, 388.
  • PtP point-to-point
  • Processors 370, 380 may each exchange data with a chipset 390 via individual PtP interfaces 352, 354 using point to point interface circuits 376, 394, 386, 398.
  • Chipset 390 may also exchange data with a high-performance graphics circuit 338 via a high- performance graphics interface 339.
  • Embodiments of the invention may be located within any processor having any number of processing cores, or within each of the PtP bus agents of Figure 3.
  • any processor core may include or otherwise be associated with a local cache memory (not shown).
  • a shared cache (not shown) may be included in either processor outside of both processors, yet connected with the processors via p2p interconnect, such that either or both processors' local cache information may be stored in the shared cache if a processor is placed into a low power mode.
  • One or more of the processors or cores in Figure 3 may include or otherwise be associated with logic 319 to enable secure enclave techniques, in accordance with at least one embodiment.
  • IP cores may be stored on a tangible, machine readable medium (“tape”) and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor.
  • Secure Enclaves is a set of instructions that provides a safe place for an application to execute code and store data inside in the context of an OS process.
  • An application that executes in this environment is called an enclave.
  • Enclaves are executed from the Enclave Page Cache (EPC).
  • EPC Enclave Page Cache
  • the enclave pages are loaded into EPC by an OS.
  • cryptographic protections are used to protect the confidentiality of the enclave and to detect tampering when the enclave is loaded back into the EPC.
  • enclave data is protected using access control mechanisms provided by the processor. Table Error! No text of specified style in document.-l below provides a complete list of the non privileged enclave instructions.
  • Hardware ELPG Used to manage the enclave Management EWBI VPG, page cache.
  • Enclave Page Cache is where enclave code is executed and protected enclave data is accessed.
  • the EPC is located within the physical address space of a platform but can be accessed only using SE instructions.
  • the EPC may contain pages from many different enclaves and provides access control mechanism to protect the integrity and confidentiality of the pages.
  • the page cache maintains a coherency protocol similar to the one used for coherent physical memory in the platform.
  • the EPC can be instantiated in several ways. It could be constructed of dedicated SRAM on the processor package.
  • the preferred implementation mechanism is known as Crypto Memory Aperture. This mechanism allows the EPC to be large. More details of CMA are in the section below.
  • the Enclave Page Cache Map contains the state information associated with each page in the EPC. This state provides the information such as the enclave that the page belongs to, the state of a loaded page, etc. When a page is removed from the EPC, the state information is exported as well and is protected using cryptographic means. When an enclave page is re-loaded into the EPC, the state information is verified.
  • FIG. 4 illustrates a block diagram of a multi-core microprocessor 499, in which at least one embodiment of the invention may be used.
  • the microprocessor 499 can contain multiple cores 400, 420.
  • One core 400 contains a CR3 402, SMBR 404, , page- miss handler 408, PMHE 410, and a translation lookaside buffer 412.
  • One core 420 contains a CR3 422, SMBR 424, , page-miss handler 428, PMHE 430, and a translation lookaside Buffer 432.
  • the microprocessor 499 in some embodiments of the invention, contains a level- 1 cache 440 shared between core 400 and core 420.
  • the level- 1 cache 440 can transfer data to and from the last level cache 445.
  • the home agent 450 can connect to the last level cache 445 and attach to the crypto engine 452.
  • the home agent 450 can assess the physical address space 488 of the crypto memory aperture 480 through the memory controller 454.
  • the crypto memory aperture 480 contains an enclave page cache 482, enclave page cache map 484, backing store 486, as part of the physical address space 488.
  • CMA is a mechanism which provides support for instantiating the EPC, EPCM, and other SE related structures.
  • the aperture is a region of the physical address space which is reserved for this use.
  • the EPC and EPCM (as well as other implementation data structures) are mapped to a location inside the aperture.
  • the backing store is the actual data for these resources.
  • CMA remaps to the backing store location containing the encrypted EPC data and retrieves the data.
  • FIG. 5 illustrates a possible implementation of a secure enclave in one embodiment of the invention.
  • the operating system and VMM 542 can use the ELPG instruction 540 to load an enclave page in the enclave 532 into an enclave page cache 544.
  • the enclave page cache 544 is protected from the from software access by the SERR register 548,
  • the microcode page tables provide protection 546.
  • Each VM has an associated VMCS.
  • VM 510 is connected to VMCS 515.
  • VM 520 is connected to VMCS 525.
  • VM 530 is connected to VMCS 535.
  • the SMM 500 can be in a separate container and the processor states can be in a separate container.
  • FIG. 5 is the high level overview of one embodiment of a Secure Enclave implementation.
  • the EPC is kept as a separate container managed by the microcode. The container is not accessible when execution is not inside the enclave.
  • control is transferred to the enclave code inside the EPC which is contained in a separate container. Any page faults or exceptions which occur while executing inside of the enclave are reflected by the microcode to the responsible OS or VMM.
  • SE range register SE range register
  • One option to implement secure enclaves is to implement the instructions and the protections using the microcode capability in some processors. This capability may meet the security requirements that secure enclaves requires to meet its goals.
  • the SERR register as shown in Error! Reference source not found, is implemented in the Page Miss Handler PMH.
  • the register may be enabled and disabled independently for each logic processor.
  • TLB Translation Lookaside Buffer
  • the enclave bit is compared to the enclave mode bit. Extra bits would provide an enclave space id functionality. A particular enclave would be assigned an id. The id would be compared with the id of the executing enclave as part of the address check.
  • TLB support is an optional performance enhancement. When an entry may be invalidated in the TLB due to the removal of EPC data, a special microcoded shootdown mechanism is needed. In one embodiment microcode may contact all other cores in the enclave trust boundary and verify the entry is no longer in any TLB. Other embodiments may provide a means for microcode to be assured that other processors have invalidated the TLB entries.
  • Secure Enclave microcode may use secure access to random numbers in one embodiment.
  • An enclave may be protected against tampering.
  • the details of the mechanism used for tampering protection vary by implementation. When an enclave is tampered it will prevent further execution on the thread which detected the tampering.
  • an attestation mechanism put into place to provide proof of the enclave build. This includes the EREPORT instruction used to present information on the enclave contents.
  • the enclave state across power cycles is dependent on software policy. Data inside the CMA is lost on power down. Software may ensure that the enclave data is not lost on a power cycle if it would like to preserve the enclave. Data resident in the EPC may be flushed to memory if software wishes to keep enclaves alive across S3 power states.
  • Software could elect to require that applications tear down all enclaves when power is removed.
  • An enclave is protected differently depending on its location. Data external to the CPU package is protected using encryption and integrity checking. For code and data in the enclave page cache, pages are protected using access control mechanisms.
  • Figure 6 illustrates a block diagram of a microprocessor, in which at least one embodiment of the invention may be used.
  • Figure 6 illustrates microprocessor 600 having multiple 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. During the load of the page into the EPC, the page is copied into the EPC, decrypted and page's integrity is checked. Figure 6 shows this portion of the data.
  • Enclave data inside the EPC is unencrypted and protected by access control mechanisms. The processor protects this data so that only the enclave which owns that data can access it.
  • FIG. 7 illustrates an example of a control structure for accessing a portion of the enclave page cache that can be implemented in one embodiment of the invention.
  • Each page of the enclave page cache 720 can have corresponding metadata in the enclave page cache map 710.
  • the metadata is shown in Figure 7 secure enclave containing a set of linear addresses 700 can access data stored in the enclave page cache 720 when the linear address matches the linear address stored in the enclave page cache map 710.
  • FIG. 7 shows the layout and usage of the EPC and EPCM.
  • the EPC is split into 4k pages. Each enclave may have some number of pages resident in the EPC. There is an entry in the EPCM for each page of the EPC which provide meta information needed to ensure security. The details of the EPCM are implementation specific.
  • an application desires to load an enclave it will call a system routine in the OS.
  • the OS will attempt to allocate some pages in the EPC. If there is no open spot then the OS will select a victim enclave to remove.
  • the OS will evict the pages of the victim enclave using the EWBINVPG instruction for each page.
  • the OS When the OS has completed the eviction, it will add the secure enclaves control structure (SECS) to the enclave using the ECREATE command. After the SECS is created, the OS will add pages to the enclave as requested by the application using the EADDPRE instruction.
  • SECS secure enclaves control structure
  • the OS may first add SMAP pages to the enclave using the EADDSMAP instruction. Depending on the size and layout of the enclave the OS will add several SMAP pages. When all of the enclave pages are added to the enclave the OS will execute the ⁇ instruction to enable the enclave to be executed.
  • a parameter to the ⁇ instruction is a permit which demonstrates that the enclave is licensed to run on that machine. When an application is loaded a permit needs to be created. After ⁇ successfully completes, the application can execute the EENTER instruction to enter the enclave.
  • the application may need to add or subtract physical memory inside the enclave.
  • To add memory to the enclave the memory is allocated to the correct linear address inside the enclave.
  • the OS copies this memory page into the EPC indicating the linear address.
  • the EADDPOST instruction is run to add this memory to the enclave enclave. If the SMAP node is not resident inside the EPC it may be loadedfirst. After the memory is copied the enclave software may accept the page before it can be accessed inside.
  • the enclave accepts the data by executing the EACCEPT instruction. This instruction can only be executed by the software inside the enclave.
  • the software may want to modify the properties of the enclave memory.
  • the SMAP may be updated.
  • the software may want to create another thread entry point, TCS inside the enclave.
  • the enclave requests that the OS change the SMAP properties of the page using the
  • the enclave software executes the EACCEPT instruction to allow the page to be used.
  • Memory pages can be removed from the enclave.
  • the enclave When the enclave is ready to remove a page, it sends a request to the OS.
  • the OS will execute the EREMOVE instruction which will remove the page from the SMAP.
  • the EREMOVE instruction also invalidates the EPC entry.
  • the access protection requirements can be implemented using a ranger register and microcode managed shadow page tables.
  • the page miss handler hardware can be modified to perform the same access control requirements.
  • the EPC is accessible to the logical processor (LP) only if the LP is either executing in microcode extension mode, or if the LP is executing inside an enclave and the linear address being accessed belongs to the linear address range covered by that enclave. In other words, only microcode extension accesses or enclave accesses are allowed to go to the EPC range. Any other accesses to the EPC range are considered illegal.
  • LP logical processor
  • An enclave access may be resolved to a physical address belonging to the EPC. If the access falls outside the EPC but the linear address indicates the address is inside the enclave then the access may be stopped. A fault to the OS or the instruction is reported.
  • the access to an address in the enclave may be located inside the EPC for the access to succeed.
  • the check that the entry is present in the EPC is usually done by checking the EPCM to verify the valid bit.
  • Each EPC page is dedicated to a particular enclave. References to that EPC entry can only be made by the enclave who owns the EPC page. This is checked by validating the referenced page matches the SECS of the executing enclave.
  • Each EPC page represents a particular linear address page for the enclave.
  • the requested linear address may match the linear address of the page in the EPC.
  • the EPCM entry stores the linear address for which an enclave page was brought into the EPC.
  • the linear address for which the page was brought in may match the linear address of the current request.
  • the EADDPOST instruction sets the "pending" bit in the EPCM for that page.
  • the pending bit survives subsequent EPC write-backs and evictions (using SEC_TNFO).
  • the enclave may issue EACCEPT to clear the pending bit. If an enclave access resolves to an EPC page for which the pending bit is set, the LP issues EF_PENDING fault to the OS/VMM.
  • the OS/VMM When the OS/VMM loads a replay-protected enclave page to the EPC, it sets the FCR (Freshness Check Required) bit in the EPCM entry for that page.
  • the OS/VMM can clear this bit by executing EUPSMAP instruction on that EPC page to clear this bit. An enclave access is allowed to continue only if the FCR bit on that page is not set.
  • the LP delivers EF FRESH CHK fault to the OS/VMM.
  • Each EPCM entry contains a "dirty" bit which indicates whether an enclave is allowed to write to that page. An enclave is allowed to write to an enclave page only if the dirty bit for that page in the EPCM is set. If such is not the case, the LP issues
  • the OS/VMM can set the dirty bit by executing the EUPSMAP instruction on that page
  • the SE security model requires that an enclave may not be allowed to make any direct memory accesses to its own SECS (otherwise the enclave will be able to read its own enclave key, completely compromising the security).
  • the OS/VMM is notified via EF ATTRIB SECS fault.
  • An enclave is not allowed to modify any pages that have a TCS attribute set. If an enclave attempts to modify a TCS loaded into the EPC, the OS/VMM is notified via EF ATTRIB TCS fault.
  • Some fields have names beginning with a lower case "o" (e.g. oLSP). These fields are pointers, but are represented in the enclave as offsets relative to the base of the enclave. This representation ensures that the measurement of enclave pages is independent of the location at which the enclave is created.
  • o e.g. oLSP
  • Fields are not described in any particular order (yet). Some fields may be moved to different memory pages within their respective data structures to allow, for example, for different means of protection.
  • FLAGS Boolean indicates ⁇ Software (Debug executed flag)
  • TCS Thread Control Structure
  • Offset Software ensures relative to the enclave base. Pointer memory region is to save state stack. allocated,
  • the thread state can have one of 5 values:
  • ACTIVE A processor is currently executing in the context of this TCS.
  • TCS::Handler exception handler entry
  • the TCS::Handler has EEXITted and the TCS may be re-entered only by using EENTER/RETURN J3 ⁇ 4OM_INTERRUPT.
  • the State Save Area Offset points to a stack of state save frames used to save the processor state on an interrupt or exception that occurs while executing in the enclave.
  • Next State Save Area NSSA is used by the interrupt microcode to determine where to save the processor state on an interrupt or exception that occurs while executing in the enclave. It is an index into the array of frames addressed by oSSA.
  • the TCS::SSA may not be paged out at the time an interrupt occurs.
  • EENTER checks that SSA is inside the EPC and caches the physical address. In the event that the page is evicted, the processor executing the EWBINVPG will force an enclave exit on the processor currently executing the thread using the SSA and report a page fault to it.
  • Figure 8 illustrates an example of a thread control structure in one embodiment of the invention, showing how the save state areas are stitched together.
  • the 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 of the number of save state areas available.
  • Page Information is an architectural data structure that is used as parameter to the EPC-management instructions.
  • SECS 8 Linear address of EPC slot that currently contains a copy of the SECS
  • the SECJNFO flags and E] PC flags contain bits indicating the type of page.
  • PT TCS 4 Page is a TCS
  • PT REG 8 Page is a normal page
  • the SEC_INFO Flags are a set of bits describing the state of an enclave page. Table Error! No text of specified style in document.-4 SEC INFO Flags
  • FORGERY PROTECTION FP Forgery Protection. Since forgery protection in SE architecture is mandatory, this bit may always be set to 1.
  • READ access R Bit value of 1 indicates that the page can be read from inside the enclave. Bit value of 0 indicates that the page cannot be read from inside the enclave. If the SECS flag is set (see below), the R flag may be set to 0 (SECS cannot be read from inside an enclave).
  • Bit value of 1 indicates that the page can be written from inside the enclave.
  • Bit value of 0 indicates that the page cannot be written from inside the enclave. If the SECS, SMAP or TCS flag is set (see below), the W flag may be set to 0 (SECS and TCS cannot be read from inside an enclave).
  • Execute Access X Bit value of 1 indicates that the page can be executed from inside the enclave. Bit value of 0 indicates that the page cannot be executed from inside the enclave. If the SECS or TCS flag is set (see below), the X flag may be set to 0 (SECS and TCS cannot be executed from inside an enclave).
  • PAGE TYPE SECS Bit value of 0. R mav be 0. W mav
  • X may be 0.
  • SMAP LEVEL 3 SMAP LEVEL 3 (RESERVED) SMAP LEVEL 2: Bit value of 2.
  • R mav 4 - TCS be 0, W may be 0, X may be 0.
  • TCS Bit value of 4.
  • R mav be 1, W mav be 0, and X may be 0.
  • A-REPLAY PROTECTION Indicates whether Replay Protections will be applied once page is accepted inside the enclave
  • A-CONFIDENTIALITY Indicates whether Confidentiality
  • PROTECTION Protection will be applied once the page is accepted inside the enclave.
  • A-FORGERY PROTECTION Indicates whether Forgery Protection will be applied once the page is accepted inside the enclave.
  • SEC_INFO Security Information
  • Certificate is the certificate structure provided with Architectural Enclaves and passed to EMKPERMIT. This structure is 4096 byte and may be page-aligned.
  • Permit outputted from EMKPERMIT and the Permit Enclave and consumed by EINIT. It is 4096 bytes and may be page-aligned.
  • the ERPORT structure is the output of the EREPORT instruction.
  • Measurements is the output parameter of the ERDMR instruction. It contains the Measurement Register values of an enclave, taken from a specified SECS.
  • Key Request (KEY_REQUEST) is an input parameter to the EGETKEY instruction. It is used for selecting the appropriate key and any additional parameters required in the derivation of that key.
  • This structure is used by key derivations to generate keys based on the security versions of the enclave and the enclave's SE TCB. See the Platform TCB Recovery Specification for more details on the TCB Security Version structure.
  • FUSE_KEY 128 A package unique key which roots the in4oand key hierarchy
  • OOB GLOBAL KEY 128 A global key used to provide an OOB experience.
  • ENCLAVE MODE 1 Indicates whether the processor is currently executing in enclave mode
  • SECS PHYSICAL ADDRESS 16 The slot id that contains the SECS for the currently executing enclave
  • TCS LINEAR ADDRESS 64 The linear address of the TCS that was used to enter the enclave
  • SSA that may be used in the event the enclave exits due to an interrupt, fault, or exception.
  • the EPCM Flags are a set of bits describing the state of an enclave page.
  • Enclave Page Cache Map is a secure structure used by the processor to track the contents of the page cache.
  • the EPCM holds exactly one entry for each page that is currently loaded into the EPC.
  • Attestation is the process of demonstrating that a piece of software has been established on the platform especially to a remote entity.
  • secure enclaves it is the mechanism by which a remote platform establishes that software is running on an authentic platform protected within an enclave prior to trusting that software with secrets and protected data.
  • the process of attestation has three phases, Measurement, Storage and Reporting.
  • Figure 9 illustrates one step of the process of software attestation known as quoting, which can be found in one embodiment of the invention.
  • the sign operation 910 applies a signing key 915 to the concatenated data from measurement registers 901, 902, 903, 904.
  • the result of the sign operation 910 is the quote 920.
  • the values of the Measurement Registers (MR) are concatenated and then signed using an asymmetric key. Any challenger simply then has to verify the signature over the quote structure in order to validate the quote.
  • MR Measurement Registers
  • Figure 10 illustrates the steps, in one embodiment of the invention, to produce quotes from a set of measurement registers 1000.
  • the local reports 1005 can be generated by accessing the measurement registers 1000 with a symmetric authentication key.
  • the quoting enclave 1025 can contain software that converts the local reports 1005 into anonymous quotes 1010 or normal quotes 1020.
  • Each enclave provides two 256-bit wide Measurement Registers (MR_EADD & MR_POLICY) and two reserved registers. These measurement registers are contained within the SECS of the enclave.
  • Figure 11 illustrates the EADD process to update the measurement register MR EADD 1100 in one embodiment of the invention.
  • the extend operation 1 1 15 can take as inputs the current value of the MR EADD 1 100, the page data 1 105, and the page meta data 1 110.
  • the output of the extend operation is the MR EADD' 1 120, which is the next value to store into MR EADD 1 100.
  • MR_EADD contains the aggregated measurement of the enclave as it was built using the EADD instruction before the ⁇ instruction is called. It is only written to by microcode and therefore it needs to be placed in a page of the SECS which is read-only by enclave code.
  • EADD On each invocation of EADD it computes a SHA256 over the page data and the security meta data associated with that page, namely the relative address (w.r.t. to the enclave's base address) of the page and the page's SEC_INFO. flags and this value is extended into MR EADD l 100. Where we define 'extend' to mean:
  • New MR Value Hash ( Old MR Value 11 Input Value )
  • MR POLICY contains the value of the policy used to authenticate the policy which permitted the enclave to be launched. This value was taken from the enclave permit which was placed in the SECS at launch and copied as a successful completion of the ⁇ instruction. MR POLICY is only written to by microcode and therefore it needs to be placed in a page of the SECS which is read-only by enclave code.
  • Figure 12 illustrates the EREPORT instruction that creates reports in one embodiment of the invention.
  • the KEYID 1200, owner epoch 1205, package fuse key 1210, and fixed string MAC key 1215 are possible inputs to a derivation instruction 1220.
  • the output of the derivation 1220 can enter the CMAC 1225 along with the present values of TCB version 1232, ISV version 1234, capabilities 1236, flags 1238, user data 1240, and measurement registers 1242.
  • the output of the CMAC 1225 can be stored in the MAC 1244.
  • the output of the EREPORT instruction can include the key identification 1230, TCB version 1232, ISV version 1234, capabilities 1236, flags 1238, user data 1240, measurement registers 1242, and MAC 1244.
  • the EREPORT instruction creates an intermediate key to perform a symmetric key based GMAC over the measurement registers, user data, and additional contextual information, such as the enclave's capabilities and flags.
  • the user can also supply a 256bit wide block of data for inclusion in the report.
  • reportKeylD a random 128 bit value (known as reportKeylD) is produced on each power cycle of the processor and stored in internal location. This value is incremented after 2 ⁇ 32 AES operations using this value. Each call to the EREPORT instruction will increment this value by 1 in one embodiment.
  • 16 1 Flags A bit field which represents certain state of the enclave or the report instruction
  • EREPORT Structure The Flags field in the report structure can be used to determine certain state information about the enclave or when the EREPORT instruction was called which will be useful for a challenger to assess whether they may trust the enclave.
  • RESERVED MBZ RESERVED for future use
  • the architecture allows an architectural enclave with the appropriate capability set to retrieve the key used in the CMAC operation with the EGETKEY command and hence verify that the report was created on the hardware it is currently running on. This capability is limited to the Quoting Architectural Enclave.
  • the ERDMR (Read Measurements) instruction For retrieving measurements of the enclave when executing outside the enclave, the ERDMR (Read Measurements) instruction is provided. This instruction takes a pointer to a valid SECS page and a pointer to address where the measurements will be delivered. The measurements are delivered in the form of a MEASUREMENT structure. The MEASUREMENT structure is not cryptographically protected.
  • Confidentiality Protection There are three levels of cryptographic protection: Confidentiality Protection, Forgery Protection, and Replay Protection.
  • application are allowed to choose a protection level for each enclave page independently of the protection level chosen for other pages of the same enclave.
  • the enclaves' implementation MAY allow applications to choose between the following combinations: Forgery Protection, Forgery Protection and Replay Protection, Confidentiality and Forgery Protection, and Confidentiality, Forgery Protection, and Replay Protection.
  • Confidentiality and forgery protection on enclave page can be achieved using one of the several authenticated encryption modes such as the Galois Counter Mode (GCM) in conjunction with an appropriate cipher such as AES.
  • GCM Galois Counter Mode
  • AES Access Security
  • Figure 13 illustrates the mechanism of forgery protection and replay -protection found in one embodiment of the invention.
  • Forgery protection prevents an attacker from substituting a different value of encrypted data which is not generated by the program.
  • Replay protection prevents an attacker from substituting a value of encrypted data which is not the current latest value generated by the program.
  • the node version number 1300 can enter the IV 1310 and then to the GMAC 1325 algorithm.
  • the version numbers for children 1305 can send data 1315 to the GMAC 1325 algorithm.
  • the GMAC 1325 algorithm combines the key 1320, the IV 1310, and the data 1315 to generate the MAC 1330.
  • Replay protection ensures that all the contents of an enclave as seen by a logical processor at any given time belong to a single snapshot of a non-corrupted enclave.
  • a replay -protection mechanism needs to define the concept of an enclave version and provide a mechanism of determining whether a forgery-protected enclave page belongs to that version of the enclave.
  • the replay-protection mechanism ties the contents of each forgery-protected enclave page to a page version number using a message- authentication algorithm such GMAC.
  • GMAC message- authentication algorithm
  • the version can be used as a part of the initialization vector (IV) as shown in Error! Reference source not found.
  • Figure 14 illustrates an example of the MAC tree structure portion of the replay- protection mechanism found in one embodiment of the invention.
  • the leaf node 1425 can contain the version information for individual MAC content page 1430.
  • Each leaf node such as 1420 contains an individual MAC content page (not shown).
  • Each internal node 1410, 1415 can contain version information of the children groups it links to.
  • the root 1400 is the highest level node in the tree data structure.
  • Leaf nodes contain the versions of individual rep lay -protected pages of the enclave instance.
  • Each internal node provides the version of each group of children and therefore logically holds the version information for the pages they are representing. Error! Reference source not found, shows this concept pictorially.
  • tree structure was chosen to reduce the number of data that needs to be processed from O(n) pages to 0(log n).
  • the use of a version tree instead of a hash tree was selected to allow page eviction from the EPC without necessitating a tree update.
  • the OS/VMM creates an enclave by executing the ECREATE instruction.
  • the range of linear addresses that is protected by the enclave is specified. This range of linear addresses is known as the Enclave Linear Space (ELS) range.
  • ELS Enclave Linear Space
  • the cryptographic protections are achieved by associating cryptographic meta-data with each enclave page. This meta-data is used by the uCode flows for various processor instructions to decrypt the contents of an enclave page and to verify the
  • the SE architecture provides several such instructions to update, manage, and validate the cryptographic meta-data.
  • Each enclave page has Security Information SEC_INFO data structure associated with it.
  • the purpose of the SEC_INFO data structure is to hold the cryptographic metadata required to decrypt and verify the page.
  • the various fields of the SEC_INFO structure are as follows.
  • SEC_INFO. Flags describe the page type, graphic and access protection for a protected page.
  • Execute Access X Bit value of 1 indicates that the page can be executed from inside the enclave. Bit value of 0 indicates that the page cannot be executed from inside the enclave. If the SECS or TCS flag is set (see below), the X flag may be set to 0 (SECS and TCS cannot be executed from inside an enclave).
  • X may be 0.
  • SMAP LEVEL 3 SMAP LEVEL 3 (RESERVED) SMAP LEVEL 2: Bit value of 2.
  • R mav 4 - TCS be 0, W may be 0, X may be 0.
  • TCS Bit value of 4.
  • R mav be 1, W mav be 0, and X may be 0.
  • PROTECTION Protection will be applied once the page is accepted inside the enclave.
  • SMAP Security Map
  • a security map represents a full version tree for a particular snapshot of an enclave.
  • Each node of the Security Map holds versions for 256 child nodes (or enclave pages, in the case of a leaf node). Additional meta-data about the security node is contained within the SEC I FO for a particular SMAP node.
  • the Security Map tree is two levels deep 1 , and is accessed using enclave offset of an enclave page within that enclave.
  • the root of the SMAP is contained within the SECS and it only holds versions for 128 child nodes. Bits from the enclave offset are used to choose appropriate child are used to index the SMAP.
  • the enclave offset is 35 bits long.
  • the enclave offset is extracted by the following formula (enclave linear address & enclave mask).
  • the enclave mask is determined by (size of the enclave - 1) and can be calculated during ECREATE.
  • N - (/) x 8 through N - (/ + 1) x 8 + 1 are used to select the appropriate child at next level.
  • Security Map is a logical data-structure, and is not architectural. A logical processor is not even aware of where in the linear address space the SMAP is located. The system software is responsible for maintaining and walking the security map. Each individual node in the security map has an architecturally defined structure— however, the architecture does not specify how the security map is maintained in the memory. It may however be noted that, each node in the security map has a well-defined logical position in
  • the depth of the Security Map is related to the size of the enclave supported by the SE architecture.
  • SE architecture will support maximum enclave size of 32GB. the security map, and if the node is moved around within the map, the various processor instructions that relate to the security map will interpret that as an attack scenario.
  • a root security node is contained within the SECS and contains version information for 128 children.
  • a non-root security node is protected page and its associated SEC_INFO. The protected page contains version information for 256 children.
  • the SEC_INFO contains the location of the SMAP within the SMAP.
  • the location with the SMAP is determined by the linear/enclave offset and the page type
  • Adding a replay -protected enclave page requires that the SMAP parent have been created and resident inside the EPC with FCR bit cleared.
  • a logical processor uses the IV_P and key_id in the SEC_INFO structure to generate a key.
  • the key is used to compute the MAC over the flags in the SEC_INFO structure and the contents of the page.
  • the computed MAC is compared with MAC located in the SEC_INFO structure. If the MACs match, then the page is considered to pass the integrity check.
  • a logical processor verifies the integrity of a page when the page is loaded into the EPC using the ELPG instruction. As a part of this instruction, a logical processor notes down the IV_P from the SEC_INFO structure that was used to verify the page.
  • a logical processor verifies that the enclave page and its smap parent have been loaded into the EPC and that smap parent is fresh. It then proceeds to check the version of the page against version of stored in the smap parent. If the two versions match, the processor generates a new version for the page and updates the version in the smap parent and version of the enclave page. Lastly, it marks the enclave page as fresh.
  • a logical processor verifies that the enclave page and its smap parent have been loaded into the EPC and are both fresh. It then proceeds to set the version of the page in the smap parent to 0 and mark the EPC slot of the enclave page as available.
  • the Enclave Page Cache (EPC) is a secure storage used by the CPU to temporarily store enclave pages when they are not cryptographically protected by SE cryptographic protections.
  • Any accesses to the enclave memory pages loaded into the EPC that belong to non-debug en-claves may be protected from any modification by software entities outside that enclave.
  • Attackers may not be able to read plain-text data belonging to non-debug enclaves that is loaded into the EPC via straight-forward hardware attacks.
  • Attackers may not be able to able to modify data in the EPC that belongs to non- debug en-claves via straight-forward hardware attacks. Any data loaded into the EPC may be accessible coherently, yet securely from any CPU in the system.
  • the EPC could be implemented as on on-die SRAM or eDRAM.
  • the EPC could also be constructed by dynamically sequestering ways of the CPU's last-level cache. In such an implementation, the EPC may be protected from un-authorized accesses from outside the package.
  • the Crypto Memory Aperture provides a cost-effective mechanism of creating cryptographically protected volatile storage using platform DRAM.
  • the CMA uses one or more strategically placed cryptographic units in the CPU uncore to provide varying levels of protection, as needed by the customer technology.
  • the various uncore agents are modified to recognize the memory accesses going to the CMA, and to route those 25 accesses to a Crypto Controller located in the uncore.
  • the Crypto Controller depending on the desired protection level, generates one or more memory accesses to the platform DRAM to fetch the cipher-text. It then processes the cipher-text to generate the plain-text, and satisfies the original CMA memory request.
  • the CMA fully integrates into the Intel QuickPath Interconnect (QPI) protocol, and scales to multi-package platforms, with security extensions to the QPI protocol.
  • QPI QuickPath Interconnect
  • the CMA protects memory transfers between Intel CPUs using a link-level security (Link-Sec) engine in the externally facing QPI link layers.
  • Link-Sec link-level security
  • An SECS is said to be active if it is currently loaded into the EPC.
  • the OS/VMM is responsible for managing what gets loaded into the EPC.
  • the OS/VMM needs to tell the CPU the whereabouts of the SECS for that page, except when the page under consideration itself is an SECS.
  • the CPU requires that the SECS corresponding to the page be located inside the EPC.
  • the OS/VMM MAY load the SECS for that enclave into the EPC.
  • the CPU does not enforce any restrictions on how many times an SECS could be loaded to the EPC— however, it would be highly unusual for the OS/VMM to load multiple copies of the SECS to the enclave page cache. Nevertheless, even if multiple copies of the same SECS are loaded to the EPC, each of those copies is considered as a separate active SECS instance, and enclave pages loaded into the EPC that belong to different instances of active SECS are considered to belong to different enclaves by the hardware.
  • the OS/VMM sees the EPC as a contiguous block of physical memory in the system address space. 10 However, to reduce internal storage, and enable fast indexing, the CPU associates a slot identifier (SID) with each EPC page.
  • SID slot identifier
  • the physical address of an EPC page and the corresponding slot identifier are related to each other as follows.
  • the hardware uses a special slot identifier of OxFF to denote an invalid slot.
  • EPC slot identifiers are used by both the uCode and the PMH to track the information about the enclave pages.
  • Every enclave page loaded to the EPC has a well-defined system physical address. Since there is a one-to-one mapping between the physical addresses belonging to EPC and the EPC slot identifiers, we say that each page loaded to EPC has its own EPC slot identifier or EPC SID.
  • every enclave page, except for the SECS page, that is loaded into the EPC is associated with an active SECS instance. Recall that an active SECS instance is nothing but an SECS page that is loaded to the EPC. Consequently, the active SECS page also has its own EPC SID.
  • the EPC SID of the SECS page to which a non-SECS enclave page belongs is referred to as the SECS_SID for non-SECS 25 page.
  • the hardware keeps track of the SECS SID.
  • the SECS SID for an SECS pages loaded into the EPC is defined to be OxFF, or the invalid SID.
  • the EPCM is a secure structure used by the processor to track the contents of the page cache.
  • the 30 EPCM holds exactly one entry for each page that is currently loaded into the EPC.
  • each EPCM entry tracks such information as the enclave to which that page belongs, the linear address for which the page was brought into the enclave page cache, the version of the page, etc.
  • the EPCM structure is used by the CPU in the address-translation flow to enforce access-control on the enclave pages loaded into the EPC.
  • the EPCM entries are managed by the (x)uCode as part of various instruction flows.
  • an enclave page cache may be dynamically allocated or de-allocated.
  • software such as an operating system can dynamically allocate pages in memory as EPC or de-allocate memory from
  • the operating system can assign any page in the enclave to be in the EPC.
  • the EPC can take up every available location in the memory in some embodiments.
  • logic such as a software driver may allocate a memory area to be EPC and de-allocate the memory from the EPC.
  • a pre-boot process checks for available memory to store meta data for each page of memory and software may declare a page to be EPC or non EPC, while hardware logic may track and enforce each page's attributes.
  • hardware logic may control access to the memory used as an
  • TLB translation lookaside buffer
  • PMH page miss handler
  • the TLB may be flushed when the secure enclave exits the EPC.
  • an extra lookup may fetch data from the enclave page cache map (EPCM) on multiple memory references.
  • EPCM enclave page cache map
  • a PMH may perform the look up of the EPCM.
  • a range register in the PMH is checked to control access to a contiguous physical address, EPC. The operating system may not allow direct memory access (DMA) to access the EPC pages.
  • DMA direct memory access
  • the secure enclave control structure identification (SECSID) of the page may be checked against that of the currently executing enclave to ensure that the access is secure. If there is a mismatch between the SECSID of the returned page and that of the currently executing enclave, the PMH may issue an abort message. If the returned page of the memory is not marked as an enclave page or if the returned page of the memory is marked as an enclave page and the SECSID of the page matches that of the executing enclave's, the PMH may load the page translation into the TLB.
  • SECSID secure enclave control structure identification
  • a cache tag can be used to identify the enclave line from the other lines on a writeback cycle. However, in at least one embodiment, a cache tag is not used if the logic determining the type of memory request accesses the EPCM during a writeback cycle.
  • software can allocate memory before the operating system boots to create enclave pages.
  • Software may, in one embodiment, create an EPC with a sequence of steps in the BIOS.
  • the BIOS may reserve some memory to store meta data and, for each processor, set a range register.
  • BIOS may take as input a base address and a memory size.
  • the system configuration is checked by a process known as MCHECK to ensure all registers on all packages and all cores are set correctly to provide protection from accesses outside the enclave. MCHECK will lock the registers until the system resets.
  • software can add a page to an EPC by an instruction known as EPCADD, which declares portions of memory to be a part of the EPC.
  • the EPCADD sequence can take a memory address as input and can output a message to indicate the success or failure.
  • EPCADD can set the EPCM.E bit and the page corresponding to that physical address is flushed from all TLBs in the system.
  • the EPCADD may return an error code in RAX of 01 to represent the page with the input address is already an EPC page and an error code of 02 to represent the input address is out of range.
  • a page of memory declared by EPCADD as part of an EPC may require EPC semantics to access the data.
  • software can remove a page from the EPC in a instruction known as EWBI VPG and allow the encrypted data to continue to be available while protected by cryptography and integrity protection. Data in this format can be stored on regular memory of the hard disk drive.
  • software can, in an instructionknown as EPCREMOVE, remove a page in an EPC and make the encrypted data unavailable.
  • EPCREMOVE clears the page and parts of the EPCM.
  • EPCREMOVE can be executed without first executing EWBINVPG.
  • the EPCREMOVE sequence can, in one embodiment, remove a page from an EPC based on a memory address.
  • the EPCREMOVE instruction may contain an error code in RAX of 01 to represent that the page being removed is part of a secure enclave control structure (SECS) and cannot be removed and an error code of 02 to represent that the page being removed is not an EPC page.
  • SECS secure enclave control structure
  • the PMH prevents access to the protected regions of the memory space.
  • PMH Page- miss Handler
  • SE architecture relies on the Page- miss Handler (PMH) to prevent unauthorized accesses to the enclave pages loaded into the enclave page cache. PMH detects various events, and reports those events back to microcode. The microcode may report an event to the OS/VMM. The OS/VMM then can execute appropriate instruction to remedy the fault.
  • PMH Page- miss Handler
  • a linear address range is specified for that enclave. This range is called the linear address range for that enclave. Any memory pages belonging to the linear address range of the enclave are considered to be under the enclave's protection, and have SEC_INFO entries associated with them.
  • Memory pages belonging to the linear address range of an enclave are also referred to as enclave pages.
  • a program executing inside an enclave is allowed to access the enclave pages only if those pages are loaded into the enclave page cache and it is the enclave which owns the page.
  • the processor will generate an exception-class event if this is not the case. It is the responsibility of the OS/VMM to ensure that the enclave pages get loaded to the EPC as needed. If a logical processor is executing an enclave, and it generates a memory access to its enclave page, then such a memory access is referred to as an enclave access.
  • the address may be checked to ensure it is being accessed by the correct entity
  • the PMH provides access control functionality to protect the EPC when a program is not executing in an enclave.
  • a range register enabled for each logical processor will restrict access to the EPC when the processor is not executing enclave code. This range register is disabled when the processor starts executing enclave code. In its place the processor puts special page tables in place. These page tables are controlled by the processor and only allow access to EPC pages owned by that enclave. The processor and microcode restrict access to the EPC using these two mechanisms.
  • a tradeoffs can be made among many axis including performance, implementation complexity, and silicon cost.
  • three possible implementations are described such that developers can understand some of the possible tradeoffs.
  • Table Error! No text of specified style in document.- 18 below shows these possible protections and the PMH support required.
  • PMH is modified to prune out accesses to the CMA range (covered by CMRR in the CPU) from LPs that are neither running in extended microcode mode nor in enclave mode. Additionally, LPs running in enclave mode are only allowed to access the EPC subrange of the CMA.
  • Figure 15 illustrates in one embodiment of the invention how a page fault error code map can be implemented.
  • bit 9 bit 8, bit 7, and bit 6 can be decoded together to determine the page fault error codes.
  • a fault is provided to the OS/VMM to indicate this fact.
  • the Page Fault Error Code Map is altered as shown in Table 8-2. This indicate the new bits which are used to report the faulting condition. If there is no EPC fault then bit 5 is set to zero and bits 6 to 9 are also zero. If the fault is due to an EPC condition then bit 5 will be set and the software may decode bits 6 to 9 to understand the EPC faulting condition. More information on the fault types is described in the next section.
  • bits 6 to 9 are interpreted as given in Table Error! No text of specified style in document.- 19. This shows the condition which caused the page fault to occur. Some of the states indicate an illegal condition which may never occur in normal operation. They indicate an OS/VMM management error.
  • a mechanism which invalidates EPC addresses in all TLB's on the platform may signal to all cores that a particular page is to be invalidated. It may then wait until all processors return an indication that the shoot down is complete.
  • EEXIT Whenever an enclave exit, EEXIT, occurs the TLB may not allow accesses to the enclave pages currently present in the TLB. This can be done by clearing the TLB or using extra bits to tag the enclave entries.
  • One alternative is the use of an enclave bit in the TLB on enclave exit all the enclave entries are cleared.
  • Another alternative is the use of several bits to indentify a particular enclave. In this case the enclave entries do not need to be evicted. The enclave entries can be left in the tlb. When an address is sent to the tlb for lookup these bits are appended to the lookup. These bits are compared to an enclave id from the core which indicates the enclave identity. If the bits match then the request came from the same enclave. If the match fails then the request did not come from that particular enclave and the lookup will not hit on that location.
  • Enclave Authentication provides a means of determining the authority that licensed the enclave code to run within an enclave, which is the author/approver of that code. Enclave Authentication also provides a foundation to outsource Enclave microcode flows, Flexible Sealing & Reporting, as well an enforcement point for a number of new business models.
  • Enclave Sealed Storage provides enclave software with the ability to encrypt data to certain attributes of the enclave, such as its load-time measurement. Enclaves
  • Attestation framework allows an enclave to provide evidence of the enclave's
  • the public portion of the key used to sign the enclave is made available to the Sealing & Attestation mechanisms, allowing a vendor the ability to choose between the rigid protection based on the enclave measurement or more flexible protection based on the source of the enclave's code.
  • Enclave authentication is split into two parts. Each enclave is accompanied by an Enclave License with a signature chain rooted back to Intel.
  • the enclave license indicates who the source/accountable entity for the enclave is, any special capabilities the enclave requires, and any additional information needed for identifying the particular business model/agreement that enabled this enclave.
  • a license may be for a specific enclave, indicating the measurement of that enclave, or it may be for a key, which is then allowed to sign enclaves as needed.
  • Permits are symmetrically authenticated using the CMAC algorithm and are interpreted during initialization ( ⁇ ) of the enclave.
  • the License ID is a 64 bit number to identify a business agreement.
  • License Type identifies what platforms this license applies to.
  • a Bulk license allows this enclave to be launched on any platform supporting Secure Enclaves.
  • a Per Platform license requires the platform to first contact the indicated License Authority, and request permission to launch the enclave. Once permission has been established, no further contact with the License Authority is needed, but this allows the License Authority to track the number of platforms this enclave is deployed at for billing purposes.
  • the ISV that licensed this enclave may opt to establish a security version number for this version of the enclave.
  • the flags field indicates flags for the enclave that may be set in order for this permit to apply.
  • the Capability Mask is a bit mask of the special capabilities that this enclave may be granted.
  • the ParentKeyHash is the hash of the public key that signed this enclave's license, hashed with the public key that signed that key.
  • EntityHash is the expected hash of the entity this license applies to. In the case of an enclave, this is the value of MR.EADD for the properly constructed enclave. For a licensing key, this is the hash of the public key.
  • the public key used to sign the license is included in the license itself.
  • the permit is MACed using CPU keys.
  • a proper cpuMAC indicates that the
  • EMKPERMIT instruction created this permit after validating the license chain back to Intel. If the LicenseType is not Bulk, then a licenseMAC indicates that the Architectural License Enclave has contacted the appropriate License Authority and has receive confirmation that this platform may launch the enclave.
  • Non-debug enclaves always require a permit to launch.
  • Debug Enclaves will launch without a permit. However, if no permit is presented to ⁇ , MR.Policy, ISV Sec Version, Permit Sec Version, and Capabilities will all be set to 0.
  • permit->Flags [DEBUG] may be set, and only capabilities allowed by debug enclaves may be set in the permit.
  • Figure 16 illustrates an example of a process to create a permit to launch an enclave in one embodiment of the invention.
  • the process can have three stages: permit issuing 1600, additional license approval 1640, and initialization enclave 1680.
  • the ISV key permit 1615 can be generated by performing an EMKPERMIT instruction 1612 on the ISV key license 1610.
  • the enclave permit with MAC for CPU only 1625 can be generated by performing an EKPERMIT instruction 1612 on the enclave license 1620 and ISV key permit 1615.
  • the enclave permit with MAC for CPU only 1625 and the 3 rd party enclave that corresponds to the information to be licensed 1642 enter the license enclave 1644, and the license enclave 1644 generates the enclave permit with MAC for CPU and license 1645.
  • the enclave SECS 1682 and the enclave permit with MAC for CPU and license 1645 can be the inputs to the ⁇ 1684 instruction.
  • the output of the ⁇ 1684 instruction is the ISV enclave 1685.
  • a permit may be created from the license that is shipped with the software, and then provided to the cpu to start the enclave. This process is broken down into three: Permit Issuing, Additional License Approval, and Enclave Initialization. Error! Reference source not found, depicts the flow through this process.
  • a new instruction, EMKPERMIT, is used to create a permit from a license.
  • EMKPERMIT creates a single permit from a single license, but can be called in succession in to convert a chain of licenses into a single permit with MAC using the Permit Key. The next section will describe this in further detail.
  • Each license includes a license type, which determines what additional steps may be taken for the permit to be usable.
  • Per Platform Licenses require that a License
  • License Enclave will negotiate with the License Authority in the cloud, and upon approval, will provide an addition MAC on the permit using the License Key.
  • Enclave Initialization During initialization the permit is processed, and if the enclave measurement matches that in the permit, and the MACs are correct, the enclave launches. ⁇ will look at the license type and only inspect the License MAC for licenses requiring additional approval.
  • EMKPERMIT is a privileged instruction, due to the time required to verify the RSA signature on the license. This instruction takes a very simple signed credential that adheres to the uCode Patch format, verifies it, and produces a permit from its contents.
  • the license contains both a signature and the public portion of the key used to sign it. This allows uCode to only store a hash of the Intel's license signing key, and be able to validate Intel signed licenses.
  • EMKPERMIT can also validate licenses signed by ISV keys, by providing an authenticated approval of their key. This is done by created a permit, which contains a hash of the ISV's public key. The result is that EMKPERMIT can verify Intel licenses using an internal hash, or ISV keys with a hash provided in a second permit.
  • EMKPERMIT takes 3 parameters: pointer to a License, an optional pointer to a key permit, and a pointer to an output permit.
  • the key permit is null, and an internally hardcoded set of permit parameters are used.
  • the calling method is used to validate an Architectural Enclave's License and produce a permit for it.
  • EMKPERMIT ensures that the public key in the license is authorize by the uCode (by comparing the hash of the included public key to the internal hash).
  • an ISV's key will have a license signed by Intel.
  • Calling EMKPERMIT without a key permit will use the Intel key hash to verify the signature on the license and create a permit authorizing the ISV key's hash to represent a legitimate license signing key.
  • EMKPERMIT is then called a second time including the ISV's key's permit.
  • EMKPERMIT validates the key permit's MAC, and then uses the hash of the ISV key where it previously used the Intel hash. Assuming the public key in the enclave license hashes to the value in the ISV key, and that the enclave license is properly signed by it, EMKPERMIT will produce a permit for the enclave. This permit indicates the license information (which may be consistent through the entire chain), the hash of all the public keys in the license chain, the enclave's measurement, and its capabilities.
  • the License Enclave is designed to make decisions about enclave launching outside the scope of visibility for uCode. For example, uCode cannot evaluate whether an ISV's business arrangements with Intel allow for an additional enclave deployment.
  • the License Enclave is designed to collect whatever material is necessary to make an assessment and either further approve the enclave launch, or veto it.
  • the License Enclave is only required to support complex business arrangements, and is not necessary for Bulk Licenses such as the ability to launch the enclave on any platform as many times as is needed.
  • the License Enclave is expected to be a system service. If a license indicates it needed further approval from the License Enclave, the chain of licenses and the enclave permit created by EMKPERMIT are passed to the License Enclave. The License Enclave then generates an approval request. The application then sends this approval request to the appropriate License Authority, which generates an approval notice. This is passed back into the License Enclave, and the License Enclave uses the License Key to MAC the permit in the licenseMAC field.
  • a permit may be evaluated and enforced by u-code in the enclave launch process. This is done as a part of the ETNIT instruction, which takes the linear address of the permit as a parameter. The following additional steps are added to EINIT as part of the Authenticated Enclaves mechanism.
  • LicenseType ! Bulk
  • the current capabilities map is a 128 bit mask of capabilities available to this enclave.
  • the space is organized based on the action to be taken by EINIT. Bit 00-03 are reserved for future use as ring level restrictions are active on this enclave. 04- 07 is reserved to indicate what page protections are permitted in the future. 08-23 are processor keys available through EGETKEY. 24-31 are for other controls, such as using Name Based mode for attestation or for future technologies we want to restrict. Certain capabilities may never be used by an enclave in debug mode. The Debug column indicates whether a capability is legal to use in Debug Mode.
  • bit 00 may indicate that ring level and VT restrictions apply to this enclave.
  • Bits 01-02 indicate what ring level the enclave is permitted to run at, and bit 02 indicates whether the enclave runs in VT root mode or not.
  • the current CPL may be compared against bits 01-02 to determine if this enclave is allowed to execute at this ring level. If an attempt is made to execute it at the wrong ring, EENTER will fail.
  • the enclave may only be entered from VT root mode if bit 03 is on. In the first generations these bits are MBZ.
  • Enclave pages may be encrypted or only integrity protected. Also, pages may be executable or not. In future generations, these attributes may be tracked and enforces in the security info portion of the EPCM. These capability bits are reserved to control the application of encryption to enclave pages in the enclave based on whether the page is executable and whether the enclave has been EINITed already.
  • EGETKEY provides access to these keys while the capability bits are used by EGETKEY to decide if access to the key may be granted.
  • the Provisioning Enclave with capabilities KEY PRO VISION and authorized by Intel, runs on single package platforms whenever a new Device Attestation Key (DAK) or Provisioning Attestation Key (PAK) is required. Its purpose is to allow the enclave to derive Device ID & Provisioning Key based on the Provisioning Seed provided by EGETKEY. The Provisioning Enclave then uses these keys to prove the authenticity of the platform to a provisioning server and retrieves a Device Attestation Key (DAK). After retrieving the DAK, the Provisioning Enclave seals it such that the Quoting Enclave can retrieve it.
  • DAK Device Attestation Key
  • PAK Provisioning Attestation Key
  • the Provisioning Enclave may then optionally use the DAK to authenticate with a Platform Attestation Key (PAK) provider and retried a PAK.
  • PAK Platform Attestation Key
  • Using a PAK provides better privacy for the user by ensuring that for a particular ISV, their activities cannot be associated with those of a previous owner of their platform.
  • the Provisioning Enclave seals it such that the Quoting Enclave can retrieve it.
  • the Quote Enclave with capabilities KEY REPORT and authorized by the enclave has the same author as the Provisioning Enclave (typically Intel) used to provision the EPID key. Its location is OS Service Available to all apps. Its purpose is to allow enclaves to unseal a platform EPID key.
  • a Report from EREPORT is provided as input. The enclave uses EGETKEY to retrieve the Report Key. The Report key is then used to verify the report. Enclave signs a Quote from using EPID.
  • the License Enclave with capabilities KEY_LICENSE and authorized by Intel and signed by Root Intel, is shipped with Enclaves (OS Service) and singularly instantiated. Its purpose is to evaluate complex license policies. If an enclave requires additional license confirmation from the License Enclave, ⁇ will only accept it after the License Enclave uses the License Key to CMAC the permit.
  • SE TCB Hierarchy which serves as the root for the SE Key Hierarchy. All keying material used both within the enclave instruction set and in trusted Architectural Enclaves is provided by the SE Key Hierarchy.
  • the platform provides a two 128 bit platform unique keys in fuses. These keys are encrypted in fuses using a key stored in secret CPU logic. Several single purpose keys are derived from this key, and TCB recovery techniques are applied based on the platform's requirements. The resulting keys serve as the roots in the SE Key Hierarchy.
  • the enclave architecture also requires the use of an asymmetric key to provide attestation of the REPORT values to systems outside the platform.
  • This key an EPID key
  • the method for provisioning the EPID attestation key is outside the scope of this specification. More information can be found in the Device Attestation Key (DAK) Provisioning Specification.
  • DAK Device Attestation Key
  • the enclave's architecture also makes use of a key which is in the logic of all processors, for provisioning of key material at the OEM. This key is known as the Out- of-Box Experience Global Key. We perform similar derivation operations on this key to provide ISV uniquesness. How these keys derived from the OOB Key are used by ISV's is beyond the scope of this specification.
  • EPID ID uniquely identifies this package. Its only use is during Yes ID provisioning anonymous attestation keys, which are then used for
  • the OOB Base key is a global key shared across many Intel Yes Box (OOB) platforms.
  • the key may be shared across an entire generation of Intel Base Key microprocessors or a particular stepping. This key is then used to
  • Figure 17 illustrates for one embodiment of the invention a possible
  • the out of the box base key 1700 can be derived 1702 from the available derivation resources 1750 to generate the out of the box key 1704.
  • the available derivation resources 1750 is a string with elements including fixed values 1752, owner epoch 1754, secure enclave security version 1756, The SECS measurement registers 1758, the ISV security version 1760, and SECS flags 1762.
  • the provisioning key 1710 can prove the authenticity of a platform to the Intel backend.
  • the EPID ID 1712 is a signing key.
  • the initial safelD key blob 1718 is a quote and is associated with the safelD seed 1716.
  • the base ops key 1714 can combine with the information from available derivation resources 1750 to derive 1720 a series of keys, including the enclave key 1730, permit key 1732, license key 1734, report key 1736, authentication key 1738, and seal key 1740.
  • Figure 17a illustrates for one embodiment of a multipackage key hierarchy
  • the Secure Enclaves instructions and data structures rely on the Base Keys as a source for keying material.
  • the Enclave Wrapping Key, 1752 is a symmetric key used to encrypt the Secure Enclaves Control Structure (SECS) page while it is not protected inside the Enclave Page Cache (EPC). This key is only used by uCode.
  • the Permit Key, 1754 is used to provide authenticity and integrity over Permits, which contain capability and licensing information for an enclave. Permits are MACed to ensure their integrity while in transit to EINIT. This key used by EMKPERMIT uCode and EINIT.
  • the License Key, 1756 is used assert compliance with license policies not able to be evaluated by uCode.
  • the License Key is used to produce an authenticated approval from the License Enclave that is evaluated by EINIT. This key used by EINIT uCode, and is available via EGETKEY to enclaves with the KEY_LICENSE Capability set.
  • the Report Key, 1758, is used to provide authenticity and integrity over Reports. Reports are MACed by the ERPEPORT to ensure their integrity while in transit to the
  • the Auth Key, 1760 is an enclave specific key, and is used to provide authenticity and integrity over data transmitted from the Quoting Enclave to an ISV Enclave and enables enclave-to-enclave authentication on the same platform.
  • the key is available via
  • the Seal Key, 1762 provides each enclave with a 128-bit key to encrypt their sensitive data.
  • a number of sealing policies can be integrated into the seal key, providing ISVs with flexibility on what software can unseal their data. These keys are available to any enclave via EGETKEY, but individually a seal key is only available to an enclave that meets the seal policy requested.
  • the EPID ID 1712, uniquely identifies the package. Its sole purpose is to enable the provisioning of Device Attestation Keys, which are EPID-based anonymous attestation keys.
  • the EPID ID is only accessible to the provisioning enclave. The provisioning enclave will only provide it over a secured channel to an approved provisioning server, and only during the provisioning process, which is initiated by the user or operating system. This ID is available via EGETKEY to enclaves with the PROVISIONING capability.
  • the Provisioning Key, 1710 is used to prove authenticity of a platform to the Intel
  • the provisioning server is assured that the enclave is indeed the device in possession of EPID ID, and is running at least the specified TCB security version.
  • the Provisioning Key is unique to this package and the signer of the provision enclave requesting it. This creates a separation between provisioning infrastructures, if more than one is used on a single platform. This key is available via EGETKEY to enclaves with the KEY PRO VISION capability.
  • the Provisioning Seal Key provides the provisioning enclave with a 128-bit key to encrypt provisioning in a way that can be retrieved even after a change of ownership. This key is used to encrypt old EPID in order to prove the platform has not been revoked while acquiring new EPIDs.
  • the Provisioning Key is unique to this package and the signer of the provision enclave requesting it. This creates a separation between provisioning infrastructures, if more than one is used on a single platform. This key is available via EGETKEY to enclaves with the KEY PRO VISION capability.
  • the ISV Out of Box (OOB) Experience Key, 1700 is a shared key between all Intel platforms and an ISV. This key is derived from the OOB Root uniquely to a specific ISV. ISVs will be able to purchase access to this key, allowing them to encrypt secrets to this key and placed in an OEM's hard disk image. These secrets will only be accessible to their code running safely in a secure enclave, and does not require the platform to go online or complete attestation key provisioning. These keys are available via EGETKEY to enclaves with the OOB Capability.
  • Provisioned keys are those critical keys to the Secure Enclave architecture, but are not derived from the platform keying material. These keys are provisioned from a provisioning server or offline techniques.
  • the Device Attestation Key (DAK) is an anonymous signing key (EPID) use to attestation to the properties of individual enclaves. This can be used by an ISV during key or secret provisioning to ensure that sensitive information is only sent to protected instantiations of their untampered applications.
  • DAK Device Attestation Key
  • EPID anonymous signing key
  • the preferred architecture ships with an initial DAK compressed in fuses as the EPID Key Blob and EPID Entropy. This enables the platform to perform attestations immediately after the first power on.
  • the second source is by contacting the DAK provisioning server and downloading one after proving the legitimacy of the hardware using the EPID ID and Provisioning Key.
  • This second method is used by platforms, which do not have fused EPID keys as well as any platform after we revoke a version of the underlying TCB.
  • the EPID fuses are accessible via EGETKEY to enclaves with the PROVISIONING capability.
  • the Platform Attestation Key (PAK) provides an optional additional level of privacy. Certain uses of the DAK can be associated.
  • an ISV enclave has the Name Based Attestation capability, then that single ISV can determine if a given EPID is revisiting that service. (Multiple ISVs cannot collude to track users, however). Since the DAK is bound to the platform, rather than the owner, this association continues through waterfall events. Therefore some users will prefer to use their DAK to assert the legitimacy of their platform to a third party that will issue a PAK to use for daily attestations. In multi-package platforms the DAK's of each package is used to establish the PAK, which represents the whole of the platform in attestations.
  • a Pseudorandom Function In the construction of a key derivation function, a Pseudorandom Function (PRF) is needed.
  • the PRF shall be based on the AES-CMAC algorithm as defined in NIST SP 800-38B, Recommendation for Block Cipher Modes of Operation - The CMAC Mode for Authentication, May 2005. (http:/7csrc.nist.gov/publications/nistpubs/800- 108/sp800-108.pdf).
  • the key derivation generally looks like the following:
  • the derivative string is composed of a subset of 8 elements based on the specific key being requested.
  • Table Error! No text of specified style in document.-24 describes each available element that may be part of a derivation.
  • Epoch platform owners By establishing a new
  • the TCB security versions are
  • the current value of the MR EADD includes the measurement of
  • Measurement Register MR EADD the contents of the enclave at its initial launch. This allows for the creation of a Sealing key only available to enclaves containing this particular set of trusted functions.
  • the current value of the MR POLICY includes the hash of the Measurement Register signing key used to sign an Authenticated MR POLICY Enclave. This allows for the creation of a
  • Sealing key only available to enclaves signed by the same key as this key.
  • Random 256 random bits Then adds entropy to the derivation process. This is useful for preventing key wear out, adding additional access controls to a secret such as a user password.
  • Each key has a predefined set of derivation elements, which will compose the derivation string.
  • the Debug string is included if the SECS of the requesting enclave indicates it's in debug mode, and "Request" indicates that this element is not required, but is selectable in the request to derive the key.
  • Secure Enclaves supports techniques for isolation and recovery of software compromise at several points in the boot sequence. In order to support isolation, all long term keying material provided to enclaves is derived using the security versions of the current TCB.
  • This section describes an example architecture for a platform whose recoverable
  • TCB is composed of uCode, MCHECK, and microcode extensions (or a uVMM) will be described.
  • the hardware requirements are the same for any SE supporting platform, however the exact key flow is dependent on the specific TCB elements.
  • Other platforms can be supported using similar techniques to those applied here.
  • Patch-at-Reset this mechanism compliments Patch-at-Reset to enable full recovery of uCode, including evidence of upgrade and cryptographic separate between uCode revisions.
  • the following keys are required in hardware to support a CPU-based protection technology. These keys are the foundation of the TCB Key Hierarchy.
  • Stepping-specific 256-bit Logic Key The 256-bit logic key is broken into two parts— 128-bit fuse wrapping key, and 128-bit out-of-box experience key. It is possible to use a single 128-bit key for both, however, that adds more uCode.
  • Die-specific 544 bits of fuse key include 32 bits of group id, 256 bits of Safeld A.x value, and 256 bits of pre-seed.
  • the A.x value and the 256-bit pre-seed are encrypted with the 128-bit fuse wrapping key described above.
  • Temporary Registers The key-derivation process requires the keys be stored and on the package and available only to uCode. Two 128 bit registers are needed for the duration of platform runtime. An additional 256 bits of space are needed for the EPID key until CMA is up and running. After which the additional 256 bits are no longer needed in the CPU.
  • TCB SVN Register This register is a 64 bit lockable register that is sub-divided to hold SVNs for each TCB layer. Specific subdivision is at the discretion of the platform designers, but 8 8bit SVNs would be reasonable. Each section of this register may be independently lockable.
  • the binding of keys to a specific set of TCB version is achieved by having the uCode derive a first set of keys from the fused key, based on the type of boot sequence that will commence (ie. Patch at Reset or Patch later). After this the fuses are locked, and a chain of derivations occurs at each load in the boot sequence. After the low level code is loaded, the chain continues to include the ISV assigned security version for the software running in the enclave. For any specific configuration, keys derived from the current version are accessible, as well as keys from previous configurations. This enables seamless user data transitions to newer non-vulnerable versions.
  • the die-specific key is generated, it is encrypted with the key wrapping key. This increases the difficultly of extracting the keys with hardware monitoring tools as well as provide protection for the keys in transit before being deposited in the part.
  • the crypto algorithm used to encrypt these keys is 10 rounds of 128 bit AES-ECB decrypt.
  • the key generation server will apply AES-ECB encrypt to each key to generate a cipher text key that will be burned in fuses.
  • PRE Pseudorandom Function
  • the PRE Loop Derivation is used to inject the uCode SVN into a key, while establishing a relationship between keys of different SVNs. Specifically:
  • PRFLoop (x - 1) PRF PRFL ⁇ p ⁇ x) ⁇ const )
  • PRFLoop(x-l) is computed from PRFLoop(x)
  • PRFLoop(x) we need to establish a maximum SVN and count back from it.
  • the specific maxes will need to be established for each platform type based on likelihood of patch and required performance.
  • Application of a PRF Loop Derivation generally looks like the following:
  • This method will be used to inject uCode's SVN into the SVN key, which will be the underlying key behind the SE base keys.
  • the die-specific key in fuses contains 288 bits of EPID values and a 256 bit of random key. All non-ephemeral symmetric keys may be derived from these 256 bits, which is composed of 2 128 bit keys. Therefore a technique may be created for deriving multiple keys from a single key. To do this, after the fuse key is decrypted, we use it to call PRF using different fixed constants.
  • PRF source, CONSTANT1, &sub_keyl
  • PRF source, CONSTANT2, &sub_key2
  • This technique is used to generate random numbers used as part of the EPID ID and a provisioning ID.
  • the SVN key Once the SVN key has been loop derived based on the uCode SVN, it can be store away in protected memory such as the SE CMA. Extended microcode will use an MSR exposed to extended microcode only to derive keys from the SVN Key.
  • the MSR takes a key selector that indicates whether the basis for the derivation is the global out of the box key or the fuse key, and a set of requested SVNs for each TCB layer. It verifies the request is less than or equal to the current values.
  • UCode applies any necessary PRF's to retrieve an old SVN keys, and the PRFs the requested TCB SVNs.
  • tmp_svn_key key_registers [ SVN_KEY_REG] ;
  • tmp_svn_key key_registers [GlobalKey_REG] ;
  • Extended microcode uses this as a CMAC key over the SE Ops Seed (a value derived from the portion of the fuse key not known by Intel) for the Ops key, or a fixed string for the Provisioning Base Key.
  • se_base_key CMAC(svn_base_key, se_ops_seed);
  • Figure 18 illustrates an example of a microcode based secure enclave key hierarchy in one embodiment of the invention.
  • the reset microcode 1800 hierarchy global wrapping logic key 1801 and Intel known unique root fuse 1802 are inputs to the unwrap 1806 function.
  • the output of the unwrap 1806 and the microcode SVN 1805 enter a PRF loop 1808.
  • the microcode SVN 1805 and the global root logic key 1803 enter another PRF loop 1809.
  • the output of PRF loop 1808 is stored in the SVN key 1810 register.
  • the output of PRF loop 1809 is stored in the global key register 1812.
  • the microcode SVN 1805 is stored in the TCB SVN Register 1814.
  • the global wrapping logic key 1801 and the SE EPID A.x fuses 1893 are inputs to the unwrap 1807 function and the results are stored in the SE EPID 1816 register.
  • the MCheck SVN 1821 and the output of the TCB SVN register 1814 are stored in the TCB SVN register
  • 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.
  • the microcode SVN 1831 and the output of 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.
  • the microcode SVN difference 1841 enters the PRF loop 1842 and PRF loop 1844.
  • the microcode SVN 1832 register sends data to the PRF loop 1842
  • the global key register 1834 sends data to the PRF loop 1844.
  • the output of PRF loop 1842 and the output of the TCB SVN register 1836 enter a PRF loop 1846
  • the output of PRF loop 1844 and the output of the TCP3 SVN Register 1836 enter a PRF loop 1848.
  • the output of PRF loop 1846 is stored in SVN base key 1850
  • the output of PRF loop 1848 is stored in global key 1852.
  • the Intel not known unique root fuse 1894 is stored in the seedl 1856 while the EPID group ID fuses are stored in EPID rroup 1858.
  • the seedl 1856 enters PRF loop 1886 and PRF loop 1888.
  • the output of PRF loop 1888 is the SE EPID Seed 1 1892.
  • the output of the PRF loop 1886 is the SE ops seed 1890.
  • the SE ops seed 1890 which comes from the SVN base key 1850, and the requested SVN 1864 enter a CMAC 1868 function to generate the SE ops key 1872.
  • the current SVN 1862 which comes from SVN base key 1850, enters a CMAC 1866 function to generate the SE provisioning key 1870.
  • the SVN base key 1850 is stored in the seedO 1876 .
  • the seedO 1876 enters the PRF loop 1878 and PRF loop 1880.
  • Output of PRF loop 1878 is the SE EPID ID 1882
  • output of PRF loop 1880 is SE EPID seedO 1884.
  • uCode applies a PRF Loop on the SVN key, and PRF loop on the OOBE key injecting the uCode's SVN into both keys. uCode writes it's SVN to the TCB SVN register and locks that portion
  • MCHECK loader or early MCHECK code writes MCHECK' s SVN to the TCB SVN register and locks it.
  • Microcode extensions patch loader writes the microcode extension patch SVN to the TCB SVN register and locks it.
  • extended microcode calculates the SE Base Keys needed to satisfy requests.
  • the Base Keys may be cached in the CMA for further use for increased performance.
  • Table Error! No text of specified style in document.-26 describes how the base keys are computed.
  • Seedl Fuses, not encrypted or locked.
  • Previous Ops Prev svn bask key XuMSRDeriveBaseKey (previous Keys svns )
  • EPID (DAK) SeedO XuMSRDeriveBaseKey ( 0 , 0 , 0 )
  • Base EPID ID PRF (SeedO, 0x01) ; Out of the Box XuMSRDeriveBaseKey (0x01, currentSVNs)
  • a 256-bit random Owner Epoch is included in the derivations of key. This value is created randomly during ownership change.
  • software may write the OwnerEpoch to the SE EPOCH MSR. This can be achieved by the BIOS, which stores it persistently in flash. It can be calculated from some user input, such as the hash of a user boot password. It can also be provided by a Secure Enclaves driver prior to allowing enclave use.
  • the SE Key Info structure is a non-persistent structure stored in a protected area of memory or the package.
  • the CMA is the most likely location, but any on die protected storage is also ok.
  • the SE Key Info is initialized. KeylD is set to a random value, and Key Count is set to 0. On each use of the Enclave Key, Permit Key, and Report key the KeylD read, and the Key Count is incremented. After 2 ⁇ 32 key uses, the KeylD is changed to a new random value, and Key Count is reset to 0.
  • the SE Key Info layout is shown in 5.
  • Key Count is set to zero each time the KeylD is initialized or incremented. The KeyCount is incremented by one for each AES block processed.
  • Lock 36 1 Compare-Set lock byte to synchronize access to the structure.
  • BIOS or other host firmware acquires the current Owner Epoch either from persistent storage or from the user and writes it to the LoadOwnerEpochMSR. At this point the enclave key hierarchy is available.
  • the Quoting Enclave uses the REPORT key to establish that a REPORT structure generated by the EREPORT instruction was created on the platform, and the PERMITTNG enclave uses the PERMIT key to create an enclave PERMIT which is consumed by ⁇ when an enclave is being launched.
  • any application level enclave needs access to a key to seal secrets which are stored on the platform outside the enclave, and will be unsealed when the application enclave is re-established -even across power cycles.
  • Themechanism for doing this is the EGETKEY instruction. It is the single interface for establishing secrets about the current software environment.
  • EGETKEY currently provides access to the following keys:
  • Enclave for identifying datablobs which have been uniquely encrypted using the PROVISIONING KEY) for the processor.
  • PROVISIONING KEY - used by the Architectural Provisioning Enclave to decrypt data blobs which have been uniquely encrypted for the processor.
  • ISV AUTH KEY - used by the Architectural Quoting Enclave to create authentication data for a particular target application enclave.
  • OOB EXPERIENCE KEY - used by ISVs for pre-provisioning encrypted data for out-of-box experience usages (e.g. BluRay players).
  • a KeyRequest structure is used as an input to the EGETKEY instruction.
  • the user wants the KeyRequest structure allows the caller to specify those variables under his control which he wishes to be used in the creation of the key.
  • Randomness Provides a random 256 bits value to be mixed into the key during derivation.
  • KeySelect is used to identify the key the user requires
  • KeyPolicy is used to establish which additional values are used in creating the key - whether that be a particular security version of the architectural enclaves, or a particular version of an application enclave, or the measurement registers associated with the current enclave (when
  • EGETKEY is called from within an ENCLAVE).
  • Additional randomness can also be added to the key derivation, this particularly required to prevent wearing of keys, and is used by the PERMITING and QUOTING architectural enclaves. It would also be used by the application enclave when creating SEALing keys. Setting the field to zero indicates that no additional randomness is to be added, otherwise the field points to a 256bit aligned data value.
  • the figure below specifies the structure for the KeySelect field.
  • KeyPolicy is a bit field selector and is used to determine if a particular value, either from the user or the system state is to be used in deriving the key.
  • the system may be reset to re- enable enclaves.
  • SE_EPOCH_MSR_0-3 will result in 0x0 being returned
  • the first enable is an opt in bit set by the BIOS. It is a write once function. It enables or disables enclave capability until the next reset.
  • the second enable is provided to the OS or VMM to turn enclave capabilities on or off dynamically as needed.
  • Figure 19 is a diagram for the enclave CTL_MSR register, which can be found in one embodiment of the invention.
  • the least significant bit is the Enable 1900.
  • Bit 1 of the register is On 1910.
  • Bits 2 through 63 are reserved.
  • the Enclave capability is enabled by first setting the Enable bit in the
  • BIOS sets the bit to enable enclaves. If BIOS clears the bit then enclaves cannot be enabled until the part is reset.
  • CPUID Software can detect support for enclaves by executing the CPUID instruction.
  • CPUID will return a result indicating whether enclaves are supported or not. If the Opt in bit is cleared then CPUID reports that enclaves will not execute.
  • Software can detect support for enclaves by executing the CPUID instruction.
  • Enclave support is indicated if the ON bit in the EnclaveCTL MSR is set
  • the TCSMSR register is a register on each processor which contains the address of the TCS. It is used by exception handling and the RDTCSPTR. It is loaded when entering the enclave. The register is loaded with the value of the TCS when EENTER is executed. It is read by ERDTCSPTR. The register size is based on the mode of the processor.
  • the enclave base address register on each processor contains the lower address of the enclave under execution. It is loaded when entering the enclave by the microcode.
  • the register size is based on the mode of the processor. This register is not visible to the software. It is a microcode temporary.
  • the register holds the upper address limit of the current enclave. It is loaded when entering the enclave.
  • the register is loaded with a value stored in the SECS when the enclave starts execution. It is a microcode temporary register. Register size is based on the mode of the processor.
  • the Enclave Page Cache (EPC) Maximum Size Register indicates the maximum size of the EPC. This size is given in the number of 4096 byte pages. It is a 32-bit register. This register is read only to indicate the largest size EPC supported in the current design.
  • the EPC Size Register EPC SIZE MSR indicates the currently defined size of the EPC. Loading the register results in an EPC defined to the size. The value is given in 4096 bit pages. For example, one 4096 bit page would be a 1. The value of the register cannot exceed EPC_MAX value. If the value exceeds the EPC_MAX value a GP fault is taken by the WRMSR instruction. Writing to this register will invalidate all data in the EPC prior to the write. Software may save all EPC entries (if needed) before updating this register.
  • the EPC base register indicates the location of the base of the EPC. Writing to this register will invalidate all data in the EPC prior to the write. Software may save all EPC entries (if needed) before updating this register.
  • FIG. 26 illustrates, for one embodiment of the invention, the processor package for a digital random number generator.
  • the processor package 2600 could contain multiple cores, CoreO 2640 and Corel 2670.
  • CoreO 2640 can contain external instruction microcode 2642, internal function microcode 2644, internal function microcode 2646, RNG microcode module 2650, and RNG queue 2654.
  • Corel 2670 can contain external instruction microcode 2672, internal function microcode 2674, internal function microcode 2676, RNG microcode module 2680, and RNG queue 2684.
  • Read random instruction 2630 can communicate with external instruction microcode 2642, while read random instruction 2635 can communicate with external microcode 2672.
  • the processor package 2600 could also include a DRNG 2602, which takes STD 2608, OPE 2610, PSK 2612, and TSC 2614.
  • the DRNG 2602 can contain a digital entropy source 2604, which connects to online self tests 2606.
  • the output of the online self tests 2606 could be one input of the combined conditioner/ deterministic random bit generator (DRBG) 2620.
  • DRBG deterministic random bit generator
  • An enclave can be set as a debug enclave when it is created.
  • the debug enclave will allow external access to the enclave contents using the EDBGRD and EDBGWR instructions.
  • a debug enclave is set up by setting the debug flag in the ECREATE instruction. This bit is stored inside the SECS of the enclave.
  • Enclaves which are created with the debug bit clear are production enclaves.
  • the EPC contains a debug bit which indicates that the enclave is a debug enclave.
  • the enclave remains encrypted inside main memory or on disk. Debuggers needing to look at the enclave contents will load the memory into the EPC.
  • the EDBGRD and EDBGWR instructions can be used to access enclave memory locations which reside in the EPC.A debug enclave does not require a permit in order to execute. It will execute without a valid permit.
  • FIG. 27 illustrates, for one embodiment of the invention, a debug register DR7 2700.
  • the register DR7 2700 contains bits LO 2702, LI 2706, L2 2710, L3 2714, GO 2704, Gl 2708, G2 2712, and G3 2716.
  • Other bits in the DR7 register 2700 include LE 2718, GE 2720, 001 2722, GD 2724, 00 2726, R/WO 2728, LENO 2730, RAVI 2732, LEN1 2734, R/W2 2736, LEN2 2738, R/W3 2740, and LEN3 2742.
  • Bits L3-L0 and G3-G0 are set to zero value. DR7 is returned to its original value at enclave exit.
  • the debug register value is not changed.
  • RFLAGS.TF is set at the start of an EENTER instruction, there are two cases to be considered:
  • the debugger is a legacy (non SE-aware) or the enclave is in production (non- debug) mode.
  • An SE-aware debugger is targeting a debug-mode enclave.
  • the #DB exception may occur on the target of the next EEXIT instruction. This treats the enclave as large, opaque operation.
  • the user has complete freedom to single step through the enclave. This behavior is supported by 3 data fields inside the enclave and special processing of RFLAGS.TF on EENTER, EEXIT and EIRET.
  • Interrupt SSA :RFLAGS.TF - RFLAGS.TF
  • the register value is saved in the TCS save area.
  • the register is set to 0.
  • At enclave exit the register is restored to the value at entry. If the enclave has branch trace enabled at entry the EENTER is the last entry before entering the enclave. When exiting the enclave the first location after the exit is written to the branch trace.
  • Int n and Int 3 instructions are reported as GP faults if executed inside the enclave.
  • the debugger may hook the GP fault condition when debugging an enclave.
  • CMAC is a mode supporting message authenticity. It accepts as input a message A and a key K and returns an authentication tag T. The derivation of the authentication tag is done using the CBC (cipher block chaining) algorithm.
  • CBC cipher block chaining
  • CMAC is more complex than CBC because it includes mechanisms for protecting against length extension attacks. We refer to these as the 'three peculiarities of CMAC. In what follows we provide an overview of CBC and CMAC.
  • Figure 20 illustrates the cipher block chaining algorithm used in one embodiment of the invention.
  • the initialization vector 2000 and the stage-one input 2010 enter the exclusive-or gate 2012.
  • the output of the exclusive-or gate 2012 enters the stage-one block cipher 2015.
  • the stage-one block cipher output 2018 then enters the stage-two exclusive-or gate 2022 along with the stage-two input 2020.
  • the output of the exclusive- or gate 2022 enters the stage-two block cipher 2025.
  • the stage-two block cipher output 2028 then enters the next stage of the cipher block chain (not pictured).
  • the CBC algorithm utilizes a block cipher to provide confidentiality for some piece of data or to compute an authentication tag on this data.
  • the main idea behind the CBC algorithm is that the output from the previous encryption is XOR-ed with the next input block before being encrypted. In this way patterns which may exist in the input data are eliminated in the ciphertext. Also the combination of the XOR operations between and the transformations of the block cipher provide strong mixing for deriving a message authentication tag which ideally is not forgeable.
  • the CBC algorithm is given below and illustrated in Figure 20.
  • the cipher is assumed to be a 128-bit block cipher as in the case of AES
  • the CMAC specification includes three additional algorithms for initializing and finalizing the CBC algorithm. We refer to these as the "three peculiarities" of CMAC.
  • the first peculiarity concerns the derivation of two subkey values K ⁇ and Ki from the symmetric key K.
  • Subkeys K ⁇ and Ki derive from an intermediate value L.
  • CMAC specifies that L derives by applying the symmetric key block cipher transformation on a string consisting of zeros (i.e., 0 128 ) using the symmetric key value K. Such relationship is shown in equation (1):
  • L is derived the most significant bit of L is checked. If this is zero then K ⁇ derives from L by shifting by one bit position to the left. Otherwise L is shifted by one bit position to the left and also XOR-ed with a special value R b to produce K ⁇ .
  • R b is defiend as ⁇ 0 120 100001 11> in binary form. Ki is produced from K ⁇ following the same procedure.
  • the derivation of subkeys K K 2 is given in pseudo-code below. By MSB() we mean the most significant bit of a value.
  • the second peculiarity of CMAC concerns the padding that takes place before applying the CBC algorithm on the input data. If the last block of data is not a complete block then the block is padded with a bit equal to "1" followed by as many zero as needed so that the final block becomes complete.
  • the third peculiarity of CMAC concerns a modification on the last block that takes place in order to avoid length extension attacks. If the last block is a complete one (no padding required) then the last block is XOR-ed with the subkey K ⁇ , Otherwise it is XOR- ed with the subkey K 2.
  • bit data (state) from xmml with a xmml xmm2/128 128-bit round key from xmm2/128 performs one round of an AES
  • AESKEYGENASSIST is used for generating the round keys, used for encryption.
  • AESIMC is used for converting the encryption round keys to a form usable for decryption according to the equivalent inverse cipher model.
  • the description of the AESIMC and AESKEYGENASSIST instructions is given in
  • CMAC is specified using the big endian notation for the 128-bit quantities involved. To implement CMAC in a little endian machine correctly one needs to perform 16 byte-wide byte reflection operations at certain points in the source code
  • xrrtfaO [3] ( ( xrrmO [3] (_ximO [2] » 31) )
  • xrrtfaO [1] ( ( xrrmO [1] (_ximO [0] » 31) )
  • xrrtfaO [3] ( ( xrrmO [3] (_ximO [2] » 31) )
  • xrrtfaO [2] ( ( xrrmO [2] (_ximO [1] » 31) )
  • xrr ⁇ aO [1] ( ( xrrmO [1] (_ximO [0] » 31) )
  • uint32_t lr bit_length%128 ;
  • uint32_t lq bit_length/128 ;

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Storage Device Security (AREA)
  • Memory System Of A Hierarchy Structure (AREA)
  • Retry When Errors Occur (AREA)

Abstract

La présente invention concerne une technique pour permettre une application sécurisée et obtenir une intégrité des données dans un système informatique. Dans un mode de réalisation, on établit une ou plusieurs enclaves sécurisées dans lesquelles une application et des données peuvent être stockées et exécutées.
PCT/US2009/069212 2009-12-22 2009-12-22 Procédé et appareil permettant d'exécuter une application sécurisée WO2011078855A1 (fr)

Priority Applications (11)

Application Number Priority Date Filing Date Title
JP2012516046A JP5443599B2 (ja) 2009-12-22 2009-12-22 セキュアなアプリケーションの実行を提供する方法および装置
KR1020127016450A KR101457355B1 (ko) 2009-12-22 2009-12-22 보안 애플리케이션 실행을 제공하는 방법 및 장치
PCT/US2009/069212 WO2011078855A1 (fr) 2009-12-22 2009-12-22 Procédé et appareil permettant d'exécuter une application sécurisée
DE112009005466T DE112009005466T5 (de) 2009-12-22 2009-12-22 Verfahren und Vorrichtung zum Bereitstellen einer sicheren Anwendungsausführung
BRPI0924512A BRPI0924512A2 (pt) 2009-12-22 2009-12-22 método e aparelho de fornecimento de execução de aplicativos seguros
GB1118724.2A GB2481563B (en) 2009-12-22 2009-12-22 Method and apparatus to provide secure application execution
CN200980160114.XA CN102473224B (zh) 2009-12-22 2009-12-22 提供安全应用执行的方法和装置
GB1709341.0A GB2550698B (en) 2009-12-22 2009-12-22 Method and Apparatus to provide secure application execution
US13/527,547 US9087200B2 (en) 2009-12-22 2012-06-19 Method and apparatus to provide secure application execution
US13/802,272 US10102380B2 (en) 2009-12-22 2013-03-13 Method and apparatus to provide secure application execution
US16/123,593 US10885202B2 (en) 2009-12-22 2018-09-06 Method and apparatus to provide secure application execution

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2009/069212 WO2011078855A1 (fr) 2009-12-22 2009-12-22 Procédé et appareil permettant d'exécuter une application sécurisée

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/527,547 Continuation-In-Part US9087200B2 (en) 2009-12-22 2012-06-19 Method and apparatus to provide secure application execution

Publications (2)

Publication Number Publication Date
WO2011078855A1 true WO2011078855A1 (fr) 2011-06-30
WO2011078855A9 WO2011078855A9 (fr) 2011-09-09

Family

ID=44196072

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2009/069212 WO2011078855A1 (fr) 2009-12-22 2009-12-22 Procédé et appareil permettant d'exécuter une application sécurisée

Country Status (7)

Country Link
JP (1) JP5443599B2 (fr)
KR (1) KR101457355B1 (fr)
CN (1) CN102473224B (fr)
BR (1) BRPI0924512A2 (fr)
DE (1) DE112009005466T5 (fr)
GB (2) GB2550698B (fr)
WO (1) WO2011078855A1 (fr)

Cited By (41)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8739177B2 (en) 2010-06-21 2014-05-27 Intel Corporation Method for network interface sharing among multiple virtual machines
US20140157410A1 (en) * 2012-11-30 2014-06-05 Prashant Dewan Secure Environment for Graphics Processing Units
US20140189246A1 (en) * 2012-12-31 2014-07-03 Bin Xing Measuring applications loaded in secure enclaves at runtime
US20140189326A1 (en) * 2012-12-28 2014-07-03 Rebekah Leslie Memory management in secure enclaves
US20140189325A1 (en) * 2012-12-28 2014-07-03 Francis X. McKeen Paging in secure enclaves
US20140297962A1 (en) * 2013-03-31 2014-10-02 Carlos V Rozas Instructions and logic to provide advanced paging capabilities for secure enclave page caches
US20140337983A1 (en) * 2013-05-10 2014-11-13 Xiaozhu Kang Entry/Exit Architecture for Protected Device Modules
WO2014201059A1 (fr) * 2013-06-10 2014-12-18 Certimix, Llc Stockage sécurisé et transfert hors ligne de bien transférable numériquement
US20150033034A1 (en) * 2013-07-23 2015-01-29 Gideon Gerzon Measuring a secure enclave
WO2015047789A1 (fr) * 2013-09-24 2015-04-02 Intel Corporation Création d'un nouveau partitionnement pour une mémoire sécurisée
WO2015060858A1 (fr) * 2013-10-24 2015-04-30 Intel Corporation Procédés et appareils destinés à protéger des logiciels contre une copie non autorisée
US9053042B2 (en) 2012-06-27 2015-06-09 Intel Corporation Method, system, and device for modifying a secure enclave configuration without changing the enclave measurement
US9058494B2 (en) 2013-03-15 2015-06-16 Intel Corporation Method, apparatus, system, and computer readable medium to provide secure operation
WO2015147986A1 (fr) * 2014-03-25 2015-10-01 Intel Corporation Concentrateur à noeuds multiples pour une informatique de confiance
WO2016060859A1 (fr) * 2014-10-17 2016-04-21 Intel Corporation Interface entre un dispositif et un environnement de traitement sécurisé
US9338918B2 (en) 2013-07-10 2016-05-10 Samsung Electronics Co., Ltd. Socket interposer and computer system using the socket interposer
CN105723377A (zh) * 2013-12-17 2016-06-29 英特尔公司 供内核模式应用使用的安全区域
US9448950B2 (en) 2013-12-24 2016-09-20 Intel Corporation Using authenticated manifests to enable external certification of multi-processor platforms
US9501668B2 (en) 2013-09-25 2016-11-22 Intel Corporation Secure video ouput path
EP3025268A4 (fr) * 2013-07-23 2017-03-01 Intel Corporation Octroi d'une licence sur une fonctionnalité dans un environnement de traitement sécurisé
US9606940B2 (en) 2015-03-27 2017-03-28 Intel Corporation Methods and apparatus to utilize a trusted loader in a trusted computing environment
WO2017058408A3 (fr) * 2015-09-25 2017-05-26 Intel Corporation Protection de métadonnées d'un moteur de chiffrement sans mémoire (non mee) dans un environnement d'exécution fiable
US9705892B2 (en) 2014-06-27 2017-07-11 Intel Corporation Trusted time service for offline mode
US9864861B2 (en) 2014-03-27 2018-01-09 Intel Corporation Object oriented marshaling scheme for calls to a secure region
US9875189B2 (en) 2015-06-12 2018-01-23 Intel Corporation Supporting secure memory intent
US9940456B2 (en) 2014-12-16 2018-04-10 Intel Corporation Using trusted execution environments for security of code and data
US9990314B2 (en) 2014-06-27 2018-06-05 Intel Corporation Instructions and logic to interrupt and resume paging in a secure enclave page cache
US10102380B2 (en) 2009-12-22 2018-10-16 Intel Corporation Method and apparatus to provide secure application execution
US10121144B2 (en) 2013-11-04 2018-11-06 Apple Inc. Using biometric authentication for NFC-based payments
GB2563882A (en) * 2017-06-28 2019-01-02 Advanced Risc Mach Ltd Interrupting sequences of command actions performed upon memory regions
GB2564097A (en) * 2017-06-28 2019-01-09 Advanced Risc Mach Ltd Memory region locking
WO2019089403A1 (fr) * 2017-11-03 2019-05-09 Microsoft Technology Licensing, Llc Fourniture d'environnement(s) d'exécution de confiance sur la base d'une chaîne de confiance comprenant une plate-forme
EP3528130A1 (fr) * 2018-02-15 2019-08-21 INTEL Corporation Mécanisme pour éviter des canaux secondaires de logiciel
EP3547201A1 (fr) * 2018-03-30 2019-10-02 INTEL Corporation Techniques d'attribution dynamique de ressources mémoires entre des domaines cryptographiques
US10552344B2 (en) 2017-12-26 2020-02-04 Intel Corporation Unblock instruction to reverse page block during paging
US10787452B2 (en) 2012-12-07 2020-09-29 Vertex Pharmaceuticals Incorporated Compounds useful as inhibitors of ATR kinase
US10867092B2 (en) 2017-12-16 2020-12-15 Intel Corporation Avoiding asynchronous enclave exits based on requests to invalidate translation lookaside buffer entries
US11016910B2 (en) 2017-06-28 2021-05-25 Arm Limited Memory region locking using lock/unlock flag state for exclusive rights to control memory access
CN113821835A (zh) * 2021-11-24 2021-12-21 飞腾信息技术有限公司 密钥管理方法、密钥管理装置和计算设备
US11474916B2 (en) 2018-08-22 2022-10-18 Intel Corporation Failover of virtual devices in a scalable input/output (I/O) virtualization (S-IOV) architecture
US11943368B2 (en) 2017-11-03 2024-03-26 Microsoft Technology Licensing, Llc Provisioning trusted execution environment based on chain of trust including platform

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9053059B2 (en) * 2013-03-06 2015-06-09 Intel Corporation Roots-of-trust for measurement of virtual machines
US9514317B2 (en) * 2013-12-19 2016-12-06 Intel Corporation Policy-based trusted inspection of rights managed content
KR101883816B1 (ko) * 2013-12-19 2018-07-31 인텔 코포레이션 클라이언트 디바이스 상에서의 다수의 디지털 저작권 관리 프로토콜 지원 기술
CN105573831B (zh) * 2014-10-13 2019-11-26 龙芯中科技术有限公司 数据转移方法和装置
US9710622B2 (en) * 2015-02-23 2017-07-18 Intel Corporation Instructions and logic to fork processes of secure enclaves and establish child enclaves in a secure enclave page cache
US9716710B2 (en) * 2015-06-26 2017-07-25 Intel Corporation Technologies for virtualized access to security services provided by a converged manageability and security engine
US9996479B2 (en) * 2015-08-17 2018-06-12 Micron Technology, Inc. Encryption of executables in computational memory
US10061941B2 (en) 2015-08-19 2018-08-28 Altera Corporation Systems and methods for multiport to multiport cryptography
US10846409B2 (en) * 2015-11-19 2020-11-24 Nagravision S.A. Method to verify the execution integrity of an application in a target device
US9798641B2 (en) * 2015-12-22 2017-10-24 Intel Corporation Method to increase cloud availability and silicon isolation using secure enclaves
US10503931B2 (en) * 2016-05-09 2019-12-10 Arris Enterprises Llc Method and apparatus for dynamic executable verification
IE20170239A1 (en) 2016-11-14 2018-05-16 Google Llc System of Enclaves
US10324857B2 (en) * 2017-01-26 2019-06-18 Intel Corporation Linear memory address transformation and management
CN108469986B (zh) * 2017-02-23 2021-04-09 华为技术有限公司 一种数据迁移方法及装置
CN111259380B (zh) * 2017-08-22 2021-02-12 海光信息技术股份有限公司 内存页转移方法和函数调用方法
KR102080497B1 (ko) * 2017-10-31 2020-02-24 삼성에스디에스 주식회사 멀티 채널 블록 체인 기반 시스템의 채널간 데이터 교환 방법 및 그 시스템
CN111614464B (zh) * 2019-01-31 2023-09-29 创新先进技术有限公司 区块链中安全更新密钥的方法及节点、存储介质
CN110032883B (zh) * 2019-01-31 2020-05-29 阿里巴巴集团控股有限公司 区块链中实现隐私保护的方法、系统和节点
CN110008736A (zh) * 2019-01-31 2019-07-12 阿里巴巴集团控股有限公司 区块链中实现隐私保护的方法及节点、存储介质
CN110032885B (zh) * 2019-02-19 2020-03-06 阿里巴巴集团控股有限公司 区块链中实现隐私保护的方法、节点和存储介质
CN109901880B (zh) * 2019-02-28 2020-11-20 瑞芯微电子股份有限公司 一种spinlock硬件电路及电子设备
CN110069920A (zh) * 2019-03-06 2019-07-30 上海交通大学 基于虚拟化保证sgx安全性的方法和系统
CN110096887B (zh) 2019-03-22 2020-06-30 阿里巴巴集团控股有限公司 一种可信计算方法及服务器
SG11202000825YA (en) * 2019-04-19 2020-02-27 Alibaba Group Holding Ltd Methods and devices for executing trusted applications on processor with support for protected execution environments
US11044080B2 (en) 2019-06-24 2021-06-22 International Business Machines Corporation Cryptographic key orchestration between trusted containers in a multi-node cluster
JP6885640B1 (ja) * 2020-10-01 2021-06-16 株式会社ラムダシステムズ 画像処理装置
US11792644B2 (en) * 2021-06-21 2023-10-17 Motional Ad Llc Session key generation for autonomous vehicle operation

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060075312A1 (en) * 2004-09-30 2006-04-06 Fischer Stephen A System and method for limiting exposure of hardware failure information for a secured execution environment
US20070277223A1 (en) * 2006-05-26 2007-11-29 Datta Shamanna M Execution of a secured environment initialization instruction on a point-to-point interconnect system
KR20070118589A (ko) * 2005-02-11 2007-12-17 유니버셜 데이터 프로텍션 코퍼레이션 마이크로프로세서 데이터 보안을 위한 방법 및 시스템
KR20080074848A (ko) * 2005-12-08 2008-08-13 에이저 시스템즈 인크 마이크로제어기 내의 데이터 보안 처리를 위한 방법 및장치

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4098478B2 (ja) * 2001-01-31 2008-06-11 株式会社東芝 マイクロプロセッサ
JP2002353960A (ja) * 2001-05-30 2002-12-06 Fujitsu Ltd コード実行装置およびコード配布方法
JP4263976B2 (ja) * 2003-09-24 2009-05-13 株式会社東芝 オンチップマルチコア型耐タンパプロセッサ
CN101116081A (zh) * 2005-02-11 2008-01-30 通用数据保护公司 用于微处理器数据安全的方法和系统
JP4795812B2 (ja) * 2006-02-22 2011-10-19 富士通セミコンダクター株式会社 セキュアプロセッサ
JP2008033457A (ja) * 2006-07-26 2008-02-14 Internatl Business Mach Corp <Ibm> 暗号化ソフトウェアを処理する方法及び中央処理装置
JP4912921B2 (ja) * 2007-02-27 2012-04-11 富士通セミコンダクター株式会社 セキュアプロセッサシステム、セキュアプロセッサ及びセキュアプロセッサシステムの制御方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060075312A1 (en) * 2004-09-30 2006-04-06 Fischer Stephen A System and method for limiting exposure of hardware failure information for a secured execution environment
KR20070118589A (ko) * 2005-02-11 2007-12-17 유니버셜 데이터 프로텍션 코퍼레이션 마이크로프로세서 데이터 보안을 위한 방법 및 시스템
KR20080074848A (ko) * 2005-12-08 2008-08-13 에이저 시스템즈 인크 마이크로제어기 내의 데이터 보안 처리를 위한 방법 및장치
US20070277223A1 (en) * 2006-05-26 2007-11-29 Datta Shamanna M Execution of a secured environment initialization instruction on a point-to-point interconnect system

Cited By (90)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10102380B2 (en) 2009-12-22 2018-10-16 Intel Corporation Method and apparatus to provide secure application execution
US10885202B2 (en) 2009-12-22 2021-01-05 Intel Corporation Method and apparatus to provide secure application execution
US8739177B2 (en) 2010-06-21 2014-05-27 Intel Corporation Method for network interface sharing among multiple virtual machines
US9053042B2 (en) 2012-06-27 2015-06-09 Intel Corporation Method, system, and device for modifying a secure enclave configuration without changing the enclave measurement
US20140157410A1 (en) * 2012-11-30 2014-06-05 Prashant Dewan Secure Environment for Graphics Processing Units
US9519803B2 (en) * 2012-11-30 2016-12-13 Intel Corporation Secure environment for graphics processing units
CN104769605A (zh) * 2012-11-30 2015-07-08 英特尔公司 用于图形处理单元的安全环境
CN104769605B (zh) * 2012-11-30 2018-06-01 英特尔公司 用于图形处理单元的安全环境
US10787452B2 (en) 2012-12-07 2020-09-29 Vertex Pharmaceuticals Incorporated Compounds useful as inhibitors of ATR kinase
US9766889B2 (en) 2012-12-28 2017-09-19 Intel Corporation Memory management in secure enclaves
CN108710585A (zh) * 2012-12-28 2018-10-26 英特尔公司 安全区域内的存储器管理
US9990197B2 (en) 2012-12-28 2018-06-05 Intel Corporation Memory management in secure enclaves
US20140189325A1 (en) * 2012-12-28 2014-07-03 Francis X. McKeen Paging in secure enclaves
US10409597B2 (en) 2012-12-28 2019-09-10 Intel Corporation Memory management in secure enclaves
US9690704B2 (en) * 2012-12-28 2017-06-27 Intel Corporation Paging in secure enclaves
US20140189326A1 (en) * 2012-12-28 2014-07-03 Rebekah Leslie Memory management in secure enclaves
US9323686B2 (en) * 2012-12-28 2016-04-26 Intel Corporation Paging in secure enclaves
CN104813330A (zh) * 2012-12-31 2015-07-29 英特尔公司 在运行时测量在安全区域内加载的应用
US20140189246A1 (en) * 2012-12-31 2014-07-03 Bin Xing Measuring applications loaded in secure enclaves at runtime
US9058494B2 (en) 2013-03-15 2015-06-16 Intel Corporation Method, apparatus, system, and computer readable medium to provide secure operation
GB2534037A (en) * 2013-03-31 2016-07-13 Intel Corp Instructions and logic to provide advanced paging capabilities for secure enclave page caches
US20160371191A1 (en) * 2013-03-31 2016-12-22 Intel Corporation Instructions and logic to provide advanced paging capabilities for secure enclave page caches
US20140297962A1 (en) * 2013-03-31 2014-10-02 Carlos V Rozas Instructions and logic to provide advanced paging capabilities for secure enclave page caches
US10592421B2 (en) * 2013-03-31 2020-03-17 Intel Corporation Instructions and logic to provide advanced paging capabilities for secure enclave page caches
GB2522137B (en) * 2013-03-31 2015-12-02 Intel Corp Instructions and logic to provide advanced paging capabilities for secure enclave page caches
US9430384B2 (en) * 2013-03-31 2016-08-30 Intel Corporation Instructions and logic to provide advanced paging capabilities for secure enclave page caches
GB2534037B (en) * 2013-03-31 2016-10-19 Intel Corp Instructions and logic to provide advanced paging capabilities for secure enclave page caches
GB2522137A (en) * 2013-03-31 2015-07-15 Intel Corp Instructions and logic to provide advanced paging capabilities for secure enclave page caches
US9087202B2 (en) * 2013-05-10 2015-07-21 Intel Corporation Entry/exit architecture for protected device modules
US20140337983A1 (en) * 2013-05-10 2014-11-13 Xiaozhu Kang Entry/Exit Architecture for Protected Device Modules
US9652609B2 (en) 2013-05-10 2017-05-16 Intel Corporation Entry/exit architecture for protected device modules
WO2014201059A1 (fr) * 2013-06-10 2014-12-18 Certimix, Llc Stockage sécurisé et transfert hors ligne de bien transférable numériquement
US9338918B2 (en) 2013-07-10 2016-05-10 Samsung Electronics Co., Ltd. Socket interposer and computer system using the socket interposer
CN105339912A (zh) * 2013-07-23 2016-02-17 英特尔公司 测量安全区域
EP3025268A4 (fr) * 2013-07-23 2017-03-01 Intel Corporation Octroi d'une licence sur une fonctionnalité dans un environnement de traitement sécurisé
EP3025266A4 (fr) * 2013-07-23 2017-03-01 Intel Corporation Mesure d'une enclave sécurisée
US20150033034A1 (en) * 2013-07-23 2015-01-29 Gideon Gerzon Measuring a secure enclave
US9698989B2 (en) 2013-07-23 2017-07-04 Intel Corporation Feature licensing in a secure processing environment
CN105339912B (zh) * 2013-07-23 2018-10-12 英特尔公司 测量安全区域
US9767044B2 (en) 2013-09-24 2017-09-19 Intel Corporation Secure memory repartitioning
WO2015047789A1 (fr) * 2013-09-24 2015-04-02 Intel Corporation Création d'un nouveau partitionnement pour une mémoire sécurisée
US9501668B2 (en) 2013-09-25 2016-11-22 Intel Corporation Secure video ouput path
US9536063B2 (en) 2013-10-24 2017-01-03 Intel Corporation Methods and apparatus for protecting software from unauthorized copying
WO2015060858A1 (fr) * 2013-10-24 2015-04-30 Intel Corporation Procédés et appareils destinés à protéger des logiciels contre une copie non autorisée
US10121144B2 (en) 2013-11-04 2018-11-06 Apple Inc. Using biometric authentication for NFC-based payments
US12026705B2 (en) 2013-11-04 2024-07-02 Apple Inc. System and method for payments using biometric authentication
US10691618B2 (en) 2013-12-17 2020-06-23 Intel Corporation Secure enclaves for use by kernel mode applications
EP3084614A4 (fr) * 2013-12-17 2017-07-19 Intel Corporation Enclaves sécurisées destinées à être utilisées par des applications en mode noyau
CN105723377B (zh) * 2013-12-17 2019-06-04 英特尔公司 供内核模式应用使用的安全区域
CN105723377A (zh) * 2013-12-17 2016-06-29 英特尔公司 供内核模式应用使用的安全区域
US9448950B2 (en) 2013-12-24 2016-09-20 Intel Corporation Using authenticated manifests to enable external certification of multi-processor platforms
US9781117B2 (en) 2014-03-25 2017-10-03 Intel Corporation Multinode hubs for trusted computing
WO2015147986A1 (fr) * 2014-03-25 2015-10-01 Intel Corporation Concentrateur à noeuds multiples pour une informatique de confiance
US9413765B2 (en) 2014-03-25 2016-08-09 Intel Corporation Multinode hubs for trusted computing
US9864861B2 (en) 2014-03-27 2018-01-09 Intel Corporation Object oriented marshaling scheme for calls to a secure region
US9990314B2 (en) 2014-06-27 2018-06-05 Intel Corporation Instructions and logic to interrupt and resume paging in a secure enclave page cache
US9705892B2 (en) 2014-06-27 2017-07-11 Intel Corporation Trusted time service for offline mode
US10181027B2 (en) 2014-10-17 2019-01-15 Intel Corporation Interface between a device and a secure processing environment
TWI608378B (zh) * 2014-10-17 2017-12-11 英特爾股份有限公司 裝置與安全處理環境之間的介面
WO2016060859A1 (fr) * 2014-10-17 2016-04-21 Intel Corporation Interface entre un dispositif et un environnement de traitement sécurisé
US10169574B2 (en) 2014-12-16 2019-01-01 Intel Corporation Using trusted execution environments for security of code and data
US9940456B2 (en) 2014-12-16 2018-04-10 Intel Corporation Using trusted execution environments for security of code and data
US9606940B2 (en) 2015-03-27 2017-03-28 Intel Corporation Methods and apparatus to utilize a trusted loader in a trusted computing environment
US11995001B2 (en) 2015-06-12 2024-05-28 Intel Corporation Supporting secure memory intent
US10282306B2 (en) 2015-06-12 2019-05-07 Intel Corporation Supporting secure memory intent
US11392507B2 (en) 2015-06-12 2022-07-19 Intel Corporation Supporting secure memory intent
US10922241B2 (en) 2015-06-12 2021-02-16 Intel Corporation Supporting secure memory intent
US9875189B2 (en) 2015-06-12 2018-01-23 Intel Corporation Supporting secure memory intent
WO2017058408A3 (fr) * 2015-09-25 2017-05-26 Intel Corporation Protection de métadonnées d'un moteur de chiffrement sans mémoire (non mee) dans un environnement d'exécution fiable
US10031861B2 (en) 2015-09-25 2018-07-24 Intel Corporation Protect non-memory encryption engine (non-mee) metadata in trusted execution environment
US11016910B2 (en) 2017-06-28 2021-05-25 Arm Limited Memory region locking using lock/unlock flag state for exclusive rights to control memory access
GB2564097B (en) * 2017-06-28 2019-10-23 Advanced Risc Mach Ltd Memory region locking
GB2563882B (en) * 2017-06-28 2019-10-23 Advanced Risc Mach Ltd Interrupting sequences of command actions performed upon memory regions
GB2563882A (en) * 2017-06-28 2019-01-02 Advanced Risc Mach Ltd Interrupting sequences of command actions performed upon memory regions
GB2564097A (en) * 2017-06-28 2019-01-09 Advanced Risc Mach Ltd Memory region locking
WO2019089403A1 (fr) * 2017-11-03 2019-05-09 Microsoft Technology Licensing, Llc Fourniture d'environnement(s) d'exécution de confiance sur la base d'une chaîne de confiance comprenant une plate-forme
US11943368B2 (en) 2017-11-03 2024-03-26 Microsoft Technology Licensing, Llc Provisioning trusted execution environment based on chain of trust including platform
US10867092B2 (en) 2017-12-16 2020-12-15 Intel Corporation Avoiding asynchronous enclave exits based on requests to invalidate translation lookaside buffer entries
US10552344B2 (en) 2017-12-26 2020-02-04 Intel Corporation Unblock instruction to reverse page block during paging
EP3528130A1 (fr) * 2018-02-15 2019-08-21 INTEL Corporation Mécanisme pour éviter des canaux secondaires de logiciel
US10970390B2 (en) 2018-02-15 2021-04-06 Intel Corporation Mechanism to prevent software side channels
US10838773B2 (en) 2018-03-30 2020-11-17 Intel Corporation Techniques for dynamic resource allocation among cryptographic domains
EP3547201A1 (fr) * 2018-03-30 2019-10-02 INTEL Corporation Techniques d'attribution dynamique de ressources mémoires entre des domaines cryptographiques
US11556436B2 (en) 2018-08-22 2023-01-17 Intel Corporation Memory enclaves using process address space identifiers in a scalable input/output (I/O) virtualization (S-IOV) architecture
US11513924B2 (en) 2018-08-22 2022-11-29 Intel Corporation Flexible memory mapped input/output (I/O) space definition for a virtual device in a scalable I/O virtualization (S-IOV) architecture
US11556437B2 (en) 2018-08-22 2023-01-17 Intel Corporation Live migration of virtual devices in a scalable input/output (I/O) virtualization (S-IOV) architecture
US11573870B2 (en) 2018-08-22 2023-02-07 Intel Corporation Zero copy host interface in a scalable input/output (I/O) virtualization (S-IOV) architecture
US11474916B2 (en) 2018-08-22 2022-10-18 Intel Corporation Failover of virtual devices in a scalable input/output (I/O) virtualization (S-IOV) architecture
CN113821835B (zh) * 2021-11-24 2022-02-08 飞腾信息技术有限公司 密钥管理方法、密钥管理装置和计算设备
CN113821835A (zh) * 2021-11-24 2021-12-21 飞腾信息技术有限公司 密钥管理方法、密钥管理装置和计算设备

Also Published As

Publication number Publication date
GB201709341D0 (en) 2017-07-26
JP2012530961A (ja) 2012-12-06
DE112009005466T5 (de) 2012-10-31
KR101457355B1 (ko) 2014-11-04
GB2481563A (en) 2011-12-28
JP5443599B2 (ja) 2014-03-19
GB2550698B (en) 2018-04-11
WO2011078855A9 (fr) 2011-09-09
GB2550698A (en) 2017-11-29
GB2481563B (en) 2017-07-19
CN102473224B (zh) 2016-10-12
BRPI0924512A2 (pt) 2016-03-01
KR20120099472A (ko) 2012-09-10
GB201118724D0 (en) 2011-12-14
CN102473224A (zh) 2012-05-23

Similar Documents

Publication Publication Date Title
US10885202B2 (en) Method and apparatus to provide secure application execution
US9904632B2 (en) Technique for supporting multiple secure enclaves
KR101457355B1 (ko) 보안 애플리케이션 실행을 제공하는 방법 및 장치
US10325118B2 (en) Cryptographic cache lines for a trusted execution environment
US11520611B2 (en) Secure public cloud using extended paging and memory integrity
Maene et al. Hardware-based trusted computing architectures for isolation and attestation
US9989043B2 (en) System and method for processor-based security
US7073059B2 (en) Secure machine platform that interfaces to operating systems and customized control programs
JP2005527019A (ja) マルチトークンのシール及びシール解除
Kumar et al. Towards designing a secure RISC-V system-on-chip: ITUS
JP6068325B2 (ja) セキュアなアプリケーションの実行を提供するプロセッサ
JP6777288B2 (ja) プロセッサ
Donnini Integration of the DICE specification into the Keystone framework
JP6480403B2 (ja) 装置
JP6085320B2 (ja) プロセッサ、プログラム、システム及び方法
Quaresma TrustZone based Attestation in Secure Runtime Verification for Embedded Systems
Cheruvu et al. Base Platform Security Hardware Building Blocks
Menda-Shabat Security Target
Cases Hardware-Enabled Security
vor starken Angreifern et al. Trusted Systems in Untrusted Environments: Protecting against Strong Attackers

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980160114.X

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09852678

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2012516046

Country of ref document: JP

ENP Entry into the national phase

Ref document number: 1118724

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20091222

WWE Wipo information: entry into national phase

Ref document number: 1118724.2

Country of ref document: GB

WWE Wipo information: entry into national phase

Ref document number: 9403/DELNP/2011

Country of ref document: IN

WWE Wipo information: entry into national phase

Ref document number: 1120090054668

Country of ref document: DE

Ref document number: 112009005466

Country of ref document: DE

ENP Entry into the national phase

Ref document number: 20127016450

Country of ref document: KR

Kind code of ref document: A

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: PI0924512

Country of ref document: BR

122 Ep: pct application non-entry in european phase

Ref document number: 09852678

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: PI0924512

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20111229