Mobile · 19. Mai 2015 0

Android Sicherheit

Android unterscheidet sich zu Apples iOS dahingehend, dass die Hardware nicht vom selben Anbieter kommt. Durch die Anpassung von Android durch die Hardware Hersteller dauert es länger, bis Updates oder neue Versionen ihren Weg auf das Gerät finden. Zudem bleibt es den Herstellern vorbehalten, welche Versionen sie ausliefern. Ein weiterer Unterschied ist die Implementierung einer externen Speicherkarte, die es unter iOS nicht gibt. Zudem fehlen die Krypto Engine und die hardwareseitig verbauten Geräteschlüssel. Die mit Android 5.0 (Android L) ausgelieferten Geräte sind standardmäßig verschlüsseltet. Android selbst bietet zudem auch Sicherheitsmechanismen an, wie sie von iOS oder Linux/Unix bekannt ist.

Bootvorgang
Nach dem Einschalten eines Android Gerätes wird der Code im Boot-ROM ausgeführt, der die Geräte Hardware initialisiert. Nach der erfolgreichen Initialisierung wird der Code des Bootloader aus dem Flash Speicher des Bootmediums in den Hauptspeicher geladen und anschließend von dort aus ausgeführt. Dieser Code ist an die vom Gerät genutzte CPU angepasst. Damit ähnelt der Bootvorgang den eines Windows, Mac OS X oder Linux Computers. Der Bootloader durchläuft nun zwei Phasen: In der ersten Phase sorgt der Initial Program Loader (IPL) für die Erkennung und Einrichtung des externen Hauptspeichers. Nach der Vorbereitung kopiert der IPL in der zweiten Phase den Second Program Loader (SPL), der nun für das Laden des Betriebssystems (Linux-Kernel) sowie auch für den Zugriff auf die alternativen Bootmethoden, wie Recovery, Debugging, Aktualisierung oder die Wartung des Gerätes verantwortlich ist. Dieser SPL wird in der Regel von den Geräteherstellern zur Verfügung gestellt und übergibt die Kontrolle nun an den Linux-Kernel, der die weitere Einrichtung des Gerätes übernimmt. Sind diese abgeschlossen, wird das root-Dateisystem aus dem Flash Speicher gelesen, umso den Zugriff auf das System und die Anwenderdaten zu erhalten. Als Nächstes erfolgt der Init-Prozess. Besitzt der Linux-Kernel Zugriff auf die Systempartition, können die Init-Skripte geladen sowie die Schlüsselprozesse des Systems und der Anwendersoftware gestartet werden. Vergleichen lässt sich dies mit dem unter Linux-Systemen verwendeten /etc/init.d Skripten. Weiter wird die Zygote-Sequenz geladen, welche sich um die Konfiguration der Java Laufzeitumgebung kümmert, damit neue gestartete Apps eine neue Dalvik-VM bzw. Android-Runtime anfordern können. Ohne Zygote ist die Ausführung von Apps nicht möglich, das betrifft auch die mit Android ausgelieferten Apps, wie Telefon oder Browser. Nachdem Zygote fertig geladen wurde, folgt nun der letzte Prozess des Bootvorgangs, indem der System-Server gestartet wird. Der System-Server ist für Kernfunktionalitäten verantwortlich, wie z.B. Telefonie, Netzwerk und andere grundlegende Komponenten. Ist dieser abgeschlossen, sendet er dem System einen Standard Broadcast namens ACTION_BOOT_COMPLETED, so dass das Android System nun voll funktionsfähig ist.

