Sicherheitskompromisse freier Android-Derivate

  nor   Lesezeit: 7 Minuten  🗪 7 Kommentare

Bei der Befreiung eines Android Handys sollte man einige Sicherheitsaspekte berücksichtigen.

sicherheitskompromisse freier android-derivate

Mobilgeräte sind Wanzen. Darüber sind sich die meisten einig. Die Betriebssysteme von Google und Apple 'telefonieren nach Hause', senden also eine Menge Daten über den Nutzer an ihre Hersteller. Um hier Abhilfe zu schaffen, ist es bei den Freunden von Privatsphäre und freier Software nicht unüblich, den Bootloader von Androidgeräten zu entsperren und freie Android-Derivate zu installieren.

In diesem Artikel sollen ein paar Probleme aufgezeigt werden, die das mit sich bringt, und welche Kompromisse an Androids Sicherheitskonzept eingegangen werden, um die Ziele der freien Android-Derivate umzusetzen.

Google Services und microG

Androidgeräte haben in der Regel die Google Services vorinstalliert, und dies als Systemapps, also als nicht deinstallierbare Apps mit erhöhten Privilegien. Hier liegt das grösste Problem des Standard-Android. 'Entgoogelte' Android-Derivate werden ohne diese Google-Apps erstellt, um die Privatsphäre besser zu schützen.

Während dies für die meisten Android-Apps keinen grossen Unterschied macht und sie auch ohne Google-Apps funktionieren, sind sie für einige eine Abhängigkeit. Manche Anwendungen erhalten auf entgoogelten Systemen keine Benachrichtigungen, ohne im Vordergrund geöffnet zu werden. Selten sieht man auch Apps, die direkt nach dem Öffnen abstürzen, weil die von ihnen erwartete Umgebung so nicht existiert.

Es gibt zwei Wege, wie die Custom ROMs damit umgehen. Einige, wie /e/, LineageOS for microG sowie CalyxOS, installieren hierzu microG. MicroG ist ein Projekt, bei dem die Funktionalität, die sonst von den proprietären Googlediensten bereitgestellt wird, weitestmöglich mit freier Software reimplementiert wird. Je nach Nutzung baut auch microG wiederum Verbindungen zu den Googleservern auf, z.B. für die Pushbenachrichtigungen.

Andere Systeme wie LineageOS und DivestOS lehnen das Einbinden von microG strikt ab. Grund dafür ist nicht nur, dass microG – wenngleich in sehr viel kleinerem Rahmen – je nach Nutzungsweise wiederum Daten an Google schickt.

Ein wesentliches Problem ist auch, dass sich microG, um im System die Rolle der Google-Komponenten einzunehmen, als diese ausgeben muss. Dies erfordert Signaturspoofing: Das System muss also die Kontrolle, welche App welche ist, schwächen. Dieses Signaturspoofing wird als grosses Sicherheitsproblem angesehen: wenn sich Apps als andere Apps ausgeben und an deren Stelle auf Daten zugreifen können, die somit eigentlich ausserhalb ihrer App-Sandbox liegen, wird letztere deutlich geschwächt.

Es herrscht Uneinigkeit darüber, wie ernst diese Sicherheitsbedenken sind. Betriebssysteme mit Unterstützung für Signaturspoofing schränken dieses oft ein, z.B. indem es nur microG zur Verfügung stehen soll oder manuell festgelegt wird, wo Signaturspoofing möglich ist. Andererseits ist es dennoch eine bewusste Schwächung von Androids Sicherheitskonzept, welche von einigen als inakzeptabel angesehen wird. Einen Sonderweg geht GrapheneOS, welches Signaturspoofing und somit microG ebenfas strikt ablehnt, stattdessen aber eine Kompatibilitätsschicht bereitstellt, welche es erlaubt, die Google-Apps ohne Privilegien innerhalb der normalen App-Sandbox zu installieren und somit in ihren Befugnissen eingeschränkt, z.B. netzwerklos, zu betreiben.

