App-Sicherheit

Elemente von Apps

Android bietet eine Open-Source-Plattform und App-Umgebung für Mobilgeräte. Das Kernbetriebssystem basiert auf dem Linux-Kernel. Android-Apps werden am häufigsten 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 über eine einzelne Datei mit der Dateiendung „APK“ installiert.

Die Hauptbausteine einer Android-App sind:

  • AndroidManifest.xml: Die AndroidManifest.xml-Datei ist die Steuerdatei, die dem System mitteilt, was mit allen Komponenten der obersten Ebene (insbesondere Aktivitäten, Dienste, Übertragungsempfänger und Inhaltsanbieter, die unten beschrieben werden) in einer App zu tun ist. Außerdem wird hier angegeben, welche Berechtigungen erforderlich sind.

  • Aktivitäten: Eine Aktivität ist in der Regel der Code für eine einzelne, nutzerorientierte Aufgabe mit der Klasse Activity. Eine Aktivität umfasst in der Regel die Anzeige einer Benutzeroberfläche für den Nutzer, muss dies aber nicht. Bei einigen Aktivitäten wird nie eine Benutzeroberfläche angezeigt. In der Regel ist eine der App-Aktivitäten der Einstiegspunkt in die App.

  • Dienste: Ein Dienst ist ein Code-Snippet, das im Hintergrund ausgeführt wird. Sie kann in einem eigenen Prozess oder im Kontext des Prozesses einer anderen App ausgeführt werden. Andere Komponenten „binden“ sich an einen Dienst und rufen Methoden über Remote Procedure Calls darauf auf. Ein Beispiel für einen Dienst ist ein Mediaplayer: Auch wenn der Nutzer die Benutzeroberfläche für die Medienauswahl verlässt, möchte er wahrscheinlich, dass die Musik weiter abgespielt wird. Ein Dienst sorgt dafür, dass die Musik auch dann weiter abgespielt wird, wenn die Benutzeroberfläche nicht mehr angezeigt wird.

  • Broadcast-Empfänger: Ein BroadcastReceiver ist ein Objekt, das instanziiert wird, wenn ein IPC-Mechanismus, der als Intent bezeichnet wird, vom Betriebssystem oder einer anderen App ausgegeben wird. Eine App kann beispielsweise einen Empfänger für die Meldung „Akkustand niedrig“ registrieren und ihr Verhalten basierend auf diesen Informationen ändern.

Android-Berechtigungsmodell: Zugriff auf geschützte APIs

Alle Apps auf Android werden in einer Anwendungs-Sandbox ausgeführt. Standardmäßig kann eine Android-App nur auf einen begrenzten Bereich von Systemressourcen zugreifen. Das System verwaltet den Zugriff von Android-Apps auf Ressourcen, die sich bei falscher oder böswilliger Verwendung negativ auf die Nutzerfreundlichkeit, das Netzwerk oder die Daten auf dem Gerät auswirken können.

Diese Einschränkungen werden in verschiedenen Formen implementiert. Einige Funktionen sind aufgrund des bewussten Fehlens von APIs für vertrauliche Funktionen eingeschränkt. So gibt es beispielsweise keine Android API zum direkten Bearbeiten der SIM-Karte. In einigen Fällen ist die Rollentrennung eine Sicherheitsmaßnahme, z. B. bei der App-spezifischen Speicherisolierung. In anderen Fällen sind die sensiblen APIs für die Verwendung durch vertrauenswürdige Apps vorgesehen und werden durch einen Sicherheitsmechanismus namens Berechtigungen geschützt.

Zu diesen geschützten APIs gehören:

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

Auf diese Ressourcen kann nur über das Betriebssystem zugegriffen werden. Wenn eine App die geschützten APIs auf dem Gerät verwenden möchte, muss sie die erforderlichen Funktionen in ihrem Manifest definieren. Alle Android-Versionen ab 6.0 verwenden ein Modell für Laufzeitberechtigungen. Wenn ein Nutzer eine Funktion von einer App anfordert, für die eine geschützte API erforderlich ist, wird ein Dialogfeld angezeigt, in dem der Nutzer aufgefordert wird, die Berechtigung zu verweigern oder zuzulassen.

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

