Anwendungssicherheit

Elemente von Anwendungen

Android bietet eine Open-Source-Plattform und Anwendungsumgebung für mobile Geräte. Das Kernbetriebssystem basiert auf dem Linux-Kernel. Android-Anwendungen werden meist in der Programmiersprache Java geschrieben und in der virtuellen Maschine Android Runtime (ART) ausgeführt. Allerdings können Anwendungen auch in nativem Code geschrieben werden. Anwendungen werden aus einer einzigen Datei mit der Dateierweiterung .apk installiert.

Die wichtigsten Bausteine ​​für Android-Anwendungen sind:

• AndroidManifest.xml : Die Datei AndroidManifest.xml ist die Steuerdatei, die dem System mitteilt, was mit allen Komponenten der obersten Ebene (insbesondere Aktivitäten, Dienste, Rundfunkempfänger und Inhaltsanbieter, die unten beschrieben werden) in einer Anwendung geschehen soll. Dadurch wird auch angegeben, welche Berechtigungen erforderlich sind.

• Aktivitäten : Eine Aktivität ist im Allgemeinen der Code für eine einzelne, benutzerorientierte Aufgabe. Dazu gehört in der Regel die Anzeige einer Benutzeroberfläche für den Benutzer, dies ist jedoch nicht unbedingt erforderlich – einige Aktivitäten zeigen niemals Benutzeroberflächen an. Typischerweise ist eine der Aktivitäten der Anwendung der Einstiegspunkt zu einer Anwendung.

• Dienste : Ein Dienst ist ein Codekörper, der im Hintergrund ausgeführt wird. Es kann in einem eigenen Prozess oder im Kontext des Prozesses einer anderen Anwendung ausgeführt werden. Andere Komponenten „binden“ sich an einen Dienst und rufen über Remote-Prozeduraufrufe Methoden darauf auf. Ein Beispiel für einen Dienst ist ein Medienplayer: Auch wenn der Benutzer die Medienauswahl-Benutzeroberfläche verlässt, möchte der Benutzer wahrscheinlich weiterhin Musik abspielen. Ein Dienst sorgt dafür, dass die Musik auch dann weiterläuft, wenn die Benutzeroberfläche abgeschlossen ist.

• Broadcast Receiver : Ein BroadcastReceiver ist ein Objekt, das instanziiert wird, wenn ein IPC-Mechanismus namens Intent vom Betriebssystem oder einer anderen Anwendung ausgegeben wird. Eine Anwendung kann beispielsweise einen Empfänger für die Meldung über niedrigen Batteriestand registrieren und sein Verhalten basierend auf dieser Information ändern.

Das Android-Berechtigungsmodell: Zugriff auf geschützte APIs

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

Diese Einschränkungen werden in unterschiedlicher Form umgesetzt. Einige Funktionen werden durch das bewusste Fehlen von APIs auf die sensiblen Funktionen eingeschränkt (z. B. gibt es keine Android-API zur direkten Manipulation der SIM-Karte). In einigen Fällen stellt die Rollentrennung eine Sicherheitsmaßnahme dar, beispielsweise bei der Isolierung des Speichers pro Anwendung. In anderen Fällen sind die sensiblen APIs für die Verwendung durch vertrauenswürdige Anwendungen vorgesehen und werden 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

Auf diese Ressourcen kann nur über das Betriebssystem zugegriffen werden. Um die geschützten APIs auf dem Gerät nutzen zu können, muss eine Anwendung die benötigten Funktionen in ihrem Manifest definieren. Alle Android-Versionen 6.0 und höher verwenden ein Laufzeitberechtigungsmodell . Wenn ein Benutzer eine Funktion von einer App anfordert, die eine geschützte API erfordert, zeigt das System ein Dialogfeld an, in dem der Benutzer aufgefordert wird, die Berechtigung zu verweigern oder zuzulassen .

Nach der Erteilung werden die Berechtigungen auf die Anwendung angewendet, solange sie installiert ist. Um Verwirrung beim Benutzer zu vermeiden, benachrichtigt das System den Benutzer nicht erneut über die der Anwendung gewährten Berechtigungen, und Anwendungen, die im Kernbetriebssystem enthalten oder von einem OEM gebündelt sind, fordern keine Berechtigungen vom Benutzer an. Berechtigungen werden entfernt, wenn eine Anwendung deinstalliert wird, sodass bei einer anschließenden Neuinstallation erneut Berechtigungen angezeigt werden.

