Anwendungssicherheit

Elemente von Anwendungen

Android bietet eine Open-Source-Plattform und Anwendungsumgebung für Mobilgeräte. Das Kernbetriebssystem basiert auf dem Linux-Kernel. Android-Anwendungen werden meistens in der Programmiersprache Java geschrieben und in der virtuellen Maschine von Dalvik ausgeführt. Anwendungen können jedoch auch in nativem Code geschrieben werden. Anwendungen werden aus einer einzigen Datei mit der Dateierweiterung .apk installiert.

Die wichtigsten Bausteine ​​der Android-Anwendung 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 unten beschriebene Inhaltsanbieter) in einer Anwendung zu tun ist. Hier wird auch festgelegt, welche Berechtigungen erforderlich sind.

• Aktivitäten : Eine Aktivität ist im Allgemeinen der Code für eine einzelne, benutzerorientierte Aufgabe. Es beinhaltet normalerweise das Anzeigen einer Benutzeroberfläche für den Benutzer, muss es aber nicht – 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 Methoden darauf über entfernte Prozeduraufrufe auf. Ein Beispiel für einen Dienst ist ein Mediaplayer: Selbst wenn der Benutzer die Medienauswahl-UI verlässt, beabsichtigt der Benutzer wahrscheinlich immer noch, dass die Musik weiter abgespielt wird. Ein Dienst hält die Musik auch dann am Laufen, wenn die Benutzeroberfläche abgeschlossen ist.

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

Das Android-Berechtigungsmodell: Zugriff auf geschützte APIs

Alle Anwendungen auf Android laufen in einer Anwendungs-Sandbox . Standardmäßig kann eine Android-Anwendung nur auf eine begrenzte Anzahl von Systemressourcen zugreifen. Das System verwaltet den Zugriff von Android-Anwendungen auf Ressourcen, die bei falscher oder böswilliger Verwendung die Benutzererfahrung, das Netzwerk oder die Daten auf dem Gerät beeinträchtigen könnten.

Diese Beschränkungen werden in einer Vielzahl unterschiedlicher Formen implementiert. Einige Fähigkeiten sind durch bewusstes Fehlen von APIs auf die sensible Funktionalität beschränkt (z. B. gibt es keine Android-API zum direkten Manipulieren der SIM-Karte). In einigen Fällen bietet die Trennung von Rollen eine Sicherheitsmaßnahme, wie bei der Isolierung des Speichers pro Anwendung. In anderen Fällen sind die sensiblen APIs für die Verwendung durch vertrauenswürdige Anwendungen bestimmt und durch einen als Berechtigungen bekannten Sicherheitsmechanismus 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 erforderlichen 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 einen Dialog 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 Benutzerverwirrung zu vermeiden, benachrichtigt das System den Benutzer nicht erneut über die Berechtigungen, die der Anwendung gewährt wurden, und Anwendungen, die im Kernbetriebssystem enthalten sind oder von einem OEM gebündelt sind, fordern keine Berechtigungen vom Benutzer an. Berechtigungen werden entfernt, wenn eine Anwendung deinstalliert wird, sodass eine nachfolgende Neuinstallation wieder zur Anzeige von Berechtigungen führt.

Innerhalb der Geräteeinstellungen können Benutzer Berechtigungen für Anwendungen anzeigen, die sie zuvor installiert haben. Benutzer können auch einige Funktionen nach Belieben global deaktivieren, z. B. das Deaktivieren von GPS, Radio oder Wi-Fi.

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 erzwungen, um eine Umgehung zu verhindern. Ein Beispiel für die Benutzerbenachrichtigung, wenn eine Anwendung installiert wird, während Zugriff auf geschützte APIs angefordert wird, 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 zur Verwendung durch andere Anwendungen deklarieren. Solche Berechtigungen sind an der obigen Stelle nicht aufgeführt.

Beim Definieren einer Berechtigung teilt ein 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 von anwendungsspezifischen Berechtigungen werden unter https://developer.android.com/guide/topics/security/security.html beschrieben.

