DE112009005466T5

DE112009005466T5 - Verfahren und Vorrichtung zum Bereitstellen einer sicheren Anwendungsausführung

Info

Publication number: DE112009005466T5
Application number: DE112009005466T
Authority: DE
Inventors: Francis X. McKeen; Carlos V. Rozas; Uday R. Savagankar; Simon P. Johnson; Vincent R. Scarlata; Ernie Brickell; Jiang Tao Li; Howard C. Herbert; Prashant Dewan; Stephen J. Tolopka; Gilbert Neigert; David Durham; Gary Graunke; Dion Rodgers; Asher Altman; Joseph Cihula; Stalinselvaraj Jeyasingh; A. Goldsmith Michael; Bernard Lint; Don A. Van Dyke
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2009-12-22
Filing date: 2009-12-22
Publication date: 2012-10-31
Also published as: JP2012530961A; GB2550698A; CN102473224A; CN102473224B; GB2550698B; KR101457355B1; GB2481563A; GB201709341D0; JP5443599B2; BRPI0924512A2; GB201118724D0; KR20120099472A; GB2481563B; WO2011078855A9; WO2011078855A1

Abstract

Eine Technik wird beschrieben, welche sichere Anwendungen und Datenintegrität innerhalb eines Computersystems ermöglicht. In einer Ausführungsform werden eine oder mehrere sichere Enklaven eingerichtet, in welchen eine Anwendung und Daten gespeichert und ausgeführt werden können.

Description

Bereich der Erfindung
Ausführungsformen der Erfindung beziehen sich allgemein auf den Bereich der Informationsverarbeitung und insbesondere auf den Bereich der Sicherheit in Computersystemen und Mikroprozessoren.
Hintergrund
Die Sicherung der Ausführung und Integrität von Anwendungen und ihrer Daten innerhalb eines Computersystems erlangt eine zunehmende Bedeutung. Einige Sicherheitstechniken des Stands der Technik versagen dabei, Anwendungen und Daten in einer flexiblen, jedoch zuverlässigen Art und Weise adäquat zu sichern.
Kurzbeschreibung der Zeichnungen
Ausführungsformen der Erfindung sind in den Figuren der begleitenden Zeichnungen beispielhaft und keinesfalls beschränkend dargestellt, in denen sich gleiche Bezugszeichen auf ähnliche Elemente beziehen und in denen:
1 ein Blockdiagramm eines Mikroprozessors darstellt, in dem mindestens eine Ausführungsform der Erfindung verwendet werden kann;
2 ein Blockdiagramm eines Computersystems mit einem gemeinsam genutzten Bus darstellt, in dem mindestens eine Ausführungsform der Erfindung verwendet werden kann;
3 ein Blockdiagramm eines Computersystems mit einer Punkt-zu-Punkt-Verbindung darstellt, in dem mindestens eine Ausführungsform der Erfindung verwendet werden kann.
4 stellt ein Blockdiagramm eines Mehrfachkern-Mikroprozessors dar, in dem mindestens eine Ausführungsform der Erfindung verwendet werden kann.
5 stellt eine mögliche Implementierung einer sicheren Enklave (SE) in einer Ausführungsform der Erfindung dar.
6 stellt ein Blockdiagramm eines Mikroprozessors dar, in dem mindestens eine Ausführungsform der Erfindung verwendet werden kann.
7 stellt ein Beispiel einer Kontrollstruktur zum Zugreifen auf einen Abschnitt des Enklavenseiten-Cache dar, der in einer Ausführungsform der Erfindung implementiert sein kann.
8 stellt ein Beispiel einer Thread-Kontrollstruktur in einer Ausführungsform der Erfindung dar, welche zeigt, wie die Datenstrukturen zusammengeheftet werden.
9 stellt einen Schritt des Prozesses der Softwarebeglaubigung dar, das als Notieren (Quoting) bekannt ist, das in einer Ausführungsform der Erfindung vorhanden sein kann.
10 stellt die Schritte einer Ausführungsform der Erfindung dar, um Notierungen aus einem Satz von Messregistern zu erzeugen.
11 stellt den EADD-Prozess zum Aktualisieren des Messregisters MR_EADD in einer Ausführungsform der Erfindung dar.
12 stellt den EREPORT-Befehl dar, der Berichte in einer Ausführungsform der Erfindung erstellt.
13 stellt den Mechanismus für den Wiedergabeschutz dar, der in einer Ausführungsform der Erfindung vorhanden ist.
14 stellt ein Beispiel des Abschnitts der MAC-Baumstruktur des Wiedergabeschutzmechanismus dar, der in einer Ausführungsform der Erfindung vorhanden ist.
15 stellt für eine Ausführungsform der Erfindung dar, wie eine Seiten-Fault-Fehlercodeabbildung implementiert sein kann.
16 stellt ein Beispiel eines Prozesses zum Erstellen einer Genehmigung dar, um eine Enklave in einer Ausführungsform der Erfindung zu starten.
17 stellt für eine Ausführungsform der Erfindung eine mögliche Implementierung der Plattformschlüsselhierarchie für eine sichere Enklave einer einzelnen Baugruppe dar.
18 stellt ein Beispiel einer Mikrocode-basierten Schlüsselhierarchie einer sicheren Enklave in einer Ausführungsform der Erfindung dar.
19 ist ein Diagramm für das CTL_MSR-Enklavenregister, das in einer Ausführungsform der Erfindung vorhanden sein kann.
20 stellt den Chiffrenblockverkettungsalgorithmus dar, der in einer Ausführungsform der Erfindung verwendet wird.
21 ist ein Flussdiagramm, das die Verschlüsselung eines einzelnen AES-Blocks in einer Ausführungsform der Erfindung darstellt.
22 ist ein Flussdiagramm, das ein Beispiel der Verschlüsselung von mehreren AES-Blöcken unter Verwendung des Chiffrenblockverkettungsalgorithmus darstellt, wie es in einer Ausführungsform der Erfindung implementiert ist.
23 stellt in einer Ausführungsform die Anwendungs- und Interrupt-Stacks nach einem Interrupt mit einem Stack-Wechsel dar.
24 stellt eine mögliche Art und Weise dar, einen Stack aus mehreren Slots eines zustandssicheren Bereichs in einer Ausführungsform der Erfindung zu implementieren.
25 stellt in einer Ausführungsform der Erfindung einen Abschnitt der Zustandsmaschinen mit Zustandsübergängen für Interrupts, Faults und Traps dar.
26 stellt für eine Ausführungsform der Erfindung die Prozessorbaugruppe für einen digitalen Zufallszahlengenerator dar.
27 stellt für eine Ausführungsform der Erfindung ein Debug-Register DR7 2700 dar.
Detaillierte Beschreibung
Ausführungsformen der Erfindung beziehen sich auf eine Technik zum Bereitstellen von sicheren Anwendungen und Daten in einer flexiblen, jedoch zuverlässigen Art und Weise. Obwohl mehrere Ausführungsformen mit mehreren Aspekten der Erfindung vorhanden sind, wird hiermit das angehängte Dokument mit dem Titel „Architektur von sicheren Enklaven” als ein Beispiel von mindestens einer Ausführungsform durch Bezugnahme aufgenommen. Jedoch ist die aufgenommene Bezugnahme nicht dazu bestimmt, den Umfang von Ausführungsformen der Erfindung in irgendeiner Art und Weise zu beschränken und andere Ausführungsformen können verwendet werden, die im Geist und Umfang der Erfindung verbleiben.
1 stellt einen Mikroprozessor dar, in dem mindestens eine Ausführungsform der Erfindung verwendet werden kann. Insbesondere stellt 1 einen Mikroprozessor 100 mit einem oder mehreren Prozessorkernen 105 und 110 dar, den jeweils ein lokaler Cache 107 bzw. 113 zugeordnet ist. In 1 ist ebenfalls ein gemeinsamer Cache-Speicher 115 gezeigt, der Versionen von mindestens einigen der Informationen speichern kann, die in jedem der lokalen Caches 107 und 113 gespeichert sind. In einigen Ausführungsformen kann der Mikroprozessor 100 ebenfalls andere Logik aufweisen, die nicht in 1 gezeigt ist, wie zum Beispiel einen integrierten Speicher-Controller, einen integrierten Grafik-Controller, sowie andere Logik, um andere Funktionen innerhalb eines Computersystems durchzuführen, wie zum Beispiel eine I/O-Kontrolle. In einer Ausführungsform kann jeder Mikroprozessor in einem Mehrfachprozessorsystem oder jeder Prozessorkern in einem Mehrfachkernprozessor Logik 119 aufweisen oder ihr anderweitig zugeordnet sein, um Techniken für sichere Enklaven in Übereinstimmung mit mindestens einer Ausführungsform zu ermöglichen. Die Logik kann Schaltkreise, Software (als greifbares Medium verkörpert) oder beides aufweisen, um eine effizientere Ressourcenallokation unter einer Vielzahl von Kernen oder Prozessoren als in einigen Implementierungen des Stands der Technik zu ermöglichen.
2 stellt zum Beispiel ein Front-Side-Bus(FSB)-Computersystem dar, in dem eine Ausführungsform der Erfindung verwendet werden kann. Ein beliebiger Prozessor 201, 205, 210 oder 215 kann auf Informationen aus einem beliebigen lokalen Level-One(L1)-Cache-Speicher 220, 225, 230, 235, 240, 245, 250, 255 innerhalb eines der Prozessorkerne 223, 227, 233, 237, 243, 247, 253, 257, oder der einem anderweitig zugeordnet ist, zugreifen. Des Weiteren kann einer der Prozessoren 201, 205, 210 oder 215 auf Informationen aus einem beliebigen der gemeinsamen Level-Two(L2)-Caches 203, 207, 213, 217 oder aus einem Systemspeicher 260 über einen Chipsatz 265 zugreifen. Einer oder mehrere der Prozessoren in 2 können eine Logik 219 aufweisen oder ihr anderweitig zugeordnet sein, um Techniken für sichere Enklaven in Übereinstimmung mit mindestens einer Ausführungsform zu ermöglichen.
Zusätzlich zu dem in 2 dargestellten FSB-Computersystem können andere Systemkonfigurationen in Verbindung mit verschiedenen Ausführungsformen der Erfindung verwendet werden, welche Systeme mit einer Punkt-zu-Punkt(P2P)-Verbindung und Systeme mit einer Ringverbindung aufweisen. Das P2P-System aus 3 kann zum Beispiel einige Prozessoren aufweisen, von denen nur zwei, Prozessoren 370, 380, beispielhaft gezeigt sind. Die Prozessoren 370, 380 können jeweils einen lokalen Speicher-Controller-Hub (MCH) 372, 382 aufweisen, um mit einem Speicher 32, 34 zu verbinden. Die Prozessoren 370, 380 können Daten über eine Punkt-zu-Punkt(PtP)-Schnittstelle 350 mittels PtP-Schnittstellenschaltungen 378, 388 austauschen. Die Prozessoren 370, 380 können jeweils Daten mit einem Chipsatz 390 über individuelle PtP-Schnittstellen 352, 354 mittels Punkt-zu-Punkt-Schnittstellenschaltungen 376, 394, 386, 398 austauschen. Der Chipsatz 390 kann ebenfalls Daten mit einer Hochleistungsgrafikschaltung 338 über eine Hochleistungsgrafikschnittstelle 339 austauschen. Ausführungsformen der Erfindung können innerhalb eines beliebigen Prozessors mit einer beliebigen Zahl von Prozessorkernen oder innerhalb von jedem der PtP-Busagenten aus 3 angeordnet sein. In einer Ausführungsform kann ein beliebiger Prozessorkern einen lokalen Cache-Speicher (nicht gezeigt) aufweisen oder ihm anderweitig zugeordnet sein. Darüber hinaus kann ein gemeinsamer Cache (nicht gezeigt) in jedem Prozessor außerhalb beider Prozessoren aufgenommen sein, der jedoch mit den Prozessoren über eine p2p-Verbindung verbunden ist, so dass Informationen des lokalen Cache sowohl des einen als auch beider Prozessoren in dem gemeinsamen Cache gespeichert werden können, wenn ein Prozessor in einen Niedrigenergiemodus versetzt wird. Einer oder mehrere der Prozessoren oder Kerne aus 3 können eine Logik 319 aufweisen oder ihr anderweitig zugeordnet sein, um Techniken für sichere Enklaven in Übereinstimmung mit mindestens einer Ausführungsform zu ermöglichen.
Ein oder mehrere Aspekte von mindestens einer Ausführungsform können durch repräsentative Daten implementiert sein, die auf einem maschinenlesbaren Medium gespeichert sind, das verschiedene Logiken innerhalb des Prozessors repräsentiert, die, wenn sie von einer Maschine gelesen werden, die Maschine dazu zu veranlassen, Logik herzustellen, um die hier beschriebenen Techniken durchzuführen. Solche Repräsentationen, die als „IP-Kerne” bekannt sind, können auf einem greifbaren, maschinen-lesbaren Medium („Band”) gespeichert sein und an verschiedene Kunden oder Fertigungseinrichtungen geliefert werden, um in die Herstellungsmaschinen zu laden, die die Logik oder den Prozessor tatsächlich machen.
Somit wurden ein Verfahren und eine Vorrichtung zum Leiten von Zugriffen auf mikroarchitektonische Speicherregionen beschrieben. Es sollte verständlich sein, dass die obige Beschreibung dazu bestimmt ist, darstellend und keinesfalls restriktiv zu sein. Zahlreiche andere Ausführungsformen werden für den Fachmann, der die obige Beschreibung liest und versteht, ersichtlich sein. Der Umfang der Erfindung kann deshalb mit Bezug auf die angehängten Ansprüche zusammen mit dem vollen Umfang von Äquivalenten, zu denen die Ansprüche berechtigen, bestimmt werden.

Sichere Enklaven sind ein Satz von Befehlen, der einen sicheren Ort für eine Anwendung bereitstellt, um im Kontext eines BS-Prozesses Code auszuführen und Daten drinnen zu speichern. Eine Anwendung, die in dieser Umgebung ausführt, wird eine Enklave genannt. Enklaven werden aus dem Enklavenseiten-Cache (Enclave Page Cache, EPC) ausgeführt. Die Enklavenseiten werden in den EPC durch ein BS geladen. Sobald eine Seite einer Enklave aus dem EPC entfernt wird, werden kryptographische Schutzmaßnahmen verwendet, um die Vertraulichkeit der Enklave zu schützen und um eine Verfälschung zu detektieren, wenn die Enklave in den EPC zurückgeladen wird. Innerhalb des EPC werden Enklavendaten mittels Zugriffskontrollmechanismen geschützt, die durch den Prozessor bereitgestellt werden. Die untere Tabelle 2-1 stellt eine komplette Liste der nicht-privilegierten Enklavenbefehle bereit. Tabelle 2-1: Liste von nicht-privilegierten Befehlen

Kategorie	Operationen	Beschreibung
Anwendungsunterstützung	EENTER, EEXIT, EACCEPT, ERDTCSPTR, EIRET	Wird verwendet, um in die Enklave einzutreten oder sie zu verlassen, Speicherverwaltungsanfragen zu akzeptieren und Thread-spezifische Informationen bereitzustellen
Versorgung	EREPORT, EGETKEY, EMKPERMIT, ERDMR	Wird verwendet, um Belege über eine Enklave bereitzustellen. Dieser Beleg/diese Belege kann/können verwendet werden, um einem Dritten gegenüber aufzuzeigen, dass eine Enklave auf einem Intel-Prozessor läuft, und die initialen Enklaveninhalte.

Diese Befehle werden nur im Ring 3 ausführen. In allen anderen Fällen werden sie einen #UD-Fault generieren. Tabelle 2-2 stellt die Liste von privilegierten Befehlen bereit. Tabelle 2-2: Liste von privilegierten Befehlen

Kategorie	Operationen	Beschreibung
Enklavenkonstruktion	ECREATE, EADDPRE, EADDPOST, EINIT	Wird verwendet, um die Enklave aufzubauen und zu aktivieren.
Anwendungsunterstützung	EMODIFY, EREMOVE	Wird verwendet, um Enklavenseitenattribute dynamisch zu manipulieren.
Hardware-Verwaltung	ELPT, EWBINVPG, EADDSMAP, EUPSMAP	Wird verwendet, um den Enklavenseiten-Cache zu verwalten
Debugging	EDBGRD, EDBGWR	Wird verwendet, um die Inhalte einer Debug-Enklave zu lesen und zu schreiben.
Virtualisierungsunterstützung	ERDINFO	Wird verwendet, um Informationen über EPC-Einträge zu lesen.

Ein Enklavenseiten-Cache ist dort, wo Enklaven-Code ausgeführt und auf geschützte Enklavendaten zugegriffen wird. Der EPC ist innerhalb des physikalischen Adressraums einer Plattform angeordnet, auf ihn kann jedoch nur unter Verwendung von SE-Befehlen zugegriffen werden. Der EPC kann Seiten aus vielen unterschiedlichen Enklaven enthalten und stellt einen Zugriffskontrollmechanismus bereit, um die Integrität und Vertraulichkeit der Seiten zu schützen. Der Seiten-Cache hält ein Kohärenzprotokoll ein, das demjenigen ähnlich ist, das für einen kohärenten physikalischen Speicher in der Plattform verwendet wird.
Der EPC kann auf unterschiedliche Art und Weise instanziiert werden. Er kann aus dediziertem SRAM in der Prozessorbaugruppe aufgebaut sein. Der bevorzugte Implementierungsmechanismus ist als Kryptospeicherapertur (Crypto Memory Aperture) bekannt. Dieser Mechanismus erlaubt es dem EPC groß zu sein. Weitere Details der CMA sind in den unteren Abschnitten.
Die Enklavenseiten-Cache-Abbildung oder -Abbild (Enklave Page Cache Map, EPCM) umfasst die Zustandsinformationen, die jeder Seite im EPC zugeordnet sind. Dieser Zustand stellt die Informationen bereit, wie zum Beispiel die Enklave, zu der die Seite gehört, den Zustand einer geladenen Seite usw. Wenn eine Seite aus dem EPC entfernt wird, werden die Zustandsinformationen ebenfalls exportiert und unter Verwendung von kryptographischen Mitteln geschützt. Wenn eine Enklavenseite in den EPC wieder geladen wird, werden die Zustandsinformationen verifiziert.
4 stellt ein Blockdiagramm eines Mehrfachkern-Mikroprozessors 499 dar, in dem mindestens eine Ausführungsform der Erfindung verwendet werden kann. Der Mikroprozessor 499 kann mehrere Kerne 400, 420 umfassen. Ein Kern 400 umfasst einen CR3 402, SMBR 404, einen Page-Miss-Handler 408, PMHE 410 und einen Übersetzungsseitenpuffer 412. Ein Kern 420 umfasst einen CR3 422, SMBR 424, einen Page-Miss-Handler 428, PMHE 430 und einen Übersetzungsseitenpuffer 432. Der Mikroprozessor 499 umfasst in einigen Ausführungsformen der Erfindung einen Level-1-Cache 440, den sich der Kern 400 und der Kern 420 teilen. Der Level-1-Cache 440 kann Daten in den und aus dem Cache 445 der letzten Ebene (Last-Level-Cache) transferieren. Der Heimagent 450 kann sich mit dem Cache 445 der letzten Ebene verbinden und sich an die Krypto-Engine 452 anschließen. Der Heimagent 450 kann den physikalischen Adressraum 488 der Kryptospeicherapertur 480 durch den Speicher-Controller 454 bewerten. Die Kryptospeicherapertur 480 umfasst einen Enklavenseiten-Cache 482, eine Enklavenseiten-Cache-Abbildung 484, einen Hilfsspeicher 486, als Teil des physikalischen Adressraums 488.
Die CMA ist ein Mechanismus, der Unterstützung für eine Instanziierung des EPC, der EPCM und anderer SE-bezogener Strukturen liefert. Die Apertur ist ein Bereich des physikalischen Adressraums, der für diese Verwendung reserviert ist.
Der EPC und die EPCM (sowie andere Datenstrukturen der Implementierung) werden auf eine Stelle innerhalb der Apertur abgebildet. Der Hilfsspeicher stellt die tatsächlichen Daten für diese Ressourcen dar. Wenn eine Speicheranforderung für den EPC generiert wird, bildet die CMA auf die Hilfsspeicherstelle neu ab, die die verschlüsselten EPC-Daten enthält, und ruft die Daten ab.
Im Allgemeinen, ist der größte Teil der SE als Mikrocode oder erweiterter Mikrocode implementiert. Es wird eine Hardware-Unterstützung an mehreren Stellen benötigt, aufweisend CMA, Logik, die eine Datenverschiebung außerhalb der Baugruppe steuert, und in den Kernen.
5 stellt eine mögliche Implementierung einer sicheren Enklave in einer Ausführungsform der Erfindung dar. Das Betriebssystem und der VMM 542 können den ELPG-Befehl 540 verwenden, um eine Enklavenseite in der Enklave 532 in einen Enklavenseiten-Cache 544 zu laden. Wenn der Mikroprozessor nicht innerhalb einer Enklave 532 ausführt, wird der Enklavenseiten-Cache 544 vor dem Software-Zugriff durch das SERR-Register 548 geschützt. Beim Ausführen innerhalb der Enklave, liefern die Mikrocode-Seitentabellen einen Schutz 546. Jede VM hat eine zugeordnete VMCS. Eine VM 510 ist mit einer VMCS 515 verbunden. Eine VM 520 ist mit einer VMCS 525 verbunden. Eine VM 530 ist mit einer VMCS 535 verbunden. Der SMM 500 kann in einem separaten Container sein und die Prozessorzustände können in einem separaten Container sein.
5 ist die Übersicht einer Ausführungsform einer Implementierung einer sicheren Enklave auf hoher Ebene. In dieser Implementierung wird der EPC als ein separater Container gehalten, der durch den Mikrocode verwaltet wird. Auf den Container kann nicht zugegriffen werden, wenn sich die Ausführung nicht innerhalb der Enklave befindet. Wenn in die Enklave eingestiegen wird, wird die Kontrolle auf den Enklaven-Code innerhalb des EPC übertragen, der in einem separaten Container enthalten ist.
Beliebige Seiten-Faults oder Ausnahmen, die während einer Ausführung innerhalb der Enklave auftreten, werden von dem Mikrocode auf das verantwortliche BS oder den VMM reflektiert. Wenn die Maschine nicht innerhalb einer Enklave ausführt, wird die Zugriffskontrolle für den EPC durch das SE-Bereichsregister (SE Range Register, SERR) gebildet. Wenn die Maschine drinnen abläuft, stellt der Mikrocode Schutzmaßnahmen auf Seitentabellenebene bereit, die einen Zugriff auf andere EPC-Einträge verhindern, die nicht zu der ausführenden Enklave gehören.
Eine Möglichkeit, sichere Enklaven zu implementieren, besteht darin, die Befehle und die Schutzmaßnahmen unter Verwendung der Mikrocode-Leistungsfähigkeit einiger Prozessoren zu implementieren. Diese Leistungsfähigkeit kann die Sicherheitsanforderungen erfüllen, die sichere Enklaven benötigen, um ihre Ziele zu erreichen.
Das SERR-Register, wie es in 2-2 gezeigt ist, ist in dem Page-Miss-Handler PMH implementiert. Das Register kann unabhängig für jeden logischen Prozessor aktiviert und deaktiviert werden.
Eine Möglichkeit der Implementierung zur Verbesserung der Leistung besteht darin, ein Bit oder einige wenige Bits bereitzustellen, um anzuzeigen, dass Einträge in dem Übersetzungspuffer (Translation Lookaside Buffer, TLB) für eine Enklave oder eine bestimmte Enklave bestimmt sind. Falls diese Bits nicht bereitgestellt werden, wird ein TLB-Flush benötigt werden, wenn aus der Enklave ausgestiegen wird, um anderen Code daran zu hindern, auf die Enklave zuzugreifen.
Das Enklavenbit wird mit dem Enklavenmodusbit verglichen. Zusätzliche Bits würden eine Enklavenraum-ID-Funktionalität bereitstellen. Einer bestimmten Enklave würde eine ID zugeordnet. Die ID würde mit der ID der ausführenden Enklave als Teil der Adressprüfung verglichen. Die TLB-Unterstützung ist eine optionale Leistungsverbesserung. Wenn ein Eintrag in dem TLB aufgrund des Entfernens von EPC-Daten für ungültig erklärt werden kann, wird ein spezieller Mikrocode-Shootdown-Mechanismus benötigt. In einer Ausführungsform kann der Mikrocode alle anderen Kerne innerhalb der Vertrauensgrenze der Enklave kontaktieren und verifizieren, dass sich der Eintrag nicht mehr in irgendeinem TLB befindet. Andere Ausführungsformen können Mittel für Mikrocode bereitstellen, um sicher zu sein, dass andere Prozessoren die TLB-Einträge für ungültig erklärt haben.
Um DMA-Snoops und Ungültig-Erklärungen des EPC zu verhindern, wird ein spezieller SAD- und/oder TAD-Eintrag bereitgestellt. Diese dedizierten Register liefern den Schutz für den EPC. Dies wird auf dieselben Werte wie das SERR gesetzt.
Um sichere Schlüssel für jede Enklave zu garantieren, kann in einer Ausführungsform ein Mikrocode für sichere Enklaven einen sicheren Zugriff auf Zufallszahlen verwenden.
Eine Enklave kann gegen Verfälschung geschützt werden. Die Details des für den Verfälschungsschutz verwendeten Mechanismus variieren je nach Implementierung. Wenn eine Enklave verfälscht wird, wird dies eine weitere Ausführung auf dem Thread verhindern, der die Verfälschung detektiert hat. Damit Benutzer den Zustand einer Enklave verstehen, ist ein Beglaubigungsmechanismus aufgestellt worden, um einen Nachweis des Enklavenaufbaus zu liefern. Dies umfasst den EREPORT-Befehl, der verwendet wird, um Informationen über die Enlklaveninhalte zu präsentieren.
Um den Mikrocode-Code zu vereinfachen, der bei dem Enklavendesign benötigt wird, wurde das Konzept von architektonischen Enklaven entwickelt. Diesen Enklaven werden Sonderzugriffsprivilegien basierend auf dem Original des Codes für die Enklave verliehen.
Der Enklavenzustand über Energiezyklen hinweg ist von Softwarerichtlinien abhängig. Daten innerhalb der CMA sind beim Herunterfahren verloren. Die Software kann sicherstellen, dass die Enklavendaten bei einem Energiezyklus nicht verloren gehen, wenn sie die Enklave beibehalten mag. Daten, die sich in dem EPC befinden, können in einen Speicher geflusht werden, wenn die Software wünscht, dass Enklaven über S3-Ehergiezustände hinweg aufrecht erhalten werden. Die Software kann wahlweise verlangen, dass diese Anwendungen alle Enklaven abreißen, wenn Energie abgezogen wird.
Eine Enklave wird in Abhängigkeit von ihrem Ort unterschiedlich geschützt. Daten, die sich außerhalb der CPU-Baugruppe befinden, werden mittels einer Verschlüsselungs- und Integritätsprüfung geschützt. Für Code und Daten in dem Enklavenseiten-Cache werden Seiten mittels Zugriffskontrollmechanismen geschützt.
6 stellt ein Blockdiagramm eines Mikroprozessors dar, in dem mindestens eine Ausführungsform der Erfindung verwendet werden kann. 6 stellt einen Mikroprozessor 600 mit mehreren Prozessorkernen 600, 605, 610, 615 und einen Cache 620 dar. Die Enklavendaten 635 können verschlüsselt sein. Die Kryptospeicheraperturdaten 630 werden verwendet, um die Enklavendaten 635 zu schützen.
Enklavenseiten, die sich in einem Systemspeicher befinden, werden mittels Verschlüsselung und Integrität geschützt. Während des Ladens der Seite in den EPC wird die Seite in den EPC kopiert, entschlüsselt und die Integrität der Seite wird geprüft. 6 zeigt diesen Abschnitt der Daten.
Wenn eine Enklavenseite, die sich innerhalb des EPC befindet, in den Systemspeicher gespeichert wird, wird sie mit dem Enklavenschlüssel verschlüsselt. Authentifikationsinformationen werden ebenfalls zum Zeitpunkt des Seitenspeichervorgangs gespeichert. Enklavendaten innerhalb des EPC sind unverschlüsselt und werden durch Zugriffskontrollmechanismen geschützt. Der Prozessor schützt diese Daten, so dass nur die Enklave, die diese Daten besitzt, auf sie zugreifen kann.
Wenn Enklavenseiten, die sich in dem EPC befinden, aus dem Cache in den Hauptspeicher außerhalb der CPU-Baugruppe geräumt werden, werden sie durch eine CMA-Verschlüsselung geschützt. Die CMA wird die Daten verschlüsseln, um Datenvertraulichkeit bereitzustellen. Die Integrität des EPC wird durch Bereichsregister gebildet, die Lese- und Schreibvorgänge auf dem EPC verhindern.
7 stellt ein Beispiel einer Kontrollstruktur zum Zugreifen auf einen Abschnitt des Enklavenseiten-Cache dar, die in einer Ausführungsform der Erfindung implementiert sein kann. Jede Seite des Enklavenseiten-Cache 720 kann entsprechende Metadaten in der Enklavenseiten-Cache-Abbildung 710 haben. Die Metadaten sind in 7 gezeigt. Eine sichere Enklave, die einen Satz von linearen Adressen 700 umfasst, kann auf Daten, die in dem Enklavenseiten-Cache 720 gespeichert sind, zugreifen, wenn die lineare Adresse mit der linearen Adresse, die in der Enklavenseiten-Cache-Abbildung 710 gespeichert ist, übereinstimmt.
7 zeigt das Layout und die Verwendung des EPC und der EPCM. Der EPC ist in 4k-Seiten aufgeteilt. Jede Enklave kann eine gewisse Anzahl von Seiten haben, die sich in dem EPC befinden. Für jede Seite des EPC, die Metainformationen bereitstellt, die zum Sicherstellen der Sicherheit benötigt werden, gibt es einen Eintrag in der EPCM. Die Details der EPCM sind von der Implementierung abhängig.
Wenn eine Anwendung eine Enklave zu laden wünscht, wird sie eine Systemroutine in dem BS aufrufen. Das BS wird versuchen, einige Seiten im EPC zu allozieren. Falls es keine offene Stelle gibt, wird das BS eine Opferenklave zum Entfernen auswählen. Das BS wird die Seiten der Opferenklave mittels des EWBINVPG-Befehls für jede Seite ausräumen. Wenn das BS das Ausräumen abgeschlossen hat, wird es die Kontrollstruktur für sichere Enklaven (Secure Enclaves Control Structure, SECS) mittels des ECREATE-Kommandos zu der Enklave hinzufügen. Nachdem die SECS erzeugt ist, wird das BS mittels des EADDPRE-Befehls Seiten zu der Enklave hinzufügen, wie es durch die Anwendung angefordert ist.
Um Datenseiten zu der Enklave hinzuzufügen, kann das BS zuerst SMAP-Seiten mittels des EADDSMAP-Befehls zu der Enklave hinzufügen. Abhängig von der Größe und des Layouts der Enklave, wird das BS mehrere SMAP-Seiten hinzufügen. Wenn alle Enklavenseiten zu der Enklave hinzugefügt sind, wird das BS den EIHIT-Befehl ausführen, um das Ausführen der Enklave zu ermöglichen. Ein Parameter des EINIT-Befehls ist eine Genehmigung, die demonstriert, dass die Enklave dafür lizenziert ist, auf dieser Maschine zu laufen. Wenn eine Anwendung geladen ist, muss eine Genehmigung erzeugt werden. Nach einem erfolgreichen Abschluss von EINIT kann die Anwendung den EENTER-Befehl ausführen, um in die Enklave einzusteigen.
Wenn eine Enklave aufgebaut und zur Ausführung markiert ist, kann die Anwendung erfordern, dass physikalischer Speicher innerhalb der Enklave hinzugefügt oder abgezogen wird. Um dies zu unterstützen, gibt es Befehle, die es erlauben, dass zusätzlicher Speicher zu der Enklave hinzugefügt wird. Um Speicher zu der Enklave hinzuzufügen, wird der Speicher an der richtigen linearen Adresse innerhalb der Enklave alloziert. Das BS kopiert diese Speicherseite in den EPC, die lineare Adresse angebend. Der EADDPOST-Befehl wird ausgeführt, um diesen Speicher zu der Enklaven-Enklave hinzuzufügen. Wenn sich der SMAP-Knoten nicht innerhalb des EPC befindet, kann er zuerst geladen werden.
Nachdem der Speicher kopiert ist, kann die Enklaven-Software die Seite akzeptieren, bevor darin auf sie zugegriffen werden kann. Die Enklave akzeptiert die Daten durch Ausführen des EACCEPT-Befehls. Dieser Befehl kann nur von der Software innerhalb der Enklave ausgeführt werden.
In einigen Fällen möchte die Software vielleicht die Eigenschaften des Enklavenspeichers modifizieren. Um die Änderung durchzuführen, kann die SMAP aktualisiert werden. Die Software möchte zum Beispiel einen anderen Thread-Einsprungspunkt, TCS innerhalb der Enklave erzeugen. In diesem Fall fordert die Enklave an, dass das BS die SMAP-Eigenschaften der Seite mittels des EMODIFY-Befehls ändert. Nachdem die Eigenschaften geändert sind, führt die Enklaven-Software den EACCEPT-Befehl aus, um zu erlauben, dass die Seite verwendet wird.
Speicherseiten können aus der Enklave entfernt werden. Wenn die Enklave dazu bereit ist, eine Seite zu entfernen, sendet sie eine Anforderung and das BS. Das BS wird den EREMOVE-Befehl ausführen, der die Seite aus der SMAP entfernen wird. Der EREMOVE-Befehl erklärt den EPC-Eintrag ebenfalls für ungültig.
Um die Integrität der Enklavenumgebung sicherzustellen, kann eine Anzahl von Zugriffsprüfungen gemacht werden. Zu den verschiedenen durchgesetzten Sicherheitseigenschaften gehört auch, dass Daten im EPC richtig angeordnet sind, um zu verhindern, dass Daten über Enklaven hinweg durchsickern, und die referenzierende Adresse nicht beschädigt ist, um sicherzustellen, dass Code nicht zu einer anderen linearen Adresse in der Enklave verschoben wird.
Die Zugriffsschutzanforderungen können mittels eines Bereichsregisters und Mikrocodeverwalteten Schattenseitentabellen implementiert werden. Um den Overhead von Schattenseitentabellen zu vermeiden, kann in einer anderen Ausführungsform die Page-Miss-Handler-Hardware modifiziert werden, um dieselben Zugriffskontrollanforderungen durchzuführen.
Der logische Prozessor (LP) kann nur auf den EPC zugreifen, wenn der LP entweder in einem Mikrocode-Erweiterungsmodus ausführt oder wenn der LP innerhalb einer Enklave ausführt und die lineare Adresse, auf die zugegriffen wird, zu dem linearen Adressbereich gehört, der von dieser Enklave abgedeckt ist. Anders gesagt, ist es nur Mikrocode-Erweitungszugriffen oder Enklavenzugriffen erlaubt, in den EPC-Bereich zu gehen. Andere Zugriffe auf den EPC-Bereich werden als illegal betrachtet.
Ein Enklavenzugriff kann in eine physikalische Adresse aufgelöst werden, die dem EPC gehört. Wenn der Zugriff außerhalb des EPC fällt, die lineare Adresse jedoch anzeigt, dass die Adresse innerhalb der Enklave ist, kann der Zugriff gestoppt werden. Ein Fault an das BS oder der Befehl wird berichtet.
Der Zugriff auf eine Adresse in der Enklave kann innerhalb des EPC angeordnet sein, damit der Zugriff erfolgreich ist. Die Prüfung, dass der Eintrag in dem EPC präsent ist, wird gewöhnlicherweise durch Prüfen der EPCM gemacht, um das Gültigkeitsbit zu verifizieren. Jede EPC-Seite ist für eine bestimmte Enklave bestimmt. Referenzen auf diesen EPC-Eintrag können nur von der Enklave gemacht werden, die die EPC-Seite besitzt. Dies wird durch ein Validieren geprüft, dass die referenzierte Seite mit der SECS der ausführenden Enklave übereinstimmt.
Jede EPC-Seite repräsentiert eine bestimmte Seite einer linearen Adresse für die Enklave. Die angeforderte lineare Adresse kann mit der linearen Adresse der Seite in dem EPC übereinstimmen. Beispielsweise kann der EPCM-Eintrag die lineare Adresse speichern, für die eine Enklavenseite in den EPC gebracht wurde. Wenn ein Enklavenzugriff auf eine EPC-Seite auflöst, kann die lineare Adresse, für die die Seite reingebracht wurde, mit der linearen Adresse der aktuellen Anforderungen übereinstimmen.
Die Abbildung von linearen Adressen einer Enklave kann nicht beschädigt werden. Wenn die Seitentabellen der linearen Adresse beschädigt sind, ist der resultierende Zugriff illegal. Dies hindert einen Angreifer daran, Code und Daten innerhalb der Enklave herum zu verschieben.
Wenn das BS/der VMM eine Seite zu einer Enklave hinzufügt, nachdem sie initialisiert worden ist, setzt der EADDPOST-Befehl das „pending”-Bit in der EPCM für diese Seite. Das Pending-Bit übersteht nachfolgende EPC-Rückschreibvorgänge und -Ausräumungen (unter Verwendung von SEC_INFO). Die Enklave kann EACCEPT ausgeben, um das Pending-Bit zu löschen. Wenn ein Enklavenzugriff auf eine EPC-Seite auflöst, für die das Pending-Bit gesetzt ist, gibt der LP einen EF_PENDING-Fault an das BS/den VMM aus.
Wenn das BS/der VMM eine wiedergabegeschützte Enklavenseite in den EPC lädt, setzt es das FCR-Bit (Freshness Check Required) in dem EPCM-Eintrag für diese Seite. Das BS/der VMM kann dieses Bit durch Ausführen eines EUPSMAP-Befehls auf dieser EPC-Seite löschen, um dieses Bit zu löschen. Einem Enklavenzugriff wird es nur dann erlaubt, weiterzuarbeiten, wenn das FCR-Bit auf dieser Seite nicht gesetzt ist. Ansonsten liefert der LP einen EF_FRESH_CHK-Fault an das BS/den VMM.
Jeder EPCM-Eintrag umfasst ein „dirty”-Bit, das angibt, ob es einer Enklave erlaubt ist, auf diese Seite zu schreiben. Einer Enklave ist es nur dann erlaubt, auf eine Enklavenseite zu schreiben, wenn das Dirty-Bit für diese Seite in der EPCM gesetzt ist. Wenn dies nicht der Fall ist, gibt der LP ein EF_EWRITE an das BS/den VMM aus. Das BS/der VMM kann das Dirty-Bit durch Ausführen des EUPSMAP-Befehls auf dieser Seite setzen.
Jedes Mal, wenn ein logischer Prozessor innerhalb einer Enklave ausführt, können die SECS-Seiten dieser Enklave in dem EPC präsent sein. Jedoch erfordert das SE-Sicherheitsmodell, dass es einer Enklave nicht erlaubt sein muss, irgendwelche direkten Speicherzugriffe auf ihre eigene SECS zu machen (andernfalls wäre die Enklave in der Lage, ihren eigenen Enklavenschlüssel zu lesen, was gänzlich die Sicherheit kompromittieren würde). Wenn ein Enklavenzugriff auf eine EPC-Seite auflöst, die die SECS für diese Enklave hält, wird das BS/der VMM über einen EF_ATTRIB_SECS-Fault benachrichtigt. Einer Enklave ist es nicht erlaubt, irgendwelche Seiten zu modifizieren, die ein TCS-Attribut gesetzt haben. Wenn eine Enklave versucht, eine TCS zu modifizieren, die in den EPC geladen ist, wird das BS/der VMM über einen EF_ATTRIB_TCS-Fault benachrichtigt.
In dem Größe-Feld der unteren Tabellen werden die folgenden Werte und Indikatoren verwendet:

4 4-Byte-Feld sowohl im 32- als auch im 64-Bit-Modus

8 8-Byte-Feld sowohl im 32- als auch im 64-Bit-Modus

8(4) 8-Byte-Feld in beiden Modi. Die oberen 4 Bytes werden im 32-Bit-Modus ignoriert.
Beachte: Einige Felder besitzen Namen, die mit einem kleingeschriebenen „o” beginnen (zum Beispiel oLSP). Diese Felder sind Zeiger, werden jedoch in der Enklave als Offsets relativ zu der Basis der Enklave repräsentiert. Diese Repräsentation stellt sicher, dass die Abmessung von Enklavenseiten unabhängig von der Stelle ist, an der die Enklave erzeugt wird.

Beachte: Die Felder sind (bisher) nicht in irgendeiner bestimmten Reihenfolge beschrieben. Einige Felder können in andere Speicherseiten innerhalb ihrer entsprechenden Datenstrukturen verschoben werden, um zum Beispiel andere Schutzmittel zu erlauben. Tabelle 4-1: Inhalte einer Kontrollstruktur für sichere Enklaven

Name des Offsets	Größe (Bytes)	Kurzbeschreibung	Wie initialisiert
SIZE	8	Größe der Enklave	Software
BaseAddr	8	Lineare Adresse der Enklavenbasis	Software
Mask	8	Enklavenmaske, welche den Enklavenbereich bestimmt	Mikrocode
FLAGS	8	Boolean, gibt an, dass EINIT ausgeführt wurde Enc Code Present, Enc Data Present, Pre-production	Software (DebugFlag) und Mikro-code
MR_EADD	32	Messregister erweitert um EADDs aus pre-EINIT	Mikrocode
MR_POLICY	32	Messregister erweitert mit dem öffentlichen Schlüssel, der die Berechtigungsnachweise signiert hat, die verwendet werden, um die Genehmigung der Enklave zu generieren, falls eine verwendet wurde.	Mikrocode
MR_RESERVE1	32	Reserviertes Messregister	Mikrocode
MR_RESERVE2	32	Reserviertes Messregister	Mikrocode
ENCLAVE_KEY	16	Schlüssel der Enklave	Mikrocode
Reserviert	16	MBZ
ISV_SEC_VERSION	4	Sicherheitsversion der Enklave	Mikrocode
PERMIT_SECVERSION	4	Sicherheitsversion des Genehmigungserzeugers	Mikrocode
Reserviert	1824	MBZ
VERSION	128·16

Jedem Thread ist eine Thread-Kontrollstruktur (Thread Control Structure, TCS) zugeordnet.

Die TCS umfasst: Tabelle 4-2: TCS-Layout

Thread Control Structure
Name des Offsets	Größe (Bytes)	Kurzbeschreibung	Wie Initialisiert
STATE	4	Gibt den aktuellen Zustand des Threads an	Software initialisiert auf inaktiv.
oSSA	8	Offset der State Save Area, Offset relativ zu der Enklavenbasis. Zeiger auf Stack mit sicherem Zustand.	Software stellt sicher, dass Speicherbereich alloziert, bestätigt und EADDt ist. Software initialisiert INT-Offset auf Null.
NSSA	4	Anzahl von SSA-Slots	Software initialisiert.
CSSA	4	Aktueller SSA-Slot	Software setzt auf Null.
IRR	8(4)	Interrupt-Rücksprungroutine	Software initialisiert auf Trampoline in uRTS. Dieses Feld wird nicht gemessen, wenn die TCS EADDPREt wird
oEntry	8	Offset in der Enklave, auf den die Kontrolle beim EENTER übertragen wird, wenn die Enklave im INACTIVE-Zustand	Software
oHandler	8	Offset in Enklave, auf den die Kontrolle übertragen wird, wenn die Enklave im EXCEPTED-Zustand ist.	Software
SAVE_DR7	8	Stelle, in welche h/w DR7 beim EENTER gesichert wird, wenn die Enklave NICHT im Debug-Modus ist, und beim Aussteigen aus der Enklave (EEXIT oder Interrupt) wieder geladen wird.	Software setzt auf Null
SAVE_DEBUGCTL	4	Stelle in welche h/w IA32_DEBUGCTL MSR beim EENTER gesichert wird, wenn die Enklave NICHT im Debug-Modus ist, und beim Aussteigen aus der Enklave (EEXIT oder Interrupt) wieder geladen wird.	Software setzt auf Null
TF	1	Trap-Flag-Wert, der in RFLAGS.TF beim EENTER geladen wird.	Software setzt auf Null
SAVE_TF	1	Stelle, in welche RFLAGS.TF beim EENTER gesichert wird und aus der es beim EEXIT wiederhergestellt wird.	Software setzt auf Null.

Der Thread-Zustand kann einen der folgenden fünf Werte annehmen:

Zustand	Bedeutung
INACTIVE	Die TCS ist für ein normales EENTER verfügbar
ACTIVE	Ein Prozessor führt aktuell im Kontext dieser TCS aus.
INTERRUPTED	Ein Interrupt (Vektor >= 32) ist aufgetreten, während ein Prozessor im Kontext dieser TCS ausführte. Der Ausführungszustand wurde auf einen SSA-Rahmen gepusht und aus der Enklave wurde ausgestiegen. Nichts führt im Kontext dieser TCS aus. EENTER/RETURN_FROM_INTERRUPT wird den Thread an der unterbrochenen Stelle wiederaufnehmen. EENTER/NORMAL ist illegal.
HANDLING	Der TCS::Handler (Ausnahmen-Handler-Einstieg) wurde
	geEENTERt im Kontext dieser TCS.
HANDLED	Der TCS::Handler hat geEEXITet und in die TCS kann nur unter
	Verwendung von EENTER/RETURN_FROM_INTERRUPT
	wiedereingestiegen werden.

State Save Area-Offset (oSSA)
Der State Save Area-Offset (oSSA) zeigt auf einen Stack von zustandssicheren Rahmen, die verwendet werden, um den Prozessorzustand bei einem Interrupt oder einer Ausnahme zu sichern, die während des Ausführens in der Enklave auftritt. Next State Save Area (NSSA) wird von dem Interrupt-Mikrocode verwendet, um zu bestimmen, wo der Prozessorzustand bei einem Interrupt oder einer Ausnahme zu sichern ist, die während des Ausführens in der Enklave auftritt. Es ist ein Index in das Array von Rahmen, die durch oSSA adressiert sind. Count of Save Areas (CSSA) spezifiziert die Anzahl von SSA-Rahmen, die dieser TCS zur Verfügung stehen. Wenn ein Interrupt oder eine Ausnahme auftritt und keine weiteren SSA-Rahmen verfügbar sind (NSSA >= CSSA), wird der Interrupt oder die Ausnahme trotzdem auftreten und der Prozessorzustand wird gelöscht, jedoch wird die TCS als UNGÜLTIG markiert.

Bei einem Interrupt, der während des Ablaufens in einer Enklave auftritt, wird der Maschinenzustand in das TCS::SSA (zustandssicherer Bereich, State Save Area) gesichert. Dieser Bereich weist auf: Figur4–3: Interrupt-sicherer Bereich

State Save Area
Name	Beschreibung
STATE	Wert von TCS::STATE direkt vor Interrupt
RFLAGS	Flag-Register
RAX...R15	16 allgemeine Register
RIP	Befehlszeiger (Instruction Pointer)
XSAVE	XSAVE-kompatible X87 FPU, MMX, SSE, SSE2, erweiterbarer Bereich

Der TCS::SSA darf nicht zu dem Zeitpunkt, an dem ein Interrupt auftritt, aus der Seite ausgelagert werden (paged out). EENTER prüft, dass der SSA innerhalb des EPC ist und cacht die physikalische Adresse. In dem Fall, dass die Seite geräumt ist, wird der Prozessor, der den EWBINVPG ausführt, ein Verlassen der Enklave auf dem Prozessor, der den Thread aktuell ausführt, mittels des SSA erzwingen und einen Seiten-Fault daran berichten.
8 zeigt, wie alle diese Datenstrukturen zusammengeheftet sind. Um ein Durcheinander zu vermeiden, werden nicht alle Strukturen pro Thread für alle Threads gezeigt. Die nicht vertrauenswürdigen Stacks (Untrusted Stacks) und ihre zugeordneten Zeiger sind ebenfalls ausgelassen. 8 stellt ein Beispiel einer Thread-Kontrollstruktur in einer Ausführungsform der Erfindung dar, die zeigt, wie die sicheren Zustandsbereiche zusammengeheftet sind. Der Zeiger 800 eines zustandssicheren Bereichs zeigt auf einen sicheren Bereich 0 820. Der aktuelle zustandssichere Bereich 805 zeigt auf einen sicheren Bereich 1 824. Der nächste zustandssichere Bereich 810 zeigt auf den nächsten sicheren Bereich 828. Die Anzahl von sicheren Zustandsbereichen stellt eine Referenz auf die Anzahl von verfügbaren sicheren Zustandsbereichen dar.

Page Information (PAGE_INFO) ist eine architektonische Datenstruktur, die als Parameter für die EPC-Verwaltungsbefehle verwendet wird. Tabelle 4-3: PAGE_INFO-Struktur

Page Information
Name des Offsets	Größe (Bytes)	Kurzbeschreibung
LIN_ADDR	8	Lineare Adresse einer Enklave
SOURCE_PAGE	8	Lineare Adresse der Seite, in der sich Seiteninhalte befinden
SEC_INFO	8	Lineare Adresse der secinfo-Struktur für die Seite
SECS	8	Lineare Adresse eines EPC-Slots, der aktuell eine Kopie der SECS enthält

Die SEC_INFO-Flags und die EPC-Flags umfassen Bits, die den Typ einer Seite angeben. PAGE_TYPE-Flags

Name des Flags	Wert	Kurzbeschreibung
PT_SECS	0	Seite ist eine SECS
PT_SMAP_LEVEL1	1	Seite ist ein SMAP-Level 1
PT_SMAP_LEVEL2	2	Seite ist ein SMAP-Level 2
PT_SMAP_LEVEL3	3	Seite ist ein SMAP-Level 3
PT_TCS	4	Seite ist eine TCS
PT_REG	8	Seite ist eine normale Seite
	Alle anderen	Reserviert

Die SEC_INFO-Flags sind ein Satz von Bits, die den Zustand einer Enklavenseite beschreiben. Tabelle 4-4: SEC_INFO-Flags

Bit-Pos.	Inhalt
0	WIEDERGABESCHUTZ	RP: Wiedergabeschutz (Replay Protection). Ein Bitwert von 1 gibt an, dass die Seite wiedergabegeschützt ist. Ein Bitwert von Null gibt an, dass die Seite nicht wiedergabegeschützt ist.
1	VERTRAULICHKEITSSCHUTZ	CP: Vertraulichkeitsschutz (Confidentiality Protection). Ein Bitwert von 1 gibt an, dass die Inhalte der Seite verschlüsselt sind, während ein Bitwert von Null angibt, dass die Inhalte der Seite nicht verschlüsselt sind.
2	FÄLSCHUNGSSCHUTZ	FP: Fälschungsschutz (Forgery Protection). Da ein Fälschungsschutz in einer SE-Architektur obligatorisch ist, kann dieses Bit immer auf 1 gesetzt sein.
3	LESE-Zugriff	R: Ein Bitwert von 1 gibt an, dass die Seite aus dem Inneren der Enklave gelesen werden kann. Ein Bitwert von 0 gibt an, dass die Seite nicht aus dem Inneren der Enklave gelesen werden kann. Wenn das SECS-Flag gesetzt ist (siehe unten), kann das R-Flag auf 0 gesetzt sein (SECS kann nicht aus dem Inneren einer Enklave gelesen werden).
4	SCHREIB-Zugriff	W: Ein Bitwert von 1 gibt an, dass die Seite aus dem Inneren der Enklave beschrieben werden kann. Ein Bitwert von 0 gibt an, dass die Seite
		nicht aus dem Inneren der Enklave beschrieben werden kann. Wenn das SECS-, SMAP- oder TCS-Flag gesetzt ist (siehe unten), kann das W-Flag auf 0 gesetzt sein (SECS und TCS können nicht aus dem Inneren einer Enklave gelesen werden).
5	Ausführzugriff	X: Ein Bitwert von 1 gibt an, dass die Seite aus dem Inneren der Enklave ausgeführt werden kann. Ein Bitwert von 0 gibt an, dass die Seite nicht aus dem Inneren der Enklave ausgeführt werden kann. Wenn das SECS- oder TCS-Flag gesetzt ist (siehe unten), kann das X-Flag auf 0 gesetzt sein (SECS und TCS können nicht aus dem Inneren einer Enklave ausgeführt werden).
9:6	SEITENTYP 0 – SECS 1 – SMAP_LEVEL_1 2 – SMAP_LEVEL_2 3 – SMAP_LEVEL_3 (RESERVIERT) 4 – TCS 8 – REG	SECS: Bitwert von 0. R kann 0 sein, W kann 0 sein, X kann 0 sein. SMAP_LEVEL_1: Bitwert von 1. R kann 0 sein, W kann 0 sein, X kann 0 sein. SMAP_LEVEL_2: Bitwert von 2, R kann 0 sein, W kann 0 sein, X kann 0 sein. SMAP_LEVEL_3: Bitwert von 3, R kann 0 sein, W kann 0 sein, X kann 0 sein. TCS: Bitwert von 4, R kann 1 sein, W kann 0 sein und X kann 0 sein. REG: Bitwert von 8.
11:10	EACCEPT_PAGE_TYPE 00 – NONE 01 – EMODIFY 02 – EADD	NONE: Seite ist ein Element der Enklave. EMODIFIED: Seitenattribute wurden durch das BS modifiziert. EADD: Seite wurde von dem BS hinzugefügt.
12	A-WIEDERGABESCHUTZ	Gibt an, ob Wiedergabeschutzmaßnahmen angewendet werden, sobald eine Seite innerhalb der Enklave akzeptiert ist.
13	A-VERTRAULICHKEITSSCHUTZ	Gibt an, ob ein Vertraulichkeitsschutz angewendet wird, sobald die Seite innerhalb der Enklave akzeptiert ist.
14	A-FÄLSCHUNGSSCHUTZ	Gibt an, ob ein Fälschungsschutz angewendet wird, sobald die Seite innerhalb der Enklave akzeptiert ist.
15	RESERVIERT	MBZ
31:16	RESERVIERT	MBZ

Die Security Information(SEC_INFO)-Datenstruktur hält kryptographische Metadaten, die für den Fälschungsschutz benötigt werden. Tabelle 4-5: SEC_INFO-Struktur

Security Information
Name des Offsets	Größe (Bytes)	Kurzbeschreibung
MAC	16	Nachrichtenauthentifikationscode, der die Inhalte der Seite und die SEC_INFO-Flags authentifiziert
VERSION	16	Version (Seite IV)
KEY_ID	16	Schlüsselkennung, die verwendet werden soll, um die Seite und die SEC_INFO-Flags zu MAC/verschlüsseln
FLAGS	8	Flags, die den Zustand der Enklavenseite beschreiben
Reserviertes Flag	???
Reserviert	8	MBZ

Certificate (CERT) ist die Zertifikatstruktur, die mit den architektonischen Enklaven bereitgestellt wird und an EMKPERMIT weitergegeben wird. Diese Struktur weist 4096 Bytes auf und kann seitenausgerichtet sein. Tabelle 4-6: Certificate-Struktur

Offset (Bytes)	Länge (Bytes)	Name	Signiert?	Beschreibung
0	4	Cert Version	Nein	Strukturversion für dieses Zertifikat
4	4	Header Size	Nein	Größe des Headers (unsignierter Abschnitt von cert)
8	4	Body Size	Nein	Größe des Hauptteils (signierter Abschnitt)
12	4	Algorithm	Nein	Asymmetrischer Algorithmus, der zum Signieren verwendet wird 0x00000001: RSA
16	4	Key Size	Nein	Schlüsselgröße in Bits
20	4	Pub Key Size	Nein	Größe des öffentlichen Schlüssels in Dwords
24	4	Exponent	Nein	Exponent des Signierschlüssels
28	36	RESERVIERT	Nein	Reserviert-MBZ
64	256	Pub Key	Nein	Öffentlicher Schlüssel des Signierers
320	256	Signature	Nein	Signatur des Zertifikats
576	32	EADD Measurement	Ja	Erwarteter MR.EADD-Wert zum Zeitpunkt eines EINIT-Aufrufs.
608	16	Capability Mask	Ja	Satz von Fähigkeiten, die dieser Enklave zur Verfügung stehen.
612	4	ISV_Sec_Version	Ja	ISV-zugeordnete Sicherheitsversion
616	3480	RESERVIERT	Nein	Reserviert-MBZ

Permit (PERMIT) wird von EMKPERMIT und der Genehmigungsenklave (Permit Enclave) ausgegeben und von EINIT konsumiert. Es weist 4096 Bytes auf und kann seitenausgerichtet sein.

Offset (Bytes)	Länge (Bytes)	Name	Beschreibung
0	32	EADD Measurement	Erwarteter Wert von MR.EADD zum Zeitpunkt eines EINIT-Aufrufs.
32	32	Pub key_hash	Hash des Schlüssels, der zum Signieren eines Zertifikats verwendet wird.
64	16	Capabilities	Satz von Fähigkeiten, die dieser Enklave zur Verfügung stehen.
80	4	ISV_Sec_Version	ISV-zugeordnete Sicherheitsversion
84	4	Permit_Sec_Version	Sicherheitsversion der Quelle der Genehmigung
88	104	RESERVIERT	Reserviert-MBZ
192	16	KeyID	Der Wert der currentKeyID
208	16	RESERVIERT	Reserviert für KeyID-Erweiterung-MBZ
224	16	MAC	CMAC-Berechnung über die vorhergehenden Felder
240	16	RESERVIERT	Reserviert für MAC-Erweiterung-MBZ
256	3840	RESERVIERT	RESERVIERT-MBZ

Die ERPORT-Struktur ist die Ausgabe des EREPORT-Befehls. Tabelle 4-7: Report-Struktur

Offset (Bytes)	Länge (Bytes)	Name	Beschreibung
0	4	Capabilities	Die Werte der Capabilities-Flags für die Enklave.
4	1	Flags	Ein Bitfeld, das bestimmte Zustände der Enklave oder des Report-Befehls repräsentiert
5	1	RegSelect	Ein Bitfeld, um solche Messregister anzugeben, die außerhalb von UserData aufgenommen sind
6	10	RESERVIERT	Auf Null gesetzt
16	16	Sec Version	Die Sicherheitsversion des TCB
32	32	UserData	Der Wert der UserData, der von dem EREPORT-Aufrufer bereitgestellt wird.
64	32	MR_EADD	Der Wert des SECS->MR_EADD
96	32	MR_POLICY	Der Wert des SECS->MR_POLICY
128	32	RESERVIERT	Auf Null gesetzt
160	32	RESERVIERT	Auf Null gesetzt
176	16	KeyID	Der Wert von reportKeyID für die Baugruppe, auf der EREPORT ausgeführt wurde.
192	16	MAC	Die Ausgabe des Durchführens eines CMAC über die vorhergehenden Felder in dieser Struktur hinweg

Measurements (MEASUREMENTS) ist der Ausgabeparameter des ERDMR-Befehls. Er enthält die Messregisterwerte einer Enklave, die aus einer spezifizierten SECS genommen sind. Tabelle 4-8: Measurements-Struktur

Offset (Bytes)	Länge (Bytes)	Name	Beschreibung
0	32	MR_EADD	Der Wert des SECS->MR_EADD
32	32	MR_POLICY	Der Wert des SECS->MR_POLICY
64	32	RESERVIERT	Auf Null gesetzt
96	32	RESERVIERT	Auf Null gesetzt

Key Request (KEY_REQUEST) ist ein Eingabeparameter des EGETKEY-Befehls. Er wird zum Auswählen des geeigneten Schlüssels und beliebiger zusätzlicher Parameter verwendet, die bei der Ableitung dieses Schlüssels benötigt werden. Tabelle 4-9: Key Request-Struktur

Offset	Größe	Name	Beschreibung
(Byte)	(Bytes)
0x00	0x02	KeySelect	Identifiziert den benötigten Schlüssel (Key Required)
0x02	0x02	KeyPolicy	Identifiziert, welche Eingaben benötigt werden, die bei der Schlüsselableitung verwendet werden sollen
0x04	0x04	RESERVIERT	RESERVIERT
0x08	0x08	Randomness_1a	Stellt einen Zeiger auf einen 256-Bit-Datenblock bereit – kann natürlich ausgerichtet sein
0x16	0x16	SecVersion	Identifiziert, welche Sicherheitsversion (Security Version) bei der Schlüsselableitung verwendet werden kann

Tabelle 4-10: Request Key Request-Struktur

Bits	Name	Beschreibung
15:12	RESERVIERT	KANN NULL SEIN
11:00	KeyName	Numerischer Wert identifiziert den benötigten Schlüssel. 0x0000 – Out-of-Box ISV Experience-Schlüssel 0x0001 – Versorgungs-DID 0x0002 – Versorgungsschlüssel 0x0003 – Genehmigungsschlüssel 0x0004 – Berichtschlüssel 0x0005 – Siegelschlüssel 0x0006:0x07FF – RESERVIERT

Tabelle 4-11: Key Request Policy-Struktur

Bit	Name	Beschreibung
15:02	RESERVIERT	Reserviert. Kann Null sein
01	MR_POLICY	Leite Schlüssel mittels des POLICY-Messregisters der Enklave ab
00	MR_EADD	Leite Schlüssel mittels des EADD-Messregisters der Enklave ab

Diese Struktur wird bei Schlüsselableitungen verwendet, um Schlüssel basierend auf den Sicherheitsversionen der Enklave und dem SE TCB der Enklave zu generieren. Siehe die Plattform-TCB-Wiederherstellungsspezifikation für weitere Details der TCB-Security Version-Struktur. Tabelle 4-12: Security Version

Offset (Byte)	Größe (Bytes)	Name	Beschreibung
0x00	0x08	TCB Sec Version	Struktur einer Sicherheitsversion, die die Sicherheitsversion von wiederherstellbaren TCB-Schichten beschreibt, die unter der SE-Befehlsimplementierung implementiert sind.
0x08	0x04	Permit Enclave	Sicherheitsversion einer Genehmigungsenklave, die die Genehmigung für die Enklave generierte.
0x12	0x04	ISV	ISV-zugeordnete Sicherheitsversion für die Enklave

Tabelle 4-13: Package Manufacturing-Register

NAME	GRÖSSE (Bits)	Beschreibung
FUSE_KEY	128	Ein baugruppeneindeutiger Schlüssel, der als Wurzel für die In-Band-Schlüsselhierarchie dient
MKPERMIT_ROOT_HASH_KEY	256	Hash des öffentlichen Schlüssels, der verwendet wird, um die Lizenzen von architektonischen Enklaven zu authentifizieren
OOB_GLOBAL_KEY	128	Ein globaler Schlüssel, der verwendet wird, um eine OOB-Erfahrung bereitzustellen.

Tabelle 4-14: Package-Register

NAME	GRÖSSE (Bits)	Beschreibung
OWNER_EPOCH	256	Durch den Plattformbesitzer bereitgestellte Entropie, die bei der Ableitung der Schlüsselhierarchie verwendet wird
EPC_BASE	36
EPC_MASK	36
EPCM_BASE_OFFSET	16
EPC_SECSBASE_OFFSET	16

Tabelle 4-15: Logical Processor (Logischer Prozessor)

NAME	GRÖSSE (Bits)	Beschreibung
ENCLAVE_MODE	1	Gibt an, ob der Prozessor aktuell im Enklavenmodus ausführt
SECS_PHYSICAL_ADDRESS	16	Die Slot-ID, die die SECS für die aktuell ausführende Enklave umfasst
TCS_LINEAR_ADDRESS	64	Die lineare Adresse der TCS, die verwendet wurde, um in die Enklave einzusteigen
TCS_PHYSICAL_OFFSET	16	Die physikalische Adresse der Plattform der TCS, die verwendet wurde, um in die Enklave einzusteigen
SSA_PHYSICAL_OFFSET	16	Die physikalische Adresse der Plattform des SSA, die in dem Fall verwendet werden kann, dass die Enklave aufgrund eines Interrupts, Faults oder einer Ausnahme aussteigt.

Die EPCM-Flags sind ein Satz von Bits, die den Zustand einer Enklavenseite beschreiben. Tabelle 4-16: EPCM-Flags

EPCM-Flags
Name des Bits	Kurzbeschreibung
P	Präsent (Present)
D	Schmutzig (Dirty)
FCR	Aktualitätsprüfung (Freshness Check) benötigt
CP	Vertraulichkeitsgeschützt (Confidentiality Protected)
FP	Fälschungsgeschützt (Forgery Protected)
RP	Wiedergabegeschützt (Replay Protected)
R	Lesbar (Readable)
W	Beschreibbar (Writable)
X	Ausführbar (Executable)
PND	Seite steht aus, warten auf EACCEPT
DB	Debug
M	Flags von EMODIFY geändert

Enclave Page Cache Map (EPCM) ist eine Sicherheitsstruktur, die von dem Prozessor verwendet wird, um die Inhalte des Seiten-Cache nachzuverfolgen. Die EPCM enthält genau einen Eintrag für jede Seite, die aktuell in den EPC geladen ist. Tabelle 4-17: EPCM-Abbildung

Enclave Page Cache Map
Name des Offsets	Größe (Bytes)	Kurzbeschreibung
FLAGS	2	Flags, die den Zustand der Enklavenseite beschreiben
SECS_SID	2	SECS-Slot-ID
OFFSET	4	Offset einer Seite relativ zur linearen Basisadresse der Enklave.

