Best Practices für die Systemsicherheit

Dieser Abschnitt enthält Empfehlungen zur Gewährleistung der Sicherheit des Android-Betriebssystems und der Geräte.

Biometrische Authentifizierung

Biometrische Daten für die Nutzerauthentifizierung müssen mit Bedacht erhoben, gespeichert und verarbeitet werden. …solltest du:

  • Die primäre Authentifizierungsmethode muss vor jeder anderen Authentifizierungsmethode (einschließlich biometrischer Authentifizierung) verwendet werden.
  • Erforderliche explizite Bestätigung, um die Absicht anzugeben, wenn passive biometrische Verfahren wie die Gesichtserkennung für Transaktionen (z. B. Zahlungen) verwendet werden, die authentifizierte Schlüssel erfordern.
  • Die primäre Authentifizierungsmethode muss alle 72 Stunden verwendet werden.
  • Verwenden Sie eine vollständig sichere Pipeline für alle biometrischen Daten und die damit verbundene Verarbeitung.
  • Senden Sie niemals biometrische Daten (einschließlich Rohsensormessungen und abgeleiteter Funktionen) vom Gerät weg. Bewahren Sie diese Daten nach Möglichkeit in einer sicheren, isolierten Umgebung wie der Trusted Execution Environment (TEE) oder einem Secure Element auf.

Geräte mit biometrischen Funktionen sollten die BiometricPrompt API unterstützen. Diese API bietet eine gemeinsame und konsistente Schnittstelle für App-Entwickler, um die biometrische Authentifizierung in ihren Apps zu nutzen. Nur starke biometrische Verfahren können in BiometricPrompt eingebunden werden. Die Integrationen müssen den Richtlinien des Compatibility Definition Document (CDD) für Android entsprechen.

Weitere biometrische Richtlinien finden Sie in den Richtlinien für die Implementierung biometrischer HALs.

SELinux

SELinux dient der Definition und Durchsetzung eines Großteils des Sicherheitsmodells von Android. Die korrekte Verwendung von SELinux ist für die Sicherheit von Android-Geräten entscheidend und kann dazu beitragen, die Auswirkungen von Sicherheitslücken zu mindern. Aus diesem Grund sollten alle Android-Geräte eine robuste SELinux-Richtlinie implementieren.

  • Implementieren Sie eine Richtlinie für die geringste Berechtigung.
  • Gewähren Sie keine Berechtigungen vom Typ CAP_DAC_OVERRIDE, CAP_SYS_ADMIN und CAP_NET_ADMIN.
  • Systemdaten nicht auf der SD-Karte protokollieren
  • Verwenden Sie die bereitgestellten Typen für den Treiberzugriff, z. B. gpu_device oder audio_device.
  • Verwenden Sie aussagekräftige Namen für Prozesse, Dateien und SELinux-Typen.
    • Achten Sie darauf, dass Standardlabels nicht verwendet und ihnen kein Zugriff gewährt wird.
  • Gerätespezifische Richtlinien sollten 5 bis 10% der Gesamtrichtlinien ausmachen, die auf einem Gerät ausgeführt werden. Anpassungen mit einem Wert von über 20%enthalten mit hoher Wahrscheinlichkeit überberechtigte Domains und inaktive Richtlinien. Unnötig große Richtlinien verbrauchen Arbeitsspeicher und Speicherplatz, da ein größeres Boot-Image erforderlich ist, und wirken sich negativ auf die Suchzeiten für Laufzeitrichtlinien aus.

Dynamisches Laden der SELinux-Richtlinie

SELinux-Richtlinien nicht dynamisch auf Android-Geräten laden. Das kann zu Problemen führen, z. B. zu:

  • Die Annahme wichtiger Sicherheits-Patches verhindern.
  • Die Möglichkeit, ein Gerät durch das Neuladen von Richtlinien zu rooten.
  • Es wird ein Vektor für Man-in-the-Middle-Angriffe auf den Richtlinien-Updater freigelegt.
  • Dies führte aufgrund von Fehlern bei Richtlinienaktualisierungen zu nicht mehr funktionsfähigen Geräten.

Backdoors

