Inhalt einer LocalPolicy-Datei für Mac-Computer mit Apple Chips

Übergabe des Eigentümerstatus zwischen Betriebssystemen

Der Zugriff auf den OIK (Owner Identity Key) wird als „Eigentümerstatus“ bezeichnet. Der Eigentümerstatus ist notwendig, um es Benutzern zu erlauben, die LocalPolicy-Datei nach dem Ändern der Richtlinie oder Software erneut zu signieren. Der OIK wird mit derselben Schlüsselhierarchie geschützt, die unter Sealed Key Protection (SKP) beschrieben ist. Dabei wird der OIK mit demselben KEK (Key Encryption Key) wie der VEK (Volume Encryption Key) geschützt. Das bedeutet, dass er im Normalfall sowohl mit den Benutzerpasswörtern als auch den Spezifikationen des Betriebssystems und der Richtlinie geschützt ist. Es gibt nur einen OIK für alle Betriebssysteme auf dem Mac. Aus diesem Grund ist beim Installieren eines zweiten Betriebssystems die ausdrückliche Zustimmung des Benutzers auf dem ersten Betriebssystem erforderlich, um den Eigentümerstatus an den Benutzer auf dem zweiten Betriebssystem zu übergeben. Allerdings existieren für das zweite Betriebssystem noch keine Benutzer, wenn das Installationsprogramm auf dem ersten Betriebssystem ausgeführt wird. Benutzer werden in Betriebssystemen normalerweise erst generiert, wenn das Betriebssystem gestartet und der Systemassistent ausgeführt wurde. Daher sind zwei neue Schritte erforderlich, wenn ein zweites Betriebssystem auf einem Mac mit Apple Chips installiert wird:

• LocalPolicy-Datei für das zweite Betriebssystem erstellen

• Benutzerinstallation („Install User“) für die Übergabe des Eigentümerstatus vorbereiten

Wenn ein Installationsassistent gestartet und eine Installation auf einem zweiten leeren Volume durchgeführt wird, wird der Benutzer gefragt, ob er einen Benutzer vom aktuellen Volume auf das zweite Volume als erster Benutzer kopieren möchte. Wenn der Benutzer dies bestätigt, wird die Benutzerinstallation (eigentlich ein vom Passwort und den Hardwareschlüsseln des ausgewählten Benutzers abgeleiteter KEK) für die Verschlüsselung des OIK verwendet, wenn dieser an das zweite Betriebssystem übergeben wird. Im Anschluss fragt der Installationsassistent des zweiten Betriebssystems nach dem Passwort dieses Benutzers, um den Zugriff auf den OIK in der Secure Enclave durch das neue Betriebssystem zu erlauben. Wenn sich Benutzer gegen das Kopieren eines Benutzers entscheiden, wird die Benutzerinstallation trotzdem auf dieselbe Weise ausgeführt, allerdings wird ein leeres Passwort anstatt eines Benutzerpassworts verwendet. Der zweite Prozess ist für bestimmte Systemadministrationsszenarien konzipiert. Benutzer, die Installationen auf verschiedenen Volumes verwenden und die Übergabe des Eigentumsstatus auf die sicherste Art und Weise durchführen möchten, sollten immer einen Benutzer vom ersten Betriebssystem auf das zweite Betriebssystem kopieren.

LocalPolicy-Datei auf einem Mac mit Apple Chips

Bei einem Mac mit Apple Chips wurde die Steuerung für die lokale Sicherheitsrichtlinie an eine Anwendung übergeben, die in der Secure Enclave ausgeführt wird. Diese Software kann ausgehend von den Anmeldeinformationen des Benutzers und dem Startmodus der primären CPU feststellen, wer die Sicherheitsrichtlinie ändern kann und aus welcher Startumgebung heraus dies möglich ist. Dadurch kann verhindert werden, dass Schadsoftware die Steuerung für die Sicherheitsrichtlinie gegen den Benutzer einsetzen kann, indem der Benutzer herabgestuft wird, um danach zusätzliche Rechte und Berechtigungen zu erhalten.

Eigenschaften des LocalPolicy-Manifests

