iPhone-Sicherheit - ein Haus aus Stein oder Stroh? Ist GrapheneOS besser?

Der Artikel rekapituliert, wie sich das iPhone in Bezug auf Sicherheit gegenüber Angriffen mit Malware in den letzten ungefähr 10 Jahren geschlagen hat und vergleicht danach offengelegte Schwächen des iPhone Betriebssystems iOS mit entsprechenden Merkmalen von GrapheneOS, einer gegenüber Malwareangriffen besonders gehärteten Androidvariante.

Das iPhone hat den Ruf, ein sicheres und vergleichsweise datenschutzfreundliches Smartphone zu sein, wenn nicht die sicherste Lösung auf dem Markt. Aus diesem Grund entscheiden sich die meisten Unternehmen und Organisationen für das iPhone als dienstliche Smartphone-Anwendung für ihre Mitarbeiter und Nutzer. Auch im gehobenen Marktsegment hat das iPhone nicht zuletzt aus diesem Grund quasi ein Monopol.

Was den Datenschutz betrifft, so wurde die behauptete Überlegenheit des iPhone gegenüber anderen Plattformen wie Android in mehreren Analysen als Marketing-Mythos von Apple entlarvt, z.B. von Kollnig et al (1). Auch was die Sicherheit des iPhones angeht, gab es in den letzten Jahren immer wieder beunruhigende Meldungen über erfolgreiche Angriffe, die das Abhören der angegriffenen Nutzer im weitesten Sinn ermöglichten. Hier sollen die Analysen von einigen bekannteren Angriffen rekapituliert und kurz zusammengefasst werden, um zu sehen, ob sich daraus allgemeine Schlussfolgerungen zur Sicherheit der Plattform ableiten lassen. Am Ende erfolgt eine Gegenüberstellung der offengelegten Schwächen von iOS zu vergleichbaren Merkmalen von GrapheneOS, um abzuschätzen, ob sich GrapheneOS in den dargestellten Angriffsszenarien besser geschlagen hätte. Einschränkend ist hier anzumerken, dass dieser Artikel keinen Versuch darstellt, eine tiefgehende oder sogar vollumfängliche Analyse der Sicherheitsarchitektur von iOS und GrapheneOS vorzunehmen und die beiden in dieser Hinsicht zu vergleichen und zu bewerten. GrapheneOS ist eine Abspaltung des Android Open Source Projekts (AOSP), ein sogenanntes Custom-ROM, das eine zusätzliche Härtung der Sicherheit in Bezug auf das Ausspähen von persönlichen Daten durch Internetkonzerne und gegenüber Angriffen mit Malware erhalten hat. Hier auf gnulinux.ch wurde es bereits mehrfach besprochen. Es lässt sich ausschließlich auf Smartphones der Google Pixelserie nachträglich installieren (2), auf dem Markt werden aber auch Pixel angeboten, auf denen die Installation bereits von Dritten durchgeführt wurde (3). Nun zu den erfolgreichen Angriffen auf iOS und das iPhone.

1. Massenhack des iPhone über gehackte Webseiten:

Dieser Angriff wurde um 2019 bekannt, als sich die Nachricht verbreitete (4), dass ein einfaches Laden bestimmter gehackter Webseiten Malware auf das iPhone brachte, die das iOS ohne weitere Benutzerinteraktion vollständig als Administrator übernehmen konnte, d. h. die vollständige Kontrolle über das System, installierte Apps, Verschlüsselung, damit private Nutzerdaten, wie SMS-, Messengernachrichten, Emails, Adressdaten, persönliche Dateien ermöglichte ohne dass der Nutzer etwas davon bemerkte. Eine Einschränkung dieses Angriffs war, dass er nicht von Dauer war. Ein Neustart entfernte die Malware. Es wurde vermutet, dass Hacker oder Regierungsorganisationen aus China hinter den Angriffen steckten, da insbesondere Uiguren davon betroffen waren. Der Angriff wurde von dem Google Project Zero registriert und analysiert (5). Er betraf iOS10 bis iOS12.

