Zum Inhalt springen
Open Sourced
Zurück zum Blog

Läuft meine Banking-App noch? — Play Integrity auf entgoogelten Geräten

Orell6 Min. Lesezeit

slug: play-integrity-banking-apps-entgoogelte-geraete status: draft category: digitale-freiheit tags: [android, datenschutz, vendor-lock-in] titleDe: Läuft meine Banking-App noch? — Play Integrity auf entgoogelten Geräten titleFr: titleEn: excerptDe: Ob eine App auf einem entgoogelten Gerät läuft, entscheidet nicht die Entwickler-Verifizierung, sondern die Play-Integrity-API. Wie ihre drei Stufen funktionieren — und wo Hardware-Attestierung die offene Alternative ist. sources:

Zwei Tore, nicht eines

Googles Entwickler-Verifizierung — die wir an anderer Stelle als Lock-in-Mechanismus eingeordnet haben — regelt, wer eine App veröffentlichen darf. Sie ist ein Tor vor der Installation. Daneben steht ein zweites, technisch ganz anderes Tor: Es entscheidet zur Laufzeit, ob eine bereits installierte App einem Gerät vertraut. Dieses zweite Tor ist die Play-Integrity-API.

Die Unterscheidung ist nicht akademisch. Die Frage, die sich Nutzerinnen entgoogelter Geräte am häufigsten stellen — «Läuft meine Banking-App noch, wenn ich GrapheneOS oder CalyxOS einsetze?» —, beantwortet nicht die Entwickler-Verifizierung. Selbst wenn die App sauber verteilt und installiert ist, kann sie sich beim Start weigern zu laufen. Ob sie das tut, hängt von der Play-Integrity-API ab und davon, welche Vertrauensstufe die Bank verlangt.

Was die Play-Integrity-API prüft

Die Play-Integrity-API ist Googles Nachfolger der früheren SafetyNet Attestation. Eine App fragt Googles Server nach einem signierten Urteil über das Gerät, die App-Version und das Nutzerkonto. Zurück kommen sogenannte Geräte-Labels — abgestufte Aussagen darüber, wie vertrauenswürdig das Gerät aus Googles Sicht ist.

Es gibt drei Geräte-Stufen. Ihre offiziellen Definitionen sind der Kern der ganzen Frage:

  • MEETS_BASIC_INTEGRITY — «The app is running on a device that passes basic system integrity checks.» Der Bootloader darf gesperrt oder entsperrt sein, das Gerät «may not be certified». Verlangt wird auf Android 13+ nur, dass die Vertrauenswurzel von Google stammt. Es ist die schwächste Stufe.
  • MEETS_DEVICE_INTEGRITY — «The app is running on a genuine and certified Android device.» Auf Android 13+ braucht es den hardware-gestützten Nachweis, dass der Bootloader gesperrt ist und ein «certified device manufacturer image» geladen wurde.
  • MEETS_STRONG_INTEGRITY — «genuine and certified Android device with a recent security update.» Verlangt zusätzlich zu MEETS_DEVICE_INTEGRITY Sicherheitsupdates im letzten Jahr für alle Partitionen.

Das entscheidende Wort wiederholt sich: «certified». Sowohl die Geräte- als auch die starke Stufe setzen ein von Google zertifiziertes Betriebssystem-Image voraus. Seit Android 13 sind diese Prüfungen hardware-gestützt — sie hängen an einem Schlüssel, der im Sicherheitschip des Geräts erzeugt wurde und ihn nie verlässt.

Was auf entgoogelten Geräten tatsächlich passiert

Hier trennen sich die beiden grossen entgoogelten Systeme — und beide landen am selben Punkt.

GrapheneOS mit Sandboxed Google Play: Die Google-Play-Dienste laufen hier als ganz normale, unprivilegierte App im Standard-Sandbox — ohne Sonderzugriff, ohne privilegierte Integration ins System. Die Play-Integrity-API liefert hier zwar ein Ergebnis, aber nur das schwächste. GrapheneOS dokumentiert für die zugrunde liegende Prüfung: «GrapheneOS passes the basicIntegrity check but isn't certified by Google so it fails the ctsProfileMatch check». Übertragen auf die Play-Integrity-Stufen heisst das: Die Basisstufe wird erreicht, die zertifizierungsgebundene Geräte- und die starke Stufe nicht. Das folgt zwingend aus der Definition: MEETS_DEVICE_INTEGRITY verlangt ein «certified device manufacturer image», und genau das ist ein alternatives, selbst gebautes System per Definition nicht.

CalyxOS geht den microG-Weg. Statt Googles Play-Dienste sandboxt CalyxOS microG, eine quelloffene Reimplementierung. Damit Apps microG überhaupt als «Google Play Services» akzeptieren, braucht es Signature-Spoofing — die Fähigkeit, die erwartete Google-Signatur vorzuweisen. CalyxOS erlaubt das bewusst restriktiv: Die Berechtigung ist als signature|privileged markiert und die zu spoofende Signatur ist fest auf die microG-Pakete verdrahtet, statt sie beliebigen Apps freizugeben. microG kann die Geräte- und die starke Integritätsstufe in der Regel nicht erreichen, weil diese auf proprietären Google-Binärdateien und der vollständigen Attestierungskette beruhen — der Test bleibt bei der Basisstufe stehen.