In den Geräteeinstellungen können Nutzer die Berechtigungen für Apps aufrufen, die sie zuvor installiert haben. Nutzer können einige Funktionen auch 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. Geschützte API-Berechtigungsprüfungen werden auf der niedrigsten Ebene erzwungen, um ein Umgehen zu verhindern. In Abbildung 2 ist ein Beispiel für die Nutzermitteilung zu sehen, wenn eine App installiert wird, während der Zugriff auf geschützte APIs angefordert wird.

Die Standardberechtigungen des Systems werden unter https://developer.android.com/reference/android/Manifest.permission.html beschrieben. Apps können eigene Berechtigungen für andere Apps deklarieren. Solche Berechtigungen sind an der oben genannten Stelle nicht aufgeführt.

Beim Definieren einer Berechtigung gibt das Attribut „protectionLevel“ dem System an, wie der Nutzer über Apps informiert werden soll, für die die Berechtigung erforderlich ist, oder wer eine Berechtigung haben darf. Weitere Informationen zum Erstellen und Verwenden von app-spezifischen Berechtigungen finden Sie unter https://developer.android.com/guide/topics/security/security.html.

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 verstehen

Android möchte Nutzern klar machen, wenn sie mit Drittanbieter-Apps interagieren, und sie über die Funktionen dieser Apps informieren. Vor der Installation einer App wird dem Nutzer eine klare Mitteilung über die 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, Berechtigungen direkt vor der Installation anzuzeigen. In diesem Fall sehen sich Nutzer aktiv Informationen zur App, zum Entwickler und zu den Funktionen an, um festzustellen, ob sie ihren Anforderungen und Erwartungen entsprechen. Es ist auch wichtig, dass sie noch keine mentale oder finanzielle Bindung zur App aufgebaut haben und die App leicht mit anderen alternativen Apps vergleichen können.

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. Android soll es Nutzern ermöglichen, nahtlos zwischen Apps zu wechseln. Wenn jedes Mal eine Bestätigung erforderlich wäre, würde das die Nutzer verlangsamen und die Nutzerfreundlichkeit von Android beeinträchtigen. Wenn der Nutzer die Berechtigungen bei der Installation prüfen muss, hat er die Möglichkeit, die App nicht zu installieren, wenn er Bedenken hat.

Außerdem haben viele Studien zur Benutzeroberfläche gezeigt, dass Nutzer, die zu oft aufgefordert werden, bei jedem angezeigten Dialogfeld einfach „Ok“ anklicken. Eines der Sicherheitsziele von Android besteht darin, wichtige Sicherheitsinformationen effektiv an die Nutzer zu übermitteln. Das ist nicht mit Dialogfeldern möglich, die Nutzer dazu bringen, sie zu ignorieren. Wenn die wichtigen Informationen nur einmal und nur dann präsentiert werden, wenn es wichtig ist, denken Nutzer eher darüber nach, wozu sie zustimmen.

Auf einigen Plattformen werden überhaupt keine Informationen zu den Funktionen von Apps angezeigt. Dieser Ansatz verhindert, dass Nutzer die Funktionen der App leicht verstehen und besprechen können. Es ist zwar nicht möglich, dass alle Nutzer immer fundierte Entscheidungen treffen, aber das Android-Berechtigungsmodell macht Informationen zu Apps für eine breite Palette von Nutzern leicht zugänglich. Unerwartete Berechtigungsanfragen können beispielsweise versiertere Nutzer dazu veranlassen, kritische Fragen zur App-Funktionsweise zu stellen und ihre Bedenken an Orten wie Google Play zu äußern, wo sie für alle Nutzer sichtbar sind.

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

Abbildung 1: Anzeige von Berechtigungen für Apps

Interprocess Communication

Prozesse können mit allen traditionellen UNIX-Mechanismen kommunizieren. Beispiele sind das Dateisystem, lokale Sockets oder Signale. Die Linux-Berechtigungen gelten jedoch weiterhin.