Bei Smartphone-Betriebssystemen sind nutzerinstallierte Apps und Systemapps, wie der Browser in einer Sandbox "eingesperrt", d.h. sie können außerhalb der Sandbox nur auf die Daten zugreifen, die ihnen vom Nutzer oder dem Betriebssystem mit Berechtigungen freigegeben werden. Ein Beispiel sind GPS-Standortdaten, die der Benutzer per App freischalten oder blockieren kann. Das Einfallstor für Malware sind Apps, die auf das Internet zugreifen können, also Browser, Messenger- oder Email-Apps. Bevor Malware ein System komplett übernehmen kann, muss sie also aus der Sandbox der App ausbrechen, über die sie via Internet auf das System gekommen ist.

Dies gelang der Malware der genannten Webseiten über Schwachstellen im Safari-Browser, Web-Kit und deren Sandbox. Danach nutzte sie Schwachstellen im Betriebssystem-Kernel um das System komplett zu übernehmen. Ein Teil der verwendeten Schwachstellen waren "0-Day", d.h. bis dato unbekannt. Apple spielte das Problem damals herunter, da nur wenige Nutzer betroffen seien, davon keine in westlichen Ländern. Daher wurde Apple kritisiert, nicht offen mit dem Problem umzugehen, sondern stattdessen den Umfang und die Tiefe der Sicherheitslücken zu verharmlosen (6).

2. Pegasus Spyware

Dieser Hack wurde 2021 bekannt und betraf Versionen bis iOS14 und schaffte es diesmal auch in die Schlagzeilen, da viele Personen des öffentlichen Lebens zu den Opfern gehörten, darunter der französische Staatspräsident. Daher gibt es zahlreiche Veröffentlichungen zu diesem Angriff (7, 8). Dahinter steckte Spyware der israelischen Firma NSA Group, die ihre Hackerdienste kommerziell anbot. Hier ist interessanter, wie der Angriff erfolgte, als wer darin involviert war. Dies wurde erst später bekannt, nachdem Sicherheitsexperten infizierte iPhones analysiert hatten (9, 10). Die wichtigsten Merkmale der Malware und ausgenützte Sicherheitslücken waren:

- Der Schadcode wurde über eine iMessage auf das Gerät gesendet. In einer ersten Version offen, mit einem Anhang, den der Nutzer anklicken musste (1-Klick), später als stille, für den Nutzer nicht sichtbare iMessage, deren Anhang von selbst startete (0-Klick).

- Der eigentliche Angriff wurde mit einer manipulierten Bilddatei durchgeführt. Die Datei gab sich als GIF-Format aus, war tatsächlich aber in dem urtümlichen Format JBIG2 programmiert.

- Apple hatte versäumt, den JBIG2 Codec aus den 90er Jahren an aktuelle Sicherheitsstandards anzupassen (Stichwort Memory Overflow). Da der Codec logische Operationen, wie NAND und NOR erlaubte, ließ sich in die Bilddatei bösartiger Programmcode schreiben, mit der Sandboxausbruch und das Erlangen von Adminrechten gelang. Die angehängte Bilddatei war also tatsächlich ein mächtiges Programmpaket.

Von Pegasus wurde auch eine Androidvariante bekannt, mit dem Namen Chrysaor (11). Interessanterweise konnte die Androidvariante nicht aus eigener Kraft das System übernehmen wie bei iOS. Hier war die "Mitarbeit" der Nutzer nötig, indem diese dazu gebracht wurden, die App mit der Spyware aufzuspielen oder ihr erweiterte Berechtigungen zu erteilen. Dieser Angriffsweg ist offensichtlicher. Aufmerksame Nutzer lassen sich nicht derart übertölpeln. In diesem Beispiel hatte das iPhone also keine Sicherheitsvorteile gegenüber der Android-Plattform.

3. Operation Triangulation