Sicherheitsupdates und Supportdauer

Ein weiterer häufiger Grund zur Installation von sogenannten Custom ROMs ist der Wunsch, ein Gerät länger als vom Hersteller unterstützt zu betreiben. Die meisten Androidgeräte sind bereits 2-3 Jahre nach Erscheinen am 'EOL', dem 'End of life', angekommen, erhalten also keine Updates und somit keine Sicherheitspatches vom Hersteller mehr. Manche Custom ROMs versprechen, EOL-Geräte weiterhin mit Updates zu versorgen.

Hierbei muss man sich bewusst sein, dass diese von Freiwilligen unterhaltenen Systeme zwar all das Updaten und Patchen können, was freie Komponenten sind, beim Patchen von proprietären BLOBs in Treibern und Firmware allerdings ebenfalls auf den Hersteller der jeweiligen Hardwarekomponenten angewiesen sind. Sicherheitslücken in nicht mehr offiziell unterstützten, auf Mobilgeräten leider sehr häufigem hardwarespezifischem Code bleiben somit oft auch mit diesen lebensverlängernden freien Systemen ungepatcht.

Root und Bootloader

In Kürze soll noch auf zwei weitere bedenkenswerte Haken eingegangen werden. Hin und wieder werden Androidsysteme gerootet oder auch mit vorab verfügbarem Rootzugriff installiert. Auch hier sollte man sich bewusst sein, dass Androids Sicherheitskonzept eigentlich vorsieht, dass der Rootzugriff gesperrt bleibt.

Zum Installieren eines anderen Android-Derivats muss der Bootloader entsperrt werden. Empfehlenswert ist hier, eine Kombination aus Hardware und Software zu wählen, bei der anschliessend der Bootloader nach der Installation mit dem neuen System wieder gesperrt werden kann, da dies für den verifizierten Boot und somit die Systemintegrität sehr wichtig ist.

Fazit

Google-Android-Systeme durch freie Android-Derivate zu ersetzen, wirft ein paar Probleme auf, mit denen von unterschiedlichen Betriebssystemen wie auch unterschiedlichen Personen unterschiedlich behandelt werden. Zum Betreiben bestimmter Apps können microG und somit Signaturspoofing, oder der Rootzugriff notwendig sein. Manche Hardware, die man betreiben möchte, kann nur noch mit ungepatchten Blobs oder mit offengelassenem Bootloader verwendet werden.

Alle vier Kompromisse sind hinsichtlich ihrer Bedeutung für die Systemsicherheit umstritten. Das bedeutet nicht, dass diese Kompromisse niemals eingegangen werden sollten, doch man sollte sich dabei bewusst sein, dass man sie überhaupt eingeht. Absolute Sicherheit ist ohnehin nicht möglich, doch ist es gut zu wissen, welche Entscheidungen welche Implikationen für die Sicherheit der eigenen IT-Geräte haben.

Links

Dies sind ein paar von vielen Links (englischsprachig), die das Thema aus unterschiedlichen, teils sehr einseitigen Meinungsperspektiven beleuchten. Sie geben allerdings einen guten Einblick, warum angesprochene Kompromisse als bedenklich oder unbedenklich sehr umstritten sind.

https://divestos.org/index.php?page=faq
https://lineage.microg.org/#faq
https://wiki.lineageos.org/faq#my-device-doesnt-pass-safetynet
https://wiki.lineageos.org/faq#will-you-enable-signature-spoofing
https://grapheneos.org/faq#legacy-devices
https://madaidans-insecurities.github.io/android.html
https://calyxos.org/docs/guide/microg/#is-using-microg-a-privacy-risk
https://calyxos.org/docs/guide/microg/#is-microg-a-security-risk-in-calyxos-because-it-requires-signature-spoofing

Tags