In den Geräteeinstellungen können Benutzer Berechtigungen für Anwendungen anzeigen, die sie zuvor installiert haben. Benutzer können bei Bedarf auch einige Funktionen global deaktivieren, z. B. GPS, Radio oder WLAN deaktivieren.

Falls eine Anwendung versucht, eine geschützte Funktion zu verwenden, die nicht im Manifest der Anwendung deklariert wurde, führt der Berechtigungsfehler normalerweise dazu, dass eine Sicherheitsausnahme an die Anwendung zurückgeworfen wird. Geschützte API-Berechtigungsprüfungen werden auf der niedrigstmöglichen Ebene durchgesetzt, um eine Umgehung zu verhindern. Ein Beispiel für die Benutzerbenachrichtigung, wenn eine Anwendung installiert wird und gleichzeitig Zugriff auf geschützte APIs anfordert, ist in Abbildung 2 dargestellt.

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

Beim Definieren einer Berechtigung teilt das Attribut „protectionLevel“ dem System mit, wie der Benutzer über Anwendungen informiert werden soll, die die Berechtigung erfordern, oder wer eine Berechtigung besitzen darf. Einzelheiten zum Erstellen und Verwenden anwendungsspezifischer Berechtigungen werden unter https://developer.android.com/guide/topics/security/security.html beschrieben.

Einige Gerätefunktionen, beispielsweise die Möglichkeit, SMS-Broadcast-Intents zu senden, stehen Anwendungen von Drittanbietern nicht zur Verfügung, können aber von vom OEM vorinstallierten Anwendungen genutzt werden. Diese Berechtigungen verwenden die SignaturOrSystem-Berechtigung.

Wie Benutzer Anwendungen von Drittanbietern verstehen

Android ist bestrebt, Benutzern deutlich zu machen, wann sie mit Anwendungen von Drittanbietern interagieren, und den Benutzer über die Funktionen dieser Anwendungen zu informieren. Vor der Installation einer Anwendung wird dem Benutzer eine klare Meldung über die verschiedenen Berechtigungen angezeigt, die die Anwendung anfordert. Nach der Installation wird der Benutzer nicht erneut aufgefordert, Berechtigungen zu bestätigen.

Es gibt viele Gründe, Berechtigungen unmittelbar vor der Installationszeit anzuzeigen. Dabei überprüft der Benutzer aktiv Informationen über die Anwendung, den Entwickler und die Funktionalität, um festzustellen, ob sie seinen Anforderungen und Erwartungen entsprechen. Wichtig ist auch, dass sie noch keine mentale oder finanzielle Bindung an die App aufgebaut haben und die Anwendung problemlos mit anderen alternativen Anwendungen vergleichen können.

Einige andere Plattformen verwenden einen anderen Ansatz zur Benutzerbenachrichtigung und fordern zu Beginn jeder Sitzung oder während der Verwendung von Anwendungen eine Erlaubnis an. Die Vision von Android ist es, dass Benutzer nach Belieben nahtlos zwischen Anwendungen wechseln können. Die Bereitstellung von Bestätigungen jedes Mal würde den Benutzer verlangsamen und Android daran hindern, ein großartiges Benutzererlebnis zu bieten. Wenn der Benutzer die Berechtigungen zum Zeitpunkt der Installation überprüft, hat der Benutzer die Möglichkeit, die Anwendung nicht zu installieren, wenn er sich unwohl fühlt.

Viele Studien zur Benutzeroberfläche haben außerdem gezeigt, dass übermäßige Eingabeaufforderungen dazu führen, dass der Benutzer in jedem angezeigten Dialog „OK“ sagt. Eines der Sicherheitsziele von Android besteht darin, dem Benutzer wichtige Sicherheitsinformationen effektiv zu übermitteln, was nicht durch Dialoge erreicht werden kann, deren Ignorieren dem Benutzer beigebracht wird. Indem die wichtigen Informationen nur einmal und nur dann präsentiert werden, wenn sie wichtig sind, ist es wahrscheinlicher, dass der Benutzer darüber nachdenkt, womit er einverstanden ist.

Einige Plattformen entscheiden sich dafür, überhaupt keine Informationen über die Anwendungsfunktionalität anzuzeigen. Dieser Ansatz verhindert, dass Benutzer die Anwendungsfunktionen leicht verstehen und diskutieren können. Auch wenn es nicht allen Benutzern möglich ist, stets fundierte Entscheidungen zu treffen, macht das Android-Berechtigungsmodell Informationen über Anwendungen für eine breite Palette von Benutzern leicht zugänglich. Beispielsweise können unerwartete Berechtigungsanfragen anspruchsvollere Benutzer dazu veranlassen, kritische Fragen zur Anwendungsfunktionalität zu stellen und ihre Bedenken an Orten wie Google Play mitzuteilen, wo sie für alle Benutzer sichtbar sind.