Praktisch heisst das: Eine App, die der Play-Integrity-API nur MEETS_BASIC_INTEGRITY abverlangt, läuft auf beiden Systemen. Eine App, die auf MEETS_DEVICE_INTEGRITY besteht, verweigert den Dienst. Ob Ihre Banking-App weiterläuft, hängt also weder daran, ob die Bank eine APK ausliefert, noch an der Entwickler-Verifizierung — sondern allein daran, welche Vertrauensstufe die Bank in ihrer App verlangt.

Die eigentliche Wahl: Play Integrity oder Hardware-Attestierung

An dieser Stelle wird der Lock-in-Charakter sichtbar. Die Geräte-Integritätsstufe vertraut nicht der tatsächlichen Sicherheit eines Geräts, sondern der Google-Zertifizierung. Ein gehärtetes GrapheneOS mit gesperrtem Bootloader und Verified Boot fällt durch; ein veraltetes, aber zertifiziertes Lagergerät besteht. Die Stufe misst Herkunft, nicht Sicherheit.

Dass es anders ginge, zeigt die Technik darunter. Android hat seit Version 8 eine hardware-gestützte Schlüssel-Attestierung — Schlüssel, die im Sicherheitschip erzeugt werden und beweisbar dort bleiben. GrapheneOS unterstützt die standardisierte Hardware-Attestierungs-API und beschreibt sie als «a much stronger form of attestation than the Play Integrity API with the ability to whitelist the keys of alternate operating systems». Eine App kann damit die Integrität eines Geräts kryptografisch prüfen — Hardware, Firmware, Betriebssystem und App — und dabei den Verified-Boot-Schlüssel eines alternativen, sicheren Systems zulassen. Das Verfahren «avoids an unnecessary dependency on Google Play services and Google's Play Integrity servers».

Beide Wege nutzen dieselbe Hardware-Wurzel: Die starke Play-Integrity-Stufe ist laut GrapheneOS «directly based on the hardware key attestation API». Der Unterschied liegt nur in der Politik obendrauf. Play Integrity koppelt «vertrauenswürdig» fest an «von Google zertifiziert» und schliesst damit jedes Aftermarket-System aus, egal wie sicher es ist. Die direkte Hardware-Attestierung koppelt Vertrauen an die nachweisbare Hardware- und OS-Integrität und kann sichere Drittsysteme einschliessen. Welches Tor eine App benutzt, entscheidet die App-Entwicklung — und die meisten wählen den für Google bequemen Weg.

Was technische Entscheider jetzt tun können

Für jede Organisation, die entgoogelte Geräte erwägt — aus Datenschutz-, Souveränitäts- oder Sicherheitsgründen —, ist die Lage damit konkret prüfbar statt diffus bedrohlich:

  1. Anforderungsstufe der kritischen Apps klären. Nicht jede Banking- oder Bezahl-App verlangt Geräte-Integrität; viele begnügen sich mit der Basisstufe. Welche Stufe eine App fordert, lässt sich nur am realen Gerät feststellen, nicht aus der Dokumentation.
  2. Vor dem Flottenentscheid testen. Spielen Sie die zwingend nötigen Apps auf ein Testgerät mit GrapheneOS oder CalyxOS, bevor Sie eine Geräteklasse standardisieren. Eine einzelne App, die auf MEETS_DEVICE_INTEGRITY besteht, kann die ganze Entscheidung kippen — oder eben nicht, wenn sie die Basisstufe akzeptiert.
  3. Bei Eigenentwicklung die Hardware-Attestierung erwägen. Wer selbst Apps baut und sichere Aftermarket-Systeme unterstützen will, kann die standardisierte Hardware-Attestierungs-API statt der Play-Integrity-API verwenden — und so Vertrauen an die tatsächliche Geräteintegrität binden, nicht an die Google-Zertifizierung.

Wer für eine solche Strategie geeignete Geräte braucht, kann entgoogelte Smartphones mit CalyxOS vorkonfiguriert beziehen oder die Auswahl und die App-Verträglichkeit vorab beraten lassen, statt sie selbst durchzutesten.

Die Entwickler-Verifizierung entscheidet, wer Software veröffentlichen darf; die Play-Integrity-API entscheidet, wessen Gerät als vertrauenswürdig gilt, um sie laufen zu lassen. Beide Tore verschieben die Kontrolle in Richtung Google. Wer weiss, welches Tor im konkreten Fall greift, trifft eine informierte Geräteentscheidung — statt an der Kasse oder beim Login überrascht zu werden.

DatenschutzAndroid

Weitere Beiträge