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 Verhaltens einer App 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. Unter Kernelkonfiguration finden Sie Maßnahmen, mit denen Sie den Kernel auf Ihren Geräten stärken können. 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, Nutzerressourcen 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
- Nutzer A sollte die Geräte von Nutzer B (z. B. Telefonie, GPS und Bluetooth) nicht überschreiten.
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 findest du 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 von einer App erstellte Dateien 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 (Mac) für Prozesse einzurichten. 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 verifizierte 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 KeyChain-Klasse eingeführt, damit Apps den Anmeldedatenspeicher des Systems für private Schlüssel und Zertifikatsketten nutzen können.
Rooting 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 Bootmodus verhindert, dass ein Nutzer oder Dienst mit Root-Berechtigungen das Betriebssystem dauerhaft ä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 haben Nutzer die Möglichkeit, den Bootloader zu entsperren, um die Installation eines alternativen Betriebssystems zu ermöglichen. Mit diesen alternativen Betriebssystemen kann ein Inhaber Root-Zugriff erhalten, um Fehler in Apps und Systemkomponenten zu beheben oder auf Funktionen zuzugreifen, die Apps von Android-APIs nicht 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 durch Verschlüsselung mit einem extern gespeicherten Schlüssel, z. B. auf einem Server oder einem Nutzerpasswort, eine zusätzliche Datenschutzebene hinzufügen. Dieser Ansatz kann 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 in Android ist die dateibasierte Verschlüsselung in Kombination mit der Metadatenverschlüsselung. 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 noch nicht durch die dateibasierte Verschlüsselung verschlüsselt wurden. 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 vorschreiben.
Geräteverwaltung
Android 2.2 und höher bieten die Android Device Administration API, die Funktionen zur Geräteverwaltung auf Systemebene bietet. Beispielsweise verwendet die in Android integrierte E-Mail-App die APIs, um die Exchange-Unterstützung zu verbessern. Über die E-Mail-App können Exchange-Administratoren Richtlinien für Anmeldedaten auf dem Sperrbildschirm – einschließlich alphanumerischer Passwörter oder numerischer PINs – geräteübergreifend erzwingen. Administratoren können verloren gegangene oder gestohlene Mobilgeräte auch per Fernzugriff auf die Werkseinstellungen zurücksetzen (d. h. die Werkseinstellungen wiederherstellen).
Diese APIs können nicht nur in Apps verwendet werden, die im Android-System enthalten sind, sondern stehen auch Drittanbietern von Geräteverwaltungslösungen zur Verfügung. Weitere Informationen zur API finden Sie unter Geräteverwaltung.