Warum einzelne Banking-Apps auf Android nur mit offiziellen Google Play Services funktionieren

Aus Volla Wiki
Zur Navigation springen Zur Suche springen

Warum Banking-Apps auf Android oft nur mit offiziellen Google Play Services funktionieren

Banking-Apps und andere sicherheitskritische Anwendungen implementieren umfangreiche Integritäts- und Sicherheitsprüfungen, um manipulierte Systeme, Root-Zugriff oder nicht zertifizierte Android-Installationen zu erkennen.<ref name="android-security"/> Ziel dieser Prüfungen ist es, das Risiko unautorisierter Zugriffe, Datenmanipulation oder betrügerischer Transaktionen zu reduzieren. Technisch stützen sich viele dieser Mechanismen auf proprietäre Sicherheits- und Attestierungsdienste von Google, die ausschließlich auf zertifizierten Android-Systemen mit originalen Google Play Services (GMS) vollständig unterstützt werden.

Abhängigkeit von Google Play Services (GMS)

Viele Android-Apps nutzen APIs der Google Play Services, unter anderem für Push-Benachrichtigungen (Firebase Cloud Messaging), Standortdienste, Lizenzprüfungen oder Integritätsnachweise über die Play Integrity API.<ref name="gms-apis"/> Diese Dienste sind proprietär und nicht Teil des Android Open Source Project (AOSP).

microG ist eine quelloffene Reimplementierung ausgewählter GMS-Schnittstellen. Sie zielt auf funktionale Kompatibilität ab, kann jedoch nicht alle APIs vollständig oder identisch nachbilden.<ref name="microg-docs"/> Apps können unter anderem prüfen:

  • Ob das Paket com.google.android.gms vorhanden und mit der originalen Google-Signatur signiert ist. microG nutzt hierfür sogenanntes Signature Spoofing, das von Apps explizit erkannt werden kann.<ref name="microg-spoofing"/>
  • Ob das Laufzeitverhalten bestimmter APIs (z. B. Fehlercodes, Timing, interne Klassen) exakt dem der originalen Google Play Services entspricht.

Abweichungen vom erwarteten Verhalten werden von sicherheitskritischen Apps häufig als Integritätsverletzung gewertet.

Device Integrity Checks: Play Integrity API

Ein zentraler Bestandteil moderner App-Sicherheitsprüfungen ist die Play Integrity API. Sie ersetzt die frühere SafetyNet Attestation API, deren Nutzung seit 2024/2025 eingeschränkt bzw. eingestellt wurde.<ref name="play-integrity-overview"/>

Dabei sendet die App eine Anfrage an Google-Server, die ein kryptografisch signiertes Integritätsurteil (Integrity Verdict) zurückliefern.<ref name="play-integrity-details"/>

Dieses kann unter anderem folgende Status enthalten:

  • MEETS_BASIC_INTEGRITY: Softwarebasierte Prüfung auf bekannte Manipulationen.
  • MEETS_DEVICE_INTEGRITY: Erweiterte Prüfung der Systemintegrität und Gerätekonfiguration.
  • MEETS_STRONG_INTEGRITY: Hardwarebasierte Attestation unter Nutzung der Trusted Execution Environment (TEE) bzw. StrongBox, bei der geprüft wird, ob
 * das Gerät Play-Protect-zertifiziert ist,
 * der Bootloader gesperrt ist,
 * die Verified-Boot-Kette intakt ist und
 * das Betriebssystem mit vom Hersteller freigegebenen Schlüsseln signiert wurde.<ref name="hardware-attestation"/>

Auf Custom-ROMs (z. B. LineageOS) ohne offizielle Zertifizierung gilt typischerweise:

  • Ein entsperrter Bootloader verhindert das Bestehen hardwarebasierter Attestation.<ref name="verified-boot"/>
  • Nicht herstellerseitig signierte Systemimages erfüllen die Anforderungen für Strong Integrity nicht.
  • microG kann keine hardwaregestützten Attestierungen erzeugen, da diese direkt durch Secure Hardware und Googles Server validiert werden.<ref name="strongbox"/>

Viele Banking-Apps setzen mindestens DEVICE_INTEGRITY, teilweise explizit STRONG_INTEGRITY voraus. Bei Nichterfüllung wird die App nicht gestartet oder der Zugriff eingeschränkt.

Weitere von Apps genutzte Prüfmechanismen

Neben der Play Integrity API kommen häufig zusätzliche Prüfungen zum Einsatz:

  • Bootloader-Status: Abfrage über Systemparameter wie ro.boot.verifiedbootstate oder ro.boot.flash.locked.<ref name="bootloader"/>
  • Build-Properties: Analyse von Build-Tags (release-keys vs. test-keys) und Build-Fingerprint.<ref name="build-props"/>
  • Play Protect Certification: Abgleich des Geräts mit Googles Zertifizierungsdatenbank.<ref name="play-protect"/>
  • Widevine DRM: Nutzung von DRM-Level L1, das nur auf zertifizierten Geräten mit intakter TEE verfügbar ist.<ref name="widevine"/>
  • App-spezifische Sicherheitsprüfungen: Kombination aus Root-Erkennung, Code-Obfuskation und serverseitiger Bewertung durch den Anbieter.

Einordnung von microG im Kontext sicherheitskritischer Apps

Custom-ROMs mit microG können technisch aktuell und sicher konfiguriert sein. Dennoch werden sie von vielen Banking-Apps nicht unterstützt:

  • Die Sicherheitsmodelle basieren primär auf formaler Zertifizierung und nicht auf individueller Systembewertung.<ref name="trust-chain"/>
  • Finanzinstitute orientieren sich an regulatorischen Anforderungen und Haftungsfragen, bei denen zertifizierte Plattformen bevorzugt werden.<ref name="bank-compliance"/>
  • Umgehungslösungen (z. B. mittels Root-Frameworks oder Modulen) unterliegen regelmäßigen Gegenmaßnahmen durch Google und App-Anbieter.
  • Die Entwicklung geht in Richtung verpflichtender hardwarebasierter Attestierung, wodurch softwarebasierte Reimplementierungen weiter an Bedeutung verlieren.<ref name="future-integrity"/>

Zusammenfassend sind viele Banking-Apps so konzipiert, dass sie ausschließlich auf Google-zertifizierten Android-Geräten mit originalen Google Play Services betrieben werden können. microG ermöglicht die Nutzung zahlreicher Anwendungen ohne Google-Dienste, stößt jedoch bei hochsicherheitsrelevanten Apps an technische und konzeptionelle Grenzen.

Quellen

https://developer.android.com/guide/ https://microg.org/docs https://github.com/microg/ https://source.android.com/docs/security/ https://www.widevine.com/ https://www.eba.europa.eu/regulation-and-policy/

Abgerufen von „http://wiki.volla.online/index.php?title=Warum_einzelne_Banking-Apps_auf_Android_nur_mit_offiziellen_Google_Play_Services_funktionieren&oldid=6117“