microG, Android-Derivate, ROMs, LineageOS, Signaturspoofing, Android, Google, App, Kompromiß

Speedy-10
Geschrieben von Speedy-10 am 3. Juni 2022 um 16:16

Es wäre noch zu erwähnen: https://sailfishos.org/

n0r
Geschrieben von n0r am 3. Juni 2022 um 18:38

Es gibt einige freie mobile Betriebssysteme, ein weiteres Beispiel ist Ubuntu Touch, und es gibt noch mehr. Allerdings ging es hier speziell um AOSP-basierte Systeme, insbesondere bezüglich microG. Nicht androidbasierte Alternativen sind aber natürlich auch ein weites, sehr interessantes Themenfeld.

Bob
Geschrieben von Bob am 3. Juni 2022 um 17:43

Ich weise auch noch gerne auf das noch recht neue iodéOS hin: https://iode.tech/de/iodeos-de/

Es basiert auf LineageOS, integriert einen Adblocker und bringt weitere kleine "Ent-Google"-Änderungen mit (bspw. Googles DNS durch Quad9 ersetzt). microG wird mitgeliefert, kann aber vollständig deinstalliert werden.

Ich verwende es schon fast 1 Jahr und bin sehr zufrieden damit (gestern kam Update auf Android 12). Einzeiger Nachteil (mit dem ich persönlich leben kann), wie auch im Artikel angesprochen, ist der Bootloader: Bei meinem Samsung Handy kann ich den Bootloader nicht mehr sperren (beim Fairphone 4 wird das wohl unterstützt).

n0r
Geschrieben von n0r am 4. Juni 2022 um 09:21

Leider ist iodéOS eines der Androidderivate, bei denen ich die meisten Probleme sehe.

Nicht nur, dass Signaturspoofing enthalten ist und veraltete Geräte "unterstützt" werden, das viel größere Problem sehe ich darin, dass es sich wohl nicht um freie Software handelt.

Zwar sind Open-Source-Komponenten wie microG und F-Droid (oder auch wie bei jedem Android der Kernel) verwendet/eingebaut, aber der eigenentwickelte Quellcode von iodéOS selbst ist meines Wissens nach nicht öffentlich verfügbar und das System hat vorinstallierte proprietäre Apps.

Soweit ich das nach kurzer oberflächlicher Suche überprüfen konnte, hat sich das wohl auch nicht kürzlich geändert, wenn ich nicht entscheidendes übersehen habe.

Bob
Geschrieben von Bob am 4. Juni 2022 um 14:02

Was ist denn das Problem daran dass "veraltete" Geräte unterstützt werden? Wenn das ein Argument sein soll, verstehe ich es nicht. Genau deshalb sind ja viele Menschen auf Custom Roms angewiesen, sobald Hersteller X beschließt, dass er keine Updates mehr bereit stellt. Daher ist es doch zu begrüßen, wenn ältere Modelle von Custom Roms unterstützt werden? Was ist der Nachteil?

Vorinstallierte proprietäre Apps können deinstalliert werden. Dh, das wäre (für mich) daher kein Argument diese Custom Rom nicht in Erwägung zu ziehen.

Ja es stimmt, dass noch nicht alle Komponenten von iodé Open-Source sind. Es gibt im Forum einen kurzen Thread, in dem das thematisiert wird und "Bestreben" ausgedrückt wird, das "irgendwann" zu ändern: https://community.iode.tech/t/iode-not-open-source-why/341/12 Bei jedem Custom Rom (selbst wenn alles Open-Source ist), kann man sich nicht 100% sicher sein, ob in ein Image nicht doch auch noch schädlichen geänderten Code enthält. Auch dort muss man den Menschen, die Images bereitstellen vertrauen. Persönlich wäre mir auch 100% Open-Source lieber und ich hoffe, dass die vagen Versprechen auch noch wahr gemacht werden.

