GrapheneOS: Der Goldstandard unter den Android-ROMs – Custom-ROMs Teil7

1. Auf dem Prüfstand

In der Artikelserie »Custom-ROMs« möchte ich einige alternative Android-Systeme näher beleuchten. Der Schwerpunkt liegt dabei auf der Analyse des Datensendeverhaltens. Es wird untersucht, wohin die Custom-ROMs Verbindungen aufbauen und welche Daten dabei übermittelt werden. Die Ergebnisse sollen Aufschluss darüber geben, wie datenschutzfreundlich ein Custom-ROM in der Standardkonfiguration ist und daraus Tipps ableiten, wie sich das »Nach-Hause-Telefonieren« einschränken oder sogar vollständig abschalten lässt.

Im vorliegenden Beitrag wird GrapheneOS einer Analyse unterzogen. Das Custom-ROM wird wie folgt beworben:

GrapheneOS is a privacy and security focused mobile OS with Android app compatibility developed as a non-profit open source project. It’s focused on the research and development of privacy and security technology including substantial improvements to sandboxing, exploit mitigations and the permission model.

Wird GrapheneOS dem gerecht? Nachfolgend werfen wir einen Blick in das Datensendeverhalten des Systems.

• Android: GrapheneOS, CalyxOS und Co. unter der Lupe – Custom-ROMs Teil1
• CalyxOS: De-Googled geht anders – Custom-ROMs Teil2
• iodéOS: Datenschutzfreundlich, aber Abstriche bei der Sicherheit – Custom-ROMs Teil3
• LineageOS: Weder sicher noch datenschutzfreundlich – Custom-ROMs Teil4
• DivestOS: Datenschutzfreundlich und erhöhte Sicherheit – Custom-ROMs Teil5
• /e/: Datenschutzfreundlich bedeutet nicht zwangsläufig sicher – Custom-ROMs Teil6
• GrapheneOS: Der Goldstandard unter den Android-ROMs – Custom-ROMs Teil7

2. GrapheneOS

GrapheneOS ist ein gemeinnütziges, Open-Source-Betriebssystem (MIT- und Apache License 2.0) für mobile Geräte mit Schwerpunkt auf Datenschutz und Sicherheit. Das Projekt konzentriert sich auf die Erforschung und Entwicklung fortschrittlicher Datenschutz- und Sicherheitstechnologien. Dazu gehören wesentliche Verbesserungen in den Bereichen Sandboxing, Exploit-Schutz und Android-Berechtigungsmodell. GrapheneOS basiert eng auf dem Android Open Source Project (AOSP), erweitert dieses aber um zahlreiche Funktionen und Maßnahmen, die die Sicherheit und den Datenschutz verbessern.

Es wird exklusiv für Google Pixel-Geräte entwickelt – andere Geräte werden nicht unterstützt. Im Vergleich zu anderen Custom-ROMs ist die Auswahl an Geräten daher sehr eingeschränkt. Hintergrund dieser Einschränkung sind die hohen Sicherheitsanforderungen von GrapheneOS. Die folgenden Anforderungen werden derzeit nur von Google Pixel Geräten vollständig erfüllt:

• Support for using alternate operating systems including full hardware security functionality
• Complete monthly Android Security Bulletin patches without any regular delays longer than a week
• At least 4 years of updates from launch (Pixels now have 7)
• Vendor code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they’re released)
• Linux 5.15 or Linux 6.1 Generic Kernel Image (GKI) support
• Hardware memory tagging (ARM MTE or equivalent)
• BTI/PAC, CET or equivalent
• PXN, SMEP or equivalent
• PAN, SMAP or equivalent
• Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode / decode, image processor and other components
• Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
• Verified boot with rollback protection for firmware
• Verified boot with rollback protection for the OS (Android Verified Boot)
• Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
• StrongBox keystore provided by secure element
• Hardware key attestation support for the StrongBox keystore
• Attest key support for hardware key attestation to provide pinning support
• Weaver disk encryption key derivation throttling provided by secure element
• Inline disk encryption acceleration with wrapped key support
• 64-bit-only device support code
• Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers

Außerdem habe ich Daniel Micay um eine Stellungnahme gebeten, warum derzeit nur Google Pixel-Geräte unterstützt werden. Die vollständige Stellungnahme ist hier zu finden. Hier eine gekürzte Version:

Pixels are currently the only Android devices providing both strong security and proper alternate OS support. There are currently no other devices meeting even the most basic security requirements while running an alternate OS. GrapheneOS is very interested in supporting a non-Pixel brand, but the vast majority of Android OEMs do not take security seriously. Samsung takes security almost as seriously as Google, but they deliberately cripple their devices when you unlock them to install another OS and don’t allow an alternate OS to use important security features. If Samsung permitted GrapheneOS to support their devices properly, many of their phones would be the closest to meeting our requirements. They’re currently missing the very important hardware memory tagging feature, but only because it’s such a new feature, and we’re optimistic that the next generation Snapdragon and Exynos SoC platforms will support it.

[…]

Die Installation von GrapheneOS kann entweder über die Kommandozeile oder über einen benutzerfreundlichen Web-Installer erfolgen, der auch für Anfänger geeignet ist. Sobald die Systemvoraussetzungen erfüllt sind, kann die Installation in wenigen Minuten abgeschlossen werden.

Interessierte können sich vorab in der umfangreichen Dokumentation / FAQ über GrapheneOS informieren und über das Community-Forum und andere Kanäle Hilfe erhalten. Ein Teil der FAQ ist den Netzwerkverbindungen gewidmet, die aufzeigen, wohin (Server/Gegenstelle) und zu welchem Zweck das System Verbindungen aufbaut:

By default, GrapheneOS only makes remote connections to GrapheneOS services and the network provided DNS resolvers. There aren’t any analytics/telemetry in GrapheneOS. The only information revealed to the GrapheneOS servers are the generic device model (such as Pixel 7 Pro) and OS version which are necessary for obtaining updates. The default connections provide the OS and apps with updates, set the system clock, check each network connection for internet connectivity, download a global database (does not vary based on location) with predicted satellite locations when using Location and obtain attestation chain signing keys for the hardware keystore needed for the hardware-based attestation feature.