Berechtigungen bei der Anwendungsinstallation – Google Translate	Berechtigungen einer installierten Anwendung – Gmail

Abbildung 1. Anzeige der Berechtigungen für Anwendungen

Interprozesskommunikation

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

Android bietet außerdem neue IPC-Mechanismen:

• Binder : Ein leichter, funktionsbasierter Remote-Prozeduraufrufmechanismus, der für hohe Leistung bei der Durchführung von prozessinternen und prozessübergreifenden Aufrufen ausgelegt ist. Binder wird mithilfe eines benutzerdefinierten Linux-Treibers implementiert. Siehe https://developer.android.com/reference/android/os/Binder.html .

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

• Absichten : Eine Absicht ist ein einfaches Nachrichtenobjekt, das eine „Absicht“ darstellt, etwas zu tun. Wenn Ihre Anwendung beispielsweise eine Webseite anzeigen möchte, drückt sie ihre „Absicht“ aus, die URL anzuzeigen, indem sie eine Intent-Instanz erstellt und diese an das System übergibt. Das System findet einen anderen Codeabschnitt (in diesem Fall den Browser), der weiß, wie dieser Intent zu handhaben ist, und führt ihn aus. Absichten können auch verwendet werden, um interessante Ereignisse (z. B. eine Benachrichtigung) systemweit zu verbreiten. Siehe https://developer.android.com/reference/android/content/Intent.html .

• ContentProviders : Ein ContentProvider ist ein Datenspeicher, der Zugriff auf Daten auf dem Gerät ermöglicht; Das klassische Beispiel ist der ContentProvider, der für den Zugriff auf die Kontaktliste des Benutzers verwendet wird. Eine Anwendung kann auf Daten zugreifen, die andere Anwendungen über einen ContentProvider offengelegt haben, und eine Anwendung kann auch ihre eigenen ContentProvider definieren, um eigene Daten offenzulegen. Siehe https://developer.android.com/reference/android/content/ContentProvider.html .

Während es möglich ist, IPC mithilfe anderer Mechanismen wie Netzwerk-Sockets oder weltweit beschreibbaren Dateien zu implementieren, handelt es sich hierbei um die empfohlenen Android-IPC-Frameworks. Android-Entwickler werden ermutigt, Best Practices zur Sicherung der Benutzerdaten und zur Vermeidung der Entstehung von Sicherheitslücken anzuwenden.

Kostensensitive APIs

Eine kostensensible API ist jede Funktion, die dem Benutzer oder dem Netzwerk Kosten verursachen könnte. Die Android-Plattform hat kostenempfindliche APIs in die Liste der geschützten APIs aufgenommen, die vom Betriebssystem gesteuert werden. Der Benutzer muss Drittanwendungen, die die Verwendung kostenempfindlicher APIs anfordern, eine ausdrückliche Erlaubnis erteilen. Zu diesen APIs gehören:

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

Android 4.2 bietet weitere Kontrolle über die Verwendung von SMS. Android sendet eine Benachrichtigung, wenn eine Anwendung versucht, SMS an einen Kurzcode zu senden, der Premiumdienste nutzt, was zusätzliche Kosten verursachen könnte. Der Benutzer kann wählen, ob er der Anwendung das Senden der Nachricht erlauben oder sie blockieren soll.

Zugriff auf SIM-Karte

Der Low-Level-Zugriff auf die SIM-Karte ist für Apps von Drittanbietern nicht verfügbar. Das Betriebssystem verwaltet die gesamte Kommunikation mit der SIM-Karte, einschließlich des Zugriffs auf persönliche Informationen (Kontakte) im SIM-Kartenspeicher. Anwendungen können auch nicht auf AT-Befehle zugreifen, da diese ausschließlich vom Radio Interface Layer (RIL) verwaltet werden. Die RIL stellt für diese Befehle keine High-Level-APIs bereit.

Persönliche Angaben

Android hat APIs, die den Zugriff auf Benutzerdaten ermöglichen, in den Satz geschützter APIs eingefügt. Bei normaler Nutzung sammeln Android-Geräte auch Benutzerdaten in von Benutzern installierten Drittanbieteranwendungen. Anwendungen, die diese Informationen weitergeben, können die Berechtigungsprüfungen des Android-Betriebssystems verwenden, um die Daten vor Anwendungen von Drittanbietern zu schützen.

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

