Best Practices für die Systemsicherheit

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

Biometrische Authentifizierung

Erfassen, speichern und verarbeiten Sie biometrische Daten zur Benutzerauthentifizierung sorgfältig. Du solltest:

  • Legen Sie die primäre Authentifizierungsmethode fest, bevor Sie eine andere Form der Authentifizierung (einschließlich Biometrie) verwenden.
  • Erfordern Sie eine explizite Bestätigung, um die Absicht anzuzeigen, wenn Sie passive biometrische Modalitäten wie Gesichtserkennung für Transaktionen (z. B. Zahlungen) verwenden, die an die Authentifizierung gebundene Schlüssel beinhalten.
  • Erfordern die primäre Authentifizierungsmethode alle 72 Stunden.
  • Nutzen Sie eine vollständig sichere Pipeline für alle biometrischen Daten und deren Verarbeitung.
  • Senden Sie niemals biometrische Daten (einschließlich roher Sensormessungen und abgeleiteter Merkmale) außerhalb des Geräts. Bewahren Sie diese Daten nach Möglichkeit in einer sicheren, isolierten Umgebung auf, beispielsweise im Trusted Execution Environment (TEE) oder Secure Element.

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

Weitere biometrische Richtlinien finden Sie unter Implementierungsrichtlinien für biometrisches HAL .

SELinux

SELinux bietet die Definition und Durchsetzung eines Großteils des Android-Sicherheitsmodells. Die korrekte Verwendung von SELinux ist für die Sicherheit von Android-Geräten von entscheidender Bedeutung 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 mit den geringsten Privilegien.
  • Vermeiden Sie die Erteilung der Berechtigungen CAP_DAC_OVERRIDE , CAP_SYS_ADMIN und CAP_NET_ADMIN .
  • Protokollieren Sie keine Systemdaten auf der SD-Karte.
  • Verwenden Sie bereitgestellte Typen für den Treiberzugriff, z. B. gpu_device , audio_device usw.
  • Verwenden Sie aussagekräftige Namen für Prozesse, Dateien und SELinux-Typen.
    • Stellen Sie sicher, dass keine Standardbezeichnungen verwendet werden und ihnen kein Zugriff gewährt wird.
  • Die gerätespezifische Richtlinie sollte 5–10 % der gesamten auf einem Gerät ausgeführten Richtlinie ausmachen. Anpassungen im Bereich von über 20 % enthalten mit ziemlicher Sicherheit überprivilegierte Domänen und tote Richtlinien. Eine unnötig große Richtlinie verschwendet Arbeitsspeicher, verschwendet Speicherplatz, da ein größeres Boot-Image erforderlich ist, und wirkt sich negativ auf die Suchzeiten der Laufzeitrichtlinie aus.

Dynamisches Laden der SELinux-Richtlinie

Laden Sie die SELinux-Richtlinie nicht dynamisch auf Android-Geräten. Dies kann zu folgenden Problemen führen:

  • Verhinderung der Akzeptanz kritischer Sicherheitspatches.
  • Offenlegung der Möglichkeit, ein Gerät durch Neuladen von Richtlinien zu rooten.
  • Offenlegung eines Vektors für Man-in-the-Middle-Angriffe gegen den Richtlinien-Updater.
  • Dies führt zu blockierten Geräten aufgrund von Fehlern bei Richtlinienaktualisierungen.

Hintertüren

Android-Apps sollten keine Hintertüren oder Zugriffsmöglichkeiten auf das System oder die Daten haben, die normale Sicherheitsmechanismen umgehen. Dazu gehören spezielle Zugriffe für Diagnose, Debugging, Entwicklung oder Garantiereparatur, die durch Geheimnisse geschützt sind, die dem Entwickler bekannt sind. Um Hintertüren zu verhindern:

  • Scannen Sie alle Apps von Drittanbietern mit einem branchenweit anerkannten Tool zum Scannen von App-Schwachstellen.
  • Führen Sie Codeüberprüfungen des gesamten Codes mit vertraulichem Zugriff durch, einschließlich Bibliotheken von Drittanbietern.
  • Nutzen Sie Google Play Protect, indem Sie Apps zum Scannen auf Google Play hochladen. Sie können Apps zum Scannen hochladen, ohne sie bei Google Play zu veröffentlichen.
  • Laden Sie in Release-Builds keine Tools für die Diagnose oder Reparatur vor. Installieren Sie diese Tools nur bei Bedarf, um bestimmte Probleme zu lösen. Darüber hinaus dürfen diese Tools keine kontospezifischen Daten verarbeiten oder hochladen.

