App-Sicherheit

Auf dieser Seite werden verschiedene Aspekte der App-Sicherheit beschrieben.

Elemente von Apps

Android bietet eine Open-Source-Plattform und eine App-Umgebung für Mobilgeräte. Das Kernbetriebssystem basiert auf dem Linux-Kernel. Android-Apps werden meist in der Programmiersprache Java geschrieben und in der virtuellen Maschine Android Runtime (ART) ausgeführt. Apps können aber auch in nativem Code geschrieben werden. Apps werden aus einer einzelnen Datei mit der Dateiendung „.apk“ installiert.

Die wichtigsten Bausteine von Android-Apps sind:

• AndroidManifest.xml: Die Datei AndroidManifest.xml ist die Steuerdatei, die dem System mitteilt, was mit allen Komponenten der obersten Ebene (insbesondere Aktivitäten, Diensten, Broadcast-Empfängern und Contentanbietern, die unten beschrieben werden) in einer App geschehen soll. Außerdem wird angegeben, welche Berechtigungen erforderlich sind.

• Aktivitäten:Eine Aktivität ist in der Regel der Code für eine einzelne, nutzerorientierte Aufgabe, die die Klasse Activity verwendet. Eine Aktivität umfasst in der Regel die Anzeige einer Benutzeroberfläche für den Nutzer, dies ist jedoch nicht zwingend. Einige Aktivitäten zeigen nie Benutzeroberflächen an. Normalerweise ist eine der Aktivitäten der App der Einstiegspunkt in eine App.

• Dienste:Ein Dienst ist ein Code-Snippet, das im Hintergrund ausgeführt wird und auf der Klasse Service basiert. Sie kann in einem eigenen Prozess oder im Kontext des Prozesses einer anderen App ausgeführt werden. Andere Komponenten binden an einen Dienst und rufen Methoden über Remote-Prozeduraufrufe auf. Ein Beispiel für einen Dienst ist ein Mediaplayer: Auch wenn der Nutzer die Benutzeroberfläche für die Mediaauswahl schließt, möchte er wahrscheinlich, dass die Musik weiter abgespielt wird. Ein Dienst sorgt dafür, dass die Musik weiterläuft, auch wenn die Benutzeroberfläche geschlossen wurde.

• Übertragungsempfänger:Ein Übertragungsempfänger ist ein Objekt der Klasse BroadcastReceiver. Sie wird instanziiert, wenn ein IPC-Mechanismus (Inter-Process Communication) namens Intent, eine Instanz der Klasse Intent, vom Betriebssystem oder einer anderen App ausgegeben wird. Eine App kann beispielsweise einen Receiver für die Meldung „Niedriger Akkustand“ registrieren und ihr Verhalten basierend auf diesen Informationen ändern.

Android-Berechtigungsmodell: Zugriff auf geschützte APIs

Alle Apps unter Android werden in einer App-Sandbox ausgeführt. Standardmäßig kann eine Android-App nur auf eine begrenzte Anzahl von Systemressourcen zugreifen. Das System verwaltet den Zugriff von Android-Apps auf Ressourcen, die bei unsachgemäßer oder böswilliger Verwendung die Nutzerfreundlichkeit, das Netzwerk oder Daten auf dem Gerät beeinträchtigen könnten.

Diese Einschränkungen werden auf unterschiedliche Weise umgesetzt. Einige Funktionen sind durch das absichtliche Fehlen von APIs für die vertraulichen Funktionen eingeschränkt. So gibt es beispielsweise keine Android-API zum direkten Bearbeiten der SIM-Karte. In einigen Fällen bietet die Trennung von Rollen eine Sicherheitsmaßnahme, z. B. durch die Isolation des Speichers pro App. In anderen Fällen sind die sensiblen APIs für die Verwendung durch vertrauenswürdige Apps vorgesehen und durch einen Sicherheitsmechanismus namens Berechtigungen geschützt.

Zu diesen geschützten APIs gehören:

