Vorschau: GrapheneOS und CalyxOS
Aktuell schaue ich mir gerade die beiden Android-Custom-ROMs GrapheneOS und CalyxOS an. Beide fokussieren sich auf mehr Sicherheit und Privatsphäre. Erreicht wird dies unter anderem durch die Möglichkeit den Bootloader nach dem Aufspielen des Systems wieder zu schließen und Verified Boot – also die Sicherstellung, dass der ausgeführte Code von einer vertrauenswürdigen Quelle stammt und ein Angreifer keine Manipulation daran vorgenommen hat.
GrapheneOS wirbt wie folgt:
GrapheneOS is an open source privacy and security focused mobile OS with Android app compatibility.
Und auch CalyxOS ist nicht zurückhaltend:
Android without spyware: CalyxOS has reconfigured Android to avoid Google’s spyware and tracking. […]
Der Praxistest brachte dann ein klein wenig Ernüchterung. Fangen wir mal mit CalyxOS an.
Wenn man dort während der Einrichtung das WLAN-Interface auf eine manuelle IP-Adresse setzt, dann sind die Google DNS-Server (8.8.8.8 / 8.8.4.4) voreingestellt. Unmittelbar nach dem Start erfolgt der Captive-Portal-Check dann über die bekannte Google-Adresse »connectivitycheck.gstatic.com«:
Wed Nov 4 21:21:54 2020 daemon.info dnsmasq[3875]: 607 192.168.150.16/19984 query[A] connectivitycheck.gstatic.com
Und die Zeit wird auch gleich bei Google angefragt:
Wed Nov 4 21:21:54 2020 daemon.info dnsmasq[3875]: 608 192.168.150.16/53508 query[A] time.android.com
Vor dem Hintergrund, dass mit »Security and privacy by default« geworben wird, ist das ein klein wenig enttäuschend.
GrapheneOS macht es nur ein klein wenig besser. Dort sind während der Einrichtung die Standard-DNS-Server auf die von Cloudflare (1.1.1.1) definiert.
Unmittelbar nach dem Start erfolgt der Captive-Portal-Check dann ebenfalls über die bekannte Google-Adresse »connectivitycheck.gstatic.com«:
Thu Nov 5 09:19:31 2020 daemon.info dnsmasq[565]: 8242 192.168.150.17/51511 query[A] connectivitycheck.gstatic.com
Als Zeitserver setzt GrapheneOS auf einen eigenen Dienst:
Thu Nov 5 09:19:31 2020 daemon.info dnsmasq[565]: 8242 192.168.150.17/51511 query [A] time.grapheneos.org
Im Gegensatz zu CalyxOS nennt GrapheneOS in der FAQ alle Verbindungen, die vom System während dem Start und der Nutzung aufgebaut werden. Zum Captive-Portal-Check ist dort hinterlegt:
We have our own connectivitycheck.grapheneos.org server as an alternative to using the standard URLs. This can currently be enabled by users interested in using it via the developer tools. Providing a toggle in the Settings app for using connectivitycheck.grapheneos.org as an alternative is planned. The option to blend into the crowd with the standard URLs is important and must remain supported for people who need to be able to blend in rather than getting the nice feeling that comes from using GrapheneOS servers.
- HTTPS: https://connectivitycheck.grapheneos.org/generate_204
- HTTP: http://connectivitycheck.grapheneos.org/generate_204
Man ist sich der Problematik also bewusst und kann dies umstellen.
Das ist natürlich Jammern auf hohem Niveau. Aber ich finde, wenn man tatsächlich den Anspruch auf ein datenschutzfreundliches System hat, dann muss man hier so ehrlich sein und auch sagen: Das geht besser. Bei beiden Systemen lässt sich das Captive-Portal immerhin manuell anpassen.
Davon abgesehen sind beide Systeme ein Vorbild. Außer Update-Checks gehen rein vom System her keine Netzwerkanfragen über die Leitung. So wünscht man sich das.
Die CalyxOS-Entwickler habe ich bereits benachrichtigt und vorgeschlagen, dass der Nutzer die Wahl haben sollte, ob er den Captive-Portal-Check über Google-Server machen möchte oder nicht.
Ein Nachteil von beiden Systemen sollte nicht unerwähnt bleiben: Die Geräteauswahl ist auf Geräte von Google beschränkt. Das hat seinen Grund, wie man dem GrapheneOS-Wiki entnehmen kann:
Devices need to be meeting the standards of the project in order to be considered as potential targets. In addition to support for installing other operating systems, standard hardware-based security features like the hardware-backed keystores, verified boot, attestation and various hardware-based exploit mitigations need to be available. Devices also need to have decent integration of IOMMUs for isolating components such as the GPU, radios (NFC, Wi-Fi, Bluetooth, Cellular), media decode / encode, image processor, etc., because if the hardware / firmware support is missing or broken, there’s not much that the OS can do to provide an alternative. Devices with support for alternative operating systems as an afterthought will not be considered. Devices need to have proper ongoing support for their firmware and software specific to the hardware like drivers in order to provide proper full security updates too.
Um das nun zu verstehen, muss man zunächst einmal wissen, dass die Sicherheit eines Android-Geräts grob gesagt von drei Ebenen abhängt:
- Ebene 1: Android-System
- Ebene 2: Kernel
- Ebene 3: Firmware
Nur wenn alle drei Ebenen aktuell gehalten werden, kann man von einem hohen Grad an Sicherheit sprechen. Lest dazu bitte den folgenden Beitrag: Aufklärung über den Stand der Sicherheitsupdates.
GrapheneOS und CalyxOS setzen also unter anderem deshalb auf die Geräte von Google, weil diese auf allen drei Ebenen »sicher« sind bzw. aktuell gehalten werden können – bei Google-Pixel-Geräten zumindest für eine Dauer von drei Jahren. Das leistet kaum ein anderer Hersteller. Zugegeben, das ist schon paradox. Um die größtmögliche Unabhängigkeit von Google zu erlangen, muss man letztendlich in Google-Geräte investieren. Eine Umfrage auf Mastodon zeigt auch, dass knapp 60 % der Nutzer dies für einen Nachteil halten bzw. »Geht gar nicht« ausgewählt haben.
Soweit die Vorschau. In einem ausführlichen Beitrag werde ich nochmal auf beide Systeme eingehen – insbesondere auf GrapheneOS.
CalyxOS: De-Googled geht anders – Custom-ROMs Teil2
iodéOS: Datenschutzfreundlich, aber Abstriche bei der Sicherheit – Custom-ROMs Teil3
GrapheneOS: Das Android für Sicherheits- und Datenschutzfreaks
LineageOS: Weder sicher noch datenschutzfreundlich – Custom-ROMs Teil4