Anfang 2024 wurde ein weiterer erfolgreich durchgeführter Angriff auf das iPhone mit einer möglicherweise noch größeren Raffinesse als Pegasus mit der Bezeichnung Operation Triangulation von Kaspersky veröffentlicht (12, 13). Der Ursprung ist unbekannt, liegt aber aufgrund der Komplexität und der Tatsache, dass hauptsächlich Russen abgehört wurden, möglicherweise bei westlichen Geheimdiensten oder ähnlichen staatlichen Akteuren. Auch hier wird eine vollständige administrative Kontrolle über das Gerät erlangt. Die Angreifer gaben sich große Mühe, den Angriff zu verbergen, indem sie ihren Code nach dem Eindringen in ein Gerät wieder löschten. Der Angriff hielt also nur bis zum nächsten Neustart, konnte danach aber wiederholt werden. Es gibt sowohl Ähnlichkeiten als auch Unterschiede zu Pegasus:

- Der Angriff wurde wieder mit dem Anhang einer stillen iMessage gestartet. Erneut auf Grund veralteter Codecs aus den 90er Jahren im Font-Rendering konnte der Messageanhang genutzt werden, um Programmcode auszuführen, ähnlich wie dies mit der JBIG2-Bilddatei bei Pegasus geschah.

- Nach mehreren Stufen der Umgehung verschiedener Sicherheitsmechanismen wie Sandboxen nutzte der Angriff in seiner letzten Stufe erneut Schwachstellen im Apple-eigenen Safari Web-Kit, um die volle Kontrolle über das Gerät zu übernehmen.

- Das neue und raffinierteste Merkmal dieses Angriffs war die Umgehung der hardwarebasierten Beschränkungen für das Schreiben in den Kernelspeicher (Page Protection Layer - PPL). Die Firmware des Prozessors weist dabei Prozessen eigene Speicherbereiche zu, außerhalb derer sie keine Daten lesen oder speichern können. Die Umgehung dieser Funktion erforderte intime Kenntnisse über normalerweise nicht genutzte und undokumentierte Designmerkmale von 5 (!) Generationen von Apple Prozessoren (SoCs) und deren Firmware, um die Malware wahrscheinlich ab iOS8 (ca. 2015) bis iOS16 (2023) lauffähig zu halten. Dies hat manche, aber nicht alle Sicherheitsforscher zu der Schlussfolgerung veranlasst, dass die Angreifer dieses Wissen nicht ohne passive oder aktive Zuarbeit aus dem Hause Apple erlangt haben können.

Die Methode zur Umgehung der hardwarebasierten Sicherheitsfunktionen könnte als Blaupause für zukünftige Angriffe dienen, da Apple als Fix nur den im Angriff verwendeten Adressbereich gesperrt hat, aber scheinbar nicht die Methode an sich.

4. Analyse des „Find my“-Ortungsnetzes

Das "Find-my" Netz von Apple zur Ortung von Bluetoothgeräten wurde bereits kritisiert, da es offensichtlich Stalking ermöglicht, indem einem Opfer ein AirTag untergeschoben wird. Unabhängige Analysen zu dessen Funktion legten zwar keine weiteren erfolgreichen Attacken zur kompletten Übernahme von iOS offen, dafür aber Angriffspfade auf die Privatsphäre von Nutzern und Schwachstellen in der Sicherheit des Dienstes und iOS, sowie weitere schlampige Programmierpraktiken. In der Zeitschrift c't 25/2023 wurde gezeigt, dass das "Find-my" Netz zur Übertragung kleiner Datenmengen, z.B. eines Keyloggers an jeden Ort der Welt verwendet werden kann, ohne dass dieser Datenverkehr mittels Firewalls oder der Analyse des Netzwerkverkehrs beobachtet und gestoppt werden kann, da die Daten huckepack und incognito in der großen Datenmenge transportiert werden, die iPhones ständig an Appleserver senden (14). Dieses Experiment der c't basiert auf einer Analyse aus dem Jahr 2021, in der IT-Forscher ein Reverse-Engineering des "Find-my" Dienstes durchgeführt hatten (15) und dabei Sicherheits- und Datenschutzmängel im Design dieses Netzwerks fanden:

- Die Forscher kritisieren Apple für die unzureichende Dokumentation und den Closed-Source-Charakter des „Find my“-Dienstes, was ihre Nachforschungen und die Aufdeckung von Sicherheitslücken unwahrscheinlicher, zeitaufwändig und ressourcenintensiv mache.

