Secure Enclave

Übersicht

Die Secure Enclave ist ein dediziertes sicheres Subsystem, das bei Apple in die SoCs (System on Chip) integriert ist. Die Secure Enclave ist vom Hauptprozessor isoliert, was eine zusätzliche Sicherheitsebene mit sich bringt, und ist darauf ausgelegt, die Sicherheit sensibler Benutzerdaten selbst dann zu gewährleisten, wenn der Kernel des Anwendungsprozessors kompromittiert werden sollte. Sie folgt denselben Designprinzipien wie das SoC insgesamt – ein Boot-ROM, das einen Hardware-Vertrauensanker etabliert, eine AES-Engine für effiziente und sichere kryptografische Operationen und geschützter Speicher. Die Secure Enclave umfasst keinen Speicher, verfügt aber über einen Mechanismus zum sicheren Speichern von Informationen auf dem angeschlossenen Speicher, der unabhängig von dem vom Anwendungsprozessor und dem Betriebssystem verwendeten NAND-Flashspeicher ist.

Die Secure Enclave ist eine Hardwarefunktion der meisten Versionen von iPhone, iPad, Mac, Apple TV, Apple Watch und HomePod. Im Einzelnen sind dies folgende Geräte:

• iPhone 5s (oder neuer)

• iPad Air (oder neuer)

• Mac-Computer mit Apple Chips

• MacBook Pro-Computer mit Touch Bar (2016 und 2017) und Apple T1-Chip

• Intel-basierte Mac-Computer mit Apple T2 Security Chip

• Apple TV HD (oder neuer)

• Apple Watch Series 1 (oder neuer)

• HomePod und HomePod mini

Secure Enclave-Prozessor

Der Prozessor der Secure Enclave stellt die hauptsächliche Rechenleistung für die Secure Enclave bereit. Um die strikte Isolation zu gewährleisten, wird der Prozessor der Secure Enclave ausschließlich von der Secure Enclave genutzt. Dies hilft bei der Abwehr von Seitenkanalattacken, die den Ansatz verfolgen, dass die Schadsoftware denselben Ausführungskern wie die Zielsoftware verwendet, die im Fokus des Angriffs steht.

Der Prozessor der Secure Enclave läuft auf einer von Apple angepassten Version des L4-Mikrokernels. Er ist so konzipiert, dass er bei einer niedrigeren Taktrate effizient arbeitet, was wiederum seinem Schutz vor Clock- und Power-Angriffen dient. Der Secure Enclave-Prozessor verfügt ab A11 und S4 über eine Memory Protection Engine und einen verschlüsselten Speicher mit Anti-Replay-Funktionen, sicheres Starten, einen dedizierten Generator für Zufallszahlen und eine eigene AES-Engine.

Engine für den Speicherschutz (Memory Protection Engine)

Die Secure Enclave wird aus einer dedizierten Region des DRAM-Gerätespeichers betrieben. Der Speicher der Secure Enclave ist durch mehrere Sicherheitsebenen vom Anwendungsprozessor isoliert.

Beim Starten des Geräts generiert der Boot-ROM der Secure Enclave einen zufälligen temporären Speichersicherheitsschlüssel für die Memory Protection Engine (Speicherschutz-Engine). Bei jedem Schreibvorgang, den die Secure Enclave in der für sie dedizierten Speicherregion vornimmt, verschlüsselt die Memory Protection Engine den Speicherblock mittels AES im Mac XEX-Modus (xor-encrypt-xor) und berechnet ein CMAC-Authentifizierungs-Tag (Cipher-based Message Authentication Code) für den Speicher. Die Memory Protection Engine speichert diesen Authentifizierungs-Tag zusammen mit dem verschlüsselten Speicher. Wenn die Secure Enclave den Speicher liest, prüft die Memory Protection Engine den Authentifizierungs-Tag. Stimmt das Authentifizierungs-Tag überein, entschlüsselt die Memory Protection Engine den Speicherblock. Stimmt das Tag nicht überein, meldet die Memory Protection Engine einen Fehler an die Secure Enclave. Nach einem Speicherauthentifizierungsfehler akzeptiert die Secure Enclave Anfragen erst wieder, nachdem das System neu gebootet wurde.