Beglaubigung ist der Prozess des Demonstrieren, dass ein Stück Software auf der Plattform eingerichtet worden ist, insbesondere für eine entfernte Entität. Im Fall von sicheren Enklaven ist das der Mechanismus, durch den eine entfernte Plattform den Nachweis erbringt, dass Software auf einer authentischen Plattform abläuft, die innerhalb einer Enklave geschützt ist, bevor dieser Software Geheimnisse und ungeschützte Daten anvertraut werden. Der Beglaubigungsprozess hat drei Phasen, Messung, Speicherung und Berichten.
Es gibt zwei Messabschnitte innerhalb einer Enklave, vor der Enklaveneinrichtung und nach der Enklaveneinrichtung. Es liegt in der Verantwortung der Enklavenbefehle, Messungen der Enklave zu liefern, wenn sie eingerichtet wird. Sobald die Enklave eingerichtet worden ist, trägt die Software innerhalb der Enklave die Verantwortung für die Messung.
9 stellt einen Schritt des Softwarebeglaubigungsprozesses dar, der als Notieren (Quoting) bekannt ist, der in einer Ausführungsform der Erfindung gefunden werden kann. In einer Ausführungsform wendet die Signieroperation 910 einen Signierschlüssel 915 auf die verknüpften Daten aus Messregistern 901, 902, 903, 904 an. Das Ergebnis der Signieroperation 910 ist die Notierung 920.
Die Handlung des Berichtens bindet kryptographisch Messungen, die beim Erstellen der Enklave gemacht wurden, an die Plattform. Auf diesen Mechanismus wird oft als Notieren (Quoting) Bezug genommen, da auf der Plattform dieser Typ von Funktionalität für einige Zeit als ein TPM-Kommando verfügbar war. Die Werte der Messregister (MR) werden verknüpft und dann mittels eines asymmetrischen Schlüssels signiert. Jeder Herausforderer muss dann einfach die Signatur auf der Notierungsstruktur verifizieren, um die Notierung zu validieren.
10 stellt die Schritte einer Ausführungsform der Erfindung dar, um Notierungen aus einem Satz von Messregistern 1000 zu erzeugen. Die lokalen Berichte 1005 können durch Zugreifen auf die Messregister 1000 mit einem symmetrischen Authentifikationsschlüssel generiert werden. Die Notierungsenklave 1025 kann Software aufweisen, die die lokalen Berichte 1005 in anonyme Notierungen 1010 oder normale Notierungen 1020 konvertiert.
Aufgrund der Art und Weise der bei asymmetrischen Schlüsseln involvierten Berechnung und unseres Verlangens, die Anzahl von Befehlen in dem Enklavenblatt zu reduzieren, werden wir keine Befehle aufnehmen, um asymmetrisches Signieren zu machen. Unser in der unteren Figur gezeigte Ansatz besteht darin, einen hardware-basierten Mechanismus zum Erzeugen von ,Berichten' basierend auf einem Authentifikationsschlüssel eines symmetrischen Schlüssels bereitzustellen und zu erlauben, dass diese auf symmetrischen Schlüsseln basierende ,Berichte' in asymmetrisch signierte ,Notierungen' unter Verwendung von Software konvertiert werden, die selbst mittels einer Enklave geschützt ist. Da die Notierungsenklave autorisiert werden muss, um Zugriff auf den Plattformbeglaubigungsschlüssel zu haben, ist die Notierungsenklave selbst eine Spezialenklave, die als eine authentifizierte Enklave bekannt ist.
Jede Enklave stellt zwei 256-Bit-breite Messregister (MR_EADD und MR_POLICY) und zwei reservierte Register bereit. Diese Messregister sind innerhalb der SECS der Enklave enthalten.
11 stellt den EADD-Prozess zum Aktualisieren des Messregisters MR_EADD 1100 in einer Ausführungsform der Erfindung dar. Die Erweiterungsoperation 1115 kann als Eingabe den aktuellen Wert des MR_EADD 1100, die Seitendaten 1105 und die Seitenmetadaten 1110 annehmen. Die Ausgabe der Erweiterungsoperation ist das MR_EADD' 1120, das der nächste Wert ist, der in MR_EADD 1100 zu speichern ist.
MR_EADD umfasst die aggregierte Messung der Enklave als sie unter Verwendung des EADD-Befehls aufgebaut wurde, bevor der EINIT-Befehl aufgerufen wird. Darauf wird nur durch Mikrocode geschrieben und deshalb muss es in eine Seite der SECS platziert werden, die vor Enklavencode schreibgeschützt ist. Bei jedem Aufruf von EADD berechnet es einen SHA256 auf den Seitendaten und den Sicherheitsmetadaten, die der Seite zugeordnet sind, nämlich die relative Adresse (in Bezug auf die Basisadresse der Enklave) der Seite und die SEC_INFO.flags der Seite, und dieser Wert wird in MR_EADD 1100 erweitert. Wobei wir ,erweitern' mit folgender Bedeutung definieren: Neuer MR-Wert = Hash (Alter MR-Wert∥Eingabewert) MR_POLICY enthält den Wert der Richtlinie, der verwendet wird, um die Richtlinie zu authentifizieren, die es der Enklave erlaubt hat, gestartet zu werden. Dieser Wert wurde aus der Enklavengenehmigung genommen, die in der SECS beim Start platziert wurde und als erfolgreicher Abschluss des EINIT-Befehls kopiert wurde. Auf MR_POLICY wird nur durch Mikrocode geschrieben und deshalb muss es in einer Seite der SECS platziert werden, die vor Enklavencode schreibgeschützt ist.
12 stellt den EREPORT-Befehl dar, der in einer Ausführungsform der Erfindung Berichte erstellt. Die KEYID 1200, ein Besitzerzeitraum 1205, ein Baugruppenabsicherungsschlüssel 1210 und ein MAC-Schlüssel 1215 einer festgelegten Zeichenkette sind mögliche Eingaben für einen Ableitungsbefehl 1220. Die Ausgabe der Ableitung 1220 kann in die CMAC 1225 zusammen mit den aktuellen Werten von TCB-Version 1232, ISV-Version 1234, Fähigkeiten 1236, Flags 1238, Benutzerdaten 1240 und Messregistern 1242 eingegeben werden. Die Ausgabe des CMAC 1225 kann in dem MAC 1244 gespeichert sein. Die Ausgabe des EREPORT-Befehls kann die Schlüsselidentifikation 1230, TCB-Version 1232, ISV-Version 1234, Fähigkeiten 1236, Flags 1238, Benutzerdaten 1240, Messregister 1242 und MAC 1244 aufweisen.
Der EREPORT-Befehl erzeugt einen Zwischenschlüssel, um ein auf einem symmetrischen Schlüssel basiertes GMAC auf den Messregistern, Benutzerdaten und zusätzlichen Kontextinformationen, wie zum Beispiel den Fähigkeiten und Flags der Enklave, durchzuführen.
Zusätzlich zu den Messregistern kann der Benutzer ebenfalls einen 256-Bit-breiten Block von Daten zum Einfügen in den Bericht liefern. Es gibt viele anwendungsspezifische Werte, zum Beispiel eine Herausforderer-NONCE und/oder ein anwendungserstellter Schlüssel, die der Benutzer gerne attestieren würde. Diese Werte können auf einen einzelnen Hash reduziert und zur Aufnahme an den Bericht übermittelt werden.

Um ein Abnutzen von Schlüsseln durch wiederholtes Aufrufen von EREPORT zu verhindern, wird ein zufälliger 128-Bit-Wert (bekannt als reportKeyID) bei jedem Energiezyklus des Prozessors erzeugt und an einer internen Stelle gespeichert. Dieser Wert wird nach 2^32 AES-Operationen unter Verwendung dieses Werts inkrementiert. Jeder Aufruf des EREPORT-Befehls wird in einer Ausführungsform diesen Wert um 1 erhöhen. Tabelle 5-1: EREPORT-Ausgabestruktur

Offset (Bytes)	Länge (Bytes)	Name	Beschreibung
0	16	Capabilities	Die Werte der Fähigkeiten-Flags für die Enklave.
16	1	Flags	Ein Bitfeld, das einen bestimmten Zustand der Enklave oder des Berichtsbefehls repräsentiert
17	1	RegSelect	Ein Bitfeld, um diejenigen Messregister anzugeben, die außerhalb von UserData aufgenommen sind
18	14	RESERVIERT	Auf Null gesetzt
32	16	Sec Version	Die Sicherheitsversion des TCB
48	32	UserData	Der Wert der UserData, der von dem EREPORT-Aufrufer bereitgestellt wird.
80	32	MR_EADD	Der Wert des SECS->MR_EADD
112	32	MR_POLICY	Der Wert des SECS->MR_POLICY
144	32	RESERVIERT	Auf Null gesetzt
176	32	RESERVIERT	Auf Null gesetzt
208	16	KeyID	Der Wert von reportKeyID für die Baugruppe, auf der EREPORT ausgeführt wurde.
224	16	MAC	Die Ausgabe des Durchführens einer CMAC über die vorhergehenden Felder in dieser Struktur hinweg

Tabelle 5-2: EREPORT-Struktur

Das Flags-Feld in der Berichtstruktur kann verwendet werden, um bestimmte Zustandsinformationen über die Enklave oder, wenn der EREPORT-Befehl aufgerufen wurde, die für einen Herausforderer nützlich sein werden, zu bestimmen, um zu bewerten, ob sie der Enklave trauen können. Tabelle 5-3: EREPORT-Flag-Struktur

Bit	Name	Beschreibung
0	DEBUG	1: Die Enklave ist im Debug-Modus (auf ECREATE gesetzt)
1	NPW	1: Wenn Capabilities.NPW = 1. Gesetzt durch EINIT
2-7	RESERVIERT	MBZ: RESERVIERT für zukünftige Verwendung

Tabelle 5-4: Flags
In einer Ausführungsform erlaubt die Architektur eine architektonische Enklave mit dem geeigneten Fähigkeitensatz, um den in der CMAC-Operation verwendeten Schlüssel mit dem EGETKEY-Kommando abzurufen und somit zu verifizieren, dass der Bericht auf der Hardware erzeugt wurde, auf der sie aktuell abläuft. Diese Fähigkeit ist auf die notierende architektonische Enklave beschränkt.

Zum Abrufen von Messungen der Enklave beim Ausführen außerhalb der Enklave ist der ERDMR(Read Measurements)-Befehl bereitgestellt. Dieser Befehl nimmt einen Zeiger auf eine gültige SECS-Seite und einen Zeiger auf eine Adresse, an der die Messungen bereitgestellt werden. Die Messungen werden in der Form einer MEASUREMENT-Struktur bereitgestellt. Die MEASUREMENT-Struktur ist nicht kryptographisch geschützt. Tabelle 5-5: MEASUREMENT-Struktur

Enklavenseiten werden kryptographisch geschützt, wenn sie sich nicht innerhalb des Enklavenseiten-Cache befinden. Es gibt drei Ebenen des kryptographischen Schutzes: Vertraulichkeitsschutz, Fälschungsschutz und Wiedergabeschutz. In einer Ausführungsform ist es Anwendungen erlaubt, eine Schutzebene für jede Enklavenseite unabhängig von der Schutzebene zu wählen, die für andere Seiten derselben Enklave gewählt wird. Die Implementierung der Enklaven KANN Anwendungen erlauben, zwischen den folgenden Kombinationen zu wählen: Fälschungsschutz, Fälschungsschutz und Wiedergabeschutz, Vertraulichkeits- und Fälschungsschutz, sowie Vertraulichkeits-, Fälschungsschutz und Wiedergabeschutz. Vertraulichkeits- und Fälschungsschutz auf einer Enklavenseite kann unter Verwendung eines der vielen authentifizierten Verschlüsselungsmodi erreicht werden, wie zum Beispiel dem Galois-Zähler-Modus (GCM) in Verbindung mit einer geeigneten Chiffre, wie zum Beispiel AES. Der Wiedergabeschutz erfordert jedoch eine anspruchsvollere Lösung.
13 stellt den Mechanismus des Fälschungsschutzes und Wiedergabeschutzes dar, der in einer Ausführungsform der Erfindung zu finden ist. Der Fälschungsschutz hindert einen Angreifer daran, einen anderen Wert von verschlüsselten Daten zu ersetzen, der nicht durch das Programm generiert ist. Der Wiedergabeschutz hindert einen Angreifer daran, einen Wert von verschlüsselten Daten zu ersetzen, der nicht der aktuelle neuste von dem Programm generierte Wert ist. Die Knotenversionsnummer 1300 kann den IV 1310 eingeben und dann zu dem GMAC-Algorithmus 1325. Die Versionsnummern für Kinder 1305 können Daten 1315 an den GMAC-Algorithmus 1325 senden. Der GMAC-Algorithmus 1325 kombiniert den Schlüssel 1320, den IV 1310 und die Daten 1315, um den MAC 1330 zu generieren.
Der Wiedergabeschutz stellt sicher, dass alle Inhalte einer Enklave, wie sie von einem logischen Prozessor zu jeder beliebigen Zeit gesehen werden, zu einem einzelnen Speicherauszug (Snapshot) einer unbeschädigten Enklave gehören. Somit muss ein Wiedergabeschutzmechanismus das Konzept einer Enklavenversion definieren und einen Mechanismus zum Bestimmen bereitstellen, ob eine fälschungsgeschützte Enklavenseite zu dieser Version der Enklave gehört. Zu diesem Zweck bindet der Wiedergabeschutzmechanismus die Inhalte jeder fälschungsgeschützten Enklavenseite an eine Seitenversionsnummer mittels eines Nachrichtenauthentifikationsalgorithmus, wie zum Beispiel GMAC. Im Fall von GMAC kann die Version als ein Teil des Initialisierungsvektors (IV) verwendet werden, wie es in 13 gezeigt ist.
14 stellt ein Beispiel des MAC-Baumstrukturabschnitts des Wiedergabeschutzmechanismus dar, der in einer Ausführungsform der Erfindung zu finden ist. Der Blattknoten 1425 kann die Versionsinformationen für eine individuelle MAC-Inhaltsseite 1430 umfassen. Jeder Blattknoten, wie zum Beispiel 1420, umfasst eine individuelle MAC-Inhaltsseite (nicht gezeigt). Jeder innere Knoten 1410, 1415 kann Versionsinformationen der Kindergruppen umfassen, zu denen er verbindet. Die Wurzel 1400 ist der Knoten auf höchster Ebene in der Baumdatenstruktur.
Um die Versionsverwaltung auf die gesamte Enklave auszuweiten, pflegt der Wiedergabeschutzmechanismus einen Versionsbaum. Blattknoten umfassen die Versionen von individuellen wiedergabegeschützten Seiten der Enklaveninstanz. Jeder innere Knoten stellt die Version von jeder Gruppe von Kinder bereit und hält deshalb logisch die Versionsinformationen für die Seiten, die sie repräsentieren. 14 zeigt dieses Konzept bildlich.
In einer Ausführungsform wurde die Baumstruktur gewählt, um die Anzahl von Daten, die verarbeitet werden müssen, von O(n)-Seiten auf O(logn) zu reduzieren. Die Verwendung eines Versionsbaums statt eines Hash-Baums wurde ausgewählt, um ein Seitenausräumen aus dem EPC zu ermöglichen, ohne eine Baumaktualisierung zu benötigen.
Da der Wiedergabeschutz von jeder Seite verlangen kann, ihre eigene Version zu haben, die kryptographisch an ihre Inhalte gebunden ist, erfordert der Wiedergabeschutz den Fälschungsschutz. Somit ist der Fälschungsschutz in einer SE-Architektur obligatorisch. Zusätzlich können initiale Implementierungen von SE weiter die Liste von unterstützten Schutzkombinationen einschränken.
Das BS/der VMM erzeugt eine Enklave durch Ausführen des ECREATE-Befehls. Während der Erzeugung der Enklave wird der Bereich von linearen Adressen, der durch die Enklave geschützt ist, spezifiziert. Dieser Bereich von linearen Adressen ist bekannt als der Bereich des linearen Enklavenraums (Enclave Linear Space, ELS).
Sobald eine Enklave erzeugt ist, werden individuelle Seiten, die zu dem ELS-Bereich gehören, zu der Enklave mittels des EADDPRE-Befehls hinzugefügt. Der EADDPRE-Befehl bringt jede der hinzugefügten Seiten in die Enklavenschutzdomäne durch Verschieben dieser Seiten in den Enklavenseiten-Cache. Falls irgendeine dieser Seiten aus dem EPC mittels EWBINVPG ausgelagert wird, wird der logische Prozessor kryptographische Schutzmaßnahmen auf diese Seiten packen.
Die kryptographischen Schutzmaßnahmen werden durch Zuordnen von kryptographischen Metadaten zu jeder Enklavenseite erreicht. Diese Metadaten werden von den uCode-Flüssen für verschiedene Prozessorbefehle verwendet, um die Inhalte einer Enklavenseite zu entschlüsseln und die Authentizität/Aktualität von jeder Enklavenseite zu verifizieren. Die SE-Architektur stellt mehrere solche Befehle zum Aktualisieren, Verwalten und Validieren der kryptographischen Metadaten bereit.

Jede Enklavenseite hat eine Security Information SEC_INFO-Datenstruktur, die ihr zugeordnet ist. Der Zweck der SEC_INFO-Datenstruktur besteht darin, die kryptographischen Metadaten zu halten, die benötigt werden, um die Seite zu entschlüsseln und zu verifizieren. Die verschiedenen Felder der SEC_INFO-Struktur sind wie folgt. Tabelle 6-1: Die SEC_INFO-Datenstruktur

Feldtyp	Feldname	Beschreibung
UINT128	MAC	Nachrichtenauthentifikationscode, der die Inhalte der Seite und die SEC_INFO-Flags authentifiziert
UINT128	iv_p	Seiten-IV, der zum Berechnen des obigen MAC verwendet wird.
UINT128	Key_id	Schlüsselkennung, die verwendet werden soll, um die Seite und die SEC_INFO-Flags zu MAC/verschlüsseln
UINT32	Flags	Flags, die den Seitentyp, die kryptographischen und Zugriffsschutzmaßnahmen für die Seite beschreiben.
UINT32	RESERVIERT	Reserviert für zukünftige Verwendung. MBZ.
UINT64	RESERVIERT	Reserviert für zukünftige Verwendung. MBZ.

Die Security Information-Flags (SEC_INFO.Flags) beschreiben den Seitentyp, den kryptographischen und den Zugriffsschutz für eine geschützte Seite. Tabelle 6-2: SEC_INFO-Flags

Bit-Pos.	Inhalt
0	WIEDERGABESCHUTZ	RP: Wiedergabeschutz (Replay Protection). Ein Bitwert von 1 gibt an, dass die Seite wiedergabegeschützt ist. Ein Bitwert von Null gibt an, dass die Seite nicht wiedergabegeschützt ist.
1	VERTRAULICHKEITSSCHUTZ	CP: Vertraulichkeitsschutz (Confidentiality Protection). Ein Bitwert von 1 gibt an, dass die Inhalte der Seite verschlüsselt sind, während ein Bitwert von Null angibt, dass die Inhalte der Seite nicht verschlüsselt sind.
2	FÄLSCHUNGSSCHUTZ	FP: Fälschungsschutz (Forgery Protection). Da ein Fälschungsschutz in einer SE-Architektur obligatorisch ist, kann dieses Bit immer auf 1 gesetzt sein.
3	LESE-Zugriff	R: Ein Bitwert von 1 gibt an, dass die Seite aus dem Inneren der Enklave gelesen werden kann. Ein Bitwert von 0 gibt an, dass die Seite nicht aus dem Inneren der Enklave gelesen werden kann. Wenn das SECS-Flag gesetzt ist (siehe unten), kann das R-Flag auf 0 gesetzt sein (SECS kann nicht aus dem Inneren einer Enklave gelesen werden).
4	SCHREIB-Zugriff	W: Ein Bitwert von 1 gibt an, dass die Seite aus dem Inneren der Enklave beschrieben werden kann. Ein Bitwert von 0 gibt an, dass die Seite nicht aus dem Inneren der Enklave beschrieben werden kann. Wenn das SECS-, SMAP- oder TCS-Flag gesetzt ist (siehe unten), kann das W-Flag auf 0 gesetzt sein (SECS und TCS können nicht aus dem Inneren einer Enklave gelesen werden).
5	Ausführzugriff	X: Ein Bitwert von 1 gibt an, dass die Seite aus dem Inneren der Enklave ausgeführt werden kann. Ein Bitwert von 0 gibt an, dass die Seite nicht aus dem Inneren der Enklave ausgeführt werden kann. Wenn das SECS- oder TCS-Flag gesetzt ist (siehe unten), kann das X-Flag auf 0 gesetzt sein (SECS und TCS können nicht aus dem Inneren einer Enklave ausgeführt werden).
9:6	SEITENTYP 0 – SECS 1 – SMAP_LEVEL_1 2 – SMAP_LEVEL_2 3 – SMAP_LEVEL_3 (RESERVIERT) 4 – TCS 8 – REG	SECS: Bitwert von 0. R kann 0 sein, W kann 0 sein, X kann 0 sein. SMAP_LEVEL_1: Bitwert von 1. R kann 0 sein, W kann 0 sein, X kann 0 sein. SMAP_LEVEL_2: Bitwert von 2, R kann 0 sein, W kann 0 sein, X kann 0 sein. SMAP_LEVEL_3: Bitwert von 3, R kann 0 sein, W kann 0 sein, X kann 0 sein. TCS: Bitwert von 4. R kann 1 sein, W kann 0 sein und X kann 0 sein. REG: Bitwert von 8.
11:10	EACCEPT_PAGE_TYPE 00 – NONE 01 – EMODIFY 10 – EADD	NONE: Seite ist ein Element der Enklave. EMODIFIED: Seitenattribute wurden durch das BS modifiziert. EADD: Seite wurde von dem BS hinzugefügt.
12	A-WIEDERGABESCHUTZ	Gibt an, ob Wiedergabeschutzmaßnahmen angewendet werden, sobald eine Seite innerhalb der Enklave akzeptiert ist.
13	A-VERTRAULICHKEITSSCHUTZ	Gibt an, ob ein Vertraulichkeitsschutz angewendet wird, sobald die Seite innerhalb der Enklave akzeptiert ist.
14	A-FÄLSCHUNGSSCHUTZ	Gibt an, ob ein Fälschungsschutz angewendet wird, sobald die Seite innerhalb der Enklave akzeptiert ist.
15	RESERVIERT	MBZ
31:16	RESERVIERT	MBZ

Security Map (SMAP) ist die Datenstruktur, die verwendet wird, um kryptographische Metadaten zu speichern, die benötigt werden, um die Aktualität einer Enklavenseite zu verifizieren (d. h. Wiedergabeschutz). Eine Sicherheitsabbildung (Security Map) repräsentiert einen vollständigen Versionsbaum für einen bestimmten Speicherauszug einer Enklave. Jeder Knoten der Security Map hält Versionen für 256 Kindknoten (oder im Fall eines Blattknotens für Enklavenseiten). Zusätzliche Metadaten über den Sicherheitsknoten sind innerhalb der SEC_INFO für einen bestimmten SMAP-Knoten enthalten.
In einer Ausführungsform ist der Security Map-Baum zwei Ebenen tief1

1: Die Tiefe der Security Map bezieht sich auf die von der SE-Architektur unterstützte Größe der Enklave. In Gen 1 wird die SE-Architektur eine maximale Enklavengröße von 32 GB unterstützen.

Baumtiefe	Indizierende Bits
Bei Tiefe 0	Bits 34 bis 28 des Enklavenoffsets werden verwendet
Bei Tiefe 1	Bits 27 bis 20 des Enklavenoffsets werden verwendet
Bei Tiefe 2	Bits 19 bis 12 des Enklavenoffsets werden verwendet

Allgemein werden bei einer Tiefe l > 1 die Bits N – (l) × 8 bis N – (l + 1) × 8 + 1 verwendet, um das geeignete Kind auf nächster Ebene auszuwählen.
Beachte: Security Map ist eine logische Datenstruktur und ist nicht architektonisch. Ein logischer Prozessor ist sich nicht einmal dessen bewusst, wo im linearen Adressraum die SMAP angeordnet ist. Die Systemsoftware ist für das Warten und Begehen der Sicherheitsabbildung verantwortlich. Jeder individuelle Knoten in der Sicherheitsabbildung hat eine architektonisch definierte Struktur –jedoch spezifiziert die Architektur nicht, wie die Sicherheitsabbildung im Speicher gewartet wird. Es sollte jedoch beachtet werden, dass jeder Knoten in der Sicherheitsabbildung eine wohldefinierte logische Position in der Sicherheitsabbildung hat und die verschiedenen Prozessorbefehle, die sich auf die Sicherheitsabbildung beziehen, es als ein Angriffsszenario interpretieren werden, wenn der Knoten innerhalb der Abbildung herumverschoben wird.
Ein Sicherheitswurzelknoten ist innerhalb der SECS enthalten und umfasst Versionsinformationen für 128 Kinder. Ein Sicherheitsknoten, der keine Wurzel ist, ist eine geschützte Seite und ihre zugeordnete SEC_INFO. Die geschützte Seite umfasst Versionsinformationen für 256 Kinder. Tabelle 6-4: SMAP-Knoten-Layout

Feldtyp Feldname Beschreibung

UINT128 VERSION-0 VERSION für Kind 0

UINT128 VERSION-1 VERSION für Kind 1

UINT128 VERSION-N VERSION für Kind N

UINT128 VERSION-255 VERSION für Kind 255
Die SEC_INFO umfasst die Position der SMAP innerhalb der SMAP. Die Position mit der SMAP ist durch den linearen Offset/Enklavenoffset und den Seitentyp SMAP_LEVEL_1 und SMAP_LEVEL_2 bestimmt.
Ein Hinzufügen einer wiedergabegeschützten Enklavenseite erfordert, dass der SMAP-Vorgänger erstellt wurde und sich innerhalb des EPC mit einem gelöschten FCR-Bit befindet.
Um die Integrität einer Enklavenseite zu verifizieren, verwendet ein logischer Prozessor den IV_P und die key_id in der SEC_INFO-Struktur, um einen Schlüssel zu generieren. Der Schlüssel wird verwendet, um den MAC über den Flags in der SEC_INFO-Struktur und den Inhalten der Seite zu berechnen. Der berechnete MAC wird mit einem MAC verglichen, der in der SEC_INFO-Struktur angeordnet ist. Wenn die MACs übereinstimmen, wird angenommen, dass die Seite die Integritätsprüfung bestanden hat.
Ein logischer Prozessor verifiziert die Integrität einer Seite, wenn die Seite in den EPC mittels des ELPG-Befehls geladen wird. Als Teil dieses Befehls notiert ein logischer Prozessor den IV_P aus der SEC_INFO-Struktur, die verwendet wurde, um die Seite zu verifizieren.
Um die Aktualität einer Enklavenseite zu verifizieren, verifiziert ein logischer Prozessor, dass die Enklavenseite und ihr smap-Vorgänger in den EPC geladen wurden und dass der smap-Vorgänger aktuell ist. Er fährt dann damit fort, die Version der Seite mit einer Version zu prüfen, die in dem smap-Vorgänger gespeichert ist. Falls die beiden Versionen übereinstimmen, generiert der Prozessor eine neue Version für die Seite und aktualisiert die Version in dem smap-Vorgänger und die Version der Enklavenseite. Zum Schluss markiert er die Enklavenseite als aktuell.
Beachte – die Generierung einer neuen Version ermöglicht der Seite, modifizierbar zu sein. Dies vereinfacht sowohl die Architektur als auch die Implementierung.
Um eine Enklavenseite zu entfernen, verifiziert ein logischer Prozessor, dass die Enklavenseite und ihr smap-Vorgänger in den EPC geladen wurden und beide aktuell sind. Er fährt dann damit fort, die Version der Seite in dem smap-Vorgänger auf 0 zu setzen und den EPC-Slot der Enklavenseite als verfügbar zu markieren.
Der Enklavenseiten-Cache (EPC) ist ein sicherer Speicher, der von der CPU verwendet wird, um Enklavenseiten temporär zu speichern, wenn sie nicht durch kryptographische SE-Schutzmaßnahmen kryptographisch geschützt sind.
Die folgenden Anforderungen werden auf dem EPC identifiziert. Beliebige Zugriffe auf die in den EPC geladenen Enklavenspeicherseiten, die zu Nicht-Debug-Enklaven gehören, können vor jeder Modifizierung durch Softwareentitäten außerhalb dieser Enklave geschützt werden. Angreifer können daran gehindert werden, Klartextdaten durch direkte Hardware-Angriffe zu lesen, die zu Nicht-Debug-Enklaven gehören, die in den EPC geladen sind. Angreifer können daran gehindert werden, Daten im EPC durch direkte Hardware-Angriffe zu modifizieren, die zu Nicht-Debug-Enklaven gehören. Auf beliebige Daten, die in den EPC geladen sind, kann kohärent, von einer beliebigen CPU im System jedoch sicher zugegriffen werden.
Es gibt mehrere Mechanismen zum Implementieren des EPC. Der EPC kann als On-Die-SRAM oder eDRAM implementiert sein. Der EPC kann ebenfalls durch dynamisches Sequestrieren von Bahnen des Last-Level-Cache der CPU konstruiert sein. In einer solchen Implementierung kann der EPC vor nicht autorisierten Zugriffen von außerhalb der Baugruppe geschützt sein. Jedoch können andere Baugruppen im System in der Lage sein, auf den EPC kohärent, jedoch sicher zuzugreifen.
Ein anderer Mechanismus zum Implementieren des EPC ist die Kryptospeicherapertur (CMA). Die Kryptospeicherapertur (CMA) stellt einen kosteneffektiven Mechanismus zum Erstellen von kryptographisch geschütztem volatilem Speicher unter Verwendung von Plattform-DRAM bereit. Die CMA verwendet eine oder mehrere strategisch platzierte kryptographische Einheiten im CPU-Uncore, um verschiedene Ebenen des Schutzes bereitzustellen, wie es von der Kundentechnologie benötigt wird. Die verschiedenen Uncore-Agenten werden modifiziert, um die Speicherzugriffe, die zu der CMA gehen, zu erkennen und um diese Zugriffe an einen Krypto-Controller zu leiten, der im Uncore angeordnet ist. Der Krypto-Controller generiert abhängig von der gewünschten Schutzebene einen oder mehrere Speicherzugriffe auf den Plattform-DRAM, um den Chiffriertext zu holen. Er verarbeitet dann den Chiffriertext, um den Klartext zu generieren, und erfüllt die ursprüngliche CMA-Speicheranforderung. Die CMA ist vollständig in das Intel QuickPath Interconnect(QPI)-Protokoll integriert und skaliert auf Mehrfachbaugruppenplattformen mit Sicherheitserweiterungen für das QPI-Protokoll. In einer Konfiguration einer Mehrfachbaugruppenplattform schützt die CMA Speichertransfers zwischen Intel CPUs mittels einer Verbindungsebenensicherheits(Link-Sec)-Engine in den auswärts gerichteten QPI-Verbindungsebenen.
Man sagt, dass eine SECS aktiv ist, wenn sie aktuell in den EPC geladen ist. Wie später in diesem Dokument erklärt wird, ist das BS/der VMM dafür verantwortlich, das zu verwalten, was in den EPC geladen wird. Jedoch muss das BS/der VMM beim Laden einer Enklavenseite in den EPC der CPU den zeitweiligen Aufenthaltsort der SECS für diese Seite mitteilen, außer wenn die betrachtete Seite selbst eine SECS ist. Wenn die Seite, die geladen wird, keine SECS ist, verlangt die CPU, dass die SECS, die der Seite entspricht, innerhalb des EPC angeordnet ist. Vor einem Laden einer beliebigen Seite für eine Enklave KANN das BS/der VMM die SECS für diese Enklave in den EPC laden.
Es sollte beachtet werden, dass die CPU keinerlei Beschränkungen dahingehend durchsetzt, wie oft eine SECS in dem EPC geladen sein kann – jedoch wäre es für das BS/den VMM höchst unüblich, mehrere Kopien der SECS in den Enklavenseiten-Cache zu laden. Nichtsdestotrotz wird, sogar wenn mehrere Kopien derselben SECS in dem EPC geladen sind, jede dieser Kopien als eine separate aktive SECS-Instanz betrachtet und die in den EPC geladenen Enklavenseiten, die zu unterschiedlichen Instanzen einer aktiven SECS gehören, werden von der Hardware derart betrachtet, als dass sie zu unterschiedlichen Enklaven gehören.
Das BS/der VMM sieht den EPC als einen zusammenhängenden Block eines physikalischen Speichers im Systemadressraum 10. Jedoch ordnet die CPU jeder EPC-Seite eine Slot-Kennung (SID) zu, um internen Speicher zu reduzieren und ein schnelles indizieren zu ermöglichen. Die physikalische Adresse einer EPC-Seite und die korrespondierende Slot-Kennung sind wie folgt aufeinander bezogen. sid = (page_pa – epc_base_pa) >> 12 page_pa = pc_base_p)|(sid << 12)
Die Hardware verwendet eine spezielle Slot-Kennung 0xFF, um einen ungültigen Slot zu bezeichnen. Die EPC-Slot-Kennungen werden sowohl von dem uCode als auch dem PMH verwendet, um die Informationen über die Enklavenseiten nachzuverfolgen.
Jede Enklavenseite, die in dem EPC geladen ist, hat eine wohldefinierte physikalische Systemadresse. Da es eine Eins-zu-Eins-Abbildung zwischen den physikalischen Adressen, die zu dem EPC gehören, und den EPC-Slot-Kennungen gibt, sagen wir, dass jede Seite, die in dem EPC geladen ist, ihre eigene EPC-Slot-Kennung oder EPC_SID hat.
Zusätzlich ist jede Enklavenseite außer der SECS-Seite, die in den EPC geladen ist, einer aktiven SECS-Instanz zugeordnet. Es wird daran erinnert, dass eine aktive SECS-Instanz nichts als eine SECS-Seite ist, die in dem EPC geladen ist. Konsequenterweise hat die aktive SECS-Seite ebenfalls ihre eigene EPC_SID. Auf die EPC_SID der SECS-Seite, zu der eine nicht-SECS-Enklavenseite gehört, wird als die SECS_SID für eine Nicht-SECS-Seite Bezug genommen. Für jede Seite, die in den EPC geladen ist, wird die Hardware die SECS_SID nachverfolgen. Die SECS_SID für SECS-Seiten, die in den EPC geladen sind, wird als 0xFF oder die ungültige SID definiert.
Die EPCM ist eine sichere Struktur, die von dem Prozessor verwendet wird, um die Inhalte des Seiten-Cache nachzuverfolgen. Die EPCM hält genau einen Eintrag für jede Seite, die aktuell in den EPC geladen ist. Für die dadurch repräsentierte Seite verfolgt jeder EPCM-Eintrag solche Informationen nach, wie die Enklave, zu der die Seite gehört, die Adresse, für die die Seite in den Enklavenseiten-Cache gebracht wurde, die Version der Seite usw. Die EPCM-Struktur wird von der CPU in dem Adressübersetzungsfluss verwendet, um eine Adresskontrolle der Enklavenseiten, die in den EPC geladen sind, durchzusetzen. Die EPCM-Einträge werden von dem (x)uCode als Teil von verschiedenen Befehlsflüssen verwaltet.
In einer Ausführungsform der Erfindung kann der Enklavenseiten-Cache (EPC) dynamisch alloziert oder dealloziert werden. In einer Ausführungsform kann Software, wie zum Beispiel ein Betriebssystem, Seiten in einem Speicher als EPC allozieren oder Speicher aus dem EPC deallozieren. In einer Ausführungsform kann das Betriebssystem eine beliebige Seite in der Enklave derart zuweisen, dass sie im EPC ist. Der EPC kann in einigen Ausführungsformen jede verfügbare Stelle im Speicher aufgreifen. Eine Unterscheidung zwischen einem dynamischen EPC und einem festgelegten EPC besteht gemäß einer Ausführungsform darin, dass der dynamische EPC das Hinzufügen und Entfernen von Seiten des Speichers erlaubt. In einer Ausführungsform kann Logik, wie zum Beispiel ein Software-Treiber, einen Speicherbereich als EPC allozieren und den Speicher aus dem EPC deallozieren. In einer Ausführungsform prüft ein Pre-Boot-Prozess verfügbaren Speicher, um Metadaten für jede Seite des Speichers zu speichern und eine Software kann eine Seite dahingehend deklarieren, dass sie ein EPC oder kein EPC ist, während eine Hardware-Logik Attribute jeder Seite nachverfolgen und durchsetzen kann.
In einer Ausführungsform kann Hardware-Logik Zugriff auf den Speicher, der als ein EPC verwendet wird, über einen Übersetzungsnachschlagepuffer (Tranisation Lookaside Buffer, TLB) und einen Page-Miss-Handler (PMH) kontrollieren. Wenn die Suchadresse eine Übereinstimmung im TLB hat, was als ein TLB-Hit bekannt ist, kann in einer Ausführungsform der TLB geflusht werden, wenn die sichere Enklave aus dem EPC aussteigt. Wenn die Suchadresse keine Übereinstimmung im TLB hat, was als ein TLB-Miss bekannt ist, kann in einer Ausführungsform ein zusätzliches Nachschlagen Daten aus der Enklavenseiten-Cache-Abbildung (EPCM) über mehrere Speicherreferenzen holen. In einer Ausführungsform kann ein PMH das Nachschlagen der EPCM durchführen. In einer anderen Ausführungsform wird ein Bereichsregister im PMH geprüft, um Zugriff auf eine zusammenhängende physikalische Adresse, EPC, zu kontrollieren. Das Betriebssystem muss nicht einen direkten Speicherzugriff (Direct Memory Access, DMA) erlauben, um auf die EPC-Seiten zuzugreifen. Wenn die zurückgegebene Seite des Speichers als eine Enklavenseite markiert ist, kann die Kontrollstrukturkennung der sicheren Enklave (SECSID) der Seite mit derjenigen der aktuell ausführenden Enklave geprüft werden, um sicherzustellen, dass der Zugriff sicher ist. Falls eine Diskrepanz zwischen der SECSID der zurückgegebenen Seite und der der aktuell ausführenden Enklave vorliegt, kann der PMH eine Abbruchnachricht ausgeben. Wenn die zurückgegebene Seite des Speichers nicht als eine Enklavenseite markiert ist oder wenn die zurückgegebene Seite des Speichers als eine Enklavenseite markiert ist und die SECSID der Seite mit der der ausführenden Enklave übereinstimmt, kann der PMH die Seitenübersetzung in den TLB laden. In einer Ausführungsform kann ein Cache-Tag verwendet werden, um die Enklavenzeile von den anderen Zeilen bei einem Rückschreibzyklus zu identifizieren. Jedoch wird in mindestens einer Ausführungsform kein Cache-Tag verwendet, wenn die Logik, die den Typ der Speicheranforderung bestimmt, auf die EPCM während eines Rückschreibzyklus zugreift.
In einer Ausführungsform der Erfindung kann eine Software, das BIOS, Speicher allozieren bevor das Betriebssystem bootet, um Enklavenseiten zu erstellen. Die Software kann in einer Ausführungsform einen EPC durch eine Sequenz von Schritten im BIOS erstellen. Das BIOS kann einigen Speicher dafür reservieren, Metadaten zu speichern, und für jeden Prozessor ein Bereichsregister setzen. Das BIOS kann als Eingabe eine Basisadresse und eine Speichergröße nehmen. Die Systemkonfiguration wird durch einen Prozess, der als MCHECK bekannt ist, geprüft, um sicherzustellen, dass alle Register auf allen Baugruppen und allen Kernen richtig gesetzt sind, um Schutz vor Zugriffen außerhalb der Enklave bereitzustellen. MCHECK wird die Register sperren, bis das System zurücksetzt. In einer anderen Ausführungsform kann eine Software eine Seite zu einem EPC durch einen Befehl hinzufügen, der als EPCADD bekannt ist, der Abschnitte von Speicher dahingehend deklariert, dass sie ein Teil des EPC sind. Die EPCADD-Sequenz kann eine Speicheradresse als Eingabe nehmen und eine Nachricht ausgeben, um den Erfolg oder Fehlschlag anzugeben. In dem Fall, dass der EPCADD eine Nachricht ausgibt, die Erfolg angibt, kann der EPCADD das EPCM.E-Bit setzen und die Seite, die dieser physikalischen Adresse entspricht, wird aus allen TLBs im System geflusht. In einer Ausführungsform der Erfindung kann der EPCADD im RAX einen Fehlercode von 01 zurückgeben, um darzustellen, dass die Seite mit der Eingabeadresse bereits eine EPC-Seite ist, und einen Fehlercode von 02, um darzustellen, dass die Eingabeadresse nicht im zulässigen Bereich liegt. Eine Seite des Speichers, die von EPCADD als Teil eines EPC deklariert ist, kann EPC-Semantiken benötigen, um auf die Daten zuzugreifen. In dieser Ausführungsform der Erfindung kann eine Software eine Seite aus dem EPC in einem Befehl entfernen, der als EWBINVPG bekannt ist, und den verschlüsselten Daten erlauben, fortlaufend verfügbar zu sein, während sie durch einen Kryptographie- und Integritätsschutz geschützt sind. Daten in diesem Format können im regulären Speicher des Festplattenlaufwerks gespeichert sein. In einer noch weiteren Ausführungsform kann eine Software in einem Befehl, der als EPCREMOVE bekannt ist, eine Seite aus einem EPC entfernen und die verschlüsselten Daten nicht verfügbar machen. Eine Hardware, die EPCREMOVE ausführt, löscht die Seite und Teile der EPCM. EPCREMOVE kann ausgeführt werden, ohne dass zuerst EWBINVPG ausgeführt wird. Die EPCREMOVE-Sequenz kann in einer Ausführungsform eine Seite aus einem EPC basierend auf einer Speicheradresse entfernen. In einer Ausführungsform der Erfindung kann der EPCREMOVE-Befehl im RAX einen Fehlercode von 01 aufweisen, um darzustellen, dass die Seite, die entfernt wird, Teil einer Kontrollstruktur einer sicheren Enklave (SECS) ist und nicht entfernt werden kann, und einen Fehlercode von 02, um darzustellen, dass die Seite, die entfernt wird, keine EPC-Seite ist. Ein globales TLB-Shootdown einer Seite des Speichers kann in einer Ausführungsform der Erfindung aus EPCREMOVE resultieren und der Speicher, der vorher von der Seite besetzt war, kann für allgemeinen Software-Zugriff wieder verfügbar sein.
Der PMH verhindert einen Zugriff auf die geschützten Bereiche des Speicherraums. In Abhängigkeit von der Architektur, kann dies genauso einfach wie die physikalische Adressprüfung von Zugriffen auf den EPC sein. Darüber hinaus kann PMH-Unterstützung verwendet werden, um Leistungsverbesserungen oder alternative Implementierungen von SE zu ermöglichen. Die SE-Architektur hängt von dem Page-Miss-Handler (PMH) ab, um unautorisierte Zugriffe auf die Enklavenseiten zu verhindern, die in den Enllavenseiten-Cache geladen sind. Der PMH detektiert verschiedene Ereignisse und berichtet diese Ereignisse zurück an den Mikrocode. Der Mikrocode kann ein Ereignis an das BS/den VMM berichten. Das BS/der VMM kann dann geeignete Befehle ausführen, um den Fehler zu beheben.
Wenn eine Enklave mittels des ECREATE-Befehls erzeugt ist, wird ein linearer Adressbereich für diese Enklave spezifiziert. Dieser Bereich wird der lineare Adressbereich für diese Enklave genannt. Alle Speicherseiten, die zu dem linearen Adressbereich der Enklave gehören, werden als unter dem Schutz der Enklave stehend angesehen und haben SEC_INFO-Einträge, die ihnen zugeordnet sind.
Auf Speicherseiten, die zu dem linearen Adressbereich einer Enklave gehören, wird ebenfalls als Enklavenseiten Bezug genommen. Einem Programm, das innerhalb einer Enklave ausführt, ist es erlaubt, auf die Enklavenseiten nur dann zuzugreifen, wenn diese Seiten in den Enklavenseiten-Cache geladen sind und es die Enklave ist, der die Seite gehört. Der Prozessor wird ein Ereignis einer Ausnahmenklasse generieren, wenn dies nicht der Fall ist. Es liegt in der Zuständigkeit des BS/VMM, sicherzustellen, dass die Enklavenseiten, wie benötigt, in den EPC geladen werden.
Wenn ein logischer Prozessor eine Enklave ausführt und er einen Speicherzugriff auf seine Enklavenseite generiert, dann wird auf einen solchen Speicherzugriff als ein Enklavenzugriff Bezug genommen. Die Adresse kann geprüft werden, um sicherzustellen, dass auf sie von der richtigen Entität zugegriffen worden ist.
In einer Ausführungsform stellt der PMH eine Zugriffskontrollfunktionalität bereit, um den EPC zu schützen, wenn ein Programm nicht in einer Enklave ausführt. Ein Bereichsregister, das für jeden Prozessor aktiviert ist, wird einen Zugriff auf den EPC beschränken, wenn der Prozessor keinen Enklavencode ausführt. Dieses Bereichsregister ist deaktiviert, wenn der Prozessor mit dem Ausführen von Enklavencode beginnt. An seinem Ort führt der Prozessor spezielle Seitentabellen ein. Diese Seitentabellen werden von dem Prozessor kontrolliert und erlauben nur Zugriff auf EPC-Seiten, die dieser Enklave gehören. Der Prozessor und ein Mikrocode beschränken den Zugriff auf den EPC mittels dieser zwei Mechanismen.