Android-Apps dürfen keine Backdoors oder Zugriffsmöglichkeiten auf das System oder Daten haben, die normale Sicherheitsmechanismen umgehen. Dazu gehören Diagnose, Fehlerbehebung, Entwicklung oder Garantiereparaturen, für die der Zugriff durch Secrets eingeschränkt wird, die dem Entwickler bekannt sind. So verhindern Sie Backdoors:

  • Scannen Sie alle Drittanbieter-Apps mit einem branchenweit anerkannten Tool zum Scannen von App-Sicherheitslücken.
  • Führen Sie Codeüberprüfungen für den gesamten Code mit sensiblem Zugriff durch, einschließlich Bibliotheken von Drittanbietern.
  • Nutzen Sie Google Play Protect, indem Sie Apps zum Scannen in Google Play hochladen. Sie können Apps zum Scannen hochladen, ohne sie bei Google Play zu veröffentlichen.
  • Laden Sie keine Tools zur Diagnose oder Reparatur in Release-Builds vor. Installieren Sie diese Tools nur bei Bedarf, um bestimmte Probleme zu beheben. Außerdem dürfen diese Tools keine kontospezifischen Daten verarbeiten oder hochladen.

Entwickler-Tools

Entwicklungstools wie Tools zum Entfernen von Fehlern, zum Testen und zur Diagnose können oft unbeabsichtigte Sicherheitslücken auf Ihrem Gerät verursachen, da sie offenlegen, wie sie funktionieren und welche Daten sie erheben. So sorgen Sie dafür, dass Entwicklungstools nicht in Produktionsbuilds gelangen:

  • Erstellen Sie eine Blacklist mit Hashes von internen Debug- und Testtools und scannen Sie Builds auf diese APKs, bevor Sie das System-Image verwenden.
  • Scannen Sie alle eigenen Apps mit einem branchenweit anerkannten Tool zum Scannen von App-Sicherheitslücken.
  • Beauftragen Sie ein Unternehmen für App-Sicherheitstests, alle kritischen On-Device-Diagnose-Apps vor jedem größeren Update zu prüfen, insbesondere wenn die App von einem Drittanbieter entwickelt wurde.
  • Achten Sie darauf, dass nur der Nutzer das Tool während einer Support-Sitzung entweder mündlich oder per Chat aktivieren kann. Speichern Sie die Einwilligungsnachweise und deaktivieren Sie das Tool, nachdem Sie die erforderlichen Diagnoseinformationen erfasst haben.
  • Speichern Sie die Nutzungsdaten dieses Tools in einem Protokoll, auf das der Nutzer in seinem Mobilfunkanbieterkonto zugreifen kann.
  • Alle personenidentifizierbaren Informationen oder Gerätemessdaten, die mit dem Tool erhoben werden, müssen den für das Land geltenden Verfahren zur Anonymisierung, Aufbewahrung und Löschung unterliegen. Es sollten nur Daten erhoben werden, die für den Supportanruf relevant sind. Diese Daten sollten nach jedem Aufruf gelöscht werden.
  • Achten Sie darauf, dass Methoden, die für Spyware verwendet werden können, wie die Erfassung von Tastenanschlägen, die Nutzung des Mikrofons oder der Kamera, nicht ohne ausdrückliche Einwilligung des Nutzers verwendet werden. Apps, die diese potenziell datenschutzverletzenden Methoden verwenden, müssen sehr deutlich offengelegt werden. Außerdem muss eine Datenschutzerklärung vorhanden sein, der der Nutzer zustimmen muss. Apps wie diese dürfen nicht ohne ausdrückliche Einwilligung des Nutzers aktiviert werden.

Hier sind einige weitere Vorschläge für die Implementierung von Offenlegung und Einwilligung:

Offenlegung in Apps

  • Die normale Nutzung der App muss direkt in der App angezeigt werden. Der Nutzer darf nicht zu einem Menü oder den Einstellungen wechseln müssen.
  • Beschreiben Sie die Art der erhobenen Daten und erläutern Sie, wie die Daten verwendet werden.
  • Idealerweise sollten Sie diese Informationen nicht in eine Datenschutzerklärung oder in die Nutzungsbedingungen einbetten. Sie darf nicht in andere Offenlegungen integriert werden, die nicht im Zusammenhang mit der Erhebung personenbezogener oder sensibler Daten stehen.
  • Die Einwilligung muss ausdrücklich erfolgen. Ein Wegtippen der Offenlegung, das Drücken der Zurück- oder Startbildschirmtaste oder Ähnliches darf nicht als Einwilligung aufgefasst werden.
  • Der Dialog zur Einwilligung muss klar und eindeutig präsentiert werden.
  • Der Nutzer muss z. B. durch Tippen oder das Aussprechen eines Befehls aktiv seine Zustimmung bekunden.
  • Es dürfen keine personenbezogenen oder vertraulichen Daten erhoben werden, bevor eine Einwilligung vorliegt.
  • Verwenden Sie keine Meldungen, die automatisch geschlossen werden oder zeitlich befristet sind.

