GrapheneOS – das Betriebssystem für bewegte Chaot:innen?

Zunehmend mehr Menschen benutzen mobile Geräte mit GrapheneOS als Betriebssystem. Wir werden sowohl von Einzelpersonen als auch politischen Zusammenhängen regelmäßig gefragt, ob GrapheneOS sicher ist, ob wir die Nutzung empfehlen und wenn ja, was es zu beachten gilt. Einige nehmen ihr Smartphone gleich mit aufs Plenum zum Protokoll schreiben: „Das ist GrapheneOS. Ist sicher.“

Unter einem Indymedia-Artikel zu den jüngsten Angriffen auf das Tor-Netzwerk, der am Rande die Sicherheit von Tails behandelte, wurde gegen uns und Tails gestänkert:

“Capulcu, hört doch mal auf, immer auf veralteter Technologie herumzureiten. Ein GrapheneOS-Telefon (mit im Gegensatz zu Tails sauber implementierter MAC-Randomisierung), dazu ein moderner VPN als Basisschutz für das Profil (kann Proton, Mullvad, iVPN sein), und in dem Profil der klassische Tor Browser bringen in Kombination deutlich mehr in puncto Sicherheit und Privatsphäre. Tails war vielleicht gut in den 2010er Jahren, jetzt ist Zeit, nach vorne zu blicken.”[1]

Aber stimmt die Behauptung auch? Es wird Zeit, dass wir uns der Frage zuwenden, ob bzw. unter welchen Bedingungen wir GrapheneOS empfehlen können. Und ist es wirklich sicherer als Tails?

Eins gleich vorweg: Pauschal und ganz eindeutig lassen sich Fragen nach der Sicherheit so gut wie nie beantworten. Denn es geht niemals nur um die technischen Details eines Geräts. Mindestens ebenso wichtig sind Fragen nach dem vorgesehenen Einsatzzweck, gegen wen es sich zu schützen gilt und welche Konsequenzen zu erwarten sind, falls es schief geht. Erst nach Beantwortung dieser Fragen lässt sich fundiert sagen, ob ein Gerät den Sicherheitsanforderungen gerecht wird.[2] Es ist daher Skepsis angebracht, wenn uns jemand etwas anderes weiß machen will. Wir werden die Auseinandersetzung mit diesen Sicherheitsfragen hier nicht  erledigen – und wollen dies auch gar nicht, schon allein, weil wir es sinnvoll finden, sich im Gruppenprozess auf gemeinsame Sicherheitsstandards und -bedürfnisse zu verständigen. Dennoch lassen sich natürlich einige Anhaltspunkte geben und wir wollen hier ein paar grundsätzliche Punkte anmerken, die zum Nachdenken und selber weiter informieren anregen sollen. Konkrete Handlungsempfehlungen, wie GrapheneOS möglichst sicher genutzt werden kann, geben wir nicht, und wir können auch nicht auf alle Spezialfälle eingehen, wie Leute ihre Geräte verwenden. Stattdessen thematisieren wir zum Ende unseres Textes die Folgen der Verwendung mobiler Geräte für linke Bewegung. Wir hoffen dadurch, die im oben zitierten Kommentar aufgemachte und etwas plumpe Diskussion rein technischer Eigenschaften um eine Auseinandersetzung der politischen Folgen der Verbreitung bestimmter Technologien in unseren Strukturen zu erweitern. Denn die kollektiven Folgen unserer Entscheidungen gehen weit hinaus über das Risiko, zum Ziel der Repressionsapparate und Datenunternehmen zu werden.

Bevor dieser Text vollends in technische Sphären abgleitet, wollen wir darauf hinweisen, dass ein Vergleich von GrapheneOS mit Tails Gefahr läuft, Äpfel mit Birnen zu vergleichen. GrapheneOS ist ein Betriebssystem für Smartphones, Tails ein Betriebssystem für Desktops / Laptops. Die unterliegende Hardware ist also unterschiedlich, was u.a. bedeutet, dass GrapheneOS-Nutzer:innen zwangsläufig ein Gerät benutzen müssen, welches mit Sensoren und Netztechnologien (GSM, etc.) ausgestattet ist, die auf Desktops / Laptops eher selten zu finden sind. Die Aufgabe, den Zugriff auf diese potentiell verräterischen Hardwarekomponenten regulieren zu müssen, stellt sich für Tails in der Form nicht. Auch die Erwartungen an die Nutzbarkeit sind sehr unterschiedlich: Ein Desktopbetriebssystem so zuzunageln, wie es Betriebssysteme für Smartphones machen, hätte massive Akzeptanzprobleme zur Folge. Schließlich sollen Dateien, die mit dem einen Programm erstellt wurden, mit einem anderen Programm geöffnet werden können – und Drag-and-Drop soll bitteschön auch funktionieren. Mit diesen Unterschieden im Hinterkopf ist ein Vergleich trotzdem nicht ganz abwegig, da beide Ansätze versprechen, die Nutzung digitaler Dienste sicherer zu machen.

Was ist GrapheneOS?