In einigen Ausführungsformen kann ein Kompromiss oder Tradeoff zwischen vielen Faktoren oder Achsen durchgeführt werden, aufweisend Leistungsfähigkeit, Implementierungskomplexität und Siliziumkosten. In diesem Kapitel werden drei mögliche Implementierungen beschrieben, sodass Entwickler einige der möglichen Tradeoffs verstehen können. Die untere Tabelle 8-1 zeigt diese möglichen Schutzmaßnahmen und die benötigte PMH-Unterstützung. Tabelle 8-1: PMH-Unterstützungsoptionen

Implementierung	Minimale PMH-Unterstützung
Unterstützung von minimaler Hardware: Sichere Enklave innerhalb einer MikrocodeErweiterung	Unterstützung von physikalischen Bereichsregistern, um Zugriffe auf den EPC oder die CMA zu schützen
Unterstützung von minimaler Hardware für Mikrocode: SE mit PMH-Zusätzen	Unterstützung von physikalischen Bereichsregistern, um Zugriffe auf den EPC oder die CMA zu schützen. Prüfung von linearen Adressen für Zugriff innerhalb einer Enklave, siehe Anhang 3 für weitere Informationen
Unterstützung von robuster Hardware für Mikrocode oder Mikrocode-Erweiterungen: Implementierung mit umfangreicher PMH-Unterstützung	Unterstützung von physikalischen Bereichsregistern, um Zugriffe auf den EPC oder die CMA zu schützen. Prüfung von linearen Adressen für Zugriff innerhalb der Enklave, siehe Anhang 3 für weitere Informationen

Wie in der ersten Zeile von Tabelle 8-1 gezeigt ist, wird genau ein zusätzliches Bereichsregister benötigt, um die benötigten Zugriffskontrollschutzmaßnahmen bereitzustellen. In dieser bestimmten Implementierung werden die anderen Schutzmaßnahmen durch Mikrocode-Erweiterungen bereitgestellt. Das Bereichsregister kann auf einer Basis eines logischen Prozessors freigegeben sein. Die Grundimplementierung, die diesen Mechanismus verwendet, ist in 2-2 gezeigt.
Der PMH ist modifiziert, um Zugriffe auf den CMA-Bereich (der durch CMRR in der CPU abgedeckt ist) von LPs auszuschneiden, die weder im erweiterten Mikrocode-Modus noch im Enklavenmodus laufen. Zusätzlich ist es LPs, die im Enklavenmodus laufen, nur erlaubt, auf den EPC-Teilbereich der CMA zuzugreifen.
15 stellt in einer Ausführungsform der Erfindung dar, wie eine Seiten-Fault-Fehlercodeabbildung implementiert sein kann. Wenn Bit 5 1540 gesetzt ist, können Bit 9, Bit 8, Bit 7 und Bit 6 zusammen decodiert werden, um die Seiten-Fault-Fehlercodes zu bestimmen. Die res-Bits 1512, das I/D-Bit 1514, das RSVD-Bit 1516, das U/S-Bit 1518, das W/R-Bit 1520, das P-Bit 1522.
Wenn eine Seite im EPC nicht präsent ist, wird ein Fault an das BS/den VMM geliefert, um diese Tatsache anzugeben. Die Seiten-Fault-Fehlercodeabbildung wird wie in Tabelle 8-2 gezeigt abgeändert. Dies gibt die neuen Bits an, die verwendet werden, um die Fehlerbedingung zu berichten. Falls kein EPC-Fault vorliegt, wird Bit 5 auf Null gesetzt und Bits 6 bis 9 sind ebenfalls Null. Falls der Fault aufgrund einer EPC-Bedingung auftritt, dann wird Bit 5 gesetzt und die Software kann Bits 6 bis 9 decodieren, um die EPC-Fehlerbedingung zu verstehen. Weitere Informationen über die Fault-Typen sind im nächsten Abschnitt beschrieben.

Wenn Bit 5 des Seiten-Fault-Fehlercodes gesetzt ist, werden Bits 6 bis 9 wie in Tabelle 8-2 angegeben interpretiert. Dies zeigt die Bedingung, die das Auftreten des Seiten-Faults verursacht hat. Einige der Zustände geben eine illegale Bedingung an, die im normalen Betrieb nie auftreten muss. Sie geben einen BS/VMM-Verwaltungsfehler an. Tabelle 8-2: Seiten-Fault-Fehlercodes

EPCF-Code	Definition
0	Ein Zugriff auf eine EPC-Stelle trat auf, die nicht Teil der aktuellen Enklave war oder wenn nicht im Enklavenmodus ausgeführt wird
1	Adresse einer Seite innerhalb der linearen Adresse der Enklave bildet nicht auf eine EPC-Stelle ab
2	Die EPC-Seite ist als nicht präsent markiert
3	Die EPC-Seite, auf die zugegriffen wird (die gegen EPCM geprüft wird), ist nicht Teil der Enklave, die ausgeführt wird
4	Die EPC-Seite, auf die zugegriffen wird, hat nicht dieselbe lineare Adresse wie die Referenz (geprüft gegen EPCM)
5	Post-EINIT: Die EPC-Seite wurde der Enklave hinzugefügt, wurde jedoch nicht von der Enklaven-Software akzeptiert
6	Eine Enklavenseite wurde in den EPC geladen, jedoch wurde die Versionsnummer der Integrität nicht aktualisiert
7	Ein Schreibvorgang wurde auf einer Enklavenseite versucht, die keine Schreibgenehmigung hat.
8	Ein Lesevorgang wurde auf einer Enklavenseite versucht, die keine Lesegenehmigung hat
9	Ein Holen von Befehlen wurde auf einer Enklavenseite versucht, die keine Ausführgenehmigimg hat
A	Eine Enklave versuchte, auf die SECS zuzugreifen. Der Zugriff ist verboten
B	Eine Enklave versuchte, auf die TCS zuzugreifen. Der Zugriff ist verboten.

Um den EPC vor einem Angriff zu schützen, kann ein Mechanismus vorgesehen sein, der EPC-Adressen in allen TLBs auf der Plattform für ungültig erklärt. Dieses Merkmal kann an alle Kerne signalisieren, dass eine bestimmte Seite für ungültig zu erklären ist. Es kann dann warten, bis alle Prozessoren eine Angabe darüber zurückgeben, dass das Shoot-Down abgeschlossen ist.
Sobald ein Ausstieg aus einer Enklave, EEXIT, auftritt, muss der TLB Zugriffe auf die Enklavenseiten, die aktuell im TLB präsent sind, nicht erlauben. Dies kann durch Löschen des TLB oder durch Verwenden von zusätzlichen Bits zum Auszeichnen der Enklaveneinträge gemacht werden.
Eine Alternative besteht in der Verwendung eines Enklavenbits in dem TLB, wobei beim Ausstieg aus der Enklave alle Enklaveneinträge gelöscht werden. Eine andere Alternative besteht in der Verwendung von mehreren Bits, um eine bestimmte Enklave zu identifizieren. In diesem Fall müssen die Enklaveneinträge nicht ausgeräumt werden. Die Enklaveneinträge können in dem tlb belassen werden. Wenn eine Adresse an den tlb zum Nachschlagen gesendet wird, werden diese Bits an das Nachschlagen angefügt. Diese Bits werden mit einer Enklaven-ID aus dem Kern verglichen, die die Enklavenidentität angibt. Wenn die Bits übereinstimmen, dann kam die Anforderung von derselben Enklave. Wenn der Abgleich fehlschlägt, dann kam die Anforderung nicht von dieser bestimmten Enklave und das Nachschlagen wird keinen Hit für diese Stelle liefern.
Die Enklavenauthentifikation stellt Mittel zum Bestimmen der Instanz oder Autorität bereit, die den Enklavencode für das Ablaufen innerhalb einer Enklave lizenziert hat, welche der Autor/die Freigabestelle dieses Codes ist. Die Enklavenauthentifikation stellt ebenfalls eine Grundlage bereit, um Enklavenmikrocodeflüsse auszugliedern, für flexibles Versiegeln & Berichten, sowie einen Durchsetzungspunkt für eine Anzahl von neuen Geschäftsmodellen.
Bestimmte Aspekte der Architektur von sicheren Enklaven erfordern komplexe, Zeit raubende Abläufe, die nicht für eine Implementierung innerhalb von mikrocodierten Befehlen geeignet sind. Die Lösung besteht darin, diese Abschnitte der Architektur von sicheren Enklaven in Makrocode auszugliedern. In vielen Fällen erfordert der ausgegliederte Code einen Sonderzugriff auf sensible Prozessor- oder Plattformdaten. Beispielsweise ist ein EPID-Signieren für einen einzelnen Befehl zu lang. Stattdessen wird eine Notierungsenklave verwendet, um EPID-signierte Notierungen zu erzeugen, durch Gewähren eines Sonderzugriffs auf den privaten EPID-Schlüssel. Die Enklavenauthentifikation ermöglicht Intel, die zusätzlichen Fähigkeiten zu spezifizieren, die spezifischen Enklaven gewährt werden, wie zum Beispiel ein Zugriff auf den EPID-Schlüssel nur durch die Notierungsenklave. Auf Enklaven, die von Intel bereitgestellt werden, welche zusätzliche Fähigkeiten haben und die Enklaven-Kernfunktionalität implementieren, wird als architektonische Enklaven Bezug genommen.
Ein enklavenversiegelter Speicher versetzt Enklaven-Software in die Lage, Daten für bestimmte Attribute der Enklave zu verschlüsseln, wie zum Beispiel ihre Ladezeitmessung. Ein Enklavenbeglaubigungs-Framework erlaubt es einer Enklave, Nachweise der Enklavenmessung an eine externe Partei zu liefern. In vielen Fällen ist es statt des genauen Software-Hash der Enklave eher wünschenswert, Daten zu versiegeln oder an die Quelle der Enklave zu attestieren.
In einer Ausführungsform wird, sobald die Signatur auf einer authentifizierten Enklave verifiziert ist, der öffentliche Teil des Schlüssels, der zum Signieren der Enklave verwendet wird, den Versiegelungs- & Beglaubigungs-Mechanismen verfügbar gemacht, wodurch ein Verkäufer in die Lage versetzt wird, zwischen dem rigiden Schutz basierend auf der Enklavenmessung oder einem flexibleren Schutz basierend auf der Quelle des Enklavencodes zu wählen.
Die Enklavenauthentifikation ist auf zwei Teile aufgeteilt. Jede Enklave wird von einer Enklavenlizenz mit einer Signaturkette begleitet, die auf Intel rückführbar ist. Die Enklavenlizenz gibt an, wer die Ursprungs- oder verantwortliche Entität für die Enklave ist, jede Sonderfähigkeit, die die Enklave benötigt, und jede zusätzliche Information, die zum Identifizieren des bestimmten Geschäftsmodells/Abkommens benötigt wird, die diese Enklave möglich gemacht haben. Eine Lizenz kann für eine spezifische Enklave sein, die die Messung dieser Enklave angibt, oder sie kann für einen Schlüssel sein, dem es dann erlaubt ist, Enklaven nach Bedarf zu signieren.
Beispielsweise könnte A eine Lizenz kaufen, die ihn autorisiert, Enklaven zur Verwendung in einem Videoplayer von A zu erzeugen. Um dies zu tun, würde Intel eine Lizenz für den Stammschlüssel (Root Key) des Videoplayers des Verkäufers A zusammen mit Fähigkeiten erstellen, die Intel dem Verkäufer A genehmigt, in Videoplayer-Enklaven zu verwenden. Der Verkäufer A wird dann den Stammschlüssel des Videoplayers verwenden, um individuelle Lizenzdateien für jede Videoplayer-Revision zu signieren, die er freigibt. Dies erzeugt eine Lizenzkette für die Enklave, die mehrere Zwischenlizenzen umfassen kann.

Eine Kette von signierten Lizenzen ist für die Evaluierung während des Startprozesses der Enklave nicht optimal, sodass sie stattdessen in einer einzelnen befehlsverwertbaren Struktur kombiniert werden, die Permit (Genehmigung) genannt wird. Permits sind mittels des CMAC-Algorithmus symmetrisch authentifiziert und werden während der Initialisierung (EINIT) der Enklave interpretiert. Tabelle 11-1: Enklavenlizenz-Struktur (Hält das Ucode-Patch-Format ein)

Offset (Bytes)	Länge (Bytes)	Name	Signiert?	Beschreibung
0	4	License Version	Nein	Strukturversion für diese Lizenz
4	4	Header Size	Nein	Größe des Headers (unsignierter Abschnitt von cert)
8	4	Body Size	Nein	Größe des Hauptteils (signierter Abschnitt)
12	4	Algorithm	Nein	Asymmetrischer Algorithmus, der zum Signieren verwendet wird 0x00000001: RSA
16	4	Key Size	Nein	Schlüsselgröße in Bits
20	4	Pub Key Size	Nein	Größe des öffentlichen Schlüssels in Dwords
24	4	Exponent	Nein	Exponent des Signierschlüssels
28	36	RESERVIERT	Nein	Reserviert-MBZ
64	256	Pub Key	Nein	Öffentlicher Schlüssel des Signierers
320	256	Signature	Nein	Signatur eines Zertifikats
576	8	LicenseID	Ja	Lizenzvertrag-ID
584	2	LicenseType	Ja	Lizenztyp 0x0000: Bulk 0x0001: Pro Plattform
586	2	LicenseAuthorityID	Ja	ID der Lizenzinstanz zum Freigeben
588	4	LicenseReserved	Ja	MBZ-Reserviert
592	4	ISV SVN	Ja	ISV-zugeordnete Sicherheitsversionsnummer
596	2	Flags	Ja	Flags, die in einer Enklave eingeschaltet werden können
598	10	Reserviert	Ja	MBZ-Reserviert
608	16	Capabilities	Ja	Bitmaske von verfügbaren Fähigkeiten
624	32	EntityHash	Ja	Hash eines lizenzierten PubKey oder Enklaven-MR.EADD
656	3440	RESERVIERT	Nein	Reserviert-MBZ

Tabelle 11-2: Permit-Struktur

Offset (Bytes)	Länge (Bytes)	Name	Beschreibung
0	8	LicenseID	Lizenzvertrag-ID
8	2	LicenseType	Lizenztyp 0x0000: Bulk 0x0001: Pro Plattform
10	2	LicenseAuthorityID	ID der Lizenzinstanz zum Freigeben
12	4	LicenseReserved	MBZ-Reserviert
16	4	ISV SVN	ISV-zugeordnete Sicherheitsversionsnummer
20	2	Flags	Flags, die in einer Enklave eingeschaltet werden können
22	10	Reserviert	MBZ-Reserviert
32	16	Capabilities	Bitmaske von verfügbaren Fähigkeiten
48	16	ParentKeyHash	Hash, der Schlüssel für Lizenzkette signiert
64	32	EntitiyHash	Hash eines lizenzierten PubKey des Enklaven-MR.EADD
96	16	KeyID	Schlüssel-ID zum Ableiten des Genehmigungs- & Lizenzschlüssels
112	16	RESERVIERT	Reserviert für MAC-Erweiterung auf 256 Bit
128	32	cpuMAC	MAC, der einen Genehmigungsschlüssel verwendet
160	32	licenseMAC	MAC, der einen Lizenzschlüssel verwendet (Nur benötigt, wenn LicenseType != 0 ist)
192	3440	RESERVIERT	Reserviert-MBZ

Die meisten Elemente der Lizenz werden in die Genehmigung (Permit) kopiert, was ähnliche Strukturen ergibt. Die License ID ist eine 64-Bit-Zahl, um ein Geschäftsabkommen zu identifizieren. Der Lizenztyp identifiziert, auf welche Plattformen diese Lizenz anwendbar ist. Eine Bulk-Lizenz erlaubt dieser Enklave, auf einer beliebigen Plattform, die sichere Enklaven unterstützt, gestartet zu werden. Eine Pro-Plattform-Lizenz erfordert, dass die Plattform zuerst die angezeigte Lizenzinstanz kontaktiert und eine Erlaubnis anfordert, die Enklave zu starten. Sobald die Erlaubnis eingerichtet wurde, ist kein weiterer Kontakt mit der Lizenzinstanz erforderlich, jedoch erlaubt dies der Lizenzinstanz, die Anzahl von Plattformen, an die diese Enklave ausgeliefert wird, für Abrechnungszwecke nachzuverfolgen. Der ISV, der diese Enklave lizenziert hat, kann sich dafür entscheiden, eine Sicherheitsversionsnummer für diese Version der Enklave einzurichten. Hierdurch können Daten, die mit dieser Version versiegelt sind, für zukünftige Versionen verfügbar gemacht werden, jedoch nicht für vorhergehende Versionen. Das Flags-Feld gibt Flags für die Enklave an, die gesetzt werden können, damit diese Genehmigung anwendbar ist. Die Fähigkeitsmaske ist eine Bitmaske der Sonderfähigkeiten, die dieser Enklave verliehen werden können. Das ParentKeyHash ist der Hash des öffentlichen Schlüssels, der diese Lizenz der Enklave signiert hat, gehasht mit dem öffentlichen Schlüssel, der diesen Schlüssel signiert hat. EntitiyHash ist der erwartete Hash der Entität, auf die diese Lizenz anwendbar ist. Im Fall einer Enklave ist dies der Wert von MR.EADD für die ordnungsgemäß konstruierte Enklave. Für einen Lizenzierungsschlüssel ist dies der Hash des öffentlichen Schlüssels.
In einer Lizenz ist der öffentliche Schlüssel, der zum Signieren der Lizenz verwendet wird, in der Lizenz selbst enthalten. Die Genehmigung wird unter Verwendung von CPU-Schlüsseln geMACt. Ein richtiger cpuMAC gibt an, dass der EMKPERMIT-Befehl diese Genehmigung nach einem Validieren der Lizenzkette zurück auf Intel erstellt hat. Wenn der LicenseType nicht Bulk ist, dann gibt ein licenseMAC an, dass die architektonische Lizenzenklave die zutreffende Lizenzinstanz kontaktiert hat und eine Bestätigung erhalten hat, dass diese Plattform die Enklave starten darf.
Nicht alle Enklaven erfordern eine Genehmigung. Um die Entwicklung von Enklaven zu vereinfachen, werden Genehmigungen während der Entwicklungs- und Debug-Phasen in dem Lebenszyklus der Software optional sein. Die folgenden Richtlinien werden durch EINIT durchgesetzt. Nicht-Debug-Enklaven benötigen zum Starten immer eine Genehmigung. Debug-Enklaven werden ohne eine Genehmigung starten. Jedoch werden, falls EINIT keine Genehmigung präsentiert wird, MR.Policy, ISV Sec Version, Permit Sec Version und Capabilities alle auf 0 gesetzt sein.
Wenn eine Genehmigung verwendet wird, um eine Debug-Enklave zu starten, kann permit->Flags[DEBUG] gesetzt sein und nur Fähigkeiten, die von Debug-Enklaven erlaubt sind, können in der Genehmigung gesetzt sein.
16 stellt ein Beispiel eines Verfahrens zum Erzeugen einer Genehmigung, um eine Enklave zu starten, in einer Ausführungsform der Erfindung dar. Das Verfahren kann drei Stufen haben: Ausgeben einer Genehmigung 1600, zusätzliche Lizenzfreigabe 1640 und Initialisierung einer Enklave 1680. In der Stufe der Genehmigungsausgabe 1600 kann die ISV-Schlüsselgenehmigung 1615 durch Durchführen eines EMKPERMIT-Befehls 1612 auf der ISV-Schlüssellizenz 1610 generiert werden. Die Enklavengenehmigung mit einem MAC nur für eine CPU 1625 kann durch Durchführen eines EMKPERMIT-Befehls 1612 auf der Enklavenlizenz 1620 und der ISV-Schlüsselgenehmigung 1615 generiert werden. In der Stufe der zusätzlichen Lizenzfreigabe 1640 steigen die Enklavengenehmigung mit einem MAC nur für eine CPU 1625 und die Fremdenklave, die den zu lizenzierenden Informationen 1642 entspricht, in die Lizenzenklave 1644 ein und die Lizenzenklave 1644 generiert die Enklavengenehmigung mit einem MAC für eine CPU und eine Lizenz 1645. In der Stufe der Initialisierung der Enklave 1680 können die Enklaven-SECS 1682 und die Enklavengenehmigung mit dem MAC für die CPU und die Lizenz 1645 die Eingaben für den EINIT-Befehl 1684 sein. Die Ausgabe des EINIT-Befehls 1684 ist die ISV-Enklave 1685.
Um eine Enklave zu starten, kann eine Genehmigung aus der Lizenz, die mit der Software ausgeliefert wird, erstellt werden und dann an die CPU geliefert werden, um die Enklave zu starten. Dieses Verfahren wird in drei aufgebrochen: Ausgeben einer Genehmigung, zusätzliche Lizenzfreigabe und Enklaveninitialisierung. 16 stellt den Ablauf in diesem Verfahren dar.
Ein neuer Befehl, EMKPERMIT, wird verwendet, um eine Genehmigung aus einer Lizenz zu erstellen. EMKPERMIT erstellt eine einzelne Genehmigung aus einer einzelnen Lizenz, kann jedoch nacheinander aufgerufen werden, um eine Kette von Lizenzen in eine einzelne Genehmigung mit einem MAC unter Verwendung des Genehmigungsschlüssels zu konvertieren. Der nächste Abschnitt wird dies detaillierter beschreiben.
Jede Lizenz weist einen Lizenztyp auf, der bestimmt, welche zusätzlichen Schritte vorgenommen werden können, damit die Genehmigung verwendbar ist. Pro-Plattform-Lizenzen erfordern, dass eine Lizenzinstanz in der Wolke oder Cloud eine Abrechnungszählung von Plattformen pflegt, auf denen die Enklave ausgeliefert ist. Für Lizenzen dieses Typs ist ein zusätzlicher Schritt notwendig. Eine architektonische Enklave, die die Lizenzenklave genannt wird, wird mit der Lizenzinstanz in der Cloud verhandeln und wird bei einer Freigabe einen zusätzlichen MAC auf der Genehmigung mittels des Lizenzschlüssels bereitstellen. Architektonische Enklaven sind zum Beispiel immer Bulk-Lizenzen, was bedeutet, dass sie nicht den Lizenzschlüssel-MAC benötigen, um laufen zu können. Sie arbeiten auf einer beliebigen Plattform, die sichere Enklaven unterstützt.
Genehmigungen werden bei der Enklaveninitialisierung durchgesetzt. Während der Initialisierung wird die Genehmigung verarbeitet und wenn die Enklavenabmessung mit der in der Genehmigung übereinstimmt und die MACs richtig sind, startet die Enklave. EINIT wird auf den Lizenztyp schauen und den Lizenz-MAC nur bei Lizenzen inspizieren, die eine zusätzliche Freigabe benötigen.
EMKPERMIT ist aufgrund der Zeit, die benötigt wird, um die RSA-Signatur auf der Lizenz zu verifizieren, ein privilegierter Befehl. Dieser Befehl nimmt sehr einfach signierte Anmeldeinformationen, die das uCode-Patch-Format einhalten, verifiziert sie und erzeugt eine Genehmigung aus ihren Inhalten. Die Lizenz umfasst sowohl eine Signatur als auch den öffentlichen Abschnitt des Schlüssels, der verwendet wurde, um sie zu signieren. Dies ermöglicht einem uCode lediglich einen Hash des Lizenzsignierschlüssels von Intel zu speichern und in der Lage zu sein, von Intel signierte Lizenzen zu validieren. EMKPERMIT kann ebenfalls Lizenzen validieren, die mit ISV-Schlüsseln signiert sind, durch Bereitstellen einer authentifizierten Freigabe ihrer Schlüssel. Dies wird durch Erstellen einer Genehmigung gemacht, die einen Hash des öffentlichen Schlüssels des ISV enthält. Das Ergebnis besteht darin, dass EMKPERMIT Intel-Lizenzen mittels eines internen Hash oder ISV-Schlüssel mit einem Hash verifizieren kann, der in einer zweiten Genehmigung bereitgestellt ist.
EMKPERMIT nimmt 3 Parameter: einen Zeiger auf eine Lizenz, einen optionalen Zeiger auf eine Schlüsselgenehmigung und einen Zeiger auf eine Ausgabegenehmigung. Für von Intel signierte Lizenzen ist die Schlüsselgenehmigung Null und ein intern fest codierter Satz von Genehmigungsparametern wird verwendet. Die aufrufende Methode wird verwendet, um eine Lizenz einer architektonischen Enklave zu validieren und eine Genehmigung für sie zu erzeugen. EMKPERMIT stellt sicher, dass der öffentliche Schlüssel in der Lizenz durch den uCode autorisiert ist (durch Vergleichen des Hash des enthaltenen öffentlichen Schlüssels mit dem internen Hash).
Im Fall eines ISV wird ein Schlüssel des ISV eine Lizenz haben, die von Intel signiert ist. Ein Aufrufen von EMKPERMIT ohne eine Schlüsselgenehmigung wird den Intel-Schlüssel-Hash verwenden, um die Signatur der Lizenz zu verifizieren und eine Genehmigung zu erstellen, die den Hash des ISV-Schlüssel dazu autorisiert, einen legitimen Lizenzsignierschlüssel darzustellen. EMKPERMIT wird dann ein zweites Mal mit der Genehmigung des Schlüssels des ISV aufgerufen. EMKPERMIT validiert den MAC der Schlüsselgenehmigung und verwendet dann den Hash des ISV-Schlüssels, wo es vorher den Intel-Hash verwendet hat. Vorausgesetzt, dass der öffentliche Schlüssel in der Enklavenlizenz auf den Wert in dem ISV-Schlüssel hasht und dass die Enklavenlizenz damit ordnungsgemäß signiert ist, wird EMKPERMIT eine Genehmigung für die Enklave erzeugen. Diese Genehmigung gibt die Lizenzinformationen (die über die gesamte Kette hinweg konsistent sein können), den Hash von allen öffentlichen Schlüsseln in der Lizenzkette, die Abmessung der Enklave und ihre Fähigkeiten an.
Die folgenden Schritte werden von dem u-code während EMKPERMIT unternommen:

1. Kopiere Parameter in Notizblock (um gegen Race-Condition-Angriffe zu schützen)
2. Berechne Hash von öffentlichem Schlüssel (Public Key) in Lizenz.
3. Wenn Schlüsselgenehmigung (Key Permit) == Null, a. Verifiziere, dass der Hash des öffentlichen Schlüssels der Lizenz = Intel-Schlüssel-Hash ist, oder schlage fehl.
4. Sonst a. Validiere MAC der Schlüsselgenehmigung mittels Genehmigungsschlüssel (Permit Key) b. Verifiziere, dass der Hash des öffentlichen Schlüssels der Lizenz = EntityHash der Schlüsselgenehmigung ist, oder schlage fehl.
5. Validiere Signatur von cert mit PubKey.
6. Stelle sicher, dass Lizenzinfo, Fähigkeiten und Flags zwischen Lizenz und Schlüsselgenehmigung konsistent sind.
7. Erstelle Genehmigung mit: a. PubKeyHash = Hash(KeyPermit.Hash, Hash(License Pub Key)) b. Capabilities = KeyPermit.Capabilities & License.Capabilities c. Measurement = License.Measurement d. ISV SVN = SVN der Lizenz. e. Flags = Flags der Lizenz
8. KeyID = aktuelle KeyID in dem Kern
9. cpuMAC = CMAC, berechnet mittels Genehmigungsschlüssels
10. licenseMAC = 0x0000...0000