• Kamerafunktionen
• Standortdaten (GPS)
• Bluetooth-Funktionen
• Telefoniefunktionen
• SMS/MMS-Funktionen
• Netzwerk-/Datenverbindungen

Diese Ressourcen sind nur über das Betriebssystem zugänglich. Damit eine App die geschützten APIs auf dem Gerät nutzen kann, muss sie die benötigten Funktionen in ihrem Manifest definieren. Alle Android-Versionen 6.0 und höher verwenden ein Laufzeitberechtigungsmodell. Wenn ein Nutzer eine Funktion in einer App anfordert, für die eine geschützte API erforderlich ist, wird vom System ein Dialogfeld angezeigt, in dem der Nutzer aufgefordert wird, die Berechtigung zu verweigern oder zuzulassen.

Sobald die Berechtigungen erteilt wurden, gelten sie für die App, solange sie installiert ist. Um Verwirrung bei Nutzern zu vermeiden, werden sie nicht noch einmal über die Berechtigungen informiert, die der App gewährt wurden. Apps, die im Betriebssystem enthalten oder von einem OEM gebündelt sind, fordern keine Berechtigungen vom Nutzer an. Berechtigungen werden entfernt, wenn eine App deinstalliert wird. Bei einer anschließenden Neuinstallation werden die Berechtigungen wieder angezeigt.

In den Geräteeinstellungen können Nutzer Berechtigungen für Apps ansehen, die sie zuvor installiert haben. Nutzer können auch einige Funktionen global deaktivieren, z. B. GPS, Radio oder WLAN.

Wenn eine App versucht, eine geschützte Funktion zu verwenden, die nicht im Manifest der App deklariert wurde, führt der Berechtigungsfehler in der Regel dazu, dass eine Sicherheitsausnahme an die App zurückgegeben wird. Die Berechtigungsprüfungen für geschützte APIs werden auf der niedrigstmöglichen Ebene erzwungen, um eine Umgehung zu verhindern. Ein Beispiel für die Nutzerbenachrichtigung, wenn eine App installiert wird, während der Zugriff auf geschützte APIs angefordert wird, ist in Abbildung 2 zu sehen.

Die Standardberechtigungen des Systems werden unter Manifest.permission beschrieben. Apps können eigene Berechtigungen deklarieren, die von anderen Apps verwendet werden können. Diese Berechtigungen sind nicht am oben genannten Ort aufgeführt.

Wenn Sie eine Berechtigung definieren, wird mit dem Attribut „protectionLevel“ festgelegt, wie der Nutzer über Apps informiert werden soll, die die Berechtigung benötigen, oder wer eine Berechtigung erhalten darf. Details zum Erstellen und Verwenden von anwendungsspezifischen Berechtigungen finden Sie in der Sicherheitscheckliste.

Einige Gerätefunktionen, z. B. die Möglichkeit, SMS-Broadcast-Intents zu senden, sind für Drittanbieter-Apps nicht verfügbar, können aber von Apps verwendet werden, die vom OEM vorinstalliert wurden. Für diese Berechtigungen wird die Berechtigung signatureOrSystem verwendet.

Wie Nutzer Drittanbieter-Apps wahrnehmen

Android ist bestrebt, Nutzern deutlich zu machen, wann sie mit Drittanbieter-Apps interagieren, und sie über die Funktionen dieser Apps zu informieren. Vor der Installation einer App wird dem Nutzer eine deutliche Meldung mit den verschiedenen Berechtigungen angezeigt, die die App anfordert. Nach der Installation wird der Nutzer nicht noch einmal aufgefordert, Berechtigungen zu bestätigen.

Es gibt viele Gründe, warum Berechtigungen unmittelbar vor der Installation angezeigt werden sollten. In dieser Phase sehen sich Nutzer aktiv Informationen zur App, zum Entwickler und zur Funktionalität an, um festzustellen, ob sie ihren Anforderungen und Erwartungen entspricht. Außerdem ist es wichtig, dass sie noch keine mentale oder finanzielle Bindung an die App aufgebaut haben und die App leicht mit anderen alternativen Apps vergleichen können.