Signatur der App
Alle Android Apps müssen durch ihre Entwickler, einschließlich der System Apps, signiert werden. Android APK-Dateien sind eine Erweiterung des Java JAR Paketformats, wodurch die Codesignierung auch auf der Grundlage von JAR-Dateien basiert. Android verwendet die Signatur auch zum Sicherstellen, dass ein Update einer App auch vom selben Entwickler stammt, indem es beide Zertifikate vergleicht. System Apps werden durch Plattform Schlüssel signiert, welche vom Betreiber der Android Version generiert und kontrolliert werden und können erhöhte Rechte besitzen. Betreiber können hierbei Gerätehersteller, aber auch Hersteller von Google Nexus Geräten sein. Die Codesignierung stellt zwei Sachen sicher: Erstens, dass der Code nicht manipuliert wurde und zweitens, dass die Signatur gültig ist. Das dem Entwickler auch vertraut werden kann, stellt die Codesignierung nicht sicher. Das Zertifikat kann entweder von einer öffentlichen Zertifizierungsstelle kommen, oder aber selbst signiert werden, womit es sich von Apple unterscheidet. Sobald eine App im Google Play Store hochgeladen wurde, wird diese vom Google Bouncer, einer virtuellen Umgebung, auf ihre Sicherheit überprüft, jedoch nicht weiter signiert. Ein Entwickler muss sein Zertifikat gut aufbewahren, um es vor Missbrauch zu schützen.

Sandbox
Auch unter Android werden die Daten von Apps und zugehörige Benutzerprozesse separiert und können nicht auf die Daten anderer Apps zugreifen. Dazu wird einer App eine eigene Benutzerkennung (User ID) vergeben, unter der sie im System registriert ist. Hier wurde das von Unix-Systemen bekannte Sicherheitskonzept „Kernel Level Application Sandbox“ übernommen. Seit Android 4.3 und der Implementierung von Security Enhanced Linux (SELinux) wurde die Linux Kernel-API um eine detailliertere Zugriffskontrolle erweitert. Jede in Java geschriebene App bekommt ihren eigenen Zugriff auf Systemressourcen durch APIs und zudem ihre eigene Laufzeitumgebung (Dalvik VM oder ART), die im Benutzerkontext ausgeführt wird. Vorinstallierte Apps werden auf der Systempartition installiert, die im laufenden Betrieb nur als lesend eingebunden ist, während nachinstallierte Apps auf einer Datenpartition liegen. Diese kann entweder der interne Flash Speicher sein, oder wenn vorhanden auch ein externen Flash Speicher in Form einer SD-Karte. Bevor jedoch eine App installiert werden kann, muss der Benutzer dieser App Berechtigungen über einen Berechtigungsdialog erteilen. Sollte der Benutzer diesen nicht zustimmen, wird die App auch nicht installiert. Zudem besteht keine Möglichkeit, im Gegensatz zu iOS, im Nachhinein einer App Rechte zu entziehen. Schutzmechanismen wie ASLR kommen unter Android ebenso zum Einsatz wie unter iOS.

Verschlüsselung
Geräte, bei denen Android 5.0 (Android L) vorinstalliert ist, ist die Verschlüsselung des internen Speichers standardmäßig aktiviert, bei älteren Versionen ist dies nicht der Fall. Hier muss die Verschlüsselung entweder manuell aktiviert werden oder sie ist schlichtweg nicht möglich. Erst mit Android 3.0 wurde dies implementiert. Ist das Gerät verschlüsselt, gibt es bei einigen Geräteherstellern nur einen Weg zurück, indem man das Gerät auf den Auslieferungszustand zurücksetzt, wobei alle Daten auf dem Gerät unwiderruflich gelöscht werden. Verschlüsselt sind die Daten nur im gesperrten oder ausgeschalteten Gerätezustand. Hat ein Angreifer das Passwort oder die Möglichkeit Codes auszuführen, sieht er die Daten wie im unverschlüsselten Zustand. Verschlüsselt bedeutet, dass ein Großteil des internen Speichers ohne passenden Schlüssel (AES 128-bit) unzugänglich ist. Jedoch bleibt ein Teil unverschlüsselt, um von diesem Bereich aus starten zu können. Dieser Bereich enthält die Start- und Systempartition, aber auch den Entschlüsselungsschlüssel, der wiederum verschlüsselt abgespeichert ist. Externe Speichermedien sind davon nicht betroffen, können jedoch separat verschlüsselt werden.