GrapheneOS wird standardmäßig ohne Google-Anwendungen und Google Play-Dienste ausgeliefert. Bei Bedarf kann jedoch eine spezielle Version namens Sandboxed Google Play über den GrapheneOS App-Store installiert werden. Weitere Informationen dazu findet ihr unter »4.6 Installation von Sandboxed Play Services«.

2.1 Verwendetes Setup

Während der erstmaligen Einrichtung von GrapheneOS kann die Standortermittlung aktiviert/deaktiviert werden. Unabhängig von eurer Entscheidung bei der Einrichtung kann die Einstellungen jederzeit während des Betriebs angepasst werden:

Während der Testphase kam die folgende GrapheneOS-Version zum Einsatz:

• Google Pixel 6a (bluejay): bluejay-factory-2023120800.zip (8. Dezember 2023)

2.2 Privates DNS

Standardmäßig ist die Option »Privates DNS« auf Automatisch eingestellt. Über Einstellungen -> Netzwerk & Internet -> Privates DNS wird die Einstellung auf Aus gesetzt. DNS-Anfragen sollen meinen (Test-)Router erreichen bzw. für diesen lesbar sein und nicht über DNS over TLS getunnelt werden.

3. Datensendeverhalten: Start – Anmeldung – Updates

Sowohl die Voraussetzungen an die Systemumgebung, als auch die (Netzwerk-)Tools, mit denen die Datenmitschnitte erfolgen, wurden im ersten Teil der Artikelserie beschrieben. Nachfolgend werden unterschiedliche (Anwendungs-)Szenarien beleuchtet. Was passiert bspw. beim Start des Gerätes? Welche Verbindungen werden initiiert, wenn die GPS-Schnittstelle aktiviert wird? Und welche Daten überträgt der Standardbrowser nach dem Aufruf?

3.1 Start/Neustart

Noch während des Boot-Vorgangs bzw. sobald ein Netzwerkinterface (WiFi, Mobile) verfügbar ist, werden folgende (DNS-)Namensauflösungen initiiert:

• time.grapheneos.org
• connectivitycheck.grapheneos.network

Nach der Auflösung der Domainnamen in die zugehörige IP-Adresse startet das System eine Aktualisierung der (Netzwerk-)Zeit via HTTPS zum Server time.grapheneos.org. Unmittelbar danach erfolgt ein Connectivity- bzw. Captive-Portal-Check, um sicherzustellen, dass ein Gerät vom Access-Point bzw. Internet Service Provider nicht nur eine IP-Adresse erhalten hat, sondern tatsächlich auch Ziele im Internet erreichen kann. Zur Prüfung, ob eine Verbindung besteht, sendet GrapheneOS eine Anfrage an die Adresse connectivitycheck.grapheneos.network. Die Überprüfung der Konnektivität erfolgt durch folgende GET-Anfrage:

GET /generate_204 HTTP/1.1
Connection: close
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.32 Safari/537.36
Host: connectivitycheck.grapheneos.network
Accept-Encoding: gzip, deflate, br

Als Antwort erfolgt dann ein 204er-Statuscode:

HTTP/1.1 204 No Content
Server: nginx
Date: Mon, 10 Dec 2023 08:15:00 GMT
Connection: close
X-Robots-Tag: none

Eine zweite Verbindung erfolgt dann zu grapheneos.online und ist eine Art Fallback, wenn die HTTP(S)-Verbindung zu connectivitycheck.grapheneos.network fehlschlägt. Während der Tests wurde die Verbindung meist zu beiden Adressen hergestellt, sobald der Captive-Portal-Check durchgeführt wurde.

3.2 Nach Anmeldung am System

Nach erfolgreicher Anmeldung/Authentifizierung am System wird eine Verbindung zur GrapheneOS-Gegenstelle remoteprovisioning.grapheneos.org hergestellt. Android-Geräte, die mit Android 8 oder einer neueren Version auf den Markt kommen, unterstützen die hardwarebasierte Authentifizierung als Teil der Hardware Keystore API, auch Remote Provisioning genannt. Jedes Gerät erzeugt ein eindeutiges, statisches Schlüsselpaar. Der öffentliche Teil dieses Schlüsselpaars wird vom Hersteller direkt während der Produktion an die Google-Server übermittelt und dient später als Vertrauensbasis für die Bereitstellung. Der private Schlüssel verlässt nie die sichere Umgebung, in der er erzeugt wurde.

Wenn ein Gerät zum ersten Mal eine Verbindung zum Internet herstellt, erzeugt es eine Zertifikatsanforderung für die erzeugten Schlüssel und signiert diese mit dem privaten Schlüssel, der dem bei der Herstellung übermittelten öffentlichen Schlüssel entspricht. Die Backend-Server von Google überprüfen die Authentizität der Anforderung, signieren die öffentlichen Schlüssel und geben Zertifikatsketten oder eine Authentifizierung zurück. Der Schlüsselspeicher auf dem Gerät speichert dann diese Zertifikatsketten und weist sie den Anwendungen zu, wenn eine Bestätigung/Authentifizierung angefordert wird. Diese Schlüsselbestätigung ist bspw. Voraussetzung für Dienste wie SafetyNet.

Diese Zertifikatsketten werden regelmäßig aktualisiert. Im Gegensatz zu anderen Custom-ROMs verwendet GrapheneOS nicht direkt den Remote-Server von Google (remoteprovisioning.googleapis.com), sondern leitet die Anfrage über einen Reverse-Proxy weiter. Über Einstellungen -> Netzwerk und Internet -> Attestation Key Provisioning kann auch der Standard-Google-Server ausgewählt werden.

3.3 Geräte-Updates

GrapheneOS prüft regelmäßig (standardmäßig alle vier Stunden), ob neue Systemaktualisierungen verfügbar sind. Der Update-Check erfolgt über die Adresse releases.grapheneos.org. Die Verbindung zur Gegenstelle ist durch TLS-Certificate-Pinning gegen das Aufbrechen der TLS-Verbindung geschützt. In der Dokumentation von GrapheneOS finden sich folgende Hinweise zur Verbindung:

The GrapheneOS System Updater app fetches update metadata from https://releases.grapheneos.org/DEVICE-CHANNEL approximately once every four hours when connected to a permitted network for updates.

