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

1. Auf dem PrüfstandCalyxOS

In der Artikelserie »Custom-ROMs« möchte ich einige alternative Android-Systeme näher beleuchten. Der Schwerpunkt wird in der Analyse des Datensendeverhaltens liegen. Es wird geprüft, 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 Tipps ableiten, wie sich das »Nach-Hause-Telefonieren« einschränken oder sogar vollständig abschalten lässt.

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

CalyxOS is an Android mobile operating system that puts privacy and security into the hands of everyday users. Plus, proactive security recommendations and automatic updates take the guesswork out of keeping your personal data personal.

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

Dieser Beitrag ist Teil einer Artikelserie:

2. CalyxOS

Das Android-basierte System CalyxOS ist seit dem Jahr 2020 verfügbar und unterstützt die Pixel Geräte-Reihe von Google – und daneben noch das Fairphone 4. Im Gegensatz zu den Pixel-Geräten werden die Updates, die die proprietären Komponenten wie den Bootloader, Firmware etc. betreffen, allerdings verzögert ausgeliefert. Wer also tatsächlich Wert auf möglichst zeitnahe Updates (aller Komponenten) legt, der wird nicht um Pixel-Geräte umhinkommen.

Sowohl die Installation als auch die initiale Inbetriebnahme ist relativ einfach gestaltet, um möglichst vielen Nutzern den Umstieg auf das System zu ermöglichen. Als Nutzer hat man die Wahl auf Google-Play-Dienste zu verzichten oder diese durch die quelloffene Alternative microG zu ersetzen. Allerdings bedeutet der Verzicht auf die Google-Play-Dienste nicht automatisch, jegliche Brücken zu Google abgerissen zu haben. Wie die nachfolgende Analyse zeigt, verwendet das System weiterhin einige Google-Dienste im Betrieb. Als Nutzer kann man nicht jedem dieser Dienste »entkommen«, aber zumindest eine Verringerung erreichen.

Der User Guide von CalyxOS ist relativ umfangreich und beantwortet viele Fragen. Ein Teil der Dokumentation widmet sich der Network Activity, bei der tabellarisch dargestellt ist, wohin (Server/Gegenstelle) und zu welchem Zweck das System Verbindungen aufbaut. Zitat aus der Dokumentation:

With CalyxOS, we have tried to reduce to as much as possible the number of network connections made by your phone. On this page, we document what domains your phone is connecting to and for what purpose.

Leider ist die Seite unvollständig. Während meiner Analyse habe ich weitere Verbindungen identifiziert, die nicht dokumentiert wurden. Da sollte das CalyxOS-Projekt unbedingt nachbessern.

Tschüß Überwachungswanze

Der Verzicht auf die Google-Play-Dienste geht übrigens mit einer erheblichen Steigerung der Privatsphäre einher. Im Beitrag »Google Play Services: Die Überwachungswanze von Google« ist aufgezeigt, welche Daten Google von einem Gerät erhebt – und das, obwohl praktisch alle Einstellungen möglichst datenschutzfreundlich konfiguriert wurden.

Unterstütze den Blog mit einem Dauerauftrag!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

2.1 Verwendetes Setup

Während der initialen Einrichtung von CalyxOS können zusätzliche Apps wie der Aurora Store, DAVx⁵ oder K-9 Mail gleich mitinstalliert werden. Im Testsetup verzichte ich auf die zusätzliche Installation von Apps, da dies nicht im Fokus steht. Weiterhin besteht die Möglichkeit, die Google-Play-Dienste-Alternative microG zu installieren:

microG

In meinem Testsetup wird microG einmal nicht aktiviert und nach einem Reset des Geräts dann aktiviert. Es werden also beide Szenarien beleuchtet: microG installiert bzw. nicht installiert.

Während der mehrwöchigen Testphase kamen folgende CalyxOS-Versionen zum Einsatz:

  • Google Pixel 6a (bluejay): CalyxOS 4.4.1
  • Google Pixel 6a (bluejay): CalyxOS 4.5.1

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 gestellt. 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 System-Umgebung, als auch die (Netzwerk-)Tools, mit denen die Datenmitschnitte erfolgen, sind im ersten Teil der Artikelserie beschrieben. Nachfolgend werden unterschiedliche (Anwendungs-)Szenarien beleuchtet. Was passiert bspw. beim Geräte-Start? Welche Verbindungen werden bei der Aktivierung der GPS-Schnittstelle initiiert? Und welche Daten übermittelt der Standard-Browser nach dem Aufruf?

Das Kommunikationsverhalten unterscheidet sich, sofern sich der Nutzer bei der Inbetriebnahme für die Installation von microG entscheidet. Nachfolgend wird dies mit dem Zusatz [mit microG] in der Überschrift unterschieden.

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:

  • www.google.com
  • time.android.com
  • connectivitycheck.gstatic.com

Nach der Auflösung der Domainnamen in die zugehörige IP-Adresse startet das System eine Aktualisierung der (Netzwerk-)Zeit via NTP zum Server time.android.com. 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 Android eine Anfrage an die Adresse connectivitycheck.gstatic.com. Die Überprüfung der Konnektivität erfolgt durch folgende GET-Anfrage:

GET http://connectivitycheck.gstatic.com/generate_204

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.gstatic.com
Connection: Close
Accept-Encoding: gzip
Content-Length: 0

Als Antwort erfolgt dann ein 204er-Statuscode:

Response Version: HTTP/1.1
Status Code: 204
Connection: Close
Content-Length: 0

Die dritte Verbindung erfolgt dann zu www.google.com und ist eine Art Fallback, wenn die unverschlüsselte HTTP-Verbindung zu connectivitycheck.gstatic.com fehlschlägt. Während der Tests erfolgte die Verbindung zu www.google.com jedes Mal, sobald der Captive-Portal-Check durchgeführt wurde.

Weshalb das System Captive-Portal-Checks bei Google-Servern durchführt, begründet CalyxOS wie folgt:

We have considered replacing Google servers for updating the system time and for connectivity check but decided against it. Our position is that using Google servers provides better privacy in this situation by allowing CalyxOS users to hide among the crowd of every other Android device on earth. Imagine if every CalyxOS device was using non-standard servers for these core functions. If we did this, it would be trivially easy for a repressive state to instantly identify all the people running CalyxOS devices and potentially target them for scrutiny.