Einige andere Plattformen verwenden einen anderen Ansatz für die Nutzerbenachrichtigung und fordern die Berechtigung zu Beginn jeder Sitzung oder während der Nutzung von Apps an. Die Vision von Android ist, dass Nutzer nahtlos zwischen Apps wechseln können. Wenn jedes Mal eine Bestätigung erforderlich wäre, würde das den Nutzer verlangsamen und Android daran hindern, eine gute Nutzererfahrung zu bieten. Wenn der Nutzer die Berechtigungen bei der Installation prüft, hat er die Möglichkeit, die App nicht zu installieren, wenn er sich unwohl fühlt.

Außerdem hat sich in vielen Studien zur Benutzeroberfläche gezeigt, dass Nutzer, die zu oft aufgefordert werden, auf OK klicken, ohne sich den Dialog anzusehen. Eines der Sicherheitsziele von Android ist es, dem Nutzer wichtige Sicherheitsinformationen effektiv zu vermitteln. Dies ist nicht möglich, wenn Dialogfelder verwendet werden, die der Nutzer ignoriert. Wenn Sie die wichtigen Informationen nur einmal und nur dann präsentieren, wenn sie wichtig sind, ist es wahrscheinlicher, dass der Nutzer darüber nachdenkt, womit er sich einverstanden erklärt.

Auf einigen Plattformen werden überhaupt keine Informationen zur App-Funktionalität angezeigt. So können Nutzer die Funktionen der App nicht einfach nachvollziehen und darüber diskutieren. Es ist zwar nicht möglich, dass alle Nutzer immer vollständig informierte Entscheidungen treffen, aber das Android-Berechtigungsmodell macht Informationen zu Apps für eine Vielzahl von Nutzern leicht zugänglich. Unerwartete Berechtigungsanfragen können beispielsweise dazu führen, dass anspruchsvollere Nutzer kritische Fragen zur App-Funktionalität stellen und ihre Bedenken an Orten wie Google Play äußern, wo sie für alle Nutzer sichtbar sind.

Berechtigungen bei der App-Installation – Google Übersetzer	Berechtigungen einer installierten App – Gmail

Abbildung 1. Anzeige von Berechtigungen für Apps

Interprozesskommunikation

Prozesse können über die herkömmlichen Unix-Mechanismen kommunizieren. Beispiele hierfür sind das Dateisystem, lokale Sockets oder Signale. Die Linux-Berechtigungen gelten jedoch weiterhin.

Android bietet auch neue IPC-Mechanismen:

• Binder:Ein einfacher, auf Berechtigungen basierender Mechanismus für Remote-Prozeduraufrufe, der für hohe Leistung bei In-Process- und Cross-Process-Aufrufen entwickelt wurde. Binder wird mit einem benutzerdefinierten Linux-Treiber implementiert. Eine Beschreibung der Klasse finden Sie unter Binder.

• Dienste:Dienste können Schnittstellen bereitstellen, auf die direkt über Binder zugegriffen werden kann. Eine detailliertere Beschreibung finden Sie unter Elemente von Apps.

• Intents:Ein Intent ist ein einfaches Nachrichtenobjekt, das eine Absicht darstellt, etwas zu tun. Wenn Ihre App beispielsweise eine Webseite anzeigen möchte, drückt sie ihre Absicht, die URL aufzurufen, aus, indem sie eine Intent-Instanz erstellt und an das System übergibt. Das System findet einen anderen Codeabschnitt (in diesem Fall den Browser), der weiß, wie dieser Intent verarbeitet werden muss, und führt ihn aus. Intents können auch verwendet werden, um interessante Ereignisse (z. B. eine Benachrichtigung) systemweit zu übertragen. Eine Beschreibung der Klasse finden Sie unter Intent.