Ab den SoCs der Typen Apple A11 und S4 übernimmt die Memory Protection Engine auch den Schutz des Secure-Enclave-Speichers vor Replay-Angriffen. Um ein Replay sicherheitskritischer Daten zu verhindern, speichert die Memory Protection Engine eine eindeutige und einmal genutzte Nummer, die als Nonce bezeichnet wird, für den Speicherblock zusammen mit dem Authentifizierungs-Tag. Die Nonce ist ein zusätzliches Optimierungselement für das CMAC-Authentifizierungs-Tag. Die Nonces aller Speicherblöcke werden mithilfe einer Integritätsstruktur geschützt, die ihren Ursprung im dedizierten SRAM innerhalb der Secure Enclave hat. Bei Schreibvorgängen aktualisiert die Memory Protection Engine die Nonce und jede Ebene der Integritätsstruktur bis hin zum SRAM. Bei Lesevorgängen prüft die Memory Protection Engine die Nonce und jede Ebene der Integritätsstruktur bis hin zum SRAM. Fehlende Übereinstimmungen bei Nonces werden auf ähnliche Weise behandelt wie Abweichungen bei Authentifizierungs-Tags.

Bei A14, A15, der M1-Familie und neueren SoCs von Apple unterstützt die Memory Protection Engine zwei temporäre Speichersicherheitsschlüssel. Der erste wird für private Daten verwendet, die an die Secure Enclave gesendet werden. Der zweite wird für Daten verwendet, die mit der Secure Neural Engine geteilt werden.

Die Memory Protection Engine arbeitet inline und in einer für die Secure Enclave transparenten Weise. Die Secure Enclave liest und beschreibt den Speicher, als handele es sich bei ihm um einen regulären unverschlüsselten DRAM, während ein Beobachter außerhalb der Secure Enclave nur die verschlüsselte und authentifizierte Version des Speichers zu sehen bekommt. Dies führt zu einem starken und robusten Speicherschutz ohne Abstriche an der Leistung oder der Komplexität der Software.

Boot-ROM der Secure Enclave

Die Secure Enclave umfasst einen eigenen dedizierten Boot-ROM. Ähnlich wie der Boot-ROM des Anwendungsprozessors ist auch der Boot-ROM der Secure Enclave unveränderlicher Code, der den Hardware-Vertrauensanker für die Secure Enclave darstellt.

Beim Starten des Systems weist iBoot der Secure Enclave eine dedizierte Speicherregion zu. Vor der Nutzung des Speichers initialisiert der Boot-ROM der Secure Enclave die Memory Protection Engine, um den kryptografischen Schutz für den geschützten Speicher der Secure Enclave bereitzustellen.

Im Anschluss daran sendet der Anwendungsprozessor das sepOS-Image an den Boot-ROM der Secure Enclave. Nachdem das sepOS-Image in den geschützten Speicher der Secure Enclave kopiert wurde, prüft der Boot-ROM der Secure Enclave den kryptografischen Hash-Wert und die Signatur des Image. Auf diese Weise wird geprüft und sichergestellt, dass das sepOS-Image für die Ausführung auf dem Gerät autorisiert ist. Wenn das sepOS-Image für die Ausführung auf dem Gerät korrekt signiert ist, übergibt der Boot-ROM der Secure Enclave die Steuerung an sepOS. Wenn die Signatur ungültig ist, wehrt der Boot-ROM der Secure Enclave bis zum nächsten Zurücksetzen des Chips jeden weiteren Versuch ab, die Secure Enclave zu verwenden.

Bei Apple A10 und neueren SoCs verschließt der Boot-ROM der Secure Enclave einen Hash-Wert von sepOS in einem für diesen Zweck dedizierten Register. Der Public Key Accelerator verwendet diesen Hash-Wert für an das Betriebssystem gebundene Schlüssel („OS-bound keys“).

Boot-Monitor der Secure Enclave

Bei Apple A13 und neueren SoCs umfasst die Secure Enclave einen Boot-Monitor, um die Integrität des Hash-Werts des gestarteten sepOS-Image in noch stärkerem Maße zu gewährleisten.