- Apple-Programmierer hatten die privaten Schlüssel der Nutzer des Dienstes in einem Nutzerverzeichnis zwischengespeichert. Stand der Technik wäre, private Schlüssel ausschließlich in einem hardwarebasierten Secure Element zu speichern, das bei Applegeräten vorhanden ist. Bei macOS führte dies tatsächlich dazu, dass installierte Apps Zugriff auf diese Schlüssel bekommen konnten. Bei iOS war die App-Sandbox eine letzte Verteidigungslinie, die dies verhinderte.

- Beim Hochladen der Standortberichte des „Find-my“ Dienstes auf Apple-Server fragt Apple die eindeutige Apple-ID der Gerätenutzer ab. Damit liegt die Information, welche Nutzer von Applegeräten einander in die Nähe kommen, d. h. sich treffen, für Apple einsehbar auf seinen Servern. Dies ist keine zwingende Funktion des Dienstes, sondern eine Designentscheidung von Apple.

- Nach der Enthüllung dieser Schwachstellen durch die Forscher hat Apple die unsichere Speicherung privater Schlüssel behoben, aber nicht auf die Möglichkeit der Identifizierung von Applekunden verzichtet, die einander treffen!

Eine weitere Machbarkeitsstudie zeigte nun erst kürzlich, dass das "Find-my" Netz missbraucht werden kann, um den Standort der meisten Bluetoothgeräte weltweit und damit ihrer Besitzer aus der Ferne zu tracken, selbst wenn Besitzer sie nicht im "Find-my" Netz registriert haben und das Bluetoothgerät nicht für die Registrierung im "Find-My" Netz zertifiziert oder vorgesehen ist (16).

Resumée zur Sicherheit von iOS

In Summe lassen sich aus dieser Serie von Hacks und Analysen einige allgemeine Schlussfolgerungen ziehen, über den Stand der Sicherheit von iPhones und die Bedeutung, die Apple der Sicherheit im Vergleich zu anderen Unternehmenszielen beimisst:

- Möglicherweise ab 2014 (iOS8), spätestens ab dem Massenhack 2016 (iOS10) bis zum Bekanntwerden der Operation Triangulation 2023 (bis iOS16) gab es zu jedem Zeitpunkt mindestens einen Hack, um iPhones aus der Ferne komplett zu übernehmen, ohne dass dies einem durchschnittlichen Nutzer aufgefallen wäre. iOS10 bis iOS12 waren rückblickend wahrscheinlich von allen genannten Hacks angreifbar. Die dafür erforderlichen Techniken waren so anspruchsvoll, dass sie nur von sehr spezialisierten Organisationen oder staatlichen Akteuren durchzuführen waren. Es wäre naiv und eine Verletzung des Gesetzes der Serie, aktuell keine solchen Exploits mehr zu erwarten. Sie dürften der breiten Allgemeinheit nur noch nicht bekannt sein.

- Hinreichend ausgefeilte, mit Spyware präparierte Webseiten oder iMessage-Anhänge reichten aus, um die volle Kontrolle über iPhones zu erlangen. Während stellenweise extrem komplexe Methoden eingesetzt wurden, die nur wenige, spezialisierte Cyberorganisationen beherrschen, um Kernel-, Hardware- und Sandbox-Sicherheitsfunktionen des iOS über mehrstufige Angriffswege zu umgehen, konnten sich Angreifer andererseits regelmäßig auf Sicherheitslücken in peripheren Apps und Diensten verlassen. So kann z.B. Malware seit Jahren als Anhang über stille iMessages zugestellt werden, ohne dass Apple diesen Angriffspfad schließt.

- Schlampige Programmierpraktiken von Apple wurden offengelegt: Private Schlüssel wurden in unsichere Speicher abgelegt. Veralteter, unsicherer, mehr als 20 Jahre alter Code war in Bild- und Schriftcodecs verbaut.