Die Lizenzenklave ist derart entworfen, Entscheidungen über einen Enklavenstart außerhalb des Sichtbarkeitsbereichs für uCode zu treffen. Beispielsweise kann uCode nicht evaluieren, ob Geschäftsverbindungen eines ISV mit Intel eine zusätzliche Enklavenauslieferung erlauben. Die Lizenzenklave ist derart entworfen, jedwedes Material zu sammeln, das notwendig ist, um eine Bewertung zu machen, und entweder weiter den Enklavenstart freizugeben oder ein Veto dagegen einzulegen. Von der Lizenzenklave wird lediglich gefordert, dass sie komplexe Geschäftsverbindungen unterstützt, und sie wird nicht für Bulk-Lizenzen benötigt, wie zum Beispiel die Befähigung, die Enklave auf einer beliebigen Plattform so oft wie nötig zu starten.
Von der Lizenzenklave wird erwartet, dass sie ein Systemdienst ist. Wenn eine Lizenz angibt, dass sie eine weitere Freigabe von der Lizenzenklave benötigt hat, wird die Kette von Lizenzen und die Enklavengenehmigung, die von EMKPERMIT erstellt sind, an die Lizenzenklave weitergegeben. Die Lizenzenklave generiert dann eine Freigabeanforderung. Die Anwendung sendet dann diese Freigabeanforderung an die zutreffende Lizenzinstanz, die eine Freigabenotiz generiert. Dies wird in die Lizenzenklave zurückgegeben und die Lizenzenklave verwendet den Lizenzschlüssel, um die Genehmigung in dem licenseMAC-Feld zu MACen.
Sobald eine Genehmigung für eine Enklave ausgegeben ist, kann sie evaluiert werden und von u-code in dem Enklavenstartprozess durchgesetzt werden. Dies wird als Teil des EINIT-Befehls gemacht, das die lineare Adresse der Genehmigung als einen Parameter nimmt. Die folgenden zusätzlichen Schritte werden zu EINIT als Teil des Mechanismus der authentifizierten Enklaven hinzugefügt.

1. Kopiere Genehmigung in Notizblock
2. Verifizierte cpuMAC auf der Genehmigung mittels des Genehmigungsschlüssels
3. Wenn LicenseType != Bulk, verifiziere licenseMAC mittels des Lizenzschlüssels
4. Vergleiche Abmessung in Genehmigung mit MR.EADD in SECS.
5. Vergleiche Flags in Genehmigung mit Flags in SECS.
6. Kopiere Pubkey-Hash aus Genehmigung in MR.Policy.
7. Kopiere ISV SVN nach SECS
8. Kopiere Fähigkeitsabbildung aus Genehmigung in SECS

Fähigkeiten (Capabilities)

Die aktuelle Fähigkeitenabbildung ist eine 128-Bit-Maske von Fähigkeiten, die dieser Enklave zur Verfügung stehen. Tabelle 11-3: Capability-Bit-Tabelle

Bit	Name	Debug	Beschreibung
00	RESERVIERT-MBZ	Nein	Reserviert für Aktivieren von Ring-Kontrollen (nicht Gen 1)
01-02	RESERVIERT-MBZ	Nein	Reserviert für autorisierten Enldaveneintritt auf Ringstufe (nicht Gen 1)
03	RESERVIERT-MBZ	Nein	Reserviert dafür, dass Enklave im VT-Root-Modus ausführen kann (nicht Gen 1)
04	RESERVIERT-MBZ	Nein	Reserviert für Deaktivieren von verschlüsselten ausführbaren Seiten (nicht Gen 1)
05	RESERVIERT-MBZ	Nein	Reserviert für Erlauben von verschlüsselten nicht ausführbaren Seiten (nicht Gen 1)
06	RESERVIERT-MBZ	Nein	Reserviert für Erlauben von EADD von ausführbaren Seiten nach EINIT (nicht Gen 1)
07	RESERVIERT-MBZ	Nein	MBZ: RESERVIERT für Speicherschutzmaßnahmen
08	KEY_PROVISION	Ja	1: Gebe Zugriff auf Versorgungsschlüssel frei
09	KEY_LICENSE	Ja	1: Gebe Zugriff auf Lizenzschlüssel frei
10	KEY_REPORT	Ja	1: Gebe Zugriff auf Berichtschlüssel frei
11	KEY_ISV_AUTH	Ja	1: Gebe Zugriff auf den ISV-Auth-Schlüssel frei
12	KEY_OOB	Ja	1: Gebe Zugriff auf OOB-Schlüssel frei
13	KEY_EPID	Nein	1: Gebe Zugriff auf abgesicherten EPD-Schlüssel frei
14	KEY_EPID_ID	Nein	1: Gebe Zugriff auf EPID ID frei
15-23	RESERVIERT	Nein	MBZ: RESERVIERT für EGETKEY-Kontrollen
24	CL_NAMEBASED	Ja	1: Der Enklave ist erlaubt, mittels einer Namenbasis zu attestieren
25-127	RESERVIERT	Nein	RESERVIERT

Der Raum wird auf der Grundlage der Aktion organisiert, die von EINIT vorzunehmen ist. Bits 00–03 sind für eine zukünftige Verwendung reserviert, wenn Ringstufenbeschränkungen auf dieser Enklave aktiv sind. 04-07 sind reserviert, um anzugeben, welche Seitenschutzmaßnahmen zukünftig erlaubt sein werden. 08-23 sind Prozessorschlüssel, die durch EGETKEY verfügbar sind. 24-31 sind für andere Kontrollen, wie zum Beispiel Verwenden eines namensbasierten Modus zur Beglaubigung oder für zukünftige Technologien, die wir beschränken wollen. Bestimmte Fähigkeiten müssen von einer Enklave im Debug-Modus nie verwendet werden. Die Debug-Spalte gibt an, ob eine Fähigkeit im Debug-Modus legal zu verwenden ist.
In zukünftigen Generationen kann das Bit 00 angeben, dass Ringstufen- und VT-Beschränkungen auf diese Enklave anwendbar sind. Die Bits 01–02 geben an, auf welcher Ringstufe es der Enklave erlaubt ist, zu laufen, und das Bit 02 gibt an, ob die Enklave im VT-Root-Modus läuft oder nicht. Bei jedem EENTER kann die aktuelle CPL mit den Bits 01–02 verglichen werden, um zu bestimmen, ob es dieser Enklave erlaubt ist, auf dieser Ring-Stufe auszuführen. Wenn ein Versuch unternommen wird, sie auf dem falschen Ring auszuführen, wird EENTER fehlschlagen. Wenn Ringbeschränkungen aktiv sind, kann gleichermaßen in die Enklave nur aus einem VT-Root-Modus eingestiegen werden, wenn Bit 03 an ist. In den ersten Generationen sind diese Bits MBZ.
Enklavenseiten können verschlüsselt sein oder lediglich integritätsgeschützt sein. Seiten können ebenfalls ausführbar sein oder nicht. In zukünftigen Generationen können diese Attribute nachverfolgt werden und in dem Sicherheitsinfo-Abschnitt der EPCM durchgesetzt werden. Diese Fähigkeitsbits sind reserviert, um die Anwendung von Verschlüsselung auf Enklavenseiten in der Enklave auf der Grundlage davon zu kontrollieren, ob die Seite ausführbar ist und ob die Enklave bereits EINIT wurde.
Viele architektonische Enklaven sind Ring 3-Entitäten, die einen Zugriff auf Schlüssel benötigen, die innerhalb oder von der CPU geschützt sind. EGETKEY stellt einen Zugriff auf diese Schlüssel bereit, wobei die Fähigkeitsbits von EGETKEY verwendet werden, um zu entscheiden, ob der Zugriff auf den Schlüssel freigegeben werden kann.
Das Folgende ist eine Auflistung der aktuellen architektonischen Enklaven mit ihren Eigenschaften und kurzen Beschreibungen.
Die Versorgungsenklave (Provisioning Enclave), welche mit Fähigkeiten KEY_PROVISION ausgestattet ist und von Intel autorisiert ist, läuft auf einer Einzelbaugruppenplattform immer dann ab, wenn ein neuer Vorrichtungsbeglaubigungsschlüssel (Device Attestation Key, DAK) oder ein Versorgungsbeglaubigungsschlüssel (Provisioning Attestation Key, PAK) benötigt wird. Ihr Zweck besteht darin, der Enklave zu erlauben, einen Device-ID & Versorgungsschlüssel basierend auf dem Versorgungs-Seed abzuleiten, der von EGETKEY bereitgestellt wird. Die Versorgungsenklave verwendet dann diese Schlüssel, um die Authentizität der Plattform gegenüber einem Versorgungs-Server nachzuweisen und ruft einen Vorrichtungsbeglaubigungsschlüssel (DAK) ab. Nach dem Abrufen des DAK versiegelt ihn die Versorgungsenklave, sodass ihn die Notierungsenklave abrufen kann. Die Versorgungsenklave kann dann optional den DAK verwenden, um sich bei einem Provider eines Plattformbeglaubigungsschlüssels (Platform Attestation Key, PAK) zu authentifizieren, und einen PAK erneut versuchen. Das Verwenden eines PAK verbessert die Privatsphäre der Benutzer durch Sicherstellen, dass im Hinblick auf einen bestimmten ISV, ihre Aktivitäten nicht denen eines vorhergehenden Besitzers dieser Plattform zugeordnet werden können. Nach dem Abrufen des PAK versiegelt ihn die Versorgungsenklave, sodass die Notierungsenklave ihn abrufen kann.
Die Notierungsenklave (Quote Enklave), welche mit Fähigkeiten KEY_REPORT ausgestattet ist und von der Enklave autorisiert ist, hat denselben Autor wie die Versorgungsenklave (typischerweise Intel), die verwendet wird, um den EPID-Schlüssel vorzuhalten. Ihr Ort ist ein BS-Dienst, der für alle Apps verfügbar ist. Ihr Zweck besteht darin, es Enklaven zu erlauben, einen Plattform-EPID-Schlüssel zu entsiegeln. Ein Bericht von EREPORT wird als Eingabe bereitgestellt. Die Enklave verwendet EGETKEY, um den Berichtschlüssel abzurufen. Der Berichtschlüssel wird dann verwendet, um den Bericht zu verifizieren. Die Enklave signiert eine Notierung aus der Verwendung der EPID.
Die Lizenzenklave (License Enklave), welche mit Fähigkeiten KEY_LICENSE ausgestattet ist und von Intel autorisiert ist und mit Root-Intel signiert ist, wird mit Enklaven (BS-Dienst) ausgeliefert und wird singulär instanziiert. Ihr Zweck besteht darin, komplexe Lizenzrichtlinien zu evaluieren. Falls eine Enklave eine zusätzliche Lizenzbestätigung von der Lizenzenklave benötigt, wird EINIT dies nur akzeptieren, nachdem die Lizenzenklave den Lizenzschlüssel verwendet, um die Genehmigung zu CMACen.
In Einzelbaugruppensystemen werden alle symmetrischen Schlüssel, die von der Architektur der Enklave verwendet werden, aus einer einzelnen Quelle eine Eindeutigkeit abgeleitet, die in dem Absicherungs-Array des Prozessors gespeichert ist. Die Schlüsselhierarchie ist in eine SE-TCB-Hierarchie, welche von der Plattformimplementierung abhängt, und eine SE-Schlüsselhierarchie aufgeteilt, deren Struktur über alle Implementierungen von sicheren Enklaven hinweg konsistent ist. Schlüsselerstellungsmaterial für eine TCB-Wiederherstellung und die Fundierung einer EPID-Versorgung wird von der SE-TCB-Hierarchie bereitgestellt, welche als die Wurzel oder der Stamm der SE-Schlüsselhierarchie dient. Jedwedes Schlüsselerstellungsmaterial, das sowohl innerhalb des Enklavenbefehlssatzes als auch in vertrauenswürdigen architektonischen Enklaven verwendet wird, wird von der SE-Schlüsselhierarchie bereitgestellt.
Die Plattform stellt zwei plattformeindeutige 128-Bit-Schlüssel in Absicherungen bereit. Diese Schlüssel sind in Absicherungen mittels eines Schlüssels verschlüsselt, der in einer geheimen CPU-Logik gespeichert ist. Mehrere Einzweckschlüssel sind aus diesem Schlüssel abgeleitet und TCB-Wiederherstellungstechniken werden basierend auf den Anforderungen der Plattform angewendet. Die resultierenden Schlüssel dienen als die Wurzeln in der SE-Schlüsselhierarchie.
Schlüssel für die architektonischen Enklaven werden unter Verwendung des EGETKEY-Befehls abgerufen.
Die Enklavenarchitektur benötigt ebenfalls die Verwendung eines asymmetrischen Schlüssels, um eine Beglaubigung der REPORT-Werte gegenüber Systemen außerhalb der Plattform zu ermöglichen. Dieser Schlüssel, ein EPID-Schlüssel, wird zunächst in Absicherungen vorgehalten, kann jedoch unter Verwendung eines der Schlüssel, die aus der Schlüsselhierarchie nach der Auslieferung abgeleitet sind, erneut vorgehalten werden. Das Verfahren zum Versorgen mit dem EPID-Beglaubigungsschlüssel befindet sich außerhalb des Umfangs dieser Beschreibung. Weitere Informationen können in der Versorgungsspezifikation für Vorrichtungsbeglaubigungsschlüssel (DAK) gefunden werden.
Schließlich verwendet die Architektur der Enklave ebenfalls einen Schlüssel, der sich in der Logik von allen Prozessoren befindet, zum Versorgen mit Schlüsselmaterial bei dem OEM. Dieser Schlüssel ist als der Out-of-Box-Experience Global Key bekannt. Wir führen ähnliche Ableitungsoperationen auf diesem Schlüssel durch, um eine ISV-Eindeutigkeit zu ermöglichen. Wie diese aus dem OOB-Schlüssel abgeleiteten Schlüssel von den ISVs verwendet werden, liegt außerhalb des Umfangs dieser Beschreibung.

Obwohl der SE-TCB-Abschnitt der Schlüsselhierarchie plattformspezifisch ist, benötigen alle Fundamente denselben elementaren Satz von Schlüsseln. Wir beziehen uns auf diese als die Basisschlüssel. Sie werden alle in einem Absicherungsschlüssel und einem logischen Schlüssel abgeleitet und stellen die Wurzel der SE-Schlüsselhierarchie dar. Diese Schlüssel werden dann von einem SE-Befehl verwendet, um alle Schlüssel abzuleiten, die direkt in der SE-Architektur verwendet werden. Diese Schlüssel sind das Ergebnis der TCB-Schlüsselhierarchie. Es gibt vier SE-Basisschlüssel sowie EPID-Komponenten, die der SE-Architektur durch plattformspezifische Mechanismen zur Verfügung gestellt sind. Tabelle 12-1 beschreibt jeden dieser Schlüssel. Tabelle 12-1: Basisschlüssel einer sicheren Enklave

Name	Beschreibung	Intelbekannt
Basis-Ops-Schlüssel	Der Basis-Ops-Schlüssel ist die Hauptquelle für Schlüsselablei-tungen für eine SE. Der MAC, die Enklave und die Siegelschlüssel werden alle aus dem Ops-Schlüssel abgeleitet.	Nein
Initialer EPID (DAK)-SchlüsselBlob	Der initiale DAK EPID-Schlüssel wird in Hardware gespeichert. Dies wird verwendet, um die Authentizität der Intel-Hardware und die Schutzmaßnahmen auf einer Enklave zu attestieren. Ermöglicht Out-of-the-Box-Beglaubigungen und reduziert maximal unterstützte Ladeanforderungen in den Back-End-Servern. Der DAK-Schlüssel-Blob umfasst den komprimierten privaten 256-Bit-Schlüssel, 128 Entropiebits und eine 32-Bit-Gruppen-ID.	Nein
EPID(DAK)-Entropie	Die DAK-Entropie stellt zusätzliche 128 Bit von notwendiger Entropie für den DAK dar. Diese Bits sind von dem DAK-Blob getrennt, um Absicherungen einzusparen, durch Ableiten aus dem Hauptabsicherungsschlüssel.	Nein
Versorgungsbasisschlüssel	Der Versorgungsbasisschlüssel wird verwendet, um plattformeindeutige Versorgungsschlüssel abzuleiten. Der Versorgungsbasisschlüssel ist Intel bekannt und wird als ein gemeinsames Geheimnis verwendet, um draußen ein Versorgen mit dem Vorrichtungsbeglaubigungschlüssel zu ermöglichen.	Ja
Basis-EPID-ID	Die EPID-ID identifiziert eindeutig diese Baugruppe. Ihre einzige Verwendung ist bei der Versorgung mit anonymen Beglaubigungsschlüsseln, die dann für gewöhnliche Transaktionen verwendet werden. Der Zugriff auf die EPID-ID ist augrund ihrer Privatsphärensensibilität nur auf die Versorgungsenklave beschränkt.	Ja
Out-of-the-Box(OOB)-Basisschlüssel	Der OOB-Basisschlüssel ist ein globaler Schlüssel, der von vielen Intel-Plattformen gemeinsam genutzt wird. Der Schlüssel kann von einer gesamten Generation von Intel-Mikroprozessoren oder einem bestimmten Stepping gemeinsam genutzt werden. Dieser Schlüssel wird dann verwendet, um Verschlüsselungsschlüssel, die pro ISV widerrufbar sind, zum Verteilen von ISV-Geheimnissen auf neuen Plattformen abzuleiten.	Ja

17 stellt für eine Ausführungsform der Erfindung eine mögliche Implementierung der Plattformschlüsselhierarchie für eine sichere Enklave einer einzelnen Baugruppe dar. Der Out-of-the-Box-Basisschlüssel 1700 kann aus den verfügbaren Ableitungsressourcen 1750 abgeleitet werden 1702, um den Out-of-the-Box-Schlüssel 1704 zu generieren. Die verfügbaren Ableitungsressourcen 1750 sind eine Zeichenkette oder String mit Elementen, die festgelegte Werte 1752, einen Besitzerzeitraum oder -epoche 1754, eine Sicherheitsversion 1756 einer sicheren Enklave, die SECS-Messregister 1758, die ISV-Sicherheitsversion 1760 und SECS-Flags 1762 aufweisen. Der Versorgungsschlüssel 1710 kann die Authentizität einer Plattform gegenüber dem Intel-Backend nachweisen. Die EPID-ID 1712 ist ein Signierschlüssel. Der initiale safeID-Schlüssel-Blob 1718 ist eine Notierung und ist dem safeID-Seed 1716 zugeordnet. Der Basis-Ops-Schlüssel 1714 kann mit den Informationen aus den verfügbaren Ableitungsressourcen 1750 kombiniert werden, um eine Serie von Schlüsseln abzuleiten 1720, die den Enklavenschlüssel 1730, den Genehmigungsschlüssel 1732, den Lizenzschlüssel 1734, den Berichtschlüssel 1736, den Authentifikationsschlüssel 1738 und den Siegelschlüssel 1740 aufweisen.
17a stellt eine Ausführungsform einer Mehrfachbaugruppenschlüsselhierarchie dar.
Die Befehle und Datenstrukturen der sicheren Enklaven hängen von den Basisschlüsseln als eine Quelle für Schlüsselerstellungsmaterial ab. Die in Tabelle 12-1 gezeigte Plattformschlüsselhierarchie beschreibt die hierarchische Beziehung des Plattformschlüsselmaterials und wie Schlüssel aus dem Plattformstammschlüssel abgeleitet werden.
Der Enklavenhüllschlüssel 1752 ist ein symmetrischer Schlüssel, der zum Verschlüsseln der Seite der Kontrollstruktur für sichere Enklaven (SECS) verwendet wird, während sie nicht innerhalb des Enklavenseiten-Cache (EPC) geschützt ist. Dieser Schlüssel wird nur von uCode verwendet.
Der Genehmigungsschlüssel 1754 wird zum Bereitstellen von Authentizität und Integrität von Genehmigungen verwendet, die Fähigkeits- und Lizenzierungsinformationen für eine Enklave enthalten. Die Genehmigungen werden geMACt, um ihre Integrität sicherzustellen, während sie sich im Transit zu EINIT befinden. Dieser Schlüssel wird von EMKPERMIT-uCode und EINIT verwendet.
Der Lizenzschlüssel 1756 wird verwendet, um die Konformität mit Lizenzrichtlinien zuzusichern, die nicht in der Lage sind, von uCode evaluiert zu werden. Der Lizenzschlüssel wird zum Erzeugen einer authentifizierten Freigabe aus der Lizenzenklave verwendet, die von EINIT evaluiert wird. Dieser Schlüssel wird von EINIT-uCode verwendet und ist über EGETKEY für Enklaven mit der gesetzten KEY_LICENSE-Fähigkeit verfügbar.
Der Berichtschlüssel 1758 wird zum Bereitstellen von Authentizität und Integrität von Berichten verwendet. Berichte werden von dem EREPORT geMACt, um ihre Integrität sicherzustellen, während sie sich im Transit zu der Notierungsenklave befinden. Dieser Schlüssel wird von EREPORT-uCode verwendet und ist über EGETKEY für Enklaven mit der gesetzten QUOTE-Fähigkeit verfügbar.
Der Auth-Schlüssel 1760 ist ein enklavenspezifischer Schlüssel und wird zum Bereitstellen von Authentizität und Integrität von Daten verwendet, die von der Notierungsenklave zu einer ISV-Enklave gesendet werden, und ermöglicht eine Authentifikation von Enklave zu Enklave auf derselben Plattform. Der Schlüssel ist über EGETKEY für alle Enklaven verfügbar und diejenigen Enklaven mit der gesetzten ISV_AUTH-Fähigkeit können angeben, welchen Schlüssel sie benötigen.
Der Siegelschlüssel 1762 stellt für jede Enklave einen 128-Bit-Schlüssel zum Verschlüsseln ihrer sensitiven Daten bereit. Eine Anzahl von Versiegelungsrichtlinien kann in den Siegelschlüssel integriert werden, wodurch ISVs dahingehend flexibel werden, in welcher Software ihre Daten entsiegeln werden können. Diese Schlüssel sind jeder Enklave über EGETKEY verfügbar, jedoch ist ein Siegelschlüssel individuell nur für eine Enklave verfügbar, die die angeforderte Siegelrichtlinie erfüllt.
Die EPID-ID 1712 identifiziert eindeutig die Baugruppe. Ihr einziger Zweck besteht darin, die Versorgung mit Vorrichtungsbeglaubigungsschlüsseln zu ermöglichen, welche EPID-basierte anonyme Beglaubigungsschlüssel sind. Auf die EPID-ID kann nur von der Versorgungsenklave aus zugegriffen werden. Die Versorgungsenklave wird sie nur über einen sicheren Kanal an einen freigegebenen Versorgungs-Server liefern und nur während des Versorgungsprozesses, der von dem Benutzer oder dem Betriebssystem initiiert wird. Diese ID ist über EGETKEY für Enklaven mit der PROVISIONING-Fähigkeit verfügbar.
Der Versorgungsschlüssel 1710 wird zum Nachweis der Authentizität einer Plattform gegenüber dem Intel-Backend sowie zum Authentifizieren des ablaufenden aktuellen SE-TCB verwendet. Durch Demonstrieren des Zugriffs auf den Versorgungsschlüssel wird dem Versorgungs-Server versichert, dass die Enklave tatsächlich diejenige Vorrichtung ist, die sich im Besitz der EPID-ID befindet, und zumindest die spezifizierte TCB-Sicherheitsversion ausführt. Der Versorgungsschlüssel ist für diese Baugruppe und den Unterzeichner der Versorgungsenklave, die ihn anfordert, eindeutig. Dies erstellt eine Trennung zwischen Versorgungsinfrastrukturen, wenn mehr als eine auf einer einzelnen Plattform verwendet wird. Dieser Schlüssel ist über EGETKEY für Enklaven mit der KEY_PROVISION-Fähigkeit verfügbar.
Der Versorgungssiegelschlüssel liefert an die Versorgungsenklave einen 128-Bit-Schlüssel, um das Versorgen in einer Weise zu verschlüsseln, die sogar nach einem Besitzerwechsel abgerufen werden kann. Dieser Schlüssel wird verwendet, um eine alte EPID zu verschlüsseln, um nachzuweisen, dass die Plattform bei der Akquise von neuen EPIDs nicht widerrufen wurde. Der Versorgungsschlüssel ist für diese Baugruppe und den Unterzeichner der Versorgungsenklave, die ihn anfordert, eindeutig. Dies erstellt eine Trennung zwischen Versorgungsinfrastrukturen, wenn mehr als eine auf einer einzelnen Plattform verwendet wird. Dieser Schlüssel ist über EGETKEY für Enklaven mit der KEY_PROVISION-Fähigkeit verfügbar.
Der ISV-Out-of-Box(OOB)-Experience-Schlüssel 1700 ist ein gemeinsamer Schlüssel von allen Intel-Plattformen und eines ISV. Dieser Schlüssel ist aus der OOB-Wurzel für einen spezifischen ISV eindeutig abgeleitet. ISVs werden in der Lage sein, einen Zugriff auf diesen Schlüssel zu erwerben, was ihnen erlaubt, Geheimnisse auf diesem Schlüssel zu verschlüsseln, und platziert in einem Festplattenabbild eines OEM. Auf diese Geheimnisse kann nur von ihrem Code aus zugegriffen werden, der sicher in einer sicheren Enklave abläuft, und von der Plattform nicht erfordert, online zu gehen oder eine Versorgung mit einem Beglaubigungsschlüssel abzuschließen. Diese Schlüssel sind über EGETKEY für Enklaven mit der OOB-Fähigkeit verfügbar.
Versorgte Schlüssel sind solche kritischen Schlüssel für die Architektur der sicheren Enklaven, werden jedoch nicht aus dem Plattformschlüsselerstellungsmaterial abgeleitet. Mit diesem Schlüssel wird von einem Versorgungs-Server oder durch Offline-Techniken versorgt. Der Vorrichtungsbeglaubigungsschlüssel (DAK) ist ein Schlüssel für anonymes Signieren (EPID), der zum Beglaubigen der Eigenschaften von individuellen Enklaven verwendet wird. Dies kann von einem ISV während der Schlüssel- oder Geheimnisversorgung verwendet werden, um sicherzustellen, dass sensitive Informationen nur an geschützte Instanziierungen von ihren nicht manipulierten Anwendungen gesendet werden.
Es gibt zwei Quellen für den Vorrichtungsbeglaubigungsschlüssel. Die bevorzugte Architektur wird mit einem initialen DAK ausgeliefert, der in Absicherungen als der EPID-Schlüssel-Blob und die EPID-Entropie komprimiert ist. Dies erlaubt der Plattform, Beglaubigungen unmittelbar nach dem ersten Einschalten durchzuführen. Die zweite Quelle besteht darin, den DAK-Versorgungs-Server zu kontaktieren und einen herunterzuladen, nachdem die Legitimität der Hardware mittels der EPID-ID und des Versorgungsschlüssels nachgewiesen ist. Dieses zweite Verfahren wird von Plattformen verwendet, die keine abgesicherten EPID-Schlüssel haben, sowie beliebigen anderen Plattformen, nachdem wir eine Version des zugrunde liegenden TCB widerrufen haben. Die EPID-Absicherungen sind über EGETKEY für Enklaven mit der PROVISIONING-Fähigkeit zugreifbar.
Der Plattformbeglaubigungsschlüssel (PAK) stellt eine optionale zusätzliche Ebene der Privatsphäre bereit. Bestimmte Verwendungen des DAK können zugeordnet sein. Insbesondere wenn eine ISV-Enklave die namensbasierte Beglaubigungsfähigkeiten hat, kann diese einzelne ISV bestimmen, ob eine gegebene EPID diesen Dienst wieder aufsucht. (Mehrere ISVs können jedoch nicht kolludieren, um Benutzer nachzuverfolgen.) Da der DAK an die Plattform statt an den Besitzer gebunden ist, hält diese Zuordnung über Wasserfallereignisse hinweg an. Deshalb werden es einige Benutzer vorziehen, ihren DAK zu verwenden, um die Legitimität ihrer Plattform gegenüber einem Dritten zuzusichern, der einen PAK zur Verwendung bei täglichen Beglaubigungen ausgeben wird. In Mehrfachbaugruppenplattformen wird der DAK von jeder Baugruppe verwendet, um den PAK einzurichten, der die Gesamtheit der Plattform bei Beglaubigungen repräsentiert.
Schlüsselableitung für benutzerzugängliche Schlüssel sollte sich nach der NIST-Sonderpublikation 800-108 (Empfehlung für Schlüsselableitung unter Verwendung von pseudozufälligen Funktionen) richten. Bei der Konstruktion einer Schlüsselableitungsfunktion wird eine pseudozufällige Funktion (PRF) benötigt. Die PRF sollte auf einem AES-CMAC-Algorithmus basieren, wie es in NIST-SP 800-38B, Empfehlung für eine Funktionsweise von Blockchiffren – Der CMAC-Modus für Authentifikation, Mai 2005, definiert ist (http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf). Die Schlüsselableitung sieht allgemein wie folgt aus: AbleitungsSchlüssel = PRF_{ÜbergeordneterSchlüsset}(AbleitungsString)

Die Ableitungszeichenkette oder -String ist basierend auf dem angeforderten spezifischen Schlüssel aus einer Teilmenge von 8 Elementen aufgebaut. Tabelle 12-2 beschreibt jedes verfügbare Element, das Teil einer Ableitung sein kann. Tabelle 12-2: Verfügbare Ableitungszeichenkettenelemente

	Beschreibung	Zweck
Debug	Der festgelegte String „DEBUG” gibt an, dass sich die anfordernde Enklave im Debug-Modus befindet	Stellt eine kryptographische Trennung zwischen Schlüsseln in Debug-Enklaven und bei Produktion bereit
Festgelegter String	Ein festgelegter String, der jedem Schlüssel zugeordnet ist. Zum Beispiel ist der String des Enklavenschlüssels „ENCLAVE”.	Stellt Schlüsseltrennung bereit. Zum Beispiel kann keine EGETKEYAnforderung an Versiegeln den MAC-Schlüssel oder den Versorgungsschlüssel ableiten.
Benutzerepoche	Wert eines Besitzerzeitraums oder – epoche	Stellt eine Trennung von Schlüsseln zwischen Plattformbesitzern bereit. Durch Einrichten einer neuen Besitzerepoche kann keiner der vorhergehenden Besitzerschlüssel abgeleitet werden.
TCB-Sicherheitsversion	Sicherheitsversion der SE. Nur aktuelle oder vorhergehende TCBs werden abgeleitet. Die TCB-Sicherheitsversionen werden als ein TCB SVN 64-Bit-Wert gespeichert. Dieser Wert ist architektonisch nicht sichtbar oder definiert, enthält jedoch die Sicherheitsversionen von jeder TCB-Schicht in ihm.	Stellt eine Trennung zwischen SE-TCB-Versionen bereit. Dies hindert kompromittierte HW-Unterfangungen daran, Schlüssel aus neueren Versionen abzurufen, erlaubt jedoch neuen Enklaven, Benutzerdaten aus vor dem Upgrade abzurufen.
ISV-Sicherheitsversion (SVN)	Sicherheitsversion der Enklave, die von dem ISV zugewiesen ist, und der architektonischen Genehmigungsenklave. Nur aktuelle und vorhergehende Versionen werden abgeleitet. Die von dem ISV zugewiesene Sicherheitsversion ist ein 32-Bit-Wert, der im Großen und Ganzen zwischen Versionen mathematisch vergleichbar ist, unter Verwendung eines einfachen Größer-als- oder Gleich-Tests. Deshalb wird der ISV nicht versuchen, es in mehrere Versionskomponenten aufzuteilen.	Stellt eine Trennung zwischen Versio-nen einer Enklave und einer architektonischen Enklave bereit. Dies hindert kompromittierte Enklaven daran, Schlüssel aus neueren Enklavenversionen abzurufen, erlaubt jedoch neuen Enklaven, Benutzerdaten aus vor dem Upgrade abzurufen.
MR.EADD	Der aktuelle Wert des Messregisters MR_EADD.	MR_EADD weist die Abmessung der Inhalte der Enklave bei ihrem initialen Start auf. Dies ermöglicht die Erstellung eines Versiegelungsschlüssels, der nur für Enklaven verfügbar ist, die diesen bestimmten Satz von vertrauenswürdigen Funktionen enthalten.
MR.Policy	Der aktuelle Wert des Messregisters MR_POLICY	MR_POLICY weist den Hash des Signierschlüssels auf, der zum Signieren einer authentifizierten Enklave verwendet wird. Dies erlaubt die Erstellung eines Versiegelungsschlüssels, der nur für Enklaven verfügbar ist, die durch den gleichen Schlüssel wie diesen Schlüssel signiert sind.
Zufällig	256 zufällige Bits.	Fügt dann Entropie zu dem Ableitungsprozess hinzu. Dies ist zum Verhindern von Schlüsselabnutzung nützlich, wobei zusätzliche Zugriffskontrollmechanismen zu einem Geheimnis hinzugefügt werden, wie zum Beispiel ein Benutzerpasswort.