Die LocalPolicy-Datei umfasst einige architekturelle 4CCs, die in nahezu allen Image4-Dateien zu finden sind – beispielsweise Board- oder Modellkennung (BORD), Angabe eines bestimmten Apple-Chips (CHIP) oder Exclusive Chip Identification (ECID). Die im Folgenden beschriebenen 4CCs beschränken sich allerdings auf die Sicherheitsrichtlinien, die vom Benutzer konfiguriert werden können.

LocalPolicy Nonce Hash (lpnh)

• Typ: OctetString (48)

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: lpnh wird als Maßnahme gegen das Anti-Replay der LocalPolicy-Datei eingesetzt. Hierbei handelt es sich um einen SHA-384-Hash-Wert der Nonce der lokalen Richtlinie (LPN, Local Policy Nonce), der in der Secure Storage-Komponente gespeichert ist und über den Boot-ROM der Secure Enclave oder die Secure Enclave zugänglich ist. Die eigentliche Nonce wird nur gegenüber sepOS, niemals gegenüber dem Anwendungsprozessor offengelegt. Ein Angreifer, der LLB dahingehend manipulieren möchte, dass eine frühere von ihm abgegriffene LocalPolicy-Datei gültig ist, müsste somit einen Wert in der Secure Storage-Komponente platzieren, dessen Hash-Wert identisch mit dem lpnh-Wert aus der lokalen Richtlinie ist, deren Replay ausgelöst werden soll. Im Normalfall ist nur eine einzige LPN im System gültig. Eine Ausnahme dazu besteht nur während einer Softwareaktualisierung. Während dieses Vorgangs sind zwei LPNs gleichzeitig gültig, damit es im Fall eines Fehlers bei der Aktualisierung möglich ist, wieder die alte Software zu starten. Wenn die LocalPolicy-Datei irgendeines Betriebssystems geändert wird, werden alle Richtlinien mit dem neuen lpnh-Wert signiert, der mit dem neuen LPN in der Secure Storage-Komponente korrespondiert. Diese Änderung erfolgt, wenn der Benutzer Änderungen an den Sicherheitseinstellungen vornimmt oder neue Betriebssysteme mit einer jeweils neuen LocalPolicy-Datei erstellt.

Remote Policy Nonce Hash (rpnh)

• Typ: OctetString (48)

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: rpnh zeigt das gleiche Verhalten wie lpnh; dieser Wert wird aber nur aktualisiert, wenn die Remote-Richtlinie aktualisiert wird. Das ist zum Beispiel der Fall, wenn der Status der Registrierung für „Wo ist?“ geändert wird. Diese Änderung erfolgt implizit, wenn der Benutzer auf seinem Mac den Status von „Wo ist?“ ändert.

recoveryOS Nonce Hash (ronh)

• Typ: OctetString (48)

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: ronh zeigt das gleiche Verhalten wie „lpnh“; dieser Wert ist aber ausschließlich in der lokalen Richtlinie für das recoveryOS des Systems enthalten. Er wird aktualisiert, wenn recoveryOS des Systems (zum Beispiel im Zuge einer Softwareaktualisierung) aktualisiert wird. Die Verwendung dieser separaten Nonce (neben lpnh und rpnh) hat folgenden Grund: Wenn ein Gerät mit „Wo ist?“ in den Status „Deaktiviert“ versetzt wird, können vorhandene Betriebssysteme deaktiviert werden (indem ihre LPN und RPN aus der Secure Storage-Komponente entfernt werden), während zugleich das recoveryOS des Systems seine Startfähigkeit behält. Auf diese Weise können die Betriebssysteme wieder aktiviert werden, wenn der Benutzer des Systems den Nachweis erbringt, dass sich das Gerät wieder unter seiner Kontrolle und Steuerung befindet, indem er das iCloud-Passwort eingibt, das für den „Wo ist?“-Account hinterlegt ist. Diese Änderung erfolgt, wenn ein Benutzer das recoveryOS des Systems aktualisiert oder neue Betriebssysteme erstellt.

Next Stage Image4 Manifest Hash (nsih)