Systeminhaltsanbieter, die wahrscheinlich persönliche oder persönlich identifizierbare Informationen wie Kontakte und Kalender enthalten, wurden mit klar definierten Berechtigungen erstellt. Diese Granularität bietet dem Benutzer einen klaren Hinweis auf die Arten von Informationen, die der Anwendung bereitgestellt werden können. Während der Installation fordert eine Drittanbieteranwendung möglicherweise die Erlaubnis zum Zugriff auf diese Ressourcen an. Bei Erteilung der Erlaubnis kann die Anwendung installiert werden und hat bei der Installation jederzeit Zugriff auf die angeforderten Daten.

Bei allen Anwendungen, die personenbezogene Daten sammeln, sind diese Daten standardmäßig nur auf die jeweilige Anwendung beschränkt. Wenn eine Anwendung beschließt, die Daten anderen Anwendungen über IPC zur Verfügung zu stellen, kann die Anwendung, die den Zugriff gewährt, Berechtigungen auf den IPC-Mechanismus anwenden, die vom Betriebssystem erzwungen werden.

Sensible Dateneingabegeräte

Android-Geräte verfügen häufig über Eingabegeräte für sensible Daten, die es Anwendungen ermöglichen, mit der Umgebung zu interagieren, z. B. Kamera, Mikrofon oder GPS. Damit eine Drittanbieteranwendung auf diese Geräte zugreifen kann, muss ihr der Benutzer zunächst explizit über Android-Betriebssystemberechtigungen Zugriff gewähren. Bei der Installation fordert das Installationsprogramm den Benutzer auf, seinen Namen für den Zugriff auf den Sensor anzufordern.

Wenn eine Anwendung den Standort des Benutzers wissen möchte, benötigt die Anwendung eine Berechtigung zum Zugriff auf den Standort des Benutzers. Bei der Installation wird der Benutzer vom Installationsprogramm gefragt, ob die Anwendung auf den Standort des Benutzers zugreifen kann. Wenn der Benutzer jederzeit nicht möchte, dass eine Anwendung auf seinen Standort zugreift, kann er die Anwendung „Einstellungen“ ausführen, zu „Standort & Sicherheit“ gehen und die Kontrollkästchen „Drahtlose Netzwerke verwenden“ und „GPS-Satelliten aktivieren“ deaktivieren. . Dadurch werden standortbasierte Dienste für alle Anwendungen auf dem Gerät des Benutzers deaktiviert.

Gerätemetadaten

Android ist außerdem bestrebt, den Zugriff auf Daten einzuschränken, die nicht an sich sensibel sind, aber indirekt Merkmale des Benutzers, Benutzerpräferenzen und die Art und Weise, wie er ein Gerät verwendet, preisgeben können.

Standardmäßig haben Anwendungen keinen Zugriff auf Betriebssystemprotokolle, Browserverlauf, Telefonnummer oder Hardware-/Netzwerkidentifikationsinformationen. Wenn eine Anwendung zum Zeitpunkt der Installation Zugriff auf diese Informationen anfordert, fordert das Installationsprogramm den Benutzer auf, zu fragen, ob die Anwendung auf die Informationen zugreifen kann. Wenn der Benutzer keinen Zugriff gewährt, wird die Anwendung nicht installiert.

Zertifizierungsstellen

Android umfasst eine Reihe installierter Systemzertifizierungsstellen, die systemweit vertrauenswürdig sind. Vor Android 7.0 konnten Gerätehersteller die auf ihren Geräten ausgelieferten Zertifizierungsstellen ändern. Geräte mit Version 7.0 und höher verfügen jedoch über einen einheitlichen Satz von Systemzertifizierungsstellen, da Änderungen durch Gerätehersteller nicht mehr zulässig sind.

