Startvorgang von einem Mac mit Apple Chips
Der Startvorgang beim Einschalten eines Mac mit Apple Chips ist dem Startvorgang eines iPhone- oder iPad-Geräts sehr ähnlich.
Im ersten Schritt in der Chain of Trust führt der Chip Code aus dem Boot-ROM aus. Der sichere macOS-Startvorgang auf einem Mac mit Apple Chips verifiziert nicht nur den Code des Betriebssystems selbst, sondern auch die Sicherheitsrichtlinien und sogar Kernel-Erweiterungen (unterstützt, aber nicht empfohlen), die von autorisierten Benutzern konfiguriert wurden.
Beim Starten von LLB (Low-Level-Bootstrap) werden die Signaturen überprüft und mit dem System gekoppelte Firmware-Objekte für Intra-SoC-Kerne wie beispielsweise die Controller für Festspeicher, Display, Systemverwaltung und Thunderbolt geladen. LLB ist auch verantwortlich für das Laden der LocalPolicy-Datei (der lokalen Richtlinie), bei der es sich um eine Datei handelt, die von der Secure Enclave signiert wird. Die LocalPolicy-Datei beschreibt die Konfiguration, die der Benutzer im Hinblick auf die Sicherheitsrichtlinien für den Systemstart und die Laufzeit ausgewählt hat. Diese lokale Richtlinie (LocalPolicy) weist dasselbe Datenstrukturformat auf wie alle anderen Startobjekte, wird aber nicht (wie Softwareaktualisierungen) von einem zentralen Apple-Server, sondern lokal mithilfe eines privaten Schlüssels signiert, der nur innerhalb der Secure Enclave des jeweiligen Computers verfügbar ist.
Um das Replay einer früheren LocalPolicy-Datei zu verhindern, muss LLB eine Nonce aus der an die Secure Enclave angeschlossenen Secure Storage-Komponente abrufen. Für diesen Zweck verwendet iBoot den Boot-ROM der Secure Enclave; iBoot stellt sicher, dass die Nonce in der LocalPolicy-Datei mit der Nonce in der Secure Storage-Komponente übereinstimmt. Auf diese Weise wird verhindert, dass eine ältere lokale Richtlinie, die möglicherweise für ein niedrigeres Sicherheitsniveau konfiguriert wurde, erneut auf das System angewendet wird, nachdem dessen Sicherheitsniveau per Upgrade erhöht wurde. Dies hat zum Ergebnis, dass der sichere Startvorgang auf einem Mac mit Apple Chips nicht nur vor Rollbacks von Betriebssystemversionen, sondern auch vor der Herabstufung von Sicherheitsrichtlinien schützt.
Die lokale Richtlinie erfasst, für welches Sicherheitsniveau das Betriebssystem konfiguriert ist – „Volle Sicherheit“, „Reduzierte Sicherheit“ oder „Permissive Sicherheit“.
Volle Sicherheit: Das System verhält sich wie iOS und iPadOS und lässt nur das Starten von Software zu, die zum Zeitpunkt ihrer Installation als die neueste Version klassifiziert war.
Reduzierte Sicherheit: LLB wird angewiesen, „globalen“ Signaturen zu vertrauen, die an das Betriebssystem gekoppelt sind. Dies ermöglicht es dem System, ältere Versionen von macOS auszuführen. Ältere Versionen von macOS weisen unweigerlich nicht behobene Sicherheitslücken auf; aus diesem Grund ist die Rede von „reduzierter Sicherheit“. Dies ist auch die Richtlinienebene, die erforderlich ist, um das Booten von Kernel-Erweiterungen zu unterstützen.
Permissive Sicherheit: Das Verhalten des Systems ähnelt insofern dem Verhalten bei reduzierter Sicherheit, als für iBoot und darüber hinaus die Prüfung globaler Signaturen verwendet wird. Anders als bei der reduzierten Sicherheit wird iBoot aber angewiesen zu akzeptieren, dass bestimmte Startobjekte durch die Secure Enclave mit demselben Schlüssel signiert werden, mit dem die LocalPolicy-Datei signiert ist. Diese Richtlinienebene unterstützt das Erstellen, Signieren und Starten eigener XNU-Kernel durch Benutzer.
Wenn sich für LLB aus der lokalen Richtlinie ergibt, dass das ausgewählte Betriebssystem im Modus „Volle Sicherheit“ ausgeführt wird, evaluiert LLB die personalisierte Signatur für iBoot. Bei der Ausführung im Modus „Reduzierte Sicherheit“ oder „Permissive Sicherheit“ wird die globale Signatur evaluiert. Jeglicher Fehler bei der Signaturprüfung führt dazu, dass recoveryOS gestartet wird und Optionen für die Reparatur bereitgestellt werden.
Nach der Übergabe der Steuerung von LLB an iBoot werden an macOS gekoppelte Firmware-Objekte wie die Secure Neural Engine, der „Always On“-Prozessor und andere Firmware gestartet. iBoot überprüft auch die Informationen bezüglich der LocalPolicy-Datei, die von LLB an iBoot übergeben wird. Wenn aus der lokalen Richtlinie hervorgeht, dass eine Auxiliary Kernel Collection (AuxKC) vorhanden sein müsste, sucht iBoot im Dateisystem nach diesem Cache und stellt sicher, dass er in der Secure Enclave mit demselben Schlüssel wie in der LocalPolicy-Datei signiert wurde und dass der Hash-Wert mit dem in der LocalPolicy-Datei enthaltenen Hash-Wert übereinstimmt. Wenn die Prüfung des AuxKC erfolgreich ist, platziert iBoot diesen Cache zusammen mit der Boot Kernel-Sammlung im Arbeitsspeicher, bevor die gesamte Speicherregion mit Boot Kernel-Sammlung und AuxKC per System Coprocessor Integrity Protection (SCIP) gesperrt wird. Wenn aus der Richtlinie hervorgeht, dass ein AuxKC vorhanden sein müsste, er aber nicht gefunden wird, setzt das System das Starten von macOS ohne diesen Cache fort. iBoot ist auch verantwortlich für die Prüfung des Root-Hash-Werts des Signed System Volume (SSV), damit die Integrität des Dateisystems, das der Kernel aktiviert, in vollem Umfang gewährleistet ist.