Es gibt einige Gerätefunktionen, wie z. B. die Möglichkeit, SMS-Broadcast-Intents zu senden, die Anwendungen von Drittanbietern nicht zur Verfügung stehen, aber von Anwendungen verwendet werden können, die vom OEM vorinstalliert wurden. Diese Berechtigungen verwenden die Berechtigung signatureOrSystem.

Wie Benutzer Anwendungen von Drittanbietern verstehen

Android ist bestrebt, den Benutzern deutlich zu machen, wenn sie mit Anwendungen von Drittanbietern interagieren, und den Benutzer über die Fähigkeiten dieser Anwendungen zu informieren. Vor der Installation einer Anwendung wird dem Benutzer eine klare Nachricht ü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 Installation anzuzeigen. Dies ist der Fall, wenn Benutzer aktiv Informationen über die Anwendung, den Entwickler und die Funktionalität überprüfen, um festzustellen, ob sie ihren Bedürfnissen und Erwartungen entsprechen. Wichtig ist auch, dass sie noch keine geistige 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 für die 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. Jedes Mal Bestätigungen bereitzustellen, würde den Benutzer verlangsamen und verhindern, dass Android eine großartige Benutzererfahrung bietet. Die Überprüfungsberechtigungen des Benutzers zum Zeitpunkt der Installation geben dem Benutzer die Möglichkeit, die Anwendung nicht zu installieren, wenn er sich unwohl fühlt.

Außerdem haben viele Studien zur Benutzeroberfläche gezeigt, dass eine übermäßige Aufforderung des Benutzers dazu führt, dass der Benutzer zu jedem angezeigten Dialogfeld "OK" sagt. Eines der Sicherheitsziele von Android ist die effektive Übermittlung wichtiger Sicherheitsinformationen an den Benutzer, was nicht mit Dialogen erfolgen kann, die der Benutzer zu ignorieren trainiert. Indem die wichtigen Informationen einmal und nur dann präsentiert werden, wenn es wichtig ist, wird der Benutzer eher darüber nachdenken, womit er einverstanden ist.

Einige Plattformen entscheiden sich dafür, überhaupt keine Informationen über die Anwendungsfunktionalität anzuzeigen. Dieser Ansatz hindert Benutzer daran, Anwendungsfunktionen einfach zu verstehen und zu diskutieren. Während es nicht allen Benutzern möglich ist, immer voll informierte 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 erfahrenere 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 Maps	Berechtigungen einer installierten Anwendung – Gmail

Abbildung 1. Anzeige der Berechtigungen für Anwendungen

Interprozesskommunikation

Prozesse können unter Verwendung eines der herkömmlichen UNIX-Typ-Mechanismen kommunizieren. Beispiele sind das Dateisystem, lokale Sockets oder Signale. Die Linux-Berechtigungen gelten jedoch weiterhin.

Android bietet auch neue IPC-Mechanismen:

• Binder : Ein leichtgewichtiger, funktionsbasierter Remote-Prozeduraufrufmechanismus, der für eine hohe Leistung bei der Durchführung von In-Process- und Cross-Process-Aufrufen ausgelegt ist. Binder wird mit einem benutzerdefinierten Linux-Treiber implementiert. Siehe https://developer.android.com/reference/android/os/Binder.html .

• Dienste : Dienste (oben erörtert) können Schnittstellen bereitstellen, auf die unter Verwendung von Binder direkt 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“ zum Anzeigen der URL aus, indem sie eine Absichtsinstanz erstellt und an das System weitergibt. 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 .

• Inhaltsanbieter : Ein Inhaltsanbieter ist ein Datenspeicher, der Zugriff auf Daten auf dem Gerät bietet; Das klassische Beispiel ist der ContentProvider, der verwendet wird, um auf die Kontaktliste des Benutzers zuzugreifen. Eine Anwendung kann auf Daten zugreifen, die andere Anwendungen über einen ContentProvider verfügbar gemacht haben, und eine Anwendung kann auch ihre eigenen ContentProvider definieren, um ihre eigenen Daten verfügbar zu machen. Siehe https://developer.android.com/reference/android/content/ContentProvider.html .