GrapheneOS basiert auf dem Android Open Source Project (AOSP) und läuft derzeit nur auf Googles Pixel-Geräten, da nur diese den Sicherheitsanforderungen des Entwickler:innenteams an die Hardware gerecht werden. Das Projekt fokussiert sich darauf, die Sicherheit von Android weiter zu verbessern. Zudem verbessert es den Schutz von Nutzer:innendaten, indem keine unnötigen Netzwerkverbindungen aufgebaut werden und Google-Dienste aus dem System entfernt bzw. deaktiviert werden. Der grundsätzliche Ansatz von GrapheneOS ist es, Funktionen nicht zu entfernen oder Einbußen bei der Kompatibilität hinzunehmen, sondern den Nutzer:innen die Entscheidungen und Konfiguration selbst zu überlassen. Dahingehend unterscheidet sich das Projekt von Apples Ansatz, die Nutzer:innen mit endgültigen Entscheidungen zu bevormunden. Ein Beispiel für die Herangehensweise von GrapheneOS sind die Sandboxed Google Play Services. Diese sind in GrapheneOS nicht vorinstalliert und GrapheneOS lässt sich gut ohne Google-Dienste nutzen. Sie lassen sich jedoch nachinstallieren und laufen dann mit den Berechtigungen einer normalen (sandboxed) App, also ohne die tiefe Systemintegration der Dienste bei einem Pixel mit vorinstalliertem Google Android. Zudem ist es möglich, die Google-Dienste in einem separaten Profil zu installieren, so dass sie keinen Zugriff auf Daten anderer Profile haben.

Über die Jahre hat GrapheneOS viele (teils innovative) Sicherheitsfeatures entwickelt, die auch in Android und andere Projekte wie den Linux-Kernel integriert worden sind. Beispiele sind hier Auto-Reboot, das inzwischen auch iPhones verwenden, oder die eigene hardened-malloc-Bibliothek. Zu beidem später mehr. Das Projekt hat immer wieder Schwachstellen in Android, im gerätespezifischen Pixel Code und im Linux Kernel gefunden und gemeldet, so dass diese geschlossen werden konnten.

GrapheneOS wird durch Spenden finanziert und von einem verhältnismäßig kleinen Entwickler:innenteam betrieben. Als kleines Projekt ist es nicht gefeit davor, dass die Entwicklung  spontan eingestellt oder zumindest unterbrochen werden muss, wie wir es etwa bei DivestOS oder CalyxOS gesehen haben. GrapheneOS ist davon abhängig, dass es Geräte gibt, auf dem das Betriebssystem betrieben werden kann. Uns ist wenig darüber bekannt, woher genau die Spenden kommen. Ein guter Teil der benötigten Infrastruktur wie z.B. Server-Kapazitäten wird ebenfalls von größeren Providern gespendet. Dazu kommen Spenden von Unternehmen wie Proton und Privatpersonen.

Zur Sicherheit von GrapheneOS

Im Juli 2024 tauchten im GrapheneOS-Forum Dokumente von Cellebrite auf, aus denen hervorging, dass Cellebrite (und damit die Cops allgemein) die GrapheneOS-Geräte seit Jahren als einzige auch bei physischem Zugriff nicht knacken konnte. Ende Oktober 2025 wurde dies nochmal durch eine geleakte Präsentation von Cellebrite bestätigt. Cellebrite ist der wichtigste Anbieter von Geräten und Dienstleistungen zur Daten-Extraktion aus Mobilgeräten mit physischem Zugriff – in der Regel über die USB-Schnittstelle. Des Weiteren sind für GrapheneOS keine Fälle remote kompromittierter Geräte aus den letzten Jahren bekannt. Dennoch ist es wichtig zu betonen, dass nie auszuschließen ist, dass neue Schwachstellen entdeckt und für Angriffe ausgenutzt werden. In der Regel erfahren wir davon erst, wenn es schief geht. Deswegen müssen wir uns gut überlegen, wie sehr wir uns auf die technische Sicherheit verlassen wollen.

Kürzlich wurde öffentlich, dass der Druck auf GrapheneOS steigt, sodass sich diese veranlasst fühlten, ihre Hostingfirma OVH zu verlassen. Führungskräfte französischer Strafverfolgungsbehörden sollen ihre Einsatzkräfte den Medienberichten zufolge angewiesen haben, insbesondere mit GrapheneOS ausgestattete Pixel-Smartphones grundsätzlich als sehr verdächtig zu behandeln.

Sowohl Tor als auch aktuell GrapheneOS oder andere verschlüsselte Kommunikationsdienste stehen immer wieder im Fokus politischer Kampagnen. Nutzen wir digitale (verschlüsselte) Kommunikation, müssen wir den Entwickler:innen und ihren Sicherheitsmaßnahmen vertrauen. Die Fälle von ANOM und EncroChat zeigen in jüngerer Vergangenheit, wie schnell dieses Vertrauen obsolet sein kann. Bei beiden Angriffen war verschlüsselte Kommunikation das Ziel. Im Falle von ANOM folgte die Infiltration über die erzwungene Kooperation mit den Entwickler:innen des Customs-Roms, das die Messengerapp mit auslieferte. Im Falle von EncroChat wurden die Updateserver des Projekts infiltriert. Beide Angriffe liefen über mehrere Jahre und waren eine internationale Kooperation von Ermittlungsbehörden. Durch das massenweise Ausleiten von entschlüsselten Nachrichten konnten weltweit zahlreiche Strafprozesse initiiert werden.

Um die technische Sicherheit von GrapheneOS genauer zu diskutieren, beschreiben wir im Folgenden die Sicherheitsarchitektur von GrapheneOS und weitere Sicherheitsfeatures (ab Pixel 8).

Die Sicherheitsarchitektur von GrapheneOS

Starten wir mit der Sicherheitsarchitektur von GrapheneOS. Vieles ist schon Teil von AOSP und wird von GrapheneOS weiter ausgebaut. Ganz grob folgt GrapheneOS folgendem dreiteiligen Ansatz, um die Geräte möglichst sicher zu machen:

1. Die Verkleinerung der Angriffsfläche bedeutet, dass nur absolut notwendige Features im Grundzustand enthalten und aktiviert sind, und alles Unnötige entfernt wird.
2. Durch moderne, sichere Softwareentwicklung wird versucht, ganze Klassen von Programmfehlern (Bugs) auszuschließen (z.B. memory corruption oder dynamic code loading/execution).
3. Durch Containment und Isolation werden die Auswirkungen minimiert, die es hat, wenn ein Angreifer doch mal eine Sicherheitslücke ausnutzen kann, weil jeder Prozess nur minimale Zugriffsrechte hat.

Außerdem gibt es viele kleine technische und prozessorientierte Verbesserungen, z.B. das Fixen von VPN-Leaks unter Android oder das prompte Ausliefern von Sicherheitsupdates derzeit meist noch vor Google selbst.

Wie diese Mechanismen ineinander greifen, lässt sich gut am Beispiel einer Schwachstelle im Linux-Kernel verdeutlichen, die im Android Security Bulletin vom Februar geschlossen wurde und durch die GrapheneOS-Geräte im Gegensatz zu den meisten anderen Android-Geräten nicht angreifbar waren. Es handelte sich dabei um einen Heap-Buffer-Overflow in einem Treiber für USB-Webcams, der Teil des Linux Kernel ist, den auch Android als Basis hat. Nun zu den oben beschriebenen Verteidigungslinien von GrapheneOS (exemplarisch):

• In GrapheneOS ist die USB-Schnittstelle standardmäßig im gesperrten Bildschirm deaktiviert, und zwar sowohl hardwareseitig als auch durch das Betriebssystem. Der Bug kann also nur ausgenutzt werden, wenn die Nutzer:in das Gerät selbst entsperrt. Zum Beispiel ein Cellebrite-Exploit mit physischem Zugriff in einer Polizeikontrolle ist somit schon ausgeschlossen.
• Durch die hardened-malloc-Implementierung von GrapheneOS, die auch hardware memory tagging (MTE) verwendet, hätte die Heap Corruption aufgedeckt und ein erfolgreicher Exploit (erfolgreiches Ausnutzen der Schwachstelle) verhindert werden können. Allerdings hat GrapheneOS erst später begonnen, die hardware memory tagging-Implementierung zum Schutz des Heaps im Linux-Kernel zu aktivieren. Auch wäre eine solche Schwachstelle in einer speichersicheren Programmiersprache wie Rust nicht aufgetreten. Neuentwicklungen von Treibern für Android werden mittlerweile in der Regel in Rust geschrieben. Es werden aber nicht alle Treiber neu geschrieben. Alte verbleiben im C/C++-Code. Nach und nach soll sich aber so die Angriffsfläche verkleinern.
• Schwachstellen in einer App führen in Android nur dazu, dass ein Angreifer Zugriff auf die Berechtigung der App erhält (oder analog z.B. nur zur Sandbox einer bestimmten kompromittierten System-Komponente wie dem Media-Codec). Ein erfolgreicher Exploit für eine Schwachstelle im Linux-Kernel hingegen ermöglicht umfassenden Zugriff. Weil Linux ein monolithischer Kernel ist und auch schlecht gepflegte und selten beachtete Treiber für Peripherie-Geräte nicht durch eine Sandbox vom übrigen Kernel getrennt laufen, ist eine Schwachstelle in einem Kernel-Treiber der einfachste Weg, ein Android-Gerät umfassend zu kompromittieren. Die GrapheneOS-Entwickler:innen bezeichnen daher den Linux-Kernel als größte Schwachstelle in der Sicherheitsarchitektur von Android-Systemen.
• Ein weiterer Aspekt sind die in Mobiltelefonen verbauten Sensoren (Beschleunigungssensor, Lagesensor, Kompass etc.), die von Android als nicht sicherheitsrelevant eingestuft werden und deshalb von allen Applikationen angesprochen werden können. Diese Einstufung ist leichtfertig, da über diese Sensoren kompromittierende Informationen gesammelt werden können. Sämtliche Zugriffsrechte auf Sensoren sind per default für jede Anwendung aktiviert. GrapheneOS erlaubt aber anders als Standard Android, den Zugriff auf Sensoren zu deaktivieren.
• Durch die Implementierung von Verified Boot ist es für einen Angreifer kaum möglich, das System dauerhaft zu kompromittieren. Denn bei persistenter Veränderung würde das Gerät nicht mehr booten. Auch bei erfolgreichem Angriff ist die Nutzer:in nach einem Neustart wieder sicher. Die Auswirkungen eines Exploits sind daher nicht nur räumlich (nur Zugriff auf bestimmte Ressourcen), sondern auch zeitlich eingeschränkt (Neustart). Der Nachteil von Verified Boot ist, dass nur Entwickler:innen Änderungen am System vornehmen können, nicht aber die Nutzer:innen, da nur die Entwickler:innen die Schlüssel besitzen, um Bootloader, System und Apps zu signieren.
• GrapheneOS liefert prompte Backports für (sicherheitsrelevante) Patches im eigenen LTS-Kernel aus. Daher war die Schwachstelle in GrapheneOS bereits lange gepatcht, bevor sie im Android Security Bulletin überhaupt auftauchte.[3] Google und auch viele Desktop-Distributionen brauchen ihre Zeit, bis ein Sicherheitsupdate als stabil gilt und breit ausgerollt wird. Die Pixel-Geräte ab Pixel 8 erhalten sieben Jahre Sicherheitsupdates. Nur Apple und Samsung bieten ähnlich langen Support an im Mobilbereich.