Entwicklungswerkzeuge

Entwicklungstools wie Debugging-, Test- und Diagnosetools können häufig unbeabsichtigte Sicherheitslücken auf Ihrem Gerät schaffen, indem sie ihre Funktionsweise und die von ihnen erfassten Daten offenlegen. Um sicherzustellen, dass Entwicklungstools nicht in Produktions-Builds gelangen:

  • Erstellen Sie eine Blacklist mit internen Debug- und Testtool-Hashes und scannen Sie Builds für diese APKs, bevor Sie das System-Image verwenden.
  • Scannen Sie alle Erstanbieter-Apps mit einem branchenweit anerkannten Tool zum Scannen von App-Schwachstellen.
  • Beauftragen Sie ein Drittanbieter-Unternehmen für App-Sicherheitstests mit der Bewertung aller wichtigen Diagnose-Apps auf dem Gerät vor einem größeren Update, insbesondere wenn die App von einem Drittanbieter entwickelt wurde.
  • Stellen Sie sicher, dass nur der Benutzer das Tool während einer Supportsitzung entweder mündlich oder per Chat aktivieren kann. Speichern Sie Einwilligungsartefakte und deaktivieren Sie das Tool, nachdem Sie die erforderlichen Diagnoseinformationen gesammelt haben.
  • Speichern Sie die Nutzungsaufzeichnungen dieses Tools in einem Protokoll, auf das der Benutzer über sein Mobilfunkanbieterkonto zugreifen kann.
  • Stellen Sie sicher, dass alle vom Tool erfassten personenbezogenen Daten (PII) oder Gerätetelemetriedaten den für das jeweilige Land geltenden Anonymisierungs-, Aufbewahrungs- und Löschpraktiken unterliegen. Es sollten nur für den Support-Anruf relevante Daten erhoben werden. Diese Daten sollten nach jedem Aufruf gelöscht werden.
  • Stellen Sie sicher, dass Techniken, die für Spyware verwendet werden können, wie z. B. die Protokollierung von Tastenanschlägen, die Verwendung von Mikrofonen oder Kameras, nicht ohne ausdrückliche Zustimmung des Benutzers verwendet werden. Apps, die diese potenziell in die Privatsphäre eingreifenden Methoden nutzen, sollten zusammen mit einer Datenschutzrichtlinie, der der Benutzer zustimmen muss, sehr deutlich offengelegt werden. Apps wie diese sollten nicht ohne ausdrückliche Zustimmung des Benutzers aktiviert werden.

Hier sind einige zusätzliche Vorschläge, die Sie bei der Umsetzung von Offenlegung und Einwilligung beachten sollten:

Offenlegung in der App

  • Zeigen Sie die normale Nutzung der App direkt in der App an. Der Benutzer muss nicht in ein Menü oder Einstellungen navigieren.
  • Beschreiben Sie die Art der erfassten Daten und erläutern Sie, wie die Daten verwendet werden.
  • Betten Sie diese Informationen idealerweise nicht in eine Datenschutzrichtlinie oder Nutzungsbedingungen ein. Fügen Sie es nicht zusammen mit anderen Offenlegungen ein, die nichts mit der Erhebung persönlicher oder sensibler Daten zu tun haben.
  • Die Zustimmung muss positiv sein. Betrachten Sie das Wegnavigieren von der Offenlegung, einschließlich des Wegtippens oder Drückens der Zurück- oder Home-Taste, nicht als Einwilligung.
  • Präsentieren Sie den Einwilligungsdialog klar und eindeutig.
  • Erfordern eine bestätigende Benutzeraktion, z. B. Tippen zum Akzeptieren oder Sprechen eines Befehls zum Akzeptieren.
  • Sammeln Sie keine persönlichen oder sensiblen Daten, bevor Sie Ihre ausdrückliche Einwilligung eingeholt haben.
  • Verwenden Sie keine automatisch schließenden oder ablaufenden Nachrichten.

