Systemli Wiki

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== Infos zur (Geräte-)Sicherheit von google-freien Androids ======

Diese Seite sammelt einige Überlegungen zu Sicherheit und Nutzbarkeit bei der Auswahl des passenden Gerätes für ein google-freies Android-Smartphone.
===== Hintergrund-Infos =====

==== Alternative Android-Betriebssysteme ====

Das //Android Open Source Project// (AOSP) ist ein freies und quelloffenes Betriebssystem. Zwar wird es maßgeblich von Google entwickelt, der Quellcode steht allerdings allen Menschen zur Inspektion und Veränderung bereit. Die meisten Smartphone-Hersteller vertreiben auf ihren Geräte leicht modifizierte Androids, auf denen in der Regel die Standard-Apps von Google oder je nach Hersteller auch andere Apps vorinstalliert sind (z.B. haben Samsung-Geräte einen eigenen App-Store vorinstalliert)

Prinzipiell steht es allen offen, eigene Änderungen beizusteuern oder eine eigene, modifizierte Version von Android zu veröffentlichen. Über die Zeit sind einige Projekte und Communities entstanden, die sich die Entwicklung und Wartung Google-freier Android-Betriebssysteme ("//Custom-ROMs//") zur Aufgabe machen.


==== Sicherheitsupdates für Android ====

Wie bei jeder anderen Software können auch beim Android-Betriebssystem Sicherheitslücken entdeckt werden. In der Regel werden sie bei Bekanntwerden so schnell wie möglich durch die Entwickler:innen von Google geschlossen und Updates zur Verfügung gestellt.

Da viele Smartphone-Hersteller ihre Geräte mit modifizierten Versionen von Android ausliefern, müssen sie  diese die Sicherheitsupdates zunächst in ihren eigenen Android-Varianten einspielen, bevor diese bei den Nutzer:innen landen. Auch die Betreuer:innen alternativer Android-Betriebssysteme müssen sich um das einspielen dieser Updates in ihre eigene Android-Version kümmern.

Für die verschiedenen Android-Versionen gibt es dabei unterschiedliche Support-Zeiträume. Während die neueste Version, Android 11 (Stand 2020) sicher noch einige Jahre mit Sicherheitsupdates versorgen werden wird, hat Google z.B. den Support für Android 7 Ende 2019 eingestellt.

<note tip>Auf https://endoflife.date/android gibt es eine ausführliche Übersicht, welche Android-Versionen noch Sicherheitsupdates erhalten.</note>

Durch alternative Betriebssysteme ist es möglich, ältere Telefone, die von ihren Herstellern längst nicht mehr auf sichere Android-Versionen aktualisiert werden, wieder sicher benutzen zu können. Es gibt allerdings auch //Custom-ROMs//, die selbst noch auf veralteten Android-Versionen basieren. Bei solchen Custom-ROMs ist Vorsicht geboten: Zwar können deren Entwickler:innen die Verantwortung dafür übernehmen, beim Bekanntwerden von Sicherheitslücken ihre Custom-ROM zu patchen. Allerdings stehen einem kleines Team unabhängiger Entwickler:innen, die in der Regel in ihrer Freizeit eine Custom-ROM betreuen, ganz andere Ressourcen zur Verfügung als Google.

==== Sicherheitsupdates für Firmware ====

Neben den Updates für das Android-Betriebssystem spielt die //Firmware// des Gerätes eine Rolle. Mit //Firmware// sind Gerätetreiber gemeint, die für die Funktionalität der Hardware benötigt werden. Beispielsweise Treiber für den WLAN-Chip, den Prozessor, oder das Bluetooth-Modul.

Diese Firmware ist in der Regel aber nicht quelloffen, deswegen kann hier //nur// der Hersteller der jeweiligen Hardware Updates für Sicherheitslücken schreiben und zur Verfügung stellen. Über den offiziellen Support-Zeitraum hinaus stellen die meisten Hersteller keine Sicherheitsupdates bereit, und selbst da, wo es offiziell Support gibt, sind Hersteller oft nachlässig.