Beim Starten des Systems wird durch die SCIP (System Coprocessor Integrity Protection)-Konfiguration des Secure Enclave-Prozessors verhindert, dass ein anderer Code als der Boot-ROM der Secure Enclave ausgeführt wird. Der Boot-Monitor verhindert, dass die Secure Enclave die SCIP-Konfiguration direkt modifiziert. Damit das geladene sepOS-Image ausführbar wird, sendet der Boot-ROM der Secure Enclave eine Anfrage an den Boot-Monitor, in der die Adresse und die Größe des geladenen sepOS enthalten sind. Beim Erhalt dieser Anfrage setzt der Boot-Monitor den Prozessor der Secure Enclave zurück, erstellt einen Hash-Wert für das geladene sepOS, aktualisiert die SCIP-Einstellungen so, dass die Ausführung des geladenen sepOS erlaubt wird, und startet die Ausführung unter Verwendung des neu geladenen Codes. Im weiteren Verlauf des Startvorgangs wird derselbe Vorgang immer dann verwendet, wenn neuer Code ausführbar gemacht wird. Jedes Mal aktualisiert der Boot-Monitor einen laufenden Hash-Wert des Startprozesses. Der Boot-Monitor bettet auch kritische Sicherheitsparameter in diesen laufenden Hash-Wert ein.

Nach Abschluss des Startvorgangs finalisiert der Boot-Monitor den laufenden Hash und sendet ihn an den Public Key Accelerator (PKA), um den betriebssystemgebundenen Schlüssel zu verwenden. Dieser Prozess ist so konzipiert, dass die Bindung von Betriebssystemschlüsseln nicht umgangen werden kann, selbst wenn es zu einer Schwachstelle im Boot-ROM der Secure Enclave kommen sollte.

True Random Number Generator

Der True Random Number Generator (TRNG) wird verwendet, um sichere Zufallsdaten zu generieren. Die Secure Enclave nutzt den TRNG, wann immer sie einen zufälligen kryptografischen Schlüssel, einen Zufallswert für einen Schlüssel oder eine sonstige Entropie generiert. Der TRNG basiert auf mehreren Ringoszillatoren; das Post-Processing erfolgt mittels CTR_DRBG (ein auf Blockchiffren im Zählermodus basierender Algorithmus).

Kryptografische Stammschlüssel

Die Secure Enclave umfasst eine Unique ID (UID) als kryptografischen Stammschlüssel. Die UID ist für jedes einzelne Gerät eindeutig und steht in keiner Beziehung zu irgendeiner anderen ID oder Kennung des Geräts.

Eine nach dem Zufallsprinzip generierte UID wird zur Fertigungszeit fest mit dem SoC verschmolzen. Bei SoCs ab A9 wird die UID zur Fertigungszeit durch den TRNG der Secure Enclave generiert und mit einem Softwareprozess in die Sicherungen geschrieben, der vollständig in der Secure Enclave ausgeführt wird. Dieser Prozess stellt sicher, dass die UID während der Herstellung nicht außerhalb des Geräts sichtbar ist, sodass weder Apple noch ein Apple-Lieferant Zugriff auf sie hat oder sie speichern kann.

sepOS verwendet die UID, um gerätespezifische Secrets (Geheimnisse) zu schützen. Durch die UID können Daten kryptografisch an ein bestimmtes Gerät gebunden werden. So enthält beispielsweise die Schlüsselhierarchie, die das Dateisystem schützt, die UID. Dies bewirkt, dass nicht auf die Dateien zugegriffen werden kann, wenn die Speicherchips physisch von einem Gerät in ein anderes verschoben werden. Andere gerätespezifische und geschützte Secrets sind zum Beispiel die Face ID- und die Touch ID-Daten. Auf Mac-Computern wird dieser Verschlüsselungsstandard nur auf vollständig internen Speicher angewendet, der mit der AES-Engine verbunden ist. Beispielsweise werden weder externe, über USB verbundene Speichergeräte, noch PCIe-basierte Speichergeräte, die zum Mac Pro (2019) hinzugefügt werden, auf diese Weise verschlüsselt.

Die Secure Enclave hat außerdem eine Gerätegruppe-ID (GID), die für alle Geräte gleich ist, die einen bestimmten SoC verwenden. (Beispielsweise haben alle Geräte mit einem Apple A15 SoC dieselbe GID.)

Auf die UID und die GID kann nicht über Joint Test Action Group (JTAG) oder andere Debugging-Schnittstellen zugegriffen werden.

AES-Engine der Secure Enclave

Die AES-Engine der Secure Enclave ist ein Hardwareblock, der für die symmetrische Kryptografie basierend auf der AES-Chiffre verwendet wird. Die AES-Engine ist darauf ausgelegt, der Offenlegung von Informationen durch zeitliche Planung oder Static Power Analysis (SPA) entgegenzuwirken. Seit der A9-SoCs umfasst die AES-Engine auch Gegenmaßnahmen für Dynamic Power Analysis (DPA).