• Content-Provider:Ein Content-Provider ist ein Datenspeicher, der Zugriff auf Daten auf dem Gerät bietet. Das klassische Beispiel ist der Content-Provider, der für den Zugriff auf die Kontaktliste des Nutzers verwendet wird. Eine App kann auf Daten zugreifen, die von anderen Apps über einen Contentanbieter bereitgestellt werden. Außerdem kann eine App ihren eigenen Contentanbieter definieren, um eigene Daten bereitzustellen. Eine Beschreibung der Klasse finden Sie unter ContentProvider.

Es ist zwar möglich, die IPC mit anderen Mechanismen wie Netzwerksockets oder weltweit beschreibbaren Dateien zu implementieren, aber dies sind die empfohlenen Android-IPC-Frameworks. Android-Entwickler werden aufgefordert, Best Practices für den Schutz von Nutzerdaten zu verwenden und Sicherheitslücken zu vermeiden.

Kostensensitive APIs

Eine kostenpflichtige API ist jede Funktion, die Kosten für den Nutzer oder das Netzwerk verursachen kann. Auf der Android-Plattform wurden kostenintensive APIs in die Liste der geschützten APIs aufgenommen, die vom Betriebssystem gesteuert werden. Nutzer müssen Drittanbieter-Apps, die kostensensitive APIs verwenden möchten, explizit die Berechtigung dazu erteilen. Diese APIs umfassen:

• Telefonie
• SMS/MMS
• Netzwerk/Daten
• In-App-Abrechnung
• NFC-Zugriff

In Android 4.2 wurde die Steuerung der Verwendung von SMS weiter verbessert. Android zeigt eine Benachrichtigung an, wenn eine App versucht, SMS an einen Kurzcode zu senden, der Premium-Dienste verwendet, die zusätzliche Kosten verursachen können. Der Nutzer kann entscheiden, ob die App die Nachricht senden darf oder nicht.

Zugriff auf SIM-Karte

Drittanbieter-Apps haben keinen Low-Level-Zugriff auf die SIM-Karte. Das Betriebssystem übernimmt die gesamte Kommunikation mit der SIM-Karte, einschließlich des Zugriffs auf personenbezogene Daten (Kontakte) im SIM-Kartenspeicher. Apps können auch nicht auf AT-Befehle zugreifen, da diese ausschließlich von der Radio Interface Layer (RIL) verwaltet werden. Die RIL bietet keine APIs auf hoher Ebene für diese Befehle.

Personenbezogene Daten

Android hat APIs, die Zugriff auf Nutzerdaten ermöglichen, in die Gruppe der geschützten APIs aufgenommen. Bei normaler Nutzung werden auf Android-Geräten auch Nutzerdaten in von Nutzern installierten Drittanbieter-Apps gesammelt. Apps, die diese Informationen weitergeben möchten, können die Berechtigungsprüfungen des Android-Betriebssystems verwenden, um die Daten vor Drittanbieter-Apps zu schützen.

Abbildung 2: Der Zugriff auf vertrauliche Nutzerdaten ist nur über geschützte APIs möglich.

Systeminhaltsanbieter, die wahrscheinlich personenbezogene oder personenidentifizierbare Informationen wie Kontakte und Kalender enthalten, wurden mit eindeutig identifizierten Berechtigungen erstellt. Diese Granularität gibt dem Nutzer einen klaren Hinweis auf die Arten von Informationen, die der App zur Verfügung gestellt werden können. Während der Installation kann eine Drittanbieter-App die Berechtigung zum Zugriff auf diese Ressourcen anfordern. Wenn die Berechtigung erteilt wird, kann die App installiert werden und hat jederzeit Zugriff auf die angeforderten Daten, solange sie installiert ist.

Bei Apps, die personenbezogene Daten erheben, sind diese Daten standardmäßig nur für die jeweilige App verfügbar. Wenn eine App die Daten über IPC für andere Apps verfügbar macht, kann die App, die den Zugriff gewährt, Berechtigungen für den IPC-Mechanismus anwenden, die vom Betriebssystem erzwungen werden.