Das Ziel des Ansatzes von GrapheneOS ist es nicht, einfach nur bekannte Sicherheitslücken zu finden und zu schließen (reaktive Sicherheit), sondern fundamentale Schutzgräben ins Betriebssystem einzuziehen, die die effektive Ausnutzung von Schwachstellen verhindern, auch wenn diese noch nicht bekannt sind (0-day). Dieser proaktive Sicherheitsansatz ist im Linux- und Desktop-Bereich allenfalls rudimentär vorhanden, und gerade der Linux-Kernel ist aus Sicherheitsperspektive problematisch, weil Sicherheit dort eben nicht von Anfang an mitgedacht wurde.

Diskussion einiger Sicherheitsfeatures von Pixel-Geräten und GrapheneOS

Pixel-Phones legen kryptographisches Schlüsselmaterial im von Google entwickelten Titan M2 Chip ab, von wo es sich nicht extrahieren lässt. Ohne den Chip lässt sich das Home-Verzeichnis somit nicht entschlüsseln. Das bedeutet auch, dass Schlüssel nicht unnötig dauerhaft im Arbeitsspeicher herumliegen. Der Chip erlaubt die Verwendung der Schlüssel nur nach erfolgreicher Authentisierung (Passworteingabe). Die Zahl der Versuche wird dabei hardwareseitig so limitiert, dass GrapheneOS zufolge schon eine zufällige Sechs-Ziffern-Pin sicher sein soll. Allerdings ist nicht auszuschließen, dass irgendwer z.B. einen Seitenkanal findet und Extraktionsangriffe doch praktikabel werden. Ebenfalls auf dem Sicherheitschip basiert die Auditor-App. Mit dieser App können Geräte gegenseitig überprüfen, dass Hardware, Bootloader und Betriebssystem nicht manipuliert worden sind.

Nette kleine Features sind das automatische Abschalten der Schnittstellen (Wlan, Bluetooth etc.) bei Nicht-Verbindung, sodass darüber keine Angriffe mehr stattfinden können. Auch findet ein Auto-Reboot statt, wenn sich die Nutzer:in für eine konfigurierbare Zeit nicht eingeloggt hat. Dadurch geht das Gerät wieder in den sichereren Before First Unlock (BFU)-Zustand über, in dem keine Geheimnisse im RAM liegen. Weiterhin können Nutzer:innen eine Duress-PIN setzen, die bei (erzwungener) Eingabe alle Daten vom Gerät löscht. GrapheneOS erlaubt es auch, eine Zwei-Faktor-Authentifizierung zum Entsperren des Geräts zu verwenden. Durch Biometrie und PIN soll sowohl vor Shouldersurfing / Kameraüberwachung von Pin-Eingaben als auch vor dem Zwang, den Fingerabdruck abzugeben, geschützt werden. Die Fingerabdruck-Daten werden ebenfalls nicht-extrahierbar im Titan M2 gespeichert.

Smartphone-Angriffe over the air, also das Ausnutzen von Schwachstellen im Baseband (der Prozessor für die Steuerung der Mobilfunkkommunikation), um das Betriebssystem des GSM-Modems zu kompromittieren, waren und sind üblich. Die Schutzmaßnahme: Das Baseband ist bei Pixel-Geräten anders als bei den meisten Smartphones isoliert, d.h., es gibt nur einen minimalen Speicherbereich, auf den Baseband und Arm-CPU gemeinsam zugreifen. Das Baseband kann damit das Betriebssystem schwieriger angreifen. Durch einen Angriff kann es aberaktiviert werden, können Datenübertragungen manipuliert werden, etc.

Der Chip, auf dem sich das Baseband befindet, implementiert weitere Funktionen wie WLAN und GPS, aber jede dieser Komponenten ist separat gesandboxed und unabhängig voneinander. Durch Aktivieren des Flugmodus wird der Mobilfunk deaktiviert, aber WLAN kann wieder aktiviert und verwendet werden, ohne den Mobilfunk erneut zu aktivieren. Dadurch kann das Gerät theoretisch als reines WLAN-Gerät verwendet werden. Absolute Aussagen sind immer schwierig. Verlässlichkeit von Hardware ist einfach sehr begrenzt. Ist ein kompromittiertes Baseband  im Flugmodus wirklich vollständig ausgeschaltet?

Eine Evaluation ist schwierig, da die Treiber bzw. Firmware in dem Gerät proprietärer Code sind. Es ist also nicht alles Open Source in GrapheneOS. Das Gleiche trifft zwar für die üblichen Desktop-Rechner ebenfalls zu. Laptops haben ein proprietäres BIOS/UEFI und Intel ME (sofern nicht große Anstrengungen unternommen werden und beispielsweise Coreboot installiert wird). Allerdings enthält z.B. die Linuxdistribution Debian im Ausgangszustand keine proprietäre Software, was nicht heißt, dass diese nicht dennoch in UEFI, Festplatten-, Tastatur-Firmware usw. enthalten ist. Demgegenüber verwendet Android ein sogenanntes Hardware Abstraction Layer (HAL), in dem die Treiber für die Hardware des Geräts (Kamera, NFC, Modems usw.) liegen. Das HAL besteht zu großen Teilen aus proprietären Blobs und ist sehr eng mit dem Android Linux-Kernel verknüpft. Auch in GrapheneOS sind diese binären Blobs von Google enthalten und es kann nur mit großem Aufwand überprüft werden, was sie tun.

Welche Vorteile hat GrapheneOS gegenüber Tails?

Wir haben keinen Zweifel daran, dass GrapheneOS seit einigen Jahren das sicherste und datensparsamste mobile Betriebssystem ist – zumindest unter den Systemen, deren Verwendung von ihrer Funktionalität her für typische Nutzer:innen in Betracht kommen.