Während es möglich ist, IPC mit anderen Mechanismen wie Netzwerk-Sockets oder World-Writable-Dateien zu implementieren, sind dies die empfohlenen Android-IPC-Frameworks. Android-Entwickler werden ermutigt, Best Practices zur Sicherung von Benutzerdaten anzuwenden und die Einführung von Sicherheitslücken zu vermeiden.

Kostenbewusste APIs

Eine kostenempfindliche API ist jede Funktion, die Kosten für den Benutzer oder das Netzwerk verursachen könnte. Die Android-Plattform hat kostensensitive APIs in die Liste der geschützten APIs aufgenommen, die vom Betriebssystem kontrolliert werden. Der Benutzer muss Anwendungen von Drittanbietern, die die Verwendung kostensensibler APIs anfordern, ausdrücklich die Erlaubnis erteilen. Zu diesen APIs gehören:

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

Android 4.2 fügt weitere Kontrolle über die Verwendung von SMS hinzu. Android sendet eine Benachrichtigung, wenn eine Anwendung versucht, eine SMS an eine Kurzwahl zu senden, die Premium-Dienste verwendet, die möglicherweise zusätzliche Gebühren verursachen. Der Benutzer kann wählen, ob er der Anwendung das Senden der Nachricht erlauben oder sie blockieren möchte.

Zugriff auf die SIM-Karte

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

Persönliche Informationen

Android hat APIs, die Zugriff auf Benutzerdaten bieten, in den Satz geschützter APIs platziert. Bei normaler Nutzung sammeln Android-Geräte auch Benutzerdaten in Anwendungen von Drittanbietern, die von Benutzern installiert werden. Anwendungen, die diese Informationen freigeben, können 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 eindeutig identifizierten Berechtigungen erstellt. Diese Granularität liefert dem Benutzer einen klaren Hinweis auf die Arten von Informationen, die der Anwendung bereitgestellt werden können. Während der Installation kann eine Drittanbieteranwendung die Berechtigung zum Zugriff auf diese Ressourcen anfordern. Wenn die Erlaubnis erteilt wird, kann die Anwendung installiert werden und hat während der Installation jederzeit Zugriff auf die angeforderten Daten.

Bei allen Anwendungen, die personenbezogene Daten erfassen, werden diese Daten standardmäßig nur auf die spezifische Anwendung beschränkt. Wenn sich eine Anwendung dafür entscheidet, die Daten anderen Anwendungen über IPC zur Verfügung zu stellen, kann die Zugriff gewährende Anwendung 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, die es Anwendungen ermöglichen, mit der Umgebung zu interagieren, wie z. B. Kamera, Mikrofon oder GPS. Damit eine Anwendung eines Drittanbieters auf diese Geräte zugreifen kann, muss ihr zunächst explizit der Zugriff durch den Benutzer durch die Verwendung von Android-Betriebssystemberechtigungen gewährt werden. Bei der Installation fordert das Installationsprogramm den Benutzer auf, die Erlaubnis für den Sensor nach Namen 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 fragt das Installationsprogramm den Benutzer, 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 der Benutzer die Anwendung „Einstellungen“ ausführen, zu „Standort & Sicherheit“ gehen und „Drahtlose Netzwerke verwenden“ und „GPS-Satelliten aktivieren“ deaktivieren. . Dadurch werden standortbasierte Dienste für alle Anwendungen auf dem Gerät des Benutzers deaktiviert.

Geräte-Metadaten

Android ist auch bestrebt, den Zugriff auf Daten zu beschränken, die nicht an sich sensibel sind, aber indirekt Merkmale über den Benutzer, 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 Informationen zur Hardware-/Netzwerkidentifikation. Wenn eine Anwendung während der Installation Zugriff auf diese Informationen anfordert, fragt das Installationsprogramm den Benutzer, ob die Anwendung auf die Informationen zugreifen kann. Wenn der Benutzer keinen Zugriff gewährt, wird die Anwendung nicht installiert.

Zertifizierungsstellen