Eingabegeräte für sensible Daten

Android-Geräte bieten häufig sensible Dateneingabegeräte, die es Apps ermöglichen, mit der Umgebung zu interagieren, z. B. Kamera, Mikrofon oder GPS. Damit eine Drittanbieter-App auf diese Geräte zugreifen kann, muss der Nutzer ihr zuerst explizit Zugriff über Android-Berechtigungen gewähren. Bei der Installation fordert das Installationsprogramm den Nutzer auf, die Berechtigung für den Sensor nach Namen zu erteilen.

Wenn eine App den Standort des Nutzers ermitteln möchte, benötigt sie eine Berechtigung für den Zugriff auf den Standort des Nutzers. Bei der Installation wird der Nutzer gefragt, ob die App auf seinen Standort zugreifen darf. Wenn der Nutzer zu einem beliebigen Zeitpunkt nicht möchte, dass eine App auf seinen Standort zugreift, kann er die Einstellungen aufrufen, zu Standort & Sicherheit gehen und die Optionen Drahtlosnetzwerke verwenden und GPS-Satelliten aktivieren deaktivieren. Dadurch werden standortbasierte Dienste für alle Apps auf dem Gerät des Nutzers deaktiviert.

Gerätemetadaten

Android versucht auch, den Zugriff auf Daten einzuschränken, die nicht von Natur aus vertraulich sind, aber indirekt Merkmale des Nutzers, der Nutzereinstellungen und der Art und Weise, wie er ein Gerät verwendet, offenbaren können.

Standardmäßig haben Apps keinen Zugriff auf Betriebssystemprotokolle, den Browserverlauf, die Telefonnummer oder Hardware- oder Netzwerkkennungen. Wenn eine App bei der Installation Zugriff auf diese Informationen anfordert, wird der Nutzer vom Installationsprogramm gefragt, ob die App auf die Informationen zugreifen darf. Wenn der Nutzer keinen Zugriff gewährt, wird die App nicht installiert.

Zertifizierungsstellen

Android enthält eine Reihe von installierten Systemzertifizierungsstellen, die systemweit als vertrauenswürdig eingestuft werden. Vor Android 7.0 konnten Gerätehersteller die auf ihren Geräten ausgelieferten Zertifizierungsstellen ändern. Auf Geräten mit Android 7.0 und höher ist jedoch ein einheitlicher Satz von System-Zertifizierungsstellen vorhanden, da Änderungen durch Gerätehersteller nicht mehr zulässig sind.