GrapheneOS lässt sich nur auf (relativ aktuellen) Pixel installieren. Dadurch kann der Code optimiert werden, unnötige Module entfernt und die Angriffsfläche verkleinert werden. Das geht bei Tails nicht, weil es darauf ausgelegt ist, auf möglichst vielen Laptops und Desktops zu funktionieren.

Im Vergleich zu Tails profitiert GrapheneOS von der moderneren Sicherheitsarchitektur mobiler Betriebssysteme. Während zur Zeit der Entstehung der heutigen Desktop-Systeme und des Linux-Kernels Sicherheit kaum von Bedeutung war – es gab beispielsweise kaum relevante Angriffe über Netzwerke –, wurde sie bei der Entwicklung von Android von Anfang an als ein wesentliches Designziel mitgedacht. Während Linux-Desktops daher aus Kompatibilitätsgründen so ihre liebe Mühe haben, neue Sicherheitsfeatures z.B. tief in den Kernel zu integrieren, lassen sich bei Android die Vorteile des proaktiven Sicherheitskonzepts inzwischen deutlich erkennen. Wir gehen einige schon oben erwähnte Aspekte vor diesem Hintergrund nochmal genauer durch.

Durch Verified Boot ist sichergestellt, dass der komplette Bootprozess und die Integrität des Systems mit den Schlüsseln der Entwickler:innen abgesichert ist. Verified Boot geht bei GrapheneOS sogar so weit, dass auch die Signaturen installierter Apps geprüft werden. Somit ist es kaum möglich, ein GrapheneOS-Gerät persistent zu kompromittieren. Entsprechend funktionieren auch die Exploits von NSO und Co wie bei anderen Mobilgeräten nicht persistent, sondern müssen nach einem Reboot erneut durchgeführt werden. Das steigert zumindest das Risiko der Angreifer:innen, aufzufliegen. Im Desktop-Bereich gibt es mit Secure Boot zwar Ansätze, die in eine ähnliche Richtung gehen, jedoch nicht so konsequent umgesetzt werden, und die von Nutzer:innen erst eigenständig eingerichtet werden müssen, d.h., wenn ihr Tails benutzt, müsst ihr  der verwendeten Hardware und dem BIOS/UEFI vertrauen. Das kann ein Problem sein, insbesondere, wenn das Bedrohungsmodell von einem Angreifer ausgeht, der sich (unbemerkt) physischen Zugriff auf euren Tails-Rechner verschaffen kann.

Was die Reduktion der Angriffsfläche angeht, wählt Tails einen ähnlichen Ansatz wie GrapheneOS und profitiert hier zusätzlich davon, dass ein Tails-Stick eigentlich immer ausgeschaltet ist. Tails unternimmt jedoch keine besonderen Anstrengungen, bestimmte Klassen von Sicherheitslücken komplett auszuschließen. Dies geschieht nur insoweit, wie es in Debian passiert, auf dem Tails basiert. Und Debian und der Linux-Kernel bestehen nach wie vor weitestgehend aus C/C++-Code, auch wenn allmählich neuer Code auch mal in Rust geschrieben wird. Der Sicherheitsansatz von Tails ist hier also eher reaktiv und baut darauf, mit Debian Stable eine gut getestete Distribution mit ausgereifter Software als Basis zu verwenden. GrapheneOS hat hier deutliche Vorteile, da fast der gesamte Kernel und die meisten Systemkomponenten mit hardware memory tagging geschützt sind (MTE), und zudem in Android von Beginn an ein Großteil des Codes in speichersicheren Programmiersprachen geschrieben worden ist.

Bezüglich des Sandboxing profitiert GrapheneOS davon, dass etwa das Berechtigungssystem von Android mittels SELinux tief in das Betriebssystem integriert ist. Die Apps müssen also kompatibel damit sein und es lassen sich strikte Berechtigungen umsetzen. Wenn in einem normalen Linux-Desktop-System wie Debian ein Angreifer eine Schwachstelle in Thunderbird findet, kann er damit im Prinzip auf dieselben Ressourcen zugreifen wie die Nutzer:in, die den Prozess gestartet hat. Das bedeutet in der Regel, dass alle relevanten Dateien lesbar sind. Dem Angreifer reicht somit eine Lücke in einer einzelnen Anwendung, um weitgehenden Zugriff zu erhalten. Im Gegensatz dazu verhindert das Sandboxing von Android eine derart schnelle Ausweitung eines Angriffs. Die Folge dieses Ansatzes ist es, dass Angreifer:innen mehrere Schwachstellen finden müssen, um sich umfassenden Zugriff auf ein Gerät zu verschaffen. Wir wollen hier nicht verschweigen, dass auch Tails versucht, einen ähnlichen Ansatz mittels AppArmor umzusetzen, aber dies geschieht viel rudimentärer und bedeutet großen Aufwand für jede einzelne Anwendung, da die Entwickler:innen genau entscheiden müssen, welche Berechtigungen nötig sind. Das Ganze ist kaum ins System integriert, und so kommt es denn auch, dass der in Tails enthaltene Tor-Browser nur eingeschränkten Zugriff auf das Dateisystem hat, andere Anwendungen wie Thunderbird aber Zugriff auf das gesamte Dateisystem haben. Auch laufen in Tails einzelne besonders anfällige Systemkomponenten wie media codecs nicht in abgekapselten Bereichen. Abschließend wollen wir bemerken, dass im Desktopbereich der Ansatz „Sicherheit durch Kompartimentierung“ von Qubes OS noch konsequenter umgesetzt wird als von Android. Die Isolation wird bei Qubes OS mittels Xen-basierter Virtualisierung direkt auf der Hardware umgesetzt. Eine Architektur, die GrapheneOS ebenfalls anstrebt, aber bisher nicht realisieren kann. Für technisch versierte Nutzer:innen ist Qubes OS auf jeden Fall einen Blick wert.