Dadurch wird veraltete Firmware zu einer sehr großen Schwachstelle in der Sicherheit von Android-Geräten: Selbst wenn man, etwa durch Installation einer Custom-ROM, ein Gerät mit einem sicheren Betriebssystem ausstatten kann, bleibt die Sicherheit der Firmware vor allem von älteren Geräten ungewiss.

<note tip>LineageOS-Nutzer:innen können mithilfe der **[[https://www.xda-developers.com/lineageos-trust-centralized-interface-security-privacy|Trust]]**-App unter ''Einstellungen -> Datenschutz -> Trust'' überprüfen ob Firmware und Betriebssystem aktuell sind. </note>

==== microG und "Signature Spoofing" ====

Manche praktische Funktionen von Android-Smartphones sind nicht bereits im quell-offenen AOSP enthalten, sondern in den Google-Play-Services implementiert. Wer also ein googlefreies Android-System installiert, könnte manche dieser Funktionen vermissen, zum Beispiel die Batterie-schonende Ortungsfunktion mithilfe von Mobilfunk und Wifi anstatt mit GPS oder die Contact-Tracing-Schnittstelle die benötigt wird um Contact-Tracing-Apps wie die Corona-Warn-App zu benutzen.

Eine Alternative zu den Google-Play-Services ist //[[https://microg.org/|microG]]//. Das ist ein OpenSource-Projekt, dass einige Funktionen der Google-Play-Services privatsphäre-freundlich implementiert und sich gegenüber anderen Apps als Google-App ausgibt. Für wenige der bereitgestellten Funktionen ist aber weiterhin der Login in einen Google-Account erforderlich, das ist aber optional.

Die Sicherheit von microG ist ein Streitthema unter Android-Entwickler:innen: Um sich als Google-Play-Services ausgeben zu können, muss das Betriebssystem das Vortäuschen einer Signatur (“signature spoofing”) erlauben. Manche halten das für ein unnötiges Sicherheitsrisiko, es könnte sich ja schlimmstenfalls eine bösartige App als eine andere App ausgeben. Die Entwickler:innen von microG schätzen das als unwahrscheinlich ein, da das Vortäuschen einer Signatur nicht von irgendwelchen Apps eingefordert werden kann, sondern aktive Zustimmung des Geräteadministrators erfordert.

<note tip>Um die [[https://www.coronawarn.app/de/|Corona-Warn-App des Robert-Koch-Institutes]] zu benutzen sind Google-Play-Services oder alternativ microG nicht mehr nötig. Mit [[https://f-droid.org/packages/de.corona.tracing/|Corona Contact Tracing Germany]] steht bei FDroid ein Fork der Corona-Warn-App zur Verfügung, bei dem die nötige Contact-Tracing-Schnittstelle direkt in der App selbst eingebaut ist.</note>

==== Bootloader-Entsperrung ====

Der Bootloader ist ein kleines Stück Software, das dafür zuständig ist beim Einschalten das installierte Betriebssystem zu starten. Um auf einem Gerät ein alternatives Betriebssystem zu installieren, ist es in der Regel nötig den Bootloader dafür zu entsperren. Die Entsperrung ist nicht vor dem Boot möglich, sondern erst nachdem man das Telefon gestartet hat, kann nach Eingabe der PIN die Entsperrung in den Systemeinstellungen erlaubt werden werden. 

Aus Sicherheitsgründen wird das installierte Betriebssystem bei einer Entsperrung des Bootloaders auf Werkseinstellungen zurückgesetzt und der Speicher geleert, um zu verhindern dass jemand mit physischem Zugriff auf ein Smartphone die Passwortsperre des Betriebssystem umgeht und sich über den Bootloader Zugriff auf persönliche Daten verschafft.

<note important>Nur manche Geräte erlauben es, den Bootloader nach erfolgreicher Installation eines alternativen Betriebssystems wieder zu sperren. Ein entsperrter Bootloader hinterlässt ein Gerät mit einer Sicherheitslücke: Da der Bootloader bereits entsperrt ist, könnte jemand mit physischem Zugriff auf das Gerät unbemerkt zusätzliche (Schad-)Software auf dem Gerät installieren. Auch ein sogenannter //[[https://de.wikipedia.org/wiki/Kaltstartattacke|Cold Boot Attack]]// ist denkbar: Mit diesem kann die Geräteverschlüsselung eines eingeschalteten aber gesperrten Gerätes potenziell umgangen werden.</note>

==== Verifizierter Boot ====

Bei moderneren Smartphones hat der Bootloader zusätzlich die Aufgabe, das für den Start vorgesehene Betriebssystem auf seine Integrität und Echtheit zu überprüfen. So soll ausgeschlossen werden, dass die Kernfunktionen des Betriebssystems seit Auslieferung manipuliert oder beschädigt wurden. Für diese Prüfung ist das Betriebssystem vom Hersteller mit einer kryptografischen Signatur gekennzeichnet. Der Bootloader überprüft, ob die Signatur übereinstimmt ist und vom Hersteller stammt.

Der verifizierte Boot als Sicherheitsfeature des ausgelieferten Betriebssystems geht bei der Installation eines alternativen Betriebssystems meistens verloren. Nur wenige Geräte unterstützen sowohl das Sperren des Bootloaders als auch die Wiederherstellung des verifizierten Bootvorgangs mit einem alternativen Betriebssystem. 

Es gibt eine [[https://hub.libranet.de/wiki/and-priv-sec/wiki/verified-boot|Übersicht]], welche Geräte einen verifizierten Bootvorgang (zu welchem Grad) unterstützen.

==== Hardware-basierte Limitierung von PIN-Eingaben ====

Insbesondere Smartphones stehen vor dem Problem, dass wirklich sichere Passwörter für einen Touch-Display in der Regel zu lang wären und sich nicht leicht merken lassen. Jemand mit unbefugtem Zugriff auf das Gerät ist allerdings nicht auf das unhandliche Touch-Display und eine Limitierung von PIN-Eingaben durch das Display beschränkt, sondern könnte den Speicher des Gerätes einfach auf eine Festplatte übertragen und die PIN-Eingaben automatisiert, mit vielen Tausend PIN-Kombinationen pro Minute, von einem anderen Computer aus durchführen. Diese Methode, um an den Inhalt eines verschlüsselten Datenträgers zu gelangen, nennt sich "Brute Force" (eng,: Rohe Gewalt).

Aus diesem Grund sind mittlerweile viele Smartphones mit einem Hardware-Chip ausgestattet, der diese Art von Angriff erschweren soll. Dieser Hardware-Chip ist an ein spezifisches Gerät gebunden und so beschaffen, dass seine interne Informationen nicht einfach ausgelesen oder kopiert werden können. Bei der Geräteverschlüsselung mit einem solchen Hardware-Chip wird das kryptografische Geheimnis, also der Schlüssel, mit dem der Speicher verschlüsselt ist, sozusagen zweigeteilt: Der eine Schlüssel ist der PIN, den man zum Entsperren benutzt. Der andere Schlüssel ist im Chip versteckt, und wird nur freigegeben, wenn der eingegebene PIN korrekt ist. Eine Angreiferin könnte den Speicher eines derart verschlüsselten Smartphones zwar auf eine andere Festplatte kopieren, würde aber dabei mit dem Hardware-Chip den zweiten Schlüssel für die Entschlüsselung verlieren: Selbst mit unendlich vielen Versuchen wäre eine Entschlüsselung also nicht mehr möglich. Der Chip kann auch so konfiguriert sein, sich ab einer bestimmten Anzahl von Fehlversuchen selbst zu leeren, und dadurch unwiederbringlich den Schlüssel zu löschen.

Smartphones, die über eine Hardware-basierte Limitierung von PIN-Eingaben verfügen, sind in der Theorie besser gegen Datendiebstahl durch 'Brute Force' geschützt. Gleichzeitig ist ein solcher Hardware-Chip kein Wundermittel, sondern eine sehr komplexe und von Menschen gemachte Technologie, deren Konzeption oder Implementation potenziell Sicherheitslücken aufweisen könnte. Zudem sind sie in aller Regel //proprietär//, d.h. Quellcode oder Design der Chips ist nicht öffentlich einsehbar oder überprüfbar. Zudem schützt eine limitierte PIN-Eingabe nur gegen 'Brute Force'-Angriffe, und nicht schlechte Passwörter, die sich aus der Biografie vermuten lassen (z.B. Geburtsdaten oder Namen).