Jeder Schlüssel hat einen vorher festgelegten Satz von Ableitungselementen, die den Ableitungs-String bilden werden. Tabelle 12-3 beschreibt, welche Elemente in jedem der Schlüssel aus der Schlüsselhierarchie aufgenommen sind. Jede Spalte repräsentiert einen Schlüssel und die Zeilen geben an, ob ein spezifisches Element in diesem Schlüssel enthalten ist. Der Debug-String wird aufgenommen, wenn die SECS der anfordernden Enklave angibt, dass sie im Debug-Modus ist, und „Anforderung” gibt an, dass dieses Element nicht benötigt wird, jedoch in der Anforderung auswählbar ist, um den Schlüssel abzuleiten. Tabelle 12-3: Zusammenstellungen der Schlüsselableitungszeichenkette
Sichere Enklaven unterstützen Techniken zur Isolation und Wiederherstellung von Software, die an mehreren Stellen in der Boot-Sequenz beeinträchtigt wird. Um die Isolation zu unterstützen, wird jedes Langzeitschlüsselerstellungsmaterial, das Enklaven bereitgestellt wird, unter Verwendung der Sicherheitsversionen des aktuellen TCB abgeleitet.
Dieser Abschnitt beschreibt eine Beispielarchitektur für eine Plattform, deren wiederherstellbarer TCB aufgebaut ist aus uCode, MCHECK, und Mikrocode-Erweiterungen (oder ein uVMM) werden beschrieben. Die Hardware-Anforderungen sind für jede SE-unterstützende Plattform dieselben, der exakte Schlüsselfluss hängt jedoch von den spezifischen TCB-Elementen ab. Andere Plattformen können unter Verwendung von Techniken, die den hier angewandten ähnlich sind, unterstützt werden. Bei Plattformen, die Patch-at-Reset unterstützen, komplimentiert dieser Mechanismus Patch-at-Reset, um eine vollständige Wiederherstellung von uCode zu ermöglichen, aufweisend ein Nachweis eines Upgrade und kryptographisch separat zwischen uCode-Revisionen.
Die folgenden Schlüssel werden in Hardware benötigt, um eine CPU-basierte Schutztechnologie zu unterstützen. Diese Schlüssel sind das Fundament der TCB-Schlüsselhierarchie.
Stepping-spezifischer logischer 256-Bit-Schlüssel: Der logische 256-Bit-Schlüssel ist in zwei Teile aufgebrochen: ein 128-Bit-Absicherungshüllschlüssel und ein 128-Bit-Out-of-Box-Experience-Schlüssel. Es ist möglich, einen einzelnen 128-Bit-Schlüssel für beide zu verwenden, jedoch fügt dies mehr uCode hinzu.
Die-spezifische 544 Bit eines Absicherungsschlüssels: Diese weisen 32 Bit einer Gruppen-ID, 256 Bit eines Safeld A.x-Werts und 256 Bit eines Pre-Seed auf. Der A.x-Wert und das 256-Bit-Pre-Seed werden mit dem oben beschriebenen 128-Bit-Absicherungshüllschlüssel verschlüsselt.
Temporäre Register: Der Schlüsselableitungsprozess erfordert, dass die Schlüssel gespeichert werden und in der Baugruppe und nur für uCode verfügbar sind. Zwei 128-Bit-Register werden für die Dauer der Plattformlaufzeit benötigt. Ein zusätzlicher Platz von 256 Bit wird für den EPID-Schlüssel benötigt, bis CMA hoch ist und abläuft. Danach werden die zusätzlichen 256 Bit in der CPU nicht mehr benötigt.
TCB-SVN-Register: Dieses Register ist ein verriegelbares 64-Bit-Register, das unterteilt ist, um SVNs für jede TCB-Schicht zu halten. Eine spezifische Unterteilung liegt im Ermessen des Plattform-Designers, jedoch wären 8-Bit-SVNs sinnvoll. Jeder Abschnitt dieses Registers kann unabhängig verriegelbar sein.
Das Binden von Schlüsseln an einen spezifischen Satz einer TCB-Version wird dadurch erreicht, dass der uCode dazu veranlasst wird, einen ersten Satz von Schlüsseln aus dem abgesicherten Schlüssel abzuleiten, basierend auf dem Typ einer Boot-Sequenz, die eingeleitet wird (das heißt, Patch bei Reset oder Patch später). Danach werden die Absicherungen verriegelt und eine Kette von Ableitungen tritt bei jedem Ladevorgang in der Boot-Sequenz auf.
Nachdem der Code auf niedriger Ebene geladen ist, fährt die Kette damit fort, die ISV-zugewiesene Sicherheitsversion für die Software, die in der Enklave abläuft, aufzunehmen. In jeder spezifischen Konfiguration kann auf die aus der aktuellen Version abgeleiteten Schlüssel, sowie auf Schlüssel aus vorhergehenden Konfigurationen zugegriffen werden. Dies erlaubt nahtlose Benutzerdatenübergänge auf neuere nicht gefährdete Versionen.
Sobald der Die-spezifische Schlüssel generiert ist, wird er mit dem Schlüsselhüllschlüssel verschlüsselt. Dies erhöht die Schwierigkeit des Extrahierens der Schlüssel mit Hardware-Überwachungstools und stellt einen Schutz der Schlüssel im Transit bereit, bevor sie in dem Teil abgelegt werden.
Der Krypto-Algorithmus, der zum Verschlüsseln dieser Schlüssel verwendet wird, umfasst 10 Runden einer 128-Bit-AES-ECB-Entschlüsselung. Der Schlüsselgenerierungs-Server wird eine AES-ECB-Verschlüsselung auf jeden Schlüssel anwenden, um einen Chiffriertextschlüssel zu generieren, der in Absicherungen eingebrannt wird.
Die für die Schlüsselableitung in der TCB-Schlüsselhierarchie verwendete pseudozufällige Funktion (PRF) ist plattformspezifisch. Wir empfehlen ein 128-Bit-AES-ECB für Plattformen, die AES-NI unterstützen. Das Ziel besteht darin, einen nicht reversiblen Weg zum Ableiten von Schlüssel aus anderen Schlüsseln bereitzustellen. Für diesen Abschnitt verwenden wir den folgenden funktionalen Prototyp.
void PRF(uint128*key, uint128*string, uint128*key_out) {
Verwende AES-ECB, um unter Verwendung des Schlüssels key zu verschlüsseln Gebe resultierenden Chiffriertext an key_out zurück
Es gibt drei Möglichkeiten, wie PRFs bei einer Schlüsselableitung verwendet werden. Die PRF-Schleifenableitung wird verwendet, um die uCode-SVN in einen Schlüssel zu injizieren, während eine Beziehung zwischen Schlüsseln unterschiedlicher SVNs aufgebaut wird. Speziell: PRFLoop(x – 1) = PRF_PRFLoop(x(const)
Dies ermöglicht eine Vorwärtsmigration von Daten. Als Beispiel kann ein Ablaufen von uCode-SVN 3 genommen werden. Eine Enklave verwendet EGETKEY, um einen Siegelschlüssel basierend auf dieser Version (PRFLoop(3)) abzurufen, und versiegelt damit Daten. Ein uCode-Patch-Außen-Upgrade wird geliefert und bei dem nächsten Boot-Vorgang ist der uCode-SVN 4. Nach dem Upgrade wird die EGETKEY-Implementierung Zugriff auf PRFLoop(4) haben. Wenn die Enklave den SVN 3-Schlüssel von EGETKEY anfordert, kann sie PRFLoop(3) = PRF_PRFLoop(4)(constant) berechnen und deshalb den alten Siegelschlüssel abrufen.
Um diese Eigenschaft einzurichten, wird eine Schleife aus PRFs verwendet, jedoch muss aufgrund der Eigenschaft, dass PRFLoop(x – 1) aus PRFLoop(x) berechnet wird, eine maximale SVN eingerichtet werden und von ihr zurückgezählt werden. Diese spezifischen Maxima müssen für jeden Plattformtyp basierend auf einer Wahrscheinlichkeit von Patches und der benötigten Performance eingerichtet sein. Wir empfehlen 32 als den initialen Max-Punkt.
Eine Anwendung einer PRF-Schleifenableitung sieht allgemein wie folgt aus:
Dieses Verfahren wird verwendet, um die SVN des uCode in den SVN-Schlüssel zu injizieren, der der zugrunde liegende Schlüssel hinter den SE-Basisschlüsseln sein wird. Der Diespezifische Schlüssel in Absicherungen umfasst 288 Bit von EPID-Werten und 256 Bit eines Zufallsschlüssels. Alle nicht kurzlebigen symmetrischen Schlüssel können aus diesen 256 Bit abgeleitet werden, die aus 2 128-Bit-Schlüsseln aufgebaut sind. Deshalb kann eine Technik zum Ableiten von mehreren Schlüsseln aus einem einzelnen Schlüssel erstellt werden. Um dies zu tun, verwenden wir, nachdem der Absicherungsschlüssel entschlüsselt ist, ihn zum Aufrufen von ERF, unter Verwendung von unterschiedlichen festgelegten Konstanten.
Eine Anwendung einer Schlüssel-Aufteilung sieht im Allgemeinen wie folgt aus:
Diese Technik wird verwendet, um Zufallszahlen zu generieren, die als Teil der EPID-ID und einer Versorgungs-ID verwendet werden.
Sobald der SVN-Schlüssel basierend auf der uCode-SVN schleifen-abgeleitet worden ist, kann er im geschützten Speicher weggespeichert werden, wie z. B. die SE-CMA. Erweiterter Mikrocode wird ein MSR verwenden, das erweiterten Mikrocode nur zum Ableiten von Schlüsseln aus dem SVN-Schlüssel offengelegt ist. Das MSR nimmt einen Schlüssel-Selektor, der angibt, ob die Basis für die Ableitung der globale Out-of-the-Box-Schlüssel oder der Absicherungsschlüssel ist, und einen Satz von angeforderten SVNs für jede TCB-Schicht. Es verifiziert, ob die Anforderung weniger als die oder gleich den aktuellen Werten ist. uCode wendet eine beliebige notwendige PRF an, um alte SVN-Schlüssel abzurufen, und die PRFs die angeforderten TCB-SVNs.
Sobald der richtige SVN-Schlüssel verfügbar ist, wird er als der Schlüssel für eine CMAC auf den der angeforderten TCB-SVNs verwendet. Erweiterter Mikrocode verwendet dann dieses als einen CMAC-Schlüssel auf dem SE Ops Seed (ein Wert, der aus dem Abschnitt des Absicherungsschlüssels abgeleitet ist, der Intel nicht bekannt ist) für den Ops-Schlüssel oder einen festgelegten String für den Versorgungsbasisschlüssel. se_base_key = CMAC(svn_base_key, se_ops_seed);
18 stellt ein Beispiel einer mikrocode-basierten Schlüsselhierarchie einer sicheren Enklave in einer Ausführungsform der Erfindung dar. In der Hierarchie des Reset-Mikrocodes 1800 sind der globale logische Hüllschlüssel 1801 und eine Intel-bekannte eindeutige Stammabsicherung 1802 Eingaben für die Unwrap-Funktion 1806. Die Ausgabe der Unwrap 1806 und die Mikrocode-SVN 1805 steigen in eine PRF-Schleife 1808 ein. Die Mikrocode-SVN 1805 und der globale logische Stammschlüssel 1803 steigen in eine andere PRF-Schleife 1809 ein. Die Ausgabe der PRF-Schleife 1808 wird in dem SVN-Schlüsselregister 1810 gespeichert. Die Ausgabe der PRF-Schleife 1809 wird in dem globalen Schlüsselregister 1812 gespeichert. Die Mikrocode-SVN 1805 wird in dem TCB-SVN-Register 1814 gespeichert. Der globale logische Hüllschlüssel 1801 und die SE-EPID A.x-Absicherungen 1893 sind Eingaben für die Unwrap-Funktion 1807 und die Ergebnisse werden in dem SE-EPID-Register 1816 gespeichert. In der Hierarchie von MCheck 1820 werden die MCheck-SVN 1821 und die Ausgabe des TCB-SVN-Registers 1814 in dem TCB-SVN-Register 1826 gespeichert. Das SVN-Schlüsselregister 1810 wird in dem Mikrocode-SVN-Register 1822 gespeichert. Das globale Schlüsselregister 1812 wird in dem globalen Schlüsselregister 1824 gespeichert. Die SE-EPID 1816 wird in der SE-EPID 1828 gespeichert. In der Hierarchie des Load-Mikrocodes 1830 werden die Mikrocode-SVN 1831 und die Ausgabe des TCB-SVN-Registers 1826 in dem TCB-SVN-Register 1846 gespeichert. Das Mikrocode-SVN-Register 1822 wird in dem Mikrocode-SVN-Register 1832 gespeichert. Das globale Schlüsselregister 1824 wird in dem globalen Schlüsselregister 1834 gespeichert. Die SE-EPID 1828 wird in der SE-EPID 1838 gespeichert. In der Hierarchie von XuMSR Leite Schlüssel ab 1840, steigt die Mikrocode-SVN-Differenz 1841 in die PRF-Schleife 1842 und PRF-Schleife 1844 ein. Das Mikrocode-SVN-Register 1832 sendet Daten an die PRF-Schleife 1842 und das globale Schlüsselregister 1834 sendet Daten an die PRF-Schleife 1844. Die Ausgabe der PRF-Schleife 1842 und die Ausgabe des TCB-SVN-Registers 1836 steigt in eine PRF-Schleife 1846 ein und die Ausgabe der PRF-Schleife 1844 und die Ausgabe des TCB-SVN-Registers 1836 steigen in eine PRF-Schleife 1848 ein. Die Ausgabe der PRF-Schleife 1846 wird in dem SVN-Basisschlüssel 1850 gespeichert und die Ausgabe der PRF-Schleife 1848 wird im globalen Schlüssel 1852 gespeichert. In der Hierarchie des Mikrocodes 1860 wird die Intel nicht bekannte eindeutige Stammabsicherung 1894 in dem seed1 1856 gespeichert, während die EPID-Gruppen-ID-Absicherungen in EPID-rroup 1858 gespeichert werden. Das seed1 1856 steigt in eine PRF-Schleife 1886 und eine PRF-Schleife 1888 ein. Die Ausgabe der PRF-Schleife 1888 ist das SE-EPID-Seed 1 1892. Die Ausgabe der PRF-Schleife 1886 ist das SE-ops-Seed 1890. Das SE-ops-Seed 1890, das aus dem SVN-Basisschlüssel 1850 kommt, und die angeforderte SVN 1864 steigen in eine CMAC-Funktion 1868 ein, um den SE-ops-Schlüssel 1872 zu generieren. Die aktuelle SVN 1862, die aus dem SVN-Basisschlüssel 1850 kommt, steigt in eine CMAC-Funktion 1866 ein, um den SE-Versorgungsschlüssel 1870 zu generieren. Wenn der SVN-Basisschlüssel {0, 0, 0} 1874 gleich ist, wird der SVN-Basisschlüssel 1850 im seed0 1876 gespeichert. Das seed0 1876 steigt in die PRF-Schleife 1878 und die PRF-Schleife 1880 ein. Die Ausgabe der PRF-Schleife 1878 ist die SE-EPID-ID 1882 und die Ausgabe der PRF-Schleife 1880 ist das SE-EPID-seed0 1884.
Alle Kerne synchronisieren und stellen sicher, dass sie sich in MCHECK befinden, unter Verwendung von Türklingeln (door bells) oder ähnlichen Mechanismen. Sobald alle Kerne MCHECK ausführen, werden folgende Schritte von dem BSP unternommen. APs beteiligen sich nicht an dem Schlüsselfluss:

1. uCode liest, entschlüsselt und verriegelt Absicherungen.
2. uCode wendet eine PRF-Schleife auf dem SVN-Schlüssel und eine PRF-Schleife auf dem OOBE-Schlüssel an, wobei die SVN des uCodes in beide Schlüssel injiziert wird. uCode schreibt seine SVN in das TCB-SVN-Register und verriegelt diesen Abschnitt.
3. Ein MCHECK-Lader oder ein früher MCHECK-Code schreibt die SVN des MCHECK in das TCB-SVN-Register und verriegelt es.
4. Ein Patch-Lader für Mikrocode-Erweiterungen schreibt die SVN des Mikrocode-Erweiterungs-Patch in das TCB-SVN-Register und verriegelt es.

Entweder während der Initialisierung des erweiterten Mikrocodes oder beim Aufruf von EGETKEY berechnet der erweiterte Mikrocode die SE-Basisschlüssel, die benötigt werden, um Anforderungen zu entsprechen. Die Basisschlüssel können in der CMA für eine weitere Verwendung gecacht werden, um die Performance zu steigern.

Tabelle 12-4 beschreibt, wie die Basisschlüssel berechnet werden. Tabelle 12-4: Basisschlüsselberechnungen

Basisschlüsselname	Schlüsselberechnung
Basis-Ops-Schlüssel	current_svn_bask_key = XuMSRDeriveBaseKey (0x00, svns) Seed1 = Absicherungen, nicht verschlüsselt oder verriegelt. SE Ops Seed = PRF(Seed1, 0x01); = CMAC(current_svn_base_key, SE Ops Seed)
Vorhergehende Ops-Schlüssel	Prev_svn_bask_key = XuMSRDeriveBaseKey (vorhergehende svns) = CMAC(svn_base_key, SE Ops Seed)
Initialer EPID (DAK)-Schlüssel-Blob	= EPID Register
EPID(DAK)-Entropie	Seed0 = XuMSRDeriveBaseKey (0, 0, 0) Beachte: Initiale Produkte werden mit Version SVN 1 ausgeliefert. untere Bits = PRF(Seed0, 0x00); obere Bits = PRF(Seedl, 0x00);
Versorgungsbasisschlüssel	current_svn_bask_key = XuMSRDeriveBaseKey(vorhergehende svns) = CMAC (current_svn_base_key, PROV_STRING)
Basis-EPID-ID	= PRF(Seed0, 0x01);
Out-of-the-Box (OOB)-Basisschlüssel	= XuMSRDeriveBaseKey(0x01, currentSVNs)

Um die Benutzerprivatsphäre und Daten über Plattformwasserfälle hinweg zu schützen, wird eine zufällige 256-Bit-Besitzerepoche in die Ableitungen von Schlüsseln eingefügt. Dieser Wert wird zufällig während eines Besitzerwechsels erstellt. Vor der Verwendung von Enklavenschlüsseln kann eine Software die OwnerEpoch in das SE_EPOCH_MSR schreiben. Dies kann durch das BIOS erreicht werden, das sie persistent im Flash speichert. Sie kann aus irgendeiner Benutzereingabe berechnet werden, wie zum Beispiel der Hash eines Benutzer-Boot-Passworts. Sie kann ebenfalls von einem Treiber für sichere Enklaven bereitgestellt werden, bevor eine Enklavenverwendung erlaubt wird.
Die Vertraulichkeit dieses Werts wird benötigt, um sicherzustellen, dass Daten, die von der Plattform verschlüsselt sind, in der ursprünglich autorisierten Enklave durch irgendjemanden, der sich im Besitz des Laptops nach einem Wasserfall befindet, nicht entschlüsselt werden können. Eine Kompromittierung dieses Werts führt nicht zur Kompromittierung von irgendwelchen Enklavendaten.

Die SE-Key Info-Struktur ist eine nicht persistente Struktur, die in einem geschützten Speicherbereich oder der Baugruppe gespeichert ist. Die CMA ist die wahrscheinlichste Stelle, jedoch ist ein beliebiger geschützter On-Die-Speicher ebenfalls in Ordnung. Während des Einschaltens wird die SE-Key Info initialisiert. Die KeyID wird auf einen zufälligen Wert gesetzt und Key Count wird auf 0 gesetzt. Bei jeder Verwendung des Enklavenschlüssels, des Genehmigungsschlüssels und des Berichtschlüssels wird die KeyID gelesen und der Key Count wird inkrementiert. Nach 2^32 Schlüsselverwendungen wird die KeyID auf einen neuen zufälligen Wert geändert und Key Count wird auf 0 zurückgesetzt. Das SE-Key Info-Layout ist in 5 gezeigt. Tabelle 12-5: SE-Key Info

Feld	Byte-Offsets	Byte-Länge	Beschreibung
KeyID	16	16	Zufällige Versions-#, die im Schlüsselableitungsalgorithmus verwendet wird. Die KeyID wird jedes Mal, wenn die Plattformschlüsseltabelle initialisiert wird, auf einen zufälligen Wert voreingestellt. KeyID wird jedes Mal, wenn das Key Count über 2^32 rollt inkrementiert.
Key Count	32	4	# von AES-Blöcken, die von aktuell abgeleitetem Schlüssel verarbeitet werden. Key Count wird jedes Mal, wenn die KeyID initialisiert wird, auf Null gesetzt oder inkrementiert. Das KeyCount wird für jeden verarbeiteten AES-Block um 1 inkrementiert.
Lock	36	1	Compare-Set-Lock-Byte, um den Zugriff auf die Struktur zu synchronisieren.

Die Plattformschlüsseltabelle wird beim Einschalten durch uCode initialisiert. Das BIOS oder eine andere Host-Firmware erlangt die aktuelle Besitzerepoche entweder aus einem persistenten Speicher oder von dem Benutzer und schreibt sie in das LoadOwnerEpochMSR. An diesem Punkt ist die Enklavenschlüsselhierarchie verfügbar.
Vieles von der Architektur der Enklave hängt von der Verwendung von Schlüsseln zum Bereitstellen von Authentifikation und Vertraulichkeit von Enklaven ab und, um die Prozessorkomplexität minimal zu halten, werden architektonische Enklaven verwendet, um diese Schlüssel für Verwendungen auf hoher Ebene zu verarbeiten. Beispielsweise verwendet die Notierungsenklave den REPORT-Schlüssel, um einzurichten, dass eine REPORT-Struktur, die durch den EREPORT-Befehl generiert wurde, auf der Plattform erstellt wurde, und die PERMITING-Enklave verwendet den PERMIT-Schlüssel, um einen Enklaven-PERMIT zu erstellen, der von EINIT konsumiert wird, wenn eine Enklave gestartet wird.
Zusätzlich benötigt jede Enklave auf Anwenderebene einen Zugriff auf einen Schlüssel, um Geheimnisse zu versiegeln, die auf der Plattform außerhalb der Enklave gespeichert werden und die entsiegelt werden, wenn die Anwendungsenklave wieder eingerichtet wird – sogar über Leistungszyklen hinweg.
Der Mechanismus, um dies zu tun, ist der EGETKEY-Befehl. Es ist die einzige Schnittstelle zum Einrichten von Geheimnissen über die aktuelle Softwareumgebung.
EGETKEY stellt derzeit einen Zugriff auf die folgenden Schlüssel bereit:

• PROVISIONING KEY ID – wird von der architektonischen Versorgungsenklave verwendet, um Daten-Blobs zu identifizieren, welche für den Prozessor (unter Verwendung des PROVISIONING KEY) eindeutig verschlüsselt wurden.
• PROVISIONING KEY – wird von der architektonischen Versorgungsenklave verwendet, um Daten-BIobs zu entschlüsseln, welche für den Prozessor eindeutig verschlüsselt wurden.
• PROVISIONING SEAL KEY – wird von der architektonischen Versorgungsenklave verwendet, um die EPID derart zu verschlüsseln, dass sie die Enklave sogar nach einem Besitzerwechsel entschlüsseln kann.
• PERMIT KEY – wird von der architektonischen Genehmigungsenklave verwendet, um PERMITs zu erzeugen.
• REPORT KEY – wird von der architektonischen Notierungsenklave verwendet, um REPORT-Strukturen zu verifizieren.
• ISV AUTH KEY – wird von der architektonischen Notierungsenklave verwendet, um Authentifikationsdaten für eine bestimmte Zielanwendungsenklave zu erstellen.
• AUTH KEY – wird von einer Anwendungsenklave verwendet, um Daten zu authentifizieren, die an sie von der architektonischen Notierungsenklave gesendet werden.
• SEAL KEY – wird von den Anwendungsenklaven verwendet, um Daten zu verschlüsseln, die sie außerhalb der Enklave speichern möchte
• OOB EXPERIENCE KEY – wird von ISVs zum Vor-Versorgen mit verschlüsselten Daten für Out-of-Box-Experience-Verwendungen (zum Beispiel BluRay-Player) verwendet.

Die Meisten dieser Werte befinden sich nicht in dem Prozessor in der Rohform und werden vielmehr auf Anfrage durch EGETKEY aus einem einzelnen Absicherungsschlüsselwert abgeleitet. Sie werden auf Anfrage abgeleitet, da jeder dieser Schlüssel nicht ein einzelner Schlüssel ist, sondern vielmehr in einem einzelnen Schlüssel aus einem möglichen Satz ist. Der bestimmte gelieferte Schlüssel hängt von einer Anzahl von Parametern ab, von denen einige benutzerauswählbar sind und andere auf dem System oder einem bestimmten Zustand basieren.

Um den Schlüssel auszuwählen, wird eine KeyRequest-Struktur als eine Eingabe für den EGETKEY-Befehl verwendet. Neben dem Auswählen des Schlüssels, den der Benutzer will, erlaubt es die KeyRequest-Struktur dem Aufrufer, solche Variablen unter seiner Kontrolle zu spezifizieren, von denen er wünscht, dass sie bei der Erstellung des Schlüssels verwendet werden sollen. Die untere Figur spezifiziert die KeyRequest-Struktur: Tabelle 12-6: Key Request-Struktur

Offset (Byte)	Größe (Bytes)	Name	Beschreibung
0x00	0x02	KeySelect	Identifiziert den benötigten Schlüssel
0x02	0x02	KeyPolicy	Identifiziert, welche Eingaben bei der Schlüsselableitung verwendet werden müssen
0x04	0x04	ISVSecVersion	Identifiziert, welche Sicherheitsversion für die Enklave bei der Schlüsselableitung verwendet werden kann
0x08	0x08	TCBSecVersion	Identifiziert eine Sicherheitsversion für den TCB, die bei der Schlüsselableitung verwendet werden kann
0x16	0x32	Randomness	Stellt einen zufälligen 256-Bit-Wert bereit, der in den Schlüssel während der Ableitung gemischt werden soll

KeySelect wird verwendet, um den Schlüssel, den der Benutzer benötigt, zu identifizieren, und KeyPolicy wird verwendet, um einzurichten, welche zusätzlichen Werte beim Erzeugen des Schlüssels verwendet werden – ob dies eine bestimmte Sicherheitsversion der architektonischen Enklaven sein soll oder eine bestimmte Version einer Anwendungsenklave oder die Messregister, die der aktuellen Enklave zugeordnet sind (wenn EGETKEY aus dem Inneren einer ENCLAVE aufgerufen wird).

Eine zusätzliche Zufälligkeit (Randomness) kann ebenfalls zu der Schlüsselableitung hinzugefügt werden, was insbesondere benötigt wird, um Abtragen von Schlüsseln zu verhindern, und von den architektonischen PERMITING- und QUOTING-Enklaven verwendet wird. Es würde ebenfalls von der Anwendungsenklave beim Erstellen von VerSIEGELungsschlüsseln verwendet werden. Ein Setzen des Felds auf Null gibt an, dass keine zusätzliche Zufälligkeit hinzugefügt werden soll, sonst zeigt das Feld auf einen 256-Bit-ausgerichteten Datenwert. Die untere Figur spezifiziert die Struktur für das KeySelect-Feld. Tabelle 12-7: Key Request Key Value-Struktur

Bits	Name	Beschreibung
15:12	RESERVIERT	KANN NULL SEIN
11:00	KeyName	Numerischer Wert identifiziert den benötigten Schlüssel. 0x0000 – Out-of-Box-Experience-Schlüssel 0x0001 – Versorgungs-DID 0x0002 – Versorgungsschlüssel 0x0003 – Genehmigungsschlüssel 0x0004 – Berichtschlüssel 0x0005 – Auth-Schlüssel 0x0006 – ISV-Auth-Schlüssel 0x0007 – Siegelschlüssel 0x0008 – EPID-Schlüssel-Blob 0x0009 – EPID-Entropie 0x000A – Versorgungssiegelschlüssel 0x000B:0x07FF – RESERVIERT

KeyPolicy ist ein Bit-Feld-Selektor und wird verwendet, um zu bestimmen, ob ein bestimmter Wert entweder von dem Benutzer oder dem Systemzustand beim Ableiten des Schlüssels verwendet werden soll. Tabelle 12-8: Key Request Policy-Struktur

Bit	Name	Beschreibung
15:02	RESERVIERT	Reserviert. Kann Null sein
01	MR_POLICY	Leite Schlüssel unter Verwendung des POLICY-Messregisters der Enklave ab
00	MR_EADD	Leite Schlüssel unter Verwendung des EADD-Messregisters der Enklave ab

Enklavenregister und Kontrolle

Tabelle 14-1 SE-Registerlayout

Registeradresse	Registername Feld und Flags	Bit-Beschreibung
SE_BASE_MSR_ADDR	EnclaveCTL_MSR
	0	Deaktiviere SE Sobald dieses Bit gesetzt ist. System kann zurückgesetzt werden, um Enklaven neu zu aktivieren.
	1	SE-Besitzerepochenverriegelung Sobald dieses Bit gesetzt ist. Das System kann zurückgesetzt werden, um Enklaven neu zu aktivieren. Ferner können SE_EPOCH_MSR 0-3 nicht geändert werden und beliebige Versuche, SE_EPOCH_MSR 0-3 zu lesen, werden dazu führen, dass 0x0 zurückgegeben wird
	63:2	Reserviert
SE_BASE_MRS_ADDR + 1	SE_EPOCH_MSR_0	OWNER_EPOCH 63:0
SE_BASE_MRS_ADDR + 2	SE_EPOCH_MSR_1	OWNER_EPOCH 127:64
SE_BASE_MRS_ADDR + 3	SE_EPOCH_MSR_2	OWNER_EPOCH 191:128
SE_BASE_MRS_ADDR + 4	SE_EPOCH_MSR_3	OWNER_EPOCH 255:192

Enklaven werden zwei aktivierende Ebenen bereitgestellt. Die erste Aktivierung ist ein Optin-Bit, das von dem BIOS gesetzt wird. Es ist eine einmal schreibende Funktion. Es aktiviert oder deaktiviert eine Enldavenfähigkeit bis zum nächsten Zurücksetzen. Die zweite Aktivierung wird dem BS oder dem VMM bereitgestellt, um je nach Bedarf Enklavenfähigkeiten dynamisch ein- oder auszuschalten.
19 ist ein Diagramm für das Enklaven-CTL_MSR-Register, das in einer Ausführungsform der Erfindung gefunden werden kann. Das niedrigstwertige Bit ist das Enable 1900. Bit 1 des Registers ist On 1910. Bits 2 bis 63 sind reserviert.
Die Enklavenfähigkeit wird dadurch aktiviert, dass zuerst das Enable-Bit in dem EnclaveCTL_MSR, das in 19 gezeigt ist, gesetzt wird. Dieses Bit ist standardmäßig deaktiviert, wenn ein Zurücksetzen der Baugruppe auftritt. Dieses Bit kann nach einem Zurücksetzen der Baugruppe genau einmal beschrieben werden.
Das BIOS setzt das Bit, um Enklaven zu aktivieren. Wenn das BIOS das Bit löscht, können Enklaven nicht aktiviert werden, bis das Bauteil zurückgesetzt ist.
Eine Software kann eine Unterstützung fpr Enklaven durch Ausführen des CPUID-Befehls detektieren. CPUID wird ein Ergebnis zurückgeben, das angibt, ob Enklaven unterstützt werden oder nicht.
Wenn das Opt-in-Bit gelöscht ist, dann berichtet CPUID, dass Enklaven nicht ausführen werden.
Systemsoftware kontrolliert eine Enklavenfähigkeit unter Verwendung des in 19 gezeigten EnclaveCTL_MSR. Das On-Bit ermöglicht Software, einen Zugriff auf die Enklavenfähigkeit dynamisch zu kontrollieren.
Eine Software kann eine Unterstützung für Enklaven durch Ausführung des CPUID-Befehls detektieren. Die Enklavenunterstützung wird angegeben, wenn das ON-Bit in dem EnclaveCTL MSR gesetzt ist.
Das TCSMSR-Register ist ein Register auf jedem Prozessor, das die Adresse der TCS umfasst. Es wird von der Ausnahmenbehandlung und dem ERDTCSPTR verwendet. Es wird geladen, wenn in die Enklave eingestiegen wird. Das Register wird mit dem Wert der TCS geladen, wenn EENTER ausgeführt wird. Es wird von ERDTCSPTR gelesen. Die Registergröße basiert auf dem Modus des Prozessors.
Das Enklavenbasisadressregister auf jedem Prozessor umfasst die untere Adresse der Enklave, die ausgeführt wird. Es wird geladen, wenn durch den Mikrocode in die Enklave eingestiegen wird. Die Registergröße basiert auf dem Modus des Prozessors. Dieses Register ist nicht für Software sichtbar. Es ist mikrocode-temporär.
Das Register hält die obere Adressgrenze der aktuellen Enklave. Es wird geladen, wenn in die Enklave eingestiegen wird. Das Register wird mit einem Wert geladen, der in der SECS gespeichert ist, wenn die Enklave die Ausführung startet. Es ist ein mikrocode-temporäres Register. Die Registergröße basiert auf dem Modus des Prozessors.
Das Maximum-Größenregister des Enklavenseiten-Cache (EPC) gibt die maximale Größe des EPC an. Diese Größe ist als die Anzahl von 4096-Byte-Seiten gegeben. Es ist ein 32-Bit-Register. Dieses Register ist schreibgeschützt, um den größten EPC anzugeben, der von dem aktuellen Design unterstützt wird.
Das EPC-Größenregister EPC_SIZE MSR gibt die aktuell definierte Größe des EPC an. Ein Laden des Register führt zu einem EPC, der auf diese Größe definiert ist. Der Wert wird als 4096-Bit-Seiten gegeben. Beispielsweise wäre (genau) eine 4096-Bit-Seite eine 1. Der Wert des Registers kann den EPC_MAX-Wert nicht übersteigen. Wenn der Wert den EPC_MAX-Wert übersteigt, wird ein GP-Fault von dem WRMSR-Befehl genommen. Ein Schreiben in dieses Register wird alle Daten in dem EPC vor dem Schreiben für ungültig erklären. Eine Software kann alle EPC-Einträge (falls erforderlich) vor einem Aktualisieren dieses Registers sichern.
Das EPC-Basisregister gibt die Stelle der Basis des EPC an. Ein Schreiben in dieses Register wird alle Daten in dem EPC vor dem Schreibvorgang für ungültig erklären. Eine Software kann alle EPC-Einträge (falls erforderlich) vor einem Aktualisieren dieses Registers sichern.
Allgemein sollten keine externen Schnittstellen irgendeinen Transfer oder eine Transaktion erlauben, die die Sicherheit von Enklaven kompromittieren kann. Sichere Enklaven benötigen Zufallszahlen für die Enklavenschlüssel. Zufallsbits werden unter Verwendung des digitalen Zufallszahlengenerators generiert. Auf den Zufallszahlengenerator kann durch den Mikrocode sicher zugegriffen werden. Er muss nicht in dem Kern des Bauteils angeordnet sein.
26 stellt für eine Ausführungsform der Erfindung die Prozessorbaugruppe für einen digitalen Zufallszahlengenerator dar. Die Prozessorbaugruppe 2600 kann mehrere Kerne, einen Core0 2640 und einen Corel 2670, umfassen. Der Core0 2640 kann einen externen Befehlsmikrocode 2642, einen internen Funktionsmikrocode 2644, einen internen Funktionsmikrocode 2646, ein RNG-Mikrocode-Modul 2650 und eine RNG-Warteschlange 2654 umfassen. Der Corel 2670 kann einen externen Befehlsmikrocode 2672, einen internen Funktionsmikrocode 2674, einen internen Funktionsmikrocode 2676, ein RNG-Mikrocode-Modul 2680 und eine RNG-Warteschlange 2684 umfassen. Ein Read-Random-Befehl 2630 kann mit dem externen Befehlsmikrocode 2642 kommunizieren, während ein Read-Random-Befehl 2635 mit dem externen Mikrocode 2672 kommunizieren kann. Die Prozessorbaugruppe 2600 kann ebenfalls einen DRNG 2602 aufweisen, der STD 2608, OPE 2610, PSK 2612 und TSC 2614 nimmt. Der DRNG 2602 kann eine digitale Entropiequelle 2604 umfassen, die sich mit Online-Selbsttests 2606 verbindet. Die Ausgabe der Online-Selbsttests 2606 kann eine Eingabe des kombinierten Konditionierer/deterministischen Zufallsbit-Generators (DRBG) 2620 sein.
Eine Enklave kann als eine Debug-Enklave gesetzt werden, wenn sie erzeugt wird. Die Debug-Enklave wird einen externen Zugriff auf die Enklaveninhalte mittels der EDBGRD- und EDBGWR-Befehle erlauben. Eine Debug-Enklave wird durch Setzen des Debug-Flags in dem ECREATE-Befehl aufgesetzt. Dieses Bit wird innerhalb der SECS der Enklave gespeichert.
Enklaven, die mit dem gelöschten Debug-Bit erzeugt werden, sind Produktionsenklaven. Der EPC umfasst ein Debug-Bit, das angibt, dass die Enklave eine Debug-Enklave ist. Die Enklave verbleibt innerhalb des Hauptspeichers oder auf einer Platte verschlüsselt. Debugger, die auf die Enklaveninhalte schauen müssen, werden den Speicher in den EPC laden. Die EDBGRD- und EDBGWR-Befehle können verwendet werden, um auf Enklavenspeicherstellen zuzugreifen, die sich in dem EPC befinden. Eine Debug-Enklave benötigt keine Genehmigung, um auszuführen. Sie wird ohne eine gültige Genehmigung ausführen.
Beim Einsteigen in eine Produktionsenklave wird das Debug-Kontrollregister, DR7 in dem sicheren TCS-Bereich gesichert. DR7 ist in 27 gezeigt. 27 stellt für eine Ausführungsform der Erfindung ein Debug-Register DR7 2700 dar. Das Register DR 7 2700 umfasst die Bits L0 2702, L1 2706, L2 2710, L3 2714, G0 2704, G1 2708, G2 2712 und G3 2716. Andere Bits in dem DR7-Register 2700 weisen LE 2718, GE 2720, 001 2722, GD 2724, 00 2726, R/W0 2728, LENO 2730, R/W1 2732, LEN1 2734, R/W2 2736, LEN2 2738, R/W3 2740 und LEN3 2742 auf.
Die Bits L3 bis L0 und G3 bis G0 sind auf einen Null-Wert gesetzt. DR7 wird beim Ausstieg aus der Enklave auf seinen ursprünglichen Wert zurück gebracht.
Für Debug-Enklaven wird der Wert des Debug-Registers nicht geändert. Wenn RFLAGS.TF am Start eines EENTER-Befehls gesetzt ist, müssen zwei Fälle in Betracht gezogen werden:
Der Debugger ist in einem (nicht SE-bewussten) Alt-Debugger- oder die Enklave befindet sich im Produktions(Nicht-Debug)-Modus.
Ein SE-bewusster Debugger zielt auf eine Debug-Modus-Enkalve ab.

Im ersten Fall kann die #DB-Ausnahme auf dem Ziel des nächsten EEXIT-Befehls auftreten. Dies behandelt die Enklave als eine große, undurchsichtige Operation. Im zweiten Fall hat der Benutzer die volle Freiheit durch die Enklave in einzelnen Steps zu schreiten. Dieses Verhalten wird durch 3 Datenfelder innerhalb der Enklave und eine besondere Verarbeitung von RFLAGS.TF beim EENTER, EEXIT und EIRET unterstützt. Tabelle 15-1: TF Flag-Datenfelder

TCS::TF	Wert, der in RFLAGS.TF bei EENTER geladen ist
TCS::SAVE_TF	Stelle, um RFLAGS.TF bei EENTER zu sichern und bei EEXIT wiederherzustellen
SSA::RFLAGS.TF	Stelle, um RFLAGS.TF bei einem Interrupt zu sichern und bei EIRET wiederherzustellen

Tabelle 15-2: Befehlverhalten mit TF

EENTER	TCS::SAVE_TF ← RFLAGS.TF RFLAGS.TF ← TCS::TF Trap auf RFLAGS.TF
EEXIT	RFLAGS.TF ← TCS::SAVE_TF Trap auf RFLAGS.TF
Interrupt	SSA::RFLAGS.TF ← RFLAGS.TF
EIRET	Temp ← RFLAGS.TF RFLAGS.TF ← SSA:RFLAGS.TF Trap auf Temp

Der Registerwert wird in dem sicheren TCS-Bereich gesichert. Das Register wird auf 0 gesetzt. Beim Enklavenausstieg wird das Register auf den Wert beim Einstieg wiederhergestellt. Wenn die Enklave beim Einstieg ein aktiviertes Branch-Trace hat, ist das EENTER der letzte Eintrag vor dem Einsteigen in die Enklave. Beim Aussteigen aus der Enklave wird die erste Stelle nach dem Ausstieg in das Branch-Trace geschrieben.
Int n- und Int 3-Befehle werden als GP-Faults berichtet, wenn sie innerhalb der Enklave ausgeführt werden. Der Debugger kann die GP-Fault-Bedingung beim Debuggen einer Enklave hooken.
In diesem Dokument wird eine neue Technik zum Implementieren des CMAC-Betriebsmodus für die AES-Blockchiffre beschrieben. CMAC ist ein Modus, der Nachrichtenauthentizität unterstützt. Es akzeptiert als Eingabe eine Nachricht A und einen Schlüssel K und gibt ein Authentifizierungs-Tag T zurück. Die Ableitung des Authentifizierungs-Tag wird unter Verwendung des CBC(Cipher Block Chaining)-Algorithmus gemacht. CMAC ist komplexer als CBC, da es Mechanismen zum Schützen gegen Längenerweiterungsangriffe aufweist. Wir beziehen uns auf diese als die ,drei Besonderheiten von CMAC'. Im Folgenden wird eine Übersicht von CBC und CMAC bereitgestellt.
20 stellt den Chiffrenblockverkettungsalgorithmus dar, der in einer Ausführungsform der Erfindung verwendet wird. Der Initialisierungsvektor 2000 und die Eingabe 2010 der ersten Stufe steigen in das Exklusives-Oder-Gatter 2012 ein. Die Ausgabe des Exklusives-Oder-Gatters 2012 steigt in die Blockchiffre 2015 der ersten Stufe ein. Die Blockchiffienausgabe 2018 der ersten Stufe steigt dann in das Exklusives-Oder-Gatter 2022 der zweiten Stufe zusammen mit der Eingabe 2020 der zweiten Stufe ein. Die Ausgabe des Exklusives-Oder-Gatters 2022 steigt in die Blockchiffre 2025 der zweiten Stufe ein. Die Blockchiffrenausgabe 2028 der zweiten Stufe steigt dann in die nächste Stufe der Chiffrenblockkette (nicht abgebildet) ein.
Der CBC-Algorithmus verwendet eine Blockchiffre, um Vertraulichkeit für einige Datenstücke bereitzustellen oder ein Authentifizierungs-Tag auf diesen Daten zu berechnen. Die Grundidee hinter dem CBC-Algorithmus besteht darin, dass die Ausgabe aus der vorhergehenden Verschlüsselung mit dem nächsten Eingabenblock geXORt wird, bevor sie verschlüsselt wird. Auf diese Art und Weise werden Muster, die in den Eingabedaten vorhanden sein können, in dem Chiffriertext eliminiert. Die Kombination der XOR-Operationen zwischen und die Transformationen der Blockchiffre stellen ebenfalls eine starke Vermischung für das Ableiten eines Nachrichtenauthentifikations-Tag dar, das idealer Weise nicht fälschbar ist.
Der CBC-Algorithmus wird unten angegeben und ist in 20 dargestellt. Es wird angenommen, dass die Chiffre wie in dem Fall von AES eine 128-Bit-Blockchiffre ist.
Die CMAC-Spezifikation weist drei zusätzliche Algorithmen zum Initialisieren und Finalisieren des CBC-Algorithmus auf. Wir beziehen uns auf diese als die „drei Besonderheiten” von CMAC. Die erste Besonderheit betrifft die Ableitung von zwei Unterschlüsselwerten K₁ und K₂ aus dem symmetrischen Schlüssel K. Die Unterschlüssel K₁ und K₂ leiten sich aus einem Zwischenwert L ab. CMAC spezifiziert, dass sich L durch Anwenden der Blockchiffrentransformation des symmetrischen Schlüssels auf einem String, der aus Nullen besteht (das heißt 0¹²⁸), unter Verwendung des symmetrischen Schlüsselwerts K ableitet. Diese Beziehung ist in Gleichung (1) gezeigt: L = CIPHER_K(0¹²⁸) (1)
Sobald L abgeleitet ist, wird das höchstwertige Bit von L geprüft. Wenn es Null ist, dann leitet K₁ aus L durch Verschieben um eine Bitposition nach links ab. Ansonsten wird L um eine Bitposition nach links verschoben und ebenfalls mit einem speziellen Wert R_b geXORt, um K₁ zu erzeugen. R_b ist in binärer Form als <0¹²⁰10000111> definiert. K₂ wird aus K₁ gemäß derselben Prozedur erzeugt. Die Ableitung der Unterschlüssel K₁, K₂ ist unten als Pseudocode gegeben. Durch MSB() ist das höchstwertige Bit eines Werts gemeint.
Die zweite Besonderheit von CMAC betrifft das Auffüllen (padding), das vor einem Anwenden des CBC-Algorithmus auf den Eingabedaten erfolgt. Wenn der letzte Datenblock kein vollständiger Block ist, dann wird der Block mit einem Bit, das „1” gleicht, gefolgt von so vielen Nullen, wie benötigt, aufgefüllt, sodass der finale Block vollständig wird.
Die dritte Besonderheit von CMAC betrifft eine Modifikation auf dem letzten Block, die stattfindet, um Längenerweiterungsangriffe zu vermeiden. Wenn der letzte Block ein vollständiger ist (kein Auffüllen wird benötigt), dann wird der letzte Block mit dem Unterschlüssel K₁ geXORt. Sonst wird er mit dem Unterschlüssel K₂ geXORt.
Die Algorithmen für die CMAC-Tag-Generierung und -Validierung sind unten aufgelistet:

Im Folgenden wird gezeigt, wie der CBC()-Algorithmus implementiert sein kann, wenn die verwendete Blockchiffre mit einem symmetrischen Schlüssel AES ist und der Prozessor einen Satz von Befehlen für AES-Rundenbeschleunigung unterstützt. Die Intel-Architektur unterstützt 4 solche neuen Befehle im Zeitfenster des Westmere-Prozessors (2009) und danach. Diese Befehle sind AESENC (AES-Rundenverschlüsselung), AESENCLAST (AES-Verschlüsselung der letzten Runde), AESDEC (AES-Rundenentschlüsselung) und AESDECLAST (AES-Entschlüsselung der letzten Runde). Die Spezifikation für diese Befehle ist wie folgt: Tabelle 16-1: AES-Rundenbefehle

Opcode/Befehl	Unterstützung für 64/32-Bit-Modus	CPUID-Feature-Flag	Beschreibung
66 OF 38 DC/r AESENC xmm1, xmm2/128	V/V	AES	führt eine Runde eines AES-Verschlüsselungsflusses aus, die auf 128-Bit-Daten (Zustand) aus xmm1 mit einem 128-Bit-Rundenschlüssel aus xmm2/128 arbeitet
66 OF 38 DD/r AESENCLAST xmm1, xmm2/128	V/V	AES	führt die letzte Runde eines AES-Verschlüsselungsflusses aus, die auf 12-Bit-Daten (Zustand) aus xmm1 mit einem 128-Bit-Rundenschlüssel aus xmm2/128 arbeitet
66 OF 38 DE/r AESDEC xmm1, xmm2/128	V/V	AES	führt eine Runde eines AES-Entschlüsselungsflusses unter Verwendung der äquivalenten inversen Chiffre aus, die auf 128-Bit-Daten (Zustand) aus xmm1 mit einem 128-Bit-Rundenschlüssel aus xmm2/128 arbeitet
66 OF 38 DF/r AESDECLAST xmm1, xmm2/128	V/V	AES	Führt die letzte Runde eines AES-Bntschlüsselungsflusses unter Verwendung der äquivalenten inversen Chiffre aus, die auf 128-Bit-Daten (Zustand) aus xmm1 mit einem 128-Bit-Rundenschlüssel aus xmm2/128 arbeitet

Um den CMAC-Modus mittels der AES-Rundenbefehle zu implementieren, reicht es aus, nur AESBNC, AESBNCLAST aufzurufen, da der Tag-Validierungsprozess derselbe ist wie die Tag-Generierung. 21 zeigt ein Flussdiagramm, das der Verschlüsselung eines einzelnen AES-Blocks zugeordnet ist. 22 zeigt ein Flussdiagramm, das der Verschlüsselung von mehreren AES-Blöcken unter Verwendung des CBC-Algorithmus zugeordnet ist.
Um die Schlüsseleinteilungstransformation zu implementieren, kann man den AESIMC-Befehl zum inversen Vermischen von Spalten und den AESKEYGENASSIST-Befehl verwenden. AESKEYGENASSIST wird zum Generieren der Rundenschlüssel verwendet, die zur Verschlüsselung verwendet werden. AESIMC wird zum Konvertieren der Verschlüsselungsrundenschlüssel in eine Form verwendet, die zum Entschlüsseln verwendet werden kann, gemäß dem äquivalenten inversen Chiffrenmodell. Die Beschreibung der AESIMC- und AESKEYGENASSIST-Befehle ist in http://softwarecommunity.intel.com/articles/eng/3788.htm gegeben.
CMAC ist mittels der Big-Endian-Notation für die involvierten 128-Bit-Quantitäten spezifiziert. Um CMAC in einer Little-Endian-Maschine richtig zu implementieren, müssen 16 Byte breite Byte-Reflexionsoperationen an bestimmten Punkten in der Quellcodeimplementierung durchgeführt werden. Solche Operationen können unter Verwendung des PSHUFB-Befehls schnell durchgeführt werden (1 Takt Latenz, Durchsatz). Im Folgenden werden die Punkte beschrieben, an denen ein Byte-Mischen benötigt wird.
In der Implementierung des SUBKEYS()-Algorithmus wird eine Byte-Reflexion auf L benötigt, nachdem es durch Anwenden der AES-Chiffre auf den Null-String abgeleitet wird und vor der Ableitung der zwei Unterschlüssel. Eine Byte-Reflexion wird ebenfalls auf den zwei Unterschlüsseln benötigt, nachdem sie aus L abgeleitet werden. Eine SUBKEYS()-Implementierung ist unten in C gegeben:
Als Nächstes ist eine Byte-Reflexion auf dem letzten Block vor und nach einem Auffüllen nur dann erforderlich, wenn dieser letzte Block unvollständig ist. Diese Schritte sind in einer C-Implementierung unten gezeigt:
Wobei die Funktion_pshufb() eine 128 Bit breite Byte-Reflexion durchführt.
SE-Anforderungen für SMI
Enklaven ist es nicht erlaubt, innerhalb eines SMM-Raums auszuführen. Ein Versuch, eine Enklave im SMM-Modus auszuführen, wird zu einem GP-Fault des Befehls führen. Wenn ein SMI während eines Ausführens innerhalb einer Enklave auftritt, kann der Prozessor den Registerzustand innerhalb der Enklave wegsichern und aussteigen. Wenn der Ausstieg auftritt, ist das TBD MSR-Bit gesetzt, um anzugeben, dass der SMI aufgetreten ist, während die Enklave ausführte. Der SMM-Code kann nicht auf die Enklavendaten zugreifen. Versuche, den EPC-Bereich zu berühren, werden zu der Rückgabe von Junk-Daten im Realmodus (real mode) um einem EPC-Seiten-Fault im geschützten Modus (protected mode) führen.
Bestimmten Befehlen ist es nicht erlaubt, auszuführen. Es gibt eine Anzahl von allgemeinen Regeln, die verwendet werden, um zu entscheiden, welche Befehle legal sind.

1. Änderungen einer Ringebene sind nicht innerhalb einer Enklave erlaubt. Befehle, die die Ringebene ändern oder ändern könnten, sind verboten.
2. Software von außerhalb kann VMEXITS innerhalb einer Enklave nicht bedienen. Alle Befehle, die einen VMEXIT innerhalb der Enklave generieren oder generieren könnten sind verboten.
3. Software kann keine virtuelle Maschine innerhalb einer Enklave erstellen. Alle VMX-Befehle sind verboten.
4. Befehle, die I/O-Referenzen durchführen, sind innerhalb einer Enklave verboten.

In der ersten Generation von Enklaven kann der Prozessor im Ring 3 mit der IOPL auf 0 gesetzt beim Einsteigen in eine Enklave ablaufen.

Um die Programmierumgebung zu erhalten, wenn Enklaven entweder eine virtualisierte oder eine nicht-virtualisierte Umgebung ablaufen, sind die in Tabelle 18-1 aufgelisteten Befehle illegal. Tabelle 18-1: Illegale Befehle innerhalb einer Enklave

Grund für die Illegalität	Befehle
VMEXIT generierend. Kann nicht von VMM unterstützt werden. Generiere konsistentes Verhalten durch Verbieten über die ganze Zeit. Generiere #UD	CLTS, CPUID, GETSEC, HALT, INVD, INVEPT, INVLPG, INVVPID, LGDT/LIDT, LLDT, LMSW, LTR, MONITOR, MOV CR, MOV DR, MWAIT, PAUSE, RDMSR, RDPMC, RDTSC, RSM, SGDT, SIDT, SLDT, SLDT, STR, VMCALL, VMCLEAR, VMENTRY, VMLAUNCH, VMPTRLD, VMPTRST, VMREAD, VMRESUME, VMWRITE, VMXON, VMXOFF, WBINVD, WRMSR, XSETBV
I/O-Befehle (ebenfalls VMEXIT). Generiere #UD	IN, INS/INSB/INSW/INSD, OUT, OUTS/OUTSB/OUTSW/OUTSD

Beschränkungen werden auf den Zustand innerhalb einer Enklave auferlegt. Beim Einsteigen in die Enklave werden die GDTR.limit, LDTR.limit, IA32_EFER.SCE und IA32_SYSENTER_CS in dem TCS-Bereich gesichert. Die lokalen Werte werden gelöscht. Befehle, die auf diese Register zugreifen oder einen Zugriff verursachen, werden innerhalb einer Enklave fehlschlagen. Die GDTR.limit, LDTR.limit, IA32_EFER.SCE und IA32_SYSENTER_CS werden wiederhergestellt, wenn die Enklave verlassen wird. Tabelle 18-2: Befehle, die nicht ausführen werden

Grund	Befehle
Befehle, die auf Segmentregister zugreifen, werden fehlschlagen.	Far call, Far jump, Far Ret, TNT n/INT0/INT 3, IRET, LAR, LDS/LES/LGS/LSS, LSL, MOV zu DS/ES/SS/FS/GS, POP DS/ES/SS/FS/GS, SYSCALL, SYSTENTER, SYSEXIT, SYSRET

Die Lebensdauer einer Enklave ist in unterschiedliche Phasen geteilt. Die erste Phase ist eine Enklavenerstellung. Die zweite Phase ist eine Enklavenverwendung. Und die finale Phase ist eine Enklavenzerstörung.
Die Erstellung und Verwendung einer Enklave benötigt die Unterstützung des BS/VMM. Obwohl die Enklave nicht hinsichtlich der Sicherheit von dem BS/VMM abhängen wird, benötigt sie das BS/den VMM, um bestimmte Hardware-Datenstrukturen ordnungsgemäß zu pflegen. Ein Fehlschlag des BS/VMM, diese Strukturen zu pflegen, wird nicht zu einem Sicherheitsverlust führen, kann jedoch den totalen Fehlschlag der Enklave verursachen.
Mehrere Befehle unterstützen eine Beglaubigung von Enklaven, ein Versiegeln und ein Entsiegeln von geheimen Daten und das Genehmigen von authentifizierten Enklaven.
In der ersten Phase kann die Enklave sicher konstruiert, werden und die interne Softwareumgebung zur Verwendung durch die Anwendung aufgesetzt werden. Drei Befehle werden verwendet, um die Enklave zu erstellen. Der erste Befehl, ECREATE, setzt die Umgebung des initialen Zustands auf. Dieser Befehl erstellt den Enklavenschlüssel, lädt, verschlüsselt und prüft die Integrität von zwei Seiten, die zum Speichern der Enklavendatenstrukturen verwendet werden. Der zweite Befehl, EADDPRE, fügt eine Datenseite zu der Enklave hinzu. Er fügt Seiten hinzu, die für den Code, den Stack und den Heap-Speicher innerhalb der Enklave benötigt werden. Der dritte Befehl, EINIT, setzt die interne Software-Umgebung auf einen bekannten Zustand. Beim Abschluss dieses Befehls hat sich die Enklave in die zweite Phase der Verwendung bewegt.
Vor dem Durchführen von EINIT kann die Konstruktions-Software eine Genehmigung erlangt haben, entweder durch Durchführen von EMKPERMIT oder durch Verwenden der Genehmigungsenklave.
In die Enklave wird durch den EENTER-Befehl eingestiegen. Dieser Befehl überführt die Maschine in einen Enklavenmodus. Er überträgt die Kontrolle auf einen vordefinierten Einstiegspunkt. Der EEXIT-Befehl kehrt aus der Enklave in die Außenanwendung zurück. Der EIRRET-Befehl kehrt in die Enklave von einem Interrupt-Ausstieg zurück.
Beim Einsteigen in die Enklave entweder über EENTER oder EIRET werden die folgenden Operationen von den Befehlen durchgeführt. Sichere und Lösche GDTR.limit, LDTR.limit, IA32_EFER.SCE und IA32_SYSENTER_CS. Beim Ausstieg, stelle GDTR, LDTR, IA32_EFER und IA32_SYSENTER_CS wieder her.
Es gibt keine Befehle zum Zerstören einer Enklave.
Der EDBG_READ-Befehl macht einen 8 Byte Lesevorgang von einer Stelle innerhalb einer Debug-Enklave. Nicht-Debug-Enklaven ist kein Zugriff erlaubt. Der EDBG_WRITE-Befehl macht einen 8 Byte Schreibvorgang an eine Stelle innerhalb einer Debug-Enklave. Nicht-Debug-Enklaven ist kein Zugriff erlaubt.
Der Enklavenseiten-Cache (EPC) wird über 2 Befehle verwaltet. Zwei Befehle 1a den/speichern EPC-Seiten (ELPG und EWBINVPG).

EREPORT generiert eine kryptographisch geschützte Struktur, die eine Enklavenabmessung hält. EGETKEY stellt Mittel zum Abrufen eines enklavenspezifischen Schlüssels eines wechselnden Typs bereit. EMKPERMIT wird verwendet, um eine Genehmigung für eine authentifizierte Enklave zu erstellen. Tabelle 19-1: Befehlskategorien

Befehle	Funktion	CPL	ENKLAVENMODUS
ELPG, EWBINVPG	EPC-Verwaltung	nur 0	AUSSERHALB
ECREATE, EINIT, EADDPRE, EADDPPOST	Enklavenverwaltung	nur 0	AUSSERHALB
EMKPERMIT	Enklavenverwaltung	nur 0	AUSSERHALB²
EENTER/EIRET	Enklaveneinstieg	nur 1–3³	AUSSERHALB
EEXIT	Enklavenausstieg	ALLE	INNERHALB
ERDTCSPTR	Thread-Kontext	ALLE	INNERHALB
EREPORT	Vertrauen	ALLE	INNERHALB
EGETKEY	Vertrauen	ALLE	INNERHALB
ERDMR	Vertrauen	ALLE	AUSSERHALB
EDBGRD, EDBGWR, ERDINFO	DEBUG/UNTERSTÜTZUNG	ALLE	AUSSERHALB

²kein Verwendungsmodell für INNERHALB, es gibt jedoch keinen bekannten Nachteil, wenn es EMKPERMIT erlaubt wird, von innerhalb auszuführen.
³zukünftige Versionen können einen Einstieg in Enklaven aus Ring 0 erlauben.

Bei einem Interrupt kann der Prozessorzustand innerhalb der Enklave gesichert (und versteckt) werden und der Zustand kann dann gelöscht werden. Ferner kann sogar die Rückkehradresse des Interrupts versteckt werden.
Interrupts, die auftreten, während eine Enklave ausführt, können Informationen auf den Interrupt-Stack in einer Form pushen, die von dem Betriebssystem erwartet wird, um zu verhindern, dass BS-Code geändert werden muss. Um dies zu erreichen, wird ein Zeiger auf Trampoline-Code auf den Interrupt-Stack als der RIP gepusht. Dieser Trampoline-Code kehrt schließlich zu der Enklave mittels eines EENTER-Befehls mit einem speziellen Parameter (siehe dort) zurück.
Der Interrupt-Stack, der verwendet werden soll, wird unter Verwendung der gleichen Regeln wie bei einem Nicht-SE-Modus ausgewählt:

• Falls eine Änderung einer Berechtigungsebene stattfindet, wird der Interrupt-Stack derjenige sein, der dem neuen Ring zugeordnet ist.
• Falls keine Änderung der Berechtigungsebene stattfindet, wird der aktuelle nicht vertrauenswürdige Stack verwendet.
• Falls der IA-32e IST-Mechanismus verwendet wird, wird der Interrupt-Stack unter Verwendung dieses Verfahrens gewählt.

23 stellt in einer Ausführungsform die Anwendungs- und Interrupt-Stacks nach einem Interrupt mit einem Stack-Wechsel dar. Der aktuelle Rahmen 2300 eines sicheren Zustandsbereichs umfasst das RSP-Register 2305. Die Thread-Kontrollstruktur 2310 kann die Zählung des zustandssicheren Bereichs 2312 und der Interrupt-Rückkehrroutine 2314 umfassen. Der Interrupt-Stack 2330 umfasst das SS-Register 2332, das RSP-Register 2334, das Flag-Register 2336, das CS-Register 2338, das Befehlsregister 2340 und den Fehlercode 2342. Der Interrupt-Stack 2330 kann die Daten in seinem RSP-Register 2334 an den Anwendungs-Stack 2320 und die Zählung des sicheren Zustandsbereichs 2300 senden. Der Fehlercode 2342 kommt aus dem RSP nach Push-Vorgängen 2346. Die Interrupt-Leitroutine 2314 und das Befehlsregister 2340 senden den Trampoline pro Thread in uRTS 2344 aus.
In allen Fällen ist die Wahl des Interrupt-Stacks und die Informationen, die auf ihn gepusht werden, mit Nicht-SE-Operationen konsistent. 23 zeigt die Anwendungs- und Interrupt-Stacks nach einem Interrupt mit einem Stack-Wechsel. Ein Interrupt ohne einen Stack-Wechsel verwendet den Anwendungs-Stack. Zusätzlich wird der TCS-Zeiger für eine spätere Verwendung durch den EENTER-Befehl im REX platziert, wenn die Enklave nach dem Interrupt wieder aufgenommen wird.
Die TCS::IRR (Interrupt-Rückkehrroutine, Interrupt Return Routine) zeigt auf eine Codesequenz pro Thread, die später zu einem spezifischen Thread zurückkehren wird. Dieser Zeiger wird auf den Interrupt-Stack als der Rückkehr-RIP gepusht. Dies führt zu einem Satz von Datenstrukturen, die den IRET dazu veranlassen, zu der Anwendung dort zurückzukehren, wo der Interrupt-Rückkehrcode (der den spezialisierten EENTER-Befehl aufweist) ausgeführt wird. Der EENTER nimmt das RBX-Register, das zu dem Zeitpunkt des Interrupts initialisiert wurde (und durch das BS aufbewahrt wurde), und verwenden es als eine TCS, um in die Enklave wieder einzusteigen.
Die folgenden Bits in RFLAGS werden gelöscht, bevor das Register auf den Interrupt-Stack gepusht wird:

CF Carry Flag SF Sign Flag

PF Parity Flag OF Overflow Flag

AF Adjust Flag DF Direction Flag

ZF Zero Flag
24 stellt einen möglichen Weg dar, einen Stack mit mehreren Slots für zustandssichere Bereiche in einer Ausführungsform der Erfindung zu implementieren. Die Thread-Kontrollstruktur 2400 kann den Slot 2402 für den nächsten zustandssicheren Bereich, den Slot 2404 für den aktuellen zustandssicheren Bereich und den Slot 2406 für den zustandssicheren Bereich umfassen. Ein zustandssicherer Bereich 0 2410, ein zustandssicherer Bereich 1 2412 und ein zustandssicherer Bereich N 2418 sind die drei individuell gewählten Stellen innerhalb des zustandssicheren Bereichs. Der Slot 2402 des nächsten zustandssicheren Bereichs spezifiziert eine Stelle, die in dem zustandssicheren Bereich (zustandssicherer Bereich 0 2010) zu verwenden ist. Der Slot 2404 des aktuellen zustandssicheren Bereichs spezifiziert eine Stelle, die in dem zustandssicheren Bereich (zustandssicherer Bereich 1 2412) zu verwenden ist. Der Slot 2406 des zustandssicheren Bereichs spezifiziert eine Stelle, die in dem zustandssicheren Bereich (zustandssicherer Bereich N 2418) zu verwenden ist.
Der zustandssichere Bereich (State Save Area) hält den Enklavenzustand zu dem Zeitpunkt eines Interrupts. Da ein Interrupt im Benutzermodus geliefert werden kann, der dann in die Enklave wieder einsteigen kann, ist der SSA ein Stack aus mehreren SSA-Slots, wie es in 19-3 dargestellt ist. Die Stelle des zustandssicheren Bereichs, die verwendet werden soll, wird durch drei Variablen in der TCS kontrolliert: Anzahl der Slots für zustandssichere Bereiche (NSSA) (definiert die Gesamtanzahl von Slots in dem Stack des zustandssicheren Bereichs), Slot des aktuellen zustandssicheren Bereichs (CSSA) (definiert den aktuellen Slot, der bei dem nächsten Interrupt zu verwenden ist), zustandssicherer Bereich (SSA) (Satz von Sicherheitsbereich-Slots, der zum Sichern des Prozessorzustands bei einem Interrupt verwendet wird).
Wenn ein Interrupt während des Ausführens eines Threads innerhalb der Enklave auftritt, bestimmt ein Mikrocode den zu verwendenden sicheren Bereich durch Untersuchen von TCS::SSA und TCS::CSSA. Der Prozessorzustand wird gesichert und gelöscht (um ein Aussickern von Geheimnissen zu vermeiden) und TCS::CSSA wird inkrementiert. Wie später beschrieben werden wird, wird es nicht möglich sein, eine Ausnahme an die Enklave zu liefern, wenn die eine Ausnahme den letzten Slot einnimmt.
Beachte: Bei EENTER kann CSSR < NSSA sein, wodurch sichergestellt wird, dass dort mindestens ein sicherer Bereich vorhanden ist, der für Interrupts verfügbar ist (bis auf den Fall, dass EENTER verwendet wird, um aus einem Interrupt zurückzukehren).
25 stellt in einer Ausführungsform der Erfindung einen Abschnitt der Zustandsmaschinen mit Zustandsübergängen für Interrupts, Faults und Traps dar. Die möglichen Zustände sind Inaktiv (inactive) 2500, Aktiv (active) 2510, Ausgenommen (excepted) 2520, Behandelt (handled) (EENTER ist illegal) 2530 und Behandeln (handling) 2540. Wenn EENTER nach TCS:ENTRY 2502 abgeht, geht Inaktiv 2500 zu Aktiv 2510 über. Wenn EEXIT 2504 auftritt, geht Aktiv 2510 zu Inaktiv 2500 über. Wenn ein Interrupt, ein Fault oder ein Trap 2512 auftritt, geht Aktiv 2510 zu Ausgenommen 2520 über. Wenn EIRET 2514 auftritt, geht Ausgenommen 2520 zu Aktiv 2510 über. Wenn EENTER zu TCS:HANDLER 2524 abgeht, geht Ausgenommen 2520 zu Behandeln 2540 über. Wenn EIRET 2522 auftritt 2522, geht Ausgenommen 2520 zu Behandeln 2540 über. Wenn ein Interrupt, ein Fault oder ein Trap 2526 auftritt, geht Behandeln 2540 zu Ausgenommen 2520 über. Wenn EEXIT 2532 auftritt, geht Behandeln 2540 zu Behandelt 2530 über. Beim Behandeln von Interrupts innerhalb des Ausnahmen-Handlers der Enklave und wenn EIRET 2534 auftritt, geht Behandelt 2530 zu Behandeln 2540 über. Wenn Interrupts nicht aus dem Ausnahmen-Handler der Enklave behandelt werden und EIRET 2534 auftritt, geht Behandelt 2530 zu Aktiv 2510 über. Die gestrichelten Übergänge 2522, 2526, 2534 treten nur beim Behandeln von Interrupts innerhalb des Ausnahmen-Handlers der Enklave auf.
25 zeigt den Abschnitt der Zustandsmaschine der Enklave, der mit Interrupts zu tun hat. Ein Interrupt beginnt mit einem optionalen Stack-Wechsel und dem Pushen des synthetischen Interrupt-Rahmens auf den Interrupt-Stack. Falls das Ereignis ein Interrupt war, tritt die Enklave in den Interrupted-Zustand ein. Falls das Ereignis eine Ausnahme war, tritt die Enklave in den Excepted-Zustand ein. Diese zwei Zustände werden unterschieden, um sowohl eine Lieferung einer Enklavenausnahme an die Enklave zu garantieren, als auch eine Lieferung einer gefälschten Ausnahme durch angreifenden Anwendungscode zu verhindern.
Bei jedem Übergang in den Interrupted-Zustand kann ein nicht vertrauenswürdiger Code (entweder die Anwendung, das BS oder beide) die Enklave nur mittels EENTER/RETURN_FROM_INTERRUPT wiederaufnehmen.
Bei jedem Übergang in den Excepted-Zustand, kann ein nicht vertrauenswürdiger Code (entweder die Anwendung, das BS oder beide) entscheiden:

• die Enklave mittels EIRET fortzusetzen, um zu dem unterbrochenen IP zurückzukehren. Dies ist, wie zum Beispiel Seiten-Faults behandelt werden. Beachte, dass falls der Interrupt durch einen Fault verursacht worden ist und nichts unternommen wurde, um die Fault-Bedingung zu korrigieren, der zu dem Fault führende Befehl neu ausgeführt und wieder zu einem Fault führen wird. EIRET wird jedoch nach einem Trap zu dem Befehl, der dem zu dem Trap führenden Befehl folgt, zurückkehren.
• den Ausnahmen-Handler der Enklave aufzurufen.
• den Thread oder die Enklave zu verlassen.

EENTER im Excepted-Zustand schreitet zu dem Handling-Zustand fort. EEXIT aus dem Trap-Handler (Handling-Zustand) schreitet zu dem Handled-Zustand fort. EENTER/NORMAL ist in diesem Zustand illegal. EIRET aus dem Trampoline nimmt den Zustand, der auf dem SSA zum Zeitpunkt des letzten Interrupts gepusht wurde, wieder auf; was entweder der Active- oder der Handling-Zustand ist.

Die Befehle für sichere Enklaven sind in 2 Opcodes aufgeteilt, einen privilegierten Opcode und einen nicht privilegierten Opcode. Die Befehlsoperation ist durch den Wert im RAX zum Zeitpunkt eines Aufrufs eines Befehls bestimmt. Tabelle 19-2: Layout von nicht privilegierten Befehlen einer Enklave

Befehl	RA X	RBX	RCX	RDX
EREPORT	0x0	userData-Zeiger	REPORT-Zeiger (Ausgabe)
EMKPERMIT	0x1	License-Zeiger	PERMIT-Zeiger (ein)	PERMIT-Zeiger (aus)
EGETKEY	0x2	KEYREQUEST-Zeiger (ein)	KEY-Zeiger (aus)
ERDTCSPTR	0x3	TCS-Zeiger (Ausgabe)
EENTER	0x4	TCS-Zeiger (Eingabe)	Rückkehradresse (Ausgabe)
EIRET	0x5	TCS-Zeiger
EEXIT	0x6	Zieladresse
EACCEPT	0x7	Lineare Adresse	Flags	Maske
ERDMR	0x8	SECS-Zeiger	MR Data-Zeiger (Ausgabe)

Tabelle 19-3: Layout von privilegierten Befehlen einer Enklave

Befehl	RAX	RBX	RCX	RDX
ECREATE	0x0	PAGE_INFO-Zeiger	Reserviert (MZB)
EADDPRE	0x1	PAGE_INFO-Zeiger	Lineare EPC-Adresse	SMAP-Zeiger
EINIT	0x2	SECS-Zeiger	PERMIT-Zeiger
ELPG	0x3	PAGE_INFO-Zeiger	Lineare EPC-Adresse
EWBINVPG	0x4	PAGE_INFO-Zeiger	Lineare EPC-Adresse
EUPSMAP	0x5	Lineare EPC-Adresse	SMAP-Zeiger
EREMOVE	0x6	Lineare EPC-Adresse	SMAP-Zeiger
EMODIFY	0x7	SEC_INFO-Zeiger	Lineare EPC-Adresse	Maske
EDBGRD	0x8	Pufferzeiger	Lineare EPC-Adresse
EDBGWR	0x9	Pufferzeiger	Lineare EPC-Adresse
EDRDINFO	0xA	PAGE_INFO-Zeiger	Lineare EPC-Adresse
EADDPOST	0xB	PAGE_INFO-Zeiger	Lineare EPC-Adresse	SMAP-Zeiger
EADDSMAP	0xC

Der ECREATE-Befehl initialisiert eine geschützte SECS. Der Quelloperand zeigt auf eine page_info-Struktur. Das Inhaltsseitenfeld zeigt auf eine ungeschützte SECS-Struktur. Die SECS-Struktur kann seitenausgerichtet sein. Die unteren 12 Bits der SECS-Basis und gebundene Werte können 0 sein. Die SECS ist eine Adresse eines leeren Slots in dem EPC. Die sec_info ist eine Adresse einer ungeschützten sec_info-Struktur. Das entsprechende sec_info-Flag-Feld kann ordnungsgemäß initialisiert sein.

Name des Offsets	Wert
LIN_ADDR	MBZ
SOURCE_PAGE	Lineare Adresse von SECS, die die Enklave beschreibt, die erstellt wird. Kann seitenausgerichtet sein.
SEC_INFO	Lineare Adresse der secinfo-Struktur für die Seite
SECS	Lineare Adresse von EPC eines leeren Slots. Kann seitenausgerichtet und innerhalb des EPC sein.

Befehlseingabe(n)

RAX	0x0
RBX	PAGE_INFO-Zeiger

Befehlsausgabe
Register RAX. RAX enthält den Fehlercode, falls der Befehl fehlschlägt. Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Lock: verursacht UD#
REP: verursacht US#
Segment-Überschreibungen: n. z.
Operandengröße: verursacht UD#
Adressengröße: ignoriert
Rex: ignoriert

Ausnahmen im geschützten Modus (Protected Mode)

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus (Real Address Mode)

#UD Der ECREATE-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der ECREATE-Befehl wird im 8086-Modus nicht erkannt
EADDPRE
Befehlsbeschreibung
EADDPRE erlaubt privilegierter Software, eine Seite außerhalb einer Enklave in eine Seite innerhalb einer Enklave, die durch lin_addr spezifiziert ist, zu kopieren und die Attribute der Enklavenseite werden unter Verwendung des sec_info-Flag-Felds gesetzt.
Als Teil des Befehls wird die Seite gehasht und der resultierende Hash-Wert wird in das Messregister der Enklave erweitert.
EADDPRE kann nur auf Enklaven durchgeführt werden, die bisher nicht durch den EINIT-Befehl initialisiert worden sind. Befehlseingaben

RAX 0x1

RBX PAGE_INFO-Zeiger

RCX Lineare EPC-Adresse

RDX SMAP-Zeiger

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Lock: verursacht UD#
REP: verursacht US#
Segment-Überschreibungen: n. z.
Operandengröße: verursacht UD#
Adressengröße: ignoriert

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der EADDPRE-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der EADDPRE-Befehl wird im 8086-Modus nicht erkannt
EADDPOST
Befehlsbeschreibung
EALLOCATE erlaubt es privilegierter Software, einen SMAP-Eintrag einer Enklave, die durch lin_addr spezifiziert ist, zu initialisieren und die Attribute der Enklavenseite werden unter Verwendung des sec_info-Flag-Felds gesetzt.
Bevor die Enklave auf die Seite zugreifen kann, kann sie die Seite in der Enklave unter Verwendung des EACCEPT-Befehls akzeptieren.
EALLOCATE kann nur auf Enklaven durchgeführt werden, die durch den EINIT-Befehl initialisiert worden sind. Befehlseingaben

RAX 0xa

RBX PAGE_INFO-Zeiger

RCX Lineare EPC-Adresse

RDX SMAP-Zeiger

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Lock: verursacht UD#
REP: verursacht US#
Segmentüberschreibungen: n. z.
Operandengröße: verursacht UD#
Adressengröße: ignoriert

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der EADDPOST-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der EADDPOST-Befehl wird im 8086-Modus nicht erkannt
EMKPERMIT
Befehlsbeschreibung
Authentifiziert eine Enklave oder Lizenz und generiert aus ihr eine Genehmigung. Wenn rbx==NULL, kann Zertifikat durch Intel signiert werden. Sonst kann die Lizenz durch den Schlüssel signiert werden, der in der rbx-Genehmigung angegeben ist. Befehlseingaben

LICENSE-Zeiger PERMIT-Zeiger(ein) PERMIT-Zeiger (aus)

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Lock: verursacht UD#
REP: verursacht UD#
Segmentüberschreibungen: n. z.
Operandengröße: verursacht UD#
Adressengröße: ignoriert

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
EINIT
Befehlsbeschreibung
EINIT markiert die Enklave als dazu bereit, in einer Softwareumgebung abzulaufen. Am Ende einer erfolgreichen Initialisierung wird EENTER für die Enklave erlaubt. Befehlseingaben

RAX 0x2

RBX SECS-Zeiger

RCX PERMIT-Zeiger

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
ELPG
Befehlsbeschreibung
Dieser Befehl wird verwendet, um eine Seite in den Enklavenseiten-Cache (EPC) zu laden.
Befehlseingaben

Lineare Adresse der Quellseite: page_info
Lineare Adresse des Ziels: epc_1a

Befehlsoperation
Rückgabe:
Wenn erfolgreich, setzt der Befehl das Z-Flag in dem EFLAGS-Register auf 0, sonst wird das Z-Flag auf Eins gesetzt. Das ENCLAVE_STATUS_MSR hält einen aus den folgenden Gründen:

1. Seitenverifikation fehlgeschlagen
2. Parameter sind nicht richtig ausgerichtet.
3. page_info-Parameter ist für SECS-Ladevorgang missgebildet

Betroffene Flags

Siehe Operation.

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
EWBINVPG
Befehlsbeschreibung
Dieser Befehl wird verwendet, um dirty-Seiten aus dem EPC in den Hauptspeicher zurückzuschreiben.
Befehlseingaben

page_info
epc_1a

1. Derspezifizierte EPC-Slot ist nicht besetzt
2. Parameter sind nicht richtig ausgerichtet.

Betroffene Flags

Siehe Operation.

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
EUPSMAP
Befehlsbeschreibung
Dieser Befehl prüft und aktualisiert die Version einer Enklavenseite, die sich in dem EPC befindet.
Befehlseingaben

leaf
epc_1a
smap_1a

1. TBD

Betroffene Flags

Siehe Operation.

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
EREMOVE
Befehlsbeschreibung
Dieser Befehl aktualisiert die SMAP, wenn Daten in den EPC geladen werden.
Befehlseingaben

leaf
epc_1a
smap_1a

Befehlsoperation
Rückgabe:
Wenn erfolgreich, setzt der Befehl das Z-Flag in dem EFLAGS-Register auf 0, sonst wird das Z-Flag auf Eins gesetzt. Das ENCLAVE_STATE_MSR hält einen aus den folgenden Gründen:

2. TBD

Betroffene Flags

Siehe Operation.

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
EADDSMAP
Befehlsbeschreibung
Dieser Befehl wird verwendet, um eine neue Seite zu der SMAP hinzuzufügen, wenn die Enklave bereits initialisiert ist.
Befehlseingaben

page_info
epc_1a
smap_1a

Name des Offsets	Wert
LIN_ADDR	MBZ
SOURCE_PAGE	Lineare Adresse der Seite, in der die Seiteninhalte angeordnet sind
SEC_INFO	Lineare Adresse der secinfo-Struktur für die Seite
SECS	Lineare Adresse von EPC eines leeren Slots

Befehlsoperation

Rückgabe:
Wenn erfolgreich, setzt der Befehl das Z-Flag in dem EFLAGS-Register auf 0, sonst wird das Z-Flag auf Eins gesetzt. Das ENCLAVE_STATUS_MSR hält einen aus den folgenden Gründen:

3. TBD

Betroffene Flags

Siehe Operation.

Verwendung von Prefixen

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-cod Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
EMODIFY
Befehlsbeschreibung
Der Befehl modifiziert das SEC_INFO-Feld, um einer Enklave zu erlauben, eine Seite innerhalb der Enklave zu modifizieren. Die Enklave fordert die Änderung der Seite an, kann dann jedoch die Änderung akzeptieren, um den Prozess abzuschließen. Befehlseingaben

SEC_INFO-Zeiger Lineare EPC-Adresse Maske

Befehlsoperation
Rückgabe:
Wenn erfolgreich, setzt der Befehl das Z-Flag in dem EFLAGS-Register auf 0, sonst wird das Z-Flag auf Eins gesetzt. Das ENCLAVE_STATUS_MSR hält einen aus den folgenden Gründen:

4. TBD

Betroffene Flags

Siehe Operation.

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
EACCEPT
Befehlsbeschreibung
Software innerhalb der Enklave verwendet diese Befehle, um Änderungen des SEC_INFO-Felds zu akzeptieren. Dies ermöglicht der SMAP, auf einen neuen Seitentyp aktualisiert zu werden. Befehlseingaben

Lineare Adresse Flags Maske

Befehlsoperation
Rückgabe:
Wenn erfolgreich, setzt der Befehl das Z-Flag in dem EFLAGS-Register auf 0, sonst wird das Z-Flag auf Eins gesetzt. Das ENCLAVE_STATUS_MSR hält einen aus den folgenden Gründen:

5. TBD

Betroffene Flags

Siehe Operation

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#GP(0) Wenn die aktuelle Berechtigungsebene nicht 0 ist.

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der Befehl wird im 8086-Modus nicht erkannt
EENTER
Befehlsbeschreibung
Der EENTER-Befehl überträgt die Ausführung an eine Enklave. Am Ende des Befehls läuft die CPU im Enklavenmodus an dem IP ab, der in dem TCS oENTRY oder oHANDLER spezifiziert ist.
EENTER prüft, ob TCS gültig und für einen Einstieg verfügbar ist. TCS und der entsprechende SSA können sich zum Fortsetzen des Befehls im Speicher befinden.
EENTER prüft ebenfalls die Zustandsmaschine, um den Typ des Einstiegs zu bestimmen, und prüft, dass nur ein logischer Prozess innerhalb einer TCS zu einem Zeitpunkt aktiv ist.
RFLAGS.TF hat ein leicht geändertes Verhalten bei EENTER. RFLAGS.TF wird in TCS.SAFE_TF gespeichert und wird dann aus TCS.TF geladen. Eine Debug-Ausnahme wird dann in Abhängigkeit von dem aktualisierten Wert von RFLAGS.TF konditionell generiert.
Wenn sich die Enklave nicht im Debug-Modus befindet, wird das Debug-Register DR7 in TCS.DR7 gesichert und wird gelöscht. Gleichermaßen für das IA32_DEBUGCTL MSR. Befehlseingaben

RAX 0x4

RBX TCS-Zeiger

Befehlsausgaben

RCX Lineare EPC-Adresse

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

RFLAGS.TF-Verhalten
Der Wert von RFLAGS.TF beim Start der Ausführung von EENTER hat keinen Effekt auf einen Trap beim Abschluss von EENTER. Stattdessen bestimmt der Wert von RLFAGS.TF, der aus der TCS geladen wird, ob ein Trap genommen wird oder nicht.
DR7-Verhalten
Wenn sich die Enklave nicht im Debug-Modus befindet, wird das Debug-Register DR7 in TCS.DR7 gesichert und wird gelöscht.
IA32_DEBUG_CTL-Verhalten

Wenn sich die Enklave nicht im Debug-Modus befindet, wird das IA32_DEBUG_CTL MSR in TCS.DEBUG_CTL gesichert und wird gelöscht. Ausnahmen im geschützten Modus

#GP(0)	Wenn die aktuelle Berechtigungsebene nicht 3 ist.
	Wenn innerhalb einer Enklave ausgeführt.
	Wenn sich der Prozessor im SMM befindet
	Wenn Segmentregister oder Grenzregister nicht richtig gesetzt sind.
	Wenn Thread beschäftigt ist
	Ausgeführt im Enklavenmodus
#PF(fault-code)	Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.
#UD	Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD	Der ECALL-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD	Der ECALL-Befehl wird im 8086-Modus nicht erkannt

EEXIT
EEXIT steigt aus der Enklave nach draußen aus.
Befehlsbeschreibung
EEXIT deaktiviert den Enklavenmodus und verzweigt an die Stelle, die in RBX spezifiziert ist.
Keine Register sind von diesem Befehl betroffen. Wenn in einem beliebigen Register Geheimnisse enthalten sind, ist es die Verantwortung der Enklaven-Software, diese Register zu löschen.
RFLAGS.TF hat ein leicht geändertes Verhalten bei EEXIT. RFLAGS.TF wird aus TCS.SAVE_TF geladen. Eine Debug-Ausnahme wird dann in Abhängigkeit von dem aktualisierten Wert von RFLAGS.TF konditionell generiert.
Wenn sich die Enklave nicht im Debug-Modus befindet, wird das Debug-Register DR7 aus TCS.DR7 geladen. Dieses Verhalten und das von RFLAGS.TF ist detailliert in ??? dokumentiert. Befehlseingaben

RAX 0x6

RBX Zieladresse

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

RFLAGS.TF-Verhalten
Der Wert von RFLAGS.TF beim Start der Ausführung von EENTER hat keinen Effekt auf einen Trap beim Abschluss von EENTER. Stattdessen bestimmt der Wert von RLFAGS.TF, der aus dem SSA geladen wird, ob ein Trap genommen wird oder nicht.
DR7-Verhalten
Wenn sich die Enklave nicht im Debug-Modus befindet, wird das Debug-Register DR7 aus TCS.DR7 geladen.
IA32_DEBUG_CTL-Verhalten

Wenn sich die Enklave nicht im Debug-Modus befindet, wird das IA32_DEBUG_CTL MSR aus TCS.DEBUG_CTL geladen. Ausnahmen im geschützten Modus

#GP(0)	Wenn die aktuelle Berechtigungsebene nicht 3 ist.
	Wenn außerhalb einer Enklave ausgeführt.
	Wenn sich der Prozessor im SMM befindet
	Wenn Segmentregister oder Grenzregister nicht richtig gesetzt sind.
	Wenn Thread beschäftigt ist, nicht im ACTIVE- oder HANDLED-Zustand
#PF(fault-code)	Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.
#UD	Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD	Der EEXIT-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD	Der EEXIT-Befehl wird im 8086-Modus nicht erkannt

EIRET
Befehlsbeschreibung
Der EIRET-Befehl nimmt die Ausführung einer Enklave wieder auf, die aufgrund einer Ausnahme oder eines Interrupts unterbrochen wurde, unter Verwendung des Maschinenzustands, der vorher in dem SSA gespeichert wurde.
EIRET prüft, ob die TCS gültig ist und für die Wiederaufnahme verfügbar ist. TCS und der entsprechende SSA können sich zum Fortsetzen des Befehls im Speicher befinden.
EIRET prüft ebenfalls die Zustandsmaschine, um den Typ des Einstiegs zu bestimmen, und prüft, dass nur ein logischer Prozessor innerhalb einer TCS zu einem Zeitpunkt aktiv ist.
Wenn RFLAGS.TF bei EIRET gesetzt ist, wird eine Debug-Ausnahme beim Abschluss des Befehls auftreten, das heißt, normales TF-Verhalten. Diese Ausnahme wird derart berichtet, dass sie innerhalb der Enklave aufgetreten ist (in der gewöhnlichen SE-definierten Weise), ohne dass Befehle innerhalb ausgeführt worden sind. Da EIRET RFLAGS aus dem SSA wiederherstellt, kann TF am Ende von EIRET gesetzt werden. In diesem Fall wird das TF den folgenden Befehl beeinflussen; wiederum normales TF-Verhalten. Befehlseingaben

RAX 0x5

RBX TCS-Zeiger

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

RFLAGS.TF-Verhalten
Wenn RFLAGS.TF beim Start des EIRET-Befehls gesetzt ist, wird #DB nach Abschluss auftreten. Die Ausnahme wird an den RIP berichtet, an den die Kontrolle übertragen worden wäre, wenn TF nicht gesetzt worden wäre. Letztendlich wird kein Fortschreiten innerhalb der Enklave stattfinden.
Als Teil der normalen Operation von EIRET wird RFLAGS aus der SSA-Kopie wiederhergestellt. Wenn der resultierende TF gesetzt ist, wird #DB nach der Ausführung des Zielbefehls innerhalb der Enklave auftreten.
Diese Verhalten sind mit denen des normalen IA IRET-Befehls konsistent.
DR7-Verhalten
DR7 wird aus der SSA-Kopie wiederhergestellt, die vorher in dem letzten Interrupt oder der Ausnahme gesichert war.
IA32_DEBUG_CTL-Verhalten

Das IA32_DEBUG_CTL MSR wird aus der SSA-Kopie wiederhergestellt, die vorher in dem letzten Interrupt oder der Ausnahme gesichert war. Ausnahmen im geschützten Modus

#GP(0)	Wenn die Berechtigungsebene nicht 3 ist.
	Wenn innerhalb einer Enklave ausgeführt.
	Wenn sich der Prozessor im SMM befindet.
	Wenn Segmentregister oder Grenzregister nicht richtig gesetzt sind.
	Wenn Thread beschäftigt ist
	Ausgeführt im Enklavenmodus
#PF(fault-code)	Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.
#UD	Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD	Der ECALL-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD	Der ECALL-Befehl wird im 8086-Modus nicht erkannt

EREPORT
Der EREPORT-Befehl berichtet eine Abmessung über die Enklaveninhalte
Befehlsbeschreibung
EREPORT ruft die Enklavenmessregister, seine Fähigkeiten und den Debug-Zustand (Flags) ab. All diese Werte sind geschützt mittels eines symmetrischen Nachrichtenauthentifikationscodes, der unter Verwendung des REPORT-Schlüssels verifiziert werden kann. Enklaven, die den REPORT-Schlüssel benötigen, können die richtige Fähigkeit in ihrer SECS gesetzt haben, um ihn mittels des EGETKEY-Befehls abzurufen.
Das Ergebnis dieses Befehls wird an der Zielstelle, output_buffer_1a, hinterlegt. Befehlseingaben

RAX 0x0

RBX output_buffer_1a

RCX userInput_1a

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der EREPORT-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der EREPORT-Befehl wird im 8086-Modus nicht erkannt
ERDMR
Der ERDMR-Befehl liest die Messregisterwerte aus der SECS der Enklaven
Befehlsbeschreibung
Dieser Befehl kann nur von außerhalb der Enklave ausgeführt werden. Wenn die SECS auf eine gültige SECS-Seite zeigt, dann gibt der Befehl die Inhalte der Enklavenmessregister an die Adresse aus, die durch output_buffer_1a spezifiziert ist. Befehlseingaben

RAX 0x8

RBX secs_1a

RCX output_buffer_1a

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der EREPORT-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der EREPORT-Befehl wird im 8086-Modus nicht erkannt
EGETKEY
Wird von Enklavencode verwendet, um einen bestimmten Schlüssel aus der Prozessorschlüsselhierarchie zurückzugeben.
Befehlsbeschreibung
Der benötigte Schlüssel wird mittels einer KeyRequest-Struktur spezifiziert, deren Adresse als eine Eingabe bereitgestellt wird. Diese Adresse kann natürlich ausgerichtet sein.
Die Ausgabe ist immer ein 256-Bit-Datenwert. output_1a muss für diesen Wert natürlich ausgerichtet sein. Eingaben

RAX 0x02

RBX request_1a

RCX output_buffer_1a

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der EGETKEY-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der EGETKEY-Befehl wird im 8086-Modus nicht erkannt
ERDTCSPTR
Befehlsbeschreibung
Der ERDTCSPTR-Befehl wird verwendet, um die aktuelle lineare Adresse der TCS in RBX einzulesen Befehlsausgabe

RAX 0x3

Befehlsausgabe

RBX aktueller TCS-Zeiger

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#UD Wenn Enklaven nicht aktiviert sind

#GP(0) Wenn außerhalb einer Enklave ausgeführt.

Ausnahmen im Realadressenmodus

#UD Der ERDTCSPTR-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der ERDTCSPTR-Befehl wird im 8086-Modus nicht erkannt
EDBGRD
Befehlsbeschreibung
Der EDBGRD-Befehl wird verwendet, um 8 Bytes aus einer Debug-Enklave zu lesen
Befehlseingaben

epc_1a
dest

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

Ausnahmen im geschützten Modus

GP(0) Wenn Enklave nicht als Debug markiert ist

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der EDBGRD-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der EDBGRD-Befehl wird im 8086-Modus nicht erkannt
EDBGWR
Befehlsbeschreibung
Der EDBGWR-Befehl wird verwendet, um 8 Byte in eine Seite einer Debug-Enklave zu schreiben
Befehlseingaben

src
epc_1a

Befehlsoperation
Betroffene Flags

Keine

Verwendung von Präfixen

TBD

Ausnahmen im geschützten Modus

GP(0) Wenn Enklave nicht als Debug markiert ist

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

Ausnahmen im Realadressenmodus

#UD Der EDBGWR-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der EDBGWRITE-Befehl wird im 8086-Modus nicht erkannt
ERDINFO
Der ERDINFO-Befehl gibt Informationen über die Inhalte des Enklavenseiten-Cache zurück
Befehlsbeschreibung
Wenn er außerhalb der Enklave ausgeführt wird, berichtet EREPORT die Enklavenmessregister, ihre Fähigkeiten und den Debug-Zustand (Flags). Alle diese Werte werden unter Verwendung eines symmetrischen Nachrichtenauthentifikationscodes geschützt, der unter Verwendung des EVERIFYREPORT-Befehls verifiziert werden kann.

Das Ergebnis dieses Befehls wird an der Zielstelle, output_buffer_1a, hinterlegt. Befehlseingaben

epc_1a	// lineare Adresse der Seite innerhalb des EPC
page_info	// das SEC_INFO-Feld innerhalb von page_info kann mit einem gültigen Zeiger auf // eine natürlich ausgerichtete SEC_INFO-Struktur besiedelt werden

Befehlsoperation

Betroffene Flags

RFLAGS.ZF

Verwendung von Präfixen

Ausnahmen im geschützten Modus

#PF(fault-code) Wenn ein Seiten-Fault in Zugriffsspeicheroperanden auftritt.

#UD Wenn Enklaven nicht aktiviert sind

#GP Wenn CPL != 0

FAULT Wenn epc_1a nicht innerhalb EPC zeigt

Ausnahmen im Realadressenmodus

#UD Der EREPORT-Befehl wird im Realadressenmodus nicht erkannt

Ausnahmen im virtuellen 8086-Modus

#UD Der EREPORT-Befehl wird im 8086-Modus nicht erkannt
Referenzen von Routinen
Ausstiege (Exits)
Dieser Abschnitt stellt Pseudocode für eine Ausstiegsverarbeitung bereit. Dieser Code wird aufgerufen, wenn ein Ausstieg aus der Enklave stattfindet, der nicht von dem Enklavencode geplant ist. Die Enklavenausführung wird an der Stelle wiederaufgenommen, wo sie gestoppt wurde. Informationen, die zum Wiederaufnehmen benötigt werden, werden auf dem Außen-Stack gesichert. Der architektonische Zustand des Prozessors wird in dem geeigneten sicheren Bereich gesichert. Operation
acquire reader lock
RW-Locks erlauben es logischen Prozessoren, auf gemeinsame Ressourcen zuzugreifen, und stellen zwei Modi bereit, in denen Threads auf eine gemeinsame Ressource zugreifen können:

• Shared-Modus gewährt mehreren lesenden logischen Prozessoren einen gemeinsamen Nur-Lese-Zugriff, wodurch sie in die Lage versetzt werden, gleichzeitig Daten aus der gemeinsamen Ressource zu lesen.
• Exclusive-Modus gewährt zu einem Zeitpunkt einem schreibenden logischen Prozessor einen Lese/Schreibzugriff. Wenn der Lock im Exclusive-Modus erlangt wurde, kann kein anderer Thread auf die gemeinsame Ressource zugreifen, bis der Schreiber den Lock freigibt.

Ein einzelner RW-Lock kann in jedem Modus erlangt werden; lesende logische Prozessoren können ihn im Shared-Modus erlangen, wohingegen schreibende logische Prozessoren ihn im Exclusive-Modus erlagen können. Den logischen Prozessoren wird Anforderungsbesitz in einer fairen Reihenfolge gewährt.
Das Folgende sind die RW-Lock-Funktionen.
acquire_reader_lock, release_reader_lock, acquire_writer_lock, release_lock.
Subroutinenbeschreibung
Erlangt Lock im Shared-Modus.
Subroutineneingaben

volatile se_rw_lock_t·1

Subroutinenoperation
Betroffene Flags

Keine

Ausnahmen

Keine

release reader lock
Subroutinenbeschreibung
Gibt Lock frei, der im Shared-Modus erlangt wird.
Subroutineneingaben

volatile se_rw_lock_t·1

Subroutinenoperation
Betroffene Flags

Keine

Ausnahmen

Keine

acquire writer lock
Subroutinenbeschreibung

Erlangt Lock im Exclusive-Modus

Subroutineneingaben

volatile se_rw_lock_t·1

Subroutinenoperation
Betroffene Flags

Keine

Ausnahmen

Keine

release writer lock
Subroutinenbeschreibung
Gibt lock frei, der im Exclusive-Modus erlangt wird.
Subroutineneingaben

volatile se_rw_lock_t·1

Subroutinenoperation
Betroffene Flags

Keine

Ausnahmen

Keine

xutranslate
Subroutinenbeschreibung
Diese Subroutine ist eigentlich ein Hardware-Zusatz, durch den der uCode die PMH-Adressübersetzungsfunktionalität für xuCode freilegt. XUTRANSLATE ist im Wesentlichen ein xuOp, der als Eingabe einen PMH-Kontext und eine lineare Adresse nimmt und die finale physikalische Adresse als Ausgabe erzeugt. Wenn der PMH auf beliebige Fault-Bedingungen während des Seitentabellendurchlaufs trifft, werden diese an xuCode berichtet. Die genauen Details dieser xuOp gehen über den Umfang dieses Dokuments hinaus.
Subroutineneingaben

TBD

Subroutinenoperation
Betroffene Flags

Keine

Ausnahmen

Keine

deriveKey
Subroutinenbeschreibung
Diese Subroutine wird verwendet, um einen Schlüssel durch Durchführen einer CMAC-Operation auf dem DerivationBuffer mit dem identifizierten Schlüssel zu erstellen. Der DerivationBuffer muss ein Vielfaches von 128 Bit sein.
Subroutineneingaben

pBaseKey – der Basisschlüssel, der verwendet werden soll.
derivationBuffer – Datenfeld mit festgelegter Größe, das gehasht werden soll.

Subroutinenoperation
Betroffene Flags

Keine

Ausnahmen

Keine

ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf [0226]
http://softwarecommunity.intel.com/articles/eng/3788.htm [0304]

Claims

Prozessor, der Folgendes umfasst: eine Ausführungslogik zum Durchführen mindestens eines ersten Befehls zum Verschieben von geschützten Daten zwischen einem Enklavenseiten-Cache (EPC) und einem zweiten Speicherbereich während einer Ausführung eines Programms, das auf die geschützten Daten zugreift, wobei das Programm eingerichtet ist, in einem geschützten Modus zu laufen.
Prozessor nach Anspruch 1, wobei eine Sicherheitsabbildung (SMAP) eingerichtet ist, dabei zu helfen, die Integrität des Programms sicherzustellen, wenn das Programm auf einem Festplattenlaufwerk oder in einem geschützten Speicher gespeichert ist.
Prozessor, der Folgendes umfasst: eine Ausführungslogik zum Durchführen eines ersten Befehls zum Identifizieren eines Software-Threads, der in einer sicheren Enklave abläuft, wobei der erste Befehl eingerichtet ist, ein Programm eines Benutzers über die Identität des Software-Threads zu informieren.
Prozessor, der Folgendes umfasst: eine Ausführungslogik zum Durchführen mindestens eines ersten Befehls zum dynamischen Zugreifen auf mindestens ein Informationsfeld, um die Integrität von Daten zu bestimmen, die in der sicheren Enklave gespeichert sind, wobei das mindestens eine Informationsfeld ein Feld einer sicheren Abbildung (SMAP) und ein Feld von Sicherheitsinformationen (SEC_INFO) aufweist.
Prozessor, der Folgendes umfasst: eine Ausführungslogik zum Durchführen eines ersten Befehls zum Berichten des Zustands einer sicheren Enklave, die in einem Speicher gespeichert ist, an entweder einen lokalen oder einen entfernten Agenten.
Prozessor, der Folgendes umfasst: eine Kryptospeicherapertur (CMA) zum Schützen eines Softwareprogramms gegen Angriffe, wenn das Softwareprogramm ausgeführt wird; und eine sichere Abbildung (SMAP) zum Schützen des Softwareprogramms, wenn das Softwareprogramm nicht ausgeführt wird.
Prozessor, der Folgendes umfasst: eine Ausführungslogik zum Durchführen mindestens eines Zugriffsbefehls einer sicheren Enklave zum Allozieren oder Deallozieren von Speicher oder Software-Threads, die innerhalb einer sicheren Enklave entsprechen.
Prozessor, der Folgendes umfasst: einen hierarchischen Schutzbaum, SMAP, um mehrere Speicher-Updates innerhalb einer sicheren Enklave in einem einzelnen Prozessorzyklus freizugeben.
Prozessor, der Folgendes umfasst: eine Ausführungslogik zum Durchführen eines ersten Befehls zum Bereitstellen eines eindeutigen Schlüssels für eine sichere Enklave.
Prozessor, der Folgendes umfasst: eine Logik zum Durchführen eines ersten Befehls zum Aufbauen einer vertrauenswürdigen Umgebung, die von einem nicht vertrauenswürdigen Agenten verwaltet werden soll.
Prozessor, der Folgendes umfasst: eine Logik zum Durchführen eines Befehl zum Bestimmen der Validität einer Lizenz zum Zugreifen auf eine sichere Enklave, wobei der Befehl die Größe der Enklave mit derjenigen vergleicht, die durch ein Lizenzzertifikat vorgeschrieben ist, um die Validität der Lizenz zu bestimmen.
Prozessor, der eine Logik zum Freigeben einer Richtlinienverwaltung auf Benutzerebene für eine sichere Enklave umfasst, wobei die Logik eingerichtet ist, durch Kontrollbits gesteuert zu werden.
Prozessor, der eine Logik zum Durchführen mindestens eines Befehls zum Freigeben eines Zugriffs auf mindestens eine Instanz einer sicheren Enklave umfasst, die an einen Benutzer lizenziert werden soll.
Prozessor, der Folgendes umfasst: eine Logik zum Durchführen mindestens eines Befehls zum Freigeben einer Fehlersuche (Debugging) in einer sicheren Enklave, wobei der mindestens eine Befehl eingerichtet ist, die Enklavensicherheit nur bei Enklaven zu usurpieren, welche in der Lage sind, auf Fehler untersucht zu werden.
Prozessor, der Folgendes umfasst: eine Ausführungslogik zum Durchführen mindestens eines Befehls zum Allozieren oder Deallozieren von Speicherseiten in bzw. aus einem Enklavenseiten-Cache (EPC).