Auf Betriebssystemebene bietet die Android-Plattform die Sicherheit des Linux-Kernels sowie eine sichere Inter-Process-Communication (IPC), um eine sichere Kommunikation zwischen Apps zu ermöglichen, die in verschiedenen Prozessen ausgeführt werden. Diese Sicherheitsfunktionen auf Betriebssystemebene sorgen dafür, dass auch nativer Code durch die Anwendungs-Sandbox eingeschränkt wird. Unabhängig davon, ob dieser Code aufgrund des App-Verhaltens oder der Ausnutzung einer App-Sicherheitslücke vorhanden ist, soll das System verhindern, dass die schädliche App anderen Apps, dem Android-System oder dem Gerät selbst schadet. Die erforderlichen Einstellungen finden Sie im Android Compatibility Definition Document (CDD).
Linux-Sicherheit
Die Grundlage der Android-Plattform ist der Linux-Kernel. Der Linux-Kernel wird seit Jahren in Millionen von sicherheitssensiblen Umgebungen eingesetzt. Da Linux ständig von Tausenden von Entwicklern untersucht, angegriffen und behoben wird, ist es zu einem stabilen und sicheren Kernel geworden, dem viele Unternehmen und Sicherheitsexperten vertrauen.
Als Grundlage für eine mobile Computing-Umgebung bietet der Linux-Kernel Android mehrere wichtige Sicherheitsfunktionen, darunter:
- Ein nutzerbasiertes Berechtigungsmodell
- Prozessisolierung
- Erweiterbarer Mechanismus für sichere IPC
- Die Möglichkeit, unnötige und potenziell unsichere Teile des Kernels zu entfernen
Als Mehrbenutzer-Betriebssystem besteht ein grundlegendes Sicherheitsziel des Linux-Kernels darin, Nutzerressourcen voneinander zu isolieren. Die Linux-Sicherheitsphilosophie besteht darin, die Ressourcen der Nutzer voreinander zu schützen. Linux:
- Verhindert, dass Nutzer A die Dateien von Nutzer B lesen kann
- Verhindert, dass Nutzer A den Arbeitsspeicher von Nutzer B vollständig belegt
- Verhindert, dass Nutzer A die CPU-Ressourcen von Nutzer B erschöpft
- Verhindert, dass Nutzer A die Geräte von Nutzer B überlastet (z. B. Telefonie, GPS und Bluetooth)
Anwendungs-Sandbox
Die App-Sicherheit von Android wird durch die Anwendungs-Sandbox erzwungen, die Apps voneinander isoliert und Apps und das System vor schädlichen Apps schützt. Weitere Informationen finden Sie unter Anwendungs-Sandbox.
Systempartition und abgesicherter Modus
Die verschiedenen vor Integritätsverletzungen geschützten Partitionen enthalten den Android-Kernel sowie die Betriebssystembibliotheken, die App-Laufzeit, das App-Framework und die Apps. Diese Partition ist schreibgeschützt. Wenn ein Nutzer das Gerät im abgesicherten Modus startet, können Drittanbieter-Apps vom Geräteeigentümer manuell gestartet werden, werden aber nicht standardmäßig gestartet.
Dateisystemberechtigungen
In einer UNIX-ähnlichen Umgebung sorgen Dateisystemberechtigungen dafür, dass ein Nutzer die Dateien eines anderen Nutzers nicht ändern oder lesen kann. Unter Android wird jede App als eigener Nutzer ausgeführt. Sofern der Entwickler Dateien nicht ausdrücklich für andere Apps freigibt, können Dateien, die von einer App erstellt wurden, nicht von einer anderen App gelesen oder geändert werden.
Security-Enhanced Linux
Android verwendet Security-Enhanced Linux (SELinux), um Zugriffssteuerungsrichtlinien anzuwenden und eine obligatorische Zugriffssteuerung (Mandatory Access Control, MAC) für Prozesse festzulegen. Weitere Informationen finden Sie unter Security-Enhanced Linux in Android.
Verified Boot
Android 7.0 und höher unterstützen den strikt erzwungenen Verified Boot. Das bedeutet, dass manipulierte Geräte nicht gestartet werden können. Der abgesicherte Bootmodus garantiert die Integrität der Gerätesoftware vom Hardware Root of Trust bis zur Systempartition. Während des Starts wird in jeder Phase die Integrität und Authentizität der nächsten Phase kryptografisch geprüft, bevor sie ausgeführt wird.
Weitere Informationen finden Sie unter Verifizierter Start.
Kryptografie
Android bietet eine Reihe kryptografischer APIs zur Verwendung durch Apps. Dazu gehören Implementierungen von standardmäßigen und gängigen kryptografischen Primitiven wie AES, RSA, DSA und SHA. Außerdem werden APIs für Protokolle der höheren Ebene wie SSL und HTTPS bereitgestellt.
Mit Android 4.0 wurde die Klasse KeyChain eingeführt, damit Apps den Anmeldedatenspeicher des Systems für private Schlüssel und Zertifikatsketten verwenden können.
Rooten des Geräts
Standardmäßig werden unter Android nur der Kernel und ein kleiner Teil der Kerndienste mit Root-Berechtigungen ausgeführt. SELinux schränkt weiterhin Prozesse im Nutzerbereich ein, die als Root ausgeführt werden. Der verifizierte Boot verhindert, dass ein Nutzer oder Dienst mit Root-Berechtigungen das Betriebssystem dauerhaft verändert.
Die Möglichkeit, ein eigenes Android-Gerät zu modifizieren, ist für Entwickler, die mit der Android-Plattform arbeiten, wichtig. Auf vielen Android-Geräten können Nutzer den Bootloader entsperren, um die Installation eines alternativen Betriebssystems zu ermöglichen. Mit diesen alternativen Betriebssystemen kann ein Eigentümer Root-Zugriff erhalten, um Apps und Systemkomponenten zu debuggen oder auf Funktionen zuzugreifen, die Apps nicht über Android APIs zur Verfügung gestellt werden.
Bei einigen Geräten kann eine Person, die physischen Zugriff auf ein Gerät und ein USB-Kabel hat, ein neues Betriebssystem installieren, das dem Nutzer Root-Berechtigungen gewährt. Um vorhandene Nutzerdaten vor Manipulationen zu schützen, muss der Bootloader im Rahmen des Entsperrvorgangs alle vorhandenen Nutzerdaten löschen. Ein Root-Zugriff, der durch Ausnutzung eines Kernel-Fehlers oder einer Sicherheitslücke erlangt wurde, kann diesen Schutz umgehen.
Die Verschlüsselung von Daten mit einem auf dem Gerät gespeicherten Schlüssel schützt die App-Daten nicht vor Root-Nutzern auf gerooteten Geräten. Apps können eine zusätzliche Datensicherheitsebene durch Verschlüsselung mit einem außerhalb des Geräts gespeicherten Schlüssel bieten, z. B. auf einem Server oder mit einem Nutzerpasswort. Dieser Ansatz kann einen vorübergehenden Schutz bieten, solange der Schlüssel nicht vorhanden ist. Irgendwann muss der Schlüssel jedoch der App zur Verfügung gestellt werden, wodurch Root-Nutzer darauf zugreifen können.
Ein robusterer Ansatz zum Schutz von Daten vor Root-Nutzern ist die Verwendung von Hardwarelösungen. OEMs können Hardwarelösungen implementieren, die den Zugriff auf bestimmte Arten von Inhalten einschränken, z. B. DRM für die Videowiedergabe oder den NFC-basierten vertrauenswürdigen Speicher für Google Wallet. Bei einem verlorenen oder gestohlenen Gerät sorgt die Speicherverschlüsselung dafür, dass ohne Kenntnis der Anmeldedaten des Nutzers nicht auf seine Nutzerdaten zugegriffen werden kann.
Sicherheitsfunktionen für Nutzer
Speicherverschlüsselung
Gemäß dem CDD müssen alle Geräte, die mit Android 10 oder höher ausgeliefert werden, und die meisten Geräte, die mit Android 6.0 oder höher ausgeliefert werden, die Speicherverschlüsselung standardmäßig aktivieren.
Die aktuelle Implementierung der Speicherverschlüsselung von Android ist die dateibasierte Verschlüsselung in Kombination mit der Verschlüsselung von Metadaten. Bei der dateibasierten Verschlüsselung werden Dateiinhalte und ‑namen auf der Benutzerdatenpartition transparent verschlüsselt. Dabei werden für verschiedene Verzeichnisse unterschiedliche Schlüssel verwendet. Es bietet für jeden Nutzer Anmeldedaten- und geräteverschlüsselte Speicherverzeichnisse, einschließlich Arbeitsprofilen.
Die Metadatenverschlüsselung ergänzt die dateibasierte Verschlüsselung. Dabei werden alle Blöcke auf der userdata-Partition verschlüsselt, die nicht bereits durch die dateibasierte Verschlüsselung verschlüsselt sind. Dazu wird ein Schlüssel verwendet, der nicht an die Anmeldedaten eines Nutzers für den Sperrbildschirm gebunden ist, aber dennoch durch Verified Boot geschützt ist.
Schutz von Anmeldedaten auf dem Sperrbildschirm
Android kann so konfiguriert werden, dass Anmeldedaten für den Sperrbildschirm (PIN, Passwort oder Muster) von Nutzern überprüft werden, bevor der Zugriff auf ein Gerät gewährt wird. Die Anmeldedaten für den Sperrbildschirm verhindern nicht nur die unbefugte Nutzung des Geräts, sondern schützen auch den kryptografischen Schlüssel für mit Anmeldedaten verschlüsselte Daten. Ein Geräteadministrator kann die Verwendung von Anmeldedaten für den Sperrbildschirm und/oder Regeln zur Komplexität von Anmeldedaten erzwingen.
Geräteverwaltung
Android 2.2 und höher bieten die Android Device Administration API, die Funktionen zur Geräteverwaltung auf Systemebene bietet. Beispielsweise werden die APIs in der integrierten E-Mail-App von Android verwendet, um die Exchange-Unterstützung zu verbessern. Über die E-Mail-App können Exchange-Administratoren Anmeldedatenrichtlinien für den Sperrbildschirm – einschließlich alphanumerischer Passwörter oder numerischer PINs – auf allen Geräten erzwingen. Administratoren können verlorene oder gestohlene Smartphones auch aus der Ferne löschen, d. h. auf die Werkseinstellungen zurücksetzen.
Diese APIs können nicht nur in Apps verwendet werden, die im Android-System enthalten sind, sondern auch von Drittanbietern von Geräteverwaltungslösungen. Weitere Informationen zur API finden Sie unter Geräteverwaltung.