Eingebettete Funktionalität in AOSP

Das Einbetten zusätzlicher Funktionen in AOSP kann oft zu unerwartetem Verhalten und unerwarteten Konsequenzen führen; mit Vorsicht fortfahren.

  • Stellen Sie sicher, dass der Benutzer gefragt wird, ob er andere Standard-Apps verwenden möchte (z. B. Suchmaschine, Webbrowser, Launcher) und das Senden von Daten außerhalb des Geräts offenlegt.
  • Stellen Sie sicher, dass AOSP-APKs mit dem AOSP-Zertifikat signiert sind.
  • 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 ab dem Start mindestens zwei Jahre lang fortlaufenden Sicherheitssupport erhalten. Dazu gehört auch der Erhalt regelmäßiger Updates, die bekannte Sicherheitslücken beheben.

  • Arbeiten Sie mit Hardwarepartnern wie Ihren SoC-Anbietern zusammen, um entsprechende Supportvereinbarungen für alle Komponenten Ihres Android-Geräts abzuschließen.
  • Stellen Sie sicher, dass Sicherheitsupdates mit minimaler Benutzerinteraktion installiert werden können, um die Wahrscheinlichkeit zu erhöhen, dass Benutzer Updates akzeptieren und auf ihrem Android-Gerät installieren. Die Implementierung nahtloser Systemaktualisierungen oder einer gleichwertigen Sicherheitsfunktion wird dringend empfohlen.
  • Stellen Sie sicher, dass Sie die kumulativen Anforderungen des Android Security Patch Level (SPL) verstehen, wie im Android Security Bulletin erklärt. Beispielsweise müssen Geräte, die die Sicherheitspatchstufe 2018-02-01 verwenden, alle mit dieser Sicherheitspatchstufe verbundenen Probleme sowie Korrekturen für alle in allen vorherigen Sicherheitsbulletins gemeldeten Probleme enthalten.

Dynamische Kernel-Updates

Ändern Sie kritische Systemkomponenten nicht dynamisch. Zwar gibt es einige Untersuchungen, die darauf hindeuten, dass dynamische Kernel-Updates zum Schutz vor Notfallbedrohungen beitragen, doch überwiegen derzeit die geschätzten Kosten den Nutzen. Erstellen Sie stattdessen eine robuste OTA-Update-Methode, um den Schutz vor Schwachstellen schnell zu verteilen.

Schlüsselverwaltung

Behalten Sie gute Schlüsselverwaltungsrichtlinien und -praktiken bei, um die Sicherheit der Signaturschlüssel zu gewährleisten.

  • Geben Sie Signaturschlüssel nicht an externe Parteien weiter.
  • Wenn ein Signaturschlüssel kompromittiert ist, generieren Sie einen neuen Schlüssel und signieren Sie künftig alle Apps doppelt.
  • Speichern Sie alle Schlüssel in Hochsicherheitsmodul-Hardware oder -Diensten, für deren Zugriff mehrere Faktoren erforderlich sind.

System-Image-Signierung

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

  • Signieren Sie Geräte nicht mit einem öffentlich bekannten Schlüssel.
  • Verwalten Sie Gerätesignaturschlüssel auf eine Weise, die branchenüblichen Praktiken für den Umgang mit vertraulichen Schlüsseln entspricht, einschließlich eines Hardware-Sicherheitsmoduls (HSM), das begrenzten, überprüfbaren Zugriff bietet.

Freischaltbare Bootloader