Hinsichtlich der technischen Sicherheitsarchitektur lässt sich sagen, dass es mit Tails bei gleicher Nutzung (z.B. Öffnen eines E-Mail-Anhangs) einfacher ist, dass das System (für die laufende Sitzung) umfassend kompromittiert wird als bei GrapheneOS.

Welche Vorteile hat Tails gegenüber GrapheneOS?

Auch wenn mobile Betriebssysteme und die Hardware mobiler Geräte gravierende Sicherheitsvorteile gegenüber klassischen Desktopgeräten haben, gibt es einige Nachteile. Diese betreffen insbesondere das Nutzungsverhalten. Aus unserer Sicht ist es eine der Stärken von Tails, dass es ein sensibles Nutzungsverhalten provoziert. Tails regt, anders als GrapheneOS, nicht dazu an, bei einer heiklen Recherche im Tor Browser zwischendurch zu klären, wer morgen die Kinder aus der Kita abholt oder noch schnell den einen Link an einen Freund weiterzuleiten und dabei aus Versehen die falschen Daten zu copy-pasten… Tails ist dazu designt, für einen bestimmten Zweck gestartet zu werden, z.B. eine Recherche, und dann bis zum Ausschalten auch nur dafür verwendet zu werden. Apropos Ausschalten – es ist immer eine gute Idee, Geräte auszuschalten, aber wer schaltet nachts noch sein Mobilgerät aus?

Einige offensichtliche technische Vorteile seien hier auch noch angemerkt, bei Tails lässt sich die Nutzung von Tor nicht so leicht verkacken, da dies in der Standardeinstellung der einzige Weg ins Internet ist. Diese macht natürlich nur bei Tails in der Form Sinn, weil nicht auch noch die ganze Privatkommunikation über das gleiche Gerät läuft. Wer kauft sich schon mehrere Pixel-Geräte, um Privat- und Politkommunikation zu trennen, wo doch die Profile in GrapheneOS so eine tolle Isolation ermöglichen. Bei GrapheneOS muss man den Tor Browser oder Tor als VPN immerhin noch selber einrichten. Auch das hat sicher schon zu Clearnet-Leaks geführt.

Da die meisten Nutzer:innen ihr Smartphone mal eben schnell entsperren können wollen, werden bei Mobilgeräten meist schwächere Pins/Passwörter verwendet als bei Tails, wo Nutzer:innen die Passphrase relativ selten eingeben müssen. Hoffentlich hält der brute-force-Schutz von Googles Titan M2 dann auch wirklich Stand. Außerdem verwendet GrapheneOS kein Read-Only-Dateisystem. Tails „vergisst“ alle Aktivitäten nach dem Herunterfahren (mit Ausnahme der Dateien im Persistententen Speicher). Dies ist bei GrapheneOS nicht der Fall. Browser-Historie, Nachrichten, erstellte Dokumente, Bilder usw. - alles bleibt erhalten und ist damit bei Zugriff auch für Repressionsbehörden zugänglich. Das A für „Amnesic“ in Tails meint aber nicht nur das Verwischen jeglicher Spuren, sondern erreicht auch ein ähnliches Verhalten wie Verified Boot bei GrapheneOS, nämlich, dass auch ein kompromittiertes System nach einem Neustart wieder in einem sauberen Zustand ist. Hier muss aber einschränkend hinzugefügt werden, dass Verified Boot eine umfassendere Integritätsprüfung darstellt, die sowohl den Bootloader als auch die installierten Apps mit einschließt, was bei Tails nicht der Fall ist. Ein Tails-Stick sollte daher auch nie an einem unsicheren Ort verwahrt werden, wo Angreifer:innen physischen Zugriff haben, um euren Tails-Stick zu manipulieren, so dass bei der nächsten Verwendung wichtige Daten wie Passwörter abfließen oder die Angreifer:innen Live-Zugriff auf das System erhalten.

Wie schon erwähnt, werden GrapheneOS-Updates automatisch installiert, sodass Sicherheitslücken schnell geschlossen werden. Wie bei eigentlich allen Betriebssystemen müssen Nutzer:innen den Entwickler:innen bzw. Infrastrukturbetreiber:innen vertrauen. Denn diese könnten jederzeit bösartige Updates signieren und ausliefern lassen. Zur Vertrauenswürdigkeit der Menschen hinter GrapheneOS können wir nichts sagen, das nicht schon öffentlich bekannt ist. Sie sind technisch sehr kompetent und verfolgen Sicherheit und Datenschutz mit großer Konsequenz. Bei Tails wissen wir, dass das Projekt dezidiert emanzipatorische Ziele verfolgt, das zeigt sich etwa an den Personas, auf deren Bedürfnisse Tails zugeschnitten ist.

Und noch ein Punkt, ein Mobilgerät wird öfter außerhalb von zu Hause mitgenommen. Das bedeutet nicht nur, dass (mehr) Standortdaten gesammelt werden, sondern auch, dass die Wahrscheinlichkeit viel größer ist, dass es Repressionsbehörden in die Finger bekommen.[4] Zudem werden auch sichere Entsperr-Passphrasen schnell mal in der U-Bahn oder im Supermarkt eingegeben. Die Cops brauchen sich dann nur noch das Videomaterial der dortigen Kameras aushändigen zu lassen, um zumindest auf dieses Profil Zugriff zu erhalten. Hier wird der wesentliche Unterschied deutlich. GrapheneOS ist darauf ausgelegt, im alltäglichen Nutzen eines Mobilgeräts ein Maximum an Sicherheit und Datenschutz zu ermöglichen. Tails hingegen ist für die bewusste Nutzung in heiklen Angelegenheiten entwickelt worden. Tails führt daher quasi automatisch zu einer besseren Opsec, wobei diese Behauptung nicht als Freifahrtschein für Fahrlässigkeit missverstanden werden sollte.