(Zu Signaturspoofing bin ich ehrlich, fehlt mir das genauere sicherheitstechnische Verständnis wie gefährlich das für Laien in der Realität wirklich ist)

n0r
Geschrieben von n0r am 5. Juni 2022 um 16:07

Wie schon im Artikel erklärt wurde, das Problem an EOL-Geräten ist, dass auch Custom ROMs die Firmware und Treiber, sofern proprietär, nicht patchen können. Ich halte es nicht für empfehlenswert, mit Mobilgeräten unterwegs zu sein, die seit Jahren ungepatchte Lücken z.B. in der Bluetoothsoftware haben.

Wenn ein Nutzer das tolerieren kann und trotz dieser Problematik Geräte ohne auch die Blobs umfassende Sicherheitspatches nutzen will, ist das ja in Ordnung. Dieser Artikel soll nur auf die Problematik hinweisen und Bewusstsein dafür schaffen, dass Custom ROMs EOL-Geräte nur in eingeschränktem Maß patchen können.

Sicher ist nichts zu 100%, auch nicht Open Source, das ist klar. Das ist für mich aber auch vor allem eine Frage der Transparenz: Ich finde das dubios, wenn eine Firma für Privatsphäre wirbt, aber nicht einmal ordentlich offenlegt, welcher Code auf den Geräten, die ihre Kunden in der Hand halten sollen, läuft.

Android besteht ja nicht nur aus deinstallierbaren Apps, sondern auch aus Systemcode. Dieser ist weder deinstallierbar noch bei iodé öffentlich einsehbar. Hier sehe ich das Problem. Transparenz geht anders. Und Transparenz ist in meinen Augen nötig.

Diese beiden Punkte klingen zunächst natürlich widersprüchlich: Ich betone sowohl, dass proprietäre Blobs gepatcht werden sollten als auch, dass iodé nicht quelloffen ist.

Der Unterschied besteht darin, dass es für iodé zahlreiche (bis auf herstellerabhängige Blobs) quelloffene Alternativen gibt, hingegen die Entwicklung quelloffener Alternativen zu von Herstellerfirmen proprietär gehaltener Hardware und dessen nötigen Blobs aber leider noch in den Kinderschuhen steckt. Ich hoffe natürlich sehr auf viele Fortschritte in Nutzbarkeit und Erhältlichkeit dort (Siehe z.B. Librem 5). Das käme sowohl der Freiheit als auch der Patchdauer des Gerätes zugute.

Schlussendlich zu der von dir angesprochenen Thematik, wie wichtig die Sicherheitsfaktoren Signature Spoofing, aber auch veraltete Blobs und weitere in der Praxis tatsächlich sind. Abschließend lässt sich das nicht pauschal beantworten, sondern unterscheidet sich je nach Gerät, Nutzungsweise und Threatmodel. Eine pauschale Antwort ist allerdings auch nicht der Zweck des Artikels. Wozu dieser Artikel dienen soll, ist darauf hinzuweisen, dass EOL-Geräte-ROMs und microG immer mehr oder minder einen Kompromiss in der Sicherheit bedeuten, was oft verschwiegen wird.

Ob diese Kompromisse nun gute Kompromisse sind (Sicherheitsverlust tolerierbar, Vorteile sehr groß) oder schlechte (Sicherheitsverlust zu hoch, Vorteile verzichtbar) muss jeder Nutzer für sich selbst abwägen. Aber überhaupt ab und zu angesprochen werden sollte das Dasein der Kompromisse in meinen Augen, weil sie oft gar nicht bekannt sind und somit gar nicht erst abgewägt wird.

Bob
Geschrieben von Bob am 15. Juni 2022 um 19:51

Danke nor für die ausführliche Antwort!

Wie Du richtig anmerkst, finden die angesprochenen Punkte in der Öffentlichkeit wenig Erwähnung und waren auch mir so nicht bewusst. Daher nochmal Danke für die zusätzlichen Erläuterungen!