• Typ: OctetString (48)

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: Das Feld „nsih“ steht für den SHA-384-Hash-Wert der Image4-Manifestdatenstruktur, die das gestartete macOS-Betriebssystem beschreibt. Das Image4-Manifest für macOS enthält Kennzahlen für alle Startobjekte (zum Beispiel für iBoot, den statischen Cache für die Vertrauensstellung („Static Trust Cache“), die Gerätestruktur („Device Tree“), die Boot Kernel-Sammlung und den Root-Hash-Wert des Signed System Volume (SSV)). Wenn LLB instruiert wird, ein bestimmtes macOS-Betriebssystem zu starten, stellt LLB sicher, dass der Hash-Wert des Image4-Manifests für macOS, das an iBoot angehängt ist, mit dem Wert übereinstimmt, der im nsih-Feld der LocalPolicy-Datei erfasst ist. Auf diesem Weg erfasst nsih die Absicht des Benutzers, für welches Betriebssystem er eine lokale Richtlinie (LocalPolicy-Datei) erstellt hat. Der nsih-Wert wird implizit geändert, wenn eine Softwareaktualisierung durchgeführt wird.

Cryptex1 Image4 Manifest Hash (spih)

• Typ: OctetString (48)

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: Das Feld spih steht für den SHA-384-Hash-Wert der Image4-Manifestdatenstruktur. Das Cryptex1-Image4-Manifest enthält Kennzahlen seiner Cryptexes, ihrer Dateisystem-Seals (Siegel) und ihrer Caches für die Vertrauensstellung. Während des Startvorgangs von macOS stellen der XNU-Kernel und die PPL (Page Protection Layer) sicher, dass der Hash-Wert des Cryptex1-Image4-Manifests mit dem Wert übereinstimmt, den iBoot gemäß dem spih-Feld der LocalPolicy-Datei veröffentlicht hat. Der spih-Wert wird implizit geändert, wenn eine schnelle Sicherheitsmaßnahme (Rapid Security Response) installiert oder eine Softwareaktualisierung durchgeführt wird. Der Cryptex1 Image4 Manifest Hash kann unabhängig vom Next Stage Image4 Manifest Hash (nsih) aktualisiert werden.

Cryptex1 Generation (stng)

• Typ: Unsignierte 64-Bit-Ganzzahl

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: Das Feld stng enthält einen Zählerwert, der angibt, wann der Cryptex1 Image4 Manifest Hash zuletzt in der LocalPolicy-Datei aktualisiert wurde. Es stellt eine Nonce anstelle von lpnh bereit, während die PPL (Page Protection Layer) die lokale Richtlinie für die Anwendung des eingehenden Cryptex auswertet. Der stng-Wert wird implizit geändert, wenn eine schnelle Sicherheitsmaßnahme (Rapid Security Response) installiert oder eine Softwareaktualisierung durchgeführt wird.

Auxiliary Kernel Collection (AuxKC) Policy Hash (auxp)

• Typ: OctetString (48)

• Veränderbare Umgebungen: macOS

• Beschreibung: auxp ist ein SHA-384-Hash-Wert der Richtlinie für die Liste der vom Benutzer autorisierten Kernel-Erweiterungen (UAKL, User-authorized KEXT list). Dieser Wert wird zum Zeitpunkt der AuxKC-Generierung verwendet, um sicherzustellen, dass nur Kernel-Erweiterungen (KEXTs) in die AuxKC übernommen werden, die vom Benutzer autorisiert wurden. smb2 ist erforderlich, um dieses Feld festlegen zu können. Der auxp-Wert wird implizit geändert, wenn der Benutzer die UAKL-Liste ändert, indem er in „Systemeinstellungen“ > „Datenschutz & Sicherheit“ (macOS 13 oder neuer) oder „Systemeinstellungen“ > „Sicherheit & Datenschutz“ (macOS 12 oder älter) eine Kernel-Erweiterung genehmigt.

Auxiliary Kernel Collection (AuxKC) Image4 Manifest Hash (auxi)

• Typ: OctetString (48)

• Veränderbare Umgebungen: macOS