Wenn wir das Argument »repressive Staaten« mal außen vor lassen, gibt es aus meiner Sicht keinen Grund, weiterhin die Google-Server für einen Captive-Portal-Check zu nutzen. Leider gibt es in CalyxOS nur die Option an oder aus. Ein alternativer Captive-Portal-Check-Server wird nicht angeboten.

Datenminimierung

Sobald das Häkchen unter »Einstellungen -> Netzwerk & Internet -> Verbindungsprüfung« entfernt ist, nimmt CalyxOS keine Verbindungen mehr zu »www.google.com« bzw. »connectivitycheck.gstatic.com« auf. Die Entfernung des Häkchens bedeutet allerdings auch, dass Captive-Portals dann nicht (immer) zuverlässig erkannt werden können. Man muss den Captive-Portal-Check allerdings nicht vollständig deaktivieren. Über die URL captiveportal.kuketz.de biete ich ebenfalls einen solchen Dienst an – weitere Details in der Empfehlungsecke.

3.2 Nach Anmeldung am System

Nachdem eine Anmeldung/Authentifizierung am System erfolgt, wird eine Verbindung zum Google-Server remoteprovisioning.googleapis.com initiiert:

POST https://remoteprovisioning.googleapis.com/v1:fetchEekChain

Content-Type: application/x-www-form-urlencoded
User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.221205.011)
Host: remoteprovisioning.googleapis.com
Connection: Keep-Alive
Accept-Encoding: gzip
Content-Length: 90

\xa2bid\x1a\x00\x03Z~kfingerprintxCgoogle/bluejay/bluejay:13/TQ1A.221205.011/9244662:user/release-keys

Android-Geräte, die mit Android 8 oder später auf den Markt kommen, bieten Unterstützung für die hardwarebasierte Beglaubigung als Teil der Hardware-Keystore-API – Remote Provisioning genannt. Jedes Gerät generiert ein eindeutiges, statisches Schlüsselpaar. Der öffentliche Teil dieses Schlüsselpaars wird vom Hersteller direkt bei der Produktion/Herstellung an die Google-Server übermittelt. Dort dienen sie später als Vertrauensbasis für die Bereitstellung. Der private Schlüssel verlässt niemals die sichere Umgebung, in der er erzeugt wurde.

Wenn ein Gerät zum ersten Mal Verbindung zum Internet herstellt, erzeugt es eine Zertifikatsanforderung für die von ihm erzeugten Schlüssel und signiert sie mit dem privaten Schlüssel, der dem bei der Herstellung (öffentlicher Schlüssel) entspricht. Die Backend-Server von Google überprüfen die Authentizität der Anfrage und signieren dann die öffentlichen Schlüssel, wobei die Zertifikatsketten bzw. eine Beglaubigung zurückgegeben werden. Der Schlüsselspeicher auf dem Gerät speichert dann diese Zertifikatsketten und weist sie den Anwendungen zu, wenn eine Bestätigung/Bescheinigung angefordert wird. Diese Bestätigung des Schlüssels ist bspw. eine Voraussetzung für Dienste wie SafetyNet.

Diese Zertifikatsketten werden regelmäßig angefordert – bspw. nach einem Neustart oder wenn die Zertifikate abgelaufen sind. Obwohl regelmäßig eine Verbindung zu remoteprovisioning.googleapis.com erfolgt, ist dies in der CalxyOS-Dokumentation nicht vermerkt.

3.3 Geräte-Updates

CalyxOS prüft regelmäßig (bspw. nach einem Geräte-Neustart), ob neue System-Updates zur Verfügung stehen. Der Update-Check erfolgt über die Adresse release.calyxinstitute.org:

GET https://release.calyxinstitute.org/bluejay-stable4

User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.221205.011)
Host: release.calyxinstitute.org
Connection: Keep-Alive
Accept-Encoding: gzip

Als Antwort erfolgt dann (bereinigte Kurzform):

22405000 1672865259 TQ1A.230105.001.A2

Darin sind alle Informationen des neuen Builds bzw. inkrementellen Updates enthalten: TQ1A.230105.001.22405000 (Version 4.5.0). Die aktuell installierte Version trägt (natürlich) eine andere Build-Number: TQ1A.221205.011.22404010 (Version 4.4.1).

Als Nächstes wird der Changelog abgefragt:

GET https://release.calyxinstitute.org/bluejay-stable4-changelog.html

User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.221205.011)
Host: release.calyxinstitute.org
Connection: Keep-Alive
Accept-Encoding: gzip

Die Antwort (bereinigt) sieht dann wie folgt aus:

CalyxOS 4.5.0

January 2023 Security update

Features and bug fixes

  • Potential fix for unresponsive screen / shutdown
  • Calendar (Etar): Latest upstream version 1.0.33, contains bugfixes
  • Work profile: Make new work profile creation faster.

Sofern ein Update bereitsteht, wird der Download initiiert:

GET https://release.calyxinstitute.org/bluejay-incremental-22404010-22405000.zip

Range: bytes=0-
User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.221205.011)
Host: release.calyxinstitute.org
Connection: Keep-Alive
Accept-Encoding: gzip

Die Prüfung, das Herunterladen und die Installation der Updates erfolgt also automatisch bzw. Over-The-Air (OTA). Sobald ein Neustart ausgeführt wurde, befindet sich das Gerät auf dem neuesten Stand.

4. Datensendeverhalten: Im Betrieb

4.1 24 Stunden Mitschnitt

Innerhalb einer 24-Stunden-Zeitspanne ist das System relativ ruhig – eine Benutzung des Smartphones findet nicht statt, sondern es wird hierbei lediglich geprüft, welche Verbindungen das (Standard-)System binnen 24-Stunden initiiert. Neben Updates-Checks (release.calyxinstitute.org) wurde zweimal versucht, die (Netzwerk-)Zeit via NTP zu aktualisieren. Abgesehen davon, wurden keine weiteren Verbindungen vom System initiiert. Das ändert sich natürlich dann, wenn der Nutzer weitere Apps installiert und diese bspw. mittels Polling/Push Daten abfragen bzw. erhalten.

4.2 24 Stunden Mitschnitt [mit microG]