Android bietet außerdem neue IPC-Mechanismen:

  • Binder: Ein schlanker, fähigkeitsbasierter Remote-Prozeduraufrufmechanismus, der für eine hohe Leistung bei In-Process- und ‑Prozessaufrufen entwickelt wurde. Binder wird mit einem benutzerdefinierten Linux-Treiber implementiert. Weitere Informationen finden Sie unter https://developer.android.com/reference/android/os/Binder.html.

  • Dienste: Dienste (siehe oben) können Schnittstellen bereitstellen, auf die über Binder direkt zugegriffen werden kann.

  • Intents: Ein Intent ist ein einfaches Nachrichtenobjekt, das die Absicht, etwas zu tun, darstellt. Wenn Ihre App beispielsweise eine Webseite anzeigen soll, drückt sie ihren „Intent“ zum Aufrufen der URL aus, indem sie eine Intent-Instanz erstellt und an das System weitergibt. Das System sucht nach einem anderen Code-Snippet (in diesem Fall dem Browser), das diesen Intent verarbeiten kann, und führt ihn aus. Intents können auch verwendet werden, um interessante Ereignisse (z. B. eine Benachrichtigung) systemweit zu übertragen. Weitere Informationen finden Sie unter https://developer.android.com/reference/android/content/Intent.html.

  • ContentProvider: Ein ContentProvider ist ein Datenspeicher, der Zugriff auf Daten auf dem Gerät bietet. Ein klassisches Beispiel ist der ContentProvider, der zum Zugriff auf die Kontaktliste des Nutzers verwendet wird. Eine App kann auf Daten zugreifen, die andere Apps über einen ContentProvider freigegeben haben. Eine App kann auch eigene ContentProvider definieren, um eigene Daten freizugeben. Weitere Informationen finden Sie unter https://developer.android.com/reference/android/content/ContentProvider.html.

Es ist zwar möglich, IPC mit anderen Mechanismen wie Netzwerk-Sockets oder von allen beschreibbaren Dateien zu implementieren, aber dies sind die empfohlenen Android-IPC-Frameworks. Android-Entwickler werden dazu angehalten, Best Practices zur Sicherung der Daten von Nutzern und zum Vermeiden von Sicherheitslücken zu verwenden.

Kostensensitive APIs

Eine kostenempfindliche API ist eine Funktion, die Kosten für den Nutzer oder das Netzwerk verursachen kann. Die Android-Plattform hat kostenempfindliche APIs in die Liste der vom Betriebssystem verwalteten geschützten APIs aufgenommen. Der Nutzer muss Drittanbieter-Apps, die die Verwendung kostenempfindlicher APIs anfordern, ausdrücklich erlauben, dies zu tun. Zu diesen APIs gehören:

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

Android 4.2 bietet zusätzliche Einstellungen für die Nutzung von SMS. Android sendet eine Benachrichtigung, wenn eine App versucht, eine SMS an eine Kurzwahlnummer zu senden, für die Premiumdienste verwendet werden, die zusätzliche Kosten verursachen können. Der Nutzer kann festlegen, 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 verwaltet 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 höherer Ebene für diese Befehle.

Personenbezogene Daten

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

Zugriff auf vertrauliche Nutzerdaten nur über geschützte APIs

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

Systeminhaltsanbieter, die wahrscheinlich personenbezogene oder personenidentifizierbare Informationen wie Kontakte und Kalender enthalten, wurden mit klar definierten Berechtigungen erstellt. Diese Detaillierung gibt dem Nutzer eine klare Angabe der Arten von Informationen, die an die App weitergegeben werden können. Während der Installation kann eine Drittanbieter-App die Berechtigung zum Zugriff auf diese Ressourcen anfordern. Wenn die Berechtigung gewährt wird, kann die App installiert werden und hat jederzeit Zugriff auf die angeforderten Daten.

Bei allen 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 auf den IPC-Mechanismus anwenden, die vom Betriebssystem erzwungen werden.

Eingabegeräte für sensible Daten

Android-Geräte bieten häufig Eingabegeräte für sensible Daten, mit denen Apps mit der Umgebung interagieren können, z. B. Kamera, Mikrofon oder GPS. Damit eine Drittanbieter-App auf diese Geräte zugreifen kann, muss der Nutzer ihr zuerst explizit über die Android-Berechtigungen des Betriebssystems Zugriff gewähren. Bei der Installation wird der Nutzer vom Installationsprogramm aufgefordert, die Berechtigung für den Sensor per Namen zu gewähren.

Wenn eine App den Standort des Nutzers ermitteln möchte, benötigt sie eine Berechtigung zum Zugriff auf den Standort des Nutzers. Bei der Installation wird der Nutzer gefragt, ob die App auf seinen Standort zugreifen darf. Wenn der Nutzer nicht möchte, dass eine App auf seinen Standort zugreifen kann, kann er jederzeit die App „Einstellungen“ öffnen, zu „Standort und Sicherheit“ gehen und die Optionen „WLANs 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 zwar nicht per se vertraulich sind, aber indirekt Merkmale des Nutzers, seine Einstellungen und die Art und Weise, wie er ein Gerät verwendet, offenlegen können.