• Beschreibung: Nachdem das System verifiziert hat, dass der Hash-Wert der UAKL mit dem Wert im Feld auxp der lokalen Richtlinie übereinstimmt, veranlasst es, dass die AuxKC vom Prozessor der Secure Enclave signiert wird, der für das Signieren der LocalPolicy-Datei zuständig ist. Danach wird ein SHA-384-Hash-Wert der Image4-Manifestsignatur der AuxKC in der lokalen Richtlinie platziert um die Möglichkeit einer Verwechslung und des fälschlichen Abgleichs einer zu einem früheren Zeitpunkt signierten AuxKC mit einem Betriebssystem auszuschließen. Wenn iBoot das Feld auxi in der lokalen Richtlinie vorfindet, versucht iBoot, die AuxKC vom Speichermedium zu laden und deren Signatur zu validieren. Außerdem wird geprüft, ob der Hash-Wert des an den AuxKC angeschlossenen Image4-Manifests mit dem Wert im Feld auxi übereinstimmt. Wenn die AuxKC aus irgendeinem Grund nicht geladen werden kann, setzt das System den Startvorgang ohne dieses Startobjekt fort, d. h. ohne dass irgendwelche Kernel-Erweiterung von Drittanbietern geladen werden. Das Feld auxp muss vorhanden sein, damit das Feld „auxi“ in der LocalPolicy-Datei festgelegt werden kann. Der auxi-Wert wird implizit geändert, wenn der Benutzer die UAKL-Liste ändert, indem er in „Systemeinstellungen“ > „Datenschutz & Sicherheit“ (macOS 13 oder neuer) oder „Systemeinstellungen“ > „Sicherheit & Datenschutz“ (macOS 12 oder älter) eine Kernel-Erweiterung genehmigt.

Auxiliary Kernel Collection (AuxKC) Receipt Hash (auxr)

• Typ: OctetString (48)

• Veränderbare Umgebungen: macOS

• Beschreibung: auxr ist ein SHA-384-Hash-Wert des AuxKC-Empfangsbelegs; aus ihm geht hervor, welcher Satz von Kernel-Erweiterungen genau in die AuxKC aufgenommen wurde. Bei dem AuxKC-Beleg kann es sich um eine Untermenge der UAKL-Liste handeln, da Kernel-Erweiterungen, die bekanntermaßen für Angriffe genutzt werden können, aus der AuxKC ausgeschlossen werden können, selbst wenn sie vom Benutzer autorisiert wurden. Außerdem können bestimmte Kernel-Erweiterungen, die dafür verwendet werden können, die Begrenzung des Benutzer-Kernels zu umgehen, eine funktionale Einschränkung zur Folge haben, sodass beispielsweise Apple Pay nicht verwendet und 4K/HDR-Inhalte nicht wiedergegeben werden können. Benutzer, die von entsprechenden Möglichkeiten Gebrauch machen möchten, sollten sich für eine restriktivere Form der Aufnahme in die AuxKC entscheiden. Das Feld auxp muss vorhanden sein, damit das Feld auxr in der LocalPolicy-Datei festgelegt werden kann. Der auxr-Wert wird implizit geändert, wenn der Benutzer über „Systemeinstellungen“ > „Datenschutz & Sicherheit“ (macOS 13 oder neuer) oder „Systemeinstellungen“ > „Sicherheit & Datenschutz“ (macOS 12 oder älter) eine neue AuxKC erstellt.

CustomOS Image4 Manifest Hash (coih)

• Typ: OctetString (48)

• Veränderbare Umgebungen: 1TR

• Beschreibung: coih ist ein SHA-384-Hash des CustomOS-Image4-Manifest. Die Payload für dieses Manifest wird von iBoot (anstelle des XNU-Kernels) verwendet, um die Steuerung zu übergeben. Der coih-Wert wird implizit geändert, wenn der Benutzer das kmutil configure-boot-Befehlszeilenprogramm in 1TR verwendet.

APFS volume group UUID (vuid)