Once an update is available, it tries to download https://releases.grapheneos.org/DEVICE-incremental-OLD_VERSION-NEW_VERSION.zip for a delta update, and then falls back to https://releases.grapheneos.org/DEVICE-ota_update-NEW_VERSION.zip.

No query / data is sent to the server, so the only information given to it are the variables in these 3 URLs (device, channel, current version) which is necessary to obtain the update.

Certificate-Pinning ist Teil mehrerer Sicherheitsvorkehrungen. Das Update-Paket wird mit einem Offline-Schlüssel signiert und der Update-Client bzw. das Recovery verifiziert die Signatur, um sicherzustellen, dass es sich nicht um ein Downgrade handelt. Zusätzlich wird auch die interne Update-Nutzlast von der Update-Engine signiert und verifiziert, um vor Downgrades zu schützen. Weitere Informationen zu Updates bzw. den Sicherheitsmaßnahmen sind hier zu finden.

Die Prüfung, das Herunterladen und die Installation der Updates erfolgen automatisch bzw. Over-The-Air (OTA). Nach einem Neustart ist das Gerät auf dem neuesten Stand.

4. Datensendeverhalten: Im Betrieb

4.1 24 Stunden Mitschnitt

Das Smartphone wird in einem Zeitraum von 24 Stunden nicht benutzt. Stattdessen wird geprüft, welche Verbindungen das (Standard-)System innerhalb von 24 Stunden initiiert hat. Es wurde mehrfach versucht, die (Netzwerk-)Zeit über HTTPS zu aktualisieren und mehrmals Update-Checks durchgeführt. Ansonsten wurden keine weiteren Verbindungen vom System initiiert. Dies ändert sich natürlich, wenn der Benutzer weitere Applikationen installiert und diese bspw. mittels Polling/Push Daten abfragen bzw. erhalten.

4.2 Aktivierung Netzwerkschnittstelle

Bereits während des Boot-Vorgangs wird ein Captive-Portal-Check durchgeführt, sofern eine Netzwerkschnittstelle (WiFi, Mobile) aktiv ist. Wird das Gerät zwischenzeitlich in den Flugmodus versetzt und danach wieder ein Netzwerkinterface aktiviert, wird erneut ein Captive-Portal-Check initiiert. Dies bedeutet einen erneuten Verbindungsaufbau zu connectivitycheck.grapheneos.network. Was dabei auffällt: Die Verbindungen werden nicht durch das VPN getunnelt, sondern werden daran vorbeigeleitet. Das hat mich stutzig gemacht, denn selbst wenn bei der VPN-Verbindung die Option Verbindungen ohne VPN blockieren aktiv ist, werden die Captive-Portal-Checks einfach am VPN vorbei getunnelt. Aus meiner Sicht ist das problematisch, Daniel Micay sagt dazu:

Connectivity checks aren’t a VPN leak but rather are part of the low-level functionality for establishing a connection to the internet. They’re empty HTTP/HTTPS GET requests with a standard frozen user agent to a standard URL. They don’t send any data. VPNs require that the OS establishes an internet connection and resolves their hostname via DNS in order to connect. Connectivity checks allow the OS to determine which networks have internet access to choose a working one and the main reason they exist is to detect and handle captive portals. On a Wi-Fi or other network with a captive portal, the connectivity checks will detect it, create a notification about it and the user can use the WebView-based interface opened from the notification to handle the captive portal since it has a special case bypassing the VPN. This allows you to deal with captive portals while leaving your always-on VPN enabled instead of temporarily disabling it and connecting to a non-HTTPS website in a browser to trigger the captive portal UI. GrapheneOS provides 3 choices for connectivity checks:

• the default of using GrapheneOS servers with at most 4 day logging
• standard connectivity checks to blend in with other Android devices while using a VPN and disabling them.

We recommend using the default when not using a VPN and using the standard mode when using a VPN if you want to blend in with other Android users who use VPNs. Disabling it is provided as an option for people who want it, but there isn’t really a good reason to do it.

Google sieht das übrigens ähnlich und wird an dem Verhalten nichts ändern. Ein dazu eingereichtes Issue hat den Status »Won’t Fix« (Intended Behavior). Dies wird wie folgt begründet:

We have looked into the feature request you have reported and would like to inform you that this is working as intended. We do not think such an option would be understandable by most users, so we don’t think there is a strong case for offering this. As for disabling connectivity checks :

• the VPN might be actually relying on the result of these connectivity checks (they are available through public APIs).
• the VPN may be a split tunnel, letting part of the traffic over the underlying network, or only affect a given set of apps. In both these cases, the connectivity checks are still necessary for smooth operation of all the legitimate traffic that doesn’t go over the VPN.
• the connectivity checks are far from the only thing exempted from the VPN ; privileged apps can also bypass the VPN and this is necessary for their operation in many cases. An example is IWLAN, or tethering traffic.
• it’s unclear to us what specific privacy impact is meant. The connectivity checks reveal there is an Android device at this address, which is plenty clear from the L2 connection and from the traffic going over the VPN anyway.

Obwohl die Erklärungen von Micay und Google überzeugend sind, ziehe ich es vor, selbst entscheiden zu können, welche Verbindungen durch das VPN geleitet werden und welche nicht. Für diejenigen, die nicht möchten, dass der Captive-Portal-Check am VPN vorbeigeschleust wird, bleibt letztlich nur die Option, den Captive-Portal-Check zu deaktivieren, was von GrapheneOS unterstützt wird.

4.3 Vanadium

GrapheneOS wird standardmäßig mit dem Vanadium Browser ausgeliefert, einer gehärteten und datenschutzfreundlichen Variante von Chromium, die als WebView für andere Apps zur Darstellung von Webinhalten dient. Der Browser kann optional als Standardbrowser konfiguriert werden. Historisch gesehen lag der Schwerpunkt des Projekts vorrangig auf Sicherheitsverbesserungen und Hardening. Für die nahe Zukunft sind jedoch Erweiterungen wie Inkognito-Modus, Inhaltsfilterung (einschließlich Werbeblocker), Backup/Restore und weitere Funktionen geplant.