- Erleichtert wurden die Angriffe also durch die große Angriffsfläche, die iPhones bieten, dank der Menge an proprietären Apps und Diensten, die Apple seinen Nutzern aufzwingt, auch wenn sie diese nicht nutzen („Bloatware“). Für die genannten Sicherheitslücken waren insbesondere der Safari-Browser und das Web-Kit, iMessage, proprietäre Bild- und Schriftrendering-Software und der „Find my“-Geräteortungsdienst verantwortlich. Apple erlaubt es nicht, diese vollständig zu deinstallieren oder durch nicht-proprietäre Software zu ersetzen. Auch wenn es möglich ist, alternative Browser zu installieren, werden diese von Apple gezwungen, das proprietäre Safari Web-Kit zu verwenden, wodurch sie bisher nicht mehr als eine andere Nutzeroberfläche des proprietären Apple-Browsers bieten (17). Die EU zwingt Apple allerdings nun, alternative Web-Engines künftig zuzulassen. Im "Walled Garden" von Apple fehlt Nutzern also die für bessere Sicherheit nötige Möglichkeit, alle überflüssigen Anwendungen zu deinstallieren, sicherere, alternative Apps und Dienste generell zu installieren und damit Datenverkehr und Angriffsfläche zu reduzieren.

- Apple ist zwar bereit, gemeldete Sicherheitslücken schnell zu schließen, wenn diese Daten an Dritte weitergeben. Aber Apple ist nicht bereit, den eigenen Zugriff auf Nutzerdaten einzuschränken, wie das Beispiel des "Find my"-Dienstes zeigt. Ein weiteres Beispiel ist die Ende-zu-Ende Verschlüsselung der iCloud. Nach jahrelangen, vergeblichen Forderungen wurde diese erst mit iOS16 2022 als Option eingeführt, nur um im Vereinigten Königreich auf Druck der Regierung bereits wieder abgeschaltet zu werden (18).

- Die hier zitierten Forscher kritisieren, dass iOS auf Grund seines Closed Source Codes schwieriger zu analysieren ist, als z.B. Android, das auf Open Source basiert (1, 15). Eine Folge davon ist, dass es zu iOS weniger Veröffentlichungen zur Sicherheit des Systems gibt, als für Android. Wenn Forscher allerdings die Sicherheit von iOS in der Tiefe analysieren, wie in den hier zitierten Arbeiten, finden sie nicht selten Schwachstellen. Apple-Software folgt also zumindest zum Teil dem veralteten und gefährlichen Konzept von „Security by obscurity“, was auch zitierte Sicherheitsforscher kritisieren (12) anstatt dem überlegenen Konzept von Open Source und vollständiger Offenlegung.

- Zusammengefasst entsteht der Anschein, dass die Maximierung von Profiten aus dem Apple-Ökosystem und „Walled Garden“ für Apple höhere Priorität hat, als Nutzern die bestmögliche Sicherheit anzubieten.

Vergleich zu GrapheneOS

GrapheneOS wird von Sicherheitsexperten wie Edward Snowden und Mike Kuketz als das sicherste und datenschutzfreundlichste Android bewertet (19, 20). In Bezug auf die Analyse von Datenschutz und Sicherheit wollte ich daher hier an den Test von Mike Kuketz verweisen (19). Die zusätzliche Härtung von GrapheneOS ist ausführlich auf deren Webseite beschrieben (2). Ich will mich hier darauf beschränken, wie sich GrapheneOS im Vergleich zu den aufgedeckten Schwächen von iPhones, iOS darstellt.

- Die Angriffsfläche von GrapheneOS ist so gering wie bei keinem anderen gängigen Smartphone-Betriebssystem. Im Vergleich zu Google Stock Android sind die System-Apps von ca. 270 auf 166 reduziert (Android 14 - die Anzahl von iOS Systemapps ist mir als Vergleich nicht bekannt). Die Anzahl der über das System vorinstallierten Anwendungsapps ist minimal: Ein Telefon-Dialer, SMS/MMS, Kontaktverwaltung, gehärteter Vanadium-Browser, gehärteter PDF-Viewer, Datei-Manager, Kalender, Taschenrechner, Uhr, Bildergalerie, Kamera und ein App-Store für Systemapps. Davon sind nur Browser, SMS/MMS-App und App-Store in der Lage, sich mit dem Internet zu verbinden. Diese vorinstallierten Anwendungen können vom Nutzer deaktiviert werden und durch Alternativen ergänzt oder ersetzt werden, was allerdings nicht in jedem Fall ratsam ist. GrapheneOS ist also komplett frei von Bloatware.