Damit eine neue öffentliche Zertifizierungsstelle in den Android-Standardsatz aufgenommen werden kann, muss sie das Mozilla CA Inclusion Process durchlaufen und dann einen Feature Request für Android ( https://code.google.com/p/android/issues/entry) einreichen, damit die Zertifizierungsstelle dem Standard-CA-Satz von Android im Open-Source-Projekt für Android (AOSP) hinzugefügt wird.

Es gibt weiterhin Zertifizierungsstellen, die gerätespezifisch sind und nicht in den Kernsatz der AOSP-Zertifizierungsstellen aufgenommen werden sollten, z. B. die privaten Zertifizierungsstellen von Mobilfunkanbietern, die möglicherweise für den sicheren Zugriff auf Komponenten der Infrastruktur des Mobilfunkanbieters wie SMS-/MMS-Gateways erforderlich sind. Gerätehersteller werden aufgefordert, die privaten Zertifizierungsstellen nur in die Komponenten/Apps aufzunehmen, die diesen Zertifizierungsstellen vertrauen müssen. Weitere Informationen finden Sie unter Network Security Configuration.

App-Signatur

Codesignatur: Mit der Codesignatur können Entwickler den Autor der App identifizieren und ihre App aktualisieren, ohne komplizierte Schnittstellen und Berechtigungen erstellen zu müssen. Jede App, die auf der Android-Plattform ausgeführt wird, muss vom Entwickler signiert werden. Apps, die ohne Signatur installiert werden sollen, werden entweder von Google Play oder vom Paketinstaller auf dem Android-Gerät abgelehnt.

In Google Play schafft die App-Signatur Vertrauen zwischen Google und dem Entwickler sowie zwischen dem Entwickler und seiner App. Entwickler wissen, dass ihre App unverändert auf dem Android-Gerät bereitgestellt wird, und können für das Verhalten ihrer App zur Rechenschaft gezogen werden.

Unter Android ist die App-Signatur der erste Schritt, um eine App in die App-Sandbox zu verschieben. Das signierte App-Zertifikat definiert, welche Nutzer-ID welcher App zugeordnet ist. Verschiedene Apps werden unter verschiedenen Nutzer-IDs ausgeführt. Durch die App-Signierung wird sichergestellt, dass eine App nur über eine genau definierte IPC auf andere Apps zugreifen kann.

Wenn eine App (APK-Datei) auf einem Android-Gerät installiert wird, prüft der Paketmanager, ob das APK ordnungsgemäß mit dem in diesem APK enthaltenen Zertifikat signiert wurde. Wenn das Zertifikat (oder genauer gesagt der öffentliche Schlüssel im Zertifikat) mit dem Schlüssel übereinstimmt, der zum Signieren anderer APKs auf dem Gerät verwendet wurde, kann im Manifest des neuen APK angegeben werden, dass es eine UID mit den anderen ähnlich signierten APKs gemeinsam nutzt.

Apps können von einem Drittanbieter (OEM, Mobilfunkanbieter, alternativer Marktplatz) signiert werden oder selbst signiert sein. Android bietet die Codesignierung mit selbstsignierten Zertifikaten, die Entwickler ohne externe Hilfe oder Berechtigung generieren können. Apps müssen nicht von einer zentralen Behörde signiert werden. Unter Android wird derzeit keine CA-Überprüfung für App-Zertifikate durchgeführt.

Apps können auch Sicherheitsberechtigungen auf der Signaturschutzebene deklarieren, wodurch der Zugriff nur auf Apps beschränkt wird, die mit demselben Schlüssel signiert sind, während separate UIDs und Anwendungssandboxes beibehalten werden. Eine engere Beziehung mit einer gemeinsamen Application Sandbox ist über die Funktion für gemeinsame UIDs möglich. Dabei können zwei oder mehr Apps, die mit demselben Entwicklerschlüssel signiert sind, eine gemeinsame UID in ihrem Manifest deklarieren.

Anwendungsüberprüfung

Die App-Überprüfung wird ab Android 4.2 unterstützt. Nutzer können Apps überprüfen aktivieren, damit Apps vor der Installation von einem App-Prüftool bewertet werden. Die App-Überprüfung kann Nutzer warnen, wenn sie versuchen, eine potenziell schädliche App zu installieren. Wenn eine App besonders schädlich ist, kann die Installation blockiert werden.

Digitale Rechteverwaltung

Die Android-Plattform bietet ein erweiterbares DRM-Framework (Digital Rights Management, digitale Rechteverwaltung), mit dem Apps urheberrechtlich geschützte Inhalte gemäß den mit den Inhalten verknüpften Lizenzbeschränkungen verwalten können. Das DRM-Framework unterstützt viele DRM-Schemata. Welche DRM-Schemata ein Gerät unterstützt, liegt im Ermessen des Geräteherstellers.

Das Android-DRM-Framework ist in zwei Architekturebenen implementiert (siehe Abbildung 3):

• Eine DRM-Framework-API, die Apps über das Android-App-Framework zur Verfügung gestellt wird und für Standard-Apps über die ART-VM ausgeführt wird.

• Ein DRM-Manager für nativen Code, der das DRM-Framework implementiert und eine Schnittstelle für DRM-Plug-ins (Agents) bereitstellt, um die Rechteverwaltung und Entschlüsselung für verschiedene DRM-Schemata zu verarbeiten.

Abbildung 3: Architektur der digitalen Rechteverwaltung auf der Android-Plattform.