Sofern der Nutzer microG installiert, ist das System gleich etwas gesprächiger – was natürlich nicht ungewöhnlich ist, denn microG ist eine (nicht vollständige) Nachbildung der Google-Play-Dienste. Im Gegensatz zu den Google-Play-Diensten verfolgt microG die Nutzeraktivitäten auf dem Gerät zumindest nicht. Weiterhin können Nutzer teilweise selbst bestimmen, welche API-Funktionen (Google Cloud Messaging, SafetyNet, das Exposure Notification Framework) sie nutzen möchten.

In der Standardkonfiguration von microG nimmt das System regelmäßig Kontakt zu Google auf, um über diesen Kanal Push-Notifications (von Apps) zu empfangen. Das erfolgt über eine TCP-Verbindung zur Gegenstelle mtalk.google.com (74.125.206.188:5228) – einem Server von Google. Eine solche Verbindung sieht ausgehend (zu Google) wie folgt aus:

\x02\x8d\x01

android-33\x12\x0fmcs.android.com\x1a\x133877793905634447622"\x133877793905634447622*\x1331828487379034433532\x18android-35d0b10301841106B\x0b
\x06new_vc\x12\x011`\x00p\x01\x80\x01\x02\x88\x01\x01

Eingehend (von Google) dann folgendermaßen:

\x036

android-33\x12\x1fuser@firebase.com/notifications0\x01@\xa3\xdf\x81\x99\xde0\x07
\x10\x01\x1a\x00:\x04\x08\x0c\x12\x00

Auch wenn noch keine Apps für den Erhalt von Push-Notifications registriert sind, erfolgt eine dauerhafte Aktualisierung der Verbindung zu mtalk.google.com.

4.3 Aktivierung Netzwerkschnittstelle

Bereits während des Boot-Vorgangs wird ein Captive-Portal-Check durchgeführt, sofern ein Netzwerkinterface (WiFi, Mobile) aktiv ist. Wird das Gerät in der Zwischenzeit in den Flugmodus versetzt und danach wieder eine Netzwerkschnittstelle aktiviert, wird erneut ein Captive-Portal-Check initiiert. Das bedeutet erneut ein Verbindungsaufbau zu connectivitycheck.gstatic.com bzw. www.google.com. Was dabei auffällt: Beide Verbindungen werden nicht durch das VPN getunnelt, sondern werden einfach daran vorbeigeführt. Das hat mich stutzig gemacht, denn selbst wenn bei der VPN-Verbindung die Option Verbindungen ohne VPN blockieren aktiv ist, wird der Captive-Portal-Check einfach am VPN vorbeigetunnelt. Android leakt also Traffic, was nicht nur die VPN-Option infrage stellt, sondern ein echtes Problem hinsichtlich der Privatsphäre sein kann. Wenn einfach Daten an einem VPN-Tunnel vorbeigeschleust werden können, dann ist die Implementierung fragwürdig.

Das Problem scheint übrigens nicht neu zu sein. Mullvad VPN hatte darüber bereits im Oktober 2022 berichtet: Android leaks connectivity check traffic. Offenbar wird Google an diesem Verhalten allerdings nichts ändern. Ein dazu eingereichtes Issue hat den Status »Won’t Fix« (Intended Behavior). Begründet wird das wie folgt:

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.

Ich zitiere mal eine entscheidende Stelle:

We do not think such an option would be understandable by most users, […]

Einverstanden. Aber wenn jemand aktiv die Option Verbindungen ohne VPN blockieren aktiviert, dann erwartet er genau das – mit all seinen Konsequenzen. So sehe ich das jedenfalls. Die Connectivity-Checks am VPN vorbei sind technisch zwar nachvollziehbar, aber dann sollte das verständlicher erklärt werden. Das Setzen der Option Verbindungen ohne VPN blockieren ist in meinen Augen irreführend. Dazu kommt ja auch noch:

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.

Merke: Man kann sich nie sicher sein, welche System-Apps bzw. Datenverbindungen am VPN vorbeigeschleust werden.

Datenminimierung

Sobald das Häkchen unter »Einstellungen -> Netzwerk & Internet -> Verbindungsprüfung« entfernt ist, nimmt CalyxOS keine Verbindungen mehr zu »www.google.com« bzw. »connectivitycheck.gstatic.com« auf. Die Entfernung des Häkchens bedeutet allerdings auch, dass Captive-Portals dann nicht (immer) zuverlässig erkannt werden können. Man muss den Captive-Portal-Check allerdings nicht vollständig deaktivieren. Über die URL captiveportal.kuketz.de biete ich ebenfalls einen solchen Dienst an – weitere Details in der Empfehlungsecke.

4.4 Browser: Chromium

Der mitgelieferte Browser ist der Chromium-Fork Bromite, der bereits einen Werbe- bzw. Trackingblocker integriert hat. In der Serie »Browser-Check« schnitt der Browser insgesamt gut ab. Abgesehen von der Aktualisierung der Filterlisten initiiert der Browser beim Start keine weiteren Verbindungen – abgesehen vom Nachladen der Favicons für die mitgelieferten Favoriten/Lesezeichen. Als Standardsuchmaschine ist DuckDuckGo eingestellt. Über Einstellungen -> Suchmaschinen lässt sich dies anpassen.

Anbei der Verbindungsaufbau zu www.bromite.org, um von dort die aktuelle Filterliste zu beziehen:

GET https://www.bromite.org/filters/filters.dat

pragma: no-cache
cache-control: no-cache
sec-fetch-site: none
sec-fetch-mode: no-cors
sec-fetch-dest: empty
user-agent: Mozilla/5.0 (Linux; Android 13; SAMSUNG SM-G960U) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Mobile Safari/537.36
accept-encoding: gzip, deflate, br

Insgesamt weist der Browser ein unauffälliges Datensendeverhalten auf.

4.5 (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 CalyxOS wird hierbei die Gegenstelle supl.google.com über Port 7275 kontaktiert. Anbei der gekürzte Datenmitschnitt:

Internet Protocol Version 4, Src: 10.215.173.1, Dst: 142.251.31.192
Transmission Control Protocol, Src Port: 51516, Dst Port: 7275, Seq: 1, Ack: 1, Len: 71

[...]

OMA UserPlane Location Protocol
    ULP-PDU
        length: 71
        version
            maj: 2
            min: 0
            servind: 0
        sessionID
            setSessionID
                sessionId: 4
                setId: imsi (3)
                    imsi: 62022207547xxxxx
                        IMSI: 26202xxxxxxxxxx
                        [Association IMSI: 26202xxxxxxxxxx]
                            Mobile Country Code (MCC): Germany (262)
                            Mobile Network Code (MNC): Vodafone GmbH (02)
        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: 11904140 [bit length 28, 4 LSB pad bits, 0001 0001  1001 0000  0100 0001  0100 .... decimal value 18416660]
                                physCellId: 280
                                trackingAreaCode: b876 [bit length 16, 1011 1000  0111 0110 decimal value 47222]
                    status: current (1)
                qoP
                    horacc: 51,159090m (19)
                    maxLocAge: 1s

Problematisch dabei ist allerdings, dass bei der Anfrage auch die personenbeziehbare IMSI-Nummer an den SUPL-Server übermittelt wird – was technisch gesehen eigentlich nicht notwendig wäre. Die Kombination der IMSI-Nummer mit den Funkzellen-IDs ermöglicht dem Betreiber eines SUPL-Servers, die relativ genaue Lokalisierung eines Nutzers, sobald das Smartphone eine SUPL-Anfrage initiiert. Das SUPL-Protokoll ist also eigentlich relativ sinnvoll, nur ist fraglich, weshalb hierbei die IMSI-Nummer übermittelt wird – und dann ausgerechnet noch an Google.

Update 05.04.2023

CalyxOS hat in der Version 4.7.0 jüngst im Changelog vermerkt: »Remove sensitive info from SUPL requests«. Damit dürfte die Standortbestimmung via SUPL nun etwas datenschutzfreundlicher sein.

Im obigen Datenmitschnitt habe ich die IMSI-Nummer übrigens weitestgehend unkenntlich gemacht. Die 15 Ziffern einer IMSI-Nummer setzen sich wie folgt zusammen:

  • Mobile Country Code (MCC): 262 für Deutschland
  • Mobile Network Code (MNC): 02 für Vodafone
  • gefolgt von der 10-stelligen Mobile Subscriber Identification Number (MSIN): xxxxxxxxxx

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"

Datenminimierung

Über »Einstellungen -> Netzwerk & Internet -> SIM-Karten -> Zugangspunkte (APNs) -> [aktuell verwendeter APN] -> APN-Typ« lässt sich das Verhalten beeinflussen. Zumindest theoretisch – denn unter CalyxOS ist es mir nicht gelungen, die APN-Einstellungen anzupassen. Entfernt man unter APN-Typ den Wert supl, wird kein SUPL-Server zur schnelleren Standortbestimmung kontaktiert. Die Standortbestimmung erfolgt dann ausschließlich über die GNSS-Schnittstelle, was die Ortungszeit allerdings erheblich verlängert.

Zur Beschleunigung der Standortbestimmung nutzt CalyxOS 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 CalyxOS von der Gegenstelle »gllto.glpals.com« (Broadcom):

  • https://gllto.glpals.com/rto/v1/latest/rto.dat
  • https://gllto.glpals.com/7day/v5/latest/lto2.dat
  • https://gllto.glpals.com/rtistatus4.dat

Außer der IP-Adresse werden bei der Abfrage der sogenannten Almanache keine Informationen übermittelt. Es handelt sich um einfache GET-Anfrage, ohne Parameter. Nachfolgend eine dieser Abfragen:

GET https://gllto.glpals.com/rto/v1/latest/rto.dat

Accept:           */*, application/vnd.wap.mms-message, application/vnd.wap.sic                                                                                                                                 
x-wap-profile:    http://www.openmobilealliance.org/tech/profiles/UAPROF/ccppschema-20021212#                                                                                                                   
User-Agent:       Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.221205.011)                                                                                                                        
Host:             gllto.glpals.com                                                                                                                                                                                    
Connection:       Keep-Alive                                                                                                                                                                                    
Accept-Encoding:  gzip

Im Gegensatz zu CalyxOS, das die Standardserver von Broadcom verwendet, betreibt GrapheneOS seine eigenen Server, auf denen es die Almanache bereitstellt. Dies verringert die Abhängigkeit von Google:

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

4.5 (GPS-)Standort [mit microG]

Auch bei der microG-Variante erfolgt zur Beschleunigung der Standortbestimmung eine SUPL-Anfrage an supl.google.com – es wird ebenfalls die IMSI-Nummer an Google übermittelt. Zusätzlich erfolgt die Positionsbestimmung mittels Mozilla Location Service:

The Mozilla Location Service (MLS) is an open service, which lets devices determine their location based on network infrastructure like Bluetooth beacons, cell towers and WiFi access points. This network based location service complements satellite based navigation systems like A-GPS.

Eine solche Anfrage zur Standortbestimmung wird an die Gegenstelle location.services.mozilla.com übermittelt (gekürzte Darstellung):

POST /v1/geolocate?key=068ab754-c06b-473d-a1e5-60e7b1a2eb77 HTTP/1.1

Content-Type: application/x-www-form-urlencoded
User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6a Build/TQ1A.221205.011)
Host: location.services.mozilla.com
Connection: close
Accept-Encoding: gzip, deflate
Content-Length: 1613

{

   "radioType":"lte",
   "cellTowers":[
      {
         "radioType":"lte",
         "mobileCountryCode":262,
         "mobileNetworkCode":2,
         "locationAreaCode":47222,
         "cellId":18416649,
         "signalStrength":-102,
         "psc":176,
         "asu":38
      }
   ],
   "wifiAccessPoints":[
      {
         "macAddress":"f0:af:85:2a:c3:d3",
         "channel":6,
         "frequency":2437,
         "signalStrength":-87
      },
      {
         "macAddress":"54:fa:3e:ae:fe:17",
         "channel":13,
         "frequency":2472,
         "signalStrength":-60
      }

[15 weiter WiFis]

      }
   ],
   "fallbacks":{
      "lacf":true,
      "ipf":false
   }
}

Neben Informationen zum aktiven/verbundenen Mobilfunkmast werden Informationen von allen umliegenden bzw. in der Empfangsreichsweite des Smartphones befindlichen WiFi-Netzwerkinformationen ausgelesen und übermittelt. Dazu zählt bspw. die MAC-Adresse der Router, der Sendekanal und ebenfalls die Signalstärke.

Auf die Standortbestimmung mittels Assisted GPS (abgekürzt als A-GPS) hat man als Nutzer wie bereits dargestellt keinen Einfluss. Auf die Standortbestimmung über microG bzw. die integrierten Location-Module schon:

Location Modules

4.6 Initialisierung microG [mit microG]

Bei der erstmaligen Initialisierung von microG und ebenfalls in vordefinierten Zuständen (bspw. nach jedem Neustart) nimmt microG eine Verbindung zu Google bzw. der Gegenstelle android.clients.google.com auf. Bei dieser Verbindung wird das Gerät zur Nutzung von Google-Diensten vorbereitet. Das sieht im Detail wie folgt aus:

POST https://android.clients.google.com/checkin

Content-type: application/x-protobuffer
Content-Encoding: gzip
Accept-Encoding: gzip
User-Agent: Android-Checkin/2.0 (vbox86p JLS36G); gzip
Host: android.clients.google.com
Connection: Keep-Alive
Content-Length: 3667

[uint32] 2 0
[string] 3 1-929a0dca0eee55513280171a8585da7dcd3700f8
[message] 4
[message] 4.1
[string] 4.1.1 google/bluejay/bluejay:13/TQ1A.221205.011/9244662:user/release-keys
[string] 4.1.2 bluejay
[string] 4.1.3 google
[string] 4.1.4 unknown
[string] 4.1.5 bluejay-1.2-9152140
[string] 4.1.6 android-google
[uint32] 4.1.7 1671729802
[string] 4.1.9 bluejay
[uint32] 4.1.10 33
[string] 4.1.11 Pixel 6a
[string] 4.1.12 Google
[string] 4.1.13 bluejay
[uint32] 4.1.14 0
[uint32] 4.2 0
[message] 4.3
[string] 4.3.1 event_log_start
[uint64] 4.3.3 1674552689097
[string] 4.6 26207
[string] 4.7 26207
[string] 4.8 mobile-notroaming
[uint32] 4.9 0
[string] 6 de_DE
[uint64] 7 12040080050019317819
[string] 9 b407f9ae627e
[string] 10 355031043209390
[message] 11
[string] 12 Europe/Berlin
[uint32] 14 3
[string] 15 71Q6Rn2DDZl1zPDVaaeEHItd
[string] 16 008741A1C3D3F3C8
[message] 18
[uint32] 18.1 3
[uint32] 18.2 1
[uint32] 18.3 1
[uint32] 18.4 2
[uint32] 18.5 0
[uint32] 18.6 0
[uint32] 18.7 420
[uint32] 18.8 196610
[string] 18.9 android.ext.shared
[string] 18.9 android.hidl.base-V1.0-java
[string] 18.9 android.hidl.manager-V1.0-java
[string] 18.9 android.net.ipsec.ike
[string] 18.9 android.system.virtualmachine
[string] 18.9 android.test.base
[string] 18.9 android.test.mock

[...]

[string] 18.10 android.hardware.camera.autofocus
[string] 18.10 android.hardware.camera.capability.manual_post_processing
[string] 18.10 android.hardware.camera.capability.manual_sensor
[string] 18.10 android.hardware.camera.capability.raw
[string] 18.10 android.hardware.camera.concurrent
[string] 18.10 android.hardware.camera.flash
[string] 18.10 android.hardware.camera.front
[string] 18.10 android.hardware.camera.level.full
[string] 18.10 android.hardware.context_hub
[string] 18.10 android.hardware.device_unique_attestation
[string] 18.10 android.hardware.faketouch
[string] 18.10 android.hardware.fingerprint
[string] 18.10 android.hardware.hardware_keystore
[string] 18.10 android.hardware.identity_credential
[string] 18.10 android.hardware.keystore.app_attest_key
[string] 18.10 android.hardware.location
[string] 18.10 android.hardware.location.gps
[string] 18.10 android.hardware.location.network
[message] 18.10
[fixed64] 18.10.12 7507048032877306990
[fixed64] 18.10.12 7867337140998726770
[fixed64] 18.10.13 7308901739622527587
[string] 18.10 android.hardware.nfc
[string] 18.10 android.hardware.nfc.any
[string] 18.10 android.hardware.nfc.ese
[string] 18.10 android.hardware.nfc.hce
[string] 18.10 android.hardware.nfc.hcef
[string] 18.10 android.hardware.nfc.uicc
[string] 18.10 android.hardware.opengles.aep
[message] 18.10
[fixed64] 18.10.12 7507048032877306990
[fixed64] 18.10.12 8227625111188366450
[fixed64] 18.10.12 7809643567100341869
[string] 18.10 android.hardware.screen.landscape
[string] 18.10 android.hardware.screen.portrait
[string] 18.10 android.hardware.se.omapi.ese
[string] 18.10 android.hardware.se.omapi.uicc
[string] 18.10 android.hardware.security.model.compatible
[string] 18.10 android.hardware.sensor.accelerometer
[string] 18.10 android.hardware.sensor.barometer
[string] 18.10 android.hardware.sensor.compass
[string] 18.10 android.hardware.sensor.dynamic.head_tracker
[string] 18.10 android.hardware.sensor.gyroscope
[string] 18.10 android.hardware.sensor.hifi_sensors
[string] 18.10 android.hardware.sensor.light
[string] 18.10 android.hardware.sensor.proximity
[string] 18.10 android.hardware.sensor.stepcounter

[...]

Die übermittelten Informationen sind gekürzt dargestellt, dennoch kann man einiges herauslesen. Es werden etliche Gerätedaten (Gerätemodell, Sprache, Land, installierte System-Bibliotheken, Hardware-Features, CPU-Type, UUIDs, Android-Version etc.) an Google übermittelt. Auch diese Netzwerk-Verbindung ist nicht in der CalxyOS-Dokumentation vermerkt. Dazu ein Hinweis vom microG-Entwickler:

Generell sind die Daten, die bei der Geräte-Registrierung gesendet werden, soweit möglich, praktisch anonymisiert. Wenn der Speicher des Geräts zurückgesetzt wird, ist es aus Googles Sicht nicht mehr wiederzuerkennen. Die gerätespezifischen Daten sind alle nur Modell-spezifisch, aber nicht auf das individuelle Gerät zugeschnitten – alle Pixel 6a mit CalyxOS und deutscher Sprache sehen für Google also gleich aus.

Diese Registrierung bzw. Anmeldung bei Google lässt sich über microG-Einstellungen -> Google Geräte-Registrierung deaktivieren. Nur sollte man sich vor der Deaktivierung darüber im Klaren sein, dass anschließend Push-Notifications, SafetyNet und weitere API-Komponenten nicht mehr (korrekt) funktionieren. Die Deaktivierung des Schiebereglers kommt also einer Stilllegung von microG gleich:

Google Registration

5. Tabelle mit Datenverbindungen

Die nachfolgende Tabelle fasst alle identifizierten Netzwerkverbindungen in einer Übersicht zusammen:

Domain Zweck Einschätzung
connectivitycheck.
gstatic.com
www.google.com
[System]
CalyxOS stellt eine Verbindung zu diesem Google-Dienst her, um festzustellen, ob das Gerät eine Verbindung zum Internet herstellen kann. Diese Verbindung ist aus unterschiedlichen Gründen problematisch. Zunächst einmal wird sie am VPN vorbeigeschleust. Wie bereits dargestellt, kann man sich trefflich darüber streiten, ob dies nun ein VPN-Leak darstellt oder eine bewusste Design-Entscheidung. Entscheidet man sich für die Deaktivierung des Dienstes, wird Google zwar nicht jedes Mal »angepingt«, allerdings entstehen dann gerade in Kombination mit Captive-Portals in Hotels/Flughäfen etc. erhebliche Probleme. Alternativ kann man den Captive-Portal-Check auch auf einen anderen Dienst umleiten. Siehe dazu die Empfehlungsecke.
time.android.com
[System]
CalyxOS verbindet sich mit diesem Google-Dienst, um die interne Uhr des Geräts zu synchronisieren. Auch hier sitzt wiederum Google am anderen Ende der Leitung. Alternativ könnte CalyxOS selbst einen NTP/SNTP-Dienst hosten, um den »Ping« an Google zu vermeiden.
remoteprovisioning.
googleapis.com
[System]
Anforderung von Zertifikatsketten bzw. Beglaubigung, die dann im Schlüsselspeicher des Geräts abgelegt und dort für Apps bereitgehalten werden. Unter anderem Voraussetzung für Dienste wie SafetyNet. Um die Privatsphäre zu verbessern/wahren, nutzt GrapheneOS einen Reverse-Proxy (https://remoteprovisioning.grapheneos.org). CalyxOS hingegen bietet eine solche Möglichkeit nicht. Hier erfolgt eine direkte Verbindung mit dem Key-Provisioning-Server von Google.
release.calyxinstitute.org
[System]
Wird verwendet, um nach System-Updates zu suchen.
mtalk.google.com
[microG]
Sofern microG installiert:
Wird für den Empfang von Push-Benachrichtigungen verwendet.
Der »Preis« für den Empfang von Push-Notifications über den Google-Dienst Firebase Cloud Messaging (FCM) geht mit einer dauerhaften Aktualisierung der Verbindung einher – zu Google-Servern.
www.bromite.org
[Browser]
Der Browser aktualisiert die Filterlisten des integrierten Tracking- und Werbeblockers.
supl.google.com
[System]
Wird für die (Beschleunigung der) Positionsbestimmung verwendet. Dies ist eine jener Verbindungen, die in der CalyxOS-Dokumentation unter Network Activity nicht hinterlegt ist. Die Verwendung eines Google SUPL-Servers ist aus meiner Sicht nicht gerade datenschutzfreundlich. Wenn dabei zusätzlich noch ein personenbeziehbares Datum wie die IMSI-Nummer übermittelt wird, ist das kritisch. Leider hat der Nutzer darauf keinerlei Einfluss.
gllto.glpals.com
[System]
Wird für die (Beschleunigung der) Positionsbestimmung verwendet. Die PSDS-Hilfsdaten werden direkt von Broadcom bezogen. Dabei werden (außer der IP-Adresse) keine sensiblen Daten übermittelt.
location.services.mozilla.
com
[microG]
Sofern microG installiert:
Wird für die (Beschleunigung der) Positionsbestimmung verwendet.
Jeder muss selbst entscheiden, ob er damit einverstanden ist, dass der Mozilla Location Service, Informationen zum eingebuchten Mobilfunkmast und alle im Empfang (des Smartphones) befindlichen WiFi-Netzwerke übermittelt bekommt.
android.clients.google.
com
[microG]
Sofern microG installiert:
Bei dieser Verbindung wird das Gerät zur Nutzung von Google-Diensten vorbereitet.
Der »Preis« für die Nutzung von Google-Diensten wie Push-Notifications, SafetyNet und weitere API-Komponenten (die microG implementiert) geht mit einer (dauerhaften) Datenübermittlung mit Google-Servern einher. Es werden etliche Gerätedaten (Gerätemodell, Sprache, Land, installierte Packages/Apps, CPU-Type, UUIDs, Android-Version etc.) an Google übermittelt.

Folgende Verbindungen sind in der Dokumentation von CalyxOS (Network Activity) nicht verzeichnet:

  • remoteprovisioning.googleapis.com
  • supl.google.com
  • gllto.glpals.com
  • location.services.mozilla.com [microG]
  • android.clients.google.com [microG]

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

6.1 Entwickler | Institution

CalyxOS wird vom Calyx Institute entwickelt/bereitgestellt, dessen Geschichte laut Wikipedia bis ins Jahr 2004 zurückreicht. Das Team rund um CalyxOS ist prominent besetzt.

Werfen wir mal einen Blick auf die About-Seite von CalyxOS:

CalyxOS is different. We believe the device in your pocket should always work for your best interests. Our guiding principles include:

  • Privacy: You should have total control over your own personal data. Our guiding principle is Privacy By Design, an approach that incorporates your interests at every step of the design and development process.
  • Security: Your device should not surprise you. The meaning of security is different for everyone. Maybe you are concerned about repressive governments, censorship, surveillance, ransomware, or just your nosy friend reading your messages. Whatever is important for you, your device should not surprise you by leaking information that seems like it should be secure or exposing your device to various attacks.
    […]

Sofern jemand das Prinzip Privacy By Design nennt, lohnt es sich, etwas genauer hinzuschauen:

CalyxOS does not put your data in Google’s cloud or constantly report your location to Google.

Es landen zwar nicht kontinuierlich Daten in der Google-Cloud, aber sofern die Standortbestimmung aktiv ist, wird der ungefähre Standort eines Nutzers inkl. der personenbeziehbaren IMSI-Nummer an Google übermittelt (siehe 4.5 (GPS-)Standort). Aber auch die Nutzung weiterer Google-Infrastruktur wie des Captive-Portal-Checks oder der Key-Provisioning-Server (remoteprovisioning.googleapis.com) ist hierbei erwähnenswert.

Das Calyx Institute bewirbt CalyxOS ebenfalls als de-googled. Was bedeutet das eigentlich?

Stock Android is a combination of the underlying Android Open Source Project (AOSP) which is free software, plus a number of proprietary layers including the Google Play Services and many proprietary Google applications ( Gmail, Google Maps, Google Drive, Duo, Google Meet, Google Fi etc ). Because CalyxOS is a free software and privacy focused Android, we don’t include the proprietary, closed-source Google parts. This has benefits and drawbacks. Many application developers rely on Google’s play services in order to have basic functionality such as push notifications, mapping and others. If you simply remove Google’s proprietary layers many applications no longer work properly and some crash. To remedy this, we decided to include a free software project called MicroG whose intention is to make an open source implementation of some of Google’s services but with more enhanced privacy.

Nun kennen wir die Definition von de-googled. Meine Definition davon wäre eine andere. Nämlich der (vollständige) Verzicht auf Google-Dienste und auch Google-Infrastruktur. Das schafft CalyxOS leider auch dann nicht, wenn man auf microG verzichtet.

6.2 Installationsvorgang

Sofern man etwas Geduld und Zeit mitbringt, sollte der Installationsvorgang von jedem durchführbar sein, der in der Lage ist, einer Anleitung 1:1 zu folgen. Nach Auswahl des entsprechenden Geräts stehen Installationsanleitungen für Windows, macOS und Linux bereit. Exemplarisch verlinke ich hier die Flash-Anleitung für das Google Pixel 6a. Kurz zusammengefasst sind die Schritte wie folgt:

  • Entwickleroptionen, USB-Debugging und OEM-Unlocking aktivieren
  • Falls notwendig: Benötigte Linux-Pakete bzw. Software installieren
  • Den Device-Flasher und das Geräteimage herunterladen
  • Checksummen der beiden heruntergeladenen Dateien verifizieren
  • Den Device-Flasher ausführen/starten
  • Den Bootloader im Installationsvorgang mittels Tastenwippe entsperren
  • Warten, bis der Device-Flasher den Vorgang beendet
  • Den Bootloader des Geräts wieder sperren

Für jemanden, der sich mit dieser Materie bisher nicht beschäftigt hat, sind da natürlich ein paar »Fremdwörter« dabei. Davon sollte man sich jedoch nicht abschrecken lassen.

6.3 Verfügbarkeit (Sicherheits-)Updates

Der wirkungsvollste Schutz gegen bekanntgewordene bzw. geschlossene Schwachstellen ist das Einspielen von (Sicherheits-)Updates. Google stellt mittlerweile monatlich Sicherheitsupdates bereit, die traditionell um den 5. eines Monats veröffentlicht werden. Leider stecken viele Anwender in einem Dilemma: Einige Smartphone-Hersteller schaffen es oftmals nicht, zeitnah Updates für ihre herstellerspezifischen Android-Versionen bereitzustellen oder unterstützen ältere ihrer Geräte einfach aus Kostengründen nicht mehr. Damit entsteht zwangsläufig ein »Vakuum« in der Android-Welt, das viele Geräte anfällig für kritische Sicherheitslücken macht.

CalyxOS wirbt nicht nur mit Datenschutz, sondern auch mit Sicherheit. Das bedeutet: Man erwartet, dass die monatlichen (Sicherheits-)Updates zeitnah bereitgestellt werden. Aus meinem Beobachtungszeitraum (Dezember 2022, Januar 2023 und Februar 2023) kann ich Folgendes berichten:

  • Dezember: Google-(Security-)Updates erscheinen am 5. Dezember | Von CalyxOS veröffentlicht am 9. Dezember
  • Januar: Google-(Security-)Updates erscheinen am 3. Januar | Von CalyxOS veröffentlicht am 25. Januar (4.5.0 wurde zurückgezogen)
  • Februar: Google-(Security-)Updates erscheinen am 6. Februar | Das Februar-Update ist bis dato (10.02.2023) noch nicht verfügbar

Auf einem Google Pixel 6a mit Stock-ROM wurde das Februar-Update (erscheinen 6. Februar) bereits ausgeliefert. Ähnliches kann ich von einem Google Pixel 4a mit GrapheneOS berichten, bei dem das Update am 6. Februar verfügbar war.

Für eine Betrachtung über einen längeren Zeitraum kann man sich die Android-Sicherheitsbulletins der letzten Monate/Jahre anschauen und gegenprüfen, wann diese von CalyxOS veröffentlicht (Changelog) wurden. Mein Kurzcheck ergab:

  • Ganz selten erschien das Update am selben Tag
  • Meist liegen einige Tage (3-6) zwischen der Google-Veröffentlichung und dem Release von CalyxOS
  • Es gibt auch ein paar Ausreißer, bei denen CalyxOS sieben und mehr Tage hinterherhinkt (wie auch Januar 2023)

Offenbar erscheinen die (Sicherheits-)Updates nicht so zeitnah, wie man sich das von einem System wie CalyxOS wünschen würde. Was zusätzlich auffällt: In den Monaten August und September 2022 wurden die Security-Updates jeweils nur teilweise ausgerollt:

September 2022 Security update (Partial, open source patches)

Erst im Oktober 2022 wurden die vollständigen (Sicherheits-)Updates mit dem Upgrade auf Android 13 für August, September und Oktober 2022 ausgeliefert.

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« ist aufgezeigt, welche Daten Google von einem Gerät erhebt – und das, obwohl praktisch alle Einstellungen möglichst datenschutzfreundlich konfiguriert wurden.

In CalyxOS ist die Google-Play-Dienste-Alternative microG integriert. Man muss sich allerdings während der Inbetriebnahme des Smartphones entscheiden, ob man diese nutzen möchte oder nicht. Es besteht keine Möglichkeit, die microG-Dienste nachträglich nachzuinstallieren – das funktioniert nur über ein Reset auf Werkseinstellungen. In der Dokumentation ist microG ein komplettes Unterkapitel gewidmet. Ich zitiere dort mal eine Stelle:

Location: typically, an Android device will using WiFi and cell-towers data from Google to help determine precise location. microG does this without using Google, and without reporting your location to Google (CalyxOS is configured to use location information from Mozilla).

Leider ist das nicht korrekt. Selbst wenn microG installiert/aktiv ist, wird noch immer der SUPL-Server von Google kontaktiert und neben Informationen zum ungefähren Standort (Mobilfunkmasten) ebenfalls die IMSI-Nummer übermittelt.

Klar, gegenüber den Google-Play-Diensten ist microG deutlich weniger invasiv und ebenfalls quelloffen. Dennoch sollte man sich hier vor Augen führen, (auch) weiterhin auf die Infrastruktur von Google angewiesen zu sein.

6.5 Sicherheit/Datenschutz

CalyxOS unterstützt Verified Boot. Dieses soll sicherstellen, dass der gesamte ausgeführte Code von einer vertrauenswürdigen Quelle stammt und ein Angreifer keine Manipulation daran vorgenommen hat. Das soll unter anderem Evil-Maid-Angriffe erkennen, bei dem ein Angreifer Zugang zum Gerät hat. Bei einem Gerät, das bspw. einen offenen Bootloader (unlocked) hat und/oder bei dem zusätzlich ein Recovery-Image aufgespielt wurde, ist es für einen versierten Angreifer möglich Veränderungen vorzunehmen, die man als Nutzer im Nachhinein nicht erkennt. Die Android-Geräteverschlüsselung, die auch beim Booten ins Recovery abgefragt wird, schützt nämlich nur die Nutzerdaten. Ein Angreifer kann aber mittels ADB (Android Debug Bridge) weiterhin auf die Systempartition zugreifen und daran Veränderungen vornehmen. Denkbar ist auch eine Veränderung des Bootloaders. Zugegeben ist das ein eher geringes Risiko, aber die Möglichkeit besteht dennoch. CalyxOS bootet nur dann, wenn keine (manipulative) Veränderung durch einen Dritten am Bootloader, System, Vendor-Dateien etc. festgestellt wurde. Das ist auch der Grund, weshalb der Bootloader nach dem Aufspielen von CalyxOS wieder geschlossen werden sollte.

Daneben bietet CalyxOS noch weitere Anpassungen, die sich positiv auf die Sicherheit und den Datenschutz auswirken können. Dazu zählt bspw. der Umgang mit Unique Identifiers:

Your Android device has many identifiers that are unique, creating many opportunities for applications and services to track your activity. This page attempts to document all the important identifiers, how CalyxOS handles each one, and how this differs from stock Android distributions.

Nach dem Durchlesen der Seite stellt sich allerdings schnell Ernüchterung ein: Die meisten Maßnahmen werden bereits in Standard-Android implementiert bzw. der »Schutz« wird dadurch erreicht, dass auf die Google-Play-Dienste verzichtet wird.

Wirklich positiv muss ich hingegen die in CalyxOS integrierte Firewall Datura erwähnen, die eine Steuerung ermöglicht, unter welchen Bedingungen eine App, Verbindung mit dem Netzwerk/Internet aufnehmen kann:

Datura Firewall

Das funktioniert in der Praxis tatsächlich zuverlässig. Entzieht man einer App bspw. den
Netzwerkzugriff im Hintergrund zulassen, kann die App nur dann (Netzwerk-)Verbindungen aufbauen, wenn sie im Vordergrund ist bzw. aktiv genutzt wird. Das ist gerade bei solchen Apps sinnvoll, die sich automatisch bei einem externen (System-)Trigger starten und Netzwerkverkehr erzeugen, obwohl der Nutzer die App gerade nicht nutzt/das nicht möchte. Der Next DB Navigator oder auch die heise-App starten sich bspw. nach einem Systemstart automatisch und beginnen damit Domains aufzurufen – darunter auch Tracking-Domains. Mit dieser Einstellung kann man zuverlässig verhindern, dass Apps ungewollt im Hintergrund Datenverbindungen initiieren – natürlich ist das nicht bei jeder App sinnvoll, aber bei einigen schon. Dem (App-)Tracking an sich entkommt man dadurch natürlich nicht, aber man kann selbst bestimmen, wann eine App Verbindungen initiieren darf (bspw. wenn aktiv genutzt bzw. im Vordergrund). Tipps und Tricks zur Minimierung von App-Tracking und Werbeeinblendungen findet ihr in der Empfehlungsecke.

Datura-Leaks

In meiner Analyse konnte ich in Kombination mit Orbot Leaks feststellen. Deaktiviert man bei Orbot Netzwerkzugriff im Hintergrund zulassen, lässt sich bspw. über eine Browser-App weiterhin eine Verbindung über den Tor Socks-Proxy ins Internet aufbauen.

7. Fazit

Ein Zitat aus der Beschreibung von CalyxOS möchte ich noch verarbeiten:

CalyxOS has reconfigured Android to avoid Google’s spyware and tracking.

Das sehe ich nur eingeschränkt so. Um wirklich datenschutzfreundlich zu sein, müsste das Projekt weitere Parameter/Quellcode des AOSP-Standards modifizieren und den Nutzern mehr Optionen bzw. Freiheit (Captive-Portal-Check, Key-Provisioning-Server, SUPL-Server) zur Anpassung bereitstellen. Der Verzicht auf die Integration der Google-Play-Dienste reicht nicht aus, um ein Gerät als de-googled zu bezeichnen. Da ist noch Luft nach oben.

Insgesamt ist CalyxOS sicherlich kein schlechtes Custom-ROM, sondern bietet ein stimmiges Gesamtpaket, mit dem Nutzer, die ihre Abhängigkeit von Google (stark) reduzieren möchten, einen guten Start haben dürften. Allerdings sollte man ebenfalls die Nachteile berücksichtigen: Die verzögerte Bereitstellung von (Sicherheits-)Updates und eine Außendarstellung, die nicht ganz zu dem passt, was die vorliegende Analyse ergab.

Bildquellen:

CalyxOS: Chirayu Desai from wikimedia.org is licensed by CC BY-SA 4.0

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

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

Bleib aktuell ➡


Diskussion

Ich freue mich auf Deine Beteiligung zum Artikel

HilfeWenn 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.