- GrapheneOS kontaktiert nach der Installation weniger als 10 Internetadressen regelmäßig. Davon lassen sich Kontakte zu Zeit- und Standortdiensten, sowie Closed Portal Verbindungschecks in den Einstellungen abschalten, womit sich der Datenverkehr auf die GrapheneOS-Server für Systemupdates als Minimum beschränken lässt. iOS (1) und Android Stock-ROMs kontaktieren im Auslieferungszustand, je nach Einstellungen bereits einige Dutzend bis über 100 Domains, jeweils eine davon im Abstand weniger Minuten.

- Abgesehen vom Kontakt zum Updateserver benötigt GrapheneOS keine Clouddienste um zu funktionieren. Es werden keine proprietären Clouddienste ausgeliefert, wie iCloud, iMessage oder "Find My" unter iOS. Der Nutzer kann sich aber bei Bedarf die "Sandboxed Google Playdienste" ohne besondere Systemrechte aus dem Appstore nachinstallieren.

- GrapheneOS und die vorinstallierten Anwendungen sind zu 100% quelloffen (mit Ausnahme der Google Play Services, die optional sind), folgt also dem überlegenen Sicherheitskonzept der vollständigen Offenlegung, das eine unbeschränkte Kontrolle der Sicherheitsarchitektur durch die Öffentlichkeit und Experten ermöglicht.

- Da der Quellcode von GrapheneOS offen ist, können Anwender, die über die entsprechenden Fähigkeiten verfügen, ihre eigene, konfektionierte Version des Betriebssystems erstellen und z.B. eigene Systemapps integrieren. Die Sicherheitsfirma Nitrokey scheint bei ihren Cryptophones mit vorinstalliertem GrapheneOS davon Gebrauch zu machen.

- Die Entwicklung von GrapheneOS wird von einer Stiftung mit Sitz in Kanada getragen, die anders als Apple keine Profitinteressen verfolgt und Sicherheit als übergeordnetes Entwicklungsziel ohne Kompromisse verfolgen kann.

- GrapheneOS hat einige Funktionen für zusätzlichen Datenschutz und Sicherheit, die weder bei iOS noch Android Stock-ROMS zu finden sind:

i) Der Zugriff auf alle Sensoren lässt sich per App im Berechtigungsmanagement abschalten. iOS und Stock Android erlauben dagegen keine Kontrolle von Sensoren für Beschleunigung, Magnetometer, Kompass, Luftdruck, etc. Trackende Apps nutzen diese Sensoren regelmäßig um das Verhalten von Nutzern aufzuzeichnen (z.B. benutztes Verkehrsmittel). Malware könnte einen Beschleunigungssensor als Ersatzmikrofon missbrauchen. Nitrokey bietet für seine Pixel mit GrapheneOS daher an, diese Sensoren herauszulöten.

ii) Der Internetzugriff kann Apps generell entzogen werden. Unter iOS und Stock Android lässt sich der Internetzugriff nur für mobile Daten bzw. für Hintergrundverbindungen entziehen, nicht wenn eine App bei WiFi-Verbindung aktiv ist.

iii) Neben App-Sandboxen bietet GrapheneOS eine weitere Ebene an Sandboxen um bis zu 32 Nutzerprofile und ihre jeweiligen Nutzerdaten, wie z.B. Adressbücher hermetisch gegeneinander abzuschirmen.

Wie sind die Erfahrungen zur Sicherheit von GrapheneOS im Vergleich zu iOS nun in der realen Welt?

Ich konnte keine dokumentierten, erfolgreichen Angriffe aus der Ferne auf GrapheneOS finden, vergleichbar zu den hier dokumentierten auf iOS (Op. Triangulation, Pegasus, Massenhack). GrapheneOS ist allerdings auch sehr viel weniger verbreitet als iOS. Wenn keine Angriffe darauf bekannt sind, kann das daran liegen, dass sie nicht entdeckt wurden oder Angreifer sich nicht die Mühe machten, für die geringe Zahl der Nutzer dedizierte Angriffstools zu entwickeln.

