Sealed Key Protection (SKP)
Auf Apple-Geräten, die Datensicherheit unterstützen, wird der Key Encryption Key (KEK) mit Kennzahlen der auf dem System installierten Software sowie der Verknüpfung mit der UID geschützt (oder „versiegelt“), die nur von der Secure Enclave bereitgestellt werden kann. Auf einem Mac mit Apple Chips wird der Schutz des KEK weiter verstärkt, indem Informationen über die Sicherheitsrichtlinie des Systems einbezogen werden, da macOS kritische Änderungen von Sicherheitsrichtlinien (z. B. das Deaktivieren des sicheren Startvorgangs oder von SIP) unterstützt, die von anderen Plattformen nicht unterstützt werden. Auf einem Mac mit Apple Chips umfasst dieser Schutz auch FileVault-Schlüssel, da FileVault unter Verwendung von Datensicherheit (Klasse C) implementiert wird.
Der Schlüssel, der auf der Verknüpfung von Benutzerpasswort, SKP-Langzeitschlüssel und Hardwareschlüssel 1 (die UID der Secure Enclave) basiert, wird als passwortbasierter Schlüssel bezeichnet. Dieser Schlüssel wird verwendet, um den Keybag „User“ (auf allen unterstützten Plattformen) und den KEK (nur in macOS) zu schützen und das biometrische Entsperren oder automatische Entsperren mit anderen Geräten wie z. B. der Apple Watch zu aktivieren.
Der Boot-Monitor der Secure Enclave erfasst die Kennzahlen des Betriebssystems der Secure Enclave, das geladen wird. Wenn der Boot-ROM des Anwendungsprozessors das Image4-Manifest erfasst, das an LLB gekoppelt ist, enthält dieses Manifest auch die Kennzahlen aller anderen mit dem System gekoppelten Firmwarekomponenten, die geladen werden. Die LocalPolicy-Datei – die lokale Richtlinie - umfasst die zentralen Sicherheitskonfigurationen des macOS-Betriebssystems, die geladen werden. Diese lokale Richtlinie enthält außerdem das nsih-Feld, eine Hash-Darstellung des Image4-Manifests von macOS. Das Image4-Manifest von macOS umfasst die Kennzahlen aller mit macOS gekoppelten Firmwarekomponenten und der zentralen Startobjekte von macOS, zum Beispiel die Boot Kernel-Sammlung und den Root-Hash-Wert des Signed System Volume (SSV).
Wenn es einem Angreifer wider aller Erwartungen gelingt, eine der o. g. gemessenen Firmware-, Software- oder Sicherheitskonfigurationskomponenten zu ändern, führt dies zu einer Änderung der Kennzahlen, die in den Hardwareregistern gespeichert sind. Die Modifikation der Kennzahlen bewirkt, dass der per Kryptohardware hergeleitete SMRK-Schlüssel (System Measurement Root Key) auf einen anderen Wert abgeleitet wird und so das Seal (Siegel) in der Schlüsselhierarchie gebrochen wird. Dadurch wird der SMDK-Schlüssel (System Measurement Device Key) unzugänglich, was wiederum dazu führt, dass der KEK und somit die Daten für den Angreifer unzugänglich werden.
Allerdings muss das System, wenn es nicht angegriffen wird, die Möglichkeit zu legitimen Softwareaktualisierungen bieten, die die Kennzahlen der Firmware und das nsih-Feld in der lokalen Richtlinie so ändern, dass sie auf neue macOS-Kennzahlen verweisen. Bei anderen Systemen, die versuchen, Kennzahlen ihrer Firmware einzubinden, die aber keine als verlässlich oder gut klassifizierte Quelle der Wahrheit haben, muss der Benutzer die Sicherheitsfunktionen deaktivieren, die Firmware aktualisieren und eine erneute Aktivierung vornehmen, damit die neue Ausgangsbasis der Kennzahlen erfasst werden kann. Dadurch steigt das Risiko, dass ein Angreifer die Firmware während einer Softwareaktualisierung kompromittieren kann, in signifikanter Weise. Das System profitiert von der Tatsache, dass die Image4-Manifeste alle benötigten Kennzahlen umfassen. Die Hardware, die bei einem normalen Startvorgang bei übereinstimmenden Kennzahlen den SMDK mithilfe des SMRK entschlüsselt, kann auch verwendet werden, um den SMDK im Hinblick auf einen vorgeschlagenen künftigen SMRK zu verschlüsseln. Indem die Kennzahlen bereitgestellt werden, die nach einer Softwareaktualisierung erwartet werden, kann die Hardware einen SMDK, der in einem aktuellen Betriebssystem zugänglich ist, so verschlüsseln, dass er auch in einem künftigen Betriebssystem zugänglich bleibt. Analog gilt dies auch für den Fall, dass ein Kunde legitim Änderungen an den eigenen Sicherheitseinstellungen in der lokalen Richtlinie vornimmt. In diesem Fall muss der SMDK im Hinblick auf den zukünftigen SMRK verschlüsselt werden; Ausgangspunkt hierfür sind die Kennzahlen in der LocalPolicy-Datei, die LLB beim nächsten Neustart errechnen wird.