• Typ: OctetString (16)

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: vuid ist die Volumegruppe, die der Kernel als Root (Stamm) verwenden soll. Dieses Feld dient primär der Information; es wird nicht für sicherheitsrelevante Einschränkungen verwendet. Die Festlegung der vuid erfolgt implizit, wenn der Benutzer eine neue Betriebssysteminstallation erstellt.

Key encryption key (KEK) Group UUID (kuid)

• Typ: OctetString (16)

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: kuid ist das gestartete Volume. Der Key Encryption Key wird üblicherweise für Zwecke des Datenschutzes und der Datensicherheit verwendet. Bei jeder LocalPolicy-Datei wird er verwendet, um den Signierschlüssel der lokalen Richtlinie zu schützen. Die Festlegung der kuid erfolgt implizit, wenn der Benutzer eine neue Betriebssysteminstallation erstellt.

Paired recoveryOS Trusted Boot Policy Measurement (prot)

• Typ: OctetString (48)

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: Das Trusted Boot Policy Measurement der gekoppelten recoveryOS-Software ist eine spezielle iterative SHA-384-Hash-Berechnung auf der Basis des Image4-Manifests einer lokalen Richtlinie und unter Ausschluss von Nonces, um eine konsistente Messung im Zeitablauf zu erhalten (da Nonces wie lpnh häufig aktualisiert werden). Das Feld prot ist nur in lokalen Richtlinien für macOS enthalten und enthält eine Angabe, welche LocalPolicy-Datei für recoveryOS mit welcher LocalPolicy-Datei für macOS korrespondiert.

Has Secure Enclave Signed recoveryOS Local Policy (hrlp)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: hrlp gibt an, ob der oben beschriebene prot-Wert eine Kennzahl für die LocalPolicy-Datei für eine durch die Secure Enclave signierte recoveryOS-Software ist oder nicht. Ist dies nicht der Fall, wird die LocalPolicy-Datei von recoveryOS vom Apple Online-Signierungsserver signiert, der Objekte wie macOS Image4-Dateien signiert.

Local Operating System Version (love)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR, recoveryOS, macOS

• Beschreibung: love zeigt die Version des Betriebssystems an, für das die lokale Richtlinie (LocalPolicy) erstellt wurde. Die Version wird von dem nächsten Statusmanifest während der Erstellung der LocalPolicy abgerufen und verwendet, um die Kopplungseinschränkungen für das recoveryOS umzusetzen.

Secure Multi-Boot (smb0)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR, recoveryOS

• Beschreibung: Wenn smb0 vorhanden ist und den Wert „True“ enthält, lässt LLB es zu, dass das nsih-Manifest (Next stage Image4) global signiert wird und keine personalisierte Signatur erforderlich ist. Dieses Feld kann vom Benutzer mit dem Startsicherheitsdienstprogramm oder mit bputil geändert werden, um die Herabstufung auf „Reduzierte Sicherheit“ vorzunehmen.

Secure Multi-Boot (smb1)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR

• Beschreibung: Wenn smb1 vorhanden ist und den Wert „True“ enthält, lässt iBoot es zu, dass Objekte wie beispielsweise eine angepasste Kernel-Sammlung in der Secure Enclave mit demselben Schlüssel wie die LocalPolicy-Datei signiert wird. Das Feld smb1 kann nur vorhanden sein, wenn das Feld smb0 vorhanden ist. Dieses Feld kann vom Benutzer mit dem Befehlszeilenprogramm csrutil oder bputil geändert werden, um die Herabstufung auf „Permissive Sicherheit“ vorzunehmen.

Secure Multi-Boot (smb2)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR

• Beschreibung: Wenn smb2 vorhanden ist und den Wert „True“ enthält, lässt iBoot es zu, dass die Auxiliary Kernel Collection in der Secure Enclave mit demselben Schlüssel wie die LocalPolicy-Datei signiert wird. Das Feld smb2 kann nur vorhanden sein, wenn das Feld smb0 vorhanden ist. Dieses Feld kann vom Benutzer mit dem Startsicherheitsdienstprogramm oder bputil geändert werden, um die Herabstufung auf „Reduzierte Sicherheit“ vorzunehmen und Kernel-Erweiterungen von Drittanbietern zu aktivieren.

Secure Multi-Boot (smb3)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR

• Beschreibung: Wenn smb3 vorhanden ist und den Wert „True“ enthält, bedeutet dies, dass sich ein Benutzer auf dem System für die Registrierung in einer MDM-Lösung (Mobile Device Management) entschieden hat. Das Vorhandensein dieses Felds bewirkt, dass die Prozessoranwendung der Secure Enclave, die die LocalPolicy-Datei steuert, die Authentifizierung über die MDM-Lösung anstelle der lokalen Benutzerauthentifizierung akzeptiert. Dieses Feld kann vom Benutzer mit dem Startsicherheitsdienstprogramm oder mit bputil geändert werden, um die verwaltete Steuerung für Kernel-Erweiterungen von Drittanbietern und von Softwareaktualisierungen zu aktivieren. (In macOS 11.2 (oder neuer) kann die MDM-Lösung auch eine Aktualisierung auf die neueste macOS-Version veranlassen, wenn als Sicherheitsmodus „Volle Sicherheit“ ausgewählt ist.)

Secure Multi-Boot (smb4)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: macOS

• Beschreibung: Wenn smb4 vorhanden ist und den Wert „True“ enthält, bedeutet dies, dass das Gerät über Apple School Manager, Apple Business Manager oder Apple Business Essentials in einer MDM-Lösung registriert wurde und von ihr gesteuert wird. Das Vorhandensein dieses Felds bewirkt, dass die Anwendung der Secure Enclave, die die LocalPolicy-Datei steuert, die Authentifizierung über die MDM-Lösung anstelle der lokalen Benutzerauthentifizierung akzeptiert. Dieses Feld wird durch die MDM-Lösung geändert, wenn sie erkennt, dass die Seriennummer des Geräts in einem dieser drei Dienste erscheint.

System Integrity Protection (sip0)

• Typ: Unsignierte 64-Bit-Ganzzahl

• Veränderbare Umgebungen: 1TR

• Beschreibung: sip0 umfasst die Bits der SIP-Richtlinie (System Integrity Protection, Systemintegritätsschutz), die bisher im NVRAM gespeichert wurden. Neue SIP-Richtlinienbits werden hier hinzugefügt (und nicht in die nachfolgend beschriebenen Felder der lokalen Richtlinie), wenn sie ausschließlich von macOS und nicht auch von LLB verwendet werden. Dieses Feld kann von einem Benutzer mit csrutil aus 1TR geändert werden, um SIP zu deaktivieren und die Herabstufung auf „Permissive Sicherheit“ vorzunehmen.

System Integrity Protection (sip1)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR

• Beschreibung: Wenn sip1 vorhanden ist und den Wert „True“ enthält, lässt iBoot Fehler beim Prüfen des Hash-Werts des SSV zu. Dieses Feld kann von einem Benutzer mit csrutil oder bputil aus 1TR geändert werden.

System Integrity Protection (sip2)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR

• Beschreibung: Wenn sip2 vorhanden ist und den Wert „True“ enthält, sperrt iBoot nicht das Hardwareregister CTRR (Configurable Text Read-only Region), das Kernelspeicher als nicht beschreibbar markiert. Dieses Feld kann von einem Benutzer mit csrutil oder bputil aus 1TR geändert werden.

System Integrity Protection (sip3)

• Typ: Boolescher Wert

• Veränderbare Umgebungen: 1TR

• Beschreibung: Wenn sip3 vorhanden ist und den Wert „True“ enthält, erzwingt iBoot nicht die Verwendung der eigenen integrierten Positivliste für die NVRAM-Variable boot-args, die ansonsten die Optionen filtern würde, die an den Kernel übergeben werden. Dieses Feld kann von einem Benutzer mit csrutil oder bputil aus 1TR geändert werden.

Zertifikate und Remote-Richtlinien (RemotePolicy)

Wie unter Erstellung und Verwaltung von Signaturschlüsseln für die lokale Richtlinie (LocalPolicy) beschrieben ist, enthält die Image4-Datei der lokalen Richtlinie auch das OIC (Owner Identity Certificate) und die eingebettete Remote-Richtlinie (RemotePolicy).