Besser dokumentiert sind Angriffe, bei denen das gesperrte Smartphone in die Hände der Angreifer gelangt ist, in dem Fall Ermittlungsbehörden und Forensiker, ohne dass ihnen die PIN bekannt ist. Ihnen stehen Angriffswerkzeuge von Firmen wie Cellebrite, Graykey, MSAB zur Verfügung, um die Daten des Smartphones zu extrahieren. Zu unterscheiden sind sowohl für Android als auch iOS die Fälle BFU, AFU (before, after first unlock) und FFS (Full Filesystem Extraction) z.B. nach einer Brute-Force Attacke auf die PIN (22). BFU ist der Zustand vor dem ersten Entsperren nach einem Neustart. In diesem Zustand liegen die meisten Nutzerdaten noch sicher verschlüsselt im Speicher und sind auf modernen Smartphones mit Secure Element auch für die genannten Angriffswerkzeuge nicht zugänglich. Interessant für Angreifer ist daher vor allem die AFU- und FFS-Extraktion, die Zugriff auf die meisten oder alle Nutzerdaten gibt. 2024 war bei iOS für alle Versionen unter 17.4 AFU und FFS möglich, bei GrapheneOS für OS-Versionen mit Release vor 2023. Bei beiden Plattformen durfte zudem die Hardware und das Secure Element nicht zu alt sein, bei den Pixel nicht älter als das Pixel 6 (23). Beide Plattformen bieten also nur für neue Hardware und OS-Versionen vorübergehenden Schutz. GrapheneOS bietet als weiteren Schutz eine Auto-Reboot Funktion. Wenn aktiviert startet das Gerät von selbst neu und versetzt sich zurück in den sicheren BFU-Zustand. Der Timer dafür kann bei GrapheneOS bis auf 10min heruntergesetzt werden. Damit bleibt Forensikern nicht die Zeit, eine AFU- oder FFS-Extrakion vorzunehmen. Apple plant für das iPhone Auto-Reboot erst ab iOS18.1 für die der Timer fest auf 3 Tage eingestellt sein soll (24). Stock-Androids bieten gegen diese Attacken generell weniger Schutz als GrapheneOS und iOS. Das wurde kürzlich demonstrierenden, serbischen Studenten zum Verhängnis, deren Smartphones nach Ihrer Verhaftung ausgelesen werden konnten (25). Selbst ohne GrapheneOS hätten sie sich besser schützen können, wenn sie mit ausgeschalteten Smartphones auf die Demo gegangen wären, da die Polizei diese dann nur in den BFU Status hätte booten können.

Zusammengefasst entsteht der Eindruck, dass GrapheneOS nicht nur gegenüber Stock-Androids ein überlegenes Sicherheitskonzept bietet, sondern auch gegenüber iOS und dem iPhone. Vor Angriffen durch Forensiker, die Geräte in die Hand bekommen, sind beide Systeme nicht sicher. GrapheneOS bietet hier einen besseren indirekten Schutz durch den einstellbaren Auto-Reboot, den Apple erst implementieren will. Gegenüber Angriffen aus der Ferne, über das Internet schützt GrapheneOS ein konsequent auf Sicherheit ausgelegtes Konzept, das es in dieser Form bei iOS nicht gibt. Möglicherweise fliegt GrapheneOS wegen seiner geringeren Verbreitung in diesem Fall zusätzlich unter dem Radar, da es sich für Angreifer nicht lohnen könnte, für die wenigen Nutzer aufwendige Angriffswerkzeuge zu entwickeln. Der iPhone Marktanteil liegt global bei knapp über 20%, zu Custom ROM Marktanteilen konnte ich keine Daten finden. Die Größenordnung dürfte nicht höher als 0,1% sein, vergleichbar zu anderen "exotischen" Betriebssystemen wie Tizen oder KaiOS (26). Die notwendigen, aufwendigen Angriffswerkzeuge existierten in der Vergangenheit aber mehrfach für iOS, das daher als kompromittiert gelten muss. Grob geschätzt dürften einige 10.000 bis 100.000 Nutzer über die genannten Angriffe ausgespäht worden sein (Massenhack, Pegasus; 6, 7). Für Nutzer, die nur zufällige Angriffe durch Ransomware, Cryptominer und ähnliche Malware befürchten müssen, mag die iOS-Sicherheit hinreichend sein. Auch große Organisationen können mit Sicherheitslücken im Endgerät zurecht kommen, wenn sie über weitere Verteidigungslinien verfügen, wie die Überwachung des Netzverkehrs. Für Einzelkämpfer in puncto Sicherheit, die zudem einem hohen Verfolgungsdruck durch staatliche oder mächtige Organisationen ausgesetzt sind, wie Investigativjournalisten, Rechtsanwälte, Whistle-Blower, Oppositionelle in repressiven Staaten kann die Nutzung eines iPhones jedoch verhängnisvolle Konsequenzen haben. Sie müssen damit rechnen dass ihre Verfolger Zugriff auf die Daten ihrer Telefone bekommen. Wenn das Sicherheitskonzept der drei Schweinchen gegen Angriffe des Wolfs, wie in er Überschrift als Maßstab herangezogen wird, ist die Sicherheit des iPhones zwar klar besser als eine Strohhütte aber angesichts von regelmäßig erfolgreichen Angriffen nicht unbedingt eine Hütte aus Stein. Die Sicherheit von GrapheneOS könnte eine Hütte aus Stein sein. Sicher beurteilen ließe sich das erst, wenn GrapheneOS größere Verbreitung fände und damit für die Wölfe eine lohnende Beute würde. Bis dahin profitieren Nutzer von GrapheneOS von dessen besonderem Sicherheitskonzept und möglicherweise davon, dass dies ein zu seltenes Wild ist, um Wölfe regelmäßig satt zu machen.