Integrierte Funktionen in AOSP

Das Einbetten zusätzlicher Funktionen in AOSP kann oft zu unerwartetem Verhalten und unerwarteten Folgen führen. Gehen Sie daher mit Vorsicht vor.

  • Nutzer müssen gefragt werden, ob sie andere Standard-Apps verwenden möchten (z. B. Suchmaschine, Webbrowser, Launcher). Außerdem muss offengelegt werden, dass Daten vom Gerät gesendet werden.
  • AOSP-APKs müssen mit dem AOSP-Zertifikat signiert sein.
  • Führen Sie Regressionstests durch und führen Sie ein Änderungsprotokoll, um festzustellen, ob den AOSP-APKs Code hinzugefügt wurde.

Sicherheitsupdates

Android-Geräte sollten mindestens zwei Jahre nach der Markteinführung kontinuierlichen Sicherheitssupport erhalten. Dazu gehören regelmäßige Updates, die bekannte Sicherheitslücken schließen.

  • Erarbeiten Sie mit Hardwarepartnern wie Ihren SoC-Anbietern geeignete Supportvereinbarungen für alle Komponenten Ihres Android-Geräts.
  • Sorgen Sie dafür, dass Sicherheitsupdates mit minimaler Nutzerinteraktion installiert werden können, um die Wahrscheinlichkeit zu erhöhen, dass Nutzer Updates auf ihrem Android-Gerät akzeptieren und installieren. Es wird dringend empfohlen, nahtlose Systemupdates oder eine gleichwertige Sicherheitsfunktion zu implementieren.
  • Sie müssen die kumulative Anforderung der Android-Sicherheitspatch-Ebene (SPL) kennen, wie im Android-Sicherheitsbulletin angegeben. Beispiel: Auf Geräten mit dem Sicherheitspatch vom 01.02.2018 müssen alle mit diesem Sicherheitspatch verbundenen Probleme behoben sein. Außerdem müssen alle Probleme behoben sein, die in allen vorherigen Sicherheitsbulletins gemeldet wurden.

Dynamische Kernelupdates

Ändern Sie kritische Systemkomponenten nicht dynamisch. Es gibt zwar einige Studien, die darauf hinweisen, dass dynamische Kernel-Updates vor Notfallbedrohungen schützen, aber die Kosten überwiegen derzeit die Vorteile. Erstellen Sie stattdessen eine robuste Methode für OTA-Updates, um Sicherheitsmaßnahmen für Sicherheitslücken schnell bereitzustellen.

Schlüsselverwaltung

Sorgen Sie für gute Richtlinien und Verfahren zur Schlüsselverwaltung, um die Sicherheit der Signaturschlüssel zu gewährleisten.

  • Geben Sie Signaturschlüssel nicht an externe Parteien weiter.
  • Wenn ein Signaturschlüssel manipuliert wurde, generieren Sie einen neuen Schlüssel und signieren Sie alle Apps in Zukunft doppelt.
  • Bewahren Sie alle Schlüssel in Hochsicherheitsmodulen oder ‑diensten auf, für die mehrere Faktoren für den Zugriff erforderlich sind.

Signatur des System-Images

Die Signatur des System-Images ist entscheidend für die Bestimmung der Geräteintegrität.

  • Signieren Sie Geräte nicht mit einem öffentlich bekannten Schlüssel.
  • Verwalten Sie Schlüssel für die Gerätesignatur gemäß den branchenüblichen Verfahren zum Umgang mit sensiblen Schlüsseln, einschließlich eines Hardwaresicherheitsmoduls (HSM), das eingeschränkten, auditierbaren Zugriff bietet.

Entsperrbare Bootloader

