ADMIN

2023

02

2023-01-31T12:00:00

Endpoint Security

SCHWERPUNKT

080

Sicherheit

Apple

Lockdown Mode und Device Attestation bei Apple-Geräten

Gut geschützt

von Mark Zimmermann

Veröffentlicht in Ausgabe 02/2023 - SCHWERPUNKT

Smartphones sind ein beliebtes Ziel für Spionageangriffe jeder Art. Damit ist es kein Wunder, dass Apple mit seinen jährlichen Betriebssystemreleases auch interessantere Verbesserungen unter der Haube mitbringt. Diese spielen in Fragen der Informationssicherheit eine gewaltige Rolle. In diesem Beitrag betrachten wir die zwei wichtigsten Neuigkeiten im Bereich der IT-Sicherheit für Privatpersonen wie auch für Unternehmen.

Apple wirbt regelmäßig mit den Datenschutz- und Sicherheitsfunktionen, die in seiner Software und Hardware integriert sind. Die Betriebssysteme erhalten dabei jährlich neue Schutzmechanismen und Sicherheitsvorkehrungen. In diesem Artikel möchten wir uns mit zwei besonderen Aspekten auseinandersetzen: Zum einen bietet der neue Blockierungsmodus (Lockdown Mode) jedem gefährdeten Anwender die Möglichkeit, sich und sein Gerät vor gezielten Cyberangriffen zu schützen. Zum anderen gibt es die Device Attestation, die es Firmen ermöglicht, eine neue Vertrauensstufe zu einem mobilen Endgerät herzustellen.
Gegen Angriffe abschotten: Lockdown Mode
Smartphones sind beliebte Angriffsziele, insbesondere für Spionagezwecke. Eines der bekanntesten Beispiele der jüngsten Geschichte ist die Software "Pegasus", mit der Aktivisten, Menschenrechtler, Journalisten und Politiker durch fremde Mächte (meistens Staaten) ausspioniert wurden. Um Menschen aus dieser Gruppe eine Möglichkeit zum Selbstschutz anzubieten, hat Apple den Lockdown Mode eingeführt. Wie der Name vermuten lässt, gibt es Parallelen zum Corona-Lockdown. Es ist so, als würden Sie am iPhone die Rollläden schließen, die Türen doppelt verriegeln und alle Lichter im Haus ausschalten. Der Blockierungsmodus schützt Anwender, indem er auf den Geräten die zulässigen Aktionen und Aktivitäten stark einschränkt.
Standardmäßig ist der Blockierungsmodus abgeschaltet. Aktivieren lässt er sich auf einem Gerät mit iOS/iPadOS 16 oder macOS Ventura über "Einstellungen / Datenschutz & Sicherheit / Blockierungsmodus". Nach dem Einschalten des Modus ist ein Neustart des Endgeräts notwendig. Zum Deaktivieren ist zusätzlich die Eingabe der Geräte-PIN und ebenfalls ein Neustart erforderlich. Der Modus ist sehr mächtig und verhindert viele Angriffsvektoren, wie sie in der Vergangenheit für gezielte Cyberangriffe genutzt wurden. Die adressierte Zielgruppe besteht aus besonders gefährdeten Personengruppen. Es ist daher nicht zu empfehlen, den Modus ohne klaren Grund zu aktivieren, denn die Konsequenzen dieser Funktion sind mehr als deutlich.
Apple wirbt regelmäßig mit den Datenschutz- und Sicherheitsfunktionen, die in seiner Software und Hardware integriert sind. Die Betriebssysteme erhalten dabei jährlich neue Schutzmechanismen und Sicherheitsvorkehrungen. In diesem Artikel möchten wir uns mit zwei besonderen Aspekten auseinandersetzen: Zum einen bietet der neue Blockierungsmodus (Lockdown Mode) jedem gefährdeten Anwender die Möglichkeit, sich und sein Gerät vor gezielten Cyberangriffen zu schützen. Zum anderen gibt es die Device Attestation, die es Firmen ermöglicht, eine neue Vertrauensstufe zu einem mobilen Endgerät herzustellen.
Gegen Angriffe abschotten: Lockdown Mode
Smartphones sind beliebte Angriffsziele, insbesondere für Spionagezwecke. Eines der bekanntesten Beispiele der jüngsten Geschichte ist die Software "Pegasus", mit der Aktivisten, Menschenrechtler, Journalisten und Politiker durch fremde Mächte (meistens Staaten) ausspioniert wurden. Um Menschen aus dieser Gruppe eine Möglichkeit zum Selbstschutz anzubieten, hat Apple den Lockdown Mode eingeführt. Wie der Name vermuten lässt, gibt es Parallelen zum Corona-Lockdown. Es ist so, als würden Sie am iPhone die Rollläden schließen, die Türen doppelt verriegeln und alle Lichter im Haus ausschalten. Der Blockierungsmodus schützt Anwender, indem er auf den Geräten die zulässigen Aktionen und Aktivitäten stark einschränkt.
Standardmäßig ist der Blockierungsmodus abgeschaltet. Aktivieren lässt er sich auf einem Gerät mit iOS/iPadOS 16 oder macOS Ventura über "Einstellungen / Datenschutz & Sicherheit / Blockierungsmodus". Nach dem Einschalten des Modus ist ein Neustart des Endgeräts notwendig. Zum Deaktivieren ist zusätzlich die Eingabe der Geräte-PIN und ebenfalls ein Neustart erforderlich. Der Modus ist sehr mächtig und verhindert viele Angriffsvektoren, wie sie in der Vergangenheit für gezielte Cyberangriffe genutzt wurden. Die adressierte Zielgruppe besteht aus besonders gefährdeten Personengruppen. Es ist daher nicht zu empfehlen, den Modus ohne klaren Grund zu aktivieren, denn die Konsequenzen dieser Funktion sind mehr als deutlich.
Einige der vom System aktivierten Maßnahmen zielen darauf ab, die häufigsten zielgerichteten Remote-Angriffsvektoren für Apple-Geräte einzuschränken: infizierte iMessages, Links zu schädlichen Webseiten und eingehende Videoanrufe. So werden unter anderem Dateianhänge (außer einige Bilder-, Video- und Audiodateien) und die Linkvorschau von Internetadressen in der Nachrichten-App (iMessage) deaktiviert.
Aber auch die Apple-Dienste bleiben vom Blockierungsmodus nicht verschont. Eingehende Einladungen und Servicean­fragen, einschließlich FaceTime-Anrufe, werden unterbunden. Am Beispiel von FaceTime-Anrufen bedeutet dies, dass unbekannte Kontakte so lange außen vor sind, bis der Anwender mit dem jeweiligen Gerät einen Kontakt selbst anruft. Liegt die letzte Kommunikation mehr als 30 Tage zurück, wird der Kontakt wieder blockiert. Auch im Umgang mit Bildern und beim Surfen im Internet greift der Blockierungsmodus. Er entfernt freigegebene Alben aus der Fotos-App und verhindert Einladungen zu fremden freigegebenen Alben. Auch andere Apple-Dienste wie das Verwalten eines Smart-Homes sind eingeschränkt.
Bild 1: Der Blockierungsmodus lässt sich von jedem Anwender aktivieren.
Auf technischer Ebene werden eine Reihe von Webtechnologien deaktiviert, darunter die Just-in-Time-JavaScript-Kompilierung, die Code gleichzeitig kompiliert und ausführt. Ebenso stehen in Safari Funktionen wie WebAssembly , MathML, Web Audio API, WebGL oder SVG-Schriften nicht mehr zur Verfügung. Diese Beschränkungen verdeutlichen, warum Sie den Blockierungsmodus nicht ohne Grund aktivieren sollten. Zum einen geht er mit Einschränkungen der Benutzerfreundlichkeit einher, so ist etwa die Darstellung von PDF-Dateien in der Vorschau nicht mehr möglich. Auf der anderen Seite sind Maßnahmen zur Abschaltung von Funktionen wie JIT mit erheblichen Performanceeinbußen verbunden.
Es sei jedoch erwähnt, dass Anwender eigenständig individuelle Webseiten aus dem Sperrmodus herausnehmen können. Diese Seiten arbeiten in Safari danach wieder mit voller Performance, allerdings auch ohne die sicherheitsrelevanten Schutzfunktionen. Auch Apps mit eigenen Webviews sind vom Lockdown Modus betroffen, diese lassen sich in den Systemeinstellungen unter "Blockierungsmodus / Surfen konfigurieren" jedoch ebenfalls ausnehmen.
Datenschutz steht hinten an
Der Lockdown-Modus schirmt das Gerät und damit den Anwender vor Cyberangriffen ab. Dieser Schutz betrifft jedoch die Informationssicherheit, während der Datenschutz eine gewisse Einschränkung erfährt. Die Nutzung des Blockierungsmodus ist nämlich für eine Webseite nachvollziehbar [1]. Zudem speichern Webserver üblicherweise die IP-Adressen und weitere Informationen. Sie kann der Betreiber des Webservers erkennen, dass der Benutzer mit dieser IP-Adresse den Sperrmodus verwendet und der Zugewinn an Sicherheit geht anhand dieses Beispiels mit einer Reduzierung der Anonymität einher [2].
Weiterhin soll verhindert werden, dass unbeaufsichtigte Geräte an einem fremden Computer angeschlossen werden und wertvolle Informationen durch Schwachstellen im Kommunikationsprotokoll abfließen. Angesichts dessen sind kabelgebundene Verbindungen mit unbekanntem Hardwarezubehör bei einem gesperrten Endgerät ebenfalls nicht mehr möglich.
Ein Gerät, das vor Aktivieren des Blockierungsmodus bereits bei einem MDM-System registriert wurde, lässt sich weiterhin von diesem verwalten und konfigurieren. Normalerweise verwenden Unternehmen ein solches MDM häufig aus Support- und Sicherheitsgründen, zum Beispiel zum Löschen von Informationen auf einem verlorenen Gerät. Auch wenn ein MDM-System häufig sehr tiefgreifende Konfigurationen durchführen kann (Supervised), gehört der Blockierungsmodus nicht dazu. Er lässt sich durch ein MDM nicht ein- oder ausschalten. [3]
Sollten Sie selbst Apps entwicklen, können Sie in diesen übrigens prüfen, ob der Lockdown-Modus vom Anwender gewünscht wird oder nicht. Über eine Abfrage wie: bool isLockDownModeEnabled NSUserDefaults.StandardUserDefaults. ObjectIsForced("LDMGlobalEnabled"); kann jede App den Zustand des Modus prüfen und bei Bedarf eigene Schutzfunktionen vorsehen. Die Telefoniefunktion bleibt derweil vom Sperrmodus unbeeindruckt. Anrufe sind weiterhin möglich, auch der Notruf ist nicht eingeschränkt.
Apple plant, den Lockdown-Modus im Lauf der Zeit mit zusätzlichen Funktionen auszubauen. Hier dürfen wir gespannt sein, welche noch folgen. All diese Maßnahmen helfen dabei, es Spyware so schwer wie möglich zu machen, in das System einzudringen. Wurde ein Gerät bereits kompromittiert, begrenzt der Modus zumindest die Auswirkungen von bösartigem Code. Daher kann es angebracht sein, den Modus auch dann zu aktivieren, wenn das Endgerät verdächtige Aktivitäten zeigt.
Bild 2: Webseiten können vom Blockierungsmodus ausgenommen werden.
Auf Vertrauensbasis: Device Attestation
In einem modernen Zero-Trust-Sicherheitsmodell vertraut die Infrastruktur eines Unternehmens nicht mehr ausschließlich auf VPN und Firewall zur Gewährleistung der Informationssicherheit. Stattdessen findet für jede genutzte Ressource eine eigene Vertrauensprüfung statt. Damit liegt es an der Organisation, selbst zu entscheiden, welche Details für eine derartige Vertrauensprüfung wichtig sind und welche nicht.
Neben den betroffenen IT-Ressourcen ist die Identität des Nutzers ein wichtiger Aspekt bei einer solchen Vertrauensprüfung. Die SSO-Extensions unterstützen gängige Authentifizierungsverfahren seit Längerem auf iPhones, iPads und Apple TV. Der Microsoft Authenticator stellt beispielsweise unter anderem eine SSO-Extension zur Verfügung, die sich in das Betriebssystem integriert und alle Authentifizierungsanfragen gegenüber Azure-Clouddiensten sicherstellt.
Mit der "Managed Device Attestation"-Funktionalität ermöglicht Apple einer MDM-Geräteverwaltung die Abfrage verlässlicher Informationen über die wahre Geräteidentität. Durch eine Device-Information-Abfrage konnten MDM-Systeme früher lediglich unüberprüfbare Informationen wie die UDID des Geräts oder die Seriennummer erhalten. Es ist bei dieser Abfrage aber immer unklar gewesen, ob es sich tatsächlich um das Device handelt, für das es sich ausgibt. Jailbreaks oder Exploits konnten hier in der Vergangenheit schadhafte Geräte als vertrauenswürdig erscheinen lassen.
Damit Anwender auf Unternehmensressourcen wie Intranetseiten, Anwendungsserver und Datenbanken zugreifen können, benötigen sie ein Endgerät, das die Zugänge und den Vertrauensstatus, zum Beispiel durch Clientzertifikate, besitzt. Ein MDM-System spielt diese Zertifikate, die die Identität des Gerätes für Unternehmensressourcen sicherstellen, auf die Devices auf. Aber genau an dieser Stelle muss das MDM-System (oder andere beteiligte Systeme) sicherstellen, dass das Gerät sich die Zugänge nicht erschlichen hat.
Es besteht also der Bedarf nach einer Möglichkeit, das Vertrauen zum Endgerät und dessen Eigenschaften zu erzeugen, bevor unternehmenskritische Zugänge oder Daten auf diesem Gerät zum Einsatz kommen. In Software wird Vertrauen durch ein signiertes X.509-Zertifikat sichergestellt. Dies nutzt auch die Managed Device Attestation. Wie beim Zugriff per TLS auf Webseiten muss hier dem Root-Unterzeichner vertraut werden. Bei der Managed Device Attestation garantiert Apple als Unterzeichner die Richtigkeit der attestierten Gerätedaten.
Ziel in unserem Kontext ist es, der Behauptung eines Geräts über seine Eigenschaften wirklich vertrauen zu können. Hierbei geht es darum, dass die folgenden Eigenschaften nachweisbar sind: Das Gerät ist eine echte Apple-Hardware, das Gerät ist ein bestimmtes Gerät, das Gerät hat bestimmte Eigenschaften und ein privater Schlüssel ist in der Hardware des Devices abgelegt, um den sicheren Datenaustausch zu gewährleisten [4].
Dieses Prozedere soll mit der "Managed Device Attestation" erreicht werden und benötigt im Hintergrund die folgenden Komponenten:
- Apples Secure Enclave auf dem Gerät
- Apples Attestation-Server im Internet
- Herstellungsunterlagen zu dem Gerät (bei Apple vorhanden)
- OS-Kataloginformationen zu dem eingesetzten Betriebssystem (ebenfalls bei Apple vorhanden).
Validierte Geräteinformationen
Unterstützen MDM-Systeme die Managed Device Attestation, erhalten diese im Fall von iOS, iPadOS oder tvOS 16 eine signierte Geräteinformation. Hierzu beantwortet das iOS-Gerät die Anfrage des MDM-Systems nicht selbst, vielmehr fordert es eine Bescheinigung von einem Apple-Server ein und sendet dessen Bescheinigung an den MDM-Server zurück. Um sicherzustellen, dass die Bescheinigung tatsächlich von Apple ausgestellt wurde, kann der MDM-Server sein Kommando zur Abfrage um den Schlüssel "DeviceAttestationNonce (32 Byte)" erweitern. Dieser wird in der Antwort von Apple (und damit des Gerätes) mit verarbeitet. Damit kann das MDM-System die Aktualität der Antwort prüfen. Wird keine Nonce mitgegeben, bedeutet dies, dass die Aktualität der Datenabfrage keine Rolle spielt und das iOS-Gerät die letzte Bescheinigung ohne erneute Rückfrage bei Apple verwenden kann.
Die Antwort, die das Gerät dann an das MDM-System zurückgibt, erscheint als Datenarray ("DevicePropertiesAttestation") und beinhaltet Geräteeigenschaften, die in benutzerdefinierten OIDs (Object Identifier) repräsentiert werden. Die ersten beiden OIDs stellen zwei geräteidentifizierende Attribute dar. Hierzu gehören die Seriennummer und der UDID (Unique Device Identifier). Der Vollständigkeit halber sei erwähnt, dass bei BYOD-Geräten (User Enrollment) die Seriennummer und die UDID weggelassen werden. Die verbleibenden OIDs sind anonym und beinhalten die Betriebssystemversion der Secure Enclave (sepOS) und ein Wert für die zuvor erwähnte DeviceAttesta­tionNonce. Diese Antwort prüft der MDM-Server jetzt auf Herz und Nieren. Zuerst muss sichergestellt sein, inwiefern die Zertifikatskette mit der Apple-Zertifizierungsstelle in Verbindung steht. Ferner findet ein Abgleich der Nonce mit der Abfrage über die Device-Information statt. Erst danach folgt die Analyse der übrigen OIDs.
Das Erstellen neuer Bescheinigungen verbraucht erhebliche Ressourcen auf dem Gerät und den Apple-Servern. Daher gibt es ein Begrenzung diesbezüglich, wie oft sich neue Bescheinigungen anfordern lassen. Folglich können MDM-Systeme derzeit nur alle sieben Tage eine solche Anforderung erhalten. Es ist jedoch auch darauf hinzuweisen, dass eine Einforderung alle sieben Tage ebenfalls unnötig ist. Das MDM-System sollte die Bescheinigung nur neu einfordern, wenn sich etwas Wichtiges bezüglich des Geräts ändert – zum Beispiel, wenn das Betriebssystem aktualisiert wird oder kritische Konfigurationen oder Zertifikate aufzuspielen sind.
Eine signierte Bescheinigung kann übrigens auch fehlerhaft sein. Der Grund muss nicht unbedingt gravierend sein. Je mehr Systeme zu einer Kommunikationsverbindung zusammenkommen, desto größer ist die Wahrscheinlichkeit, dass ein Fehler auftritt. Trotzdem antwortet das Gerät, aber es werden die geforderten Informationen nur unvollständig bis gar nicht übergeben. Für dieses Verhalten kann es verschiedene Gründe geben: Es ist unter anderem denkbar, dass das Gerät selbst beim Erreichen der Apple-Bescheinigungsserver ein Netzwerkproblem hat. Kein Server ist mit einer Verfügbarkeit von 100 Prozent erreichbar. Aber auch die Hardwarekomponenten können defekt oder die installierte Software durch einen Angriff auf das Gerät kompromittiert sein. Im schlimmsten Fall stellt sich das Device selbst als ein Fremdgerät heraus, das nicht von Apple stammt. In diesen genannten Szenarien verweigern die Apple-Server die Ausstellung von Bescheinigungen. Die verschiedenen Ursachen für eine fehlgeschlagene Bescheinigung können also von einer harmlosen Netzwerkstörung bis zu einem aktiven Angriff reichen.
Bild 3: Wenn eine Webseite im Blockierungsmodus aufgerufen wird, ist dies für den Anwender oberhalb der Adressleiste sichtbar.
Bedauerlicherweise gibt es für den MDM-Server keine zuverlässige Quelle, die über die exakte Ursache Aufschluss gibt. Lediglich das (kompromittierte) Gerät könnte hierzu Auskunft geben. Im Fall einer Kompromittierung würde dieses Gerät jedoch die Unwahrheit vermitteln. Nicht jeder Ausfall einer Bescheinigung ist aber gleich ein Angriff. In einer zertifizierten Zero-Trust-Umgebung sind oftmals weitere Parameter relevant. So hängt der Vertrauenswert einer bestimmten Ressource von verschiedenen Parametern ab. Eine ausgefallene Bescheinigung hat lediglich diesen Vertrauenswert in diesem Fall reduziert. Folglich würde ein niedrigerer Vertrauenswert verschiedene Maßnahmen veranlassen, wie die Verweigerung des Zugangs zu Diensten, die Kennzeichnung des Geräts für eine manuelle Untersuchung oder die Beseitigung des Problems durch Löschen des Geräts und Widerruf der darauf installierten Zertifikate. Dies sind nur einige Beispiele für angemessene Reaktionen auf ein fehlerhaftes Beschleunigungsverfahren.
Was sich bis hierher noch recht einfach anhört, hat tatsächlich eine größere Komplexität, als es scheint. Der Grund liegt in der ausgelieferten Bescheinigung. Diese identifiziert lediglich ein Device, aber nicht, ob das gerade in der Kommunikation angesprochene Gerät mit diesem identisch ist. Damit sich dies gegenüber dem MDM-System und anderen Systemen in der Organisations-IT verifiziert sicherstellen lässt, kommt nun zusätzlich die ACME-Nutzdatenbescheinigung ins Spiel.
ACME-Nutzdatenbescheinigung
Wer ACME hört und schon ein paar Jahre auf dieser Welt ist, denkt bestimmt an den Kojoten bei Road Runner. Dieses ACME hingegen stellt jedoch etwas anderes dar, nämlich das ACME-Protokoll (Automatic Certificate Management Environment), das ursprünglich die Internet-Security Research Group (ISRG) für ihren Zertifikatsdienst zum Ausstellen von Webserver-Zertifikaten entwickelt hat. Das ACME-Protokoll ist inzwischen eine moderne Alternative von SCEP.
Der Validierungstyp, den wir für diesen Artikel benötigen, wurde in einem IETF-Entwurf der Öffentlichkeit zugänglich gemacht, in dem die Erweiterung des ACME-Protokolls zum Empfang von Bescheinigungen und zur Ausstellung von Zertifikaten von Clients beschrieben ist. Lassen Sie uns die Implementierung der Geräteprüfung gemäß des ACME-RFC 8555 [5] betrachten. Damit diese Prüfung für ein MDM-System zur Verfügung steht, muss zusätzlich ein ACME-Server in der IT-Organisation bereitstehen [6], der Clientzertifikate einer Zertifizierungsstelle für die Organisation ausstellen kann.
Bild 4: In den Einstellungen sehen Anwender, welche Webseiten und Apps vom Blockierungsmodus ausgenommen sind.
Zuerst muss der MDM-Server für die authentische Kommunikation mit dem Gerät ein Konfigurationsprofil installieren, das die ACME-Konfiguration initiiert. Dieses Profil gibt die Eigenschaften des Zertifikates ("ACMECertificate") an, das das iOS-Gerät generieren soll, um mit dem ACME-Server zusammenzuarbeiten, sowie die Kommunikationsparameter ("DirectoryURL") des ACME-Servers selbst. Das Gerät legt dieses Zertifikat in seiner Secure Enclave an. Nach Erstellen des Zertifikats kontaktiert das Device den ACME-Server und es wird ein Gerätekonto auf dem ACME-Server angelegt.
Der Prozess zur Bestätigung der Echtheit eines Endgeräts läuft nun folgendermaßen ab: Der ACME-Server fordert das Endgerät auf, ein Zertifikat bei Apple einzuholen. Zu diesem Zweck wird das Gerät mit einer vom ACME-Server generierten Nonce versorgt. Mit der Antwort des Geräts muss der ACME-Server jedoch sorgfältig umgehen und verschiedene Prüfschritte durchlaufen. So muss dieser verifzieren, dass die eindeutige Zeichenfolge, die das Gerät identifiziert, ("ClientIdentifier") gültig ist. Zusätzlich prüft er das Bescheinigungszertifikat des Devices und ob dieses mit der richtigen Apple-CA verbunden ist. Die Nonce muss mit dem SHA-256-Hash der Nonce übereinstimmen, die der ACME-Server (nicht das MDM-System) zuvor an das Gerät gesendet hat. Wenn auch diese Prüfung passt, kann der ACME-Server die weiteren OIDs auswerten. Am Ende des Prozesses stellt der ACME-Server ein Clientzertifikat von der CA des Unternehmens aus und liefert es an das Gerät zurück [7].
Das vom ACME-Server ausgelieferte Clientzertifikat kann für das MDM-System wie auch die übrige IT-Infrastruktur als Vertrauensbasis dienen. Hierzu können auch andere Konfigurationsprofile auf die ACME-Payload verweisen, um das Zertifikat einzubinden. So profitieren nicht nur MDM-Systeme, sondern auch WLAN, VPN oder Kerberos-Systeme von dieser Bescheinigung. Auf einem Gerät lassen sich damit eigene ACME-Payloads in bis zu zehn Konfigurationsprofile einbinden.
Die Zuordnung zum Gerät erfolgt auf Basis des Kommunikationsverbunds in Verbindung mit dem privaten Schlüssel, den das Gerät in verschiedenen Arten nutzt:
- wenn es eine Bescheinigung von Apple erhält,
- wenn es ein Clientzertifikat vom ACME-Server erhält und
- wenn es TLS zur Kommunikation mit anderen Servern nutzt.
Da der Schlüssel hardwaregebunden ist, wissen alle beteiligten Systeme, dass all diese Aktionen von ein und demselben Gerät durchgeführt werden.
Fazit
Die Sicherheitsverbesserungen, die 2022 auf der WWDC eingeführt wurden, sind beeindruckend. Managed Device Attestation hilft dabei, gleich mehrere Klassen von Gefährdungen zu beseitigen. Mit der "DeviceInformation"-Attestierung erreichen Organisationen eine höhere Vertrauensüberprüfung für ihre im Einsatz befindlichen Endgeräte.
Die zugehörige ACME-Bescheinigung weist die Identität eines Geräts kryptografisch nach, wenn es auf Unternehmensressourcen zugreift. Dass es sich hierbei um ein zukunftsträchtiges Verfahren handelt, zeigt sich dadurch, dass die ACME-Gerätebescheinigung auch in Android und ChromeOS einfließen sollen. Der Lockdown Mode auf der anderen Seite hilft den Anwendern, sich vor gezielten Angriffen zu schützen, schränkt aber die Benutzerfreundlichkeit spürbar ein.
(dr)
Link-Codes
[1] Test zur Weberkennung des Lockdown-Modus: https://crypt.ee/ios-lockdown-mode-test
[3] Lockdown-Modus und MDM: https://support.apple.com/de-de/HT212650
[6] YouTube-Video zur Installation eines ACME-Servers: https://www.youtube.com/watch?v=yNwU-1_o0Hw&feature=emb_imp_woyt