Die AES-Engine unterstützt Hardware- und Softwareschlüssel. Hardwareschlüssel werden aus der UID oder der GID der Secure Enclave hergeleitet. Diese Schlüssel verbleiben in der AES-Engine und sind nicht einmal für die sepOS-Software sichtbar. Die Software kann Funktionen zur Ver- und Entschlüsselung mittels Hardwareschlüssel anfordern, die Schlüssel aber nicht extrahieren.

Bei Apple A10 und neueren SoCs umfasst die AES-Engine sperrbare Seed-Bits, sodass aus der UID oder GID abgeleitete Schlüssel diversifiziert werden können. Dadurch kann der Zugriff auf Daten abhängig vom Betriebsmodus des Geräts erlaubt oder verweigert werden. Auf diese Weise werden beispielsweise sperrbare Seed-Bits verwendet, um beim Starten im DFU-Modus den Zugriff auf passwortgeschützte Daten zu verwehren. Weitere Informationen sind unter Gerätecodes und Passwörter zu finden.

AES-Engine

Jedes Apple-Gerät mit einer Secure Enclave verfügt über eine dedizierte kryptografische AES-256-Engine (die „AES-Engine“), die sich im DMA-Pfad (Direct Memory Access) zwischen dem NAND (nicht flüchtigen) Flash-Speicher und dem Hauptsystemspeicher befindet, was eine höchst effiziente Dateiverschlüsselung ermöglicht. Bei A9-Prozessoren oder Prozessoren einer neueren A-Reihe befindet sich das Subsystem des Flash-Speichers auf einem isolierten Bus, der nur über die DMA Crypto Engine auf den Speicher zugreifen kann, in dem die Benutzerdaten enthalten sind.

Beim Booten generiert das sepOS mithilfe von TRNG einen temporären Verpackungsschlüssel. Die Secure Enclave übermittelt diesen Schlüssel über dedizierte Drähte an die AES-Engine, sodass ein Zugriff durch irgendwelche Software außerhalb der Secure Enclave ausgeschlossen ist. Danach kann das sepOS den temporären Verpackungsschlüssel verwenden, um Dateischlüssel zu verpacken, die vom Dateisystemtreiber des Anwendungsprozessors verwendet werden. Wenn der Dateisystemtreiber eine Datei liest oder schreibt, sendet er den verpackten Schlüssel an die AES-Engine, die ihn entpackt. Die AES-Engine legt den unverpackten Schlüssel nie gegenüber Software offen.

Public Key Accelerator

Der Public Key Accelerator (PKA) ist ein Hardwareblock, der für Operationen der asymmetrischen Kryptografie verwendet wird. Der PKA unterstützt Signier- und Verschlüsselungsalgorithmen auf Basis von RSA und ECC (Elliptic Curve Cryptography, Verschlüsselung mit elliptischen Kurven). Der PKA ist darauf ausgelegt, der Offenlegung von Informationen durch zeitliche Planung oder Seitenkanalattacken wie SPA oder DPA entgegenzuwirken.

Der PKA unterstützt Hardware- und Softwareschlüssel. Hardwareschlüssel werden aus der UID oder der GID der Secure Enclave hergeleitet. Diese Schlüssel verbleiben in der PKA- und sind nicht einmal für die sepOS-Software sichtbar.

Ab SoCs vom Typ A13 ist die mathematische Richtigkeit der PKA-Verschlüsselungsimplementierungen durch formale Verifizierungstechniken nachweisbar.

Bei Apple A10 und neueren SoCs unterstützt der PKA an das Betriebssysteme gebundene Schlüssel, die auch als Sealed Key Protection (SKP) bezeichnet werden. Diese Schlüssel werden generiert, indem die UID des jeweiligen Geräts mit dem Hash-Wert der auf dem Gerät ausgeführten sepOS-Software kombiniert wird. Der Hash-Wert wird vom Boot-ROM der Secure Enclave bzw. bei Apple A13 und neueren SoCs vom Boot-Monitor der Secure Enclave bereitgestellt. Diese Schlüssel werden auch für die Verifizierung der sepOS-Version herangezogen, wenn Anfragen an bestimmte Apple-Dienste gesendet werden. Außerdem werden sie verwendet, um die Sicherheit von Daten zu verbessern, die per Code (Passcode) geschützt sind, indem sie dazu beitragen, den Zugriff auf Verschlüsselungsmaterialien zu verhindern, wenn kritische Systemänderungen ohne Benutzerauthentifizierung vorgenommen werden.