Viele Android-Geräte unterstützen das Entsperren, sodass der Geräteeigentümer die Systempartition ändern oder ein benutzerdefiniertes Betriebssystem installieren kann. Gängige Anwendungsfälle sind die Installation eines Systemimages eines Drittanbieters und die Entwicklung auf Systemebene auf dem Gerät. Wenn ein Nutzer beispielsweise das System-Image auf einem Google Nexus oder Pixel entsperren möchte, kann er fastboot oem unlock ausführen. Daraufhin wird diese Meldung angezeigt:

Als Best Practice sollten alle Nutzerdaten auf entsperrbaren Android-Geräten vor dem Entsperren sicher gelöscht werden. Wenn nicht alle Daten beim Entsperren richtig gelöscht werden, kann ein Angreifer, der sich in der Nähe des Geräts befindet, unbefugten Zugriff auf vertrauliche Android-Nutzerdaten erhalten. Um die Offenlegung von Nutzerdaten zu verhindern, muss die Entsperrung auf einem Gerät, das diese Funktion unterstützt, ordnungsgemäß implementiert sein.

  • Nachdem der Nutzer den Befehl zum Entsperren bestätigt hat, muss das Gerät sofort mit dem Löschen der Daten beginnen. Das Flag unlocked darf erst gesetzt werden, nachdem das sichere Löschen abgeschlossen ist.
  • Wenn das sichere Löschen nicht abgeschlossen werden kann, muss das Gerät gesperrt bleiben.
  • Wenn vom zugrunde liegenden Blockgerät unterstützt, sollte ioctl(BLKSECDISCARD) oder ein entsprechender Wert verwendet werden. Bei eingebetteten Multimediakarten (eMMC) bedeutet dies, dass der Befehl „Secure Erase“ oder „Secure Trim“ verwendet werden muss. Bei eMMC 4.5 und höher bedeutet das, dass ein normaler Lösch- oder Trimmvorgang gefolgt von einem Löschvorgang ausgeführt wird.
  • Wenn BLKSECDISCARD vom zugrunde liegenden Blockgerät nicht unterstützt wird, muss stattdessen ioctl(BLKDISCARD) verwendet werden. Auf eMMC-Geräten ist dies ein normaler Trim-Vorgang.
  • Wenn BLKDISCARD nicht unterstützt wird, ist es zulässig, die Blockgeräte mit Nullen zu überschreiben.
  • Nutzer müssen die Möglichkeit haben, vor dem Flashen einer Partition zu verlangen, dass Nutzerdaten gelöscht werden. Auf Nexus-Geräten wird beispielsweise der Befehl fastboot oem lock verwendet, um Nutzerdaten zu löschen.
  • Ein Gerät kann über eFuses oder einen ähnlichen Mechanismus aufzeichnen, ob es entsperrt und/oder wieder gesperrt wurde. Wir empfehlen jedoch dringend, den Bootloader wieder zu sperren und das Gerät anschließend auf die Werkseinstellungen zurückzusetzen. Dadurch sollte die volle Funktionalität des Geräts wiederhergestellt werden.

So wird sichergestellt, dass alle Daten nach Abschluss eines Entsperrvorgangs gelöscht werden. Das Fehlen dieser Schutzmaßnahmen gilt als Sicherheitslücke vom mittleren Risikograd.

Ein entsperrtes Gerät kann mit dem Befehl fastboot oem lock wieder gesperrt werden. Durch das Sperren des Bootloaders werden die Nutzerdaten mit dem neuen benutzerdefinierten Betriebssystem genauso geschützt wie mit dem ursprünglichen Betriebssystem des Geräteherstellers. Beispielsweise werden Nutzerdaten gelöscht, wenn das Gerät wieder entsperrt wird.

Geräte-Penetrationstests

Geräte sollten vor dem Versand von einem kompetenten Pentester geprüft werden. Beim Pentest sollte festgestellt werden, dass das Gerät den hier bereitgestellten Sicherheitsrichtlinien sowie den internen Sicherheitsrichtlinien des OEMs entspricht.

Sicherheitstests

Verwenden Sie die Sicherheitstesttools von AOSP. Insbesondere

  • Verwenden Sie während der Entwicklung Tools zur Speichersicherheit: Verwenden Sie MTE, sofern unterstützt (ARMv9 und höher), und HWASan, sofern nicht. Führen Sie so viele Tests wie möglich mit aktivierten Tools aus.
  • Verwenden Sie GWP-ASan und KFENCE in der Produktion, um Speichersicherheitsprobleme probabilistisch zu erkennen.