Mobilgeräte als Teil des technologischen Angriffs

Kommen wir nun zum spannendsten Teil dieses Texts, nämlich, warum wir immer noch skeptisch sind. Mobilgeräte sind eine der Speerspitzen des (informations-)technologischen Angriffs. Der technologische Angriff ist ein Konzept, das wir aufgegriffen haben, um Technologiekritik als Herrschaftskritik zu betreiben. Konkret verstehen wir unter dem technologischen Angriff, dass technische Innovationen strategisch zur schöpferischen Zerstörung eingesetzt werden. Das bedeutet, wir begreifen die Digitalisierung und Mobiltelefone als ein Vehikel, das diese Zerstörung bis in die letzten Winkel unseres Alltags trägt, als Zertrümmerung der alten Arbeits- und Lebensformen im umfassenden Sinn mit dem Ziel der Unterwerfung unter ein neues technologisches Regime. Wir wollen diese alten Zustände nicht als „gut“ oder gar verteidigenswert darstellen, die Stoßrichtung des technologischen Angriffs jedoch ist konträr zu einer freien und egalitären Gesellschaft. Das mag abstrakt klingen. Wir werden nun aber deutlich machen, was wir meinen. Dabei konzentrieren wir uns nur auf die direkten Folgen des Angriffs für uns als Bewegung – die Folgen der Verbreitung von Smartphone und Co auf die Breite der Gesellschaft haben wir in unseren Texten oft genug analysiert. Die derzeitige gesellschaftliche Rechtsentwicklung und Faschisierung hat seine Ursachen u.a. in den Folgen des technologischen Angriffs. Trump, Musk & Co wären ohne Smartphones und soziale Medien nicht derart erfolgreich. Wir erleben derzeit ein Faschisierung, die  durch die Zerschlagung vorher bestehender zivilgesellschaftlicher Strukturen, die soziale Atomisierung und die algorithmisch-gesteuerte Reichweitenverstärkung der sozialen Netzwerke verstärkt wurde. Die Identifikationsangebote der Faschisierung (Nationalismus, Rassismus, Patriarchat) bieten zumindest Teilen der Gesellschaft den notwendigen Ersatzkitt, um die Atomisierung erträglich zu machen und sich mit den Verhältnissen zu arrangieren. Insofern ist die Faschisierung als komplementär zum technologischen Angriff zu sehen.

Unter diesem technologischen Regime haben alle emanzipatorischen Kräfte systematisch schlechte Karten, gesellschaftliche Relevanz zu entfalten. Faschisierung und technologischer Angriff fallen aus unserer Sicht nicht zufällig zeitlich zusammen, und wir halten eine Bekämpfung der Faschisierung ohne Auseinandersetzung mit dem technologischen Angriff für wenig aussichtsreich.[5]

In den letzten Jahr(zehnt)en hat sich zunehmend mehr Kommunikation ins Digitale verlagert. Diese Entwicklung hat auch vor unseren Gruppen und Bewegungen nicht Halt gemacht. In Teilen der Linken werden die Möglichkeiten des Digitalen unkritisch abgefeiert oder zumindest „trotz alledem“ genutzt. Bei einer überraschenden Räumung, Hausdurchsuchung oder ähnlichem Ereignis werden heute über Messenger und soziale Medien schnell viele Leute erreicht. Es ist also gut, dass es diese Möglichkeit nun gibt. Oder vielleicht doch nicht?

Virtuelle Räume und Messengerkommunikation führen in den seltensten Fällen zu entschlossenem Handeln. Physische Zusammenkünfte finden sicherlich immer noch statt, aber wie viel seltener kommt es aktuell zu organisierten politischen Handlungen und wie sehr helfen Onlinedienste (Social Media) der Handlungsfähigkeit - oder führen zu Ohnmachtsgefühlen und substituieren das Bedürfnis, etwas zu tun? Der Griff zum Mobiltelefon ist daher ein Griff ins Klo – jedenfalls vom Standpunkt einer dynamischen kraftvollen Bewegung, die in der Lage ist, reale Fortschritte in sozialen Kämpfen durchzusetzen. Trotzdem sehen wir auch die Beispiele (People on the move, die Proteste in Hongkong 2019 oder aktuell der GenZ-Proteste z.B. in Marokko), wo Messengerkommunikation soziale Räume nicht ersetzt, sondern erschaffen hat.

Wem das zu viel falsche Nostalgie ist, die kann vielleicht mit der folgenden Begebenheit mehr anfangen. Als im April diesen Jahres in Teilen Spaniens der Strom länger ausfiel, öffnete sich ein Möglichkeitsfenster, um Aktionen ohne Kameraüberwachung an kritischen Orten, etwa in Innenstädten, durchzuführen. Genoss:innen aus Barcelona berichteten uns, dass es auch genug interessierte Leute gab. Allerdings fanden sie nicht zusammen. Denn mit dem Internet fiel auch Signal als einzige verbliebene Kommunikationsstruktur aus und hinterließ einen Haufen handlungsunfähiger Individuen, die sich bestenfalls mal in Kleingrüppchen trafen.