Standardmäßig haben Apps keinen Zugriff auf Betriebssystemprotokolle, Browserverlauf, Telefonnummern oder Informationen zur Hardware-/Netzwerkidentifikation. 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 installierter Systemzertifizierungsstellen, die systemweit als vertrauenswürdig eingestuft sind. Vor Android 7.0 konnten Gerätehersteller die auf ihren Geräten vorinstallierten Zertifizierungsstellen ändern. Geräte mit Android 7.0 und höher haben jedoch einheitliche System-Zertifizierungsstellen, da Änderungen durch Gerätehersteller nicht mehr zulässig sind.

Damit die Zertifizierungsstelle dem Standard-Android-CA-Set als neue öffentliche Zertifizierungsstelle hinzugefügt werden kann, muss sie den Einschlussprozess für Mozilla-Zertifizierungsstellen durchlaufen und dann einen Funktionsantrag für Android ( https://code.google.com/p/android/issues/entry) einreichen, damit die Zertifizierungsstelle dem Standard-Android-CA-Set im Android Open Source Project (AOSP) hinzugefügt wird.

Es gibt immer noch Zertifizierungsstellen, die gerätespezifisch sind und nicht in den Kernsatz der AOSP-Zertifizierungsstellen aufgenommen werden sollten, z. B. die privaten Zertifizierungsstellen der Mobilfunkanbieter, die für den sicheren Zugriff auf Komponenten der Infrastruktur des Mobilfunkanbieters wie SMS/MMS-Gateways erforderlich sein können. Geräteherstellern wird empfohlen, die privaten Zertifizierungsstellen nur in den Komponenten/Apps anzugeben, die diesen Zertifizierungsstellen vertrauen müssen. Weitere Informationen finden Sie unter Konfiguration der Netzwerksicherheit.

App-Signatur

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

Bei Google Play stellt die App-Signatur eine Brücke zwischen dem Vertrauen von Google in den Entwickler und dem Vertrauen des Entwicklers in seine App dar. Entwickler wissen, dass ihre App unverändert auf dem Android-Gerät bereitgestellt wird. Außerdem können Entwickler für das Verhalten ihrer App zur Verantwortung 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 mit welcher App verknüpft ist. Unterschiedliche Apps werden unter verschiedenen Nutzer-IDs ausgeführt. Durch die App-Signatur wird sichergestellt, dass eine App nur über eine klar definierte IPC auf eine andere App zugreifen kann.

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

Apps können von einem Drittanbieter (OEM, Mobilfunkanbieter, alternativer Markt) signiert oder selbst signiert sein. Android bietet die Codesignatur mit selbstsignierten Zertifikaten, die Entwickler ohne externe Unterstützung oder Berechtigung generieren können. Apps müssen nicht von einer zentralen Zertifizierungsstelle signiert werden. Android führt derzeit keine CA-Überprüfung für App-Zertifikate durch.

Apps können auch Sicherheitsberechtigungen auf Signaturebene deklarieren, um den Zugriff nur auf Apps zu beschränken, die mit demselben Schlüssel signiert sind, und dabei unterschiedliche UIDs und Anwendungs-Sandboxes beizubehalten. Eine engere Beziehung zu einer freigegebenen Anwendungs-Sandbox ist über die Funktion für freigegebene UIDs zulässig. Dabei können zwei oder mehr Apps, die mit demselben Entwicklerschlüssel signiert sind, in ihrem Manifest eine freigegebene UID deklarieren.

App-Überprüfung

Android 4.2 und höher unterstützen die App-Überprüfung. Nutzer können die Option „Apps überprüfen“ aktivieren und Apps vor der Installation von einem App-Überprüfer prüfen lassen. 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), mit dem Apps rechtlich geschützte Inhalte gemäß den Lizenzeinschränkungen verwalten können, die mit den Inhalten verknüpft sind. 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 Architekturschichten implementiert (siehe Abbildung unten):

  • 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 aus nativem Code, der das DRM-Framework implementiert und eine Schnittstelle für DRM-Plug-ins (Agenten) bereitstellt, um die Rechteverwaltung und Entschlüsselung für verschiedene DRM-Schemata zu verarbeiten

Architektur der digitalen Rechteverwaltung auf der Android-Plattform

Abbildung 3: Architektur von DRM auf der Android-Plattform