Quellen

(1) https://arxiv.org/abs/2109.13722
(2) https://grapheneos.org/
(3) https://gnulinux.ch/das-nitrophone
(4) https://www.heise.de/meinung/Analyse-Was-bedeutet-der-iPhone-Massen-Hack-4511921.html
(5) https://googleprojectzero.blogspot.com/2019/08/a-very-deep-dive-into-ios-exploit.html
(6) https://arstechnica.com/information-technology/2019/09/apple-takes-flak-for-disputing-ios-security-bombshell-dropped-by-google/?comments=1
(7) https://en.wikipedia.org/wiki/Pegasus_(spyware)#cite_note-KasperskyOnPagasusOnAndroid-35
(8) https://en.wikipedia.org/wiki/FORCEDENTRY
(9) https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html
(10) https://googleprojectzero.blogspot.com/2022/03/forcedentry-sandbox-escape.html
(11) https://android-developers.googleblog.com/2017/04/an-investigation-of-chrysaor-malware-on.html
(12) https://securelist.com/operation-triangulation-the-last-hardware-mystery/111669/
(13) https://de.wikipedia.org/wiki/Operation_Triangulation
(14) ct.de/ybdd
(15) https://arxiv.org/abs/2103.02282
(16) https://cec.gmu.edu/news/2025-02/find-my-hacker-how-apples-network-can-be-potential-tracking-tool
(17) https://medium.com/@techscribecentral/apples-webkit-exploit-a-deep-dive-into-cve-2025-24201-and-its-implications-e4e770873dbb
(18) https://en.wikipedia.org/wiki/ICloud#Advanced_Data_Protection
(19) https://www.kuketz-blog.de/grapheneos-der-goldstandard-unter-den-android-roms-custom-roms-teil7/
(20) https://www.heise.de/hintergrund/Android-Alternative-Datenschutz-und-Komfort-vereinen-mit-GrapheneOS-10252683.html
(21) https://shop.nitrokey.com/de/shop?search=nitrophone
(22) https://blogs.dsu.edu/digforce/2023/08/23/bfu-and-afu-lock-states/
(23) https://discuss.grapheneos.org/d/12848-claims-made-by-forensics-companies-their-capabilities-and-how-grapheneos-fares
(24) https://www.heise.de/news/Reboot-nach-Inaktivitaet-So-funktioniert-Apples-neues-iOS-Sicherheitsfeature-10056382.html
(25) https://discuss.grapheneos.org/d/20402-cellebrite-exploits-used-to-target-serbian-student-activist
(26) https://en.wikipedia.org/wiki/Comparison_of_mobile_operating_systems