Sicherer nicht flüchtiger Speicher

Die Secure Enclave verfügt über eine dedizierte Einheit mit einem sicheren nicht flüchtigen Speicher. Der sichere nicht flüchtige Speicher ist über einen dedizierten I2C-Bus mit der Secure Enclave verbunden; das bedeutet, dass nur die Secure Enclave auf ihn zugreifen kann. Alle für die Verschlüsselung von Benutzerdaten eingesetzten Schlüssel haben ihren Ursprung in einer Entropie, die im nicht flüchtigen Speicher der Secure Enclave gespeichert ist.

Bei Geräten mit SoCs der Typen A12 und S4 (oder neuer) ist die Secure Enclave mit einer Secure Storage-Komponente gekoppelt, die als Entropiespeicher dient. Die Secure Storage-Komponente ist selbst mit einem unveränderlichem ROM-Code, einem Hardwaregenerator für Zufallszahlen, einem gerätespezifischen kryptografischen Schlüssel, kryptografischen Engines und einem Mechanismus zum Schutz vor physischer Manipulation ausgestattet. Die Secure Enclave und die Secure Storage-Komponente kommunizieren über ein verschlüsseltes und authentifiziertes Protokoll, das den ausschließlichen Zugriff auf die Entropie sicherstellt.

Geräte, die im Herbst 2020 oder später ausgeliefert wurden, sind mit einer Secure Storage-Komponente der zweiten Generation ausgestattet. Diese Secure Storage-Komponente der zweiten Generation stellt zusätzlich Lockboxen für Zähler bereit. Jede dieser Lockboxen enthält einen Salt- und einen Prüfwert für den Code mit jeweils 128 Bit sowie einen 8-Bit-Zähler und einen 8-Bit-Maximalwert. Für den Zugriff auf diese Lockboxen wird ein verschlüsseltes und authentifiziertes Protokoll verwendet.

Zähler-Lockboxen enthalten die Entropie, die für die Entsperrung von codegeschützten Benutzerdaten erforderlich ist. Für den Zugriff auf die Benutzerdaten muss die gekoppelte Secure Enclave den richtigen Entropiewert für den Code aus dem Code des Benutzers und der UID der Secure Enclave herleiten. Der Benutzercode kann nicht durch Entsperrvorgänge bereitgestellt werden, die aus einer anderen Quelle als der gekoppelten Secure Enclave stammen. Wenn die maximale Anzahl der Versuche überschritten wird (z. B. 10 Versuche auf einem iPhone), werden die mit dem Code geschützten Informationen durch die Secure Storage-Komponente vollständig gelöscht.

Zum Erstellen einer solchen Zähler-Lockbox sendet die Secure Enclave den Entropiewert für den Code und den Maximalwert für den Zähler an die Secure Storage-Komponente. Der Secure Storage-Komponente generiert den Salt-Wert mit seinem Generator für Zufallszahlen. Danach leitet er einen Prüfwert für den Code und einen Lockbox-Entropiewert aus dem Entropiewert für den Code, dem eindeutigen kryptografischen Schlüssel der Secure Storage-Komponente und dem Salt-Wert ab. Die Secure Storage-Komponente initialisiert die Zähler-Lockbox mit dem Wert 0, dem bereitgestellten Maximalwert für den Zähler, dem abgeleiteten Prüfwert für den Code und dem Salt-Wert. Im Anschluss übergibt die Secure Storage-Komponente den generierten Lockbox-Entropiewert an die Secure Enclave.

Um zu einem späteren Zeitpunkt den Lockbox-Entropiewert aus der Zähler-Lockbox abzurufen, sendet die Secure Enclave den Entropiewert für den Code an die Secure Storage-Komponente. Die Secure Storage-Komponente erhöht zunächst den Zähler für die Lockbox. Wenn der erhöhte Zählerwert den Maximalwert übersteigt, löscht die Secure Storage-Komponente die Zähler-Lockbox vollständig. Solange die Maximalanzahl an Versuchen nicht überschritten wird, versucht die Secure Storage-Komponente, den Prüfwert für den Code und den Lockbox-Entropiewert mit demselben Algorithmus abzuleiten, der für die Erzeugung der Zähler-Lockbox verwendet wurde. Wenn der abgeleitete Prüfwert für den Code mit dem hinterlegten Prüfwert für den Code übereinstimmt, gibt die Secure Storage-Komponente den Lockbox-Entropiewert zurück an die Secure Enclave und setzt den Zähler wieder auf 0 zurück.