Um als neue öffentliche Zertifizierungsstelle zum Android-Bestandssatz hinzugefügt zu werden, muss die Zertifizierungsstelle den Mozilla-CA-Aufnahmeprozess abschließen und dann eine Funktionsanfrage an Android stellen ( https://code.google.com/p/android/issues/entry ). um die CA zur Standard-Android-CA hinzuzufügen, die im Android Open Source Project (AOSP) festgelegt ist.

Es gibt immer noch CAs, die gerätespezifisch sind und nicht in den Kernsatz der AOSP-CAs aufgenommen werden sollten, wie z. B. private CAs von Netzbetreibern, die möglicherweise für den sicheren Zugriff auf Komponenten der Infrastruktur des Netzbetreibers erforderlich sind, wie z. B. SMS/MMS-Gateways. Gerätehersteller werden aufgefordert, die privaten Zertifizierungsstellen nur in die Komponenten/Apps aufzunehmen, die diesen Zertifizierungsstellen vertrauen müssen. Weitere Einzelheiten finden Sie unter Netzwerksicherheitskonfiguration .

Anwendungssignatur

Durch die Codesignatur können Entwickler den Autor der Anwendung identifizieren und ihre Anwendung aktualisieren, ohne komplizierte Schnittstellen und Berechtigungen zu erstellen. Jede Anwendung, die auf der Android-Plattform ausgeführt wird, muss vom Entwickler signiert werden. Anwendungen, die versuchen, ohne Signatur zu installieren, werden entweder von Google Play oder dem Paketinstallationsprogramm auf dem Android-Gerät abgelehnt.

Bei Google Play überbrückt die Anwendungssignatur das Vertrauen, das Google gegenüber dem Entwickler hat, und das Vertrauen, das der Entwickler gegenüber seiner Anwendung hat. Entwickler wissen, dass ihre Anwendung unverändert auf dem Android-Gerät bereitgestellt wird. und Entwickler können für das Verhalten ihrer Anwendung zur Verantwortung gezogen werden.

Unter Android ist das Signieren von Anwendungen der erste Schritt zum Platzieren einer Anwendung in der Anwendungssandbox. Das signierte Anwendungszertifikat definiert, welche Benutzer-ID welcher Anwendung zugeordnet ist; Verschiedene Anwendungen laufen unter unterschiedlichen Benutzer-IDs. Durch die Anwendungssignatur wird sichergestellt, dass eine Anwendung nur über einen genau definierten IPC auf eine andere Anwendung zugreifen kann.

Wenn eine Anwendung (APK-Datei) auf einem Android-Gerät installiert wird, überprüft der Paketmanager, ob die APK ordnungsgemäß mit dem in dieser 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 eines anderen APK auf dem Gerät verwendet wird, hat das neue APK die Möglichkeit, im Manifest anzugeben, dass es auf ähnliche Weise eine UID mit dem anderen teilen wird -signierte APKs.

Anträge können von einem Dritten (OEM, Betreiber, alternativer Markt) oder selbst unterzeichnet werden. Android bietet Code-Signierung mithilfe selbstsignierter Zertifikate, die Entwickler ohne externe Hilfe oder Erlaubnis generieren können. Anträge müssen nicht von einer zentralen Behörde unterzeichnet werden. Android führt derzeit keine CA-Überprüfung für Anwendungszertifikate durch.

Anwendungen können auch Sicherheitsberechtigungen auf der Signaturschutzebene deklarieren und so den Zugriff nur auf Anwendungen beschränken, die mit demselben Schlüssel signiert sind, während unterschiedliche UIDs und Anwendungssandboxen beibehalten werden. Eine engere Beziehung zu einer gemeinsam genutzten Anwendungs-Sandbox ist über die Funktion „Shared UID“ möglich, bei der zwei oder mehr mit demselben Entwicklerschlüssel signierte Anwendungen eine gemeinsame UID in ihrem Manifest deklarieren können.

Anwendungsüberprüfung

Android 4.2 und höher unterstützen die Anwendungsüberprüfung. Benutzer können „Apps überprüfen“ aktivieren und Anwendungen vor der Installation von einem Anwendungsverifizierer bewerten lassen. Die App-Verifizierung kann den Benutzer warnen, wenn er versucht, eine App zu installieren, die möglicherweise schädlich ist. Wenn eine Anwendung besonders schlecht ist, kann sie die Installation blockieren .

Management von Digitalen Rechten

Die Android-Plattform bietet ein erweiterbares DRM-Framework, mit dem Anwendungen rechtegeschützte Inhalte gemäß den mit den Inhalten verbundenen Lizenzbeschränkungen verwalten können. Das DRM-Framework unterstützt viele DRM-Schemata; Welche DRM-Schemata ein Gerät unterstützt, bleibt dem Gerätehersteller überlassen.

Das Android DRM-Framework ist in zwei Architekturschichten implementiert (siehe Abbildung unten):

• Eine DRM-Framework-API, die über das Android-Anwendungsframework für Anwendungen verfügbar gemacht wird und für Standardanwendungen über die ART-VM ausgeführt wird.

• Ein nativer Code-DRM-Manager, 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 übernehmen

Abbildung 3. Architektur des Digital Rights Management auf der Android-Plattform