Viele Android-Geräte unterstützen das Entsperren, sodass der Gerätebesitzer die Systempartition ändern oder ein benutzerdefiniertes Betriebssystem installieren kann. Zu den häufigsten Anwendungsfällen gehören die Installation eines Systemabbilds eines Drittanbieters und die Durchführung einer Entwicklung auf Systemebene auf dem Gerät. Um beispielsweise das Systemabbild auf einem Google Nexus oder Pixel zu entsperren, kann ein Benutzer fastboot oem unlock ausführen, wodurch diese Meldung angezeigt wird:

Als Best Practice gilt, dass entsperrbare Android-Geräte vor dem Entsperren alle Benutzerdaten sicher löschen müssen. Wenn beim Entsperren nicht alle Daten ordnungsgemäß gelöscht werden, kann ein Angreifer in der Nähe unbefugten Zugriff auf vertrauliche Android-Benutzerdaten erhalten. Um die Offenlegung von Benutzerdaten zu verhindern, muss ein Gerät, das das Entsperren unterstützt, dies ordnungsgemäß implementieren.

  • Nachdem der Benutzer den Entsperrbefehl bestätigt hat, muss das Gerät eine sofortige Datenlöschung starten. Das Flag unlocked darf erst nach Abschluss des sicheren Löschvorgangs gesetzt werden.
  • Wenn ein sicherer Löschvorgang nicht abgeschlossen werden kann, muss das Gerät im gesperrten Zustand bleiben.
  • Wenn vom zugrunde liegenden Blockgerät unterstützt, sollte ioctl(BLKSECDISCARD) oder ein gleichwertiges Produkt verwendet werden. Für eingebettete MultiMediaCard-Geräte (eMMC) bedeutet dies die Verwendung eines Secure Erase- oder Secure Trim-Befehls. Für eMMC 4.5 und höher bedeutet dies die Verwendung eines normalen Erase- oder Trim-Vorgangs, gefolgt von einem Sanitize-Vorgang.
  • 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 das Überschreiben der Blockgeräte mit ausschließlich Nullen akzeptabel.
  • Ein Benutzer muss die Möglichkeit haben, zu verlangen, dass Benutzerdaten vor dem Flashen einer Partition gelöscht werden. Beispielsweise verwenden Nexus-Geräte den Befehl fastboot oem lock , um Benutzerdaten zu löschen.
  • Ein Gerät kann über eFuses oder ähnliche Mechanismen aufzeichnen, ob ein Gerät entsperrt und/oder wieder gesperrt wurde. Wir empfehlen jedoch dringend, den Bootloader erneut zu sperren und anschließend auf die Werkseinstellungen zurückzusetzen, um die volle Funktionalität des Geräts wiederherzustellen.

Diese Anforderungen stellen sicher, dass alle Daten nach Abschluss eines Entsperrvorgangs zerstört werden. Das Versäumnis, diese Schutzmaßnahmen zu implementieren, wird als Sicherheitslücke mittleren Grades betrachtet.

Ein entsperrtes Gerät kann anschließend mit dem Befehl fastboot oem lock wieder gesperrt werden. Das Sperren des Bootloaders bietet mit dem neuen benutzerdefinierten Betriebssystem denselben Schutz für Benutzerdaten wie mit dem ursprünglichen Betriebssystem des Geräteherstellers (z. B. werden Benutzerdaten gelöscht, wenn das Gerät erneut entsperrt wird).

Geräte-Pentesting

Geräte sollten vor dem Versand von einem kompetenten Prüfer überprüft werden. Durch Penetrationstests sollte festgestellt werden, dass das Gerät die hier bereitgestellten Sicherheitsrichtlinien sowie die internen OEM-Sicherheitsrichtlinien befolgt.

Sicherheitstests

Nutzen Sie die von AOSP bereitgestellten Sicherheitstest- Tools. Insbesondere

  • Verwenden Sie während der Entwicklung Speichersicherheitstools : Verwenden Sie MTE , wo dies unterstützt wird (ARMv9 und höher), und HWASan , wo dies nicht unterstützt wird. Führen Sie so viele Tests wie möglich mit aktivierten Tools durch.
  • Verwenden Sie GWP-ASan und KFENCE in der Produktion zur probabilistischen Erkennung von Speichersicherheitsproblemen.