Nachfolgend wird das Datensendeverhalten des Browsers betrachtet. Unmittelbar nach dem Start werden die folgenden Verbindungen initiiert:

• update.vanadium.app
• dl.vanadium.app

[1] Betrachten wir den Verbindungsaufbau zum Host »update.vanadium.app« etwas genauer:

content-length:   1242                                                                                                                                
content-type:     application/json                                                                                                                    
sec-fetch-site:   none                                                                                                                                
sec-fetch-mode:   no-cors                                                                                                                             
sec-fetch-dest:   empty                                                                                                                               
user-agent:       Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36                     
accept-encoding:  gzip, deflate, br

{
    "request": {
        "@os": "android",
        "@updater": "chromium",
        "acceptformat": "crx3,puff",
        "app": [
            {
                "appid": "llkgjffcdpffmhiakmfcdcblohccpfmo",
                "cohort": "1::",
                "enabled": true,
                "event": [
                    {
                        "download_time_ms": 199,
                        "downloaded": 2903,
                        "downloader": "direct",
                        "eventresult": 1,
                        "eventtype": 14,
                        "nextversion": "1.0.0.14",
                        "previousversion": "0.0.0.0",
                        "total": 2903,
                        "url": "http://edgedl.me.gvt1.com/edgedl/chromewebstore/L2Nocm9tZV9leHRlbnNpb24vYmxvYnMvYWM3QUFZQV9zN2JXZFNHTWhCbGtIMVUwdw/1.0.0
.14_llkgjffcdpffmhiakmfcdcblohccpfmo.crx"
                    },
                    {
                        "eventresult": 1,
                        "eventtype": 3,
                        "nextfp": "1.3e4f959036fef1cae2b1f426864a23f11caae1c96a2816523f2daf4213c3cc73",
                        "nextversion": "1.0.0.14",
                        "previousversion": "0.0.0.0"
                    }
                ],
[...]

Vanadium sucht über die Adresse update.vanadium.app nach Updates für Komponenten, die bspw. widerrufene Zertifikate bereitstellen. Der Download erfolgt dann über die Adresse dl.vanadium.app. Beide Adressen werden über einen Reverse-Proxy weitergeleitet und haben als eigentlichen Endpunkt entweder den Google-Server »update.googleapis.com« oder Content Delivery Networks (CDNs). Der Proxy stellt sicher, dass das Gerät nicht direkt mit Google kommuniziert und bspw. die IP-Adresse übermittelt.

Insgesamt gibt es am Datensendeverhalten des Browsers nichts auszusetzen. Lediglich die Voreinstellungen könnten kritisiert werden. Über Einstellungen -> Datenschutz und Sicherheit kann man bspw. wählen, ob jede Tastatureingabe an die Suchmaschine übermittelt werden soll oder erst nachdem der Suchbegriff vollständig eingegeben und abgeschickt wurde: Suchvorschläge verbessern an/aus.

Auch die (Sicherheits-)Updates sind immer auf dem neuesten Stand. Wenn das Projekt jetzt noch einen Werbeblocker und andere datenschutzrelevante Funktionen integrieren würde, wäre das hervorragend und Konkurrenten wie Brave müssten sich auf einen verschärften Wettbewerb einstellen.

4.4 (GPS-)Standort

Der Standort eines Smartphones kann auf verschiedene Arten ermittelt werden. Die wohl wichtigsten Hilfsmittel dafür sind GPS/GLONASS, WiFi und das Mobilfunk-Netzwerk. Im Falle von GPS ermittelt das Gerät selbst seine Position durch Kommunikation mit Satelliten. Da die Bestimmung des Standorts via GPS vergleichsweise lang dauert, wird zusätzlich Assisted GPS (abgekürzt als A-GPS) eingesetzt. A-GPS ist ein System, das die Zeit bis zum ersten Fixieren eines satellitengestützten Positionierungssystems (GPS) meist deutlich verbessert – die GPS-Positionsbestimmung wird also beschleunigt. Wie funktioniert das? Bei Mobiltelefonen ist anhand der Funkzelle, in der euer Gerät eingebucht ist, der ungefähre Aufenthaltsort bereits bekannt. Via Secure-User-Plane-Location-Protokoll (SUPL) wird nun dieser ungefähre Standort an einen SUPL-Server gesendet, der anhand dieser Informationen den Suchbereich für die Satellitensignale einschränkt und somit eine schnelle GPS-Positionsbestimmung ermöglicht. Die Kommunikation mit dem SUPL-Server erfolgt via TCP/IP über das UserPlane Location Protocol.

Solch einen SUPL-Server nutzen Android-Systeme, um die Ortungszeit für GNSS (GPS, GLONASS usw.) erheblich zu beschleunigen. Bei GrapheneOS wird hierbei die Gegenstelle supl.grapheneos.org über Port 7275 kontaktiert. Anbei der gekürzte Datenmitschnitt:

Internet Protocol Version 4, Src: 10.215.173.1, Dst: 146.59.144.170
Transmission Control Protocol, Src Port: 46814, Dst Port: 7275, Seq: 1, Ack: 1, Len: 93

[...]

OMA UserPlane Location Protocol
    ULP-PDU
        length: 93
        version
            maj: 2
            min: 0
            servind: 0
        sessionID
            setSessionID
                sessionId: 4
                setId: nai (4)
                    nai: suplsetid@broadcom.com                       
        message: msSUPLSTART (1)
            msSUPLSTART
                sETCapabilities
                    posTechnology
                        ..0. .... agpsSETassisted: False
                        ...1 .... agpsSETBased: True
                        .... 1... autonomousGPS: True
                        .... .0.. aflt: False
                        .... ..1. ecid: True
                        .... ...0 eotd: False
                        0... .... otdoa: False
                        ver2-PosTechnology-extension
                            gANSSPositionMethods: 5 items
                                Item 0
                                    GANSSPositionMethod
                                        ganssId: Galileo (0)
                                        gANSSPositioningMethodTypes
                                            .... ..0. setAssisted: False
                                            .... ...1 setBased: True
                                            1... .... autonomous: True
                                        gANSSSignals: 80 [bit length 1, 7 LSB pad bits, 1... .... decimal value 1]
                                            1... .... = signal1: True
                                            .0.. .... = signal2: False
                                            ..0. .... = signal3: False
                                            ...0 .... = signal4: False
                                            .... 0... = signal5: False
                                            .... .0.. = signal6: False
                                            .... ..0. = signal7: False
                                            .... ...0 = signal8: False

[...]                    
                   
                locationId
                    cellInfo: ver2-CellInfo-extension (3)
                        ver2-CellInfo-extension: lteCell (2)
                            lteCell
                                cellGlobalIdEUTRA
                                    plmn-Identity
                                        mcc: 3 items
                                            Item 0
                                                MCC-MNC-Digit: 2
                                            Item 1
                                                MCC-MNC-Digit: 6
                                            Item 2
                                                MCC-MNC-Digit: 2
                                        mnc: 2 items
                                            Item 0
                                                MCC-MNC-Digit: 0
                                            Item 1
                                                MCC-MNC-Digit: 2
                                    cellIdentity: 1190420 [bit length 28, 4 LSB pad bits, 0001 0001  1001 0000  0100 0001  0100 .... decimal value 18416660]
                                physCellId: 292
                                trackingAreaCode: b876 [bit length 16, 1011 1000  0111 0110 decimal value 47222]            
                                rsrqResult: -48dB <= RSRQ < -470dB (93)
                                rsrqResult: -15,5dB <= RSRQ < -15,0dB (9)
                                ta: 5 
                                earfcn: 6300
                    status: current (1)
                qoP
                    horacc: 51,159090m (19)
                    maxLocAge: 1s

Um zu verhindern, dass Google die ungefähren Standortdaten erhält, die bspw. mit der IP-Adresse verknüpft werden können, hat GrapheneOS einen SUPL-Proxy-Server eingerichtet (supl.grapheneos.org), der alle SUPL-Anfragen stellvertretend entgegennimmt bzw. weiterleitet. Das Ergebnis: Google kann die Ortungsanfrage keinem Nutzer/Gerät zuordnen. Fairerweise muss ich allerdings erwähnen, dass GrapheneOS diesen SUPL-Proxy-Server als Reaktion auf meine Analyse von CalyxOS betreibt. Das Team um Daniel Micay hat umgehend auf meine kritischen Ergebnisse zu CalyxOS reagiert und eine Lösung für das Google-SUPL-Problem gefunden.

Hinweis: Die Verbindung zum SUPL-Server ist eigentlich TLS-verschlüsselt. Nach einer Anpassung der Datei /system/vendor/gnss/gps.xml erfolgt der Verbindungsaufbau dann unverschlüsselt und konnte mitgelesen werden:

tlsEnable="false"

Zur Beschleunigung der Standortbestimmung verwendet GrapheneOS neben SUPL zusätzlich PSDS-Hilfsdaten. PSDS steht für Predicted Satellite Data Service, der Informationen über die Umlaufbahnen, den Status der Satelliten, Daten über die Umweltbedingungen auf der Erde und Informationen zur Zeitanpassung liefert. Die statischen PSDS-Daten bezieht GrapheneOS von der Gegenstelle »broadcom.psds.grapheneos.org« – die Dateien werden also direkt von GrapheneOS bereitgestellt:

• https://broadcom.psds.grapheneos.org/rto.dat
• https://broadcom.psds.grapheneos.org/lto2.dat
• https://broadcom.psds.grapheneos.org/rtistatus.dat

4.6 Installation Sandboxed Play Services  [Optional]

Optional hat man bei GrapheneOS die Möglichkeit, Sandboxed Play Services zu installieren. Dabei handelt es sich um eine Variante der Google Play-Dienste, die in einer abgeschotteten Umgebung (Sandbox) ausgeführt wird, ohne den vollen Systemzugriff zu gewähren, den die herkömmlichen Google-Dienste normalerweise haben. Da die Google Play-Dienste unter GrapheneOS letztlich wie »normale« Apps behandelt werden, sind sie nur in dem Benutzer- oder Arbeitsprofil verfügbar, unter dem sie installiert wurden. Auf diese Weise kann bspw. der Hauptnutzer sein Gerät googlefrei verwenden, während Google-Dienste und über den Play Store erworbene Apps in einem separaten Nutzerkonto oder Arbeitsprofil installiert werden können. Nachfolgend werfen wir einen Blick auf das Datensendeverhalten.

Nach Installation der Sandboxed Play Services wird eine Verbindung zu den folgenden Gegenstellen aufgebaut:

• pay.google.com
• wallet.google.com
• cert-wallet.apple.com
• business.google.com
• gds.google.com
• play.google.com
• enterprise.google.com
• pay.sandbox.google.com
• market.android.com
• wallet.apple.com
• walletshare.googleapis.com
• one.google.com
• staging-walletshare.sandbox.googleapis.com
• digitalkeypairing.org
• near.by
• app.goo.gl

Diese Netzwerkanfragen des Intent Filter Verification Service zur Überprüfung der Zuordnung von Apps zu Domains werden oft mit Netzwerkanfragen von Apps verwechselt. Dabei handelt es sich lediglich um HTTPS-GET-Anfragen ohne Identifizierungsinformationen (außer der IP-Adresse), die keinen Kommunikationskanal zu Apps/Diensten bieten. Der Intent Filter Verification Service stellt sicher, dass Apps bestimmte Aktionen ausführen können, wenn bspw. eine verknüpfte URL aufgerufen wird. Wird beispielsweise eine URL nach dem Muster https://play.google.com/* im Browser eingegeben/aufgerufen, wird die URL an die Play Store App übergeben und dort geöffnet.

Die Sandboxed Play Services öffnen nach der Installation die folgenden Verbindungen:

• www.googleapis.com
• android.googleapis.com
• infinitedata-pa.googleapis.com
• gmscompliance-pa.googleapis.com

Im laufenden Betrieb stellt das System regelmäßig Verbindungen zu Google her, um über diesen Kanal Push-Benachrichtigungen von Apps zu erhalten. Diese Kommunikation erfolgt über eine TCP-Verbindung mit der Gegenstelle mtalk.google.com (bspw. 173.194.76.188:5228), einem Server von Google.

Entscheidend zu wissen ist: Der wesentliche Vorteil der Google-Dienste mit Sandbox besteht darin, dass es sich um »normale« Apps handelt, für die keine (Standard-)Berechtigungen erforderlich sind. Im Gegensatz zu den herkömmlichen Google-Diensten auf Android-Geräten können die Sandboxed Play Services nicht auf Informationen wie Telefonnummer, SIM-Kartennummer, eindeutige Gerätenummer (IMEI), Standort etc. zugreifen und diese an Google übermitteln. Ihnen fehlen schlicht die Berechtigungen, um auf diese Informationen zuzugreifen:

GrapheneOS isoliert die Google-Dienste in einem Sandbox-Bereich, in dem sie agieren dürfen. Der Versuch, auf sensible Informationen zuzugreifen, wird durch die Sandbox verhindert. Die Play Services, die sich in der Sandbox befinden, übertragen daher keine sensiblen Informationen, da der Zugriff auf diese nicht erlaubt ist.

Beim Start der Google-Play-Store-App wird mit nachfolgenden Google-Servern Kontakt aufgenommen:

• play.googleapis.com
• firebaseinstallations.googleapis.com
• play.fe.googleapis.com
• safebrowsing.google.com
• connectivitycheck.gstatic.com

Aber auch hier gilt: Die Sandbox verhindert den Zugriff auf sensible Informationen.

Es ist jedoch wichtig zu bedenken, dass trotz der Sandbox und der Beschränkung auf einzelne Nutzerbereiche (Hauptprofil/Arbeitsprofil) ein gewisser Teil der Privatsphäre des grundsätzlich googlefreien Systems geopfert wird, insbesondere wenn der Play Store genutzt wird. Denn der Play Store erfordert eine Anmeldung mit einem Google-Konto. Wer also wirklich komplett auf Google verzichten möchte, sollte auf die Installation der Sandboxed Play Services verzichten oder diese zumindest in einem getrennten Arbeitsprofil installieren.

Wer auf die Sandboxed Play Services nicht verzichten möchte oder kann, sollte in den Einstellungen unter Apps -> Sandboxed Google Play -> Google Settings prüfen, ob der Datenfluss weiter eingeschränkt werden kann. So kann beispielsweise die Google Advertising-ID deaktiviert werden:

5. Tabelle mit Datenverbindungen

GrapheneOS hat Verbindungen, die vom System initiiert werden, vollständig dokumentiert. Die nachfolgende Tabelle fasst alle identifizierten Netzwerkverbindungen in einer Übersicht zusammen:

6. Zusätzliche Informationen zu/über das Custom-ROM

6.1 Entwickler | Institution

GrapheneOS wurde 2014 als Einzelprojekt von Daniel Micay gegründet. Das Projekt trug zeitweilig den Namen CopperheadOS, bis es 2018 wieder in GrapheneOS umbenannt wurde. Eine Chronik der Entwicklungen und der bewegten Vergangenheit des Projekts ist auf der GrapheneOS History Seite verfügbar.

Daniel Micay ist die Hauptfigur und treibende Kraft hinter GrapheneOS. Derzeit verfügt GrapheneOS über eine Gruppe von Vollzeit- und Teilzeit-Entwicklern, die durch Spenden und Kooperationen mit verschiedenen Unternehmen unterstützt/finanziert werden. Im Jahr 2023 wurde in Kanada die GrapheneOS-Foundation als gemeinnützige Organisation gegründet, um den Empfang und die Verteilung der Spenden zu koordinieren. Basierend auf den Erfahrungen mit CopperheadOS wird das Projekt in Zukunft bewusst darauf verzichten, sich eng an einen bestimmten Sponsor oder eine Firma zu binden.

GrapheneOS ist klar auf Sicherheit und Datenschutz ausgerichtet:

It’s focused on the research and development of privacy and security technology including substantial improvements to sandboxing, exploit mitigations and the permission model.

Die Feature-Seite bietet einen Überblick über die wichtigsten Datenschutz- und Sicherheitsverbesserungen, die GrapheneOS zum Android Open Source Project (AOSP) beigetragen hat. Hervorzuheben ist, dass GrapheneOS standardmäßig auf Google Apps oder Dienste vollständig verzichtet:

GrapheneOS will never include either Google Play services or another implementation of Google services like microG. It’s possible to install Play services as a set of fully sandboxed apps without special privileges via our sandboxed Google Play compatibility layer. See the FAQ section for more details on our plans for filling in the gaps from not shipping Play services and Google apps.

6.2 Installationsvorgang

GrapheneOS kann auf zwei Arten installiert werden: Entweder über die Kommandozeile oder über einen benutzerfreundlichen Web-Installer, der auch für Anfänger geeignet ist. Mit etwas Geduld und Zeit sollte die Installation von jedem durchführbar sein, der in der Lage ist, einer Anleitung Schritt für Schritt zu folgen. Sobald die Systemvoraussetzungen erfüllt sind, kann die Installation in wenigen Minuten abgeschlossen werden. Anfänger sollten sich nicht von den technischen Begriffen abschrecken lassen. Insbesondere mit dem Web-Installer ist die Installation beinahe ein Kinderspiel, bei dem nur noch der Easy-Installer von /e/ mithalten kann.

Im Auslieferungszustand enthält GrapheneOS nur wenige Apps, die speziell auf Datenschutz und Sicherheit ausgerichtet sind. Neben den Standard-Android-Apps für Telefonie und SMS gibt es den gehärteten Browser Vanadium, eine GrapheneOS Kamera-App und einen PDF-Viewer. Insgesamt halten sich die vorinstallierten Apps in Grenzen, was aber kein Nachteil ist – der Nutzer kann die benötigten Apps bei Bedarf selbst installieren.

6.3 Verfügbarkeit (Sicherheits-)Updates

Der wirksamste Schutz gegen bekannt gewordene oder geschlossene Schwachstellen ist das Einspielen von (Sicherheits-)Updates. Google stellt mittlerweile monatliche Sicherheitsupdates zur Verfügung, die traditionell um den 5. eines Monats veröffentlicht werden. Leider stehen viele Nutzer vor einem Dilemma: Einige Smartphone-Hersteller schaffen es oft nicht, Updates für ihre herstellerspezifischen Android-Versionen zeitnah bereitzustellen oder unterstützen ältere Geräte aus Kostengründen einfach nicht mehr. Dadurch entsteht zwangsläufig ein »Vakuum« in der Android-Welt, das viele Geräte anfällig für kritische Sicherheitslücken macht.

Für GrapheneOS sieht das Verfahren wie folgt aus: Sobald Google die monatlichen Sicherheitsupdates veröffentlicht, wird noch am selben oder spätestens am nächsten Tag ein Update für alle unterstützten Geräte von GrapheneOS bereitgestellt. Die Reaktionszeit könnte nicht besser sein, das schafft in der Regel kein anderes Custom-ROM. Selbst Hersteller wie Samsung benötigen für ihre Top-Geräte mehr Zeit, bis neue Updates verfügbar sind.

Ähnlich schnell ist die Reaktionszeit bei der WebView-Komponente bzw. bei (Chromium-)Updates für Vanadium. Updates sind noch am selben Tag oder spätestens am Folgetag verfügbar. Der Umgang mit (Sicherheits-)Updates unterstreicht nochmals die hohe Sicherheitsorientierung des Projekts und zeigt, dass GrapheneOS äußerst bemüht ist, zeitnah auf potenzielle Sicherheitsbedrohungen zu reagieren und seinen Nutzern stets aktuelle Schutzmaßnahmen zu bieten.

6.4 Alternative zu Google Play-Diensten

In der Privacy-Szene haben die Google Play-Dienste nicht umsonst den Ruf einer Überwachungswanze. Im Beitrag »Google Play Services: Die Überwachungswanze von Google« wird aufgezeigt, welche Daten Google von einem Gerät erhebt – und das, obwohl praktisch alle Einstellungen möglichst datenschutzfreundlich konfiguriert sind.

Standardmäßig verzichtet GrapheneOS auf jegliche Google Apps oder Dienste. Als Nutzer hat man allerdings die Möglichkeit, Sandboxed Play Services zu installieren. Dabei handelt es sich um eine Variante der Google Play-Dienste, die in einer abgeschotteten Umgebung (Sandbox) ausgeführt wird, ohne den vollen Systemzugriff zu gewähren, den die herkömmlichen Google-Dienste normalerweise haben. Es ist von entscheidender Bedeutung zu verstehen, dass der zentrale Vorteil der Google-Dienste mit Sandbox darin liegt, dass es sich um »normale« Apps handelt, für die keine (Standard-)Berechtigungen erforderlich sind. Im Gegensatz zu den herkömmlichen Google-Diensten auf Android-Geräten haben Play-Dienste, die in einer Sandbox ausgeführten werden, keinen Zugriff auf sensible Informationen wie Telefonnummer, SIM-Kartennummer, eindeutige Gerätenummer (IMEI), Standort etc. Sie verfügen einfach nicht über die erforderlichen Berechtigungen, um auf diese Daten zuzugreifen und sie an Google zu übermitteln.

Ausführlichere Informationen zu den Sandboxed Play Services, einschließlich Informationen zur Kompatibilität, sind im Benutzerhandbuch enthalten:

Sandboxed Google Play is close to being fully functional and provides near complete compatibility with the app ecosystem depending on Google Play. Only a small subset of privileged functionality which we haven’t yet ported to different approaches with our compatibility layer is unavailable. Some functionality is inherently privileged and can’t be provided as part of the compatibility layer.

6.5 Sicherheit/Datenschutz

GrapheneOS unterstützt Verified Boot für alle Geräte. Damit soll sichergestellt werden, dass der gesamte ausgeführte Code aus einer vertrauenswürdigen Quelle stammt und nicht von einem Angreifer manipuliert wurde. Damit sollen unter anderem Evil-Maid-Angriffe erkannt werden, bei denen ein Angreifer Zugriff auf das Gerät hat. Bei einem Gerät, das bspw. einen offenen Bootloader (unlocked) hat und/oder auf das zusätzlich ein Recovery Image aufgespielt wurde, ist es für einen versierten Angreifer möglich, Veränderungen vorzunehmen, die der Nutzer im Nachhinein nicht erkennt. Denn die Verschlüsselung des Android-Gerätes, die auch beim Booten in das Recovery abgefragt wird, schützt nur die Nutzerdaten. Ein Angreifer kann aber weiterhin über die ADB (Android Debug Bridge) auf die Systempartition zugreifen und dort Veränderungen vornehmen. Auch eine Veränderung des Bootloaders ist denkbar. Zwar ist das Risiko eher gering, aber die Möglichkeit besteht. GrapheneOS bootet nur, wenn keine (manipulativen) Änderungen durch Dritte am Bootloader, System, Vendor-Dateien etc. festgestellt wurden. Dies ist auch der Grund, warum der Bootloader nach der Installation von GrapheneOS wieder geschlossen werden sollte.

Zusätzlich zu den herkömmlichen Sicherheitsfunktionen von Android bietet GrapheneOS eine ganze Reihe von weiteren Verbesserungen. Die Anzahl der Verbesserungen und Änderungen ist umfangreich – äußerst umfangreich. Nachfolgend ein Auszug:

• Schutz vor bisher unbekannten Sicherheitslücken (Zero-Day-Schwachstellen): Mehrere Verteidigungslinien reduzieren die Angriffsfläche. Unter anderem verzichtet GrapheneOS auf unnötigen Code, setzt auf Programmiersprachen und gehärtete Bibliotheken, die das Risiko von Buffer Overflows und ähnlichen Angriffen reduzieren, und implementiert (verbessertes) Sandboxing auf verschiedenen Ebenen. Diese Maßnahmen sollen es Angreifern erschweren, Schadcode auszuführen oder überhaupt zu entwickeln.
• Umfassenderes Patching: Es mag überraschen, aber GrapheneOS behebt eine beträchtliche Anzahl von Sicherheitslücken, die in Android noch nicht behoben wurden. Zum Beispiel verwendet GrapheneOS einen neueren Linux-Kernel, der viele Sicherheitspatches enthält, die bislang nicht im Standard-Betriebssystem enthalten sind.
• Netzwerkberechtigung: GrapheneOS verfügt über einen Schalter für Netzwerkberechtigungen, der sowohl den direkten als auch den indirekten Zugriff auf verfügbare Netzwerke verhindert. Diese Berechtigung schützt auch das geräteeigene Netzwerk (localhost), um sicherzustellen, dass Anwendungen es nicht für die Kommunikation zwischen Profilen verwenden. Einfach ausgedrückt kann der Schalter einer App den Zugang zum Internet/Netzwerk erlauben oder verbieten.
• Feingranulare Kontaktbeschränkung: Im klassischen Berechtigungsmodell von Android können Berechtigungen entweder gewährt oder verweigert werden, wobei eine feingranulare Vergabe von Berechtigungen nicht möglich ist. Im Gegensatz dazu verfolgt GrapheneOS einen anderen Ansatz. Hier gibt es bspw. den Storage- oder Contact-Scope. Mit dem Contact-Scope kann für jede App individuell festgelegt werden, auf welche Kontakte oder Kontaktgruppen die App zugreifen darf.
• Verringerung der Tracking-Möglichkeiten: GrapheneOS sperrt aktiv den Zugriff auf Hardware-IDs oder entfernt diese, um zu verhindern, dass Apps diese zum Tracking und Verfolgen von Nutzern verwenden. Dieser proaktive Ansatz verstärkt die Datenschutzmaßnahmen und trägt dazu bei, die Privatsphäre der Nutzer effektiv zu schützen.
• Privacy by default: Privacy by default ist ein etabliertes Paradigma, das die Grundphilosophie vertritt, den Datenschutz von Anfang an zu integrieren und standardmäßig zu gewährleisten. Es konzentriert sich darauf, sicherzustellen, dass Datenschutzmaßnahmen von Anfang an in den Entwurf und die Implementierung von Systemen, Anwendungen und Diensten einbezogen werden. Dadurch wird sichergestellt, dass die Privatsphäre der Nutzer als grundlegendes Prinzip respektiert und geschützt wird. Im Gegensatz zu vielen Projekten, die sich fälschlicherweise mit dem Titel »Privacy by default« schmücken, wird dieses Prinzip bei GrapheneOS tatsächlich umgesetzt. GrapheneOS enthält standardmäßig keine Google-Apps und -Dienste und verzichtet bewusst auf die Integration anderer Apps oder Dienste, die mit der klaren Ausrichtung des Projekts auf Datenschutz und Sicherheit nicht vereinbar sind.
• Indikator für Zugriff auf Standortdaten: GrapheneOS verfügt über eine Datenschutzanzeige für den Zugriff auf Standortdaten, die zusätzlich zu den Standardanzeigen für Kamera und Mikrofon aktiv ist. Diese Anzeige informiert den Nutzer, wenn eine App, für die Standortdaten freigegeben wurden, auf diese Daten zugreift.

7. Fazit

GrapheneOS setzt Standards in puncto Sicherheit und Datenschutz, die von keinem anderen Android-System erreicht werden. Dennoch ist das System nicht ausschließlich für Sicherheits- und Datenschutz-Freaks konzipiert. Es bietet eine Alternative für alle, die mehr Kontrolle über ihre Daten haben und sich aus der Abhängigkeit von Google befreien wollen. Sollten einige Apps dennoch auf die Google Play-Dienste angewiesen sein, können diese einfach zusammen mit den Sandboxed Play Services im Arbeitsprofil installiert werden. Das ist vielleicht nicht die optimale Lösung, aber immerhin ein wesentlicher Unterschied zu herkömmlichen Android-Systemen, bei denen die Nutzer permanent überwacht werden.

Es besteht kein Zweifel, dass GrapheneOS derzeit das sicherste und datenschutzfreundlichste Custom-ROM bzw. Android-System ist. Das Sahnehäubchen wäre es, wenn der Zwang, ein Google-Gerät zu verwenden, aufgehoben würde und GrapheneOS an den Plänen festhielte, eigene Geräte auf den Markt zu bringen. Das ist eigentlich der einzige Punkt, an dem ich etwas zu kritisieren hätte – Jammern auf hohem Niveau.

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡

Ähnliche Beiträge

10. September 2023

Klimaschutz mit Datenschutz? Der große Elektroauto-Ladeapp-Test

Manche Ladeapps sind eine Datenschutzkatastrophe. Wir haben 41 Apps getestet und geben Tipps für datensparsames Laden.

10. Februar 2023

CalyxOS: De-Googled geht anders – Custom-ROMs Teil2

Die Analyse des Datensendeverhaltens zeigt: CalyxOS ist leider nicht so de-googled, wie man vermuten würde.

6. April 2023

iodéOS: Datenschutzfreundlich, aber Abstriche bei der Sicherheit – Custom-ROMs Teil3

iodéOS entgoogelt Android weitgehend, jedoch nicht vollständig. Die Zielgruppe: Datenschutzsensible Nutzer, die ältere Geräte weiter nutzen möchten.

5. Dezember 2023

/e/: Datenschutzfreundlich bedeutet nicht zwangsläufig sicher – Custom-ROMs Teil6

/e/ punktet beim Datenschutz, aber hinsichtlich der Sicherheit bestehen erhebliche Bedenken.

1. Juni 2023

DivestOS: Datenschutzfreundlich und erhöhte Sicherheit – Custom-ROMs Teil5

DivestOS stellt Datenschutz und Sicherheit als grundlegende Prinzipien in den Vordergrund: Man kann berechtigterweise sagen: Take back (some) control!

Weitere Themen

AndroidAuditAutonomieBackupBezahlenBrowserCloudDatenschutzDatensendeverhaltenDigitalpolitikDSGVOE-MailFirewallHackingHärteniOSKuketz-BlogLinuxmacOSMessengerOpenWrtPasswortPentestRaspberryPiRechtSicherheitslückeSicherheitsmaßnahmeTorTrackingTTDSGÜberwachungVerschlüsselungWindowsWordPressXMPP

---

Diskussion

Ich freue mich auf Deine Beteiligung zum Artikel

Wenn du Ergänzungen oder konkrete Fragen zum Beitrag hast, besuche das offizielle Forum. Dort kann der Beitrag diskutiert werden. Oder besuche den Chat, um dein Anliegen zu besprechen. zur Diskussion ➡

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.