Die Schlüssel, die für den Zugriff auf passwortgeschützte Daten verwendet werden, haben ihren Ursprung in der in Zähler-Lockboxen hinterlegten Entropie. Weitere Informationen sind unter Datensicherheit – Übersicht zu finden.

Der sichere nicht flüchtige Speicher wird für alle Anti-Replay-Dienste in der Secure Enclave verwendet. Anti-Replay-Dienste in der Secure Enclave werden zum Widerrufen von Daten zu Ereignissen verwendet, die Anti-Replay-Grenzen markieren. Dazu gehören unter anderem:

• Codeänderungen

• Aktivieren oder Deaktivieren von Face ID oder Touch ID

• Hinzufügen oder Entfernen von Gesichtsdaten in Face ID oder Fingerabdruckdaten in Touch ID

• Zurücksetzen von Face ID oder Touch ID

• Hinzufügen oder Entfernen einer Karte in Apple Pay

• Löschen aller Inhalte und Einstellungen

In Architekturen ohne Secure Storage-Komponente wird das EEPROM (electrically erasable programmable read-only memory) eingesetzt, um der Secure Enclave sichere Speicherdienste bereitzustellen. Das EEPROM ist genau wie die Secure Storage-Komponente ausschließlich über die Secure Enclave erreichbar und mit ihr verbunden. Es enthält allerdings weder dedizierte Hardwaresicherheitsfunktionen noch kann es exklusiven Zugriff auf die Entropie (über ihre physischen Verbindungscharakteristiken hinaus) oder die Zähler-Lockbox-Funktionen bieten.

Secure Neural Engine

Bei Geräten mit Face ID (nicht jedoch auf Geräten mit Touch ID) konvertiert die Secure Neural Engine (sichere neuronale Engine) 2D-Bilder und Tiefendarstellungen in die mathematische Darstellung des Gesichts eines Benutzers.

Bei SoCs der Typen A11 bis A13 ist die Secure Neural Engine in die Secure Enclave integriert. Im Interesse einer hohen Leistung verwendet die Secure Neural Engine den direkten Zugriff (DMA, Direct Memory Access). Eine IOMMU-Einheit (zur Eingabe-Ausgabe-Speicherverwaltung), die der Steuerung des sepOS-Kernels untersteht, beschränkt diesen direkten Zugriff auf autorisierte Speicherregionen.

Ab A14 und der M1-Familie ist die Secure Neural Engine als sicherer Modus in die neuronale Engine des Anwendungsprozessors implementiert. Ein dedizierter Controller zur Wahrung der Hardwaresicherheit bewirkt das Umschalten zwischen Anfragen des Anwendungsprozessors und solchen der Secure Enclave, wobei bei jedem Wechsel der Status der neuronalen Engine zurückgesetzt wird, um die Sicherheit der Face ID-Daten auf Dauer zu wahren. Eine dedizierte Engine übernimmt die Speicherverschlüsselung, die Authentifizierung und die Zugriffssteuerung. Gleichzeitig kommen ein separater kryptografischer Schlüssel und ein Speicherbereich zum Einsatz, um die Secure Neural Engine auf autorisierte Speicherregionen zu beschränken.

Strom- und Taktmonitore

Die gesamte Elektronik ist für den Betrieb innerhalb eines bestimmten Netzspannungs- und Netzfrequenzbereichs ausgelegt. Beim Betrieb außerhalb des vorgegebenen Bereichs kann es zu Fehlfunktionen der Elektronik mit dem Ergebnis kommen, dass Sicherheitsvorkehrungen umgangen werden können. Die Secure Enclave ist mit auf das Monitoring ausgelegten Schaltkreisen ausgestattet, die sicherstellen, dass Netzspannung und Netzfrequenz in einem sicheren Bereich verbleiben. Diese für das Monitoring verwendeten Schaltkreise sind für einen sehr viel größeren Spannungs- und Frequenzbereich ausgelegt als die übrigen Bestandteile der Secure Enclave. Beim Erkennen eines illegalen Betriebspunkts werden die Taktgeber der Secure Enclave automatisch gestoppt; sie können bis zum nächsten Zurücksetzen des SoCs nicht neu gestartet werden.

Secure Enclave – Funktionsübersicht