Es bleibt nicht folgenlos für unsere Bewegungen, wenn wir einen derart tiefen Eingriff in unsere Organisationsform zulassen. Klar, auch mit einem Tails-Rechner findet digitale Kommunikation statt. Der Eingriff ist aber weit weniger invasiv. Denn der Rechner wird vielleicht nur alle paar Tage angeschaltet und nicht wie das Smartphone alle paar Minuten gezückt. Außerdem nehmen ihn Leute nicht zum Treffen mit. Er zwingt daher zu verbindlichen Absprachen, die auch ohne Messengerkommunikation funktionieren. Und ja, wir alle saßen schon mal an einem Treffpunkt und keine:r kam oder wir wurden am Bahnhof nicht abgeholt. Wir haben es überlebt.

In der Beantwortung der Frage, welches Gerät oder Betriebssystem verwendet werden sollte, ist die Frage nach der Sicherheit für uns aus den genannten Gründen nachrangig gegenüber der Frage nach den sozialen Folgen für die politische Organisierung. Konkret heißt das: Auch wenn ein bestimmtes Mobiltelefon technisch das sicherere Gerät sein sollte – und wir haben unsere Zweifel an dieser einseitigen Behauptung deutlich gemacht –, verlieren wir durch die Verwendung von Mobiltelefonen als Bewegung mehr, als wir gewinnen. Wir machen uns nicht vor, die Entwicklung umkehren zu können. Der technologische Angriff läuft auch in unseren engsten Beziehungen auf Hochtouren, aber wir werden weiter Überzeugungsarbeit leisten, uns ihm entgegenzustellen, wo es möglich ist.

Bevor man uns jetzt nachsagt, wir würden die Risiken von Überwachung und Repression verharmlosen: Ja, die Überwachung unserer Kommunikation und Analyse unserer Strukturen wird für die Behörden im Digitalen um ein Vielfaches effizienter und praktikabler als im Analogen. Sie wird aber umso leichter, je mehr Kommunikation digital stattfindet. Mobilgeräte waren diesbezüglich für die Linke ein echter Gamechanger. Außerdem erzeugen diese Geräte gänzlich neue Klassen von Daten, z.B. Standort- oder Sensordaten. Wir glauben deshalb, dass mehr (GrapheneOS-) Smartphones zu mehr statt weniger Repression führen werden, schlicht und ergreifend, weil mehr Kommunikation darüber stattfinden wird als es sie über (Tails-) Desktop-Rechner je gegeben hätte. Auch wenn das Gerät verhältnismäßig schwer zu kompromittieren ist, birgt das Gefühl der Sicherheit die Gefahr des fahrlässigen Umgangs, sodass das eigene Verhalten technische Sicherheitsgewinne im Handumdrehen zunichte machen kann. Mobile Geräte führen in diesem Sinne zu einer Vergrößerung der (sozialen) Angriffsfläche.

Die Frage, die wir uns stellen, lautet also, ob und für was wir überhaupt ein Smartphone haben wollen und welche Folgen dieses Gerät für unser Leben und unsere Organisierungen hat, oder ob wir nicht lieber die Ressourcen investieren, starke analoge Strukturen aufzubauen (z.B. regelmäßige Treffpunkte, vereinbarte Orte im Fall von spontanen Ereignissen usw.). Und wenn wir – aus welchen Gründen auch immer – zu dem Schluss kommen, dass am Mobiltelefon keine Weg vorbeiführt: Welches Verhältnis wollen wir zu dem Gerät haben und können wir es nicht aus unserer politischen Organisierung heraushalten? Welches Verhältnis wollen wir zu einer Technologie haben, die den technologischen Angriff tief in unsere sozialen Strukturen trägt? Wir sollten diese Fragen nicht leichtfertig beantworten nur mit einem Blick auf die technische Sicherheit von Endgeräten. Und wenn wir darauf bauen, neue Technologien entgegen der im Design eingeschriebenen Zwecke zu verwenden, sollten wir uns Gedanken darüber machen, wie erfolgreich diese Strategie sein kann angesichts der existierenden Machtverhältnisse, und wo ihre Grenzen liegen.

Wir wollen die Antworten auf diese Fragestellungen nicht vorwegnehmen, sondern eine ernsthafte und kollektive Auseinandersetzung anstoßen. Die kollektiven Folgen unserer Entscheidungen gehen weit hinaus über das Risiko, zum Ziel der Repressionsapparate und Datenunternehmen zu werden.

___

[1] https://de.indymedia.org/node/465919 
[2] Eine bewusste und formale Auseinandersetzung mit diesen Fragen wird als Threat Modelling bezeichnet.
[3] Auch wenn GrapheneOS große Anstrengungen unternimmt, Sicherheitsupdates zeitnah auszuliefern, entwickelt Google Android gerade in einer problematische Richtung, indem nur noch quartals- statt monatsweise Updates ausgeliefert werden sollen. Die Schwachstellen sind so einem großen Personenkreis mehrere Monate bekannt, bevor Quellcode veröffentlicht werden darf, der sie fixt. Sicherer wird Android so nicht, auch wenn mehr Hersteller behaupten werden können, auf dem Stand des (vor-) letzten Sicherheitsupdates zu sein.
[4] Bei Leuten, die nichts mehr ohne Handy machen, ist es dafür natürlich schwieriger das Gerät unbemerkt zu manipulieren ;)
[5] Zum Zusammenhang von gesellschaftlicher Rechtsentwicklung und Technologie vgl. die diesbezüglichen Texte in unserer aktuellen Broschüre Debunk, z.B. „ChatGPT als Hegemonieverstärker“, „Bullshitting – die Normalisierung des Postfaktischen“ oder „Big-Tech goes MAGA“.