Android enthält eine Reihe installierter Systemzertifizierungsstellen, denen systemweit vertraut wird. Vor Android 7.0 konnten Gerätehersteller die auf ihren Geräten gelieferten CAs ändern. Geräte mit Version 7.0 und höher verfügen jedoch über einen einheitlichen Satz von System-CAs, da Änderungen durch Gerätehersteller nicht mehr zulässig sind.

Um als neue öffentliche Zertifizierungsstelle zum Android Stock Set hinzugefügt zu werden, muss die Zertifizierungsstelle den Mozilla CA Inclusion Process abschließen und dann eine Funktionsanforderung für Android einreichen ( https://code.google.com/p/android/issues/entry ). um die Zertifizierungsstelle zum Standard-Android-CA-Set im Android Open Source Project (AOSP) hinzuzufügen.

Es gibt immer noch Zertifizierungsstellen, die gerätespezifisch sind und nicht in den Kernsatz der AOSP-Zertifizierungsstellen aufgenommen werden sollten, wie z. Gerätehersteller werden ermutigt, die privaten Zertifizierungsstellen nur in die Komponenten/Apps aufzunehmen, die diesen Zertifizierungsstellen vertrauen müssen. Weitere Einzelheiten finden Sie unter Netzwerksicherheitskonfiguration .

Anwendungssignierung

Code Signing ermöglicht es Entwicklern, den Autor der Anwendung zu identifizieren und ihre Anwendung zu 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 Signierung zu installieren, werden entweder von Google Play oder dem Paketinstallationsprogramm auf dem Android-Gerät abgelehnt.

Bei Google Play überbrückt die Anwendungssignierung das Vertrauen, das Google in den Entwickler hat, und das Vertrauen, das der Entwickler in seine Anwendung hat. Entwickler wissen, dass ihre Anwendung unverändert für das Android-Gerät bereitgestellt wird; und Entwickler können für das Verhalten ihrer Anwendung zur Rechenschaft gezogen werden.

Unter Android ist die Anwendungssignierung der erste Schritt, um eine Anwendung in ihrer Anwendungs-Sandbox zu platzieren. Das signierte Anwendungszertifikat definiert, welche Benutzer-ID welcher Anwendung zugeordnet ist; verschiedene Anwendungen laufen unter verschiedenen Benutzer-IDs. Die Anwendungssignierung stellt sicher, dass eine Anwendung nur über einen klar definierten IPC auf eine andere Anwendung zugreifen kann.

Wenn eine Anwendung (APK-Datei) auf einem Android-Gerät installiert wird, überprüft der Paket-Manager, 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 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 teilt -signierte APKs.

Anwendungen können von einem Drittanbieter (OEM, Betreiber, alternativer Markt) oder selbst signiert werden. Android bietet Codesignierung mit selbstsignierten Zertifikaten, die Entwickler ohne externe Hilfe oder Erlaubnis generieren können. Anträge müssen nicht von einer zentralen Stelle unterzeichnet werden. Android führt derzeit keine CA-Überprüfung für Anwendungszertifikate durch.

Anwendungen können auch Sicherheitsberechtigungen auf der Signaturschutzebene deklarieren, wodurch der Zugriff nur auf Anwendungen beschränkt wird, die mit demselben Schlüssel signiert sind, während unterschiedliche UIDs und Anwendungs-Sandboxen beibehalten werden. Eine engere Beziehung zu einer gemeinsam genutzten Anwendungs-Sandbox wird über die gemeinsame UID-Funktion ermöglicht, bei der zwei oder mehr Anwendungen, die mit demselben Entwicklerschlüssel signiert sind, 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 verifizieren“ aktivieren und Anwendungen vor der Installation von einem Anwendungsverifizierer bewerten lassen. Die App-Überprüfung kann den Benutzer warnen, wenn er versucht, eine App zu installieren, die schädlich sein könnte; 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 Lizenzeinschrä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 Anwendungen über das Android-Anwendungsframework zugänglich gemacht wird und über die Dalvik-VM für Standardanwendungen läuft.

• 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 handhaben

Abbildung 3. Architektur der Verwaltung digitaler Rechte auf der Android-Plattform